바이브 코딩에서 에이전틱 엔지니어링으로

Software 3.0: 프롬프트가 프로그램이다

세대	프로그래밍 방식
1.0	사람이 코드를 쓴다
2.0	데이터셋과 목적 함수로 신경망을 학습시킨다
3.0	맥락 창에 넣는 텍스트가 프로그램이고, LLM이 그것을 해석해 실행한다

에이전트에게 붙여 넣을 텍스트가 곧 배포물이다. 플랫폼마다 분기하며 비대해지는 설치 스크립트 대신 에이전트에게 줄 지시문을 배포하면, 에이전트가 환경을 보고 판단하고 루프 안에서 디버깅한다.
있어선 안 될 앱: 메뉴 사진을 OCR하고 항목별 이미지를 생성해 다시 그리는 앱을 만들 수 있지만, 3.0 방식은 사진을 이미지 모델에 주고 「메뉴 위에 그림을 얹어」라고 하면 끝이다. 중간의 앱 전체가 필요 없다. 기존 것을 빠르게 만드는 것보다 새로 가능해진 것을 봐야 한다.
자동화 대상은 코드가 아니라 정보 처리 전반이다. 예전 코드는 정형 데이터만 다뤘지만, 이제 문서 묶음을 다른 형태로 「재컴파일」해 위키를 만드는 일(LLM 위키)처럼 전에는 없던 것이 가능하다.
더 멀리 보면 신경망이 호스트 프로세스가 되고 CPU가 보조 프로세서가 되는 반전, 그 순간에만 맞는 UI를 렌더하는 「신경 컴퓨터」를 상상할 수 있다. 도구 사용은 결정적 작업을 위한 부속물로 남는다.

검증 가능성과 들쭉날쭉한 지능

전통 컴퓨터는 명세할 수 있는 것을, LLM은 검증할 수 있는 것을 쉽게 자동화한다. 프런티어 연구소가 검증 보상이 있는 거대한 강화학습(RL) 환경으로 모델을 훈련하기 때문이다.

들쭉날쭉함(jaggedness) 은 「검증 가능함 + 연구소가 신경 씀」의 조합에서 생긴다. 수학·코드처럼 검증할 수 있고 경제 가치가 커 환경이 많이 만들어진 곳에서는 솟고, 그 밖에서는 거칠다. 10만 줄 리팩터링이나 제로데이 발견은 하면서 50미터 앞 세차장에 차를 몰고 가야 하는지 걸어가야 하는지는 틀린다.
그래서 매뉴얼 없는 도구다. 내 응용이 RL 회로 안인지 밖인지 탐색해야 한다. 안이면 날고, 밖이면 고전한다. 밖이라면 직접 미세 조정을 고려하고, 들쭉날쭉한 동안에는 도구로 다루며 루프 안에 머문다.
거의 모든 것은 어느 정도 검증 가능하게 만들 수 있다(글쓰기도 LLM 심판단으로). 쉽고 어려움의 차이일 뿐이다. 연구소가 집중하지 않는 영역에서도 RL 환경이나 예시를 만들 수 있다면 그 레버는 그대로 유효하다.

바이브 코딩과 에이전틱 엔지니어링

	바이브 코딩	에이전틱 엔지니어링
목적	바닥을 올린다. 누구나 무엇이든 만든다	전문 소프트웨어의 품질 기준을 지키며 더 빨리 간다
책임	버릴 코드·시제품	취약점을 들이면 안 되고 책임도 그대로
핵심 기술	원하는 것을 말하기	오류 가능하고 확률적인 에이전트 여럿을 품질 희생 없이 조율하기

에이전틱 엔지니어링의 천장은 매우 높다. 잘하는 사람과 못하는 사람의 격차가 예전 「10배 엔지니어」보다 훨씬 크다.
2025년 12월 무렵부터 최신 모델로 덩어리 코드가 그냥 맞게 나오기 시작했다. 1년 전 챗봇 경험으로 판단하지 말고 다시 봐야 한다.
AI 네이티브 개발자의 차이는 도구의 모든 기능을 쓰고 자기 설정에 투자하는 데 있다. Vim·VS Code를 깊이 쓰던 것과 같다.
채용도 바뀐다. 퍼즐 문제 대신 큰 프로젝트(예: 에이전트용 SNS 클론을 안전하게 만들고 에이전트로 활동을 시뮬레이션)를 구현시키고, 강한 모델 에이전트 10개로 깨뜨려 보게 해 버티는지 본다.

