Harness, Scaffold 및 AI 에이전트 용어 정리하기

AI 에이전트 생태계가 폭발적으로 확장되면서 "harness(하니스)"와 "scaffold(스캐폴드)" 같은 용어가 빈번하게 등장하지만, 팀마다 정의가 달라 혼선이 발생하고 있다. 기술적으로 harness는 LLM 모델 자체를 감싸는 런타임 계층을 의미한다. 즉, 컨텍스트 윈도우 관리, 도구(tool) 호출 라우팅, 권한 시스템, 후킹(hooks), 토큰 캐싱, 자동 압축 같은 인프라적 요소를 포괄한다. Claude Code, Cursor, Aider 같은 도구는 모두 동일한 베이스 모델 위에 서로 다른 harness를 구현한 사례다. 반면 scaffold는 에이전트가 작업을 수행하기 위한 구조적 템플릿—시스템 프롬프트 구조, 도구 정의 스키마, 워크플로 단계, 메모리/스킬 시스템 등—을 가리킨다. 같은 모델이라도 harness가 권한과 도구 실행 방식을 결정하고, scaffold가 추론과 작업 흐름을 결정하는 셈이다.

실무 관점에서 이 구분이 중요한 이유는 에이전트의 품질 차이가 모델 성능보다 harness/scaffold 설계에서 비롯되는 경우가 많기 때문이다. 동일한 Claude Opus 4.7을 사용하더라도 Claude Code의 SDK harness 위에서 동작할 때와 단순 API 호출만으로 동작할 때의 결과 품질은 큰 차이를 보인다. 컨텍스트 관리, parallel tool call, hook 기반 자동화, 권한 모드 같은 harness 레벨 기능이 코드 작성 정확도와 안정성에 직접 영향을 주기 때문이다. Scaffold 측면에서는 superpowers 스킬 시스템이나 PARA 메모리 구조처럼, 동일 모델이라도 "어떻게 사고하도록 유도하는가"가 결과를 크게 좌우한다. 따라서 팀에서 "에이전트 성능이 낮다"는 피드백이 나올 때, 모델 교체보다 harness/scaffold 개선이 더 효과적인 해법일 수 있다.

한국 개발자들이 액션 아이템으로 가져갈 점은 세 가지다. 첫째, 자체 에이전트나 워크플로를 구축할 때 harness 계층(권한, 도구 실행, 컨텍스트 관리)과 scaffold 계층(프롬프트 구조, 스킬, 메모리)을 명확히 분리해 설계하면 디버깅과 개선이 훨씬 쉬워진다. 둘째, Anthropic SDK나 OpenAI Agents SDK 같은 프레임워크를 사용할 때 어디까지가 SDK가 제공하는 harness이고 어디부터 내가 작성하는 scaffold인지 파악해야 책임 경계를 정의할 수 있다. 셋째, 사내 표준 용어집을 만들어 "에이전트", "워크플로", "툴", "스킬", "메모리" 등의 정의를 통일하면 코드 리뷰와 아키텍처 논의 시 발생하는 의사소통 비용을 크게 줄일 수 있다. 용어를 정확히 사용하는 것은 단순한 의미론 문제가 아니라, 시스템 경계를 명확히 하고 협업 효율을 높이는 엔지니어링 작업의 일부다.