정도영 Doyoung Jeong

유아·초등 스마트 학습 서비스 '윙크(Wink)'를 운영하는 에듀테크 기업.

담당메인 서버·큐레이션·결제·인증·인도네시아·개발 표준 플랫폼 등 6개 백엔드 서비스의 기능 개발과 플랫폼 엔지니어링을 함께 담당. 인도네시아 현지 채널 API(방문교사 오프라인 체험 신청, WhatsApp QR 전송)와 Meta 전환 이벤트 서버 사이드 수집(Conversions API) 구축, 운영 장애 대응, 4개 서비스 정기 릴리즈 관리.

1. 백오피스 API 신구조 설계·이관

   2026.07 ~ 진행 중

   한 일

   백오피스 화면이 쓰는 API를 화면 하나에 API 하나가 대응하는 구조로 새로 설계하고, 백오피스 API 전체를 이 구조로 옮겼습니다.

   • 프론트엔드가 API 3~4개를 조합해 구성하던 백오피스 화면을 화면 1개 = 엔드포인트 1개 규칙의 도메인 네임스페이스 구조로 재설계하고, 백오피스 API 전체를 새 구조로 이관
   • 여러 API를 호출해 조합하던 프론트엔드 호출을 1회 호출로 줄이고, 성능이 우려되는 지점은 DB 인덱스와 캐시로 보완
   • ISMS 인증 대응을 위해 개인정보 마스킹과 화면 단위 권한 통제 등 백오피스 보안 고도화

   이유

   화면 하나를 구성하려면 프론트엔드가 API 3~4개를 조합해야 했고, 레거시 시스템에서는 어떤 API가 어느 화면에 쓰이는지 알 수 없어 화면 단위로 권한과 개인정보를 통제할 수 없었습니다.

   결론

   화면 단위로 권한과 마스킹을 통제할 수 있게 됐고, 프론트엔드의 API 호출은 화면당 1번으로 줄었습니다. 이 과정에서 팀의 API 작업 규칙을 다시 정의해 공유했습니다.

2. 학습지 화상 수업 '꾹꾹' 신규 서비스

   2026.06 ~ 진행 중

   한 일

   운영 중인 학습 서비스 '윙크'와 회원·상품·배송 데이터를 함께 쓰는 신규 서비스 '꾹꾹'의 백엔드를 가입부터 수업까지 전 구간 개발했습니다.

   • 윙크의 기능을 그대로 활용해야 해서 테이블·배치를 함께 쓰는 구조에서, 운영 서비스에 문제없이 신규 서비스를 오픈할 수 있도록 백엔드 전 구간 연결
   • 신규 회원 목록 조회 시 약 154만 행의 JSONB를 스캔하는 회원 판별 쿼리로 지연이 발생해, partial index와 조회 범위 축소로 6.2초 → ms 단위로 개선

   이유

   두 서비스가 같은 데이터를 쓰기 때문에 잘못 연결하면 운영 중인 윙크 회원의 배송·결제에 바로 영향을 줄 수 있었습니다. 또 신규 회원을 구분하는 조회 쿼리가 회원 목록 화면마다 약 6.2초씩 걸렸습니다.

   결론

   기존 윙크 서비스에 영향 없이 '꾹꾹'을 오픈했고, 회원 구분 조회를 약 6.2초 → ms 단위로 개선해 회원 수가 급격히 늘어도 성능이 유지되도록 했습니다.

3. 학습 콘텐츠 제작·배포 시스템(LCMS) 신규 구축

   2026.03 ~ 진행 중

   한 일

   학습 콘텐츠를 콘텐츠 제작팀이 직접 편집하고 배포할 수 있는 관리 시스템(LCMS)의 백엔드를 구축했습니다.

   • 개발자가 직접 하드코딩해 배포하던 학습 콘텐츠를 콘텐츠 제작팀이 직접 편집·배포할 수 있도록 도메인 데이터 모델링부터 배포 파이프라인까지 신규 구축
   • 이력 관리를 위한 스냅샷과 배포 이력으로 재배포·롤백 기능 확보
   • 콘텐츠 캐시 구조를 정리해 배포마다 실행하던 CloudFront 캐시 무효화(invalidation) 제거

   이유

   학습 콘텐츠를 바꿀 때마다 개발자가 직접 코드에 반영해야 했고, 한 번 배포한 콘텐츠를 다시 확인하거나 되돌릴 방법이 없었습니다.

   결론

   콘텐츠 변경에 더 이상 개발자 작업이 필요하지 않게 됐고, 제작팀이 배포한 콘텐츠를 직접 다시 배포하거나 되돌릴 수 있게 됐습니다.

