[Codeit Resources] 코드잇 인턴 프로젝트 회고

시작하며...

사내 리소스 관리 서비스인 "Codeit Resources" 프로젝트가 끝이 났다.

해당 프로젝트는 코드잇 미래 내일 일경험 인턴에서 진행했던 프로젝트로 총 10명의 인턴 인원에서 5명씩 두 팀으로 나뉘어 진행했다.

 

운이 좋게, 내가 속한 팀의 서비스가 한 달이라는 인턴 기간 안에 프로젝트의 MVP 기능을 모두 구현하였고 사내 직원분들에게 만족을 얻어내었다.

 

그러나 실제로 해당 서비스를 사용하기 위해서는 기존 사내 리소스들을 예약하던 "구글 캘린더"와 연동을 해야 된다는 요구사항이 있었다.

그래서 인턴 기간이 끝난 후, 약 2주 동안 추가 기능 개발을 진행하게 되었고 무사히 개발을 잘 마치게 되어 사내에 실제로 오픈되어 사용하고 있다.

 

그래서 해당 프로젝트를 진행하면서 나는 어떤 부분을 개발 했고 개발하면서 어떤 고민을 했는지 기록하기 위해 글을 작성하게 되었다.

 

프로젝트 소개

이미지 내가 만들었당ㅎㅎ

간단하게 소개하자면 "Codeit Resources" 서비스는 사내에서 회의실과 좌석을 예약하는 서비스이다.

 

역할 분담

나는 프론트엔드 개발자를 준비하고 있지만, 이번 프로젝트에서 백엔드를 맡게 되었다.

 

그동안 프론트엔드만 했었기 때문에 새로운 도전을 하고 싶었고(사실 예전에 백엔드 해봤음), 웹 개발에 있어서 전반적인 경험을 통해 웹 개발 지식을 얻고 싶었기 때문에 백엔드를 선택하게 되었다.

 

그러나... 우리가 일반적으로 생각하는 Spring이나 express와 같은 백엔드가 아닌 서버리스 서비스를 사용했기 때문에 백엔드 개발이 예상보다 빠르게 끝났고, 프론트엔드 부분까지 구현하게 되어 결론은 "풀스택"을 하게 되었다.

 

그래서 우리 팀은 프론트엔드 2명, 풀스택 2명, PM(풀스택) 1명으로 구성되어 있다.

 

그 중에서 나는 백엔드에서는 Team, User 테이블을, 프론트엔드에서는 로그인(유저 로직), 멤버 관리 페이지, 팀 관리 페이지를 담당하였다.

 

협업 방식 - 데일리 스크럼

한 달이라는 정해진 기간이 있고 모든 기능을 완수해야 했기 때문에 매일 회의 시간에 데일리 스크럼을 작성하고 각자 진행 상황을 공유하였다. (글로 적고 말로 함)

데일리 스크럼

 

기술 스택

기술 스택은 추가 기능인 Google Calendar API 연동 작업으로 인해 기술 스택이 좀 달라지게 되었다. 그래서 그와 관련된 Next.js와 NextAuth.js 등 기술 스택 선정 이유는 나중에 천천히 설명할 예정이다.

[1] 초기 기술 스택, [2] 추가 기능 이후 기술 스택

 

AWS Amplify Gen2

AWS Amplify Gen2

이번 프로젝트에서는 AWS Amplify Gen2라는 기술을 사용하게 되었다. (지금까지 이런 기술이 있는지도 몰랐다...)

 

처음 사용해보는 기술이라 초반에는 어려웠지만, 프론트엔드 개발자가 인프라 구축 없이 간단하게 풀스택을 개발할 수 있게 도와주는 아주 유용한 기술이었다.

 

AWS Amplify 선택한 이유?!

사실 팀원들끼리 자의적으로 선택한 기술이 아니라 우리에게 두 가지 선택 사항이 주어졌다.

1. Next.js API Routes + MongoDB
2. AWS Amplify + DynamoDB

