프롬프트 엔지니어링의 시대는 끝났다? 에이전트를 제어하는 '하네스 엔지니어링'의 등장

AI 기술이 발전하면서 우리는 AI에게 단순히 질문을 던지는 것을 넘어, AI가 스스로 코드를 짜고 복잡한 업무를 수행하는 '에이전트(Agent)' 시대를 맞이하고 있습니다. 하지만 AI 에이전트가 똑똑해질수록 새로운 고민이 생깁니다. "어떻게 하면 이 강력한 AI가 내 의도대로, 실수 없이 끝까지 일을 완수하게 만들 수 있을까?"

이 질문에 대한 해답으로 최근 주목받는 개념이 바로 **하네스 엔지니어링(Harness Engineering)**입니다. 오늘은 프롬프트 엔지니어링의 한계를 짚어보고, 왜 우리가 하네스 엔지니어링으로 넘어가야 하는지, 그 핵심 철학과 적용 방법에 대해 알아보겠습니다.

 

참고로 블로그를 작성하면서 참고한 유튜브 영상을 공유합니다.

https://youtu.be/DrekqeDlO1w?si=LL1ShIJbF84UWamT

 

---

1. 프롬프트 엔지니어링의 한계와 두 가지 치명적 문제

지금까지 우리가 AI를 다루는 방식은 주로 다음과 같이 발전해 왔습니다.

• 프롬프트 엔지니어링(Prompt Engineering): AI에게 "말을 잘 거는" 기술. 어떻게 질문하느냐에 따라 더 나은 답을 얻어내는 과정.
• 컨텍스트 엔지니어링(Context Engineering): AI에게 프로젝트 상황이나 배경지식을 잘 알려주어 맥락에 맞는 결과물을 내도록 하는 것.

하지만 AI 에이전트에게 복잡하고 긴 프로젝트를 맡겼을 때, 단순히 '말을 잘하고 상황을 잘 설명하는 것'만으로는 한계에 부딪힙니다.

첫 번째 문제: 컨텍스트 부패 (Context Decay) Anthropic 연구팀이 자사의 최고 모델인 Claude Opus에게 'Claude.ai 클론 코딩'을 지시하는 실험을 했습니다. 결과는 어땠을까요? 절반만 구현하고 조기 종료를 선언해 버렸습니다. 작업이 길어질수록 AI의 컨텍스트 창이 꽉 차면서 앞선 지시나 맥락을 잊어버리는 '컨텍스트 소진' 현상이 발생한 것입니다.

두 번째 문제: 규칙과 울타리의 부재 AI에게 결제 시스템 구축을 맡겼더니 갑자기 중요한 DB 테이블을 통째로 삭제해 버리는 대참사가 일어났다고 가정해 봅시다. 이는 AI가 정보가 부족해서가 아닙니다. "이 행동은 절대 하면 안 돼!"라는 구조적 제약이 없었기 때문입니다. 프롬프트로 아무리 "DB는 건드리지 마"라고 '부탁'해도, 환각(Hallucination)이나 오류로 인해 언제든 규칙을 어길 수 있습니다.

---

2. 하네스 엔지니어링이란 무엇인가?

'하네스(Harness)'는 본래 야생마를 길들여 마차를 끌게 할 때 사용하는 마구를 뜻합니다. 하네스 엔지니어링은 에이전트(야생마)가 엉뚱한 곳으로 튀지 않고 올바르게 성능에 집중할 수 있도록, 마구(하네스)를 이용해 작업 환경을 제어하고 설계하는 것을 말합니다.

이는 AI 모델 자체를 뜯어고치는 것이 아닙니다. claude.md 파일, MCP(Model Context Protocol), 스킬, 훅(Hook) 등 에이전트가 일하는 전체 환경을 설계하는 것입니다.

• MCP + 스킬: AI가 쓸 수 있는 도구를 연결하고 행동 반경을 정해줍니다.
• 하네스 엔지니어링: 도구를 포함해 AI가 작업하는 전체 구조와 룰을 설계합니다.

하네스의 핵심 철학 프롬프트 엔지니어링이 AI에게 "이렇게 해줘"라고 **'부탁'**하는 것이라면, 하네스 엔지니어링은 AI가 규칙을 어길 수 없도록 **'강제'**하는 것입니다. 마치 공장의 안전 시스템처럼, 사람(또는 AI)의 판단에 의존하지 않고 시스템에 규칙을 내장하여 실수가 반복되지 않는 구조를 만듭니다.

---

3. 하네스는 문제를 어떻게 해결하는가?

