서론
레벨 4를 마무리하는 현 시점에 레벨 3, 4동안 피움 프로젝트를 진행한 전체적인 과정과 소감에 대해 회고를 해보려고한다.
인상깊었던 사건을 기준으로 피움 프로젝트를 돌아보자.
신뢰 자본
최근 신뢰자본이라는 용어를 접할 일이 있었는데 피움 프로젝트를 진행하기에 앞서 이러한 신뢰 자본을 잘 쌓았는가? 에 대한 생각을 해보게 된다.
대뜸 모르는사람이 와서 API 짜주세요!, 저는 이런 기획을 생각하고있어요!!라는 말부터 시작하면 적잖이 당황스러울 것이다.
일단 서로 친해져야 의견도 적극적으로 제시할 수 있고 다른 사람의 의견도 들어줄 마음이 생길 것이다.
우리는 기계랑 일하는게 아니다. 사람과 함께 일을 하기 때문에 친근함은 당연하게도 업무의 효율성에 영향을 미칠 수 밖에 없다고 생각한다.
여기서 말하는 업무의 효율성은 회의시간에 나오는 소통비용과 사적으로 나누는 잡담에 대한 부분까지도 모두 포함한다.
팀원들과 만나기 전에 아이스브레이킹 항목도 생각해보고,
팀원들이랑 첫 회식도 주최해보기도 했다.
과거의 회고들을 보면 은연중에 이런 노력들을 하고 있던 모습이 보인다.
의도하지는... 않았으려나? 잘 모르겠다.
스스로는 잘 하고 있었다고 생각한다. (아닐수도 😅)
기획 - 스프린트
처음에 조이의 식물과 함께라는 아이디어에 함께 참여하게되었다.
하지만 스케줄링, 추천, 챌린지, 커뮤니티라는 기능들을 모두 구현하기에는 일정이 빠듯했기 때문에 현실적으로 구현하기 어려운 부분을 제거했다.
그러다보니 해당 서비스가 정확히 누구를 위한 서비스인지 구분하기가 어려워졌다. 단순히 커뮤니티, 챌린지 기능만을 남겨두자니 이 기능이 해결해야하는 문제가 보이지 않았다.
다른 서비스와의 차별점도 한몫했다.
이를 구체화 시키는 과정이 당시에는 꽤나 고통스러운 과정이라고 느꼈던 기억이 난다.
추상적이고 비타민이 가득한 프로젝트를 어떻게 작은 진통제로 바꿔야할지 감이 도무지 오지 않았었다.
비타민: 본 글에서 서비스 대상에게
즐거움이 주된 목표가 되는 서비스를 일컫는 말로 사용한다.
진통제: 본 글에서 서비스 대상의불편함을 해결해주는 것이 주된 목표가 되는 서비스를 일컽는 말로 사용한다.
우리 팀은 명확한 Pain Point를 도출하기 위해 구글 스프린트 과정을 도입했었고, 해당 방식에 대해 경험이 있던 쵸파의 진행하에 기획이 진행되었다.
아이디어 도출과정에 대한 틀과 흐름이 있어서 마음이 놓이는 구석이 있었다.
아날로그로 포스트잇을 붙여가면서 이벤트 스토밍을 진행하던 팀도 몇몇 보였는데 Figjam은 아날로그의 번거로움을 많이 줄여줬다. 팀원들 모두 툴 사용에 거부감이 없었기 잘 진행될 수 있었다고 생각한다.
추가로 늘어지는 시간이 없도록 진행해준 쵸파의 역할이 독특히 컸던것 같다.
위 스프린트 과정을 거쳐 지금의 피움 서비스가 탄생했다.
나중에 팀 프로젝트를 시작할 일이 있다면 꼭 도입하고싶은 방법과 툴이라고 생각한다.
팀 문화
개인적으로 피움 팀의 그라운드룰은 아주 잘 만든 팀 문화라고 생각한다.
회의
초기에 회의를 하면서 회의에 대한 룰을 정하는 과정이 있었다.
팀원들의 의견을 종합해봤을 때 일반적으로 회의라고 했을 때 다음과 같은 문제들을 주의해야한다는 것을 알 수 있었다.
문제점
- 회의 도중에 이야기가 다른곳으로 샌다.
- 팀이 수평을 추구할수록 결론이 나기 어렵다.
- 추후에 중복된 논제로 이야기를 나눌 때가 있다.
- 회의의 방향성이 명확하지 않은 채로 두리뭉실하게 시작되면 회의가 끝나고 남는게 없다.
- 회의 시간에 한명만 말하는 상황이 생기기도 한다.
위와 같은 상황들을 고려하여 회의 시간에 다음과 같은 룰을 정했다.
모두가 데일리 마스터
- 데일리 마스터는 매일 번갈아가며 진행한다.
- 의사결정이 미뤄지는 경우 데일리 마스터에게 결정권한이 주어진다.
- 회의시간에 데일리 마스터가 손을 들면 하던 이야기를 멈추고 주목한다.
이 덕분에 회의가 방향성을 잃지 않고 원활하게 진행될 수 있었다.
만약 이 룰이 없었다면 아직까지 방향성을 못잡고 기획만하고 있었을거라고 생각한다.
팀 내에서 조이가 이 룰을 가장 잘 활용했다고 생각한다.
매번 회의를 할 때마다 흐름을 잘 이어나가주는 역할을 독특히 잘 해내주었다. 👍
침묵은 부정의 의미로 해석한다.
어떤 의견이 제안되고 반응이 없다면 의견을 제시한 사람의 입장에서 상당히 무안하다..
내 말은 제대로 듣고 있는건지 회의가 진행되고있는것인지 의심되기 시작한다.
이 때 침묵을 유지하고 있는 사람은 무조건 부정하고있다고 해석하기로 했고 해당 의견에 부정한다면 이유를 물어보기로 했다.
팀 내에서 그레이가 이 역할알 가장 잘 해줬다고 생각한다.
회의에서 정적이 일어날 때 마다 가장 먼저 교통정리를 해주는 역할을 잘 수행해주었다. 👍
회의록을 작성하는 서기
회의시간에 나온 안건이 결정되기까지는 상당히 많은 에너지가 쓰이고 이 과정에서 충돌과 이해과정이 여럿 얽혀있을 수 있다.
기획 과정에서 많은 회의를 하는데 이러한 설득 과정을 모두 기억하기에는 조금 무리가 있다.
이에 Github Discussion을 활용하여 회의록을 작성했다.
물론 데일리마스터와 동일하게 팀원들 모두 돌아가면서 서기를 진행했다.
그 중에 참새가 이 역할을 정말 잘 수행해줬다고 생각한다.
회의 시간에 가벼운 대화에서부터 프로젝트에 중요한 안건으로 이어지는 경우도 종종 있었는데 이 때 마다 가장 적극적으로 회의 내용을 기록해줬다. 👍
기록
프로젝트를 진행하며 기록을 남기고싶다는 개인적인 욕심에 회고, 팀 기술블로그, Github Wiki 활용을 제안했는데 흔쾌히 받아주는 팀원들의 모습에 감동받았었다.
말을 꺼냈기 때문이였을까 이러한 문화가 지속될 수 있는 환경을 구성해야겠다는 책임감이 생겼다.
팀 블로그
후디의 gatsby-starter를 활용하여 만들었다.
멋진 블로그를 양식을 만들어준 후디에게 다시한번 감사드립니다 🙇♂️
글을 작성하는 데 부담을 느끼게 되면 꾸준한 기록에서 멀어질 것이라고 우려했기 때문에 팀 블로그 글 작성에는 특별한 규칙을 두지 않았다.
팀 블로그를 구축한 사람만 글 작성방법을 알고 있기 때문에 이를 최대한 다른 팀원들도 손쉽게 사용할 수 있도록 글 작성 방법도 데일리 미팅 시간에 설명했었다.
마크다운형태로 자유롭게 작성하는것을 핵심으로 두었다.
글의 예시가 있으면 다른 글의 작성에 도움이 될 것이라고 생각했기에 첫 글은 최대한 가벼운 내용의 글로 작성하려고 했던 기억도 난다.
우테코를 마무리하고 있는 현 시점에서 자료들을 돌아보면 꽤나 양질의 자료들이 많이 쌓여있는 것을 확인할 수 있었고, 나도 모를 뿌듯함을 느꼈다.
팀 노션
Notion도 만들고 꾸준히 개선했다.
어떻게하면 메뉴를 복잡하지 않게 구성하면서도 접근성이 좋게 만들 수 있을지를 생각하며 개선하려고 했다.
가장 자주 활용하는 데일리미팅 회의록에 대한 템플릿을 구성해둠으로써 문서화에 대한 부담을 줄였다.
discussion 또한 적극적으로 활용하기 시작하면서 보다 생산적인 회의를 진행할 수 있었다.
회의록 생성 시 해당 템플릿을 누르면 아래와 같은 형태로 양식이 나온다.
각 TODO는 메인 화면의 캘린더와 연동시켜놔서 일정을 한눈에 보기 쉽게 구성해놨다.
기획은 팀원 전체가, 개발은 각 트랙별로 진행하기 때문에 개발실이라는 탭도 따로 만들었다.
공통으로 확인해야할 문서에 대한 부분은 개발실 메인페이지에 두고 각 트랙별로 이야기할 개발 관련 논의는 세부 트랙별 페이지에서 진행할 수 있다.
백엔드 개발부서 조이가 예쁘게 꾸며줬다 👍
팀 Wiki
팀의 다양한 내용을 소개하는 Wiki를 적극적으로 활용했다.
문서를 작성할 때 다음과 같은 상황을 계속 생각하면서 작성했다.
후임 개발자가 우리 프로젝트에 왔을 때 과연 Wiki에 있는 문서만으로 충분히 이해하고 개발을 진행할 수 있을까?
그만큼 더 꼼꼼하게 작성하려고 노력을 기울였던 것 같다.
참고로 Wiki의 우측 사이드바는 자동이 아닌 수동이다.
생성된 Page에 대해 일일히 링크를 걸어준 것이다.
물론 지금도 많이 부족하긴 하지만 프로젝트 구성원, 프로젝트의 방향성, 사용한 기술에 대한 이해는 어느정도 할 수 있을 것이라고 여겨진다.
프론트엔드
프론트엔드 분야를 정확하고 세세하게는 알지 못하지만 그래도 어느정도 이야기는 될 수 있게끔 프론트 분야와 소통을 자주 시도했다.
모든 내용을 다 알 수는 없지만 클라이언트와 소통하기 위해 대략적인 키워드와 용도에 대해 알아두려고 노력했다.
리액트,css,컴포넌트,렌더링,fetch,상태관리,console log,npm,yarn등등
로컬에 프론트엔드 프로젝트가 구동될 수 있는 환경을 구축하기도 했었는데 이 덕분에 로컬로 프론트, 백엔드 프로젝트를 띄우고 프론트분들이 캐싱 관련 문제를 디버깅해볼 수도 있었다.
어드민 페이지를 만들 때 javascript를 작성해야하는 경우가 있었는데 질문을 많이 받아주시고 다양한 인사이트도 제공해주셔서 감사했다.
프론트엔드 개발자로서 팀원들의 특색도 살짝 엿볼 수 있던 것 같다.
CSS를 예쁘게 꾸미고 생산성이 빠른 쵸파, 코드 품질에 항상 신경을 쓰며 리팩터링에 집중하는 참새, 새로운 분야에 대한 탐구와 다양한 시도를 좋아하는 클린
옆에서 살짝 본 정도라 정확하진 않을 수도 있지만 적어도 내가 옆에서 단편적으로 봐온 프론트엔드 팀원들의 성향은 이렇게 느껴졌다.
세 팀원 모두 프로젝트에 대한 열정과 개발에 대한 열정이 대단하다 👍
이러한 경험은 트러블 슈팅 및 QA, 일정추산을 위해 많은 도움이 되었다.
일거리 만들기
레벨 4를 시작하며 백엔드는 주어진 요구사항을 만족하는 것도 살짝 벅찬 일정이였기 때문에 레벨 4에 무엇을 할까? 에 대해 명확한 방향을 잡을 수 있었다.
그러나 프론트엔드는 더 이상의 고도화를 할 내용이 없다고 했다.
서비스 특성 상 사용자의 즉각적인 피드백을 바라기가 어렵기도 하고 유저 풀을 넓히기 위한 노력을 이 이상으로 들이기도 시간적, 공간적으로 애매한 상황이라는 이야기가 나왔다.
잘은 모르겠지만 뭔가를 도전하고 싶은 프론트엔드 팀원들의 요구사항이 간질간질하게 있던 것 같았다.
무엇을 개선해야할지 인지하지 못하고있는 이 상황이 너무 안타까워 이 회의를 한 날 밤에 집에가면서 학교 친구 한명 붙들고 서비스 QA를 와르르 했다.
이후의 몫은 프론트 팀원분들에게 전적으로 맡겼다.. 🙇♂️
프론트 일거리만들기 장인이랄까..
최근에 PWA QA도 열었다..
PWA 와르르 QA discussion
트러블 슈팅
데모데이 전날에 ios에서 브라우저 랜더링이 안되는 문제가 있었다.
개발서버에 프론트엔드 FCM 기능을 적용하고 배포했을 당시의 일이다.
안드로이드는 잘 동작하는데 ios 환경 (맥북말고 아이폰)에서 브라우저 렌더링이 안되는 문제가 발생했다.
집에 돌아가는 지하철에서 너무 원인이 알고싶었다.
핸드폰에서 디버그 모드를 켜보고싶어 집에 도착하자마자 아이폰과 맥북을 연결하고 디버그 모드를 켜고 콘솔을 확인했다.
클린이 멋지게 해결해줬던 경험이 생각난다.
클라이언트 문제냐 서버 문제냐 할 것 없이 함께 트러블 슈팅을 하고 원인을 찾아주는 경험이 꽤나 즐겁고 뿌듯했던 생각이 난다.
백엔드
백엔드의 기술적인 내용은 팀 블로그에 모두 게시되어있으므로 별도로 정리하지는 않겠다.
조이, 그레이, 하마드 모두 학구열이 대단한 팀원들이다.
백엔드 전체적으로 협의해야하는 내용이 있을 때 마다 모여서 탐구해봤던 경험이 기억에 남는다.
Entity 동등성
인텔리제이가 만들어주는 Equals & HashCode의 형태가 조금 이상하게 생겨서 왜 이렇게 생겼을까? 라는 의문점에서 시작되었다.
백엔드 팀원들이 옹기종기 모여 Equals를 다양하게 정의해보고 각 상황별로 테스트를 하면서 학습을 했던 경험이 좋았다.
이때 논의한 내용도 discussion에 정리해뒀다.
discussion - JPA 엔티티의 동등성 비교
Pageable
프론트엔드와 협업을 진행하면서 페이징이 0부터 시작하냐 1부터 시작하냐에 대한 고민도 꽤나 많이 했다.
아주 간단한 내용이지만 막상 구현하기 위해 클라이언트, 서버가 맞춰나가야하는 부분이라 협의도 꽤나 꼼꼼하게 하려고 했다.
백엔드에서 어떤 상황을 고려해야하는지를 먼저 정리하는 과정에서 많은 의견들이 나왔던 것이 기억난다.
협업
페어로 작업하는 과정도 꽤나 인상깊었다.
프론트엔드, 백엔드 모두가 한번 이상은 협업을 진행했었다.
- 클린 & 조이의 로그인 기능 구현
- 클린 & 그레이의 Jenkins 설정
- 클린 & 주노의 알림 기능 구현
- 쵸파 & 조이의 모두의 정원 기능 구현
- 참새 & 그레이의 이미지 업로드 기능 구현
- 참새 & 하마드의 식물 등록요청 기능 구현
뭔가 더 있던거같은데.. 기억이 안난다 😅
자잘 자잘
나는 어느 집단에서든 남들이 귀찮아할만한 일들을 주로 맡아서 한다고 생각한다. 개인적으로 자료를 만들거나 문서화를 하는 등의 작업에 대해 스스로의 생산성이 좋다고 생각하기 때문에 그런것도 있는 것 같다.
항상 주력으로 내세우기는 좀 그렇지만 자잘하게 해소했었던 팀 내 어려움(?) 들을 여기에 적어보려고한다.
진짜 별거 아닌 일이여도 스스로가 은연중에 해낸 작은 일들을 모아두면 뿌듯할 것 같아서 정리해본다 :)
피우미 아이콘 제작
팀원들 다같이 팀 아이콘을 구상해보는 시간에 keynote로 끄적끄적하다가 나왔던 친구다.
메인 로고로는 활용되기 어려웠지만 favicon, 로딩스피너, 404페이지 등 다양한곳에 소소한 디자인 요소로 활용되었다. 👍
노션 꾸미기
개인적으로 정리에 조금 집착하는 면이 있어서 나도모르게 시간 날때마다 노션 정리를 와르르 해버리곤한다.
정리를 와르르 해놨을 때 팀원들이 너무나 잘 활용해줘서 기분이 너무 좋았다 👍
서버 이미지 최적화 쉘 스크립트
서버이미지 최적화를 위한 개발 일정을 투입하기에는 미리 추산한 일정을 초과하는 업무였기 때문에 Application단에서 해당 작업을 처리하기가 어려웠다.
때문에 서버에 쉘 스크립트를 작성하여 이미지 압축 작업을 수행했다.
이 과정에서 참새가 nodejs로 압축 로직을 만들어줘서 손쉽게 작업을 진행할 수 있었다.
해당 코드는 깃허브에도 올려뒀다.
팀 블로그 생성
항상 초기 블로그 세팅은 골치가 아프다.
약 3일을 투자해서 팀 블로그를 만들었다.
이 과정에서 gatsby, node 버전문제 등등 꽤 자잘한 트러블 슈팅들이 있었다.
자세한 과정은 팀 블로그 - 피움 블로그 생성과정을 확인
팀 식물 키우기 추진
식물 도메인을 다루는 만큼 팀에서 식물을 키우면 좋겠다는 생각을 초기부터 가지고있었다.
중간중간 "팀에서 식물 키우는거 어때요?"라고 팀에 질문을 했을 때 긍정적인 반응이 나오는 것을 확인하고 주도해서 식물을 사왔다.
팀 식물 키우기 2차 추진
데모데이 상품으로 고니에게 식물을 줄 일이 생겼다.
다육이 하나만 사서 줄 수도 있었지만 이왕 상품으로 줄 다육이를 사는 김에 우리 팀원들도 하나씩 다육이를 집에 가져갔으면 좋겠다는 생각이 들었다.
일단 총대매고 진행시키는걸 좋아하기에 팀원들의 동의를 구하고 팀원들의 다육이까지 구매했다.
막상 다육이 구매하니까 화분이 너무 별로라서 집에서 직접 분갈이도 해봤다.
이 덕에 식물이라는 도메인 이해도가 꽤 많이 높아졌다. 👍
팀 스티커 제작
개발 외적으로 부수적인 내용에 대해서는 보통 할까요? 만 하다가 흐지부지 되는 경우가 많았다.
때문에 일단 결제버튼만 누르면 될 정도로 시안을 구성한 뒤 피드백을 받는 편이 빠르게 실행할 수 있는 방법이라고 생각한다.
만약 1명이라도 반대하면 그저 아쉬운거지~ 싶은 마음으로 작업을 진행하기 때문에 크게 여의치도 않는다.
정말 다행히도 팀원들이 좋아해줘서 그대로 스티커 제작/주문에 착수할 수 있었다. 👍
개인적으로 이런 자잘한 요소가 팀의 소속감을 증대시켜준다고 생각하기 때문에 자꾸 식물사고, 스티커사고.. 하는것 같다 😅
팀 인스타그램
사용자 유치계획 미션이 나오기 전부터 팀 인스타그램이 있으면 좋겠다는 생각을 했다.
그래서 인스타 계정도 파고 이런 저런 게시글도 올렸다.
사용자 유치계획 미션이 나오고 나서는 아주 많은 쓸모가 있어서 기쁘기도 했다 ㅋㅋㅋ
중간에 카드뉴스도 직접 만들었다.
스스로 keynote로 이런거 만드는거에 대한 생산성이 꽤나 높다고 자부하기 때문에 자처해서 작업을 진행했다.
카드뉴스 만드는데는 약 2시간 30분정도 걸렸다.
jmeter 결과 확인
부하테스트 툴로 jmeter를 사용하고 있는데 네트워크 트래픽으로 인한 예외 상황이 많았다.
이를 해결하고자 dev서버에서 localhost로 요청을 보내게끔 jmeter를 구성했는데 그 결과페이지를 확인하고싶었다.
nginx 설정을 통해 jmeter 결과 파일을 가리키도록 주섬주섬 설정했다.
그 외에도 자잘자잘한 이야기들이 많지만 이정도로도 꽤나 만족스럽다 :)
후기
프로젝트 초기에 모 코치님께서 여기팀은 다 둥글둥글한 사람만 있네요~ 라고 하셨던 말이 기억난다.
정말로 다들 둥글둥글한 사람들이라 팀 내 불화가 단 한번도 없었다.
오죽하면 매 감정 회고마다 우스갯소리로 "갈등상황이 없는게 아쉽네요~"라는 말이 나올 정도다.
어디가서 또 이런 팀원들과 함께 일할 수 있을까 싶을 정도로 정말 좋은 팀원들이였다.
낯간지러운말은 Wiki에 와르르 적어놨으니 보고싶다면 Wiki에서 확인하길 바란다..
레벨 3, 4동안 함께 프로젝트하며 고생한 우리 팀원들에게 박수 👏👏👏
즐거운 프로젝트를 할 수 있어서 행복합니다 👍
피움팀 정말 고생많이했서요! 우테코가 끝나더라도 오래오래 갔으면 좋겠습니다 👍