두 가지 기술 중에 어떤 것이 프로젝트에 적합하고, 해당 기술 스택을 선택해야 원활하게 구현을 해낼 수 있을 지 많은 고민을 하였다...

 

결국 최종적으로 AWS Amplify + DynamoDB 조합을 사용하여 개발하게 되었다.

 

만약 Next.js API Routes를 사용하게 될 경우에는 인증 시스템 구축, 데이터베이스 연동 등 인프라 설정을 모두 직접 했어야 했다. 하지만 AWS Amplify는 서버리스 웹 어플리케이션을 구축할 수 있게 도와주는 도구로 프론트엔드 개발자가 백엔드 지식이 부족해도 풀스택 어플리케이션을 개발할 수 있다.

 

그래서 팀원 5명 모두 프론트엔드 개발자였기 때문에 직접 인프라를 구축하는 작업은 어렵다고 판단을 하여, 한 달이라는 기간 내에 비즈니스 로직 구현에 집중하고 안정적인 서비스를 구축할 수 있는 AWS Amplify를 선택하게 되었다.

 

결국 이 결정이 프로젝트의 성공적인 완수로 이어졌다. 👍

 

AWS Amplify 단점

물론 무조건 장점만 있는 것은 아니다...

 

AWS Amplify Gen2가 올해 릴리즈된 새로운 기술이다 보니 참고할 수 있는 자료가 매우 제한적이었다... 공식문서 이외에는 커뮤니티 자료나 실제 사용 사례를 찾기 어려웠고, 특히 한국어로 된 자료는 거의 없었다. 그래서 이번 프로젝트에서는 항상 공식문서를 옆에 끼고 개발을 했었다. 🤣

 

다행히 프로젝트가 단순한 CRUD 작업이 주를 이뤘기 때문에 Amplfiy로 충분했지만, 조금 더 복잡한 쿼리가 필요한 프로젝트였다면 어려움을 겪었을 것 같다.

 

DynamoDB, Cognito, Storage

DynamoDB, Cognito, Storage

AWS Amplify를 사용하게 될 경우에

데이터 저장을 위한 DynamoDB, 사용자 인증을 위한 Cognito, 파일 업로드를 위한 S3(Storage) 기능을 간단하게 연동해서 사용할 수 있다.

 

DynamoDB

AWS Amplify를 사용하면 스키마 기반의 DynamoDB 테이블 생성과 GraphQL API 연동이 자동화되어 개발 생산성을 크게 향상되었다.

 

조금 더 자세하게 설명해보자면

1. 스키마를 작성하고 push 함.
2. DynamoDB 테이블이 생성되거나 업데이트.
3. 테이블과 연결된 AppSync GraphQL API가 자동 설정.
4. 클라이언트에서 사용할 GraphQL 쿼리 자동 생성.

쿼리 자동 생성

 

Cognito

서비스 개발에 있어서 가장 어려운 부분이 바로 유저 관련 로직이라고 생각한다. 🤯

 

하지만 Cognito를 사용하게 되면서 access token 발급 및 자동 재발급과 비밀번호 암호화 등 기본적으로 지원하기 때문에 적은 리소스를 투자하여 유저 관련 로직을 구현할 수 있었다.

 

로그인, 회원가입, 비밀번호 찾기, 비밀번호 재설정, 탈퇴하기 등 기본적인 메서드를 제공하기 때문에 간단한 풀스택 개발을 할 때 정말 유용한 것 같다.

 

그러나 난 물론... 그 메서드를 사용하기에 적합한 프로젝트가 아니었기 때문에 기본 메서드 대신 다른 방식을 사용하여 구현했다. 😂

 

Tailwind CSS

Tailwind CSS

Emotion과 Tailwind CSS 중에서 많이 고민을 했다.

 

왜냐하면 팀원 모두 Tailwind CSS를 선호했지만, 사실 원래 이 프로젝트는 모노레포 구조로 하나는 web, 하나는 app이었다. 그래서 app인 React Native에서도 지원하는 라이브러리를 선택했어야 했다.

 

