스태프 엔지니어가 중요한 문제를 찾는 법…요청보다 반복되는 불편을 보라

스태프 엔지니어의 역할은 어려운 일을 잘 수행하는 데서 그치지 않고, 조직이 아직 명확히 정의하지 못한 문제를 찾는 데까지 넓어지는 경우가 많다. 구글의 인프라·개발 도구 분야에서 일해 온 엔지니어 Lalit Maganti는 개인 블로그에서 자신이 해결할 문제를 찾는 방식을 공유했다.

요청보다 그 뒤에 있는 문제를 듣는다

그는 일정에 ‘전략적으로 생각하는 시간’을 따로 잡기보다 회의, 채팅, 이메일에서 사람들이 반복해서 겪는 불편을 듣는다고 설명한다. 사용자가 특정 기능을 요구하더라도 곧바로 구현하지 않고, 실제 목표와 기존 도구가 해결하지 못하는 이유를 확인한다.

문제를 직접 재현하거나 관련 팀의 작업 과정을 지켜보는 것도 중요하다. 한 사람의 강한 요구가 조직 전체의 우선순위와 같지는 않기 때문이다.

충분한 증거가 쌓일 때까지 기다린다

후보 문제를 바로 프로젝트로 만들지 않고 여러 팀에서 같은 문제가 반복되는지 살핀다. 서로 달라 보이는 요청에서 공통된 형태를 찾으면 하나의 확장 가능한 해결책으로 묶을 수 있지만, 우아해 보이는 아이디어 자체는 증거가 아니므로 프로토타입과 피드백으로 다시 검증한다.

글에 소개된 Perfetto 사례에서는 팀마다 다른 화면 구성을 요구했지만, 공통 요구는 UI를 각자의 작업 흐름에 맞게 확장하는 능력이었다. 그 결과 매크로와 확장 서버라는 방식이 만들어졌다.

보편 법칙이 아닌 개인의 실무 경험

이 글은 대규모 조직에서 엔지니어의 자율성이 큰 팀을 중심으로 한 개인 경험이다. 저자 역시 의사결정이 위에서 아래로 이뤄지는 조직에서는 같은 방식으로 움직일 여지가 적을 수 있다고 밝힌다. 따라서 모든 회사에 적용되는 승진 공식보다는, 문제를 발견하고 검증하는 한 가지 실무 방법으로 읽는 것이 적절하다.