첫 이직, 수습 종료 회고 & 3분기 MVP 상 수상기

2월 말에 퇴사한 뒤 4개월간 재충전의 시간을 가진 후, 6월 말 새 팀에 합류해 이제 막 수습기간을 마무리했다.
원래는 연말에 올 한 해를 정리하는 회고를 쓰려 했지만, 나름 뿌듯한 소식도 있고 마침 추석 연휴 덕분에 숨을 고를 틈이 생겨서, 중간 점검 삼아 이 마음이 바래기 전에 지금의 생각을 글로 남겨 두려 한다.

첫 이직

비전공자로, 거의 컴맹에 가까웠던 내가 개발을 시작한 지 1년 반. 국비 학원을 거친 뒤 인프런 강의로 약 11개월간 독학하며 개발자 취업을 준비했다. 그 과정에서 실무 코드와 좋은 개발 문화에 대한 환상이 굉장히 컸었다. 그러나 신입으로 전 직장에 입사한 뒤 그 환상들은 금세 깨졌다. 주변에 개발자가 많지 않아 “다른 회사에서는 어떻게 하는지” 비교할 기준도 부족했다. 대신 그 빈자리를 스스로 생각하고 판단하는 시간으로 채웠다. 현 상황에서 무엇을 바꾸면 더 나아질지, 당장 가능한 범위에서 지속 가능한 개선을 만들려면 무엇부터 손대야 할지 재직했던 1년 3개월 동안 주도적으로 고민하고 실행해 볼 수 있었다.

입사를 할 때 적어도 2년은 다니자고 마음먹었었는데, 회사 사정이 어려워지며 급여가 밀리는 일이 발생했고, 맡은 일 안에서 해볼 수 있는 건 거의 다 해봤다는 생각이 들었다. 마침 자바 ORM 표준 JPA 프로그래밍 의 저자이며 인프런에서 스타강사로 유명하신 영한 님과의 1:1 식사권이 당첨됐다. 식사 도중 영한님께 이러한 고민들을 털어놓았었는데, 여러 조언을 해주셨지만 마지막에 “자네도 이미 답을 알고 있잖아?”라고 말씀해주신 것이 가장 기억에 남는다. 내 환경에 대한 한계를 가장 잘 아는 건 결국 나였다. 고민 끝에 내 경험이 더 큰 임팩트로 이어질 무대를 찾아보기로 했고, 퇴사를 결정했다.

퇴사 즈음 스스로 기강(?)을 잡고자 주니어 개발자를 대상으로 하는 부트캠프를 수강했는데, 나와 비슷한 연차의 개발자들을 여럿 만나 각자의 자리에서 더 잘하기 위해 노력하시는 모습들을 보며 좋은 자극을 얻었다. 수료 후에는 여기서 얻은 인사이트들을 바탕으로, 여러 회사에 지원하면서 기준을 좀 더 명확히 설정했다. 첫째, 스타트업에서 쌓은 경험과 역량을 바탕으로 이전보다 더 많은 가치를 낼 수 있어야 한다는 것. 두번째, 주도적으로 일할 수 있는 환경일 것. 셋째, 안정적인 매출 구조를 갖춘 곳일 것. 넷째, 내가 제품을 좋아하고 애정을 갖고 개발할 수 있는지를 가장 높은 기준으로 삼았다. 채용 과정만으로 이 조건들을 100% 확신할 수는 없지만, 적어도 대외적으로 또는 직/간접적으로 이러한 문화와 시스템이 자리 잡았음을 확인할 수 있는 회사를 우선으로 살폈다.

그렇게 이직을 준비하던 중 지금 회사의 코딩 테스트 → 1차 기술 면접 → 2차 컬처핏 면접을 거쳤고, 면접 내내 “여기라면 내가 주도적으로 일하며 성장할 수 있겠다”는 감이 왔다. 그 확신이 최종 선택의 결정적 이유가 되었고, 6월 말 합류를 결정했다.

 

2주 간의 온보딩

합류 이후 2주간 온보딩을 진행했다. 첫 주는 이른바 “개밥먹기”—우리 제품을 직접 써 보며 유저 스토리 플로우와 페인포인트를 몸으로 익히는 제품 온보딩이었고, 둘째 주는 온보딩 과제를 풀어가며 시스템을 손에 익히는 기술 온보딩이었다. 여기서 문제가 하나 있었다. 이전 백엔드 개발자들이 모두 퇴사한 상태라 히스토리를 설명해 줄 사람이 사실상 없었다는 점이다. 한 분이 계시긴 했지만 입사하신 지 이제 막 3개월 되신 분이셔서 전체 시스템 구조와 과거 맥락을 제대로 설명해주시기에는 아무래도 무리가 있었다.

