인프라스트럭처 엔지니어링을 할 때보다 제품 엔지니어링을 할 때 스태프플러스 엔지니어가 되기 더 어려운가요?

상황에 따라 다른 것 같아요. 그리고 스트라이프의 경우는 핵심 제품이 인프라스트럭처라서 아무래도 좀 더 쉬웠죠. 그렇다는 것은 제품 엔지니어링 조직 내에서 확장성, 견고성, 마이그레이션 계획, 잘 설계된 인터페이스 등을 고려해야 할 프로젝트에 참여할 기회가 많다는 뜻이죠.

당연히 UI를 구현하는 팀에서만 근무하면 스태프 엔지니어가 되긴 어려울 거예요. UI 제품은 본질적으로 더 일시적이고 반복적이고 실험적인 일이 더 많기 때문이죠. UI 팀의 엔지니어로서 스태프 수준의 영향력을 발휘하려면 그런 영향력을 스스로 만들어낼 수 있어야 합니다. 그러려면 잘 설계된 컴포넌트 라이브러리, 실험용 프레임워크 등을 구현해야 합니다.

제품 엔지니어로서 영향력을 만드는 또 다른 방법은 ‘제품 부채(product debt)’를 관리하는 절차와 시스템을 만드는 거예요. 보통 사람들은 ‘기술 부채’를 언급하는데 ‘제품 부채’도 마찬가지로 중요합니다. 제품 부채는 보통 오래된 버전의 제품을 지원하면서 발생해요. 시간이 지나면서 제품 엔지니어링에서 확장하기 어려운 제품 부채와 제품 표류(서로 다른 방향으로 움직이는 제품 간 상호 운용이 필요한 경우)를 관리하는 것과 관련이 있어요. 저는 회사에서 제품 부채가 쌓이면 어느 정도 규모가 됐을 때 제품 엔지니어링 조직 내에 스태프 수준의 복잡성을 처리해야 할 역할이 필요해질 거라고 믿어요.