AI 에이전트가 자꾸 실수하는 이유: 모델보다 하네스가 중요해졌다

처음에는 보통 모델을 탓합니다. 에이전트가 파일을 놓쳤다. 엉뚱한 문단을 고쳤다. 브라우저에서 다른 페이지를 열었다. 그럴듯한 요약을 만들었는데 아무도 그대로 쓰지 못했다. 그러면 곧바로 이런 말이 나옵니다. 모델이 아직 부족하다, 프롬프트가 약하다, 컨텍스트 창이 더 커야 한다.

맞는 말일 때도 있습니다. 그런데 실무에서는 더 자주 보이는 원인이 따로 있습니다. 모델을 일할 수 있는 작업 환경 없이 던져 넣은 겁니다.

요즘 이 주변 장치를 하네스라고 부릅니다. 말이 조금 개발자스럽기는 합니다. 그래도 실무에서 겪는 문제를 꽤 정확하게 짚는 단어입니다. AI 에이전트가 실무에서 버티려면 모델만 있으면 안 됩니다. 어떤 정보를 받을지, 어떤 도구를 쓸지, 어디까지 바꿔도 되는지, 결과를 어떻게 증명할지, 사람이 어디서 확인할지, 막혔을 때 어떻게 멈출지까지 같이 있어야 합니다.

하네스가 약하면 좋은 모델도 똑똑한 신입에게 노트북만 던져준 것과 비슷해집니다. 한 번은 일을 잘할 수 있습니다. 하지만 계속 맡기기는 어렵습니다.

확인하고 싶었던 실패 패턴

먼저 본 건 기능표가 아니라 실제 일이 어디서 막히는지였습니다. AI 에이전트가 실무에서 흔들릴 때는 모델만 바꿔도 해결되지 않습니다. 맥락 전달, 도구 권한, 로그, 재시도, 사람 확인 지점을 먼저 점검해야 합니다. 결국 남는 기준은 결과물을 다음 사람이 다시 해체하지 않고 이어받을 수 있느냐였습니다.

테스트베드로 삼은 에이전트 업무

제가 놓고 본 업무는 이렇습니다. 기억, 권한, 도구 호출, fallback 규칙이 자동화 신뢰도를 가르는 에이전트 업무. 먼저 자료가 어디서 들어오고, 누가 확인하고, 결과가 어디에 남는지부터 적었습니다. OpenAI Codex, ChatGPT, Claude, LangChain, Databricks, AI 에이전트는 그 흐름을 덜 흔들리게 만들 때만 의미가 있었습니다.

하네스에서 본 구성요소

확인한 것	제가 본 기준	실패 신호
입력 자료	AI가 그대로 써도 될 만큼 자료가 분명한가	빠진 맥락을 질문하지 않고 추측합니다
사람 검토	승인, 수정, 반려가 몇 분 안에 가능한가	검토자가 처음부터 다시 읽습니다
다음 전달	문서, 표, 티켓, 업무 흐름으로 바로 넘길 수 있는가	다음 사람이 형식이나 의미를 다시 맞춥니다
반복성	다른 자료를 넣어도 같은 방식으로 굴러가는가	첫 번은 괜찮고 두 번째부터 흔들립니다

시연과 실행을 가른 메모

증거	확인한 것	왜 중요했나
입력	기억, 권한, 도구 호출, fallback 규칙이 자동화 신뢰도를 가르는 에이전트 업무.	일은 도구 이름이 아니라 들어오는 자료에서 시작합니다
검토 지점	누가 확인하고 무엇을 반려할 수 있는지 봤습니다	검토자가 없으면 자동화처럼 보일 뿐입니다
실패 메모	정상 경로는 끝냈지만 권한, 복구, 도구 호출 생략 이유를 설명하지 못하는 상황.	안 된 실행을 하나 남겨야 범위를 줄일 수 있습니다

좋은 답변인데도 멈춘 지점

문제는 첫 답변보다 그다음이었습니다. 답변을 받은 뒤 실제로 넘기려는 순간에 일이 다시 늘어났습니다. 이 주제에서 자주 보인 실패는 이렇습니다. 정상 경로는 끝냈지만 권한, 복구, 도구 호출 생략 이유를 설명하지 못하는 상황. 그래서 저는 보기 좋은 초안을 업무 준비 완료로 보지 않습니다.

