에이전트를 나누는 건 기능 개수가 아니라, 예외를 만났을 때 누가 정하느냐다

이 글은 도구 추천을 하지 않습니다. 무엇을 깔아야 하는지도 다루지 않아요. 세 가지 방식이 실제로 어디서 나뉘는지, 그리고 그 경계를 만든 쪽이 자기 문서에 뭐라고 적어 놨는지만 봅니다.

에이전트라는 말은 매일 보는데 챗봇과 어디가 다른지는 설명이 안 되던 분이라면 맞습니다. 2026년 9월에 확인한 내용이고요.

기능 목록으로 비교하는 글은 이미 많습니다. 그런데 기능 개수로는 예약이 되는 자동화와 에이전트가 구분되지 않아요. 둘 다 예약을 끝내거든요.

같은 과제를 세 방식에 줬습니다. 그리고 예외를 하나 집어넣었더니 셋 중 하나만 사람 손이 안 갔어요. 참고로 가장 성적이 좋은 시스템도 실제 업무의 **30%**만 사람 손 없이 끝낸다는 실험이 있는데요, 그 30%가 어떤 자질로 돌아가는지가 이 글의 주제입니다.

기능 개수로 왜 구분이 안 되는가

기능 개수로는 구분되지 않습니다. 결과가 같아도 과정이 다르기 때문입니다.

같은 과제를 두 방식에 줬습니다. 다음 주 화요일 부산 출장, 항공권과 숙소.

순서를 1번부터 5번까지 미리 적어 둔 쪽은 예약을 끝냈습니다. 표가 끊기고 숙소가 잡히고 달력에 시간이 들어갔어요. 목표만 준 쪽도 예약을 끝냈고요.

여기까지는 나온 결과가 같습니다. 그래서 "예약이 되나"로는 아무것도 못 가릅니다.

앤트로픽은 이 경계를 어떻게 적어 놨나

앤트로픽은 두 방식을 한 줄씩으로 나눠 정의합니다. 개발자용 문서에 나란히 적혀 있어요.

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

앞쪽은 "미리 깔아 둔 길"이고 뒤쪽은 "자기 과정과 도구 사용을 스스로 지휘한다"입니다. 경계가 기능이 아니라 통제권의 위치에 그어져 있습니다.

오픈에이아이는 무엇을 배제하는가

오픈에이아이는 반대 방향으로 씁니다. 무엇이 에이전트인지보다 무엇이 아닌지를 앞쪽에 못 박아요.

Applications that integrate LLMs but don't use them to control workflow execution—think simple chatbots, single-turn LLMs, or sentiment classifiers—are not agents.

한 번 묻고 한 번 답하고 끝나는 것은 배제됩니다. 언어 모델을 쓰느냐가 아니라 그 모델이 실행을 통제하느냐가 기준입니다.

두 회사가 다른 문장으로 같은 곳에 선을 그었습니다.

그 경계를 눈으로 보려면 무엇을 흔들어야 하나

경계를 보려면 예외를 하나 집어넣어야 합니다. 순조로운 과제로는 셋이 똑같이 보입니다.

집어넣은 예외는 이것이었습니다. 조건에 맞던 오전 항공편이 매진.

세 방식의 반응이 여기서 처음으로 달라졌습니다.

방식	매진 직후	다음 행동을 정한 주체
대화창에 질문	정지. 재질문 전까지 변화 없음	사람
미리 짠 순서	2번 단계에서 정지	사람 (미리, 문서에)
목표와 제약만	다음 편 확인 → 도착 시각 초과로 폐기 → 철도 조회	실행 주체

세 번째 줄만 사람이 개입하지 않았습니다.

왜 순서를 짜 두는 방식은 멈추는가

미리 짜 둔 순서는 적어 두지 않은 상황을 만나면 멈춥니다. 정의상 그렇게 동작해요.

2번 단계는 "조건에 맞는 편 고르기"였습니다. 조건에 맞는 편이 없으면 고를 대상이 없고, 다음 단계로 넘어갈 근거도 없습니다.

여기서 흔한 오해가 하나 있습니다. "분기를 넣으면 되지 않느냐"는 겁니다.

넣으면 됩니다. 매진이면 다음 편, 다음 편도 없으면 기차. 이렇게 적으면 그 상황은 통과해요.

다만 그 분기도 사람이 미리 적은 것입니다. 다음에는 숙소 만실이 나오고, 그다음엔 태풍 결항이 나옵니다. 적어 놓은 줄은 계속 길어지는데 다음 주에 무엇이 터질지는 모릅니다.

