에이전트 하네스 엔지니어링, 모델보다 중요한 것은 작업 환경

한눈에 보기

• 원문 성격: 2026년 4월 19일 애디 오스마니가 쓴 AI 에이전트 운영 설계 글
• 핵심 메시지: 좋은 에이전트는 좋은 모델만으로 만들어지지 않고 모델을 둘러싼 하네스에서 완성
• 의미 번역: 하네스는 지시문, 도구, 맥락 관리, 안전장치, 로그, 평가, 재시도 흐름을 묶은 운영 장치
• 중요한 관점: 에이전트의 실수는 웃고 넘길 사건이 아니라 다음 버전의 규칙으로 남겨야 할 신호
• 서비스 의미: 앞으로 경쟁력은 모델 호출보다 하네스 API, 도구 실행 환경, 검증 루프에서 생길 가능성
• 우리에게 남는 질문: 더 큰 모델을 기다릴 것인가, 아니면 오늘의 실패를 줄이는 실행 환경을 고칠 것인가

서론

AI 에이전트가 일을 망쳤을 때 우리는 거의 자동으로 모델을 탓한다. “아직 모델이 부족하다”, “다음 버전이 나오면 괜찮아질 것이다”, “더 비싼 모델을 쓰면 해결될 것이다” 같은 말이 나온다. 아주 틀린 말은 아니다. 모델 성능은 당연히 중요하다.

그런데 애디 오스마니가 2026년 4월 19일 공개한 Agent Harness Engineering은 시선을 살짝 옆으로 돌린다. 모델만 보지 말고, 모델이 실제로 일하는 작업장 전체를 보자는 이야기다.

오스마니가 말하는 하네스 엔지니어링은 거창한 유행어라기보다 현실적인 태도에 가깝다. AI 에이전트가 반복해서 같은 실수를 한다면, 그 실수를 다음 실행에서 막도록 지시문, 도구, 권한, 평가, 로그, 재시도 흐름을 고친다. 실패를 기억이 아니라 구조로 남기는 일이다.

이 글은 원문을 문장별로 길게 옮기기보다, 핵심 의미를 한국어 독자가 이해하기 쉬운 흐름으로 다시 구성했다. 중요한 질문은 하나다. AI 에이전트 시대에 진짜 제품은 모델인가, 아니면 모델을 일하게 만드는 운영 장치인가.

1. 원문을 한 문장으로 옮기면

오스마니의 글을 한 문장으로 줄이면 이렇게 말할 수 있다.

코딩 에이전트는 모델에 하네스를 더한 것이며, 실제 신뢰성은 그 하네스를 얼마나 잘 설계하느냐에서 나온다.

여기서 하네스는 말 그대로 에이전트를 붙잡고, 안내하고, 멈추고, 다시 시도하게 만드는 장치다. 자동차 엔진만 있다고 차가 안전하게 달리지 않는 것처럼, AI 모델만 있다고 에이전트가 제대로 일하지 않는다. 엔진 주변에는 핸들, 브레이크, 계기판, 안전벨트, 정비 기록이 필요하다.

AI 에이전트의 세계에서는 그 역할을 다음 요소들이 맡는다.

• 지시문: 에이전트가 따라야 할 원칙과 금지 사항
• 도구: 파일 읽기, 명령 실행, 브라우저 확인, 검색, 배포 같은 행동 수단
• 맥락 관리: 지금 작업에 필요한 정보만 골라 넣는 방식
• 안전장치: 위험한 명령이나 되돌리기 어려운 변경을 막는 장치
• 평가와 재현: 결과가 좋아졌는지 다시 확인할 수 있는 테스트와 기록
• 관찰 가능성: 비용, 시간, 실패 지점, 로그를 추적하는 체계

오스마니가 강조하는 지점은 단순하다. 같은 모델을 써도 하네스가 다르면 완전히 다른 제품처럼 보일 수 있다. Claude Code, Cursor, Codex, Aider, Cline 같은 도구가 모두 비슷한 모델 계열을 쓸 수 있지만, 사용자가 느끼는 품질은 모델 이름보다 그 도구가 제공하는 작업 흐름과 안전장치에 크게 좌우된다.

