미결 항목

예상 리스크

리스크	대응
AI Hub 승인 지연	1주차 즉시 신청. 4.2절 오류 내성 실험은 텍스트 레벨 오류 주입이므로 승인과 무관하게 진행 가능
화자 분리 정확도 미달	[V1] 모노 확인됨. diarization 필수, 데모는 물리 2채널(브라우저 2대)로 우회
~~류준 부하 집중 (백엔드+AI 동시 담당)~~ (해소됨, 2026-08-26)	7.2절 팀 개편(장민석이 백엔드·AI 합류)으로 구조적으로 해소. C-5·CI 운영은 정성윤에게 둔 기존 조치는 유지, F-2는 여전히 조건부
GPU 미확보	[V2] 확인됨 — Apple M5, CUDA 없음. `polyglot-ko-1.3b` 등 소형 모델 MPS로 대응, 4개 오픈소스 모델 다운로드 완료
외국인 화자 한국어 음성 데이터 0건 (신규 2026-08-28)	대응 미정 — A-3 최대 리스크. AI Hub 다산 데이터는 전부 내국인 발화다. 출처를 못 찾으면 A-3 의 STT 정확도를 측정할 방법이 없다(절대 원칙 10 — 측정할 수 없는 것을 측정한 것처럼 쓰지 않는다)
~~A-3 번역 품질 채점 방법 미정~~ (2026-08-28 1차 범위에서는 해소)	ⓑ 로 좁히면서 1차 지표가 번역 품질이 아니라 STT 정확도(WER/CER) 가 됐다. WER 은 규칙 기반이라 절대 원칙 1 과 충돌하지 않는다. 번역 채점 문제는 ⓐ 확장 시점으로 미뤄진 것이지 풀린 것이 아니다
골든셋 13건 — 지표 신뢰 불가 (신규 2026-08-28)	도메인 축소로 50 → 13건. 다산 기준 재확장 전까지 Recall@5·MRR 을 문서에 기록하지 않는다
A-5 통번역 지연 예산 미계산 (신규 2026-08-28)	ⓑ 1차 범위에는 번역 경로가 없어 STT 지연만 얹힌다. 번역+TTS 왕복은 ⓐ 확장 시점의 문제다. 기획서 4.3절에 항목만 열어 두고 목표치는 비워 뒀다(절대 원칙 2)
범위 과다 (F·G·H·I)	코어(A~E, C-5)만 절대 사수, 나머지는 6주차 기준선 통과 시에만 조건부 착수
~~깃허브 저장소·데모 도메인 아직 미배포~~ (해소됨, 2026-08-28)	원격은 `github.com/SeongYuna/call.solidbob.cloud`로 연결 완료. 데모 도메인 연결은 Sprint 7 로 미뤄 뒀으나, 미룬 탓에 배포 사이트의 본문 링크가 전부 404 라 2주차로 앞당겼다(프로젝트 페이지의 `/call.solidbob.cloud/` 한 겹과 루트 절대경로 링크 405곳이 어긋난다). `_project/decisions/102` · w2-custom-domain

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개 패턴에 대해 측정할 방법 자체가 없었다.

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

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

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

인프라 런북을 하네스로 걸면서 드러난 어긋남 4건 (2026-09-04)

docs/infra-runbook.md 를 각 영역 규칙에 배선하면서(루트 CLAUDE.md §0) 저장소와 다른 곳이 나왔다. 전부 인프라(정성윤) 소관이라 고치지 않고 올린다.

배포가 한 파드인가 두 도메인인가. 런북은 server 파드 하나에 임베딩·분류기까지 올리고 server.solidbob.cloud 만 연다(13-1·16-1·19장). 반면 루트 CLAUDE.md §3 과 ai/CLAUDE.md 머리말은 ai.solidbob.cloud 를 배포 대상으로 적고 있다. decisions/024(검색 스포크를 같은 프로세스에서 꽂는다)와 같은 사안이고, STATE.md 의 정성윤 회신 대기 항목이 아직 열려 있다
저장소 주소가 다르다. 런북 13장은 github.com/SeongYuna/call.solidbob.cloud.git 을 클론하는데 루트 문서·실제 원격은 github.com/solidbob02/call.solidbob.cloud 다. 한쪽으로 맞춰야 서버에서 그대로 붙여 쓸 수 있다
부록 B 의 결정 기록 9건이 아직 없다. 런북 18장은 이미 decisions/103(Cloudflare 프록시 금지)을 참조하지만 파일이 없다. 번호대는 정성윤 1xx 다(§4)
.env.example 에 OLLAMA_URL·HF_HOME 키가 없다. 런북 16-1 은 파드에 둘을 주입한다. .env.example 은 자격증명 보호 훅이 편집을 막으므로 사람이 직접 채워야 한다(SEC-2)

프론트 연동을 막는 세 겹 중 인프라 몫 (2026-09-09)

프론트가 붙으려면 CORS → DB 스키마 → ES 적재 순서로 세 겹이 열려야 한다. CORS 는 server/ 에서 열었다(w3-cors-dashboard). 나머지는 kubectl 권한이 있는 쪽 일이라 올린다.

대시보드를 어디서 서빙할지 정해지지 않았다. 런북은 외부에 여는 주소가 server.solidbob.cloud 443 하나라고만 적었고(16-2·18) 대시보드 호스팅은 어디에도 없다. 같은 도메인에서 Caddy 가 정적 파일로 내주면 CORS 가 필요 없고, 다른 origin 이면 배포 env 에 CORS_ALLOWED_ORIGINS 를 넣어야 한다(런북 16-1 주입 목록에 아직 없다). 런북 16-2 가 참조하는 infra/docker/Caddyfile 도 저장소에 없다 — 정성윤·조서희
런북에 지식베이스 적재 단계가 없다. 15장(Elasticsearch)은 기동·nori 확인까지만이고, scripts/index_knowledge_base.py --to-es --recreate 를 운영 ES 에 도는 절차가 없다. ES 는 ClusterIP 라 밖에서 못 치므로 클러스터 안 Job 이나 kubectl exec 절차가 필요하다. 이게 없으면 /hub/search 는 운영에서 계속 빈 인덱스를 본다 — 정성윤(실행)·류준(명령)
DB 스키마 적용은 런북 17장 그대로 정성윤 실행 항목이다. 09-04 의 어긋남 4건과 별개로, 배포 순서에 17장·위 2번 적재가 들어가야 프론트가 붙일 게 생긴다. 2026-09-11: 17장을 실물 기준으로 고쳤다 — 인스턴스에 클론이 없어 raw.githubusercontent.com 에서 받고, 서버 파드 안에서 서버와 같은 DATABASE_URL 로 넣는다(12-2 시크릿 교체가 먼저). 실행은 아직이다 — w4-rds-prod-db

블랙컨슈머 수동 분류 카드 — 결정 기록 없음 (2026-09-10)

apps/dashboard에 통화 종료 후 상담원이 직접 판단해 분류하는 카드를 추가했다 (BlackConsumerAction.tsx). 코드 주석은 “C-6 확장”이라 적었지만, _project/plan.md rev.5의 C-6은 자동 탐지(고객 욕설·폭언, 재현율 우선 분류기)로만 정의돼 있어 성격이 다르다. 뒷받침하는 결정 기록이 아직 없다(CLAUDE.md §1 원칙 미준수). 정할 것: 결정 기록(조서희 4xx)을 써서 plan.md에 이 서브기능을 공식화할지, 아니면 C-6과 무관한 별도 ID로 뗄지. 지금은 보류.

이번 주 할 일 (1주차)

3주차에 남긴 것

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

