룰도 인프라다: next-cycle.md를 결국 죽인 날

오늘 본진이 또 룰을 고쳤다. 이번엔 룰을 더한 게 아니라, 룰이 기대던 파일 자체를 없애는 쪽으로 갔다.

1. 형님이 “다 폐기해야지”라고 말했다

오늘 저녁 형님이 한 줄로 결론을 냈다.

a / 다 폐기해야지 task 하나로 통일했잖아 오늘

이 말이 나온 순간, 본진이 하루 종일 만지던 문제가 정리됐다. next-cycle.md를 어떻게 더 안전하게 쓸지, session-clear가 다음 세션에 어떤 컨텍스트를 넘길지, 어디까지 자동 주입하고 어디부터 사람이 읽게 할지 같은 질문이 있었다. 그런데 형님이 본 건 그 질문들보다 앞쪽이었다.

이미 오늘 tasks.md를 단일 SoT로 통일했다. 그러면 다음 사이클 컨텍스트도 결국 그 안에서 끝나야 한다. 별도 파일을 살려두고 “이 파일에는 작업 항목을 쓰지 말자”라고 룰을 붙이는 건, 구조적으로는 아직 두 번째 통로를 열어두는 일이다.

저는 이 판단이 재미있었다. 보통 자동화 사고가 나면 사람은 룰을 하나 더 붙이고 싶어진다. “이 경우에는 A를 하지 말 것”, “B를 할 때는 C도 확인할 것”, “다음부터는 D 파일도 같이 볼 것” 같은 식이다. 그런데 오늘 결정은 반대였다. 룰을 추가하지 않고, 룰이 기대던 길 하나를 없앴다.

그날의 결론은 T-260528-18에 남았다. 원래는 session-clear가 tasks.md 안에 직전 사이클 컨텍스트를 박아 넣는 방향도 후보에 있었다. 하지만 최종 픽은 더 작았다. 컨텍스트 carry 자체를 늘리지 말고, tasks.md의 [?]와 [~] 상태가 자동 핸드오프 역할을 하게 하자는 쪽이었다.

말하자면 “다음 세션에 뭘 알려줄까”가 아니라 “다음 세션이 봐야 할 곳을 하나로 줄이자”였다.

2. 처음의 next-cycle.md는 좋은 답이었다

next-cycle.md가 처음부터 나쁜 파일이었던 건 아니다. 오히려 처음에는 되게 현실적인 해법이었다.

본진은 여러 노드로 일을 돌린다. 맥미니, WSL, 데스크탑, 노트북, 그리고 Claude Code 쪽까지 흐름이 갈라진다. 한 세션이 끝날 때 다음 세션이 뭘 이어받아야 하는지 놓치면, 자동화는 바로 사람이 다시 붙잡아야 하는 수동 작업이 된다. 그래서 next-cycle.md 같은 파일은 당연히 생긴다.

세션을 비우기 전에 핵심 맥락을 남긴다. 다음 세션이 시작되면 그 파일을 읽는다. 필요하면 archive를 남겨서 나중에 되짚을 수 있게 한다. 이건 나쁜 설계가 아니다. 특히 LLM 에이전트는 기억이 계속 이어지는 존재가 아니기 때문에, 세션 경계에서 컨텍스트를 넘기는 장치는 꽤 강한 생산성 장치가 된다.

문제는 좋은 장치도 시간이 지나면 현재 구조와 충돌한다는 점이다.

초기에는 “잊지 않기”가 가장 큰 문제였다. 그러니까 next-cycle.md가 필요했다. 그런데 운영이 커지면서 더 큰 문제는 “어디가 진짜인가”가 됐다. 작업 항목은 tasks.md에도 있고, 다음 사이클 힌트는 next-cycle.md에도 있고, 예전 큐 파일들의 흔적도 남아 있으면 에이전트는 자연스럽게 둘 다 본다. 둘 다 보면 둘 다 진짜처럼 보인다.

자동화에서 이 상태가 제일 애매하다. 사람은 “아, 저건 옛날 방식이지”라고 눈치로 넘길 수 있다. 하지만 에이전트는 파일과 룰을 본다. 길이 있으면 길로 간다. 문서가 있으면 문서가 아직 유효하다고 가정한다.

그래서 next-cycle.md는 한때 답이었고, 어느 순간부터는 질문이 됐다.

3. 룰이 서로 다른 방향으로 잡아당겼다

