2024년 나의 회고 일지

어느덧 2024년이 저물어 간다. 이 짧은 시간 동안 나는 얼마나 성장했을까? 어떤 일들이 나를 스쳐 갔는지 돌아볼 필요가 있다고 느꼈다. 그래서 인프런 회고 밋업에 참가해 도움을 받기도 했다.

"산을 오를 때 경치 대신 앞만 보고 걷다 보면 정말 아름다운 순간들을 놓칠 수 있다.
나의 올해는 얼마나 아름다웠을까? 혹은 나는 앞만 보고 달리지는 않았을까?"

이를 돌아보고자 회고를 작성하게 되었다.

---

1월

프로그래머스 데브코스의 졸업 직전과 졸업 이후, 지속적으로 이력서를 수정하며 바쁜 한 달을 보냈다.
당시 노션을 활용해 이력서를 제출하는 방식이 유행했는데, 매니저님의 조언이 큰 도움이 되었다.

“이력서는 문서다. 아름답고 화려함보다 중요한 건, 면접관이 평가하고자 하는 내용을 명확하게 담아내는 것이다. 문서 안에 자신의 강점을 녹여라.”

이 조언을 바탕으로, 강조하고 싶은 부분은 수치화하고, 결과보다는 '어떻게(How)’ 에 초점을 맞추어 이력서를 작성했다. 또한, 면접관마다 서류에서 중점적으로 보는 포인트가 다를 수 있으니 다양한 사람들에게 피드백을 받기도 했다. 하지만 피드백이 상충되는 경우도 있었다. 어떤 사람은 좋다고 한 내용을 또 다른 사람은 빼는 것이 좋겠다고 하기도 했다. 그럴 때는 ‘내가 면접관이라면 어떤 정보를 가장 중점적으로 보겠는가’ 를 기준으로 최종 결정을 내렸다.

 

이렇게 많은 서류를 접수하고, 내가 지원하고자 하는 회사들을 분석했으며, 여러 면접에 부딪히고 깨지면서 면접에 대한 두려움을 조금씩 없앨 수 있었다.

다양한 경험을 쌓으며 한 걸음 성장했던 바쁜 1월이었다.

 

2월

첫 회사, 트렌비 합격

현재 재직 중인 회사인 트렌비에 합격 소식을 들었던 날이다.
1월부터 오전과 점심에는 면접 준비와 공부를 하고, 저녁에는 다이소 물류 아르바이트를 병행하던 힘든 시기였다. 그러던 어느 날 퇴근길 버스 안에서 메일이 도착했다. 합격 소식을 확인한 순간, 가장 먼저 나를 믿고 응원해 준 가족들과 여자친구에게 소식을 전했다.

합격 카톡

당시 감정이 벅차올라 눈물을 흘리는 이모티콘을 카카오톡 대화창에 도배했던 기억이 난다. 회고를 작성하며 카톡 기록을 다시 보니 그날의 기쁨이 떠올라 잠시 울컥하기도 했다. 😂 합격 직후에는 스스로 아래와 같은 목표를 세웠다:

1. 상반기 목표:
   • 회사 문화에 적응하고, 필요한 기술들을 익혀 사고 없이 1인분의 역할을 해내기
2. 코틀린 학습
   • 주요 학습 자료:
     • 아토믹 코틀린
     • 코틀린 인 액션
     • 이펙티브 코틀린
     • 코틀린 코루틴
3. 카프카
4. 쿠버네티스

회사의 기술 스택에 맞춘 학습 목표도 정리했지만, 돌아보니 완전히 달성하지 못한 부분이 많았다. 월간 목표를 세우고 이루지 못한 부분들을 하나씩 해결해 나가야겠다고 다짐한다.

---

트렌비 입사

입사 후에는 사내 백오피스와 중고 도메인을 담당하는 가든 팀에 배정받았다.
이 팀에서는 백엔드와 프론트엔드 작업을 골고루 경험할 수 있었다. 다양한 업무를 통해 기술 역량을 넓히기에 좋은 환경이었다.

트렌비는 매달 타운 홀 미팅을 개최했는데, 그 자리에서 신입으로서 다음과 같은 포부를 밝혔다:

1. 백오피스 담당자로서 사내 클라이언트들에게 더 나은 경험과 서비스를 제공하겠다.
2. 회사의 비즈니스 발전에 기여하고, 내 연봉의 두 배 이상의 수익을 창출할 수 있는 개발을 해내겠다.

당찬 신입으로서 내세울 수 있는 포부였고, 다행히 올해 두 가지 목표를 모두 이루는 성과를 거두었다.

---

