성능 개선인데 모델 얘기가 아니야

오픈AI 코덱스 팀이 예고한 이번 업데이트에는 벤치마크 점수가 없어. 대신 이런 숫자들이 있어. 741턴짜리, 용량 231MB에 달하는 대화를 여는 데 걸리던 시간이 27.6초에서 1.7초로 줄었어. 94% 단축이야. 같은 조건에서 렌더러 메모리 증가량은 약 88% 줄었고, 서버와 클라이언트 사이를 오가던 요청 횟수는 약 98% 감소했어.

이 수치는 코덱스를 이끄는 앤드류 앰브로시노가 8월 14일 공개한 내부 슬랙 메시지 스크린샷을 통해 알려졌어. 오픈AI가 정식 발표문으로 낸 게 아니라, 팀 내부에서 돌던 성능 개선 리포트가 외부로 나온 형태야. 업데이트 자체는 그 주에 배포될 예정이라고 언급됐어.

숫자가 재미있는 건 개선 대상이 모델이 아니라는 점이야. GPT가 더 똑똑해진 게 아니라, 대화 기록을 관리하는 클라이언트가 덜 멍청해진 거야. 그런데 이게 지금 코딩 에이전트 경쟁에서 꽤 중요한 축이 됐어.

코덱스가 지금 어디쯤 서 있는지

코덱스는 오픈AI가 2025년에 내놓은 코딩 에이전트야. 처음에는 클라우드에서 돌아가는 비동기 작업 도구로 시작했는데, 이후 CLI와 IDE 확장, 데스크톱 앱으로 계속 형태를 늘려 왔어. 지금은 터미널에서 명령을 받아 저장소를 읽고 고치고 테스트를 돌리는 방식이 주력이야. 클로드 코드가 만든 사용 패턴을 오픈AI가 자기 모델 위에서 재현하고 확장해 온 셈이야.

앤드류 앰브로시노는 이 코덱스 조직을 이끄는 사람이야. 최근 외부 인터뷰에서 그는 "구현은 이제 싸졌고 희소한 자원은 취향"이라는 취지의 말을 했어. 코드를 짜는 비용이 급격히 떨어진 상황에서 제품 조직이 무엇에 집중해야 하는지를 정리한 말인데, 이번 최적화 작업과도 통해. 모델이 코드를 잘 짜는 건 이제 기본값이고, 그 위에서 사람이 얼마나 매끄럽게 일하느냐가 남은 승부처라는 거지.

코딩 에이전트 시장 자체도 1년 사이 완전히 달라졌어. 2025년에는 자동완성이 중심이었고, 지금은 에이전트가 계획을 세우고 여러 파일을 동시에 고치고 검증까지 하는 게 표준이 됐어. 오픈AI, 앤스로픽, 구글, 커서, 그리고 오픈소스 도구들이 같은 자리를 두고 붙는 중이야. 모델 품질 격차가 좁혀지면서 승부처는 통합 품질과 운영 안정성 쪽으로 내려오고 있어.

이번 발표가 정식 릴리스 노트가 아니라 내부 스크린샷이라는 점도 이 경쟁 상황과 무관하지 않아. 성능 개선 수치를 팀 내부 기록 형태로 먼저 흘리는 건, 정식 발표 전에 개발자 커뮤니티의 관심을 잡아 두는 방식이기도 해.

741턴이라는 숫자가 말해 주는 것

먼저 741턴이 어떤 상황인지 감을 잡아 보자. 한 세션에서 사람과 에이전트가 741번 주고받았다는 뜻이야. 파일을 읽고, 테스트를 돌리고, 실패를 보고, 고치고, 다시 돌리는 걸 하루 종일 반복하면 나오는 숫자야. 대화 용량이 231MB라는 건 그 안에 파일 내용, 터미널 출력, 도구 호출 결과가 통째로 쌓였다는 뜻이고.

작년까지만 해도 이런 사용 패턴은 극단적인 예외였어. 코딩 도구는 "함수 하나 짜 줘" 수준으로 쓰는 게 보통이었고, 대화가 길어지면 새 세션을 열면 됐거든. 그런데 에이전트가 스스로 계획을 세우고 여러 파일을 고치고 테스트까지 돌리는 방식이 자리 잡으면서, 한 세션이 몇 시간에서 며칠까지 이어지는 게 흔해졌어.

문제는 클라이언트 소프트웨어가 이런 사용 패턴을 전제로 설계되지 않았다는 거야. 대화 기록 전체를 메모리에 올려 두고, 화면을 그릴 때마다 전부 다시 계산하고, 상태가 바뀔 때마다 서버에 물어보는 구조로 만들면 짧은 대화에서는 아무 문제가 없어. 대화가 700턴을 넘어가는 순간 그 구조가 무너져.

