AI 에이전트가 뭐냐고 물어봤더니, 생각보다 단순했습니다

기업 이메일 데이터를 AI로 분석하는 프로젝트를 진행하고 있습니다. LangGraph라는 프레임워크로 RAG 시스템을 만들어서, 이메일을 검색하면 AI가 답변해주는 것까지는 구현했습니다.

근데 이 과정에서 "에이전트"라는 단어가 계속 나오더라고요. ChatGPT도 에이전트, Claude도 에이전트, Cursor도 에이전트. 대충은 알겠는데, 막상 "에이전트가 정확히 뭐야?"라고 물으면 설명을 못하겠더라고요. 특히 제가 만든 게 에이전트인 건지, 그냥 파이프라인인 건지도 구분이 안 됐습니다.

그래서 직접 정리해봤습니다.

도구는 손이고, 에이전트는 뇌입니다

목수를 생각해보겠습니다.

망치, 톱, 드릴은 도구입니다. 목수가 "여기는 못을 박아야 하니까 망치를 쓰고, 저기는 잘라야 하니까 톱을 쓰자"라고 판단하죠. 도구는 시키면 하는 것이고, 목수는 뭘 시킬지 판단하는 겁니다.

AI에서도 똑같습니다.

"이메일을 검색해서 결과를 돌려주는 함수"는 도구입니다. "검색해"라고 시키면 검색하고 끝입니다. 스스로 "다음에 뭘 해야 하지?"라고 생각하지 않습니다.

반면 에이전트는 이렇게 동작합니다:

사용자: "최근 시스템 장애 이슈 정리해줘"

에이전트의 머릿속:
→ "먼저 이메일 검색을 해볼까"       → 이메일 검색 도구 사용
→ "결과가 좀 부족한데? 스레드도 보자" → 스레드 검색 도구 사용
→ "시스템 연관 관계도 확인해야지"     → 그래프 탐색 도구 사용
→ "이 정도면 정리할 수 있겠다"       → 답변 생성

핵심은 세 가지입니다:

자율적 판단 — 뭘 할지 스스로 결정합니다

도구 사용 — 실제로 검색하고, 분석하고, 실행합니다

반복 — 결과를 보고 "충분한가?" 판단해서 다음 행동을 정합니다

이 세 가지가 있으면 에이전트, 없으면 그냥 도구입니다.

에이전트의 코드는 놀라울 정도로 단순합니다

에이전트라고 하면 뭔가 엄청 복잡한 시스템일 것 같지 않습니까. 근데 막상 코드를 보면 이게 전부입니다:

while True:
    응답 = AI에게_물어보기(대화내용, 사용가능한_도구들)

    if 응답에_도구_사용이_있으면:
        결과 = 도구_실행(응답.도구)
        대화내용에_결과_추가(결과)
    else:
        break  # 도구 안 쓰면 끝

while 루프 하나입니다. AI한테 "너 이런 도구들 쓸 수 있어"라고 알려주고, AI가 "이 도구 쓸게요"라고 하면 실행하고, 결과를 다시 AI한테 보여주고, AI가 "더 할 거 없어요"라고 하면 끝입니다.

실제로 Anthropic이라는 회사가 만든 Claude Code도 이 방식입니다. 복잡한 프레임워크 없이 while 루프 하나로 돌아갑니다.

LangGraph가 곧 에이전트인 줄 알았습니다

여기서 제가 헷갈렸던 포인트가 나옵니다.

저는 LangGraph라는 프레임워크로 시스템을 만들었습니다. LangGraph는 "이 상황에서는 이쪽으로 가라"를 그래프로 그려서 흐름을 관리하는 건데, 처음에는 이게 곧 에이전트인 줄 알았거든요.

근데 아니더라고요.

다시 목수로 비유하면 이렇습니다. 에이전트가 목수라면 LangGraph는 작업 매뉴얼입니다. 실력 좋은 목수는 매뉴얼 없이도 알아서 판단합니다. 그게 while 루프 방식입니다. 반면 경험이 부족한 목수에게는 "이런 상황에서는 이렇게 해"라는 매뉴얼이 있으면 더 안정적이죠. 그게 LangGraph 방식입니다.

Anthropic이 단순한 while 루프로 할 수 있는 건, Claude라는 AI 모델이 워낙 똑똑해서 도구 설명만 보고도 적절한 도구를 골라 쓸 수 있기 때문입니다. 반면 다른 AI 모델을 쓸 때는 LangGraph로 흐름을 명시적으로 잡아주는 게 더 안전하고요.

