기술 시리즈 15편의 종착: 사람
지난 14편은 시스템·언어·런타임·AI에 관한 것이었다. 이 글은 **그 기술을 다루는 사람**에 관한 것이다.
기술의 반감기는 짧다. 2020년에 쓴 Angular.js 지식은 2025년엔 거의 가치 없다. 그러나 **기술을 배우는 방식**, **문제를 푸는 태도**, **동료와 협업하는 원칙**은 반감기가 길다. 심지어 AI가 코드를 대신 쓰는 시대엔 이 '메타 레이어'의 가치가 더 커진다.
이 글의 주제:
- 실제 생산성의 구조
- 시니어·스태프·프린시팔의 실체
- AI 시대 학습 전략
- 번아웃 없이 오래 가는 법
- 기술자의 재무 상식
Part 1 — "10배 엔지니어"의 해체
신화의 출처
1968년 "Exploratory Experimental Studies Comparing Online and Offline Programming Performance" 연구에서 개발자 간 생산성 차이 **최대 28배** 관찰. 이후 "10배 엔지니어"라는 표현이 굳어짐.
오해
- "10배 엔지니어는 타이핑 속도가 10배 빠르다" — **거짓**.
- "10배 엔지니어는 버그 없이 코드를 쓴다" — **거짓**.
- "10배 엔지니어는 혼자서 다 한다" — **실제론 정반대**.
실제 관찰
시니어들이 보여주는 공통 특성:
1. **문제 정의를 더 잘한다** — 코드 작성 전에 올바른 문제를 찾는다.
2. **"하지 않기로 결정"을 잘한다** — 불필요한 일을 제거한다.
3. **레버리지 포인트를 본다** — 한 번의 투자로 팀 전체 속도 10% 올리는 일.
4. **더 많이 읽는다** — 쓰는 만큼 읽는다.
5. **빠르게 "틀렸음"을 인정한다** — 매몰 비용에 약하지 않다.
6. **동료를 레벨업시킨다** — 자기 산출물 X 1이 아니라 팀 전체 X 1.1이 된다.
**10배 엔지니어는 "코드 10배 작성자"가 아니라 "팀 산출 10배 증폭기"다.**
Part 2 — Deep Work — 코딩 집중력의 과학
Cal Newport의 주장
*Deep Work* (2016):
"**깊은 몰입 상태에서의 1시간이, 산만한 상태의 4시간보다 가치 있다.**"
방해의 비용
- **Task Switch Cost**: 연구에 따르면 10-20분.
- **Slack 알림 1개 = 15분 집중력 손실**.
- **회의 2번 연달아 = 그 사이 1시간은 잔해**.
Maker's Schedule vs Manager's Schedule
Paul Graham (2009):
- **Maker** (엔지니어): 반나절 이상 이어지는 블록이 필요.
- **Manager**: 30분 단위 회의로 하루 구성 가능.
**같은 캘린더에서 이 둘이 섞이면 Maker가 항상 진다.** 해결:
- 회의를 오후에 몰기.
- "집중 블록"을 달력에 예약.
- Slack을 하루 3-4번만 확인.
2024-2025 AI 시대의 Deep Work
"AI가 잡무를 처리하니 Deep Work 시간 늘어날 것" → 부분적 참.
그러나 **AI와의 대화 자체가 얕은 작업**이 될 수 있음. Cursor·Copilot과 쉴 새 없이 주고받기만 하면, 결과적으로 사고의 깊이는 얕아진다.
권장:
- AI로 초안·자동화 → 사람이 깊이 검토.
- "LLM 출력이 왜 맞는지/틀린지 설명할 수 있어야" 학습에 도움.
- 주 1-2회는 **AI 없이 코드 작성** — 근육이 약해지지 않도록.
Part 3 — 레벨 프레임 — 시니어·스태프·프린시팔
Will Larson의 스태프 엔지니어 원형 (Staff Engineer, 2021)
4가지 원형:
1. **Tech Lead** — 팀 하나의 기술 방향. 1명의 시니어 매니저와 짝.
2. **Architect** — 여러 팀에 영향 주는 아키텍처 결정.
3. **Solver** — 난제가 생기면 투입되는 해결사. 팀 소속 불명확.
4. **Right Hand** — 임원의 오른팔. 전략·실행·대리.
레벨별 구분
| 레벨 | 스코프 | 판단 | 영향력 |
|---|---|---|---|
| Junior | 단일 티켓 | 지침 필요 | 자기 코드 |
| Mid | 기능 단위 | 자율 | 자기 코드 + 팀 일부 |
| Senior | 프로젝트 | 설계 책임 | 팀 산출물 |
| Staff | 여러 팀 | 기술 전략 | 조직 산출물 |
| Principal | 전체 회사 | 비즈니스 연결 | 회사 방향성 |
스태프 레벨로 올라가는 신호
- 코드 작성 시간이 줄어들고 **문서·리뷰·조정**이 늘어난다.
- "이 시스템을 어떻게 만들까"에서 "**우리가 이걸 만들어야 하는가**"로 질문이 바뀐다.
- 팀 경계를 넘어 기술 방향 제시.
- **"없어선 안 될 사람"에서 "결정권자"**로.
"기술적 리더십"의 함정
- 더 이상 코드를 안 쓰면 **현실감 상실**.
- 권력 없는 영향력만 있을 때 좌절.
- 정치 기술 없으면 큰 변화를 못 만든다.
**해결책:** 주 20-30%는 여전히 코딩. 정치 기술은 조직 심리학 책을 읽어라.
Part 4 — AI 시대의 학습
바뀌지 않은 것
- **기초 지식의 가치** — 분산 시스템, DB, 알고리즘, OS. 이 시리즈가 다룬 모든 것.
- **독해력** — 논문·코드베이스를 이해하는 능력.
- **글쓰기** — 생각의 명확성이 글에 나타난다.
- **커뮤니케이션·협상·피드백** — AI가 대신할 수 없는 것.
바뀐 것
- **단순 암기의 가치 하락** — API 문서를 외우지 않아도 된다.
- **Boilerplate 작성의 가치 하락** — LLM이 빠르게 생성.
- **빠른 탐색·실험의 비용 급락** — 한 주 일이 하루에.
- **"멀티 언어 엔지니어"가 자연스러워짐** — 컨텍스트 전환 비용 감소.
AI로 학습하는 법
**해야 할 것:**
- 개념 설명을 LLM에게 요청, **그 설명을 의심**하면서 읽기.
- 코드를 LLM에게 분석시키고, **내 이해와 비교**.
- 새 기술을 LLM과 페어로 작은 프로젝트로 시도.
- 내 글을 LLM에 리뷰시킴.
**하지 말아야 할 것:**
- LLM 출력을 이해 없이 복붙.
- 기초 없이 고급으로 바로.
- **"AI가 다 해줘서 나는 몰라도 된다"** — 위험한 착각.
T자형 지식의 중요성
- **가로**: 넓은 시스템 이해 (이 시리즈에서 시도한 영역).
- **세로**: 한 영역의 깊은 전문성.
AI 시대에 가로는 AI가 빠르게 보충 가능. 세로는 여전히 사람의 몫.
Part 5 — 코드 리뷰의 경제학
수치로 본 효과
- 버그 수정 비용: 개발 단계 < 리뷰 < QA < 프로덕션 = **1 : 5 : 25 : 125**.
- **리뷰는 가장 싼 버그 발견 수단**.
좋은 리뷰의 조건
1. **24시간 내 리뷰** — 그 이상 지연되면 컨텍스트 상실.
2. **작은 PR** — 400줄 이상이면 리뷰 품질 급락.
3. **구체적 피드백** — "이상해요" 말고 "X 함수의 Y 경우가 처리 안 됩니다".
4. **감정 분리** — 코드에 대한 비판은 사람에 대한 비판 X.
5. **리뷰어도 배운다** — 좋은 PR을 읽는 것도 학습.
리뷰 문화 구축
- PR 템플릿 — 맥락, 테스트, 배포 영향.
- 리뷰 할당 자동화(CODEOWNERS).
- "한 번 승인 최소 2명" 같은 정책은 규모에 맞춰.
AI 코드 리뷰
2024-2025년 GitHub Copilot Code Review, Graphite, CodeRabbit, Greptile.
- 자동 스타일·단순 버그 체크.
- 인간 리뷰어는 **아키텍처·설계·비즈니스 맥락**에 집중.
- **단, AI 제안을 맹신 X** — 프로덕션 오염 위험.
Part 6 — 리모트 워크의 원칙
비동기 우선
- "모두가 같은 시간에 온라인"이 안 된다고 가정.
- **문서 > 회의**.
- 결정은 문서로 남긴다. Slack 메시지는 휘발.
문서의 복리
시니어 엔지니어의 **가장 큰 레버리지는 글쓰기**. 한 번 쓰면 반복해서 읽힌다.
- RFC / ADR (Architecture Decision Record) 문화.
- 설계 문서 템플릿.
- 포스트모텀 의무화.
회의의 ROI
회의 = 시간 × 인원 × 시급. 6명 1시간 회의 = 개발자 하루 비용.
**의무:** 안건 문서, 30분 이하, 결정 문서화.
Part 7 — 번아웃 없이 오래 가기
번아웃의 실체
- **신체적 에너지**만 있는 게 아님.
- **인지 에너지** — 복잡한 코드를 이해하는 능력.
- **정서적 에너지** — 동료와 협업하는 능력.
- **의지 에너지** — 어려운 결정을 내리는 능력.
이 네 가지 중 하나라도 고갈되면 번아웃으로 향한다.
경고 신호
- 주말에 월요일이 두렵다.
- 피드백에 과도하게 상처.
- "나는 쓸모없어"라는 생각.
- 수면 질 저하.
- 취미에 흥미 상실.
예방
1. **에너지 회복의 의도적 시간** — 운동, 수면, 취미.
2. **일의 '끝'이 있는 구조** — 반복 가능한 데일리 루틴.
3. **거절의 연습** — 모든 요청을 받으면 번아웃 보장.
4. **일과 자아 분리** — 코드가 깨져도 나는 깨지지 않는다.
5. **멘토·동료 네트워크** — 고립이 번아웃을 가속.
장기 커리어 관점
"빠르게 성장해 빠르게 소진"보다 "적당한 속도로 20년"이 대부분 더 멀리 간다.
**실제 최고 엔지니어들의 공통점**: 30대 후반 이후에도 여전히 학습 곡선이 꺾이지 않음. 이는 체력·정신 건강의 장기 투자가 있었기 때문.
Part 8 — 기술 블로깅과 강연 — 복리 투자
왜 블로그를 쓰는가
- **학습의 공고화** — 가르치는 것이 가장 빠른 학습.
- **포트폴리오** — GitHub 리포 50개보다 좋은 글 10개.
- **네트워크** — 같은 주제에 관심 있는 사람이 찾아온다.
- **기회** — 외부 회사 채용 제안, 컨퍼런스 초청.
블로그의 복리
한 번 쓴 글이 5년간 읽힌다. 누적 독자 수가 시간 X 글 수에 비례.
**시작 팁:**
- 처음엔 **자기 학습 노트** 수준이어도 OK.
- 빈도가 질보다 중요(초기 1년).
- **SEO**: 구체적 오류 메시지, 도구 이름을 제목에.
- 플랫폼: GitHub Pages, Next.js + MDX, Hashnode, Medium(덜 추천).
컨퍼런스 강연
- 작은 미팅업부터 시작.
- **같은 주제로 글 → 사내 발표 → 로컬 밋업 → 컨퍼런스**로 단계.
- 준비 비용은 크지만 이후 기회의 폭은 비례하게 커진다.
오픈소스 기여
- 유명 프로젝트에 큰 PR보다, **매일 쓰는 도구에 작은 개선**.
- 2024년 기준 GitHub "star" 다는 데 드는 시간 0. 실제 코드 PR이 가치.
- 유지보수자의 번아웃을 이해하고, 친절하게 소통.
Part 9 — 재무 상식 — 엔지니어가 꼭 알아야 할 것
스톡옵션 기본
- **ISO vs NSO** (미국): 세금 처리 다름.
- **Vesting 4년, 1년 cliff** — 표준.
- **Strike Price**: 옵션 행사가. 낮을수록 좋다.
- **Exit 없으면 모두 종이** — 유동화 어려움.
- **사퇴 시 90일 행사 기한** → 2020년대 상당수 회사가 10년으로 연장.
총 보상 계산
- **Base + Bonus + Equity + 복지** 총합을 봐라.
- Equity는 회사 가치 전망이 전부. 현재 valuation으로 나누면 상한.
연봉 협상
- **오퍼 받고 24시간 기다려라** — 즉답 금물.
- **경쟁 오퍼가 최고의 레버리지**.
- **Base vs Equity vs Bonus 분배 협상 가능**.
- **Signing bonus + relocation**은 거의 확실히 협상 가능.
401k / IRA / 퇴직연금
나라별 다르지만 공통: **세제 혜택 계좌를 최대한 채워라**. 매년 한도를 놓치면 복리 손실이 커진다.
긴급 예비금
**6개월 생활비**를 유동 자산으로. 해고·번아웃 시 여유를 준다.
세금
- 프리랜서 활동 시 세무 기본 지식 필수.
- 스톡옵션 행사·매각 시 **세금 계산을 행사 전에** 해라. 후에는 늦다.
Part 10 — 시리즈의 마침 — 15편을 돌아보며
이 시리즈는 Python 3.13부터 시작해 Core Web Vitals, PostgreSQL, Functional Programming, Kubernetes, Observability, WebAssembly, Edge Computing, CI/CD, Security, Distributed Systems, Database Internals, Messaging, Frontend State, Web Security 공격/방어, Network Engineering, Modern OS, Compiler/Runtime, AI Engineering까지 왔다.
이 15편을 한 문장으로 요약하면:
> **"2025년의 엔지니어는 프로토콜부터 모델까지 전 스택을 이해하며, 그 이해를 바탕으로 사람의 문제를 푸는 존재다."**
기술은 수단이다. 목적은 **사람에게 유용한 무언가를 만드는 것**. 코드·아키텍처·모델은 모두 그 목적 위에서 의미를 얻는다.
Part 11 — 커리어 체크리스트 (12항목)
1. **주간 Deep Work 시간 블록** — 달력에 예약.
2. **매주 1개 문서 작성** — ADR, 설계 문서, 블로그 글.
3. **1:1을 의미 있게** — 상사와의 가장 큰 레버리지.
4. **연간 2-3개 학습 목표** — 너무 많으면 모두 실패.
5. **오픈소스 기여 습관** — 내가 쓰는 도구에.
6. **기술 블로그 월 1회 이상**.
7. **1시간 운동 주 3회 이상** — 인지 능력의 하부구조.
8. **7시간 이상 수면** — 생산성의 최상위 레버리지.
9. **멘토·피어 3명 이상**.
10. **5년 뒤 목표를 분기별로 리뷰**.
11. **연 1회 연봉·역할 재평가**.
12. **긴급 예비금 6개월치** 유지.
Part 12 — 10대 커리어 안티패턴
1. **"지금 회사만이 나의 가치"** — 외부 지표 주기적 체크.
2. **매 회의에 참석** — 거절 근육 없음 = 번아웃 보장.
3. **코드 커밋 수로 생산성 측정** — 가장 오해받기 쉬운 지표.
4. **기술 트렌드만 쫓기** — 기초 없이는 유행 바뀌면 리셋.
5. **혼자 해결하는 것이 멋짐** — 도움 요청은 약점이 아니라 효율.
6. **"제품 결정은 PM의 일"이라 선 긋기** — 스태프 이상은 제품 책임을 공유.
7. **글을 안 쓴다** — 글쓰기 없이 스태프 이상은 드물다.
8. **AI를 쓰지 않는다** — 2025년엔 잔업이 2배.
9. **AI를 무비판 수용** — 반대 방향 실수. 품질 급락.
10. **자기 건강·재무를 "나중에"** — 가장 비싼 지연.
Part 13 — 추천 도서 (한 명의 엔지니어가 10년에 걸쳐 읽을 만한 것들)
기술
- *Designing Data-Intensive Applications* — Martin Kleppmann
- *The Pragmatic Programmer* — Hunt & Thomas
- *Code Complete 2* — Steve McConnell
- *Clean Architecture* — Robert Martin
- *Site Reliability Engineering* — Google
커리어·리더십
- *Staff Engineer* — Will Larson
- *The Manager's Path* — Camille Fournier
- *An Elegant Puzzle* — Will Larson
- *The Phoenix Project* / *The Unicorn Project* — Gene Kim
- *Accelerate* — Forsgren, Humble, Kim
사고·생산성
- *Deep Work* — Cal Newport
- *Atomic Habits* — James Clear
- *Thinking, Fast and Slow* — Daniel Kahneman
- *Getting Things Done* — David Allen
- *Range* — David Epstein
글쓰기·커뮤니케이션
- *On Writing Well* — William Zinsser
- *The Sense of Style* — Steven Pinker
- *Crucial Conversations* — Patterson et al.
재무
- *The Simple Path to Wealth* — JL Collins
- *The Psychology of Money* — Morgan Housel
마치며 — 기술자의 장기 여정
기술은 도구고, 커리어는 여정이다. 이 시리즈를 읽는 당신이 1년 뒤, 5년 뒤, 10년 뒤에도 여전히 배우고, 만들고, 나누고 있기를 바란다.
가장 좋은 엔지니어는:
- **겸손한 호기심**을 유지하고,
- **자기 건강**에 투자하며,
- **동료를 일으켜 세우고**,
- **가장 지루한 문제에서도 배움을 찾는** 사람.
이 시리즈가 제공한 기술 지식은 시간이 지나면 일부 낡을 것이다. 그러나 **"배우는 법을 배운 사람"**은 언제나 다음 것을 배울 수 있다.
2025년 4월, 이 시리즈 15편을 마친다. 읽어준 모두에게 감사.
그리고 — 당신이 만드는 무언가가 세상에 조금 더 나은 차이를 만들기를.
시리즈 인덱스
Python 3.13 • Core Web Vitals • PostgreSQL + pgvector • Functional Programming • Kubernetes Complexity • Observability • WebAssembly • Edge Computing • Modern CI/CD • Security & Zero Trust • Distributed Systems • Database Internals • Messaging & Streaming • Frontend State Management • Web Security Attacks/Defense • Network Engineering • Modern OS • Compiler & Runtime • AI Engineering • Developer Productivity & Career (이 글)
현재 단락 (1/204)
지난 14편은 시스템·언어·런타임·AI에 관한 것이었다. 이 글은 **그 기술을 다루는 사람**에 관한 것이다.