개발자혜수 홈으로 이동개발자혜수

Hyesu's Blog

테크블로그

공부하면서 기록을 남겨요

AI 에이전트를 만드는 4단계 — Prompt, Context, Loop, Graph Engineering 쉽게 이해하기

2026.08.17. AI

요즘 AI 에이전트 관련 글을 읽다 보면 “프롬프트 엔지니어링”, “컨텍스트 엔지니어링”, “루프 엔지니어링”, “그래프 엔지니어링”이라는 말이 계속 나와요. 다 비슷비슷해 보이는데 정확히 뭐가 다른 건지 헷갈려서, 앤트로픽 공식 글들을 근거로 하나씩 정리해봤어요.

먼저 결론부터 말하면, 이 네 가지는 AI에게 일을 맡길 때 “무엇을 정교하게 다듬을 것인가”가 점점 넓어지는 순서예요.

단계 무엇을 다듬나 한 줄 비유
Prompt Engineering AI에게 주는 지시문 한 장 신입사원에게 업무 지시서 잘 써주기
Context Engineering AI가 매 순간 보고 있는 정보 전체 책상 위에 필요한 자료만 딱 올려두기
Loop Engineering AI가 반복 작업하는 절차 요리사가 간 보고 다시 조리하는 루틴
Graph Engineering 여러 작업을 역할별로 나누고 연결하는 구조 회사 조직도처럼 업무를 부서별로 쪼개기

하나씩 쉽게 풀어볼게요.

1. Prompt Engineering — 지시문을 잘 쓰는 기술

프롬프트 엔지니어링은 AI에게 주는 지시문(prompt) 한 장을 최대한 명확하게 쓰는 기술이에요. 앤트로픽 공식 문서는 이걸 아주 쉬운 비유로 설명해요.

Claude를 “우리 회사 관행은 전혀 모르는, 똑똑하지만 갓 입사한 신입사원”이라고 생각하세요.

똑똑한 사람이라도 맥락을 모르면 엉뚱한 결과를 낼 수 있죠. 그래서 지시를 구체적으로, 명확하게 줘야 해요.

대표적인 기법들

이 기법들은 지시문 한 번을 잘 쓰는 데 집중해요. 그런데 AI가 여러 단계에 걸쳐 도구를 쓰고, 대화가 길어지고, 파일을 읽고 쓰기 시작하면 — 지시문 하나만 잘 써서는 부족해져요. 여기서 다음 단계인 컨텍스트 엔지니어링이 필요해져요.

2. Context Engineering — AI가 보는 정보 전체를 관리하는 기술

컨텍스트 엔지니어링은 앤트로픽이 “프롬프트 엔지니어링의 자연스러운 다음 단계”라고 설명하는 개념이에요. 지시문 한 장뿐 아니라, AI가 답을 낼 때 실제로 보고 있는 모든 정보(시스템 지시사항, 도구 목록, 대화 기록, 파일 내용 등)를 어떻게 정리해서 보여줄지를 다루는 기술이에요.

왜 필요할까 — Context Rot

사람도 책상에 자료가 산더미처럼 쌓여 있으면 오히려 필요한 걸 못 찾잖아요. AI도 비슷해요. 앤트로픽은 이걸 컨텍스트 부패(Context Rot)라고 불러요 — 넣어주는 정보(토큰)가 많아질수록, 오히려 AI가 정말 중요한 내용을 놓치는 정확도가 떨어지는 현상이에요.

그래서 컨텍스트는 “무조건 많이”가 아니라 한정된 자원으로 다뤄야 해요. 정보 하나를 추가할 때마다 AI의 “집중력 예산”을 쓰는 셈이거든요.

대표적인 기법들

3. Loop Engineering — 스스로 확인하고 반복하는 절차를 설계하는 기술

루프 엔지니어링은 “AI가 멈출 조건을 만족할 때까지 작업을 반복하는 절차”를 설계하는 기술이에요. Claude Code 팀은 이 절차를 네 단계로 정의해요.

1. Gather context  (상황 파악)   — 지금 뭘 알아야 하는지 확인한다
2. Take action     (행동 실행)   — 코드 수정, 파일 생성 같은 실제 작업을 한다
3. Verify work     (결과 검증)   — 테스트를 돌리거나 결과를 스스로 확인한다
4. Repeat          (필요시 반복) — 검증에 실패하면 1번부터 다시

요리사가 요리를 하고, 맛을 보고, 간이 부족하면 다시 조리하는 과정과 똑같아요. 핵심은 3번 “Verify work”예요 — AI가 스스로 결과를 확인하는 단계가 없으면, 반복해봤자 품질이 좋아지지 않고 제자리걸음만 해요. 검증 방법에는 린트/테스트 같은 규칙 기반 확인, 스크린샷으로 보는 시각적 확인, 다른 AI 모델이 품질을 평가하는 “LLM 심사” 등이 있어요.

루프의 네 가지 종류

종류 언제 실행되나 예시
Turn-based 사용자가 입력할 때마다 챗봇 대화
Goal-based 목표를 달성할 때까지 “테스트가 다 통과할 때까지 코드 고쳐”
Time-based 정해진 시간마다 매일 아침 리포트 생성
Proactive 조건이 감지되면 자동으로 에러 로그 발생 시 자동 대응

루프에는 반드시 “멈추는 조건”이 있어야 해요. 종료 조건이 불명확하면 AI가 일찍 멈춰버리거나, 반대로 끝없이 맴돌 수 있거든요.

4. Graph Engineering — 작업을 나누고 연결하는 구조를 설계하는 기술

