테스트 커버리지를 2%에서 수십%로
이 글은 Pragmatic Engineer의 뉴스레터 및 팟캐스트 에피소드 Building Reddit’s iOS and Android apps at scale를 바탕으로 작성하였습니다.
2021년, Reddit의 테스트 커버리지는 불과 2% 수준이었습니다. 그나마 있던 테스트는 불안정했고, 빌드는 느렸고, 실서비스에서 장애가 나면 원인을 찾기 어려웠습니다. 이 모든 문제는 하나로 연결됩니다.
“개발 속도보다, 회복력(resilience)이 없는 것이 더 큰 리스크였다.”
그래서 플랫폼팀은 이렇게 움직였습니다.
• 과거 장애가 발생했던 흐름을 기반으로 테스트 우선순위 선정
• 테스트 커버리지를 점진적으로 높이는 Ratchet 도입
• 실제 테스트를 생성하는 외주 파트너와 함께 일함
• 인프라팀과 협업하여 테스트 자동화 기반 마련
저는 이 접근이 정말 인상 깊었습니다. 특히 “테스트는 회복력을 위한 투자”라는 관점. 테스트는 단순히 안정성을 높이기 위한 게 아니라, “문제가 터져도 빠르게 파악하고 대응할 수 있는 시스템”을 만드는 과정이라는 걸 실감하게 해 줍니다.
Reddit의 플랫폼팀이 가장 자주 반복한 메시지는 이것이었습니다.
“우리는 개발자들을 위하는 ‘서비스 팀’이다.”
그래서 그들은 이런 행동을 했습니다.
• 그래프 QL을 도입했지만, 학습 곡선 때문에 강제하지 않음
• 구조 변경 시, 언제든 돌아갈 수 있게 ‘one-way door’를 만들지 않음
• SliceKit 같은 중간 단계 기술을 도입해 SwiftUI로의 점진적 전환 가능하게 함
이건 제가 현장에서 가장 부러운 지점이기도 합니다.
스타트업에선 새로운 기술을 도입하면 “그냥 다 바꾸자”는 식으로 움직이기 쉽습니다. 하지만 그것이 팀의 혼란을 가져온다는 걸 너무 잘 알기에, 플랫폼팀이 심리적 안전까지 고려한 전환 구조를 설계했다는 점이 정말 본받을 만했습니다.
결과적으로, 코어 스택 도입과 테스트 자동화 이후, 레딧 개발팀은 이렇게 달라졌습니다.
• 신규 입사자의 온보딩 속도 증가
• 테스트 실패율 감소 배포 주기 증가
• 애니메이션, 인터랙션 등 UI 품질 향상
• 크래시율 감소 (Android 기준 1.5% p 개선)
이런 변화는 단지 기술 개선이 아니라, 개발자의 일하는 방식 자체를 바꾸는 변화입니다.
기술보다 ‘구조’를 바꾸는 일
그 구조 속에서 개발자들이 창의적으로 일할 수 있게 만드는 설계.
그게 바로 제가 플랫폼팀에서 배우고 싶은 리더십입니다.