AI 에이전트의 품질은 모델 성능과 하네스 설계가 함께 만든다

2. 하네스는 프롬프트보다 넓은 개념이다

많은 사람이 AI를 잘 쓰는 방법을 프롬프트를 잘 쓰는 법으로 이해한다. 물론 프롬프트는 중요하다. 하지만 하네스 엔지니어링은 그보다 넓다.

프롬프트가 말로 지시하는 일이라면, 하네스는 시스템이 행동을 강제하게 만드는 일이다. “위험한 명령을 실행하지 마”라고 말하는 것과, 위험한 명령이 들어오면 실행 전에 차단하는 것은 다르다. “테스트를 꼭 돌려”라고 부탁하는 것과, 파일이 바뀔 때마다 테스트 실패를 에이전트에게 되돌려 보내는 것도 다르다.

오스마니가 든 예시는 현실적이다. 에이전트가 프로젝트 규칙을 몰라서 잘못 고쳤다면 규칙 파일에 넣는다. 파괴적인 명령을 실행했다면 그 명령을 막는 장치를 둔다. 긴 작업에서 길을 잃는다면 계획자와 실행자를 나눈다. 깨진 코드를 다 끝났다고 주장한다면 타입 검사나 테스트 결과를 작업 루프 안으로 다시 넣는다.

이 차이가 중요하다. 프롬프트는 에이전트가 기억해 주기를 바라는 장치다. 하네스는 에이전트가 잊어도 시스템이 붙잡아 주는 장치다.

그래서 하네스 엔지니어링은 “말을 예쁘게 쓰는 기술”이 아니다. 오히려 작은 운영 체계를 만드는 일에 가깝다. 에이전트가 어떤 파일을 읽고, 어떤 도구를 쓰고, 어디까지 자동으로 실행하고, 어떤 순간 사람에게 멈춰야 하는지 정하는 설계다.

3. 실수는 다음 버전의 규칙이 되어야 한다

원문에서 가장 실용적인 대목은 실수 래칫에 가깝다. 래칫은 한 방향으로만 움직이게 만드는 장치다. 하네스 엔지니어링에서 이 말은 에이전트가 한 번 저지른 실수가 다음 실행에서 다시 나오지 않도록 구조를 조이는 습관을 뜻한다.

예를 들어 에이전트가 테스트를 주석 처리한 채로 pull request를 만들었다고 해 보자. 나쁜 대응은 “다음엔 조심해”라고 말하고 넘어가는 것이다. 좋은 대응은 그 실수를 하네스에 새긴다.

• 규칙 추가: 테스트를 주석 처리하지 말고 고치거나 삭제
• 검사 추가: 변경분에서 건너뛰는 테스트나 비활성 테스트 패턴 탐지
• 리뷰 기준 추가: 리뷰 에이전트가 해당 패턴을 막는 이슈로 표시
• 재현 사례 추가: 같은 문제가 다시 나오는지 확인하는 평가 항목으로 보존

이렇게 하면 실패는 단순한 사고가 아니라 시스템의 학습 자료가 된다. 물론 무작정 규칙을 늘리면 안 된다. 규칙이 너무 많으면 에이전트도 사람도 중요한 것을 놓친다. 오스마니는 좋은 규칙이 실제 실패 이력에 연결돼야 한다고 본다. “언젠가 필요할 것 같아서”가 아니라 “이 문제가 실제로 터졌기 때문에” 넣는 방식이다.

이 관점은 AI 도구를 쓰는 개인에게도 꽤 유용하다. 에이전트가 자꾸 같은 실수를 한다면 모델을 바꾸기 전에 먼저 물어볼 수 있다. 그 실수를 막는 규칙이 있는가. 그 규칙을 확인하는 도구가 있는가. 실패 로그가 다음 실행으로 이어지는가.

하네스가 좋아지는 순간은 실패를 다시 실행 가능한 규칙으로 바꿀 때다

