하네스란 무엇인가

같은 AI, 다른 결과 — 차이는 구조에 있습니다

김은진 씨는 마케팅 팀에서 AI를 가장 먼저 도입한 사람이었습니다. 클로드(Claude)에게 월간 보고서 초안을 맡기자 처음 두 달은 쓸 만했습니다. 그런데 결과물이 매번 달랐습니다. 어떤 날은 회사 형식 가이드를 정확히 지켰고, 어떤 날은 무시했습니다. 지난번에 수정을 요청한 표현이 다음 보고서에서 또 나왔습니다. "분명 오늘은 잘 될 텐데"라는 기대가 매번 빗나갔습니다.

같은 팀의 박준호 씨는 달랐습니다. 그도 같은 클로드를 썼습니다. 그런데 결과물이 매번 일정했습니다. 형식도 맞고, 지난번 수정 사항도 반영되어 있었습니다. 금지 표현 목록도 지켰고, 분량도 정해진 범위 안에 들어왔습니다. 새로운 요청을 추가하면 다음 주부터는 알아서 반영됐습니다. 그의 AI는 사용할수록 더 잘 작동하는 것처럼 보였습니다.

김은진 씨가 물었습니다. "어떻게 한 거야?" 박준호 씨가 짧게 답했습니다. "환경을 만들어 줬어."

같은 AI, 다른 결과입니다. 차이는 AI의 성능이 아니라 AI가 작동하는 구조에 있었습니다. 챕터 1에서 저는 이 구조가 결과를 바꾼다고 말씀드렸습니다. 이제 그 구조에 이름을 붙이겠습니다. 그것이 하네스(Harness)입니다.

같은 AI, 다른 결과입니다. 차이는 성능이 아니라 구조에 있었습니다. 이제 그 구조에 이름을 붙이겠습니다.

제1장 · 저자

말의 마구에서 AI의 고삐로

하네스는 원래 말(馬)에 씌우는 마구(馬具)를 뜻합니다. 안장, 고삐, 가슴걸이를 묶어 만든 장비입니다. 말은 혼자 두면 방향을 잡지 못합니다. 하네스를 장착하면 말의 힘을 원하는 방향으로 이끌 수 있습니다. AI도 비슷합니다. AI 모델은 강력합니다. 그러나 방향이 없으면 힘이 분산됩니다. 하네스는 그 힘에 방향과 제약을 부여하는 환경입니다.

2026년 3월, 랭체인(LangChain) 팀은 이 개념을 한 문장으로 요약했습니다. "모델이 아닌 것은 전부 하네스다." 에이전트가 참조하는 지시 파일, 지켜야 할 규칙, 결과를 검증하는 구조, 대화 기록을 관리하는 방식 — 이 모두가 하네스입니다. AI 모델 자체만 빼면 나머지가 전부 하네스에 해당합니다.

이 비유에 비판적인 시각도 있습니다. 연구자 앤드루 메이너드(Andrew Maynard)는 2026년 2월 에세이에서 이렇게 지적했습니다. '하네스'라는 단어가 AI를 "힘은 세지만 스스로 방향을 정할 수 없는 존재"로 프레이밍한다는 것입니다. 통제하는 쪽이 설계를 주도하고, 통제받는 쪽은 발언권이 없습니다. AI 시스템이 점점 자율성을 갖춰 가는 지금, 이 관점이 적절한지 다시 생각할 필요가 있다는 논지였습니다.

비판은 타당합니다. 그러나 현시점에서 비개발자가 AI 에이전트를 실무에 안정적으로 쓰기 위한 틀로는 하네스가 가장 실용적인 개념입니다. 이 책은 그 실용적 의미에 집중합니다.

프롬프트에서 하네스까지 — 세 단계 진화

AI를 업무에 활용하는 방식은 세 단계를 거쳤습니다. 먼저 말씀드릴 것이 있습니다. 이 세 단계 구분은 이 책의 설명을 위한 틀입니다. 업계에서 확립된 표준 분류가 아니며, 원천 자료에 따라 관계 정의가 다를 수 있습니다.

1단계 — 프롬프트 엔지니어링(2023~2024)

