비엔지니어가 완전한 AI 구동으로 실제 SaaS를 출시하기까지 9개월.

구현 단계에서는 Claude Code, Codex, Cursor Composer의 등장으로 운용 방식이 세 번이나 바뀌었습니다.

본문에서는 각 도구의 한계와 전환점을 시간 순서대로 되짚어보고, 최종적으로 정착한 '분업' 스타일을 정리합니다.

이 글은 『Codex가 대단하다—AI 구현의 주역이 교체된, SaaS 개발 후반 6개월 이야기』의 요약본입니다.

각 도구별 구체적인 실수 사례나 사쿠라 클라우드 × Terraform 실제 운용 이야기는 위에서 언급한 전체 버전을 참고해 주세요.

보충: 방법론은 2025년 6월~2026년 3월경 모델을 전제로 합니다. 서비스 개발의 본질은 변하지 않지만, 베스트 스택은 유동적입니다.

요구사항 정의 단계에서는 Claude, ChatGPT, Cursor의 '삼각 검토(三すくみレビュー)'를 거쳐 2개월에 걸쳐 완성했습니다 (상편에서 자세히 다룸). 그 후 구현 단계로 진입합니다.

구현 단계에 들어선 순간, 운용 방식은 바뀔 수밖에 없었습니다. 이유는 간단해서, ChatGPT는 평소 사용하는 코드 에디터에 직접 통합할 수 없기 때문입니다. 브라우저의 ChatGPT에 매번 복사-붙여넣기로 던지자니 파일이 늘어날수록 현실적이지 않습니다.

에디터에 직접 내장된 AI로 구동할 수밖에 없습니다. 여기서부터 구현 주역 교체의 이야기가 시작됩니다.

대략적인 시간 순서대로 정리하면 다음과 같습니다.

'Claude Code는 이미 구현 단계의 주역으로는 상대가 안 되지 않을까?'라고 느낄 정도로, Codex 도입 이후의 차이는 지금도 이어지고 있습니다.

Claude Code를 구현에 본격적으로 운용하자마자 3가지 문제가 빈번하게 발생했습니다. 이것은 'Claude Code가 나쁘다'기보다는, 광범위한 구현에서 문맥을 계속 유지할 수 없는 구조적 한계라고 느꼈습니다.

요구사항 정의에서는 완벽한 명명 규칙(naming)을 제시해 주었지만, 개발 구현 단계에서는 다른 파일에서 명명하는 것을 잊어버립니다. 잊어버린 것만으로도 괜찮은데, 새롭고 게다가 기존과 중복되는 이름을 태연하게 만들어서 구현을 진행합니다.

언뜻 보기에는 깔끔하고 동작도 합니다. 하지만 나중에 디렉터리 전체를 보면, 같은 것을 가리키는 이름이 파일마다 미묘하게 다릅니다. 한 곳을 고치면 관련해서 다른 장소가 망가집니다. 이것만으로 반나절을 날린 적도 있었습니다.

이미 만들어진 디렉터리 구조가 있는데도 Claude Code는 다른 장소에 새로운 디렉터리를 만들어서 비슷한 화면 컴포넌트를 작성하기 시작합니다.

결과적으로, 화면 표시나 CSS 충돌, 라우팅 혼란, 컴포넌트 중복 구현 등. 동작해 봐야 알 수 있는 버그가 양산됩니다.

이것이 가장 힘들었습니다. 프롬프트에 적고, CLAUDE.md에 적어도 잊어버립니다. 단기적인 기억으로는 지시를 기억하지만, 파일을 넘나들거나 시간이 지나면 태연하게 원래대로 돌아갑니다.

태스크를 세분화하거나 CLAUDE.md를 다시 작성했지만, 줄 수가 늘어나면서 같은 현상이 재발합니다. '비엔지니어가 Claude Code만으로 대규모 서비스 개발을 완수하는 것은 무리다'라고 확신했습니다.

'그럼 Cursor로 보완하자'라고 생각했지만, 당시(2025년 8월~9월경)의 Cursor도 구현은 미숙했습니다.

Claude Code로 뼈대를 작성하게 하고, Cursor로 품질을 검토하게 했습니다. 이 역할 고정 덕분에 Cursor는 안정적이었습니다. Claude Code가 폭주했을 때의 스토퍼(stopper)로서 없어서는 안 될 존재가 되었습니다.

하지만 이것만으로는 구현 속도가 이상에서 멀었습니다. '무언가가 근본적으로 바뀌지 않으면 출시할 수 없다'고 느끼기 시작했을 무렵, 전환점이 찾아옵니다.

2025년 9월, OpenAI로부터 GPT-5-Codex가 출시되었습니다.

당시 X(구 Twitter) 업계는 Claude 일색이었다. "Claude Code 최고", "앞으로는 Claude의 시대"라는 의견이 지배적이었다. 반면, 실제 서비스 구현(Production Implementation)에 대한 지견이 깊은 업계에서는 "Codex가 장난 아니다", "진검승부를 하려면 Codex다"라는 목소리가 들려왔다.

Claude Code의 한계를 느끼고 있던 나는 즉시 도입했다. "머리 두 개는 앞서 있다"는 것을 즉각적으로 알 수 있었다.

Codex가 압도적으로 다른 점은 "면(面)을 밀어붙이는 힘"——여러 파일에 걸친 광범위한 구현을 일관성을 유지하며 단번에 진행하는 능력——이다.

