그래프 엔지니어링 입문 — 큰 프롬프트를 노드와 엣지로 나누는 법

AI에게 업무를 맡길 때 흔한 첫 시도는 하나의 에이전트에게 하나의 큰 프롬프트를 주는 것입니다. 결과가 그럴듯하면 잘된 것처럼 보이지만, 그 답의 숫자가 어디서 왔는지 물으면 대답하기 어렵습니다. 이 글은 그 문제를 구조로 푸는 방법인 그래프 엔지니어링을 소개합니다. Google Cloud의 Agent Development Kit 팀 Annie가 영어 영상에서 설명한 내용을 한국어로 풀어 정리했고, 끝에서 20분 안에 자기 업무를 그래프로 그려 보는 실습을 합니다.

큰 프롬프트 하나가 지어내는 것

영상의 예시는 마라톤 주자입니다. 하나의 에이전트에게 하나의 거대한 프롬프트로 날씨 조회, 코스 분석, 체력 점검, 전략 수립을 전부 시킵니다. 답은 매우 자신 있고 구체적입니다. 그런데 이 에이전트에게는 날씨 API도 코스 데이터도 없습니다. 그래서 답 속의 숫자는 전부 지어낸 것, 곧 할루시네이션입니다.

모든 단계가 하나의 모델 호출 안에 들어 있으면 아무것도 가져올 수 없고, 테스트할 수 없고, 신뢰할 수 없다는 것이 설명의 요지입니다. 고칠 것은 더 나은 프롬프트가 아니라 구조입니다.

프롬프트에서 그래프까지 네 단계

영상은 이 흐름을 네 단계로 설명합니다.

1. 프롬프트 엔지니어링: 모델에게 무엇을 말할지 다룹니다.
2. 컨텍스트 엔지니어링: 모델 주변에 무엇을 둘지 다룹니다.
3. 루프 엔지니어링: 에이전트가 계획하고, 행동하고, 확인하는 것을 한 사이클 안에서 반복하게 합니다.
4. 그래프 엔지니어링: 여러 조각의 작업이 함께 작동하게 합니다.

네 번째가 그다음 층입니다. 그 조각이 노드이고, 조각들을 잇는 배선이 엣지입니다.

노드와 엣지, 함수 노드와 에이전트 노드

노드는 그래프 안의 작업 한 조각입니다. 에이전트일 수도 있고 결정론 함수일 수도 있습니다. 결정론 함수는 같은 입력이면 같은 결과가 나오도록 정해진 규칙대로 움직이는 작업입니다. 엣지는 노드 사이의 배선으로, 실행 순서와 데이터 흐름을 나타내는 화살표입니다.

영상의 노드 두 개짜리 그래프는 이렇습니다. 하나는 모델 호출 없이 날씨와 코스 조건을 가져오는 함수 노드이고, 다른 하나는 그 조건을 읽고 조언을 쓰는 에이전트 노드입니다. 기준은 한 줄입니다. 예측 가능한 작업은 함수에 넣고, 추론은 모델에 넣습니다. 두 종류의 노드는 같은 그래프 안에서 같은 방식으로 배선됩니다.

팬아웃과 조인, 서로 의존하지 않는 일은 동시에

마라톤 예에서 날씨, 코스, 체력 세 입력은 서로 의존하지 않습니다. 하나씩 순서대로 기다릴 이유가 없으니 함께 병렬로 돌리면 됩니다. 하나에서 여러 가지로 갈라 병렬로 실행하는 이 패턴을 팬아웃이라 부릅니다.

갈라진 가지는 조인 노드에서 다시 만납니다. 조인은 세 작업이 모두 끝나기를, 곧 느린 작업까지 기다린 뒤 결과를 노드 이름을 키로 하는 하나의 묶음(딕셔너리)으로 모읍니다. 이 묶음을 위해 병합기나 취합용 에이전트를 따로 둘 필요는 없다고 합니다.

라우터, 갈림길에서 누가 고르는가

라우터는 다음에 어떤 노드로 갈지 고르는 노드이고 두 종류가 있습니다.

• LLM 라우터: 모델에게 분류를 맡깁니다. 동작은 하지만 토큰이 들고, AI는 비결정론적이라 잘못 읽을 수 있습니다.
• 결정론 라우터: 고정된 규칙과 조건을 가진 노드를 그래프에 넣습니다.

