Figma를 빠르게 유지하기

Figma는 2018년 한 대의 MacBook으로 운영하던 성능 테스트 체계가 제품과 조직의 성장으로 한계에 이르자 전면적인 개편을 추진했습니다. 플러그인, FigJam, Dev Mode 등 기능이 늘고 코드베이스가 복잡해지면서 기존의 소수 대형 파일 테스트만으로는 성능 회귀를 조기에 발견하기 어려워졌습니다. 이에 Figma는 모든 코드 변경을 대상으로 실제 하드웨어에서 병렬 성능 테스트를 실행하고, 10분 이내에 결과를 제공하는 확장 가능한 시스템을 목표로 삼았습니다.

한 대의 MacBook으로 시작한 성능 테스트

• 2018년 Figma는 한 대의 MacBook에서 동일한 테스트 시나리오를 반복 실행했습니다.
• 테스트 결과와 실행 시간은 약 한 시간 간격으로 공유 대시보드에 기록됐습니다.
• 당시에는 소수의 대형 디자인 파일만으로도 주요 성능 문제를 확인할 수 있었습니다.
• 문서 렌더러 구조를 개선하고 WebAssembly 관련 버그를 해결하면서 Figma의 성능을 약 3배 향상시킨 사례도 있었습니다.
• 작은 조직에서 단일 컴퓨터로 테스트하는 방식은 단순하고 비용이 낮다는 장점이 있었습니다.

제품과 조직의 성장으로 드러난 한계

• 5년 동안 코드베이스가 커지고 다음과 같은 기능이 추가됐습니다.
  • 플러그인
  • Community 기능
  • FigJam
  • Dev Mode
  • 수많은 제품 업데이트
• 기존에 사용하던 몇 개의 대형 디자인 파일은 늘어나는 기능과 예외 상황을 충분히 대표하지 못했습니다.
• 기능별로 세밀한 성능 테스트를 작성하는 것이 이상적이었지만, 엔지니어와 매니저가 400명 이상으로 늘면서 모든 변경 사항을 한 사람이 추적하기 어려워졌습니다.
• 성능 테스트 대상과 코드 변경이 많아지면서 단일 노트북만으로는 출시 전 성능 회귀를 안정적으로 발견할 수 없었습니다.
• 원격 근무가 시작된 뒤에도 사무실에 있던 MacBook은 계속 테스트를 실행했고, 결국 2020년 10월 과열됐습니다.
• 다른 노트북으로 같은 환경을 재현하려 했지만 테스트가 원활하게 실행되지 않아 새로운 시스템이 필요해졌습니다.

세밀한 성능 테스트의 필요성

• **세밀한 성능 테스트(granular performance test)**는 특정 기능이나 사용 패턴을 대규모 조건에서 검증하는 테스트입니다.
• 예를 들어 Figma는 다음과 같은 상황을 시뮬레이션할 수 있습니다.
  • 100명의 협업 편집자가 동시에 파일을 편집
  • 여러 사용자가 레이어를 이동
  • 동시에 새로운 텍스트 입력
  • 사용자가 빠르게 화면을 패닝
• 이런 테스트는 특정 기능의 성능 영향을 정확하게 파악하는 데 유용합니다.
• 하지만 기능 수와 엣지 케이스가 계속 증가하면 모든 기능을 수동으로 테스트하는 방식은 조직 규모에 맞게 확장되지 않습니다.

새 성능 테스트 시스템의 목표

• Figma는 시스템을 처음부터 다시 설계하며 세 가지 문제를 해결하려 했습니다.
  • 성능에 영향을 줄 수 있는 기능의 증가
  • 테스트 하드웨어 운영의 어려움
  • 신뢰할 수 있는 성능 지표의 부족
• 메인 모노레포에 제출되는 모든 코드 변경을 테스트해 성능 회귀를 개발 초기에 발견하는 것을 목표로 삼았습니다.
• 사용자가 버그를 보고한 뒤 대응하는 대신, 기능이 배포되기 전에 성능 문제를 예방하려 했습니다.
• Figma 사용자는 하루에도 여러 시간 제품을 사용하기 때문에 작은 지연도 작업 흐름에 큰 영향을 줄 수 있다고 판단했습니다.
• 성능을 기능 개발 이후의 사후 대응이 아니라 개발 과정에 포함되는 품질 기준으로 다루려 했습니다.

병렬 실행과 10분 성능 가드레일

• 테스트 대기 시간을 줄이기 위해 여러 테스트를 동시에 실행하는 **병렬 실행(parallel runs)**을 핵심 전략으로 채택했습니다.
• 기존 CI에서도 클라우드 러너를 이용한 병렬 테스트를 이미 활용하고 있었습니다.
• 성능 테스트 역시 수십 개의 스트레스 시나리오를 동시에 실행해야 목표 시간을 달성할 수 있었습니다.
• 성능 가드레일 검사는 개발 흐름을 방해하지 않도록 10분 이내에 완료되어야 한다는 기준을 세웠습니다.
• 모든 풀 리퀘스트를 실제 하드웨어에서 테스트하려면 피크 시점에 동일한 성능의 테스트 러너 약 100대가 필요했습니다.
• 따라서 새로운 체계는 단순히 테스트 수를 늘리는 것이 아니라, 하드웨어를 효율적으로 운영하고 결과를 빠르게 수집하는 구조여야 했습니다.

실용적인 결론

성능 테스트는 제품과 조직이 작을 때는 단일 장비와 소수의 대표 시나리오만으로도 충분할 수 있지만, 기능·코드·팀 규모가 커지면 자동화와 병렬화가 필수입니다. 특히 사용자 경험에 직접 영향을 주는 성능은 출시 후 모니터링하는 것보다 모든 코드 변경 단계에서 회귀를 차단하는 가드레일로 운영하는 편이 효과적입니다.