Search

오몰내알’s blog

오늘은 몰라도 내일은 알자

- Data Engineer - Analytic Engineer - 지식 공유자
kgw7401@gmail.com

Posts

Search

2024년 주요 이벤트

올해는 저에게 정말 up&down이 많았던 해가 아니었나 싶습니다. 연초에는 좋은 일들이 있었지만 연말로 갈수록 번아웃이 오면서 커리어적으로 고민이 굉장히 많았던 것 같습니다. 그렇다보니 24년 회고를 쓰는데도 쉽지는 않았는데요. 하지만 조금 더 나은 삶을 만들어나갈 수 있을 거라는 믿음을 가지고 힘을 내서 회고를 적어보았습니다.
회고를 하기 앞서 24년에는 어떤 것을 해왔는지 달마다 주요 이벤트를 먼저 정리해보았습니다.
정리를 하면서 놀랐던 점은 뭔가 한게 많으면서도 한게 없다(?)는 느낌이었습니다. 이직 후에 정말 회사 일에 파묻혀 살았다보니 일은 많이 했지만 회사 프로젝트 말고는 크게 기억에 남을 만한 일이 없다는 게 약간 뿌듯하면서도 아쉬웠습니다. 그래도 정리해본 주요 이벤트에서 주요한 키워드를 몇가지 뽑아보자면 아래와 같습니다.
첫퇴사 첫이직 라이너 외부 활동 복싱 번아웃

첫퇴사 첫이직

아마 24년도 가장 큰 이벤트가 아니었을까 싶습니다. 1년 반 정도 근무했던 첫 회사를 퇴사하고 이직을 하였습니다. 첫 회사였던만큼 많이 배웠고 많은 일들이 있었습니다. 언제나 그렇듯 이직 준비를 하는 과정은 꽤나 쉽지 않았습니다. 특히 당시는 개발자 붐이 꺼지고 채용 시장이 얼어붙고 있던 시기였기 때문에 많은 직군 중 DE로서의 이직은 정말 어려웠습니다.
그래도 언젠가 나와 핏한 회사를 발견할 수 있을 것이라고 믿고 꾸준히 이직 준비를 하였고, 최종적으로 현재 회사에 최종합격하여 이직을 하였습니다.
이와 관련된 이야기는 다른 포스팅에서 상세히 적어놓았기 때문에 이것으로 갈음하도록 하겠습니다.

라이너

4월 1일부터 라이너에서 두번째 커리어를 시작하게 되었습니다. 라이너에서의 생활은 올해 정말 저에게 많은 영향을 끼쳤는데요. 그 덕에 문화적으로나 커리어적으로나 여러 자극과 고민을 많이 하게되었던 것 같습니다.
2024년 회고와 2025년 목표
데이터 엔지니어의 2024년 회고
Life
2025/01/05
개발자라면 학생 때부터 항상 듣는 이야기가 있죠. “개발자는 CS가 중요하다” 하지만 막상 학생 때 운영체제, 자료구조 등의 지루한 수업 등을 들을 때는 이게 왜 중요한가라는 생각을 하곤 했습니다. 과연 이런 이론들이 실무에서 쓰이는 것이 맞는 지 의심을 많이 했었는데요. 실제 개발자로 살고 있는 요즘 이런 기본기의 중요성을 매우 체감하고 있는 것 같습니다.
요즘 다시 CS를 공부해보고 싶다는 생각이 들었지만 어디서부터 어떻게 시작해야 할 지 감이 오지 않아 계속 백로그로만 쌓여 있었는데요. 때마침 글또에서 길벗출판사로부터 책 후원을 받을 수 있는 좋은 기회가 생겨 이를 활용할 수 있었습니다!
여러 책들 중에 저는 “컴퓨터 밑바닥의 비밀”이라는 책을 선택하였는데요. 이유는 위에서 설명드린 것처럼 다시 한 번 저의 CS 지식을 점검하고 복습하는 목적이었습니다.
책은 컴퓨터의 동작원리를 다루고 있는데요. 운영체제, 자료구조, 알고리즘 등 컴퓨터의 근간이 되는 CS를 대부분 다루고 있고, 자칫하면 굉장히 지루하고 어려울 수 있는 내용임에도 아주 높은 퀄리티와 쉬운 설명을 기반으로 구성되어 있습니다. 걱정과 다르게 저도 굉장히 재밌게 읽었고, 책 내용이 꽤 많음에도 불구하고 3일만에 완독을 하였네요
책은 각 목차별로 크게는 아래의 내용들을 다루고 있습니다.
이번 리뷰에서는 1, 2장 일부를 소개해드리려고 하는데요. 정말 책의 모든 부분이 거를 내용없이 알차게 구성되어 있어서 꼭 책을 구입하시면 정독해보시는 것을 추천드립니다!

