AI 어벤져스, ‘팀플’의 함정: 각자 다른 시간 속에서 싸우고 있었다

도입: AI판 ‘어벤져스’의 꿈, 그러나 팀은 종종 깨진다

최근 인공지능 분야의 가장 뜨거운 화두 중 하나는 단연 ‘AI 에이전트’입니다. 마치 영화 어벤져스처럼 각기 다른 능력을 지닌 AI 전문가들이 팀을 이뤄, 사람이 시키지 않아도 스스로 목표를 달성하는 그림입니다. 여행 계획을 짜주는 에이전트, 시장을 분석해 보고서를 쓰는 에이전트, 코드를 짜고 오류를 수정하는 에이전트가 한데 모여 복잡한 프로젝트를 수행하는 모습은 공상과학 영화의 한 장면을 현실로 소환하는 듯합니다.

이러한 다중 에이전트 시스템(Multi-Agent System, 줄여서 MAS)이 인류의 생산성을 비약적으로 높일 것이라는 기대가 큽니다. 하지만 장밋빛 전망 이면에는 잘 드러나지 않는 심각한 균열이 있습니다. 이 똑똑한 AI 팀이 예기치 않게 작업을 망치거나, 서로 엉뚱한 소리를 하며 와해되는 사례가 빈번하게 관찰되기 때문입니다.

많은 이들이 이 문제를 AI의 ‘소통 능력’ 부족이나 ‘지시 이해 능력’의 한계로 여깁니다. 하지만 최근 발표된 한 논문은 문제의 본질이 전혀 다른 곳에 있다고 지적합니다. arXiv에 공개된 '다중 에이전트 시스템은 동시성 제어를 우선시해야 한다'는 제목의 이 연구는, AI 팀의 실패가 '협업'의 문제가 아니라 '질서'의 문제라고 일갈합니다. 구체적으로는 수십 년 된 컴퓨터 과학의 고전적 난제, ‘동시성 제어(Concurrency Control)’의 부재가 문제의 핵심이라는 것입니다.

오늘은 이 문제를 깊이 파고들어 보겠습니다. 자극적인 제목에 휘둘리지 않고, AI 에이전트라는 기술이 왜 아직 모래 위에 지은 성일 수 있는지, 그 근본적인 한계를 짚어보는 것이 중요합니다. 다만 연구는 정확히 읽어야 합니다. 이것은 AI의 지능 문제가 아니라, AI가 서 있는 땅의 단단함에 관한 이야기입니다.

문제의 본질: 각자 다른 시계를 보는 AI 직원들

'동시성 제어'라는 말이 어렵게 들릴 수 있습니다. 아주 쉬운 비유로 시작하겠습니다. 여러 명의 요리사가 하나의 주방에서 같은 요리책을 보고 파스타를 만든다고 상상해 봅시다. 이 요리책이 바로 AI 에이전트들이 함께 보는 정보, 즉 '공유 상태(Shared State)'입니다.

• 1단계: 요리사 A가 요리책을 보고 '소금 10g을 넣으라'는 내용을 확인합니다. 그리고 소금을 가지러 창고로 갑니다.
• 2단계: 그 사이, 주방에 새로 들어온 요리사 B가 요리책을 보더니 '이 레시피는 너무 짜다'며 '소금 10g'을 '소금 5g'으로 고쳐 씁니다.
• 3단계: 창고에서 돌아온 요리사 A는 자기가 봤던 '10g'이라는 내용을 기억하고 그대로 소금 10g을 넣습니다. 그는 요리책이 바뀌었다는 사실을 모릅니다.
• 4단계: 잠시 후 요리사 C가 들어와 요리책의 '소금 5g'이라는 내용을 보고, 이미 냄비에 들어간 소금 양을 맛봅니다. 맛을 보니 생각보다 훨씬 짭니다. 그는 요리사 A가 10g을 넣었다는 사실을 모르고, '누군가 실수로 소금을 더 쏟았나 보다'라고 생각하며 물을 더 부어 간을 맞추려 합니다.

결과물은 어떻게 될까요? 누구의 의도와도 다른, 정체불명의 음식이 탄생합니다. 여기서 요리사들은 각자의 역할에 충실했지만, 팀의 결과물은 실패했습니다. 문제는 요리사들의 실력이 아니라, 모두가 같은 최신 버전의 '요리책'을 보고 일한다는 규칙이 없었기 때문입니다.

