시니어 엔지니어에서 스태프 엔지니어로 성장

시니어 엔지니어에서 스태프 엔지니어(Staff Engineer)로 역할이 확장될 때 가장 크게 달라지는 점 중 하나는 주어진 문제를 잘 푸는 것만으로는 충분하지 않다는 것이다.

스태프 레벨에서는 한 단계 더 나아가야 한다.

우리 팀과 조직이 지금 무엇을 해결해야 하는가?

Lalit Maganti가 자신의 글 How I Find Problems to Solve as a Staff Engineer에서 설명하는 핵심도 바로 여기에 있다.

그가 강조하는 방식은 의외로 단순하다.

회의실에 앉아 억지로 “전략적인 아이디어”를 만들어내는 것이 아니다.

조직에서 매일 발생하는 문제를 지속적으로 관찰하고, 충분한 시간 동안 축적한 뒤, 서로 다른 문제 사이에서 공통된 구조(Common Shape)를 발견하는 것이다.

---

1. 전략은 빈 문서에서 시작되지 않는다

많은 엔지니어가 스태프 엔지니어가 되면 일정 시간을 따로 확보해 다음과 같은 질문을 고민해야 한다고 생각한다.

• 우리 조직의 가장 중요한 문제는 무엇인가?
• 다음 분기에 무엇을 만들어야 하는가?
• 어떤 프로젝트를 제안해야 하는가?

하지만 Maganti는 이런 방식으로 좋은 문제를 찾는 경우가 거의 없다고 말한다.

대신 자신을 스펀지처럼 만든다.

일상적인 업무 속에서 흘러다니는 정보를 계속 흡수한다.

예를 들어 다음과 같은 곳이다.

• 회의
• Slack이나 사내 채팅
• 이메일
• 발표
• 장애 대응
• 버그 분석
• 다른 팀의 불만
• 개발자가 사용하는 우회 방법
• 반복적으로 발생하는 운영 문제

처음 들었을 때는 별것 아닌 문제처럼 보일 수 있다.

하지만 바로 해결하려 하지 않고 머릿속에 남겨두면 시간이 지나면서 일부 문제는 사라지고, 일부 문제는 다른 문제와 연결되기 시작한다.

그리고 어느 순간 이런 질문을 할 수 있게 된다.

“이 문제들이 사실은 같은 원인에서 발생하는 것 아닐까?”

스태프 엔지니어의 문제 발견 능력은 여기서 시작된다.

---

2. 요청(Request)이 아니라 문제(Problem)를 수집한다

사용자는 자신의 문제를 항상 정확하게 설명하지 않는다.

대부분은 문제 대신 해결책을 요청한다.

예를 들어 사용자가 이렇게 말할 수 있다.

“이 버튼을 화면 위쪽에 고정할 수 있게 해주세요.”

이때 그대로 기능 요구사항으로 받아들이면 다음과 같은 구현이 시작된다.

Request
↓
버튼 고정 기능
↓
개발
↓
배포

하지만 스태프 엔지니어는 한 단계 더 들어간다.

Request
↓
왜 필요한가?
↓
어떤 작업을 하려고 하는가?
↓
현재 방식은 왜 불편한가?
↓
다른 팀도 같은 문제가 있는가?
↓
Root Problem

질문도 달라진다.

“왜 이 기능이 필요한가요?”

“지금은 이 작업을 어떻게 하고 있나요?”

“이 기능이 생기면 어떤 문제가 해결되나요?”

“기존 기능으로는 어느 정도까지 해결할 수 있나요?”

요청을 구현하는 것과 문제를 이해하는 것은 완전히 다른 활동이다.

스태프 엔지니어에게 더 중요한 것은 후자다.

---

3. 직접 워크플로를 관찰한다

문제가 중요해 보이면 Maganti는 단순히 인터뷰만 하지 않는다.

실제 사용자가 문제를 겪는 과정을 직접 본다.

