🤖 개발자들이 클로드를 계속 선택하는 진짜 이유는 뭘까?

 

새 모델이 나올 때마다 반복되는 패턴이 있어요

AI 코딩 도구를 매일 사용하는 개발자들 사이에서 요즘 꽤 일관된 흐름이 반복되고 있어요. 새로운 모델이 출시되고, 벤치마크 점수가 역대 최고를 찍고, 개발자들이 몰려가서 써보고, 그리고 다시 클로드로 돌아옵니다. 이 패턴이 벌써 서너 번 반복됐습니다.

단순한 팬심이나 브랜드 충성도 이야기가 아니에요. 실제로 다른 도구들이 매번 같은 지점에서 실패하기 때문입니다. 앤트로픽에 따르면 최근 3개월 사이 클로드의 코딩 관련 수익이 10배 증가했다고 해요. 그냥 우연이 아니라는 거죠.

오늘은 벤치마크만 보고 AI 코딩 도구를 판단하면 안 되는 이유, 그리고 클로드가 현장 개발자들에게 계속 선택받는 진짜 이유를 제대로 짚어볼게요.

벤치마크 1위 모델이 실제 작업에서 기대에 못 미치는 이유

새 모델이 나올 때마다 가장 먼저 쏟아지는 건 벤치마크 결과죠. 코딩 관련 평가에서 높은 점수를 받았다는 소식이 들리면 개발자들은 자연스럽게 기대를 품게 됩니다. 그런데 그 모델이 거짓말을 하는 건 아니에요. 정말로 격리된 문제에서는 더 좋은 코드를 만들어냅니다.

문제는 실제 개발 환경이 벤치마크와 전혀 다르다는 거예요. 과거에 많이 쓰이던 HumanEval 같은 평가 방식은 독립된 함수 하나를 작성하고 테스트를 통과하면 됩니다. 최근에 나온 SWE-bench는 실제 깃허브 저장소의 이슈를 주고 패치를 만들게 해서 좀 더 현실에 가깝죠.

하지만 그것도 결국 통제된 환경이에요. 실제 개발 작업에는 훨씬 많은 것들이 동시에 일어납니다. 어떤 파일을 읽어야 하는지 판단하고, 주변 코드를 건드리지 않으면서 딱 필요한 부분만 수정하고, 예상치 못한 오류가 생겼을 때 스스로 해결할지 물어볼지 결정하고, 20단계가 넘는 작업을 흐트러지지 않고 끝까지 마무리하는 것. 이런 능력은 어떤 벤치마크로도 제대로 측정하기 어렵습니다.

참고로 클로드 Opus 4.1은 SWE-bench Verified에서 74.5%를 기록했고, Sonnet 4도 72.7%에 근접하면서 특히 다중 파일 코드 리팩토링과 디버깅에서 뚜렷한 강세를 보이고 있어요.

코딩 실력의 진짜 40%와 나머지 60%의 이야기

많은 사람들이 AI 코딩 도구를 평가할 때 "코드를 얼마나 잘 짜느냐"만 봅니다. 그런데 현직 개발자들의 경험을 종합해보면, 올바른 코드를 생성하는 능력은 전체 필요 능력의 40% 정도에 불과해요.

나머지 60%는 코드를 둘러싼 모든 것입니다. 변경하기 전에 올바른 파일을 먼저 읽는 것, 주변 코드를 망가뜨리지 않고 파일을 수정하는 것, 여러 단계에 걸친 작업을 중간에 맥락을 잃지 않고 완수하는 것, 가정하지 않고 적절한 때 질문하는 것, 요청하지 않은 관련 없는 파일에 임의로 변경을 가하지 않는 것. 이 모든 게 실제 개발 현장에서 신뢰할 수 있는 도구를 만드는 요소예요.

여기서 중요한 포인트가 있어요. 능력이 있느냐 없느냐의 문제가 아닙니다. 주요 코딩 에이전트들은 모두 파일 읽기, 코드 편집, 터미널 명령 실행이 가능해요. 차이는 이 워크플로우를 얼마나 일관되게 실행하느냐에 있습니다.