AI 에이전트 시스템에서 벌어지는 일이 바로 이것입니다. 여기서 요리사는 각자의 역할을 부여받은 'AI 에이전트'이고, 요리책은 시스템이 공유하는 데이터나 작업 상태입니다. 특히 문제가 심각해지는 이유는 오늘날의 AI, 즉 LLM(Large Language Model, 사람의 말을 흉내 내 문장을 만들어 내는 AI)의 특성 때문입니다. LLM은 사람처럼 '생각'하는 데 시간이 꽤 걸립니다. 요리사 A가 소금을 가지러 창고에 다녀오는 시간이 긴 것과 같습니다. 이 긴 '추론 시간' 동안 다른 에이전트가 공유 정보를 바꿔버릴 가능성이 매우 커집니다.

이로 인해 발생하는 대표적인 오류는 세 가지입니다.

1. 오래된 정보 읽기 (Stale Reads): 요리사 A처럼, 이미 과거의 정보가 된 것을 붙들고 잘못된 판단을 내리는 경우입니다.
2. 업데이트 유실 (Lost Updates): 요리사 B가 애써 '5g'으로 레시피를 수정했지만, 요리사 A의 행동 때문에 그 수정이 무의미해진 것처럼 한 에이전트의 중요한 작업이 다른 에이전트에 의해 덮어씌워지는 현상입니다.
3. 비일관적인 결과 (Inconsistent Outcomes): 최종 결과물이 논리적으로 설명되지 않고 예측 불가능하게 나오는, 마치 정체불명 파스타 같은 상황입니다.

결국 AI 에이전트들은 서로 다른 시간대에 존재하는 유령처럼, 각자 다른 현실을 보며 협업 아닌 협업을 하고 있었던 셈입니다.

데자뷰: 50년 전 데이터베이스의 악몽이 재현되다

흥미로운 점은 이 문제가 전혀 새롭지 않다는 사실입니다. AI 분야에서는 신선한 충격일지 몰라도, 컴퓨터 과학의 다른 분야, 특히 데이터베이스 시스템에서는 1970년대부터 씨름해 온 아주 오래된 문제입니다.

은행의 현금인출기(ATM)를 생각해 봅시다. 제 계좌에 10만 원이 있습니다. 제가 서울역 ATM에서 10만 원을 인출하는 동시에, 제 가족이 부산역 ATM에서 같은 계좌의 10만 원을 인출하려 합니다. 두 ATM 기기가 거의 동시에 제 계좌 잔액 '10만 원'을 확인합니다. 그리고 둘 다 '인출 가능'이라고 판단하고 돈을 내어준다면 어떻게 될까요? 은행은 10만 원의 손실을 입게 됩니다. 잔액은 -10만 원이 되는, 있어서는 안 될 일이 벌어집니다.

이런 사태를 막기 위해 데이터베이스 엔지니어들은 수십 년간 정교한 동시성 제어 기술을 발전시켜 왔습니다. 대표적인 것이 '락(Lock)'과 '트랜잭션(Transaction)'입니다.

• 락 (Lock): 말 그대로 '잠금장치'입니다. 한 사람이 화장실에 들어가 문을 잠그면 다른 사람은 그 사람이 나올 때까지 기다려야 합니다. 마찬가지로, 서울역 ATM이 제 계좌에 접근해 '인출 작업'을 시작하는 순간, 해당 계좌 정보를 잠가버립니다. 부산역 ATM은 잠금이 풀릴 때까지 기다려야 합니다. 서울역에서 인출이 끝나고 잔액이 0원으로 업데이트된 후에야, 부산역 ATM은 '잔액 부족'이라는 정확한 정보를 읽게 됩니다.

• 트랜잭션 (Transaction): 여러 단계를 하나의 묶음(논리적 단위)으로 처리하는 개념입니다. 'A 계좌에서 돈을 빼서 B 계좌로 옮긴다'는 송금 작업은 'A 계좌 출금'과 'B 계좌 입금'이라는 두 단계로 이뤄집니다. 트랜잭션은 이 두 단계가 모두 성공해야만 전체를 '완료'로 처리하고, 중간에 하나라도 실패하면 모든 것을 '시작 전 상태'로 되돌려 버립니다. '모 아니면 도' 방식입니다. 이를 통해 데이터의 정합성을 보장합니다.

