[Project] Billim / 중고 물품 대여 서비스 팀 프로젝트 후기

DNS 설정까지 마친 후 쓰려 했으나 생각보다 프로젝트가 길어져 먼저 일찍이 끝난 백엔드 파트에 대한 후기를 먼저 남겨보려 한다.
 

---

기획 배경

Spring 공부를 시작한 지 10개월 정도가 지났다. 나는 내가 이해한 것들을 정리하지 않거나 적용 해보지 않으면 금방 잊어버리는 탓에 지금까지 배운 것들을 모두 적용시켜보겠다는 취지로 프로젝트를 진행해보고 싶었다. 마침 같은 데이터베이스 연구실의 친구도 나와 뜻이 비슷하여 함께 프로젝트에 참여하게 되었다. 주제에 대한 고민을 하던 도중, 중고 물품을 사고 파는 '당근마켓'에서 아이디어를 얻어 중고 물품을 대여해주는 플랫폼을 만들어 보면 좋겠다라는 아이디어에서 시작해 이번 프로젝트를 중고 물품 대여 서비스 개발로 주제를 잡고 진행하였다. 

---

개발 환경

• Language : Java 11, Javascript
• Framework 
  • BE : Spring Boot 2.7.13
  • FE : React 18.2.0
• DataBase : MySQL
• ERD Diagram : ERDCloud
• IDE : IntelliJ, MySQL WorkBench
• API Docs : Swagger, Notion
• 협업 툴 : GitHub, Notion
• 인프라 : AWS(EC2, S3)

개발 기간 : 2023/06/28 ~ 2023/08/16
 
개발 인원

• Front-End (2)

leejaejae - Overview

choimyeongsu - Overview

• Back-End (2)

park0jae - Overview

Dongwoongkim - Overview

---

ERD Diagram

---

프로젝트 후기

협업을 통한 기회

• API 개발은 나와 park0jae 둘이 페어 프로그래밍으로 진행했다. 내가 작성한 코드와, 파트너가 작성한 코드에 대해 서로 즉각적으로 피드백하며 코드를 더 좋은 구조로 바꾼다거나, 자주 사용하는 메소드 분리하고 하나의 메소드가 수행하는 역할이 많을 때 메소드를 분리해주는 등 코드를 읽기 좋게 짜는 방법에 대해서 생각할 수 있었다. 각자의 맡은 바 책임을 분리하기 위해 Notion을 처음 사용해봤는데, 진행 상황이나 리펙토링야할 부분들에 피드백을 문서화하니 프로젝트가 효율적으로 진행된 것 같다. 그 외에도 버그를 고칠 때 내가 생각해내지 못했던 부분들을 파트너가 기막힌 해결책을 찾아왔을 때, 아 이래서 협업이 중요하구나 하고 느꼈던 것 같다. 페어 프로그래밍 또한 작은 협업이라 볼 수 있으니, 협업을 통한 커뮤니케이션의 경험을 체험해봤다고 할 수 있겠다. 어쩌면 공부 이상의 경험을 얻을 수 있는 기회가 되었다고 느껴, 앞으로 자주 많이 협업을 해보고 싶다.

---

원리에 대한 이해와 적용

[Security] Jwt Authentication 구현 by Overriding Spring Security 인증 아키텍쳐

• Spring 기반의 보안을 담당하는 프레임워크인 Spring Security 사용하면서 JWT 인증 및 권한 부여하는 로직에서 Security Filter가 내부적으로 어떻게 동작하는지에 대한 원리를 깊게 공부할 수 있었다. 전체적인 인증관련 아키텍쳐에 대한 이해를 선수적으로 잡고 진행하니, 코드 작성과 참조를 할 때 많이 도움이 되었던 것 같다.  

public abstract class Guard {

    public final boolean check(Long id){
       return SecurityUtil.isAuthenticated() && hasAuthority(id);
    }

    private boolean hasAuthority(Long id){
        return SecurityUtil.extractMemberRolesFromContext().contains(RoleType.ADMIN) || isResourceOwner(id);
    } 

    abstract protected boolean isResourceOwner(Long id);
}