다른 도구들도 할 수는 있습니다. 클로드가 더 안정적으로 합니다. 개별 코드 품질에서 차이가 나는 게 아니에요. 전체 작업을 완수하는 일관성에서 차이가 납니다.

앤트로픽은 코딩의 결과물이 아니라 '과정' 자체를 훈련시켰어요

왜 이런 차이가 생기는 걸까요? 개발자들이 찾아낸 가장 설득력 있는 설명이 있어요. 앤트로픽이 클로드를 훈련시킬 때 코딩의 결과물이 아니라 과정 자체를 중점적으로 학습시켰다는 거예요.

즉, 유능한 개발자가 실제 코드베이스에서 작업을 받았을 때 실제로 어떤 순서로 무엇을 결정하는지, 그 워크플로우 전체를 학습했다는 이야기입니다.

앤트로픽 공개 자료에 따르면 자사 에이전트 형태 사용의 거의 절반이 소프트웨어 개발 관련이에요. 전체 에이전트 활용의 50%가 코딩입니다. 이게 현실이라면 당연히 그에 맞게 훈련하게 되죠. 파일 편집 방식, 도구 사용 흐름, 다단계 워크플로우 전체를 최적화할 수밖에 없어요. 실제 사용자들이 그걸 쓰고 있으니까요.

이 부분이 정말 중요해요. 더 큰 모델을 만드는 것만으로는 이 격차를 좁힐 수 없어요. 세상에서 가장 똑똑한 모델이라도 옆 파일을 망가뜨리지 않고 파일 하나를 수정하지 못한다면 의미가 없습니다.

실제 한국 개발자들도 이걸 이미 알고 있었어요

한국 개발자 커뮤니티에서도 이런 흐름이 명확하게 나타나고 있어요. 클로드 코드 토큰 사용량으로 전 세계 1위를 기록한 한국인 개발자 박진형 씨는 "AI 코딩의 핵심은 얼마나 빨리 결과를 꺼내 사람과 피드백 루프를 도는가에 있다"고 말했어요. 단순히 토큰을 많이 쓰는 것이 실력이 아니라, AI와 얼마나 정교한 피드백 루프를 형성하느냐가 생산성의 핵심이라는 거죠.

서울은 전 세계에서 클로드 코드 밋업을 2회 연속으로 개최한 첫 도시이기도 해요. 앤트로픽 내부에서도 자체 코드의 80%를 클로드 코드로 작성하고 있다고 공개했습니다. 자기들이 만든 도구를 자기들이 제일 많이 쓰고 있다는 건, 신뢰할 수 있는 신호죠.

소프트웨어 기업 깃랩은 클로드를 사용하는 개발팀의 효율성이 25~50% 향상했다고 밝혔고, 코드 인텔리전스 플랫폼 소스그래프는 클로드 채택 후 코드 삽입률이 75% 증가했다고 해요.

다른 모델들이 실패하는 공통 패턴, 루프와 맥락 상실

매일 코딩 도구를 쓰는 개발자들이 공통적으로 지적하는 실패 패턴이 있어요. 바로 루프와 맥락 상실입니다.

다른 도구들은 여러 파일에 걸친 작업 중간에 뭔가 흐트러지는 경우가 있어요. 파일이 일부 덮어써지거나, 요청하지 않은 부분을 임의로 "개선"하기 시작하거나, 작업 중간에 방향을 잃고 계속 개입이 필요해지거나. 그 코드 자체는 충분히 좋을 수 있어요. 그런데 작업 흐름 어딘가에서 무언가가 어긋납니다.

클로드를 주 도구로 쓰는 개발자들이 공통적으로 말하는 것은 "감시 없이 맡겨도 되는 신뢰"입니다. 새 기능 추가, 운영 중인 버그 디버깅, 컴포넌트 리팩토링. 이런 작업을 완벽하지는 않지만 일관되게 처리해요. 매 단계마다 직접 확인하지 않아도 된다는 것, 그게 실제 생산성의 차이를 만듭니다.

