Agent2026년 8월 26일

소프트웨어 개발 하네스를 에이전트로 구현하는 기술 동향

#agent-harness#agentic-coding#multi-agent-orchestration#sandbox-isolation#swe-bench

같은 모델을 붙여도 어떤 코딩 에이전트는 리포지토리 하나를 통째로 리팩터링해내고 어떤 에이전트는 파일 하나를 고치다가 맥락을 놓친다. 이 차이를 만드는 것은 대개 모델이 아니다. 모델을 둘러싸고 도구를 연결하고 상태를 관리하고 결과를 검증하는 소프트웨어 층, 즉 하네스(harness)다. 소프트웨어 개발이라는 영역에서 하네스는 원래 테스트 하네스나 CI 파이프라인처럼 사람이 짠 코드를 기계적으로 검증하는 수동적 장치를 가리키는 말이었다. 그런데 이 장치 자체가 LLM을 품으면서 판단하고 계획하고 스스로 다음 행동을 정하는 능동적인 구조로 바뀌고 있다.

이 글은 그 전환을 다룬다. 코딩 에이전트의 하네스가 구조적으로 무엇을 책임지는지 그 책임이 최근 어떤 방향으로 확장되고 있는지 그리고 확장 과정에서 아직 해결되지 않은 채 구현자의 몫으로 남아 있는 문제가 무엇인지 순서대로 짚는다.

전제: 하네스는 모델을 제외한 모든 것이다

하네스를 가장 단순하게 정의하면 "모델을 제외한 에이전트의 나머지 전부"다. 여기에는 파일을 읽고 쓰는 도구, 셸 명령을 실행하는 인터페이스, 작업 컨텍스트와 세션 상태를 유지하는 메모리 계층, 그리고 모델 호출마다 어떤 정보를 넣고 뺄지 결정하는 컨텍스트 엔지니어링이 포함된다. LLM 자체는 상태를 갖지 않는다. 호출이 끝나면 그 전까지의 진행 상황을 스스로 기억하지 못한다. 하네스가 이 상태를 대신 짊어지고 다음 호출에 필요한 형태로 다시 넣어주기 때문에 비로소 단일 응답기가 여러 단계에 걸친 작업을 이어가는 에이전트로 기능하게 된다.

실무에서 이 구조는 한 겹으로 끝나지 않고 중첩된다. 핵심 모델 위에 에이전트를 만드는 쪽이 짠 하네스가 있고 그 위에 실제 사용자가 조직의 관례에 맞게 얹은 하네스가 다시 있다. 예를 들어 코딩 도구 자체의 실행 루프와 도구 호출 규약은 첫 번째 층이고 그 도구 위에 얹는 코딩 컨벤션 문서, 부트스트랩 스크립트, 아키텍처 정의서는 두 번째 층이다. 두 번째 층은 사람의 경험과 조직 지식을 코드가 읽을 수 있는 형태로 외재화하는 작업에 가깝다.

하네스를 구성하는 두 축: 사전 통제와 사후 피드백

하네스의 규제 방식은 크게 두 갈래로 나뉜다. 하나는 에이전트가 행동하기 전에 방향을 미리 잡아주는 사전 통제(feedforward control)이고 다른 하나는 행동한 뒤 결과를 보고 스스로 고치게 만드는 사후 피드백(feedback control)이다. 코딩 컨벤션 문서나 언어 서버(LSP) 프로토콜을 통한 타입 정보 제공이 전자에 속하고 정적 분석, 린터, 테스트 실행, 그리고 최근 늘어난 AI 코드 리뷰 에이전트가 후자에 속한다.