1장. 프로그래밍 언어부터 프로그램 실행까지, 이렇게 진행된다

1장은 컴퓨터가 어떤 방식으로 동작하는지 프로그램의 실행과정을 다루고 있습니다. 기본적으로 CPU는 데이터를 옮기는 매우 간단하고 멍청한 작업만 수행할 수 있습니다. 하지만 CPU의 가장 큰 특징은 이러한 행동을 매우매우 빠르게 수행할 수 있다는 것이죠. 우리는 이러한 특징을 이용하여 코드를 실행하는데요.
여기서 코드는 우리가 수행하고자 하는 명령을 추상적인 언어로 표현한 것입니다. 인간은 평소 굉장히 추상적으로 소통하는데, CPU는 이러한 추상적인 언어를 모릅니다. 예를 들어 “물 한잔을 주세요”라는 명령이 있다면 단순히 저렇게 명령해서는 CPU가 명령을 수행하지 못합니다. 오른쪽 다리를 내딛는다 → 멈춘다 → 왼쪽 다리를 내딛는다 → … → 물컵을 잡는다 → … 와 같이 굉장히 구체적으로 명령을 해주어야 제대로 동작을 수행할 수 있습니다. 어셈블리어 같은 언어가 이러한 저수준의 통제를 위해 만들어진 언어라고 할 수 있습니다.
매번 이렇게 코딩을 해야한다면 생산성이 매우매우 좋지 않기 때문에 인간은 보다 편리한 코딩을 위해서 C, 파이쎤과 같은 고수준의 언어를 만들어냅니다. 하지만 결국 프로그램 실행을 위해선 컴퓨터가 이해하는 0과 1로 변환이 필요한데, 이 역할을 하는 것이 바로 컴파일러입니다.
이 밖에도 1장에서는 컴파일러가 여러 소스 코드로 이루어진 프로그램을 컴파일하였을 때 소스 코드들을 모아 하나의 실행 파일로 만들어주는 링커라는 개념까지 아주 알차게 다루고 있습니다.
[도서 리뷰] 컴퓨터 밑바닥의 비밀
컴퓨터 시스템의 본질을 알면 코드의 실마리가 보인다
Review
2024/12/05

Open table format이란?

Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to compute engines including Spark, Trino, PrestoDB, Flink, Hive and Impala using a high-performance table format that works just like a SQL table.
•
공식문서에 따르면 iceberg는 대용량 분석을 위한 고성능의 오픈 테이블 포맷(OTF)이라고 되어 있습니다.
•
오픈 테이블 포맷이 무엇일까요?
•
데이터 레이크(DL) vs 데이터 웨어하우스(DW)
•
테이블 포맷은 DL의 관리 문제로 인해 생겨났습니다.
•
OTF은 DL에서도 RDBMS와 같이 데이터 신뢰성을 보장해주는 작업을 위해 탄생했다고 볼 수 있습니다.
•
Apache Iceberg 또한 OTF 중에 하나입니다.

Apache Iceberg OTF

•
Iceberg는 전통적인 데이터베이스의 SQL 테이블과 유사한 성능 및 기능을 다양한 엔진을 사용해서 접근할 수 있도록 합니다.
•
Iceberg는 특정 시점 스냅샷을 기록한 메타데이터를 통해 DL에서 SQL 테이블과 같은 기능을 사용할 수 있도록 합니다.
•
또한 이러한 스냅샷 메타데이터를 계층 구조로 관리하기 때문에 테이블 업데이트에 빠르고 효율적으로 대응할 수가 있습니다.
•
기본적으로 standard file format(Parquet, Avro…) 뿐 아니라 , Dremio, Spark, Hive와 같은 엔진들을 지원합니다.
What is Apache Iceberg?
Iceberg의 특징과 차별점
Iceberg
2024/11/24
목차

