글을 쓰게 된 배경
데이터 분석가라는 직무는 회사의 규모, 도메인, 업무 방식에 따라서 성격이 많이 다릅니다. 때문에 "본인이 상상했던 일과는 다르다"는 이야기를 어렵지 않게 들을 수 있는데요. 속칭 데이터 추출만 하는 '쿼리머신'이 된 것 같아 커리어가 걱정된다고 이야기하시는 분들을 위해서 조직의 전략가로 포지셔닝하기 위해서 제가 시도했던 방법을 적어보았습니다.
예상독자
- 데이터 문화가 자리잡지 않은 스타트업의 데이터 분석가, PM
- 데이터 분석가 직무이지만, 실제 하는일은 단순 데이터 추출의 비중이 높으신 분
- 데이터 분석가 채용을 했는데, 어떤 역할을 부여하면 좋을지 고민이 많은 조직장
저는 스타트업의 1인 데이터 분석가입니다. 입사 초반에는 여러 개발자 분들이 나누어 담당하시던 데이터 추출 업무를 도맡아 조직의 데이터 구조에 대한 이해를 높였는데요. 데이터 구조에 익숙해질 무렵 점점 추출 요청이 많아졌습니다. 문제는 요청사항이 전부 다르기 때문에 비즈니스와 DB의 히스토리를 파악하는 과정에서 꽤나 시간이 필요하다는 점이었습니다.(이미 짰던 쿼리를 보는 것 포함) 그리고 데이터 분석가와 일하는 게 낯선 조직원도 '데이터 분석가 = 데이터 주는 사람'의 인식을 가지고 있어서 데이터 추출 요청을 하는 경우가 대다수였습니다.
저는 데이터 추출을 포함하여 업무에 사용되는 리소스를 줄이고, 데이터 분석가에 대한 인식을 바꾸기 위해서
리소스 최적화 - 측정 - 인식변화의 과정을 적용했습니다.
리소스 최적화
Redash 활용

redash란?
협업 데이터 쿼리 및 시각화를 위한 오픈 소스 자체 호스팅 플랫폼. 여러 데이터 소스들을 손쉽게 연결할 수 있고, 쿼리 편집과 대시보드를 활용하여 원활한 공유가 가능합니다.
저는 데이터 추출에 소모되는 리소스를 줄이기 위하여 redash를 적극적으로 활용하였는데요. 데이터 추출 요청이 오면 정기적인 사용여부를 확인하고, 자주 필요한 데이터의 경우 redash의 파라미터를 활용해서 구축해놓고 쿼리를 모르시는 분도 쓸 수 있도록 해두었습니다. 제목과 description을 활용해서 처음 보시는 분들도 어떻게 사용해야 하는지, 어떤 조건이 걸려있는지에 대한 내용을 알 수 있도록 했습니다. 태그를 활용해서 요청 부서별, 서비스별로 구분이 되도록 관리하고 있습니다. 사용이 매우 편리하고 접근성이 높습니다.
그리고 redash 사용현황을 주기적으로 모니터링하며, 잘 사용하시는지? 새로운 요청을 하실 때 기존에 구축되어 있는 항목은 아닌지?를 확인했습니다. 또한 잘 활용하시지 않는 경우, 이유를 물어봐서 불필요한 항목을 제거하고 개선하여 지속적으로 사용가능하도록 만들기 위해 노력하고 있습니다. 그 결과 추출 요청이 많이 줄었습니다.
커뮤니케이션 코스트 줄이기
다른 직무도 마찬가지겠지만, 데이터 분석가는 커뮤니케이션이 정말 중요한 요소 중 하나라고 생각하는데요. 요청하시는 분과 서로 이해하는 바가 달라 본래 처리에 필요했던 리소스보다 몇 배는 더 많이 사용하는 경우가 비일비재 합니다.
저는 이런 경우를 최소화하고자 두 가지 질문을 자주 사용합니다.
- 왜 필요하신가요?
요청하시는 분이 의도하신 것은 아니겠지만, 목적자체가 아직 확실하게 정의되지 않은 경우가 있습니다. 이럴 경우 분석가의 입장에서도 어떤 것을 원하는 것인지에 대해 생각해야 해서 많은 시간이 소요되는데요. 왜?라는 질문을 함으로써 해야 하는 일을 명확하게 정의할 수 있고, 요청자가 원하는 것보다 더 좋은 방법을 떠올리기도 합니다. 이것은 추출요청뿐만 아니라 데이터 분석이 필요한 경우에 더 많은 리소스를 줄일 수 있습니다. - ~의 정의가 어떻게 되나요?
다양한 팀과 소통하는 데이터 분석가의 특성상, 생소한 용어들을 많이 접하게 되는데요. 같은 용어여도 사용하는 팀마다, 사람마다 의미하는 바가 다르기 때문에 정의가 어떤 것인지 꼼꼼하게 파악하는 것이 중요합니다. 컨텍스트를 알아야 되는 용어가 있다면 요청을 받을 때 미리 알아 놓아야 추후에 핑퐁을 효과적으로 줄일 수 있습니다. (이렇게 해도 핑퐁을 완전히 없앨 수는 없는 것 같지만요...)
위와 같이 리소스를 최적화했다면, 실제로 얼마나 효과가 있었는지 측정을 해야겠죠? 저는 이것들을 효율적으로 측정하기 위해서 다음과 같은 방법을 사용합니다.
측정
회사 자체의 협업툴이 따로 존재하지만 개인적으로 해당 업무에 얼마 정도의 시간을 투자하고, 느낀 점들을 기록하기 위해서 어떤 방식이 가장 좋을지를 고민했는데요. 아무래도 가장 허들이 낮고 편리한 구글 스프레드시트를 활용했습니다.