Emotion은 공식적으로 React Native를 제공하지만, Tailwind CSS는 제공하지 않았지만 대신 비슷한 라이브러리가 있다는 것을 알게 되었다.

 

또한 한 달이라는 짧은 기간이 있었고 Emotion을 사용해 본 팀원이 없었기 때문에 러닝커브와 기간을 고려하여 결국 Tailwind CSS를 선택하게 되었다.

 

React Hook Form + Zod

React Hook Form, Zod

 

프로젝트 요구사항을 보면 회의실을 예약하는 등 입력 폼을 구현해야 되는 부분이 많았다.

 

그래서 내가 팀원들에게 적극적으로 React Hook Form과 Zod를 사용하자고 권장했다. 해당 라이브러리를 안 써본 팀원이 있어 React Hook Form으로 컴포넌트 분리도 쉽고, Zod로 유효성 검증하는 것도 쉽다는 것을 적극적으로 어필했다. 

 

다행히 팀원 모두 긍정적인 반응이었고, 한 번쯤 React Hook Form를 사용해보고 싶다고 해서 이 기술도 채택되었다.

 

TanStack Query

TanStack Query

AWS Amplify를 사용하고 있고, GraphQL 쿼리를 사용하는 방식으로 API 요청을 하는데 이것도 TanStack Query 사용 가능할까? 걱정했었는데 다행히 사용 가능했다. 😌

 

TanStack Query는 직관적이고 깔끔한 쿼리 Hook을 제공하지만 무엇보다도, 데이터를 캐싱해 주는 기능이 너무 유용하다...

 

real time이 중요하지 않은 서비스에서는 캐싱을 통해 특정 시간 내에 중복 요청을 해도 캐싱된 데이터를 사용해서 서버 요청도 줄일 수 있고, 데이터가 바뀔 시점에 쿼리 무효화해서 데이터를 다시 요청하여 새로운 데이터를 가져올 수 있게 해준다.

(최고최고)

 

Jotai

Jotai

상태 관리 라이브러리로는 Jotai를 선택하였다.

 

우선 프로젝트 규모가 크지 않았고, 팀원 모두 Jotai가 익숙하고 간편했기 때문에 선택하게 되었다.

 

React

React

인턴 기간 이후에 추가 기능 구현 때문에 React에서 Next.js로 마이그레이션 하게 되었지만... 처음엔 React를 선택하게 되었다.

 

먼저 해당 프로젝트는 사내에서만 사용하는 서비스였기 때문에 SEO가 중요하지 않았고, 초기 로딩 속도도 크게 중요하지 않을 것이라고 판단했다.

 

그리고 무엇보다도 원래 이 프로젝트는 app과 web 모노레포 구조였기 때문에 React Native와 가장 유사하고 비슷하게 구현할 수 있는 React를 선택하게 되었다.

 

또한 AWS Amplify라는 익숙하지 않은 기술을 Next.js에서 사용했을 경우에 예상치 못한 오류가 발생할 수 있었기 때문에, React를 선택하게 되었다.

 

프로젝트 초기 세팅

기술 스택 선정을 완료하고 app과 web 동시에 개발하기 위해 모노레포 구조를 선택하였다.

 

그러나 프로젝트를 진행하면서 두 개 동시에 개발해서 다 끝내지 못하는 것보다는 선택과 집중을 해서 web 하나라도 다 완성하는 게 좋다고 생각하여 결국엔 web만 개발하게 되었다. (Next.js로 마이그레이션 하면서 모노레포 구조를 없애고 web만 개발함...)

 

Storybook 배포

Storybook을 PR에서 배포하는 작업은 해봤기 때문에 금방 해결할 줄 알았다.

 