"어떻게 질문하는가"의 시대입니다. 같은 AI에게 같은 내용을 물어도 질문 방식에 따라 결과가 달라진다는 사실이 알려졌습니다. "요약해 줘"보다 "3줄로 요약해 줘"가 낫고, "작성해 줘"보다 "마케터를 위한 500자 칼럼을 작성해 줘"가 낫습니다. 프롬프트는 지시입니다. 이 단계에서 AI 활용은 주로 일회성 대화였습니다. 한 번 묻고, 한 번 받고, 끝이었습니다.

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

질문뿐 아니라 맥락(컨텍스트)을 설계하는 시대입니다. AI에게 어떤 자료를 주느냐, 어떤 배경 정보를 포함하느냐가 결과를 결정합니다. 외부 문서를 검색해 AI에게 실시간으로 제공하는 기법, 외부 도구를 연결하는 방식이 이 단계의 핵심입니다. 컨텍스트는 배경입니다. 이 단계에서 AI는 단순한 질문 응답기를 넘어, 더 풍부한 정보를 바탕으로 일하는 보조자가 됐습니다.

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

AI가 독립적으로 작업을 수행하는 에이전트로 진화했습니다. 에이전트는 장시간 실행하고, 여러 도구를 사용하고, 결과를 다음 단계로 넘깁니다. 이 수준에서는 프롬프트와 컨텍스트만으로 충분하지 않습니다. 에이전트 전체가 작동하는 환경 — 제약, 검증, 피드백, 지속성 — 을 설계해야 합니다. 이것이 하네스 엔지니어링입니다. "AI에게 무엇을 하라"고 말하는 것을 넘어, "AI가 어떤 조건에서 어떻게 작동해야 하는가"를 설계하는 단계입니다.

관계 정의에 대해 한 가지 더 밝혀 두겠습니다. 랭체인 CEO 해리슨 체이스(Harrison Chase)는 "하네스 엔지니어링은 컨텍스트 엔지니어링의 확장"이라고 정의했습니다. 반면 이 책은 하네스를 컨텍스트를 포함하는 더 넓은 개념으로 다룹니다. 어느 관점이 맞는지는 아직 업계에서 정리되지 않았습니다. 이 책에서 하네스를 상위 개념으로 쓰는 이유는 하나입니다. 비개발자에게 가장 직관적이기 때문입니다.

핵심 공식 — 에이전트는 모델과 하네스의 합입니다

랭체인 팀은 2026년 3월에 하네스 개념을 공식화했습니다. "에이전트의 해부학(The Anatomy of an Agent Harness)"이라는 글에서였습니다. 핵심 정의는 이것입니다. "에이전트 = 모델 + 하네스(Agent = Model + Harness)." AI 에이전트는 모델 혼자가 아닙니다. 모델과 하네스의 합입니다.

이 공식을 업무에 적용하면 이렇게 바뀝니다. 실무 성과는 모델 성능 곱하기 하네스 품질에 가깝습니다. 모델이 아무리 좋아도 하네스가 없으면 결과가 불안정합니다. 같은 모델이라도 하네스를 개선하면 성과가 올라갑니다.

여기서 중요한 함의가 있습니다. 더 비싼 모델로 교체하는 것이 항상 최선은 아니라는 것입니다. 이 점을 앞서 소개한 랭체인의 실험이 보여 줬습니다. 하네스 최적화 없이 고성능 모델을 투입했을 때 성능이 기대에 미치지 못했습니다. 반대로 기존 모델에 하네스를 개선하자 성과가 크게 올라갔습니다. 모델 선택에 앞서 환경 설계가 먼저입니다.

더 비싼 모델로 교체하는 것이 항상 최선은 아닙니다. 모델 선택에 앞서 환경 설계가 먼저입니다.

제4장 · 저자

오픈AI 코덱스 팀의 100만 줄 실험

오픈AI(OpenAI) 코딩 에이전트 팀은 2026년 2월, 실제 업무에 5개월간 코딩 에이전트를 투입한 결과를 공개했습니다. 수치가 구체적입니다. 엔지니어를 3명에서 7명으로 늘리는 동안, 사람이 직접 작성한 코드는 0줄이었습니다. 에이전트가 약 100만 줄의 코드를 생성했고, 약 1,500건의 작업 단위(코드 변경 요청)가 처리됐습니다.

