> "At Staff level, your output is no longer what you produce, but what you make possible." — Will Larson
[AI Engineer 커리어 가이드]에서 L3→L8 레벨 프레임워크를 봤다. 한 가지가 반복해서 언급됐다 — **L5 이상에서는 영향력이 기술력보다 중요해진다.**
시니어로 4~6년을 보내고도 스태프로 가지 못하는 엔지니어의 80%는 기술이 부족한 게 아니라 **영향력 설계**를 안 하고 있다. 혼자 코드만 잘 쓰는 것으로는 티어가 안 올라간다. 이 글은 그 간극을 메우는 실전 플레이북이다.
다룰 주제:
- 기술 글쓰기의 **2.0 버전** — 내부 RFC에서 외부 세계로
- 컨퍼런스 발표 — QCon·KubeCon·AWS re:Invent 진입
- 오픈소스 메인테이너 — 기여에서 운영자로
- 개인 브랜드 vs 회사 브랜드 — 2025년의 균형
- 멘토십 네트워크 — 양방향 학습
- Internal Staff → External Staff 전환
목차
1. 영향력이 커리어를 결정하는 이유
2. 기술 글쓰기 2.0 — 외부 관객을 위한 글
3. 컨퍼런스 발표 — 연사로 올라가는 길
4. 오픈소스 메인테이너 — 엔지니어의 공공재
5. 개인 브랜드 전략 — 2025년 플랫폼별 가이드
6. 멘토십 — 양방향 네트워크 설계
7. Internal vs External Staff
8. 측정 가능한 영향력 — 수치·가시성·임팩트
9. 번아웃 없이 지속하기
10. 한국 엔지니어의 영향력 전략
11. 체크리스트와 안티패턴
1. 영향력이 커리어를 결정하는 이유
1.1 왜 L5에서 L6로 못 넘어가는가
Will Larson 『Staff Engineer』에서:
> "Promotion to Staff is a political event, not a technical one."
이것은 부정적 의미가 아니다. **"여러 팀이 당신을 필요로 한다"**는 사실이 증거로 보여야 한다. 한 팀에서만 아무리 잘해도 스태프는 멀다.
1.2 영향력의 4가지 형태
1. **Direct** — 내가 직접 구현·결정.
2. **Mentorship** — 주변을 성장시킴.
3. **Written leverage** — 문서가 독립적으로 전파.
4. **Public presence** — 회사 외부로까지 파급.
주니어는 1번이 전부. 시니어는 1+2. 스태프는 2+3+4. 프린시플은 3+4.
1.3 "Force multiplier"의 수학
- 내가 10x 개발자라고 해봤자 "10배".
- 5명을 2x로 만들면 "10배".
- 50명이 읽는 글을 쓰면 "50배 이상".
- 100만 명이 쓰는 오픈소스 — 수천만 배.
스케일이 완전히 다르다.
2. 기술 글쓰기 2.0 — 외부 관객을 위한 글
2.1 RFC·Design Doc은 1.0
[엔지니어링 글쓰기] 포스트에서 다룬 RFC·ADR·Design Doc은 **내부 독자**가 전제. 회사 맥락을 공유.
2.2 2.0의 차이
외부 독자는 **회사 맥락 0, 관심 5초, 경쟁 콘텐츠 무한**. 글 구조가 완전히 다르다.
| 차원 | 내부 1.0 | 외부 2.0 |
|---|---|---|
| 첫 문단 | 배경 설명 | **hook** (충격적 수치·주장) |
| 길이 | 5~20 페이지 | 1,500~3,000 단어 |
| 목적 | 의사결정 | 이해·전파 |
| 언어 | 기업 용어 OK | 일반 개발자 언어 |
| 이미지 | 다이어그램 중심 | + 짤·코드·그래프 |
2.3 hook 쓰는 법
나쁜 예: "Kubernetes 운영 경험을 공유한다."
좋은 예: "한 줄의 YAML 변경으로 월 $50,000 AWS 비용이 절감됐다. 그 과정에서 우리가 배운 것."
좋은 hook의 공통점:
- **구체적 수치**.
- **반직관적 결과**.
- **긴장감**: 문제 → 실패 → 발견.
2.4 구조: AIDA vs BLUF
- **AIDA** (Attention-Interest-Desire-Action) — 마케팅 스타일.
- **BLUF** (Bottom Line Up Front) — 엔지니어링 스타일.
기술 블로그는 BLUF: **결론 먼저, 이유 나중**.
1. 결론 (what we learned)
2. 배경 (problem we faced)
3. 해결 과정 (journey)
4. 디테일 (technical deep dive)
5. 제약·한계 (caveats)
6. 참고 자료
2.5 플랫폼 선택
- **자체 블로그 (Next.js + MDX·Astro·Hugo)** — SEO, 자산화, 영구성.
- **dev.to·Medium·Substack** — 배포 쉬움, 초기 노출.
- **회사 엔지니어링 블로그** — 권위, 내부 마케팅 협업.
- **LinkedIn long-form** — 채용·커리어 노출.
추천 조합: **자체 블로그 + LinkedIn 요약 + 회사 블로그 기고**.
2.6 반복 가능한 발행 루틴
- **월 1편** 최소.
- **주제 백로그** 10개 이상 유지.
- **3 draft 원칙**: 러프 → 정리 → 퇴고.
- **동료 리뷰** — 발행 전 2명 이상 피드백.
2.7 성공 사례 벤치마크
- **Hamel Husain** — AI 엔지니어링 가이드.
- **Chip Huyen** — ML 시스템 설계.
- **Julia Evans** — "zines" 스타일 그림 중심.
- **Dan Luu** — 깊이 있는 성능·시스템.
- **Gergely Orosz** — Pragmatic Engineer 뉴스레터.
- **Evan Czaplicki (Elm)** — 언어 디자인.
- **Rachel By The Bay** — 엔지니어링 문화.
글 많이 읽고 스타일을 분석하라. **자기만의 목소리**가 결국 기억된다.
3. 컨퍼런스 발표 — 연사로 올라가는 길
3.1 왜 컨퍼런스인가
- **깊은 신뢰** — 글보다 효과 크다.
- **네트워크** — 연사끼리 연결.
- **회사 인지도** — 리쿠르팅 효과.
- **스킬**: 영상 녹화로 자기 자산.
3.2 컨퍼런스 계층
**1단계 (첫 발표)**:
- 사내 Tech Talk.
- Local Meetup (GDG, Rust Korea).
- 회사 Engineering Day.
**2단계 (중급)**:
- 국내 컨퍼런스: FEConf, if(kakao), DEVIEW, AWS Summit Korea, Google I/O Extended.
- 국제 지역 이벤트: PyCon Asia, JSConf Asia.
**3단계 (상위)**:
- **QCon** (SF·London·NYC) — 엔지니어링 리더십.
- **KubeCon + CloudNativeCon** — 클라우드 네이티브.
- **AWS re:Invent** — 초대형, 3만+명.
- **Google Cloud Next, Microsoft Build**.
- **Strange Loop** — 2023 종료 후 SciPy·LambdaConf.
**4단계 (탑 티어)**:
- **ACM SIGCOMM, NSDI, OSDI** — 연구 컨퍼런스.
- **RailsConf, RubyConf, PyCon US** (키노트).
3.3 CFP (Call For Proposals) 작성
**성공 CFP 구조**:
1. **제목** — 구체적·hook이 있는.
2. **Abstract** (200~300 단어) — 문제·해결·청자 수확.
3. **Outline** — 5~7개 섹션.
4. **Why me** — 왜 내가 말할 자격이 있는가.
5. **Prior talks** — 비디오 링크.
**나쁜 제목**: "Kubernetes로 마이크로서비스 구축하기"
**좋은 제목**: "100만 RPS에서 Kubernetes가 깨진 하루와 그걸 다시 세운 방법"
3.4 발표 준비
- **슬라이드** — 1 슬라이드 = 1 아이디어. 글자 최소.
- **스토리텔링**: 문제 → 실패 → 깨달음 → 해결.
- **라이브 데모는 위험** — 녹화 백업 준비.
- **리허설 5회+**. 시간 정확히.
- **Q&A 예상**: 10~20개 준비.
3.5 첫 영어 발표 준비
- **스크립트 → 키워드 slide** 전환.
- **녹음하며 쉐도잉**.
- **해외 Meetup online**으로 먼저 연습.
- Accent는 문제 아님 — **명확성·리듬**이 중요.
3.6 한국 엔지니어의 국제 발표 경로
1. Meetup 3회 → if(kakao)/DEVIEW → QCon/KubeCon.
2. 오픈소스 메인테이너 → 관련 컨퍼런스 초청.
3. 유명 기술 블로그 → 컨퍼런스 섭외.
4. 회사 마케팅 예산 활용 (AWS 파트너 이벤트).
4. 오픈소스 메인테이너 — 엔지니어의 공공재
4.1 기여자 → 메인테이너
대부분 엔지니어는 기여자(contributor)에서 멈춘다. 메인테이너로 올라가면:
- **신뢰 지표**: 업계 전반.
- **학습 가속**: 수많은 use case.
- **네트워크**: 전 세계.
- **경력 자산**: 평생.
4.2 메인테이너가 되는 경로
1. **작은 PR 5~10개**.
2. **Issue triage** 자발적.
3. **새 기능 제안**: RFC issue.
4. **메인테이너 승격** (기존 팀 결정) 또는 **자체 오픈소스 시작**.
4.3 자체 오픈소스 시작
- **Scratch your own itch** — 자신의 문제 해결.
- **작게 시작**: 단일 목적 라이브러리.
- **좋은 README + DevRel**.
- **MIT/Apache 라이선스** — 채택 장벽 낮춤.
- **CI·테스트·CHANGELOG** 처음부터.
**성공 사례**:
- **LangChain** (Harrison Chase) — 2022년 솔로 시작.
- **Playwright, Puppeteer**.
- **tRPC** (Alex Johansson).
- **Zod** (Colin McDonnell).
- **Hono** (유스케 와다).
- **Uno.css, Windi.css**.
4.4 메인테이너의 일상
- **Issue triage** — 주당 2~5시간.
- **PR 리뷰** — 큰 프로젝트는 전담.
- **릴리스 관리**.
- **커뮤니티 관리** — Discord·Slack·GitHub Discussions.
- **번아웃 관리** — 엔지니어가 가장 흔히 실패하는 영역.
4.5 지속 가능성
- **GitHub Sponsors·OpenCollective·Tidelift** — 후원.
- **회사 유료화**: Vercel·Supabase·Grafana 모델.
- **컨설팅·교육** 부업.
- **Co-maintainer** 확보 — bus factor > 1.
4.6 한국의 오픈소스 생태계
- **네이버**: Pinpoint, Arcus, Navi.
- **카카오**: Khaiii, Kakao Open Source.
- **NHN**: FE-Development-Kit.
- **개인**: DukSoo(Hakko), Beom-i(various Rust tools).
한국 엔지니어 기여는 여전히 전체 비율에서 낮음. 진입 장벽은 낮다.
5. 개인 브랜드 전략 — 2025년 플랫폼별 가이드
5.1 왜 개인 브랜드인가
- **재취업 보험**: 오퍼가 먼저 온다.
- **협상력**: 시장 가치 가시화.
- **기회의 폭**: 자문·겨시·창업.
- **팀 채용**: 동료 영입 쉬움.
5.2 주의: 회사 브랜드와 경계
- **고용 계약 확인**: 사이드 프로젝트·공개 글 조항.
- **내부 정보**: NDA·영업비밀 주의.
- **포지셔닝**: "회사 대변인"이 아닌 "엔지니어 본인" 명확화.
5.3 플랫폼별 전략
**LinkedIn (2025 가장 중요)**:
- 헤드라인에 역할·키워드 (AI Engineer, Staff Engineer, Distributed Systems).
- About — 200~300자, 성과·관심·대화 초대.
- 포스트 — 주 1~2회. 깊이 있는 long-form이 알고리즘 선호.
- Comment — 업계 리더 글에 의미 있는 코멘트.
**Twitter/X**:
- 2023년 이후 흐름 변화 (머스크 인수 후 논쟁).
- 여전히 AI/엔지니어링 담론 중심.
- Thread (스레드) 포맷으로 깊이 있는 글.
- **대체 플랫폼**: Bluesky, Mastodon (엔지니어링·ML 활발).
**YouTube·Twitch**:
- 진입 장벽 높음. 편집 시간 막대.
- live coding·paper reading 스타일이 성공 확률 높음.
- **The Primeagen, Jon Gjengset, Fireship** 벤치마크.
**Podcast**:
- 호스트보다 **게스트**로 시작.
- 자기 팟캐스트는 최소 50 에피소드 지속 가능할 때만.
**Newsletter (Substack·Beehiiv)**:
- 이메일 리스트 = 알고리즘 독립 자산.
- 무료·유료 구독.
- **Pragmatic Engineer** (Gergely Orosz), **Prompt Engineering** 등.
5.4 콘텐츠 캘린더
월간:
- 블로그 포스트 1편 (2000+ 단어).
- LinkedIn 포스트 4~6개.
- Twitter 15~30개 (짧은 insight).
- Newsletter (있다면) 1~2회.
5.5 가시성과 진정성의 균형
- **hype 금지** — 과장된 성과 주장은 신뢰 파괴.
- **실패 공유** — 성공보다 더 깊은 교감.
- **credit 나누기** — 팀·도구·레퍼런스.
- **respond 폴리시**: 90% 반응, 10% 무시.
6. 멘토십 — 양방향 네트워크 설계
6.1 멘토 찾기
- **내부 매니저**는 멘토가 아니다 (평가 충돌).
- **한 단계 위 시니어** (2~5년 앞) — 현실적.
- **이전 직장 시니어** — 외부 시각.
- **컨퍼런스 네트워킹** — 1:1 커피 요청.
6.2 좋은 멘토-멘티 관계
- **목표 명확**: 구체적 질문 가져가기.
- **빈도**: 월 1회 30분도 충분.
- **준비**: 멘토에게 숙제 주지 않기.
- **감사**: 소소한 업데이트·성과 공유.
6.3 멘티 받기 — 스태프 이상의 책임
- **mentorship은 스태프 역량의 핵심**.
- **도제식** (Apprenticeship): 몇 주간 shadowing.
- **Career conversation**: 분기별.
- **피드백**: 직접·구체적·시기 적절.
6.4 Peer network
- 멘토뿐 아니라 **동급 피어 네트워크**가 장기적으로 중요.
- **Slack/Discord 커뮤니티**: Rands Leadership, 개발자 커뮤니티 Korea.
- **Mastermind group**: 4~6명, 격주 1시간.
- **Private dinner clubs**.
6.5 네트워크 품질 > 양
- LinkedIn 1,000명 팔로워 > 100명 **반응하는** 팔로워 가치 적음.
- "내가 연락하면 24시간 내 답하는" 사람 50명 — 진짜 자산.
- **한 달 1명** 의미 있는 새 관계가 연 12명 = 10년 120명.
7. Internal vs External Staff
7.1 Internal Staff
- 회사 내 강한 영향력.
- 외부 인지도 낮음.
- 이직 시 "이력서 재구성" 필요.
- 한국 대기업에 흔함.
7.2 External Staff
- 업계 전반 인지도.
- 회사 독립 브랜드.
- 리크루터가 먼저 연락.
- OpenAI·Anthropic·Stripe 엔지니어 다수.
7.3 전환 전략
- **Internal → External**은 점진.
- 오픈소스 기여, 컨퍼런스 발표, 블로그 글 순서.
- 2~3년에 걸쳐 구축.
- **회사 엔지니어링 블로그** 기고가 첫 단추로 좋음.
7.4 위험 관리
- **외부 평판 = 이중 책임**: 실수 공개화 가능.
- **SNS 정치** — AI·정책 민감 이슈 조심.
- **회사 이해관계와의 충돌**.
- **Self-censorship의 미묘한 균형**.
8. 측정 가능한 영향력
8.1 측정 없이는 개선 없다
- **GitHub stars** (자체 프로젝트).
- **Blog view, unique visitor**.
- **Conference CFP 채택률**.
- **LinkedIn impression, engagement**.
- **인바운드 오퍼** 수.
- **Community Discord/Slack 멤버**.
8.2 허영 지표 vs 실질 지표
- 허영: 팔로워 수.
- 실질: 의미 있는 대화·협업·오퍼·채용으로 이어진 횟수.
8.3 분기별 리뷰
- 작성한 글: 몇 편, 조회수.
- 발표: 몇 회.
- 멘티: 몇 명.
- 내 브랜드 자산 변화.
- 개선 방향.
8.4 팀 영향력 증거
- **주니어 승진 기여**: 내가 멘토한 사람의 성장.
- **프로젝트 성공**: 내가 주도·기여.
- **문서 영향력**: RFC 읽힘·인용.
- **채용**: 영입·면접 기여.
9. 번아웃 없이 지속하기
9.1 영향력 작업은 추가 업무다
- 본업 + 글쓰기 + 발표 + 오픈소스 = 80시간.
- 번아웃 지름길.
9.2 규칙 1: 업무와 통합
- **회사 프로젝트가 블로그 주제**: 1석 2조.
- **RFC가 나중에 외부 글로**.
- **발표가 팀 지식 공유와 연결**.
9.3 규칙 2: 시간 박스
- 주 1회 금요일 오후 = "영향력 시간".
- 하루 30분 아침 블로그.
- 분기별 주말 1회 = 컨퍼런스 CFP.
9.4 규칙 3: 조용한 시즌
- 번아웃 직전이면 3~6개월 **조용히**.
- 그 기간은 소비 (읽기·강의) 집중.
- 다시 발행 시 돌아오는 고객은 깊게 연결된 사람.
9.5 규칙 4: 재무 버퍼
- 3년 이상 영향력 축적하면 **기회비용이 크다**.
- 창업·컨설팅·강연으로 변환 가능.
- 본업 외 연 $10K~$100K+ 부업 구조.
10. 한국 엔지니어의 영향력 전략
10.1 한국 기반의 고유 강점
- **제조·반도체·게임** 도메인 깊이.
- **판교·강남 네트워크** 밀도.
- **카카오·네이버·쿠팡** 대규모 트래픽 경험.
10.2 한국 기반의 고유 도전
- **영어 벽** — 기술 글·발표.
- **겸손 문화** — 자기 PR에 불편.
- **휴식 부재** — 영향력 작업할 여력 적음.
10.3 실용 전략
1. **한국어 콘텐츠 → 영어 번역**: 내부 청자 먼저, 외부 확장.
2. **글로벌 회사 원격 취업**: 영어 환경 자연 노출.
3. **해외 컨퍼런스 참석 → 발표**: 먼저 듣고 익숙해지기.
4. **한국어 오픈소스 번역·문서화**: 작은 기여부터.
5. **해외 엔지니어와 1:1 커피**: LinkedIn 요청.
10.4 한국 + 글로벌 이중 브랜딩
- 한국어 블로그 (네이버·Tistory·Medium).
- 영어 버전 (자체 Next.js 블로그).
- LinkedIn 한국·영어 이중 포스트.
- 국내 컨퍼런스 + 아시아 컨퍼런스 (PyCon TW, RubyConf JP).
체크리스트
1. ☐ 자체 기술 블로그가 있고 월 1편 이상 발행한다.
2. ☐ LinkedIn에 깊이 있는 포스트를 주 1회 이상 한다.
3. ☐ 최근 6개월 내에 사내 또는 외부 발표를 했다.
4. ☐ 오픈소스에 PR 5개 이상 기여했다.
5. ☐ 최소 1명의 멘토와 정기 연락한다.
6. ☐ 최소 1명의 멘티가 있다.
7. ☐ 전 직장 동료와 분기별 연락한다.
8. ☐ 내가 작성한 문서를 인용·참조하는 사람이 회사 밖에도 있다.
9. ☐ 업계 주요 뉴스레터 3개 이상 구독한다.
10. ☐ 영향력 작업 전용 시간이 주간 스케줄에 박혀 있다.
11. ☐ 번아웃 시 쉴 수 있는 3개월 생활비 버퍼가 있다.
12. ☐ 내가 하는 외부 활동이 현재 고용계약과 충돌 없음을 확인했다.
자주 보는 안티패턴 10가지
1. **"일만 잘하면 된다" 신화** — 시니어 이상에선 틀림.
2. **회사 브랜드에 자기 브랜드 완전 종속** — 이직 시 reset.
3. **완벽주의로 발행 미루기** — shipping이 rewriting보다 중요.
4. **논쟁적 이슈로 팔로워 늘리기** — 단기 성과, 장기 독.
5. **지속성 없는 콘텐츠**: 한두 편 쓰고 포기.
6. **멘티 안 받기**: 주는 게 받는 것.
7. **해외 컨퍼런스 참여 포기**: "영어 안 돼서" 핑계.
8. **오픈소스 메인테이너 번아웃**: solo로 끌고 감.
9. **Self-promotion 과잉**: 겸손·진정성과 균형 깨짐.
10. **단기 정량 지표 집착**: 팔로워 1,000 vs 의미 있는 관계 50.
다음 글 예고 — “엔지니어 창업 완전 가이드: Idea에서 시리즈 A까지, PM·디자인·마케팅·영업·펀드레이징까지”
영향력을 충분히 쌓았다면 다음은 **창업**이다.
- Idea 검증 — PoC에서 MVP까지
- 팀 구성 — co-founder·초기 채용
- GTM과 마케팅 — PLG·영업 주도
- 펀드레이징 — 엔젤·시드·시리즈 A·네트워크
- 법인·스톡 옵션·재무 기초
- 엔지니어가 CEO/CTO로 전환
- 실패에서 배우는 법
- 한국·미국 창업 생태계 비교
커리어의 마지막 단계이자 새로운 시작. 다음 글에서 이어진다.
현재 단락 (1/299)
[AI Engineer 커리어 가이드]에서 L3→L8 레벨 프레임워크를 봤다. 한 가지가 반복해서 언급됐다 — **L5 이상에서는 영향력이 기술력보다 중요해진다.**