AI에게 일을 맡겼다면, 무엇을 보고 끝났다고 할 것인가

보내지 않은 메일도 끝난 일이다

가상의 상황을 하나 생각해 보자. 실제로 메일을 작성하거나 저장하거나 보낸 기록은 아니다. 고객 문의에 답할 AI에게 이렇게 부탁했다고 가정한다. “답장을 작성해서 내 Gmail 계정의 임시보관함에 저장해 줘. Gmail에 초안을 저장하는 것은 허용하지만, 발송하지는 마.” 답장의 내용과 수신인 정보는 요구에 맞고, 지정한 계정과 저장 위치도 정확하다고 하자. 지금 따질 것은 문장의 품질이 아니라 어디까지 해야 일이 끝나는가다.

이 부탁의 결과로 미발송 초안이 저장되어 있다면 일은 끝났다. 보내지 않았다는 사실은 미완성의 흔적이 아니다. 오히려 요청을 지켰다는 판단에 꼭 필요한 부분이다. 반대로 같은 답장을 “지정한 수신인에게 발송해 줘”라고 부탁했다면, 임시보관함에 놓인 초안만으로는 끝났다고 할 수 없다. 똑같은 결과물도 어느 부탁에 대한 답인지에 따라 완료 여부가 달라진다.

여기서 저장 허용을 굳이 명시한 데는 이유가 있다. “초안만 써 줘”라는 말이 외부 메일 서비스에 내용을 올려도 된다는 뜻까지 저절로 포함하지는 않기 때문이다. Gmail의 초안 생성은 계정에 자원을 만드는 작업이다. Google 문서에서도 미발송 초안과 발송 후 생성되는 보낸 메시지를 구별한다.¹ 따라서 이 예에서는 저장할 권한과 보내지 말아야 할 경계를 따로 정했다. 실제 사용에서는 사용자가 이미 정해 둔 유효한 권한도 함께 살펴야 한다.

완료를 작업의 가장 먼 지점으로 생각하면 이 구별을 놓친다. 초안보다 발송이 더 많은 일을 한 것처럼 보이지만, 첫 번째 부탁에서는 더 한 일이 잘못한 일이 된다. 그렇다고 아무것도 하지 않는 것이 신중함도 아니다. 저장까지 허용하고 요구했는데 문장만 대화창에 남겼다면 그 역시 부족하다. 우리에게 필요한 것은 최대한 많이 움직이는 AI도, 매번 허락을 다시 묻는 AI도 아니다. 맡긴 범위 안에서 결과를 만들고 그 경계에서 멈추는 AI다.

같은 화면, 다른 요청

JustDori의 글 「보고서 한 장으로 읽는 아스트라 시대」는 이미 실행 증거와 권한의 경계, 검증을 강조한다.² 이 글의 출발점도 거기에 있다. 다만 증거를 요구하자는 주장 다음에는 질문이 하나 더 남는다. 무엇의 증거인가. 작업을 시도했다는 증거와 요청한 결과가 생겼다는 증거는 다르다. 결과가 생겼다는 사실만으로 지켜야 할 조건까지 모두 지켰다고 말할 수도 없다.

예를 들어 도구가 표시한 ‘완료’를 보았다고 하자. 그 글자의 뜻은 해당 도구의 약속을 읽어야 알 수 있다. OpenAI의 컴퓨터 사용 문서에서 특정 컴퓨터 호출의 완료 상태는 호출 생성이 끝났다는 의미이며, 실제 동작 실행과 결과 확인은 그 뒤에 필요하다.³ 이것을 모든 제품의 완료 표시가 믿을 수 없다는 말로 넓힐 이유는 없다. 어떤 완료 표시는 작업 지시의 생성을, 다른 표시는 실행이나 검사의 통과를 가리킬 수 있다. 이름보다 그 표시가 보증하는 범위를 읽는 편이 정확하다.

