안녕하세요, 주식회사 estra에서 엔지니어로 근무하고 있는 후쿠치입니다.

최근 X 등에서 「graph engineering」이라는 단어를 접하게 되었고, 기존의 수법과는 어떻게 다른지 궁금해져서 조사해 보았습니다.

기왕 하는 김에, prompt engineering에서 이어지는 「◯◯ engineering」의 흐름을 다시 한번 정리하면서, 본론인 graph engineering은 코드 예시와 실용 패턴을 포함하여 해설하겠습니다.

AI 에이전트 업계에서는 설계 수법의 유행어가 몇 달마다 바뀌어 왔습니다. prompt engineering, context engineering, harness engineering, loop engineering, 그리고 graph engineering입니다.

순서대로 살펴보면, 관심사가 「1회의 출력」에서 에이전트의 「업무 절차(work orchestration)」 측면으로 점점 옮겨가고 있다는 것을 알 수 있습니다.

이후의 설명에서는 「영수증을 읽어서 경비 정산을 자동화하는 AI」를 공통 소재로 하여, 각 수법이 무엇을 설계하는지 그림으로 살펴보겠습니다.

LLM에 전달하는 지시문(프롬프트)을 설계하는 수법입니다. 2022년 말 ChatGPT 등장 이후 일반화되었습니다. 말투를 고안하거나, 좋은 예시와 나쁜 예시를 보여주거나(few-shot), 단계적으로 생각하게 하는(Chain of Thought) 등, 1회의 입출력 품질을 높이는 테크닉 군입니다.

경비 정산의 예로 들면, 영수증 읽기 지시를 어떻게 작성하느냐가 prompt engineering입니다.

「읽어줘」라고만 해도 무언가는 돌아오지만, 형식이 제각각이라 후속 공정(경비 시스템 등록)에 사용할 수 없습니다. 출력 형식이나 읽을 수 없을 때의 동작까지 지시에 작성합니다. 설계 대상은 지시문 그 자체이며, 이곳이 모든 출발점이 됩니다.

LLM에 전달하는 정보 전체를 설계하는 수법입니다. 2025년 6월경, Andrej Karpathy 씨가 「prompt engineering보다 context engineering이라고 불러야 한다」라고 지지한 포스트를 계기로 퍼졌습니다. 지시문뿐만 아니라 검색 결과(RAG), 대화 이력, 도구 정의 등 「컨텍스트 윈도우(context window)에 무엇을 넣고 무엇을 넣지 않을 것인가」를 설계합니다.

경비 정산의 예에서는 「이 영수증의 계정 과목은 무엇인가」를 판정하게 할 때 무엇을 전달할 것인가에 대한 설계가 이에 해당합니다.

경비 규정 100페이지를 통째로 전달하면 요점이 흐려지고, 반대로 규정을 전달하지 않으면 판정 기준이 없어 추측에 의존하게 됩니다. 같은 모델, 같은 지시문이라도 전달하는 정보의 설계만으로 정밀도가 크게 달라집니다. LLM 실패의 상당수는 모델의 능력 부족이 아니라 전달하는 정보의 설계 미스라는 인식이 확산된 시기였습니다.

에이전트의 실행 환경(harness)을 설계하는 수법입니다. Anthropic이 2025년 11월에 공개한 「Effective harnesses for long-running agents」 등을 기점으로 퍼졌으며, 2026년에 들어서 martinfowler.com의 기사 등에서 「harness engineering」이라는 명칭이 정착되었습니다.

「Agent = Model + Harness」라는 정리로, 경비 정산의 예라면 모델 주변에 무엇을 준비해 둘 것인가에 대한 설계입니다.

어떤 도구(OCR API, 경비 시스템 등록)를 갖추게 할 것인지, 무엇을 기계적으로 검증할 것인지(명세 합계와 청구 금액의 일치 여부), 어디서 멈출 것인지(1만 엔 초과는 인간에게 전달) 등을 결정합니다. 모두 모델 본체에는 전혀 손을 대지 않고 「환경」만을 설계한다는 것이 포인트입니다. Claude Code로 치면 CLAUDE.md나 hooks, permissions를 정비하는 것이 바로 이것입니다.