예를 들어 개발팀이 특정 디버깅 문제를 이야기한다면 옆에 앉아서 다음 과정을 확인한다.

Bug 발생
↓
로그 검색
↓
Trace 분석
↓
특정 데이터 찾기
↓
도구 설정 변경
↓
반복 작업
↓
원인 발견

가능하면 자신도 같은 버그를 직접 분석해 본다.

이런 관찰이 중요한 이유는 사용자가 말한 문제와 실제 문제가 다를 수 있기 때문이다.

사용자는

“필터 기능이 필요합니다.”

라고 말하지만 실제로 관찰해 보면 필요한 것은

“매번 같은 분석 환경을 다시 만드는 작업을 없애는 것”

일 수도 있다.

즉,

Requested Solution ≠ Actual Need

일 가능성이 상당히 높다.

---

4. 조직을 넓게 보는 사람에게서 신호를 얻는다

자신이 경험한 문제만 관찰해서는 조직 전체의 패턴을 발견하기 어렵다.

그래서 Maganti는 다음과 같은 사람들과 의도적으로 이야기한다고 설명한다.

• 핵심 시스템 담당자
• 여러 팀을 지원하는 엔지니어
• 플랫폼 엔지니어
• 인프라 엔지니어
• downstream 시스템을 잘 아는 사람
• 여러 조직의 문제를 반복해서 접하는 사람

이들은 일종의 Problem Router 역할을 한다.

한 팀에서는

Problem A

로 보였던 것이 다른 팀에서는

Problem B

처럼 나타날 수 있다.

하지만 여러 팀을 보는 사람은 이미 이렇게 인식하고 있을 수 있다.

Team A → Problem A ┐
Team B → Problem B ├→ Root Problem X
Team C → Problem C ┘

스태프 엔지니어에게 조직 내 네트워크가 중요한 이유도 단순히 정치적 영향력을 얻기 위해서가 아니다.

더 많은 문제 신호에 접근하기 위해서다.

---

5. 문제를 바로 프로젝트로 만들지 않는다

여기서 중요한 원칙이 하나 나온다.

문제를 충분히 쌓이게 둔다.

Maganti는 과거 특정 팀의 요청에 너무 빨리 반응했다가 실패했던 경험을 소개한다.

어떤 팀이 특정 기능을 강하게 원했다.

그래서 기능을 만들었다.

하지만 정작 배포했을 때 거의 사용하지 않았다.

그 사이 팀의 우선순위가 바뀌었거나, 애초에 일회성 조사 때문에 필요했던 기능이었기 때문이다.

이 경험에서 중요한 구분이 나온다.

요청의 강도 ≠ 문제의 중요도

누군가 매우 적극적으로 요구한다고 해서 반드시 중요한 문제는 아니다.

그래서 문제를 처음 발견했을 때 바로 개발 프로젝트로 만들지 않는다.

대신 일종의 Problem Backlog에 넣어둔다.

---

6. 문제에도 증거가 누적되어야 한다

시간이 지나면서 같은 문제가 다시 나타나는지 본다.

예를 들어 처음에는 이렇게 보인다.

Team A → Problem A

몇 달 뒤 다른 팀에서도 나타난다.

Team A → Problem A
Team B → Problem A

다른 형태로 또 나타난다.

Team C → Problem B

조금 더 분석해 보면 사실 이런 구조일 수 있다.

Problem A ┐
Problem A ├→ Root Problem X
Problem B ┘

이때부터 문제의 중요도가 올라간다.

즉 문제의 우선순위는 단순한 목소리의 크기가 아니라 증거의 누적으로 결정된다.

이를 간단하게 모델링하면 다음과 같이 생각할 수도 있다.

Problem Priority
=
Frequency
× Number of Teams
× Severity
× Strategic Relevance

정확한 공식이 중요한 것이 아니다.

핵심은 문제를 처음 발견한 순간보다 반복해서 발견되는 패턴을 중요하게 보는 것이다.

---

7. 가장 중요한 순간: Common Shape 찾기

