[이달의SSAFY 8月] 2학기 공통 프로젝트 회고

안녕하세요! 9기 SSAFYcial 전인혁 기자입니다.

지난 7월, 2학기가 시작되고 어느덧 공통프로젝트를 마치고

특화 프로젝트가 시작되었답니다.

지난 공통프로젝트는 어땠을까요?

 

이번 기사의 주제는 바로바로~!~!

[이달의SSAFY 8月] 2학기 공통 프로젝트 회고 입니다.

 

2학기의 첫 프로젝트였던 공통 프로젝트.

이번 프로젝트를 통해, 정말 많은 지식과 경험을 얻을 수 있었는데요,

 

공통프로젝트에서 어떤 역할을 수행해왔는지,

그리고 어떤 것들을 느끼고 배웠는지를 이번 기사에 담아보았습니다.

 

지금부터 한 번 살펴볼까요? 💨💨

 

---

2학기 공통 프로젝트 회고

공통 프로젝트 회고에 앞서,

SSAFY의 2학기는 어떻게 진행되는지,

공통 프로젝트가 무엇인지 알아볼까요?

 

 

SSAFY 2학기는 어떻게 진행되나요?

🎤 2학기에서는 총 3번의 프로젝트가 5개월 안에 진행됩니다.

 

현재, SSAFY 9기 교육생들은

공통프로젝트를 마친 뒤, 특화프로젝트 부트캠프(1주)까지 진행되었으며,

특화프로젝트(6주) 진행을 앞둔 상태입니다 !

 

 

공통프로젝트가 무엇인가요?

🎤 공통프로젝트에서는 다양한 트랙 중, 원하는 트랙을 선택하고
트랙에 따라 주어지는 명세서에 따라 프로젝트를 수행합니다.

 

9기 기준, 총 4개의 트랙이 선택지로 주어졌습니다.

 

1. 웹 기술 트랙

2. 웹 디자인 트랙

3. 웹 IoT 트랙

4. 모바일 트랙

 

자세한 내용은 보안 상의 이유로 알려드릴 수가 없답니다 😥

 

 

공통프로젝트 회고 - 팀 빌딩

공통프로젝트 부트캠프에 들어가기 전, 팀 빌딩 기간이 있었습니다.

2학기는 정해진 팀에서 프로젝트를 수행하는 것이 아니라,

전공자와 비전공자가 모두 포함된 팀을 각자 꾸려서 진행이됩니다.

 

그래서 팀 빌딩 기간에,

자기 자신을 소개하는 장표를 공유하는 시간이 있었습니다.

 

저는 이런식으로 만들어보았습니다 ✌

 

저희 팀은 전공자 4명 + 비전공자 2명이 한 팀이 되어 프로젝트를 수행하게 되었습니다.

역할은 프론트엔드 4명(전공2+비전공2), 백엔드 2명(전공2)으로,

저는 당연하게도 프론트엔드를 맡았습니다.

 

모두가 열정적인 팀원이어서,

기획과 프로젝트 동안 지치지 않고 해낼 수 있었답니다!

 

 

공통프로젝트 회고 - 부트캠프 (1주)

🎤 부트캠프 기간에는 다음과 같은 업무들을 수행했습니다.

 

프로젝트 주제 선정

팀원들 모두 아이디어 뱅크였기에 수많은 주제들이 오갔습니다.

팀원 모두의 만장일치로

'홈 가드너를 위한, 식물 전문 화상 컨설팅 서비스'로 주제를 선정하였습니다.

 

주제를 더욱 구체화 하는 단계에서,

식물 관련 지식과 조언을 얻고자 광주 농업 기술센터에 방문하여

관련 전문가 분을 직접 찾아뵙고, 인터뷰하는 시간도 가졌습니다.

 

트랙 별 핵심 기술 학습

저는 웹 기술 트랙을 선택했기 때문에, WebRTC 기술을 주로 학습했습니다.

관련 라이브러리로 OpenVidu가 있어서, 공식 문서를 참고하여 구현 위주로 학습하였습니다.

 

🔗 공식 문서 링크 → https://docs.openvidu.io/en/2.28.0/

 

프로젝트 기술스택 선정

프로젝트에서 사용할 주요 스택들을 선정하였습니다.

팀 내에서 프로젝트 경험이 비교적 많던 제가 주도하여 선정했으며,

