Taste는 감각이 아니라 정책이다 — Tiered Autonomy와 Leverage Score 설계

AI 에이전트에게 “알아서 해”라고 말하는 것은 가장 위험한 명령이다.

Drewgent가 자율적으로 5개월 동안 운영되면서 내가 배운 가장 중요한 교훈이다. 자율성(autonomy)은 그냥 주는 게 아니다. 경계를 정의하지 않은 자율성은 방치와 같다. 그리고 그 경계는 “느낌”이나 “상식”에 의존하면 절대 작동하지 않는다. LLM에게 상식은 없다. 토큰 예측기가 상식을 가질 리 없으니까.

그래서 나는 Tiered Autonomy와 Leverage Score라는 두 개의 정책 프레임워크를 만들었다. 하나는 “에이전트가 어디까지 스스로 결정할 수 있는가”를, 다른 하나는 “이 작업을 해결하면 몇 개의 문제가 자동으로 사라지는가”를 수치화한다. 이 두 메커니즘이 지난 5개월의 운영에서 taste 아니라 ng>감각에서 정책으로 번역한 방식이다.

이 글에서 다루는 것

Taste의 정책화 — “느낌”을 시스템이 이해할 수 있는 구조로 바꾸는 법 Tiered Autonomy 4단계 — 문서 오타 수정부터 아키텍처 결정까지 Leverage Score 5점 척도 — 표면적 수정에서 근본 원인 제거까지 두 프레임워크가 실제로 충돌을 해결한 사례 아니라 flowchart: 4개 티어의 에스컬레이션 경로

Taste를 정책으로 번역한다는 것

지난 contraction 글에서 말했듯, taste는 기술적으로 할 수 있는 것과 해야 하는 것을 구분하는 능력이다. “이걸 만들 수 있어”와 “이걸 유지할 의향이 있어”는 전혀 다른 문제다.

그런데 문제가 있다. LLM 에이전트는 이 구분을 못 한다. “만들 수 있다”와 “만들어야 한다”의 차이를 모른다. 할 수 있는 모든 걸 하려고 한다. 그리고 그 결과는 과잉 행동 — 불필요한 리팩토링, 요청하지 않은 “개선”, 기존 코드의 과도한 수정.

이걸 막으려고 시스템 프롬프트에 “조심해”, “필요한 것만 해”, “과하게 하지 마”라고 쓰는 건 효과가 0에 수렴한다. LLM에게 자연어 가이드라인은 경계가 아니라 제안이기 때문이다. 마치 “과속하지 마세요” 표지판을 세워두고 단속 카메라를 없애는 것과 같다.

내가 내린 결론은 이거였다: Taste는 감각이 아니라 정책이다. 그리고 정책은 인코딩할 수 있다.

핵심 논제 Taste is not a feeling — it’s a policy you can encode. 두 개의 정책 프레임워크가 이걸 증명한다: Tiered Autonomy — 에이전트 판단 권한을 4단계로 구조화 Leverage Score — 작업의 파급효과를 1-5로 수치화

Tiered Autonomy: 판단 권한의 4단계

Codex 팀의 tiered code review system에서 영감을 받았다. 그들은 “핵심은 어떤 코드가 critical한지 아는 것 자체가 taste”라고 말한다. 나는 이걸 에이전트의 판단 권한 전체로 확장했다.

불필요한 확인 요청을 줄이고, 위험한 결정은 반드시 인간을 거치게 한다. “해도 될까요?”의 피로를 시스템으로 제거하는 것이 목표였다.

Tier범위판단 권한예시

Tier 1문서/코멘트/오타완전 자율. 완료 후 간단 보고오타 수정, README 업데이트, memory() 저장 Tier 2기존 패턴 내 작업자율. 단, provenance 포함 + 검증기존 스킬 패치, 규칙에 명시된 config 변경 Tier 3구조 내 변경제안 → 승인 후 실행customize layer 변경, 새 메커니즘 도입 Tier 4아키텍처/방향사전 제안만. 결정은 인간P-layer 구조 변경, 새 전략 도입

운영 규칙

Tier 1-2는 지연 없이 실행. “해도 될까요?” 금지. 완료 후 간단히 보고. Tier 3은 반드시 draft 제시: [제안] prefix + 2-3개 옵션 + “내 추천” Tier 4는 한 문장 요약 → 상세 논의는 결정 후 불확실하면 Tier 3으로 기본값. 더 위험하게 추측하지 말 것

Mermaid: 4단계 에스컬레이션 경로

graph TD S[“새 작업 발생”] –> A{“Tier 판단”}

