내가 무엇을, 왜 하고 있는지 인지하기 [수습기간 회고]
들어가며
2024년 9월 지금의 조직으로 이동하여 3개월의 수습 기간 종료를 앞두고 있다. 합류와 동시에 바로 현업에 투입되었기 때문에 what/why/how를 정리하지 못한 채 정신없이 시간을 보냈다. 이번 수습 회고에서는 지금까지 해온 구체적인 ACTION을 직무 관점에서 ‘무엇을 했는지’로 추상화하고, ‘왜 그렇게 했는지’ 의도를 부여하려 한다. 그리고 과정 중에서 어려움을 느꼈거나 개선의 여지가 있는 지점을 파악할 것이다.
물론 프로젝트의 내용은 밝히기 어려우니 기술 스택을 중점으로 다룰 예정이다. 일부 구체적인 사례가 필요한 경우에는 간단한 예시로 대체하겠다.
직무에 대해서
지금 회사에서 나의 직무는 분석가다. 여기서 분석가는 UX분석가, 데이터분석가, AI엔지니어 등을 포괄적으로 지칭하는 말이다. 그 중에서 나는 AI엔지니어라는 포지션로 입사했지만 대체로 데이터 과학자, 데이터 분석가, ML엔지니어를 오가는 다양한 업무를 접했다.
이전 회사에서는 하나의 프로젝트에 소속된 상태였다. 따라서 해당 서비스의 데이터 안에서 여러 방면으로 경험할 수 있었다. 당연하게도 모든 일의 목적은 근본적으로 ‘서비스를 성공시키는 것’이기 때문에 업무마다 문제와 목표가 달라지곤 했다. 간단하게는 지표의 현황을 파악하는 것, 위험을 최소화하기 위해 pain point를 탐색하는 것, 서비스의 피처가 의도대로 작동하는지 확인하는 것, ML 기반의 새로운 컨텐츠를 리서치하는 것, 내부 개발진을 대상으로 데이터 기반의 의사결정을 도모하는 것 등등.
이렇게 분석가로서 다양한 영역의 작업을 경험한다는 것은 뚜렷한 장단점을 지닌다.
- 장점
- 다양한 스킬셋을 확보할 수 있었다
- 비즈니스와 기술적 액션의 연결고리를 이해하게 되었다
- 협업과 커뮤니케이션 역량을 강화했다
- 단점
- 나의 역할과 커리어의 방향성 불분명했다
- 특정 영역의 전문성을 쌓기 어려웠다
특히 비즈니스와 기술적 액션을 연결 짓는 역량은 나에게 대단한 발전이었다. 어쨌든 회사는 돈을 벌어야 한다. 기술적으로 깊이를 더하거나 새로운 기술을 도입, 고도화하더라도 그것이 비즈니스 임팩트를 창출하거나 의사결정에 실질적으로 기여하지 못한다면 “그래서 이걸 해서 뭐?” 라는 허무한 질문으로 끝나버릴 수 있는 것이다. 조직과 나의 성과로 연결되는 일을 해야 한다는 중요한 깨달음을 얻었다. (물론 리서치 중심의 조직이거나 학술적 목적이 주가 되는 곳이라면 상황이 다를 수 있다)
한편 커리어의 방향성이 불분명하다는 것은 여전히 고민 지점이다. 예를 들어 데이터 직군의 채용 공고를 아무거나 눌러 읽어본다. JD에 나열된 기술 역량을 살펴보면 애매하다. 채용공고만 봐도 나의 경험과 역량이 여러 포지션에 걸쳐져 있다는 것을 알 수 있다. 심지어는 특정 자격 요건에 해당 되더라도 “내가 이걸 해봤다고 말할 수 있나?” 라고 자문하게 된다. 해본 건 맞다. 그런데 그것을 전문적으로, 깊이 있게, 비즈니스 성과로 이어지도록 해냈는지는 확신을 갖기 어려운 것이다.
실제로 지난 면접에서 오간 대화를 통해 나의 전문성이 부족하다는 것을 깨달을 수 있었다. 최종적으로는 불합격한 포지션이었다.
- 면접관
- A 모델의 학습 과정에 B 모델을 접목 시킨 이유가 무엇이었나요?
- 나
- B 모델의 XX적 특성이 문제와 연결된다고 생각해서 적용했습니다.
- 면접관
- 실제로 그 접근 방식이 잘 워킹하는지 어떻게 검증하셨나요?
- 나
- OOO 지표가 기존보다 빠르게 수렴하는 것을 확인할 수 있었습니다.
- 면접관
- B 모델의 내부 요소가 A 모델에 어떤 영향을 미쳐서 성능이 향상되는지 검증해본 적 있나요?
- 나
- (일단 적용하는 데만 공수를 겁나 들였고 전반적인 성능만 확인해서 할 말이 없음)
- 면접관
- B 모델의 +++ 를 추출해서 시각화하는 방식은 생각해보셨나요?
- 나
- 그런 검증 방식은 떠올리지 못했습니다.
창피하다…
그렇다. 나는 ‘일단 해본다’에서 그쳐온 것이다. 아니, 사실은 내가 정확히 무엇을, 어떻게, 왜 했는지조차 설명할 수준이 안 되었던 것이다. 일련의 깨달음을 끝으로 나는 기본기와 전문성을 갖추는 것 그리고 내가 무슨 일을 하는지 명확하게 정리하고 인지하는 것에 집중하기로 결심한다.
작업 정리
정리한 방식은 이렇다.
- 업무 일지를 기반으로 구체적인 작업을 리스트로 나열한다
- 각 항목을 추상적인 표현으로 바꾸고 큼직한 키워드로 분류한다
- 각 항목의 의도를 설명한다
- 어려웠거나 개선의 여지가 있는 지점을 짚는다
예를 들어,
- ACTION
- Snowflake 에서 AAA 라는 스키마 아래에 있는 TABLE0, TABLE1, TABLE2를 참조하는 SQL 문을 작성했다
- WHAT
- 클라우드 기반의 데이터 웨어하우스의 구조를 이해하고 여러 소스로부터 데이터를 통합하는 SQL 쿼리를 작성했다 => Data Engineering
- WHY
- 최신 데이터를 정확하고 효율적으로 통합함으로써 데이터 분석과 시각화의 기반을 마련하고자 했다
- HOW
- 복잡한 SQL 쿼리 : API로 fetch 한 JSON 배치가 통째로 한 셀에 들어가 매우 nested된 형식이었다. 더 효율적인 데이터 추출을 위해 최적화할 필요가 있다.
- 낯선 데이터베이스의 구조 파악 : 구조화된 문서로 세부 사항을 기록하고, 필요한 경우 자체 데이터 사전(Data Dictionary)을 구축할 수 있다
실제로 수행한 업무는 Snowflake 에서 AAA 라는 스키마 아래에 있는 TABLE0, TABLE1, TABLE2를 참조하는 SQL 문을 작성했다
이지만, 데이터 직무의 관점에서 무슨 일을 한 건지 객관화, 추상화할 수 있게 된다.
정리 결과, 키워드는 크게 네 가지로 나눌 수 있었다. 각 키워드에 해당하는 WHAT 들을 아래 나열해본다.
협업 및 운영 | 데이터 분석 |
---|---|
- 데이터 분석을 위한 Ubuntu 개발 환경 구축 - CI/CD 도구와 협업 도구 통합 설정 - 데이터플랫폼 계정 및 라이센스 할당, 스펙 설정 - API 및 데이터 웨어하우스 활용 가이드 제공 - 외부 리소스 활용한 아이디어, 방향성 제시 |
- NLP 모델 활용한 다국어 데이터 처리 리서치 - LLM 프롬프트와 호출 비용 분석 - 통계 기반 가설 검증과 인사이트 도출 - 비즈니스 목적에 맞춘 모델 평가 지표 설계 |
데이터 엔지니어링 | 데이터 시각화 |
- 데이터 그레인 정의, API 활용 가능성 리서치 - 외부 API 기반의 데이터 수집 - 클라우드 기반 데이터 웨어하우스 연동 최적화 - 데이터베이스 메타 분석과 문서화 - SQL 쿼리 최적화 및 성능 모니터링, 검증 - 데이터 정합성 문제 해결 및 관계 테이블 설계 - 대시보드용 요약 테이블 운영 - 데이터 통합 플랫폼 활용한 파이프라인 구축 |
- 데이터 기반 대시보드 설계 및 구현 - 대시보드 설계 단계의 시뮬레이션 및 피드백 수집 - BI 도구와 클라우드/정적 데이터 연동 - 인포그래픽 및 웹앱 설계, 제작 |
지난 3개월 동안 진행한 내용 중 제일 비중이 컸던 키워드는 데이터 엔지니어링이었다. 글 서두에 합류 직후 현업에 바로 투입되었다고 언급했는데, 데이터 인프라를 셋업하기 위한 업무를 주로 진행했기 때문이다.
“당장 필요하니까 해본다”의 방식으로 일을 진행해왔는데, 이렇게 정리함으로써 내가 무엇을 하고 있는지 보다 명확하게 파악할 수 있었다. 특히 구체적인 업무 내용을 데이터 분야의 용어로 추상화할 수 있다는 점이 만족스럽다. 머릿속에서 명쾌하게 설명할 수 있게 되었다고 느낀 요소들을 몇 가지 나열해보면 이렇다.
데이터(통합)플랫폼
데이터를 통합, 활용하기 위한 각종 시스템을 ‘데이터 통합 플랫폼’이라는 용어로 표현할 수 있었다. Snowflake, Tableau 등이 여기에 해당된다.
데이터웨어하우스(DHW)
데이터베이스 이론에서 항상 보던 이 용어가 바로 여기에 쓰인다는 것을 알았다. ‘대용량 데이터를 중앙 집중식으로 관리하는 저장소’ 라는 정의로는 크게 와닿지 않았는데, 실제 업무를 해온 환경을 돌아보면 데이터 레이크, 웨어하우스, 데이터 마트 등으로 모두 설명할 수 있었다.
데이터 그레인 (Granularity)
데이터를 적재, 분석하는 세부 수준을 일컫는 말이다. ‘데이터를 어떤 기준과 단위로 다뤄야 하지?’ 라는 고민이 곧 데이터 그레인에 대한 정의였음을 알았다.
데이터베이스 메타 분석
쿼리를 작성하기 위해서는 데이터베이스의 구조부터 전반적으로 파악해야 했다. 이러한 일련의 작업은 메타 분석이라는 이름으로 정리할 수 있었다.
데이터 정합성
샘플이 중복되거나, 일관되지 않거나, 누락되기도 했다. 또 맵핑하는 key에 따라 결과가 부정확하기도 했다. 데이터를 정확하게 추출한다는 것은 데이터의 정합성을 체크했음을 전제로 한다.
요약 테이블
여러 소스로부터 데이터를 수집하고 가공, 집계한 결과를 하나의 테이블에 밀어 넣었다. 단순하게 ‘대시보드용 테이블’이라고 부르던 것을 요약 테이블이라는 말로 설명할 수 있게 되었다.
그 외에도 API가 무엇인지 실질적으로 이해했고, 데이터베이스의 기본 요소나 성능 최적화에 대해서도 고려할 수 있게 되었다. 면접에서 “API 가 무엇인가요?” 라고 물어보았을 때, “Application Programming Interface의 줄임말입니다” 라고 외운 대로 읊는 수준에서 한 걸음 더 발전한 느낌이랄까.
나가며
마지막으로 나의 결심을 다시 한번 상기해보겠다.
- 기본기와 전문성을 갖추는 것
- 내가 무슨 일을 하는지 명확하게 정리하고 인지하는 것
사실 1번과 2번은 아주 밀접하게 연결되어 있었다. 기본적인 지식이 있어야 내가 무슨 일을 하는지 이해할 수 있다.
지난 3개월은 각종 불안과 불확신으로 가득했다. 특히 실력을 키워야 한다는 강박관념이 제일 컸다. 때로는 퇴근하면서 “오늘 엄청나게 바빴지만, 실제적으로 한 일은 없는 것 같다” 라는 불안감에 떨기도 했다. 하지만 이번 회고를 통해 내가 해본 적 없는 영역의 기본기를 쌓는 과정이었음을 배웠다. 어떻게 보면 퍼즐이 맞춰지는 과정과도 같았다. ‘그래서 팀원이 그때 그렇게 했구나’ 혹은 ‘그래서 SQLD 시험에 그런 내용이 포함되어 있었구나’ 라고 깨달은 것이다.
어쩌면 이것은 비전공자의 숙명일지도 모른다. 이 모든 걸 전공 수업에서 진작에 배웠다면 좀 달랐을까? 하는 상상이 스쳐 지나갔지만, 이제 그런 걱정은 소용이 없다. 앞으로 무엇을 할지가 더 중요하니까. ML엔지니어답게 베이즈 업데이트해갈 뿐이다.
(난데없지만 나의 성장 과정이 베이즈 확률 모델처럼 작동한다고 느껴졌다. 초보적인 이해라는 사전 확률에서 시작하여 다양한 경험과 시행착오를 통해 데이터를 쌓고 사후 확률로서 업데이트된 실력으로 나아가는 것이다 … 이런 비유가 자꾸 떠오르는 것은 인문학도의 숙명이라고 하자.)
여전히 내가 무엇을 하고 싶은지 딱 잘라 말하기 어렵고 나의 직무에 대해서 자신 있게 설명하지 못한다. 그럼에도 불구하고 다행인 것은 아직도 하고 싶은 게 너무나도 많다는 것이다! ML엔지니어가 아니면 안 된다는 고집과 스페셜리스트가 되는 것에 대한 로망은 잠시 내려놓고, 초심으로 돌아가려 한다. “앞으로 무엇이 되어야 한다” 라는 강박에서 벗어나기 위함이다. “지금 당장 할 수 있는 것”을 수행하고 그 경험을 잘 정리하는 것이 어제의 나보다 나아지는 길일 테다.
그럼, 내일도 힘 내보자.