하네스vs루프vs그래프 엔지니어링이 뭐야?

사람들이 계속 혼동하는 세 가지 계층에 대한 실용 가이드

대부분의 사람은 AI 에이전트를 하나의 것으로 이야기한다.

그렇지 않다.

에이전트가 단순한 데모를 넘어 파일, API, 문서, 고객 또는 프로덕션 코드까지 다루기 시작하면, 더 이상 단순히 “모델에 프롬프트를 입력하는” 것이 아니다.

시스템을 설계하는 것이다.

그 시스템 안에서 다음 세 가지 개념이 계속 뒤섞인다.

에이전트 하네스 엔지니어링

루프 엔지니어링

그래프 엔지니어링

모두 같은 모델을 중심으로 한다.

모두 신뢰성에 영향을 준다.

그리고 맞다. 모두 루프를 포함할 수 있다.

하지만 해결하는 문제는 서로 다르다.

이를 혼동하면 엉뚱한 계층을 디버깅하게 된다.

간략한 요약

정리하면 이렇다.

하네스 엔지니어링은 모델 주변의 환경을 구축한다.

루프 엔지니어링은 반복되는 작업-피드백 주기를 설계한다.

그래프 엔지니어링은 워크플로 토폴로지를 명시적으로 만든다. (워크플로의 구조를 설계한다.)

환경 → 피드백 → 흐름

하네스는 모델에 도구, 메모리, 제어 기능, 작업 공간을 제공한다.

루프는 작업을 어떻게 재시도하고, 점검하고, 개선할지 결정한다.

그래프는 다음에 어떤 단계가 실행될 수 있는지 정의한다.

이것이 차이다.

왜 지금 이 용어들이 중요한가

가공되지 않은 모델은 혼자서 실제 작업을 할 수 없다.

할 수 없는 일:

세션 간 프로젝트 상태 유지

안전하게 도구 호출

브라우저 검사

권한 강제

실패한 작업 재시도

출력 품질 검증

여러 전문 담당자 사이에서 작업 라우팅

적절한 순간에 중단

이 모든 것은 모델을 둘러싼 시스템에서 나온다.

에이전트형 소프트웨어가 성숙하면서 다음과 같은 실용적인 스택이 나타나고 있다.

하네스는 모델에 작동 조건을 제공한다.

루프는 작업을 반복 가능하고 검증 가능하게 만든다.

그래프는 복잡한 워크플로를 명시적이고 제어 가능하게 만든다.

이 계층들을 서로 다른 것으로 보면 AI 아키텍처에 대한 혼란이 많이 사라진다.

제대로 된 하네스에는 무엇이 포함되어야 하는가?

1. 컨텍스트 주입

모델이 행동하기 전에 보는 것:

지침

검색된 지식

대화 상태

메모리

정책

작업별 규칙

2. 행동 수단

모델이 할 수 있는 것:

API 호출

브라우저 조작

셸 명령

코드 실행

MCP 도구

데이터베이스

사용자 정의 함수

3. 지속성

시간이 지나도 남는 것:

파일

체크포인트

세션 상태

진행 로그

Git 이력

장기 메모리

4. 실행 제어

실행을 관리하는 방식:

재시도

타임아웃

예산

모델 선택

서브에이전트 생성

승인 게이트

5. 안전 및 거버넌스

시스템을 안전하게 유지하는 것:

최소 권한 원칙

격리

허용 목록

비밀 정보 처리

사람 승인

6. 관측 가능성(기록장치 : 문제 발생시 개선의 근거로 활용)

디버깅을 가능하게 하는 것:

트레이스
: 에이전트가 발자국을 남기듯 처음부터 끝까지 일한 전체 경로를 기록한 타임라인

도구 입력 및 출력

상태 전이 :
에이전트가 작업하는 동안 메모리나 상태가 어떻게 바뀌었는지 변화 과정의 기록

지연 시간

비용

평가 결과

왜 하네스 엔지니어링이 중요한가?

같은 모델을 사용해도 두 팀의 결과는 완전히 다를 수 있다.

