"프롬프트-컨텍스트-하네스"의 각 단계와 "바이브 코딩-에이전트 루프"

 

 

현재 개발 업계의 가장 뜨거운 키워드인 바이브 코딩(Vibe Coding)은 단순히 '느낌대로 코딩한다'는 의미를 넘어, AI와의 협업 패러다임이 어떻게 성숙해왔는지를 보여주는 상징적인 현상이라고 할 수 있습니다.
이번 글에서는 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링의 세 단계의 발전 축 위에서 바이브 코딩이 어떻게 자리 잡고 있는지 생각해 보겠습니다.

바이브 코딩은 각 기술 단계의 장점을 흡수하며 발전해 왔습니다.

 

먼저 가장 처음 등장한 프롬프트 엔지니어링 단계부터 살펴보죠.

바이브 코딩에서 프롬프트 엔지니어링 단계의 의미는 "의도의 전달"이라고 할 수 있겠습니다.
초기의 바이브 코딩은 자연어가 코딩 언어가 되는 시기로, 이를테면 '말만 하면 코드가 나온다'는 환상에서 시작되었다고 보입니다.
개발자는 구체적인 로직 대신 "이런 느낌의 웹사이트를 만들어줘"라는 추상적인 'Vibe'를 던지고, LLM이 만들어내는 결과를 받아들이거나 다시 수정을 요청하는 형태입니다.
그런데 LLM이 전체 맥락을 몰라 엉뚱한 코드를 짜거나, 조금만 복잡해지면 수동으로 수정해야 하는 '노가다'가 발생했습니다.

 

그래서 다음 단계인 컨텍스트 엔지니어링 단계에서는 "공감대 형성"에 집중했다고 할 수 있습니다.
Cursor, Windsurf 같은 도구들이 등장하기 시작했고, 환각현상(Hallucination)을 극복하기 위해 주목받았던 RAG(Retrieval Augmented Generation, 검색 증강 생성) 기술이 코딩에 접목되었습니다.

LLM은 프로젝트의 전체 구조, 사용 중인 라이브러리, 과거의 코딩 스타일을 'Vibe'로 이해하기 시작했습니다.
컨텍스트(Context, 문맥)를 기반으로 이해하게 되면서 "저번처럼 API 연결해줘"라고만 해도 LLM이 기존 코드를 참고해 맥락에 맞는 코드를 생성할 수 있게 되었고 개발자는 상세 명세서를 쓸 필요 없이 LLM, 즉 AI와 컨텍스트를 공유하게 되었습니다.

그런데 컨텍스트 엔지니어링 단계에서의 바이브 코딩은 AI를 '말귀가 잘 통하는 동료'로 만들어 주었지만, "이해는 잘하지만, 책임은 지지 않는 상태"라는 결정적인 한계를 가지고 있었습니다.

 

특히 3가지의 한계가 중요합니다.

 

먼저 지식과 실행의 괴리를 들 수 있습니다.

알고는 있는데, 실행은 못한다는 겁니다.
컨텍스트 엔지니어링은 LLM, AI에게 '참고 자료'를 풍부하게 제공할 뿐, AI가 그 자료를 바탕으로 직접 무언가를 완결 짓는 능력은 보장하지 못했습니다.
"저번처럼 API 연결해줘"라고 하면 코드는 그럴듯하게 짜주지만, 그 코드가 실제 내 서버 환경에서 돌아가는지, 의존성 라이브러리가 충돌하지 않는지 AI는 알 길이 없었다는 문제입니다.
결국 AI가 짠 코드를 복사해서 내 에디터에 붙여넣고 에러가 나면, 결국 개발자가 다시 에러 메시지를 복사해서 AI에게 물어봐야 하는 '수동 피드백 루프'에 갇혀 있었습니다.

두 번째 한계는 어제는 됐는데 오늘은 안 된다는.. 비결정성의 늪에 빠지기 쉬웠다는 것입니다.
컨텍스트는 모델의 확률적 답변에 영향을 주는 요소일 뿐, 결과를 강제하는 '규칙(Constraint)'이 아니기 때문이죠.
프로젝트 전체 구조를 공유했음에도 불구하고, LLM의 특성상 기분에 따라(?) 혹은 확률적 계산에 따라 갑자기 엉뚱한 라이브러리를 쓰거나 기존 코딩 컨벤션을 무시하는 결과물을 내놓곤 합니다.

