미결 항목

예상 리스크

2026-08-28 해소 — 트리거 허용 창을 1,500ms 로 확정했다(_project/decisions/202). 새 결정이 아니라 2026-08-25 팀 확정의 누락된 반영이다. 코드·사이트는 그때부터 1,500ms 였고 _project/plan.md 만 800ms 로 남아 있었는데, 그 사실이 어디에도 적혀 있지 않아 3일간 같은 질문이 네 번 올라왔다. 팀 컨펌을 로그에만 적고 결정 기록으로 올리지 않은 것이 원인이다.

정하지 못한 것 (2주차로 넘어감)

골든셋 50건 — 비율은 정해졌고, 측정 방법 두 가지가 남았다

⚠ 2026-08-28 무효. 도메인이 다산 하나가 되면서(decisions/201) 아래 배분 전체가 의미를 잃었다. 골든셋은 50 → 13건이 됐고, F-2 케이스는 0건이다(다산에 종결 유형이 없다). P1~P7 커버리지도 다시 확인해야 한다 — 아래에서 큰 소득이라 적은 그 커버리지가 삭제된 37건에 실려 있었을 수 있다. 재확장 계획은 부록 C 9번 항목.

배분은 확정됐다(F-2 가중: 금융보험 18 · 쇼핑 16 · 다산콜센터 9 · 질병관리본부 7). 근거는 w2-golden-set-50에 기록돼 있다. P1~P7 개인정보 패턴이 전부 커버된 것이 큰 소득이다 — 1주차 10건에는 P3·P5·P6·P7 이 아예 없어 C-5 “누락 0건” 절대 규칙을 4개 패턴에 대해 측정할 방법 자체가 없었다.

남은 것은 이 표본으로 지표를 어떻게 읽을 것인가다. 둘 다 숫자로 판단할 수 있다.

1. B-0 도메인 분류 정확도(≥0.95)의 기저율이 올라간다. 도메인이 18/16/9/7 로 기울어 다수 도메인으로 찍기만 해도 36% 가 나온다(균등이면 25%). 6.1절이 이 지표를 “도메인 내 검색 지표보다 엄격”하게 잡은 취지가 흐려진다 → 균형 부분집합으로 따로 재거나, 다수 클래스 기저율을 함께 보고하면 해소된다
2. B(검색) 14건은 2주차 베이스라인용으로 얇다. 도메인당 2~4건이라 Recall@5·MRR 의 분산이 크다. 잠정 베이스라인을 “여러 번 실행한 값 중 최저치”로 고정할 때(절대 원칙 4) 표본이 작으면 그 최저치가 실력이 아니라 운을 반영할 수 있다

배분을 다시 잡자는 게 아니다. 측정 방법에 반영할지만 정하면 되고, 3주차 150건 확장 때 비율을 다시 볼 기회가 있다.

이번 주 할 일 (1주차)