Maganti가 설명하는 과정에서 가장 중요한 단계가 있다.

여러 문제의 공통된 형태를 발견하는 것

Perfetto 사례가 이를 잘 보여준다.

Perfetto는 시스템의 동작 기록을 타임라인으로 분석하는 성능 디버깅 도구다.

여러 팀이 다음과 같은 기능을 요청했다.

Team A
→ 특정 Track을 항상 위에 고정하고 싶다.

Team B
→ 다른 Track을 고정하고 싶다.

Team C
→ 특정 위치로 자동 Zoom하고 싶다.

Team D
→ 특정 Aggregation을 자동으로 보고 싶다.

Team E
→ Bookmarklet으로 직접 자동화하고 있다.

겉으로 보면 모두 다른 기능이다.

그래서 하나씩 대응하면 이런 제품이 된다.

Feature A
Feature B
Feature C
Feature D
Feature E
...

하지만 충분히 문제를 쌓아놓고 보면 공통점이 나타난다.

각 팀이 원한 것은 개별 기능이 아니었다.

각자의 업무 방식에 맞게 Perfetto를 개인화하고 확장할 수 있는 능력이었다.

즉 문제의 구조가 바뀐다.

Track 고정 ┐
Auto Zoom  │
Aggregation├→ UI 확장성
Automation │
Bookmarklet┘

이것이 Common Shape다.

---

8. 좋은 플랫폼은 기능을 대신 만들어주지 않는다

이 통찰은 플랫폼 엔지니어링에서 특히 중요하다.

첫 번째 접근은 다음과 같다.

Team A 요청 → Platform Team 개발
Team B 요청 → Platform Team 개발
Team C 요청 → Platform Team 개발
Team D 요청 → Platform Team 개발

이 구조에서는 플랫폼 팀이 병목이 된다.

요청이 늘어날수록 유지보수 비용도 계속 증가한다.

반면 공통 문제를 발견하면 구조가 달라진다.

Team A ┐
Team B │
Team C ├→ Extension Platform
Team D │
Team E ┘

플랫폼팀이 모든 기능을 구현하는 대신 다른 팀이 자신의 요구를 해결할 수 있는 Primitive를 제공한다.

Maganti가 Perfetto에서 도달한 방향도 이런 형태였다.

글에 따르면 그는 이후 UI 동작을 자동화할 수 있는 Macros와 이를 팀 간 공유할 수 있는 Extension Servers를 설계했다.

즉,

Build Features

에서

Build Capability

로 문제의 추상화 수준이 올라간 것이다.

이 차이는 매우 크다.

---

9. 그러나 ‘멋진 추상화’는 증거가 아니다

여기서 위험한 함정이 하나 있다.

엔지니어는 우아한 설계를 좋아한다.

여러 문제를 하나의 구조로 설명할 수 있는 순간 이런 생각이 들기 쉽다.

“찾았다.”

하지만 Maganti는 경고한다.

공통된 구조는 어디까지나 가설이다.

즉,

Elegant Architecture ≠ Correct Problem

이다.

그가 소개한 또 다른 Perfetto 사례에서는 대용량 trace 공유 문제와 반복 query 문제를 하나의 투명한 캐시 시스템으로 해결하려 했다.

처음에는 두 문제를 하나로 해결하는 매우 우아한 설계처럼 보였다.

하지만 RFC와 프로토타입을 만들면서 실제로는 서로 다른 문제라는 사실이 드러났다.

결국 글에 따르면 해결책은 분리됐다.

Repeated Query
→ Warm Session

Large Trace Reopen
→ Streaming Table Export

이 사례에서 중요한 것은 추상화를 사랑하지 않는 태도다.

엔지니어가 만든 개념보다 실제 문제가 더 중요하다.

---

10. 구현 전에 Pressure Test 한다

Common Shape을 발견했다고 바로 개발하지 않는다.

다음 단계는 가설 검증이다.

Maganti는 상황에 따라 세 가지 방식으로 접근한다고 설명한다.

