한 주간 flask를 이용한 풀스택 팀 미니 프로젝트를 진행했다.
후기와 함께 그 속에서 본인은 무얼 했고 무엇을 느꼈나 간단하게 기록하였다.
시작 전
프로젝트 주제가 정해지고 팀원이 만든 와이어프레임을 통해 UI틀을 파악하여 그 속에서 요구사항을 도출했다.
회원은 다이소 상품리뷰를 등록할 수 있다.
사용자는 등록된 상품목록을 조회할 수 있다.
사용자는 등록된 상품 하나에 대해 상세조회 할 수 있다.
요구사항과 와이어프레임을 기반으로 단순한 정적 UI 부분을 제외한
백엔드에서 동적으로 가져오거나 처리되어야 되는 것이 무엇인지 파악하여 API 명세를 만들었다.
Api
| METHOD | URI | Request | Response | Description |
|---|---|---|---|---|
| GET | /api/reviews | {reviews: [{id: number, title: string, rating: number, thumnailImage: string, userId: string}]} | 리뷰 목록 조회 | |
| GET | /api/reviews/{id} | {'id': number} | {id: number, title: string, contents: string, rating: number, price: number, images: string[], userId: string} | 리뷰 상세 조회 |
| POST | /api/reviews | {title: string, contents: string, rating: number, price: number, images: string[]} | {id: number} | 리뷰 등록 |
회원관리 부분을 제외한 api 명세이다.
서비스 규모가 작고 구조가 단순해 운이 좋게도 한 페이지에 하나의 api가 사용되는 형태라 도출하기 쉬웠던 것 같다.
api는 어플리케이션을 위한 인터페이스 즉 서비스를 위해 필요한 특정한 동작의 규칙 또는 틀이라고 생각했기 때문에
팀원들에게 맡은 페이지를 동작시키기 위한 백엔드 api를 개발할 때
위에 명시된 URI 규칙과 요청 데이터, 응답 데이터 이름과 타입을 반드시 준수하라고 말을 했던 것 같다.
개발하는 팀원 모두가 각각의 api들이 위와 똑같은 형태로 존재함고 사용되어야 함을 알고있어야 할 뿐 아니라
사용하는 모든 사람이 명세를 보고 의도를 파악할 수 있어야 하기 때문에 규칙과 질서가 있어야 한다고 생각했다.
예: [GET] /api/reviews/{id} => api인데 조회(GET)를 하네 review라는 자원에 대해, 그것의 id 하나로 한정지어서, 그럼 저런 응답을 얻네?
예: [GET] /api/reviews => api인데 조회(GET)를 하네 review라는 자원에 대해, 그럼 저런 응답을 얻네?
예: [POST] /api/reviews => api인데 생성(POST)를 하네 review라는 자원을 내가 요청한대로
다행히도 통용되는 규칙을 따르기 매우 쉬운 형태였기에 최소한 URI 명명은 나름대로 restful했다고 생각했다.
api라는 접두사를 붙이는 것이 궁금했던 팀원이 있어
사용하는 사람 또는 우리가 이 동작이 api 역할을 함을 정확하게 인지할 뿐 아니라
페이지 라우팅 처리를 해주는 동작과 구분지어져 동일한 네이밍일 경우에 대한 혼란을 막을 수 있지 않을까 라고 대답했던 것 같다.
개인적인 경험으로는 웹 서버에서 백엔드 쪽 api 요청을 대리로 받고자 할 때 통일된 접두사 규칙이 있을 경우 관리가 수월했던 점도 있는 것 같다.
JWT 토큰 인증 구현
본인은 팀에서 정한 핵심 요구사항 개발이 아닌 회원 인증 처리 부분을 개발하게 되었다.
라이브 세션을 듣고 알던 것을 바탕으로 정리한 글을 참고하며 파이썬 쪽에서 어떻게 흐름을 만들어갈지 생각해본 것 같다.
근데 사실 라이브 세션에서 보았던 인증 흐름 자체가 프로젝트에도 부합했고
코드만 봐도 의도가 너무 명확해서 파이썬을 잘 모르는데도 거의 복붙 수준으로 따라서 적용할 수 있었던 것 같다.
조금 달리 적용한 것은 인증 성공 후 쿠키를 서버사이드에서 만들어 응답에 실어보낸다는 정도?
로그아웃은 그냥 프론트쪽에서 쿠키를 없애는 식으로 해버렸지만 이 부분도 로그아웃 api를 서버에 따로 두고 요청하게끔 한다면 서버쪽에서만 쿠키를 관리할 수 있는 구조가 되지 않을까 생각한다.
사실 쿠키로 중요정보를 전달해야할 경우 ssl 인증서가 적용된 상태로만 통신할 수 있게하는 secure 옵션과
클라이언트 스크립트에서 쿠키를 핸들링하지 못하게 막는 httponly 설정을 해주는 것이 좋은데
서버에서 쿠키 생명을 모두 관리하게 한다면 다음과 같은 옵션이 부여됨에도 클라이언트는 영향을 받지 않을 수 있지 않을까라고 생각한다.
스크립트로 핸들링 하지 못하게 막는다고 반드시 안전한 건 아니지만 (이글참고) 인증 정보를 넘기는데 사용하는 것에 대한 최소한의 예의이지 않을까!
CI/CD
사실 각자 팀원들이 처음에 맡은 필수 요구사항들을 구현해갈 때 쯤 부터 머지 된 후
각자 엔드 투 엔드로 직접 테스트 해보는 시간이 있을 것이라고 판단했다.
팀원 분 중 PM 하시던 분이 있어서 좋았다!
그래서 필수 기능이 완료될 시점 쯤에 main 브랜치에 머지될 때 마다 자동으로 ec2 인스턴스에 배포되도록 설정했다.
간단하게 docker와 github actions 를 사용해 워크플로우를 구성했다.
사실 팀 미니 프로젝트 때 필요할 것 같아서 입학 시험 때 미리 연습했어가지고 시간을 크게 안들이고 적용했던 것 같다.
정말 좋았던 건 사소한, 정말 스타일적인 면 하나라도 즉시 팀원의 피드백이 발생했을 때 수정하여 즉시 적용할 수 있었다는 점이다.
Feedback
우리팀의 목표는 기본에 충실하고 흐름을 파악하여 개발하자 였다.
잘 안되는 것은 한땀한땀 디버깅하며 안되는 지점을 찾고 무엇이 문제인지 고민하고 해결책을 찾아 해결했고
이해가 안되는 부분은 UI부터 DB까지 어딜 거쳐서 어떻게 반영되나 확인해본 것 같다.
그 목표와 결과를 발표 때 멘토님들이 잘 알아주셨는지 좋은말씀을 많이 해주신 것 같다!
하나의 파일에 다수의 추가가 발생함에 따른 머지 충돌을 개발 시작 단계에서 고민했었다.
따라서 백엔드쪽 api 하나하나 별로 파일을 분리하는 구조로 개발하게끔 팀 내에서 협의했는데 이 부분에서 지적을 받았다. 사실 이 때 좀 끊겨서 잘 못들었는데 그 부분이 확실할 것이다
사실 100% 전적으로 그 의견에 동의했다.
하나의 리소스에 대한 처리들은 하나의 파일에 있어야 한다.
예를 들면 리뷰에 대한 조회, 단일조회, 수정, 삭제 등은 하나의 파일에 있어야 코드 응집도가 높아져 관리가 편하고 가독성이 높을 것이라고 생각했다.
정말 좋은 피드백을 주신 덕분에 한번 더 생각해보게 되었다!
아쉬운점
유효성검사
필수 요구사항 구현을 완료했음에도 매우 크게 아쉬움을 느꼈던 부분이다.
시간 할애를 좀 더 해서라도 post 요청에 대한 백엔드 api 유효성 검사를 확고하게 했어야 했다.
사실 프론트엔드 쪽 유효성 검사는 사용자 경험도를 향상시키는 것 뿐이지 실제 validation이 백엔드에서도 반드시 이루어져야 한다고 생각한다.
이 부분은 프로젝트 종료 후 발표에서 언급하며 왜 아쉬움을 크게 느꼈는지 직접 보여드렸다.
코드리뷰
사실 처음에 팀장으로서 가진 이상은 pr 하나하나에 대해 모두가 코드리뷰를 하는 것이었다.
코드리뷰 부분은 멘토님께서도 프로젝트 중간단계에서 피드백해주셨던 내용이기도 하다.
코드리뷰를 통해 본인이 개발하지 않은 요구사항에 대해서도 흐름을 이해하고 넘어갈 수 있을 뿐 아니라
코드리뷰 자체만으로도 코드를 작성하는 능력이 향상되지 않나 생각한다.
부가기능
조회와 생성만 있는 간단한 api였다.
시간이 있었다면 두명 정도가 각각 리뷰 수정, 삭제를 구현하고 모두가 이를 같이 확인하며 흐름을 파악하는 시간을 가졌다면 좋았을 것이다.
1주차 Review
솔직히 좀 힘들었다. 3일만에 팀으로 같이 무언가를 기획하고 설계하고 개발해서 결과를 내 본 경험이 없었다.
하지만 정말 재밌었고 정말 필요한 과정이라고 생각했다.
당연히 100%의 결과라고는 생각하지 않지만 모두가 100% 이상을 쏟아냈기에 얻을 수 있었던 완성이었다!
끊임없이 노력하고 시도해 결국 해냈던 팀원들 모두에게 감사했다!
github repo