사실 이런 상황이 처음은 아니었다. 전 직장에서도 기존 개발자들이 대거 퇴사한 뒤 신입으로 합류해 초반에 꽤나 고생을 많이 했었는데, 그 경험 덕분에 무엇부터 빠르게 파악해야 하는지 스스로 리스트업할 수 있었고, 매일 늦게까지 남아 아키텍처·배포·운영 플로우를 최대한 빨리 훑었다. 로컬 개발 환경조차 제대로 갖춰지지 않은 상태라 docker-compose로 로컬 인프라를 빠르게 올리는 템플릿을 만들고, 개발 DB를 덤프 떠서 로컬 DB에 주입하는 작업부터 시작했다. 이 세팅은 이후 합류한 동료들이 빠르게 로컬 환경을 구축하는 데에도 도움이 되었다고 생각한다.

2주 차 온보딩 과제로는 마이너 운영 이슈 3건을 해결해야 했다. 가장 기억에 남는 건, 깃허브 레포를 클론하자마자 문서 없이 코드만으로 히스토리를 추론하고 가설을 세우며 원인을 좁혀 가던 시간들이다. 낮에는 온보딩 미팅이 이어져 집중적으로 작업을 할 시간이 부족했고, 매일 야근했음에도 결국 3건 중 2건만 해결할 수 있었다. 이 과정에서 개인적으로 느낀 온보딩 구조의 문제(문서 부재, 환경 세팅 부담, 시간 배분 한계 등)을 정리해 헤드와의 1:1 미팅에서 가감 없이 공유했다. 다음 합류자가 같은 어려움을 겪지 않도록 하기 위한 피드백이었다.
이 미팅에서 내게도 피드백이 있었는데, 일주일 안에 반드시 해결해내야한다는 강박에 사로잡혀 3건 중 한 건을 해결하지 못한 채, 진행 상황을 미리 알리지 못했다는 것이다. 이 피드백을 통해 중간에 공유하는 습관의 중요성을 다시한번 깨닫는 계기가 되었다.

어찌저찌 이렇게 나의 2주간의 온보딩은 마무리가 되었다.

스쿼드 합류, 첫 프로젝트 배포

온보딩 이후 해구대 제품을 개발하는 스쿼드에 배치되어 첫 프로젝트로 카카오 톡스토어 연동을 맡았다. 이후에 다른 오픈마켓 연동 또한 예정되어 있어 해당 프로젝트에서 기존 오픈마켓 연동로직들의 하위 호환성을 해치지 않는 선에서 새로운 오픈마켓을 쉽게 추가할 수 있도록 확장성 있는 구조로 개발하는 것이 해당 프로젝트의 핵심이라고 생각되었다.
적절한 추상화의 범위를 선정하고 가능한 수준에서 기존의 기술부채도 함께 상환하며 개발했다. 배포 이후 톡스토어를 사용하는 셀러들의 숫자가 조금씩 늘어나는 것을 지표로 확인할 수 있어 뿌듯했다.

내가 배포한 기능이 제품 업데이트 노트에도 반영되었다!

 

주도적으로 실행한 여러 개선들

스타트업답게, 보통의 경우에는 ‘당연히’ 갖춰져 있을 거라 기대하는 것들이 비어 있는 부분이 많았다. 개선해야 할 지점도 수두룩했다. 이런 액션 아이템들을 별도 시간으로 할당받아 진행할 수 있으면 좋겠지만 스타트업 특성상 내가 사용할 수 있는 리소스가 제한적이기에, 스쿼드 업무와 병행하여 진행할 수 밖에 없었고, 짬짬히 진행한 개선 목록들은 다음과 같다.

에러 로그 슬랙 알림 구축

서비스를 개발·운영하는 과정에서 가장 중요한 요소 중 하나는 장애가 고객 문의로 이어지기 전에 감지하고 대응할 수 있는 체계를 구축하는 것이라고 생각한다. 많은 회사들이 이미 이러한 모니터링 및 알림 시스템을 갖추고 있을 것이라고 예상했지만(아마도…?), 현재 우리 회사에는 사전 인지를 위한 알림 시스템이 전혀 존재하지 않는 상황이었다.

