조용히 어긋나는 에이전트 데이터 사이언스

The Silent Failures in Agentic Data Science는 arXiv에 공개된 연구로 식별자 2610.14115를 갖고 있으며, 원문 링크는 이 글의 제목 아래에 걸어 두었습니다.

이 연구가 던지는 주장은 한 문장으로 정리됩니다, 에이전트가 만든 데이터 사이언스 풀이는 겉으로 실행되고 점수까지 내지만 방법론 어딘가에서 조용히 어긋나는 경우가 잦으며 220개 과제와 여섯 가지 실수에 대한 별도 시험 그리고 Kaggle 우승 풀이와의 나란한 비교를 통해 정확도 중심 평가가 왜 그 어긋남을 가리는지를 이 글에서 차례로 풀어 보겠습니다.

돌아가는 코드 앞에서 저는 잠시 멈췄습니다

안녕하세요, 패트릭입니다.

저는 평소에 에이전트가 짠 코드를 볼 때 실행이 되는지부터 확인하곤 하는데요, 이번 연구를 읽으면서 그 습관을 다시 생각하게 됐습니다. 실행된다는 사실이 곧 올바르다는 뜻은 아니기 때문입니다. 데이터 사이언스에서는 돌아가는 코드가 오히려 의심을 미뤄주는 가림막이 되기도 합니다. 에러가 없으니 넘어가고, 숫자가 나오니 믿게 되죠. 그런데 그 숫자가 어디에서 왔는지를 묻기 시작하면 이야기가 달라집니다.

제가 이 논문에서 가장 길게 눈길을 준 부분은 바로 그 지점이었습니다. 실패가 소리 없이 일어난다는 표현이 정확하다고 봤거든요. 터지는 실패는 고치면 됩니다. 로그에 빨간 글씨가 뜨고, 스택 트레이스가 나오고, 어디를 손봐야 할지 알려주니까요. 반면 방법론의 실패는 조용합니다. 코드는 끝까지 돌아가고, 제출 파일도 만들어지고, 점수까지 찍힙니다. 그래서 문제를 알아채기가 더 어렵습니다. 여러분도 비슷한 장면을 보신 적이 있을 겁니다. 월요일 아침에 누군가 정확도가 올랐다고 보고하는데, 막상 어떻게 나눠서 검증했냐고 물으면 답이 머뭇거리는 장면 말이죠.

그렇다면 소리 없는 실패를 어떻게 들리게 만들 수 있을까요. 연구팀이 고른 방법은 실패를 일부러 따로 떼어내는 것이었습니다. 점수라는 합창 속에 묻힌 잡음을 하나씩 분리해서 듣는 방식이죠. 저는 이 접근이 운영 감각과 닿아 있다고 봅니다. 배포 전에 각 단계를 따로 흔들어보는 절차와 비슷하니까요.

220개 과제에서 무엇을 재었을까요

연구팀은 흔히 쓰는 에이전트 틀과 모델들을 가져다가 220개 데이터 사이언스 과제에 풀어보게 했습니다. 규모를 먼저 말하는 이유는 범위가 해석을 바꾸기 때문입니다. 한두 개 과제에서 삐끗한 것과 220개에서 반복되는 것은 무게가 다르죠. 같은 실수가 여러 틀과 여러 모델에서 되풀이된다면, 그건 특정 구현의 버그라고 부르기 어렵습니다. 풍토에 가깝습니다.

여기서 재미있는 질문이 생깁니다. 왜 하필 과제 수를 늘렸을까요. 답은 에이전트의 실패가 조건을 타기 때문입니다. 어떤 과제에서는 멀쩡해 보이다가, 검증 방식이 까다로워지거나 시간 순서가 얽히면 비로소 드러나는 실수가 있습니다. 과제가 적으면 그런 조건을 놓치기 쉽습니다. 그래서 과제를 넓게 깔아두면 실수의 얼굴이 더 또렷해집니다. 저는 이런 설계가 설득력이 있다고 봤습니다. 한 번의 인상적인 성공보다 여러 조건에서의 반복되는 어긋남이 말해주는 바가 크니까요.

