내가 만든 웹 서비스, meView
아래 링크는 Notion 페이지입니다.
🔗 프로젝트 meView 회고록
🔗 사이트 주소: meView
🕔 진행 기간
- 기획/디자인: 2024.01.28 ~ 2024.03.10
- 개발: 2024.02.17 ~ 2024.03.10
- 유지보수: 2024.03.11 ~ 2024.03.17배포 후 유지보수 계속 진행할 예정
🗓️ 세부 일정(개발 기준)
1주차: 아이디에이션
2주차: 개발 스택 조사
3주차: 개발환경 세팅
4주차-6주차: 개발 진행 및 배포
7주차: 유지보수 작업
8주차: 발표 및 네트워킹 행사
📖 기술스택
- 디자인:
Figma - 프론트엔드
- 언어:
javascript - 라이브러리:
React,Recoil,styled-components,Axios,React Query - 배포:
스위그
- 언어:
- 백엔드:
- 언어:
typescript - 프레임워크:
NestJS - 데이터베이스:
PostgreSQL,AWS RDS - ORM:
Prisma - 관리 및 배포:
AWS EC2,Github Actions,Docker
- 언어:
- 코드 관리:
Github - 협업 툴:
Notion,Slack,Zoom
① meView 란 무엇인가
❶ 미뷰는 나만의 강약점을 발견하는 웹 서비스로, 내가 리뷰 받고 싶은 것을 정해 질문지를 생성하고 이를 공유해 공유한 사람들이 답변해주면 해당 답변을 모아 관리하는 서비스이다.
❷ 언제 사용하나요??
- 프로젝트가 끝났을 때, 취업할 때, 자기소개서 작성할 때 등등…
- 내가 어떤 강점이 있고, 약점이 있는지를 알 수 있고, 프로젝트에서 나의 모습, 친구들에게 나의 모습,
회사에서의 나의 모습 등을 주변 지인이나 팀원들에게 피드백 받고,
나를 알아갈 수 있는 기회를 제공합니다 !!
❸ 어떻게 사용하나요??
- 어떤 주제에 대해서 리뷰를 받고 싶은지, 어떤 대상에게 받고 싶은지 등등을 정하고, 답변을 작성할 수
있도록 링크를 전달한다. 링크를 받은 사람은 링크를 통해 답변을 작성합니다. - 질문자는 받은 답변을 모아볼 수 있고, 나의 강약점을 능력과 연결지어서 볼 수 있습니다.
❹ 팀은 어떻게 이루었나요??
- 기획자 1 / 디자이너 1 / 프론트개발 2 / 백엔드개발 2
⭐ 내 역할 ⭐
- Back-End API 개발 & 클라우드 서버, DB 구축 및 배포
- 다른 팀원분들과 의사소통, 협업 담당
② 프로젝트는 어떤 구조인가
❶ Front-End: React 를 활용해 웹 서비스를 만들었고, 스위그를 통해서 배포했습니다.
❷ Back-End: Nestjs 를 활용해 웹 서버를 구축했고, AWS 를 활용해 배포했습니다.
👍 이번 프로젝트를 통해 배운 점
- Nestjs 프레임워크에 대한 전반적인 이해와 API 작성했습니다.
- decorator, filter, interceptor, guard… 등등에 대한 사용법을 익혔습니다.
- prisma & postgresql 을 사용하여 relation 관계와 다대다 관계를 해결했습니다.
- AWS EC2, RDS, S3 를 구축하며 인바운딩, 아웃바운딩 등 AWS 서비스를 직접 설정하며 사용법을 익혔다.
③ 어떤 API 가 필요했나
- 총 19개의 API 를 작성했고,
Get,Post,Put요청에 대한 API 를 작성하였습니다. Delete는 데아터베이스에is_used속성을 추가하여,Put요청으로 속성 값을 바꾸도록 했습니다.URL과Parameter, return type등을 노션과Postman을 이용해 프론트엔드와 협업하였습니다.- 로그인과 답변 작성을 제외한 나머지 API 는
Guard를 이용해 로그인 상태를 검사했습니다.
④ ERD 는 어떻게 작성했나
- 여러 테이블과 각 relation 을 설정했고, 다대다 관계를 연결테이블인 Review 를 생성해 해결했습니다.
- ORM 은 Prisma 를 사용해서 N+1 문제가 발생하지 않았습니다.
⑤ 아쉬운 점에 대해서
❶ 아쉬웠던 점
authority에 따라서Admin과 일반User를 구분하여 서버에서 사용할 수 있는 API 를 구분하고 싶었지만, 시간이 부족한 탓에Admin페이지를 따로 만들지 못해서,Role을 따로 나누지 않았다.
다음 프로젝트에서는admin과user를 구분하여 적용하고 싶다.- 프로젝트를 시작할 때
CI/CD와cloud DB,server를 일단 세팅해놓고 시작했다면, 프론트엔드와 연동하는 과정에서 더욱 수월했을 것 같다. 또한 API 를 작성할 때도Parameter와Response에 더미 데이터를 넣고 시작했다면 더욱 좋았을 것 같다.
→Postman과Notion을 통해Parameter,Response Format을 정하고 했음
⑥ 이 프로젝트에서 어떤 걸 배웠는가, 나중에 어떤 걸 활용할 수 있을까
❶ API 명세서 작성에 대해서
- API 명세서를 작성할 때 이걸 보는 사람의 입장에서 작성을 해야한다. 우선 프론트엔드 개발자, 넘어서는 기획자나 디자이너까지 API 명세서를 본다. 그렇다면 각각 어떤 식으로 명세서를 활용하는지도 살펴보아야한다. 일단 프론트엔드 개발자는 API 를 보내는 코드를 작성하기 위해, 실제 request 와 response를 살펴보고 연결이 제대로 되는지를 확인한다. 기획자와 디자이너는 볼 일이 많지는 않겠지만, 보게 된다면 우리 팀의 서버가 어떤 식으로 돌아가는지 전체적인 흐름을 파악하기 위함이다.
- 따라서 이번 프로젝트에서는 프론트엔드 개발자를 위한 Postman API 명세서, 이외 직군을 위한 Notion API 명세서를 작성했다. Swagger 를 쓸 수도 있었지만, API 작성을 마치고, 자동으로 Swagger 문서를 NestJS 에서 만들어주기 때문에 제외했다.
- 이번 프로젝트에서 작성한 API 명세서는 감히 내가 본 문서 중 가장 명료하고, 깔끔하다고 생각한다. 이후 프로젝트에서도 아래와 같이 깔끔하고, 소통이 원활하게 될 수 있는 API 명세서를 작성하려고 한다.
아쉽게도 Postman 은 3명이 초과된 TeamSpace 사용으로 Upgrade 하지 않으면 볼 수가 없게 변해버렸다…
❷ NestJS 의 실전과 폴더 구조, OOP 에 대하여
- 이전 프로젝트에서는 NestJS 라는 프레임워크를 배우고, 어떤 식으로 동작하는지를 알았다면, 이번 프로젝트에서는 내가 실제로 서버 구축에 많은 기여를 하고, 어떤 식으로 폴더 구조를 정하고, 코드를 작성하고, 재사용성과 효율을 중시하면서, Interceptor, filter, Guard … 등을 이해하면서 프로젝트를 진행하였다.
- 모든 NestJS 의 기능을 사용하진 못했지만, 우리 프로젝트에서 필요한 기능은 라이브러리나 기본적으로 NestJS 의 life cycle 에 기반하여 코드를 작성하였다.
- 가장 만족스러웠던 작업은 Guard 이다. JWT 를 사용하여 로그인 상태를 확인하는 기능인데, NestJS 에서 제공하는 passport 를 사용하였고, 위 기능을 Guard 로 구현하였다. 매 Request 마다 If 문을 붙여서 헤더에 토큰을 검사하는 것보다 UseGuard 를 사용하여 직접 만든 Guard 를 이용했다는 점이 매우 뿌듯했다.
- 기존 NodeJS 를 이용했을 때보다 협업이나 코드 가독성, 재사용성 측면에서 모듈화, 추상화, 표준화된 코드를 제공하는 NestJS 가 훨씬 뛰어났다. 예를 들어 MVC 패턴, 의존성 주입 등등.. 이번 프로젝트를 통해서 OOP 의 매력에 빠져든 것 같다. 물론 자유도가 높은 NodeJS 도 충분히 매력적이긴 하지만, 나와 같은 신입 개발자들에게는 어느정도 틀이 잡혀진 프레임워크를 사용하는 게 맞는 것 같다.
❸ ERD 에 대하여
- 이건 그냥 스스로 고민이 되는 아주 작은 부분이다. 이번 프로젝트에서도 그렇고, 이전 프로젝트도 그렇고, 항상 ERD 를 작성할 때마다 고민이 많이 되는 것 같다. 효율적인 sql 쿼리를 보내도록 간결하게 구성해야할지, 아니면 프로젝트 이후에도 확장을 염두해 최대한 많은 정보를 담도록 구성할지에 대해서 고민이 많다. 또한 속성명을 짓는 것도 매우 큰 고민이기도 하고, 연관관계도 마찬가지다.
- 많은 걱정이 있고, 이번 프로젝트에서도 해결이 되진 않았다. 나 혼자서만 계속 고민한다면 해결되진 않을 것같다. 그렇지만 좋은 점은 매번 열심히 고민하니까, 개발하다가 뭔가 추가하거나 삭제하는 일은 없다는 것?
이게 맞는지는 모르겠지만, 문제가 없다면 내가 작성한 ERD 가 정답과 가깝다는 것이 아닐까라는 생각이 든다.
❹ 의사소통, 팀 협업에 대하여
- 나도 평소 소극적인 성격으로 활발하다기 보다는 차분한 편에 속한다. 말을 듣는 사람이고, 경청한다는 좋은 표현도 있지만, 다른 편으로는 먼저 분위기를 띄우기는 힘들다고 할 수 있다. 분위기를 활발하게 만든다면 더 좋을 것 같다고 생각했다. 이번 프로젝트에서 기획자님이 팀 분위기를 띄우려고 매우 힘내주셨다. 매번 회의마다 마이크를 켜고, 회의를 주도하셨다. 너무 감사했다.
- 백엔드 개발은 2명이고, 그 중 한 명이 ‘나’다. 다른 팀원과 나이 차이가 조금 있었다. 내가 어린 쪽으로. 팀원분도 활발하기 보다는 차분한 편이고, 회의에서도 딱히 말씀이 없으셨다. 나이도 있고, 성격상 조용하다고 말씀하셨다. 그래서 다른 직군과의 의사소통은 내가 담당했다. 이렇다보니, 평소에 조용하던 나도 카카오톡이나 회의에서도 말을 많이 하고, 타직군과 의사소통하면서 어떤 점이 이해하기 힘들고, 내가 어떻게 말을 해야 좋은지를 많이 생각하게 되었다.
- 특히 기획자와 디자이너는 개발쪽 용어 자체가 생소하다는 것을 알게 되었다. 내가 설명을 해줄 때는 이걸 풀어서 어떤 기능이고, 역할이고, 이걸 왜 했는지를 말할 수 있다. 하지만 발표자료를 만들 때, 백엔드 개발의 진행 결과, 서버 구조 등등에 대해서 내가 대본과 사진, 화면 구성을 띄워야된다. 대본을 작성하면서 ‘이걸 기획자님이 읽을 수 있을까? 없다면 하나하나 찾아야되는건가? 내가 써서 주는 게 좋겠다.’ 라고 생각이 들어서 대본에 용어를 쓰고, 괄호를 이용해 발음을 표시해줬다. 발표가 끝나고 이렇게 대본을 넘겨주셔서 너무 감사하다고, 이렇게 대본을 주셔서 인상깊었다고 칭찬해주셨다. 🔗백엔드 1분 발표대본
❺ AWS 과금 경험에 대하여
- 일단 처음에는 당황스러웠지만, 지금은 기분이 너무 좋다. AWS RDS Storage 85% 초과했다는 이메일을 받았고, 이후 과금되었다는 메일을 받았을 때 너무 기분이 좋았다. 사용자가 늘어나서 초과됐다는 게 나한테는 엄청난 경험이라고 생각한다.
- 혹시 EC2 나 RDS 를 켜놓은 게 초과의 원인인가라고 생각은 했지만, 한달 내내 EC2, RDS 1개씩만 켜뒀을 때는 과금이 되지 않는다고 한다. 아무래도…너무 기쁘다. 데이터 초과 때문에 RDS 요금이 나오다니. 최대 storage 임계량은 최고로 높여놔서 데이터베이스 스케일업은 필요없을 것 같다. 과금은 되겠지만, 기쁘게 낼 것 같다. 🔗AWS 프리티어를 넘어서 과금까지..!
Backend-Developer