스태프 엔지니어는 어떻게 풀 만한 문제를 찾아내는가

시니어 엔지니어에서 스태프 엔지니어로 넘어가는 길목에서 많은 이들이 벽에 부딪힌다. 주어진 일을 잘 해내는 것만으로는 부족하고, '무엇을 만들어야 하는가'를 스스로 정의하는 역량이 요구되기 때문이다. 성능 디버깅 도구 Perfetto를 개발하는 엔지니어 랄릿 M(Lalit M)은 자신이 멘토링하던 시니어 엔지니어에게서 바로 이 질문을 받았다. "풀 만한 가치가 있는 문제를 어떻게 찾느냐"는 것이었다. 흔히 권해지는 방법은 캘린더에 '큰 그림을 고민하는 시간'을 따로 잡아두는 것이지만, 멘티는 그 방식이 별 성과가 없었다고 털어놓았다. 이 글은 그에 대한 저자 나름의 대안이자, 대기업 인프라·개발자 도구 팀에서 오랫동안 로드맵에 상향식으로 영향을 미쳐 온 경험에서 나온 실무 방법론이다.

전략적 사고보다 스펀지가 되는 일

저자의 핵심 주장은 의외로 소박하다. 빈 화면을 앞에 두고 '전략적으로 생각하자'며 앉아 있는 방식으로는 좋은 문제가 거의 나오지 않는다는 것이다. 대신 그는 스스로를 스펀지에 비유한다. 회의, 채팅 스레드, 발표, 이메일에 흘러다니는 일상의 잡음을 흡수하고, 사람들이 겪는 문제를 머릿속 한켠에 그냥 두는 것이다. 시간이 지나면 어떤 문제는 흐려져 사라지고, 처음에는 무관해 보이던 다른 문제들 사이에 연결 고리가 드러나기 시작한다. 사람들은 자신이 겪는 어려움을 이야기하기를 좋아하므로, 평범한 한 주 동안에도 이미 방대한 양의 유용한 정보가 주변에 흐르고 있다는 것이 그의 관찰이다. 내향적인 성격의 저자에게는 추측성 회의로 일정을 채우지 않고도 정보를 얻을 수 있는 이 '주변 청취' 방식이 특히 잘 맞았다.

다만 그는 사용자의 요청을 액면 그대로 받아들이지 않는다. 사람들은 근본 문제를 설명하는 대신 특정 해법을 요구하는 경향이 있기 때문이다. 그래서 그는 "만약 X가 있다면 문제가 해결되겠느냐"고 묻거나, 자신이 소유한 제품의 기존 기능을 가리키며 사용 사례를 얼마나 커버하는지 되묻는다. 탐색할 가치가 있어 보이는 문제라면 더 적극적으로 움직여, 팀의 워크플로와 그들이 조사 중인 버그를 옆에서 지켜보고 가능하면 직접 그 버그를 다뤄 본다. 문제를 직접 목격해야 팀이 요청한 해법과 실제로 필요한 것을 구분할 수 있기 때문이다. 조직을 더 넓게 보는 사람들, 즉 핵심 시스템을 소유하거나 여러 팀에 걸쳐 일하는 이들과의 1:1이나 커피챗도 같은 문제가 여러 곳에서 반복되는 패턴을 앞당겨 발견하게 해 준다.

기다림이라는 초능력

저자가 여러 번 데인 지점은 '너무 빨리 움직인 것'이었다. 목소리 큰 팀의 요청에 흥분해 기능을 만들었지만 그들이 거의 쓰지 않는 경우가 반복됐다. 우선순위가 바뀌었거나, 일회성 조사에서 나온 요청이 더는 중요하지 않게 된 탓이다. 그 순간의 열의는 제품 전체 관점에서의 중요도와 같지 않았다. 여기서 그는 문제를 쌓아 두는 법을 배웠다. 기다리면 같은 문제가 여러 팀에서 독립적으로 튀어나와 우선순위가 올라가거나, 겉모습이 다른 문제들이 사실 같은 형태임이 드러나 한 번에 여러 사용 사례를 해결할 수 있게 된다. 요청한 팀이 애초에 그리 절실하지 않았다는 사실이 드러나기도 한다. 기록을 체계적으로 남기든 머릿속에 메모하든 방식은 개인의 선택이지만, 미해결 문제를 증거가 쌓일 만큼 오래 살려 두는 것이 핵심이다.