물론 과제 수가 많다고 해서 모든 의문이 풀리는 건 아닙니다. 220개라는 숫자는 범위를 넓혀주지만, 각 과제가 현실의 지저분함을 얼마나 담고 있는지는 또 다른 문제입니다. 실제 데이터는 결측이 있고, 라벨 정의가 바뀌고, 마감 전날 스키마가 바뀌기도 하니까요. 그럼에도 통제된 과제 묶음은 출발점으로 쓸모가 있습니다. 어디에서 자주 넘어지는지를 지도처럼 보여주기 때문입니다. 이 지도가 있으면 다음 질문으로 넘어갈 수 있습니다. 자주 넘어지는 곳에 무엇이 있었을까요.

여섯 가지 실수를 따로 떼어 시험하는 까닭

연구팀은 여섯 가지 방법론 실수를 겨냥한 별도 과제 묶음을 만들었습니다. 다시 쓸 수 있고, 다른 사람이 이어서 확장할 수 있는 형태로요. 이 대목은 길게 곱씹을 만합니다. 보통 평가는 과제 하나를 주고 점수를 매깁니다. 그런데 이 방식으로는 무엇이 잘못됐는지를 알기 어렵습니다. 점수는 결과만 말해주고, 과정은 말해주지 않으니까요. 반면 실수마다 따로 시험지를 만들면 이야기가 달라집니다. 어떤 시험지에서 미끄러졌는지가 그대로 진단이 되기 때문입니다.

생각해보면 사람도 비슷하게 배웁니다. 모의고사 총점만 보는 것과 과목별 오답 분포를 보는 것은 다르죠. 총점은 기분을 말해주고, 분포는 처방을 알려줍니다. 연구팀이 만든 묶음은 후자에 가깝습니다. 데이터 리크처럼 과정을 오염시키는 실수, 검증을 어긋나게 짜는 실수를 각각 따로 불러내서 묻습니다. 저는 이런 분리가 에이전트 평가에서 오래 비어 있던 자리였다고 봅니다. 실행 여부와 점수만으로는 채울 수 없는 자리 말이죠.

그런데 여기서 조심해서 읽을 대목이 있습니다. 따로 시험한다는 건 현실을 단순화한다는 뜻이기도 합니다. 실제 파이프라인에서는 여러 실수가 겹쳐서 일어나고, 서로를 가리기도 합니다. 그럼에도 분리는 필요합니다. 겹친 실패는 한 번에 고치기 어렵고, 분리된 실패는 가르치기 쉽기 때문입니다. 이 시험 묶음이 앞으로 다른 팀 손에서 늘어난다면, 에이전트의 성적표는 지금보다 훨씬 읽기 쉬워질 겁니다.

절반 넘는 풀이에서 같은 균열이 보였습니다

연구팀의 관찰은 직설적이었습니다. 틀을 바꾸고 모델을 바꿔도, 절반을 넘는 풀이에서 적어도 하나의 방법론 어긋남이 나왔다는 것이죠. 이 문장은 천천히 읽어야 합니다. 틀의 복잡함이 결과를 구해주지 못했고, 모델의 용량이 커졌다고 해서 실수가 사라지지 않았다는 뜻이기 때문입니다. 흔히 우리는 문제가 생기면 틀을 두껍게 하거나 모델을 키우면 되지 않을까 생각합니다. 그런데 이번 결과는 그 기대에 제동을 겁니다.

왜 그럴까요. 저는 이유가 에이전트의 일하는 순서에 있다고 봅니다. 에이전트는 주어진 목표를 향해 다음 행동을 고르는 데에는 능숙합니다. 파일을 읽고, 코드를 짜고, 실행하고, 고치고, 다시 돌리죠. 그런데 그 과정에서 방법론의 경계는 잘 보지 못합니다. 학습에 쓰면 안 되는 정보가 흘러들었는지, 검증을 나눈 방식이 시간 흐름을 거스르는지 같은 경계 말이죠. 이런 경계는 실행 로그에 빨간 글씨로 뜨지 않습니다. 그래서 더 두꺼운 틀도, 더 큰 모델도 같은 곳에서 미끄러집니다.

여기서 한 가지 오해를 바로잡고 싶습니다. 절반이 넘는다는 말이 모든 에이전트가 엉망이라는 뜻으로 읽히면 곤란합니다. 코드가 돌아가지 않았다는 뜻으로도 읽히면 곤란하죠. 코드는 대개 잘 돕니다. 문제는 코드가 도는 층위보다 방법이 서 있는 층위에 있다는 것이죠. 집으로 치면 전등은 다 켜지는데 기초에 금이 간 상태와 비슷합니다. 불이 켜지니 당장은 살 만하지만, 비가 오면 이야기가 달라집니다. 데이터 사이언스에서 비는 새로운 데이터, 바뀌는 분포, 마감 이후의 시간입니다.

