How I Find Problems to Solve as a Staff Engineer

3줄 요약

1. Perfetto를 만드는 구글 엔지니어 Lalit Maganti가, 스태프 엔지니어로 승진하려는 멘티의 “무엇을 풀 문제로 고를 것인가"라는 질문에 답하며 자기 방식을 정리한 글이다. 2026년 7월 25일 개인 블로그 발행, 독자 피드백을 받아 이후 개정했다.
2. 그는 캘린더에 사고 시간을 비워 두는 방식으로는 좋은 문제를 찾지 못했다고 한다. 대신 스펀지처럼 일상의 대화를 흡수해 문제를 머릿속에 남겨 두고, 같은 문제가 다른 팀에서 독립적으로 다시 올라오거나 겉모습이 다른 요청들이 같은 형태로 겹칠 때까지 기다린다.
3. 겹침을 발견해도 곧바로 만들지 않는다. 우아함은 근거가 아니라는 이유로 RFC와 버리는 프로토타입으로 먼저 압력을 걸고, 그 시험을 통과한 아이디어만 몇 주에서 몇 달의 작업으로 옮긴다.

질문은 멘티에게서 나왔다

저자가 멘토링하는 시니어 엔지니어가 물었다. 풀 만한 문제를 어떻게 찾습니까. 그는 스태프 엔지니어로 올라가려 하면서, 이 역할이 배정받은 일을 잘 해내는 것만이 아님을 깨달았다. 팀과 조직이 무엇을 만들어야 하는지 정하는 일에도 끼어들어야 했다.

누군가는 큰 그림을 생각할 시간을 캘린더에 확보하라고 조언했다. 멘티는 그대로 해 봤지만 성과가 없었고, 다른 방법이 있는지 물어 온 것이다.

저자의 답은 이렇다. 빈 페이지를 들여다보며 전략적으로 사고하려 해서 좋은 문제를 찾은 적은 거의 없다. 그는 스펀지처럼 행동한다. 하루하루의 소음을 듣고, 사람들이 겪는 문제를 흡수해 머리 뒤편에 놓아둔다. 시간이 지나면 일부는 사라지고, 무관해 보였던 것들 사이에 연결이 나타난다. 그러고 나서야 무엇이 사람들을 실제로 느리게 만드는지, 자기 팀이나 자신이 무엇을 할 수 있는지가 보인다.

그는 이런 시도를 한 번도 해 보지 않은 엔지니어를 많이 만났다고 적는다. 그들은 매니저나 리드가 기회를 찾아 줄 때까지 기다렸다가, 배정된 가장 어려운 문제를 풀어 가치를 증명한다. 그것도 분명히 승진으로 이어진다. 다만 저자의 경력에서 가장 강한 인상을 남긴 프로젝트는, 리더들이 아직 존재조차 모르던 중요한 문제를 스스로 찾아 해결한 쪽이었다.

한 가지 단서를 달아 둔다. 그의 경험은 대기업의 인프라와 개발자 도구, 그중에서도 엔지니어가 로드맵에 영향을 줄 상향식 자율성을 상당히 가진 팀에서 나왔다. 더 하향식인 환경에서는 이렇게 일할 여지가 애초에 적을 수 있다.

요청과 문제를 가른다

사람들은 자기가 겪는 문제를 이야기하기를 좋아한다. 회의에서, 채팅 스레드에서, 발표와 이메일에서. 왜 자기 일이 어려운지 설명하고, 무엇이 자신을 느리게 만드는지 불평하고, 무엇을 할 수 있으면 좋겠다고 말한다.

자기 영역과 겹치는 무언가가 나오면 저자는 실을 당겨 본다. X가 있으면 문제가 풀립니까, 하고 묻거나, 자기가 소유한 제품의 기존 기능을 가리키며 그것이 상대의 사용 사례를 얼마나 덮는지 되묻는다.

사용자는 근본 문제를 설명하는 대신 특정 해결책을 요구하는 일이 잦다. 그는 요청을 액면 그대로 받지 않고, 상대가 무엇을 이루려 하는지와 기존 제품이 왜 통하지 않는지를 이해할 때까지 계속 파고든다.

