완료라고 쓰면 완료일까: AI의 기억보다 장부를 봐야 하는 이유

1. 정답을 아는 일과 일을 끝내는 일은 다릅니다

배송지를 바로잡으려면 주문에 저장된 주소를 바꿔야 합니다. 상담 메모에 올바른 주소를 적는 것만으로는 택배가 새 주소로 가지 않습니다. 사람이 보면 당연한 구분입니다. 그런데 AI 에이전트, 곧 질문에 답하는 데서 그치지 않고 프로그램을 조작해 업무를 수행하는 인공지능에는 이 구분이 중요한 시험대가 됩니다. 다음 행동을 정할 때 읽는 기록과 실제 업무 시스템에 남아 있는 값이 서로 다를 수 있기 때문입니다.

가상의 주문 사례를 보겠습니다. 고객이 배송지를 ‘301호’에서 ‘302호’로 고쳐 달라고 요청했습니다. 담당 에이전트는 수정에 실패했고 주문에는 여전히 301호가 남았습니다. 이때 인계 메모에 ‘정확한 배송지는 302호이며, 주문에는 아직 301호가 저장돼 있음’이라고 적으면 다음 담당자는 무엇을 해야 할지 알 수 있습니다. 반대로 ‘배송지를 302호로 수정 완료’라고 적으면 정답인 302호를 전달하면서도 필요한 수정 작업을 감출 수 있습니다.

두 메모에는 같은 정답이 들어 있습니다. 하지만 하나는 할 일을 남기고, 다른 하나는 할 일을 지웁니다. 이 사례는 논문의 실험 장면을 그대로 옮긴 것이 아니라, 연구가 다루는 문제를 주문 업무에 대입한 설명입니다. 중요한 것은 주소의 정확성만이 아닙니다. 그 주소가 고객의 요청인지, 앞으로 저장해야 할 값인지, 이미 저장을 마친 값인지까지 구분해야 합니다.

세일즈포스 AI 리서치의 Egor Pakhomov 등 6명이 2026년 11월 10일 공개한 논문은 바로 이 틈을 다룹니다. 연구진은 작업 중인 에이전트의 기록과 실행 환경을 함께 저장한 뒤, 기록이나 실제 상태를 바꾸고 작업을 이어가게 했습니다. 기록을 고치는 행위와 현실을 고치는 행위를 나눠 비교한 것입니다. 논문 제목도 실제 오류가 남아 있을 때 기록 정리가 해로울 수 있다는 조건을 달고 있습니다. 논문 원문

다만 연구는 정확히 읽어야 합니다. 이 결과는 정답을 알려주지 말라는 뜻도, 실수한 대화를 모두 보존하라는 뜻도 아닙니다. 특정하게 마련한 조건에서 기록 편집의 효과를 비교한 연구입니다. 현실의 기업 서비스에서 이런 불일치가 얼마나 자주 일어나는지는 별도로 측정해야 합니다. 실험에서 발견한 실패 경로를 곧바로 산업 전체의 사고율로 바꿔 읽어서는 안 됩니다.

그 한계를 전제로 제 입장은 분명합니다. 업무를 수행하는 AI의 완료 선언에는 실제 변경을 확인할 근거가 붙어야 합니다. 문장이 자연스럽고 정답이 포함돼 있다는 이유만으로 일을 마쳤다고 인정하는 평가 방식은 부족합니다. 고객에게 필요한 것은 올바른 배송지를 말하는 상담원이 아니라, 그 주소로 물건이 가도록 주문을 처리하는 담당자입니다.

2. 기억을 고쳤는데 왜 복구가 어려워질까요

장보기 목록에 ‘우유를 사야 함’이라고 적힌 경우와 ‘우유 구입 완료’라고 적힌 경우를 생각해 보겠습니다. 두 문장 모두 우유를 언급하지만 다음 행동은 달라집니다. 전자는 매장으로 가게 하고, 후자는 목록에서 우유를 빼게 합니다. 냉장고에 우유가 실제로 있는지 확인하지 않는다면, 목록의 완료 표시가 행동을 결정할 수 있습니다.

