Pi vs Claude Code: 하네스를 빌릴 것인가 소유할 것인가

나는 1년 넘게 거의 매일 Claude Code로 코드를 짠다. 최근 미니멀한 터미널 코딩 하네스 Pi를 써볼 기회가 있었고, 자연스럽게 항목별로 비교하게 됐다. Pi의 어떤 지점이 왜 매력적이었는지, 그 매력을 Claude Code에서도 흉내 낼 수 있는지, 아니면 구조적으로 아예 안 되는지를 정리해본다. 결론부터 적자면 지금도 나는 Claude Code Max 20을 결제해서 쓴다. 이유는 마지막에 있다.

하네스가 뭐길래

코딩 에이전트를 컴퓨터에 비유하면 이해가 쉽다. 모델—Claude나 GPT, Gemini 같은—은 CPU에 해당한다. 컨텍스트 윈도우는 RAM이고, 하네스는 운영체제(OS)에 해당한다.

이 비유가 의미를 갖는 건 하네스가 실제로 하는 일 때문이다. 모델이 어떤 도구를 호출할 수 있는지 정하는 주체가 하네스다. 컨텍스트가 한계에 가까워지면 오래된 내용을 정리하는 판단도 하네스가 내린다. Claude Code와 Cursor, Open Code는 전부 하네스이고 각자 같은 모델을 서로 다른 방식으로 실행한다.

왜 같은 모델을 쓰는데 결과물이 이렇게 달라질까. 하네스가 바뀌면 모델은 완전히 다른 에이전트처럼 움직이기 때문이다. Opus를 평범한 하네스에 넣으면 평범한 결과가 나온다. 반대로 Kimi K2처럼 작고 저렴한 모델도 제대로 짜인 하네스 안에서는 훨씬 비싼 모델을 능가할 수 있다. 모델 선택보다 하네스 선택이 결과를 더 크게 좌우한다는 뜻이다.

오해하기 쉬운 지점이 하나 있다. 하네스를 바꾼다고 모델 자체의 성능이 좋아지는 건 아니다. 모델은 그대로다. 달라지는 건 모델이 쓸 수 있는 도구의 폭, 컨텍스트를 정리하는 타이밍, 뭔가 실패했을 때 되돌리는 방식이다. 이 세 가지가 누적되면서 체감 성능 차이로 드러난다. Pi와 Claude Code를 나란히 놓고 비교하는 것도 결국 이 세 가지를 항목별로 뜯어보는 일이다.

Pi에 끌린 지점

Pi 팀이 신경 쓰는 지점은 딱 세 가지다. 미니멀리즘, 커스터마이징, 확장성이다. 화면을 켜면 미리 갖춰진 기능이 잔뜩 나오는 게 아니라 거의 빈 캔버스에 가깝다. 이 차이는 다음과 같이 표현할 수 있다.

Claude Code가 배워야 할 기능—어쩌면 실제로는 쓰지도 않을 기능—으로 가득 찬 우주선이라면, Pi는 레고 블록 더미다. 몇 개의 조각만 주어지고 나머지는 직접 조립한다. 아니면 Pi에게 만들어달라고 부탁한다.

이 비유의 핵심은 우주선이 나쁘다는 게 아니다. 우주선은 조종법을 익혀야 쓸 수 있다는 점이다. 레고는 다르다. 손에 쥔 블록만큼만 할 수 있지만 원하는 모양은 사용자가 직접 정한다.

Pi는 오픈소스이고 시스템 프롬프트가 매우 작다. 도구는 전부 코드로 드러나 있어서 뭘 하는지 숨겨지지 않는다. 원하는 기능이 없으면 NPM으로 Pi 패키지를 설치하거나, Pi에게 직접 만들어달라고 요청한 뒤 핫리로드로 바로 확인한다.

