어느날부터 사랑하는 제품이 생기면 PM(Product Manager a.k.a PO)로 일해보고 싶다는 생각이 들었다. 해결할 문제를 정의하고, 문제를 구체화해서 계획을 세우고, 무엇을 먼저 구현할 지 결정하고, 그리고 팀원이 자신의 역량을 최대한 발휘할 수 있도록 여기저기 막힌 부분을 풀어주는 역할이 매력적이었다.
하지만 선뜻 도전하는 것도 망설여졌다. 커리어 전환이라는 큰 의미를 차치하더라도 마음에 걸리는 고민이 몇 가지 있었다.
첫 번째로 정말로 사랑하는 제품이 뭔지 아직 모른다. IT 서비스이면서, 적당히 삶에 녹아들어 많이 사용할 만한, 그러면서 제품을 사용하는 사람들을 보며 성취감을 느낄 제품. 쉽게 찾기 힘들다.
두 번째는 그동안 쌓아 온 FE 엔지니어링 지식을 포기하고 싶지 않은 마음이다. 팀원이 작성한 코드를 직접 볼 일이 거의 없겠지만 코드리뷰 하고 싶은 충동을 억제할 수 있을까? 심지어는 그냥 코딩하고 싶은 생각이 들지 않을까? 논리의 씨줄과 컴포넌트의 날줄로 UI를 직조하는 재미를 그리워하지는 않을까? 그동안 쌓아 온 것보다 훨씬 더 많은 개념과 이해를 PM으로서 쌓아야 할 테니 기억은 쉽게 자리를 내줄 것이고 그리워할 대상조차 잊게 될 것이다.
이런 생각을 하고나니 여전히 FE 엔지니어가 천직이라고 생각하면서 지냈다.
그런데 문득 디자인 시스템의 PM이라면 열정을 가질 수 있고, FE 엔지니어링 지식을 포기하지 않을 수 있을 거란 생각이 들었다. 물론 PM이 되면 디자인 시스템을 사용하지는 않겠지만 지금의 나와 비슷한 사람들이 디자인 시스템을 쓰는 걸 보면서 보람을 느낄 수 있다. 그리고 그동안 디자인 시스템과 그 비스무리한 걸 사용해보면서 느꼈던 점을 문제 정의와 구체화에 사용할 수 있다. 물론 내가 직접 코딩을 하는 건 아닐 것이다. 하지만 여전히 개발자를 잘 관찰하고 그들을 이해하며 좋은 코딩 방식에 대한 고민을 해야 한다. 이런 생각을 바탕으로 더 좋은 디자인 시스템 인터페이스를 만들 것이다.
디자이너, 개발자를 인터뷰하거나 디자인 파일을 분석하고 Pull Request를 읽어보며 디자인 시스템을 사용할 때 불편한 점을 알아내는 것이 가장 먼저일 것이다. 알아낸 정보를 바탕으로 해결해야 할 문제를 구체화하여 이슈로 정리하고 우선순위도 설정할 수 있을 것이다. 하나의 작업을 처리할 때는 개발자 팀원, 디자이너 팀원을 모아 컴포넌트의 인터페이스와 제공하는 기능을 결정한다. 이후 개발자 팀원과 디자이너 팀원은 각자의 역량을 발휘하여 디자인 시스템을 구현한다.
PM은 디자인 시스템을 사용할 수 있는 환경, Figma와 코드가 배포된 라이브러리도 잘 알아야 할 것 같다. 디자인 시스템을 사용하는 디자이너와 개발자에게 어떻게 사용하는 것인지 알리고 도와주는 역할은 PM이 수행해야 생산적이지 않을까? Figma를 디자이너와 개발자 모두에게 유용하게 사용할 수 있게 설정해주거나 구현된 코드를 확인할 수 있는 Storybook/테스트 설정은 다른 사람이 하는 것보다 PM이 하는 게 더 효율적일 수 있다.
이렇게 업무 방식을 상상해보니 PM으로 나뉘는 것보다 디자인 시스템을 다루는 플랫폼 팀의 엔지니어가 되어도 될 것 같다는 생각이 든다. 디자이너, 엔지니어 둘로 이뤄진 작은 팀. 시작은 그런 모습이지 않을까?
디자인 시스템을 위해 별개의 팀을 만들 정도면 회사의 규모가 꽤 커야겠다. 디자이너와 개발자 각각이 실무를 하다가 그 때 그 때 필요에 의해 디자인 시스템을 개선하는 단계를 넘어서 이 일만을 전담하는 팀이 생겨야하니 말이다. 하지만 디자이너, 개발자 각각이 실무에 치이다 디자인 시스템이 삐걱거리는 걸 보면 조금 작은 규모에서 미리 디자인 시스템 전담 팀을 운영하면 어떤 효과가 있을지 궁금하다.
한편으로는 디자인 시스템 PM이 되기에 내 디자인 지식이 부족하다고 느껴지기도 한다. 하지만 컴포넌트 사용률 등을 목표로 삼는다면 이것이 피드백이 되어 디자인 지식을 쌓을 수도 있겠다는 생각이 든다. 여기서도 해결책을 강요하는 것이 아니라 언제나 배우겠다는 태도가 중요하다.
언젠가 경험하고 싶다! 디자인 시스템 팀! 디자인 시스템 PM!