작은 온라인 쇼핑몰이 고객 응대를 세 개의 AI 모듈로 자동화했다. 고객에게 답장하는 모듈, 주문 진행 상황을 정리하는 모듈, 환불을 판단하는 모듈이다. 어느 날 한 고객이 “상품이 깨져서 왔으니 환불해 달라"고 메일을 보냈다. 세 모듈이 동시에 깨어났다. 고객 응대 모듈은 “환불을 처리해 드렸습니다"라고 답장했고, 진행 모듈은 주문 상태를 “처리 중"으로 바꿨다. 환불 모듈은 사진이 빠졌다고 판단해 상태를 “서류 대기"로 바꾸고, 사진을 보내 달라는 메일을 한 통 더 보냈다. 고객은 서로 반대되는 말을 하는 메일 두 통을 받았고, 주문 상태가 마지막에 무엇으로 남을지는 어느 모듈이 마지막에 썼느냐에 달려 있다.

여기서 말하는 “모듈"은 도구마다 부르는 이름이 다르다. skills, agents, 자동화 흐름 등이다. 공통점은 어떤 이벤트가 일어나면 일의 한 부분을 자동으로 맡는다는 것이다.

이런 충돌을 만나면 많은 팀이 먼저 떠올리는 것은 누구 말이 우선인지 정하는 중재 규칙을 더하는 일이다. 더 효과적인 방법은 설계로 돌아가는 것이다. 한 가지 일에는 입구를 하나만 두고, 바뀌는 항목마다 쓸 수 있는 모듈을 하나만 두고, 나머지 모듈은 제안만 할 수 있게 한다.

중재 규칙이 자꾸 늘어나는 이유

중재 규칙은 그럴듯해 보인다. 환불 모듈의 판단이 고객 응대 모듈보다 우선하고, 진행 모듈은 마지막에 쓴다. 하지만 규칙이 늘수록 규칙 사이의 예외를 처리해야 한다. 환불 모듈이 아직 끝나지 않았다면 고객 응대 모듈은 기다려야 하는가. 두 모듈이 거의 동시에 썼다면 어느 쪽을 먼저로 볼 것인가. 새 규칙 하나하나가 원래 일어나지 말았어야 할 경쟁의 뒷수습을 하고 있다.

더 흔한 방식은 “마지막에 쓴 것이 이긴다"이다. 설계가 전혀 필요 없기 때문이다. 문제는 마지막에 쓴 쪽이 옳다는 보장이 없다는 점이다. 그저 조금 느렸을 뿐일 수 있다.

충돌은 두 곳에서 생긴다

첫째는 중복 실행이다. 같은 일이 여러 입구로 들어온다. 고객의 메일로 한 번, 고객지원 시스템이 티켓을 만들면서 또 한 번, 5분마다 미처리 건을 훑는 예약 작업으로 다시 한 번 실행된다. 세 입구는 이름이 다르지만 다루는 일은 같다. “모듈끼리 싸운다"는 경우의 상당수는 사실 같은 모듈이 세 번 불린 것이다.

둘째는 쓰는 주체가 여럿이라는 점이다. 주문 상태라는 항목을 세 모듈 모두 바꿀 수 있다. 같은 항목을 두 개 이상의 모듈이 쓸 수 있다면, 충돌은 시간문제일 뿐이다.

두 가지 모두 설계에서 생긴 것이고, 모델이 얼마나 똑똑한지와는 관계가 없다. Microsoft는 여러 agent의 협업 패턴을 정리한 아키텍처 가이드에서, 공유 상태나 외부 시스템에 대한 변경을 확실하게 조율할 수 없다면 여러 agent를 같은 일에 동시에 돌리지 말라고 당부한다. 도구를 갖춘 단일 agent로 확실히 처리할 수 있다면 그 단순한 방식을 먼저 택하라고도 권한다. Anthropic도 agent를 만드는 방법을 설명한 글에서 비슷하게 조언한다. 가능한 한 가장 단순한 해법을 찾고, 결과가 분명히 좋아질 때에만 복잡성을 더하라는 것이다.

광고

입구 하나, 쓰는 주체 하나

그래서 충돌은 원인에서부터 고친다. 순서는 이렇다.

먼저 한 가지 일에 입구를 하나만 둔다. 모듈을 깨우는 출처를 모두 적어 보고, 이름은 다르지만 같은 일을 다루는 것들을 찾아 하나로 합친다. 같은 이벤트가 다시 들어오면 시스템이 알아볼 수 있어야 한다. 결제 시스템에서는 이미 자리 잡은 방식이다. Stripe는 요청마다 고유 식별자(idempotency key, 멱등 키)를 붙일 수 있게 해서, 같은 요청이 다시 오면 작업을 한 번 더 하지 않고 처음 결과를 돌려준다. AI 모듈의 이벤트도 똑같이 할 수 있다. 이벤트마다 번호를 붙이고, 같은 번호는 한 번만 처리한다.