온보딩

입사 초기에는 사내 도메인에 익숙해지는 것을 목표로 유지보수 작업을 할당받았다.
주로 노출 데이터를 수정하거나 프론트 UI를 변경하는 간단한 작업들이었지만, 이를 통해 코드 컨벤션을 익히고 사내 코드를 이해할 수 있었다.

트렌비의 코드는 대부분 MSA(Microservices Architecture) 환경으로 구성되어 있었다.
처음 MSA 코드를 접했을 때는 프로젝트를 한 번에 여러 개 띄워서 확인해야 했기 때문에 익숙해지는 데 시간이 걸렸다. 하지만 이를 통해 새로운 아키텍처 환경을 이해하고 적응할 수 있었다.

---

첫 프로젝트 티켓

트렌비 파트너사의 요청으로 공휴일을 제외하고 답변 지연 패널티를 계산해 달라는 티켓을 맡게 되었다.

우선 기존 코드의 히스토리를 분석하며 운영팀과의 싱크를 맞추는 데 집중했다. 고객의 요구사항을 반영하는 것이 가장 중요하다고 생각했기 때문이다. 이를 통해 운영팀이 파악한 비즈니스 논리와 코드 간의 불일치를 발견했고, 이를 해결하기 위한 Short-term 작업을 빠르게 진행했다. 이후 스크럼 시간에 개발팀, 기획팀과 문제를 공유하며 협업을 이어갔다.

이 이슈로 인해 기존에는 지표 확인에 3~5일이 걸렸지만, 문제를 해결한 후에는 월평균 4일이 걸리던 작업이 10분 내외로 단축되었다. 비즈니스에 큰 임팩트를 줄 수 있는 개선이었다. 작업 중 레거시 코드를 리팩토링하고 테스트 코드도 꼼꼼히 작성했다.
예를 들어, 아래는 다양한 케이스를 테스트하기 위해 작성한 테스트 케이스 일부다

@JvmStatic  
fun delayTestCaseWithIncludeHoliday(): Stream<Arguments> {  
    return Stream.of(  
        Arguments.of( // 삼일절과 주말 포함  
            LocalDate.of(2024, 2, 29).atTime(12, 0), // 목요일  
            LocalDate.of(2024, 3, 4).atTime(12, 0), // 월요일  
            true  
        ),  
        Arguments.of(  
            LocalDate.of(2024, 5, 6).atTime(9, 0), // 어린이날 대체 공휴일  
            LocalDate.of(2024, 5, 8).atTime(9, 0), // 수요일  
            true  
        ),  
        Arguments.of(  
            LocalDate.of(2024, 5, 14).atTime(9, 0), // 화요일  
            LocalDate.of(2024, 5, 16).atTime(9, 0), // 목요일  
            true  
        ),  
        Arguments.of( // 주말 + 대체공휴일이 끼어있지만 목요일날에 대한 질문을 금요일날 답 할 수 있어야함.  
            LocalDate.of(2024, 5, 2).atTime(9, 0), // 목요일  
            LocalDate.of(2024, 5, 6).atTime(17, 0), // 화요일  
            true  
        ),  
        Arguments.of( // 주말 + 추석 연휴가 껴있지만 13일날 응답 해야함.  
            LocalDate.of(2024, 9, 12).atTime(11, 0), // 목요일  
            LocalDate.of(2024, 9, 19).atTime(10, 0), // 목요일  
            true  
        ),  
        Arguments.of( // 공휴일에 답하더라도 평일에 먼저 답을 했어야 함.  
            LocalDate.of(2024, 9, 12).atTime(11, 0), // 목요일  
            LocalDate.of(2024, 9, 18).atTime(10, 0), // 수요일  
            true  
        )  
    )  
}

 

단순한 날짜 나열로는 다음 개발자가 이해하기 어렵다고 판단해 적절한 주석을 추가했다.
클린 코드의 원칙인 “주석이 필요 없는 코드를 작성하라”는 지침도 중요하지만, 비즈니스 히스토리가 포함된 경우에는 주석이 큰 도움이 된다고 생각한다. 이를 보완하기 위해 JavaDocs를 적극 활용하기도 한다.

---

작은 나의 행복

프로젝트 완료 후 운영팀으로부터 감사 인사를 받았는데, 이는 내가 개발자로서 가장 큰 보람을 느끼는 순간 중 하나였다.

회고 사진 (1)

---

3월

바로시세 TF

3월에는 CTO님과 CPO님으로부터 하나의 TF팀을 구성하자는 제안을 받았다. TF라는 단어 자체가 다소 부담스럽게 느껴졌지만, 회사의 비즈니스 성과에 기여할 수 있는 좋은 기회라고 생각해 자원하게 되었다.