에이전트의 기록도 단순한 참고 자료에 그치지 않습니다. 고객이 무엇을 요청했는지, 앞서 어떤 작업을 시도했는지, 프로그램이 어떤 결과를 돌려줬는지, 무엇이 남았는지를 판단하는 재료가 됩니다. 따라서 기록 속 문장을 바꾸면 정답을 전달하는 효과와 함께 남은 작업을 달리 보이게 하는 효과도 생길 수 있습니다. ‘정확한 값은 이것’과 ‘이 값으로 처리했음’은 서로 다른 지시를 품습니다.

여기서 세 가지를 나눠야 합니다. 첫째는 원하는 상태입니다. 고객이 요청한 배송지 302호가 여기에 해당합니다. 둘째는 관찰한 상태입니다. 주문 시스템을 확인했더니 301호가 저장돼 있었다는 사실입니다. 셋째는 수행한 행동입니다. 주소 변경을 요청했는지, 요청이 받아들여졌는지, 변경된 값까지 확인했는지를 뜻합니다. 요약이 짧아지는 과정에서 이 셋이 한 문장으로 합쳐지면 문제가 생깁니다.

이 구분을 놓치면 오류가 이어지는 경로는 다음처럼 설명할 수 있습니다. 아래는 실험 결과와 양립하는 업무상 설명이며, 모델 내부에서 오직 이 과정만 일어났다고 입증한 설명은 아닙니다.

1. 잘못된 값이 업무 시스템에 남습니다. 실제 상태가 바뀌지 않았으므로 누군가는 수정 작업을 해야 합니다.
2. 기록을 정리하면서 올바른 값을 이미 처리한 내용으로 적습니다. 다음 담당자는 정답과 함께 완료 주장도 전달받습니다.
3. 다음 담당자가 그 주장을 근거로 수정 작업을 건너뛸 수 있습니다. 정답을 몰라서가 아니라 남은 일로 보이지 않아서입니다.
4. 다른 업무를 진행한 뒤 종료하면 잘못된 값은 그대로 남습니다. 마지막 설명이 정확해 보여도 실제 처리 결과는 틀릴 수 있습니다.

다만 여기에는 경쟁하는 설명이 있습니다. 뒤에 붙인 주석은 눈에 잘 들어와서 도움이 됐을 수 있습니다. 사용자가 알려주는 형태의 문장을 모델이 더 중요하게 받아들였을 수도 있습니다. 오류를 지운 효과와 정답을 놓은 위치의 효과도 섞일 수 있습니다. 따라서 ‘AI는 완료라는 말을 보면 반드시 확인을 멈춘다’고 단정하면 실험이 보여준 범위를 넘습니다.

그렇다고 설계상의 결론까지 미룰 필요는 없습니다. 내부 원인이 하나로 정리되지 않았더라도, 실제 상태가 같은데 기록을 바꾸자 결과가 나빠지는 조건은 검사할 수 있습니다. 자동차 고장 원인을 모두 알아내기 전에도 브레이크가 듣지 않는 조건을 시험하듯, 서비스에서도 인계 기록과 실제 데이터가 어긋났을 때의 행동을 먼저 확인할 수 있습니다. 원인을 밝히는 연구와 사고를 줄이는 검사는 서로 돕지만 같은 일은 아닙니다.

특히 긴 대화를 압축할 때 이 문제가 중요합니다. 압축은 필요한 내용을 짧게 남기는 작업입니다. 그런데 올바른 값만 남기고 실패 여부를 지우면 문장 수는 줄어도 업무 정보는 훼손될 수 있습니다. 좋은 요약의 기준에는 간결함뿐 아니라, 다음 담당자가 아직 해야 할 일을 정확히 알아볼 수 있는지도 들어가야 합니다.

3. 오래된 장부의 원칙이 새로운 AI를 시험합니다

이 문제를 완전히 새로운 지능의 결함으로만 보면 해결의 실마리를 놓칩니다. 장부를 다루는 전산 시스템은 오래전부터 ‘처리했다고 알리는 일’과 ‘실제로 처리하는 일’을 맞추려 애써 왔습니다. 은행 송금에서 보내는 사람의 잔액만 줄고 받는 사람의 잔액은 늘지 않는다면, 화면에 성공이라고 표시해도 정상적인 송금이 아닙니다. 서로 연결된 변경을 어떻게 함께 확정할지가 핵심입니다.

