<div id="readability-page-1" class="page"><div>
    <article>
        

        <div>
            

<h2 id="원문-정보">원문 정보</h2>

<blockquote>
  <ul>
    <li><strong>제목</strong>: the senior engineer death spiral</li>
    <li><strong>출처</strong>: Sunil Pai (<a href="https://sunilpai.dev/">https://sunilpai.dev</a>)</li>
    <li><strong>발행</strong>: 2026-09-19 · 약 5~7분 분량</li>
    <li><strong>원문 링크</strong>: <a href="https://sunilpai.dev/posts/the-senior-engineer-death-spiral/">https://sunilpai.dev/posts/the-senior-engineer-death-spiral/</a></li>
  </ul>
</blockquote>

<p>시니어로 올라선 직후가 오히려 커리어에서 가장 위험한 구간일 수 있다는, 짧지만 뼈아픈 에세이다. 기술 얘기가 아니라 일하는 방식과 심리에 관한 글이라 <code>Career-Life</code>에 담는다.</p>

<h2 id="한-줄-요약-tldr">한 줄 요약 (TL;DR)</h2>

<p>고성과 엔지니어는 승진이나 큰 프로젝트를 맡는 순간 “조용히 사라졌다가 거대한 결과물로 한 번에 증명하겠다”는 함정에 빠지기 쉽고, 이 패턴은 번아웃·PIP·퇴사로 끝난다. 해독제는 반대 방향에 있다 — 일을 공개하고, 잠시 레벨을 낮춰 팀을 돕고, 결과가 아닌 모멘텀에 집중해 신뢰를 쌓으면 큰 기회는 자연히 따라온다.</p>

<h2 id="왜-이-글을-골랐나">왜 이 글을 골랐나</h2>

<p>이 글이 그리는 패턴은 특정 회사나 특정 사람의 이야기가 아니라, 실력 있는 엔지니어일수록 더 잘 빠지는 구조적 함정이다. “요즘 뭘 못 보여줬으니 더 열심히 해야 한다”는 자책은 성실한 사람의 언어처럼 들리지만, 실제로는 고립과 침묵을 정당화하는 소용돌이의 입구다. 특히 리모트 환경에서 일하는 사람, 최근 승진했거나 큰 프로젝트를 새로 맡은 사람에게는 자기 진단 체크리스트로 쓸 수 있는 글이다. 이 위키의 <a href="/2026/07/06/team-success-individual-success.html">팀이 성공해야 개인이 성공한다</a>가 리더 관점에서 본 구조 설계라면, 이 글은 같은 문제를 개인(IC) 관점에서 뒤집어 본다.</p>

<p>글의 척추는 같은 출발점에서 갈라지는 두 갈래 흐름이다.</p>

<pre><code>flowchart TB
    A["큰 역할 부여&lt;br/&gt;(승진 · 대형 프로젝트)"] --&gt; B{"어떻게 증명할 것인가"}

    B --&gt;|"조용히 사라져&lt;br/&gt;한 방으로"| S1["침묵 · 잠수&lt;br/&gt;(몇 주간 업데이트 없음)"]
    S1 --&gt; S2["'더 열심히 해야 해'&lt;br/&gt;자책 · 기대치 상승"]
    S2 -.-&gt;|"증명 부채&lt;br/&gt;복리 증가"| S1
    S2 --&gt; S3["영웅적 몰아치기&lt;br/&gt;(수면 부족 · 고립)"]
    S3 --&gt; S4["번아웃 → PIP&lt;br/&gt;→ 해고 / 퇴사"]

    B --&gt;|"일을 공개하고&lt;br/&gt;모멘텀으로"| T1["일 공개&lt;br/&gt;(share your work)"]
    T1 --&gt; T2["일시적 레벨 낮추기&lt;br/&gt;(궂은일 · 정리 · 문서)"]
    T2 --&gt; T3["일일 습관 · 모멘텀&lt;br/&gt;(작고 꾸준한 전진)"]
    T3 --&gt; T4["신뢰 축적"]
    T4 --&gt; T5["더 큰 기회가&lt;br/&gt;자연히 온다"]
    T5 -.-&gt;|"선순환"| T1
</code></pre>

<h2 id="핵심-내용">핵심 내용</h2>

<h3 id="죽음의-소용돌이--패턴의-해부">죽음의 소용돌이 — 패턴의 해부</h3>

<p>글의 출발점은 역설이다. 소용돌이에 빠지는 사람은 저성과자가 아니라 <strong>고성과자</strong>다. 승진하거나 중요한 프로젝트를 맡은 엔지니어가 “이번엔 제대로 보여주겠다”며 몇 주씩 업데이트 없이 사라지고, 그 공백을 나중에 영웅적인 몰아치기(heroic catch-up)로 메우려 한다.</p>

<p>이 침묵을 지탱하는 것은 심리적 합리화다. 원문은 그 내면의 목소리를 이렇게 옮긴다.</p>

<blockquote>
  <p>“they’re telling themselves, ‘oh my god, I haven’t really shipped anything in a while. what I need to do is work harder.’”</p>
</blockquote>

<p>“한동안 뭘 못 냈으니 더 열심히 해야 한다”는 생각은 침묵을 더 길게 만들고, 나중에 내놓을 결과물의 기대치를 스스로 더 높인다. 그 대가는 수면 부족, 거른 끼니, 우울, 관계 손상으로 이어지고, 최악의 경우 번아웃 → PIP(performance improvement plan) → 해고 또는 자진 퇴사로 끝난다.</p>

<h3 id="리모트-워크가-소용돌이를-증폭시킨다">리모트 워크가 소용돌이를 증폭시킨다</h3>

<p>원문은 이 패턴이 현대 근무 환경에서 특히 위험해졌다고 본다. 옆자리에서 일하며 자연스럽게 상태가 공유되던 시절과 달리, 리모트 환경에는 근접성이 만들어주던 어카운터빌리티가 없다.</p>

<blockquote>
  <p>“you don’t really have the same structure of working next to someone and being given Jira tasks, etc.”</p>
</blockquote>

<p>구조가 없으니 잠수는 아무도 눈치채지 못한 채 길어지고, 문제는 파국적인 시점에야 드러난다.</p>

<h3 id="해독제-1--선의를-가정하고-일을-공개하라">해독제 1 — 선의를 가정하고, 일을 공개하라</h3>

<p>첫 번째 처방은 태도의 전환이다. 동료들이 선의로 움직인다고 가정하고(assume good faith), 내 작업의 가시성을 높게 유지하는 것. 원문은 이것이 자기 PR과는 다르다고 선을 긋는다 — “요란하게 굴 필요는 없다. 일을 공유하면 된다(you have to share your work).”</p>

<p>여기서 저자는 자기 증명 강박의 뿌리를 찌르는 문장을 남긴다.</p>

<blockquote>
  <p>“they hired you for you. they didn’t hire you for who you think you’re going to be in six months.”</p>
</blockquote>

<p>회사는 6개월 뒤의 이상적인 나를 고용한 게 아니라 지금의 나를 고용했다. 지금의 나를 숨길 이유가 없다는 것이다.</p>

<h3 id="해독제-2--전략적으로-레벨을-낮춰라">해독제 2 — 전략적으로 레벨을 낮춰라</h3>

<p>두 번째 처방은 직관에 반한다. 원하는 시니어 레벨을 연기(performing)하는 대신, 일시적으로 지원자 역할로 내려가라는 것 — 원문의 표현으로는 “grunt work, organizational stuff, write-ups”(궂은일, 조직 정리, 문서 작업)이다. 화려하지 않지만 매일 눈에 보이는 기여가 침묵의 공백을 메우고, 팀과의 접점을 회복시킨다.</p>

<h3 id="해독제-3--결과가-아니라-모멘텀">해독제 3 — 결과가 아니라 모멘텀</h3>

<p>세 번째 처방이 글의 축이다.</p>

<blockquote>
  <p>“you want to move away from an outcome-based mindset to momentum-based.”</p>
</blockquote>

<p>거대한 결과물 하나로 승부하는 사고에서, 매일의 습관이 만드는 복리적 전진으로 옮겨가라는 것이다. 큰 프로젝트에 대한 저자의 정의가 이를 압축한다.</p>

<blockquote>
  <p>“big projects are not done with big efforts. it’s a big marathon, just slow, steady, incremental work.”</p>
</blockquote>

<h3 id="신뢰가-기회를-연다">신뢰가 기회를 연다</h3>

<p>이 셋이 맞물리면 선순환이 시작된다. 꾸준한 신뢰성과 좋은 관계가 쌓이면, 매니저는 자연스럽게 더 큰 일을 맡긴다. 글의 결론은 소프트웨어 엔지니어의 정체성 자체를 재정의한다.</p>

<blockquote>
  <p>“you are in the reputation-building business, and software is actually downstream of that.”</p>
</blockquote>

<p>우리는 평판을 쌓는 업에 종사하고 있으며, 소프트웨어는 그 하류(downstream)에 있다는 것이다.</p>

<h2 id="분석과-인사이트">분석과 인사이트</h2>

<h3 id="증명-부채는-이자가-복리로-붙는다">“증명 부채”는 이자가 복리로 붙는다</h3>

<p>이 글에서 가장 날카로운 관찰은 소용돌이의 연료가 게으름이 아니라 <strong>성실함의 왜곡</strong>이라는 점이다. “못 보여줬으니 더 크게 보여줘야 한다”는 심리는 일종의 증명 부채다 — 침묵이 길어질수록 갚아야 할 기대치가 커지고, 기대치가 커질수록 어중간한 중간 공유가 더 부끄러워져 침묵이 또 길어진다. 부채의 이자가 복리로 붙는 구조라서, 빠져나오는 유일한 방법은 “지금의 어중간한 상태”를 일찍, 싸게 공개하는 것뿐이다. 이는 소프트웨어 공학이 오래 말해온 원칙 — 작은 배치(small batch), 짧은 피드백 루프 — 의 심리 버전이기도 하다. 큰 배치가 코드에서 위험하듯, 큰 배치의 자기 증명은 커리어에서 위험하다.</p>

<h3 id="리모트-시대의-가시성은-성과-연기가-아니라-인프라다">리모트 시대의 가시성은 ‘성과 연기’가 아니라 인프라다</h3>

<p>“일을 공유하라”는 조언은 자칫 사내 정치나 셀프 브랜딩으로 오독되기 쉽다. 하지만 저자가 말하는 가시성은 과시가 아니라 팀이 나를 도울 수 있게 만드는 인터페이스에 가깝다. 진행 상황이 보여야 매니저가 장애물을 치워줄 수 있고, 동료가 방향 오류를 일찍 잡아줄 수 있다. 잠수는 겸손이 아니라 팀의 도움 받을 권리를 스스로 차단하는 행위다. <a href="/2026/08/18/engineering-leaders-day-to-day.html">엔지니어링 리더의 하루</a>에서 봤듯 매니저의 일 자체가 정보 수집과 공유의 사이클이라는 점을 생각하면, 정보를 끊는 IC는 매니저의 업무 자체를 불가능하게 만드는 셈이다.</p>

<h3 id="동의하지만-레벨-낮추기에는-단서가-필요하다">동의하지만, ‘레벨 낮추기’에는 단서가 필요하다</h3>

<p>“일시적으로 궂은일·정리·문서 작업으로 내려가라”는 처방에는 대체로 동의한다. 신뢰가 바닥난 상태에서 신뢰를 다시 쌓는 가장 빠른 통화는 작고 확실한 납품이기 때문이다. 다만 이것이 상시 전략이 되면 다른 함정 — 시니어가 잡무 처리자로 고착되는 — 으로 이어질 수 있다. 원문도 “temporarily”라고 못 박고 있지만, 실무에서는 이 기간에 출구 조건(신뢰가 회복됐다는 신호가 무엇인지)을 매니저와 명시적으로 합의해 두는 편이 안전하다고 본다. 그리고 시니어에서 그 이상으로 가는 진짜 전환은 결국 <a href="/2026/07/31/problem-framing-principal-engineer.html">문제를 정의하는 능력</a>에서 오므로, 궂은일 기간에도 문제 정의 근육은 계속 쓰는 것이 좋다.</p>

<h3 id="소프트웨어는-평판의-하류라는-명제의-무게">“소프트웨어는 평판의 하류”라는 명제의 무게</h3>

<p>마지막 인용은 냉소적으로 들릴 수 있지만, <a href="/2026/06/22/surviving-in-the-job-market.html">노동시장에서 살아남기</a>가 말한 “시장의 벤더로서의 개발자”와 정확히 같은 결론에 도달한다. 벤더의 자산은 개별 납품물이 아니라 “이 사람에게 맡기면 된다”는 신뢰의 총량이고, 코드 품질은 그 신뢰를 만드는 여러 입력 중 하나일 뿐이다. 기술적 탁월함으로 커리어의 모든 문제를 돌파하려는 태도가 시니어 이후 구간에서 자주 벽에 부딪히는 이유가 여기에 있다.</p>

<h2 id="적용-포인트">적용 포인트</h2>

<ul>
  <li><strong>침묵 상한선을 정하라.</strong> 이틀 이상 진행 상황을 아무에게도 공유하지 않았다면, 그것 자체를 경보로 취급한다. 완성도와 무관하게 “지금 여기까지, 다음은 이것”을 공유한다.</li>
  <li><strong>“더 열심히”가 떠오르면 “더 공개하라”로 치환하라.</strong> “한동안 못 보여줬으니 더 열심히”라는 생각이 드는 순간이 소용돌이의 입구다. 처방은 노동량 증가가 아니라 가시성 증가다.</li>
  <li><strong>큰 프로젝트를 맡으면 데모/공유 주기부터 설계하라.</strong> 산출물 계획보다 커뮤니케이션 계획(주간 업데이트, 중간 데모, 진행 로그)을 먼저 세운다.</li>
  <li><strong>신뢰 회복 구간에는 작고 확실한 납품을 택하라.</strong> 문서화, 정리, 리뷰 같은 “지루하지만 매일 보이는” 기여로 접점을 복구한다 — 단, 기간과 출구 조건을 명시한다.</li>
  <li><strong>결과 목표를 모멘텀 목표로 번역하라.</strong> “분기 내 시스템 X 완성” 대신 “매일 리뷰 가능한 단위 하나 머지”처럼, 매일 판정 가능한 습관으로 바꾼다.</li>
  <li><strong>6개월 뒤의 나를 연기하지 마라.</strong> 지금의 나로 고용됐다는 사실을 받아들이면, 모르는 것을 묻고 어중간한 것을 공유하는 비용이 급격히 낮아진다.</li>
</ul>

<h2 id="마무리">마무리</h2>

<p>이 글의 미덕은 번아웃을 의지나 체력의 문제가 아니라 일하는 구조의 문제로 다시 그려낸다는 데 있다. 잠수 후 영웅적 한 방은 실력이 부족해서가 아니라, “결과로 한 번에 증명하겠다”는 사고방식 자체가 만드는 예측 가능한 실패다. 해독제 — 일을 공개하고, 필요하면 잠시 내려가고, 결과 대신 모멘텀을 관리하는 것 — 는 화려하지 않지만, 시니어 이후의 커리어가 결국 평판이라는 복리 자산 위에 서 있다는 점을 받아들이면 가장 합리적인 전략이 된다. 큰 프로젝트는 큰 노력이 아니라 긴 마라톤으로 끝난다.</p>

<h3 id="더-읽어보기">더 읽어보기</h3>

<ul>
  <li><a href="https://sunilpai.dev/posts/the-senior-engineer-death-spiral/">원문 — the senior engineer death spiral (Sunil Pai)</a></li>
  <li><a href="/2026/07/06/team-success-individual-success.html">팀이 성공해야 개인이 성공한다</a> — 같은 문제(압박 vs 구조)를 리더 관점에서 본 짝글</li>
  <li><a href="/2026/06/22/surviving-in-the-job-market.html">노동시장이라는 게임에서 살아남기</a> — “평판의 하류에 소프트웨어가 있다”와 같은 결론에 도달하는 시장 관점</li>
  <li><a href="/2026/08/18/engineering-leaders-day-to-day.html">엔지니어링 리더의 하루는 무엇으로 채워지는가</a> — 가시성이 왜 매니저 업무의 전제 조건인지</li>
  <li><a href="/2026/07/31/problem-framing-principal-engineer.html">모호한 의견에서 본질을 찾기: 문제 정의와 Principal Engineer의 사고 방식</a> — ‘레벨 낮추기’ 기간에도 놓지 말아야 할 근육</li>
</ul>

        </div>

        
    </article>

    
</div></div>

Orc’s WIKI

Orc Hwang

원문 정보
제목: the senior engineer death spiral
출처: Sunil Pai (https://sunilpai.dev)
발행: 2026-09-19 · 약 5~7분 분량
원문 링크: https://sunilpai.dev/posts/the-senior-engineer-death-spiral/
시니어로 올라선 직후가 오히려 커리어에서 가장 위험한 구간일 수 있다는, 짧지만 뼈아픈 에세이다. 기술 얘기가 아니라 일하는 방식과 심리에 관한 글이라 Career-Life에 담는다.
한 줄 요약 (TL;DR)
고성과 엔지니어는 승진이나 큰 프로젝트를 맡는 순간 “조용히 사라졌다가 거대한 결과물로 한 번에 증명하겠다”는 함정에 빠지기 쉽고, 이 패턴은 번아웃·PIP·퇴사로 끝난다. 해독제는 반대 방향에 있다 — 일을 공개하고, 잠시 레벨을 낮춰 팀을 돕고, 결과가 아닌 모멘텀에 집중해 신뢰를 쌓으면 큰 기회는 자연히 따라온다.
왜 이 글을 골랐나
이 글이 그리는 패턴은 특정 회사나 특정 사람의 이야기가 아니라, 실력 있는 엔지니어일수록 더 잘 빠지는 구조적 함정이다. “요즘 뭘 못 보여줬으니 더 열심히 해야 한다”는 자책은 성실한 사람의 언어처럼 들리지만, 실제로는 고립과 침묵을 정당화하는 소용돌이의 입구다. 특히 리모트 환경에서 일하는 사람, 최근 승진했거나 큰 프로젝트를 새로 맡은 사람에게는 자기 진단 체크리스트로 쓸 수 있는 글이다. 이 위키의 팀이 성공해야 개인이 성공한다가 리더 관점에서 본 구조 설계라면, 이 글은 같은 문제를 개인(IC) 관점에서 뒤집어 본다.
글의 척추는 같은 출발점에서 갈라지는 두 갈래 흐름이다.
flowchart TB
    A["큰 역할 부여<br/>(승진 · 대형 프로젝트)"] --> B{"어떻게 증명할 것인가"}
    B -->|"조용히 사라져<br/>한 방으로"| S1["침묵 · 잠수<br/>(몇 주간 업데이트 없음)"]
    S1 --> S2["'더 열심히 해야 해'<br/>자책 · 기대치 상승"]
    S2 -.->|"증명 부채<br/>복리 증가"| S1
    S2 --> S3["영웅적 몰아치기<br/>(수면 부족 · 고립)"]
    S3 --> S4["번아웃 → PIP<br/>→ 해고 / 퇴사"]
    B -->|"일을 공개하고<br/>모멘텀으로"| T1["일 공개<br/>(share your work)"]
    T1 --> T2["일시적 레벨 낮추기<br/>(궂은일 · 정리 · 문서)"]
    T2 --> T3["일일 습관 · 모멘텀<br/>(작고 꾸준한 전진)"]
    T3 --> T4["신뢰 축적"]
    T4 --> T5["더 큰 기회가<br/>자연히 온다"]
    T5 -.->|"선순환"| T1
핵심 내용
죽음의 소용돌이 — 패턴의 해부
글의 출발점은 역설이다. 소용돌이에 빠지는 사람은 저성과자가 아니라 고성과자다. 승진하거나 중요한 프로젝트를 맡은 엔지니어가 “이번엔 제대로 보여주겠다”며 몇 주씩 업데이트 없이 사라지고, 그 공백을 나중에 영웅적인 몰아치기(heroic catch-up)로 메우려 한다.
이 침묵을 지탱하는 것은 심리적 합리화다. 원문은 그 내면의 목소리를 이렇게 옮긴다.
“they’re telling themselves, ‘oh my god, I haven’t really shipped anything in a while. what I need to do is work harder.’”
“한동안 뭘 못 냈으니 더 열심히 해야 한다”는 생각은 침묵을 더 길게 만들고, 나중에 내놓을 결과물의 기대치를 스스로 더 높인다. 그 대가는 수면 부족, 거른 끼니, 우울, 관계 손상으로 이어지고, 최악의 경우 번아웃 → PIP(performance improvement plan) → 해고 또는 자진 퇴사로 끝난다.
리모트 워크가 소용돌이를 증폭시킨다
원문은 이 패턴이 현대 근무 환경에서 특히 위험해졌다고 본다. 옆자리에서 일하며 자연스럽게 상태가 공유되던 시절과 달리, 리모트 환경에는 근접성이 만들어주던 어카운터빌리티가 없다.
“you don’t really have the same structure of working next to someone and being given Jira tasks, etc.”
구조가 없으니 잠수는 아무도 눈치채지 못한 채 길어지고, 문제는 파국적인 시점에야 드러난다.
해독제 1 — 선의를 가정하고, 일을 공개하라
첫 번째 처방은 태도의 전환이다. 동료들이 선의로 움직인다고 가정하고(assume good faith), 내 작업의 가시성을 높게 유지하는 것. 원문은 이것이 자기 PR과는 다르다고 선을 긋는다 — “요란하게 굴 필요는 없다. 일을 공유하면 된다(you have to share your work).”
여기서 저자는 자기 증명 강박의 뿌리를 찌르는 문장을 남긴다.
“they hired you for you. they didn’t hire you for who you think you’re going to be in six months.”
회사는 6개월 뒤의 이상적인 나를 고용한 게 아니라 지금의 나를 고용했다. 지금의 나를 숨길 이유가 없다는 것이다.
해독제 2 — 전략적으로 레벨을 낮춰라
두 번째 처방은 직관에 반한다. 원하는 시니어 레벨을 연기(performing)하는 대신, 일시적으로 지원자 역할로 내려가라는 것 — 원문의 표현으로는 “grunt work, organizational stuff, write-ups”(궂은일, 조직 정리, 문서 작업)이다. 화려하지 않지만 매일 눈에 보이는 기여가 침묵의 공백을 메우고, 팀과의 접점을 회복시킨다.
해독제 3 — 결과가 아니라 모멘텀
세 번째 처방이 글의 축이다.
“you want to move away from an outcome-based mindset to momentum-based.”
거대한 결과물 하나로 승부하는 사고에서, 매일의 습관이 만드는 복리적 전진으로 옮겨가라는 것이다. 큰 프로젝트에 대한 저자의 정의가 이를 압축한다.
“big projects are not done with big efforts. it’s a big marathon, just slow, steady, incremental work.”
신뢰가 기회를 연다
이 셋이 맞물리면 선순환이 시작된다. 꾸준한 신뢰성과 좋은 관계가 쌓이면, 매니저는 자연스럽게 더 큰 일을 맡긴다. 글의 결론은 소프트웨어 엔지니어의 정체성 자체를 재정의한다.
“you are in the reputation-building business, and software is actually downstream of that.”
우리는 평판을 쌓는 업에 종사하고 있으며, 소프트웨어는 그 하류(downstream)에 있다는 것이다.
분석과 인사이트
“증명 부채”는 이자가 복리로 붙는다
이 글에서 가장 날카로운 관찰은 소용돌이의 연료가 게으름이 아니라 성실함의 왜곡이라는 점이다. “못 보여줬으니 더 크게 보여줘야 한다”는 심리는 일종의 증명 부채다 — 침묵이 길어질수록 갚아야 할 기대치가 커지고, 기대치가 커질수록 어중간한 중간 공유가 더 부끄러워져 침묵이 또 길어진다. 부채의 이자가 복리로 붙는 구조라서, 빠져나오는 유일한 방법은 “지금의 어중간한 상태”를 일찍, 싸게 공개하는 것뿐이다. 이는 소프트웨어 공학이 오래 말해온 원칙 — 작은 배치(small batch), 짧은 피드백 루프 — 의 심리 버전이기도 하다. 큰 배치가 코드에서 위험하듯, 큰 배치의 자기 증명은 커리어에서 위험하다.
리모트 시대의 가시성은 ‘성과 연기’가 아니라 인프라다
“일을 공유하라”는 조언은 자칫 사내 정치나 셀프 브랜딩으로 오독되기 쉽다. 하지만 저자가 말하는 가시성은 과시가 아니라 팀이 나를 도울 수 있게 만드는 인터페이스에 가깝다. 진행 상황이 보여야 매니저가 장애물을 치워줄 수 있고, 동료가 방향 오류를 일찍 잡아줄 수 있다. 잠수는 겸손이 아니라 팀의 도움 받을 권리를 스스로 차단하는 행위다. 엔지니어링 리더의 하루에서 봤듯 매니저의 일 자체가 정보 수집과 공유의 사이클이라는 점을 생각하면, 정보를 끊는 IC는 매니저의 업무 자체를 불가능하게 만드는 셈이다.
동의하지만, ‘레벨 낮추기’에는 단서가 필요하다
“일시적으로 궂은일·정리·문서 작업으로 내려가라”는 처방에는 대체로 동의한다. 신뢰가 바닥난 상태에서 신뢰를 다시 쌓는 가장 빠른 통화는 작고 확실한 납품이기 때문이다. 다만 이것이 상시 전략이 되면 다른 함정 — 시니어가 잡무 처리자로 고착되는 — 으로 이어질 수 있다. 원문도 “temporarily”라고 못 박고 있지만, 실무에서는 이 기간에 출구 조건(신뢰가 회복됐다는 신호가 무엇인지)을 매니저와 명시적으로 합의해 두는 편이 안전하다고 본다. 그리고 시니어에서 그 이상으로 가는 진짜 전환은 결국 문제를 정의하는 능력에서 오므로, 궂은일 기간에도 문제 정의 근육은 계속 쓰는 것이 좋다.
“소프트웨어는 평판의 하류”라는 명제의 무게
마지막 인용은 냉소적으로 들릴 수 있지만, 노동시장에서 살아남기가 말한 “시장의 벤더로서의 개발자”와 정확히 같은 결론에 도달한다. 벤더의 자산은 개별 납품물이 아니라 “이 사람에게 맡기면 된다”는 신뢰의 총량이고, 코드 품질은 그 신뢰를 만드는 여러 입력 중 하나일 뿐이다. 기술적 탁월함으로 커리어의 모든 문제를 돌파하려는 태도가 시니어 이후 구간에서 자주 벽에 부딪히는 이유가 여기에 있다.
적용 포인트
침묵 상한선을 정하라. 이틀 이상 진행 상황을 아무에게도 공유하지 않았다면, 그것 자체를 경보로 취급한다. 완성도와 무관하게 “지금 여기까지, 다음은 이것”을 공유한다.
“더 열심히”가 떠오르면 “더 공개하라”로 치환하라. “한동안 못 보여줬으니 더 열심히”라는 생각이 드는 순간이 소용돌이의 입구다. 처방은 노동량 증가가 아니라 가시성 증가다.
큰 프로젝트를 맡으면 데모/공유 주기부터 설계하라. 산출물 계획보다 커뮤니케이션 계획(주간 업데이트, 중간 데모, 진행 로그)을 먼저 세운다.
신뢰 회복 구간에는 작고 확실한 납품을 택하라. 문서화, 정리, 리뷰 같은 “지루하지만 매일 보이는” 기여로 접점을 복구한다 — 단, 기간과 출구 조건을 명시한다.
결과 목표를 모멘텀 목표로 번역하라. “분기 내 시스템 X 완성” 대신 “매일 리뷰 가능한 단위 하나 머지”처럼, 매일 판정 가능한 습관으로 바꾼다.
6개월 뒤의 나를 연기하지 마라. 지금의 나로 고용됐다는 사실을 받아들이면, 모르는 것을 묻고 어중간한 것을 공유하는 비용이 급격히 낮아진다.
마무리
이 글의 미덕은 번아웃을 의지나 체력의 문제가 아니라 일하는 구조의 문제로 다시 그려낸다는 데 있다. 잠수 후 영웅적 한 방은 실력이 부족해서가 아니라, “결과로 한 번에 증명하겠다”는 사고방식 자체가 만드는 예측 가능한 실패다. 해독제 — 일을 공개하고, 필요하면 잠시 내려가고, 결과 대신 모멘텀을 관리하는 것 — 는 화려하지 않지만, 시니어 이후의 커리어가 결국 평판이라는 복리 자산 위에 서 있다는 점을 받아들이면 가장 합리적인 전략이 된다. 큰 프로젝트는 큰 노력이 아니라 긴 마라톤으로 끝난다.
더 읽어보기
원문 — the senior engineer death spiral (Sunil Pai)
팀이 성공해야 개인이 성공한다 — 같은 문제(압박 vs 구조)를 리더 관점에서 본 짝글
노동시장이라는 게임에서 살아남기 — “평판의 하류에 소프트웨어가 있다”와 같은 결론에 도달하는 시장 관점
엔지니어링 리더의 하루는 무엇으로 채워지는가 — 가시성이 왜 매니저 업무의 전제 조건인지
모호한 의견에서 본질을 찾기: 문제 정의와 Principal Engineer의 사고 방식 — ‘레벨 낮추기’ 기간에도 놓지 말아야 할 근육

시니어 엔지니어의 죽음의 소용돌이 — ‘잠수 후 영웅적 한 방’이 커리어를 무너뜨리는 방식

댓글