에이전트 하네스 계층: 2026년 소규모 팀이 코딩 에이전트를 도입하기 전에 확인해야 할 것들

Codex, Cursor 같은 코딩 에이전트의 안전성과 비용은 모델이 아니라 하네스(샌드박스·도구·메모리·가드레일)가 결정합니다. 도입 전 점검할 다섯 가지.

핵심 요약

에이전트 하네스 — 모델이 아니라 — 가 파일시스템 접근, 네트워크 송신, 승인 흐름을 결정합니다.
2026년 5월 TanStack npm 사고로 경계 품질이 도입의 1급 기준이 됐습니다.
샌드박스·도구 접근·승인 정책·메모리 스코프·감사 로그 — 다섯 가지를 점검하세요.
위험도가 낮은 저장소에서, 벤더가 제공하는 가장 엄격한 샌드박스로 파일럿하세요.

다이어그램 1 — Agent Harness Coding Agents 개념도 — FIG. 1핵심 요약 — 본문 흐름을 한 장으로 본 그림입니다.

에이전트 하네스 계층: 소규모 팀이 코딩 에이전트를 도입하기 전에 확인해야 할 것들

코딩 에이전트는 모델 하나가 아닙니다. 모델은 코드를 작성하지만, 하네스(harness) 가 어떤 파일을 건드릴 수 있는지, 어떤 API를 호출할 수 있는지, 언제 사람이 승인해야 하는지, 그리고 문제가 생겼을 때 어떤 흔적이 남는지를 결정합니다. OpenAI Codex, Cursor, Claude Code 같은 도구를 도입하는 소규모 팀에게 도입의 안전성·예측 가능성·되돌릴 수 있는지를 결정하는 것은 모델이 아니라 하네스입니다.

다이어그램 2 — Agent Harness Coding Agents 개념도 — FIG. 2에이전트 하네스 계층: 소규모 팀이 코딩 에이전트를 도입하기 전에 확인해야 할 것들 — 본문 흐름을 한 장으로 본 그림입니다.

이 글은 이번 분기에 코딩 에이전트를 파일럿하려는 2~15인 엔지니어링 팀을 위한 실전 점검 가이드입니다.

“에이전트 하네스”란 정확히 무엇인가

Zapier의 최근 정리에 따르면 에이전트 하네스는 *”AI 모델을 실제로 동작하는 에이전트로 만들기 위해 모델을 감싸는 모든 것 — 도구, 메모리, 상태 유지, 컨텍스트 관리, 샌드박스 실행, 가드레일, 그리고 이들을 묶어주는 로직”* 입니다. 모델은 추론을 담당하고, 하네스는 외부 세계에 미치는 영향을 통제합니다.

같은 모델이라도 하네스에 따라 동작이 크게 달라지기 때문에 이 구분이 중요합니다. 승인 절차 없이 셸 명령을 자유롭게 실행하고 네트워크에도 제한 없이 접근하는 하네스에 연결된 모델은, 동일한 모델이 권한이 제한된 샌드박스 사용자로 실행되며 네트워크 접근이 명시적으로 통제되는 환경에서 돌 때와는 전혀 다른 운영 리스크입니다.

왜 모델보다 하네스가 더 중요해졌는가

2026년 5월, `@tanstack/*` 패키지에 대한 npm 공급망 공격이 발생해 설치 과정에서 자격 증명(credential)을 탈취하는 악성코드가 심어졌습니다. TanStack의 자체 포스트모템에 따르면 이번 사고는 42개의 `@tanstack/*` 패키지에 걸쳐 84개 버전이 영향을 받았습니다. OpenAI는 자사 사내 환경의 직원 단말 두 대가 영향을 받았고, 일부 코드 저장소 자격 증명 정보가 외부로 유출됐다고 공개했습니다. 다만 영향 범위는 제한적이었고 다른 정보나 코드에는 영향이 없었다고 밝혔습니다.

소규모 팀에게 중요한 포인트는 “에이전트는 위험하다”가 아닙니다. 한 번의 잘못된 `npm install` — 사람이 실행했든 에이전트가 실행했든 — 이 일으킬 수 있는 피해 반경은, 그 프로세스를 둘러싼 경계가 무엇이냐에 거의 전적으로 달려 있다는 점입니다. 좋은 하네스가 제공하는 것이 바로 그 경계입니다.

OpenAI가 동일 사고에 대해 후속으로 내놓은 Codex의 Windows 샌드박스가 이를 잘 보여줍니다. 에이전트는 권한이 낮은 전용 샌드박스 사용자 계정으로 실행되며, 작업 폴더 바깥의 파일시스템 쓰기는 차단되고 네트워크 접근은 방화벽 규칙으로 통제됩니다. Codex 공식 문서는 이런 제약 없이 실행하는 것이 *”Codex가 프로젝트 디렉토리에 한정되지 않게 되어 의도하지 않은 파괴적 동작으로 데이터 손실을 일으킬 수 있음”* 을 의미한다고 명시합니다. 이 경고는 오염된 의존성에서 비롯된 파괴적 동작에도 동일하게 적용됩니다.

도입 전 점검해야 할 다섯 가지 하네스 기능

1. 파일시스템·네트워크 샌드박스

에이전트가 평소 사용자 계정으로 실행돼 홈 디렉토리 전체에 읽기·쓰기가 가능하고 네트워크에도 무제한 접근하는가? 아니면 권한이 낮은 전용 사용자로 실행돼 쓰기는 작업 폴더로 한정되고 네트워크는 허용 목록으로 통제되는가?

Codex Windows 문서는 “elevated” 샌드박스 모드를 *”권한이 낮은 전용 샌드박스 사용자, 파일시스템 권한 경계, 방화벽 규칙, 로컬 정책 변경의 결합”* 으로 설명합니다. 벤더가 어떤 이름으로 부르든 이런 형태의 경계가 요구해야 할 기본선입니다.

