프롬프트 엔지니어링부터 그래프 엔지니어링까지, AI 에이전트 설계는 어떻게 달라지는가

AI 엔지니어링 분야에서 프롬프트 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링이라는 용어가 잇따라 등장하고 있습니다. 세 가지 모두 AI 에이전트를 설계하는 방법을 이야기하지만, 서로 같은 의미로 사용해서는 안 됩니다.

핵심은 간단합니다. 프롬프트는 하나의 모델 응답을 제어하고, 루프는 하나의 에이전트가 반복적으로 행동하는 과정을 제어하며, 그래프는 여러 에이전트가 어떻게 조직되고 협력할지를 제어합니다.

따라서 상위 단계로 넘어간다고 해서 기존 기술이 사라지는 것은 아닙니다. 프롬프트는 루프 안에서도 필요하고, 루프는 그래프를 구성하는 기본 요소가 됩니다.

이번 글에서는 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링으로 이어지는 흐름을 살펴보고, 각각 어떤 문제를 해결하는지와 언제 상위 단계로 넘어가야 하는지 정리합니다.

반응형

AI 에이전트 설계는 하나의 프롬프트에서 시작한다

AI 시스템의 설계 범위는 점점 넓어지고 있습니다.

가장 기본적인 단계에서는 모델에게 어떤 지시를 전달할 것인지가 중요합니다. 하지만 AI가 단순한 질문에 답하는 수준을 넘어 여러 단계를 스스로 수행하게 되면 프롬프트만으로는 부족해집니다.

자료에서는 이를 다음과 같은 계층으로 설명합니다.

1. 프롬프트 엔지니어링
2. 컨텍스트 엔지니어링
3. 하네스 엔지니어링
4. 루프 엔지니어링
5. 그래프 엔지니어링

각 단계는 이전 단계의 기능을 없애는 것이 아니라 그 위에 새로운 제어 범위를 추가합니다.

프롬프트가 하나의 응답을 제어한다면 루프는 에이전트의 행동 사이클을 제어하고, 그래프는 여러 에이전트의 조직과 작업 흐름을 제어하는 방식입니다.

1. 프롬프트 엔지니어링: 하나의 응답을 설계하는 단계

프롬프트 엔지니어링은 하나의 모델 호출에 어떤 지시를 전달할지 작성하고 구조화하는 작업입니다.

기본적인 과정은 사람이 프롬프트를 작성하고, 모델의 응답을 확인한 다음, 결과에 따라 프롬프트를 수정하는 방식입니다.

Anthropic의 가이드에서는 시스템 프롬프트를 배경 정보, 지시사항, 도구 사용 지침, 출력 형식 등으로 구분하고 XML 태그나 마크다운 헤더를 활용해 구조화하는 방법을 제시합니다.

여기서 중요한 점은 간결함이 반드시 짧음을 의미하지 않는다는 것입니다.

필요한 행동을 충분히 지정하면서도 불필요한 정보는 넣지 않는 것이 핵심입니다.

다만 이 방식에는 한계가 있습니다.

사람이 매번 결과를 확인할 수 있다면 프롬프트만으로도 충분할 수 있습니다. 하지만 작업량이 많아지거나 여러 단계의 작업을 자동으로 수행해야 한다면 상황이 달라집니다.

예를 들어 한 단계의 결과가 다음 단계의 입력으로 자동 전달되고, 사람이 모든 결과를 직접 확인할 수 없다면 단순히 좋은 프롬프트를 작성하는 것만으로는 충분하지 않습니다.

프롬프트 자체가 나빠진 것이 아니라 AI가 작동하는 주변 환경이 달라졌기 때문입니다.

2. 컨텍스트 엔지니어링: 무엇을 모델에게 보여줄 것인가

프롬프트 엔지니어링 다음에는 컨텍스트 엔지니어링이 등장합니다.

여기서 관심사는 단순히 "어떤 문장을 입력할 것인가"가 아닙니다.

