플랫폼 엔지니어링 03 - 개발자 경험이 북극성인 이유

아무도 안 쓰는 플랫폼

세상에서 가장 멋진 플랫폼을 만들 수 있다. 하지만 개발자들이 쓰기 싫어하면 그 플랫폼은 실패한 것이다. 개발자 경험(DevEx)은 있으면 좋은 부가 요소가 아니라, 플랫폼이 살아남을 수 있는지를 결정하는 핵심 지표이다.

DevEx가 실제로 어떻게 보이는가

좋은 DevEx의 경우를 생각해 보자. 코드를 푸시하면 CI가 자동으로 실행되고, 5분 안에 배포가 완료되며, 로그와 메트릭이 즉시 확인된다.

나쁜 DevEx의 경우는 이와 대조적이다. 코드를 푸시한 뒤 CI가 40분 동안 돌아가는 것을 기다리고, 설정 파일을 수동으로 수정하고, 슬랙에서 누군가에게 배포 승인을 요청하고, 서버에 SSH로 접속해서 서비스가 정상적으로 동작하는지 직접 확인해야 한다.

두 경우 모두 최종 결과는 같다. 하지만 그 과정에서의 경험은 완전히 다르며, 이 차이가 개발자의 생산성과 만족도를 결정짓는 것이다.

SPACE 프레임워크

마이크로소프트 리서치가 개발자 생산성을 체계적으로 이해하기 위해 SPACE 프레임워크를 제안했다. 플랫폼 팀이 자신들의 성과를 평가할 때 유용한 렌즈가 되는 프레임워크이다.

여기서 주의할 점은 한 가지 차원만 최적화하는 함정에 빠지지 않는 것이다. 빠르지만 사용할 때마다 짜증이 나는 플랫폼은 좋은 DevEx가 아니다. 쉽지만 불안정한 플랫폼도 마찬가지이다. 여러 차원을 균형 있게 고려해야 비로소 의미 있는 개발자 경험을 제공할 수 있는 것이다.

무엇을 측정할 것인가

시간 기반 메트릭은 직접 측정이 가능하다. 커밋에서 프로덕션까지 걸리는 시간, 새 환경을 프로비저닝하는 속도, 신규 개발자가 첫 배포까지 도달하는 시간, CI 소요 시간 등이 여기에 해당한다. 숫자로 명확하게 나오기 때문에 추적하기 가장 용이한 지표이다.

채택 메트릭은 개발자들이 실제로 플랫폼을 사용하고 있는지를 보여준다. 골든 패스를 따르는 팀의 비율, 셀프서비스 대비 티켓 요청의 비율, 첫 사용 이후 반복적으로 돌아오는지 여부를 추적하는 것이다. 다만 채택률이 높은데 만족도가 낮다면, 그것은 자발적 선택이 아니라 강제의 결과일 가능성이 높다.

만족도 메트릭은 개발자들의 주관적인 느낌을 포착한다. 분기별로 짧은 개발자 설문을 실시하고, 내부 도구에 대한 NPS를 추적하고, 지원 티켓에서 반복적으로 등장하는 주제를 분석하는 방식이다.

피드백 루프

짧은 루프와 긴 루프를 모두 갖추는 것이 중요하다. 짧은 루프에서는 개발자가 마찰을 보고하면 며칠 안에 수정을 배포한다. 이를 통해 신뢰가 쌓인다. 긴 루프에서는 분기별 설문을 통해 트렌드를 파악하고 로드맵을 조정한다. 이를 통해 전략이 만들어진다.

가장 나쁜 것은 피드백을 요청해 놓고 아무런 조치를 취하지 않는 것이다. 이런 상황이 반복되면 개발자들은 무엇이 고장났는지 알려주는 것을 포기하고 자체적으로 우회 방법을 만들기 시작한다. 그 시점이 되면 이미 플랫폼에 대한 신뢰를 잃은 것이다.

플랫폼을 죽이는 안티패턴

"만들면 알아서 오겠지"라는 태도는 온보딩, 문서화, 마이그레이션 지원을 모두 건너뛰게 만든다. 결과적으로 아무도 오지 않는 플랫폼이 남게 된다.

반대로 준비가 덜 된 플랫폼에 팀을 강제로 이주시키는 것도 위험하다. 채택을 강제하는 것은 플랫폼에 대한 신뢰를 가장 빠르게 소진시키는 방법이다.

"이번 달 배포 1000회"를 축하하면서 그중 절반이 실패한 사실을 간과하는 경우도 있다. 활동 지표만 추적하고 결과를 무시하면 숫자가 실상을 가리는 것이다.

골든 패스가 정상적으로 작동하는 상황에서는 문제가 드러나지 않는다. 진짜 시험은 에러가 발생했을 때이다. 안내 없이 알 수 없는 메시지만 표시되면 개발자는 플랫폼을 우회하는 쪽을 선택하게 된다.

추상화에도 같은 원리가 적용된다. 복잡성을 지나치게 숨기면 문제가 발생했을 때 아무도 디버깅할 수 없게 된다. 추상화는 유용하지만, 벽이 되는 순간 오히려 장애물이 되는 것이다.

간단한 테스트

플랫폼은 제품이고, 개발자는 그 제품의 사용자이다. 고객 대상 제품을 UX에 신경 쓰지 않고 출시하는 일은 없다. 내부 플랫폼도 이와 다르지 않다.

모든 플랫폼 의사결정은 하나의 테스트를 통과해야 한다. 이 결정이 개발자의 일상을 더 쉽게 만드는가, 아니면 더 어렵게 만드는가 하는 것이다.

다음 포스트에서는 골든 패스를 실전에서 다룬다. 올바른 일을 쉬운 일로 만드는 기본 경로의 설계 방법이다.