백엔드 개발 포트폴리오 | 개발자 커뮤니티

내일배움캠프 4기 웹 개발 과정 Spring 트랙 수료생 최종 프로젝트 ‘디벨로니티’을 소개합니다.

Aug 17, 2023

Contents

프로젝트 개요 서비스 아키텍쳐 MVP 시연 기술적 의사결정 트러블 슈팅 & 성능개선 추후 개발 및 기술적인 도전 계획 취업 준비, 어디서부터 시작해야 할지 모르겠다면?

Developer's community - Develonity

http://develonity.shop/

코드 컨벤션 & RESTful API

RESTful API 참고 Ref - https://sanghaklee.tistory.com/57

프로젝트 개요

주제 및 선정 배경

Developer + Community = Develonity

입문 & 주니어 & 시니어 개발자 모두에게 가치 있는 커뮤니티를 만들고자 했습니다.

Q&A 게시판 활동(답변)을 통해 Gift Point 를 쌓고, 포인트로 Gift Card 를 살 수 있습니다.

[미구현] Q&A 게시판 활동(답변)을 통해 단순히 Gift Point 뿐만 아니라 Respect Point 가 쌓이게 되고, Respect Point 를 기반으로 외주, 과외 등의 서비스 를 제공하고자 했습니다.

프로젝트 팀 구성 및 역할

리더

조성현 [개인 깃허브]

User(Account) & Spring Security - redis & JWT 기반의 Token 인증 및 Admin과 User의 Filter&Authentication 로직 구분

전반적인 프론트 제작 및 연동(Gift Card & Order쪽 프론트 제외)

프론트(S3 + CloudFront), 백엔드(EC2), RDS(Mysql) 배포

Github Actions 기반 CI 적용

Sub Module & profile 기반 배포, 테스트 환경 분리

부리더

이 솔 [개인 깃허브]

기프트카드 관련 백&프론트 로직 구현

기프트 카드 등록, 조회, 수정, 삭제

주문 관련 백&프론트 로직 구현

주문하기, 주문조회

메인페이지 제작(프론트엔드)

팀원

김태웅 [개인 깃허브]

게시글 관련 백엔드 로직 구현

게시글 CRUD 기능
좋아요 기능
스크랩 기능
답변 채택, 포인트 및 등업 관련 기능

QueryDSL을 활용한 조회 및 검색, 정렬 기능 구현

AWS S3를 활용한 이미지 업로드 기능 구현

배지호 [개인 깃허브]

댓글 관련 백엔드 로직 구현

댓글 CRUD 기능
좋아요 기능
대댓글 기능

송성원 [개인 깃허브]

어드민 관련 백엔드 로직 구현

유저 전체 조회
유저 ROLE에 따른 조회
유저 개인 조회

주차별 프로젝트 타임라인

JIRA를 활용한 프로젝트 업무관리

API 문서(Postman Publish Documentation)

https://documenter.getpostman.com/view/24836890/2s93JqRjo6#284b7458-f36f-4878-a3ce-378b21d70cbe

서비스 아키텍쳐

MVP 시연

→ 이미 세팅이 되어있는 상태로 간략하게 슥슥 (2분언더)

[로그아웃 → 로그인 → QnA 슥 돌고 → 상세 조회(채택할 댓글 세팅 된)에서 댓글&대댓글&좋아요&채택 풀코스 → 기프트카드 조회 & 구매 → 기프트카드 구매내역 → 회원탈퇴 → 로그인실패 ]

++++ 기프트카드 등록, 수정 페이지도 보여주기

프론트 미구현으로 빛을 보지 못한 서비스들…

게시물 스크랩 등록/취소/조회

검색 기능

등업 기능

내가 쓴 게시글 , 댓글 조회 등 활동 조회

인기글(당일 작성된 좋아요 순 게시글 3개)

커뮤니티 게시판

어드민

기술적 의사결정

Session vs Token(JWT)

보안 vs 효율&확장성

서비스의 특성상(커뮤니티) 보안적으로 매우 민감한 주제는 아니라고 판단하여

HTTP의 비상태성(Stateless)를 그대로 활용할 수 있고, 따라서 높은 확장성을 가질 수 있는 Token방식을 채택하였다.

그럼에도 보안을 챙기긴 해야한다.

refresh token을 도입하여 access token의 유효기간을 짧게 가져가고,

RTR(refresh token rotation)을 도입하여 refresh token 탈취 시 문제점도 어느정도 보완,

계정정보 or 회원탈퇴 등 중요한 기능들은 ‘비밀번호 검증＇을 1회 더 하는 방식으로 보안을 조금 더 강화하였음.

++ access token과 refresh token이 모두 탈취 당했을 경우에 대한 고민

네이버 토큰 갱신방법[grant_type, client id를 같이 보내는 방식]

카카오 토큰 갱신방법[네이버와 유사]

현재 프로젝트에서 대응 가능한 방법들

