프런트엔드 AX 설계기 8편 - 자율 모드에서 설계한 건 자동화가 아니라 멈추는 지점이었다

에이전트에게 "이 기능, 한 번에 끝까지 끝내줘"라고 시키고 싶었다. goal 하나를 던지면 구현부터 검증까지 알아서 도는 end-to-end 패턴은 이미 손에 익었고, 남은 욕심은 "매 단계 확인을 그만 받고 싶다"였다. 그래서 /feature 커맨드에 --auto 플래그를 붙였다. 그런데 붙이자마자 첫 실행이 엉뚱한 데서 멈췄다. 격리 작업공간(worktree)을 만들 권한이 없다는 것이었다. 폴더 하나 만드는, 언제든 되돌릴 수 있는 일 앞에서 파이프라인이 손을 든 것이다. 그 순간 질문이 뒤집혔다. 문제는 "어디까지 자동화하나"가 아니라 "어디서 멈춰 사람에게 넘기나"였다.

이 글은 그 뒤로 --auto의 권한 경계를 다시 그은 작업기다. AI에게 자율 실행을 맡겨보려는 사람이라면 같은 벽을 만난다 — 다 맡기자니 무섭고, 매번 확인받자니 자율이 아니다. 결론부터 말하면, 안전한 무인 실행은 "끝까지 실행"이 아니라 되돌릴 수 있는 일과 발행을 다른 권한으로 가를 때만 가능했다. (2026년 중반 워크플로이고 도구 동작은 자주 바뀌니, 규칙보다 경계 긋는 방식을 가져가시길.)

되돌릴 수 있는 일과 발행은 같은 권한이 아니다

--auto가 사람 확인 없이 실행해도 되는 일은 딱 하나의 성질을 만족했다. 되돌릴 수 있을 것. 파일을 고치고, 격리 작업공간을 만들고, 테스트를 돌리는 일은 전부 git이나 삭제로 되돌릴 수 있다. 잘못돼도 흔적을 지우면 그만이다. 반면 branch를 만들고 commit 하고 push 하고 PR을 열고, 완료된 작업을 아카이브로 옮기는 정리 작업은 성질이 다르다. 한번 밖으로 나가면 남의 눈에 들어가거나, 되돌리는 데 또 다른 공개 작업(revert)이 필요하다. 앞을 reversible work, 뒤를 발행(publishing)이라 부르고, --auto는 앞만 pre-authorize 하도록 못 박았다.

 

처음엔 이 구분이 없었다. 그래서 worktree 생성 앞에서 멈췄던 것이다 — 되돌릴 수 있는 준비 작업을, 발행과 똑같이 "위험" 칸에 넣어둔 탓이었다. carve-out을 하나 넣어 되돌릴 수 있는 셋업은 흐르게 하고, 발행만 게이트에 세웠다. 그러자 --auto는 구현에서 검증까지 쉬지 않고 달리다가, PR을 여는 문 앞에서 정확히 한 번 멈춰 나를 불렀다. 자동화한 범위가 넓어진 게 아니라, 멈추는 지점이 정확해진 것이다.

경계를 파일로 못 박기

경계를 머릿속에만 두면 다음 세션에서 또 흔들린다. 그래서 정책을 파일로 고정했다. 아래는 그대로 복사해 출발점으로 쓸 수 있는 --auto 권한 정책이다.

# /feature --auto 권한 정책 (설정 파일 발췌)
auto:
  # 되돌릴 수 있는 일 — 사람 확인 없이 실행한다
  pre_authorized:
    - implement            # 파일 편집·구현·수정
    - worktree_setup       # 격리 작업공간 생성 (되돌릴 수 있어 멈추지 않음)
    - run_tests            # 검증 게이트

  # 되돌릴 수 없는 발행 — 항상 사람 게이트 앞에서 멈춘다
  gated:
    - branch_create
    - commit
    - push
    - open_pr
    - completion_cleanup   # 완료 작업 아카이브 이동·정리

  review_loop:
    max_rounds: 3          # 무한 루프 상한
    loop_on: [CRITICAL, WARNING]
    # edge case ①: 라운드 사이에 CRITICAL이 strictly decrease 하지 않으면
    # (정체하거나 늘면) 상한에 닿기 전에 멈추고 사람에게 escalate 한다
    regression_guard: strict_decrease

  pre_pr_loop:
    loop_on: [lint, type, format]   # 발행 직전엔 기계적 검사만 반복

  drift:
    # edge case ②: 발산·Non-goals 위반은 자동수정하지 않는다
    divergent: stop_for_human
    non_goals_violation: stop_for_human
    missing: warn                   # 비차단 경고

