[Kernel360] E2E 프로젝트 회고

E2E 프로젝트란?

E2E 프로젝트란 엔드 투 엔드(End-to-End)의 약어로, 전체적인 프로세스나 시스템을 포괄하는 프로젝트를 말합니다.

Kernel360에서의 E2E 프로젝트는 약 1달의 기간 동안 기획, 설계, 구현 배포까지의 웹 어플리케이션의 한 사이클을 경험하며 개발 스택에 대한 숙련도를 높이는 과정이었습니다.

 

부트업과 해커톤 프로젝트에서는 빠르게 아이디어를 도출하고 프로토타입을 만드는 경험을 했는데, 이제는 그 경험들을 기반으로 본격적인 서비스를 개발하고자 했기에 더욱 철저한 설계를 통해 빈틈없는 서비스를 완성하는 데 집중했고 서로의 아이디어와 역량을 최대한 발휘하고자 각자의 의견을 존중하며, 우리만의 독특한 서비스를 만들어보자로 E2E 프로젝트를 시작하게 되었습니다.

 

그렇게 E2E프로젝트 기간동안 "지역기반 물물거래 플랫폼 - 아나바다" 서비스를 구현하게 되었습니다.

 

아나바다(AnabadA)

프로젝트 소개

Anabada : 지역기반 물물 교환 플랫폼 | Notion

아나바다 프로젝트는 지역기반을 바탕으로 동을 기준으로 주민들과의 물물교환을 도모하는 지역기반 물물교환 서비스입니다.

 

 

자주 애용하고 있는 서비스의 당근마켓의 '나눔'이라는 키워드에서 아이디어를 얻어 물물교환까지 지원하는 서비스를 만들고자 기획하게 되었습니다.

 

그렇게 흥미로운 주제를 기반으로 같은 목표를 위해 모인 팀원들과 프로젝트를 시작했습니다.

시스템 아키텍처

 

Form 로그인을 시작으로 신규 회원의 접근성을 고려하여 카카오 OAuth2 로그인까지 도입하게 되었습니다.

인증 인가 작업은 무상태 아키텍처를 고려하여 JWT를 도입, Refresh Token을 캐시에 관리하기 위해 Redis를 도입하였습니다.

시스템의 핵심 기능인 위치정보는 카카오 Open API의 Kakao Map API를 활용해 사용자가 접속한 브라우저의 IP 주소를 기반으로, 어느 지역에서 로그인했는지를 판단하고 접속 위치정보를 가져올 수 있었습니다.

또한 완성된 서비스를 AWS EC2에 수동 배포하는 작업을 경험하였습니다.

 

DB ERD

요구사항 정의를 바탕으로 기능 명세서를 작성한 후, 부트업 및 해커톤 프로젝트에서의 경험을 토대로 데이터베이스를 설계하였습니다. 

 

API 명세서

API 명세서는 API를 문서화할 수 있는 오픈소스인 Swagger를 도입하여 API 명세서를 자동화했습니다.

API 명세서

 

 

개발 문화

E2E 프로젝트에서 가장 얻고 싶었던 것은 기획부터 배포까지 주어진 일정 내에 철저한 분업이 아닌  다른 팀원이 하는 일을 명확하게 알고 나의 업무를 다른 팀원이 바로 아는 진정한 협업을 경험하는 것이었습니다.

따라서 다음과 같은 팀 문화를 도입했습니다.

• 매일 오전 업무 시작 전 데일리 스크럼
• 코드리뷰를 통한 의견 반영 및 코드 품질 향상
• 일정 기간 페어프로그래밍을 통한 문제에 대한 다양한 접근성 확보
• 매일 있었던 일을 회고

마치 작은 스타트업 팀처럼 생각하고 행동하며 개발 문화에 경험을 쌓으며 협업할 수 있었습니다.

 

 

담당한 부분

프로젝트에서 로그인 부분을 담당하였습니다. 인증 인가 처리를 관련하여 서버가 아닌 클라이언트에 인가 정보를 저장하는 Token 기반의 인증 방식을 채택하여 반영하였고 토큰 방식이기에 무상태로 관리가 되었는데, Access Token과 Refrash Token을 적절히 사용하여 서비스 보안성을 향상 시켜려 노력했습니다.

 

처음에는 Refrash Token을 Access Token과 동일한 형식으로 사용하고 만료기간을 늘리는 방식으로 구현하였었는데 서버에서 전혀 회원의 인증정보를 보관하지 않기 때문에 위변조 된 토큰을 제어할 수 없다는 문제에 직면했습니다.

따라서  Refrash Token을 Access Token 형식으로 만들지 않고 유일한 키로 만들고 Redis에 Key를 유일키, Value로 Refrash Token토큰에 대한 사용자정보 및 만료기간을 저장하여 만약 위변조된 토큰의 경우 서버에서  Refrash Token정보를 삭제함으로써 Access Token 재발급을 무효화시켜 Token 정보를 제어할 수 있었습니다.

 

서버에 사용자 정보를 저장한다는 점에서 session 방식과 다를 것이 없다고 생각될 수 있으나, 매 요청마다 서버에서 인증정보를 확인하는 것이 아니라 Access Token이 재발급돼야 할 경우만 인증정보를 확인하여 처리비용을 줄였고 스케일 아웃을 고려하여 Redis에 저장하는 등의 방법으로 트러블 슈팅을 경험하였습니다.

 

해당 내용의 자세한 내용은 아래의 게시글에 정리했으니 궁금하신 분은 확인하셔도 좋을 것 같아요.

세션 인증과 JWT를 이용한 토큰 인증 방식

 

JWT 기반으로 로그인을 설계해 보았으니 다음 파이널 프로젝트에서는 세션 클러스터링 기반의 로그인 방식을 도입했으면 좋을 것 같습니다..

 

 

프로젝트 후기

아나바다 서비스의 기획부터 설계까지의 한 사이클을 경험하면서 프로젝트 및 데이터베이스 설계 능력 향상, AWS EC2 환경에서 수동 배포 경험, 로그인 인가를 위한 JWT 적용 등 웹 애플리케이션의 동작 과정 및 이해도를 더 높일 수 있었습니다.

웹 애플리케이션에 대한 경험도 좋았지만 팀 내 개발문화를 수립하여 진정한 협업이 무엇인지 맛볼 수 있었던 과정들이 가장 크게 와닿았던 것 같습니다.

팀 내에서 프런트엔드에 대한 이해도가 높았던 터라, 시간적 제약 및 러닝커브를 고려하여 프론트엔드 설계를 주로 맡아 진행했습니다. 팀원분들께 템플릿 및 가이드를 제공하고 동작 방식을 설명드렸었는데, 익숙하지 않으셨을 프론트엔드에 대해 팀원들이 매우 수월하게 따라와 주시고 UI/UX에 대한 요소도 칭찬해 주셔서 큰 동기부여가 되었었던 좋았던 기억이 있습니다. 물론 그 과정에서 백엔드에도 더 집중하려고 노력했습니다!

 

부족하거나 아쉬웠던 부분은 회고하며 다음 프로젝트 때 잘 녹여낼 수 있도록 준비하도록 하겠습니다. :)

 

아래의 Github에서 프로젝트에 대한 더 자세한 내용을 확인하실 수 있습니다.

GitHub - Kernel360/E2E1-Anabada: 지역기반 물물교환 플랫폼 - 아나바다!