[2편] 플랫폼팀이 문화를 바꾸는 방법

테스트 커버리지를 2%에서 수십%로

by 오유나
이 글은 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 개선)


이런 변화는 단지 기술 개선이 아니라, 개발자의 일하는 방식 자체를 바꾸는 변화입니다.


기술보다 ‘구조’를 바꾸는 일


그 구조 속에서 개발자들이 창의적으로 일할 수 있게 만드는 설계.

그게 바로 제가 플랫폼팀에서 배우고 싶은 리더십입니다.

keyword
화, 목, 토 연재
이전 14화[1편] 레딧은 어떻게 일했을까