AI 에이전트를 신뢰할 수 있게 만드는 방법: 측정에서 자율 작업까지 단계별 로드맵

모델이 강력해도 에이전트가 신뢰할 수 없는 이유

신뢰성은 모델이 아니라 시스템 전체의 속성입니다. 긴 작업은 수십 단계로 이루어지고, 오류는 쌓입니다. 각 단계가 95% 정확하다면, 오류 없이 열 단계를 통과하는 실행은 약 60%(0.95^10 ≈ 0.60)이고, 쉰 단계를 통과하는 실행은 10% 미만입니다. 모델의 정확도는 여러분이 높일 수 없지만, 오류를 같은 단계에서 잡아내 저렴하게 만드는 것은 할 수 있습니다. 하네스가 하는 일이 바로 이것입니다: 모델 주변의 지침, 도구, 환경, 상태, 피드백.

아래 계획은 "느낌"으로 평가하던 단계에서 측정 가능한 신뢰성으로, 그리고 거기서 자율 작업으로 이어집니다. 단계는 효과의 순서대로 배열되어 있으며, 각 단계는 앞 단계를 바탕으로 합니다.

1단계. 느낌으로 평가하는 것을 멈추세요

한 엔지니어는 새 프롬프트가 모든 것을 바꿨다고 믿고, 다른 엔지니어는 차이를 보지 못하며, 아무도 지표를 재지 않았습니다. 실패 기록부터 시작하세요. 에이전트가 막히거나, 무언가를 망가뜨리거나, 작동하지 않는 기능을 완료라고 보고할 때마다 한 줄씩 적으세요.

| 날짜  | 작업             | 무슨 일이 있었나               | 구성 요소      |
|-------|------------------|--------------------------------|----------------|
| 10.10 | 장바구니 할인    | "완료", e2e는 실행 안 함      | 피드백         |
| 10.10 | 결제 webhook     | 데이터베이스를 띄우지 못함     | 환경           |
| 11.10 | API 리팩터링     | 기각된 해결책을 되풀이함       | 상태           |

"구성 요소" 열이 가장 중요합니다. 일주일 뒤에는 병목이 어디인지 보이고, 모든 것이 아니라 그것만 고치게 됩니다. 성공한 실행만으로 신뢰성을 세는 것은 실수입니다. 에이전트가 어디서 넘어지는지는 막힘 기록만 보여 줍니다.

2단계. 두 가지 지표를 도입하세요: MTBF와 MTTR

신뢰성은 두 숫자로 측정합니다. 에이전트에게 MTBF(고장 간 평균 시간)는 막히기 전까지 몇 단계를 갈 수 있는지입니다. MTTR(평균 복구 시간)은 고장 후 정상 상태로 돌아가는 데 걸리는 시간입니다. 가용성은 두 숫자 모두의 영향을 받습니다: 첫 번째가 늘거나 두 번째가 줄어듭니다.

절대 실수하지 않는 에이전트를 쫓는 것은 끝없는 경주입니다. MTTR을 줄이는 것은 보통 하루면 가능합니다. 그러니 두 번째 숫자부터 시작하세요.

3단계. 실수를 저렴하게 만드세요

에이전트에게 자율성을 주는 것은 에이전트가 실수를 멈췄을 때가 아니라, 실수의 비용이 거의 0에 가까워졌을 때입니다. 이를 위해 세 가지가 필요합니다:

• 작고 깨끗한 commit — 어떤 수정이든 명령 한 번으로 되돌릴 수 있어야 합니다.
• 격리 — 에이전트는 별도 브랜치나 작업 사본에서, 예를 들어 git worktree로, 운영 환경 접근이 없는 sandbox 안에서 일해야 합니다.
• 환경 초기화 스크립트 — 데이터베이스, 의존성, 서비스가 명령 한 번으로 초기 상태로 돌아가야 합니다.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # 데이터베이스 재생성, migration 적용, fixture 로드

전체 복귀에 얼마나 걸리는지 스톱워치로 재어 보세요. 그것이 여러분의 MTTR입니다. 또한 피해 범위를 제한하세요: 한 작업의 변경 크기에 상한을 두고, 작업 범위 밖 파일의 수정을 금지하세요.