실행 결과를 검사하는 테스트는 더 강한 근거가 된다. 원래의 tau-bench 논문은 작업 후 데이터베이스 상태와 응답에 포함되어야 할 정보를 평가한다. 단순히 답변이 그럴듯한지를 보는 검사가 아니다. 그러면서 논문은 필요한 확인 절차를 생략했더라도 보상을 받을 수 있는 평가의 한계를 밝힌다.⁴ 이 두 사실은 함께 읽어야 한다. 검사가 쓸모없다는 뜻이 아니라, 유용한 검사가 모든 요구를 덮지는 않는다는 뜻이다.

가상의 답장으로 돌아오면 그 차이가 선명해진다. 내용 검사에서는 고객의 질문에 답했는지 볼 수 있고, 저장 상태 확인에서는 초안이 지정한 곳에 있는지 볼 수 있다. 발송 금지까지 요청했다면 그 경계에 관한 확인도 필요하다. 한 검사에 나머지 검사의 몫까지 기대해서는 안 된다. 반대로 요구한 결과와 조건을 이미 적절한 검사가 확인했다면, 다른 순서로 작업했다는 이유만으로 실패라고 부를 필요도 없다. 사용자가 특정 절차까지 요구한 경우와 결과만 요구한 경우를 구분해야 한다.

그래서 완료 보고의 문장은 짧아도 구체적이어야 한다. 이 예에서는 “처리했습니다”보다 “Gmail 임시보관함에 초안을 저장했고, 발송하지 않았습니다”가 낫다. 물론 문장 자체가 증거는 아니다. 확인된 상태를 정확히 요약할 때 비로소 보고가 된다. 보고가 가리키는 결과와 실제로 확인한 범위가 맞아야, 일을 맡긴 사람도 처음부터 전부 다시 읽지 않고 무엇이 끝났는지 판단할 수 있다.

매끄러운 답장은 충분한가

이런 구별을 강조한다고 AI가 실무에 도움이 되지 않는다는 결론이 나오지는 않는다. 고객지원 업무를 다룬 QJE 연구는 전체 5,172명의 상담원 표본에서 AI 지원 도입에 따른 시간당 해결 건수 증가를 약 15%로 추정했다. 상담원은 제안을 수정하거나 무시할 수 있었다. 시차를 두고 이루어진 도입을 분석한 현장 연구이지, 그 인원 모두를 무작위로 나누어 자율 에이전트에 일을 맡긴 실험은 아니다.⁵ 그 범위 안에서는 실제로 해결한 업무가 늘었다는 긍정적인 결과다.

동시에 산출물의 유려함과 정확성이 늘 함께 좋아지는 것은 아니다. BCG 컨설턴트들을 대상으로 한 실험에서는 AI 지원을 받은 집단이 제품 관련 과제에서 더 높은 품질의 결과를 냈다. 그러나 별도로 선정한 분석 과제에서는 지원 집단의 정답 비율이 비지원 집단보다 약 19퍼센트포인트 낮았다. 작업은 더 빨랐고 설명의 설득력에 대한 평가도 더 좋았는데, 정확성은 떨어졌다.⁶ 앞의 이익을 지워서도, 뒤의 손실을 문장이 좋았다는 말로 덮어서도 안 된다.

두 과제에는 서로 겹치지 않는 참가자 집단이 참여했다. 따라서 같은 사람들이 쉬운 일에서 AI를 믿게 된 뒤 어려운 일에서 속았다는 이야기로 엮을 수 없다. 분석 과제에서도 지원 집단 답변의 대다수는 정답이었다. 이 실험은 2023년의 GPT-4와 특정 과제를 다룬 결과다. 오늘 쓰는 모델의 실패율도 아니고, 모든 지식 업무가 같은 비율로 나빠진다는 예측도 아니다. 여기서 가져올 만한 교훈은 더 좁다. 읽기 좋은 설명이라는 관찰만으로 그 설명이 옳다는 판단을 대신하지 말자는 것이다.

