사람들이 계속 헷갈려하는 3 가지 레이어에 대한 실용 가이드
대부분의 사람들은 AI 에이전트를 하나의 개념처럼 이야기합니다.
하지만 그렇지 않습니다.
에이전트가 단순한 장난감 수준의 데모를 넘어 파일, API, 문서, 고객 또는 프로덕션 코드를 다루기 시작하면, 더 이상 단순히 "모델에 프롬프트를 입력하는" 것이 아닙니다.
여러분은 시스템을 설계하고 있는 것입니다.
그리고 그 시스템에는 사람들이 계속 헷갈려하는 세 가지 개념이 있습니다:
- 에이전트 Harness 엔지니어링
- 루프 엔지니어링
- 그래프 엔지니어링
이 세 가지는 모두 동일한 모델을 중심으로 자리 잡고 있습니다.
모두 안정성에 영향을 미칩니다.
그리고 네, 모두 루프를 포함할 수 있습니다.
하지만 이들은 서로 다른 문제를 해결합니다.
이들을 혼동하면, 결국 잘못된 레이어를 디버깅하게 됩니다.
30초 요약
깔끔한 버전은 이렇습니다:
- Harness 엔지니어링은 모델 주변의 환경을 구축합니다
- 루프 엔지니어링은 반복적인 작업 및 피드백 주기를 설계합니다
- 그래프 엔지니어링은 워크플로우 토폴로지를 명시적으로 만듭니다
좋은 멘탈 모델은 다음과 같습니다:
환경 → 피드백 → 흐름
- Harness는 모델에 도구, 메모리, 제어 및 작업 공간을 제공합니다
- 루프는 작업이 재시도, 확인 및 개선되는 방식을 결정합니다
- 그래프는 다음에 어떤 단계가 실행될 수 있는지 정의합니다
이것이 차이점입니다.
이 용어들이 지금 중요한 이유
원시 모델은 스스로 실제 작업을 수행할 수 없습니다.
다음을 할 수 없습니다:
- 세션 간에 프로젝트 상태 유지
- 안전하게 도구 호출
- 브라우저 검사
- 권한 적용
- 실패한 작업 재시도
- 출력 품질 검증
- 전문가 간 작업 라우팅
- 적절한 시점에 중단
이 모든 것은 모델 주변의 시스템에서 비롯됩니다.
에이전트 소프트웨어가 성숙해짐에 따라, 실용적인 스택이 등장하고 있습니다:
- Harness는 모델에 운영 조건을 제공합니다
- 루프는 작업을 반복 가능하고 검증 가능하게 만듭니다
- 그래프는 복잡한 워크플로우를 명시적이고 제어 가능하게 만듭니다
이것들을 별개의 레이어로 보게 되면, AI 아키텍처에 대한 많은 혼란이 사라집니다.
진지한 Harness가 일반적으로 포함하는 것
- 컨텍스트 주입
모델이 행동하기 전에 보는 것:
- 지침
- 검색된 지식
- 대화 상태
- 메모리
- 정책
- 작업별 규칙
- 액션 표면
모델이 할 수 있는 것:
- API 호출
- 브라우저 작업
- 셸 명령어
- 코드 실행
- MCP 도구
- 데이터베이스
- 사용자 정의 함수
- 지속성
시간이 지나도 유지되는 것:
- 파일
- 체크포인트
- 세션 상태
- 진행 로그
- Git 히스토리
- 장기 메모리
- 실행 제어
실행이 관리되는 방식:
- 재시도
- 시간 제한
- 예산
- 모델 선택
- 하위 에이전트 생성
- 승인 게이트
- 안전 및 거버넌스
시스템을 안전하게 유지하는 것:
- 최소 권한
- 격리
- 허용 목록
- 비밀 처리
- 인간 승인
- 관찰 가능성
디버깅을 가능하게 하는 것:
- 트레이스
- 도구 입력 및 출력
- 상태 전환
- 지연 시간
- 비용
- 평가 결과
Harness 엔지니어링이 중요한 이유
두 팀이 동일한 모델을 사용해도 완전히 다른 결과를 얻을 수 있습니다.
왜일까요?
한 팀은 모델에 다음을 제공하기 때문입니다:
- 깔끔한 도구
- 안정적인 상태
- 구조화된 메모리
- 명확한 권한
- 관찰 가능한 실행
그리고 다른 팀은 다음을 제공합니다:
- 모호한 프롬프트
- 지저분한 도구
- 시끄러운 컨텍스트
- 메모리 없음
- 검증 없음
모델은 동일할 수 있습니다.
하지만 작업 조건은 다릅니다.
Harness 엔지니어링은 에이전트가 다음과 같은 상황에서 중요합니다:
- 필요한 기능에 접근할 수 없음
- 세션 간 컨텍스트 손실
- 환경 간 일관성 없는 동작
- 감사 불가능
- 너무 많은 권한 보유
- 중단 후 깔끔하게 복구 불가능
모델이 안정적으로 작동할 수 없다면, 가장 먼저 살펴봐야 할 곳은 Harness입니다.
2. 루프 엔지니어링
그것이 무엇인가
모든 도구 사용 에이전트는 이미 작은 내장 루프를 가지고 있습니다:
- 모델 호출
- 결과 관찰
- 도구 실행
- 관찰 결과를 다시 피드백
- 완료될 때까지 반복
루프 엔지니어링은 의도적으로 그 동작 주변에 추가적인 사이클을 설계할 때 시작됩니다.
단순히 "다시 물어보는" 것이 아닙니다.
단순히 "재시도"하는 것도 아닙니다.
하지만 진정한 작업 및 피드백 시스템입니다.
좋은 루프의 구성 요소
트리거
무엇이 새로운 사이클을 시작하나요?
- 사용자 요청
- 실패한 테스트
- 새 문서
- 예약된 실행
- 웹훅
- 평가자 피드백
목표
우리가 도달하려는 특정 조건은 무엇인가요?
"계속 개선"이 아닙니다.
실제 목표입니다.
상태
다음 사이클이 알아야 할 것은 무엇인가요?
- 현재 초안
- 이전 시도
- 도구 결과
- 오류
- 진행 상태
행동 정책
에이전트가 무엇을 할 수 있나요?
- 편집
- 위임
- 도구 호출
- 토큰 소비
- 파일 쓰기
- PR 열기
증거
작동했는지 어떻게 알 수 있나요?
- 테스트
- 스키마 검증
- 인용
- 차이점
- 메트릭
- 검토자 승인
피드백
정확히 무엇이 실패했나요?
피드백은 간결하고 실행 가능해야 합니다.
중지 규칙
언제 종료되나요?
- 성공
- 시간 초과
- 예산 소진
- 최대 재시도 횟수 도달
- 복구 불가능한 실패
- 인간에게 에스컬레이션
루프 엔지니어링에서 가장 중요한 원칙
**확신에 대해 루프를 돌리지 마세요.
증거에 대해 루프를 돌리세요.**
"에이전트가 완료되었다고 말한다"는 중지 조건이 아닙니다.
실제 중지 조건은 다음과 같습니다:
- 테스트 통과
- 스키마 검증
- 인용 확인
- 검토자 승인
- 정책 검사 통과
이것이 루프 엔지니어링입니다.
루프 엔지니어링이 단순한 프롬프트 엔지니어링이 아닌 이유
프롬프트는 호출 중에 모델이 무엇을 해야 하는지 알려줍니다.
루프는 호출 후에 시스템이 무엇을 해야 하는지 정의합니다.
여기에는 다음이 포함됩니다:
- 결과를 확인하는 방법
- 실패에 대응하는 방법
- 진행 상황을 유지하는 방법
- 계속하기로 결정하는 방법
- 종료하는 방법
프롬프트는 응답을 개선합니다.
루프는 프로세스를 개선합니다.
이것은 매우 다른 엔지니어링 문제입니다.
3. 그래프 엔지니어링
그것이 무엇인가
그래프 엔지니어링은 워크플로우 구조를 명시적으로 만듭니다.
그것은 다른 질문에 답합니다:
단지 "에이전트가 무엇을 해야 하는가?"가 아니라 "무엇이 다음에 발생하도록 허용되는가?"입니다.
그래프 엔지니어링에서:
- 단계는 노드
- 전환은 엣지
- 분기는 명시적
- 병렬 작업은 명시적
- 결합은 명시적
- 재시도는 명시적
- 인간 개입은 명시적
그래프는 시스템의 제어 맵이 됩니다.
그래프 엔지니어가 실제로 설계하는 것
노드 경계
무엇이 속하는가:
- 결정론적 함수
- LLM 호출
- 전문가 에이전트
- 인간 검토 단계
상태 스키마
각 노드가 읽거나 쓸 수 있는 것.
라우팅 조건
어떤 증거가 작업을 이동시키는가:
- 앞으로
- 뒤로
- 옆으로
- 에스컬레이션으로
동시성
무엇이 병렬로 실행될 수 있고, 무엇이 기다려야 하는가.
사이클 및 종료
재시도가 허용되는 위치, 허용되는 횟수, 중단 방법.
내구성
체크포인트가 발생하는 위치와 중단 후 워크플로우가 재개되는 방법.
그래프가 가치 있을 때
그래프는 프로세스에 다음이 포함될 때 가치 있습니다:
- 의미 있는 분기
- 승인
- 전문가 핸드오프
- 병렬 작업
- 복구 경로
- 명시적인 제어 지점이 있는 다단계 워크플로우
작업이 단순히 다음과 같을 때는 덜 유용합니다:
"하나의 에이전트에 몇 가지 도구를 주고 작업하게 하라."
그런 경우, 견고한 Harness와 몇 개의 루프만으로 충분할 수 있습니다.
그래프는 명확성을 더하지만, 구조도 더합니다.
너무 이른 시기에 너무 많은 구조는 시스템을 취약하게 만들 수 있습니다.
3 가지 레이어가 함께 작동하는 방식
연구 및 게시 에이전트를 구축한다고 가정해 보겠습니다.
다음을 수행해야 합니다:
- 주제 범위 지정
- 소스 수집
- 인용 검토
- 보고서 초안 작성
- 법무 검토 통과
- 승인 후에만 게시
레이어가 매핑되는 방식은 다음과 같습니다:
Harness
제공:
- 브라우저 액세스
- 검색 도구
- 파일 작업 공간
- 메모리
- 인용
- 승인
- 트레이스
- 모델 라우팅
루프
처리:
- 증거가 약할 때 소스 검색 재시도
- 인용 실패 수정
- 평가자 검사 실행
- 시장 변화 시 작업 새로 고침
그래프
경로 제어:
- 범위 지정
- 연구
- 검토
- 종합
- 초안 작성
- 검토
- 게시
릴리스 전에 인간 게이트 포함.
그렇기 때문에 3 가지 레이어는 서로 대체할 수 없습니다.
함께 작동하지만, 동일한 것은 아닙니다.
수정 방법을 선택하기 전에 실패를 진단하세요
실용적인 규칙은 다음과 같습니다:
에이전트가 작동할 수 없으면 Harness를 수정하세요
예시:
- 누락된 도구 액세스
- 오래된 상태
- 약한 메모리
- 잘못된 권한
- 관찰 가능성 부족
에이전트가 거의 작동하지만 신뢰할 수 없으면 루프를 수정하세요
예시:
- 첫 번째 초안이 근접하지만 약함
- 성공이 일관되지 않음
- 재시도가 통제되지 않음
- 완료 증거 없음
프로세스 자체가 복잡하면 그래프를 수정하세요
예시:
- 많은 전문가
- 승인
- 분기 로직
- 병렬 경로
- 구조화된 핸드오프
일반적인 실수
1. 그래프를 너무 일찍 구축하기
팀은 작업이 실제로 어떻게 동작하는지 확인하기 전에 거대한 워크플로우를 다이어그램으로 그리는 경우가 많습니다.
더 나은 접근 방식:
- 더 간단한 Harness로 시작
- 트레이스 수집
- 안정적인 패턴 찾기
- 제어할 가치가 있는 것만 공식화
2. 동일한 모델이 안전장치 없이 작성과 평가를 하도록 허용하기
자체 검토는 도움이 될 수 있지만 동일한 사각지대를 공유합니다.
다음을 선호하세요:
- 가능한 경우 결정론적 검사
- 별도의 검토자 컨텍스트
- 외부 평가자
- 영향력이 큰 작업에 대한 인간 승인
3. "계속 시도"를 루프로 사용하기
그것은 루프 설계가 아닙니다.
통제되지 않은 비용 누수입니다.
모든 루프에는 다음이 필요합니다:
- 측정 가능한 목표
- 실제 증거
- 재시도 제한
- 에스컬레이션 규칙
4. Harness를 잡동사니 서랍처럼 취급하기
더 많은 도구가 자동으로 더 나은 에이전트를 의미하지는 않습니다.
너무 많은 도구는 다음을 만듭니다:
- 선택 실수
- 시끄러운 컨텍스트
- 약한 안정성
- 더 넓은 위험 표면
좋은 Harness는 복잡하지 않습니다.
정밀합니다.
5. 오케스트레이션 실패에 대해 모델을 비난하기
모델은 다음을 보상할 수 없습니다:
- 고장난 API
- 오래된 상태
- 누락된 종료 조건
- 모호한 도구 스키마
- 보이지 않는 실패 모드
실패를 소유한 레이어를 수정하세요.
간단한 프로덕션 체크리스트
Harness
- 도구가 좁고 문서화되어 있습니까?
- 상태가 지속적입니까?
- 권한이 최소 권한 원칙을 따릅니까?
- 운영자가 일시 중지, 검사 및 재개할 수 있습니까?
- 트레이스가 표시됩니까?
루프
- 어떤 증거가 성공을 입증합니까?
- 실패 시 어떤 피드백이 반환됩니까?
- 몇 번의 재시도가 허용됩니까?
- 중지 규칙은 무엇입니까?
- 예산이 소진되면 어떻게 됩니까?
그래프
- 어떤 경로가 결정론적이어야 합니까?
- 무엇이 병렬로 실행될 수 있습니까?
- 인간 게이트는 어디에 있습니까?
- 어떤 상태가 공유됩니까?
- 복구 경로는 어디에서 시작됩니까?
평가
- 실제 트레이스를 재생할 수 있습니까?
- 버전을 비교할 수 있습니까?
- 개선을 실제 변경에 기여할 수 있습니까?
운영
- 비용을 추적하고 있습니까?
- 지연 시간?
- 실패율?
- 개입율?
- 프로덕션에서의 작업 성공?
차이점을 기억하는 가장 간단한 방법
단 한 가지만 기억한다면, 이것을 기억하세요:
- Harness 엔지니어링은 모델을 작동 가능하게 만듭니다
- 루프 엔지니어링은 작업을 반복적이고 검증 가능하게 만듭니다
- 그래프 엔지니어링은 실행 경로를 명시적이고 제어 가능하게 만듭니다
어느 것도 다른 것을 대체하지 않습니다.
완벽한 그래프도 약한 Harness를 구원하지 못합니다.
강력한 Harness도 좋은 루프 없이는 여전히 비용을 낭비합니다.
그리고 깔끔한 루프는 분기와 승인이 임시 코드에 숨겨져 있으면 관리하기 어려워집니다.
신뢰할 수 있는 에이전트 시스템은 3 가지 레이어가 모두 의도적으로 설계될 때 나타납니다.
그것이 실제 아키텍처 스택입니다.
최종 요점
사람들은 AI 에이전트에 대해 마치 혁신이 모델인 것처럼 계속 이야기합니다.
프로덕션에서, 그것은 거의 실제 차별화 요소가 아닙니다.
차별화 요소는 모델 주변의 시스템입니다:
- 작업을 가능하게 하는 Harness
- 개선을 가능하게 하는 루프
- 통제 하에 운영되도록 하는 그래프
이것이 장난감 에이전트가 실제 시스템이 되는 방법입니다.
여기까지 읽으셨다면:
- 이것을 북마크하세요.
- [@LunarResearcher](https://x.com/@LunarResearcher) 팔로우
- 제 Substack 팔로우**
- 제 비공개 텔레그램 채널 팔로우**
