엔지니어링 주도 플랫폼 팀의 스태프 엔지니어가 다음에 무엇을 만들지 스스로 일감을 찾아야 하는 이유와 그 방법론을 다루고 있습니다.
일감을 찾는 신호로 시스템(장애, 비용, 운영 잡무), 사용자(문제 탐색, 용도 확장), 조직(목표, 마이그레이션 잔여 과제), 업계 등 네 가지 방향을 제시하며, 단순히 가장 시끄러운 문제가 아닌 우선순위를 설명할 수 있는 근거를 바탕으로 일감을 발굴해야 한다고 강조합니다.
엔지니어링 주도 플랫폼 팀에서는 다음에 무엇을 만들지 스스로 찾아야 하며, 시스템, 사용자, 조직, 업계에서 개선할 일의 단서를 얻을 수 있음
장애, 비용, 반복적인 운영 작업은 개선 대상을 드러내지만, 가장 시끄럽고 최근에 발생한 문제가 가장 큰 기회는 아닐 수 있음
사용자에게 원하는 기능만 묻기보다 실제 작업과 불편, 이미 쓰는 우회책을 살펴야 함. 원래 용도 밖의 활용은 사용자가 직접 만든 프로토타입이 될 수 있음
마이그레이션에서 뒤처진 팀은 기존 해법이 놓친 요구를 드러내며, 현재 시스템을 글로 설명하거나 업계의 시행착오를 살피는 과정에서도 개선점을 찾을 수 있음
일감은 부족하지 않음. 중요한 것은 장애나 상사의 관심사만 따라 백로그를 채우는 대신, 다른 후보보다 이 일을 먼저 해야 하는 이유를 설명하는 것임
플랫폼 팀이 스스로 일감을 찾아야 하는 이유
플랫폼 팀은 제품 주도보다 엔지니어링 주도로 움직이며, 로드맵을 건네는 제품 관리자나 따라갈 매출 지표, 잃을 시장이 거의 없음
엔지니어가 일을 만들어내지 않으면 일감 자체가 생기지 않으며, 사용자에게 제공하는 가치를 지속해서 높일 방법을 찾아야 함
스태프 엔지니어의 중요한 역할은 팀이 다음에 무엇을 만들지 결정하는 것이며, 이를 위한 신호는 시스템, 사용자, 조직, 업계의 네 방향에서 들어옴
시스템의 신호: 장애, 비용, 운영 잡무
장애와 사후 분석은 제대로 수행하면 무엇을 고치거나 교체해야 하는지 알려줌
새로운 구축 대상을 가리키는 경우는 드물지만, 사용자가 받은 영향이나 장기 장애를 우회한 방법을 살피면 새 일감을 발견할 수도 있음
여러 사후 분석에서 패턴을 찾는 작업은 단서가 산발적으로 나타나 정례화하기 어렵지만, 큰 흐름을 놓치지 않도록 해야 함
가장 시끄럽고 최근의 실패에 편향되기 쉬우며, 극단적인 후행 지표라는 한계가 있음
비용은 매출이라는 기준점이 없는 팀에 방향을 제공하지만, 데이터베이스 쿼리나 VPC 간 트래픽 비용 최적화에서 멈춰서는 안 됨
가능하면 사업 부문의 손익계산서, 벤더 계약, 클라우드 청구 항목을 살피거나 비용 구조를 아는 사람에게 물어봐야 함
각 비용 항목에서 외부에 맡기는 이점과 팀 내부로 가져올 때의 변화를 검토함
반대로 현재 팀이 담당하는 기능을 벤더, 클라우드 서비스, 다른 팀에 맡기는 방안도 검토할 수 있음
구매와 자체 구축의 선택은 일회성 결정이 아니며, 업무 범위, 팀 구성, 기술, 시장이 달라지면 재검토할 수 있음
운영 잡무(toil) 는 이를 수행하는 사람에게조차 보이지 않을 수 있는 또 다른 비용이며, 거의 모든 팀에 있지만 우선순위에 오르는 경우는 드묾
팀의 잡무와 사용자의 잡무는 구분해야 함
전자를 줄이면 단위 경제성이 개선되고, 후자를 줄이면 사용자 경험이 개선됨
사용자의 신호: 문제 탐색과 공동 실험
지속적인 탐색은 사용자와 꾸준히 대화하는 과정임
플랫폼을 선택할 자유가 없는 사용자는 이상적인 도구의 모습을 잘 알지 못할 수 있으며, 원하는 것을 물으면 기존 방식의 개선판인 ‘더 빠른 말’을 요구할 수 있음
사용자 인터뷰에 과도하게 의존해서는 안 되지만, 이것이 대화하지 않아도 된다는 뜻은 아님
주/월/분기마다 정한 수의 사용자를 만나 실제 작업과 고충을 확인함
가장 최근에 플랫폼을 사용한 작업을 순서대로 설명해 달라고 요청함
플랫폼 사용 중 가장 큰 세 가지 고충, 이를 해결했을 때 달라지는 점, 같은 문제를 겪는 다른 사용자를 물어봄
실제 문제에는 거의 항상 우회책이 있으므로, 우회책이 없다면 고통이 충분히 절박하지 않은지 확인함
사용자가 제안한 해결책을 그대로 받아들이지 않고, 왜 원하는지와 현재 설계에 사고가 갇혀 있는지 검토함
고충을 문서화하고 언급 빈도에 따라 색인화함
인터뷰는 문제 공간을 함께 이해하는 일에 집중해야 하며, 해결책 설계는 별도의 자리에서 진행해야 함
용도 확장 사례(Overloaded Use-cases) 는 사용자가 원래 의도하지 않은 문제를 플랫폼으로 해결하는 경우임
대안이 있다면 왜 대안 대신 플랫폼을 선택했는지 살펴야 함
이를 사용자가 대신 만든 프로토타입으로 보고, 다른 사용자도 같은 문제를 겪는지를 기준으로 흡수할 대상을 판단함
내부 플랫폼에 관한 기존 논의에서도 이 탐색법을 다룸
프로토타입 공동 개발(Partner-to-Prototype) 은 사후에 용도 확장 사례를 발견하는 대신, 팀과 사용자가 의도적으로 함께 실험하는 방식임
사용자 문제를 해결할 수 있는 프로토타입을 플랫폼 위에 함께 만듦
플랫폼 기능으로 정식 편입하겠다는 약속이 아니라 공동 탐색이며, 흡수 여부의 기준은 다른 사용자도 같은 문제를 겪는지임
조직의 신호: 목표, 반복되는 관심사, 마이그레이션 잔여 과제
OKR을 팀이 직접 정했든 상위 조직에서 받았든, 목표가 정해졌다면 그 항목의 일감은 이미 발굴한 셈임
관리자의 반복 언급 휴리스틱은 관리자나 그 윗선에서 같은 주제를 일주일에 두 번 말하면 해결되지 않은 우려가 있을 가능성을 살피는 방법임
이를 포착하려면 1:1 회의에서 메모하거나 LLM이 생성한 회의록을 읽는 것이 도움이 됨
여러 발굴법 중 가장 약한 편이며, 직급이 높을수록 사용자와 멀어져 HiPPO(Highest Paid Person’s Opinion), 즉 가장 높은 보수를 받는 사람의 의견에 따라 구축할 가능성이 커짐
마이그레이션 잔여 과제(Migration Debris) 는 최신 플랫폼으로 옮기기를 미루거나 끝내 도입하지 않는 팀에서 드러남
중요한 플랫폼 변경에는 마이그레이션이 필요하며, 도입 과정에는 긴 꼬리가 있음
Crossing the Chasm의 곡선처럼 혁신 수용자, 초기 수용자, 전기 다수 수용자, 후기 다수 수용자, 지각 수용자로 이어짐
마지막까지 남은 팀은 새 플랫폼이 어디서 불완전하고 어떤 작업이 더 필요한지 알려줌
내부 플랫폼은 중간값에 해당하는 사용자보다 넓은 범위를 지원해야 하며, 마이그레이션 잔여 과제는 평균적인 해법이 놓친 사용자를 드러냄
업계의 신호: 현행 시스템을 글로 정리하고, 업계의 시차를 활용하기
현행 시스템을 기술하는 글쓰기는 RFC 같은 개선 제안으로 이어질 수 있음
동료, 사용자, 신규 입사자 등을 대상으로 이미 존재하는 시스템의 설계 문서를 작성함
비슷하거나 인접한 역할을 수행하는 최신 시스템과 비교하면, 더 이상 타당하지 않은 기존 결정을 발견할 수 있음
글쓰기를 사고의 수단으로 활용하는 방식임
오픈소스 릴리스, 다른 회사의 블로그, 연구 논문, 컨퍼런스 발표를 통해 업계 동향을 파악하되, 내부 플랫폼이 이를 받아들이는 시차도 활용할 수 있음
컴퓨팅 영역은 장기적으로 통합과 분리 사이를 오가며, 내부 플랫폼도 아이디어가 전파되는 데 시간이 걸려 같은 방향을 늦게 따름
컴퓨팅과 스토리지는 데이터 웨어하우스에서 결합됐다가 데이터 레이크에서 분리됐고, 레이크하우스 엔진에서 다시 결합하고 있음
모놀리스에서 마이크로서비스로 향했던 흐름은 모듈형 모놀리스로 이어지고 있음
시차 활용(Lag Arbitrage) 은 업계가 특정 방향으로 수렴한 논리와 그 근거를 함께 가져오는 방법임
공개 사후 분석, 성공한 마이그레이션, 비교 벤치마크, 다른 회사가 포기한 접근법 등을 활용함
직접 근거를 만들어내는 비용 없이 증거를 얻고, 업계가 이미 포기한 선택지를 건너뛸 수 있음
다만 너무 오래 지연해 추세 도입의 최후미에 남는 것은 피해야 함
어떤 신호를 언제 선택할 것인가
열한 가지 신호를 동시에 추적하기는 어려우므로, 신호 자체가 얼마나 많은 논거를 제공하는지와 선행/후행 여부라는 두 축으로 비교함
사후 분석, 비용 항목, OKR은 이미 설득의 재료를 갖춘 신호임
사후 분석에는 관심을 가진 사람들과 결론이 있고, 비용은 금액으로 표시되며, OKR은 이미 발굴한 일을 추적함
실행에 옮기기 위한 부담은 작지만, 정도의 차이는 있어도 후행 신호임
별도로 논거를 구성해야 하는 신호들은 근거와 조직 내 설득 기반이 서로 다름
시차 활용은 가장 강한 논리를 제공하지만, 증거가 회사 밖에서 왔기 때문에 조직 내 설득 기반은 가장 약함
관리자의 반복 언급은 증거가 없지만 일정한 조직 내 설득 기반은 있음
지속적인 탐색은 사용자 고충을 제공하지만, 이를 명세로 바꾸는 일은 팀의 몫임
용도 확장 사례는 선행 신호이면서 논거가 이미 프로덕션에서 작동하고 있어 두 극단 사이에 위치함