AI Agent가 모든 단계를 판단하게 해야 할까? n8n 기반 PoC 경험을 바탕으로 Agentic Reasoning과 Deterministic Workflow의 경계를 나누고, 이를 Step Functions·Lambda·애플리케이션 백엔드 같은 Enterprise Production 구조의 Blueprint로 연결하는 기준을 정리한다.
MCP로 AI Agent에 Tool을 연결한 뒤에도 실행 권한까지 LLM에 맡겨야 할까? Tool Planning, Runtime Context, Authorization, Policy와 Deterministic Execution의 경계를 Enterprise AI 관점에서 정리한다.
AI PoC의 병목은 코드 생성 속도가 아니라 현업의 아이디어가 실제 동작으로 돌아오는 시간이었다. Codex CLI를 API 뒤의 Agent Runtime으로 연결하고 Web, n8n, Salesforce에서 공통 실행 기반을 재사용하게 된 과정을 정리한다.
AI 프로젝트에서 명시적인 반대보다 더 어려웠던 것은 아무 말도 하지 않는 ‘조용한 저항’이었다. 현업의 두려움과 암묵지를 어떻게 이해해야 하는지, 그리고 왜 빠른 PoC가 신뢰 형성의 중요한 도구가 되는지를 실제 AX 프로젝트 경험을 중심으로 정리한다.
ChatGPT가 만든 Git Commit을 GitHub 이벤트로 받아 n8n과 OCI FastAPI에서 안전하게 실행하는 Event-Driven AI Automation 구조를 직접 구현한다.
ChatGPT의 대화를 단순히 기억에 맡기지 않고, 살아남은 프로젝트 지식을 Markdown으로 승격해 GitHub와 Obsidian에 축적하는 개인 LLM Wiki 구축 과정을 정리한다.
지난 두 글에서는 하나의 작은 요구사항을 계속 따라가봤다. 처음 고객이 원했던 것은 Salesforce Email-to-Case로 생성되는 Case의 Level 1과 Level 2 Category를 AI가 자동으로 판단하는 것이었다. 첫 번째 글에서는 무엇을 AI에게 맡길 것인지 고민했다. 두 번째 글에서는 AI가 고객의 문의 의미를 판단하더라도 실제 Case의 Category, 담당 조직, 업무 이력 같은 상태 변화까지 바로 맡길 필요는 없다고 … 더 읽기
지난 글에서는 고객의 요구사항을 최대한 단순하게 유지했다. 최초 이메일이 Salesforce Email-to-Case를 통해 Case로 생성되면 AI가 내용을 읽고 Level 1과 Level 2 Category를 판단한다. Category가 정해진 이후의 Assignment는 이미 존재하는 Salesforce의 규칙에 맡긴다. 여기까지만 보면 꽤 깔끔하다. 그런데 실제 상담 업무를 생각하기 시작하면 문제는 최초 분류 이후부터 생긴다. 처음에는 Billing 문의였던 고객이 같은 이메일 Thread에서 이렇게 … 더 읽기
Salesforce Email-to-Case의 단순한 L1/L2 자동 분류 요구에서 시작해, 기존 시스템 이해와 실제 상담 업무, AI Observability까지 생각이 확장된 과정을 정리한다.
좋은 모델을 도입한다고 업무가 자동으로 바뀌지는 않는다. 10년의 B2B 영업 경험과 Enterprise AX 설계를 거치며 생각하게 된, 결정론적 시스템과 AI의 판단 사이에 경계를 그리는 방법에 대한 이야기.