DOCS/journey/debug/260313_coldmail_ir_분석대상_오선택_디버그.md
happybell80 60a892e5ab fix: DOCS 내 0_VALUE 참조를 GitHub URL → 로컬 상대경로로 전환, 02_Governance → 20_Governance 수정 #33 #34
SSOT는 로컬 0_VALUE/. GitHub URL은 복사본 참조로 SSOT 원칙 위반.
02_Governance는 존재하지 않는 구 경로로 전부 깨진 링크.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-30 14:00:21 +09:00

12 KiB

tags
tags
debug
coldmail
ir
attachments
rb8001

콜드메일 IR 분석이 첫 번째 PDF를 잘못 선택하는 상태

작성일: 2026-03-13
상태: closed (fixed)
상위 원칙: 0_VALUE Writing Principles, 문서 작성 원칙

관련 문서

1. 이 문서의 역할

  • 이 문서는 콜드메일 IR 분석 문제의 "무엇이 잘못 연결됐는가"와 "왜 지금 상태가 문제인가"를 고정합니다.
  • 수정 방법, 작업 순서, 검증 절차 확정은 다음 plans 문서에서 다룹니다.
  • 이 문서는 플랜이 바로 받아야 할 입력 상태를 만들기 위해, 현재 상태와 목표 상태 사이의 차이를 가능한 한 좁혀 적습니다.

2. 문제 한 줄 정의

  • 현재 콜드메일 프로세스는 "IR 자료를 분석"해야 하지만, 실제로는 "업로드된 첫 번째 PDF"를 분석 대상으로 사용합니다.

3. 현재 상태

3.1 오늘 실제 실행에서 확인된 상태

  • 실행 시각: 2026-03-13 09:05 KST
  • 대상 메일: email_id=21037
  • 첨부 PDF 인식:
    • 모바일콘 재무제표 표준(2024년).pdf
    • 모바일콘 회사소개서_v.1.0_01 (2).pdf
    • [Brand IR] Introduction PPT2.26-압축됨.pdf
  • 업로드 결과:
    • 첫 번째 업로드 document_id=95bc416e-bdf1-40b3-9de2-6073c8c1b313
    • 두 번째 업로드 document_id=486bfc9e-fcc2-4229-a080-6af6fb5cc940
  • 이후 IR 분석 실행:
    • document_id=95bc416e-bdf1-40b3-9de2-6073c8c1b313로 분석 시작
  • 이 값은 로그상 모바일콘 재무제표 표준(2024년).pdf에 대응합니다.
  • document_id=486bfc9e-fcc2-4229-a080-6af6fb5cc940는 실제 저장소에서 모바일콘 회사소개서_v.1.0_01 (2).pdf로 확인됐습니다.
  • 즉 오늘 사례는 "IR 후보 파일이 없어서 실패한 상태"가 아니라, "IR 후보 파일이 이미 있었지만 다른 파일을 선택한 상태"입니다.

3.2 현재 코드가 만드는 상태

  • 첨부파일 처리 함수는 PDF 여러 개를 업로드하고 document_ids 리스트를 반환합니다.
  • 하지만 이후 단계는 document_ids[0]만 사용합니다.
  • 따라서 "어떤 PDF가 IR 자료인가"를 고르는 선택 단계가 없습니다.
  • 결과적으로 첨부 순서가 곧 분석 대상이 됩니다.

3.3 오늘 바로 수정 시 활용 가능한 상태

  • 오늘 메일의 회사소개서 PDF는 이미 skill-rag-file에 저장돼 있습니다.
  • 따라서 이 이슈를 닫기 위해 필요한 것은 메일 재수집이 아니라, 이미 저장된 첨부들 중 올바른 분석 대상을 선택하는 로직입니다.
  • 플랜은 "재조회가 필요한가"보다 "기저 저장 구조 없이도 현재 저장된 첨부들로 선택을 바로잡을 수 있는가"를 기준으로 출발할 수 있습니다.

4. 기대 상태

4.1 업무 기준 기대 상태

  • 콜드메일에 PDF가 여러 개 있더라도, IR 분석은 IR 자료 또는 회사소개서에 해당하는 문서를 선택해 실행되어야 합니다.
  • 재무제표, 부록, 별도 참고자료는 IR 분석 대상이 아니어야 합니다.

4.2 시스템 기준 기대 상태

  • 첨부 처리 결과는 단순 document_ids 리스트가 아니라, "분석 대상으로 선택된 문서"가 명시적으로 구분된 상태여야 합니다.
  • Slack List 첨부, coldmail_analyze_ir 버튼 payload, 실제 IRDeckAnalyzer.analyze() 호출이 모두 같은 선택 문서를 가리켜야 합니다.
  • 사용자가 Slack에서 "이 기업을 분석해 드릴까요?"를 눌렀을 때도 동일한 문서가 재사용되어야 합니다.
  • 이미 저장된 첨부가 있는 경우에는 재다운로드 없이 그 선택 결과를 재사용할 수 있어야 합니다.

