이 글은 스태프 엔지니어가 단순히 주어진 어려운 과제를 잘 푸는 데서 나아가, 조직이 아직 명확히 인식하지 못한 중요한 문제를 발견하고 구체화하는 과정을 설명한다. 핵심은 빈 화면 앞에서 전략을 억지로 짜내는 것이 아니라, 일상 업무에서 들리는 여러 문제를 오래 관찰하고 축적한 뒤 그 공통 원인을 찾아 검증하는 데 있다. 저자는 Perfetto 사례를 통해, 여러 팀의 작은 요청을 모두 개별 기능으로 만들기보다 사용자가 직접 도구를 맞춤화할 수 있는 확장 방식을 제공한 과정을 보여 준다.

1. 스태프 엔지니어에게 필요한 문제 발견 능력

글은 최근 저자가 멘토링하던 한 시니어 엔지니어의 질문에서 시작한다. 그는 스태프 엔지니어로 성장하려면 배정받은 일만 잘 처리해서는 부족하며, 팀과 조직이 무엇을 만들어야 하는지 판단하는 과정에도 참여해야 한다는 점을 깨달았다. 그래서 "해결할 가치가 있는 문제는 어떻게 찾느냐"고 물었다.

누군가는 달력에 따로 시간을 확보해 큰 그림을 생각해 보라고 조언했지만, 그 엔지니어에게는 별 도움이 되지 않았다. 이에 저자는 자신이 좋은 문제를 찾는 방식은 '전략적으로 생각하려 애쓰는 것'과 다르다고 설명한다. 그는 자신을 스펀지처럼 행동하는 사람이라고 표현한다. 회의, 채팅, 이메일, 발표처럼 일상적으로 흘러가는 정보 속에서 사람들이 겪는 어려움을 듣고 흡수한 뒤, 머릿속 한편에 오래 두는 것이다.

"나는 빈 페이지를 바라보며 '전략적으로 생각'하려 해서 좋은 문제를 찾는 경우가 거의 없다. 대신 스펀지처럼 행동한다."

처음에는 서로 무관해 보이던 문제들이 시간이 지나며 연결되고, 일부 문제는 자연스럽게 사라진다. 그 과정 끝에 저자는 무엇이 실제로 사람들의 속도를 늦추는지, 그리고 자신이나 팀이 무엇을 할 수 있는지를 파악하게 된다.

많은 엔지니어는 관리자나 리더가 기회를 찾아 주기를 기다린 뒤, 주어진 과제 중 가장 어려운 문제를 해결하며 가치를 증명한다. 물론 이것도 승진으로 이어질 수 있다. 하지만 저자의 경력에서 가장 큰 인상을 남긴 프로젝트들은 리더조차 아직 존재를 깨닫지 못했던 중요한 문제를 스스로 찾아 해결한 일이었다.

다만 이 방식에는 전제가 있다. 저자의 경험은 대기업에서 인프라와 개발자 도구를 만들고, 엔지니어가 아래에서 위로 로드맵에 영향을 줄 수 있는 환경을 중심으로 형성됐다. 위에서 정한 계획을 따르는 성격이 강한 조직에서는 이런 방식으로 움직일 여지가 더 적을 수 있다.

2. 요청이 아니라 문제를 흡수하기

사람들은 자신이 겪는 어려움을 자주 이야기한다. 회의에서는 업무가 왜 힘든지 말하고, 채팅에서는 방해 요소를 토로하며, 이메일과 발표에서는 있었으면 하는 기능을 설명한다. 저자는 이런 말들 중 자신의 영역과 겹치는 것이 있으면 그 실마리를 더듬어 본다.

예를 들어 "X가 있으면 정말 문제가 해결될까요?"라고 묻거나, 자신이 담당하는 제품의 기존 기능을 소개한 뒤 그 기능이 상대방의 상황을 얼마나 해결해 주는지 확인한다. 중요한 점은 사용자가 대개 근본 문제보다 원하는 해결책을 먼저 요청한다는 것이다. 따라서 요청을 그대로 받아들이지 않고, 그들이 진짜로 이루려는 목적은 무엇인지, 기존 제품이 왜 충분하지 않은지를 계속 파고들어야 한다.

"사용자는 종종 자신의 근본 문제를 설명하는 대신 특정 해결책을 요청한다."

