AI에게 "적당히 만들어줘"라고 말하면, 무언가는 만들어진다. 화면도 만들어진다. 문서도 만들어진다. 하지만 "적당히"는 사양 (Specification)이 아니다. "적당히"는 나중에 해석이 갈라진다. 갈라진 해석은 리뷰 (Review)에서 충돌한다. 충돌한 채로 진행하면, 버전 (Version)의 의미가 퇴색된다.

Kagoshimaniax OS를 진행하면서 몇 번이고 같은 벽에 부딪혔다. 구현이 멈춰 있는 것이 아니라, 무엇을 만들어야 할지가 결정되지 않았다. 결정되지 않은 채로 진행하면, 나중에 반드시 되돌아오게 된다. 되돌아오는 비용은 처음에 사양을 결정하는 비용보다 높은 경우가 많았다. 속도는 결단의 대안이 될 수 없다.

연결이 늘어나고, 데이터가 모이기 시작하며, 화면 이야기도 나온다. AI는 선택지를 병렬로 제시할 수 있다. SQLite로 할 것인가, 클라우드로 할 것인가. MCP만 할 것인가, API도 포함할 것인가. 지금 바로 AI 제안 기능을 넣을 것인가. 비교표는 아름답다. 아름다운 비교표는 결정을 내린 듯한 기분을 느끼게 한다.

비엔지니어인 나는 비교표를 보고 안심하곤 했다. 표가 있다 = 생각했다는 기분이 든다. 하지만 표의 행을 선택하는 것은 결국 인간이다. 선택하지 않은 채 "추천은?"이라고 물으면, AI는 또 다른 표를 내놓는다. 추천은 나의 아침의 책임을 대신 져주지 않는다.

폭주를 멈춘 뒤에 남는 것은 공백이다. 멈춰 있는 동안 무엇을 채택할지 결정해야 한다. 공백을 싫어해서 다시 폭주 상태로 돌아갈 것인가, 공백을 사양으로 채울 것인가. 후자를 선택하는 연습이 이 시기의 본론이었다.

테마는 사양·우선순위·비목표 (Non-goal)의 오너는 인간이다라는 것이다.

AI는 제안자로서 우수했다. 조사, 초안, 대안, 리스크 열거. 한편으로, 지역 미디어로서 무엇을 지키고 무엇을 Version 1.0에 포함하지 않을지는 운영의 문맥 (Context)이 없으면 결정할 수 없다. 그 문맥의 소유자는 나였다. 소유를 포기하면 프로젝트는 일반론의 창고가 된다.

사양을 인간이 결정한다고 의식하기 시작한 계기는 기능 요구사항이 부풀어 올랐을 때였다. AI 분석, 자동 개선, SaaS화, 타 업종으로의 전개——모두 장래에 일어날 수 있는 이야기로서 매력적이었다. 하지만 당시의 목적은 훨씬 수수했다. 사이트 분석과 보수를 일원화하고, 필요한 조작을 안전하게 수행하는 것. 수수한 목적은 화려한 제안에 지기 쉽다. 그래서 문서에 쓸 필요가 있었다.

그래서 "비목표 (Non-goal)"를 쓰기로 했다. Version 1.0에 포함하지 않을 것들. 기사 제작의 완전 자동화, 뉴스 수집, 멀티테넌트 (Multi-tenant). 쓰지 않으면 매번 대화가 제자리로 돌아온다. 써두면 AI도 사람도 같은 지도 위에서 거부할 수 있다. 거부할 수 있다는 것은 나아가는 것만큼이나 생산적이다.

비목표의 예를 표로 정리하자 당시의 대화가 상당히 조용해졌다.

• 질문을 한 문장으로 만들기 (무엇을 위해?)
• 선택지를 줄이기 (너무 많은 비교는 결단을 늦춘다)
• 채택 / 기각 / 보류를 명시하기
• 이유를 짧게 남기기 (나중의 ADR이나 리뷰를 위해)
• 완료 조건 쓰기 (무엇이 있으면 Done 인가)

