바이브 코딩이 막히는 건 모델이 아니라 지도다

코드를 더 못 받아서 막히는 게 아니다. 어디까지 바꾸고, 어디는 손대지 않으며, 무엇으로 끝났다고 볼지가 비어 있을 때 막힌다. 그 네 칸이 지도다.

1. 막힌 지점은 코드가 아니라 지도

세션은 돌아가고 패치도 나온다. 그런데 전송에 넣어야 할 것과 넣으면 안 되는 것이 한 묶음으로 섞이고, 표준을 건드렸는지 확장으로 남겼는지는 커밋 메시지에만 있다. 막힌 지점은 생성량이 아니다. 판정할 좌표가 없는 것이다.

Andrej Karpathy가 바이브 코딩을 말할 때 쓴 표현은 이 좌표를 전제로 하지 않는다. 그는 코드를 잊어도 된다고 했고(forget that the code even exists), 그 자리를 throwaway weekend project에 두었다. (Andrej Karpathy, X, 2025-02-02)

운영 레포에서 그 문장을 그대로 쓰면, 모델이 틀린 게 아니라 지도가 없는 상태로 주말을 재현하는 셈이 된다.

2. 바이브 코딩이 원래 가리킨 것

정의는 짧다. 2025년 2월 2일, Karpathy는 바이브 코딩을 코드를 만지지 않고 느낌으로 밀어 보는 작업으로 두었고, 그 자리를 throwaway weekend project에 놓았다. 그 정의 안에는 운영 이관, 권한, 하위 호환이 들어 있지 않다. (Andrej Karpathy, X, 2025-02-02)

GitHub은 이후 이 말을 둘로 갈라 놓는다. 코드를 거의 보지 않고 모델에 맡기는 full vibe와, 사람이 방향을 쥐고 모델을 쓰는 human-led. (GitHub, What Is Vibe Coding?)

운영 코드에서 필요한 쪽은 후자다. 전자를 운영에 가져오면 실패로 읽히기 쉽다. 실패의 원인은 모델 성능이 아니라, throwaway 전제를 운영 전제와 바꾼 데 있다.

스펙이 진실의 원천이라는 말은 여기서 나온다. Microsoft의 Spec-Driven Development는 산출물 품질을 스펙 품질에 묶는다. 의도, 제약, 수용 기준을 적고 Constitution에서 Validate로 돌린다. 스펙이 흐리면 출력도 흐리다. (Apoorv Gupta, Microsoft, Spec-Driven Development: A Spec-First Approach to AI-Native Engineering, 2026-06-10)

3. 왜 숙련자도 길을 잃나

익숙한 대형 레포를 다루는 숙련 개발자에게도, AI를 썼을 때의 체감과 측정은 어긋날 수 있다. METR이 2025년 7월 10일 공개한 연구에는 개발자 16명, 이슈 246건, Cursor와 Claude 3.5/3.7이 쓰였다. 측정된 작업 시간은 약 19% 늘었다. 참가자는 사전에 약 24% 빨라질 것으로 예상했고, 사후에도 약 20% 빨라졌다고 보았다. (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10)

이 글이 가져가는 주장은 하나다. 자기보고와 측정이 어긋날 수 있다는 것. “숙련자도 AI 때문에 느려진다”를 일반 법칙으로 쓰지 않는다.

같은 이유로, 이 19%를 2026년의 일반 사실로 단정하지 않는다. METR은 2026년 2월 24일, 이 수치가 2025년 초 도구·데이터 기준이며 이후 실험은 선택 편향으로 현재 효과를 단정하지 못한다고 밝혔다. 참가자 대화 기준으로는 지금이 더 빨라졌을 수 있다고 적었다. (METR, We are Changing our Developer Productivity Experiment Design, 2026-02-24)

체감이 지도를 대신하지 못한다. 빨라 보여도 범위 밖을 지웠는지, 금지한 인터페이스를 바꿨는지, 수용 기준을 통과했는지는 별개의 판정이다.

4. 지도의 네 칸

지도는 프롬프트 문장이 아니다. 스펙(의도), 범위, 금지, 판정이다.

Microsoft SDD가 적으라는 것은 의도와 제약과 수용 기준이다. Constitution을 정해 Validate로 확인한다. (Apoorv Gupta, Microsoft, Spec-Driven Development: A Spec-First Approach to AI-Native Engineering, 2026-06-10)

채팅 히스토리는 그 자리를 대신하지 못한다. 데이터넷에서 AWS 솔루션 아키텍트 하재영·김예진은 히스토리가 휘발된다고 보고, 그래서 SDD를 말한다. (하재영·김예진, 데이터넷, [기고] 바이브 코딩의 함정, 스펙 주도 개발로 해결한다)

