운전석에는 누가 앉아야 할까 클라우드가 쓰고 로컬이 읽는 에이전트

오늘 다룰 연구는 Should SLMs be in the Driver's Seat? A Study of Local Models as Interpreters in Cloud-Written Agent Programs라는 제목으로 arXiv에 공개된 논문이며 식별자는 arXiv 2610.14209입니다. 원문은 제목 아래 링크로 연결해 두었습니다. 이 연구가 내세우는 주장은 한 문장으로 정리할 수 있습니다. 바로 클라우드가 미리 짠 프로그램이 실행 중에만 보이는 내용을 기기 안 작은 모델에게 함수 호출로 해석시키면, 사용자 데이터를 밖에 내놓지 않고도 에이전트 성공률을 끌어올릴 수 있다는 것이죠.

안녕하세요, 패트릭입니다. 저는 에이전트를 실제로 써볼 때마다 묘한 불편함을 느꼈습니다. 일을 잘하는 에이전트일수록 제 메일과 일정과 파일을 더 많이 읽어야 했기 때문이죠. 그래서 편하자면 감시받는 느낌이 들고, 안전하자면 성능이 뚝 떨어집니다. 저는 바로 이 교환이야말로 이번 논문이 파고든 지점이라고 봤습니다. 그렇다면 운전석이라는 비유는 무엇을 가리킬까요. 저는 누가 핸들을 잡고 누가 길을 읽을지를 나누는 문제로 읽었습니다.

왜 이 논문을 붙잡고 읽게 됐을까

저는 평소처럼 숫자를 확인하기 전에 이 논문의 문제 설정부터 오래 들여다봤습니다. 에이전트 논문은 대개 성공률 숫자만 늘어놓지만, 이 논문은 숫자를 올리기 전에 어디서 데이터를 읽을지를 먼저 묻고 있으니까요. 가장 정확한 에이전트는 대개 큰 클라우드 모델이 사용자의 사적인 내용을 직접 읽으면서 일을 처리합니다. 반면 기기에서 도는 작은 모델은 데이터를 밖에 내보내지 않지만 결과가 훨씬 떨어지죠. 이 간극을 저는 이전부터 체감하고 있었습니다. 로컬 모델에게 일정을 정리해 달라고 하면 빠르지만 엉뚱한 답이 돌아왔고, 클라우드 에이전트에게 맡기면 정확했지만 모든 문서를 올려야 했기 때문입니다.

여기서 재미있는 질문이 생깁니다. 정확도와 프라이버시는 늘 맞바꿔야만 할까요. 논문이 던지는 답은 셋째 길에 가깝습니다. 계획을 짜는 일과 눈앞의 내용을 읽는 일을 분리하자는 것이죠. 계획은 큰 모델이 미리 세우고, 실행 중에만 나타나는 문장이나 화면이나 기록은 작은 모델이 그 자리에서 읽습니다. 저는 이 구분이 마음에 들었습니다. 연구실 점수 놀음처럼 보이지 않았고, 제품을 만들 때 매일 부딪히는 타협점을 정면으로 건드렸기 때문입니다. 그래서 이번 글에서는 성공률 숫자보다 그 뒤의 구조를 따라가 보려고 합니다.

가장 잘하는 에이전트가 가장 꺼려지는 이유

여러 사람이 함께 일하다 보면, 일을 잘하는 동료에게 더 많은 비밀을 털어놓게 됩니다. 에이전트도 구조가 비슷합니다. 오늘날 일을 가장 잘 처리하는 에이전트는 대개 큰 클라우드 모델이 사용자 데이터를 직접 읽으면서 매 단계를 판단하는 방식이니까요. 그래서 메일 본문을 열어보고, 캘린더의 약속 이름을 확인하고, 앱 안의 버튼과 목록을 하나씩 해석하면서 다음 행동을 정합니다. 이렇게 하면 판단이 유연해집니다. 화면에 갑자기 낯선 문구가 나타나도 그 자리에서 의미를 파악할 수 있으니까요.

