2026년 임베딩 가능한 코딩 에이전트 하네스 추천 비교

Vercel AI SDK는 AI SDK 7을 통해 9개의 지원 코딩 런타임을 단일 제품 인터페이스 뒤로 통합하므로 종합적으로 가장 우수한 선택입니다. 이를 활용하면 향후 런타임 교체 시 UI 전체를 재작성하는 대신 어댑터 설정만 변경할 수 있습니다. 단, 샌드박스를 직접 관리하고 실험적 패키지 경계를 수용할 수 있어야 합니다.

요약: 어떤 하네스를 선택해야 할까?

임베딩 코딩 에이전트 하네스는 애플리케이션이 직접 호출하는 제어 계층입니다. 에이전트 루프, 툴, 권한, 세션, 컨텍스트 압축, 모델 접근 및 실행 환경을 적절히 결합하여 관리합니다. 이는 터미널이나 에디터에서 직접 사용하는 코딩 에이전트를 고르는 것과는 완전히 다른 의사결정입니다. 독립형 제품이 필요하다면 광범위한 AI 코딩 에이전트 비교를 먼저 확인하십시오.

새로운 TypeScript 제품을 개발 중이라면 Vercel AI SDK HarnessAgent가 종합적으로 가장 우수한 선택입니다. 호스트 애플리케이션에 Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode, Pi 전반에 걸친 단일 인터페이스를 제공합니다. 핵심 가치는 모든 런타임을 동일하게 만드는 것이 아닙니다. 스트리밍, 세션 라이프사이클, UI 통합, 샌드박스 할당 로직이 개별 제품 기능마다 파편화되어 침투하지 않도록 방지하는 데 있습니다. 단, 어댑터별 세부 기능은 차이가 있습니다.

전체 순위는 개발팀이 직접 소유하고 운영하려는 기술 스택의 범위에 따라 나뉩니다:

1. Vercel AI SDK HarnessAgent: 최고의 종합 이식성 계층
2. Claude Agent SDK: 가장 완성도 높은 벤더 런타임
3. OpenAI Codex SDK: Codex 네이티브 자동화에 최적화
4. Cursor SDK: 로컬 및 클라우드 통합 벤더 런타임
5. OpenHands Software Agent SDK: 최고의 오픈소스 원격 스택
6. OpenCode SDK: 최고의 타입 안전 클라이언트/서버 인터페이스
7. Pi: 가장 작고 유연한 에이전트 코어
8. fx and libfx: 실험적인 네이티브 및 브라우저 임베딩에 최적화

판단 기준은 명확합니다. 향후 코딩 런타임을 자유롭게 교체하는 것이 전략적으로 중요하다면 Vercel을 선택하십시오. 특정 벤더의 기본 제공 루프 자체가 제품 경쟁력이라면 Claude나 Codex를 직접 사용하십시오. 단일 SDK로 로컬 에이전트와 Cursor 호스팅 클라우드 에이전트를 모두 제어해야 한다면 Cursor를 사용하십시오. 오픈형 원격 서비스가 필요하다면 OpenHands나 OpenCode를 고르십시오. 가능한 가장 작은 루프를 직접 조합하고 싶다면 Pi가 적합합니다. 네이티브 바이너리 크기나 브라우저 WebAssembly 자체를 실험하는 목적이라면 fx를 쓰되, 확정된 보안 경계가 필요한 프로덕션 일정에서는 피하는 것이 좋습니다.

한눈에 보는 비교

가격과 기능은 2026년 9월 1일 기준으로 확인되었습니다. "시작 가격"은 SDK 또는 오픈소스 패키지 기준입니다. 모델 토큰, 컴퓨팅, 스토리지 및 네트워크 비용은 배포하는 아키텍처에 따라 달라지므로 별도로 청구됩니다.

실제 비용 구조 살펴보기

SDK 라이선스 비용이 예산에서 가장 큰 비중을 차지하는 경우는 드뭅니다. 모델 출력, 긴 컨텍스트, 샌드박스 수명, 재시도 횟수, 사람의 검토 작업이 실제 비용을 좌우합니다. 무료 오픈소스 패키지라도 매우 비싼 에이전트를 구동할 수 있으며, 유료 호스팅 플랜이라도 운영 부담을 충분히 덜어준다면 더 경제적인 선택이 될 수 있습니다.

일반적인 워크로드를 기준으로 규모를 계산해 보겠습니다. 각 작업 실행 시 입력 20,000토큰 및 출력 5,000토큰을 소비하고, 영업일 기준 하루 100회, 한 달 22영업일 동안 작동한다고 가정합니다. 이는 월 2,200회 실행에 해당합니다. 이는 벤치마크가 아닌 비용 분석 프레임워크이며, 기본 가정을 투명하게 유지하기 위해 캐싱은 의도적으로 제외했습니다.

현재 Claude Sonnet 5 API 가격인 1백만 토큰당 입력 $2 및 출력 $10를 기준으로 한 모델 비용은 다음과 같습니다:

• 입력: 20,000 / 1,000,000 x $2 = 회당 $0.04
• 출력: 5,000 / 1,000,000 x $10 = 회당 $0.05
• 합계: 회당 $0.09, 2,200회 실행 시 월 $198

현재 프로모션 중인 GPT-5.6 Sol 가격인 1백만 토큰당 입력 $4 및 출력 $20 기준으로는 회당 $0.18, 월 $396가 됩니다. 이는 두 모델이 완전히 동일한 품질을 낸다는 의미가 아닙니다. 어떤 모델을 선택하는지, 그리고 에이전트가 얼마나 자주 재시도하는지가 라이브러리 라이선스보다 예산에 훨씬 더 큰 영향을 미친다는 점을 보여줍니다.

