본 발표는 DK Gate가 자신의 루비 프로파일러 PS2의 업데이트 소식을 전하며 시작됩니다. 그는 프로파일러 자체는 프로그램을 빠르게 만들지 않지만, 성능 저하의 원인을 파악하는 데 도움을 준다는 점을 강조합니다. 이어서 그는 벤치마크 기반 개발(Benchmark Driven Development, BDD)이라는 새로운 개발 방법론을 소개하고, 이를 통해 Sinatra와 유사한 웹 프레임워크인 Zinetra를 어떻게 100배 더 빠르게 만들었는지 상세히 설명합니다. BDD는 개발 초기 단계부터 성능을 측정하고 개선하는 것을 목표로 하며, 이는 단순히 버그를 찾는 디버거처럼 성능 문제를 사후적으로 해결하는 것이 아니라, 처음부터 빠른 코드를 작성하는 데 중점을 둡니다.
벤치마킹은 프로그램 성능을 측정하는 일반적인 기술이며, 루비에는 benchmark 및 benchmark-ips와 같은 라이브러리가 있습니다. BDD의 핵심 개념은 간단합니다. 코드를 작성하기 전에 벤치마크를 먼저 설계하고, 그 다음 코드를 작성하며, 지속적으로 성능을 개선하는 사이클을 반복하는 것입니다. 이는 테스트 주도 개발(TDD)과 유사하게, 실패하는 벤치마크를 작성하고 이를 통과시키며 리팩토링하는 과정으로 이루어집니다.
성능 최적화에 있어 흔히 병목 현상에 집중하라는 조언이 있지만, 실제로는 명확한 단일 병목이 존재하지 않고, 수많은 미묘한 성능 저하가 전체 성능에 큰 영향을 미칠 수 있습니다. “느리지 않음이 빠름을 의미하지는 않는다”는 원칙 아래, 작은 개선들이 모여 큰 성능 향상을 가져올 수 있습니다. 이를 위해 발표자는 Zinetra 개발 과정에서 모든 코드 변경 사항에 대해 벤치마크를 수행하고, 이전과 이후의 성능을 비교했다고 설명합니다.
효과적인 BDD를 위해 발표자는 맞춤형 벤치마킹 프레임워크를 개발했습니다. 이 프레임워크는 RSpec과 유사한 DSL을 제공하여 워크로드를 정의하고, 설정(setup) 부분은 측정하지 않으며, 시나리오(scenario) 부분만 벤치마크합니다. Zinetra의 경우, 현실적이고 대표적인 워크로드를 위해 1만 개의 무작위 요청으로 구성된 ‘small’ 데이터셋과 실제 Sinatra 앱에서 수집된 10만 개의 요청으로 구성된 ‘large’ 데이터셋을 활용했습니다. ‘small’ 데이터셋은 개발 중 빠른 실험에, ‘large’ 데이터셋은 더 정확한 결과 도출에 사용되었습니다.
벤치마킹만으로는 성능 변화의 원인을 파악하기 어렵기 때문에 프로파일링이 중요합니다. 발표자는 자신의 프로파일러 PS2에 두 리비전 간의 성능 차이를 시각화하는 ‘Differential Flame Graph’ 기능을 추가했습니다. 이 그래프는 개선된 부분은 파란색으로, 성능이 저하된 부분은 빨간색으로 표시하여 최적화 지점을 명확히 보여줍니다. 또한, 에디터 통합 기능을 통해 각 코드 라인에 소요된 시간을 고스트 텍스트로 표시하여 개발자가 핫스팟을 즉시 식별할 수 있도록 지원합니다.
Zinetra를 100배 빠르게 만든 구체적인 최적화 사례들도 소개됩니다.
* 라우팅: Sinatra에서 가장 큰 부분을 차지하는 라우팅 로직은 선형(linear) 방식과 트라이(trie) 기반 방식 중 등록된 라우트 수에 따라 자동으로 전환되도록 구현되었습니다. 10~20개 라우트까지는 선형 방식이 더 빠르다는 벤치마크 결과에 기반한 결정입니다.
* params API: params 메서드 호출이 비용이 많이 든다는 점을 파악하고, params를 인스턴스 변수로 직접 접근할 수 있도록 API를 변경했습니다. 이는 성능이 API 디자인에 영향을 미칠 수 있음을 보여주는 사례입니다.
* request 객체: request 객체를 Struct로 구현하여 최적화했습니다. 클래스, 데이터, 스트럭트 중 Struct가 가장 빨랐습니다. 이는 프로덕션 환경에 가까운 환경에서 실험하는 것이 중요함을 시사합니다.
* before/after 액션: 블록 호출 방식 중 instance_eval이 가장 빠르다는 벤치마크 결과를 바탕으로 이를 채택했습니다. 그러나 100배 목표 달성을 위해 define_method를 사용하여 메서드를 동적으로 정의하고 self.send로 호출하는 방식으로 개선했습니다. 이는 블록보다 메서드 호출이 빠르기 때문입니다.
* 기타 최적화: 해시 접근 감소, 객체 할당 감소 등 작은 부분에서의 최적화가 전체 성능에 기여했습니다.
발표자는 루비와 레일즈에서 CPU 시간이 매우 중요하며, 데이터베이스가 유일한 병목이라는 오해와 달리 루비 코드 최적화가 큰 영향을 미칠 수 있다고 강조합니다. 또한 벤치마킹 시 “가챠” (좋은 결과가 나올 때까지 반복 실행)를 피하고, 통계적 가설 검정을 사용하며, 벤치마킹 환경을 실제 프로덕션 환경에 가깝게 유지하는 것이 중요하다고 조언합니다. CI 환경에서의 벤치마킹은 불안정할 수 있으므로 로컬 환경에서의 지속적인 벤치마킹이 더 효과적이라고 설명합니다.
결론적으로, 고성능 애플리케이션 개발은 단순히 코드를 빠르게 만드는 것이 아니라, 애초에 코드가 느려지지 않도록 하는 데 있습니다. 벤치마크 기반 개발(BDD)은 개발 초기부터 지속적인 벤치마크와 프로파일링을 통해 작은 성능 저하 요인들을 제거하고, 궁극적으로 빠르고 효율적인 애플리케이션을 구축하는 데 필수적인 방법론입니다. 이러한 접근 방식을 통해 Zinetra는 Sinatra의 핵심 로직을 획기적으로 가속화할 수 있었습니다. 개발자는 항상 코드를 작성할 때 벤치마크를 실행하고, 커밋하기 전에 성능 문제를 발견해야 합니다.