AI가 코드를 쓰는 속도는 이제 논쟁거리가 아니다. 진짜 질문은 따로 있다. "코드가 무한히 나온다면, 다음 병목은 어디인가?"
dev.to에 실린 'Pragmatism in an Age of Infinite Code'는 이 질문에 정면으로 답한다. 핵심 주장은 단순하다. AI는 코드 생성이라는 병목을 해소했지만, 병목 자체를 없애지는 못했다. 병목은 사라지는 게 아니라 이동한다. 코드를 10배 빠르게 쓰면 병목은 코드 리뷰로 옮겨가고, LLM으로 리뷰를 자동화하면 병목은 프로덕트 정렬과 배포 인프라로 이동한다. 제약은 항상 다음 단계에 살아남는다.
이 구조를 실전에서 체감한 사례가 있다. 한 개발자는 이미지·PDF 압축 SaaS를 두 달 가까이 Claude Code로 구축했다. 코드는 빠르게 완성됐다. 문제는 다른 곳에 있었다. 대형 플레이어가 지배하는 레드오션 키워드, 눈에 띄지 않는 포지셔닝, 그리고 트래픽 제로. 결국 그는 제품을 피벗했다. 디자인 시스템과 일부 컴포넌트만 살리고, 동일한 Next.js + Tailwind 스택 위에서 'SaaS 대체 도구 디렉토리'로 방향을 틀었다. "Notion alternatives", "free Figma alternative" 같은 키워드는 경쟁 강도는 낮고 검색 의도는 명확했다. AI가 코드를 짜는 건 주말 하나로 끝났다. 진짜 시간이 걸린 건 무엇을 빌드할 것인가를 판단하는 일이었다.
두 사례가 공유하는 테제는 명확하다. AI 코드 생성은 실행 비용을 거의 0에 수렴시켰다. 그 결과, 과거엔 실행 비용 때문에 묻혔던 더 근본적인 질문들이 수면 위로 올라왔다. 어떤 기능이 실제 사용자 문제를 해결하는가? 어떤 아키텍처가 팀의 의도를 유지하는가? 어떤 방향이 시장에서 살아남는가? 이 질문들은 AI가 대신 답해줄 수 없다. Claude Code가 데이터 구조를 설계해주지는 않는다. 어떤 툴을 디렉토리에 넣을지 결정해주지도 않는다. 제품이 Wikipedia처럼 느껴져야 할지 SaaS처럼 느껴져야 할지도 마찬가지다.
여기서 "다음 모델을 기다리면 해결될 것"이라는 유혹이 끼어든다. 'Pragmatism in an Age of Infinite Code'는 이를 S-커브 함정이라 부른다. 1~2년 전에는 이 논리가 유효했다. 어차피 다음 모델이 나오면 지금 최적화한 워크플로우가 쓸모없어지니, 기다리는 쪽이 합리적이었다. 하지만 지금은 다르다. 인간 중심의 병목—이해관계자 합의, 크로스팀 조율, 아키텍처 응집성—은 모델 인텔리전스가 아무리 올라가도 단기간에 해소될 성질이 아니다. ASI가 오기 전까지, 스테이크홀더 회의의 정치적 역학을 읽거나 사용자의 실제 불편을 공감하는 건 여전히 사람의 몫이다.
그렇다면 지금 실무에서 해야 할 설계는 무엇인가? 핵심 키워드는 에르고노믹스(ergonomics)다. 완전한 자율 주행이 아니라, 인간이 더 높은 추상 레벨에서 개입할 수 있는 루프를 설계하는 것. 에이전트가 무엇을 시도하는지 한눈에 파악하고, 방향이 틀어졌을 때 단 한 번의 개입으로 궤도를 수정하고, 그 결과가 전체 아키텍처에 응집성 있게 합류하는 구조. 이게 지금 당장 만들 수 있는, 그리고 만들어야 하는 워크플로우다.
프론트엔드 관점에서 이 논리는 더 구체적으로 작동한다. AI가 컴포넌트를 순식간에 생성한다면, 개발자의 시간은 어디로 가야 하는가. 컴포넌트 품질 판단, 디자인 시스템 응집성 검토, 사용자 여정 맥락 판단—이 모든 것은 AI가 건드리지 못하는 영역이다. 실행 비용이 0에 가까워질수록, 판단 비용의 밀도는 오히려 높아진다.
퍽이 있던 곳이 아니라 퍽이 향하는 곳으로 스케이트를 타라는 그레츠키의 말처럼, AI 도구의 활용 방향도 마찬가지다. 지금 이 순간의 병목을 직시하고, 지금 있는 도구로 그 마찰을 줄이는 것. 다음 모델이 전부 해결해 줄 것이라는 기대는 흥미로운 SF지만, 지금 출시해야 하는 프로덕트 앞에서는 현실적인 전략이 아니다. AI가 코드를 무한히 쏟아내는 시대일수록, 개발자의 진짜 역할은 코드를 생성하는 것이 아니라 무엇을 만들지 판단하고, 만들어진 것을 응집성 있게 조율하는 것으로 이동하고 있다.