문제가 보이면 무언가를 더하고 싶어진다. 나도 그랬다. 새로운 대책, 새로운 모니터링, 새로운 도피처. 하지만 RC 검증 주간에는 그 반사적인 행동을 의식하며 멈췄다. Version을 경계로 신기능 추가를 중단한다. 이 수수한 판단이 없었다면, 검증을 통해 보인 것들의 의미가 흐릿해졌을 것이라 생각한다.

2026-07-24 시점의 Current Context에는 지금 해서는 안 될 일로서 「신기능 추가」, 「인증 방식 변경」, 「v1.0.0 tag」, 「Issue 자동 클로즈(Close)」가 나열되어 있다. 이것은 소극적인 제한이 아니다. 정식 버전으로 나아가기 위해, 무엇을 늘리지 않을 것인지를 명확히 한 선이었다.

Vol.10에서도 썼듯이, 2026-07-11부터의 7일간은 코드 추가 금지 상태로 v1.0.0-rc1을 매일 사용하는 기간이었다. RC는 완성 축하 파티가 아니라, 완성이라고 말해도 좋을지 지켜보는 주간이었기 때문이다.

그런데 실제로 사용하기 시작하면 마찰이 발생한다. 일일 Connector가 작동하지 않는다. DarkWake에서 멈출 수 있다. OAuth나 네트워크도 아침의 맥락에서는 다른 얼굴을 한다. 이러한 마찰을 보았을 때 가장 쉬운 방법은 새로운 대책을 계속해서 추가하는 것이다. 하지만 그것을 계속하면 「지금 무엇을 검증하고 있는가」가 보이지 않게 된다.

Vol.11에서는 일시적인 No-Go를 선택했다. Vol.12에서는 손으로 움직이는 Connector와 매일 움직이는 메커니즘은 별개의 품질이라는 것을 알게 되었다. Vol.13과 Vol.14에서는 DarkWake나 OAuth처럼 아침의 무인 실행에서만 보이기 쉬운 조건들도 표면으로 드러났다. 즉, RC 검증 주간은 부족한 기능을 늘리는 기간이 아니라, 지금 있는 구성 그대로 어디까지 단언할 수 있는지를 확인하는 기간으로 바뀌어 있었다.

테마는, Version을 경계로 신기능 추가를 중단함으로써, RC 검증 주간을 「구현의 연장」이 아닌 「판단의 기간」으로서 지켜낼 수 있었다는 것이다.

중단한다고 해서 아무것도 하지 않는 것은 아니다. 2026-07-24 시점의 Current Context에 있는 --wait-for-user-active와 같이 최소한의 수정은 들어간다. 중요한 것은 검증의 의미를 망가뜨릴 정도로 이야기를 확장하지 않는 것이었다.

비엔지니어의 입장에서는 이 부분이 상당히 이해하기 어려웠다. 문제가 보일 때마다 새로운 대응책을 넣는 것이 전진하는 것처럼 보이기 때문이다. 하지만 RC 검증 주간에는 전진하는 것처럼 보이는 것과 판단 재료가 늘어나는 것은 같지 않았다. 오히려 대책을 너무 많이 늘리면 무엇을 확인하고 있는지가 애매해진다. Version의 경계는 그 애매함을 막기 위해 효과가 있었다.

2026-07-24 시점의 Current Context가 보여주는 것은 상당히 명확한 운용 자세다. Version 1.0은 No-Go 지속. Issue #11 / #12의 운용 팔로업(Follow-up)이 남아 있음. 최근의 수정은 launchd 실행에 --wait-for-user-active를 추가한 최소 수정. 그리고 「지금 해서는 안 될 일」에 신기능 추가와 인증 방식 변경이 명기되어 있다.

이 나열을 보면 RC 검증 주간에서 지키고 싶었던 것이 보인다. 문제가 나왔다고 해서 바로 다른 메커니즘으로 뛰어넘지 않는다. 인증에서 마찰이 있어도 방식 변경으로 가지 않는다. Issue가 남아 있어도 자동으로 닫아서 진행된 형태를 만들지 않는다. 즉, 앞으로 나아간 느낌을 만드는 것보다 현재 상태를 정확하게 관찰하는 것을 우선시하고 있었다.

최소 수정을 허용하면서 신기능 추가를 중단하는 것은 조금 어렵다. 경계가 애매하면 무엇이든 「필요한 수정」이라고 말할 수 있기 때문이다. 그렇기에 Version이 필요하다고 생각한다. RC라는 단어가 있으면 「지금은 완성을 늘리는 기간이 아니라, 완성이라고 할 수 있는지 확인하는 기간이다」라고 말하기 쉽다.

여기서 중요했던 것은 최소 수정과 신기능 추가를 같은 상자에 넣지 않은 것이다. --wait-for-user-active의 추가는 DarkWake 맥락의 아침 실행 조건을 망가뜨리지 않기 위한 최소 수정으로 취급되고 있다. 하지만 그것은 아침의 운용 조건을 더욱 확장하는 추가 기능이 아니다. 만약 이 차이를 애매하게 했다면 「필요한 수정」이라는 명목으로 무엇이든 추가할 수 있게 된다. 그렇게 되면 RC 검증 주간은 관찰 기간이 아니라 구현의 연장으로 되돌아가 버린다.

