AI에게 반품 방법을 묻습니다. AI는 필요한 서류와 신청 절차를 설명합니다. 사용자는 그 안내를 읽고 직접 접수합니다.
이번에는 AI가 이렇게 답한다고 가정해 보겠습니다.
“주문을 확인했습니다. 반품 접수도 완료했습니다.”
편리해 보입니다. 설명을 읽고 화면을 찾아다니던 과정이 줄어들었습니다. 그런데 이 짧은 답변 뒤에서는 무엇이 일어났을까요.
어떤 주문을 조회했는지, 반품 조건을 어떻게 확인했는지, 실제 접수가 만들어졌는지 살펴봐야 합니다. 잘못된 주문을 처리했다면 문장을 고치는 것만으로 끝나지 않습니다. 외부 시스템에서 일어난 변경까지 바로잡아야 합니다.
앞선 글에서는 회사 문서를 찾아 답하는 AI를 살펴봤습니다. 이번에는 자료를 읽는 데서 더 나아가, 도구를 사용해 일을 수행하는 AI를 이야기해 보겠습니다.
에이전트라는 말은 여러 방식으로 쓰입니다. 여기서는 모델이 도구를 활용하며 작업의 다음 단계를 선택하는 시스템을 뜻하는 것으로 사용하겠습니다.
사용자의 요청을 받은 뒤 필요한 정보를 찾고, 결과를 살펴보고, 추가 질문을 하거나 다른 도구를 사용하는 흐름입니다. 미리 정해진 순서대로 실행하는 방식보다 상황에 따른 선택의 여지가 있습니다.
가상의 반품 업무를 생각해 보겠습니다. 사용자가 주문번호를 알려주면 주문을 조회합니다. 상품 상태가 불분명하면 추가로 질문합니다. 반품 가능 여부를 확인한 뒤 접수를 만들고 결과를 안내할 수 있습니다.
이 흐름에서 모델은 사용자의 말을 해석하거나 다음에 필요한 정보를 판단하는 역할을 맡을 수 있습니다. 실제 주문 조회와 접수 생성은 연결된 도구나 서비스가 수행합니다.
따라서 에이전트를 이해하려면 모델의 답변과 도구의 실행을 함께 살펴봐야 합니다.
새로운 기술을 도입하면 가능한 많은 일을 맡겨 보고 싶어 집니다. 하지만 작업의 어느 부분에 선택이 필요한 지부터 나누어 보는 편이 좋습니다.
주문번호 형식이 맞는지 확인하는 일, 해당 주문이 현재 사용자의 것인지 검사하는 일, 필수 입력이 모두 있는지 확인하는 일은 명확한 규칙으로 처리할 수 있습니다.
반면 사용자가 길게 설명한 불편 사항에서 핵심을 파악하거나, 부족한 정보를 자연스럽게 질문하는 일에는 모델을 활용할 여지가 있습니다.
반품 규정이 명확하다면 적용할 조건을 시스템에서 확인할 수 있습니다. 예외 판단이 필요한 경우에는 담당자에게 넘기는 절차를 둘 수도 있습니다.
이처럼 작업을 나누면 어디에서 모델의 판단이 도움이 되고, 어디에서는 정해진 검증이 필요한지 드러납니다.
에이전트라는 이름을 붙였다는 이유로 모든 단계를 자율적으로 처리할 필요는 없습니다. 작업에 필요한 만큼의 선택권을 주는 것부터 시작할 수 있습니다.
모델이 주문 조회 도구를 사용하겠다고 결정했습니다. 주문번호도 함께 전달했습니다.
이제 바로 조회해도 될까요.
실행을 맡는 서비스에서는 확인할 것이 남아 있습니다. 허용된 도구인지, 입력 형식이 맞는지, 현재 사용자가 해당 주문을 볼 수 있는지 검사해야 합니다.
모델이 정확한 도구 이름을 골랐다는 것은 그 행동을 할 권한이 있다는 뜻이 아닙니다.
사용자가 다른 사람의 주문번호를 입력했을 수도 있습니다. 외부 문서에 잘못된 정보가 들어 있을 수도 있습니다. 모델이 도구 인자를 만드는 과정에서 값을 잘못 넣었을 수도 있습니다.
그래서 권한은 실제로 인증된 사용자의 신원을 기준으로 실행 계층에서 확인해야 합니다. 모델이 만들어 낸 사용자 ID를 그대로 신뢰해서는 안 됩니다.
이 경계가 분명하면 모델의 판단이 잘못되었을 때도 실행 전에 막을 수 있습니다.
사람에게 일을 맡길 때는 무엇을 하면 되는지 설명합니다. 도구를 연결할 때도 비슷한 명세가 필요합니다.
어떤 입력을 받는지, 어떤 결과를 반환하는지, 데이터를 변경하는지, 실패하면 어떤 오류가 나오는지 정해야 합니다.
예를 들어 주문 조회 도구는 주문번호를 받아 현재 상태와 확인 시각을 반환할 수 있습니다. 주문이 없거나 권한이 없을 때는 그 상태를 구분해서 알려줄 수 있습니다. 다만 권한이 없는 사용자에게 민감한 정보가 드러나지 않도록 오류 메시지도 설계해야 합니다.
이런 구분이 없으면 모델이 ‘조회 실패’를 ‘주문 없음’으로 해석할 수 있습니다. 일시적인 시스템 문제인데 사용자에게 존재하지 않는 주문이라고 안내할 수도 있습니다.
도구의 결과는 성공했을 때뿐 아니라 실패했을 때도 해석 가능해야 합니다.
반품 접수 생성 도구를 호출했는데 응답이 오지 않습니다. 잠시 뒤 시간 초과 오류가 나타납니다.
다시 시도하면 될 것 같습니다. 하지만 외부 시스템에서는 이미 접수가 만들어졌을 수 있습니다. 접수는 완료되었는데 응답을 전달하는 과정에서 문제가 생긴 것일 수도 있습니다.
응답을 받지 못한 것과 작업이 실행되지 않은 것은 다릅니다.
같은 요청을 무조건 다시 보내면 반품 접수가 두 번 생성될 수 있습니다. 발송이나 결제처럼 외부에 영향을 주는 작업이라면 중복 실행의 결과가 더 커질 수 있습니다.
이때는 작업을 식별할 수 있는 ID를 사용해 기존 실행 상태를 확인하는 방식이 필요합니다. 같은 작업이 이미 처리되었다면 다시 만들지 않도록 해야 합니다.
재시도 규칙도 작업의 성격에 따라 달라집니다. 읽기 요청을 다시 보내는 것과 데이터를 변경하는 요청을 다시 보내는 것은 같은 판단으로 다루기 어렵습니다.
에이전트가 오류를 만났을 때 계속 시도하는 능력만큼, 무엇을 확인한 뒤 다시 시도할지 정하는 일이 중요합니다.
사용자는 원하는 결과를 얻고 싶습니다. 그래서 “완료될 때까지 진행해 줘”라고 말할 수 있습니다.
시스템에는 이 바람을 구체적인 실행 조건으로 바꾸는 과정이 필요합니다. 최대 몇 단계까지 수행할지, 얼마 동안 기다릴지, 같은 오류가 반복되면 언제 멈출지 정해야 합니다. 비용이 정해진 범위를 넘거나 사용자가 취소했을 때의 행동도 필요합니다.
멈추는 조건이 없으면 같은 자료를 반복해서 찾거나, 실패하는 도구를 계속 호출하는 상황이 생길 수 있습니다.
종료할 때는 상태도 구분해야 합니다. 모든 작업을 마쳤는지, 일부만 완료했는지, 아무것도 실행하지 못했는지 알려야 합니다.
가령 반품 가능 여부는 확인했지만 접수 생성에 실패했다면 다음처럼 설명할 수 있습니다.
반품 조건은 확인했습니다. 접수 생성 결과는 아직 확인되지 않았습니다. 중복 접수를 피하기 위해 기존 처리 상태를 먼저 확인해야 합니다.
이 답변은 단순한 실패 메시지보다 다음 행동을 판단하는 데 도움이 됩니다. 완료된 부분과 남은 부분이 드러나기 때문입니다.
실행의 영향에 따라 사람의 확인이 필요한 지점을 둘 수 있습니다.
메일을 보내는 작업이라면 수신자와 내용, 첨부파일을 보여줄 수 있습니다. 주문을 변경하는 작업이라면 대상 주문과 바뀌는 항목을 확인하게 할 수 있습니다.
“진행할까요?”라는 질문만으로는 사용자가 무엇을 승인하는지 알기 어려울 때가 있습니다. 실행할 대상과 결과를 구체적으로 보여줘야 합니다.
확인 이후 내용이 달라졌다면 기존 승인이 여전히 유효한지도 살펴야 합니다. 초안을 확인했는데 발송 직전 다른 파일이 첨부되었다면 같은 행동을 승인했다고 보기 어렵습니다.
어떤 작업에 사람의 확인을 둘진 업무의 영향과 조직의 기준에 따라 정할 수 있습니다. 중요한 것은 승인이 실제 실행 내용과 연결되어 있어야 한다는 점입니다.
에이전트가 마지막에 “처리했습니다”라고 말하면 사용자는 일이 끝났다고 받아들이기 쉽습니다.
하지만 성공 여부는 문장만으로 판단할 수 없습니다. 반품 접수가 실제로 존재하는지, 올바른 주문에 연결되었는지, 필요한 상태로 저장되었는지 확인해야 합니다.
도구 호출이 성공했다는 응답을 받더라도 반환값과 업무 결과를 살펴야 할 수 있습니다. 요청을 받아 두었다는 의미인지, 처리가 완전히 끝났다는 의미인지도 구분해야 합니다.
행동의 결과를 해당 시스템의 상태와 연결해 확인할 수 있어야 완료라는 말에도 근거가 생깁니다.
이런 검증은 운영 지표에도 영향을 줍니다. 에이전트가 성공했다고 표현한 횟수와 실제 업무가 완료된 횟수를 혼동하면 성과를 잘못 평가할 수 있습니다.
에이전트를 설계할 때는 무엇을 할 수 있는지에 관심이 모입니다. 질문에 답하고, 정보를 찾고, 외부 시스템을 조작하는 모습이 눈에 띄기 때문입니다.
실제로 업무를 맡기려면 그 주변도 살펴야 합니다.
어떤 입력을 믿을 것인가.
누구의 권한으로 실행할 것인가.
오류가 나면 무엇을 확인할 것인가.
어느 조건에서 멈추고 사람에게 넘길 것인가.
이 질문에 답하면 자동화할 수 있는 범위도 구체적으로 정할 수 있습니다. 읽기 전용 작업부터 시작하거나, 외부 변경은 검토 후 실행하도록 구성할 수도 있습니다.
AI가 일하는 과정을 지켜볼 때는 능숙한 설명과 함께 실행의 경계를 보아야 합니다.
잘못 선택했을 때 어디에서 발견하고, 어떻게 멈추게 할 것인가.
그 답이 있어야 반복되는 업무를 더 안심하고 맡길 수 있습니다.
다음 글에서는 이렇게 만든 AI 기능이 실제로 좋아졌는지 확인하는 방법을 살펴보겠습니다. 잘 나온 몇 번의 답변을 넘어, 비교 가능한 평가 기준을 어떻게 만들 수 있을지 이야기하겠습니다.
참고 자료
Anthropic — Building effective agents