Highlight

•
데이터 팀을 프로덕트 팀처럼 운영하는 방법에 대해 논의합니다. 데이터 팀의 목적과 문제점, 그리고 이를 극복할 수 있는 "data product"의 개념 및 그 실행 방법에 대해 설명합니다.

Intro

데이터팀을 운영한다는 것은 여타 다른 팀을 운영하는 것보다 더 어려운 것 같습니다. 그도 그럴 것이 조직이 데이터 기반으로 일하게 된 것도 그리 오래지나지 않았기 때문에 다른 조직에 비해 레퍼런스가 적은 편이죠.
저도 데이터팀의 일원으로서 어떻게 하면 데이터 조직의 영향력을 늘리고, 회사의 성장에 기여하도록 방향성을 설정할 수 있을까에 대한 고민을 하게 되는데요.
그 고민의 일환으로 최근 data as a product라는 개념에 대해 리서치하고 있습니다. data as a product는 말 그대로 데이터를 하나의 프로덕트로 보고 이를 조직 내에 적용시킨다는 개념인데요.
저 또한 명확한 정의를 알기가 어려워 이런 저런 자료를 찾아보다 dbt 채널에서 Netlify 데이터팀이 발표한 자료에서 좋은 인사이트들을 얻어 내용 정리+의견을 담아 공유합니다.

데이터팀의 목적

•
조직이 더 나은 의사결정을 하도록 돕는 것
•
하지만 안타깝게도 데이터팀은 항상 질문 폭격을 당하느라 조직의 본질적인 목적을 잃게 됨
•
데이터팀은 아래의 악순환을 반복하게 됨
•
악순환의 이유
•
데이터팀은 서비스 조직이 아니라 더 나은 의사결정을 가능케 하는 데이터 프로덕트를 만들어야 한다
데이터팀을 프로덕트팀처럼 운영하는 법
data as a product의 의미
Data
Culture
Reference
2024/11/09
디멘젼 모델링은 크게 팩트 테이블과 디멘젼 테이블 두 가지로 구성됩니다. 그 중 디멘젼 테이블은 데이터를 다양한 각도로 볼 수 있게 해주기 때문에 디멘젼 모델링에서 핵심이라고 할 수 있겠죠.
이런 디멘젼 테이블에서의 속성들이 변하지 않는다면 큰 문제가 되지 않겠지만 만약 값이 변한다면 어떻게 될까요? 이를 참조하는 팩트 테이블에서도 굉장한 혼란이 올 것이고, 정확하게 분석을 할 수 없게 됩니다. 예를 들어, 어떤 상품의 품목에 변경이 있었다면 품목별 총 매출을 구할 때 해당 상품을 어떤 품목으로 집계할 것인지 혼란이 있을테죠.
이런 식으로 디멘젼 테이블 속성의 변화에 대응하기 위해 만든 방법론이 바로 오늘 다룰 Slow Changing Dimension(SCD) 입니다. 이름에서 알 수 있듯이 디멘젼 변화에 대응하는 방법의 종류를 다룬 것인데요. 총 8가지 종류가 있기 때문에 천천히 하나씩 다뤄보도록 하죠.

Base

SCD는 크게 베이스가 되는 base 방법과 이 베이스들을 섞어 만든 hybrid 방법론이 존재합니다. 사실 대부분은 이 베이스들만 사용하는 경우가 많기 때문에 이 부분만 잘 알고 있어도 SCD를 이해하는데 큰 문제가 없기는 합니다.

Type 0: Retain Original

•
디멘젼 속성이 절대 변하지 않습니다.
•
영구 식별자, 날짜와 같이 변경되지 않는 속성에 적합합니다.

Type 1: Overwrite

•
예전 속성이 새로운 속성으로 덮어쓰여집니다.
•
따라서 type1은 항상 최신 값을 가지고 있고 과거 데이터를 없애버립니다.

Type 2: Add New Row

