데이터를 봐요💻
[데이터 분석] 데이터 분석가가 처음으로 github을 만났을 때 본문
오늘 글에서는 이직을 하고 나서 느꼈던 환경 중 그중에서 너무나도 생소했고(벌써 일 년 반이 넘음;ㅅ ;), 우리 팀이 업무 하는 방식인 ‘github으로 협업하기’에 대해서 이야기해보려고 한다.
내가 속해있는 팀은 직군과 상관없이, github을 사용해서 협업을 진행하고 있다. github을 이용한 협업 방식은 아마 개발 직군에서는 익숙한 업무 방식일 텐데, github은 코드를 좀 더 효율적으로 관리하기 위해 사용하는 프로그램으로, github의 주요 장점은 코드의 변경 기록을 확인할 수 있고, 소스 변경 등을 할 때 병렬적으로 진행할 수 있다는 장점이 있다.
지금은 github을 사용하여 헙업하는게 익숙하지만, 이직하고 처음 팀에 합류해서 github 사용에 대한 이야기를 들었을 때는 '멘붕 그 자체'였던 것 같다. 이 전 회사들에서는 데이터를 추출할 때나, 분석을 진행할 때는 그냥 개인적으로 jupter notebook 혹은 redash를 이용해서 혼자 업무를 했었다. 그래서 분석을 진행할 때 썼던 python 코드나 혹은 추출할 때 썼던 sql 코드를 다른 구성원들에게 보여주거나, 리뷰받는다는 걸 상상해보지도 못했다. 그래서 github 협업을 마주했을 때 누군가가 보고 있지 않기 때문에 코드의 최적화, 효율 등을 고려하지 않은 날 것의 내 코드를 구성원들에게 보여준다는 게 초반에는 너무 부끄럽기도 했지만, 점점 github을 통해 협업을 진행하면서 이제는 github 활용이 저에게 너무 당연한 업무의 한 부분이 되었던 것 같다.
물론, 처음으로 git을 사용해 보는 거 기 때문에 github과 친해지기 위해서 꽤나 많은 노력을 했었다. 처음에는 적응이 어려웠지만 github에 대한 장점을 빨리 누려보고 싶어서 'github으로 하는 협업’에 익숙해지기 위해 꽤나 많은 시간을 들였다. 처음 쓰는 github에 익숙해지기 위해서 인터넷에서 자료를 찾고 강의를 듣거나 주위에 있는 팀원들에게 모르는 부분에 대해서 물어보기도 하면서 점점 github과 친해져 갔다. 그래도 부딪혀가면서 배우는 게 가장 빠른 배움의 길이라고, 실제로 github에 PR open을 하고 리뷰도 받고, 리뷰를 직접 해보기도 하면서 코드를 이용한 협업 방법이 더 쉬워졌다.
github을 통한 협업을 겪어보면서 github으로 일했을 때와 github으로 일하지 않았을 때의 업무 방식이 꽤나 다르다는 생각을 했는데. 이 전과의 업무 방식을 비교해 본 표는 다음과 같다.
github으로 일했을 때와, github으로 일하지 않았을 때 데이터 분석가의 업무 일지
상황 가정 | github으로 일 할때의 분석가 | github으로 일하지 않을 때 분석가 |
A라는 지표가 갑자기 특정일 이후로 하락했어요. 왜 그런걸까요? | 1) 특정일에 로직 변화가 있었는지 코드를 통해 확인해본다. 2) 변화된 로직 확인 후 특정일을 기점으로 어떤 조건 때문에 하락했는지 답변을 해준다. |
1) 특정일에 로직 변화가 있었는지 해당 지표를 작업한 히스토리를 찾는다. 2) 히스토리를 통해서 어떤 날짜를 기준으로 해당 로직의 변화가 적용되었는지 찾아본다. 혹은 문서가 없다면 지표를 만든 구성원을 찾아 로직이 바뀐 특정 날에 대해 물어본다. 3) 이 전 로직과 어떤 부분이 바뀌었는지 히스토리 문서 혹은 구성원을 통해 파악하고 답변을 해준다. |
상황 가정 | github으로 일 할때의 분석가 | github으로 일하지 않을 때 분석가 |
이전에 A라는 분석이 프로덕트 개선에 큰 도움이 되었어요. 이 A분석을 B에도 적용하고 싶어요. | 1) A 분석을 진행할 때 사용했던 코드를 지난 pr을 통해서 확인한다 2) 이 전에 받았던 피드백을 반영해서, 해당 코드를 B관련 분석에 사용한다. 3) B 분석에 사용하면서 해당 코드를 좀 더 자동화시켜 다른 구성원들도 편하게 사용할 수 있는 방법을 고민해본다. |
1) A 분석을 진행할 때 어떤 코드를 활용해서 분석했는지 찾아본다. 2) A 분석때 사용했던 코드를 B 분석에도 적용시켜본다. 3) 이 후 동일 요청이 왔을 때 이 이터레이션을 다시 진행한다. |
github으로 하는 협업에 좀 더 익숙해지면서 지금은 오히려 github으로 협업하기에 큰 장점이 있음을 느끼고 있다.
- 한 번에 보는 히스토리
- 데이터 관련 업무를 하는 분들을 포함해서 업무를 진행할 때 업무의 효율성과 정확도를 위해 ‘히스토리 관리’를 중요하게 생각할거다. 특히나 데이터분석가는 그중에서도 '지표' 등의 히스토리 관리가 중요한 부분 중 한 부분인데, github을 통해 협업을 진행하게 된다면 이런 히스토리 관리 차원에서도 큰 장점이 있다는 걸 경험했다. 예를 들어 전사 혹은 팀에서 중요하게 생각하는 지표 A가 어떠한 이유로 지표 계산에 사용되는 데이터 소스가 바뀌는 경우가 있을 수 있다. 이런 경우에는 데이터의 소스가 변경되었기 때문에 아무리 데이터의 정합성 등을 확인했다고 해도 데이터가 이전 데이터 소스보다는 소폭 상승, 하락할 수 있다. 그렇기 때문에, 지표의 잘못된 해석을 방지하기 위해서 지표 변경이 특정 날부터 어떤 이유로, 그리고 어떤 소스에서 어떤 소스로 바뀌었는지에 대한 기록이 중요해진다. 만약 github을 통한 협업을 진행하게 된다면 누가, 언제 해당 지표의 로직을 바꿨는지 그리고 그 바꾼 이유는 무엇인지 한 곳에서 찾아볼 수 있다는 장점이 있다. 만약 github 업무를 하지 않았다면, 이 히스토리가 적혀있는 문서에 대해서 하나하나 찾아보거나 히스토리를 아는 사람에게 물어봐야 했을 가능성이 크고, 이렇게 된다면 해당 지표를 만든 구성원에게 항상 dependency가 걸리게 되고, 이 구성원이 없을 때는 지표의 변화에 대해서 파악하기가 어려워질 수 있다. 하지만 github으로 협업한다면 특정 날짜 이후로 로직, 또는 정의가 바뀌었을 때 언제부터 그리고 어떻게 바뀌었는지 코드를 통해서 질문 없이 파악할 수 있다는 장점이 있다.
- 내 코드는 내 것이 아닌 팀원들의 것
- 이 팀에와서 처음으로 코드 리뷰를 경험해 봤었다. 처음에는 구성원들이 제 코드를 보는 게 조금 부끄럽기도 했지만, 팀원들의 코드 리뷰를 통해서 제 코드 중 어떤 부분의 개선이 필요한지, 그리고 어떤 코드가 더 효율적인지 계속해서 피드백의 과정을 거치면서 내가 직접 코드를 칠 때 어떤 부분을 더 신경 써야 하는지 알아가는 과정을 겪으면서 점점 더 성장하는 게 느껴졌다. 그리고 나 또한 구성원들의 코드를 보고 리뷰를 해주는 시간을 가지면서 다른 구성원이 사용한 코드를 활용해서 제 코드에 사용해보기도 하면서 좀 더 활용할 수 있는 코드의 범위가 넓어졌던 것 같다. 그리고 처음에는 코드를 남에게 보여주는 게 부담감이 들었지만 다른 팀원들의 리뷰의 과정을 거친 후 제 코드를 적용했기 때문에 오히려 업무에 대한 부담감이 덜어졌다. 혼자 코드를 썼을 때는 '아 내 코드가 틀렸으면 어쩌지'라는 고민을 더 많이 했다면, 지금은 내 코드에 대한 확신보다는 '어떻게 하면 이 코드를 좀 더 사용성 있게 작성할 수 있을까?'라는 고민을 더 많이 진행하게 된다.
- 또한 다른 분석가분이 지표 개발을 할 때나, 데이터 분석에 사용했던 코드를 모든 구성원들이 볼 수 있기 때문에 만약 개발했던 지표에 대한 로직을 다른 지표에 동일하게 적용하고 싶을 때나, 진행했던 분석을 다른 도메인에 적용해보고 싶을 때 github 내에 기록되어 있는 코드를 통해서 쉽게 적용할 수 있다는 장점이 있다.
github을 통한 협업에는 단점도 물론 있을 수 있다. 리뷰 과정을 거치기 때문에 업무를 완료하기 위한 속도가 늦어지는 경우도 있다. 만약 지표에 대한 수정을 빨리 진행해야 하는 경우, 해당 지표에 대한 쿼리 리뷰를 받아야 하기 때문에 생각했던 것보다는 업무의 속도가 지체될 수 있는 가능성이 있다. 이 부분을 이미 팀에서도 인지하고 있기 때문에 어느 정도 해소하기 위해서 온콜 제도를 도입했다. 팀 내에서 지정된 팀원이 일주일 동안 돌아가면서 온콜을 담당하게 되고, 온콜 담당자는 github 레포에 쌓여있는 PR의 리뷰를 빠르게 해주는 업무도 담당하면서 팀의 구성원들의 github을 통한 협업의 병목이 최대한 없도록 노력하는 방법을 택하고 있다.
지금까지 내가 회사를 다니면서 처음 마주한 github을 통한 협업 방식에 대해서 느꼈던 점을 소소하게 적어보았다. 정리해보자면 github을 통한 협업은 히스토리를 한 곳에서 한 번에 확인할 수 있고, 코드 리뷰를 통한 피드백을 통해 좀 더 효율적이고 사용성이 좋은 코드를 작성할 수 있도록 도와주는 협업 방식이라고 설명할 수 있다. 처음 배울 때는 조금 어려울 수 있지만, 그래도 익숙해지면 데이터 분석가에게는 정말 좋은 툴이라고 생각한다.
'글또' 카테고리의 다른 글
[데이터 분석] 빅쿼리(Bigquery)의 쿼리를 최적화 해보자! (1) | 2024.03.30 |
---|---|
가볍게, 그래도 조금 무겁게 3개월 돌아보기 (0) | 2024.03.16 |
[데이터분석] 실험은 못하지만 실험이 하고싶어 (0) | 2024.02.03 |
[데이터분석] 그렇다면 다른 지표는요? 한 가설 내 다른 검증을 최대한 줄여보자. (1) | 2024.01.21 |
2024년 다짐글 (1) | 2024.01.21 |