천성이 내향적인 그에게는 이런 주변 청취가 특히 잘 맞는다. 아이디어를 찾겠다고 캘린더를 추측성 회의로 채울 필요가 없다. 평범한 한 주 동안에도 쓸 만한 정보가 이미 엄청나게 흐르고 있다.

다만 탐색할 가치가 있어 보이는 문제가 나오면 그는 더 능동적으로 움직인다. 그 문제가 팀의 일상 업무에 어떻게 작용하는지 봐야 하기 때문이다. 그들과 함께 앉아 워크플로와 조사 중인 버그를 따라가고, 가능하면 그 버그 몇 개를 직접 다뤄 본다. 문제를 직접 보면, 팀이 실제로 필요한 것과 팀이 요구한 해결책을 분리하기가 쉬워진다.

조직을 자기보다 넓게 보는 사람도 찾아 나선다. 핵심 시스템을 소유한 사람, 여러 팀을 넘나드는 사람, 자기 팀의 하류 작업을 특히 깊이 아는 사람이다. 1:1이나 커피 챗을 잡고 그들이 마주친 흥미로운 문제를 묻는다. 그들은 같은 문제를 이미 여러 곳에서 보고 점을 잇기 시작했을 수 있고, 그러면 혼자서는 훨씬 늦게 알아차렸을 패턴을 앞당겨 얻는다.

서둘러 만들다 데인 적이 있다

저자는 너무 빨리 움직여 여러 번 데었다. 목소리 큰 팀의 요청에 흥분해 기능을 만들었는데, 그 팀은 거의 쓰지 않았다. 우선순위가 바뀌었거나, 요청이 이미 의미를 잃은 일회성 조사에서 나온 것이었다. 그 순간 팀이 얼마나 간절했는지는, 자기 제품이 지원해야 할 다른 모든 것에 비해 그 기능이 얼마나 중요한지와 같은 값이 아니었다. 요청 하나에 과집중하면서 큰 그림을 놓친 것이다.

그 일로 그는 후보 문제를 쌓아 두는 법을 배웠다. 그런 식으로 듣다 보면 도저히 다 풀 수 없을 만큼 많은 문제가 남고, 그 전부가 행동할 값을 하지도 않는다. 대부분은 처음 들은 자리에서 프로젝트가 될 필요가 없다. 기다림이 초능력일 수 있다.

기다리면 같은 문제가 다른 팀에서 독립적으로 다시 올라올 수 있고, 그러면 우선순위가 올라간다. 겉모습이 다른 문제들이 실은 같은 형태여서, 여러 사용 사례를 한 번에 처리할 수도 있다. 또는 그가 아프게 배운 대로, 요청한 팀이 애초에 그만큼 절실하지 않았음이 드러난다.

그는 머릿속에 표시를 남기고, 문제가 다시 올라오면 되돌아본다. 그가 아는 다른 엔지니어들은 이런 것을 더 체계적으로 적어 둔다. 방식은 개인의 선택이고, 각자 자기에게 맞는 것을 찾아야 한다. 중요한 건 미해결 문제를 근거가 더 쌓일 만큼 오래 곁에 두는 것이다.

흩어진 요청을 겹쳐 본다

기다림은 근거를 모아 주지만, 그것만으로 무엇을 만들지가 정해지지는 않는다. 남겨 둔 문제들이 정말 서로 관련이 있는지, 그리고 무엇이 그것들을 함께 해결할 수 있는지를 따로 풀어야 한다.

저자가 일하는 성능 디버깅 도구 Perfetto가 좋은 예다. 이 도구는 시스템 활동 기록을 트랙이라 불리는 행들로 이루어진 타임라인에 표시한다. 몇 년에 걸쳐 팀들이 UI에 작고 구체적인 추가를 요청해 왔다.

이만큼 쌓였을 때 그의 머릿속은 늘 그렇듯 엉켜 있었다. 요청 자체, 각각에 걸린 제약, 그리고 절반쯤 형태를 갖춘 해결책 몇 개. 그는 책상에 앉아 생각하는 것으로 해결책을 억지로 끌어내지 않는 법을 배웠다. 가장 잘 풀리는 자리는 런던을 목적 없이 오래 걷는 시간이었다. 억지로 붙이려 하지 않을 때 연결이 더 쉽게 온다.

