에이전트에게 모든 걸 시키지 마라

요즘 AI 제품을 보면 한 가지 욕망이 반복된다.

모든 일을 agent에게 시키고 싶어 한다.

사람이 자연어로 명령하면 agent가 알아서 판단하고, 도구를 호출하고, 파일을 만들고, 메시지를 보내고, 결과를 보고한다. 이름은 계속 바뀐다. OpenClaw든 Hermes든, 또는 다른 agent framework든, 밑에 깔린 상상은 비슷하다.

업무 시스템을 만들지 말고 똑똑한 agent에게 맡기자는 상상이다.

그 상상은 매력적이다. 특히 데모에서는 강하다. 화면에 명령을 한 줄 넣었는데 여러 단계 일이 자동으로 굴러간다. 사람이 만든 폼, 버튼, 승인 플로우, 배치 시스템 같은 것들이 갑자기 구식처럼 보인다. 마치 MVC 웹앱을 만드는 대신 agent 하나가 운영팀, PM, 개발자, 회계팀 역할을 다 해줄 것처럼 느껴진다.

그런데 운영으로 들어가면 이야기가 달라진다.

업무의 대부분은 사실 창의적 판단이 아니다. 같은 입력이면 같은 출력이 나와야 한다. 실패하면 재현할 수 있어야 한다. 누가 언제 무엇을 바꿨는지 남아야 한다. 권한이 맞는지 확인해야 하고, 승인 없이 바뀌면 안 되는 값이 있어야 한다. 비용도 예측 가능해야 한다.

이런 일까지 agent에게 맡기면 생산성이 올라가는 게 아니라 시스템이 흐려진다.

어제는 A라고 판단했는데 오늘은 B라고 판단한다. 왜 실패했는지 로그를 봐도 “모델이 그렇게 생각했다” 이상으로 내려가기 어렵다. 같은 요청을 다시 넣으면 다른 실행 경로를 탄다. 비용은 요청마다 달라지고, latency도 흔들린다. 무엇보다 audit trail이 약해진다.

이건 AI가 나쁘다는 말이 아니다.

오히려 반대다. AI를 진짜 운영에 쓰려면 agent가 하지 말아야 할 일을 먼저 정해야 한다.

다시 웹앱이 중요해진다

여기서 낡아 보이는 구조가 다시 중요해진다.

MVC다. 웹앱이다. DB다. queue다. service object다. job이다.

AI 시대에도 Model은 필요하다. 오히려 더 중요해진다. Model은 상태와 정본을 잡는다. 고객, 주문, 계약, 티켓, 캠페인, 리포트, 승인 상태, 실행 이력 같은 것들이 모델로 남아야 한다. 그래야 시스템이 기억을 가진다.

Controller와 Service는 결정적 실행을 맡는다. 같은 input이면 같은 output이 나와야 하는 것들이다. 권한 체크, 정산 계산, 상태 전이, 알림 발송, 배치 실행, 외부 API write, 파일 생성 같은 것들은 코드가 해야 한다. 코드로 되어 있어야 테스트할 수 있고, 롤백할 수 있고, 감시할 수 있다.

View는 사람이 보는 운영 표면이다. agent가 결과를 냈더라도 사람은 그것을 검토하고 승인하고 수정할 수 있어야 한다. 좋은 View는 단순한 UI가 아니라 판단 표면이다. 무엇이 바뀌는지, 왜 추천됐는지, 어떤 근거가 있는지, 승인하면 어디에 write되는지 보여줘야 한다.

그럼 agent는 어디에 들어가는가?

Agent는 시스템 전체가 아니다. Agent는 판단 엔진이다. 더 정확히는 deterministic software 안에 꽂히는 비결정적 판단 layer다.

정산 금액 계산은 agent에게 맡기면 안 된다. 코드가 해야 한다. 하지만 “이 정산 건은 왜 이상해 보이는가?“를 설명하는 건 agent가 잘할 수 있다.

권한 체크는 코드가 해야 한다. 하지만 “이 요청은 어떤 정책에 걸릴 가능성이 있는가?“를 요약하는 건 agent가 잘할 수 있다.

고객 메시지 발송은 deterministic command가 해야 한다. 하지만 메시지 초안 작성은 agent가 잘할 수 있다.

이 차이를 놓치면 agent는 시스템을 강하게 만드는 대신 시스템의 경계를 흐린다.

반복되는 것은 코드로 졸업시켜라

AI 운영의 핵심은 agent에게 더 많은 일을 시키는 게 아니다.

반복되는 일을 agent에게서 빼앗는 것이다.

처음에는 agent가 분류해도 된다. 처음에는 agent가 판단해도 된다. 처음에는 agent가 수동 작업의 빈틈을 메워도 된다. workflow가 아직 불안정하고, 입력이 지저분하고, 사람이 어떤 기준으로 판단하는지도 확정되지 않았을 때 agent는 훌륭한 임시 운영자다.

하지만 같은 판단이 반복되기 시작하면 다른 질문을 해야 한다.

이건 아직 agent가 해야 하는 일인가?

아니면 이제 모델, 서비스, job, test, runbook으로 내려야 하는 일인가?

정산 계산은 코드가 해야 한다.

상태 변경은 service가 해야 한다.

반복 실행은 job이 해야 한다.

권한 검사는 policy가 해야 한다.

실패 감지는 monitor가 해야 한다.

회귀 방지는 test가 해야 한다.

예외 분류는 agent가 도울 수 있다.

긴 문서 요약은 agent가 잘한다.

초안 작성도 agent가 잘한다.