더 중요한 질문은 "모델의 컨텍스트 창에 어떤 정보를 넣을 것인가"입니다.

모델이 사용할 수 있는 컨텍스트는 무한하지 않습니다. 따라서 모든 정보를 넣는 것이 좋은 방법은 아닙니다.

컨텍스트 엔지니어링에서는 제한된 토큰 안에서 어떤 정보가 실제로 유용한지를 판단하고, 모델의 제약 조건과 정보의 효용 사이에서 균형을 맞추는 것이 중요합니다.

즉, 프롬프트가 지시사항을 설계하는 문제라면 컨텍스트 엔지니어링은 모델이 판단할 수 있도록 어떤 정보 환경을 제공할 것인지 설계하는 문제로 볼 수 있습니다.

3. 하네스 엔지니어링: 에이전트가 움직이는 환경을 설계한다

하네스 엔지니어링은 하나의 에이전트가 실제로 작동하는 환경을 다룹니다.

여기에는 다음과 같은 요소가 포함됩니다.

• 파일
• 도구
• 메모리
• 피드백

즉, 모델에게 지시를 전달하는 것에서 한 단계 더 나아가 에이전트가 작업을 수행할 수 있는 환경 자체를 구성하는 것입니다.

이 단계가 중요한 이유는 에이전트가 단순히 답변을 생성하는 존재가 아니라 파일을 확인하고, 도구를 사용하고, 이전 정보를 활용하고, 결과에 대한 피드백을 받는 시스템으로 확장되기 때문입니다.

4. 루프 엔지니어링: 한 번의 응답에서 반복적인 행동으로

루프 엔지니어링은 하네스보다 한 단계 위에서 에이전트가 반복적으로 관찰하고, 행동하고, 확인하고, 필요하면 복구하는 과정을 설계합니다.

특히 코딩 에이전트에서는 단순히 프롬프트를 잘 작성하는 것보다 에이전트가 문제를 해결할 수 있도록 목표와 도구, 반복 과정을 설계하는 것이 중요해집니다.

자료에서는 루프 엔지니어링을 구성하는 요소로 다음을 제시합니다.

자동화

사람이 계속 지켜보지 않아도 탐색과 분류 작업을 수행할 수 있도록 일정이나 이벤트를 활용합니다.

워크트리

여러 에이전트가 동시에 작업할 때 서로 같은 파일을 수정하는 문제를 방지하기 위해 작업 영역을 분리합니다.

스킬

프로젝트에 필요한 지식을 매번 대화에서 설명하는 대신 SKILL.md와 같은 형태로 정리해 반복적으로 사용할 수 있도록 합니다.

플러그인과 커넥터

MCP 기반으로 이슈 트래커, 데이터베이스, 스테이징 API 등 외부 시스템에 접근할 수 있도록 합니다.

서브 에이전트

코드를 작성한 모델이 자신이 만든 결과를 지나치게 긍정적으로 평가할 가능성을 줄이기 위해 작성 역할과 검증 역할을 분리합니다.

상태

모델은 실행이 끝난 뒤 대화 내용을 계속 기억하지 못할 수 있기 때문에 마크다운 파일이나 보드처럼 대화 외부에 상태를 저장합니다.

이러한 요소들이 결합되면서 에이전트는 단순히 한 번 답변하는 모델이 아니라 반복적으로 작업을 수행하는 시스템이 됩니다.

루프에서 가장 중요한 것은 반복보다 종료 조건이다

루프 엔지니어링에서 특히 중요한 부분은 반복 자체가 아닙니다.

자료에서는 종료 조건(stop condition)이 핵심이라고 설명합니다.

예를 들어 에이전트가 계속 코드를 수정한다고 가정해보겠습니다.

"계속 시도한다"는 조건만 있다면 에이전트는 언제 작업이 완료됐는지 판단하기 어렵습니다.

따라서 테스트나 스키마, 평가 기준, 별도의 모델과 같은 방법으로 무엇이 완료 상태인지 기계적으로 확인할 수 있어야 합니다.