저자는 내향적인 성향이라 이런 '주변의 신호를 듣는 방식'이 특히 잘 맞는다고 말한다. 아이디어를 찾겠다는 목적으로 추측성 회의를 빽빽하게 잡을 필요가 없다. 평범한 한 주 동안에도 이미 엄청난 양의 유용한 정보가 조직 안을 흐르고 있기 때문이다.

하지만 어떤 문제가 더 살펴볼 가치가 있어 보이면, 그때부터는 능동적으로 움직인다. 해당 팀이 버그를 조사하고 업무 흐름을 따라가는 모습을 곁에서 보고, 가능하다면 자신도 그 버그를 직접 해결해 본다. 문제를 직접 경험하면 팀이 실제로 필요한 것과 그들이 요청한 해결책 사이의 차이를 더 잘 구분할 수 있다.

또한 저자는 자신보다 조직 전체를 더 넓게 보는 사람들을 찾아간다. 핵심 시스템의 담당자, 여러 팀에 걸쳐 일하는 사람, 자신의 팀 이후 단계의 업무를 깊이 이해하는 사람이 대상이다. 1:1이나 커피챗을 잡아 흥미로운 문제를 물어보면, 그들은 이미 여러 곳에서 같은 문제를 목격하고 패턴을 연결해 두었을 수도 있다. 이는 혼자였다면 한참 뒤에야 발견했을 연결고리를 앞당겨 준다.

3. 문제를 서둘러 프로젝트로 만들지 않기

저자는 과거에 너무 빨리 움직였다가 여러 번 실패했다. 목소리가 큰 한 팀의 요청에 흥분해 기능을 만들었지만, 정작 그 팀은 기능을 거의 사용하지 않았다. 팀의 우선순위가 바뀌었거나, 요청 자체가 한 번성 조사에서 비롯되어 더는 중요하지 않았기 때문이다.

그 순간 팀이 얼마나 간절해 보였는지는, 제품이 지원해야 하는 수많은 요구 가운데 그 기능이 얼마나 중요한지와는 다르다. 특정 요청에 과도하게 몰입하면 더 큰 그림을 놓치게 된다.

"그 순간 팀이 얼마나 열성적이었는지는, 내 제품이 지원해야 하는 다른 모든 것에 비해 그 기능이 얼마나 중요한지와 같지 않았다."

이 경험을 통해 저자는 잠재적 문제를 쌓아 두는 습관을 갖게 됐다. 일상적으로 듣다 보면 자신이 해결할 수 있는 것보다 훨씬 많은 문제를 발견하게 되며, 그중 대부분은 즉시 행동으로 옮길 만큼 중요하지 않다. 어떤 문제는 처음 들었을 때 바로 프로젝트가 될 필요가 없다. 저자에게 기다림은 초능력에 가깝다.

기다리는 동안 다음과 같은 증거가 생길 수 있다.

• 서로 다른 팀에서 같은 문제가 독립적으로 반복되면, 해결 우선순위가 높아진다.
• 겉보기에는 다른 문제들이 사실 같은 구조를 가졌다는 점이 드러나면, 한 번의 해결로 여러 사례를 다룰 수 있다.
• 반대로 요청했던 팀조차 그 문제를 그다지 중요하게 여기지 않았다는 사실이 드러날 수 있다.

저자는 이런 문제를 주로 머릿속에 기록해 두었다가 다시 나타나면 되짚어 본다. 다른 엔지니어들은 더 체계적으로 기록할 수도 있다. 어떤 도구를 쓰는지는 개인 취향의 문제지만, 핵심은 미해결 문제를 충분히 오래 보존해 추가 증거가 쌓일 시간을 주는 것이다.

4. 여러 요청 뒤에 숨은 공통 구조 찾기

문제를 오래 모아 두었다고 해서 곧바로 무엇을 만들어야 하는지가 정해지는 것은 아니다. 남겨 둔 문제들이 정말로 연관되어 있는지, 그리고 하나의 해결책으로 함께 다룰 수 있는지를 판단해야 한다.

저자는 자신이 개발하는 성능 디버깅 도구 Perfetto를 사례로 든다. Perfetto는 시스템 활동 기록을 시간축으로 보여 주며, 화면은 '트랙'이라는 여러 행으로 구성된다. 수년에 걸쳐 여러 팀은 저마다 작고 구체적인 UI 기능을 요청했다.

