에이전틱 워크플로우 컨설팅이란 무엇인가? 데이터 리더를 위한 실무 가이드

모두가 사용하지만 아무도 정의하지 않는 용어

당신의 CTO가 컨퍼런스에서 돌아와 팀이 "에이전틱(agentic)하게" 변해야 한다고 말했습니다. 지난주에는 한 벤더가 "에이전틱 데이터 플랫폼(agentic data platform)"을 제안했습니다. LinkedIn은 고객 지원부터 공급망 관리까지 모든 것을 변화시키고 있는 에이전틱 워크플로우(agentic workflows)에 관한 게시물로 가득합니다.

하지만 당신이 세 사람에게 "에이전틱"이 당신의 데이터 운영에 실제로 무엇을 의미하는지 물으면, 네 가지 답변이 돌아옵니다.

이것은 어휘의 문제가 아닙니다. 전략의 문제입니다. 조직들은 무엇을 사고, 구축하며, 무엇을 위해 채용하는지에 대한 공유된 정의 없이 에이전틱 AI(agentic AI)에 대해 수억 원대의 결정을 내리고 있습니다. 유행어와 아키텍처(architecture) 사이의 이 간극이 대부분의 프로젝트가 실패하는 지점입니다. 기술이 작동하지 않아서가 아니라, 그것이 무엇을 해야 하는지에 대해 아무도 합의하지 않았기 때문입니다.

이 가이드는 그 간극을 메우기 위한 실무자의 시도입니다. 벤더의 영업 멘트도, 막연한 설명도 없습니다. 오직 명확한 정의, 실제 사례, 그리고 에이전틱 워크플로우 컨설팅(agentic workflow consulting)이 당신의 팀에 실제로 필요한 것인지 결정하기 위한 프레임워크만을 제공합니다.

"에이전틱"이 실제로 의미하는 것 (쉬운 언어로)

전통적인 데이터 파이프라인(data pipelines)은 결정론적(deterministic)입니다. 단계를 정의하고, 순서대로 연결한 뒤 실행합니다. 단계 A가 단계 B에 데이터를 전달하고, 단계 B가 단계 C에 전달합니다. 입력값의 형태가 바뀌면 파이프라인은 깨지고 사람이 이를 수정해야 합니다. 파이프라인은 적응하거나, 추론하거나, 결정을 내리지 않습니다. 그저 실행할 뿐입니다.

로봇 프로세스 자동화 (RPA, Robotic process automation)는 조금 더 똑똑하지만 여전히 스크립트(scripted) 방식입니다. 인간의 행동을 기록하고 이를 재현합니다. 여기를 클릭하고, 저기에 타이핑하고, 이 파일을 이동합니다. UI가 변경되거나 예외 상황(edge case)이 발생하면, 봇은 파이프라인이 깨지는 것과 똑같은 방식으로 작동을 멈춥니다. 즉, 멈춰서 사람이 나타나기를 기다립니다.

에이전틱 워크플로우 (Agentic workflows)는 근본적으로 다릅니다. 에이전틱 시스템은 자신의 작업에 대해 추론하고, 문맥 (context)을 바탕으로 의사결정을 내리며, 모든 시나리오에 대해 미리 작성된 경로 없이도 행동을 취할 수 있는 구성 요소들을 가지고 있습니다. "만약 X라면 Y를 한다"는 식의 방식 대신, 에이전틱 노드 (agentic node)는 모호한 입력을 평가하고, 접근 방식 중 하나를 선택하며, 자신의 출력을 검증하고, 신뢰도가 낮을 경우 사람에게 알리는 것을 포함하여 적절한 다음 단계로 작업을 라우팅 (route)할 수 있습니다.

