스태프 엔지니어를 위한 일감 발굴 가이드

엔지니어링 주도 플랫폼 팀에서는 다음에 무엇을 만들지 스스로 찾아야 하며, 시스템, 사용자, 조직, 업계에서 오는 신호가 일감 발굴의 출발점이 됨 장애, 비용, 운영 잡무는 개선 대상을 드러내지만, 장애 중심 탐색은 가장 큰 기회보다 가장 시끄럽고 최근에 발생한 실패에 치우칠 수 있음 지속적인 사용자 탐색은 요구받은 해결책을 그대로 구현하는 과정이 아니라, 실제 작업과 고충, 이미 쓰고 있는 우회책을 함께 이해하는 과정이어야 함 사용자가 플랫폼을 원래 설계와 다른 용도로 활용하는 용도 확장 사례는 이미 운영 중인 프로토타입이며, 다른 사용자도 같은 문제를 겪는지가 플랫폼에 흡수할지 판단하는 기준임 일감 발굴의 핵심은 신호 부족을 해소하는 것이 아니라, 왜 다른 신호가 아닌 이 신호를 선택하는지 설명하는 데 있음 플랫폼 팀이 스스로 일감을 찾아야 하는 이유 플랫폼 팀은 제품 주도보다 엔지니어링 주도로 움직이며, 로드맵을 건네는 제품 관리자나 따라갈 매출 지표, 잃을 시장이 거의 없음 엔지니어가 일을 만들어내지 않으면 일감 자체가 생기지 않으며, 사용자에게 제공하는 가치를 지속해서 높일 방법을 찾아야 함 스태프 엔지니어의 중요한 역할은 팀이 다음에 무엇을 만들지 결정하는 것이며, 이를 위한 신호는 시스템, 사용자, 조직, 업계의 네 방향에서 들어옴 시스템의 신호: 장애, 비용, 운영 잡무 장애와 사후 분석은 제대로 수행하면 무엇을 고치거나 교체해야 하는지 알려줌 새로운 구축 대상을 가리키는 경우는 드물지만, 사용자가 받은 영향이나 장기 장애를 우회한 방법을 살피면 새 일감을 발견할 수도 있음 여러 사후 분석에서 패턴을 찾는 작업은 단서가 산발적으로 나타나 정례화하기 어렵지만, 큰 흐름을 놓치지 않도록 해야 함 가장 시끄럽고 최근의 실패에 편향되기 쉬우며, 극단적인 후행 지표라는 한계가 있음 비용은 매출이라는 기준점이 없는 팀에 방향을 제공하지만, 데이터베이스 쿼리나 VPC 간 트래픽 비용 최적화에서 멈춰서는 안 됨 가능하면 사업 부문의 손익계산서, 벤더 계약, 클라우드 청구 항목을 살피거나 비용 구조를 아는 사람에게 물어봐야 함 각 비용 항목에서 외부에 맡기는 이점과 팀 내부로 가져올 때의 변화를 검토함 반대로 현재 팀이 담당하는 기능을 벤더, 클라우드 서비스, 다른 팀에 맡기는 방안도 검토할 수 있음 구매와 자체 구축의 선택은 일회성 결정이 아니며, 업무 범위, 팀 구성, 기술, 시장이 달라지면 재검토할 수 있음...