1년 넘게 쓴 Claude Code를 떠나 Pi로 옮긴 이유: 한 개발자가 꼽은 코딩 하네스의 조건

들어가며

AI 코딩 도구를 쓰는 개발자라면 한 번쯤 "지금 쓰는 도구가 나한테 정말 맞나?" 고민해 보셨을 텐데요. 이번 글은 Claude Pro 구독에 Claude Code가 포함된 뒤로 1년 넘게 써 온 한 개발자가 주력 코딩 하네스를 오픈소스 도구 Pi로 바꾼 이야기입니다. 큰 사건 하나가 아니라 작은 불편이 하나둘 쌓인 끝에 내린 결정이라 더 공감되는 부분이 많습니다.

출처: GeekNews (2026-11-08)

핵심 요약

📄 설정 파일 이중 관리: CLAUDE.md와 AGENTS.md 사이에서 파일을 복사하거나 심볼릭 링크를 따로 관리해야 했음
🖥️ VSCode 연동 제약: IDE에는 한 번에 한 세션만 연결할 수 있음
🧩 GUI 확장의 한계: 일부 슬래시 명령이 작동하지 않고, 사용자 지정 상태 표시줄이 없으며, 서브에이전트 출력이 메인 대화에 뒤섞임
🔄 잦은 변경: 올해 244회 릴리스 가운데 4분의 3 이상에서 시스템 프롬프트나 도구 설명이 바뀜
⚖️ 프롬프트 오버헤드: 기본 Bash 도구 설명만 3,000토큰 가까이 됨
✅ Pi로 전환한 뒤: 처음 며칠 조정 기간을 거친 뒤로는 안정성, 미니멀한 구조, 높은 사용자 지정 자유도에 만족하고 있음

처음엔 감탄했던 Claude Code

글쓴이는 Claude Code를 처음 썼을 때 프롬프트 하나로 주말 프로젝트용 Python 코드가 뚝딱 만들어지는 경험에 크게 놀랐다고 합니다. 코드가 깔끔하진 않았지만, Claude Code의 출시는 새로운 소프트웨어 개발 시대를 연 주요 동력 중 하나로 기억될 것이라고 평가하기도 했어요.

그래도 쓰는 시간이 길어질수록 작은 불편이 쌓였고, 결국 주력 도구를 바꾸기로 합니다.

불편 1. AGENTS.md 지원이 늦었다

글쓴이는 이 문제를 전환 이유를 가장 잘 보여 주는 사례로 꼽습니다.

저장소마다 CLAUDE.md를 두는 방식은 홍보에는 도움이 되지만, 사용자는 업계 표준에 가까운 AGENTS.md와 두 파일을 함께 관리해야 했습니다.
공교롭게도 전환을 결정한 바로 다음 날 Anthropic이 AGENTS.md 지원을 발표했지만, 이미 마음을 돌리기엔 늦었다고 하네요.

불편 2. VSCode에는 세션 하나만 연결된다

IDE 연결 기능은 에디터에서 선택한 코드를 질문이나 수정 요청의 문맥에 자동으로 넣어 줍니다. 생성된 코드를 커밋 전에 대부분 직접 검토하는 글쓴이에게는 꽤 유용한 기능이었죠.

문제는 첫 작업이 돌아가는 동안 두 번째 탭을 열면, 그 탭은 텍스트 선택 이벤트를 받지 못한다는 점입니다.
이 문제는 적어도 2025년 12월 버그 보고까지 거슬러 올라가지만, 관련 없는 버그의 중복으로 처리되어 닫혔습니다.
반면 Pi에서는 같은 기능을 여러 탭에서 처리하는 확장을 약 20분 만에 직접 만들었다고 합니다. 확장성이 어느 정도인지 보여 주는 대목입니다.

불편 3. 공식 GUI 확장도 대안이 되지 못했다

공식 VSCode GUI 확장은 여러 탭에서 선택한 텍스트를 문맥에 넣을 수 있지만, 다른 제약이 있었습니다.

내장 슬래시 명령의 절반가량이 GUI에서 작동하지 않음
사용자 지정 상태 표시줄 미지원
서브에이전트 출력이 시간순으로 메인 대화에 섞여 들어와, 에이전트를 여러 개 돌리면 읽기 어려움

