From Hired!… to Fired! Avoid these 2 Developer Career Death Traps
Medium
[Medium] 개발자로서 살아남기: 해고를 피하는 두 가지 방법
이번 글에서는 사람들이 해고되는 가장 흔한 두 가지 이유와 이를 피하는 방법에 대해 살펴보겠습니다.
1단계: 목표를 명확히 설정하기
개발자가 해고되는 가장 일반적인 이유는 기대치 불일치 때문입니다.
90일 계획 없음
매니저 피드백 없음
본인은 잘하고 있다고 생각하지만 팀원들은 답답해함
그리고 갑작스러운 해고 통보
본인에게는 '갑자기'일지 모르지만, 팀원들에게는 그렇지 않습니다.
대부분의 매니저는 일부러 피드백을 주지 않는 것이 아닙니다. 사람들은 본능적으로 갈등을 피하려 합니다.
그러므로 첫 출근 날부터 팀 리드나 매니저와 실질적인 목표를 설정하는 것이 중요합니다.
특히, 첫 1~2개월 동안 성공의 기준을 정리해야 합니다. 만약 매니저가 명확한 계획을 제공하지 않는다면, 스스로 계획을 세워 공유해야 합니다.
예를 들어, 주니어 개발자라면 다음과 같이 설정할 수 있습니다.
1~30일
로컬 환경에서 모든 레포지토리를 실행
코드 리뷰 및 배포 프로세스 이해
적어도 2개의 작은 기능을 프로덕션에 배포
30~60일
온콜(On-call) 로테이션 참여
주요 장애 대응 프로세스 학습
소프트웨어 개발 라이프사이클 이해
작은 버그를 혼자 해결
60~90일
중급 난이도의 기능 개발 및 배포
기술적 논의에 기여
이렇게 하면 '눈치 게임'을 할 필요 없이, 본인의 성장 수준을 명확히 파악할 수 있습니다.
2단계: 본인의 성과를 알리기
일부 조직에서는 매니저가 모든 엔지니어와 직접 소통하지 않습니다.
그 결과, 관리자는 본인을 잘못된 기준으로 평가할 수 있습니다.
예를 들어, 코드 라인 수나 버그 수정 개수 같은 무의미한 지표로 평가받을 수도 있습니다.
그렇다면 어떻게 해야 할까요?
👉 본인의 성과를 자연스럽게 알리는 방법을 배워야 합니다. "자랑"하지 말고, "교육"해야 합니다.
중요한 문제를 해결했나요?
→ 해결 방법을 문서화하고, 간단한 발표를 통해 공유하기새로운 기능을 출시했나요?
→ 다음 회의에서 직접 데모를 진행하기
마지막으로, 본인이 한 모든 중요한 작업을 기록해 두는 것이 중요합니다.
이렇게 하면 연말 평가 때 본인의 가치를 쉽게 증명할 수 있습니다. 이제 당신은 "그 사람 누구였더라?"가 아니라 "그 팀에서 중요한 엔지니어"로 기억될 것입니다.
당신의 성공을 바랍니다
이 글을 읽고 있다면, 아마 개발자로서 커리어를 시작한 지 얼마 되지 않았을 것입니다.
저는 수많은 실수를 했지만, 다행히도 해고당하지 않았습니다. 하지만 이번에 다룬 두 가지 교훈을 배우기까지 4년이 걸렸습니다.
제 목표는 단순히 해고를 피하는 것이 아닙니다.
기술적으로 성장하고, 회사 내에서 돋보이며, 만약 해고당하더라도 빠르게 새로운 기회를 잡을 수 있는 개발자가 되는 것입니다.
첫 취업이 끝은 아닙니다. 진짜 중요한 것은 그 이후입니다.
번역: [https://ducktopia.tistory.com/m/144]
원문:
다음 내용이 궁금하다면?
이미 회원이신가요?
2025년 2월 5일 오전 9:03
댓글 2
좋은 글 감사합니다. 이번에 이직해서 딱 30일 되었는데 운좋게도 이끌어주시는 사수분을 만나서 잘 적응하는 중입니다. 혼자서 해보고싶어도 뭐부터해야하나 막막했는데 가이드대로 하다보면 가지뻗기처럼 쭉쭉 뻗어나갈 수 있기를 기대하면서 우선은 해봐야겠습니다 감사합니다!
- 경기 침체나, 회사가 어려워지는 상황은 개인의 역량과 성과만으로 해결하기 어려움 - 조직 전체가 인력 감축에 대한 압박을 받게 되면, 잘하는 사람도 해고 될 수 있음.(특정 부서가 통째로 폐쇄되거나, 회사가 도산 위기에 놓이면 개인 성과는 큰 영향력이 없음.) “내가 아무리 잘해도, 회사가 돈이 없거나 구조조정이 불가피하면 어쩔 수 없이 내보낼 수밖에 없다는 것”입니다.(컬리도 개발자들 인력감축을 한 것으로 알고있는데 개인의 성과가 정말 크게 작용했나요? 그 잘하던 동료분들도 있었을텐데 그분들은 성과 관리를 못해서 그랬던 부분이 클까요?) 그리고 해고는 단순하게 개인의 성과만으로 결정되지 않는 복합적 요인을가지고 있음. 글에서 제시한 경력관리 측면에서는 유효하나, 해고를 피한다.? 이건 개인의 노력으로 해결이 되는 부분이 아님.(후순위로 선택되는 부분은 있을듯?) 이 글을 보시고, 다들 행복 회로 돌리지 마시고 경영진의 판단, 시장 상황, 투자 환경, 경기 흐름 등 개인이 어찌할 수 없는 부분도 있다는 사실을 간과하면 안 됩니다.
함께 읽은 게시물
< 🔔 내가 만나본 빠르게 성장하는 주니어 개발자들의 특징 >
본론에 앞서 이 글은 그동안 제가 만나본 성장이 빠르다고 느낀 주니어 개발자분들의 태도와 습관을 정리해보는 글입니다.
기술이나 학습등을 거론하며 '이런것만 배우면 당신도 빠르게 성장할 수 있습니다!' 류의 글은 아니고 그분들의 이런 태도와 습관이 성장에 영향이 있지 않았을까 정도의 글이라고 생각해주시면 되겠습니다.
✅️ 질문을 잘한다.
빠르게 성장하신 분들의 질문엔 2가지 공통점이 있었다.
1. 질문의 타이밍
대부분의 신입사원이나 주니어 개발자분들은 선배 개발자에게 질문을 하기 부담스러워 한다. 그래서 혼자 몇일을 끙끙거리다가 힘겹게 질문하거나 선배 개발자가 먼저 말을 걸어서 답을 얻는 모습을 많이 본다.
만약 알고싶던 내용이 선배 개발자가 바로 대답해줄 수 있는 것이었다면 오래 끙끙거린만큼 시간을 허비해버린것과 같다.
질문을 잘하는 분들의 경우 자신들의 고민이 자신이 풀수 없는 수준이라는걸 알게 되면 선배 개발자들에게 바로 질문함으로써 그만큼 시간을 아끼고 다음 스텝으로 나아간다.
2. 질문의 깊이
질문할 때 '이게 뭐에요?' 나 'A 부터 Z 까지 알려주세요' 등의 질문을 하지 않는다.
자신이 충분히 찾아보고 자신의 선에서 최대한 알아본 뒤에 풀리지 않는 부분을 질문한다. 그렇기에 질문의 깊이가 깊다.
이런 질문을 받았을 때 바로 답을 주는 경우도 있지만 대부분 이런 깊이 있는 질문은 정확한 확인을 위해 다시 한번 관련 내용을 찾아보게 만든다.
이로 인해 질문 받는 사람도 알고 있던 내용을 복습하거나 놓쳤던 부분을 공부하게 되고 이를 통해 같이 성장하는 느낌을 받는다. 그래서 나는 이런식으로 질문 하는 분들이 좋고 나도 다른 사람들한테 이렇게 질문을 하기 위해 노력한다.
✅️ 가만히 있지 않는다.
간혹 내 업무가 많이 밀리고 바쁘다보면 주니어 분들을 신경쓰지 못해 그분들의 업무에 공백이 생길때가 있다. 업무를 잘하시는 주니어 분들은 이런 공백도 허투루 지나가지 않고 아래와 같은 행동들을 한다.
1. 업무 혹은 과제를 달라고 요청한다.
2. 팀에서 진행하는 프로젝트에 이슈가 없는지 찾아본다. 혹은 발견된 이슈의 원인을 파악해보려고 한다.
3. 팀에서 진행하는 프로젝트 코드를 분석한다.
4. 팀에서 사용하는 오픈소스나 프레임워크, 라이브러리 코드를 분석한다.
5. 프... 더 보기
Longest Common Subsequence 자바스크립트 풀이
코
... 더 보기