이 두 통제는 실행 방식의 성격에서도 갈린다. 정적 분석이나 테스트 실행처럼 결정론적이고 밀리초 단위로 끝나며 결과를 전적으로 신뢰할 수 있는 계산 기반(computational) 실행이 있고 코드 리뷰나 요구사항 충족 여부 판단처럼 의미론적 해석이 필요해 LLM에 다시 맡기는 추론 기반(inferential) 실행이 있다. 계산 기반 통제는 코드 품질이나 중복 제거처럼 이미 성숙한 영역에서 강하게 작동하지만 기능적 정확성처럼 맥락 이해가 필요한 판단은 여전히 추론 기반 통제에 의존해야 하고 이 영역의 신뢰도가 하네스 전체의 완성도를 좌우한다.

단일 에이전트에서 다중 에이전트 팀으로

초기의 코딩 에이전트 하네스는 한 개의 루프 안에서 계획하고 도구를 쓰고 결과를 확인하는 단일 에이전트 구조가 대부분이었다. 최근 흐름은 이 구조를 오케스트레이터 아래에 여러 전문화된 하위 에이전트가 병렬로 붙는 형태로 바꾸어 놓고 있다. 코드 작성을 맡는 에이전트와 테스트를 짜는 에이전트, 리뷰를 맡는 에이전트가 역할을 나눠 갖고 오케스트레이터가 작업을 쪼개고 결과를 합치는 구조다.

이 확장과 맞물려 두 가지 변화가 함께 나타난다. 첫째는 작업의 지속 시간이다. 한 번의 호출로 끝나는 짧은 작업이 아니라 시간 단위 심지어 일 단위로 이어지는 장기 작업을 하네스가 끊기지 않고 관리해야 하는 경우가 늘고 있다. 둘째는 인간 개입 시점의 판단이다. 모든 단계마다 사람에게 확인을 구하는 대신 에이전트 스스로 불확실성을 감지해서 꼭 필요한 지점에서만 입력을 요청하는 능력이 하네스의 설계 목표로 자리 잡고 있다. 두 변화 모두 하네스가 단순한 도구 중개자에서 작업 전체의 생명주기를 관리하는 상위 계층으로 올라서고 있다는 신호다.

실행 환경의 격리: 하네스가 떠안는 보안 책임

에이전트가 스스로 코드를 생성하고 그 자리에서 실행까지 하게 되면 하네스는 필연적으로 그 실행 환경의 안전을 책임져야 한다. 문제는 사람이 검토하지 않은 코드가 실행된다는 것 그리고 프롬프트 인젝션처럼 에이전트의 판단 자체를 오염시키는 공격 경로가 존재한다는 것이다. 이 문제에 대한 업계의 대응은 격리 기술의 계층으로 나타난다. 프로세스 수준에서 커널을 공유하는 표준 컨테이너는 빠르지만 커널 취약점을 통한 탈출 위험을 안고 있다. 사용자 공간에서 시스템 콜을 가로채는 방식은 공격 표면을 줄이지만 입출력이 많은 작업에서 성능 저하가 발생한다. 반면 하드웨어 수준의 격리를 제공하는 MicroVM 방식은 신뢰할 수 없는 코드를 실행하기에 가장 안전한 경계로 꼽히며 부팅 시간이 수백 밀리초 수준까지 줄어들면서 실용적인 선택지가 됐다.

격리는 한 축만으로 완결되지 않는다는 점도 실무에서 반복적으로 확인되는 교훈이다. 파일시스템 격리만 있으면 탈출 이후 네트워크로 정보가 유출될 수 있고 네트워크 격리만 있으면 자격 증명 파일 자체가 그대로 노출된다. 그래서 최근의 코딩 에이전트 하네스는 작업 디렉터리 바깥의 파일 수정을 차단하는 파일시스템 경계와 허용된 도메인으로만 트래픽을 통과시키는 네트워크 경계를 함께 두는 방향으로 수렴하고 있다. 이렇게 실행 환경 자체가 안전하다는 전제가 확보되면 역설적으로 매 단계마다 사람의 승인을 구하던 마찰이 줄어든다. 격리가 촘촘해질수록 에이전트에게 더 넓은 자율성을 안전하게 내줄 수 있다는 뜻이다.

벤치마크가 말해주는 것: 모델이 아니라 하네스가 점수를 가른다