하지만 최종 write는 deterministic command와 audit log가 가져가야 한다.

이렇게 나누면 agent의 가치가 줄어드는 게 아니다. 오히려 커진다. agent가 모든 걸 직접 하려고 하면 매번 새롭게 판단해야 한다. 반대로 웹앱과 DB와 job이 기본 구조를 잡아주면 agent는 정말 애매한 구간에 집중할 수 있다. 그러면 비용도 줄고, 결과도 안정되고, 사람이 검토하기도 쉬워진다.

좋은 agent 시스템은 agent가 많은 시스템이 아니다.

Agent가 할 일과 하지 말아야 할 일이 명확한 시스템이다.

자연어 인터페이스는 정본이 아니다

많은 agent-first 제품이 헷갈리는 지점이 여기에 있다.

자연어 인터페이스를 업무 시스템이라고 착각한다.

자연어 명령은 interface일 수 있다. 아주 좋은 interface일 수도 있다. 사람이 복잡한 폼을 다 채우지 않고 “지난주 캠페인 성과 보고서 만들어줘”라고 말하는 것은 훌륭한 UX다.

하지만 그 말 자체가 정본은 아니다.

정본은 데이터 모델, 상태 전이, 승인 기록, 실행 로그, 테스트, runbook에 있다. agent가 채팅창에서 무언가 해냈다고 해서 그게 운영 시스템이 되는 것은 아니다.

운영 시스템은 같은 일을 다시 할 수 있어야 한다. 누가 실행했는지 보여야 한다. 어디까지 자동이고 어디서부터 사람 승인인지 분명해야 한다. 실패하면 어느 단계에서 실패했는지 보여야 한다. 그리고 더 중요한 것은, 한 번 배운 일이 다음 실행에 남아야 한다.

채팅창은 쉽게 흘러간다.

시스템은 남아야 한다.

Agent는 Controller가 아니다

그래서 나는 AI 제품을 만들 때 agent를 controller로 두는 설계가 위험하다고 본다.

Controller는 요청을 받아 정해진 규칙에 따라 상태를 바꾼다. 권한을 확인하고, 필요한 service를 호출하고, 실패하면 정해진 error path로 보낸다. 이 레이어가 비결정적이면 시스템 전체가 흔들린다.

Agent는 controller가 아니라 advisor에 가깝다. 또는 compiler, analyst, drafter에 가깝다. agent는 애매한 input을 구조화하고, 긴 context를 압축하고, 사람이 놓친 edge case를 제안하고, 다음 액션 후보를 만든다.

하지만 실행은 좁은 command로 내려야 한다.

approve_invoice

publish_post

send_email

sync_customer_record

create_followup_task

이런 command는 입력, 권한, validation, side effect, audit log가 정해져 있어야 한다. agent는 이 command를 직접 발명하는 것이 아니라, 가능한 command 중 어떤 것을 제안할지 판단해야 한다.

사람이 승인하면 deterministic system이 실행한다.

이 구조가 훨씬 강하다.

AI-native는 agent-native와 다르다

AI-native라는 말을 agent-native로 오해하면 안 된다.

AI-native 운영은 모든 일을 autonomous agent에게 맡기는 것이 아니다. 오히려 deterministic software와 judgment engine을 결합하는 것이다.

안정된 것은 코드가 한다.

불확실한 것은 agent가 돕는다.

그리고 불확실했던 것이 안정되면 다시 코드로 내려간다.

이 흐름이 진짜 compound다.

Agent가 같은 분류를 매번 반복하고 있다면, 그건 자동화가 덜 된 것이다. Agent가 같은 보고서를 매주 처음부터 만들고 있다면, 그건 모델과 query와 template이 아직 부족한 것이다. Agent가 같은 정책 판단을 계속 설명하고 있다면, 그건 rule, guard, UI state로 내려갈 준비가 된 것이다.

Agent의 반복 업무는 성공이 아니라 부채일 수 있다.

좋은 시스템은 시간이 갈수록 agent의 자유도를 무한히 키우지 않는다. 오히려 agent가 자유롭게 판단해야 하는 면적을 줄인다. agent가 다룬 예외를 관찰하고, 반복 패턴을 추출하고, 안정된 부분을 코드로 고정한다.

그러면 agent는 점점 더 어려운 판단으로 올라갈 수 있다.

사람도 마찬가지다. 좋은 조직은 사람이 매번 같은 양식을 다시 만들게 하지 않는다. 체크리스트, 템플릿, dashboard, workflow, 자동화로 내린다. AI 운영도 같다.

Agent가 직원처럼 일하는 듯 보여도, 진짜 목표는 직원 수를 늘리는 것이 아니다.

업무 시스템을 진화시키는 것이다.

결론

에이전트에게 모든 걸 시키지 마라.

같은 입력에 같은 출력이 필요한 일은 소프트웨어가 해야 한다. 상태를 바꾸는 일은 command와 service가 해야 한다. 반복 실행은 job이 해야 한다. 권한과 감사는 시스템이 잡아야 한다.

Agent는 그 위에서 판단을 돕는다. 애매한 것을 분류하고, 긴 것을 요약하고, 초안을 만들고, 예외를 설명하고, 다음 액션을 제안한다. 그리고 그 판단이 반복되면 다시 시스템으로 내려간다.

AI의 미래는 모든 걸 알아서 하는 agent 직원이 아니다.

AI의 미래는 deterministic software 안에 배치된 judgment engine이다.

참고:

• Anthropic, Building effective agents
• OpenAI, A practical guide to building agents
• Kieran Klaassen, Every, The Folder Is the Agent