권한을 넓히기 전에 요구할 조건

저라면 먼저 원자료, 판단표, 실패 메모, 독자가 다시 쓸 수 있는 체크리스트를 남깁니다. 그 자료가 사람 검토를 통과하는지 확인한 뒤에야 도구를 고릅니다. 몇 분 안에 확인할 수 없는 결과라면 모델을 바꾸기 전에 자동화 범위부터 줄이는 편이 낫습니다.

에이전트를 넓히기 전 체크

AI가 받는 입력 자료를 한 줄로 적습니다.
결과를 승인하거나 반려할 사람을 정합니다.
출력물이 다음에 어디로 가야 하는지 정합니다.
잘 된 예시만 두지 말고 실패한 예시도 하나 남깁니다.
생성은 빨라졌는데 검토 시간이 그대로라면 효과가 없습니다.
다음 사람이 계속 다시 만들고 있다면 그 자동화는 멈춥니다.

확인한 자료

변할 수 있는 사실은 공식 문서, 제품 페이지, 바뀔 가능성이 있는 주장에 대한 출처 메모를 기준으로 확인했습니다. 가격, 모델 접근, 플랫폼 기능은 자주 바뀌기 때문에 의견과 근거를 분리해서 봐야 합니다.

회의에서 짧게 말한다면

AI 에이전트는 단순히 도구를 붙인 모델이 아닙니다. 모델을 중심에 둔 작업 환경이라고 보는 편이 맞습니다.

층위	맡는 일	실패 신호
작업 패킷	목표, 파일, 범위, 현재 상태	매번 같은 설명을 다시 요구함
도구 경계	브라우저, 터미널, 문서, API, 저장소	읽을 것은 못 읽고 바꿀 것은 너무 많이 바꿈
권한 모델	읽기, 초안, 수정, 삭제, 발송, 결제, 배포	유용한 행동이 바로 업무 리스크가 됨
확인 경로	테스트, 린트, diff, 스크린샷, 출처, 리뷰 메모	결과는 좋아 보이는데 증명할 방법이 없음
복구 경로	재시도, 롤백, 담당자, 중단 상태	예상 밖 페이지나 API 오류 하나에 전체가 멈춤
기억과 재사용	저장된 규칙, 플레이북, 반복 실수	다음날 다시 처음부터 시작함

모델 성능은 중요합니다. 그걸 부정할 생각은 없습니다. 다만 모델은 전체 작업 시스템의 일부입니다. 주변 하네스가 얇으면 에이전트를 돌릴 때마다 사람이 새로 감독해야 하는 일이 됩니다.

하네스라는 말을 쉽게 풀면

코딩 에이전트에서 하네스는 IDE 하나를 뜻하지 않습니다. 저장소 상태, 브랜치 규칙, 테스트 명령어, 패키지 매니저, 로컬 서비스, 비밀값 정책, 배포 스크립트, 코드 리뷰 방식, 완료 기준까지 포함합니다.

브라우저를 쓰는 에이전트라면 로그인 상태, 허용 도메인, 출처 우선순위, 스크린샷 증거, 다운로드 폴더 규칙, 자동화가 막혔을 때의 처리 방식까지 들어갑니다.

문서 업무라면 원본 파일, 파일명 규칙, 템플릿 구조, 표 형식, 검토자 코멘트, 버전 이력, 에이전트가 고쳐도 되는 문장과 표시만 해야 하는 문장의 경계가 하네스입니다.

고객지원이나 영업 운영이라면 고객 데이터 범위, CRM 필드, 에스컬레이션 규칙, 말투 정책, 승인 지점, 에이전트가 실제로 발송해도 되는지 아니면 초안만 만들어야 하는지가 하네스입니다.

그래서 저는 에이전트를 깔끔한 파일 하나와 프롬프트 하나로 판단하는 걸 별로 믿지 않습니다. 그건 모델이 작업 하나를 할 수 있다는 뜻입니다. 다음 주에 파일명이 바뀌고, 로그인이 풀리고, 고객이 이상한 문장으로 문의하고, 검토자가 “그래서 어디를 고쳤냐”고 물을 때도 굴러간다는 뜻은 아닙니다.

실무에서 먼저 깨지는 곳

실패는 대개 거창하지 않습니다. 너무 평범해서 오히려 무시됩니다.

