실제로 사람들이 계속 혼동하는 세 가지 아키텍처 레이어에 대한 실용 가이드
혼란스러운 것은 이해할 수 있습니다. 세 가지 개념 모두 동일한 모델을 기반으로 하고, 모두 신뢰성에 영향을 미치며, 모두 "루프"를 포함할 수 있습니다. 하지만 이들은 동의어가 아닙니다. 각각은 다른 엔지니어링 결정을 설명하며, 에이전트가 데모 노트북을 벗어나 파일, API, 고객 또는 프로덕션 코드를 다루기 시작하는 순간 그 차이가 중요해집니다.
30초 요약
- Harness 엔지니어링은 모델 주변의 기계 장치를 구축합니다.
- Loop 엔지니어링은 반복적인 작업 및 피드백 주기를 설계합니다.
- Graph 엔지니어링은 워크플로우 토폴로지, 즉 노드, 분기, 조인, 상태 전환 및 제어된 주기를 명시적으로 만듭니다.
깔끔한 개념 모델은 환경 → 피드백 → 흐름입니다.
이 용어들이 갑자기 중요한 이유
원시 언어 모델은 텍스트를 생성하거나, 프로젝트 상태를 유지하거나, 테스트 스위트를 실행하거나, 브라우저를 보거나, 승인 규칙을 적용하거나, 실패한 작업을 다시 시작할 수 없습니다. 이러한 기능은 모델이 위치한 환경에서 비롯됩니다. 에이전트 소프트웨어가 성숙해짐에 따라 표준 엔지니어링 스택이 마침내 구체화되고 있습니다. 기초에는 에이전트 Harness, 즉 실제로 모델을 실행하는 코드가 있습니다. 다음은 반복 실행 및 품질 검사를 처리하는 루프입니다. 마지막으로 그래프는 전체 프로세스를 안내하는 구조화된 경로를 매핑합니다.
레이블은 아직 완전히 표준화되지 않았습니다. 현재 프레임워크에서 "에이전트 Harness"라는 용어는 상당히 구체적인 정의를 가지기 시작했습니다. "루프 엔지니어링"이라는 용어는 2026년 실무자들 사이에서 비교적 새로운 용어로 등장했습니다. 그래프 엔지니어링은 학문적 분야라기보다는 실용적으로 이해해야 합니다. 이는 에이전트 워크플로우를 명시적인 방향 그래프 또는 상태 머신으로 만드는 과정일 뿐입니다. 이러한 실용적인 구분은 유행어 뒤에 실제 설계 질문이 숨겨지는 것을 방지하기 때문에 유용합니다.
에이전트 Harness 엔지니어링
- Langchain에 따르면, 에이전트는 모델과 Harness의 결합이며, Harness는 모델 외부의 코드, 구성 및 실행 로직입니다. 실제로 여기에는 시스템 프롬프트, 도구 정의, 메모리, 파일 시스템, 샌드박스, 모델 라우팅, 핸드오프, 미들웨어 훅, 압축, 권한, 로깅 및 검증 인터페이스가 포함됩니다.
- OpenAI의 Agents SDK는 런타임 관점에서 동일한 운영 핵심을 설명합니다. 러너가 모델을 호출하고, 도구 호출을 실행하고, 핸드오프를 처리하고, 상태를 유지하며, 실행이 실제 종료 조건에 도달할 때만 중지됩니다.
Harness라는 단어는 모델 숭배에서 주의를 돌리기 때문에 유용합니다. 두 팀이 동일한 기반 모델을 사용하더라도 매우 다른 결과를 얻을 수 있습니다. 한 팀은 모델에게 깔끔한 도구, 안정적인 작업 공간, 제한된 권한 및 관찰 가능한 상태를 제공하는 반면, 다른 팀은 모호한 프롬프트와 신뢰할 수 없는 API 래퍼를 제공하기 때문입니다. 지능은 비슷할 수 있지만 작업 조건은 그렇지 않습니다. 진지한 Harness가 일반적으로 포함하는 것:
- 컨텍스트 주입: 지침, 검색된 사실, 대화 상태, 기술 및 작업별 정책
- 액션 표면: API, 브라우저, 셸, 코드 인터프리터, 데이터베이스 및 MCP 호환 도구
- 지속성: 파일, 체크포인트, 세션, 진행 로그, Git 히스토리 및 장기 기억
- 실행 제어: 타임아웃, 재시도, 예산, 모델 라우팅, 하위 에이전트 생성 및 승인 게이트
- 안전 및 거버넌스: 권한, 격리, 허용 목록, 비밀 처리 및 인간 승인
- 관찰 가능성: 추적, 도구 입력 및 출력, 상태 전환, 비용, 지연 시간 및 평가 결과
모델은 컨텍스트, 제어, 액션, 지속성 및 검증이라는 더 넓은 Harness 안에 위치합니다. 아키텍처 다이어그램에서 모델을 제거하십시오. 남은 모든 것은 아마도 Harness의 일부일 것입니다: 도구, 데이터 액세스, 상태 저장소, 샌드박스, 미들웨어, 평가자, 재시도 정책 및 UI.
Harness 엔지니어링이 빛을 발하는 곳
Harness 작업은 장기 실행 작업에 중요합니다. 다중 세션 코딩에서 Anthropic은 단순히 컨텍스트 압축을 사용하는 것만으로는 충분하지 않다는 것을 발견했습니다. 이것은 더 나은 프롬프트 자체가 아니라, 초기화기, 진행 파일, Git 히스토리 및 각각의 새로운 컨텍스트가 무슨 일이 일어났고 무엇을 해야 하는지 이해할 수 있는 점진적 작업 규율을 만드는 좋은 설정이었습니다. 에이전트에 대한 개선된 작업 시스템입니다. 에이전트에 기능이 없거나, 깔끔하게 돌아올 수 없거나, 상태를 잃거나, 너무 많이 액세스하거나, 감사할 수 없거나, 환경에 따라 다르게 작동할 때 Harness 엔지니어링을 적용하십시오.
루프 엔지니어링
도구를 사용하는 각 에이전트는 내장된 작은 루프를 가지고 있습니다:
- 모델 호출
- 결과 확인
- 도구 실행
- 관찰 내용을 모델에 입력
- 최종 답변이 반환될 때까지 반복
빌더가 의도적으로 해당 동작 주위에 새로운 주기를 구축하거나 쌓을 때, 이것이 OpenAI가 부르는 루프 엔지니어링의 시작입니다. 예를 들어, 검증 루프를 통해 에이전트는 아티팩트를 생성하고, 결정론적 검사 또는 평가자를 실행하고, 명시적인 피드백을 받고, 오류 증거가 있는 경우에만 반복할 수 있습니다. 이벤트 기반 루프는 일정, 웹훅 또는 새 문서가 수신될 때 에이전트를 깨웁니다. 개선 루프는 추적 및 실패를 분석하고, 지침/도구를 수정하고, 새 버전이 더 잘 작동하는지 테스트합니다. LangChain의 2026년 프레임워크는 이를 하나의 마법 같은 while 문이 아닌 루프 스택으로 지칭합니다.
잘 설계된 루프의 구성 요소:
- 트리거: 새로운 주기를 시작하는 것; 사용자 요청, 일정, 실패한 테스트, 새 데이터 또는 평가자 피드백
- 목표: 도달해야 할 특정 상태, "계속 개선"과 같은 모호한 지침이 아님
- 상태 및 메모리: 다음 주기가 모든 것을 다시 재생할 필요 없이 알아야 할 사항
- 액션 정책: 에이전트가 변경, 호출, 위임 또는 지출할 수 있는 것
- 증거: 테스트, 스키마 검증, 인용, 차이점, 메트릭 또는 인간 검토
- 피드백: 증거가 실패한 이유에 대한 간결하고 실행 가능한 설명
- 중지 규칙: 성공, 예산 제한, 타임아웃, 복구 불가능한 오류 또는 인간 에스컬레이션
검증 루프는 에이전트 루프를 외부 평가자와 명시적인 통과 조건으로 감쌉니다. 자신감에 대해 루프를 돌리지 마십시오. 증거에 대해 루프를 돌리십시오. "에이전트가 완료되었다고 말한다"는 중지 조건이 아닙니다. "테스트 통과, 링크 확인, 스키마 검증 및 검토자 승인"이 중지 조건입니다.
루프 엔지니어링이 단순한 프롬프트 엔지니어링이 아닌 이유
프롬프트는 호출 중에 모델에게 무엇을 할지 알려줍니다. 루프는 호출 후 시스템이 수행하는 작업을 지정합니다:
결과를 관찰하는 방법, 피드백을 선택하는 방법, 계속할지 여부를 결정하는 방법, 진행 상황을 유지하는 방법 및 종료하는 방법
프롬프트 품질은 여전히 중요하지만, 루프는 일회성 지침을 관리되는 프로세스로 변환합니다. 주요 트레이드오프는 비용과 지연 시간입니다. 각 평가자, 검토자 또는 재시도는 또 다른 모델 호출 또는 도구 실행을 추가합니다. Anthropic의 광범위한 지침은 작동하는 가장 간단한 아키텍처를 선호하고 성능 향상이 이를 정당화할 때만 에이전트 복잡성을 추가하는 것입니다. 동일한 조언이 루프에도 적용됩니다: 실패 비용이 검증 비용보다 높은 곳에 루프를 추가하십시오.
그래프 엔지니어링
그래프 엔지니어링은 다른 질문을 던집니다. 에이전트가 무엇을 하는지뿐만 아니라, 어떤 구성 요소가 다음에 실행될 수 있는지에 대한 질문입니다. 단계는 노드로 표시되고 허용된 단계는 엣지로 표시됩니다. 이러한 엣지는 순서, 조건부 분기, 병렬 팬아웃, 조인, 루프 및 인간 개입을 나타내는 데 사용될 수 있습니다. 상태는 그래프를 통과하며, 토폴로지를 통해 원하는 제어 흐름을 확인할 수 있습니다. LangGraph는 장기 실행, 상태 저장 에이전트를 위한 저수준 오케스트레이션 인프라로, 지속적인 실행, 상태 및 인간 참여 제어를 제공하며, 워크플로우 추상화보다는 에이전트에 대한 명시적인 제어에 초점을 맞춥니다. Microsoft AutoGen의 문서는 매우 직관적입니다: 에이전트 순서에 대한 정확한 제어, 다양한 결과에 대한 다른 다음 단계, 결정론적 분기 또는 주기가 있는 복잡한 다단계 프로세스가 필요할 때 그래프를 사용하십시오. 그래프 엔지니어가 실제로 결정하는 것:
- 노드 경계: 어떤 작업이 결정론적 함수, LLM 호출, 전문가 에이전트 또는 인간 검토 단계에 속하는지
- 상태 스키마: 각 노드가 읽거나 업데이트할 수 있는 것과 병렬 업데이트가 병합되는 방법
- 라우팅 조건: 어떤 증거가 작업을 앞으로, 뒤로, 옆으로 또는 에스컬레이션으로 보내는지
- 동시성: 병렬로 실행할 수 있는 것, 결합해야 하는 것, 조정이 필요한 공유 리소스
- 주기 및 종료: 재시도가 허용되는 위치, 허용되는 횟수 및 주기를 안전하게 만드는 요소
- 내구성: 체크포인트가 발생하는 위치와 중단 후 실행이 재개되는 방법
위의 캔버스는 에이전트, 기술 및 관계를 구성된 시스템으로 검사 가능하게 만듭니다. 여기서 그래프 엔지니어링은 그래프 기반 실행을 엔지니어링하는 것을 의미합니다. 이는 그래프가 데이터의 엔터티와 관계를 나타내는 지식 그래프 엔지니어링과 동일하지 않습니다. 워크플로우 그래프는 제어 및 상태 전환을 나타냅니다.
그래프가 그 복잡함을 감수할 가치가 있을 때
그래프는 프로세스에 의미 있는 분기, 병렬 작업, 승인, 복구 경로 또는 여러 전문가 에이전트가 있을 때 가치가 있습니다. 작업이 단순히 "에이전트 하나에 세 가지 도구를 주고 일하게 하는 것"이라면 그래프는 덜 유용합니다. 그래프는 디버깅을 개선할 수 있지만, 가정을 너무 일찍 고정시킬 수도 있습니다. 모델이 동적으로 계획을 발명해야 하는 경우, 가능한 모든 경로를 다이어그램으로 강제하면 시스템이 덜 취약해지기보다는 더 취약해질 수 있습니다.
세 가지 레이어가 하나의 실제 시스템에서 함께 작동하는 방식
사실적인 산업 브리핑을 생성하는 책임이 있는 연구 및 게시 에이전트를 고려해 보십시오.
중첩 구조에 주목하십시오: 그래프는 Harness 내에서 실행됩니다. 하나 이상의 루프가 그래프 내에 존재합니다. 그리고 Harness는 해당 루프에 필요한 상태, 도구 및 평가자를 제공합니다. 소프트웨어 레이어가 중첩되기 때문에 범주는 겹치지만, 각각은 시스템이 실패할 때 팀이 당길 수 있는 다른 레버를 제공합니다.
실패 진단을 통해 엔지니어링 레이어 선택하기
증상
시작 지점
가능한 해결책
에이전트가 안전하게 올바른 데이터나 도구에 액세스할 수 없습니다.
Harness
도구 계약, 권한, 샌드박스, 컨텍스트 주입.
에이전트가 세션 간 진행 상황을 잊어버립니다.
Harness
지속적인 상태, 체크포인팅, 진행 아티팩트, 압축.
첫 번째 시도는 종종 근접하지만 신뢰할 수 없습니다.
루프
외부 평가자, 결정론적 테스트, 피드백 및 제한된 재시도.
에이전트가 성공 후에도 계속 작업하거나 증거 전에 중지합니다.
루프
증거 기반 종료 상태 및 예산 인식 중지 규칙.
여러 전문가가 통제된 순서로 실행되어야 합니다.
그래프
명시적 노드, 엣지, 라우팅 조건 및 조인.
다단계 프로세스에서 실패 위치를 찾기 어렵습니다.
그래프 + Harness
그래프 노드 및 전환과 정렬된 상태 저장 추적.
고정된 다이어그램에는 워크플로우가 너무 자주 변경됩니다.
더 간단한 Harness
제어를 모델 기반으로 유지하고 그래프 공식화를 지연시킵니다.
취약한 에이전트 아키텍처 뒤에 숨은 비용이 많이 드는 실수
작업을 이해하기 전에 그래프 구축하기
팀은 때때로 유능한 에이전트가 실제로 문제를 해결하는 방식을 관찰하기 전에 비즈니스 프로세스를 수십 개의 노드로 변환합니다. 더 간단한 Harness의 추적으로 시작한 다음, 안정적인 경로를 공식화하십시오.
동일한 모델이 안전 장치 없이 작성하고 평가하도록 놔두기
자체 검토는 도움이 될 수 있지만 공유된 사각지대에 취약합니다. 가능한 경우 결정론적 검사를 선호하고, 검토자 컨텍스트를 분리하며, 영향력이 큰 작업에 대해 인간 승인을 요구하십시오.
루프 사양으로 "계속 시도" 사용하기
무제한 재시도 루프는 비용 누수입니다. 모든 루프에는 측정 가능한 목표, 새로운 증거, 최대 시도 횟수 및 명명된 에스컬레이션 경로가 필요합니다.
Harness를 쓰레기통 취급하기
더 많은 도구와 메모리가 자동으로 더 나은 것은 아닙니다. 복잡한 도구 세트는 선택 오류를 높이고, 시끄러운 컨텍스트는 혼란을 높이며, 광범위한 권한은 위험을 높입니다.
오케스트레이션 실패를 모델 탓으로 돌리기
모델은 오래된 상태, 모호한 도구 스키마, 손상된 API 또는 누락된 종료 조건을 안정적으로 보상할 수 없습니다. 실패를 소유한 레이어를 개선하십시오.
프로덕션 준비 설계 체크리스트
- Harness: 도구가 좁고, 문서화되어 있으며, 관찰 가능합니까? 상태는 지속적입니까? 권한은 최소 권한 원칙을 따릅니까? 운영자가 실행을 일시 중지, 검사 및 재개할 수 있습니까?
- 루프: 어떤 증거가 성공을 입증합니까? 실패 시 어떤 피드백이 반환됩니까? 얼마나 많은 재시도가 허용됩니까? 예산이 소진되면 어떻게 됩니까?
- 그래프: 어떤 경로가 결정론적이어야 합니까? 어디에서 작업을 병렬로 실행할 수 있습니까? 어떤 상태가 공유됩니까? 인간 게이트 및 복구 경로는 어디에 있습니까?
- 평가: 팀이 실제 추적을 재생하고, 버전을 비교하며, 개선을 직관이 아닌 특정 변경에 귀속시킬 수 있습니까?
- 운영: 비용, 지연 시간, 실패율, 개입률 및 작업 수준 성공이 프로덕션에서 모니터링됩니까?
차이점을 기억하는 가장 간단한 방법
무언가를 작동시키기 위해 엔지니어링하는 것은 모델을 만드는 것입니다. 루프 엔지니어링 방법론은 반복적이고, 검증 가능하며, 재개 가능합니다. 복잡한 실행 경로는 그래프 엔지니어링을 통해 명시적이고 제어 가능하게 만들어집니다. 이 세 가지 중 어느 것도 다른 것으로 대체될 수 없습니다. Harness가 상태를 잃었다면, 아무리 아름답게 그려진 그래프라도 충분하지 않습니다. 그러나 최고의 Harness가 있더라도 증거나 중지 규칙이 없다면 그것은 돈 낭비입니다! 신중하게 제작된 루프도 분기, 병렬 처리 및 승인이 임시 코드에 내장되어 있으면 작동하기 어렵습니다. 이 세 가지 레이어가 함께 설계된다면, 팀이 각 레이어가 해결해야 할 것이 무엇인지 알고 있을 때 안정적인 에이전트 시스템이 나타날 것입니다.
독자들이 사용하는 검색어
- 에이전트 Harness vs 루프 엔지니어링
- AI 에이전트를 위한 그래프 엔지니어링
- AI 에이전트 오케스트레이션
- LLM 에이전트 아키텍처
- 프로덕션 AI 에이전트
- LangGraph 워크플로우
- AutoGen GraphFlow
- 에이전트 검증 루프
출처 및 추가 자료
에이전트 Harness의 구조 - 에이전트 Harness가 AI 모델을 자율 작업 엔진으로 변환하는 방법을 알아보세요. 파일 시스템, 샌드박스, 메모리 등 핵심 구성 요소를 살펴보세요.
LangChain 및 LangGraph 에이전트 프레임워크, v1.0 마일스톤 달성 - LangChain 1.0과 LangGraph 1.0이 출시되었습니다. 표준화된 도구, 미들웨어 커스터마이징, 지속적인 상태로 프로덕션 준비 AI 에이전트를 더 빠르게 구축하세요.
GraphFlow (워크플로우) - AutoGen - 이 섹션에서는 GraphFlow 또는 간단히 "플로우"를 사용하여 다중 에이전트 워크플로우를 만드는 방법을 배웁니다. 구조화된 실행을 사용하며 에이전트가 작업을 수행하기 위해 상호 작용하는 방식을 정밀하게 제어합니다. 먼저 플로우를 생성하고 실행하는 방법을 보여드리겠습니다.
루프 엔지니어링의 기술 - 에이전트는 실제 작업을 자동화하지만, 안정적인 성능을 위해서는 좋은 모델 그 이상, 즉 특정 작업에 맞게 신중하게 설계된 Harness가 필요합니다. 이 게시물에서는 핵심 에이전트 루프, 루프를 쌓고 확장하여 더 효과적인 에이전트를 구축하는 방법, 그리고 LangChain 프리미티브로 각 레벨을 계측하는 방법을 살펴봅니다.
Microsoft Research의 AutoGen Studio 소개 - Microsoft의 유연한 오픈 소스 AutoGen 프레임워크를 기반으로 구축된 AutoGen Studio는 AI 에이전트를 오케스트레이션하여 개발자가 코드를 거의 또는 전혀 작성하지 않고도 다중 에이전트 AI 솔루션을 신속하게 구축, 테스트, 사용자 지정 및 공유할 수 있는 사용자 친화적인 인터페이스를 제공합니다.
사용자 정의 에이전트 Harness 구축 방법 - 효과적인 에이전트는 당면한 작업과 밀접하게 결합된 Harness로 구축됩니다. 사용자 정의 Harness를 구축하는 가장 쉬운 방법은 LangChain의 create_agent와 미들웨어를 사용하는 것입니다. 이 가이드는 핵심 에이전트 루프와 에이전트의 사용 사례에 맞게 사용자 정의하는 방법을 다룹니다.
에이전트 구축 실용 가이드 - AI 에이전트 설계, 오케스트레이션 및 배포에 대한 종합 가이드로, 사용 사례, 모델 선택, 도구 설계, 안전장치 및 다중 에이전트 패턴을 다룹니다.
효과적인 AI 에이전트 구축 - Anthropic과 고객사가 제공하는 프로덕션 준비 단일 및 다중 에이전트 시스템 구축을 위한 실용적인 조언과 지침입니다.
저장하세요, 잃지 않도록.
더 많은 기술 게시물을 보려면 @beamnxw를 팔로우하세요 :)
