[팀 프로젝트] UMC 2기 웹 개발 프로젝트: 서버 개발자 입상 후기

오늘은 여름방학동안 진행했던 '동네' 웹 프로젝트를 마무리하겠다.

마무리 블로그를 작성하지 않고, 학기를 시작하면, 열심히 프로젝트 한 소중한 경험을 까먹을 것 같아서 블로그를 작성해둔다 ㅎㅎ

UMC 데모데이 우수상

무려 UMC 데모데이에서 우수상을 수상한 프로젝트 경험이기도하니, 잘 회고해서 프로젝트에 대한 시야를 넓히자 ㅎㅎ

실천해야 비로소 내것이 된다.

---

"동네" 웹 서비스 설명

우리 동네 웹 서비스는

대규모로 구성된 동아리의 회원 및 관리를 해야되는 임무가 있는 동아리 운영진을 위해서 만들어진

동아리 관리 웹사이트이다.

 

즉, 동아리를 운영해야되는 임무를 지닌 대학생들이

동아리를 개설하고 많은 동아리 회원들을 체계적으로 관리할 수 있도록 도와주는 웹 사이트이다.

 

 

우리 "동네" 에서 체계적인 동아리 관리를 위해 고안된 핵심 기능들은 다음과 같다.

# 운영진/단체
- 동아리의 소속회원들을 한 눈에 볼 수 있는 회원명단 조회 페이지
- 동아리 내의 스터디/활동그룹을 구성하는 페이지 -> 구성된 스터디/활동그룹의 스케줄을 생성하는 페이지
- 동아리 내의 회계내역을 관리하는 회계 관리 페이지

# 일반회원
- 동아리 소속회원이 본인이 속한 스터디/활동그룹의 생성된 스케줄의 출결을 하는 페이지
- 개인 회원정보를 수정하는 마이페이지

 

그럼, "동네"의 핵심기능을 웹에서 어떻게 구현했는지 자세하게 알아보자!

아래는, 노션에 정리된 랜딩페이지 내용을 복사해온 내용이며, 부족한 내용을 추가해서 정리했다.

 

 

"동네"는 동아리 대표 계정인 단체 회원과 개인 계정인 일반 회원으로 이루어져 있습니다.

동네 회원가입 페이지

 

단체 회원은 동아리에 가입한 일반 회원의 명단과 출결을 관리하고, 회계 관리와 커뮤니티가 이용가능합니다.

- 동아리 카톡방은 이제 빠빠이~ 우리 동네로 동아리 관리&정보를 기록해보자고요! (동아리 소속회원 명단 조회)

  동네에서는 단체에 소속한 회원들을 한 눈에 조회 그리고, 관리할 수 있습니다.
  단체 회원을 개설해서 동아리 가입코드로 원하는 회원들을 동아리에 가입시켜보세요! 


- 아직도 운영진이 직접 회원 출결을 확인하고 있나요? 😮 (스터디/활동 그룹관리, 그룹 내의 스케줄 관리)

  동아리 내에서 스터디/활동 그룹을 나눠서 회원들을 그룹에 추가하여 회원들의 활동들을 관리할 수 있습니다.
  회원을 지정해 스터디/활동 그룹을 생성하고, 그룹 별 스케줄을 생성해서 자동으로 만들어진 출석 코드를 통해 회원들의 출결을 간편하    게 관리하세요 !
  스케줄에 출석한 회원에게 출석 코드를 배포해 입력하게 하면 출결 관리 끝✨

- 엑셀로 직접 양식을 만들어 입력하는 회계 장부는 이제 그만 ❌ (동아리 내의 회계내역 관리)

  동네에서는 일/월 별 회계 현황을 간편하게 확인하고, 관리할 수 있습니다.

  회계 항목을 입력해서 일자 별 합계와 카테고리 별 사용 내역을 확인하세요.

 

 

일반 회원은 개인이 가입한 동아리의 기본 정보와 회계 현황을 조회하고, 본인의 출결 현황 조회와 처리, 커뮤니티가 이용가능합니다.

활동하는 동아리가 너무 많아 관리하기 힘드신가요? 🏃🏻 (동아리 가입)

동네에서는 개인이 활동하는 모든 동아리를 관리할 수 있습니다.

단체 코드를 통해 동아리에 가입하고, 내 워크스페이스에서 필요한 단체에 입장하세요.

이 단체에서 저 단체로, 가입 한 번으로 여러 개의 단체 페이지를 이용할 수 있어요‼️

결석이 몇 번인지 기억이 안 나시나요? 😅 (스터디/활동그룹 조회, 그룹 내의 스케줄에서의 출결)

동네에서는 출석 그룹 별 개인의 출결 현황을 한 눈에 확인할 수 있습니다.

출석 코드를 해당 출석 스케줄에 입력해 출석하고, 지금까지의 출결 현황을 확인하세요.

출석 스케줄 카드 위에 표시되어 있어 일일이 출석 스케줄을 확인하지 않아도 돼요🎨

회비는 냈는데 동아리에서 어떻게 사용되는지 아직도 모르세요? 🧐 (동아리 내의 회계내역 조회)