어떤 에이전트는 제품 요구사항 문서를 잘 요약합니다. 그런데 법무 섹션은 수정 범위가 아니라는 걸 모릅니다. 다른 에이전트는 스프레드시트를 읽습니다. 하지만 빈칸이 0이 아니라 “아직 승인 전”이라는 뜻인 줄 모릅니다. 코딩 에이전트는 테스트를 고칩니다. 그런데 배포 때 같은 파일을 다시 생성하는 내부 스크립트를 놓칩니다. 브라우저 에이전트는 출처를 모읍니다. 하지만 공식 정책 페이지와 긁어온 재게시 글을 구분하지 못합니다.

이런 경우 모델이 아무 쓸모 없다는 뜻은 아닙니다. 작업 패킷이 부족했던 겁니다.

저라면 먼저 프롬프트 실패로 보지 않습니다. 하네스 실패로 표시합니다.

문제가 된 장면	모델을 바꾸기 전에 할 일
엉뚱한 파일을 고침	허용 파일 목록과 수정 전 diff 확인 규칙을 둠
답변에 근거가 없음	완료 전에 출처, 스크린샷, 명령 결과를 남기게 함
같은 예외가 반복됨	더 긴 프롬프트가 아니라 운영 규칙에 예외를 추가함
검토 시간이 줄지 않음	초안, 확인, 최종 실행 단계를 나눔
무엇이 바뀌었는지 모름	파일, 출처, 남은 위험을 마지막에 남기게 함
중간에 권한을 더 달라고 함	시작 전에 허용 도구와 금지 행동을 정함

표만 보면 단순합니다. 하지만 실제 운영에서는 이 차이가 “흥미로운 시연”과 “실무에 가까이 둘 수 있는 일”을 가릅니다.

코딩 업무 예시

Codex 같은 코딩 에이전트를 생각해보면 차이가 분명합니다. 인상적인 부분은 코드를 쓴다는 사실 자체가 아닙니다. 코드는 여러 모델이 씁니다. 핵심은 기존 프로젝트 안에서 개발자에게 두 번째 일을 만들지 않고 움직일 수 있느냐입니다.

한 저장소에서 쓸 만한 하네스는 이런 패킷을 갖습니다.

현재 브랜치와 새 브랜치 생성 가능 여부.
실제 런타임을 결정하는 파일.
정확한 테스트 명령어와 너무 느려서 평소에는 피할 명령어.
실행 중인 앱이 있어도 사용할 수 있는 빌드 방식.
배포 경로와 배포 후 남겨야 할 증거.
고객 데이터, 비밀값, 관련 없는 미커밋 변경은 건드리지 않는다는 규칙.

이게 없으면 에이전트는 여전히 바빠 보입니다. 코드를 읽고, 패치를 만들고, 설명도 합니다. 하지만 개발자는 다시 확인해야 합니다. 테스트 명령이 맞았는지, 경계를 잘못 건드렸는지, 말하지 않은 관례를 깼는지, 배포 단계를 남겨둔 건 아닌지 봐야 합니다.

그건 자동화라기보다, 사람이 뒤에서 다시 맞춰 봐야 하는 보조 작업입니다.

하네스가 있으면 같은 에이전트가 훨씬 쓸 만해집니다. 어디서 시작할지 알고, 어떻게 증명할지 알고, 언제 멈출지 알고, 사람이 믿을 수 있는 인수인계를 남깁니다.

문서 업무 예시

코드 밖에서도 똑같습니다. 세 개의 PDF, 하나의 스프레드시트, 두 번의 회의 메모를 바탕으로 벤더 비교 메모를 만든다고 해보겠습니다.

약한 요청은 익숙합니다. “이 자료 읽고 비교표 만들어줘.”

강한 하네스는 이렇게 생겼습니다.

벤더 목록은 PDF가 아니라 스프레드시트를 기준으로 삼는다.
가격은 날짜가 가장 최신인 문서에서만 가져온다.
확인되지 않은 정보는 추정하지 않고 “미확인”으로 표시한다.
보안 우려는 점수 안에 섞지 말고 별도 섹션에 둔다.
추천에 영향을 주는 문장은 반드시 출처 메모를 남긴다.
메모 초안은 만들되, 최종 추천 문장은 사람 검토 전까지 바꾸지 않는다.