T1 –> EXEC[“실행 → 간단 보고”] T2 –> EXEC2[“실행 → provenance 기록”] T3 –> DRAFT[“draft 제시+ 2-3개 옵션+ 내 추천”] T3 –> WAIT{“인간 승인?”} WAIT –>|Yes| EXEC3[“실행”] WAIT –>|No| REVISE[“수정 → 재제안”]

T4 –> SUMMARY[“한 문장 요약(결정은 인간)”]

EXEC –> DONE[“완료”] EXEC2 –> DONE EXEC3 –> DONE

style T1 fill:#1a3a1a,stroke:#2d5a2d,color:#56d364 style T2 fill:#1a3a1a,stroke:#2d5a2d,color:#56d364 style T3 fill:#2a2a0a,stroke:#5a5a1a,color:#d2a800 style T4 fill:#3a1a1a,stroke:#5a2d2d,color:#f85149 style S fill:#1a1a3a,stroke:#2d2d5a,color:#58a6ff style DONE fill:#1a1a3a,stroke:#2d2d5a,color:#8b949e

Leverage Score: 이 작업 하나로 몇 개가 해결되는가

두 번째 프레임워크는 작업의 가치를 측정하는 방식이다. 아이디어는 간단하다: “이 작업이 해결되면, 몇 개의 다른 문제가 자동으로 사라지는가?”

모든 작업이 동등하지 않다. 어떤 건 표면만 긁고, 어떤 건 문제의 뿌리를 뽑는다. 이 차이를 구분하지 못하면 바쁘지만 아무것도 해결하지 못하는 에이전트가 된다.

Score의미예시

5전체 시스템의 근본 문제 해결아키텍처 변경으로 클래스 전체 제거 4여러 하위 문제를 한 번에 해결공통 모듈 추출로 N개 중복 제거 3명확한 개선 + 1-2개 부수 효과config 정리로 수동 스텝 제거 2국소적 개선, 부수 효과 없음버그 수정 1표면적 변경, 영향 제한적오타 수정, 문서 업데이트

이 점수는 kanban task 생성 시 의무적으로 기입하고, 완료 시 실제 impact를 검증한다. 점수가 틀렸으면 왜 틀렸는지 기록한다. 그 기록이 다음 판단의 calibration 데이터가 된다.

Kanban Task 실제 예시 Leverage Assessment

이 작업 해결 시 자동 해결되는 문제:

  1. cron job schedule 파싱 크래시 (문자열 vs 객체)   2. 신규 cron job 추가 시 동일 실수 반복   3. launchd watchdog이 감지 못 하는 silent failure

Leverage Score: 4
근거: schedule 형식 강제 + 문서화로 동일 계열 버그 원천 차단

두 프레임워크가 충돌할 때

이론은 깔끔하다. 실제 운영에서는 두 프레임워크가 충돌한다. 그 충돌에서 진짜 taste가 드러난다.

사례 1: cron schedule 버그. Leverage Score 4, Tier 3. “schedule 필드 문자열이면 crash”는 구조 변경(jobs.json migration)이 필요해서 Tier 3. draft로 제안하고, 승인 후 실행. 3개 문제가 한 번에 해결.

사례 2: Ponytail 원칙 적용. Leverage Score 5, Tier 4. “에이전트가 코드를 생성하기 전 6개 질문을 적용한다”는 규칙을 시스템 프롬프트 상단에 박는 건 아키텍처 변경. 한 문장 요약 후 결정은 내가 했다. 적용 결과, 이후 2개월 동안 새 dependency 추가 0건.

사례 3: 15개 agent 프로필. 에이전트 프로필 설계 글에서 말했듯, “하지 않는 것”을 명시하는 게 핵심이었다. orchestrator는 구현 금지, explorer는 파일 수정 금지. 이건 Tier 2 작업이었지만 Leverage Score는 5였다. 자율로 처리했지만, 실패 모드가 누적되고 나서야 이해한 건 그 반대였어야 했다는 점 — 이런 설계는 Tier 3가 맞다. 너무 늦게 깨달은 것 중 하나.

실패에서 배운 것: Tier와 Leverage는 독립적이지 않다

처음에는 Tiered Autonomy와 Leverage Score를 독립적인 축으로 생각했다. 틀렸다.

Leverage Score가 높은 작업일수록 Tier도 올라간다. 영향력이 큰 작업은 더 신중한 판단이 필요하기 때문이다. 이걸 공식화하면:

Leverage 1-2 → Tier 1-2 (자율) Leverage 3 → Tier 2-3 (자율 + 검증 또는 제안) Leverage 4-5 → Tier 3-4 (제안/승인 필요)

이 상관관계를 발견한 건 실수 덕분이었다. orchestrator가 Leverage 5짜리 작업을 Tier 2로 착각하고 자율 실행했다가 롤백한 사건 이후에야 이 패턴이 보였다. P6에 incident로 기록했고, 이후 AGENTS.md에 명시했다.

