내가 '가짜 시니어'였다는 걸 깨달은 순간

1. 코딩 기계가 시니어인 줄 알았다

개발을 시작한 지 몇 년이 지났을 때, 스스로를 '시니어 개발자'라고 생각했습니다. 화려한 디자인 패턴을 알고 있었고, 단축키를 현란하게 썼으며, 누구보다 빨리 기능을 구현했으니까요.

하지만 멘토가 저에게 했던 피드백은 충격적이었습니다. "OO님은 코딩은 잘하시는데, 팀 전체의 속도를 높여주지는 못하고 계세요."

화가 났습니다. "내가 일을 다 처리하고 있는데 무슨 소리야?" 하지만 돌이켜보니 저는 '나 혼자 잘하는 개발자'였지, '팀을 이끄는 개발자'는 아니었습니다.

---

2. 진짜 시니어의 3가지 역할

제가 겪으며 깨달은 시니어의 진짜 역할은 다음과 같습니다.

1) '어떻게(How)'보다 '왜(Why)'를 결정하는 사람

주니어는 "이 기능을 어떻게 Redux로 구현할까?"를 고민합니다. 시니어는 "이 기능에 꼭 Redux가 필요한가? Context API로 충분하지 않을까?" 혹은 "이 기능을 지금 개발하는 게 비즈니스적으로 옳은가?"를 고민해야 합니다.

기술적 화려함보다 비즈니스 임팩트와 유지보수성을 기준으로 기술 스택을 결정하는 능력, 그게 시니어의 핵심 역량입니다.

2) 모호함을 없애주는 사람 (Dealing with Ambiguity)

기획서가 부실하게 넘어왔을 때, 주니어는 "기획서가 이상해서 개발 못 해요"라고 멈춥니다. 시니어는 기획자, 디자이너를 찾아가서 빈 구멍을 메우고, 기술적 제약 사항을 설명하며 대안을 제시합니다. 모호한 요구사항을 명확한 기술 스펙으로 변환(Translation)하는 능력이 필요합니다.

3) 팀의 병목을 뚫어주는 사람 (Force Multiplier)

자기가 10인분의 코드를 짜는 것보다, 팀원 5명이 2배의 효율을 내게 만드는 것이 훨씬 가치 있습니다.

• 반복되는 삽질을 막기 위한 가이드 문서 작성.
• 코드 리뷰를 통해 설계적 결함 미리 차단.
• 개발 환경 자동화(CI/CD)로 노가다 제거.

이것이 제가 놓치고 있던 '팀 전체의 속도'였습니다.

---

3. 시니어의 무기 - "안 된다"고 말하는 용기

예전의 저는 "모든 걸 할 수 있다"고 말하는 게 실력인 줄 알았습니다. 그래서 무리한 일정에도 "네, 해보겠습니다"라고 하고 야근으로 때웠죠.

진짜 시니어는 "No"를 할 줄 알아야 합니다.

• "그 일정으로는 테스트 코드를 못 짜서, 나중에 버그 수정에 시간이 더 들 겁니다."
• "지금 이 구조로는 확장성이 없어서, 나중에 다 갈아엎어야 합니다."

무작정 거절하는 게 아니라, 기술적 부채(Technical Debt)의 이자를 계산해서 비즈니스팀에 경고해 주는 것. 그게 전문가로서의 태도입니다.

---

4. 멘토링 - 정답을 알려주지 마라

처음 멘토링을 할 때 저는 '인간 스택오버플로우'였습니다. 후배가 물어보면 바로 정답 코드를 알려줬죠. 그러자 후배들은 저에게 의존하기 시작했고, 제가 휴가를 가면 업무가 마비되었습니다.

좋은 멘토링은 질문하는 법을 가르쳐주는 것입니다.

• "왜 그렇게 생각했나요?"
• "이 방식의 트레이드오프는 뭘까요?"
• "공식 문서는 찾아봤나요?"