동네에서는 활동하는 단체의 회계 현황을 실시간으로 확인할 수 있습니다.

회비의 항목 별, 일자 별, 카테고리 별 사용 내역을 지금 바로 확인하세요!

 

프로젝트를 완성된 걸 돌이켜보니, 대학에 입학하고 첫 프로젝트임에도 많은 기능들을 구현을 했다는 사실을 알게되었다.

개발하면서, 힘들었긴 했지만, 그만큼 많은 것들을 배우고 느낄 수 있었다.

그래서, 오늘 블로그의 목적은 방학동안 진행한 웹 개발 프로젝트에 대한 회고이다.

 

이번 프로젝트에서 가장 많이 배웠다고 생각하는 건 안정적으로 프로젝트를 완성시키는 방법이다.

이번 경험을 통해 프로젝트를 이끄는 힘인 프로젝트 진행력에 대해서 새롭게 배운 점과 느낀점이 아주 많다!

따라서, 팀원 모두가 즐겁고, 안정적으로 프로젝트를 이끄는 방법을 비롯해서 프로젝트를 하면서 느꼇던 새로운 배움을 잊기 않기 위해서

우리가 회의했던 것과 개발했던 과정을 되돌아보면서

프로젝트를 하면서 내가 깨달은 것과 좋았던 점을 정리하는 블로그를 작성했다.

---

본론으로 들어가기 전..

아래의 적힌 내용들이 완벽한 답이 아니고, 좋은 답안 중 하나라고 생각하자!

인생은 답이 없고, 개발 또한 완벽한 답이 없음.

그렇기에, 완벽한 하나의 답안만을 고집하는 것이 아닌, 여러 좋은 답안을 지닌 사람이 되어
상황에 따라 적절한 답안을 이용하려는 사람이 되자  - 세상엔 완벽한 사람은 없고, 최적의 선택을 재빨리하는 사람이 성공의 길을 걷는다.

 

그리고, 내가 프로젝트 회고 블로그를 작성하는 이유는 2학기 때 프로젝트 리더로서 잘하려고 하는게 아니라,

앞으로 진행할 많은 프로젝트에서 이끌어 나갈 수 있는 존재가 되고자 블로그에 기록하는 것이다.

누구에게 잘 보이려고, 블로그를 하는게 아니라, 나의 프로젝트를 이끄는 역량을 키워 더 거대한 프로젝트를 수행할 수 있는 존재로 발전시키기 위해 블로깅을 하는 것이다.

그러니깐, 마음을 조금 내려놓고 "나를 위한" 블로그를 하자.

블로그의 목적이 나를 위한 것이 아닌, 보여주기 식 블로그를 하려니깐 의미도 없고 시간만 낭비하는 듯한 느낌이 들어서

잠시나마 나에게 충고를 했다. 

---

기획의 처음 (공통된 핵심목적을 찾기)

우린, 회의의 처음에는 프로젝트에 대한 설계를 진행했다.

프로젝트의 핵심 목적을 공유하고, 이에 따른 핵심 기능들을 찾는 회의를 진행했다.

기획 회의에 대해서 궁금하다면 아래의 블로그를 참고하자!

동네 1차 회의 (비대면)

 

동네 2차 회의 (대면)

 

모각코에서 나눈 의견이지만

기획은 한 사람이 해서 전달하는 게 더 편하다고함.
우리가 회의하면서 느낄 수 있듯이 여러명이 기획을 하면,

서로 다른 기능들을 제안하고, 모든 걸 수용하다보면

맥가이버 칼의 오류처럼 프로젝트의 방향성을 쉽게 잃어버릴 수 있기 때문이다.

 

그래서, 함께 기획을 하면, 공통된 핵심목적을 찾아야지만, 프로젝트가 방향성을 잃지않고 앞으로 나간다.

---

개발 회의의 처음 - 기술 스택 , 개발 템플릿, erd 설계

첫번째 백엔드 대면회의

(회의 전 약속: 개발템플릿 구성해오기)

(회의 후 결과: git organization 구성, 공통된 개발템플릿, 완성된 erd)

(공유 github 구성, 공유 개발템플릿)

 

첫번째 백엔드 대면회의가 가장 중요했었다고 생각한다.

프로젝트의 기획을 모두 한 후에 진행한 회의였고,

완성된 와이어프레임을 토대로 첫번째 백엔드 회의를 진행했었다.

 

이 회의는 개발의 기획단계 즉, 개발의 설계단계였던 것으로 생각이 든다.
이 단계가 있었기에, 프로젝트의 백엔드 개발자로서 개발에 대한 방향성을 잃지않고 프로젝트 개발에 임할 수 있었던 것 같다.

 

 

첫번째 백엔드 회의에서는 프로젝트 개발에서 사용할 기술 스택을 정하고,

백엔드 (협업) 개발 방식을 Github의 git flow 전략을 사용하기로 했다.

마지막으로 개별적으로 다음회의까지 개발 템플릿을 구성해오기로 약속했다.

 

- 기술 스택

1. 웹서버: express.js, node.js
2. db: mysql
3. AWS를 사용한 배포 (EC2, RDS)
4. api 명세서: api 적어주는 tool 있는 거 아세요? 뭐요 swagger → 써보지는 않았는데 편하다고 들었음. 이번에 한번 써보자~ 라는 생각
5. 로그 외에 자잘한 것들은 인스타그램 클론코딩 보고 하자

 

