요약 버전: AI는 소프트웨어 전달 방식을 두 가지 모드로 나누었습니다. 바이브 코딩 (Vibe coding)은 일회성 작업에는 빠르고 저렴하지만, 실행 비용이 높고 배포하기에는 위험합니다. 에이전틱 엔지니어링 (Agentic engineering)은 AI를 사양(specifications), 테스트, 그리고 인간의 검토로 감싸 결과물의 신뢰성을 확보합니다. 만약 당신이 전달(delivery)을 관리한다면, 당신의 추정치, 예산, 리스크 레지스터(risk register), 그리고 인력 계획이 모두 바뀌게 될 것입니다.

바이브 코딩 (Vibe coding)이란 무엇이며, 왜 프로젝트 매니저가 관심을 가져야 하는가?

바이브 코딩 (Vibe coding)은 원하는 것을 평이한 언어로 설명하고, AI가 생성하는 결과물을 그대로 받아들이며, 프로그램이 실행될 때까지 오류를 다시 붙여넣는 방식의 소프트웨어 구축 방법입니다. 이 용어는 2025년 2월 Andrej Karpathy가 (karpathy on X) 만든 것으로, 그는 분위기(vibes)에 몸을 맡기고 코드가 존재하는지조차 잊어버리는 상태를 설명했습니다. 이는 빠르고 마법처럼 느껴집니다. 하지만 정의상, 어떤 인간도 코드를 완전히 읽지 않은 상태이기도 합니다.

에이전틱 엔지니어링 (Agentic engineering)은 동일한 개념의 규율 있는 종단(end)입니다. AI가 여전히 구현(implementation)을 작성하지만, 인간이 설계한 사양(specifications), 자동화된 테스트, 그리고 작업 내용을 확인하는 피드백 루프 내부에서 작동합니다. 이 둘은 하나의 스펙트럼 양 끝에 위치합니다 (Wikipedia). 차이점은 팀이 AI를 사용하느냐 아니냐가 아닙니다. 결과물을 얼마나 많은 검증(verification)이 둘러싸고 있느냐입니다. 경험 법칙(Rule of thumb)을 적용하자면, 주말 동안 만드는 프로토타입은 순수한 바이브 코딩 (vibe coding)일 수 있지만, 고객이 의존하는 모든 것은 에이전틱 엔지니어링 (agentic engineering)이 필요합니다.

소프트웨어 개발 생명 주기 (SDLC)에서 무엇이 변하는가?

여러분이 알고 있는 단계들(요구사항 정의 (requirements), 설계 (design), 구축 (build), 테스트 (test), 리뷰 (review), 유지보수 (maintain))이 사라지는 것은 아닙니다. 다만 그 비중이 변할 뿐입니다. AI는 구현 (implementation) 단계를 강력하게 압축합니다. 몇 주가 걸리던 작업이 몇 시간 만에 끝날 수 있습니다. 하지만 요구사항 정의 (requirements), 아키텍처 (architecture), 검증 (verification)과 같이 인간의 속도로 진행되는 부분에 대해서는 거의 아무런 역할도 하지 못합니다. 따라서 병목 현상 (bottleneck)의 위치가 이동합니다. 코드를 작성하는 것이 더 이상 느린 단계가 아닙니다. 정확히 무엇을 만들지 결정하고, 그것이 올바르게 만들어졌는지 확인하는 것이 느린 단계가 됩니다.

이는 Google 백서 (whitepaper)에서 말하는 팩토리 모델 (factory model)로 이어집니다. 팀의 실제 산출물 (output)은 코드가 아니라, 코드를 생성하는 시스템입니다. 공장 관리자는 각 제품을 일일이 손으로 조립하지 않습니다. 대신 생산 라인을 설계하고 품질 관리 (quality control)를 책임집니다. 요구사항 정의 (requirements)는 벽 너머로 던져지는 문서가 아니라 AI와의 실시간 대화가 됩니다. 설계 (design)는 여전히 인간의 영역으로 남습니다. 왜냐하면 트레이드오프 (trade-offs, 예: 일관성 대 가용성, 자체 구축 대 구매)는 비즈니스 맥락 (business context)에 달려 있기 때문입니다. 테스트 (tests)와 평가 (evals)는 AI에게 무엇이 "정확함"인지를 알려주는 계약 (contract)이 됩니다. 그리고 한때 "건드리기에는 너무 위험한" 레거시 코드 (legacy code)는 현대화하기에 안전한 대상이 됩니다.