문제는 그다음입니다. 정확해지려면 데이터를 올려야 하고, 데이터를 올리면 밖에 나간 정보를 되돌릴 수 없기 때문입니다. 특히 기업 일정이나 의료 기록이나 가족 사진처럼 민감한 내용이 섞여 있을 때 이 비용은 더 크게 느껴집니다. 물론 기기 안에서만 도는 작은 모델을 쓰면 데이터는 밖에 나가지 않습니다. 하지만 이 선택은 정확도를 크게 깎아먹습니다. 작은 모델은 긴 지시를 끝까지 따라가거나 여러 앱을 오가며 상태를 관리하는 일에 약하기 때문이죠. 같은 모델에 같은 질문을 던져도 결과가 크게 달라질 수 있다는 것을 경험으로 알고 있는데, 특히 여러 단계가 엮인 작업에서는 한 번의 오해가 다음 단계까지 번지면서 전체가 무너집니다.

저는 여기서 멈칫했습니다. 우리가 흔히 말하는 온디바이스 AI가 프라이버시 문제를 풀었다는 이야기는 절반만 맞기 때문입니다. 데이터를 안 보내는 것은 맞지만, 그래서 일을 못 끝내면 사용자는 결국 다시 클라우드로 돌아가니까요. 이러면 프라이버시는 구호에 그치고, 정확도는 클라우드가 독점하는 구도가 굳어집니다. 논문은 이 구도를 정면으로 부수려 하지 않습니다. 대신 질문을 바꿨습니다. 큰 모델의 계획 능력을 빌리되, 사적인 내용은 끝까지 기기 안에 둘 수는 없을까 하고 말이죠.

코드를 미리 짜두면 프라이버시가 해결될까

앞의 고민에서 자연스럽게 떠오르는 대안이 있습니다. 큰 모델이 사용자 데이터를 보기 전에 프로그램만 짜주고, 실행은 기기가 하면 되지 않을까 하는 것이죠. 실제로 논문이 정리한 기준선 중 하나가 바로 이 코드만 쓰는 방식입니다. 클라우드 모델은 사용자 기록을 한 번도 보지 않고 어떤 앱을 어떤 순서로 두드릴지에 대한 절차를 코드로 적어 내려보냅니다. 그러면 기기는 그 코드를 그대로 실행하면서 로컬 데이터에 접근합니다. 겉으로 보면 깔끔합니다. 큰 모델은 계획을 제공하고, 작은 기기는 데이터를 지키니까요.

그런데 막상 돌려보면 어딘가에서 삐걱거립니다. 절차는 맞지만 눈앞의 문장을 읽지 못하기 때문입니다. 예를 들어 제가 상상해본 장면은 이렇습니다. 프로그램에는 주문 목록에서 환불 가능한 항목을 고르라는 지시가 들어 있는데, 막상 앱을 열어보니 항목 옆에 작게 적힌 조건 문구가 제각각인 경우입니다. 코드는 조건을 비교하는 틀까지는 짤 수 있지만, 그 문구가 실제로 무엇을 뜻하는지는 실행 전에는 알 수 없습니다. 화면에 뜬 문장이나 메모에 적힌 약어, 상대가 갑자기 바꿔 쓴 표현처럼 실행 중에만 나타나는 내용은 미리 짠 분기로 다 덮을 수 없죠. 결국 프로그램은 멈추거나 엉뚱한 항목을 고릅니다.

이 대목은 생각보다 중요합니다. 코드만 쓰는 방식이 실패하는 이유가 코드가 짧아서가 아니라, 세상이 코드보다 늦게 정해지기 때문입니다. 사용자 데이터라는 것은 대부분 실행 전에는 존재하지 않거나 형태가 정해지지 않은 것들이기 때문이죠. 그래서 논문이 지적한 한계는 구조적입니다. 계획과 해석을 같은 주체가 하지 않으면서 해석 자체를 아예 없애버리면, 그 빈자리가 매번 실패로 돌아간다는 것이죠. 그렇다면 해석을 살리되 데이터를 밖에 내보내지 않는 방법은 없을까요. 그 이야기는 다음 대목으로 이어집니다.

운전은 클라우드가 하고 해석은 로컬이 맡는다

논문이 제안하는 구조는 제목의 비유를 그대로 풀어쓴 것입니다. 운전석이라는 말을 들으면 흔히 모든 판단을 한 주체가 한다는 느낌이 듭니다. 하지만 이 논문은 핸들을 둘로 나눕니다. 큰 모델은 출발 전에 경로를 그리고, 작은 모델은 운전 중에 표지판을 읽는 식이죠. 기술적으로는 클라우드가 짠 프로그램 안에 로컬 모델을 부르는 평범한 함수 호출이 들어 있습니다. 프로그램이 실행되다가 애매한 내용이 나타나면 그 내용을 통째로 클라우드에 보내지 않고, 기기 안 작은 모델에게 짧게 물어봅니다.

