CheQuiz 프로젝트

DevLog

0606

• 오랜만에 서비스 기획을 하게 되었는데, 아이디어 브레인 스토밍 단계에서 부터 정말 재미있었다.

• Figzam이라는 툴을 사용해 브레인 스토밍을 진행하였는데, 동시작업시 딜레이를 거의 느낄 수 없었고, figma와의 요소 호환등으로 문서 협업 도구로서 굉장히 매력을 많이느꼈다.

• 학습을 위한 프로젝트이지만, 뻔한 클론 형식의 프로젝트 보다는 내가 느꼈던 문제를 조금이나마 해결할 수 있는 아이디어로 프로젝트를 진행하고 싶었다.
• “캘린더의 일상기록 챌린지 + 레벨링 제도 도입” 라는 팀원들의 아이디어와 “개발지식 측정 + 퀴즈" 라는 나의 아이디어가 합쳐져 코딩테스트 이외의 가볍게 개발 지식을 확인할 수 있는 앱을 만들어보자는 아이디어로 구체화 되어 선정되었다.

• 문제를 해결하기 위해 다양한 아이디어를 쏟아내는 과정과 토의 혹은 토론 과정들이 참 즐겁다는 생각을 많이 하게 되었고, 뻔하지 않은 아이디어가 빠르게 나온 것에 감사했다.
• 좋은 사람들과 좋은 아이디어를 좋은 프로젝트로 만들어, 우리가 가졌던 문제들을 조금이나마 해결하고 싶은 바람이다.

0607

• 모든 팀원이 온라인이 아닌 오프라인에서 만나는 것은 처음이었다.
• 확실히 이야기를 주고 받는 타이밍이 빠르고, 비언어적인 행동들을 통해 그 사람의 생각을 조금 더 빠르게 받아들일 수 있었다. 내가 근무를 하게 된다면, 풀 재택 보다는 출근을 하는 회사를 조금 더 선호하는 이유이기도 하다.

• 오프라인으로 회의도 같이 진행하고, 끝나고 가벼운 치맥 회식도 하면서 이런 저런 이야기를 많이 나누었다.

• 유사한 환경 속에서 같은 목표를 가지고 있는 사람들이기 때문에, 후회하지 않도록 열심히 참여해서 좋은 성과를 이루어내고 싶다.

0608

• 5명의 팀원 중 2분의 개인 사정으로 3명에서 와이어프레임 작업을 진행하였다.
• 확실하게 느낀 것은 줌은 4명일 때 부터 소통의 효용성이 급격히 저하된다고 느꼈다. 3명이 되어도, 자신의 생각을 자주 멈추지 않고 바로바로 이야기할 수 있는 환경이 나오는데, 그 숫자가 4명 혹은 그 이상이 될 때에는 아무래도 말하기 전 딜레이가 걸리는 상황이 자주 발생한다.

• 요구 분석에 관한 유명한 짤과 같이, 본격적인 개발을 들어가기 앞서 팀원들이 생각하는 그림을 일치시키는 것이 정말 중요하다고 생각했다.
• 이번 와이어프레임을 그리면서도 느낀 것이 눈으로 보는 UI를 통해 이야기를 나누니, 애매하게 텍스트로 이해했던 부분들을 각자 다르게 이해한 부분도 있었고, 데이터 설계에 영향을 미치는 부분도 있었다.
• 디자인에 감각있는 훌륭한 팀원분이 있어서 수월하게 와이어프레임 작업을 이어나갈 수 있었고, UI 와이어프레임을 기반으로 다시 한 번 feature들을 세부 점검할 수 있었다.

0609

• 백엔드 서버가 모든 데브코스 팀원들에게 사용가능한 구조라서, 각 팀에 맞게 custom하여 사용할 수 있는 여지가 있었다. 따라서 custom 속성들과, 우리 팀의 특정 기능들에서 사용할 API 명세서 작성이 필요하였고, Notion과 Postman을 사용하여 문서화 하였다.

• 이번 프로젝트에서는 크게 5가지의 feature가 존재하였는데 ( 회원관련/ 퀴즈 생성 / 퀴즈풀이 / 유저정보 / 랭킹) 그 중에 퀴즈생성 feature를 맡게 되었다. form을 다루는 부분을 개발해보고 싶어서 생성 부분을 맡기를 희망하였는데, 뽑기 운도 좋았고, 팀원들도 그런 부분을 알았는지 feature 선정에서 배려를 받은 느낌이 들어 감사했다.

