0. 들어가기에 앞서

📌 프레젤에 대해서
PPSG는 '라이프스타일 기반 소비경험 SNS' 서비스를 만드는 회사로 기업협업 진행하면서 프론트를 담당하시는 CTO, Terry님과 위코드 출신의 Back-End 개발자 Leah님과 소통을 하였습니다.

📌 전반적인 프로젝트 소개

• 모바일 서비스 '모내기'의 관리용 툴인 컨텐츠를 관리할 수 있는 기능이 들어있는 백오피스를 구현했다.
• SNS 형태의 모내기 서비스를 이용하는 유저가 자신의 소비경험을 공유하며 등록되지 않는 자신이 공유한 타겟(제품 혹은 장소)을 등록하여 라벨링을 할 수 있는데 이 라벨링 등록을 할 수 있는 관리자(어드민) 페이지를 구현했다.
• 라벨링의 목적은 크게 2가지로 나눠진다.

1. 유저가 공유한 소비 경험에 대한 리뷰 작성 후 타켓(제품이나 장소) 요청 시 이를 식별할 수 있는 정보(라벨)를 모아 데이터베이스에 저장해주기 위함이 첫 번째 목적이다.
2. 모든 유저 요청한 같은 제품이나 장소에 대해서 같은 정보를 입력하지 않기 때문에 정확하지 않은 정보들을 모아서 따로 관리하기 위함이 두 번째 목적이다.

1. 💻 Team 내마음의별로⭐️ 📡

• 안녕하세요 저희는 프레젤글로벌커넥션그룹(PPSG)의 '모내기' 서비스의 백오피스를 구현하게 된 내마음의별로입니다.

1_1> 🌟 프로젝트 소개

• 프로젝트 소개 : PPSG의 '라이프스타일 기반 소비경험 (제품 혹은 상품에 대한 리뷰이자 타겟) SNS' 모바일 서비스 모내기의 관리용 툴인 컨텐츠를 관리하는 기능이 있는 백오피스를 구현했습니다.
• 프로젝트 목표들 : 저희는 소비 경험을 공유하는 SNS인 모내기 서비스의 콘텐츠를 보다 안전하고 효과적으로 관리할 수 있는 관리자 페이지, 백오피스를 구현하는 것을 목표로 두었습니다.
• 진행기간 : 2021년 10월 25일 ~ 2021년 11월 5일(12일)
• 프로젝트 참여자
  • 프론트 앤드 개발자 : 안다빈, 윤창현
  • 백앤드 개발자 : 👨‍💻김민재👨‍💻,

2. 🛠 기술 스택

2_1> ⛏ FrontEnd 기술 스택

• React Hook(TypeScript)
• Style component
• Apollo-client

2_2> 🔧 BackEnd 기술

• NestJs(TypeScript)
• Mysql, Prisma
• GraphQL

3. 담당 및 구현 기능

3_1> ⛓ 기업협업의 역할

관리자 페이지(백오피스)

• 프로젝트 담당 : BackOffice 로그인, 타겟(제품 혹은 장소)요청 현황 페이지, 타겟 요청 등록 페이지 부분을 담당하였습니다.

3_2> 🔧 구현현 상세 내역

0. NestJS에서 GraphQL과 Prisma를 사용환경 설정

• NestJS에서 GraphQL과 Prisma Client을 사용할 수 있는 Code first 방식의 GraphQLModule및 Resolver 그리고 PrismaService와 PrismaModule의 초기 세팅 설정

1. 관리자 계정 로그인 API 구현

• JWT+JWT passport 기반의 로그인 어드민 유저 로그인(인증 관리) 구현
• Crypto를 활용해 hash된 password를 업데이트하여 데이터 베이스에 저장하는 로직 구현
• Token에 담긴 payload 정보를 담고 있는 커스튬 Admin decorator를 활용한 비밀번호 재설정 기능 구현
• Guard를 활용하여 Bearer Token(OAuth 2.0 API에서 인증하는 방식) 방식의 인가 과정 구현

2. 등록 현황 페이지네이션 관련 구현

