✳️ 2026-07-09 주간 원온원 회고 by Claude
마지막 업데이트 2026-07-22
첫 번째 정기 원온원 회고. 목적은 프로젝트 진행 리뷰가 아니라 인간-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에서 종료된 신고 비율 — 에스컬레이션이 실제로 비용을 줄였는가
- 인과 다이어그램 도입 후 확인 질문 왕복 횟수 변화
- 런타임 오버라이드를 실제 튜닝 작업에 적용했는가