강제 도입의 함정

중앙 팀이 새로운 도구를 만들고 리더십이 전사적으로 사용을 지시하는 패턴은 흔히 볼 수 있다. 개발자들은 형식적으로 따르지만, 도구가 제대로 동작하지 않는 부분마다 우회 방법을 찾게 된다. 6개월이 지나면 플랫폼 팀은 지원 티켓에 파묻히게 된다.

이 상황을 직접 경험해본 입장에서 말하자면, 대안은 명확하다. 플랫폼을 제품처럼 다루고, 개발자를 고객처럼 대한다.

개발자는 고객이다

개발자를 "감사해야 하는 사용자"로 바라보는 시각은 잘못된 것이다. 개발자는 선택권이 있는 고객이다. 플랫폼이 유일한 공식 옵션이라 해도 개발자는 언제든지 우회할 수 있다. 섀도우 IT를 도입하거나, 수동 프로세스로 돌아가거나, 플랫폼을 그냥 무시하는 것이 모두 가능하다.

플랫폼이 진정으로 좋다면 개발자가 자발적으로 선택하게 된다. 이것이 플랫폼의 성공 여부를 판단하는 기준이 되어야 한다.

물론 내부 플랫폼에는 완전한 시장 경쟁이 존재하지 않는다. 회사 표준이라는 이유로 사실상 강제되는 부분도 있다. 그래서 더더욱 중요한 것은 "강제된 사용"과 "실제 선호"를 구분하는 일이다. 공식 경로를 쓰면서도 뒤에서 계속 우회 스크립트가 늘어난다면, 채택은 된 것처럼 보여도 제품은 실패하고 있는 셈이다.

제품 관리 실천법

가장 먼저 해야 할 일은 개발자와 직접 대화하는 것이다. 설문 조사가 아니라 실제 대화를 의미한다. 개발자가 플랫폼을 사용하는 모습을 관찰하고, 어디에서 막히는지를 파악해야 한다.

질문도 추상적이면 도움이 되지 않는다. "무엇이 불편한가?"보다 "최근 배포에서 가장 오래 걸린 단계가 무엇이었는가?", "새 서비스 만들 때 누구에게 가장 먼저 물어봤는가?", "문서 대신 슬랙을 연 이유가 무엇이었는가?" 같은 질문이 훨씬 많은 정보를 준다. 플랫폼 문제는 대개 선언보다 행동에서 더 잘 드러난다.

이렇게 발견한 고통 지점을 기준으로 로드맵의 우선순위를 정해야 한다. 기술적 우아함이 아니라 개발자가 실제로 겪는 문제의 심각도 순서로 정렬한다. 로드맵을 공개하면 개발자들의 신뢰를 쌓을 수 있다.

이슈 제보 과정은 극도로 쉬워야 한다. Slack 채널, 간단한 폼, 오피스 아워 등 접근 장벽이 낮은 경로를 제공해야 한다. 그리고 반드시 피드백 루프를 닫아야 한다. 제보를 받기만 하고 반응이 없으면 다음부터는 아무도 이슈를 보고하지 않게 되기 때문이다.

작은 단위로 출시하고, 피드백을 받고, 반복하는 것이 핵심이다. 6개월 동안 사라져서 완벽한 플랫폼을 만들겠다는 계획은 대부분 실패로 끝나게 된다.

자발적 채택 테스트

개발자가 플랫폼 사용을 강제받지 않아도, 여전히 선택할 것인가?

이 질문에 대한 답이 아니오라면, 그것은 마케팅 문제가 아니라 제품 문제이다. 홍보를 강화하기 전에 제품 자체를 먼저 개선해야 한다.

성공 측정

지표알 수 있는 것
채택률팀들이 플랫폼을 선택하고 있는가?
첫 배포까지 시간제로에서 프로덕션까지 얼마나 걸리는가?
지원 티켓 수직관적인가 혼란스러운가?
개발자 만족도플랫폼을 어떻게 느끼는가?
변경 리드 타임실제로 팀을 빠르게 하고 있는가?
유지율남아있는가 떠나고 있는가?

모든 지표를 한꺼번에 측정하려고 할 필요는 없다. 조직의 상황에 맞는 3~4개를 선택하여 집중하는 것이 효과적이다.

내부 마케팅

아무리 뛰어난 기능을 만들었다 해도 개발자가 그 존재를 모른다면 의미가 없다. 개발자가 이미 있는 곳에서 알려야 한다. Slack, 올핸즈, 팀 미팅 등 기존 채널을 활용한다. 짧은 세션으로 데모를 진행하고, 작업 중심의 가이드로 문서화해야 한다. 60분짜리 웨비나 녹화본이나 복잡한 아키텍처 다이어그램은 대부분의 개발자가 보지 않는다.

좋은 내부 마케팅은 홍보 문구보다 "바뀐 작업 방식"을 보여준다. 예를 들어 "새 배포 시스템 출시"보다 "이제 서비스 생성부터 첫 배포까지 8단계 대신 2단계"라고 설명하는 편이 훨씬 설득력 있다. 개발자는 기능 목록보다 자신이 절약할 시간을 먼저 본다.

가장 흔한 실패

플랫폼 팀이 겪는 가장 흔한 실패는 개발자가 실제로 필요로 하는 것 대신, 필요할 것이라고 생각하는 것을 만드는 것이다. 인프라 관점에서 문제를 식별하고, 자체적인 멘탈 모델에 맞춰 우아한 솔루션을 설계한 뒤 출시하지만, 채택률이 저조하면 개발자 탓을 하게 되는 패턴이다.

이 함정을 피하려면 만든 후가 아니라 만들기 전에 개발자와 이야기해야 한다. 아무도 쓰고 싶어하지 않는 플랫폼은 그저 비용이 많이 드는 인프라에 불과한 것이다.

다음 글에서는 대규모 CI/CD를 다룬다.