속도만을 중시하는 개발과 사양을 먼저 두는 개발의 차이는 다음 날의 나에게 나타났다. 속도만 빠른 날은 파일은 늘어나지만 설명할 수 없다. 사양을 먼저 둔 날은 차분이 작더라도 "왜 이것인가"가 남는다. 버전 (Version)이 의미를 갖기 시작하는 것도 후자였다. 의미 없는 버전은 그저 날짜 스탬프일 뿐이다.

데이터 계층 (Data layer)에 대한 논의는 사양 오너십 (Ownership)의 시험대였다. AI는 MySQL, PostgreSQL, 클라우드 DB, 스프레드시트, API만 사용 (비영속) 등 선택지를 늘어놓았다. 모두 일리가 있다. 나는 "어제와 비교해서 어떤가"를 아침에 보고 싶다는 운영의 질문으로 돌아갔다. 라이브로 보는 것만으로는 비교의 근거가 남지 않는다. 이력이 필요하다고 결정했다. DB의 세부 사항은 AI에게 맡겼지만, 이력을 남길 것인가는 인간이 결정했다.

실패담: 나는 종종 AI의 자신감 넘치는 문체에 압도당했다. "이것이 표준적입니다"라는 말을 들으면 표준을 채택한 듯한 기분이 든다. 하지만 표준은 나의 아침 10분을 보장하지 않는다. 표준인지 여부보다 Kagoshimaniax에서 가치가 나오는지가 중요하다. Dogfood (직접 먼저 사용하기) 원칙은 사양 선정의 감각에도 효과적이었다. 자신이 사용하지 않는 표준은 타인을 위한 장식이 되기 쉽다.

또 다른 실패는 사양을 구두(채팅)로만 남긴 것이다. 채팅은 흘러간다. 나중에 "그건 결정되었나?"를 알 수 없게 된다. 결정된 것은 문서나 CHANGELOG, 혹은 짧은 메모로 남긴다. 코드를 쓸 수 없더라도 결정 사항을 문장화할 수는 있다. 문장화할 수 없는 결정은 결정이 아니다. 보류조차도 보류라고 적어두면 자산이 된다.

세 번째 실패는 '보류'를 '미루기'의 다른 이름으로 만든 것이다. 보류는 정보 부족을 인정하는 상태여야 하며, 결단 회피를 위한 피난처가 되어서는 안 된다. 기한이나 재검토 조건을 덧붙여야 한다. 예를 들어 "Metricool의 처리는 OAuth의 안정성을 확인한 후 재판정한다"와 같이 말이다. 조건 없는 보류는 그저 미결 상태일 뿐이다.

네 번째는 버전 (Version) 번호를 올리는 것 자체를 성과로 여긴 것이다. 0.3.0, 0.4.0으로 올라가면 안심하게 된다. 하지만 내용을 설명할 수 없는 버전은 그저 날짜 스탬프에 불과하다. 사양 (Specification)을 먼저 작성한 단계 (Step)만이 버전에 의미를 부여했다. "이 버전으로 아침에 무엇을 할 수 있는가"를 한 문장으로 말할 수 있는가? 말할 수 없다면 번호를 올려도 운영은 편해지지 않는다.

Connector의 분류를 결정할 때도 같은 패턴을 사용했다. SQLite를 향한 정기적 취득과, Interactive MCP의 대화적 심층 탐구——이 모든 것을 같은 유형으로 밀어 넣으려 하면 사양이 왜곡된다. 왜곡된 사양은 구현 (Implementation) 속도로 일시적으로 숨겨질 수 있다. 숨겨지더라도 리뷰 (Review)에서 반드시 드러난다. 드러났을 때 인간이 "유형을 분리한다"라고 다시 결정할 수 있었던 것은, 오너십 (Ownership)이 조금씩 근육처럼 붙고 있었기 때문이다.

