“어이 신입, 탈출각이다”

9분

1일 전

5.9K

서론: 나의 첫 번째 착각, 그리고 그 대가

나는 첫 회사로 모두가 선망하는 거대 테크 기업 대신 작은 개발팀이 있는 일반 서비스 기업을 택했다. 이유는 단순했다. 거대 테크 기업보다 입사 허들이 낮아 빠르게 현장에 들어갈 수 있으면서도, 실제 사용자에게 닿는 서비스를 직접 다루며 값진 경험을 쌓을 기회가 있기 때문이었다. ‘언제든 배울 수 있는 최신 기술을 익히기보다 현장에서 부딪히며 성장하는 경험이 더 값지다’라고 생각했기에, 나는 현장을 선택했다. 그러나 현실은 냉혹했고, 내 순진한 기대는 곧 차가운 벽에 부딪혔다.

기술적 의사결정이 대부분 외부의 손에 맡겨진 구조, 동료의 성장에 대한 무관심, 코드 리뷰와 피드백이라는 개념 자체가 존재하지 않는 환경, 그리고 모든 것을 임기응변과 개인의 희생으로 메우는 주먹구구식 운영 시스템까지. 이 모든 것이 보이지 않는 족쇄가 되어 나를 짓눌렀다. 매일 코드를 짜고 기능을 배포했지만, 이곳에서는 성장이 아닌 생존을 위한 사투를 벌이고 있다는 감각만이 선명해졌다.

그런 위기감 속에서 성장의 한계를 뼈저리게 체감하고 더 나은 개발자로 자라고자 용기를 낸 과정을 기록한다. 과거의 나처럼 현재 자신이 속한 환경에 의문을 느끼며 “내가 너무 불평만 하는 걸까?”, “이직이 과연 옳은 판단일까?”라고 밤새워 고민하는 주니어 개발자들에게 하나의 사례가 되기를 바랐다.

이 글은 단순한 퇴사 이야기가 아니다. 한 명의 주니어 개발자가 스스로를 불합리한 환경으로부터 지켜내고 진짜 성장을 찾아 나선 여정에 관한 이야기이며, 지금 당신이 겪는 고민이 결코 혼자만의 것이 아니라는 걸 말해줄 목소리다.

1. 열정과 번아웃 사이

퇴근 후에도 원격으로 코딩을 이어가는 것이 당연해졌다. 낮에 미처 완성하지 못한 코드를 집에서 마무리하는 것이 열정이며, 나 아니면 이 일을 챙길 사람이 없다는 책임감의 발현이라고 믿었다. 하지만 어느 날 문득, 깊은 밤 모니터 불빛에 비친 내 모습을 보며 “이대로 괜찮을까?”라는 질문이 머릿속을 떠나지 않았다.

입사 초반에는 오히려 기회라고 생각했다. 자동화된 시스템이 없고 체계가 잡혀있지 않다는 건 반대로 내가 주도적으로 무언가를 개선할 여지가 많다는 의미였기 때문이다. 당시 우리 시스템은 마치 블랙박스와 같아서 장애가 발생해도 어디서 무슨 일이 일어나는지 알 길이 없어 온종일 로그만 뒤져야 했다. 그래서 나는 프로메테우스(Prometheus)로 각종 지표를 수집했고, 그라파나(Grafana)로 대시보드를 만들었다. CPU 사용량, 메모리 점유율, API 응답 시간이 실시간 그래프로 한눈에 보이자 장애 대응 속도가 눈에 띄게 빨라졌다.

하지만 팀원들의 반응은 “이제 좀 편해졌네”가 전부였다. 그 누구도 이 시스템의 원리나 구성 방식, 혹은 추가로 개선할 부분에 대해 묻지 않았다. 기술적인 성취의 기쁨은 나 혼자만의 것이었고, 조직 내에는 기술적인 대화를 나눌 동료가 없었다. “이 부분의 데이터베이스 쿼리 성능을 개선해야 할 것 같아요” 혹은 “정기적으로 기술 공유 스터디를 하는 건 어떤가요?” 같은 나의 제안은 공허한 외침이 되었다. 중요한 아키텍처는 늘 외부 업체에 의해 결정되었고, 나는 그들이 남기고 간 시스템을 설계의 근거도 모른 채 받아 유지보수 하는 역할에 머물렀다. ‘성장하고 있다’는 감각은 희미해지고, 그저 ‘버티고 있다’는 느낌만이 나를 지배하기 시작했다.

열정이라고 믿었던 것은 사실 번아웃으로 가는 급행열차의 티켓이었다. 책임감이라고 포장했던 무언가는 언제 터질지 모르는 시스템에 대한 불신의 다른 이름이었다.

2. 돌아보면 이상했던 것들

그때는 당연하게 여겼던 회사의 시스템은 건강한 개발 문화의 관점에서 돌이켜보면 분명한 적색 경고였다. 일하면서는 미처 알아채지 못했던, 혹은 애써 외면했던 위험 신호들을 다시 되짚어본다.

