플랫폼 엔지니어링 07 - 제품으로서의 플랫폼

강제 도입의 함정

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

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

개발자는 고객이다

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

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

제품 관리 실천법

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

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

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

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

자발적 채택 테스트

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

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

성공 측정

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

내부 마케팅

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

가장 흔한 실패

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

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

다음 포스트에서는 대규모 CI/CD를 다룬다.