AI 에이전트의 하네스·루프·그래프 엔지니어링 순서대로 이해하기

AI 에이전트가 장기 작업을 맡기 시작하면서 프롬프트만 잘 쓰는 것으로는 안정적인 결과를 얻기 어려워졌다. 에이전트가 어떤 정보를 보고, 어떤 도구를 사용하며, 언제 반복하고, 어느 경로로 이동하고, 어디에서 사람의 승인을 받아야 하는지까지 설계해야 하기 때문이다.

이 문제를 설명할 때 자주 등장하는 표현이 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링이다. 이들은 국제 표준이나 엄격히 합의된 학술 분류가 아니다. 서로 겹치는 부분이 있으며 제품과 개발팀에 따라 뜻도 달라질 수 있다. 따라서 연도별 유행어로 외우기보다 각각이 답하려는 제어 질문으로 구분하는 편이 유용하다.

세 개념을 한눈에 비교하기

짧게 표현하면 하네스는 환경과 경계, 루프는 반복 규칙, 그래프는 가능한 경로의 구조다. 실제 시스템에서는 그래프의 한 노드 안에 루프가 들어가고, 전체 그래프가 하나의 하네스 안에서 실행될 수 있다.

에이전트 제어 방식은 어떻게 변해 왔나

초기 에이전트: 정해진 워크플로우가 자율성을 보완했다

초기 생성형 AI 에이전트는 긴 작업에서 목표를 잊거나, 잘못된 도구 호출을 반복하거나, 근거 없는 결과를 만드는 경우가 많았다. 이에 개발자는 큰 작업을 작은 단계로 나누고 각 단계의 입력과 출력을 고정했다.

이 방식에서는 사람이 전체 절차를 체인, 플로차트 또는 상태 머신으로 작성하고 LLM은 분류, 추출, 요약, 초안 작성처럼 제한된 작업을 맡는다. LangGraph와 같은 프레임워크는 상태를 유지하면서 분기, 순환, 체크포인트, 사람의 개입을 표현하는 데 사용된다.

다만 그래프 기반 오케스트레이션이 특정 연도에 끝난 구식 방식은 아니다. 현재도 감사 가능성, 재현성, 규제 준수 또는 정확한 복구 절차가 중요한 업무에서는 명시적 그래프가 적합하다.

모델 성능 향상: 고정 경로에서 동적 도구 사용으로

도구 사용과 추론 능력이 개선되면서 하나의 에이전트가 상황에 따라 검색, 코드 편집, 테스트, 파일 읽기 같은 행동을 선택할 수 있게 됐다. ReAct 계열 접근은 추론과 행동, 관찰을 번갈아 수행하는 대표적 구조다.

이 변화는 사람이 모든 분기를 미리 작성해야 하는 부담을 줄였다. 반면 에이전트가 읽는 정보, 보유한 권한, 실행 비용, 오류 복구 방식을 관리하는 문제가 더 중요해졌다. 이때 컨텍스트 엔지니어링과 하네스 엔지니어링이 실무의 중심으로 들어온다.

장기 작업과 멀티 에이전트: 루프와 그래프의 재결합

장기 작업에서는 한 번의 모델 호출보다 반복적인 계획·실행·검증이 중요하다. 여러 에이전트가 참여하면 역할, 산출물 형식, 권한, 종료 조건도 명시해야 한다. 동시에 자율 루프를 완전히 방치하면 비용 폭증, 무한 재시도, 보상 해킹, 잘못된 목표 최적화가 발생할 수 있다.

그래서 현대적인 에이전트 시스템은 자율성을 없애기보다 자율성을 허용할 구간과 결정론적으로 통제할 구간을 결합하는 방향으로 설계된다. 이는 과거의 고정 체인으로 단순 회귀하는 것이 아니라, 유연한 실행을 상태·전이·정책으로 둘러싸는 방식이다.

이러한 변화는 정확한 연대표라기보다 설계상의 강조점 변화다. 그래프, 루프, 하네스는 처음부터 공존해 왔으며 현재도 함께 사용된다.

하네스 엔지니어링이 다루는 것

