Claude의 50가지 기능이 무너진 이유.

개발자 Shiv Bhosale는 7개월에 걸친 야심찬 프로젝트에 착수하여 GPU 인식 Kubernetes 대시보드인 K10s를 전적으로 Claude로 구축했습니다. 이 집중적인 "vibe coding" 노력은 50가지의 개별 기능을 탄생시켰으며, 각 기능은 단일 개발 세션 내에서 깔끔하게 구현되는 것처럼 보였습니다. 개별 구성 요소의 빠른 생성은 엄청난 속도로 복잡한 애플리케이션이 구현될 수 있는 미래를 암시하며, 도취적인 진전감을 불러일으켰습니다.

이러한 접근 방식은 개발자들이 놀라운 용이함으로 새로운 기능을 프로토타입하고 구현할 수 있다고 느끼게 하는 10x velocity의 매혹적인 매력을 길러주었습니다. Claude의 효율적인 세션 기반 출력은 각 기능이 독립적인 성공이며 최소한의 통합 노력이 필요하다는 인식을 강화했습니다. 이는 순수한 생성 속도로 인해 근본적인 문제를 가리고, 아키텍처적 건전성에 대한 잘못된 인식을 만들었습니다.

그러나 Bhosale이 마침내 50가지 기능을 응집력 있는 애플리케이션으로 결합하려고 시도했을 때 환상은 비극적으로 산산조각 났습니다. 전체 시스템이 무너져 근본적인 아키텍처 불일치를 드러냈습니다. 뷰를 전환하면 오래된 데이터가 표시되었고, 한때 채워져 있던 테이블은 설명할 수 없이 비어 있었으며, 중요한 키 기능은 활성 화면에 따라 세 가지 다른 예측 불가능한 작업을 수행했습니다. AI의 아키텍처적 통찰력 부족으로 인한 이 완전한 붕괴는 Bhosale이 7개월간의 작업을 포기하고 전체 코드베이스를 보관하며 프로젝트를 처음부터 다시 시작하도록 강요했습니다.

AI의 근본적인 결함은 빠르게 드러났습니다. AI는 응집력 있는 아키텍처가 아닌 고립된 기능을 생성하는 데 탁월합니다. 각 프롬프트는 Shiv Bhosale의 K10s 프로젝트 내에서 상태를 공유하는 다른 49가지 기능을 전혀 알지 못하는 고립된 지시처럼 작동합니다. Claude는 개별 구성 요소를 제공했지만, 결정적으로 이 조각들이 통합 시스템으로 어떻게 상호 작용해야 하는지에 대한 이해가 부족했습니다.

이러한 파편화된 접근 방식은 필연적으로 취약하고 유지보수 불가능한 코드베이스로 이어졌습니다. Bhosale이 모든 것을 함께 사용하려고 했을 때, 전체 구조가 무너졌습니다. 뷰를 전환하면 오래된 데이터가 표시되었고, 한때 채워져 있던 테이블은 비어 있었으며, 단일 키가 화면에 따라 세 가지 다른 작업을 수행했습니다. 개별 기능들은 독립적으로는 깔끔했지만, 함께 작동하지 않았습니다.

Bhosale의 해결책은 명확했습니다. 개발자는 아키텍트의 역할을 되찾아야 합니다. 그는 시스템 아키텍처를 수동으로 설계하고, 이를 `Claude MD` 파일에 철저히 문서화했습니다. 그 후에야 그는 미리 정의된, 손으로 작성된 구조적 청사진 내에서 특정 기능을 구현하는 '지루한 작업'에 Claude를 활용했습니다. 이러한 변화는 AI를 자율적인 빌더에서 강력하고 안내받는 구현 도구로 탈바꿈시켰습니다.

AI의 기본 접근 방식은 모든 로직을 단일하고 거대한 데이터 구조에 넣어 작동하는 기능으로 가는 최단 경로를 찾는 god object 안티 패턴입니다. Shiv Bhosale의 K10s 코드베이스는 이를 극명하게 보여주는데, 무려 1,690줄에 달하는 단일 구조체를 특징으로 합니다. 이 모놀리식 객체는 500줄짜리 `Update()` 메서드와 110개의 switch case를 포함하고 있었으며, 이는 관리 불가능한 범위의 명확한 증거입니다.