4단계. 피드백 루프를 닫으세요

검사가 없으면 에이전트는 자신의 유일한 심판이며, 작업이 끝났다고 성실하게 믿습니다. 에이전트가 스스로 확인할 수 있는 명령을 주고, 그것을 필수로 만드세요.

• Fail-fast: 검사는 첫 번째 오류에서 명확한 메시지와 함께 멈춰야 하며, 백 줄짜리 소음을 내면 안 됩니다.
• 변경할 때마다 빠른 검사: 에이전트의 hook을 통한 linter와 타입 검사.
• 중복 안전장치: 같은 속성을 두 번째 독립 검사로 확인하세요. 예를 들어 unit 테스트 위에 E2E 시나리오를 두는 것입니다. 초록색 unit 테스트는 사용자에게 기능이 작동한다는 증명이 아닙니다.

"완료" 기준은 "할인이 구현되었다"가 아니라 "프로모션 코드가 적용된 주문 흐름의 E2E 시나리오가 통과한다"처럼 검증 가능한 조건으로 적으세요.

5단계. 기억을 파일로 옮기세요

에이전트는 이전 세션을 기억하지 못합니다. 작업을 이어 가는 데 필요한 모든 것은 저장소에 있어야 합니다: 목표, 완료된 작업과 검증 방법, 이유가 적힌 결정, 막다른 길, 다음 단계. 좋은 신호는, 저장소와 "계속해"라는 말만 받은 새 세션이 곧바로 유용한 작업을 시작하는 것입니다.

길게 압축된 대화 기록은 연속성의 느낌을 주지만 가장 귀한 것, 즉 기각된 결정의 이유를 잃어버립니다. 완전한 서면 상태를 갖춘 채 의도적으로 세션을 재설정하는 것이 보통 더 저렴합니다.

6단계. 한 번에 한 작업만

리틀의 법칙: 동시에 진행 중인 작업 수는 도착률에 작업의 시스템 체류 시간을 곱한 값과 같습니다. 용량이 고정되어 있을 때 병렬 작업은 속도를 높이지 않고 각 작업을 늘려 놓을 뿐입니다. 에이전트에게는 더 가혹합니다: 세 가지 기능은 같은 context 창 안에 세 개의 도메인 모델이 있는 것을 뜻합니다.

• WIP=1을 유지하세요: 검증된 결과에 도달할 때까지 기능은 하나.
• 작업을 작게 나누세요: 검증 가능한 사용자 기능 하나, 파일 1에서 3개, 1분 미만의 검사.
• BACKLOG.md를 두세요 — "덤으로 할 것"을 위한 밸브입니다. 이웃한 결함을 발견하면 백로그에 한 줄 적고, 임의로 고치지 않습니다.

7단계. 실행자와 검증자를 분리하세요

에이전트의 자기 평가는 약한 브레이크입니다. 코드를 쓴 같은 세션은 그 코드가 옳다고 생각하기 쉽습니다. 결과 평가는 별도의 subagent나 별도의 세션이 맡게 하세요. 그들은 요구사항, diff, 검사 결과만 받고, 실행자의 추론은 받지 않아야 합니다. 검증자의 판정은 "괜찮아 보인다"가 아니라 기계 검사에 기반해야 합니다.

8단계. 에이전트를 자율 순환에 맡기세요

하네스는 한 번의 실행을 신뢰할 수 있게 만들고, 순환은 실행의 연속을 자율적으로 만듭니다. 나쁜 하네스 위에 올린 순환은 실수를 더 빨리 늘릴 뿐이므로, 이 단계는 마지막입니다. 가장 간단한 순환은 세 줄로 적을 수 있습니다:

목표:        프로모션 코드 포함 e2e 결제 시나리오 통과
검사:        make lint && make test && make e2e
중단:        목표 달성 또는 15회 시도 또는 2시간 → 사람을 호출