모델 자유도도 끌린 지점 중 하나다. Pi는 수백 개 모델을 지원하고, 대화 도중에 모델을 바꿔도 맥락이 끊기지 않는다. 예를 들어 저렴하고 빠른 Kimi K2로 반복 작업을 처리하다가 어려운 문제를 만나면 Opus로 전환하고, 풀리면 다시 돌아올 수 있다. 값싼 모델로 반복 작업을 처리하고 비싼 모델은 정말 필요한 순간에만 꺼내 쓰는 구조다. 매번 API 호출량만큼 종량제로 비용이 붙기 때문에, 어떤 모델을 얼마나 썼는지가 그대로 청구서에 찍힌다.

확장 시스템도 인상 깊었다. 확장은 Pi의 동작을 바꾸는 작은 TypeScript 파일이다. 새 도구를 추가하거나 기존 도구를 수정할 수 있고, 에이전트 루프 자체에 훅을 걸 수도 있고, 자체 UI를 붙일 수도 있다.

예를 들어 신스웨이브 톤의 테마를 요청하면 Pi가 테마 파일을 직접 작성하고, /reload 명령 한 번으로 터미널 색상이 바로 바뀐다. 재시작도 재배포도 없다.

다른 예로 안전장치도 그 자리에서 짤 수 있다. bash 명령을 실행하기 직전에 가로채서 rm -rf 같은 위험한 패턴이 있으면 확인을 요구하는 가드레일이다. 코드량은 10줄 안팎이다. 대략 이런 형태다.

onBeforeToolCall(tool) {
  if (tool.name === "bash" && /rm\s+-rf/.test(tool.command)) {
    return askUser(`위험한 명령 감지: ${tool.command} 계속 진행할까요?`)
  }
  return allow()
}

대화 한 번과 리로드 한 번이면 요청부터 적용까지 끝난다. 별도 빌드 파이프라인이나 배포 절차를 거치지 않는다는 점이 인상 깊었다.

항목별로 뜯어보기: 흉내 낼 수 있는 것과 안 되는 것

Pi에서 매력을 느낀 지점을 Claude Code로 하나씩 가져와 봤다. 어디까지 근접하게 재현되고 어디서 구조적으로 막히는지, 항목별로 정리한다.

모델 스위칭: 종량제 자유 vs 구독 번들

Claude Code Max 20 안에서도 세션 도중 /model 명령으로 Opus·Sonnet·Haiku를 오갈 수 있다. 이 부분은 근접하게 재현된다. 다만 오갈 수 있는 범위가 Anthropic 라인업 안으로 한정된다. Pi에서처럼 Kimi K2 같은 타사 저가 모델을 섞어 쓰려면 별도 API 키와 별도 빌링을 붙여야 하는데, 그 순간 Max 20 구독료와는 별개의 종량제 비용이 새로 생긴다. 구독 하나에 다 들어있는 대신 그 구독 밖으로 못 나간다는 뜻이다.

세션 트리와 브랜치: 정직하게 안 되는 지점

Pi에서 세션은 하나의 선이 아니라 트리 구조로 저장된다. 이전 메시지 지점으로 돌아가 새 브랜치를 만들고, 실험이 마음에 안 들면 그 브랜치만 접어두면 그만이다.

Claude Code에는 이런 구조가 없다. 훅이나 서브에이전트로 비슷한 걸 흉내 내볼 수도 있겠지만, 세션 자체를 트리로 저장하고 브랜치별 토큰·비용을 노드 단위로 보여주는 건 하네스 코어 설계의 영역이라 사용자 쪽 확장으로는 손이 안 닿는다. 이 지점은 그냥 아쉬운 채로 남겨둔다.

압축 제어권: 일부만 손에 쥔다

대화가 길어지면 어느 하네스든 오래된 부분을 요약해서 컨텍스트를 비운다. 이 과정을 압축(compaction)이라고 부른다. Pi는 언제 압축을 시작할지, 몇 개 메시지를 남길지, 어떤 모델이 요약을 맡을지까지 전부 사용자가 정한다. Claude Code는 이 정도로 세세하게는 못 정한다. 대신 PreCompact 훅이 있어서, 압축이 실행되기 직전에 스크립트를 걸어 지키고 싶은 맥락을 메모로 남기거나 압축 시점을 로그로 남기는 식의 절반짜리 통제는 가능하다. 압축의 타이밍과 요약 모델까지 고르는 Pi의 완전한 통제권에는 못 미치지만, 아예 손을 못 대는 것보다는 낫다.