4. 모델을 바꾸기 전에 작업장을 바꿔야 한다

AI 논쟁은 종종 모델 비교로 흘러간다. 어떤 모델이 더 똑똑한지, 어떤 모델이 코드를 더 잘 쓰는지, 어떤 모델이 환각을 덜 일으키는지 비교한다. 이 비교는 필요하다. 하지만 그것만으로는 부족하다.

오스마니의 핵심은 지금 우리가 보는 성능 차이 중 상당수가 모델 격차가 아니라 하네스 격차일 수 있다는 점이다. 같은 모델이라도 더 좋은 도구, 더 선명한 지시문, 더 빠른 피드백, 더 안전한 실행 환경을 만나면 훨씬 나은 결과를 낼 수 있다.

쉽게 말해, 뛰어난 요리사에게 불안정한 조리대와 무딘 칼만 주면 결과가 흔들린다. 반대로 보통 수준의 요리사라도 좋은 주방, 정리된 재료, 명확한 주문서, 중간 점검이 있으면 훨씬 안정적인 결과를 낼 수 있다.

AI 에이전트도 비슷하다. 모델이 똑똑해지는 속도만 기다리는 전략은 편하지만 수동적이다. 하네스를 손보는 전략은 번거롭지만 즉시 효과를 낼 수 있다.

• 모델 교체: 성능이 오를 수 있지만 실패 원인이 그대로 남을 수 있음
• 하네스 개선: 반복 실패를 줄이고 작업 결과를 더 잘 확인할 수 있음
• 둘의 조합: 좋은 모델이 좋은 하네스 안에서 가장 큰 효과

이 지점에서 하네스 엔지니어링은 일종의 현실주의다. “언젠가 완벽한 모델이 나오면 해결된다”가 아니라, “오늘 이 에이전트가 왜 실패했는지 보고 작업 환경을 고친다”에 가깝다.

5. 맥락은 많이 넣을수록 좋은 것이 아니다

AI 에이전트를 쓰다 보면 모든 정보를 한 번에 넣고 싶어진다. 전체 문서, 전체 로그, 전체 회의록, 전체 코드 맥락을 다 주면 더 잘할 것처럼 보인다. 하지만 원문은 이 생각을 경계한다.

오스마니는 맥락 부패라는 표현을 다룬다. 맥락 창이 길어질수록 모델의 추론과 작업 지속력이 떨어지는 현상이다. 큰 창은 유용하지만, 창이 크다고 모든 정보를 넣어도 된다는 뜻은 아니다. 많은 정보가 곧 좋은 정보는 아니다.

좋은 하네스는 정보를 많이 넣는 장치가 아니라, 필요한 정보를 제때 꺼내는 장치다. 오래된 대화는 요약해서 파일로 옮기고, 긴 로그는 앞뒤 핵심만 넣고 전체는 필요할 때 읽게 한다. 모든 도구 설명을 처음부터 밀어 넣지 않고, 필요한 순간에만 드러내는 방식도 중요하다.

이 방식은 사람의 일과도 닮았다. 새로 온 동료에게 회사 위키 전체를 던져 주는 것은 도움처럼 보이지만 사실은 방해가 될 수 있다. 좋은 인수인계는 지금 해야 할 일, 꼭 지켜야 할 규칙, 참고할 문서 위치, 최근에 실패한 지점만 먼저 알려준다.

AI 에이전트에게도 같은 기준이 필요하다.

• 맥락 부족: 에이전트가 상황을 추측하면서 엉뚱한 선택
• 좋은 맥락: 지금 작업에 필요한 규칙과 최근 변경을 짧게 제공
• 맥락 과식: 중요한 신호가 긴 문서와 로그 속에 묻힘

하네스가 잘 설계될수록 “얼마나 많이 넣을까”보다 “무엇을 지금 보여줄까”가 중요해진다. 이 변화는 프롬프트 작성보다 정보 설계에 가깝다.