처음의 가정에서는 이미 답장 내용이 요구를 충족한다고 정했다. 그 조건을 풀어 실제 업무를 설계한다면, 문장을 다듬는 일과 고객에게 약속해도 되는 내용을 확인하는 일을 구별할 수 있다. 가령 정중한 환불 안내라도 적용할 정책이 틀렸다면 좋은 답장이 아니다. 이때 필요한 것은 막연히 더 오래 읽는 일이 아니라, 해당 고객에게 적용되는 정책과 안내 내용이 맞는지 보는 일이다. 어조를 평가하는 검토로 정책 확인을 대신할 수 없듯, 정책이 맞는다고 발송 금지까지 지켰다고 할 수도 없다.

두 연구를 하나의 생산성 숫자로 합치는 것도 피해야 한다. 고객지원의 시간당 해결 건수, 제품 과제의 품질, 분석 문제의 정답 비율은 서로 다른 것을 잰다. 어느 곳에서 이익을 얻었고 어디에서 정확성을 놓쳤는지를 남겨 두어야 다음 업무를 설계할 수 있다. AI를 쓸 것인가 말 것인가보다, 이 답장 작업이 끝났다고 받아들이려면 어떤 결과를 확인해야 하는가가 이 글의 질문이다.

사람이 읽었다는 말 다음에

여기까지 읽으면 마지막에 사람이 검토하면 되지 않느냐는 답이 자연스럽다. 필요한 경우라면 맞는 선택이다. 다만 검토자를 한 명 더 두었다는 사실과 검토가 효과를 냈다는 사실은 같지 않다. “사람이 읽었다”는 말 뒤에도 무엇을 보고 어떤 판단을 했는지가 남는다. 문체만 읽은 사람이 발송 권한까지 확인한 것은 아니다.

인간과 AI의 조합을 다룬 Nature Human Behaviour의 메타분석은 이 기대를 조심스럽게 다룰 근거를 준다. 통합된 결과에서 인간과 AI의 조합은 인간 단독보다 잘했지만, 인간 단독과 AI 단독 중 더 잘한 쪽과 비교하면 못했다.⁷ 두 비교를 함께 말해야 한다. 인간 단독과의 비교만 남기면 협업이 언제나 최선인 것처럼 보이고, 더 나은 단독 수행과의 비교만 남기면 협업의 이익 자체가 없었던 것처럼 보인다.

대상 연구들은 시기와 과제, 협업 방식이 다양하고 결과 차이도 컸다. 이 분석은 마지막 검토자가 성능 저하를 일으켰다는 인과관계를 입증하지 않는다. 성능이 더 좋은 단독 수행이 실제 현장에서 권한과 책임을 갖고 배치될 수 있다는 허가증도 아니다. 사람을 빼자는 결론보다, 사람이 있다는 사실만으로 성능을 보증하지 말자는 해석이 이 글의 범위에 맞는다.

가상의 답장을 검토할 사람이 있다면, 그 사람에게 필요한 자료도 판단할 내용에 따라 달라져야 한다. 고객에게 예외를 허용해도 되는지 판단해야 한다면 원래 요청과 적용 정책이 중요하다. 저장만 했는지 확인하려면 매끄러운 본문보다 메일의 현재 상태가 중요하다. 실제로 남은 문제가 문장 하나뿐이라면 그 부분만 보면 된다. 사람의 몫을 무조건 최종 승인으로 고정하기보다, 해결되지 않은 판단이 어디 있는지 먼저 정하자는 제안이다.

이미 발송을 허용했고 필요한 조건도 충족한 업무에 새 승인 단계를 끼워 넣을 이유는 없다. 반대로 발송하지 말라고 했는데 검토자가 문장에 동의했다고 해서 발송 권한이 생기는 것도 아니다. 내용에 대한 동의와 행동을 허용하는 결정은 별개다. 이 구별을 지키면 사람에게 모든 일을 다시 하라고 떠넘기지 않으면서도, 실제로 사람의 판단이 필요한 지점을 남길 수 있다.

매번 다시 확인하면 맡긴 의미가 있을까

하지만 요구와 권한, 검사 범위를 매번 처음부터 재구성해야 한다면 위임의 이점이 작아질 수 있다. 이 반론은 타당하다. 답은 모든 작업에 긴 심사 문서를 붙이는 데 있지 않다. 이미 있는 요청과 결과, 검사 기록을 다시 찾기 쉽게 이어 두고, 그 사이에 빠진 판단만 짧게 남기는 편을 권한다. 여기서 제안하는 기록은 생산성이나 안전 효과가 실험으로 입증된 처방이 아니라, 완료 판단을 불필요하게 다시 만들지 않기 위한 집필자의 제안이다.