4. 로깅·관측성 인프라 구축

   2026.02 ~ 2026.07

   한 일

   4개 서비스의 로그를 같은 형식으로 통일하고, 요청 하나를 처음부터 끝까지 추적할 수 있는 로깅 체계를 만들었습니다.

   • 시스템 로그만 있던 환경에 API 로깅과 trace_id 기반 요청 추적을 도입하고, 4개 서비스가 같은 JSON 형식으로 로그를 남기도록 적용
   • 결제 정보와 개인정보가 담긴 로그는 마스킹 처리해 보안 강화

   이유

   서비스마다 로그 형식이 달라 검색이 어려웠고, 장애나 문의가 들어와도 어떤 요청이 어디서 실패했는지 추적하기 어려워 원인 파악이 늦어지곤 했습니다.

   결론

   4개 서비스에서 요청 하나를 끝까지 추적할 수 있게 됐고, 개인정보와 민감정보는 마스킹돼 원문 그대로 로그에 남지 않습니다.

5. Python · Django 메이저 버전 업그레이드

   2026.06 ~ 2026.08

   한 일

   메인 서버의 Python 3.9 → 3.11, Django 3.2 → 4.2 LTS 업그레이드와 배포 이미지 재구성을 진행했습니다.

   • Python 3.9 → 3.11, Django 3.2 → 4.2 LTS 마이그레이션과 4단계 multi-stage 빌드로 배포 이미지를 재구성해, 막혀 있던 의존성 업그레이드 경로 확보

   이유

   사용 중인 버전의 보안 지원 종료가 다가왔고, 필요한 라이브러리들이 새 버전만 지원하기 시작해 업그레이드가 막혀 있었습니다.

   결론

   장기 지원(LTS) 기간을 확보했고, 막혀 있던 라이브러리 업그레이드를 진행할 수 있게 됐습니다.

6. Python 패키지 관리 고도화

   2025.09 ~ 2026.01

   한 일

   패키지 관리 도구를 requirements.txt에서 uv와 Poetry로 바꿔 모든 환경의 패키지 의존성을 관리하도록 했습니다. 레포지토리 특성에 맞춰 uv와 Poetry를 나눠 적용했습니다.

   이유

   개발자 환경마다 설치되는 패키지 버전이 달라, 로컬에서는 정상 동작하지만 운영 환경에서는 실패하는 문제를 재현하기 어려웠습니다.

   결론

   모든 환경의 패키지 버전을 통일해 의존성을 일관되게 관리할 수 있게 됐고, 이를 바탕으로 이후 Django 메이저 버전 업그레이드를 진행할 수 있었습니다.

7. 백엔드 팀 컨벤션 Claude Code 플러그인 개발

   2026.02 ~ 2026.09

   한 일

   팀 코딩 표준을 Claude Code 플러그인으로 만들어 사내에 배포했습니다.

   • 팀 코딩 표준을 바로 실행할 수 있는 Claude Code 플러그인으로 만들고, 이를 배포하는 사내 마켓플레이스 구축
   • 특정 레포지토리를 하드코딩하지 않고 세션 시작 시 현재 프로젝트를 탐색하도록 설계해 여러 레포지토리에서 공통으로 사용

   이유

   코딩 표준이 문서로만 있어 지켜지지 않았고, LLM이 작성한 코드의 품질이 떨어지거나 코드 리뷰에서 같은 지적이 매번 반복됐습니다.

   결론

   LLM이 코드를 작성하는 시점에 표준이 적용돼 리뷰에서 반복되던 지적이 줄었습니다. 팀 전체가 같은 규칙으로 LLM 코드를 리뷰하게 되면서 프로젝트 전반의 코드 스타일이 통일돼 가독성도 좋아졌습니다.