전자신문 2026년 8월 12일 단상은 범위, 금지, 검증이 없는 지시를 문제로 짚는다. 모델에 “잘”을 붙이는 것과, 손대지 말 것과 끝난 상태를 적는 것은 다른 작업이다. (전자신문, [ET단상] 바이브 코딩 시대, 프롬프트 디자인은 정말 끝났을까?, 2026-08-12)

컨텍스트가 길다고 좌표가 생기지는 않는다. 컬리 기술블로그는 Lost in the Middle을 들어 작업 분해를 말한다. 한 세션에 시스템을 통째로 넣으면 중간이 빠진다. 네 칸을 잘게 나눈 뒤에야 모델이 그 칸을 채운다. (컬리 기술블로그, Claude Code를 활용한 예측 가능한 바이브 코딩 전략)

병목은 타수나 모델 선택이 아니다. 신규하는 진짜 병목을 기능 구현이 아니라 판정 기준으로 본다. (신규하, 바이브 코딩의 진짜 병목은 기능 구현이 아니라 판정 기준이다, 2026-05-04)

네 칸을 한 줄로 쓰면 이렇다.

• 스펙: 무엇을 바꾸려는가. 의도가 한 문장으로 남는가.
• 범위: 어느 오브젝트, 어느 모듈, 어느 인터페이스까지인가.
• 금지: 무엇을 생성·수정·삭제하지 않는가.
• 판정: 어떤 입력에 어떤 출력이면 통과인가. 누가 어떤 환경에서 확인하는가.

이 칸이 비어 있으면 숙련자도, 좋은 모델도, 긴 프롬프트도 같은 자리에서 멈춘다.

5. SAP 개발자의 지도

SAP가 다른 스택보다 어렵다는 통계는 이 글에 없다. 필요한 것은 운영에서 이미 알고 있는 항목을 지도 칸에 옮기는 일이다.

전송. 이번 변경이 들어가는 요청과 들어가지 말아야 할 요청. 시퀀스와 대상 시스템. 이걸 범위와 금지에 적지 않으면, 모델은 “관련된 것”을 한 전송에 넣는다.

권한. 누가 이 기능을 실행할 수 있어야 하고, 어떤 권한 오브젝트는 손대지 않는가. 권한을 코드 뒤에 숨기면 판정이 롤 테스트로 미뤄진다.

표준과 확장. 표준 수정을 허용하는지, 확장·BAdI·enhancement point로만 남기는지. 이 한 줄이 없으면 생성 코드는 가장 짧은 경로를 고르고, 그 경로는 대개 표준이다.

인터페이스 계약. BAPI와 RFC의 시그니처, 커밋 제어, 오류 반환. 계약 밖 필드나 우회 호출은 금지 칸에 명시한다. 모듈 경계도 같다. 호출 방향과 소유 모듈을 범위에 쓰지 않으면, 모델은 경계를 리팩터링으로 읽는다.

Joule for Developers와 ABAP MCP는 있다. (SAP Community, Our 2026 Roadmap for Joule for Developers ABAP AI capabilities) 도구가 네 칸을 대신 채우지는 않는다. 입력을 채우는 것은 개발자다.

6. 붙여넣을 지도 한 장

아래를 채운 뒤 세션 맨 위에 붙인다.

목표:
- 한 문장. 사용자/프로세스 기준으로 무엇이 달라지는가.

범위:
- 포함 오브젝트:
- 포함 모듈:
- 포함 인터페이스(BAPI/RFC/이벤트):
- 대상 전송:

금지:
- 표준 수정 여부:
- 손대지 않을 권한 오브젝트:
- 변경 금지 인터페이스·필드:
- 넘지 않을 모듈 경계:
- 이번 전송에 넣지 않을 것:

판정 (샘플 입출력):
- 입력 A → 출력 A':
- 입력 B (예외) → 출력 B':
- 권한: 허용 롤 / 거부 롤:
- 확인할 시스템:

완료 기준:
- 위 샘플이 통과하면 끝인가:
- 남은 수동 확인:
- 다음 전송/이관에 넘길 것:

모델에게 “잘 좀”을 추가하기 전에 빈 칸을 채운다. 빈 칸이 남아 있으면 그 칸은 모델이 추측하고, 추측은 운영에서 버그로 돌아온다.

지도를 채웠는가. 그다음 작업은 그 한 장을 붙인 뒤에 시작한다.