(회고) 퇴사 회고 Part.1
📝 작성 배경
조금은 늦은 나이에 개발자로 전향을 하고 23년도 1월에 처음 월급을 받으며 개발자로 일을 할 수 있게 되었는데,
어느덧 3년차가 되는 올해 작년에 이어 두번째 퇴사를 하게되어 퇴사에 대한 회고 겸 돌아보는 시간을 갖고자 글을 작성하게 되었다.
간략하게 첫 퇴사에 대해 적어보면
24년 지방에서 개발자로 일을하고 있을 때 어떻게 하면 좀 더 좋은 방향으로 성장할 수 있는 개발자가 될 수 있을지 고민이 정말 많았는데,
이 시기에 운이 좋게도 여러 밋업에 참여하게 되었는데 매번 밋업 참석을 위해 지방에서 서울로 왔다갔다 하면서, 지방에서 좋은 개발자로 성장하는건 조금은 어려울수도 있을것 같다는 생각이 들었다.
(물론 그 외에 어려울것 같다 생각하게 된 계기는 정말 다양하게 있었다.)
서울에 있는 회사를 다니며 좀 더 다양한 사람들에게서 좋은 개발자에 대한 인사이트를 얻고 싶다는 생각을 하게 되었고,
그렇게 생각한 지 채 한달이 되기 전 서울에 있는 회사로 이직을 하게 되면서 퇴사를 하게 되었다.
두번째 퇴사
왜 퇴사를 하게 되었는지.
개발자로서의 목표
이 회사를 처음 들어오고자 했을 때 개발자로서의 목표는 플랫폼 개발하고 싶다는 생각 때문이였다.
기존 회사의 경우는 솔루션 회사였고, 일정한 트래픽과 사용자도 고정되어 있는 형태였는데,
특정 사용자를 위한 솔루션을 개발하는건 늘 반복적인 기능 개발에 한정이 되어 있다 생각하게 되었고, 1년 4개월간 한 싸이클을 경험해봤을 때 실제로도 반복적인 기능 개발만 하고 있어 조금은 아쉽다는 생각이 들었다.
(다양한 좋은 방향에 대해 시도는 해봤지만, 신입 개발자가 할 수 있는건 거의 없었다.)
현재 회사에서 개발 하던 플랫폼은 불특정 다수가 이용하는 플랫폼이였고, 그 당시 내가 느끼고 있는 갈증을 해소시켜 줄 수 있을거라 생각했다.
하지만, 내 기대와는 다르게 입사 후 플랫폼을 봤을 때 불특정 다수가 이용할 수 있는 플랫폼인것은 맞으나 사용자가 전혀 없는 플랫폼이였다. 말 그대로 사용자가 전혀 없었다.
거기다 회사의 사업 방향성이 24년도에 많은 변화가 발생하면서 해당 플랫폼 사업은 접게 되면서 그마저 있던 플랫폼 마저 더 이상 개발되지 않는 상황이 되었다. 이 회사에 입사하면서 내가 경험하고 배울 수 있을거라 생각했던 부분이 사라져버리게 되었다.
사실 이건 퇴사에 그리 큰 영향을 주진 못했다. 플랫폼을 하지 못하게 되었고, 다시 솔루션 개발을 하게 되었지만,
그 안에서 정말 다양한 기술을 좋은 사람들과 학습하면서 고도화 하는 작업 또한 개발자로서의 만족감을 높여주는데
부족함이 없었기 때문이다.
내가 퇴사를 결심하게 된 가장 큰 이유는 개발자로서의 이유가 아닌 다른 이유였다.
개발자 외적 목표
개발자가 되고 회사를 다니며 개발자 외적으로의 목표는 생각해본적이 없었다. 목표라기 보다는 개발자 외적으로 회사가 나에게 줬으면 하는 바람이 있는데
그건 바로 안정성이다. 이 회사를 다니기 전에는 안정성이라는건 생각해본적이 없었다. 개발자로 일을 하기 전에 다양한 일을 해봤고 여러 회사를 다녔었는데,
단 한순간도 “다니고 있는 회사가 망하면 어떻게 하지” 라는 고민을 해본적이 없었다. 그러나
24년도 이직 이후 9월, 12월 두번의 구조조정을 겪으면서 회사가 주는 안정성이 매우 중요하다는걸 느낄 수 있었다.
24년 5월에 이직 후 4개월이 지난 시점에 회사가 어려워 구조조정을 하게 되었고, 몇몇 분들이 회사를 떠나게 되었다.
이후 워크샵에서 다시는 이런일이 없을것이라는 대표님의 말씀과는 다르게 12월
다시 한번의 구조조정이 있었고, 정확하게 기억이 나진 않지만 130여명의 회사분들 중 꽤 많은 분들이 회사를 떠나게 되었고,
그 중에는 24년도에 입사한 분들도 꽤 많았다.
이런 일을 겪다보니 회사가 주는 안정성에 대한 생각을 하게 되었고, 회사를 보는 또 다른 시야가 생기게 되었다.
정말 왜 퇴사를 하는가?
개발자 외적 목표에서 말헸듯이 현재 회사는 매우 불안정한 상태였고, 나는 이게 25년에 해소가 될 수 있을거라 생각했다.
(지금 돌아 보니 최소한 불안정한 상태는 조금 나아질거라 생각했던것 같다.)
이유가 있는 구조조정이라 생각했고, 앞으로 회사가 나아가는 방향성은 확고하며 그 방향성에 조금은 불필요한 인원을 정리한것이라 생각했다.
하지만 25년 상반기 그리고 지금을 봤을 때 그게 아니라는 생각이 들었다.
아직 회사의 방향성은 정해지지 않았으며, 자금의 흐름 또한 다시 어려워지고 있었다.
올 한해 목표했던 매출액의 채 10% 도 채우지 못했으며, 여러 굵직한 사업건들이 있었지만 현재 그 사업들 중 단 한건도
결실을 맺은 사업이 없다.
물론 경영진 분들이 우리에게 모든걸 말해 줄 순 없으니, 회사의 현 상황은 내가 생각하는것 보다 덜 심각할 수 있다.
하지만 어떠한것도 이뤄지지 않은 채 마냥 불안해 하고만 있을순 없었다.
이게 내가 두번째 퇴사를 하게된 가장 큰 이유다. 회사가 주는 안정성이 전혀 없었고, 경영진분들이 말하는 회사의 방향성에 대해 공감하지 못한 이유.
회사에서 배운 것
업무를 진행하면서 아쉬운 점을 바탕으로 다양한 부분에서 깨달음을 얻을 수 있었던 것 같다.
기술
회사와 팀에서 사용 중인 기술은 기술에 있어 진취적이어서 정말 다양한 기술을 사용하고 있다. (Spring WebFlux, k8s, MSA 등등)
인프라의 경우는 클라우드와 사내 IDC를 함께 사용하고 있었으며, 클라우드는 AWS, GCP를 사용하고 있다. 정말 다양한 환경 그리고 다양한 기술을 사용하고 있어, 다양한 기술을 접해볼 수 있었다. 이렇게 사용하는 기술이 많다 보니 다양한 기술을 접해 볼 수 있었고, 하나하나의 기술을 깊이 있게 공부하기는 어려웠지만, 대략 어떻게 사용되는지는 알 수 있었다.
다만, 이 기술을 우리가 제대로 활용하고 사용하고 있는 게 맞는 건지 이 부분에 대한 의문이 종종 생길 때가 있었다. 새롭게 적용한 기술로 인해 운영의 편리함이나, 성능의 이점을 얻는 게 아니라 시스템 설계적으로 복잡해지고,
난잡해진 것 같다는 느낌을 떨쳐낼 수가 없었기 때문에 이런 생각이 들었던 것 같다.
다양한 기술을 사용해 보는건 좋지만 새로운 기술을 실무에 적용시킬 때 는 조금은 보수적으로
접근해야 한다는 깨달음을 얻을 수 있었다.
적졀한 기술을 적절한 시기에 적절한 곳에 사용할 수 있도록 하는것도 개발자의 중요한 역량중에 하나라는 생각을 하게 되었다.
프레임워크
혼자 사이드 프로젝트를 진행 할 때 스프링을 주로 사용하면서 스프링에서 제공해주는 기능 외적으로
내가 직접 개발한 기능들을 사용하곤 하는데, 회사에서는 그러면 안될 것 같다는 생각을 많이 하게 되었다.
회사에서 이전 개발자 분들이 스프링을 사용하면서 정말 다양한 부분을 커스텀해서 사용했는데,
이게 진짜 많은 문제를 일으켰다. 우선 스프링을 사용하고 있는데 전혀 스프링을 사용하고 있다는 느낌을 받을 수 없었고
문제가 생겨 디버깅을 해야하는데 커스텀한 부분이 문제가 되면 디버깅하는 난이도가 엄청 높아졌다, 콘솔에 찍혀 있는 로그로 문제 파악 하기 힘들었고, AI 조차 엉뚱한 답변을 줄 정도였다.
그나마 codex
나 claude code
를 사용하면서 조금은 해소가 되었는데 프레임워크는 프레임워크 답게 사용해야 한다는걸 많이 느꼈다.
핵심 도메인 로직이 프레임워크에 의존성이 없도록 작성하는건 찬성하는 부분이지만, 사용해야 하는 곳에는 사용하는게 좋은게 아닐까?
우리가 왜 스프링 같은 프레임워크를 사용하는지 다시한번 생각해 볼 필요가 있을것 같다.
(업무를 진행하면서 해당 프로젝트에 사용된 프레임워크 자체를 변경하는 경우가 얼마나 있을까?)
그 외
내가 생각하는 좋은 개발자는 내가 없어도 내가 작성한 코드를 디버깅하고 설계한 시스템을 운영할 수 있도록 수단을 만들어 두는 개발자가 좋은 개발자 인것 같다.
여기서 말하는 수단은 문서가 될 수도 있고, 잘 작성된 코드가 될 수도 있고, 그외 여러가지가 있을것 같은데 이걸 꼼꼼하게 챙기는 개발자는 생각보다 많지 않은것 같다.
어느순간 좋은 개발자가 어떤 개발자일까? 라는 생각을 할때 위 와 같이 생각을 하게 되었는데, 다시 한번 이 회사를 거치면서 느끼게 되었다.
기술을 적용시키는 사람이야 있어 보이는 기술 적용 시키고 이력서 한줄 추가 해서 떠나면 그만이지만,
결국 그걸 운영하고 관리하는건 남아 있는 사람들의 몫이라는걸 모두가 조금은 생각해 좋으면 좋을것 같다.
아쉬운 점
성장
지금 회사는 인공위성을 활용한 솔루션을 주력으로 하고 있는데, 이게 참 어렵고 희귀한 도메인이다 보니.
입사 초기에는 회의를 할때 진행한 내용준 10%도 이해하지 못한 경우도 있을 정도 였다.
아쉽게도 회사 내부에 도메인 교육이나, 도메인 전문가가 없어서 주위 개발자 분들에게 여쭤보거나 검색을 하면서
배워나갔어야 했는데 이 과정이 정말 오래걸리고 힘들었다. 입사 후 1년은 백엔드 개발자로 성장하는게 아니라
도메인 지식을 학습하고 배우는데 시간을 사용했다. 한 1년쯤 그렇게 하니까 무의식 중에도 회사 분들이 이야기하는 내용들이 귀에 들어오기 시작했다.
이 시기에 백엔드 개발자로서의 성장은 멈춰 있던것 같아 이부분이 참 아쉬웠다. 모든걸 챙길 수 있었으면 좋았을텐데 쉽지 않았다.
이건 항해 플러스라는 과정을 진행하면서 더욱 많이 느끼게 되었다. 1년4개월 동안 벡엔드 개발자로의 성장은 거의 멈춰 있었던것 같다는 느낌을.