[팀 프로젝트] 동네 백엔드 대면 회의 - 1차 (erd 설계)

오늘은 날씨가 화창하고 구름이 잔잔하게 껴있는 날이었다.

 

대면 회의가 중앙대학교에서 하기로 약속하여 8시 30분에 일어나서

씻고, 9시 30분에 기숙사를 나와

셔틀타고 한대 앞에서 4호선을 타고 동작역으로 갔다.

동작역에서 9호선으로 갈아타서 중앙대학교에 도착했다.

화창한 12시 중앙대학교

도착하자마자 발 길이 간 곳은 바로..

중앙대학교를 상징하는 로고와, 중앙대학교 글자가 있는 곳에서 중앙대학교 사진을 찍었다.

중앙대학교 건물 너무 이쁜 걸.. 

 

시간이 조금 남아서 중앙대학교 탐방을 했다.

너무 더워서 그늘진 곳으로 발걸음이 간 건 비밀..ㅋㅋ

 

카톡으로 같이 동네 프로젝트를 진행하는 백엔드 개발자 한 분이 연락이 닿아

중앙대학교 정문으로 왔다고 하셨다.

 

정문에서 백엔드 개발자 한 분과 냉면 집에서 다른 백엔드 개발자 한 분을 만났다.

아침, 점심을 안먹고 와서 다같이 점심으로 냉면을 먹고

중앙대학교 소프트웨어학부 PC실로 갔다.

PC실은 2시간 예약제로 운영해서 백엔드 두 분이 예약해 총 4시간을 예약했다.

 

어쨋든 우리는 PC실에 도착하고 노트북을 꺼낸 후 본격적인 회의를 시작했다.

 

우리의 오늘 회의 목표는 DB erd 설계, API 구성이었다.

그래서 erd를 최대한 빨리 설계해보고 API를 구성해보기로 나름 목표를 세우고 기세등등하게

회의를 시작했다.

---

Github organization 설정   - 그룹 개발

우선 백엔드_빙글님께서 AWS RDS와 개발템플릿을 미리 구성해두고 Github repositorie에 업로드 해주셨다.

미리 개발 툴을 구성해주셔서 감사했고, 덕분에 개발 환경 셋팅을 손쉽게 할 수 있었다.

 

나의 첫 번째 github Organizations

빙글님께서 개발 템플릿을 repositories에 업로드 해두고 organizations를 만들고,

나를 초대해 Github에 빙글님이 만든 개발 템플릿을 다운 받게 해주었다.

 

여기서 나는 초대 받은 organizations에서 git clone을 하려고 했다.

원래는 파일 따로 다운받아서 하려고 했음..ㅋㅋㅋ - 난 깃린이~

 

그러자 빙글님께서 organizations 의 repositories를 git clone 하면 안되고,

이걸 fork해서 나의 개별 repositories를 생성 후 이것을 git clone해야 된다고 알려주셨다.

깃린이인 나는 첨엔 이렇게 하는 이유를 몰랐다..

 

그치만 빙글님은 친절하게 github를 이렇게 사용하는 이유는
메인 코드 파일들이 organizations의 repositories에 속해있는데,
그걸 git clone해서 사용하면
다운 받을 때는 문제가 안된다.

하지만, git push를 하면 내가 개별적으로 작업한 게 공유하고 있는 저장소의
메인 코드 파일들을 대체해버려 다른 사람(빙글,오리) 분들이
organizations 의 repositories를 이용할 때 갑자기 바꿔진 메인 코드 파일들을 보고
혼란을 겪을 수가 있기 때문이다.

 

위 내용을 요약하면 다음과 같다.

 

 

친절한 설명 덕분에 이해 후 fork를 하고 로컬환경에서 git clone을 진행했다.

여기서 로컬환경이란, 서버 API를 만드는 로컬 디렉토리이다.  - 로컬환경에서 서버 API를 만들고 github에 push 함.

 

나는 로컬환경을 Desktop에 UMC_doneNe 디렉토리를 생성 후 여기다가 git clone을 했다.

 

 

 

organizations의 repositories에 fork를 해서 내 repositories에 복사하자.

(umc-dongne) organization의 (dongne-server) repositories를 fork

 

 

 

fork 버튼을 눌러 내 repositories에 fork를 진행했다.

