2026.06.11 작업일지 v1.0.0
21:5x, 나는 안전장치 하나에 마침내 빗장을 걸고 있었다. 23:0x, 맥미니가 “여기부턴 못 간다”며 마지막 한 칸을 본진으로 넘겼다. 23:1x, 그 한 칸 앞에서, 죽은 줄 알았던 브라우저가 문을 잠그고 있었다.
오늘은 “이메일 주소 한 줄”을 여러 앱에 똑같이 박는, 단순해 보이는 일이 종일 이어달리기를 한 이야기다. 저장소에서, 웹페이지에서, 그리고 마지막으로 구글 플레이 콘솔에서 — 같은 한 줄이 surface마다 다른 모습으로 나를 기다렸다. 그 사이에 안전장치 하나가 관찰 모드를 졸업했고, 함대는 여느 때처럼 자기 일을 했다.
1. 증거 없이는 코드도 없다 — 게이트에 빗장을 걸다
낮 동안의 주인공은 ‘Preflight Evidence Gate’였다. 큰 작업(재구현·삭제·배포)에 손대기 전, “메모리가 아니라 코드를 먼저 보라”고 강제하는 훅이다. 며칠간 본진 한 노드에서 **관찰 모드(로그만, 차단 X)**로 돌린 로그 22건을 까봤다. 진짜로 막았어야 할 사고는 0건, 대신 오탐 두 종류 — 문서 파일(tasks.md·worklog) 안의 “재구현” 같은 단어를 자연스럽게 물고, 핵심 모듈 한 개를 정상 편집하는 것까지 신호로 잡았다.
그래서 두 가지를 깎았다. .md/.json 같은 문서·상태 파일은 게이트에서 빼고(770ff89), 차단은 부정 키워드 + 핵심 모듈이 동시에 걸릴 때만 — 즉 사고의 지문(naming_engine.dart 재구현 같은) 한 패턴으로 좁혔다. 그 위에서 본진 한 노드만 관찰→차단으로 승격했다(dcd3a98, 결재 A). 오차단 비용이 ‘Edit 마비’가 아니라 ‘VERIFY 증거 한 번 더’로 줄었으니, 그건 게이트의 설계 목적 그 자체였다.
배운 것 — 안전장치는 “관찰 → 정제 → 좁은 차단” 순서로 졸업시켜야 한다. 처음부터 전 노드에 빗장을 걸었으면, 오탐이 함대를 멈췄을 것이다.
2. 여섯 개의 저장소, 그리고 막다른 한 칸
저녁의 바통은 8개 앱의 지원 이메일 통일이었다. 맥미니가 앞 구간을 달렸다 — 저장소 6곳의 메타데이터를 회사 메일 minusbetastudio@gmail.com으로 바꾸는 PR 6건 머지, 그리고 공개 개인정보처리방침 8장을 모두 회사 메일로 교체해 라이브 검증까지(a4696af). App Store 쪽은 공개 리스팅에 지원 이메일 칸 자체가 없어 손댈 게 없었다.
막힌 건 마지막 한 칸, 구글 플레이 콘솔의 연락처 이메일이었다. 업로드용 API(서비스 계정)에는 이 필드가 노출되지 않는다 — 사람이 브라우저로 로그인해 콘솔 UI에서 고쳐야 한다. 맥미니에는 그 구글 세션이 없었다. 그래서 그 한 칸만 본진으로 넘어왔다.
3. 좀비가 문을 잠그고 있었다
본진에서 플레이 콘솔을 열려는데 브라우저가 거부했다.
Browser is already in use for .../mcp-chrome-..., use --isolated처음엔 “세션이 죽었나” 싶었다. 하지만 천천히 봤다 — 프로세스를 세어 보니 Chrome 여러 개가 살아서 떠 있었고, 전부 자동화 전용 프로필을 물고 있었다. 직전 세션이 40% 하드클리어로 닫히면서 자기가 띄운 브라우저를 닫지 못하고 떠난 것이다. 떠난 세션이 SingletonLock을 쥔 채 사라졌고, 새 세션은 그 문을 못 열었다.
좀비 프로세스를 정리하고 잠금 파일을 풀었다. 중요한 건, 로그인 쿠키는 프로필 디렉터리에 그대로 남아 있다는 점 — 프로세스를 죽여도 세션은 무손실이다. 다시 여니 콘솔이 열렸다. 개발자 계정 ‘DAEJONG KANG’, 로그인 멀쩡했다.
배운 것 — “브라우저가 죽었다”는 에러는 종종 죽은 게 아니라, 떠난 세션이 문을 잠가둔 것이다. 프로세스를 죽여도 디스크의 세션은 살아 있다.
4. “즉시 게시” — 재제출은 없었다
플레이 콘솔에 실제로 등록된 앱은 여섯 개였다. 8개 목록 중 한컵·로또계산기는 애초에 플레이에 없었으니, 스코프는 6이었다. 실측이 스펙을 이긴 순간이다.
먼저 한 앱(한줄일기)만 카나리로 고쳤다. 연락처 이메일을 회사 메일로 바꾸고 저장하자 다이얼로그가 떴다 — “이 변경사항은 즉시 게시됩니다. 보통 1시간 이내에 표시됩니다.” 검토도 재제출도 없었다. 연락처 이메일은 심사 파이프라인을 타지 않는 비제출 메타였다. 그걸 확인하고 나머지를 한 칸씩 채웠다.
| 앱 | 옛 메일 | 바뀐 메일 |
|---|---|---|
| 한줄일기 / 더치페이 | me.com | minusbetastudio@gmail.com |
| 메모요 / 포모도로 | naver | minusbetastudio@gmail.com |
| 약먹자 | 개인 gmail | minusbetastudio@gmail.com |
| 단어요 | (이미 회사 메일) | — |
마지막 포모도로를 게시하려는 찰나, 밤 11시 20분 정각에 나이트리 작업일지 잡이 끼어들어 확인 클릭이 끊겼다. 죽은 줄 알았더니 — 새로고침해 보니 회사 메일로 이미 영속돼 있었고, 편집 폼을 다시 열자 저장 버튼이 비활성이었다(= 바꿀 게 없다 = 이미 저장됨). 단정하지 않고 한 번 더 확인한 게 맞았다.
5. 그래서 뭐가 남았나
여섯 개 앱의 플레이 연락처 이메일이 전부 회사 메일로 통일됐고, 저장소·웹·앱스토어·플레이 — 네 군데 surface가 모두 정리됐다. 재제출 트리거는 0건. 안전장치 게이트는 한 노드에서 관찰을 졸업해 좁은 차단으로 LIVE, 일주일 오탐 실측 뒤 함대 전체로 넓힐지 정한다.
그 사이 함대는 평소처럼 굴러갔다 — 첫이름의 작명서 PDF를 결과 메일 디자인과 1:1로 맞추고 입력폼 UX를 손봤고(c771802), 백로그를 idle 노드가 스스로 집어 가는 픽업 워커를 세웠고(T-260611-03), 회사 랜딩 푸터에 스튜디오 로고를 박았고(bd69927), 함대 운영기를 다룬 뉴스레터 한 편을 세 채널에 올렸다.
단순한 한 줄이, 끝까지 단순하지 않았다.
다음 이야기는, 일주일 뒤 그 게이트가 함대 전체로 넓혀질지의 이야기.
— 강대종 / @ssamssae