우리는 실제로 AI 에이전트로 복합 시스템을 배포하는 방법
Source: Dev.to
Part 1: 왜 옛날 플레이북은 더 이상 통하지 않을까
내가 아는 모든 창업자는 같은 이야기를 가지고 있다. 두 주를 예상했지만, 여섯 주에 배포한다. 그 “간단한” 결제 연동이 아무도 알려주지 않은 엣지 케이스를 쫓는 3주가 된다.
그곳에 가봤다. 그걸 해봤다. 너무 많이.
수년간 우리는 그냥 받아들였다: 복잡성 = 시간. 뭔가 견고하게 만들고 싶다면? 속도를 늦추라. 빨리 움직여야 한다면? 구석을 잘라내고 프로덕션에서 깨지지 않길 바란다.
하지만 2025년 무렵 무언가가 변했다. 그리고 이것이 내가 이 글을 쓰는 이유다.
AI 에이전트는 이제 단순한 자동완성 그 이상이다. 그들을 제대로 설정한다면(그리고 정말로 적절히 제약한다면) 실제 작동하는 시스템을 만들 수 있다. 스니펫이 아니다. 보일러플레이트가 아니다. 테스트를 통과하는 실제 비즈니스 로직이다.
핵심은 AI를 단순히 사용하는 것이 아니라, 복잡한 무언가가 필요할 때 바로 무너지 않도록 사용하는 것이다. 나는 이를 contract‑first 개발이라고 부른다: 코드가 작성되기 전에 무엇을 만들지 먼저 확정해 놓는 것이다.
왜 AI와 단순히 대화하는 것만으로는 확장되지 않을까
팀들이 이 일에 몇 주씩 허비하는 모습을 보아왔습니다.
그들은 ChatGPT나 Claude를 열고 “결제 처리를 위한 함수를 작성해줘”라고 입력하고, 돌아오는 코드를 복사‑붙여넣고 다음 작업으로 넘어갑니다. 괜찮아 보이죠. 그러고는 또 다른 코드를 요청하고, 또 또 요청합니다.
3주가 지나고 나서, 실제 부하가 걸리면 체크아웃 흐름이 무너집니다. 비즈니스 로직이 열두 개가 넘는 파일에 흩어져 있고, 그 중 절반은 테스트조차 없습니다. 그리고 그 “간단한 함수”는 모든 곳에 촉수를 뻗어버렸습니다.
보세요, AI와 그냥 대화하면서 바로 프로덕션 수준의 코드를 기대할 수는 없습니다. 그렇게는 안 됩니다.
작동하는 방법: 시스템이 무엇을 하고, 무엇을 하지 않으며, 오류는 어떻게 처리되는지, 데이터는 어떤 형태인지 등을 미리 모두 정의합니다. 먼저 그 경계를 확정합니다. 그런 다음 에이전트가 그 경계 안에서 구현을 채워 넣게 합니다.
사람이 경계를 설정하고, AI가 그 안에서 작업을 수행합니다.
팀처럼 생각하세요, 한 사람처럼이 아니라
대부분의 사람들은 “코딩에 AI를 활용한다”는 것을 하나의 대화, 하나의 에이전트, 하나의 결과물로 떠올립니다. 이는 곧 여러분을 제한하게 됩니다. 실제로 효과적인 방법은 여러 전문가가 있는 것과 비슷하지만, 그들이 기계 속도로 작업한다는 점입니다.
조각들이 어떻게 맞춰지는가
- Planner – 무엇을 만들지 결정합니다.
- Implementer – 코드를 작성합니다.
- Reviewer – 문제를 찾아냅니다.
- Tester – 작동함을 증명합니다.
각 단계는 구체적인 산출물을 다음 단계에 전달하며, 이전 단계에 대한 가정은 없습니다.
실제로 언제 필요할까요?
하나의 파일에 함수 하나만 작성한다면 단일 에이전트면 충분합니다. 여러 구성 요소가 있는 무언가를 구축하게 되면, 서로 다른 작업을 담당하는 다양한 에이전트가 필요합니다. 그렇지 않으면 에이전트가 너무 많은 일을 하려다 보니 어느 것도 잘하지 못하게 됩니다.
간단 예시
주문 서비스 구축:
- Planner says: “이것을 API 사양, 도메인 모델, 데이터베이스 레이어, 트랜잭션 핸들러, 테스트 스위트로 나누세요.”
- Agent A는 OpenAPI 사양을 생성합니다.
- Reviewer는 이를 보안 규칙에 맞추어 확인합니다.
- Agent B는 실제 코드를 구현합니다.
- Tester는 사양을 기반으로 테스트를 작성합니다.
- Final review는 병합 전에 진행됩니다.
각 단계는 구체적인 결과물을 생성합니다. 이전 단계가 무엇을 했는지 추측할 필요가 없습니다.
먼저 계약을 고정하라
실제 상황에서 실제로 효과가 있는 것은 무엇일까요?
- 구현 전에 엄격한 API 사양을 생성하세요—REST는 OpenAPI, gRPC는 Protobuf. 이것이 에이전트가 따라야 할 규칙이 됩니다.
- 아키텍트의 역할: 도메인 모델을 검토하고, 관계(
User↔Subscription등)가 타당하고 비즈니스 문제를 해결하는지 확인합니다. - 에이전트의 역할: 모델을 받아서 지루한 세부 사항—오류 응답, 엣지 케이스, 데이터 타입—을 채웁니다. 이는 사람에게는 귀찮지만 실수하기 쉬운 부분입니다.
시스템을 처음부터 복잡성을 처리하도록 설계하세요. 나중에 문제가 발생했을 때 추가하는 것이 아니라.
핵심 요점
먼저 계약을 잠그세요. 그런 다음 에이전트가 코드를 채우도록 하세요.
다음 단계
- Part 2: 컨텍스트 설정, 검증 레이어 구축, 그리고 실패 처리.
- Part 3: 개입 시점, 흔한 실수, 그리고 효과적인 도구.
이것은 “AI 에이전트를 활용한 복합 시스템 구축” 시리즈의 Part 1입니다.