그러나 모노레포 구조였기 때문에...😂 app과 web에서 모두 Storybook이 작성되고 공유 폴더에서도 Storybook이 작성되게 하기 위해 많은 시간을 투자하게 되었다. (모노레포 구조 너무 어려워요... 하지만 경험해 볼 수 있어서 좋았음!)

 

결국 공유 폴더와 web 폴더 내에서만 작성이 되고 실행이 되게 하였다.

 

그리고 배포할 때에도 Chromatic URL을 제대로 읽어내지 못해 이것도 추출하는데 시간이 오래 걸렸다...

재작성n

Chromatic URL 추출

추출하기

web 디렉토리 내에 package.json에 chromatic 배포하는 명령어가 있기 때문에 run에 저런 명령어를 입력했다.

그리고 실행된 결과를 chromatic_output.txt 라는 파일에 저장하여 콘솔에 출력하였다.

 

chromatic_output.txt에서 Chromatic으로 배포된 URL을 찾기 위해 정규식을 사용했고, 찾아낸 후에 GitHub Actions 환경 변수로 등록하였다.

 

Tailwind CSS 설정

이전 프로젝트에서 Tailwind CSS를 사용할 때 pxr 단위를 적용하였는데 너무 편리했다. 😊

 

피그마에서는 기본적으로 px 단위를 적용하는데 이를 다시 tailwind에서 제공하는 단위로 계산하기까지 좀 시간이 걸리는 번거로움이 있다..

 

만약 padding 16px이라면 tailwind에서는 p-4 이렇게 했어야 됐지만, pxr 단위를 적용하게 되면서 px 단위처럼 p-16 이렇게 사용하면 자동으로 rem으로 변환되기 때문에 실제로는 1 rem이 된다! (너무 간편~)

 

백엔드 스키마 작성

데이터베이스 구조는 크게 User, Resource, Reservation 이렇게 세 가지가 있었고 백엔드 팀원은 3명이었기 때문에 각자 하나씩 맡았고 내가 User를 담당하게 되었다.

 

그런데 "멘토 - 디자이너 - 팀미팅"에서 내가 멤버에게 속한 부서 이름도 보여주면 좋을 것 같다고 제안하게 되어, 해당 기능이 디자인에 추가되었고 이 부분을 구현하게 위해 Team 테이블이 추가되었고 User와 관련된 부분이었기 때문에 이것도 내가 담당하게 되었다.

 

User 스키마 작성

User 스키마

 

Team 스키마 작성

Team 스키마

 

스키마 연결 어떻게 하면 좋을까?

User는 여러 개의 Team에 속할 수 있고, 한 Team에는 여러 명의 User가 속할 수 있는 다대다 구조이다.

 

이 부분에서 많은 고민을 했다. 사내 서비스인데 직원이 부서를 바꾸는 경우도 별로 없고 부서가 사라지는 경우도 별로 없다. 결국 주로 조회를 위한 용도로 사용되고 데이터가 변경될 일은 별로 없다.

 

그래서 빠른 조회를 위해 다대다 연결 대신, User 테이블에 teams 속성을 배열 형태로 두어 이 안에 속한 team의 id를 넣는 방식으로 개선하였다.

 

그리고 Team 테이블에서 해당 팀에 속한 User의 id도 넣으려고 했지만 이제 동기화가 번거롭다는 문제가 있었다. 그리고 해당 Team에 속한 User를 보여주는 것보다는 특정 User가 속한 Team을 보여주는 것이 목적이기 때문에 User 테이블에만 teams 속성을 추가하여 구현하였다.

 

백엔드 API 작성

다른 프론트엔드 팀원들도 데이터를 요청하기 편하도록 백엔드 API 함수를 작성하였다. 마치 axios로 API 함수 작성해서 사용하는 것과 비슷해서 직관적으로 사용하기 편리했다.

API 작성

 

공통 컴포넌트 구현

사실 프론트엔드 담당이 아니라서 공통 컴포넌트를 구현한 것이 거의 없지만...