에이전트가 돌리는 「시도 → 평가 → 재시도」의 루프 그 자체를 설계하는 수법입니다. LangChain이 2026년 6월에 공개한 「The Art of Loop Engineering」에서 이름이 붙여졌습니다. 「에이전트는 그저 LLM의 루프일 뿐이다」라는 표현 자체는 2024년경부터 밈(meme)으로 존재해 왔으나, 그것이 「무엇을 반복하게 하고 어디서 빠져나가게 할 것인가」라는 설계론으로서 이름을 얻게 된 흐름입니다.

경비 정산의 예에서는 읽기 결과의 검산 루프가 이에 해당합니다.

명세 합계와 청구 금액이 맞지 않으면 다시 읽게 합니다. 단, 2회까지로 제한하며 그래도 안 되면 인간에게 넘깁니다. 무엇을 피드백으로 전달할지, 종료 조건과 상한을 어떻게 둘지 등을 결정합니다. 이 설계에 따라 같은 모델이라도 완수율이 크게 달라집니다. 코딩 에이전트의 「테스트 실행 → 실패 시 수정 → 재실행」도 같은 구조입니다.

그리고 본론입니다. graph engineering은 AI 에이전트에게 시킬 일을 흐름도(flowchart)로서 설계하는 기법입니다. 2026년 7월 X(구 트위터)에서 화제가 되었습니다.

「그래프」라고 해서 막대그래프를 말하는 것은 아닙니다. 작업(node)을 화살표(edge)로 연결한 흐름도를 의미합니다. 즉, 업무 플로우차트의 AI 버전이라고 생각하면 대체로 맞습니다. 지금까지의 기법이 「하나의 AI 내부」를 설계해 온 것에 반해, graph engineering은 여러 AI와 인간을 포함한 업무 전체의 절차를 설계합니다.

경비 정산의 예라면, 이런 흐름도를 설계하게 됩니다.

[IMG:1]

노드와 화살표의 역할 분담을 정리하면 다음과 같습니다.

[IMG:2]

솔직히 말하면, 이 구조 자체는 전혀 새롭지 않습니다. 「현재 상태에서 어떤 사건이 발생하면 다음은 어떤 상태가 될 것인가」를 결정해 두는 메커니즘은 스테이트 머신 (State Machine, 상태 기계)이라 불리는 고전적인 방식으로, 신호등(초록→노랑→빨강)이나 자동판매기의 제어와 같습니다. 루프(loop)도, 에이전트 그래프(agent graph)도 그려보면 모두 같은 그림이 됩니다.

그렇다면 무엇이 새로운가 하면, 개념이 아니라 부품의 성능입니다. AI가 똑똑해졌기 때문에, 흐름도의 노드 하나에 「함수」가 아니라 「에이전트 통째로」를 넣을 수 있게 되었습니다. LangChain의 멤버들도 graph engineering이 버즈워드(buzzword)라는 점은 인정하면서도, 실질적으로 새로운 점은 바로 이 지점이라고 정리하고 있습니다1.

「에이전트는 LLM + 도구 + 루프면 충분하다」는 설계도 여전히 강력하게 존재합니다. 실제로 작은 태스크라면 그것만으로도 작동합니다. 하지만 업무 규모가 커지면 하나의 루프에 모든 것을 맡기는 방식에는 한계가 옵니다.

• 조사, 집필, 검증을 하나의 대화 이력(conversation history)에서 수행하므로, 후반부로 갈수록 컨텍스트(context)가 혼탁해져 정밀도가 떨어짐
• 「어디까지 진행되었는지」「다음에 무엇을 할지」가 루프의 내부 상태에만 존재하여, 외부에서 폭주를 멈출 수 없음
• 작업을 수행한 본인(동일한 컨텍스트)에게 「이게 맞나요?」라고 물어도, 제 체감상으로는 거의 오류를 찾아내지 못함

반대로, 되돌아가기(cycle)를 가질 수 없는 일방통행 구조(이른바 DAG)에도 한계가 있습니다. 현실의 업무에는 「검증에서 탈락하면 다시 하기」, 「인간의 확인 대기」와 같은 되돌아가기가 반드시 포함되므로, 일방통행만으로는 표현할 수 없습니다.

