육두문자(KTB6) 팀 블로그 제작 후기

안녕하세요, Danny입니다!

썸네일을 보고 이곳에 오신 분들이라면 'KTB6 Team Blog? KTB6가 뭐지?'라는 생각을 하셨을 겁니다. KTB6는 "KakaoTech Bootcamp 6조"의 약자입니다. (카테부 6기를 뜻하는 게 아닙니다!)
육두문자라는 팀명을 영어로 번역하는 것이 쉽지 않아 영문명은 그냥 KTB6로 정했습니다.

(마음에 드는 게 없다...)

각설하고, 오늘은 팀 블로그 제작 후기를 공유하고자 합니다. 첫 번째 프로젝트로 팀 블로그를 선정한 이유, 사용된 기술 스택, 그리고 제작 과정에서 느낀 점 등을 다루겠습니다.

1. 프로젝트 선정 이유 및 목표

육두문자팀이 팀 블로그를 첫 번째 프로젝트로 선정한 이유가 무엇일까요?

카테부 교육생이라면 구름 EXP라는 전용 교육 플랫폼을 사용하고 계실 겁니다. 이 플랫폼에는 운영진이 학습 계획이라는 이름으로 팀활동을 위한 프로젝트들을 미리 준비해 두었는데요. 아마 대부분의 팀들은 여기서 하나를 골라 프로젝트를 진행하고 있을 텐데요.

아 근데... 이 녀석들 만만치가 않습니다. 우리는 아직 초짜인데, 교육 초반인데, 프로젝트 주제들이 너무 거창합니다.

• 통합 헬스케어 및 금융 관리 플랫폼
• SNS, 생성형 AI, WebRTC 기술을 활용한 프로젝트
• 클라우드 기반 e-커머스 플랫폼
• 실시간 영상 스트리밍 플랫폼
• 스마트 환경 모니터링 및 정보 공유 플랫폼

등등...

아직 github에서 협업하는 것조차 제대로 해본 적 없는 우리 코린이들에게 이런 프로젝트는 에베레스트 산 꼭대기보다 높아보입니다. 아직 뒷동산도 마스터하지 못한 저질체력 상태에서 에베레스트를 오르라고 한다면 압박감과 스트레스로 의욕이 저하될 수밖에 없습니다.

(팀 프로젝트 미션을 본 나의 심정을 표현한 그림)

그래서 육두문자팀은 먼저 뒷동산부터 오르기로 했습니다. 쉬운 프로젝트를 먼저 완주해 봄으로써 협업에 대한 감을 익히고, 프로젝트를 끝까지 해냈다는 성취감과 자신감을 얻자는 계획을 세운 것이죠.

이렇게 해서 첫 번째 프로젝트인 팀 블로그는 교육 시작 1주일 만에 완성되었습니다. 일단 팀 프로젝트를 하나 끝내서 근자감(?)을 얻자는 소기의 목적은 달성한 셈입니다.

또한, 팀 블로그는 앞으로 6개월 간의 여정에 지속적으로 도움을 줄 것입니다. 공개적인 장소(최소 6명은 1주일에 한 번은 들어오는 공간... 이어야 하지만 우리는 1명 퇴소해서 5명 ㅠㅠ)에 글을 쓴다는 것 자체가 일종의 건강한 긴장감을 주며, 천천히 체력을 기르는 데 도움을 줍니다. 공부한 내용을 기록하는 것만으로도 의미가 있으며, 나중에 돌아볼 때 '그때 내가 무엇을 했었지'를 공개적인 장소에 남겨둠으로써 먼 시간이 흐른 뒤에도 자신을 성찰해볼 수 있는 계기가 될 수 있죠.

또한, 제가 카테부 오리엔테이션 후기 글에도 언급했듯이 카카오 성과 리더님이 중요하게 여기는 교육생의 자세 2번이 바로 '글쓰기 많이 하기'입니다. 당연히 혼자 보는 곳에 쓰는 글보다 공개적인 곳에 쓰는 글에 더 정성을 쏟을 수밖에 없습니다. 자연스럽게 글쓰기를 잘하기 위해 노력하게 됩니다. 블로그는 나 자신의 성장 과정을 기록함으로써 남에게 나를 어필할 수 있는 수단으로도 쓰입니다. (대부분의 테크 블로그가 이 목적을 가지고 있습니다.)

팀 블로그는 아직 협업이 어색하고, 공부할 것이 많이 남아있는 팀이 첫 번째로 해보기 좋은 프로젝트이며, 우리 팀의 지속적인 성장에도 기여합니다. 이러한 이유로 팀 블로그를 첫 번째 팀 프로젝트로 선정하여 진행하게 된 것입니다.