확장 시스템: hooks·MCP·서브에이전트·스킬로 어디까지

Pi의 확장이 주는 즉흥성 중 상당 부분은 Claude Code 생태계로 옮겨온다. bash 가드레일은 PreToolUse 훅으로 거의 그대로 재현된다. 위 코드 예시의 rm -rf 확인 로직은 Claude Code의 훅 설정에 옮겨 적어도 똑같이 동작한다. 외부 서비스 연결은 MCP 서버로, 반복되는 워크플로우는 서브에이전트나 스킬로 패키징해 재사용할 수 있다. 다만 터미널 테마를 그 자리에서 새로 짜고 /reload 한 번으로 색상을 바꾸는 흐름은 Claude Code 쪽에서 그대로 재현하기 어렵다. CLI 자체가 오픈소스가 아니라서 확장 지점이 공식 훅 이벤트로 미리 정해져 있고, 그 밖의 영역은 사용자가 손댈 여지가 없다.

미니멀 자유와 통합 생태계 사이

두 하네스를 나란히 놓고 보니 트레이드오프의 축이 뚜렷해졌다. Pi는 거의 빈 캔버스에서 시작해서 필요한 만큼만 직접 짜 붙인다. 그래서 자유롭지만, 가드레일이든 서브에이전트든 필요한 걸 전부 직접 만들어야 한다. Claude Code는 hooks·MCP·서브에이전트·스킬이 이미 하나의 생태계로 갖춰져 있다. 그래서 빠르게 조합해 쓸 수 있지만, 그 조합 방식 자체는 공식 훅 이벤트가 정해둔 틀 안에서만 가능하다. 미니멀리즘이 주는 자유와 이미 갖춰진 생태계가 주는 깊이는 서로 다른 종류의 편리함이다.

경제성도 같은 축을 따라 갈린다. Pi는 종량제·자체 API 키 방식이라 쓴 만큼만 청구서에 찍힌다. Claude Code Max 20은 매달 고정 요금 안에 Opus·Sonnet·Haiku 사용량이 번들로 들어있다. 작업량이 들쭉날쭉하면 종량제가 유리할 때도 있고, 매일 코드를 짜는 사람에게는 고정 요금이 예측 가능해서 편할 때도 있다.

그래서 지금 뭘 쓰나

지금 나는 Claude Code Max 20을 결제해서 계속 쓰고 있다. Pi에는 구독 요금제가 없다. 종량제로 API 키를 직접 붙여 쓰는 방식이라, 매달 같은 금액을 내고 예측 가능하게 쓰고 싶은 내 사용 패턴에는 잘 안 맞는다. 매일 코드를 짜는 입장에서는 사용량이 들쭉날쭉한 종량제보다 고정 요금이 관리하기 편했다.

대신 Pi에서 얻은 건 아이디어 쪽이다. 압축을 훅으로 일부 통제하는 습관, bash 가드레일을 직접 짜서 붙이는 감각, 필요한 기능만 최소로 조립하는 사고방식은 Claude Code를 커스터마이징할 때 계속 참고하고 있다. 세션 트리나 완전한 압축 제어권처럼 구조적으로 못 가져오는 부분은 그냥 아쉬운 채로 남는다. 반면 hooks·MCP·서브에이전트·스킬로 재현되는 부분은 이미 내 Claude Code 설정에 들어와 있다.

결국 주력 도구를 바꾼 게 아니라, 주력 도구를 더 잘 쓰는 법을 하나 배운 셈이다. 하네스라는 개념 자체가 도구를 고르는 기준을 하나 더 늘려준다. 다른 LLM 활용 사례가 궁금하다면 LLM 활용 카테고리에도 관련 글이 정리돼 있다.