• AI Hub 회원가입 + 휴대폰 인증 + 데이터 신청 — 5개 데이터셋(data/raw/) 다운로드·정리 완료
• Google Cloud STT 키 발급 + 이중 캡 설정 완료 (2026-08-25) — 프로젝트 callguard-506606, 서비스 계정 callguard-stt@. ① GCP 콘솔 쿼터 하드 리밋: Audio seconds per day 1,728,000 → 600, Concurrent StreamingRecognize (global endpoint) → 5 ② 예산 callguard(월 ₩30,000, 50/90/100% 알림) ③ .env의 STT_MAX_SECONDS_PER_DAY=600/_MONTH=3600. 지출 한도(spending limit) 기능은 Cloud Run·Vertex AI 등만 지원해 STT 에는 걸 수 없다
• 5.6절 V1 확인 — AI Hub 데이터 전부 모노. diarization 필수, 데모는 물리 2채널 우회 필요
• 5.6절 V2 확인 — GPU: Apple M5 MacBook Air, 24GB 통합메모리, CUDA 없음(MPS 가속)
• 5.6절 V3·V4 확인 — Google STT 키 발급 완료, 실측 오디오로 검증. V3: 숫자 정규화가 케이스마다 다름(완전 정규화/부분 정규화/오인식 혼재), 자릿수 낭독형(인증코드류)은 저품질 통화 음성에서 오인식 위험 큼. V4: 첫 interim 962ms, 최종 결과는 발화 종료 후 +346ms — 자세한 수치는 5절 참고
• 인터페이스 스키마 3종 확정 (전사·카드·종결) — 7.3절 v2로 확정. 정성윤이 DB·골든셋과 대조해 불일치 4건(verdict 값, source ID 기준, evidence 유형별 부분집합, segment_id 누락)을 잡아내 반영. 결정 기록: _project/decisions/002(v1)·003(v2)
• 지식베이스 문서 초안 작성 완료 (knowledge-base/ — 요금제약관·응대매뉴얼·내부처리규정), 팀 리뷰 대기
• 골든셋 10개 초안 작성 완료 (golden-set/v1-10.json), 팀 리뷰 대기
• 평가 하네스 골격 설계 완료(류준) — services/core/eval/, 단위테스트 24개 통과. CI 연결(정성윤)은 남음
• 트리거 허용 창 확정 — 보완지시서 1번 안 A 채택, 0~800ms → 0~1,500ms로 확정(2026-08-25 팀 컨펌). 안 B(침묵 임계값 실측 후 역산)는 보유 데이터로 발화 간 침묵 길이를 잴 수 없어 기각. 3주차 v1은 자체 침묵 타이머 대신 Google STT is_final 기반으로 설계(정성윤 제안) — 1,500ms 산식도 “STT 엔드포인팅 +346ms 실측 + 판정 여유”로 갱신. 4.1절·6.1절·trigger.py 반영 완료, harness.py가 report["trigger"]["latency_ms"]로 p50/p95/p99 자동 계산 → 티켓
• 데모 도메인 확정 — 가상 통신사 “한별텔레콤” 대신 실제 확보 데이터 4종(금융보험·다산콜센터·쇼핑·질병관리본부) 전부 지원으로 확정(2026-08-26). _project/decisions/004-데모-도메인-4종-확정.md
• 골든셋 재작성 — 4개 도메인 기준으로 10건 재작성 완료(2026-08-26). 금융보험 4·다산콜센터 2·쇼핑 3·질병관리본부 1, F-2는 금융보험·쇼핑에만. pytest services/core 27개 통과. w1-golden-set-10.md. 팀 리뷰(지식베이스 포함) 완료 — 2026-08-26 팀 회의
• 검수 방식 — 규칙을 없앴다 (2026-08-27) — 완료 시 팀 리뷰·승인을 요구하던 규칙(§7.4, 4주차 말 체크포인트)과 계약 변경 시 합의를 요구하던 규칙(ai·server/CLAUDE.md)을 전부 걷어냈다. 네 사람이 같은 공간에서 일하므로 필요하면 그 자리에서 말로 맞춘다 — 문서로 절차를 만들 이유가 없었다. _project/decisions/023(008 철회)
• DB 스키마·ERD 도메인 재검토 — plan 테이블 제거, subscriber→customer 정리, call.domain 컬럼 신설, closure.closure_type/evidence를 금융보험(상품해지·보상)·쇼핑(반품·교환) 기준으로 교체(2026-08-26, 17→16개 테이블). _project/decisions/006-db-스키마-도메인-정리.md, 16절 ERD
• 도메인 라우팅 방식 확정 — 자동 분류로 결정(수동 선택 안 함, 2026-08-26). 평가 하네스에 B-0 배선 완료(정확도 목표 ≥0.95), 실제 분류기 구현은 후속. _project/decisions/007-도메인-라우팅-자동분류-확정.md, 3.2절
• 팀 개편 확정 — 3인(정성윤·류준·장민석) → 4인(정성윤·류준·장민석·조서희). 플러터 앱 중단, 장민석 백엔드·AI 합류, 조서희 프론트엔드 신규 합류(2026-08-26). _project/decisions/005-팀-개편-4인-체제.md
• 백엔드·AI(류준·장민석) 내부 세부 분담 — 처음에는 기능별로 나누지 않고 둘이 함께 하기로 했으나(2026-08-26), 같은 날 fastapi/가 server/·ai/ 두 서브도메인으로 갈리면서 나눌 경계가 실제로 생겨 디렉터리 경계를 그대로 담당 경계로 삼았다: 류준 ai/(모델 학습·청킹·BM25·리랭크·임베딩·LangGraph·평가 하네스), 장민석 server/(파이프라인·클린 아키텍처·계약·요청 경로). 경계에 걸친 작업은 여전히 함께 정한다. _project/decisions/012-백엔드-ai-server-담당-분리.md, 7.2절
• AI 모델 구성 전면 확정 — Opus 교차검증 반영, 검증 가능한 주장(모델 존재·설정 파일·라이선스·추론 속도) 전부 확인 후 확정(2026-08-26). 임베딩 ko-sroberta-multitask→KoE5(128토큰 truncation 실측 확인, 1024차원), 생성 exaone3.5:2.4b→EXAONE-4.0-1.2B(250토큰 2.0~2.1초로 더 빠름, think:false+/api/chat 필수), 분류기·NER은 유지하고 klue/roberta-base를 분류기 대조군으로 추가. _project/decisions/010-AI-모델-구성-확정.md, 3.1절
• 분류기·NER 실제 비교 측정 (신규, 후속) — klue/roberta-base 대조군 vs KcELECTRA-base는 5주차 오류 내성 실험에서, 생성 대조군 kanana-1.5-2.1b-instruct(6주차, 아직 로컬에 못 받음 — Ollama 공식 라이브러리·hf.co/kakaocorp/... GGUF 둘 다 안 됨, 재시도 필요) vs EXAONE-4.0-1.2B는 6주차 환각 건수 비교에서 실측한다. NER 의 P6(인명)·P7(상세주소)은 2026-08-27 server/ 에 규칙 기반 폴백을 넣어 골든셋 누락 0건을 달성했다(w3-masking-c5 done). 다만 규칙은 문맥 있는 이름·어절 2개 이상인 주소만 잡는다 — 일반 NER 은 여전히 ai/ 몫이다
• 시멘틱 청킹 vs 「1 조항 = 1 청크」 — 4주차 비교 측정 (신규, 2026-08-27) — LG CNS AICC 페이지를 열어 보니 상용은 시멘틱 청킹을 쓴다고 밝히고 있다(9.3.1). 우리는 1 조항 = 1 청크 고정이고 근거도 있다 — 청크가 조항 경계를 넘나들면 doc_id 정확 일치 채점이 깨진다(하나의 청크에 doc_id 를 하나만 달 수 있다). 다만 재본 적이 없다. 4주차 리랭킹·하이브리드를 붙일 때 standard 애널라이저 비교와 함께 시멘틱 청킹 인덱스를 따로 적재해 Recall@5·MRR 을 대조하면 된다(재적재가 1초라 비용이 거의 없다). 채점을 유지하려면 청크마다 «대표 조항 ID» 를 달아야 하므로 평가 방식도 같이 정해야 한다 — 류준 님 영역
• 배포를 한 컨테이너로 할지 둘로 나눌지 — 정성윤 님 결정 (신규, 2026-08-27) — 검색 스포크를 같은 프로세스에서 꽂기로 했다(_project/decisions/024). ai/ 에 HTTP 표면도 웹 프레임워크 의존성도 없어(라이브러리이지 서비스가 아니다) HTTP 호출은 없는 서비스를 새로 만드는 일이 되고, 4.1절 p95 ≤1,000ms 예산에 네트워크 홉을 더할 이유도 없었다. 그런데 CLAUDE.md 는 server.solidbob.cloud·ai.solidbob.cloud 두 도메인을 적어 뒀다 — 같은 프로세스면 한 컨테이너에 둘이 함께 실린다. 지금은 ai/ 에 서비스 실체가 없어 모순이 드러나지 않지만 배포를 짤 때 정해야 한다: ① 도메인 서술을 한 개로 고칠지 ② 나중에 ai/ 를 서비스로 올리고 HTTP 어댑터로 전환할지(되돌리는 법은 decisions/024 에 있다). 참고로 server CI 는 ai/ 의존성 없이도 그대로 돈다 — 못 꽂으면 조용히 501 로 남는다
• 프론트 ↔ 백엔드 계약이 어긋나 있다 — 연동 전에 맞춰야 한다 (신규, 2026-08-27) — frontend 를 일부러 머지하지 않고 백엔드끼리만 진행 중인데, 파일이 안 겹쳐도 계약은 어긋난다. apps/dashboard/src/types/contract.ts 를 지금 값과 대조해 2건이 나왔다. ① ClosureType 의 "사고·보상" → "보상" — DB CHECK·골든셋 16건·F-2 게이트가 전부 "보상" 이다(3:1로 프론트만 다르다). 지금 값으로 종결 요청을 보내면 게이트가 422 로 거부한다 — 비슷한 이름을 눈감아 주지 않게 만든 규칙에 그대로 걸린다. 이건 오탈자에 가까워 프론트가 고치면 끝난다. ② segment_id 를 string 으로 쓸지 number 로 쓸지 — 아직 아무도 정하지 않았다. 7.3절 예시가 "seg_0031" 이라 프론트가 문자열로 구현했는데, transcript_segment.segment_id 는 BIGINT 이고 서버 요청 스키마도 int 다. 코드와 DB 는 서로 맞고 계약 예시만 어긋난 상태이며, 2026-08-27 w2-mysql-persistence 에서 이미 발견해 «예시를 고칠지 타입을 바꿀지 팀 결정»으로 남겨뒀던 건이다. 그 사이 프론트가 문자열 위에 컴포넌트를 쌓았다. 정할 것: 7.3절 예시를 31 로 고칠지, 아니면 DB·서버를 문자열로 바꿀지(후자는 BIGINT PK·FK 를 건드려야 해서 비용이 크다). ⚠ 진짜 위험은 「머지를 미루는 것」이 아니라 「계약 변경이 코드 머지와 별개로 전파되지 않는 것」이다 — 지금처럼 가면 연동 시점에 한꺼번에 터지고, 그때는 프론트가 이미 그 타입 위에 쌓여 있다
• 백엔드 생산성을 막는 규칙 4건 완화 — 팀 논의 필요 (신규, 2026-08-27) — 지금 백엔드를 굴리는 류준·장민석 둘이 규칙에서 계속 멈춘다. 규칙 대부분이 08-25~26에 코드가 거의 없던 시점에 세워졌고, 8-27 하루에 server/ 가 테스트 311개·엔드포인트 14개가 되며 전제가 달라졌다. 제안 4건: ① 담당 디렉터리 경계에서 「소유(알고리즘·판정)」와 「배선(포트 주입·import·문서 참조)」을 갈라 배선은 상호 가능하게 — 오늘 경계에서 멈춘 것이 6건이고 그중 하나가 하네스에 C-5·F-2 를 꽂는 3줄이었다(그 3줄이 프로젝트 첫 실측값이다). .importlinter 계약 7종이 이미 구조 위반을 잡으므로 안전장치는 있다 ② F·G·H·I 동결에 해제 조건을 붙인다 — 지금은 조건이 「코어 기준선 통과」인데 기준선이 0개라 사실상 영구 동결이다 ③ 미결 항목 전용 X- 접두어 — 기획서에 없는 아이디어는 붙일 ID 가 없어 제안 단계에서 막힌다 ④ 결정 기록 번호를 담당자별 번호대로 — 하루에 두 번 겹쳐 참조 16곳을 고쳤다. ⚠ 절대 원칙 1·2·8·9·10 과 진행 기록·티켓 규칙은 건드리지 않는다 — 그건 프로젝트가 평가받는 근거다. 초안: _project/decisions/022-백엔드-생산성-규칙-완화.md. ① 의 핵심 마찰은 류준이 decisions/023 으로 해소했다(협의를 절차로 요구하던 규칙 전부 삭제). ✅ ②③④ 도 2026-08-27 확정·반영됐다 — 아래 「확장을 막던 규칙 4건 완화」 항목이 결과다. 그 과정에서 ②(동결 해제 조건)의 진단이 틀렸음이 드러났다: 해제 조건은 원래부터 기획서에 있었고(「6주차 종료 시점에」) CLAUDE.md 에서만 빠져 있었다. 새 조건을 만들지 않고 원문을 복원했다
• 평가 하네스에 C-5·F-2 를 꽂으면 이 프로젝트의 첫 실측값이 나온다 — 류준 님 확인 요청 (신규, 2026-08-27) — 하네스(ai/apps/evaluation/harness.py)는 Ports(...) 에 구현을 꽂아야 채점하는데 main() 이 Ports() 빈 채로 부르고 있어 전부 「측정 불가 — 모듈 미구현」으로 보고된다. 그런데 C-5 마스킹·F-2 게이트는 2026-08-27 실제로 구현됐다(w3-masking-c5·w7-closure-gate-spoke done). 장민석이 파일을 고치지 않고 시험 삼아 꽂아 돌린 결과: masking {miss_count: 0, absolute_rule_passed: true, n: 12} · closure_gate {accuracy: 1.0, absolute_rule_passed: true, n: 16} (v1-50 기준. v1-10 은 각 n=3). 절대 원칙 2·5상 지금 이 프로젝트에는 문서에 쓸 수치가 하나도 없는데, 이 둘은 당장 낼 수 있다. 고칠 곳은 harness.py main() 한 곳이고(Ports() → Ports(masking=..., closure_gate=...) + import 2줄), 의존 방향(ai → server)은 열려 있어 계약 위반이 아니다. 정할 것: ① main() 기본 골든셋을 v1-10 → v1-50 으로 올릴지 ② CI 에서 하네스를 돌려 E-4 기준선 미달 시 실패를 언제부터 켤지 — 지금 켜면 미구현 4종 때문에 계속 빨간불이다. ai/apps/evaluation/ 은 류준 님 영역이라 손대지 않았다
• P6·P7 NER 구현 — ai/ 몫 (신규, 2026-08-27) — server/apps/masking/ 에 규칙 기반 폴백을 넣어 골든셋 C-5 누락 3건 → 0건이 됐지만, 이건 2.4절이 정한 NER 이 아니다. server/.importlinter 계약 2 가 server/ 안의 transformers import 를 금지하므로 모델은 ai/ 에 있어야 한다. 규칙이 못 잡는 범위: P6 는 문맥 없는 이름("그 김민준 씨가"), P7 은 단독 어절 주소("테헤란로요"). 어댑터가 PARTIAL_PATTERNS = ("P6","P7") 로 이 사실을 드러내고, 한계를 고정하는 테스트도 있다(NER 이 붙으면 그 테스트가 뒤집히고 지워진다). 정할 것: ① ai/ 의 NER 을 어떤 포트로 부를지 ② 규칙과 NER 을 합칠지(누락 0건 우선이면 합집합) 아니면 대체할지. 류준 님과 경계를 맞춰야 한다
• ES 인덱스 — 단일 인덱스 + domain 필터로 확정 (2026-08-27) — 4개 도메인을 별도 인덱스로 만들지, 하나에 domain 필드로 두고 필터할지가 적재 자체를 막고 있었다. single(callguard-kb-single)로 간다. 근거: 조항이 102개뿐이라 나누면 인덱스당 20~34건이 되어 BM25 IDF 가 불안정해지고(health 21·dasan 20), 얻는 이점(도메인별 독립 재적재)은 전체 재적재가 1초도 안 걸리는 지금 있으나 마나다. ⚠ 이건 판단이지 실측이 아니다 — 점수를 내려면 검색 구현체가 있어야 하는데 아직 없다. _project/decisions/017-es-인덱스-단일-인덱스와-도메인-필터.md, w2-kb-index
• 도메인이 늘면 도메인별 인덱스로 전환 (조건부, 2026-08-27) — 위 결정은 지금 규모에 대한 것이다. 볼륨 증가만으로는 바꾸지 않는다(청크가 1000배 늘어도 40MB 라 샤드 하나에 들어간다). 아래 중 하나가 참이 되면 --layout per-domain 으로 전환한다: ① 도메인이 4개를 넘어 크게 늘어난다(특히 고객사별 KB — 필터 선택도가 25%→1~2%로 떨어지면 filtered HNSW 의 recall 이 무너진다) ② 단일 인덱스가 샤드 2개 이상을 필요로 한다(BM25 점수는 인덱스가 아니라 샤드 단위라, 단일 인덱스의 “전역 IDF” 장점이 그때 사라진다) ③ 전체 재색인이 “커피 한 잔” 넘게 걸린다 ④ 도메인별로 보존기간·권한이 갈린다. 전환은 alias 를 앞에 세우는 방식으로 — 쓰기는 도메인별 인덱스, 읽기는 callguard-kb alias. 소비 측 코드는 안 바뀐다. 코드는 이미 양쪽을 지원한다
• single vs per-domain 사후 실측 (2026-08-27) — 2026-08-28 실측하지 않고 닫는다. 도메인이 하나가 되어 per-domain 이 single 과 같은 것이 됐다. 비교할 대상 자체가 사라졌으므로 실측 없이 종료한다(측정 결과가 나온 것이 아니다). 원문: — w2-naive-rag로 RetrievalPort 구현이 생기면 골든셋 v1-50 의 B 케이스 14건으로 양쪽 Recall@5·MRR 을 재서 위 판단이 맞았는지 확인한다. 진행을 막지는 않는다 — 이미 single 로 간다. 반대 방향 요인도 있다: 도메인별 IDF 가 그 도메인 안에서는 더 잘 변별할 수 있다(“환불”이 쇼핑에서 흔하다는 사실은 쇼핑 검색에 반영되는 게 맞다)
• Elasticsearch 로컬 구성을 infra/ 하나로 합쳤다 (2026-08-27) — 병합으로 루트 docker-compose.yml(ES 9.5.1, 기동 시 nori 설치)과 infra/docker-compose.yml(PostgreSQL + ES 8.15.3, 이미지에 nori 굽기)이 동시에 존재했다. 둘 다 9200 을 잡아 같이 뜨지 않는다. infra/ 하나로 합치고 ES 를 9.5.1 로 올렸다 — 버전은 논쟁이 아니라 실측이 정했다: ai/requirements.txt 가 고정한 9.x 클라이언트는 8.x 서버에 접속 자체를 거부한다(media_type_header_exception ... found 9). nori 는 이미지에 굽는 쪽을 골랐다(오프라인·기동 속도). cd infra && docker compose up -d 하나로 DB+ES 가 함께 뜬다. 실적재 102건·ai 통합 테스트 5건 skip→통과로 확인. _project/decisions/020-로컬-도커-환경-infra-단일화.md
• RRF 를 어디서 계산할지 — ai/ 코드로 확정 (2026-08-27) — ES 의 retriever.rrf 는 8.15.3·9.5.1 양쪽 다 basic 라이선스에서 403 non-compliant 다(장민석 실측). 버전을 올려도 안 풀린다. 30일 trial 은 만료가 2026-09-26 이라 프로젝트 종료(10-27)를 못 넘기고, OpenSearch 로 교체하는 건 2주차에 엔진을 바꾸는 비용이 크다. → 순위 병합을 ai/ 검색 코드에서 계산한다(_project/decisions/021). RRF 는 원래 1/(k+rank) 합이 전부라 몇 줄이고, 우리 코드 안에 있으면 평가 하네스가 k 를 바꿔 가며 채점할 수 있다 — 절대 원칙 1·9 와 같은 방향이다. 막힌 것은 순위 병합 하나뿐이고 BM25·kNN·nori·dense_vector·collapse 는 basic 에서 전부 된다. 4주차 하이브리드에 적용한다. 랭체인 EnsembleRetriever 도 검토했다 — 그게 하는 일이 정확히 weighted RRF 라 라이선스를 피해 가는 길이 아니고(같은 알고리즘·같은 클라이언트 위치), ai/CLAUDE.md 4번(“랭킹 산식은 순수 파이썬”)과 계약 3(domain·evaluation 에서 langchain 금지)에 걸린다. 게다가 BaseRetriever↔RetrievalPort 글루가 아끼는 10줄보다 길고, 같은 인덱스에 두 질의를 던지는 우리 구조에서는 _msearch 왕복 1회가 2회가 된다. 랭체인은 orchestration(랭그래프)에 쓰고 랭킹 산식에는 쓰지 않는다
• 브랜치 구조 통합 — 하지 않기로 결정 (2026-08-26) — 네 브랜치(PM/backend/ai/frontend) 체제를 그대로 유지한다. 통합 검토 과정에서 확인된 사실은 남겨둔다: ① 네 브랜치가 실제로는 같은 파일 영역(jekyll/_backlogs, fastapi/apps/hub/app/*)을 만지고 있어 격리 효과가 크지 않다 ② ai·backend 는 둘 다 백엔드·AI 작업인데 7.1절은 그 일을 “둘이 함께” 하라고 정해 브랜치가 둘인 것 자체는 모순이다 ③ main 에 브랜치 보호 설정이 없다(2026-08-26 확인) — pages.yml 이 main push 시 즉시 공개 배포이므로 PR·CI 가 현재 유일한 게이트다. 통합을 안 하기로 한 이상 이 게이트를 계속 지키는 것이 더 중요해졌다. 충돌 자체는 브랜치 문제가 아니라 분담·티켓 선점의 문제이므로, 그쪽(착수 시 status: in-progress 로 선점 + 자주 푸시)으로 대응한다
• 수동 검색·통화 후 처리 메시지를 7.3절 계약에 올릴지 (신규, 2026-08-27) — B-6으로 “관련 문서 없음”이 떴을 때 상담원이 직접 찾는 경로를 화면에 넣었는데, 계약 3종(전사·카드·종결)에는 이 요청·응답이 없다. 프론트가 임시로 ManualSearchRequest { call_id, query } + 응답은 카드 이벤트 재사용(source_type: "auto" | "manual" 추가)으로 정의했고, mock 에서만 동작한다. 실서버 경로는 “아직 연결되지 않았습니다”로 응답한다 — 임의 형식을 보내면 서버가 모르는 메시지로 버려 화면이 결과를 기다리게 되기 때문이다. 결정할 것 두 가지: ① 자동 추천과 같은 WebSocket 채널로 보낼지, REST 로 뺄지(요청·응답이 1:1 이라 REST 가 자연스럽다) ② source_type 을 계약에 정식으로 넣을지, 프론트 표시용으로만 둘지. D절 통화 후 처리(CallWrapUp { summary, category, follow_ups })도 같은 처지라 함께 정한다 — 요청·응답이 1:1 이고 통화가 끝난 뒤에 오가므로 REST 가 더 자연스럽다. 단 D-4(지식베이스 공백)는 서버가 줄 수 없는 값이라 계약 대상이 아니다
• 브랜치 이름을 담당 디렉터리에 맞췄다 (2026-08-26) — backend→ai(류준) · ai→server(장민석). 브랜치 수는 넷 그대로다(위 항목의 “합치지 않는다”는 유지). _project/decisions/012가 이 개명을 “룰셋의 필수 통과 검사 이름까지 바꿔야 한다”며 미뤄뒀는데 그 전제가 틀렸다 — 검사 이름은 test.yml의 job 이름(server·ai·jekyll)이지 브랜치 이름이 아니라서, 실제로 고친 곳은 push 트리거 한 줄뿐이고 admin 권한도 필요 없었다. 삭제 전 두 옛 브랜치가 main의 조상임을 확인해 미머지 0건. ⚠ 오늘 이전 기록의 ai 브랜치는 장민석을 가리킨다 — 이름이 사람을 갈아탔다. _project/decisions/015-브랜치명을-담당-디렉터리에-맞춘다.md, w2-branch-rename
• generation·compliance 를 ai/ 에 두는 것 — 장민석 확인 필요 (신규, 2026-08-26) — .claude/rules/rfp-harness.md §3.1은 B-4~B-6(generation)·C-1~C-4(compliance)의 코드 위치를 server/apps/로 적어 뒀지만, 이건 fastapi/ 분리 이전 표기다. 두 모듈 다 모델(EXAONE·분류기)을 로드하는데 server/.importlinter 계약 2가 server/ 안의 torch·transformers·langchain·langgraph import를 금지하므로 거기서는 만들 수 없다. 문서를 ai/apps/로 정정하고 architecture §1에 근거를 남겼으나, 담당이 류준으로 바뀌는 변경이라 장민석 님 확인을 받아야 한다. 이견이 있으면 대안은 “server/에 얇은 배선만 두고 모델 호출은 ai/ 포트 구현으로 빼는” 쪽이다
• Neo4j(그래프 DB) 도입 여부 — 보류 (2026-08-27) — 저장소 전체를 검색해도 Neo4j·그래프 DB·GraphRAG 언급이 0건이다. 기획서·3.1절 투입자원 어디에도 없어 새 도구 도입 결정이 필요한 사안이다(1.1절 “투입자원 목록이 이미 답을 가리킨다” — 목록 밖 도구는 Ollama 처럼 예외 절차를 밟는다). 현재 지식베이스는 조항 102개짜리 평면 구조이고 검색은 BM25+임베딩이라 조항 간 그래프 관계를 쓰는 설계가 없다. 쓰려면 용도부터 정해야 한다 — 용도 없이 도입하면 투입자원 목록만 늘어난다
• 랭그래프·랭체인 실제 도입 (ai/ — 류준 담당) — 영역 규칙이 “한다” 목록에 올려두고 orchestration 디렉터리도 예정 표에 있으나, 의존성·코드가 둘 다 없다(2026-08-27 확인). server/.importlinter 에는 금지 대상으로만 등록돼 있다 — server/ 가 import 하면 계약 위반이라는 뜻이지 설치돼 있다는 뜻이 아니다. 파이프라인 배선은 이미 포트로 끝나 있어 오케스트레이션이 없어도 동작하므로, 실제로 필요한 시점(생성·리랭킹 체인)에 도입 여부를 정한다
• RetrievalPort 에 도메인을 넘길 방법이 없다 (신규, 2026-08-27 실측) — retrieve(utterance, top_k) 시그니처에 도메인이 없어서 평가 하네스가 B-0 라우팅 결과를 넘겨줄 수 없다. 지금은 4개 도메인 전체를 검색한다. 그 대가가 실측으로 보인다: 못 맞힌 2건(GS-001·GS-019)의 상위에 다른 도메인 문서가 올라와 있다(금융 질의에 DASAN-MANUAL-4.1·HLT-MANUAL-1.4). 어댑터 생성자에 domain= 을 임시로 열어 뒀고 필터가 듣는 것은 확인했지만, 포트 시그니처 변경은 server/ 소관이라 장민석 님과 합의가 필요하다. w2-naive-rag
• nori 개선 폭을 잴 수 없게 됐다 (신규, 2026-08-27) — 8주 로드맵은 4주차에 “nori 인덱스”를 넣어 개선 폭을 보여주기로 했는데, w2-kb-index 색인 매핑이 이미 nori 라 베이스라인에 포함돼 버렸다(2주차 티켓 문구는 “nori 없이 BM25 만”이었다). 재려면 standard 애널라이저 인덱스를 따로 적재해 같은 골든셋으로 비교해야 한다 — 재적재가 1초라 언제든 가능하다. 4주차 비교 항목을 dense_vector·RRF·청킹전략 3종으로 좁힐지, nori 대조군을 만들지 정한다
• TranscriptEvent 에 이벤트 도착 시각이 없다 — 트리거 지연을 잴 수 없다 (신규, 2026-08-27) — TriggerPort.decide(event) 가 받는 TranscriptEvent 에는 utterance_end_ms(발화가 끝난 시각)만 있고 이벤트가 언제 도착했는지가 없다. 그래서 발동 시각을 “발화 종료 + STT 최종 결과 지연(V4 실측 346ms)”으로 모형화했고, 그대로 채점하면 지연 분포가 상수 하나로 수렴한다(p50 = p95 = 346, 적절 발동률 1.0) — 숫자는 나오지만 측정이 아니다. 그래서 서버 경로에는 꽂고(발동 여부는 진짜 판정이라 파이프라인이 흘러야 한다) 평가 하네스에는 일부러 꽂지 않았다(절대 원칙 10). 고치려면 게이트웨이가 도착 시각을 실어 보내고 포트가 받아야 하는데 계약 변경이라 server/(장민석)·게이트웨이(정성윤) 합의가 필요하다. 그때까지의 통로로 IsFinalTrigger(now_ms=...) 를 열어 뒀다. w3-trigger-v1
• nori 복합명사 분해 — 사용자 사전으로 해결 (2026-08-27) — 장민석 님이 찾아준 건. _analyze 로 확인해 보니 decompound_mode 문제가 아니라 사전 미등재였다: mixed 는 멀쩡하다(수수료 → 수수료·수수·료 로 원형+조각을 제대로 낸다). mecab-ko-dic 에 없는 말이라 미등록어 분해로 떨어지면서 해지 가 하+아+지(동사 활용)로 오분석된 것이다. 조항 제목의 4글자+ 명사 24개를 전수 검사해 3개를 찾았다 — 중도해지수수료·생활하수도·에스컬레이션. user_dictionary_rules 로 등록하니 중도해지수수료 · 중도 · 해지 · 수수료 로 정상화됐다. ⚠ 재측정 결과 Recall@5·MRR 은 변하지 않았다(0.857 / 0.702 그대로) — 골든셋 14건 중 이 세 용어를 쓰는 질의가 없다. 토큰화는 고쳤지만 개선 효과는 이 표본에서 미측정이다. 정밀도·IDF 오염을 줄이는 위생 조치로 남긴다. 내 초안 주석이 “mixed 가 원형을 남긴다”고 일반화한 것도 틀려서 함께 고쳤다
• hub 포트 계약 간극 3건 — 장민석 님 확인 대상 (2026-08-27 정리) — ai/ 스포크를 붙이면서 계약으로는 표현할 수 없는 것이 셋 나왔다. 셋 다 server/ 소관이라 손대지 않았고, 지금은 각각 우회로만 열어 뒀다. ① RetrievalPort.retrieve(utterance, top_k) 에 도메인이 없다 — 하네스가 B-0 결과를 넘겨줄 수 없어 4개 도메인 전체를 검색한다. 못 맞힌 2건의 상위에 다른 도메인 문서가 올라온 것이 그 대가다(어댑터 생성자에 domain= 임시 통로) ② TranscriptEvent 에 이벤트 도착 시각이 없다 — 트리거 발동 시각을 상수로 모형화할 수밖에 없어 하네스에 꽂지 못한다(IsFinalTrigger(now_ms=...) 통로) ③ DomainClassification.domain 이 str 이라 “판정 불가”를 표현할 수 없다 — 결과가 0건일 때 런타임에 None 을 넣고 있다. 셋을 한 번에 논의하는 게 효율적일 것 같다
• B-0 분류기 학습 — 두 번 시도했고 두 번 다 v1 을 못 넘었다 (2026-08-27) — AI Hub 민원 데이터로 KcELECTRA 파인튜닝. 골든셋은 학습에 쓰지 않았다(평가 세트). 2 epoch → AI Hub 0.815 / 골든셋 0.786. epoch 4 + 초반턴 증강(+13,204건) → AI Hub 0.879 / 골든셋 0.786 — 혼동 행렬까지 동일하다. 검색 기반 v1 은 0.857. 틀린 3건은 전부 finance 로 가고 신뢰도 0.77~0.97 로 확신하며 틀린다 — 발급·처리·비용 이 AI Hub 금융에 압도적으로 많은 탓으로 보이고 학습을 키울수록 편향이 강해진다. 기본값을 v1 으로 고정했다. scripts/train_domain_classifier.py, w1-domain-routing
• B-0 — 검색 v1 과 분류기를 합쳐 본다 (신규, 2026-08-27) — 두 방식이 겹치지 않게 틀린다: 분류기는 GS-016·018·021 을, v1 은 GS-002·019 를 놓친다. 합치면 둘 다 넘길 여지가 있다. RRF 병합 함수는 이미 있다(decisions/021, retrieval/domain/services/fusion.py) — 검색 순위와 분류기 확률을 섞으면 된다. 다만 n=14 라 개선이 보여도 한두 건 차이이므로 표본 확장과 함께 봐야 한다
• dasan 보강 — 다산콜DB 6,614건 전사가 핵심 (신규, 2026-08-27) — dasan 이 두 방식 다 최하위다(AI Hub 0.746). 원인 세 가지를 데이터로 확인했다: ① 표본이 절반(7,600건 = health 16,237 의 47%) ② 어휘 겹침이 모든 쌍 중 최대(상위 400단어 dasan↔finance 0.47 — 수도요금·납부·지원금이 금융과 정면으로 겹친다) ③ 고유어(시내버스·지하철·대중교통)는 뚜렷한데 드물게 나타난다. data/raw/seoul-minwon-audio/민원상담_음성/다산콜DB/ 에 wav 6,614건이 있는데 전사가 없다 — 전사하면 dasan 이 7,600 → 14,000+ 로 불균형이 사라진다. 정성윤 님 w2-stt-batch가 하는 일과 같다. 덤으로 전사본은 STT 오류 특성을 그대로 가져 “깨끗한 텍스트 vs 실제 입력” 간극까지 메운다(5주차 오류 내성 실험과 연결). 그 전까지의 임시 완화는 클래스 가중치(오버샘플링보다 낫다 — 복제하면 그 문장에 과적합)
• B-0 목표(≥0.95)를 판정할 표본이 없다 (신규, 2026-08-27) — 채점 대상을 B(검색) 항목으로 좁히니 n=14 다. 14건에서 0.95 를 넘으려면 14/14 여야 하고(13/14 = 0.929) 만점 말고는 통과가 없다. 두 방식의 차이(12/14 vs 11/14)도 한 건이라 의미를 두기 어렵다. 3주차 골든셋 150건 확장 때 도메인 판정용 표본을 따로 늘려야 이 목표를 잴 수 있다
• 골든셋 문체와 실제 전사의 분포 차이 (신규, 2026-08-27) — 분류기가 AI Hub 에서 0.815 인데 골든셋에서 0.786 인 것이 이 차이 때문으로 보인다. 이건 B-0 만의 문제가 아니다 — 검색·컴플라이언스 지표도 같은 골든셋으로 재므로, 우리가 쓴 시나리오 문장이 실제 통화와 얼마나 다른지는 모든 지표의 해석에 걸린다. 3주차 150건 확장 때 AI Hub 실제 발화를 일부 섞을지 검토한다
• 프로젝트 종료 후 GCP 정리 (10-27 이후) — 무료 크레딧 유효기간이 2026-11-24 이라, 종료 뒤 리소스를 켜둔 채 두면 만료 시점부터 카드로 청구된다. 프로젝트 삭제 또는 결제 연결 해제로 마무리한다
• 확장을 막던 규칙 4건 완화 — 확정·반영 완료 (2026-08-27) — 「기능을 추가하려 하면 규약에 걸려 못 한다」는 지적을 규칙 파일에서 실제로 확인하고 고쳤다. 막고 있던 것은 넷이었다: ① F·G·H·I 동결이 시한 없는 상시 금지가 돼 있었다 — 규칙 파일이 기획서와 어긋나 있었던 것이다. 기획서 원문은 “6주차 종료 시점에 코어 기준선을 통과하지 못했다면” 인데 CLAUDE.md 에서만 「6주차 종료 시점에」가 빠져 있었다. 시점이 빠지자 “기준선 통과를 증명하기 전까지 언제나 금지”가 됐고, 하네스가 전부 「측정 불가」를 보고하던 동안에는 그 증명이 불가능해 2주차에 이미 동결이었다. 빠진 경위는 ee5c137(2026-08-25 chore: 두 갈래 저장소 통합) — 공통 조상이 없는 두 저장소의 CLAUDE.md 를 손으로 합치며 문장을 다시 쓸 때 사라졌고, 기획서 5개 문서는 전부 원문을 유지했다. 같은 커밋에서 「B(검색)·E(평가)·C-5 절대 사수」(초판부터 7개 문서에 있던 문장)도 빠져 사수 대상이 「코어 전부」로 읽혔다. ② 기획서를 고칠 공식 경로가 문서에 없었다. 「기능 추가·변경」 논의가 2026-08-27 “상담 중 고객 자료 발송”에서 멈췄는데, 처음엔 rfp-harness §1(새 접두어 금지)을 원인으로 봤으나 오독이었다 — 그 문장이 막는 것은 SFR 같은 ID 체계를 두 벌 만드는 것이지 새 기능이 아니다(새 기능은 기획서에 B-7 을 추가하면 된다). 실제 원인은 _project/plan.md 가 그때까지 “수정하지 않는 사본”이어서 ID 를 추가할 방법이 없었던 것이고, 더 근본적으로는 문서 우선순위에 결정 기록이 없어 004·014·018·021·023 이 실제로 기획서를 뒤집어 왔는데도 “그래도 되나”에서 매번 멈춘 것이다. ⚠ CLAUDE.md:77 은 2026-08-24 작성 보완지시서를 최상위로 두어 08-27 결정이 08-24 문서에 지는 역전까지 있었다(014 가 이미 보완지시서 11번을 이긴 전례가 있는데도). ③ decisions/012 의 “경계에 걸친 작업”에 정의가 없어 남의 디렉터리는 3줄도 못 고쳤다(그날 6건이 멈췄고 그중 하나가 하네스에 C-5·F-2 를 꽂는 3줄, 즉 이 프로젝트의 첫 실측값이었다). ④ 도메인 4종 조항이 “예시로도” 까지 막아 문서·발표 예시도 못 들었다 — 그런데 이것도 decisions/004 에 없는 문구였다(결정은 “A. 4개 도메인 전부 지원” 한 줄뿐). → ①은 원문 복원, ②는 문서 우선순위에 결정 기록 최상위 명문화(CLAUDE.md §1·rfp-harness §1 — X- 접두어는 미결 후보 표기 편의로 성격 정정), ③은 합성 루트 정의(decisions/012 — 류준의 023 이 협의 절차를 전부 걷어냈으므로 「소유는 담당자만」 표는 뺐다), ④는 근거 없던 제약 삭제. ①④는 파생 문서가 원문보다 빡빡해진 것이라 팀 합의가 필요 없고, ②③만 신규 규칙이다. 절대 원칙 1·2·8·9·10 과 진행 기록·티켓 규칙은 건드리지 않았다 — 그건 프로젝트가 평가받는 근거다. 근거·되돌리는 법: _project/decisions/022
• B-0 목표 ≥0.95 를 n=14 로는 판정할 수 없다 — 표본 설계 사안 (신규, 2026-08-27) — 6.1절이 도메인 분류 정확도에 ≥0.95 를 걸어 뒀는데 현재 채점 표본이 B(검색) 항목 14건이다. 14/14 = 1.000 만 통과이고 13/14 = 0.929 는 실패라, 만점 말고는 통과가 없다. 검색 기반 v1(12/14 = 0.857)과 KcELECTRA 분류기(11/14 = 0.786)의 차이도 한 건이라 우열을 말할 수 없다. ⚠ 목표 수치를 지금 낮추지 않았다 — 지표 변경은 규칙 완화가 아니라 평가 기준 변경이고, 발표에서 “기준을 왜 내렸냐”에 답해야 하는 종류다(절대 원칙 2). 정할 것: ① 3주차 골든셋 150건 확장 때 도메인 판정용 표본을 따로 늘릴지(C·C-5 항목은 발화에 도메인 단서가 없어 채점 대상에서 이미 빠졌으므로, B 항목만 늘려야 한다) ② 아니면 표본 크기에 맞게 목표를 재설정할지. ⚠ 6주차 종료 시점의 「코어 기준선 통과」 판정에 직접 물린다 — 그때 B-0 가 ❌ 로 남아 있으면 F·G·H·I 착수가 막힌다. 지금 당장 막는 것은 아니지만(동결은 6주차 시점 판정이다) 판정 시점 전에 표본을 정리해야 한다
• 배포를 한 컨테이너로 갈지 — ai/ 는 서비스가 아니다 (신규, 2026-08-27) — decisions/024 이 검색 스포크를 같은 프로세스에서 꽂기로 정했는데(HTTP 홉이 4.1절 p95 ≤1,000ms 예산을 먹는다), 그러면 server 컨테이너에 ai/ 코드가 함께 실린다. 그런데 CLAUDE.md §3 은 server.solidbob.cloud · ai.solidbob.cloud 두 도메인을 적어 두고 있다. 실제로 ai/ 에는 HTTP 표면도 fastapi·uvicorn 의존성도 없다 — ai/requirements.txt 주석이 “의존성은 server/requirements.txt 에 있다” 고 적고 있고, 구조상 라이브러리다. 지금은 ai/ 에 서비스 실체가 없어 모순이 드러나지 않지만 배포를 짤 때 정해야 한다. 정할 것: 문서의 두 도메인 서술을 고칠지, 나중에 ai/ 를 별도 서비스로 세울지(후자는 ai/ 에 웹 서버를 새로 만들고 server/apps/hub/adapter/outbound/ 에 HTTP 어댑터를 둔다 — 그건 server/ 안이라 계약 위반이 아니다). 담당: 정성윤(인프라)
• 기획서 ↔ 파생 문서 대조 검사가 없다 — 어긋남 4건이 이번에 우연히 발견됐다 (신규, 2026-08-27) — 규칙 파일·공개 문서가 기획서를 옮겨 적은 것인데, 옮기는 과정의 어긋남을 잡는 장치가 없다. 2026-08-27 대조에서 4건이 나왔다: ① F·G·H·I 동결의 「6주차 종료 시점에」가 CLAUDE.md 에서만 누락(ee5c137, 시한 있는 조건이 상시 금지가 됐다 — 팀이 3일간 여기 묶였다) ② 「B·E·C-5 절대 사수」가 CLAUDE.md 에서만 누락(초판부터 7개 문서에 있던 문장. 사수 대상이 「코어 전부」로 읽혔다) ③ 트리거 허용 창이 plan.md 800ms · docs/04 1,500ms 로 갈림(팀 컨펌은 1,500ms 쪽이고 plan.md 가 낡았다 — 아직 안 맞췄다) ④ server/.importlinter 계약 수가 실제 4종인데 CLAUDE.md 는 3종(정정 완료). ⚠ ①②는 규칙이 기획서보다 빡빡해진 사례다 — 옮겨 적기 실수가 팀을 막았고, 팀은 그걸 “규칙이 빡빡하다”로 경험했다. 정할 것: 같은 값이 두 곳에 다르게 적힌 것을 찾는 검사를 CI 에 넣을지(check_site_links.py 와 같은 자리), 아니면 값이 한 곳에만 살도록 문서 역할을 나눌지. 후자가 근본적이지만 문서 구조를 건드린다
• STATE.md 충돌 구조를 없앴다 (2026-08-27) — 네 사람이 매 세션 맨 위에 블록을 끼워 넣고 6행 「최종 갱신」을 각자 덮어써서, 그 파일 커밋 63건 중 19건이 머지 커밋이었고 08-27 네 브랜치 통합에서는 네 번 모두 여기서 걸렸다. 게다가 같은 날 STATE.md 에 세션 블록 14개 · _logs/ 에 58개로 같은 내용을 두 곳에 쓰고 있었다(§4 “같은 내용을 세 곳에 적지 않는다”와 §0.5 종료 루틴이 서로 모순이었다). → 「최종 갱신」 줄 삭제(git 이 이미 갖고 있다) · 세션 블록 24개를 _project/STATE-archive.md 로 이동(한 글자도 안 고쳤다, 절대 원칙 8) · 남는 것을 「영역별 상태」 표로 바꿔 각자 자기 줄만 덮어쓰게 했다 · CLAUDE.md §0·§0.5·§3 갱신. 809줄 → 130줄. ⚠ 파일을 쪼개지는 않았다 — _logs/·_backlogs/ 와 달리 STATE.md 는 “지금 상태”를 한 곳에서 봐야 하는 문서라 쪼개면 목적을 잃는다. _project/decisions/101
• 스케줄러를 무엇으로 할지 확정 — 현재는 지킬 칸반(/kanban/, _backlogs/ 컬렉션). GitHub Projects를 메인 보드로 쓰고 지킬은 산출물 기록만 담당하는 방식도 있다. Projects는 드래그 앤 드롭·이슈 연동이 되지만 저장소 밖에 상태가 생겨 기록이 두 곳으로 갈린다. 한쪽으로 정한다
• apps/platform 랜딩을 아키텍처·역할 문서에 올릴지 (신규, 2026-08-27) — 상담원 대시보드(apps/dashboard)와 별개 배포 단위로 제품 소개 페이지를 프론트가 먼저 정의했다. 기획서·3절에는 아직 없다. 배포는 2026-08-28 Vercel, 공개 URL은 https://www.solidbob.cloud/. 히어로 1차(문장 타이핑)는 폐기했고, 지금은 밝은 랜딩(키워드·카드 제목 4도메인 2.8초 순환, 히어로 100dvh). 정본으로 지시한 reference/mockup.html은 저장소에 없었다. 아키텍처·역할 문서 반영은 팀이 정하면 적는다
• 통화 목록 조회 API 필요 — 상담기록 화면 전제조건 (신규, 2026-08-28) — GET /hub/calls/{call_id}/transcript는 있지만(call_id를 이미 알 때 그 통화 자막 재조회), 여러 통화를 나열하는 목록 조회 엔드포인트(예: GET /hub/calls?domain=&limit=&offset=)는 계약에 없다. 프론트는 mock으로 화면만 먼저 구현.
• 다산콜DB 6,614건 전량 전사 — 승인 보류, 정성윤 결정 대기 — 2026-08-28 류준 철회. 전제가 사라졌다. 이 요청의 목적이 B-0 도메인 분류기의 dasan 표본 보강이었는데, 같은 날 다산 단일 도메인 전환으로 B-0 자체를 폐기하고 ai/apps/training/ 을 삭제했다 (_project/decisions/201). 분류할 도메인이 없으니 표본을 늘릴 대상도 없다. 정성윤 님 결정을 기다릴 필요 없다 — 요청을 거둔다. ⚠ 정성윤 님이 적어 둔 분석은 그대로 살려 둔다(아래 원문) — 「56개 시나리오 × 2역할 = 고유 텍스트 상한 112건」이라는 지적은 B-0 과 무관하게 이 데이터셋 자체의 성질이라, A-5 평가셋을 뽑을 때 다시 쓰인다. 소량 검증(w2-stt-batch)은 계속 유효하다. 원문 — — 류준 님이 B-0 dasan 표본 부족(7,600건 = health 16,237의 47%)을 메우려고 data/raw/seoul-minwon-audio/민원상담_음성/다산콜DB/ wav 6,614건 전량 전사를 요청했다. 전제 하나가 어긋난다: 서울 열린데이터광장이 이 데이터셋을 「56개의 시나리오에 대한 음성데이터」로 명시하고, 파일명 <시나리오번호>_<연령대>_<성별>_<지역>_<민원인|상담사>_<take번호>.wav 가 그 구조 그대로다(6,614 ÷ 56 ≈ 시나리오당 118개). 고유 텍스트의 상한은 56 × 2역할 = 112 이고 B-0 은 텍스트 분류기라 화자가 달라도 입력이 같다 — 늘어나는 6,000여 건은 그 112건의 복제본이고, 류준 님이 3c84411 에 적은 “복제하면 그 문장에 과적합” 이 그대로 해당한다. 같은 커밋의 실측도 같은 방향이다(초반턴 증강 +13,204건 → AI Hub +6.4%p, 골든셋은 혼동 행렬까지 한 자리도 안 바뀜). 권고: ① 소량 5~10건 검증만 지금 진행(무료 한도 안, w2-stt-batch 완료 조건) ② 클래스 가중치 학습 1회 — 지금 트레이너에 아예 없다(domain_classifier_trainer.py 가 그냥 model(..., labels=labels).loss) ③ 그래도 부족하면 시나리오 커버 112건만 전사(평균 7초면 13분·12초면 23분 → 무료 한도 60분/월 안). 정할 것: 이 순서로 갈지, 요청대로 전량 전사를 승인할지. 승인되면 결정 기록 1xx 로 남긴다
• ⚠ ₩0 으로 확정 가능 — 다산콜DB 고유 시나리오 수를 직접 세야 한다 (신규, 2026-08-28) — 위 판단의 근거인 「56」은 서울시 페이지에서 온 숫자이고 파일을 직접 보지 못했다(이 머신에 data/raw/ 오디오도 .venv 도 없다). 오디오가 있는 머신에서 ls .../다산콜DB/ | awk -F_ '{print $1}' | sort -u | wc -l 한 줄이면 1분에 확정된다. 같이 확인할 것 — data/README.md 의 「1.3G」와 류준 님이 잰 45,853초가 안 맞는다. 8kHz 16bit 모노면 734MB 여야 하므로 실제 파일은 16kHz 거나 스테레오다. 2026-08-28 수정으로 transcribe_batch.py --dry-run 이 헤더 조합을 요약에 찍으므로 같은 실행에서 함께 드러난다
• STT 비용 전제 정정 — 지금 스크립트로는 Dynamic Batch 가격을 못 받는다 (신규, 2026-08-28) — ① Dynamic Batch 는 $0.004 가 아니라 $0.003/분이지만, V2 BatchRecognize 는 gs:// 만 받는다 — wav 1.3GB 를 GCS 에 올리고 스크립트를 V2 로 고쳐야 그 가격이 나온다. 지금 코드는 V1 동기 recognize() 다 ② Standard $0.016/분은 V1 에서 데이터 로깅 옵트인 가격이다. 민원 음성엔 개인정보가 그대로 들어 있어 SEC-1 상 받을 수 없다 — 옵트인 없는 V1 은 $0.024/분(전량이면 약 ₩23,000, 월 예산 ₩30,000의 78%) ③ 크레딧 ₩435,523 이 미사용이라 카드 청구는 어느 쪽이든 0원이다. 전량 전사를 반대하는 이유는 돈이 아니라 얻는 게 없다는 것이다. 정할 것: 전량으로 간다면 V2 전환 + GCS 업로드를 티켓으로 뺄지, V1 그대로 비싸게 갈지
• 중복 티켓 — 조서희 님 확인 필요 (신규, 2026-08-28) — 세션 종료 검사가 w1-dashboard-scaffold-seohee(status done) ↔ w2-dashboard-scaffold(status todo)를 같은 작업으로 경고한다. 제목이 「React 대시보드 스캐폴딩」으로 같고 담당도 둘 다 조서희다. 남의 티켓이라 손대지 않았다(§4). w2 쪽이 아직 todo 라 보존할 수행 기록이 없으므로 합치거나 범위를 나누면 된다
• call.solidbob.cloud 는 프론트, 지킬은 docs.solidbob.cloud — 확정 (2026-08-28, decisions/104) — call(통화)은 제품 쪽 이름이라 상담 화면이 붙는 게 자연스럽고, 문서 사이트는 주소만 보고 알 수 있는 docs 가 낫다. 바꾸는 비용이 거의 없었다 — 본문 링크 405곳은 전부 루트 절대경로라 도메인과 무관하고, github.com/solidbob02/call.solidbob.cloud 는 저장소 이름이라 그대로다. ⚠ 저장소 이름과 사이트 주소가 달라진다(저장소 개명은 링크·클론 경로를 깨므로 안 한다). 원래 논의는 아래에 남긴다 — — DNS 이관 중에 프론트 담당이 가비아 존에 call CNAME cname.vercel-dns.com(Vercel)을 추가한 것을 발견했다. 그런데 call 은 지킬 기획서 사이트가 쓸 이름으로 잡혀 있다(저장소 이름·표지·문서 링크 405곳이 전부 이 기준이고, decisions/102 도 그렇게 정했다). 한 이름은 한 곳만 가리킨다. ⚠ 의도인지 확인이 먼저다 — 저장소 이름을 보고 넣은 것일 수도 있다. 프론트는 이미 apex(solidbob.cloud)·www 를 갖고 있어서, 화면이 더 필요하면 app·dashboard 를 쓰면 된다. 정할 것: ① call = 지킬(권장 — 고칠 게 없다) ② call = 프론트(지킬은 docs 등으로, _config.yml·decisions/102·티켓을 함께 고쳐야 한다). 담당: 정성윤 ↔ 프론트
• DNS 레코드를 넣는 곳이 바뀌었다 — 팀 전체 공지 필요 (신규, 2026-08-28) — 네임서버를 클라우드플레어로 옮기면 가비아 DNS 설정은 무시된다. 실제로 프론트 담당이 이관 중에 가비아에 call 을 넣었는데 그건 전환 순간 사라진다. 앞으로 DNS 는 클라우드플레어에서만 넣는다. ⚠ 함께 겪은 것: 버셀이 요구하는 www CNAME 대상값은 프로젝트가 바뀌면 같이 바뀐다(오전 8511982eb7ecc120… → 오후 ea6aaafa6f786127…). 값의 정본은 버셀 대시보드 Domains 화면이지 우리가 적어둔 메모가 아니다. 레코드 원본·확인법: _project/dns-solidbob-cloud.md
• 배포 사이트 본문 링크 404 — 해결 (2026-08-28) — https://docs.solidbob.cloud/ 로 붙였다. 내부 링크 86개 전수 확인 200, HTTPS 강제, 인증서 정상. 아래는 원인 기록 — — https://solidbob02.github.io/docs/09/ 처럼 죽는다. 프로젝트 페이지라 사이트가 /call.solidbob.cloud/ 아래 놓이는데 링크 405곳이 /docs/09/ 같은 루트 절대경로라 한 겹이 어긋난다. 상단 내비만 relative_url 을 써서 내비는 되고 본문은 안 되는 모양이 됐다. CI 가 못 잡는 이유: 링크 검사는 --baseurl 없이 빌드한 _site 를 보고, 배포는 --baseurl /call.solidbob.cloud 로 다시 빌드한다 — 검사한 사이트와 배포된 사이트가 다르다. 해법은 커스텀 도메인이다(루트에 올라가면 baseurl 이 "" 가 되어 405곳이 그대로 맞고, CI·배포 빌드도 같아진다). 저장소 쪽(_config.yml url · jekyll/CNAME · pages.yml 주석)은 반영했다. 남은 것 — 정성윤: ① 가비아 DNS 에 call CNAME solidbob02.github.io. ② Settings → Pages → Custom domain 지정 후 Enforce HTTPS. ⚠ jekyll/CNAME 파일이 ①② 를 대신하지 못한다 — Actions 배포는 그 파일을 읽지 않는다. _project/decisions/102 · w2-custom-domain
• 커스텀 도메인을 클라우드플레어로 걸지 — 건다. ⚠ 아래 판단은 같은 날 뒤집혔다 (2026-08-28, decisions/103) — 존은 이미 클라우드플레어에 추가됐고 네임서버 전환 대기 중이다. 아래 우려 셋 중 둘은 순서를 지키면 사라진다(프록시를 DNS only 로 두면 인증서 발급이 막히지 않고, 암호화 모드를 Full (strict) 로 두면 루프가 안 난다). 남는 것은 「존을 통째로 옮겨야 한다」인데 레코드가 2건뿐이라 비용이 작고, 옮겨 두면 나중에 server.solidbob.cloud(AWS)에 프록시·터널을 붙일 때 이관 단계가 없어진다. 지켜야 할 조건 4가지는 decisions/103 에 있다 — ① call 은 항상 회색 구름 ② Full (strict) ③ apex·www(Vercel)도 회색 구름 ④ NS 전환 전에 레코드 2건 대조(가져오기가 놓친 채로 바꾸면 그 순간 랜딩이 죽는다). 원래 판단은 아래에 그대로 남긴다(절대 원칙 8) — 클라우드플레어는 서브도메인만 위임받지 못해(부분 설정은 엔터프라이즈) 네임서버를 통째로 옮겨야 하고, 그러면 지금 살아 있는 apex·www(Vercel)를 다시 만들어야 한다. 프록시(주황 구름)를 켜면 GitHub 의 인증서 발급이 막히고, SSL 모드가 Flexible 이면 리다이렉트 루프가 난다. 지금 solidbob.cloud 존에는 apex A 216.198.79.1 와 www CNAME 둘뿐이고 MX·TXT 가 없어서, 나중에 server.solidbob.cloud(AWS)에 프록시·터널이 필요해지면 그때 옮겨도 비용이 같다. _project/decisions/102
• GitHub Pages 활성화 — Source를 “GitHub Actions”로 변경 완료, 배포 워크플로 정상 동작 확인(https://solidbob02.github.io/call.solidbob.cloud/). ⚠ 커스텀 도메인 연결을 Sprint 7 로 미룬 것이 위 404 의 원인이다 — 2주차로 앞당겼다

세부 진행은 8주 마일스톤의 칸반 보드, 완료 기록은 진행상황에서 확인하세요.

← 표지로 돌아가기