실행으로 만드는 데이터, 시뮬레이션으로 배우는 에이전트

Synthesis Through Simulation: Generating Coherent Enterprise Data via Scalable Agent-System Interaction는 arXiv에 공개된 기업 데이터 합성 연구로 arXiv 번호 2610.10549로 등록되어 있다. 원문 링크는 제목 아래에 걸어두었다.

이 연구가 내세우는 주장은 하나의 문장으로 정리된다. 기업용 도구를 다루는 에이전트에 필요한 학습 데이터를 표를 흉내 내어 찍어내는 대신 정책을 실제로 집행하는 시뮬레이션 환경 안에서 에이전트가 직접 조작을 실행하게 하면 스키마 없이도 구조적으로 올바른 데이터를 얻을 수 있다는 것이다. 이 글에서는 그 문제의식에서 출발해 기존 합성 방식의 벽과 시뮬레이션 합성의 동작 원리, Generalist Populator의 설계와 수치, 그리고 항공 환경에서 드러난 차이를 차례로 따라간다.

왜 도구를 쓰는 에이전트인데 정작 학습시킬 데이터가 없을까

제가 이 논문에서 가장 흥미롭게 본 부분은 출발점의 솔직함이었다. 도구를 부르는 에이전트가 기업 현장의 중심에 들어섰는데, 정작 그 에이전트를 가르치고 시험할 데이터는 구하기가 지독하게 어렵다는 고백부터 시작하기 때문이다. 기업 시스템은 열어볼 수 없고, 실제 데이터는 밖으로 가져올 수 없으며, 데이터베이스 스키마조차 법과 계약의 울타리 안에 갇혀 있죠. 그러니 연구자는 재료를 쥔 적이 없으면서 요리를 해야 하는 처지에 놓인다. 그렇다면 이 막힌 상황에서 무엇을 할 수 있을까. 이 질문이 논문 전체를 끌고 간다.

생각해보면 사람도 비슷하게 배웁니다. 신입 직원이 창고 일을 배울 때 매뉴얼만 읽게 하면 며칠은 버티지만 진짜 주문이 몰리는 날에는 손이 멈춘다. 물건이 어디에 있는지, 누구에게 먼저 연락해야 하는지, 결제가 막혔을 때 어떤 단추를 눌러야 하는지는 몸으로 부딪혀봐야 익혀지니까요. 에이전트도 마찬가지인데, 문서로 된 설명만 읽은 에이전트는 실제 도구 앞에서 자주 길을 잃는다. 호출 순서가 조금만 어긋나도 전체 작업이 무너지고, 권한이 바뀌면 다음 행동을 고르지 못하죠. 그래서 현장에서 바로 쓸 수 있는 에이전트를 만들려면 현장과 같은 조건에서 부딪혀본 기록이 필요한데, 그 기록 자체가 잠겨 있다는 것이 문제의 시작이다.

여기서는 조금 조심해서 읽을 필요가 있는데, 데이터가 없다는 말이 기업에 데이터가 없다는 뜻은 아니기 때문이다. 기업 안에는 데이터가 넘치죠. 문제는 그 데이터를 연구와 학습에 쓸 수 없다는 데 있다. 영업 비밀이 걸려 있고, 고객 정보가 섞여 있으며, 스키마를 여는 순간 내부 구조가 드러나기 때문에 문을 열 수 없는 것이다. 저는 이 대목을 읽으며 저희가 새로운 AI 아키텍처를 볼 때 자주 던지는 질문을 떠올렸다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 데이터 합성도 같은 잣대로 봐야 하는데, 점수보다 먼저 물을 것이 있다. 잠긴 문을 열지 않고도 현장과 같은 기록을 만들 수 있을까. 이 물음이 다음 장면으로 이어진다.

표를 먼저 만들면 왜 현실과 어긋나기 쉬울까