RTR(refresh token rotation)을 적용하고 access token의 유효시간을 30분으로 짧게 설정해두어, 사용자가 서비스를 이용중이라면 [reissue 실패 → 재로그인 → 탈취된 refresh token 무효화]가 가능하다.

지속적으로 탈취되는 상황이라면 해당 회원을 일단 탈퇴처리 하여 해커의 나쁜 행동을 막고 개인적으로 네트워크와 컴퓨터를 리셋(포맷)한 이후에 다시 탈퇴 취소 하는 방법이 있긴하다. (회원 탈퇴는 soft delete 방식으로 구현되어 가능하다.)

특정 상황이 발생하여 회원 다수의 token이 탈취된 경우라면 30분여 서비스 점검 실시(access token 유효기간 만료를 위함) 및 redis(refresh token 저장소)를 재가동 하는 방법도 고려할 수 있을 것 같다. (서비스 점검기간동안 보안적인 대처도 병행)

현재 계정정보 접근, 회원탈퇴 등 민감한 서비스들에는 패스워드 재검증 로직을 포함하고 있으므로 개인정보 유출, 금전적 피해 가 발생 가능한 경우는 예방하고 있다.

Redis - Token 저장소로 Redis를 선정한 이유

~~Key(LoginId)-Value(Refresh Token) 외의 다른 필드가 필요하지 않다.~~

I/O가 빈번하게 발생하는 환경

저장된 데이터의 개수와 무관하게 O(1) 의 수행시간을 가진다.

저장된 모든 token을 조회하는 등의 싱글 스레드의 단점이 부각 될 상황이 없다.

Admin과 User 분리

기존 방식

동일한 User Entity에서 Role Enum 으로 Admin과 User를 구분하였음

동일한 security filter와 Authentication Service를 사용하였음.

문제점

근본적으로 User와 Admin의 생명주기가 다르고,

User의 다양한 field들은 Admin에게 불필요함.

User와 Admin의 인증과정을 분리할 수 없음.

해결

Entity 및 Package 분리

security filter와 Authentication Service 분리

Authentication Service에 팩토리 패턴 적용하여 OCP 원칙을 지키고자 노력

게시글 JPA 상속 관계 매핑

JPA는 테이터베이스와 객체를 매핑해주는 자바 진영의 ORM 기술 표준이지만 객체의 상속 관계와 정확하게 일치하는 데이터베이스 모델링은 존재하지 않는다.

따라서 차선책으로 상속 관계와 비교적 유사한 슈퍼타입-서브타입 모델링 기법으로 데이터베이스를 상속 객체에 매핑 해야 한다.

슈퍼타입-서브타입 논리모델을 실제 데이터베이스 물리모델로 구현하는 방법으로 3가지 전략이 있는데 그 중 단일 테이블 전략을 사용했다.

단일 테이블 전략의 장점은 아래와 같다.

조인이 필요 없으므로 조회 성능이 빠르다.

조회 쿼리가 단순하다.

단일 테이블의 단점은 아래와 같다.

하위 엔티티의 필드값은 모두 Null을 허용한다.

하나의 테이블에 칼럼이 많아져 복잡하다.

단점이 있음에도 단일 테이블 전략을 선택한 이유는 아래와 같다.

지금 진행 중인 프로젝트는 게시글의 필드값을 최대한 적게 가져가는 방식을 사용하고 있어서 테이블 칼럼 수가 적고 가볍기 때문에 단일 테이블 전략을 사용하더라도 복잡해지지 않는다.

비록 데이터베이스에는 Null값을 허용하더라도 실제 객체가 Null값을 가지고 있는 것은 아니다.

만약 단일 테이블 전략이 아니라 각자 테이블을 가지는 조인 전략과 같은 방식을 사용했다면 Null값은 들어가지 않지만 조회 쿼리가 복잡해지고 INSERT QUERY를 2번 실행해야 하기 때문에

단일 테이블 전략을 사용하기로 결정했다.

id를 활용한 간접참조 방식 설계

직접 참조 : Entity 클래스를 설계할 때 @OneToOne, @OneToMany ... 와 같은 어노테이션을 써서 Entity 간에 연관 매핑하는 것

간접 참조 : 객체를 직접 참조하지 않고, 식별값을 이용하는 것

직접 참조 방식의 단점

의존 관계 형성
편한 탐색 오용 방지

직접 참조를 한다면 연관 관계 맺은 객체를 편하게 탐색할 수 있고 바뀌길 원하지 않는 참조 객체의 값이 손쉽게 바뀔 가능성이 있다. 직접 참조는 편한만큼 위험한 것이다.
예를 들어 Board Entity안에 user라는 변수가 있다면 Board를 다룰 때 User를 변경할 수 있는 가능성과 여러 실수의 가능성이 존재하게 됨
즉 User 라는 Entity 자체를 날것으로 가져오게 되면, Entity 가 오염이 될 수 도 있음, setter 를 통해서든, 도메인 서비스를 통해서든 어떤 일이 벌어질 수 있는 가능성을 열어둔 것