logo
Published on
25 min read

내 마음 속 바다 프로젝트 회고

서론

내 마음 속 바다 (https://www.oceanletter.site)
내 마음 속 바다 (https://www.oceanletter.site)

데브코스에 참여하는 동안 함께 하는 환경에서 많은 성장을 이뤘다고 생각하기에, 사이드 프로젝트를 더 해보고 싶다는 생각을 했었습니다. 마침 데브코스 4기를 수료하고 기간이 얼마 지나지 않아 DND 개발 동아리에서 10기를 모집한다는 소식을 들을 수 있었는데, 제가 원했던 경험을 할 수 있는 좋은 기회라고 생각되어서 지원하게 되었습니다.

사실 경쟁률이 상당히 높았기에 붙을 것이라고는 생각하지 못했었습니다만, 합격하게 되어서 감사히 활동할 수 있었습니다.

활동하는 기간에는 주변에 털어 놓기에는 부담을 줄까봐 하지 못했던 고민들을 물병 편지에 담아서 바다 속으로 털어 놓는다는 주제내 마음 속 바다를 만들었는데, 동아리의 활동 기간은 꽤나 지났지만 이번에 회고를 해보고자 합니다.

DND에 참여하면서

출처: DND 인스타그램(https://www.instagram.com/p/C0_8kEGPJii/)
출처: DND 인스타그램(https://www.instagram.com/p/C0_8kEGPJii/)

지원서

지원서에는 4가지의 문항이 있었습니다.

  1. DND에 지원한 동기와, 이루고 싶은 목표
    함께 하는 환경에서 새로운 인사이트를 얻어가고 싶고, 다른 분야의 동료를 알아가고 싶다는 내용을 표현했어요.
  2. 개발 활동에서 어려웠던 문제를 해결했던 경험
    데브코스에서 했던 모아밤 프로젝트에서 Service Worker를 적용했던 과정의 시행 착오 경험을 표현했어요.
  3. 열정을 가지고 몰입하여 성취했던 경험
    만든 프로덕트를 누구나 이용할 수 있도록 배포하는 능력을 갖추고 싶어서 AWS를 탐구하면서 즐겁게 몰입했던 경험을 표현했어요.
  4. 공동의 목표를 달성하기 위해 협업했던 경험 혹은 협업 가치관
    머쓱레터 프로젝트에서 아직 협업이 미숙했다보니 발생했던 문제를 페어 프로그래밍하며 함께 해결했던 경험을 표현했어요.

면접 과정이 없는 만큼 지원서에 최대한 제 경험을 정리하고 표현하는 것이 중요하다고 생각해서 1주일 정도의 시간은 모두 지원서 쓰는 곳에만 할애했던 것 같습니다.

지원서에서 왜 DND에 참여하고 싶고, 어떤 부분을 얻어가고 싶고, 특히 협업에서의 가치관은 어떤지를 표현하고자 노력했습니다.

DND에 기대했던 점

감사하게도 합격할 수 있게 되었고, DND에서 이러한 부분을 얻어가고 싶었습니다.

  • 디자이너 동료와의 협업
    • 데브코스에서 FE 동료와 협업하면서 즐거움을 느낄 수 있었고, BE 동료와 협업하면서는 BE 직군이기에 더 잘 알고있는 내용에 대한 인사이트도 얻으면서 성장하는 경험을 할 수 있었어요.
    • 이번에는 디자이너 동료와 함께할 수 있는 과정이기에, 디자이너 직군이 제품을 바라보는 새로운 인사이트를 배우고 싶었어요.
  • 운영진 분들의 든든한 가이드
    • 본업과 병행하시면서 사이드 프로젝트를 위한 비영리 동아리를 운영하는 것이 쉽지 않을텐데, 프로젝트가 최소한 산으로 가지는 않을 수 있도록 매 주 가이드와 미션을 정리해주시고 프로젝트 진행에 있어서 어려움을 나눌 수 있는 운영진 분들이 계시다는 점이 든든했어요.
    • 특히 구현의 방향성에 대해서 고민했던 부분을 코드 리뷰를 요청드렸을 때 예상했던 것보다 상세하게 의견을 주고 받았어서 감동받았던 경험이 있어요.
  • 동아리의 소속감
    • 사실 멤버를 모집할 수 있는 플랫폼을 이용해서 사이드 프로젝트를 시작하는 것도 가능하겠지만, 사이드 프로젝트이기 때문에 완성까지 지속하는 것이 쉬운 일은 아니라는 생각이 들었어요.
    • DND 동아리에서는 경쟁률도 만만치 않았던 만큼, 꼭 완성까지 달려보고 싶은 동료분들과 함께 사이드 프로젝트를 할 수 있겠다는 기대가 있었어요.

프로젝트 진행 과정

1. 기획

어떤 주제로 프로젝트를 만들어볼 것인지 아이데이션하는 과정부터 시작했습니다.
10가지 정도의 아이디어가 나왔는데 이미 존재하는 유사한 서비스가 있는지를 조사하고, 만들기에 재밌을 것 같은 아이디어를 선정했습니다.
그 중에서 물병 편지 서비스가 재밌을 것 같다는 생각이 들었고, 다수의 투표로 선정되었습니다.

아이디어 기획
아이디어 기획

2. 사용자 경험 조사

데스크 리서치 및 설문 조사를 통한 사용자 경험의 정량적 조사 과정을 거치면서 이번에 만드려는 서비스에서 어떤 측면을 강조해야 할지를 고민했습니다. 다만, 주변 지인과 커뮤니티를 위주로 설문을 했는데, 아무래도 비슷한 연령대인 20~30대의 연령층의 표본을 위주로 수집되었다는 부분이 있었고, 자연스럽게 취업 및 진로에 대한 고민을 많이 하는 것으로 나타났습니다.

이러한 진로에 대한 현실적인 고민은 신뢰성 있는 전문가로부터 조언을 받고 싶어 할 것이라고 생각이 들었는데, 이번에 저희가 만드려고 하는 것은 익명 기반의 서비스이기 때문에 깊이 있게 고민을 주고 받는 느낌보다는 주변에 이야기하기에는 부담되지만 익명의 누군가에게 가볍게 털어놓고 서로 공감해주는 서비스로 방향을 잡았습니다.

3. 프로젝트 준비

디자이너 팀원분들이 Lo-Fi와 Hi-Fi 작업, 그리고 BE 팀원분들이 요구사항 정의를 기반으로 ERD 설계 작업을 해주시는 동안 FE 팀에서도 도입할 라이브러리나 컨벤션 같은 부분을 논의하고 공통으로 묶어낼 수 있는 컴포넌트를 정리하기 시작했습니다.

도입할 기술 논의

데브코스에서 모아밤 프로젝트를 할 때에도 유사한 방식으로 정리했던 표인데, 이번에도 비슷하게 구성해서 동료분께 공유하여 논의했습니다.

사실 Storybook 도 고민을 했었는데 이미 제가 제안했던 기술 스택이 많았던 상황이라 러닝 커브적인 측면을 우려하여 제안하지는 않았습니다만, 동료분이 감사하게도 먼저 제안해주셨고 저도 이전에 Chromatic 을 적용해보지 못했던 것이 아쉬웠어서 이번 기회에 적용하기로 하였습니다. 실제 개발 단계에서는 공통 컴포넌트부터 구현하는 bottom-up 방식으로 진행하게 되었는데, 스토리북과의 시너지가 괜찮았던 것 같아서 좋았던 선택이라고 생각됩니다.

기술 스택 논의
기술 스택 논의

UI 라이브러리

디자이너 동료분이 계시는 프로젝트이다보니 Headless UI 기반의 라이브러리가 커스텀하기 용이하다는 생각이 들었고, 몇 가지의 옵션을 조사해서 FE 동료분께 제안했습니다.

그러나 논의 한 결과, headless UI도 좋지만 기본 스타일이 있어야 빠르게 구현하기에 편할 것 같은 부분도 있을 것 같다는 의견으로 합의되어서 MUIradix-ui를 함께 사용하기로 결정했습니다. 마침 스타일링 라이브러리로 emotion 을 사용하기로 논의했었으니, emotion에 의존성을 갖는 MUI 를 도입하기에도 괜찮다는 생각이 들었습니다.

번들 사이즈가 커질 수 있다는 점을 우려하기도 했으나, radix-ui 는 필요한 라이브러리마다 세밀하게 설치하는 것이 가능해서 큰 문제는 되지 않을 것이라고 판단했습니다.

UI 라이브러리 논의
UI 라이브러리 논의

디렉토리 구조 논의

디렉토리 구조 논의
디렉토리 구조 논의

공통 컴포넌트 개발

Storybook의 활용
Storybook의 활용

4. 중간 회고

중간에 잠시 회고하는 시간도 있었습니다. 사실 프로젝트 진행 과정에서 어떤 부분이 잘 되고 있고 어떤 부분이 보완이 필요한지 의견을 주고받는 것이 회고의 중요한 포인트이긴 하지만, 2달이라는 짧은 기간에 완성해야 하기도 하고 본업과 병행하시는 팀원분들도 계시기에 냉철한 피드백보다는 서로를 응원하는 방식의 회고가 좋은 결과물을 내기에 적합한 방식이라는 생각이 들었습니다.

회고
회고

프로젝트 협업 과정

실질적인 개발 단계에 들어가면서, 가장 중요하게 생각했던 것은 각 직군의 동료와 문제를 함께 해결하기 위한 커뮤니케이션이었습니다.

특히 처음 알게된 동료분들과 짧은 기간안에 프로젝트를 완성 해야 하는 만큼 팀 내 분위기가 중요하다는 생각이 들었고, 의도치 않게 타인의 감정을 상하게 해서 프로젝트의 동력을 잃어버리는 상황이 발생하기 않도록 커뮤니케이션에 신경썼습니다.

평소에 좋았던 부분에 대해서는 긍정적인 피드백을 한다거나, 요청해야 할 부분에 대해서는 근거를 확실하게 하고 의도를 오해하지 않도록 부드럽게 요청하고자 했습니다.

사용자 인가 관련

로그인 기능을 연동하려는 상황에 인가 권한이 필요한 API 호출 시 액세스 토큰이 만료되면 토큰 만료 응답이 아니라, 성공 응답으로 새로운 토큰이 반환되는 상황이어서 재발급 로직 핸들링이 어려운 상황이었습니다.

아무래도 이미 기능이 구현되어 있던 상황에 요청 드리는 것이어서 조심스러웠는데, BE 동료분께 요청드리니 재빠르게 해결해주셨습니다.

배경 애니메이션 관련

디자이너 동료분과 회의하면서 배경 이미지가 움직이면 생동감있겠다는 이야기가 나왔었습니다.
가볍게 해결할 수 있을까 싶어 background 관련 CSS 효과를 적용하고, 물병 이미지에 keyframe을 줘서 흔들리는 효과를 적용했습니다.

마침 Vercel을 통해서 배포하고 있었는데, 디자이너 분들이 예상하셨던 효과가 맞을지 피드백을 받기 위해 Preview URL에 MSW를 빠르게 적용해서 슬랙에 공유했는데 좋게 봐주셔서 현재 프로덕션에도 적용했습니다.

배경 애니메이션 효과
배경 애니메이션 효과

코드 리뷰

FE 동료분과 협업하는 과정에서도 코드 리뷰를 최대한 상세하게 남기려고 노력했습니다.

이는 동아리를 참여한 목적 중 하나로 같이 성장하면서 인사이트를 공유하고 싶은 마음이 있었기 때문입니다. 그런데 사실 코드 리뷰에도 시간이 꽤 소요되기 때문에 기능을 빠르게 구현하는 시기에는 쉽지 않을 수도 있겠다는 생각이 들기도 했습니다.

셀프 리뷰

프로젝트 진행 과정에 제가 제안했던 기술 스택이 많았던 만큼 러닝 커브를 고려하면 동료분이 빠르게 파악할 수 있도록 하는 것이 중요하다고 생각했습니다. 그래서 작업에 대한 의도가 중요하다고 생각되는 태스크에 대해서는 셀프 리뷰를 상세히 남기려고 했습니다.

https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/223#discussion_r1506015788
https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/223#discussion_r1506015788

논의

또한 리뷰를 주고 받는 과정에서 감사하게도 FE 동료분이 의문점이 있는 부분에 대해서 자세히 논의를 나눠 주셨고, 같이 이야기하면서 생각을 정리하는 데 도움이 많이 되었습니다.

https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/54#issuecomment-1919366471
https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/54#issuecomment-1919366471

코드 리뷰

코드 리뷰에 있어서는 근거를 확실히 하고, 인상 깊게 봤던 레퍼런스로부터의 인사이트를 공유하고자 노력했습니다.

https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/97#discussion_r1485960254
https://github.com/dnd-side-project/dnd-10th-4-frontend/pull/97#discussion_r1485960254

얻은 점

이전에는 기술적인 측면을 위주로 생각했었다면, DND에 참여한 이후로는 제품을 만드는 데 고려해야 하는 점이 많다는 것을 알게 되었고, 전반적인 관점을 생각하게 된 것 같습니다.

  • 프로덕트에 대한 전반적인 이해
    • 사용자 경험 조사, 필드 리서치, 정량적 조사와 정성적 조사, 페르소나 설정 후 가설 검증까지.. 하나의 프로덕트를 만들기 위해서는 개발 외에도 다양한 측면이 존재한다는 점을 알게 되었어요.
  • 디자인 용어에 대한 이해
    • 디자인 토큰, empty state, 4-Point Grid, 8-Point Grid 등 디자이너 직군의 동료와 함께하다보니 자연스럽게 알아가는 용어가 생겼어요.
  • 커뮤니케이션
    • 프로젝트에 도입할 기술을 제안하거나, 배포 환경에서의 문제가 발생할 때 해결하기 위한 방법을 제시하는 경우가 많았는데 그 과정에서 제안하는 저 스스로도 납득할 수 있고 동료도 납득할 수 있는 근거를 기반으로 이야기하려고 노력을 했었어요.
  • 예쁘게 완성된 프로젝트 결과물
    • 열정 가득한 디자이너 그리고 개발자 동료분들과 함께하면서 예쁜 결과물을 만들 수 있었어요.

깨달은 점 or 어려웠던 점

BFF의 필요성

프로젝트를 바쁘게 만들다보니 사용자 인가 처리나 CORS 관련 이슈 등 서버와 관련한 모든 내용을 BE 동료분께 요청드려야 했다는 점이 어렵기도 하고 미안하기도 했습니다. (다른 기능도 바쁘게 구현하시는 상황에서 추가 요청을 드려야 하는 상황이 여럿 연출..)

예를 들어 카카오 인가 코드로 액세스 토큰을 받아오는 과정에는 ajax 요청이 불가능한 문제를 해결해야 한다거나, S3 버킷에 CORS 정책이 적용이 안되어서 Cloudfront를 통해 해결한다는 점이 그랬습니다.

문제가 발생했던 부분의 원인을 파악하기 위해서 직접 playground 레포지토리나 개인 AWS 계정으로 테스트해보고 해결했던 방법을 공유했던 적이 있는데 사실 이 또한 커뮤니케이션 비용이 될 수 있겠다는 생각이 들었습니다.

FE 단에서 관리할 수 있는 서버가 있었다면 간단한 이슈는 직접 해결할 수 있지 않을까 싶었습니다.
(물론 동아리 활동이기에 이슈 해결 방법을 함께 학습하고 공유하는 것도 성장한다는 차원에서는 의미가 있긴 했었지만..)

BFF를 구성하기 위해서 Express 서버를 만들어도 좋지만 가장 쉬운 방법은 Next.js 라는 생각이 드는데, Next.js 에서 제공하는 기능 중 번들에서도 제외되고 높은 SEO 와 빠른 FCP 성능을 제공하는 RSC 를 활용하는 것도 재밌을 것 같습니다.

그래도 만약 동아리 활동 이전으로 돌아간다고 해도 당장 Next.js 를 적용하진 않았을 것 같긴 하지만, 이번 프로젝트를 통해 왜 Next.js 가 필요한지를 느낀 계기가 되었고 다음 사이드 프로젝트에서는 Next.jsNuxt.js 같은 프레임워크를 활용해보고 싶습니다.

사이드 프로젝트의 지속 가능성

Google Analytics
Google Analytics

DND 활동 기간은 2월 말에 끝났지만, 4월 말까지 리팩토링을 하거나 부족한 부분을 개선하면서 드디어 1차 런칭을 할 수 있었습니다.

특히 다양한 커뮤니티에 홍보했던 날에는 서비스에 접속해서 이용하는 모습을 GA로 실시간으로 지켜보기도 하고, 실제로 편지가 날아오는 것에 답장하기도 하면서 왠지 모를 설렘을 느낄 수 있었는데 이런 뿌듯함에 서비스를 개발하고 운영하는 것 아닐까 싶은 생각이 들었습니다.

동아리 활동 기간이 끝난 뒤에는 사실 각자가 본업, 학교, 교육 과정 등으로 바빠졌기에.. 이전 만큼 사이드 프로젝트에 몰입할 수 없었고 사실상 지속 개발은 어려운 상황이라는 생각이 들지만, 사이드 프로젝트의 특성상 어쩔 수 없는 부분이라는 생각도 듭니다.

그래도 또 GA 대시보드에 실시간으로 사용자가 쌓이는 짜릿함을 느껴보고 싶을 때마다 마케팅을 한번씩 하는 것도 재밌겠다는 생각도 들고, 추가해보고 싶은 기능이 생기면 가볍게 작업하고 PR을 올려보기도 하는 등 사이드 프로젝트로써 해보고 싶은 걸 여유롭게 해본다면 좋겠다는 생각이 듭니다.

마무리

사실 활동 초기에는 취업 준비에 더욱 집중해야 하는 시기인 것 아닐까? 사이드 프로젝트를 더 할 여유가 있을까? 싶은 생각도 들었습니다. 그런데 지금 돌이켜보면 DND 활동을 통해 제품을 바라보는 더 넓은 관점을 생각하게 되었고 협업을 통해 인사이트도 공유하면서 성장할 수 있는 경험을 해볼 수 있었다는 점에서 감사한 경험이었다는 생각이 듭니다.

아직 취업 준비중인 상황이지만, 취업에 성공하고 나서도 좋은 기회가 있다면 사이드 프로젝트 동아리에 또 참여해보고 싶다는 생각이 들었습니다.