하네스는 기반 모델 자체가 아니라 모델이 실제 업무를 수행하도록 둘러싼 실행 체계다. 같은 모델을 사용해도 하네스에 따라 성공률, 비용, 보안성과 재현성이 크게 달라질 수 있다.

하네스의 주요 구성 요소

1. 지시 체계: 시스템 지침, 저장소 규칙, 코딩 표준, 우선순위와 금지 행동
2. 컨텍스트 공급: 검색, 파일 선택, 요약, 메모리, 필요한 시점의 문서 주입
3. 도구 인터페이스: 파일 편집, 터미널, 브라우저, 데이터베이스, 외부 API
4. 권한과 격리: 읽기·쓰기 범위, 비밀정보 접근, 네트워크 제한, 샌드박스
5. 검증 장치: 테스트, 린터, 타입 검사, 스키마 검증, 사실 확인
6. 사람의 승인: 배포, 결제, 삭제, 외부 전송 등 되돌리기 어려운 행동의 승인
7. 관찰 가능성: 호출 기록, 비용, 지연 시간, 오류, 변경 내역, 결정 근거
8. 복구 정책: 재시도, 이전 상태 복원, 작업 중단, 담당자 이관

Claude Code의 프로젝트 지침 파일이나 훅은 하네스 구성 요소의 사례로 볼 수 있다. 그러나 특정 제품 기능 하나가 하네스 전체를 뜻하지는 않는다.

컨텍스트 엔지니어링과의 차이

컨텍스트 엔지니어링은 현재 모델 호출에 어떤 정보와 지침을 넣을지 최적화한다. 검색으로 관련 문서만 가져오기, 오래된 대화를 요약하기, 작업 상태를 외부 파일에 저장하기, 하위 작업별로 컨텍스트를 분리하기 등이 포함된다.

하네스 엔지니어링은 이보다 넓다. 컨텍스트뿐 아니라 도구 권한, 실행 환경, 승인, 검증, 로깅과 비용 제한까지 다룬다. 따라서 컨텍스트 엔지니어링은 하네스의 핵심 부분이지만 둘을 완전히 같은 뜻으로 쓰는 것은 부정확하다.

루프 엔지니어링의 핵심은 종료 조건이다

루프는 에이전트가 결과를 만든 뒤 검사하고 부족하면 다시 시도하도록 만든다. 중요한 것은 반복 자체가 아니라 진전의 정의와 중단 조건이다.

대표적인 루프 유형

• 검증 루프: 초안을 만든 뒤 테스트나 평가 기준으로 검사하고 실패한 항목을 수정한다.
• 이벤트 기반 루프: 이메일, 알림, 코드 변경, 센서 데이터 같은 외부 사건이 발생할 때 작업을 시작한다.
• 탐색 루프: 여러 가설이나 자료원을 조사하고 증거가 충분해질 때까지 탐색 범위를 조정한다.
• 개선 루프: 이전 결과와 평가값을 바탕으로 다음 전략을 선택한다. 단일 점수만 최적화하면 보상 해킹이 발생할 수 있으므로 여러 평가 기준과 사람의 검토가 필요하다.
• 복구 루프: 오류 원인을 분류하고 허용된 범위에서 재시도한 뒤 해결되지 않으면 사람에게 넘긴다.

안전한 루프에 필요한 계약

에이전트 사이의 계약은 법적 계약이 아니라 입출력과 책임을 명시한 실행 명세다. 다음 항목을 포함하는 것이 좋다.

완료 조건이 모호하면 에이전트는 문장을 바꾸거나 같은 검색을 반복하면서도 작업이 진전되고 있다고 판단할 수 있다. 최대 반복 횟수만 두는 것보다 결과 품질, 새 정보의 증가량, 오류 변화와 비용을 함께 보는 편이 낫다.

그래프 엔지니어링은 자율성의 경계를 구조화한다

그래프는 작업을 노드와 연결선으로 표현한다. 노드는 모델 호출, 도구 실행, 사람의 승인 또는 검증 과정이 될 수 있고, 연결선은 상태에 따른 다음 행동을 나타낸다.

체인과 그래프의 차이