TF의 공통 목표는 트렌비에서 제공하는 바로시세의 커버리지를 높이는 것이었다.
나는 바로시세 커버리지가 낮은 원인을 분석하고, 이를 해결할 방안을 제시하는 역할을 맡았다. 분석 과정에서 항상 데이터 기반으로 원인을 규명해야 한다는 점을 염두에 두었다.

데이터 분석과 솔루션 제안

학부에서 인공지능을 공부하며 익혔던 Pandas와 Matplotlib를 활용해 기존 데이터를 분석하고 내용을 공유했다.

위 그래프는 내가 시각화한 데이터 중 하나로, 초록색 그래프는 유저들의 이미지 퀵 등록 관련 지표를 보여준다.

주요 발견사항:

• 구찌의 경우, 실제로 바로시세를 제공하는 상품이 많음에도 불구하고 고객들이 이미지를 통해 상품을 등록하는 비율이 높았다.
  • 이는 바로시세를 제공하는 뷰가 사용자에게 친절하지 않다는 점을 시사했다.
• 직접 판매하기 퍼널에 들어가 상품을 검색해본 결과, 상품을 찾는 과정이 매우 불편했다.
• 다른 브랜드에서도 바로시세를 제공하는 비율이 낮은 경우가 많았다.

이에 대해 구체적인 솔루션을 제안했고, 이를 개발하여 적용하였다.

---

성과와 지속적인 개선

솔루션 적용 이후 지표는 현재 다음과 같은 변화를 보인다.

회고 사진 (2)

• 바로시세 커버리지는 기존 대비 약 90% 증가라는 큰 성과를 기록했다.
• 처음부터 이처럼 높은 수치를 기록한 것은 아니었고, 초기에는 약 30%의 개선이 있었다.
• 지속적으로 솔루션을 고민하고 개선안을 적용하면서 점진적으로 지표를 끌어올릴 수 있었다.

현재의 데이터 환경으로는 지표를 더 올리는 데 한계가 있었기에, 새로운 솔루션도 제안하며 개선 작업을 이어갔다. 이러한 과정 덕분에 이후 TF에서는 내가 주도적으로 팀을 이끌며 프로젝트를 진행할 수 있는 환경이 자연스럽게 만들어졌다.

---

4월

개인적으로 힘들었던 한 달

4월은 개인적으로 정말 힘든 달이었다. 해외 부티크 업체와 API 연동을 통해 해외 주문 자동화를 개발하던 시기였기 때문이다.

당시 해외 업체는 SOAP 프로토콜을 사용하고 있었다. SOAP은 1998년에 등장해 2003년쯤 활발히 사용되던 프로토콜로, 지금은 대부분 HTTP나 다른 네트워크 프로토콜로 대체된 상태다. 학부에서도 SOAP은 거의 사용되지 않는 과거의 프로토콜로만 언급되었는데, 이를 연동해야 한다니 당황스러웠다.

하지만 결국 SOAP도 하나의 프로토콜일 뿐. 포맷을 이해하고 데이터를 네트워크로 잘 전송하면 된다는 마음으로 개발을 시작했다.

---

SOAP 연동 과정에서의 고난

고객사와의 통신은 성공적으로 이루어졌고 데이터를 확인할 수 있었다. 하지만 실제로 요청해야 하는 파라미터에 문제가 있어 보였다.

이에 고객사에 요청 파라미터를 다시 확인해 줄 수 있는지 문의했지만, 돌아온 답변은 문제가 없다는 이야기뿐이었다. 더 나아가, 고객사의 개발팀과 직접 소통할 수 있는지 요청했지만 그것마저 거절당했다. 결국, 나는 파라미터 맞추기 노가다에 돌입할 수밖에 없었다.
아래는 그 과정에서 작업한 일부 화면이다:

다른 변수들에 대해서도 비슷한 작업을 반복해야 했다. 시도 횟수를 나타내자면, 이는 Ω(변수 개수 × 변수명의 길이) 정도의 작업량이었다.

---

소통의 깨달음

이 프로젝트를 통해, 개발에서 소통의 중요성을 다시 한번 깨닫게 되었다. 고객사와의 소통 부족으로 인해 효율적으로 해결할 수 있었을 문제를 너무 오래 끌고 갈 수밖에 없었다.

---

개발자로서의 의심과 극복

이 시기에는 스스로 "나 개발을 잘하고 있는 걸까? 개발을 내가 너무 못하는건 아닐까?” 라는 생각이 들기도 했다. 프로젝트가 너무 길어지고 비효율적으로 진행되면서 자신감을 잃어갔던 것이다.

