- 사내 업무가 느린 것은 대개 이메일, 채팅, 여러 버전의 파일을 오가며 서로 묻고 다녀야 하기 때문입니다. 단계 하나하나가 어려운 경우는 드뭅니다.
- 좋은 시스템은 AI를 넣는 이야기를 하기 전에 모든 업무에 상태, 담당자, 분명한 다음 단계를 붙입니다.
- 이 기반이 갖춰지면 AI가 실제로 도움이 됩니다. 요청을 읽고, 유형별로 나누고, 정보를 모으고, 마감을 넘기기 전에 알려 줍니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
오늘 어떤 고객의 요청이 누구 손에서 멈춰 있는지 알고 싶다면, 단체 채팅방을 열고 이메일을 뒤진 다음 두 사람에게 더 전화해 봐야 합니다. 업무 과정이 눈에 보이지 않아서 생기는 문제이고, 직원에게 더 열심히 하라고 해서 풀리지 않습니다.
회사에는 시스템이 여러 개 있지만 직원들은 여전히 채팅으로 일을 챙깁니다. 시스템마다 자기 부분만 보기 때문입니다. 그래서 여러 부서를 거치는 업무에는 처음부터 끝까지 책임지는 사람이 없습니다.
많은 사내 업무는 단계마다 어려울 것이 없는데도 이메일, 채팅, 스프레드시트, 여러 시스템을 거치느라 느려집니다. 한 사람은 다른 사람이 어디까지 했는지 모르니 진행 상황을 묻고, 파일을 다시 보내고, 개인 메시지로 급한 불을 끕니다. 일이 굴러가는 것은 기억력 좋은 사람이 있어서이고, 업무 과정 자체는 여전히 보이지 않습니다.
개발팀 참고 · 기술 세부 사항
AI Internal Operations App은 지능을 더하기 전에 업무마다 State, Owner, Dependency, Next Action을 분명히 해야 합니다. 그래야 Agent가 요청을 읽고, 분류하고, 정보를 모으고, 알림을 보내고, 결정을 준비하는 일을 도울 수 있습니다. 이 순서를 지키지 않으면 메시지는 늘어나는데 진짜 Record가 어디 있는지 아무도 모르는 시스템이 됩니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 양식 접수, 상태 저장, 대시보드 표시 | 에이전트가 요청을 하위 작업으로 나누고, 여러 시스템에서 데이터를 가져오고, SLA에 따라 우선순위를 정하고, 승인을 요청하고, 업무가 왜 막혔는지 설명 |
모든 업무 항목(Work Item)에 하나의 상태(State)와 식별자가 있어야 에이전트가 업무 조율을 도울 수 있습니다. 경로는 워크플로 시스템이 통제하고, AI는 글을 해석하고 데이터를 준비하는 일을 돕습니다. 이 두 역할을 나눠야 자연어로 나온 답이 근거 없이 중요한 상태를 바꾸는 일을 막을 수 있습니다.
기업이 쓸 수 있는 새로운 기능
AI를 넣기 전에 먼저 고칠 것은 공장의 작업 지시서처럼 모든 업무에 분명한 상태와 담당자를 붙이는 일입니다. 이것이 갖춰지면 AI가 실제로 도움이 됩니다. 들어온 요청을 읽고, 어떤 유형의 일인지 가리고, 관련 정보를 찾아 붙이고, 어떤 건이 마감을 넘기려 하는지 미리 알려 줍니다.
프로젝트의 모습
시스템은 운영 작업 공간(Operations Workspace) 역할을 합니다. 양식, 이메일, 채팅으로 들어온 요청을 받아 중앙 업무 항목을 만들고, 관련된 사람 모두가 같은 타임라인, 문서, 담당자, SLA, 예외를 봅니다. AI는 정리되지 않은 글을 확인할 수 있는 데이터로 바꾸는 일을 돕지만, 중요한 지점의 확인 절차는 건너뛰지 않습니다.
갖춰야 할 기능
기능으로는 스마트 접수, 자동 분류, 중복 탐지, 체크리스트, 승인, SLA 알림, 예외 처리 대기열(Exception Queue), 상태 요약, 시스템 간 업데이트가 있을 수 있습니다. 관리자 화면은 보기에는 좋아도 아무 조치로 이어지지 않는 요약 그래프 대신, 밀린 업무와 그 이유, 내려야 할 결정에 집중해야 합니다.
뒤에서 돌아가는 기술
시스템의 중심은 워크플로 엔진과 상태 저장소(State Store)이며, API와 이벤트로 ERP, HRIS, CRM, 문서나 이메일 시스템과 연결됩니다. AI는 해석과 요약을 맡고, 상태 변경, 권한, 승인 조건은 정의할 수 있는 규칙으로 처리합니다. 같은 명령이 반복돼도 기록이 중복으로 생기거나 돈이 두 번 나가지 않도록 큐, 재시도(Retry), 멱등성(Idempotency)을 갖춰야 합니다.
조직에 주는 효과
직원은 일을 챙기고 파일을 찾는 시간이 줄고, 팀장은 업무가 SLA를 넘기기 전에 병목을 보며, 경영진은 문제가 처리 용량, 불완전한 데이터, 승인 규칙 중 어디에서 생기는지 가려낼 수 있습니다. 길게 보면 업무를 조율하던 사람들의 노하우가 가르치고 점검하고 개선할 수 있는 업무 프로세스로 바뀌고, 예외를 위한 여지도 남습니다.
- 평소 말로 쓴 요청을 정형 데이터로 바꾸는 지능형 접수(Intelligent Intake)
- 중앙의 상태 정보를 기준으로 시스템과 부서를 넘나들며 업무를 조율하는 오케스트레이션(Orchestration)
- 사람이 결정해야 할 건만 보여 주는 예외 우선 UX(Exception-first UX)
- 로그로 병목과 고쳐야 할 규칙을 찾는 프로세스 학습(Process Learning)
가상 사례
실제로 쓰이는 모습
신규 지점 개설 요청을 IT, 구매, 인사, 시설 업무로 나눕니다. 에이전트는 빠진 정보를 확인하고, 의존 관계에 따라 작업을 만들며, 전체 일정을 좌우하는 경로(크리티컬 패스)가 늦어지면 팀장에게 알립니다.
또 다른 가상 사례로, 신규 공급업체 등록은 구매, 재무, 법무, 예산 책임자를 거쳐야 합니다. 시스템은 요청을 읽고 공급업체 유형에 맞는 서류를 확인한 뒤, 부서별 작업을 만들고 의존 관계를 보여 줍니다. 납세자 번호가 맞지 않으면 AI가 다음 단계로 넘기기 전에 추가 정보를 요청하므로, 모든 부서가 검토를 시작한 뒤에 일이 되돌아가는 경우가 줄어듭니다.
급하게 등록해야 하는 공급업체처럼 예외가 생기면, 시스템은 특수한 건을 일반 흐름에 억지로 밀어 넣지 않고 예외 경로(Exception Lane)로 옮겨 이유, 위험, 승인 권한자를 밝힙니다. 경영진은 예외가 왜 자주 생기는지, 정책이나 처리 용량을 어디서 바꿔야 하는지 볼 수 있습니다.
에이전트 전에 상태부터(State-before-Agent)
AI를 더하기 전에 상태, 담당자(Owner), 상태 변경 규칙을 정하십시오.
업무가 어느 단계에 있는지 시스템이 모르면, 에이전트는 메시지만 더 많이 보냅니다.
범위, 위험, 성과 측정 방법
개발팀 참고 · 기술 지표
Idempotency, Permission, Manual Recovery가 없는 Automation은 오류를 아주 빠르게 불릴 수 있습니다. 단계별 Cycle Time, Waiting Time, Rework, Exception Rate, 채팅으로 챙겨야 하는 업무 수를 측정하십시오. 시스템은 Ticket을 빨리 닫는데 직원은 여전히 시스템 밖에서 일한다면, 그 숫자는 실제 Productivity를 보여 주지 못합니다.
에이전트는 멱등성, 권한, 감사 기록 없이 중요한 데이터를 바꿔서는 안 됩니다. 우선순위를 정하는 방식은 투명해야 하며 누구도 차별해서는 안 됩니다.
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
중복 기록이 생기거나, 담당자 없이 멈춘 상태가 있거나, 직원이 시스템 밖에서 데이터를 고치는 일이 잦으면 자동화를 멈추십시오. 이런 문제는 대개 모델의 능력을 키우기 전에 워크플로와 시스템 연동부터 고쳐야 풀립니다.
BUSINESS & PRODUCT READINESS
에이전트에게 업무를 맡기기 전에 상태, 담당자, 의존 관계부터 드러내기
개발팀 참고 · 기술 세부 사항
Operations Agent는 주인 없는 Process를 고칠 수 없습니다. 상태가 "진행 중" 하나뿐이면 시스템은 업무가 데이터를 기다리는지, 승인을 기다리는지, 다른 시스템을 기다리는지 알 수 없습니다. 그러니 State Model, Entry/Exit Criteria, Dependency를 먼저 만들고, 그다음에 Agent가 요청 변환, 큐 관리, 병목 설명을 돕게 하십시오.
개발팀 참고 · 기술 지표
Happy Path만 설계하지 말고 실제 케이스로 Exception Catalog를 준비하십시오. 반복되는 Action에는 Idempotency를, State 변경에는 권한을, Integration이 멈췄을 때를 위해서는 Fallback을 정의합니다. Orphan Task와 Exception Age를 측정하면 부서 사이에서 업무가 사라지고 있는지 알 수 있습니다.
먼저 업무 한 유형의 상태 다이어그램(State Diagram)을 그리십시오. 각 상태에 어떤 이벤트로 들어오는지, 어떤 증거가 있으면 나갈 수 있는지, 누구에게 결정 권한이 있는지 적습니다. 그다음 예외 목록(Exception Catalog)을 만들어, 흐름을 추가로 설계해야 할 경우와 사람이 판단해야 할 경우를 나눕니다.
에이전트에는 역할에 필요한 만큼만 권한을 주어야 합니다. 예를 들어 문서를 읽고 요청서 초안을 쓸 수는 있어도, 승인이나 기준 정보(마스터 데이터) 수정은 확인자가 있는 별도 도구로 처리해야 합니다. 데이터 품질과 복구 절차를 믿을 수 있을 때까지는 한 팀, 한 업무 흐름(Journey)으로 운영하고, 그 뒤에 조직 전체의 프로세스를 연결하십시오.
처음부터 끝까지 성과를 책임지는 사람은 누구입니까?
가장 모호한 상태는 무엇입니까?
절대 두 번 일어나면 안 되는 작업은 무엇입니까?
시스템이 멈추면 업무는 어디에서 막힙니까?
여러 부서를 거치는 업무에 모두가 볼 수 있는 하나의 경로를 만듭니다
DNA Maker는 프로세스 책임자(Process Owner), 실무자와 함께 서비스 블루프린트를 만드는 데서 시작합니다. 실제 케이스를 따라가며 접수, 상태, 인계, 승인, 예외가 분명해질 때까지 확인합니다. 자동화를 생각하기 전에 가치 없는 단계부터 줄여서, 새 시스템이 예전만큼 복잡한 기존 프로세스를 빨리 돌리기만 하는 일이 없게 합니다.
프로덕트/UX팀은 업무 대기열, 예외 화면, 맥락 패널을 설계해 역할마다 결정에 필요한 만큼의 정보를 보게 합니다. 에이전트는 비정형 데이터를 읽거나 여러 도구를 조율하는 단계에 배치하고, 비즈니스 규칙은 감사할 수 있는 워크플로에 둡니다.
DNA Maker는 채팅과 사람들의 기억 속에 있던 업무를 서비스 블루프린트, 상태 모델, 역할/권한, 연동 지도(Integration Map)로 바꾸도록 돕습니다. 정책과 예외는 계속 고객사 팀이 정합니다. 저희는 그 규칙이 직원들이 실제로 쓰는 대기열, 승인, 감사 화면에 드러나게 만듭니다.
저희는 사내 웹 앱, 워크플로 엔진, AI 접수/조율 기능, 대시보드, 커넥터를 개발할 수 있고, 규칙과 SLA를 고치는 관리자 화면도 함께 만듭니다. 시범 운영에서는 업무 항목 하나를 처음부터 끝까지 따라가며 직접 작업 시간(Touch Time)과 대기 시간을 따로 재고, 현장 사용자와 이야기해 시스템이 조율 부담을 줄이는지 아니면 부담을 다른 화면으로 옮길 뿐인지 확인합니다.
사내 웹 앱, 워크플로 엔진, AI 오케스트레이터, 역할/권한, 연동, 알림, 관리용 대시보드를 감사 기록, 재시도, 모니터링과 함께 개발할 수 있습니다. 아키텍처는 각 구성 요소를 다음 업무 흐름에도 다시 쓸 수 있도록 설계합니다.
모두가 채팅으로 챙기는 부서 간 업무가 있다면, 업무 흐름 하나를 골라 막혀 있는 케이스를 가지고 이야기해 보십시오. DNA Maker는 전체 플랫폼에 투자하기 전에 현재와 향후의 흐름(Current/Future Flow)을 정리하고 업무 대기열 프로토타입을 만들도록 돕습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
이 표의 용어는 팀이 상태, 반복 실행, SLA, 여러 시스템의 조율을 같은 말로 이야기하도록 돕습니다. 에이전트에게 권한을 주기 전에 워크플로에 정상 경로, 예외, 복구가 모두 들어 있는지 확인할 때 쓰십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Orchestration | 여러 단계와 시스템이 함께 돌아가도록 통제하는 일. 조율 계층은 단계마다 상태, 의존 관계, 실패를 알아야 하며, 그래야 전체 과정을 다시 시작하지 않고도 멈추거나, 다시 시도하거나, 사람에게 넘길 수 있습니다. | 의존 관계 순서에 따라 지점 개설 진행 | 전체 흐름은 누가 책임집니까? |
| State Machine | 업무의 상태가 어떻게 바뀌는지 정한 규칙. 상태와 전환을 분명히 정해 두므로, 업무가 단계를 건너뛰거나 담당자 없는 상태로 멈추는 일을 막습니다. | 초안 → 검토 → 승인 | 잘못 바뀐 상태를 되돌릴 수 있습니까? |
| Idempotency | 같은 명령이 반복되어도 결과가 중복되지 않게 하는 원칙. 시스템이 타임아웃 뒤에 명령을 다시 보낼 때 특히 중요하며, 발주서를 두 번 만들거나 돈을 두 번 빼 가는 일을 막아 줍니다. | 재시도해도 발주서(PO)가 두 장 생기지 않음 | 중요한 작업은 모두 중복 방지가 되어 있습니까? |
| SLA | 합의한 서비스 시간. SLA는 서비스를 받는 사람에게 의미 있는 시간을 재야 하고, 정보를 기다리는 시간과 실제 작업 시간을 나누며, 기한을 넘기면 어떻게 되는지 밝혀야 합니다. | IT팀이 4시간 안에 요청을 접수 | SLA를 넘기기 직전에는 누구에게 알립니까? |
| Workflow Engine | 업무 규칙과 경로를 실행하는 시스템. 엔진이 규칙, 상태, 대기 중인 작업, 인계를 저장하므로, 모든 조건을 화면이나 프롬프트에 박아 넣지 않고도 프로세스를 바꿀 수 있습니다. | 금액에 따라 승인 요청 발송 | 규칙은 누가 바꿀 수 있습니까? |
더 읽을거리(원문 자료): https://openai.github.io/openai-agents-js/guides/multi-agent/