하네스와 루프 — AI에게 일을 시키는 시스템 설계

AI 페어 프로그래밍

프롬프트를 고치지 말고 시스템을 고쳐라

하네스와 루프 — AI에게 일을 시키는 시스템 설계

핵심 요약

• AI가 실수하면 가장 흔한 대응은 프롬프트에 지시 한 줄을 얹는 것이다. 더 오래가는 대응은 같은 실수가 다시 일어날 수 없게 주변 시스템을 고치는 것 — 요즘 이걸 하네스(harness) 엔지니어링이라 부른다.
• 하네스 = 행동 전에 방향을 잡아주는 가이드 + 행동 후에 잘못을 스스로 알게 하는 센서. 지침(프롬프트)은 확률적으로 유도할 뿐이고, lint·테스트·권한은 기계적으로 강제한다.
• "될 때까지 반복"은 자동화가 아니라 비용이 드는 낙관이다. 반복이 개선이 되려면 외부 증거(verifier)·예산 상한·명시적 종료 조건이 필요하다.
• 좋은 자율 시스템은 오래 도는 시스템이 아니라, 오류가 빨리 드러나고 · 실패 비용이 제한되고 · 불확실할 때 멈추는 시스템이다.

1.지시 한 줄의 유혹

AI가 실수를 하면 누구나 같은 반사가 나온다. 지침 파일을 열고 "다음부터는 ~하지 마"를 한 줄 추가하는 것. 당장은 효과가 있는 것 같고, 실제로 얼마간은 효과가 있다. 문제는 이 대응이 쌓인다는 거다. 실수 하나에 한 줄씩, 지침 파일은 수백 줄이 되고 — 그때부터 다른 문제가 시작된다.

• 매번 로드되는 양이 늘어서 정작 중요한 규칙이 묻힌다.
• 오래된 규칙과 새 규칙이 서로 모순되기 시작한다.
• 어떤 규칙이 실제로 지켜지는지 측정할 방법이 없다.

그리고 더 근본적인 한계가 있다. 프롬프트는 확률적이다. "절대 하지 마라"라고 적어도 AI는 어길 수 있다 — 지침은 행동의 가능성을 높일 뿐, 무엇도 보장하지 않는다. 실수가 반복될 때 지시문을 "더 세게" 고쳐 쓰는 건, 안 잠기는 문에 "들어오지 마시오"를 더 큰 글씨로 붙이는 것과 같다. 필요한 건 더 큰 경고문이 아니라 자물쇠다.

2.하네스 — 실수를 시스템 개선으로 바꾼다

2026년 초, 몇몇 개발자와 회사들이 이 문제에 이름을 붙였다. AI가 실수할 때마다 프롬프트를 고치는 대신 그 실수가 다시 발생하지 않도록 주변 시스템을 개선하는 일 — 하네스 엔지니어링이다. 모델 자체는 못 바꾸지만, 모델이 일하는 환경은 전부 우리 손에 있다는 관점의 전환이다.

하네스는 두 축으로 이해하면 정확하다.

축	역할	예
가이드 (행동 전)	잘못된 방향을 미리 줄인다	지침 파일, 아키텍처 지도, 컨벤션 문서, 예제
센서 (행동 후)	잘못을 스스로 알게 한다	컴파일러, lint, 테스트, 스키마 검증, 스크린샷 비교

센서의 요점은 "AI가 스스로 알아차리게" 하는 것이다

사람이 결과물을 보고 잘못을 지적하면, 그 지적은 이번 대화에서만 유효하다. 반면 테스트나 lint가 잡으면 AI는 다음 행동을 하기 전에 실패를 보고 스스로 고친다 — 사람이 개입하기도 전에. 좋은 하네스에서 사람의 일은 매 실수를 잡아주는 게 아니라, 실수를 잡는 센서를 하나 더 만드는 것이다.

이 접근을 극단까지 밀어본 공개 사례도 있다. 한 대형 AI 회사 내부 팀은 사람이 코드를 거의 직접 쓰지 않는 실험에서 엔지니어 세 명이 다섯 달 동안 100만 라인 규모를 만들었다고 공개했다 — 사람의 역할은 코드 입력이 아니라 환경 설계, 의도 명세, 피드백 루프 구축으로 이동했다. 물론 통제 실험이 아니고 처음부터 AI 친화적으로 설계한 신규 프로젝트라 수치를 일반화할 수는 없다. 가져올 것은 숫자가 아니라 철학이다 — 같은 프롬프트를 더 세게 반복하기보다, 어떤 정보·도구·센서·제약이 빠졌는지 찾아서 재사용 가능한 시스템 개선으로 바꾼다.