데이터베이스, 즉 주문·고객·잔액 같은 정보를 구조에 맞춰 저장하고 관리하는 시스템에는 트랜잭션이라는 개념이 있습니다. 여러 변경을 한 묶음으로 처리해 전부 반영하거나 전부 취소하는 장치입니다. 널리 쓰이는 데이터베이스인 PostgreSQL의 공식 설명도 송금을 예로 들어 이 원칙을 풉니다. 완료를 알리는 시점과 변경 사항을 확실히 저장하는 절차가 연결돼야 한다는 설명입니다. PostgreSQL 공식 문서

이 오래된 원칙을 에이전트 업무와 비교하면 차이가 선명해집니다. 데이터베이스 내부에서는 정해진 명령과 처리 규칙으로 변경을 관리할 수 있습니다. 반면 에이전트는 상담 내용, 작업 계획, 프로그램의 응답, 다른 담당자의 요약처럼 성격이 다른 문장을 함께 읽습니다. 이때 사람이 알아보기 좋은 ‘완료했습니다’라는 표현이 실제 처리 근거를 대신하지 않도록 경계를 세워야 합니다.

물론 데이터베이스의 처리 원칙을 그대로 가져오면 모든 문제가 해결된다는 뜻은 아닙니다. 주문 시스템, 배송 회사, 문자 발송 업체가 함께 움직이는 업무에서는 각 시스템의 처리 시점이 다를 수 있습니다. 한곳에서 변경을 확정했다고 다른 곳의 작업까지 끝난 것은 아닙니다. 따라서 완료의 범위를 ‘주소 저장 완료’, ‘출고 정보 반영 완료’, ‘고객 통지 완료’처럼 나누는 편이 더 정확할 수 있습니다.

표의 오른쪽은 논문이 성능을 검증한 제품 규격이 아닙니다. 연구 결과를 바탕으로 제안하는 업무 기록 방식입니다. 실제로 도움이 되는지는 적용할 서비스에서 비교해야 합니다. 다만 왼쪽과 오른쪽이 담는 정보가 다르다는 점은 분명합니다. 정답 중심의 기록은 무엇이 맞는지 알려주지만, 상태를 구분한 기록은 그 정답을 실현하려면 무엇이 더 필요한지도 알려줍니다.

역사적 교훈은 ‘옛 기술을 붙이면 된다’는 단순한 처방이 아닙니다. 처리 결과를 보증하는 책임을 문장 하나에 맡기지 말아야 한다는 원칙입니다. 사람이 자연스럽게 읽는 설명과 기계가 확인할 수 있는 처리 근거는 함께 있어야 합니다. 상담 요약은 업무를 이해하도록 돕고, 실제 변경 기록은 완료 여부를 판단하도록 도와야 합니다.

이렇게 보면 AI 도입은 기존 전산 업무의 기본기를 생략할 기회가 아닙니다. 오히려 그 기본기가 드러나는 순간입니다. 어느 시스템의 어떤 값을 바꿨는지 추적할 수 없는 조직에서는 에이전트도 완료 여부를 확인하기 어렵습니다. 말솜씨 좋은 모델을 붙이기 전에 완료의 뜻부터 정리해야 하는 이유입니다.

4. 50%와 44% 사이에서 꼭 읽어야 할 조건

이제 숫자를 보겠습니다. AgentCE-Bench는 에이전트의 행동을 시험하는 평가 환경입니다. 연구진은 잘못된 값이 저장된 319개 상태를 대상으로 기록 편집을 비교했습니다. 여기서 복구율은 남은 평가 대상 중 작업을 이어간 뒤 올바른 값을 갖춘 비율입니다. 모든 업무를 처음부터 끝까지 성공한 비율과는 다릅니다. 복구율 50%를 고객 주문 절반이 실패했다는 뜻으로 옮기면 잘못된 해석입니다.

비교는 두 갈래입니다. 오류를 남겨둔 채 정답을 주석으로 덧붙인 조건에서는 복구율이 중립적인 주석을 붙인 조건의 51%에서 66%로 높아졌습니다. 같은 정답을 이미 실행한 행동처럼 기록한 조건에서는 원래 기록 조건의 50%에서 44%로 낮아졌습니다. 정답이 기록에 존재한다는 사실만으로는 결과의 방향을 설명할 수 없었던 것입니다. 논문 실험 설계와 결과