여기까지는 AI 하나가 얼마나 똑똑하게 일하는지에 대한 이야기였어요. 그런데 작업이 커지면 질문이 달라져요 — “이 많은 일을 정말 AI 하나가 다 처리하는 게 맞을까?”

단일 에이전트의 한계 — 백엔드 개발자 관점에서

이건 백엔드 개발에서 익숙한 문제예요. 회원가입, 결제, 알림, 재고 관리를 전부 처리하는 함수 하나를 상상해볼게요.

function handleEverything(request) {
  // 회원가입 로직 200줄
  // 결제 로직 300줄
  // 알림 로직 150줄
  // 재고 관리 로직 250줄
  // 그 사이를 넘나드는 if-else 분기 수십 개...
}

이런 “갓 함수(God Function)“에서 결제가 실패하면 무슨 일이 생길까요?

그래서 백엔드에서는 이걸 회원가입 서비스, 결제 서비스, 알림 서비스로 나누고, 그 사이를 API 호출이나 이벤트로 연결하죠. AI 에이전트도 똑같은 문제를 겪어요. 하나의 에이전트가 계획·검색·코드 작성·검증을 전부 떠맡으면, 실패했을 때 어느 단계가 문제였는지 파악하기 어렵고, 컨텍스트도 뒤죽박죽 섞여서 앞서 본 Context Rot이 더 빨리 와요.

그래서 나온 게 그래프 엔지니어링

그래프 엔지니어링은 하나의 AI에게 모든 일을 맡기는 대신, 작업을 여러 조각(노드)으로 나누고 그 사이를 잇는 이동 규칙(엣지)을 설계하는 방식이에요. 네 가지 요소로 이루어져요.

요소 의미 백엔드 비유
Node(노드) 작업 하나의 단위 (LLM 호출, 도구 실행 등) 함수 하나, 마이크로서비스 하나
Edge(엣지) 다음 노드로 넘어가는 연결선 API 호출, 이벤트 전달
State(상태) 지금까지 쌓인 데이터/진행 상황 요청 객체, DB의 현재 행 값
Condition(조건) 어느 엣지로 갈지 판단하는 기준 if (결제성공) 배송준비 else 결제실패

이 구조는 사실 백엔드에서 흔히 쓰는 **상태 머신(State Machine)**과 거의 똑같아요. 주문 처리를 예로 들면 이렇게 그릴 수 있어요.

[결제대기] --(결제 성공)--> [배송준비] --(출고 완료)--> [배송중] --(수령 확인)--> [배송완료]
     |
     └--(결제 실패)--> [결제실패]

각 대괄호가 노드, 화살표가 엣지, 화살표 위 조건이 Condition, 지금 어느 칸에 있는지가 State예요. 이 구조 그대로를 AI 에이전트에 적용한 게 그래프 엔지니어링이에요. (draft에 적어두신 것처럼, 진행 경로가 상황에 따라 달라진다는 점에서 다이나믹 워크플로우와 개념이 비슷해요 — 그래프가 곧 “상황별로 달라지는 작업 흐름”인 거예요.)

참고: “그래프 엔지니어링”이라는 용어 자체는

한 가지 짚고 넘어갈게요. “그래프 엔지니어링”이라는 이름 자체는 앤트로픽이 공식적으로 쓰는 용어는 아니에요. 대신 앤트로픽은 Building Effective Agents라는 글에서 같은 개념을 워크플로우 패턴이라는 이름으로 다섯 가지로 정리해요. 이게 사실상 그래프의 각기 다른 모양이에요.

패턴 그래프 모양 언제 쓰나
Prompt Chaining 노드가 일렬로 연결 (A → B → C) 순서가 고정된 단계로 나눌 수 있을 때
Routing 조건에 따라 갈라지는 분기 입력 유형별로 다른 처리가 필요할 때
Parallelization 여러 노드가 동시에 실행 후 합류 독립적인 작업을 동시에 처리해도 될 때
Orchestrator-Workers 중심 노드가 작업자 노드들에게 동적으로 업무 분배 필요한 하위 작업을 미리 예측할 수 없을 때
Evaluator-Optimizer 두 노드가 서로 피드백을 주며 순환 명확한 평가 기준이 있고 반복 개선이 유효할 때

실제로 LangGraph 같은 프레임워크가 이 패턴들을 정확히 “노드-엣지-상태-조건”이라는 문자 그대로의 그래프 구조로 구현하고 있어요. 그래서 draft에 적어주신 표현(“Node-Edge-State-Condition”)은 정확히 이 프레임워크들이 쓰는 용어예요.

워크플로우 vs 자율 에이전트

앤트로픽은 이 글에서 중요한 구분을 하나 더 해요.

앤트로픽의 원칙은 명확해요 — “가장 단순한 해결책부터 시작하고, 성능 개선이 확실할 때만 복잡도를 높여라.” 즉, 굳이 자율 에이전트나 복잡한 그래프가 필요 없는 일까지 무리해서 에이전트로 만들 필요는 없어요.

정리하며

네 가지를 한 문장씩으로 요약하면 이래요.

이 네 가지는 순서대로 쌓이는 관계예요 — 지시문이 잘못되면 컨텍스트도 소용없고, 컨텍스트가 뒤죽박죽이면 아무리 루프를 돌려도 품질이 안 좋고, 루프 하나로 감당 안 되는 큰 작업은 그래프로 쪼개야 해요. 그래서 실제로 복잡한 AI 에이전트를 설계할 때는 이 네 가지를 함께 고려하게 되는 것 같아요.

다음에 더 파볼 것

참고한 글

목록으로 돌아가기

댓글