0610

• 기존 gitHub 이슈를 사용하여 프로젝트를 관리하고자하였는데, issue와 프로젝트 칸반만으로는 팀원들이 어떤 부분을 하고 있고, 또 이슈단위들이 작아지다 보니, 어떠한 맥락에서 이루어지고 있는 작업인지 파악하기 어려울 것이라는 생각이 들었다.

• 이전 인턴활동 때 팀에서 사용하고 있던 ZenHub가 떠올랐고, 이를 활용하여 Epic 단위의 일정관리를 도입한다면, DailyScrum과 전체 프로젝트의 진척도를 파악하는데 큰 효율을 가져올 것이라 생각하고 팀원들에게 ZenHub설명과 얻을 수 있는 장점을 설명하며 도입을 제안하였다.

• organization 허가 부분에서 조금의 이슈가 있어, 생각보다 도입하는 것에 애를 먹었지만, 성공적으로 도입할 수 있었고, 앞으로의 프로젝트 진행 중 ZenHub의 여러기능 중 비용 대비 효과가 좋은 기능들을 잘 살펴보아야 겠다.

0613

• 기능 개발 중 올라온 준혁님의 PR

• (me)해당 PR이 로직확인용 인지, merge를 위한 PR인지 확인 요청 ⇒ 로직확인용 대답 받음

• (me) 코드는 공통 책임이라고 생각하여, 상세하게 리뷰 작성

• (준혁) 일부 코드 리뷰 반영 및 새로운 기능 추가되어 merge 됨

• (me) 리뷰에 대한 의견 없는 것들 존재한 상태에서 바로 merge 된 점 새로운 기능에 대한 부분은 누구에게도 리뷰된 부분 없이 스텔스 merge 된 점 에 대한 문제 제기
• comment 해결안 된 부분 궁금하면, 닫힌 PR에 다시 요청해야하나?
• 이미 리뷰 없이 merge된 새로운 기능에 로직오류 있을 수 있지 않나?
• 왜 어떤 의사소통이 없이 이렇게 되어버린거지?ㅇ.ㅇ

• issue와 브랜치를 연결하여, 하나의 issue/branch에서 기능을 개발하려고 하다보니 추가로직이 같은 issue/PR에 들어가게 되었다.

• 처음 부터 하나의 완성 된 기능에 대한 PR이 아닌. 작업 중인 PR을 올린 것이 문제의 발단이라고 생각

• (to Me) 프로젝트의 모-든 코드들이 나의 생각을 이해시키고, 만족시켜야 한다면, 오히려 그것이 개인프로젝트에 가까울 수도 있다고 생각. 코드 리뷰 강도에 대해서 조금 낮추어도 된다고 이야기 주셨다.
• (me) 여기서 조금 다른 관점으로 생각해보게 됨. 내 스타일은 최대한 좋은 코드만 담으려고 노력하고, 그것이 좋은 프로젝트라고 생각했는데, 지금 처럼 2주라는 짧은 기간이 정해져있다면 그 기준을 조금 낮추어도 되지 않을까 생각
• 1~10을 다 채워야할 때, 나는 1,2,3,4,5 …, 채우는 방법에 가깝다면, 1,3,5,7,9를 만들고 이후 2,4,6,8,10 을 채우면 되니까! 시간상 중간에 끊기게 되었을 때, 12345 보다는 1,3,5,7,9가 완성도 측면에서 더 높은 점수를 받을 수 있으니까!
 

• 프로젝트 단에서의 코드 기준 및 관리와, 실제 서비스단에서의 코드 기준 및 관리가 다를 수 있다고 생각

• 개인 < 프로젝트 < 서비스단 이 존재한다면, 준혁님은 개인과 프로젝트 중간에 어딘가를 기준으로 설정하였고, 나는 프로젝트와 서비스단 어딘가를 기준으로 생각하고 있어 발생한 문제라고 판단함

• 앞으로 리뷰의 정도는 어떻게 해야할까?
• 뾰족한 정답이 없는 부분에 대한 이슈가 있을 때는 그냥 넘어가는 것이 좋은가?
• 프로젝트 전반에 통일성이 유지가 안되어도, 우선은 “basic First, advance Later Due to TimeLimit“ 정책에 의해 넘어가는 것이 맞는가
• 이해되지 않는 코드들이 프로젝트에 존재하는데, 내 담당 부분이 아니니까..라는 식으로 넘어가는 것이 맞을까..