4.3 이번 플랜의 닫힘 기준이 되어야 하는 상태

  • 오늘 같은 다중 PDF 콜드메일에서 버튼 클릭 시 회사소개서 또는 IR 자료로 분류된 PDF가 실제 분석 입력으로 들어가야 합니다.
  • 잘못 선택된 기존 첫 번째 PDF 고정 경로는 process_coldmail, Slack 첨부 생성, Slack 버튼 payload에서 제거돼야 합니다.
  • 선택된 문서가 무엇이었는지 로그로 확인 가능해야 합니다.
  • 적어도 오늘 메일 21037 사례를 다시 눌렀을 때 같은 재무제표 오분석이 재발하지 않아야 합니다.

5. 문제 지점

5.1 첫 번째 고정 선택 지점

  • rb8001/app/services/coldmail_processor.py:252
    • 첨부 PDF를 document_ids로 수집합니다.
  • rb8001/app/services/coldmail_processor.py:264
    • IR 지표 추출이 document_ids[0]으로 시작됩니다.
  • rb8001/app/services/coldmail_processor.py:518
    • IR Deck 평가도 document_ids[0]으로 시작됩니다.
  • rb8001/app/services/coldmail_processor.py:749
    • Slack 첨부 파일 다운로드도 document_ids[0]을 사용합니다.
  • rb8001/app/services/coldmail_processor.py:902
    • Slack coldmail_analyze_ir 버튼 payload도 document_ids[0]을 전달합니다.

5.2 선택 정보가 사라지는 지점

  • rb8001/app/services/naverworks_file_processor.py:217-296
    • 이 함수는 PDF를 필터링하고 병렬 업로드한 뒤 document_id 목록만 반환합니다.
  • 이 반환값에는 파일명과 document_id의 대응 정보가 이후 단계에서 유지되지 않습니다.
  • 따라서 후속 단계는 "어떤 파일이 어떤 문서 ID인가"를 기준으로 판단할 수 없습니다.

5.3 플랜이 반드시 다뤄야 할 결정 포인트

  • 선택 로직은 어느 단계에서 실행할 것인가
    • 첨부 업로드 직후
    • process_coldmail() 내부
    • Slack 버튼 payload 생성 직전
  • 선택 결과를 어떤 형태로 유지할 것인가
    • 단일 selected_document_id
    • filename + document_id + selection_reason
    • 이메일 단위 첨부 매핑 구조
  • 선택 실패를 어떻게 드러낼 것인가
    • 실패 로그만 남길지
    • 버튼을 비활성화할지
    • 확인 대기 상태로 보낼지

6. 왜 이것이 문제인가

6.1 현재 발생하는 실제 문제

  • 오늘 사례에서 IR 분석은 회사소개서가 아니라 재무제표를 대상으로 실행됐습니다.
  • 그 결과 IR Deck analysis completed 로그와 Slack 결과 링크는 "IR 자료 평가"처럼 보이지만, 실제 입력 문서는 다른 파일입니다.
  • 즉 사용자에게 노출되는 기능명과 실제 입력 데이터가 어긋납니다.

6.2 사용자 체감 문제

  • 운영자는 Slack에서 "IR 분석 완료" 메시지를 보고도 실제로는 잘못된 파일이 분석됐다는 사실을 알기 어렵습니다.
  • 점수와 등급이 낮거나 이상해도, 그것이 회사 내용이 아니라 재무제표를 읽은 결과인지 즉시 드러나지 않습니다.

6.3 시스템 신뢰 문제

  • 이 상태는 단순 정확도 저하가 아니라 입력 계약 위반입니다.
  • 기능 이름은 IR Deck 분석인데 실제 입력은 첫 번째 PDF이므로, 결과가 맞더라도 우연에 의존한 상태입니다.
  • 첨부 순서가 바뀌면 결과가 바뀌는 구조이므로 재현성과 설명 가능성이 깨집니다.

6.4 왜 지금 바로 플랜으로 넘어갈 수 있는가

  • 문제 재현 로그가 이미 확보됐습니다.
  • 잘못 사용된 document_id와 올바른 IR 후보 document_id가 모두 확인됐습니다.
  • 고정 선택 지점도 코드에서 모두 특정됐습니다.
  • 따라서 추가 리서치 없이도 플랜은 "선택 로직 도입과 선택 결과 전달 경로 정합화"를 바로 결정할 수 있습니다.