첫째, 코드 리뷰가 존재하지 않았다. 내가 작성한 코드는 어떤 동료의 검토도 거치지 않고 git push와 동시에 그대로 반영되었다. 한번은 포인트 통계 페이지를 구현했는데, 특정 조건에서 데이터가 전혀 조회되지 않는 버그가 숨어 있었다. 하지만 동료 누구도 문제를 지적하지 않았고 나 역시 검토의 필요성을 느끼지 못한 채 배포가 이뤄졌다. 버그는 뒤늦은 검수 단계에서 발견되었다. 식은땀을 흘리며 급히 코드를 수정했던 그 경험으로 내 코드에 그 누구도 책임감을 느끼지 않는다는 사실을 깨달았다. 이곳에서는 ‘빠른 구현’만이 미덕이었고 코드의 품질이나 안정성과 같은 장기적인 가치는 논의의 대상조차 되지 못했다.

둘째, 시스템의 주인이 우리가 아니었다. 대부분의 핵심 시스템은 외주 업체가 초기에 구축했고, 우리는 그것을 이어받아 유지보수 했다. 이는 단지 일을 떠넘겨 받는 것 이상의 심각한 문제를 낳았다. 우리는 해당 아키텍처가 왜 그렇게 설계되었는지, 어떤 기술적 트레이드오프 끝에 그런 선택이 나왔는지 전혀 알 수 없었다. 설계의 맥락조차 이해하지 못한 채, 이미 낡고 불안정한 기반 위에 새로운 코드를 덧대는 ‘땜질’의 연속이었다. 근본적인 구조 개선은 불가능했고, 기술 부채는 눈덩이처럼 불어나 결국 미래의 내가 감당해야 할 몫으로 돌아왔다.

셋째, 장애를 대하는 태도가 안일했다. 한번은 우분투 서버의 자동 업데이트 과정에서 발생한 데드락으로 인해 전체 서비스가 다운된 적이 있었다. SSH 접속을 포함한 모든 네트워크가 마비됐고, 별도 이중화 체계가 없어 IDC에 직접 찾아가 서버 전원을 물리적으로 껐다 켜는 것 외에는 방법이 없었다. 몇 시간의 서비스 중단이라는 그런 아찔한 경험에도 팀이 얻은 교훈은 “재부팅했더니 잘 되더라”가 전부였다. 근본 원인을 분석하고, 재발 방지 대책을 세우는 회고 과정은 당연히 생략이었다. “앞으로는 자동 업데이트를 꺼야겠네”라는 임시방편에 가까운 결론만이 남았다.

넷째, 도구만 있을 뿐 문화는 없었다. 도커(Docker)와 젠킨스(Jenkins)를 도입해 배포 자동화를 구축했지만, 운영은 여전히 체계가 없었다. 배포 절차는 공식 문서가 아닌 담당자의 머릿속에만 존재했고, 인수인계는 “이 버튼 누르고, 저거 실행하면 돼요”라는 식의 구두로만 이루어졌다. 명확한 장애 대응 매뉴얼도, 체계적인 배포 이력 관리도 존재하지 않았다. 도구는 있었지만, 그 도구를 올바르게 사용하는 문화는 없었다.

이 모든 상황 속에서 나는 끊임없이 자문했다. “내가 이상한 걸까? 내가 너무 많은 것을 바라는 걸까? 내 실력이 부족해서 불만만 많은 걸까?” 하지만 시간이 지나고 나서 깨달았다. 문제는 내가 아니라, 성장을 허락하지 않는 환경 그 자체에 있었다는 것을.

3. 부족함이라는 착각

리뷰는 물론 기술적 논의 역시 부재한 환경에서도, 나는 그저 내가 더 열심히 하면 모든 것이 해결될 것이라 믿었다. 동료들이 코드에 관심이 없다면 나라도 더 좋은 코드를 짜기 위해 밤새워 공부하면 된다고 생각했다. 외주 업체가 만들어 놓은 스파게티 구조가 비효율적이라면, 내가 주말을 반납해서라도 리팩토링하면 된다고 믿었다. 그렇게 나는 모든 문제의 원인을 외부 환경이 아닌 나 자신에게서 찾았다.

하지만 이제 막 출발한 개인의 노력은 거대한 조직의 관성과 무관심을 넘어서지 못했다. 내가 제안한 리팩토링 계획은 “지금 잘 돌아가는데 굳이 그걸 왜 건드려요? 리스크만 커져요”라는 차가운 반응에 묻혔고, 새로운 기술 도입 제안은 “우리가 그걸 써본 적이 없어 안정성을 보장할 수 없다”는 이유로 번번이 거절당했다. 조직은 변화에 극도로 둔감했고, 나의 시도는 ‘굳이 일을 만드는 유난스러운 신입’의 치기 어린 행동으로 치부되며 보이지 않는 벽에 부딪혔다.