바이브 코딩의 정의와 운영상의 숙취는 하네스 엔지니어링의 「바이브 코딩이라는 극단」에 있다.

사람이 맡는 것: 판단·취향·이해

에이전트는 인턴 같은 존재다. 사람은 미감·판단·취향·감독을 맡는다.

사람이 잡아야 하는 것	예
설계 판단	로그인 계정과 결제 계정의 이메일을 맞춰 크레딧을 연결하는 설계. 영속 사용자 ID 없이 서로 다를 수 있는 이메일로 연결한 오류다
명세	계획 모드보다 일반적인 방법은 에이전트와 함께 아주 상세한 명세를 설계하는 것이다. 사람은 상위 구조와 감독, 에이전트는 빈칸 채우기를 맡는다
근본 이해	`keepdim`과 `keep_dims`, `dim`과 `axis` 같은 API 세부는 잊어도 된다. 하지만 텐서와 뷰가 같은 저장소를 공유하는지 같은 근본 이해가 있어야 불필요한 메모리 복사를 막는다
미학	모델 코드는 비대하고 복붙이 많고 추상화가 부서지기 쉽다. 미학 보상이 RL에 없기 때문이다. 근본적 한계라기보다 아직 안 한 일이다

동물이 아니라 유령

LLM은 진화로 생긴 내재 동기·호기심으로 빚어진 동물 지능이 아니라, 데이터와 보상 함수로 빚어진 소환된 유령이다. 기질은 사전 학습(통계)이고 그 위에 RL이 덧붙는다. 소리친다고 더 잘하지도 못하지도 않는다. 정답 목록을 외우기보다 무엇인지에 대한 좋은 모델을 의심하며 시간을 들여 파악하는 태도가 잘 쓰는 법이다.

에이전트 네이티브 인프라

세상 대부분은 사람을 위해 쓰여 있어 다시 써야 한다.

문서가 「이 URL로 가서 이걸 눌러라」라고 사람에게 지시하는 것이 문제다. 에이전트에게 붙여 넣을 텍스트를 줘야 한다. 일을 센서·액추에이터로 분해하고, LLM이 읽기 쉬운 데이터 구조를 둔다.
시험 기준: 앱 코드보다 여러 서비스 설정·DNS 연결 같은 배포가 더 고생이다. 「이 앱 만들어」 프롬프트 하나로 손대지 않고 인터넷에 배포까지 되면 인프라가 에이전트 네이티브가 된 것이다.
사람과 조직을 대변하는 에이전트가 생기고, 「내 에이전트가 당신 에이전트와 얘기하게 할게」가 일상이 된다.

사고는 맡겨도 이해는 못 맡긴다

무엇을 왜 만들고 에이전트를 어떻게 지휘할지는 이해에 묶여 있고, 그래서 사람이 병목이 된다. LLM은 이해를 대신해 주지 못하니 좋은 지휘자가 되려면 이해가 필요하다. 반대로 LLM은 이해를 늘리는 도구가 된다. 같은 정보에 다른 투영을 줄 때마다 통찰이 생기므로, 읽은 것을 개인 위키로 쌓고 거기에 질문하는 방식이 이해를 키운다.

정리

Software 3.0에서는 맥락 창의 텍스트가 프로그램이다. 기존 앱을 빠르게 만들기보다 아예 필요 없어지는 앱을 본다.
LLM은 검증할 수 있는 것을 자동화한다. 내 일이 RL 회로 안인지 밖인지 먼저 탐색한다.
바이브 코딩은 바닥을, 에이전틱 엔지니어링은 품질 기준을 지키며 속도를 올린다.
설계 판단·명세·근본 이해·취향은 사람 몫이고, 이해는 외주할 수 없다.

버그 제보