점수가 높을수록 의심해야 하는 역설

저는 여기서 조금 멈칫했습니다. 데이터 리크가 있는 풀이일수록 예측 점수가 더 잘 나오는 경향이 관찰됐기 때문입니다. 곰곰이 생각해보면 당연한 면이 있습니다. 미래의 답을 슬쩍 본 시험지가 점수가 잘 나올 수밖에 없으니까요. 그런데 당연하다고 해서 가볍게 넘길 일이 아닙니다. 우리가 점수로 모델을 고르는 한, 잘못된 방법이 더 좋은 옷을 입고 뽑히는 일이 벌어지기 때문입니다.

이 차이는 생각보다 무게가 있습니다. 보통 리더보드는 점수 순서대로 줄을 세웁니다. 위에 있는 풀이가 더 좋은 풀이겠거니 하고 믿죠. 그런데 리크가 섞여 있으면 그 믿음이 깨집니다. 위쪽에 있는 풀이가 더 정직해서 올라온 경우도 있고, 더 많이 봐서 올라온 경우도 있기 때문입니다. 여러분이 속한 팀에서도 비슷한 일이 생길 수 있습니다. 분기 보고회에서 정확도가 오른 모델이 박수를 받는데, 나중에 알고 보니 검증 구간에 다음 달 정보가 섞여 있던 경우 말이죠. 그날의 박수는 정당했을까요.

그렇다면 이 흐름은 어디에서 끊을 수 있을까요. 그 이야기는 평가 방식을 다루는 대목에서 다시 꺼내겠습니다. 다만 여기서 미리 말해둘 수 있는 것이 있습니다. 점수와 올바름을 같은 말로 쓰지 않는 습관이 필요합니다. 점수는 결과가 얼마나 그럴듯한지를 말해주고, 올바름은 그 결과가 믿을 만한 절차에서 왔는지를 말해주기 때문입니다. 두 단어를 일부러 다르게 쓰는 것만으로도 팀의 대화가 달라집니다.

정확도와 올바름은 왜 따로 놀까요

지금의 평가는 대개 두 가지를 봅니다. 예측 점수와 코드가 도는지 여부죠. 이 두 가지는 분명히 쓸모가 있습니다. 돌아가지 않는 코드는 쓸 수 없고, 점수가 너무 낮은 모델은 쓸 이유가 없으니까요. 그런데 이 두 가지만으로는 방법론의 어긋남을 잡아내기 어렵습니다. 리크가 있어도 코드는 돕니다. 검증이 어긋나도 점수는 나옵니다. 그러니 점수판만 오래 보고 있으면 실패는 계속 조용히 남습니다.

저는 이 대목을 읽으면서 시험장 비유를 떠올렸습니다 (시험장에서 답안지만 채점하고 풀이 과정은 보지 않는 모습과 비슷합니다. 답이 맞았으니 넘어가는데, 나중에 알고 보면 옆 답을 본 경우와 비슷하죠). 과정 점수를 주자는 말이 아닙니다. 다만 답이 맞는 이유를 묻는 절차가 있어야 한다는 뜻입니다. 어떤 정보를 보고 배웠는지, 어떤 구간으로 검증했는지, 시간 순서를 지켰는지 같은 질문 말이죠. 이런 질문은 점수표에 숫자로 찍히지 않지만, 모델을 믿어도 되는지를 가릅니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그럼 절차 검사는 얼마나 자주, 얼마나 깊게 해야 할까요. 매번 모든 파이프라인을 뜯어볼 수는 없으니까요. 저는 답이 단계마다 다르다고 봅니다. 학습 데이터와 검증 구간이 만나는 지점, 시간 정보가 들어오는 지점, 외부 데이터가 합쳐지는 지점처럼 오염이 잘 일어나는 목부터 보면 됩니다. 하수구 냄새가 나는 곳부터 찾는 것과 비슷합니다. 모든 배관을 뜯지 않아도 냄새가 나는 연결부부터 보면 되죠.

우승자의 노트와 에이전트의 답은 어디서 갈라질까요