실질적인 차이는 시스템이 예기치 않은 상황을 처리하는 방식에서 나타납니다. 새로운 컬럼 이름이 포함된 CSV 파일을 만난 전통적인 ETL 파이프라인은 실패합니다. 반면 에이전틱 파이프라인은 새로운 컬럼을 조사하고, 문맥으로부터 그 의미를 추론하며, 이를 올바른 목적지 필드에 매핑 (map)하고, 나중에 사람이 검토할 수 있도록 해당 결정 사항을 로그 (log)에 남길 수 있습니다.

이것은 범용 인공지능 (AGI)이 아닙니다. 데이터베이스에 연결된 챗봇도 아닙니다. 이것은 자율적인 구성 요소들이 모호함을 처리하고, 자신의 작업을 검증하며, 정의된 체크포인트 (checkpoint)에서 인간과 협업하는 특정한 아키텍처 패턴 (architectural pattern)입니다. 컨설턴트들이 "에이전틱 워크플로우"라고 말할 때 의미하는 것, 혹은 의미해야 하는 것이 바로 이 패턴입니다.

에이전틱 워크플로우가 실제 문제를 해결하는 지점

모든 데이터 문제가 에이전틱 접근 방식의 혜택을 받는 것은 아닙니다. 데이터 운영이 특정 특성을 공유할 때 이 패턴은 그 복잡성에 상응하는 가치를 발휘합니다.

첫 번째는 소스의 다양성 (source diversity)입니다. 증권사 API, 은퇴 계좌 피드, 부동산 관리 플랫폼, 예산 관리 도구, 암호화폐 거래소, 세무 문서 포털, 그리고 수동 설정 스프레드시트 등 7개의 서로 다른 시스템에서 데이터를 가져오는 경우, 통합해야 할 표면적 (integration surface)은 엄청나게 넓어집니다. 각 소스는 자신만의 형식, 자신만의 오류 모드, 그리고 무엇이 "트랜잭션 (transaction)"인지에 대한 자신만의 정의를 가지고 있습니다. 전통적인 파이프라인은 소스가 출력 형식을 변경할 때마다 깨져버리는 취약한 변환 로직 (transformation logic)으로 이를 처리합니다. 에이전틱 구성 요소는 하드코딩된 매핑 (hardcoded mappings)에 전적으로 의존하는 대신 데이터에 대해 추론함으로써 이러한 변동성의 일부를 흡수할 수 있습니다.

두 번째는 검증 복잡성 (validation complexity)입니다. 잘못된 수치로 인한 비용이 높은 경우 — 세금 계산, 재무 보고, 규제 제출 등 — 유닛 테스트 (unit tests) 이상의 것이 필요합니다. 한 프로세스가 결과를 생성하면 별도의 프로세스가 다른 각도에서 이를 확인하는 독립적인 검증 (independent verification)이 필요합니다. 이것이 바로 메이커-체커 패턴 (maker-checker pattern)입니다. 코드가 계산을 생성하면, LLM이 이를 독립적으로 검증하고, 불일치가 발생하면 인간의 검토를 위해 플래그(flag)를 지정합니다. 이 방식은 단순히 공식과 일치하는지 여부뿐만 아니라, 문맥상 숫자가 "타당한지"에 대해 추론할 수 있기 때문에 결정론적 검증 (deterministic validation)이 놓치는 오류를 잡아냅니다.

세 번째는 의사결정 분기 (decision branching)입니다. 데이터 내용에 따라 작업 경로를 다르게 라우팅해야 하는 경우 — 이 트랜잭션은 주식 매각이고, 저것은 배당금이며, 이것은 다른 세무 처리가 필요한 경우 — 의사결정 트리 (decision tree)는 하드코딩 (hard-code)할 수 있는 속도보다 더 빠르게 성장합니다. 에이전틱 노드 (Agentic nodes)는 일련의 기준에 따라 각 항목을 평가하고 적절한 처리 경로를 선택할 수 있어, if-else 분기의 조합 폭발 (combinatorial explosion)을 줄여줍니다.

실무에서의 모습

