✳️ 2026-07-09 주간 원온원 회고 by Claude

마지막 업데이트 2026-07-29

문서 읽는 법 · 회고식

이 문서는 이렇게 읽으면 됩니다

✳️ 2026-07-09 주간 원온원 회고 by Claude의 핵심을 회고식으로 먼저 안내합니다. 기술적 결론과 원문 근거는 아래 본문에 보존되어 있습니다.

핵심 흐름 펼쳐 보기

대상 기간과 작업 스트림을 확인합니다.
중요한 결정과 배운 점을 읽습니다.
다음 액션으로 회고를 실행 항목에 연결합니다.

1. 주간 작업 스트림 (배경)
2. AI 활용 분석 (본론)
3. 대화에서 나온 결정 사항

대상 기간: 2026-07-02 ~ 07-09 · 재료: Claude Code 세션 65개(사용자 메시지 572개) + develop 커밋 이력 · 생성: 2026-07-09 KST

첫 번째 정기 원온원 회고. 목적은 프로젝트 진행 리뷰가 아니라 인간-AI 협업 방식의 개선 — 잘 먹힌 패턴을 굳히고, 마찰·비효율을 스킬/메모리/워크플로우 변경으로 환원한다.

1. 주간 작업 스트림 (배경)

🔊 iOS 덕킹 (PPI-1097→1101)3종 접근 실패 후 WebRTC loopback으로 해결·머지, 게인 튜닝 6회

🎙 녹음 파이프라인 (1098/1106/1107)stem+wallclock 재설계, epoch 손상 stem 디스크 폭주 hotfix, suspended AudioContext 픽스

🔍 현장 이슈 분석 (거의 매일)LogRocket 멀티에이전트 분석 7건+ → PPI-1112 진단 로깅으로 환류

🧰 메타 작업스킬 4개 신규: branch-diff-viz, ppi-grafana-health, sanity-checking, oneonone

iOS 덕킹과의 전쟁: EC 동적 토글(복구 불능) → audioSession 힌트(실기기 실패) → EC 상시 OFF(Realtime 인식 불가) 3종 실패 후 WebRTC loopback 로컬 출력으로 최종 해결, develop 머지(1dc7317d). 이어 loopback vs 영상 볼륨 격차로 게인 튜닝 커밋 6개(0.5→0.25→진단 극단값→0.25→0.15→0.1).
녹음 합본: amix 갭 붕괴로 인한 겹침/무음 → stem 분리+wallclock+post-mix 재설계(PPI-1098). 손상 stem(epoch 1970)이 56년 무음 인코딩을 유발해 prod 디스크 100% 폭주 → hotfix(PPI-1106). iOS suspended AudioContext TTS 무음 수정(PPI-1107).
현장 이슈: 박제후 마이크 무음, 홍재하 TTS 고착, 장세희 재생 큐 정지, 도윤우 차량 네트워크, 김서랑/안나연 TTS 지연(Typecast 바디 지연 판별), 영상 종료 후 자동전환 실패 케이스 분류. 분석 결과가 아동측 진단 로깅 추가(PPI-1112)로 환류.
기능 작업: PPI-1085 접속 제한 소프트 게이트, PPI-1103 태그 히스토리(+상한), PPI-1088 정정 주입 검토, 전체 코드 감사(멀티에이전트 6팀).

2. AI 활용 분석 (본론)

✅ 잘 먹힌 패턴

멀티에이전트 refuter(반증) 패턴: 세션 매칭 + Grafana + 가설별 반증 에이전트 병렬 투입. 도윤우 건 "네트워크 열화" 확정, 김서랑 건 "Typecast 바디 지연" 특정. 단독 분석 대비 오판 감소 체감.
재현 루프 협업: 사용자 실기기 재현 → Claude devtools 콘솔 직접 읽기 → 계측 로그 심기 → 재재현. PPI-1098 녹음 디버깅이 이 방식으로 하루 만에 해결.
분석 → ppi-docs 문서화 → 메모리 저장 사이클: 실패 이력(audioSession 힌트 등)이 메모리에 남아 재시도 방지. 판별법 메모리가 누적되어 재사용 가능한 자산이 됨.
반복 작업의 스킬화: ppi-grafana-health는 제작 다음날 3회 사용. "health 체크해줘" 한 마디로 조회~HTML 리포트까지.