•
새로운 속성을 추가합니다.
SCD(Slow Changing Dimension) 테이블 7가지 타입
디멘젼 테이블의 변경 이력을 잘 관리하는 법
Data Modeling
2024/10/26
목차
Under the hood, BigQuery employs a vast set of multi-tenant services driven by low-level Google infrastructure technologies like Dremel, Colossus, Jupiter and Borg. - Google Cloud Blog 발췌
여러분들은 빅쿼리가 여러 첨단(?) 기술들로 이루어진 구글 기술의 총집합체라는 사실을 알고 계셨나요?
저는 꽤나 오랫동안 Bigquery를 애용하고 있는데요. 문득 자칭 Bigquery 매니아라면서 작동 원리도 모르고 쓰는 것이 굉장히 무례하다는 생각이 들었습니다.
그렇게 개인적인 호기심+리스펙으로 빅쿼리의 내부 아키텍처를 리서치해보았습니다.

Dremel: 논문으로 알아보는 Bigquery 컴퓨팅 핵심

위에서 언급했지만 빅쿼리는 여러 기술들이 사용되었습니다. 그 중 빅쿼리 서버리스 아키텍처의 핵심 포인트는 스토리지와 컴퓨팅이라고 볼 수 있는데요. 빅쿼리는 이 둘을 디커플링하여 독립적으로 유연하게 관리할 수 있다는 장점이 있습니다.
엔지니어라면 한 번쯤 읽어봐야 할 Bigquery 컴퓨팅 아키텍처

돌아보기

학창 시절

인정 욕구 (초등학교~중학교)

초등학교와 중학교 시절, 저는 꽤 공부를 잘하는 학생이었습니다. 늘 어른들의 기대에 부응하며 나쁜 일은 하지 않는, 이른바 모범생에 가까웠습니다. 그래서인지 인정 욕구가 굉장히 강했던 아이였던 것 같습니다. 항상 부모님이나 선생님의 인정을 받고 싶었고, 그 인정을 받기 위해 노력했습니다. 독서나 글쓰기도 자주 했는데, 지금 돌아보면 그것을 좋아해서 했다기보다는 인정을 받고 싶어서 시작한 것 같습니다.
물론 이러한 인정 욕구가 저를 나쁜 방향보다는 좋은 방향으로 이끌어주기도 했습니다. 초등학교 시절에 했던 독서 덕분에 저는 지금까지도 책을 좋아하고 글쓰기에 욕심이 많습니다. 하지만 이런 인정 욕구가 저를 약간 수동적으로 만들기도 했던 것 같습니다. 제가 좋아하는 것보다는 어른들이 좋아하는 쪽에 조금 더 초점을 맞췄고, 제 약점을 인정하지 못하는 성격을 키우기도 했습니다.

우물 안 개구리 (고등학교)

중학교 내내 좋은 성적을 유지했던 저는 명문 고등학교에 입학하게 되었습니다. 이름만 들어도 알 만한 고등학교에 입학한 저는 그곳에서도 잘할 수 있을 것이라는 착각을 품고 학교생활을 시작했습니다. 그러나 그 착각은 얼마 안 가서 깨졌습니다. 전국에는 공부를 잘하는 학생들이 정말 많다는 것을 몸소 체험하면서 자존감이 많이 떨어졌던 시기였습니다.
늘 하위권 성적을 기록했고, 내신뿐 아니라 모의고사에서도 좋은 성적을 내지 못했습니다. 가장 후회되는 것 중 하나는 이러한 제 상태를 인정하지 않고 주변의 잘하는 친구들과 저를 동등한 수준이라고 생각했던 것입니다. 아마 제 수준을 인정하고 차근차근 노력했다면 더 좋은 결과를 냈을지도 모른다는 생각이 듭니다.
하지만 이 시기에서 부정적인 에너지만 얻은 것은 아닙니다. 아마 일반 고등학교에 진학했더라면 얻지 못했을 좋은 친구들을 만나 즐거운 학창 시절을 보냈습니다. 특히 기숙사 생활을 하면서 정말 다양한 경험을 했고, 인격적으로도 많이 성장했던 시기였다고 생각합니다.

대학교

데이터와의 우연