그래서 비용이 들지 않는 선에서 먼저 할 수 있는 조치를 고민했고, logback을 활용하여 ERROR 레벨 이상의 로그를 슬랙 채널로 전송하는 방식으로 알림 시스템을 구성하여 적용했다.

 

PR 리뷰요청 슬랙 알림

백엔드 개발자가 한 분 더 합류해, 나를 포함해 총 세 명이 되었다.(현재는 한 분 더 합류하여 총 네명) 이 시점에 코드 리뷰 문화를 본격 활성화하자는 의견이 나왔고, 기존 개발자들이 모두 퇴사한 상황에서 코드 리뷰가 저맥락을 고맥락으로 빠르게 끌어올리는 가장 효과적인 수단이라 판단해 적극 동의했다.

다만 PR을 만들 때마다 슬랙 채널에 수동으로 리뷰를 요청하는 방식은 비효율적이었다. 스타트업 특성상 제한된 리소스를 효율적으로 써야 하므로, 이 부분은 자동화하는 것이 좋을 것 같다고 판단했다.

주말을 활용해 GitHub Actions 기반의 PR -> Slack 알림 워크플로를 구현했다. 여러 오픈소스와 사례를 참고했지만 원하는 형태의 레퍼런스가 없어서, ChatGPT와 Gemini CLI를 함께 활용해 결과물이 만족스러울 때까지 반복적으로 다듬었다. 단순히 알림을 주는것을 넘어서 아래 기능들까지 포함하려다보니 3시간이면 만들 수 있을 줄 알았으나 주말 내내 붙잡아서 겨우 완성할 수 있었다.

• 리뷰 코멘트가 달리면 해당 리뷰이를 멘션
• 코드 변경(푸시) 발생 시 자동 Re-request 처리
• 최초 리뷰요청 스레드에서 모든 후속 알림을 이어붙여 맥락 유지

주말 이후 월요일에 바로 팀원들에게 결과물을 공유드리고, 논의를 거쳐 적용했다. 아직 리뷰 규칙과 브랜치 기준 등 세부 룰을 합의해 나가는 단계라 가시적인 효과는 제한적이지만, 이런 작은 개선의 축적이 결국 더 효율적으로 일하는 조직을 만든다고 믿는다.

알림 예시

이렇게 변경사항이 있으면 최초 리뷰요청 스레드로 댓글이 달린다!

 

AWS ECR 라이프사이클 정책 설정

인프라 환경을 훑어보던 중 AWS ECR에 라이프사이클 정책이 설정되어 있지 않아, 이미지가 사실상 무한히 쌓이고 있다는 점을 발견했다. ECR은 사용한 스토리지 용량에 따라 과금되는 구조이므로 이를 방치하면 불필요한 인프라 비용이 계속 증가하게 된다. 이전 회사에서 배포 파이프라인을 구축하며 관련 설정을 다뤄본 경험이 있어, 비교적 간단히 해결 가능한 문제라고 판단했고 즉시 이슈를 제기했다. 이후 모든 레포지토리에 최대 이미지 개수를 제한하는 정책을 적용해, 무제한으로 이미지가 누적되고 있던 문제를 해결할 수 있었다.

미사용 S3 이미지 파일 삭제 배치 개발

전혀 사용되지 않는 S3 이미지가 삭제되지 않아 불필요한 인프라 비용이 발생하고 있었다. 일회성 스크립트로 ‘대청소’를 할 수도 있었지만, 리스크가 크고 재발 가능성도 높았다. 근본적으로 해결하기 위해 Spring Batch 기반의 미사용 파일 식별·삭제 배치를 설계해 재사용 가능한 운영 흐름으로 만들었다. 기대 효과는 월 약 $2,000 절감으로, 규모 있는 개선 과제였다.

문제는 내가 Spring Batch를 실무에서 처음 다룬다는 점이었다. 어떤 ItemReader/ItemWriter 조합을 쓸지, chunk 크기를 어떻게 잡을지 감이 서지 않았다. 단순 구글링이나 AI 답변에만 의존하기보다, 인프런 강의를 수강하며 간단한 예제 배치를 직접 만들어 전체 흐름부터 손에 익혔다. 기본 동작을 구현한 뒤 더미 데이터로 성능을 추정해 보니, 프로덕션 볼륨에서는 완주까지 약 2년이 걸릴 거라는, 꽤 충격적인 계산이 나왔다.

