에이전트의 다음 차원은 무엇일까? (룰베이스와 복잡계)

1960년대 초 MIT의 기상학자 에드워드 로렌츠는 컴퓨터로 날씨를 모사하다 흥미로운 일을 발견했습니다.

이전 시뮬레이션의 중간 지점부터 계산을 다시 시작하면서, 출력된 숫자를 입력했습니다. 소수점 아래 몇 자리가 반올림된 값이었습니다. 처음에는 비슷하게 움직이던 두 시뮬레이션이 시간이 지나자 전혀 다른 날씨를 그리기 시작했습니다.

아주 작은 차이가 시간이 흐르며 크게 벌어진 것입니다. 훗날 ‘나비 효과’로 널리 알려진 이야기입니다.

며칠 전 한 오픈채팅방에서 에이전트 이야기를 나누다가 이 사례가 떠올랐습니다.

저는 바이브코딩으로 만든 업무 시스템에서 에이전트를 활용하고 있습니다.

비즈니스 룰은 문서와 설정, 코드로 나눠 관리합니다. 에이전트는 자연어 요청을 이해하고, 필요한 데이터를 찾고, 이미 만들어둔 함수를 실행합니다. 휴가 일수나 복리후생 대상처럼 확실해야 하는 계산은 LLM의 판단에 맡기지 않습니다.

모든 판단을 LLM에 맡기는 것은 움직이는 인형의 관절마다 LLM이 일일이 제어하게 하는 것처럼 느껴졌습니다. 그래서 비즈니스 룰은 코드로 고정하고, 그 코드를 찾아 쓰는 일을 에이전트에게 맡겼습니다. 저는 이 정도면 꽤 괜찮은 역할 분담이라고 생각했습니다.

그러나 고객 현장에 깊이 들어가 문제를 푸는 FDE(Forward Deployed Engineer)로 일하시는 분의 고민은 조금 더 앞에 있었습니다.

그분은 기존 룰베이스 시스템에 에이전트를 어떻게 적용할지 고민하고 계셨습니다. 나이와 가족 구성, 상품별 조건처럼 수식과 자연어 규칙이 섞인 시스템이었습니다.

새로운 규칙이 이메일이나 대화에서 생길 수 있었습니다. 방금 생긴 예외가 기존 규칙을 덮어쓰거나 다른 규칙과 충돌할 수도 있었습니다. 누군가의 머릿속에 있던 판단을 언제, 어떤 절차로 공식 규칙에 반영할지도 고민하고 있었습니다.

제가 고민하던 것은 정해진 규칙 집합 안에서 에이전트가 잘 일하게 만드는 문제였습니다. 반면 그분은 사람과 조직의 상호작용 속에서 규칙 자체가 생기고 바뀌는 상황까지 시스템으로 다루려 했습니다. 문제의 차원이 달랐습니다.

같은 에이전트 이야기였지만, 몇 년 뒤 우리가 마주할 문제를 미리 보는 기분이 들었습니다.

규칙이 많다고 모두 복잡계는 아닙니다

보험 가입 조건이 수백 개 있고 할인 계산식이 길더라도, 규칙이 고정되어 있고 같은 입력에 같은 결과가 나온다면 테스트할 수 있습니다. 구현하기 어려운 시스템이지만 해결할 방법은 비교적 분명합니다.

반면 규칙이 몇 개 안 되더라도 사람들이 서로 반응하며 새로운 예외를 만들고, 그 예외가 다시 사람들의 행동을 바꾼다면 이야기가 달라집니다.

상담 결과를 본 고객이 요구를 바꾸고, 예외 가능성을 들은 영업 담당자가 새로운 약속을 합니다. 반복되는 예외는 어느 순간 사실상의 정책이 되고, 불편한 규칙이 생기면 사람들은 우회하는 방법을 찾습니다.

시스템의 판단이 사람의 행동을 바꾸고, 바뀐 행동이 다시 시스템의 조건을 바꿉니다. 구성 요소 자체보다 그 사이의 상호작용과 피드백이 중요해집니다.

산타페연구소의 Complexity Explorer는 복잡계를 많은 구성 요소가 상호작용하면서, 각 부분의 합만으로는 설명하거나 예측하기 어려운 전체 행동이 나타나는 시스템으로 설명합니다. 조직의 예외와 규칙도 이런 관점에서 바라볼 수 있겠다는 생각이 들었습니다.

날씨는 일기예보를 듣고 스스로 움직임을 바꾸지 않지만, 사람은 예측과 판단을 들은 뒤 행동을 바꿉니다. 에이전트는 조직을 관찰하면서 동시에 조직에 영향을 주게 됩니다.

상담봇이 현업봇에게 물어보는 단계

지금의 상담봇은 대체로 정리된 지식 안에서 답을 찾습니다. 앞으로는 모든 답을 알고 있기보다 인사봇, 재무봇, 영업봇에게 필요한 사실을 물은 뒤 고객에게 설명할 수도 있습니다.

이때 답이 충돌한다면 어느 한쪽이 맞는 척 정리해서는 곤란합니다. 무엇이 충돌했는지 보여주고 책임 있는 사람에게 넘겨야 합니다.

다음 차원의 에이전트도 비슷할 것 같습니다. 반복되는 예외를 발견하고, 기존 규칙과의 충돌과 근거를 정리한 뒤, 공식 규칙의 후보로 제안하는 역할입니다.

예외 발견 → 충돌 확인 → 임시 판단과 근거 기록 → 반복 여부 확인 → 공식 규칙 후보 제안 → 담당자 승인 → 설정이나 코드에 반영

중요한 것은 에이전트가 예외를 곧바로 새로운 규칙으로 확정하지 않는 것입니다. 일시적인 사건인지 반복되는 패턴인지 구분하고, 기존 정책과 충돌하는 이유를 사람이 판단할 수 있도록 보여줘야 합니다.

날씨를 예측하기 어렵다고 물리 법칙을 버리지는 않습니다. 업무 시스템에서도 금액, 권한, 자격처럼 확실해야 하는 규칙은 여전히 코드로 남아 있어야 합니다.

지금 저는 에이전트가 코드로 정리된 업무 시스템 안에서 그 규칙대로 잘 일하도록 만드는 중입니다. 다음에는 에이전트가 예외와 충돌을 찾아 새로운 규칙과 코드 변경안을 제안할지도 모릅니다. 사람이 판단하고 검증해 승인하면 비즈니스 룰에 반영합니다.

어쩌면 이런 일을 맡는 것이 에이전트의 다음 차원이 아닐까 생각해봅니다.