• 채팅 잡담 기반의 복잡한 요구사항이라도 정확하게 해석
• 다수의 파일에 걸쳐 일관성을 유지한 아웃풋(Output)
• 디렉토리 구조를 이해한 상태에서, 신규 기능을 기존 문맥(Context)에 올바르게 통합
• Claude Code에서 빈번했던 "구현 붕괴"의 좌절감이 거의 발생하지 않음

다만 Codex도 완벽하지는 않다. 광범위한 영역을 한꺼번에 구현할 수 있는 대신, 세부적인 품질, 에지 케이스(Edge Case), 에러 핸들링(Error Handling)의 정교함은 인간의 판단과 다른 AI의 리뷰가 필요하다.

여기서 전편에서 다루었던 **삼각 리뷰(Three-way Review)**의 진가가 다시 나타난다.

새로운 운영 방식은 다음과 같이 바뀌었다.

• Codex가 초안(광범위한 구현)을 단번에 작성한다 $\rightarrow$ **Claude (Code)**로 문서 일관성, 명명 규칙(Naming Convention), 요구사항과의 대조를 리뷰한다.
• Cursor로 구현 관점에서의 허점, 에지 케이스, 에러 핸들링을 리뷰한다 $\rightarrow$ 수정 사항은 다시 Codex로 돌린다.
• 다시 2~3단계를 반복한다.

역할은 다르지만 구조는 같다. 하나의 AI에 전부 맡기지 않는다. 세 가지 AI로 서로 부딪히며 검증하고, 마지막에는 스스로 판단한다.

이 방식으로 정착한 이후 구현 속도와 품질이 양립하기 시작했다. 그리고 여기서, 전편에서 철저히 준비했던 요구사항 정의의 진가가 드디어 나타났다고 느낀다. 세부 사항까지 문서화되어 있기 때문에 Codex에 전달할 컨텍스트(Context)가 갖춰져 있다. 리뷰 역할을 하는 Claude/Cursor도 요구사항 정의에 비추어 지적을 할 수 있다.

결국, 문서가 잘 정리되어 있어야 AI가 올바르게 일을 한다.

▶ 각 도구에서의 구체적인 실수 사례나, Cursor Composer 등장 이후의 운영 변화, 사쿠라 클라우드(Sakura Cloud) × Terraform 실서비스 운영 이야기는 이쪽으로 $\rightarrow$ Codex가 장난 아니다——AI 구현의 주역이 교체된, SaaS 개발 후반 6개월의 기록

10월 말, Cursor가 Composer를 출시했다. 여러 파일에 걸친 광범위한 구현이나 리팩터링(Refactoring)을 Cursor 상에서 자율적으로 수행할 수 있는 신기능이다.

이것이 결정적이었다. "구현은 대충, 리뷰는 전문"이라고 고정해 두었던 Cursor가, Composer를 통해 구현 정밀도가 격상되었다. Codex만큼은 아니지만, Claude Code보다는 확실히 우위에 있다. 리뷰 역할로서의 정밀도도 더욱 뛰어올랐다.

나의 운영 방식에서 Cursor는 리뷰와 리팩터링을 위한 필수적인 포지션을 확립했다. 반대로 Claude Code는 구현의 주역에서는 물러나, 문서 생성이나 명명·설계 리뷰를 위한 CLI 버전으로서 제한적으로 사용하는 경우가 많아졌다.

AI 코딩의 세계는 정말로 수개월 단위로 세력도가 바뀐다. 하나의 도구에만 매달리는 것 자체가 리스크라는 것을 체감했다.

• 하나의 AI에 맡기면 반드시 어딘가에서 막힌다. 구현 페이즈도 요구사항 정의와 마찬가지였다.
• AI마다 역할을 고정한다. 구현은 Codex, 리뷰는 Cursor, 문서 일관성은 Claude.
• 역할은 시대에 따라 변한다. Cursor Composer로 하룻밤 사이에 변했다. 다음에 무엇이 변할지는 아무도 모른다.
• "대항할 수 없다"고 느껴지면 즉시 갈아탄다. X 업계의 분위기가 아니라 자신의 손과 현장의 목소리로 판단한다. 요구사항 정의가 제대로 되어 있지 않으면 어떤 AI를 써도 결국 막힌다.

AI 코딩은 분업이 정답이다. "AI로 혼자서 전부 할 수 있다"라고 말하는 엔지니어도 있다. 나도 처음에는 그렇게 생각했다. 하지만 진심으로 실서비스를 운영하는 SaaS를 9개월 동안 만들어보며 깨달았다. 할 수 있다. 단, 하나의 AI로는 불가능하다.

마지막으로, 주니어 엔지니어들에게 전하고 싶은 가장 중요한 말.

AI로 초고속 개발이 가능한 시대이기 때문에, 오히려 "어떤 AI를, 왜, 어떻게 구분해서 사용했는가"를 설명할 수 있는 엔지니어가 단가 면에서 앞서나가는 시대가 될 것이다.

"AI를 사용할 줄 압니다"가 아니라, 이렇게 쓸 수 있는지 여부가 관건이다.

스킬 시트에 「Cursor 사용」이라고 한 줄 적는 엔지니어와, AI를 어떻게 분업시켜 어떤 성과를 냈는지 이야기할 수 있는 엔지니어. 프로젝트 단가에서 차이가 나는 것은 틀림없이 후자다.

▶ 완전판 가이드는 이쪽으로 → Codex가 대단하다——AI 구현의 주역이 교체된, SaaS 개발 후반 6개월의 이야기

▶ 무료로 스킬 시트를 만들어 보기 → https://www.skillsheet-port.com/