기록이 필요한 경우라면 작업 일지를 통째로 복사하기보다 결정의 이유와 현재 효력을 남기는 쪽이 낫다. Nygard의 아키텍처 결정 기록은 대체된 결정도 상태를 표시해 보존한다. MADR 양식에는 결정을 어떻게 확인할지 적는 선택 항목도 있다.⁸⁹ 이 관행에서 빌려올 것은 문서의 격식보다 구별이다. 과거에 무엇을 정했는지, 지금도 유효한지, 확인할 계획인지 이미 확인했는지를 섞지 않는 것이다. 확인 방법을 써 두었다고 검사가 실행된 것은 아니다.

답장 예에 적용한다면 기록은 몇 문장으로 충분할 수 있다. 이번 요청은 Gmail 초안 저장까지이며 발송은 제외된다는 점, 요청한 위치의 초안을 어떤 근거로 확인했는지, 내용 검토에서 아직 남은 문제가 있는지를 실제 관찰에 맞춰 적는 것이다. 기존 작업 화면에 이 정보가 충분히 드러나 있다면 별도 문서는 필요 없다. 기록을 더 만드는 대신 그 화면과 확인 결과를 가리키면 된다.

이 구별은 AI가 과거 작업을 기억한다고 가정해도 필요하다. “이 사용자는 보통 답장을 바로 보낸다”는 선호의 기억은 이번 발송 금지 요청을 지우지 못한다. 그렇다고 매번 마지막 메시지에 허용 문구가 없다는 이유로 이전의 유효한 권한까지 폐기할 필요도 없다. 과거의 습관, 아직 유효한 허용, 이번에 정한 예외가 서로 다른 종류의 정보라는 점을 남겨야 한다. 오래된 기록이라서 틀린 것도, 저장된 기록이라서 현재의 명령인 것도 아니다.

근거를 붙일 때는 그 근거가 어디서 왔는지도 짧게 남길 가치가 있다. 가령 여러 AI가 답장의 정책 근거를 조사했는데 세 요약이 모두 같은 자료 하나를 옮겼다면, 일치한 요약 셋이 독립된 관찰 셋을 만들지는 않는다. Cochrane도 하나의 연구를 다룬 여러 보고와 서로 다른 연구를 구별하며, 부차적인 보고의 유용성까지 버리지는 않는다.¹⁰ 각자 원문을 읽는 일은 인용 오류를 찾는 데 도움이 될 수 있다. 다만 같은 원문을 정확히 읽었다는 확인과 원문의 결론을 별도 자료로 뒷받침했다는 확인은 다르다.

어디까지 확인하고 멈출 것인가

짧은 기록이라도 그것을 만들고 읽고 갱신하는 일은 남는다. 매번 확인 자료를 새로 꾸미고 이미 끝난 검사를 다시 수행한다면, 우리는 업무 대신 업무를 설명하는 일을 늘릴 수 있다. 검증을 강조하는 글이라면 이 비용을 사소한 불편으로 치부해서는 안 된다. 더 긴 절차를 붙였다는 사실만으로 더 나은 결과를 얻었다고 말할 수는 없다.

Anthropic의 에이전트 설계 지침도 가능한 한 단순한 해법에서 시작하고, 복잡성이 성능과 함께 지연 시간 및 비용을 바꾼다는 점을 고려하라고 권한다.¹¹ 이것은 특정 절차의 수익률을 측정한 결론이 아니라 실무 지침이다. 이 글의 권고도 그 정도에 머문다. 기존 검사와 직접 확인할 수 있는 결과를 먼저 쓰고, 실제로 비어 있는 요구나 권한의 경계가 있을 때만 확인을 더하자.