한 번쯤 구현해보고 싶은 UI였고, 이전에 만들었던 컴포넌트와 달리 발전된 부분이 있었기 때문에 이것도 글을 작성하게 되었다.

 

공통 Input 컴포넌트

Input 컴포넌트

Input UI

우선 Input에서 label이 위로 올라가는 애니메이션을 적용해보고 싶었다.

 

해당 디자인은 Tailwind CSS의 peer라는 선택자를 사용해서 placeholder가 비어있을 때, focus 되었을 때 label이 이동하도록 구현하였다. 

 

Input Props

props

Input 컴포넌트가 "input" 태그의 속성을 상속받아서 확장성 높은 컴포넌트를 설계했다.

 

그리고 이전까지 React Hook Form의 register를 연결하기 위해서 forwardRef를 사용했었다. 왜냐하면 React Hook Form은 비제어 컴포넌트 방식으로 동작하고, 해당 인풋 필드를 dom으로 접근해서 register를 사용하기 때문이다.

 

forwardRef를 사용하게 되어 코드가 복잡해지는 단점이 있었는데...

이번에 프로젝트를 진행하면서 React Hook Form에서 제공해 주는 useFormRegisterReturn이라는 타입을 알게 되었다.

 

그래서 register의 타입을 지정해 주었기 때문에 굳이 forwardRef를 사용할 필요가 없어졌다! (완전 편함)

 

User 로직 구현

사내 서비스이기 때문에 회원가입 기능은 존재하지 않고 관리자가 직접 멤버를 추가해서 그 멤버가 로그인하는 방식이었다.

 

• 멤버 추가 - ADMIN 기능
  • 사내 이메일, 이름, 부서, 프로필 이미지, 관리자 여부
  • 고정된 임시 비밀번호
• 멤버 삭제 - ADMIN 기능
• 멤버 수정 - ADMIN 기능
  • 사내 이메일, 이름, 부서, 프로필 이미지, 관리자 여부
• 로그인
• 비밀번호 찾기
• 비밀번호 수정

 

멤버 관리 기능 (추가, 삭제, 수정)

초반에 Cognito의 기본 메서드를 사용해서 임시적으로 회원가입, 로그인을 구현하였다. 그러나 이 로직은 "회원가입 -> 이메일 인증 -> 로그인" 흐름으로 동작한다.

 

관리자가 사내 멤버를 추가하는 건데 이메일 인증과 같은 작업은 불필요하다 느껴졌고, 멤버 추가를 위해 기본적으로 제공하는 Cognito 메서드를 사용해서 구현하기 매우 어려워 보였다.

 

그래서 이를 해결하기 위해 Cognito에 접근할 수 있는 AWS SDK를 사용하여, 직접 cognito user pool에 유저를 추가하고 수정하고 삭제하는 작업을 수행하였다.

 

이 부분에 대한 내용은 따로 게시물을 작성하였다.

[AWS Amplify Gen2] Cognito, AWS SDK를 활용한 유저 기능 구현

 

역할에 따른 렌더링

jotai

인증 여부, ADMIN에 따른 렌더링을 해야 되기 때문에 Jotai를 사용해서 구현하였다.

 

페이지 제작

멤버 관리 페이지

너무 자세하게 설명하려면 양이 너무 많기 때문에 간단하게 설명하자면, searchParam 값으로 멤버를 렌더링 했다. 그리고 TanStack Query 사용해서 캐싱되었기 때문에 같은 탭을 또 접근하면 캐싱된 값을 사용하여 빠르게 렌더링 된다.

멤버 관리

 

팀 관리 페이지

대단한 기능은 없다... 팀 삭제하기 누르면 팀 이름을 입력받아 신중한 선택을 할 수 있게 도와주는 정도..?

팀 관리 페이지

 

최종 발표

약 한 달의 기간이 지나고 최종 발표 날이 오게 되었다.

 

