스태프 엔지니어로서 해결할 문제를 찾는 방법

스태프 엔지니어는 주어진 어려운 과제를 푸는 데 그치지 않고, 일상 업무에서 흘러나오는 마찰을 흡수해 조직이 아직 인식하지 못한 중요한 문제를 찾아야 함 사용자의 요청을 그대로 구현하기보다 실제 목표와 기존 제품이 맞지 않는 이유를 파고들고, 여러 팀에서 문제가 반복될 때까지 기다려 공통된 형태를 찾아야 함 Perfetto의 여러 UI 요청은 팀별 작업 흐름에 맞게 화면을 확장하려는 요구로 수렴했고, 이를 매크로와 확장 서버로 구현해 Google 내부 수십 개 팀과 다른 회사들이 사용함 공통점이 보여도 우아한 아이디어만으로는 부족하므로, 위험과 확신에 따라 즉시 변경·일회성 프로토타입·RFC와 장기 개발 중 하나를 선택해 기술적·조직적 검증을 거쳐야 함 유용한 문제를 반복해서 해결하면 사람들이 더 일찍 문제를 공유하고 판단에 대한 신뢰가 쌓여, 모든 구현을 직접 맡지 않고도 로드맵에 영향을 줄 수 있음 전략보다 일상적인 문제 흡수 빈 화면을 바라보며 별도로 “전략적 사고”를 하기보다 회의, 채팅, 발표, 이메일에서 사람들이 겪는 일상적인 마찰을 지속적으로 받아들임 문제를 머릿속에 남겨두면 일부는 사라지고 처음에는 무관해 보였던 문제 사이에 연결이 생기면서, 실제로 사람들을 늦추는 요인과 대응 방법이 드러남 관리자가 기회를 정하고 엔지니어가 가장 어려운 할당 과제를 해결하는 방식도 승진으로 이어질 수 있음 하지만 경력에서 가장 큰 인상을 남긴 프로젝트는 리더가 아직 존재를 알지 못한 중요한 문제를 직접 찾아 해결한 경우였음 이 접근법은 엔지니어가 로드맵에 상향식으로 영향을 줄 자율성이 큰 대기업 인프라·개발자 도구 조직에서 얻은 경험에 기반함 하향식 환경에서는 같은 방식으로 움직일 여지가 적을 수 있음 요청이 아닌 근본 문제 흡수 업무 영역과 겹치는 이야기가 나오면 “X가 있다면 문제가 해결되는가”라고 묻거나, 기존 제품 기능이 사용 사례를 얼마나 충족하는지 확인함 사용자는 근본 문제보다 특정 해결책을 요청하는 경우가 많음 달성하려는 목표와 기존 제품이 작동하지 않는 이유를 이해할 때까지 파고들어야 함 평소 흘러다니는 정보를 듣는 방식은 아이디어를 찾기 위한 추측성 회의를 늘리지 않아도 되므로 내향적인 성향에도 잘 맞음 탐색할 가치가 있는 문제는 더 적극적으로 조사함 팀과 함께 작업 흐름과 조사 중인 버그를 살펴봄 가능하면 일부 버그를 직접 다뤄보며 실제 요구와 요청된 해결책을 구분함 조직을 더 넓게 보는 사람과...