1. 단순한 텍스트 답변의 시대는 끝났습니다

불과 1년 전만 해도 LLM의 성능을 평가하는 기준은 단순했습니다. 모델이 내놓은 텍스트 답변이 얼마나 그럴듯한지, 문맥에 맞는지 'Vibe Check(느낌적인 확인)'를 하는 것만으로도 충분했기 때문입니다. 하지만 에이전트가 더 복잡해지고, 장기적인 작업을 수행하며, 스스로 환경에 개입하는 '액션 중심(action-oriented)' 모델로 진화하면서 상황은 완전히 달라졌습니다.

이제 에이전트는 단순히 말을 하는 수준을 넘어, 컴퓨터 파일 시스템에 직접 접근하고 코드를 실행하며 실제 환경을 변경합니다. 에이전트가 파일을 읽고 수정하는 단계에 이르면, 기존의 출력값 기반 평가는 더 이상 유효하지 않습니다. 에이전트가 내뱉은 말이 아니라, 에이전트가 남긴 '행동의 결과'를 검증할 수 있는 새로운 평가 프레임워크가 필요해진 것입니다.

2. 'Deep Agent'의 등장: 단순한 도구 호출을 넘어선 '합성 루프'

단순한 에이전트와 이른바 'Deep Agent(딥 에이전트)'를 구분하는 지점은 다단계의 확장된 작업을 설계하고 실행하는 능력에 있습니다.

  • Standard Agent (표준 에이전트): 루프 내에서 단순히 도구를 호출하고 응답을 받는 일차적인 수준에 머뭅니다.
  • Deep Agent (딥 에이전트): 플래닝 툴(Planning tool)을 통해 스스로 계획을 수립하고, 하위 작업을 위해 서브 에이전트(Sub-agents)를 호출하며, 파일 시스템에 직접 접근해 데이터를 읽고 씁니다.

Deep Agent의 핵심은 **'합성 루프(Synthesis Loop)'**에 있습니다. 예를 들어 '노이즈 오염(noise pollution) 보고서 생성' 작업을 맡은 에이전트는 단순히 정보를 요약하지 않습니다. 수많은 소스 파일을 읽고(Reading), 작업에 필요한 핵심 정보를 결정하며(Deciding), 이를 바탕으로 새로운 보고서를 특정 형식에 맞춰 작성(Writing/Synthesis)합니다. 이러한 지능형 계획을 평가하려면 에이전트의 '말'이 아닌, 환경 속에 생성된 '결과물'을 확인해야 합니다.

3. 왜 '샌드박스(Sandbox)'인가? 에이전트에 의한 환경 오염 방지

에이전트에게 파일 시스템 수정 권한을 부여할 때 발생하는 가장 큰 리스크는 '환경의 오염'입니다. 에이전트가 로컬 파일이나 설정을 변경하기 시작하면, 이후의 테스트는 이전 실행의 잔재에 영향을 받게 되어 평가의 객관성이 무너집니다. 이른바 '에이전트에 의한 환경 부패(environment rot)' 현상입니다.

Harbor는 이를 해결하기 위해 격리된 '샌드박스'를 제공하여 재현 가능한(reproducible) 평가를 보장합니다.

"에이전트의 역량이 강화되어 컴퓨터 전체에 접근하고 코드를 실행하게 됨에 따라, 단순히 텍스트에 등급을 매기는 방식에서 실제 환경 기반의 평가로 진화해야 할 임계점에 도달했습니다." — Nick, LangChain Software Engineer

샌드박스는 매 실행마다 에이전트에게 깨끗한 운동장을 제공함으로써, 코드 변경이나 프롬프트 수정이 에이전트의 성능에 미치는 영향을 결정론적으로 측정할 수 있게 합니다.

4. Harbor의 3대 아키텍처 기둥: 논리와 환경의 분리