우리가 기술 스택을 정할 때는 한번씩 경험한 것들에서 추가하는 방식으로 정했다.

인스타 클론코딩에서 AWS EC2, RDS를 통해서 배포를 진행했고,

node.js를 이용해 클론코딩을 진행하였으니, 한번 써본 기술들을 가져와 기술 스택을 정했다.

(즉, 기존에 배워둔 기술 스택들이 우리 프로젝트에 적합한 상황이니, 그대로 사용했다.)

배우지 않았더라도, 프로젝트에 적합한 기술이면 가져와서 사용하는 능력도 중요함.

 

인스타 클론코딩에서는 API 명세서를 액셀로 수기로 기록해 관리했다.

우린, Swagger를 사용해서 API 명세서를 기록했다.

수기로 API 명세서 관리하는 건 불편하기에,, 개발하기 전에 미리 셋팅 계획을 세웠다.

(Swagger는 API 명세서 관리를 편하게 하는 개발 도구이다.) - Swagger에 대한 자세한 블로깅은 추후에 작성 완료하겠다.

 

이렇게, 회의를 통해서 기술 스택을 정했다.

아래는 "동네" 개발 프레임워크이다.

 

 

---

- Github | git-flow 전략 채택

우리는 Github의 work-flow는 git-flow 전략을 사용했다.

git-flow 전략은 Github 레포의 브랜치를 main, develop, feature/~ 로 파서

브랜치별로 코드를 관리하는 일정한 규칙으로 Github 소스코드를 관리하는 전략이다.

 

git-flow 전략의 일정한 규칙은 다음과 같다.

main에서는 개발이 완료되어 배포용 코드를 push
develop에서는 중간개발이 완료되면, feature/~ 브랜치의 팀원들의 코드들을 merge하는 브랜치이다.
feature/~ 브랜치에서는 각자에게 부여받은 개발파트에 대한 기능 브랜치로
중간개발이 완료되면 해당 브랜치로 코드를 push한다.

 

프로젝트 내내 git-flow 전략을 사용하면서 느낀 점은 develop 브랜치 하나로 github를 관리하는 것보다

merge 시 형상관리를 기록할 수 있어서 Github 소스코드의 버전 관리에 용의했다.

git-flow 전략

 

하지만, git-flow 전략이 프로젝트에서 항상 도움을 주진 못했다.

github에 소스코드를 push하면서 많은 브랜치를 통해 관리하니 github에 코드를 push하는 전략이 헷갈렸었다.

그래서 프로젝트를 마치고 혼자 알아보았더니,

 

 

Git-flow는 소프트웨어 버전 관리가 필요한 앱이나 솔루션, 혹은 public API에 적합한 워크플로우입니다. 웹 애플리케이션에서 Git-flow는 고려할 전략이 아닙니다.

결국, git-flow 전략이 Github 소스코드 관리에는 유용하지만, 만병통치약이 아닌셈이다.

아래의 블로그에서 GIt 브랜치 전략에는 정답이 없다고 강조한다.

프로젝트의 크기 및 방향성에 따라 적절한 github 브랜치 관리 전략을 정해서 관리하는 것
그리고,
만약 주어진 상황에 어울리는 전략이 없다면 상황에 맞게 새로운 플로우를 만드세요. 리소스를 낭비하면서 틀에 얽매일 필요는 없습니다.

 

Git 브랜치 전략 수립을 위한 전문가의 조언들 – 화해 블로그 | 기술 블로그

 

그래서, 다음에 Github 관리해야 되는 상황이 오면, 이번의 경험을 기반으로

프로젝트의 크기에 따라 적합한 Github 브랜치 전략을 정해서 진행해볼 것이다!

좋은 Github 브랜치 전략은 모든 팀원이 브랜치 전략을 이해할 수 있는 브랜치 전략이다. 

 

 

---

- 쉬운 프로젝트 개발을 위한 개발템플릿 구성  with. REST API

우리의 개발템플릿은 인스타 클론코딩에서 사용한 프로젝트 폴더를 복사한 다음에,

내용물 중 필요없는 것들 지우고, 필요한 것들은 추가해주면서

우리의 프로젝트를 진행할 수 있는 상태로 개발템플릿을 setting 했다.

 

그리고 우리의 개발템플릿은 REST API로 구성했다.

REST API에 대한 상세 설명은 아래의 블로그를 참고하길 바란다.

[네트워크] REST API란? REST, RESTful이란?

REST API는 자원을 이름(명사)으로 구분하여 해당 자원의 상태를 주고받는(CRUD) 모든 것을 의미합니다.

REST API는 API를 작성하는 가장 트렌디한 방법이라고 

API에도 체계가 필요하다는 관점에서 나온 방법이 REST API다.

한마디로, API 개발을 좀 더 쉽고 체계적이고, 개발에 대한 규칙적인 방법을 정해 만들어둔 규약이라고 보면되겠다.

 

따라서 우린, REST API를 기반으로 개발템플릿을 구성하고, 개발을 시작했다. 

 

 

