연차가 실력을 만들지 않는다

10년차 주니어의 현실

"10년 동안 일했다는 것과 1년을 10번 반복했다는 것은 다르다." 로버트 마틴(Clean Code, 2008)이 오래전부터 반복해 온 이 말은 업계의 불편한 진실입니다. 2023년 Stack Overflow 개발자 설문에서 경력 5년 이상 응답자 중 자신을 "시니어"로 분류한 비율은 41%였지만, 조직 내부에서 동일 인물이 시니어 직급을 인정받는 비율은 그보다 훨씬 낮았습니다.

시니어는 직함이 아니라 문제 정의 능력이 임계점을 넘은 상태입니다. 주어진 태스크를 깔끔하게 처리하는 것을 넘어서, 어떤 문제를 풀어야 하는지, 언제는 풀지 않아야 하는지를 판단하는 단계에 들어서야 시니어로 불립니다.

저희 팀만 해도 Flutter 기반 11개 앱을 모노레포로 운영하고 Next.js 기반 백엔드와 자체 AI 서비스를 함께 다루다 보니, 단순히 "코드를 많이 짜는 사람"보다 "이 기능을 지금 만들 가치가 있는지"를 묻는 사람의 기여가 훨씬 크게 느껴지더군요. 대구에 자리 잡은 작은 조직이라 특히 그렇습니다. 한 사람이 결정하는 문제의 범위가 곧 서비스의 형태를 결정하니까요.

주니어와 시니어의 구조적 차이

Google의 엔지니어링 관행 문서 Software Engineering at Google(2020)은 레벨을 이렇게 구분합니다.

L3–L4 (Junior): 잘 정의된 태스크를 완수한다. 코드 리뷰를 받는다.
L5 (Senior): 중간 규모 시스템을 설계하고 소유한다. 팀의 기술 방향에 기여한다.
L6 (Staff): 여러 팀에 영향을 주는 아키텍처를 결정한다. 기술 전략을 설계한다.

이 단계는 나이·연차·자격증으로 채워지지 않습니다. 각 단계는 관여하는 문제의 규모로 정의됩니다.

---

1단계: "잘 쓰는" 주니어 (1~2년차)

목표: 태스크를 시간 안에 완수한다

이 구간에서 중요한 것은 속도가 아니라 완결성입니다. 티켓 하나를 맡았을 때 다음을 빠짐없이 해내는 것이 1단계 졸업 조건입니다.

요구사항을 정확히 이해하고, 애매하면 질문한다
자신의 변경이 영향을 주는 범위를 추적한다
테스트를 직접 작성한다
PR 설명을 읽을 만하게 쓴다
리뷰 피드백을 방어하지 않고 받아들인다

흔한 함정

"일단 돌아가면 된다"는 사고방식은 이 단계의 대표적 함정입니다. 한 번 돌아간 코드를 고칠 때 드는 비용이 처음 작성하는 비용보다 훨씬 크다는 것을 깨닫는 순간이 1단계의 진짜 졸업입니다.

---

2단계: 미들 엔지니어 (2~4년차)

목표: 모듈을 소유한다

이 구간의 핵심 단어는 "소유권(ownership)"입니다. 하나의 서비스 모듈, 하나의 내부 라이브러리, 하나의 데이터 파이프라인을 자신이 책임지고 유지·개선합니다.

Ben Horowitz는 The Hard Thing About Hard Things(2014)에서 "뛰어난 팀은 문제가 생겼을 때 '누가 이걸 담당하는가'를 묻지 않고, 해당 담당자가 '나는 이미 알고 있었다'고 답하는 팀"이라고 썼습니다. 미들 엔지니어는 자신의 모듈에 대해 이런 태도를 가져야 합니다.

기술 확장의 폭

이 시기부터는 단일 언어·단일 프레임워크에 갇히지 않아야 합니다. 백엔드 엔지니어라면 최소한 SQL 튜닝, 기본 인덱스 구조, HTTP 캐시 헤더, 간단한 프론트엔드까지 자력으로 해결할 수 있어야 합니다. T자형 인재(하나의 깊이 + 넓은 인접 영역)가 업계의 표준 기대치입니다.

평가 기준

| 역량 | 구체 행동 | |---|---| | 설계 | 중간 규모 모듈의 인터페이스를 혼자 결정한다 | | 디버깅 | 로그·메트릭만 보고 원인 가설을 세운다 | | 문서화 | 후임이 읽고 바로 착수할 수 있는 README를 쓴다 | | 협업 | 다른 팀의 요청을 거절할 줄 안다 |

---

3단계: 시니어 진입 (4~7년차)

목표: 문제를 정의한다

시니어의 결정적 차이는 "이 문제를 꼭 지금 풀어야 하는가"를 묻는 능력입니다. 주니어는 주어진 문제를 풀고, 시니어는 어떤 문제를 풀지 정합니다.

이 능력은 종종 역설적으로 나타납니다. "빠르게 구현할 수 있는 기능을 제안받았지만, 6개월 뒤 유지비가 더 클 것이라고 예상하여 반대한다." "팀이 3개월째 해결하지 못한 버그가 실제로는 요구사항 자체의 모순이라는 것을 지적한다." 이런 판단은 경험만으로 만들어지지 않고, 체계적으로 시스템을 읽는 훈련의 결과입니다.

시스템 사고의 실전

Donella Meadows(Thinking in Systems, 2008)는 "숲을 보는 사람은 나무의 위치가 아니라 나무들이 서로에게 미치는 영향의 방향을 본다"고 했습니다. 시니어가 설계 회의에서 던지는 질문은 다음과 같은 형태입니다.

