Graph Engineering

AI 엔지니어링 노트

Graph Engineering

Prompt에서 Graph까지 — AI 시대 엔지니어링 5단계 진화와 실전 적용

TL;DR · 오늘의 결론

결과를 만드는 건 모델이 아니라 설계다

1

AI 아웃풋의 품질 = 모델 성능 × 설계 수준. 모델은 모두에게 동일하게 주어진다.

2

설계는 5단계로 진화했다 — Prompt → Context → Harness → Loop → Graph

3

작업의 복잡도가 설계 수준을 결정한다. 낮은 단계를 건너뛰면 상위 단계는 더 복잡하게 실패한다.

4

필요한 건 새 도구가 아니라, 우리가 이미 쓰는 Jira · Confluence · Git을 설계 부품으로 다시 보는 것

---

01 같은 모델, 다른 결과 — 차이는 설계에서 온다

2023 → 2026, 질문이 바뀌었다

"그냥 물어보면 된다"에서 "무엇을, 어떤 순서로, 누구에게 맡길지 설계해야 한다"로 질문 자체가 바뀌었습니다. 모델 성능은 모두에게 동일하게 주어집니다. 차이를 만드는 건 그 앞뒤를 감싸는 설계입니다.

팀 현장의 현실

오타 수정 티켓 하나와, 여러 도메인이 얽힌 Epic 하나는 필요한 설계 수준이 완전히 다릅니다. 하나의 방식을 모든 작업에 똑같이 적용하면 늘 과하거나, 늘 부족합니다.

이 글의 목표 — "AI에게 어떻게 시킬까"가 아니라, "이 작업엔 어느 수준의 설계가 필요한가"를 판단하는 기준을 갖는 것.

02 AI 엔지니어링, 5단계의 진화

레버리지는 점점 모델 "바깥"으로 이동합니다 — 요청 문구 한 줄에서, 여러 에이전트로 이루어진 조직 설계까지.

시기	계층	엔지니어링 대상	핵심 질문	역할 비유
2023-24	Prompt	모델에 보내는 요청 문구	"잘 요청하고 있는가?"	운영자
2024	Context	모델이 접근 가능한 정보	"올바른 정보를 갖고 있는가?"	편집자
2025	Harness	도구 · 메모리 · 복구 구조	"무엇으로 작업을 뒷받침하는가?"	도구 제작자
2026 초기	Loop	단일 에이전트의 반복 사이클	"언제 검사하고 멈출 것인가?"	시스템 설계자
2026 중기	Graph	다중 에이전트 간 조정	"누가·무엇을·어떤 순서로 하는가?"	조직 설계자

03 5단계, 하나씩 뜯어보기

STEP 1 · 2023-2024

Prompt Engineering

탄생 배경

초기 LLM 시대, 모델에게 보내는 '요청 문구' 자체가 결과를 바꿀 수 있는 유일한 조절 지점이었다.

정의

역할 부여, 예시 제공, 출력 형식 지정 등으로 질문·지시문을 최적화해 원하는 출력을 끌어내는 기법.

장점

즉시 적용 가능, 추가 인프라 불필요, 학습 곡선이 낮아 누구나 바로 쓸 수 있다.

단점

재현성이 낮고, 정보 부족 문제는 해결하지 못하며, 작업이 복잡해지면 프롬프트만으로는 한계가 뚜렷하다.

언제 쓰나 — 1회성 질의, 단순 텍스트 생성, 최하 난이도 작업 (오타 수정, 간단 문의 응대)

STEP 2 · 2024

Context Engineering

탄생 배경

컨텍스트 윈도우 확장과 RAG 확산으로, "무엇을 물어보는가"보다 "무엇을 보여주는가"가 결과를 좌우하게 됐다.

정의

모델이 접근할 수 있는 정보 — 문서, 코드, 이력 — 를 전략적으로 선택·정리·주입하는 작업.

장점

정확도와 최신성이 오르고, 근거 없는 환각(hallucination)이 크게 줄어든다.

단점

좋은 컨텍스트를 고르는 데 비용이 들고, 과도한 정보를 밀어 넣으면 오히려 노이즈로 성능이 떨어진다.

언제 쓰나 — 관련 코드·로그가 필요한 하 난이도 버그 수정, 특정 티켓 맥락 이해가 핵심인 작업