① 작고 안전한 문제

바로 구현한다.

Low Risk
+
Clear Value
↓
Ship

② 불확실한 문제

버려도 되는 프로토타입을 만든다.

Hypothesis
↓
Throwaway Prototype
↓
Feedback
↓
Technical Risk
↓
Decision

프로토타입의 목적은 제품을 만드는 것이 아니다.

틀렸다는 사실을 싸게 발견하는 것이다.

③ 크지만 확신이 높은 문제

RFC, 설계 검토, 조직 설득까지 들어간다.

Problem
↓
Evidence
↓
Proposal
↓
RFC
↓
1:1
↓
Presentation
↓
Feedback
↓
Refinement
↓
Implementation

스태프 엔지니어의 중요한 역할 중 하나가 바로 이 단계다.

---

11. 스스로의 아이디어도 설득해야 한다

Pressure Test의 목적은 다른 사람을 설득하는 것만이 아니다.

자신도 설득해야 한다.

다음 질문을 계속 던져야 한다.

이 문제가 정말 중요한가?

여러 팀에게 발생하는가?

기존 도구로 해결할 수 없는가?

우리가 해결해야 하는 문제인가?

기술적으로 가능한가?

유지보수 비용은 감당할 수 있는가?

지금 해결해야 하는가?

그 결과 프로젝트를 포기할 수도 있다.

그것은 실패가 아니다.

오히려 큰 시스템을 만들기 전에 잘못된 가설을 제거한 것이다.

---

12. 타이밍이 틀렸다면 문제를 버리지 않는다

좋은 아이디어라도 조직의 현재 우선순위와 맞지 않을 수 있다.

이 경우 바로 실행하지 않고 보관한다.

Good Problem
+
Wrong Timing
↓
Park

그리고 환경이 바뀌면 다시 꺼낸다.

Org Priority Change
↓
Existing Problem Evidence
↓
Ready Proposal
↓
Fast Execution

이것은 스태프 레벨에서 상당히 중요한 능력이다.

항상 새로운 아이디어를 만드는 것이 아니라 이미 충분히 연구된 문제를 적절한 순간에 실행하는 것이다.

---

13. 반드시 자신이 구현할 필요는 없다

스태프 엔지니어의 영향력은 코드량으로 측정되지 않는다.

문제를 발견하고 구조화한 뒤 다른 팀이 구현하게 만들 수도 있다.

Problem Discovery
↓
Problem Framing
↓
Solution Direction
↓
Org Alignment
↓
Another Engineer Implements

이 경우에도 상당한 기술적 영향력을 만들어낼 수 있다.

스태프 엔지니어의 역할은

I built X

에서 점차

X became the right thing for the organization to build

로 확대된다.

---

14. 문제 해결은 새로운 문제를 가져오는 플라이휠을 만든다

이 과정에는 흥미로운 네트워크 효과가 있다.

누군가의 문제를 진지하게 듣고 실제로 해결해 주면 사람들이 기억한다.

그러면 다음번에는 문제가 더 일찍 공유된다.

문제 발견
↓
좋은 질문
↓
문제 해결
↓
신뢰 증가
↓
더 많은 문제 공유
↓
조직 가시성 증가
↓
더 좋은 문제 발견

즉 하나의 Problem Discovery Flywheel이 만들어진다.

Listen
  ↓
Understand
  ↓
Solve
  ↓
Trust
  ↓
More Signals
  ↓
Better Patterns
  ↓
Better Problems
  ↺

경력이 올라갈수록 스태프 엔지니어가 중요한 문제를 더 빨리 발견하는 이유도 단순히 경험이 많기 때문만은 아니다.

조직 안에서 문제 신호가 그 사람에게 모이기 시작하기 때문이다.

---

15. Staff Engineer의 핵심 루프

전체 내용을 하나의 루프로 압축하면 다음과 같다.

① Listen
조직의 문제를 듣는다
        ↓