여기에 Vercel Sandbox 가격 정책 예시를 더해보겠습니다. 1 GB 샌드박스를 10분 동안 프로비저닝하고 CPU가 2분 동안 활성 작동할 경우, 현재 요율인 활성 CPU 시간당 $0.128, 프로비저닝된 GB-시간당 $0.0212 기준으로 회당 약 $0.0078이 발생합니다. 2,200회 실행 시 데이터 전송 및 스토리지를 제외한 순수 CPU 및 메모리 사용 요금은 약 $17.16입니다. Vercel Pro는 월 $20이며 $20의 사용량 크레딧을 포함하므로, 이 연산 프로필은 해당 크레딧 내에 수용됩니다. 2,200회 샌드박스 생성 요금은 1백만 회당 $0.60 요율 기준 약 $0.00132가 추가됩니다. Hobby 플랜은 5,000회 생성을 포함하지만 개인적, 비상업적 용도에 한하며 추가 사용량을 구매할 수 없습니다.

선정 및 평가 기준

선정 기준은 호스트 애플리케이션에서 공식 문서화된 SDK, 라이브러리, 프로토콜 또는 서버 API를 통해 프로그래밍 방식으로 제어할 수 있는지 여부였습니다. 단순 터미널 명령어는 제외했습니다. 에디터 플러그인도 제외했습니다. 벤치마크 프레임워크나 프롬프트 모음은 정식 제품 통합 인터페이스를 제공하지 않는 한 평가 대상에 포함하지 않았습니다.

이 기준으로 수많은 후보군을 8개 옵션으로 압축했습니다. 시중의 광범위한 목록은 대개 공식 런타임 SDK와 스킬 라이브러리, 연구용 프레임워크, 최종 사용자용 제품을 마구 섞어둡니다. 이러한 혼합 카탈로그보다 8가지 솔루션을 심층 평가하는 것이 훨씬 실용적입니다. 실제 기술 선택의 분기점은 운영 경계에서 나타나기 때문입니다.

순위에 오른 각 옵션은 다음 5가지 기준으로 검토되었습니다:

• 임베딩 계약 (Embedding contract): 호스트가 호출, 스트리밍, 재개, 중단할 수 있는 범위
• 실행 경계 (Execution boundary): 코드가 프로세스 내에서 실행되는지, 서브프로세스로 실행되는지, 서버 뒤에서 구동되는지, 샌드박스에서 격리되는지 여부
• 상태 소유권 (State ownership): 대화 기록, 작업 파일, 자격 증명, 재개 데이터를 누가 저장하는지
• 정책 제어 (Policy control): 권한, 툴 승인, 테넌트 격리, 네트워크 규칙이 어디에 상주하는지
• 전환 비용 (Exit cost): 런타임이나 모델을 변경할 때 기존 제품 코드 중 얼마를 유지할 수 있는지

임의의 주관적 제품 테스트는 배제했습니다. 평가는 현재 벤더 문서, 최신 가격, 명시된 보안 경계, 그리고 위의 비용 모델을 기반으로 진행되었습니다. 화려한 데모 영상보다 안정적인 기술 계약을 중시한 평가 방식입니다. 임베딩 결정은 제품 출시 홍보 영상보다 훨씬 오래 유지되기 때문입니다.

1. Vercel AI SDK HarnessAgent: 최고의 종합 이식성 계층

Vercel AI SDK HarnessAgent는 여러 코딩 런타임을 아우르는 단일 애플리케이션 인터페이스를 원하는 TypeScript 제품에 가장 이상적인 솔루션입니다. AI SDK 7은 Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode, Pi를 공식 지원하며, 하위 패키지를 통해 세션, 스트리밍, 권한, 스킬, 컨텍스트 압축, 샌드박스 접근을 표준화합니다. 예컨대 Claude Code로 코드 리뷰 서비스를 시작한 뒤 채팅 UI나 작업 라이프사이클을 뜯어고치지 않고 Codex를 교차 검증하려는 제품에 완벽히 들어맞습니다. 다만 단점도 존재합니다. @ai-sdk/harness는 여전히 실험적(experimental) 단계이며, 브리지 기반 어댑터 대다수는 포트가 개방된 네트워크 샌드박스를 필요로 합니다.

최적의 대상: 런타임 이식성을 제품의 핵심 리스크 대비책으로 여기는 TypeScript 개발팀
차별점: 여러 코딩 런타임 전반에 걸친 AI SDK 호환 생성 및 스트리밍 결과 제공
가격: Apache-2.0 패키지는 오픈소스입니다. Vercel Hobby 및 Pro는 각각 월 $0 및 월 $20이며, Pro에는 $20의 사용량 크레딧과 무료 체험이 포함됩니다. Enterprise는 맞춤 견적입니다. Vercel Sandbox 사용량은 활성 CPU 시간당 $0.128, 프로비저닝된 GB-시간당 $0.0212부터 시작합니다.
무료 체험: Vercel은 무료 Pro 체험을 제공하며, 라이브러리 자체는 오픈소스입니다.

Vercel을 선택해야 하는 가장 강력한 이유는 단순한 편의성이 아니라 비즈니스 협상력에 있습니다. 프롬프트, UI 상태, 출력 스키마, 작업 기록, 평가 이벤트가 어댑터 상위 계층에 존재한다면, 런타임 교체 작업이 수반되더라도 전체 제품을 처음부터 다시 개발할 필요는 없어집니다. 특정 공급업체가 인증 정책을 변경하거나 모델 요금이 인상될 때, 혹은 다른 에이전트 루프가 회사 코드베이스에서 더 우수한 성능을 낼 때 이러한 유연성은 결정적인 무기가 됩니다.

이 추상화 계층에는 명확한 한계점도 있습니다. Claude Code, Cline, Codex, Cursor, Deep Agents, fx, OpenCode, Pi와 같은 브리지 기반 어댑터는 현재 네트워크 샌드박스 세션을 필요로 하며, Grok Build는 호스트 프로세스를 사용합니다. 즉, "이식성이 뛰어나다"는 말이 "코드 변경 없이 어디에나 즉시 배포할 수 있다"는 뜻은 아닙니다. 애플리케이션 수준의 계약은 안정적으로 유지되되, 런타임별 구체적 실행 환경은 어댑터에 맞게 구성해야 합니다.

