2026.08.24 작업일지 v1.0.0
00:34, 터미널에서
gg를 쳐도 그록 창에 안 들어가졌다. 01:06, 「초록인 테스트가 진짜 뭘 지키는지」 재는 도구를 머지했다. 16:20, 그 도구가 하루 종일 나를 잡아낸 뒤에야 마지막 함정이 닫혔다.
오늘 고친 것들은 서로 달라 보였다. 사진이 자꾸 따라붙는 문제, /clear 치면 창이 튕겨 나가는 문제, 배차 권한, 상태줄 위치. 그런데 파고들수록 같은 뿌리가 나왔다 — 초록인 테스트가 이미 죽은 계약을 지키고 있었다. 자체 검증이 「이상 없음」이라고 말해 주는 동안 결함은 하루를 갔다.
1. 네 번 고쳤는데 안 고쳐진 것
폰에서 글만 보냈는데 화면엔 안녕하세요 [Image #1] 이 제출된다. 어제부터 네 번 고쳤다. 입력칸 지우는 키를 Escape → Ctrl+U → Backspace → Ctrl+C 로 계속 갈아탔다.
그런데 여전히 안 고쳐진 것으로 보였다. 이유는 단순했다. 수리가 기계까지 안 왔다. 본진 클론이 브랜치에 묶여 12커밋 뒤였고 다른 두 노드도 옛 코드를 돌리고 있었다. 앉은 자리에서는 「네 번 고쳤는데 안 됨」과 「안 고침」이 똑같아 보인다.
더 나쁜 건 같은 함수를 두 노드가 따로 고쳐 PR 두 개를 냈다는 것이다. 워커는 티켓 하나만 보기 때문에 아무도 몰랐다.
그리고 다섯 번째 층이 있었다. 맥 클립보드에 스크린샷이 남아 있으면 입력칸을 아무리 지워도 붙여넣기가 사진을 되살린다. 이건 내가 아니라 워커 노드가 찾아냈다 — 클립보드 내용을 직접 조회하고, 붙은 사진 두 장의 해시를 대조해서.
배운 것 — 진단 능력과 배송 능력은 다른 축이다. 맞는 수리 네 건이 저장소에만 쌓이면, 쓰는 사람에게는 아무것도 안 고친 것과 같다.
2. gg 가 없는 방 문을 두드리고 있었다
tmux 에는 「소켓」이라는 별개의 방이 여러 개 있을 수 있다. 어제 낮 커밋이 그록 창을 다른 방으로 이사시켰는데, 그 커밋이 손댄 파일 12개에 gg 가 없었다. 브릿지·기동면·헬스와치·노드감시 넷은 따라갔고 gg 하나만 옛 주소를 들고 남았다.
tmux -L grok has-session → no server running (gg 가 보던 방)
tmux -L default has-session → rc=0 (진짜 그록이 있는 방)여기서 진짜 문제가 나왔다. gg 의 테스트가 「소켓은 grok 이어야 한다」고 단언한 채 초록이었다. 죽은 주소를 성실히 지켜 주고 있었다. 픽스처가 사고를 막은 게 아니라 굳혔다.
덤으로 더 오래된 결함도 나왔다. gg 는 심볼릭 링크로 설치돼 있는데 자기 위치를 푸는 코드가 링크를 안 따라가서, 라이브러리 경로를 통째로 못 찾고 있었다. 조용히 넘어가는 구조라 아무도 몰랐다.
3. 초록인 테스트는 증거가 아니다
여기서 방향을 틀었다. 개별 결함을 계속 쫓는 대신 계기 자체를 검증하는 도구를 만들었다.
원리는 단순하다. 픽스처에 결함을 일부러 되살려 넣고 적색이 나는지 본다. 통과해 버리면 그 픽스처는 아무것도 안 지키고 있는 것이다. 픽스처가 자기 변이를 주석 한 줄로 들고 다닌다:
# @mutate-why <이 변이가 되살리는 결함>
# @mutate <대상파일> | <찾을 것> | <바꿀 것>러너 자신도 같은 잣대를 받는다. 임시 저장소에 「지키는 픽스처」와 「아무것도 안 지키는 픽스처」를 세워 놓고 후자를 잡아내는지 검사한다. 거짓 초록을 못 잡는 검출기는 그 자체가 거짓 초록이니까.
첫 전수 조사 결과가 숫자로 나왔다 — 변이 미선언 픽스처 768본.
그리고 만들자마자 나부터 걸렸다.
| 무엇을 잘못 쟀나 | 어떻게 드러났나 |
|---|---|
| 세션 동일성을 id 로 판정 | 대상이 유일한 세션이면 죽일 때 서버까지 죽고 id 가 처음부터 다시 세어져, 죽였는데 「같은 id」 로 보였다 |
| 환경변수 검사가 첫 기동과 같은 값을 잼 | 전달 코드를 빼도 통과 |
| 경로가 어긋나 함수가 아예 안 불림 | 그 rc=127 을 「제대로 거부했다」로 읽어 초록 |
| 추종 조건만 재고 핵심(조용한 실패) 을 안 잼 | 「진단을 뺀다」 변이가 그대로 통과 |
네 번 다 테스트를 돌려서는 안 잡혔고, 결함을 되살려 본 뒤에야 드러났다.
배운 것 — 픽스처가 초록이라는 사실은 그 자체로 아무것도 증명하지 않는다. 변이로 적색을 만들 수 있어야 비로소 무언가를 지키고 있다는 뜻이다.
4. 답이 없던 게 아니라 다른 파일을 보고 있었다
오후에 신고가 들어왔다. 터미널엔 27초 만에 답이 완성됐는데 폰엔 「180초 무진전」 실패가 떴다.
워커 노드가 날카롭게 짚었다 — 이 증상의 수리 네 건이 전부 기다리는 시간을 늘리는 층이었고, 「보는 파일이 맞나」를 묻는 층은 0건이라고.
프로브를 떠 보니 그대로였다. 브릿지는 켜질 때 「이 대화 볼게」라고 주소를 적어두는데, 그록이 도중에 새 대화로 갈아탔다. 브릿지는 새벽에 멈춘 옛 대화를 오후 내내 노려보고 있었다.
고치되 함부로 따라가진 않게 했다. 「멋대로 새 폴더를 따라가면 엉뚱한 대화를 집는다」는 이전 판단이 여전히 옳기 때문이다. 조건 넷이 전부 맞을 때만 옮긴다 — 옛 대화가 죽어 있고, 확실히 최신인 후보가, 정확히 하나 있고, 최근에 쓰였을 때.
그리고 조용히 죽지 않게 했다. 실패 문구에 「갈렸다 + 양쪽 주소 + 마지막 기록 시각」이 실린다. 이 사고의 진짜 피해는 잘린 것이 아니라 왜 잘렸는지 아무도 몰랐던 것이었다.
5. 빨간 테스트가 옳았다
전체 스위트에 계속 빨간 게 하나 있었다. 이름이 공교로웠다 — dead_session_with_stale_state. 들여다보니 픽스처가 아니라 코드가 틀렸다.
어제 커밋이 「꺼진 세션은 이어 쓴다」로 바꿨는데, 그 대화가 디스크에 있는지는 안 봤다. 주소만 적힌 쪽지가 남고 공책은 버려진 상태면 이어 쓸 게 없어서 즉사한다.
여기서 오늘 가장 뚜렷한 패턴이 나왔다. 두 픽스처가 정반대를 단언하고 있었다. 하나는 「새 주소를 써야 한다」며 영영 빨갛고, 하나는 「옛 주소를 이어 써야 한다」며 초록이었다. 둘 다 그 대화가 실재하는지를 안 만들어놓고 단언했다. 조건별로 갈라 주니 둘 다 성립했다. 그리고 그 어제 커밋은 2번에서 gg 를 남겨둔 바로 그 커밋이었다.
마지막은 경로였다. 맥에는 별명 주소가 있다 — /tmp 라고 쓰면 실제로는 /private/tmp 다. 그록은 대화 폴더 이름을 작업 위치 글자 그대로 만든다. 쓰는 쪽이 진짜 주소로 만든 폴더를 읽는 쪽이 별명으로 찾으면 텅 빈 엉뚱한 폴더를 본다. 증상은 언제나 같다 — 「화면엔 답이 났는데 무응답」.
오늘만 세 번 나왔다. 실사고 한 건, 내 테스트 두 건. 세 번 다 사람이 눈으로 잡았다. 세 번 잡았으면 네 번째는 놓친다. 그래서 작업 폴더를 일부러 별명으로 준 다음 양쪽이 같은 폴더를 가리키는지 기계가 대조하게 했다.
6. 그래서 뭐가 남았나
머지 20건, 티켓 31건 종결 / 32건 신규. 사진 다섯 층, /clear 창 유지, gg 소켓, 머지 영수증 오배송, 상태줄 게이지, 30분 상한, 배차권 개방과 그 깊이 계수기, 브릿지 세션 추종, 실재 확인, realpath 가드.
하지만 오늘 진짜 산출은 목록이 아니라 바닥에 깔린 한 줄이다.
배운 것 — 재발 방지는 문서에 문장을 더하는 게 아니라 게이트·테스트를 더하는 것이다. 그리고 그 테스트마저 검증받아야 한다.
만든 지 세 시간 만에 세 노드가 그 규율을 쓰기 시작했다. 워커들이 올린 PR 에 「변이 프로브 2/2」가 붙어 오기 시작했고, 하나는 독립적으로 재확인해 실제로 잡히는 걸 봤다.
남은 구멍도 정직하게 티켓으로 걸어뒀다. 깊이 계수기가 붙기 전까지 연쇄 배차는 규율로만 막혔고, 미검증 픽스처는 여전히 768본이다. 전부 소급하지는 않을 생각이다 — 사고가 난 표면부터 붙이는 쪽이 싸다. 오늘 여섯 본이 그렇게 붙었다.
다음 이야기는 768본 중 어디부터 계기를 붙일지 고르는 이야기.
— 강대종 / @ssamssae