이 차이는 생각보다 큽니다. 예전처럼 작은 모델에게 처음부터 끝까지 운전을 맡기는 것이 아니기 때문입니다. 작은 모델이 맡는 일은 전체 계획을 세우거나 여러 앱의 상태를 조율하는 일이 아니라, 눈앞의 문장이 무엇을 뜻하는지나 이 목록에서 조건에 맞는 항목이 무엇인지처럼 범위가 좁은 질문에 답하는 일로 줄어듭니다. 범위가 좁아지면 작은 모델도 훨씬 잘합니다. 긴 추론 사슬을 이어가지 않아도 되고 기억해야 할 문맥도 짧아지기 때문이죠. 마치 복잡한 계약서를 처음부터 쓰라고 하면 버거워도, 특정 조항이 무슨 뜻인지 물으면 잘 답하는 사람과 비슷합니다.

저는 이 구분이야말로 이번 연구에서 가장 눈여겨볼 대목이라고 봅니다. 흔히 모델 크기를 키우면 만사가 해결된다고 말하지만, 여기서는 크기 대신 역할 나누기가 해답으로 등장하니까요. 큰 모델은 추상화와 계획에 쓰고, 작은 모델은 현장의 언어 해석에 쓰는 셈입니다. (여담으로 제목의 운전석이라는 표현을 처음 봤을 때는 자율주행 이야기인 줄 알았습니다. 읽어보니 에이전트의 주도권을 누가 쥘지에 대한 비유였습니다.) 물론 이 구조가 만능은 아닙니다. 함수 호출로 물어볼 수 있는 질문을 어떻게 설계할지, 작은 모델이 틀렸을 때 프로그램이 어떻게 복구할지가 여전히 남기 때문입니다. 하지만 방향은 분명합니다. 데이터를 옮기지 말고 질문을 옮기자는 것이죠.

함수 하나로 묻고 답하는 구조는 어떻게 돌까

이제 이 구조가 실제로 어떻게 도는지 따라가 보겠습니다. 출발점은 클라우드 모델이 사용자 데이터를 한 번도 보지 않은 상태라는 점입니다. 이 상태에서 큰 모델은 과제를 푸는 절차를 프로그램으로 적습니다. 어떤 앱을 열고 어떤 목록을 가져오고 어떤 조건으로 골라낼지에 대한 뼈대죠. 여기까지는 기존의 코드만 쓰는 방식과 비슷해 보입니다. 달라지는 지점은 애매한 판단이 필요한 자리에 미리 빈칸을 두는 대신, 그 빈칸을 채우는 질문을 함수로 넣어둔다는 데 있습니다.

실행이 시작되면 기기는 이 프로그램을 위에서부터 실행합니다. 데이터가 필요 없는 부분은 코드가 그대로 처리하고, 눈앞의 문장을 해석해야 하는 부분에 닿으면 로컬 모델을 호출합니다. 이때 넘어가는 것은 전체 작업 기록이 아니라 지금 판단에 필요한 짧은 내용과 질문뿐입니다. 그래서 작은 모델은 그 질문에만 답하고 프로그램은 그 답을 받아 다음 단계로 넘어갑니다. 결과적으로 클라우드는 계획을 세웠지만 사적인 내용은 끝까지 보지 못하고, 로컬 모델은 내용을 봤지만 전체 계획을 쥐지 않는 분업이 성립합니다.

좋은 건 알겠는데, 이걸 실제로 어떻게 물을까요. 논문이 말하는 bounded question이라는 표현이 바로 그 감각을 가리킵니다. 끝없이 열린 질문을 던지는 것이 아니라 답의 형태가 정해진 좁은 질문을 던진다는 뜻이죠. 예를 들어 가상의 장면으로 바꿔 말하면, 오늘 온 메일 중에서 환불 관련 메일을 골라달라는 식의 넓은 부탁이 아니라, 이 문장이 환불 가능을 뜻하는지 그렇지 않은지만 답해달라는 식입니다. 이렇게 물으면 작은 모델의 부담이 줄고, 프로그램도 답을 받아 처리하기 쉬워집니다. 실제로 시스템을 만들 때도 이런 식으로 질문을 좁히는 일이 성패를 가릅니다. 저는 그래서 이 함수 호출을 단순한 구현 잔재주가 아니라 설계의 본체로 읽었습니다. 무엇을 물을지를 정하는 일이 곧 에이전트의 능력을 정하기 때문입니다.