정리하면 이런 관계입니다:

에이전트의 본질          = AI + 도구 + 반복 루프
만드는 방법 A (단순)     = while 루프 하나
만드는 방법 B (명시적)   = LangGraph로 흐름을 그래프로 관리
만드는 방법 C (역할 기반) = CrewAI 같은 프레임워크

LangGraph는 에이전트를 만드는 방법 중 하나일 뿐, 에이전트 자체가 아니었던 겁니다.

그런데 파이프라인은 에이전트가 아닙니다

이것도 헷갈렸던 부분입니다.

저는 이미 데이터 처리 코드가 있었습니다. 이메일을 추출하고, 분류하고, 저장하는 코드. "이것도 도구를 쓰고 있으니까 에이전트 아닌가?" 싶었거든요. 근데 아니더라고요.

회사 출근을 생각해보겠습니다.

파이프라인은 매일 똑같은 출근 루틴입니다. 알람 울리면 일어나고, 씻고, 옷 입고, 밥 먹고, 출발합니다. 비가 오든 눈이 오든 항상 같은 순서로 합니다. "오늘은 비가 오니까 씻기를 건너뛸까?" 이런 판단은 없습니다.

에이전트는 상황을 보고 행동을 바꿉니다. 비가 오면 우산을 챙기고, 지하철이 파업이면 택시를 부르고, 재택근무 날이면 아예 안 나갑니다. 같은 도구들(씻기, 옷 입기, 이동 수단)을 쓰지만, 상황에 따라 어떤 도구를 쓸지, 스킵할지를 판단합니다.

제가 만든 데이터 처리 코드도 마찬가지였습니다. 새 이메일이 0건이든 1만 건이든 무조건 전체 과정을 실행하고 있었거든요. 에이전트로 바꾸면 이렇게 달라집니다:

새 이메일이 0건이면? → 나머지 과정 전부 스킵

새 이메일이 있는데 긴급 키워드가 포함돼 있으면? → 알림도 보내기

변동이 많으면? → 전체 재분석. 적으면? → 바뀐 부분만 분석

같은 도구들입니다. 차이는 "상황을 보고 판단하는 로직"이 있느냐 없느냐, 그게 전부입니다.

그래서 프로젝트를 다시 보게 됐습니다

이 개념을 정리하고 나니까 프로젝트를 바라보는 눈이 달라졌습니다.

지금까지는 "이메일 검색 기능 만들기", "데이터 처리 코드 짜기" 같은 도구 단위로만 생각했습니다. 개별 기능을 하나씩 만들어서 순서대로 실행하는 것에 집중했던 거죠.

근데 이제는 질문이 바뀌었습니다. "이 도구를 어떻게 만들지?"가 아니라 "이 도구들을 언제, 어떤 순서로, 어떤 조합으로 쓸지를 누가 판단할 것인가?"로요.

실제로 제 프로젝트에는 이미 도구가 꽤 있었습니다. 이메일 검색, 스레드 검색, 시스템 그래프 탐색, 커뮤니티 요약 조회 — 이런 것들을 각각 만들어뒀거든요. 지금까지는 이걸 "사용자가 질문하면 → 전부 검색 → 결과 종합 → 답변"으로 고정된 순서로 실행하고 있었습니다.

근데 생각해보면 모든 질문에 모든 도구를 쓸 필요가 없습니다. "김대리 이메일 찾아줘"라는 질문에 시스템 그래프 탐색은 필요 없잖아요. 반대로 "이 시스템 장애가 어디까지 영향을 미쳤어?"라는 질문에는 그래프 탐색이 핵심이고요.

그래서 다음에 할 일은 이렇습니다. 지금 고정된 순서로 실행하고 있는 파이프라인에 "이 질문에는 어떤 도구를 써야 하지?"를 판단하는 로직을 넣는 것. 그러면 같은 도구들인데 에이전트가 되는 겁니다.

마무리

프로젝트를 하면서 에이전트라는 말을 수도 없이 들었는데, 솔직히 제대로 이해하지 못한 채 쓰고 있었습니다. 이번에 정리하고 나니까 결국 세 가지였습니다.

도구는 손이고, 에이전트는 뇌입니다. LangGraph 같은 프레임워크는 에이전트를 만드는 방법 중 하나인거고, 파이프라인에 판단을 넣으면 에이전트가 됩니다.

이미 도구가 있다면 절반은 된 겁니다. 거기에 "언제, 뭘 쓸지"를 판단하는 뇌를 얹는 것. 그게 에이전트를 만드는 핵심입니다.