같은 모델을 호출해도 어떤 파일을 읽고, 어떤 도구로 수정하고, 언제 검증하는지는 에이전트 실행 도구가 결정합니다. 그래서 코딩 도구를 바꾸는 실험은 모델 비교만으로 끝나지 않습니다.

Goodbye Claude, Hello Pi는 11월 8일 새로 발표된 글이 아닙니다. 원문은 9월 21일이며, 여러 사용성 불편 때문에 Pi로 옮겼다는 개인의 경험담입니다. 해당 시점의 불만을 현재 모든 버전의 기능 결함으로 취급하거나 생산성 우위의 증거로 일반화하지 않습니다.

전환 경험담을 읽을 때 빠지기 쉬운 변수

작성자가 바꾼 것은 단순한 UI만이 아닙니다. 지시문을 전달하는 방식, 확장을 작성하는 비용, 대화를 이어가는 방식도 사용자 경험에 영향을 줍니다. 어떤 사람에게는 기본 기능이 적어 직접 구성할 수 있는 제품이 편하고, 다른 팀에는 표준화된 검증과 운영 지원이 더 중요할 수 있습니다.

Pi 공식 사이트는 확장·스킬·프롬프트 템플릿을 통한 구성을 설명하고, 세션을 트리로 저장하는 구조를 소개합니다. 공식 저장소는 모델 API, 에이전트 루프, 터미널 UI와 코딩 CLI를 구분합니다. 이것은 구성 가능성의 근거이며, 그 구성으로 우리 팀이 얼마나 빨라질지에 대한 측정은 아닙니다.

하네스는 여기서 모델 호출을 둘러싼 도구·상태·검증의 실행 구조를 뜻합니다. 같은 모델 이름을 선택해도 시스템 지시, 도구 정의, 컨텍스트 압축과 재시도 정책이 다르면 모델에 실제로 들어간 입력과 가능한 행동이 달라집니다.

비교 실험에는 두 가지 질문이 필요하다

첫 질문은 “통제된 조건에서 실행 구조가 어떤 차이를 만드는가”입니다. 두 번째는 “팀이 실제로 유지할 구성으로 작업을 끝내는 비용은 얼마인가”입니다. 둘을 하나의 점수로 합치면 도구의 편리한 기본값을 제거하거나, 반대로 모델 차이를 하네스 차이로 오해할 수 있습니다.

항목 통제 비교 실제 도입 비교
모델 동일한 제공자·버전·설정 팀이 사용할 모델, 차이 명시
도구·네트워크 같은 허용 범위 운영 정책에 맞는 실제 범위
시작 상태 같은 커밋의 별도 작업 공간 같은 대표 업무 집합
확장 최소 공통 구성 필요한 확장 포함, 버전 고정
종료 조건 독립 수락 테스트 통과 리뷰·수정·CI까지 완료

이 표는 CodeBridge의 제안이며 제품 벤치마크 결과가 아닙니다. 작업 공간을 공유하면 첫 실행의 패치나 캐시가 다음 실행에 영향을 줄 수 있으므로 별도 디렉터리에서 시작하세요. 시행 순서를 바꾸고 반복 실행해야 첫 실행·우연한 성공의 영향을 살펴볼 수 있습니다.

도구 호출을 읽을 수 있는 기록으로 바꾼다

단순한 호출 수는 성공률을 설명하지 못합니다. 파일을 열 번 읽는 것이 필요한 탐색일 수도 있고 같은 오류의 반복일 수도 있습니다. 다음은 가상 작업 한 건의 기록 형식이며 실제 Pi·Claude 실행 로그가 아닙니다.

{
  "task": "report-filename-change",
  "start_commit": "example-base",
  "model_revision": "record-the-exact-version",
  "harness_revision": "record-the-exact-version",
  "extensions": [],
  "acceptance_passed": true,
  "agent_minutes": 8,
  "review_minutes": 12,
  "rework_minutes": 6,
  "out_of_scope_files": 0
}

위 가상 값에서 관측한 세 구간이 겹치지 않는다면 합계는 26분입니다. 이 숫자는 실제 제품 성능이 아닙니다. 에이전트 실행 8분만 비교하면 검토와 재작업 18분이 사라진다는 계산 예시입니다. 병렬 작업에서는 구간의 합과 사람이 기다린 실제 경과 시간을 별도로 기록해야 합니다.

추가로 남길 것은 거부된 도구 호출, 변경한 파일, 검증 명령과 종료 이유입니다. 비밀정보가 들어갈 수 있는 전체 명령·대화 내용을 무조건 중앙 수집하지 말고, 필요한 메타데이터부터 정하세요. 승인 기록의 비밀정보 경로가 같은 문제를 보안 관점에서 다룹니다.

확장의 자유에는 유지보수 비용이 붙는다

필요한 기능을 직접 붙일 수 있다면 맞춤 워크플로를 만들기 좋습니다. 하지만 확장의 실행 권한, 업그레이드 호환성, 담당자가 없을 때의 복구 절차도 팀이 맡게 됩니다. 작은 코어가 자동으로 작은 전체 시스템을 뜻하지는 않습니다.

반대로 기능이 많은 도구라도 팀이 쓰지 않는 기능을 비활성화하고 작업 범위를 제한할 수 있다면 충분히 단순하게 운영할 수 있습니다. 이 글에서는 두 제품을 설치하거나 동일 모델로 실행하지 않았으므로 어느 쪽의 총비용이 낮다고 결론 내리지 않습니다.

교체 결정은 회수할 수 있는 비용으로 내린다

한 사람의 성공적인 전환은 시험해 볼 이유가 될 수 있지만 팀 전체를 옮길 근거로는 부족합니다. 먼저 반복되는 업무 몇 개에서 통제 비교를 하고, 그다음 실제 확장을 포함한 도입 비교를 하세요. 검토 시간, 실패 후 복구, 확장 유지 비용이 함께 줄어드는지 확인해야 합니다.

좋은 결과는 “프롬프트가 더 짧다”가 아니라, 팀이 검증할 수 있는 변경을 더 적은 총비용으로 받아들였다는 기록입니다. 그 기록이 없다면 도구 교체는 성능 개선이 아니라 선호에 따른 선택으로 남겨 두는 편이 정확합니다.