여기서 51%와 50%를 대충 같은 출발점으로 묶으면 안 됩니다. 하나는 중립적인 주석을 붙인 비교 조건이고, 다른 하나는 원래 기록을 둔 비교 조건입니다. 주석을 추가하는 형식 자체가 영향을 줄 수 있으므로 각 편집을 알맞은 기준과 비교해야 합니다. 기사를 읽을 때 숫자 옆에 ‘무엇과 비교했는가’를 함께 적어두면 이런 혼동을 줄일 수 있습니다.

표시된 정수 비율끼리 빼면 51%에서 66%는 15퍼센트포인트 상승이고, 50%에서 44%는 6퍼센트포인트 하락입니다. 퍼센트포인트는 두 비율을 직접 뺀 차이입니다. ‘6% 하락’과는 계산이 다릅니다. 또한 표시값은 반올림돼 있으므로 논문의 더 정밀한 추정치와 끝자리까지 같다고 요구해서도 안 됩니다. 숫자를 정확히 읽는 일은 소수점을 많이 쓰는 일이 아니라 비교의 뜻을 지키는 일입니다.

두 번째 평가 환경인 AppWorld에서는 실제 데이터 변경의 유무와 성공·실패 표시를 나눠 비교했습니다. 실제 변경이 없는데 성공이라고 표시하면 전체 작업 성공률은 실패 표시 조건의 45%에서 28%로 낮아졌습니다. 반대로 실제 변경이 존재할 때는 성공 표시 조건이 49%, 실패 표시 조건이 38%였습니다. 여기서는 복구율이 아니라 전체 작업 성공률을 측정했습니다.

이 표에서 끌어낼 핵심은 성공 메시지가 나쁘다는 결론이 아닙니다. 같은 성공 표시라도 실제 변경이 있는지에 따라 효과의 방향이 달라졌다는 점입니다. 따라서 안전을 이유로 모든 결과를 실패나 미확인으로 표시하는 방식도 답이 되기 어렵습니다. 실제로 끝난 작업을 계속 미완료로 취급하면 이미 처리한 일을 다시 시도하게 만들 수 있습니다.

가령 발송된 안내 문자를 실패로 기록하면 다음 담당자가 같은 문자를 또 보낼 수 있습니다. 이 역시 업무에 대입한 가상 사례이며 논문에서 그대로 관찰한 문자 발송 사례는 아닙니다. 요점은 낙관적인 기록과 비관적인 기록 중 어느 쪽을 고를지가 아닙니다. 완료된 범위와 확인되지 않은 범위를 정확히 구분하는 일이 중요합니다.

또한 두 평가 환경의 비율을 한데 합쳐 ‘AI 신뢰성 점수’를 만들어서는 안 됩니다. 복구율과 전체 작업 성공률은 묻는 질문이 다릅니다. 두 실험을 연결하는 것은 숫자의 크기보다 기록과 실제 상태의 관계입니다. 서로 다른 시험에서 비슷한 문제의식이 드러났다고 말할 수는 있어도, 어느 서비스에서 몇 퍼센트 손실이 날지는 이 표만으로 계산할 수 없습니다.

5. 한계부터 읽어야 처방도 정확해집니다

첫 번째 오해는 ‘실수를 지우면 나쁘니 대화를 모두 저장하자’입니다. 실수의 흔적이 필요한 경우가 있다는 주장과 모든 문장을 영구 보관해야 한다는 주장은 다릅니다. 업무상 필요한 것은 실패한 작업, 현재 확인된 값, 목표값, 아직 남은 조치를 구분하는 정보입니다. 같은 내용을 여러 번 반복한 대화까지 모두 다음 담당자에게 보여줘야 한다는 근거는 이번 결과에 없습니다.

두 번째 오해는 ‘정답을 주면 오히려 성능이 떨어진다’입니다. 정답을 주석으로 알려준 조건에서는 복구율이 높아졌습니다. 문제가 된 것은 정답을 이미 실행한 행동처럼 기록했을 때입니다. 교육에서 답을 알려주는 문제와 업무 장부에서 처리 여부를 바꾸는 문제를 섞어서는 안 됩니다. 정답의 내용과 그 정답이 어떤 상태로 제시됐는지를 함께 읽어야 합니다.

