AI 보조 개발 (AI-assisted development)에 관한 많은 글들은 속도에 집중합니다.

코드를 얼마나 빨리 생성할 수 있는지. 시간당 몇 줄을 작성하는지. 아이디어에서 풀 리퀘스트 (pull request)까지 얼마나 빨리 도달하는지 말입니다.

속도는 실재합니다. 하지만 그것은 흥미로운 질문이 아닙니다.

흥미로운 질문은 이것입니다: 누가 무엇에 대해 책임을 지는가?

이것을 잘못 파악하면 속도는 부채 (liability)가 됩니다. 어떻게 그곳에 도달했는지에 대한 인식은 줄어든 채, 잘못된 방향으로 더 빠르게 움직이게 됩니다.

내가 사용하는 경계선

Claude Code를 주요 도구로 사용하여 프로덕션 시스템 (production system)을 구축하는 솔로 엔지니어로서 4개월을 보낸 후, 나는 다음과 같은 선을 그었습니다:

인간 측면 (Human side):

• 요구사항 (Requirements) — 시스템이 무엇을 해야 하는지, 그리고 무엇을 하지 말아야 하는지
• 수락 기준 (Acceptance criteria) — 각 작업 단위에 대해

더 미묘한 사례도 있습니다. 때로는 관찰 단계 (observation phase)에서 얻은 정답이 아무것도 구축하지 않는 것일 수도 있습니다. 저는 한때 서류상으로는 비효율적으로 보이는 워크플로우를 관찰한 적이 있습니다. 수동 핸드오프 (manual handoffs)가 이루어지고, 명확한 상태 추적 (status tracking)도 없었습니다. 본능적으로 이를 시스템화하고 싶었습니다. 하지만 두 가지 요소가 저를 멈추게 했습니다. 첫째, 수동 핸드오프는 시스템이 할 수 없는 역할을 수행하고 있었습니다. 즉, 두 사람의 의견을 일치시키는 대화를 강제하고 있었습니다. 둘째, 해당 워크플로우의 그 부분은 특정 규제 요구사항 (regulatory requirement) 때문에 존재하고 있었습니다. 이는 언제든 변하거나 완전히 사라질 수 있는 것이었습니다. 그 주변에 시스템을 구축하는 것은 수명이 불확실한 것을 유지 관리해야 함을 의미했습니다. 저는 그대로 두었습니다.

관찰 단계 (observation phase)는 무엇을 구축하지 말아야 할지를 알아내는 단계입니다. AI는 그 자리에 없었습니다.

수락 기준 (acceptance criteria)이 인간의 몫이어야 하는 이유

"완료 (Done)"는 기술적 결정이 아니라 비즈니스 결정입니다.

어떤 기능이 모든 테스트를 통과하더라도 여전히 완료되지 않았을 수 있습니다. 아마도 해피 패스 (happy path)는 처리하지만 에러 상태 (error states)를 불분명하게 남겨둘 수도 있습니다. 혹은 고립된 상태에서는 작동하지만 실제 워크플로우에서는 마찰을 일으킬 수도 있습니다. 또는 기술된 문제를 해결할 수는 있지만, 실제로 존재하는 문제를 해결하지 못할 수도 있습니다.

수락 기준 (acceptance criteria)은 비즈니스가 필요로 하는 것과 시스템이 수행하는 것 사이의 번역 계층 (translation layer)입니다. 이 번역을 정확하게 수행하려면 요구사항 (requirements)과 마찬가지로 동일한 도메인 지식 (domain knowledge)이 필요합니다.

저는 GitHub Issue를 작성할 때, Claude Code에게 무엇인가를 구현해 달라고 요청하기 전에 수락 기준 (acceptance criteria)을 먼저 작성합니다. 이 순서가 중요합니다. 구현 (implementation)은 기준에 의해 형성됩니다. 만약 기준이 틀렸다면, 구현은 잘못된 방향으로 빠르게 진행될 뿐입니다.

프로덕션 판단 (production judgment)이 인간의 몫이어야 하는 이유

책임은 도구에 위임될 수 없습니다.

프로덕션 (production) 환경에서 무언가 고장 난다면 — 데이터 손실, 잘못된 계산, 밤새 잘못 실행된 프로세스 등 — 질문은 "AI가 무엇을 했는가"가 아닙니다. 질문은 "누가 이것을 배포하기로 결정했는가"입니다.

그 책임 (accountability)은 어딘가에 존재해야 합니다. 그것은 결정을 내린 사람에게 있습니다.

구체적인 예시를 들어보겠습니다. 고객 측의 이미지 유출 사고가 발생하여 신속한 감사 (audit) 대응이 필요한 상황이었습니다. 참고할 수 있는 과거 데이터가 거의 없었습니다. 모델의 추론 (inference) 능력은 약했습니다. 하지만 최소한의 범위 (scope), 제한된 주장, 명확한 주의 사항 (caveats), 그리고 모든 단계에서의 인간 참여 (humans in the loop)를 통해, 출력물은 여전히 사용 가능한 수준이었습니다. 약한 추론에 인간의 판단이 더해지면 종종 충분히 훌륭한 결과가 나옵니다. 반면, 인간의 체크포인트가 없는 강력한 추론은 상황을 잘못된 방향으로 몰고 가는 원인이 됩니다.