기존에 데이터를 만들던 방식은 크게 두 갈래였다. 하나는 표 형태의 데이터를 통계적으로 흉내 내는 길이고, 다른 하나는 절차를 직접 짜서 데이터를 찍어내는 길이다. 표를 흉내 내는 쪽은 분포는 그럴듯하게 맞추지만 구조가 자주 어긋난다. 실제로는 일어날 수 없는 조합이 버젓이 들어가고, 외래 키가 어긋나며, 순서가 뒤바뀐 기록이 섞이죠. 반면 절차를 짜는 쪽은 구조는 맞출 수 있지만 분포가 밋밋해진다. 도메인마다 장인이 따로 붙어 규칙을 써야 해서 손이 많이 가는데, 그렇게 만든 데이터는 현실의 울퉁불퉁함을 잃어버리기 때문이다. 그래서 두 길 모두 어딘가 아쉬움이 남는다.

이 차이는 생각보다 중요합니다. 표를 보고 배우는 에이전트는 모양만 보고 배우기 때문이다. 예를 들어 월요일 아침 정산 장면을 떠올려보자. 환불이 먼저 들어오고 나서야 취소 기록이 찍히고, 그다음에야 재고가 돌아오는 순서가 있다. 그런데 표 합성으로 만든 데이터에 취소보다 환불이 먼저 찍힌 행이 섞여 있으면 에이전트는 잘못된 순서를 정상으로 외운다. 현장에 나가서는 맨 먼저 해야 할 확인을 건너뛰고, 그래서 첫 단추부터 어긋나죠. 모양은 맞는데 순서가 틀린 공부가 쌓이면 실력이 아니라 오해가 쌓인다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 몇 퍼센트가 맞았느냐보다, 틀린 몇 퍼센트가 어떤 종류의 틀림이냐가 현장에서는 훨씬 아프기 때문이다.

그런데 절차 기반 합성이 분포를 놓치는 까닭도 분명하다. 사람이 규칙을 쓰면 자기가 아는 경우만 쓰기 때문이다. 자주 일어나는 일은 꼼꼼히 쓰지만 드물게 일어나는 일은 빠뜨리고, 예외가 겹치는 상황은 아예 상상하지 못하죠. 이렇게 되면 데이터는 깔끔하지만 현실은 그렇지 않아서 간격이 벌어진다. 그렇다면 모양과 분포를 한 번에 잡는 길은 없을까. 표를 그리는 손과 순서를 정하는 손을 나누지 않고, 아예 일을 하면서 기록을 남기는 방법은 없을까. 여기서 논문의 방향이 갈라진다.

시뮬레이션으로 합성한다는 말은 무엇을 뜻할까

이 연구가 제안하는 Synthesis Through Simulation은 발상을 뒤집는다. 데이터를 먼저 만들고 나서 맞는지 검사하는 대신, 맞는 것만 허락하는 환경 안에서 직접 일을 시키고 그 흔적을 데이터로 삼는다. 정책을 실제로 집행하는 API가 앞에 있고, 그 뒤에 시뮬레이션된 기업 환경이 버티고 있다. 에이전트가 예약을 만들고, 결제를 시도하고, 승인을 요청하면 환경이 그때그때 옳고 그름을 가려준다. 안 되는 호출은 애초에 기록으로 남지 않고, 되는 호출만 순서대로 쌓이니까요. 그래서 만들어진 데이터는 검사해서 맞는 것이 아니라 만들어지는 과정에서 이미 맞을 수밖에 없다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 맞는 것만 허락한다는 말이 쉬워 보이지만, 그 말을 지키려면 환경이 진짜 기업 시스템처럼 굴어야 하기 때문이다. 권한이 없으면 막아야 하고, 잔액이 모자라면 거절해야 하며, 앞 단계가 끝나지 않았으면 다음 단계를 받지 않아야 한다. 이런 거절이 있어야 에이전트의 성공 기록이 의미를 갖죠. 운전 연습을 빈 주차장이 아니라 신호등과 일방통행이 있는 모의 도로에서 하는 셈인데, 부딪혀도 다치지 않으면서 규칙은 그대로 지키는 공간이 필요했던 것이다. 저는 이 구분을 논문이 던진 진짜 질문이라고 봅니다. 무엇을 만들 것인가가 아니라 어디에서 만들 것인가를 먼저 정했다는 점이 다르니까요.