연구팀은 Kaggle 대회의 우승 풀이와 에이전트 파이프라인을 나란히 놓고 질적으로 견주었습니다. 점수 비교를 넘어 일하는 방식 비교에 가까웠다는 점이 눈여겨볼 대목입니다. 우승자의 풀이를 보면 문제에 대한 해석이 먼저 보입니다. 어떤 변수가 왜 판도를 가르는지, 어떤 누수가 숨어 있을지, 시간 흐름을 어떻게 존중할지 같은 판단이 코드 곳곳에 배어 있습니다. 반면 에이전트의 풀이는 절차가 매끈합니다. 빨리 돌리고, 빨리 고치고, 빨리 점수를 냅니다. 그런데 그 매끈함 속에 도메인에 대한 망설임이 잘 보이지 않습니다.

이 차이를 저는 창의성과 배경 지식의 차이로 읽었습니다. 연구팀도 비슷한 판단을 내놓았는데요, 에이전트가 경쟁 우승자들에 비해 문제 풀이의 창의성과 도메인 지식이 부족해 보인다는 것이죠. 여기서 창의성이라는 말은 거창한 발명을 뜻하지 않습니다. 이상한 분포를 보고 멈춰 서는 능력, 변수 하나를 보고 이건 시간 순서상 쓰면 안 되겠다고 판단하는 능력 같은 것입니다. 이런 판단은 교과서에서 배우기보다 바닥에서 배웁니다. 대회를 여러 번 나가보고, 크게 속아보고, 그제야 몸에 남는 감각이죠.

물론 에이전트에게 사람만큼의 바닥 경험을 바라는 건 무리입니다. 그렇다고 해서 손을 놓을 일도 아닙니다. 우승자의 노트에는 반복되는 점검 목록이 담겨 있습니다. 리크 의심 지점, 검증 나누는 법, 시간 순서 지키는 법 같은 것들이죠. 이런 목록은 규칙으로 옮기기 비교적 쉽습니다. 저는 앞으로 보고 싶은 것이 바로 그 지점입니다. 에이전트가 더 빨리 도는 쪽으로만 좋아지면 아쉽고, 멈춰서 물을 수 있는 목록을 품게 되면 반갑죠. 잘 달리는 것보다 잘 멈추는 것이 먼저일 때가 있습니다.

그렇다면 평가는 무엇을 놓치고 있었을까요

앞에서 말한 관찰들을 한 줄로 모으면 이렇게 됩니다. 점수 중심 평가는 방법론 실패를 가리는 천이 됩니다. 코드가 도는지, 점수가 올랐는지 묻는 평가는 분명히 필요하지만, 그것만으로는 리크와 어긋난 검증을 골라내기 어렵습니다. 그래서 연구팀이 만든 여섯 가지 별도 시험이 의미를 갖습니다. 총점 대신 오답 분포를 보여주는 성적표이기 때문입니다.

저는 저희가 새로운 AI 구조를 볼 때도 점수 숫자만 보지 않으려고 애쓴다는 이야기를 가끔 합니다. 실제로 무엇이 바뀌었고, 그 변화가 운영에서 어떤 부담을 만드는지를 함께 보려고 하죠. 이번 연구도 같은 선상에 있습니다. 에이전트가 과제를 풀었다는 말 다음에, 어떤 절차로 풀었는지를 묻는 칸을 성적표에 넣자는 제안이기 때문입니다. 이 칸이 있으면 리더보드 읽는 법이 바뀝니다. 위쪽에 있는 이름이 곧 믿을 만한 이름이라는 믿음이 흔들리고, 대신 검증 절차를 통과한 이름이 눈에 들어오죠.

여기서 반론도 짚어둘 필요가 있습니다. 절차 검사를 넣으면 평가 비용이 올라갑니다. 과제마다 따로 시험지를 만들고, 풀이마다 과정을 뜯어봐야 하니까요. 겉보기에 효율이 떨어지는 것처럼 보일 수 있습니다. 그런데 길게 보면 계산이 달라집니다. 잘못된 방법으로 뽑힌 모델을 운영에 올렸다가 되돌리는 비용이 훨씬 크기 때문입니다. 한 번 잘못 올린 모델을 내리고, 데이터를 다시 나누고, 보고서를 다시 쓰는 밤의 비용을 생각해보면, 낮에 검사하는 비용은 싸게 느껴집니다. 저는 그래서 별도 시험 묶음을 비용으로 적기보다 보험으로 적습니다.

숫자보다 먼저 봐야 하는 절차가 있습니다