그럼, 내 repositories에 fork가 완료된 걸 확인할 수 있다.

 

 

 

그리고 다음, 서버 API를 저장해둘 디렉토리를 (로컬환경에서) 생성하고

그 디렉토리에 git clone을 해서

서버 API를 저장한다.

git clone을 해서 로컬 디렉토리에 로컬 저장소를 생성함.

나의 github의 repositories 주소를 git clone 옵션인자에 입력해 가져오는 것임

 

~/Desktop/UMC_dongne에서 git clone을 수행

 

 

 

 

결과적으로 git clone을 해서

github repositories에 저장된 파일들을 로컬환경에 불러왔다 !

git clone해서 파일들을 불러옴.

 

 

 

 

그럼, 지금까지 동네 서버 API 개발 환경 셋팅을 완료한 것이다.

추가적으로, .env 파일은 따로 생성해줘야 한다.

.env 파일은 .gitignore 에 속하기 때문이다.

그리고, .env 파일 내용은 RDS 정보와 비밀번호가 기록되어 있는 파일이기 때문이다. - 민감한 정보들

# .env 파일
DB_HOST="binglebingle.ckifj4noknvx.ap-northeast-2.rds.amazonaws.com"
DB_USER=root
DB_PASS=12345678
DB_PORT="3306"
DB_DATABASE_TEST = "testSchema"
# RDS에 연결하기 위해 필요한 파일

 

.gitignore 파일이 먼데?

.gitignore 파일은 git push를 사용할 때 지정된 github repositories에 올라가지 않게 하는 파일 리스트들을 기록 해둔 파일이다.

그래서, .gitignore 파일에는 RDS 정보, 비밀번호 나 log와 같은 github에 올리면 민감한 파일들을 저장해두어

보안과 효율성을 증대시킨다.

RDS 정보와 비밀번호를 기록해두면, 다른 github 사용자가 내 repositories에 들어와 무단으로 RDS를 사용할 수 있는

사태가 발생할 수 있다..    - 빙글님 말씀으로는 github내에서 민감한 정보를 업로드하면 메일로 알림을 보내줬다고 함.. 대박이다 ㅋㅋ..

 

 

 

개발 템플릿 요약 정리

빙글님께서 구성해주신 개발 템플릿에 대해 살펴보면,

winston.js 파일은 로그 기록용 모듈이다.

express.js 파일은 서버 API 도메인 설정시켜주는 파일이다. - Route.js와 다른 점은 무엇일까?

init.js 파일은 로그를 잡아주는 파일이다. - 실행로그, 종료로그, DB 연결로그, DB 연결해제 로그

 

 

 

 

---

ERD 설계 - 잊지 못할 좋은 경험

우선 ERD를 설계하기 앞서 기능명세서와 와이어프레임을 보고

어떤 API가 필요한 지를 대략적으로 살펴보았다.

솔직히,.,.. 와이어프레임이 너무 구체화가 안되어있어서 고생좀 했다..ㅋㅋ

 

그래서 백엔드 3명이 모였기에, 구체화가 안된? 와이어프레임을 가지고

살을 붙이면서

회원가입 로직, 로그인 로직, 출결 그룹 관리 로직, 출결 수행 로직에 대해서 뜯어 고쳤다 ㅋㅋ..

 

와이어프레임 구체화 (erd 설계 준비)

회원가입 로직은

일반 회원이 웹사이트에 회원가입을 할 때 동네 웹 서비스에 대한 회원가입을 수행하고,

회원가입 된 회원으로 로그인하면 메인 페이지에 서버(동아리) 선택란이 있고,

초기 로그인 회원은 동아리를 추가할 수 있는 버튼이 있다.

동아리 식별 코드를 거기서 입력해 동아리를 가입한다.

그러면, 서버(동아리) 선택란에 가입한 동아리가 추가되고

클릭하면 동네 웹 서비스 페이지로 이동.

동네 일반회원 회원가입 & 로그인 로직은 메이플스토리 서버 선택란에서 영감받고  동네 웹 뷰로 아이디어 제공

 

로그인 로직은

일반회원 로그인, 단체 로그인으로 분리해서 별도로 로그인을 할 수 있는 페이지를 제작해야함.

-> 오리님의 의견이고, 이건 백엔드의 관리 측면에서 생각하고 비판적으로 바라본 후 제공한 의견이었다.

