첫 Java 프로젝트
처음으로 프론트 설계부터 API서버 배포까지한 프로젝트.
Java + Spring Boot + JPA를 사용하여 만든 과정에서 느꼈던 점을 공유합니다.
어떻게 백엔드를 시작했나?
React 프로젝트 시작
저는 JS와 React를 사용하여 개인 프로젝트를 시작했었습니다. 어렸을 때부터 미술을 좋아해서 시각적으로 꾸민다는 것에 마음이 가서 프론트에 마음이 갔었습니다. 백엔드는 잘 모르다보니, 저에게 익숙한 firebase를 사용해서 프로젝트를 시작 하게 되었습니다.
firebase말고 내가 직접 만들어보자
주변 친구들이나 개발자 사이에서 firebase에 대한 인식이 그렇게 좋은 것 같지 않다는 기분이 들었어요. firebase는 빠르게 Prototype을 만드는데 사용되는 반쪽짜리 서비스 느낌이었습니다. 그런 firebase에 의존해서 프로젝트를 만든다는게 뭔가 부끄러웠습니다. 제 프로젝트가 반쪽짜리 프로젝트인 것 같았거든요. (비하할 의도는 아닙니다.)
firebase 다른 관계형 데이터 모델과 달리, firebase는 Docuemnt-Collection모델의 언어라서, path를 통해서 저장하는 특징이 있습니다. 그래서 데이터가 연관된다는 느낌보다는 서로 독립적이라는 느낌이 많이 들었습니다. 또 백엔드에서 테이터 구조를 설계한다기 보다는, JS에서 설계해서 데이터를 저장한다는 느낌때문에 너무 복잡하다는 생강도 들었던 것 같습니다. 그래서 나만의 API server를 만들어보고 프로젝트에 적용해보자는 생각을 가지게 되었습니다.
아래는 프로젝트를 진행하면서 느꼈던 점을 적어보았습니다.
패키지 내에서 클래스 분류하기
Spring Boot가 처음이라 책 2개를 보면서 공부를 했습니다. 하지만 2개의 책에서 패키지로 클래스를 분류하는 방식이 달라 재밌었습니다.
하나는 Controller, Repository, Service, Dto, Entity 이렇게 기능별로 패키지로 묶어서 관리를 했습니다.
다른 하나는 User, Question, Answer,… 등 도메인별로 관리를 하더군요.
‘어떻게 디렉터리를 작성해야하나?’는 항상 고민이었습니다. 때로는 기능별로, 때로는 관련있는 도메인별로, 때로는 제 마음대로 하기도 했으니까요.
이번프로젝트에는 뭘 선택하더라도 크게 상관은 없었지만, 저는 기능별로 분류해서 관리하는 방식을 택했습니다. 구현할 기능이 적어서 기능별로 분류해서 관리하는게 찾기에 편했기 때문입니다. 하지만 구현할 기능이 많아진다면 도메인별로 관리하는 것이 한 패키지 내에 클래스들이 적어 관리하기 편할 것 같다는 생각이 드네요.
테스트 코드를 배우자
이번 프로젝트에서는 JUnit을 이용한 테스트 코드를 많이 사용하지 않았습니다. 빠르게 만들 필요가 있는데 JUnit 사용법을 몰랐기 때문입니다. 그래서 테스트를 크롬 개발자 도구 콘솔이나 Post man을 이용해서 테스트를 진행했습니다.
이번에는 테스트를 url을 중심으로 진행했기때문에, 위 툴만으로도 충분히 테스트가 가능했다고 생각이 듭니다. 하지만 중간 과정이 복잡할수록 이번 기회에 JUnit이 필요할 거라는걸 느낍니다.
리팩토링은 언제하나…
사실 리팩토링이 중요하다는 걸 알고있지만, 기능을 막상 구현하고나면 그냥 넘어가버리는 경우가 많았습니다. 아무래도 빠르게 프로젝트를 완성해야한다는 압박때문인지도 모르겠습니다.
그렇게 미루고 미루다 결국 끝나면 결국 잘 안하게 됩니다. 끝나면 까먹은 코드도 많고, 다시 처음부터 이해해야하는 코드도 많으니 하기가 싫어지는 듯 합니다. 역시 리팩토링은 개발 도중에 주기적으로 하는게 좋아보입니다.
가장 이상적인 시기는 테스트를 성공적으로 마친 후 라고 생각을 합니다. 이 시기가 해당 기능에 대해서 구체적으로 기억도 잘나고 금방금방 수정을 할 수 있을 거라는 생각이 드네요.
이해 없이 그냥 가져다가 쓰는 것 같아
Spring Security는 이해한다는 느낌보다, 이미 구현이 되어있는 걸 가져다가 쓰기만 한다는 느낌이 강했습니다. 메서드 하나하나를 이해보려해도, 사용하는 메서드가 너무 많아서 차마 이해해보겠다는 엄두가 안났습니다. 그래서 큰 흐름만 공부하고 이미 구현되어있는 코드만 이해하고 가져가 쓰는 방식으로 코딩을 했습니다.
대충 넘어갔지만, 이러한 미스테리함이 저에게는 상당히 매력적이었습니다. 미지의 세계를 탐험하며 수수께끼를 풀어가는 느낌이 들었습니다. 그래서 이번 기회에 인증 부분을 깊게 공부해볼 예정입니다.
데이터 통신하는게 이렇게 어려워? 잠도 못자고… (CORS, HTTPS)
웹 프론트와 API server를 분리해서 배포를 했습니다. 이때 로컬 localHost 상에서는 HTTP 통신으로 데이터를 잘 주고 받았는데, 배포된 서비스에서는 데이터를 주고받지 못하는 문제가 발생했습니다. 2가지 이유 때문인데요, 첫번째는 CORS(Cross-Origin Resource Sharing)이고 두번째는 HTTPS와 HTTP간의 통신 문제 때문입니다.
CORS는 생각보다 금방 해결할 수 있었습니다. 하지만 HTTPS는 상당히 번거로웠습니다. 도메인 구매부터 IP에 도메인 할당, NGINX를 이용해서 SSL인증서 적용까지 해야했습니다. 모든게 처음이었고 네트워크 관련 지식도 부족했습니다. 밤 11시부터 기숙사 휴게실에 혼자 앉아 새벽 5시까지 이런 저런 시도를 해봤습니다. ‘내일하자’라는 생각이 많이 들었지만, 내일이 되면 흐름이 끊겨서 더 오래걸릴거라는 두려움에 ‘어떻게든 오늘 끝내고 잔다!’라는 생각으로 임했던 것 같습니다. 결국 6시간의 대장정 끝에 인증을 받았습니다. 아직도 그때 통신이 잘 되었던 순간을 떠올리면 도파민이 뿜뿜 나오네요.
처음은 뭐든 어려워
프론트부터 백엔드까지 처음부터 구현하고 배포한 첫 프로젝트였습니다. 누군가가 '가장 어려운게 뭐였어?'라고 물어본다면, 저는 AWS에서 SSL 인증은 받는 거라고 답할 것 같습니다. 사실 코딩과 구현은 어렵다기보단 시간만 들이면 할 수 있다는 느낌이 강했습니다. 하지만 SSL은 한번도 밟아보지 않은 미지의 영역이라 망망대해를 떠나는 느낌이었습니다. '3시간만 하면 끝낸다!'라는 느낌이 아니었거든요. 마치 콜럼버스가 대서양 한 가운데에 있을 때, '아메리카 대륙엔 언제 도착할지' 를 모르듯이, SSL 인증을 언제 받을 수 있을지 몰랐거든요. 특히 DOMAIN이 전세계에 퍼지는데에 시간도 24시간 정도 소요된다고 하는데, 언제 될지도 모르는 상태에서 발발 떨었던 기억이 납니다.
하지만 이제는 이미 발을 밟은 대륙이니만큼 다음번 할때는 손쉽게 할것 같습니다. 저에겐 뭐든 처음만 어려우니까요.
