
AI 코딩 에이전트를 “코드를 잘 생성하는 챗봇”으로만 보면 핵심을 놓치기 쉽다. 최근 리뷰 논문 Code as Agent Harness가 강조하는 관점은 다르다. 코드가 에이전트의 결과물일 뿐 아니라, 추론하고 행동하고 환경을 모델링하며 실행 결과로 검증하는 운영 기반이 된다는 것이다.1
하네스: 모델을 실제 작업으로 연결하는 계층
논문은 에이전트 주변의 소프트웨어 계층을 ‘하네스’라고 부른다. 쉽게 말해 모델이 답변만 생성하는 것이 아니라 파일 시스템, 터미널, 도구, 메모리, 테스트 실행 같은 요소와 연결되어 실제 작업을 수행하게 만드는 구조다.
이 관점에서 중요한 질문은 “모델이 얼마나 똑똑한가?”에서 “그 모델이 어떤 실행 구조 위에서 움직이는가?”로 바뀐다. 같은 모델이라도 코드 실행, 도구 호출, 피드백 수집, 상태 관리가 어떻게 설계되어 있느냐에 따라 에이전트의 실용성은 크게 달라진다.
논문이 언급하는 Program-of-Thoughts, Chain of Code, Code as Policies 같은 접근도 이 흐름 안에서 이해할 수 있다. 공통점은 자연어 답변만으로 끝내지 않고, 코드를 통해 추론과 실행을 더 명시적이고 검증 가능한 형태로 만든다는 점이다.
좋은 에이전트는 실행 루프를 가진다
Code as Agent Harness는 코드 기반 에이전트 하네스를 세 계층으로 정리한다. 첫째는 코드가 에이전트의 추론, 행동, 환경 모델링과 만나는 인터페이스다. 둘째는 장기 실행을 위한 계획, 메모리, 도구 사용 같은 메커니즘이다. 셋째는 단일 에이전트에서 다중 에이전트로 확장되는 구조다.1
이 세 계층을 관통하는 핵심은 피드백 루프다. 에이전트가 코드를 작성하고, 실행하고, 실패 로그나 테스트 결과를 읽고, 다시 수정하는 과정이 있어야 한다. 이 루프가 있을 때 에이전트는 “그럴듯한 답변”을 넘어 “검증 가능한 작업”에 가까워진다.
다중 에이전트 환경에서는 공유 코드 산출물이 더 중요해진다. 여러 에이전트가 같은 코드, 테스트, 리뷰 결과를 기준으로 조정하고 검증할 수 있기 때문이다. 즉 코드는 결과물이면서 동시에 협업의 기준점이 된다.1
적용 분야보다 먼저 봐야 할 기준
코드 기반 하네스는 코딩 보조를 넘어 GUI·OS 자동화, 임바디드 에이전트, 과학 발견, 개인화·추천, DevOps, 기업 워크플로까지 확장될 수 있다.1 Anthropic의 Claude Code처럼 로컬 터미널, 개발 환경, 브라우저를 하나의 워크플로로 연결하는 도구도 이런 방향을 보여준다. OpenCode 같은 개발 도구 역시 터미널과 IDE 맥락에서 코드 기반 에이전트 경험을 제품화하려는 흐름으로 볼 수 있다.2
다만 적용 가능성이 넓다는 말이 곧 신뢰할 수 있다는 뜻은 아니다. 논문은 최종 작업 성공률만으로는 부족하다고 본다. 중간 계획이 타당했는지, 불완전한 피드백 아래에서도 검증이 가능한지, 여러 에이전트가 일관된 공유 상태를 유지하는지, 안전에 민감한 행동에는 사람이 감독할 수 있는지가 함께 평가되어야 한다.1
결국 코드 기반 AI 에이전트를 판단할 때는 모델 이름만 보면 안 된다. 어떤 코드 실행 환경을 갖췄는지, 테스트와 피드백 루프가 있는지, 메모리와 도구 사용이 어떻게 관리되는지, 사람이 개입할 지점이 명확한지를 봐야 한다.
코드 기반 에이전트의 경쟁력은 단순한 생성 능력이 아니라 실행 구조에서 나온다. 앞으로의 차이는 “누가 더 그럴듯한 코드를 쓰는가”보다 “누가 더 안전하고 검증 가능한 방식으로 코드를 실행하며 개선하는가”에서 갈릴 가능성이 크다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.
