코드를 잘 짜는데, Codex는 왜 불편해졌을까?

한 줄 핵심

Codex의 모델 성능은 강하지만, 현재 제품은 작업 흐름과 개념 구조가 어색하게 분리돼 있어 기능을 더하기보다 먼저 기본 단위를 재설계해야 한다는 주장이다.

시간별 요약

1. 0:00
   모델은 강한데, 제품은 왜 불편할까? 모델 자체의 능력은 인상적이지만, 제품으로 묶였을 때는 사용 흐름이 매끄럽지 않아 불편함이 드러난다. 성능이 좋다고 해서 제품 경험까지 자동으로 좋아지지는 않는다.
2. 0:12
   우선순위 목록과 최근 기록의 차이 우선순위 화면은 처리해야 할 작업 목록이어야 하지만, 실제로는 최근에 작업한 대화의 타임라인처럼 동작한다. 사용자가 지금 해야 할 일보다 과거 작업 내역이 앞에 드러나면서 목적과 형태가 어긋난다.
3. 0:39
   테스트로 검증하기 어려운 제품 판단 모델은 테스트 통과처럼 명확한 목표에는 강하지만, 제품 경험이나 UI처럼 인간의 취향과 판단이 필요한 문제에는 약하다. 검증 함수로 깔끔하게 표현할 수 없는 영역은 아직 모델이 안정적으로 최적화하기 어렵다.
4. 1:35
   ChatGPT와 Codex를 나누는 방식 코딩용과 일반 대화를 별도 제품으로 나누기보다, 하나의 기반 위에서 입력에 따라 동작만 달라지는 형태가 더 자연스럽다. 현재처럼 ChatGPT와 Codex를 따로 두는 구조는 사용자가 왜 나뉘는지 이해하기 어렵게 만든다.
5. 2:22
   Spaces의 장점과 어색한 연결 Spaces는 반복 작업을 템플릿과 프롬프트로 묶어 관리하기에 유용해서 실제 업무 흐름에 잘 맞는다. 다만 thread와 space가 서로 단단히 연결되지 못하고 화면 이동과 포커스 전환이 거슬려, 좋은 기능이 있어도 전체 결합감이 약하다.
6. 4:25
   기능을 더하기 전에 정할 것 기능을 추가하는 일은 쉬워졌지만, 무엇을 넣고 무엇을 거를지 결정하는 제품 원칙은 더 중요해졌다. 강한 비전과 명확한 거절 기준이 없으면 기능은 늘어나도 제품 품질은 쉽게 흐트러진다.
7. 5:08
   대화를 공통 기반으로 만든다면 먼저 불필요한 기능을 덜어내고, Coda thread를 모든 인터페이스의 공통 빌딩 블록으로 삼는 편이 낫다. 그 위에 Spaces를 별도 원자로 정교하게 다듬으면, thread와 space가 느슨하게 연결된 구조보다 훨씬 일관된 제품이 된다.
8. 6:33
   기능보다 먼저, 제품의 기반 새 기능을 얹기보다 먼저 기본 구조를 고쳐야 하며, 지금의 foundation은 아직 충분히 안정적이지 않다. 핵심 단위를 정리하고 그 위에서 확장해야만 제품 전체의 일관성과 사용성이 살아난다.

실무 인사이트

• 코딩 에이전트 제품은 모델 성능보다 정보 구조와 화면 전환 같은 제품 설계가 체감 품질을 더 크게 좌우한다.
• 명확한 정답이 없는 경험 설계는 테스트 자동화보다 강한 제품 원칙과 편집 기준으로 관리해야 한다.
• 새 기능을 늘리기 전에 thread 같은 공통 원자를 먼저 고정하면, 이후 확장과 정리가 훨씬 쉬워진다.