1. 전통적인 Gem 활용의 명암과 기술 부채
과거 루비 생태계에서 ‘바퀴를 재발명하지 마라’는 원칙은 절대적이었습니다. 직접 기능을 구현하는 데 4시간이 걸린다면, Gem을 설치하는 데는 10분이면 충분했기 때문입니다. 하지만 이러한 시간적 이득 뒤에는 다음과 같은 치명적인 기술 부채가 숨어 있었습니다.
- 코드 비대화(Bloat): 단 하나의 메서드만 사용하기 위해 수십 개의 불필요한 기능이 포함된 대규모 라이브러리를 프로젝트에 포함해야 했습니다.
- 의존성 지옥(Dependency Hell): 서로 다른 Gem들이 요구하는 라이브러리 버전이 충돌하면서
bundle update한 번에 전체 시스템이 마비되는 위험을 감수해야 했습니다. - 유지보수의 외주화: 외부 관리자가 프로젝트를 방치하거나 예기치 않은 변경을 가할 경우, 개발자는 이에 수동적으로 대응할 수밖에 없었습니다.
2. AI가 가져온 패러다임의 전환: 맞춤형 코드의 시대
LLM의 등장은 코드를 작성하는 비용(Friction)을 극적으로 낮추었습니다. 이제 개발자는 루비젬스(RubyGems)를 검색하는 대신 AI에게 구체적인 요구사항을 전달합니다. 이를 통해 얻는 결과물은 다음과 같은 독보적인 장점을 가집니다.
- 최적화된 구현(Bespoke): 현재 프로젝트의 맥락에 정확히 일치하며 불필요한 기능이 전혀 없는 순수한 코드를 얻을 수 있습니다.
- 외부 의존성 제로(Zero-Dependency): 루비 표준 라이브러리(Standard Library)만을 활용하여 작성되므로 시스템이 가볍고 안정적입니다.
- 완전한 소유권(Ownership): 내가 직접 검토하고 커밋한 코드이므로, 문제가 발생했을 때 외부 관리자의 패치를 기다릴 필요 없이 즉각적인 수정이 가능합니다.
3. Gem의 계층 분화: 무엇을 남기고 무엇을 버릴 것인가
저자는 모든 Gem을 부정하는 것이 아니라, 사용 기준을 재정립해야 한다고 강조합니다.
- 유지해야 할 핵심 Gem:
Devise(인증),Sidekiq(백그라운드 처리),Rails(프레임워크)와 같이 보안이 극도로 중요하거나 복잡도가 높은 분야는 여전히 커뮤니티의 집단지성이 담긴 솔루션을 사용해야 합니다. 암호화 로직이나 복잡한 프로토콜을 AI에게 맡기는 것은 위험할 수 있기 때문입니다. - 제거해야 할 중간 계층 Gem: 단순한 API 래퍼, 문자열 포맷터, 간단한 논리 유틸리티 등은 이제 Gem으로 관리할 실익이 없습니다. 이러한 ‘중간 계층’ 라이브러리들은 이제 자산이 아니라 잠재적인 보안 취약점(Supply Chain Attack)이자 관리 비용일 뿐입니다.
4. 조립가에서 설계자로의 진화
이제 개발자의 역량은 남이 만든 블랙박스를 얼마나 잘 연결하느냐가 아니라, AI를 도구로 활용해 시스템의 세부 로직을 얼마나 정교하게 설계하고 통제하느냐에 달려 있습니다. 50줄 내외의 클래스를 직접 구현하고 테스트하는 것이 Gem의 문서를 읽고 초기화 설정을 하는 것보다 빨라진 시대입니다. 다음번에 새로운 기능을 추가할 때, 무의식적으로 Gemfile에 한 줄을 추가하기 전에 스스로 질문해 보십시오. “이 의존성과 결혼할 준비가 되었는가, 아니면 2분 만에 내가 직접 만들 것인가?”