"에이전트 (Agent)"가 너무 많은 일을 하고 있습니다

이제 "에이전트 (Agent)"라는 단어는 거의 모든 것을 포괄합니다. 단일 채팅 프롬프트(chat prompt)도 에이전트라고 불립니다. 중간에 LLM (Large Language Model)이 포함된 크론 잡 (cron job)도 에이전트라고 불립니다. 계획을 세우고, 10개의 도구(tool)를 호출하며, 실패 시 재시도하는 시스템도 마찬가지입니다.

브랜딩을 걷어내면 대부분의 유용한 에이전트들은 동일한 작은 형태를 공유합니다. 무언가 발생하고, 시스템이 필요한 것을 수집하며, 작업을 수행하고, 그 결과를 인간이나 다른 시스템이 볼 수 있는 곳에 배치합니다. 네 단계: 트리거 (trigger), 데이터 (data), 액션 (action), 전달 (deliver). 여러분의 사용 사례에 대해 각 단계를 명명할 수 있다면, 여러분은 그것을 구축할 수 있습니다. 만약 명명할 수 없다면, 여러분은 아직 에이전트를 가진 것이 아니라 막연한 희망을 가진 것뿐입니다.

루프: 트리거, 데이터, 액션, 전달

이를 평이한 의사코드 (pseudocode)로 나타내면 다음과 같습니다:

on trigger:                 # 웹훅 (webhook), 크론 (cron), 새로운 행 (new row), 메시지
    context = gather()      # 파일 읽기, API 쿼리, 레코드 가져오기
    result  = act(context)  # LLM 호출, 도구 사용 (tool use), 또는 연산
...

제가 출시한 모든 신뢰할 수 있는 에이전트는 이 구조에 부합합니다. 흥미로운 엔지니어링 요소는 거의 항상 LLM 호출에 있지 않습니다. 그것은 나머지 세 단계에 존재합니다. 즉, 트리거가 적절한 시점에 발생하도록 만들고, 모델에 정확히 필요한 데이터만을 공급하며, 오류가 발생했을 때 명확하게 알릴 수 있는 곳으로 전달하는 것입니다.

구체적인 예시: "새로운 고객 지원 티켓을 요약하고 화가 난 티켓에 플래그를 지정하라."

• 트리거 (Trigger): 티켓 테이블의 새로운 행 (new row).
• 데이터 (Data): 티켓 텍스트와 고객의 플랜(plan) 및 최근 3개의 티켓.
• 액션 (Action): 감정 분류 (classify sentiment), 한 줄 요약 작성.
• 전달 (Deliver): Slack 채널에 게시, 헬프데스크(helpdesk)에 라벨 추가.

계획 루프 (planning loop)도, 자율성 (autonomy)도 없습니다. 그냥 실행되며, 유용합니다.

프롬프트만으로 충분할 때

대부분의 작업은 에이전트를 필요로 하지 않습니다. 직접 실행할 수 있는 좋은 프롬프트(prompt)가 필요할 뿐입니다.

작업이 단발성(one-shot)이고, 이미 키보드 앞에 있으며, 출력물을 눈으로 직접 확인할 수 있는 상황이라면 일반적인 프롬프트(prompt)를 사용하세요. 이메일 재작성, SQL 쿼리 초안 작성, 스택 트레이스(stack trace) 설명 등은 채팅창을 열고 컨텍스트(context)를 붙여넣는 것이 당신이 구축할 그 어떤 파이프라인(pipeline)보다 빠르며, 실수도 즉시 잡아낼 수 있습니다.

에이전트(agent)를 구축하는 데에는 실제 비용이 발생합니다. 유지 관리해야 할 트리거(trigger), 저장해야 할 자격 증명(credentials), 에러 핸들링(error handling), 로깅(logging), 그리고 새벽 2시에 당신을 깨울 수 있는 새로운 요소가 추가됩니다. 이러한 비용은 작업이 반복되고, 루프 내의 인간(human in the loop)이 병목 현상(bottleneck)이 될 때에만 지불할 가치가 있습니다.

구축할 가치가 있는 경우

다음 세 가지 조건이 충족될 때 에이전트를 구축하세요:

1. 반복되는가. 동일한 형태의 작업이 하루 또는 일주일 동안 여러 번 발생해야 합니다. 일회성 작업은 설정 비용을 결코 회수할 수 없습니다.
2. 트리거(trigger)가 실재하는가, 아니면 당신의 기억에 의존하는가. 시스템 이벤트(웹훅(webhook), 스케줄(schedule), 파일 도착 등)가 작업을 시작할 수 있다면 에이전트 후보가 됩니다. 만약 유일한 트리거가 "하고 싶을 때"라면, 그냥 프롬프트로 유지하세요.
3. "완료"를 정의할 수 있는가. 자동화된 방식이나 눈으로 훑어보는 것만으로도 좋은 출력물이 무엇인지 충분히 확인할 수 있을 만큼 잘 알고 있어야 합니다.