핵심 기능인 회의실 예약, 좌석 예약을 맡은 팀원들은 수정해야 될 내용이 많았지만, 나는 내가 맡은 부분 기능을 다 구현했기 때문에 발표 자료 제작에 주도했다. (어려운 기능 너무 잘 만들어주셔서 감사해용...)

최종 발표일은 아니고 찐 마지막 날...

 

4L 회고

최종 발표일은 수요일이었고, 진짜 마지막날인 금요일에는 각 팀 별로 4L(Liked, Learned, Lacked, Longed for) 회고를 진행하였다.

 

처음엔 회고 시작 시점 기분과, 회고를 마친 뒤 기분에 대한 점수를 매겼다. 그냥 서로 그동안 있었던 일을 말하는 시간인데 솔직한 감정을 들을 수 있었고 다시 한번 돌아볼 수 있는 계기가 되어 도움이 많이 되었다.

 

본격적으로 4L 회고를 시작했다. Liked, Learned, Lacked, Longed for 를 기준으로 각자의 의견을 포스트잇에 작성하였다. 그리고 비슷한 의견끼리 연결하여 시간 순으로 배치하였다.

배치

그리고 이제 긍정적인 내용엔 파란 스티커를, 부정적인 내용엔 빨간 스티커를 붙여 투표를 진행하였다.

 

가장 많은 표를 받은 4가지 주제에 대해 팀원들과 함께 소통하고 논의하는 시간을 가지게 되었다. 그래서 각자 해당 주제에 대한 의견을 말하면서 앞으로의 Action Plan을 도출하는 방식으로 진행하였다.

4가지 주제

이후에는 롤링 페이퍼를 작성하였다.

 

처음 해보는 회고 방식이었는데 4개의 카테고리가 나뉘어 있어서 모든 영역에 대해 골고루 살펴보고 다양한 관점에서 피드백을 얻을 수 있어서 좋았다!

 

그리고 부족했던 점을 쉽게 파악할 수 있었고 함께 개선점을 도출할 수 있어 앞으로 어떤 방식으로 진행하면 좋을지 목표를 설정할 수 있었다.

 

이제 끝이다!!!

한 달간 여정이 끝나게 되어 아쉬웠지만 한편으로는 프로젝트가 끝이 나 후련한 기분이 들었다! 🤗

 

MVP 기능을 구현하였기 때문에 실제 사내에서 서비스를 사용하고 직원분들의 피드백을 얻고 싶었지만, 실제 직원들이 사용할 수 있게 하기 위해서는 조건이 필요했다. 바로 "Google Calendar"와 연동해야 되는 조건이었다!

 

기존 사내에서 회의실을 예약할 때 Google Calendar를 사용하고 있었기 때문에, 우리의 서비스가 실제로 사내에서 사용되려면 Google Calendar 연동이 필수였다. 

 

사실 나는 여기서 프로젝트를 그만하고 싶었지만... 프로젝트가 사내에서 사용된다는 점과 추가 기능을 개발하면서 기술적 도전 과제를 해결하며 성장할 수 있을 것 같아 팀원들과 함께 계속 프로젝트를 이어나가기로 했다. 💪

파이팅!

 

추가 기능 구현 시작

Google Calendar API와 연동을 하기 위해서 서버가 필요하다.

 

현재 AWS Amplify를 사용하고 있고 여기서 제공하는 Lambda 서버가 있지만... 프로젝트를 구현하는 동안 Lambda와 연동이 잘 되지 않아 포기하고 사용하고 있지 않았다.

 

Next.js로 마이그레이션 한 이유

Next.js

그래서 백엔드 서버를 구축하기 위해 어떤 방법을 사용할 수 있을지 고민을 하다가 Next.js의 API Routes 기능을 사용해서 백엔드 서버로 이용하자고 했다.

 

API Routes는 서버리스 환경에서 서버 측 코드를 작성할 수 있도록 지원하는 기능으로, 외부 서비스와 통신하기 위해 적합해 보였다.

 