• abstract class의 개념만 알고 실제적으로 사용해 본 적은 처음이였다. 추상클래스를 언제 쓰는지 머리로는 이해했지만 직관적으로 와닿지는 않았었다. 이번에 리소스의 Owner이거나 또는 권한이 ADMIN인지 검사하는 클래스를 만들 때, 이 때 어떤 리소스에 대한 검사를 할 것 인지에 작성 하기 전, 추상 클래스에 공통 분모들을 표현(check(), hasAuthority()) 하고, 상속을 통해 여러 Guard 클래스를 확장해나감으로써 상위 Guard 추상 클래스와 하위 클래스 (PostGuard, CommentGuard) 간의 의미있는 연관관계를 구축할 수 있었다.

---

초기 설계의 중요성

• 요구사항 작성부터 ERD 설계까지 그리고 최종적으로 배포까지 해보지 않은 것들을 해보면서 배울 수 있었다. ERD 설계는 처음 단계에서는 막연히 엔티티들을 나열해놓고 이렇게 저렇게 엮으면 되지 않을까며 쉽게 생각했는데 외래키 제약조건이나 1:N 매핑으로 인한 N+1문제에 직면하게 되었다. 일대다 매핑을 지양하고, 페치조인하는 솔루션과 함께 ERD도 계속 수정해가면서 프로젝트가 진행되었다. 초기 ERD 설계를 잘 해놓는것이 매우매우 중요한 것 같다.
• 배포의 경우에는 아예 문외한이였는데 친구의 도움을 많이 받았다. 인프라적 지식이 전무해서 장벽이 꽤 높다고 생각했는데 부딪혀보니 생각보다는 어렵지 않았다. 내가 해보지 않은 것, 새로운 것들을 받아드리는 것에 대한 막연한 두려움이 있었는데, 생각해보니 그냥 당시에 주변에서 종강하니 나도 덩달아 공부하기 싫었던 게 아닐까 싶기도 하다. 

---

앞으로의 방향성

• 부족한 부분들이 무엇인지 파악하고 앞으로 어떻게 나아가야 할 지에 대해 방향을 잡을 수 있었다.

• 시도 때도 없이 친구에게 코드 리뷰를 요청했다. 내가 보지 못하고 있는 부분들을 독자 입장에서 듣고 싶었다. 실제로 친구의 피드백을 들으며 배울 점이 많았고, 작성자인 내 입장에서는 이게 최선이라고 생각했던 부분들은 최선이 아니였던 경우가 많았다. 메소드/URI 네이밍, 계층 분리와 클린 코드 사이에서 오는 딜레마나, 성능 최적화와 가독성에서 사이에서 오는 딜레마들은 아직도 어려운 것 같다. 가독성 높은 코드 작성 방법에 대해 고민해봐야 하는 시점인 것 같다. ( 일하고 있는 친구입장에서는 꽤 귀찮은 일일수 있는데 항상 흔쾌히 그리고 심지어 이 글을 작성하고 있는 지금도 코드를 리뷰해주고 디비자러간 친구에게 고마움을 느낀다 )
• Java ( 특히 객체지향적인 사고력 ) 더 깊게 공부하기 : 객체, 클래스, 상속, 다형성, 캡슐화 같은 객체 지향적인 '개념'과 객체지향적인 '사고력'은 전혀 다른 이야기인 것 같다. 개발에서 객체 지향 '개념'은 단순 OOP에서 사용되는 도구일 뿐, 그 자체에 집중하기 보다 이제는 객체지향적인 사고력을 길러 좋은 코드를 작성하는 방법에 대해 고민하고 생각해봐야 할 것 같다.
• Github 사용법 숙지 : 깃허브를 사용하는 데 익숙치 않아, branch를 분리하고 작업하는 것에 적응하기가 어려웠다. branch 하나만 파서 작업하고 main으로 merge하는 방식으로 진행했는데 이로 인해 merge 과정에서 충돌도 자주 발생하여 코드가 꼬이는 사태가 종종 발생했다. 

---

이뤄냈던 것들도 있지만 해내지 못했거나, 진행하면서 아쉬웠던 부분들도 많다.

• 대표적으로 STOMP, SockJS를 사용해서 클라이언트간 실시간 채팅 기능을 구현해보려 했었다. 단순 웹소켓을 사용해 채팅방을 구성하는 것까지는 어려움이 없었지만, STOMP를 적용해서 여러 채팅방을 구성할 때 어려움을 겪었다. 시큐리티까지 고려해야 했었기도 하고, 당시 테스트 코드 작성과 기존 코드 리펙토링을 중점적으로 하고 있을 때라 크게 신경을 못쓰고 흐지부지 넘어갔었던 것 같다. 다음에 기회가 된다면 해보도록 하자.