결국 알게 된 것은, 어느 팀도 자기가 요청한 특정 기능을 정말로 원한 게 아니었다는 것이다. 각 팀은 자기 워크플로에 맞게 Perfetto를 개인화하면서 그 선택을 다른 모두에게 강요하지 않기를 원했다. 근본 필요는 어느 한 기능이 아니라 UI를 확장할 수 있는 능력이었다.

그런 연결이 마침내 딸깍 맞물릴 때가 이 일에서 가장 좋은 순간 중 하나다. 어색했던 여러 요청이 하나의 아이디어로 접히고, 각각으로는 암시조차 없던 가능성이 열린다.

바로 그 기분이 조심해야 할 신호이기도 하다. 공통 형태는 가설일 뿐이고, 우아함은 근거가 아니다. UI 확장의 경우에는 실제였지만, 그는 전에 속은 적이 있다.

최근 다른 사례에서 그는 Perfetto 트레이스를 조회할 때 쓰는 투명 캐싱 시스템이 큰 트레이스 공유 문제와 반복 쿼리 문제를 함께 해결한다고 확신했다. RFC를 쓰고 프로토타입을 만들면서야 그 우아함이 거짓이었음을 알았다. 두 문제는 서로 정말 다른 해결책을 원하고 있었다. 그는 아쉬운 마음으로 설계를 둘로 나눴고, 이후 양쪽 모두 출시됐다.

만들기 전에 압력을 건다

여기서 만들기 시작할 것 같지만 보통은 아니다. 얼마나 나아갈지는 아이디어가 통한다는 확신과 사람들이 실제로 그것을 원한다는 확신의 정도에 달려 있다.

• 충분히 유용하고 위험이 낮으면 바로 행동한다. 변경을 보내고 매니저에게 알린다.
• 아이디어가 통할지, 얼마나 걸릴지 불확실하면 버릴 프로토타입을 만든다. 실패 지점이 드러나고, 다른 사람들이 반응할 구체적인 물건이 생긴다.
• 아이디어가 크지만 스스로 납득했다면 전면적인 노력을 약속한다. 몇 주에서 몇 달의 작업과, 다른 엔지니어와 팀들의 지지를 쌓는 고된 구간이다.

이 과정 전체에서 그는 남을 설득하는 것만이 아니라 자신을 설득하려 한다. 때로는 멈추는 게 정직한 답이다. 사람들이 자기가 보는 가치를 보지 못하거나 큰 기술적 벽에 부딪히면, 아무도 쓰지 않을 것이나 유지보수 악몽이 될 것을 만드는 대신 지금 접는 편을 택한다. 검증은 통과했는데 시기가 틀린 경우도 있다. 그러면 조직의 우선순위가 되는 날 즉시 움직일 수 있게 세워 둔다.

아이디어가 버텨 냈다 해도 그가 만드는 사람일 필요는 없다. 자신이 구현할 수도, 팀의 다른 사람이 할 수도, 조직의 초점 자체를 바꿀 수도 있다. 올바른 문제를 찾아 형태를 잡는 일은 구현을 소유하지 않아도 영향을 남긴다.

Perfetto 확장 아이디어는 전면적인 노력을 들일 값을 했다. 팀은 이미 UI를 모듈화하는 플러그인을 만들고 있었지만 그것으로는 부족했다. 팀들이 플러그인 코드 전부를 오픈소스로 공개해야 했고, 많은 내부 사용 사례에서는 선택할 수 없는 조건이었다. 새것을 만들기 전에 그는 문제와 제안을 매니저, 팀원, 클라이언트 팀들에 가져갔다. 결과적으로 RFC를 두 편 쓰고, 1:1을 여러 번 하고, 발표를 두 번 했으며, 피드백이 들어올 때마다 다듬었다.

