당신이 만든 건 에이전트가 아니라 자동화다

'에이전트를 만들었다'고 말하는 프로젝트 대부분이 실제로는 자동화이거나 작업 오케스트레이션이라는 주장이 다시 회자되고 있다. 데이터 사이언스 컬렉티브에 실린 벤자민 에티엔의 해설로, 자동화·함수 호출·에이전트 세 가지를 코드 예시와 함께 갈라놓는다. 지난해 7월 공개된 글이지만 에이전트라는 말이 더 헐거워진 지금 다시 읽히고 있다.

무슨 일인가 / 배경

필자의 요지는 한 문장으로 압축된다. 에이전트는 '무엇을 하라'는 절차를 받는 존재가 아니라 '목표'를 받고 방법을 스스로 찾아 가며 도중에 조정하는 존재다. 비유는 명료하다. 목적지를 향해 장애물을 피해 가며 스스로 경로를 바꾸는 자율주행차가 에이전트라면, 정해진 속도를 유지하는 크루즈 컨트롤은 자동화다. 글은 '에이전트를 만들고 있다고 생각하는 경우의 99%는 사실 자동화'라는 도발적인 추정으로 시작한다.

핵심 짚어보기

첫 번째 층은 자동화다. 사전에 짜 놓은 규칙대로 돌고, 결과는 결정론적이며, 목적은 반복과 효율이다. 필자가 든 예시는 CSV 파일을 읽어 타임스탬프 열을 붙이고 저장하는 짧은 파이썬 스크립트다. 훌륭하게 일하지만 '매출이 떨어졌으니 마케팅팀에도 메일을 보낼까' 같은 판단은 하지 못한다. 일꾼이지 전략가가 아니라는 것이다.

두 번째 층은 함수 호출(function calling)이다. LLM이 사용자 요청을 보고 외부 도구가 필요한 시점을 판단하고, 호출에 필요한 인자를 형식에 맞게 만들어 준다. 핵심은 LLM이 실행하지 않는다는 점이다. 실행과 응답은 외부 도구가 하고, LLM은 똑똑한 라우터 역할에 머문다. 순수한 형태에서는 질의-호출-응답으로 끝나는 단일 턴 상호작용이다. 날씨 API를 붙인 것만으로 에이전트를 만들었다고 보기 어려운 이유가 여기 있다.

세 번째 층이 에이전트다. 자율성, 추론, 목표 지향적 행동이 기준이며, 필자는 강화학습의 관점을 끌어와 설명한다. 글이 예시로 드는 '해커 에이전트'는 정해진 순서 없이 상황에 따라 도구를 골라 쓰는 진짜 동적 도구 선택을 보여준다. 이 층에 도달했는지 가르는 질문은 하나다. 계획이 어긋났을 때 스스로 다른 방법을 시도하는가.

혼란의 원인으로는 용어 중첩과 마케팅 과장이 지목된다. 세 층이 실제 시스템 안에서 겹쳐 쓰이는 데다, '에이전트'라는 말이 붙어야 팔리는 시장 분위기가 구분을 흐린다는 것이다.

1인기업 실전 적용 포인트

• 만들기 전에 한 줄로 적어 보라. '이 시스템에 실패가 발생하면 스스로 다른 경로를 시도하는가.' 아니라면 그것은 자동화이며, 그렇게 부르는 편이 유지보수에 훨씬 유리하다.
• 매일 도는 수집·요약·발행 같은 정형 업무는 굳이 에이전트로 만들지 마라. 크론과 스크립트가 더 싸고, 더 안 죽고, 로그가 읽힌다. 에이전트는 결과가 매번 달라져도 되는 자리에만 넣는 것이 맞다.
• 외주나 강의를 판다면 용어부터 정직하게 나눠 써라. '에이전트 구축'이라 팔고 자동화 스크립트를 납품하면 첫 계약은 되지만 재계약은 사라진다.
• 이미 굴리는 자동화가 있다면 층을 올리는 순서는 자동화 → 함수 호출 → 에이전트다. 도구 호출 한 개를 붙여 보고, 그다음에 판단 지점을 넘겨라. 순서를 건너뛴 자동화는 대부분 통제 불가능한 비용으로 돌아온다.

전망 / 주의점

용어 구분은 취향 문제가 아니라 비용 문제다. 결정론적으로 처리해도 될 일을 LLM 판단에 맡기면 토큰과 지연 시간, 실패율이 함께 올라간다. 반대로 진짜 판단이 필요한 자리에 규칙을 박아 두면 예외마다 사람이 붙어야 한다. 1인기업에게 필요한 것은 '전부 에이전트로'가 아니라, 어느 지점까지 규칙으로 밀고 어디서부터 판단을 넘길지 선을 긋는 감각이다. 이 글의 쓸모도 거기에 있다.

출처: 해커뉴스 경유 · 미디엄 데이터 사이언스 컬렉티브 (https://medium.com/data-science-collective/why-there-is-confusion-around-automation-and-agentic-ai-1a4c33860736)