25년 회고록

2025년 회고

올해가 얼마 남지 않은 시점에서, 지금의 나를 기록해 두고 싶어 이렇게 글을 남긴다.
올해 나는 크게 두 가지 경험을 했다. 하나는 일정 관리 개인 프로젝트, 다른 하나는 팀 프로젝트였다.

1. 일정 관리 프로젝트

기존에 진행하던 Coffies 프로젝트만으로는 더 이상 한계가 명확하다고 느꼈다.
그래서 멘토링을 신청했고, 그 과정에서 완전히 새로운 프로젝트를 시작하게 되었다.

이 사이드 프로젝트를 진행하면서 정말 많은 개발 지식과, 그보다 더 중요한 개발 문화를 배웠다.
그중 가장 인상 깊었던 것은 코드 리뷰였다.

기존에는 혼자 브랜치에서 작업하고, 인터넷 블로그를 참고해 코드를 작성하는 방식이 전부였다.
하지만 이번에는 브랜치를 나누고, PR을 올리고, 멘토에게 리뷰를 받고, 그 후에 머지하는 과정을 반복했다.

이 경험은 나에게 굉장히 큰 전환점이었다.
코드를 “돌아가게 만드는 것”이 아니라, 읽히는 코드, 고쳐질 수 있는 코드를 작성해야 한다는 감각을 처음으로 체득했다.

물론 과정은 순탄하지 않았다.
새로운 라이브러리를 익히고, 그 내부 동작을 이해하고, 실제로 적용하는 일은 생각보다 훨씬 어려웠다.

특히 Testcontainers를 사용한 테스트 코드 작성,
모니터링 서버를 별도로 띄운 뒤 제한된 용량의 서버를 유지하는 작업,
부하 테스트 이후 성능 지표를 수집하고 이를 기반으로 개선하는 과정은 정말 버거웠다.

하나의 작업에 10일 이상이 걸리기도 했고,
그때마다 “내가 이걸 할 수 있는 사람이 맞나?”라는 자괴감이 반복해서 들었다.

그럼에도 불구하고, 결국 문제를 해결했을 때의 쾌감은 말로 설명하기 어려웠다.
무엇보다 가장 크게 바뀐 것은 개발에 대한 태도였다.

이전에는 에러 로그를 보고 당장 터진 부분만 고치는 방식으로 접근했다면,
이 프로젝트를 통해서는 문제를 마주했을 때 자연스럽게
“왜 이런 구조가 되었을까?”, “근본 원인은 뭘까?”를 먼저 생각하게 되었다.

지식이 쌓이면서 코드를 바라보는 시야가 조금은 넓어졌다는 느낌을 처음으로 받았다.

2. 팀 프로젝트

개인 프로젝트 위주로 진행해왔기 때문에, 협업 경험의 필요성을 느껴 팀 프로젝트에 참여했다.

프로젝트 진행 과정에서 프론트엔드와 백엔드 간 요구사항 정의가 명확하지 않아
개발 방향이 어긋나는 문제가 발생했다.

이를 해결하기 위해 중간에서 요구사항을 정리하고 조율을 시도했지만,
커뮤니케이션 체계가 부족한 상태에서는 한계가 있었다.

이후 테스트 코드 안정성 문제를 해결하기 위해
팀원과 페어코딩을 통해 구조를 개선했고, 유지보수성을 확보했다.

또한 역할 분담이 명확하지 않은 상태에서 작업 범위가 확장되면서
일정 리스크가 발생할 수 있음을 경험했다.
이에 역할을 재정의하여 백엔드와 프론트/배포를 분리했다.

이번 경험을 통해 협업에서는 기술보다
명확한 역할 정의와 커뮤니케이션 구조가 더 중요하다는 것을 배웠다.

마무리

이번 한 해를 돌아보면,
기술적인 성장만큼이나 사람과 협업의 어려움을 크게 체감한 시간이었다.

단순한 프로젝트조차도 팀으로 진행하는 것은 쉽지 않았고,
다양한 사람의 태도와 책임감을 직접 경험할 수 있었다.

힘든 해였지만,
그만큼 분명하게 배운 것도 많은 한 해였다.

이 기록은 나중에 다시 흔들릴 때,
“그래도 여기까지는 왔다”는 증거로 남겨두고 싶다.