IP 기획 가이드 RAG 챗봇: 같은 구조를 내 PRD로 다시 만들기
물류창고 재고 조사 RAG 실습을 먼저 진행한 뒤, 같은 구조로 내 PRD(IP 기획 가이드 챗봇)를 만들며 나온 이슈와 작업 방식을 정리한 기록입니다.
이 글은 Claude(Cowork)와 함께 진행한 작업 기록이다. 주제·자료 원칙·결정은 내가 정했고, 자료 수집·청크 작성·코드·검수·커밋은 Claude가 했다. 임베딩 모델과 LLM이 필요한 명령은 내 Mac에서 내가 실행하고 결과를 붙여 넣었다. 어느 쪽이 한 일인지 구분해서 적었다.
- 제출 저장소: Lightnine999/ip-guide-rag
- 앞 실습 글: 물류창고 재고 조사 RAG 챗봇 과제 실행 기록
이 글의 위치
먼저 학습 과제인 물류창고 재고 조사 RAG 챗봇을 과제 문서대로 한 번 실행했다(앞 글). 그다음 같은 구조(STEP 0~9, CLAUDE.md 계약 → 데이터 → 임베딩 → 검색 → 관찰 → 프롬프트 → 생성 → 비교 → README)를 그대로 두고, 주제만 내 것으로 바꿔 처음부터 다시 만들었다.
| 물류창고 실습 | 이번 작업 | |
|---|---|---|
| 주제 | 재고 조사 안내 | IP 기획 가이드 (스토리텔링 이론, 스튜디오 기법, IP 확장 전략, 국내 캐릭터 사례) |
| 기준 문서 | 과제 문서 | 내가 정한 PRD (과제 문서 구조 참고) |
| 청크 | 15개 | 133개 |
| 진행 방식 | 과제 문서에 적힌 그대로 구현 | STEP마다 결과를 검수하고 내 원칙에 맞게 고친 뒤 커밋 |
주제를 IP 기획으로 잡은 이유는 내가 애니메이션 쪽 일을 하고 있고 오리지널 IP 제작이 목표이기 때문이다. 다만 아직 만든 IP가 없어서, 내 작품 설정을 넣는 대신 공개된 자료(위키백과, 논문 초록, 기사)로 IP 기획에 필요한 이론과 사례를 찾아 주는 챗봇으로 정했다.
작업 방식
- STEP 단위로 진행 → 검수 → 커밋. 한 STEP이 끝나면 Claude가 결과를 보여 주고, 내가 보고 넘어가거나 고칠 것을 말했다. “스텝2에서도 빠진 게 없는지 검수 후에 넘어가”처럼 넘어가기 전에 다시 점검하게 한 경우가 여러 번 있었다.
- 결정은 CLAUDE.md에 계약으로 남김. 데이터·임베딩·검색·생성 계약을 STEP마다 한 절씩 추가했고, 정하지 못한 것은 “결정 필요” 목록에 남겼다. 시스템 메시지처럼 제품 성격을 정하는 문장은 Claude가 초안을 내고 내가 고치는 방식이었다.
- 두 곳에서 나눠 실행. Claude는 클라우드 작업 공간과 연결된 내 폴더에서 코드를 쓰고 검사했다. 이 환경에서는 Hugging Face와 Ollama에 접근할 수 없어서, 인덱스 만들기·검색·답변·평가는 내가 Mac 터미널에서 실행하고 출력을 붙여 넣었다. 모델이 필요 없는 검사(데이터 계약, 질문 종류 관문)는 Claude가 직접 돌렸다.
- 자료 수집은 브라우저로. 웹 검색 도구는 조직 설정상 꺼져 있었다. Claude가 내장 브라우저로 위키백과 API, KCI, 프로젝트 구텐베르크, 언론사 기사 페이지를 직접 열어 확인했다.
- 공개 저장소와 분리. 기존 학습 저장소에 넣으면 개인 정보가 노출될 수 있어서, 처음부터 별도 폴더(
~/ip-guide-rag)에서 작업했다. 커밋 이메일은 GitHub noreply 주소를 썼다.
전체 흐름
| STEP | 한 일 | 결과 |
|---|---|---|
| PRD | 목표·비목표·수용 기준·코퍼스 설계·결정 사항 작성 | 결정 사항은 최종 14개 |
| 1 | CLAUDE.md 첫 버전 (제품·비목표·환경·작업 규칙) | 커밋 |
| 2 | 데이터 계약, 청크 작성, 중복 정리, 지브리·픽사 작품 추가 | 청크 106개 |
| 3 | 임베딩 계약, embedder·validate·build-index, STEP 2 검수 보강 | 119개 × 768차원 |
| 4 | 검색 계약, search.mjs (top-k, --category, 약한 근거 표시) | 커밋 |
| 5 | 평가 질문 20개로 관찰, 기준 점수 결정 | Hit@3 16/16, 기준 0.58 |
| 6 | 생성 계약, prompt.mjs, ask.mjs --show-prompt, 질문 종류 관문 | 커밋 |
| 7 | ollama.mjs, ask.mjs 완성 (스트리밍, 📚 근거, ✓) | 커밋 |
| 8 | RAG 유무 비교 실험, 자료 보강, 검수 | 청크 133개 |
| 9 | 제출용 README, 제출 전 점검, 공개 저장소 정리 | 커밋 14개 공개 |
이슈와 처리
1. 자료 원칙: “있는 그대로”만
초기 PRD와 청크 설계에서 내 원칙과 맞지 않는 부분이 여러 번 나왔고, 그때마다 원칙을 정해 계약에 넣었다.
| 나온 문제 | 내가 정한 원칙 | 반영 |
|---|---|---|
| 자료가 없는 부분을 “가설”로 채우는 설계 | RAG는 있는 그대로만 제공하고, 없으면 없다고 답한다 | 가설 청크 없음 |
| 책 내용을 “내 노트”로 정리하는 칸 | 출처 있는 요약만 넣고 출처를 밝힌다 | 이후 이름을 “논문 초록 정리”(paper-abstract), “원문 미수록”(link-only)으로 바꿈 |
| 책에서 내용을 가져온 것처럼 쓴 청크 | 위키백과 문서가 있으면 위키백과를 출처로 한다 | 책 관련 청크를 모두 위키백과 출처로 바꿈. 책 본문 요약은 하지 않기로 함 |
| 저작권 문제가 될 수 있는 자료 | 침해 소지가 있으면 내용 대신 “제공하지 않음”과 출처만 | 데이터 계약, 거절 문구에 반영 |
| 기사 사용 | 언론사·URL·발행일이 모두 있는 기사만. 없으면 제외 | 검사 코드가 자동으로 건너뜀 |
2. 비슷한 청크가 여러 개로 쪼개짐
STEP 2에서 내가 ST-102·103·104처럼 같은 목록(애니메이션 12원칙)이 여러 청크로 나뉜 것을 발견했다. Claude가 전체를 다시 점검해 12원칙, 캠벨 17단계, 보글러 12단계, 비트 시트 15비트를 각각 한 청크로 합쳤다. 합치면서 없어진 id(ST-103, ST-104 등 7개)는 다시 쓰지 않도록 계약에 적었다. 이후 전체 청크 쌍의 글자 유사도를 재서 중복이 남지 않았는지 확인했다.
3. 내 작업 기준(SOP)을 RAG에서 뺌
처음 설계에는 docs/ip-sop.md라는 “내 작업 기준” 문서가 있었다. 캐릭터 시트·세계관 규칙·매체 확장 검토 기준인데, 내가 무엇을 넣을지 물었고 Claude가 추천한 내용을 그대로 넣은 것이었다. 진행하다가 “내 개인적인 생각과 Claude의 추측도 넣으면 안 된다”고 정해서, 이 문서와 청크 3개(IP-001~003)를 지웠다. 데이터 계약에도 “개인 생각, AI의 추측·예측·해석은 넣지 않는다”를 추가했다.
4. 기준 점수 0.58을 측정으로 정함
과제의 출발값은 0.55였다. STEP 5에서 평가 질문 20개를 돌리니 자료 안 질문의 1위 최저점은 0.640, 걸러야 할 자료 밖 질문의 최고점은 0.521이었다. 0.53~0.63 사이는 판정 결과가 같아서, 양쪽 여유가 같은 가운데값 0.58로 정했다(0.55는 자료 밖 쪽 여유가 0.029뿐). 이후 청크가 133개로 늘어난 뒤 다시 재 보니 자료 안 최저점이 0.620이 되어 여유가 0.040으로 줄었다. 판정은 같지만, 자료를 더 넣으면 다시 재야 한다고 README에 적었다.
평가 질문 14번(“세이브 더 캣 비트 시트에서 미드포인트는?”)은 내가 이해하기 어려워서 초보자도 알 수 있게 풀어 쓰게 했다. 그러자 정답 청크 점수가 0.682에서 0.728로 올랐다.
5. 점수로 막을 수 없는 질문
“내 캐릭터 아이디어가 성공할까?”는 0.647로 기준을 넘었다. 주제(캐릭터)가 자료와 같아서다. 내가 막을 방법을 물었고, Claude가 세 가지(문장 패턴, 예시 질문과의 거리 비교, 시스템 메시지에만 맡기기)를 제안했다. 나는 문장 패턴 방식을 골랐다.
scope-guard.mjs: “성공할까”, “평가해 줘”, “아이디어 줘” 같은 표현을 검색 전에 잡는다. “성공”, “평가” 같은 단어 하나는 잡지 않는다(“카카오프렌즈가 성공한 과정은?”은 통과).test-scope.mjs: 막을 질문 23개와 통과할 질문 19개로 검사한다. 이후 Mac에서 Claude Code CLI에 결과를 검토시켰더니 “성공하겠지?” 같은 말투를 놓친다는 지적이 나와서, 그 표현도 추가했다.- 정규식 목록에 없는 말투는 여전히 놓칠 수 있다(한계로 기록).
6. 기준 미달인데 LLM에 넘기는 과정이 있었나
내가 “1위 점수가 기준 아래면 LLM을 부르지 않는다”고 정한 뒤 실제로 그렇게 되어 있는지 확인을 요청했다. 처음 확인에서 Claude는 과제 문서 방식(기준 미달이면 “주의” 문구로 바꿔 LLM에 넘김)이 남아 있는 것을 찾아 고쳤다. 그런데 2·3위 중 기준 미달 자료는 계속 LLM에 넘어가고 있었다. 이건 STEP 6·7을 다시 검수하라고 했을 때 발견됐다(예: “IP가 뭐야?”의 3위 라인프렌즈 청크 0.554). 이후 기준 미달 자료는 1위가 아니어도 넘기지 않게 바꿨다.
7. “IP가 뭐야?”가 실패함
IP 기획 챗봇인데 “IP가 뭔지 알려줘”가 “관련 자료가 약함”으로 멈췄다. 내가 발견해서 문제를 제기했다. 원인은 자료에 IP를 정의한 청크가 하나도 없었던 것이다. Claude가 위키백과 「지식 재산권」, 「Intellectual property」에서 정의 청크 3개(MK-015~017)를 추가했고, 이후 0.640으로 통과했다. 표현을 바꾼 질문 두 개(21·22번)도 평가에 넣었다.
8. 예시 ID와 거절 문구
- 예시 ID: 프롬프트에 “근거 ID는
[TH-123]처럼 쓴다”고 적혀 있었는데, TH-123은 실제 청크(비트 시트)였다. 작은 모델이 예시를 베끼면 엉뚱한 자료에 ✓가 붙을 수 있어서, 실제로 없는[MK-000]으로 바꿨다. 나는 처음에 이 설명을 “가짜 자료로 답을 유도한다”는 뜻으로 이해했다가, 신청서 견본의 “홍길동” 같은 표기 견본이라는 설명을 듣고 진행했다. - 거절 문구: 자료가 없거나 범위 밖일 때 나오는 문장을 한 곳(
messages.mjs)에서 정의해 일관되게 했다. 처음 초안은 “죄송합니다.”로 시작했는데, 간결한 게 좋아서 뺐다.
9. 기사 자료 추가와 근거 확인
- 무직타이거: 처음에는 자료가 없어 “확인 불가”로 남겨 둔 사례였다. 내 요청으로 Claude가 기사 5건(뉴시스, 경제인뉴스, 문화뉴스, MTN, 뉴스핌)을 찾아 원문 문장 없이 요약했다. 회사 발표는 “대원미디어에 따르면”처럼 출처를 밝혔고, 매출은 출처 있는 수치가 없어 넣지 않았다.
- 조구만 스튜디오: 비교 질문 “어떤 채널에서 먼저 팬을 모았어?”가 거절로 끝나자, 내가 기사 링크와 ChatGPT 답변(인스타그램이 초기 채널이라는 표)을 가져왔다. Claude가 기사 원문을 열어 보니 그런 내용이 없었다. 다른 기사(연세춘추 2017)에는 페이스북 페이지로 시작했다고 적혀 있었다. 기사 4건으로 청크 8개를 만들었다.
- PDF 검토: 내가 조구만 IP 성장 분석 PDF를 첨부했다. 작성자·출처가 없고, 수치(성장률, 팬 수, IP 가치 80~300억)의 근거가 없으며 해석이 섞여 있어서 제외했다. 쓸 만한 사실은 이미 기사 청크에 있었다.
- “있는 그대로”로 다시 대조: 내가 기사 내용 그대로 정리하라고 하자, Claude가 청크를 원문과 한 문장씩 다시 대조했다. 기사의 “지난 4월 1일”을 “2017년 4월 1일”로 계산해 쓴 것, 한 사람의 발언을 “대표들은”으로 넓혀 쓴 것 등 3곳을 기사 표현대로 고쳤다.
10. 비교 실험에서 나온 것 (STEP 8)
같은 질문 10개를 RAG 없이와 RAG로 물었다. 답변 문장을 출처와 대조해 지어낸·틀린 문장을 셌다.
| 지표 | 결과 |
|---|---|
| 지어낸·틀린 문장 | RAG 없이 22개 이상 → RAG 2개 → 고친 뒤 1개 |
| RAG 없이 고유명사 오해 | IP → 인터넷 프로토콜, 카카오프렌즈 → 카카오톡, 무직타이거 → 실업 현상, 조구만 → K-POP 그룹 |
| 근거 ID 표시 | RAG 답변 8개 중 4개 |
RAG 쪽에서 나온 문제 두 가지:
- 예시 문구 베끼기: 시스템 메시지의 예시 “‘위키백과는 …라고 적는다’“를 답변에 그대로 적었다. 예시를 빼고 규칙만 남기자 사라졌다.
- 숫자 오독: 청크의 “2006년 1월 74억 달러에 … 합의”를 “2006년 1월 7일”로 읽었다. 프롬프트를 고쳐도 같았다(temperature 0). Claude가 문장 순서를 바꾸자고 제안했고(사실은 그대로, “1월 … 합의했다(인수 금액 74억 달러)”), 내가 골라 다시 실행하니 원문대로 답했다. 작은 모델을 쓸 때는 청크에서 날짜와 금액을 떼어 쓰는 것도 데이터 설계라는 것을 알게 됐다.
11. 공개 전 정리
| 문제 | 처리 |
|---|---|
| 참고한 과제 문서 원문이 저장소 기록에 들어 있었음 | 파일은 내 폴더에만 두고, 커밋 기록 전체에서 지움 |
| 위키백과 요약 청크의 라이선스 표기 없음 | README에 CC BY-SA 4.0, 논문·기사는 원문 미수록·링크라고 표기 |
| 비교 결과의 “RAG 없이” 답변이 실제 회사·캐릭터에 대한 틀린 내용 | “LLM이 지어낸 틀린 답의 기록”이라는 경고 추가 |
| README·PRD에 학습 프로그램 이름과 원본 과제 언급 | 진행 중인 과정이 드러나지 않게 문구를 바꾸고, 커밋 기록에서도 지움 |
| README 그림(mermaid) 문법 오류 | 내가 GitHub에서 빨간 오류 박스를 발견. 최신 README는 고쳐져 있었지만 예전 커밋에 남아 있어서 기록까지 고침 |
| README 중복·설명 부족 | 내가 지적한 겹치는 문장을 정리하고, RAG 워크플로우·사용 기술·파일 구조를 추가. “⚠가 무슨 뜻이냐”는 질문에 근거 표시 설명을 풀어 씀 |
커밋 기록을 다시 쓸 때마다 GitHub에는 강제 푸시가 필요했다. Claude의 작업 환경에는 GitHub 로그인 정보가 없어서 푸시는 내가 Mac에서 했다. 저장소를 지우고 다시 만드는 방법과 강제 푸시 중에서 나는 강제 푸시를 했다. 그래서 옛 커밋은 화면과 기록에는 보이지 않지만, 해시를 정확히 아는 사람은 직접 주소로 열 수 있는 상태다.
Claude의 실수로 생긴 일
있는 그대로 남겨 둔다.
- 검토 메모(“시점 확인 필요”, “확인 불가로 둔다”)를 청크 본문에 넣었다. 출처에 없는 말이라
review_note칸으로 옮겼다. - 기사의 상대 날짜를 연도로 바꾸고, 발언자를 넓혀 썼다(9번).
- 조구만 기사 수를 5건으로 잘못 셌다(실제 4건).
compare.mjs --only B가 전체 비교 결과 파일을 덮어썼다. 기록에서 되살리고, 일부 실행은 다른 파일에 저장하게 바꿨다.- README를 만든 스크립트가 그림의 중괄호를 지워 mermaid 오류가 났다(11번).
- 2·3위 기준 미달 자료가 LLM에 넘어가는 것을 처음 설계에서 놓쳤다(6번).
- 청크 검토표를 다시 만들면서, 내가 표시해 둔 체크(✅)를 덮어썼을 수 있다.
지금 이해하지 못한 것 / 남은 것
- 근거 ID 표기율(8개 중 4개)을 올리는 방법. 시스템 메시지를 줄이면 나아지는지 아직 시험하지 않았다.
- 정규식 관문이 놓치는 말투를 어떻게 줄일지. 예시 질문과의 거리 비교 방식은 시도하지 않았다.
- top-3로는 여러 청크에 걸친 질문(예: 카카오프렌즈 성장 과정)에 일부만 답한다.
--k를 늘리거나 같은 출처 청크를 묶는 방법은 시험하지 않았다. - 기준 0.58의 자료 안 쪽 여유가 0.040으로 줄었다. 자료가 늘면 다시 재야 한다.
- 스티키몬스터랩 자료와 2025 캐릭터산업백서는 아직 넣지 못했다.
- 임베딩 점수가 왜 그렇게 나오는지(예: 같은 출처 청크끼리 점수가 비슷하게 묶이는 이유)는 아직 설명하지 못한다.
정리
- 물류창고 실습을 먼저 해 본 덕분에 구조는 그대로 가져올 수 있었고, 시간은 대부분 자료의 출처와 저작권을 확인하는 일에 들었다.
- RAG가 막아 주는 것은 분명했다. 자료 없이 물으면 고유명사의 뜻부터 틀렸고, 자료가 있으면 틀린 문장이 1개로 줄었다.
- 그래도 RAG만으로 충분하지 않았다. 점수로 못 막는 질문은 관문으로, 근거 표시는 프로그램으로, 모델의 숫자 오독은 데이터 문장으로 보완했다.
- 다른 AI가 만든 요약(ChatGPT 표, PDF)은 출처를 열어 대조해 보니 틀린 부분이 있었다. 출처를 직접 확인하는 습관이 필요하다.
- 공개 전에는 저장소 기록까지 점검해야 한다. 이번에는 참고 문서 원문, 학습 과정 이름, 그림 오류가 모두 예전 커밋에 남아 있었다.