첫 번째 수능에서 처참하게 실패한 후 재수를 했지만, 다시 한 번 원하는 성적을 얻지 못했습니다. 삼수는 부모님께 죄송한 일 같아 결국 대학 진학을 결정했습니다. 하지만 그 당시 저는 명확한 꿈이 없었기 때문에 어떤 학과에 진학할지도 정하지 못한 상태였습니다. 다만, 문과와 이과를 모두 아우를 수 있는 학과를 가고 싶다는 막연한 생각이 있었습니다.
여러 학과 중 고민을 하다 AI와 경영을 함께 배울 수 있는 학과에 지원하게 되었습니다. 당시 알파고가 한창 이슈였지만, 저는 이러한 이슈에는 별로 관심이 없었습니다. 단지 데이터와 경영을 함께 배울 수 있겠다는 생각으로 지원서를 넣었고, 최종적으로 합격했습니다. 그러나 큰 열정을 갖지 않은 상태에서 학교를 다니기 시작했습니다.
내가 걸어온 길을 돌아보다
삶의 지도를 통한 본 나
Life
2024/09/14
Airflow를 사용 중인 개발자라면 한번쯤은 Executor와 Operator에 대해 들어보셨을 겁니다. 하지만 둘의 정의를 어림짐작하고 사용하는 경우도 꽤나 많을 텐데요. 저 또한 그 둘의 관계를 잘 모르는 상태로 단지 사용만 하고 있었는데요. 이번 포스팅으로 Executor와 Operator의 관계, 특히 프로덕션 환경에서 많이들 사용하는 KubernetesExecutor와 KubernetesPodOperator의 관계에 대해 알아보려고 합니다.

Executor와 Operator에 대해

KubernetesExecutor와 KubernetesPodOperator에 대해 알아보기 전에 먼저 그냥 Executor와 Operator에 대해 알아보도록 하겠습니다. 사실 이 둘을 알면 결과적으로는 KubernetesExecutor와 KubernetesPodOperator 알게 되니까 말이죠.
Executor와 Operator는 둘다 Airflow의 task를 다룬다는 공통점이 있습니다. 이런 공통점 하에 둘의 차이점을 살펴보면 둘의 역할을 아주 간결하고 쉽게 설명할 수 있죠.
•
Executor: Airflow가 어떻게 Task를 실행할지 결정
•
Operator: Airflow가 무슨 Task를 실행할지 결정
각각 조금 더 자세히 알아보도록 하겠습니다.
먼저 executor입니다. executor는 말 그대로 Airflow task를 실행하는 주체입니다. executor에는 다양한 종류가 있습니다. SequentialExecutor, LocalExecutor, CeleryExecutor, KubernetesExecutor 등 다양한 종류가 있는데요.
각각의 이름에서 알 수 있다시피 모두 task를 실행하는 방법이 다릅니다. 예를 들면 가장 기본적인 executor인 SequentialExecutor는 task를 순차적으로만 실행시킬 수 있죠. 나머지 executor에 대해서는 나중에 시간이 된다면 다뤄보도록 하고 오늘 알아볼 것은 KubernetesExecutor입니다.
이름에서 알 수 있다시피 KubernetesExecutor는 쿠버네티스를 이용하여 task를 실행합니다. 가장 큰 특징은 아래 3가지로 정리할 수 있습니다.
1.
분산 처리
2.
독립된 환경
KubernetesExecutor와 KubernetesPodOperator의 관계
AKA. KubernetesExecutor와 KubernetesPodOperator는 종속적인 관계가 아닙니다!
Airflow
2024/06/30

이전 글

들어가며

저번 시간 퇴직 회고에 이어 이번 포스팅에서는 이직기를 풀어보려고 합니다. 요즘 채용시장, 특히 개발자 채용시장이 얼음장처럼 차갑다 보니 저 또한 이직 과정이 순탄치 않았습니다. 그래서 글 제목은 나의 해방일지를 본따 나의 이직일지라고 지어보았습니다. 이 글에서는 그 과정에서 겪은 일들과 느낀 점들을 솔직담백하게 작성하려 합니다.

이직을 결정한 이유