적어 둔 만큼만 가는 구조입니다.

목표만 줬을 때 무엇이 새로 생기는가

새로 생기는 것은 방법을 고를 권한입니다. 성능이 아니라 권한이에요.

준 것은 세 줄이었습니다. 두 시 전 도착, 왕복 15만 원 이내, 회의장에서 걸어갈 거리.

돌아온 결과에는 철도가 있었습니다. 세 줄 어디에도 철도라는 단어가 없었고요.

교통수단은 제약이 아니라 방법이었기 때문에 열려 있었던 겁니다. 제약은 도착 시각·비용·거리 셋뿐이었어요.

그럼 아무거나 고르는가

아무거나 고르지는 않습니다. 경계를 어디에 그어 두느냐에 따라 사람을 부르기도 합니다.

환불이 안 되는 표를 끊어야 하는 대목에서는 확인을 요청하고 멈췄습니다. 다만 이건 내장된 성질이 아니라 그렇게 정해 뒀을 때 생기는 동작이에요. 문서들도 이 부분을 능력이 아니라 설정으로 다룹니다.

제가 처음에 잘못 세운 기준

이 글의 초안에서 저는 판별 기준을 "광고 문구에서 에이전트라고 파는 것을 걸러내는 법"으로 잡았습니다.

그런데 그 틀로 쓰고 나니 읽는 사람이 얻는 게 의심하는 태도뿐이더군요. 무엇인지는 여전히 모르는 상태로 끝났습니다.

원인은 하나였습니다. 제가 판정하는 글을 쓰면서 독자에게는 이해가 필요했던 겁니다. 셋으로 나눠 보면 이렇습니다. 첫째, 판별법은 이미 개념을 아는 사람용입니다. 둘째, 벤더를 의심하는 프레임은 도구를 못 고르게 만듭니다. 셋째, 제 근거가 시장 비판 자료라 개념 설명 재료가 아니었어요.

그래서 방향을 셋 다 바꿨습니다. 개념 설명으로, 한 과제 시연으로, 회사 공개 문서로.

그래서 도구를 볼 때 무엇을 확인하나

확인할 것은 하나입니다. 예외가 났을 때 사람이 다시 알려 줘야 하는가.

기능 개수는 확인 대상이 아닙니다. 응답 품질도 아니고요. 둘 다 예외 앞에서는 정보를 주지 않습니다.

• 매진·품절·오류 같은 예외를 일부러 하나 만들어 본다
• 그 상태에서 아무 말도 안 하고 기다려 본다
• 화면이 변하는지, 그대로 멈춰 있는지 본다

멈춰 있으면 통제권은 아직 사람에게 있습니다.

지금 어디까지 되는가

지금은 맡기고 나가는 단계가 아닙니다. 맡기고 지켜보는 단계입니다.

가상의 소프트웨어 회사를 만들어 실제 업무를 시켜 본 연구(TheAgentCompany, arXiv:2412.14161)에서, 가장 성적이 좋은 쪽도 과제의 30%만 사람 손 없이 완수했습니다. 논문은 긴 호흡의 과제가 현재 시스템의 범위 밖이라고 적고 있어요.

그리고 제약을 빼면 결과가 넓어집니다. 예산 한 줄을 지웠더니 오전 편이 전부 차 있는 상황에서 비즈니스석을 잡아 왔습니다. 30만 원이었고, 두 시 전 도착이라는 목표는 지킨 결과였어요.

틀린 답이 아니라 제가 허용 범위를 안 알려 준 결과입니다.

맡기는 쪽이 하는 일은 무엇으로 바뀌나

없어지지 않고 바뀝니다. 순서를 짜 주던 일이 선을 긋는 일로 옮겨 가요.

앞의 사례 넷을 그대로 액션으로 옮기면 이렇습니다.

1. 매진처럼 예외가 나올 수 있는 과제를 하나 고른다
2. 목표와 제약을 분리해서 적는다 — 도착 시각은 제약, 교통수단은 방법
3. 비용 상한처럼 넘으면 안 되는 선을 숫자로 넣는다
4. 되돌리기 어려운 동작 앞에서는 확인을 요청하도록 정해 둔다

네 줄을 적는 데 5분이면 됩니다. 순서 열 줄을 적는 것보다 짧아요.

지금 하시는 일 중에 중간에 예외가 튀어나오는 것은 무엇인가요. 그게 첫 후보입니다.

---

같은 과제를 세 방식으로 돌린 기록은 영상으로 정리했습니다. 제가 실제로 친 지시문 원문은 오픈톡 방구석모각코 자료집에 있습니다.