사양을 문서로 남기는 습관은 처음에는 번거로웠다. 채팅이 더 빠르다. 하지만 빠른 합의는 흘러가 버린다. 흘러가 버린 합의는 동일한 논의를 두 번 반복하는 비용을 발생시킨다. 두 번 반복하는 비용이 더 높다는 것을 깨달은 후부터는 짧은 메모라도 남기게 되었다. 남기는 행위 자체가 사양의 오너 (Owner)라는 증명이 되었다.

사양을 결정하는 것은 권한의 문제가 아니라 책임의 문제라고 생각한다. 채택한 사람이 잘 풀리지 않았을 때 책임을 진다. AI에게 채택하게 하면 책임의 소재가 사라진다. 사라진 책임은 실제 서비스 사고가 발생했을 때 가장 큰 대가를 치르게 한다. 책임을 질 각오가 있는 것만을 사양으로 만든다. 각오가 없는 것은 실험으로 두거나, 하지 않는 것으로 결정한다.

또한, 사양은 한 번 쓰면 끝나는 것이 아니다. 구현을 해보니 Interactive MCP처럼 "모두를 같은 유형으로 하지 않는다"와 같은 수정도 일어났다. 중요한 것은 편차를 숨기지 않고 성숙 (Maturity)으로 기록하는 것이었다. 설계 변경을 패배로 여기지 않는 문화는 비엔지니어 (Non-engineer) 프로젝트일수록 더 필요하다. 완벽한 초기 설계보다 설명 가능한 변경 이력 (Change log)이 더 신뢰할 수 있다. 신뢰는 정답을 연출하는 것이 아니라 추적 가능성 (Traceability)에서 나온다.

AI와의 논의에서 좋았던 점은 반대 의견을 끌어낼 수 있었다는 것이다. "이 사양의 약점은?", "하지 않았을 때 잃는 것은?"라고 물으면 채택의 해상도가 높아진다. 찬성만 하는 AI는 기분은 좋지만 사양은 거칠어진다. 거칠어진 사양은 구현 속도로 속일 수 없다.

비엔지니어가 할 수 있는 사양 관련 업무는 구현보다 앞선 단계에 있다. 무엇을 지킬 것인가. 무엇을 지금 버릴 것인가. 무엇을 기준으로 완성이라 할 것인가. 이것들에 답하지 못한 채 진행된 구현은 리뷰에서 반드시 되돌아온다. 되돌아올 때마다 사양을 결정하는 것은 인간이라는 사실을 뼈저리게 느꼈다.

사양을 결정한다는 것은 정답을 맞히는 것이 아니다. 책임의 위치를 정하는 것이다. AI에게 정답을 요구하면 일반론이 돌아온다. 일반론은 안전하게 들리지만, 지역 미디어의 아침에는 와닿지 않는다. 와닿는 사양은 수수하고, 설명 가능하며, 스스로 책임질 수 있는 것뿐이다. 그 기준에 따라 SQLite에 관한 이야기도 다음으로 진행할 수 있었다. DB의 상세 내용은 AI가 제안했고, 이력을 남길지 말지는 내가 결정했다. 역할 분담이 명확해졌다.

• AI는 사양의 안을 낼 수는 있지만, 사양의 오너가 될 수는 없다
• 비목표 (Non-goal)를 작성하면 대화의 노이즈가 줄어든다
• 채택/기각/보류를 명시하지 않으면 결정된 것이 아니다
• 채팅상의 합의는 흘러가기 쉽다. 짧은 문서로 남긴다
• 보류에는 재검토 조건을 붙인다
• 변경은 실패가 아니라, 구현 경험에 따른 성숙으로 기록할 수 있다

다음은 사양 중에서도 특히 컸던 데이터 계층 (Data layer) 이야기——왜 SQLite를 선택했는가——를 쓸 것이다. 라이브로 보는 것만으로는 부족해진 날의 이야기다.

"지금은 어떤가"에서 "어제와 비교해 어떤가"로 나아간 판단을 적습니다.