여기서 재미있는 질문이 생깁니다. 스키마를 안 봤는데 어떻게 올바른 데이터를 만들 수 있을까. 보통은 테이블 구조를 알아야 올바른 행을 넣을 수 있다고 생각하기 때문이다. 그런데 이 방식에서는 구조를 외울 필요가 없다. 환경이 틀린 길을 막아주니까 에이전트는 뚫린 길만 걸으면 되고, 그 걸음이 곧 올바른 기록이 되죠. 길을 외우는 대신 발밑의 감각을 믿고 걷는 셈이다. 그렇다면 환경이 막아주는 일과 에이전트가 그럴듯하게 걷는 일은 어떻게 나뉠까. 이 나눔이 다음 대목의 열쇠다.

스키마를 보지 않고도 일을 해내는 방법이 있을까

Generalist Populator라는 이름의 에이전트가 바로 그 걷는 주체다. 이 에이전트는 데이터베이스 스키마를 들여다보지 않는다. 테이블 이름도 모르고, 컬럼 정의도 모른 채 오직 API만을 통해 환경과 만난다. 무엇을 할 수 있는지는 직접 눌러보고 배우고, 막히면 다른 길을 찾는다. 도메인마다 따로 손볼 필요도 없어서 열 개 환경 어디에 놓아도 같은 방식으로 움직이죠. 특정 가게의 뒷방 구조를 외운 점원이 아니라, 어느 가게에 가도 진열과 안내 표지판만 보고 일을 시작하는 일꾼에 가깝다.

개인적으로 인상 깊었던 점은, 이 무지가 약점이 아니라 설계라는 것이다. 스키마를 보면 편해 보이지만, 그 편함이 오히려 독이 될 수 있기 때문이다. 스키마를 아는 에이전트는 지름길을 외워서 일을 처리하려 들고, 환경이 조금만 바뀌면 외운 길이 끊겨버린다. 반면 스키마를 모르는 에이전트는 매번 현재 상태를 확인하고 가능한 행동을 고르는 습관을 들이죠. 느려 보이지만 흔들림에는 강한 셈이다. 생각해보면 낯선 식당 주방에 들어간 요리사와 비슷하다. 칼과 불의 위치를 매번 확인하는 요리사가 처음에는 느려 보여도, 주방이 바뀌면 오히려 그 요리사가 먼저 적응한다. 외운 것이 적을수록 바뀌는 것에 덜 무너지니까요.

문제는 그다음입니다. 스키마 없이 걷는 에이전트가 정말로 그럴듯한 분포까지 만들 수 있을까. 올바른 것과 그럴듯한 것은 다른 능력이기 때문이다. 환경이 막아주면 올바른 것은 보장되지만, 현실에서 자주 일어나는 일을 자주 하고 드문 일을 드물게 하는 감각은 따로 필요하죠. 이 에이전트는 언어 모델이 가진 상식과 환경의 반응을 오가며 그 감각을 맞춘다. 자주 있을 법한 요청을 먼저 시도하고, 거절당하면 조건을 바꿔 다시 시도하는 식이다. 저는 여기서 조금 의심했습니다. 상식에만 기대면 뻔한 이야기만 반복하는 것은 아닐까. 그런데 뒤에 나오는 수치를 보면 그 의심이 절반은 풀린다. 올바른 것과 그럴듯한 것을 나누어 맡긴 덕분인데, 그 나눔을 이제 들여다볼 차례다.

유효하다는 말과 그럴듯하다는 말을 어떻게 다를까