Harbor 프레임워크는 에이전트의 로직과 실행 환경을 완벽하게 분리하는 세 가지 핵심 기둥 위에 구축되었습니다.

  • Agent (에이전트): 프롬프트, 도구, 로직이 포함된 컴파일된 함수입니다. 실제 운영 환경과 동일하게 langgraph.json이나 레지스트리 파일을 통해 의존성과 그래프 참조를 관리하며, 구조화된 방식으로 통합됩니다.
  • Sandbox (샌드박스): 에이전트가 활동할 격리된 공간입니다. 로컬 Docker 환경뿐만 아니라, 대규모 병렬 처리를 위한 LangSmith 클라우드 샌드박스를 지원합니다.
  • Data Set (데이터셋): 해결해야 할 구체적인 작업(Task)들의 모음입니다. 단순한 리스트가 아니라, 각 작업에 필요한 모든 환경 설정이 포함된 폴더 구조를 의미합니다.

5. 평가의 과학: 'Vibe Check'를 대체하는 결정론적 테스트

에이전트의 신뢰도를 확보하는 것은 '느낌'이 아니라 '데이터'여야 합니다. Harbor는 각 Task 폴더를 다음의 4가지 핵심 요소로 구조화하여 결과물을 객관적으로 검증합니다.

  1. task.toml: 타임아웃, CPU, 메모리 등 리소스 실행 구성을 정의합니다.
  2. instruction.md: 에이전트가 수행해야 할 메인 미션이 담겨 있습니다.
  3. environment 폴더: Docker 이미지를 포함하여, 모든 실행이 동일한 지점에서 시작되도록 보장하는 '리셋 버튼' 역할을 합니다.
  4. test 폴더 (pytest): 에이전트가 생성한 파일의 위치, 형식, 인용구의 정확성을 코드로 체크합니다.

또한, Harbor는 고도화된 비교를 위해 정답지 역할을 하는 **오라클 에이전트(Oracle Agent)**와 솔루션 폴더를 활용하여 에이전트의 작업 결과가 최적의 결과값에 얼마나 근접했는지 정밀하게 측정할 수 있습니다. 이를 통해 에이전트의 성공 여부는 주관적인 개입 없이 0 또는 1(Reward)로 명확히 판별됩니다.

6. 확장성과 가시성: Docker에서 LangSmith까지

Harbor는 소규모 로컬 리그레션 테스트(Regression testing)부터 대규모 클라우드 평가까지 유연하게 확장됩니다.

로컬 환경에서는 harbor run 명령어를 통해 실행할 수 있습니다. 이때 데이터셋 경로(-p), 에이전트 유형(--agent-type), 그리고 에이전트 로직이 담긴 프로젝트 경로(--project-path)를 파라미터로 지정하여 환경과 로직을 연결합니다. 더 나아가 클라우드 기반의 LangSmith 샌드박스로 전환하면 수많은 작업을 병렬로 처리하며 성능의 한계를 테스트할 수 있습니다.

LangSmith 플랫폼을 통해 시각화되는 메트릭은 에이전트 최적화의 나침반이 됩니다.

  • 보상(Reward): 결정론적 테스트 통과 여부.
  • 지연 시간(Latency): 작업 완료까지의 속도.
  • 토큰 사용량: 실행 비용의 효율성.

7. 에이전트 평가의 미래를 향한 질문

에이전트가 더 지능화되고 자율적인 권한을 가질수록, 우리는 그들이 마음껏 활동하면서도 통제 가능한 '안전한 운동장'을 먼저 구축해야 합니다. Harbor는 격리된 샌드박스와 결정론적인 검증 방식을 통해, 모호한 AI 응답의 시대를 끝내고 신뢰할 수 있는 에이전트 소프트웨어 공학의 시대를 열고 있습니다.

단순히 말을 잘하는 AI를 넘어, 실제 세상의 파일을 정확하게 다루고 복잡한 워크플로우를 완수하는 에이전트를 목표로 하고 있다면 이제 평가의 기반부터 재설계해야 할 때입니다.

"당신의 AI 에이전트는 오늘 샌드박스 안에서 안전하게 검증받고 있습니까?"