프로젝트 규모, 필요성, 얼마나 많은 개발자들이 사용하는지, 팀원들의 의견 등 여러 조건을 고려하며 선정하였습니다.

 

이번 프로젝트에서 선정한 프론트엔드 주요 기술스택과 선정 이유입니다.

 

1. React

- 팀 빌딩 때부터 React를 희망하는 팀원들로 구성.

- 가장 잘 다룰 수 있는 UI프레임워크(라이브러리).

 

2. TypeScript

- 지난 프로젝트들에서 마주한 타입 관련 에러(undefined 등)으로 인해 고통받았던 기억...

- 1학기 내내 자바를 배우면서 정적 타입언어가 익숙해짐.

- 많은 기업들에서 사용하고, 타입스크립트 경험자 채용 우대.

 

3. Sass

- 기존 프로젝트에서 사용해본 적이 없어서, 경험해보고 싶어서 사용.

- styled-components와 비교했을 때, 기존 id, class를 활용한 css 방식과 더 유사했기에 팀원들이 더 배우기 쉽다고 판단.

 

4. Recoil

- Redux에 비해 매우 간단하고 배우기 쉬움.

- 기존 프로젝트에서 사용해본 적이 없어서, 경험해보고 싶어서 사용.

- 프로젝트 주제와 규모를 고려했을 때, 그렇게 복잡한 상태로직이 포함되지 않을 것이라 판단 → Recoil로도 충분했다.

 

 

공통프로젝트 회고 - 프로젝트 수행 (6주)

🎤 본격적인 프로젝트를 수행하고, 느낀 점입니다.

좋았었고 유지할 점은 Good,

미흡했고 아쉬웠던 점은 Bad로 표현하였습니다.

 

 

Good 1. 아토믹 디자인 패턴

어떻게 하면 컴포넌트들을 효율적으로 설계하고, 공통 컴포넌트를 잘 뽑아낼 수 있을까?

위와 같은 고민에서 시작하여, 아토믹 디자인을 선택하게 되었습니다.

 

카카오 기술 블로그를 참고하여, 아토믹 디자인을 전체적으로 이해하고,

그 중 일부만 선택적으로 적용하였습니다.

 

아토믹 디자인은 컴포넌트를 기준에 따라서 총 5단계로 추상화합니다. (Atoms-Molecules-Organisms-Templates-Pages)

하지만, 5단계로 세세히 쪼갰을 때, 오히려 복잡성이 증가한다는 단점이 있었기에

저희 프로젝트에 맞게 패턴을 일부만 채택하였습니다.

 

저희 프로젝트에서는 Atoms-Organisms-Pages로 총 3단계로 추상화하였습니다.

 

🔗 참고 글 링크 → https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/

 

 

Good 2. 레이아웃 컴포넌트 패턴

하나의 Page 컴포넌트 내에서 상태로직과 스타일을 모두 처리한다면,

코드가 길어지고 수정 시의 코드 추적도 힘들어서, 유지보수가 힘들어집니다.

 

이러한 점을 보완하고자,

스타일은 레이아웃 컴포넌트에서 처리하고 상태로직들은 페이지 컴포넌트에서 처리하도록 설계했습니다.

 

아래의 HomePage 컴포넌트에서는

<Header/>, <BannerSlider/>...등과 같은 Organism 컴포넌트들을 

<HomePageLayout>...</HomePageLayout>로 감싸주고 있습니다.

 

이처럼 페이지 컴포넌트에서는 기능을 담당하는 컴포넌트들을 불러오거나,

props로 값들을 넘겨주는 등 로직 위주로 작성합니다.

 

레이아웃 컴포넌트에서는 컴포넌트들의 구조와 배치를 담당합니다.

<HomePageLayout/>으로 감싸진 컴포넌트들은 레이아웃 컴포넌트에서 children prop로 내려받아 배치하였습니다.

 

따라서 레이아웃 컴포넌트에서 Organism 컴포넌트를 직접 import 하지 않고도,

페이지 컴포넌트의 배치(레이아웃)를 수정할 수 있었습니다. 

 

🔗 참고 글 링크 → https://itchallenger.tistory.com/561

 

 

Good 3. 커스텀 훅의 활용

이전에는 커스텀 훅의 개념도, 어떻게 만들고 사용해야할지도 몰랐습니다.

이번 프로젝트에서는 자주 사용하는 로직들에서 커스텀 훅을 직접 만들어 적용하였습니다.

 

