About Team management

1. 정말 쉽지 않았던 프로젝트 기획

프로젝트 기획을 3번을 갈아엎었다. 갈아엎은 횟수만큼 와이어프레임, API 명세서를 다시 작성해야했다. 그래서 원래 일정 상으로는 04.23(월)부터 착수해야했던 API 1차 구현을 04.29(금)에서야 돌입할 수 있었다.

프로젝트 기획이 여러번 변경되는 건 자연스러운 일이라고 생각한다. 포트폴리오 목적으로 진행하는 프로젝트인만큼, FE, BE, DESIGN 모든 파트가 만족할 수 있어야 하는 프로젝트가 기획되어야 하기 때문이다.
다만, 기획 과정에서 팀장으로서 팀원들의 의견 논의 과정을 매끄럽게 조율하지 못했던 것이 몹시 큰 아쉬움으로 남는다.
특히 다음과 같은 부분에서 그러했고, 각 부분들에 대해 떠올린 해결방법은 다음과 같다.

- 논의 안건과 무관한 의견으로 회의가 산으로 가는 것을 통제(?) 하지 못했다.

=> 안건 시작과 동시에 안건에 대해서만 집중하자고 다시 한 번 환기시키는 것이 우선적으로 필요하다고 느꼈다.
=> 안건과 무관한 논의라고 생각될 경우, 팀원 상호가 가감없이 안건과 무관함을 서로 인지시켜주도록 하자고 제안한다.

- 팀원들이 각각이 제시한 의견이 어떤 의미인지 그때마다 명확하게 짚지 못해, 이후 논의 과정에서 다시 한번 각 의견이 어떤 의미였는지를 되짚는 시간이 추가로 할애되게 했다.

=> 스스로 서기 역할을 자처해서, 팀원들이 각각 제시한 의견을 텍스트로 작성해서, 의견의 의미를 재확인한다.

- 특정 안건의 합의 내용에 대한 팀원들의 이해도를 명확하게 체크하지 못해, 이 또한 위와 마찬가지로 다시 한번 짚고 넘어가는데 시간이 추가로 할애되게 하였다.

=> 안건의 결론을 반드시 문서로 명시화한다.

2. 역시나 어려운 타임라인 관리

개인적으로 나는 하루를 '오늘 완료한 일', '내일 해야할 일'을 중심으로 관리하는 편이다. 그리고 '내일 해야할 일'의 경우 우선순위에 따라 오름차순 형태로 작성해서 관리하는 편이다. 그리고 데드라인이 정해진 일의 경우에는 그러한 일상 관리 방법을 데드라인까지의 월 단위, 주 단위로 확장해서 관리하는 편이다.
예컨대, 3주 내에 책 100쪽을 읽어야한다면, 1주차 목표 = 50쪽 읽기, 2주차 목표 = 100쪽까지 다 읽기, 3주차 목표 = 책 내용 회고 및 정리하기와 같이 나누는 편이다. 일부러 주차 목표를 조금 더 챌린지하게 잡아서 주차별 수행률을 높이려고 의도한다.

이러한 나의 일정 관리 방식을 팀에 도입하기 위해 노력했다. 5월 14일(남은 기간: 3주) MVP 구현 및 서비스 배포라는 팀의 목적 아래, 나는 팀의 타임라인을 주 단위로 구분해서 주차별 목표를 각 파트별로 수립했다. 그리고 각 파트별로 담당 역할을 팀 노션에 텍스트로 명시화했다. 그리고 팀원별로 주차별 개발 목표에 맞춰 오늘 한일, 내일 할 일을 체계적으로 관리하기 위해서 추가적으로 세부 타임라인 페이지를 제작해서, 주차별 목표에 대응해서 팀이 하루를 어떻게 보내야하는지를 관리하고자 했다. 아래 그림들은 타임라인 관리를 위해 내가 제작한 툴들이다.
나름대로 팀의 속도를 텍스트로 명시화해서 좀 더 구체적으로 체크하기 위한 방안이었다.