7. 확인된 사실

  • 2026-03-13 09:05:11 로그에서 message 21037의 PDF 3개 처리 시작이 확인됐습니다.
  • 2026-03-13 09:05:13 로그에서 재무제표 PDF가 먼저 document_id=95bc416e-...로 업로드됐습니다.
  • 2026-03-13 09:05:23 로그에서 회사소개서 PDF가 document_id=486bfc9e-...로 업로드됐습니다.
  • 2026-03-13 09:05:49 로그에서 실제 IR Deck 분석은 document_id=95bc416e-...로 시작됐습니다.
  • 2026-03-13 09:07:41 이후 사용자의 재분석 액션도 동일한 document_id=95bc416e-...를 재사용했습니다.
  • skill-rag-file 저장소 조회에서 document_id=486bfc9e-...의 파일명은 모바일콘 회사소개서_v.1.0_01 (2).pdf로 확인됐습니다.
  • skill-rag-file 저장소 조회에서 document_id=95bc416e-...의 파일명은 모바일콘 재무제표 표준(2024년).pdf로 확인됐습니다.

7.1 아직 필요하지 않은 추가 리서치

  • 오늘 건을 바로 수정하기 위해 메일 원문을 다시 받아올 필요는 없습니다.
  • 이미 저장된 두 개의 document_id만으로도 잘못된 선택과 올바른 후보를 구분할 수 있습니다.
  • 세 번째 PDF의 업로드 실패 원인은 별도 문제일 수 있지만, 오늘 오분석 버그를 닫는 데 필수 선행조건은 아닙니다.

8. 현재 상태가 일으키는 결과

  • 콜드메일 등록은 성공처럼 보이지만 IR 분석 입력 품질이 보장되지 않습니다.
  • Slack List의 첨부 파일과 실제 분석 파일이 "우연히 같거나 다를 수 있는 상태"가 됩니다.
  • 향후 PDF가 2개 이상 붙는 콜드메일마다 같은 문제가 반복될 수 있습니다.
  • 재무제표, 소개서, 브로셔, 보도자료가 함께 오는 메일에서 특히 오분석 가능성이 높습니다.

9. 앞으로 되어야 하는 상태

  • 콜드메일 프로세스는 "PDF 업로드"와 "IR 분석 대상 선택"을 분리된 단계로 가져야 합니다.
  • 선택된 분석 대상은 파일명 근거와 함께 유지되어야 합니다.
  • Slack 표시용 파일, IR 분석용 document_id, 재분석 버튼 payload는 모두 같은 선택 결과를 따라야 합니다.
  • 선택 근거가 없거나 후보가 복수로 충돌하면, 조용히 첫 번째 파일로 진행하지 말고 선택 실패가 드러나야 합니다.

9.1 오늘 사례 기준 목표 상태

  • 오늘 메일 21037에서 다시 분석 버튼을 눌렀을 때, 분석 입력은 95bc416e-...가 아니라 486bfc9e-... 또는 정책상 더 높은 우선순위를 받은 IR 후보여야 합니다.
  • 오늘 사례 기준으로 Slack 첨부도 같은 선택 문서를 따라야 합니다.
  • 오늘 사례 기준으로 로그에는 "선택된 IR 문서"가 파일명 또는 document_id 수준으로 남아야 합니다.

10. 미확정 항목

  • 오늘 메일의 세 번째 PDF [Brand IR] Introduction PPT2.26-압축됨.pdf가 업로드 실패한 이유는 이 문서 범위에서 확정하지 않았습니다.
  • 현재 업무 기준에서 "회사소개서"와 "Brand IR 문서" 중 어떤 것을 우선 IR 자료로 볼지 아직 정책으로 고정하지 않았습니다.
  • 첨부 파일명만으로 충분한지, 본문/제목/페이지 텍스트까지 함께 봐야 하는지는 아직 결정하지 않았습니다.

10.1 이번 플랜 범위 밖으로 둘 수 있는 항목

  • 전체 이메일 저장 구조 전환
  • 첨부 업로드 실패 원인 일반화
  • 다중 첨부 문서 선택의 장기 정책 고도화
  • 회사소개서/브랜드 IR/재무제표 외 다른 문서군까지 포괄하는 범용 분류 체계

11. 디버그 결론

  • 이 이슈의 본질은 분석 모델 품질 문제가 아니라, IR 분석 입력 문서를 잘못 고르는 선택 로직 부재입니다.
  • 지금 상태는 "IR 분석"이라는 이름과 실제 입력 대상이 어긋난 버그 상태입니다.
  • 오늘 사례 기준으로는 이미 저장된 회사소개서 PDF가 존재하므로, 플랜은 메일 재조회가 아니라 선택 로직과 전달 경로 정합화에 집중하면 됩니다.

12. 종료