그래프 엔지니어링 뜻, LLM 몫과 코드 몫 나누는 에이전트 설계

그래프 엔지니어링은 AI 에이전트가 할 일을 LLM(대규모 언어 모델)에게 맡길 일과 코드로 묶어 둘 일로 나누고, 그 흐름을 노드와 그래프로 설계하는 방법입니다. 결정론적 처리와 확률론적 처리의 차이, 하네스 엔지니어링과의 관계, 종이 위에서 해 보는 설계 11단계와 LangGraph로 옮기는 예시까지 정리했습니다.

그래프 엔지니어링이 또 나온 이유

프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링에 이어 그래프 엔지니어링이라는 말까지 나왔습니다. "이것도 곧 사라질 유행어 아닌가?"라는 의심이 드는 게 자연스럽습니다.

이 말을 널리 알린 곳은 LangChain입니다. 2026년 7월 22일 LangChain 블로그에 실린 글 "3 Years of Graph Engineering with LangGraph"는 이런 이름들이 어느 정도는 유행어라는 점을 인정합니다. 그러면서도 그 밑에 진짜 설계 문제가 있다고 봅니다. LLM은 예측하기 어렵고 비결정적인 소프트웨어라서, 안정적으로 돌리는 새 방법을 계속 찾게 되고 그때마다 새 이름이 붙는다는 것입니다. 같은 글은 그래프 엔지니어링을 "잘 확립된 접근법에 붙은 최신 이름"이라고도 부릅니다.

먼저 나눠야 할 두 가지 처리

그래프 엔지니어링을 이해하려면 결정론적 처리와 확률론적 처리부터 구분해야 합니다.

결정론적 처리: 몇 번을 돌려도 같은 결과

결정론적 처리는 같은 입력, 같은 상태, 같은 규칙이 주어지면 항상 같은 결과가 나오는 처리입니다.

은행 앱 송금을 생각하면 쉽습니다. 송금 금액을 계산하고 검증하는 코드에 100만 원이 들어갔다면, 몇 번을 실행해도 100만 원을 처리해야 합니다. 어떨 때는 100만 원, 어떨 때는 101만 원을 처리하면 안 됩니다.

이런 일은 LLM에게 맡기면 안 됩니다. 100만 원을 보내 달라고 했는데 LLM이 상황을 판단해 "101만 원을 보내는 게 좋겠습니다"라며 스스로 송금하면 곤란하니까요. 권한, 송금, 데이터 저장, 파일 삭제처럼 정확성과 안전성이 중요한 작업은 코드로 결정론적으로 처리합니다.

확률론적 처리: 예측은 어렵지만 유연하다

LLM 기반 처리는 확률론적입니다. 같은 프롬프트를 넣어도 글자 하나까지 똑같은 결과가 나온다고 보장할 수 없습니다.

대신 잘하는 일이 있습니다. 환불 문의 두 문장을 보겠습니다.

• "지난달에 결제했는데 아직 환불이 안 됐어요. 확인 좀 해 주세요."
• "돈이 아직 안 들어왔어요. 결제 취소해 주세요."

규칙 기반 챗봇은 미리 등록한 키워드로 움직입니다. 문장에 "환불"이 정확히 있으면 작동하지만, 두 번째 문장처럼 그 단어가 없으면 제대로 작동하지 않았습니다. LLM은 문맥을 읽고 두 문장 모두 환불 문의라는 걸 추론할 수 있습니다.

그래서 LLM은 사용자 입력의 의도 분석, 요약 작성, 검색어 만들기처럼 정답을 하나로 정하기 어려운 작업에 맞습니다.

그래프 엔지니어링의 뜻: 두 처리를 한 흐름으로

모든 업무를 AI에게 맡기는 게 아니다

AI 에이전트를 만든다는 것은 모든 업무를 AI에게 넘긴다는 뜻이 아닙니다. 전체 업무를 분석해서 어떤 일은 LLM에게 맡기고 어떤 일은 코드로 제한할지 먼저 정해야 합니다. 나누는 예를 두 쌍 들면 이렇습니다.

• 사용자의 자연어 문의를 해석하는 일은 LLM에게, 관련 문서를 검색하는 일은 코드로
• 답변을 만드는 일은 LLM에게, 그 답변에 개인정보가 들어 있는지 보는 일은 정규 표현식(글자 패턴으로 문자열을 찾는 규칙) 기반 코드로

노드로 만들고 흐름을 통제한다

그다음 각 업무를 하나의 노드, 즉 함수로 만들어 작업 흐름을 설계합니다. 사용자 입력이 들어오면 LLM이 분석하고, 그 결과에 따라 때로는 검색 노드로, 때로는 답변 작성 노드로 보내는 식입니다.