AI 에이전트에게 필요한 것은 문서 전체가 아니라 지금의 판단을 돕는 선별된 맥락이다

6. 긴 작업에는 계획자, 실행자, 평가자가 필요하다

짧은 요청은 한 번의 대화로 해결될 수 있다. 하지만 실제 업무는 그렇지 않다. 기능을 설계하고, 코드를 바꾸고, 화면을 확인하고, 테스트를 돌리고, 버그를 고치고, 다시 검토해야 한다. 이런 긴 작업에서는 에이전트가 중간에 길을 잃거나, 대충 마무리하거나, 자신이 만든 결과를 지나치게 좋게 평가할 수 있다.

Anthropic은 2026년 3월 24일 공개한 Harness design for long-running application development에서 긴 시간 자율 코딩을 위해 계획자, 생성자, 평가자를 나누는 방식을 설명했다. 핵심은 하나의 에이전트에게 모든 일을 맡기지 않는 것이다.

• 계획자: 짧은 요청을 제품 명세와 작업 단위로 확장
• 생성자: 정해진 범위 안에서 기능을 구현
• 평가자: 실제 화면, API, 데이터 상태를 확인하고 문제를 되돌려 보냄
• 계약: 시작 전에 완료 조건을 합의해 범위 흐림을 줄임

이 구조가 흥미로운 이유는 AI가 사람의 협업 구조를 닮아간다는 점이다. 좋은 프로젝트에는 만드는 사람만 있지 않다. 무엇을 만들지 정하는 사람, 실제로 만드는 사람, 결과를 확인하는 사람이 필요하다. 에이전트도 긴 작업으로 갈수록 같은 분업이 필요해진다.

오스마니는 특히 완료 조건을 먼저 적는 일의 가치를 강조한다. 작업을 시작하기 전에 무엇을 만들고, 어떤 조건에서 끝났다고 볼지 적어두면 에이전트가 도중에 범위를 바꾸거나 멋대로 성공을 선언하는 위험이 줄어든다.

이것은 제품 개발뿐 아니라 글쓰기, 리서치, 데이터 분석에도 적용된다. “좋은 결과를 만들어줘”보다 “이 결과가 좋은지 판단할 기준을 먼저 합의하자”가 더 강한 지시다.

7. 훅은 부탁을 규칙으로 바꾸는 장치다

원문에서 눈여겨볼 또 다른 키워드는 훅이다. 훅은 특정 순간에 자동으로 실행되는 작은 장치다. 파일을 저장한 뒤, 명령을 실행하기 전, 커밋하기 전, 세션이 시작될 때 같은 시점에 작동한다.

훅이 중요한 이유는 말보다 강하기 때문이다. 에이전트에게 “테스트를 돌려라”라고 말하는 것보다, 파일 변경 후 테스트가 실패하면 그 오류를 바로 에이전트에게 되돌려 보내는 편이 낫다. “위험한 명령을 쓰지 마라”라고 적는 것보다, 위험한 명령이 실행되기 전에 막는 편이 낫다.

좋은 훅은 조용해야 한다. 성공했을 때는 에이전트의 주의를 빼앗지 않는다. 실패했을 때만 자세히 말한다. 예를 들어 타입 검사가 통과하면 아무 메시지도 주지 않고, 실패하면 오류 위치와 수정 힌트를 작업 루프에 넣는다. 이렇게 하면 평소에는 비용이 거의 없고, 문제가 생겼을 때만 강한 신호가 된다.

하네스에서 훅은 안전과 품질의 실무 장치다.

• 실행 전 훅: 위험 명령, 민감 파일 변경, 권한 초과 차단
• 실행 후 훅: 테스트, 타입 검사, 린트, 포맷 결과를 에이전트에게 전달
• 커밋 전 훅: 깨진 테스트, 빠진 문서, 불필요한 큰 변경 탐지
• 세션 시작 훅: 작업 규칙, 최근 실패, 필요한 도구만 불러오기