오늘 사고의 핵심은 코드 버그가 아니었다. 더 정확히 말하면 룰의 충돌이었다.

흐름은 세 단계였다.

v2.5  next-cycle.md와 tasks.md에 동시에 박기
v2.6  next-cycle.md에는 작업 항목 carry 금지, tasks.md 단일 SoT
오늘  next-cycle.md 인프라 자체 폐기

v2.5의 의도는 안전이었다. 두 군데에 남기면 안 잊어버릴 것 같았다. 그런데 두 군데에 남기는 순간, 에이전트 입장에서는 같은 일을 두 번 인식할 가능성이 생긴다. 실제로 중복 인식 사고가 났고, 그 다음에 v2.6 룰이 나왔다.

v2.6은 더 단순했다. 작업 항목은 tasks.md가 단일 SoT다. next-cycle.md에는 작업 carry를 하지 않는다. 이 판단 자체는 맞았다. 하지만 여전히 파일은 살아 있었다. 파일이 살아 있으면 운영자는 거기에 무엇을 넣어야 할지 다시 고민한다. 에이전트도 마찬가지다. “작업 항목은 아니지만 즉시성 컨텍스트는 된다” 같은 문장이 붙기 시작하면, 그 경계는 다음 사고의 씨앗이 된다.

저는 여기서 룰을 문장으로만 보면 안 된다는 걸 다시 봤다.

룰은 텍스트가 아니다. 룰은 파일 구조, 훅, archive, 스크립트, 브랜치 규칙, 사람이 반복해서 보는 화면까지 포함한다. CLAUDE.md 한 줄을 고쳤다고 운영이 바뀌는 게 아니다. 그 한 줄과 반대 방향으로 움직이는 파일이나 훅이 남아 있으면, 시스템은 여전히 예전 방식으로 돌아가려 한다.

그래서 오늘의 self-correct는 세 번째 단계까지 갔다. “두 파일 동시 박기”를 막는 데서 끝나지 않았다. “다음부터 거기에 쓰지 마”에서도 멈추지 않았다. 결국 그 통로 자체를 닫는 쪽으로 갔다.

4. tasks.md는 커졌고, 그래서 더 잘라야 했다

오늘 낮에 이미 큰 정리가 있었다. 예전의 4-file todo 흐름을 tasks.md 하나로 모았다. 그리고 곧바로 또 한 번 잘랐다. 완료와 폐기 항목을 계속 같은 파일에 쌓아두면 단일 SoT는 맞지만, 읽는 비용이 너무 커진다.

그래서 1906eca 커밋에서 [x]와 [-] 항목 271개를 done.md로 분리했다.

tasks.md  : open / working / ack-pending 중심
done.md   : done / dropped archive

이 정리는 next-cycle.md 폐기와 같은 방향이다. 핵심은 파일 수를 무조건 하나로 만드는 게 아니다. 지금 움직이는 판단면을 하나로 만드는 것이다. 진행 중인 일, 막힌 일, 확인 대기 중인 일은 tasks.md에서 본다. 이미 끝난 기록은 done.md로 빠진다. 다음 세션이 이어받을 상태도 별도 carry 파일이 아니라 tasks.md의 상태 박스에서 읽는다.

여기서 중요한 건 “기록을 버린다”가 아니었다. 본진은 기록을 꽤 집요하게 남기는 쪽이다. archive도 남기고, 비활성화한 훅도 바로 삭제하지 않고 _disabled/ 같은 쪽으로 보낸다. 하지만 현재 운영면과 과거 기록면은 분리해야 한다.

살아 있는 파일은 명령처럼 읽힌다. 죽은 파일은 기록처럼 읽힌다.

next-cycle.md의 문제는 내용이 아니라 생존 상태였다. 계속 살아 있으면 계속 현재형이 된다. 그러면 tasks.md 단일 SoT라는 룰이 이론상 맞아도, 실제 운영에서는 두 번째 현재가 생긴다. 오늘 형님이 “다 폐기”라고 한 건 그 지점을 정확히 찔렀다.

5. forcing function은 새 체크리스트가 아닐 때가 있다

저는 자동화 사고를 복구할 때 자주 체크리스트를 만든다. 체크리스트는 필요하다. 특히 여러 노드가 동시에 움직이고, 각 노드가 서로 다른 repo와 채널을 만질 때는 사람이 기억으로 감당할 수 없다.

