자동 트레이딩에 모든 걸 맡겼다가 0승 8패, 자산 3%를 날렸다.

AI가 써준 블로그 글을 검수 없이 자동 발행했다가 독자한테 “이거 AI가 쓴 거죠?”라는 댓글을 받았다.

둘 다 같은 실수다. 도메인 지식 없이 AI에게 판단을 넘긴 것.

두 번의 실패

첫 번째 실패는 자동 트레이딩이다. AI가 생성한 트레이딩 코드를 그대로 배포했다. 해당 시장의 도메인 지식이 없었기 때문에 코드가 말이 되는지 검증할 수 없었다. 결과는 8연패.

두 번째는 블로그 자동 발행이다. trending repo에서 주제를 뽑고, AI가 draft를 쓰고, 사람 검토 없이 publish했다. 부정확한 정보가 포함된 글이 그대로 올라갔고, 독자들은 바로 알아챘다.

이 두 실패의 교훈은 단순하다: 자동화를 할 수 있다고 해서 판단까지 자동화할 수 있는 건 아니다.

핵심은 “어디까지 AI가 결정하고, 어디까지 내가 결정하는가”

이 문제를 Drewgent에서 풀 때 만든 프레임워크가 Tiered Autonomy다. 모든 작업을 위험도에 따라 네 계층으로 나누고, 계층별로 AI의 자율권을 다르게 설정한다.

Tier범위AI의 권한예시

1문서, 코멘트, 오타자율 실행. 완료 후 보고README 업데이트, memory 저장, skill 문서화 2기존 패턴 내 작업자율 실행 + provenance 포함기존 스킬 패치, config 변경, AGENTS.md 업데이트 3구조 내 변경제안 → 승인 후 실행customize layer 변경, 새 메커니즘 도입, skill 구조 변경 4아키텍처, 방향사전 제안만. 인간이 결정P-layer 구조 변경, 새 전략 도입, fork/repot 결정

자동 트레이딩은 Tier 4다. 블로그 자동 발행은 적어도 Tier 3다. 그런데 둘 다 Tier 1처럼 다뤘다. 모든 결정을 AI에게 넘기고, 검증하지 않았다.

왜 Tier가 중요한가

Tier의 핵심은 실패 비용에 따라 의사결정 게이트를 다르게 두는 거다.

Tier 1은 실패해도 비용이 미미하다. 오타 하나 틀린다고 시스템이 죽지 않는다. Tier 4는 실패하면 전체 방향이 틀어진다. 그래서 AI는 “이렇게 하는 게 좋을 것 같다”는 제안만 하고, 최종 결정은 내가 한다.

중요한 건 대부분의 실패가 Tier를 착각하는 데서 온다는 점이다. “이 정도는 AI가 알아서 해도 되겠지”라고 생각한 작업이 실제로는 Tier 3-4였던 경우다. 자동 트레이딩도, 블로그 자동 발행도 정확히 여기서 실패했다.

자동화할 수 있는가? → 기술적 질문 판단을 넘겨도 되는가? → 전혀 다른 질문

많은 사람이 첫 번째 질문만 하고 두 번째는 건너뛴다. 거기서 사고가 난다.

Drewgent에서 Tier가 작동하는 방식

Drewgent는 15개 에이전트 프로필을 쓰고 있다. explorer, implementer, reviewer, orchestrator, content-manager, security-reviewer… 각 프로필은 Tier별 권한을 내장하고 있다.

예를 들어 content-manager는 Tier 1-2 자율권을 가진다. draft 작성, SVG 커버 생성, WordPress publish까지 하고 “다 썼으니 확인해”라고만 알려준다. 반면 배포 파이프라인을 건드리는 sre나 아키텍처 결정을 건드리는 reviewer-critical은 Tier 3-4에서만 움직인다. 직접 변경하지 않고 보고만 한다.

실전에서는 이렇게 돌아간다:

Tier 1-2: content-manager가 자율 실행

→ draft 작성 → SVG 커버 생성 → WordPress publish

Tier 3: sre가 진단 보고만, 변경은 제안

→ launchd 상태 체크 → “이 서비스가 반복적으로 죽고 있습니다” → 제안: “KeepAlive ThrottleInterval을 10→30으로 조정할까요?”

Tier 4: 아키텍처 결정

→ orchestrator: “P7 레이어를 추가할까요?” → 나: “아니, 7개로 충분해”

Tier를 시스템에 박아넣는 방법

처음 Drewgent를 만들 땐 나도 “AI한테 최대한 많이 맡기자”였다. 그게 더 효율적일 거라고 생각했다. 틀렸다.

Tiered Autonomy는 그 반대에서 출발한다: 무엇을 AI에게 맡기지 않을 것인가를 먼저 정한다. 그리고 그걸 시스템 프롬프트가 아니라 구조로 강제한다. 프롬프트에 “중요한 결정은 하지 마”라고 쓰는 건 효과가 없다. 대신:

에이전트 프로필별 권한 경계 — sre는 read-only first, content-manager는 publish 권한 보유 orchestrator의 “구현 금지” 규칙 — PM이 직접 코딩하지 않는 것과 같은 원리 reviewer 파이프라인 — Tier 3 이상 변경은 반드시 reviewer-critical 통과 kanban_block() — 모호한 태스크는 자동으로 인간 검토 대기로 전환

이게 중요한 이유는 AI의 판단 능력이 문제가 아니라, 실패 비용이 비대칭적이기 때문이다. AI가 100번 중 99번 맞춰도, 나머지 1번이 Tier 4 실수면 모든 걸 망친다. 자동 트레이딩 8연패처럼.

“도메인 지식은 선택이 아니다”

두 번의 실패에서 배운 건 결국 이거다.

트레이딩 코드를 검증할 도메인 지식이 없었다. 그래서 “이 로직이 말이 안 된다”는 걸 알아채지 못했다. 블로그 콘텐츠를 검증할 편집 경험이 부족했다. 그래서 부정확한 정보가 그대로 나갔다.

AI를 써서 자동화할 때 도메인 지식은 옵션이 아니다. 오히려 AI를 쓸수록 더 많은 도메인 지식이 필요하다. 검증해야 할 표면적이 넓어지기 때문이다.

Tiered Autonomy는 이걸 시스템으로 번역한 거다: “내가 도메인 지식을 가진 영역(Tier 1-2)은 자율화하고, 그렇지 않은 영역(Tier 3-4)은 게이트를 둔다.”

마치며

AI 자동화 도구는 매주 쏟아져 나온다. Cursor, Devin, Bolt, Replit Agent… 하나같이 “AI가 모든 걸 해준다”고 말한다.

그 말은 절반만 맞다. AI가 할 수 있는 건 늘고 있다. 하지만 판단을 넘겨도 되는 범위는 훨씬 느리게 는다. 속도 차이가 벌어질수록, 그 간극을 메우는 건 도메인 지식이다.

AI에게 주도권을 빼앗기지 말고, Tier를 설계하라.

Season 1 “Taste Engineering”. 에이전트 프로필 설계와 launchd cron 이관에 이어, 이번 글은 자동화와 판단의 경계에 대한 이야기였다.