Henry's Algorithm

지금까지 어떤 직군이 있고, 기술들이 있고, 어떤 조직 구조가 있고에 대해서 배웠다.

이제는 어떻게 커리어를 시작하고 전문성을 높일 수 있는지 배워보자.

요즘 세상에서 커리어라는 것이 어떻게 변했고,

어떤 관점을 가지고 커리어 전환, 커리어 시작을 시작하면 좋을지 생각해보자.

일직선으로 우상향 되는 커리어는 더 이상 없다.

이제는 up and down이 많은 다수의 커리어를 가져야 한다.

회사가 바뀌는 경우도 있을 것이고,

직업이 바뀌는 경우도 있을 것이다.

이제는 빠르게 변하는 사회에서 자연스러운 현상이 되었다.

조금 더 젊었을 때, 이것 저것 시도해봐서, 

더 나이가 들기 전에 자신감을 쌓고, 나와 더 맞는 분야를 찾고 최대한 우려먹고 또 찾게 되고 그러는 것이다.

불안하니까 무언가는 배워야 한다고 생각하고, 배우면서 전문성을 갖게 되면

내 미래가 보장받게 되는 것이 아닐까 하는 생각을 하게 된다.

이런 생각을 하는 다른 사람들이 굉장히 많다.

남들과 비교하기 시작하고 자신감이 떨어진다.

이런 것을 극복하기 위해서는 작은 성공들을 많이 하는 것이 좋고,

나와 비슷한 상황에 있는 사람들을 만나고, 같이 공부를 하는 것도 좋다.

앞으로 워터풀하게 하나의 길을 갖게 되는 것이 아니고,

회사는 5~6개 다녀야 한다고 보면서, 커리어라는 것을 빨리 시작하는 것이 중요할 것이다.

계속해서 변화하고 성장하는 것이 중요하다.

발전해서 더 좋은 환경으로 갈 것이다라는 좋은 환경으로 가라.

그러나 이렇게 하려면 무언가를 계속해서 배워야 한다.

이제부터 배울 것 투성이다.

그러면 배움이라는 것은 어떤 관점에서 봐야 하는가.

시간을 들이면 나아지긴 하는데,

계속 배우다 보면, 어느순간 정체기가 온다. 

이때

"아 이거 나랑 안맞아" 라고 생각하면,

아무것도 배울 수 없다.

처음에는 이 정체기가 왔을 때, 즐기려고 해야한다.

그리고 정체기를 버팀으로서 나의 지식이 확 올라가는 경험을 해야한다.

경험이 중요하다.

그냥 무조건 계속 공부하는 것이 아니라,

내가 여기서 무엇을 모르는지 자문자답을 해야한다.

action point

hadoop 세팅 방법.

spark 세팅 방법.

저거도 6개월 풀타임으로 해보고 나와 맞는지 안맞는지 경험을 해보아라.

이 도메인이 나와 맞는지 안맞는지.

가장 중요한 것은 남과 비교하지 않는 것이다.

저 사람은 나보다 앞서 수 많은 시간을 쏟았구나.

이렇게 비교를 해야한다.

인생은 시작점이 중요한 것이 아니라,

종착점이 중요하다

한기용 강사님이 지난 8년간 데이터 팀을 운영하면서 배웠던 점들 공유.

1. 데이터 팀은 영리적으로 매출을 올리는 데 이유가 있다.

매출과의 연관성, 비용 절감 측면에서 커뮤니케이션을 해야 한다.

가장 좋은 것이 이런 것들이 눈에 보이게 지표로 만들어서 대시보드로 제공할 수 있으면 최고다.

이것이 리더의 가장 중요한 역할 중 하나이다.

중앙 집중이건, 하이브리드건 데이터 팀원들을 위해 모이는 것에 힘써야 한다.

2. 데이터 인프라가 첫 번째 스텝이다.

스타트업 관점에서는 데이터 분석도 할 수 있고, 데이터 인프라도 할 수 있는

듀얼 플레이가 가능한 사람을 뽑으면 최적이다.

고려점은 클라우드이냐, 직접 구성이냐.

가능하면 클라우드가 좋다.

