[회고] 2024년 회고록 - 1 : 도약의 발판

더 큰 도약을 위해서

2024년 12월 31일 22시 석촌호수 앞에서...

 

들어가며

2024년은 나의 20대 중 최고의 한 해로 기억될 것 같다.
매일을 후회 없이 살기 위해 노력했고, 덕분에 후회 없는 하루하루를 보낼 수 있었다.
 
물론, 후회 없는 나날을 보냈지만 행복한 일만 있었던 것은 아니다.
때로는 너무 힘들어 지치는 순간도 있었고, 마음이 무너질 때도 있었다. 그럼에도 불구하고, 그런 경험들이 결국 나를 더 단단하게 만들었고, 나아갈 힘이 되어주었다.

지난 한 해 동안의 경험들은 내게 소중한 자산이 되었다.
실패를 두려워하지 않고 도전했던 순간들, 힘들어도 포기하지 않았던 시간들, 그리고 그 과정에서 만난 소중한 인연들까지 모두...

2025년에는 어떤 일이 펼쳐질까? 두려움도 있지만 25살의 내가 이뤄낼 성과가 더 기대된다.
그만큼 내가 내 길을 잘 헤쳐나갈 거라는 믿음이 크기 때문인 것 같다. 😊
 
2025년에도 스스로를 믿으며, 더 큰 도약을 이뤄내는 한 해가 되기를 기원하며 2024년 회고록을 작성해보자!
 
 

나를 믿는 마음을 기르면 세상이 더 넓어진다.
- 소크라테스 -

 
 
 

---

 
 
 

1월~2월

우물 안에서 바라본 더 큰 세상: 나의 첫 해커톤 이야기

GDSC 해커톤

GitHub - GDSC-Hackathon-TeamB/GoalKeeper-BE

 
1월과 2월, 총 두 번의 해커톤에 참여했다.
그 두 번의 해커톤 중, 가장 기억에 남는 해커톤은 GDSC New Year 해커톤이다. 내 인생 첫 해커톤 경험이자 나의 개발 여정에서 중요한 전환점이 되었기 때문이다.
 
주제 키워드는 SDGs, 사랑, 다짐이었다.(다시 생각해봐도 정말 어려운 주제인 것 같다)
다시 생각해봐도 꽤 까다로운 주제였던 만큼, 팀원들과 열띤 논의를 이어갔지만 쉽게 “이거다!” 싶은 아이디어가 떠오르지 않았다.
아이디어를 정하는 데 예상보다 시간이 많이 걸리면서, 우리 팀은 방향을 잡지 못해 잠시 방황하기도 했다.
 
그러다 문득 떠오른 아이디어가 바로 매칭 서비스였다. 기존에 ‘무드메이트’라는 서비스를 통해 같은 데이트 무드를 원하는 사람들을 매칭한 경험을 바탕으로, 이번에는 새해 다짐(봉사, 기부)이 비슷한 사람들을 매칭하면 주제 키워드 3개를 모두 충족할 수 있겠다고 생각했다. 이 아이디어를 팀원들에게 공유하자, 모두 "너무 좋다"며 적극적으로 공감해주었고, 덕분에 막판에야 아이디어를 확정할 수 있었다. 😊
그렇게 새해 다짐이 비슷한 사람들을 매칭하여 서로 동기부여와 지지를 주고받으며 목표를 이루고, 인증과 보상을 통해 성취감을 느낄 수 있도록 돕는 서비스 “GoalKeeper”가 탄생했다.
 
GoalKeepr에서 백엔드 개발을 맡게 되었고, 함께했던 백엔드 개발자분이 개발이 처음이셔서 내가 전체적인 백엔드 개발을 담당해야 했다. 이때, 처음부터 백엔드 설계를 해나가면서 나는 내 실력의 부족함을 절실히 느꼈었다.
그동안은 경험 많은 팀원들의 도움으로 기능 구현을 무사히 해냈지만, 혼자서 모든 것을 책임져야 하니 막막함을 느꼈다. 특히, API의 개념조차 제대로 알지 못한 채 매칭 알고리즘 구현에만 집중했던 그때, 스스로가 너무 부끄러웠다.
 
결국 최종 제출 때는 API 없이 내가 익숙한 서버 개발과 매칭 알고리즘만 구현해 제출할 수 밖에 없었다. 이 과정에서 함께한 iOS 개발자분들께 죄송스러운 마음이 컸고, "내가 잘했더라면..." 하는 아쉬움도 크게 남았다.
 
당시 나는 400명의 매칭을 수행하는 알고리즘을 개발했다는 자신감에 차있었는데, 정작 단순한 API조차 구현하지 못하는 내 모습을 보며 "나는 우물안 개구리구나..." 하고 생각했었다.
 
