테스트가 Green이면 안심이 된다. 나도 그랬다. 하지만 RC 검증 주간에는 Green의 수가 늘어날수록, 오히려 다른 질문이 강해졌다. 그 Green은 내일 아침 06:30의 운용까지 보장해 주는가. 이 질문에 「예」라고 단언할 수 없었기에, Go는 서두르지 않았다.

Day 7 시점에서 171 Green이 확인되었다. 나아가 2026-07-24의 Current Context에서는 178 Green이 되었다. 그럼에도 상태는 No-Go 지속이며, Issue #11 / #12의 운용 팔로업 (follow-up)이 남아 있다. 이번에는 그 「통과하고 있는데도 진행하지 않는」 판단에 관한 이야기다.

Vol.11에서는 Day 7의 일시적인 No-Go를 썼다. 그 기사에서 중심에 두었던 것은, 171 Green이라도 정식 버전의 충분조건은 아니라는 선이었다. 이번 Vol.16은 그 선을 조금 더 넓히고 있다.

Current Context에는 현재 상태가 명확히 적혀 있다. Version 1.0은 No-Go 지속. 현재의 논점은 Issue #11 / #12의 운용 팔로업 (follow-up). 최근의 최소 수정 사항으로 --wait-for-user-active가 추가되었지만, DarkWake 중의 기동 문제는 무인 실기 확인이 미완료 상태다. 즉, 테스트는 늘어나고 있지만, 아침의 조건 확인은 아직 끝나지 않았다.

테마는, 테스트 Green은 「망가지지 않았다」는 강력한 증거이지만, 「정식 버전으로서 설명할 수 있다」의 충분조건은 아니었다는 것이다.

이 차이는 비엔지니어인 나에게 상당히 컸다. 테스트가 많을수록 이제 앞으로 나아가도 될 것 같은 기분이 든다. 하지만 RC 검증 주간에는 코드의 정확성뿐만 아니라, 정해진 시간에 작동하는지, 무인으로 지속되는지, 멈추는 이유를 설명할 수 있는지까지 보고 있었다.

Day 7의 기록에는 171 Green이라는 사실이 있었다. 그것은 크다. 폭넓게 망가지지 않았다는 것, 과거에 정한 약속이 상당히 지켜지고 있다는 것을 보여준다. 나아가 2026-07-24의 Current Context에서는 테스트가 178 Green으로 늘어났다. 이것만 보면 전진은 명확하다.

하지만 동일한 Current Context에는 Go를 멈추는 이유도 같은 강도로 적혀 있다. Issue #11 / #12의 운용 팔로업 (follow-up)이 남아 있다. DarkWake 중의 launchd 기동은 검증 중이며, 수정은 이루어졌으나 무인 실기 확인은 미완료다. 지금 해서는 안 될 일로서 신기능 추가, 인증 방식 변경, v1.0.0 태그, Issue 자동 클로즈 (close)도 명시되어 있다.

여기서 보이는 것은 테스트와 운용 판단의 역할 차이다. 테스트는 「이 변경으로 인해 기지(known)의 약속을 깨뜨리지 않았는가」를 강력하게 봐준다. 반면 Go / No-Go는 「정식 버전으로서 세상에 설명할 수 있는가」를 본다. 설명에는 무인 운용의 확인, 남은 Issue의 처리, Version을 올리는 이유까지 포함된다.

RC 검증 주간에서 특히 중요했던 것은, Go를 감정으로 결정하지 않았던 것이라고 생각한다. 171 Green에서 178 Green으로 늘어나도 미확인 항목이 있다면 멈춘다. 개선이 이루어졌더라도 실기의 아침 상황에서 아직 뒷받침이 되지 않는다면 멈춘다. 이 순서를 지켰기에 Green의 숫자를 장식으로 만들지 않을 수 있었다.

여기서 지탱해 준 것은, 멈추는 이유가 애매한 불안이 아니라 문서로서 나열되어 있었다는 점이다. Issue #11 / #12의 운용 팔로업 (follow-up), DarkWake 중의 기동 문제, --wait-for-user-active를 추가한 뒤의 무인 실기 확인 미료. 모두 「아마 신경 쓰일 것 같다」가 아니라, 확인 대기 중인 논점으로서 놓여 있었다. 그래서 Green의 수가 늘어나도 어디를 보고 멈춰 있는지를 말로 설명할 수 있었다.

이 정리는 숫자를 가볍게 다루기 위함이 아니다. 오히려 Green을 올바르고 무겁게 다루기 위한 선이었다고 생각한다. 171이나 178이라는 숫자는 상당히 많은 약속이 지켜지고 있음을 보여준다. 그렇기에 그 숫자에 포함되지 않는 논점을 별도로 가지고 있지 않으면, 안심할 수 있는 요소가 그대로 판단의 지름길(shortcut)이 되어 버린다. RC 검증 주간에서 지키고 싶었던 것은, Green을 강력한 사실로서 사용하면서도, Green만으로 Go를 결정하지 않는 것이었다.