이러한 모놀리식 디자인은 유지보수를 불가능하게 만들고, 서로 다른 기능들 간에 강한 결합을 조장합니다. 한 영역의 작은 변화가 취약한 시스템 전체에 연쇄적인 오류를 일으킬 위험이 있습니다. Bhosale이 경험한 오래된 데이터, 빈 테이블, 뷰 전반에 걸친 일관성 없는 핵심 기능은 이러한 아키텍처 결함에서 직접 비롯되었으며, 애플리케이션을 본질적으로 불안정하게 만들었습니다.

이를 바로잡으려면 LLM에 명시적인 지침을 내려야 합니다. 개발자는 Claude가 관심사를 분리하여 로직을 별개의 뷰, 컴포넌트 및 데이터 구조로 나누도록 강제해야 합니다. 이러한 아키텍처 지침은 AI가 기본적으로 모놀리식 구조를 사용하는 것을 적극적으로 방지하여, 더 모듈화되고 유지보수하기 쉬운 코드베이스를 조성합니다. Bhosale의 프로젝트와 그 진화에 대한 더 자세한 통찰력을 얻으려면 K10s GitHub 저장소를 살펴보세요: shvbsle (Shiv Bhosale) / k10s - GitHub.

AI가 생성한 코드의 인지된 '자유로움'은 위험할 정도로 기만적이며, 만연한 범위 확장(scope creep)으로 직접 이어집니다. Claude가 마치 50개의 개별 세션에서 50개의 기능을 마법처럼 만들어낼 수 있는 것처럼 보일 때, 계속해서 더 많은 것을 추가하려는 충동은 저항할 수 없게 됩니다. 이러한 빠른 속도는 처음에는 짜릿하지만, 쌓여가는 기술 부채를 가리고 개발자들을 끊임없이 확장되는 프로젝트로 유인합니다.

새로운 기능은 아무리 사소하게 만들어졌더라도 상당한 숨겨진 비용을 초래합니다: - 장기적인 지원 - 포괄적인 문서화 - 예상치 못한 엣지 케이스 처리 - 사용자 인지 부하 증가 50개의 축소된 기능을 가진 Bhosale의 K10s는 이러한 함정을 극명하게 보여줍니다. 속도라는 속임수는 아키텍처 없이 무분별하게 확장된 것의 진정한 부담을 가렸습니다.

이러한 교활한 확장을 막기 위해 개발자는 명확한 경계를 설정해야 합니다. Shiv Bhosale은 자신이 *누구를 위해* 만들지 않는지를 명시적으로 정의하여 부정적인 제약을 설정했습니다. 그런 다음 그는 이러한 명시적인 범위 제한을 `Claude MD` 컨텍스트 파일 내에 직접 코드로 작성하여, AI가 기존 기능을 재구축하거나 프로젝트의 범위를 과도하게 확장하는 것을 방지했습니다. 이러한 사전 예방적 제약은 AI의 속도가 관리할 수 없는 기능 확장을 만드는 대신, 정확하게 정의된 목적에 부합하도록 보장합니다.

AI를 이용한 'vibe coding'이란 무엇인가요?

이는 프로그래머가 Claude와 같은 LLM을 사용하여 높은 수준의 프롬프트 또는 'vibe'를 기반으로 기능을 생성하는 빠른 개발 방식이며, 종종 엄격하고 미리 정의된 아키텍처 계획 없이 진행됩니다.

AI는 왜 'god object'를 생성하나요?

AI는 기능적 솔루션에 도달하는 가장 짧은 경로를 택합니다. 모든 상태와 로직을 단일 객체에 집어넣는 것은 종종 새로운 기능에 대한 프롬프트를 충족시키는 가장 간단한 방법이며, 장기적인 유지보수성은 무시됩니다.

개발자는 AI 코딩 함정을 어떻게 피할 수 있나요?

핵심 아키텍처를 수동으로 정의하고, 명확한 범위 경계를 설정하며, AI를 자율적인 아키텍트가 아닌 잘 정의된 작은 작업을 구현하는 도구로 사용함으로써 피할 수 있습니다.

Shiv Bhosale은 누구이며 K10s는 무엇인가요?

Shiv Bhosale은 이 경험을 공유한 개발자입니다. K10s는 그의 프로젝트로, GPU를 인식하는 Kubernetes 대시보드이며, 초기 AI 생성 버전이 아키텍처 문제로 실패한 후 성공적으로 재구축했습니다.