한 팀은 자신이 선호하는 트랙을 화면 상단에 고정하고 싶어 했다. 다른 팀도 같은 기능을 원했지만 고정하고 싶은 트랙의 종류는 전혀 달랐다. 또 어떤 팀은 특정 기록 구간이 확대된 상태로 Perfetto가 열리기를 바랐고, 자신들이 관심 있는 항목에 맞춘 맞춤형 집계를 원하기도 했다. 몇몇 팀은 기다리다 못해 북마클릿으로 복잡한 우회책까지 만들었다.

처음에는 이런 요청들, 각 요청의 제약 조건, 어렴풋한 해결책들이 머릿속에서 뒤엉켜 있었다. 저자는 책상에 앉아 해결책을 억지로 쥐어짜기보다, 런던을 목적 없이 오래 걸을 때 생각이 가장 잘 정리된다고 말한다. 의식적으로 해결하려 애쓰지 않을 때 오히려 연결이 더 잘 보인다는 것이다. 🚶

결국 저자가 알아낸 것은 팀들이 요청한 각각의 특정 기능이 진짜 목적이 아니었다는 점이다. 모든 팀은 자신의 선택을 다른 사용자에게 강요하지 않으면서도, 자기 업무 방식에 맞게 Perfetto를 개인화하고 싶어 했다. 즉, 핵심 요구는 트랙 고정이나 자동 확대가 아니라 UI를 확장할 수 있는 능력이었다.

"이 팀들이 정말 원한 것은 각자 요청한 특정 기능이 아니었다. 모두가 다른 사람에게 자신의 선택을 강요하지 않고, 자기 업무 방식에 맞게 Perfetto를 개인화하고 싶어 했다."

여러 어색한 요청이 하나의 아이디어로 합쳐지고, 각 요청만으로는 떠올릴 수 없었던 가능성이 열리는 순간은 매우 짜릿하다. 그러나 저자는 바로 이때 경계해야 한다고 강조한다. 공통 구조는 가설일 뿐이며, 우아한 설계라는 사실은 증거가 아니다.

그는 최근 Perfetto 트레이스를 공유하는 문제와 반복 쿼리 문제를 함께 풀기 위해, 투명한 캐싱 시스템을 만들면 된다고 확신한 적이 있다. 하지만 RFC를 작성하고 프로토타입을 만들면서 깨달았다. 두 문제는 겉으로는 하나로 묶기 좋아 보였을 뿐, 실제로는 서로 다른 해결책을 요구했다. 결국 아쉬움을 무릅쓰고 설계를 둘로 나누었고, 두 결과물 모두 이후 출시됐다.

5. 만들기 전에 가설을 압박 검증하기

공통 구조를 찾았다고 해서 바로 본격 개발에 들어가는 것은 아니다. 저자는 아이디어가 실제로 통할지, 사람들이 정말 원하는지, 구현에 얼마나 드는지에 대한 확신 정도에 따라 행동을 달리한다.

• 유용하고 위험이 낮은 일이라면 바로 변경을 적용하고 관리자에게 알린다.
• 효과나 난이도가 불확실하다면, 버려도 되는 일회성 프로토타입을 만든다. 이는 실패 지점을 드러내고 다른 사람들이 구체적인 의견을 줄 수 있게 한다.
• 아이디어가 크지만 충분한 확신이 있다면, 수주 또는 수개월의 개발과 여러 엔지니어·팀의 지지를 얻는 작업까지 감수한다.

이 검증 과정은 다른 사람을 설득하기 위한 것만이 아니라, 자기 자신을 설득하기 위한 과정이기도 하다. 사람들이 저자가 보는 가치를 보지 못하거나 큰 기술적 장벽에 부딪힌다면, 아무도 쓰지 않거나 유지보수가 악몽이 될 결과물을 만들기보다 일찍 아이디어를 접는 편이 낫다.

"사람들이 내가 보는 가치를 보지 못하거나 큰 기술적 벽에 부딪힌다면, 아무도 쓰지 않을 것을 만들기보다 지금 아이디어를 버리는 편이 낫다."

