Solargraph의 대규모 코드베이스 문제점
기존 Serena의 Ruby 지원에 사용되던 Solargraph는 역사 깊은 Ruby용 LSP였지만, 대규모 코드베이스 환경에서는 다음과 같은 문제점을 드러냈습니다.
-
느린 인덱스 생성: 정적 분석을 기반으로 하므로, 방대한 코드의 인덱스를 생성하는 데 많은 시간이 소요되었습니다.
-
동적 코드 및 DSL 분석 한계: 동적으로 생성되는 메서드나 Rails 프레임워크 특유의 DSL(예: ActiveRecord)을 정확하게 파악하지 못해 코드 자동 완성 기능의 정확도가 떨어졌습니다.
-
부정확한 심볼 검색: 위의 문제들로 인해 심볼 검색 기능이 원활하게 작동하지 않아 개발자가 코드 내에서 필요한 정의를 찾기 어려웠습니다.
이러한 문제들은 Serena를 도입하더라도 사용자 기대치에 미치지 못하는 개발 경험을 제공하는 원인이 되었습니다.
Ruby LSP로의 전환 결정 및 이점
근본적인 해결책으로 Serena에서 활용할 LSP를 Ruby LSP로 전환하는 방안을 검토했습니다. Shopify에서 개발한 Ruby LSP는 Solargraph와 비교했을 때 다음과 같은 주요 이점을 제공합니다.
-
온디맨드 분석: 코드베이스 전체를 한 번에 분석하는 대신, 필요한 부분만 즉각적으로 처리하여 거대한 프로젝트에서도 효율적인 성능을 보장합니다.
-
Rails/RSpec 애드온 지원: Rails DSL에 대한 깊은 이해를 바탕으로 동적 메서드 및 테스트 보조 기능을 자동 완성에 반영하여, Rails 개발 환경에 최적화된 지원을 제공합니다.
이러한 특징들은 엔터프라이즈급 대규모 Ruby 코드베이스에 Ruby LSP가 훨씬 더 적합한 솔루션임을 시사했습니다.
성공적인 전환 추진 과정
Ruby LSP로의 전환은 체계적인 단계를 거쳐 이루어졌습니다.
- PoC(Proof of Concept) 수행:
- Ruby LSP 전환의 실질적인 동작 여부를 검증하기 위해 Serena 프로젝트를 포크하여 최소한의 구현으로 PoC를 진행했습니다.
- 대규모 코드베이스에서도 심볼 검색이 빠르게 작동하는 등 기대했던 성능을 확인했습니다.
- 유지보수 담당자와의 협의:
- LSP 전환은 중대한 사양 변경이므로, GitHub Issue를 통해 유지보수 담당자에게 사전 협의를 요청했습니다.
- Solargraph의 문제점, Ruby LSP의 개선 효과, PoC를 통한 검증 결과를 상세히 설명했습니다.
- 유지보수 담당자는 긍정적인 반응을 보였으며, 하위 호환성을 위해 Solargraph 지원을 ‘Experimental’ 옵션으로 유지하는 것에 동의했습니다.
- PR(Pull Request) 생성 및 병합:
- PoC를 통해 이미 구현 방향이 명확했으므로, PR 작성은 신속하게 진행되었습니다.
- 기존 코드와의 차이를 최소화하고 Solargraph와의 하위 호환성을 유지하는 데 중점을 두었습니다.
- Issue 생성 후 1일, PR 생성 후 반나절 만에 PR이 병합되는 빠른 처리 속도를 보였습니다.