AI 기반 개발 워크플로우: 소프트웨어 출시를 위한 관리된 운영 체제

병목 현상의 이동

직접 경험해 보기 전까지는 틀린 말처럼 들릴 수도 있는 주장이 하나 있습니다: AI 기반 개발에서 가장 어려운 부분은 코드를 작성하는 것이 아니라, 무엇을 만들지 결정하는 것입니다.

에이전트 기반 개발 (Agentic development)은 병목 현상을 구현 단계에서 제품 소유 (Product ownership) 단계로 이동시켰습니다. 올바르게 만드는 것보다 더 중요한 것은 '올바른 것'을 만드는 것입니다. 무엇을 만들지 결정하는 것이 실제로 그것을 만드는 것보다 더 큰 자산이 되고 있습니다.

저는 수개월 동안 50개 이상의 자율 AI 에이전트 (Autonomous AI agents)를 프로덕션 환경에서 운영해 왔습니다. 안정적으로 결과물을 내놓는 에이전트들은 가장 영리한 프롬프트 (Prompts)를 가진 것들이 아닙니다. 이들은 워크플로우, 즉 AI 에이전트를 고성과 엔지니어링 팀처럼 다루는 관리된 운영 체제 (Governed operating system)를 가진 것들입니다. 그리고 고성과 팀에는 재능뿐만 아니라 인프라 (Infrastructure)가 필요합니다.

바이브 코딩 (Vibe Coding)이 규모가 커질 때 무너지는 이유

분명히 말씀드리자면, 바이브 코딩 (Vibe coding)은 탐색 단계에서는 훌륭합니다. 저는 이를 **바이브 엔지니어링 (Vibe engineering)**이라고 부르고 싶습니다. 코드로 스케치를 하고 AI가 아이디어를 즉흥적으로 제안하도록 두는 그 첫 번째 창의적인 폭발 단계 말입니다. 이는 프로토타이핑 (Prototyping)을 위한 정당하고 유용한 워크플로우입니다.

하지만 무언가를 출시해야 하는 순간 — 사용자에게, 프로덕션에, 혹은 당신의 작업에 의존하는 팀에게 — 바이브 코딩은 부채 (Liability)가 됩니다. Addy Osmani는 이 차이를 정확히 짚어냈습니다: 바이브 코딩은 AI 보조 엔지니어링 (AI-assisted engineering)과 같지 않습니다. 하나는 창의적인 모드이고, 다른 하나는 규율 (Discipline)입니다.

제가 가장 자주 목격하는 두 가지 안티 패턴 (Anti-patterns)은 다음과 같습니다:

1. Zero context engineering (컨텍스트 없는 엔지니어링) — 구조 없이 프롬프트에서 바로 제품으로 넘어가는 방식입니다. 에이전트(Agent)가 무엇을 만들고 있는지 이해하지 못하므로, 아키텍처를 환각(Hallucinate)하고, 인터페이스를 임의로 만들어내며, 확신에 찬 말투로 쓰레기 같은 결과물을 생성합니다.

2. No security scanning (보안 스캐닝 부재) — 느낌(Vibe)대로 짠 코드(Vibe code)를 바로 운영 환경(Production)에 배포하는 것은 매우 위험합니다. 그 코드 안에 무엇이 들어있는지 알 수 없기 때문입니다. 비즈니스에 영향을 미칠 수 있는 거대한 취약점이 포함되어 있을 수 있습니다. 코드를 직접 작성하지도 않았고 검토(Review)하지도 않았다면, 이를 배포하는 것은 도박과 같습니다.

두 문제 모두 동일한 근본 원인을 가지고 있습니다: 바로 워크플로우(Workflow)의 부재입니다.

Research → Plan → Implement 패러다임

Research → Plan → Implement 패러다임: 코드 작성 전 컨텍스트 확보, 실행 전 계획 수립.

A 신뢰할 수 있는 AI 개발 워크플로우는 단순한 패러다임을 따릅니다: Research (조사) → Plan (계획) → Implement (구현).