추상적인 설명만으로는 한계가 있습니다. 실제 문제를 해결하기 위해 구축된 실제 시스템으로서의 에이전틱 워크플로우 (agentic workflow)는 다음과 같습니다.

문제: IRS(미국 국세청) 제출용 세무 일정표, 은퇴 포트폴리오 대시보드 및 작성된 PDF 양식을 생성하기 위해 서로 연결되지 않은 7개의 금융 데이터 소스가 필요했습니다. 기존 프로세스는 매 세금 시즌마다 한 명의 담당자, 스프레드시트, 회계사와의 전화 통화, 그리고 몇 주간의 수동 조정 (manual reconciliation) 작업을 포함했습니다.

해결책: 19개의 노드로 구성된 LangGraph 파이프라인입니다. LangGraph는 상태 유지형 (stateful) 다단계 AI 워크플로우를 유향 그래프 (directed graphs)로 구축하기 위한 프레임워크입니다. 그래프의 각 노드는 수집 (ingestion), 변환 (transformation), 검증 (validation), 출력 생성 (output generation)과 같은 처리 단계를 나타내며, 그래프 구조는 데이터가 노드 사이에서 어떻게 흐르는지를 정의합니다.

이 아키텍처는 네 가지 계층으로 나뉩니다. 인제스션 계층 (ingestion layer)은 전용 어댑터를 통해 각 데이터 소스에 연결되어 원시 데이터 (raw data)를 공통 형식으로 정규화합니다. 변환 계층 (transformation layer)은 13개의 모델과 58개의 테스트를 포함한 dbt를 사용하여 분석을 위해 데이터를 재구성합니다. 이는 전통적이고 결정론적인 (deterministic) 데이터 엔지니어링이며, 마땅히 그러해야 합니다. 모든 것이 반드시 "에이전틱 (agentic)"할 필요는 없습니다. 검증 계층 (validation layer)은 에이전틱 패턴이 제 역할을 다하는 곳입니다. 이곳에는 코드 생성 결과가 LLM 기반 검사기 (checker)에 의해 독립적으로 검증되는 메이커-체커 (maker-checker) 노드가 있으며, 의견이 불일치할 경우 인간의 검토 (human review)로 전달됩니다. 출력 계층 (output layer)은 검증되고 변환된 데이터로부터 최종 산출물(artifacts)—세무 일정, 대시보드, 작성된 양식 등—을 생성합니다.

메이커-체커 검증은 면밀히 살펴볼 가치가 있습니다. 파이프라인이 자본 이득 (capital gains) 수치를 계산할 때, 계산 노드는 취득 원가 (cost basis), 매도 가격, 보유 기간을 바탕으로 숫자를 생성합니다. 별도의 체커 노드는 동일한 원시 거래 데이터를 수신하여 자본 이득이 얼마가 되어야 하는지를 독립적으로 추정합니다. 두 숫자가 정의된 허용 오차 범위 내에서 일치하면 결과가 통과됩니다. 만약 불일치하면, 해당 거래는 두 숫자와 원시 데이터가 함께 플래그(flag) 처리되며, 인간이 최종 결정을 내립니다.

이는 코드를 불신하는 것에 관한 것이 아닙니다. 결정론적 로직이 놓치는 엣지 케이스 (edge cases)—워시 세일 (wash sales), 로트 선택 (lot selection)의 모호함, 취득 원가를 비자명한 방식으로 변경하는 기업 활동 등—를 포착하는 것에 관한 것입니다. 이 패턴은 실제로 금전적 손실을 초래할 수 있었던 실제 오류들을 잡아냈습니다.

결과적으로, 과거에 몇 주간의 수동 작업이 필요했던 일이 이제는 몇 시간 만에 실행됩니다. 이는 단 하나의 마법 같은 AI가 인간을 대체했기 때문이 아니라, 아키텍처가 문제를 각 구성 요소로 분해하여 각 요소가 가장 잘하는 일을 처리하도록 했기 때문입니다. 즉, 계산에는 결정론적 코드 (deterministic code)를, 검증에는 LLM 추론 (LLM reasoning)을, 모호한 사례에는 인간의 판단 (human judgment)을 사용하는 것입니다.