8. 테스트·CI 개선

   2025.09 ~ 2026.02

   한 일

   307개 파일 규모의 테스트를 정리하고, PR마다 테스트가 자동으로 실행되도록 GitHub Actions를 도입했습니다.

   이유

   테스트가 오래 걸려 로컬 검증을 건너뛰는 일이 잦았고, 테스트 자동 실행 환경이 없어 실패하는 테스트를 머지한 뒤에야 발견했습니다.

   결론

   실패하는 테스트를 머지 전에 잡을 수 있게 됐고, CI 테스트 시간은 1시간 → 17분으로 줄었습니다.

가족 여가 플랫폼 '놀이의발견' 운영.

담당레저·숙소 API와 총판 거래 시스템 담당. 자사 직거래 숙소와 외부 공급사(OTA) 상품을 한데 모아 검색·가격 비교·예약을 제공하는 숙박 커머스 백엔드 신규 구축, API 개발·운영(CS)·데이터 추출, QuickSight 기반 백오피스 통계 대시보드 개발 보조.

1. 숙소 시스템 Java → Django 전환

   한 일

   Java 숙소 시스템을 Django로 전환하는 프로젝트(BE 4인)에서 신규 DB 설계에 참여하고, 기존 데이터 이관을 혼자 맡았습니다.

   • BE 4인 팀에서 신규 DB 모델링에 주도적으로 참여하고 데이터 마이그레이션을 혼자 전담
   • 정산 금액 계산 등 정책이 바뀌어 SQL로 그대로 옮길 수 없는 데이터를 Python 스크립트 + Django ORM으로 변환하고 운영과 같은 로컬 환경에서 검증해, 5년 누적 데이터 이관 후 오픈 당시 데이터 장애 0건
   • Postman으로 관리하던 API 문서를 drf-spectacular 기반 OpenAPI 3.0 스키마 자동 생성으로 전환하고, 표준 응답 포맷·에러 코드 체계를 문서화해 프론트엔드 문의 감소

   이유

   5년간 쌓인 데이터를 옮겨야 했는데, 정산 금액 계산 같은 정책이 바뀌어 데이터를 그대로 복사할 수 없었습니다.

   결론

   5년치 데이터를 모두 옮겼고, 오픈 당시 데이터 장애 0건이었습니다.

2. Elasticsearch 숙소 검색 고도화

   한 일

   Elasticsearch 기반 숙소 검색의 안정성과 기능을 개선했습니다. 검색 장애 시 DB 검색으로 자동 전환하는 구조와 상품 변경이 바로 반영되는 색인 방식을 만들었습니다.

   • 대용량 Document 하나를 여러 개로 나눠(샤딩) 색인 타임아웃 에러율 10% → 0%
   • alias 원자적 교체로 무중단 재색인을 구현하고, 숙소 단위 부분 색인으로 전체 재색인 없이 상품 변경을 즉시 반영
   • ES 에러 시 RDB 조회로 자동 전환하는 failover를 구축해 검색의 단일 실패 지점을 없애고, 실제 ES 장애 때도 같은 필터 조건으로 검색 유지
   • Nested Field·inner_hits 기반 요금·날짜 검색, 동적 쿼리 빌더, geo distance 위치 검색, 최근 14일 예약·취소 금액 기반 랭킹 구현

   이유

   색인 요청의 10%가 타임아웃으로 실패했고, 검색 엔진이 멈추면 검색 전체가 멈췄습니다. 상품을 바꿔도 전체를 다시 색인해야 반영됐습니다.

   결론

   색인 에러율 10% → 0%를 달성했고, 실제 검색 엔진 장애 때도 검색이 유지됐으며, 상품 변경은 즉시 반영됩니다.

3. 외부 공급사(OTA) 연동·최저가 수집

   한 일

   아고다·온다 같은 외부 숙박 공급사 상품을 자사 숙소와 함께 검색·예약할 수 있도록 연동 구조를 설계하고, 외부 상품 최저가를 매일 미리 수집해 검색에 반영했습니다.

   • 레지스트리 패턴으로 아고다·온다 연동을 하나의 인터페이스로 통일해, 코어 로직을 수정하지 않고 구현체 등록만으로 신규 공급사를 추가하는 구조 설계
   • ES 검색에 외부 상품 가격을 보여 주기 위해 인원 × 체크인 날짜 조합별 최저가를 하루 한 번 asyncio·aiohttp로 미리 수집해 색인에 반영하고, 상세 조회 시에는 실시간 조회로 실제 가격 확인
   • 배치 Job 프레임워크로 색인·최저가 갱신·랭킹 산출·예약 완료 처리 등 운영 배치 통합

   이유

   공급사마다 API와 취소·환불 정책이 달라 연동이 늘수록 코드가 복잡해지는 구조였고, 외부 상품 가격은 미리 확보하지 않으면 검색 결과에 보여 줄 수 없었습니다.

   결론

   새 공급사는 기존 코드를 수정하지 않고 추가할 수 있게 됐고, 외부 상품도 자사 숙소와 같은 검색 결과에 가격과 함께 노출됩니다.