이에 병렬 처리를 도입하고 불필요한 네트워크 I/O를 최소화하도록 호출 단위를 재설계했다. 그 결과 거의 100배에 가까운 성능 개선을 달성했다. 현재는 주기·한도·예외 기준 등 운영 정책을 PM과 합의하며 실행을 앞두고 있다. (세부 개선기는 별도 블로그 글로 정리할 예정이다.)

어플리케이션 아키텍처 개선 PoC

온보딩 직후 백엔드 챕터의 3분기 OKR을 정해야 했는데, 시스템을 전반적으로 살펴보니 가장 먼저 손봐야 할 지점은 애플리케이션 아키텍처를 개선해야 한다고 생각했다.

레이어 경계와 의존성 방향, 공통 규칙이 명확하지 않아 신규 기능 개발과 유지보수에서 예측 가능성이 떨어졌고, 코드 이해 비용도 높았다. 해당 구조를 설계한 개발자분들이 현재 남아 있었다면 의도를 확인하며 보완할 수 있었겠지만, 현재는 대부분 퇴사하신 상황이라 ‘의도 해석’보다 ‘현행 기준의 재정의’가 시급하다고 판단했다.

다만 아무것도 없는 상태에서 진행한 초기 회의는 추상적 논의에 머물렀고, 현 구조를 리팩터링하는 것이 가능한지, 가능하다면 기간과 범위가 어느 정도일지 결론을 내기 어려웠다.

어플리케이션 아키텍처는 개인 취향으로 밀어붙일 수 있는 주제가 아니다. 팀의 합의와 운영 현실을 반영해야 실효성이 생긴다. 그래서 무작정 “앞으로 이렇게 갑시다”가 아니라, 최소한의 원칙과 구조를 빠르게 가설로 제시하고 팀과 함께 검증하는 접근이 중요하다고 보았다.

이에 별도 브랜치를 파서 하루 만에 내가 구상한 ‘지속적으로 성장 가능한 구조’를 작동하는 결과물로 만들고, 실제 도입 시 어떤 단계로 확장·개선할지까지 포함해 문서로 작성하고 리뷰를 요청했다.

바로 적용하고 싶은 마음은 크지만, 프로덕션 반영까지는 규모 있는 작업이다. 적용 전략을 세우고, 구조에 대한 충분한 합의를 이룬 뒤 단계적으로 진행할 계획이다. 이후 잘 정착된다면 개선 과정을 블로그에 정리해 공유해보고자 한다.

 

AI-Diver 선정

7월부터 AI-Dive 제도가 운영되고 있다. 3개월 동안 매월 한 번, 업무에 실제로 도움이 된 AI 활용 사례를 공유하고, 그 임팩트를 기준으로 2명을 선정해 소정의 상품을 제공하는 방식이다.

처음엔 “개발자가 조금 유리하지 않을까?” 하는 생각이 들었는데, 예상대로 7월의 AI-Diver로 선정되어 배달의 민족 5만원 쿠폰을 받았다. 공유한 사례는 아래와 같다.

• Gemini CLI로 약 5분 만에 약 200개의 API를 호출해볼 수 있는 IntelliJ HTTP Client 파일 자동 생성
• ChatGPT + Gemini CLI + GitHub Copilot를 사용하여 코드 리뷰 요청 Slack 알림 자동화 스크립트 작성
• DIA 브라우저로 Confluence 문서 요약 및 정리

마지막 문장으로 “이 서베이도 AI로 작성 중입니다”라고 적어 나름 개그욕심을 냈는데, 타운홀에서 별다른 언급은 없어 약간 서운했다.

 

3분기 MVP 상 수상

내가 개발자를 하며 가장 중요하게 생각하는 건 “가치”다.

아무리 개발 실력이 좋아도 가치를 만들지 못하면 좋은 개발자라 할 수 없다고 믿기에, 지금 하는 일이 어떤 가치를 만드는지, 더 효율적으로 가치를 높이려면 무엇을 바꿔야 하는지 늘 고민하면서 일하고 있다.

그런 마음으로 일해 온 노력을 인정받아 감사하게도 수습이 끝남과 동시에 3분기 MVP 상을 수상하게 되었다.
MVP 시상 제도는 컬처핏과 비즈니스 임팩트를 기준으로, 분기마다 팀에 긍정적 변화를 만든 동료 한 명을 선정해 시상하는 제도인데, 기존부터 있던 제도인 줄 알았으나 이번에 새로 신설된 것이었고 무려 내가 1대 수상자였다!

타운홀 미팅에서 상패를 받으며 사진을 찍었는데, 당시에 상을 받을 줄 몰랐어서 면도를 하지 않고 출근한 것이 조금 아쉬웠다.

 