이 논문이 마음에 든 까닭은 두 가지 일을 깔끔하게 나눴기 때문이다. 유효성을 지키는 일은 환경이 맡고, 분포를 맞추는 일은 에이전트가 맡는다. 환경은 정책 집행자로 서서 안 되는 것을 막고, 에이전트는 손님처럼 행동하며 있을 법한 일을 고른다. 이렇게 나누면 각자 잘하는 일만 하면 된다. 환경은 엄격하면 되고, 에이전트는 자연스러우면 되니까요. 한쪽이 두 가지를 다 짊어질 때 생기던 타협이 사라진다. 검사와 연기가 한 몸이면 연기가 굳기 마련인데, 심판과 선수를 나눈 셈이다.

예를 들어 병원 접수 창구를 떠올려보자. 접수 규정은 벽에 붙어 있고, 직원은 그 규정을 어길 수 없다. 그런데 손님들의 사정은 제각각이다. 급한 사람도 있고, 서류를 빠뜨린 사람도 있으며, 예약을 착각한 사람도 있다. 규정은 그대로인데 손님의 분포는 매일 다르죠. 이 연구의 나눔도 같은 결이다. 환경이라는 벽은 움직이지 않고, 그 앞에서 벌어지는 일들의 결만 현실과 닮게 만드는 것이다. 그래서 유효성은 설계로 보장되고, 분포는 행동으로 맞춘다. 하나가 무너지면 다른 하나까지 무너지는 구조가 아니라서 고치기도 쉽다. 규정이 바뀌면 환경만 고치고, 손님 취향이 바뀌면 에이전트의 행동만 다듬으면 되니까요.

그렇다면 이 나눔은 어디에서 끊을 수 있을까요. 그 이야기는 마지막에 다시 다루겠습니다. 미리 한 가지만 짚으면, 나눔이 깔끔하다는 말이 두 일이 서로 모른다는 뜻은 아니기 때문이다. 에이전트가 너무 엉뚱한 일만 시도하면 환경이 다 막아버려서 기록이 안 쌓이고, 환경이 너무 빡빡하면 그럴듯한 분포를 담을 그릇이 좁아진다. 둘이 서로 맞아야 전체가 도는 구조죠. 저는 그래서 뒤에 나오는 0.88과 100퍼센트라는 한 쌍의 숫자를 함께 봐야 한다고 봅니다. 하나는 나눔의 한쪽을, 다른 하나는 나머지 한쪽을 말해주기 때문이다.

평균 0.88이라는 숫자를 어떻게 읽어야 할까

Generalist Populator는 열 개 환경에서 평균 0.88의 주변 분포 충실도와 100퍼센트의 제약 만족을 기록했다. 두 숫자는 나란히 읽어야 한다. 0.88은 현실의 분포를 얼마나 닮았는지를 말하고, 100퍼센트는 규칙을 어긴 기록이 하나도 없다는 뜻이기 때문이다. 따로 보면 반쪽짜리 이야기가 되는데, 분포만 좋으면 틀린 기록이 섞일 수 있고, 규칙만 지키면 밋밋한 기록이 되기 쉽죠. 그런데 이 한 쌍이 함께 나왔다는 것이 의미가 크다. 스키마를 보지 않고도 두 마리 토끼를 한 번에 잡았다는 뜻이니까요.

이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 0.88이 만점은 아니기 때문이다. 주변 분포라는 말은 각 항목 따로따로의 분포를 본다는 뜻인데, 항목 사이의 얽힘까지 다 본 것은 아닐 수 있다. 예를 들어 결제 금액 분포는 맞고 시간대 분포도 맞는데, 특정 시간대의 특정 금액 조합이 현실과 어긋날 여지는 남는다. 그럼에도 100퍼센트와 짝을 이루면 이야기가 달라지는데, 틀린 조합이 없다는 바닥 위에서 0.88이 나왔기 때문이다. 바닥이 없는 0.95보다 바닥이 있는 0.88이 현장에서는 더 쓸모 있을 때가 많다. 틀린 것을 가르치는 것만큼 비싼 수업은 없으니까요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 기록으로 가르친 에이전트가 진짜 현장에서 덜 헤맬까. 논문이 직접 보여주는 범위를 넘기면 안 되지만, 방향은 분명해 보인다. 올바른 순서로만 쌓인 기록은 에이전트에게 올바른 습관을 심어준다. 환불 뒤에 취소가 오는 것이 아니라 취소 뒤에 환불이 오고, 결제 전에 승인이 먼저 있다는 순서를 몸에 새기게 되죠. 저는 이 대목에서 benchmark 숫자 자체보다 그 숫자가 만들어진 바닥을 함께 봐야 한다고 봅니다. 같은 0.88이라도 검사 뒤에 걸러낸 0.88과 만들 때부터 맞을 수밖에 없었던 0.88은 무게가 다르기 때문이다. 바닥이 다르면 같은 숫자도 다른 이야기를 한다.

