[지디넷코리아]최근 여러 기업 인공지능 전환(AX) 프로젝트를 접하면서 한 가지 아쉬움을 느낀다. 어떤 AI를 도입할지, AI 에이전트를 어디에 적용할지에 대한 관심은 높아졌지만 정작 AI가 연결돼 일해야 할 기존 시스템을 얼마나 제대로 이해하고 있는지에 대한 고민은 상대적으로 부족하다.예를 들어 고객이 AI 에이전트에게 "어제 주문한 상품을 취소해 주세요"라고 요청한다고 생각해 보자. 겉으로 보기에는 AI가 기존 시스템의 주문 취소 기능을 호출하면 끝날 것처럼 보인다. 하지만 실제 시스템에서는 이야기가 달라진다.하나의 주문 취소 업무 안에는 결제 환불, 재고 복구, 포인트 회수, 배송 중지 등 여러 기능이 복잡하게 연결돼 있을 수 있다. 어떤 데이터가 변경되는지, 처리 중 오류가 발생하면 어디까지 되돌려야 하는지, 다른 업무에는 어떤 영향을 미치는지 명확하지 않은 경우도 적지 않다.그렇다면 이런 시스템에 주문 취소 권한을 AI에게 맡겨도 괜찮을까? 결국 중요한 것은 AI가 주문을 취소할 능력이 있느냐가 아니다. 우리가 AI에게 맡기려는 업무를 얼마나 정확하게 이해하고 있고 그 실행 결과를 얼마나 신뢰할 수 있느냐의 문제다.기업 업무 시스템은 하루아침에 만들어지지 않는다. 10년, 20년 동안 새로운 요구사항을 반영하고 기능을 추가하면서 지금의 모습으로 발전해 왔다. 그 과정에서 처음에는 독립적이었던 기능들이 서로의 데이터를 참조하고 하나의 기능이 여러 업무를 동시에 처리하면서 구조는 점점 복잡해진다.더 큰 문제는 이러한 구조를 정확하게 설명할 수 있는 자료가 충분하지 않다는 것이다. 설계 문서는 오래전에 작성됐지만 실제 시스템은 수차례 변경돼 문서와 다른 모습으로 운영되기도 한다. 결국 소스코드를 다시 분석하거나 오랫동안 유지보수를 담당한 개발자의 경험과 기억에 의존하는 경우가 많다.이전에 진행했던 프로젝트에서 우리가 검증 목적으로 분석했던 한 ERP 시스템에는 74개 화면과 275개 기능(API)이 있었다. 분석 결과 서로 다른 업무 영역의 경계를 넘나드는 기능은 7개였는데 흥미롭게도 모두 데이터를 변경하는 기능이었다. 전체 기능에서 차지하는 비중은 크지 않았다. 하지만 이런 소수 기능이 시스템의 복잡성과 변경 위험을 높이는 요인이 될 수 있었다.사람이 직접 업무를 처리할 때는 경험과 업무 지식을 바탕으로 예외 상황에 대응할 수 있다. 하지만 AI 에이전트가 업무를 수행하려면 조건이 달라진다. "이 기능은 무엇을 하는가?", "어떤 데이터를 책임지는가?", "다른 업무와 어떻게 연결되는가?", "실패했을 때 어떻게 복구해야 하는가?" 이 질문에 답할 수 있어야 AI에게 실제 업무를 맡길 수 있다.AI 기술은 빠르게 발전하고 있다. 새로운 모델과 에이전트가 등장하면서 AI가 수행할 수 있는 기업 업무 범위도 넓어지고 있다. 하지만 기업의 기존 시스템은 이러한 변화에 빠르게 대응하기 어려운 경우가 많다. 하나의 기능을 변경하려 해도 다른 업무에 어떤 영향을 미치는지 확인해야 하고 작은 수정에도 시스템 전체를 다시 검증해야 하는 경우가 있다.이런 문제를 경험하면서 효과적인 AX를 위해서는 단순히 AI를 기존 시스템에 연결하는 것을 넘어 AI가 필요한 업무 기능을 명확하게 이해하고 호출할 수 있는 구조가 필요하다고 생각하게 됐다. 그 과정에서 주목한 것이 마이크로서비스 아키텍처(MSA)였다. MSA는 하나의 거대한 시스템을 업무 특성에 따라 독립적인 서비스로 구성하고 각 서비스가 자신의 업무와 데이터를 책임지도록 하는 방식이다.하지만 시스템을 잘게 나눈다고 문제가 해결되는 것은 아니다. 실제 MSA 전환 프로젝트에서는 기존 시스템을 어떤 기준으로 나눌 것인지, 각 서비스가 어떤 데이터를 책임져야 하는지 결정하는 과정 자체가 어렵다. 같은 시스템이라도 설계자의 경험과 판단에 따라 서비스의 경계가 달라질 수 있고 설계 단계에서는 독립적으로 나눴지만 실제 개발 과정에서는 여러 서비스가 다시 강하게 연결되는 일도 발생한다.쿠버네티스나 CI/CD, 데브옵스 환경을 구축하는 것도 중요하다. 그러나 새로운 인프라 위로 시스템을 옮긴다고 기존 업무 구조까지 자동으로 개선되는 것은 아니다. 결국 중요한 것은 기존 시스템을 정확하게 분석하고 업무의 경계를 일관된 기준으로 찾아내며 그 설계가 실제 구현까지 제대로 이어졌는지 검증할 수 있느냐였다.처음부터 새로운 플랫폼을 만들려고 했던 것은 아니다. 여러 프로젝트를 수행하면서 비슷한 질문을 반복해서 마주했다. "왜 기존 시스템을 분석하는 데 매번 많은 시간이 필요한가?", "왜 비슷한 설계 과정을 반복하면서도 프로젝트마다 결과가 달라지는가?", "설계자가 바뀌어도 일관된 기준으로 시스템을 분석할 수는 없는가?", "우리가 만든 설계가 실제로 올바른지 확인할 방법은 없는가?" 이런 질문이 쌓이면서 하나의 생각에 이르렀다."설계 방법론을 문서로만 남겨두지 말고 실제로 수행하고 검증할 수 있는 시스템으로 만들어보자" 이것이 'MuSAnga(뮤산가)'를 개발하게 된 출발점이다. MuSAnga는 기존 시스템의 소스코드와 데이터베이스 구조를 분석해 업무와 데이터 간 관계를 파악하고 이를 바탕으로 서비스 경계를 식별하는 과정을 체계화하려는 고민에서 시작됐다.이 과정에서 AI는 방대한 소스코드를 분석하고 업무와 데이터 사이의 관계를 찾아내는 역할을 할 수 있다. 하지만 우리가 중요하게 생각한 것은 AI가 빠르게 답을 만들어내는 것만이 아니었다. 왜 그런 결과가 나왔는지 설명할 수 있어야 하고 그 설계가 실제로 타당한지 검증할 수 있어야 한다. AI가 제안한 결과를 사람이 이해하고 검증할 수 없다면 실제 기업의 핵심 시스템에 적용하기 어렵기 때문이다.MuSAnga가 기존의 단순 분석이나 설계 자동화 방식과 다른 지점도 여기에 있다. 레거시 시스템을 이해하는 것에서 시작해 업무 단위를 식별하고 AI 에이전트가 활용할 수 있는 시스템 구조로 이어지도록 하는 것이 우리가 해결하고자 하는 문제다.앞으로 AI 에이전트가 기업의 실제 업무를 수행하는 영역은 더욱 확대될 것이다. 그럴수록 기업은 "어떤 AI를 도입할 것인가"와 함께 "우리 시스템은 AI에게 일을 맡길 준비가 돼 있는가"를 질문해야 한다.AX는 기존 시스템에 AI를 붙이는 것으로 끝나서는 안 된다. AI가 기업의 실제 업무를 안정적으로 수행하려면 업무 경계와 데이터의 책임이 명확해야 하고 필요한 기능을 AI가 안전하게 활용할 수 있는 구조가 준비돼 있어야 한다.MuSAnga를 개발하게 된 이유도 결국 여기에 있다.이번 글에서는 왜 이런 고민을 시작하게 됐는지 이야기했다. 다음 글에서는 한 단계 더 들어가 MuSAnga가 기존 레거시 분석과 MSA 전환 방식과 무엇이 다른지, 복잡하게 얽혀 있는 시스템에서 어떻게 업무의 경계를 찾아내고 AI 에이전트가 활용할 수 있는 구조로 만들어가는지 이야기해 보려 한다.이후에는 실제 기업의 시스템에서 이를 어떻게 활용할 수 있는지, 그리고 PoC와 적용 과정에서 어떤 경험과 인사이트를 얻었는지도 차례로 다뤄볼 예정이다.
Continue to ZDNet Korea →You are being forwarded in 6s — stay on this page