저는 중고차 수출 기업에 유일한 엔지니어로 합류했습니다.

기존 코드베이스도 없었습니다. 엔지니어링 팀도 없었습니다. 주어진 임무는 단 하나였습니다. 영업, 재고 관리, 백오피스 업무를 위한 내부 운영 플랫폼을 구축하여 프로덕션(Production) 환경에 배포하는 것이었습니다.

4개월 후, 시스템은 라이브 상태가 되었습니다.

75일 이상의 근무일 동안, 저는 153개의 풀 리퀘스트(Pull Requests, PRs)를 생성했습니다.

제가 프로세스를 어떻게 구조화했는지 소개합니다.

"AI 보조" 개발의 문제점

AI 보조 개발에 관한 대부분의 논의는 코드 생성 속도에 집중되어 있습니다.

하지만 이는 더 어려운 질문을 놓치고 있습니다:

무엇을 만들지 결정하는 사람은 누구이며, 그것이 제대로 작동하는지 최종 승인하는 사람은 누구인가?

만약 이러한 결정권을 AI에게 넘겨버린다면, 명확한 책임 소재 없이 빠른 결과물만 얻게 됩니다. 반대로 모든 결정을 온전히 스스로 내리려 한다면, 당신은 병목 현상(Bottleneck)이 됩니다. 즉, 한 사람이 모든 종류의 사고를 동시에 처리하려고 시도하는 상황이 되는 것입니다.

저는 다른 기준을 세웠습니다.

경계선

인간의 영역:

• 요구사항(Requirements): 시스템이 무엇을 해야 하고, 무엇을 하지 말아야 하는가
• 수락 기준(Acceptance criteria): 무엇이 실제로 "완료"된 상태를 의미하는가
• 프로덕션 판단(Production judgment): 무언가를 배포해도 안전한가

AI의 영역:

• 구현(Implementation): 기준을 충족하는 코드 작성
• 코드 리뷰(Code review): 문제점을 지적하고 대안을 제시
• 반복적인 테스트(Repetitive testing): 테스트 케이스 생성 및 어설션(Assertions) 실행

서류상으로는 깔끔해 보입니다.

어려운 점은 이 경계선을 유지하는 것입니다.

Claude Code가 특정 접근 방식을 제안할 때, 그것을 그대로 받아들이고 넘어가고 싶은 유혹이 생깁니다. 하지만 바로 그 지점에서 판단력이 흐려질 수 있습니다.

질문은 단지 "이 코드가 작동하는가?"에 그쳐서는 안 됩니다.

더 나은 질문은 다음과 같습니다:

이것이 올바른 문제를 해결하고 있는가?

그 질문은 인간의 영역에 머물러야 합니다.

실제 워크플로우의 모습

모든 기능은 GitHub Issue로 시작되었습니다.

모호한 작업이 아니었습니다. 평이한 언어로 작성된, 범위가 정해진 설명과 수락 기준(Acceptance criteria)이 포함되었습니다. 다음 날 아침에 읽어도 무엇이 "완료"를 의미하는지 정확히 알 수 있을 만큼 명확했습니다.

그다음 단계는 다음과 같습니다:

1. Claude Code가 구현 사항을 초안(drafted)했습니다.
2. 저는 풀 리퀘스트(Pull Request, PR)를 검토했습니다. 주로 구문(syntax)을 확인하기 위해서가 아니라, 그것이 이슈(Issue)와 일치하는지를 확인하기 위함이었습니다.
3. Claude Code가 수락 기준(acceptance criteria)에 따라 테스트 케이스를 생성했습니다.
4. 저는 병합(merge) 여부에 대한 최종 결정을 내렸습니다.

이슈(Issue)들이 작고 구체적이었기 때문에 PR 개수는 빠르게 증가했습니다.

153개의 PR이 있는 코드베이스가 153개의 기능을 의미하는 것은 아닙니다. 이는 명확한 시작과 끝을 가진, 잘 정의된 범위(well-scoped)의 작업 단위가 153개 있음을 의미합니다.

AI가 잘 처리하는 것

