Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 더 많이 짜면 승진하는가
공개된 사다리는 실제로 무엇을 재는가
네 가지 아키타입 — 당신은 어디에 서 있나
임팩트는 어떻게 "증거"가 되는가
글루 워크의 함정 — 라일리가 실제로 한 말
글쓰기가 레버리지다
정치 없이 보이기
정직한 노트 — 사다리는 노이즈가 많다
AI 시대의 각주
마치며
참고 자료

들어가며 — 더 많이 짜면 승진하는가

승진이 안 되는 엔지니어가 가장 먼저 시도하는 처방은 대개 "더 많이, 더 빨리"입니다. 티켓을 더 닫고, PR을 더 올리고, 주말에도 짭니다. 그런데 1년 뒤에도 레벨은 그대로입니다.

이유는 단순합니다. 공개된 엔지니어링 사다리 중 산출량을 축으로 두는 곳이 없기 때문입니다. 이건 추측이 아니라 문서를 열어 보면 확인되는 사실입니다. 이 글은 실제 사다리 문장, Will Larson의 스태프 엔지니어 연구, Tanya Reilly의 글루 워크 논의를 근거로 "무엇이 실제로 평가받는가"를 정리합니다.

공개된 사다리는 실제로 무엇을 재는가

progression.fyi에는 CircleCI, Dropbox, Monzo, Etsy, Spotify, Square, Rent the Runway 등 수십 개 회사의 커리어 프레임워크가 공개돼 있습니다. 문서를 나란히 놓고 보면 표현은 달라도 재는 축은 놀랄 만큼 겹칩니다.

Rent the Runway의 사다리는 가장 먼저 공개된 축에 속하고, 이후 수많은 프레임워크가 베낀 네 기둥을 세웠습니다 — "Technical Skill", "Get Stuff Done", "Impact", "Communication & Leadership".

Dropbox의 커리어 프레임워크는 더 직설적입니다. 문서는 "Dropbox measures the success of its engineers largely on business impact"라고 시작하고, 레벨 기대치를 세 축으로 정의합니다 — Scope(스코프), Collaborative Reach(협업 반경), Levers for Impact(임팩트 레버). 그리고 이렇게 못 박습니다: 이 기대치들이 "the what that determines the difference between an IC3 and IC4"라고. 스태프(IC5) 레벨의 스코프는 이렇게 적혀 있습니다 — "I deliver multi-year, multi-team product or platform goals", 그리고 "open-ended problems that require difficult prioritization, defining both the what and how". 협업 반경은 "I am increasingly influencing the roadmaps of other Dropbox teams"입니다.

CircleCI는 E1(Associate)부터 E6(Principal)까지 여섯 단계를 두는데, 레벨을 가르는 것은 임팩트가 닿는 범위입니다 — "from task to epic, team level, and onwards ... to across several teams and, ultimately, across the organization". 그리고 일의 성격 자체가 바뀝니다: 업무는 "shifts over time from execution to include facilitating, guiding, and mentoring others, whether or not they are in a management role". 문서가 드는 예시가 명료합니다. 주니어는 테스트를 짜고, 최상위 레벨은 팀들의 테스트 전략을 이끕니다. 같은 주제, 다른 레버리지.

CircleCI E1 -> E6 : 임팩트가 닿는 범위가 커진다
  task  ->  epic  ->  team  ->  several teams  ->  organization

Dropbox IC3 -> IC5 : 세 축이 함께 커진다
  Scope              내 프로젝트   ->  multi-year, multi-team goals
  Collaborative      내 팀         ->  다른 팀의 로드맵에 영향
  Levers for Impact  직접 실행     ->  전략, 판단, 롤모델

어느 사다리에도 없는 축:
  "짠 코드의 양"

여기서 정직해야 할 부분이 하나 있습니다. Rent the Runway에 "Get Stuff Done"이 엄연히 있듯, 실행력은 분명히 평가받습니다. 다만 그것은 모든 레벨의 기본값입니다. 레벨을 올려 주는 축이 아니라, 없으면 탈락하는 축입니다. 레벨 간에 실제로 달라지는 것은 스코프와 레버리지입니다. 시니어가 스태프가 되지 못하는 흔한 이유는 실행이 부족해서가 아니라, 실행이 늘 남이 정해 준 스코프 안에서만 일어나기 때문입니다.