그래프 엔지니어링은 필요한 업무를 LLM 노드로 처리할지, 코드 기반의 결정론적 방법으로 처리할지 엔지니어가 구성한 뒤 그 흐름을 통제하는 방식으로 에이전트를 만드는 일입니다. LangChain의 글도 노드 하나는 결정론적 코드일 수도, LLM 호출 한 번일 수도, 도구 호출일 수도, 스스로 반복하는 에이전트 전체일 수도 있다고 설명합니다. 노드를 잇는 선(엣지)도 항상 같은 곳으로 가는 고정 연결과 조건에 따라 갈리는 연결이 있습니다.

하네스 엔지니어링과의 차이

"결국 하네스 엔지니어링 아닌가?"라는 질문에 대한 답은 "그렇다"에 가깝습니다. LLM 주변에 코드와 도구를 배치해 안정적으로 움직이게 한다는 점에서 두 개념은 같은 근본 문제를 다룹니다.

하네스 엔지니어링은 LLM이 실제 업무를 할 수 있도록 모델 주변 환경을 설계하는 일입니다. 그 환경에는 이런 것이 들어갑니다.

• 시스템 프롬프트
• 메모리
• 코드 기반의 권한, 검증, 로그

그래서 그래프 엔지니어링은 하네스⁠·루프 엔지니어링과 완전히 다른 새 개념이 아닙니다. 각 단계에 맞는 컨텍스트와 모델의 추론을 알맞은 자리에 배치한다는 같은 큰 아이디어를, 흐름도(그래프)라는 형태로 그린 것에 가깝습니다. LangChain의 글도 "루프는 방향이 있고 되돌아오는 그래프일 뿐"이라는 말을 인용하며 둘을 이어 봅니다.

그래프가 맞는 일, 에이전트 루프가 맞는 일

LangChain은 그래프가 늘 정답이라고 하지 않습니다. 구조가 예측 가능한 업무, 예를 들어 답하기 전에 먼저 분류해야 하거나 외부로 무언가를 보내기 전에 승인이 필요한 업무는 그래프가 맞습니다. 무엇을 해야 할지 열려 있는 탐색형 작업은 에이전트가 스스로 도구를 골라 반복하는 하네스(LangChain의 Deep Agents 같은 것)가 더 낫다고 봅니다. 또 실제 서비스용 에이전트는 재시도, 되묻기, 검증 반복 때문에 한 방향으로만 흐르지 않고 되돌아가는 고리가 자주 필요합니다.

그래프 설계 11단계, 종이 위에서 해 보기

아래는 코드를 쓰기 전에 종이나 메모장에서 해 볼 수 있는 설계 순서입니다.

준비물

• 설계하려는 AI 에이전트의 업무 설명(예: 고객 문의 응대, 그중 환불 문의)
• 메모할 수단(종이, 메모 앱, 화이트보드)

업무를 LLM 몫과 코드 몫으로 나누기

1. 에이전트가 해야 할 전체 업무를 적습니다.
   • 확인: 에이전트가 할 일 목록이 한 줄에 하나씩 적혀 있습니다.
2. 일마다 정확성⁠·안전성이 중요한 일인지 표시합니다.
   • 기준: 권한, 송금, 데이터 저장, 파일 삭제, 검증, 결제, 실행
   • 확인: 해당하는 일에 표시가 붙어 있습니다.
3. 표시된 일은 코드로 제한하기로 정하고 옆에 "코드"라고 적습니다.
   • 예: 답변에 개인정보가 들어 있는지 확인하는 일은 정규 표현식 기반 코드
4. 나머지 가운데 자연어 해석⁠·추론이 필요한 일에는 "LLM"이라고 적습니다.
   • 예: 문의 의도 해석, 답변 작성

노드와 흐름 만들기

5. 각 일을 하나의 노드(함수)로 정의합니다.
   • 확인: 일의 개수만큼 노드가 있고, 각각 LLM 처리인지 코드 처리인지 정해져 있습니다.
6. 사용자 입력이 들어오는 첫 노드를 정합니다.
   • 예: 첫 입력은 LLM이 분석합니다.
7. 첫 노드의 분석 결과에 따라 다음 노드가 갈리도록 화살표로 잇습니다.
   • 예: 환불 문의면 결제 조회 노드로, 일반 문의면 답변 작성 노드로
   • 확인: 분석 결과마다 갈 노드가 정해져 있습니다.

상태⁠·실패⁠·승인 정하기

8. 코드 영역과 LLM 영역이 함께 쓸 상태(문의 내용, 분류 결과, 조회한 결제 정보 등)를 적습니다.
9. 시작부터 끝까지 노드가 실행되는 순서를 적습니다.
10. 노드마다 실패했을 때 돌아갈 노드를 적습니다.
    • 예: 결제 조회가 실패하면 다시 조회, 세 번 실패하면 상담원 연결
11. 사람에게 승인을 받을 시점을 표시합니다.
    • 예: 실제 환불 실행 직전

