Lite-Harness SDK

AI harness(AI 하네스)는 새로운 벤더 종속(vendor lock-in)의 원인이 되고 있습니다. 앱을 다시 작성하지 않고도 harness 간에 쉽게 전환하기 위해, LiteLLM이 Lite-Harness SDK를 출시했습니다.

다양한 harness에서 프롬프트를 실행하세요:

from lite_harness import query, AgentOptions

prompt = "Fix the failing test"
...

비용 제어, 폴백(fallbacks), 로깅(logging)을 활성화하려면 LiteLLM AI Gateway를 가리키도록 설정하세요:

export LITELLM_API_BASE=https://litellm.your-company.com/v1
export LITELLM_API_KEY=sk-litellm-...

엔지니어의 핵심 요약 (Engineer's Takeaway):
이 SDK는 에이전트가 내부적으로 실행되는 방식이 아니라, 에이전트를 _호출(invoke)_하는 방식을 통합합니다. 각 harness는 고유의 네이티브 루프(native loop)와 도구 호출(tool-calling) 의미론을 유지합니다. 에이전트 성능의 A/B 테스트와 비용 중앙 집중화에 완벽하지만, 현재 퍼블릭 베타(public beta) 상태이므로 커스텀 도구 주입(custom tool injection)에는 추가 작업이 필요할 수 있음을 기억하세요!

내가 겪었던 문제

우리 팀은 실패하는 CI/CD 테스트를 수정하기 위한 내부 봇을 구축하고 있었습니다. 세 명의 엔지니어가 각각 세 가지 다른 harness를 주장했습니다. 한 명은 Claude Code를, 다른 한 명은 Codex를, 또 다른 한 명은 Pi AI를 원했습니다. 추상화 계층(abstraction layer)이 없었다면, 우리는 세 개의 서로 다른 SDK, 세 개의 로깅 시스템, 세 개의 비용 추적 방식을 가진 **동일한 봇의 세 가지 포크(forks)**를 유지 관리해야 했을 것입니다. 이는 불가능한 유지 관리 부담이 되었을 것입니다.

Lite-Harness가 도움을 준 방법

이 SDK는 정확히 그 고충을 세 가지 구체적인 측면에서 해결했습니다:

1. 통합된 호출 (시간 절약)

세 개의 별도 구현체를 유지 관리하는 대신, 제가 원하는 어떤 harness로든 라우팅할 수 있는 **단일 query()**를 갖게 되었습니다. Claude Code에서 Codex로 전환하는 것은 말 그대로 옵션에서 문자열 하나를 바꾸는 것뿐이었습니다. 이를 통해 핵심 로직을 전혀 다시 작성하지 않고도 2주 동안 운영 환경에서 실제 A/B 테스트를 수행할 수 있었습니다.

2. 비용 관측성 (핵심 기능)

LiteLLM AI Gateway에 연결함으로써, 갑자기 단일 대시보드에서 다음을 확인할 수 있게 되었습니다:

• Claude Code는 테스트의 78%를 해결했으며, 평균 4회의 반복(iteration)과 수정당 $0.12의 비용이 발생했습니다.
• Codex는 65%의 테스트를 해결했으며, 6회의 반복과 수정당 $0.08의 비용이 발생했습니다.
• Pi AI는 더 저렴했지만, 복잡한 모크(mock)가 포함된 테스트에서는 실패했습니다.

게이트웨이(gateway)가 없다면, (여러 번의 순차적인 도구 호출을 수행하는) 에이전트의 실제 비용을 추적하는 것은 흩어진 로그들로 인해 악몽과 같은 일이 될 것입니다.

3. 미래의 이식성 (Future Portability)

Anthropic이 Claude Opus 4.8에서 새로운 기능을 출시했을 때, 저는 단순히 모델 문자열(model string)만 업데이트했습니다. 봇의 기저 코드(underlying code)를 건드릴 필요가 없었습니다. 이것이 LiteLLM이 제공하는 진정한 약속인 **애플리케이션과 제공자(provider) 간의 디커플링 (decoupling)**입니다.

깨달은 점 (Lessons Learned)

• 동작을 통일하는 것이 아니라, 호출(invocation)만을 통일합니다. 각 하네스(harness)는 프롬프트와 환경을 다르게 해석합니다. 우리는 매우 명시적인 지침(예: "편집하기 전에 grep을 사용하세요", "테스트 파일을 수정하지 마세요")을 통해 프롬프트를 정규화(normalize)해야 했습니다.
• 네이티브 반복 제어 (native iteration control) 기능이 부족합니다. 내장된 max_iterations가 없으면, 에이전트가 무한 루프에 빠질 경우 토큰 비용으로 5달러를 순식간에 써버릴 수 있습니다. 저는 예산을 보호하기 위해 query() 호출을 엄격한 타임아웃이 설정된 asyncio.wait_for로 감싸야 했습니다.
• 커스텀 도구 주입 (Custom tool injection)이 제한적입니다. 에이전트가 내부 API(Jira, Slack, 내부 DB 등)를 호출해야 하는 경우, 추상화 계층이 너무 제한적으로 변합니다. 이러한 복잡한 유스케이스(use case)의 경우, 결국 하네스의 네이티브 SDK를 직접 사용하게 됩니다.

최종 결론

Lite-Harness는 아마도 저의 통합 작업 시간을 3주 정도 단축해 주었을 것이며, 정보에 기반한 아키텍처 결정을 내릴 수 있도록 확실한 데이터를 제공해 주었습니다. 우리는 결국 Claude Code를 기본 하네스로 선택하고, 더 단순하고 비용에 민감한 작업을 위한 폴백(fallback)으로 Codex를 선택했습니다.