사전에 개발템플릿을 구성해두고, 개발을 하면서 좋았던 점은

사전에 정한 개발템플릿을 통해 개발에 대한 방향성을 잃지 않을 수 있었던 게 가장 좋았었다.
그리고, 모든 팀원이 공통된 개발템플릿으로 각자의 개발파트에 속하는 개발을 진행하니깐, merge하면 작업내역을 develop 브랜치에 바로 반영할 수 있어서 Github 소스코드 관리에도 편리했었다.
(개발템플릿이 핵심기능별로 도메인을 나눠서 개개인의 작업공간이 분리될 수 있었던 것 같다.) 

 

이렇게 가능했던 이유가 사전에 개발템플릿을 정하고 개발을 시작했던 것이라고 생각이 든다.

개발 템플릿으로 개발할 때의 규칙을 정해서 프로젝트 개발을 할 때 방향성을 잃지 않고, 개발할 때 헷갈리지 않고(어디에 코드를 작성해야되는지 모르는 상황) 꾸준하게 개발을 할 수 있었던 것 같다.

그리고, 정한 개발템플릿의 규칙이 뚜렷하니깐 GIthub 소스코드 관리도 편했던 것 같다.

(Github 소스코드 관리가 편하다는 건, 각자의 작업한 내용물을 merge할 때 큰 어려움이 없었던 것을 의미한다.)

 

 

아래는 우리의(백엔드) 개발템플릿이다.

개발템플릿에 대해 감이 않잡힌다면, 아래 사진을 참고하기!

"동네" 백엔드 개발템플릿

 

명심해야 할 점은, 우리가 개발템플릿을 구성할 때 처음부터 끝까지 생각해낸 게 아니라,

시중에 흔히돌아댕기는 개발템플릿 (인스타그램 클론코딩) 프로젝트 폴더를 복사해와서

우리의 프로젝트에서 필요한 것들을 위주로 setting 해줬다는 걸 잊지 말자!

그리고, 이러한 개발템플릿을 구성할 수 있었던 건
사전조사가 있었기 때문이다.
그렇기에, 프로젝트에 적합한 개발템플릿 구성에 대한 사전조사를 충분히 한 후 팀원들과 공통의 개발템플릿을 구성하면 된다.

 

개발템플릿은 Test 버전으로 임의로 작업영역에 대해서 test를 만들어두면

팀원 모두가 개발템플릿을 이해하는데 수월하다.

 

만약, 개발템플릿이 없이 무작정 개발을 시작하면, 하울의 움직이는 성처럼 돌이킬 수 없는 상황이 벌어질 것 같다는 생각이 든다... ^..^

그렇기에, 프로젝트를 시작하기 전에 개발템플릿을 구성해두고 프로젝트가 하울의 움직이는 성처럼 되지 않도록 대비하는 자세를 지니자

ㅋㅋ..

 

---

- 프로젝트 협업 관리를 위한 Github organization 구축

 

우린, 프로젝트를 관리하기 위해 Github의 organization을 조직하고

organization에 레포를 구축했다.

 

 

그리고, 앞에서 설명한 개발템플릿을 레포에 push해두고,

프로젝트 협업 관리를 위한 Github organization 조직? 구축을 완료했다.

구축한 Github organization의 백엔드 레포

 

그리고, 앞에서 정한 Github 브랜치 관리 전략인 git-flow 전략을 위한 브랜치를 설정해주었다.

개발 완료 후 배포를 위한 코드를 저장해두는 main 브랜치
중간개발 완료 후 feature/~ 브랜치의 코드를 merge 해서 중간개발 완료용 코드를 저장해두는 develop 브랜치
핵심 기능별로 부여받은 작업 도메인을 브랜치 구분자로 코드가 저장되는 feature/~ 브랜치

 

 

우리가 프로젝트하면서 구성한 브랜치는 다음과 같다.

"동네" 백엔드 Github 브랜치

 

GIthub oraganization을 이용해 협업 개발하는 방법이 궁금하다면,

아래의 블로그를 참고하자!

동네 백엔드 대면 회의 - 1차 (erd 설계)

과거에 블로그를 작성할 때 하루하루에 경험했던 걸 정리하는 식으로 했었다!

이 점 감안하면서 보자!

---

- [백엔드 개발 시작의 꽃] erd 설계

 

우리는 Aquery tool을 이용해 erd 설계를 했다.

 

아래는 우리가 설계한 erd이다.

비밀번호: 1obi13

AQueryTool

 

 

erd 설계는 프로젝트 기획에서 완료한 와이어프레임을 보면서 erd를 설계를 했다.

Figma로 설계된 와이어프레임

참고로, 와이어프레임을 토대로 erd를 설계할 때는 한 페이지씩 보는 게 아니라

사용자가 웹을 사용하는 로직을 생각하면서 와이어프레임을 봐야한다.

와이어프레임에서 구성된 페이지간의 연결되는 것끼리 연결해서 보는 방식이라고 생각하면 되겠다.

 

위와 같은 방식으로 와이어프레임을 보게되면, 프로젝트의 구조가 보인다.

