「슬슬 1.0 아닌가?」라는 말은 프로젝트 곳곳에서 들려온다. 그 말이 들릴 때마다 나는 딱 한 번씩 심호흡을 했다. 1.0은 기합으로 만드는 숫자가 아니다. 설명할 수 있는 완성의 선언이다. 설명하지 못한 채 올린 Version은 그저 축배에 불과하다. 축배가 끝난 뒤, 아침의 확인 작업은 변하지 않는다.

Kagoshimaniax OS는 Step48에서 Version 1.0.0-rc1을 배치했다. Release Candidate. 정식 버전 1.0.0 그 자체는 아니다. 하지만 여기까지의 여정을 하나의 매듭으로 부를 수 있는 지점이다. 부를 수 있다는 것은, 더 추가하고 싶은 마음을 한 번 멈출 수 있다는 뜻이기도 하다.

Vol.01부터 되돌아보면 기점은 단순했다. 아침의 확인 작업이 힘들다. 뿔뿔이 흩어진 화면을 오가야 하고, 어제와 비교할 수 없으며, 개선의 우선순위를 정할 수 없다. MCP, SQLite, Connector Platform, Dashboard, Human Approval——수단은 늘어났다. 늘어난 수단들이 목적에 수렴했는지를 물어야 하는 단계에 도달했다.

Version 1.0의 Must(필수 사항)는 사양서에 적혀 있었다. 사이트 분석과 유지보수의 일원화. Human Approval이 포함된 안전한 개선 조작. 10개의 연결, 일일 4개 계통, Dashboard 8개 화면——숫자는 지도의 눈금이다. 눈금이 맞춰져 있어도 내용물이 비어 있다면 의미가 없다. 내용물을 확인하는 주가 RC 이전에 필요했다.

테마는, Step48에서 1.0.0-rc1을 동결하고, Must를 확인한 여정이다.

새로운 기능을 추가하지 않는다. 이미 있는 것들이 약속대로 작동하는지 확인한다. 테스트를 실행하고, Known Limitations(알려진 한계)를 숨기지 않고 적는다. Dogfood Before Deploy——스스로 먼저 사용하며, 본 운영 전에 위화감을 포착한다. RC는 골(Goal)이 아니라, 검증의 시작점이다.

Step47에서 Version 1의 마일스톤을 정리했다. 무엇이 Must이고, 무엇이 1.1 이후인지. AI 분석 본체는 1.1로 넘긴다. SEOPress나 Imagify의 쓰기 작업은 롤백(Rollback) 방침이 확정될 때까지 기다린다. 기다리는 판단은 지연이 아니다. 포함하지 않는 용기다.

Step48은 추가가 아닌 확인의 Step이었다. Connector 10건——WordPress, SEOPress, WP Rocket, Imagify, GA4, Search Console, Clarity, Metricool, GitHub, Obsidian——을 Must의 관점에서 점검했다. SQLite에는 필수 테이블과 행이 있다. system_connector_runs에 실행 이력이 남아 있다. Dashboard에는 8개의 화면이 등록되어 있다.

Human Approval은 단체 테스트(Unit Test)를 통해 「승인 없이는 실행할 수 없음」을 확인했다. Obsidian의 create-note, WP Rocket의 retest-page-insights——Green(정상) 상태에서도 승인을 거치도록 하는 설계가 테스트를 통해 고정되어 있다. 고정은 안심을 주는 형식이다.

테스트는 141건 OK. 숫자가 전부를 증명하지는 않는다. 하지만 망가진 부분을 빠르게 빨간색으로 표시해 준다. 빨간색으로 표시할 수 있게 되면, RC를 내놓을 용기가 생긴다.

Release Notes docs/releases/v1.0.0-rc1.md를 작성했다. 포함하는 것, 포함하지 않는 것, Known Limitations——숨기지 않는 것이 RC의 성실함이다. Sidebar에는 1.0.0-rc1이라고 표시된다. 표시는 작다. 하지만 매일 여는 화면에 Version이 있으면 자신과의 약속이 보인다.

실패담: RC 전에 「딱 하나만 더」라고 말할 뻔한 기능이 있었다. 대시보드의 세밀한 개선, 문구 조정, 편리해 보이는 단축키——모두 나쁘지 않다. 하지만 동결을 깨뜨리면 확인의 축이 어긋난다. 어긋난 축으로 Must를 점검하면 무엇이 1.0인지 모호해진다. 모호한 1.0은 운영 OS가 아니다.

또 다른 실패는 RC를 완벽하다고 착각하는 것이다. RC는 완벽의 증명이 아니다. 더 이상 추가하지 않는 기간의 선언이다. 선언을 지키지 않으면 RC는 단순한 태그가 된다.

세 번째는 Known Limitations를 부끄러워하는 것이다. 부끄러워하며 숨기면 나중에 신뢰를 잃는다. AI 개선 제안의 자동 쓰기는 하지 않는다. 일부 Red Action은 미배선 상태——이렇게 적어두면 기대치가 정돈된다. 기대치가 정돈되면 사용하는 쪽이 편해진다.