제가 머지 (merge)하기 전에 풀 리퀘스트 (pull request)를 검토할 때, 저는 구문 (syntax)을 확인하는 것이 아닙니다. 저는 다음과 같이 질문합니다:

경계의 오른쪽 영역이야말로 AI가 진정으로 강력한 힘을 발휘하는 곳입니다.

구현 (Implementation), 검토 (Review), 그리고 반복적인 테스트 (Repetitive testing)는 모두 하나의 공통된 속성을 공유합니다. 바로 작업이 시작되기 전에 표준 (Standard)이 명확하다는 점입니다.

수락 기준 (Acceptance criteria)이 작성되면, 정답을 판단할 수 있는 외부적인 척도가 존재하게 됩니다. AI는 그 기준에 맞춰 코드를 작성할 수 있고, 그 기준을 검증하는 테스트를 생성할 수 있으며, 코드가 기준을 충족하지 못할 때 이를 알릴 수 있습니다. 이러한 검증 가능성 (Verifiability)이 이 과정을 가능하게 만듭니다.

보일러플레이트 (Boilerplate)가 가장 명확한 사례입니다. Cloud Run 설정, Argo CD 매니페스트 (Manifests), GitHub Actions 워크플로 (Workflows) 등은 모두 잘 정의된 올바른 형태를 가지고 있습니다. AI는 이를 빠르고 정확하게 만들어낼 수 있습니다. 여기에는 결정해야 할 것이 없습니다. 단지 써 내려가야 할 것이 있을 뿐입니다.

오류 진단 (Error diagnosis) 또한 강력한 사례입니다. 명확한 에러 메시지가 포함된 스택 트레이스 (Stack trace)는 무엇이 잘못되었는지에 대한 명세 (Specification)입니다. AI는 그 명세를 읽고 무엇이 원인이 되었는지 제안할 수 있습니다. 해석의 범위가 제한적이고 확인 가능하기 때문입니다.

제한적이고 검증 가능한 작업에서의 빠른 출력. 그것이 바로 레버리지 (Leverage)가 발생하는 지점입니다.

실질적인 결과

이 경계가 명확해지면, 일상 업무의 느낌이 달라집니다.

저는 Claude Code에게 무엇을 만들지 묻지 않습니다. 무엇을 만들지 결정하고, 이를 수락 기준이 포함된 범위가 정해진 이슈 (Issue)로 작성한 다음, Claude Code에게 이를 구현해 달라고 요청합니다.

저는 Claude Code에게 머지 (Merge) 여부를 묻지 않습니다. Claude Code에게 풀 리퀘스트 (Pull request)를 검토해 달라고 요청하고, 저는 그 검토 내용을 읽은 뒤 직접 결정합니다.

저는 Claude Code에게 시스템이 프로덕션 (Production)에 투입될 준비가 되었는지 묻지 않습니다. 저는 테스트, 로그, 스테이징 (Staging) 환경에서의 동작을 살펴보고 최종 결정을 내립니다.

AI는 빠릅니다. 결정은 저의 몫입니다.

도구가 발전할수록 이것이 더 중요한 이유

AI 도구의 능력이 향상됨에 따라, 이 경계를 옮기고 싶은 유혹이 커집니다.

출력물은 더 좋아집니다. 제안은 더 신뢰할 수 있게 느껴집니다. AI가 대부분의 경우 정답을 맞히게 되면, 스스로 결정을 내리는 과정에서 발생하는 마찰 (Friction)이 불필요하게 느껴지기 시작합니다.

하지만 요구사항 (Requirements), 수락 기준 (Acceptance criteria), 또는 운영 결정 (Production decisions)에 있어서 "대부분의 경우"라는 말은 충분하지 않습니다. 그러한 순간들은 잘못된 결정이 복합적인 결과 (Compounding consequences)를 초래하는 시점입니다.

도구의 성능이 향상된다고 해서 인간의 판단 (Human judgment)이 필요한 영역이 변하는 것은 아닙니다. 다만, 그 외의 나머지 부분들을 인간의 판단 없이 얼마나 더 많이 처리할 수 있는지가 변할 뿐입니다.

이는 인간의 역할이 사라지는 것이 아니라, 집중되고 있음을 의미합니다.

구현 (Implementation)에 쓰는 시간은 줄어들고, 실제로 결정이 필요한 부분에 쓰는 시간은 늘어납니다.

이것은 더 나쁜 상황이 아니라, 더 나은 배치 (Arrangement)입니다. 하지만 이는 경계 (Boundary)가 유지될 때에만 유효합니다.