엔지니어링 주도 플랫폼 팀의 스태프 엔지니어는 다음에 무엇을 만들지 스스로 찾아야 하는 중요한 역할을 맡고 있습니다. 제품 관리자(PM)가 로드맵을 제공하는 일반적인 제품 팀과 달리, 플랫폼 팀은 매출 지표나 잃을 시장이 명확하지 않아 엔지니어 스스로가 사용자에게 제공할 가치를 지속적으로 높일 방법을 모색해야 합니다. 단순히 장애나 상사의 관심사만 따라 백로그(backlog)를 채우는 것이 아니라, 다양한 신호 속에서 다른 후보보다 이 일을 먼저 해야 하는 분명한 이유를 설명하는 능력이 핵심입니다.
일감 발굴을 위한 신호는 크게 네 가지 영역에서 찾을 수 있습니다. 첫째, 시스템의 신호로는 장애, 비용, 반복적인 운영 잡무(toil)가 있습니다. 사후 분석(post-mortem)을 통해 무엇을 고치거나 교체해야 할지 파악하고, 클라우드 비용 최적화나 운영 잡무 감소를 통해 단위 경제성 개선 및 사용자 경험 향상 기회를 발견할 수 있습니다. 둘째, 사용자의 신호는 지속적인 탐색과 공동 실험을 통해 얻습니다. 사용자가 원하는 기능만 묻기보다 실제 작업 흐름, 고충, 그리고 현재 사용 중인 우회책을 깊이 있게 이해하는 것이 중요하며, 사용자가 의도치 않게 플랫폼을 활용하는 '용도 확장 사례(Overloaded Use-cases)'도 중요한 단서가 됩니다. 셋째, 조직의 신호는 OKR(목표 및 핵심 결과), 관리자의 반복적인 언급, 그리고 마이그레이션 잔여 과제(Migration Debris)에서 찾을 수 있습니다. 특히 최신 플랫폼으로의 마이그레이션에서 뒤처진 팀은 기존 해법이 놓친 요구사항을 명확히 드러냅니다. 넷째, 업계의 신호는 현행 시스템을 글로 정리하고 업계 동향의 '시차 활용(Lag Arbitrage)'을 통해 얻을 수 있습니다. 다른 회사의 성공적인 마이그레이션 사례나 포기한 접근법을 참고하여 시행착오를 줄일 수 있습니다.
이러한 열한 가지 신호를 동시에 추적하기는 어렵기 때문에, 각 신호가 제공하는 논거의 강도와 선행/후행 여부를 기준으로 우선순위를 정해야 합니다. 사후 분석, 비용 항목, OKR은 이미 설득의 재료를 갖춘 후행 신호로 실행 부담이 적습니다. 반면 시차 활용은 가장 강력한 논리를 제공하지만, 조직 내 설득 기반이 약할 수 있습니다. 가장 위험한 것은 빈 백로그가 아니라, 가장 시끄럽고 최근에 발생한 문제에만 편향된 백로그입니다. 스태프 엔지니어는 단순히 신호를 찾는 것을 넘어, 수많은 잠재적 일감 중 특정 신호를 선택하고 이를 먼저 추진해야 하는 명확한 이유를 제시함으로써 플랫폼 팀의 전략적 가치를 극대화해야 합니다. 이는 플랫폼 팀이 고립된 조직이 아닌, 내부 사용자에게 실질적인 가치를 제공하고 다른 팀의 성과를 키우는 '제품 중심' 조직으로 거듭나는 데 필수적인 역량입니다.