다행히도, 오랜 연차를 보유한 팀장님께서 “소통이 저런 식이었다면 나라도 오래 걸렸을 작업이었다” 라고 말씀해 주셨다. 이 말을 듣고 왜곡된 자기 생각에서 빠르게 벗어날 수 있었다.

---

5월

부티크 주문 연동 완료

정말 많은 시행착오 끝에 부티크 주문 연동 작업을 마무리할 수 있었다.
해외 업체와의 소통은 예상대로 쉽지 않았다. 메일을 보내도 답장을 받는 데 평균적으로 3일이 걸리곤 했다. 이렇게 시간이 계속 지체되다 보니 나도 조급해졌고, 세일즈 팀도 점점 초조해졌다. 한편으론 “이탈리아에 직접 가서 담당자와 소통하고 싶다”는 생각마저 들었다.

하지만 결국 많은 노력을 통해 해외 주문 연동을 성공적으로 완료했다. 성과는 놀라웠다

• 직전 주 매출 대비 110% 증가
  • 이 수치는 나의 월급의 두 배를 상회하는 금액이었다.
  • 입사 당시 세웠던 “연봉의 두 배 이상의 가치를 창출하겠다” 는 포부를 입사 3개월 만에 실현할 수 있었다.

이 시점에서 수습 기간이 끝나고 정규직으로 전환되기도 했다.
4월이 힘든 시간이었다면, 5월은 그 노력이 빛을 본 보람찬 한 달이었다.

---

해외 주문 연동의 확장

부티크 주문 연동 완료 이후에도 많은 해외 주문 연동 작업 요청이 들어왔다.
이 경험을 통해 큰 성장을 이룰 수 있었고, 현재 12월 기준으로 약 15개의 업체의 자동 주문 연동을 진행하며 그 과정을 이어가고 있다.

---

카탈로그 TF

5월 말에는 이전 TF 이후 논의되었던 솔루션을 기반으로 새로운 카탈로그 TF 팀에 합류했다.

카탈로그 프로젝트는 잘 추상화되어 있는 만큼 복잡도가 높은 프로젝트였다.
특히, 이 프로젝트를 주도적으로 개발했던 분이 퇴사한 상태라, 레거시 코드와 문서를 통해 전체 구조를 이해해야 했다. 다행히도 당시 함께 참여했던 한 분이 남아 계셔서, 그분과 지속적으로 소통하며 솔루션을 만들어갈 수 있었다.

 

5월은 4월의 어려움을 극복한 성과로 가득 찬 달이었고, 새로운 도전을 준비할 수 있었던 시기였다.

---

6월

카탈로그 TF

프로젝트 구조를 이해한 후 본격적으로 작업에 착수했다.
바로시세 TF 이후, 바로시세를 제공하기 위해서는 상품이 적절한 카탈로그에 묶여 있어야 한다는 것을 알게 되었다. 이를 위해 두 가지 작업이 필요했다:

1. 상품을 적절한 카탈로그에 묶는 작업
2. 존재하지 않는 카탈로그를 생성하는 작업

이를 실현하기 위해 세일즈 팀과 협력하여 정확도가 높은 SKU를 제공할 수 있는 파트너사를 찾고, 카탈로그를 생성할 수 있는 API를 추가로 마련했다.

---

카탈로그 강제 생성 스크립트 작성

당시 Java와 Kotlin이 주요 언어였기 때문에, 익숙한 언어로 빠르게 작업할 수 있었다. 약 0.5일 정도의 시간을 들여 카탈로그를 강제 생성하는 스크립트를 작성했다.

스크립트를 Java로 작성하자, 상품 팀과 우리 팀의 팀장님이 깜짝 놀라며 말씀하셨다. “이런 건 그냥 JS로 작성하셔도 돼요!”

그 말을 듣고, 언어 선택에 대해 다시 고민해보게 되었다. 당시에는 JS에 대한 깊이가 부족해 JS로 작성하면 더 많은 시간을 소모할까 봐 선뜻 시도하지 못했다. 하지만 이 경험을 통해, 언어는 단지 도구일 뿐이며 문제를 해결하기 위해 적재적소에 적합한 언어를 사용하는 것이 중요하다는 교훈을 얻었다.

---

작업 중 발생한 이슈와 책임감

세일즈 팀과 데이터를 분석하고 카탈로그를 강제로 생성했지만, 일부 요구사항을 놓친 부분이 있어 수정이 필요했다. 리더님들은 “유저에게 악영향이 없으니, 집에 가서 작업해도 된다”고 말씀하셨지만, 책임감이 강한 나는 “오늘 반드시 끝내겠다”는 생각으로 작업을 이어갔다.

