AI 요약
2026년 6월 4일, IT 전문 블로그 arnorhs.dev에 게재된 글에서 저자는 개발 프로젝트에서 구현하지 않고 남겨둔 '나중에 하기(Maybe later)' 백로그가 사실 가장 가치 있는 결정이었다는 역설적인 통찰을 제시합니다. 과거 GCP 대신 AWS로의 인프라 이전이나 CRM 위에서의 작업 관리 도구 구축 등 당시에는 흥미로웠던 수많은 아이디어들이 우선순위에서 밀려났고, 4년이 지난 지금 시점에서 보면 제품의 피벗 등으로 인해 결국 만들지 않는 편이 백업이나 유지보수 비용을 아끼는 현명한 선택이었음이 증명되었습니다. 저자는 개발하지 않는 것이 오히려 팀의 속도를 높이고 핵심에 집중하게 만드는 강력한 전략이라고 설명합니다. 그러나 최근 LLM의 급격한 발전으로 인해 개발자들이 토큰을 무제한 사용하는 '토큰맥싱(Tokenmaxxing)' 현상이 나타나면서, 이전 같았으면 만들지 않았을 무의미한 백로그 기능들까지 무분별하게 빌드되어 코드베이스를 망치고 있다고 우려합니다. 이러한 흐름은 인간 개발자가 코드를 해석할 수 없고 오직 AI만 읽을 수 있는 비대화된 레거시 시스템을 초래할 것이라는 경고를 보냅니다.
핵심 인사이트
- 2026년 6월 4일 발표된 개발 통찰: 개발 저장소(Repo)에서 가장 가치 있는 코드는 '작성하지 않은 코드'이며, 개발을 유보하는 결정 자체가 강력한 개발 전략입니다.
- 4년의 유예 기간이 입증한 효과: 당시에 열광했던 수많은 백로그 기능들은 4년 뒤 시점에서 되돌아봤을 때 제품의 피벗이나 환경 변화로 인해 불필요한 쓰레기(Legacy Cruft)가 되었을 확률이 매우 높습니다.
- 토큰맥싱(Tokenmaxxing)의 함정: 인공지능(AI)의 보급으로 코드 작성이 쉬워지자, 개발자들이 우선순위를 신중하게 고르는 대신 무분별하게 AI 토큰을 소비하며 불필요한 백로그 아이디어까지 모두 제품에 구현해버리는 부작용이 발생하고 있습니다.
주요 디테일
- 백로그의 현실적 예시: GCP에서 AWS로 서비스 배포 환경 바꾸기, CRM 위에 작업 관리 기능 개발하기, 인프라 내 이미지 처리 아키텍처 재구축 등 우선순위가 낮아 보류된 대표적인 사례들을 나열했습니다.
- 가독성이 떨어지는 LLM 코드 패턴: 현재도 LLM이 작성한 코드는 가독성이 떨어지는 경우가 많으며, 동일한 기능이 15개의 서로 다른 위치에 중복 정의되거나 중첩된 if문 안에 4개의 서로 다른 스키마 검증이 들어가는 부작용이 목격됩니다.
- 제품 우선순위의 보존: 무언가를 빌드하지 않음으로써 개발팀은 매 순간 가장 중요하고 가치 있는 단 하나의 기능 개발에 온전히 집중할 수 있는 추진력을 얻습니다.
- 인간 배제적 코드의 탄생: 저자는 무분별한 개발 결과물들이 가득 찬 코드베이스가 결국 인간이 도저히 읽고 파악할 수 없는 지저분한 상태가 될 것이며, 이로 인해 코드와의 인터페이스를 오직 AI에게만 의존해야 하는 끔찍한 미래가 올 수 있다고 경고합니다.
향후 전망
- 코드베이스 비대화 현상 가속: 수많은 개발 환경에서 LLM을 이용해 코드 재작성(A에서 B로) 및 불필요한 기능 추가를 과도하게 진행하여 전 세계 소프트웨어의 코드 규모가 급격히 부풀어 오를 것입니다.
- 개발 도구 환경의 재편: 인간의 가독성 한계를 초과한 코드베이스를 관리하기 위해, 인간 개발자 대신 AI끼리 코드를 수정하고 배포하는 AI 중심의 인터페이스가 개발 패러다임을 지배할 가능성이 큽니다.