여섯 번의 대결에서 모두 이긴 작은 변화

여기까지는 구조 이야기였고, 이제는 측정이 나올 차례입니다. 연구진이 사용한 무대는 AppWorld라는 에이전트 과제 묶음입니다. 서로 다른 뼈대 모델과 평가 구간을 조합한 여섯 가지 조건에서 코드만 쓰는 방식과 로컬 해석을 더한 방식을 나란히 비교했죠. 저는 이 설정을 보고 고개를 끄덕였습니다. 한두 조건에서만 이기는 결과는 우연일 수 있지만, 여섯 조합 모두에서 같은 방향이 나온다면 구조가 무언가를 건드렸다고 보는 편이 자연스러우니까요.

결과는 방향이 분명했습니다. 로컬 해석을 더한 방식이 여섯 조합 모두에서 코드만 쓰는 방식보다 성공률이 높았고, 격차는 조건에 따라 최대 14.9퍼센트포인트까지 벌어졌습니다. 숫자를 조금 풀어보면 의미가 더 또렷해집니다. 코드만으로 돌릴 때 풀리지 않던 과제 중 적지 않은 수가 로컬 모델의 짧은 해석 한두 번으로 풀렸다는 뜻이죠. 14.9라는 숫자는 그 자체로 크지만, 저는 여섯 번 모두 이겼다는 사실 쪽을 더 눈여겨봤습니다. 편차가 큰 에이전트 실험에서 여섯 번 연속 같은 방향이 나온다는 것은, 특정 과제나 특정 뼈대 모델에 기대어 얻은 우연이 아니라는 신호에 가깝기 때문입니다.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 성공률이 올랐다는 말은 실패가 사라졌다는 말이 아니기 때문입니다. 로컬 모델이 해석을 틀리면 프로그램도 함께 틀어지고, 질문 자체를 잘못 설계하면 호출 횟수만 늘어날 수 있습니다. 그럼에도 이 결과는 코드만 쓰는 방식의 빈자리가 정확히 어디였는지를 보여줍니다. 부족했던 것은 더 긴 코드가 아니라 현장의 눈이었고, 그 눈을 기기 안에서 조달해도 효과가 있었다는 것이죠. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이런 잣대로 보면 이번 개선은 비용을 크게 늘리지 않고 실패 지점만 메운 셈이라 실용적인 냄새가 납니다.

클라우드 ReAct와의 거리는 얼마나 좁혀졌을까

여기서 한 걸음 더 들어가 보겠습니다. 로컬 해석을 더한 방식이 코드만 쓰는 방식보다 낫다는 것은 알겠는데, 그렇다면 가장 강한 상대와 견주면 어떨까요. 논문은 클라우드에서 큰 모델이 매 단계를 직접 읽고 행동하는 ReAct 방식을 그 상대로 둡니다. 이 방식은 사용자 데이터를 직접 보기 때문에 정확도가 높지만, 프라이버시 측면에서는 가장 비싼 선택이죠. 그래서 진짜 질문은 이것입니다. 데이터를 밖에 내놓지 않으면서 그 강한 상대와의 격차를 얼마나 좁힐 수 있을까 하는 것이죠.

논문의 답은 상당 부분을 메웠다는 쪽에 가깝습니다. 로컬 해석을 더한 구조는 코드만 쓰는 방식과 클라우드 ReAct 방식 사이의 간극 중 적지 않은 몫을 되찾았다고 보고됐습니다. 저는 이 표현을 읽으면서 두 가지 감정이 들었습니다. 하나는 고무적인 쪽으로, 데이터를 기기에 둔 채로 강한 방식에 다가갔다는 것은 제품 관점에서 큰 진전이기 때문입니다. 다른 하나는 경계하는 쪽으로, 상당 부분이라는 말이 정확한 점수로 고정된 것이 아니라 구간과 조건에 따라 달라질 수밖에 없기 때문입니다. 모든 과제에서 같은 비율로 격차가 좁혀졌다고 읽으면 실험을 과장하는 셈입니다.