(어드민 - 유저
어드민 기능
회원가입&로그인
회원명단 관리
스터디/활동그룹 관리
그룹 내의 스케줄 관리
회계 관리

유저 기능
회원가입-로그인
스터디/활동그룹 조회
그룹 내의 스케줄 조회 & 스케줄 출석
회계 조회
)

 

erd 설계할 때 와이어프레임의 세부정보를 보는 것보다, 핵심정보를 보고

핵심기능을 추출해서 정리하자. - 정리하는 방법은 사용자(단체, 일반 회원) 기준으로 정리하는 게 직관적이다.

그리고, 추출된 핵심기능을 토대로 erd를 설계한다.

 

 

우리가 erd 설계할 때는

우선 유저 table 어드민 table, 그룹 table, 회계 table을 구성했다.

핵심기능에 대한 Table을 구성한 것이다.

 

그러고, table간의 "관계"의 종류를 파악해
핵심기능에 대한 table 간의 connect table을 추가로 구성하여 erd 설계를 완료했다.

connect table을 구성할 때는 아래의 블로그를 참고했다!

관계형 데이터베이스 설계 (관계 종류 1:1 / 1:M / N:M ) - 하나몬

 

결국, 기획단계에서 설계한 와이어프레임을 앞에서 설명한 것처럼 해석하는 방법만 안다면,

데이터베이스 erd 설계는 어려운 것이 아니다.

 

프로젝트를 마치고, erd 설계에 대해 덧붙이자면,

한번의 erd 설계로 완벽한 데이터베이스를 만드려고 하지말자!

프로젝트하면서, 그룹의 스케줄 출석에 대한 Table은 코드를 작성하면서 erd를 추가로 수정해주었다.

그렇기에, 직접코드를 구성해보면서 알 수 있는 erd가 있으니,

핵심기능을 위주로 erd설계를 하자.

다시말하지만, 한번의 erd 설계로 완벽한 데이터베이스를 꿈꾸지 말고, 어설프지만, 작동은 되는 erd설계를 생각하자!!

 

혹시 erd 설계에 대해서 더 알아보고 싶다면 아래를 참고하자!

"동네" 백엔드 대면 erd 설계 회의 후 정리한 블로그이다.

동네 백엔드 대면 회의 - 1차 (erd 설계)

 

 

 

---

개발 회의의 두번째 - API 목록 리스트, 개발 분야 지정

 

우리는 API 목록 리스트를 정한 후 이를 토대로 개발 파트를 나눴다.

API 목록 리스트도 와이어프레임을 토대로 정했다.

 

API 목록 리스트를 어떻게 정했는지 살펴보기 전,

우선 API에 대한 개념을 살펴보자!

API(Application Programming Interface) 는 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법을 의미합니다. 어떤 특정 사이트에서 특정 데이터를 공유할 경우 어떠한 방식으로 정보를 요청해야 하는지, 그리고 어떠한 데이터를 제공 받을 수 있을지에 대한 규격들을 API라고 한다! API라고 함!

클라이언트 - 서버와의 통신을 조율해서, 클라이언트에서 원하는 결과를 제공할 수 있도록 만들어주는 것이 API이다.
클라이언트에서 요청을 보내면 이에 따른 응답 값을 받도록 API가 조정해준다. - 음식점의 점원
실제로 API는 클라이언트의 요청을 받아서 DB에게 클라이언트가 원하는 형태로 요청을 전달하고,
DB의 응답 값을 다시 받아서 클라이언트에게 전달해준다.

 

API의 역할을 세부적으로 나누면 요청과 응답을 조율하는 역할로 보이지만,

실제로 개발을 할 때는 클라이언트에 대한 요청 값을 받아서 요청에 따른 적절한 응답 값을 만들어간다.

그러니깐, API를 개발할 때는, DB 쿼리문까지 직접구성해서 요청에 대한 응답값을 만들어 클라이언트에게 전달한다.

개발자의 입장에서 보았을 때 API는 음식점의 점원이 아니라, 음식점의 점원 + 요리사인 셈이다!

 

API에 대해서 잘 모르겠다면, 아래의 블로그를 참고하자!

API란 무엇일까? API 쉽게 이해하기

 

[IT용어] API란 무엇인가? — Steemit

 

 

다시 본론으로 돌아와서, 우리는 개발을 시작하기에 앞서,

"동네" 웹 서비스에서 필요한 API 목록 리스트를 정하는 회의를 했다.

API 목록 리스트는 와이어프레임을 토대로 구성했다.

 

우리는 API 목록 리스트를 정하기 위해 웹에서 클라이언트의 요청 값 - 응답 값에 해당하는 쌍들이 무엇이 있는지 찾았다.

대체로 요청 값 - 응답 값의 쌍은 사용자의 마우스 클릭포인트에서 발생한다.

그렇기에, 와이어프레임을 볼 때 사용자가 웹을 사용하는 관점에서 마우스 클릭포인트 지점을 찾는다면,

클라이언트의 요청 - 응답에 해당하는 쌍들("동네"에서 필요한 API)을 찾을 수 있다.

 

여기서, 주의해야 할 점은 프론트엔드에서 처리할 데이터를 API 목록 리스트에 기재하면 안된다.