그리고 실시간은 비용이 많이 들기 때문에, 왠만하면 배치로 하는것이 좋다.

데이터의 품질이 중요하다.

데이터 청소(Garbage Data를 걸러내는 작업)

데이터 품질을 올리는 방법.

모니터링을 잘하는 것이 중요하다.

중요 데이터(매출 데이터와 같은)에 초점을 맞춰서 품질 유지를 한다.

3. 항상 지표를 생각한다.

성장을 하게 해주는 개발자의 좋은 습관이다.

성공의 척도가 되는 숫자가 무엇인지 알고 있고,

내가 이 일을 왜 하는지 나름대로 가설이 있어야 한다.

ex) 이런 일을 하면서 이런 효과가 있고, 이런 지표를 형성할 수 있다.

성패의 지표를 계산할 때, 남들도 객관적으로 볼 수 있는 지표여야 한다.

지표가 말이 안되고, 어떻게 계산되는지 불분명하면 사람들은 의심하게 된다.

지표를 보다 객관적이고 투명하게 하는 방법을 생각해보라.

4. 가능하면 간단한 솔루션으로 시작해라

(그냥 If 문 볓개 쓰면 될 일을 딥러닝으로 복잡하게 풀지 마라)

현업에서는 딥러닝보다 Linear Regression, Decision Tree로 푸는 상황들이 더 많다.

워터풀 형태로 한 큐에 끝내려고 하지 말고,

점진적으로 한 단계씩 고도화하는 방법이 더 선호된다.

OverEngineering 하지마라!

Done is better than perfect

이것은 데이터 분야에만 국한되는 것은 아니다.

애자일 개발방법론에 대해서 설명하며 시작한다.

(점진적으로 짧은 개발 사이클을 반복하면서 프로그램을 개선해나가는 개발 방법론)

짧은 사이클 - 스프린트(Sprint) 라고 부름.

데이터팀도 애자일 방법론을 따른다.

월요일

(그냥 월요일은 아니고, 스프린트가 새로 시작하는 월요일로 가정)

자기가 한 일을 팀원들에게 비주얼하게 데모한다.

잘됬던 일들, 잘되지 못한 일들 회고.

다시 생각해보아야 할 논의할 포인트 회고.

이런 회고 미팅은 팀장이 혼자 하지 않고, 팀원들끼리 한 명씩 돌아가면서 했다.

이후 논의할 액션 아이템을 찾아내는 것이 중요하다.

(기존 백로그에 있는 스프린트 중에 이번주에 할 일은 무엇인지 계획)

백로그 - 이미 몇몇 사람들이 중요하다고 계획해놓은 작업들.

데이터 파이프라인이 많이 생기면, ETL 들도 많아진다.

그리고 항상 실패하는 ETL들도 생겨난다.

- 데이터 ETL 관련 이슈와 다양한 데이터 관련 질문을 맡을 사람들을 별도로 지정

나머지 사람들은 자기 일에 포커스를 맡는다. 한사람만 조금 고생(온콜 엔지니어)

이후 사후보고를 함.

JIRA - 인터페이스가 구닥다리 느낌

ClickUp - Notion 비슷한 느낌으로 애자일 스프린트 진행 가능하다.

이런 과정을 매일매일 스탠드업에서 팀원들에게 공유한다.

화요일

팀 내에서 미팅을 하는 날, 미팅을 하면 안되는 날을 정하면 조금 도움이 될 수 있다.

팀원들이 집중을 할 수 있기 때문이다.

수,목요일

코로나 펜데믹 이후로는 비디오콜이 큰 의미가 없다.

왠만한 것들은 다 스탠드업도 비디오콜로 하기 때문이다.

- 대시보드는 보며 중요 KPI 지표에 변화를 살펴보는 시간.

- A/B 테스트 중이 머신러닝 모델이 있으면 성능 리뷰 및 공유.(기존 기능과 비교) <- 중요

ex) 이 모델이 현재 5%의 사용자에게 노출되어 있는데 확대할 것인지. 아니면 중단할 것인지.)

금요일

ETL 실패 이유, 성공 이유 리뷰.