화려하지 않습니다. 그냥 운영 디테일입니다. 그런데 신뢰는 여기서 생깁니다. 에이전트가 확정 사실과 회의 중 나온 의견을 구분하지 못하고, 추천 근거를 남기지 못한다면 저는 그 판단을 맡기지 않습니다.

현장 판단: 범위를 넓히기 전에 보는 것

에이전트의 범위를 넓히기 전에 저는 네 가지를 먼저 확인합니다.

첫째, 시작 전에 일의 모양을 알고 있는가. 사람이 매번 폴더 구조, 출처 순서, 출력 형식을 다시 설명해야 한다면 하네스가 아직 준비되지 않은 겁니다.

둘째, 시키지 않아도 근거를 남기는가. diff, 출처, 명령 결과, 스크린샷, 검토자가 보기 쉬운 변경 목록이 필요합니다. 자신감 있는 문단은 근거가 아닙니다.

셋째, 권한 경계가 심심할 정도로 명확한가. 읽기 작업은 조금 느슨해도 됩니다. 초안 작성도 어느 정도 넓게 줄 수 있습니다. 하지만 발송, 삭제, 게시, 결제, 고객 기록 수정은 확인 경로가 충분히 반복될 때까지 좁게 가져가야 합니다.

넷째, 실패한 실행이 다음 실행을 낫게 만드는가. 막힌 실행이 “다시 해보자”로 끝나면 시스템이 배운 게 없습니다. 그 예외가 규칙, 체크리스트, 저장된 스킬로 남으면 하네스가 성숙해지는 겁니다.

“에이전트 품질” 대신 봐야 할 지표

팀에서는 에이전트가 좋은지 묻습니다. 질문이 너무 큽니다.

저는 검토 부담부터 확인합니다. 사람이 결과를 확인하는 데 몇 분을 썼는지, 고쳐야 할 사실이 몇 개인지, 입력값 부족으로 몇 번 멈췄는지, 최종 행동을 검토자가 몇 번 거절했는지, 손으로 다시 처리한 단계가 몇 개인지 따집니다.

에이전트가 더 그럴듯한 초안을 만들었는데 검토 시간이 그대로라면 하네스는 아직 돈값을 못 한 겁니다. 초안이 조금 덜 예뻐도 재작업이 줄고 인수인계가 분명해졌다면 저는 그쪽을 택합니다.

현장에서 쓰는 점수표는 단순합니다.

질문	좋은 신호	나쁜 신호
현재 상태를 알고 있는가	올바른 파일, 날짜, 담당자를 언급함	시스템 안에 있는 기본 정보를 다시 물음
도구를 안전하게 쓰는가	넓게 읽고 좁게 씀	계획을 보이기 전에 수정부터 함
근거를 남겼는가	검토자가 경로를 확인할 수 있음	사람이 일을 다시 재현해야 함
실패가 시스템을 낫게 했는가	예외가 규칙으로 남음	다음 실행이 같은 실수를 반복함
사람 일이 줄었는가	검토 시간이 줄어듦	결과는 매끈한데 여전히 위험함

에이전트부터 고르지 마세요

저라면 “어떤 에이전트를 살까”로 시작하지 않습니다. 눈에 보이는 반복 업무 하나를 고릅니다.

좋은 후보는 입력값이 분명하고, 출력물이 반복되고, 검토자가 있고, 인수인계를 측정할 수 있습니다. 나쁜 후보는 숨은 정치, 흐릿한 판단, 검토 습관이 없는 상태의 실행 권한에 기대고 있습니다.

예를 들어 “주간 벤더 리스크 메모 초안을 출처와 함께 만든다”는 시작할 만합니다. “벤더 리스크를 처리한다”는 너무 큽니다. 앞의 것은 하네스를 만들 수 있습니다. 뒤의 것은 아직 희망사항입니다.

프롬프트 모음이 사람을 실망시키는 이유도 여기에 있습니다. 프롬프트는 한 순간을 개선합니다. 하네스는 그 순간의 앞뒤 경로를 개선합니다.

실패 기준을 먼저 적어야 합니다

에이전트가 그럴듯해지기 전에 중단 기준부터 적는 편이 낫습니다.