2026년 8월 31일부터 Vercel의 공식 @ai-sdk/harness-fx 어댑터를 통해 HarnessAgent와 fx 간 ACP 통신을 지원하면서 fx가 9번째 공식 지원 하네스가 되었습니다. 이 어댑터는 공통 인터페이스를 유지하지만, fx는 이 계층에서 정형 출력, 수동 압축, 턴 중간 지시(mid-turn steering), 기본 제공 툴 필터링을 지원하지 않습니다. 심층적인 트레이드오프는 Vercel의 fx AI SDK 하네스 어댑터 상세 분석에서 다룹니다.

현재 @ai-sdk/harness 패키지 버전은 1.0.96에 도달했습니다. 실험적 경계 내에서 버전 번호가 빠르게 올라간다는 점을 개발 일정에 반영해야 합니다. 패키지 버전을 엄격히 고정(pinning)하고, 업그레이드 전 반드시 계약 테스트를 수행하며, 원시 런타임 이벤트를 저장하여 추후 재생할 수 있도록 아키텍처를 설계하십시오.

1. 1

   제품 계약을 먼저 정의하십시오

   특정 런타임 이름을 지정하지 말고 입력값, 허용되는 리포지토리 범위, 필수 JSON 출력 형식, 취소 동작, 최대 예산을 먼저 정의하십시오. 초기 과제로는 변경된 파일 목록, 테스트 상태, 간결한 위험 분석 노트를 반환해야 하는 실패 테스트 수정 작업이 적합합니다.

2. 2

   단 하나의 어댑터로 시작하십시오

   Node.js 22 ESM 서비스 환경에 AI SDK 7을 설치하고, 런타임 어댑터 하나를 선택한 뒤 각 세션에 격리된 작업 디렉터리를 할당하십시오. UI에 런타임 선택 메뉴를 미리 만들지 마십시오.

3. 3

   격리 환경을 명시적으로 구성하십시오

   브리지 기반 어댑터의 경우 네트워크 샌드박스를 확보하고, 작업 디렉터리를 설정하며, 재현 가능한 종속 항목만 부트스트랩한 뒤 문서화된 라이프사이클에 따라 세션을 파기하거나 중단하십시오. 인증 정보는 에이전트 작업 공간 외부에 보관해야 합니다.

4. 4

   4가지 핵심 판단 지표를 기록하십시오

   모든 실행에 대해 작업 완료 여부, 권한 거부 건수, 토큰 사용량, 총 소요 시간을 기록하십시오. 이 데이터가 있어야 어댑터 변경이 실제로 비용을 절감하는지, 아니면 장애 지점을 다른 곳으로 옮길 뿐인지 검증할 수 있습니다.

5. 5

   두 번째 런타임으로 재생 테스트를 수행하십시오

   동일한 제품 계약 뒤에 두 번째 어댑터를 추가하고 동일한 리포지토리 작업을 재생하십시오. 일반적인 외부 벤치마크가 아니라 실제 운영 워크로드에서 두 번째 런타임의 우수성이 입증될 때까지는 첫 번째 런타임을 유지하십시오.

2. Claude Agent SDK: 가장 완성도 높은 벤더 런타임

Claude Agent SDK는 완전한 Claude Code 루프 자체가 단순한 구현 방식이 아니라 핵심 기능일 때 가장 강력한 직접 선택지입니다. 동일한 에이전트 루프, 컨텍스트 관리, 파일 툴, 명령어 실행, 웹 검색, MCP, 권한 제어를 Python과 TypeScript로 제공합니다. 엄격한 권한 정책과 장시간 조율 가능한 리포지토리 세션이 필요한 보안 검토 서비스의 경우 최소형 루프보다 이 SDK에서 훨씬 완성도 높은 동작을 즉시 얻을 수 있습니다. 완성도의 대가는 벤더 종속성과 더불어 호스트가 신중히 관리해야 하는 서브프로세스 및 테넌트 격리 모델입니다.

최적의 대상: Claude Code의 내장 루프와 기본 툴셋에 제품 차별성을 둔 서비스
차별점: Claude Code와 완전히 동일한 에이전트 루프 및 컨텍스트 관리를 Python과 TypeScript로 프로그래밍 가능
가격: 사용량 기반 요금제입니다. 현재 Claude API 티어는 1백만 입력/출력 토큰당 Fable 5가 $10/$50, Opus 5가 $5/$25, Sonnet 5가 $2/$10, Haiku 4.5가 $1/$5입니다.
무료 체험: 별도의 Agent SDK 무료 체험은 제공되지 않습니다.

조합해야 할 구성 요소의 수를 최소화하고 싶을 때 Claude는 훌륭한 선택지입니다. 툴 호출 순서 제어, 컨텍스트 용량 초과 처리, 권한 확인 프롬프트를 바닥부터 개발할 필요 없이 검증된 코딩 루프를 바로 사용할 수 있습니다. 애플리케이션 코드는 대폭 줄어들지만, 기능 동작의 상당 부분이 단일 공급업체의 릴리스 정책에 종속됩니다.

프로덕션 도입은 프로세스 리소스 계획부터 시작해야 합니다. Anthropic은 에이전트당 최소 사양으로 1 GiB RAM, 5 GiB 디스크, 1 CPU를 권장하며, 이는 상한선이 아닙니다. 각 세션은 독립된 서브프로세스를 점유합니다. 따라서 다수의 동시 세션을 처리하는 컨테이너 환경에서는 단순 오토스케일링 규칙에 의존하지 말고, 세션별 메모리 한도를 명확히 측정하고 인입 제어(admission control)를 구성해야 합니다.

영속성 역시 주의 깊게 살펴봐야 할 경계입니다. SessionStore는 대화 기록을 S3, Redis, Postgres 또는 커스텀 어댑터로 미러링하지만, CLAUDE.md 메모리 파일이나 작업 디렉터리의 나머지 파일은 보존하지 않습니다. 미러링 실패 시 mirror_error 이벤트가 발생하며 쿼리는 계속 진행됩니다. 고객이 중단된 작업을 완벽히 재개할 수 있어야 한다면, 해당 이벤트에 대한 알림을 구축하고 작업 공간 아티팩트를 별도로 동기화하는 로직을 반드시 구현해야 합니다.

