Joyuno's Dev Blog

2026-08-07 (금) 개발일지

dev-blog

오늘은 여러 프로젝트를 병렬로 진행했는데, 가장 흥미로운 건 demo_apps 의 토큰 만료 문제와 lepons cockpit 의 원격 트랜스크립트 비용 최적화였다. 전자는 데이터 손실 우려로 시작했지만 실제론 인증 문제였고, 후자는 초기 설계 방향이 완전히 틀렸다는 걸 측정으로 증명하게 됐다.

demo_apps — 토큰 만료로 조인이 멈춘 이유

처음엔 백엔드 복구 후 조인이 정상 작동하는지 확인이 급했다. 데이터가 크게 쌓여 있었거든 — events 가 96 개에서 1899 개로, traces 가 200 개로 늘어난 상태였다. 단순히 DB 에러로 데이터가 버려지는 건 아닐까 하는 불안감이 컸다.

그런데 최신 트레이스를 직접 들여다보니 토큰 만료가 원인이었다. 데이터 문제가 아니라 인증 자체가 끊긴 거였다. 백엔드를 복구한 후 조인이 재개되는지 확인하려면 코드 변경이 필요했다.

worktree 로 격리해서 3 가지 구현을 모두 진행했다 — 조기 스킵, 캐시 서빙, 재귀 감시. 그런데 worktree 가 6e1167c 기반이라 dev 최신(P1~P8 포함)보다 뒤처져 있었다. dev 기준으로 맞춰야 했고, 그 과정에서 iOSJankAdapter 가 이미 SharedResourceBuilder 를 쓰고 있다는 걸 발견했다. 서버가 본 게 구빌드 데이터일 가능성이 있었다.

더 급한 문제는 allowlist 회신이 없는데 클라이언트는 이미 saju-* 로 전환돼 있다는 것. 문서 §4 가 경고한 순서 위반 상태였다. 주말 정리까지 모두 끝났고, 이제 서버팀 응답을 기다리는 중이다.

lepons cockpit — 훅이 아니라 측정이 정답이었던 이유

처음엔 원격 트랜스크립트 비용을 줄이기 위해 훅으로 구현하려고 했다. 에이전트가 알려준다는 말에 “모델 판단과 무관하게 결정적으로 실행된다”는 성질이 좋아 보였거든. 하지만 비용이 어디서 나는지 재기 전에 메커니즘부터 골랐다는 게 문제였다.

실제 측정 지점을 찾아보니 main/index.ts:341-348 에서:

새 SSH 연결 → ls -t 로 최신 .jsonl 찾기 → tail -c 500000 → 연결 종료

저장소마다 10초에 한 번, 핸드셰이크 + 최대 500KB. 이게 실제 비용이었다. 훅은 이 비용을 절감하지 못했다.

같은 함정이 네 번째 변주로 나타났다 — 앞선 세 개를 막으려던 수정 자체가 원인이었다.

시행착오 기록:

함정 발견 시점
stat -c (GNU) vs -f (BSD) 스펙 작성 중
find -printf (GNU 전용) 스펙 작성 중
total vs 합계 (로케일) 실물 노드 검증 중
테스트가 시뮬레이션으로 바뀜 명령 수정 후

마지막 함정이 가장 교훈적이었다. 81: test("the command finds a nested subagent transcript", () => { 이 테스트가 시뮬레이션으로 바뀌어 있었다. 원래는 실제 파일을 만들고 명령을 실행하는 통합 테스트였는데, 어느 시점부터 mkd 로 시작하는 부분이 주석 처리됐다. 그 때문에 xargs 버그 같은 실제 쉘 에러를 절대 잡을 수 없었다.

해결 방향:

  1. 실제 tree-walk 테스트 복원 — 중첩 파일 생성 → 명령 실행 → 파싱
  2. 재귀 감시에 fallback 구현 — fs.watch 실패 시 polling 으로 전환
  3. 캐시 서빙 조건 추가 — mayServeCache 로 불필요한 원격 호출 차단

최종적으로 203/203 테스트 통과, typecheck 와 build 모두 성공했다. 인계 문서(2026-08-07-codebase-sharing-handoff.md)를 작성해 맥북에서 이어가는 법을 정리했다. 푸시 대기 중인 165 개 커밋이 있다.

하네스 — 문서 일관성 검증의 함정

riff FRAME 질문 업그레이드 검증 과정에서 6 개 위반 사항을 찾았다.

위반 원인 해결
V1 money_flow 게이트 태그가 수집 질문 없음 설계 §3 Q6 추가
V3 Q7 참조가 남아있음 Q8 로 재키
V4 답변-아키텍처 Router 표현 부정확 문구 수정
V7 스코어카드에 프레임워크명 노출 마스킹 처리

가장 흥미로웠던 발견: 소셜/데이팅 상세 규정이 caution.md 에만 존재하고, 소셜/모니터링정책/개인정보 전담 페이지는 공개 문서에 없다는 것. 사이트맵 100+ 페이지를 전수 조사했지만 찾을 수 없었다. 사업자 유형도 “개인 사업자·법인 사업자 모두 가능”이라고 명시되어 있는데, 소셜 체크리스트는 “법인 등록”만 콕 집고 있어 문서 내 모순이 있었다.

사주 엔진 — 정답지 구축의 천장

사주 엔진 정합성 벤치마크를 위해 『적천수천미』 503 개 명례를 파싱했다. 90 개 표본을 sonnet 에이전트 3 개가 용신·강약·격 라벨링을 했고, 70 건을 확정했다.

핵심 발견: 규칙을 아무리 튜닝해도 숫자가 안 올랐다. 이유는 케이스가 강약 판정에서 다른 분기로 라우팅돼 룰이 도달조차 못 했기 때문이다. 이를 잡으려면 강약 가중치→통관→병약→격국까지 전부 손대야 한다. 결국 임철초 원전 수준의 해석층이 필요했다.

한국 웹에서 공개된 자료 중 “8 글자 명식 + 명시된 신강/신약 + 명시된 용신 오행”을 모두 갖춘 사례는 4 건에 불과했다. 정답지 구성을 위해선 명리전문가와의 직접 인터뷰가 필수라는 결론에 도달했다.

오늘의 한줄

측정 없는 최적화는 방향을 잃고, 통합 테스트 없는 버그 수정은 숨은 함정을 남긴다.