왜 Codex 한도가 부족한지 이제야 알았다
처음엔 이해를 못했다. Claude를 쓸 때도 그렇고 GPT를 쓸 때도 그렇고 나는 한도를 그렇게 많이 쓰는 편이 아니었다. 정확히 말하면 비싼 Pro 플랜을 써본 적도 없다. 그냥 흔히 말하는 20달러짜리 플랜을 쓰는 유저였다. 그 안에서도 5시간 제한이 부족하다고 느낀 적은 거의 없었다. 작업량이 많은 날에는 한도를 꽉 채운 적도 있긴 했다. 그런데 그쯤 되면 보통 퇴근시간이었다. 그래서 Codex Pro 한도가 부족하다거나, 2배는 더 줘야 한다는 이야기를 봐도 솔직히 잘 이해가 안 됐다. 도대체 뭘 하길래?<br><br>예전 코드를 다시 꺼내기 시작했다. AI를 쓰기 시작하면서 예전에 만들었던 OSS 라이브러리들을 다시 들춰보게 됐다. 당시에는 시간이나 실력 문제로 적당히 우회했던 부분들. “언젠가 다시 손봐야지.” 하고 넘어갔던 코드들. 그걸 하나씩 AI에게 보여주기 시작했다. 기능 추가가 아니라 구조를 물어보기 시작했다. 처음에는 나도 흔히 하는 방식으로 사용했다. 여기에 기능 하나 추가해줘. 버그 수정해줘. 테스트 코드 작성해줘. 그런데 어느 순간 질문 자체가 달라졌다. 이 라이브러리가 다른 UI 프레임워크와도 호환되게 만들 수 있을까? 지금 구조는 유지하면서 코어 부분만 분리하면 어떨까? 당시에는 이렇게 만들었는데 지금 다시 만든다면 어떤 방향이 좋을까? 그때부터 토큰이 녹기 시작했다.<br><br>이건 단순히 Context 관리를 못해서 생긴 문제가 아니었다. 사용 패턴 자체가 달랐다. 기능 하나를 추가하는 수준이 아니라 시스템 구조를 다시 뜯어보는 대화를 하기 시작하면 대화 길이도 길어진다. 참고 코드도 많아지고, 실험도 계속하게 된다. 기획자와 개발자가 보는 알림 기능은 조금 다르다. 극단적으로 말하면 이런 차이였다. 유저에게 알림 기능을 추가해야 하는 일이 생겼다고 해보자. 기획자 시점에서는 대략 이렇게 말할 수 있다. 알림 기능 추가해줘. 알림 수신 동의도 받을 수 있게 해줘. 필요하면 설정 화면에서도 켜고 끌 수 있게 해줘. 그런데 개발자 시점으로 들어오면 갑자기 이야기가 길어진다. 알림 API를 어떻게 설계할지 이벤트 모델은 어떻게 정의할지 모바일 푸시는 어떤 라이브러리로 붙일지 데스크탑 알림은 별도로 처리해야 하는지 실패했을 때 재시도 전략은 어떻게 가져갈지 여러 플랫폼에서 공통으로 쓸 추상화 계층을 둘지 결국 같은 알림 기능인데, 머릿속에서 펼쳐지는 범위가 다르다. 기획자는 유저가 보게 될 기능을 말하고, 개발자는 그 기능이 굴러가기 위해 필요한 구조까지 같이 떠올린다. AI를 쓸 때도 비슷했다. 처음에는 단순히 기능 하나를 추가해달라고 말했는데, 어느 순간부터는 그 기능 뒤에 깔린 구조를 같이 묻고 있었다. 이제야 왜 한도가 부족한지 알겠다. 예전에는 이런 생각을 했다. Claude, Codex 한도가 왜 부족하지? 도대체 뭘 하길래? 그런데 오래된 프로젝트를 다시 뜯어보고, 당시에 못 했던 설계를 다시 고민하고, 구조 자체를 AI와 같이 리팩토링하기 시작하니 조금 알 것 같았다. 5시간 제한을 처음으로 기다리게 됐다. 이건 AI가 Context를 못 관리해서 생긴 문제가 아니었다. 오히려 반대에 가까웠다. Codex가 내가 어떤 식으로 작업하는 사람인지, 어떤 패턴으로 코드를 바라보는지 조금씩 이해해주는 느낌이 있었다. 그러니까 나도 더 깊게 던지게 됐다. 기능 하나 추가해달라는 말에서 끝나는 게 아니라, 예전에 만들었던 구조와 당시의 의도까지 같이 꺼내놓게 됐다. 그러다 보니 대화는 길어졌고, 한도는 생각보다 빨리 사라졌다.