3.프롬프트는 유도하고, 코드는 강제한다

그러면 실수를 겪었을 때 무엇을 어디에 적어야 하나. 기준은 간단하다 — 산문(prose)은 지도와 이유에 강하고, 코드는 강제와 빠른 피드백에 강하다. 모든 교훈을 항상 로드되는 지침 파일에 쌓는 대신, 이런 승격 경로를 태운다.

교훈의 승격 경로 — 아래로 갈수록 강한 보장원칙

일회성 지적            # "이번엔 이렇게 고쳐줘"
  → 반복되는지 관찰
  → 규칙 파일에 한 줄     # 해당 작업에서만 로드되게 (조건부 로드)
  → lint·테스트·스키마로 코드화   # 가능하다면 여기까지 — 어길 수 없음
  → 항상 로드되는 공통 지침은 조직 전체 불변식만

실제 겪은 예 하나. 우리가 쓰는 DB 마이그레이션 도구는 리비전 ID가 32자를 넘으면 기존 DB에선 멀쩡하고 새로 만든 DB에서만 부팅이 실패한다 — 로컬에선 절대 안 잡히고 새 환경에서만 터지는 고약한 함정이다. 처음엔 지침 파일에 "리비전 ID는 32자 이내로"라고 적었다. 하지만 이건 확률적 유도일 뿐이다. 그래서 리비전 ID 길이를 검사하는 테스트를 CI에 추가했다. 그 뒤로 이 실수는 재발하지 않는 게 아니라, 재발할 수 없게 됐다 — 어겨진 순간 CI가 빨간불로 알려주니까.

지침 파일 쪽도 그냥 두면 §1의 "지침 무덤"이 되므로 구조가 필요하다 — 항상 로드할 것과 파일 패턴별로 조건부 로드할 것을 나누는 실전 설정은 별도 글에서 다뤘다.

실전 가이드 →

AI에게 규칙을 한 번만 가르치는 법

지침 파일을 파일 패턴별 조건부 로드로 쪼개고, 함정을 learnings 파일에 쌓는 실전 설정 — CLAUDE.md · AGENTS.md · rules 디렉터리.

4.루프 — "될 때까지 반복"의 함정

하네스가 갖춰지면 자연스럽게 다음 욕심이 생긴다. "센서가 있으니, 통과할 때까지 알아서 반복하게 두면 되지 않나?" 2026년 들어 이런 반복 실행 설계를 루프(loop) 엔지니어링이라 부르기 시작했다 — 사람이 계속 프롬프트를 치는 대신, 프롬프트하는 시스템을 설계한다는 발상이다. 방향은 맞다. 하지만 가장 흔한 구현이 가장 위험하다.

⚠ "모델이 다 됐다고 할 때까지 반복"은 루프 엔지니어링이 아니다

AI가 자기 결과를 스스로 판정하게 두면 반복은 개선이 아니라 비용이 드는 낙관이 된다. 자기 답을 스스로 비평해서 고치는 방식은 신뢰할 만한 근거가 없고, AI 심판은 자기 출력과 비슷한 답을 선호하는 편향까지 있다는 게 연구들의 일관된 결론이다. 반복 횟수는 품질의 증거가 아니다.

연구들이 공통으로 가리키는 조건은 하나다 — 교정은 신뢰할 수 있는 외부 피드백이 있을 때 작동한다. 테스트, 타입 체크, 스키마 검증, 실제 실행 결과처럼 모델 바깥에서 오는 신호 말이다. 그래서 안전한 반복은 "무한 재시도"가 아니라 이런 모양이다.

안전한 반복의 공식원칙

안전한 반복
= 제한된 시도 횟수          # 3회 실패면 멈춘다 — 무한 재시도 금지
+ 외부 증거                # 테스트·타입·스키마·실행 결과가 판정한다
+ 예산 상한                # 토큰·시간의 하드 리밋
+ 이름 있는 종료 상태       # 성공 / 실패 / 판단 필요 를 구분한다
+ 사람에게 넘기는 조건       # 불확실하면 계속하지 말고 멈춰서 묻는다

repeat는 가장 쉬운 부분이다. 어려운 건 done과 safe를 거짓 양성 없이 정의하는 일이고, 루프 설계의 본체는 사실 그쪽이다.

5."완료"의 등급 — 검증 사다리