저는 이 시트를 아래와 같은 항목으로 구성했습니다.
- 요청일: 요청을 받은 일자
- 완료일: 요청을 완료한 일자
- 실소요 시간: 업무에 소요된 시간(분)
- 진행상황: 진행 중, 완료, 보류, 추가작업 등 상태에 맞게 카테고리화
- 요청부서: 요청을 한 부서 (스스로 하는 경우 데이터팀 기재)
- 요청인: 요청을 한 당사자
- 분류: 데이터 추출, 대시보드, 데이터 분석 등등 업무내용별 카테고리화
- 내용: 요청 및 작업 내용
- 작업툴: 작업에 사용되는 툴
- 링크: 요청 혹은 관련 스레드, 컨플루언스 링크
- 비고: 기타 작업에 참고해야 할 내용
- 회고: 업무가 끝나고 어떤 점이 어려웠는지? 어떤 부분을 잘했는지? 어떻게 하면 더 잘할 수 있는지? 등에 대해서 기재
위와 같은 형태로 업무를 관리하며 제가 느낀 장단점은 다음과 같습니다.
장점
- 어떤 업무에 어느 정도의 리소스를 사용했는지 정량적으로 관리
- 부서별 분석가 리소스 사용 현황 확인 가능
- 업무별 회고를 통해 셀프 피드백 가능
- 추후 비슷한 업무 진행 시, 히스토리를 찾아보는데 용이
단점
- 협업툴 외에 추가적으로 기재해야 하기 때문에 시간이 중복으로 소요될 수 있음
- 수동으로 기재하기 때문에 누락의 가능성 존재
- 다른 사람들과 공유가 불가능함 (= 다른 사람들이 내가 어떤 일을 하는지 상세히 파악하기 어려움)
위와 같은 단점이 존재하지만, 장점이 단점을 크게 압도하기 때문에 이런 방식을 도입이 도움이 되는 것 같습니다. 저는 이와 같은 방법을 통해 다음과 같은 측정을 했는데요.



데이터 요청 관리시트를 통해서 파악한 입사 초 3개월의 업무 비중 모습입니다. 데이터 추출이 차지하는 비율이 점점 줄어듦을 확인할 수 있습니다. 요청 자체가 줄어들었을 수도 있기 때문에, 팀별 redash 사용률을 함께 확인하면 좋습니다.