• Prisma의 take와 skip을 활용한 쿼리문을 활용환 타겟요청 현황 페이지의 pagination(페이지 수, 갯수, orderBy 방식까지 프론트에서 작성 가능하도록) 구현
• context에 담긴 정보를 활용하여 만든 createParamDecorator로 생성한 Selections을 활용하여 프론트에서 작성하는 쿼리의 형식대로 데이터를 보내주는 API 구현

2. 타켓 등록 현황 관련 구현

• Prisma의 contains를 활용한 데이터 베이스에 있는 브랜드 및 제품 search API 구현
• Set과 Set의 메소드 has를 활용한 현존하는 라벨 및 새로 생성된 라벨만을 테이블에 등록하기 위한 형태의 컬럼으로 새로 mapping해주는 createLabel API 구현
• sql 쿼리문의 INNER JOIN과 GROUP BY를 활용한 product, place 라벨을 많이 등록된 라벨순으로 정렬한 getRecommendationLabels API 구현
• Prisma의 nested create를 활용하여 transaction을 걸어 FK로 연결된 4개의 테이블을 생성해 등록해주는 createProduct와 createPlace API 구현
• Mysql로 데이터 관리, NestJS에서 prisma 메소드로 쿼리문 실행
• try-catch와 apollo Error를 활용하여 상수로 정의한 메세지를 던져주는 예외 처리 구현

4. 👬협업의 깨달음

1. 📗 질문의 중요성을 깨닫다.

• 첫 날은, COO님께 테스트 단계에 있는 앱, '모내기' 서비스에 대해 간략한 설명을 들었다. 이후 리아님과 함께 백앤드 서버 초기세팅을 하고 곧바로 내가 이번 프로젝트에서 구현하게 될 것들에 대해서 설명을 들었다.
• 이후 맡긴 Task에 대해서 마쳐야한다는 압박감과 부담감에 휩싸여 실제로 내가 이해한 것들을 정리할 세도 없이 곧바로 개발을 시작했다.

• 1주차가 지나고 2주차가 지나면서 찜찜한 마음 한켠을 가진 채 내가 구현해야 할 업무만을 끝내기 위해서 정말 코드만 쳤던거같다. 이때 깨달은 것이 바로 질문의 중요성이었다.
• 매주 목요일마다 진행한 것들에 대해서 코드리뷰를 받았었는데 리뷰를 받으면 받을 수록 내가 지금 이 서비스에 대해서 그리고 내가 치고 있는 코드의 목적성에 대해서 정확하게 이해하고 있는지에 대해서 의문이 들었다.
  특히, 백앤드의 경우 설계를 기반으로 코드를 쳐야하다 보니 테이블의 목적과 여러 테이블과의 연결성들에 대해서 보다 잘 정리가 되어야했다.
• 내가 이러한 전체적인 흐름에 대해서 이해하지 못하는 건 당연한 결과였다.
  왜냐면 내가 이 서비스의 설계 단계부터 함께 한 게 아니니 아무래도 모델링 전체를 파악하고 흐름을 이해한다는 게 여간 쉬운 일이 아니었다. 따라서 나는 다소 뒤늦은 시점인 2주차가 지났을 때 Terry님과 Leah님께 미친듯이 질문하기 시작했다.

<질문 시 세운 원칙들>

1. 모르는 것을 혼자 고민하려하지말자. 최대한 빠르게 내가 고민하고 있는 상황에 정리한 뒤 이를 공유하여 함께 해결하기 위해 노력해야한다.
2. 모르는 것에 대해서 고민하는 과정에서 1>현재 내가 잘 모르는 상황이 무엇인지 2> 이를 해결 하기 위해 어디까지 시도해보았는지 3>그 과정을 통해 해결하고자 하는 최종 목적은 무엇인지에 대해서 최소한의 정리하는 시간을 가진 뒤 질문을 하자.
3. 내가 질문하려하는 부분에 대해 이해하고 있는 부분이 어디까지인지, 현재 나의 상황에 대해서 보다 명확하게 설명하려고 노력하자. 이 부분은 구체적이면 구체적일 수록 더 명확한 답변을 들을 수 있었다.
   => 따라서 위와 같은 원칙을 가지고 질문에 질문을 거듭한 결과 보다 명확하게 내가 코드를 치는 목적에 대해서 알게 되었고 그 결과 어떻게 하면 그 목적을 보다 효율적으로 도달할 수 있을지 고민하는 시간을 더 많이 확보할 수 있었다.