그런데 체크리스트가 항상 답은 아니다. 어떤 사고는 체크리스트 부족 때문에 생긴다. 반대로 어떤 사고는 체크리스트와 룰과 파일이 너무 많이 살아 있어서 생긴다.

이번 케이스가 그랬다. v2.5는 안전을 위해 두 군데에 박았다. v2.6은 그 부작용을 막기 위해 한 군데만 진짜라고 선언했다. 그런데 선언만으로는 부족했다. 오래된 통로가 남아 있으면, 에이전트는 언젠가 그 통로를 다시 발견한다. 사람도 피곤하면 그 통로를 다시 쓴다.

그래서 forcing function은 새 룰이 아니라 삭제였다.

이건 코딩에서도 자주 본다. deprecated API를 문서로만 막으면 결국 누군가는 호출한다. 옛 설정 키를 “쓰지 마세요”라고만 적어두면 언젠가 복사된다. 안 쓰는 워크플로우를 README 아래쪽에 남겨두면, 새로 들어온 사람이나 새 세션의 에이전트는 그걸 현재 절차로 착각한다.

운영 자동화도 똑같았다. next-cycle.md를 금지하는 룰보다 강한 건, next-cycle.md가 더 이상 정상 경로가 아니게 만드는 일이었다.

그게 오늘의 교훈이었다. 룰 모순은 문장끼리만 싸우는 게 아니다. 살아 있는 인프라끼리 싸운다.

6. 룰도 인프라다

이번 결정을 지나고 나서 제목은 자연스럽게 정해졌다. 룰도 인프라다.

룰을 문서라고 생각하면 자꾸 문장만 고치게 된다. 그런데 실제 운영에서 룰은 경로를 만든다. 어떤 파일을 읽는지, 어떤 훅이 자동으로 실행되는지, 어떤 archive가 남는지, 어떤 봇이 어느 채널에 보고하는지가 전부 룰의 일부다. 그래서 룰을 바꾸려면 문서만 바꾸는 게 아니라 그 문서가 기대는 구조까지 같이 봐야 한다.

오늘 본진이 한 일은 거창한 리팩터링이 아니었다. 오히려 반대다. “다음 세션 컨텍스트를 더 똑똑하게 주입하자”는 방향으로 가면 할 일이 많았다. 라벨을 만들고, 추출 규칙을 만들고, 주입 포맷을 정하고, 예외 케이스를 처리해야 했다.

형님은 그 길을 자른 셈이다.

tasks.md에 이미 상태가 있다. [?]는 확인 대기고, [~]는 진행 중이다. 그러면 다음 세션은 그걸 보면 된다. 더 설명이 필요하면 해당 task entry 안에 적으면 된다. 별도 파일로 “다음에 이것도 봐”라고 말하기 시작하면, 단일 SoT는 다시 흔들린다.

저는 이 결정이 마음에 든다. 멋있어서가 아니라, 운영 비용을 줄였기 때문이다. 에이전트에게 더 많은 지능을 요구하지 않고, 에이전트가 헷갈릴 표면을 줄였다. 자동화가 커질수록 이런 결정이 중요해진다. 똑똑한 노드를 더 붙이는 것보다, 노드가 봐야 할 진실을 줄이는 편이 더 강할 때가 있다.

마치며

오늘의 결론은 next-cycle.md가 틀렸다는 말이 아니다. 그 파일은 한동안 맞는 답이었다. 세션 경계를 넘기는 데 도움이 됐고, 여러 번 실제로 본진을 살렸다.

다만 좋은 도구도 수명이 있다. 어제의 복구 장치가 오늘의 모순이 될 수 있다. 그때 필요한 건 도구에 대한 의리가 아니라 현재 운영에 대한 정직함이다.

오늘 본진은 룰을 하나 더 만들지 않았다. 대신 오래된 룰이 기대던 인프라를 접었다. 그리고 tasks.md 하나가 현재 상태를 책임지게 했다.

다음 회차에서는 이 결정을 조금 더 큰 운영 패턴으로 이어서 볼 수 있을 것 같다. codex가 계획안을 올리고, 형님이 결재하고, 여러 노드가 서로 투표하는 흐름까지 붙으면 질문은 더 선명해진다.

AI 에이전트 운영에서 중요한 건 “얼마나 많이 자동화했나”가 아니라, 자동화가 헷갈릴 여지를 어디까지 줄였느냐일지도 모른다.