서론

개인 개발에서 인간은 제품 판단과 '리스크 검수'(인증이나 데이터 삭제와 같은 리스크 영역만, 인지한 상태에서 떠맡는 것)에 집중하고, 구현은 AI에게 맡기는 운용 방식을 시도하고 있습니다. 마침 새로운 기능 3개를 만들 예정이었기에, 이 체제를 그대로 실전에 투입해 보았습니다.

2일 만에 출시 준비까지 도달할 수 있었던 것은 좋았지만, 끝난 뒤 머지(Merge) 전의 대화 내용을 다시 읽어보고 조금 당황했습니다. 이 2일 동안 머지 전에 없앤 지적 사항이 10건이 넘었는데, 그 모든 것을 찾아낸 것이 Claude Code나 Codex였으며, 제가 처음으로 알아챈 것은 단 하나도 없었습니다.

이 사실을 깨달았을 때, '나는 무엇을 하고 있었던 걸까'라며 초조해졌습니다. 하지만 다시 읽어보니, 지적을 찾아낸 것은 AI였지만, 그것을 채택할지 말지, 어디까지 수정할지를 결정한 것은 전부 저였다는 사실을 깨달았습니다. 이 기사는 그 2일 동안 실제로 인간이 무엇을 하고, 무엇을 AI에게 넘겼는지에 대한 기록입니다.

세자의 역할 분담

이번에 팀을 구성한 것은 인간, Claude Code, Codex CLI의 세 명입니다. 역할은 다음과 같이 나누었습니다.

나만의 지도·유명 맛집 체크리스트·게시 시 축하 연출이라는, 성격이 다른 3가지 기능을 이 체제로 출시 준비까지 진행했습니다. PR(Pull Request)은 5건, 테스트는 259건에서 297건까지 늘어났습니다.

제가 키보드로 직접 코드를 작성한 시간은 솔직히 거의 없습니다. 대신 시간을 사용한 것은, Codex가 찾아낸 지적 사항을 읽고 "이것은 수정한다", "이것은 이번에는 보류한다"를 판단하는 것과, 리스크 영역에 대한 설명을 제 언어로 다시 말할 수 있는지 확인하는 것이었습니다.

같은 AI에게 설계와 리뷰를 시키지 마라

3자 체제 중에서 가장 도움이 되었던 것은, Claude Code에게 설계와 구현을 시키고, 리뷰는 다른 AI인 Codex에게 맡기는 방식이었습니다. 같은 AI에게 설계와 리뷰를 모두 시키면, 그 AI가 처음에 선택한 전제 자체는 의심받지 않은 채 통과되어 버립니다. 리뷰 역할에는 설계 의도를 일부러 자세히 설명하지 않고, 차이점(Diff)만 보여주도록 한 것도 그 때문입니다.

실제로 찾아낸 지적 사항을 두 가지 적겠습니다.

첫 번째는 유명 맛집 체크리스트를 만들고 있을 때의 일입니다.
Claude Code는 "시드 데이터(Seed Data)로서 처음부터 넣어둔 가게는 created_by가 null로 되어 있다. 이것을 '운영진이 등록한 유명 맛집'의 표식으로 사용하자"라는 설계를 내놓았습니다. 이를 구현하기 전에 Codex에게 전달했더니, 다음과 같은 답변이 돌아왔습니다.

탈퇴 처리 시 사용자의 created_by를 null로 클리어하는 사양이라면, 탈퇴한 사용자가 게시한 가게도 똑같이 null이 되어, 유명 맛집의 표식과 구분이 불가능해집니다.

그 말을 듣고 나서야, 탈퇴 기능 측의 사양과 유명 맛집 기능 측의 설계가 서로 다른 PR로 만들어졌기 때문에 충돌하고 있었다는 것을 깨달았습니다. 설계한 Claude Code 자신은 이 모순을 깨닫지 못했기에, 만약 작성하기 전에 다른 AI에게 전달하지 않았다면 그대로 구현까지 진행되었을 것입니다.

두 번째는 구현 후의 독립적인 리뷰에서 찾아낸 지적 사항입니다. 기존 데이터에 유명 맛집 플래그를 세우는 backfill(백필) 처리에 대해, Codex로부터 "생성일 컷오프(Cut-off)를 넣지 않았기 때문에, 향후 추가될 일반 사용자의 게시물까지 포함하여 유명 맛집으로 취급하게 된다"라는 지적이 돌아왔습니다. 이는 설계 상담 단계에서는 나오지 않았고, 구현이 완료된 코드를 보고 나서야 비로소 떠오른 지적입니다. 설계 시의 리뷰와 구현 후의 리뷰를 모두 도입함으로써, 각각 다른 허점을 찾아낼 수 있었습니다.

제품 판단

한편, AI에게 선택지와 근거는 내놓게 하더라도, 마지막에 결정한 것은 저였던 장면도 있습니다. 도도부현(일본의 광역자치단체) 정복률을 산출하는 기능에서, 분모를 어떻게 할 것인가에 대한 판단이었습니다.