예시로, 화상 채팅에서 캠, 마이크, 차트 기능의 on/off를 담당하는 변수들을 관리할 때,

useToggle() 훅을 만들어 사용할 수 있었습니다.

 

토글버튼은 useState 변수에 값을 넣는 것이 아니라 토글 상태에 따라 true/false 만 변경해주면 되었기에,

[현재 상태, 현재 상태를 역(!)으로 바꾸는 toggle() 함수]를 리턴하는 커스텀 훅을 만들어주었습니다.

 

useToggle은 아래와 같이 사용해주었습니다.

 

기존 useState로 관리했다면,

각 상태 변수에 setCamState(false), setCamState(true) 와 같이 boolean 값들을 일일이 주어야 했습니다.

 

커스텀 훅 적용 후에는,

useToggle에서 받아온 toggle() 함수를 사용함으로써 toggle()을 호출하기만 해도 상태를 역으로 바꿔줄 수 있었습니다.

 

이 외에도 반복되는 API 호출 - recoil 저장 로직을 관리하는데에도

커스텀훅을 만들어서 사용해보는 등, 다양한 곳에서 커스텀 훅을 활용해볼 수 있었습니다.

 

 

Bad 1. 프로젝트 범위

매 프로젝트마다 범위문제를 겪었었는데,

이번 프로젝트에서도 범위 산정이 미흡했습니다.

 

큼지막한 기능들이 사용자측에 4개, 관리자측에 3개로

실 개발기간인 4주안에 끝내기에는 무리가 있었습니다.

 

각 기능별 우선순위를 상/중/하로 선정하여,

상에 해당하는 기능들을 우선적으로 만드는 등 대안을 만들어 적용하였습니다.

 

기획 단계에서의 욕심이 범위를 키우는데 큰 비중을 차지했으며,

다음 프로젝트에서는 꼭꼭 반드시!!!

팀 자원을 충분히 판단하고, 이를 고려하여 알맞은 범위를 산정해야겠다고 다짐하게 되었습니다.

 

 

Bad 2. 코드리뷰의 부재

프로젝트 기간이 중간쯤 지나갈 때부터, 같은 기능을 하는 컴포넌트가 여러개 생기는 경우가 발생했습니다.

공통 컴포넌트로 만든 것을 서로 인지하지 못하고, 새로운 컴포넌트로 만들어 버려서 발생한 문제라고 생각했습니다.

 

코드리뷰가 충분히 수행되었다면, 서로가 어떤 컴포넌트를 만들었는지 공유할 수 있었을텐데,

지켜지지 못했던 점이 아쉬웠습니다.

 

매일 아침 스크럼에서 공통코드에 대한 리뷰를 진행했다면 좋았을 것이라는 생각이 들었습니다.

 

다음 프로젝트에서는 최소한 공통컴포넌트에 대해서는 서로의 코드를 인지할 수 있도록

코드리뷰를 필수적으로 수행해보고자 합니다.

 

 

마치며 ...

여러모로 배운점도 많았고, 아쉬운 점이 많았던 2학기 첫 프로젝트입니다.

 

이번 프로젝트는

제가 SSAFY에 입과하게 된 이유이기도 한 프론트엔드 간 협업 및 프론트엔드 역량 향상 측면에서

많은 도움이 되었습니다.

 

위에서 언급한 디자인 패턴들도 적용해볼 수 있었고,

2학기 목표였던 타입스크립트도 프로젝트에 적용해볼 수 있었습니다.

 

이를 바탕으로,

다음 프로젝트인 특화 프로젝트에서는 더욱 성공적인 결과를 기대해도 되겠죠?

 

함께 했던 공통프로젝트 Planty 팀원들에게

감사의 인사로 이번 기사를 마무리하고자 합니다.

 

광주 2반 C202, 자랑스러운 우리 팀원들

전**, 양**, 이**, 임**, 김** 모두 모두 고생했어~!~!!~!

 

 

이상으로 기사 마치겠습니다 😊

SSAFYcial 기자 전인혁입니다.

 

 

 

 

이번 기사가 현재 SSAFY 교육생 이거나, SSAFY에 관심이 있으신 분들에게  많은 도움이 되었으면 좋겠습니다.

궁금하신 점이 있다면, 댓글로 꼭! 꼭! 남겨주세요 🙏🏻

 

 

 

---

" 읽어주셔서 감사합니다!

더 재밌고 유익한 기사와 함께 돌아오겠습니다 "