[일일 회고] 22.04.18 - "협업하기, 상황에 맞는 아키텍처와 FE/BE 배포, DB 모델링"

📚 배운 것

쇼핑몰 웹 협업 프로젝트 시작 with FE & BE

이번에는 프론트엔드와 백엔드, 총 4명이 모여 반찬가게 쇼핑몰 웹 애플리케이션 프로젝트를 시작했다.

어색한 분위기를 탈피하고자 웃고 떠들고 힘이 나는 말을 의도적으로 했다. 협업을 위해 그라운드 룰을 정했다. 이젠 함께 룰 정하는 것이 익숙해졌다. 저번 프로젝트에서 클라이언트 개발자가 View 개발에 부담을 느낀다고 했다. View 개발 집중을 도와주기 위해 공통 업무를 백엔드에서 주로 맡았었다. 이번 클라이언트 개발자는 여유가 있어 보였다. 이번엔 모두가 즐겁고 의견을 말할 수 있는 분위기를 만들 수 있겠다는 생각이 들었다. 혼자 하면 10분이면 할 수 있는 일을 굳이(?) 작은 일로 나누었다. 프로젝트에 함께 한다는 유대관계를 쌓는게 가장 중요하다고 생각했다. 또한 팀원이 의견을 낼 수 있게 기다리려 했다. (많이 기다렸는지는 모르겠지만 ..ㅎ) 팀은 혼자 하는 것이 함께 해내는 것임을 잊지 말아야겠다. Github 저장소 : Side Dish Project Repo , Ground Rule 

---

상황에 맞는(?) 간단한 아키텍처와 FE/BE 배포

배포하는 데 프로젝트 제약사항이 있었고 다음과 같이 결정했다.

 

서버 비용 0원

서버 비용 없이 배포해야 한다. 짧은 시간 운영한다. -> AWS 프리티어 ec2를 활용하자 (구두쇠로 한 대만 사용...? 쿨럭)

 

프론트(React), 백엔드 모두 백엔드가 배포한다. CI/CD 등 배포 툴 사용하지 말 것

소스코드가 한 저장소에 FE / BE 디렉토리로 구분되어 있다.

-> 자동화 배포 스크립트를 만들어야겠다.

-> 디렉토리 별로 빌드한 뒤, scp를 활용해 aws로 전송해야겠다. 왜? 프리티어는 컴퓨팅 파워가 부족해서 mysql 돌리고 있는 상태에서 spring 빌드도 안 되는 문제 발생한다.

-> gradle으로 spring 빌드 스크립트 작성

-> 프론트 배포는 어떻게 하지?  -> React Build(npm run build)를 하여 정적 파일로 만든 다음 배포하면 된다.

-> 문제는 ec2 보낸 빌드 파일을 실행할 스크립트가 별도로 필요하다...

 

프론트 코드는 스프링 static에서 정적 전송하지 말 것

-> Nginx로 서버를 만들고 build 한 react 프로젝트를 전송하자.

-> 이때 백엔드 서버와 프론트 서버 간의 CORS 문제가 발생하니 백엔드에서 CORS 설정이 필요하다. (나봄의 cors, SOP를 모르고선...)

 

로그인 Oauth2.0(Github)을 위한 Spring security 사용하지 말 것

-> 직접 세션 하자

 

아주 간략한 아키텍처가 그려졌다. 프리티어 EC2 하나에 스프링, nginx, mysql 띄우는 게 말이 안 되지만...

---

데이터베이스 모델링과 ERD - 개인적인 생각 + 호눅스 마스터 클래스 

개인적 생각

예로부터(?) 견고한 백엔드 설계를 위해선 DB 모델링이 필요하다. (DataBase가 먼저인가 도메인이 먼저인가는 잠시 잊고(사실 잘 모르겠다))

데이터 분석을 하면서도 ERD를 파악하는 것은 매우 중요했다. 프로덕트의 전체 Data 구조를 파악해야 원하는 데이터를 찾고, 분석할 수 있기 때문이다. 백엔드 개발을 시작하면서도 마찬가지다. 진행 중인 프로젝트가 있다면 ERD 파악이 우선순위가 되어야 한다. ERD 파일이 된다는 것은 해당 도메인의 전체 흐름을 알 수 있다는 뜻이다. 비즈니스 로직을 이해한다면 개발하는데 어려움이 없을 것이다.

아예 새로운 개발을 시작해도 마찬가지이다. 

 

호눅스 마스터 클래스 

데이터 베이스 모델링 과정은 다음과 같다.

1. 요구사항 분석 -> 요구사항 분석서

2. 개념적 설계 -> ERD

3. 논리적 설계 - 관계형 모델

4. 물리적 설계 - SQL

 

3번을 기준으로 1,2번은 DBMS에 독립적이고 4번은 DBMS에 종속적인 작업이다.

 

1. 요구사항 분석

애플리케이션의 요구사항을 데이터 관점에서 바라보는 것이다. 사용자 / 앱이 DB에 요구하는 것은 무엇인지, 어떻게 저장할 것인가 이다.

 

2. 개념적 설계 : ERD

- 개체 (Entity) : 실제 현실에서 독립적으로 존재하는 어떤 것이다. 직사각형으로 표현된다.

- 속성 (Attribute) : 개체를 설명하는 특성이다. 타원으로 표현된다. 키 속성은 개체마다 고유한 값을 가지는 속성이다. 키 속성을 밑줄로 표현하면 하나 이상 존재 가능하다. (여기서 말하는 키 속성은 PK와는 조금 다르다.)

- 관계 (Relationship) : 개체가 개체를 연결하는 정보이다. 관계도 속성을 가질 수 있다. 1:1, 1:N, N:M의 세 가지 관계가 존재한다. 반드시 필요한 관계는 겹줄로 표현한다.

- 약개체와 식별 관계 : 키가 없는 개체를 약객체(weak entity)라고 한다. 약개체와 부모 객체와의 관계를 식별 관계(identifying relationship)이라고 한다.

 

출처 : ERD of a company database — From Fundamentals of Database Systems by Ramez Elmasri, Lecture Slides

---

👍 Keep

• 팀원과 일 나누기
• 긍정적인 말하기 e.g. 오~ 말씀하신 브랜치 전략이 아주 힙한데요?

🔥Problem

• 안쉬고 계속 자리에 앉아있음 (허리가 너무 아프다)

🚒 Try

• 적어도 한 시간 마다 자리에 일어나 스트레칭 필수