바이브 코딩의 한계, '절차'로 넘는다

프롬프트 한 줄을 던지고 몇 분 뒤 받은 코드가 컴파일은 되지만 요구사항 절반을 놓치고, 시키지도 않은 추상화를 만들어내며, 기존 코드의 규칙을 조용히 깨뜨린다. 1인 개발자라면 익숙한 풍경이다. API 도구 기업 에이피매틱(APIMatic)의 메흐디 라자 자페리는 6월 23일 공개한 글에서 이 악순환의 진짜 원인이 모델 성능이 아니라 프롬프트를 감싸는 '절차'가 없기 때문이라고 진단했다.

무슨 일인가

그가 말하는 '바이브 코딩(Vibe Coding)'은 에이전트에게 프롬프트를 주고, 결과를 대충 훑은 뒤, 그럴듯하면 받아들이고 넘어가는 지금의 흔한 작업 방식이다. 문제는 그 코드가 실제 운영 코드베이스 안에서 살아야 하는 순간 드러난다. 에이전트는 모호한 부분을 전부 '추측'으로 채우고, 개발자는 그 추측의 결과를 고스란히 떠안는다. 그래서 다시 프롬프트를 고쳐 던지고, 또 고치다 보면 정작 결과물을 내놓기도 전에 컨텍스트 창이 바닥난다.

그가 제안하는 대안은 '에이전틱 엔지니어링(Agentic Engineering)'이다. 코딩 에이전트를 '유능하지만 곧이곧대로 일하는 동료'로 보고, 수십 년간 검증된 엔지니어링 규율 — 명확한 요구사항, 계획, 테스트, 검증, 리뷰 —을 그대로 유지하는 태도다. 타이핑은 에이전트가 더 많이 하되, 엔지니어링의 책임은 사람이 진다는 것이 핵심이다.

핵심 짚어보기

자페리가 매번 코딩 작업 전에 채워 넣는다는 '구조화된 코드 프롬프트' 템플릿은 일곱 가지 요소로 짜여 있다. ①능동태 한 문장으로 된 명령형 과제 정의("/users 엔드포인트에 페이지네이션을 추가하라"처럼 모호함이 없는 문장), ②그 작업을 하는 이유(의도), ③에이전트가 먼저 읽어야 할 파일·모듈·기존 패턴 지정, ④지켜야 할 제약(공개 API를 바꾸지 말 것, 새 의존성 금지 등), ⑤건드리면 안 되는 범위의 명시, ⑥테스트 작성 기대치, ⑦사람의 판단 없이도 확인 가능한 완료 기준이다. "잘 작동해야 한다"는 기준이 아니라 통과하는 테스트, 특정 응답값, 오류 없는 린트 실행처럼 기계적으로 검증 가능한 기준이어야 한다.

그가 든 예시는 구체적이다. 사용자 테이블이 50만 행을 넘겨 운영 환경에서 타임아웃이 나니, 사용자 목록 엔드포인트에 오프셋 기반 페이지네이션을 추가하되 기존 호출자가 영향받지 않도록 기본값을 1페이지·20건으로 둔다는 식이다. 의도와 제약, 완료 기준을 함께 적어야 에이전트가 엉뚱한 곳으로 새지 않는다.

1인기업 실전 적용 포인트

• 새 기능을 맡기기 전, 위 7개 항목을 메모장에 1~2분만 채워 보라. 특히 ⑤'건드리지 말 것'과 ⑦'완료 기준'을 빠뜨리면 에이전트가 선의로 과잉 작업을 한다.
• 완료 기준은 반드시 검증 명령으로 적어라. 예: "pytest 전체 통과", "목록 2페이지 호출 시 20건 반환". 사람 눈대중을 기준으로 두지 말 것.
• 작업 전 읽을 파일을 직접 지정해 에이전트가 코드베이스를 헤매며 토큰을 태우지 않게 하라(예: "db/helpers.py의 페이지네이션 헬퍼 패턴을 따르라").
• 프로토타입·일회성 스크립트는 바이브 코딩으로 빠르게, 오래 유지보수할 운영 코드는 절차를 갖춘 방식으로 — 두 모드를 의식적으로 구분해 쓰면 속도와 안정성을 모두 챙긴다.

전망 / 주의점

이 방식은 마법이 아니라 옛 소프트웨어 공학 습관의 복원에 가깝다. 프롬프트를 채우는 데 드는 몇 분이 부담스러워 보일 수 있지만, 재작업과 컨텍스트 초과로 날리는 시간에 비하면 싸다. 다만 모든 작업에 무거운 절차를 강요하면 오히려 생산성을 깎는다. 작업의 수명과 위험도에 따라 절차의 두께를 조절하는 판단이 1인 개발자에게 필요하다.

출처: APIMatic 블로그 (https://www.apimatic.io/blog/agentic-engineering-claude-code)