Pi Agent의 비결: 모델별 하네스(Harness)
Pi Agent's Secret Sauce: Model-Specific Harnesses
핵심 요약
다양한 LLM을 Pi Agent에서 사용할 때 모델별로 최적화된 시스템 프롬프트를 자동으로 적용해 주는 확장 기능을 소개합니다.
- 모델별 하네스 — 모델마다 최적화된 시스템 프롬프트를 자동으로 전환함
- Pi Agent 확장 — 단일 에이전트 인터페이스에서 여러 모델을 유연하게 활용함
- 간편한 설치 — 명령어 한 줄로 즉시 사용 가능하며 커스텀 프롬프트도 지원함
- 오픈 소스 프로젝트 — 개발자가 직접 경험을 바탕으로 만든 유용한 도구임
왜 Pi Agent인가?
Claude Code 덕후에서 모델 중립적 워크플로우로
처음 AI 에이전트한테 코딩 업무를 통째로 맡기기 시작했을 때, 난 완전 Claude Code 광팬이었음.
개발자라면 당연히 성능 좋은 툴에 끌리기 마련이잖아. 작업 속도도 높여주고, 코드 퀄리티도 챙겨주고, 귀찮은 잡무까지 알아서 해주는 그런 툴을 원하니까.
그 당시 Claude Code는 경쟁자들보다 한 발 앞서 나가는 느낌이었어. Opus 4.6이 나오면서 Anthropic이 진짜 물건 하나 제대로 만들었다는 게 확실해졌지. 성능이 워낙 압도적이라 개발자 커뮤니티에서 난리가 났고, 심지어 개발 쪽이랑 상관없는 사람들까지 이름을 알 정도였으니까.
근데 현실적인 문제들이 좀 있더라고.
-
비용. 코딩 에이전트를 빡세게 돌리면 돈이 꽤 깨짐. 특히 내 돈 내고 쓰는 입장에서는 더더욱.
-
사용 제한. 대규모 프로젝트를 하거나 하루 종일 에이전트를 돌리다 보면 사용량 제한 때문에 답답할 때가 많음.
-
접근성 및 가용성. 사는 곳에 따라 쓸 수 있는 서비스가 다르고, 서비스가 얼마나 안정적인지도 천차만별임.
-
벤더 종속. 한 업체의 툴, 프롬프트, 관습에 워크플로우가 묶여버리면, 나중에 다른 모델로 갈아타는 게 단순히 API 엔드포인트 바꾸는 수준이 아니게 됨.
이런 단점들이 있는데도 많은 개발자가 익숙한 툴을 계속 쓰려고 우회 방법을 찾곤 해. 근데 비공식적인 중간 경로를 거치면 지금 내가 어떤 모델을 쓰고 있는 건지, 아니면 모델이 일관되게 작동하는 건지 알기 어렵다는 게 문제지.
그래서 난 다른 방법을 찾아보기 시작했어.
더 강력해진 모델들의 등장
다행히 요즘은 대체재들이 훨씬 쓸만해졌어.
DeepSeek, Kimi, GLM, MiniMax 같은 곳에서 내놓은 모델들이 엄청나게 발전했거든. 작업 내용에 따라서는 실무 개발에 써먹기에 충분히 훌륭함.
근데 여러 모델을 써보면서 깨달은 게 하나 있어. 모델이 문제를 풀 능력이 있다고 해서, 항상 내가 원하는 방식으로 접근하는 건 아니라는 거야.
이런 상황 겪어본 적 있지?
-
에이전트한테 검토용 계획서를 짜달라고 했더니, 내가 승인도 안 했는데 바로 구현부터 시작함.
-
버그 좀 봐달라고 했더니, 공식 문서부터 확인하는 게 아니라 의존성 소스 코드부터 역공학으로 파고들어서 1분이면 끝날 걸 한 시간 동안 붙잡고 있음.
-
따라야 할 단계를 명확하게 알려줬는데도 몇 개를 그냥 건너뛰거나, 하지도 않은 단계를 다 끝냈다고 구라침.
이게 모델이 코딩을 못 한다는 뜻은 아님. 가끔은 모델한테 지시하는 방식이나 실행 워크플로우 설계가 문제인 경우가 많거든.
거기서 필요한 게 바로 **하니스 엔지니어링(harness engineering)**이야.
중요한 건 모델만이 아님
프롬프트 엔지니어링은 이미 나온 지 꽤 됐지. 스킬, 시스템 프롬프트, 도구 정의, 실행 루프, 그리고 코딩 에이전트 내부에 점점 정교하게 들어가는 하니스(harness)까지, 이 모든 게 결국 모델을 실제 업무에서 제대로 써먹기 위한 노력의 일환이야.
젠슨 황도 모델 자체보다는 모델을 둘러싼 소프트웨어와 인프라를 결합하는 게 중요하다고 강조했잖아. 뛰어난 모델 하나만 있다고 끝이 아님. 그 모델을 뒷받침하는 시스템이 얼마나 잘 갖춰져 있느냐가 핵심이지.
코딩 에이전트 제공업체들도 이걸 이미 알고 있어. 그래서 자기네 모델에 최적화된 시스템 프롬프트, 도구, 실행 전략 같은 전용 툴들을 묶어서 제공하는 거고.