• 체인은 A에서 B, B에서 C로 이어지는 선형 절차에 적합하다.
• 그래프는 조건 분기, 반복, 병렬 실행, 실패 복구, 중간 저장이 필요한 작업에 적합하다.
• 동적 그래프는 실행 중 모델이 다음 하위 작업이나 경로를 제안한다.
• 제약된 그래프는 모델이 선택하더라도 허용된 노드와 전이 안에서만 움직이게 한다.

현대적인 그래프 설계의 목적은 모든 행동을 사람이 미리 결정하는 데 있지 않다. 데이터 삭제 전 승인 노드를 반드시 거치게 하거나, 테스트 실패 상태에서는 배포 상태로 이동하지 못하게 하는 식으로 지켜야 할 불변 조건을 구조에 넣는 데 있다.

그래프가 필요한 신호

다음 조건 중 여러 개가 해당하면 명시적인 그래프를 검토할 가치가 있다.

• 실패 후 돌아가야 할 복구 지점이 분명하다.
• 사람의 승인이 반드시 필요한 단계가 있다.
• 여러 작업을 병렬 실행한 뒤 결과를 합쳐야 한다.
• 상태에 따라 사용 가능한 도구나 권한이 달라진다.
• 전체 실행 경로를 감사하거나 재현해야 한다.
• 단일 에이전트 루프가 같은 실패를 반복한다.

단순한 문서 요약이나 한 번의 데이터 변환까지 그래프로 만들면 복잡성만 늘어날 수 있다.

실무 적용 순서: 하네스에서 시작해 필요한 만큼 확장하기

대부분의 팀에는 다음 순서가 현실적이다.

1. 단일 작업과 성공 기준을 정한다. 먼저 입력, 기대 출력, 실패 사례를 모은다.
2. 최소 하네스를 만든다. 필요한 컨텍스트와 도구만 제공하고 권한, 테스트, 로그, 비용 한도를 설정한다.
3. 평가 세트를 구축한다. 정상 사례뿐 아니라 모호한 요청, 잘못된 문서, 도구 오류, 권한 초과 시도를 포함한다.
4. 반복이 필요한 지점을 루프로 만든다. 검증과 수정이 실제 품질을 높이는 구간에만 재시도를 허용한다.
5. 분기와 복구가 복잡할 때 그래프로 승격한다. 상태와 전이를 명시하고 위험 행동 앞에 승인 노드를 둔다.
6. 업무 분리가 이득일 때만 멀티 에이전트를 사용한다. 병렬 탐색이나 서로 다른 전문 역할이 필요하지 않다면 단일 에이전트가 더 단순하고 저렴할 수 있다.

코딩과 리서치에서의 적용 차이

코딩에는 동적 워크플로우가 항상 비효율적이고 리서치에는 항상 유리하다고 단정할 수 없다. 테스트 가능한 대규모 마이그레이션은 자율 에이전트에 적합할 수 있고, 답이 명확한 사실 조회는 고정된 리서치 절차가 더 효율적일 수 있다. 핵심 변수는 분야보다 목표의 명확성, 자동 검증 가능성, 탐색 공간과 오류 비용이다.

코드 리뷰는 사라지는 것이 아니라 검토 단위가 바뀐다

에이전트가 코드를 작성하면 개발자는 모든 줄을 직접 입력하는 대신 요구사항, 설계, 테스트 결과, 변경 범위와 위험을 감독하는 역할을 더 많이 맡게 된다. Pull Request 요약과 에이전트 보고서는 검토 속도를 높일 수 있다.

그러나 요약만 읽고 승인하는 방식은 안전한 기본값이 아니다. 에이전트가 누락한 변경이나 잘못 이해한 로직은 요약에도 나타나지 않을 수 있다. 다음 상황에서는 원본 diff와 관련 코드를 직접 검토해야 한다.

• 인증, 결제, 개인정보, 암호화, 접근 통제 변경
• 데이터베이스 스키마 변경이나 비가역적 마이그레이션
• 성능과 동시성에 민감한 코드
• 테스트 범위를 벗어난 대규모 리팩터링
• 외부 의존성, 배포 설정, 비밀정보 처리 변경
• 에이전트의 설명과 실제 diff가 일치하지 않는 경우