세 번째 오해는 ‘실패라고 표시하면 언제나 안전하다’입니다. 실제 변경이 있는 AppWorld 조건에서는 성공 표시 쪽이 유리했습니다. 안전한 시스템은 매번 의심만 하는 시스템이 아닙니다. 확인할 근거가 있으면 완료를 인정하고, 근거가 부족하면 판단을 유보하며, 서로 충돌하면 다시 확인하는 시스템입니다. 불확실함을 인정하는 일과 실패를 단정하는 일도 구분해야 합니다.

연구 자체의 한계도 무겁게 봐야 합니다. 정답 주석과 실행 기록은 내용의 진실성 외에 메시지 역할과 위치 등이 다릅니다. 따라서 성능 차이를 ‘진실한 기록의 힘’ 하나로 설명할 수 없습니다. AppWorld의 성공·실패 메시지도 내용이 같지 않습니다. 어느 요소가 얼마만큼 작용했는지 더 잘 분리하려면 후속 실험이 필요합니다. 논문의 한계 설명

더 중요한 경계는 실험과 실제 요약 기능 사이에 있습니다. 논문은 특정 기록을 바꾸거나 주석을 붙인 조건을 시험했습니다. 서비스가 긴 대화를 읽고 요약문을 만드는 전체 절차를 직접 검증한 것은 아닙니다. 따라서 ‘특정 요약 제품을 쓰면 복구율이 44%가 된다’는 주장은 성립하지 않습니다. 이번 결과는 그런 제품을 평가할 때 어떤 실패 조건을 넣어야 하는지 알려주는 근거로 읽는 편이 정확합니다.

재현되는가, 조건은 무엇인가. 이 질문은 여기서 시작합니다. 같은 기록을 다시 읽혀 비슷한 숫자가 나오는지뿐 아니라, 같은 잘못된 값이 실제로 저장돼 있는 상태에서 출발했는지도 확인해야 합니다. 한쪽에서는 오류가 남아 있고 다른 쪽에서는 이미 고쳐져 있다면 기록 편집만 비교한 실험이 아닙니다. 연구를 따라 하는 사람은 대화와 실행 환경을 함께 맞춰야 합니다.

실무에 옮길 때는 허용 시간과 작업 횟수도 맞춰야 합니다. 한 조건에만 충분한 재시도 기회를 주면 기록의 효과와 시간의 효과가 섞입니다. 반대로 수정할 시간이 지나치게 짧으면 확인 절차가 있는 설계가 불리해 보일 수 있습니다. 비용과 시간을 포함한 공정한 비교가 필요합니다. 재현은 같은 문장을 입력하는 일이 아니라 같은 출발 조건과 평가 규칙을 마련하는 일입니다.

이런 한계가 있으니 아무 결론도 내릴 수 없다는 태도도 적절하지 않습니다. 연구는 특정한 실패 가능성을 구체적으로 보여줍니다. 다만 그 가능성에서 시장 전체의 미래를 예언할 수는 없습니다. 기록과 실제 상태를 맞추는 절차가 중요하다는 설계 판단과, 어떤 기업이 경쟁에서 승리할 것이라는 전망은 증거의 무게가 다릅니다. 메커니즘과 예언을 구분해야 합니다.

6. 도입 평가에는 성공 화면보다 어긋난 인계를 넣어야 합니다

한국 기업이 주문 처리나 고객 관리에 에이전트를 붙인다면, 정상적인 시연만으로 평가를 끝내지 않는 편이 좋겠습니다. 고객이 요청하고 에이전트가 처리한 뒤 완료를 알리는 장면은 출발점입니다. 그다음에는 기록과 실제 데이터가 어긋난 상황을 일부러 마련해야 합니다. 이것은 논문이 특정 기업에 권고한 제품 사양이 아니라, 실험에서 출발한 도입 평가 제안입니다.

첫 시험은 주소 변경 요청이 실패했는데 인계 요약에는 완료라고 적힌 경우입니다. 다음 에이전트가 주문을 조회하는지, 요약만 믿고 종료하는지 확인합니다. 두 번째 시험은 실제 변경은 끝났는데 응답을 받지 못한 경우입니다. 이때 곧바로 다시 변경하기보다 현재 상태를 확인하는지 봅니다. 세 번째 시험은 저장한 주소와 배송에 사용되는 주소가 따로 있는 경우입니다. 완료의 범위를 어디까지 구분하는지가 드러납니다.