항공사 환경에서 82퍼센트가 무너진 까닭은 무엇일까

눈에 띄는 대목은 항공사 환경에서의 기록이다. 스키마를 알고 들어간 에이전트가 82퍼센트의 궤적에서 실패했다는 대목인데, 처음에는 뜻밖으로 느껴진다. 안을 훤히 아는 쪽이 더 잘해야 할 것 같은데 결과가 뒤집혔기 때문이다. 까닭을 들여다보면 고개가 끄덕여진다. 항공사 업무는 한 번의 호출로 끝나지 않고 여러 단계가 사슬처럼 얽혀 있기 때문이다. 예약이 바뀌면 좌석이 바뀌고, 좌석이 바뀌면 요금이 바뀌며, 요금이 바뀌면 환불 규정이 달라진다. 하나를 건드리면 줄줄이 따라 움직이는 구조죠. 이런 곳에서는 아는 것이 오히려 굳은 길이 된다.

생각해보면 갈아타는 비행 일정과 비슷하다. 첫 비행기가 늦어지면 두 번째 비행기는 기다려주지 않고, 숙소가 바뀌면 픽업 시간이 바뀌며, 픽업이 바뀌면 회의 시간이 흔들린다. 이때 필요한 것은 지도가 아니라 대처다. 외운 지름길이 막혔을 때 현재 안내판을 보고 다음 길을 고르는 순발력이죠. 스키마를 privileged하게 쥔 에이전트는 미리 짜둔 작업 묶음이 있어서 막히면 그대로 멈춘다. 반면 스키마 없이 걷는 쪽은 매 단계 상태를 묻고 다음 행동을 정하니까 흔들림에 강하다. 82퍼센트라는 숫자는 그래서 실력 부족이 아니라 굳은 계획의 대가로 읽힌다. 짠 대로만 가려 하면 얽힌 곳에서 반드시 멈추게 되니까요. (참고로 저는 이 대목을 읽으며 예전에 결제 승인 단계 하나가 바뀌어 전체 자동화가 멈췄던 운영의 아침을 떠올렸는데요. 그때도 지름길을 외운 쪽이 먼저 멈췄습니다.)

여기서는 조금 조심해서 읽을 필요가 있습니다. 스키마를 아는 방식이 항상 나쁘다는 뜻은 아니기 때문이다. 단계가 짧고 얽힘이 적은 일에서는 미리 짠 계획이 빠르고 정확할 수 있다. 그런데 현실의 기업 일은 대개 짧지 않고, 얽힘이 적지도 않죠. 그래서 이 실패 기록은 특정 환경의 일화가 아니라 설계에 대한 경고로 읽어야 한다. 미리 묶은 계획에 기대면 얽힌 곳에서 깨진다는 경고인데, 저는 이 경고를 논문이 준 가장 실용적인 선물이라고 봅니다. 무엇을 더해야 할지가 아니라 무엇을 덜 믿어야 할지를 알려주기 때문이다.

일곱 개 환경에서 통계 합성이 힘을 못 쓴 이유는 무엇일까

