이제 모든 개발자는 코드 일부를 챗GPT에 붙여넣어 보았거나, 깃허브 코파일럿이 함수를 자동 완성하는 모습을 본 적이 있다. 만약 그것이 LLM 코딩에 대한 유일한 경험이라면, “아직 멀었다”는 결론을 내리기 쉽다. 실제로는 모델의 품질과 전문성이 너무 빠르게 발전하고 있어서, 심지어 8주 전의 경험조차 이미 구식이 돼 버릴 정도로 속도가 빠르다. 오픈AI, 앤트로픽, 구글은 올봄에 각각 모델을 크게 업그레이드했고, 오픈AI는 조용히 ‘o 시리즈’ 모델을 새로 도입하여 추론 기능에 중점을 두었다.

다음은 다섯 개 주요 모델을 실무에서 매일 사용한 후 작성된 현장 보고서이다. 복음처럼 받아들이기보다는 하나의 스냅샷으로 생각하며 읽어보자. 기사 발행 몇 주 후에는 또 작은 업데이트로 순위가 뒤바뀔 수도 있다.

오픈AI GPT-4.1 : 사용자 인터페이스 전문가, 메인 코더는 아님

오픈AI의 GPT-4.1은 이제 퇴역한 GPT-4.5 프리뷰를 대체하며, 더 저렴하고 지연 시간이 짧은 128K 토큰 컨텍스트와 더 나은 이미지-사양 변환 기능을 제공한다. 여전히 그린필드 스캐폴딩이나 스크린샷을 코드로 변환하는 데는 뛰어나지만, 이미 성숙한 코드베이스에 수정을 반영해야 할 때는 긴 의존성 체인이나 유닛 테스트의 엣지 케이스를 놓치곤 한다.

호출할 때 : 디자인 시스템 목업, API 문서 초안, UI 컴포넌트를 코드로 변환할 때.
피할 때 : 초기 스캐폴드 이후.

앤트로픽 클로드 3.7 소네트 : 믿음직한 일꾼

앤트로픽의 최신 소네트 모델은 여전히 필자가 가장 먼저 찾는 모델이다. 비용과 지연 시간의 균형이 가장 좋고, 128K 윈도우 내에서 프로젝트 전반의 맥락을 유지하며, 라이브러리 이름에서 거의 환각이 없다. 까다로운 버그에서는 가끔 테스트 대상 코드에 “특수 케이스 처리”를 추가하는 식으로 꼼수를 부리기도 한다(if (id==='TEST_CASE_1 data') 식 패치에 주의). 또한 ESLint나 타입스크립트 검사를 “속도를 위해” 비활성화하는 습관이 있으므로, 린터는 항상 켜두는 게 좋다.

최적 용도 : 반복적인 기능 작업, 5~50개 파일에 걸친 리팩터링, 빌드 파이프라인 추론.
약점 : 시각적 작업, CSS 미세 조정, 유닛 테스트 목(mock).
팁 : 코드 내에 “special case handling” 문자열이 있는지 grep으로 검색해보자.

구글 제미니 2.5 프로-Exp : 사용자 인터페이스 전문, 정체성 혼란

구글의 제미니 2.5는 100만 토큰 컨텍스트(200만 예고)를 제공하며, 현재 다양한 환경에서 무료로 사용할 수 있다(아직 API 호출 요금이 청구된 적이 없다). UI 작업에 탁월하고, 코드 생성 속도는 지금까지 써본 모델 중 가장 빠르다. 단점은? 학습 이후 변경된 API를 사용하는 리포지터리에서는 사용자의 “구식” 현실과 논쟁이 벌어지기도 한다. 가끔 사용자의 현실을 따옴표로 감싸기도 한다. 한 번은 로그에 나타난 현상이 “미래에 발생하는 일이므로 불가능하다”라고 주장하기도 했다.

사용 용도 : 대시보드, 디자인 시스템 정제, 접근성 점검, 빠른 UI 프로토타입.
주의점 : 자신감 넘치지만 틀린 API 호출, 환각된 라이브러리. 라이브러리 버전은 항상 다시 확인할 것.

오픈AI o3 : 고급 문제 해결사, 가격도 고급