아이디어 자체는 타당하지만 타이밍이 맞지 않을 때도 있다. 이때는 폐기하기보다 보류해 두었다가 조직의 우선순위가 되는 날 행동하면 된다. 또한 문제를 잘 찾고 형태를 잡는 사람이 꼭 구현자일 필요도 없다. 본인이 만들 수도, 팀의 다른 사람이 만들 수도, 문제 발견 자체가 조직의 초점을 바꾸는 계기가 될 수도 있다.

Perfetto의 확장성 문제는 저자가 장기적인 투자를 감수할 만하다고 판단한 사례다. 당시 팀은 UI를 모듈화하기 위해 플러그인을 만들고 있었지만, 내부 사용 사례에는 한계가 있었다. 많은 팀이 플러그인 코드를 오픈소스로 공개해야 했는데, 이는 현실적으로 받아들일 수 없는 조건이었다.

그래서 저자는 새 기능을 만들기 전에 문제와 제안서를 관리자, 동료, 고객 팀에 가져갔다. 두 개의 RFC를 작성하고, 여러 차례 1:1 대화를 진행하고, 발표도 하면서 피드백에 따라 설계를 다듬었다. 그 결과 플러그인을 작성하지 않고도 UI 동작을 자동화할 수 있는 가벼운 확장 기능인 매크로(macros) 를 설계하고 구현했다. 이어서 확장 서버(extension servers) 를 통해 팀들이 자신의 매크로를 공유할 수 있게 했다.

이 접근의 핵심은 개별 기능 요청을 하나하나 직접 구현하는 대신, 각 팀이 자신의 필요에 맞게 Perfetto를 적응시킬 수단을 제공한 데 있다. 현재 Google 내부의 수십 개 팀이 매크로와 확장 서버를 사용하고 있으며, 다른 여러 회사도 내부적으로 확장 서버를 사용한다.

6. 문제 해결이 만드는 신뢰와 선순환

이 과정을 많이 반복할수록 다음 문제를 찾는 일도 쉬워진다. 누군가의 문제에 진심으로 관심을 보이고, 유용한 질문을 던지거나 해결을 도우면 사람들은 그것을 기억한다. 그러면 더 이른 단계부터 저자에게 찾아오고, 비슷한 문제를 겪는 다른 사람들과의 대화에도 참여시킨다.

그 결과 저자는 조직 전반에서 무슨 일이 일어나는지 더 넓게 볼 수 있고, 반복되는 패턴을 발견해 사람들이 실제로 필요로 하는 것을 만들 가능성도 커진다. 한 문제를 해결하면 더 많은 대화로 이어지고, 그 대화가 다시 다음 문제를 발견하게 하는 선순환이 형성된다. 🔄

이러한 성공은 장기적으로 제품과 문제를 책임지는 지속적인 관리와 돌봄에서 나오는 신뢰를 만든다. 저자는 초기에 자신의 판단이 타당하다는 것을 증명하기 위해 많은 아이디어를 직접 현실로 만들어야 했다. 시간이 흐르자 관리자와 조직은 무엇이 중요한지에 대한 그의 평가를 더 신뢰하게 됐고, 그는 모든 프로젝트를 직접 소유하지 않아도 로드맵에 영향을 미칠 수 있게 됐다.

이는 스태프 엔지니어가 되면 기술 일을 회의와 조율로 대체한다는 통념과 다르다. 저자에게 대화는 그 자체가 최종 산출물이 아니다. 대화는 무엇을 만들지 결정하기 위한 입력값이다.

"나에게 대화는 내가 만드는 것을 위한 입력이지, 최종 결과물이 아니다."

7. 마무리

저자가 멘티에게 전하고 싶었던 결론은 분명하다. 해결할 가치가 있는 문제를 찾는 일은 본업과 별개인 전략 활동이 아니다. 사람들의 실제 업무에 꾸준히 관여하고, 단일 요청만으로는 보이지 않는 반복과 연결을 충분히 오래 관찰할 때 비로소 가능한 일이다.

좋은 스태프 엔지니어십은 요청받은 일을 빠르게 구현하는 데만 있지 않다. 여러 사람의 불편과 목적을 듣고, 성급하게 결론 내리지 않으며, 공통 원인을 검증한 뒤 조직에 가장 큰 영향을 줄 문제를 찾아내는 데 있다.