정식 출시(Official Release)가 끝나면, 다음 이야기도 앞으로 나아가고 있는 것처럼 보이게 하고 싶어진다. 나 또한 그렇게 되기 쉽다. 하지만 2026-07-26 시점의 Current Context에는, 공개판 리포지토리(Repository) 분리의 안전한 계획과 새로운 Version의 기능 구현은 미착수라고 명시되어 있다. 이 부분을 모호하게 하지 않는 것 자체가 Kagoshimaniax OS 운영에서는 상당히 중요했다.

PROJECT_RULES에도 미래 예정 사항을 이미 실현된 사실로서 쓰지 말 것, Version을 앞당기지 말 것, 불분명한 사실은 본문에 넣지 말 것이 나열되어 있다. 이번 테마는, "아직 하지 않았다"를 그대로 남기는 것이 개발의 느림이 아니라 신뢰의 관리였다는 이야기다.

Current Context의 현재 위치는 확실하다. v1.0.0은 정식 출시되었고, v1.1.0도 정식 출시되었다. 그 상태에서 미착수로 남아 있는 것은 "공개판 리포지토리 분리의 안전한 계획"과 "신 Version의 기능 구현"이다. 즉, 이 프로젝트는 무엇이든 멈춰 있는 것이 아니라, 끝난 일과 아직 시작하지 않은 일을 구분하고 있다.

Qiita의 기사 작성에서는 이 부분이 어렵다. 연재가 계속되면 독자에게도, 쓰는 사람에게도 "다음은 이렇게 진행될 것이다"라는 분위기가 생기기 쉽다. 하지만 PROJECT_RULES에서는 미구현 기능을 쓰는 것, 미래 예정 사항을 실현된 것으로 취급하는 것, 추측으로 빈틈을 메우는 것이 명확히 금지되어 있다. 기세보다 먼저 선을 지킬 필요가 있었다.

테마는, 미착수 계획을 "진행 중"이라고 쓰지 않음으로써 공개 정보와 정본(Source of Truth) 사이의 괴리를 방지하고 있었다는 것이다.

비엔지니어(Non-engineer)의 입장에서는 미착수라고 쓰는 것이 조금 무섭다. 진전이 없는 것처럼 보이기 때문이다. 하지만 실제로는 반대로, 아직 시작하지 않은 것을 시작하지 않았다고 쓸 수 있는 편이 나중에 더 강력하다. 어디까지가 사실이고 어디부터가 기대인지를 나눌 수 있기 때문이다.

Current Context에서는 현재의 개발 상황에 "미착수"가 그대로 남아 있다. 공개판 리포지토리 분리는 안전한 계획 단계에서 멈춰 있고, 신 Version의 기능 구현도 미착수다. 같은 파일의 "지금 해서는 안 되는 일"에는 미착수 계획을 기성 사실화하는 것, Version 1.0 / 1.1에 신기능을 섞어서 쓰는 것도 명기되어 있다.

PROJECT_RULES에서도 같은 방향성이 반복된다. 미구현 기능을 쓰지 않는다. Release 전의 내용을 완성된 형태로 취급하지 않는다. GitHub의 정본과 다른 정보를 쓰지 않는다. 불분명한 사실은 본문에 넣지 않고 집필 메모에서 멈춘다. 이 반복을 보면, Qiita 측에서 강한 것은 "앞의 이야기를 잘 만드는 것"이 아니라, 정본에서 확정된 것만을 내놓는 것임을 알 수 있다.

이 정리는 Season 2의 현재 위치와도 맞닿아 있다. v1.1.0에서 완료된 것은 Dashboard UI 개선이며, 신 Connector, DB / SQL / 스키마 변경, AI 요약, 자동 제안, 새로운 쓰기 Action은 하지 않았다. 즉 "다음에 무엇을 할 것인가"보다 먼저 "이번에는 무엇을 하지 않았는가"를 명기하고 있다. 이렇게 써 두면 기사 측에서 미래를 앞서 나아가기 어렵다.

또 하나 큰 점은 독자뿐만 아니라 쓰는 사람 자신의 착각도 방지할 수 있다는 점이라고 생각한다. 연재를 쓰다 보면 메모에 있는 계획이 이미 달리기 시작한 것처럼 느껴지는 순간이 있다. 하지만 Current Context의 "미착수"는 그 착각에 브레이크를 건다. 아직 시작하지 않았다면 쓰는 방식도 아직 시작하지 않은 형태로 되돌릴 수 있다.

여기서 효과를 발휘하는 것은 미래를 말하지 않는 것이 아니라, 미래를 사실로서 말하지 않는 것이다. 계획이 있다는 것과 계획이 진행 중인 것은 다르다. 안전한 계획이 필요하다는 것을 알고 있는 것과 그 계획이 움직이기 시작한 것도 다르다. Current Context는 그 차이를 모호하게 하지 않는다. 이 차이를 남겨두는 것만으로도 나중에 기사를 다시 읽었을 때 "당시 어디까지 결정되어 있었는지"가 상당히 보기 편해진다.