뭔가 문제가 발견되어 수정을 요청했을 때, 기존 코드의 수정이 아니라 코드를 통째로 바꿔버린다거나, 수시로 전혀 다른 방식의 코드를 내밀어서 전체 흐름을 뒤흔들어 놓거나 하는 일도 종종 발생했습니다.
결국 맥락을 공유했으니 믿고 맡겼는데, 결과물을 검토해보니 미묘하게 틀린 부분이 섞여 있거나 해서 '전수 검토'가 필수가 되어버린 것입니다.

수천 줄, 수만 줄의 코딩을 맡기기엔 신뢰도가 낮았던 것이죠.

세 번째 한계는 컨텍스트의 오염과 용량 제한 (Context Drift)이었습니다.
아무리 맥락을 잘 이해한다 해도, 프로젝트가 커지면 AI가 기억해야 할 정보가 너무 많아집니다.
프로젝트가 방대해지다보니 관련 없는 코드들까지 컨텍스트에 섞이면서(Noise), 정작 중요한 규칙을 잊어버리는 '컨텍스트 오염' 현상이 발생하게 된 것입니다.

또한, 토큰 제한 때문에 모든 맥락을 다 넣을 수도 없었죠.
그러다보니 "저번처럼 해줘"와 같은 명령은 시간이 지날수록 부정확해지며, 대규모 프로젝트를 통째로 관리하기에는 한계에 부딪힐 수 밖에 없었습니다.

 

결국 개발자들은 "AI에게 아무리 많은 정보를 줘봤자(Context), 스스로 잘했는지 확인할 시스템(Harness)이 없으면 인간의 일감은 줄어들지 않는다"는 것을 깨닫게 된 겁니다.

즉, "내 의도를 이해(Context)하는 것을 넘어, 결과물이 맞는지 기계적으로 증명(Harness)하고 틀렸으면 스스로 고쳐라(Agentic Loop)"라는 요구가 하네스 엔지니어링이라는 새로운 패러다임을 탄생시킨 것이라고 할 수 있겠습니다.

그래서 등장한 하네스 엔지니어링 단계가 바이브 코딩에서 가지는 의미는 "안전망과 자율성"이라고 할 수 있습니다.
AI가 짠 코드를 단순히 복사하는 게 아니라, 실행 환경(Sandbox)에 넣고 테스트와 린터를 돌려 스스로 수정하게 합니다.
개발자는 결과물을 일일이 검토하지 않습니다.

대신 AI에게 "테스트 통과할 때까지 고쳐놔"라고 던져두는 '결과 중심적 방임'이 가능해졌습니다.
느낌(Vibe)으로 시작하되, 하네스(Harness)라는 견고한 시스템 안에서 결과물을 걸러내는 방식이 된 것입니다.

 

 

바이브 코딩의 진화 과정(그림출처: : Gemini-Nano Banana 2 로 직접 그림)

 

 

그러면 하네스 엔지니어링과 바이브 코딩은 어떻게 연결되어 있을까?를 생각해 보죠.

현재의 최신 바이브 코딩 기법은 '인텐트(Intent) 🠢 실행(Action) 🠢 검증(Validation)'의 무한 루프를 타는 에이전틱 워크플로우(Agentic Workflow)와 맞닿아 있습니다.

그리고 '에이전틱 루프'는 에이전틱 워크플로우를 구성하는 요소의 하나로, 바이브 코딩이 작동하는 '엔진'이라고 할 수 있으며, '하네스 엔지니어링'은 그 엔진이 폭주하지 않도록 감싸는 '제어 장치'라고 볼 수 있습니다.

이전 단계인 프롬프트와 컨텍스트 엔지니어링 역시 버려지는 것이 아니라, 이 루프 안에서 더 고도화된 형태로 녹아들어 있습니다.

 

하네스의 핵심 메커니즘은 구조적 바이브(Intent & Plan), Self-Healing(Action & validation), 멀티 에이전트(Collaboration)의 세 가지 포인트로 볼 수 있으며, 바이브 코딩이 어떻게 '느낌'만으로 '실제 결과'를 만들어내는지 보여주고 있습니다.

 

• 구조적 바이브 (Intent & Plan)
  • 무턱대고 질문하는 것이 아니라, AI가 먼저 '구현 계획(Plan)'을 세우게 하고 인간은 그 '방향성(Vibe)'만 승인합니다.
  • 즉, 인간이 추상적인 'Vibe'를 던지면, 하네스 시스템은 이를 '아키텍처 제약'으로 변환하고, AI가 세운 계획이 이 제약 조건에 맞는지 확인하는 과정이 바로 인간의 '방향성 승인'입니다.
