[Medium] 개발자로서 살아남기: 해고를 피하는 두 가지 방법
엔지니어링 매니저로서 팀원들의 승진을 돕고, 처음으로 개발자로 입사할 기회를 제공하는 것은 큰 보람입니다. 물론, 끝없는 회의가 그 보상인 것은 아니지만요.
반면, 팀에서 누군가를 내보내야 하는 불편한 순간도 경험했습니다. 어렵게 첫 개발자 직무를 얻었지만, 얼마 지나지 않아 해고된 주니어 개발자들과 이야기를 나눈 적도 있습니다.
이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다.
대부분의 경우, 당신의 잘못이 아닙니다
아무리 좋은 코드를 작성하고 기대치를 충족하더라도 해고될 수 있습니다. 안정적인 직장은 존재하지 않습니다.
구조조정, 무능한 관리자, 회사 합병, 심지어 사무실을 파괴하는 소행성(?) 같은 변수도 있습니다.
이러한 상황을 완전히 피할 수는 없지만, 다시 무료로 코드를 작성해야 하는 상황을 방지할 수 있는 두 가지 방법이 있습니다.
1단계: 목표를 명확히 설정하기
개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.
- 90일 계획 없음
- 매니저 피드백 없음
- 본인은 잘하고 있다고 생각하지만 팀원들은 답답해함
- 그리고 갑작스러운 해고 통보
본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.
대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다.
그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.
특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다.
예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.
- 1~30일
- 로컬 환경에서 모든 레포지토리를 실행
- 코드 리뷰 및 배포 프로세스 이해
- 적어도 2개의 작은 기능을 프로덕션에 배포
- 30~60일
- 온콜(On-call) 로테이션 참여
- 주요 장애 대응 프로세스 학습
- 소프트웨어 개발 라이프사이클 이해
- 작은 버그를 혼자 해결
- 60~90일
- 중급 난이도의 기능 개발 및 배포
- 기술적 논의에 기여
이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다.
2단계: 본인의 성과를 알리기
만약 중요한 기능을 개발하고, 신입 사원을 온보딩하며, 주니어 개발자들을 돕는 등 여러 일을 했다고 가정해 보겠습니다. 연말 평가가 다가오면 꽤 뿌듯할 것입니다.
그런데, CEO가 새 요트를 사기 위해 10% 감원을 결정했을 때, 본인이 정리해고 명단에 포함된다면 어떨까요?
일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다.
그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다.
예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다.
그렇다면 어떻게 해야 할까요?
👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.
- 중요한 문제를 해결했나요?
- → 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기
- 새로운 기능을 출시했나요?
- → 다음 회의에서 직접 데모를 진행하기
마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다.
이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다.
당신의 성공을 바랍니다
이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다.
저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다.
제 목표는 단순히 해고를 피하는 것이 아닙니다.
기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다.
첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다.