결국 새벽 4시쯤 모든 작업을 마무리했고, 당시 인천에서 출퇴근하던 나는 근처 찜질방에서 잠시 눈을 붙였다.

그 결과, 아래와 같은 성과를 이룰 수 있었다:

이후에는 카탈로그 매칭 자동화 프로세스를 만들어 현재는 18%의 자동화율을 달성했다.

---

PSP (Problem Solving Party)

6월에는 사내 이벤트인 PSP(Problem Solving Party)에도 참여했다.
PSP는 직원들이 팀을 구성해 회사 비즈니스에 임팩트를 줄 수 있는 아이디어를 내고 기획하는 행사다.

나는 PSP를 위해 노션에 아이디어를 정리하고, 팀원들과 함께 실행 방안을 고민했다. 여러 방면으로 다른 회사들과 컨택하며 아이디어를 구체화했다. 마지막에는 전사 직원들 앞에서 PPT로 발표를 진행했는데, 떨지 않고 준비한 대로 잘 발표할 수 있었다.

 

6월은 기술적인 도전과 회사 문화 활동을 통해 책임감과 협업, 성장의 의미를 되새긴 한 달이었다.

---

7월

외부 활동 시작

7월에는 새로운 도전을 시작했다.
스토어 팀 리드분께서 다른 회사로 이직하시며 팀 리드 자리가 공석이 되었고, 신입이 힘들어하는 모습을 보았다. 신입에게 힘이 되어주면서 나도 성장할 방법이 없을까? 고민하다가, 이전에 데브코스에서 함께했던 동기들과 스터디를 시작했다.

스터디를 통해 각자 회사에서 쌓은 경험을 나누며 많은 의견을 교환할 수 있었다. 혼자 공부하는 것보다 다양한 사람들의 의견을 듣는 것이 학습에 훨씬 큰 도움이 된다는 것을 느꼈다.

---

카탈로그 매칭율 개선과 성능 극대화

회사에서는 계속해서 카탈로그 매칭율을 어떻게 더 증가시킬 수 있을지 고민하며 새로운 티켓들을 처리했다.
이 과정에서 카탈로그 매칭율을 높이는 작업뿐 아니라, 증가한 데이터를 처리하며 카탈로그의 성능을 극대화하는 경험도 쌓을 수 있었다.

해당 작업은 내게도 의미 있는 경험이었고, 사례를 블로그에 정리해 공유하면 좋겠다는 생각이 들었다.

---

CEO님께 받은 편지

7월에는 사내에서 뜻깊은 순간도 있었다.
CEO님께서 직접 내게 좋은 내용의 편지를 보내주셨다.
“내 능력을 누군가가 인정해주고, 믿고 맡길 수 있는 동료가 되는 것”은 내가 추구하는 인생의 모토 중 하나다.
그런 의미에서 이 편지는 기분 좋은 순간 중 하나로 오래 기억에 남을 것 같다.

회고 사진(4)

7월은 동료와 함께 성장하고, 회사에서 내 역할과 가치를 인정받을 수 있었던 한 달이었다.

---

8월

무더운 여름과 회사 생활

올해 여름은 정말 더웠다. 회사 사무실은 에어컨이 잘 작동해서 시원했지만, 회의실과 화장실은 에어컨 바람이 들어오지 않아 많이 힘들었다. 이 고충은 나뿐만 아니라 다른 직원들도 동일하게 느끼던 문제였다.

---

자취 시작

8월에는 내게 정말 특별한 일이 있었다. 드디어 자취를 시작한 것이다.
부모님과 자취 여부를 두고 오랫동안 고민했다. 부모님께서는 자취로 인한 식비 증가와 결혼 자금 준비의 어려움 등을 이유로 반대하셨다. 나 역시 부모님의 조언에 공감하며 최대한 참고 다녔지만, 왕복 평균 3시간, 많게는 5시간이 걸리는 출퇴근은 도저히 감당하기 힘들었다.

결국, 혼자서 공인중개사들을 찾아다니며 방을 알아보기 시작했다. 마침내 내 마음에 꼭 드는 방을 발견했고, 부모님께 통보한 뒤 계약을 진행했다.

자취를 시작한 후로는 개인적으로 사용할 수 있는 시간이 크게 늘어났다. 덕분에 운동과 자기계발에 시간을 잘 활용할 수 있었다. 특히, 도림천에서 러닝을 하는 기분은 정말 짜릿하다! 이 경험을 계기로 내년에는 하프 마라톤에 도전해볼 계획도 세우게 되었다.

 