Human-in-the-loop는 사람이 형식적으로 버튼을 누르는 것이 아니다. 사람이 판단할 수 있도록 변경 증거, 테스트 결과, 실패 가능성과 되돌리기 절차를 제공하는 것까지 포함한다.

자주 빠지는 함정

목적 없는 멀티 에이전트

에이전트를 늘리면 역할 조정, 중복 호출, 컨텍스트 전달과 결과 병합 비용이 생긴다. 서로 다른 관점의 병렬 탐색이 필요하거나 컨텍스트를 분리해야 하는 이유가 없다면 단일 에이전트가 더 낫다.

무제한 동적 워크플로우

에이전트가 하위 작업을 계속 만들도록 허용하면 토큰과 도구 호출 비용이 빠르게 증가한다. 비용은 대략 각 단계의 입력·출력 토큰 비용, 도구 비용, 병렬 에이전트 수, 반복 횟수의 합으로 결정된다. 호출 횟수, 동시 실행 수, 총예산과 최대 실행 시간을 별도로 제한해야 한다.

평가 지표 하나만 최적화하기

테스트 통과율만 목표로 주면 테스트를 약화하거나 예외 처리를 숨기는 식의 잘못된 최적화가 생길 수 있다. 품질, 보안, 변경 규모, 비용, 지연 시간과 사람의 평가를 함께 사용해야 한다.

문서 주입을 파인튜닝과 혼동하기

문서 검색이나 프로젝트 지침을 통해 결과가 지속적으로 달라질 수 있지만 모델 가중치가 바뀌는 것은 아니다. 이는 넓은 의미에서 시스템의 학습 효과로 설명할 수 있으나, 엄밀히는 외부 메모리와 컨텍스트를 이용한 적응이다. 문서나 검색 인덱스를 보존해야 다음 실행에도 변화가 유지된다.

운영 단계에서 놓치기 쉬운 평가·보안·경제성

에이전트 설계는 아키텍처 그림으로 끝나지 않는다. 실제 운영에서는 무엇을 허용했는지보다 무엇이 실제로 발생했는지 측정하는 체계가 중요하다.

최소 운영 지표

• 작업 성공률과 사람의 수정률
• 작업당 모델·도구 비용과 총 실행 시간
• 반복 횟수와 진전 없이 소비된 호출 비율
• 승인 요청, 거부, 권한 초과 시도 횟수
• 잘못된 도구 호출과 복구 성공률
• 출처 또는 테스트 없이 제출된 결과 비율
• 동일 입력에서 결과가 달라지는 정도

보안상 필요한 불변 조건

• 외부 문서의 지시가 시스템 정책보다 높은 우선순위를 갖지 않는다.
• 비밀정보는 모델 입력과 로그에 불필요하게 노출하지 않는다.
• 읽기 권한과 쓰기·삭제·배포 권한을 분리한다.
• 외부 전송과 비가역적 행동에는 별도 승인이나 정책 검사를 둔다.
• 에이전트가 자신의 평가 기준, 테스트 또는 감사 로그를 임의로 수정하지 못하게 한다.

이러한 불변 조건은 프롬프트 한 문장보다 샌드박스, 접근 제어, 그래프 전이와 독립 검증기로 강제하는 편이 안전하다. 생성형 AI 위험 관리는 모델의 정확도뿐 아니라 운영 환경, 사람의 감독과 사고 대응까지 포함해야 한다.

어떤 개념부터 배워야 하나

현재 실무에서 가장 먼저 익힐 것은 하네스 엔지니어링이다. 정확한 컨텍스트, 최소 권한, 자동 검증, 로그, 승인과 비용 한도를 갖추면 단일 에이전트의 많은 실패를 줄일 수 있다.

그다음 반복이 품질을 높이는 작업에 종료 조건이 있는 루프를 추가한다. 분기, 병렬 처리, 복구와 승인 절차가 복잡해졌을 때 그래프로 명시한다. 복잡한 용어를 채택하는 것보다 에이전트의 목표, 권한, 증거, 비용과 중단 조건을 측정 가능한 형태로 만드는 것이 우선이다.