이쯤에서 실무 이야기를 해보겠습니다. 여러분 팀에 에이전트가 짠 파이프라인이 하나 올라왔다고 해보죠. 정확도가 지난주보다 올랐습니다. 코드는 깔끔하고, 실행 로그도 깨끗합니다. 이때 어디부터 보시겠습니까. 저는 점수 그래프보다 데이터 나누는 코드부터 펼칩니다. 언제 끊었고, 무엇을 기준으로 나눴고, 시간 정보가 섞이지 않았는지를 먼저 봅니다. 이유가 있습니다. 나누는 방식이 어긋나면 그 뒤의 모든 숫자가 흔들리기 때문입니다.

다음으로 보는 곳은 외부 정보가 들어오는 지점입니다. 타깃과 관련된 컬럼이 학습 구간에 슬쩍 들어와 있지는 않은지, 집계 변수가 미래 구간을 포함하고 있지는 않은지 확인합니다. 이런 확인은 거창한 도구가 없어도 할 수 있습니다. 컬럼 목록을 시간 순서대로 늘어놓고, 각 변수가 어느 시점에 알 수 있는 값인지를 한 줄씩 적어보는 것만으로도 많은 리크가 드러납니다. 저는 이 과정을 파이프라인의 출입 명부를 쓰는 일이라고 부릅니다. 누가 언제 들어왔는지를 적어두면, 나중에 소란이 나도 원인을 찾기 쉽죠.

마지막으로 보는 것은 검증과 보고의 간격입니다. 검증 점수와 최종 보고 점수가 너무 다르게 움직이지는 않는지, 특정 구간에서만 유독 잘 나오는 것은 아닌지 봅니다. 차이가 크다면 절차 어딘가에 기대지 못한 기둥이 있다는 신호일 수 있습니다. 물론 차이가 있다고 해서 곧바로 부정행위는 아닙니다. 다만 멈춰서 물을 이유는 됩니다. 이 질문을 던질 수 있는 팀과 없는 팀의 차이는 시간이 지날수록 벌어집니다. 질문이 쌓이면 목록이 되고, 목록이 쌓이면 문화가 되기 때문입니다.

앞으로 사람이 맡아야 할 몫은 어디에 남을까요

연구팀이 남긴 질문을 저는 이렇게 받아들였습니다. 에이전트가 코드를 대신 짜주는 시대인데, 그렇다면 사람이 더 잘해야 하는 일은 어디에 남을까요? 제가 보기에는 답이 코드를 더 빨리 짜는 쪽에 있지 않습니다. 무엇이 올바른 절차인지를 정하는 일부터, 그리고 그 절차를 지켰는지를 확인하는 일까지가 여전히 사람의 몫이기 때문입니다. 점수는 에이전트가 올려줄 수 있는데, 그 점수를 믿어도 되는지를 판단하는 일은 사람에게 남습니다. 그래서 이 구분은 앞으로 더 또렷해지리라고 봅니다.

실제 시스템 관점에서 보면 할 일은 분명합니다. 시험 묶음을 팀 안에 들여놓는 일인데, 연구팀이 공개한 형태의 별도 시험을 가져다가 자기 팀 파이프라인에 맞게 고쳐 쓰면 됩니다. 그래서 배포 전에 리크 시험을 돌리고, 검증 나누기 시험을 돌리고, 시간 순서 시험을 돌리는 식으로 고정하면 됩니다. 처음에는 번거롭게 느껴지는데, 몇 번만 돌려보면 팀마다 자주 걸리는 함정이 보이기 시작합니다. 그 함정 목록이 곧 팀의 자산이 되는데, 저는 이런 자산을 가진 팀이 에이전트를 가장 잘 쓰는 팀이 되리라고 봅니다. 결국 빨리 쓰는 팀보다 오래 믿고 쓰는 팀이 남으리라고 봅니다.

여러분은 다음 주에 무엇을 바꾸시겠습니까? 저는 작은 것부터 권하는데, 리더보드 옆에 절차 확인 칸을 하나 만드는 일입니다. 점수 옆에 검증 방식을 한 줄로 적는 칸인데, 누가 언제 어떤 구간으로 검증했는지를 적으면 됩니다. 이 한 줄이 있으면 대화가 달라지는데, 점수가 올랐다는 보고 뒤에 어떻게 나눴는지를 묻는 말이 자연스럽게 붙기 때문입니다. 그래서 그 질문이 모이면, 조용한 실패는 조금씩 소리를 내기 시작합니다. 저는 그 소리를 듣는 팀이 오래 간다고 믿습니다.