가상의 초안을 확인하는 데 모든 도구 호출을 사람이 처음부터 재생할 필요는 없다. 요청한 내용과 수신인이 맞고, 허용한 위치에 저장되었으며, 발송하지 않았다는 조건을 기존 증거가 충분히 보여 준다면 그것으로 끝낼 수 있다. 다만 초안이 있다는 화면만으로 발송하지 않았다는 사실까지 언제나 확정할 수 있다고 미리 정해 두어서는 안 된다. 증거가 어떤 상태를 확인하는지 보고 부족한 부분만 보완해야 한다. 확인의 양을 줄이는 것과 확인하지 않은 일을 확인했다고 말하는 것은 다르다.

발송 요청이라면 확인할 상태도 달라진다. 보낸 상태는 의미 있는 발송 근거지만 고객이 읽었다거나 문제가 해결되었다는 근거는 아니다.¹² 사용자가 요구한 끝이 발송이라면 고객의 회신을 기다리며 작업을 계속 붙들 이유가 없다. 반대로 문제 해결까지 맡긴 경우라면 발송만으로 완료 범위를 넓혀 보고해서는 안 된다. 더 큰 목적을 짐작할 수 있다는 사실이 이번에 맡은 일의 범위를 저절로 바꾸지는 않는다.

비용을 비교하고 싶다면 생성 시간만이 아니라 확인과 수정, 운영 중 유지에 드는 시간도 함께 보아야 할 것이다. 그렇지만 이 글의 자료로 그 합계나 절감률을 계산할 수는 없다. 모든 업무에 통하는 적정 검토 횟수도 제시하지 않는다. 대신 확인을 더할 때마다 어떤 미확인 요구를 새로 덮는지 설명할 수 있어야 한다. 이미 충분한 근거가 있는데도 불안하다는 이유만으로 같은 검사를 반복한다면, 추가 확인의 목적부터 다시 물을 때다.

초안은 저장했고, 보내지는 않았다

처음의 가상 장면으로 돌아가자. 부탁은 답장을 작성해 Gmail 임시보관함에 저장하되 발송하지 않는 것이었다. 내용과 수신인은 요구에 맞는다는 가정도 그대로다. 이제 지정한 위치에 초안이 저장되어 있고 발송하지 않았다는 점까지 충분히 확인된 상태를 가정하자. 이 경우 결과 보고는 “초안을 저장했고, 보내지는 않았습니다”면 된다. 발송 버튼을 누를 것도, 이미 허용받은 저장을 뒤늦게 다시 승인받을 것도 없다.

다른 부탁이었다면 결론도 바뀐다. 발송까지 요청하고 허용했다면 같은 미발송 초안은 아직 남은 일이 있다는 증거다. 초안의 문장이 아무리 훌륭해도, 검토자가 읽었다고 해도, 생성 도구가 완료를 표시했다고 해도 그 간격은 사라지지 않는다. 완료는 결과물에 붙어 있는 고정된 성질이 아니라, 그 결과가 맡긴 요청을 충족한다는 판단이다.

이 판단을 위해 언제나 새로운 문서나 사람에게 넘기는 절차가 필요한 것은 아니다. 필요한 것은 요청한 결과, 허용한 행동의 범위, 실제 확인한 사실이 서로 맞는 상태다. 부족하면 그 부분을 채우고, 충분하면 멈춘다. 검증은 일을 끝없이 연장하려고 하는 것이 아니라 끝났다고 말할 근거를 얻으려고 하는 일이다.

이 가정의 답장은 고객에게 도착하지 않았다. 그래도 맡긴 일은 끝났다. 저장하라고 한 곳에 저장했고, 보내지 말라고 한 메일을 보내지 않았기 때문이다.

출처와 집필 참고

아래 실증 결과는 각각 명시한 연구에 한정해 인용했다. 같은 연구를 소개하는 여러 글이나 같은 원문을 읽은 여러 검토를 독립된 재현으로 세지 않았다. 제품 문서는 해당 기능의 계약을 설명하는 근거이지 실제 시스템의 준수율을 측정한 자료가 아니다. 본문의 답장 장면은 전부 가정이며, 짧은 완료 기록과 비례적인 확인 절차는 이 글의 제안이다.