일시적인 No-Go 상태가 된 후, 다음에 필요한 것은 신기능이라고 생각하기 쉽다. 나도 처음에는 그렇게 느꼈다. 하지만 2026-07-26에 v1.0.0을 정식 Go로 결정한 근거는, 다른 거대한 기능이 아니었다. 운용 조건(Operational conditions)을 최소 차분(Minimum difference)으로 다시 다듬고, 그 조건으로 무인(Unattended) 상태의 아침을 다시 한번 확인한 것이었다.

Current Context에는 RC 검증 주의 최종 판정으로서 「Day 7의 일시적 No-Go를 거쳐, 2026-07-26의 최종 무인 검증에서 Go」라고 되어 있다. 같은 맥락에서, 중대 버그 누계 1건은 해소되었으며, 최종 무인 검증에서는 DarkWake 중에 Connector를 시작하지 않을 것, 통상적인 Wake 후에 GA4 / GSC / Clarity가 success였던 것, Metricool은 기지(Known) 허용 범위인 partial로 7 / 7 저장되었던 것, wrapper exit code 0, stderr 공백, 전체 178 tests passed도 확인되었다. 이번에는 '무엇을 추가했는가'가 아니라 '어떤 조건에서 Go라고 말할 수 있게 되었는가'에 대한 이야기다.

Vol.11에서는 7일을 사용한 끝에 일시적 No-Go를 선택했음을 썼다. Vol.12에서는 작동하는 Connector와 매일 작동하는 메커니즘은 별개라고 썼다. Vol.13과 Vol.14에서는 Mac의 수면이나 OAuth와 같이, 낮에는 보이지 않는 조건이 아침의 무인 실행에서는 전면에 드러난다는 점도 보였다. 즉, RC 검증 주간에 멈춰 있었던 이유는 단일한 화려한 고장이 아니라, 매일 아침 맡기기 위한 조건을 아직 확언할 수 없었기 때문이었다.

Current Context에서는 그 이후의 정리도 명확하다. Step49.1에서 launchd를 통한 Daily Connector Automation을 도입했고, 그 이후에도 신기능 추가가 아닌 최소 차분으로 운용 조건을 다듬었다. 나열된 것은 DNS / 일시적 통신 장애의 유한 재시도(Finite retry), Metricool의 비대화형(Non-interactive) OAuth refresh, DarkWake 제외, launchd 실행 시의 통상적인 Wake 대기다. 여기서 중요한 것은 완성을 화려하게 새로 만든 것이 아니라, 아침에 필요한 전제를 하나씩 확인 가능한 형태로 모은 것이었다.

테마는, v1.0.0의 Go 판정을 바꾼 것은 신기능 추가가 아니라, 운용 조건의 명확화와 재검증이었다는 것이다.

기능 추가는 성과로서 보이기 쉽다. 하지만 Go / No-Go 판단에 필요한 것은 무엇이 늘어났느냐보다 무엇을 설명할 수 있게 되었느냐라고 생각한다. 무인 실행의 아침에 무엇이 일어나는지, 그때 기지(Known) 제한 사항을 어떻게 다룰지, 어디까지를 성공으로 간주할지. 그 부분이 모호한 채로는 기능이 늘어나도 Go를 결정하기 어렵다.

Current Context에 따르면, 최종 무인 검증에서 확인된 사실은 상당히 구체적이다. DarkWake 중에는 Connector를 시작하지 않는다. 통상적인 Wake 후에는 GA4 / GSC / Clarity가 success이다. Metricool은 partial이지만 기지 허용으로서 7 / 7 저장. wrapper exit code는 0, stderr는 공백, 그리고 전체 178 tests passed. 이는 '대충 잘 되었다'가 아니라, 아침 운용에서 보고 싶은 조건을 열거하여 확인한 기록에 가깝다.

이 나열 중에서 특히 큰 것은 partial을 실패와 혼동하지 않았다는 점이라고 생각한다. Current Context에는 Metricool은 미제공 지표가 있는 경우 partial을 사양(Specification)으로서 허용한다고 되어 있다. 즉, 인증 실패, 통신 장애, 사양상 발생할 수 있는 누락을 한데 묶지 않고, 어디까지를 아침 운용으로서 받아들일 것인지를 먼저 설정해 두었다. Go 판정을 뒷받침한 것은 완벽해 보이게 만드는 숫자가 아니라, 성공 조건과 허용 조건을 분리한 정리였다.

또 하나 큰 것은 Step49.1 이후의 수정이 최소 차분에 머물러 있다는 점이다. launchd를 도입한 후에도 DNS의 유한 재시도, OAuth의 비대화형 refresh, DarkWake 제외, 통상적인 Wake 대기와 같은 운용 조건의 조정에 집중하고 있다. Current Context에서도 v1.0.0의 Go 판정은 신기능 추가가 아니라 운용 조건의 명확화와 재검증으로 성립되었다는 점이 중요하다고 명기되어 있다. 이 정도로 쓰여 있다면, Go는 기세로 결정한 것이 아니라 조건이 나열되었기에 확언할 수 있었던 것임을 알 수 있다.

나아가, 정식화 이후에 v1.1.0에서 UI 개선만을 쌓은 것도 이 Go 판정을 읽는 법을 보강한다. 만약 v1.0.0

v1.0.0에 새로운 기능 추가가 필요했다면, 직후의 정리 작업도 더 뒤섞여 있었을 것이다. 하지만 실제로는 v1.0.0에서 운용 조건을 다듬어 Go 판정을 내렸고, 그 이후의 v1.1.0에서는 Dashboard의 시각적 요소만을 개선했다. 버전(Version)이 명확히 구분되어 있기 때문에, 어느 단계에서 무엇이 근거였는지를 읽어내기가 쉽다.