스스로 답을 찾게 도와주는 것이 진정한 성장 지원입니다.

---

8. 일정 산정의 기술 (The Art of Estimation)

주니어는 "최상의 시나리오"를 기준으로 일정을 산정합니다. "로그인 페이지? 4시간이면 짜죠." (버그 없음, 회의 없음, 스펙 변경 없음을 가정)

시니어는 "현실"을 기준으로 산정합니다. "OAuth 붙여야 하고, 모바일 호환성 체크해야 하고, 에러 처리까지 하려면 3일 걸립니다."

약속을 적게 하고 더 많이 보여주는 것(Under-promise, Over-deliver)이 낫습니다. 시니어의 일정에는 다음 시간들이 포함되어야 합니다:

• 코드 리뷰 대기 시간
• 예상치 못한 버그 수정
• 컨텍스트 스위칭(회의, 메신저)
• QA 피드백 반영

시니어에게 추정(Estimate)은 '추측'이 아니라 '약속(Commitment)'입니다.

---

5. 갈등 해결 - 공감 능력 (Empathy)

기술 토론은 종종 감정 싸움이 됩니다. "React가 Vue보다 낫다", "탭이냐 스페이스냐". 주니어 개발자는 팩트(Fact)로 상대를 이기려 듭니다. 시니어 개발자는 상대방의 맥락(Context)을 이해하려 합니다.

"왜 저 사람은 NoSQL을 쓰고 싶어 할까? 스키마 변경이 두려운가?" "NoSQL은 구려요"라고 말하는 대신, "우리가 필요한 유연성이 구체적으로 뭔가요?"라고 물어봅니다.

상대방의 우려를 인정해주고("X 때문에 걱정하시는군요"), 적이 아닌 협력자로 만드는 것. 소프트 스킬이 가장 하드한 스킬입니다.

---

6. 시스템 설계 - 트레이드오프 (Trade-off)

"최고의 기술(Best Practice)"은 없습니다. 오직 트레이드오프만 있을 뿐입니다.

• 마이크로서비스? 팀 확장에 좋지만, 디버깅이 지옥입니다.
• 서버리스? 트래픽이 적을 땐 싸지만, 많아지면 파산합니다.
• SQL? 데이터 무결성은 좋지만, 수평 확장이 어렵습니다.

주니어는 "정답"을 찾습니다. 시니어는 묻습니다. "이 이점을 얻기 위해 우리는 무엇을 희생하고 있는가?"

"지루한 기술"을 선택한 이유를 명확히 설명하고, 그로 인한 단점을 인지하고 있다면 당신은 이미 아키텍트처럼 생각하고 있는 겁니다.

---

7. 상사 관리 - 비즈니스 언어로 말하기 (Managing Up)

CTO나 CEO는 "리덕스 리팩토링"에 관심 없습니다. 그들은 "기능 출시 속도"와 "고객 유지율"에 관심이 있습니다.

나쁜 소통: "레거시 코드가 스파게티라서 리팩토링해야 해요." (개발자 입장)

시니어의 소통: "지금 코드는 신규 기능 개발 속도를 50% 저하시킵니다. 지금 2주를 투자해서 리팩토링하면, 4분기 로드맵을 한 달 더 빨리 달성할 수 있습니다." (비즈니스 가치)

코드 문제를 비즈니스 가치로 번역하세요. 그래야 리소스(시간, 인력)를 지원받을 수 있습니다.

---

5. 마무리 - 시니어는 직급이 아니라 태도다

연차가 10년이 되어도 주니어 마인드인 사람이 있고, 3년 차라도 시니어처럼 일하는 사람이 있습니다.

당신이 오늘 작성한 코드가 아니라, 당신 덕분에 팀원들이 얼마나 더 편하게 일했는가? 당신의 결정 덕분에 회사가 얼마나 큰 리스크를 피했는가?

이 질문에 대답할 수 있다면, 당신은 이미 훌륭한 시니어입니다.

---

---