기획자가 제공한 틀에서만 사고하는 것이 아닌, 비판적인 사고로 프로젝트의 올바른 방향으로 나아갈 수 있도록 하는 모습이

본 받고 싶었다..ㅠ

 

출결 그룹 관리 로직은

출결 그룹의 카테고리인 팀/조를 지정해주는 것을 일반 회원가입에 추가하는 것이 아닌,

운영진 (단체)에서 모든 회원의 팀/조를 지정할 수 있게 출결 그룹을 관리하도록 만듦.

그리고, 2주차 스터디, 3주차 스터디로 출결 그룹을 분할하는 게 아니라

node.js 스터디, spring 스터디, web 스터디 처럼 카테고리로 나눠서 출결그룹을 할당한다.

 

출결 수행 로직은

출결 수행을 할 때 식별코드를 어떻게 제공할까에 대한 고민을 했다.

와이어프레임이 구체화가 덜되어서 이것에 대해 토의를 함.

일반 회원 사이드에서 출결을 누르면 출결 식별 코드를 입력할 수 있게 만들기로 함.

 

이렇게 와이어프레임을 보고 구체화에 대한 회의를 가진다음,

erd 설계하기를 시작했다.

 

erd 설계는 AqueryTool에서 한 달에 6000원을 유료결제 후 진행했다.

AqueryTool 무료 erd 설계는 5개 Table만 생성가능...ㅋㅋ

 

 

erd 설계 회의

erd 설계는 동네 웹서비스에서 핵심 기능 순으로 짜기 시작했다.

User -> Admin -> ClubMembers -> Group -> GroupMembers // -> GroupSchedule -> Attendance // -> Account -> ClubCategoty -> AccountCategory

 

핵심 기능 순으로 erd를 설계하니, 모든 기능들에 대한 관계를 포기안하고? 구성할 수 있었던 것 같다.

ERD 회의 과정에 대한 블로깅은 금요일에 작성하도록 하겠다. - 실천해야 비로소 내 것이 된다.

금요일에 ERD 회의 과정을 블로깅 하고있다 ㅋㅋ - 실천해야 내 것이 된다.

 

아래의 영상을 보면서 erd를 설계하는 방법에 대해 터득했다.

와이어프레임을 보면서 erd를 설계한다.

erd 설계 방법

 

동네 웹 서비스의 핵심 목적이

단체 회원을 위한 기능

일반 회원을 위한 기능이므로,

User 와 Admin Table를 우선적으로 설계 했다.

일반회원, 단체회원을 기반으로 웹 서비스 기능들이 구현되기 때문이다. - 관계형 데이터베이스의 특징이랄까?

 

 

핵심 기능

1. 회원 관리

2. 출결

3. 회계

핵심 기능을 중요 순서대로 정리하고 erd를 설계하기 시작했다. - 와이어프레임을 구체화하면서 생각함.

 

회원 관리

User Table 설계

User의 erd를 설계하기 위해

우선 일반 회원이 "동네" 웹에서 수행하는 동작들에 대해서 정리를 했다.

일반 회원의 동작

1. 회원가입 & 로그인

2. 동아리(단체) 가입

3. 동아리 내의 기능들 수행 (동아리 회원명단 보기, 출석 그룹 & 출결수행, 회계 목록 보기)

 

2, 3에 대해선 User Table에 설계하지 않고, 다대다 관계로 속해있기 때문..

1에 대해서만 User Table에 설계했다.

 

 

일반 회원이 회원가입할 때 아이디, 비밀번호, 회원 개별 정보들을 입력하기 때문에,

User Table에 일반 회원에 대한 정보를 저장하는 User Table을 구성했다. -일반 회원이 웹을 이용하는 로직?에 대해 생각.

User Table

User Table은 일반 회원 리스트를 담은 Table이라고 생각해도 좋다.

- 아마 다대다 관계, 일대다 관계를 구현하기 위해서 이렇게 구성한 듯 하다.

 

Admin Table 설계

admin Table도 User Table과 같은 방식으로

단체 (운영진) 회원이 "동네" 웹에서 수행하는 동작들에 대해서 정리를 했다.

단체 회원의 동작

1. 단체 회원가입 & 로그인