27.6초라는 숫자가 그 붕괴의 결과야. 세션을 다시 열 때마다 30초 가까이 기다려야 한다면, 아무리 모델이 좋아도 사람은 그 도구를 쓰지 않게 돼.

그리고 이런 지연은 단순한 불편으로 끝나지 않아. 사람이 도구를 쓰는 방식 자체를 바꿔 놓거든. 세션 여는 게 느리면 세션을 짧게 유지하게 되고, 세션이 짧으면 에이전트에게 큰 작업을 맡기지 않게 돼. 결국 "에이전트한테 큰 걸 맡기면 안 된다"는 경험칙이 생기는데, 이건 모델 능력의 한계가 아니라 클라이언트 성능이 만든 습관이야. 오픈AI가 이 숫자를 굳이 공개한 이유도 그 습관을 깨려는 쪽에 가까워.

무엇을 고쳤길래 이렇게 줄었나

지표 이전 이후 개선폭
741턴 대화 로딩 27.6초 1.7초 약 94%
렌더러 메모리 증가량 기준 — 약 88% 감소
서버-클라이언트 요청 수 기준 — 약 98% 감소
테스트 대화 용량 231MB 231MB 동일

세 지표가 같이 움직인 걸 보면 개선의 방향을 짐작할 수 있어. 요청 수가 98% 줄었다는 건 이전에 화면을 구성하면서 잘게 쪼갠 요청을 수백 번씩 날리고 있었다는 뜻이야. 메모리 증가량이 88% 줄었다는 건 전체 기록을 통째로 들고 있던 걸 필요한 부분만 들고 있도록 바꿨다는 뜻이고. 로딩 시간이 94% 줄어든 건 그 두 변화의 결과야.

공개된 코덱스 체인지로그를 보면 이 방향의 작업이 몇 주 전부터 이어져 왔다는 걸 알 수 있어. 8월 7일 배포된 CLI 0.147.0에는 "대화를 지속적인 섹션으로 정리하고 긴 기록을 점진적으로 탐색"하는 기능과 페이지네이션 기반 기록 조회가 들어갔어. 전체를 한 번에 불러오지 않고 필요한 만큼만 가져오는 구조야. 이번에 공개된 수치는 그 작업이 실제 사용 조건에서 얼마나 효과가 있었는지를 보여주는 결과 보고서인 셈이야.

개선 방식 자체는 소프트웨어 엔지니어링에서 오래된 처방이야. 전부 불러오지 말고 필요한 만큼만 불러오기(지연 로딩), 화면에 보이는 부분만 그리기(가상 스크롤), 여러 요청을 하나로 묶기(배칭), 그리고 변하지 않은 부분은 다시 계산하지 않기(캐싱). 새로운 기술이 필요한 게 아니라, 에이전트 클라이언트가 급하게 커지는 동안 미뤄 뒀던 기본기를 뒤늦게 갖춘 거야.

여기서 오해하기 쉬운 지점이 하나 있어. 로딩이 빨라졌다고 모델이 741턴을 다 기억하는 건 아니야. 컨텍스트 윈도우는 그대로고, 모델에 실제로 들어가는 건 여전히 그중 일부야. 바뀐 건 그 기록을 저장하고 화면에 보여주는 쪽이지 모델이 참조하는 범위가 아니야. 둘을 섞어서 이해하면 "이제 맥락이 안 날아가겠네"라는 잘못된 기대를 하게 돼.

같은 시기 코덱스 쪽에는 다른 변화도 붙었어. 8월 11일에는 리눅스용 데스크톱 앱 프리뷰가 나왔고, 클로드 코드와 커서에서 설정과 최근 작업을 가져오는 기능이 들어갔어. 경쟁 도구에서 넘어오는 마찰을 줄이겠다는 의도가 분명한 기능이야.

각자가 챙기는 것

오픈AI가 챙기는 건 체류 시간이야. 코딩 에이전트 경쟁에서 승부처가 모델 품질에서 세션 지속성으로 옮겨 가고 있어. 개발자가 한 도구 안에서 오래 머물수록 그 도구가 쌓는 맥락이 두꺼워지고, 다른 도구로 옮기는 비용이 커져. 27초를 1.7초로 줄이는 건 그 체류를 끊지 않게 만드는 작업이야.