이 변경이 유도할 피드백 루프는 무엇인가?
장애 시 실패 모드는 몇 가지이고, 각각 어떻게 감지되는가?
이 API가 유출하는 내부 상태는 무엇이고, 클라이언트는 어디까지 의존할 수 있는가?

사람과 프로세스

시니어의 업무 시간은 점점 "코드 작성"에서 "합의 형성"으로 이동합니다. Stack Overflow 2023 설문에서 시니어 개발자의 주간 코딩 시간은 평균 21시간으로, 주니어(32시간)보다 현저히 적었습니다. 나머지 시간은 리뷰·회의·문서화·멘토링에 쓰입니다. 이 변화가 불편한 사람은 시니어가 되어도 실제 영향력을 내지 못합니다.

---

4단계: 시니어의 확장 (7~10년차)

목표: 팀의 기술 방향에 영향을 준다

개인의 생산성은 어느 시점에서 반드시 정체됩니다. 1인 개발자가 최고 수준으로 타이핑할 수 있는 속도는 연간 수만 줄 수준이고, 이는 팀 전체 산출물과 비교하면 미미합니다. 이 지점에서 레버리지를 이해하는 사람과 그렇지 못한 사람이 갈립니다.

Will Larson(Staff Engineer, 2021)은 시니어 이상의 핵심 레버리지를 다음 네 가지로 정리합니다.

핵심 시스템의 소유 — 모든 팀이 의존하는 인프라를 관리한다
기술 전략 — 2~3년의 기술 로드맵을 설계한다
접착제(Glue) — 여러 팀 사이의 마찰을 줄이는 문서·회의·프로토콜을 만든다
전문성(Solver) — 다른 엔지니어가 못 푸는 특정 영역의 최후의 해결사가 된다

이 네 가지 중 어떤 "유형"의 시니어가 될지 의식적으로 선택하는 것이 이 구간의 과제입니다.

기술 부채에 대한 태도 전환

시니어는 기술 부채를 "없애야 할 악"이 아니라 "관리해야 할 재고"로 봅니다. 모든 부채를 갚으려는 팀은 신제품을 내지 못하고, 어떤 부채도 인정하지 않는 팀은 결국 폭발합니다. 적정한 부채 비율은 프로덕트 단계(발견·성장·성숙)에 따라 다르며, 이 판단 자체가 시니어의 주요 산출물입니다.

---

5단계: Staff/Principal로의 전환 (10년+)

목표: 조직의 기술 선택 공간을 정의한다

이 단계는 개인의 코딩 역량으로 넘을 수 있는 벽이 아닙니다. "이 회사가 앞으로 어떤 기술 문제를 풀 것인가"를 설계하는 역할이고, 그 결정에 따라 수십 명의 엔지니어가 움직입니다.

Camille Fournier(The Manager's Path, 2017)는 이 단계에 오를 준비가 된 엔지니어의 징후를 이렇게 썼습니다.

경영진 회의에서 기술적 발언이 경영 용어로 번역되어 나온다
채용·해고·조직 개편에 기술적 근거를 제시한다
기술 블로그·컨퍼런스·오픈소스를 통해 회사 외부의 인지도를 쌓는다

매니저의 길, IC의 길

Staff 이상에서는 두 갈래의 길이 열립니다. 매니저 트랙(EM → Director)은 사람을 통해 성과를 내고, IC(Individual Contributor) 트랙(Staff → Principal → Distinguished)은 기술로 성과를 냅니다. 두 트랙이 조직 내에서 동등한 위상을 갖는 회사가 점점 늘고 있으며, 어느 쪽도 다른 쪽보다 열등하지 않습니다.

---

가속을 위한 실전 원칙들

1. 읽고 쓰는 시간을 늘려라

코드를 쓰는 시간보다 읽는 시간이 많아질 때 성장 속도가 빨라집니다. 오픈소스, 동료의 PR, 대형 시스템의 설계 문서를 꾸준히 읽으세요.

2. 실패를 빨리 공개하라

주니어일수록 실패를 숨기려는 유혹이 큽니다. 하지만 조직은 "실패를 빨리 공유하는 사람"에게 더 중요한 문제를 맡기는 경향이 있습니다. 포스트모템은 약점이 아니라 자산입니다.

3. 코드 외부로 확장하라

시스템 설계, 프로덕트 이해, 사용자 인터뷰, 데이터 분석까지 관여하세요. 엔지니어링은 "코드를 쓰는 일"의 부분집합이 아니라 "문제를 푸는 일"의 부분집합입니다.

4. 의도적으로 낯선 기술을 익혀라

분기마다 업무에서 쓰지 않는 기술을 하나씩 얕게 익히세요. Go를 써 본 백엔드 개발자는 성능 관점을 갖게 되고, Rust를 건드려 본 프론트엔드 개발자는 메모리 안전을 다르게 보게 됩니다.

---

한 줄로 정리하면

시니어는 "언제 되느냐"가 아니라 "무엇을 선택했느냐"의 결과입니다. 편한 태스크만 잡은 5년보다, 불편한 문제 하나를 끝까지 소유한 2년이 훨씬 큰 성장을 만들어내곤 합니다.

지금 자신의 포지션이 어디쯤인지 정직하게 점검해 보고, 다음 단계로 가기 위해 이번 분기에 의도적으로 불편해질 한 가지를 골라 보세요. 성장은 대개 그 한 번의 선택에서 시작됩니다.