종료 조건이 없다면 에이전트는 작업이 완료돼서 멈추는 것이 아니라 토큰 예산이 소진될 때까지 계속 실행할 수 있습니다.

자료에서 제시한 /loop와 /goal 역시 이러한 반복 실행과 종료 조건의 차이를 보여줍니다.

/loop는 일정한 주기로 다시 실행하는 방식이고, /goal은 작성된 조건이 실제로 충족될 때까지 실행하면서 각 단계 이후 별도의 작은 모델이 결과를 확인하는 방식입니다.

결국 루프 엔지니어링에서는 얼마나 많이 반복하는가보다 무엇을 기준으로 완료를 판단하는가가 중요합니다.

5. 그래프 엔지니어링: 여러 에이전트의 조직을 설계한다

루프가 하나의 에이전트가 반복해서 행동하는 방식을 프로그래밍한다면, 그래프 엔지니어링은 여러 에이전트가 어떻게 조직되고 협력하는지를 프로그래밍합니다.

그래프 엔지니어링이라는 명칭 자체는 아직 완전히 정착된 개념은 아닙니다. 자료에서도 용어의 출처가 명확하게 정리되지 않았고, 기존의 지식 그래프라는 용어와 충돌할 수 있다는 점을 지적합니다.

하지만 여러 에이전트를 그래프 형태로 구성하고 조율하는 방식 자체는 새로운 기술이 아닙니다.

기존 멀티 에이전트 연구에서도 다양한 에이전트의 역할과 작업 흐름을 구성하는 방식이 이미 사용되어 왔습니다.

따라서 그래프 엔지니어링에서 새로운 것은 반드시 기술 그 자체라기보다, 기존에 존재하던 여러 설계 결정을 하나의 이름으로 묶어 바라보는 관점이라고 볼 수 있습니다.

프로덕션 환경에서는 두 개의 그래프가 동시에 작동한다

자료에서 특히 주목할 부분은 실제 멀티 에이전트 시스템에서는 두 종류의 그래프가 동시에 존재한다는 점입니다.

조직 그래프

조직 그래프는 안정적인 구조입니다.

장기간 유지되는 에이전트가 특정 역할을 맡고, 자신이 담당하는 영역을 관리하며, 시간이 지나면서 관련 컨텍스트를 축적합니다.

이 그래프는 일반적으로 시스템을 다시 배포할 때 변경됩니다.

조직 그래프가 답하는 질문은 간단합니다.

"누가 무엇을 담당하는가?"

작업 그래프

작업 그래프는 특정 작업이 진행되는 동안 만들어지는 일시적인 구조입니다.

작업을 여러 경로로 나누어 동시에 처리할 수도 있고, 각각의 결과가 모이면 다시 하나로 합칠 수도 있습니다.

어떤 분기가 더 이상 필요하지 않다는 근거가 생기면 해당 경로를 없앨 수도 있습니다.

작업 그래프가 답하는 질문은 다음과 같습니다.

"지금 무엇을 해야 하는가?"

따라서 조직 그래프가 장기적인 역할과 책임을 표현한다면 작업 그래프는 특정 작업의 현재 진행 구조를 표현합니다.

그래프의 핵심은 노드, 엣지, 상태다

그래프 기반 에이전트 시스템을 이해할 때 중요한 요소는 노드와 엣지, 그리고 상태입니다.

자료에서는 LangGraph의 StateGraph를 구체적인 사례로 제시합니다.

StateGraph에서는 상태 스키마를 기반으로 그래프를 선언하고, add_node를 통해 노드를 등록합니다. 이후 add_edge와 add_conditional_edges를 사용해 노드 간의 연결과 조건부 흐름을 구성합니다.

START와 END를 지정한 다음 그래프를 컴파일합니다.

각 노드는 상태를 입력으로 받고 일부 상태를 업데이트하는 일반 함수로 구성할 수 있습니다.