머신러닝 모델 개발 상황, A/B 테스트 진행 상황 공유

팀 내 중요 인력들이 행복하게 지내는지 점검.

주간 사고가 있으면 내용 디테일하게 미팅.

시간이 남으면 팀별로 돌아가면서 팀 상황 공유.

머신러닝 모델을 만드는 가정 하에 데이터 과학자들이 어떤 생각을 하는지 한번 살펴보자.

모델을 만드는 것은 시작일 뿐이다.

그것이 현업에서 어떻게 배포되고 사용되는지에 관심을 가져야지

실제로 내가 만든 머신러닝 모델에 의미가 있는 것이다.

데이터 모델 배포 잘 됬어?

실제 서비스 엔지니어: "뭐 잘 됬겠지?"

이런 마찰이 생기는 원인은 어디서 발생하는 것일까?

현재도 많은 수의 데이터 과학자들은 R로 데이터 모델을 만든다.

그러나 이것은 실제 서비스에 접붙이기가 쉽지 않다.

MLOpes 팀이 생기게된 개념.

(머신러닝 모델의 배포와 운영을 해주고, 그것을 자동화하는 것까지 책임지는 팀)

배포를 담당하는 백엔드 엔지니어는 R로 개발된 언어를 받아서

서비스의 java나 python으로 포팅을 하게 되는데, 이것은 2번 일을 하는 것과 다름이 없다.

백엔드 엔지니어 론치하다가 현타옴..

현재는 이런 모델을 만들 때, 만드는 것에서 끝나는 것이 아니라, 이것을 론치시키는 과정까지

조금 더 길게 스코프를 보는 MLOps 팀이 생기게 된다.

MLOps 팀은 개발된 머신러닝 모델을 받아서 이것을 배포하고 운영하는 것까지 책임지게 된다.

예전에는 이 작업을 백엔드 팀이 하고 있었다.

이런 과정을 담당해주는 프레임워크들도 생겨났다.

AWS의 sagemaker 같은 것들이 대표적이다.

트위터 같은 경우에는 데이터 과학자들에게 R 사용을 지양하게끔 했다.

파이썬의 특정 라이브러리만 사용해라. - 배포와 운영 과정을 단순화 시킴.

AWS - SageMaker와 같이 머신러닝 모델 개발, 검증, 배포를 하나의 프레임워크에서 수행.

모델 개발은 시작일 뿐이다.

운영을 통해 점진적 개선을 이루어야 하는 것이다.

운영하다보면, 예전에 개발된 모델의 성능을 개선해야 한다.(성능이 자연적으로 떨어지기 때문이다.)

안녕하세요

코딩교육자 헨리입니다.

오늘은 회사마다 다 가지고 있는 데이터 팀의 조직 구조에 대해서 공부하는 시간을 갖었습니다.

이번 수업을 듣기 전까지는 단순히 데이터 엔지니어 혹은 ML 엔지니어로 일하고 싶다는 생각뿐이었는데,

수업을 들으면서 회사 내 데이터 조직 구조에 대해 미리 질문하고 알아보는 것이 중요하겠구나 라는 것을

깨닫게 되었습니다. 데이터 조직은 중앙 집중, 분산, 하이브리드 형태의 구조가 있다고 합니다.

자세한 내용은 아래 강의 노트를 참고해주시기 바랍니다!

(노트 형식이기 때문에 어투가 변경될 수 있습니다.)

앞으로 배울 구체적인 내용은 아래와 같다.

1. 3가지 데이터 팀의 조직 구조
2. ML 모델 개발시 기억할 점
3. 데이터 조직의 일주일 살펴보기
4. 데이터 일을 할 때 기억할 점

3가지 데이터 팀 조직 구조에 대해서 알아보자

1. 중앙 집중 구조

2. 분산 구조

3. 하이브리드 구조

1. 중앙 집중 구조

데이터 팀의 리더가 대부분을 결정하기 때문에, 현업 부서들의 만족도는 떨어질 수 있다.

각자의 팀에 데이터 담당자가 있으면 좋을 텐데..

2. 분산 구조