오픈AI의 o3(이름 때문에 GPT 시리즈로 오해하기 쉽다)은 연구용 추론 엔진이다. 도구 호출을 연쇄 실행하고 분석 보고서를 작성하며, 300개 테스트가 있는 제스트(Jest) 스위트를 아무 불평 없이 검토한다. 단, 접근 제한이 있고(나는 여권을 제출해야 했다), 느리며, 비싸다. 만약 사용자가 FAANG급 예산을 갖고 있거나, 스스로 버그를 해결할 수 없는 상황이 아니라면, o3은 일상용이 아닌 사치품이다.

오픈AI o4-미니 : 디버깅의 메스

4월의 깜짝 스타는 o4-미니이다. 압축된 o 시리즈 변형으로, 치밀한 추론 루프에 최적화되어 있다. 실제 사용 시 o3보다 3~4배 빠르며, 오픈AI API에서는 여전히 비싸지만, 여러 IDE에서 무료로 속도 제한을 두고 사용할 수 있다. 클로드가 목(mock)된 의존성에서 멈춰서는 부분도, o4-미니는 테스트 하네스를 재구성하고 버그를 정확히 찾아낸다. 출력은 간결하며, 오픈AI 모델 치고는 이례적이다 (https ://openai.com/index/sycophancy-in-gpt-4o/).

최적 용도 : 복잡한 제네릭, 의존성 주입 엣지 케이스, 다른 모델이 막히는 목(mock) 전략.
비추천 용도 : 대량 코드 생성이나 장황한 설명. 간결한 패치만 제공된다.

멀티 모델 워크플로 : 실전 가이드

1. 챗GPT의 GPT-4.1로 UI 아이디어를 탐색하자. 슬라이드 덱을 드롭해서 목업을 생성하도록 요청하자. 이미지 생성 모델인 달리(DALL-E)는 글자를 이상하게 처리할 수 있으니 주의하자.
2. 클로드를 ‘생각 모드’로 설정해 초기 사양서를 작성하자. 다른 LLM에게 비평을 요청하자. 단계별 구현 계획을 받아보자. 가끔 o4-미니에게 이 사양이 LLM이 해석하기에 충분한지 물어보기도 한다.
3. 제미니 2.5로 스캐폴딩하자. 스케치 드롭, 리액트나 플러터 구조 생성, 전체 틀을 만들기 적합하다.
4. 클로드 3.7로 로직을 채우자. 구조물을 불러와 소네트에게 컨트롤러 로직과 테스트를 작성하게 하자.
5. 클로드가 놓친 부분은 o4-미니로 디버깅하거나 마무리하자. 테스트가 통과할 때까지 목이나 타입 스텁을 재설계하게 하자.

이 “바통터치” 방식은 각 모델이 자기 역할에 집중해서 토큰 낭비를 줄이고, 무료 이용 한도를 넘지 않으면서 성능을 극대화할 수 있다.

배포 전 꼭 유념해야 할 마지막 회의주의

LLM 코딩은 여전히 사람의 검토가 필요하다. 네 모델 모두 때때로 다음과 같은 행동을 한다 :

• 실패하는 경로를 수정하지 않고 스텁 처리한다.
• 의존성 트리를 과도하게 설치한다 (package.json 확인 요망).
• 타입 검사나 ESLint 가드를 “임시로” 비활성화한다.

자동 계약 테스트, 점진적 린팅, 커밋 시 차이점 리뷰는 필수다. 모델은 사진기억을 가진 인턴처럼 다루어야 한다. 패턴 인식에는 탁월하지만, 책임감은 전혀 없다. (아이러니하게도 이 문단은 o3에게 교정 부탁했을 때 추가된 문장인데, 마음에 들어서 그대로 뒀다.)

결론 2024년에 깃허브 코파일럿을 써보고 AI 코딩을 포기했다면, 도구를 다시 업데이트하라. 클로드 3.7 소네트는 일상 업무에서 가장 신뢰할 수 있고, 제미니 2.5는 프론트엔드 사용성에서 최고이며, o4-미니는 현재 최고의 디버거이다—비용을 감수하거나 인내심이 충분하다면 말이다. 조합해서 사용하라. 진짜 뇌가 필요한 순간에는 언제든 개입할 수 있으니까.
dl-itworldkorea@foundryco.com