9월 9일 수요일

장기 에이전트 시스템에서 하네스와 지식 계층은 무엇을 담당해야 하나

오늘 기술 원문들은 모델 가중치만으로 에이전트 품질을 설명할 수 없다고 말한다. YC Paper Club은 같은 모델도 어떤 하네스를 씌우느냐에 따라 관찰, 행동, 평가, 재시도 능력이 달라진다고 본다. 모델은 입력 토큰을 출력 토큰으로 바꾸는 신경망이지만, 실제 에이전트는 파일, 도구, 메모리, 실행 환경, 하위 에이전트와 연결되어야 한다. Tech Bridge의 지식 설계 원문은 이 연결을 스킬, MCP, RAG, 메모리로 나눠 설명한다. 반복 절차와 중단 판단은 스킬에, 외부 시스템 조회와 실행은 MCP에, 사람이 문서화한 지식 검색은 RAG에, 과거 경험에서 얻은 교훈은 메모리에 둬야 한다는 구분이다. Cursor 리팩터링 워크플로우는 이 원리를 개발 작업에 적용한다. Canvas로 코드베이스를 감사하고, Plan Mode로 목표 아키텍처와 TDD 계획을 만들며, Jira 티켓과 Cloud Agent PR, 테스트·스크린샷·동영상 증거로 변경을 쪼개 검증한다. 따라서 장기 에이전트의 핵심 설계 질문은 “모델이 똑똑한가”보다 “상태를 어디에 저장하고, 어떤 도구를 허용하며, 실패를 어떻게 관찰하고 되돌릴 것인가”다.

1. 01

   하네스는 프롬프트 길이가 아니라 실행 표현력이다

   YC 원문은 하네스를 단순한 프롬프트 보조물이 아니라 모델이 외부 세계를 읽고 행동하고 결과를 평가하는 실행 시스템으로 본다. ARC-AGI 사례처럼 같은 가중치도 실행 틀에 따라 점수가 크게 달라질 수 있다는 주장은 벤치마크 해석 자체를 바꾼다. 점수에는 모델의 추론력뿐 아니라 도구 호출, 상태 유지, 실패 복구가 함께 들어간다. 개발자가 볼 지점은 하네스가 모델의 사고를 대신한다는 뜻이 아니라, 모델이 무엇을 관찰할 수 있고 어떤 행동을 실제로 실행할 수 있는지의 인터페이스를 정의한다는 점이다. 파일 시스템, 테스트 러너, 브라우저, 평가 함수가 없으면 같은 모델도 긴 작업에서 확인과 수정의 루프를 만들 수 없다.

2. 02

   지식은 성격별로 다른 통로가 필요하다

   스킬, MCP, RAG, 메모리는 서로 대체재가 아니다. 런북처럼 반복 절차가 필요한 지식은 스킬이 맞고, 결제 시스템이나 로그처럼 외부 상태를 읽고 바꿔야 하는 일은 MCP가 맞다. 사내 문서 검색은 RAG로 가져오고, 이전 장애에서 얻은 교훈은 메모리에 남긴다. 한 컨텍스트에 모든 자료를 밀어 넣는 방식은 길을 잃기 쉽다. 예를 들어 체크아웃 500 오류를 고칠 때 절차 지식만 있으면 일반적인 점검표에 머무르고, MCP만 있으면 행동은 가능하지만 기준이 부족할 수 있다. 문서 검색과 과거 해결 메모리가 함께 붙어야 해당 서비스의 정상 상태와 반복된 실패 패턴을 구분할 수 있다.

3. 03

   리팩터링은 큰 요청이 아니라 감사와 티켓의 묶음이다

   Cursor 사례에서 안전한 레거시 리팩터링은 코드 생성을 크게 요청하는 방식이 아니다. 테스트 커버리지와 마이그레이션 우선순위를 먼저 보고, 계획을 티켓으로 나눈 뒤, 각 티켓을 원격 에이전트가 PR과 검증 증거로 제출하게 한다. 장시간 작업의 품질은 모델보다 CI, 브라우저 테스트, 사람의 리뷰가 둘러싼 경계에서 나온다.

4. 04

   제품 경계는 권한과 롤백까지 포함한다

   하네스가 강해질수록 에이전트는 더 많은 파일과 시스템을 바꿀 수 있다. 이때 필요한 것은 더 넓은 권한이 아니라 샌드박스, 관측 로그, 캐시와 컨텍스트 관리, 사람 검토, 빠른 복구 경로다. 구현자는 모델 호출 API만 설계해서는 부족하고, 에이전트가 실패했을 때 무엇을 남기고 어디서 멈추는지도 제품 계약으로 만들어야 한다.

기술 독자가 오늘 가져갈 결론은 분명하다. 에이전트 품질을 높이려면 모델 교체 이전에 하네스의 입출력, 도구 권한, 상태 저장, 평가 루프, 증거 산출을 설계해야 한다. 스킬은 절차를 고정하고, MCP는 실제 시스템 접점을 열며, RAG는 문서화된 지식을 검색하고, 메모리는 반복 경험을 축적한다. 개발 자동화에서는 이 층위를 티켓, PR, CI, 시각 증거, 리뷰 정책으로 연결해야 한다. 모델은 실행계 안에서만 제품이 된다. 이 구분은 비용 설계와도 연결된다. 모든 호출에 긴 문서를 넣으면 토큰 비용과 혼선이 커지고, 모든 일을 외부 도구에 맡기면 권한 위험이 커진다. 그래서 에이전트 플랫폼은 지식의 저장 위치, 호출 시점, 실패 시 복구 경로를 별도 계층으로 나누어야 한다.