그때 처절히 깨달았다. 내가 성장하지 못하는 이유는 나의 게으름이나 역량 부족 때문이 아니었다. 애초에 나는 성장이라는 씨앗이 뿌리내릴 수 없는 척박한 땅에 서 있었다. 오히려 환경 탓을 하지 않고 모든 것을 ‘내 탓’으로 돌리던 그 착각이야말로, 나의 자존감을 갉아먹으며 나를 병들게 하고 있었다. 그것은 건강한 책임감이 아니라, “네가 부족해서 그런 거야”라고 속삭이는 환경이 만든 가스라이팅에 가까웠다. 나도 모르게 그 프레임에 갇혀 스스로를 채찍질하고 있었던 것이다.

4. 이직은 도망이 아니다

이직 결심은 충동적인 결정이 아니었다. 매일 경험해 온 조그마한 이상함과 불편함, 무력감이 쌓여 더는 개발자로서의 미래를 그릴 수 없다는 확신이 빚어낸 결과였다. 나는 생존이 아닌 성장을 하고 싶었다. 기술적인 고민을 함께 나누고 더 나은 방향을 찾아 나설 동료를 원했다. 단순히 더 높은 연봉이나 좋은 복지가 아니라, 건강한 개발 문화와 성장 지향적인 동료들이 있는 환경을 찾아야겠다고 결심했다.

이는 나 자신을 불합리한 상황으로부터 지켜내기 위한 가장 적극적인 선택이었다. 현실로부터의 ‘도망’이 아니라 더 나은 미래를 향한 ‘전략적 방향 전환’이었다.

5. 성장 토양 찾기

첫 직장에서 배운 가장 큰 교훈은, 복지나 연봉, 회사 규모보다 “개발자로서 단단히 성장할 수 있는 환경”이 훨씬 더 중요하다는 사실이었다. 그렇게 면접 과정에서도 일방적으로 평가받기보다, 오히려 회사의 문화를 직접 확인하려고 노력했다. 특히 다음과 같은 질문들을 권장한다. 내게는 이들이 회사를 고를 때 길을 잃지 않고 위험한 환경을 미리 걸러낼 기준이 되었다.

리뷰와 피드백의 문화가 있는가?

“팀의 코드 리뷰는 어떤 방식으로 진행되나요?”
“PR(Pull Request)에 보통 몇 명의 리뷰어가 참여하고, 어떤 점(예: 컨벤션, 아키텍처, 테스트 커버리지)을 중점적으로 보나요?”

기술적 판단이 내부에서 이루어지는가?

“새로운 프로젝트를 시작할 때 기술 스택은 누가, 어떤 과정을 거쳐 결정하나요?”
“아키텍처 설계에 팀원들이 참여하고 의견을 낼 기회가 충분히 보장되나요?”

실험과 실패를 장려하는 문화가 있는가?

“개발자가 새로운 기술이나 라이브러리를 도입해보고 싶을 때, 어떤 절차를 거치나요?”
“업무 시간의 일부를 기술 연구나 사이드 프로젝트에 사용할 제도가 있나요?”

6. 새로운 출발선 위에서

돌아보면, 첫 직장이 꼭 나쁜 곳이었다고 단정할 수는 없다. 어떤 이들에게는 안정적이고 만족스러운 직장이었을지도 모른다. 다만 ‘폭발적인 성장을 꿈꾸던 주니어 개발자’인 나에게 맞지 않는 토양이었을 뿐이다. 씨앗이 아무 데서나 뿌리내릴 수 없듯, 개발자에게도 잘 자랄 수 있는 환경이 필요하다. 특히 흡수력이 뛰어난 주니어일수록 첫 커리어를 어디서 시작하느냐가 앞으로 10년, 그리고 개발자로서의 정체성까지 결정짓는다.

내가 느낀 좋은 환경은 단지 최신 기술을 쓰는 곳이 아니었다. 기술과 사람이 함께 성장하는 선순환 구조가 자리 잡은 곳이다. 시니어는 주니어를 이끌고, 주니어의 성장이 다시 팀의 기술력을 끌어올리는 곳이다. 높아진 기술력으로 더 나은 제품을 만들고, 그것이 결국 회사의 성장으로 이어지는 곳이다.

이직은 도망도 실패도 아니었다. 더 나답고, 더 즐겁고, 더 오래 개발자로 살기 위한 현명하고 용감한 선택이었다.

지금 이 글을 읽으며 “뭔가 이상한데?”라는 감각이 든다면, 그 신호를 외면하지 않길 바란다. 그 울림은 나약함에서 비롯된 불평이 아니다. 더 넓은 곳에서 자라야 한다는 당신의 잠재력과 성장 욕구가 보내는 솔직한 메시지일 수 있다. 그 메시지를 믿고, 용기를 내어 주변을 둘러보라. 그리고 이런 목소리에 귀 기울여보라.

“어이 신입, 지금이 탈출각이다.”