[BE-기술] 채식쇼핑몰 '채식이들' 프로젝트 백엔드 개발 설계 후기

안녕하세요 NOT-ERROR-064팀의 백엔드 개발자 황윤준입니다.

코드스테이츠 개발 프로젝트도 어느덧 3주차.... 막바지로 달려가고 있습니다. 이전에 IT서비스를 기획하는 과정을 포스팅한 바가 있습니다.

2022.09.27 - [[ Team ] 기획] - [기획] 맞춤형 채식 쇼핑몰 프로젝트 IT서비스 기획 과정 정리

[기획] 맞춤형 채식 쇼핑몰 프로젝트 IT서비스 기획 과정 정리

 

위 과정에서 우리에게 필요한 기능들이 대부분 도출되었습니다. 이제는 서비스를 실제로 구현하는 엔지니어들인 개발자의 차례입니다. 

개발자들이라고해서 기획자가 넘겨준 화면설계서나 요구사항정의서만 보고 바로 코딩을 하지는 않습니다. 개발에도 '설계'가 필요합니다. 실제로 소프트웨어 엔지니어링에서 가장 중요하고 많은 시간을 들이는 과정이 바로 이 설계 과정이라고 합니다.

저희는 첫 발을 뗀 개발자로서 '코딩할 땐 코딩에만 집중할 수 있도록 설계를 잘해보자!'라는 마인드로 개발 명세서와 설계 스터디를 하게되었습니다.

백엔드 개발 설계 과정 

Pre-Requisite: 백엔드와 서버의 개념

백엔드는 '서버(Server)'를 다루는 사람들입니다. 여기서 서버는 이렇게 정의해 볼 수 있습니다.

'무언가'를 '어디론가' 제공(Serve)해주는 '장치'

1. 무언가: Data(데이터), View(화면)...

2. 어디론가: Client(클라이언트), Other Server(또 다른 서버)

3. 장치: Computer(컴퓨터)

 

즉, 데이터나 화면 등을 클라이언트나 다른 서버(컴퓨터)로 전달해주는 컴퓨터입니다. 서버는 결국 무언가를 전달하기 위한 컴퓨터인 것이죠. 더 쉽게 얘기하면,

다른 컴퓨터(클라이언트, 서버)로 각종 데이터를 제공하는 컴퓨터

 

입니다. 여기서 클라이언트나 서버나 모두 컴퓨터인 것은 같습니다. 백엔드가 다루는 서버는 '백엔드 서버(Back-end Server)'로서 사용자와 직접 만나지 않는 컴퓨터입니다. 사용자에게 보이지 않는 뒤 쪽에 있다고 하여 Backend라는 말이 붙었습니다.  (마치 사무실을 Back Office라고 부르는 것 처럼!) 반대로 사용자가 직접 조작하는 컴퓨터는 프론트엔드 서버(Front-end Server)라고 하죠. 사용자 앞에 있으니까요.

이는 웹 개발의 가장 기본적인 아키텍처 구조인 2-tier, 3-tier 아키텍처와 밀접한 연관이 있는데 이는 아래의 글을 참고하시면 좋을 듯합니다. 

https://yunjuniverse.tistory.com/18

프론트엔드와 백엔드가 나눠진 이유?

 

백엔드 서버는 사용자가 직접 조작하는 컴퓨터인 '프론트엔드 서버'에서 요청하는 각종 정보를 동적(actively)으로 제공하고, 민감한 데이터에 대한 보안을 담당하며, 데이터베이스를 다루는 컴퓨터 입니다. 이를 보면 백엔드의 3가지 키워드는 동적인 활성화(Activation), 보안(Security), 데이터베이스(Database)가 될 수 있겠네요.

따라서 우리는 데이터 보안과 데이터 관리, 특정 요청에 대한 응답을 관리하는 컴퓨터를 설계해야합니다. 이 컴퓨터를 어떻게 세팅하느냐가 바로 백엔드 개발 설계라고 할 수 있습니다. 

그렇다면 다양한 스펙트럼의 채식주의자를 위한 맞춤형 쇼핑몰 '채식이들'의 백엔드 개발 설계는 어떻게 진행했는지 살펴보겠습니다.

💡 참고!
앞으로 나올 설계 순서는 절대적인 것이 아님을 밝힙니다. 백엔드 서버 설계를 위해 필요한 내용을 어느정도 흐름에 맞게 설명해보겠습니다. 

 

