Day 136 - 취하여(취업을 위하여) 프로젝트 32%, 숨 참고 알림으로 딥 다이브(Deep Dive), 수신함 터뜨리기는 덤

1. 프로젝트 진행 상황 및 계획 

🥇 이메일 전송 기능 1차 리팩토링(refactoring)하기 (진행 중, 2025.02.20 완료 목표) 
🥈 새로운 기술 없이 실시간 알림 기능 구현하기 (진행 전, 2025.02.20 완료 목표)

🥉 실시간 알림 기능 구현 방법 및 각 방법의 장단점 공부하기 (진행 중, 2025.02.23 완료 목표)
4️⃣ API 명세서 수정 및 검토하기 (진행 전, 2025.02.23 완료 목표) 

5️⃣ 리드미(README) 틀 완성하기 (진행 전, 2025.02.23 완료 목표) 

6️⃣ MVP(최소 기능 제품) 버전 테스트 코드 작성하기 (진행 전, 2025.02.23 완료 목표)

 

2. 수신함을 터뜨렸다. 

(1) 깃허브 브랜치 링크

(2) 알림 기능 찾아 삼만리 Day 5 링크

이메일 전송용 스프링 스케줄러(Spring Scheduler)를 고치다가 수신자의 받은편지함을 빵 터뜨렸다. 존재하지도 않는 이메일의 수신함을 터뜨리다니, 스스로가 대단했다. 나중에 꼭 수신자 이메일 검증도 추가해야지.

 

3. 숨 참고 알림으로 딥 다이브(Deep Dive), 이렇게 한 기능을 깊게 판 적이 있었나? 

프로젝트 1주 차까지만 해도 'API 개수도 다른 팀보다 적은데 할 일이 이게 다인가?' 의구심이 종종 들었는데 기우였다. 초반에는 정말 몰랐다.

 

뭐 하나 시도했다 하면 할 일이 줄줄이 소시지인 양 뒤따라온다는 점을.

 

이거 한 번 적용해 볼까 떠올린 순간 기록할 거리가 뻥튀기된단 사실을.

경험하지 않고도 탄탄한 논리로 무장해서 새로운 기술을 쓰면 얼마나 좋겠냐마는 안 된다. '잘 안 된다'도 아니고 그냥 안 된다. 검색도 해 보고 공식 문서도 종종 찾아 읽어보지만, 솔직히 글자로만 접해서는 그 기술의 쓸모가 막 와닿지 않는다. 새로운 기술이 생기기 전에도 어떻게든 기능은 구현되었을 테고, 그럼 그 기술을 쓰지 못할 때를 대비하여 기존의 지식을 전부 써서 구현해 봐야 않을까, 이런 생각도 마음 한쪽에 있다. 제대로 불편을 겪고 싶다면 개발자라는 사원증을 받기 전, 지금이 적기라는 마음도 있고.

 

한 가지 기능을 이렇게 깊게 파고 들어간 적이 처음이라 그 어느 때보다 서툰 나 자신을 많이 마주한다. 어렵다고 불평할 시간에 고민을 한 번 더 해야겠다. 어느 순간 '언제 적응했지, 나?'라고 스스로 감탄할 만큼 성장했을 테니까.