이에 대해서 구분하는 법은 마우스 클릭포인트 지점 후의 데이터들이 고정 데이터인지 유동 데이터인지를 파악하면 된다.

고정 데이터이면, 프론트엔드에서 작업해야할 사항이고,
유동 데이터이면, API 목록 리스트에 추가해야할 사항이다.

 

그렇게 클라이언트의 요청-응답에 해당하는 쌍을 찾으면,

어떤 도메인에서 개발을 할 것인지를 정해야한다.

우리는 REST API를 기반으로 API를 개발하기에,
 개발 자원(API)을 도메인 네임으로 분류한다.

요청에 대한 응답 값을 얻기위해 DB에서 처리하는 Table을 토대로

핵심 도메인으로 간주하고, 서브 도메인은 DB에서 응답을 처리하는 세부과정(CRUD)을 보고 정했다. - 여기는 조금더 토의해야됨

아마 핵심 도메인은 "핵심 기능"으로 분류가 될 것이다.

ex) 동아리 내의 모든 회원명단 조회 API는
어드민-유저를 연결하는 ClubMembers Table에서 처리가 이루어지므로,
핵심 도메인을 Member로 정했고,
조회 API이므로 서브 도메인은 쿼리스트링으로 정했다.

 

그렇게, 위와 같은 방법으로 "동네" 웹에서 필요한 API 목록 리스트를 정했다.

"동네" API 목록 리스트

 

아래는 "동네" API 목록 리스트이다.

https://www.notion.so/api-8409ff4ec0d54484ab2a351afb21ebe9

 

 

API 목록 리스트를 정한 다음,

핵심 도메인별로, 개발파트를 나눴다.

나는 회원명단 (Member), 스터디/활동그룹 (Group) 에 관한 API 개발을 맡았다.

 

이제 여기까지 프로젝트 설계에 대한 회고를 완료했다.

설계는 기초적이면서, 가장 핵심적인 단계로 프로젝트의 지지대를 만드는 것과 같았다.

그렇기에, 오늘 정리한 프로젝트 설계에 대한 회고를 잊지말고 앞으로 프로젝트할 때 참고하자!

---

여러 번의 정규 회의 및 개발 회의

여러 번의 정규회의 및 개발회의는 프로젝트 개발 단계에 대한 회의로 개발을 하면서 가지는 정규 회의였다.

정규 회의는 매주 화요일 오후 10시에 비대면으로 진행했다.

이 회의에서는 프론트엔드 개발진행 상황, 백엔드 개발진행 상황을 공유했고,

개발하면서 생긴 이슈들을 서로 회의하는 시간을 가졌다.

(프론트엔드 - 디자이너 , 백엔드 - 프론트엔드 , 디자이너 - 개발자 -> 우리의 질문구조는 이렇게 되었다.)

 

개발 회의는 정규회의가 아닌, 개발하면서 이슈가 생기면 그때 그때 회의날짜를 잡아서

회의를 진행했었다.

이슈는 개발 방향성에 대한 논의나, API 추가 설계에 대한 논의와 같은 프로젝트 이슈를 뜻한다.

슬랙으로 전할 수는 있지만, 전달사항이 많아서 회의를 통해 이슈사항을 한꺼번에 해결했다.

 

이렇게 필요할 때 개발회의 일정을 잡아서 회의를 진행하니, 많은양의 이슈거리를 한번에 해결할 수 있어서

프로젝트가 지체되지 않아서 좋았었다.

- 누군가가 주도를 해야지만 가능한 회의방식! -

 

개발하면서 좋았던 점

- 개발에 대한 우선순위를 정한 것

  우선순위를 정하고 개발을 시작하니, 프로젝트가 지체되지 않았던 점이 좋았었다.

  프로젝트는 시간과의 싸움이라고 해도 과언이 아닌만큼, 시간분배가 중요한데

  개발 우선순위을 정한 전략은 프로젝트 개발의 방향성을 잃지 않고 지속적인 개발을 할 수 있었다.

  개발 우선순위를 정하는 건 장기적으로 보았을 때 유리한 전략이다.

우리는 핵심기능을 나열하고, "동네" 서비스 런칭 목적인 동아리를 체계적으로 관리할 수 있도록 돕는 웹 서비스를 감안해서
핵심기능 중 중요도가 높은 기능 순으로 개발에 대한 우선순위를 정했다.

 

프로젝트를 진행할 때 개발 우선순위를 정하는 방법에 대해서 잘 모르겠다면,

우리 "동네"의 개발 우선순위를 참고하자!

회원명단 -> 출결그룹 -> 회계관리 -> 커뮤니티 -> 활동관리
(로그인&회원가입은 우선순위에 속하지 않고, 무조건 개발 - 웹 서비스 특성)

"동네"의 주 사용자가 동아리 운영진이기에,
 어드민 사이드 개발 -> 유저 사이드 개발

"동네"의 개발 우선순위가 완벽한 "답"이 아니고, 좋은 예시 중 하나라고 생각하자 - 시야가 넓은 개발자되기

 