이제 누가 무엇을 하는가: 지휘자, 오케스트레이터, 그리고 하네스

개발자는 두 가지 모드를 오가며 작업합니다. 지휘자 (conductor) 모드에서 개발자는 AI와 실시간으로 협업하며 나타나는 각 변경 사항을 검토하는데, 이는 복잡하거나 익숙하지 않은 코드에 적합합니다. 오케스트레이터 (orchestrator) 모드에서 개발자는 작업을 정의하여 백그라운드에서 실행되는 하나 이상의 에이전트 (agents)에게 전달하고 나중에 결과를 검토하며, 이는 버그 수정 (bug fixes), 마이그레이션 (migrations), 테스트 생성 (test generation)과 같이 범위가 명확한 작업에 적합합니다. 한 사람이 하루 동안 이 두 가지 모드를 모두 사용하게 됩니다.

모델 자체는 하나의 구성 요소일 뿐입니다. 그 주변에는 모델이 실제 작업을 완료할 수 있게 해주는 규칙 파일 (rule files), 도구 (tools), 샌드박스 (sandboxes), 그리고 검사 (checks)와 같은 하네스 (harness)가 자리 잡고 있습니다. 논문에서 제시된 유용한 방정식은 '에이전트 (Agent) = 모델 (Model) + 하네스 (Harness)'입니다. 이는 매우 단순한 이유로 중요합니다. 에이전트가 무언가 잘못했을 때, 본능적으로 모델을 탓하게 되지만, 대부분의 실패는 누락된 도구, 모호한 규칙, 또는 누락된 검사로 거슬러 올라갑니다. 모델을 교체하는 것보다 컨텍스트 (context)를 올바르게 설정하는 것(에이전트에게 제공하는 사양 (specs), 관례 (conventions), 제약 조건 (constraints))이 품질 향상에 더 큰 도움이 됩니다. 이러한 컨텍스트 파일들을 검토되고, 버전 관리되며, 지정된 담당자가 소유하는 팀 자산 (team assets)으로 취급하십시오.

비용 문제: CapEx와 OpEx의 반전

프로젝트 매니저에게 돈 이야기는 예산에 직결되는 문제입니다. 바이브 코딩 (Vibe coding)은 초기 비용이 거의 제로에 가깝기 때문에 저렴해 보입니다. 하지만 숨겨진 비용은 운영 (operational) 측면에서 발생합니다. 모든 프롬프트 (prompt)는 토큰 (tokens)을 소비하며, "스스로 실수를 수정하라"는 루프 (loop)는 첫 번째 시도의 성공률 (first-pass hit rate)이 낮은 상태에서 토큰을 낭비합니다. 구조화되지 않은 AI 코드는 몇 달 후 버그가 나타날 때 유지보수 세금 (maintenance tax)이 되며, 검증되지 않은 코드는 운영 환경 (production)에서 보안 청구서 (security bill)가 됩니다.

에이전틱 엔지니어링 (Agentic engineering)은 이를 반전시킵니다. 사양 (specs), 테스트 (tests), 컨텍스트 (context)를 설계하는 데 초기 비용을 더 많이 지불하지만, 새로운 기능이 추가될 때마다 발생하는 한계 비용 (marginal cost)은 낮아집니다. 운영 비용을 낮게 유지하는 두 가지 레버 (levers)가 있습니다. 컨텍스트 엔지니어링 (Context engineering)은 매번 전체 코드베이스 (codebase)를 보내는 대신 밀도 있고 관련성 높은 페이로드 (payload)를 보내는 것을 의미합니다. 모델 라우팅 (Model routing)은 어려운 작업은 대형 모델 (large model)로 보내고, 저렴하고 일상적인 작업(단위 테스트 (unit test), 간단한 리뷰 (small review))은 더 작고 저렴한 모델로 보내는 것을 의미합니다. 이는 익숙한 트레이드오프 (trade-off)입니다. 즉, 나중에 낮은 운영 비용 (operating cost)을 얻기 위해 지금 더 높은 자본 비용 (capital cost)을 지불하는 것입니다.