초기에는 생산성이 낮았습니다. 에이전트가 자주 실수했고, 결과물의 일관성도 부족했습니다. 그러나 시간이 지나면서 성과가 폭발적으로 향상됐습니다. 무엇이 바뀌었겠습니까. AI 모델은 바뀌지 않았습니다. 바뀐 것은 환경이었습니다.

보고서의 핵심 문장은 이것입니다. "초기 생산성이 낮았던 이유는 모델 능력 부족이 아니라 환경이 부족했기 때문이다." 이 팀은 에이전트가 실패했을 때 "더 분발하라"고 요구하지 않았습니다. 대신 물었습니다. "어떤 환경 요소가 빠져 있는가? 그것을 에이전트가 읽고 따를 수 있도록 어떻게 만들 것인가?"

오픈AI 팀이 발견한 또 하나의 교훈입니다. "지도를 줘라, 1,000페이지 매뉴얼을 주지 마라." 에이전트에게 모든 규칙을 한꺼번에 주려 하면 오히려 성능이 떨어집니다. 핵심 지도만 주고, 나머지는 필요할 때 찾게 하는 구조가 효과적이었습니다.

신입에게 회사 규정집 전권을 넘기며 "알아서 해"라고 하는 것과, 핵심 업무 흐름만 담은 한 장짜리 안내서를 주는 것의 차이입니다.

이것이 하네스 설계의 출발점입니다. AI에게 더 열심히 하라고 요구하는 것이 아니라, AI가 제대로 작동할 수 있는 환경을 만드는 것입니다. 처음에는 그 환경을 만드는 데 시간이 걸립니다. 그러나 한 번 만들어 두면, 이후에는 그 시간이 돌아옵니다.

하시모토의 원칙 — 실수는 규칙이 됩니다

해시코프(HashiCorp) 공동창립자 미첼 하시모토(Mitchell Hashimoto)의 이야기입니다. 그는 2026년 2월, 자신의 AI 활용 여정을 6단계로 정리한 글을 발표했습니다. 그중 5단계가 "하네스 엔지니어링"이었습니다. 그 전 단계들은 AI를 조심스럽게 써 보고, 반복 작업을 위임해 보는 과정이었습니다.

5단계의 핵심 원칙은 이것입니다. "에이전트가 실수하면, 그 실수가 다시는 발생하지 않도록 엔지니어링하라."

하시모토가 관리하는 오픈소스 프로젝트 고스티(Ghostty)에는 에이전트용 업무 매뉴얼이 있습니다. AGENTS.md라는 에이전트 전용 지시 파일입니다. 그 문서의 각 줄은 과거에 에이전트가 저지른 실수를 방지하는 규칙입니다. 에이전트가 실수할 때마다 규칙이 추가됐습니다. 이 문서는 지금도 계속 늘어나고 있습니다.

이 원칙은 관점의 전환을 요구합니다. AI가 엉뚱한 답을 냈을 때 "AI가 문제다"가 아니라 "내 환경에 규칙이 없었다"고 보는 것입니다. 그 전환이 하네스 엔지니어링의 시작입니다. 실수는 불운이 아닙니다. 환경을 개선할 기회입니다. 하네스는 실수를 쌓아 만드는 구조입니다.

실수는 불운이 아닙니다. 환경을 개선할 기회입니다. 하네스는 실수를 쌓아 만드는 구조입니다.

제6장 · 저자

복리 효과 — 하네스는 쌓입니다

하네스의 가장 강력한 특성은 누적입니다. 하시모토는 이것을 "복리(Compounding)"라고 표현했습니다. 하네스를 세션마다 조금씩 개선하면, 그 개선이 이후 모든 세션에 적용됩니다. 오늘 추가한 규칙 하나가 내일, 다음 달, 6개월 뒤에도 에이전트의 실수를 막습니다.

