저번주 질문 회의 + 미니 데모데이 때 받은 피드백을 바탕으로 우리만의 리뷰폼 ver2를 완성해보았다. 이주동안 매일 아침 30분-1시간씩 회의를 하며 질문과 폼 형태를 조금씩 발전시켰다. 이 과정에서 서술형이 리뷰에 대한 부담감을 높이고 막연하게 만든다는 문제점을 공통적으로 느꼈다. 강점 카테고리(커뮤니케이션 능력, 기술 역량 등)를 선택하고 해당 카테고리에 대해 객관식+서술형으로 응답하는 형태로 변경하게 되었다. 또한 ‘긍정적인 측면을 강화할 수 있는 리뷰’를 우리의 방향성으로 잡는 것으로 비로소 모두가 의견을 모았다!
지난 데모데이들을 통해 우리는 도그 푸딩이 얼마나 중요한지 깨달았기때문에 확정된 폼으로 바로 우리 팀원들과 몇몇 주위 크루에게 그 사람에 대한 리뷰를 남겨달라고 부탁했다. 피드백을 받고나니 우리의 예상과 비슷하게 받아들여지는 것도 있었고, 예상 외로 불편함을 느낀 점도 있었었다.
역시 우리끼리 이런 질문은 이렇게 받아들여지지 않을까? 이런 논의를 길게하는 것보다 만들어서 써보게 하는 것이 더 효과적이다. 우리가 ‘이럴것이다’하고 예상한 것이 빗나갈 때가 많았기 때문이다. 만약 그걸로 논의를 길게했다면 필요없는 논의를 길게한 것이 되었을테니까!
이렇게 매일매일 질문회의를 조금씩 하면서 우리의 질문폼이 점점 나아지고 있다고 생각한다. 아니 나아지고 있다!
ps. 점점 회의가 짧아지고 있다는 것도 최근 발견한 특이점이다. 아침에 30분 내외로 짧게 매일 질문 회의를 했는데 어느정도 논의에서 넘겨야하고, 어떤 것들은 지금 시간을 내서라도 결정을 내려야하고, 어떤 것들은 대충만 정해놓고 결정을 미루는 것이 나은지 등의 기준들이 생기고 있다. 이것 역시 하루 종일 기획회의를 3~4시간씩 해보기도 하면서 ‘아 이렇게하면 저번처럼 오래 걸리고 결론이 안날거야’라는 경험에서 얻게된 기준들인 것 같다😂
이번주 백엔드 요구사항은 로깅, 모니터링이었다. 두가지 모두 처음 접해보는 개념이라 다른 팀원들이 설명해주는 것을 바탕으로 열심히 받아적고 이해하려고 했다. 그런데 이게 로깅, 모니터링이라는 개념만 알면 되는 게 아니라, 이를 위해 인프라를 구성해야했고, 이를 위한 서버를 띄우면서 도커가 필요하면 또 도커, 가상화의 개념을 알아야했다.
화, 수요일 동안 로깅, 모니터링을 적용했는데 이 이틀동안 정말 지식의 홍수가 쏟아지는 기분이었다. 기본 리눅스 명령어부터, ip, 포트, 서브넷, 도커와 가상화, 최종적으로 이 개념들을 기반으로 로깅, 모니터링을 적용하는 것까지. 낮 동안은 최대한 따라 적고, 이해해서 따라가려고 하다가 바로 바로 이해가 안되니까, 물어보고, 물어봤던 거 미안하지만 또 물어보고, 그러다보니 ‘왜 난 CS 공부를 하지 않았지?’라는 자책감도 자꾸 들었다.
그래도 학습이 싫지는 않았다. 버거웠지만 재밌었다. 이전에 억지로 외우려고 했던 CS 지식이, 직접 써야할 때가 되어서 공부하게 되니 왜 써야하는지, 우리 프로젝트에 어떻게 적용되는지가 보여서 재밌었다.
(CS 초보자인 나에게 재밌게 설명해준 팀원들 덕이 크다👍)
이전 데모데이에서 하나의 유저 플로우를 제대로 보여주지 못한 게 아쉬웠기에 이번에는 피드백 받을 수 있는 유저 플로우를 보여드리는 것을 목표로 했다.
버전 1과 버전 2를 모두 보여드렸고, 코치들은 어떻게 이런 변화가 생기게 된 것인지 궁금해했다. 우리의 조금씩 매일 진행했던 질문, 폼 회의와 수많은 도그 푸딩, UT를 통한 변화였다는 걸 말씀드렸고, 처음으로 칭찬을 받았다.
사실 칭찬이 중요한 건 아니지만, 우리가 비로소 방향을 잡은 것 같다는 생각이 들어서 뿌듯했다.
하나 아쉬웠던 점은 이번 스프린트에서 모니터링을 열심히 적용했고 시간을 많이 투자했는데, 정작 기능 구현이 아니라 왜 현재 필요하지 않은 오버 엔지니어링 성격의 모니터링을 했는가에 대한 질문에 대해 명확하게 대답하기 어려웠던 것이었다. 나도 필요성이 아직 느껴지지 않는데 왜 적용해야하나 라는 의문을 한 편으로 가졌었기에 더욱 아쉬웠다. 코치에게 해당 요구사항을 조정 가능한지 물어봤어도 좋았겠다는 생각이 든다!