r/PiCodingAgent•약 19시간 전•13•6

Gemini가 Claude보다 코드 수정 속도가 5배 느려서 'edit' 기능을 껐습니다

Gemini was 5x slower than Claude at code edits in pi, so I stopped letting it run `edit`

핵심 요약

Gemini의 비효율적인 코드 수정 방식을 우회하기 위해 DeepSeek을 활용한 빠른 수정 파이프라인을 구축했습니다.

Gemini 성능 문제 — 코드 수정 시 Claude 대비 5배 느리고 토큰 낭비가 심함
수정 방식 개선 — Gemini는 수정 지시만 내리고 DeepSeek이 실제 코드 변경을 수행
성능 향상 — SQL 리팩토링 작업 시 수정 시간을 103초에서 29초로 단축
오류 감소 — 기존 방식의 'oldText not found' 오류가 완전히 사라짐

세션 도중에 제미나이 쓰다가 자꾸 클로드로 갈아탔음. 왜냐면 `edit(oldText, newText)` 호출할 때 제미나이는 중앙값이 42초(p95는 172초)나 걸리는데, 오퍼스는 9초면 끝나거든. 내 세션 로그에서 599번의 edit 호출을 분석해보니까, 제미나이는 호출당 평균 9.3KB의 `oldText`/`newText`를 쳐먹더라(클로드보다 4배 많음). 게다가 JSON 이스케이프된 문자열 스트리밍하기 전에 공백 확인한다고 생각 토큰만 수천 개씩 날려먹고 앉았음.

그래서 pi에서 제미나이 차례일 땐 `edit`을 숨겨버리고 대신 `fast_edit(path, instructions)`를 연결해버림. 제미나이는 높은 사고 수준을 유지하면서 뭘 바꿀지만 적게 하고, 그다음 딥시크(`reasoning_effort="none"`, 초당 약 195 토큰)가 파일의 번호 매겨진 뷰를 기준으로 원본 `SPAN: L<start>..L<end>` 줄 교체 내용을 뱉어내게 함.

620줄짜리 파일에서 SQL 리팩토링 돌려보니까 편집 시간이 103초에서 29초(제미나이 23초 + 딥시크 6초)로 줄어듦. `oldText not found` 때문에 재시도하는 일도 아예 없어짐.

*(참고: 세션 로그 분석이랑 테스트벤치 실행은 `carbon-high` 설정으로 진행함.)*

원문

커뮤니티 목록

r/PiCodingAgent•약 19시간 전•13•6

Gemini가 Claude보다 코드 수정 속도가 5배 느려서 'edit' 기능을 껐습니다

Gemini was 5x slower than Claude at code edits in pi, so I stopped letting it run `edit`

핵심 요약

Gemini의 비효율적인 코드 수정 방식을 우회하기 위해 DeepSeek을 활용한 빠른 수정 파이프라인을 구축했습니다.

Gemini 성능 문제 — 코드 수정 시 Claude 대비 5배 느리고 토큰 낭비가 심함
수정 방식 개선 — Gemini는 수정 지시만 내리고 DeepSeek이 실제 코드 변경을 수행
성능 향상 — SQL 리팩토링 작업 시 수정 시간을 103초에서 29초로 단축
오류 감소 — 기존 방식의 'oldText not found' 오류가 완전히 사라짐

*(참고: 세션 로그 분석이랑 테스트벤치 실행은 `carbon-high` 설정으로 진행함.)*

주요 댓글

r/picodingagent

Gemini의 느린 코드 수정 속도에 공감하며, 에이전트의 효율적인 수정 방식과 과거 Cursor의 사례를 공유하는 분위기입니다.

antigravity나 Gemini CLI에서는 수정이 어떻게 이루어지는지 궁금하네요. 분명 그걸 기반으로 학습시켰을 텐데 말이죠?

요즘 에이전트들은 수정 오류를 줄이기 위해 bash나 파이썬을 사용하는 걸 선호하는 편임.

맞음. Opus는 항상 기본적으로 그렇게 해왔는데, 멍청한 Gemini는 그걸 안 함. 파이썬을 써서 수정하라고 일일이 지시해야 했음.

진짜 역대급 토큰 잡아먹는 괴물임.

근데 Claude랑 Gemini를 어떻게 호출하고 있는 거임? AGY CLI ACP를 쓰면 초기 예열 시간 때문에 느릴 수 있음. 아니면 다른 사람들이 겪는 느림 현상을 똑같이 느끼는 걸 수도 있고. 나도 계정이 여러 개라 하루에 한두 번씩 타이밍 테스트를 돌리는데, 어떤 날은 2~5초 만에 응답이 오다가도 가끔은 '1+1' 같은 간단한 질문에도 첫 토큰이 나오기까지 60~90초씩 걸릴 때가 있음. 생각할 게 전혀 없는데도 말이지.

이게 Cursor가 하는(했던?) 방식임: 코드 생성 모델이 인간이 읽을 수 있는 형태의 수정안을 내놓고, 그 안에 //existing code here... 같은 주석을 섞어둔 뒤, 그걸 실제 파일 수정 작업을 수행하는 특화된 빠른 'apply' 모델에 넘기는 거지(작성자가 DeepSeek으로 하고 있는 방식). 예를 들면 https://openrouter.ai/morph/morph-v3-large

근데 요즘은 다들 이 방식을 안 쓰는 것 같음. 최신 수정 적용 모델들은 다 2025년 버전인 것 같더라고.

원문r/PiCodingAgent