8월은 자취라는 새로운 환경에서 시간을 효율적으로 활용하며 나만의 삶을 만들어가기 시작한 달이었다.

---

9월

코드 개선과 응답 포맷 공통화

9월에는 회사에서 코드 개선을 위한 작은 변화들을 시도하기 시작했다.
그중 가장 주목했던 작업은 응답 포맷 공통화였다.

회사 자체가 MSA 구조이다 보니, 백엔드와 프론트엔드 모두 클라이언트가 될 수 있다. 하지만 각 팀마다 사용하는 응답 규격이 달라 매번 이를 수정해야 하는 일이 번거롭고 비효율적이었다. 이를 해결하기 위해 응답 포맷을 공통화하려고 노력했지만, 모든 팀이 쉽게 받아들이지는 않았다.

특히, 문서를 효과적으로 작성하지 못했던 점이 아쉬웠다. 더 설득력 있는 문서로 해당 작업의 필요성을 명확히 전달했더라면 더 좋은 결과를 얻었을 것이라는 생각이 든다.

---

클린코드와 테스트코드 스터디

9월부터 인프런에서 진행하는 클린코드와 테스트코드 스터디를 신청했다.
이 스터디에 참여한 가장 큰 이유는 사내 레거시 코드를 리팩토링하고 싶은 마음이 컸기 때문이다.

업무가 바쁠 때는 빠르게 알고리즘식 코드를 작성할 수밖에 없을 때가 있다. 하지만 이런 코드들을 방치하다 보면 점점 수정이 어려운 수준의 코드로 변질되기 마련이다. 이를 방지하기 위해, 빠른 시일 내에 코드를 리팩토링하고자 했다.

스터디를 통해 배우고자 했던 점은 리팩토링의 구체적인 방법과 방향성이었다. 하지만 궁극적으로는 코드 작성 습관이 중요하다는 것을 깨달았다. 문제를 마주했을 때, 자신만의 규격과 방식을 기반으로 효율적으로 코드를 작성하는 습관을 기르는 것이 장기적인 코드 품질 향상에 필수적이라고 느꼈다.

---

글또 활동

사내 발표를 넘어서 더 많은 사람들과 내가 배우고 경험한 내용을 공유하고 싶다는 생각이 들었다.
또한, 사내 문화와 기술에 안주하지 않고 더 넓은 개발자 세계를 탐험하며 다양한 사고를 배우고 싶었다.

이런 고민 끝에 글또(글 쓰는 개발자들 모임)에 참여하게 되었다.
글또에서는 외부 개발자들과 교류하며 더 넓은 관점에서 다양한 글을 읽고 공부할 수 있었다. 이를 통해 아직도 배워야 할 것이 많다는 것을 깨닫게 되었다. 외부에서 얻은 경험과 통찰을 사내에서 공유하며 더 좋은 문화를 만들어 나가는 데 기여하고 싶다는 목표도 생겼다.

 

9월은 코드 품질 개선을 위한 노력과 외부 활동을 통해 성장과 교류의 중요성을 다시금 깨달은 한 달이었다.

---

10월

CTO 님의 퇴사와 팀의 변화

10월은 회사 생활에서 가장 혼란스러운 시기 중 하나였다.
CTO 님이 개인적인 사정으로 퇴사하시면서 팀 규모도 축소되었다. 신입으로서 이런 상황을 처음 겪다 보니 “나는 이제 어떻게 해야 할까?”라는 불안감과 혼란스러운 감정이 교차했다.

다행히도, CTO 자리가 공석이 된 후 우리 팀의 팀장님이 그 자리를 맡으시게 되었다. 팀장님은 뛰어난 능력과 매니징 스킬을 갖춘 분이었기에, 그로 인해 불안감이 조금은 덜해졌다.

이 시기에는 팀 전체적으로 사용성을 개선하기 위해 라이브러리를 도입하는 작업도 처음 시도해보았다. 도입 이후, 팀 전체에서 분산 락을 도입할 때 이 라이브러리를 유용하게 사용하는 모습을 보며 큰 보람을 느꼈다. 내가 만든 도구가 팀의 효율성을 높이는 데 기여했다는 점이 특히 감회가 새로웠다.

---

여자친구와의 속초 여행