2. 사용할 기술 스택

아래는 사용한 기술 스택과 그 이유입니다.

• React:
  • '단연 Javascript UI Library 1인자인 React를 사용하지 않고는 입안에 가시가 돋기 때문에 사용하였습니다!' 는 너무 장난식이고, 프론트엔드 개발자들이 가장 많이 사용하는 툴이자 저에게도 익숙한 툴이며 속도전에서 자신이 있기에 해당 기술을 선택했습니다. 사실 팀 블로그를 만드는데 있어 고급 기술은 필요하지 않기 떄문에 자신이 배우고 싶거나 자신있는 기술로 만들면 된다고 생각합니다.
• TypeScript:
  • 협업에서 가장 중요한 것 중 하나가 명확한 타입 선언이죠. 남이 작성한 코드를 수정할 때 타입이 없으면 예기치 못한 수많은 에러를 맞이하게 될 것입니다.
• Next.js:
  • 현재 React를 주력으로 사용하는 개발자라면 모를 수가 없는 Web Framework죠. 블로그 글은 정적인 내용이 많기 때문에 SSR의 효과를 크게 누릴 수 있어 Next.js를 선택했습니다. 그 외에도 배포가 쉽고, TailwindCSS 세팅을 기본으로 지원하는 등 장점이 많습니다.
• TailwindCSS:
  • Styled-components나 Emotion, PostCSS, 혹은 기본 CSS를 사용하던 개발자에게 Utility-first CSS는 혁명처럼 다가왔습니다. '와 이제는 CSS 클래스에 이름을 붙일 필요가 없어! 개발할 때 가장 큰 고민인 변수명 짓기에서 해방되었다!' 그렇습니다, TailwindCSS를 사용하면 변수명 짓기라는 아주 커다란 스트레스에서 벗어날 수 있습니다. 문법 자체가 기존 CSS와 다르기 때문에 처음에는 어색하지만, 조금만 써보면 원래 내 몸의 일부였던 것처럼 착 달라붙어 하나가 되는 기분을 느끼실 수 있습니다. 또한 공식 문서가 잘 되어 있어 웬만한 사용법 및 트릭은 공식 문서만 보고도 해결할 수 있습니다. 아직까지 제가 느낀 TailwindCSS의 단점이라면 HTML 태그가 조금 더러워 보일 수 있다는 점과 스타일 재사용을 하는데 있어 조금 불편한 부분이 있다는 점 정도입니다.

3. 개발 과정

프로젝트 폴더 구조와 주요 파일들

Next.js는 어느 정도 폴더 구조를 강제하는 편이라 크게 변주를 준 부분은 없습니다. 설명이 필요한 폴더는 'src/app/assets' 정도가 있을 것 같네요. 이 폴더 안에는 정적 데이터를 JSON 형식으로 저장해두는 data 폴더가 있습니다. 정적 데이터라고 해서 반드시 JSON으로 저장해야 하는 것은 아니지만, 서비스 내에서 두 곳 이상에서 사용되면서 반드시 동기화가 되어야 하는 데이터는 이곳에 저장합니다. 개인적으로 이렇게 관리하는 것이 편리하다고 느꼈습니다.

상태 관리 방법과 도구

현재 상태 관리 도구는 사용하지 않고 있지만, post의 view 옵션인 grid와 list view의 상태를 저장하기 위해 Context API를 사용해볼 생각입니다. 다른 방식으로도 해결할 수 있지만, 이 방식이 로직상 적합해 보입니다.

4. 배포 과정

배포 도구

Next.js를 사용하면 자연스럽게 Vercel도 사용하게 되는 경우가 많은데요. 일단 Vercel은 Next.js의 제작사이며 서로 호환성이 뛰어나 너무나도 편하게 호스팅 및 관리를 할 수 있기 때문입니다.

CI/CD 설정

아직 CI/CD라고 말할 법한 것들을 많이 추가하진 않은 상태인데요. 그래도 이번에 review requested 시 자동으로 디스코드로 멘션 메시지를 보내주는 봇을 개발하면서 Github Actions에 대한 감을 익힐 수 있었습니다. (알고싶지 않았던 shell script 사용법은 덤으로...🥲)

도메인 설정

훈련지원금으로 월 최대 36만원만 사용할 수 있는 취준생이 사적으로 운영하는 프로젝트를 위해 도메인을 구매하는 것은 아주 큰 사치라고 생각되어 Vercel에서 무료로 제공해주는 주소를 사용하기로 했습니다.

5. 문제 해결 경험

워낙 단순한 프로젝트라 서비스 코드 작성 자체에는 어려움이나 막히는 부분은 딱히 없었는데요.

