“코드를 안 놓으면 애매해진다?” Staff-plus 시대의 엔지니어 리더십을 역할(Role)로 다시 정의하기

Bro's Insights
1

테크 리드/스태프/프린시펄 같은 포지션은 “기술도 하고, 조직 맥락도 읽는 자리”라서 종종 양쪽에서 애매하게 보입니다. 이 글에서는 그 애매함의 원인을 직급(Rank)이 아니라 역할(Role) 관점에서 풀어보고, 제가 최근 RFP·기술협상 같은 비즈니스 접점을 처음 겪으며 얻은 실전적인 정리(정렬, 문서, 임팩트 설계)를 공유합니다.

Rank-driven vs Role-driven: 애매함은 “권한-책임-평가” 불일치에서 시작합니다

제가 느낀 “양쪽한테 다 애매한 자리”라는 감각은 보통 아래 3가지가 서로 어긋날 때 커집니다.

  • 권한(Decision rights): 무엇을 내가 결정할 수 있는가?
  • 책임(Accountability): 어떤 결과에 내가 책임지는가?
  • 평가 기준(Reward criteria): 무엇을 하면 인정/보상받는가?

Rank-driven 조직에서는 직급이 곧 권한처럼 작동하기 쉽습니다. 반면 Role-driven 조직에서는 “어떤 역할로 어떤 임팩트를 내는가” 가 중심이고, 그래서 정보 공유와 문서화가 거의 필수 조건이 됩니다. (실리콘밸리식 레벨도 권력이라기보다 역량/보상의 기준이라는 관점이 여기에 닿아 있습니다.)

제가 최근 PM 역할(외부 접점, RFP, 기술협상)을 이어받으며 깨달은 것도 비슷합니다. “전략 경영은 내 일이 아니겠지”라고 생각했지만, 실제로는 기술이 항상 누군가의 의사결정 위에 올라타 있고, 그 결정을 추적하면 비용·리스크·조직 방향으로 이어졌습니다.
결국 애매함을 줄이려면 “내가 아직 코딩을 얼마나 하냐”가 아니라, 내 역할이 어떤 결정의 비용/리스크를 가시화하고 정렬시키는지를 먼저 합의해야 합니다.

Staff-plus는 “더 잘하는 시니어 개발자”가 아니라 Force Multiplier입니다

Slack의 Senior Staff를 설명할 때 자주 나오는 표현이 Force Multiplier입니다. 핵심은 “기술을 잘함” 자체보다도:

  • 기술이 가능케 하는 가치(value) 를 키우고
  • 실험이 가능하도록 환경을 만들며
  • DX(Developer Experience), 관계 구축, 신뢰/네트워크로 조직의 속도와 품질을 올리는 것

Google의 Staff(레벨 6) 이야기도 방향이 같습니다. 단순 실행을 넘어:

  • 문제를 선택하고
  • 문제를 프레이밍하고
  • 문서/조율/멘토링으로 조직의 혼돈을 감소시키는 것이 핵심 역량이 됩니다.

제가 이걸 “진정한 테크 엔지니어링”이라고 느낀 지점은 여기였습니다. 설계/구현은 이미 경험적 베이스가 있지만, 다음 단계의 성장은 문제정의·우선순위·리스크 관리였고, 이건 자연스럽게 합의 형성력(결정이 실행되게 만드는 힘) 으로 이어졌습니다.

시간이 줄수록 “고임팩트”만 남깁니다: 스낵/프리닝/고스트를 경계하세요

레벨이 올라갈수록 시간은 늘지 않고, 대신 영향 범위와 기대치가 커집니다. 그래서 “바빠 보이지만 임팩트가 낮은 일”이 커리어를 잡아먹습니다.

대표적인 함정 3가지가 자주 언급됩니다.

  • 스낵(snacks): 쉽고 저임팩트인 일을 계속 처리하며 바쁜 척하게 됨
  • 프리닝(preening): 저임팩트인데 가시성만 높은 일(겉보기 성과)
  • 고스트(ghosts): 의미가 불분명한 대형 과제(큰 것처럼 보이나 실제 가치가 없음)

저는 특히 PM/대외 업무(RFP, 협상)를 처음 맡을 때 “요청이 오면 다 처리해야 할 것 같은” 압박을 느꼈는데, 이때 스낵과 프리닝이 급증하기 쉽습니다. Staff-plus로 갈수록 중요한 건 처리량이 아니라 선택과 거절(또는 나중으로 미루기) 입니다.

Staff-plus 권한은 ‘위임된 권한’: 스폰서 정렬이 성과의 전제입니다

Staff-plus의 많은 영향력은 공식 권한이 아니라 위임된 권한인 경우가 많습니다. 그래서 스폰서(상위 권한자)와의 정렬이 성과의 전제가 됩니다.

정렬에서 가장 중요한 건 두 가지였습니다.

  • 서프라이즈 방지: “이 결론이 나왔다”가 아니라, “이 결론으로 가는 과정”을 공유하기
  • 컨텍스트 공유: 결정권자가 중요하게 보는 축(비용/일정/리스크/평판/규제)을 먼저 맞추기

제가 앞서 말했던 “기술은 누군가의 의사결정 위에 있다”는 관점은 여기서 실전이 됩니다. 최고결정권자의 동의를 얻고 싶다면 기술 정합성만 설명하는 게 아니라, 그들이 싫어하는 실패(예: 일정 지연, 신뢰/평판, 법적 리스크 등)와 내가 제안하는 선택지가 어떻게 연결되는지를 먼저 맞춰야 합니다.