PROJECT_RULES가 강력한 이유는 금지 사항이 단발적이지 않고 정보원의 우선순위까지 결정하고 있기 때문이다. GitHub의 코드와 문서, docs/chatgpt/, CURRENT_STATUS.md, Release, Issue / Milestone 순으로 본다. 반대로 말하면 대화의 흐름이나 "슬슬 시작될 것 같다"는 감각은 이 우선순위에 포함되지 않는다. 이 정도로 명확하면 기사 측에서 미래를 이야기로서 보완하기 어렵다.

Qiita 측이 독립 프로젝트가 된 이유도 여기서 작용한다. 기사를 읽기 쉽게 만들기 위해, 무심코 미래의 선을 매끄럽게 잇고 싶어지기 마련이다. 하지만 OS 본체와 분리되어 있기 때문에, 본체의 미착수 상태를 기사 편의를 위해 고쳐 쓰지 않아도 된다. 쓰기 편하게 하기 위해 정본(正本)을 움직이지 않는다. 이 순서가 지켜지고 있기 때문에, 미착수도 미착수 상태 그대로 남겨둘 수 있다.

나아가, Current Context의 '지금 해서는 안 되는 일'과도 연결된다. 거기에는 미착수 계획을 기성 사실화하는 것, Version 1.0 / 1.1에 신기능을 섞어서 쓰는 것이 나열되어 있다. 즉, 미착수의 기록은 단순히 정적인 메모가 아니다. 지금 이 시점에서 기사가 넘어서서는 안 될 선으로서 사용되고 있다. 미착수를 명확히 남겨두고 있기 때문에, 그 선도 명확하게 그을 수 있는 것이다.

이러한 선긋기가 있으면, 정식 출시된 범위도 역으로 명확해진다. v1.0.0은 정식 Go, v1.1.0은 Dashboard UI 개선까지 완료되었다고 단언할 수 있는 이유는, 그 외의 이야기를 섞지 않았기 때문이다. 만약 미착수 계획까지 '진행 중'인 것처럼 보이게 했다면, 지금 어디까지가 완료되었는지도 흐릿해지기 쉽다. 하지 않은 일을 남기는 것은 완료된 사실을 지키기 위함이기도 했다.

나는 이전에 미착수라고 쓰는 것이 부정적인 인상을 줄지도 모른다고 생각했다. 하지만 지금은 오히려 그 표현이 가장 성실하다고 생각한다. 진행되지 않은 것을 숨기면 나중에 독자도 자신도 곤란해진다. 어느 단계에서 무엇이 결정되었는지 되돌아볼 수 없게 되기 때문이다.

AI와 함께 진행할수록 이 선은 중요해진다. 제안은 즉시 나오고 문장도 금방 정돈된다. 그렇기에 정돈된 문장이 그대로 사실을 앞질러 가기 쉽다. PROJECT_RULES가 장래 예정의 앞당기기나 창작을 명확히 금지하는 것은 그 위험을 알고 있기 때문이라고 생각한다.

Human Approval의 사고방식과도 조금 닮아 있다. 할 수 있는 것과, 해도 되는 것을 나눈다. 떠올릴 수 있는 것과, 써도 되는 것을 나눈다. 미착수를 미착수 상태로 남겨두는 것은, 그 경계를 문장 측에서도 지키는 방식이었다.

여기에는 독자에 대한 성실함뿐만 아니라, 개발 팀 측의 방어(defense)도 있다. 일단 '진행 중'이라고 써버리면 그 이후의 대화도 판단도 그 전제에 끌려가기 쉽다. 실제로는 움직이지 않는 계획이 문장 위에서 먼저 달리기 시작한다. 그렇게 되면 나중에 되돌릴 때 설명 비용(explanation cost)이 증가한다. 처음부터 미착수 상태로 남겨두면 그 비용을 짊어지지 않아도 된다.

나는 처음에 미착수의 기록은 단순히 신중할 뿐이라고 생각했다. 하지만 지금은 그것이 운영 OS의 신뢰를 지키기 위한 능동적인 판단이라고 생각한다. 앞의 이야기를 아름답게 잇기보다, 아직 시작되지 않은 것을 그대로 멈춰둔다. 그 멈추는 방식이 있기에 정식 출시된 사실이나 v1.1.0의 완료 범위가 역으로 강하게 보인다.

• 미착수 계획을 미착수라고 쓰는 것은 진척의 약함이 아니라 정보 관리의 강함이 된다
• Current Context와 PROJECT_RULES 양쪽에서 미래의 앞당기기를 금지하는 것은 기사의 창작 방지에 효과적이다
• '한 일'뿐만 아니라 '하지 않은 일'을 명기하면 Version의 경계가 흔들리기 어렵다
• AI와 함께하는 집필에서는 정돈된 문장일수록 사실을 앞지르기 쉬우므로 경계선이 필요하다
• 독자를 위한 설명뿐만 아니라, 쓰는 사람 자신의 착각을 막는 의미에서도 未着手(미착수)는 중요했다

이 내용의 뒤를 이어 쓴다면, 공개 버전 리포지토리 분리(repository extraction)와 같이 '아직 써서는 안 될 이야기'를 어떻게 관리할지로 이어진다. 진행 방식이 확정될 때까지는 소재보다 경계 관리(boundary management)가 더 중요하기 때문이다.