이런 장치가 쌓이면 에이전트는 단순한 채팅 상대가 아니라, 자기 결과를 보고 다시 고치는 작업자로 바뀐다. 완벽해진다는 뜻은 아니지만, 최소한 같은 구덩이에 계속 빠질 가능성은 줄어든다.

8. 하네스는 서비스가 될 수 있다

오스마니 글의 후반부에서 가장 흥미로운 대목은 서비스형 하네스다. 지금까지 많은 개발자는 LLM API를 호출해 답을 받는 방식에 익숙했다. 질문을 보내고, 응답을 받고, 필요하면 도구 호출을 직접 엮었다.

하지만 에이전트 시대의 기본 단위는 달라지고 있다. 단순한 모델 API가 아니라 하네스 API가 중요해진다. 이 API는 모델 호출만 제공하지 않는다. 도구 실행, 작업 루프, 맥락 관리, 승인 흐름, 샌드박스, 로그, 평가를 함께 제공한다.

이 변화는 꽤 크다. 예전에는 에이전트를 만들려면 직접 반복 루프를 만들고, 도구 호출을 붙이고, 대화 상태를 관리하고, 오류 처리를 설계해야 했다. 이제는 어느 정도 갖춰진 하네스 위에서 시스템 지시문, 도구, 맥락, 하위 에이전트를 조정하는 쪽으로 무게가 이동한다.

서비스 관점에서 보면 돈을 낼 만한 지점도 이동한다.

• 모델 호출: 점점 표준화되고 가격 비교가 쉬워지는 영역
• 실행 환경: 안전한 샌드박스, 브라우저, 파일 시스템, 권한 관리가 필요한 영역
• 검증 루프: 테스트, 로그, 평가자, 재현 가능한 실패 사례가 쌓이는 영역
• 운영 지표: 비용, 지연 시간, 성공률, 실패 원인을 추적하는 영역
• 도메인 도구: 특정 산업이나 업무에 맞춘 전용 도구와 규칙이 붙는 영역

결국 “어떤 모델을 쓰느냐”보다 “그 모델이 어떤 작업 환경에서 움직이느냐”가 제품 차이를 만든다. 앞으로 에이전트 도구 시장은 모델 선택 화면보다 하네스 구성 화면에서 더 치열해질 수 있다.

에이전트 제품의 중심은 모델 호출에서 안전한 실행 환경과 검증 루프로 이동하고 있다

9. 우리에게 의미 있는 변화는 무엇인가

이 글을 읽고 바로 떠올릴 질문은 “그래서 우리는 무엇을 해야 하나”다. 여기서 말하는 우리는 개발자만 뜻하지 않는다. AI로 글을 쓰는 사람, 데이터를 분석하는 사람, 고객 응대를 자동화하는 사람, 업무 자동화를 설계하는 사람 모두 포함된다.

에이전트는 앞으로 더 많은 일을 대신할 것이다. 하지만 대신한다는 말은 책임이 사라진다는 뜻이 아니다. 오히려 책임은 더 선명하게 남는다. 에이전트가 무엇을 할 수 있고, 무엇을 하면 안 되며, 어떤 결과를 믿을 수 있는지 정하는 일은 여전히 사람과 조직의 몫이다.

우리에게 중요한 변화는 세 가지다.

• 첫째: AI 사용 능력은 질문을 잘 쓰는 능력에서 작업 환경을 설계하는 능력으로 확장
• 둘째: 반복 실수는 개인의 운이 아니라 시스템 개선 신호로 다뤄야 함
• 셋째: 자동화의 성과는 빠른 실행보다 재현 가능한 검증에서 판단해야 함

예를 들어 콘텐츠 작업에서도 하네스 관점은 쓸 수 있다. AI가 자꾸 출처가 약한 문장을 만든다면, “출처를 잘 확인해”라고 말하는 데서 끝내면 안 된다. 참고 자료 섹션을 필수로 만들고, 날짜가 있는 정보는 두 출처를 비교하게 하고, 링크가 실제로 열리는지 확인하는 절차를 넣어야 한다.