4년 가까이 만나고 있는 여자친구와 속초로 장거리 여행을 다녀왔다. 연애 후 처음 가보는 장거리 여행이라 설렘과 함께 한편으로는 미안한 마음도 들었다. 지금까지 여행을 가지 못했던 이유는, 취업 시장에서 “하루라도 뒤처지면 안 된다”는 간절한 마음 때문이었던 것 같다. 하지만 이번 여행을 통해, 잠깐의 휴식이나 여행이 취업에 크게 영향을 미치지 않는다는 것을 깨달았다. 현재 여자친구도 취업 준비 중인데, 이 짧은 여행이 그녀에게 잠시 숨을 고르고 넓은 세상을 바라볼 여유를 주었으면 하는 바람이다. 당시 설악산에서 찍은 절경은 아직도 기억에 남는다.

회고 사진(5)

넓은 세상을 바라보니 마음이 한결 편안해졌다. 작은 일에도 감사함을 느끼고, 세상을 긍정적으로 바라볼 수 있는 계기가 된 여행이었다.

 

10월은 혼란 속에서도 새로운 도전을 통해 성장하고, 소중한 사람과의 시간을 통해 삶의 여유와 감사를 배운 달이었다.

---

11월

루틴 만들기

꾸준히 학습할 수 있는 환경을 만드는 것이 중요하다고 생각했다. 나는 환경의 영향을 많이 받는 편이기에, 동료와 함께 아침 7시에 출근해 공부 시간을 가지는 루틴을 제안했다. 다행히 동료분께서 흔쾌히 수락해주셔서 오전 7시 공부 팟이 성사되었다.

이 루틴은 학습과 집중력을 높이는 데 큰 도움이 되었다.

---

레거시 프로젝트 리팩토링

인프런 스터디를 무사히 수료한 후, 드디어 레거시 프로젝트 개선 작업을 맡게 되었다.
이 프로젝트는 여러 라이브러리 의존성 관리와 설계 과정을 딥 다이브할 수 있는 좋은 기회였다. 프로젝트 경험이 다른 팀원들에게도 도움이 될 수 있도록 자체 템플릿을 제작해 깃허브에 공유했다.
해당 템플릿은 제미니의 개발 실무, 향로, 클린 아키텍처를 기반으로 제작되었다.

https://github.com/bombo-dev/template

GitHub - bombo-dev/template: 스프링 환경에서 마이크로서비스로 편하게 개발 할 수 있도록 만들어진 Jav

 

---

도메인 설계와 유스케이스 분석

레거시 프로젝트를 개선하기 위해 먼저 명확한 도메인 명칭을 정하는 작업부터 시작했다.
이를 위해 도메인 전문가를 찾아가 유스케이스를 정리하고, 이를 바탕으로 도메인 설계를 진행했다.

많은 리소스가 없는 상황에서, 직접 해당 도메인을 다루는 직원들과 대화하며 필요한 정보를 정리하고 설계에 반영했다. 이런 과정을 통해 나는 주도적으로 프로젝트를 이끌 수 있었고, 이는 내게 큰 즐거움과 성취감을 안겨주었다.

---

동료의 퇴사

한편, 회사 인원이 줄어들면서 프론트 리더님과 함께 사내 문서를 통합하는 프로젝트를 진행했다.
팀 내 문서를 한데 모아 검색을 더 용이하게 만드는 작업이었고, 이는 마치 레거시 코드를 정리하고 리팩토링하는 작업과도 같았다.

하지만, 이 프로젝트는 프론트 리더님의 마지막 프로젝트가 되었다. 리더님의 갑작스러운 퇴사 소식은 큰 충격이었다. 좋아하는 동료가 떠나는 일은 언제나 슬프고 힘든 경험이다. 하루 동안 업무에 집중하지 못할 만큼 큰 영향을 받았다.

---

프로젝트 취소

추가적으로, 환율 상승과 개발 비용 증가로 인해 레거시 프로젝트 리뉴얼이 우선순위에서 밀려나고 취소되었다.
대신, 남용되고 있던 개발 비용을 줄이는 데 초점을 맞추는 방향으로 변경되었다.

오랫동안 기다리던 리뉴얼 작업을 진행하지 못한 것이 정말 아쉬웠지만, 회사의 현실적인 상황에 맞춰 방향성을 조정할 수밖에 없었다.

 

11월은 주도적으로 프로젝트를 이끌며 성취감을 느낀 시기인 동시에, 동료의 퇴사와 프로젝트 취소라는 아쉬움도 함께했던 달이었다.

---

12월

리소스 절감 프로젝트

사내에서 리소스 비용 절감을 목표로 RI(Reserved Instance) 수준의 리소스만 사용하자는 방향이 결정되었다.
이에 따라, 여러 서비스 개발 경험이 있는 내가 비용 절감 프로젝트의 메인 엔지니어로 선정되었다.

