🎉 2년 만의 복귀전
2년 전, 개발자로서 첫 직장이었던 스타트업에서 사수 없이 프론트엔드 개발자로 1년을 보냈었다.
피드백 없는 환경에서 나름 스스로 방향성을 찾으려 노력했지만, 여러 이유로 번아웃이 찾아왔다..
성장이 멈췄다는 불안감에 퇴사를 결정했고, 섣부른 결정이었는지 생각보다 번아웃을 회복하고 나를 되돌아보는 데 예상보다 엄청 긴 시간이 걸린 것 같다.
긴 휴식기 동안 이런저런 일을 하면서 '그동안 해왔던 것 중에 내가 원하고 잘할 수 있는게 뭘까?' 생각했다.
내가 내린 결론은 '개발'이었고, 가장 몰입했던 기억 역시 코딩할 때였다.
다시 도전할 용기가 생긴 나는 제대로 다시 시작해보기 위해서, 감도 찾고 협업 경험도 채울 수 있는 국비교육을 듣게 되었다.
그리고 새로운 시작에 '새 장비'가 빠질 수 없는 법. 😎
새 키보드를 사고 타건음을 듣고 있자니, 빨리 코딩하고 싶어지는 기분이 들었었다.
🚀 시작된 첫 프로젝트
설계 포함 약 한달 간의 프로젝트가 시작되었고, 나는 팀장을 맡게 되었다. 메인 역할은 PM과 프론트엔드를 담당하게 되었는데, 프로젝트 시작 전에 목표가 몇가지 있었다.
1. 무지성 복사 붙여넣기 금지, 이유 찾기
원래 성격도 그렇지만 매사에 이유나 원인을 찾는 걸 좋아하는데, 개발하면서도 단순 구현보다는 '이게 최선인가? 왜 이렇게 짜야 할까?' 를 숨쉬듯이 생각하려했다.
2. '기간 내 완성'과 '리팩토링' 균형 잡기
국비교육 특성상 취업이 목표가 아닌 사람도 많고 코딩 자체가 낯선 사람들도 많이 듣기 때문에 내가 팀장으로서, 혹은 조금이라도 개발을 해본 입장으로서의 책임감이 들었다.
솔직하게 말하면 '내가 할 것만 야무지게 파서 많이 배우고 내것을 챙기자' 라는 생각도 했지만, 막상 팀장을 맡게 되니 프로젝트의 기간 내 완성이란 목표에 더 치중하게 됐다.
그래서 조건을 더했다. 기간 내 완성에 집중하되, 프로젝트가 끝나고 반드시 리팩토링하자!
3. 이번엔 라이브러리 사용을 줄여보기
생산성으로보나 편의성으로 보나 좋은 라이브러리가 있다면 사용하는게 맞다고 생각은 한다.
하지만 난 배우는 중이고, 사람들이 왜 많이 사용하는지도 모른채 무분별하게 사용하고 싶지는 않았다.
그래서 최소한의 라이브러리만 사용하고, 핵심 기능들은 되도록 직접 구현해 보며 해당 라이브러리들이 왜 필요하고 어떤 문제를 해결해 주는지 몸소 겪고자 했다.
4. AI는 '도구', 주도권을 뺏기지 않기
2년만에 복귀해서 가장 놀란 부분이다. 그때만 해도 ChatGPT만 조언을 얻기 위해 조금 사용할 뿐, 대부분 구글링하며 프로젝트를 수행했던 기억이다.
하지만 복귀해보니 간단한 서비스 하나 쯤은 AI로 '딸깍' 하면 구현되는 것을 보고 '개발자가 필요한거지...?' 하고 당황했다.
AI가 트렌드인 것은 잘 알겠지만 나는 나대로 살 길을 찾아야 하는 법. 서비스 흐름이나 어떠한 결정의 기준, 시스템 아키텍처는 조언을 구할 지언정 내가 결정하고자 했다.
뻔한 말일 수 있지만, 이렇게 훈련하다보면 AI를 도구로 활용했을 때 나도 더 좋은 인력이 되지 않겠냐는 생각으로 정한 목표였다.
결론부터 말하자면, 지킨 것도 있지만 삽질도 많이 했다.
🚧 결국 마주한 문제들
2년 만의 복귀인데다 리더 역할을 맡아본 적도 없었기 때문에 '더 좋은 구조와 설계'에 대해 더 찾아보고, 잘하고 싶었다.
그래서 프로젝트 구조, 관심사 분리, 인증 및 모달 Context 전역화 등 나름 신경써서 설계하고 구현하려고 노력했다.
하지만 프로젝트가 진행될수록 설계에 딱 맞아떨어지게 구현되진 않았고, 중간중간에 재정립하는 시간을 갖지 못해서 문제들이 생기기 시작했다.
📢 정보
프로젝트 간단 설명
웹 기반으로, 수면 상태를 코골이 감지 위주로 모니터링 및 대응하며 사후 레포트까지 제공하는 서비스였다.여기서, 나는 관심있었던 React를 기반으로 프론트엔드를 개발했다.
1. ⚓ God Hook
핵심 기능을 구현하면서, 나름 UI와 로직을 분리하겠다고 커스텀 훅을 만들었다.
그런데 여기서 마이크 음성 수집, 상태 관리, 서버 전송, 결과 데이터 처리, 알람 트리거 등 훅의 부피가 걷잡을 수 없이 커졌다.
문제를 자각했을 땐 일정에 쫓길 때였다, 이를 분해하자니 당장은 자신이 없고 기능 추가나 디버깅은 점점 더 어려워졌다.
그래서 회고하는 현재 기준, 단일 책임 원칙을 위반한 거대 훅이 되어있다.
2. 🎢 성급한 추상화
개발을 시작하고서 공통으로 자주 쓰일 것 같은 인증, 비동기 요청 처리 로직을 커스텀 훅으로 미리 만들었다.
그런데 React를 처음 써본 것도 있지만 실제 사용 패턴을 명확히 파악하기 전에 예측만으로 시도하다 보니, 개발이 진행될수록 구현 내용과 미리 짜둔 훅의 구조가 어긋나기 시작했다.
3. 🤦🏻♂️ 일관성 부족
프로젝트 기간 중에 '아 이건 이렇게 하는게 더 좋겠구나' 라는 깨달음을 얻고, 그 이후에 작성하는 코드에는 개선된 방식을 적용했다.
문제는 기존에 작성해 둔 코드들이 방치되다 보니, 두 가지 (혹은 그 이상..?) 방식이 다르게 공존하면서, 전체적으로 가독성이나 통일성이 떨어졌다.
일정에 쫓긴다는 핑계로 그때 그때 동기화하지 않은 나의 잘못이다.
4. 💫 끊임없이 늘어나는 폴더 구조
초기에 폴더 구조를 나름 신경써서 설계했다고 생각했지만, 무언가를 구현할 때마다 '이 파일은 어디에 넣지?' 라는 고민을 하게 되는 순간이 생겼고, 그때마다 폴더를 생성하거나 수정했다.
결국 후반부에는 프론트단 폴더 구조가 10개까지 늘어나며, 나는 원하는 파일을 금방 찾을 수 있지만 다른 사람이 찾기엔 시간이 필요한 구조가 되어버린 것 같다.
💡 삽질에서 얻은 것
각 문제에 대해 배운 것은 무엇일까 생각했다.
1. ⚓ 단일 책임 원칙의 중요성
하나의 컴포넌트나 훅은 오직 한 가지 책임만 져야 한다는 것.
거대해진 훅을 보며, 가독성으로나 재사용성으로나 편의성으로나 이 것이 얼마나 중요한지 정말 크게 체감했다.
2. 🎢 추상화 타이밍
숙련도가 쌓이면 다를 수 있겠지만, 아직은 공통화를 예측해서 미리 하기보다는 실제로 반복되는게 보일 때 진행하는 것이 안전하겠다고 생각했다.
3. 🤦🏻♂️ 일관성의 가치
개선사항이 생기면 기존 코드도 함께 수정해야 유지보수 단계의 부담이 줄어들겠다는 생각이 들었다. (일단 그냥 보기가 싫다.....!)
4. 💫 리팩토링 시간 확보
물론 이번엔 나를 포함한 팀의 평균 실력에 비해 일정이 빠듯했기 때문에 시간을 확보하지 못했다.
하지만 가능하다면, 혹은 방치했을 때 프로젝트 기간 내에 생길 리스크를 비교해서 리팩토링 시간을 확보하면 좋겠다는 생각을 했다.
🎯 그래서 앞으로 할 것은?
프로젝트는 기간 내에 완성되었지만, 가장 처음에 목표한 것처럼 리팩토링 진행 계획과 함께 목표 습관을 설정해 보았다.
1. 거대 훅 분해하기
단일 책임의 원칙을 지키며 잘 분해해보려 한다.
2. 공통 훅 사용처 살펴보기
미리 만들어뒀던 인증이나 비동기 요청 처리 훅을 사용한 곳과, 같은 로직이지만 사용하지 않은 곳을 점검해보려 한다.
3. 간단한 리팩토링은 습관화하기
프로젝트 초반에는 잘 지켰다고 생각하는데, 후반에 접어들수록 소홀해졌던 것 같다. 더 의식할 수 있도록 해야겠다.
4. 프로젝트 구조 개선
코드리뷰를 요청하면서 'FSD 아키텍처' 라는 키워드를 팁으로 받았는데, 이를 학습해서 적용해볼까 한다.
✍️ 마무리
2년 만에 다시 마주한 개발은 쉽지 않기도 하지만 역시 재밌다.
회고도 처음 해보는 건데 얻는 것이 정말 많다고 느껴져, 앞으로도 프로젝트와 회고를 루틴화 해보면 좋겠다는 생각을 한다.
아직 국비교육 과정이 남아있고 여유 시간도 많이 부족하지만, 틈틈히 리팩토링과 개인공부를 하면서 목표한 것들은 끝내고싶다!
응원합니다^^