Engineering Story
첫 출시부터 약 3년간 책임진 콘텐츠 제작 제품 백엔드
원본 자료 편집·PDF·판매 등록을 연결한 제품을 출시하고, 메인 백엔드로 기능 확장·배포·운영·성능 개선까지 맡은 사례
- NestJS
- PostgreSQL
- AdminJS
- AWS ECS
제품의 시작과 맡은 역할
처음부터 완성된 콘텐츠 플랫폼이 있었던 것은 아닙니다. 원본 자료를 불러와 편집·저장하고, PDF를 만들고, 고객의 라이선스를 확인해 판매 등록까지 이어지는 실사용 제품의 백엔드가 필요했습니다. 제품은 이후 한 문항을 편집하는 수준을 넘어 시험지, 기출·변형 문제, 분석지, 단어장과 워크북을 만드는 방향으로 계속 확장됐습니다.
제품 설계와 출시 단계부터 약 3년간 메인 백엔드를 맡았습니다. 초기 구조와 기능 구현뿐 아니라 신규 기능, 데이터 이전, 배포, 운영 이슈 대응과 성능 개선까지 같은 제품의 수명주기 안에서 이어서 담당했습니다.
출시 단계에서 만든 핵심 흐름
원본 자료 불러오기, 편집·저장, PDF 생성, 라이선스 확인과 판매 등록이 하나의 사용자 흐름으로 동작하도록 백엔드를 구성했습니다. 원본 자료·문항·지문·교재·이용권·생성 자료의 경계를 모델링하고, 기능이 늘어나도 카테고리·검색·자료 생성과 권한 확인을 확장할 수 있는 API와 데이터 구조로 정리했습니다.
제품에 사용할 콘텐츠를 안정적으로 공급하기 위해 문항 등록, 영역 검수, HTML·메타데이터 편집, 작업자 할당, 검수와 배포 상태를 관리하는 운영 흐름도 구축했습니다. 검수된 데이터만 제품에서 조회되도록 연결해 내부 제작 과정이 실제 사용자 기능으로 이어지게 했습니다.
제품이 확장되며 달라진 백엔드
교재·단원·지문 카테고리와 출처 기반 문항 탐색을 추가하고, 시험지 생성·복사, 필터, 본문 분석, 기출·변형 문제, 단어장과 워크북까지 제품 기능을 확장했습니다. 이용권 모델이 바뀐 뒤에는 제품에서 세부 권한 정보를 다시 확인하도록 구현해 상품별 사용 범위를 구분했습니다.
처리 시간이 길고 실패 영향이 큰 PDF 생성은 Redis 기반 전용 Worker로 분리했습니다. 제품이 커지며 내부 적재·검수 도구, 제품 검색, 이용권과 자료 생성이 서로 단절되지 않도록 데이터 계약과 API 경계를 함께 발전시켰습니다.
약 3년간 이어진 운영과 개선
출시 뒤 생긴 문제도 같은 제품의 백엔드 책임으로 다뤘습니다. PDF Worker의 Browser 리소스 미해제로 전체 Worker가 멈추는 원인을 수정하고, 후속 Puppeteer 종료 문제에는 재시도 로직을 추가했습니다. 데이터가 대용량으로 쌓인 뒤에는 JSONB·TOAST 접근 비용을 분석해 주요 조회 구조와 인덱스를 다시 설계했습니다.
32개 교재의 지문·문항·편집 자료·시험 범위 연결은 staging 검증 뒤 production까지 장애 없이 전환했습니다. 주요 기능과 데이터 변경을 출시할 때마다 배포 이후의 사용자 흐름과 운영 결과를 확인하고, 다음 확장을 막는 구조나 반복 문제를 다시 개선했습니다.
여러 직군과 맞춘 출시 기준
제품 요구사항은 PO와, 화면·API 계약은 프론트엔드와, 문항 영역과 지문 매핑은 ML 담당자와, 원본 데이터와 검수 규칙은 콘텐츠·데이터 담당자와 문서로 맞추고 피드백을 반영했습니다. 백엔드를 혼자 완성하는 방식이 아니라 각 전문 영역의 결과가 한 제품 흐름으로 연결되도록 경계와 예외 조건을 정리했습니다.
대표 사용자가 자료를 불러오고 편집·저장한 뒤 PDF와 판매 등록까지 완료하는 흐름을 확인했고, 주요 스프린트에서는 staging 검증과 배포 체크리스트를 운영했습니다. 출시 전 20명·1,000건 조건에서는 실패 0건과 p95 941ms를 확인해 출시 판단의 보조 근거로 사용했습니다.
제품에 남은 변화와 배운 점
출시 당시의 자료 편집·PDF·판매 등록 흐름은 여러 유형의 시험지와 기출·변형 문제, 분석지, 단어장과 워크북을 만드는 제품으로 확장됐습니다. 구축한 제품 백엔드와 콘텐츠 제작·검수 도구는 현재도 사용되고 있고, 콘텐츠는 지금도 이 과정을 거쳐 제품 데이터로 관리되고 있습니다.
이 경험에서 가장 크게 남은 것은 특정 기능 하나보다 제품을 오래 책임지는 방식입니다. 제품 담당자와 사용자 흐름을 먼저 맞추고, 출시 뒤 생긴 데이터·성능·운영 문제까지 같은 백엔드의 책임으로 가져가는 원칙을 유지했습니다. 다시 시작한다면 자료 생성 성공률, 처리 대기 시간, 단계별 실패율과 주요 조회 성능을 초기부터 제품 지표로 관리해 기능 확장과 운영 개선의 우선순위를 더 빠르게 맞추겠습니다.