프로젝트 매니저가 견지해야 할 세 가지 사항

1. 80% 문제는 추정의 함정입니다. 에이전트(Agent)는 기능의 대략적인 초기 80%를 빠르게 생성할 수 있습니다. 나머지 20%(예외 케이스 (edge cases), 에러 처리 (error handling), 통합 (integration), 정확성 (correctness))에는 모델이 흔히 결여하고 있는 판단력이 필요하며, 바로 이 지점에서 실제 시간이 소요됩니다. 쉬운 80%가 아니라 어려운 20%를 중심으로 일정을 계획하십시오.
2. 속도 (Velocity)는 빠름 (speed)과 같지 않습니다. METR의 통제된 실험에서, AI를 사용하는 숙련된 개발자들은 스스로가 약 20% 더 빠르다고 믿었지만 실제로는 19% 더 오래 걸렸습니다 (METR). 시간은 코드를 작성하는 것에서 검토 (reviewing)하고 수정 (correcting)하는 것으로 이동합니다. 생산된 코드 라인 수나 체감 속도가 아니라, 전달되고 검증된 작업물을 측정하십시오.
3. AI는 당신의 엔지니어링 문화 (engineering culture)를 증폭시킵니다. 강력한 테스트, 명확한 표준, 그리고 실제 코드 리뷰 (code review)를 갖춘 팀은 AI로부터 훨씬 더 많은 것을 얻습니다. 그렇지 않은 팀은 더 큰 혼란 속으로 더 빠르게 결과물을 내놓을 뿐입니다. 도입 그 자체는 전략이 아닙니다. Stack Overflow 2025 설문조사에 따르면 AI 출력물에 대한 신뢰도가 떨어졌음에도 불구하고 사용량은 기록적인 수준에 도달했습니다.

FAQ

바이브 코딩 (vibe coding)은 프로덕션 환경에서 안전한가요?
그 자체만으로는 그렇지 않습니다. 프로토타입 (prototypes)과 내부 도구 (internal tools)에는 이상적입니다. 고객이 의존하는 모든 것에는 에이전틱 엔지니어링 (agentic engineering)을 정의하는 사양 (specs), 테스트, 그리고 리뷰를 추가하십시오.

AI가 우리 팀의 규모를 줄일까요?
규모보다는 구성 (mix)을 변화시킵니다. 더 작은 팀이 더 큰 문제를 다룰 수 있지만, 희소한 기술은 코드를 타이핑하는 것이 아니라 사양 정의 (specification), 평가 (evaluation), 그리고 아키텍처 (architecture)로 이동합니다.

가장 좋은 첫 번째 단계는 무엇인가요?
사용 중인 스택 (stack), 컨벤션 (conventions), 그리고 엄격한 규칙을 포함한 프로젝트 규칙 파일 (AGENTS.md 또는 그에 상응하는 파일)을 설정한 다음, 코드를 생성하기 전에 테스트와 평가 (evals)를 작성하십시오. 이들이 결합되어 AI와의 계약 (contract)이 됩니다.

경영진에게 리스크를 어떻게 설명해야 하나요?
팀이 에이전틱 엔지니어링 (agentic engineering)을 실천하고 있으며, 인간이 설계한 제약 조건 (constraints) 하에서 AI가 코드를 작성하고 테스트 커버리지 (test coverage)가 정확성을 확인한다고 말하십시오. 이는 "우리는 결제 시스템을 바이브 코딩하고 있습니다"라고 말하는 것과는 매우 다른 대화입니다.

Sources

• Andrej Karpathy, 원본 "바이브 코딩(vibe coding)" 게시물 (2025년 2월): [https://x.com/karpathy/status/1886192184808149383]
• Vibe coding 개요 및 수용도 (Wikipedia): [https://en.wikipedia.org/wiki/Vibe_coding]
• METR, "2025년 초 AI가 숙련된 오픈 소스 개발자 생산성에 미치는 영향 측정" (2025년 7월): [https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/]
• Stack Overflow 2025 개발자 설문조사 (AI 채택 및 정서): [https://survey.stackoverflow.co/2025/]
• 근거 자료: Osmani, Saboo, 그리고 Kartakis, "바이브 코딩을 통한 새로운 SDLC," Google (2026년 5월)