- Swagger를 활용한 API 명세서 작성

  API 개발이 완료가 되고, API 명세서(API 사용법)를 작성해줘야하는 것이 백엔드 개발자의 임무?이다.

  Swagger를 활용해서 액셀과 같은 별도의 툴을 사용할 필요없이

  웹 사이트에서 API 도메인 요청테스트를 할 수 있다.

  API 명세서 겸, API 도메인 요청테스트를 할 수 있어서 API를 쉽게 이해할 수 있었다.

  Swagger가 주는 이점은

  액셀로 정리된 API 명세서 + Postman에서의 API 요청을 합친 것이다.

 "프론트, 백엔드 모두가 좋았던 개발 툴 Swagger"

 

- 개발템플릿의 개발 규칙을 이해한 것

  개발템플릿이 가지고 있는 규칙을 이해하니, 개발을 할 때 어디에 코드를 작성해야되는 혼동이 오지 않아서 좋았었다.

  마치 하울의 움직이는 성처럼 어디에 코드를 작성해야되는지 혼란이 없으니, 개발에 대한 방향성을 잃지않았고, 개발 속도도 향상되었다.

 추가로, 함수&변수 네이밍 규칙을 정해두니 개발하는 내내 편해서 좋았었다.

  *쿼리문 함수는 selectRetrieve~, Service.js의 함수는 Retrieve~ *

 함수&변수 네이밍 규칙에 대해선 따로 블로그를 작성할 예정이다.

개발템플릿의 개발 규칙을 이해한 후 개발을 진행하면, 개발하다가 하울의 움직이는 성을 보지않아도 되는 좋은 전략이다.

 

 

개발하면서 아쉬웠던 점

- API 핵심 도메인의 부족

개발하면서 Member 도메인에 대해서 의미가 결여되는 상황이 있었다.

Member 도메인의 목적은 회원명단에 관한 API들을 속하게 만들었다.

개발을 진행하면서 추가적인 API를 구현할 때

마이페이지, 메인 홈 정보 조회와 같은 API들을 Member 도메인 특성이 아님에도,

Member 도메인에 넣었다.

이 부분에 대해선, 핵심 도메인을 핵심 웹 뷰를 통해 분류하면 되겠다. (메인 홈 뷰, 회원 명단 뷰, 출석그룹 뷰, 회계 관리 뷰, 커뮤니티 뷰)

 

- baseResponse 규칙을 정하지 않고 개발

서로서로 다른 baseResponse에 대해서 규칙을 정하지 않고, 개발을 하니깐

baseResponse가 다르게 정리된 게 여러 개가 나오는 결과가 초래되었다.

이 부분에 대해선, baseResponse 작성 규칙에 대해서 개발 전에 정해두면 중복 response 없이 관리할 수 있겠다.

 

- Git-Flow 전략

main 브랜치와 develop 브랜치의 차이가 미미했고, Github를 관리할 때

차이가 미미한 브랜치가 있어서 merge할 때 브랜치 낭비인 느낌이 들었다.

그래서, pull 받을 때 main과 develop 브랜치가 헷갈렸고

특히 배포할 때 브랜치가 헷갈렸던 적이 있었다.

이 부분에 대해선, 낭비되는 브랜치를 제거하면 해결할 수 있다고 생각한다.

git-flow 전략이 만병통치약이 아닌만큼, 프로젝트에 따라서 적합한 github 브랜치 관리전략을 세우면 되겠다.

 

 

- Validation 검증 규칙을 정하지 않았던 것

프론트에게 유효한 Validation 검증 수준을 확인하지 않고 개발을해서 개발 과정과 개발시간 및 개발 규칙을 몰라서 많이 헤맸었다.

그래서, 프론트에서 유효한 Validation 검증이 어떤 것인지 규칙을 정하고, Validation 개발을 했다면 헤매지않고 개발을 할 수 있을 것 같다는 걸 개발이 끝나가는 시점에서 깨달았다.

그러니깐, API Validation 검증 규칙을 미리 정해두었다면, 개발속도가 더 빨랐을 것 같다는 아쉬움이 있었다.

이 부분에 대해선, 프론트와 백엔드가 Validation 검증 규칙 선정에 대한 회의로 API 목록 리스트를 정하고 본격적인 개발에 들어가기 전에

해두면 좋을 것 같다!

 

 

우수상을 받은 소감 & 프로젝트를 마친 소감

이번에 여름방학동안 진행했던 "웹" 런칭 프로젝트는 내가 지금까지 진행했던 프로젝트 중 가장 규모가 크고, 직무(프론트, 백엔드, 디자이너)가 뚜렷하게 드러나고, 가장 많은 걸 배우고 느낄 수 있었던 프로젝트였다.

사실, 너무나 많은 걸 배우고 느꼈기에... 모든 걸 블로그에 담아내지 못한 것 같아서 아쉽긴 하지만, 나름 기억하고 싶은 것들은 모두 담아낸 것 같다  ^.^

 

프로젝트 초기에는

Github를 다루는 방법도 하나도 몰랐기에, 협업을 위한 개발 준비에 대해 하나도 안되어있는 상황이었다.

그리고, 백엔드 개발자로써, 메인 개발자로서 참여한 프로젝트 경험이 처음이었기에

회의를 진행할 때 막막하고, 엄청 힘들었다.

