IT 프로젝트에서 시니어 개발자를 주니어로 대체하는 것을 어떻게 감지할까

## 벤더가 시니어를 주니어로 대체하는 방식과 이를 알아채는 법

외부 IT 벤더와 진행 중인 프로젝트에서 개발 속도가 몇 배나 떨어졌다 — 예전에는 이틀이면 끝나던 작업이 이제 몇 주씩 끌린다. 이유는 기술 부채나 아키텍처 복잡성 때문이 아니라 시니어 개발자 3분의 1이 조용히 주니어로 교체된 것이다. 이는 고립된 사례가 아니다: 런치 후 클라이언트가 팀 구성을 모니터링하지 않으면 특히 CIS 시장에서 이런 교체가 체계적인 관행으로 자리 잡고 있다.

왜 교체가 눈치채지 못할까

전문가 레벨 교체는 드물게 한꺼번에 이뤄진다. 벤더들은 점진적으로 움직인다: 한 명의 시니어가 "다른 프로젝트로 이동"하고 좋은 이력서를 가진 "거의 시니어"로 교체되며, 한 달 후 또 다른 하나. 클라이언트는 보고서에서 동일한 팀 구조를 확인하고 Jira에서 같은 이름을 보지만 실제 수행자의 실력 수준은 떨어진다. 형식적으로는 계약대로, 실제로는 속임수다.

이런 수법을 가능하게 하는 주요 요인:

• 클라이언트의 교체 승인이 의무화되지 않음.
• 형식적 지표(시간, 스프린트 내 작업 수)에만 집중하고 코드 품질이나 솔루션 깊이는 무시.
• 클라이언트 측 기술 리드나 아키텍트의 참여 부족.

클라이언트가 정기적인 코드 리뷰나 감사를 하지 않고 모든 기술 책임을 벤더에게 떠넘기는 프로젝트가 특히 취약하다. 누가 코드를 쓰는지, 어떻게 쓰는지 확인하지 않으면 속도 저하가 심각해질 때까지 교체가 들통나지 않는다.

위기 전에 교체를 알아채는 방법

마감 압박이 닥치기 훨씬 전에 문제를 감지할 수 있다. 주요 신호는 다음과 같다:

• 객관적 이유 없는 속도 저하 — 작업 복잡도가 늘지 않고 기술 부채도 쌓이지 않는데 작업 완료가 느려지면 첫 번째 신호.
• 재작업과 버그 증가 — 주니어 개발자는 수정이 필요한 실수를 더 많이 한다. QA나 프로덕션에서 버그 비율이 오르면 누가 썼는지 확인하라.
• 코드 품질 저하 — 안티패턴 등장, 표준 무시, 이전에 테스트가 붙어 있던 부분에서 테스트 부재.
• 남은 시니어의 부하 증가 — 핵심 개발자들이 갑자기 모두를 "도와주기" 시작하면 신입들의 낮은 실력을 메우는 것일 수 있다.
• 커뮤니케이션 톤 변화 — 주니어들은 아키텍처 질문을 덜 하고 구체적인 지시를 더 자주 요구하며 복잡한 작업을 피한다.

정기적인 코드 리뷰, 클라이언트 대표가 참여하는 페어 프로그래밍, 지표 분석(예: cyclomatic complexity, coverage, churn rate)이 조기 발견에 효과적이다.

대처법: 예방 조치와 대응

교체를 발견했다면 당황하지 말고 체계적으로 통제를 되찾아라. 단계별 액션 플랜:

• 기술 감사 실시 — 이력서가 아니라 실제 코드와 커밋 히스토리를 기준으로. 어떤 모듈을 만졌나? 얼마나 자주? 품질은 어땠나?
• 교체 투명성 복원 — 벤더가 어떤 전문가 교체도 클라이언트 기술 담당자의 승인을 받도록 계약 조항 추가.
• 주요 역할에 시니어 복귀 — 예산이 허락하면 주니어를 미들/시니어로 교체. 안 될 때는 작업 재분배: 주니어에게 명확한 범위와 문서화된 코드 섹션만 맡김.
• 기술 감독 배치 — 클라이언트 측 아키텍트나 기술 리드 한 명이 주간 리뷰만 해도 교체 위험을 80% 줄일 수 있다.
• 팀 KPI 재설계 — 단순 시간과 완료 티켓 대신 품질 지표 도입: 커밋당 버그 수, 재작업 시간, 변경 커버리지.

시장 레드 플래그

일부 벤더가 이 수법을 의도적인 비즈니스 모델로 쓰면서 상황이 더 악화된다: 시장 요율에 맞춰 시니어 팀으로 클라이언트를 끌어들인 뒤 점진적으로 저렴한 인력으로 교체해 마진을 챙기는 식. 가격 경쟁이 치열한 지역에서 특히 흔하다.

보호를 위한 두 가지 단호한 규칙:

• 시니어 시급 $25 미만 — 레드 플래그. CIS 시장에서 진짜 시니어는 이 수준 이하로 일하지 않는다. 제안이 너무 좋아 보이면 테스트 작업이나 라이브 코딩으로 실력 확인.
• 벤더 측 기술 리드나 PM 부재 — 위험. 기술 리더십이 없는 팀은 실력 저하에 취약하다. 기술 리드는 무자격 교체를 걸러내는 자연스러운 필터다.

핵심 요약

• 시니어를 주니어로 교체하는 건 실수가 아니라 일부 벤더의 마진 확대를 위한 고의적 전략이다.
• 초기 징후: 속도 저하, 버그 증가, 코드 품질 하락 — 위기가 닥치기 훨씬 전에 나타난다.
• 보호책: 교체 승인 의무화, 정기 코드 리뷰, 클라이언트 측 기술 리드 배치.
• CIS 시장 시니어 시급 $25 미만 — 거의 사기.
• 예방이 치료보다 낫다: 프로젝트 시작 시 통제 장치를 내장하는 게 6개월 후 수습하는 것보다 훨씬 낫다.

형식적인 보고서만 믿지 마라. 실제로 당신 코드를 쓰는 사람을 확인하라 — 오늘 당장, 6개월 전이 아니라. 프로젝트 성공은 화려한 이력서가 아니라 키보드를 두드리는 실제 손에 달려 있다.

— Editorial Team