결국 지금 AI 에이전트가 겪는 혼란은, 50년 전 데이터베이스 학자들이 풀었던 문제를 다른 옷을 입고 다시 마주한 것에 가깝습니다. 차이점을 표로 정리하면 다음과 같습니다.

AI 연구자들이 '지능'을 높이는 데 몰두하는 동안, 시스템의 안정성을 떠받치는 '기반 공사'의 중요성을 잠시 잊었던 것은 아닐까요. 재현되는가, 조건은 무엇인가. 과거의 해결책에서 교훈을 얻어야 합니다.

흔한 오해 짚어보기: ‘소통’과 ‘프롬프트’만으로는 부족한 이유

이 지점에서 몇 가지 반론이나 오해가 생길 수 있습니다. 하나씩 짚고 넘어가겠습니다.

첫 번째 오해: "에이전트끼리 대화를 잘하도록 만들면 해결되지 않나요?"

일견 타당해 보입니다. AI 에이전트들이 서로 작업 진행 상황을 공유하고 조율하면 문제가 줄어들 것이라는 생각입니다. 실제로 많은 연구가 에이전트 간의 소통 프로토콜을 정교하게 만드는 데 집중하고 있습니다. 하지만 이는 문제의 본질을 비껴가는 해법입니다.

앞서든 요리사 비유로 돌아가 봅시다. 요리사들이 서로 끊임없이 대화한다고 가정해 보겠습니다. "나 지금 소금 넣으려고!", "나는 레시피를 5g으로 바꿨어!" 하지만 이 대화가 오가는 짧은 순간에도 누군가는 이미 행동에 들어갔을 수 있습니다. 더 근본적으로, '어떤 요리책 버전을 기준으로 삼을 것인가'에 대한 합의, 즉 정보에 접근하는 순서와 규칙이 없다면 소통은 혼란만 가중시킬 수 있습니다. 팀원들이 아무리 열심히 회의를 해도, 각자 들고 온 재무제표 버전이 다르면 엉뚱한 결론이 나오는 것과 같습니다. '어떤 버전의 정보를 볼 것인가'를 정하는 규칙이 소통 능력보다 먼저입니다. 메커니즘과 예언을 구분해야 합니다. 소통은 행동의 조율이지, 현실 인식의 통일이 아닙니다.

두 번째 오해: "더 똑똑한 AI(GPT-5 같은 차세대 모델)가 나오면 스스로 해결할 겁니다."

이 역시 AI의 '지능'에 대한 과도한 기대에서 비롯된 착각입니다. 아무리 운전을 잘하는 베테랑 운전자 100명이 모여도 신호등 없는 사거리는 아수라장이 됩니다. 교통 체증은 개별 운전자의 운전 실력 문제가 아니라, 차량의 흐름을 제어하는 규칙, 즉 '시스템'의 문제이기 때문입니다.

동시성 제어는 신호등, 차선, 교통 법규와 같은 '규칙'의 영역입니다. AI가 아무리 똑똑해져서 동시성 문제의 위험을 '이해'하게 되더라도, 시스템 차원에서 접근 순서를 통제하는 강제적인 규칙이 없다면 충돌을 피할 수 없습니다. 오히려 더 똑똑하고 자율적인 에이전트들이 각자의 판단에 따라 동시다발적으로 행동하려 들면서 문제는 더 심각해질 수도 있습니다. 문제 해결 능력(지능)과 질서 유지(규칙)는 다른 차원의 문제입니다. 지금 필요한 것은 더 똑똑한 운전자가 아니라, 더 잘 설계된 신호등 시스템입니다.

모래 위의 AI 성: 왜 지금 동시성 제어가 중요한가

이 문제가 단순히 학술적인 논의에 그치지 않는 이유는, AI 에이전트 시스템이 현실의 중요한 문제들을 해결할 후보로 거론되기 때문입니다. 만약 동시성 제어라는 기초 공사 없이 시스템을 구축한다면, 우리는 거대한 모래성을 쌓는 것과 같습니다. 겉은 화려하지만 작은 충격에도 쉽게 무너져 내릴 수 있습니다.

그 위험성을 구체적인 시나리오로 살펴보겠습니다.