또 하나의 숫자는 일곱 개 환경에서 통계 합성이 아예 적용되지 못했다는 기록이다. 씨앗 데이터가 필요하다는 것이 표면적인 까닭이다. 통계 합성은 기존 행을 보고 분포를 배우는데, 볼 행이 없으면 시작조차 못 하기 때문이다. 기업 현장에서는 이 경우가 흔하다. 새로 만든 시스템에는 기록이 없고, 민감한 도메인은 씨앗조차 밖으로 못 내보내며, 스키마가 닫혀 있으면 어디에 무엇을 넣어야 할지도 알 수 없죠.씨를 심을 밭이 없는데 싹을 틔우라는 셈이라서 시작선에 서지 못한다.

반면 시뮬레이션 합성은 씨앗 없이 시작한다. 환경이 밭이 되어주고, 에이전트가 손으로 직접 심기 때문이다. 빈손으로 시작해도 일을 실행하면 기록이 생기고, 그 기록이 다시 다음 행동의 거름이 된다. 그래서 열 개 환경 모두에서 기록을 남길 수 있었고, 일곱 개 환경에서는 비교 대상 자체가 없었다는 결과가 나온다. 저는 이 대목이 단순한 승패표가 아니라고 봅니다. 뛸 수 있는 경기 자체가 다르다는 선언이기 때문이다. 한쪽은 밭이 있어야 뛰고, 다른 쪽은 밭을 등에 지고 다니며 어디서든 뛰니까요. 경기 수로만 보면 일곱 대 영처럼 보이지만, 진짜 차이는 경기 수가 아니라 뛸 수 있는 땅의 넓이다.

그렇다면 통계 합성이 쓸모없어졌을까. 그렇게 단정하면 읽기를 잘못한 것이다. 씨앗이 넉넉하고 스키마가 열린 곳에서는 통계 합성이 빠르고 값싸게 좋은 분포를 뽑아낼 수 있다. 문제는 기업 현장의 많은 곳이 그 조건을 못 갖춘다는 데 있다. 그래서 저는 이 기록을 대체가 아니라 분업으로 읽는다. 씨앗이 있으면 통계로, 씨앗이 없고 문이 잠겼으면 시뮬레이션으로 가는 분업인데, 현장의 자물쇠가 많은 쪽이 어디인지를 생각하면 시뮬레이션 쪽 손이 더 자주 바빠질 것 같다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 그 운영의 이야기가 남았다.

운영 아침에 이 방식을 올리면 무엇이 달라질까

연구실 점수와 운영의 아침은 다른 시간을 산다. 연구실에서는 평균이 좋으면 박수를 받지만, 운영에서는 새벽에 울리는 알림 하나가 하루를 정한다. 밤사이 공시가 늦게 도착하거나 아침에 특정 종목이 거래 정지에 걸려도 예측 라인은 멈추면 안 되는 것처럼, 기업 에이전트도 결제 모듈이 바뀌고 승인 정책이 바뀌어도 일을 멈추면 안 된다. 이 관점에서 시뮬레이션 합성의 매력은 기록의 양이 아니라 기록의 성질에 있다. 틀린 순서가 섞이지 않은 기록, 정책 변경을 환경에 한 번만 반영하면 다시 찍을 수 있는 기록, 도메인마다 장인을 부르지 않아도 뽑을 수 있는 기록이죠. 이런 성질은 운영자의 어깨를 가볍게 한다.

저희 팀의 기준으로 봐도 같은 감각이 든다. 새로운 모듈이 들어오면 시험 데이터를 다시 만드는 일이 먼저 막히기 때문이다. 표를 흉내 내는 방식이면 스키마 변경분을 손으로 고쳐야 하고, 절차를 짜는 방식이면 규칙서를 다시 써야 한다. 그런데 환경이 정책을 집행하는 구조라면 정책이 바뀌었을 때 환경만 고치면 된다. 에이전트는 바뀐 환경에서 다시 걸으며 새 기록을 남기니까요. 물론 공짜는 아니다. 시뮬레이션 환경을 현실과 가깝게 유지하는 손이 따로 들고, 에이전트를 여러 번 걷게 하는 계산 비용도 만만치 않다. 그럼에도 손이 드는 위치가 달라졌다는 것이 중요하다. 도메인마다 흩어져 있던 손이 환경이라는 한곳으로 모이기 때문이다. 모인 손은 관리할 수 있지만 흩어진 손은 관리하기 어렵죠. 운영 측면에서 보면 이 차이는 상당히 큽니다.

