실제 업무를 위해 Claude Opus 4.7과 GPT-5.4를 번갈아 사용해 본 한 달간의 기록

저는 비교를 목적으로 시작한 것이 아닙니다. 업무용으로 하나를 결제하고, 개인용으로 다른 하나를 결제하고 있었기에 두 모델을 모두 띄워두고 있었을 뿐입니다. 실제 티켓(tickets)을 처리하며 한 달 동안 두 모델을 번갈아 사용해 본 결과, 제 의견을 글로 남길 가치가 있다고 느낄 만큼 충분한 견해가 쌓였습니다. 이 글은 벤치마크(benchmark) 포스트가 아닙니다. 벤치마크는 어디에나 널려 있지만, 다른 사람의 코드 세 겹을 파고들고 있는 금요일 오후 4시의 체감 성능과는 거의 일치하지 않습니다.

Opus 4.7이 저에게 승리한 부분

일관성을 유지하는 긴 컨텍스트(Long context)입니다. 저는 정말 지저분한 리팩터링(refactor) 작업을 맡겼습니다. 세 명의 서로 다른 컨벤션(conventions)이 뒤엉킨 채 1,200줄이 넘어버린 서비스 파일이었는데, Opus 4.7은 이미 무엇을 변경했는지 놓치지 않고 전체 내용을 머릿속에 담아두었습니다. 이것이 바로 리더보드(leaderboard)에 담기 어려운 부분입니다. GPT-5.4도 날카롭지만, 두 메시지 전에 자신이 도입했던 무언가를 다시 "수정"해버리는 경우가 몇 번 있었는데, Opus는 그런 일이 훨씬 적었습니다.

또한 단순히 작업을 수행하는 대신 "이것은 위험합니다"라고 말해주는 능력이 더 뛰어납니다. 데이터베이스 컬럼(database column)을 마이그레이션(migrate)해달라고 요청했을 때, Opus는 제가 스테이징(staging) 환경에서 부딪히기 전에 백필(backfill) 문제를 실제로 지적해 주었습니다. 작은 부분이지만, 저의 저녁 시간을 아껴주었습니다.

GPT-5.4가 승리한 부분

속도와 초안 코드입니다. 그린필드(greenfield) 작업 — 파서를 작성하거나 엔드포인트(endpoint)의 스캐폴딩(scaffold)을 만드는 일 — 에 있어서 GPT-5.4는 저를 더 빠르게 실행 가능한 초안 단계로 이끌어주었으며, 첫 번째 패스(pass)에서 작성된 코드가 대개 관용적(idiomatic)인 형태에 더 가까웠습니다. 프로토타이핑(prototyping) 중이고 어차피 코드를 버릴 예정이라면, 저는 GPT-5.4를 찾습니다.

또한 기본적으로 덜 장황합니다. Opus는 설명을 좋아하는 경향이 있습니다. 때로는 설명이 필요하지만, 종종 저는 그저 디프(diff)만 원할 때가 있습니다.

솔직한 짜증 유발 요소들

두 모델 모두 매우 대중적이지 않은 라이브러리 API(library APIs)에 대해서는 여전히 환각(hallucinate) 현상을 보입니다. 같은 주에 두 모델 모두로부터 자신만만하게 틀린 임포트(import)를 받아 시간을 허비한 적이 있습니다. 니치(niche)한 패키지를 사용할 때는 두 모델 모두 실제 문서(docs)를 읽는 것을 대체할 수 없습니다.

그리고 비용은 현실적인 문제입니다. 많은 반복 작업(iterating)을 수행한다면 심층 추론(deeper-reasoning) 실행 비용이 예상보다 빠르게 쌓이며, 청구서를 보기 전까지는 이를 알아차리기 쉽지 않습니다.

제가 실제로 내린 결론

저는 승자를 정하려는 시도를 그만두었습니다. 까다롭고, 상태 유지(stateful)가 필요하며, "기존 시스템을 망가뜨리지 말아야 하는" 작업에는 Opus를 사용합니다. 빠른 초안 작성과 일회성 프로토타이핑(prototyping)에는 GPT-5.4를 사용합니다. 모델을 충성도에 기반한 결정으로 취급하지 않게 되면, 전환 비용(switching cost)은 낮아집니다.

만약 회사가 제공해준 것 때문에 단 하나의 모델만 사용해 왔다면, 본인의 업무에 다른 모델을 일주일 동안 직접 사용해 보는 것은 진정으로 가치 있는 일입니다. 두 모델 사이의 격차는 마케팅에서 암시하는 것보다 작지만, 각 모델이 강점을 보이는 "형태(shape)\