'채식이들' 쇼핑몰 백엔드 서버 설계 순서

---

0. 개발 명세서(이미지)

1. 클라우드 서버 서비스 선정 및 세팅

2. 사용 언어, IDE, 프레임워크 선정 및 개발 기본 규칙 설정 

3. 협업 프로그래밍 툴 선정 및 전략 설정 (GitFlow 전략)

4. 패키지 구조 제작, ERD, 클래스 다이어그램 등 제작

5. 기본 API 명세서 제작

6. 배포 설계

---

 

0. 채식이들 개발 명세서(이미지)

백엔드 서버 구성

1. 클라우드 컴퓨팅 서비스

    1) 클라우드 서비스: AWS EC2

    2) 서버OS: 우분투 18 (Linux)

    3) 서버 성능: t2.micro(1CPU, 1Gbit Memory) 

2. 서버 프로그래밍

    1) 사용 언어: JAVA(OpenJDK 11)

    2) 개발 프레임워크: Spring Boot

    3) 개발 프레임워크 설정

1. Spring Boot(스프링부트)
   1. 버전: 2.7.3.
   2. 빌드 툴(Build Tool): Gradle
   3. 패키징 종류: Jar
   4. 의존성
      1. DEVELOPER TOOLS
         1. Spring Boot DevTools
            1. Property Default: 코드 변경시 자동으로 어플리케이션 재시작 기능 제공
            2. Live Reload: 브라우저 자동 업데이트 기능 제공
         2. Lombok
            1. VO, DTO, Entity 관련 작업에 편리한 기능 제공 (getter, setter 등)
      2. WEB
         1. Spring Boot Starter Web
            1. Spring MVC, Restful 기능 포함
            2. 웹 어플리케이션 서버로 톰캣 사용
         2. Spring Web
            1. 웹어플리케이션 개발환경 제공(Multipart File 업로드, IOC 컨테이너 초기화 등)
      3. Security
         1. Spring Security
            1. 보안(인증, 권한, 인가) 기능 제공
            2. 일반 로그인 세션 방식 보안에 사용
         2. OAuth2 Client
            1. 소셜로그인 인증 권한 처리 기능 제공
      4. SQL
         1. Spring Data JPA
            1. CRUD 기능 처리를 위한 공통 인터페이스 제공
            2. 쿼리 메서드 기능 제공, 메서드 이름만으로 쿼리 자동 생성
            3. 데이터 접근 계층 개발 용이
         2. Map Struct
            1. Entity와 DTO 변환 작업
         3. Spring REST Docs
            1. API 문서 자동화

1. IDE
   1. IntelliJ(인텔리제이)
      1. 자바를 다루는 가장 강력한 IDE로 community 버전 사용
2. 서버
   1. AWS EC2
3. 스토리지
   1. AWS S3
4. 데이터베이스(DB)
   1. MySQL(AMAZON RDS for MySQL)
      1. AWS RDS를 이용해 클라우드 환경에서 데이터베이스 작업 관리
      2. DBMS는 MySQL 사용
5. 배포 툴(CI/CD)
   1. AWS CODE DEPLOY
   2. AWS PIPE LINE
6. 관리 툴
   1. GitHub, Git
      1. 브랜치 전략: 깃 플로우(Git Flow) 방식 채용
7. 협업 관리툴
   1. JIRA
   2. CONFLUENCE

 

1. 클라우드 서버 서비스 선정 및 세팅: AWS EC2(Linux), S3, RDS 

요즘은 서버를 구축하기 위한 컴퓨터를 새롭게 사기보다는 사용량에 따라 비용을 지불하는 클라우드 컴퓨팅 서비스를 이용합니다. 실물 서버가 아닌 웹서비스를 다루는 것이죠. 저희는 AWS, Heroku, Azure 등 수많은 클라우드 컴퓨팅 서비스 중 AWS를 사용하기로 했습니다. 이유는

1) 아는게 이거 밖에 없고....

2) AWS EC2의 무료 서비스를 이용하며

3) 배포 관련 서비스, RDS, S3서비스 연계 하기 위해

위 3가지 이유였습니다. 일단 한국의 호스팅 서비스와는 다르게 후불제로 사용할 수 있기도 하고, 일정 사용량 이하면 무료로 서버를 구축할 수 있다는 장점이 있죠.