테넌트 격리에도 명시적인 설정이 필요합니다. 공유 프로세스 환경에서는 다른 테넌트의 파일시스템 설정과 메모리를 잘못 읽어올 위험이 있습니다. 문서화된 프로덕션 패턴에 따라 테넌트별 독립 구성 디렉터리와 작업 디렉터리를 분리하고, 자동 메모리 기능을 비활성화하며, 파일시스템 설정 소스를 초기화하고, 에이전트 외부에서 송신(egress) 규칙을 강제해야 합니다. 이 작업이 선행되어야 데이터 유출 없는 안전한 에이전트 임베딩이 완성됩니다.

3. OpenAI Codex SDK: Codex 네이티브 자동화에 최적화

OpenAI Codex SDK는 Codex 스레드, 스트리밍 진행 상황, 스키마 제약 기반 리포지토리 작업을 구현하는 가장 직관적인 직접 접근 경로입니다. 공식 TypeScript 패키지는 Codex CLI를 래핑하여 표준 입출력(stdin/stdout)을 통해 JSONL 데이터를 교환합니다. 변경된 파일, 테스트 결과, 릴리스 노트가 포함된 고정 JSON 객체를 반드시 반환해야 하는 배포 봇에 매우 적합합니다. 다만 아키텍처적 종속성이 존재합니다. SDK가 CLI 프로세스를 직접 실행하며, 기본 작업 공간 정책은 Git 리포지토리를 전제로 합니다.

최적의 대상: 이미 Codex 및 OpenAI 인증 인프라를 채택한 제품
차별점: 스트리밍 정형 이벤트 및 JSON Schema 출력을 지원하는 지속성 스레드
가격: SDK는 Apache-2.0입니다. GPT-5.6 Sol API 가격은 현재 프로모션 기준 1백만 토큰당 입력 $4, 출력 $20입니다.
무료 체험: 오픈소스 SDK 자체에는 해당 사항이 없으며, 모델 및 구독 접근 권한은 별도입니다.

Codex가 Claude보다 순위가 낮은 이유는 본 평가가 보다 포괄적인 내장 호스팅 생태계를 높게 평가했기 때문입니다. 이미 Codex 작업을 스케줄링하고 있는 제품이라면 Codex SDK가 더 나은 선택일 수 있습니다. API는 실용적인 제품 기본 요소를 갖추고 있습니다. 스레드가 대화 상태를 유지하고, runStreamed()가 진행 상황을 노출하며, 출력 스키마를 통해 후속 코드가 긴 텍스트를 파싱할 필요 없이 잘못된 형식의 결과를 즉시 거부할 수 있습니다.

서브프로세스 아키텍처가 무조건 단점인 것은 아닙니다. stdin/stdout을 통한 JSONL 방식은 디버깅이 용이하고, 경계면에서 언어 중립적이며, CLI 내부의 잦은 변경으로부터 SDK를 보호합니다. 다만 프로세스 시작 시간, CLI 바이너리 가용성, stdout 제어, 종료 처리를 프로덕션 런북에 철저히 반영해야 합니다. 웹 요청 하나가 무제한 실행되는 자식 프로세스로 이어져서는 안 됩니다.

TypeScript 환경에서 스레드 상태는 ~/.codex/sessions 경로에 저장됩니다. 이러한 로컬 기본값은 로컬 개발자에게는 편리하지만, 임시 컨테이너 환경에서는 유일한 영속성 방안으로 삼기에 매우 위험합니다. 스레드 ID를 고객 작업에 매핑하고, Codex 홈 경로를 직접 제어하며, 인스턴스가 종료되기 전에 필요한 상태를 영구 스토리지로 복사하십시오.

개발자가 Codex, Claude Code, Cursor를 직접 사용하는 방식의 비교가 궁금하다면 Codex vs Claude Code vs Cursor 비교에서 작업 워크플로를 다루고 있습니다. 본 SDK 선택은 호스트 애플리케이션이 Codex 스레드를 직접 생성하고 감독할 것인지 여부에 집중됩니다.

4. Cursor SDK: 로컬 및 클라우드 통합 벤더 런타임

Cursor SDK는 단순한 에디터 연동을 넘어 공식 지원되는 임베딩 기술 계약으로 발전했습니다. TypeScript 및 Python SDK를 통해 동일한 에이전트를 두 가지 실행 모드로 제공합니다. 로컬 에이전트는 호출 애플리케이션과 함께 실행되며, 클라우드 에이전트는 Cursor가 관리하는 격리된 가상 머신에서 작동합니다. 지속성 클라우드 에이전트를 시작해 실행 상태를 스트리밍하고 작업을 취소할 수 있으며, 코드가 개발자 로컬 머신에 머물러야 할 때는 로컬 경로를 활용할 수 있습니다. 다만 양쪽 모드 모두 Cursor 런타임에 종속되며, 고객 대면 제품에 적용하려면 로컬 툴 호출에 대한 명시적인 훅이나 샌드박스 정책이 반드시 선행되어야 합니다.

최적의 대상: 단일 벤더 SDK로 로컬 실행과 관리형 클라우드 실행을 모두 처리하려는 개발팀
차별점: 단일 에이전트 인터페이스로 로컬 프로세스 또는 지속성 Cursor 호스팅 에이전트 제어 가능
가격: SDK 사용량은 Cursor 요금제 및 요청 풀을 따릅니다. Hobby는 제한된 에이전트 요청을 포함해 무료이며, Pro는 월 $20, Teams는 사용자당 월 $40, Enterprise는 맞춤형입니다.
무료 체험: 유료 플랜 없이도 Hobby 티어 이용이 가능합니다.

Cursor가 Codex나 Claude 직접 SDK보다 후순위에 배치된 이유는 벤더 중립성이 아니라 배포 유연성에 강점이 있기 때문입니다. 노트북과 관리형 클라우드 인프라 전반에서 동일한 워크플로를 구현하려는 개발자 플랫폼에는 매력적인 대안입니다. 반면 자체 호스팅, 소스코드 수준의 제어, 런타임 독립적 기술 계약이 필수 요구사항이라면 적합하지 않습니다.