추가적으로 Next.js로 마이그레이션 할 때 Next.js의 App Router인 14 버전이 아닌 Page Router를 선택하게 되었다. 왜냐하면 App Router 같은 경우는 컴포넌트를 서버 컴포넌트, 클라이언트 컴포넌트를 고려해서 설계해야 하기 때문에 빠르게 마이그레이션 할 수 있는 Page Router를 선택하게 되었다.

 

내가 맡은 기능

Google Calendar 연동을 하기 위해서는 Google 로그인이 필요하다. 나는 기존에 User 관련 로직을 담당하였기 때문에 자연스럽게 Google 로그인을 맡게 되었다.

 

Google 로그인 구현

구글 로그인

Cognito를 활용한 로그인 방식

기존 인증 방식을 Cognito로 사용하고 있었기 때문에 Cognito로 Google 로그인을 구현을 했다. Google Calendar 연동을 하기 위해서는 로그인 시 구글에서 발급해 주는 Access Token이 필요했다.

 

그러나 Cognito를 사용한 로그인은 Access Token만 발급해 주고, Refresh Token은 최초 로그인에만 발급되는 현상이 있었다. 그래서 Access Token 만료 시, 자동으로 재발급하지 못하고 매번 재로그인해야 되는 번거로운 상황이 발생할 것 같았다. 🥲

 

그래서 조금 더 유연한 방법을 사용하기 위해 NextAuth.js 라이브러리를 사용하여 로그인 방식을 변경하였다.

 

NextAuth.js를 활용한 로그인 방식

NextAuth.js 라이브러리를 사용하여 Google 로그인을 구현했고, Cognito와 다르게 Access Token과 Refresh Token 모두 발급이 잘 되었고, 로컬 스토리지나 쿠키에 Token을 저장하는 방식이 아닌 메서드를 통해 가져오는 방식이라 보안 측면에서도 우수했다.

 

그런데... 배포 환경에서 환경 변수를 제대로 읽어 들이지 못한 문제가 발생하였다. 알고 보니 AWS Amplify와 Next.js가 환경 변수를 처리하는 방식이 달랐던 것이었다. 그래서 Next.js가 빌드 전에 환경 변수를 읽을 수 있도록 수정하여 문제를 해결하였다.

 

Cognito로 Google 로그인 과정부터 NextAuth.js에서 발생한 환경변수 문제까지 전 과정에 대한 내용은 따로 글로 작성했다.

[AWS Amplfiy Gen2/Next.js] NextAuth.js 구글 로그인 구현기 (feat. Cognito)

 

일관성 문제 해결

NextAuth.js로 로그인하고, Cognito로 유저 인증을 할 경우 데이터 동기화 하는 것이 복잡할 것 같고 충분히 NextAuth.js로만 유저 로직을 구현할 수 있을 거 같아 기존 Cognito 방식을 제거하게 되었다.

 

원래 이전에는 멤버의 Role을 수정하기 위해서는 User 테이블 값도 변경하고, Cognito User Pool에 저장된 값도 수정해야 한다. 또한 멤버를 삭제할 때에도 User 테이블에서 제거해야 할 뿐만 아니라 Cognito User Pool에서도 해당 멤버를 제거했어야 한다.

 

이렇게 상태 값을 두 곳에서 관리를 하게 되다 보니 추후에 일관성 문제가 발생할 수 있을 것 같았다.

 

하지만 이제 Cognito를 사용하지 않게 되다보니 유저 상태를 User 테이블 한 곳에서만 관리할 수 있어 일관성 문제를 해결할 수 있었다. 👍

 

바뀐 멤버 관리 페이지

[1] 인증된 유저, [2] 미인증 유저

새롭게 User 테이블에 isValid 값을 추가하였다.

 

그래서 처음 멤버를 추가하면 isValid 값이 false 이기 때문에 로그인 대기 상태가 되며 이름, 이메일, 팀, 역할 모두 수정 가능하다.

 