추천의 출처를 말하지 못하면 중단합니다.
사람이 모든 문장을 다시 확인해야 하면 중단합니다.
반복 업무를 끝내기 위해 권한을 계속 넓혀 달라고 하면 중단합니다.
검토 전 고객이나 외부에 노출되는 자료를 바꾸면 중단합니다.
같은 예외가 세 번 연속 나오면 중단합니다.
담당자가 에이전트가 한 일을 설명하지 못하면 중단합니다.

보수적으로 들릴 수 있습니다. 하지만 실제 시스템에 접근한 뒤 자신감 있는 실수를 수습하는 것보다 훨씬 쌉니다.

먼저 만들 것은 모델 선택표가 아닙니다

저라면 모델을 바꾸기 전에 작은 하네스 문서부터 만듭니다. 한 장이면 됩니다.

어떤 일이 에이전트에게 들어가는가.
에이전트가 무엇을 읽을 수 있는가.
에이전트가 무엇을 바꿀 수 있는가.
어떤 근거를 남겨야 하는가.
누가 결과를 확인하는가.
실행이 막히면 어떻게 멈추는가.
어떤 반복 실수를 새 규칙으로 남길 것인가.

그리고 같은 업무를 다섯 번 실행합니다. 느낌이 아니라 검토 시간의 변화를 기록합니다. 다섯 번째 실행도 첫 번째 실행과 같은 설명을 사람이 다시 해야 한다면 아직 해결된 게 아닙니다.

자주 묻는 질문

하네스 엔지니어링은 코딩 에이전트에만 필요한가요?

아닙니다. 코딩 에이전트는 저장소, 테스트, diff가 있어서 문제가 잘 보일 뿐입니다. 문서, 브라우저 리서치, 고객지원, 영업 운영, 내부 보고에서도 같은 패턴이 나옵니다.

모델이 좋아지면 하네스가 덜 필요하지 않나요?

일부 실수는 줄어듭니다. 하지만 운영 문제는 사라지지 않습니다. 좋은 모델도 올바른 맥락, 안전한 도구, 근거 요구, 검토 경로가 필요합니다.

모든 업무를 에이전트로 바꿔야 하나요?

아닙니다. 드물게 일어나거나, 판단이 무겁거나, 조직 정치가 섞인 일은 체크리스트와 좋은 담당자가 더 낫습니다. 반복, 근거, 인수인계가 분명할 때 에이전트가 자리를 얻습니다.

하네스가 제대로 잡혔다는 첫 신호는 뭔가요?

에이전트가 덜 요란해집니다. 설정 질문이 줄고, 근거가 남고, 막히면 안전하게 멈추고, 검토자의 일을 더 크게 만들지 않습니다.

제 결론

다음 단계의 AI 에이전트 경쟁은 모델 크기만으로 결정되지 않을 겁니다. 일을 잘 포장하고, 도구를 제한하고, 결과를 증명하고, 반복 실패를 운영 규칙으로 바꾸는 팀이 앞서갈 가능성이 큽니다.

그래서 하네스 엔지니어링이 중요합니다. 모델 옆에 붙이는 장식이 아닙니다. 한 번의 멋진 실행과 내일도 다시 맡길 수 있는 업무 시스템을 가르는 차이입니다.

업무 흐름

이 글이 속한 업무 흐름

지금 읽는 글이 어떤 업무 흐름에 연결되는지 확인하고, 관련 글로 이어서 볼 수 있습니다.

도구 스택 선택 팀의 운영 성숙도에 맞는 스택을 고릅니다.

자동화 플랫폼, 앱 빌더, 에이전트 빌더, 회계 도구, 범용 AI 어시스턴트는 운영 부담까지 같이 따져야 합니다.

참고한 공개 자료

본문의 보도 사실, 공식 문서, 정책 배경, 제품 정보, 바뀔 수 있는 주장을 확인할 때 참고한 공개 자료입니다.

Harness engineering OpenAI
Harness engineering for coding agent users Martin Fowler
The Anatomy of an Agent Harness LangChain
What is an AI Harness? Databricks
Building effective agents Anthropic
Engineer photo Wikimedia Commons / Bench Accounting

다음 단계

읽은 내용을 운영 체크리스트로 옮겨보세요.

먼저 리소스 경로에서 업무 flow를 점검하고, 현재 프로세스와 인계 지점을 확인한 뒤 도구를 비교하세요.

비교 업데이트 제보