외부의 도움이 필요한 때 (그리고 필요하지 않은 때)

에이전틱 워크플로우 컨설팅 (Agentic workflow consulting)이 존재하는 이유는 개념을 이해하는 것과 실제 프로덕션 시스템 (production system)을 출시하는 것 사이에 간극이 있기 때문입니다. 하지만 모든 팀이 이를 위해 인력을 채용할 필요는 없습니다. 여기 솔직한 프레임워크를 제시합니다.

만약 귀하의 팀이 이전에 (단순한 프로토타입이 아닌) 프로덕션 AI 시스템을 구축한 경험이 있고, 데이터 소스가 적으며 잘 구조화되어 있으며, 검증 요구사항이 표준적이고, 학습 곡선을 고려할 수 있을 만큼 일정이 유연하다면 아마 컨설턴트가 필요하지 않을 것입니다. 그런 경우라면 프레임워크는 문서화가 잘 되어 있고 패턴도 확립되어 있으므로, AI 경험이 있는 시니어 엔지니어 (senior engineer)가 스스로 해결할 수 있습니다.

반면, 귀하의 팀이 전통적인 데이터 엔지니어링 (data engineering)에는 강하지만 AI가 강화된 파이프라인 (AI-augmented pipelines)을 프로덕션에 출시해 본 적이 없다면 외부의 도움이 필요할 가능성이 높습니다. "챗봇 데모를 만들었다"와 "이 시스템이 새벽 2시에 금융 데이터를 가지고 무인으로 작동한다" 사이의 간극은 보기보다 훨씬 넓습니다. 이는 지능의 문제가 아니라, 실패 모드 (failure modes)가 어디에 숨어 있는지 아는 것에 관한 문제입니다. 어떤 검증 패턴 (validation patterns)이 어떤 오류를 잡아내는지, 파이프라인이 부분적인 실패로부터 우아하게 복구될 수 있도록 상태 관리 (state management)를 어떻게 구조화할 것인지, 그리고 병목 현상이 되는 대신 실제로 활용되는 인간 검토 게이트 (human review gates)를 어떻게 설정할 것인지에 관한 문제입니다.

또한 이해관계가 높고 일정이 촉박할 때도 도움이 필요합니다. 금융 데이터, 의료 데이터, 규제 산업 등은 프로덕션 데이터에서 시행착오를 거치며 에이전틱 패턴 (agentic patterns)을 학습하고 싶지 않은 환경입니다.

솔직한 사실은 대부분의 팀이 그 중간 어디쯤에 위치한다는 것입니다. 그들은 강력한 데이터 엔지니어링 기반을 갖추고 있지만, 프로덕션 환경에서의 에이전틱 아키텍처 (agentic architecture)가 가진 특유의 복잡성을 헤쳐 나간 경험은 없습니다. 이전에 이를 수행해 본 경험이 있는 컨설턴트는 귀하를 대신해 일을 해주는 것이 아니라, 막다른 길로 가지 않도록 방향을 잡아줌으로써 수개월의 반복 작업을 수주로 단축할 수 있습니다.

컨설턴트가 실제로 이를 알고 있는지 평가하는 방법

에이전틱 AI 분야는 매우 새롭기 때문에 자격 증명 (credentials)을 신뢰하기 어렵습니다. 유의미한 의미에서의 자격증은 존재하지 않습니다. 따라서 평가의 책임은 귀하에게 있습니다.

