에이전틱 엔지니어링은 바이브 코딩의 다음 단계입니다. 안드레이 카파시는 Sequoia Capital의 AI Ascent 2026 대담에서, 최신 AI 코딩 도구가 단순한 자동완성 수준을 넘어 개발자의 역할 자체를 바꾸고 있다고 설명합니다. 이제 중요한 질문은 “AI가 코드를 얼마나 빨리 쓰는가”가 아니라, “사람이 에이전트를 어떻게 지휘하고 검증할 것인가”입니다.
왜 에이전틱 엔지니어링이 중요해졌나
카파시는 자신이 “프로그래머로서 가장 뒤처진 느낌을 받았다”고 말합니다. 놀라운 말입니다. 그는 OpenAI 공동창업자였고, Tesla Autopilot 개발에도 참여한 인물입니다. 그런 개발자조차 최신 AI 코딩 도구의 변화 속도 앞에서 기존 감각이 흔들렸다고 말한 것입니다.
2025년 말 이후의 전환점
그가 짚은 전환점은 2025년 말입니다. 이전의 에이전트 도구는 코드 조각을 제안해 주는 보조 도구에 가까웠습니다. 사람이 자주 고쳐야 했고, 결과를 완전히 믿기는 어려웠습니다.
그러나 어느 순간부터 최신 모델은 더 긴 코드 덩어리도 꽤 안정적으로 만들기 시작했습니다. 개발자는 직접 타이핑하는 시간을 줄이고, 요구사항을 설명하고, 결과를 검토하는 쪽으로 이동합니다. 이것이 바이브 코딩의 출발점입니다.
Software 3.0은 무엇인가
카파시는 이 변화를 Software 3.0이라는 개념으로 설명합니다. Software 1.0은 사람이 직접 작성한 코드입니다. Software 2.0은 데이터셋과 신경망 학습으로 만들어진 모델입니다. Software 3.0은 LLM이라는 인터프리터를 프롬프트와 컨텍스트로 조종하는 방식입니다.
코드는 파일에만 있지 않다
Software 3.0에서는 코드만이 프로그램이 아닙니다. 프롬프트, 문서, 테스트, 예시, 오류 로그, 저장소 구조, 컨텍스트 윈도우까지 모두 프로그램의 일부가 됩니다. 개발자는 LLM이 해석할 수 있는 환경을 설계해야 합니다.
이 관점에서는 “좋은 프롬프트”보다 “좋은 작업 맥락”이 더 중요합니다. 에이전트가 문제를 이해하고, 스스로 탐색하고, 실행 결과를 확인할 수 있어야 하기 때문입니다.
바이브 코딩은 누구나 만들게 하지만, 실무는 다르다
바이브 코딩은 아이디어를 빠르게 제품 형태로 바꾸는 방식입니다. 말로 요구사항을 설명하고, AI가 코드를 작성하게 하며, 결과물을 보면서 계속 수정합니다. 이 방식은 진입 장벽을 크게 낮춥니다.
MenuGen 사례가 보여준 것
카파시는 메뉴판 사진을 찍으면 음식 이미지를 붙여 보여주는 MenuGen 앱을 바이브 코딩으로 만들었습니다. 그런데 나중에는 Gemini와 이미지 생성 모델에 메뉴판 사진을 주고 바로 오버레이를 요청하는 방식이 더 자연스럽다는 점을 깨달았다고 말합니다.
이 사례는 중요한 질문을 던집니다. 앞으로 어떤 앱은 더 잘 만들어지는 것이 아니라, 아예 필요 없어질 수 있습니다. 사용자가 원하는 결과를 LLM과 생성 모델이 직접 만들어낸다면, 중간에 있던 많은 소프트웨어 계층이 사라질 수 있습니다.
에이전틱 엔지니어링은 스펙과 검증의 기술이다
카파시는 바이브 코딩과 에이전틱 엔지니어링을 구분합니다. 바이브 코딩이 빠른 구현의 감각이라면, 에이전틱 엔지니어링은 실무 시스템을 안전하게 만들기 위한 설계 방식입니다.
사람이 여전히 책임져야 하는 영역
AI 에이전트는 놀라운 속도로 코드를 작성하지만, 이상한 설계 실수도 합니다. 카파시는 결제 크레딧을 사용자 계정과 연결하는 예시를 듭니다. 에이전트가 Stripe 이메일과 Google 이메일을 단순히 맞춰 자금을 연결하려 했다는 것입니다.
겉보기에는 그럴듯하지만, 실제 서비스에서는 치명적인 설계입니다. 사용자는 결제 이메일과 로그인 이메일을 다르게 쓸 수 있습니다. 이런 문제는 코드 문법이 아니라 도메인 이해, 데이터 모델, 보안, 제품 판단의 문제입니다.
따라서 사람은 스펙, 계획, 판단 기준, 테스트 전략을 책임져야 합니다. 에이전트는 구현을 많이 맡을 수 있지만, 무엇을 만들지와 왜 그렇게 만들어야 하는지는 사람이 설계해야 합니다.
검증 가능한 환경이 AI 제품의 핵심 기회다
카파시는 검증 가능성을 매우 중요하게 봅니다. 코드가 AI에 잘 맞는 이유도 여기에 있습니다. 실행해 볼 수 있고, 테스트할 수 있고, 오류 메시지를 받을 수 있습니다. 즉, 모델이 스스로 개선할 수 있는 피드백 루프가 있습니다.
창업자는 무엇을 봐야 할까
창업자에게 중요한 질문은 “AI로 무엇을 자동화할 수 있나”보다 더 구체적이어야 합니다. “검증 가능한 환경을 어떻게 만들 수 있나”가 핵심입니다. 정답 여부를 측정할 수 있고, 실패를 감지할 수 있으며, 개선 데이터를 쌓을 수 있는 영역이 강력한 기회가 됩니다.
예를 들어 테스트 자동화, 보안 점검, 문서 검증, 데이터 정합성 검사, 운영 절차 자동화 같은 영역은 에이전트와 잘 맞습니다. 반대로 결과가 맞는지 판단하기 어렵고, 책임 소재가 불분명한 영역은 더 조심해야 합니다.
AI 네이티브 개발자의 차이는 어디서 생기나
AI 네이티브 개발자는 단순히 ChatGPT를 자주 쓰는 사람이 아닙니다. Claude Code, Codex, OpenClaw 같은 도구를 자기 작업 흐름에 맞게 세팅하고, 에이전트가 읽을 수 있는 문서와 구조를 준비합니다.
생산성 차이는 타이핑 속도가 아니다
이제 생산성 차이는 코드를 빨리 치는 능력에서만 나오지 않습니다. 문제를 잘게 나누는 능력, 좋은 스펙을 쓰는 능력, 테스트를 설계하는 능력, 결과물을 검증하는 능력에서 차이가 커집니다.
카파시는 뛰어난 개발자가 AI 도구를 잡으면 10배를 넘어서는 생산성 차이가 날 수 있다고 봅니다. 이유는 간단합니다. 좋은 개발자는 에이전트가 놓치기 쉬운 맥락을 알고, 잘못된 방향을 빠르게 감지하며, 더 좋은 작업 환경을 설계할 수 있기 때문입니다.
에이전트 퍼스트 인프라가 필요하다
현재 많은 에이전트는 사람용 웹페이지와 설정 화면을 억지로 조작합니다. 버튼을 누르고, URL을 열고, 메뉴를 찾아갑니다. 카파시는 이런 방식이 비효율적이라고 지적합니다.
사람용 UI와 에이전트용 인터페이스는 다르다
앞으로 서비스는 사람에게 보기 좋은 UI뿐 아니라, 에이전트가 이해하고 실행하기 쉬운 인터페이스를 제공해야 합니다. 명확한 API, 기계가 읽기 쉬운 문서, 구조화된 설정, 자동 검증 가능한 작업 단위가 중요해집니다.
이 변화는 개발 도구에만 국한되지 않습니다. 클라우드, 결제, 데이터베이스, 배포, 보안, 고객지원 도구까지 모두 에이전트 친화적으로 재설계될 가능성이 큽니다.
결론: 개발자는 사라지는 것이 아니라 역할이 올라간다
카파시의 메시지는 개발자의 종말론과 다릅니다. 그는 사람이 여전히 이해와 판단을 담당한다고 봅니다. 다만 직접 코드를 쓰는 비중은 줄고, 에이전트를 지휘하고 검증하는 비중이 커집니다.
에이전틱 엔지니어링 시대의 개발자는 구현자이면서 동시에 감독자입니다. 좋은 개발자는 코드를 많이 쓰는 사람에서, 좋은 문제 정의와 검증 가능한 환경을 설계하는 사람으로 이동합니다.
지금 필요한 준비는 거창하지 않습니다. 작은 프로젝트부터 에이전트에게 맡길 수 있는 작업과 사람이 직접 판단해야 하는 작업을 구분해 보아야 합니다. 그리고 문서, 테스트, 스펙, 배포 절차를 에이전트가 이해할 수 있게 정리해야 합니다. 그것이 바이브 코딩 이후의 실무 경쟁력입니다.
FAQ
에이전틱 엔지니어링은 바이브 코딩과 무엇이 다른가요?
바이브 코딩은 AI와 대화하며 빠르게 구현하는 방식에 가깝습니다. 에이전틱 엔지니어링은 실무 시스템을 만들기 위해 스펙, 테스트, 보안, 검증, 운영까지 포함해 에이전트를 지휘하는 방식입니다.
Software 3.0은 코딩을 대체한다는 뜻인가요?
완전한 대체라기보다 코딩의 단위가 바뀐다는 뜻에 가깝습니다. 코드뿐 아니라 프롬프트, 문서, 컨텍스트, 테스트가 개발의 핵심 재료가 됩니다.
개발자는 무엇을 준비해야 하나요?
AI 도구 사용법만 익히는 것으로는 부족합니다. 요구사항을 명확히 쓰는 능력, 테스트를 설계하는 능력, 결과를 검증하는 능력, 에이전트가 이해하기 쉬운 문서를 만드는 능력을 함께 길러야 합니다.