퇴사 회고
2025년 12월 9일 - #퇴사
Table of Contents
들어가며
전 회사에서 개발팀 팀장으로써 20년 넘게 축적된 레거시 청산과 교체 그리고 기술 개선을 해 왔다. 신규 사이트 및 API 개발은 현재 팀 그리고 회사에서 사용중인 기술개발스택을 고려해 결정 후 진행했다.
레거시 위주의 업무와 신규 개발을 병행할 수 있도록 체질 개선을 했고, 코드 품질이 과거에 비해 많이 좋아졌다1. 또한 타 부서의 요구사항 또는 개발 도중 프로세스에 문제가 생겼을 시 적극적으로 피드백 및 개선을 하는 커뮤니케이션을 진행했고, 해당 부서도 만족할 수 있는 결과를 내려고 노력을 했고 과거에 비해 신뢰도가 높아졌었다.
하지만, 새로온 기술 리더(임원)의 출근 2일차 발언이 모든 흐름을 한순간에 뒤집었다.
“지금까지 해왔던 건 전부 무시하겠다. 내가 들은 걸로 판단하고, 내가 원하는 방식으로 바꾸겠다.”
그 외 여러 변화가 있었고, 최종적으로 나는 퇴사를 결정했다.
이 글은 퇴사이유 그리고 미래의 내가 타산지석으로 삼아야 할 것들에 대한 내용을 작성한 글이다.
그리고 이 글은 특정 사람을 비난하려는 목적이 아니라, 기술 조직이 왜 붕괴하는지, 무엇이 조직을 흔드는지 공유하기 위한 기록이다.
내용
조직의 역사와 현 상황을 고려하지 않을 수 없음
어느 조직이던지 합류하게 되면 업무를 어떻게 하는지, 어떻게 해야 하는지를 파악하는 온 보딩(On Boarding)을 거친다. 임원도 마찬가지이다. 온 보딩 이후 본격적으로 업무를 진행하며, 개선을 해 나가면서 조직이 발전하고 개인 또한 발전하게 된다 (물론 이를 받아들일 수 있는 조직이 발전하고 개인의 성취감이 높아진다).
새로운 기술 리더는 오자마자 기존 기술 스택과 운영 구조 전부를 무시했다. 사실 기술개발 스택을 바꾼다는 건 문제가 되지 않는다. 문제는 오자마자 기술, 사람, 업무 방식을 이해하려는 노력 없이 기존을 전면 부정했다는 점이다.
- 20년 넘는 서비스 운영 히스토리
- 도메인 지식
- 누적된 기술부채
- 개선 중이던 구조
- 레거시 처리 경험
이 모든 걸 “없던 것처럼” 할 수는 없다.
기술 스택 전환 과정은 선언이 아니라 과정
팀장으로 재직 시 PHP 레거시 외 신규 프로젝트는 Laravel + Vue (Inertia.js) + Docker 를 이용해 개발을 진행하고 있었고 이를 이용해 만든 서비스가 운영되고 있었다. Laravel을 사용한 이유는 기존 개발자들이 가장 빠르게 습득할 수 있는 프레임워크가 Laravel이였기 때문이였다.
새로운 기술 리더는 오자마자 Laravel + Vue 기반에서 운영 중이던 서비스에 대해, Java로 전면 전환하겠다고 밝혔다.
하지만 전환에는 최소 다음이 필요하다.
- 도메인 분석
- 레거시 이해
- 단계적 마이그레이션
- 병행 운영 기간
- 성능/보안 문제
- 조직 교육과 문서화
그 어떤 단계도 준비되지 않은 상태에서 “전면 전환”은 기술 리스크가 아니라 사업 리스크이다.
리더십의 첫 발언이 조직 분위기 결정
“기존 다 무시하겠다”, “인턴도 파트장 할 수 있다”, “평가는 내가 새로 한다”와 같은 “무시”와 “불신” 발언은 개발자들에게 불안감을 가져오고 방어 모드로 들어갈 수 밖에 없을 것이다.
역으로 생각하면 새로운 기술 리더는 기존 개발자들을 포함한 다른 부서 직원들에게도 업무 및 소프트 파워 능력을 인정을 받아야 한다. 이는 시간을 필요로 하는데, 그 시간없이 오자마자 저런 발언으로 볼 때 기존 직원들이 인정하고 따를 사람들이 누가 있겠는가.
기술 판단보다 구조 개편 집중
새로운 기술 리더는 오자마자 “파트장(실장급)도 내릴 수 있다”, “인턴도 파트장 할 수 있다”, “내가 판단해서 직책 정하겠다”, “내가 만든 양식에 일일 업무일지 작성” 와 같은 통제 방식을 내세웠다. 기술 방향에 대한 합리적 논의보다는 오자마자 구조 및 권한 개편이 중심이 된 것처럼 느껴졌다.
개발자 동요
결과적으로 위와 같은 일들 때문에 개발자들이 동요하기 시작했고, 이를 어떻게 할 수 없었다. 결과적으로 다른 두 분과 나는 퇴사를 하게 되었다.
퇴사
새로운 기술 리더가 온지 몇 주 만에 퇴사 절차가 이루어졌다. 새로운 기술 리더의 윗분인 대표이사(회장 바로 아래) 와의 퇴사면담에서 대표이사는 외주 개발 및 재입사 등을 제안했지만, 전부 거절했다. 대표이사는 연락하고 한달에 한번 만나서 저녁밥 먹자고 했지만, 진짜였다면 본인이 먼저 나섰을 것이다.
마치며
결과적으로 “더 이상 일할 수 없는 환경”이 만들어졌기 때문에 퇴사를 하게 되었다.
위에서 서술했듯이 기술은 더 나은 방향으로 변경할 수 있고, 변경해야만 한다. 하지만 사람과 조직에 대한 존중이 없었으며 업무 이력과 프로세스를 무시하고 업무 히스토리를 무시한다면 어떤 기술도 조직을 발전시킬 수 없다. 결국 조직은 나아가고자 하는 방향으로 움직이지 못할 것이다.
이것은 내 입장과 경험일 뿐 물론 그분에게도 나름의 판단과 이유가 있었을 것이다.
내가 경험한 이 과정은 현재의 나보다 더 나은 리더가 되기 위해 반드시 거쳐가는 과정이라 생각한다. 언젠가는 이 경험이 나에게 크나큰 경험이 될 것이며, 매우 소중하게 쓰여질 것이다.
- 1.정적코드분석(PHPStan, ESLint), 코드 포매터(Pretter), Git 커밋 메시지 포맷(Conventional Commmit) 도입, 코드 리뷰 진행↩