Issue #11 / #12의 취급도 마찬가지였다. Issue가 남아 있는데도 다른 개선을 계속해서 넣어 앞으로 나아간 형태를 만들어 버리면, 어디까지가 확인된 것이고 어디서부터가 미확인인지 보이지 않게 된다. Current Context가 No-Go 지속, 운용 팔로업 남음, 최소 수정, 금지 사항을 나열하고 있는 것은 그 순서를 무너뜨리지 않기 위해서였을 것이라 생각한다.

인증에서 마찰이 생기면 방식을 변경하는 단계로 단숨에 뛰어넘고 싶어진다. 네트워크의 흔들림이 보이면 다른 모니터링이나 다른 제어를 넣고 싶어진다. 하지만 이 시점에서는 그것을 하지 않기로 결정했다. 하지 않기로 결정한 것은 소극적인 것이 아니라, 현재 있는 구성 그대로 어디까지 확언할 수 있는지를 지키기 위한 적극적인 제한이었다.

또 하나 큰 이유는 'Issue 자동 클로즈(Auto-close)'를 금지 사항에 넣어두었던 것이라고 생각한다. 겉모습만 전진한 것처럼 정리해 버리면, RC(Release Candidate)의 판단은 쉽게 느슨해진다. Issue가 닫혀 있지 않다는 것, 검증이 남아 있다는 것, Version을 올리지 않았다는 것이 그대로 남아 있기 때문에, 멈춰 있는 이유를 설명할 수 있다. 설명할 수 있는 멈춤은 나중에 강력한 힘을 발휘한다.

비엔지니어(Non-engineer)의 입장에서는 이 부분이 상당히 중요했다. 기술적 과제가 보일 때마다 새로운 대응책을 나열하고 싶어진다. 나열하면 일시적으로는 안심이 된다. 하지만 나열한 대응책이 많아질수록 어떤 것이 효과가 있었는지, 무엇이 아직 미확인 상태인지 알기 어려워진다. 알기 어려워지는 것은 그대로 Version 판단의 약점으로 이어진다.

신기능 추가를 멈추는 것은 뒤처지는 것이 아니었다. 오히려 '지금 있는 것에 책임을 지기' 위한 전향적인 제한이었다고 생각한다. 추가를 멈추면 눈에 보이는 문제로부터 도망치기 어려워진다. 도망치기 어려워지기 때문에 Issue와 기지(Known)의 제한 사항을 정면으로 기술할 수 있다. 기술할 수 있기 때문에 No-Go나 일시 정지도 설명하기 쉬워진다.

AI와 함께하는 개발에서는 추가 제안이 즉각 나온다. 그렇기에 멈추는 규칙을 미리 가지고 있는 가치가 있다. 인간의 기세도, AI의 제안량도 경계가 없으면 쉽게 부풀어 오른다. Version은 그 부풀어 오름을 억제하기 위한 기술적 라벨이기도 했다.

나는 처음에 Version을 '여기까지 만들었다'라는 라벨로 보고 있었다. 하지만 RC 검증 주간에 보인 것은, Version이 '여기서부터는 늘리지 않겠다'라고 말하기 위해서도 쓰일 수 있다는 점이었다. 기능 목록을 늘리기 위한 기호가 아니라, 관찰 대상을 지키기 위한 선이 된다. 이는 코드를 작성하지 않는 입장에서도 상당히 이해하기 쉽다. 늘리지 않기로 결정되어 있다면, 오늘 아침에 보이는 문제를 다른 이야기로 덮어쓰기 어려워지기 때문이다.

Human Approval의 사상과도 조금 닮았다고 생각한다. 운영 환경의 쓰기 작업에서는 실행할 수 있는 것과 실행해도 좋은 것을 구분했다. RC 검증 주간에서도 생각할 수 있는 것과 지금 해도 좋은 것을 구분했다. 할 수 있는 개선은 아직 더 있었을지도 모른다. 하지만 그 자리에서 전부 하는 것이 반드시 품질을 강하게 만드는 것은 아니다. 경계를 남김으로써 판단과 구현을 같은 흐름으로 만들지 않도록 했던 것이라고 생각한다.

매일 아침의 무인 실행을 전제로 하면 이 선 긋기는 더욱 중요해진다. 아침의 불안에 대해 즉시 다른 대책을 추가하면 일시적으로는 안심이 된다. 하지만 다음 날 아침 또 다른 흔들림이 보일 때, 무엇이 효과가 있었는지, 어디까지가 기지의 제한인지, 무엇이 아직 미확인 상태인지가 섞이기 쉽다. RC 검증 주간에 정말로 지키고 싶었던 것은 안심감 그 자체보다, 안심해도 되는 근거를 섞지 않는 것이었다.

• Version은 기능 목록이 아니라, 무엇을 늘리지 않을지를 결정하는 경계가 되기도 한다
• RC 검증 주간에 신기능 추가를 멈추면 관찰하고 있는 대상이 흔들리지 않는다
• 최소 수정과 기능 추가를 나누어 생각하지 않으면 검증 결과를 해석하기 어려워진다
• 문제가 보일 때일수록 추가 제안보다 현재 위치의 언어화가 중요해진다
• AI와 함께하는 개발에서는 멈추는 규칙이 없으면 제안량에 휩쓸리기 쉽다

이 내용의 뒤를 이어 쓴다면, Issue가 남아 있는 동안에는 '해결됨'이라고 쓰지 않는 태도로 이어진다. Version 관리는 말하는 방식의 성실함과도 직결되어 있었기 때문이다.