그래서, 처음에는 PM분께서 제공해준 "웹" 사이트 기획란을 보면서 "내가 이걸 구현할 수 있을까?", "내가 이 수많은 기능들을 구현할 수 있어?" 라는 프로젝트에 대한 비관적인 생각이 가득했다.

솔직히, 프로젝트가 중간에 흐지부지될 줄 알았다.. 왜냐, 부족했던 개발인력과 부족한 개발시간이 뚜렷하게 보였기 때문이다.

 

하지만, 난 이 프로젝트를 꼭 다 만들고 싶은 의지가 있었다.

나는 약 1년전 대학입시에서 비교적 좋지 않은 결과가 있었고, 그 경험을 통해 내가 자신감이 없었기에

내가 바라는 결과를 얻지 못한다는 걸 깨달았었다. - 대학교 입시는 나의 인생의 전환점.. | 궁금하면 나한테 따로 물어보기..

그래서, 난 이 프로젝트를 꼭 성공적으로 완수해서 내가 1년전에 저질렀던 실수에 대해 성장한 나의 모습을 보고 1년전 내가 저질렀던 행동에 대해 "나에게" 용서를 구하고 싶었다.

 

이런 생각을 토대로 나는 프로젝트에 열정적으로 임하기 시작했다.

우선, 프로젝트에 대한 자신감을 가지게 되는 가장 좋았던 행동이

"책임감 있게 프로젝트에 임하기" 였다.

 

책임감 있게 프로젝트에 임하기 위해선

생각없이 정규회의에 참여하는 것이 아닌, 미리 회의 전에 회의목표와 관련한 사전 공부를 했다.

하나 예로 들자면, erd설계 회의 당시에는 erd 설계하는 방법에 관한 유튜브 영상을 미리 시청했었다. 

또 다른 하나로, 기획 회의 전에는 PM분이 제공해준 프로젝트 기획란에 대해서 미리 찾아보고, 프로젝트에 대해서 이해를 했었다.

 

책임감 있게 프로젝트 구성원으로써 행동을 하니깐, 팀원들도 나에 대한 인식이 좋아졌고, 나 또한 프로젝트에 대한 방향성이 뚜렷해지는 걸 느낄 수 있었다.

프로젝트하는 내내 책임감 있는 사람이 되도록 노력했고,

그 결과 성공적으로 웹사이트를 만들고, 배포까지 완료하고..

UMC 데모데이에서 "우수상"까지 수상하는 성공적인 경험을 맛볼 수 있었다.

 

그래서, 나는 이번 프로젝트에서의 나에게 부여한 건 "책임감 있는 프로젝트 구성원 되기"였다.

 

책임감 있게 프로젝트에 임하는 생각을 가진 후부터 프로젝트에 대해서 긍정적인 시선으로 바뀌었고,

그에 따라 프로젝트를 지체하지 않고 꾸준히 완성해나가는 걸 느낄 수 있었다.

책임감 있는 사람이 되어도 중간 중간에 기획과 개발에서 많은 어려움들이 있었지만,

프로젝트 팀원들과 함께 협업하여 충분히 해쳐나갈 수 있었다.

책임감 있는 구성원으로 임했기에, 팀원들과 협업하여 해쳐나갈 수 있었다고 난 생각한다.

 

아래는 우리의 회의에 대한 회고록이다.

7월 4일 첫 회의 ~ 8월 23일 마지막 회의

참으로 많은 회의를 진행했고, 2달이 안되는 짧은 시간에 이렇게 많은 기능들을 구현하고,

배포까지 완료했다는 사실이 아직까지 믿기지 않고, 나를 비롯해서 "동네" 팀원들이 대단하다고 생각한다 ㅎㅎ

 

 

 

마지막으로, 프로젝트에 대한 회고를 마치며...

결국, 나 또한 뭐든지 할 수 있다는 자신감과 무언가를 달성하고자하는 의지만 있다면

어떠한 어려운 것들이든 충분히 해쳐나갈 수 있다는 존재라는 사실을 이번 프로젝트를 통해서 알게되었다.

그래서, 앞으로 다가올 수많은 어려움들이 있겠지만 나는 이것들에 대해서 위축되지 않고 충분히 해쳐나갈 수 있는 "나"이기에

끊임없이 어려움들을 해쳐나가며 꾸준히 성장하는 "김동욱"이 되도록 하겠다.

 

 

아래는 프로젝트하면서 느꼈던 나만의 지혜이다.

"큰 행복엔 큰 책임감이 뒤따른다."

"자신의 한계점이 없다고 생각하는 그 순간부터 내가 몰랐던, 내면의 잠재력이 발휘된다."

"눈치보지 말고, 자신에 대해서 당당해지면 내가 생각했던 것보다 훨씬 좋은 성과가 뒤따른다."

 

---

지금까지, 여름방학동안 진행했던 "동네" 프로젝트 회고 블로그이고,

블로그 작성이 처음이라 어설프지만, 끝까지 읽어주셔서 감사합니다!

---

최상의 동아리를 만들기 위해 반드시 사용해야 하는 "동네"!
동아리 관리의 편견을 없앤 웹사이트 "동네"!