프롬프트에서 하네스로 — 바이브 코딩 4년의 변화

4년 사이에 AI를 쓰는 방식이 세 번 바뀌었습니다.

처음에는 질문을 잘하는 법을 배웠습니다. 그다음에는 무엇을 읽게 할지를 고민했습니다. 지금은 다른 곳에 시간을 쓰고 있습니다.

이 흐름을 정리해두면 지금 어디에 힘을 써야 하는지 판단하기 쉬워집니다.

1단계 · 프롬프트 엔지니어링 (2022~2024)

초점은 지시였습니다. 어떻게 물어보면 좋은 답이 나오는지를 찾는 일입니다.

"너는 전문 개발자다"로 역할을 지정하고, 예시를 두세 개 보여주고, "단계별로 생각해봐"를 붙이는 기법들이 이 시기에 정리됐습니다. 프롬프트 잘 쓰는 법을 모아놓은 자료가 쏟아졌습니다.

이 단계의 실패 모드는 일관성이 없다는 것이었습니다. 어제 잘 나온 방식으로 오늘 물으면 다른 답이 나옵니다. 같은 질문을 조금 다르게 썼는데 결과가 달라집니다. 그래서 "잘 물어보는 사람"이 실력처럼 보였습니다.

2단계 · 컨텍스트 엔지니어링 (2025)

초점이 지시에서 지식으로 옮겨갔습니다.

질문을 아무리 다듬어도 넘지 못하는 벽이 있다는 것이 분명해졌기 때문입니다. AI가 우리 코드베이스를 모르고, 우리 데이터 구조를 모르고, 왜 이렇게 설계했는지를 모르면, 질문이 완벽해도 결과가 맞을 수 없습니다.

그래서 무엇을 읽게 할지를 설계하기 시작했습니다. 코드베이스, 스펙 문서, 설계 결정 기록을 구조적으로 넣어주는 일입니다.

이 단계의 실패 모드가 특히 위험합니다. 잘못된 정보 위에서도 자신 있게 추론한다는 것입니다.

앞선 글에서 첫 시스템을 만들 때 화면만 만들어지고 뒷단이 비어 있었던 이야기를 썼습니다. 그것이 정확히 이 실패였습니다. 저는 질문을 잘못한 것이 아니었습니다. 우리 환경에 대한 정보를 주지 않았고, AI는 없는 정보를 채워서 그럴듯한 것을 만들었습니다. 그리고 자신 있게 내놓았습니다.

여기서 배운 것은 AI가 모른다고 말하지 않는다는 사실이었습니다. 모르면 채웁니다.

3단계 · 하네스 엔지니어링 (2026~)

초점이 다시 옮겨갔습니다. 이번에는 실행 환경입니다.

컨텍스트를 잘 갖추고 에이전트를 제대로 설계해놓아도, 그것이 여러 개가 되고 오래 돌아가기 시작하면 예상하지 못한 방식으로 실패합니다. 하나씩 볼 때는 잘 작동하는데 전체로 보면 무너지는 것입니다.

OpenAI Codex의 Ryan Lopopolo가 이렇게 말했다고 합니다.

"에이전트 자체는 어렵지 않다, 어려운 건 하네스다."

하네스는 마구(馬具)를 뜻합니다. 말이 힘을 낼 수 있게 붙여주는 장치입니다. 말 자체를 개선하는 것이 아니라 말이 일할 수 있는 구조를 만드는 것입니다.

여기서 설계하는 것은 이런 것들입니다.

• 도구 — AI가 무엇을 할 수 있게 할지. 파일을 읽는 것까지인지, 실행까지인지, 배포까지인지.
• 검증 — 결과가 맞는지 무엇으로 확인할지. 사람이 볼지, 자동으로 검사할지.
• 권한 — 어디까지 접근하게 할지. 읽기만인지, 쓰기도 되는지.
• 재시도 — 실패했을 때 어떻게 할지. 다시 시도할지, 멈추고 사람을 부를지.

이름을 몰랐지만 하고 있었습니다

이 개념을 알고 나서 지금 우리가 하고 있는 일을 다시 봤습니다.

팀에서 각자 도구를 만들기 시작하니 문제가 생겼습니다. 코드 스타일이 다르고, 데이터를 어디에 두는지 다르고, 만든 사람만 안을 압니다. 그래서 표준을 만들고, 코드 리뷰 절차를 넣고, 공용 저장소를 두고, 무엇이 만들어졌는지 등록하는 자리를 준비하고 있습니다.

그것이 하네스였습니다.

개념을 배워서 시작한 것이 아닙니다. 만드는 속도가 빨라지니 통제가 필요해졌고, 필요해서 만들다 보니 그게 하네스였습니다. 필요가 이름보다 먼저 왔습니다.

같은 이유로 만드는 층과 관리하는 층을 분리해서 보기로 했습니다. 만드는 일은 빠르게 가고, 관리하는 일은 다른 규칙으로 갑니다. 두 개를 같은 층에서 하려고 하면 속도를 죽이거나 통제를 놓칩니다.

대체가 아니라 포함입니다

한 가지 짚어야 할 것이 있습니다. 새 단계가 앞 단계를 대체하지 않습니다. 감싸 안습니다.

프롬프트 엔지니어링이 낡은 것이 되지 않았습니다. 여전히 질문을 잘해야 합니다. 컨텍스트가 낡은 것도 아닙니다. 오히려 하네스를 설계하려면 컨텍스트가 잘 갖춰져 있어야 합니다.

그래서 3단계에 있다는 것은 앞의 두 개를 안 해도 된다는 뜻이 아닙니다. 세 개를 다 해야 하는 상태라는 뜻입니다. 층이 하나 더 얹힌 것입니다.

그러면 지금 어디에 힘을 쓸 것인가

위치에 따라 다릅니다.

혼자 쓰기 시작한 단계라면 컨텍스트가 거의 전부입니다. 하네스는 아직 필요하지 않습니다. 관리할 것이 하나뿐인데 관리 체계를 만드는 것은 낭비입니다. 우리 환경을 AI에게 제대로 알려주는 데 시간을 쓰는 것이 낫습니다.

조직으로 퍼지기 시작했다면 하네스입니다. 만드는 사람이 여러 명이 되고 만들어진 것이 여러 개가 되는 순간부터, 개별 품질보다 전체 통제가 문제가 됩니다. 여기서 준비를 안 하면 나중에 정리하는 것 자체가 프로젝트가 됩니다.

제조업 IT 조직 대부분이 지금 이 경계에 있을 것이라고 봅니다. 개인 활용은 이미 퍼졌고, 부서별로 만들기 시작했고, 아직 관리 체계는 없는 상태입니다.

정리

4년 동안 초점이 지시에서 지식으로, 지식에서 환경으로 옮겨왔습니다.

공통점이 하나 있습니다. 매번 AI 자체가 아니라 AI 주변을 설계하는 일이 문제였다는 것입니다. 모델이 좋아지면서 해결된 것이 아니라, 오히려 모델이 좋아질수록 주변 설계가 결과를 갈랐습니다.

다음 글에서는 반대편을 보겠습니다. 이 방식의 위험이 무엇인지, 데이터로 확인된 것들을 정리하려 합니다. 지금까지 잘된 이야기를 주로 썼는데 그것만 보고 판단하면 안 되기 때문입니다.