5. OpenHands Software Agent SDK: 최고의 오픈소스 원격 스택

OpenHands Software Agent SDK는 에이전트 API와 배포 가능한 원격 실행 서비스가 모두 필요할 때 가장 뛰어난 오픈소스 선택지입니다. Python 및 REST API를 통해 로컬, Docker, Kubernetes 배포를 지원하며, Agent Server는 WebSocket을 통해 이벤트를 실시간 스트리밍합니다. 규제가 엄격한 엔지니어링 플랫폼이라도 자체 인프라 내에 작업 공간을 유지하면서 사내 클라이언트에 OpenAI 호환 엔드포인트를 제공할 수 있습니다. 단점은 운영 규모입니다. 클라이언트, 에이전트 서버, 작업 공간 격리, 모델 라우팅, 영구 스토리지를 모두 직접 운영해야 합니다.

최적의 대상: 오픈소스 기반의 자체 호스팅 코딩 에이전트 서비스가 필요한 Python 팀
차별점: 로컬, Docker, 원격 작업 공간 전반에 걸쳐 동일한 대화 API 제공
가격: 무료 및 MIT 라이선스; 모델, 컨테이너, 네트워크, 스토리지 비용 별도
무료 체험: 해당 없음; 오픈소스 무료 소프트웨어입니다.

"자체 호스팅"이 단순히 노트북에 패키지 하나를 설치하는 것을 넘어설 때 OpenHands는 최고의 역량을 발휘합니다. 원격 아키텍처는 Python 클라이언트, HTTP/WebSocket 기반 Agent Server, 격리된 작업 공간이라는 3가지 명확한 요소로 나뉩니다. 로컬 실행에서 Docker나 원격 API로 전환하더라도 대화 제어 코드는 유지한 채 작업 공간 객체만 변경하면 됩니다.

이러한 구조는 다양한 클라이언트 환경에 대응하기에 유리합니다. 브라우저, IDE, 음성 시스템, 타사 OpenAI 스타일 클라이언트가 Python 패키지를 임포트하지 않고도 호환 엔드포인트를 바로 호출할 수 있습니다. 운영팀은 서비스 경계면에 인증, 쿼터, 감사 로그, 리전별 라우팅을 손쉽게 배치할 수 있습니다. 사내 플랫폼 구축을 위한 가장 완벽한 오픈소스 기반입니다.

그러나 기능의 완성도는 엔지니어링 리소스 투입을 의미합니다. 컨테이너 이미지 패치, 작업 공간 리소스 제한, 런타임 키 갱신, WebSocket 세션 모니터링, 리포지토리 데이터 보존 주기 결정을 직접 챙겨야 합니다. "MIT 라이선스"는 소프트웨어 비용 문제만 해결할 뿐, 전체 소유 비용(TCO)까지 없애주지는 않습니다.

Vercel과의 선택 기준은 인프라 소유권에 있습니다. Vercel은 TypeScript 제어 계층과 관리형 샌드박스 경로를 지원합니다. 반면 OpenHands는 소스코드 접근권과 완벽한 배포 자유를 주는 대신 더 많은 인프라 운영을 요구합니다. 코드의 물리적 위치에 대한 규제 준수나 모델 이식성이 계약상 필수라면 이 추가 작업은 충분히 가치가 있습니다. 하지만 다음 달에 출시해야 할 작은 상용 기능이 목표라면 과도한 부담이 될 수 있습니다.

6. OpenCode SDK: 최고의 타입 안전 클라이언트/서버 인터페이스

OpenCode SDK는 명시적인 OpenCode 서버를 타입 안전한 클라이언트로 제어하려는 JavaScript 및 TypeScript 환경에 가장 최적화된 독립형 옵션입니다. createOpencode()는 서버와 클라이언트를 동시에 실행하며, createOpencodeClient()는 이미 가동 중인 서버에 연결합니다. 데스크톱 앱이나 사내 개발자 포털에서 자동 생성된 타입을 통해 세션 생성, 이벤트 스트리밍, 권한 응답, 명령 실행, 파일 검사, 정형 출력 요청을 깔끔하게 처리할 수 있습니다. 다만 명확한 클라이언트/서버 계약 구조이므로 서버 라이프사이클, 포트 관리, 멀티테넌시, 인증 처리는 호스트의 책임으로 남습니다.

최적의 대상: 명시적인 에이전트 서버를 타입 안전하게 다루려는 JavaScript 및 TypeScript 제품
차별점: 세션, 파일, 명령, 권한, 이벤트 API 전반에 걸친 OpenAPI 기반 생성 타입 제공
가격: 무료 및 MIT 라이선스; 모델 및 서버 인프라 비용 별도
무료 체험: 해당 없음; 오픈소스 무료 소프트웨어입니다.

로컬 기본 설정은 매우 단순합니다: 127.0.0.1, 포트 4096, 시작 타임아웃 5,000 ms. Electron 앱, 로컬 자동화, 개발자 툴에는 편리하지만 이를 프로덕션 환경에 그대로 가져가서는 안 됩니다. 여러 테넌트가 접근하는 서버라면 전면에 인증 계층을 두고, 작업 단위별 작업 공간 정책을 수립하며, 허용할 셸 및 파일 작업 범위를 엄격히 통제해야 합니다.

OpenCode의 독보적인 강점은 투명한 가시성(inspectability)입니다. 세션 생성, 프롬프트 제출, 작업 중단, 공유, 요약, 셸 실행, 권한 응답, 파일 입출력, 설정, 이벤트 구독이 모두 독립된 메서드로 공개되어 있습니다. 따라서 단순히 "프롬프트 전송 후 응답 수신"만 제공하는 패키지보다 운영자용 관리 콘솔을 제작하기가 훨씬 수월합니다.

OpenHands와의 직접 비교는 사용 언어와 목표 범위에 따라 갈립니다. OpenCode는 서버 주변에 명확한 JS/TS 클라이언트를 제공합니다. OpenHands는 Python 중심의 에이전트 SDK와 더 고도화된 원격 작업 공간 배포 모델을 갖추고 있습니다. 애플리케이션 스택이 이미 TypeScript 기반이고 OpenCode 서버를 런타임으로 삼고자 한다면 OpenCode를 선택하십시오. 개방형 에이전트 플랫폼 자체와 작업 공간 이식성이 더 중요하다면 OpenHands가 적합합니다.