2. 동아리 내의 기능들 수행 (동아리 회원명단 관리, 출석그룹 생성 & 출결, 회계 관리)

 

2에 대해서 Admin Table에 설계하지 않고, 다대다 관계, 일대다 관계에 속한 기능이기에..

1에 대해서만 Admin Table에 설계했다.

 

단체에 대한 리스트를 저장해주는 Admin Table을 구성했다.

"동네" 웹에서 일반회원과 단체가 사용하는 기능들에 대해서 생각하니,
일반 회원 - 동아리 : 다대다 관계
일반 회원 - 출석 그룹 : 다대다 관계
동아리 - 회계 : 일대다 관계
동아리 - 동아리 카테고리 : 일대다 관계
"동네 데이터베이스"의 관계를 찾을 수 있었다.

따라서, 다대다 관계, 일대다 관계를 나타내기 위해
User Table과 Admin Table을 이렇게 구성한 것이다.(일반 회원 저장 리스트, 단체 저장 리스트)

Admin Table

 

 

GroupMembers 설계

- 다대다 관계 Table 설계법 -

 

일반 회원과 동아리는 다대다 관계에 속해있다.

일반 회원은 하나 이상의 동아리를 가입할 수 있고,
동아리는 한 명이상의 일반 회원을 받을 수 있기 때문에
"동네" 웹 서비스는 일반 회원과 동아리는 다대다 관계이다.

 

다대다 관계를 표현할 때는

일대다, 다대일 관계로 분리해서 Table로 나타낸다.

관계형 데이터베이스의 Table 특성이기에 다대다 관계는 일대다 or 다대일 관계로 분리하는 과정이 필요하다.

Table에 데이터가 규정한 칼럼 기준그대로 저장된다. - 이 규칙에 의해 다대다 관계는 분리해서 Table을 분리하는 것이다 ㅋㅋ..

다대다(M:N) 관계 연결테이블로 구현하기

 

즉,

동아리는 한 명이상의 일반 회원을 수용하고

일반 회원은 한 개이상의 동아리를 가입할 수 있으니,

 

Admin 그리고 User와 일대다 관계를 나타내는 Table인

ClubMembers Table을 구성한다.

ClubMembers Table (일반 회원 - 동아리 연결 Table)

 

출결

동아리의 출결에 대한 Table도 회원 관리와 똑같은 방법으로 구성하면 된다.

 왜냐,
일반 회원은 한 개이상의 출결 그룹에 들어갈 수 있고,
출결 그룹은 한 명이상의 일반 회원을 수용할 수 있기 때문에
일반 회원 - 출결 그룹은 다대다 관계이다.

 

따라서 일반 회원 - 출결 그룹 다대다 관계를 나타낼 수 있는

Table을 구성한다.

 

Group Table 설계

동아리 내의 출결그룹들을 저장할 수 있도록

다음과 같이 칼럼을 구성한다.

Group Table (동아리 내의 출석그룹)

 

GroupMembers Table 설계

일반 회원과 출결그룹을 일대다 관계로 나타낼 수 있도록

연결 Table인 GroupMembers Table을 구성한다.

GroupMembers Table (동아리 - 출석그룹 연결 Table)

 

조금 더 구체화하기

출결 그룹에서 한 개이상의 출석 스케줄을 생성할 수 있고,

출석 스케줄은 한 개이상의 출결 그룹에 지정받을 수 있기 때문에

출결 그룹 - 출석 스케줄은 다대다 관계이다.

GroupSchedule Table 설계

GroupSchedule Table

 

Attendance Table 설계

Attendance Table

 

 

 

erd 설계 회의는 참으로 많은 것을 느끼게 해준 회의였다..ㅋㅋ

 

 

 

회의하며 느낀점

우선 회의할 때는 경청하는 자세가 가장 중요하다는 사실을 깨달았다.

경청하지 않으면, 회의가 어디로 가는지, 어떻게 진행되는지도 모르게되고

결국 아무런 의견을 제시 못하고 수긍만 하는 포지션으로 전락하게 된다 ㅋㅋ...

항상 회의하면서 느끼는 거지만 경청하는 자세가 회의에 있어서 가장 중요한 요소라고 하겠다.

 

 

 

그리고, 내 의견을 팀원들에게 설명할 때

한번 설명들어가면 그 이후로 중간에 빠지지 말고 끝까지 내가 말한 것에 대한