먼저 제가 왜 이직을 결정하게 되었는지부터 설명해야겠습니다. 이전 포스팅에서도 간단하게 언급했지만, 한 마디로 요약하면 더 큰 문제를 풀어내기 위한 새로운 환경을 찾기 위해서라고 할 수 있을 것 같습니다. 이전 직장에서 저는 엄청나게 깊지는 않지만 다양한 스펙트럼의 문제를 정의하고 풀어나갈 수 있었다고 생각합니다. 사회 초년생으로서 이런 기회를 갖게 된 것은 긴 커리어로 봤을 때 매우 좋은 경험이었다고 생각합니다.
하지만 이런 경험들을 하면서 한편으로는 조금 더 큰 문제를 깊게 파보고 싶다는 생각이 들었습니다. 밑에서 언급하겠지만, 이는 이직을 결정하게 된 계기이자 다음 회사를 선택하는 데 가장 중요한 기준이 되었습니다. 어찌됐든 꽤 예전부터 이런 생각을 했었고, 조금씩 이직 준비를 하면서 이따금 면접도 보았습니다.
이직 준비 초기에는 이직이 처음이기도 하고 처음에는 이 정도면 괜찮겠지라는 막연한 낙관 마인드로 이직 시장을 쉽게 봤는데, 역시나 차가운 시장은 저에게도 예외가 아니었습니다 그리고 그 과정에서 수많은 좌절과 시행착오를 겪다 보니 무엇이 잘못됐고 무엇을 준비해야 하는지 어느 정도는 감을 잡아갔던 것 같습니다.

나의 이직일지

회사 기준

먼저 저는 아무 생각 없이 이직을 준비하고 싶지 않았습니다. 많은 사람들이 첫 회사가 중요하다고 말하고 저 또한 그 의견에 일정 부분 동의하는데, 얼마 전 우연히 두 번째 직장이 더 중요하다는 글을 보았습니다. 글의 요지는 이직이 당연해지고 중고 신입이 만연해진 요즘, 처음부터 좋은 직장에 가기 위해 의미 없는 공백기를 만드는 것보다 하루빨리 의미 있는 경험을 할 수 있도록 하는 것이 더 낫다는 내용이었습니다.
그리고 여기서 두 번째 직장이 더 중요하다고 한 이유는 중고 신입 포지션으로 가더라도 너무 단기간 여러 회사를 거친 사람보다는 첫 직장을 디딤돌로 삼을 교두보로 삼되, 두 번째 회사부터는 굵직한 경험을 하면서 성장을 할 생각을 갖는 것이 더 중요해진 시점이 아닌가라는 의견이었습니다. 직장에 대한 패러다임이 바뀌고 있는 요즘 굉장히 와닿는 글이었고, 정확히 제가 처한 상황이었기에 더더욱 다음 회사를 신중하게 정해야겠다고 생각했습니다.
그래서 명확한 기준을 세우고 이를 최대한 지키고자 노력했습니다. 그리고 제가 세운 기준은 다음과 같습니다.
만 2년차 데이터 엔지니어의 첫회사, 첫퇴직 그리고 첫이직 (2) - 나의 이직일지
첫번째 이직을 준비하며
Footprint
2024/06/22

들어가며...

현재 회사에서 근무한지 벌써 1년 8개월이 되었습니다. 길다고는 할 수 없는 기간이지만 나름 다양한 것들을 해보면서 의미 있는 경험을 했다고 생각합니다. 2022년 여름에 인턴으로 첫 입사를 하게 될 때까지만 해도 정규직으로 근무를 하게 될지도 몰랐고 1년을 넘게 다닐 줄은 꿈에도 생각하지 못했습니다. 약 2년의 시간 동안 첫 회사로서 개발자로서뿐만 아니라 사회인으로서 많은 것을 배웠다고 생각합니다.
그리고 2024년 3월을 마지막으로 지금의 회사를 떠나 개발자로서 첫 이직을 하며 새로운 출발을 하고자 합니다. 그리고 조금 더 발전된 다음 스텝을 위해 첫 회사에서 어떤 점을 배웠고 나는 무엇을 개선해야 할지, 이직은 어떻게 준비했고 무엇을 느꼈는지 써보려고 합니다.
원래는 퇴사와 이직 회고를 한 번에 작성하려고 했는데 목차를 작성해보니 생각보다 분량이 많아서 글을 작성하는 저도 페이스 조절이 힘들고 독자들도 가독성이 별로 좋지 않을 것 같아서 1편(퇴사) / 2편(이직) 회고를 따로 작성하려 합니다. 이번 포스팅은 전 직장에서 어떤 것들을 경험했고 무엇을 느꼈는지 앞으로 제가 개선해야 할 부분은 무엇이 있는지 써내려가 보려고 합니다.