• 핵심 로직에 대한 큰 이슈가 없다면, 나머지는 개인의 코드 스타일을 최대한 용인하자. 팀적으로 컨벤션으로 정할 정도가 아니라면, 비슷한 패턴이 개인의 스타일로 조금 다르게 작성되어도 용인하자

• 2주 프로젝트 기간 이후 끝나는 것이 아니므로, 기본기능을 만족할 수 있도록 조금 더 러프한 리뷰기준을 가지고 프로젝트에 참여하고, 2주 프로젝트 후, 한 번 더 나의 기준에 맞게 코드리뷰를 다시하여 리팩토링에 반영할 수 있도록 제시하여보자.

• 개선액션 리뷰 올라온 부분을 반영하지 못하고, 바로 merge한 이후 통보 하는 것보다, “아직 해결되지 못한 부분이 있다면, ~~한 부분의 답을 정하기 힘들어 merge 하려고 한다. 한 시간 후 merge예정인데, 혹시 한 번 필요 부분 검토 후에 수정사항 필요한 곳 있으면 comment 달라. 없다면 merge 진행하겠다.” 정도로 이야기하면 좋지않을까

0614

• 생각보다 개발 속도가 나지 않아 어느순간 조급한 마음이 들었다.
• Problem개발 2일차가 되자, 팀원들의 PR이 하나 둘 셋 넷 올라오게 되었는데, 올라온 직후 바로바로 리뷰를 처리하다 보니, 내 개발 작업에 대한 흐름을 많이 놓친다는 생각이 들었다.
• Action PR이 올라왔을 때, 바로 처리하기보다는 당장 시급한 PR이 아니라면, 코어타임 이후 저녁시간이나, 코어타임 이전 오전 시간에 리뷰를 따로 작성하고, 코어타임에는 온전히 개발에 집중하는 것을 시도하고자 한다.

• 쉽지만 빠르지는 않다.
• QuizForm 작업을 맡아 진행하면서 느낀 점은, 크게 어려운 부분은 없지만, 그만큼 빠르게 쳐내고 있지는 못하다는 느낌이었다.
• devcourse에서 배웠던 부분과 source등을 활용할 수 있는 부분이 많아서, 어렵고 막히는 부분은 거의 없었지만, 막상 흐르는 시간을 보니, 시간 대비 효율적인 코드를 작성하고 있는가에 대한 의문이 들었다.
• 이전 부터 느끼고 있지만, 하나의 기능을 추가할 때, 너무 많은 생각을 하고 있다고 느꼈다. 심플소프트웨어 책에서 미래가 아닌 현재에 집중하고, 작성하고, 수정의 반복을 통해 개선하라는 말이 있었다. 어느정도 로직이 그려졌다면, 과감하게 코드화하고, 다시 수정하는 방식을 조금 더 강화해야겠다.
 

0615

• 말하면서 배워요에서 2번의 KPT 회고를 하면서 느낀 점은, 이 회고 방식이 “작아 보이는 문제들을 수면위로 올리는 역할”을 해서, 결과적으로 “팀의 생산성 향상”에 정말 큰 영향을 준다는 점이었다.

• 이번 회고는 특히 개발적인 것들 보다 소통의 이슈가 많이 존재했기 때문에, 너무나 필요한 시간이었고, 나 역시도 이야기를 해야하나 말아야하나 고민했던 부분들을 꺼내놓을 수 있었다.
• 그 중 “가볍게 물어보기” 가 가장 대표적이었는데, 작은 모르는 문제가 나왔을 때, 그냥 물어보면 편하게 바로 알 수 있을 것을 다른 사람을 방해하는 느낌이 들어, 혼자 낑낑대는 시간이 많았다. 서로 눈치 보지 않고, 바로바로 소통하는 것이 결국 팀의 개발속도를 올린다는 점을 나누었고, 적극적으로 작고 많이 빠르게 소통하기 위한 단계들을 설정하였다.
• 재직과정에 있어 작업시간대가 다른 정환님과의 소통문제도 주요 이슈였는데, 팀 노션의 공지사항과 화이트보드 도입, 코어타임 때 나눈 이슈들을 문서화하여 전달하는 방법 등 구체적으로 실행할 수 있는 여러가지 룰을 도입하게 되었다.
• 또 크게 공감갔던 이야기 중 하나는, 현재 진행하는 프로젝트의 담당 부분들이 “어렵지는 않다고 느끼지만, 작업시간은 오래걸린다”는 이야기 였다.
• 이를 다시 해석해볼 때, 결국 React 코드를 자유자재로 다룰 만큼 익숙하지 않고, 불필요한 확장성등을 고려하느라 생각의 시간이 너무 길다는 결론에 도달하였다. 최소단위 기능을 고려하며, 현재 코드와 로직에 집중해서 생산성을 올려보아야곘다.