데이터 분석가의 위치가 팀원에서 각 팀의 2등시민으로 전락하는 면이 없지 않다..

아무리 잘해봐야 각 팀에 데이터 인력이라는 2등시민 타이틀을 뗄 수가 없다.

그냥 필요한 데이터를 뽑아주는 사람으로 전락해버린다.

다른 팀에 있는 데이터 인력이 하는 일들이 중복되는 경우 발생할 수 있다.

많은 회사들이 중앙 집중 구조 <-> 분산 구조를 왔다 갔다 한다.

3. 중앙집중과 분산의 하이브리드 모델

1년 혹은 6개월에 한번 팀을 옮겨가며 다양한 경험을 하고, 중앙 데이터 팀 소속되어 있으면,

기간을 두고 파견을 하고 다시 돌아오고 그런 경우이다.

위 3가지 구조 중 최악의 구조는 분산 구조이다.

우리가 꼭 해야할 질문!

데이터 팀이 하나의 팀으로 이루어져 있는가. 아니면 분산되어 있는 구조인가.

그러나!

마이크로소프트에 있는 데이터 팀은

재무 팀 안에 데이터 팀을 두어서 그 안에 데이터 엔지니어, 데이터 분석가, 데이터 과학자를 만들고,

기존 엑셀로 800명이 하던 작업을 데이터 웨어하우스를 만들고, 데이터 지표를 만들고, 데이터 모델을 만들어서 5명이 4시간 만에 하는 작업으로 대폭 개선했다.

엑셀을 대시보드로 쓰다가, 마이크로소프트 자체 Power BI를 사용했다.

자주 들어오는 질문을 메신저를 통한 응답에서 자동 대답을 하는 챗봇을 만들어서 재무 관련 질문들의 대답 시간을 대폭 줄이게 되었다.

ex) 파트너사에게 어느정도 금액 이상의 선물을 받으면 법적으로 문제가 될 수 있다.

- 파트너사에게 법적 문제 없이 받을 수 있는 최대 금액은 얼마인가요? 라는 질문이 제일 많이 들어왔다고 한다ㅎ

마이크로소프트의 데이터 팀에 대한 이야기는 디지털 트랜스포메이션의 아주 좋은 한 예이다.

안녕하세요!

코딩교육자 헨리입니다.

오늘은 데이터 커리어 분야에서 새롭게 뜨고 있는 데이터 직군에 대해서

강의를 들었습니다.

데이터 엔지니어, 데이터 분석가, 데이터 과학자 이외에도 실제 서비스를 운영하면서

파생된 다양한 데이터 직군들이 있다는 것을 배우게 되었고,

제가 앞으로 나아가고 싶은 길은 왠지 데이터 엔지니어 혹은 ML 엔지니어가 아닐까 하는 생각을 하게 되었습니다.

아래부터는 강의 요약입니다.

블로그에 노트를 정리하면 쓴 글이므로, 어투가 변경될 수 있는 점 양해부탁드립니다.)

어떤 새로운 직군들 혹은 뜨는 서비스들이 있는가?

# ML 엔지니어 (vs. 데이터 과학자 & 데이터 엔지니어)

 - 근데 JD로 보면, 데이터 과학자 기반 위에 데이터 엔지니어가 약간 더 들어가는 느낌이다.)

# ML옵스 (MLOps)

# 프라이버시 엔지니어: 개인정보 보호

 - 데이터 팀에 속한다고 보기는 어려울 수 있지만, 개인정보 보호에 있어서, 시스템 설계 때부터 생각할 수 있게, 설계해주고, 디자인해주는 직군으로 보면 된다.

# 데이터 디스커버리 서비스

# A/B 테스트 서비스

 - SaaS 형태로 제공되기도 한다.

MLOps란 무슨일은 하는가?

 # DevOps가 하는 일은?

  -- 개발자가 만든 코드를 시스템에 반영하는 프로세스(CI/CD, deployment)