프롬프트는 누적되지 않습니다. "꼼꼼하게 해 줘"를 1,000번 입력해도 다음 대화에서는 처음부터 다시 시작입니다. 하네스는 다릅니다. 한 번 만든 지시 파일, 검증 규칙, 진행 파일은 계속 남아 작동합니다.

1주일에 규칙 3개를 추가한다고 해 보겠습니다. 한 달이면 12개, 석 달이면 36개의 실수 방지 규칙이 쌓입니다. 같은 AI로 시작해도 3개월 후의 하네스는 처음과 전혀 다른 수준의 결과를 냅니다. 초기 투자는 작습니다. 효과는 기하급수적으로 커집니다.

단, 하시모토 본인은 이 과정을 신중하게 표현했습니다. "생산성이 몇 배 높아졌다"는 식으로 단정하지 않고, "성공적인 경험을 하고 있다"고 했습니다. 복리의 방향은 명확합니다. 하네스를 쌓는 사람과 매번 프롬프트를 새로 짜는 사람 사이의 격차는 시간이 갈수록 벌어집니다. 처음에는 티가 나지 않습니다. 그러나 6개월 후, 하나는 점점 잘 작동하는 시스템이 되고 하나는 여전히 매번 처음부터 시작합니다.

개발자의 하네스, 비개발자의 하네스

지금까지의 사례는 전부 코드 작성 영역이었습니다. 코드 변경 요청(PR), 에이전트 전용 지시 파일(AGENTS.md) — 모두 소프트웨어 개발 맥락입니다. "나는 코드를 전혀 모르는데, 이게 나와 무슨 상관인가?"라는 의문이 생길 수 있습니다.

개발자와 비개발자가 하는 일은 다릅니다. 하지만 하네스의 구조는 직업과 무관하게 같습니다. 다음 표가 이를 보여 줍니다.

표의 왼쪽과 오른쪽은 쓰는 도구가 다릅니다. 그러나 각 행이 해결하는 문제는 같습니다. 원리는 같습니다. 도구와 방법이 다를 뿐입니다. 핵심 질문은 이것입니다. "AI를 반복적으로 쓰는 업무가 있는가?" 글을 쓰는 사람, 고객 메일을 처리하는 사람, 보고서를 만드는 사람, 데이터를 정리하는 사람 — 반복 구조가 있다면, 하네스가 작동합니다.

핵심 질문은 이것입니다. "AI를 반복적으로 쓰는 업무가 있는가?" 반복 구조가 있다면, 하네스가 작동합니다.

제8장 · 저자

왜 비개발자에게 중요한가

비개발자의 하네스는 코드가 아닙니다. 코드 한 줄 없이도 만들 수 있습니다. 지시 파일, 규칙 체크리스트, 검증 루프, 컨텍스트 관리 방법으로 구성됩니다. 이 네 가지가 챕터 3에서 공식 선언되고, 챕터 4~7에서 각각 상세히 다뤄집니다. 챕터 3을 읽고 나면 "내가 지금 당장 만들 수 있는 하네스"가 무엇인지 윤곽이 잡힙니다.

하네스가 없는 상태와 있는 상태의 차이는 시간이 지날수록 선명해집니다. 처음 한 달은 큰 차이가 없습니다. 그러나 3개월, 6개월이 지나면 달라집니다. 규칙이 쌓이고, 진행 파일이 채워지고, 검증 루프가 자리를 잡습니다. AI를 쓰는 방식이 점점 자신의 업무에 맞게 최적화됩니다.

챕터 1에서 랭체인이 모델은 그대로 두고 환경만 바꿔 30위권에서 5위권으로 올라갔다고 말씀드렸습니다. 그 실험의 핵심 교훈을 비개발자 맥락으로 바꾸면 이렇습니다. 더 비싼 AI 구독을 결제하기 전에, 지금 쓰는 AI의 환경을 먼저 만드십시오. AI를 탓하기 전에, AI가 작동하는 구조를 먼저 살피십시오.

지금 AI를 쓰면서 "왜 이렇게 들쑥날쑥하지?"라는 의문이 생긴다면, 그것은 AI가 문제가 아닙니다. 하네스가 없는 것입니다. 하네스를 만들면, 같은 AI가 다른 결과를 냅니다. 박준호 씨처럼.