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

아무도 안 쓰는 플랫폼

세상에서 가장 멋진 플랫폼도 개발자들이 쓰기 싫어하면 실패다. 개발자 경험(DevEx)은 있으면 좋은 부가 요소가 아니라, 플랫폼이 실제로 정착할 수 있는지를 가르는 기준에 가깝다.

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

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

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

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

이 차이는 기분 문제에 그치지 않는다. 나쁜 DevEx는 우회로를 낳는다. CI가 너무 느리면 개발자는 테스트를 건너뛰고, 배포 절차가 복잡하면 수동 스크립트를 만들고, 문서가 부실하면 옆 사람에게 계속 물어보게 된다. 결국 플랫폼이 있어도 플랫폼 밖의 비공식 경로가 더 강해진다.

SPACE 프레임워크

마이크로소프트 리서치는 개발자 생산성을 한 가지 숫자로 환원하지 않기 위해 SPACE 프레임워크를 제안했다. 플랫폼 팀 입장에서도 어떤 경험을 개선하고 있는지 점검할 때 꽤 유용한 틀이다.

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

무엇을 측정할 것인가

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

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

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

실제로는 이 세 부류를 함께 봐야 한다. 예를 들어 첫 배포까지 시간은 줄었는데 지원 티켓이 급증했다면, 자동화는 늘었지만 인터페이스가 이해하기 어려워졌을 수 있다. 반대로 만족도는 높은데 채택률이 낮다면, 일부 팀만 혜택을 보고 있을 가능성이 있다. DevEx는 단일 숫자로 요약하기 어렵고, 그래서 오히려 여러 신호를 함께 보는 쪽이 정확하다.

피드백 루프

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

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

플랫폼을 죽이는 안티패턴

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

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

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

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

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

간단한 테스트

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

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

간단한 체크리스트로 바꾸면 더 명확해진다. 새 기능을 넣기 전에 "반복 작업이 줄어드는가?", "실패했을 때 다음 행동이 명확한가?", "새 팀원이 문서만 보고 따라갈 수 있는가?"를 물어보면 된다. 세 질문에 자신 있게 답하지 못한다면, 그 기능은 아직 DevEx 관점에서 덜 다듬어진 것이다.

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