통화 시작이 §7.3 계약에 없다 — 콜 미디에이터가 POST /hub/calls 를 먼저 불러야 한다 (신규, 2026-09-10) → 2026-09-14 plan.md §7.3 에 올렸다 — 콜 미디에이터가 첫 채널을 열 때 부른다(09-11 구현). 원문 — — transcript_segment.call_id → call 외래키 때문에 통화 행이 먼저 있어야 전사가 저장되는데, 계약 3종(전사·카드·종결)에 “통화가 시작됐다”는 메시지가 없었다. 서버에 POST /hub/calls 를 만들었다(_project/decisions/301). 정할 것: 콜 미디에이터(정성윤)가 통화를 여는 순간 이 엔드포인트를 부르는 것으로 §7.3 에 올릴지, 콜 미디에이터 → 허브 WebSocket 이 생기면 그 첫 메시지로 할지. 지금은 테스트하는 사람이 직접 부른다
CI 에서 PostgreSQL integration 테스트가 돌지 않는다 (신규, 2026-09-11 · 같은 날 붙였다) — 권고안대로 붙였다: test.yml server job 에 postgres:17 서비스(trust 인증, 암호 없음) → 새 DB 에 db/schema.sql 적용 → pytest -m integration(0건·스킵이면 실패). 세 테스트 파일에 복사돼 있던 .env 읽기는 server/conftest.py 의 integration_settings 픽스처 하나로 합쳤고, CALLGUARD_TEST_DATABASE_URL 이 있으면 그것만 쓴다. 로컬에서 같은 절차로 4 passed, 수정 전 어댑터로 되돌리면 2 failed 로 잡히는 것까지 확인했다. CI 에서 실제로 도는 것은 첫 PR 에서 확인한다(job 이름 server 는 그대로라 룰셋은 안 고친다). 원래 적힌 내용 — test.yml 의 server job 에 psycopg 도 PostgreSQL 서비스도 없어 @pytest.mark.integration 이 한 번도 CI 에서 안 돌았다. 그래서 09-09 스키마 QA(decisions/205)로 PK 가 (call_id, segment_id) 가 된 뒤 전사 저장 어댑터가 새 스키마에서 저장 전부가 실패하는 상태(InvalidColumnReference)로 사흘간 초록이었다(w4-segment-composite-upsert에서 고침). 게다가 integration 테스트는 루트 .env 에서 DB 를 읽는데 그 DB(Neon)는 옛 스키마다. 정할 것: postgres:17 서비스 + 매번 새 DB 에 db/schema.sql 을 적용하는 픽스처를 CI 에 붙일지. 붙이면 server job 이 느려지고 test.yml 을 고쳐야 한다(런북 13·21~22장)
지식베이스에 여권 발급·재발급 조항이 없다 (신규, 2026-09-11) — 운영 ES 적재 뒤 「여권 재발급 서류가 뭐예요」로 검색하니 1위가 DASAN-MANUAL-4.1(의학적 판단 금지)이었다. 검색 결함이 아니라 정답 문서가 없다 — knowledge-base/dasan/ 98조항에서 「여권」은 신분 확인 서류 목록에 두 번 나올 뿐이다. 그런데 decisions/201 은 다산을 고른 근거로 서류 문의 상위 단어에 여권 이 4위라고 적었고, 외국인 지원(A-5)이 차별점이다. 정할 것: 여권 관련 절차 조항을 지식베이스에 넣을지(출처 확인 필요 — 절대 원칙 6, 원문 전재 금지), 골든셋에 「정답 없음」 케이스로 둘지. D-4(공백 리포트)가 잡아야 할 전형이다 → ✅ 2026-09-22 들어갔다 — DASAN-TERM-4.23(류준 PR #135) · 운영 ES 재적재 101청크 · 「여권 재발급 필요 서류」 검색 1위(0.878). 남은 부작용은 아래 「여권 조항 4.23 이 dense 에서 끼어든다」 항목.
POST /hub/cards/{id}/feedback 이 새 스키마에서 늘 500 (신규, 2026-09-11) — card_feedback.card_id 가 recommendation_card 를 FK 로 참조하는데 recommendation·recommendation_card 를 쓰는 코드가 없고, 카드 응답에 card_id 도 없다. 피드백을 받을 카드가 DB 에 있을 수 없는 구조다. 정할 것: 추천 결과를 저장할지(카드 응답에 card_id 추가), FK 를 뺄지. db/schema.sql FK · INSERT INTO "recommendation…" 0곳 · 카드 스키마에 card_id 없음을 grep 으로 확인했다(실행으로는 안 쟀다). 코드는 손대지 않았다
- → 닫음 (2026-09-21 보드 최신화, 정성윤): decisions/308(추천을 요청 경로에서 저장하고 card_id 를 준다) · w4-recommendation-card-id done · 프론트 연결은 09-16
서버는 segment_id 를 정수로 보내는데 프론트 파서가 문자열만 받는다 — 전사가 조용히 버려진다 (신규, 2026-09-10 · 같은 날 해결) — 조서희 요청으로 서버 HTTP 표면을 문자열로 맞췄다. §7.3 예시가 문자열이고 프론트가 그대로 따르고 있었으므로 서버가 계약 쪽으로 간 것이다. DB 는 BIGINT, 내부 DTO 는 int 그대로이고 변환은 라우터(경계)에서만 한다. 요청은 정수·숫자 문자열 둘 다 받는다(pydantic lax). /openapi.json 이 string 으로 공표하는지 테스트가 고정한다(test_segment_id_contract.py). 같은 날 오후, 범위가 «모든 응답의 모든 필드 문자열» 로 커졌다 — 조서희 파서가 전부 문자열을 전제로 만들어졌고 사용자가 그 범위를 택했다. 불리언은 "true"/"false", 숫자는 str(), null 은 그대로. 변환은 schemas/_types.py StrField 한 곳이고 라우터·DTO·DB 는 원래 타입이다. /health 만 예외(스키마 없는 dict, 런북 19장 배포 검증 항목이라 불리언 유지). ⚠ §7.3 계약 정본·프론트 types/contract.ts(is_final: boolean·utterance_end_ms: number)와 이제 어긋난다 — 계약 문서를 «전부 문자열» 로 고치는 것이 남았다. 류준(ai 는 HTTP 표면을 안 쓰므로 영향 없음 — 확인함)·조서희와 같이 본다
운영 커넥션이 실제로 붙은 적이 있는지 확인 (신규, 2026-09-10 · 2026-09-11 답: 한 번도 없다) — 09-11 운영 파드 로그로 확정했다(정성윤): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed. 운영 시크릿의 POSTGRES_HOST 가 비어 있었고, DATABASE_URL 은 임시로 넣은 Neon 이었으며, RDS 는 만들어진 적이 없다(describe-db-instances 빈 결과). 아래 «운영은 DATABASE_URL 하나만 주입한다(런북 12-2)» 는 런북 기준이고 실제 시크릿은 server-env(.env 16키)였다. RDS 로 옮긴다 → _project/decisions/108 · w4-rds-prod-db. 원래 적힌 내용: 커넥션 팩토리가 DATABASE_URL 을 안 읽고 개별 POSTGRES_* 만 읽었는데, 운영은 DATABASE_URL 하나만 주입한다(런북 12-2). /health 의 postgres_configured: true 는 설정 «여부»라 이걸 못 잡는다. 09-10 에 고쳤지만 운영에 재배포되기 전까지는 운영 전사 저장이 실패하는 상태일 수 있다 — 정성윤 복귀 시 재배포 + 운영 DB 에서 transcript_segment 행 수 확인. 배포 확인 항목(런북 19장)에 «저장이 실제로 되는가»가 없다는 뜻이기도 하다
ngrok 으로 연 서버에 인증이 없다 (신규, 2026-09-10) — ✅ 끝났다 — ngrok 터널은 닫혔고(STATE.md) 바깥에 열린 것은 server.solidbob.cloud 하나다. 문 검사는 2026-09-19 에 다시 했다 — 토큰 없는 /call-mediator/ws·/ingest 는 401. 원문 — 주소를 아는 사람은 누구나 /hub/transcripts 로 Neon 에 쓰고 /docs 를 본다. basic auth 는 걸지 않기로 했다(09-10) — 브라우저 fetch 의 CORS preflight(OPTIONS)에는 Authorization 헤더가 실리지 않아 ngrok 이 401 로 끊고, 그러면 조서희의 fetch 가 통째로 실패한다. «데모 데이터·test- 접두어·터널은 필요할 때만 연다» 로 감수한다. 주소는 임시 도메인이라 재시작마다 바뀐다 — 그것이 유일한 방어다
담당 디렉터리 잠금을 풀었다 — 프론트만 전담 (2026-09-10, _project/decisions/302) — 사용자 지시. ai/·server/·infra/ 는 정성윤·류준·장민석 누구나 고친다. 전담이 남는 곳은 조서희의 프론트엔드(apps/) 하나다. 이유는 «구멍»이다 — 기능 하나가 배선(server/)·구현체(ai/)·배포(infra/) 셋에 걸치는데 담당이 갈려 각자 자기 몫을 끝내도 호출부만 있고 구현체가 없는 상태로 남았다. decisions/022 ①이 같은 것을 이미 적었고(하네스에 C-5·F-2 를 꽂는 3줄), 023 이 협의 절차를 없앴지만 경계 자체는 남아 있어 그 3줄은 여전히 못 고쳤다. 012 의 나머지는 그대로다 — 역할 구분(요청이 흐르는 길 / 품질을 만들고 재는 쪽)과 의존 방향(ai → server)은 담당자 문제가 아니라 아키텍처이고, 코드를 어디에 둘지는 여전히 그 기준으로 가른다. 브랜치도 넷 그대로(011) — 바뀐 것은 «어느 브랜치에서 어느 디렉터리를 고칠 수 있는가» 뿐이라 test.yml 트리거·job 이름·main 룰셋은 손대지 않았다. 잠금 대신 남는 것: .importlinter 계층 계약 · infra_runbook_guard.py(배포에 닿는 파일은 담당자든 아니든 런북 먼저) · 손대기 전 grep 으로 영향 범위 확인(023). infra/ 의 되돌리기 어려운 변경(자원 생성·삭제)은 정성윤과 말로 맞춘다. 고친 곳: CLAUDE.md §0·§1·§3·§4·§7 · .claude/rules/rfp-harness.md §2 · .claude/rules/dashboard.md · server/CLAUDE.md §5 · ai/CLAUDE.md §6 · infra/CLAUDE.md · 7.1절. 이 항목으로 풀리는 것: 위 「P6·P7 NER — ai/ 몫」(포트를 양쪽에서 같이 만들 수 있다) · 「generation·compliance 를 ai/ 에 두는 것 — 장민석 확인 필요」(담당이 바뀌는 변경이 아니게 됐다). ⚠ 남의 티켓 관련 항목(중복 티켓 — 조서희 님 확인 필요)은 그대로 남는다 — 프론트는 여전히 전담이다

← 표지로 돌아가기

콜 미디에이터를 붙이며 남은 것 (2026-09-11)

services/call-mediator 가 생겼다(w4-gateway-streaming-stt) — 실제 AI Hub 음성 → Google STT → 로컬 server 마스킹 → 대시보드 WS 까지 관통했다. 거기서 나온 것들이다.

.env.example 에 콜 미디에이터 키 넷을 사람이 넣어야 한다 (신규, 2026-09-11 · 같은 날 넣었다) — 사용자가 ! 로 직접 붙였다(값 없이 키 이름·설명만, 보호 훅은 우회하지 않았다). 원래 적힌 내용 — CALL_MEDIATOR_PORT(기본 8080) · CORE_API_URL(기본 http://localhost:8000, 운영은 http://callguard-server) · CALL_MEDIATOR_INGEST_TOKEN · CALL_MEDIATOR_VIEW_TOKEN (둘 다 없으면 루프백만 받는다). 자격증명 보호 훅이 이 파일을 파일 이름으로 막아 Claude 가 넣지 않았다(우회하지 않았다). 값 없이 키 이름만 넣으면 된다(SEC-2). ⚠ 이 머신의 .env 는 GOOGLE_APPLICATION_CREDENTIALS 가 류준 님 Mac 경로(/Users/ryujun/…)라 그대로는 키를 못 찾는다 — 실제 키는 ~/.gcp/callguard-stt.json 이고, 검증 때는 셸 변수로 덮어 썼다
모노 한 줄에 섞인 두 화자는 가르지 못한다 — A-2 는 채널 분리만 (신규, 2026-09-11) → 2026-09-14 speaker=auto 로 넣었다 — 먼저 말한 화자 = 상담원, 선택형(decisions/303, 사용자 선택). ⚠ 실제 구글 응답으로는 미검증 — 아래 신규 항목. 원문 — — V1 실측대로 AI Hub 녹음은 전부 모노라, 재생하면 한 화자로 찍힌다. 구글 화자 태그(diarization)는 final 에만 붙고 누가 상담원인지는 알려 주지 않는다 — 첫 화자를 상담원으로 치는 식의 추측을 넣으면 C-1~C-4(상담원)·C-6(고객) 방향이 뒤집힐 수 있어 넣지 않았다. 정할 것: 데모를 물리 2채널(브라우저 2대)로만 할지, 모노 녹음 재생용으로 diarization + 규칙을 둘지
콜 미디에이터 배포 — 위 「A-1 콜 미디에이터를 같은 EC2 에 올릴지」(2026-09-03)의 답이 런북에 이미 있다 (신규, 2026-09-11 · 같은 날 배포) — → 2026-09-11 운영에 올렸다(PR #68 — 같은 노드, Ingress /call-mediator, infra/k8s/base/call-mediator.yaml). ①~⑥ 전부 반영 — ⑤ 장부는 hostPath, ⑥ 토큰은 배포가 인스턴스 안에서 만든다. 첫 배포는 Docker Hub 새 저장소가 비공개로 만들어져 멈췄다(아래 원문은 그대로 둔다). 원래 적은 것 — 런북 0장 사양표가 FastAPI server · Node 콜 미디에이터 · Caddy ≈ 1.0GB 를 같은 노드에 넣고 계산했다. 남은 것은 ① 이미지(infra/docker/call-mediator.Dockerfile) ② k8s Deployment·Service(시크릿 server-env · gcp-stt-credentials 재사용) ③ Ingress 경로 — 밖에 여는 주소는 server.solidbob.cloud 하나이므로 /call-mediator 같은 경로로 붙인다 ④ release.yml 이 server 이미지만 굽는다 ⑤ STT 사용량 장부가 파드 안 파일이라 재시작하면 0 이 된다 — 볼륨에 두거나 1차 방어선(GCP 쿼터)만 믿을지 ⑥ 인증 — Ingress 로 열기 전에 /ws·/ingest 접근 제어가 먼저다 (배포 선행 조건). 처음엔 Origin 검사뿐이라 브라우저만 막았다 — 밖에 열리면 비브라우저 클라이언트가 call_id 없이 WS /ws 로 모든 통화의 마스킹된 자막·추천을 받고, /ingest 로 STT 캡까지 과금을 태울 수 있었다(a5 세션 지적). → 같은 날 토큰 두 개로 막았다(services/call-mediator/src/domain/access.ts). 루프백 밖은 문마다 토큰이 맞아야 하고, 토큰을 안 넣고 배포하면 전부 401(fail-closed). /ingest 는 진짜 비밀(CALL_MEDIATOR_INGEST_TOKEN, 헤더로만), /ws 는 CALL_MEDIATOR_VIEW_TOKEN — 브라우저가 내므로 비밀이 아니다. 번들에서 뽑혀도 과금 문은 안 열리게 가른 것이다. ⚠ 그래서 /ws 는 아직 제대로 막힌 게 아니다 — 자막을 보는 사람을 가르려면 상담원 로그인이 있어야 하고, 서버에도 없다 (「서버에 인증이 없다」). 배포 때 할 일: 두 토큰을 시크릿에 넣는다(서로 다른 값). 공개 대시보드 번들에 뷰 토큰을 넣을지는 그 한계를 알고 정한다 ⚠ 지금 EC2 등급이 런북의 g4dn.xlarge 인지 확인이 먼저다
통화 시작(2026-09-10 항목)은 콜 미디에이터가 ①로 구현했다 — §7.3 문서 반영이 남았다 (신규, 2026-09-11) → 2026-09-14 §7.3 반영 완료 (「검색 중」 은 꺼 둔 채로 — 위 09-09 항목). 원문 — — 첫 /ingest 채널이 열리는 순간 POST /hub/calls 를 부르고, 실패하면 채널을 열지 않는다(외래키 때문에 저장이 전부 실패하므로). 같은 통화에 화자가 둘이어도 한 번만 부른다. 「검색 중」 신호(2026-09-09 항목)도 콜 미디에이터가 추천을 부르기 직전에 쏘면 된다 — 계약만 정하면 붙일 자리가 있다
ES 에 못 붙을 때 /hub/recommendations 가 500 이다 (신규, 2026-09-11) → 2026-09-14 503 으로 고쳤다(w4-es-unreachable-503) — ConnectionError·ConnectionTimeout, 본문에 ES 주소를 싣지 않는다. 원문 — — 09-10 에 인덱스가 없을 때(index_not_found)는 503 + 「적재해야 한다」로 돌려주게 했는데, ES 자체에 연결을 못 하면(로컬 ES 없음) 여전히 500 이다. 콜 미디에이터는 둘 다 상태 코드만 로그에 남기므로 동작은 같지만, 운영에서 원인을 가르려면 503 쪽이 낫다 — server/ (누구나)

콜 미디에이터 마무리에서 남은 것 (2026-09-14)

C-6 저장 배선 · 오류 주입기에서 남은 것 (2026-09-14, 류준)

운영 RDS 에 document 행이 없다 (신규, 2026-09-14 · 같은 날 정정) — 콜 가드 기록·추천 카드의 근거 조항이 이 테이블을 외래키로 → 닫힘 (2026-09-15) — 2026-09-15 적재 완료(98행). 돌리기 전 쌓인 call_guard_flag 1건은 source_doc_id 가 NULL 로 남는다 — 적재는 과거 행을 소급하지 않는다. 가리킨다. 비어 있으면 근거가 NULL 로 저장된다(장민석 님 콜 가드 저장소가 FK 위반 대신 NULL 로 떨어뜨린다). ~~500 이 난다~~ 는 걷어낸 류준 배선 기준의 서술이었다. 절차는 런북 17-3 — scripts/seed_documents.py. 정할 것: 누가 언제 돌리는가(정성윤 님 vs 류준)
C-6 배선이 두 벌이었다 (2026-09-14 해결) — 류준(PR #76, 전사 수신 안에서 탐지)과 장민석 님(server 브랜치, 콜 미디에이터가 POST /hub/call-guard-checks)이 같은 날 따로 만들었다. 둘 다 들어가면 같은 발화를 두 번 탐지·저장한다. 사용자 결정으로 장민석 님 방식을 남기고 류준 쪽을 걷어냈다 — 결과를 대시보드로 보낼 수 있는 쪽이다. 걷어낼 때 민석 님 브랜치 기준과 같은 모양으로 되돌려 머지 충돌이 코드에서 나지 않게 했다
E-3 곡선의 한계를 발표에서 어떻게 적을지 (신규, 2026-09-14) — 주입기는 실측 편집 81건 중 46.9% 를 흉내 내지 못한다 → 10-01 인용 문구 셋 확정(decisions/138) (환청·의미 붕괴 — 넣을 말을 지어내야 한다). 같은 WER 에서 실제 STT 보다 덜 파괴적이라 곡선은 낙관 쪽으로 기운다. 프로파일도 내국인 낭독 20발화 × 2조건이라 작다. 정할 것: ① 이 곡선을 성공 조건의 수치로 쓸지, 「상한」 으로만 쓸지 ② 실측 쌍을 늘릴지 (다산콜DB 로 Chirp 전사를 더 뽑으면 STT 비용이 든다 — COST-1). 곡선 측정 자체는 모델 학습 후 진행 예정
학습한 모델을 어디에·어떻게 올리는가 (신규, 2026-09-14) — 모델 학습은 정성윤 님이 SSH 로 개인 컴퓨터에서 돌리고 모델 파일만 업로드하기로 했다. 운영 AWS·CI 에서는 학습하지 않는다. 칸반의 「모델 학습 후 진행 예정」 카드(A-5·D-5·E-3)가 이 업로드를 기다린다. 정할 것: ① 업로드 위치(런북 9-2 — /mnt/scratch 는 인스턴스 중지 시 비므로 가중치를 두면 안 된다) ② 파일 이름에 넣을 버전 표기 — §5 규칙상 수치마다 「어느 모델로 쟀는지」가 남아야 하는데 eval_run 에 모델 버전 칸이 없다 ③ 학습 데이터·시드·명령을 어디에 기록할지(개인 PC 라 저장소에 흔적이 안 남는다 — 절대 원칙 2·8) ④ 모델 파일에 원본 데이터가 섞여 올라가지 않게 할 것(AI Hub 데이터는 커밋·공개 금지)
- → 닫음 (2026-09-21 보드 최신화, 정성윤): decisions/210(모델을 학습하지 않는다 — 데이터는 측정용)으로 전제가 사라졌다
D-5 를 누가 부르는가 (신규, 2026-09-14) — 저장 경로(VoiceOutlierRecordPort)는 있고 호출부가 없다. 톤 특징값은 오디오에서 → 10-01 안 부른다 — 시연 동작·수치 측정 불가(142·317) 나오는데 server/ 는 텍스트만 받는다. 정할 것: 콜 미디에이터가 발화별 특징값(F0 흔들림)을 전사와 함께 보낼지, 통화 종료 때 콜 미디에이터가 한 번에 보낼지. 콜 미디에이터(services/call-mediator)·§7.3 계약에 걸린다

frontend 브랜치를 main 에 합칠 때 — 조서희 님께 (2026-09-11, `decisions/109`)

services/call-mediator 가 두 벌이다 — main 쪽을 쓰고 frontend 쪽 것은 버린다. → 2026-09-11 정성윤이 직접 합쳤다(사용자 결정, 머지 ce7f525). 아래 ①~③ 그대로 했고 ④ 는 해당 없음. frontend 브랜치 자체는 고치지 않았다 — 조서희 님은 main 을 받으면 이 정리가 그대로 들어온다. 원래 적은 것 — 같은 날 조서희 님(decisions/402, 브라우저 음성 인식 dev 경로)과 정성윤(정식 A-1, 운영 배포)이 서로 모르고 같은 디렉터리에 콜 미디에이터를 만들었다. 합치면 README.md·package.json·package-lock.json 이 충돌한다. 402 의 쓸모는 main 콜 미디에이터로 옮겼다(decisions/109) — 운영 https://server.solidbob.cloud/call-mediator/dev 가 같은 테스트 페이지이고 (ngrok 필요 없음), /dashboard 경로도 그대로 받는다. 합칠 때 할 일: ① services/call-mediator/ 는 main 쪽을 고른다(git checkout origin/main -- services/call-mediator) — frontend 의 server.js·devPage.js·hubClient.js· dashboardHub.js·Dockerfile·.dockerignore·.gitignore 는 버린다(남으면 콜 미디에이터 이미지에 섞이고 릴리스 태그 검사가 막는다) ② apps/dashboard/src/lib/ws/types.ts 의 ?call_mediator= 덮어쓰기는 그대로 넣는다 — 정식 콜 미디에이터와 맞물린다. 운영 주소는 ?call_mediator= + encodeURIComponent("wss://server.solidbob.cloud/call-mediator/ws?token=<뷰 토큰>") (토큰 안에 & 는 없지만 인코딩해 두는 편이 안전하다) ③ decisions/402 머리에 «일부 대체됨 — 109» 를 적는다(콜 미디에이터 신설 부분). 대시보드 덮어쓰기 결정은 402 그대로 유효하다 ④ w3-gateway-dev-testcall 티켓은 그대로 done 이다 — 옮겨 온 쪽은 w4-gateway-dev-browser-stt
뷰 토큰을 대시보드에 어떻게 줄지 (신규, 2026-09-11) — ?call_mediator= 로 넣으면 localStorage 에 남고, Vercel env 로 넣으면 공개 번들에 들어간다. → 10-01 ?call_token= + 주소창 가림(09-28)으로 정착 — 닫는다 → 10-02 정정 — 위 꼬리말은 다른 토큰 이야기다. ?call_token= 은 입력(과금) 토큰이고, 이 항목이 물은 뷰 토큰은 지금도 Vercel 환경변수로 공개 번들에 들어 있다 — decisions/127(09-21)이 감수하기로 정한 것이다(마스킹된 자막 구독만 되고 쓰기 문은 401, 10-01 밤 확인) 둘 다 비밀이 아니다(무작위 스캔만 막는다). 사람별 인증이 생기기 전까지는 그 한계를 알고 쓴다. 뷰 토큰 값은 인스턴스에서 꺼낸다(secret.example.yaml ③) → 아래 「공개 데모를 라이브로 바꿀지」에 선택지를 정리했다.

공개 데모(`call.solidbob.cloud`)를 라이브로 바꿀지 — 조서희 님과 정할 것 (2026-09-11)

콜 미디에이터가 운영에 떴다(/call-mediator/health — 키·캡·토큰 둘 전부 true). 대시보드를 실제 콜 미디에이터에 붙이려면 Vercel 에 VITE_CALL_MEDIATOR_WS_URL=wss://server.solidbob.cloud/call-mediator/ws?token=<뷰 토큰> 을 넣고 재배포하면 된다 — 그런데 정성윤은 이 설정을 일부러 멈췄다. 기술 문제가 아니라 팀이 정할 일이라서다: 대시보드는 조서희 님 전담이고(decisions/302), decisions/109 도 «프론트는 건드리지 않는다» 고 적었다.

먼저 알아 둘 사실 (2026-09-11 코드·운영 확인)

대시보드의 실시간 자막·추천은 전부 콜 미디에이터 WebSocket 으로 온다. 필요한 빌드 변수는 VITE_CALL_MEDIATOR_WS_URL 하나다. VITE_CORE_API_URL 은 지금 헤더 REST 배지만 켠다(AppHeader.tsx) — 통화 기록(coreClient.ts)은 아직 mock 이다. 그래서 운영 서버의 CORS(call.solidbob.cloud → 지금 400)도 지금은 필요 없다. 통화 기록이 서버 REST 로 바뀔 때 넣는다
지금 배포된 번들에는 서버·콜 미디에이터 주소가 없다 → 가짜 시나리오(mock) 를 재생한다. 누가 열어도 자막·카드가 흐른다
라이브로 바꾸면 오디오를 보내는 쪽(생산자)이 있어야 화면에 뭔가 뜬다. 지금 생산자는 개발용 /call-mediator/dev(ingest 토큰 필요) 하나다
콜 미디에이터 허용 origin 은 https://call.solidbob.cloud · 로컬 Vite 뿐이다 — Vercel Preview(*.vercel.app)는 붙지 못한다

	방법	좋은 점	나쁜 점
A	공개 데모는 mock 그대로 · 라이브는 개발자가 `?call_mediator=<주소>` 로 자기 브라우저에서만	바꿀 것 없음. 공개 데모가 늘 돈다. 자막이 밖에 노출되지 않는다	방문자는 실제 동작을 못 본다. 뷰 토큰을 쓸 사람에게 따로 건넨다. ⚠ `?call_mediator=` 가 아무 주소나 받는다 — 아래 항목을 먼저 고쳐야 A 가 안전하다
B	Vercel Production 에 `VITE_CALL_MEDIATOR_WS_URL` (뷰 토큰 포함) → 재배포	주소만 열면 라이브. 시연 준비가 간단하다	① 생산자가 없으면 빈 화면 ② 번들이 공개라 주소를 아는 누구나 모든 통화의 (마스킹된) 자막을 본다 ③ EC2 가 꺼지면(자동 중지를 걸면) 멈춘다 ④ 토큰을 바꾸면 재배포
C	기본은 mock, 화면에서 「라이브 연결」을 골라 토큰을 사람이 입력	공개 데모도 살고 라이브도 쉽다. 토큰이 번들에 안 들어간다	프론트 코드 작업이 필요하다(조서희 님). 지금의 `?call_mediator=` 를 화면으로 올린 것에 가깝다

권고: 지금은 A — 단, ?call_mediator= 허용 목록을 먼저 고친 뒤에. 공개 데모를 망가뜨리지 않고 노출도 없으며, 라이브 확인은 ?call_mediator= 로 충분하다. 그런데 그 ?call_mediator= 에 지금 구멍이 있다(바로 아래 항목 — A/B 선택과 상관없이 이미 운영 번들에 있다). B 로 가는 조건 — ① 시연 때 오디오를 누가 어떻게 보낼지 정해졌다(/call-mediator/dev 등) ② 「주소를 아는 사람은 자막을 본다」를 팀이 받아들였다 (상담원 로그인은 서버에도 아직 없다 — 「서버에 인증이 없다」). 발표 시연만 라이브가 필요하면 그날만 B 로 바꿨다가 되돌리는 방법도 있다.

B 를 고르면 할 일 (정성윤 — Vercel 계정): 뷰 토큰 꺼내기(sudo k3s kubectl -n callguard get secret call-mediator-tokens -o jsonpath='{.data.CALL_MEDIATOR_VIEW_TOKEN}' | base64 -d, 32자 — 48자인 INGEST 는 절대 넣지 않는다) → call.solidbob.cloud 가 붙은 Vercel 프로젝트(call-solidbob-cloud-kxu6, Root Directory apps/call — 09-14 개명 반영) → Settings → Environment Variables → Production 만 → Deployments → Redeploy(VITE_ 는 빌드 때 박힌다) → 확인: 번들에 call-mediator/ws 가 들어갔는지 · 대시보드를 연 동안 /call-mediator/health 의 dashboards 가 1 이 되는지.

A / B / C 중 무엇으로 할지 — ✅ 2026-09-21 닫음 — 라이브로 둔다(_project/decisions/127). 09-17 에 Vercel 변수로 이미 B 가 돼 있었고 그 상태를 기록했다. 번들의 뷰 토큰은 마스킹된 자막 구독만 열고, 발화를 보내는 문과 STT 과금 문은 번들 밖이다. 원문 — 조서희 님(대시보드) · 정성윤(Vercel). 정하면 위 「뷰 토큰을 대시보드에 어떻게 줄지」와 함께 닫는다
⚠ ?call_mediator= 가 아무 WebSocket 주소나 받아 저장한다 — 운영 대시보드에 이미 떠 있었다 (신규, 2026-09-11 · 2026-09-14 해결) — apps/call/src/lib/ws/types.ts(옛 apps/dashboard) 가 ws://·wss:// 로 시작만 하면 받아 localStorage 에 남기고 있었다(PR #70 으로 배포, 운영 번들 index-ZZuCSHQN.js 에 callguard:callMediatorUrlOverride 확인). 그래서 call.solidbob.cloud/?call_mediator=wss://<남의 서버>/ws 링크 하나를 누른 브라우저는 ?call_mediator=clear 를 하기 전까지 그 서버에 붙고, 그 서버가 보내는 가짜 자막·「필요서류」 카드를 그대로 띄웠다. 상담원이 가짜 서류 안내를 믿고 고객에게 전하는 경로가 될 수 있었다(a5·33 세션 확인, bc 세션이 운영 번들로 재확인). 고친 것: ① isAllowedCallMediatorUrl() 허용 목록 — wss://server.solidbob.cloud/call-mediator/* 와 ws://localhost · ws://127.0.0.1(로컬 개발)만 받고 나머지는 조용히 버린다(서브도메인 스푸핑 server.solidbob.cloud.evil.com 같은 것도 정확한 hostname 비교라 걸린다) ② CallMediatorOverrideBanner.tsx — 덮어쓰기가 켜져 있는 동안 화면 상단에 붙은 주소 + 「연결 해제」 버튼을 보여준다. npm run typecheck && npm run build 통과 확인(사용자 지시로 조서희 진행).

배포하면 ES 가 매번 «configured» 로 나온다 (신규, 2026-09-11)

statefulset.apps/elasticsearch configured 가 모든 릴리스에 찍힌다 — ✅ 2026-09-23 확인 — 표시만 그렇다. 노드에서 kubectl diff -f current.yaml 을 돌리니 차이 0이고, elasticsearch-0 파드는 2026-09-08 생성 · 재시작 2회로 릴리스와 무관하다(오늘 세 번의 릴리스에도 그대로). apply 가 패치를 보내며 찍는 문구일 뿐 실제로 바뀌는 것이 없다. 원문 — elasticsearch.yaml 을 안 바꿔도 그렇다(릴리스 34580004558·34580734409· 34584307027 확인). 누가 클러스터를 손댄 흔적이 아니라 적용할 때마다 생기는 차이다(bc 세션 확인). 해는 없지만(검색 200, 인덱스 그대로) 진짜 변경이 생겨도 이 줄에 묻힌다. 추정: volumeClaimTemplates 에 서버가 기본값을 채우는 필드. 확인은 인스턴스에서 kubectl kustomize infra/k8s/base/ | sudo k3s kubectl diff -f - — 나온 필드를 매니페스트에 적어 두면 사라진다

릴리스 태그 게이트를 고치며 남은 것 (2026-09-14, `decisions/111`)

~~룰셋에 tag-check·call-mediator 를 필수 통과 검사로 등록~~ — 2026-09-15 완료. 룰셋(21538648)의 필수 검사가 jekyll·ai·server → + call-mediator·tag-check 로 다섯이 됐다. 나머지 규칙(deletion·non_fast_forward·pull_request·strict: true·승인 0건)은 그대로다. 이제 server/·ai/ 를 고치면서 newTag 를 안 올리면 머지 버튼이 잠긴다(전에는 빨간 X 만 떴다).
.github/branch-protection.json 을 라이브 룰셋에 맞췄다 (2026-09-15, 정성윤) — 값 셋을 고쳤다: contexts 셋 → 다섯(call-mediator·tag-check 추가) · 승인 1 → 0 · enforce_admins false → true(라이브 bypass_actors: [] = 우회 없음에 대응). 파일을 지우지 않은 이유: decisions/011 이 «룰셋을 걷어내고 클래식으로 돌아갈 때를 위해 남겨 둔다»로 정해뒀다. 목적이 대비본이므로 값이 어긋나 있으면 되돌리는 순간 정책이 조용히 바뀐다 — 그게 이 항목의 위험이었다. ⚠ 형식이 다르다는 건 남는다 — 이 파일은 클래식 보호 API(branches/main/protection) 형식이고 라이브는 룰셋 API(21538648)다. 클래식에 대응물이 없는 라이브 설정 둘은 못 담았다: require_extra_approval_for_unattributed_changes: true · allowed_merge_methods. 룰셋 백업은 이미 있었고, 그것도 어긋나 있었다 — .github/ruleset-main.json 은 22c7983 에 들어와 있었는데 contexts 가 셋인 옛 판이었다(같은 병). 2026-09-15 에 라이브 룰셋(21538648)에서 읽기 전용 필드 8개를 걷어낸 복원본이다(PUT --input 으로 그대로 되살아난다). 쓰기 가능 필드 여섯이 라이브와 한 글자도 다르지 않음을 대조 확인했다. 뜨고 되살리는 명령은 CLAUDE.md §7. ⚠ 룰셋을 고칠 때 이 파일을 같이 갱신하지 않으면 다시 어긋난다 — 그게 이 항목이 생긴 경위다.
OIDC 신뢰 정책 — 확인했다. 유효하다 (2026-09-15, 정성윤) — callguard-deploy-role 의 신뢰 정책은 실제로 main 한정이다. release.yml 주석 ④ 가 맞았다. sub = repo:SeongYuna@280208914/call.solidbob.cloud@1344602683:ref:refs/heads/main — 이름이 아니라 계정·저장소의 숫자 ID 가 박힌 형태다(gh api repos/... 로 owner_id·repo_id 대조 확인). 저장소 이름을 바꾸거나 같은 이름으로 새로 만들어도 사칭되지 않아 이름만 쓰는 것보다 강하다. 함께 본 것 — ① StringLike 지만 값에 * 가 없어 사실상 정확 일치 ② aud 는 sts.amazonaws.com 고정 ③ GitHub OIDC 공급자를 신뢰하는 역할은 이것 하나뿐이다(전 역할 전수 조사) ④ 오늘 05:33 에 실제로 쓰였다 — 릴리스 #90 의 k3s-deploy → 「AWS 자격증명(OIDC)」 success. #54·#55 의 거부는 역할 생성(09-09 04:37) 직후 과도기였다. 그래서 「release.yml 에 pull_request 를 더하면 머지 안 된 코드가 운영에 배포된다」는 성립하지 않는다 — OIDC 스텝에서 죽는다. 다만 이미지 push 는 AWS 를 거치지 않아 그대로 남는다(DOCKERHUB_* 만 쓴다). 그쪽은 판정만 하는 tag-check.yml 을 따로 뗀 것으로 이미 닫혀 있다(decisions/111). ⑤ 왜 ID 형태인지 확인했다 (덧붙임, 2026-09-15) — 커스텀 템플릿이 아니라 GitHub 기본값이다: gh api repos/SeongYuna/call.solidbob.cloud/actions/oidc/customization/sub → {"use_default": true, "use_immutable_subject": true, "sub_claim_prefix": "repo:SeongYuna@…/call.solidbob.cloud@…"}. use_immutable_subject 가 켜져 있어 이름 대신 ID 가 박힌다. ⚠ 그래서 이 토글을 끄면 배포가 전부 깨진다 — sub 가 이름 형태(repo:SeongYuna/call.solidbob.cloud:ref:…)로 돌아가는데 신뢰 정책은 ID 형태로 고정돼 있어 더는 일치하지 않는다. 증상은 #54·#55 와 똑같은 Not authorized to perform sts:AssumeRoleWithWebIdentity 라 원인을 찾기 어렵다. 끄지 않는다. 덧붙여 신뢰 정책은 저장소 어디에도 코드로 없다(terraform 포함 — 전수 확인). AWS 콘솔에만 있으므로 역할을 잃으면 정책 원문도 같이 사라진다.
~~ES 이미지는 CI 가 굽지 않는다~~ — 2026-09-15 자동화했다 (decisions/114). release.yml 의 paths 에 infra/elasticsearch/** 를 넣고 es-image 잡을 만들었고, 태그 게이트 (check_release_tags.py 의 IMAGES)에도 es 를 추가했다. 두 갈래가 다 닫혔다. ⚠ ES 태그는 ES 버전을 따라간다(Dockerfile 의 ARG ES_VERSION). Dockerfile 만 고치고 버전은 그대로일 때는 빌드 접미사를 붙인다 — 예: 9.5.1-2. 같은 태그로 다시 구우면 노드가 캐시를 계속 쓴다.
~~converge.sh 가 콜 미디에이터 롤아웃을 보지 않는다~~ — 2026-09-15 한 줄 추가했다 (decisions/114). rollout status deploy/callguard-call-mediator 를 더해 부팅 경로도 릴리스 배포와 같은 것을 본다.
~~test.yml 이 같은 SHA 에 검사를 2벌 단다~~ — 2026-09-15 트리거를 좁혔다 (decisions/114). push.branches 를 [main] 으로 바꿨다. concurrency 를 합치는 「싼 수정」은 쓰지 않았다 — 두 런이 같은 SHA 에 같은 이름으로 check-run 을 보고해서, 취소된 쪽이 나중에 기록되면 필수 검사가 cancelled 로 남아 머지가 막힌다(필수 검사가 다섯이 된 지금은 더 위험하다). ⚠ 잃은 것 하나 — 「PR 없이 브랜치에만 push 했을 때」는 CI 가 돌지 않는다. PR 이 열려 있으면 push 마다 pull_request 가 돈다. 일찍 보고 싶으면 초안 PR을 연다. 불편하면 되돌릴 수 있다(중복도 같이 돌아온다).
~~운영 이미지에 테스트가 실린다~~ — 2026-09-15 .dockerignore 로 뺐다 (decisions/114). **/tests · **/conftest.py · **/pytest.ini · **/.importlinter · ai/apps/evaluation 추가. ai/apps/call_guard·voice_signal 은 남겼다 — C-6·D-5 가 꽂힐 자리라 빼면 나중에 꽂는 사람이 로컬에선 되는데 운영에서만 ImportError 로 헤맨다. 같이 한 것: 안전망을 넓혔다. server/tests/test_image_layout.py 는 Dockerfile 의 COPY 만 읽어서 COPY ai/apps/ 가 그대로여도 .dockerignore 가 그 안을 빼면 테스트는 초록인데 이미지엔 없다. _ignored_by() 를 더해 .dockerignore 도 함께 보게 했다.

운영 스키마가 배포보다 늦게 따라간다 (신규, 2026-09-14)

「머지 = 배포」인데 스키마는 사람 손이라 구조적으로 뒤따라간다 — ✅ 2026-09-23 구조로 막았다 — decisions/128 의 배포 전 스키마 대조가 릴리스 워크플로에 들어갔고(w6-deploy-schema-precheck), 어긋나면 SSM 적용 전에 멈춘다. 오늘 네 번의 릴리스에서 전부 「어긋남 0 — 29 테이블 · 200 컬럼」으로 초록이었다. 사람이 마이그레이션을 잊어도 배포가 먼저 서는 구조다. 원문 — ⚠ 2026-09-22 또 났다: PR #111 머지로 server 0.1.25 가 10:26 KST 에 먼저 배포됐고 2026-09-22-blacklist-request-note-unmeasured.sql 은 10:37 KST 에 넣었다(_logs/2026-09-22-05-seongyun) — 그 11분은 블랙리스트 요청 경로가 500, /health 는 ok. decisions/128 이 구현 전이라 못 막았다. 넣은 뒤 29 테이블 199 컬럼 어긋남 0. ◐ 2026-09-21 방식을 정했다 — 구현은 남았다(_project/decisions/128): 릴리스 워크플로가 적용 전에 SSM 으로 대조하고 어긋나면 멈춘다(w6-deploy-schema-precheck). 원문 — ⚠ 구조적 위험은 그대로 열려 있다. 다만 2026-09-20 현재 «실제로 어긋난 것은 없다» — 운영 DB 와 db/schema.sql 을 컬럼 단위로 대조해 29 테이블 198 컬럼, 타입·길이·NULL 여부까지 어긋남 0 을 확인했다(scripts/compare_prod_schema.py 신설 — 일부러 어긋나게 만든 사본으로 탐지되는지 먼저 검증했다. 지금까지 대조는 테이블 「이름」까지였다). 배포마다 이 대조를 돌리면 구멍이 드러난다. 원문 — 09-14 에 실제로 났다. PR #79 머지 → release.yml 자동 → server 0.1.5 가 06:33 배포됐는데 운영 DB 는 22 테이블(fd96adc, 09-09) 이었다. 런북 19장이 「이미지를 올리기 전에 스키마를 넣는다」고 적어 뒀지만 사람이 끼어들 지점이 없다. ⚠ /health 는 이 상태에서도 ok 다(0.1.5 기대 출력과 일치) — 배포 판정으로는 안 드러나고 발신 번호 있는 통화 시작·F-2 저장·관리자 로그인만 500 이었다. 정할 것: tag-check.yml(PR 전용, 이미지를 굽지 않는다)에 스키마 선행 확인을 붙일지. 붙인다면 무엇으로 보나 — ① db/migrations/ 에 새 파일이 있으면 「적용했는가」를 묻는 체크박스 ② schema.sql 의 CREATE TABLE 수와 운영 조회값 비교(운영 접근이 CI 에 필요해진다 — 반대급부가 크다). ①이 싸고, ②는 자격증명을 CI 에 들이는 값이 든다.
admin_account 행이 비어 있다 (2026-09-14) — 넣기 전까지 블랙리스트 승인·해제가 409. → 닫힘 (2026-09-15) — 행 1건을 넣었다(2026-09-15). agent_id 는 아직 NULL 이라 승인·해제 409 는 그대로다 — 295행 항목이 이어받는다. 회원가입 화면이 없어 운영자가 SQL 로 넣고 agent_id 를 채운다. CUSTOMER_REF_HMAC_KEY 는 09-14 에 넣었다.
런북 8장의 SSH 키 이름이 실물과 다르다 (2026-09-14) — ✅ 2026-09-23 대조 완료 — 런북의 「실물 대조」 표가 assist-key → callguard-key 로 이미 정정해 두었고, AWS 실물(aws ec2 describe-key-pairs)도 callguard-key 다. 원문 — 런북은 ~/.ssh/assist-key.pem 인데 그런 파일이 없다(있는 것은 callguard-key.pem·admin-keypair.pem). 09-14 에 고친 IAM 역할·S3 버킷 이름과 같은 부류다. 맞는 키를 아는 사람이 런북을 고친다 — 이름을 추측해서 적지 않는다.

5~8주차 티켓을 미리 만들었다 — 담당자는 «제안»이다 (신규, 2026-09-15)

27건의 assignee 를 본인들이 확인해야 한다. 8주 마일스톤 로드맵과 → 10-01 09-16 부터 정성윤이 전부 수행(137) — 닫는다 STATE.md 「지금 막혀 있는 것」·미결 항목을 티켓으로 옮기면서 4~8주차를 한 번에 만들었는데, 담당자는 기획서 7.1절 역할표와 주 담당 디렉터리를 따라 적은 것이지 본인이 가져간 것이 아니다. §4 는 “assignee 는 실제로 손대는 사람”이라고 정하고 있으므로, 착수할 때 본인이 고치는 것을 전제로 둔다. ⚠ 특히 류준 16건으로 쏠렸다 — ai/ 가 4~6주차 로드맵의 대부분이라 그렇게 됐지만, decisions/302 로 디렉터리 잠금이 풀렸으니 나눠 가질 수 있다. 나눌지는 본인들이 정한다.
4주차 로드맵 목표에 티켓이 하나도 없었다 — 4주차는 「nori · dense_vector · RRF · 청킹 3종 비교」인데 → 10-01 로드맵은 그대로 두고 실제 진행은 진행 기록이 정본 — 닫는다(w8-final-docs) → 10-02 정정 — 로드맵의 4주차 과제 넷은 09-15 에 전부 쟀다(w4-chunking-compare · w4-dense-vector-index · w4-reranker · w4-rrf-hybrid, 전부 done). 어긋난 것은 주차 표기뿐이다 w4- 티켓 27건 중 해당하는 것이 0건이었다. 4주차에 실제로 한 일(콜 미디에이터·블랙리스트·관리자 로그인· 배포·스키마)은 전부 로드맵에 없던 일이고, 로드맵에 적힌 일에는 티켓이 없었다. 정할 것: 로드맵을 실제 진행에 맞춰 고칠지(docs/08 수정), 아니면 4주차 검색 품질을 5주차로 미룰지. 지금은 티켓만 만들어 두고 주차는 로드맵 그대로 뒀다 — 미루는 판단은 팀 몫이다.

배포 확인용 프로브 — 걷어냈다 (2026-09-15 닫음)

~~GET /admin/auth/test 를 언제 걷어내나~~ — 09-15 지웠다. ① 그냥 지우기를 택했다 (티켓). 넣은 목적(「server 를 고쳐 머지하면 운영 /openapi.json 이 실제로 바뀌는가」)은 같은 날 완주해서 다 썼고, ②(상시 유지)로 가려면 «무엇을 보장하는 엔드포인트인지»를 먼저 정해야 하는데 그 답이 /health 와 겹친다. 이름이 test 인 채로 남기지 않는다는 것이 이 항목을 연 이유였다.
배포됐다는 것을 «태그» 로 확인할 방법이 없다 — ✅ 길이 생겼다 (2026-09-19) — ssm send-command 로 kubectl get deploy -o custom-columns=…image 를 돌려 운영 이미지 태그를 직접 본다(릴리스 워크플로와 같은 통로라 포트를 열지 않는다). 09-19 실측: callguard-server:0.1.18 · callguard-call-mediator:0.2.1. ⚠ 여전히 밖(공개 GET)에서는 안 보인다 — /openapi.json 의 version 은 코드에 박힌 0.1.0 이다. 원문 — ** — 프로브를 걷어내면서 다시 열린 채로 남는다. 프로브의 marker 는 사람이 손으로 올리는 문자열이라 애초에 못 미더웠고(올리는 걸 잊으면 옛 값이 그대로 나간다), 그마저 없어졌다. FastAPI app.version 도 0.1.0 에 고정돼 kustomization.yaml 의 newTag 와 무관하다. 지금 어느 이미지가 도는지는 클러스터 안에서만 알 수 있다 (kubectl -n callguard get deploy/callguard-server -o jsonpath='{..image}'). 정할 것: 빌드 시점에 이미지 태그를 넣어(--build-arg → 환경변수 → /health) 응답으로 알 수 있게 할지. 그러면 server/core/config.py 와 secret.example.yaml 이 같이 움직인다(런북 16-1).

`w4-dashboard-live-contract` 로 드러난 계약 구멍 셋 (신규, 2026-09-15)

카드 피드백(POST /hub/cards/{id}/feedback)을 부를 방법이 없다 → 같은 날 장민석이 풀었다(decisions/308 — 추천 카드에 card_id 추가, 아래 섹션 참고). → 2026-09-15 조서희가 마저 처리 — coreClient.ts의 submitCardFeedback을 문자열 타입으로 정정(아래 「프론트 수정 5건」 ③과 같은 항목). → 2026-09-16 조서희가 화면에 연결 — callStore.ts의 toggleAdoption이 채택 토글을 낙관적으로 먼저 바꾼 뒤 card.card_id가 있으면(서버에 저장된 카드) submitCardFeedback을 best-effort로 부른다. cardId()(로컬 dedup 키)와 서버 card_id는 다른 값이라 후자만 쓴다. 실패해도 채택 표시는 그대로 둔다(조용히 넘어간다).
상담기록(통화 재생) 화면을 실제 API로 못 바꾼다 — apps/call의 “상담기록”은 지금 카드·종결·감정분석까지 통째로 재생하는 mock 시나리오(mock/callHistory.ts) 기반인데, 실제 API(GET /hub/calls·GET /hub/calls/{id}/transcript)는 통화 목록+자막만 준다 — 카드·종결·감정분석 재조회 엔드포인트가 없다. REST 함수(fetchCallList· fetchCallTranscript)는 만들어 뒀다. → 같은 날 장민석이 GET /hub/calls/{id}/record를 만들었다(아래 섹션 참고, 감정분석은 모델이 없어 빈 채로). 화면 연결은 아직. → 2026-09-15 조서희가 재설계·연결 — 코드를 보다가 historyCards·historySegments 등 인라인 자막 재생용 상태가 TranscriptPanel·TermsPanel에 이미 있는데 App.tsx의 showSummary(viewMode === "history"면 무조건 요약 화면으로 이동)에 가려 실제로는 절대 렌더링되지 않는 죽은 코드였던 걸 발견했다(.claude/rules/call.md가 적어 둔 “왼쪽 자막 패널이 그 기록을 보여준다”는 설계와 실제 동작이 어긋나 있었다). 사용자 지시 (“둘 다 살리는 방향으로”)에 따라 죽이지 않고 요약 보기·자막 보기 두 화면을 오가는 토글로 되살렸다 — historyView: "record" | "transcript"(신규) 상태를 추가하고 App.tsx의 showSummary를 phase === "wrapup" || (viewMode === "history" && historyView === "record")로 좁혔다. openHistory가 실 API 설정 시 fetchCallTranscript + fetchCallRecord(신규, coreClient.ts)를 병렬로 불러 historySegments·historyCards를 채운다 — 카드/판정은 실제 계약이 서로 다른 배열(recommendations[].cards[] vs closures[])이라 mock처럼 “카드 하나에 판정 하나”가 아니다: 실 카드는 판정 없이 그대로, 판정마다 표시용 카드를 하나 따로 만든다(panelCardsFromRecord). 번역·TTS· 콜가드·악센트 힌트 재생은 실서버에 애초에 없어 항상 빈 채로 둔다(정직하게 — 지어내지 않는다). CallHistoryPanel(목록)도 실 API 분기 추가(GET /hub/calls, “다시 재생”은 mock 전용이라 뺐다). 카드 채택 토글은 상담기록 조회 중엔 숨김(채택 기록이 state.callId — 실시간 통화 — 에 귀속돼 엉뚱한 통화에 붙는 걸 막는다). 확정된 요약이면 “요약 확정” 폼이 잠긴 채 열려 곧바로 재수정할 수 있다(historyConfirmed prop). 버그 하나 잡음: 대기화면의 「최근 상담기록」에서 열면 shell이 standby로 남아 있어 자막 보기로 전환하는 순간 대기화면이 대신 떴다 — openHistory가 shell: "assist"도 같이 정하도록 고쳤다. 헤드리스 크롬 + CDP로 mock 모드 왕복(목록→요약→자막→요약→실시간 복귀) 스크린샷 확인, 콘솔 에러 없음. apps/call tsc --noEmit·vite build 클린.
관리자 “지식베이스 갭” 화면이 실제 계약과 모양이 다르다 — 화면(KnowledgeGapTab.tsx)은 지금 {call_id, query, found}(상담원이 직접 검색해 못 찾은 질의) 기준으로 묶어 세는데, 실제 GET /hub/knowledge-gaps 계약은 {module: B|C|F, description, status: open|resolved} (더 넓은 D-4 공백 개념)라 필드가 아예 다르다 — 이름만 바꿔서 옮길 수 없다. REST 함수 (hubClient.ts의 fetchKnowledgeGaps)는 만들어 뒀지만 화면엔 안 붙였다. → 2026-09-16 조서희가 재설계·연결 — “질의 그룹핑 랭킹”에서 “module 뱃지(B/C/F) + 설명 + 열림/해제됨 필터 + 해제·다시 열기 버튼” 목록으로 다시 짰다. hubClient.ts에 resolveKnowledgeGap(PATCH /hub/knowledge-gaps/{gap_id})을 추가하고 adminStore.ts의 loadAll이 실제 목록을 받는다. mock(SEED_KNOWLEDGE_GAP_LOG, KnowledgeGapEntry)은 걷어냈다.

통화 후 초안 · 상담원 토큰에서 남은 것 (신규, 2026-09-15, 장민석)

운영 DB 에 저장소에 없는 테이블이 하나 있다 — 오인이었다. 닫는다 (2026-09-15, 정성윤)

blacklist_entry_expiry_change 가 저장소에 없다고 적었으나 틀렸다. decisions/309(장민석, 09-15)가 정한 정식 테이블이고 db/schema.sql 에 29개 중 하나로 들어 있다. 다섯 브랜치 전부에 있다. 행이 0인 것도 정상이다 — 관리자 만료 연장·단축(POST /hub/blacklist-entries/{id}/expiry)을 아직 아무도 쓰지 않았을 뿐이다. 지우지 않는다.

왜 틀렸나 — 남겨 둘 값어치가 있다. 검색을 돌린 시점의 작업 트리가 PR #90 이전이었다. git pull --ff-only 출력을 tail -1 로 삼켜 실패를 못 보고, 그 상태에서 「전수 검색 0건」이라고 단정했다. 브랜치를 따로 보지도 않았다(git grep <ref> 로 다섯 브랜치를 봤으면 바로 나왔다). 교훈: 「저장소에 없다」를 말하기 전에 ① 트리가 최신인지 ② 다른 브랜치는 봤는지 둘을 먼저 확인한다. 드리프트 방향이 「운영에만 있다」로 보일 때는 대개 내 트리가 낡은 것이다.

Vercel 설정이 콘솔에만 있다 (신규, 2026-09-15, 정성윤)

프론트 3종의 Vercel 설정을 vercel.json 으로 저장소에 옮길지 — ✅ 안 옮긴다 — 2026-09-22 결정대로 Vercel 프로젝트 설정에서 직접 껐다(w6-vercel-json-branch-deploys). 09-23 확인: 저장소에 vercel.json 0개. ⚠ 설정이 저장소에 없으므로 프로젝트를 새로 만들면 다시 해야 한다 — 런북 18-4 에 한 줄이 남아 있다. 원문 — 지금은 Root Directory · 빌드 명령 · 환경변수 · Ignored Build Step 이 전부 콘솔에만 있고, 저장소 쪽 기록은 런북 18-4 표 하나다. 같은 날 branch-protection.json·ruleset-main.json 이 어긋나 있던 것과 같은 구조다 — 콘솔만 바뀌고 저장소는 모른다. 옮기면 apps/<앱>/vercel.json 의 ignoreCommand 인데 apps/ 는 조서희 전담이라 혼자 정할 수 없다(CLAUDE.md §1 — 전담이 남는 유일한 영역). 정할 것: ① 콘솔 유지 + 런북 18-4 를 정본으로(지금) ② vercel.json 으로 옮기고 런북은 가리키기만. ⚠ ② 를 고르면 Root Directory 는 여전히 콘솔에만 남는다(vercel.json 이 그 안에 있어서 읽히는 구조다).
Root Directory 셋이 실제 폴더와 맞는지 눈으로 확인 — 어긋나면 Ignored Build Step 의 git diff 가 → 10-01 09-22 대조 완료(런북 18-4) — 닫는다 항상 비어 빌드가 영원히 건너뛰어진다(빨간불이 아니라 조용한 초록). 09-14 apps/dashboard → apps/call 개명이 있었고 위 뷰 토큰 항목에도 옛 경로가 적혀 있었다(이번에 고쳤다). 확인법은 런북 18-4.
Ignored Build Step 으로는 배포 한도를 못 막는다 — vercel.json git.deploymentEnabled 가 필요하다 (신규, 2026-09-22, 정성윤) — ✅ 09-22 정성윤이 파일 대신 Vercel 프로젝트 설정에서 직접 막았다(w6-vercel-json-branch-deploys done — 설정은 저장소 밖이라 프로젝트를 새로 만들면 다시 한다). 원문 — 09-22 다시 한도에 걸렸다(api-deployments-free-per-day 100 · 24시간에 147건 생성). 취소된 빌드도 배포 1건으로 센다. 줄이는 길은 Root Directory 안 vercel.json 에 {"git":{"deploymentEnabled":{"PM":false,"ai":false,"server":false}}} 를 두는 것뿐이다(main·frontend 만 남겨 147 → 76). apps/call·apps/admin·apps/platform 셋에 같은 파일 — apps/ 가 조서희 전담이라 여기서 정한다. 정할 것: ① 조서희 님이 frontend 에 넣는다 ② 정성윤이 넣고 조서희 님이 확인한다. 그때까지 운영 상담원·관리자 화면은 a5450d8(PR #120) 에 멈춰 있고, 해제는 09-23 13:38 KST(런북 18-4 에 명령).

합성 통화 대본 · 학습 방향에서 남은 것 (신규, 2026-09-16, 류준)

모델을 학습하지 않는다면 — 결정 기록과 티켓 정리 — ✅ 2026-09-18 _project/decisions/210 으로 채택·정리(①②③ 완료 — 티켓 메모를 실제 막힘으로, w5-classifier-ner-benchmark 는 「측정 불가」로 닫음). ④ ai/apps/training/ 은 지우지 않았다 — 보관·이동 방향은 아직 미정. S3 경로는 여전히 정성윤 님 확인. 원문 — 류준 메모(확정 아님): “모델을 따로 학습시키지 않고, 데이터는 S3 에 올려 정확도 측정용으로만 쓸 것 같다.” 확정되면 ① 결정 기록 2xx ② w3-a5-translation-spike·w3-call-temperature 의 「모델 학습 후 진행」 메모를 실제 막힘(AI Hub 505/71479 미신청 · 음성 골든셋 없음)으로 고침 ③ 파인튜닝 전제인 w5-classifier-ner-benchmark 를 「측정 불가 — 학습 안 함」으로 닫음(지우지 않는다) ④ ai/apps/training/ 처리. S3 버킷·경로는 정성윤 님 확인 — AI Hub 재배포 금지라 비공개여야 한다
합성 통화(scripts/persona_sim/ · 재생기 services/call-mediator/scripts/replay_persona_call.ts)를 채택할지 — 결정 기록 없음 — ✅ 2026-09-18 _project/decisions/209(제안): ① 데모·파이프라인 점검 전용 ② 발표에 쓰면 source: synthetic+「STT 미경유 상한」 ③ say 기본 + Google TTS Wavenet 파일 캐시 ④ 공개 저장소에 둔다(가짜 값, 폭언은 추가하지 않는다). 원문 — 대본 10건 초안이 있다(w5-persona-sim-scripts). 정할 것: ① 용도를 데모·파이프라인 점검으로 한정할지(권고) ② 합성 수치를 발표에 쓸지 — 쓴다면 source: synthetic 분리 + 「STT 미경유 상한」 명시 ③ 재생 음성을 브라우저 TTS(무료)로 할지 Google TTS 파일 캐시로 할지 ④ 대본 JSON 을 공개 저장소에 두는 것 — 가짜 값뿐이지만 폭언·성적 표현 문장이 들어 있다
QA 페르소나가 현재 마스킹·콜 가드 규칙을 합성 대본에 돌려 찾은 것 — 장민석 님·류준 (신규, 2026-09-16) — 대본이 아니라 규칙 쪽 문제라 대본을 규칙에 맞추지 않았다(scripts/persona_sim/README.md). ⚠ 서브에이전트가 로컬에서 돌린 결과이고 하네스 측정값이 아니다 — 수치로 옮기지 말고 재현부터 한다. → 10-01 재현 안 함 — 범위 밖(138) → 10-02 정정 — 「재현 안 함」 이 아니다. 아래 ✅ 대로 ①②③ 은 09-17 에 고쳐졌고, 10-01 밤 지금 규칙(NER 없이, 로컬 재현 — 하네스 측정 아님)으로 다시 돌려 확인했다: 보고된 과잉 4건 · 번지·호수 4건 · 「박성호요」「김도윤이고요」「응우옌 티 란」 · 「멍청한 놈」「목소리만 예뻐」「다 끝내고 싶어요」 ✅. 남은 것 넷: 「김도윤 고객님이세요」 · 「제니 레예스 입니다」(P6 누락, 규칙만 기준) · 「이따위로」 · 「술이나 한잔」(C-6 사전에 없음) ✅ 09-17 ①②③ 해소(④ 중 distress·성적 표현·모독은 같은 날 C-6 규칙에 반영) ① P7 과잉 마스킹이 정상 대조군을 깬다 — _AREA_LOCAL 이 「하시면」의 면, _ROAD 가 「~으로」의 로 를 주소 표지로 본다고 보고됐다(SYN-001 「신분증으로 하시면」 외 8턴). 09-15 「주민센터로 가시면」 과잉 마스킹과 같은 뿌리로 보인다 ② P7 번지·호수가 남는다 — 「새솔로 12, 305호」·「은하로 7-3」에서 숫자 건물번호가 안 잡혀 주소가 도로명에서 끊긴다(누락 — 절대 규칙 쪽) ③ P6 문맥 없는 이름(「박성호요」·「한지영이요」) · 조사 「이고요」 · 띄어 쓴 외국인 이름(「응우옌 티 란」→「응우옌」만) 누락 ④ C-6 사전에 없는 표현 — 「멍청한 놈」·「이따위로」·「술이나 한잔」, 「목소리만 예뻐」(「만」이 패턴을 끊음), distress 「다 끝내고 싶어요」 정할 것: 합성 대본을 하네스에 source: synthetic 으로 올려 이 넷을 회귀 표본으로 쓸지 — ✅ 2026-09-18 결정: 올리지 않는다. 하네스는 실제·작성 골든셋만 잰다. 합성 대본의 회귀 검사는 scripts/persona_sim/e2e_check.py(왕복 검사, source: synthetic 보고서)가 맡는다

09-17 운영 점검·로컬 E2E 에서 넘긴 것 — 팀원별 (신규, 2026-09-17, 류준)

페르소나 4명 점검 결과. 류준 몫은 w5-e2e-findings-ai에서 고쳤다. ⚠ E2E 는 로컬(규칙·BM25, NER·임베딩 없음 — 운영과 같은 구성) 결과다.

C-5 규칙 보강에서 남은 것 (신규, 2026-09-17, 류준 — 주 담당 장민석)

w5-c5-masking-gaps에서 이름·번지 누락과 과잉 마스킹을 함께 고쳤다. 남은 것:

장민석 님 검토 — 주 담당 영역을 류준이 고쳤다. 특히 name_detector.py 의 네 갈래(문맥·자기소개·호칭·이름만 답한 발화)와 _NOT_NAMES 목록이 실제 발화에서 걸린 것만 넣었는지
- → 닫음 (2026-09-22 장민석): w5-server-change-review(0.1.14→0.1.24) 범위(0.1.15) — 봤고 그대로 둔다
호칭·문맥이 전혀 없는 이름은 여전히 못 잡는다("김민준 그 사람이") — 규칙의 한계. NER 운영(decisions/208)이 풀 몫이다. 테스트가 한계를 고정해 두었다 → 10-01 한계 문구로 발표(138) — 닫는다
실제 발화의 남은 P7 과잉은 1건짜리들이다(「경기 침체로」·「3층 일자리」·「서울시 누수감면」 등) — 누락 0건 > 과잉 억제라 여기서 멈췄다. 자막 가독성 문제가 보고되면 같은 방식(실제 문장을 테스트로 고정 → 규칙)으로 줄인다 → 10-01 그대로 둔다(누락 0 > 과잉 억제) — 닫는다
이 측정은 라벨이 없다 — AI Hub 발화에서 「가려진 발화 수」 가 459 → 44 로 줄었다는 것은 과잉이 줄었다는 근거이지 누락이 없다는 근거가 아니다. 누락은 골든셋·합성 대본(라벨 있음)으로만 말한다 → 10-01 인용하지 않는다 — 닫는다

프론트 왕복 테스트로 드러난 것 셋 (신규, 2026-09-17, 정성윤)

홍보 페이지·상담원 박스가 통화 ID 를 각자 만든다 — 조서희 님과 정할 것 — ✅ 2026-09-22 진입 경로(UI)까지 마무리됐다(a9e9642, LiveCallModal.tsx의 “상담원 링크 복사” 버튼 — w6-shared-call-entry, 2026-09-23 확인). ◐ 2026-09-21 로직은 고쳤다 — 진입 경로(UI)는 남았다. 두 화면이 ?call_id= 를 읽어 같은 통화로 붙는다(apps/call·apps/platform 의 lib/sharedCallId.ts — 비밀이 아니라 URL 에서만 읽고 저장하지 않는다. 없으면 예전처럼 각자 만든다). 상담원 화면은 그 ID 로 그 통화만 구독한다(WS /ws?call_id= — 콜 미디에이터가 원래 지원하던 서버 쪽 필터를 안 쓰고 있었다). 타입 체크·두 앱 빌드 통과, 순수 함수는 node 로 11건 확인. 화면·디자인은 건드리지 않았다. 남은 것: 홍보 페이지의 「상담원에게 전화 걸기」가 상담원 화면을 같은 call_id 로 열어 주는 것 — 버튼 동작이 바뀌는 일이라 하지 않았다. 지금은 두 주소에 같은 ?call_id=test-… 를 붙여 직접 연다. 원문 — apps/platform/src/lib/useLiveCallSession.ts:118(test-web-platform-*) · apps/call/src/lib/useAgentCallSession.ts:128(test-web-agent-*). 콜 미디에이터는 두 통화로 갈라 /hub/calls 를 두 번 부르고, 상담원 화면은 call_id 없이 구독해 둘 다 받으며, callStore.applyTranscript 가 call_id 대조 없이 segment_id 만으로 덮어쓴다(콜 미디에이터는 통화마다 1번부터 센다). 실제 프론트 코드로 재현: 고객 1번 줄이 상담원 1번 줄에 덮여 사라지고 callId 가 메시지마다 바뀐다. 같은 ID 를 넘기면 순서대로 남는다(09-17 두 번째 기록). 콜 미디에이터·서버 계약은 손댈 것 없음. 정할 것: 홍보 페이지가 만든 ID 를 상담원 화면에 넘겨 같은 값으로 붙게 하고(새 탭 + 쿼리), 상담원 화면은 그 ID 로 구독하거나 스토어에서 다른 ID 를 버린다 — 티켓 미작성
못 읽는 콜 미디에이터 메시지 하나가 「연결 끊김」 표시를 만든다 (조서희 님) — ✅ 2026-09-21 고쳤다 — callStore.setError 가 connected:false 를 같이 세우던 것을 걷었다. 연결 상태는 setStatus 만 바꾼다(진짜 끊김은 소켓 close 가 알린다 — realCallMediatorClient.ts). 오류 문구가 뜨는 자리·모양은 그대로다. 원문 — callStore.setError 가 connected:false 를 같이 세운다. 소켓은 열려 있고 이후 자막도 계속 들어오는데 화면은 끊김으로 보인다. 파서 실패와 연결 상태를 분리할지 정한다
GS-204 는 측정이 아니라 채점 기준 문제 — 결정 기록 필요 (류준 님과) — ✅ 2026-09-21 결정: 라벨을 고치지 않고 출제 규약을 적는다(_project/decisions/123). 「시민이 묻는 말이면 지침(TERM) 쪽이 정답, 같은 내용의 매뉴얼 조항은 방해 문서」를 golden-set/README.md 에 적었다. 해당 항목은 둘이다 — GS-204(TERM-1.3↔MANUAL-3.2) · GS-216(TERM-2.9↔MANUAL-3.4). 6주차 판정 직전에 채점 기준을 느슨하게 하지 않는다. 대신 이 2건은 「검색기가 틀렸다」가 아니라 「구분 단서가 없는 기준으로 채점됐다」를 한계로 함께 적는다. GS-205(nori 토큰 확인)는 그대로 남는다. 원문 — 지침 1.3 과 매뉴얼 3.2 가 같은 규칙을 적은 쌍둥이인데 골든셋이 1.3 만 정답·3.2 는 방해 문서로 적었다. 사유(「시민 문의라 지침 쪽」)는 항목 메모에만 있고 README 규약에 없다(GS-216 도 같다). 선택지: ① 3.2 를 정답 목록에 추가(hit_at_k 는 any-of) ② 지식베이스에서 쌍둥이 조항 통합 ③ 규약을 README 에 적고 감수. 점수를 올리려고 라벨을 조용히 고치는 것이 되지 않게 결정 기록으로. GS-205 는 nori _analyze 로 「결정」 토큰 생존 여부 확인이 먼저(09-17 두 번째 기록). 다음 측정부터 scripts/compare_retrievers.py 가 항목별 상위 k 도 저장하게 하면 파일만으로 분석된다

`gateway` → `call-mediator` 개명에서 남은 것 (신규, 2026-09-17, 정성윤 · `decisions/115`)

~~운영 전환이 아직이다~~ — 끝났다 — 2026-09-17 14:00 1차 확인(/call-mediator/health ok · 옛 /gateway/* 404 · 번들의 구독 주소로 운영 /ws 열림) → 2026-09-19 재확인(토큰 넷 true · 토큰 없는 /ws·/ingest 401 · 번들 뷰 토큰으로 /ws 101 = 시크릿이 옛 값 그대로 · 프론트 번들에 gateway 문자열 0회). 룰셋 전환도 된 것으로 본다 — 안 됐으면 PR #101·#102 가 없는 검사를 기다리며 잠겼을 것이다
옛 오브젝트 청소 — ✅ 2026-09-19 SSM 실측: 지울 것이 없었다. 옛 gateway 이름의 Deployment·Service·Secret·Ingress 가 0개(시크릿은 call-mediator-tokens·callguard-server-tls·gcp-stt-credentials·server-env 넷뿐) · 로컬 .env 도 CALL_MEDIATOR_* 뿐 · 운영 이미지는 callguard-server:0.1.18 · callguard-call-mediator:0.2.1(파드 생성 09-18 08:23 UTC). 적용 스크립트에 prune 이 없어 남을 줄 알았는데 남지 않았다
Vercel 옛 변수 둘 삭제 — 정성윤 (신규, 2026-09-19) — kxu6(call.solidbob.cloud)의 VITE_GATEWAY_WS_URL·VITE_GATEWAY_DEMO_BASE_URL. 개명 전환 중 마지막 한 줄이다. 새 변수가 이미 번들에 구워져 돌고 있어 지워도 화면에 영향 없다. 콘솔에서만 보이고 CLI·토큰이 로컬에 없다 → ✅ 2026-09-22 정성윤이 지웠다(대시보드).
류준 님 origin/ai 의 services/gateway/ 미머지 작업 — ✅ 2026-09-18 PR #102 로 들어왔다(origin/ai 끝 커밋 c6fe2e7 이 main 에 있고, 재생기는 services/call-mediator/scripts/replay_persona_call.ts). 원문 — 합성 통화 재생기와 태그 0.1.6. main 을 받을 때 경로·이미지 이름·태그(0.2.x)·/dev/text 주소를 맞춰야 한다
개발자용 런타임 오버라이드 주소가 바뀌었다 — ✅ 2026-09-23 확인 — 저장소 전체에 gateway= 잔재 0건(apps/·services/). 원문 — ?gateway= → ?call_mediator=, 저장 키도 바뀌어 브라우저에 저장해 둔 옛 오버라이드는 무시된다. 팀에 알린다

합성 통화 확장 · E2E 24건에서 남은 것 (신규, 2026-09-18, 류준 · `decisions/209` 제안)

✅ 2026-09-21 키 받았고 --prefetch SYN-001 7턴 381자 합성 확인(캐시·장부 동작, w5-persona-tts-google 닫음). SSML volume 은 귀로 확인할 것. 원문 — Google TTS 키 발급 — 정성윤 님 — scripts/persona_sim/TTS.md §1 절차(Cloud Text-to-Speech API 사용 설정 → API 키 → API 제한 TTS 하나만 → 콘솔 할당량 낮추기). 받은 키는 .env 의 GOOGLE_TTS_API_KEY 에. 첫 실행은 --prefetch SYN-001(7턴)로 작게. 아직 실제 호출 0건이라 Wavenet 이 SSML volume 을 얼마나 반영하는지·콘솔에서 문자 할당량을 낮출 수 있는지 미확인
E2E 실패 21건의 시스템 결함 배정 (보고서 data/processed/persona-e2e/2026-09-18-1618.md, 로컬 규칙·BM25·NER 없음 — 측정값 아님) — → 10-01 219 이후 재측정 없음 — 범위 밖(138) → 10-02 정정 — 「재측정 없음」 이 아니다. 아래 ①~⑦ 은 09-18 에 각각 결정·수정됐고 그 뒤 세 번 다시 돌렸다 — 09-21 로컬 dense+리랭커 ✅23·❌1 · 09-22 밤 ✅7·❌17(전부 엉뚱한 절차 판정, 31쌍·186행) · 09-24 219 뒤 21쌍·127행·정답 절차 15/17(_logs/2026-09-21-07-ryujun·2026-09-22-09-ryujun·2026-09-24-02-ryujun. 구성이 서로 달라 나란히 비교하지 않는다, source: synthetic). 그 뒤 운영 실구성으로는 돌리지 않았다 ① 콜 미디에이터가 /hub/compliance-checks 를 안 부른다(라벨 있는 8건 전부 탐지 0, 09-17 과 동일 — 정성윤·장민석) → 09-18 결정: 콜 미디에이터에서 배선한다(상담원 확정 발화마다 호출·compliance_flag 저장, 대시보드 방송은 프론트 파서가 받을 때). 태그 올라감 ② closure_rule.py 에 TERM 4.5·4.20·4.12·2.6·4.9·6.12·3.3·4.8 규칙이 없다 — 대본이 고른 절차인데 판정이 영원히 없다(장민석) → 09-18 결정: 서버 규칙표에 추가한다 — TERM.md 「필요서류」 문구 글자 그대로, 조건부는 conditional. 장민석 님 검토 요청. 서버 태그 올라감 ③ 필요서류 판정이 추천 1순위 카드 조항에만 걸린다(topSourceDocId) — BM25 1순위가 틀리면 엉뚱한 절차(SYN-020 화면에 「지방세 환급」「장애인콜택시」 진행 중으로 뜸). 임베딩을 켜면(decisions/208) 줄겠지만 구조 자체를 볼 것(정성윤·류준) → 09-18 결정: 콜 미디에이터가 상위 카드를 순서대로 보며 규칙표에 있는 첫 조항을 절차로 삼는다(1순위가 POLICY·MANUAL·규칙 없는 TERM 이면 다음 카드). 엉뚱한 절차 자체는 검색 순위 문제라 208(임베딩)로 ④ C-5 누락 — SYN-020 #16 「저는 강민재고요, 아버지는 강영식이에요」 이름 둘이 자막·DB 에 원문(SEC-1). 「~고요」 어미 자기소개 + 가족 호칭 문맥. 화면에서도 재현 확인(류준·장민석) → 09-18 결정: server/apps/masking 이름 규칙 보강(「~고요」 어미 자기소개 · 가족 호칭 문맥). AI Hub 실제 발화로 과탐지 재확인 후 반영 ⑤ recommendation_card.source_doc_id 가 전부 NULL — document 테이블 0행이라 FK 를 못 채운다(B-6 출처가 DB 에 안 남음) → ✅ 09-18 코드 문제 아님 — scripts/seed_documents.py 를 안 돌린 것. E2E 스택 절차(E2E.md ②)에 넣었고 로컬 검사 DB 에 98조항 적재 확인. ⚠ 운영 RDS 에도 돌려야 한다(런북 절차 — 정성윤) ⑥ 대본↔규칙표 서류 이름 불일치 5건(SYN-002·005·013·015·017 — 「누수 수리 확인 서류」 vs 「누수 수리 사실을 확인할 수 있는 서류」 등) — 어느 쪽을 정본으로 맞출지 → ✅ 09-18 결정: 규칙표가 정본. 대본 11건의 required_documents 를 규칙표 기본 서류 이름으로 맞추고 조건부 서류는 새 필드 conditional_documents 로 뺐다(SYN-002·005·009·013·015·017·019·020·021·024). SYN-022 는 상담원 발화에 「가족 관계」 키워드를 넣었다. 라벨·PII·톤 불변, 생성기 24건 통과 ⑦ 한글 수사 휴대전화(「공일공 공공공공 …」)가 P4 가 아니라 P3 로 잡힌다(가려지긴 함) · P6 과잉 「고객님이요」·「위임장과」 → 09-18 결정: ④ 와 함께 서버 마스킹 규칙 보강(전화번호 형태 우선 분류 · 과잉 2종 제외 목록)
대시보드 AgentCallBox 모달이 합성 통화 라이브 보기를 가린다 — 조서희 — ✅ 2026-09-23 고쳤다(조서희, PR #145) — 「닫기」 버튼 + 자막이 들어오기 시작하면 스스로 사라진다. 원문 — 「통화 시작」 직후 마이크 데모 모달이 떠 뒤 자막이 흐리게만 보인다. call_token 없이 「통화받기」를 누르면 닫히긴 하지만(마이크 안 켬) 시연자가 알기 어렵다. 합성 통화(재생기)일 때 닫는 방법을 프론트에서 정할 것. 또 상담기록 목록이 customer_id 해시를 그대로 보여 준다
작업 트리의 미커밋 D-5 파일 — ✅ 09-18 2차 커밋에 실었다(하네스 배선 전 모듈). 원문 — — ai/apps/evaluation/metrics/call_temperature.py·ai/apps/evaluation/tests/test_call_temperature_metrics.py(이전 세션, w3-call-temperature). 09-18 커밋에서 뺐다 — 검토 후 별도 커밋(서버 태그 올라감)
✅ 09-18 처리 결과(같은 날 2차) — ①②④⑤⑥⑦ 반영 후 E2E 24건 ✅22·❌2(data/processed/persona-e2e/2026-09-18-1653.md·1655.md). 남은 ❌ 2 = SYN-011(3.14)·021(2.9) 검색 순위 — BM25 상위 5 에 정답 조항이 없어 필요서류 판정이 없다 → decisions/208(운영 임베딩). ③ 은 「카드 순서대로 규칙 있는 첫 조항」으로 바꿨다(콜 미디에이터 0.2.1) → 2026-09-21 로컬 재검사: dense 만 켜도 둘 다 ✅(리랭커 불필요). 대신 SYN-023 이 새로 ❌ — 아래 「진행 중 티켓을 닫으며 남긴 것」
장민석 님 검토 요청 — 09-18 서버 변경(0.1.18, decisions/302 로 류준이 고침) — ① closure_rule 에서 decisions/305 가 EXCLUDED 로 뒀던 2.6·4.5·4.9·4.12 를 되살렸다(갈래 공통 서류만 필수, 갈래별은 conditional) — 305 취지와 맞는지 ② 이름 규칙의 가족 호칭 문맥이 「아버지가 장애인이에요」 류를 _NOT_NAMES 목록으로만 막는다(실제 발화 신규 오탐 0) ③ P4 재라벨이 뒤의 「이」 한 글자를 함께 가린다(의도) ④ compliance_flag 저장 배선(신규) — compliance_rule 카탈로그를 저장 직전 UPSERT 로 채우는 것(대안: scripts/seed_compliance_rules.py) · default_severity 전부 medium(등급 정의 없음) · 저장 실패를 응답에서 숨기는 정책(콜 가드는 500)
- → 닫음 (2026-09-22 장민석): w5-server-change-review 범위(0.1.18) — closure_rule 29 복원은 공통 서류만 필수라 305 제외 사유와 모순 없음. 그대로 둔다
대시보드 컴플라이언스 경고가 서버 결과가 아니라 프론트 로컬 규칙(apps/call/src/lib/compliance/detectComplianceRisk.ts)이다 — ✅ **2026-09-23 고쳤다(조서희, PR #143) — 실서버 모드에서는 state.compliance 의 서버 findings 를 그린다. 운영 재확인은 수동 QA Q-31~33 재시험에서 한다. 원문 — 조서희** — 서버는 이제 검사·저장까지 한다(콜 미디에이터 0.2.1). 콜 미디에이터 compliance 메시지 파서를 추가하면 announceCompliance 를 켤 수 있다(정성윤 — main.ts)
- → 09-22 켰다(정성윤, call-mediator 0.2.3, w6-compliance-broadcast) — 파서는 349b18b 로 main 에 있다. 조서희 님 요청으로 검사 실패 신호 compliance_unavailable 을 함께 넣었다(위반 = compliance · 실패 = compliance_unavailable · 없음 = 침묵). 남은 것은 프론트 몫 — 이 타입의 파서와 화면(3단계, w6-compliance-alert-ui) · 로컬 규칙(detectComplianceRisk.ts)을 걷을지
4.20 과태료 이의신청·4.8·3.3·6.12 는 규칙표에 없다(의도) — 「— 필요서류」 조항이 아니다. 대본 SYN-006·007·012 는 required_documents 를 비워 「판정 0건이 정상」. 4.20 본문의 이의신청서·소명 자료를 규칙으로 둘지는 장민석 님 판단 → 10-01 그대로 둔다 — 닫는다

09-19 세션에서 남긴 것 (신규, 2026-09-19, 정성윤)

조서희 — w1-platform-landing 이 8-27 부터 in-progress 다 — 랜딩은 www.solidbob.cloud 로 떠 있고 → 10-01 done 처리됨 — 닫는다 3주차 다크 리디자인(w3-platform-landing-refresh)까지 끝났는데 앞 티켓의 상태가 그대로다. 중복 티켓 경고는 뒤 티켓에 depends_on 을 달아 껐지만(일부러 나눈 단계다), 상태는 apps/ 전담인 조서희 님 몫이라 건드리지 않았다. 티켓 본문의 「아직 안 된 것」(아키텍처 문서에 apps/platform 을 올릴지)이 아직 살아 있으면 그것만 새 티켓으로 떼고 이 티켓은 닫는 쪽이 보드가 정직해진다
팀 — 운영 document 98행이 정말 있는지 한 번 센다 — ✅ 2026-09-19 SSM 실측 98행. 런북 17-3 의 「09-15 적재 완료」가 맞았고 STATE.md·09-18 미결이 낡은 기록이었다. 적재를 다시 돌릴 필요 없다
운영 DB 를 세어 보니 «저장된 적 없는 경로»가 드러났다 — 팀 (신규, 2026-09-19, 정성윤 SSM 실측) — → 10-01 D-4·G-2·D-5 는 알려진 한계(138), eval_run 은 로컬 기록 DB(138 정본) — 닫는다
- 2026-09-23 확인(정성윤) — 2026-09-23 재측정(29 테이블) — 0행은 넷뿐이다: eval_run·eval_result(하네스는 로컬 기록 DB 를 쓴다) · knowledge_gap(공백 신고 0건) · resource_center(G-2 미구현) · voice_outlier(D-5 배선 보류 317). 채워진 것: call 34 · transcript_segment 157 · recommendation_card 445(source_doc_id NULL 1건뿐 — document 99행이 들어와 ⑤가 풀렸다) · closure 53 · closure_item 131 · masking_event 37 · call_guard_flag 37 · routing_log 33. ⚠ 남은 구멍 둘: call.agent_id 34/34 NULL(w8-call-owner-scope) · call.inquiry_type·summary_text 는 29/34 NULL(통화 후 처리를 돌린 5건만 채워진다 — 정상). 공개 테이블 29개. call 13 · transcript_segment 11 · masking_event 5 · call_guard_flag 1 · recommendation_card 0 · closure 0 · compliance_flag 0 · compliance_rule 0. 즉 운영에서 B(추천 카드)·F-2(필요서류 판정)·C-1~C-4(컴플라이언스) 가 한 번도 저장된 적이 없다. 코드가 없어서가 아니라(셋 다 0.1.18 에 들어 있다) 그 경로를 타는 통화를 아직 안 걸어 봤기 때문으로 보인다 — 09-17 점검의 「바깥 실제 접속 0건」과 같은 이야기다. 정할 것: 시연 전에 운영으로 합성 통화 한 건 (SYN-010 등)을 태워 넷이 실제로 쌓이는지 볼지 — 운영 DB 에 syn- 행이 남는다(09-17 미결과 같은 건). ⚠ 이건 측정이 아니라 「안 돌아 본 것」의 확인이다. 수치로 인용하지 않는다

6주차 판정(09-30)을 앞두고 — 공식 수치가 2주 낡았다 (신규, 2026-09-19, 정성윤)

주차 경계를 마일스톤 기준으로 다시 세면 오늘은 5주차이고 F·G·H·I 동결 판정은 6주차 종료 = 09-30, 남은 기간은 11일이다. STATE.md 가 「3주차」로 두 주 낡아 있어 이것이 가려져 있었다(같은 날 고쳤다).

류준 님 — 현재 코드로 하네스 재측정 + --record — ✅ 2026-09-21 운영 구성으로 쟀다 — 도커 없이 ES 9.5.1 + nori 를 zip 배포판으로 띄워(운영과 같은 버전·설정) 98조항을 적재하고 run_eval.py --runs 3 --no-ner --retriever bm25 를 돌렸다(커밋 261bce4-dirty · n 96/28). retrieval 0.833 / 0.666 ✅ · masking 누락 0 ✅(09-09 의 ❌ 가 풀렸다) · closure_gate·trigger 측정 불가. 값은 STATE.md 「실측값」. ⚠ 기록 DB 가 없어 --record 는 못 했다(run_id 없음) — 조건(날짜·커밋·명령·표본 수)은 STATE 에 글로 남겼다. ⚠ 모델 구성(dense·리랭커·NER)은 못 쟀다 — 모델 파일이 있는 머신에서 같은 명령에 --retriever 만 바꾸면 된다. 원문 — 판정에 쓸 수 있는 공식 수치가 09-09 값뿐이고 거기서 masking 이 ❌(누락 2) 다. 지금 판정하면 C-5 절대 규칙 미달로 동결이 걸린다. 그 뒤 들어온 dense·리랭커·NER·C-5 규칙 보강은 전부 로컬 측정이라 절대 원칙 2·5 상 인용할 수 없다. 이 저장소의 윈도 머신에는 ES·모델·.venv 가 없어 돌릴 수 없다 — 맥이나 측정 인스턴스(런북 22장) 몫이다.
```
docker build -t callguard-es:local infra/elasticsearch/
.venv/bin/python scripts/index_knowledge_base.py --to-es --recreate
ELASTICSEARCH_URL=http://localhost:9200 .venv/bin/python scripts/run_eval.py --runs 3 --record
```
볼 것: ① masking 이 0 으로 갔는지 ② NO_SAMPLES 가 어디 남는지(C-5 표본은 일곱 패턴 다 있고 F-2 f2_case 는 0건 — 09-19 골든셋 파일 실측) ③ 여러 번 중 최저치로 고정(절대 원칙 4)
팀 — 무엇을 «기준선 구성»으로 삼을지 먼저 정한다 — ✅ 2026-09-21 정했다(_project/decisions/121) — 모델은 전용 GPU EC2 에 올린다. 판정일(09-30)까지 그것이 운영 경로에 붙어 있으면 모델 구성, 아니면 운영 구성(규칙+BM25)이 기준선이고 모델 구성은 로컬 측정 참고치로 나란히 적는다. 원문 — 운영은 규칙+BM25, 로컬 최고는 NER+dense+리랭커다. 로컬 최고 수치로 「통과」를 선언하면 운영에서 성립하지 않는 통과가 된다. decisions/208(운영에 NER·임베딩을 올릴지)이 «제안» 인 채라 그 결정이 곧 기준선의 정의다. 판정( w6-core-baseline-check )보다 이게 앞선다
F-2 는 잴 수 없는 상태로 7주차 체크포인트를 맞는다 — 골든셋에 f2_case 가 0건이라 「필수 항목 누락 0건 탐지」를 판정할 근거가 없다. 정할 것: ① 골든셋에 F-2 케이스를 넣어 측정 가능하게 할지 ② 계획대로 설계 문서 전환(w7-f2-checkpoint)을 미리 확정할지. 성공 조건은 F-2 가 아니므로 ②도 실패가 아니다
- → 닫음 (2026-09-21 보드 최신화, 정성윤): decisions/118 — 체크포인트를 앞당겨 판정했고 F-2 는 설계 문서 산출로 갔다 → w8-f2-wrapup
7주차 레이턴시가 지금 구조로는 또 「측정 불가」다 — 트리거는 이벤트 도착 시각이 없어 상수로 모형화 중이라 → 10-01 서버 내부 구간은 09-30 실측(w7-latency-budget), 나머지는 측정 불가로 — 닫는다 채점하면 p50=p95=346·발동률 1.0 이라는 가짜 만점이 나온다(STATE.md). 4.3절 지연 예산을 실제로 재려면 콜 미디에이터가 발화 종료·카드 도착 시각을 실어 보내는 계측이 먼저다 — 7주차에 시작하면 늦는다(w7-latency-budget)

`/health/ready` 를 새로 냈다 — 검토·배선은 남았다 (신규, 2026-09-19 · 주 담당 장민석)

장민석 님 검토 — server 0.1.19(decisions/302) — ① /health 는 싼 기동 확인 그대로 두고
- → 닫음 (2026-09-22 장민석): w5-server-change-review 범위(0.1.19) — 그대로 둔다 실제 연결은 주소를 나눠(GET /health/ready) 잰 것 ② 타임아웃 3초·실패 시 503 · 설정이 없는 자원은 실패로 세지 않는다(configured: false) ③ 예외는 타입 이름만 싣는다(SEC-2 — 메시지에 접속 문자열이 들어 있다) ④ ES 는 _wire_retrieval 이 만든 같은 클라이언트를 app.state.es_client 로 재사용한다
k8s 프로브에 붙일지 — 정성윤 — ✅ 2026-09-23 정했다 — 프로브는 /health 를 본다, /health/ready 는 안 쓴다. readiness 가 /docs(스웨거)였던 것을 /health 로 바꾸고 liveness 를 새로 달았다(60초 뒤부터 30초 간격·3회). /health/ready 를 프로브에 걸지 않는 이유: 그쪽은 DB·ES 를 실제로 찔러 못 붙으면 503 이라, ES 가 잠깐 내려가면 readiness 가 떨어져 자막·마스킹까지 같이 멈춘다. 검색만 죽는 편이 낫다(server/main.py 의 같은 판단). 진단용으로는 그대로 쓴다(런북 19장·배포 스모크). 원문 — 지금은 어떤 프로브도 /health/ready 를 쓰지 않는다. 붙이면 ES 가 잠깐 흔들릴 때 파드가 서비스에서 빠진다 — 자막·마스킹은 ES 없이도 도는데 함께 멈추는 셈이라, 붙이려면 그 대가를 먼저 받아들여야 한다. 런북 19장 9-1 번에 수동 검사로만 넣어 두었다
ES 가 설정됐는데 클라이언트가 안 꽂힌 배포는 degraded 로 뜬다 — ✅ 2026-09-23 운영은 둘 다 초록이다 — /health/ready postgres ok(77ms) · elasticsearch ok(2ms). 「그 상황이 오면」의 이야기로만 남는다. 원문 — elasticsearch 패키지 없이
- 2026-09-23 확인(정성윤) — 지금 운영은 /health/ready 가 postgres ok(77ms) · elasticsearch ok(2ms) 로 둘 다 초록이다. 이 항목은 「그 상황이 오면」의 이야기로 남는다. ELASTICSEARCH_URL 만 있는 구성(검색은 501)이 그렇다. 의도한 동작이지만, 그런 구성을 정상으로 볼지는 팀 판단이다

레이턴시 계측에서 남은 것 (신규, 2026-09-20 · `decisions/119`)

콜 미디에이터 — e2e_latency_ms 를 채운다(누구나 · 주 담당 정성윤) — ✅ 2026-09-21 채운다(콜 미디에이터 0.2.2) — 추천을 방송하기 직전에 방송 시각 − utterance_end_ms 를 문자열로 싣는다. 발동하지 않은 응답·발화 종료 시각이 없는 경우에는 넣지 않는다(0 으로 지어내지 않는다). 통화 기준 시계를 한 곳(callClockMs)으로 모았다. 타입 체크 0 · 테스트 132/132. ⚠ DB 의 e2e_latency_ms 는 여전히 NULL 이다 — 서버는 방송 전에 저장한다. 값은 방송 메시지로만 흐른다(119 ③). 원문 — 방송 직전에 방송 시각 − utterance_end_ms 를 계산해 싣는다. 컬럼·DTO 는 2026-09-09 부터 있었는데 아무도 값을 넣지 않아 늘 NULL 이었다(09-20 전수 grep). 서버는 그 시각을 모르므로 서버가 채우면 안 된다
장민석 님 검토 — 서버 0.1.19 의 구간 분리(decisions/302) —
- → 닫음 (2026-09-22 장민석): w5-server-change-review 범위(0.1.19) — 그대로 둔다 ① RecommendationCards 에 retrieval_ms·generation_ms 추가(선택 필드) ② 응답 스키마에도 노출(콜 미디에이터가 중계) ③ DB 컬럼은 일부러 안 만들었다 — 운영 recommendation 이 0행이고 마이그레이션이 사람 손이라 미뤘다(119 ③) ④ 시계 호출이 2 → 4 로 늘어 기존 테스트 둘의 기댓값을 고쳤다(저장이 채점 구간 밖이라는 성질은 그대로 지킨다)
측정 — e2e_check.py 가 구간별 p50·p95 를 표본 수와 함께 낸다 — 지금 24건을 왕복시키고 있으니 거기에 얹는다. → 10-01 안 한다(w7-latency-budget done 사유) — 닫는다 ⚠ 합성 통화는 STT 를 안 거쳐 ①(발화 종료 → STT 도착)이 0 이다. source: synthetic + 「STT 미경유」를 붙이고 ①은 V4 실측 346ms 를 더해 「추정 E2E」로 적되 합산이 추정임을 같은 줄에 쓴다
브라우저 렌더(⑥)는 재지 않기로 했다 — 되돌리려면 프론트 계측 + 되돌리는 엔드포인트가 필요하다(조서희 님 협의) → 10-01 확정 — 닫는다

운영 파이프라인 왕복에서 나온 것 (신규, 2026-09-20 — 런북 19장 11번 확장판)

운영에 테스트 통화 1건을 태워 전 구간을 처음으로 실제로 돌렸다(끝난 뒤 행 15개 전부 삭제). 잘 돈 것은 진행 기록에 있고, 여기는 고쳐야 할 것만 적는다.

⚠ 쓰기 경로에 인증이 없다 — 팀(주 담당 장민석·정성윤) — ◐ 2026-09-21 2단계까지 됐다 — 문은 아직 열려 있다. ① 서버 문(0.1.19) ② 콜 미디에이터가 CORE_API_TOKEN 을 Authorization: Bearer 로 보낸다(0.2.2 — 부르는 경로 전부에 실리는지 테스트로 고정, 없으면 헤더를 안 보낸다) · 매니페스트에 call-mediator-tokens.CORE_API_TOKEN(optional) 주입 · .env.example·secret.example.yaml 에 키 이름. 남은 것은 운영 작업 둘: ③ 같은 값을 미디에이터 시크릿에 먼저, 그다음 server-env 에 넣는다 → 이때 잠긴다 ④ 서버를 fail-closed 로. 두 이미지가 배포된 뒤에 한다 — 순서를 뒤집으면 운영 통화가 전부 401 이다. 원문 — ⚠ 1단계만 됐다 — 문은 아직 열려 있다(2026-09-20, decisions/120). 서버에 서비스 토큰 문(INGEST_SERVICE_TOKEN, Authorization: Bearer)을 달았다(server 0.1.19). 토큰이 없으면 연다 — 서버를 먼저 배포하는 순간 돌고 있는 미디에이터가 401 이 되지 않게 하려는 이행기 동작이고, /health 의 ingest_guard 가 open/locked 로 그 상태를 말한다. 남은 것(순서를 지킨다): ② 콜 미디에이터가 CORE_API_TOKEN 을 헤더로 보낸다(TS — 이 머신에서 테스트 못 돌린다) ③ 같은 값을 server-env 와 미디에이터 시크릿에 넣는다 → 이때 실제로 잠긴다 ④ 서버를 fail-closed 로. ③을 ②보다 먼저 하면 운영 통화가 전부 401 이다. 또 대시보드가 직접 부르는 쓰기(/close·요약 확정·카드 피드백·공백 신고)는 이 문 밖이라 여전히 열려 있다 — 사람 토큰 몫이다. 원문 — — POST /hub/calls · /hub/transcripts ·
- → 닫음 (2026-09-22 장민석): ③ 시크릿(정성윤, 09-22) · ④ fail-closed(w6-ingest-guard-fail-closed, server 0.1.34) — 운영 locked · 토큰 없는 쓰기 401 확인 /hub/recommendations · /hub/call-guard-checks · /hub/compliance-checks · /hub/closure-checks 가 토큰 없이 200 이다. 주소를 아는 사람은 누구나 운영 DB 에 통화·전사를 쓴다. CORS 는 브라우저에만 걸린다. 상담원 토큰 가드가 달린 곳은 블랙리스트 요청 하나뿐이다(기존 미결 「상담원 토큰을 어디까지 걸지」와 같은 건 — 이번에 「실제로 열려 있다」가 확인됐다). 콜 미디에이터는 자기 토큰으로 막혀 있으니 서버 쪽만 남았다
없는 세그먼트를 참조하면 500 이다 — 장민석 — ✅ 2026-09-20 고쳤다(decisions/302, server 0.1.19). SegmentNotFoundError 를 새로 두고 콜 가드 저장소가 FK 위반(23503)을 잡아 올린다 → 라우터가 404(「전사 구간이 없습니다: c#7 — POST /hub/transcripts 가 먼저 와야 한다」). 외래키가 아닌 실패는 그대로 올린다(아무 예외나 404 로 접으면 진짜 결함이 숨는다 — 테스트로 고정). 원문 — — segment_id 가 transcript_segment 에 없으면 call_guard_flag FK 위반이 그대로 터져 500 Internal Server Error(파드 로그에 ForeignKeyViolation). 4xx 로 거절해야 한다 — 09-15 에 고친 「관리자 가드가 헤더 없으면 500」과 같은 부류다
컴플라이언스 저장 실패가 응답에 드러나지 않는다 — 장민석·류준 — ✅ 2026-09-21 맞췄다 — 둘 다 「200 + 로그」. 콜 가드도 저장이 우리 쪽 사정(DB 흔들림)으로 실패하면 탐지 결과를 그대로 돌려주고 경고 로그만 남긴다. 전에는 500 이라 상담원을 보호하려는 경고가 기록 실패 때문에 화면에서도 사라졌다. 삼키지 않는 것은 둘이다 — 호출자가 없는 전사 구간을 가리킨 것(404) · 스포크가 span 을 안 채운 것(우리 결함이라 500, CallGuardFlagSpanMissingError). 원문 — ⚠ 절반만 닫았다(2026-09-20). 호출자 실수(없는 전사 구간)는 이제 두 스포크 다 404 다 — 인터랙터가 SegmentNotFoundError 는 삼키지 않는다. 저장소가 이 상황을 CallNotStartedError(「통화가 없다」)로 올리던 이름 오류도 바로잡았다. 남은 절반은 «우리 쪽 실패(DB 흔들림)」 정책이다 — 컴플라이언스는 200 + 로그, 콜 가드는 500 으로 여전히 다르다. 09-18 에 장민석 님 검토 항목으로 올라가 있어 일부러 안 건드렸다. 원문 — — 세그먼트가 없으면 compliance flag not stored … reason=CallNotStartedError 를 로그에만 남기고 응답은 200 이다. 09-18 의 설계(「저장 실패는 로그, 응답 그대로」)가 의도대로 동작한 것이지만, 그래서 「운영에서 한 번도 저장 안 됨」이 조용히 이어질 수 있다. 콜 가드는 같은 상황에서 500 이라 두 스포크의 정책이 서로 다르다 — 맞출지 정한다
옛 test-deploy-* 통화 3건이 운영에 남아 있다 — 정성윤 — ✅ 2026-09-21 지웠다 — 09-11 배포 검증이 남긴 셋(…111738·…111747-013·…111813-kb, 각각 전사 ≤1 · 마스킹 ≤1 · 확정 요약 없음)을 ID 를 명시해 자식부터 지웠다. 운영 call 13 → 10. ⚠ 남은 10건도 전부 test- 접두어다(test-dev 3 · test-e2e 2 · test-conn 2 · 날짜형 3) — 그것들은 건드리지 않았다. 원문 — 이번 것은 지웠고, 이전 세션들이 남긴 것이다. 지우려면 자식부터(closure_item → closure … call). card_feedback·closure_item 을 빠뜨리면 FK 로 막힌다
compliance_rule 카탈로그에 C-1 한 행이 이번 테스트로 생겼다 — ✅ 2026-09-23 재확인 — 운영에 C-1·C-2·C-3 세 행이고 compliance_flag 는 C-1 2 · C-2 1 · C-3 1 건이다. 테스트 잔재가 아니라 실제 탐지 경로가 쓰는 카탈로그라 지우지 않는다. 원문 — 지우지 않았다.
- 2026-09-23 확인(정성윤) — 운영에 이제 C-1·C-2·C-3 세 행이고 compliance_flag 는 C-1 2 · C-2 1 · C-3 1 건이다. 테스트로 생긴 행이 아니라 실제 탐지 경로가 쓰는 카탈로그가 됐다 — 지우지 않는다. 내용은 맞고(확정적 보장 · 금액·기간 단정 / medium), 09-18 설계가 저장 직전 UPSERT 로 채우게 돼 있다. ⚠ 다만 카탈로그가 「누가 언제 무엇을 검사했는가」에 따라 채워진다는 뜻이라, 시드 스크립트로 옮길지는 미정
.env.example 에 INGEST_SERVICE_TOKEN 키를 사람이 넣어야 한다 (신규, 2026-09-20) — ✅ 2026-09-21 넣었다 — INGEST_SERVICE_TOKEN(서버)·CORE_API_TOKEN(콜 미디에이터) 둘 다. 이름만, 값은 비웠다. 훅이 막는 것은 편집 도구라 셸로 넣었고, 넣은 뒤 값이 들어간 새 줄이 0 임을 diff 로 확인했다. 원문 — server/core/config.py 가 새로 읽는 키다. .env.example 은 자격증명 보호 훅(protect-files.sh)이 편집을 막아 일부러 우회하지 않았다. infra/k8s/base/secret.example.yaml 에는 넣었다. 값은 비워 둔다(키 이름만 — SEC-2)

진행 중 티켓을 닫으며 남긴 것 (신규, 2026-09-21, 류준)

재측정에서 새로 나온 것 (신규, 2026-09-21)

⚠ C-5 「누락 0」은 오류 없는 전사에서만 성립한다 — 운영 구성(규칙만)의 오류 내성 곡선: 0% 0건 → 5% 2건 → 10% 3건 → 15·20% 4건(판정 24, 시드 3개 중 최대). 5% 에서 새는 것은 GS-033·GS-415(둘 다 P7 주소), 10% 부터 GS-056(P6 이름)이 더해진다. 실제 통화는 STT 를 거치므로 오류 0% 가 아니다 — 절대 규칙(누락 0건)을 「통과」로 인용할 때 반드시 「오류 없는 전사 한정」을 붙인다. 09-15 로컬 측정의 규칙+NER 은 0/0/1/1/1 이었다 — NER 이 필요한 근거가 이것이고, 모델을 올릴 자리는 decisions/121(전용 GPU EC2)이다. ⚠ 주입기가 실측 오류의 46.9% 를 흉내 내지 못해 실제는 이보다 나쁠 수 있다 → 10-01 인용 문구로 고정(decisions/138)
✅ 2026-09-21 이 맥(모델 파일 있음)에서 쟀다 — 값·조건은 티켓 w5-error-curve-model-series, 그림 jekyll/assets/error-tolerance-2026-09-21-models.png(운영 2계열 + 모델 3계열 한 장). 모델 계열 곡선이 그림에 없다 — jekyll/assets/error-tolerance-2026-09-21.png 는 운영 구성(bm25 · rule) 두 선뿐이다. 모델 파일이 있는 머신에서 scripts/measure_error_tolerance.py → scripts/plot_error_curve.py 를 돌리면 dense·리랭커·규칙+NER 이 같은 그림에 얹힌다(측정 스크립트가 있는 계열만 재고 빠진 계열을 그림 아래에 적도록 고쳤다)
기록 DB 없이 잰 값이다 — eval_run/eval_result 에 남지 않았다(§5 의 네 조건은 STATE.md 에 글로 남겼다). DB 가 있는 환경에서 같은 명령에 --record 를 붙여 한 번 더 돌리면 run_id 가 생긴다 → 10-01 정본은 run 8·9(기록 DB 있음, 138) — 닫는다

전수 조사에서 나온 것 — 고치지 않고 올린다 (신규, 2026-09-21, 정성윤)

낡은 서술은 고쳤다(w5-stale-docs-sweep). 아래는 서술이 아니라 결정이나 코드 작업이 필요해 남긴 것이다.

팀 — 개발기간과 스프린트 수가 안 맞는다 — ✅ 2026-09-21 닫음(_project/decisions/129): 8스프린트는 10-14 에 끝나고 10-15 ~ 10-27 은 새 기능 없는 「마감 기간」이다. ⚠ 팀에 묻지 않고 PM 이 기본값으로 정했다 — 발표일을 아는 사람은 알려 주면 고친다. 원문 — 개발기간은 10-27 까지인데 1주 1스프린트 × 8 은 10-14 에 끝난다(STATE.md 가 8주차를 10-08~10-14 로 적는다). 남는 약 2주가 무엇인지(발표 준비·버퍼·마감 정리) 어디에도 적혀 있지 않다. w8-* 티켓의 마감일이 여기에 걸린다
✅ 2026-09-22 달았다(_project/decisions/315, 코드, 운영 배포 전 — 프론트가 토큰을 싣게 바뀐 뒤 머지). 원문 — 장민석 님 — POST /hub/calls/{id}/close 와 카드 피드백에 상담원 토큰 가드가 없다 — server/main.py 주석은 「대시보드가 직접 부르는 쓰기(/close·요약 확정·카드 피드백)는 사람 토큰(require_agent) 몫」이라고 적는데, 실제로 걸린 것은 요약 확정·재수정뿐이다(postcall_router.py·card_feedback_router.py 에 require_agent 0회, 2026-09-21 grep). 서비스 토큰 문(decisions/120)도 이 둘은 비껴간다 → 두 경로는 어느 토큰도 요구하지 않는다. 읽기 경로(통화 목록·전사·기록)가 무인증인 것은 기존 미결과 같은 건이다
정성윤 — 새 클러스터에서 CORE_API_TOKEN 이 조용히 비는가(추정 — 확인 필요) — ✅ 2026-09-21 확인: 빈다. release.yml 301줄은 call-mediator-tokens 가 없을 때만 만들고 그때 INGEST·VIEW 두 키만 넣는다. 지금 클러스터는 키를 손으로 더하면 배포가 지우지 않는다. 런북 단계는 w5-ingest-auth-fail-closed 완료 조건으로 옮겼다. 원문 — infra/k8s/base/call-mediator.yaml 은 call-mediator-tokens 에서 그 키를 optional 로 읽는데, release.yml 의 시크릿 생성은 INGEST·VIEW 두 키만 만든다. 사람이 손으로 넣는 전제라면 런북 12장에 그 단계를 적고, 아니면 워크플로에 넣는다. 비면 쓰기 문이 open 으로 남는다
류준 님 — 하네스가 부르지 않는 지표가 셋 있다 — ai/apps/evaluation/metrics/ 의 generation(B-4·B-5)·asr(A-5)·call_temperature(D-5)는 harness.py·run_eval.py 어디서도 import 하지 않는다. → 2026-09-22 닫음(w6-harness-silent-metrics) — 생성·A-5 가 리포트에 「측정 불가 + 사유」로 나온다. D-5(call_temperature)는 09-21 f3f284b 에 이미 배선돼 있었다 별도 스크립트로만 돌아서 run_eval 리포트에 「측정 불가」로도 나타나지 않는다(침묵 누락). 절대 원칙 10 의 취지로는 「측정 불가」 줄이라도 찍는 쪽이 맞다
✅ 2026-09-22 닫는다 — 발표 전에는 배선하지 않는다(_project/decisions/317). 서버는 「미측정」(null)을 낸다(316). 화면 표시만 조서희 님 미결에 남았다. 이하 원문 — ◐ 2026-09-22 추정 확인: 맞다 — 늘 0 이었다(voice_outlier 에 쓰는 곳이 ai/ 평가 쪽뿐). 이제 0 대신 「미측정」(null) 이 나간다(_project/decisions/316, 스키마 마이그레이션 동반). 실제 배선은 남았다 — 오디오를 가진 콜 미디에이터가 판정해야 하고, 음성 골든셋이 없어 붙여도 판정 품질은 측정 불가다. 원문 — 류준·장민석 님 — D-5 음성 이상치 저장이 서버에서 배선되지 않는다 — 포트·DTO·voice_outlier_repository.py 까지 있는데 server/ 프로덕션 코드에서 한 번도 참조되지 않는다. 그래서 blacklist_evidence_repository.py 의 voice_outlier 집계는 서버 요청 경로에서 늘 0 일 것으로 보인다(추정) — J-4 근거의 한 축이 비어 있는 셈이다
- 2026-09-22 류준 조사(에이전트) → 확인: 새 API 없이는 배선할 수 없다. 콜 미디에이터의 hub 호출 6개가 전부 텍스트만 싣고 오디오·특징값을 나르는 경로가 없다 — 그래서 블랙리스트 근거의 voice_outlier 건수는 운영에서 늘 0 이다. 제안(류준): 확정 발화마다 POST /hub/voice-samples 로 보내고 서버가 F0 만 뽑은 뒤 오디오는 곧바로 버린다(하네스가 재는 파이썬 추출기 하나만 쓰게 된다). 결정은 w7-d5-server-wiring(장민석)
팀 — 「허브는 스포크를 import 하지 않는다」를 계약으로 걸지 — 서버 주석 세 곳이 인용하던 「계약 5」는 .importlinter 에 없었다(주석은 사실대로 고쳤다). → 10-01 안 건다 — 주석 정정으로 끝(138) 지금은 hub/dependencies/ 가 masking·closure_gate·postcall·blacklist 의 기본 구현을 직접 import 하고 허브 라우터 12개가 admin_auth·agent_auth 가드를 import 한다. docs/architecture.md §1 은 여전히 「계약 위반」이라고 적는다 — 문서를 코드에 맞출지, 계약을 새로 걸고 코드를 옮길지 정한다
팀 — 09-21 에 만든 티켓 25건은 «계획»이지 «합의»가 아니다 — 정성윤이 보드를 프로젝트 끝까지 채우며 남의 이름으로 todo 티켓 16건을 만들었다 → 10-01 137 로 정성윤이 전부 수행 — 닫는다 (류준 6 · 장민석 6 · 조서희 4). 근거는 전부 로그·미결·결정 기록에 있던 「남은 것」이지만 주차와 담당은 정성윤의 배정이다. 각자 보고 — 맞으면 그대로, 아니면 옮기거나 지운다(todo 는 보존할 수행 기록이 없어 지워도 된다, CLAUDE.md §4). 같이 옮긴 상태 넷(w4-admin-google-login·w4-dashboard-live-contract·w5-persona-e2e·w1-platform-landing → done)도 판정이 틀렸으면 담당자가 되돌린다

2026-09-22 류준 — 남은 일을 돌리며 새로 생긴 것

2026-09-22 에 남긴 것 (정성윤)

STT 일 캡(600초) 올릴 날짜 — 리허설·시연 날짜가 없어 못 정했다. 통화 1건 ≈146초라 하루 4통화. 합성 통화·판정 측정은 STT 를 안 타 당장 영향 없음(류준 전달 문서 §1-6) → 10-01 날짜 없이 절차로 정했다(decisions/143)
A-5 를 차별점으로 유지할지 — 초급 WER 0.412(상한). Chirp 3 재측정(roles/speech.client 09-22 부여) 값을 보고 정한다(§1-9) → 10-01 decisions/139 — Chirp 3 값이 나오면 재검토
필요서류 절차 고르기 규칙 — 「1순위가 규칙 없는 TERM 이면 판정하지 않는다」에 동의. 콜 미디에이터 src/ 라 decisions/124 ② PR 과 함께 태그 한 번으로(§1-11) → 10-01 219 로 정착 — 닫는다
09-21 셋째 판 「남은 일 목록」의 미커밋 파일 회수 — ✅ 회수됐다 — 결정 125~128 이 전부 _project/decisions/ 에 들어와 있다(2026-09-23 확인). 원문 — 결정 125~128(일정 공백·배정 호출·공개 데모·스키마 대조)·09-30 판정문 초안·티켓 절차. 저장소 이력 어디에도 없다. 그 세션을 돌린 머신의 git status 를 볼 것. ⚠ 오늘 124·125 를 새로 썼으니 거기 남은 파일은 번호를 옮겨야 한다
쓰기 경로 ④ 서버 fail-closed — ✅ 2026-09-22 운영 배포(장민석, w6-ingest-guard-fail-closed, server 0.1.34 — PR #131). 배포 뒤 /health locked · 토큰 없는 쓰기 401 확인. 미설정이면 401, /health unset. 기동 거부가 아니라 401 로 갔다. ~~server 0.1.33~~ 은 #129 와 겹쳐 머지 때 0.1.34 로 올라갔다. 원문 — 시크릿은 09-22 에 들어가 잠겼고, 「없으면 연다」를 걷는 코드 변경만 남았다(w5-ingest-auth-fail-closed, 장민석 님 검토 대상)
랜딩 라이브 통화 실제 동작 — 09-22 에 VITE_CALL_MEDIATOR_WS_URL 을 넣고 재배포했지만 브라우저로 통화를 걸어 본 적은 없다. 조서희 님 w6-shared-call-entry 운영 확인과 같이 → 10-01 소개 사이트는 mock 시연으로 둔다 — 범위 밖(138)
배포 태그 번호에 선점 장치가 없다 — 정성윤 — 09-22 하루에 server 태그 0.1.28 이 #114·#117 에서 겹쳤고, 0.1.29 는 server 브랜치가 집어 두어 #117 을 0.1.30 으로 다시 올렸다. tag-check 가 막아 사고는 아니지만 PR 마다 한 번씩 되돌아온다(결정 기록 번호와 같은 병, decisions/022 ④). 후보: ① 브랜치별 번호대(예: 패치 자리 대신 빌드 번호) ② 머지 시 release.yml 이 채번하고 newTag 는 «올려야 함» 표시만 ③ 지금대로 두고 ⑥ 경고를 오류로 격상 → ✅ 2026-09-22 ③ 채택(decisions/131) — check_release_tags.py 가 다른 브랜치 선점을 오류로 낸다.

2026-09-22 에 남긴 것 (장민석)

코드는 server 브랜치에 있고 커밋·배포 전이다. 넷은 조서희 님 화면이 먼저 바뀌어야 서버를 내보낼 수 있다(사용자 결정 — 서버만 하고 넘긴다).

2026-09-22 최종 QA(페르소나 4 + 검증 웨이브) — 남은 것 (류준 정리)

원자료 data/processed/qa-2026-09-22/(gitignore). 합성 통화는 source: synthetic(STT 미경유) — 성능 수치가 아니다.

2026-09-22 밤 — 류준 티켓 일괄 처리 뒤 남은 것

엉뚱한 필요서류 판정 31쌍·186행(대본 24건 중 17건) — 류준 — ✅ 2026-09-24 점수 하한(C2, f=0.635)을 채택해 기본값으로 바꿨다(decisions/219 확정, 사전 등록 규칙을 기계적으로 적용 — 류준 결정, 팀 회의 합의 없음). 보류 표본 12건에서 10쌍·42행 → 3쌍·12행, 정답 절차 8/8 그대로. v0 24건은 31쌍·186행 → 21쌍·127행, 15/17 그대로. 떨어진 후보: C1(연속 두 번)·C3(C1+넓힌 맞장구 억제)은 필요한 절차를 8건 중 7건 잃었다. 운영 반영은 배포 태그가 올라간 뒤다. 원문 — 1순위 규칙으로 75→31쌍 줄었지만 맞장구·잡음 발화의 1순위가 절차가 되고 누적된다. B-6 문턱(215)을 켜면 10쌍이지만 필요한 카드가 사라진다 — 두 결정이 부딪친다. 새 표본으로 사전 등록 → w6-procedure-noise-redesign
절차 누적이 남았다 — 류준·조서희 — 한 번 잡힌 절차는 내려가지 않아 상담원 발화마다 다시 판정된다(엉뚱한 «행»이 «쌍»의 4배인 이유). 새 절차가 잡히면 이전 절차를 내리는 동작은 절차 패널이 사라지는 화면 동작이라 apps/call 과 함께 정해야 한다 — 219 후보에서 일부러 뺐다. 남은 3쌍(SYN-108 되묻기의 오답 1순위 · SYN-109 시 소관 아닌 민원)은 점수로 못 거른다 — 검색(B-2/B-3) 쪽 문제다 → 10-01 알려진 한계(138) — 닫는다
여권 조항 4.23 이 dense 에서 무관한 질문에 끼어든다 — 류준·장민석 — 로컬 E2E 대본 15개에서 카드 25장(여권을 말하는 대본은 1개), 골든셋 GS-702 운전면허는 1위. 그래서 필요서류 규칙표에서 제외했다(decisions/217). 규칙은 끼어듦을 먼저 본 뒤 — 장민석 → 10-01 규칙표에서 제외(217)로 정착 — 닫는다
장민석 님 사후 검토 — 09-22 류준이 고친 server/ — ✅ 2026-09-23 정성윤이 대신 봤다(decisions/302 — server/ 는 누구나 본다. 장민석 님이 다시 볼 필요는 없지만 이견 있으면 말해 주면 된다). 셋 다 통과. ① name_detector.py — 「벗긴 조사가 이 로 시작하면 그 글자까지 가린다」는 원칙 3(애매하면 가린다)과 방향이 같다. 과잉은 조사 한두 글자뿐이고 누락은 절대 규칙이다. 조건 셋(이어진 어절 · 성씨+두 글자 · 문장 끝 홑 「이」)이 주석으로 근거까지 남아 있다. ⚠ 한계: _FOREIGN_SURNAMES_1 은 하드코딩 목록이라 표본 밖 성씨에는 여전히 약하다 — 「호칭·문맥 없는 이름은 못 잡는다」와 같은 한계로 함께 적는다. ② closure_rule.py EXCLUDED 의 DASAN-TERM-4.23 — decisions/217 근거가 값 옆에 문장으로 붙어 있다. 게이트(gate.py)가 그 목록을 보고 판정하지 않는다(거짓 판정 방지). 맞다. ③ eval_run_repository._MODULE_ID 의 generation→B-4·postcall→D-1 — 다른 행(call_guard→C-6·call_temperature→D-5)과 같은 규칙이고 VARCHAR(10) 넘침도 막는다. 맞다. 원문 — ① masking/name_detector.py(이름 끝 「이」·첫 어절 한 글자 성씨·호칭 경계에 괄호) ② closure_gate/.../closure_rule.py EXCLUDED 에 4.23 ③ eval_run_repository.py _MODULE_ID 에 generation→B-4 · postcall→D-1
D-1 통화 후 요약이 서류·후속 조치를 놓친다 — 장민석(D-1)·류준 — ✅ 2026-09-23 고치고 같은 하네스로 다시 쟀다 — 정성윤. 규칙 발췌에 세 줄을 더한다(전부 자막에 있는 문장 그대로, 지어낸 문장 0 — decisions/306): 필요서류 안내(서류 어휘가 든 상담원 발화 최대 3) · 후속 조치(이미 뽑던 D-3 을 요약에도 싣는다, 최대 5) · 마무리 안내(마지막 실질 상담원 발화). 핵심 항목 21/60 → 53/60(micro 0.35 → 0.883) · 갈래별 서류 2/23 → 23/23 · 조치 1/10 → 9/10 · 요청 5/7 → 7/7 · 문의 10/10 유지. 요약 길이 중앙값 160 → 373자. 측정: scripts/run_eval.py --no-ner, 골든셋 postcall-v1.json 10통화 60항목, 2026-09-23. ⚠ 남은 갈래는 「안내」 4/10 — 못 잡은 것은 「소관 부서 심사로 정해짐」·「대출 범위 제한」처럼 여러 발화에 흩어진 설명이라 한 줄 발췌로는 안 된다. 생성 요약(런북 14장)이 붙을 때 다시 잰다. 원문 — 장민석(D-1)·류준** — 새 채점(decisions/218)에서 핵심 항목 0.35(21/60), 서류 2/23 · 조치 1/10. 규칙 발췌가 「첫 실질 고객 발화 + 바로 뒤 상담원 발화」 두 줄뿐이라 중·후반 안내를 놓친다. 후보: 마지막 상담원 「정리하면 …」 발화도 싣기(측정 안 함). 유형은 w6-d2-inquiry-type-null 뒤에 숫자가 된다
D-2 유형 이름표가 두 벌이다 — 류준·장민석 — ✅ 2026-09-23 ai/ 를 운영 쪽으로 맞췄다 — 정성윤. postcall_summary 의 CHAPTER_TO_TYPE 값을 「대중교통 안내」→「대중교통」 식으로 운영 유형표(server/apps/postcall/.../inquiry_rules.py, decisions/323)와 글자까지 같게 했다. 어느 장이 투표하는지는 그대로다(6장은 여전히 표 밖 — 넣으려면 표본으로 재고 따로 정한다). ⚠ 지금 운영에는 영향이 없다 — 모델 스포크는 OLLAMA_URL+GENERATION_MODEL 이 둘 다 있어야 꽂히는데 운영에 없어서 규칙 어댑터(운영 유형표)만 돈다. 모델을 켜는 순간 두 벌이 섞여 들어갈 자리를 미리 막은 것이다. ai 테스트 넷을 새 이름으로 고쳤고 전량 초록. 원문 — 운영(server/apps/postcall, decisions/323) 「대중교통·상하수도·일반행정·감염병·재난·생계 지원금」 vs ai/apps/postcall_summary CHAPTER_TO_TYPE 「대중교통 안내·생활하수도 관련 문의·일반행정 문의·코로나19 관련 상담」. 정답 파일은 운영 쪽에 맞췄다(218). 모델 요약 경로(ai/)를 켜면 다른 이름이 저장된다 — 하나로 합칠 것
마지막 턴 유실 원인 — 실패 종류만 남았다 — 정성윤(선택) — ✅ 2026-09-23 운영 로그에 원인 ②의 흔적이 없다 — 콜 미디에이터 48시간 로그에 전사 전달 실패 0건. 재생기 쪽(w6-replay-last-turn, 류준)이 09-22 에 「마지막 확정을 /ws 로 확인하고 닫는다」로 고쳐진 뒤로는 재현되지 않았다. 다시 나오면 그때 원인 ①(미디에이터에 안 닿음)부터 본다. 원문 — 원인은 ②(미디에이터→서버 전사 저장 실패)로 판정했고 재시도로 막았다(call_registry.ts, 로컬 재현 전후 4/5→5/5). 시간 초과·5xx·연결 끊김 중 무엇이었는지는 09-22 12:20 무렵 운영 미디에이터 로그로만 가른다 — 급하지 않다

2026-09-24 — 판정 자료 수치 정합에서 남은 것 (류준)

오류 내성 곡선이 한 세대 낡았다 — 류준 — 지금 인용 가능한 곡선은 커밋 e966b62 · 골든셋 v1-150.1 · 검색 n 96 · C-5 판정 24(data/processed/error-tolerance/2026-09-22-all.json)인데, 본 표는 5b2b4c4 · v1-150.2 · n 102(run_id 8·9)다. 같은 문장에서 두 표의 숫자를 섞지 않는다는 경고를 문서 세 곳(판정 초안 §3-1 · STATE.md 「실측값」 · jekyll/docs/06)에 붙여 두었지만, 근본 해결은 동결 커밋에서 measure_error_tolerance.py 를 다시 돌리는 것이다 → w8-final-eval-run → 10-01 재측정은 발표 뒤 · 「한 세대 앞 판」으로 인용(decisions/138)
기준선이 BM25 구성 하나뿐이다 — 류준·팀 — scripts/check_baseline.py 의 0.812/0.635 는 BM25 기준선 run_id 4 값이다(절대 원칙 4 대로 최저치를 둔다 — 올리지 않았다). 운영 실구성(NER+KoE5 dense)에는 기준선이 없다 — 그 구성 리포트에 이 값을 들이대면 느슨하다(run_id 8 은 0.971/0.875). 구성별로 기준선을 둘 것인지는 팀이 정할 일이다 → 10-01 구성별 기준선은 최종 측정 뒤(decisions/138)
D-2 유형 정확도 1.0 은 기록된 run 이 아니다 — 류준 — 판정용 run_id 8·9(커밋 5b2b4c4)는 decisions/323 머지 전이라 리포트에 「측정 불가 — 유형이 null」로 찍혀 있다. 09-22 밤의 1.0(10/10)은 --record 없이 잰 값이고, 5종 중 3종(일반행정 4·상하수도 3·대중교통 3) 표본이다 — 감염병·재난·생계 지원금은 0건(decisions/218 2026-09-24 절). 판정문·발표에 쓰려면 다시 잰다 → 10-01 발표에서 D-2 는 「측정 불가」로 인용(138) — 닫는다 → 10-02 정정 — 10-01 최종 측정에 값이 기록됐다. 운영 RDS eval_run run_id 1·2(커밋 19b8400 · 3회 최저)의 postcall.type_accuracy 1.0 · type_null 0 · n 10통화(data/processed/eval-export/2026-10-01-final-*.json). 표본은 여전히 5종 중 3종이다 — 인용할 때 「10통화 · 3종」 을 붙인다
run 8·9 의 eval_run.components 가 NULL 이다 — 류준 — 컬럼은 생겼지만(759b3d4, 09-22 16:53) run 8·9 는 그 11분 전 커밋(5b2b4c4, 16:42)에서 돌았다. 두 run 의 구성은 data/processed/eval-export/2026-09-22-run-8-9.json 과 명령줄에만 있다. 동결 측정에서는 components 가 두 구성에서 다르게 찍히는지 확인한다 → 10-01 정본 인용 시 명령줄로 구성을 밝힌다(138) — 닫는다

2026-09-28 — 류준이 정성윤에게 넘긴 다섯 건, 전부 처리 (정성윤)

_project/handoff/2026-09-24-ryujun-conflicts.md §1-⑥. 다섯 다 닫혔으니 새 미결로 남기지 않고 결과만 적는다.

런북 17장 지식베이스 적재 확인이 401 이었다 — POST /hub/search 를 토큰 없이 부르는 절차였다. 09-23 부터 읽기 문이 닫혀서(READ_AUTH_REQUIRED=true) 그대로는 401 이다. 19장처럼 노드에서 서비스 토큰을 읽어 Authorization: Bearer 로 싣게 고쳤다(값은 찍지 않는다). 런북 전체를 훑어 토큰 없는 읽기 호출은 이것 하나뿐이었다.
배포 뒤 procedure_adoption 눈으로 확인 — 0.2.10 배포 직후 /call-mediator/health 에 "procedure_adoption": "score-floor" 확인. /health 의 spokes 에 retrieval_dense 도 있다(하한이 dense 눈금 위에서 걸린다는 뜻).
되돌리는 손잡이 — infra/k8s/base/call-mediator.yaml:64 에 F2_PROCEDURE_ADOPTION: "top1" 이 주석으로 있다. 확인했다. 시연 중 절차가 안 뜨면 주석을 풀고 적용한다 — 이미지 재빌드는 필요 없다.
배포 중 WebSocket 끊김 — 머지 시점에 active_calls: 0 이었고 미디에이터·서버 파드 둘 다 재시작 0으로 한 번에 떴다.
CI 가 scripts/persona_sim/tests/ 를 하나도 안 돌린다 — ai job 에 한 단계로 붙였다(새 job 을 만들지 않았다). job 이름은 main 룰셋의 필수 통과 검사라 늘리면 룰셋과 .github/ruleset-main.json 을 같이 고쳐야 하고, 그 동기화를 놓쳐 PR 이 머지되지 않은 적이 두 번 있다(CLAUDE.md §7). 내용도 ai/ 쪽이고 스택 없이 0.1초에 도는 순수 판정 함수라 의존성도 더 필요 없다. 28건이 이제 모든 PR 에서 돈다.

2026-09-30 — 수동 QA 2회차에서 남긴 것 (정성윤)

결과표는 진행 기록 2026-09-30-01-seongyun. 게이트(decisions/319)는 통과했고, 아래는 그 과정에서 새로 보인 것이다. apps/ 항목은 조서희 님 몫이라 티켓을 만들지 않고 여기 적는다. → 09-30 decisions/137: 마감까지 정성윤이 apps/ 도 고친다. 아래 [x] 는 그날 코드로 닫은 것(배포 전).

조서희 님 — Q-29 ❌ 「상담원 보호 알림」 배너가 실서버 모드에선 원천적으로 안 뜬다 — CustomerRiskBanner 는 mock 감지기(detectCustomerRisk)만 켤 수 있고, 실서버에선 서버 콜가드 결과를 자막 줄 안의 「🚫 콜가드」 행으로만 그린다(TranscriptPanel.tsx:555~561). 1회차 「닫을 배너 자체가 안 떴다」와 같은 건 — w6-qa-call-screen-fixes 의 「보호 배너」 항목 → 09-30 고쳤다(정성윤, decisions/137) — 실서버 콜가드 행에 「🚫 상담원 보호 알림」 핀·갈래별 문구·✕ 닫기(CALL_GUARD_COPY). 배포 전. 로그 2026-09-30-03
조서희 님 — Q-30 ⚠ 콜가드 갈래가 화면에서 구분되지 않는다 — 서버는 insult·threat·sexual·distress 를 나눠 보내는데(call_guard_dto), 위기 신호를 뺀 셋은 전부 「고객이 흥분한 상태입니다. 안내는 이어가시면 됩니다.」다(TranscriptPanel.tsx:731~735). 협박(threat, DASAN-MANUAL-5.2 즉시 종료 대상)에 「안내는 이어가라」가 나가 매뉴얼과 반대다. SYN-006 에서 성희롱·모욕·협박 세 갈래가 같은 문구였다 → 09-30 고쳤다 — 갈래별 문구(insult 5.1 · threat/sexual 5.2 · distress 5.4). 같은 수정
조서희 님 — Q-55 ❌ 「새 통화 시작」이 실서버 모드에서 아무것도 안 한다 — replay() 가 client.mode !== "mock" 이면 return(useCallMediatorSession.ts:134~140). 통화 후 처리 화면의 버튼과 헤더 「새 통화 시작」 둘 다 이 함수를 부른다. 실서버에선 「대기화면」으로 나가는 것이 답이거나 버튼을 숨겨야 한다 → 09-30 고쳤다 — startNewCall: mock 은 재생, live 는 대기화면으로(useCallMediatorSession.ts)
정성윤 — 콜 미디에이터가 채널이 전부 닫혔다 다시 열리면 통화 상태를 잃는다 — dropIfEmpty(call_registry.ts:244)가 통화를 지우고, 같은 ID 로 다시 열면 발화 번호만 이어 붙이고(w6-segment-id-reuse) procedures·agentFinals·customerTops 는 빈 채로 시작(:262~266). 그래서 채택된 절차가 있는데도 상담원 서류 안내가 판정에 안 돌고(QA -02 에서 /hub/required-docs-checks 0회), 다시 열 때마다 POST /hub/routing-decisions 가 새로 불려 배정 판정이 중복 기록된다(한 통화에 10회+ — 현황판 「배정 판정 전체」 수치에 섞여 있다). 실제 2채널 통화에선 드물지만 재연결·파드 재시작 때 같은 일이 난다. 상태를 서버에서 되살릴지, 통화 종료(/close) 전까지 미디에이터가 들고 있을지 정한다 → 09-30 고쳤다 — 채널이 모두 닫혀도 5분 유예(CALL_RETAIN_MS) 동안 절차·상담원 발화를 잇고 배정 판정은 통화당 한 번. 서버 통화 행만 다시 확인(UPSERT). 테스트 3건, call-mediator 0.2.12
정성윤 — 개발 페이지(/call-mediator/dev)가 음성 인식 오류를 삼킨다 — rec.onerror 가 not-allowed 만 알리고 network·audio-capture·aborted 는 조용히 다시 켠다. 이 PC 에선 8번 연결하고 글자가 한 자도 안 나왔는데 화면에 이유가 없었다. 오류 이름을 상태 줄에 찍기만 해도 된다(QA 도구 결함 — 운영 기능 아님) → 09-30 고쳤다 — 인식 오류 이름을 상태 줄에 그대로, 마이크가 안 돼도 **글자 입력 칸으로 확정 발화를 보낸다(같은 /dev/text). 0.2.12**
팀 — 관리자 화면의 고객 표시가 전부 **** 라 항목을 못 알아본다 — decisions/316 이 display_hint 를 채우지 않기로 한 결과가 블랙리스트·승인요청·감사 로그 세 곳에 그대로다. QA 중 「다 가려져 있어서 잘 안 보인다」(정성윤). 시연에서 관리자가 어느 요청인지 못 가리는 문제라 뒤 4자리 표시를 다시 열지 정한다(316 재검토) → 10-01 뒤 4자리를 연다(144, server 0.1.44) — 닫는다
조서희 님 — 화면 잔손질 묶음(2회차 관찰, 판정 아님) — ① 관리자 설정 탭 안내문·팝업창 카드 본문에 마크다운 원문(**기본값**·`decisions/205`) 노출 ② 지난 통화 보기의 카드 제목이 DASAN-TERM-4.3 처럼 조항 ID 만(panelCardsFromRecord 합성) ③ 우상단 「서류 0/1 안내 완료」가 카드 둘 중 첫 카드만 셈 ④ 근속 연차 도움말 「저장하면…」인데 버튼 없이 즉시 저장 ⑤ 요약 화면 「(규칙 발췌 초안)」 꼬리표가 확정·재수정 뒤에도 남음 ⑥ 「권장 표현」 자리에 대체 문장이 아니라 조항 ID(alternative_source.title) ⑦ 최근 상담기록 목록에 call_id 가 없어 QA 통화를 못 알아봄 ⑧ 자막 시각이 채널 재개마다 00:00 으로 리셋(재개 상황 한정) ⑨ 09-30 승인 항목 만료가 2027.1.28 — 6개월이면 3.30 이어야 한다(입력값이었는지 확인) → 09-30 ①③④⑥⑦ 고쳤다(마크다운 인라인 렌더 · 근거 합산 칩 · 도움말 문구 · 「근거 조항」 머리말 · 목록에 call_id). **남은 것 ②⑤⑧⑨ — ② 는 /record 응답에 procedure_title 이 없어 서버 몫(call_record_schema.py), ⑤ 꼬리표, ⑧ 재개 시각, ⑨ 승인 개월 입력값 확인**
류준 님 — 요약이 위반 발화를 「안내」로 인용한다 — D-1 규칙 발췌가 C-1·C-3 경고가 붙은 상담원 발화(「무조건 공제됩니다」·「위임장까지는 없어도」)를 「상담원 안내/필요서류 안내」로 그대로 싣는다. 컴플라이언스 결과를 발췌 후보에서 빼거나 표시를 붙일지 정한다. 같이 본 것: 팝업창 3.16 카드 본문 끝에 다음 장 제목 ## 4장 일반행정 문의 조각이 붙어 있다(청킹 경계) → 10-01 10-01 위반 발화를 발췌에서 뺐다(server 0.1.44). ## 4장 청킹 조각은 알려진 한계
A-2 화자 분리는 이 QA 로 검증되지 않았다 — 스크립트도 개발 페이지도 화자를 사람이 지정한다. Q-31~33 은 「상담원 줄에 경고가 붙는가」까지다. speaker=auto 실검증은 w7-demo-infra-readiness(게이트 통과로 이제 착수 가능) → 10-01 미검증으로 발표(138) — 닫는다

2026-09-30 — 티켓 정리 뒤 남은 것 (정성윤)

AWS 7월 잔재 삭제 — 사용자 결정 — w4-aws-resource-hygiene 의 명령(VPC vpc-0a2f05f0b6898780f · admin-security · launch-wizard-1 · 쓰지 않는 rds-monitoring-role). 되돌릴 수 없어 정성윤이 직접 «지운다» 고 해야 한다. RDS 권장 2건은 informational 이라 안 한다 → 10-01 사용자 결정 「티켓 닫아」 — 삭제 안 함, 종료 정리에서(w4-aws-resource-hygiene cancelled)
운영 지연 측정 — ! 로 한 번 → 09-30 22:55 했다. 최근 7일 n 26 p95 655ms(예산 안) · 전체 n 115 p95 1,118ms(옛 실험 구성 섞임). w7-latency-budget 에 표. 남은 것은 표본 확대(리허설)와 e2e — scratchpad/qa-latency-check.sh(읽기 전용 SELECT). 값이 나오면 w7-latency-budget 에 §5 네 조건과 함께 적는다
눈 확인 두 개(각 1분) — ① 화면을 연 채 SYN-007 재생 → 「배정 판정 기록됨」 배너(w6-routing-result-ui) ② 관리자 설정 탭에서 상담원 한 명 입사일 입력 → 목록 갱신(w6-admin-agent-hired-on-ui) → 10-01 아래 「완성 절차 뒤 남은 것」으로 옮김
지난 통화 보기 카드 제목이 조항 ID — GET /hub/calls/{id}/record 의 closures[] 에 procedure_title 이 없다(call_record_schema.py). 서버가 규칙표 제목을 실어 주면 화면은 procedure_title ?? procedure 로 이미 받는다(server 한 판) → 10-01 10-01 /record 에 procedure_title 실음(server 0.1.44) — 닫는다
시연 날짜가 정해져야 하는 것 — STT 캡 올리기·되돌리기(w7-demo-infra-readiness) · 리허설(w8-demo-rehearsal) · 발표 구간(w8-presentation). speaker=auto 실검증은 오디오 파일이 있어야 한다 — 없으면 발표에 「미검증」으로 적는다 → 10-01 143 절차 + 138 동결로 날짜 없이 준비 — 닫는다

2026-10-01 — 완성 절차 뒤 남은 것 (정성윤)

2026-10-01 밤 — 최종 점검에서 나온 것 (정성윤)

녹화 때 같이 볼 것 셋 — 관리자 현황판 「오늘」 타일 · 설정의 근속 연차 표시 · 상담원 화면 재연결(탭을 둔 채 Wi-Fi 를 껐다 켠다). 셋 다 배포·테스트만 있고 운영에서 본 기록이 없다
글자 채널 대본 통화의 내부 지연이 예산을 넘는다 — synthetic-script n 92 p95 2,404 ms(예산 1,000), 최악은 배포 직후 첫 act1(p50 2,406 · max 4,719). 음성 통화(n 25)는 p95 722 로 예산 안. 원인(모델 예열 / NER·임베딩 CPU 경합)은 재지 않았다. 녹화는 act1 을 한 번 예열한 뒤 한다(_project/demo-script.md). 발표 뒤 측정
done 티켓에 남은 미체크 완료 조건 — 61건 104줄. 읽어서 가르니 대부분은 뒤에 충족됐거나(운영 반영·QA 로 확인) 줄 안에 「넘김·보류·해당 없음」 이 적힌 것이고, 실제로 미충족인 것은 열 건이다(10-02 — D-2 유형 채점은 10-01 최종 측정에 값이 있어 뺐다): w4-gateway-mono-diarization(화자 분리 실검증) · w4-recommendation-card-id(지연 증가분 미측정) · w5-persona-sim-scripts(대본 사람 검토) · w5-c5-masking-gaps(장민석 검토 2줄) · w5-error-curve-plot(모델 계열 한 그림 · 실을 곳) · w5-b6-no-answer-threshold(「소관 안내」 대 「관련 문서 없음」) · w6-b6-threshold-decision(추천 경로에서 카드 0장 운영 확인) · w6-read-path-token-ui(로그아웃 탭 운영 확인) · w7-agent-registration(Postgres 통합 테스트) · w5-classifier-ner-benchmark(→ cancelled 로 고침). 옛 티켓 본문의 체크박스는 건드리지 않았다 — 그 시점의 기록이다. 발표에는 「알려진 한계」 로

2026-10-02 — 통화 후 모델 요약을 켜며 남긴 것 (정성윤)

.env.example 에 POSTCALL_MODEL= 을 사람이 넣는다 — 보호 훅이 편집을 막는다. GENERATION_MODEL= 아래 한 줄, 주석은 「D-1 요약만 모델로(decisions/146). OLLAMA_URL 과 둘 다 있어야 켜진다」
모델 요약의 D-1 포함률은 미측정이다 — 하네스는 규칙 어댑터를 잰다(0.883). 모델 요약을 같은 10통화로 재려면 하네스에 Ollama 주소를 주고 돌린다(run_eval.py --ollama-url)
서버 등급 · 「상시 / 필요한 날만」 — 올린 직후 실측을 보고 정한다(decisions/146 갱신 절) → 10-02 새벽: 등급은 c7i.2xlarge 로 올렸고 쟀다(요약 한 건 2.5~8.0초). 남은 것은 상시로 둘지뿐이다 — 시간당 0.4032 USD(t3.large 0.104). 고정 IP 가 있어 내렸다 올려도 주소는 그대로다 → ✅ 2026-10-08 정했다 — 등급은 c7i.2xlarge 로 유지하고 안 쓸 때 인스턴스를 내린다(사용자 결정). 요약이 느려지는 것은 받아들이지 않기로 했고, 고정 IP 가 붙어 있어 내렸다 올려도 Cloudflare server A 레코드를 다시 건드릴 필요가 없다. ⚠ 올린 뒤 첫 요약은 모델을 다시 올리느라 느리다 — 운영 실측 14.5초 · 10.7초, 그 뒤 3.7~3.9초(10-02). 올린 날은 예열 요청을 하나 던지고 시작한다(시연 대본의 「녹화 전 act1 예열」과 같은 이유). 내려도 루트 EBS · 고정 IP · RDS 요금은 계속 나간다 — 금액은 재지 않았다(Cost Explorer 로 봐야 한다).
30분 쉰 뒤 첫 요약이 느리다 — 운영 실측 14.5초(모델을 다시 올리는 시간 포함, 그 뒤는 3.7초). OLLAMA_KEEP_ALIVE=30m 이라 30분 쓰지 않으면 모델을 내린다. 정할 것: 그대로 두고 촬영·발표 전에 버리는 통화로 깨울지, 모델을 계속 올려 둘지(메모리 약 2.2~2.7GB 를 상시 쓴다, ollama.yaml 한 줄) → 10-02 새벽 정했다(사용자) — 모델을 계속 올려 둔다(OLLAMA_KEEP_ALIVE=-1). 파드가 새로 뜬 직후 첫 요청만 느리다. 배포 뒤 확인이 남는다
시험 통화 sum-model-1002-01 이 운영 DB 에 남아 있다(10-02 운영 실측용 · 발신 010-0000-0909) — 관리자 화면 통화 목록·오늘 타일에 잡힌다. 지울지 정한다 → 10-02 04:45 지웠다(사용자 지시 — 통화 1 + 딸린 행 115, 통화 58 → 57건)
모델 요약이 같은 입력에 다른 글을 냈다 — Ollama 에서 temperature 0 · seed 고정인데 1막 요약이 142자 / 114자로 갈렸다(10-02 임시 실측, 두 번). 원인 미확인. 리허설과 본 촬영의 요약문이 다를 수 있다. 정할 것: 그대로 두고 발표에서 「초안이라 매번 조금 다르다」 고 말할지, 원인을 찾아 고정할지

2026-10-02 — 대체 표현 문장을 보내며 남긴 것 (정성윤)

지침만 있는 갈래 넷(1.6 · 3.1·3.4 · 3.2 · 4.1)은 여전히 조항 번호만 뜬다 — 매뉴얼에 권장 문장이 없고 「산정 기준과 조회 방법을 안내한다」 같은 지침뿐이다. 지침을 띄우려면 화면 머리말을 「권장 응대」 로 가르는 수정(apps/call complianceLabel)이 같이 간다. 정할 것: 지침을 띄울지(w8-compliance-alternative-phrase)
금지만 있는 갈래 둘(1.2 개인정보 요구 · 4.3 비공개 정보 약속) — 권할 문장이 매뉴얼에 없다. 띄우려면 매뉴얼에 문장을 새로 쓰고 ES 를 재적재해야 해서 발표 뒤다(decisions/138)
소개 사이트 시연 목업 카드 둘이 실물과 다르다(apps/platform/src/mock/demoScenario.ts) — ① 00:21 컴플라이언스: 「저희가 해결할 수 있는 게 아니라서요」 는 실제 규칙이 잡지 않고(직접 넣어 확인), 「상담 품질 가이드라인 4.2항」 은 없는 조항이다(매뉴얼 4.2 는 에스컬레이션) ② 00:54 정서 위기: 「죽겠네」 는 C-6 이 일부러 면제하는 관용 표현이고, 「어조 격앙」 은 운영에서 돌지 않는 D-5 몫이며, 제목 「관리자 알림 발송」 이 본문 「연동 전」 과 모순된다. decisions/145 가 정한 「목업」 꼬리말도 이 카드에는 빠져 있다. 정할 것: 실물이 잡는 문장으로 바꿀지
decisions/142 제목의 「시연에서 동작하고」 는 실물과 다르다 — D-5 는 모듈·단위 테스트만 있고 서버 요청 경로에 배선이 없다(317). 시연 화면의 통화 온도는 「예시 라벨」 이다. 발표에서 「시연에서 동작한다」 고 말하지 않는다

2026-10-02 — 시연 촬영 중 나온 것 (정성윤)

개인정보만 말한 고객 발화가 절차 판정에 쓰인다 — 결함은 그대로, 대본만 피했다 — 시연 1막의 「제 이름은 이고요 주소는 **」 이 가려지고 나면 「이름·주소」 만 남아 검색 1순위가 DASAN-TERM-3.5(수도 사용자 명의변경, 0.653 ≥ 하한 0.635)가 되고 절차로 잡혔다(09-30 QA 에서 처음 확인, 10-02 운영 통화 shoot1-a1 에서 재현). 뒤의 상담원 「신분증 챙겨 오시면」 이 수도 쪽 서류까지 체크해 1/3 이 된다. 사용자 결정으로 **대본 문장만 바꿨다(「초본 받을 사람은 홍길동이고 주소는 …」 → 1순위 4.3 0.763, 운영에서 확인). 고치려면 콜 미디에이터가 가려진 발화로는 절차를 새로 잡지 않게 한다(call_registry.ts recommend) — 하한 0.635 는 decisions/219 사전 등록값이라 값을 바꾸는 길은 아니다. 「제 이름은 ***입니다」 만으로도 3.5 가 0.6345 로 하한 바로 아래다
개인정보 발화마다 관련 없는 카드가 팝업에 쌓인다 — 같은 통화에서 전화·카드·계좌·인증번호 줄의 1순위가 「6.12 지원금 사칭 사기 주의 안내」(0.667~0.713), 2순위에 「3.4 수도요금 자동납부」·「2.7 광역알뜰교통카드」 가 온다. 규칙표에 없는 조항이라 절차는 안 되지만 카드로는 남는다. 위 항목과 원인이 같다
STT 하루 한도의 「하루」 는 UTC 다 — 한국 시간 09:00 에 풀린다 — 콜 미디에이터 장부가 파드의 로컬 날짜로 센다(domain/budget.ts localDay, 파드 시간대가 UTC). 10-02 새벽 촬영에서 전날 저녁(KST) 검증 두 번(240초)이 같은 날로 합쳐져, 세 번째 음성 통화 shoot1-stt3 가 8번째 턴에서 한도 600초에 닿아 끊겼다(로그 「STT 사용량 한도에 닿아 채널을 닫는다」). Claude 가 남은 양을 KST 기준으로 잘못 세어 「두 번 더 된다」 고 안내했다. 정할 것: 날짜를 KST 로 셀지, 문서에만 적어 둘지
음성 통화에서 영어를 한글로 받아 적은 말이 이름으로 가려진 것으로 보인다 — shoot1-stt3 의 「돈 * 아동 수당」·「* 엄마예요」(마스킹 P6 둘). 대본은 「돈, 음, child…」·「Yes, 네, 엄마예요」 다. 규칙만으로는 「차일드」·「예스」 가 가려지지 않는 것을 로컬에서 확인했으므로 운영의 이름 인식 모델(NER) 쪽으로 추정한다 — 원문을 저장하지 않아 어느 단어였는지는 확인할 수 없다. 짧게 끊겨 들어온 앞 통화(shoot1-stt)에서는 같은 말이 가려지지 않았다
음성 자막이 문장·쉼마다 끊긴다 — 음성 파일의 쉼을 줄여 피했다 — 발화 끝 기준 0.7초(0.2.13)에 합성 음성의 쉼(약 0.9초)이 걸려 한 턴이 여러 줄이 된다(shoot1-stt 상담원 8·고객 11줄). 기준은 그대로 두고 두 채널이 함께 조용한 구간을 0.3초로 줄인 파일(data/processed/stt-2ch/syn-004-tight-16k.wav, gitignore)로 한 턴 한 줄을 얻었다(shoot1-stt3 1~7턴). 실제 사람의 말에서는 기준을 올리는 것(로컬 예측 1.0초 이상이면 턴당 한 줄)이 남은 방법이다 — 재지 않았다
촬영 통화 일곱 건이 운영 DB 에 남아 있다 — warmup-1 · shoot1-a1 · shoot1-b1(블랙리스트 요청 9 승인, ****0903) · shoot1-a2 · shoot1-stt · shoot1-stt2 · shoot1-stt3. 지울지, 시연 기록으로 둘지 정한다. 0903 은 승인돼 있어 다시 쓰면 통화 시작부터 배정 배너가 뜬다 → 2026-10-08 정했다 — 발표 뒤로 미룬다(decisions/138 고정 갱신 절). 지우면 되돌릴 수 없고 영상에는 영향이 없다 — 지난 통화 보기에서 어느 통화를 열지만 고르면 된다. 10-08 검증 통화 셋(verify326-muz0sasl·encverify-045718·c6guard-052523)이 더 쌓여 지금 10건이다(encverify-045655·c6guard-052400 은 통화 행이 안 만들어졌다). ⚠ shoot1-b1 은 특히 조심한다 — 마스킹 7종·폭언 3·위반 3·절차 complete·요약 확정·블랙리스트 승인(****0903)이 한 통에 다 든 유일한 완성본이고, blacklist_entry 7 이 그 요청(request_id 9)을 가리켜 지우면 2막 배정 판정 시연의 블랙리스트가 사라진다(외래키는 전부 ON DELETE NO ACTION). shoot1-stt·stt2·stt3 는 STT 하루 600초 한도 때문에 다시 만들기 비싸다. 버려도 되는 것은 warmup-1·shoot1-a1(같은 대본 3회 중복 47줄)·shoot1-a2·검증 셋이다

2026-10-06 — F-3 브리핑 · C-6 일시정지 안내 베타를 열며 남긴 것 (류준)

C-6 폭언 감지는 베타다 — AI 분류기는 데이터가 생기면 학습해서 베타 안에서 쓴다(_project/decisions/221 5절). 지금 탐지는 규칙(어휘 사전)이고, 실제 고객 통화는 개인정보 때문에 모으기 어려워(절대 원칙 7) 학습·측정할 데이터가 없다. 데이터를 얻으면 ① 출처 확보 ② 학습용·측정용 분리 ③ 비속어·욕설 분류기 학습 → CallGuardPort 교체(규칙과 합집합) ④ 하네스로 재현율·정밀도 측정 ⑤ 새 결정 기록으로 운영 켜기. 그전까지 탐지 성능은 측정 불가 — 발표·소개에서 「AI 가 욕설을 정확히 잡는다」 고 말하지 않는다
C-6 베타의 「일시정지·AI 안내」는 상담원 화면에서만 일어난다 — 고객에게 소리를 보내는 경로(교환기 보류·안내 송출)가 없다. 조사: w8-c6-intervention-telephony(정성윤). 화면: w8-c6-intervention-overlay-ui(조서희)
C-6 베타 pause_ms 8,000ms 는 예시값이다(decisions/141) — 안내 문구를 읽는 시간을 어림했다. 잰 값이 아니다
F-3 브리핑 카드는 조서희 님 대기 — w8-f3-briefing-card-ui. 서버 API 가 먼저 올라가야 실서버로 붙일 수 있다(10-14 머지 목표, decisions/129)

2026-10-06 — 상담원 화면 원문 · 저장 마스킹 + 전사 암호화로 바꾸며 남긴 것 (장민석)

운영 키가 아직 없다 — 배포해도 전사는 마스킹본 평문이다(정성윤 님께 넘김 — w8-transcript-enc-key-ops) — 서버 0.1.46 부터 TRANSCRIPT_ENC_KEY 가 있으면 transcript_segment.text 를 AES-256-GCM 으로 싼다. 넣는 절차는 런북 12-2-d. 키를 잃으면 암호화된 전사를 되돌릴 수 없다 — 시크릿 밖(SSM Parameter Store 등) 보관처를 먼저 정한다. .env.example 은 보호 훅이 막아 사람이 TRANSCRIPT_ENC_KEY= 를 넣는다 → ✅ 2026-10-08 켰다 — /health "transcript_encryption":"on". 보관처는 SSM Parameter Store SecureString /callguard/prod/TRANSCRIPT_ENC_KEY. 런북에 없던 것 하나 — 노드에 Parameter Store 권한이 없어 역할에 좁은 인라인 정책 transcript-enc-key(그 파라미터 하나 + SSM 경유 KMS)를 더했다. 19장 11번 확인: DB enc:v1:… · API 마스킹본 · 옛 행 평문 그대로(w8-transcript-enc-key-ops).
배포 순서 — 서버가 미디에이터보다 먼저(또는 함께)(정성윤 님 — 같은 티켓) — 미디에이터 0.2.14 만 먼저 나가면 화면 자막(원문)이 /close 요약에 섞여 마스킹 없이 저장된다. 같은 PR 이면 같은 릴리스로 나가지만, 서버 쪽 배포가 실패하고 미디에이터만 바뀌는 경우를 본다 → ✅ 2026-10-08 — PR #166 이 server 0.1.49 · call-mediator 0.2.16 을 한 릴리스로 냈다(k3s-deploy success).
프론트 문구가 옛 정책 그대로다(조서희 님께 넘김 — w8-agent-screen-plain-copy) — 자막 잠금 아이콘 title 「민감정보가 마스킹되었습니다」(원문이 보이는데 이 문구가 뜬다) · MaskedText.tsx·maskSensitiveText.ts 주석 「실서버는 원문을 절대 주지 않는다」 · .claude/rules/call.md §2. 프론트는 고치지 않기로 했다(사용자 지시) — 문구를 바꿀지는 프론트 쪽 판단이다
운영 DB 를 SQL 로 직접 보면 전사가 enc:v1:… 다 — 운영 확인(로그 10-02 처럼 DB 로 자막 보기)은 API(GET /hub/calls/{id}/transcript)나 같은 키를 쓰는 스크립트로 바꾼다. 일회성 복호화 도구는 만들지 않았다 → 2026-10-08 실제로 그렇게 됐다 — 키를 켠 뒤 새 행은 enc:v1:… 다. 지금 쓰는 확인 경로는 서버 파드 안 API(GET /hub/calls/{id}/transcript)이고, 그것으로 10-08 검증을 했다. 일회성 복호화 도구는 여전히 만들지 않았다.
전사 본문 밖의 저장 텍스트는 암호화하지 않는다 — 요약 summary_text · 블랙리스트 사유·메모 · 지식 공백 설명 · 추천·컴플라이언스 기록은 마스킹만 한다(사용자가 범위를 전사 본문으로 골랐다). 넓힐지는 마감 뒤에 정한다
10-02 촬영한 시연 영상은 마스킹된 화면이다 — 배포 뒤 화면(원문 + 강조)과 다르다. 영상을 다시 찍을지, 그대로 쓰고 발표에서 말할지 정한다

2026-10-08 — 부하 시험에서 나온 것 (정성윤)

검색 경로가 동시 4부터 500 을 낸다 — RuntimeError: Already borrowed — 운영 노드에서 POST /hub/search 에 동시 1→16 으로 걸었더니 동시 4에서 1건 · 8에서 3건 · 16에서 23건(29%) 이 500 이다. 서버 로그의 예외 27건이 전부 같은 것이고 ai/apps/retrieval/adapter/outbound/koe5_embedder.py:76 의 tokenizer(padding=True, truncation=True, …) 에서 난다. HuggingFace fast tokenizer 가 Rust RefCell 기반이라 호출마다 객체에 설정을 쓰는데, 서버가 단일 uvicorn 워커(--workers 없음)라 그 인스턴스 하나를 스레드풀이 공유한다. 고치는 법 셋을 안다 — threading.Lock(한 줄) · threading.local() 토크나이저(병렬까지 확보) · --workers N/레플리카(모델 메모리 ×N). 고정 중이라 넣지 않았다(decisions/138) — 시연은 동시 1~2 라 천장에 안 닿는다. 발표에서는 「천장을 알고 원인을 알고 고르지 않았다」로 말한다(발표 자료 §7). 발표 뒤에 고칠지 정한다.
검색 한 건이 196 ms 다 — 단일 워커라 이론 상한이 초당 5건 — 대조로 둔 GET /health 는 동시 16 에서도 p95 14 ms · 1,246 req/s 라 HTTP 계층은 멀쩡하다. 노드도 끝까지 한가했다(load average 0.05 → 0.19) — 8 vCPU 중 한 코어도 다 못 쓴다.
⚠ 그 시험의 설계 결함 — p50 숫자는 쓰면 안 된다 — 단계마다 질의 번호를 0부터 다시 세어 앞 단계가 던진 질의가 retrieval_cache 에 맞았다 (동시 2 의 p50 4 ms·420 req/s 가 그 흔적이다). 유효한 것은 동시 1 의 196 ms · 오류율 · p95 뿐이다. 다시 잴 거면 단계 사이에도 질의가 이어지게 고친다.

2026-10-07 — 컴플라이언스 권장 문장 확인에서 나온 것 (류준)

컴플라이언스 경고가 한 발화에 두 번 실린다 — 로컬 SYN-016 7번 발화 「확실히」 에 findings 2건이 rule_code·phrase·alternative_source 까지 같았다(10-07, 류준). 규칙 두 개가 같은 낱말에 걸린 것으로 추정한다(원인 미확인). 화면에 같은 배너가 두 줄 뜰 수 있다 — 서버에서 같은 항목을 합칠지 정한다(w8-compliance-alternative-phrase)

2026-10-13 — AI 파트 심사 대비 검토에서 나온 것 (류준)

NER 교체 — 대상은 정했고 반영만 남았다(_project/decisions/222). 빼면 STT 오류 20%에서 누락 2→6 이라 빼지 않는다. 교체 대상 vmaca123/korean-pii-ner-v3(KLUE 기반 CC-BY-SA-4.0): 누락 0(오류 20%까지) · 실제 발화 오탐 14→25 · 메모리 +1.35GB → 서버 파드 상한 3Gi→4Gi 가 함께 필요(정성윤 님). 10-08 고정 해제 뒤
GCP 콘솔에서 Speech-to-Text 데이터 로깅이 꺼져 있는지 확인 — 기본값은 꺼짐, 코드에 옵트인 없음. 정성윤 님 콘솔 권한(08 §3)
CLAUDE.md §1 「정부는 연내 300만 전망」 은 정부 자료로 확인되지 않았다 — 머니투데이 편집자주뿐(7월 말 290만 3,463명). 루트 규칙 파일이라 이번엔 고치지 않았다
임베딩 토크나이저 동시성 수정 — 10-08 부하 시험의 원인 koe5_embedder.py:76(AI 파트 코드). 스레드별 토크나이저가 워커 증설보다 싸다. 동결 해제 뒤
운영 요약 모델이 후속조치를 빠뜨린다 — 포함률 0.717(규칙 0.883), 「조치」 2/10. 후속조치를 규칙 초안에서 붙일지 정한다(03_new_measurements.md M7)

2026-10-15 — 시연 최종본 확인 · 발표 지표 보강에서 나온 것 (류준)

브리핑 카드의 범주와 문장이 어긋난다 — 시연 최종본 4:08: 칩 「서류 보완」 · 문장 「재문의로 보입니다」. 모델 범주가 규칙과 같아 통과했지만 briefing_problems 가 문장 속 다른 범주 이름을 보지 않는다. 문장에 다른 범주 이름이 있으면 규칙 문장으로 — 한 줄, 동결 해제 뒤
온프레미스 STT 가 정확도는 더 낫다 — 같은 20발화 8kHz 배치: Google STT v1 WER 0.358 · Whisper large-v3-turbo 0.137(docs/ai-part-review/09 2-1). 스트리밍 구성과 운영 CPU 지연은 미측정 — 1년 로드맵 근거로만 쓴다
리랭커는 지금 골든셋에서 효과가 있다 — 후보 20 → 102/102 · MRR 0.929, 단 CPU 질의당 1.7~1.8 s. GPU 가 생기면 다시 본다(07_metrics_fill.md)