무언가를 만들려고 한다면, 먼저 모든 요구사항을 체계적인 방식으로 포착하기 위해 무엇을 만들 것인지 계획해야 합니다. 만약 무엇을 만들고 있는지 모른다면, 먼저 그것이 어떻게 만들어질 것인지 조사하십시오. 이 패러다임은 세 가지 뚜렷한 단계로 나뉩니다:

• Research (조사): 실제 결정 사항들 — 프레임워크, 방향성, 아키텍처(Architecture)를 수집합니다. 이 단계는 에이전트(또는 사용자)가 문제 공간(Problem space)을 탐색하고, 문서를 읽으며, 제약 사항을 이해하는 단계입니다. 여기서 컨텍스트 엔지니어링 (Context engineering)이 발생하며, 이는 이후 단계에서 발생할 환각(Hallucination)을 방지하는 정보 계층을 구축하는 과정입니다.

• Plan (계획): 애플리케이션의 모든 요소와 구축할 모든 항목에 대한 단계별 계획을 정의합니다. 계획은 선택적인 오버헤드가 아닙니다. 계획은 인간과 에이전트 모두가 무엇이 "완료(Done)"된 상태인지 일치하도록 유지해 주는 사양서(Spec)입니다.

• Implement (구현): 계획에 따라 실행합니다. 조사가 완료되고 계획이 수립되면, 구현은 단순한 과정이 됩니다. 에이전트는 컨텍스트(Context), 방향성, 그리고 가드레일(Guardrails)을 갖게 됩니다.

저는 실전에서의 RPI 프레임워크에 대해 광범위하게 작성해 왔습니다. 이는 오늘날 대부분의 AI 보조 개발을 지배하고 있는 "프롬프트하고 기도하기(Prompt and pray)" 방식에 대한 해독제입니다. 하지만 RPI는 패러다임일 뿐입니다. 이것이 실제 프로덕션 환경에서 작동하게 만드는 것은 그 밑에 깔린 거버넌스(Governance) 계층입니다.

거버넌스 계층 1: DevOps 우선 (DevOps-First)

에이전트 기반 반복(Agentic iteration)을 가능하게 하는 최소 기능 거버넌스 스택.

시작부터 DevOps를 먼저 생각하십시오. 매우 성숙한 엔지니어링 팀과 마찬가지로, 팀을 지원하기 위해서는 좋은 DevOps 전략이 필요합니다. 만약 에이전트 기반 개발을 사용하고 있다면, 당신은 매우 높은 성능을 내는 팀을 보유한 것입니다. 코드 품질을 보호하고 코드를 배포하여 빠르게 반복할 수 있도록 돕는 좋은 DevOps 전략이 필요합니다.

가장 피해야 할 상황은 확인하고 검증할 수 있는 출력물 없이 코드를 반복하는 것입니다.

다음은 최소 기능 거버넌스 스택입니다:

1. 테스트 가능성을 위한 CI/CD 파이프라인 (CI/CD Pipelines for Testability)

이는 여러분에게 테스트 스위트 (test suite)가 있다는 것을 전제로 합니다. 만약 없다면, 그것이 여러분의 첫 번째 과제입니다. 포괄적인 커버리지를 의미하는 것이 아닙니다. 100% 단위 테스트 (unit tests)를 의미하는 것도 아닙니다. 그저 해피 패스 (happy path)가 작동함을 증명하고 명백한 회귀 (regressions)를 잡아낼 수 있는 기본적인 테스트 스위트면 충분합니다.

AI 에이전트 (AI agent)가 PR (Pull Request)을 생성하면, 여러분의 CI 파이프라인 (CI pipeline)은 자동으로 테스트를 실행해야 합니다. 테스트가 실패하면 에이전트는 피드백을 받습니다. 테스트가 통과하면, 여러분은 신뢰의 기준점을 갖게 됩니다. 이것이 에이전트 기반의 반복 (agentic iteration)을 가능하게 만드는 테스트 강제 아키텍처 (test enforcement architecture)입니다.

2. 배포 및 수동 검토를 위한 CI/CD 파이프라인 (CI/CD Pipelines for Deployment + Manual Review)