네 가지 아키타입 — 당신은 어디에 서 있나

Will Larson은 여러 회사의 스태프 이상 엔지니어를 인터뷰해 네 가지 아키타입으로 정리했습니다.

Tech Lead — "guides the approach and execution of a particular team". 매니저와 짝을 이뤄 한 팀의 기술 방향과 실행을 이끕니다. 가장 흔하며, Larson의 관찰에 따르면 조사한 모든 회사에 존재했습니다. 대부분의 사람이 처음 도달하는 스태프의 모습입니다.
Architect — "responsible for the direction, quality, and approach within a critical area". API 설계나 인프라처럼 오래 지속되는 핵심 영역을 다년 단위로 책임집니다. 대체로 엔지니어 100명 규모를 넘어서야 생깁니다.
Solver — "digs deep into arbitrarily complex problems and finds an appropriate path forward". 조직이 지목한 난제에 깊이 파고들었다가, 해결되면 다음 화재 현장으로 옮깁니다. 지속적 소유권을 갖지 않는다는 점에서 앞의 둘과 다릅니다.
Right Hand — "extends an executive's attention, borrowing their scope and authority". 임원의 스코프와 권한을 빌려 복잡한 조직을 운영합니다. 넷 중 가장 드물고, 보통 엔지니어 1,000명 규모에서야 나타납니다.

중요한 것은 Larson이 이걸 처방이 아니라 관찰로 제시했다는 점입니다. 그는 이렇게 씁니다: "Being a Staff-engineer is not just a role, rather it's the intersection of the role, your behaviors, your impact, and the organization's recognition."

그래서 현실적인 질문은 "나는 어떤 아키타입이 되고 싶은가"가 아니라 **"지금 우리 회사에 자리가 있는 아키타입은 무엇인가"**입니다. 50명짜리 회사에서 Architect가 되려 애쓰는 것은 존재하지 않는 자리를 향해 달리는 일입니다. 반대로 팀 개념이 약한 조직이라면 Solver로 가는 길이 훨씬 넓습니다.

임팩트는 어떻게 "증거"가 되는가

여기서 사람들이 가장 크게 오해합니다. 임팩트를 만드는 것과 임팩트가 읽히는 것은 다른 일입니다. 그리고 승진은 후자에서 결정됩니다.

스코프가 큰 일은 본질적으로 흔적이 흐릿합니다. 두 팀이 6개월간 싸우던 인터페이스 논쟁을 정리했다면, 산출물은 코드 30줄과 합의 하나입니다. 커밋 로그에는 거의 남지 않습니다. 그래서 스태프 레벨의 일은 의도적으로 증거를 남기는 형태로 해야 합니다.

설계 문서와 RFC. 스태프 일의 절반은 "무엇을 만들 것인가"를 정의하는 일입니다(Dropbox의 표현대로 "defining both the what and how"). 그 정의가 문서로 남으면, 그것이 곧 당신이 그 레벨의 판단을 했다는 증거입니다.
장애 대응 리더십. 인시던트 커맨더를 맡고, 포스트모템을 쓰고, 재발 방지 항목을 끝까지 닫는 일. 조직이 가장 취약한 순간에 누가 방향을 잡았는지는 모두가 기억합니다.
멘토링과 리뷰. Dropbox의 IC5 항목에는 "I serve as a role model for other Dropbox engineers"가 명시돼 있습니다. 남의 코드를 좋게 만드는 것은 취미가 아니라 사다리 항목입니다.
팀 간 언블로킹. 다른 팀의 로드맵에 영향을 준 순간들을 기록해 두십시오. 그게 Dropbox가 말하는 협업 반경 그 자체입니다.

그리고 이 모든 것의 정점에 StaffEng가 말하는 "스태프 프로젝트"가 있습니다. 정의는 이렇습니다 — "complex and important enough that the person who completes it has proven themselves as a Staff engineer". 특징은 셋입니다: 처음엔 스코프가 엉망이고("poorly scoped but complex and important"), 이해관계자가 여럿이며 서로 갈라져 있고, 리더십이 전사 미팅에서 언급할 만큼 눈에 띕니다. 성공도 실패도 모두가 봅니다.

글루 워크의 함정 — 라일리가 실제로 한 말

Tanya Reilly의 "Being Glue"는 이 주제에서 가장 자주 인용되고, 가장 자주 오독되는 글입니다.