이후로 나는 부족한 점을 채우기 위해 열심히 공부하기 시작했고, 그날 느꼈던 부끄러움은 훗날 내가 진정으로 성장할 수 있었던 원동력이 되었다. 그리고 지금은 그때의 경험을 밑거름 삼아 한층 더 성장한 개발자가 되었음을 실감한다. (지금은 간단한 API는 눈감고도 뚝딱 만들 수 있다 ㅎㅎ)
 
 
 

---

 
 
 
 

1월~2월

Fling, 첫 배포 자동화를 경험하다

지금봐도 디자인이 너무 예쁘다...

GitHub - Leets-Official/Fling-BE: 꽃다발을 통한 추억 공유 서비스, Fling 🌷

Fling은 Leets 2기 시절, 겨울방학에 개발한 프로젝트로 졸업자가 자신의 졸업 페이지를 SNS에 공유하면, 지인들이 해당 페이지에 접속해 꽃과 편지를 선택하여 축하 메시지를 보낼 수 있는 서비스였다.
기획 자체는 지금 생각해도 좋은 아이디어였지만, 아쉽게도 서비스는 기대만큼 잘 되지 않아 아쉬움이 남는다 😭
 
이 당시, 나는 서비스의 전반적인 배포를 담당했다.
 
처음으로 “도메인”을 구입하고 프론트 서버와 연결하는 경험을 했는데, DNS 레코드 타입에 대해 전혀 알지 못한 채 블로그를 참고하며 진행하다 보니 꽤나 고생을 했다. 하지만 결국 연결을 마친 후, DNS 원리에 대한 이해가 생겨 큰 보람을 느꼈다 😊
 

 

---

 

Fling 아키텍처 구조도

또한, Jenkins FreeStyle을 사용하여 배포 자동화를 구현했다. 초기에는 개발하면서 deploy 스크립트를 작성해 서버에서 수동으로 실행하는 방식으로 배포를 했었는데, 점차 그 방식이 번거롭다고 느껴 Jenkins를 사용하게 되었다.
Docker에 대한 개념도 없던 상태에서 수많은 실패와 싸우며 고군분투했었는데, 결국 성공적인 배포가 이루어졌을 때 그 기쁨은 아직도 잊을 수 없다. ㅎㅎ
 
 

---

 

 

PR을 날리면 빌드를 해서 성공 여부를 알려준다!

 
개발기간~서비스 운영기간 동안 Jenkins FreeStyle을 이용해 CI/CD 워크플로우를 운영하면서, 한 가지 불편함을 느꼈었다. 바로 배포 실패가 발생했을 때, 문제가 Jenkins에 있는 것인지, 아니면 Gradle 빌드 문제인지를 매번 확인해야 하는 번거로움이었다.
 
서비스 종료 후 서버 인프라를 정리하면서도 "CI/CD 워크플로우가 Jenkins를 통해 작동되기 전에 Gradle 빌드의 성공/실패 여부를 미리 확인할 수 있었으면 좋겠다"는 아쉬움이 계속 남았다. 이를 그대로 넘기기에는 마음이 찝찝해서 대안을 찾기로 했고, 그 과정에서 Jenkins 플러그인 중 하나인 ‘GitHub Pull Request Builder’를 알게 되었다.
 
이 플러그인을 이용하면 Pull Request 단계에서 Gradle 빌드의 성공 여부를 미리 검증할 수 있어, 배포 단계에서 발생하는 불필요한 오류를 사전에 방지할 수 있다는 이점이 있었다. 실제로 적용해 본 결과, PR 시 빌드 성공 여부를 확인할 수 있게 되어 배포 전에 Gradle 빌드 문제인 지 알 수 있어 효과적이었다.
 
하지만 또 다른 문제가 발생했다. PR 단계에서 빌드 성공 여부를 확인한 뒤에도 모든 PR이 자동으로 배포 단계까지 진행되는 상황이 발생한 것이다. 이 문제를 해결하기 위해 여러 자료를 찾아보고 질문도 해봤지만, 당시에는 적절한 해결책을 찾지 못했다. 😭
(지금 와서 생각해보면, Jenkins FreeStyle을 활용할 때 빌드용 프로젝트와 빌드 후 조치용 프로젝트를 각각 따로 만들어 관리했다면, 원하는 결과를 얻을 수 있었을 것 같다.)
 
그래도 이 경험을 통해 팀원들에게 더 편리하고 효율적인 CI/CD 환경을 제공하기 위한 방안을 깊이 고민할 수 있었고, 훗날 더 발전된 Jenkins Multibranch Pipeline을 구축할 수 있는 사전 지식을 쌓는 계기가 되었다.
 
 
2편에서 이어서...