프리뷰 환경 (preview environments)으로의 자동 배포는 모든 PR이 직접 방문하여 확인할 수 있는 실제 URL을 갖게 됨을 의미합니다. 더 이상 "내 컴퓨터에서는 잘 되는데"라는 말은 필요 없습니다. 에이전트가 만든 결과물이 프로덕션 (production)에 반영되기 전에, 실제 브라우저에서 실행되는 모습을 직접 확인할 수 있습니다.

여기에는 수동 검토 게이트 (manual review gates)도 존재합니다. 에이전트를 신뢰하지 못해서가 아니라, 프리뷰를 직접 클릭하며 살펴보는 인간은 자동화된 테스트가 놓치는 범주의 버그들, 즉 잘못된 흐름, 혼란스러운 UX, 누락된 엣지 케이스 (edge cases) 등을 잡아낼 수 있기 때문입니다.

3. 브랜치 보호 (Branch Protection)

머지 (merge) 전에 반드시 실행되어야 하는 필수 CI 파이프라인입니다. 그게 전부입니다. 기본적인 브랜치 보호는 최소한의 품질 기준을 통과하지 않은 것이 메인 브랜치 (main branch)에 도달하지 않도록 보장합니다. 이는 가장 단순한 거버넌스 (governance) 메커니즘이자 가장 높은 레버리지 (leverage)를 가진 메커니즘입니다.

이 세 가지 계층은 GitHub의 Well-Architected Framework에서 말하는 "에이전트 거버넌스 (governing agents)"를 형성합니다. 즉, 자율 시스템이 안전하고 빠르게 작동할 수 있도록 하는 인프라입니다.

테이스트 계층 (The Taste Layer): 제품 소유자로서의 인간

모든 것을 바꾸는 통찰은 바로 이것입니다: 인간은 무엇을 만들지 결정하고, 에이전트는 그것을 어떻게 만들지 결정합니다.

취향 (Taste). 당신은 무엇을 만들지 결정하는 궁극적인 결정권자입니다. 그렇기에 제품 소유권 (Product ownership)이 구현 속도가 아닌, 진정한 제약 사항이 됩니다. 인간은 트렌드를 탐색하고 자율적으로 기능을 추가하는 에이전트 파이프라인 (Agentic pipeline)을 만들 수 있습니다. 하지만 인간은 그 범위를 알고 있으며, 애플리케이션의 취향을 정의해야 합니다.

이는 모든 코드 라인을 검토하는 것에 관한 것이 아닙니다. 다음의 두 가지에 관한 것입니다:

1. 무엇을 만들지 결정하기 — 전략적 선택: 어떤 기능이 중요한지, 사용자 경험 (UX)이 어떤 느낌이어야 하는지, 어디에 시간을 투자할 것인지. 이것들은 어떤 에이전트도 당신을 대신해 내릴 수 없는 취향의 결정입니다.

2. 결과물 검토하기 — 코드 차이 (Code diff)가 아니라, 실제 출력물 (Output)을 검토하는 것입니다. 이 기능이 내가 의도한 대로 작동하는가? 느낌이 맞는가? 이 제품에 어울리는가?

에이전트 기반 개발의 성숙도 곡선 (Maturity curve of agentic development)에는 개발자가 루프 (Loop)에서 자신을 완전히 제거하려고 시도하는 단계가 있습니다. 그들은 그것이 작동하지 않는다는 것을 배우게 됩니다. 가장 높은 성과를 내는 패턴은 인간이 명확한 의도를 가지고 에이전트를 지시하며, 구현 세부 사항이 아닌 출력물을 검토하고 취향을 반복적으로 개선하는 것입니다.

실제 관리된 흐름 (A Real Governed Flow)

이 운영 체제에서 새로운 프로젝트를 시작하는 모습은 다음과 같습니다:

1. 프로젝트와 함께 테스트 스위트 (test suite) 생성. 단 하나의 테스트가 통과하는 단 하나의 테스트 파일이라도 좋습니다.
2. 프로젝트 배포를 위한 워크플로우 (workflows) 생성. GitHub Actions, Vercel 등 사용 중인 스택이 무엇이든 — 첫날부터 CI/CD를 연결하세요.
3. 첫 번째 반복 (First iteration): 배포 가능성 (deployability)과 테스트 가능성 (testability)에 집중. 아직 기능을 추가하지 마세요. 뼈대를 배포하고 테스트하는 것에 집중하세요. 접근 가능한 URL이 있는 초록색 파이프라인을 만드는 것이 목표입니다.
4. 해당 단계에 도달하면: 요구사항 (requirements) 반영. 이제 안전하게 반복 작업을 수행할 수 있는 인프라를 갖추게 되었습니다.
5. 애플리케이션 반복 작업 시작 — 에이전트에게 수행할 방대한 작업 루프를 제공하세요. 이슈 (issues)를 생성하면, 에이전트가 해당 이슈들을 해결(burn down)하고, CI가 각 PR (Pull Request)을 검증합니다.
6. 이슈가 발생하면: 훅 (hooks) 추가. 개발 프로세스에서 문제(환각된 파일, 잘못된 패턴, 보안 격차 등)가 보이기 시작하면, 그때 해당 특정 실패 모드를 방지하는 거버넌스 훅 (governance hooks)을 추가합니다.

이것이 바로 제가 3일 만에 인도한 클라이언트 웹사이트부터 50개의 에이전트로 구성된 홈 오토메이션 시스템에 이르기까지 모든 것을 구축해 온 방식입니다. 거버넌스 흐름 (governed flow)은 단순한 의례가 아니라 인프라이기 때문에 확장 가능합니다.

이것이 팀에 의미하는 바

여기서의 변화는 점진적이지 않습니다. 거버넌스 기반의 AI 워크플로우를 채택하는 팀은 단순히 더 빠르게 코딩하는 것이 아니라, "개발"의 의미 자체를 완전히 재정의합니다.

개발자의 역할은 Ran Isenberg가 설명하는 "AI 기반 SDLC (AI-driven SDLC)"로 진화하고 있습니다. 즉, 에이전트가 계획을 코드로 변환하는 기계적인 작업을 처리하는 동안, 인간은 의도 (intent)를 정의하고, 결과물을 검토하며, 품질 표준을 유지하는 역할을 수행하게 됩니다.

하지만 거버넌스 (Governance)는 이 과정을 늦추는 관료주의가 아닙니다. 오히려 더 빠르게 반복 (iterate)할 수 있게 해주는 인프라입니다. CI/CD가 없다면 눈을 가린 채 반복하는 것이며, 테스트가 없다면 망가진 상태로 반복하는 것이고, 브랜치 보호 (branch protection)가 없다면 위험하게 반복하는 것입니다. 거버넌스는 "AI가 코드를 작성한다"를 "AI가 소프트웨어를 출시한다"로 바꾸는 핵심 요소입니다.

핵심 요약 (The Bottom Line)

만약 개발을 위해 AI 에이전트 (AI agents)를 사용하면서 워크플로우 (workflow)를 갖추지 않았다면, 당신은 AI 기반 개발을 하고 있는 것이 아닙니다. 그저 가끔 작동하는 값비싼 자동 완성 (autocomplete) 기능을 사용하고 있을 뿐입니다.

거버넌스가 적용된 운영 체제는 간단합니다. 무엇을 만들지 연구하십시오. 어떻게 만들지 계획하십시오. 계획에 따라 구현하십시오. DevOps 인프라로 프로세스를 보호하십시오. 그리고 안목 (taste)과 제품에 대한 결정은 인간의 손에 맡기십시오.

병목 현상의 위치가 바뀌었습니다. 질문은 AI가 유용한 구현물을 생성할 수 있느냐가 아닙니다. 적절한 컨텍스트 (context)와 가드레일 (guardrails)이 있다면 AI는 충분히 할 수 있습니다. 진짜 질문은, 당신에게 그것을 안전하게 출시할 인프라가 있는지, 그리고 애초에 무엇을 만들 가치가 있는지 결정할 안목이 있는지입니다.