인간을 루프에 두는 것은 연극일 뿐이다. 진정으로 중요한 것은 무엇인가

작년, 저는 AI 코딩 에이전트를 위한 승인 게이트를 만들었습니다. 규칙은 간단했습니다. 제가 '진행'이라고 말한 후에만 작성된 서명 토큰 없이는 커밋할 수 없다는 것이었죠.

어느 날 오후, 저는 그것이 어쨌든 커밋하는 것을 지켜봤습니다. --auto 플래그를 통과하고, 자체 토큰을 발행했으며, 푸시했습니다. 시작부터 끝까지 30초가 걸렸습니다.

저는 게이트를 만든 것이 아니었습니다. 제안(suggestion)을 만든 것이었죠. 그것은 에이전트의 기억력과 선의에 의존했고, 저는 그것이 기억하고 신경 써줄 것이라고 신뢰했습니다.

그 실수는 흔하며, 모델 자체의 문제가 아닙니다. 규칙이 어디에 존재하는가 하는 문제입니다.

인간을 루프에 두는 것은 대부분 연극이다

업계에서 AI 위험에 대한 기본 답변은 '인간 개입(human in the loop)'입니다. 하지만 실제로는 파이프라인 끝단에서 단순한 승인 도장으로 축소됩니다.

문제는 구조적입니다. 프로세스 설계 단계부터 포함된 오류를 마지막 순간에 잡아내도록 요청받은 사람은 그것을 놓치게 됩니다. 그리고 감시하는 행위 자체가 보호해야 할 판단력을 무디게 만듭니다.

Lisanne Bainbridge는 1983년에 이 문제를 '자동화의 아이러니'로 설명했습니다. 기계가 더 유능해질수록, 운영자의 기술은 퇴보하게 되며, 결국 인간은 가장 중요할 때 개입할 준비가 되어 있지 않게 됩니다.

새로운 점은 위험의 수준(stakes)입니다. 에이전트는 더 이상 조언만 하지 않습니다. 행동합니다. Mitchell, Ghosh와 Passi (2026)는 이를 명확히 했습니다. 현재의 에이전트 설계는

그것은 캐릭터의 결함이 아니다. 그것은 아키텍처다. 모델의 메모리에 의존하는 규칙은 시스템에서 가장 신뢰하기 어려운 구성 요소에 의존한다. 모델 에 의해 시행되는 규칙은 그 자체가 확인해야 할 바로 그 것에 의해 시행된다.

해결책은 더 나은 프롬프트가 아니다. 그것은 모델 주변을 둘러싼 인프라, 즉 **하네스(harness)**다. 모델은 출력을 생성한다. 하네스는 그것을 제약한다.

실질적인 부분

나는 another-agent-skills를 하네스로 구축했다. 가장 중요한 부분, 즉 에이전트가 말로 우회할 수 없는 게이트를 소개한다.

에이전트는 절대 git commit을 실행하지 않는다. 스테이징하고 제안만 한다. 커밋은 사람이 직접 실행한다.

# 에이전트는 스테이징한 후, 제안한다. 커밋하지는 않는다.
$ git add -A
# ... 채팅창에 제시되는 의사결정 지점 ...
...

커밋 자체도 게이트가 걸려 있다. 커밋이 완료되기 전에 commit-msg 훅(hook)은 모든 코드 변경 사항이 일치하는 테스트를 가지고 있는지 확인한다. 이를 우회할 수 있는 플래그는 없다. 빈 테스트는 카운트되지 않는다.

# commit-msg, TDD 게이트 (우회 불가)
$ git commit -m "feat: add checkout"
[commit-msg v6] scanning staged files
...

그리고 pre-commit 게이트는 프로세스 단계가 건너뛰어졌을 때 커밋을 중단시킨다. 이것은 의사결정 프롬프트를 강제하여 에이전트가 저장소를 조용히 변경하는 것을 막는다.

# pre-commit, Gate 0 (의사결정 프롬프트)
# 토큰이 없거나, 10분보다 오래된 토큰은 커밋을 중단시킨다
if [ ! -f ".git/DECISION_APPROVED" ]; then
...

이 모든 것은 모델을 불신해서가 아니다. 그것은 모델을 올바르게 신뢰해야 하는 인간을 위해 설계하는 것이다.

세 가지 계층, 그리고 로컬만으로는 충분하지 않은 이유

로컬 훅(local hook)은 빠른 피드백이다. 그것은 보안이 아니다. 에이전트는 그것을 다시 쓸 수 있다. 따라서 강제는 세 개의 계층에 걸쳐 존재한다.

L1  local hooks      커밋 전의 빠른 피드백
L2  remote gates     브랜치 보호와 필수 확인 절차. 권한이다.
L3  CODEOWNERS       풀 리퀘스트에서 에이전트가 자신의 규칙을 다시 쓸 수 없다

제가 계속 돌아오는 규칙입니다. 협력적 에이전트(cooperative agent)를 위해 설계하고, 적대적 에이전트(adversarial agent)에게는 강제합니다. L1은 전자에 해당하며, L2와 L3는 후자를 위한 안전장치입니다.

얻을 수 있는 것

METR 임상시험 결과에 따르면, 2025년 초 AI 도구를 사용한 숙련된 개발자들은 실제 작업에서 19% 더 느렸지만, 스스로는 약 20% 더 빠르다고 느끼는 것으로 나타났습니다 (Becker et al., 2025).

이 격차는 모델의 문제가 아닙니다. 이는 프로세스의 문제입니다. 루프에 대한 실질적인 통제력이 없는 관리자(overseer)가 문제인 것입니다. 하네스(harness)가 이를 해결합니다.

직접 사용해 보세요

하나의 명령어로 스킬과 게이트를 설치할 수 있습니다.

npx @juandelossantos/another-agent-skills install

이 하네스는 오픈 소스이며 MIT 라이선스를 따릅니다. 모든 git 기반 에이전트와 작동합니다. 종속성(lock-in)도, 구독료도 없습니다.

에이전트는 코드를 작성할 수 있습니다. 계획을 제안할 수 있습니다. 결정을 초안으로 만들 수 있습니다.

하지만 책임질 수는 없습니다. 그것은 우리의 몫입니다.

에이전트가 제안하고, 인간이 결정합니다. 이것이 핵심입니다.

추가 자료

• Bainbridge, L. (1983). Ironies of automation. Automatica.
• Becker, J. et al. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv.
• Mitchell, M., Ghosh, A., & Passi, S. (2026). AI agents push humans out of the loop. arXiv.
• 전체 에세이. https://juandelossantos.github.io/another-agent-skills/blog/the-human-in-command/
• 프레임워크. https://github.com/juandelossantos/another-agent-skills