그럼에도 이 대목이 주는 메시지는 또렷합니다. 프라이버시를 지키는 선택이 정확도를 조금 깎는 대가가 아니라, 구조를 바꾸면 대가를 줄일 수 있는 변수라는 것이죠. 예전에는 로컬에서 돌리면 무조건 성능이 떨어진다고 생각했습니다. 하지만 이제는 어디서 손해가 나는지를 찢어볼 수 있게 됐습니다. 계획의 손해인지 현장 해석의 손해인지를 나누면, 후자는 기기 안에서도 메울 수 있다는 것이 이번 결과의 주장입니다. 물론 ReAct 방식이 여전히 더 잘하는 영역은 남습니다. 여러 단계에 걸친 추론이 꼬이거나 질문 설계가 빗나가면 로컬 해석만으로 다 덮을 수 없으니까요. 그래서 저는 이 결과를 완전한 역전으로 읽지 않고, 간극의 성격이 바뀌었다는 신호로 읽었습니다.

통역사를 조수석에 앉히는 셈이다

앞의 이야기를 다른 비유로 바꿔보면 이해가 더 쉬워집니다. 클라우드가 미리 써둔 프로그램은 여행 계획표와 비슷하고, 로컬 모델은 현장에서 표지판을 읽어주는 통역사와 비슷합니다. 계획표가 아무리 정교해도 현장의 표지판을 읽지 못하면 길에서 헤매고, 통역사가 아무리 언어를 잘해도 전체 일정이 없으면 갈 곳을 모릅니다. 이번 구조는 둘을 한 차에 태우되 앉는 자리를 분명히 한 셈입니다. 계획은 큰 모델이, 해석은 작은 모델이 맡죠.

그렇다면 이 아이디어가 아닌 것은 무엇일까요. 먼저 이것은 작은 모델 하나로 모든 일을 하겠다는 주장이 아닙니다. 작은 모델을 운전석에 앉히는 것이 아니라 조수석에 앉히되, 꼭 필요한 순간에만 길을 묻게 만듭니다. 또한 클라우드가 사용자 데이터를 몰래 보는 구조도 아닙니다. 프로그램은 데이터가 없는 상태에서 미리 쓰이고, 실행 중에 데이터와 만나는 주체는 기기 안 모델뿐이기 때문입니다. 이 분리는 말로만 된 약속이 아니라 실행 구조로 보장되는 편에 가깝습니다. 코드가 먼저 고정되고 데이터가 나중에 들어오기 때문이죠.

사람도 비슷하게 배웁니다. 처음에는 모든 일을 혼자 하려다가, 어느 순간부터는 잘하는 사람에게 일을 나눠주기 시작합니다. 에이전트 설계도 같은 곡선을 그리는 것 같습니다. 처음에는 큰 모델 하나가 모든 것을 읽고 판단했고, 다음에는 코드를 미리 짜서 데이터를 지키려 했고, 이제는 해석이라는 일을 따로 떼어 기기에 두는 단계로 왔습니다. 저는 이 흐름이 자연스럽게 느껴졌습니다. 모델을 키우는 것만이 능사가 아니라, 일을 나누는 법을 배우는 쪽이 더 어른스러운 진화니까요. 다만 통역사가 항상 정확한 것은 아니라는 점은 잊지 말아야 합니다. 현장 해석이 틀리면 계획이 아무리 좋아도 길은 어긋나니까요.

실제 제품에 올리려면 무엇이 남았을까

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 구조를 밤사이 수만 명이 쓰는 서비스에 올리면 무엇이 깨질까요. 저는 논문의 숫자를 떠나 이 대목을 가장 길게 생각했습니다. 연구실에서는 통하던 구조가 운영에서는 다른 비용을 만나기 때문입니다. 먼저 로컬 모델을 부르는 횟수와 시점이 문제입니다. 매 단계마다 작은 모델을 부르면 기기의 발열과 배터리가 늘어나고 응답도 느려집니다. 반대로 너무 아껴 부르면 다시 코드만 쓰는 방식의 실패로 돌아갑니다. 어디서 물을지를 정하는 감각이 곧 제품의 체감 속도를 정합니다.

