이 프로젝트는 22년 12월 말 - 23년 4월 초 까지 프론트엔드 개발자로 참여하여 개발한 프로젝트이다.
개발이 거의 다 되었지만 배포와 운영은 진행되지 않았다..😞 사실, 로고도 정해지지 않았지만, 예비로 만들어 둔 것을 사용해 소개페이지를 만들어봤다.
조금 아쉬운 프로젝트이지만, 여태까지 진행한 프로젝트들 중 가장 배운 것이 많았고 성장할 수 있었던 프로젝트여서 나의 경험을 공유하고자 작성한다.
프로젝트 소개
[ 품 : POOM ] 서비스는 제로 웨이스트 샵의 정보확인, 리뷰 등록 및 공유를 제공하는 서비스입니다.
제로 웨이스트를 실천하고 싶지만, 가게의 위치를 몰라 어려움을 겪는 분들을 위해 도움이 되고자 제작된 서비스입니다.
품 : POOM은 사용자들이 친환경에 한 발짝 더 가까이 다가갈 수 있도록 도와드립니다.
제로 웨이스트를 실천한 당신의 소중한 경험을 기록해 깨끗한 세상을 위한 초록 발자취를 남겨주세요! 작은 발걸음이 세상을 깨끗하게 만듭니다.
당신의 제로 웨이스트를 향한 여정, 품 : POOM과 함께 시작해 보세요 :)
참여하게 된 계기
과거 Velog에서 인기를 많이 얻었던 개발자들을 위한 slusy.io라는 개발자 커뮤니티 사이트가 있었다. 여기에 내 정보를 남겨두었는데 메일을 통해 사이드 프로젝트팀 LuckTree의 프론트 개발자 분께서 내 블로그를 보고 사이드 프로젝트 제안을 주셨다..ㅎㅎ
마침 프론트 개발자 분께서 본인의 프로필을 남겨주셔서 이력을 봤는데.. 우아한 형제들 개발자 셔서 깜짝 놀랐다..
이런 분이 왜 연락을 주셨는지 아직 의문이지만 프론트 외에서 개발에 있어 많은 것을 배울 수 있을 것 같았다.
(알고 보니 LuckyTree 팀에는 나 빼고 다 현업자 분들이셨다.. 정말 갭을 좁히기 위해 많은 노력을 했다..🥹)
내가 팀에 참여하기 전에 LuckyTree팀에서는 제로 웨이스트 서비스를 만들겠다는 비전은 이미 잡혀있었다.
그래서 처음 팀 미팅을 했을때 프로젝트에 관한 설명을 듣게 되었는데, 친환경 실천을 도와줄 수 있는 서비스를 개발한다는 점이 사회적인 문제를 IT기술을 통해 해결하는 듯한 느낌이 들어 꼭 같이 해보고 싶다는 생각을 한 것 같다.
개발 문화와 소통
LuckyTree 팀은 내가 있던 어떤 동아리나 개발 팀보다 조직화되어 있었다.
지금부터 적는 것들이 당연한 것 일지도 모르지만, 나에겐 현업의 작업방식을 엿보는 듯한 느낌이 들어 신기하고 배울 것 투성이였다.
#1 _ 소통을 위한 Slack
나는 개발을 하면서 Slack을 사용해 본 것이 처음이었다. 보통 디스코드나 카톡을 이용하다 보니.. 존재만 알았다.
처음으로 써본 Slack은 협업에 있어 최적화된 소통 플랫폼 같은 느낌이었다.
앱을 통해, 누군가 PR을 날리면 알람이 오고 CI 과정에서 리뷰가 필요한 사항이면 자동으로 알려준다..
또, 파일을 관리하고 사진을 첨부하여 조직화된 스레드를 남기는 면에서 디스코드보다 훨씬 좋다고 느꼈다.
채널을 분리할 수 있는 점은 디스코드와 크게 차이 나지 않았지만.. 체계적인 채널의 리스트를 보고 엄청 놀랐던 것 같다.
개발단계를 세분화하여 배포, 빌드 등 각 과정마다 관리하는 모습이 인상적이었다.
대학교에서 동아리나 팀플을 하면 프론트, 백엔드 정도로만 채널을 구별했던 자신이 부끄러워지는 순간이었다.
사실 나는 CI/CD 자동화 과정에 있어 아는 바가 없었기 때문에 이번 프로젝트를 계기로 따로 공부해 보았다.
CI / CD 개발 프로세스가 뭘까?
이번 사이드 프로젝트를 준비하면서 모르는 개념들이 상당히 많다는 것을 알게 되었다. 그래서 그러한 개념들을 공부할 겸 하나씩 정리해 보려고 한다. Background 빠르게 변화하는 시대에 시장과
so-tired.tistory.com
#2 _ 체계화된 Notion과 정보 공유
LuckyTree 팀은 Notion을 통해 프로젝트에 대한 문서화를 체계적으로 잘해두었다.
기획의 미션과 비전, 개발 회고, 팀의 개발문화, 회의록 등 이뤄지는 모든 활동들에 관해서 기록을 해 두었던 것 같다.
이는 정말 좋은 경험이 되었다. 나는 체계화된 문서를 통해 다음과 같은 장점을 느꼈다.
- 다른 팀의 진행속도를 확인하고 API 문서, 개발 플로우차트 등 개발에 있어 필요한 정보들을 묻지 않고 쉽게 알 수 있었다.
- 우리 팀이 나아가고자 하는 비전과 목표를 명확히 하여, 일관되고 흔들리지 않는 개발을 할 수 있었다.
- 회고를 통해 다른 사람들의 개발을 하면서 느낀 점이나 팀 일원들의 생각을 알 수 있었다.
- 회의록을 작성하여 과거에 있었던 문제를 통해 현재의 문제를 해결하는데 도움을 얻을 수 있었다.
- 기록을 하는 과정에서 다시 한번 생각을 하게 되고 이유 있는 개발을 할 수 있게 해 준다.
이와 같이 체계화된 문서는 작업효율을 올려주고 팀이 같은 방향으로 나아가게 해주는 효과가 있다는 생각이 들었다.
#3 _ 팀 문화
LuckyTree 팀에는 모각코(모여서 각자 코딩)와 스프린트, 오너쉽과 같은 개발 문화가 있었다.
[ 모각코 ]
매주 수요일 저녁 8시부터 시간이 가능한 사람들은 가급적 구글 미팅에 접속해 같이 코딩을 하는 모각코 시간을 가졌다.
모각코는 실시간 의사소통을 할 수 있다 것이 가장 큰 장점이었다.
Slack을 통해 의견을 남겨 두더라도 일과 중엔 답변이 어렵고 몇 시간 뒤에 확인이 된다는 아쉬운 점이 있었다.
하지만 모각코 시간에는 실시간으로 소통이 가능하여, 빠르게 이슈를 처리할 수 있어 개발 속도가 빨라진 것을 체감할 수 있었다.
[ 스프린트 ]
스프린트는 팀이 일정량의 작업을 완료하는 시간을 짧게 정해두어 작업을 하는 것을 의미한다.
스프린트 기간은 팀 별로 달리하여 작업을 하였는데 프론트 팀의 경우 1주로 두었다. 월요일마다 회의를 통해 작업을 나누고 일요일에 확인을 해, 다음 스프린트 때의 이슈를 정했다.
스프린트는 개발의 완성이라는 장기적인 숲을 만들기 위해, 필요한 작업을 하며 나무를 심는 과정인 것 같다.
스프린트는 장기적인 목표에 지치지 않도록 해주고 지금 당장 해야 할 일을 명확히 해주었다.
[ 오너쉽 ]
팀 리더가 있지만 리더에게 모든 것을 의존하게 되면 팀은 무너져 내린다.
그래서 LuckyTree 팀에서는 스스로 서비스에 대해 책임감을 가지기 위해, 각자에게 역할을 하나씩 부여해 진행하였고 나는 회의록 담당을 하였다! 😎
오너쉽은 정말 좋은 문화인 것 같다. 나에게 책임이 주어지니 조금 더 적극적으로 임해야겠다는 생각을 들게 해 주었다.
앞으로 학교에서 팀프로젝트를 할 때 잘 써먹을 것 같다..😋
#4 _ 근거 있는 소통 & 의미 있는 행동
이 부분에 있어 정말 배운 것이 많다.
사실 디자인을 배울 때에도 의미있는 디자인에 많은 생각을 하였는데, 결과물에는 아무래도 느낌이 많은 영향을 미쳤던 것 같다.
개발에 있어서도 이는 비슷했던 것 같다.
하지만, LuckyTree 팀에서는 사소한 것을 결정할 때에도 그 의견을 제시한 근거를 얘기했어야 했던 것 같다.
아래는 프론트엔드의 본격적인 개발 전, 기술 스택을 결정하기 위해 회의를 한 자료이다.
왼쪽 자료에 보면 하나의 기술 스택을 결정함에 있어서도 거기에 따른 합당한 이유에 따라 결정하였다.
- 어떠한 기술을 쓸 것인지
- 그 기술이 왜 쓰여야 하는지
- 장단점은 무엇인지
- 이전의 경험은 어떠했는지
- 우리 팀이 그 기술을 사용할 경우 개발 속도는 어떻게 될 것 인지
이뿐만 아니라 디자인에 있어서도 이 디자인이 UX적으로 어떤지, 사용자가 이용한다면 어떤 부분이 필요할지.. UI하나를 만들 때에도 근거에 따라 결정하였다.
이러한 점은 앞으로 내가 알고리즘 문제를 풀 때나 일반적인 코드를 작성할 때에도 의식할 수 있도록 노력해야겠다.
프로젝트에 기여한 바
#1 _ Figma 디자인 & Storybook UI 컴포넌트 문서화
우리 팀에는 디자이너가 없어서 프론트 쪽에서 알아서 UI/UX 디자인을 맡아서 진행했다.
기획 단계에서 결정된 기능 요구사항을 바탕으로 페이지 별로 필요한 기능들을 배치하였다.
나와 다른 한 분이서 에셋과 전체 페이지를 디자인을 맡아 디자인하였다..!
서로 페이지의 1차 디자인이 끝나면, comment를 달아 의사소통을 해가며 조율을 통해 디자인을 결정하였다.
디자인을 하면서 이전의 해커톤 경험을 살려 폰트, 자간, margin, padding 등 픽셀 값 하나하나 신경 써서 디자인한 것 같다.
또 React로 개발이 진행되는 만큼 Figma에서 Asset을 작업할 때부터 Component를 신경 써서 작업을 했고 레이아웃, 그룹 등 여러 요소들을 신경 썼다..
Color 또한 사용자들이 직관적으로 알 수 있는 컬러와 메인 컬러를 지정해 두어 작업을 하였다. (이 부분에 있어서 TailwindCSS로 작업하는 데 있어서 많은 장점이 있었다.)
힘든 부분이 많았지만, 버튼과 InputBox 같은 것들을 일일이 Component화 해서 작업을 하여 빠른 변경과 체계적인 작업이 가능했다.
또한 Figma에서 디자인 히스토리를 남겨 두어서 어떤 식으로 모양이 변경 되었는지 기록을 남겨두었다.
이는 협업을 할때 다른 작업자가 디자인을 어떤식으로 변경했는지 파악하기 좋고 파일 관리도 편리해 진다.
조금 아쉬운 점이 있다면.. 개인적인 스타일의 디자인이 거의 반영되지 못했다.
나는 핀터레스트 등을 참고하여 조금 세련된 디자인을 하고 싶었는데, 구현에 있어서는 굳이 필요하지 않은 디자인이었다.
그래서 미리 작업해두신 디자인 스타일을 참고하여 깔끔하고 심플한 느낌의 디자인을 살려 진행했다.
이렇게 작업해 둔 Figma를 바탕으로 나는 Storybook을 사용하여 UI 컴포넌트들을 문서화하였다.
Storybook을 통한 문서화는 처음 해봤는데, 프론트 개발에 있어 디자인 시스템을 구축하는 것이 효과적인 개발을 할 수 있게 해 준다는 것을 깨달은 것 같다.
Storybook을 개발한 내용에 관해선 따로 포스팅을 해 두었으니 궁금하다면 이 문서를 참고하자.
주니어 프론트 개발자의 Storybook 경험담
2023년 전반기에 Poom이라는 서비스를 개발하면서 이것저것 프론트엔드 개발을 편리하게 해주는 기술들을 써 보았는데, 그중에 Storybook을 써본 경험담을 작성해 보려고 한다. 이번 경험을 통해 프
so-tired.tistory.com
#2 _ 프론트 개발
아래는 프론트에서 사용한 개발 스택이다.
기술 스택: React, Typescript,
CSS 라이브러리: TailwindCSS
상태관리 라이브러리: react-query
빌드: vite
코딩 컨벤션: airbnb eslint 일부 수정.
CI/CD 자동화: Github Action
진행사항 관리: Notion & Github Project
나는 다음과 같은 부분을 맡아 개발하였다.
- TailwindCSS extend 스타일 추가 (코드)
- Storybook 컴포넌트 등록 (PR)
- 해쉬태그 기능 개발. (코드 / PR)
- 하단 바 구현 및 내비게이션 기능 개발. (코드 / PR)
- 지도 위 가게의 위치 Icon을 띄우고, 클릭 시 가게의 정보를 보여주는 기능 개발. (코드 , 코드 / PR)
우선.. 공부할 것이 많았다. 개발 스택만 하더라도 모르는 것이 정말 많았는데 공부하느라 정말 급급했던 것 같다.
프로젝트를 관리하고 할 일을 이슈로 남기고 하는 이런 일련의 과정 모든 게 처음이어서 정말 배울게 많았다..
특히 백엔드 개발자 분들과 얘기할 때 AWS에 대한 지식이 거의 없어서 소통하는데 다른 프론트분들이 도와주셨다..😞
(헥사고날..? Eureka..? 내가 정말 백엔드에 무지했구나를 경험한 순간이었다.)
이때 프론트라도 백엔드와 소통을 하려면 백엔드 지식을 가지고 있어야 한다는 것을 뼈저리게 느꼈다.
그리고 우리는 PR을 날리면 코드 리뷰어의 리뷰를 받아야 merge를 할 수 있었는데, 이 부분에서 다른 프론트 분들이 코드에 관해 많이 알려주셔서 너무 감사했다.
"이 부분은 이렇게 수정해 보면 좋을 것 같아요~, 라던지 비효율 적이어서 리팩토링 하면 좋을 거 같아요~" 같이 꼼꼼하게 리뷰를 해 주셨는데 유료강의를 받는 느낌이었다..🥹🥹 돈 내고 리뷰받아야 하는 게 아닌가 하는 생각이 들어서 정말 감사했다.
모르는 게 많았기 때문에 개발을 하면서 구현을 하는데 급급했다 보니 스스로 놓치는 부분이 많았다.
(다국어 지원이나, 변수명 작성, 의미 없는 String Literal 등등.. 여러 부분에 있어서 실수가 있었다,)
하지만 지적을 통해 나의 문제점이 무엇인지 알게 되었고 다음엔 실수를 안 하기 위해 의식해서 코드를 짜다 보니 나중엔 봐줄 만한 코드를 짤 수 있었다. 이때 정말 프론트 실력이 많이는 것 같았다.
나도 나중에 여러 부분을 알려줄 수 있는 개발자가 될 수 있다면 좋을 것 같다.
마무리
이 프로젝트를 통해 나의 세계가 한 단계 커진 느낌이들었다.
개발만 급급히 하던 단계에서 그 외의 것들을 살펴본 느낌이었다.
앞으로 어떤 방향으로 성장해야 하고 나의 부족한 점들이 명확하게 보이는 순간이었다.
정말 문화도 좋고 체계적인 팀이었다. (정말 감사했습니다..🥹)
이런 좋은 문화들을 가지고도 왜 프로젝트가 중단되게 되었는지 이해하기 어렵지만..
사실 다들 현업을 하시다 보니 사이드 프로젝트까지 진행할 여력이 되지 않은 것 같다.
어떤 개발 유튜브에서 아래와 같은 얘기를 듣고 꽤나 인상 깊었다.
좋은 개발자 좋은 코드들이 어떤 모습인지 확인해라. 좋은 코드를 짜기 위해서는 좋은 코드를 보는 눈이 필요하다.
만약 내가 나중에 프로젝트의 팀장이 된다면 이런 문화를 만들고 함께해 줄 팀원들과 프로젝트를 만들어보고 싶다.
결국 좋은 서비스는 개발을 잘하는 사람이 아니라, 좋은 사람들로부터 나오는 것 같다.
앞으로 좋은 사람들을 많이 만날 수 있는 기회를 스스로 만들어 나가야겠다.
또 그런 사람들을 만났을 때 이번처럼 부끄럽지 않도록 나의 부족한 점들을 채울 수 있도록 해야겠다.
'활동 > Poom (ZeroWasteShop)' 카테고리의 다른 글
| Github Action으로 한단계 성장..? (0) | 2023.08.04 |
|---|---|
| 주니어 프론트 개발자의 Storybook 경험담 (0) | 2023.07.25 |