구름톤 챌린지 개발 회고

안녕하세요 :)
저는 구름에 1년 정도 재직 중인 Kenny입니다.

근 한 달 정도 사내에서 구름톤 챌린지 프로젝트에 대한 개발을 혼자 진행했는데, 관련해서 회고를 하려고 합니다.

 

먼저 구름톤 챌린지는 아래 랜딩 페이지 링크에 들어가시면 어떤 서비스인지 쉽게 아실 것 같아요.

구름톤 챌린지 랜딩 페이지 링크
(14일 날 정식 오픈이고, 저는 열심히 사용자들을 위해 남은 Ui 개발 및 검수를 진행하고 있습니다.)

 

📚 회고 시작

혼자 프로젝트를 진행한다는 것

저는 풀스택 엔지니어로 입사했지만 다들 백엔드 성향이 강해 프론트엔드를 주로 작업했었는데요,
이번엔 새로운 사업들이 생겨나고 같은 팀 사람들이 tf로 빠지면서 인원이 부족한 상태라 백엔드까지 혼자 진행하게 됐습니다.

 

혼자 프로젝트를 진행한다는 건 상당히 외롭다는 걸 느꼈습니다.
실제로 방대한 양의 기획에 대해 개발을 미친 듯이 진행하며 번아웃도 올 뻔했어요 🥲

그동안 최소 1명의 개발자 동료와 함께 협업했는데, 혼자 프로젝트를 진행하니 몇 가지 단점이 보였습니다.

- 주니어임에도 혼자 책임지고 개발 일정을 산정하고 실행해야 함
- 사업에 대한 코드 리뷰어를 누구를 걸어야 할지 고민...
- 혼자 하므로 버그가 나면 온통 내 책임이라는 압박감 => 주말 근무까지 하면서 QA를 완벽하게 진행하고 싶어짐..

그래도 기획, 디자인, 개발 프로세스가 원활하게 돌아가 시간적으로 여유가 조금 있었다는 것은 정말 다행이었습니다.

백엔드, 프론트엔드 할거 없이 DB 설계, api 개발, 기능 개발, Ui 개발 을 하나하나 새로 만들어가며 정말 바쁜 한 달을 보낸 것 같아요.

 

 

아직 개발이 끝나진 않았지만,
사전 알림 오픈날 이후 많은 사용자들이(무려 500명 이상) 구름톤 챌린지 사전 신청을 해주셔서 뿌듯한 것 같아요.

외로운 코드 리뷰

아무래도 개발자들이 본인이 해당되지 않는 프로젝트의 모든 기획을 이해하고 완벽한 코드 리뷰를 하기엔 무리가 있습니다.
위와 같은 리뷰 방식은 시간 지체로 이어지며, 서로에게 피곤한 영향을 줄 수 있어 조금 조심스러웠습니다.
다행히 옆자리에 프론트엔드 개발자 동료분이 계셔서 꾸준히 챌린지 이야기를 서로 하며 리뷰도 그나마 수월하게 진행된 것 같습니다.

아직 누군가가 리뷰할 PR이 7개가 쌓여있지만 아마 동료분들이 코드 레벨적인 부분에 대해 리뷰를 잘해주실 거라 믿습니다. 😎

중요한 건 QA

아무래도 유저나 기업에게 중요한 건 코드 레벨보다 QA입니다.
코드의 품질이 완벽해도 기능이 정상 동작하지 않으면 정말 무의미한 코드가 되어버리니까요.

 

이번엔 개발하면서 더더욱 QA를 많이 진행한 것 같아요.

다양한 모달을 개발하며 계속 DB 삭제 삽입 삭제 삽입 삭제 삽입 .........
계속 반복하며 일어날 수 있는 케이스들에 대해 심도 있게 자체적으로 QA 했던 것 같아요.

⛔️ 아래는 다양한 QA 리스트가 나옵니다.........

api의 경로 값을 바꿔가며 에러가 났을 때 어떻게 대응되는지,

 

에러 처리 방식이 올바른지,

 