7. Pi: 가장 작고 유연한 에이전트 코어

Pi는 완성된 코딩 플랫폼보다 작고 군더더기 없는 에이전트 루프가 필요할 때 가장 적합합니다. @earendil-works/pi-agent-core는 상태, 툴 실행, 이벤트 스트리밍, 모델 교체, 작업 조정(steering), 후속 큐, 툴 이벤트를 제공하며, 상위 프로젝트에서는 Node.js SDK와 JSONL RPC도 지원합니다. 특정 목적의 코드 마이그레이션 서비스라면 터미널 에이전트 전체를 들여오는 대신 필요한 툴과 이벤트만 선택해 최소한으로 정의할 수 있습니다. 다만 결합의 책임이 따릅니다. 영속성, 코딩 툴, 격리 환경, 애플리케이션 정책의 대부분을 개발자가 직접 구현해야 합니다.

최적의 대상: 에이전트 루프와 툴 정책을 밑바닥부터 직접 설계하려는 팀
차별점: 강제된 서버 아키텍처 없이 이벤트 스트리밍과 툴 훅을 제공하는 상태 저장 코어
가격: 무료 및 MIT 라이선스; 모델, 스토리지, 컴퓨팅 비용 별도
무료 체험: 해당 없음; 오픈소스 무료 소프트웨어입니다.

Pi가 매력적인 이유는 불필요한 결정을 강요하지 않기 때문입니다. 코어 엔진은 모델 메시지 스트리밍, 툴 실행, 턴 중간 지시(steering)를 통한 중단, 후속 작업 큐잉, 모델 호출 전 컨텍스트 변환, 턴 종료 후 정지를 매끄럽게 처리합니다. 로우 레벨 모델 API를 직접 다루지 않고도 독자적인 에이전트 루프를 구축하기에 충분한 기능입니다.

하지만 이 단순함은 곧 개발 부담을 뜻합니다. 영구 세션 스토리지와 샌드박스 가이드는 코어 외부에 존재합니다. 툴 역시 호출자가 직접 정의해야 합니다. 런타임을 가볍고 이식성 높게 유지할 수 있는 대신, 생략된 기본값 하나하나가 개발팀의 설계 과제로 남습니다.

따라서 Pi는 작업 범위가 좁은 에이전트에 강력합니다. 예컨대 리포지토리 매니페스트를 읽고, 종속성 버전을 업데이트한 뒤, 테스트 명령 하나를 실행하고, 서명된 보고서를 반환하는 서비스가 있다고 가정해 보겠습니다. 정밀하게 제약된 4개의 툴과 1개의 영속성 어댑터만 조합하는 것이 무거운 범용 런타임보다 훨씬 안전할 수 있습니다. 반면 세션, 권한, 스킬, 터미널, 원격 작업 공간, 완성도 높은 운영 UI가 즉시 필요한 IDE 성격의 제품에는 적합하지 않습니다.

Pi는 Vercel 어댑터를 통해서도 구동할 수 있습니다. 당장은 Pi 루프를 쓰되 향후 다른 런타임과 비교 평가하고 싶다면 Vercel을 대면 계약으로 두는 것이 좋습니다. 불필요한 추상화 없이 Pi 자체만을 가볍게 쓰고 싶다면 코어를 직접 임포트하는 것이 최선입니다.

8. fx and libfx: 실험적인 네이티브 및 브라우저 임베딩에 최적화

fx and libfx는 네이티브 바이너리, ACP 연동, Node 임베딩, 모던 브라우저 내 코딩 루프, 혹은 Vercel HarnessAgent 기반 fx 구동을 탐색하는 프로젝트에 가장 흥미로운 실험적 선택지입니다. 공식 사이트 기준 v0.0.7은 6.19 MiB 크기의 모델 중립적 Apache-2.0 코딩 에이전트이며, libfx는 네이티브 Node 애드온이나 WebAssembly를 통해 헤드리스 에이전트 및 인터랙티브 터미널 인터페이스를 제공합니다. 단일 네이티브 코어를 사용하면서 브라우저 데모까지 동시에 선보이고자 하는 로컬 중심(local-first) 개발자 툴에 알맞습니다. 그러나 실험적 상태라는 점, 브라우저 환경에서 JSPI가 필수라는 점, WASM 빌드에서는 주요 네이티브 기능이 대거 제외된다는 점, v0.0.5 이후 호스트 명령어 샌드박스 제어가 제거되었다는 점을 반드시 인지해야 합니다.

최적의 대상: 초경량 네이티브, ACP, Node, 브라우저 기반 에이전트 제품을 연구하는 조직
차별점: 단일 Zig 코어를 네이티브 바이너리, Node 애드온, fx-core.wasm, fx-term.wasm으로 제공
가격: 무료 및 Apache-2.0; 모델 인증 정보 또는 로컬 연산 비용 별도
무료 체험: 해당 없음; 오픈소스 무료 소프트웨어입니다.

현재 0.0.7 릴리스는 활성 턴 중간 지시(active-turn steering), 프로젝트 단위 MCP 설정, MCP 기능 탐색, 더 엄격해진 MCP 신뢰 제어를 추가했습니다. 핵심적인 호스트 경계는 유지됩니다. v0.0.5 이후 승인된 캡처, 백그라운드, 모니터 명령어는 일반 호스트 서브프로세스로 실행되며, 과거의 샌드박스 설정, 상태 필드, 명령어는 모두 제거되었습니다.

이는 가벼운 변경 사항이 아닙니다. 데스크톱 앱 환경에서 승인된 명령어는 임베딩 애플리케이션이 독자적인 격리 환경을 제공하지 않는 한 호스트 운영체제로 직접 전달됩니다. 따라서 명령어 인입 승인, 프로세스 제한, 작업 공간 경계, 감사 로그, 외부 샌드박스 도입을 위한 추가 개발 비용이 발생합니다. "권한 콜백"이 곧 "샌드박스 격리"를 의미하는 것은 아닙니다.