글루 워크란 온보딩, 멘토링, 남을 언블로킹하기, 팀 간 합의 끌어내기, 문서 쓰기, 설계 리뷰 — 아무도 시키지 않았지만 없으면 프로젝트가 무너지는 일들입니다. 오독은 여기서 시작됩니다. Reilly는 "글루 워크를 하지 말라"고 말한 적이 없습니다. 그는 글루 워크가 프로젝트의 성패를 가른다고 말합니다.

그의 실제 논점은 두 가지입니다.

첫째, 분배와 가시성의 문제. 승진에 도움이 안 되는 이 일들은 특정 사람들에게 불균등하게 쏠립니다(특히 여성에게). 그리고 정작 평가 시즌에는 "technical accomplishment가 부족하다"는 말을 듣습니다. Reilly는 이 "not technical enough"라는 피드백을 게이트키핑이자 실행 불가능한 말이라고 잘라 말합니다. 무엇을 하라는 것인지 알 수 없기 때문입니다.

둘째, 대체의 문제. 그의 가장 유명한 문장이 이것입니다: "If you only do glue, you will only get better at glue." 핵심은 only입니다. 글루 워크가 기술적 깊이를 보완하면 그것이 바로 스태프의 모습이고, 기술적 깊이를 대체하면 그것은 커리어의 막다른 길입니다.

그의 처방도 낭만적이지 않습니다. 매니저와 승진 요건을 명시적으로 합의하고, 하는 일에 걸맞은 직함을 요구하고, 증거가 되는 산출물을 남기라는 것. 그리고 그래도 안 되면 — 글루를 잠시 내려놓고 측정 가능한 기술적 결과물을 만들라는 것입니다. "Stop being the unofficial lead." 공식 리드가 아니라면, 공식 리드의 일을 무료로 해 주지 말라는 뜻입니다.

그리고 이건 매니저와 동료를 향한 말이기도 합니다. Reilly는 글루 워크를 하는 사람을 공개적으로 인정하되, "도와줘서 고맙다"가 아니라 이끌었다고 말하라고 합니다: "publicly give them credit! And not for helping, but for leading."

글쓰기가 레버리지다

Reilly의 책 The Staff Engineer's Path는 스태프의 일을 세 기둥으로 나눕니다 — 큰 그림 보기(big picture), 프로젝트 실행(execution), 남을 성장시키기(leveling up). 그리고 이 셋은 기술적 토대 위에 서야 한다고 못 박습니다.

이 세 기둥을 하나로 관통하는 도구가 글쓰기입니다. 이유는 레버리지 때문입니다. 회의에서의 설득은 그 방에 있는 사람에게만 닿고 한 시간 뒤 증발합니다. 잘 쓴 설계 문서는 당신이 자는 동안에도 설득하고, 6개월 뒤 합류한 사람에게도 설득하고, 당신이 그 방에 없을 때도 설득합니다. 스코프가 팀을 넘어가는 순간 — 즉 스태프의 정의 그 자체인 순간 — 당신은 모든 방에 있을 수 없습니다. 문서만 갈 수 있습니다.

그래서 코드도 같은 원리로 씁니다. 읽는 사람을 위해 쓴 코드가 레버리지를 만든다는 이야기는 AI가 코드를 유지보수해도 사람을 위해 쓴다 편에 따로 정리했습니다.

정치 없이 보이기

"보이는 것"을 정치와 동의어로 여기는 엔지니어가 많습니다. 그래서 아무 말도 하지 않고, 아무도 모르는 채로 승진에서 밀립니다.

구분은 간단합니다. 정치는 없는 임팩트를 있어 보이게 만드는 일이고, 가시성은 있는 임팩트를 읽히게 만드는 일입니다. 후자는 정직한 노동이며, 사실 당신을 평가하는 사람에 대한 배려이기도 합니다. 그들은 당신의 6개월을 대신 재구성할 시간이 없습니다.

StaffEng의 승진 가이드가 반복하는 항목도 결국 이것입니다 — 스폰서 찾기, 결정이 내려지는 방에 들어가서 남아 있기, 승진 패킷 쓰기, 스태프 프로젝트 맡기. 여기서 스폰서는 아첨의 대상이 아니라, 당신이 없는 방에서 당신의 일을 정확히 설명해 줄 수 있는 사람입니다. 그가 그러려면 당신의 일을 정확히 알아야 합니다. 그것을 알려 주는 것은 정치가 아니라 업무입니다.