주석에 붙인 edge case 두 줄이 이 글의 나머지 절반이다. 하나는 "라운드를 아무리 돌아도 CRITICAL이 안 줄면 어쩌나", 다른 하나는 "발산은 자동으로 고쳐도 되나". 순서대로 풀어본다.

무한 루프를 막는 건 상한만이 아니었다

자율 모드의 다음 위험은 발행이 아니라 루프였다. 에이전트가 자기 코드를 리뷰하고, 지적을 스스로 고치고, 다시 리뷰하는 수렴 루프를 돌게 했는데 — 이게 안 멈출 수 있다. 그래서 루프를 두 갈래로 좁혔다. 리뷰 수렴은 CRITICAL·WARNING에서만 돌고, 발행 직전(pre-pr) 루프는 lint·type·format 같은 기계적 검사에서만 돈다. 그리고 어느 쪽이든 max 3 rounds에서 끊는다.

상한만으로 충분한 줄 알았다. 아니었다. 어려운 문제에서 에이전트는 라운드마다 CRITICAL을 줄이기는커녕, 한 지적을 고치며 다른 걸 깨서 오히려 늘렸다. 상한 3에 닿을 때까지 "고치는 척 퇴행"만 세 번 반복한 셈이다. 그래서 상한 위에 regression guard를 얹었다. 라운드 사이에 CRITICAL 개수가 strictly decrease — 반드시 줄어야 함 — 하지 않으면, 정체하거나 늘면 그 자리에서 자동수정을 멈추고 사람에게 escalate 한다.

 

이건 감이 아니라 운영에서 나온 관찰이다. hard problem에서 자율 fix-loop는 수렴이 아니라 퇴행할 수 있다는 걸 몇 번 보고 나서야 가드를 넣었다. "몇 라운드 돌았나"가 아니라 "나아지고 있나"를 기준으로 바꾼 순간, 루프는 스스로 멈출 줄 알게 됐다.

어떤 실패는 애초에 자동으로 고치면 안 됐다

마지막 경계는 실패의 종류였다. spec과 구현이 어긋나는 drift를 검사할 때, 모든 어긋남을 자동수정 대상으로 두면 안 됐다. 종류를 갈랐다. 구현이 spec과 정면으로 어긋나는 divergent나, 하지 않기로 한 것(Non-goals)을 건드린 경우는 자동수정 금지, 사람 판단으로 정지. 반대로 아직 구현되지 않은 부분이 남았다는 missing은 비차단 경고(WARN)로만 남기고 진행한다.

 

핵심은 어긋남을 severity 숫자가 아니라 "이걸 기계가 판단해도 되나"로 나눈 것이다. divergent와 Non-goals 위반은 "의도"의 문제라 사람만 판단할 수 있다. missing은 "진행도"의 문제라 경고만으로 족하다. 자동화가 손대도 되는 실패와 그렇지 않은 실패를 미리 갈라두지 않으면, --auto는 좋은 의도로 잘못된 방향을 더 빨리 밀어붙인다. 자율 모드에서 가장 위험한 건 멈춤이 아니라, 잘못된 방향으로의 가속이다.

정리하며

무인 실행의 설계는 "무엇을 자동화하나"가 아니라 "어디서 멈추나"다. 되돌릴 수 있는 일은 끝까지 맡기고, 발행·발산·Non-goals 위반은 사람 앞에 세운다. 그리고 루프는 "몇 번 돌았나"가 아니라 "나아지고 있나"로 끊는다.

지금 자율 실행을 붙이려는 커맨드가 있다면, 자동화 목록을 짜기 전에 딱 두 칸짜리 표부터 그려보라 — 왼쪽엔 되돌릴 수 있는 일, 오른쪽엔 되돌릴 수 없는 발행. 오른쪽은 전부 사람 게이트로 시작하고, 필요할 때만 하나씩 왼쪽으로 옮겨라.

결국 --auto가 설계한 건 자동화가 아니라 사람과 에이전트 사이의 인터페이스였다. 어디까지 맡기고 어디서 손을 넘길지, 그 경계를 정하고 정합하게 유지하는 일은 화면의 버튼을 어디까지 눌리게 할지 정하던 그 craft와 다르지 않다. 표면이 사람에서 에이전트로 하나 늘었을 뿐이다.

 

2026.07.01 - [AI 엔지니어링] - 프런트엔드 AX 설계기 7편 - 게이트를 속이는 AI를 차단 없이 잡기