AI를 쓸수록 오히려 결과가 들쭉날쭉하다는 느낌, 받아보신 적 있으신가요?
어제는 보고서 톤이 딱 맞았는데, 오늘 같은 요청을 했더니 완전히 다른 문체로 돌아옵니다. 분명히 잘 쓴 프롬프트인데도 결과가 매번 다릅니다. AI를 많이 쓸수록 더 잘 쓸 수 있을 것 같았는데, 어딘가 불안정합니다.
이 문제를 해결하기 위해 2026년 초부터 업계에서 주목받기 시작한 개념이 있습니다. 바로 하네스 엔지니어링(Harness Engineering)입니다. 솔직히 말씀드리면, 이미 두 달 넘게 화제가 된 개념이라 소개 타이밍으로는 늦은 감이 있습니다. 그럼에도 지금 이 글을 쓰는 이유는 하나입니다. 아직 모르는 분이 훨씬 많고, 알면 지금 당장 써먹을 수 있기 때문입니다.
하네스(Harness)는 원래 말을 제어하는 마구(馬具)를 뜻합니다. AI에서의 하네스는 같은 의미입니다. 이미 충분히 강력한 AI를 바꾸는 것이 아니라, 그 AI가 일하는 환경을 설계하는 것입니다.
2026년 2월, HashiCorp 전 공동창업자 Mitchell Hashimoto가 자신의 블로그에 "Step 5: Engineer the Harness"라는 표현으로 이 개념에 이름을 붙였습니다. 며칠 후 OpenAI가 "Harness engineering: leveraging Codex in an agent-first world"를 발표하며 업계 전반으로 빠르게 확산됐습니다. 핵심 공식은 간단합니다.
Agent = Model + Harness
에이전트란 모델 그 자체가 아니라, 모델과 하네스의 합이다.
즉, 같은 Claude나 GPT를 쓰더라도 하네스를 어떻게 설계하느냐에 따라 결과물의 품질과 일관성이 완전히 달라집니다. 실제로 LangChain은 모델을 교체하지 않고 하네스만 개선해 AI 코딩 에이전트 벤치마크(Terminal Bench 2.0)에서 30위권에서 5위권으로 도약했습니다. 모델이 아니라 환경이 결과를 만든다는 증거입니다.
하네스 엔지니어링을 이해하려면 먼저 세 개념의 관계를 알아야 합니다. 이 셋은 순서대로 대체된 것이 아니라, 포함 관계입니다.
이 관계를 직관적으로 이해하기 위해 Atlan은 컴퓨터 구조에 빗대어 설명합니다. 모델은 CPU, 컨텍스트는 RAM, 하네스는 운영체제라는 비유입니다. 프롬프트 엔지니어링은 하네스의 한 구성 요소일 뿐이며, 하네스는 그 모두를 포함하는 더 큰 개념입니다.
하네스 엔지니어링의 전체 구현은 개발 지식이 필요합니다. 린터, CI 파이프라인, 구조 테스트, 멀티 에이전트 오케스트레이션 — 이런 것들은 개발자의 영역입니다.
그런데 글쓰기, 분석, 보고서 작성, 전략 수립처럼 지식노동자의 일상 업무에서는 컨텍스트 엔지니어링만으로도 체감 차이가 큽니다. Birgitta Böckeler가 Martin Fowler 블로그에 기고한 하네스 엔지니어링 가이드는 AI 에이전트가 일하는 환경 전체를 체계적으로 설계하는 것이 하네스 엔지니어링의 핵심이라고 설명합니다. 완전한 하네스 구현은 개발 지식이 필요하지만, 우선 컨텍스트를 구조적으로 관리하는 것부터 시작해도 충분한 효과를 얻을 수 있습니다.
중요한 것은 완벽한 하네스를 처음부터 구축하려다 시작도 못하는 상황을 피하는 것입니다. LangChain의 하네스 해부학 글에서도 강조합니다. "오늘날 하네스는 대부분 좋은 컨텍스트 엔지니어링을 위한 전달 메커니즘이다(Harnesses today are largely delivery mechanisms for good context engineering)." 즉 컨텍스트를 잘 관리하는 것이 하네스의 핵심입니다. 우선 여기서 시작하고, 필요하다면 심화 단계로 넘어가도 충분히 늦지 않습니다.
그렇다면 비개발자는 어떻게 컨텍스트 엔지니어링을 구현할 수 있을까요? 가장 접근하기 쉬운 방법이 구조화된 마크다운 파일 시스템입니다. 실제로 이 방법으로 Claude Cowork를 운영하고 있는 방식을 소개합니다.
AI와의 모든 업무에 공통으로 적용되는 지침입니다. 자주 바뀌지 않는 뼈대 정보를 담습니다. 파일을 목적별로 나누어 관리하면 필요한 부분만 선택적으로 불러올 수 있어 효율적입니다.
이 파일들은 새 세션을 시작할 때마다 학습시키는 기반이 됩니다. AI가 나를 알게 만드는 첫 번째 단계입니다.
블로그 작성, 영업 제안서, 회의록, HubSpot 코드 작업처럼 업무 유형별로 폴더를 나누고, 각각의 맥락 파일을 따로 관리합니다.
블로그 작업을 할 때는 블로그 폴더의 파일만 로드하고, 영업 작업을 할 때는 영업 폴더의 파일만 로드합니다. 필요한 맥락만 정확히 전달하는 것이 핵심입니다.
맥락 파일은 한 번 만들고 끝이 아닙니다. 상황이 바뀌면 파일도 바뀌어야 합니다. 단, 모든 것을 업데이트하지는 않습니다.
이 구분이 중요한 이유가 있습니다. 뼈대 정보까지 자주 바꾸면 AI가 나에 대한 일관된 모델을 가질 수 없습니다. 반대로 상황 정보를 업데이트하지 않으면 AI는 과거 맥락에서 벗어나지 못합니다.
파일을 만드는 것만으로는 부족합니다. 업무를 시작할 때마다 관련 파일을 먼저 학습시키는 루틴이 필요합니다. 광역 지침 파일과 해당 업무 전용 파일을 순서대로 불러온 다음 작업을 시작합니다. 처음에는 번거롭게 느껴질 수 있지만, 이 루틴이 쌓이면 AI와의 협업 품질이 눈에 띄게 달라집니다.
맥락 파일에 담아야 할 내용 중 가장 놓치기 쉬운 것이 있습니다. 바로 AI와 어떻게 일할 것인지에 대한 원칙입니다. 이것이 없으면 AI는 항상 기본값으로 작동합니다. 내가 원하는 방식이 아니라 AI가 학습한 일반적인 방식으로요.
예를 들어 이런 원칙들을 파일에 명시할 수 있습니다. "지시를 받으면 바로 실행하지 말고, 기존 계획과 충돌하는 부분이 있으면 먼저 짚어달라." "팩트와 예측을 반드시 구분해 달라. 불확실한 내용은 불확실하다고 명시해 달라." "보고서 공수를 과소 표현하지 말아 달라." 이런 원칙들이 파일로 존재하면, 새 세션을 열어도 AI는 같은 방식으로 협업합니다. 내가 매번 설명할 필요가 없어집니다.
이것이 단순한 프롬프트 엔지니어링과 다른 지점입니다. 프롬프트는 한 번의 대화를 위한 것이지만, 원칙 파일은 모든 대화에 걸쳐 일관된 협업 방식을 만드는 것입니다.
맥락 파일이 많아질수록 한 가지 문제가 생깁니다. AI에게 한꺼번에 너무 많은 파일을 학습시키면 토큰 소모가 늘어나고, 대화가 길어질수록 AI의 추론 능력이 저하될 수 있습니다. LangChain은 이를 '컨텍스트 부패(Context Rot)'라고 부릅니다. 컨텍스트 창이 채워질수록 AI가 초기 맥락을 잃어가는 현상입니다.
이를 관리하는 방법은 간단합니다.
하네스 엔지니어링은 거창한 개념입니다. 하지만 그 핵심에 있는 컨텍스트 엔지니어링은 마크다운 파일 하나로 시작할 수 있습니다. 오늘 당장 새 파일을 만들어 이렇게 적어보세요. 나는 어떤 사람인지, 어떤 업무를 하는지, AI와 어떻게 일하고 싶은지.
맥락 없이 AI를 쓰는 것은 매번 새로운 신입사원에게 일을 시키는 것과 같습니다. 아무리 뛰어난 신입이라도 나를 모르면 내가 원하는 결과를 주기 어렵습니다. 반면 나에 대해 잘 아는 AI는 같은 요청에도 일관되고 맥락에 맞는 결과를 냅니다.
완벽한 시스템을 만들려다 시작을 미루지 마세요. 지금 당장 파일 하나, 폴더 하나부터입니다. 필요하다면 그 다음 단계는 그때 고민해도 충분합니다.