• Self-Healing (Action & validation)
  • AI가 코드를 짜고, AI의 실행(Action)이 하네스의 '결정론적 검증'에 걸려 에러가 나면, 하네스 시스템이 에러 로그를 다시 AI에게 던집니다.
  • 그리고 인간은 "고쳐봐"라는 짧은 피드백(Vibe)만 주면, '피드백 루프'가 가동되면서 AI가 내부적으로 수백 번의 수정을 반복하게 됩니다.
  • 이렇게 하네스는 기계적인 로그를 AI에게 주고, 인간은 정성적인 방향만 잡아주는 분업이 일어납니다.
• 멀티 에이전트 (Collaboration)
  • 프론트엔드 전문가 AI와 백엔드 전문가 AI가 서로 대화하며 시스템을 구축하고, 인간은 이들의 '매니저'로서 전체적인 톤앤매너만 관리합니다.
  • 여러 에이전트가 협업할 때, 각 에이전트가 서로에게 '하네스' 역할을 합니다.
  • 프론트엔드 AI가 짠 코드를 백엔드 AI가 자신의 API 규격(제약)에 맞는지 검증하는 식입니다.

 

그리고 기존의 프롬프트와 컨텍스트는 사라지는 것이 아니라 에이전트 루프 내부의 부품으로 사용됩니다.

 

• 프롬프트 엔지니어링 (Instruction)
  • 에이전트 루프의 연료로서 작동합니다.
  • 최신의 기법에서는 프롬프트를 사람이 직접 하나하나 작성하지 않습니다.
  • 에이전틱 루프 내에서는 '메타 프롬프트(Meta-prompting)' 기술이 사용되는데, 하네스 시스템이 에러 로그를 보고 AI에게 "이 에러를 고치기 위해 네 페르소나를 시스템 엔지니어로 바꾸고, 다음 가이드라인을 지켜서 수정해"라고 프롬프트를 자동으로 생성하여 주입하게 됩니다.
• 컨텍스트 엔지니어링
  • 에이전트 루프의 지도(Dynamic Knowledge)로서 역할을 수행합니다.
  • 단순히 문서를 다 넣어두는 수준을 넘어, 루프의 각 단계마다 필요한 정보만 실시간으로 교체합니다.
  • AI가 계획을 세울 때는 '아키텍처 문서'를 컨텍스트로 주고, 실제 코딩을 할 때는 '관련 라이브러리 API 문서'만 골라서 넣어주는데, 이를 '동적 컨텍스트 주입(Dynamic Context Injection)'이라고 하며, 루프가 길어져도 AI가 집중력을 잃지 않게 도와줍니다.

 

전체의 흐름을 정리하면 다음과 같이 정리할 수 있습니다.

 

1. 사용자가 '인텐트(Vibe)'를 던지면,
2. 에이전틱 워크플로우가 가동되어 전체 프로젝트의 단계를 나눕니다.
3. 각 단계 내에서 에이전트 루프가 돌아가며 결과물을 만들어내고,
4. 하네스가 이 루프의 결과물을 검증하여 다음 워크플로우 단계로 넘길지 결정합니다.

 

즉, "에이전트 루프는 에이전틱 워크플로우라는 큰 공장 안에서 돌아가는 개별 생산 라인"이라고 볼 수 있고, 하네스 엔지니어링은 이 생산 라인(루프)이 공장 전체의 품질 기준(워크플로우)을 맞추도록 관리하는 기술인 셈이죠.

 

 

지금의 최신 바이브 코딩은 "인간은 Vibe(의도와 승인)만 제공하고, 기술적인 고통(프롬프트 최적화, 컨텍스트 선별, 에러 수정)은 하네스 시스템과 에이전틱 루프가 전담하는 구조"입니다.
결국 프롬프트는 루프의 '입구'를 열고, 컨텍스트는 루프의 '경로'를 안내하며, 하네스는 루프가 '목적지'에 도달했음을 보증합니다.

에이전틱 워크플로우는 이 모든 기술이 톱니바퀴처럼 맞물려 돌아가는 최종적인 완성 형태라고 볼 수 있습니다.

 

결국 바이브 코딩은 개발자의 종말이 아니라 '창의적 설계자의 시대'를 의미합니다.

기술적 디테일은 AI와 하네스 시스템이 책임지고, 인간은 시스템의 '영혼(Vibe)'과 '목적'을 정의하는 데 집중하게 될 것입니다.