챗봇과 에이전트의 진짜 차이

하나는 질문에 답한다. 다른 하나는 무엇을 할지 정하고, 실행하고, 자기 일을 확인한 뒤 다음 단계로 넘어간다. 물어보길 기다리지 않고. 이 차이는 학술적인 이야기가 아니다. 무엇이 잘못될 수 있는지, 누가 그것을 잡아야 하는지가 달라진다.

챗봇은 입력한 것을 받아 응답을 만들고 멈춘다. 에이전트는 입력한 것을 받아 무엇이 일어나야 하는지 정하고, 그에 대해 무언가를 하고, 통했는지 확인한 뒤 다음에 무엇을 할지 정한다. 스스로, 종종 여러 단계에 걸쳐, 사람이 그중 어떤 것도 보기 전에. 구분은 그게 전부다. 사람들이 “AI 에이전트”를 두고 다툴 때 다투는 것——위험, 시스템에 필요한 감독, 마케팅 혼란의 대부분——은 이 한 가지 차이에서 따라온다.

챗봇이 실제로 하는 일

챗봇은 한 번 통과하는 시스템이다. 텍스트를 주면 텍스트를 돌려주고, 상호작용은 거기서 끝난다. 대화를 길게 기억하는 챗봇도 한 턴에 하는 일은 여전히 하나다. 지금까지 나온 말을 모두 읽고 다음 메시지를 예측한다. 사실을 확인하려고 데이터베이스를 조회하지도, 누군가를 대신해 무언가를 보내지도, 나중에 자기 답이 버텼는지 보러 돌아오지도 않는다. 틀려도 피해는 사람이 읽는 한 문장이고, 일의 보통 흐름에서 그에 따라 행동하기 전에 잡을 수 있다.

사람들이 챗봇에게 시키는 일의 대부분은 아무도 눈치채지 못한 채 이 모양에 맞는다. 이 문서를 요약해, 생일 메시지를 초안 잡아, 환불 정책을 설명해, 헤드라인 세 개를 써. 이 중 어느 것도 시스템이 현실과 무언가를 대조하거나 채팅 창 밖에서 행동할 것을 요구하지 않는다. 화면 이름이 “챗봇”이 아니라 “AI 어시스턴트”나 “코파일럿”이어도 마찬가지다. 상자 위 라벨은 안에서 일어나는 일을 바꾸지 않는다.

에이전트가 실제로 하는 일

에이전트는 한 번 통과가 아니라 루프를 돈다. 한 단계를 계획하고, 실제 도구를 호출해 행동한다. 데이터베이스를 검색하고, 메시지를 보내고, 파일을 고치고, API를 친다. 그 행동이 실제로 돌려준 것을 보고, 그 결과로 다음 단계를 정한다. 일이 끝나거나, 막히거나, 사람에게 확인하도록 만들어질 때까지 이를 반복한다. 중요한 점은 그 사이 개별 단계를 아무도 승인하지 않는다는 것이다. 시스템은 지난번 행동했을 때 실제로 일어난 일을 바탕으로, 다음에 무엇을 시도할지 스스로 정한다. 그리고 최종 답만이 아니라 그 판단 지점마다 틀릴 수 있다.

이 루프는 새롭거나 특이한 것이 아니다. 연구자들은 무엇을 할지 생각하고, 행동하고, 결과를 관찰하고, 다시 생각하는 형태를 여러 해 동안 기술해 왔고, 에이전트라고 부르는 제품 아래에서 실제로 도는 것도 이것이다. 경비 보고서를 제출하는 소프트웨어부터, 터미널을 열어 자기 명령을 실행하는 코딩 도구까지. 무언가가 말이 많은 챗봇이 아니라 에이전트인 이유는, 세계에 작용하고, 무슨 일이 있었는지 보고, 조정하기 때문이다. 사람이 한 수마다 승인하지 않아도, 반복해서.

같은 요청을 두 가지 방식으로

비슷하게 들리는 지시를 두 시스템이 받았을 때, 그 차이는 이렇게 보인다.

두 번째 질문을 챗봇에게 해도, 답처럼 보이는 것은 여전히 내놓는다. 대화에 우연히 붙여 넣은 것에서 만든, 그럴듯한 독촉 메일 세 통. 하지 않는 일은 실제 청구 시스템을 조회하는 것, 건수를 확인하는 것, 실제 임시보관함에 무언가를 넣는 것이다. 출력은 비슷해 보일 수 있다. 시스템이 실제로 한 일은 그렇지 않다.

