데브코스 1 차 프로젝트로 부터 1 개월 반이 지났습니다.
그 동안 2 ∘ 3 프로젝트를 진행했는데, 이번 포스팅에는 이를 회고하는 글을 적도록 하겠습니다.
⏩ 데브코스 커리큘럼
이번에 진행한 프로젝트는 조금 특이했습니다. 데브코스 커리큘럼 상 2 차 프로젝트는 Java 를 이용한 프로젝트 구현, 3 차 프로젝트는 Kotlin migration 으로
이루어졌기 때문입니다.
그래서 2 차 프로젝튼느 대게 쉴 틈 없이 구현만 하였다면, 3 차 프로젝트는 좀 더 여유롭게 리팩토링, 성능 개선에 집중하엿습니다.
📌 프로젝트의 시작 - 2 차 프로젝트 진행
이번 프로젝트에서도 왜 그런진 모르겟지만... 제가 팀장을 담당하였습니다.
그래서 개발하며 팀원 ∘ 서비스 기능간 진행 상황을 정리하고 수시로 문서화를 진행했습니다.
 |  |
저희 프로젝트는 영화 검색 과 블로그 리뷰 를 통합한 서비스를 구현하는 프로젝트였습니다.
저는 이 중 블로그 리뷰 + 댓글 부분을 담당해 프로젝트를 수행하였고, 특히 Google Cloud Storage 에 이미지 저장하는 부분에 집중하였습니다.
블로그 이미지 저장
사실 "블로그 리뷰" 라 하면 제목과 본문, 그리고 여러 미디어가 첨부된 서비스를 생각합니다.
하지만 지금까지 배운 내용만으로는 이걸 어떻게 구현하는지, 특히 프론트와 백엔드의 역할 구분은 어떻게 되야 하는지 알 수 없었습니다.
그래서 이를 알기 위해 다양한 reference 를 검색하였고, 그러던 중 아래의 영상을 발견하였습니다.
스프링 부트 CKEditor 1 : 실습 환경 및 버전 구성
정말 우연찬게도 현재 막힌 상황을 해결하는 정확한 영상이었습니다. 영상 제작자 개발자 유미 님 정말 감사합니다....
그렇게 일반적인 블로그 작성 과정이 어떻게 이루어지는지 확실히 파악할 수 있었고 개발에 착수할 수 있었습니다.
 |  |
결국에 백엔드는 일반적인 CRUD 작업에 이미지 같은 멀티미디어 처리를 하면 끝나는 것 이었습니다.
그 때 마침 Google Cloud Storage 가 3 개월 무료라는 소식을 들어 GCS 를 이미지 저장소로 선정하였습니다.
2 차 프로젝트 마감 - 중간 발표
그렇게 블로그 작성 기능을 마무리할 즈음 2 차 프로젝트의 마감이 다가왔고, 그 외 주요 서비스 개발을 완료하였습니다.
마감과 동시에 프로젝트 진행 현황을 보고하는 중간 발표가 이루어졌는데, 데브코스 강사님들께 프로젝트의 개요, 서비스 기능, 시연 등을 포함하는 간단한 보고였습니다.
이 때 발표를 진행하며 프론트를 구현해 시연할 필요성을 느꼈고, 프로젝트 최종 발표 전까지 직접 제작하기로 하였습니다.
📤 프로젝트 개선 - 3 차 프로젝트 진행
데브코스 커리큘럼 상 3 차 프로젝트는 Java 에서 Kotlin 마이그레이션이 전부였습니다.
하지만 이는 프로젝트라 하기에 너무 단조롭다 생각해 무언가를 덧붙이길 원했고, 결국 3 차 프로젝트에서 다음의 작업들을 수행하기로 하였습니다.
Java에서Kotlin마이그레이션(기존 커리큘럼)OAuth 2.0을 통한 소셜 로그인MyBatis에서Spring-data-jpa로 마이그레이션- 프론트 부착
물론 이를 진행하며 코드 리팩토링, Test Code 개선, 버그 fix 등의 기존 서비스를 개선하는 작업도 병행하였습니다.
저는 위 작업 중 MyBatis 에서 JPA 마이그레이션 을 담당해 3 차 프로젝트를 진행하였습니다.
MyBatis 와 JPA
Spring 에서 영속 기술을 이야기하면 항상 두 기술이 비교되곤 합니다.
물론 MyBatis 가 굉장히 오래된 기술이지만, JPA 또한 조금 나이가 있는 기술로 알고 있습니다. 물론 한국에선 최신 기술이지만...
그래서 프로젝트 설계 당시,
"둘다 오래된 기술들인데, 굳이 기술에 특화된 이해가 필요한 JPA 를 사용해야 될까?""차라리 현업에서 많이 쓰이고 쿼리만 잘 짜면 되는 MyBatis 가 낫지 않을까?"
등의 의문이 제기되었었고, 결국 2 차 프로젝트는 MyBatis 를 이용하였습니다.
하지만 3 차 프로젝트를 통해 여유시간이 생겼고, "마이그레이션을 통해 두 기술 차이를 직접 알아보자" 라는 의견이 제시되었습니다.
그래서 저희는 기존 MyBatis 코드를 남기면서 JPA 를 추가하는 형태로 마이그레이션을 진행하였습니다.
마이그레이션은 Spring profile 을 이용해 작업하였습니다.
본래 profile 은 개발, 운영, 테스트 환경 등을 구분해 등록되는 Bean 이나 메서드 동작을 다르게 하기 위해 사용됩니다.
저희는 이 중 Bean 을 선택해 등록하는 기능에 집중하였고, 결국 JPA profile, MyBatis profile 을 분리해 사용되는 DAO 를 구별하였습니다.
 |  |