다음으로 질문 설계의 품질이 남습니다. 좁은 질문을 잘 만들면 작은 모델도 잘 답하지만, 질문이 모호하면 답도 모호해집니다. 프로그램이 물을 내용을 미리 고정해야 하지만, 현장의 문장은 매번 조금씩 다르니까요. 이때 프로그램이 너무 엄격하면 예외를 놓치고, 너무 느슨하면 로컬 모델에게 과도한 판단을 떠넘기게 됩니다. 운영 측면에서 보면 이 경계 조율이 매주 손이 가는 일이 될 가능성이 큽니다. 새로운 앱 화면이나 새로운 표현이 등장할 때마다 질문 문구를 손봐야 하기 때문이죠.

그럼에도 저는 이 구조가 운영 친화적인 면을 가졌다고 봅니다. 데이터가 기기 경계를 넘지 않으니 전송과 저장에 얽힌 부담이 줄고, 클라우드 호출 횟수도 매 단계 판단 방식보다 적어질 수 있기 때문입니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 종목이 거래 정지에 걸려도 예측 라인은 멈추면 안 되는 것처럼, 에이전트도 네트워크가 흔들려도 멈추지 않아야 합니다. 기기 안에서 해석이 끝나면 그 복원력이 생기죠. 물론 작은 모델을 기기에 올리는 일 자체가 메모리와 업데이트 부담을 만듭니다. 모델을 언제 갈아끼우고, 기기마다 성능이 다를 때 질문 난이도를 어떻게 맞출지는 여전히 숙제입니다. 그래서 저는 이 논문을 완성된 처방이 아니라 운영 가능한 출발점으로 읽었습니다.

그래서 운전석의 주인은 누구일까

마지막으로 처음으로 돌아가 보겠습니다. 제목이 묻는 운전석의 주인은 누구일까요. 논문의 답은 한 사람이 다 차지하는 자리가 아니라는 쪽에 가깝습니다. 큰 모델이 길을 그리고 작은 모델이 표지판을 읽는 분업이야말로 데이터를 지키면서 일을 끝내는 방법이라는 것이죠. 여섯 가지 조건 모두에서 성공률이 올랐고, 격차가 최대 14.9퍼센트포인트까지 벌어졌으며, 강한 클라우드 방식과의 거리 중 적지 않은 몫을 되찾았다는 결과는 그 분업이 우연이 아니라는 쪽에 힘을 싣습니다. 겉으로 보면 단순한 함수 호출 하나지만, 그 호출이 가리키는 책임 나누기가 이번 이야기의 본체라고 저는 봅니다.

제가 앞으로 보고 싶은 것은 이 분업이 어디까지 버티는지입니다. 화면이 아닌 음성이나 영상처럼 해석이 더 어려운 내용이 들어오면 로컬 모델의 부담이 커질 텐데, 그때도 좁은 질문만으로 버틸 수 있을까요. 또한 작은 모델이 틀렸을 때 프로그램이 스스로 물음을 고쳐 묻는 되묻기 구조가 가능할까요. 지금 구조는 묻고 답하는 흐름이 한 방향에 가깝지만, 현장이 복잡해질수록 되묻기가 필요해질 것 같습니다. 그리고 기기마다 작은 모델의 실력이 다를 때 프로그램이 그 차이를 어떻게 흡수할지도 궁금합니다. 같은 질문이라도 기기에 따라 답의 품질이 달라질 수 있으니까요.

그렇다면 사람의 역할은 무엇일까요. 저는 에이전트가 더 똑똑해질수록 무엇을 맡길지와 무엇을 맡기지 않을지를 정하는 일이 더 중요해진다고 봅니다. 모든 메일을 읽어주는 편리함 뒤에는 모든 메일을 건네준다는 선택이 있고, 그 선택은 결국 사람이 해야 하니까요. 이번 연구는 그 선택지를 하나 늘려줬습니다. 데이터를 내놓지 않고도 일을 끝낼 수 있는 길이 있다는 것을 보여준 것이죠. 다음에 에이전트를 고를 때 저는 성공률 숫자 옆에 한 가지를 더 물을 것 같습니다. 당신의 데이터는 어디에서 읽히나요 하고 말이죠.