마지막 점검

• 모든 일이 "LLM" 또는 "코드" 중 하나로 정해졌다
• 정확성⁠·안전성이 중요한 일은 코드 쪽에 있다
• 노드와 연결(흐름)이 그려졌다
• 공유 상태, 실행 순서, 실패 시 복귀, 사람 승인 시점이 적혔다

어떤 일을 코드에 둘지 헷갈리면 이 기준으로 돌아갑니다. 권한⁠·송금⁠·저장⁠·삭제⁠·검증⁠·결제⁠·실행은 코드, 자연어 해석⁠·요약⁠·검색어 만들기는 LLM입니다.

LangGraph로 옮기면 이렇게 된다

종이에 그린 그래프를 실제 코드로 옮길 때 많이 쓰는 도구가 LangGraph입니다. LangChain이 만든 파이썬⁠·자바스크립트 라이브러리로, 깃허브 저장소 langchain-ai/langgraph는 MIT 라이선스이고 별은 2026년 10월 기준 약 4만 4천 개입니다. 설치는 pip install -U langgraph입니다.

위 설계의 앞부분(분류 → 결제 조회 또는 답변 작성 → 개인정보 검사)을 옮긴 뼈대입니다. 분류와 답변 작성 함수 안에는 실제로 쓰는 모델 호출이 들어갑니다.

import re
from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    question: str
    intent: str
    payment: str
    answer: str

def classify(state: State):          # LLM 노드: 의도 분류
    intent = "refund"                # 실제로는 모델에게 분류를 맡긴다
    return {"intent": intent}

def lookup_payment(state: State):    # 코드 노드: 결제 내역 조회
    return {"payment": "2026-09-30 결제, 환불 처리 중"}

def write_answer(state: State):      # LLM 노드: 답변 작성
    return {"answer": "환불은 처리 중이며 3영업일 안에 들어옵니다."}

def check_privacy(state: State):     # 코드 노드: 주민등록번호 패턴 가리기
    masked = re.sub(r"\d{6}-\d{7}", "******-*******", state["answer"])
    return {"answer": masked}

def route(state: State):             # 분류 결과에 따라 다음 노드 고르기
    return "lookup_payment" if state["intent"] == "refund" else "write_answer"

builder = StateGraph(State)
builder.add_node("classify", classify)
builder.add_node("lookup_payment", lookup_payment)
builder.add_node("write_answer", write_answer)
builder.add_node("check_privacy", check_privacy)
builder.add_edge(START, "classify")
builder.add_conditional_edges("classify", route)
builder.add_edge("lookup_payment", "write_answer")
builder.add_edge("write_answer", "check_privacy")
builder.add_edge("check_privacy", END)
graph = builder.compile()

print(graph.invoke({"question": "돈이 아직 안 들어왔어요"}))

설계 단계와 코드의 짝은 이렇습니다.

• 8단계 공유 상태: State에 적은 항목이 노드 사이를 오가는 상태입니다.
• 5단계 노드: add_node로 등록한 함수 하나하나입니다.
• 7단계 갈림길: add_conditional_edges에 넘긴 route 함수가 다음 노드를 고릅니다.
• 10단계 실패 시 복귀: 노드에서 다시 앞 노드로 가는 연결을 추가하면 되돌아가는 고리가 생깁니다.
• 11단계 사람 승인: langgraph.types의 interrupt()로 그래프를 멈추고, compile(checkpointer=...)로 실행 상태를 저장해 두었다가 승인 뒤 이어서 실행합니다.

좋은 에이전트는 모델보다 구조에서 갈린다

그래프 엔지니어링이라는 이름은 새로 나왔지만 그 안의 생각은 새롭지 않습니다. 확률적으로 움직이는 LLM을 결정론적인 소프트웨어 구조 안에서 어떻게 쓰느냐가 전부입니다.

LLM에게 모든 걸 맡기는 것도, 모든 걸 고정된 코드로 묶는 것도 답이 아닙니다. 자연어 해석과 추론처럼 유연성이 필요한 곳은 LLM에게, 권한⁠·검증⁠·결제⁠·저장⁠·실행처럼 정확성과 안전성이 필요한 곳은 코드로 통제합니다. 그리고 두 영역이 어떤 상태를 공유하고, 어떤 순서로 실행되며, 실패하면 어디로 돌아가고, 언제 사람 승인을 받을지를 그래프로 설계합니다.

에이전트를 잘 만든다는 건 좋은 모델을 고르거나 좋은 프롬프트를 쓰는 것만이 아닙니다. 더 중요한 질문은 두 가지입니다. LLM에게 무엇을 판단하게 하고 무엇을 판단하지 못하게 할 것인가. 그리고 LLM이 일하는 업무 절차와 환경을 어떻게 설계할 것인가.