• 금융 거래: 여러 AI 에이전트가 시장 데이터를 분석해 자동으로 주식을 사고파는 시스템을 상상해 보십시오. 에이전트 A가 'X 기업의 주가가 저평가되었다'는 1분 전 데이터를 보고 '매수' 결정을 내리는 긴 '생각'의 시간에 돌입합니다. 바로 그 순간, 새로운 실적 악화 뉴스가 뜨고, 에이전트 B가 관련 데이터를 즉시 업데이트하며 '매도'가 유리하다고 판단합니다. 하지만 에이전트 A는 이미 낡은 정보에 기반해 매수 주문을 넣어버리고, 회사는 큰 손실을 입게 됩니다.

• 자율 주행 관제: 중앙 관제 시스템에서 여러 에이전트가 도시의 교통 흐름을 관리합니다. 에이전트 1이 'A 도로에 사고 발생' 정보를 인지하고, 주변 차량들의 우회 경로를 계산하기 시작합니다. 그 사이, 현장에 출동한 드론 에이전트가 '사고 처리 완료, 도로 정상화' 정보를 시스템에 업데이트합니다. 만약 우회 경로를 계산하던 에이전트 1이 이 정보를 제때 반영하지 못하면, 다른 자율주행차들을 계속해서 사고가 났던 지점으로 보내는 끔찍한 상황이 발생할 수 있습니다.

• 의료 진단: 한 환자의 전자의무기록(EMR)이라는 '공유 상태'를 여러 전문의 AI 에이전트가 동시에 검토하며 협진합니다. 영상의학과 AI가 CT 이미지를 보고 '종양 의심' 소견을 내놓습니다. 내과 AI가 이 소견을 바탕으로 복잡한 처방을 구상하는 동안, 혈액종양내과 AI가 최신 조직검사 결과를 시스템에 입력하며 '양성 종양으로 최종 확인'이라고 업데이트합니다. 내과 AI가 이 최종 업데이트를 놓치고 '악성 종양'을 전제로 한 항암 치료 계획을 세운다면, 환자의 생명에 직접적인 위협이 될 수 있습니다.

현재 AutoGen, CrewAI 등 널리 알려진 대부분의 AI 에이전트 개발 프레임워크들은 아직 이런 심각한 동시성 문제를 해결할 강력한 장치를 내장하고 있지 않습니다. 연구와 실험 단계에서는 괜찮지만, 이런 도구들을 가지고 금융, 의료, 교통 같은 '미션 크리티컬'한 시스템을 만들겠다고 말하는 것은 극히 위험한 발상입니다.

우리는 무엇을 추적해야 하는가: 데이터 주권과 ‘거래의 원자성’

그렇다면 앞으로 우리는 무엇을 보고, 무엇을 기준으로 이 기술의 발전을 판단해야 할까요? 단순히 ‘더 똑똑해졌다’, ‘더 사람 같아졌다’는 식의 감상적인 평가를 넘어서야 합니다. 이제는 AI 시스템의 ‘신뢰성’과 ‘안정성’을 가늠할 수 있는 구체적인 신호들을 추적해야 합니다.

첫 번째 추적 신호는 AI 에이전트 프레임워크의 ‘트랜잭션’ 지원 여부입니다. 앞으로 새로운 AI 에이전트 기술이나 서비스가 발표될 때, 화려한 홍보 문구나 시연 영상에 현혹되지 마십시오. 대신 개발자를 위한 기술 문서나 백서에 '트랜잭션(Transaction)', '락(Lock)', '원자성(Atomicity)', '동시성(Concurrency)' 같은 단어가 포함되어 있는지 확인해야 합니다. 이러한 단어의 유무가 장난감과 실제 산업용 도구를 가르는 결정적인 기준이 될 것입니다. 이는 시스템이 데이터의 일관성을 얼마나 중요하게 여기는지를 보여주는 시금석입니다.

두 번째 추적 신호는 AI의 ‘결정’에 대한 감사 추적(Audit Trail) 가능성입니다. AI가 특정 결정을 내렸을 때, 우리는 “왜?”라고 물을 수 있어야 합니다. 그 답을 얻으려면 AI가 ‘어느 시점의, 어떤 버전의’ 데이터를 보고 그런 판단을 내렸는지 정확히 복기할 수 있어야 합니다. 동시성 제어가 부재한 시스템에서는 이 추적이 사실상 불가능합니다. 각 에이전트가 본 현실이 제각각이라, 결정의 원인을 하나의 타임라인으로 재구성할 수 없기 때문입니다. 이런 시스템의 AI는 영원히 책임질 수 없는 ‘블랙박스’로 남게 되며, 문제가 발생해도 원인 규명과 개선이 불가능해집니다.