그래서, 앞으로는?

현재도, 앞으로도 해결해야 할 일이 많다. 특히 이전 개발자들이 남겨둔 맥락 없는 코드와, 나 스스로 업무 중간중간 메모해 둔 기술부채 리스트들을 보면 막막할 때도 있다. 하지만 이제는 이걸 단순히 “숙제”로 보기보다는, 내가 이 팀에서 만들 수 있는 임팩트의 원천이라고 생각하려 한다.

“이 문제를 내가 해결하면, 앞으로 들어올 사람들은 이 고생을 하지 않아도 되겠지”라는 마음으로 하나씩 없애 나가는 것. 당장은 눈에 잘 띄지 않더라도, 시간이 지날수록 분명히 누적될 거라 믿는다.

단기적으로는 이미 손을 대기 시작한 일들을 제대로 끝내는 것에 집중하고 싶다.
미사용 S3 이미지 삭제 배치는 실제 운영 과정까지 설계해서 안정적으로 굴러가게 만들고, 어플리케이션 아키텍처 개선 PoC는 단발성으로 끝나지 않고 팀 합의를 바탕으로 “실제로 적용 가능한 단계별 계획”까지 밀어붙이고 싶다. PR 슬랙 알림, ECR 라이프사이클 정책, 에러 로그 알림 같은 작은 자동화/운영 개선들도 계속 발굴해서, “이제 이런 건 신경 안 써도 되는” 영역을 조금씩 넓혀 나가려고 한다.

조금 더 넓게는, 이 팀에서 “일의 기준을 끌어올리는 사람”이 되고 싶다.
좋은 코드를 작성하는 개발자에서 그치는 게 아니라,

• 문제를 정확히 정의하고
• 가설을 세워 실험하고
• 과정과 결과를 문서로 남기고 공유해서
• 팀의 기본선을 같이 끌어올리는 사람

이 되는 것이 목표다. 그러기 위해 기록과 공유를 꾸준히 해볼 생각이다. 이번에 미사용 S3 이미지 배치나 아키텍처 개선 PoC 같은 것들도, 내부 문서에만 남기는 게 아니라 블로그나 발표 형태로 바깥에 공유하며 나 스스로를 더 다듬어 보고 싶다.

또 하나는, “속도”와 “지속 가능성”의 균형을 더 잘 맞추는 것이다.
스타트업이다 보니 빠르게 치고 나가야 하는 순간이 많고, 나도 그런 환경을 어느 정도 즐기는 편이다. 하지만 이번 분기에 수습과 MVP를 함께 겪으면서, “계속 이 속도로만 달리면 언젠가 번아웃이 오겠구나”라는 생각도 들었다.
앞으로는 일을 선택하고 몰입하는 과정에서, 내 체력과 멘탈을 관리하는 장치도 의식적으로 두려고 한다. 
예를 들면,

• 나 혼자 밤새워 해결하기보다, 적절한 시점에 팀에 상황을 공유하고 함께 방향을 정하기
• ‘지금 꼭 해야 하는 일’과 ‘지금 안 해도 되는 개선’의 우선순위를 더 냉정하게 나누기
• 휴식도 일의 일부라고 생각하고, 쉴 때는 제대로 쉬기

같은 것들이다.

마지막으로, 언젠가 나 이후에 들어올 사람들에게 “이 팀에 와서 다행이다”라는 느낌을 줄 수 있는 팀원이 되고 싶다. 이전 회사, 현재 회사에서 “혼자서 헤매야 하는 온보딩”을 겪어봤기 때문에, 최소한 누군가에게는 그 과정을 조금 더 덜 막막하게 만들어 주고 싶다. 온보딩 문서, 로컬 환경 세팅 템플릿, 자잘한 운영 노하우들… 이런 것들을 차곡차곡 쌓아서, 나중에는 “이 회사는 기본기가 잘 깔려 있다”라는 인상을 줄 수 있는 토대를 만들어 가고 싶다.

지금까지는 “내가 여기서 잘할 수 있을까?”를 증명하는 시간이었다면,
앞으로는 “내가 있어서 팀이 더 좋아졌다는 걸 어떻게 만들고, 어떻게 증명할 것인가”를 고민하는 시간이 될 것 같다.

연말 회고를 쓸 때 오늘 이 기록을 다시 보며,
“그때 적어둔 다짐들을 그래도 꽤 많이 지켜냈네”라고 웃으면서 돌아볼 수 있기를.