데이터 분석에서도 마찬가지다. AI가 그럴듯한 차트를 만들었지만 기준 기간을 틀렸다면, 다음부터는 기간, 단위, 집계 기준을 먼저 확인하는 체크를 넣어야 한다. 고객 응대 자동화라면 환불, 개인정보, 법적 표현처럼 위험한 영역에서 반드시 사람 승인을 거치게 해야 한다.

하네스 엔지니어링은 결국 AI를 더 믿자는 말이 아니다. AI를 믿기 위해 필요한 장치를 만들자는 말이다. 이 차이가 중요하다.

10. 도입할 때 바로 물어볼 질문들

AI 에이전트를 도입하거나, 이미 쓰고 있다면 모델 이름보다 먼저 아래 질문을 봐야 한다. 답이 흐릿하다면 하네스가 아직 약한 상태일 가능성이 크다.

• 실패 기록: 에이전트가 최근에 저지른 실수가 다음 규칙으로 남았는가
• 맥락 선별: 필요한 문서만 들어가는가, 아니면 모든 정보를 한꺼번에 밀어 넣는가
• 도구 경계: 에이전트가 읽고, 쓰고, 실행할 수 있는 범위가 명확한가
• 위험 차단: 되돌리기 어려운 명령이나 민감한 변경 앞에서 멈추는가
• 평가 루프: 결과가 좋아졌는지 다시 확인할 수 있는 테스트와 재현 사례가 있는가
• 관찰 지표: 비용, 지연 시간, 실패 원인, 반복 패턴을 볼 수 있는가
• 소유자: 하네스의 규칙과 도구를 누가 관리하고 정리하는가

여기서 특히 중요한 것은 소유자다. 하네스는 한 번 만들고 끝나는 설정 파일이 아니다. 모델이 바뀌고, 도구가 바뀌고, 업무가 바뀌면 하네스도 바뀌어야 한다. 어떤 규칙은 더 이상 필요 없어지고, 어떤 안전장치는 새로 필요해진다.

좋은 하네스는 계속 커지기만 하지 않는다. 오스마니는 모델이 좋아지면 일부 장치는 사라져야 한다고 본다. 모델이 이제 잘하는 일을 계속 보조하면 비용만 늘어난다. 반대로 새로 가능해진 긴 작업에는 새로운 평가자, 새로운 메모리 정책, 새로운 도구 조합이 필요하다.

에이전트 운영의 핵심은 더 큰 모델을 기다리는 일이 아니라 더 나은 반복 구조를 만드는 일이다

11. 에이전트 경쟁은 어디로 가는가

오스마니는 주요 코딩 에이전트들이 점점 비슷한 형태로 수렴하고 있다고 본다. 모델은 달라도 하네스 패턴은 닮아간다는 뜻이다. 파일 시스템, 명령 실행, 브라우저 확인, 권한 관리, 하위 에이전트, 작업 계획, 자동 평가 같은 요소가 점점 기본 부품처럼 자리 잡고 있다.

이 흐름이 계속되면 경쟁은 두 방향으로 갈 가능성이 크다.

첫째는 기본 하네스 경쟁이다. 누가 더 안정적인 실행 환경을 제공하는가. 누가 더 좋은 도구 연결을 제공하는가. 누가 실패를 더 잘 재현하고, 비용을 더 투명하게 보여주는가. 이 영역은 클라우드 인프라와 개발자 도구 기업이 강하게 달려들 수밖에 없다.

둘째는 도메인 하네스 경쟁이다. 범용 에이전트가 아니라 특정 업무에 맞춘 하네스가 중요해진다. 법무 검토용 하네스, 재무 분석용 하네스, 소프트웨어 테스트용 하네스, 콘텐츠 검수용 하네스, 고객 상담용 하네스처럼 업무별 규칙과 도구가 들어간 형태다.

여기서 핵심은 데이터보다 작업 방식일 수 있다. 많은 회사가 데이터 보유를 강점으로 말하지만, 실제 자동화에서는 그 데이터를 어떻게 읽고, 어떤 순서로 판단하고, 어떤 순간 멈추며, 무엇을 검증할지가 더 중요해진다. 즉 업무 절차 자체가 경쟁력이 된다.