STEP 3 · 2025

Harness Engineering

탄생 배경 · 정의

에이전트가 도구를 스스로 호출하기 시작하며, 그 주변 지원 구조 설계가 중요해졌다. 컨텍스트·도구·오케스트레이션·상태관리·평가·복구, 6가지 요소로 에이전트를 뒷받침하는 틀을 설계하는 일.

장점

신뢰성이 오르고, 다양한 도구·다중 세션에 걸친 작업이 가능해지며, 실패해도 복구할 수 있다.

단점

설계·유지보수 복잡도가 늘고, 단순 작업엔 처음부터 과한 투자로 느껴질 수 있다.

언제 쓰나

Jira · Git · 테스트 도구를 넘나드는 상 난이도 작업, 세션이 길게 이어지는 작업

STEP 4 · 2026 초기

Loop Engineering

탄생 배경 · 정의

단일 에이전트가 "언제 멈출지" 스스로 판단해야 하는 자동화 요구가 늘며 등장. 발견 → 계획 → 실행 → 검증 → 반복의 사이클을 설계하는 일. 핵심은 자체 검증이 아닌 독립적인 검증자다.

장점

명확한 목표에 대해 자율적으로 끝까지 수행 — Claude Code 등 코딩 에이전트의 기본 동작 방식이 바로 이것.

단점

병렬 작업·전문성 분리에는 한계가 있고, 검증자가 없으면 스스로를 과신하기 쉽다.

언제 쓰나

목표와 완료 기준이 명확한 순차 작업(기능 구현 → 테스트 → 수정 반복), 중 난이도 티켓

STEP 5 · 2026.07 ~

Graph Engineering

탄생 배경

2026년 7월 18-19일, X(트위터)에서 논의가 결화됨. Peter Steinberger의 질문에서 시작됐다 — "우리는 여전히 루프를 말하는가, 아니면 그래프로 이동했는가?"

정의

서로 다른 전문성을 가진 여러 노드(에이전트·단계) 간의 조정(coordination)을 설계하는 일. Loop의 대체가 아니라 확장이다.

핵심 문장 — "단일 루프는, 자기 자신에게 돌아가는 엣지를 가진 1노드 그래프다."

04 그래프는 정확히 세 부분으로 이루어진다

Node · 노드

실제 작업을 수행하는 단위. 전문화된 에이전트(연구자·작가·검토자) 또는 결정적 단계(함수·도구 호출). 각 노드는 하나의 명확한 역할을 갖는다.

Edge · 엣지

노드 간 라우팅. 직선형(A→B)·조건부(통과/실패)·팬아웃(동시 시작)·팬인(결과 통합) 네 가지 형태가 있다.

Shared State · 공유 상태

엣지를 따라 흐르는 객체. 작업 내용, 초안, 검토 결과, 메타데이터 등 모든 노드가 읽고 쓸 수 있다.

예시 · 스타터 그래프

연구자 노드
작업 → 노트

→

작가 노드
노트 → 초안

→

검토자 노드
초안 → 판정

→

✓ 통과 → 배포 ✗ 실패 → 작가 노드로 피드백

05 루프로 충분한가, 그래프가 필요한가

신호	Loop로 충분	Graph가 필요
작업의 형태	명확한 끝이 있는 단일 작업	서로 다른 전문성이 필요한 단계들
병렬화	단계가 순차적	여러 작업을 동시에 수행 후 통합
도구·모델	전체에서 동일	단계별로 다른 도구셋·모델
제어 흐름	한 에이전트가 자유롭게 이동	명시적·감시 가능한 라우팅 필요
검증	에이전트가 자기 출력을 검사	별도의 검토자 노드가 필요

과잉설계 예시 — "PDF 요약". 페칭·청킹·요약·검토·포매팅, 5개 노드 그래프는 과하다. 단일 루프가 더 빠르고 저렴하다.

적절한 예시 — "데일리 시장 리포트". 5개 소스 병렬 리서치 → 통합 → 초안 → 회의적 검토자가 점수 부여. 각 노드가 단일 루프로는 불가능한 역할을 한다.

06 Graph Engineering, 정말 새로운가?