첫 회사에서의 다양한 경험

2022년에 현재 회사에 인턴으로 입사를 했었습니다. 2달짜리 인턴이었고, 저 또한 처음 면접을 준비할 때는 2달만 실무를 경험하고 다시 취준을 하려고 했었습니다. 하지만 이 회사의 기술 블로그와 면접 경험은 데이터 엔지니어의 목표가 있었던 저에게는 굉장히 좋은 인상으로 남았습니다. 데이터뿐만 아니라 이를 잘 활용하기 위한 다양한 기술을 정말 똑똑하고 좋은 사람들과 같이 경험해볼 수 있겠다는 확신이 들었고, 이는 2달의 인턴 후 정규직으로 전환하게 된 결정적인 계기가 되었습니다.
그 후 재직 중에는 정말 다양한 경험을 했다고 생각합니다. 누군가는 너무나도 다양하고 많은 일을 해야 하는 스타트업이 별로라고 말할 수 있겠지만 아무것도 모르는 신입인 저에게는 오히려 다양한 일을 할 수 있었던 것이 너무 재미있고 의미 있는 경험이었습니다. 개발자라는 타이틀로 입사했지만 서비스를 만들고 성장시키려는 많은 노력을 위해서 다양한 포지션에서 활동하고 굉장히 작을 수 있지만 성과를 내는 것은 스타트업의 묘미가 아닌가 싶습니다.
다양한 경험을 했지만 그중에서 저는 3가지를 2년 동안의 가장 큰 배운 점으로 가지고 가고 싶습니다.

1. 주도성과 사이클

앞서 말했듯이 스타트업은 한 사람이 굉장히 다양하고 많은 일을 해야 합니다. 그것도 빠르게. 그렇기 때문에 저는 스타트업에 가장 잘 어울리는 인재는 자신이 맡은 일을 책임감 있게 해내는 주도성과 여러 사이클을 돌 수 있는 업무 속도 및 끈기를 가지고 있는 사람이라고 생각합니다.
처음 인턴 업무를 맡았을 때 저는 당연히 이 모든 것들이 굉장히 부족했습니다. 그래서 처음 받은 1 month 리뷰 또한 업무 속도에 대한 피드백이 있었습니다. 여러 도전과 실험을 많이 해봐야 하는 스타트업에서는 어떤 일을 처음부터 완벽하게 해내려고 하는 것이 독이 될 수 있다는 것을 깨달았습니다.
초기의 나..
지금 제가 완벽하게 하려는 이 일이 생각지도 못한 변수로 결과가 달라질 수도 있고, 아예 쓰이지 않을 수도 있습니다. 따라서 맡은 일을 주도적으로 해나가되 너무 완벽하게 꼼꼼히 하려고 하는 것이 아니라 조금은 틈이 있어도 증명하고자 하는 핵심 가설만 완성하고 그 뒤부터는 피드백을 통해 여러 이터레이션을 돌며 개선하려고 하는 것이 좋다는 것을 깨달았던 것 같습니다.
만 2년차 데이터 엔지니어의 첫회사, 첫퇴직 그리고 첫이직 (1) - 퇴사 회고
1년 8개월 동안 다닌 회사를 퇴직하며…
Footprint
2024/06/22
클라우드 기반의 이른바 모던 데이터 스택(MDS)이 계속해서 커가면서 이제는 모든 기업들이 아주 간편하게 조직 내에 데이터 인프라를 구축할 수 있게 되었습니다. 이렇게 되며 이른바 데이터 민주화라는 개념도 생기게 되었는데요. 데이터 민주화란 특정 조직만 데이터를 접근할 수 있는 것이 아니라 조직 인원 모두가 쉽게 쿼리나 대시보드 등을 만들면서 데이터로부터 가치를 발견할 수 있게 된 것을 말합니다.
이전에는 할 수 없었던 이런 데이터 접근성의 급격한 향상을 통해 많은 사람들이 데이터를 쉽게 이용할 수 있게 되었는데요. 하지만 꼭 이런 데이터 민주화가 장점만 가지고 있는 것은 아닙니다. 데이터 민주화의 가장 큰 장점은 누구나 데이터에 접근하여 여러 부산물(대시보드, 쿼리)를 만들어낼 수 있다는 것인데요. 단점 또한 마찬가지 입니다.
데이터 소유자가 여러 명이 된다면 데이터를 보는 방법도 여러가지가 될 것입니다. 그렇게 되면 분명 같은 지표를 보고 있는데도 다른 결과가 나오게 될 수 있습니다. 어떤 사람은 MAU가 20만이라고 하는데, 어떤 사람은 17만이라고 할 수 있는 것이죠.
이러한 문제를 해결하기 위해 도입된 개념이 바로 sementic layer(시멘틱 레이어)입니다. 그렇다면 시멘틱 레이어를 조금 더 자세히 알아보도록 하겠습니다.