이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 시뮬레이션이 현실과 어긋나면 올바른 기록도 현실과 어긋나기 때문이다. 환경이 허락한 것이 현실의 허락과 다르면, 100퍼센트라는 숫자는 모의 도로에서의 무사고 기록에 머문다. 그래서 환경을 누가, 얼마나 자주 현실에 맞추느냐가 다음 병목이 된다. 저는 그래서 이 마스크된 문맥 증강이 아니라 이 환경 동기화 작업을 운영의 아침을 지켜주는 장치로 본다. 기록을 찍는 속도보다 환경을 현실에 붙들어 매는 손이 더 중요해질 테니까요. 그렇다면 이 흐름은 어디에서 끊을 수 있을까요. 그 이야기는 마지막에 다시 다루겠습니다.

제가 앞으로 보고 싶은 것은 무엇일까

질문도 바뀌었습니다. 어떻게 표를 더 그럴듯하게 만들 것인가에서 어떻게 일을 더 현장답게 시킬 것인가로 말이죠. 이 전환이 반갑다. 표를 잘 그리는 일은 끝이 없고, 그린 표가 현장에서 통하는지는 언제나 나중에야 알기 때문이다. 반면 일을 시키는 방식은 통하는지를 바로 알 수 있다. 막히면 막혔다고 환경이 말해주고, 풀리면 풀렸다고 기록이 말해주니까요. 저는 앞으로의 연구가 이 길 위에서 세 가지로 뻗어가기를 바란다.

먼저 보고 싶은 것은 얽힘의 측정이다. 항공사 환경에서 드러난 것처럼 얽힘이 많은 곳과 적은 곳은 다른 운동장인데, 지금은 그 다름을 느끼는 수준에 머문다. 몇 단계가 사슬로 엮였는지, 되돌리기가 얼마나 어려운지, 실패가 어디까지 번지는지를 재는 자가 있으면 좋겠다. 다음으로 보고 싶은 것은 분포의 속살이다. 0.88이라는 평균 뒤에 무엇이 남았는지를 들여다보고 싶은데, 어떤 조합이 빠졌고 어떤 예외가 드문지를 알면 다음 시도의 방향이 정해지기 때문이다. 마지막으로 보고 싶은 것은 환경 동기화의 비용표다. 환경을 현실에 붙들어 매는 데 손이 얼마나 드는지, 정책이 바뀔 때 다시 찍는 데 시간이 얼마나 걸리는지를 솔직하게 적은 표가 있으면 운영자가 바로 쓸 수 있다.

그렇다면 사람의 역할은 무엇일까요. 기록을 손으로 쓰는 일은 줄어도, 무엇을 올바른 일로 정할지는 여전히 사람의 몫으로 남는다. 어떤 호출을 허락하고 어떤 순서를 강제할지, 어떤 예외를 정책으로 올릴지는 환경에 새겨야 하는데, 그 결정은 숫자로 자동화되지 않기 때문이다. 시뮬레이션이 정교해질수록 그 결정의 무게는 오히려 커진다. 잘 만든 환경은 좋은 습관을 대량으로 찍어내고, 잘못 만든 환경은 오해를 대량으로 찍어내니까요. 저는 이 글의 끝에서 그 무게를 다시 쥔다. 실행으로 만드는 데이터라는 발상은 도구를 손에 쥐여준 셈인데, 그 도구가 좋은 기록을 찍을지 오해를 찍을지는 결국 환경을 어떻게 정하느냐에 달렸다. 그래서 다음에 물을 것은 이것이다. 우리의 환경은 지금 현실의 어떤 얼굴을 하고 있을까.