개발자가 챙기는 건 세션을 안 버려도 된다는 것이야. 지금까지는 대화가 길어지면 느려지니까 주기적으로 세션을 접고 새로 시작하는 게 관행이었어. 그때마다 맥락을 다시 설명해야 했고. 로딩이 1.7초면 그럴 이유가 사라져. 대규모 리팩터링이나 며칠짜리 디버깅처럼 맥락이 통째로 필요한 작업을 한 세션에서 밀어붙일 수 있게 돼.

기업 개발팀이 챙기는 건 예측 가능성이야. 도구가 특정 규모를 넘으면 급격히 느려진다는 건 도입 검토에서 큰 감점 요인이야. "우리 모노레포에서도 버티냐"는 질문에 숫자로 답할 수 있게 된 건 영업 관점에서 의미가 커.

오픈AI가 또 하나 챙기는 건 비용이야. 서버-클라이언트 요청이 98% 줄었다는 건 오픈AI 쪽 인프라 부하도 그만큼 줄었다는 뜻이야. 코덱스 사용자가 수백만 명 단위로 늘어나는 상황에서 요청 수를 두 자릿수 배수로 줄이는 건 서비스 원가에 직접 반영돼. 사용자 경험 개선과 원가 절감이 같은 작업에서 나온 흔치 않은 경우야.

경쟁사가 챙기는 건 벤치마크 기준이야. 741턴이라는 구체적 조건이 공개된 이상, 다른 코딩 에이전트들도 비슷한 조건에서 자기 수치를 내야 하는 압박을 받게 돼. 모델 벤치마크 옆에 클라이언트 성능 벤치마크가 하나 더 생긴 거야.

도구가 무거워져서 진 사례들

개발 도구 역사에서 성능이 승패를 갈랐던 사례는 많아.

이클립스와 인텔리제이의 경쟁이 대표적이야. 두 IDE의 기능 차이는 크지 않았는데, 대형 프로젝트에서 응답성이 갈렸어. 프로젝트가 커질수록 이클립스가 버벅인다는 인식이 퍼지면서 자바 개발자들이 인텔리제이로 옮겨 갔어. 기능 목록이 아니라 매일 겪는 지연이 결정을 만들었어.

아톰과 VS 코드도 같은 이야기야. 둘 다 일렉트론 기반이었는데, 큰 파일을 열 때의 성능 차이가 컸어. 아톰은 결국 개발이 중단됐고 VS 코드가 시장을 가져갔어. 여기서도 성능이 기능보다 앞섰어.

반대로 성능만으로는 부족했던 사례도 있어. 서브라임 텍스트는 당시 어떤 에디터보다 빨랐지만, 확장 생태계와 무료 정책에서 VS 코드에 밀렸어. 빠른 게 필수 조건이긴 해도 충분 조건은 아니라는 뜻이야.

한 가지 더 참고할 사례는 깃 자체야. 리누스 토르발스가 깃을 만들 때 최우선 요구사항이 속도였어. 리눅스 커널처럼 큰 저장소에서 브랜치 전환과 커밋이 순식간에 끝나야 한다는 조건이 설계를 결정했고, 그 선택이 결과적으로 다른 버전 관리 도구들을 밀어냈어. 도구가 다루는 대상이 커질수록 성능이 기능을 압도하는 구간이 온다는 걸 보여준 사례야. 코딩 에이전트도 지금 그 구간에 들어서고 있어.

코딩 에이전트 판에서도 같은 구도가 반복될 가능성이 커. 모델 품질은 몇 달 단위로 서로 따라잡히지만, 클라이언트 성능과 통합 품질은 누적된 엔지니어링이라 따라잡는 데 시간이 걸려. 이번 수치는 오픈AI가 그 축에 자원을 쓰고 있다는 신호야.

경쟁자들은 어떻게 나올까

앤스로픽 클로드 코드는 터미널 기반이라 시작부터 가벼운 편이야. 대신 긴 세션의 맥락 관리를 압축(compact) 방식으로 풀어 왔어. 컨텍스트가 차면 요약해서 이어 가는 구조인데, 요약 과정에서 세부가 날아간다는 불만이 늘 있었어. 이번 코덱스의 접근은 요약이 아니라 저장·조회 구조 자체를 바꾸는 쪽이라 결이 달라. 다만 두 접근은 배타적이지 않아서, 결국 양쪽 다 하는 방향으로 수렴할 가능성이 커.

커서는 IDE 통합이 강점이야. 다만 IDE에 붙어 있다는 건 IDE의 성능 한계도 같이 진다는 뜻이야. 스페이스X가 커서를 인수하면서 자원은 늘었지만, 그 자원이 어디로 갈지는 아직 지켜봐야 해.

구글은 제미나이 CLI와 안티그래비티 계열 도구로 붙고 있어. 긴 컨텍스트 자체는 제미나이의 오래된 강점이라, 클라이언트 성능만 받쳐 주면 경쟁력이 있어.