시멘틱 레이어란

먼저 시멘틱 레이어의 사전적인 정의부터 살펴보도록 하겠습니다. 아래는 위키피디아의 내용입니다.
시맨틱 레이어는 기업 데이터의 비즈니스 표현으로, 최종 사용자가 비즈니스 시맨틱 관리를 통해 관리되는 공통 비즈니스 용어를 사용해 자율적으로 데이터에 액세스할 수 있도록 도와줍니다. 시맨틱 레이어는 복잡한 데이터를 제품, 고객 또는 매출과 같은 친숙한 비즈니스 용어로 매핑하여 조직 전체에서 데이터에 대한 통합된 뷰를 제공합니다.
언제나 그렇듯 사전적인 정의는 이해하기가 참 힘듭니다. 시멘틱 레이어를 쉽게 알려면 여기서 딱 한 문장만 알아가면 됩니다. 바로 “데이터에 대한 통합된 뷰를 제공한다”입니다. 위에서도 이야기 했었지만 MDS로 인한 데이터 민주화가 가능해지면서 생긴 가장 큰 문제는 같은 데이터를 다른(틀린) 시각으로 해석할 가능성이 생긴다는 것입니다.
시멘틱 레이어는 이러한 문제를 해결하기 위해 전사 인원 모두가 데이터를 일관성 있게 볼 수 있도록 도와줍니다. 이것을 모두가 데이터를 획일화된 시각으로 보게한다는 의미로 받아들일 수도 있지만 전혀 그렇지 않습니다. 오히려 구성원들이 데이터를 올바른 시각으로 바라볼 수 있게끔 도와줄 수 있게 해주는 역할을 합니다.
아래의 그림을 보면 훨씬 쉽게 이해할 수 있을텐데요.
시멘틱 레이어가 없다면 왼쪽 그림처럼 같은 데이터임에도 다양한 도구를 활용해 보다가 다른 결과를 도출할 수 있게 됩니다. 하지만 시멘틱 레이어가 있다면 중요 지표에 관해서는 미리 정의를 하여 다양한 도구를 이용해도 지표에는 흔들림이 없게끔 할 수 있죠.
더 직관적으로 이해할 수 있도록 예시를 가져왔는데요. 당근은 구성원들이 더 신뢰할 수 있는 지표를 얻을 수 있도록 하기 위해 KarrotMetric이란 중앙화된 지표를 만들었습니다. 이것을 시멘틱 레이어라고 할 수 있죠.
Semantic Layer(시멘틱 레이어) 왜 필요해졌을까?
그리고 새로운 업데이트는 피지컬 스토리지 가격 모델을 소개했는데요. 이 말은 이제 압축된 데이터에 대해 가격을 청구하겠다는 의미입니다.
아래는 각자 다른 압축 정도를 가진 테이블입니다.
Different commpression ratios (9x vs 3x)
90일의 지속시간을 가지고 있는 첫번째 데이터셋을 보면 로지컬에서 피지컬 가격으로 전환하였고 이는 보시다시피 가격이 아래 그림처럼 112,212$에서 27,324$로 내려가는 것을 보실 수 있습니다.
[번역] 빅쿼리는 생각보다 쌉니다
몇가지 규칙만 알고 있다면 빅쿼리는 최고의 가성비입니다
Bigquery
2024/05/24
목차
Fact table도 5가지 종류가 있다는 거 알고 계신가요?