처음에 Claude Code가 내놓은 안은 "해당 도도부현에 등록되어 있는 점포 수"를 분모로 하는 것이었습니다. 논리는 맞고 구현도 깔끔합니다. 하지만 생각하다 보니, 이렇게 하면 타인이 새로운 가게를 등록할 때마다, 나는 아무것도 하지 않았는데 나의 정복률만 내려간다는 사실을 깨달았습니다. 어렵게 가게를 돌며 달성률을 높여 놓아도, 누군가의 게시물 하나로 숫자가 내려가는 경험은 기능으로서 즐겁지 않다고 느꼈습니다.

이것은 AI에게 판단을 맡길 수 없는 종류의 문제라고 생각했습니다. 기술적인 정확성의 문제가 아니라, "이 숫자를 본 사용자가 어떻게 느낄 것인가"라는 취향의 문제이기 때문입니다. 최종적으로 분모는 타인의 게시물로는 변하지 않는 것(처음에 시드(Seed)로 입력한 유명 맛집의 수)으로 고정하기로 했습니다. Claude Code는 이 안을 포함하여 여러 가지 선택지와 각각의 장단점을 나열해 주었지만, 무엇을 선택할지는 스스로 결정하고 있습니다.

리스크 검수(Risk Inspection)의 실제

is_famous 플래그 주변에서는 리스크 검수를 실제로 진행해 보았습니다. 로그인한 사용자가 관리자 화면을 거치지 않고 is_famous를 직접 수정할 수 있는 허점이 있었고, Claude Code가 DB 트리거(Trigger)로 이를 막는 설계를 제안했을 때의 일입니다.

처음에 받은 설명은 이런 느낌이었습니다.

is_famous는 본래 API를 통해 자유롭게 변경되기를 원치 않는 컬럼입니다. 트리거로 보호하면 앱 측의 코드를 거치지 않는 직접 업데이트를 포함하여 차단할 수 있습니다.

읽는 순간에는 "그렇군, 그런 건가" 하고 그냥 넘길 뻔했지만, 이전의 실패를 떠올리며 한 번 내 언어로 다시 말해보기로 했습니다. 몇 번이고 되물은 끝에, 최종적으로는 이렇게 말할 수 있게 되었습니다.

로그인한 사람이라면 누구든 자신의 가게의 is_famous를 true로 바꿔서 유명 맛집 리스트에 끼어들 수 있다. 그러니 API 측뿐만 아니라 DB의 트리거로도 막아두어야 한다.

내 언어로 여기까지 말할 수 있게 된 시점에서 비로소 승인하고 운영 환경에 적용했습니다. "잘 모르겠지만 OK"와 "내 언어로 다시 말할 수 있었기에 OK"는 승인이라는 행위 자체로는 똑같은 1클릭이지만, 그 내용은 완전히 다르다는 것을 이번에도 다시금 느꼈습니다.

잘 풀리지 않았던 점

원활하게 돌아가지 않았던 부분도 두 가지 있었습니다.

첫 번째는 제품 판단이 필요한 상황에서 제가 즉시 답할 수 없는 시간대가 있었다는 점입니다. 외출 중이거나 다른 작업을 하는 중에 "이 UX, A안과 B안 중 어느 것으로 할까요?"라는 질문을 받으면 그 자리에서 판단할 수 없습니다. 결국 답을 할 수 없는 동안에는 Claude Code가 권장안으로 임시 진행하고, 나중에 PR(Pull Request) 리뷰 단계에서 제가 최종 판단을 내리는 방식으로 운영이 정착되었습니다. 임시 결정 상태로 진행하는 것이 조금 찝찝함은 남지만, 매번 손을 멈추고 기다리는 것보다는 현실적이라고 생각합니다.

두 번째는 backfill(데이터 보정)의 예상 건수가 어긋난 점입니다. 사전에 Claude Code와 함께 추산한 대상 건수는 약 292건이었으나, 실제로 운영 환경과 유사한 데이터로 돌려보니 숫자가 맞지 않아 추가 migration(마이그레이션)을 작성해야 하는 상황이 되었습니다. 추산의 근거가 된 쿼리(Query)의 조건이 실제 데이터의 분포와 미세하게 달랐던 것이 원인이었습니다. "실측한 뒤에 믿는다"라는 원칙을 소홀히 하면, AI가 내놓은 숫자라도 이런 일이 발생한다는 것이 이번의 교훈입니다.

마치며

이틀 만에 3개의 기능을 출시 준비 단계까지 가져갈 수 있었던 것은 구현이 빨랐기 때문이라기보다, 지적 사항을 수용하는 역할을 저 혼자에게만 지우지 않았기 때문이라고 생각합니다. 다만, 이 체제가 어디까지 스케일(Scale)할 수 있을지, 기능이 더 복잡해졌을 때도 같은 방식으로 돌아갈지는 솔직히 아직 잘 모르겠습니다.

특히 제품 판단의 경계선은 아직 탐색 중입니다. 이번에는 "도도부현 제패율의 분모"와 같이 명확한 예시였기에 판단할 수 있었지만, 훨씬 사소한 UX의 분기점에서도 지금처럼 계속 스스로 판단할 수 있을지는 다음에 해보지 않으면 알 수 없는 부분이 있습니다. 저와 마찬가지로 AI와 역할을 나누어 개발하고 계신 분이 있다면, 어디에서 선을 긋고 계시는지 알려주시면 감사하겠습니다🙇‍♂️

Discussion