AI와 함께 개발하다 보면 역할 분담은 대화의 흐름에 따라 조금씩 변해버린다. 오늘 잘 통했던 의뢰가 내일도 같은 전제로 통한다는 보장은 없다. 그래서 Step50에서 중요했던 것은 새로운 기능이 아니라, 누가 무엇을 가질지를 GitHub 측의 문서로 고정한 것이었다.

Current Context에서 확인할 수 있는 역할은 명확하다. ChatGPT는 설계·리뷰, Cursor는 구현, GitHub은 정본(Source of Truth), 최종 판단은 인간. Qiita 작업은 OS 본체와 분리하여 진행한다. 이 정리는 소박하지만, 비엔지니어가 AI와 계속 달려나가기 위한 토대였다.

Season 1의 전반부에서는 MCP를 연결하고, Human Approval을 결정하며, Connector와 Dashboard를 키워왔다. 하지만 부품이 늘어날수록 "지금 이 판단은 어디에 남기는가"라는 문제가 무거워진다. 대화는 빠르다. 빠르지만, 그대로 두면 정본이 되지 않는다.

RC 검증 주에 들어서면 이 문제는 더욱 명확해진다. 아침 운영에서 위화감이 느껴졌을 때, ChatGPT의 발화, Cursor의 편집, GitHub의 문서, Issue의 상태가 어긋나 있다면 무엇을 믿어야 할지 알 수 없게 된다. 그래서 Step50에서는 Project Freeze와 ChatGPT Handoff를 통해 역할과 정본의 위치를 고정할 필요가 있었다.

테마는, AI와의 역할 분담을 GitHub에 고정함으로써 대화의 속도보다 설명 책임(Accountability)을 우선시할 수 있게 되었다는 것이다.

AI와 작업하면 잘 풀리는 순간일수록 "이대로 전부 맡기고 싶다"는 유혹이 생긴다. 하지만 맡기는 범위를 말로만 운영하면 성공도 실패도 재현하기 어렵다. 재현하기 어려운 상태는 아침 운영에 적합하지 않다.

Current Context에 나와 있듯이, Step50에서 확정한 선은 다음과 같다. ChatGPT는 설계·리뷰, Cursor는 구현, GitHub은 정본, 최종 판단은 인간. Qiita는 OS 본체와 분리된 독립 프로젝트로 진행한다. 이 구분은 단순한 담당 표가 아니다. 책임의 위치를 명문화했다는 의미가 있다.

ChatGPT가 설계와 리뷰를 담당한다고 결정하면, 적어도 "그 자리의 대화로 본番(Production) 상태를 덮어쓰지 않는다"라는 안심이 생긴다. Cursor가 구현을 담당한다고 결정하면, 편집 결과는 파일 차이(Diff)로서 추적할 수 있다. GitHub을 정본으로 삼으면 대화의 인상보다 커밋(Commit)이나 문서를 우선할 수 있다. 마지막으로 인간이 판단을 가지면 Version이나 공개에 대한 책임이 흐려지지 않는다.

특히 컸던 것은 GitHub을 정본으로 고정한 것이라고 생각한다. AI와의 대화는 이해를 깊게 하는 데는 강력하지만, 현재 위치의 유일한 근거로는 적합하지 않다. 나중에 다시 읽어도 그 발화가 어느 시점의 사실이었는지 알기 어렵기 때문이다. GitHub으로 모으면 적어도 "이 커밋 시점에서 무엇이 확정되었는가"를 추적하기 쉬워진다.

RC 검증 주라는 맥락에서는 이 차이가 상당히 실무적이었다. 아침 결과에 위화감이 생겼을 때, 대화 로그와 머릿속의 이해만으로는 "지금의 공식적인 전제"를 알 수 없다. Issue인지, Current Context인지, 수중의 메모인지, 무엇을 우선해야 할지 망설이기 시작한다. 망설일 때마다 설명 책임은 약해진다. 그래서 Step50에서는 판단의 속도보다 "무엇을 정본으로 남길 것인가"를 먼저 고정할 필요가 있었다.