4. 총판 주문·재고와 대행사 시스템

   한 일

   쿠팡·네이버 등 7개 판매 채널의 주문을 처리하는 총판 시스템에서 재고 중복 차감을 막는 잠금 구조를 설계하고, 매일 수기로 하던 마감 업무를 자동화했습니다.

   • 쿠팡·네이버·11번가 등 7개 판매 채널과 파트너사 주문이 함께 쓰는 재고에 상품-옵션 단위로 Redis Lock과 최종 방어선인 DB Lock을 이중으로 걸고, 실패하면 재고를 복구해 2년여 운영 동안 중복 주문 사고 0건
   • 매일 00시 파트너센터 수기 마감 업무를 Selenium 크롤링으로 자동화해 운영 리소스 절감
   • 채널·발권사가 늘면서 단일 Controller에 쌓인 중복 코드를 채널·발권사별 Module과 Service 계층으로 분리, 코드량은 늘었지만 신규 채널 연동 비용 절감

   이유

   여러 채널의 주문이 같은 재고를 동시에 차감해 중복 주문이 생길 수 있었고, 매일 00시 마감은 사람이 직접 처리하고 있었습니다.

   결론

   2년여 운영 동안 중복 주문 사고 0건을 유지했고, 매일 00시 마감 업무는 수작업 없이 처리됩니다.

5. 개발 환경 표준화·운영 기반 정비

   한 일

   전사 프로젝트의 Python 3.6 → 3.11, MySQL 5.7 → 8.0 업그레이드와 개발 환경 표준을 정리하고, 유지보수가 끊긴 JWT 인증 라이브러리를 자체 인증 모듈로 대체했습니다.

   • 전사 프로젝트를 Python 3.6 → 3.11, AWS RDS MySQL 5.7 → 8.0으로 업그레이드하고, Poetry·pre-commit·PR 템플릿으로 신규 프로젝트 셋업 기준 정립
   • 유지보수가 중단된 JWT 라이브러리를 자체 인증 모듈로 대체해 전 프로젝트의 인증 로직 통합 (대안 라이브러리도 PyJWT를 감싼 수준이라 같은 위험이 반복된다고 판단)
   • DB Router로 Reader/Writer 분리, 숙소 목록 N+1 제거, Redis 캐시 적용
   • ECS(Elastic Common Schema) 포맷 구조화 로깅, transaction ID 기반 요청 추적, Slack 에러 알림 구축

   이유

   쓰던 JWT 라이브러리의 유지보수가 중단됐고, 다른 대안 라이브러리에도 같은 위험이 있었습니다.

   결론

   외부 인증 라이브러리 의존이 사라졌고, 모든 프로젝트의 인증 로직이 하나로 모였습니다.

유저스푼(B2B)에서 의뢰받은 기능을 우쥬테스트(B2C) 사용자에게 보여 주고, 피드백을 수집해 리워드를 지급하는 리서치·리워드 플랫폼 운영.

담당초기 1인 백엔드 개발자로 설계부터 운영까지 전담. Pre-A 투자 유치 시점까지 서비스 확장과 안정화를 주도.

1. 1인 백엔드 설계·개발

   한 일

   B2C 리서치 플랫폼과 운영 어드민 2개 서비스의 백엔드 API를 혼자 설계하고 개발했습니다.

   • DRF 기반으로 B2C 플랫폼과 운영 어드민 2개 서비스의 API 아키텍처 전체를 설계·개발하고, 누적 가입자 1만 명 규모까지 운영
   • Swagger 문서를 기준으로 프론트엔드와 협업하는 체계를 만들어 커뮤니케이션 비용 절감

   이유

   개발자가 백엔드 1명, 프론트엔드 1명뿐인 초기 스타트업이라 백엔드 전체를 혼자 맡아야 했습니다.

   결론

   입사 3개월 만에 전체 시스템을 구축했고, 이후 회사는 Pre-A 투자를 유치했습니다. 서비스는 누적 가입자 1만 명 규모까지 운영했습니다.