이건 말의 다툼이 아니다

구분이 중요한 이유는, 무엇이 잘못될 수 있는지와 누가 그것을 잡는지가 바뀌기 때문이다. 챗봇의 최악은 틀린 답이다. 누군가 그것을 읽고, 일의 보통 흐름에서 오류를 잡거나 그에 따라 행동하지 않기로 한다. 실수는 대화를 떠나지 않는다. 에이전트의 최악은 현실에서 이미 취해진 틀린 행동이다. 잘못된 잔액으로 잘못된 고객에게 간 독촉, 잘못된 값으로 갱신된 기록, 두 번 발행된 환불——아무도 아무것도 검토하기 전에. 실수는 더 이상 문장이 아니다. 사건이 되고, 사건은 없던 일이 되지 않는다.

그래서 에이전트에는 챗봇과 다른 종류의 감독이 필요하다. 챗봇에 주로 필요한 것은, 손이 닿을 때 답을 확인하는 사람이다. 에이전트에 필요한 것은, 설계자가 그것이 돌기 전에 이미 정해 둔 것이다. 묻지 않고 취할 수 있는 행동은 무엇인지, 사람이 계획을 먼저 봐야 하는 행동은 무엇인지, 막히면 무슨 일이 일어나는지. 나중에 정하면, 에이전트가 이미 한 일을 힘든 방식으로 알게 된다.

볼 수 있는 것만 신뢰할 수 있다

이것은 FabricLoop의 Legibility 개념과 같은 생각이다. 실제로 볼 수 있는 접근과 행동만 통제할 수 있다. 챗봇에서는 이것이 거의 자동이다. 출력 전체가 사람이 읽는 메시지이므로, 행동과 그 기록은 같은 것이다. 에이전트에서는 아니다. 행동은 다른 시스템 안에서 일어난다. CRM, 받은편지함, 데이터베이스, 파일. 무엇을 건드리고, 바꾸고, 보냈는지 기록하는 것이 없으면, 사후에 검토할 방법도 없고 사전에 막을 방법은 더더욱 없다. Legibility는 에이전트 위에 얹는 컴플라이언스 장식이 아니다. 에이전트에게는 그것이 질문의 전부다. 그 “답”은 교정할 수 있는 문장이 아니라, 시스템이 보여 주도록 만들어지지 않으면 일어났는지조차 모를 수 있는 행동의 묶음이기 때문이다.

두 개념의 실무적 연결은 여기 있다. 에이전트는 챗봇보다 더 많고 다른 위험을 떠안는다. 그래서 자신이 한 일의 보이는 흔적과, 이해관계가 큰 경우에는 행동하기 전의 확인점이 필요하다. FabricLoop의 인간 개입률이, 이미 무언가 잘못된 뒤에 덧붙이는 뒷생각이 아니라 설계하고 측정하는 숫자로 다루는 이유가 이것이다.

시장은 이것을 늘 거꾸로 매긴다

진짜 판별법을 갖고 나면, 라벨이 양쪽 방향으로 얼마나 자주 거짓말을 하는지 분명해진다. “AI 에이전트”로 세게 팔리는 제품 가운데 상당수——첫 화면 제목의 그 단어, 요금 구간의 그 단어——의 속은 잘 다듬은 프롬프트 하나다. 입력을 읽고, 출력을 만들고, 끝. 독립된 도구 호출도, 루프도, 사람이 다음 클릭을 승인하지 않은 결정도 없다. 한편 “에이전트”라는 말을 한 번도 쓰지 않는 소프트웨어 가운데 상당수——자동화된 청구 흐름, 트래픽을 스스로 우회하는 모니터링 시스템, 실패한 서비스를 다시 시작하고 그것이 고쳤는지 확인하는 운영 스크립트——는 위에서 말한 루프를 조용히 돌리고 있다. 라벨의 단어는 실제로 쓰고 있는 기계에 대해 믿을 만한 말을 아무것도 하지 않는다.

이것을 적용하는 데 기술 배경은 필요 없다. 다음에 공급업체나 동료가 무언가를 에이전트라고 부르면, 지시와 결과 사이에 그것이 실제로 한 일이 무엇인지, 그리고 그중 몇 단계를 스스로 정했는지 물으면 된다.