이 고정은 AI를 약화시키기 위한 것이 아니다. 오히려 반대로, AI를 오래 사용하기 위한 전제라고 생각한다. ChatGPT가 잘하는 것은 논점 정리, 설계 리뷰, 위험의 언어화다. Cursor가 강한 것은 실제 편집을 차이(Diff)로서 쌓아 올리는 것이다. 양자의 강점을 그대로 사용하려면 어디서 대화를 멈추고, 어디서 파일로 떨어뜨리며, 어디서 인간이 최종 판단을 이어받을지가 명확해야 한다.

Qiita를 별도 프로젝트로 나눈 것도 중요했다. 기사 제작은 아무래도 표현을 다듬는 방향으로 끌리기 마련이다. 하지만 OS 본체의 문서나 Version 관리까지 같은 장소에서 다루면, 집필 편의를 위해 정본을 흔들 위험이 생긴다. 분리함으로써 "쓰기 위해 본체를 바꾼다"를 피하기 쉬워졌다.

이는 Qiita 측의 작업을 가볍게 보기 위함이 아니라, 반대로 OS 본체를 지키기 위한 선이기도 했다. 기사를 쓰는 입장에서는 "이 표현이 설명하기 쉬우니까 Current Status도 고치고 싶다", "시리즈의 흐름에 맞춰 Version 쓰는 방식도 맞추고 싶다"라고 느끼는 순간이 있다. 하지만 그 유혹을 허용하면 기록을 위해 정본을 움직이는 순서가 된다. Current Context와 PROJECT_RULES가 강력하게 분리를 요구하는 것은 그 순서의 역전을 방지하기 위해서다.

나아가, 이러한 역할 고정은 공개 여부를 판단하는 경계와도 연결되어 있다. Qiita 게시, Version 확정, 정식 Go 판단과 같은 운영(Production) 작업은 인간이 담당한다. 이 부분이 모호하면 ChatGPT의 제안, Cursor의 편집, GitHub 상의 진척 상황이 그대로 "결정된 사항"처럼 보이기 시작한다. Step50에서 최종 판단을 인간에게 고정함으로써, 제안과 결정, 편집과 승인이 동일한 것으로 흘러가는 것을 막을 수 있었다.

AI와의 역할 분담에서 가장 무서운 것은 능력의 부족보다 경계의 모호함이라고 생각한다. 설계와 구현, 그리고 공개 판단이 뒤섞이면 누가 어디서 멈춰야 하는지 알 수 없게 된다. 멈추는 지점이 모호하면 속도는 날 수 있어도 설명 책임 (Accountability)이 남지 않는다. 설명 책임이 남지 않는 상태에서의 속도는 오래 지속될 수 없다.

비엔지니어(Non-engineer)의 입장에서는 이 정리가 상당히 효과적이었다. 코드의 세부 사항을 전부 평가할 수 없더라도, "이 이야기는 GitHub에 남아 있는가", "이것은 구현인가 판단인가"는 확인할 수 있다. 확인할 수 있는 경계가 늘어나면 AI에게 맡기는 것에 대한 불안감이 줄어든다. 불안이 줄어드는 것은 무작정 떠넘겼기 때문이 아니라, 오히려 떠넘기지 않는 형태가 확립되었기 때문이다.

Human Approval과도 연결된다. Human Approval은 운영 작업에 경계를 긋는 사상이었다. Step50의 역할 고정은 그것을 프로젝트 전체로 확장한 형태에 가깝다. 어디까지를 AI가 담당하고, 어디서부터를 사람이 가질 것인가. 모호한 선의가 아니라 문서화된 운용으로 만든 것이 크다.

나는 처음에 역할 분담이라는 말이 조금 사무적으로 느껴졌다. 하지만 실제로는 이는 작업 분담보다 "책임의 교통정리"에 가까웠다. 설계 리뷰가 강력해도 구현 차이(Diff)가 보이지 않으면 곤란하다. 구현이 빨라도 정본(Source of Truth)이 모호하면 나중에 추적할 수 없다. 공개까지 단숨에 흘러가더라도 누가 마지막에 멈출지가 결정되어 있지 않으면 두렵다. 역할을 고정하는 것은 각자의 강점을 활용하기에 앞서, 사고의 기점을 줄이는 일이었다.