서버 기준 날짜에 맞게 라운드가 순서대로 잘 열리는지,

 

주말을 제외하고 라운드가 잘 대응되는지,

 

주말일 때 금요일 뷰로 잘 보이는지,

 

사용자가 로컬 시간을 바꿔도 기능상으론 서버 시간 기준으로 잘 동작하는지,

 

서버 로직이 부하를 일으키진 않는지,

 

챌린지 문제 공개 날 기준 48시간 안에 풀었을 때 스탬프가 정상 발급되는지,

 

47시간 59분 59초에 제출했을 때 발급이 되는지,

 

48시간 이후 제출했을 때 발급이 되지 않는지,

 

제출 관련 이벤트 모달들이 여러 번 뜨진 않는지,

 

스켈레톤 Ui가 사용자 친화적인지, 모든 반응형에 대해 잘 대응되는지,

 

모든 반응형에 대해 Ui가 잘 대응되는지,

 

스탬프에 따라 정확하게 레고들이 잘 보이는지,

 

해설 강좌 오픈 Alert가 오전 10시 기준, 챌린지 마무리 기준으로 잘 뜨는지,

 

등등 등등 등등.........

 

기획자에게 계속 찾아가 물어가 보며 개발을 진행했고,
이후 의도한 대로 동작하는지 정말 혼자서 모든 기능에 대해 더 많이 QA를 진행했던 것 같습니다.

아마 혼자 개발함에 따른 불안함이 컸던 것 같아요.

코드 설계

이번 챌린지는 특히 모달이 많은데요,

 

1. 사전 알림 모달
2. 챌린지 시작 후 받는 정보 수집 모달
3. 학습 일기 모달
4. 중간 및 최종 설문을 받는 모달 (예정?)
5. 챌린지 문제를 제출했을 때 일어나는 다양한 케이스들에 대한 모달

등등...

모달 개발자라 불릴 정도로 모달에 대한 케이스가 아주아주 많고 기능 또한 모두 달라 구현하는 데 고민을 많이 했던 것 같아요.

일단 당연하게도 관심사별로 컴포넌트를 분리해서 정의하고, 공통적으로 뺄 수 있는 컴포넌트들은 모두 뺀 것 같아요.

 

위 사진은 이번에 개발한 사전 알림 모달인데요.

위 모달의 특징은 Footer에 Step이 있고, 다음 버튼 disabled 검증하는 부분이 Step마다 있고,
모바일일 땐 전체적인 뷰 및 디자인 자체가 바뀌도록 설계가 되어 있습니다.

 

아마 위 모달은 자주 쓰일 것 같아 따로 StepModal이라는 컴포넌트로 분리했습니다.

각 Step 별 view, data, validation 조건 등에 대해 Props로 전달받고 제출(Post) 되는 Step 수,
마지막 페이지에 이전 버튼을 넣을 건지 등등 최대한 유연하게 사용할 수 있도록 설계한 것 같아요.

 

실제로 사용하는 데는 Step별로 데이터 설계를 알맞게 해야 사용이 가능하지만,
아마 처음 사용하시는 분들도 어떻게 사용할지 잘 알도록 관련해 주석으로 잘 작성해 놔서 무리는 없을 것 같습니다.

 

구름톤 챌린지 프로그래밍 문제에서 답안을 제출했을 때 모달은 다양한 애니메이션(BX) 요소가 많은데요.
관련해서도 타입에 대해 모달 애니메이션을 설계하는 것도 재밌었던 것 같습니다.

 

공통 컴포넌트 분리

사실 두 번째 챌린지까지가 마지막이라고 모두가 예상했었습니다.

그래서 기간이 있는 일회성 프로젝트의 컴포넌트들에 대한 공통 컴포넌트를 크게 고려하진 않았습니다.

챌린지마다 스탬프 총개수나 스타일이 달랐고, 이를 공통화시키기엔 개발 기간이 너무 짧았었거든요.

https://level.goorm.io/l/challenge/algorithm-monday-highscool-1