최종적으로 그는 매크로를 경량 확장으로 설계하고 구현했다. 플러그인을 쓰지 않고 UI 동작을 자동화하는 방법이다. 확장 서버는 팀들이 자기 매크로를 공유할 수 있게 해 그 아이디어를 한 걸음 더 밀었다. 요청받은 기능을 전부 직접 구현하는 대신, 팀들이 Perfetto를 자기 필요에 맞게 바꿀 수 있는 수단을 준 것이다. 지금 구글 내부의 수십 개 팀이 매크로와 확장 서버를 쓰고, 다른 회사 몇 곳도 확장 서버를 내부적으로 사용한다.

해결이 다음 문제를 데려온다

이 과정을 자주 지날수록 다음번이 쉬워진다. 누군가의 문제에 진심으로 관심을 보이고, 쓸 만한 질문을 하거나 해결을 도우면 상대가 기억한다. 그들은 더 이른 시점에 찾아오고, 관련 문제를 겪는 다른 사람들과의 대화에 그를 데려간다.

그러면 조직 전체에서 무슨 일이 벌어지는지에 대한 시야가 넓어지고, 패턴을 알아보기도 사람들이 실제로 필요한 것을 만들기도 쉬워진다. 그중 하나를 해결하면 더 많은 대화에 들어가고, 고리가 계속 돈다.

그런 성공은 장기적인 관리에서 오는 종류의 신뢰를 쌓는다. 초기에는 자기 판단이 건전하다는 것을 증명하기 위해 이런 아이디어의 다수를 직접 실물로 만들어야 했다. 시간이 지나며 매니저와 조직은 무엇이 중요한지에 대한 그의 평가에 더 무게를 실었다. 덕분에 모든 프로젝트를 소유하지 않고도 로드맵에 영향을 줄 수 있게 됐다.

이 그림은 스태프 엔지니어가 된다는 것이 기술 작업을 회의와 조율로 대체하는 일이라는 생각과 다르다. 그에게 대화는 만들 것의 입력이고, 결과물이 아니다.

풀 값이 있는 문제를 찾는 일은 나머지 업무와 분리돼 있지 않다. 어떤 단일 요청도 보여 줄 수 없는 것을 보게 될 만큼 오래 사람들의 일에 붙어 있는 데서 온다.

가장 흥미로운 지점

내가 가장 눈여겨본 것은 “우아함은 근거가 아니다"라는 한 마디였다. 서로 다른 요청 다섯 개가 하나의 개념으로 접히는 순간을 저자는 이 일에서 가장 좋은 기분이라 적어 놓고, 곧바로 그 기분이 위험 신호라고 덧붙인다. 캐싱 사례에서 그를 구한 것은 더 오래 생각한 것이 아니라 RFC를 쓰고 프로토타입을 만든 행위였다. 설계가 종이 위에서 갈라지는 걸 손으로 확인하고 나서야 두 문제가 다른 것을 원한다는 걸 인정했다.

또 하나는 요청 수집과 요청 수용을 완전히 분리해 놓은 구조다. 목소리 큰 팀의 간절함은 정보로 받되 우선순위로는 환산하지 않는다. 대신 같은 문제가 서로 모르는 두 팀에서 독립적으로 올라오는 사건을 우선순위의 신호로 쓴다. 한 팀이 세 번 요청하는 것보다 세 팀이 한 번씩 요청하는 것이 더 무겁다는 계산이고, 이건 기다리지 않으면 얻을 수 없는 값이다.

북마클릿으로 우회 방법을 만들어 쓰던 팀들 이야기도 오래 남는다. 그들은 요청을 남기는 대신 스스로 도구를 개조했고, 저자에게는 그게 개별 기능 요청보다 강한 증거가 됐다.

출처

Lalit Maganti, “How I Find Problems to Solve as a Staff Engineer”, 2026년 7월 25일 발행(이후 독자 피드백 반영 개정). 원문: https://lalitm.com/post/find-problems-staff-engineer/

관련 원문 링크: 저자가 언급한 Perfetto 매크로와 확장 서버 문서.

원문에 인용할 이미지가 없어 삽화는 치비 서소영 라인아트로 대체했다. 「느낌적인 느낌을 숫자로 옮기는 일」의 치비 서소영 라인아트를 참조하여 gpt-image-2 image-to-image로 생성했다.