AI는 기대되는 출력값을 명확한 기준에 따라 확인할 수 있는 작업에서 효과적이었습니다:

• 보일러플레이트(Boilerplate) 및 스캐폴딩(scaffolding)
• Cloud Run 설정
• Argo CD 매니페스트(manifests)
• Pub/Sub 와이어링(wiring)
• GitHub Actions 워크플로(workflows)
• 스택 트레이스(stack traces)를 통한 오류 진단
• 솔루션의 형태가 이미 명확한 초안 구현(first-draft implementations)
• 명시적인 수락 기준(acceptance criteria)에 따른 테스트 생성

공통점은 검증 가능성(verifiability)입니다.

기준이 명확할 때, AI는 매우 빠르게 움직일 수 있습니다.

AI가 잘 처리하지 못하는 것

AI는 비즈니스적 판단(business judgment)이 필요한 부분에서는 훨씬 취약했습니다.

AI가 범위를 결정해서는 안 됩니다.

"이것이 시스템에 포함되어야 하는가?"라는 질문은 AI의 질문이 아닙니다.

AI가 운영 준비 상태(operational readiness)를 판단해서는 안 됩니다.

"이것을 프로덕션으로 전환해도 안전한가?"라는 질문에는 비즈니스 맥락, 운영 리스크에 대한 인식, 그리고 책임감이 필요합니다.

또한 AI는 무엇이 누락되었는지 안정적으로 알아차리지 못합니다.

시스템은 사용자의 도메인에 대해 자신이 무엇을 모르는지조차 알지 못합니다.

이러한 순간에 AI의 판단을 자신의 판단과 동일하게 취급하는 솔로 엔지니어(solo engineers)는 시간을 허비하게 됩니다.

맥락 속의 수치들

75 영업일 동안 153개의 풀 리퀘스트(pull requests)를 처리한 것은 하루에 대략 2개의 PR을 처리한 셈입니다.

여기에는 회의, 교육, 화재 진압(firefighting), 그리고 프로덕션 지원(production support)이 포함된 날들도 포함됩니다.

이것은 속도 기록이 아닙니다.

이것은 측정치입니다.

제가 추적을 시작한 이유는 이 프로세스가 단순히 더 빠르게 느껴지는지가 아니라, 실제로 더 빠른지를 알고 싶었기 때문입니다.

프로덕션 전환(production cutover)은 4개월 차에 이루어졌습니다.

시스템은 가동 중입니다.

측정 결과는 유효했습니다.

이것이 팀에게 의미하는 바

대부분의 AI 도입에 관한 대화는 다음과 같이 질문합니다:

한 사람이 얼마나 더 빨라질 수 있는가?

하지만 저는 더 흥미로운 질문은 이것이라고 생각합니다:

팀 전체가 이 경계(boundary)를 일관되게 유지할 때 어떤 일이 벌어지는가?

구현(Implementation)이 빨라집니다.

리뷰(Review)가 빨라집니다.

반복적인 테스트(Repetitive testing)가 빨라집니다.

하지만 판단(Judgment)은 마땅히 있어야 할 곳에 머뭅니다.

병목 현상(Bottleneck)은 코드를 작성하는 것에서 무엇을 작성할지 결정하는 것으로 이동합니다.

그곳이 바로 병목 현상이 존재해야 하는 지점입니다.

도구(Tooling)는 중요합니다. 하지만 진정한 변화는 도구가 아닙니다.

진정한 변화는 운영 모델(Operating model)입니다.

AI 네이티브(AI-native) 개발은 AI에게 소유권(Ownership)을 넘겨주는 것이 아닙니다.

그것은 AI가 실행(Execution)을 가속화하는 동시에, 인간은 방향성, 판단, 그리고 프로덕션 리스크(Production risk)에 대한 책임을 유지하는 워크플로우(Workflow)를 설계하는 것입니다.

그 경계가 75일의 근무일 동안 153개의 PR을 가능하게 만든 것입니다.

그리고 더 중요한 것은, 그것이 시스템을 배포 가능(Shippable)하게 만들었다는 점입니다.