데모가 아닌 실제 운영 사례(production examples)를 요구하십시오. 누구나 세 개의 API 호출을 연결한 프로토타입을 만들고 이를 "에이전틱(agentic)"이라고 부를 수 있습니다. 실제 운영 시스템(production systems)은 실패를 처리하고, 출력을 검증하며, 실행 간의 상태(state)를 관리하고, 사람이 지켜보지 않아도 작동합니다. 파이프라인 중간에 데이터 소스가 다운되면 어떤 일이 발생하는지 물으십시오. 검증 오류(validation errors)가 어떻게 드러나는지 물으십시오. 모니터링(monitoring)은 어떤 모습인지 물으십시오.

검증 방법론(validation methodology)에 대해 물으십시오. 컨설턴트가 귀하의 데이터로 의사결정을 내리는 시스템을 구축한다면, 그 결정들이 어떻게 검증되는지에 대해 명확한 답변을 가지고 있어야 합니다. 제작자-검토자(maker-checker) 패턴이 하나의 접근 방식입니다. 다른 방식들도 있습니다. 위험 신호(red flag)는 그들이 어떤 패턴을 사용하는가가 아니라, 패턴을 아예 가지고 있지 않다는 사실입니다.

인수인계(handoff)에 대해 물으십시오. 좋은 프로젝트(engagement)는 영구적인 의존성을 만들지 않습니다. 프로젝트가 끝날 때는 문서화, 교육된 팀원, 그리고 귀하의 엔지니어들이 유지 관리하고 확장할 수 있는 시스템이 남아야 합니다. 만약 컨설턴트의 제안이 그들이 시스템을 영원히 운영할 것임을 암시한다면, 그것은 컨설팅이 아니라 서비스 계약(service contract)입니다.

그들이 무엇을 자동화하지 않을 것인지 물으십시오. 숙련된 실무자들은 경계가 어디인지 알고 있습니다. 어떤 결정은 인간의 몫으로 남겨두어야 합니다. 어떤 데이터 변환(data transformations)은 AI 추론(AI reasoning)보다 결정론적 코드(deterministic code)로 처리하는 것이 더 낫습니다. 모든 것을 "에이전틱(agentic)"하게 만들고자 하는 컨설턴트는 해당 패턴이 언제 적용되지 않는지를 알 만큼 패턴을 충분히 이해하지 못한 것입니다.

의사결정하기

에이전틱 워크플로우 컨설팅은 마켓플레이스에서 둘러보는 제품 카테고리가 아닙니다. 이것은 특정 종류의 전문 지식, 즉 데이터 운영(data operations)에 적용되는 실제 운영 AI 아키텍처(production AI architecture)이며, 어떤 팀에는 필요하지만 어떤 팀에는 필요하지 않습니다.

귀하의 조직에 이러한 도움이 필요한지 평가하고 있다면, 가장 명확한 신호는 귀하의 데이터 과제가 위에서 언급한 세 가지 특성을 포함하고 있는지 여부입니다: 취약한 통합(brittle integrations)을 압도하는 소스의 다양성, 결정론적 테스트(deterministic testing)가 잡아낼 수 있는 범위를 넘어서는 검증 요구사항, 그리고 하드코딩(hard-code)할 수 있는 속도보다 빠르게 증가하는 의사결정 복잡성입니다.

만약 이러한 상황들이 귀하의 상황을 설명하고 있다면, 처음부터 올바른 아키텍처 (architecture)를 구축하는 데 투자하는 것이 잘못된 것을 만들고 작동할 때까지 반복하며 수정하는 것보다 거의 항상 비용이 적게 듭니다.

귀하의 구체적인 상황에 대해 논의하고 싶다면 — 그것이 실제 프로젝트 계약으로 이어지든, 혹은 귀하에게 무엇이 필요한지에 대한 더 명확한 그림을 얻는 과정이든 상관없이 — 문의해 주세요. 저희는 또한 이러한 패턴들이 실제 현장에서 어떻게 작동하는지 보여주는 상세한 사례 연구 (case studies)를 게시하고 있습니다.