실무적으로는 이 정도면 충분합니다. 결정 사항은 문서로 남기고, 남긴 문서는 관련자에게 실제로 보내고, 성과는 팀의 이름으로 말하되 당신이 한 판단은 분명히 밝히는 것. 그리고 6개월마다 스스로의 승진 패킷을 미리 써 보십시오. 쓸 게 없다면, 그것이 바로 지금 알아야 할 사실입니다.

정직한 노트 — 사다리는 노이즈가 많다

여기까지 읽고 사다리를 정밀한 측정 도구로 오해하면 곤란합니다.

사다리는 회사마다 다릅니다. progression.fyi에 모인 프레임워크들은 레벨 수도, 축의 이름도, 강조점도 제각각입니다. Larson의 관찰대로 Architect는 엔지니어 100명, Right Hand는 1,000명 규모에서야 등장합니다. 즉 똑같은 사람이 A사에서는 시니어, B사에서는 스태프일 수 있습니다. 이건 당신에 대한 평가가 아니라 조직 구조에 대한 사실입니다.

운도 큽니다. StaffEng는 스태프 프로젝트를 얻는 조건 중 하나를 솔직하게 인정합니다 — "your company having a pressing need to solve a Staff-level problem, which can require some patience". 회사에 스태프급 문제가 없으면 스태프급 증거를 만들 수 없습니다. 여기에 경영진이 당신에게 베팅할 의향까지 겹쳐야 합니다.

그러니 레벨을 자아로 삼지 마십시오. 통제할 수 있는 것은 스코프를 넓히는 습관과 증거를 남기는 습관이고, 통제할 수 없는 것은 타이밍입니다. 다만 앞의 둘을 갖춘 사람은, 기회가 왔을 때 준비돼 있습니다.

AI 시대의 각주

코드 산출이 값싸지는 중입니다. 예전에는 한 주가 걸리던 구현이 하루로 줄었고, 그 격차는 더 벌어질 것입니다.

여기서 오해하기 쉬운 결론은 "그러니 엔지니어의 가치가 떨어진다"입니다. 사다리를 다시 보면 이야기가 달라집니다. 이미 어떤 사다리도 산출량을 재고 있지 않았습니다. 사다리가 재던 것은 모호한 문제를 스코프로 바꾸는 능력("defining both the what and how"), 여러 팀에 걸친 판단, 무엇을 만들지 않을지 정하는 결정이었습니다. 그리고 그것들은 지금의 모델이 대신해 주지 않는 축입니다. 오히려 구현이 싸질수록, 잘못된 것을 훌륭하게 구현하는 비용이 눈에 띄게 커집니다.

부작용도 있습니다. AI는 새로운 글루 함정을 만듭니다. 문서도, 요약도, 프로토타입도 빠르게 찍어 낼 수 있으니 바빠 보이기가 그 어느 때보다 쉽습니다. 활동량과 스코프는 다르다는 원칙은 그대로입니다. 오히려 더 냉정하게 물어야 합니다 — 이 산출물은 누구의 결정을 바꿨는가.

낯선 환경에서 모호한 문제를 스코프로 바꿔 내는 능력이 왜 갈수록 비싸지는지는 Forward Deployed Engineer 준비기에서 다른 각도로 다뤘습니다.

마치며

정리하면 이렇습니다. 승진은 산출량이 아니라 스코프와 레버리지입니다. 실행력은 입장권이고, 레벨을 올리는 것은 임팩트가 닿는 범위입니다. 아키타입은 처방이 아니라 지도이니, 우리 회사에 실제로 존재하는 자리를 보십시오. 임팩트는 만드는 것으로 끝나지 않고 읽혀야 하니 증거를 남기십시오. 글루 워크는 필수지만 기술적 깊이를 대체하는 순간 함정이 됩니다. 그리고 사다리는 노이즈가 많으니, 레벨을 자아로 삼지 마십시오.

가장 정직한 조언 하나만 남긴다면 이것입니다. 다음 분기에 "무엇을 더 짤까"를 묻지 말고, **"지금 아무도 소유하지 않은 중요한 문제가 무엇인가"**를 물으십시오. 그 질문에 답하고 그 답을 문서로 남기는 습관이, 어떤 회사의 어떤 사다리에서도 통하는 유일한 것입니다.