왜 그럴까?

한 팀은 모델에 다음을 제공한다.

깔끔한 도구

안정적인 상태

구조화된 메모리

명확한 권한

관측 가능한 실행

다른 팀은 다음을 제공한다.

모호한 프롬프트

엉성한 도구

시끄러운 컨텍스트

메모리 없음

검증 없음

모델은 같을 수 있다. 작업 조건은 같지 않다.

에이전트가 다음과 같은 상황이라면 하네스 엔지니어링이 중요하다.

필요한 기능에 접근할 수 없다.

세션 간에 컨텍스트를 잃는다.

환경마다 일관되지 않게 행동한다.

감사할 수 없다.

권한이 너무 많다.

중단 후 깔끔하게 복구할 수 없다.

모델이 안정적으로 작동하지 않는다면 가장 먼저 하네스를 살펴봐야 한다.

2. 루프 엔지니어링

무엇인가

도구를 사용하는 모든 에이전트에는 이미 작은 내장 루프가 있다.

모델 호출

결과 관찰

도구 실행

관찰 결과를 다시 주입

완료될 때까지 반복

루프 엔지니어링은 이러한 동작을 중심으로 추가 사이클을 의도적으로 설계할 때 시작된다.

단순히 “다시 물어보기”가 아니다.

단순히 “재시도”하는 것도 아니다.

실제 작업-피드백 시스템이다.

좋은 루프의 구조

루프의 해부학

트리거

새로운 주기를 시작하는 것은 무엇인가?

사용자 요청

실패한 테스트

새 문서

예약된 실행

웹훅

평가자 피드백

목표

어떤 구체적인 조건에 도달하려는가?

“계속 개선한다”가 아니다.

실제 목표다.

상태

다음 주기가 알아야 할 것은 무엇인가?

현재 초안

이전 시도

도구 결과

오류

진행 상태

행동 정책

에이전트가 할 수 있는 일은 무엇인가?

편집

위임

도구 호출

토큰 사용

파일 작성

PR 열기

근거

작동했다는 것을 어떻게 알 수 있는가?

테스트

스키마 검증

인용

차이점

메트릭

리뷰어 승인

피드백

정확히 무엇이 실패했는가?

피드백은 간결하고 실행 가능해야 한다.

중단 규칙

언제 끝나는가?

성공

타임아웃

예산 소진

최대 재시도 횟수 도달

회복 불가능한 실패

사람에게 에스컬레이션

루프 엔지니어링의 가장 중요한 원칙

확신을 기준으로 루프를 돌리지 마라.

근거를 기준으로 루프를 돌려라.

“에이전트가 끝났다고 말한다”는 중단 조건이 아니다.

실제 중단 조건은 다음과 같다.

테스트가 통과한다.

스키마가 검증된다.

인용이 확인된다.

리뷰어가 승인한다.

정책 점검이 통과한다.

이것이 루프 엔지니어링이다.

왜 루프 엔지니어링은 단순한 프롬프트 엔지니어링이 아닌가

프롬프트는 호출 중에 모델이 무엇을 할지 알려준다.

루프는 호출 후에 시스템이 무엇을 할지 정의한다.

여기에는 다음이 포함된다.

결과 확인 방식

실패에 대한 반응

진행 상황 보존 방식

계속할지 결정하는 방식

종료 방식

프롬프트는 응답을 개선한다.

루프는 프로세스를 개선한다.

이것은 전혀 다른 엔지니어링 문제다.

3. 그래프 엔지니어링

무엇인가?

그래프 엔지니어링은 워크플로 구조를 명시적으로 만든다.

그래프 엔지니어링은 다른 질문에 답한다.

단순히 “에이전트가 무엇을 해야 하는가?”가 아니다.
“다음에 무엇이 일어나도록 허용되는가?”이다.

그래프 엔지니어링에서는:

단계는 노드다. (AI가 수행해야 하는 독립적인 하나의 작업 단위. (예: [자료 수집], [보고서 작성])

전이는 엣지다.

분기가 명시적이다. (조건에 따라 갈림길을 명확히 나눔. (예: 번역 품질이 높으면 바로 저장, 낮으면 재번역))

병렬 작업이 명시적이다. (예: 구글 검색과 데이터베이스 조회를 동시에 실행. 포인트는 서로 영향이 없는 독립된 작업이어야함.)

조인이 명시적이다.

재시도가 명시적이다.

사람의 중단이 명시적이다. (중요한 길목에서 사람의 승인을 받아야만 다음 단계로 넘어가도록 길을 막아두는 신호등 역할)

그래프는 시스템의 제어 지도가 된다.

그래프 엔지니어가 실제로 설계하는 것

노드 경계

어떤 것을 다음 안에 둘 것인가:

결정론적 함수

LLM 호출

전문 에이전트

사람의 검토 단계

상태 스키마

각 노드가 읽거나 쓸 수 있는 것.

라우팅 조건

작업을 움직이는 근거:

앞으로

뒤로

옆으로

에스컬레이션으로

동시성

무엇을 병렬로 실행할 수 있고, 무엇이 기다려야 하는가.

사이클과 종료

재시도가 허용되는 위치, 허용 횟수, 중단 방식.

내구성

체크포인트가 생성되는 위치와 중단 후 워크플로를 재개하는 방식.

그래프 엔지니어가 실제로 설계하는 것

그래프는 프로세스에 다음이 포함될 때 유용하다.

의미 있는 분기

승인

전문 담당자 인계

병렬 작업

복구 경로

명시적인 제어 지점이 있는 다단계 워크플로

그래프는 다음처럼 단순한 작업에는 덜 유용하다.

“에이전트 하나에 도구 몇 개를 주고 작업하게 하자.”

그 경우에는 탄탄한 하네스와 몇 개의 루프만으로도 충분할 수 있다.

그래프는 명확성을 더하지만 구조도 더한다.

너무 이른 시점에 구조를 과도하게 넣으면 시스템이 취약해질 수 있다.

세 가지 레이어가 어떻게 함께 작동하는가?

연구 및 발행 에이전트를 만든다고 해 보자.

에이전트는 다음을 해야 한다.

주제 범위 설정

자료 수집

인용 선별

보고서 초안 작성

법무 검토 통과

승인 후에만 게시

이제 세 계층이 어떻게 대응하는지 보자.

하네스

제공하는 것:

브라우저 접근

검색 도구

파일 작업 공간

메모리

인용

승인

트레이스

모델 라우팅

루프

처리하는 것:

근거가 약할 때 자료 검색 재시도

인용 실패 수정

채점기 점검 실행

시장이 바뀌면 작업 새로 고침

그래프

경로를 제어한다.

범위 설정

조사

선별

종합

초안 작성

검토

게시

출시 전에 사람 게이트를 둔다.

그래서 세 계층은 서로 바꿔 쓸 수 없다.

함께 작동하지만 같은 것은 아니다.

해결책을 생각하기 전에 실패를 진단하라

실용적인 규칙은 다음과 같다.

에이전트가 작동하지 않으면 하네스를 고쳐라

예시:

도구 또는 접근 권한 누락

오래된 상태

취약한 메모리

잘못된 권한

관측 가능성 없음

에이전트가 거의 작동하지만 신뢰할 수 없다면 루프를 고쳐라

예시:

첫 초안은 거의 맞지만 약함

성공이 일관되지 않음

재시도가 통제되지 않음

완료를 입증할 근거 없음

프로세스 자체가 복잡하다면 그래프를 고쳐라

예시:

전문 담당자가 많음

승인

분기 로직

병렬 경로

구조화된 인계

흔한 실수들

1. 그래프를 너무 일찍 만들기

팀은 작업이 실제로 어떻게 진행되는지 보기 전에 거대한 워크플로를 그리는 경우가 많다.

더 나은 접근:

더 단순한 하네스로 시작

트레이스 수집

안정적인 패턴 찾기

제어할 가치가 있는 것만 형식화

2. 같은 모델이 보호 장치 없이 작성과 채점을 모두 맡게 하기

자체 리뷰는 도움이 될 수 있지만 같은 사각지대를 공유한다.

다음을 우선하라.

가능하면 결정론적 점검

분리된 리뷰어 컨텍스트

외부 평가자(다른 모델)

영향이 큰 작업에 대한 사람 승인

3. “계속 시도하기”를 루프로 착각하기

그것은 루프 설계가 아니다.

통제되지 않는 비용 누수다.

잘못된 방식 (무작정 재시도):

AI에게 일을 시켜놓고 에러나 만족스럽지 않은 결과가 나왔을 때, 아무런 기준 없이 "될 때까지 계속 다시 해봐!" 하고 무한 반복을 돌리는 것. ⇒ 원하는 결과는 못 얻고 돈만 끝없이 깎여 나가는 상태

모든 루프에는 다음이 필요하다.

측정 가능한 목표

실제 근거

재시도 제한

에스컬레이션 규칙

4. 하네스를 잡동사니 서랍처럼 다루기

도구가 많다고 자동으로 더 나은 에이전트가 되는 것은 아니다.

도구가 너무 많으면 다음이 생긴다.

선택 실수

시끄러운 환경

취약한 신뢰성

더 넓어진 위험 범위

좋은 하네스는 붐비지 않는다. 정확하다.

5. 오케스트레이션 실패를 모델 탓으로 돌리기

모델은 다음을 보완할 수 없다.

망가진 API

오래된 상태

누락된 종료 조건

모호한 도구 스키마

보이지 않는 실패 모드

실패를 책임지는 계층을 고쳐라.

간단한 프로덕션 체크리스트

하네스

도구가 좁은 범위로 문서화되어 있는가?

상태가 지속되는가?

권한이 최소 권한 원칙을 따르는가?

운영자가 일시정지, 검사, 재개를 할 수 있는가?

트레이스가 보이는가?

루프

성공을 입증하는 근거는 무엇인가?

실패 시 어떤 피드백이 반환되는가?

재시도는 몇 번 허용되는가?

중단 규칙은 무엇인가?

예산이 소진되면 어떻게 되는가?

그래프

어떤 경로가 결정론적이어야 하는가?

무엇을 병렬로 실행할 수 있는가?

사람 게이트는 어디에 있는가?

어떤 상태를 공유하는가?

복구 경로는 어디에서 시작되는가?

평가

실제 트레이스를 재생할 수 있는가?

버전을 비교할 수 있는가?

개선을 실제 변경의 결과로 귀속할 수 있는가?

운영

비용을 추적하고 있는가?

지연 시간은?

실패율은?

개입률은?

프로덕션에서의 작업 성공률은?

차이를 기억하는 가장 간단한 방법

한 가지만 기억한다면 이것을 기억하라.

하네스 엔지니어링은 모델을 작동 가능하게 만든다.

루프 엔지니어링은 작업을 반복 가능하고 검증 가능하게 만든다.

그래프 엔지니어링은 실행 경로를 명시적이고 제어 가능하게 만든다.

어느 하나도 다른 것을 대체하지 않는다.

완벽한 그래프도 약한 하네스를 구할 수 없다.

강력한 하네스도 좋은 루프가 없으면 비용을 낭비한다.

분기와 승인이 임시 코드 안에 숨으면 깔끔한 루프도 관리하기 어려워진다.

신뢰할 수 있는 에이전트 시스템은 세 계층을 모두 의도적으로 설계할 때 나타난다.

이것이 실제 아키텍처 스택이다.

최종 정리

사람들은 AI 에이전트에 대해 돌파구가 모델인 것처럼 계속 이야기한다.

프로덕션에서는 그것이 진짜 차별점인 경우가 드물다.

차별점은 모델을 둘러싼 시스템이다.

작동하게 하는 하네스

개선하게 하는 루프

통제된 상태에서 작동하게 하는 그래프

이렇게 장난감 에이전트가 실제 시스템이 된다.

출처 : @lunarresearcher