배포하고 테스트를 계속 돌리고, 배포 후에 정상 동작 모니터링하고, 이슈가 생기면 이슈 해결을 위해 일하는 팀이다.

  -- 시스템이 제대로 동작하는지 모니터링 그리고 이슈 감지 시 escalation 프로세스 (On-call 프로세스)

 # MLOps가 하는 일은?

  -- 앞의 DevOps가 하는 일과 동일. 차이점은 서비스 코드가 아니라 ML모델이 대상

  -- 모델을 계속적으로 빌딩하고 배포하고 성능을 모니터링

   * ML모델 빌딩과 프로덕션 배포를 자동화할 수 있을까? 계속적인 모델 빌딩(CT, Continous Training)과 배포!

   * 모델 서빙 환경과 모델의 성능 저하를 모니터링하고 필요시 escalation 프로세스 진행

MLOps 엔지니어가 알아야하는 기술

3가지 데이터 직군 도메인이 겹쳐지는 부분이다.

CI/CD - 개발이 진행될 때마다, 계속적으로 빌드하고 테스트하고 배포할 것인가.

프라이버시 엔지니어란 무엇일까?

 # 전체 시스템에서 개인정보 보호를 위한 가이드라인/툴을 제공

  -- 개인정보란? 개인을 식별할 수 있는 정보

 # 이는 데이터 시스템에서 더욱 중요

 # 개인 정보 보호 법안의 징벌 조항이 점점 강화되는 추세

  -- 정보 주체의 권리를 강화하는 방향으로도 변화: GDPR의 프로파일링 거부권

  -- 유럽 연합의 GDPR (General Data Protection Regulation)

GDPR : 개인이 원하면 내 정보를 사용하지 말아라 라고 요청할 수 있다. 도 GDPR 법안의 일부이다.

  -- 미국의 HIPAA (건강보험 이전 및 책임에 관한 법률)

  -- 미국 캘리포니아의 CCPR (캘리포니아 소비자 개인정보 보호 법안)

데이터 디스커러버리 (Data Discovery)란?

데이터가 너무 많아지고, 대시보드가 너무 많아지면, 점점 어떤 데이터 및 대시보드를 봐야할 지 혼란이 생긴다.

어떤 테이블이 있고, 어떤 테이블을 주가 가장 최근에 사용했고, 어떤 차트가 있고, 어떤 대시보드가 있고,

이런 것들을 검색해주는 서비스가 나오기 시작했다.

실제로 어느정도 규모가 있는 회사에는 이런 이슈가 다 있었다.

이런 이슈를 해결하기 위해 필요한 서비스가 데이터 디스커버리이다.

자 이제 지금까지 배운 것들을 요약해보자.

안녕하세요

코딩교육자 헨리입니다.

오늘은 데이터 커리어 분야의 다양한 직군 중에

데이터를 활용하여 유의미한 서비스 모델을 개발하는 데이터 과학자를 배웠습니다.

이번 강의를 들으면서 멋진 머신러닝 모델을 만들기 위해서는

유의미한 데이터가 우선되어야 한다는 사실을 알게 되었습니다.

아무리 잘하는 데이터 과학자라도, 데이터가 제공되지 않는다면, 큰 힘을 발휘할 수 없다는 것이죠.

아래부터는 제가 노트 정리한 내용들입니다.

(어투가 변경될 수 있으니, 양해 부탁드립니다.)

데이터 과학자의 역할

# 머신러닝의 형태로 사용자들의 경험을 개선

 - 문제에 맞춰 가설을 세우고 데이터를 수집한 후에 예측 모델을 만들고 이를 테스트하는 역할

  * 장시간이 필요하지만 이를 짧은 사이클로 단순하게 시작해서 고도화하는 것이 좋다

 - 테스트는 가능하면 A/B 테스트를 수행하는 것이 더 좋다.

데이터 분석가는 내부 직원들을 상대하지만,

데이터 과학자는 외부 고객들을 상대해야 한다.(우리 서비스를 쓰는 실제 고객들)

# 데이터 과학자에게 필요한 스킬셋

 - 머신러닝/인공지능에 대한 깊은 지식과 경험

 - 코딩 능력 (파이썬과 SQL)

 - 통계 지식, 수학 지식

 - 끈기와 열정, 박사 학위가 도움이 되는 이유 중의 하나