Perfetto가 좋은 사례다. 이 도구는 시스템 활동 기록을 '트랙'이라 불리는 행으로 이루어진 타임라인에 표시하는데, 여러 팀이 몇 년에 걸쳐 작지만 제각각인 UI 추가 요청을 보내왔다. 한 팀은 선호하는 트랙을 화면 상단에 고정하는 명령을, 다음 팀은 완전히 다른 트랙 집합에 대해 같은 기능을 원했다. 특정 구간에 확대된 채로 열리기를 바라거나 맞춤 집계를 요구하기도 했고, 일부는 기다림을 포기하고 북마클릿으로 정교한 우회책을 만들기까지 했다. 저자는 책상에 앉아 해법을 억지로 짜내는 대신 런던을 목적 없이 오래 걸을 때 연결이 더 쉽게 떠오른다고 말한다. 결국 그가 깨달은 것은, 어느 팀도 자신이 요청한 특정 기능을 정말로 원한 게 아니라는 사실이었다. 모두가 원한 것은 남에게 강요하지 않으면서 자기 워크플로에 맞게 Perfetto를 개인화하는 능력, 곧 UI를 확장하는 능력이었다.

우아함은 증거가 아니다

여러 요청이 하나의 아이디어로 수렴하는 순간은 이 일에서 가장 짜릿한 경험이지만, 저자는 바로 그때가 가장 조심해야 할 때라고 못 박는다. 공통된 형태는 가설일 뿐이고 우아함은 증거가 아니기 때문이다. 실제로 그는 대용량 트레이스 공유와 반복 쿼리 문제를 하나의 투명 캐싱 시스템으로 풀 수 있다고 확신했지만, RFC를 쓰고 프로토타입을 만드는 과정에서 두 문제가 근본적으로 다른 해법을 원한다는 것을 깨달았다. 결국 설계를 둘로 쪼갰고, 반복 쿼리는 세션을 메모리에 따뜻하게 유지하는 방식으로, 재열기는 빠른 로딩용 포맷으로 명시적 내보내기를 하는 방식으로 각각 출시됐다.

검증을 통과한 아이디어라도 곧바로 구축에 들어가지는 않는다. 확신과 리스크에 따라 대응 수위가 달라진다. 유용하고 위험이 낮으면 바로 변경을 보내고 매니저에게 알린다. 성공 여부나 공수가 불확실하면 버릴 각오로 프로토타입을 만들어 실패 지점을 드러내고 남들이 반응할 구체적 대상을 확보한다. 크지만 확신이 서는 아이디어라면 수주에서 수개월의 작업과 여러 팀의 지지를 얻는 고된 과정에 온전히 투신한다. 이 모든 과정에서 그는 타인만이 아니라 자기 자신을 설득하려 하며, 사람들이 가치를 못 느끼거나 큰 기술적 벽에 부딪히면 유지보수 악몽이 될 무언가를 만드느니 지금 접는 편을 택한다. 아이디어가 살아남되 타이밍이 안 맞으면, 조직의 우선순위가 되는 날 즉시 움직일 수 있도록 보류해 둔다.

확장 아이디어는 전면적 투자를 할 가치가 있었다. 이미 UI 모듈화를 위한 플러그인이 있었지만, 팀들이 플러그인 코드를 전부 오픈소스로 공개해야 해서 내부 사용 사례 다수에는 선택지가 되지 못했다. 그래서 저자는 새것을 만들기 전에 문제와 제안을 매니저, 팀원, 클라이언트 팀에 가져가 두 편의 RFC를 쓰고 여러 차례의 1:1과 발표를 거치며 다듬었다. 결과물은 플러그인 없이도 UI 동작을 자동화하는 '경량 확장'인 매크로였고, 확장 서버는 팀들이 매크로를 공유할 수 있게 해 이 아이디어를 한 걸음 더 밀고 나갔다. 모든 요청 기능을 직접 구현하는 대신 팀들이 스스로 Perfetto를 적응시킬 방법을 준 것이다. 현재 구글 내부 수십 개 팀과 여러 외부 기업이 이를 사용한다.

한국의 실무자에게 이 글이 주는 함의는 분명하되 한계도 함께 읽어야 한다. 문제를 찾는 일은 회의와 조율로 기술 작업을 대체하는 것이 아니라, 대화를 '만들 것'을 정하는 입력으로 삼는다는 관점의 전환이다. 관심을 보이고 유용한 질문을 던지며 문제 해결을 돕는 사람에게 사람들은 더 일찍 찾아오고, 그 폭넓은 시야가 다시 패턴 발견으로 이어지는 선순환이 만들어진다. 다만 저자 스스로 밝히듯 이 방법론은 엔지니어에게 상향식 자율성이 큰 대기업 인프라·도구 팀의 경험에서 나온 것이다. 상명하달식 환경에서는 이렇게 일할 여지가 애초에 적을 수 있다. 또한 이는 매니저와 조직이 오랜 스튜어드십을 통해 판단을 신뢰하기까지 초기에는 아이디어를 스스로 현실로 만들어 증명해야 했던, 시간과 신뢰 축적을 전제로 한 방식이라는 점도 함께 새길 필요가 있다.