고르는 기준은 선택지의 모양입니다. 자유 텍스트 요청처럼 조건문이 읽을 신호가 없는 열린 집합이면 LLM 라우터가 낫습니다. 선택지가 닫혀 있고 신호가 데이터 안에 있으면 결정론 라우터가 이깁니다. 마라톤 예에서 날씨는 덥다, 춥다, 보통의 닫힌 집합이라 결정론 라우터를 골랐고, 더 믿을 수 있고 비용도 덜 든다고 설명합니다.

비용은 모델이 필요한 노드에만

병렬 조회 세 개, 조인 하나, 전략가 하나를 모두 합쳐도 LLM 호출은 정확히 한 번입니다. 모델이 필요한 노드는 전략가 에이전트뿐이고 나머지는 전부 결정론 로직이기 때문입니다.

그래프를 쓸지 판단하는 두 질문

첫째, 입력이 도착하기 전에 워크플로우를 그릴 수 있는가. 그릴 수 있다면 그래프 워크플로우를 씁니다. 둘째, 모양 자체가 입력에 달려 있다면 어떻게 하는가. 영상은 깊이 있는 조사(딥 리서치) 상황을 예로 듭니다. 그래프 모양을 미리 알 수 없으므로, 코드가 실행 중에 모양을 정하는 동적 워크플로우를 씁니다.

20분 실습, 내 업무 3단계를 그래프로 그리기

준비물은 종이 한 장과 펜, 그리고 최근 AI에게 맡겼거나 맡기고 싶은 업무 하나입니다. 산출물은 그래프 그림 1장입니다. 그림에는 화살표마다 「의존 있음/없음」, 노드마다 「함수/에이전트」 표시가 들어가야 합니다.

아래 예시는 마라톤 예를 일반 업무로 옮긴 설명용 사례이며, 영상에 나온 사례가 아닙니다. 거래처 세 곳의 견적서에서 금액과 납기를 뽑아 표로 합치고 추천 초안을 쓰는 일이라면, 「견적서에서 항목 뽑기 → 표로 합치기 → 초안 쓰기」 3단계가 됩니다.

1. 단계 나열, 3분: 업무를 3단계로 적어 상자(노드)로 그리고 순서대로 화살표로 잇습니다. 같은 일의 반복은 상자를 여럿 그려도 됩니다.
2. 의존 질문, 5분: 화살표마다 묻습니다. 뒤 상자가 앞 상자의 결과를 실제로 쓰는가. 쓰면 「의존 있음」, 쓰지 않으면 「의존 없음」입니다. 예시에서 견적서 상자끼리는 서로의 결과를 쓰지 않으므로 「의존 없음」이고, 합치기 상자는 세 결과가 모두 필요하므로 「의존 있음」입니다.
3. 병렬 후보와 노드 종류, 4분: 「의존 없음」 화살표로 이어진 상자는 병렬(팬아웃) 후보로 묶고, 그 뒤에 결과를 모을 조인을 둡니다. 각 상자에는 정해진 규칙으로 되는 일이면 함수, 읽고 판단하고 글로 써야 하면 에이전트라고 적습니다. 예시에서는 표에 옮기기는 함수, 추천 초안은 에이전트입니다.
4. 라우터 지점, 3분: 결과에 따라 길이 갈리는 곳이 있으면 표시합니다. 선택지가 정해진 목록이면 결정론 라우터, 자유 문장을 읽어야 하면 LLM 라우터라고 적습니다.
5. 자가 점검, 5분: 아래 세 질문에 답합니다.
   • 예측 가능한 일이 에이전트로 표시돼 있지 않은가.
   • 「의존 없음」 상자들이 병렬로 묶였고, 그 뒤에 조인이 있는가.
   • 입력이 도착하기 전에 이 그림을 그릴 수 있는가. 모양이 입력에 달려 있지는 않은가.

마무리

큰 프롬프트 하나가 숫자를 지어낼 때 고칠 것은 문장이 아니라 구조입니다. 노드로 나누고 엣지로 잇고, 서로 의존하지 않는 일은 팬아웃으로 동시에 돌리고, 조인으로 모으고, 갈림길은 선택지의 모양에 맞는 라우터로 정합니다. 오늘 그린 그림 한 장이 그 출발점입니다.

출처

• 영상 A: Annie(Google Cloud, Agent Development Kit 팀). 영상 원 링크(영상이 첨부된 X 링크): https://x.com/0xCodila/status/2098182800482390216
• 확인 근거: 2026-09-14 로컬 보관 원문·전사본
• 본문의 요약과 표현은 영어 영상을 한국어로 옮긴 것입니다.