---

꼼꼼히 신경써야 할 것들

• 프론트와의 커뮤니케이션
  • CORS 대응 : CORS 설정을 분명 잘 해준 것 같음에도, CORS가 발생할 때가 있었다. 결론적으로 Security 필터에도 CORS 설정을 적용시켜주어야 하는데, 그렇지 않아 발생한 문제였다. 
  • API Docs : Swagger를 이용했지만 프론트단에서 읽기 어렵게 만들어져 있어, 직접 Notion에 작성했다. 이 과정이 괴로워 부분부분 꼼꼼히 작성하지 못한 부분들이 종종 있어 프론트에게 미안할 때가 있다. 귀찮더라도 놓치는 부분없이 작성하도록 신경써야겠다. 
• S3의 파일 소스를 어떻게 넘겨줄 것인가에 대한 고민 : 단편적으로 S3 버킷에 올라간 이미지의 URL을 리턴하는 방식을 사용했지만, 파일의 path가 소스코드 내에 하드코딩으로 작성되어 있기 때문에 보안 상 좋지 않아 보인다.
• 성능에 대한 고민 : 어떻게 쿼리를 짜야 데이터베이스 접근 횟수를 줄일 수 있을 지 고민해봐야 할 것 같다. 
  
  • 인덱스를 설정해 조회 쿼리 성능을 높이며 비교해봐야겠다.
  • N+1 문제가 발생할만한 코드가 꽤 존재
• 문제가 생겨서 해결책을 찾았다면 기록하는 습관을 남기자.

---

테스트 코드 작성의 중요성

• 난 테스트 코드 작성은 아직도 어렵다. 작성 자체에 시간도 오래걸릴 뿐더러, 서버에서는 잘 작동하는 코드가 테스트 코드로는 돌아가지 않는 경우가 있다. 이런 경우 테스트 코드가 잘못됐던지, 또는 메인 코드에 숨은 문제나 버그가 있을 확률이 높았다. 번외로 요구사항 변경으로 메인코드가 바뀌면 테코를 리펙해야 하니 큰 골칫거리였다.
• 일단 왜 중요한지 모른채로 테스트 코드도 돌아가도록 작성은 해두었었다. 하나의 메소드를 만들면 자동적으로 작성해야하는 테스트코드를 미뤄미뤄 마지막에 작성하려하니 죽을 맛이였다(대부분 내가아닌 파트너가 작성하긴했지만서도). 언제써먹을지도 모르는 테스트코드는 오래 전 작성한 메인코드가 어떻게 돌아가는지 파악할 때 덕을 보았다. 테스트 코드를 실행하며 전체적인 로직을 다시 확인하고, 구현해놓은 부분들이 정상적으로 동작하는 것을 확인할 수 있었다. 아직 내가 테스트 코드의 몸으로 직접 느낀 바는 여기까지인데, 프로젝트 규모가 커질수록 잘 짜둔 테스트 코드가 빛을 볼 것이라 생각한다. 테스트 코드 잘(깔끔, 읽기좋게) 짜는 법을 배워두어야겠다.

---

마치며

• 휴학한지 한 학기가 지났다. 백엔드 개발자가 되고싶어 Spring을 시작한지는 10개월 정도가 지난 시점이다. 현재는 스프링을 잠깐 뒤로하고 조만간 다가올 우아한테크코스 지원에 앞서 Java 문법과 개념들에 집중하고 있다. 공부를 하면서 느끼지만, 열심히 + 잘 하는 사람들이 참 많은 것 같다고 느끼고, 나의 부족함과 무지를 느낄 때가 많다. 거기에다가 나는 무언가를 배울 때 의문점이 생기면 작은 의문일지라도 일단 패스하고 넘어가지 못하는 뻣뻣한 유연성 탓에 배움의 속도가 느릴 때가 많다. 하지만 어쩌면 느린 덕분에 지치지 않고 앞으로 나아갈 수 있는 것 같기도 하다. 이 꾸준함으로 계속 배우며 성장했으면 좋겠다.

---

소스코드 링크

GitHub - Dongwoongkim/Billim-SharingPlatform: 중고 제품 대여 서비스 플랫폼 제작 Spring/React

아직은 지저분한 코드가 조금씩 남아있어 추후에 최종배포까지 완료되면 코드리뷰를 하며, 진행과정해온 과정들을 세부적으로 기록해볼 예정이다.