앞서 언급한 두 가지 치명적인 문제를 하네스는 구조적으로 해결합니다.

• 컨텍스트 부패 해결 (CLAUDE.md의 활용): 새로운 세션이 시작될 때마다 AI의 기억은 리셋되지만, 작업 디렉토리에 있는 CLAUDE.md (또는 AGENT.md) 파일이 이를 잡아줍니다. 이는 마치 퇴사자가 바뀌어도 신규 입사자가 첫날 반드시 읽어야 하는 '불변의 온보딩 문서'와 같습니다. 컨텍스트가 꽉 차서 앞 내용을 잊어버려도, 이 핵심 지침 파일은 항상 그 자리에 있어 AI의 길잡이가 되어줍니다.
• 규칙과 울타리 문제 해결 (자동 강제 시스템): AI가 코드를 작성하고 저장하기 직전, '훅(Hook)' 코드가 자동으로 실행됩니다. 만약 치명적인 에러나 규칙 위반이 있다면 저장을 거부하고 에러 로그와 함께 AI에게 다시 돌려보냅니다. 사람은 개입하지 않습니다. AI가 스스로 에러를 읽고 수정합니다. "잘 짜줘"가 아니라, "규칙을 지키지 못하면 아예 다음 단계로 넘어갈 수 없는" 구조를 만드는 것입니다.

---

4. 실전 도입: 하네스의 3가지 기둥

성공적인 하네스 시스템을 구축하기 위해서는 다음 3가지 기둥이 필요합니다.

① 최소 컨텍스트 문서 (AGENT.md / CLAUDE.md) AI가 작업 시작 전 가장 먼저 읽는 지도입니다. 1000페이지짜리 매뉴얼이 되어서는 안 됩니다. 오늘 요리를 할 거라면 프라이팬, 냄비, 도마만 꺼내두어야지 온갖 공구를 다 올려놓으면 AI도 헷갈립니다.

• 원칙: 60줄 이하로 유지하며 항상 적용되는 핵심만 담습니다.
• 진화: 처음부터 완벽할 필요는 없습니다. 에이전트가 실패할 때마다 그 실패를 방지하는 규칙을 한 줄씩 추가해 나갑니다.

② 자동 강제 시스템 (Automated Enforcement) 규칙 위반을 시스템적으로 차단합니다.

• 린터(Linter): 코드의 맞춤법이나 룰 위반 시 자동으로 에러를 발생시킵니다.
• 프리커밋 훅(Pre-commit Hook): 코드 저장 전 "잠깐, 이것부터 확인해"라며 자동 검사를 수행합니다.
• 자동 교정 루프: 빨간 불이 켜지면 에이전트가 스스로 수정하는 자동화 루프를 구축합니다.

③ 가비지 컬렉션 (Garbage Collection) AI가 쏟아낸 불필요한 코드나 찌꺼기를 주기적으로 청소합니다. 예를 들어 '청소 에이전트'를 따로 두어, 실제 코드와 문서가 달라진 건 없는지, 안 쓰는 코드가 쌓였는지 주기적으로 검사하고 정리합니다.

이 세 가지 기둥이 맞물려 실패 ➔ 새 규칙 추가 ➔ 하네스 진화의 사이클을 거치며 시스템은 점점 더 정교해집니다. 실제 OpenAI의 사내 노코드 프로젝트에서도 AGENT.md(업무 지침서), CI 게이트(자동 테스트), 도구 경계 설정, 피드백 루프를 통해 개발자가 직접 코딩하지 않고도 훌륭한 결과물을 만들어낸 사례가 있습니다.

---

마무리: 감독으로 변모하는 개발자의 역할

프롬프트 엔지니어링의 시대에는 AI에게 어떻게든 일을 잘 시키는 것에 집중했다면, 하네스 엔지니어링의 시대에는 AI가 똑똑하게 뛰어놀 수 있는 튼튼한 경기장을 만드는 것에 집중해야 합니다.

AI 모델이 점점 더 똑똑해질수록 하네스의 구조는 역설적으로 더 단순해질 것이며, 언젠가는 에이전트가 스스로 하네스를 엔지니어링하는 날이 올지도 모릅니다.

확실한 것은 개발자의 역할이 근본적으로 바뀌고 있다는 점입니다. 코드를 직접 작성하며 그라운드를 뛰는 **'선수'**에서, 에이전트들이 올바르게 일할 수 있도록 환경과 규칙을 설계하는 **'감독'**으로 말입니다. 여러분의 프로젝트에는 지금 어떤 하네스가 채워져 있나요?