그나마 가장 고생하고 막혔던 부분은 역시 discord-noti 액션을 만들 때 였습니다. Github Actions에서 기본으로 제공하는 'github' 객체에 어떤 내용들이 있는지도 파악해야했고, 무엇보다 shell script를 작성해본 적이 거의 없어서 의도대로 액션이 잘 작동하게 만드는 데에 꽤 애먹었습니다. 그래도 깨부해서 shell script 안에서 배열 데이터를 JSON으로 변환한 뒤 jq라는 툴로 JSON를 처리하는 방법에 대해 익힐 수 있었습니다. (알고 싶지 않았어...)

지금은 제가 원하는대로 잘 작동하고 있는 중이며, 아래는 디스코드로 리뷰어들에게 멘션을 보내는 조건입니다.

• PR이 Ready for Review 상태일 때 특정 리뷰어에게 Review Requested 할 경우
• PR이 Draft 상태일때 설정해둔 리뷰어들에게 PR이 ready for review 상태로 전환될 때

PR 담당자가 작업을 끝내고 리뷰를 받고 싶을 때만 메시지가 가도록 만들고 싶어 위와 같은 조건을 설정하게 되었습니다.

6. 학습 및 성장

디스코드로 메시지를 보내는 작업을 하면서 Webhook이라는 새로운 기술도 알게 되었고, 사용하는 법도 어느 정도 익히게 되었습니다. 웹훅(Webhook)은 이벤트가 발생할 때 다른 애플리케이션에 HTTP 요청을 통해 실시간으로 데이터를 전송하는 방법을 의미합니다. 이는 애플리케이션 간의 통신을 자동화하고 실시간으로 업데이트를 받을 수 있도록 해줍니다.

(우리 팀 서버의 작고 귀여운 웹훅 친구들)

7. 팀워크 및 협업

위에서 언급했듯이, 이 프로젝트의 진정한 의의는 협업에 대한 기본 틀을 만드는 것이었습니다. 모든 팀원이 GitHub에서 협업하는 과정을 직접 경험하면서 미래에 발생할 수 있는 문제들을 미리 겪어보는 것이 목표였죠. 이번 프로젝트를 통해 브랜치 전략, 커밋 메시지 규칙, 이슈 템플릿, 이슈 작성 방식, PR 템플릿, 코드 스타일 가이드 작성, 리뷰 작성 방식 및 문화, 데일리 스크럼 회의 문화 등을 정립할 수 있었습니다.

또한, 협업 도구 중 하나인 Jira를 사용하여 이슈를 관리하고 있습니다. 아직 완벽하게 연동되지는 않았지만, 조금씩 익숙해지고 있습니다. 원래는 Slack도 사용해보고 싶었으나, 현재 Discord에서 사용하는 기능 이상으로 Slack을 활용할 것 같지 않아 일단 보류하였습니다. 만약 더 큰 프로젝트에서 체계적으로 프로세스를 관리하고 싶다면, 협업 전용 도구인 Slack이나 Microsoft Teams 등을 사용해보고 싶습니다.

8. 향후 계획

빠르게 만들다 보니 콘텐츠도 부족하고, 아직 구현되지 않은 기능도 많고, 편의성 기능도 부족합니다. 하지만 앞으로 최소한 1주일에 한 번 이상은 공부한 내용이나 작업한 내용을 글로 써서 콘텐츠를 채워나갈 계획입니다. 또한, 팀 활동으로 진행한 프로젝트를 소개하는 공간, 다크 모드, 포스트 상세보기에서 헤딩에 앵커를 걸어두는 사이드 메뉴 등 다양한 기능들을 추가할 예정입니다. 앞으로도 성장해나가는 스토리를 함께 지켜봐 주시면 감사하겠습니다.

9. 마무리

1주일 동안 작업한 것 치고는 생각보다 전체적인 작업량이 많지 않아 놀랐습니다... 그래도 새롭게 배운 점도 있고, 팀 프로젝트를 하나 진행했다는 점에서 의의를 두고 있습니다. 일단 하나를 마치고 나니 기분이 좋네요! (팀 블로그 깃헙 주소)

첫 협업 프로젝트를 함께 진행해준 팀원들에게 감사의 인사를 전합니다. 모두들 적극적으로 참여해줘서 고마워요! 🙇‍♂️ 앞으로도 좋은 팀 활동을 해나갑시다!

지금까지 Danny의 육두문자 팀 블로그 제작 후기였습니다. 이 글이 유익하셨다면 github 따봉 한 번씩 부탁드립니다! 긴 글 읽어주셔서 감사합니다~