능력의 차이가 아닙니다. 과정 규율의 차이입니다. 그리고 이게 훈련하기 훨씬 어렵다는 걸 많은 사람들이 아직 인식하지 못하고 있어요.

구글 제미나이가 코딩 에이전트로 한계를 보이는 구조적 이유

제미나이가 코드를 못 짜는 건 아니에요. 잘 정의된 문제를 주면 훌륭한 코드를 만들어냅니다. 그런데 에이전트 방식으로 복잡한 작업을 독립적으로 수행하게 하면 다른 이야기가 돼요.

이건 구글의 구조적인 문제로 봐야 해요. 구글은 근본적으로 검색과 범용 서비스 회사예요. 제미나이는 번역, 요약, 멀티모달 이해, 일반 대화 등 방대한 범위에 걸쳐 최적화되어 있습니다. 에이전트 방식의 소프트웨어 개발은 그 수십 가지 용도 중 하나일 뿐이에요.

반면 앤트로픽에게는 코딩이 사업의 핵심입니다. 에이전트 활용의 절반이 코딩이라면, 그 워크플로우에 집중적인 강화 학습을 투자하는 것이 당연한 선택이죠. 긴 도구 호출 시퀀스를 성공적으로 완수하는 것, 중간에 오류가 생겨도 자연스럽게 회복하는 것, 여러 단계에 걸쳐 맥락을 잃지 않는 것. 이런 훈련은 일반 모델 규모를 키우는 것과는 별개의 집중적인 작업이에요.

구글이 이 격차를 좁히지 못하는 건 능력의 문제가 아니라 우선순위의 문제입니다. 모든 걸 잘 해야 하는 회사와, 코딩 하나에 올인하는 회사의 차이라고 볼 수 있어요.

이 격차는 영원하지 않아요, 하지만 지금 중요한 건 이거예요

클로드의 이 우위가 영구적인 건 아닙니다. 오픈AI도 에이전트 방식 워크플로우를 진지하게 받아들이고 있고, 구글도 충분한 자원이 있어요. 만약 이 과정 규율 문제를 우선순위에 두고 집중한다면 격차는 좁혀질 수 있습니다.

하지만 중요한 건, 단순히 모델을 더 크게 만드는 것으로는 해결이 안 된다는 점이에요. 앤트로픽이 발견한 것, 즉 결과물이 아닌 워크플로우 자체를 훈련한다는 접근은 다른 회사들이 의식적으로 복제해야 하는 통찰입니다. 그냥 따라오는 게 아니라 명시적으로 그 방향을 선택해야 해요.

앞으로 몇 달 안에 벤치마크 1위는 계속 바뀔 거예요. 새 모델이 나오고, 개발자들이 시도하고, 일부는 옮겨가고, 대부분은 다시 돌아오는 패턴도 반복될 겁니다. 그 흐름 속에서 한 가지는 변하지 않아요. 벤치마크는 하나의 이야기를 하고, 매일 실제로 도구를 쓰는 개발자들은 다른 이야기를 합니다. 그리고 보통은 개발자들의 말을 들어야 합니다.

마무리: 벤치마크가 아닌 현장의 목소리를 들어야 합니다

AI 코딩 도구 경쟁은 단순히 코드를 얼마나 잘 짜느냐의 싸움이 아닙니다. 실제 개발 흐름 안에서 얼마나 일관되게 올바른 판단을 내리느냐, 즉 워크플로우 전체를 얼마나 안정적으로 수행하느냐가 핵심이에요. 클로드가 매번 새 경쟁자가 등장해도 현장 개발자들에게 선택받는 이유는 바로 이 과정 규율에 있습니다. 다음에 새 모델이 벤치마크 1위를 차지했다는 소식을 들으면, 그 수치가 실제 작업에서 어떤 의미인지 한 번 더 생각해보세요. 좋은 도구는 숫자가 아니라 매일의 작업 흐름이 증명합니다.