⚠️ 마찰 지점

게인 튜닝 = 커밋 6개 + dev 배포 6회 + iPad 실기기 확인 6회. 값 하나 조정에 전체 배포 루프. 중간에 배포 갭으로 미적용 값을 보고 진단이 흔들려 극단값 진단까지 진행.
확인 질문 연쇄: PPI-1106 epoch 건에서 "~라는 거야?" 확인 왕복 10회+. 검증 과정 자체는 필요(사용자 확인)하나, 첫 보고에 인과 다이어그램이 있었다면 구조 확인 질문은 생략 가능했음.
refuter 패턴의 비용: 신뢰도는 높지만 토큰·시간 과다(사용자 확인). 전 가설 병렬 반증 + 에이전트마다 수 MB LogRocket JSON 원본 중복 파싱 + 아는 패턴도 풀 조사가 주범.

3. 대화에서 나온 결정 사항

결정 1 — 실기기 튜닝 값은 런타임 오버라이드로. 병목은 "배포 대기 + 실기기 확인"으로 확인(Q1). 튜닝 상수(LOOPBACK_LOCAL_GAIN 등)는 URL 파라미터/localStorage 오버라이드 + 현재 적용값 화면/콘솔 표시를 함께 구현 → 6회 배포가 1회로. 메모리 runtime-tunable-override 저장.

결정 2 — 원인 분석 첫 보고에 시간순 인과 다이어그램 필수. 확인 질문 왕복은 필요한 검증 과정이지만, 인과 다이어그램이 있으면 구조 질문이 줄고 판단 질문만 남는다(Q2). 보고 형식: 결론 1줄 → 인과 다이어그램 → 근거 로그. 메모리 analysis-report-causal-diagram 저장.

게스트 재접속 → 기존 ffmpeg SIGKILL → 헤더 없는 OGG (epoch=0)
                                          ↓
            post-mix 입력에 포함 → 기준시각이 1970으로 당겨짐
                                          ↓
            정상 stem과의 갭 56년 → 무음 인코딩 무한 진행 → 디스크 100%

결정 3 — repro-path 스킬에 3단계 에스컬레이션 반영 (적용 완료). refuter 패턴의 신뢰도는 유지하되 비용을 증상 난이도에 맞춤(Q3).

레벨	이름	에이전트	내용
L0	패턴 대조	0명	판별법 메모리·ppi-docs bugs 문서와 대조 → 매칭 시 확인 로그 1~2개만 조회 후 종료. 신고의 약 절반이 여기서 끝날 것으로 기대.
L1	경량 조사	1~2명	child-session 필수, host/grafana는 증상이 요구할 때만. 반증 없이 결론+확신도 명시. 확신 "높음"이면 종료.
L2	풀 반증 검증	3+명	확신 "중" 이하 또는 "풀 검증" 명시 요청 시만. 반증은 유력 가설 1개에만 순차 적용(전 가설 병렬 금지).

공통 규칙: LogRocket export JSON은 오케스트레이터가 1회만 전처리해 요약본을 서브에이전트에 배포(원본 중복 파싱 금지).
사후 환류: 새 패턴 확정 시 판별법 메모리 저장 제안 → 다음 동일 증상은 L0에서 종료.

4. 다음 주 우선순위 / 실험

#	실험	기대 효과	상태
1	튜닝 값 런타임 오버라이드 (다음 튜닝 작업부터 적용)	커밋·배포 루프 6회 → 1회, 배포 갭 오진단 제거	다음 작업 시
2	분석 보고 고정 포맷 (결론→인과 다이어그램→근거)	확인 질문 왕복 감소	메모리 적용
3	repro-path 3단계 에스컬레이션	토큰·시간 비용을 증상 난이도에 비례하게	스킬 반영 완료

5. 다음 회고 확인 항목

repro-path L0/L1에서 종료된 신고 비율 — 에스컬레이션이 실제로 비용을 줄였는가
인과 다이어그램 도입 후 확인 질문 왕복 횟수 변화
런타임 오버라이드를 실제 튜닝 작업에 적용했는가