GitHub를 정본으로 두는 의미도 단순히 편리하기 때문만은 아니라고 생각한다. GitHub에 두면 대화보다 차갑다. 하지만 차갑기 때문에 강력하다. 커밋(Commit), 파일, Issue, Release의 형태로 떨어지는 것만이 나중에 동일하게 다시 읽을 수 있다. AI와 함께 달릴수록 그 차가움이 필요해진다. 대화가 부드럽게 앞으로 나아가게 해주기에, 어딘가에 딱딱한 지면이 필요하다. 그 지면이 바로 GitHub였다.

Qiita를 독립 프로젝트로 분리한 의미도 매일의 운용을 생각할수록 무거워진다. 기사를 쓰다 보면 가독성을 위해 주어를 맞추거나, 시계열을 압축하거나, 보충 설명을 넣고 싶어진다. 그러한 편집 감각은 필요하지만, OS 본체의 정본으로 가져와서는 안 되는 것이다. 분리되어 있다면 기사 측에서는 표현을 다듬으면서도, 본체 측에서는 사실의 고정을 지킬 수 있다. 이 이층 구조가 나누어져 있는 것만으로도 일상적인 작업은 상당히 안전해진다.

결국 여기서 지키고 싶었던 것은 AI를 신뢰하지 않는 것이 아니라, 신뢰를 두는 곳을 틀리지 않는 것이었다. ChatGPT는 설계와 리뷰에서 신뢰한다. Cursor는 편집과 구현에서 신뢰한다. GitHub는 정본으로서 신뢰한다. 인간은 최종 판단에서 책임을 갖는다. 이 체계가 있으면 무언가 흔들릴 때도 "어디로 돌아가야 할지"를 알 수 있다. 매일 만지는 운영 OS에서는 그 돌아갈 곳이 있다는 사실 자체가 상당히 크다.

매일 공개하고 싶다, 매일 아침 자동으로 돌리고 싶다와 같은 지속 운용의 욕구는 강하다. 하지만 지속은 기합이 아니라 경계에 의해 지탱된다고 생각한다. 누가 생각하고, 누가 고치고, 어디에 남기며, 누가 결정하는가. 이 선이 결정되지 않은 채 수량만 늘리면, "어제는 통과했는데 오늘은 설명할 수 없다"는 식으로 무너지기 쉽다. Step50에서 고정한 역할 분담은 화려한 개선은 아니지만, 매일 계속하기 위한 토대 그 자체였다.

특히 Qiita처럼 연일 공개를 목표로 하는 운용에서는 이 토대가 없으면 재고(Stock)만 먼저 약해진다. 공개일이 가까우니까 내보낸다, 이미지가 부족하지만 일단 진행한다, 대화로 합의했으니 확정된 것으로 간주한다. 그러한 지름길을 택하기 쉽기 때문에, 역할과 정본의 경계를 처음에 고정해 두는 의미가 있다. 매일 공개할 수 있는 체제는 매일 노력하는 것보다, 매일 무너지지 않는 선을 남기는 것에서 시작된다.

• AI와의 역할 분담은 그 자리의 대화가 아니라 정본 문서에 고정하는 편이 강력하다
• GitHub를 정본으로 하면 대화의 인상보다 확정된 사실을 우선하기 쉽다
• ChatGPT, Cursor, 인간의 책임 경계를 나누면 판단의 미아가 줄어든다
• Qiita를 본체와 분리하면 집필 편의 때문에 정본을 흔들기 어렵다
• 경계가 명문화되면 비엔지니어라도 운용 책임을 갖기 쉽다

이 내용 다음에 쓴다면, 테스트가 Green임에도 Go를 하지 않았던 이유로 이어진다. 역할이 정리되어도 정식 버전의 판단은 별도의 기준으로 멈추기 때문이다.