2. 📘 공식문서는 언제나 옳다.

• 이번 협업에서 NestJs, GraphQL 그리고 이전에는 ORM으로서만 활용했었든 Prisma의 메소드까지 새로운 것들을 바로 배우고 적용하는 과정 중에 있었다.
• 실제 업무를 하는 데 있어서 빠르게 결과를 만들기에만 급급하여 Restful API와 GraphQL의 차이점도 제대로 인지하지 않고 잘못된 구조(NestJs에서 Controller를 만드는 등)를 설계하는 등 본질적인 것들을 파고들지않아 놓쳤던 자잘한 실수들이 많았다.

• CTO이신 Terry님께서 내게 해주신 조언 중 라이브러리나 프레임워크를 배울 때 무엇보다도 이러한 라이브러리나 프레임워크가 어떠한 불편함을 해결하기 위해 등장했으며 그러한 점에 있어 가지고 있는 장점은 무엇인지 또는 단점은 어떤 것들이 있는지에 대해서 인지하는 과정이 꽤 중요하다고 하셨다.
• 또 이렇게 새로운 것을 배우는 데 있어서 언제나 그 중심에는 공식문서가 존재한다. 공식문서를 잘 들여다보면 그 답을 친절하게 알려주고 있고 그 안에서 내가 고민하고 있는 것들에 대한 답들이 잘 나와있다. 협업을 진행하면서 공식문서와 보다 친해지고 가까워진 시간들이 되었다.

5. 기업협업 과정 중 잘한 점과 아쉬웠던 점에 대해

📌 잘한 점

1. 문서화 내마음의 별 팀 노션

• 기억보단 기록에 의존하기 위해 이번에도 팀원들에게 노션으로 우리의 과정을 기록하자고 제안했고 위 수단을 이용하여 보다 효과적으로 팀원들과 소통하고 뿐만아니라 기업에 있는 내부 담당자분들과도 우리의 진행정도와 현재 상황에 대해서 원할하게 이야기를 주고 받을 수 있었다.

2. 회고 기업 협업 중 작성한 회고 모음

• 하루하루 그날 업무를 진행하며 배운 것들을 정리하는 과정을 거쳤으며 이 과정에서 내가 스스로 부족한 점에 대해서 그리고 더 채워나가야하는 점에 대해서 확실한 자기객관화가 이루어져 앞으로의 공부 방향까지 설정할 수 있는 계기가 되었다. 이러한 과정은 언제 무슨 일을 하더라고 중요한 거같으며 스스로 칭찬할만 하다는 생각이든다.

📌 아쉬운 점

1. 소통의 부재

• 앞서 언급했던 질문과 같은 맥락으로 소통을 위해선 무엇보다 질문이라는 과정이 중요하다. 질문을 함으로서 내가 어떠한 상황에 처했있으며 현재 나의 상황은 어떠한지 끊임없이 공유하고 함께 고민해야한다. 개발은 혼자하는 게 아니다. 이러한 사실을 보다 더 빨리 깨달았으면 더 좋은 기업협업의 과정을 거쳤을 거라는 아쉬움이 남는다.

2. 결과보단 과정

• 초반엔 내가 맡은 task를 마쳐야한다는 압박감과 부담감에 내가 하는 과정에 대해서 생각하는 것보다 빠르게 결과를 만드는데에 급급했다. 물론 결과가 중요하지 않다는 건 아니지만 이 결과를 어떠한 과정을 거쳐서 어떻게 만들었는지 그 과정이 더 중요하다는 생각이 들었습니다.
  
• 위 사진 처럼 도식화 혹은 그림으로 과정을 남기기 보다 과정들이 명확하게 들어오였다.

---

Reference) 이 글은 기업협업과 합의하여 컨펌받은 내용을 기반으로 작성되었습니다. 위의 내용을 무단 배포할 경우 법적으로 문제될 수 있습니다.
© 2021 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About