② Dig
요청 뒤의 실제 문제를 파고든다
        ↓
③ Observe
실제 워크플로를 본다
        ↓
④ Accumulate
문제를 바로 해결하지 않고 축적한다
        ↓
⑤ Connect
반복되는 문제 사이의 연결을 찾는다
        ↓
⑥ Abstract
Common Shape을 발견한다
        ↓
⑦ Pressure Test
인터뷰·RFC·Prototype으로 검증한다
        ↓
⑧ Build / Park / Kill
구현하거나 보류하거나 폐기한다
        ↓
⑨ Earn Trust
문제를 해결하면서 신뢰를 만든다
        ↓
⑩ More Signals
더 많은 문제 정보가 들어온다
        ↺

이 루프가 반복될수록 개인의 영향력은 커진다.

---

16. Senior와 Staff의 차이

이 글의 관점에서 Senior Engineer와 Staff Engineer의 차이를 단순화하면 다음과 같이 볼 수 있다.

Senior EngineerStaff Engineer

어려운 문제를 해결한다	어떤 문제를 해결해야 하는지 찾는다
주어진 프로젝트를 성공시킨다	프로젝트 자체를 만든다
요구사항을 구현한다	요구사항 뒤의 문제를 찾는다
한 팀의 문제를 본다	여러 팀의 패턴을 본다
Feature를 만든다	Capability를 만든다
Implementation 중심	Problem Framing 중심
프로젝트 영향	조직 영향

물론 실제 조직마다 역할 정의는 다르다.

특히 Maganti 자신도 글에서 자신의 경험이 Google과 같은 대규모 조직의 인프라·개발자 도구 팀처럼 엔지니어의 bottom-up 자율성이 큰 환경에 기반한다고 전제한다.

따라서 모든 회사에서 동일한 방식으로 적용된다고 볼 수는 없다.

---

17. 이 접근법을 실제 업무 시스템으로 만들면

이 방법은 개인의 직관에만 의존할 필요가 없다.

간단한 Problem Discovery System으로 구조화할 수 있다.

예를 들어 문제를 발견할 때 다음 정보를 기록한다.

Problem
 ├─ Source
 ├─ Team
 ├─ Context
 ├─ Requested Solution
 ├─ Actual Problem
 ├─ Frequency
 ├─ Severity
 ├─ Workaround
 ├─ Similar Problems
 ├─ Evidence
 └─ Status

그리고 상태를 관리한다.

Observed
↓
Repeated
↓
Pattern Found
↓
Investigating
↓
Validated
↓
Proposed
↓
Building
↓
Solved

핵심은 아이디어 관리가 아니라 문제 관리다.

일반적인 아이디어 백로그가

What should we build?

을 기록한다면,

Problem Backlog는

What keeps hurting people?

을 기록한다.

제품팀이나 플랫폼팀이라면 후자가 훨씬 강력한 자산이 될 수 있다.

---

결론

이 글에서 가장 중요한 메시지는 “스태프 엔지니어는 전략 회의를 많이 해야 한다”가 아니다.

오히려 반대에 가깝다.

좋은 전략적 문제는 일상적인 업무와 분리된 곳에서 갑자기 등장하지 않는다.

사람들의 불편
+
반복되는 작업
+
우회 방법
+
여러 팀의 요청
+
기술적 제약
+
시간

이것들이 충분히 축적될 때 중요한 패턴이 보이기 시작한다.

그리고 스태프 엔지니어의 역할은 그 수많은 신호 속에서

“서로 다른 문제처럼 보이지만 사실 같은 문제다.”

라는 순간을 발견하는 것이다.

결국 스태프 엔지니어의 핵심 경쟁력은 단순히 더 어려운 코드를 작성하는 능력만이 아니다.

문제를 수집하고, 문제를 기다리고, 문제를 연결하고, 올바른 추상화 수준에서 문제를 다시 정의하는 능력.

그 능력이 개인의 기술적 영향력을 팀에서 조직으로 확장시킨다.