요즘 Agent 이야기를 보다 보면 꽤 자주 만나는 주장이 있다. Claude Code나 Codex 같은 Agent가 코드를 만들고, API를 찾아 호출하고, 실패하면 스스로 고쳐 다시 실행하는데 이제 n8n 같은 Workflow 도구가 왜 필요하냐는 이야기다.
처음 들으면 그럴듯하다. 실제로 나도 사람이 Node를 하나씩 놓고 조건을 연결하던 작업의 상당 부분은 Agent가 대신하게 될 것이라고 본다. n8n도 2026년 Assistant에서 자연어로 Workflow를 만들고 실행하고 고치는 방향으로 갔고, Agents에서는 Agent가 기존 Workflow를 Tool로 사용할 수 있게 했다. 제품 자체가 이미 “Agent냐 Workflow냐”보다 둘을 어떻게 같이 쓸지를 향하고 있다.
그런데 이 논쟁에는 조금 더 큰 착각이 섞여 있다.
n8n은 화면에 Node가 보일 뿐 결국 Code다. Trigger가 있고, Condition이 있고, Branch가 있고, Credential과 API Call, Retry와 Error Handling이 있다. Make나 Zapier도 본질적으로 크게 다르지 않다. 같은 것을 TypeScript나 Python, Java/Spring, Step Functions나 Temporal로 작성하면 화면 모양만 달라진다.
그래서 “Agent가 n8n을 대체한다”는 말을 끝까지 밀어붙이면 질문이 바뀐다.
Agent가 Workflow를 작성할 수 있다는 사실은, Workflow가 가지고 있던 실행 규칙까지 필요 없어졌다는 뜻일까?
나는 그렇지 않다고 본다. 특히 Enterprise에서는 더 그렇다.
Workflow를 작성하는 노동과 Workflow의 의미는 다른 문제다
먼저 무용론에서 맞는 부분부터 인정할 필요가 있다.
Workflow Authoring의 비용은 크게 줄어들 가능성이 높다. 예전에는 사람이 요구사항을 읽고 Trigger를 정하고, API Node를 고르고, 조건 분기를 만들고, 실패 경로를 붙였다. 이제는 “새 Lead가 들어오면 담당자를 찾아 CRM에 넣고 Slack으로 알려줘”라고 말하면 Agent가 상당 부분을 만들어낼 수 있다.
Anthropic도 Agentic System을 설명하면서 Workflow를 predefined code path로, Agent를 모델이 자신의 process와 tool usage를 동적으로 결정하는 구조로 구분한다. 그리고 well-defined task에서는 Workflow가 주는 predictability와 consistency가 여전히 유효하다고 설명한다. Building Effective Agents
즉 사람이 Workflow를 손으로 작성해야 하는 이유는 줄어들 수 있다.
하지만 이것은 다음 세 가지가 같은 문제라는 뜻은 아니다.
- Workflow Authoring — 실행 구조를 누가 만드는가
- Semantic Planning — 상황을 해석하고 다음 행동 후보를 누가 고르는가
- Execution Semantics — 실제 업무 상태를 어떤 규칙으로 바꾸는가
Agent는 앞의 두 영역을 빠르게 흡수하고 있다. 문제는 세 번째다.
Enterprise 업무는 Task List보다 Shared State에 가깝다
Enterprise 시스템을 오래 보다 보면 업무가 단순히 “A를 하고 B를 한다”의 목록으로 움직이지 않는다는 것을 알게 된다.
Salesforce의 Opportunity를 생각해보자. Prospecting에서 Qualification으로, Proposal에서 Negotiation으로, 마지막에는 Closed Won이나 Closed Lost로 간다. 중요한 것은 화면에 Stage 값이 있다는 사실이 아니다. Sales, SE, Finance, Legal, Manager가 그 상태를 공통의 사실로 사용한다는 점이다.
“이 Deal은 지금 Negotiation 단계다.”
이 한 문장을 여러 Actor가 같은 의미로 받아들여야 다음 행동이 가능하다.
계약도 마찬가지다. Draft, Review, Approved, Signed 같은 상태가 있다. Support Case도 New, Assigned, Waiting, Resolved, Closed 같은 상태가 있다. Invoice, Order, Claim, Change Request, Deployment도 다르지 않다.
그리고 상태 사이의 화살표에는 항상 조건이 붙는다.
예를 들어 할인 승인은 단순한 ApproveDiscount Tool 하나가 아니다.
- 현재 Opportunity가 어떤 State인가
- 요청한 사용자가 어떤 Role인가
- 할인율이 얼마인가
- 어느 금액부터 상위 승인이 필요한가
- Legal이나 Finance의 선행 조건이 있는가
- 이미 다른 승인이나 변경이 진행 중인가
이 조건이 만족되어야 실제 상태가 바뀐다.
기업은 사람이 일을 나눠서 하는 조직이기도 하지만, 시스템 관점에서는 여러 Actor가 하나의 업무 상태를 공유하고 허용된 전이를 수행하는 조직에 더 가깝다.
이 점을 놓치면 Agent가 모든 Workflow를 대체할 수 있다는 생각이 너무 쉽게 나온다.
ESTC로 보면 무엇이 남는지가 선명해진다
이 글에서는 이 구조를 편의상 Entity–State–Transition–Constraint, 즉 ESTC라는 렌즈로 보겠다. ESTC를 이미 정립된 학계 표준 용어라고 주장하려는 것은 아니다. Agent가 실제 시스템을 움직일 때 무엇이 명시적으로 남아야 하는지를 단순하게 분해하는 방법이다.
Entity는 변경하려는 실제 업무 객체다. Opportunity, Order, Contract, Case, Invoice 같은 것이다.
State는 Agent가 그렇다고 생각하는 상태가 아니라 조직이 현재 사실로 인정하는 committed state다.
Transition은 상태를 바꾸는 행동이다. Approve, Refund, Assign, Close, Publish, Deploy 같은 것이 여기에 들어간다.
Constraint는 그 Transition이 허용되는 조건이다. Identity, Role, Permission, Approval, Amount, Compliance Rule, Current State, Separation of Duties 같은 것들이다.
이렇게 놓으면 Agent의 위치도 훨씬 명확해진다.
Agent는 현재 Context를 읽고 “이 경우 RefundRequested로 전이하는 것이 맞겠다”고 제안할 수 있다. 하지만 실제 Order가 이미 RefundCompleted인지, 이 Customer가 그 Order의 소유자인지, 같은 환불이 이미 실행됐는지, 해당 금액에 추가 승인이 필요한지는 시스템이 확인해야 한다.
나는 이 경계를 다음 네 문장으로 보는 편이 좋다고 생각한다.
Agent belief ≠ committed State.
Agent proposal ≠ legal Transition.
Tool capability ≠ execution authority.
Successful tool response ≠ committed business outcome.
LLM Agent 연구에서도 비슷한 방향을 볼 수 있다. 2025년 Artificial Intelligence Review의 Agentic AI survey는 symbolic/classical 계열과 neural/generative 계열을 구분한 뒤, 미래를 어느 한쪽의 승리보다 둘의 의도적인 결합으로 본다. Agentic AI: a comprehensive survey of architectures, applications, and future directions
이론 이름보다 중요한 것은 실무적인 결론이다. 확률적인 해석 능력이 좋아지는 것과, 공유 상태를 관리하는 구조가 없어지는 것은 같은 일이 아니다.
기존 Software 앞에 Agent만 붙이면 ‘도움은 되지만 일을 덜어주지 못하는 Agent’가 된다
그렇다고 기존 Enterprise Software를 그대로 두고 앞에 Chat Interface만 붙이면 문제가 해결될까.
실제 프로젝트에서는 이쪽 실패도 흔하다.
기존 시스템은 사람이 UI를 클릭한다는 가정으로 만들어져 있다.
사용자가 화면을 열고, 값을 입력하고, Validation을 통과하고, Approval을 요청하고, 다른 담당자가 승인하고, 다음 화면에서 후속 처리를 한다. 각각의 Button과 Modal 뒤에 권한과 Business Rule이 숨어 있다.
여기에 Agent만 앞에 붙이면 이런 경험이 나온다.
사용자는 “이 고객 환불 처리해줘”라고 말한다. Agent는 고객도 찾고 주문도 찾고 환불 사유도 정리한다. 그런데 실제 시스템에서는 Case를 만들고, Manager 승인을 받고, Finance 검증을 기다린 다음, Refund 화면에서 실행해야 한다.
Agent의 답은 점점 이런 식이 된다.
“요청을 준비했습니다.”
“승인이 필요합니다.”
“Finance 확인을 기다리고 있습니다.”
“다음 단계는 담당자가 진행해야 합니다.”
분명 똑똑하다. 검색도 빨라졌고 문서도 잘 써준다. 그런데 사용자의 느낌은 묘하다.
내 일에 도움은 되는데, 내 일이 줄지는 않았다.
Agent가 기존 Human UI Workflow를 그대로 따라가도록 만들었기 때문이다.
Enterprise Agent를 제대로 도입하려면 기존 Software를 보존하는 것만으로도 부족하다. Human만을 Actor로 가정해 설계한 UI-centric Application을, Human과 Agent와 Automation이 같은 Business Capability를 사용할 수 있는 구조로 다시 볼 필요가 있다.
반대로 통제를 없애면 Prompt 안에 Software를 다시 만들게 된다
첫 번째 실패를 경험하면 반대 방향으로 과하게 가기 쉽다.
“승인도 Agent가 판단하게 하자.”
“상태도 Agent Memory가 기억하면 되지 않을까.”
“실패하면 Agent가 알아서 다시 해보게 하자.”
그러면 처음에는 시스템이 놀랄 만큼 유연해진다. Agent가 Goal을 받고, Reasoning을 하고, Tool을 고르고, 결과를 보고 다시 다음 Tool을 호출한다.
하지만 운영에 들어가면 Prompt가 점점 길어진다.
Do not refund twice.
Always check the current status first.
Never proceed without manager approval.
If the amount exceeds X, escalate.
If the API times out, verify whether the operation already succeeded.
익숙한 문장들이다. 원래 Application Code와 Workflow에 있던 Business Rule이 Prompt로 이동했을 뿐이다.
이 지점에서 나는 꽤 단순한 기준을 쓴다.
Workflow를 없앤 뒤 그 규칙을 Prompt에 다시 적기 시작했다면, Software를 제거한 것이 아니다. 검증하기 더 어려운 곳으로 옮긴 것이다.
2024년의 한 neuro-symbolic generative agent 연구는 formal automaton으로 temporal structure를 강제했을 때 pure LLM 방식보다 procedural constraint adherence가 크게 높아졌다고 보고했다. 실험 도메인은 interactive storytelling이므로 이것을 Enterprise transaction의 직접 증거로 확대 해석할 수는 없다. 다만 장기 상태와 절차를 probabilistic generation 하나에 맡기지 않고 explicit control과 결합하는 방향이 왜 연구되는지는 잘 보여준다. Procedural Adherence and Interpretability Through Neuro-Symbolic Generative Agents
개인 비서 Agent조차 현실을 바꾸기 시작하면 Stateful System이 된다
이 문제가 Enterprise에서만 생기는 것은 아니다.
“다음 주 화요일 저녁에 John과 약속 잡아줘.”
개인 비서 Agent에게는 아주 자연스러운 요청이다. Agent가 Calendar를 보고 빈 시간을 찾고 Invite를 보내면 될 것처럼 보인다.
그런데 실제로는 상태가 생긴다.
Proposed → Invite Sent → Waiting → Accepted.
그 사이 사용자가 “화요일 말고 수요일로 바꿔”라고 말할 수 있다. 상대방은 이미 Accept했을 수도 있고, 같은 시간에 다른 일정이 새로 들어왔을 수도 있다.
이때 Agent가 믿어야 하는 것은 자신의 이전 대화 Memory가 아니다. Calendar의 현재 committed state다.
이미 보낸 Invite를 취소해야 하는지, 기존 Event를 Update해야 하는지, 새 Event를 만들어야 하는지는 현재 상태에 따라 달라진다.
개인 비서에서도 이 정도다.
Enterprise에서는 Actor가 하나가 아니다.
Human A가 있고 Human B가 있다. Agent A와 Agent B가 동시에 같은 Customer나 Contract를 볼 수도 있다. CRM과 ERP가 있고 Payment Provider와 Document System이 있다.
이 환경에서 어려운 질문은 “어느 Agent가 더 똑똑한가”가 아니다.
누가 현재 상태를 정의하며, 누가 어떤 상태 전이를 허가할 수 있는가?
이 질문은 모델 크기를 키운다고 사라지지 않는다.
Agent가 강한 곳과 Software가 강한 곳을 다시 나눠야 한다
그래서 나는 Agent 시대의 Architecture를 Agent vs Software로 보지 않는다.
Agent는 의미가 모호한 문제에 강하다.
- 요청의 의도를 이해한다.
- 여러 문서를 비교한다.
- 분류한다.
- 계획을 만든다.
- 여러 후보 중 적절한 행동을 고른다.
- 예외적인 상황에서 Context를 해석한다.
반대로 Runtime/Application이 소유해야 할 것은 성격이 다르다.
- Identity
- Committed State
- Authorization
- Policy
- Legal Transition
- Persistence
- Idempotency
- Commit
- Readback
- Audit
- Replay
Agent가 refund_order Tool을 호출할 수 있다는 사실은 “이 Agent에게 이 환불을 실행할 권한이 있다”는 뜻이 아니다.
Tool은 Capability다. Authority는 다른 문제다.
이 구분은 Agent의 능력을 줄이려는 설계가 아니다. 오히려 Agent를 정말 일을 덜어주는 Actor로 만들기 위해 필요하다. Agent가 매번 이미 확정된 규칙까지 추론하게 하지 않고, 모호한 판단에 집중시킬 수 있기 때문이다.
기존 Software도 Agent 시대에 맞게 바뀌어야 한다
여기까지 읽으면 “결국 기존 Software를 그대로 유지하자는 이야기 아닌가”라고 생각할 수 있다.
내 결론은 반대에 가깝다.
기존 Software도 꽤 많이 바뀌어야 한다.
많은 Enterprise Application은 UI-centric하다. Business Capability가 Approve Discount라는 독립된 Contract로 존재하기보다 특정 화면의 Button과 Modal, Controller Logic 안에 흩어져 있다.
사람만 사용하던 시절에는 이 구조도 충분히 작동했다.
하지만 Agent가 새로운 Actor가 되면 Capability가 UI에서 분리되어야 한다.
Human UI도 request_refund를 호출하고, Agent도 같은 Capability를 호출하고, Batch Automation도 같은 Capability를 호출할 수 있어야 한다.
그 아래에서는 누가 호출하더라도 같은 State, Policy, Authority, Constraint가 적용되어야 한다.
이 구조가 되면 Agent는 더 이상 기존 화면을 흉내 내는 고급 RPA가 아니다.
Context를 이해하고, 필요한 Capability를 고르고, 요청을 구성하고, 결과를 해석한다.
반면 Business System은 실제 세계의 State와 Authority를 지킨다.
이것이 내가 생각하는 훨씬 현실적인 Agentic Enterprise Architecture다.
그렇다면 n8n, Make, Zapier는 사라질까?
사라질 수도 있다. 적어도 지금과 같은 사용 방식은 크게 바뀔 수 있다.
그건 별로 중요한 질문이 아니다.
n8n의 2026년 제품 변화만 봐도 흥미롭다. n8n Assistant는 자연어로 Workflow를 만들고 실행하고 수정하지만 최종 결과는 팀이 보고 수정하고 실행 로그를 확인할 수 있는 Workflow로 남는다. Introducing n8n Assistant
n8n Agents에서는 Agent가 Workflow를 Tool로 쓸 수 있고, Workflow 안에서 다시 Agent를 호출할 수도 있다. Introducing n8n Agents
이 구조가 n8n이 미래에도 반드시 살아남는다는 증거는 아니다.
오히려 내가 흥미롭게 보는 것은 반대다.
Agent가 발전하자 Workflow 제품조차 Workflow를 버리는 대신 Authoring과 Reasoning을 Agent에게 열고, 실행 구조는 함께 남기는 방향으로 움직이고 있다.
앞으로 Agent가 직접 TypeScript를 만들 수도 있고, Workflow Definition을 생성할 수도 있다. 사람이 Canvas를 열어보지 않아도 되는 날도 올 수 있다.
그래도 실행되는 순간에는 누군가 다음을 책임져야 한다.
현재 State는 무엇인가.
이 Transition이 허용되는가.
누가 실행할 권한이 있는가.
외부 Side Effect는 성공했는가.
같은 요청이 다시 들어오면 어떻게 할 것인가.
무엇을 Audit Evidence로 남길 것인가.
UI가 사라져도 이 질문들은 남는다.
Agent 시대에 Software Engineering이 오히려 더 중요해지는 이유
예전 Software는 판단과 실행을 모두 Code에 넣었다.
Agent 시대에는 그 경계가 다시 그려지고 있다.
애매한 의미를 해석하고, Context를 읽고, 후보 행동을 만드는 일은 Agent에게 이동한다.
반대로 조직이 함께 믿어야 하는 State와 실제 세계를 바꾸는 Authority는 Software에 남는다.
좋은 Agentic Architecture는 이 둘 중 하나를 제거하는 구조가 아니다. 각각 잘하는 곳으로 책임을 다시 배치하는 구조다.
그래서 나는 “Agent가 좋아졌으니 Workflow Engine은 필요 없다”는 주장보다 다른 질문이 더 중요하다고 생각한다.
어떤 판단은 Agent에게 넘기고, 어떤 사실과 규칙은 Software에 남길 것인가?
Agent가 API를 잘 호출하기 시작했다고 해서 우리가 수십 년 동안 배운 State Machine, Transaction, Authorization, Concurrency, Audit를 갑자기 버릴 이유는 없다.
그것들을 Prompt에 다시 적는 것으로 충분했다면 Software Engineering은 진작 훨씬 쉬운 일이었을 것이다.
좋은 Enterprise Agent는 Software를 없애는 Agent가 아니다. Software가 이미 잘하는 일을 매번 다시 추론하지 않고, 지금까지 Software가 잘하지 못했던 모호한 판단을 맡아주는 Agent다.