이 프로젝트에서 수행한 주요 작업은 다음과 같다:

• Data Transfer 비용 추적
• Redis 통합
• DNS 내부 호출로 변경
• Pod 리소스 관리

Pod 리소스 관리를 위해 그라파나 대시보드에 Pod 리소스 확인 기능과 적정 리소스 사용량 추천 대시보드를 추가했다. 이를 통해 목표한 만큼 리소스를 최적화할 수 있었다.

이 프로젝트는 현재도 진행 중이지만, 한편으로는 내가 개발하던 서비스의 규모가 점차 축소되고 있다는 점에서 아쉬움도 남는다.

---

Action Items

이번 회고를 바탕으로 앞으로 나아갈 방향과 목표를 설정했다:

1. 사내 기술에 대한 이해도 높이기
   • 현재 사용 중인 기술 스택을 깊이 이해하고, Best Practice로 개선하기 위해 노력하기.
   • 주요 학습 분야:
     • 카프카
     • MSA
     • 쿠버네티스
2. 자유도를 활용한 새로운 도전
   • 자유도가 높아진 만큼 여러 가지 새로운 시도를 통해 더 많은 경험 쌓기.
3. Comfort Zone에서 벗어나기
   • 익숙한 환경에서 벗어나 도전적인 목표를 설정하고 실현하기.
4. 사이드 프로젝트 제작 및 운영
   • 실제로 사이드 프로젝트를 만들어 배포하고 운영하며 실전 경험 쌓기.
5. 정기적인 회고 작성
   • 매월 회고를 작성하고, 매 분기마다 Action Item을 구체적으로 분리해 실천 가능한 목표 설정하기.

---

ETC

글또에서의 커피챗 경험

최근 글또에 참여하며 많은 사람들과 커피챗을 나눴다.
참여자들은 정말 대단한 분들이 많았고, 그들과의 대화를 통해 나도 성장의 에너지를 다시 한번 얻을 수 있었다.

스스로 부족한 점이 많다고 느끼지만, 열정 있는 사람들과 함께할 때 내 에너지가 극대화되는 느낌을 받는다. 이 경험은 앞으로도 내 성장에 중요한 자극이 될 것 같다.

---

인프런 회고 밋업

12월 18일(수)에 열린 인프런 회고 밋업을 기반으로 이번 회고를 작성했다.
밋업에서는 날짜 기반 회고와 키워드 기반 회고라는 두 가지 회고 방식에 대해 배울 수 있었다:

• 날짜 기반 회고: 시간을 기준으로 작성하는 방식 (현재 회고에서 사용한 방식)
• 키워드 기반 회고: 중요한 요소나 주제 중심으로 작성하는 방식

밋업에서는 다음과 같은 템플릿을 제공받아 작성 시간을 가졌다:

회고 사진(7)

---

뽀모도로의 새로운 경험

밋업 현장에서 뽀모도로 기법을 활용하며 회고를 진행했다.
혼자 뽀모도로를 시도한 적은 있었지만, 실천이 쉽지 않았던 경험이 많았다. 하지만 모두가 함께 있는 자리에서 뽀모도로를 진행하니, 업무 효율이 놀랄 정도로 높았다.

이 환경을 가상의 상황으로 만들어 시도해보는 것도 재미있을 것 같다는 생각이 들었다.

---

회고 방식의 반성과 내년 계획

이번 회고를 시간 순서로 작성하면서, 작성된 양이 지나치게 많아지는 단점을 다시 한번 느꼈다. 이는 월간 회고를 꾸준히 작성하지 않았기 때문이라고 생각한다.

이에 따라, 내년부터는 다음과 같은 기준으로 회고를 작성하려고 한다:

• 월간 회고: 시간순으로 작성
• 연간 회고: 키워드 기반으로 작성

이 방식이 더 효율적이고, 의미 있는 회고를 만드는 데 도움이 될 것이라고 기대한다.

---

감사와 다짐

좋은 시간을 마련해주신 변성윤(카일스쿨)님과 이를 지원해주신 인프랩에 깊은 감사의 마음을 전한다. 좋은 비즈니스를 운영하며 취지에 맞는 자리를 마련하는 일이 얼마나 어려운지 요즘 실감하고 있다.

“후원은 이미 갖춘 사람이 더 잘한다”는 말이 떠오르며, 나 역시 나중에 이런 자리를 마련할 수 있는 사람이 되고 싶다.

내년에 나는 어떤 모습일까? 어떤 생각을 하고 있을까? 이 질문을 남기며 2024년 연간 회고를 마친다.