여기서 중요한 부분이 있습니다.

컨텍스트는 노드와 노드 사이를 자동으로 이동하지 않습니다.

엣지를 통해 필요한 상태가 전달되어야 합니다.

여러 에이전트를 연결하는 시스템에서 정보가 제대로 전달되지 않는 문제가 발생한다면, 단순히 모델의 추론 능력만 볼 것이 아니라 그래프의 상태와 연결 구조를 확인해야 하는 이유입니다.

프롬프트, 루프, 그래프 중 무엇을 선택해야 할까?

상위 단계의 기술이 항상 더 좋은 것은 아닙니다.

자료에서는 필요한 계층을 판단하기 위해 순서대로 질문하는 방법을 제시합니다.

사람이 모든 결과를 확인하는가?

모든 출력 결과를 사람이 직접 읽고 다음 행동을 결정한다면 프롬프트 계층으로도 충분할 수 있습니다.

이때 루프가 추가되면 얻을 수 있는 가장 큰 변화는 사람이 직접 실행하지 않아도 되는 감독 없는 실행입니다.

완료 여부를 사람이 아닌 방식으로 확인할 수 있는가?

테스트, 스키마, 평가 기준, 두 번째 모델 등으로 "완료"를 판단할 수 있어야 합니다.

그렇지 않다면 자동화된 종료 조건이 없는 것이므로 루프가 작업을 끝내는 기준이 불분명합니다.

하나의 에이전트와 하나의 도메인으로 처리할 수 있는가?

작업이 하나의 에이전트 컨텍스트 안에서 충분히 처리된다면 굳이 여러 에이전트를 추가할 필요가 없습니다.

자료에서는 하나의 추론 흐름을 유지하는 것이 가정을 일관되게 유지하는 가장 저렴한 방법이라고 설명합니다.

서로 독립적인 작업을 동시에 처리해야 하는가?

독립적인 작업을 병렬로 처리해야 한다면 그래프 문제로 넘어갈 수 있습니다.

이 경우 노드와 엣지, 공유 상태, 실패 경로를 정의해야 합니다.

반대로 병렬 처리가 필요하지 않다면 에이전트를 추가하기 전에 기존 루프의 도구를 확장하는 것이 적절할 수 있습니다.

세 가지 기술은 경쟁 관계가 아니다

프롬프트 엔지니어링과 루프 엔지니어링, 그래프 엔지니어링을 서로 대체하는 기술로 이해하면 전체 구조를 놓치기 쉽습니다.

관계를 정리하면 다음과 같습니다.

계층	제어하는 대상	핵심 질문
프롬프트 엔지니어링	하나의 모델 응답	무엇을 어떻게 답하게 할 것인가?
컨텍스트 엔지니어링	모델에 제공할 정보	어떤 정보를 모델에게 보여줄 것인가?
하네스 엔지니어링	에이전트 실행 환경	어떤 도구와 메모리, 피드백을 제공할 것인가?
루프 엔지니어링	하나의 에이전트 행동 사이클	어떻게 반복하고 검증하고 종료할 것인가?
그래프 엔지니어링	여러 에이전트의 조직과 작업 흐름	누가 무엇을 어떤 순서로 처리할 것인가?

이 관계를 한 문장으로 정리하면 프롬프트 위에 루프가 있고, 루프 위에 그래프가 있는 구조입니다.

루프는 프롬프트를 반복하는 데 필요한 구조를 더한 것이고, 그래프는 여러 루프를 조직하는 방식으로 볼 수 있습니다.

따라서 상위 계층으로 올라간다고 해서 프롬프트 엔지니어링의 중요성이 줄어드는 것은 아닙니다.

실제로 자료에서는 Anthropic의 멀티 에이전트 연구 사례를 통해 조정 문제를 해결하는 데 프롬프트 엔지니어링이 주요한 수단이었다고 설명합니다.

복잡한 구조가 항상 더 좋은 결과를 만드는 것은 아니다

