공부 과정을 기록하는 페이지입니다. 아래 중 한 가지 이상을 확인합니다.
1. 레퍼런스에서 어떤 부분을 더 발전시켰는지 확인합니다.
2. DA에서 사용하는 언어와 개념을 나의 언어로 설명합니다.
3. 나에게 부족한 부분은 무엇인지 점검합니다.
나에게 부족한 부분 점검하기
이번 프로젝트에서 처음으로 협업을 했다. 협업을 하면서 좋았던 점과 더 발전시켜야할 부분을 정리하려 한다.
좋았던 부분
시야가 넓어졌다. 서로 분석에 중점을 두는 부분이 달랐다. 나는 상품 자체를 분석했고, 동료는 유저를 분석했다. 혼자 진행했다면 단편적인 분석이 되었겠지만, 협업을 하니 입체적인 분석이 되었다. 무엇보다 좋은 점은 서로 레퍼런스를 어디서 구했는지 풀(pool)이 공유된다는 점이었다. 정보를 검색하거나 학습을 하다보면 항상 하던 곳에서 하게 되는데, 동료와 함께 하니 몰랐던 레퍼런스 자료나 플랫폼을 알게 됐다.
정해진 일정에 맞춰 결과물을 내는 경험도 생각 이상으로 소중했다. 분석을 하다보면 계속 욕심이 생긴다. 그러다보면 EDA와 전처리만 삼일밤낮을 하는 경우가 있다. 혼자한다면 일정을 조정하면서 다른 부분의 분량을 줄이면 되지만, 협업을 할 때는 그렇게 일할 수 없다. 각자 정해놓은 시간까지 정해진 결과물을 가져가야 하기 때문에 (억지로라도) 적정한 타이밍에 분석을 끊어야만 했다. 정해진 리소스 안에서 결과물을 내는 경험이 생각 이상으로 소중했다.
내가 지금 제대로 가고 있는지 물어볼 사람이 있다는 점도 기대 이상으로 좋았다. 분석을 하다보면 확증편향에 빠지기 쉽다. 내가 결론을 정해놓고 분석을 하고 있는건 아닌지 스스로 의심할 때도 많았는데, 협업할 때는 이런 부분을 함께 점검할 수 있어서 좋았다. 분석 결과를 설명할 때, 상대방의 표정이 변하는 부분이 반드시 있다. 이런 부분을 놓치지 않고 상대방에게 납득되지 않는 점이 있는지 꼭 물어보자.
아쉬웠던 부분
프로젝트의 목적부터 차근차근 논의해나가지 못했다. 각자 EDA를 한 결과를 보고 문제를 도출하고 역할을 나눴다. 운 좋게도 EDA의 결과에 서로 겹치는 부분이 없었고, 비슷한 문제를 발견해서 그대로 다음 분석 단계로 나아갈 수 있었다. 하지만, 언제까지 이렇게 운이 좋을 수는 없을 것이다. EDA 결과가 겹치거나 서로 양립할 수 없는 문제 정의를 한다면 처음부터 EDA를 다시 진행하거나 한 사람의 분석을 폐기해야할 수도 있다. 아무것도 없는 상태에서 논의를 시작할 수 없다고 생각해서 각자 분석을 시작한 것인데, 백지에서 서로 논의를 어떻게 시작할 수 있을지 고민해봐야겠다.
Github를 충분히 이용하지 못한 점도 아쉬웠다. 깃헙의 버전 관리 기능이나 협업 기능을 사용하지 않고 서로 코드를 각자 작성했다. 협업에서 꼭 경험해야하는 핵심적인 툴이라고 생각했지만, Github을 따로 익힐 시간이 부족했다. 코드를 리펙토링하면서 Github로 branch 관리나 버전 관리를 경험해봐야겠다.
서로가 사용한 기술을 설명할 시간이 많았다면 더 좋았겠다는 생각도 들었다. 결과를 도출하는데 급급해서 서로가 사용한 기술에 대해 충분히 설명할 시간이 부족했다. 그러다보니 상대의 분석 결과나, 기술에 대해 추가로 다시 공부해야 하는 번거로움이 있었다. 회의를 짧게 진행하기 위해 해오기로 한 과제를 확인하고, 다음 과제를 정하는 시간으로만 활용했기 때문인 것 같다. 조금 시간이 들더라도 서로가 사용한 기술에 대해 충분히 질문하고 고민할 시간을 가져야 겠다.