이 시험들은 모두 운영 중인 고객 데이터를 훼손할 필요 없이 별도의 시험 환경에서 구성할 수 있습니다. 중요한 것은 일부러 틀린 문장을 넣는 데 그치지 않고, 그 문장과 어긋나는 실제 상태를 함께 준비하는 일입니다. 그리고 평가는 마지막 답변보다 최종 저장값과 실제 수행 내역을 중심으로 해야 합니다. ‘고쳤습니다’라는 문장을 맞혔는지와 주소를 고쳤는지는 별개입니다.

도입 담당자가 추적할 신호는 다음처럼 정리할 수 있습니다.

• 잘못된 완료 선언 비율을 봅니다. 완료라고 알린 건을 실제 처리 결과와 대조해야 성공 화면 뒤에 숨은 오류를 찾을 수 있습니다.
• 인계 뒤 수정 누락을 봅니다. 첫 담당자가 남긴 미완료 작업을 다음 담당자가 찾아 처리했는지 확인해야 요약의 품질을 평가할 수 있습니다.
• 중복 실행을 함께 봅니다. 이미 끝난 일을 다시 수행한 횟수를 세야 지나친 재시도가 만든 손해까지 드러납니다.
• 확인에 든 시간과 비용을 봅니다. 오류 감소와 추가 조회 부담을 함께 비교해야 운영 가능한 검증 수준을 정할 수 있습니다.
• 완료 근거를 찾는 데 걸리는 시간을 봅니다. 주문 번호와 변경 내역을 쉽게 찾을 수 있어야 고객 문의나 장애 발생 때 사실관계를 복원할 수 있습니다.

확인 절차를 늘리면 느려지고 비싸진다는 반론은 맞습니다. 모든 메모 수정과 모든 잔액 변경을 똑같이 다룰 이유는 없습니다. 다시 고치기 쉬운 내부 문구와 고객에게 이미 발송되는 메시지는 실패의 비용이 다릅니다. 확인의 강도는 되돌릴 수 있는지, 외부에 어떤 영향을 주는지, 중복 실행이 어떤 손해를 만드는지에 따라 정하는 편이 합리적입니다.

그렇다고 영향이 작은 업무에서 확인을 전부 없애라는 뜻은 아닙니다. 가벼운 작업은 일부를 뽑아 사후 점검하고, 중요한 변경은 완료 전에 결과를 확인하는 식으로 나눌 수 있습니다. 어느 비율로 점검할지는 이번 논문이 알려주지 않습니다. 실제 오류 빈도와 점검 비용을 측정해 정해야 합니다. 근거 없는 정밀한 권고보다, 무엇을 측정해서 결정할지 밝히는 편이 정직합니다.

확인 자체에도 함정이 있습니다. 어제 조회한 주소로 오늘의 완료를 보증할 수는 없습니다. 조회 뒤 다른 담당자가 값을 바꿀 수도 있습니다. 따라서 무엇을 확인했는지뿐 아니라 언제, 어느 주문에서, 어떤 변경을 대상으로 확인했는지가 필요합니다. ‘확인됨’이라는 단어 하나를 추가하는 것으로 같은 문제가 해결되지는 않습니다.

7. 데이터 주권은 완료를 검증할 권한까지 포함해야 합니다

여기서 데이터 주권이라는 말도 더 구체적으로 볼 필요가 있습니다. 데이터 주권은 조직이나 개인이 자기 데이터의 이용과 관리를 통제할 수 있는 능력을 뜻합니다. 저장 장소와 접근 권한은 중요한 문제입니다. 저는 여기에 업무 결과를 독립적으로 확인할 능력도 포함해야 한다고 봅니다. 자료가 자기 서버에 있어도 에이전트가 무엇을 바꿨는지 알 수 없다면 실질적인 통제에는 빈틈이 남습니다.

외부 서비스가 ‘수정 완료’라는 요약만 돌려주고, 어떤 주문의 어떤 값이 바뀌었는지 확인할 수 없다고 가정해 보겠습니다. 고객이 잘못 배송됐다고 항의하면 기업은 서비스의 설명을 다시 물어야 합니다. 반대로 변경 대상, 처리 결과, 확인 시점이 업무 시스템에서 조회된다면 담당자는 원인을 직접 조사할 수 있습니다. 이 차이는 모델의 문장 능력보다 운영상의 통제권에 가깝습니다.