브라우저 환경 역시 뚜렷한 한계를 가집니다. libfx의 브라우저 WebAssembly 구동에는 Chrome 또는 Edge 137 이상과 JSPI 지원이 요구됩니다. 또한 WASM 런타임은 네이티브 프로세스, OS 샌드박스, 네이티브 MCP 서버, 서브에이전트나 스킬, 자동 업그레이드, 임의 WASI 파일시스템 접근, 공개 웹 또는 일반 아웃바운드 네트워크 접근을 의도적으로 배제합니다. 호스트가 제한된 포그라운드 명령어 계약을 노출할 수는 있지만, 명령어 승인, 한도 강제, 반환 출력 제한은 전적으로 호스트가 처리해야 합니다.

단순 데모 환경이라도 자격 증명 관리에 각별한 주의가 필요합니다. 공식 문서에서는 공개 브라우저 코드에 장기 API 키를 하드코딩하지 말 것을 명시하고 있습니다. 유효 기간이 짧은 임시 자격 증명이나 인증된 서버 측 프록시를 사용해야 합니다. 프록시, 작업 공간 어댑터, 명령어 정책이 사전에 준비되지 않았다면 브라우저 바이너리 파일만으로 온전한 제품을 완성할 수는 없습니다.

현시점에서 가장 유효한 활용처는 민감하지 않은 리포지토리와 좁은 툴 정책을 적용한 사내 프로토타입입니다. 가장 피해야 할 구성은 공개 브라우저 앱에 장기 모델 키를 탑재하고, 광범위한 명령어 브리지를 활성화한 뒤, WASM 모듈이 보안 격리를 대신해 줄 것이라 믿는 설계입니다. 아키텍처적 유연성은 높이 평가하지만, 성숙도 문제로 인해 본 순위의 마지막에 배치했습니다.

상황별 추천: 우리 팀에는 어떤 하네스가 맞을까?

향후 런타임 변경 리스크에 유연하게 대처해야 한다면 Vercel AI SDK HarnessAgent를 선택하십시오. 교체 비용이 완전히 0이 되는 것은 아니지만, 단일 제품 인터페이스를 유지함으로써 UI, 스키마, 세션 기록, 평가 데이터를 어댑터 상위 계층에서 온전히 보존할 수 있습니다. 단, 실험적 패키지 도입이 사내 규정상 불가능하거나 어댑터가 가려버리는 특정 벤더 고유 기능이 반드시 필요한 경우에는 다른 대안을 검토해야 합니다.

Claude Code 루프 자체가 제품의 핵심 차별화 요소이고, 활성 세션당 1개의 서브프로세스를 감당할 인프라 운영 역량이 있다면 Claude Agent SDK를 선택하십시오. 모든 기능이 갖춰진 가장 완성도 높은 선택지입니다. 정형화된 Codex 스레드와 기존 OpenAI 인증이 우선이라면 Codex로, 공급업체 종속 탈피가 필수라면 Vercel로 전환하십시오.

OpenAI 네이티브 시스템에서 지속성 스레드, 머신 스트리밍 이벤트, 스키마 기반 출력이 필요하다면 OpenAI Codex SDK를 선택하십시오. CLI 서브프로세스 제어가 부담스럽거나 벤더 중립적 계약이 더 중요하다면 다른 옵션으로 넘어가십시오.

개발자 로컬 머신과 Cursor 관리형 클라우드 에이전트 양쪽에서 동일한 제품 워크플로를 구동해야 한다면 Cursor SDK를 선택하십시오. 자체 호스팅이나 런타임 중립성이 필수 요건이라면 적합하지 않습니다.

자체 인프라 거버넌스하에 여러 클라이언트가 공유할 오픈소스 코딩 에이전트 서비스가 필요하다면 OpenHands를 선택하십시오. 클라이언트-서버-작업 공간이 분리된 구조는 플랫폼 엔지니어링 팀에 큰 강점입니다. TypeScript 중심 서버 환경을 원한다면 OpenCode로, 원격 플랫폼 구성이 과도하다고 판단되면 Pi로 선회하십시오.

명시적인 OpenCode 서버를 타입 안전한 클라이언트로 다루는 아키텍처를 원한다면 OpenCode SDK를 선택하십시오. 로컬 데스크톱 앱과 사내 개발자 포털에 매우 잘 들어맞습니다. 애플리케이션이 서버 라이프사이클과 네트워크 보안 정책을 직접 운영할 수 없는 환경이라면 피하는 것이 좋습니다.

가볍고 조합하기 쉬운 에이전트 루프를 원하고, 툴과 상태 및 정책을 직접 정의할 준비가 되어 있다면 Pi를 선택하십시오. 이러한 부가 요소를 직접 개발하는 것이 제품 차별화에 도움이 되지 않는다면 완성형 런타임을 선택하는 편이 낫습니다.

네이티브 바이너리 크기, ACP, 브라우저 WebAssembly 자체를 검증하는 연구 목적에 한해서만 fx를 검토하십시오. 초경량 바이너리의 매력 이면에 호스트 측에서 감당해야 할 명령어 격리 및 보안 과제가 산적해 있습니다.

제품 내 임베딩이 아니라 전사 차원의 도구 도입이 목적이라면 엔터프라이즈 코딩 에이전트 가이드를 참고하십시오. 조달, 인증, 감사 로그, 개발자 온보딩이 SDK 인터페이스보다 훨씬 중요한 변수가 됩니다.

피해야 할 선택지

여기서 특정 툴을 제외하라고 권고하는 것은 해당 도구의 코딩 실력이 부족해서가 아닙니다. 임베딩 기술 계약으로서 적합하지 않기 때문입니다.

Aider를 제품 종속성으로 사용하는 설계. Aider는 터미널 기반 페어 프로그래밍에 대단히 강력하며 클라우드나 로컬 모델 연동도 훌륭합니다. CLI를 스크립트로 자동화할 수는 있지만, 서브프로세스 임시 자동화는 세션, 권한, 라이프사이클, 출력 형식이 보장된 안정적인 임베딩 계약과 동일하지 않습니다. Aider는 개발자 터미널에서 직접 사용하십시오. 제품 내부 연동에는 공식 SDK나 서버 API를 써야 합니다.