• 중간발표 영상의 경우 내가 먼저 찍어 올리겠다고 선언하였는데, 사실 미해님이 디자인 감각이 있어, 디자인 작업에 많은 시간을 할애하여 개발시간이 부족함에도 불구하고, 전혀 내색하지 않고 해주시는 것에 대해 너무 감사하기도 하였고, “각자 잘할 수 있는 부분이 있다면 적극적으로 자진해서 하는 모습, 문화”를 만들고 싶었다.
• 그래도 홍개팅등 기획문서를 작성하고, 발표를 한 경험이 있기 때문에, 발표 흐름만 같이 잡고, 자료 및 발표를 통해 우리 팀의 서비스에 대해 더 잘 어필할 수 있다고 생각하였고, 그렇게 발표 영상을 촬영하게 되었다.

0622

• 프로젝트 마무리를 하면 돌아본 나의 장점
• 이번 프로젝트를 돌아보며, 소통의 측면에서 나의 강점을 재확인할 수 있었던 부분이 있었다. 단순히 관계가 완만하고, 잘 들어주고, 잘 전달하는 것이 아닌, ”소통비용을 줄여서 팀적인 생산성을 높이는 것” 에 기여했다고 자부한다.
• 재직자 팀원으로 소통이 반복적으로 일어나 소통비용이 크게 증가할 때, ‘노션 화이트 보드 제도’를 통해 이슈에 대해 빠르게 공유하고, 문서화를 통해 절대적인 소통시간을 감소시켰다. 또 KPT 회고를 중간, 최종 총 2회 리드 진행하여, 중간회고 이후 팀적으로 소통의 증가, 생산량의 큰 향상을 경험하였다.

• 회고
프로젝트 진행 중 가장 인상 깊었던 점은, 진행 초기 프로젝트 코드 기준에 대해 의견을 나누었을 때 이다. 나는 2주라는 짧은 기간에도 높은 코드기준과 코드리뷰방식을 제시했고, 팀원은 2주라는 짧은 기간의 프로젝트에서는 기준을 낮추어 빠르게 작성하고, 리팩토링을 하는 방법을 이야기하였다. 나는 의문을 가졌으나, 12345만이 아닌 13579 이후 2468을 채울 수 있다는 것을 받아드리고 해당 의견을 수용하였다. 그리고 프로젝트가 끝난 지금 정말 훌륭한 결정이었다고 생각한다. 기본 basic기능만으로도 시간이 빠듯했던 지금, 욕심내어 advance 기능과 높은 코드기준 및 리뷰를 가져갔다면, 오히려 코드적인 부분과 결과물에 있어서도 아쉬움이 남았을 것이라 생각한다.
’심플소프트웨어’ 책에서도 최근 읽었던 부분이지만, 문제를 쪼개고, 미래가 아닌, 지금 현재의 작은 문제를 차례대로 해결해나가는 것이 가장 빠른 길이라는 생각이 들었다.
팀내 소통 이슈도 있었지만, 정말 평화로운 토의와 노션문서화, 슬랙과 디스코드에서 바로바로 말하기 등의 액션을 시도하여 큰 효과를 볼 수 있었다.
개발적으로는 큰 어려움이 없어, 안주하고 있는 것이 아닌가라는 생각도 잠깐 들었지만, 앞으로 프로젝트 이후에도 advance 개발진행 계획을 세웠으므로, 더 나은 어려움과 해결과정을 겪을 수 있을 것이고, 그 중에 좋은 팀원들과 함께할 수 있다는 생각에 마무리하는 지금 정말 기분이 좋았다.