"그래프 엔지니어링이 무엇인지 아직도 모르겠고… 그냥 LangGraph인가?"— Harrison Chase, LangGraph 창시자

"'그래프'는 수십 년 된 컴퓨터 과학이다."— David K. Piano, XState 창시자

기존 기술 · 이미 있던 것들

LangGraph(StateGraph) · Microsoft AutoGen GraphFlow · Google ADK 2.0 · A2A 프로토콜

그럼에도 의미 있는 것

공유 용어(노드·엣지·상태) 확립, "프레임워크 세부사항이 아니다"라는 인식 확산, 점점 더 많은 팀의 실제 필요.

결론 — "단어는 선택적이지만, 전환은 실제다." 단일 루프 전문성에서, 작업이 강제할 때 조정된 특화 노드로 이동하는 흐름 자체는 진짜다.

07 그래프를 그리기 전에, 8가지를 먼저 확인하라

1루프로 유지할 수 있는지 먼저 시도한다

2실제 전문성이 다른 경우만 노드로 분리한다

3엣지(라우팅)부터 냅킨에 스케치한다

4공유 상태를 명시적으로 설계한다 — 누가 어디에 쓰는가

5검토자 노드에 권한을 준다 — 별도의 읽기 전용 검증자

6장애를 격리한다 — 한 노드 실패가 전체를 오염시키지 않도록

7프레임워크를 선택한다 — LangGraph, Google ADK, MS Agent Framework 등

8지출 상한선을 정한다 — 그래프는 곧 병렬 토큰 소모다

---

08 실전 적용 — Jira · Confluence · Git

Jira 티켓 복잡도가 곧 설계 수준이다

복잡도	예시 티켓	추천 엔지니어링	이유 · 핵심
최하	오타·문구 수정, 단순 문의 응대	Prompt	컨텍스트 없이 바로 요청해도 충분하다
하	단일 파일 버그 수정	Context	관련 코드 + Jira 설명을 정확히 넣어주는 게 핵심
중	단일 기능 개발 (PR 1건)	Loop	탐색 → 계획 → 구현 → 검증(리뷰) 반복이면 충분 — Claude Code 기본 동작
상	여러 모듈 연동, 구조 리팩토링	Harness	여러 도구(Jira·Git·테스트) + 메모리 + 복구까지 갖춘 환경 필요
최상	Epic, 여러 팀·도메인 관여	Graph	역할별 노드 분리 + 병렬 진행 + 독립 검토 노드 필요

낮은 단계를 건너뛰지 마라 — 약한 루프는 약한 노드를, 약한 노드는 약한 그래프를 만든다.

이미 손에 있는 Graph의 부품

Node · 노드	→ Jira 하위태스크 / 담당자별 역할 (백엔드·프론트·QA·문서화)
Edge · 엣지	→ 이슈 워크플로우 전이 + PR (리뷰 통과 → 배포, 실패 → 재작업으로 조건부 라우팅)
Shared State · 공유 상태	→ Jira 티켓(설명·댓글·체크리스트), Confluence 문서
Context 소스	→ Confluence 요구사항·설계 문서
독립 검토자 노드	→ PR 코드 리뷰어

실전 팁 — Claude Code + Atlassian MCP로 티켓·문서를 자동으로 불러오면, 컨텍스트 엔지니어링을 도구가 대신 해준다.

예시 — "신규 PG 연동 Epic"

1. 요구사항 문서화
Confluence (Context)

→

2. Epic 분해
Jira 하위태스크 (Node 정의)

→

3. 병렬 진행
백엔드·프론트·QA (Fan-out)

→

4. PR 리뷰
독립 검토자 (Edge)

→

5. 통합 테스트
Fan-in, 실패 시 피드백

→

6. Epic 완료
배포

이건 이미 많은 팀이 하고 있는 일이다. 다만 이제는 "왜 이렇게 나누는지" 설명할 수 있다.

기억할 세 가지

1 · 복잡도가 설계를 결정한다 2 · 그래프는 만능이 아니다 3 · 우리에겐 이미 Jira·Confluence·Git이 있다

Prompt부터 Graph까지, 낮은 단계부터 순서대로 숙달하라. 루프로 충분하면 루프를 써라 — 과잉설계가 가장 흔한 실수다. 그리고 이것이 곧 Graph Engineering의 Node·Edge·State다.