다음으로 항목마다 쓰는 주체를 하나로 한다. 바뀌는 항목을 적어 보고, 틀렸을 때 영향이 큰 것에 표시한다. 주문 상태, 환불 금액, 고객에게 보내는 메일 같은 것들이다. 이런 항목마다 쓸 수 있는 모듈을 하나만 남긴다. 다른 모듈은 읽고 제안할 수는 있지만 직접 바꾸지는 못한다.

마지막으로 경쟁을 이어달리기로 바꾼다. 쇼핑몰 예로 돌아가면, 환불 모듈을 주 모듈로 삼아 판단하고 주문 상태를 쓰고 메일을 보낼지도 정하게 한다. 고객 응대 모듈과 진행 모듈은 자신이 본 정보를 환불 모듈에 넘기기만 한다. 고객은 메일을 한 통만 받고, 주문 상태의 출처도 하나가 된다.

중재도 쓸모는 있지만, 예외에만 쓴다

당장은 도저히 나눌 수 없는 경우도 있다. 오래된 시스템을 바꾸기 어렵거나, 두 부서가 같은 항목의 다른 부분을 각각 맡고 있는 경우다. 그럴 때는 여전히 중재가 필요하지만 예외로 다룬다. 우선순위를 분명히 적고, 판단할 수 없으면 멈추고 사람에게 넘기고, 중재를 쓸 때마다 기록을 남긴다. 중재가 쓰인 횟수가 곧 설계가 아직 고쳐지지 않은 곳을 보여 준다.

이 방식에도 대가가 있다. 쓰는 주체를 하나만 두면, 주 모듈이 실패했을 때 다른 모듈이 자동으로 메울 수 없다. 그래서 주 모듈의 실패는 감지해서 사람에게 넘길 수 있어야 하고, 다른 모듈이 서둘러 떠맡게 해서는 안 된다.

다음 단계로, 가장 자주 문제를 일으키는 이벤트 하나를 골라 두 가지를 물어보자. 이 이벤트는 몇 개의 입구로 들어오는가. 이 이벤트가 바꾸는 항목마다 쓸 수 있는 모듈은 몇 개인가. 둘 다 답이 “하나"라면 그 이벤트에는 중재가 거의 필요 없다. AI 모듈을 외부에서 들여왔다면 설치 전에 확인할 층이 하나 더 있다. AI agent 확장 도구는 검사를 통과해도 바로 설치하면 안 된다, 위험은 실행된 뒤에 나타난다를 참고하자. 처리가 중간에 실패했을 때의 뒷수습은 자동화가 중간에 멈췄다면, 다시 돌리기 전에 이미 무슨 일이 있었는지부터 확인한다를 참고하면 된다.

AI 정리 카드

이벤트의 입구와 쓰는 주체를 AI와 함께 찾기 이 프롬프트는 어떤 이벤트가 여러 모듈을 깨우는지 확인하고, 입구와 항목별 쓰는 주체를 정리한 뒤, 주 모듈 하나가 쓰는 구조로 바꾸는 방법을 제안한다.

내 자동화 흐름에서 이벤트 하나가 여러 AI 모듈(skills, agents, 자동화 흐름 등)을 동시에 깨워서 자주 충돌이 난다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-agent-skill-conflict-prevention/
글의 관점은 이렇다. 충돌은 주로 두 곳에서 생긴다. 같은 일이 여러 입구로 들어오는 것, 그리고 같은 항목을 여러 모듈이 쓸 수 있는 것. 고치는 방법은 한 가지 일에 입구를 하나, 중요한 항목마다 쓰는 주체를 하나만 두고 나머지 모듈은 제안만 하게 하는 것이다. 중재는 나눌 수 없는 예외에만 남긴다.

먼저 나에게 질문 3개를 해 달라:
1. 어떤 이벤트이고, 어떤 모듈을 깨우며, 각 모듈은 무엇을 하는가;
2. 그 이벤트는 어디서 들어오는가(메일 수신, 티켓 생성, 예약 검사 등). 같은 일이 여러 번 실행될 수 있는가;
3. 이 모듈들은 어떤 항목이나 외부 동작(주문 상태, 금액, 메일 발송 등)을 바꾸는가. 각각 지금 몇 개의 모듈이 직접 쓸 수 있는가.

내 답을 바탕으로 다음을 출력해 달라:
- 입구 목록: 실제로 같은 일을 다루는 입구는 무엇이고, 어떻게 합치며, 중복 이벤트를 어떻게 알아볼지;
- 쓰는 주체 목록: 중요한 항목별 현재 쓰는 주체와, 남겨 둘 하나의 쓰는 주체;
- 이어달리기로 바꾼 뒤의 흐름: 주 모듈은 무엇이고, 다른 모듈은 무엇을 넘기는지;
- 그래도 나눌 수 없어서 중재나 사람의 판단이 필요한 예외.
내가 말하지 않은 기능이 시스템에 있다고 가정하지 말 것. 정보가 부족하면 먼저 나에게 물어볼 것.

제안은 출발점일 뿐이다. 어느 모듈을 쓰는 주체로 할지는 그 흐름을 책임지는 사람이 정한다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료