이 문서들을 효과적으로 활용하기 위해서 중요한 건 '일일 회고'였다. 구체적으로, 팀원들이 매일 하루를 마무리하면서, 오늘 진행한 일 - 오늘 미처 다하지 못한 일 - 그래서 내일 할 일 - 오늘 겪은 trouble shooting을 공유하는 것이 매우 중요하다.

그렇다면, 이번주동안 그 '일일 회고'를 잘 진행했는가? 아니다. 사실 아래 문서도 이번주를 거쳐오는 과정에서 팀의 진행상황을 텍스트로 문서화해서 좀 더 명료하게 시각적으로 체크할 필요성을 느끼면서 도중에 제작하게 된 것이다. 그래서 '일일 회고' 자체는 매일 진행하고는 있었지만, 아래 툴을 활용한 일일회고는 아직까지 제대로 진행된 바가 없다.

그래서 다음 주에는 일일 회고에서 이 툴을 적극적으로 활용해보려고 한다. 활용 방안은 다음과 같다.

1) 회고 시간이 되면, 팀원들이 각자의 회고를 캘린더에 작성한다.
2) 캘린더에 작성된 내용을 바탕으로 팀원들이 자신들의 일일 회고를 공유한다.
3) 팀원들의 일일회고를 종합해서 팀의 일일회고를 기록한다.

진행 결과는 다음주 WIL을 통해 공유하겠다.

About tech

아직까지 해결하지 못한 로깅 - 도대체 어느 시점부터 어떤 로그를 저장해야하는거야?

로그를 기록하는 것은 서버의 유지보수 차원에서 매우 중요하다. 뿐만 아니라, 사용자 분석 차원에서도 로그를 기록하고 저장하는 것은 웹/앱 서비스에서 매우 필수적인 과업이라고 한다.
그래서 이번 프로젝트를 통해 나는 '로깅'을 담당하기로 하고, 이번 주 시간을 내어 로그를 카테고리화해서 기록하는 방법, 카테고리화한 로그를 각각 별도의 파일에 저장하는 방법에 대해 공부했다.
공부 방식은 구글링이었다. 구글링을 통해, node.js 환경에서 많이 쓰이는 로깅 npm은 winston과 morgan임을 알 수 있었다.

• morgan: http 접속 기록을 로그로 남길 수 있는 npm이다.
• winston: 남기고 싶은 로그의 카테고리를 error ~ info까지 7까지의 카테고리로 분류할 수 있으며, 각 카테고리에 해당하는 로그를 저장할 파일/DB을 지정할 수 있는 npm이다.

두 패키지를 공부하면서, 어떻게든 로그를 기록한다.와 로그를 저장한다. 까지는 구현할 수 있었다. 사실 구글링해서 나온 코드를 복사 붙여넣기한 수준에서였지만 말이다. 하지만 궁극적으로 의문이 든 것은 개발 시점에서는 어떤 로그를 '기록'하고 '저장'해야할까?, 배포시점은 또 어떨까? 였다.
관련해서 내가 약 2시간 정도 구글링을 하고, 주변 개발자 지인들에게 물어본 끝에 내린 답은 다음과 같았다.

- 개발 시점
	FE와 통신 중 디버깅할 것을 고려해서,
    1) 모든 http 접속 기록에 대한 로그,
    2) 에러를 발생시킨 http 접속 기록에 대한 로그를 각각 기록하고 저장할 필요가 있겠다.
    
 - 배포 시점
 사용자 분석까지 고려해서,
 개발 시점에서 기록하고 저장한 로그뿐만 아니라
 사용자의 사이트 사용 흐름(?)을 파악할 수 있는 로그를 기록하고 저장하면 좋겠다.