궁극적으로 이 문제는 AI 시대의 ‘데이터 주권’이라는 묵직한 주제와 연결됩니다. 여러 AI가 내 개인정보, 우리 회사의 기밀 데이터를 동시에 들여다보고 수정하며 무언가를 처리한다고 할 때, 그 정보의 최종적인 통제권과 무결성은 누가 보장합니까? 동시성 제어는 바로 이 ‘정보의 진실성’을 지키는 최소한의 기술적 장치입니다. 내 데이터를 처리하는 AI 시스템이 이런 기본적인 일관성조차 보장하지 못한다면, 우리는 그 시스템에 내 삶의 중요한 부분을 맡길 수 없습니다. AI에게 데이터 주권을 넘겨주기 전에, AI가 그 데이터를 책임질 능력이 있는지부터 물어야 하는 이유입니다.

AI의 지능이 아니라, 그 지능이 사용하는 정보의 ‘진실성’을 보장하는 규칙이 시스템의 가치를 결정합니다. 이 원칙을 잊는 순간, 우리는 거대한 기술적 환상 위에 미래를 쌓게 될 위험이 있습니다.

독자가 던질 법한 질문들

Q. 너무 기술적인 문제 아닌가요? 일반 사용자인 제가 이런 것까지 신경 써야 하나요? A. 자동차 엔진의 상세한 원리를 몰라도 운전은 할 수 있습니다. 하지만 내가 타는 차의 엔진에 리콜 대상이 될 만한 심각한 설계 결함이 있다면, 그 사실은 반드시 알아야 합니다. 동시성 제어 문제는 바로 그런 종류의 근본적인 '설계 결함'에 해당합니다. 우리가 앞으로 사용하게 될 수많은 AI 서비스의 안정성, 신뢰성과 직결되는 문제입니다. 따라서 최소한 어떤 위험이 있는지, 그리고 그 위험이 해결된 기술인지를 분별하는 눈을 갖는 것은 현명한 사용자의 필수 소양이라 할 수 있습니다.

Q. 이 문제를 해결하는 게 그렇게 어렵나요? 왜 AI 개발자들은 처음부터 적용하지 않았을까요? A. 두 가지 주된 이유가 있습니다. 첫째, 지난 몇 년간 AI 연구 개발의 최우선 목표는 '능력'의 한계를 돌파하는 것이었습니다. 일단 달리게 만든 뒤, 안정성이나 효율성은 나중에 생각하는 경향이 강했습니다. 둘째, LLM의 본질적인 '확률적'이고 예측 불가능한 특성을, 데이터베이스의 '결정론적'이고 엄격한 규칙과 결합하는 것은 기술적으로 매우 까다로운 도전입니다. 하지만 불가능한 것은 아니며, 이제는 AI가 실험실을 나와 실생활로 들어오기 위해 반드시 넘어야 할 산입니다. 연구의 무게중심이 '성능'에서 '신뢰성'으로 옮겨가고 있는 지금이 바로 그 시작점입니다.

Q. 그렇다면 지금 나와 있는 AI 에이전트 서비스들은 전부 쓸모없는 건가요? A. 그렇지 않습니다. 다만 연구는 정확히 읽어야 합니다. 중요한 것은 '용도'를 명확히 구분하는 것입니다. 현재의 AI 에이전트들은 중요도가 비교적 낮은 반복 업무를 자동화하거나, 새로운 아이디어를 얻기 위한 브레인스토밍 도구로서는 충분히 유용하고 강력합니다. 즉, '실패해도 괜찮은' 영역에서는 훌륭한 조수 역할을 할 수 있습니다. 하지만 이 칼럼에서 경고하는 것은, 돈, 건강, 안전과 같이 '절대 실패하면 안 되는' 중요한 영역에 이 기술을 섣불리 적용해서는 안 된다는 점입니다. 기술의 현주소를 정확히 알고, 그 한계 안에서 활용하는 지혜가 필요합니다.