저희는 서버의 운영체제는 리눅스(우분투18) 버전, 성능버전은 프리티어 서비스가 가능한 t2.micro를 이용했습니다. 어차피 실제 사용할 서비스가 아니기에 이 정도로도 충분하기 때문이었습니다. 이제 저희는 서버를 AWS 서비스 위에서 다루게 되며 세션 매니저나 ssh 클라이언트로 해당 서버에 접속하여 서버를 조작합니다.

AWS 세션 매니저의 모습입니다. 일반 우분투 터미널과 같습니다

 

2. 사용 언어, IDE, 프레임워크 선정 및 개발 기본 규칙 설정 : JAVA11 기반, IntelliJ IDE, Spring boot 프레임워크, 의존성 및 라이브러리 설정

장치(컴퓨터)가 마련되었다면, 우리 서버가 어떻게 보안을 설정할지, 어떻게 다른 컴퓨터와 통신을 할지 등의 규칙을 정하는 '프로그래밍'이 필요합니다. 그럼 프로그래밍을 하기 위한 언어와 프로그래밍을 쉽게 할 수 있도록 도와주는 프레임워크가 필요하겠죠? 저희는 자바(언어)와 스프링부트(프레임워크)를 이용했습니다.

저희는 코드스테이츠 백엔드 과정 중 자바와 스프링 부트를 기반으로 한 서버 구조 설계를 학습했습니다. 자바 스프링 기술은 대한민국 전자정부프레임워크의 기반이 되는 터라, 현재도 수 많은 기업에서 사용하고 있는 기술입니다. 대표적으로 우아한 형제들의 배달의 민족 서비스가 자바 스프링 기반이죠. 스프링부트(특히 스프링 MVC)는 자바로 웹 개발을을 쉽게 할 수 있도록 도와주는 프레임워크입니다. 자바와 스프링부트에 대한 설명은 다음을 참고하시면 되겠습니다.

https://yunjuniverse.tistory.com/21

자바(JAVA)란 무엇인가? What is JAVA?

https://yunjuniverse.tistory.com/40

자바 스프링 프레임워크(Spring Framework)란 무엇인가? POJO, DI, AOP, PSA

 

실제 프로그래밍에서는 스프링부트가 매우 중요한데요, 스프링부트 기반 프로젝트 생성시 자바의 버전, 빌드 배포 관리 도구, 의존 라이브러리 설정 등을 미리 할 수 있습니다.

그리고 코드를 작성할 통합개발환경은 IntelliJ 커뮤니티 버전을 사용했습니다. 원래 자바는 Eclipse라는 기본 IDE가 대세였으나 이후 IntelliJ가 코드 예측이나 디자인, 유용한 기능을 빠르게 탑재하면서 자바 개발자의 IDE는 IntelliJ가 되었습니다. 저희는 최대한 현업에서 많이 쓰이는 형태로 만들어보고자 IntelliJ를 선택했습니다.

 

3. 협업 프로그래밍 툴 선정 및 전략 설정: Git, GitHub 사용 및 GitFlow 전략 채용, JIRA 브랜치 전략 활용

개발 프로젝트는 프론트엔드, 백엔드 등 여러 사람이 함께 하는 작업이기에 협업에 대한 전략도 필요합니다. 저희는 깃(Git)과 깃허브(GitHub)를 이용해 코드 버전 관리를 진행했습니다. 깃과 깃허브에 대한 설명은 다음을 참고해주세요

https://yunjuniverse.tistory.com/42

Git과 Github란 무엇인가? What are git and Github? feat.버전관리시스템(VCS)

 

GitFlow 전략 

저희는 Git 브랜치 전략으로 Git flow를 택했습니다. 개발자 각각의 작업 단위를 브랜치라고 하는 데, 원활한 브랜치 병합을 위한 전략이 바로 브랜치 전략입니다. Git flow 전략은 main, dev, feature, hotfix로 브랜치의 역할을 나누고 규칙에 따라 브랜치를 생성해 작업을 진행합니다. 

 

 

그리고 위와 같은 구조로 실제 완성된 제품의 코드가 담기는 main브랜치에서 프론트엔드와 백엔드의 개발 중 코드를 담는 dev 브랜치를 만들어주고 각 개발자에게 기능구현(feature), 버그수정(hotfix)에 맞춰 세부 브랜치를 지정해주는 방식입니다. 각 기능이 구현이 되면 dev브랜치로 병합을 해 테스트하고 오류 테스트 이후 실제 제품 코드가 있는 main브랜치로 최종 병합을 해주는 구조입니다.