같은 모델을 서로 다른 하네스에 얹었을 때 코딩 벤치마크 점수가 크게 갈린다는 사실은 이제 업계에서 반복적으로 확인되는 현상이다. 도구를 어떻게 노출하는지 실패한 시도를 어떻게 되돌리는지 컨텍스트를 언제 요약하고 언제 그대로 넘기는지 같은 하네스 설계의 세부가 점수 차이의 상당 부분을 설명한다. 이는 벤치마크를 해석할 때 모델의 원천 능력과 하네스가 만들어낸 성능을 구분해서 봐야 한다는 뜻이기도 하다. 동일한 평가 체계 안에서도 하네스를 무엇으로 두느냐에 따라 재현성 자체가 흔들릴 수 있다는 지적이 나오는 이유다.

구현 단계에서 남는 과제들

지금까지 살펴본 확장 흐름에도 불구하고 하네스를 실제로 구현하는 입장에서는 여전히 정답이 정해지지 않은 문제들이 남아 있다.

첫째, 장기 작업에서의 컨텍스트 관리다. 작업이 길어질수록 지금까지의 대화와 도구 호출 기록을 전부 다음 호출에 넣을 수 없기 때문에 언제 무엇을 요약하고 무엇을 버릴지 판단해야 하는데 이 판단을 잘못하면 에이전트가 앞서 확인한 제약을 잊고 같은 실수를 반복한다.

둘째, 다중 에이전트 간 책임 경계다. 하위 에이전트 여러 개가 병렬로 작업할 때 한 에이전트의 산출물이 다른 에이전트의 전제를 깨뜨리는 경우를 오케스트레이터가 어떻게 감지하고 조정할지에 대한 표준적인 방법은 아직 정립되지 않았다.

셋째, 격리 강도와 성능·비용의 균형이다. 신뢰할 수 없는 코드 실행에는 강한 격리가 필요하지만 격리가 강할수록 부팅 지연과 자원 비용이 늘어난다. 작업의 신뢰 수준에 따라 격리 강도를 동적으로 조절하는 판단은 결국 하네스를 만드는 쪽의 몫으로 남는다.

넷째, 개입 시점 판단의 신뢰도다. 에이전트가 불확실성을 감지해서 사람에게 입력을 요청하는 능력이 늘고 있지만 정작 개입이 필요한 상황을 놓치거나 반대로 사소한 판단까지 사람에게 떠넘기는 경우를 가려낼 기준은 아직 하네스마다 제각각이다.

정리 및 요약

코딩 에이전트를 실제로 움직이게 만드는 힘은 모델의 추론 능력 그 자체보다 모델을 감싼 하네스의 설계에서 나온다. 하네스는 도구를 연결하고 상태 없는 모델 호출 사이에 상태를 이어붙이는 역할에서 출발해 사전 통제와 사후 피드백을 함께 갖춘 규제 장치로 자리 잡았고 이제는 여러 전문화된 에이전트를 오케스트레이션하고 장기 작업의 생명주기를 관리하며 실행 환경의 보안 경계까지 책임지는 인프라 계층으로 확장됐다. 벤치마크 점수의 상당 부분이 모델이 아니라 하네스의 설계에서 갈린다는 사실은 이 계층의 무게를 단적으로 보여준다.

동시에 이 확장은 아직 끝나지 않은 확장이다. 장기 작업의 컨텍스트를 어떻게 다룰지 여러 에이전트의 책임을 어떻게 나눌지 격리와 성능을 어떻게 저울질할지에 대한 정답은 표준화되지 않았고 당분간은 각 구현체가 스스로 답을 찾아야 하는 영역으로 남을 것으로 보인다. 결국 소프트웨어 개발 하네스를 에이전트로 구현한다는 것은 모델 한 개를 잘 고르는 문제가 아니라 그 모델이 안전하게 오래 일할 수 있는 실행 인프라 전체를 설계하는 문제에 가깝다.

참고 자료

← Blog