에이전트가 코드를 쓴다: 제품 규모의 에이전트 개발

먼저 흔한 서사부터 부정하고 시작하겠다. 우리는 이 제품을 처음부터 에이전트로 만들지 않았다.

초기 약 일곱 달 동안, 우리는 에이전트 없이 손으로 짰다. 백엔드 도메인 모듈도, 식단 엔진의 여러 세대도, 첫 모바일 앱도 사람이 한 줄씩 썼다. “AI 회사가 AI에게 자기 코드를 맡긴다”는 그림이 멋져 보이는 건 안다. 하지만 사실이 아닌데 그렇게 쓰는 건, 정확히 우리가 경계하는 종류의 데모 마케팅이다.

전환은 2026년 봄, 제품이 어느 임계점을 넘었을 때 일어났다. 이 글은 그 전환의 이유와, 에이전트에게 제품 규모의 코드를 쓰게 하며 무엇이 깨지고 무엇이 남았는지에 대한 기록이다.

우리가 택한 접근 — SPEC을 단위로, 에이전트를 오케스트레이션으로

에이전트에게 “앱을 만들어줘”라고 말하는 것과, 에이전트가 실제로 출시되는 제품의 코드를 쓰게 하는 것 사이에는 거대한 골짜기가 있다. 그 골짜기를 메운 건 더 똑똑한 모델이 아니라 구조였다.

우리는 자유 발화를 버리고, 일을 SPEC 단위로 쪼갰다. 하나의 SPEC은 “무엇을, 왜, 어떤 조건을 만족하면 끝인가”를 명시한 작업 단위다. 에이전트는 그 SPEC 하나를 받아 계획을 세우고, 구현하고, 검증 게이트를 통과시킨 뒤 변경을 하나의 묶음으로 올린다. 사람은 자연어로 즉흥 지시를 내리는 대신, 이 흐름을 오케스트레이션한다.

SPEC(범위·완료 조건) → 계획 → 구현 → 검증 게이트 → 변경 묶음 → 사람 승인

이 한 줄이 핵심을 담는다. 중요한 건 어떤 도구를 썼느냐가 아니라, 에이전트의 출력이 항상 검토 가능한 작은 단위로 떨어지고, 게이트를 통과하지 못하면 합쳐지지 않는다는 점이다. 자유 발화로 한 번에 거대한 변경을 만들면 어디서 무엇이 틀어졌는지 추적이 불가능하다. SPEC 단위는 에이전트의 속도를 사람이 따라잡을 수 있는 보폭으로 잘라준다.

왜 전환했나 — 데모 AI와 운영 AI의 차이는 개발에도 적용된다

수기 개발의 한계가 가장 또렷이 드러난 건 큰 재작성 앞에서였다. 첫 모바일 앱을 내고 나서, 우리는 매주 반복해 쓰는 관점에서 사용자 동선을 다시 설계해야 한다고 판단했다. 프레임워크를 갈아엎고 UX를 다시 짜는 작업은, 손으로 하면 몇 달이 드는 일이다.

여기서 우리가 제품에 적용해온 철학이 개발 방식으로 그대로 넘어왔다. 우리는 제품의 AI를 만들 때 결정론을 먼저 깔고, 위험한 행위에는 승인 게이트를 둔다는 원칙을 지켜왔다. 에이전트 개발도 똑같이 다뤘다. 에이전트의 창의성에 흐름을 맡기지 않고, 재현 가능한 SPEC과 검증 게이트라는 결정론적 골격 위에 에이전트를 얹었다. 파괴적이거나 되돌리기 어려운 변경은 사람의 명시적 승인 없이는 합쳐지지 않는다.

여기에는 의식적인 트레이드오프가 있었다. 무거운 클라우드 워크플로 엔진을 도입할 수도 있었지만, 우리는 더 단순한 구조를 택했다. 작업 상태를 화려한 런타임이 아니라 추적 가능한 파일과 변경 이력에 남기는 쪽이다. 그래야 에이전트가 무엇을 했는지 사람이 언제든 펼쳐 볼 수 있고, 크래시에도 안전하다. 운영 시스템에서 가장 비싼 건 화려함이 아니라 추적 불가능성이라는 걸, 우리는 제품에서 먼저 배웠다.

무엇을 배웠나 — vibe coding은 깨지고, 구조와 검수 루프가 남았다

속도가 환상이라는 말은 아니다. 우리는 새 프레임워크 위에서 두 번째 모바일 앱을 약 3주 만에 재구축했다. 손으로는 불가능했을 속도다. 하지만 그 속도는 공짜가 아니었고, 그 앞에는 실패가 있었다.

처음 우리가 빠졌던 함정은 흔히 “vibe coding”이라 부르는 것이었다. 구조를 먼저 세우지 않고, 분위기에 맡겨 화면과 로직을 즉흥적으로 생성하는 방식. 처음 며칠은 마법 같았다. 그리고 곧 무너졌다. 레이어가 뒤엉켜 같은 책임이 여러 곳에 흩어졌고, 한 곳을 고치면 예상 못 한 곳이 깨졌다. 에이전트는 빠르게 만들었지만, 빠르게 만든 그 더미를 사람이 이해할 수 없었다.

그래서 우리는 멈추고 다시 깔았다. 즉흥 생성을 버리고, 수평 레이어를 먼저 정의한 뒤 그 위에서 SPEC 단위로 일을 흘려보냈다. 그리고 한 가지를 타협 없이 지켰다 — 에이전트가 쓴 코드는 사람이 검수하는 게이트를 반드시 통과한다. 에이전트는 빠르고 대체로 유능하지만, 가끔 그럴듯하게 틀린다. 그 “그럴듯함”이 가장 위험하다. 검수 루프는 속도를 조금 깎는 대신, 그럴듯하게 틀린 코드가 제품에 섞여드는 걸 막는다.

남은 교훈은 단순하다. 에이전트는 구조를 대체하지 않는다. 구조를 더 빨리 채울 뿐이다. 구조와 검수 루프가 없으면, 에이전트는 더 빠르게 더 큰 부채를 쌓는다.

도구 자랑이 아니라 방법론이다

에이전트 개발은 슬라이드에선 쉽고 제품에선 깨진다. 우리는 우리 제품에서 그 경계선을 먼저 밟아봤다 — SPEC 단위 분해, 검증 게이트, 그리고 사람 검수 루프까지. 어디서 vibe coding이 무너지는지, 어디서 단순한 골격이 무거운 엔진을 이기는지, 직접 부딪혀 봤다.

이건 도구 자랑이 아니라 방법론이다. 그래서 특정 도구가 아니라 당신 팀의 개발 흐름에 맞춰 이식할 수 있다. 에이전트를 제품 규모로 들이는 일을 진지하게 고민하고 있다면 — partners@creativengine.ai.