1. 하네스 엔지니어링과 토큰 분화
AI를 둘러싼 논의는 여전히 모델 성능 경쟁에 치우쳐 있다. 어느 모델이 더 똑똑한지, 누가 더 좋은 답변을 하는지, 누가 더 빨리 AGI에 도달할 것인지를 두고 시장의 시선이 쏘린다. 그러나 실제 업무 현장에서는 AI가 더 그럴듯한 문장을 쓰는지보다, 코드를 읽고, 로그를 해석하고, 도구를 호출하고, 실패를 수정하며, 끝내 업무를 완수하는지가 더 중요해지고 있다. 이것을 가능케 하는 것이 하네스 엔지니어링이다. 하네스 엔지니어링을 이해하기에 앞서 구조적인 토큰 사용량 증가의 원인을 먼저 이해해야한다. 토큰 소비가 모델이 더 많이 말하기 때문에 커지는 것이 아닌 사용량을 늘리고 소비량을 늘리는 주된 요인은 출력의 길이가 아니라 입력의 폭이다.
토큰 흐름을 해부하면 구조적으로 달라진 흐름이 드러난다. 웹쳇형(사용자가 질문을 덜지면 모델이 그 자리에서 답을 내놓은 1회성 혹은 단순 대화형 구조, 일반 소비자가 사용하는 ChatGPT, Gemini 웹 인터페이스 서비스)은 입력(55%), 출력(40%), 시스템(5%)이 전부지만 하네스형(모델을 단순히 실행한느 것이 아닌 특정 프레임워크 안에 가두어 모델 스스로 일하는 구조, Openclaw, AutogPT 등)은 사용자 입력 5%/모델 출력 15%/캐시 읽기 35%/파일, 로그 읽기 20%/툴 호출 결과 15%/시스템, 세션 10%로 분산된다. 즉 하네스형에서 비용의 약 80%는 모델이 생각하기 전, 후에 오가는 맥락(캐시, 파일, 툴, 시스템)에 쓰인다. 이것이 바로 KV cache, HBM 대역폭, 서빙 엔진이 차세데 인프라 병목으로 부상하는 구조적 이유이다.
*사용자 입력 (User Input): 사용자가 해결하고자 하는 문제나 질문을 텍스트로 전달하는 프롬프트 입력 과정
*모델 출력 (Model Output): 입력된 맥락을 바탕으로 추론하여 생성된 최종 결과물(텍스트, 코드 등)"
*캐시 읽기 (Cache Read): 이전 대화 내용이나 자주 쓰이는 지식을 매번 새로 계산하지 않고, 메모리(KV Cache)에서 미리 계산된 데이터를 불러오는 과정
*파일/로그 읽기 (File/Log Read): 모델이 답변을 생성하기 위해 로컬 문서, 소스 코드, 혹은 시스템 로그 등 외부 데이터 소스를 참조하는 과정
*툴 호출 결과 (Tool Call Results): 모델이 직접 해결할 수 없는 일(계산기, 웹 검색, API 실행 등)을 외부 도구에 맡기고 그 결과값을 받아오는 단계입니다.
*시스템 (System): 모델의 페르소나, 답변 규칙, 안전 가이드라인 등 AI의 행동 지침을 정의하는 기저 프롬프트
*세션 (Session): 현재 대화의 상태와 문맥 정보를 유지하기 위한 연결 고리 데이터
토큰 사용량 흐름이 변한 것을 보면 하네스 엔지니어링이 어떤 것인지 엿볼 수 있다. 하네스 엔지니어링의 정의는 에이전트가 실수를 할 때마다, 그 실수가 다시는 반복되지 않도록 솔루션을 엔지니어링하는 것을 말한다. 하네스는 영어로 마구, 즉, 고삐, 안장, 끈 등 말을 다룰 때 쓰는 도구 세트를 뜻한다. AI 모델의 강력한 능력을 제한하는 것이 아니라 구조화된 환경 안에서 의도된 방향으로 정확히 발휘되도록 설계하는 것이 하네스 엔지니어링의 본질이다. 2022년 ChatGPT 등장으로 구분되는 프롬프트 엔지니어링은 무엇을 물어볼 것인가, 2025년의 키워드인 컨텍스트 엔지니어링은 무엇을 보여줄 것인가를 질문한다면 2026년 2월에 등장한 하네스 엔지니어링은 어떻게 운용할 것인가를 질문한다.
2026년 2월, OpenAI가 발표한 '하네스 엔지니어링'은 AI가 스스로 소프트웨어를 만드는 시대의 새로운 표준을 제시한다. 여기서 '하네스(Harness)'란 말에게 씌우는 마구처럼, AI 에이전트가 길을 잃지 않고 효율적으로 일하게 만드는 '지능형 작업 틀'을 의미한다. OpenAI는 사람이 단 한 줄의 코드도 쓰지 않고 오직 AI(Codex)만으로 100만 줄의 코드를 생성해 실제 제품을 만드는 데 성공했다. 수작업보다 무려 10배나 빠른 이 성과를 가능하게 한 4대 핵심 기둥은 다음과 같다.
첫 번째 기둥은 '컨텍스트 설계'이다. AI에게 정보를 한꺼번에 너무 많이 주면 혼란에 빠지기 때문에, 약 100줄짜리 간결한 'AGENTS.md'를 목차로 삼아 전체 지도를 보여준다. 상세한 설계나 아키텍처 정보는 'docs/' 폴더에 분산 배치하여, AI가 필요할 때만 선택적으로 정보를 찾아 읽게 함으로써 기억력의 한계를 극복한다.
두 번째 기둥은 '결정론적 검증 자동화'이다. 테스트에 성공한 수천 줄의 결과를 모두 보여주면 AI는 정작 해야 할 작업의 맥락을 잃어버린다. 따라서 성공 시에는 침묵하고, 실패했을 때만 그 이유를 에이전트에게 상세히 알려주어 집중력을 유지시킨다. 또한 코드 간의 의존성 방향(Types → Config → Service → UI 등)을 린터와 테스트로 기계적으로 강제한다. AI가 설계 경계를 위반하면 CI 단계에서 즉시 차단하며, 실수가 발생할 때마다 새로운 제약을 추가해 시스템을 더욱 정교하게 강화한다.
세 번째 기둥은 '에이전트 간 코드 리뷰 루프(Ralph Wiggum Loop)'이다. 사람이 일일이 검토하는 대신 여러 대의 AI 에이전트가 서로를 감시하는 구조를 택한다. 한 에이전트가 코드를 올리면 다른 에이전트가 이를 검토하고, 피드백을 주고받으며 모든 리뷰어가 만족할 때까지 과정을 반복한다. 사람은 정말 중요한 최종 판단이 필요할 때만 개입한다.
마지막 네 번째 기둥은 '에이전트 가독성'이다. AI가 화면의 버그를 고칠 때 코드만 봐서는 한계가 있으므로, 웹 구조 데이터인 DOM 스냅샷과 실시간 스크린샷을 제공한다. AI에게 '눈'을 달아주어 실제 사용자 화면을 보면서 작업하게 만드는 환경을 구축한 것이다. 결과적으로 이 4기둥을 통해 5개월간 최소 인원으로 수작업 코드 0줄, 총 100만 줄의 코드를 완성하며 압도적인 생산성을 증명했다.
하네스 엔지니어링은 에이전트가 이해하기 쉬운 구조적 문서 설계, 실수를 구조적으로 제약하는 자동 검증, aI 상호 간의 자율적 코드 리뷰, 시각적 데이터 제공이 핵심 축이라 할 수 있다. 하네스 엔지니어링이 주는 가장 큰 철학적 통찰은 "AI 생성 코드의 신뢰성을 높이려면 AI의 자유도를 넓히는 것이 아니라 오히려 제한해야 한다"는 '제약의 역설'이다. 확률적이고 불확실한 AI의 출력을 결정론적인 기계적 규칙(린터, 자동 테스트 ...