여기서 나오는 해답이 그래프입니다. 설계 원칙은 한마디로 말할 수 있습니다.

코드가 화살표(제어 흐름)를 담당하고, AI가 알맹이(각 작업의 내용)를 담당한다.

어떤 순서로 무엇을 할지, 실패하면 어디로 돌아갈지는 인간이 코드로 고정하고, AI에게는 각 노드 안의 지적 작업(조사·집필·판단)만 시키는 분담 방식입니다.

거창한 프레임워크가 없어도 그래프의 골격은 Python의 함수와 분기만으로 작성할 수 있습니다. 만드는 것은 「조사 → 검증 → 답변, 검증 실패 시 조사로 돌아감 (최대 3회)」라는 플로우입니다.

코드로 작성하면 다음과 같을 것입니다.

def call_llm(prompt: str) -> str:
    """사용 중인 LLM API를 호출하는 함수 (Claude API나 OpenAI API 등으로 교체)"""
    ...
    ...

포인트는 세 가지입니다.

• 제어 흐름이 모두 코드 측에 있습니다. 「검증 실패 시 조사로 돌아감」, 「3회에서 중단함」을 LLM이 결정하지 않습니다. for 문과 if 문이 화살표 그 자체입니다.
• 검증(verify)을 작업한 문맥과 분리합니다. research 대화의 연속으로 「맞나요?」라고 묻는 것이 아니라, 완전히 새로운 입력으로 별도의 호출을 통해 검품하게 합니다.
• 상한을 초과하면 인간에게 에스컬레이션(escalation)합니다. 무한 재시도(retry)로 폭주하게 두지 않습니다.

참고로 verify의 OK 판정을 문자열 전방 일치로 하는 것은 최소 구성이라서 생략한 것이며, 실제 운용에서는 JSON 등의 구조화된 출력(structured output)으로 ok와 feedback을 반환하게 하는 것이 더 안전합니다.

이것을 보고 「그저 상태 전이(state transition)일 뿐 아닌가?」라고 생각하셨다면, 맞습니다. graph engineering의 실체는 정말 이것뿐이며, (현재 상태, 결과) → 다음 상태를 결정하고 있을 뿐입니다.

노드나 분기가 늘어나면 LangGraph와 같은 프레임워크를 사용하는 선택지도 있습니다. 위 코드와의 대응은 단순하여, 각 함수가 「노드」가 되고, for 문과 if 문이 「에지(edge, 조건부 전이)」의 선언으로 바뀝니다. 상태의 영속화(persistence), 중간에 인간이 개입하는 human-in-the-loop, 실행의 시각화가 필요해지면 프레임워크를 사용할 차례이며, 그전까지는 순수 코드로도 충분하다는 것이 제 감각입니다.

그래프 설계의 실용적인 형태로 자주 소개되는 것이 「다이아몬드형」입니다. 업무를 분할하여 여러 AI에게 동시에 조사를 시키고, 다른 AI가 검품하며, 하나로 통합한 뒤, 마지막에 사람이 승인하는 흐름입니다.

예를 들어 「대량의 종이 청구서를 읽어 들여 회계 시스템에 등록한다」라면, 다음과 같은 그래프가 됩니다.

포인트는, 한 장을 통째로 하나의 AI에게 맡기지 않고 항목별로 전용 AI에게 분할하는 것(그 편이 정확도가 높습니다), 검품을 읽기 당사자가 아닌 다른 이에게 시키는 것, 그리고 인간의 승인을 불가역적(irreversible) 조작 직전에만 두는 것입니다.

이것은 책상 위의 예시가 아니라, 제가 관여하고 있는 업무 시스템에서도 (도메인은 다르지만) 거의 이 형태의 그래프가 실무에서 가동되고 있습니다. 항목별 서브그래프(subgraph)를 병렬로 실행하고, 검품 노드(node)에서 NG라면 되돌리고(rollback), 마지막에는 담당자의 확인 화면에서 승인합니다.