가설을 먼저 잘 세우고, 어떤 문제를 해결할 것인지 이야기를 해보고,

해당 가설이 우리가 달성하고자 하는 목표에 중요한 과정이 될 것 같으면,

프로젝트를 진행한다.

가설: 제대로 해결되면, 어떤 지표가 어떻게 개선이 될 것인지 자세하게 세우는 것이 좋다.

짧은 사이클로 여러번 반복을 해서, 내가 만들고자 하는 모델을 점진적으로 고도화한다.

그렇다면 훌륭한 데이터 과학자란 무엇일까?

- 열정과 끈기

- 다양한 경험

- 코딩능력

- 현실적인 접근 방법?

 * 애자일 기반의 모델링(간단하게 시작해서, 점진적으로 고도화 시키는 것)

 * 딥러닝이 모든 문제의 해답은 아님을 명심하자.

- 과학적인 접근 방법

 * 지표기반 접근(정의가 명확하고 계산이 가능한 지표를 개선해야 한다.)

 * 내가 만드는 모델이 목표는 무엇이고 그걸 어떻게 측정할 것인가

제일 중요한 것은 모델링을 위한 데이터의 존재 여부라고 생각한다.!!

한기용 강사님은 데이터 과학자가 모델을 개발을 할 때, 점진적으로 애자일하게 개발하는 것이 좋다고 하셨는데,

애자일 개발방법론이란 뭘까?

세상이 느리게 굴러갈 때는 폭포수 개발방법론이 가능했다.

디자인 하는 동안 세상이 바뀌지 않았다.

그러나 오늘같은 세상에서는 디자인 하나가 세상이 바뀌게 된다.

그로 인해, 보통 2주 주기를 잡고 짧게 개발하고 구현하고 배포하고, 이 과정을 반복적으로 개발해나가는 것이

더 좋다고 생각이 되어졌다.

머신러닝 모델을 개발하는 과정을 아래와 같다.

모델빌딩 테스트와 A/B 테스트는 엄연히 다르다.

A/B 테스트가 조금 더 실제 사용자 환경과 밀접하게 연결된다.

위 사이클을 돌면서 점진적으로 부족한 부분이 있으면 개선하고, 더 나은 모델로 만들어가는 과정을 거칠 수 있다.

한번에 모든 것을 해결하려고 하는 것이 아니라, 짭게 한바퀴를 돌면서 

미리미리 다양한 형태의 가능성들을 빠르게 파악하면서 개발하는 애자일 방법론이 요즘 트렌드이다.

그럼 A/B 테스트에 대해서 알아보자

Control그룹과 Variation 그룹을 테스트하며 그 차이를 살펴본다.

ex) Udemy에서 상품 추천서비스를 일부는 규칙기반으로 하고, 나머지는 머신러닝 모델로 하면서,

상품 구매율에 대한 어떤 차이가 있는지 확인해보는 것.

A/B 테스트란?

# 온라인 서비스에서 새 기능의 임팩트를 객관적으로 측정하는 방법

 - 의료쪽에서 무작위 대조 시험(Randomized Controlled Trial)에 해당

# 새로운 기능을 론치함으로 생기는 위험부담을 줄이는 방법

 - 100%의 사용자에게 론치하는 것이 아니라 작게 시작하고 관찰 후 결정

 - 어떤 지표를 가지고 성공/실패를 결정할지 정해야 함.

 - 예제: 추천을 머신러닝 기반으로 바꾼 경우

  -- 먼저 5%의 사용자에게 론치. 나머지 95%의 사용자와 매출액과 같은 중요 지표를 기반 비교

  -- 5% 대상으로 별문제 없으면 10%, 20% 이런 식으로 점진적으로 키우고 최종적으로 100%로 론치(잘 동작함을 알게 되면)

100%로 되면 실제 프로덕션으로 론치가 되는 것.

# 보통 사용자들을 2개의 그룹으로 나누고 시간을 두고 관련 지표를 비교

 - 한 그룸은 기존 기능에 그대로 노출(control)

 - 다른 그룹은 새로운 기능에 노출 (test)