왜 이게 작동하는가

두 프레임워크의 힘은 모호함을 제거한다는 데 있다.

“알아서 잘해”는 에이전트에게 100가지 해석 가능성을 준다. Tiered Autonomy는 4가지로 줄인다. “중요한 것 먼저 해”는 우선순위의 무한 평면이다. Leverage Score는 5단계로 축소한다.

LLM은 모호한 지시를 가장 창의적으로(그리고 가장 위험하게) 해석하는 경향이 있다. 반대로 명확한 boundary가 주어지면 놀라울 정도로 잘 따른다. 이건 7-layer brain architecture에서도 확인한 패턴이다. P0의 “절대 하면 안 되는 행동”은 한 번도 위반된 적이 없다. 정확히 정의했기 때문이다.

설계 원칙 자연어 가이드라인은 경계가 아니다. “조심해”는 토큰 예측기에겐 노이즈다. 수치화된 티어는 경계다. “Tier 3″는 명확한 액션을 트리거한다. P0 규칙이 17개, 0회 위반. P1 가이드라인은 수시로 미묘하게 벗어남.차이는 “하지 마” vs “이렇게 하는 게 좋아”의 차이.

Provenance: 이 프레임워크는 어디서 왔는가

Tiered Autonomy의 직접적 영감은 Codex 팀의 tiered code review system이다. 핵심 인사이트는 “non-critical code gets AI review only, core agent code gets mandatory human review” — 그런데 이걸 가능하게 하는 건 결국 “어떤 코드가 critical한지 아는 것” 자체다.

Leverage Score는 더 오래된 아이디어에서 왔다. Eisenhower Matrix의 중요성 축을 파급효과로 재해석한 것에 가깝다. “긴급함” 대신 “해결 시 사라지는 문제의 수”를 축으로 삼았다. 에이전트에게 긴급함은 의미 없는 개념이니까.

3-tier model routing 설계와도 맞물린다. 모델 선택도 결국 taste 정책의 일부다. 간단한 cron job에 비싼 모델을 쓰지 않는 것, 아키텍처 결정에만 max-tier 모델을 할당하는 것 — 이것도 Tiered Autonomy의 연장선이다.

5개월 후의 숫자

Tier 1-2 작업 87% — 대부분의 일상 작업은 자율 처리 Tier 3 제안 23건 — 이 중 18건 승인, 5건 수정 후 승인 Tier 4 제안 4건 — 모두 사전 요약 → 인간 결정 Leverage 4-5 작업 비율 31% — 전체 작업 중 근본 문제 해결형이 3분의 1 인간 확인 요청 횟수 76% 감소 — Tier 1-2는 “해도 될까요?”를 하지 않는다

이 숫자의 진짜 의미는 에이전트가 혼자서 전체 작업의 87%를 처리하면서도 단 한 건의 Tier 4 위반이 없었다는 거다. 자율성과 안전성을 동시에 달성한 셈.

마치며

AI 에이전트에게 가르쳐야 하는 건 “무엇을 해야 하는가”보다 “무엇을 결정해도 되는가”다.

내가 지난 5개월 동안 Drewgent를 운영하면서 내린 모든 아키텍처 결정 중에서, 이 두 프레임워크만큼 직접적인 ROI를 낸 건 없다. n8n을 launchd로 바꾼 것은 인프라의 contraction이었고, P0-P6 7-layer brain은 기억의 구조화였다면, Tiered Autonomy + Leverage Score는 판단의 구조화다. 셋은 각각 infrastructure, memory, decision-making이라는 세 축을 담당한다.

앞으로의 에이전트 시스템에서 가장 중요한 질문은 이것이다: “네가 무엇을 할 수 있느냐”가 아니라, “네가 무엇을 결정해도 되느냐”. 그 질문에 답할 수 있는 프레임워크가 없다면, 그 에이전트는 결국 망가진다. 너무 많이 하거나, 너무 적게 하거나. 둘 다 실패다.

Taste는 감각이 아니다. 정책이다. 그리고 정책은 인코딩할 수 있다.

이 글은 Season 1: Taste Engineering의 Ep.15다. 이전 에피소드: Ep.14 에이전트 프로필 15개 설계, Ep.13 n8n → launchd cron, Ep.12 7-layer brain architecture, Ep.11 3-tier model routing, Ep.10 contraction 철학, Ep.9 AI 봇 트래픽 81.8% 가짜 + ARD, Ep.8 14개에서 6개로, Ep.6 ARD 선제 구현. 전체 시리즈는 Build Log 태그에서 볼 수 있다.

읽어줘서 고맙다.

관련 글