신규 통합 프로젝트에서의 SWE-agent 도입. SWE-agent 리포지토리에는 현재 mini-SWE-agent가 프로젝트를 대체했음을 명시하며 신규 프로젝트 도입을 권장하고 있습니다. SWE-agent는 학술 연구나 기존 벤치마크 재현에는 유용하지만, 이미 대체된 프로젝트를 기반으로 지속 가능한 제품 통합을 시작하는 것은 불필요한 마이그레이션 부채를 떠안는 일입니다.

또한 단순히 모델 이름만을 강점으로 내세우는 래퍼 라이브러리는 피하십시오. 기반 모델의 교체 주기는 세션 스키마, 보안 정책 경계, 평가 데이터셋, 고객 워크플로보다 훨씬 빠릅니다. 우수한 제어 계층은 이러한 지속성 자산을 안전하게 보호할 수 있어야 합니다.

월요일에 바로 실행할 액션 플랜

월요일 아침부터 8개의 SDK를 전부 연동하려고 들지 마십시오. 특정 런타임에 종속되지 않는 단일 인수 계약(acceptance contract)을 정의하고, 이를 두 가지 런타임에서 재생 테스트하는 것부터 시작하십시오.

실제 유료 고객의 워크로드를 대변하는 3가지 리포지토리 과제를 선정하십시오:

• 명확한 수정 범위를 가진 실패 단위 테스트
• 마이그레이션 노트 작성을 수반하는 종속성 버전 업그레이드
• 정확한 코드 라인을 인용하되 패치는 생성하지 않는 읽기 전용 검토

각 작업마다 리포지토리 접근 범위, 허용 명령어, 최대 소요 시간, 최대 토큰 예산, 필수 출력 스키마, 에스컬레이션 기준을 정의하십시오. 작업 완료 여부, 테스트 통과 결과, 수정된 파일, 거부된 툴 호출, 토큰 사용량, 재시도 횟수, 담당자 승인까지 걸린 시간을 기록하십시오. 가장 유력한 1순위 후보에서 먼저 실행한 뒤, 가장 강력한 대체 옵션에서 동일하게 실행해 보십시오.

이 과정의 결과물은 단순한 벤치마크 점수표가 아니라 명확한 의사결정 보고서가 되어야 합니다. Vercel이 제품 계약을 온전히 보호하고 하위 런타임 간 성능 차이가 크지 않다면 이식성을 택하는 것이 맞습니다. Claude가 더 적은 재시도로 복잡한 작업을 완수해 낸다면 벤더 종속의 비용을 충분히 상쇄할 수 있습니다. OpenHands가 외부 관리형 서비스 없이 사내 보안 격리 요건을 완벽히 충족한다면 인프라 부담을 감수할 명분이 섭니다. fx를 도입할 때 첫 고객을 받기 전 커스텀 명령어 샌드박스를 구축해야 한다면, 그 개발 공수를 지금 당장 출시 예산에 반영해야 합니다.

자주 묻는 질문 (FAQ)

로컬 LLM 구동에 가장 적합한 코딩 에이전트 하네스는 무엇인가요?

로컬 모델을 원격 서버 및 격리된 작업 공간 구조로 운영해야 한다면 OpenHands가 가장 완성도 높은 오픈소스 스택입니다. 가벼운 루프를 직접 통제하면서 툴, 영속성, 샌드박스를 독자적으로 구성하고 싶다면 Pi가 적합합니다. fx 역시 모델 중립적이지만, 실험적 상태이므로 기본 선택지보다는 연구 목적으로 접근해야 합니다.

벤치마크 결과가 가장 우수한 코딩 에이전트 하네스는 무엇인가요?

공개 벤치마크 순위만으로 실제 임베딩 적합성을 판단할 수는 없습니다. 벤치마크는 자체 프롬프트, 툴셋, 리포지토리 환경, 리소스 제한하에서 측정한 결과일 뿐입니다. 제품 개발팀은 자사의 보안 및 권한 규칙하에서 실제 대표 리포지토리 작업을 직접 재생해 본 뒤, 완료율, 재시도 횟수, 토큰 비용, 사람의 검토 시간을 종합 비교해야 합니다.

OpenCode도 임베딩 가능한 코딩 에이전트 하네스로 볼 수 있나요?

그렇습니다. OpenCode의 공식 SDK는 서버와 클라이언트를 함께 실행하거나, 타입 안전 클라이언트를 기존 서버에 연결하는 방식을 지원합니다. 따라서 임베딩 경계면은 인프로세스 루프가 아니라 클라이언트/서버 계약 형태로 구성됩니다.

가장 추천할 만한 무료 임베딩 코딩 에이전트 하네스는 무엇인가요?

전체 기능을 갖춘 오픈소스 스택으로는 MIT 라이선스의 OpenHands가, 경량 코어로는 MIT 라이선스의 Pi가 가장 우수합니다. OpenCode와 fx 역시 오픈소스입니다. 다만 "무료"는 소프트웨어 라이선스에 국한되며, 모델 API 토큰, 연산 인프라, 스토리지, 네트워크 비용 및 이를 운영하는 엔지니어 인건비는 별도로 발생합니다.

관련 추천 자료 및 키워드

핵심 키워드 정리

• 주요 키워드: 임베딩 코딩 에이전트 하네스 (embeddable coding agent harness)
• 보조 키워드: 코딩 에이전트 런타임 (coding agent runtime), 코딩 에이전트 SDK (coding agent SDK), Vercel AI SDK HarnessAgent, Claude Agent SDK, OpenHands SDK, 에이전트 격리 환경 및 샌드박스 비용

AI 비즈니스 워크플로 감사 체크리스트

어떤 업무가 에이전트 도입에 적합하고 어떤 영역에 사람의 승인 단계가 필요한지 무료 체크리스트로 진단해 보십시오.

---BODY---