Dogfood Before Deploy(배포 전 직접 사용하기)는 RC 직전에 효과를 발휘했다. 나의 아침 루틴으로 Dashboard(대시보드)를 열어, 커넥터(Connector)의 최종 실행을 확인한다. Actions(액션)에서 승인 플로우(Approval Flow)를 만져본다. 만질 수 없는 것은 문서대로 미개방 상태임을 확인한다. 확인은 테스트의 보완이다. 테스트가 통과되더라도, 직접 사용하지 않으면 알 수 없는 위화감이 있다.

태그 v1.0.0-rc1

과 GitHub Pre-release(프리릴리스)를 게시했다. Pre-release라는 단어는 축배의 소리를 낮춰준다. 낮춘 소리일수록 다음 검증에 집중할 수 있다.

Must(필수) 체크리스트를 하나씩 지워나가는 작업은 마치 수수한 게임 같기도 했다. WordPress가 healthy(정상), SEOPress가 healthy, WP Rocket이 healthy——체크가 표시될 때마다 안심이 된다. 하지만 안심은 간과를 낳는다. 간과를 방지하기 위해 SQLite에 행이 있는지, Dashboard가 import(임포트) 에러 없이 열리는지까지 확인했다. 본다는 행위 자체가 비엔지니어(Non-engineer)의 리뷰다.

Imagify는 warning(경고)이 붙었지만 OK였다. 완벽한 초록색만이 OK인 것은 아니다. warning을 허용할지 여부도 사양(Specification)의 일부다. 사양에 적혀 있다면 당황하지 않는다. Metricool는 SQLite에 8행, 인증 디렉터리의 존재까지 확인했다. 숫자는 작지만, 동작했다는 증거로서 충분하다. 테스트 141건의 보고를 보았을 때, 안도와 동시에 냉정해졌다. 테스트는 과거의 약속을 지킨다. 미래의 운영을 지키는 것은 앞으로의 검증 주간이다.

RC까지의 길은 직선이 아니었다. 몇 번이고 되돌아가고, 용어를 통일하고, 쓰기를 멈추고, Connector를 늘리고, 승인을 거쳤다. 직선으로 보이고 싶은 충동이 가장 위험하다. 직선은 회고를 죽인다.

1.0.0-rc1은 '만들기를 끝냈다'가 아니라 '이 형태로 한 번 현실에 내놓는다'이다. 내놓음으로써 비로소 운영의 피드백을 얻을 수 있다. 피드백은 코드보다 잔혹할 때가 있다. 잔혹하기 때문에 미리 동결(Freeze)이 필요하다. 동결이 없다면 피드백 하나에 다시 전체가 흔들린다.

비엔지니어가 RC까지 올 수 있었던 것은 기능을 많이 구현했기 때문이 아니다. Must를 좁히고, 문서로 제약하며, 테스트로 고정하고, 더하지 않는 주간을 선택했기 때문이다. 선택할 수 있다는 것 자체가 성숙의 신호라고 생각한다.

RC라는 단어에 익숙해지기까지 시간이 걸렸다. Release Candidate——후보,라는 울림은 처음에는 '아직 미완성인가?'라는 느낌을 주었다. 하지만 사용하다 보니 후보라는 점의 성실함을 알게 되었다. 완벽한 척하지 않는 Version은 운영자에게 친절하다. 친절하다는 것은 기대치를 올바르게 설정하는 것이다. Version 0.1에서 0.3, 0.5, 그리고 1.0.0-rc1——번호는 건너뛴다. 건너뛰는 이유는 도중에 사양이 성숙했기 때문이다. 번호의 연속성보다 설명의 연속성이 더 중요하다. CHANGELOG(변경 이력)와 ADR(의사결정 기록)이 그 연속성을 지탱했다.

Security(보안) 확인도 Must에 포함되어 있었다. .env나 .auth가 Git에 올라가지 않는 것. 감사 로그(Audit Log)에 인증 정보를 노출하지 않는 것——수수하지만, 유출되면 모든 것이 끝난다. 끝날 리스크는 기능의 화려함과는 무관하다. 무관하기에 체크리스트에 넣었다. 넣은 항목을 사람이 확인한다——이 또한 Human Approval(인적 승인)에 가까운 책임이다.

• Version 1.0은 기합이 아니라, 설명 가능한 완성의 선언
• RC는 신규 기능 없는 동결과 Must 확인의 단계
• 141개의 테스트는 만능은 아니지만, 고장을 빠르게 빨간색으로 표시함
• Known Limitations(알려진 제한 사항)을 적는 것은 약함이 아니라 성실함
• Dogfood Before Deploy는 테스트를 보완함
• 더하지 않겠다는 결단이 Version에 의미를 부여함

다음은 RC를 게시한 후——여기서 끝나지 않는다——라는 이야기를 쓰겠다. 시리즈의 구분과 이미 시작된 운영 검증에 관한 이야기다.

Season 1의 끝과, Step 49 운영 검증 주의 시작을 씁니다.