서비스로서의 하네스는 이 지점을 상품화한다. 고객은 단순히 모델 토큰을 사는 것이 아니라, 안전하게 실행되고 검증되는 업무 흐름을 산다. 앞으로 에이전트 도구의 가격표는 모델 사용량뿐 아니라 샌드박스 시간, 브라우저 실행, 평가자 호출, 로그 보관, 승인 흐름 같은 항목으로 더 세분화될 수 있다.

12. 그래도 하네스가 만능은 아니다

하네스 엔지니어링을 이야기할 때 조심해야 할 점도 있다. 하네스가 모든 문제를 해결해 주지는 않는다. 잘못 만든 하네스는 오히려 에이전트를 둔하게 만들 수 있다.

규칙이 너무 많으면 모델은 중요한 지시를 놓친다. 도구가 너무 많으면 어떤 도구를 써야 할지 헷갈린다. 평가자가 너무 느리면 자동화의 이점이 줄어든다. 안전장치가 너무 빡빡하면 실제로 필요한 작업까지 막힌다.

또 하나의 위험은 하네스가 낡는 것이다. 특정 모델의 약점을 보완하려고 만든 장치가 다음 모델에서는 불필요해질 수 있다. 반대로 새 모델이 더 긴 작업을 할 수 있게 되면 예전에는 없던 실패가 생길 수 있다. 하네스는 코드처럼 유지보수되어야 한다.

따라서 좋은 운영 원칙은 균형에 있다.

• 실제 실패에서 출발: 상상한 위험보다 반복된 문제를 먼저 다룸
• 작은 규칙 유지: 모든 것을 적기보다 정말 중요한 기준만 남김
• 빠른 검사는 자주: 타입 검사, 린트, 짧은 테스트처럼 싼 신호를 자주 사용
• 비싼 평가는 선별: 긴 리뷰, AI 평가자, 브라우저 자동화는 필요한 지점에 배치
• 주기적 정리: 더 이상 필요 없는 규칙과 도구를 걷어냄

하네스는 에이전트를 완전히 통제하는 감옥이 아니다. 더 안전하게 멀리 가기 위한 레일에 가깝다. 중요한 것은 더 많은 제약이 아니라 더 정확한 제약이다.

결론

애디 오스마니의 Agent Harness Engineering은 AI 에이전트 논쟁을 한 단계 현실 쪽으로 끌어당긴다. 모델은 중요하다. 하지만 모델만으로는 에이전트가 되지 않는다. 에이전트는 모델이 도구를 쓰고, 맥락을 받고, 실패를 관찰하고, 다시 시도하고, 위험한 행동 앞에서 멈출 때 비로소 실제 업무에 가까워진다.

그래서 이 글의 핵심은 “더 좋은 모델을 기다리지 말자”가 아니다. 더 좋은 모델을 기다리는 동안에도 오늘 고칠 수 있는 것이 있다는 말에 가깝다. 반복되는 실수를 규칙으로 남기고, 필요한 맥락만 주고, 위험한 행동을 막고, 결과를 다시 확인하는 일이다.

앞으로 AI 에이전트의 경쟁력은 답변 문장의 매끄러움보다 작업을 끝까지 믿을 수 있게 만드는 주변 장치에서 갈릴 가능성이 크다. 모델이 엔진이라면 하네스는 운전석, 도로, 계기판, 정비 기록이다. 우리는 이제 엔진 소리만 듣는 단계를 지나, 그 엔진이 어떤 차 안에서 달리는지 봐야 한다.

참고 자료

• Agent Harness Engineering - Addy Osmani, 2026년 4월 19일
• Harness design for long-running application development - Anthropic Engineering, 2026년 3월 24일
• Harness engineering for coding agent users - Birgitta Böckeler, Martin Fowler, 2026년 4월 2일
• Building effective agents - Anthropic Engineering, 2024년 12월 19일