만약 해당 유저가 로그인을 하게 되면 IsValid값이 true가 되면서 로그인 완료 상태가 되고 해당 이메일로 로그인을 했기 때문에 이메일은 수정 불가능하다.

 

그리고 프로필 이미지는 원래 AWS S3(Storage)를 사용하였지만, 구글 워크 스페이스 계정의 기본 프로필 이미지를 가져오도록 수정하여 프로필 이미지를 추가하고 수정하는 기능은 사라졌다.

 

Next.js를 적극 사용한 리팩토링

Next.js로 리팩토링 하게 되면서 Next.js의 기능을 적극 사용하여 리팩토링을 하였다.

 

middleware를 활용한  경로 인증

middleware

Next.js의 middleware는 경로별 인증 상태를 확인하고 리다이렉트를 처리해 주는 역할을 한다.

그래서 토큰을 활용해 인증 여부에 따라, 경로 접근을 설정하였다.

 

middleware는 브라우저에서 서버로 HTTP 요청을 할 때 실행이 되기 때문에 페이지가 잠시 깜박거리며 보이는 현상이 없어 React 보다 사용자 경험이 향상된다.

 

API Routes를 활용한 정렬 로직

해당 프로젝트는 NoSQL인 DynamoDB를 사용하고 있다.

그러나 전체 데이터를 특정 값을 기준으로 정렬하는 기능이 없어 클라이언트 측에서 직접 sort 메서드를 사용해서 정렬했었다.

 

이러한 로직을 과연 클라이언트 측에서 처리해야 될까? 🧐 라는 우려가 있었기 때문에, Next.js로 마이그레이션 하게 되면서 API Routes 기능을 사용해 서버에서 정렬 로직을 담당하도록 처리하였다. 

 

결국 성능이 개선되긴 하였다.

 

해당 내용은 아래 글에서 자세히 확인할 수 있다.

[Next.js] API Routes로 DynamoDB 정렬하기 (feat. AWS Amplify)

 

추가 기능 구현 완료!

주어진 2주라는 기간 동안 추가 기능인 Google Calendar API 연동 작업까지 무사히 잘 마치게 되었다.

 

사내 서비스 오픈

🎉 🎉 🎉

약속대로 해당 기능을 구현하게 되어 실제 사내에서 우리의 서비스를 사용하게 되었다. 

 

사용자 피드백

해당 서비스를 사용하면서 사용자의 경험은 어땠는지, 개선할 부분은 있는지 등 구글폼을 통해 의견을 받았다. 나름 좋은 반응을 얻은 것 같다.

 

사용자 피드백을 바탕으로 개선할 점과 고도화할 점을 찾아낼 수 있었다.

그러나...............

 

인수인계

좀 더 프로젝트를 개선하고 싶었지만 아쉽게도 주어진 기간이 지났기 때문에 프로젝트는 여기서 끝이 났고 회사 소유의 프로젝트가 되었다.

 

그래서 프로젝트는 여기까지 진행하게 되었고 이후 직원분들이 프로젝트를 수정하거나 리팩토링 할 수 있도록 인수인계 문서를 작성하였다. 

 

마치며...

처음에는 "이걸 정말 다 만들 수 있을까?"라는 의문이 들었다. 하지만 팀원들과 매일 회의하고, 함께 소통하며, 정보를 공유하고 서로 도와주면서 좋은 결과를 얻을 수 있었다.

 

회사 직원분들이 실제로 사용할 수 있는 서비스를 만들게 되어 정말 값진 경험이었다. 🥰

 

그리고 AWS Amplify라는 새로운 기술을 사용하고 프로젝트를 완수하게 되면서, 새로운 기술을 두려워하지 않는 자신감을 얻게 되었다. 또한 여러 번(?) 기술 스택을 변경하면서, 기술 스택 선정의 중요성을 크게 깨닫게 되었다. 😅

 

6주 동안 많은 도움을 주신 코드잇 직원분들과 함께 인턴을 했던 친구들(?) 정말 고마웠고 즐거웠습니다!!