Fire-and-forget AI 엔지니어링: 에이전트가 감독 없이 프로덕션 앱을 배포하게 하는 방법

"AI 에이전트가 GDPR 감사 로그와 암호화가 내장된 프로덕션 랜딩 페이지를 방금 구축했습니다. 저는 책상에 앉아 있지도 않았습니다."

이것은 운 좋은 단발성(one-shot) 결과가 아닙니다. 이는 반복 가능한 워크플로우입니다. Piotr Karwatka는 CRM/ERP를 위한 AI 엔지니어링 파운데이션 프레임워크(AI-Engineering Foundation Framework)인 Open Mercato를 사용하여, 별도의 감독이나 핑퐁식 프롬프팅(ping-pong prompting) 없이 아이디어에서 프로덕션 준비가 된 앱으로 나아가는 방법을 보여주는 전체 튜토리얼을 기록했습니다.

이것은 기술적인 버전입니다: 루프(loop)가 실제로 어떻게 생겼는지, 왜 무너지지 않는지, 그리고 여러분의 스택에 적용할 수 있는 패턴은 무엇인지에 대한 내용입니다.

대화형 코딩(conversational coding)의 문제점

기본적인 AI 코딩 루프는 단일 스레드(single-threaded)이며 인간에게 종속되어 있습니다:

프롬프트(prompt) -> 생성(generate) -> 버그 발견 -> 수정 -> 재프롬프트(re-prompt) -> 반복

이는 코드 조각(snippets)에는 유효합니다. 하지만 작업이 실제 아키텍처(architecture) — 멀티 테넌시(multi-tenancy), RBAC(역할 기반 액세스 제어), 이벤트 흐름(event flow), 암호화(encryption), 감사 로깅(audit logging) — 에 닿는 순간 붕괴됩니다. 수정 사항이 컨텍스트 윈도우(context window)에 쌓이면서 에이전트는 맥락을 놓치게 되고, 당신은 다시 타이핑을 해야 합니다. 당신이 내부 루프(inner loop)에 앉아 있는 병목 현상(bottleneck)이 되는 것입니다.

튜토리얼의 워크플로우는 당신을 **외부 루프(outer loop)**로 이동시킵니다. 당신은 모든 키 입력 대신, 완료되고 테스트된 PR(Pull Request)을 검토합니다.

목표(goal) -> 에이전트: 브랜치 생성(branch) + 구현(implement) + 테스트(test) + PR 오픈 -> 당신: PR 검토

Open Mercato에서 이것이 가능한 이유는 어려운 아키텍처 결정이 이미 컨벤션(conventions), 명세(specs), 그리고 에이전트가 읽을 수 있는 기술(AGENTS.md, 작업 라우팅, 명세 기술)로 인코딩되어 있기 때문입니다. 에이전트는 RBAC나 GDPR 로깅이 어떻게 작동해야 하는지를 발명하는 것이 아니라, 파운데이션을 읽고 이를 따릅니다.

1. Fire-and-forget: 자율적인 PR 루프

실행 에이전트(execution agent)는 전체 작업 단위를 소유합니다:

1. git checkout -b feat/lead-capture-landing
2. 프레임워크 컨벤션에 따라 구현
3. 테스트 스위트 실행 (Playwright 통합 테스트 포함)
...

이제 더 이상 토큰을 수정하는 단계가 아닙니다. 결과물은 검토 가능한 산출물(artifact)입니다. 이 튜토리얼에서 출력되는 결과물은 구체적입니다. 즉, 리드(leads)를 Open Mercato CRM으로 직접 캡처하는 라이브 사이트이며, GDPR 감사 로그(audit logs)와 암호화(encryption)가 기본적으로 활성화되어 있습니다. 이는 컴플라이언스 검토 후에 사후적으로 덧붙여진 것이 아닙니다.

2. main을 건드리지 않는 병렬 에이전트 (Parallel agents)

이 부분이 대부분의 사람들이 실수하는 지점입니다. 에이전트 하나는 사소한 문제입니다. N개의 에이전트를 병렬로 실행하는 것은 보통 파일 충돌과 main 브랜치의 손상을 의미합니다.

해결책은 설계에 의한 격리(isolation by design)입니다. 각 에이전트는 자신만의 브랜치/워크트리(branch/worktree)에서 작업하며, 절대 main에 직접 쓰지 않습니다:

main
 |-- agent-a -> feat/landing-page      (worktree A)
 |-- agent-b -> feat/crm-webhook       (worktree B)
...

병렬성은 안전할 때만 유용합니다. 여기서의 안전함은

에이전트는 몇 시간 동안 자율적으로 실행되며, 이는 긴 에이전트 세션의 진짜 적이라 할 수 있는 **컨텍스트 번아웃 (context burnout)**을 노출시킵니다. 단일 에이전트가 긴 작업을 수행하면 히스토리로 인해 컨텍스트 윈도우(window)가 가득 차고 일관성(coherence)을 잃게 됩니다.

해결책은 계층적 오케스트레이션 (hierarchical orchestration)입니다:

            +---------------------+
            |  Coordinator agent  |  계획을 보유하고, 위임하며, 컨텍스트를 가볍게 유지함
            +----------+----------+
...

코디네이터(coordinator)는 지도를 소유하고, 워커(worker)들은 작업을 소유하며 신선하고 범위가 제한된(scoped) 컨텍스트로 실행됩니다. 이러한 분리가 보통 뒤따르는 품질 저하 없이, 감독 없는 수 시간의 실행을 가능하게 만드는 핵심입니다.

실제로 일반화되는 것들

데모를 걷어내면 세 가지 엔지니어링 원칙이 남습니다:

1. 파운데이션 (Foundation)이 프롬프팅 (prompting)을 이깁니다. 에이전트의 성능은 그 주변에 인코딩된 결정 사항들에 달려 있습니다. 컨벤션(conventions) + 스펙(specs) + 스킬(skills)을 배포하면 아키텍처에 대한 논쟁이 멈추게 됩니다.
2. 스펙 (Specs)이 레버리지 포인트 (leverage point)입니다. 준수하는 초안을 작성한 다음, 적대적 검토 (adversarial review)를 수행하세요. 사고 과정을 앞단에 배치하면, 잘못된 것을 올바르게 만드느라 에이전트의 런타임(runtime)을 낭비하는 일을 멈출 수 있습니다.
3. 오케스트레이션 (Orchestration)이 새로운 기술입니다. 브랜치 격리 (Branch isolation) + 코디네이터 서브 에이전트 (coordinator sub-agent)는 단일 에이전트를 안전하고 병렬적이며 장시간 실행 가능한 팀으로 바꾸는 배관(plumbing) 역할을 합니다. 이것은 모델이 개선된다고 해서 사라지지 않는 작업이며, 더 나은 모델을 대규모로 사용할 수 있게 해주는 작업입니다.

간과하기 쉬운 세부 사항은 다음과 같습니다: 준수성 (compliance)은 하나의 단계가 아니라, 파운데이션의 속성이었습니다. 규제 시장에서 CRM/ERP를 배포하는 누구에게나, 이것이 게임의 전부입니다.

시도해보기

• ⭐ Open Mercato on GitHub
• 🧪 Live demo
• 📺 Watch the full tutorial

AI 에이전트를 감독 없이 실행해 본 가장 긴 시간은 얼마인가요? 댓글로 알려주세요.