이것이 적절한 로깅에 대한 고민인지는 추후에 기술 멘토링에서 멘토님과의 대화를 통해 확인해볼 것이다.
한편, 사실 문제가 생긴 부분은 카테고리별 로그 기록 그리고 카테고리별 로그 저장에 실패한 것이었다.
구글링해서 코드를 A TO Z로 작성해보는 것이 아니라, 있는 코드를 그대로 복붙했기 떄문에, winston과 morgan 두 npm을 내가 의도한 대로 잘 다루지 못해서 발생한 문제였다.
프로젝트 비즈니스 로직과 관련한 api 구현이 개발 우선순위이기 때문에, 로깅에 대한 구현은 2주차 ~ 3주차 초반 목표로 미룰 수밖에 없었다. 이에, 돌아오는 주차에 로깅에 대해서 아마 다룰 듯 하다. 로깅에 대한 고민과 시행착오의 결과는 다음주 WIL에서 공유하겠다.

브랜치 룰을 설정하게 된 배경.. 내가 망친 CD

우리 팀이 정한 브랜치 전략은 다음과 같았다.

• master: 최종 배포 브랜치
• development: 최종 배포 전, fe와 통신 목적 테스트 브랜치
• feature: 기능별 구현 브랜치

feature에서 구현한 api를 development에 합치고, development에서 문제가 없는 api들을 master에 보내는 방식이다.
이 방식에 의거해서 무난하게 협업을 이어가던 도중, 내가 그만 문제를 터뜨리고 말았다.

A팀원이 빠르게 개발을 진행하면서 development 브랜치에 push한 변경사항들을 제때에 pull 하지 않았다. 그리고 그 상태에서 내가 담당한 api를 구현해서 development에 pull request를 진행했다.
결과는 A팀원이 구현한 CD(배포 자동화) 관련 코드들이 나의 pull request로 인해 다운그레이드였다.
우리 팀은 배포 자동화를 구현하는 것 조차 처음이었기 떄문에, 이를 다시 수습하는 데 오랜 시간을 쏟을 수밖에 없었다. 문제는 하루만에 수습되지 않았고, 내가 저지른 CD 코드의 다운그레이드는 다음 날 또 다른 문제들을 계속 발생시켰다.
다행스럽게도 오늘에 이르러서야 문제를 완전히 수습할 수는 있었다.
그리고 A 팀원으로부터, "현준님, pull을 자주 해주시면 좋을 것 같고, 현준님 코드를 remote branch에 푸시하실 때도 현준님 폴더에 있는 모든 파일들을 올리지 말고, 필요한 파일들만 스테이지에 올려서 push해주세요." 였다.
동의하는 바였고, 스스로 너무 부끄럽고 팀원들에게 죄송한 순간이었다. 그래서 이에 대해 꼭 유의할 것임을 팀원들에게 전달하고 스스로도 다짐을 하였다.

하지만 한편으로 의문이 드는 점이 있었는데, 내가 저지른 실수를 시스템적으로 방지할 수 있는 방법이 없을까?였다. 그렇게 찾아낸 것이 branch rule을 설정하는 것이었다. 위와 같은 상황에서 development에 내가 pull request를 실행하면, 곧바로 development에 적용되는 것이 아니라, 다른 팀원들이 이를 검토하고 승인해주어야만 적용될 수 있도록 branch에 보안장치를 걸어두는 것이다.

기술 멘토님께 이에 대한 정보를 들은 이후에 곧바로 적용했다. 덕분에 다음주부터는 내가 저지른 실수와 같은 사례가 좀 줄어들 것 같다.

한편, branch rule과 더불어 좀 더 효율적인 git 협업을 위해 사용되는 툴 중 하나로 jira가 있다고 한다. 개인적으로 이해한 바로는, 팀원이 커밋을 날리면, 이에 대해 다른 팀원들에게 메시지를 전송해주는 툴로 이해했다.

branch rule과 더불어 함께 이용한다면, 좀 더 단단하고 효율적인 협업이 가능할 것이란 생각이 든다. 다음주에 꼭 팀원들과 확인해보고 후기를 공유할 수 있으면 좋겠다.