“동의(Alignment)를 얻는 문서”를 만들어야 합니다: 전략은 RFC의 공통점에서 나옵니다

전략/비전은 신비한 통찰이 아니라, 여러 설계문서(RFC)들의 공통점을 추출한 반복 학습의 산물이라는 설명이 인상 깊었습니다.
즉, 전략은 누가 갑자기 “선포”하는 게 아니라, 조직이 축적한 판단과 선택을 문서로 남길 때 자연스럽게 생깁니다.

제가 추천하는 최소 문서 템플릿은 아래 정도입니다. “기술 문서”라기보다 동의를 얻기 위한 의사결정 문서에 가깝습니다.

# Decision Memo: <의사결정 제목>

## 1) 배경 (Context)
- 왜 지금 이 결정을 해야 하는가?
- 관련 이해관계자/제약조건(일정, 규정, 계약, 인력 등)

## 2) 문제 정의 (Problem)
- 실패를 무엇으로 정의하는가? (돈/일정/평판/법적 리스크 등)
- 성공의 측정 기준(간단한 KPI/Acceptance criteria)

## 3) 선택지 (Options)
- Option A: ...
- Option B: ...
- Option C: ... (Do nothing 포함)

## 4) 비교 (Trade-offs)
- 비용/일정/리스크/운영(온콜)/확장성 관점에서 표로 비교

## 5) 추천안 (Recommendation)
- 내가 추천하는 선택지
- 왜 지금 이 선택이 조직 방향과 맞는가?

## 6) 롤아웃/후속 (Next steps)
- 다음 2주/1달에 무엇을 어떻게 검증할지
- 되돌릴 수 있는 지점(rollback)과 관측 지표

이 문서의 목적은 “내가 옳다”가 아니라, 결정권자가 ‘숨은 비용’을 보고 빠르게 결정할 수 있게 만드는 것입니다. 합의는 설득만으로가 아니라, 선택지/비용/리스크가 같은 화면에 올라올 때 만들어집니다.

승진 패킷(Promo Packet)은 “나중에 쓰는 서류”가 아니라 “커리어 설계 문서”입니다

승진 패킷을 미리 쓰라는 조언은 특히 Role-driven 성장에 잘 맞습니다. 제가 해석한 요지는 이렇습니다.

  • 승진 패킷은 결과 보고서가 아니라 계획 + 증거 수집 프레임
  • 임팩트/복잡성/멘토링/조직 기여/갭을 미리 구조화하면
  • “무엇을 해야 다음 레벨인가”가 덜 애매해집니다

간단한 뼈대는 아래처럼 시작할 수 있습니다.

# Promo Packet Draft (Living Doc)

## Target Role/Level
- 예: Senior → Staff, Staff → Senior Staff

## Scope & Impact
- 내가 만든 변화가 누구/무엇에 영향을 줬는가?
- 수치/사례/의사결정 로그

## Complexity
- 기술적/조직적 복잡성을 어떻게 낮췄는가?

## Leadership & Mentoring
- 멘토링, 온보딩 개선, 의사결정 프로세스 정착 등

## Org Contributions
- 재사용 가능한 문서, 가이드, 플랫폼화, 표준화

## Gaps & Next Experiments (3개월)
- 아직 부족한 역량
- 검증할 액션(실험) 2~3개

이걸 매니저/동료 피드백으로 계속 갱신하면, “애매한 자리”에서 벗어나는 가장 현실적인 도구가 됩니다. 평가 기준을 밖에서 기다리는 대신, 내가 역할을 정의하고 증거를 설계하는 방식이니까요.

기술 품질(Technical Quality)은 개인의 의지가 아니라 ‘조직 설계’ 문제입니다

기술 품질이 무너질 때 흔히 “누가 코드를 대충 짰다”로 결론이 나지만, 자료에서는 기술 품질을 시간축별 균형을 설계해야 하는 정상적인 조직 과제로 봅니다.

핵심은 거창한 리팩토링 선언보다:

  • 가벼운 해결책부터 단계적으로 도입하고
  • 품질을 “누군가의 노력”이 아니라 “팀의 시스템”으로 만든다는 점입니다.

Staff-plus 관점에서의 품질 리더십은 “내가 고쳐서 해결”이 아니라, 품질이 자동으로 지켜지는 의사결정/우선순위 구조를 만드는 것에 더 가깝습니다.

마무리: “애매함”을 없애는 방법은 코딩 비중이 아니라 역할의 언어를 만드는 것입니다

테크 리드/스태프/프린시펄이 애매해지는 이유는 능력이 부족해서가 아니라, 권한-책임-평가가 Role로 정렬되지 않아서인 경우가 많습니다. 제가 요즘 느끼는 성장의 방향도 결국 “더 잘 구현하기”보다 문제정의·우선순위·리스크를 문서로 가시화하고, 이해관계자의 동의를 만들어 실행되게 하는 힘에 있습니다.
코드를 놓지 않되, 영향력을 확장하고 싶다면 “내가 무엇을 만들었나”만이 아니라 “조직의 혼돈을 얼마나 줄였나”를 기록해보시면 좋겠습니다.

참고 자료

2 Likes