실제로 하이스쿨 챌린지는 거의 7일 만에 만들어진 챌린지입니다.😇

 

이번엔 3번째 개쵀고, 이후에도 계속 챌린지를 진행할 것 같아 공통되는 컴포넌트들은 모두 공통화를 목표로 작업했습니다.

위 스탬프 관련 캐러셀은 모바일 반응형일 땐 캐러셀, PC 반응형일 땐 일반 뷰로 보입니다.

PC 뷰 => 스크롤 => 캐러셀 형식으로 구현되어 있어요.

 

이젠 3개의 챌린지이므로 모두에게 적용이 되도록 하나의 컴포넌트를 유연하게 구현했고, 총 스탬프 개수 몇 개가 오든 백그라운드 색상, 총 개수, Dim 처리 등등 모두 대응할 수 있도록 설계했습니다.

 

사용하는 부분에서는 서버에서 받아온 우리가 정해놓은 스탬프 컨벤션을 스탬프만 넘겨주면 자동으로 되게 사용성을 크게 늘렸습니다.

여기도 마찬가지로 반응형에 따라 PC 뷰 => 스크롤 => 캐러셀로 구성되어 있습니다.

1. 스탬프(블록) 개수를 보여주고 달성하면 뱃지 뷰가 바뀌는 형식

2. 기본적으로 첫 번째 사진정도만 제공할 거냐 

 

두 개는 뭔가 같은 컴포넌트인 것 같은데, 위 두 개의 역할이 나눠져 있는 것 같아 고민이 많았는데요.

그래도 너무나 같은 view고 props로 해결할 수 있는 부분인 것 같아서 공통화를 시켰습니다.

로딩 설계

스켈레톤 Ui 처리에 대해서도 팀원에게 공유받은 내용이지만 좋은 내용이라 공유하고 싶네요!

사용단에서 Suspense, Loading처리를 하는 게 아닌 컴포넌트 자체에서 처리하는 방식입니다.

- index.tsx
- MissionContainer.tsx
- MissionContainer.scss
- MissionContainer.loading.tsx

MissionContainer.loading.tsx에는 당연하게도 스켈레톤 Ui가 정의되어 있습니다.
MissionContainer.tsx에는 메인 컴포넌트 기능들이 정의되어 있습니다.

위와 같이 설계하고 만약 suspense가 아닌 react-query를 사용한다면

// index.tsx
import React from 'react';

// 예시 useQuery
import { useGetExams } from '@/query-hooks/....';

// components
import MissionContainerComponent from './MissionContainer';
import MissionContainerLoading from './MissionContainer.loading';

const MissionContainer = ({...props}) => {
  cosnt { isLoading } = useGetExams();

  return isLoading ? <MissionContainerLoading /> : <MissionContainerComponent {...props} />
}

위와 같이 정의해서 사용했는데요!

useGetExam은 useQuery를 return 하는 함수입니다.

 

저희는 sass를 사용해서 loading이나 기능 컴포넌트가 같이 className도 공유해
기본적인 레이아웃을 동일시 가져가 스켈레톤 Ui를 개발하는데도 훨씬 수월했습니다.

suspense를 사용할 때도 위처럼 index.tsx나
MissionContainer.tsx 내부에서 export default 부분에 정의해도 좋을 것 같아요.

정리

처음이자 마지막으로 회사에서 혼자 개발하는 tf 일 것 같아서 회고합니다.
이후 프론트엔드로 커리어를 쌓아갈 거지만 혼자 백엔드까지 전부 개발하는 것도 좋은 경험이라 생각해 재밌게 개발했던 것 같습니다.

방대한 개발을 빠르게 쳐내야 되는 압박감이 있었지만 거의 다 끝나고 보니까 재밌게 개발한 것 같아요.

개발한 기능들이 모두 정상 동작하길 바라며 14일까지 QA를 계속 진행할 예정입니다😇

아마 참여하시는 분들이 읽을 수도 있을 것 같은데, 긴 글 읽어주셔셔 감사합니다.