오픈소스 진영도 변수야. 코덱스 CLI 자체가 깃허브에 공개돼 있어서 이번 최적화가 어떻게 구현됐는지 코드로 확인할 수 있어. 좋은 아이디어는 빠르게 다른 도구로 퍼질 거야. 실제로 지난 몇 달 동안 에이전트 도구들 사이에서 기능이 옮겨 다니는 속도는 꽤 빨랐어. 한쪽이 계획 모드를 내놓으면 몇 주 안에 다른 쪽에 비슷한 게 생기는 식이야.

그리고 클라이언트 성능이 새 경쟁 축이 됐다는 사실 자체가 시장이 성숙했다는 신호이기도 해. 초기에는 "되느냐 안 되느냐"가 문제였고, 다음 단계는 "얼마나 똑똑하냐"였어. 지금은 "하루 종일 켜 놓고 써도 버티느냐"로 질문이 내려왔어. 제품이 도구가 아니라 작업 환경이 되면 이런 질문이 나와. 에디터 시장이 지나온 경로와 똑같아.

그래서 뭐가 달라지는데

개발자에게는 작업 방식이 바뀔 여지가 생겨. 지금까지 긴 세션을 피해 왔다면 그 습관을 다시 점검해 볼 만해. 다만 로딩이 빨라졌다고 컨텍스트 윈도우가 늘어난 건 아니야. 모델이 한 번에 볼 수 있는 양은 그대로고, 클라이언트가 기록을 다루는 방식이 개선된 거야. 둘을 헷갈리면 안 돼.

팀 리드에게는 도입 평가 항목이 하나 늘었어. 코딩 에이전트를 비교할 때 모델 벤치마크만 보지 말고, 실제 저장소 크기에서 세션을 며칠 굴려 보고 로딩 시간과 메모리를 재 보는 게 좋아. 이번 수치가 그 측정의 기준선을 만들어 줬어. 사내 표준 도구를 정하는 자리라면, 가장 큰 모노레포에서 300턴 이상 굴려 본 결과를 비교표에 넣어 두는 걸 권해.

도구를 만드는 사람에게는 방향이 분명해. 에이전트 UI에서 병목은 대부분 모델 호출이 아니라 상태 관리와 렌더링이야. 요청 수를 98% 줄일 여지가 있었다는 건, 대부분의 에이전트 클라이언트에 비슷한 여유가 남아 있다는 뜻이기도 해.

일반 사용자에게는 직접적인 영향이 적어. 다만 코딩 에이전트가 하루 종일 도는 게 당연해지는 흐름은 눈여겨볼 만해. 소프트웨어를 만드는 속도가 바뀌면 결국 쓰는 소프트웨어도 바뀌니까.

AI 도구를 파는 회사에게는 마케팅 문법이 바뀌는 신호야. 지금까지 발표문의 주인공은 항상 모델이었어. 벤치마크 점수 몇 점, 컨텍스트 몇 만 토큰 하는 식이었지. 그런데 이번에 관심을 끈 숫자는 27.6초와 1.7초야. 사용자가 실제로 체감하는 단위로 말했을 때 반응이 더 크다는 걸 보여줬어. 앞으로 이런 형태의 수치 공개가 늘어날 거야.

🥄 남은 궁금증 세 가지

— 이거 오픈AI 공식 발표야? 정식 발표문은 아니야. 코덱스를 이끄는 앤드류 앰브로시노가 공개한 내부 슬랙 스크린샷에서 나온 수치야. 다만 8월 초 체인지로그에 같은 방향의 기능(섹션·페이지네이션 기록)이 이미 들어가 있어서, 맥락은 공개 기록과 맞아떨어져.

— 741턴이 현실적인 조건이야? 극단적인 편이긴 해. 다만 성능 테스트는 원래 극단값으로 하는 거고, 요즘 에이전트 사용 패턴을 보면 수백 턴짜리 세션은 드물지 않아. 731MB가 아니라 231MB라는 용량이 오히려 현실감 있는 숫자야.

— 그래서 코덱스가 클로드 코드보다 나아진 거야? 그렇게 읽기는 일러. 이 수치는 코덱스의 이전 버전 대비 개선폭이지 경쟁 도구와의 비교가 아니야. 두 도구는 구조 자체가 달라서 같은 조건으로 재기도 쉽지 않고. 자기 저장소에서 직접 재 보는 게 제일 정확해. 도구를 고르는 기준은 여전히 모델 품질, 통합 범위, 그리고 팀의 작업 방식과 얼마나 맞느냐 쪽에 더 가까워.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.