이것은 양 Y축의 단위가 다른 그래프의 모습인데요. 데이터 추출 요청에 실제로 소요된 총 시간과 요청별 평균 처리 소요시간을 알 수 있습니다. 그래프를 보면 추출에 사용한 절대적인 시간도 줄었고, 추출 요청에 대한 처리 속도도 상승한 걸 알 수 있습니다. 결과적으로 추출 리소스를 많이 줄일 수 있었고, 더 가치 있는 업무에 리소스를 많이 투여할 수 있었습니다.
앞서 확보한 리소스를 어떻게 더 가치있는 일에 사용할 수 있었을까요? 이것은 조직의 데이터 리터러시와 직결되는 문제라고 생각하는데요. 이 부분에서는 정성적인 노력이 많이 필요한 것 같습니다.
인식변화
문제해결(체험판) 제공
기업이 고객에게 상품을 팔거나 서비스 구독을 유도할 때, 샘플이나 무료 체험을 제공하는데요. 기업 = 나, 고객 = 사내 구성원으로 적용하여 데이터 분석가와 함께 일하는 방법을 경험하게 했습니다. 앞에서 왜?라는 질문으로 커뮤니케이션 코스트를 줄였다면, 그 질문을 통해 단순히 추출, 분석결과만 전달하기보다 어떤 액션을 할 수 있을지를 함께 고민하는 시간을 가지려고 했습니다. 엉덩이를 가볍게 하여 자리로 찾아가 요청자가 어떤 상황인지 더 이해하고 데이터를 통해 할 수 있는 액션을 함께 논의했습니다. 이렇게 조금씩 합을 맞춰가며 '저와 함께 일하면 이런 것들이 가능해요'라는 것을 조금씩 알린 결과, 점점 많은 분들이 문제 해결을 위한 고민을 저에게 나눠주시고 계십니다. (영업성공)
상부의 조력 얻기(상급자와 싱크 맞추기)
인프라가 아직 완전히 구축되지 않은 경우면 더더욱 조직장, 리드와의 커뮤니케이션이 중요합니다. 저는 혼자서 고민하는 시간 때문에 많은 일의 진행이 늦어졌는데요. 이를 위해서 CTO님과 1 on 1 시간을 최대한 활용했습니다. 한~두 달에 한번 있는 시간을 최대한 활용해서 많은 피드백을 받아야 성장할 수 있고, 환경이 바뀔 수 있다고 생각했습니다. 그래서 제 업무관리 시트를 활용해 시각화하고 업무 현황과 제가 느끼는 어려움 등을 공유했습니다. 충분히 개선의 여지가 있음에도 제가 말하지 않았던 영역이 많이 존재한다는 것을 깨달았습니다. 이후에도 CTO님의 조력으로 기본적인 업무처리에 소모되는 코스트를 많이 줄이고 있고, 저의 역할을 전략가에 가깝게 포지셔닝하는데 많은 도움을 받고 있습니다. 조력이 있는 것과 없는 것에는 정말 차이가 크기 때문에 상급자에게 지속적인 공유를 통해 싱크를 맞추는 자세가 필요한 것 같습니다. (특히나 혼자 있는 분들이라면 필수적인 요소입니다.)
위와 같은 과정을 겪으며 깨달은 점을 크게 3가지 정도로 나누어 공유해 볼까 합니다.
팁 3가지
- 친절한 것과 업무를 잘하는 것은 다릅니다.
친절함에 매몰되어 과한 인풋을 투입하거나, 우선순위를 변경하면 더 많은 리소스를 소요할 가능성이 있습니다. 이는 분석가의 리소스를 필요로 하는 다른 분들에게는 불친절한 일이 될 수 있습니다. - 너무 빠른 아웃풋은 오히려 독이 될 수 있습니다.
급한 요청의 경우 바로 해주는 것이 맞지만, 우선순위는 높지 않지만 금방 끝나는 일이라 바로 처리하는 경우 상대방은 '이 정도면 이렇게 빨리 해줄 수 있구나'라는 인식을 심어줄 수 있습니다. 저는 다음과 같은 상황을 겪었습니다.
A 요청 ► 금방 하는 거네? 빠른 아웃풋 ► B도 안될까요? ► 해줌 ► 죄송한데 C도요 ㅜㅜ ► 본래 하던 일의 업무 흐름이 계속 끊김
이런 경험들이 쌓이다 보니, 빠른 아웃풋보다 업무를 처리하는 명확한 기준 필요하다고 느꼈습니다. - 함께 일하는 가상의 coworker를 만듭니다.
혼자 일하다 보면 코드를 치는 것도, 업무를 관리하는 것도 내 머릿속에 늘어놓게 되는 경우가 늘어나는 것 같습니다. 그것이 빠르고 효율적인 방법이긴 합니다만, 우리는 언제까지고 혼자 일하지 않을 것이기 때문에 이러한 습관은 우리를 함께 일하기 어려운 사람으로 만들뿐더러, 현재 조직에서도 우리가 어떤 일을 하고 있는지 정확한 파악이 어렵게 만듭니다. 때문에 가상의 '데이터분석가2'를 만들고, 이 사람에게 계속 공유하며 일을 한다고 생각하면 이런 부분을 어느 정도 해소할 수 있는 것 같습니다.
앞으로 할 예정인 것들
- 정기 데이터 리포트 발행
결과물을 어느정도 범위로 해야 할지, 어떤 방식으로 해야할지 고민이 많은데요. 조직 구성원에게 액셔너블한 인사이트가 담긴 요소를 제공하면서 데이터 분석가 활용법을 전파하는 것이 목표입니다. (어떤 방법이 좋더라~ 하는 의견을 주실 분 언제나 환영합니다.) - 데이터 교육
현재 정식적으로 데이터 교육을 시행하기보다 데이터 요청을 자주 하시는 분들을 위주로 의사소통을 할 때마다 조금씩 지도를 하며 양육(?)을 하고 있습니다. 지금 하고 있는 것들이 많아서 아직 정식적인 세션을 운영하진 않았는데요. 장기적으로 필요한 일이라서 어떤 방식이 우리 조직에 최적일까?를 고민하고 있습니다. (이 부분도 다른 분들의 사례를 수집하고 있습니다.) - 검색이 가능한 데이터 카탈로그 도입
앞서 게시했던 데이터 거버넌스 관련 글에서 데이터 카탈로그에 대한 이야기를 언급했었는데요. 조직원이 SQL을 활용할 줄 알아도 데이터 구조를 모르면 아무런 효용이 없습니다. 이것을 해결하기 위해서 데이터 구조와 스키마를 확인할 수 있는 데이터 카탈로그를 도입하려고 계획 중입니다. 다른 업무와의 우선순위에서 밀리는 것 같지만 최대 3Q 내에 도입하는 것이 목표입니다.
마무리
글의 초입에 썼던 것처럼 회사마다 상황이 다르기 때문에 어떤 방법이 우리 조직에 적합한지에 대해서는 정답이 없습니다. 데이터 분석가 직무 역할에 대한 고민이 있으시거나 조직의 데이터 문화를 디벨롭하기 위한 고민을 하시는 당사자분들이 이 글을 보고 조금이나마 도움이 되셨으면 하는 마음으로 글을 적어보았습니다.
거창하게 썼지만 전략가로 거듭나기 위한 방법은 결국, 조직원들의 마음을 얻고 그들이 더 좋은 가치를 만들 수 있도록 도와주는 것이라고 생각합니다. 저도 아직 제갈공명의 수준이 되려면 갈 길이 멀었지만, 자고로 헤드라인은 최대한 자극적으로 써야한다고 배웠습니다.

제가 많은 분들과 이야기해 본 결과, 조직에서 데이터 분석가에게 뭔가를 원하는 때는 "그들의 주장에 근거를 찾고 확신을 얻고 싶을 때"입니다. 구성원들에게 힘을 실어주고 신뢰받는 데이터 분석가이자, 조직의 제갈공명이 되기 위해서 앞으로도 많은 시도와 실패를 반복할 예정입니다. 위에도 언급했지만, 이와 관련된 이야기 혹은 다른 어떤 주제라도 함께 나누고자 하는 분들을 언제나 기다리고 있습니다.
'데이터 > 데이터 거버넌스' 카테고리의 다른 글
| 데이터 분석가는 어떻게 조직이 '행동'하게 할 수 있을까? (1) | 2023.06.18 |
|---|---|
| 초보자도 할 수 있어, 데이터 거버넌스 (0) | 2023.02.26 |