"AI가 완료했다고 한다"는 말에는 사실 여러 등급이 섞여 있다. 등급을 나누면 무엇을 자동화하고 어디에 사람을 둘지가 명확해진다.

등급	신호	어디까지 믿을 수 있나
V0	AI의 자기 보고 ("완료했습니다")	종료 후보일 뿐, 증거가 아니다
V1	다른 AI의 리뷰	누락 탐지에 유용하지만 편향이 있다
V2	타입·lint·스키마 검사	빠르고 결정적 — 단, 의미까지는 못 본다
V3	테스트 (단위·통합·회귀)	명시된 동작에 강하다 — 테스트 구멍은 존재
V4	실제 환경 실행 (브라우저·스테이징)	끝에서 끝까지 확인 — 비싸고 가끔 흔들린다
V5	사람의 판단	고위험·가치 판단에는 결국 필요하다

좋은 루프는 V2~V4를 자동화하고, V1과 V5를 위험도에 따라 배치한다. 뒤집어 말하면 — V0(자기 보고)을 종료 조건으로 쓰는 루프는 검증이 아니라 보고서 생성기다.

6.루프에 맡기기 좋은 일, 나쁜 일

같은 반복이라도 작업의 성격에 따라 루프 적합도가 극명하게 갈린다.

맡기기 좋은 일	맡기면 안 되는 일
CI 실패 분류와 로그 요약	"제품을 더 좋게 만들어라" 같은 열린 목표
깨진 링크·낡은 문서 검사	품질을 모델 스스로 판정해야 하는 작업
lint·테스트로 확인 가능한 작은 리팩터 제안	운영 DB·과금·메인 브랜치에 직접 쓰는 작업
의존성 업데이트 PR 초안 + 호환성 체크	흔들리는(flaky) 테스트 하나만 통과하면 되는 작업
읽기 전용 품질·보안 감사	사람이 이해하는 속도보다 빨리 코드를 쌓는 작업

왼쪽 열의 공통점을 뽑으면 그대로 체크리스트가 된다 — 성공과 실패를 외부 신호로 구분할 수 있고, 실패해도 피해가 작고 되돌릴 수 있으며, 작업 공간을 격리할 수 있다. 오른쪽 열은 하나같이 이 중 최소 하나가 빠져 있다.

7.하네스도 공짜가 아니다

여기까지 읽으면 하네스와 루프를 최대한 두껍게 쌓고 싶어진다. 균형을 위해 반대쪽 증거도 봐야 한다.

• 비용이 진짜로 든다. 한 공개 실험에서는 단일 실행이면 약 20분·9달러로 끝날 일이, 계획-생성-평가를 모두 갖춘 하네스 전체로는 6시간·200달러 이상이 들었다 — 결과 품질은 좋아졌지만, 그 차이가 항상 30배의 비용을 정당화하지는 않는다.
• 하네스도 퇴화한다. 새 모델이 나오면 예전 모델의 약점을 보완하려 만든 우회로와 스캐폴드가 불필요한 오버헤드가 된다. 하네스 규칙은 영구 진리가 아니라 측정 가능한 가설이다 — 모델 업그레이드마다 구성요소를 하나씩 빼보고(ablation), 가장 단순한 기준선과 다시 비교해야 한다.
• "결국 기존 공학의 재조합 아니냐"는 회의론도 있다 — 테스트, CI, 플랫폼 엔지니어링에 새 이름을 붙였을 뿐이라는 것. 상당 부분 맞는 지적이다. 다만 그게 약점이 아니라 요점이다(§8).

8.정리 — 가장 좋은 하네스는 평범한 공학처럼 보인다

하네스 엔지니어링의 결론은 화려하지 않다. 명확한 모듈 경계, 정확한 타입과 스키마, 빠른 테스트, 이해 가능한 에러 메시지, 재현 가능한 환경, 최소 권한, 작고 되돌릴 수 있는 변경 — 좋은 소프트웨어를 만들던 원칙 그대로다. 달라진 건 하나뿐이다. 이제 그 시스템을 읽고 고치는 행위자 중 하나가 비결정적인 AI라서, 그 원칙들을 더 명시적으로, 더 기계적으로, 더 측정 가능하게 만들 이유가 생겼다는 것.

그래서 한 문장으로 줄이면 — AI가 실수하면 프롬프트가 아니라 시스템에 적어라. 프롬프트는 잊히지만, 센서는 남는다.

바이브코딩 · AI와 더 잘 일하는 법