# 가설과 영향받는 지표를 미리 정하고 시작하는 것이 일반적(자기 좋을대로 해석하지 않기 위해)

 - 지표의 경우 성공/실패 기준까지 생각해보는 것이 필요

# A/B 테스트의 분석은 과학이 아닌 예술에 가깝다.

안녕하세요 

코딩교육자 헨리입니다.

2022년은 저에게 특별한 해입니다.

제가 데이터 엔지니어로의 길을 시작하려고 마음을 먹은 해이기 때문이죠.

앞으로 2022년에 제가 하고 싶은 일은 아래와 같습니다.

우선, 데이터 엔지니어 특강을 다 듣고, 실제로 제가 되고 싶은 모습이 무엇인지 명확하게 하려고 합니다.

최근 제가 자주 연락하고 있는 한 개발자 친구가 있는데, 그 친구와 카톡을 나누면서

데이터 엔지니어와 ML 엔지니어에 대해서 구분을 할 수 있게 되었습니다.

아직 이 분야에서는 문맹인지라 제대로 된 개념이 필요했는데, 친구에게 설명을 잘 받았습니다.

저는 데이터 인프라를 운영하면서, 한편으로는 ML 모델링로 도움을 주고 싶었습니다. 

그래서 데이터 인프라와 데이터 모델링을 모두 할 수 있는 ML Ops에 대해 관심을 갖게 되었습니다.

ML Ops에 대해서 알게된 것만으로도 2021년의 저를 돌아보았을때, 놀라운 발전입니다.

정량적으로 본다면, 저는 2~3월 동안 프로그래머스에서 진행하는 아래 스터디에 참여할 예정입니다.

1주차부터 6주차까지 데이터 엔지니어링에 대한 질의응답 시간을 통하여 

저의 상황을 잘 말씀드리고, 앞으로 성장하기 위해서 어떻게 해야하는지 그동안 궁금했던 질문들을

마구마구 하고 싶습니다

이 강의를 통해서 제가 얻고자 하는 것은, 

데이터 엔지니어라는 커리어 분야에서 저의 현재 상황을 말씀드리고, 어떤 경험이 필요한지 

그 방향성에 대해서 답을 얻는 것입니다.

그리고 두번째로 정량적인 목표는

데이터 스킬셋에 대한 정의를 하나씩 정리해보는 것입니다.

최근 듣고 있는 데이터 커리어 분야 인강에서 추천 받았던 github 사이트에 이런 그림이 올라와있었습니다.

2021년의 데이터 엔지니어링 분야에 스킬셋들을 잘 정리해둔 표라고 생각합니다.

우선 여기에 나와있는 기술들을 찾아보고, 정의 내려보는 시간을 갖는 것이 두번째 목표입니다.

지금은 단순하게 Hadoop, Spark 만 알고 있는 수준의 나의 상태가

이번 목표를 이루어가면서 어떻게 바뀔지 벌써부터 기대가 됩니다.

물론 모든 기술들을 다뤄볼 수는 없겠지만,

하나씩 기술들의 기능과 필요성에 대해 공부하면서

데이터 엔지니어로서 나의 역할을 잘 잡아갈 수 있으리라 봅니다.

마지막으로 세번째 정량적인 목표는, 개인프로젝트를 실제 서비스로 론칭하는 것입니다.

물론 실제 서비스로 론칭했을 때, 그 반응은 무관심일 수 있습니다

그러나 코딩교육자로써, 누군가에게 코딩에 대해 교육해주는 날이 올 텐데, 

그러기 위해서는 실제로 경험해보는 것만큼 좋은 것이 없지 않을까요?

실제 서비스를 론칭하고 데이터를 적재하고 전처리하고 저장하고 분석하고 시각화하면서,

분명히 2번째 목표에서 공부했던 기술들일 필요한 때가 있을 것입니다.

데이터 양을 베리베리스몰데이터이겠지만.

2022년 겨울의 내가, 2022년 봄의 나를 돌아봤을 때,

이 시작을 꾸준히 안고 달려옴에 감사하는 날이 있을 것입니다.

개인 프로젝트

시작 화면.