불편 4. 기존 문제보다 새 기능이 먼저인 제품 방향

글쓴이는 기존 문제를 고치기보다 새 기능을 먼저 얹는 개발 방식에 불만을 드러냅니다. Dynamic workflows, agent teams, ultrareviews 같은 기능은 기업 고객의 토큰 사용을 늘릴 수는 있어도, 개인 작업에는 원하거나 필요한 기능이 아니었다고 해요.

불편 5. 자주 바뀌는 시스템 프롬프트

작성 시점 기준으로 올해 244회 릴리스가 있었고, 그중 4분의 3 이상에서 시스템 프롬프트나 도구 설명이 바뀌었습니다.

이런 변경은 모델 동작을 크게 바꿀 수 있습니다. 특히 새로 추가된 지침이 사용자 프롬프트나 저장소 규칙과 충돌하면 공들여 맞춰 둔 개인 설정이 흔들리게 되죠.

불편 6. 프롬프트 오버헤드

시스템 프롬프트가 80% 줄어든 뒤에도, 개인 사용에서는 Pi보다 큰 오버헤드를 감수할 만한 이점을 찾지 못했다고 합니다.
기본 Bash 도구 설명만 거의 3,000토큰인데, 상당 부분이 모델이 이미 할 줄 아는 git 사용법과 GitHub PR 생성 지침입니다.
그 안의 cat <<'EOF' 사용 지침은, auto 모드가 널리 쓰이기 전까지 기존 git 명령 허용 목록과 상관없이 늘 수동 검토 규칙을 발동시켰습니다.
글쓴이는 일간 활성 사용자 100만 명, 하루 1억 요청을 가정하면 요청당 1,000토큰만 줄여도 연간 수백만 달러의 추론 비용을 아낄 수 있다고 추산합니다.

Pi에게 기대하는 것: 안정성과 자유도

그렇다고 글쓴이가 Claude Code를 깎아내리기만 하는 건 아닙니다.

LLM 코딩 하네스는 아주 새로운 분야이고, 자신이 처음부터 제품을 맡았더라도 더 잘 만들었으리라고는 보지 않는다고 말합니다.
Pi 같은 후발 도구는 앞선 사례를 보고 무엇이 효과적인지, 무엇이 핵심이고 무엇을 덜어낼 수 있는지 판단할 수 있다는 이점이 있다는 점도 짚습니다.

다만 전환의 바탕에는 제품 방향성에 대한 불만이 있습니다. 개인적인 경험으로는 Claude Code가 다른 사용자의 불편을 충분히 고려하지 않은 채 엔지니어와 PM 각자의 작업 흐름에 맞춘 기능을 빠르게 덧붙이는 제품처럼 느껴졌다고 해요. 제품 개발에서는 기능 요청을 거절하는 역할이 중요한데, 그런 역할을 하는 상위 의사결정자가 보이지 않는다는 지적입니다.

Pi로 옮긴 뒤

처음 며칠은 조정이 필요했지만, 그 뒤로는 원활하게 사용 중
안정성, 미니멀한 접근, 높은 사용자 지정 자유도에 만족
자기 용도에 맞는 확장을 몇 개 만들었고, 정리해서 공개할 계획

에디터의 한마디 ✍️

이 글은 "어느 도구가 더 낫다"는 비교라기보다 개발자가 코딩 하네스에 무엇을 기대하는지를 보여 주는 사례에 가깝습니다. 기능이 많은 것보다 예측 가능하고, 가볍고, 내 작업 흐름에 맞게 고칠 수 있는 도구를 더 중요하게 여기는 사람도 분명히 있으니까요.

지금 쓰는 AI 코딩 도구에서 비슷한 불편을 느끼고 있다면, 글쓴이의 권유처럼 Pi 같은 오픈소스 하네스를 한 번 시험해 보는 것도 좋겠습니다. 반대로 팀 단위 협업 기능이나 다양한 내장 기능이 필요하다면 Claude Code 같은 도구가 여전히 더 맞을 수 있습니다. 결국 정답은 내 작업 방식에 달려 있습니다.

원문: https://news.hada.io/topic?id=36795&utm_source=geeknews&utm_medium=rss&utm_campaign=news