여기에 더해 깃을 커밋할 때 git template을 설정해 통일성 있는 커밋 메시지를 남길 수 있도록 했습니다.

git template 이미지

 

JIRA 브랜치 전략

마지막으로 브랜치 할당은 저희가 선정한 협업툴인 지라를 이용해 자동 할당하였습니다. 

 

위 이미지가 저희가 쓰고 있는 협업툴 지라(Jira)의 화면 이미지입니다. 지라의 큰 장점 중 하나는 할당하는 작업에 따른 브랜치 자동생성이 가능하다는 것입니다. 바로 지라에서 제공하는 Automation 기능을 활용하는 것이죠. 

\

이 자동화 규칙을 통해 팀원들의 브랜치를 자동으로 만들고 할당해줍니다. (역시 개발자들이 가장 좋아하는 것은 자동화!)

위와 같은 형태로 브랜치명이 만들어집니다.

 

덧붙여서 지라와 연계하여 문서 관리를 하고자 컨플루언스(Confluence)를 사용하였습니다. 팀원들이 편하게 쓰고 있는 노션과의 연계성도 좋고 지라의 작업에 연결하기가 쉬웠기 때문입니다.

팀장님이 고생한 흔적......

 

 

4. 패키지 구조 제작, ERD 제작: Domain 기반 패키지 구조 적용 및 ERD 제작

협업구조, 브랜치 전략, IDE, 프레임워크, 라이브러리 등을 설정했다면 이제 실제 서버 개발 구조를 그려야합니다. 가장 먼저 데이터의 관계를 그려주기 위해 ERD(Entity Relationship Diagram, 테이블 관계도)를 그려봅니다. 이 과정에서 실제 필요한 데이터가 무엇인지, 각 관계를 어떻게 이어줄 것인지 정리 가능합니다.

 ERD 제작

위 다이어그램에서 나온 테이블이 곧 스프링에서 Entity 역할을 합니다. 저희는 이 Enitity 도메인(Domain)을 기반으로 개발 패키지 구조를 그려보았습니다. 저희는 해당 Domain을 기준으로 패키지를 나누는 구조를 택해 진행하였습니다.

Domain 기반 패키지 구조

 

위 이미지에서 보면 domain, entity, global, infra라는 4가지 패키지가 상위 패키지로 나뉘어져 있습니다. domain으로 각 엔티티에 필요한 repository, service, dto, controller 등이 존재하죠. 저희는 특별히 entity는 따로 빼주었습니다. 그리고 global 패키지 안에 각 도메인에서 필요한 공통 기능을 담아 놓았습니다. 관점지향프로그래밍을 지원하는 패키지입니다. 마지막으로 infra는 특히 시큐리티 기능 등을 담아 놓은 공간입니다.

 

5. API 명세서 제작: Spring API Restdocs 활용

백엔드 개발자에게 가장 중요한 부분이 바로 프론트엔드 개발자에게 개발 API 명세서를 전달하는 것입니다. 개인적으로는 개발 전에 간단하게 문서를 정리해서 넘겨주는 것이 좋지만, 어느정도 개발에 대한 구성이 완료된 후에 해당 구성을 자동으로 만들어주는 Spring API Restdocs를 사용했습니다. 

 

스프링 restdocs는 테스트 코드 제작 시 해당 테스트 코드를 기반으로 문서를 snippet 형식으로 생성해줍니다. 사용에 러닝커브가 있긴하지만 테스트 코드에 익숙하고 빠른 개발 능력을 가지고 있다면 가장 적합한 방식이 아닐까 생각합니다.

 

6. 배포 설계: AWS PIPELINE

저희팀은 어플리케이션 자동 배포, 즉 CI/CD를 구현하기 위해 AWS Pipeline을 적극적으로 활용했습니다. 저희가 서버로 사용하고 있는 AWS EC2와 데이터베이스 서비스인 AWS RDS와 함께 사용하기에 편한 점이 있었기 때문이죠. AWS 파이프라인에 대한 설명은 다른 팀원 분께서 올리신 포스팅을 참고해주세요

2022.09.20 - [[ BE ] 기술] - [BE-기술] AWS Pipeline을 통한 자동 배포 방법