프롬프트, 컨텍스트, 하네스 엔지니어링
제대로 작동하는 AI와 시간을 낭비하게 하는 AI를 실제로 구분하는 요소
하네스를 바꿨더니 AI가 달라졌다 — LangChain이 증명한 것
올해 초, AI 커뮤니티에서 조용히 지나쳤지만 꽤 중요한 실험 결과 하나가 나왔다.
LangChain 팀이 자사 코딩 에이전트의 벤치마크 점수를 13.7점 올렸다. 꽤 큰 폭이다. 근데 흥미로운 건, 모델은 건드리지 않았다는 거다. 하네스만 바꿨다.
같은 AI, 같은 가중치. 시스템만 달라졌는데 Top 30 밖에서 Top 5로 진입했다.
이 이야기를 처음 들었을 때, "하네스가 뭔데요?"라는 질문이 자연스럽게 나온다면 오히려 잘 된 거다. 그 질문에서 오늘 이야기가 시작된다.
AI한테 말 거는 방법, 그게 다가 아니다
많은 사람들이 AI를 잘 쓰는 게 "프롬프트를 잘 쓰는 것"이라고 알고 있다. 틀린 말은 아니다. 근데 그게 전부는 아니더라고.
사실 AI를 제대로 다루려면 세 가지 레이어가 있다.
첫째는 프롬프트 엔지니어링. 말 그대로 모델에게 뭘, 어떻게 요청할지의 기술이다.
둘째는 컨텍스트 엔지니어링. 모델이 답하기 전에 어떤 정보를 보여줄지 설계하는 것이다.
셋째는 하네스 엔지니어링. 모델을 감싸는 시스템 전체를 만드는 것이다.
이 세 개를 같은 것으로 보는 사람이 많다. 그리고 그게 AI에서 계속 막히는 이유인 경우가 많다.
"더 잘 써봐야지" — 프롬프트의 한계
프롬프트 엔지니어링부터 시작하자. 이건 진짜로 중요하다.
좋은 프롬프트와 나쁜 프롬프트의 차이는 거의 항상 구체성에서 온다. "이 글 요약해줘"와 "이 글을 비기술 임원이 읽는 3문단 요약으로 정리해줘, 기술적 내용보다 비즈니스 영향 중심으로"는 완전히 다른 결과를 낸다.
여기에 역할 부여("시니어 카피라이터처럼 검토해줘"), 출력 형식 지정, 원하는 결과물 예시 제공까지 더하면 프롬프트 품질이 눈에 띄게 달라진다. 복잡한 문제에선 "단계적으로 생각해서 답해줘"라는 말 한마디가 정확도를 크게 높인다. 이걸 체인 오브 소트 프롬프팅이라고 부른다.
그런데 프롬프트 엔지니어링이 잘 안 먹히는 순간이 있다. 같은 작업을 수백 번 반복해야 할 때. 결과의 일관성이 중요할 때. 배경 정보가 사용자마다 다를 때. 그 순간부터는 프롬프트를 아무리 다듬어도 근본적인 한계가 있다.
다음 레이어로 가야 한다.
모델은 당신을 모른다 — 컨텍스트 엔지니어링
모델은 자신의 컨텍스트 윈도우 안에 있는 정보만 가지고 작업할 수 있다.
이 문장 하나가 엄청 많은 걸 설명한다.
AI는 당신 회사가 뭘 하는지 모른다. 당신 글쓰기 스타일도, 지난 달 결정도, 팀 문화도 모른다. 매번 새 세션은 백지다. 컨텍스트 엔지니어링은 그 백지를 전략적으로 채우는 기술이다.
비개발자에게 이건 생각보다 쉽다. 제안서 초안을 써달라고 하기 전에, 잘 됐던 제안서 2-3개를 붙여넣고, 회사 포지셔닝 한 단락을 더하고, 클라이언트 미팅 메모를 추가한다. 모델을 바꾼 게 아니다. 모델이 보는 것을 바꾼 거다. 품질 차이는 극적으로 달라진다.
개발자에겐 더 기술적인 이야기가 된다. 컨텍스트가 꽉 찰수록 모델의 추론 능력이 저하되는 '컨텍스트 로트(Context Rot)' 현상이 있다. 컨텍스트는 희소하고 소중한 자원이다. 그래서 컨텍스션 압축, 도구 출력 오프로딩, RAG 같은 기법들이 존재한다. 모두 "어떻게 하면 모델이 딱 필요한 정보만 보게 할까"에 대한 답이다.
실패 패턴은 두 방향이 있다. 컨텍스트가 너무 없으면 결과가 얕고 일반적이다. 너무 많으면 모델이 핵심을 잃는다. 좋은 컨텍스트는 양이 아니라 신호의 질이다.
시스템을 만드는 것 — 하네스 엔지니어링
다시 LangChain 이야기로 돌아가자.
가장 흔한 실패 패턴은 에이전트가 해결책을 작성하고, 자신의 코드를 다시 읽고, 괜찮아 보인다고 판단하고 멈추는 것이었다.
틀린 게 아니었다. 그냥 너무 일찍 만족했던 거다.
LangChain이 선택한 해결책은 더 좋은 모델이 아니었다.
PreCompletionChecklistMiddleware라는 걸 만들었다. 에이전트가 작업을 끝냈다고 선언하기 전에 강제로 원래 요구사항과 대조 검증을 하게 만드는 코드다. 모델이 스스로 잘 하길 기대하는 게 아니라, 시스템이 강제하는 거다.
이게 하네스 엔지니어링이다.
하네스는 모델 자체가 아닌 모든 코드, 설정, 실행 로직이다. 원시 모델 자체는 에이전트가 아니다. 하네스가 상태, 도구 실행, 피드백 루프, 강제 제약을 부여할 때 비로소 에이전트가 된다.
비개발자에게 하네스의 입문은 자동화 도구다. Zapier나 Make로 AI를 기존 업무 흐름에 연결하는 것. 새 이메일이 오면 AI가 분류하고 초안을 쓰고 사람이 검토해서 보낸다. 코드 없이 만드는 하네스다.
개발자에겐 진지한 엔지니어링이다. Manus는 프로덕션 준비가 되기까지 6개월과 5번의 전면 재설계가 필요했다. LangChain 팀은 LangGraph 실행 엔진을 위해 1년 이상 4가지 아키텍처를 거쳤다.데이터베이스나 OS 스케줄러를 짜는 것과 맞먹는 작업이다.
미들웨어는 루프의 각 단계 전후에 커스텀 로직을 실행하는 훅을 제공한다. 에이전트 시작 전: 메모리 로드, 입력값 검증. 모델 호출 전: 불필요한 히스토리 정리, 개인정보 필터링. 도구 실행 후: 출력 품질 확인. 이것들은 모델이 제공하는 기능이 아니다. 하네스가 제공하는 기능이다.
그럼 하네스 엔지니어링, 언제 필요한 걸까
프롬프트도 다듬었고, 컨텍스트도 잘 챙겼는데 여전히 뭔가 아쉽다면 — 이제 하네스를 봐야 할 때다.
이런 상황이 반복된다면 신호다.
매번 같은 작업을 처음부터 다시 한다
매번 같은 배경 설명을 붙여넣고, 같은 설정을 반복하고 있다면 자동화할 수 있는 하네스가 없다는 뜻이다. 한 번 잘 만든 하네스는 그 반복을 없애준다. 사람이 할 일은 검토와 판단만 남는다.
어떨 땐 잘 되고, 어떨 땐 엉망이다
결과가 들쑥날쑥하다면 프롬프트 문제가 아니다. 출력을 검증하고 일관성을 잡아주는 시스템이 없는 거다. LangChain이 만든 PreCompletionChecklistMiddleware처럼, 모델이 스스로 잘 하길 기대하는 대신 시스템이 강제하는 구조가 필요한 순간이다.
AI 작업이 두 단계 이상 연결되어야 한다
조사 → 초안 작성 → 검토 → 발송처럼 여러 단계가 이어진다면, 각 단계를 수동으로 연결하는 건 금방 한계가 온다. 중간에 사람이 계속 개입해야 하고, 한 단계에서 뭔가 잘못되면 전체가 흔들린다. 하네스는 그 연결을 자동으로 처리하고, 각 단계의 출력이 다음 단계의 입력으로 안전하게 넘어가도록 보장한다.
AI 결과를 고치는 데 시간이 더 걸린다
AI가 만든 결과물을 검토하고 수정하는 데 직접 하는 것보다 오래 걸린다면 — 출력을 검증하는 구조 자체가 없는 거다. 하네스는 결과물이 사용 가능한 수준인지 자동으로 확인하고, 기준에 미달하면 다시 시도하거나 사람에게 넘긴다. 사람의 시간은 진짜 판단이 필요한 곳에만 써야 한다.
혼자 움직이는 AI가 필요하다
사람이 매번 개입하지 않아도 AI가 스스로 판단하고 완료해야 하는 업무라면, 하네스 없이는 불가능하다. 자율적으로 작동하는 에이전트는 결국 잘 설계된 하네스 위에서만 가능하다. 모델의 지능이 아무리 높아도, 그걸 통제하고 방향을 잡아주는 시스템이 없으면 프로덕션에서 쓸 수가 없다.
한 줄로 요약하면 이렇다. AI를 한 번 쓰는 게 아니라 계속 믿고 맡겨야 하는 순간이 오면, 하네스 엔지니어링을 시작할 때다.
어느 레이어에 집중해야 하나
AI 제품의 경쟁 우위가 이동하고 있다. 모델 선택은 여전히 중요하지만, 사용 가능한 모델 간 격차는 좁아지고 있고 팀 간 하네스 품질 격차는 벌어지고 있다.
대부분의 AI 실망은 컨텍스트 문제다. 프롬프트 문제로 착각하면서 말을 계속 바꿔 쓴다.
대부분의 불일치는 하네스 문제다. 어떤 프롬프트로도 고쳐지지 않는다.
그리고 프롬프트를 계속 다듬으며 시간을 보내는 건, 발표 내용이 약한데 폰트만 바꾸고 있는 것과 비슷하다.
진짜 실력은 어느 레이어가 문제인지 진단하는 능력이다.
팀이 있을 때는 동료가 실수를 잡아줬다. 혼자 작업할 때는 하네스가 그 자리를 대신한다. 그게 LangChain 팀이 13.7점을 올린 방법이고, 그게 2026년에 AI를 잘 쓴다는 것의 진짜 의미다.