"요즘 AI는 혼자 알아서 다 하던데, 왜 워크플로우 같은 걸 신경 써야 하나요?"
자주 받는 질문입니다. 솔직히 처음 들었을 때 저도 비슷한 생각을 했습니다. Claude Code나 Openclaw 와 같은 에이전틱 도구가 알아서 판단하고 행동하는 시대에, 단계별로 흐름을 정의하는 건 좀 구식처럼 느껴지기도 하니까요. 마치 자율주행차 시대에 신호등 타이밍을 수동으로 조절하자는 이야기 같달까요.
그런데 B2B 고객들과 실제로 프로젝트를 진행해보면 이야기가 달라집니다. AI가 뭔가를 해낼 수 있다는 것과, 그걸 실제 업무에 맡길 수 있다는 건 완전히 다른 문제라는 걸 깨닫게 됩니다.
여러분이 어떤 중견 제조사와 견적 자동화 프로젝트를 진행한다고 생각해봅시다. 이 회사는 산업용 부품을 만드는 곳이었는데, 하루에 들어오는 견적 요청이 수십 건이었습니다. 영업팀 직원들이 엑셀 파일을 뒤지고, 과거 거래 이력을 찾아보고, 가격표를 대조하는 데 하루의 절반을 쓰고 있었습니다.
처음에는 단순해 보였습니다. 고객 문의가 들어오면 AI가 사양을 파악하고, 가격을 계산해서, 견적서를 보내는 것. 기술적으로 어렵지 않았습니다. 프로토타입은 2주 만에 나왔고, 데모에서 담당자들 반응도 좋았습니다. "이거 진짜 되네요"라는 말이 여기저기서 나왔습니다.
문제는 실제 업무에 붙이려고 하니까 터졌습니다.
첫 번째 미팅에서 영업팀장이 물었습니다. "이 견적은 누가 승인한 거죠?" 당연한 질문이었는데, 우리는 그걸 생각하지 못했습니다. AI가 알아서 판단해서 보낸 건데, 나중에 문제가 생기면 책임 소재가 불분명해집니다. 고객이 "그때 받은 견적이랑 실제 청구 금액이 다르다"고 하면 누가 설명을 해야 할까요.
재무팀에서도 우려가 나왔습니다. "가격 산정 근거가 뭐예요? 감사 때 어떻게 설명하죠?" 이 회사는 분기마다 내부 감사를 받고 있었습니다. 모든 거래에는 근거 문서가 있어야 했고, 가격 결정 과정이 추적 가능해야 했습니다. AI가 "이 고객은 과거 거래 이력과 현재 시장 상황을 고려해서 15% 할인이 적절하다고 판단했습니다"라고 해도, 그게 감사 자료가 될 수는 없었습니다.
영업팀 막내 직원이 조심스럽게 말했습니다. "근데 저번에 AI가 보낸 견적 중에, 단가를 좀 이상하게 계산한 게 있었어요. 다행히 고객이 먼저 물어봐서 알았는데..." 실수가 있었던 겁니다. 프로토타입 단계에서는 "나중에 고치면 되지"라고 넘어갔던 것들이, 실제 고객한테 나가면 바로 문제가 됩니다.
결국 프로젝트는 다시 설계해야 했습니다. AI가 견적 초안을 만들고, 담당자가 검토한 뒤, 일정 금액 이상은 팀장 승인을 거쳐 발송하는 워크플로우로요. 처음 생각했던 "AI가 알아서 다 하는" 모습과는 많이 달랐습니다. 하지만 이 구조가 되고 나서야 회사는 실제로 시스템을 쓰기 시작했습니다.
AI 능력이 부족했던 게 아닙니다. 기업 환경에서 요구하는 것이 달랐습니다.
"다시 해줘"가 안 통하는 환경이라 워크플로우가 필요합니다
개인이 ChatGPT에게 여행 계획을 부탁할 때를 생각해봅시다. AI가 "파리 3일 일정"을 짜줬는데 동선이 좀 이상합니다. 에펠탑 갔다가 루브르 갔다가 다시 에펠탑 근처로 돌아오는 식으로요. 이럴 때 우리는 그냥 "동선 다시 짜줘"라고 합니다. AI가 실수해도 별일 없습니다. 최악의 경우 여행 중에 좀 더 걷게 되는 정도입니다.
그런데 기업 환경은 다릅니다.
영업 리드 분류에서 AI가 실수하면 어떻게 될까요. 중요한 고객을 "우선순위 낮음"으로 분류해서 담당자가 일주일 뒤에야 연락했다고 해봅시다. 그 사이에 고객은 경쟁사와 계약을 맺었습니다. 수억 원짜리 거래가 날아간 겁니다.
계약 문서 생성에서 AI가 실수하면요. 조항 하나가 빠졌거나, 금액이 잘못 들어갔거나, 법적 문구가 누락됐습니다. 고객이 서명하고 나서야 발견됐습니다. 법무팀이 난리가 나고, 고객과의 관계가 틀어지고, 최악의 경우 소송으로 이어집니다.
고객 응대에서 AI가 실수하면요. 환불 불가 상품인데 "환불해드리겠습니다"라고 답변했습니다. 고객은 당연히 환불을 기대합니다. 나중에 "AI가 실수했어요"라고 말할 수 있을까요. 고객 입장에서는 회사가 한 약속입니다.
"AI가 실수했어요"는 고객에게 할 수 있는 말이 아닙니다. 회사가 한 행동은 회사의 책임입니다.
그래서 워크플로우가 필요합니다.
워크플로우를 정의하면 AI의 행동을 예측 가능한 단계로 제한할 수 있습니다. "리드 분류 → 담당자 할당 → 계약 문서 생성 → 승인 요청" 같은 흐름이 명확하면, AI가 어디서 무엇을 하는지 파악할 수 있습니다. 문제가 생겼을 때 "아, 분류 단계에서 잘못 판단했구나" 하고 바로 알 수 있습니다. 원인을 알면 고칠 수 있습니다.
B2B 환경은 ERP, CRM, 이메일, 데이터베이스가 복잡하게 엮여 있습니다. AI가 혼자 판단해서 이 시스템들을 호출하게 두면 순서가 꼬이거나 예상치 못한 충돌이 발생합니다. "CRM에는 업데이트됐는데 ERP에는 안 들어갔어요" 같은 상황이 생기는 겁니다. 워크플로우는 각 시스템 호출의 순서와 책임을 명확히 해줍니다.
현실 업무에는 항상 예외가 있습니다. 결제 금액이 일정 한도를 초과하면 자동 승인 대신 매니저 승인을 요청해야 합니다. 신규 고객은 신용 확인 절차를 거쳐야 합니다. 특정 품목은 수출 규정 검토가 필요합니다. 워크플로우가 있으면 이런 분기 처리를 자연스럽게 넣을 수 있습니다. "금액이 5천만 원 이상이면 이쪽 경로로, 아니면 저쪽 경로로." 이게 없으면 기업은 AI 도입 자체를 꺼립니다. 리스크가 너무 크니까요.
"누가 어떤 결정을 했는가." 감사가 들어왔을 때, 고객이 문의했을 때, 내부 검토가 필요할 때, 항상 근거가 있어야 합니다. 워크플로우 기반이면 AI의 행동 로그가 단계별로 남습니다. "이 시점에 이 데이터를 받아서, 이 판단을 했고, 이 결과를 냈다"는 기록이 자동으로 쌓입니다. 나중에 "왜 이렇게 됐죠?"라는 질문에 답할 수 있습니다.
자율성의 자리
여기까지 읽으면 "그럼 AI한테 아무것도 맡기지 말라는 건가?"라는 생각이 들 수 있습니다. 그건 아닙니다.
모든 업무가 워크플로우에 맞지는 않습니다. 여러 문서를 넘나들며 정보를 종합하거나, 답을 찾기 위해 여러 경로를 시도해야 하는 작업에서는 단계별 흐름을 미리 정의하는 것 자체가 발목을 잡습니다.
예를 들어볼게요. 고객이 "우리 회사 제품 중에 친환경 인증 받은 게 뭐가 있어요? 가격대별로 알려주세요"라고 물었습니다. 이 질문에 답하려면 AI는 제품 카탈로그를 뒤지고, 인증 정보를 확인하고, 가격 데이터를 가져와서, 적절히 정리해야 합니다. 어떤 순서로 어떤 문서를 봐야 하는지는 질문에 따라 달라집니다. "먼저 A를 보고, 그다음 B를 보고..."라고 미리 정해둘 수가 없습니다.
우리는 이 한계를 '스킬'이라는 개념으로 풀고 있습니다.
Agentic RAG 같은 경우를 생각해보면, 내부적으로는 AI가 자율적으로 문서를 탐색하고 정보를 조합합니다. 필요하면 검색을 여러 번 하고, 결과를 비교하고, 부족하면 다른 경로를 시도합니다. 꽤 자유롭게 움직입니다. 그런데 워크플로우에서는 이 전체가 하나의 호출 가능한 단위로 동작합니다. 워크플로우 입장에서는 "자료 조사"라는 한 단계일 뿐입니다. 그 안에서 AI가 어떻게 움직이는지는 스킬 내부의 문제입니다.
워크플로우가 전체 흐름을 통제하고, 스킬이 개별 구간에서 자율성을 발휘하는 구조입니다. "고객 문의 접수 → 자료 조사(스킬) → 답변 초안 작성 → 담당자 검토 → 발송" 이런 식으로요. 자료 조사 단계에서는 AI가 자유롭게 탐색하지만, 그 결과물이 나오면 다시 워크플로우의 통제 아래로 들어옵니다.
통제와 자율성 사이의 균형점을 찾은 셈입니다. 전부 통제하면 AI의 장점을 못 살리고, 전부 자율에 맡기면 기업이 쓸 수 없습니다. 적절한 균형점이 존재합니다.
설계라는 허들
워크플로우의 가치는 명확합니다. 통제 가능하고, 추적 가능하고, 재사용 가능한 구조. 기업이 AI를 실제로 쓰려면 이게 필요합니다.
그런데 새로운 문제가 생깁니다.
워크플로우를 설계하려면 설계 지식이 필요합니다. 어떤 노드를 어떤 순서로 연결할지, 분기 조건은 어떻게 설정할지, 예외 처리는 어디에 넣을지, 변수는 어떻게 전달할지. 이런 판단은 프로세스 설계 경험이 있어야 가능합니다.
워크플로우 에디터를 처음 열어본 사람의 심정을 상상해봅시다.
화면에는 여러 종류의 노드가 있습니다. LLM 노드, 조건 분기 노드, API 호출 노드, 변수 설정 노드... 각각이 뭘 하는지 설명은 있는데, 이걸 어떻게 조합해야 내가 원하는 워크플로우가 되는지는 또 다른 문제입니다. 마치 레고 블록을 잔뜩 받아놓고 "이걸로 자동차를 만들어보세요"라고 하는 것 같습니다. 블록 하나하나는 이해할 수 있는데, 조합하는 방법을 모릅니다.
도메인 전문가는 업무를 잘 압니다.
CS팀 매니저는 고객 문의가 어떤 유형으로 들어오는지, 어떤 건 바로 답변해도 되고 어떤 건 확인이 필요한지, 어떤 케이스가 예외인지 다 알고 있습니다. 머릿속에 완벽한 프로세스가 있습니다. 그런데 워크플로우 설계 도구는 낯섭니다. "조건 분기 노드의 표현식에 변수를 바인딩하세요"라는 말이 무슨 뜻인지 모릅니다.
개발자는 도구를 다룰 수 있습니다.
노드 연결하고, 조건 설정하고, 변수 전달하는 건 어렵지 않습니다. 그런데 실제 업무 맥락을 모릅니다. "이런 경우에는 어떻게 해야 해요?"라고 물어봐야 하는데, 도메인 전문가가 바쁘면 답을 못 받습니다. 답을 받아도 한 번에 다 전달되지 않습니다. "아, 그것도 있었네요. 이 경우도 추가해주세요." 몇 번이고 왔다 갔다 합니다.
이 간극이 워크플로우 도입의 가장 큰 허들입니다. 업무를 아는 사람과 도구를 아는 사람이 다릅니다. 둘 사이의 번역 비용이 큽니다. 프로젝트가 지연되고, 결과물이 원래 의도와 달라지고, 유지보수가 어려워집니다.
우리는 이 문제를 에이전트로 해결하기로 했습니다.
에이전트와 대화하며 워크플로우 설계해보아요
사이오닉 스톰의 워크플로우 디자이너 에이전트는 자연어로 원하는 것을 설명하면 그에 맞는 워크플로우를 설계해주는 AI입니다. 이게 어떤 차이를 만드는지 구체적으로 보여드릴게요.
워크플로우 디자이너 없이 CS 자동화를 만든다고 해봅시다. CS팀 매니저인 김 과장이 직접 만들어보려고 합니다.
먼저 워크플로우 에디터를 엽니다. 왼쪽에 노드 목록이 있습니다. "이 중에 뭘 써야 하지?" 문서를 찾아봅니다. LLM 노드는 AI가 텍스트를 생성할 때 쓴다고 합니다. 조건 분기 노드는 조건에 따라 경로를 나눌 때 쓴다고 합니다. 이해는 되는데, "분류"를 하려면 어떻게 해야 하지? LLM 노드로 분류를 시키면 되나? 분류 결과에 따라 분기하려면 조건 분기 노드를 어떻게 연결하지?
튜토리얼 영상을 찾아봅니다. 30분짜리입니다. 중간중간 멈추면서 따라해봅니다. 한 시간이 지났습니다. 기본적인 연결은 알 것 같은데, 변수 전달 방식이 헷갈립니다. "이 노드의 출력을 저 노드의 입력으로 넣으려면..." 문서를 다시 찾아봅니다.
노드를 하나씩 배치하고 연결합니다. LLM 노드에 프롬프트를 씁니다. "고객 문의를 분류해주세요. 카테고리는..." 프롬프트 쓰는 것도 쉽지 않습니다. 너무 짧으면 제대로 분류를 못 하고, 너무 길면 뭐가 중요한지 AI가 헷갈려 합니다. 몇 번 테스트해보면서 조정합니다.
테스트를 돌립니다. 에러가 납니다. "노드 3에서 오류: 입력 형식이 맞지 않습니다." 노드 3이 뭐였더라? 화면을 보면서 찾습니다. 아, 조건 분기 노드. 왜 에러가 났지? 표현식을 잘못 썼나? 문서를 다시 찾아봅니다.
이 과정을 며칠 반복합니다. 김 과장은 결국 개발팀에 요청서를 넣습니다. "바빠서 직접 못 하겠어요. 이거 좀 만들어주세요." 개발팀은 백로그에 추가합니다. 2주 뒤에 착수할 수 있다고 합니다. 김 과장은 한숨을 쉽니다. "그냥 수작업으로 하는 게 빠르겠다."
워크플로우 디자이너와 함께라면 어떨까요. 대화를 이어가면서 워크플로우를 점점 정교하게 다듬을 수 있습니다.
김 과장: "고객 문의가 들어오면 자동으로 응답하는 워크플로우 만들어줘."
워크플로우 디자이너: "고객 문의 자동 응답 워크플로우를 만들었습니다. 기본 구조는 문의 수신 → 내용 분류 → 답변 생성 → 발송입니다. 몇 가지 여쭤볼게요. 모든 문의에 자동 응답하시겠어요, 아니면 특정 유형만 자동 응답하시겠어요?"
김 과장: "음... 긴급한 건 자동 응답하면 안 될 것 같아. 담당자가 직접 봐야 해."
워크플로우 디자이너: "알겠습니다. 긴급 문의는 자동 응답하지 않고 담당자에게 알림을 보내는 분기를 추가했습니다. 긴급 여부를 어떻게 판단하면 될까요? 특정 키워드가 있나요, 아니면 AI가 맥락을 보고 판단하게 할까요?"
김 과장: "환불, 장애, 긴급 이런 단어가 들어가면 긴급으로 봐줘."
워크플로우 디자이너: "키워드 기반 긴급 판단을 추가했습니다. '환불', '장애', '긴급' 키워드가 포함되면 담당자에게 슬랙 알림을 보냅니다. 그런데 한 가지 제안 드려도 될까요? 키워드만으로는 '이 제품 환불 정책이 어떻게 되나요?' 같은 단순 문의도 긴급으로 분류될 수 있어요. LLM이 문맥을 보고 실제로 긴급한 상황인지 판단하도록 보조 로직을 추가하면 오분류를 줄일 수 있습니다. 적용할까요?"
김 과장: "오, 그게 낫겠다. 적용해줘."
워크플로우 디자이너: "적용했습니다. 이제 키워드가 있어도 LLM이 맥락을 보고 최종 판단합니다. 예를 들어 '환불 정책 문의'는 단순 문의로, '어제 산 제품 환불하고 싶은데 화가 나서 미치겠어요'는 긴급 문의로 분류됩니다. 다음으로, 자동 답변의 톤은 어떻게 할까요? 격식체, 친근한 말투, 아니면 다른 스타일이 있나요?"
김 과장: "친절한 상담사 느낌으로 해줘. 너무 딱딱하면 안 돼."
워크플로우 디자이너: "친절한 상담사 톤으로 답변을 생성하도록 프롬프트를 설정했습니다. 답변 예시를 보여드릴까요?"
김 과장: "응, 보여줘."
워크플로우 디자이너: "'배송이 언제 오나요?'라는 문의에 대한 예시 답변입니다:
안녕하세요, 고객님! 문의 주셔서 감사합니다 :) 주문하신 상품은 현재 배송 중이며, 내일(3월 15일) 오후 중으로 도착 예정이에요. 배송 현황은 주문 내역에서 실시간으로 확인하실 수 있습니다. 더 궁금하신 점 있으시면 편하게 말씀해주세요!
이런 느낌이면 괜찮을까요?"
김 과장: "좋은데, 이모티콘은 빼줘. 회사 정책상 공식 채널에서는 이모티콘 안 써."
워크플로우 디자이너: "반영했습니다. 이모티콘 없이 친절한 톤을 유지하도록 수정했습니다. 완성된 워크플로우를 확인해보시겠어요?"
이렇게 대화를 이어가면서 처음에는 단순했던 워크플로우가 실제 업무에 맞는 구조로 발전합니다. 김 과장은 노드를 건드린 적이 없습니다. 그냥 자기가 원하는 걸 말했을 뿐입니다.
워크플로우 디자이너의 장점은 한 번 요청하고 끝나는 게 아니라는 점입니다. 대화의 내용과 사용자의 의도, 그리고 고객사의 사용 패턴을 분석해서 적합한 에이전트 패턴을 강화학습(RL)하게 됩니다. STORM 플랫폼은 초기 기획부터 에이전트 전체 시스템을 강화학습하기 위하여 만들어진 제품입니다.
이런 것도 되어요
설계 피드백 받기
"내가 만든 이 워크플로우 봐줘. 뭐가 부족하거나 개선할 점 있어?"
직접 테스트해보기 전까지는 설계의 허점을 알기 어렵습니다. 워크플로우 디자이너에게 피드백을 요청하면, 놓치기 쉬운 예외 케이스나 휴먼 에러, 논리적 오류를 실행 전에 미리 잡아낼 수 있습니다.
프롬프트 작성 위임
"이 LLM 노드가 친절한 상담사처럼 응답하게 프롬프트 작성해줘"
좋은 프롬프트를 작성하는 건 생각보다 시간이 오래 걸리는 작업입니다. 원하는 톤이나 스타일만 말하면 워크플로우 디자이너가 프롬프트를 대신 작성해주니, 프롬프트 엔지니어링에 쓰는 시간을 크게 줄일 수 있습니다.
일괄 수정
"이 워크플로우에서 GPT-4o 쓰는 노드 전부 Claude로 바꿔줘"
워크플로우가 복잡해질수록 노드 수도 늘어납니다. 모델을 바꾸거나 설정을 수정할 때 노드를 하나씩 열어서 고치는 건 비효율적입니다. 워크플로우 디자이너는 조건에 맞는 노드를 한 번에 찾아서 일괄 수정해줍니다.
설계 지식이 없어도 원하는 워크플로우를 만들 수 있고, 이미 만든 워크플로우도 대화를 통해 빠르게 수정할 수 있습니다.
기술적으로 어떻게 동작하나요
워크플로우 디자이너가 내부적으로 어떻게 동작하는지, 왜 이게 기술적으로 어려운 문제인지 설명해드릴게요.
워크플로우가 길어질수록 분기와 상태가 쌓이고, 한 번의 실수가 비용과 책임으로 이어집니다. AI가 "이렇게 하면 될 것 같아요"라고 만든 워크플로우가 실제로 돌아갔을 때 엉뚱한 결과를 내면 곤란합니다. 그래서 자연어만으로 실행을 맡기지 않고, DSL과 컴파일러가 먼저 구조를 잡도록 했습니다.
사이오닉에이아이가 자체 개발한 Swifap DSL은 파이썬 문법을 닮았습니다. 개발자가 보면 익숙한 느낌이 들도록 설계했습니다. 하지만 일반적인 코드와는 다르게, 이 코드는 실행 경로로 들어가지 않고 해석과 컴파일 단계로 들어갑니다. 작성된 함수는 AST(추상 구문 트리)로 읽히고, 그 결과는 그래프로 바뀝니다. 이때 주석도 함께 읽혀 노드 메모로 내려가며, 설계 의도가 나중에 화면에 그대로 남습니다. "이 단계에서는 고객 감정을 파악함"이라고 주석을 달면, 워크플로우 에디터에서도 그 메모가 보입니다.
그래프의 중간 형태가 IR(중간 표현)입니다. IR에는 노드와 링크, 시작과 끝, 메타 정보가 담기고, 노드의 위치와 레이어도 계산됩니다. 의존성 계산을 거치면 같은 레이어에 놓인 노드가 병렬 실행 대상으로 표시됩니다. 예를 들어, A 노드의 결과가 B와 C 노드에 동시에 필요하고 B와 C가 서로 의존하지 않으면, B와 C는 병렬로 실행될 수 있습니다.
노드 사이 데이터 연결은 자리표시자(placeholder)로 표현됩니다. 한 노드의 결과는 {{result}} 형태로, API 상태와 본문은 {{status}}와 {{body}}로 이어집니다. 문자열 안에 자리표시자를 남기는 방식이라 런타임이 값을 늦게 채워도 흐름이 흔들리지 않습니다. "고객님의 주문번호 {{order_id}}는 현재 {{status}} 상태입니다"처럼요.
조건 분기는 하나의 분기 노드로 모입니다. if와 elif는 같은 노드 안에서 순서대로 평가되고, else는 마지막 소켓으로 처리됩니다. 각 분기의 링크에는 라벨이 붙어 다음 단계에서 흐름이 섞이지 않습니다. "긴급=true"인 경로와 "긴급=false"인 경로가 명확히 구분됩니다. 비어 있는 분기도 라벨이 유지돼 이후 연결이 어긋나지 않습니다.
반복문은 while만 허용됩니다. for는 금지입니다. 이유가 있습니다. for 루프는 "몇 번 돌지"가 미리 정해져야 하는데, 워크플로우에서는 그게 런타임에 결정되는 경우가 많습니다. "답변이 만족스러울 때까지 재생성"은 몇 번인지 미리 알 수 없습니다. while은 조건이 만족될 때까지 돌기 때문에 이런 상황에 더 맞습니다. 물론 무한 루프 방지를 위한 안전장치는 별도로 있습니다.
상태 값을 바로 불린으로 쓰는 것도 막습니다. if customer_vip:가 아니라 if customer_vip == True:처럼 비교 연산을 분명히 써야 합니다. 이건 디버깅을 쉽게 하기 위해서입니다. 나중에 "왜 이 분기로 갔지?"를 추적할 때, 조건이 명시적이면 이해하기 쉽습니다.
지원하지 않는 인자나 알 수 없는 호출은 컴파일 단계에서 차단됩니다. 등록된 노드가 아니면 실패합니다. 이런 제약들이 실행 전에 오류를 잡아줍니다. 런타임에 가서야 "이건 안 돼요"라고 하는 것보다 훨씬 낫습니다.
역방향으로도 변환이 가능합니다. JSON 형태의 워크플로우를 그래프로 해석한 뒤 제어 흐름을 분석해 DSL 코드로 되돌립니다. 에디터에서 마우스로 만든 워크플로우도 코드 형태로 볼 수 있다는 뜻입니다. 이 과정에서 지원하지 않는 패턴은 경고로 남기고, 가능하면 왕복 검증을 돌려 의미가 바뀌지 않았는지 확인합니다.
Arbiter라는 내부 서비스는 워크플로우 디자이너의 두뇌 역할을 합니다. 대화를 한 스레드로 관리하고, 활성 에이전트와 도구 목록을 한 번에 묶어 LLM에게 보냅니다. 도구 사용 규칙은 시스템 프롬프트에 합쳐지고, 세션 상태는 변수 컨텍스트로 매 스텝마다 다시 붙습니다. LLM은 필요할 때 도구 호출을 내리고, 도구 결과는 즉시 대화 기록에 들어가 다음 추론에 반영됩니다.
에이전트와 서비스의 분리는 강하게 유지됩니다. 에이전트는 도구 목록과 시스템 프롬프트를 가진 채로 판단만 하고, 실제 실행은 서비스가 맡습니다. LLM 호출은 오케스트레이터에서만 발생해 흐름이 섞이지 않습니다. 이 구조가 있어야 로그 추적, 재현, 통제가 가능합니다. "이 시점에 LLM이 뭘 판단했고, 어떤 도구를 호출했는지" 전부 기록으로 남습니다.
샌드박스는 Pyodide 워커 풀로 쿠버네티스 환경 위에서 네이티브하게 동작합니다. 세션마다 워커 하나가 붙고 동시에 실행되는 세션 수는 제한됩니다. 네트워크와 파일 시스템 접근은 없습니다. 위험 모듈은 막히고, os에서 위험한 함수는 삭제됩니다. AI가 생성한 코드가 시스템을 건드릴 수 없도록 격리해둔 겁니다.
이 시스템은 온프레미스용 SLM 강화학습에 사용되어, 인터넷을 사용할 수 없어 GPT 및 Claude와 같은 LLM을 사용하지 못하는 환경에서도 완벽하게 동작합니다. 워크플로우 디자이너를 강화학습할 수 있는 이유는 데이터가 구조화되어 있기 때문입니다. 각 스텝의 도구 호출, 성공 여부, 오류 유형, 수정 결과가 이벤트로 남습니다. IR과 JSON은 일관된 그래프 구조를 가집니다. 이 데이터로 학습하면 "이런 요청에는 이렇게 워크플로우를 만들면 된다"는 패턴을 모델이 배울 수 있습니다. 작은 모델은 요구사항 정리와 오류 수정 제안 같은 좁은 작업을 맡기고, 큰 모델은 복잡한 흐름 합성에 집중시키는 구성이 자연스럽게 나옵니다.
DSL, 컴파일러, 샌드박스. 이 세 가지가 AI가 다른 AI를 만들 때 생기는 불안을 줄여줍니다. 설계는 사람의 의도에서 시작하고, 실행은 컴파일러와 샌드박스가 막아줍니다. AI가 이상한 걸 만들어도 컴파일 단계에서 걸러지고, 실행 환경은 격리되어 있습니다.
워크플로우 디자이너 에이전트는 이렇게 진화하고 있어요
워크플로우 디자이너 에이전트는 계속 진화하고 있습니다. 지금 우리가 집중하고 있는 방향을 공유해드릴게요.
열린 질문에서 시작하기
지금은 사용자가 어느 정도 구체적인 요구사항을 가지고 있어야 제 역할을 합니다. "CS 자동화 워크플로우 만들어줘"처럼요. 그런데 현실에서는 "자동화하고 싶긴 한데, 뭘 어떻게 해야 할지 모르겠다"는 상태에서 시작하는 경우가 많습니다. 막연히 "우리 팀 업무가 비효율적인 것 같은데..."라고 느끼는 정도입니다.
앞으로는 "어떤 에이전트를 만들고 싶으세요?"라는 열린 질문에서 대화를 시작하려고 합니다.
"요즘 어떤 업무에 시간을 많이 쓰세요?"
"그중에서 반복적이거나 귀찮은 부분이 있나요?"
"그 업무에서 실수가 나면 어떤 일이 생기나요?"
"지금은 어떤 도구로 그 업무를 처리하고 계세요?"
디자이너가 질문을 던지고, 답변을 통해 요구사항을 좁혀나갑니다. 마치 컨설턴트가 고객 니즈를 파악하듯이요. 충분한 정보가 모이면 그때 설계를 시작합니다. 사용자는 자신의 업무를 설명하기만 하면 되고, 그걸 워크플로우 구조로 번역하는 건 디자이너의 몫입니다.
기존 문서에서 시작하기
기업에는 이미 업무 매뉴얼, SOP, 프로세스 가이드 같은 문서가 있습니다. 수년간 쌓아온 업무 지식이 거기 들어 있습니다. 문제는 이 문서들이 "사람이 읽고 따라하는 용도"로 작성되어 있다는 점입니다. "고객 불만 접수 시, 먼저 사과 인사를 전하고, 문제 상황을 파악한 후..." 이런 식으로요. 사람한테는 이해가 되는데, AI 에이전트에게 그대로 던져주면 제대로 동작하지 않습니다.
이 문서들을 업로드하면 디자이너가 분석해서 자동화 가능한 워크플로우 구조로 변환하는 것도 준비하고 있습니다. "이 매뉴얼에서 자동화할 수 있는 부분은 여기고, 사람이 개입해야 하는 부분은 여기입니다. 이렇게 워크플로우를 구성하면 어떨까요?"
수년간 쌓인 업무 지식을 처음부터 다시 정리할 필요가 없어집니다. 있는 자산을 그대로 활용하는 겁니다.
디버그까지 함께하기
워크플로우를 만들고 나면 끝이 아닙니다. 실제로 돌려보면 예상 못한 오류가 터지고, 엣지 케이스가 드러나고, 개선점이 보입니다.
문제는 설계 지식이 없어서 디자이너에게 맡긴 건데 디버그는 혼자 하라는 건 앞뒤가 맞지 않다는 겁니다. 에러 로그를 봐도 뭘 고쳐야 하는지 모릅니다. "노드 7에서 타임아웃 발생"이라고 해도, 노드 7이 뭐하는 노드인지, 왜 타임아웃이 났는지, 어떻게 고쳐야 하는지 알 수 없습니다.
앞으로는 실행 중 발생한 오류를 디자이너가 분석합니다. 단순히 "여기서 에러 났어요"를 알려주는 게 아니라, "이 부분을 이렇게 바꾸면 될 것 같아요"라고 제안합니다. "노드 7은 외부 API를 호출하는 노드인데, 타임아웃이 30초로 설정되어 있어요. 이 API는 응답이 느릴 때 1분까지 걸릴 수 있으니, 타임아웃을 90초로 늘리거나 재시도 로직을 추가하는 게 좋겠습니다. 수정할까요?"
승인하면 바로 수정을 실행합니다. 설계부터 디버그까지 한 흐름으로 이어지는 겁니다.
실제 사용 로그와 학습 결과가 다시 설계 도구로 돌아와 더 나은 워크플로우를 만들게 될 겁니다. 많은 고객이 비슷한 패턴의 오류를 겪으면, 디자이너가 미리 그 케이스를 고려해서 워크플로우를 제안하게 됩니다. 시간이 지날수록 똑똑해지는 구조입니다.
나가며
AI가 알아서 하는 것과, AI를 제대로 업무에 쓰는 것은 다릅니다.
B2B 환경에서 AI를 실질적으로 쓰려면 통제 가능하고, 추적 가능하고, 재사용 가능한 구조가 필요합니다. 실수했을 때 원인을 찾을 수 있어야 하고, 누가 어떤 결정을 했는지 기록이 남아야 하고, 한 번 만든 걸 다른 데서도 쓸 수 있어야 합니다. 워크플로우는 그 구조를 제공합니다.
그리고 워크플로우 설계의 진입 장벽을 낮추는 것이 우리가 풀고 있는 문제입니다. 업무를 아는 사람이 도구를 몰라도 되게, 말로 설명하면 워크플로우가 만들어지게, 실수해도 같이 고쳐나갈 수 있도록 말입니다.