AI 에이전트 시스템을 설계할 때 주의해야 할 점은 복잡한 아키텍처가 곧 더 나은 결과를 의미하지 않는다는 것입니다.

특히 글쓰기처럼 작업의 여러 부분에서 서로 연결된 판단이 필요한 경우에는 에이전트를 여러 개로 분산하면 오히려 서로 다른 가정이 생기고 결과가 충돌할 수 있습니다.

또한 자료에서는 상위 계층의 성능과 비용에 대해서도 주의가 필요하다고 설명합니다.

내부 연구 평가에서 90.2%의 향상이 보고된 사례가 있지만, 일반적인 채팅보다 토큰 사용량이 약 15배 많았으며 토큰 사용량만으로도 결과의 변동성 중 80%가 설명된다는 내용이 제시됩니다.

따라서 에이전트를 여러 개 만들고 복잡한 그래프를 구성하는 것이 언제나 효율적인 선택이라고 볼 수는 없습니다.

필요한 만큼만 복잡하게 설계하는 것이 중요합니다.

AI 에이전트 설계에서 중요한 것은 계층을 올리는 것이 아니다

프롬프트 엔지니어링에서 루프 엔지니어링으로, 다시 그래프 엔지니어링으로 발전하는 흐름을 보면 AI 시스템이 단순한 응답 생성에서 점점 더 복잡한 작업 수행 구조로 확장되고 있다는 점을 확인할 수 있습니다.

하지만 중요한 것은 가장 높은 단계까지 올라가는 것이 아닙니다.

사람이 모든 결과를 검토할 수 있다면 프롬프트만으로 충분할 수 있습니다.

반복적인 작업을 자동으로 수행해야 한다면 루프가 필요할 수 있습니다.

여러 독립적인 작업을 동시에 처리하고 결과를 조정해야 한다면 그래프가 필요할 수 있습니다.

즉, 첫 번째로 "아니오"라는 답이 나오는 계층이 현재 작업에 필요한 설계 수준일 가능성이 높습니다.

이 기준을 적용하면 불필요하게 여러 에이전트를 만들거나 복잡한 구조를 추가하는 일을 줄일 수 있습니다.

728x90

프롬프트 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링은 서로 경쟁하는 세 가지 방법론이 아닙니다.

각각 다른 범위의 문제를 해결합니다.

프롬프트는 하나의 응답을 제어합니다. 컨텍스트와 하네스는 에이전트가 판단하고 행동할 수 있는 환경을 구성합니다. 루프는 하나의 에이전트가 반복적으로 작업하고 검증하며 종료하도록 만듭니다. 그래프는 여러 에이전트가 역할을 나누고 작업을 병렬로 처리하거나 다시 통합할 수 있도록 구조화합니다.

특히 루프에서는 종료 조건이 중요하고, 그래프에서는 노드와 엣지, 상태, 실패 경로를 명확하게 설계하는 것이 중요합니다.

무엇보다 중요한 것은 복잡성을 높이는 것 자체가 목표가 되어서는 안 된다는 점입니다.

하나의 에이전트로 충분한 작업이라면 굳이 여러 에이전트를 사용할 필요가 없습니다. 반대로 사람의 개입 없이 반복 작업을 수행해야 한다면 루프를 고려할 수 있고, 독립적인 작업을 병렬로 수행하고 조정해야 한다면 그래프 구조를 검토할 수 있습니다.

결국 AI 에이전트 설계에서 중요한 질문은 "어떤 최신 엔지니어링 기법을 사용해야 하는가?"가 아닙니다.

현재 해결하려는 문제에 어느 정도의 제어 구조가 필요한가?

이 질문에 답하는 것이 프롬프트에서 루프로, 루프에서 그래프로 확장되는 AI 에이전트 설계를 이해하는 출발점이 될 수 있습니다.

300x250

https://www.marktechpost.com/2026/07/29/prompt-engineering-vs-loop-engineering-vs-graph-engineering/

Prompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layer