이러한 마이그레이션 과정으로 두 기술의 실태를 확인할 수 있었습니다.
확실히 마이바티스는 기술적 고민 없이 쿼리만 잘 짜면 문제없이 동작하였습니다. 사실 쿼리만 짜야됬었던...
하지만 JPA 와 비교했을 때 단점이 더 많았고, 이를 통해 대부분의 상황에선 JPA 가 유리함을 체감하였습니다.
🚨 트러블 슈팅
프로젝트를 진행하며 다양한 트러블 슈팅을 경험했습니다.
협엽과 관련된 트러블 슈팅을 겪기도 했었으며, CORS 를 확실히 알게 해준 트러블 슈팅도 겪었습니다.
특히 Spring-data-jpa 와 관련된 "이상한 에러" 를 발견하였는데, StackOverflow 에 질문하고 공식 Github Repo 에 Issue 를 등록하는 비개발적 경험을 쌓을 수 있었습니다.
위 트러블 슈팅은 모두 아래 링크를 통해 확인할 수 있습니다.
[Troubleshooting] - Git rebase 시 중복 커밋 존재[Troubleshooting] - CORS 탐방기[Troubleshooting] - Spring-data-jpa 의 순환 의존 에러
✅ 프로젝트 마무리
JPA 마이그레이션을 진행한 후, 저는 프로젝트 발표 담당을 맡게 되었습니다.
 |  |
특히 데브코스에서 보고용 PPT 를 요구하였기에 이들을 준비하다보니 어느새 프로젝트 마지막날이 다가왔습니다.
사실 발표 자체는 크게 부담되진 않았지만 발표 시간이 걱정스러웠습니다.
아무리 시간을 줄이려 해도 목표 시간인 10 분을 초과하였고, 더이상 안되겠다 싶어 강사님께 발표 피드백을 부탁드렸습니다.
이를 통해 확실히 발표자와 청중의 입장이 다른것을 알 수 있었습니다.
강사님께선 특히 트러블 슈팅 설명 중 Spring-data-jpa 순환 의존 에러 에 흥미가 있으셨는데, 이 부분을 간단한 예시로 만들어 설명하는 방식을 제시하셨습니다.
그렇게 강사님의 피드백을 토대로 발표를 개선하였고 성공적으로 발표를 마무리할 수 있었습니다.
💭 회고
사실 저희 프로젝트 자체는 남다른 강점이 없습니다.
특별한 기술을 사용한 것도 아니고 획기적인 비즈니스 로직이 있는 것도 아닙니다.
하지만 이번 프로젝트는 지금까지 학습한 내용을 온전히 자신의 것으로 만드는 과정이었음에 의의를 두고 싶습니다.
누군가에게 "나 진짜 엄청난거 만들었어!!" 라 자랑할 순 없지만, "난 이렇게 성장하고 있어!" 라 부끄럼 없이 말할 수 있습니다.
정말 앞으로도 갈 길이 멉니다.
하지만 느리더라도 꾸준히, 한걸음씩 정성을 다해 걸어가면 막막해 보이던 드높은 곳에 오르리라 믿습니다.
언젠가 능숙한 개발자로서, 저 자신에게 부끄럼 없이 살기를 바라며.
오늘도 한발 나아가겠습니다.