이 중 하나라도 누락된다면, 당신은 조용히 썩어갈 장난감을 만들고 있는 것입니다.

신뢰성 유지하기

데모(demo)와 신뢰할 수 있는 시스템 사이의 간극은 거의 대부분 에러 핸들링(error handling)에서 발생합니다.

작업 범위를 좁히세요. 하나의 에이전트에는 하나의 작업만 부여하세요. "모든 재무 운영을 처리하라"는 것보다 "송장을 읽고, 합계를 추출하여, 행을 작성하라"가 훨씬 낫습니다. 범위가 작아야 실제로 검증할 수 있습니다.

전달(deliver)을 멱등적(idempotent)으로 만드세요. 트리거는 두 번 실행될 수 있고, 재시도(retry)도 발생합니다. 에이전트가 Slack에 메시지를 게시하거나 행을 작성한다면, 반복 실행이 안전하도록 만드세요. 기존 결과가 있는지 확인하거나, 멱등성 키(idempotency key)를 사용하거나, 삽입(insert) 대신 업서트(upsert)를 사용하세요.

액션(action)을 제한하세요. 모델에게 자유 형식의 셸(shell) 액세스 권한을 주는 대신, 엄격한 시그니처(signature)를 가진 도구(tool)를 제공하세요. 티켓 ID와 라벨을 받는 함수는 감사(auditable)가 가능하지만, "어떤 명령이든 실행하라"는 불가능합니다.

전체 루프를 로깅(log)하세요. 트리거 페이로드(payload), 수집한 데이터, 모델의 출력물, 그리고 전달한 결과물을 모두 저장하세요. 에이전트가 오작동할 때 추측하는 것이 아니라, 정확히 해당 실행을 재현(replay)할 수 있어야 합니다.

크게 실패하세요 (Fail loud). 작동을 멈춘 채 침묵하는 에이전트는 에이전트가 없는 것보다 더 나쁩니다. 왜냐하면 당신은 수동으로 작업을 수행하는 것을 멈췄는데 아무도 이를 알아차리지 못하기 때문입니다. 단순히 에러(error)가 발생했을 때뿐만 아니라, 실행 횟수가 0이 될 때도 알림(alert)을 설정하세요.

이 방식이 취약한 부분

이 루프(loop)는 자신의 한계를 솔직하게 인정합니다. 이 방식은 명확한 트리거(trigger)와 확인 가능한 출력(output)이 있는 작업에 적합합니다. 하지만 개방형 연구(open-ended research), 장기적인 자율적 계획(autonomous planning), 또는 "완료"의 기준이 모호하고 잘못된 액션(action)의 비용이 큰 작업에는 적합하지 않습니다. 계획을 세우고 스스로 수정(self-correct)하는 다단계 에이전트(multi-step agents)는 실제로 존재하며 때로는 그만한 가치가 있지만, 신뢰성을 유지하기가 훨씬 더 어렵습니다. 또한 대부분의 팀은 실제로 필요해지기 훨씬 전부터 그런 에이전트를 갈구합니다. 만약 문제를 트리거(trigger), 데이터(data), 액션(action), 전달(deliver)로 압축할 수 있다면, 그것을 먼저 수행하세요. 단순한 루프가 증명 가능한 수준으로 작업을 수행할 수 없을 때만 자율성(autonomy)을 추가하세요.

하나의 작업부터 시작하세요

이번 주에 했던 일 중 가장 짜증 나는 반복적인 일 하나를 고르세요. 그 일의 네 가지 단계를 적어보세요. 만약 네 가지를 모두 채울 수 있다면, 당신은 첫 번째 에이전트를 가진 것입니다. 그리고 그것은 스프린트(sprint)가 아니라 아마도 오후 한나절이면 완성될 것입니다. 그 하나를 먼저 출시(ship)하세요. 신뢰성은 큰 루프에 억지로 붙이는 것이 아니라, 작은 루프를 통해 구축하는 것입니다.

저는 AI를 채팅 장난감에서 작동하는 도구로 전환하는 것에 대해 글을 씁니다. 저는 실제 실습을 통해 Claude를 배우는 게임 기반 아카데미인 AGINE Academy를 구축하는 것을 돕고 있습니다. 이는 독립적인 제품이며 Anthropic과 관련이 없습니다.