따라서 구매 과정에서도 질문을 바꿀 필요가 있습니다. ‘얼마나 긴 대화를 기억합니까’와 함께 ‘완료 판단의 근거를 어디서 확인합니까’를 물어야 합니다. ‘요약이 얼마나 짧습니까’와 함께 ‘미완료와 확인 불가를 어떻게 남깁니까’를 물어야 합니다. ‘모델을 바꿀 수 있습니까’와 함께 ‘다음 모델이 실제 상태와 남은 일을 이어받을 수 있습니까’를 물어야 합니다.

이는 제품 경쟁이 반드시 어느 방향으로 움직일 것이라는 예언은 아닙니다. 구매자가 지금 평가 기준에 넣을 수 있는 요구입니다. 모델의 답변 능력이 좋아져도 작업의 경계와 확인 권한이 불분명하면 오류를 찾기 어렵습니다. 반대로 확인 가능한 기록을 갖추면 모델이나 공급자를 교체할 때도 무엇이 끝났고 무엇이 남았는지 판단할 기반이 생깁니다.

기록을 더 남기자는 제안은 개인정보를 더 쌓자는 제안과도 구분해야 합니다. 다음 담당자에게 필요한 것이 주문 번호와 변경 상태라면 고객의 사적인 대화 전체를 인계할 이유는 없습니다. 민감한 원문은 접근을 제한하고, 업무 수행에 필요한 최소한의 상태와 확인 경로를 남기는 방식을 설계할 수 있습니다. 보관 기간과 접근 범위 역시 업무 목적에 맞춰 정해야 합니다.

결국 좋은 기억은 긴 기억도, 흠잡을 데 없이 매끈한 기억도 아닙니다. 현재 상태를 틀리게 설명하지 않고 다음 행동을 돕는 기억입니다. 잘못된 값을 정답으로 바꾸는 일과, 잘못된 작업을 고치는 일 사이에는 실행이라는 단계가 놓여 있습니다. 그 단계를 문장에서 생략했다고 현실에서도 사라지는 것은 아닙니다.

독자가 던질 법한 질문 세 가지를 남깁니다.

Q. 그러면 AI에게 실수를 고쳐 쓰라고 요청하면 안 됩니까?

A. 요청해도 됩니다. 다만 답변의 오류를 고치는 일인지, 실제 주문이나 파일을 수정하는 일인지 구분해야 합니다. 실제 작업이 필요하다면 올바른 값과 아직 남은 수정을 함께 명시하고, 처리 결과를 확인하도록 설계해야 합니다. 이번 연구는 정답 제공을 금지할 근거가 아닙니다.

Q. 모든 작업 뒤에 다시 조회하면 해결되지 않습니까?

A. 일부 문제를 줄일 수 있지만 만능은 아닙니다. 조회 비용이 들고, 조회한 시스템이나 시점이 적절하지 않을 수도 있습니다. 이미 보낸 메시지처럼 조회로 되돌릴 수 없는 작업도 있습니다. 무엇을 완료로 인정할지 먼저 정하고, 업무의 영향에 맞는 확인과 중복 방지 절차를 붙여야 합니다.

Q. 이번 논문만으로 특정 모델이나 제품을 골라도 됩니까?

A. 어렵습니다. 이 연구는 특정 조건에서 기록과 실제 상태가 어긋날 때 생기는 문제를 보여줍니다. 실제 서비스의 불일치 빈도나 제품별 전체 성능을 대신 측정하지는 않습니다. 후보 제품에 같은 업무와 같은 오류 조건을 주고, 최종 결과와 시간·비용을 함께 비교하는 출발점으로 삼는 것이 적절합니다.

완료라는 말은 설명입니다. 완료를 확인할 근거가 있어야 비로소 업무의 결과가 됩니다. 에이전트의 기억을 다듬는 기술은 유용하지만, 그 기억이 가리키는 장부를 확인할 권한과 절차가 뒤따라야 합니다.

정답을 적은 메모는 일을 대신하지 못합니다. 완료의 근거는 문장 밖에 있습니다.