새로운 리뷰 논문, 코드가 AI 에이전트의 사고와 행동 방식이지 단순히 생성물이 아니라고 주장

최근 발표된 한 리뷰 논문은 자율 AI 에이전트의 진짜 병목이 거대 언어 모델(LLM) 자체가 아니라 그것을 감싸는 소프트웨어 계층, 즉 '하네스(harness)'에 있다고 주장한다. LLM은 본질적으로 상태가 없는(stateless) 추론 엔진으로, 입력을 받아 토큰을 생성할 뿐 스스로 파일을 읽거나 명령을 실행하거나 이전 작업을 기억하지 못한다. 이를 실제로 동작하는 에이전트로 만드는 것은 도구 호출(tool calling) 인터페이스, 메모리·컨텍스트 관리, 테스트·검증 루프, 그리고 권한 경계(permission boundary)를 정의하는 코드다. 논문의 핵심 명제는 "모델 + 하네스 = AI 에이전트"라는 공식으로 요약되며, Deepseek이 베이징에 전담 '하네스 팀'을 꾸리고 있다는 사실은 이 관점이 단순한 학술적 주장이 아니라 산업계가 이미 받아들이고 있는 방향임을 보여준다. 즉, 에이전트의 '사고'와 '행동'은 모델 가중치가 아니라 그 주변을 둘러싼 엔지니어링에서 나온다는 것이다.

이 관점이 개발자에게 시사하는 바는 상당히 실질적이다. 그동안 에이전트 성능 개선은 "더 큰 모델, 더 좋은 프롬프트"라는 두 축에 집중되어 왔지만, 하네스 중심의 사고방식은 동일한 모델이라도 도구 설계·에러 복구·컨텍스트 주입 방식에 따라 결과물의 품질이 크게 달라진다는 점을 강조한다. 예를 들어 같은 LLM이라도 명확한 함수 시그니처와 구조화된 출력 스키마를 제공하고, 실패 시 재시도·검증 단계를 갖춘 하네스 위에서는 훨씬 안정적으로 동작한다. 이는 곧 AI 에이전트 개발이 '모델을 잘 고르는 일'에서 '신뢰할 수 있는 실행 환경을 설계하는 소프트웨어 엔지니어링'으로 무게중심이 옮겨가고 있음을 의미한다. 도구 인터페이스 정의, 권한·샌드박스 경계 설정, 관찰 가능성(observability), 멱등성과 재시도 전략 같은 전통적 백엔드 엔지니어링 역량이 그대로 에이전트 품질을 좌우하는 핵심 기술이 되는 셈이다.

따라서 에이전트 시스템을 다루는 개발자라면 모델 교체나 프롬프트 튜닝에만 매달리기 전에 자신이 만든 하네스의 견고함을 먼저 점검해 볼 필요가 있다. 구체적으로는 ① 도구 호출의 입력·출력 계약을 명확히 정의하고 실패 케이스를 구조화해 모델에 피드백하는지, ② 에이전트가 접근할 수 있는 권한과 부작용의 범위를 최소 권한 원칙으로 제한했는지, ③ 작업 결과를 검증하고 잘못된 동작을 차단하는 테스트·가드레일 루프가 있는지를 우선 검토하는 것이 좋다. 또한 메모리·컨텍스트 관리 전략(무엇을 기억하고 무엇을 버릴지)이 장기 작업의 일관성을 결정하므로, 이 부분을 설계 초기부터 명시적으로 다루어야 한다. 결론적으로 이 논문은 "좋은 에이전트는 좋은 모델이 아니라 좋은 코드에서 나온다"는 메시지를 던지며, 한국의 소프트웨어 엔지니어들에게는 LLM 활용 능력만큼이나 견고한 실행 계층을 설계하는 시스템 엔지니어링 역량이 앞으로의 경쟁력이 될 것임을 시사한다.