2. Celery 작업 큐 분리

   한 일

   비동기 작업 큐를 빨리 처리할 작업과 오래 걸리는 작업으로 나누고, 작업 모니터링 도구를 도입했습니다.

   • 하나의 큐에서 사용자 요청과 운영 배치가 경쟁해 대기열이 가득 차던 문제를 고속(알림 발송·쿠폰 구매)·저속(엑셀 생성·데이터 다운로드) 큐 분리로 해결, 사용자 요청은 대기 없이 즉시, 운영 배치는 최대 1분 안에 실행
   • Celery + Flower를 도입해 비동기 작업·배치 모니터링 체계 구축

   이유

   하나의 큐에서 사용자 요청과 운영 배치가 섞여, 배치가 몰리면 사용자 요청 처리가 지연됐습니다.

   결론

   사용자 요청은 대기 없이 바로 처리되고, 운영 배치는 1분 안에 실행됩니다.

3. 클라우드 인프라·배포 자동화

   한 일

   Terraform으로 AWS 인프라를 코드로 관리하고, 테스트를 포함한 개발·운영 배포를 GitLab CI/CD로 자동화했습니다.

   • Terraform(IaC)으로 AWS 리소스를 코드로 관리하고 ECS Fargate + CloudWatch 로그 환경 구성, Docker로 로컬부터 운영까지 같은 실행 환경 확보
   • GitLab CI/CD에 Django 테스트 검증 단계를 포함해 개발·운영 배포 자동화

   이유

   백엔드를 혼자 맡고 있어 API 개발과 인프라 관리를 모두 수동으로 하기에는 여력이 부족했습니다.

   결론

   인프라를 코드로 쉽게 늘리고 줄일 수 있게 됐고, 스테이징 환경을 필요할 때만 생성해 인프라 비용을 크게 줄였습니다.

4. 외부 채널 확장·데이터 품질 개선

   한 일

   카카오 알림톡과 앱 푸시를 함께 보내는 발송 체계와, 불성실 응답을 미리 걸러 내는 피드백 필터링 시스템을 만들었습니다.

   • 카카오 알림톡과 앱 푸시 발송을 분기하는 통합 발송 체계 구축
   • 부정어가 담긴 응답이나 불성실 응답을 미리 걸러 내는 피드백 라벨링 시스템으로 데이터 품질을 확보하고 리워드 어뷰징 방지

   이유

   알림을 카카오 알림톡으로만 보내다가 네이티브 앱이 출시되면서 알림톡과 앱 푸시를 나눠 보내야 했습니다. 또 불성실하거나 부정적인 응답을 수작업으로 선별하느라 운영 부담이 커지고 있었습니다.

   결론

   피드백 데이터의 품질을 확보하고 리워드 어뷰징을 막았습니다.

서민금융진흥원 차세대 프로젝트(금융 공공 SI) 수행.

담당공통팀(4인)에서 서금원 직원용 인트라넷의 회원·메뉴·화면·권한 관리 전반을 담당.

1. Spring 기반 인트라넷 시스템 개발

   한 일

   서민금융진흥원 직원용 인트라넷의 회원·메뉴·화면·권한 관리 기능을 DB 설계부터 API 개발까지 맡았습니다.

   • 회원·메뉴·화면·권한 도메인의 DB 모델링부터 API 개발까지 전담하고, 기능별 설계 문서 작성과 형상 관리 담당

   이유

   여신·수신 같은 금융 업무 시스템은 신입이 맡기 어려워, 신입 4명으로 꾸린 오피스 시스템 팀이 인트라넷의 기반 기능을 맡았습니다.

   결론

   맡은 기능을 일정 안에 100% 완수했고, 이후 결함이 발생하지 않아 담당 프로젝트를 예정보다 일찍 마무리했습니다.

2. 로그인 지연 원인 분석

   한 일

   로그인이 느려지는 원인을 분석·검증하고, 원인을 특정한 자료를 담당 업체에 공유했습니다.

   이유

   지연은 직접 수정할 권한이 없는 다른 업체의 솔루션 구간에서 발생했습니다.

   결론

   수정 권한이 없는 상황에서도 원인 자료를 제공해 문제 해결에 기여했습니다.