의도를 설명해야 된다는 사실을 깨달았다.

애매하게 의견을 제시하면, 팀원이 나를 이해를 안하게 되고,

나 또한 팀원들을 못믿고 의견을 제시하지 않고 위축만 된다는 사실을 깨달았다.

그렇기에, 한번 팀원들에게 뱉은 말은 그에 대한 의도가 팀원들이 이해할 수 있을 정도로 설명하자.

팀원이 반박한 것에 위축되서 내 의견 끝까지 말하지 말고, 팀원의 중간 반박은 내가 이렇게 이해하는게 맞나? 라는 것일 뿐

내 의견을 짓누르는 행위가 아님을 명심하자..

한번 설명하기 시작한 내 의견의 끝에는 팀원들이 내 의도를 파악할 수 있게 말하는 것을 익히자.

팀원의 반박에 위축되서 내 의견을 끝까지 말하지 않고 중간에 끝내는 습관을 없애야 발전한다.

 

 

 

진정 좋은 리더란..

이때까지 나는 좋은 리더는 말솜씨 좋고, 의사소통 능력이 좋고, 프로젝트 진행 실력이 좋은 사람이

좋은 리더라고 생각했다.

하지만, 이번 회의를 통해

진정 좋은 리더에 대해서 재정의하였다.

진정 좋은 리더는 솜씨좋고, 의사소통 능력 좋고, 프로젝트 실력이 뛰어난 사람이 아니라,

모든 팀원의 잠재력을 이끌어낼 수 있는 사람이 진정 좋은 리더라고 생각한다.

 

왜냐하면, 모든 사람들은 서로 다른 뛰어난 잠재력을 내면에 감추고 살아왔기 때문에,

그러한 내면의 잠재력을 협력적 의사소통을 통해 이끌어낼 수 있는 사람 만이 진정한 좋은 리더라고 생각한다.

 

그럼, 좋은 리더가 되는 방법은 무엇일까..?

이번 회의에서 빙글님이 내가 생각하기에 진정 좋은 리더라고 생각했고,

나는 내면의 숨겨진 잠재력이 있는데 그걸 빙글님께서 이끌어 주신 듯하다..

 

빙글님은 회의 내내 팀원들에게 불평불만을 하지 않았고, 오로지 프로젝트의 성공만을 바라보고 회의를 진행했다.

내가 낯이 있는 사람들과 회의를 잘 못하기에 의견을 잘 못냈지만, 빙글님은 이에 화난 감정을 표현하지 않고

내가 유심히 고민 끝에 던진 의견들에 대해서 차분하고 논리적이게 답변을 받아주셨다.

이에 나는 자신감을 얻게되어 숨겨진 잠재력인 프로젝트 사고력이 깨어난 듯한 느낌을 받았다.

결국, 빙글님은 나의 숨겨진 잠재력을 일꺠워주는데 한몫했다고 생각이 들어

진정한 좋은 리더란, 이러한 모든 다양한 사람들의 숨겨진 잠재력을 이끌고 프로젝트를 진행하는 리더가 좋은 리더라고 재정의했다.

 

추가적 회의 후의 대한 나의 사담.

회의할 때 나의 숨겨진 잠재력을 뽐내면 더 좋은 성취결과를 얻을 수 있다는 사실을

경험을 통해 깨달았다.

그렇기에 나는 회의나 소통을 할 때 질문하고, 의견들을 제시하며 긴장감을 풀고 팀회의의 분위기까지 주도할 수 있는 사람이 되도록

열심히 실천해보겠다.

 

그리고, 처음보는 사람, 어색한 사람과 있을 때 긴장감과 어색함을 푸는 방법을 정리하겠다.

1. 내가 알고 있는 지식이라도 궁금한 척을 하면서 질문을 한다. - 이때 질문은 누구나 답변하기 쉬운 형태여야 한다.

2. 내가 모르고 있는 지식을 감추지 말고 당당하게 물어보며 답을 얻는다. - 사람은 누군가를 도와주고 싶은 심리가 내장되어 있다.

3. 내가 많이 알고 있는 분야더라도 설명하고 싶은 욕구를 참아야 한다. - 이 욕구를 다른 사람에게 전도해서 나에 대한 호감도를 증가시키는 용도로 사용해야 한다.