작업에 맞는 순환을 고르세요. 작업에 끝선이 있다면 목표 지향 순환이 필요합니다: 진행 상황의 기억, 독립된 검증자, 단계 예산. 끝이 없다면(아침 CI 점검, 새 오류 분류) 일정 기반 순환이 맞습니다. 흔한 실수는 끝이 있는 작업을 일정에 맞춰 실행하는 것입니다. 그러면 매번 실행이 처음부터 시작합니다.

안전한 자율성의 규칙

• 중단 조건은 기계가 검증할 수 있는 것만으로 하고, 시도 횟수와 예산 한도를 함께 두세요.
• 에스컬레이션: 순환을 신뢰하지 않을 대상을 미리 나열하세요(운영 migration, 금전, 데이터 삭제).
• 작업이 막혀서 실제 진전이 없다면, 이는 사람에게 넘기라는 신호입니다. 순환을 더 돌리지 마세요.
• diff를 읽으세요. 순환의 속도가 여러분의 읽는 속도를 넘지 않게 하세요. 그렇지 않으면 자신의 코드베이스를 이해하기를 멈추게 됩니다.

이 길에서 흔한 실수

지침을 다시 쓰는 것으로 시작하기

에이전트 실패에 대한 가장 인기 있는 반응은 AGENTS.md에 규칙을 하나 더 추가하는 것입니다. 몇 달 후 파일은 수백 줄이 되고, 중요한 규칙은 그 안에서 사라집니다. 실패 기록이 에이전트가 검사를 실행하지 않았음을 보여 준다면, 피드백을 고치세요: 텍스트 한 단락이 아니라 검사 명령과 hook을요.

모든 것을 한꺼번에 고치기

하네스의 다섯 구성 요소를 동시에 개선하고 싶은 유혹이 있습니다. 하지만 그러면 무엇이 실제로 도움이 되었는지 알 수 없습니다. 각 구성 요소를 1에서 5 사이로 평가하고, 가장 약한 것에 30분을 투자하고, 같은 대표 작업 다섯 개를 개선 전후에 실행하세요. 실패 기록의 차이가 효과가 있었는지 알려 줍니다.

"테스트 초록색"과 "기능 작동"을 혼동하기

에이전트는 요구사항이 아니라 자신의 구현을 검사하는 테스트를 쓸 수 있습니다. 그런 테스트는 항상 초록색입니다. 방어 방법은 구현 전에 작성되었거나 독립된 검증자가 작성한 사용자 수준의 검사(E2E 시나리오)와, 에이전트가 테스트를 통과시키려고 테스트를 고치지 않는다는 규칙입니다.

속도를 위해 검사를 끄기

느린 검사는 "이번만 건너뛰자"는 유혹을 줍니다. 이를 분리하는 것이 낫습니다: 빠른 linter와 타입 검사는 변경할 때마다, 전체 테스트 세트와 E2E는 "완료"라고 말하기 전에. 그러면 피드백 루프가 짧게 유지되고 작업을 방해하지 않습니다.

절제 실험(ablation)을 첫 단계로 여기기

하네스 구성 요소를 하나씩 끄고 품질 저하를 보는 것도 가능합니다. 이는 유용한 검사이지만 비싸고, 첫 단계가 아닙니다. 실패 기록이 먼저 병목을 보여 주고, ablation은 그 가설을 확인할 뿐입니다. 구성 요소를 껐을 때 하락이 0이라면 그것이 쓸모없다는 뜻은 아닙니다. 선택한 작업들이 그것을 쓰지 않았을 수 있습니다.

성숙도 사다리

마무리

AI 에이전트를 신뢰할 수 있게 만드는 방법은 이렇습니다: 측정하고, 실패 기록에서 약한 구성 요소를 찾고, 실수를 저렴하게 만들고, 피드백 루프를 닫고, 기억을 파일로 옮기고, 한 번에 한 작업만 하고, 실행자와 검증자를 분리하세요. 그 뒤에야 기계가 검증할 수 있는 종료 조건을 가진 자율 순환이 안전해집니다. 이 계획의 각 단계는 실제 프로젝트를 다루는 실습 과정에서 보여 줍니다.