[Rookies 개발 4기] 2차 멘토링 일지

2025.11.15 : 2차 멘토링

1. 멘토링 일지

서비스 vs 기술, 확실한 노선 정하기 : 멘토님께서 지금 상태는 흔한 교육 서비스와 기술적 깊이 사이에서 어정쩡하다고 지적하셨다. 심사위원에게 어설프게 둘 다 잘한다고 하기보다는, 서비스 중심(사내 교육 어시스턴트)으로 가되 기술적 차별점(전처리 파이프라인)을 하나 확실하게 가져가는 전략을 세워야 한다고 조언해주셨다.

RAG의 핵심은 '전처리'다 : 단순히 RAG를 쓴다는 건 기술이 아니다. 기업의 지저분한 문서(PDF, PPT 등)를 RAG가 잘 이해할 수 있는 깔끔한 데이터로 만드는 '전처리·청킹·KB 파이프라인' 구축이 진짜 기술적 포인트다. "어려워서 피하는 선택"을 하지 말고 이 과정을 깊게 파고들어야 한다.

영상보다는 '스토리' 품질 : API로 대충 만든 영상은 오히려 마이너스다. 영상 자체보다는 교육에 바로 쓸 수 있는 수준의 '기승전결이 있는 교육 스토리'를 생성하고 검증하는 것이 1순위가 되어야 한다.

---

2. 공부한 내용

데이터 전처리 파이프라인 (Preprocessing Pipeline) : 단순히 텍스트를 자르는 게 아니라, `문서 인입 → 포맷 통일(JSON) → 섹션/카테고리 분석 → 청킹 → 검수 → KB 등록`으로 이어지는 전체 흐름을 설계하는 법을 배웠다. 특히 문서를 쪼갤 때 문맥이 끊기지 않도록 섹션 경계를 유지하고 메타데이터를 붙이는 전략이 중요하다.

WBS와 마일스톤 : WBS는 단순한 '할 일 목록'이 아니라 프로젝트의 진척도와 리스크를 보여주는 도구여야 한다. 태스크마다 가중치를 두고, 언제까지 무엇을 끝낼지 명확한 마일스톤(이정표)을 세워서 관리해야 막판에 일정이 터지는 것을 막을 수 있다.

권한 관리 모델 (Governance) : 아무나 문서를 올리면 안 된다. 잘못된 정보나 민감 정보가 LLM에 들어가는 것을 막기 위해 `업로더 → 검수자 → 최종 승인자`로 이어지는 승인 프로세스를 시스템적으로 구현해야 함을 알게 되었다.

---

3. 사용한 기술 설명 및 이유

Mini-MSA (Microservices Architecture) : 초기에는 백엔드를 단일 서비스로 생각했으나, 영상 처리, RAG, 일반 API 서버가 섞이면 확장성과 관리가 어렵다. 따라서 서비스 단위로 분리하는 Mini-MSA 구조로 아키텍처를 재설계하기로 했다.

Keycloak & 온프레미스 Vector DB : 인증 비용 문제(Okta)와 보안 이슈를 고려해 Keycloak과 온프레미스 Vector DB를 사용한다. 멘토님께서 "DB 연동이 어렵다고 H2 같은 걸 쓰면 안 된다"고 하셨기에, Docker 기반의 MariaDB/MySQL을 정석대로 연동하여 안정성을 확보할 예정이다.

FAQ 자동 생성 기능 제외 : 원래 계획했던 "질문 패턴 분석을 통한 FAQ 자동 생성"은 제외했다. 사용자 질문의 유사도를 분석하고 정형화하는 작업이 개발 기간 대비 난이도가 너무 높고, 품질 보장이 어렵다는 판단 하에 과감히 스코프에서 덜어냈다.

---

4. 문제 해결 과정

1. 프로젝트 정체성 확립 : "이게 팔릴 서비스인가?" vs "기술적으로 대단한가?" 사이에서 팀이 혼란스러웠다.
→ 해결: 최종 목표는 '사내 정보보호/교육 어시스턴트(서비스)'로 정의하되, 우리만의 무기(기술)로 '기업 문서 전처리 자동화 파이프라인'을 내세우기로 합의했다.

2. 콘텐츠 품질 보증(QA) 문제 : AI가 만든 교육 자료나 답변이 틀리면 기업에서는 절대 쓰지 않는다.
→ 해결: 모든 콘텐츠(문서, 영상 스크립트) 생성 과정에 Human-in-the-loop(사람 개입) 단계를 필수로 넣었다. 관리자가 청킹 된 데이터를 눈으로 확인하고 승인해야만 벡터 DB에 저장되도록 프로세스를 수정했다.

3. 아키텍처의 모호함 : 기능은 많은데 구조가 잡히지 않았다.
→ 해결: 멘토링 직후 아키텍처 재설계를 결정했다. 백엔드 단일 컨테이너 구조를 폐기하고, 다음 회의까지 서비스별로 역할이 분리된 인프라 구성도와 API 명세를 다시 작성하기로 했다.