운용 조건을 정리할 때 효과를 발휘하는 것은 단순히 성공 사례만을 세는 것이 아니다. 어디까지를 기지(known)의 제한 사항으로 받아들일 것인지, 어디서부터를 Go의 방해 요소로 간주할 것인지, 그 선을 먼저 긋는 것이다. DarkWake 제외나 일반적인 Wake 대기 역시 그날의 사정에 따라 임기응변식으로 늘어난 규칙이 아니라, 아침의 무인 실행에 필요한 전제 조건을 명문화한 것으로서 Current Context에 남아 있다.

이러한 기록 방식은 매우 중요하다고 생각한다. 만약 조건 정리가 대화 속에만 머물고 최종 판정 문서로 이어지지 않았다면, 무엇이 Go의 이유였는지는 나중에 상당히 모호해졌을 것이다. 하지만 실제로는 최종 무인 검증에서 무엇을 확인했는지, 기지의 제한 사항을 어떻게 다루었는지, 어떤 최소 차분(minimal diff)이 필요했는지가 나열되어 있다. 그렇기에 Go는 기분에 따른 결정이 아니라, 확인된 조건들의 집합으로서 읽힐 수 있다.

최종 무인 검증에서 wrapper exit code 0과 stderr가 비어 있는 것까지 확인한 것도 미미해 보이지만 강력한 부분이다. 표면적인 성공뿐만 아니라 실행이 끝나는 방식까지 포함하여 보고 있기 때문이다. 비엔지니어(Non-engineer) 입장에서는 성공 화면만 보고 안심하기 쉽지만, 아침의 자동 운용에서는 뒷단의 실행 결과도 조건에 포함된다. 그 조건이 문장으로 남아 있으면, 믿고 맡겨도 좋다는 이유를 설명하기가 매우 수월해진다.

비엔지니어 입장에서는 No-Go 이후에 필요한 것이 '더 강력한 무언가'라고 생각하기 쉽다. 신기능, 새로운 모니터링, 새로운 설계 변경 같은 것들 말이다. 하지만 이번 Current Context를 읽어보면, Go에 필요했던 것은 강력한 신규 요소가 아니라 아침에 맡기기 위한 조건을 모호하게 두지 않는 것이었다. 이는 다소 의외였으며, 상당히 큰 배움이었다.

조건을 다듬는 작업은 기능 추가보다 눈에 띄지 않는다. 하지만 눈에 띄지 않기에 오히려 설명 책임(accountability)을 다하는 데 적합하다고 생각한다. DarkWake 중에는 시작하지 않는다. 일반적인 Wake를 기다린다. Metricool의 partial은 사양(specification)으로서 허용한다. DNS나 일시적인 통신 장애에는 유한 재시도(finite retry)로 대응한다. 이러한 조건들은 하나하나가 화려하지는 않지만, 아침에 '오늘은 믿고 맡겨도 되는가'를 지탱하는 선이 된다.

Human Approval의 사고방식과도 유사하다. '누를 수 있는 것'과 '눌러도 되는 것'을 구분한다. '동작하는 것'과 '믿고 맡겨도 되는 것'을 구분한다. v1.0.0의 Go에서도 마찬가지로, 기능이 있는 것과 정식 버전으로서 설명할 수 있는 것은 별개였다. 이번에 Go 판정을 바꾼 것은 무언가를 많이 만들었기 때문이 아니라, 믿고 맡겨도 되는 조건을 문장과 검증으로 갖추었기 때문이라고 생각한다.

여기에는 버전(Version) 관리의 강점도 나타난다. 버전을 올리기 전에 조건을 다듬고, 버전을 올린 후에 다른 테마의 개선으로 나아간다. 이 순서가 지켜지고 있기 때문에, 어떤 개선이 정식화의 근거였고 어떤 개선이 그 이후의 사용성 향상이었는지가 뒤섞이지 않는다. 조건 정리와 신기능 추가를 같은 상자에 담지 않은 것 자체가 Go 판정을 강력하게 만들었다.

나는 처음에 조건을 다듬는 작업을 '본질에 들어가기 전의 사소한 조정' 정도로 치부했다. 하지만 지금은 반대로, 매일 믿고 맡기는 메커니즘에서는 그 부분이 본질이라고 생각한다. 화려한 신기능은 주목을 받기 쉽지만, 아침 06:30에 정말로 필요한 것은 기동 조건, 허용 조건, 종료 조건을 설명할 수 있는 것이다. 설명 가능한 조건이 쌓여야 비로소 Go를 단호하게 말할 수 있게 된다.

• No-Go 이후에 필요한 것이 반드시 신기능 추가는 아니다
• Go 판정은 '무엇을 더했는가'보다 '어떤 조건에서 믿고 맡겨도 되는가'를 설명할 수 있느냐에 따라 달라진다
• partial을 실패와 혼동하지 않는 정리가 무인 운용의 판단을 강력하게 만든다
• 최소 차분으로 운용 조건을 다듬으면 무엇이 Go의 근거였는지 추적하기 쉽다
• 버전을 나누어 기록하면 정식화의 근거와 다음 개선 테마를 혼동하기 어렵다

이후의 내용을 쓴다면, v1.0.0 정식화 이후 v1.1.0에서 UI 개선으로만 범위를 좁힌 판단에 대해 쓰게 될 것이다. Go를 결정한 근거와 그 다음에 개선한 것이 깔끔하게 분리되어 있었기 때문이다.