또 하나 컸던 것은, 최소 수정이 들어간 후에도 「그러니까 이제 괜찮다」라고 말하지 않은 것이다. --wait-for-user-active

--wait-for-user-active가 추가된 것은 진전이다. 하지만 진전했다는 것과, 아침의 운영 조건이 충분하다는 것을 확인(Back-up/Verification)한 것은 별개의 문제다. 이러한 구분이 없으면 수정의 존재 자체가 완성 증명처럼 보일 수 있다. 완성을 서두르지 않기 위해서는 수정과 검증을 별개로 다룰 필요가 있었다.

테스트가 Green임에도 멈추는 것은 처음에는 조금 어색하다. 앞으로 나아가지 못하는 것처럼 보이기 때문이다. 하지만 지금은, 거기서 멈출 수 있었던 것이 품질이었다고 생각한다. 멈추지 못하는 프로젝트는 Green을 면죄부로 삼아버린다. 면죄부가 되는 순간, 숫자는 설명 책임(Accountability)으로부터 분리된다.

비엔지니어(Non-engineer)의 입장에서 말하자면, 테스트는 "이제 안심해도 된다"라는 종소리가 아니라, "여기서부터는 다른 확인 단계로 넘어갈 수 있다"라는 신호에 가깝다. 코드의 토대가 무너지지 않았기에 다음 단계인 아침의 운영을 살펴볼 수 있는 것이다. 역으로 말하면, 아침의 운영 확인을 건너뛸 이유가 되지는 않는다.

Human Approval의 사상과도 닮아 있다. 승인이 필요한 조작에서는 실행할 수 있는 것과 실행해도 좋은 것을 나누었다. Go / No-Go 역시 마찬가지로, Green이라는 것과 정식 버전으로 만들어도 좋다는 것은 나누어 생각할 필요가 있다. 그 분리가 있기에 Version은 단순한 기념일이 되지 않는다.

나는 처음에 Green의 수가 늘어날수록 "이제는 멈출 이유를 찾고 있는 것뿐이 아닌가"라고 조금 의심했다. 하지만 지금은 반대로, 멈출 이유를 언어화할 수 있기 때문에 Green이 의미를 갖는 것이라고 생각한다. 만약 남은 논점들을 애매하게 둔 채 Go를 결정했다면, 171이나 178이라는 숫자는 나중에 형편에 맞게 이용될 뿐이었을지도 모른다. 숫자를 지키기 위해서는 숫자 외부에 있는 조건도 지켜야 한다.

매일 아침의 운영을 전제로 하면 이 차이는 더욱 커진다. 테스트는 동일한 조건으로 몇 번이고 확인할 수 있다. 반면 아침 06:30의 무인 실행은 시간, 수면 상태, 네트워크, 인증, 외부 서비스 지연 등이 얽혀 있다. 그 차이를 무시하고 "테스트가 통과했으니 충분하다"라고 말하는 편이 오히려 무책임했다. RC 검증 주의 Go / No-Go는 코드 품질을 의심하기 위해서가 아니라, 운영 품질을 별도로 판단하기 위한 결정이었다.

따라서 이 시기의 배움은 "Green을 늘리는 것"보다 "Green의 의미를 오해하지 않는 것"에 있었다. 숫자를 쌓아 올리는 노력은 필요하지만, 그것을 정식 버전 선언으로 어떻게 연결할지는 별개의 책임이다. 비엔지니어라도 이 부분을 구분하여 말할 수 있게 되면, 안심할 수 있는 재료에 휩쓸리지 않고 프로젝트를 지키기가 쉬워진다. 그 선을 그을 수 있었다는 것 자체가 RC 검증 주의 큰 수확이었다.

• 테스트 Green은 강력한 안심 재료이지만, 정식 버전의 충분조건은 아니다
• Day 7의 171 Green과 2026-07-24 시점의 178 Green은 진전의 증거이지만, 미확인 항목을 없애주지는 않는다
• Go / No-Go는 코드 품질뿐만 아니라 운영 품질과 설명 책임을 포함하여 결정한다
• 남은 Issue나 무인 확인 미결 사항을 안고 있는 채로 Version을 올리지 않는 편이 나중에 더 강력하다
• Green의 숫자를 면죄부로 삼지 않는 것이 RC 검증 주의 가치가 된다

이 내용에 이어 쓴다면, 무인 실행에서 네트워크 장애에 어떻게 대응했는가라는 이야기로 연결된다. 아침의 운영에서는 성공률보다 먼저 분리(Isolation/Troubleshooting)하는 방법이 중요해지기 때문이다.