Agent와 Node 그리고 Tool의 차이가 궁금해요

한 문장씩 정의하기

세 단어는 크기 순서로 보면 쉽습니다. 가장 작은 실행 단위가 Tool, 그 Tool들을 순서대로 엮은 흐름의 한 칸이 Node, 그 흐름 자체를 상황에 따라 스스로 짜는 존재가 Agent입니다.

공연 무대로 비유하면

공연예술 현장에서 일해 온 경험 덕분에, 저희는 이 셋을 설명할 때 무대를 자주 꺼냅니다.

• Tool은 장비입니다. 조명기, 음향 콘솔, 막 장치. 버튼을 누르면 정확히 그 일을 하지만, 언제 켤지는 모릅니다.
• Node는 큐시트의 한 줄입니다. “Q12 — 암전 후 핀 조명 켜기.” 순서와 내용이 미리 적혀 있고, 리허설 때와 본 공연 때 똑같이 실행됩니다.
• Agent는 무대감독입니다. 배우가 대사를 건너뛰거나 장비가 멈추는 돌발 상황에서 큐시트에 없는 판단을 내리고, 필요한 장비를 직접 골라 씁니다.

좋은 공연에는 셋이 다 필요합니다. 큐시트 없이 무대감독의 즉흥에만 기대는 공연은 위험하고, 무대감독 없이 큐시트만 있는 공연은 사고 한 번에 멈춥니다. AI 자동화도 똑같습니다.

한눈에 비교하기

같은 일을 두 방식으로

예를 들어 공연 단체에 이런 메일이 왔다고 해 봅시다. “11월 8일 저녁 공연, 단체 20명 예매 가능한가요? 휠체어석도 필요해요.”

방식 1. Node로 짠 워크플로

사람이 미리 흐름을 그려 둡니다. 어떤 문의가 와도 같은 순서로 지나갑니다.

워크플로는 매번 같은 길로 가기 때문에 결과가 예측 가능하고, 어느 단계에서 문제가 났는지 바로 보입니다. 대신 “휠체어석”처럼 흐름도에 없던 요청이 끼어들면 놓치기 쉽습니다.

방식 2. Agent에게 맡기기

Agent에게는 “이 문의에 답할 수 있게 준비해 줘”라는 목표와 쓸 수 있는 Tool 목록만 줍니다. Agent는 먼저 좌석을 조회하고, 휠체어석 정보가 없으면 FAQ를 검색하고, 그래도 없으면 “담당자 확인 필요”라고 표시한 초안을 씁니다. 순서를 문의마다 스스로 바꾸기 때문에 예외에 강합니다. 대신 매번 판단 과정을 거치니 비용과 시간이 더 들고, 기록을 남기지 않으면 왜 그렇게 했는지 알기 어렵습니다.

셋은 어떻게 겹쳐 있을까

헷갈리는 이유는 셋이 서로를 품을 수 있기 때문입니다.

• Node 안에서 Tool을 부릅니다. “좌석 조회” Node는 결국 좌석 조회 Tool을 실행하는 한 칸입니다.
• Agent 하나가 Node 한 칸이 될 수 있습니다. 큰 워크플로의 대부분은 고정된 순서로 두고, 판단이 필요한 한 칸에만 Agent를 넣는 식입니다.
• Agent 자체를 Node로 만들 수도 있습니다. LangGraph 같은 도구에서는 “생각하기” Node와 “Tool 실행” Node를 고리로 이어 Agent를 만듭니다.

코드로 아주 단순하게 줄이면 이런 모양입니다.

개념을 보여 주기 위한 의사 코드

# Tool — 한 가지 일만 한다
def check_seats(date, count): ...
def search_faq(question): ...

# Node — 상태를 받아 한 단계를 처리하고 넘긴다
def classify(state):
    state["type"] = llm("이 문의의 유형은?", state["mail"])
    return state

# Agent — 목표를 이룰 때까지 다음 행동을 스스로 고른다
def agent(goal, tools, max_steps=8):
    history = []
    for _ in range(max_steps):          # 멈춤 조건
        action = llm.decide(goal, history, tools)
        if action.done: return action.answer
        history.append(tools[action.name](**action.args))
    return "담당자 확인 필요"

언제 무엇을 써야 할까

실무에서 권하는 순서는 이렇습니다.

1. 먼저 워크플로로 그려 봅니다. 업무의 70~80%는 순서가 정해져 있습니다. 정해진 일은 Node로 짜는 쪽이 빠르고 저렴하고 검증하기 쉽습니다.
2. 판단이 갈리는 칸에만 Agent를 둡니다. 문의 내용이 제각각이라 처리 경로가 매번 다르다면 그 칸이 Agent 자리입니다.
3. 중요한 결정 앞에는 사람 Node를 넣습니다. 환불, 계약, 외부 발송처럼 되돌리기 어려운 일은 AI가 초안까지만 만들고 사람이 승인합니다.
4. Tool은 작고 분명하게 만듭니다. 이름과 설명만 보고도 무엇을 하는지 알 수 있어야 Agent가 잘못 고르지 않습니다.

자주 하는 오해

“Tool을 많이 붙일수록 똑똑해진다”

반대인 경우가 많습니다. 비슷한 Tool이 여러 개면 Agent가 헷갈려 엉뚱한 것을 고릅니다. 꼭 필요한 Tool만, 겹치지 않게 주는 편이 정확합니다.

“Agent면 알아서 다 해 준다”

Agent에게는 반드시 멈춤 조건(최대 반복 횟수, 비용 한도), 권한 범위(읽기만 할지 쓰기까지 할지), 실행 기록이 필요합니다. 이 셋이 없으면 같은 일을 계속 반복하거나, 하지 말아야 할 일을 하고도 이유를 알 수 없습니다.

“워크플로는 구식이고 Agent가 최신이다”

둘은 경쟁 관계가 아니라 역할 분담입니다. 실제로 잘 돌아가는 시스템은 대부분 탄탄한 워크플로 위에 Agent를 필요한 만큼만 얹은 형태입니다.

자주 묻는 질문