그리고 눈치채신 분도 있겠지만, 지금까지 살펴본 ◯◯ engineering은 전부 이 하나의 그래프 안에 공존하고 있습니다. 어디가 무엇에 해당하는지 정리하면 다음과 같습니다.

prompt engineering— 각 읽기 노드 안의 지시문. 「명세」 담당 AI에는 명세 추출에만 특화된 프롬프트(prompt)를 작성합니다 -
context engineering— 각 노드에 무엇을 전달할 것인가. 읽기 노드에는 이미지와 담당 항목의 정의만, 검품 노드에는 읽기 결과와 검산 규칙만 전달하며, 다른 노드의 대화 이력은 가져오지 않습니다 -
harness engineering— 모델 외부의 안전장치. 기계적 검산이라는 검증, 도구의 할당, 「등록 직전에는 인간에게」라는 정지 조건입니다 -
loop engineering— 「NG: 다시 읽기」 화살표 주변. 무엇을 피드백(feedback)으로 돌려줄 것인가, 몇 번 만에 포기하고 인간에게 넘길 것인가 -
graph engineering— 이 흐름도 전체. 누구에게, 어떤 순서로, 어디서 인간이 볼 것인가

즉, 5가지 기법은 레벨 구분이나 세대 교체가 아니라, **동일한 시스템의 서로 다른 레이어(layer)**이며, 실제 프로덕트에서는 모두 동시에 사용하게 됩니다.

이 패턴을 돌릴 때의 철칙이 3가지 있습니다.

• 자신의 업무 검품을 본인에게 시키지 않는다. "AI는 자신의 실수 대부분을 놓친다"라는 원문 기사의 주장과 저의 체감도 일치합니다.
• 인간의 승인은 모든 단계가 아니라, 되돌릴 수 없는 조작의 직전에만 둔다. 모든 단계에 승인을 넣으면 자동화의 의미가 없어집니다.
• 루프(loop)에는 반드시 횟수 상한을 둔다.

단, 과신은 금물입니다. 이 구도에 대해 "그래프로 살 수 있는 것은 『업무 분담의 폭』이지, 『판단력의 향상』이 아니다" (의역)라는 지적이 있는데, 이는 실제로 사용해 보면 정말 그렇다고 느낍니다. 병렬화를 통해 속도는 빨라지지만, 똑똑해지지는 않습니다. 그렇기 때문에 검품과 승인 노드를 플로우(flow)에 포함해 두어야 하는 것입니다.

• ◯◯ engineering의 변천은 지시문(prompt) → 전달하는 정보(context) → 실행 환경(harness) → 루프(loop) → 워크플로우(workflow) 전체로, 관심사가 준비 단계 쪽으로 옮겨온 역사
• graph engineering이란, AI 에이전트(agent)의 업무를 「노드 = 작업, 엣지(edge) = 전이」의 흐름도로 설계하는 것. 구조는 고전적인 상태 머신(state machine)과 같으며, 새로운 점은 노드에 에이전트 전체를 넣을 수 있게 되었다는 것
• 설계 원칙은 "코드가 화살표를, AI가 원(node)을 담당한다". 검증은 다른 AI에게, 승인은 불가역적 조작 직전에, 루프에는 상한을

「graph engineering」이라는 용어 자체는 굳이 쫓지 않아도 괜찮습니다. 다음 달에는 다른 이름이 되어 있을지도 모르지만, 위의 설계 원칙은 당분간 사용할 수 있습니다.

graph engineering 파트는 2026년 7월 X에 공개된 다음 3편의 기사(모두 X의 Article 기능을 통한 장문 게시물)를 소재로 하고 있습니다. 인용된 일본어 번역은 모두 필자의 의역입니다.

• David K 「State machines in 2 minutes」(2026/7/20). 루프도 그래프도 상태 머신의 다른 표현이라는 정리
• Sydney Runkle & Harrison Chase 「3 Years of Graph Engineering」(2026/7/22). LangGraph 3년간의 설계 학습
• Machina 「How to master graph engineering (Full Course)」(2026/7/22). 다이아몬드형 패턴과 실무의 철칙