2. 도구 접근 거버넌스

하네스는 모델이 호출할 수 있는 도구와 그 도구가 들고 다니는 자격 증명을 결정합니다. 2026년 Zapier가 정리한 MCP 서버 목록만 봐도 GitHub, AWS, Kubernetes, Supabase, Slack, Vercel, Google Workspace 커넥터가 포함되어 있고, 각각이 실제 프로덕션 액션 표면입니다. `git push –force`로 `main`을 덮어쓸 수 있거나 운영 AWS 계정을 호출할 수 있는 에이전트와, PR 생성까지만 가능한 에이전트는 전혀 다른 시스템입니다.

질문해야 할 것: 기본값으로 활성화된 도구는 무엇이며, 끄기는 얼마나 세분화돼 있는가?

3. 승인 정책 — 사람은 언제 개입하는가

좋은 하네스는 “자동 승인” 동작(파일 읽기, 린터 실행)과 “먼저 물어볼” 동작(파일 삭제, 커밋 푸시, 의존성 설치)을 구분합니다. 실패 패턴은 이분법입니다 — 명령마다 승인 클릭을 반복하거나, 아예 전체 권한 모드로 켜놓는 것. Codex Windows 문서는 샌드박스 제약을 유지하면서 예외 사항에 대해 승인 정책을 설정할 것을 권장합니다. 요구해야 할 정책의 형태가 이것입니다.

4. 메모리·컨텍스트 경계

에이전트는 상태를 유지합니다 — 대화 이력, 도구 호출 결과, 코드베이스에 대해 학습한 사실들. 이 메모리는 유용하지만 동시에 데이터 보호 표면이기도 합니다. 어디에 저장되는가? 프로젝트 간에 초기화되는가? 동료가 내가 비공개 저장소에서 가르친 내용을 볼 수 있는가?

5. 관측성과 감사

에이전트가 호출한 모든 도구 호출이 인자와 결과까지 검색 가능한 형태로 남아야 합니다. 그렇지 않으면 사후 분석은 추측에 의존하게 되고, 그것이 있어야 모든 리뷰어가 결국 묻는 질문 — *”에이전트가 정확히 무엇을 했는가?”* — 에 답할 수 있습니다.

도구별 비교

소규모 팀 도입 체크리스트

위험도가 낮은 저장소부터 파일럿. 파괴적 동작이 발생해도 회사가 흔들리지 않을 저장소를 고르세요 — 사내 도구, 문서 사이트, 개인 샌드박스.
벤더가 제공하는 가장 엄격한 샌드박스로 실행. 문서에서 명시적인 파일시스템·네트워크 경계를 찾으세요. 벤더의 “안전 모드”가 단지 “매번 승인 받기”라면 그 자체가 신호입니다.
일주일은 견딜 수 있는 기본 승인 정책 선택. 모든 프롬프트를 반사적으로 승인하고 있다면 정책이 너무 시끄러운 것입니다 — 승인을 끄지 말고 자동 승인 목록을 좁히세요.
에이전트가 접근 가능한 도구 목록 점검. 프로덕션에 영향을 줄 수 있는 것은 모두 비활성화 — 배포 훅, 패키지 퍼블리시, 강제 푸시 권한.
감사 로그를 실제 산출물로 다루기. 파일럿 기간 동안 매주 샘플링해 살펴보세요. 악성 동작만 찾는 게 아니라, 보지 않을 때 에이전트가 실제로 무엇을 하는지 학습하는 단계입니다.

FAQ

모델 선택은 여전히 중요한가? 중요합니다 — 품질, 지연, 비용을 결정합니다. 다만 같은 모델이라도 하네스가 다른 두 팀은 사고 후 회고 내용이 전혀 달라질 수 있습니다. 모델은 역량으로, 하네스는 운영 적합도로 고릅니다.

“전체 권한 모드”가 적절할 때도 있는가? 일회용 컨테이너, 일시적 CI 잡, 1인 개발 샌드박스에서는 그럴 수 있습니다. 그러나 프로덕션 자격 증명에 접근할 수 있는 공용 개발자 노트북에서는 OpenAI Windows 문서의 직설적 경고가 그대로 적용됩니다 — *”의도하지 않은 파괴적 동작으로 데이터 손실을 일으킬 수 있음.”*

MCP 서버는 하네스의 일부인가? 네. MCP는 하네스가 모델에 도구를 노출하는 표준 방법입니다. MCP 서버를 활성화할 때마다 같은 질문이 적용됩니다 — 어떤 자격 증명을 들고 있고 어떤 동작이 허용되는가?

소규모 팀 파일럿은 얼마나 길어야 하는가? 적어도 한 번의 위험천만한 순간 — 잘못된 파일, 너무 공격적인 리팩토링, 혼란스러운 승인 — 을 관찰할 만큼은 돼야 합니다. 매일 사용하는 2주가 보통 충분합니다. 놀랄 일이 전혀 없었다면, 아직 에이전트를 실제 작업에 충분히 노출시키지 않은 것일 가능성이 높습니다.

—

AI 네이티브 개발 도구: 소규모 소프트웨어 팀에서 실제로 달라지는 것 — LumoMate 홈 소개 ← LumoMate 홈으로 개발 도구 AI 네이티브 개발 도구:소규모 팀에서 실제로 달라지는 것 AI 코딩 어시스…
에이전틱 AI 비용 제어: 프로덕션 팀에 토큰 예산이 필요한 이유 — LumoMate 홈 소개 ← LumoMate 홈으로 AI 인프라 에이전틱 AI 비용 제어:토큰 예산이 필요한 이유 멀티턴 에이전트 루프는 …

—