어쩐지 오늘은

방통대에 편입했다가 자퇴하며 여러 시도를 했던 2025년 회고

Tue, 30 Dec 2025 00:00:00 +0000

2025년도 보내줄 시간이 다가오고 있네요. 매년 하는 것처럼 올해를 어떻게 보냈는지 회고를 작성해봅니다
과거 회고 글 모음
키워드 : 2025년 회고

들어가기 전에

올해를 어떻게 보냈는지 생각해보면, 사건들이 많진 않다. 왜 그런가 생각해보니 상반기엔 영어 공부를 하느라 시간을 많이 썼다. 직무적인 관점보단 인생에 대한 큰 관점이 더 많다.

떠오르는 사건들

대학원 진학 결심

갑자기 대학원 진학을 고민했다. 이런 고민을 하게 된 배경을 자세히 설명해본다
- 교육을 하면서, 앞으로 또 어떤 것을 해야 할까?에 대해 고민했다. 어떻게 더 확장할 수 있을까? 한다면 어떤 방향으로 확장할 수 있을까?의 질문을 던졌다
- 그러다가 지금 내 교육의 대상이 현업에 있는 사람들과 취준생이라는 것을 인지했고, 취준생 시기보다 더 이른 시기에 만나면 좋지 않을까?란 생각이 들었다
- 주변에 교수를 시작하는 친구들도 생기고 있고, 교수는 아니더라도 강사 생활을 통해 학교에서 현업의 이야기나 어떻게 인생을 살아갈지에 대한 이야기를 해주고 싶었다. 인하대에서 김진상 교수님의 수업이 내게 많은 영감을 주었기 때문에 나도 그렇게 전달을 하고 싶었다
- 특정 학교에서 강사 제안을 해주셨지만, 결국에 내가 석사 학위가 없어서 진행되지 않았다. 회사를 다녔다면 겸임 교수를 하는 길도 있을텐데, 당장은 회사를 다니지 않아서 진행하기엔 어려웠다. 교육 경력이 있어도 대학에서는 석사 학위에 대한 것을 요구했다
위와 같은 생각을 하면서 대학에서 강의하기 위한 학위 취득을 고민했다. 그 과정에서 국내 대학원과 해외를 고민했고 지금 하고 있는 일이 있어서 풀타임은 어렵고 영어 공부도 하고 싶다는 마음에 미국 온라인 석사로 마음을 굳혔다.
- 미국 온라인 석사 과정은 조지아텍이랑 텍사스 오스틴이 많이 언급된다. 두 학교의 차이는 토플 점수의 컷과 합격률 등이 있었다. 지금 누가 물어보면 자세하게 이야기를 할 수 있을 정도로 정리가 되어있다. 교육 과정이 살짝 지향점이 다르고, 수강 신청 인원 제한이 있는 등 여러 가지 차이점이 있었다
- Georgia Tech : 토플 100점, Texas Austin : 토플 79점
- 조지아텍은 수강신청 인원 제한이 있고, 텍사스 오스틴은 없다. 인원이 다 차서 수업을 못 듣는 스트레스는 텍사스 오스틴이 없고, CS 관점으론 조지아텍이 조금 더 과목이 풍부하고 텍사스 오스틴은 AI쪽을 더 발전시키려는 움직임을 보인다
25년 1월에 이 생각을 시작하고 2월부터 할 일을 하나씩 시작했다. 그래서 처음으로 시도한 것은 영어 공부(토플)이었다.

영어, 토플 공부

온라인 석사를 고민하는 사람들은 많지만, 결국에 하는 사람들은 적다. 그 이유는 여러가지가 있겠지만 회사를 다니면서 준비하는 것이 어렵다. 시도는 할 수 있지만 끝까지 하는 것이 어렵다. 온라인 석사 과정에서 제일 선행되어야 하는한 것은 영어 성적이나 서류 합격을 위한 작업이다. 토플 공부를 미루다가 토플도 제대로 안보고 포기할 수도 있다
- 그래서 상반기는 거의 영어 공부(토플)만 했다. 그래서 2~6월엔 떠오르는 사건들이 없고, 사진첩이나 캘린더를 봐도 토플의 연속이였다
토플 시험을 보면서 느낀 점은 ‘와 토플은 정말 긴장도가 엄청 높아지는 시험이구나’였다
- 옆에 사람들이 비슷한 템포로 문제를 풀지만, 내가 리스닝을 할 때 스피킹을 시작하는 사람이 있다. 헤드셋을 껴도 잘 들리는 경우도 있고, 옆에 사람들은 하필 또 성량이 높은 사람이라 신경이 쓰인다
- 그럼에도 불구하고 내 집중을 높이기 위한 전략을 쓰고, 그 와중에 내 답변을 잘 해야 했다. 이게 실제 면접이랑 거의 비슷한 것 같고, 코딩 테스트와도 비슷한 것 같았다. 평소에 연습을 잘 해두는 것이 중요한 이유다.
그리고 토플 시험 보는데 드는 비용이 꽤 높다. 그래서 사람들이 시험을 최대한 미루려는 경향을 보인다. 그리고 토플을 좀 더 저렴하게 볼 수 있는 서비스들이 있는데, 이 서비스는 토플 시험비보다 저렴하게 서비스 가격을 구성했다(월 약 3~4만원). 장기적으로 결제를 하는 사람은 적겠지만 시험의 가격이 높으니 월 3~4만원이 상대적으로 저렴해지는 것 같다고 느꼈다
- 더불어 간절함이 큰 곳에 더 큰 돈이 몰린다는 생각도 했다. 유학 컨설팅 가격이 생각보다 높았다.
토플 공부를 하는데, 나는 리스닝이 잘 안된다. 근데 토플의 라이팅과 스피킹은 다 리스닝과 관련 있다. 그래서 리스닝 자체를 올리는데 시간을 투자해야 했고, 리딩은 리스닝보단 괜찮았지만 역시 단어가 굉장히 중요했다. 그리고 빠른 시간에 슥 읽고 핵심적인 부분을 정리하는 것도 중요했다. 시험을 위한 영어라서 영어 실력이 개선되기도 하지만, 시험을 위한 공부를 하는 기분이었다
막판에 성적이 살짝 부족할 때 아이엘츠를 살펴보기도 했다. 리스닝 관점에서 아이엘츠가 좀 더 수월했다. 아마 처음으로 돌아가면 토플보다 아이엘츠를 시도해볼 것 같다(영국식 영어라서 조금 다르긴 해도)
처음 공부할 때는 100점을 목표로 했지만, 공부를 하면서 100점이 내게 좀 어려울 수 있겠다 판단했다. 그래서 토플 기준이 낮은 텍사스 오스틴을 생각했다. 텍사스 오스틴은 토플 점수 기준이 79점이긴 하지만, 합격률이 낮은 편이다. 반면 조지아텍은 토플 점수가 넘으면 합격률은 높은 편이다. 텍사스 오스틴은 컴퓨터 공학 학부 수업을 들었는지를 중요하게 판단하고, 레딧에서 확인하니 CS 필수 과목이라고 할 수 있는 6개 과목을 듣고 신청하는 것이 유리하다고 했다.
결론적으로 오스틴을 지원할 점수는 만들었다. 오스틴 성적은 79점이라 높진 않지만 듣기 실력과 말하기 울렁증으로 참 어려웠다.
2-3월에 토플 학원을 가기 위해 강남에 아침 9시까지 가서 수업을 들었다. 과거에 토익 공부를 하러 강남으로 갔던 것도 떠오르고, 학생이 된 기분이라 그 당시엔 즐겼다. 물론 성적이 바로 나오지 않을 땐 슬픈 적도 있지만 이럴 때 멘탈 회복을 빠르게 회복하는 방법을 알아서 잘 유지하곤 했다. 근데 다시 생각해도 토플은 보고싶지 않다…ㅋㅋㅋㅋ
- 토플을 본 직후에 RC/LC 점수를 보고 너무 슬퍼서 폭싹 속았수다를 보며 더 슬픔으로 덮었다. 드라마를 보니 내 슬픔은 크지 않을수도 있겠는걸.. 이런 생각도 들었다. 내 슬픔이 거시적으로 별거 아니라고 인식하면 슬픔이 사라지는 것 같다

(영단기 홍보 아니고 내돈내산! 월수금 반이 해커스엔 없고 영단기에만 있었다. 영단기에서 강의를 들으면서 선생님과 AI로 토플 학습하는 아이디어 이야기하고 프로토타입 공유했는데 기회가 된다면 나중에 같이 일할 수도 있을 것 같았다)

방통대 진학

위에서 언급한 것처럼 미국 온라인 석사를 할 때 CS 필수 과목을 들었는지 확인해야 한다. 조지아텍과 오스틴이 요구하는 과목이 살짝 다르지만 공통적으로 쓸 수 있다. 이걸 어떻게 채울까? 고민하다가 방통대 진학을 하기로 결정했다. 학점 은행제도 할 수는 있지만 비용이나 일정을 고려하면 방통대가 좋고, 방통대 졸업을 하지 않아도 수업을 들었다고 증빙만 하면(성적 증명서를 발급할 수 있으면) 검토한다고 한다
- 방통대 컴퓨터 공학 3학년으로 편입했고, 첫 학기는 가볍게 운영체제, 알고리즘, 파이썬만 수강했다. 다시 돌아간다면 이산수학도 들을 것 같다. 오스틴은 이산수학도 요구하고, 조지아텍은 이산수학을 요구하진 않는다.
한학기 등록금은 36만원 정도 되는데, 1학기 들으면서 강의 퀄리티에 감명을 받았다. 특히 운영체제, 알고리즘 교수님들 강의가 좋았다. 핵심적인 내용을 잘 전달해주셔서 강의를 하는 사람 입장에서도 영감을 받았다.
중간고사 쯔음 수업은 오프라인 수업도 있고 온라인 수업도 있는데, 오프라인에 가서 수업을 듣는 경험도 오랜만이라 즐거웠다. 시간표가 맞지 않아서 목동에서 수업을 들은 적도 있고, 뚝섬역에서 들은 적도 있다. 둘 다 상관없이 즐거운 경험이였다
기말고사 볼 때 다양한 분들이 방통대를 수강한다는 것을 깨달았다. 아버지 뻘 나이이신 분들도 수업을 듣고, 할아버지도 계셨는데 나도 나중에 저렇게 배움을 지속해야겠다고 다짐했다
나중에 농사를 하면서 사는 삶도 생각해서 방통대 농학과에 진학하고 싶다는 생각이 들었다. 진짜 할수도..?

GDE 활동

예전부터 Google Cloud Champion Innovator 활동을 하고 있었는데, 3월에 이 프로그램과 GDE(Google Developer Expert)가 통합된다는 메일을 받았다
- GDE는 구글 코리아의 커뮤니티 매니저분이 더 활발하게 소통을 한다는 장점이 있어서, 과거와 달리 더 소속감을 느끼게 되었다. 과거엔 메일만 주고 받아서 덜 소속감을 느꼈다
과거에 GDE를 하고 싶다는 글을 썼던 적이 있는데, 결국에 되는구나..! 계속 무언가를 하다보니 이렇게 되네!라고 생각이 들었다. 바라고자 하는 것을 기록해두고 계속 노력하면 만나는 경우가 있다
3월에 GDE + GDG 모임이 있어서 처음으로 가서 인사를 했고, 오랜만에 뵌 분들도 있었다.
7월에 발표를 제안해주셔서 Google I/O Extended Incheon 2025에서 발표했다. 모교인 인하대에서 10년 전에 강의를 듣던 공간에서 강의를 할 수 있어 영광이였다.
8월에 Google I/O Connect China가 진행되었고, 국내 GDE들이 갈 수 있다고 해서 가겠다고 해서 상해를 처음 다녀왔다
- 그 과정에서 경험한 것들은 GDE로 참여한 Google I/O Connect China 2025에 작성했다
- 상해에서 만난 다양한 사람들을 통해 더 열심히 해야겠다고 다짐했고, 영어로 이야기하면서 영어의 중요성을 더 체감했다
- 또 기억나는 것은 AI쪽 담당하시는 분이 군대 선임의 누나셨던 것. 엄청난 우연이라 그 때 선임 형에게 연락했다
- 8월 기점으로 AI/LLM을 본격적으로 활용하게 되었다
그 후에는 시간이 맞지 않아 발표하진 못했지만, 다음 해엔 좀 더 발표를 해볼 예정이다
Gemini 3.0이 나와서 AI Sprint에도 참여해서 제품들을 많이 써보고 글을 쓰고 있다. 앞으로 AI나 클라우드 내용을 더 자주 써보고 올릴 예정이다. 내가 자주 할 수 있는 것은 글을 쓰는 것!

발표

데이터야놀자 발표
- 6월에 데이터야놀자에서 개발자 글쓰기 커뮤니티 글또의 데이터 수집부터 데이터 활용까지 발표를 진행했다. 단순한 커뮤니티지만 데이터를 회사처럼 수집하고, 그 데이터를 어떻게 활용하는지를 다루었다. 지표 집계, 스프레드시트 기반 시각화, 데이터 파이프라인(BigQuery) 등 데이터 직무에 계신 분들에게 유용한 관점을 제시하고 싶었다. 회사에서 하는 것처럼 파이프라인을 구성했다
- GROUP BY CUBE 함수를 모르는 분들이 많아서 꼭 알려드리고 싶었고, 파이프라인 구성이 어렵지 않다는 것을 공유하고 싶었다. 유튜브에 영상이 있으니 관심이 있으시면 참고하면 좋겠다
- 연차가 있는 분들이 데이터 업계를 위해 계속 발표를 해주면 좋겠다. 이제 나와 비슷하게 공부했던 분들이나 내게 영감을 주신 분들은 잘 보이지 않는다. 여러분들 모두 어디에 계신가요…?
Google I/O Extended Incheon 2025
- 7월에 8년 넘게 개발 블로그를 하면서 깨달은 것들이란 주제로 발표했다. 인프런의 블로그 페이지뷰 300만이 알려주는 “실용주의 기술 블로그 글쓰기” 강의가 있지만, 내용을 똑같이 참고하지 않고 앞선 강의를 들은 분들도 영감을 받을 수 있게 새로운 내용들을 추가했다. 글쓰기 레벨을 확립한 것을 많이 인상 깊게 봐주셨고, 실행을 할 수 있게 도움을 드렸다
- 마지막 장표에 이런 내용이 있었다 : 처음부터 AI한테 글을 쓰라고 하는 것이 아닌(헬스 PT 선생님에게 대신 운동해달라고 하는 느낌) 내가 일단 작성하고, 피드백 받는 방향으로 AI를 활용하는 것을 추천
  - 이 내용은 AI 시대에 어떻게 학습하고, 어떻게 AI를 활용해야 할까에 대한 내 생각이다. AI를 그냥 사용하는 것보다 나의 발전을 위한 교보재로 쓰는 것이 더 좋다고 생각한다
BOAZ 발표
- 11월에 BOAZ에서 발표했다. 내가 참여한 동아리라서 후배분들에게 최대한 영감을 많이 드리고 싶었다. 9년 전의 나는 어떤 사람이였고, 어떤 길을 밟아서 지금의 내가 되었는지 공유했다
- 이 발표의 마지막 부분엔 AI를 어떻게 활용하는 것이 좋을까에 대한 내용을 전개했다. 이 당시에 개발하고 있던 것이 있어서 개발 환경을 그대로 보여줬다. 대학생분들이 자신의 진로에 대해 많이 고민해보고, 일단 많이 시도해보면 좋겠다. 그 과정에서 얻는 것들이 있을테니
ICT 인턴십
- 한국정보산업연합회에서 진행하는 ICT 인턴십에서 커리어 특강을 진행했다. 데이터/AI 직무에 대해 설명했는데, 요즘은 AI에 대해 더 관심을 가지고 있다는 것을 체감했다. 데이터보다 AI라는 단어가 많이 나왔는데, AI가 있기 전에 데이터가 필요하다는 것을 강조했고 어디서든 자신의 자리에서 경험을 늘려보라는 이야기를 전했다
외부에서 진행하는 컨퍼런스 발표는 2회만 진행했는데, 26년에는 조금 더 많이 발표에 도전해야겠다.

AI 엔지니어링 책 번역

칩 후옌님의 AI 엔지니어링 원서를 번역했다. 이 작업은 올해 초부터 시작했는데 9월 말에 책이 출간되었다. 영어 공부를 하는 과정에서 책을 번역하면서 독해 공부도 했고, AI 엔지니어링 분야에 대해 더 깊게 이해할 수 있었다. 전통적인 머신러닝/딥러닝 위주로 일했던 사람이라 언제 AI를 더 공부할지 고민했다. 파운데이션 모델이 나올 시기부터 학습할 내용이 참 많았는데, 이 부분에 대해 해소할 수 있었다
한빛미디어에게 24년 12월부터 연락해서 번역하고 싶다고 이야기했다. 이 책이 너무 좋아서 원서로 먼저 보면서 번역을 준비했다
번역한 내용을 다시 보면서 진짜 많이 읽었다. 10번 넘게 다시 읽으면서 어떻게 해야 더 자연스럽게 표현할 수 있을까? 이해가 잘 안된다면 어떻게 번역해야 할까? 고민했다. 많이 보고, 반복한 결과 좋은 책이 나왔다
감사하게도 교보문고 10월 IT 분야 판매 1위를 기록했고, 25년 12월 29일 기준 3쇄가 인쇄되었다. 많은 분들이 이 책을 통해 AI/LLM의 핵심적인 지식을 잘 이해하면 좋겠다. 시간이 지나도 변하지 않을 핵심적인 부분을 담은 책이다
그리고 AI 엔지니어링을 활용해 인프런 챌린지를 진행했다. 인프런에서 챌린지를 진행한 것은 처음이였는데, 책을 읽으며 드는 생각들을 보면서 어떤 내용을 또 전달하면 좋을지 고민했고, 마지막에 있는 라이브 챌린지에서 내가 AI를 어떻게 활용하고 있는지에 대해 다루었다. 작게라도 AI를 써보면서 효용을 느끼시면 좋겠다
번역 과정에서 이복연님의 이것이 번역이다를 읽고, 번역하는 과정에서 어떻게 해야 더 자연스럽게 표현할 수 있을까?를 생각했다. 직역보다 의역을 선택해서 저자님의 이야기를 독자분들이 더 잘 이해하도록 만드는 것이 역자의 역할이다. 두 집단의 연결 부분이라 이해에 초점을 맞췄다. 직역보다 더 이해가 잘 되도록 풀어서 쓴 부분도 있고, 이해를 위해 각주를 추가했다.

방통대 자퇴

위에서 방통대 진학이 나왔는데 같은 해에 자퇴가 나온다. 이렇게 생각하게 된 과정도 여러가지가 있는데 하나씩 작성하면
- 11월에 스스로에게 질문을 던졌다 : “지금 나는 행복한가? 활력이 넘치게 살고 있는가?” 이 질문에 대한 답은 그런 경우도 있지만 영어 공부를 하는 과정에서 활력은 적은 편이였다. 성적은 나왔지만 대학원에 가더라도 졸업까지 약 3년은 소요될 것 같다
- 이어서 이런 질문을 던졌다 : “3년 후에 어떤 세상이 되어 있을까?” 이 질문에 대해 답은 알 수 없지만, 지금과는 완전히 달라질 수 있다는 것. AI가 더욱 발전할 것이고 그 이후에 교육은 어떻게 되야 할까? 이런 질문으로 이어졌다. 대학에서 진행하는 교육보다 조금 더 변화가 필요하지 않을까? 먼 미래를 생각하는 것보다 지금 할 수 있는 다른 방향으로 고민하는 것이 더 보람찰 것 같다는 생각이 들었다
- 3년 후를 생각해보니 그 때를 생각하는 것보다 현실적인 지금 할 수 있는 것에 집중하는 것이 좋다는 결론에 이르렀다.
위 생각을 하는 과정에서 클로드와 제미나이와 3자 대면으로 4시간 넘게 대화했다. 내 내면을 더 이끌 수 있는 질문을 던지라고 프롬프트를 작성하고 내 생각을 작성하고, 계속 개선했다. 그 결과 보내주기로 결정했다
방통대 기말고사가 12월인데, 방통대를 진학하면 시험 공부를 위해 꽤 많은 시간을 써야 하고 그 시기에 하루 8시간씩 2주 교육이 진행 예정이었다. 그래서 너무 무리하게 하는 것보다 집중할 것에 집중하기로 결정했다
누군가는 그럼 휴학하면 되지 않냐고 물어보겠지만, 그럼 계속 아른거릴 것 같아서 그냥 자퇴로 결정했다. 자퇴 신청하니 빠르게 승인이 되었고, 학기 중에 빠르게 자퇴 신청을 해서 등록금의 40% 정도를 돌려 받았다.
누군가 방통대를 고민한다면 목적에 따라서 추천한다. 강의 퀄리티도 괜찮고 내가 어떤 부분에 부족함이 있었는지 알게 된다. 다만 회사 업무 외에 방통대에 집중할 수 있을 때 하는 것을 추천한다. 욕심은 졸업까지 발목을 잡게 된다.
나중에 다시 기회가 된다면 대학원에 갈 수는 있지만, 당장은 시대가 변하는 것을 지켜보며 지금 할 수 있는 것을 할 것 같다. 만약 회사를 다니고 있었다면 오히려 심플하게 대학원에 진학했을 것 같다. 몇년 후에 어떻게 살고 있는지 살펴봐야지

강의 - 오프라인 교육을 시도했다

2025년에도 인프런에 강의를 내려고 했으나, 상반기는 영어 공부로 삭제가 되고 하반기는 상반기에 못한 일을 진행하느라 하반기에 강의 촬영을 못했다. 그래도 강의 기획이나 자료를 조금씩 만들고 있다. 26년에는 강의를 1-2개 정도 내는 것을 목표로 한다. 강의를 더 빠르게 내기 위해 무엇을 해야할지 고민한다. 단순히 AI에게 프롬프트나 대본 쓰고, 커리큘럼 쓰라고 하면 일반적인 내용이 나온다. 결국 기획은 내가 직접 하는 것이 필요하고 AI가 강의 내용을 자세히 써준다고 해도 자세히 보면 엉성한 부분이 많다. 그래서 AI보다 직접 하는 내용이 많다. 단순 작업이나 다른 방향으로 AI를 더 쓰는 것이 좋지 않을까? 생각하고 있다. 자동화 관점에서는 AI가 좋다고 하지만 AI가 만드는 강의 퀄리티는 성에 차지 않는다. 이것도 내년엔 바뀔 수 있을까? 싶지만 (NotebookLM의 발전을 보면) 그래도 여전히 직접 만들고 싶다
부스트캠프 AI Tech는 여전히 강의를 진행하고 있다. AI 개발 기초, Product Serving, 러닝 마스터 역할. 매 기수마다 계속 내용이 개선되고 있고, 항상 진심을 담아 도와주려고 노력한다. 요즘은 캠퍼분들이 목 상태를 고려해서 천천히 말씀해주셔도 괜찮아요!라는 피드백도 온다. 예전엔 너무 길게 한다는 의견도 있었는데 상반된 의견을 받으니 감사하다. 부스트캠프 AI Tech 수료생분들 모두랑 만나는 날이 있으면 좋겠다
BigQuery(SQL) 오프라인 교육을 꽤 많이 진행했다. 하반기에 총 200시간 강의한 것 같다. 전서연님의 제안으로 하게 되었는데, 온라인 교육과 달리 오프라인 교육에서 수강생분들을 직접 만나는 경험이 좋았다. 어떻게 해야 더 잘 알려줄까? 어떤 부분을 모르는구나 이런 것들을 생생하게 볼 수 있었다
- 그 결과 강의 실력이 더 좋아졌다. 모르는 부분이나 애매한 부분을 직접적으로 알려줄 수 있고, 보조 자료도 많이 만들었다
- 다만 목 상태가 여전히 고민이다. 하루 8시간씩 2주 강의를 하면 목에 무리가 간다. 물론 요즘은 관리하는 방법을 터득해서 심하게 아프진 않지만, 회고를 쓰는 시점에 역류성 후두염에 걸렸다. 목 상태는 괜찮은데 위산이 후두로 역류해서 후두가 상한 상태. 어쩐지 목이 계속 가래가 낀 느낌이 들더라. 장기적으로 더 할 수 있을까?에 대한 생각은 계속 있다. 조만간 오프라인 교육을 그만할 수도 있을 것 같기도 하고.. 아직 결정을 내리진 않았다
- 여름에 한 강의의 수료생분들이 종종 인스타로 연락이 오는데, 그 강의 들을 때 생각이 난다고 힘이 되었다는 이야기를 들으면 뭉클하고 다 잘되면 좋겠다
11월에 방통대 자퇴를 결정하고, 강의도 더 즐겁고 재미있게 하려면 뭘 해야 할까? 생각했다. 그리고 AI 엔지니어링 번역하면서 AI/LLM을 활용해보자! 라는 생각에 수강생 자동 질문 답변 시스템을 만들었다. 교육의 보조 자료인 셈인데, 강의를 듣다가 궁금한 것들이 있으면 질문을 하는 웹페이지다. 프롬프트를 공들여서 했고, Gemini 2.5 Flash Lite를 사용해서 비용이 거의 들지 않는다. 이 제품을 계속 고도화할 예정이다. 요즘은 제품 개발이 재미있고, 동시에 여러가지를 돌린다. Antigravity도 큰 도움을 주고 있다
강의 마지막 시간엔 SQL의 다양한 패턴을 정리한 내용을 공유하며 짧은 편지를 주고 있다. 이 패턴들을 토대로 자신만의 Cheat Sheet를 만들 수 있길

인프런 지식 공유자 모임

글또에서 진행한 강의 만들기 모임에서 강의를 만든 승현님 은찬님이 연말에 진행한 인프런 지식 공유자 모임에 간다고 해서 나도 갔다. 을지로에서 판교까지 가는 길이 너무 멀었지만! 같이 진행한 사람들과 사진을 찍고 싶어서 갔다. 병진님도 같이 하면 좋을텐데 아쉽게 영국에 계셔서 그건 다음으로..!
오랜만에 뵌 인프런 직원분들도 여전히 따뜻했다. 그리고 GDE 동기(?)이신 박해선 님과 이야기를 나누었다. 나중에 또 만나서 담소를 나눠야겠다
지식 공유자 모임에서 올해도 상을 주셨는데 더 열심히 해야지.. 잘 해보자…! 여러분 인프런 많이 이용해주세요

개발

10월 연휴에 비사이드에서 진행하는 SOLO 포텐데이에 참여했다. 1인 개발을 단기간에 경험하도록 하는 프로그램이였는데, 이 기간 내에 프로토타입을 개발했다
영어 일기 첨삭 웹페이지를 개발했는데, 첫 배포는 1시간만에 진행했다. 그리고 계속 써보면서 기능을 추가했다. 이 시기까지 토플을 공부하던 시기라 내 라이팅 실력을 올리기 위한 피드백 서비스를 개발했다. 실제로 주변 지인에게 공유하니 퀄리티가 좋다고 쓰는 분들이 있다. 이걸 토대로 어떻게 해야 내가 더 공부하게 만들 수 있을까?에 대해 계속 시도하고 있다
- 프론트엔드에 대해 자세히 몰라도 AI와 함께 협업하며 혼자 개발을 할 수 있다. 게다가 Firebase Studio를 사용하면 서버 비용 이슈도 크게 줄어든다. 나는 Firebase Studio를 사용해서 개발하고, Firebase로 배포하고 Firestore to BigQuery Extension을 사용해 데이터를 BigQuery로 저장한다. 저장된 데이터는 개인화를 위해 사용된다
AI가 좋더라~라는 말을 듣고 책을 보는 것보다 자신이 사용할 서비스를 만드는 것이 더 재미있고 빠르게 배운다. 도파민이 생겨서 계속 개발하게 된다. Claude Code 토큰이 만료될 때까지 계속 개발하는 내 모습을 보면서 아 이거 중독되네… 싶었다. 실제로 주변에 클로드 코드 맥스 쓰는 분들은 엄청나게 많은 개발을 시도하고 있다
이런 경험들을 하면서 미래의 개발 형태는 바뀔 수 있겠다고 생각했고, 아키텍처를 잘 설계하는 것과 의사결정을 잘하는 것이 더 중요해지는 시기가 다가온다고 느꼈다. 아키텍처 설계에 대한 내용도 공부도 하고 계속 시도도 하면서 실력이 올라가고 있다
아래 이미지는 개발한 영어 일기 첨삭 웹. 매일 쓰고 있다. 피드백도 잘 해주고, 영어 단어도 추천해준다. 이걸 토대로 개인화까지 거의 완성했다. 나중에 사람들에게 공유해야지

여행

상반기에는 아무것도 안하고, 하반기에 여행을 다녀왔다. 상해(구글 행사 겸), 호주(멜버른, 시드니), 치앙마이, 그리고 국내는 글또 10기 운영진 MT를 2박 3일간 강릉으로 다녀오고, 쏘카 데이터 본부 사람들과 정선에 있는 강원랜드에 다녀왔다

상해

Google I/O Connect China에 참여하기 위해 상해에 방문했다. 행사 4일 전에 출국해서 먼저 상해 여행을 했다. 처음엔 혼자 다닐까 고민하다가 숙소를 찾아보니 다 더블 베드라서 친동생에게 물어봤다. 동생이랑 나이 차이가 6살이 나는데 여태 같이 여행을 간 적이 없다. 그래서 이번 기회에 같이 여행을 다녀오면 좋을 것 같아서 동생에게 일정 가능한지 물어봤다. 이 때 동생에게 “비행기만 너가 알아서 하고 나머진 내가 다 냄”이라고 말해서 동생이 바로 ㄱㄱ!!!라고 외쳤다
동생은 해외 여행을 많이 안해봐서, 이번 기회에 같이 데려가서 경험을 시켜주고 싶었다. 나도 상해는 처음이지만 동생도 처음이였다. 사실 동생과 첫 여행이 상해라는 점이 기쁘다. 6살 차이가 어릴 땐 컸는데 이젠 다 비슷하다. 동생이나 나나 의견이 강한 편이 아니라 그냥 내가 일정 후루룩 짜고 제시하고 수정할 부분이 있으면 수정해서 여행을 즐겼다
밀크티는 진짜 많이 먹었고, 우전 수향마을도 참 이뻤고, 헌지우이치엔 양꼬치도 맛있었다. 양꼬치 먹으면서 진지한 대화도 하고 동생을 더 잘 이해할 수 있고 그래도 힘든 일이 있어도 잘~ 살자!라는 이야기를 많이 했다
그리고 내년에도 같이 일본 여행을 가기로 했다
상해가 인상 깊은 도시인 점은 전기차가 참 많다. 이게 왜 많은지 AI랑 대화해보니 상하이선 차량을 구매하고 번호판도 구매해야 하는데 번호판의 가격이 1,000 만원이 넘는다. 다만 전기차를 구매하면 번호판이 더 수월해지고, 취득세도 할인해준다. 기타 혜택이 많아서 전기차를 안탈 이유가 없다고 한다. 그리고 인프라도 잘 깔려있어서 어디서나 쉽게 충전을 할 수 있다. 이런 정책을 탑다운으로 시행하는 과정이 신기했다.
그리고 알리페이 앱 하나로 대부분의 서비스를 이용할 수 있다. 중국에 가면 알리페이, 위챗, 고덕 지도 정도만 있으면 충분하다. 앱 안에 앱이 또 있는 형태인데 이게 가능한가? 싶었는데 중국이라서 가능했다. 한국은 개인 정보의 이슈로 불가능하다.
- 그리고 중국의 디디추싱 서비스도 타봤는데, 디디추싱 앱을 보면 타다 시절에 일했던 시기가 떠올랐다. 리텐션을 늘리기 위해 쿠폰 제도도 있고, 앱 내에서 광고도 노출하고, 탑승 장소에 대해 자세한 지침을 주는 등 과거에 타다에서 시도하려고 했던 것들이 구현되어 있어서 신기했다. 그 당시에 같이 일하던 동료들에게 이 사실을 알리기도 했다.
운이 좋다면 돌아다니는 로봇도 볼 수 있다. 정말 내가 생각한 중국과 다르구나를 느꼈다
도시도 이쁘고, 물가도 저렴해서 주변에 여행지 고민할 때 상해를 추천한다. 다만 8월엔 기온이 최대 38~39까지 올라가서 추천하진 않는다
상하이 여행 정보가 필요하면 상하이 여행 정보 링크를 참고하면 된다. 중국어 단어와 헌지우이치엔 줄 서는 방법에 대해 작성했다

멜번

상해에 귀국하고 3일 뒤에 호주 여행을 떠났다. 애드파워 동기였던 로운이와 떠나는 여행이였는데, 재미있었다. 둘이 여행한 것은 처음인데 잘 조율하며 다녔다. 멜번이 특히 좋았던 이유는 대자연을 볼 수 있었고, 동물을 볼 수 있었기 때문이다. 애드파워 동기였던 아미와 연락해서 오랜만에 만났는데 시간이 흘러도 여전히 잘 지내고 있다는 점이 좋았다
- 현지인분이 멜버른이 아니라 멜번이라고 발음해야 한다고 해서 멜번이라고 발음하고 있다
멜번 대학교에 갔을 때 석사 진학 뽐뿌가 왔었다… 진짜… 오프라인으로 갈까? 멜번 대학교에 로보틱스 관련 연구실을 밖에서도 볼 수 있었는데 연구에 몰두하는 대학원생분들을 보며 공부에 대한 의지가 올라갔다
멜번 공항에서 UberX를 타려고 하는데, 다른 지역의 우버와 다르게 차량이 오면 순서대로 탑승하고, 우리의 Pin 번호를 주면 된다. 놀이기구 타는 느낌인데 어떻게 보면 이게 더 효율적일 것 같았다. 호출 후 차가 오는 것을 기다리는 것이 아니라 차가 오고 고객의 탑승 정보를 제공하는 것이라 UX가 완전 반대라고 느꼈다. 그렇지만 이게 효율적일 수도 있지
- 이런 현상의 이유도 찾아보니까 호주 공항들은 택시/라이드쉐어 업체에 엄격한 규정을 적용해서 PIN 시스템을 사용한다. 그리고 공항 피업존에 우버 차량이 몰려서 잘못된 차에 타는 거을 방지하려고 했다고 한다. 그리고 공항에서 가짜 우버 기사가 승객을 가로치는 일이 있어서 이런 PIN 인증 시스템을 사용한다
- 찾아보니 미국에서 특정 혼잡 지역, 영국, 유럽 일부, 인도에서도 이런 방식을 적용한다. 국가마다 규제나 시스템이 다르니까 다르게 쓰는구나를 깨닫게 된 사건
동물원에서 쿼카, 캥거루를 봤느데 캥거루를 보니까 엄마는 참 위대하다고 느꼈다. 다 큰 캥거루를 안고 가는데 그런 모습을 보며 부모님을 떠올렸다. 어릴 땐 느끼지 못했는데 나이가 들며 부모님에게 감사함이 커진다
멜번에만 있는 피콜리나 젤라또 맛집이 진짜 기가 막힌다. 다시 가고 싶다..
그리고 빅토리아 주립 도서관은 너무 이뻤다. 여기서 공부하고 싶었는데 시간이 없어서 못했다. ㅋㅋㅋ 나중에 간다면 여기서 공부를 해봐야지!!! 그리고 퍼핑빌리 기차도 너무 재밌었다. 또 쿼카가 너무 귀엽다.. 쿼카 최고

시드니

시드니는 2회차라서 거의 가이드처럼 다녔다. 과거에 가지 못했던 바다도 가고, 시드니에서 요리 공부했던 NFNG 사장님인 재권이형이 추천해준 가게를 가는 재미도 있었다.
저녁에 하버브릿지에서 오페라 하우스쪽으로 걸어오는 것도 기억에 남는다. 참 아름다운 도시다.
시드니 2회차여도 여전히 안해본 것들이 많아서 안해본 것들을 해봤다. 페리 타보기, 돌고래 투어 등
호주에서 지오펜싱 기술을 모빌리티 서비스에 적극적으로 도입하는 것을 알 수 있었다. 버스 내릴 때 카드를 찍어야 하는데, 미리 찍으면 아직 지오펜스 내가 아니라서 찍히지 않았다. 그냥 지나칠 수 있는 일이지만 이젠 왜 이게 생겼지?를 생각하는 습관이 생겼다. 이런 습관이 생기니 여행도 더 즐겁게 다닐 수 있다
- 삼성페이로 버스를 탈 수 있다는 것도 신기했다. 삼성페이 어디까지 발전하나요? 너무 감사합니다 삼성..
맨리비치에서 아버지와 자식이 같이 운동하는 것을 봤는데, 참 보기 좋았다. 아버지와 어떤 것을 같이 해볼까 고민했다
레밍턴 케이크 맛집을 귀국하는 날에 찾았다. 아… 거기를 첫 날부터 갔어야 했는데!! 진짜 다시 가면 레밍턴 케이크 매일 1개씩 먹을 것이다. Flour and Stone이란 곳이다
시드니 여행지 모음에 시드니 여행에 대한 가이드를 정리했다. 주변에 시드니 간다는 사람에게 공유하고 있다

치앙마이

귀국하고 쏘카에서 만난 그랩과 치앙마이에 가게 되었다. 정말 갑자기 가게 되었는데, 치앙마이 비행기가 35만원이라 갑자기 가게 되었다
치앙마이에서 스쿠터를 타고 다니면 정말 이동이 편하구나를 느꼈고, 덕분에 치앙마이에서 여러 동네를 다닐 수 있었다. 둘 다 치앙마이 1회차가 아니라 관광보다는 진짜 일에 집중했다. 그 와중에 수영도 하고 헬스장도 가고 건강하게 보냈다
목표를 명확하게 잡으니 집중할 수 있었고, 생각해보니 그랩이랑 예전에 맹그로브 고성도 같이 갔었는데 두번째였다. 그랩과 상황도 비슷해서 여러 이야기를 하면서 집중할 수 있었던 시간이였다
치앙마이 기억을 떠올리면 이 헬스장이 떠오른다.. 정말 강렬했다… 다들 엄청난 몸을 가지고 계셨다.

글또 운영진 MT

글또 10기를 끝냈고, 잘 마무리를 했다. 아쉬워하는 분들도 있지만 장기적으로 운영을 하려면 여러 요소가 선행되어야 하고, 그걸 하고 싶은지 생각해보면 아직은 그렇지 않아서 중단하기로 결정했다
- 커뮤니티를 운영하며 든 생각들은 글또 1~10기. 7년의 커뮤니티 운영 회고에 기록했다
글또 10기를 마치고 3달 후, 운영진 MT를 강릉으로 갔다(2박 3일). 정말 좋은 숙소를 가겠다고 다짐해서 정말 좋은 곳을 찾아왔다. 어떤 분들은 여기 연애 프로그램 촬영장 아니냐고 말했지만 아무 일도 일어나지 않았다
내가 좋아하는 음식들을 먹이고, 가리비도 먹이고, 잘 먹을 수 있도록 여러 요리도 했다
2일차에 모두 사진 찍으러 가는 길에 비가 너무 많이 왔다ㅎ.. 돌아보면 추억이긴 하지만, 그 때 비가 많이 와서 너무 미안하긴 했다
그래도 잘 놀고, 잘 쉬었다
운영진분들을 위해 내가 선물 키트도 만들었다. 메타몽 마카다미아 쿠키도 구웠다
내가 참 좋아한 강릉. 안목해변 근처에서 삼교리 동치미 막국수 먹고 젤라또 먹는 루트를 운영진분들에게 공유했다. 다들 좋아해서 뿌듯했다

정선 카지노

정선 카지노는 다들 가보자고 해서 갔는데, 카지노 입장을 위해 사전 신청을 하고 추첨을 통해 결과를 알려준다
근데 가려고 하는 사람들 모두 다 합격했다고 하는데 나만 불합격이였다 ㅋㅋㅋ 그 때부터 벌써 가챠가 시작되었다
사람들이 전날 저녁에 가면 들어갈 수 있을지도 모르니 가보자!해서 갔고, 들어갈 수 있었다
처음엔 너무 어렵고 무서워서 초심자들끼리 다녔는데, 카지노에 뉴비존(일명 온보딩 지역)이 있다. 거기서 간단히 수업을 듣고 어떻게 해야 하는지 감을 익히고 시도했다
같이 간 형이 돈을 버는 것을 보고 나도 시도했는데, 난 탕진했다ㅋㅎ 데이터 기반 의사결정 그런거 안통한다. 그냥 한다… 하다가 앞으로 해도 각이 안나오겠는데 싶어서 4만원만 썼다. 체험 비용으로 10만원 생각했는데 그 전에 잘 멈췄다. 빠른 의사결정..!
카지노에서 사람들이 더 게임을 하도록 어떤 장치가 있는지 살펴보고, 사람들의 표정도 살펴봤다. 오 이런 곳이구나.. 참 신기한 곳이네.. 생각하면서도 제품에서 이걸 적용하려면 어떻게 하려나? 생각했다.
정선이 참 멀지만 날씨가 좋아서 소풍 가는 기분이였다. 이 모임이 예전에 쏘카에서 바람의 나라 모바일 나와서 같이 하던 사람들인데 이제 게임은 하나도 안하고 가끔씩 만나는 모임이 되었다

요즘 생각들

나만의 동기를 얻는 방법 : 콘서트

올해는 어쩌다 보니 콘서트를 많이 다녔는데, 콘서트에서 엄청난 영감을 얻는다
올해는 스텔라장, 유다빈밴드, JYP, 로이킴 콘서트, 아이유 팬밋업에 다녀왔다. 모든 공연들이 다 좋았고, 각자의 깨달음이 있었다. 그렇지만 제일 인상 깊었던 것은 JYP(박진영님) 콘서트
- 권진아 님이 공연을 시작해주는데, 권진아 님의 노래를 직접 들으니까 더 빠져들게 되었다
- 심사위원이였던 박진영 님과 참여자였던 권진아 님의 장면을 보니, 나도 나중에 강의 수강생분들과 같이 일할 수 있을까?를 생각해보게 되었다. 시간이 흘러 서로를 리스펙할 수 있게 된 관계가 된 것. 너무 멋졌다
- 공연 중간에 박진영 님이 음이란 무엇일까?에 대한 이야기를 해주셨는데 자신만의 철학이 너무 좋았다. 음이란 무엇일까? 음악이란 무엇일까? 로 시작하는데 음이 길을 걸을 때 음악이 된다
- 내가 왜 콘서트를 좋아하나 생각해보니까, 콘서트는 단순히 노래만 부르는 곳이 아니고 어떤 컨셉을 가질지 고민하면서 스토리텔링을 한다. 이 노래를 왜 이 타이밍에 배치했고, 요즘 느끼는 것을 공유한다. 행사 기획이랑 같은 맥락인데, 개인의 생각이 많이 담겼다
- 자신에게 도움을 준 외삼촌, 외숙모, 엄마, 작곡가 형이 공연에 왔다고 언급하는 것도 보기 좋았다. 사람은 혼자 발전하는 것이 아니고 모두 도우며 산다
- 사람들에게 모두 일어나서 즐겨요!라고 하셨는데 재밌었다. 부모님 나이이신 분들도 많이 왔는데, 나중에 콘서트에 부모님도 같이 와도 좋을 것 같다고 생각했다
- 2시간 50분 정도를 쉼 없이 계속 달리셨다. 어떻게 저렇게 달리시지? 6년 후 환갑이신데 체력이 대박이다.. 나도 저 나이에 저럴 수 있을까? 생각하면 지금부터 열심히 운동해야겠다
- 한 회사의 경영자(물론 정확히는 CEO는 아니고 CCO)가 열심히 본업을 하는 것도 대단했다. 보통 저 자리에 있으면 안하는 경우도 있던데
- 같이 나이가 들었지만, 여전히 현역처럼 공연을 하는 것이 동시대의 사람들에게 감동일 것 같다. 내가 90년생 연예인분들에게 느끼는 감정과 동일하지 않을까?
- 관객들의 함성을 듣고 싶어서 인이어를 계속 안끼고 노래를 했다. 이게 참 대단한 포인트. 노래가 밀리는 느낌도 없었다
- 환갑 때 자신의 인생에서 끝내주는 콘서트를 할 예정이라고, 6년 남았다고. 갑자기 나도 환갑에 어떤 일을 하고 있을지 생각해보게 되었다. 다른 사람의 질문은 내게 영감을 준다
- 콘서트가 이렇게 흥이 날 수 있구나!를 깨닫게 해준 콘서트. 계속 신났다. 이런 에너지를 준다는 것이 정말 좋다
- 박진영 님이 정말 명곡을 많이 냈다는 것을 깨달았다. 소재가 많으면, 할 수 있는 이야기도 다양하다는 것을 깨달았다. GOD, 원더걸스 등
- 결국 끝까지 살아남은 사람이 이기는 것. 한때는 최고가 되고 싶었던 적도 있지만 이제는 최고보다는 끝까지 가고 싶다고 말하신다. 나는 어떤 끝을 향해 가고 있는가?
- 50살이나 60살이나 늦지 않았다. 지금부터 시작하면 된다. 어르신들이 자주 말하는 말이 이 나이에 뭐~라고 하는데 그냥 해보는 것. 그게 참 중요하고 나이가 들어도 동일하다
- 박진영 님의 콘서트를 나중에 또 가고 싶다는 생각이 들었고, 이런 경험을 할 수 있어서 감사했다
- 박진영 님의 루틴을 따라하려고 아침마다 올리브 오일을 시도하고 있는데 아직 적응은 안된다….. 내 올리브 오일이 맛이 없는건가?
앞으로도 주기적으로 영감을 받기 위해 여러 콘서트를 가야겠다. 일단 2월에 10CM 콘서트도 신청했다

AI에 대한 생각

2025년의 AI는 정말 빠르게 발전했다. 그와 동시에 우리의 삶이 윤택해지기도 하지만, 불안함을 가지고 오기도 한다. 이제 앞으로 어떻게 살아야 할까?라는 질문이 컨퍼런스에서 종종 나온다
- 근데 나는 여전히 크게 걱정하진 않는다. 여전히 개발자 필요하고, 데이터 과학자/분석가 필요하다. 미래를 걱정할 수는 있지만 산업 혁명 때의 이야기를 찾아보면 직업 형태의 변화가 있었고, 대규모가 영구적인 실업난을 겪은 기록은 찾기 어렵다.
- 그래서 너무 고민하지 말고 AI가 나오면 써보고, 내가 겪는 문제를 고민하고 그러면 되지 않을까
- 요즘 같은 시기에 여전히 본질이 중요하다. 본질을 잘 이해하는 상태로 AI 적용하고 그러면서 계속 더 시도하는 것. 그게 진리가 아닐까?
- 기술은 계속 바뀐다. 내년엔 또 새로운 것들이 우수수수 나올 것이다
- 더 나아가서 누구에게나 도구가 있기 때문에 생각하는 힘, 호기심이 더욱 중요한 가치가 될 것 같다
그래서 나는 너무 걱정하지 않고 지금 할 수 있는 일들을 하는 편이다
11월에 방통대를 자퇴하고 어떻게 해야 더 재밌게, 즐겁게 일을 할 수 있지? 그리고 어떻게 해야 더 잘할 수 있지? 강의도 어떻게 더 하지? 이런 고민을 하며 필요한 제품을 만들었다
- 그 결과 만든 것이 수강생들을 위한 QnA 시스템. 사람들이 꽤 많이 쓰고, 프롬프트도 잘 작성해서 자세한 답변을 하고 있다
AI 개발하며 떠오른 것들
1. 기획을 구체화하는 것이 중요하지만, 제품을 만들기로 다짐했다면 최대한 빨리 배포하기. 나는 시작하고 1-2일차부터 제일 작은 버전 배포하고 계속 쓰면서 수정했음
2. 처음에 기획, 목표, 와이어프레임, PRD가 있으면 좋다. 근데 작게 시작한다면 없어도 무방한 것 같다. 물론 있으면 더 잘 정돈되는 느낌이 있음. 이 부분은 PM/기획자분들이 잘 진행할 것 같음
3. Speckit을 활용해서 스펙을 명확히 정의했다. Speckit에서 권장하는 흐름(specify -> clarify -> plan -> tasks -> implement)이 있는데, 작은 스펙이라고 생각하면 이 중간 단계를 건너뛰어도 무방하다. 이건 어떻게 보면 사람이 문서를 잘 작성해야 할 일을 AI에게 위임한 것으로 봐도 좋을 것 같다
4. 배포를 어디에 할 것인가 생각을 해보면 좋다. 나는 Firebase Studio를 활용해서 진행했는데, Firebase와 통합이 잘 되어서 바로 배포를 진행했다. IDE 에서 미리보기를 할 수 있는 URL을 주는데 그건 마치 Dev 겸 내 Local처럼 사용했고, 배포하곤 Prod 환경이라 생각했다. Firebase를 안 쓰면 Vercel + Supabase 조합이 무난하다
5. 제품을 만든다고 하면, 오류 메시지를 잘 추적해야 한다. 개인이 시작한다면 Sentry 추천한다. 월에 오류 5000개까지 무료인데, 월에 이 정도 오류가 나는 트래픽이라면 오히려 행복해야 할 것 같다
6. 그와 동시에 사용자 유저 로그도 수집하면 좋다. Google Analytics 4가 무난하다. 일단 추가하고 이벤트를 심자. 그리고 데이터를 BigQuery로 Export해두자
7. Claude Code, Gemini CLI 모두 수준급이다. 선택의 문제거나 컨텍스트가 많이 필요하거나 스킬이 필요할 때 선택하면 되는 것 같다
8. GitHub에 브랜치를 따고 PR하는 과정에 AI를 도입해도 좋다. 코드 리뷰를 해주는 AI 활용했는데 코드 정리하기 수월했다.
9. 디자인은 디자인 시스템을 차용해서 디자인 시스템 관련 마크다운을 만들어서 참고하라고 하면 좋은 것 같다. 특정 상황에 어떤 것을 쓰라고 지침을 남겨두면 된다. 이건 회사에서도 공통적으로 참고하고 있을듯
10. 데이터를 잘 관리하면 좋다. 어떤 질문이 들어오고 어떤 output이 나왔는가? 이건 LLMOps쪽에선 랭스미스 같은 제품을 쓰면 된다. 구글의 GenKit은 이런 것이 없어서 그냥 데이터를 BigQuery에 저장해서 확인해야 할 것 같다. 혹은 데이터 포맷만 맞추면 다른 프레임워크에서 쓸 수 있다.
11. 어뷰징을 방지하기 위해 프롬프트에 무제한 Input을 허용하지 말고, 제한을 두자. 실제로 지인이 바로 10000자 테스트를 하려고 했음(일기 아닌데 그냥 텍스트 뭉치 붙임^^..)
12. Gemini API가 굉장히 저렴하다. 일단 Gemini로 시도해보고 원하는 답변이 안나오면 모델을 고민해도 좋을 것 같다. Gemini Flash Lite도 내 작업에선 성능이 좋았음.
13. claude.md 에서 작업이 끝날 때 항상 WORK_LOG.md 작성하라고 해서 작업일지를 작성했다. 이렇게 보니까 지금까지 뭘 했는지 알 수 있다
14. 더 나아가서 MCP 붙여서 지라나 컨플루언스에 티켓 바로 만들게 할 수도 있을 것 같다. 지라/컨플을 쓰진 않아서 안했지만 노션 칸반에 추가하는 것 가능할 것 같다. 회사에서 일하는 것과 비슷하게 해야지.
15. 배포했다고 끝이 아니다. 좀 더 해야 한다. 사이드 프로젝트를 단순 배포만 하고 끝내는 경우가 많은데, 계속 해야 한다.
16. 생각보다 한번 하면 큰 그림을 빠르게 깨닫는다. 한번 하는 것이 어렵지, 해보면 계속 하게 된다. 이런 것도 챌린지처럼 도와주면서 참여자가 할 수 있게 만드는 프로그램을 만들 수 있을 것 같다.
AI를 활용하며 개발할 때 고민해야 하는 부분
1. 어느 수준까지 AI에게 위임할 것인가?
2. 코드를 모두 다 이해할 것인가? 혹은 큰 아키텍처만 이해할 것인가?
3. 문제를 디버깅할 때 얼마나 시간을 투자할 것인가?
4. 필수 문서를 어떻게 작성할 것인가?
5. 버전 관리를 어떻게 할 것인가?
6. 로그를 어떻게 저장할 것인가?
7. 오류를 어떻게 대응할 것인가?
8. AI 비용을 어떻게 컨트롤할 것인가?
9. AI가 개발을 할 때 무엇을 해야 할까? (기획 다듬기, 다른 작업하기, 독서하기 등)
왠만한 작업은 AI와 잘 진행할 수 있어서 이제 아이디어를 잘 생각하고, 실행하는 것. 이 두가지의 가치가 중요해질 것 같다.
AI에 대한 지식은 AI 엔지니어링 번역하며 많이 배웠다. 칩 후옌 선생님이 필요한 핵심을 정말 잘 정리해주셨다
AI 엔지니어에 대한 정의는 변하고 있다
- (1) AI 모델을 직접 만드는 엔지니어
- (2) AI API를 사용해서 제품을 만드는 엔지니어
- 지금은 둘 다 AI 엔지니어라고 부르는 것 같은데, 전자의 사람들이 점점 직접 모델을 만들지 않고 후자의 길로 가는 경우도 있는 것 같다. 이런 흐름에 따라 AI 엔지니어의 역할도 점점 애매해지고 있는걸까? 백엔드 개발자가 하는 것이 더 좋을 경우도 있다
  - 그러나 전통적인 머신러닝의 방법을 차용해서 AI 엔지니어링에 적용할 부분이 분명 있다. 꽤 효과가 있는데, 아직 연결이 되어있지 않은 것 같다
직접 모델을 만들고 서빙하는 사람이 필요하기에 이 분야에 대해 계속 갈고 닦으면 길이 있을 것이다. 이쪽 라이브러리는 정말 많이 나오고 사라지고 있다

놓아주는 것의 중요성

올해는 방통대 편입 ~ 자퇴가 공존하는데, 이 결정을 한 후에 든 생각은 “놓아주는 것이 중요하다”였다. 종종 가지고 있는 것들에 계속 새로운 것을 추가하느라 힘들어하고, 번아웃을 겪는 사람들을 본다. 놓아주는 것이 쉽지 않다고 말하는데, 쉽지 않을 수 있지만 그렇기 때문에 놓는 것이 더 필요하지 않을까?
모든 것을 가질 수 없다. 적절히 선택을 해야 하고, 매몰 비용이 있더라도 그냥 놓는 것이 앞으로 다가올 시간을 생각했을 때 더 좋을 수 있다. 놓지 못하는 것도 습관이 되어있을 수 있는데, 놓는 것도 습관처럼 연습을 해야하는 것 같다
대학원을 가지 않겠다고 결정하니 오히려 후련했다. 생각해보면 난 학부 졸업하고 일을 했던 사람으로 계속 그렇게 살려고 했다. 무림에서 정파와 사파가 있으면 나는 정파는 아닐 것 같고, 사파에 가깝지 않을까? 라는 생각이 들었다. 사파인데 정파처럼 하려다가 아 이거 내 길이 아니네 깨닫고 사파로 계속 가는 그런 사람이 나의 모습인 것 같다. 그래도 영어 공부를 하면서 활력을 얻었고, 평온한 호수에 돌을 던져서 움직일 수 있는 동력을 얻었다! 너무 만족스럽다. 이런 방황이 오히려 더 나은 길로 가고 있는 것이라 믿음
요즘은 잘 놓았더니 너무 행복하고, 하루 하루 즐겁다. 에너지가 넘쳐서 무엇이든 할 수 있을 것 같다(토플 빼고)
- 그냥 내 자리에서 할 수 있는 최선을 다 해보자. 강의도 하고, 요즘은 중고등학교까지 확장하고 싶다는 생각도 들고, 뭐든 많이 해보자는 생각을 하고 있다
- 회사 경험도 소중해서 좋은 제안이 온다면 그리고 나의 마음이 움직인다면 할 수도 있다고 생각한다

요즘에 중요한 가치는 무엇일까

요즘 행복하고 싶다, 행복의 중요성에 대해 이야기를 잘 안한다. 왜 그럴까 생각해보니
- 불행함이 있을 때 행복을 추구하는 것 같고, 나는 평온한 상태에 있기 때문에 행복!!을 외치지 않는 것 같다. 고요함을 유지하고 있는 시기랄까
- 그래서 인생이 설레고 내일 일어날 때 또 뭘 해볼까! 이런 생각이 든다.
- 이런 생각을 원래부터 하던 사람은 아니였고, 의도적으로 긍정적인 생각을 한다. 떠오르지 않으면 의도적으로 내가 기대되는 사건들을 만든다. 예를 들어 새로 생긴 잠실 메타몽 팝업을 간다거나, 해보지 않은 경험을 시도한다거나 등
요즘 AI의 발전 이후로 커리어에서 더 불안함이 많아지고 있는 것 같다. 어디든 가면 AI가 우리를 대체할까? 라는 질문을 하는 분들이 있고 자신이 가지지 못한 것에 대해 고민하는 분들이 예전보다 더 보이는 것 같다
- 불안한 부분에 포커스를 맞춰서 생각하면 계속 불안해진다. 그거만 생각하니까. 그래서 나는 불안한 것보다 긍정적인 것이나 더 좋은 부분만 많이 보려고 한다(낙관적 사고)
- 내 마음 먹기에 따라서 세상을 낙관적으로 바라볼 수도 있고, 비관적으로 바라볼 수 있다. 나는 낙관적 사고를 의식하지 않아도 생각하고 있고, 그러면서 사람에 대한 연민도 많이 느낀다. 다들 조금 더 잘되면 좋겠는데..!
다른 관점으로 생각하면 내가 하고 싶은 것이 무엇인지 몰라서 걱정이 있는 경우도 있는 것 같다
- 하고 싶은 것이 없으니 뭘 해야할지 모르겠고, 그러다가 걱정으로 되는 것. 그리고 답이 나오지 않는 어려운 문제일 것 같다
- 흑백 요리사 시즌 2를 보면서 좋아하는 것을 하는 사람들의 얼굴은 저런 모습이구나, 불안감보다 잘하는 것에 집중하는 모습을 보며 왜 흑백 요리사에 열광을 하게 되는지 느끼고 있다
  - 어떤 참여자는 기존에 하던 것을 멈추고 새로운 방식으로 도전하는 사람도 있다. 우리의 삶도 비슷하지 않을까.
- 혹은 용기가 아직 없어서 머뭇거릴 수도 있을 것 같고, 작은 성취를 만들어서 계속 더 굴려야 하는 것 같다
낙관적으로 세상을 바라보면서 안정적인 환경을 만들었다면, 어느 시기가 지난 후 또 의도적으로 나가는 것이 좋지 않나?라는 생각이 든다
- 안정적인 상태도 계속 있으면 고여버린다. 조금씩 새로운 경험을 얻어서 새롭게 발전하는 모습이 필요한 것 같다
- 나도 올해 영어 공부를 했던 것이 안정적인 환경이고 굳이인 것을 시도해서 새로운 경험과 생각을 얻었다. 뭐라도 해야 뭐라도 얻을 수 있다. 집에만 있는 것이 아니라!
- 어떤 시기엔 유지도 중요하고, 어떤 시기엔 시도가 중요하고 시기에 따라 계속 변한다. 발산하고 수렴하고 발산/수렴 프레임워크로 생각하며 산다
- 일단 작게 시도하고, 결과를 보고, 그리고 또 시도해보고, 안되면 또 다른 결정해서 또 새로운 길로 가고, 되면 그 길 더 가보고 이게 인생의 큰 진리 중 하나인 것 같다
또 중요한 것은 유연하게 변하는 능력(메타몽처럼), 실행력, 저항감 이기기
- 빠르게 발전할 때 중요한 것은 기본기라고 생각하고 기본기가 있을 때 유연하게 환경에 변화하면서 발전하면 된다. 너무 갑자기 변화하지 않아도 괜찮고 상황에 맞게 적절한 변화가 필요하다
- 그 변화를 하는 과정에 실행력이 필요하고, 하기 싫다는 저항감을 이기는 것도 필요하다
의사결정을 할 때 너무 현실적인 생각을 하는 것보다, 때로는 그냥 하고 싶은 방향으로 하고 의미는 몇년 후에 시간이 지난 후 생각해봐도 괜찮다. 의미를 나중에 아는 경우도 있다

1인 사업자 4년차

퇴사한지 벌써 4년이 지났다. 오랜만에 만나는 사람들과 이야기를 나누면 벌써 시간이 그렇게 되었냐고 말한다. 생각해보면 4년이 진짜 빠르게 지나갔다. 할 일들을 계속 처리했는데, 아직도 할 일이 많다
4년 정도 지나니까 이제 어떻게 하면 더 좋을지가 보이는데 이런 내용들에 관심을 가지는 분들이 있다면 내 경험담을 자세히 다루는 시간을 만들어도 좋을 것 같다
그냥 퇴사하고 1인 사업자를 하겠다고 하는 분들에겐 덜 추천을 드리고, 미리 준비를 하고 나오라고 권한다. 그리고 세법을 잘 파악해보라고 권한다…
연차로는 이제 내년이면 내가 10년차라고 한다. 와 진짜 시간이 왜 이렇게 빠른가? 정신을 차리니 이렇게 되어 있다. 1년차가 볼 때는 10년차가 대단해 보일 수 있지만, 내가? 10년차? ㅎ??? 이런 생각이 들기도 한다. 예전에 내가 바라본 10년차 분들도 그랬을까
- 할 수 있는 것들이 여전히 많으니 즐겁게 하자~

올해의 장소 : 광진 정보 도서관

토플 공부를 하거나 업무를 할 때 자주 방문한 도서관
한강뷰 자리에 가려면 8시 20분에 도착해야 해서, 진짜 부지런하게 다녔다. 8시 20분에 입실해서 퇴실 시간인 22시까지 있었던 날도 많다
다들 열심히 공부하시니 나도 집중해야지! 이런 생각이 들고, 시간이 진짜 빨리 가는 공간이라 마치 정신과 시간의 방 같았다
멀진 않은데 집에서 버스 타고 20분 거리라서 오랜 시간 있을 때 간다. 강이 바로 옆에 있어서 산책하기도 좋고, 평일 점심엔 뷔페가 근처에 있어서 점심 걱정도 적다
나만의 집중 공간을 만들어서 집중이 필요하면 그 공간에 가면 좋다. 습관 형성 관점에서 새로운 공간에서 새로운 습관을 만들기 수월하다.

올해의 물건 : 로봇 청소기

진짜 편하다. 왜 이제 알았을까?
로봇 청소기를 쓰면서 아 로보틱스 공부를 하고 싶다!! 이런 생각이 들었다. 올해 계획 중 하나였는데 토플하느라 미뤄졌는데 이제 다시 슬슬 올려볼까?
상해 갔을 때도 로봇이 보여서 너무 신기했다. 로보틱스 관련 일을 할 수 있다면 가슴이 뛸 것 같다.
글또 10기 운영진분들 모두 감사합니다..

올해의 책 : 다정함이 인격이다

심리 관련 책 중에 가장 인상 깊고, 도움이 되는 책이다. 도서관에서 구매하고 다시 구매했다. 그만큼 다시 보면 좋을 책이고, 많은 사람들이 읽고 힘을 얻으면 좋겠다
자세한 내용은 인스타그램에 작성했다

간단한 다짐

사실 내년에 뭘 이루고 싶다라는 것이 떠오르진 않는다. 오늘을 잘 살아보자!라는 생각만 가득하다
내년에 강의를 최소 하나는 내고 싶고, 그동안 미뤄둔 책 집필을 이젠 하고 싶다. 예전부터 이야기를 해둔 출판사가 있어서 초고를 쓰고 고민해야겠다
여러 경험을 하고, 그걸 또 수렴하고 나중에 후회하지 않도록 즐겁게 여러 활동을 해야겠다. 최근 안했던 독서 모임도 참여해보거나 내가 열거나!
작년 회고에 과거에 했던 것 다시 해본다면? 많이 시도하기, 데일리 다이어리 작성하기, 도전해보기, 초심 잃지 않기, 사람 소중히 여기기는 거의 다 생각하며 살았던 것 같다. 내가 힘들었을 때 도움을 준 친구들에게 감사하다고 갑자기 이야기하며 고마움을 표현했다.
요리도 더 많이 해보기. 요리를 하면 할수록 재미있다. 이제 마카다미아 쿠키도 굽는다… 메타몽 틀이 생겨서 뭐할까 고민하다가 마카다미아 쿠키도 굽는 삶. 밀가루 덜 쓰면서 베이킹을 하는 방법도 있는 것 같은데 찾아봐야지

글 작성하는데 걸린 시간 : 9시간

Gemini CLI 사용법 - QnA 게시판 만들기(feat. SpecKit)

Sun, 21 Dec 2025 00:00:00 +0000

안녕하세요. 이번 글은 Gemini CLI, SpecKit, Supabase, Vercel을 활용해 QnA 시스템을 구현하는 내용에 대해 작성한 글입니다.
Gemini CLI 설정부터 SpecKit을 사용하는 흐름, Supabase 설정 및 UI 개선하는 과정을 담았습니다.
키워드 : Gemini CLI 사용법, Gemini CLI with SpecKit, Supabase, Vercel, Gemini Code Assist

Gemini CLI

소개

Gemini CLI는 Google의 AI 모델(Gemini)을 CLI 환경에서 사용할 수 있게 해주는 개발자 도구
최근 터미널 기반의 제품이 많이 나오는데, 직접 사용해보면 생산성이 많이 좋아지는 것을 느낄 수 있음
Gemini 모델의 장점 때문에 Gemini CLI를 쓰게 됨
- (1) 긴 컨텍스트 : 컨텍스트를 많이 넣을 수 있기 때문에 복잡한 작업, 많은 컨텍스트가 필요할 때 유리
- (2) 가격 : Gemini 모델의 가격은 다른 모델의 가격 대비 엄청 저렴함(특히 Gemini Flash Lite가 저렴해서 자주 사용함)
공식 문서, Docs

Gemini CLI 설치

Gemini CLI는 Node.js 환경에서 동작하므로, 사전에 Node.js가 설치되어 있어야 함
- 만약 Node가 설치되어 있지 않다면 Node.js 페이지를 확인해서 Node 설치
npm으로 글로벌하게 설치
```
  npm install -g @google/gemini-cli
```

Gemini CLI 실행

터미널에서 gemini 입력 후 엔터
- 만약 첫 실행이면 인증 방식을 선택하게 됨
- 구글 계정 로그인, API Key 방식, 구글 클라우드의 Vertex AI를 통해 인증할 수 있음
- 저는 Gemini를 구독하고 있어서 구글 로그인으로 선택함

/model을 입력하면 모델을 선택할 수 있음
- Pro (gemini-3-pro-preview, gemini-2.5-pro)로 설정

Gemini CLI 주요 명령어

명령어	설명
`/help`	사용 가능한 명령어 목록 확인
`/model`	모델 선택 (gemini-3-pro 등)
`/memory show`	현재 로드된 GEMINI.md 내용 확인
`/memory refresh`	GEMINI.md 파일 다시 로드
`/memory add <text>`	메모리에 텍스트 추가
`/chat`	대화 저장/불러오기/공유
`/chat save <tag>`	현재 대화를 태그로 저장
`/chat resume <tag>`	저장된 대화 이어서 진행
`/mcp`	MCP 서버 목록 및 상태 확인
`/tools`	사용 가능한 도구 목록
`/stats`	토큰 사용량, 세션 시간 등 통계
`/restore`	체크포인트로 롤백 (파일 변경 전 상태)
`/clear`	터미널 화면 초기화 (Ctrl+L)
`/compress`	대화 컨텍스트를 요약해서 토큰 절약
`/copy`	마지막 응답을 클립보드에 복사
`/settings`	설정 편집기 열기

stats 입력시 아래와 같이 Session의 통계 정보를 제공함

Extensions
- 다양한 Extensions이 존재하며, 설치하고 싶으면 아래와 같이 실행(나노바나나 Extension)
```
  gemini extensions install https://github.com/gemini-cli-extensions/nanobanana
```

GEMINI.md 설정

GEMINI.md는 Gemini CLI에게 프로젝트 Context와 작업 규칙(Rules)을 알려주는 설정 파일
- 이 파일에 작성한 내용은 모든 대화에서 시스템 프롬프트처럼 적용됨

Gemini CLI는 여러 위치의 GEMINI.md를 자동으로 찾아서 합쳐줌

아래 순서대로 로드되며, 모든 파일의 내용이 합쳐짐. 같은 항목에 대해 충돌이 있으면 하위 파일이 우선 적용됨(프로젝트가 글로벌보다 더 우선 적용)

  # 1) 글로벌(모든 프로젝트 공통) : 공통 규칙, 한국어 사용 등
  ~/.gemini/GEMINI.md      
	
  # 2) 프로젝트 루트 : 기술 스택, 구조 위주
  /project-root/GEMINI.md 
	
  # 3) 하위 디렉토리(해당 폴더에서 작업할 경우)
  /project-root/src/GEMINI.md

현재 로드된 컨텍스트는 /memory show 명령어로 확인할 수 있으며, CLI 하단에 로드된 파일 개수가 표시됨
GEMINI.md에 자주 들어가는 내용
- 기술 스택 : Python 3.13
- 코딩 컨벤션 : 네이밍 컨벤션
- 프로젝트 구조 : 폴더 설명
- 에러 처리 방식, API 호출 패턴
- 금지 사항 : 특정 라이브러리 사용 금지
- 참고 문서 : @로 외부 파일 import 가능
다른 파일을 Import해서 불러오고 싶을 때는 @을 사용함. 프로젝트 문서나 스타일 가이드를 분리해서 관리할 때 유용함
```
  # GEMINI.md 
	
  ## Project Context 
  @docs/architecture.md 
  @docs/api-spec.md 
```
GEMINI.md를 수정했으면 /memory refresh로 반영해야 함
컨텍스트가 길다고 좋은 것은 아니므로 이 파일도 계속 관리해야 함

SpecKit을 활용한 SDD 개발

소개

SpecKit은 GitHub에서 만든 오픈소스로 SDD(Spec Driven Development) 도구
- AI 코딩 에이전트(Gemini CLI, Claude Code 등)와 함께 사용하도록 설계됨
만들어진 계기
- AI에게 그냥 A 만들어줘라고 하면 의도와 다르게 나오거나 아키텍처가 엉망인 경우가 많음. 이 문제를 해결하기 위해 SpecKit은 코드 작성 전에 Spec을 정의하고 이를 기반으로 AI가 구현하도록 유도함
이 Spec을 사람이 리뷰하면 되고, 리뷰하는 과정도 이 도구 사용법 안에 자연스레 존재함
- 코드보다 이 Spec을 더 잘 관리하고, 잘 작성하는 것이 중요하다는 의견이 있는데, 저도 동의함. 기본적인 문서 작성이 더 중요해지는 시기
Workflow 흐름
- 크게 6단계로 설명할 수 있음
- (1) Specify : 기능 요구사항 정의(기술 스택이 아닌 무엇을 만들지)
- (2) Clarify : 애매한 부분, 의사결정이 필요한 부분을 질문하며 구체화
- (3) Plan : 기술 스택, 아키텍처 등 계획을 세움
- (4) Tasks : Plan을 기반으로 구현할 Task 생성
- (5) Analyze : Spec과 Task의 일관성 검증
- (6) Implement : Task 기반으로 코드 구현

SpecKit 설치하기

Python의 uv 설치

  curl -LsSf https://astral.sh/uv/install.sh | sh

SpecKit 글로벌 설치

  uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

SpecKit 프로젝트 설정

SpecKit 프로젝트 초기 설정

  specify init ask-kyleschool --ai gemini

만약 이미 폴더가 생성되어 있고, 현재 폴더에서 설정하고 싶은 경우
```
  cd existing-project 
  specify init . --ai gemini
```

이제 .gemini 폴더와 .specify 폴더를 보면 SpecKit 관련 파일들이 생성된 것을 볼 수 있음

Gemini CLI에서도 커맨드가 보임

SpecKit을 활용한 개발

위에서 소개한 6단계를 실제로 진행

단계	명령어	설명
1. Specify	`/speckit.specify`	기능 요구사항 정의
2. Clarify	`/speckit.clarify`	애매한 부분 구체화
3. Plan	`/speckit.plan`	기술 스택, 아키텍처 계획
4. Tasks	`/speckit.tasks`	구현할 태스크 생성
5. Analyze	`/speckit.analyze`	Spec-Task 일관성 검증
6. Implement	`/speckit.implement`	코드 구현

Specify로 요구사항 구체화

/speckit.specify "SQL 강의를 진행하는데, 학생들이 자유롭게 질문을 남기면 AI가 자동으로 답변을 남겨주는 플랫폼을  만들고 싶어."

조금 시간이 지나면 Branch, Spec이 완성됨
- 여기서 디자인적 요소는 제외하고 기능 구현에 집중함

Clarify를 통해 구체화

이제 clarify를 입력해서 애매한 부분에 대해 구체화를 진행

/speckit.clarify

아래 화면처럼 질문들이 나타나고, 답변하면 됨

“Short. supabase를 사용하고 Social Login을 진행해”라고 답변함
이번엔 모델 질문

Gemini 2.5 Flash Lite를 사용하라고 답하고, 다른 질문들도 답변하고 이제 모두 Clarify 됨

Plan : 계획 생성

/speckit.plan

plan이 모두 세워짐

Tasks : Task 생성

이제 tasks 실행

/speckit.tasks

이제 tasks 생성 완료

생성된 tasks를 확인해보니 다음과 같음

Analyze : Spec과 Task의 일관성 검증

/speckit.analyze

SpecKit이 분석(analyze) 도중 Critical 이슈를 감지하면, 사용자에게 해결 방향을 물어봄

Critical 이슈를 해결하기 위해 Tasks.md 수정하라고 지시함
- Constitution Alignment Issue
- SpecKit 기본 원칙(constitution)에 “테스트 먼저 작성(Test-First)”이 필수로 되어 있음
- 근데 현재 tasks.md를 보니 테스트 작성 태스크가 없거나 너무 뒤에 있음 (T025/T026이 마지막 폴리싱 단계)
- 요약하면 테스트 먼저 써야 하는데 구현 태스크만 잔뜩 있어서 이슈 제시

위와 같이 tasks.md를 수정함
- Test tasks 추가 : Phase 3, 4, 5에 테스트 Task 추가 (Test-First 원칙 준수)
- RLS task 명시 : “같은 강의의 질문만 보이게” 가시성 규칙 명확히 함 (FR-009)
- Input Sanitization : 보안용 입력값 검증 Task 추가 (T012)
- Dependencies 업데이트 : 테스트 도구 설치(T002)

Implement : 코드 구현

이제 코드 구현. 이 작업은 앞선 작업들보다 시간이 더 소요됨

/speckit.implement

약 13분 정도 소요됨. 이 시간엔 위에서 작성된 Spec 문서를 다시 확인하거나 인프라 작업을 준비함(DB 등)

코드 구현 후, 이제 어떻게 진행하면 좋을지 물어봄(=인프라 작업 등의 안내를 받기 위해)

환경 설정

앞서 구현한 코드를 실행하기 위해 Supabase 및 Gemini API 설정 진행

Supabase 설정

Supabase 가입 후 새 프로젝트 생성

프로젝트 Settings - API Keys - Legacy anon, service_role API Keys를 누르면 anon_key를 확인할 수 있음

Supabase URL은 Settings - Data API - Project URL에서 확인할 수 있음

위 두 키를 .env.local에 저장함. 이 파일은 .gitignore에 추가되어야 함(Push 방지)

Gemini API 설정

AI Studio에서 생성할 수 있음
홈페이지 접속 후 Get API Key - API 키 만들기 - 이름 설정하면 Key가 저장됨
Supabase와 마찬가지로 Gemini API Key를 .env.local에 저장함

Supabase - Database 생성

supabase/migrations/20251220_init_schema.sql의 내용을 Supabase SQL Editor에서 실행

이제 필요한 Database가 생성됨

소셜 로그인 설정

소셜 로그인 설정을 하기 위해서 구글 클라우드 계정이 필요함
- 만약 이 과정이 번거로우면 처음엔 소셜 로그인 설정을 추가하지 않아도 무방함. 하지만 서비스로 만들 땐 소셜 로그인을 지원하는 것이 필요함
구글 클라우드 계정을 하나 생성한 후, Auth 페이지로 이동
만약 처음 생성했다면 아무것도 존재하지 않고, 시작하기 버튼을 클릭해야 함

앱 정보를 입력하고 나머지도 순차적으로 입력 후 저장
- 대상 : 외부

그 후, 클라이언트를 클릭한 후, 클라이언트 만들기 클릭

클라이언트를 만들면 다음과 같이 설정이 저장됨. JSON 다운로드를 해두는 것을 추천(잃어버리지 않도록 주의. 다운로드 폴더에 그대로 두지 않기)

이제 Supabase로 돌아와서 Authentication - Sign In / Providers - Google을 선택

Enable Sign in with Google을 설정하고 위에서 만든 클라이언트 id와 클라이언트 secret 값을 붙여넣기
- 하단에 있는 Callback URL 값은 이후에 사용할 예정이므로 복사 클릭

다시 구글 클라우드의 Client쪽에 다음과 같이 추가
- 승인된 JavaScript 원본 : 실행시킬 URL 입력. 지금은 배포하지 않고 제 로컬에서 실행할 예정이라 localhost:3000만 추가함
  - 나중에 배포하면 배포한 URL 웹페이지를 입력하면 됨
- 승인된 리디렉션 URI : 위에 Google 로그인에서 복사한 Callback URL 입력

개발 결과 확인

이제 인프라 설정이 완료되었으므로, 터미널에서 아래 명령어 실행해서 개발 결과 확인

npm run dev

localhost:3000으로 접속하면 다음과 같이 뜸

구글로 로그인을 시도하니 정상적으로 로그인 완료
로그인 후 닉네임 설정을 하게 됨

강의 페이지로 이동

‘BigQuery 쿼리를 실행하기 위한 기본적인 쿼리 구성 요소를 알려주세요’라고 질문함

그 결과 질문이 올라옴

답변은 다음과 같이 달림. 단, 마크다운 설정이 필요할 것 같음

만약 실행하는 과정에서 오류가 발생하면 Gemini CLI에게 오류를 보내고 수정하라고 가이드하면 됨. 만약 반복된다면 전체적으로 점검하라고 요청하는 것을 추천

UI 개선

새로운 Spec을 통해 디자인 개선하기

기능 구현은 되었고, 디자인을 개선하기 위해 다시 Spec을 작성함

위에서 진행한 것처럼 clarify, plan, tasks, analyze, implement를 실행한 후 기다림
- 이제 마크다운을 잘 표현하고, 디자인이 살짝 개선됨

더 자세한 지시를 통해 디자인 개선하기

만들어진 디자인이 마음에 들지 않아 어떻게 개선할지 고민하다가, Claude Code의 frontend-design 스킬을 참고해서 개선하라고 지시함

GEMINI.md 파일에 아래 내용을 추가함

  ## Frontend Design
  - Please refer to @frontend-design.md when implementing frontend designs

GEMINI.md를 수정한 후, 해당 지시를 기반으로 디자인을 개선하라고 지시함

처음 버전보다 더 세련된 느낌. 만약 내가 원하는 방향성이 있다면 디자인 레퍼런스를 구체적으로 줄수록 만족스러운 결과가 나올 수 있음

Gemini CLI에게 아이디어 문의

이제 또 무엇을 하면 좋을지 아이디어를 물어봤더니, 좋은 아이디어를 줬음

위 내용을 모두 모아서 하나의 Spec으로 정의해서 구현해달라고 지시함
- 강의 클릭시 대기 시간에 system_log 형식으로 구현함

Gemini Code Assist를 활용한 AI 코드 리뷰

이제 GitHub에 Push함. 처음 작업이라 main에 바로 Push했으나, 그 이후엔 브랜치를 새롭게 만들어서 확인하는 것을 추천함
Gemini Code Assist를 설치하면 GitHub에서 Pull Request가 발생할 때 코드를 Gemini가 리뷰해줌. 이 설정을 해두는 것을 추천

설정

Gemini Code Assist GitHub App 페이지 이동 -> Configure 클릭

로그인을 완료한 후, 사용할 GitHub Repository를 추가

AI 코드 리뷰 결과

이렇게 설정한 후, Pull Request를 하면 아래와 같이 리뷰가 달림(아래 리뷰는 다른 Repo에서 Gemini Code Assist가 리뷰한 내용을 가져옴)

Vercel 배포

Supabase와 Vercel이 잘 통합되어 있으므로, Vercel을 통해 배포하는 것을 추천
이 부분에 대해 글을 작성할 예정은 아니였지만, 간단하게라도 가이드를 남겨봄
Vercel - New Project를 누르면 GitHub에서 Import를 할 수 있음

Supabase URL, Anon Key를 추가하면 어렵지 않게 배포할 수 있음
Vercel 배포가 완료되면 새로운 URL이 생성됨. 이 URL을 Google Cloud OAuth(위에 소셜 로그인 부분)에 가서 승인된 JavaScript 원본에 Vercel URL을 추가해야 함
그리고 Supabase에서도 URL 설정을 추가해야 함
- Supabase > Authentication > URL Configuration에서 Site URL을 Vercel URL로 변경

후기

Gemini CLI도 많이 사용하면서 도구에 적응하게 됨. 이런 도구들은 실제로 써보고, 피드백 루프를 돌리는 과정이 필요함
Gemini CLI의 Release Notes를 보면 새로운 기능들이 계속 생기고 있음. 앞으로 계속 더 발전할 것 같음
Claude Code와 Gemini CLI 둘 다 사용하게 되었는데, 필요에 맞게 사용할 수 있도록 계속 시도해볼 예정
- Gemini CLI가 컨텍스트가 많기 때문에 핵심 AI 에이전트로 쓰고, Gemini CLI에서 Claude Code나 Codex를 실행하게 하는 것도 방법이고, 이미 이런 시도를 하는 분들이 계심
- AI 에이전트 도구들의 설정을 동일하게 저장해서 (예를 들어 AGENT.md를 만들어서) 관리하는 것이 필요할 듯. 새로운 도구로 이사하는 것이 번거롭게 느껴질 수 있음

이 글은 GDE 프로그램에서 진행한 AI Sprint에 참여하며 작성한 글입니다.

Google Cloud credits are provided for this project. #AISprint

Google Antigravity 사용법

Mon, 08 Dec 2025 00:00:00 +0000

안녕하세요. 이번 글은 Google의 Antigravity 사용법에 대해 작성한 글입니다.

키워드 : Google Antigravity, Google Antigravity 사용법

Antigravity

이름의 유래

Antigravity 소개글에 작성되어 있는 비전
- Our vision is to ultimately enable anyone with an idea to experience liftoff and build that idea into reality.
- Liftoff라는 용어는 항공기 전체가 지면에서 완전히 떨어지는 시점을 의미하는데, 구글은 자신의 아이디어 구현할 때 누구나 사용할 수 있는 도구를 만들고 싶었던 것 같음. 즉, 개발할 때 생기는 여러 이슈들을 중력이라 생각하고 그것을 대항할 수 있는 도구
여담으로 Python에서 import antigravity를 하면 XKCD 만화(353번)를 웹 브라우저로 열어주는 이스터에그가 발생하는데, 관련은 없지만 익숙한 용어였음

핵심 원칙

Antigravity의 핵심 원칙은 Trust, Autonomy, Feedback, Self-improvement

Trust

오늘날의 대부분의 제품은 두 케이스에 속함
- (1) 에이전트가 수행한 모든 Action과 Tool 호출을 사용자에게 보여줌
- (2) 작업의 컨텍스트나 검증할 방법 없이 최종 코드 변경 사항만 보여줌
- 이런 제품들은 에이전트가 왜 이 작업을 했는지, 어떻게 확인해야 하는지를 알기 어려움.
Antigravity는 사용자가 에이전트가 수행할 작업에 대한 신뢰를 가질 수 있도록 Actifact와 Verfication result(검증 결과)를 제공해 컨텍스트를 제공함
- 단순히 개별 Tool 호출이 전부 보이는 것이 아닌, 호출들이 Task 단위로 묶어서 표시함
- Task에 대한 추상화된 정리와 진행 상황을 확인할 수 있음
- 사용자가 검증하기 쉬운 형식의 Artifact를 생성함. 예를 들어 Task list(작업 목록), Implementation plan(구현 계획), Walkthrough(단계별 설명서), 스크린샷, 브라우저 녹화 영상
사용하면서 인상 깊은 부분은 웹브라우저 작업을 할 때 녹화가 되는 기능으로 작업을 어떻게 진행했는지 확인할 수 있었음. Plan 버전으로 실행할 때 Implementation plan, Walkthrough를 제공하는 것도 좋았음

Autonomy

요즘 가장 직관적인 제품의 형태는 여러 Surface(편집기, 브라우저, 터미널)에 내장된 에이전트와 동기적으로 동작하는 형태
- 에이전트가 자율적으로 프론트엔드 코드를 구현하고, 터미널에서 로컬호스트 실행하고, 브라우저를 작동시켜 새로운 기능이 작동하는지 테스트하는 형태
이런 자율성을 최적으로 사용하기 위해 사용자가 에이전트와 비동기적으로 상호 작용할 수 있도록 Manager View를 만들었음
Agent Manager View는 여러 에이전트를 병렬로 생성하고 모니터링할 수 있는 관제탑 스타일의 화면
기존에 자주 사용하던 VSCode, Cursor 같은 스타일은 Editor View로 존재함(Editor View와 Manager View로 전환하는 단축키는 커맨드(컨트롤) + e)

Feedback

에이전트의 지능이 좋아지면서 여러 작업이 가능해졌지만, 아직 완벽하지 않음
- 이런 상황에서 피드백을 제공하면 도움이 됨
- Antigravity는 모든 Surface나 Artifact에서 비동기 사용자 피드백을 허용함
- Text Artifact에선 주석을 달 수 있고, 스크린샷에서 영역을 선택해서 주석을 달 수 있음

Self-improvement

에이전트가 일하면서 배운 내용을 저장하고, 나중에 비슷한 일을 할 때 참조함
- 명시적 정보 : 유용한 코드 snippet, 아키텍처 정보

설치

웹페이지에서 다운로드 가능
Mac 사용자라면 brew로도 설치 가능
```
  brew install --cask antigravity
```
처음에 설치하면 기존에 사용하던 IDE(VS Code, Windsurf, Cursor 등)의 설정을 불러올 수 있고, Start fresh를 눌러서 시작할 수 있음
Agent 설정은 Agent-assisted development으로 설정했음

Antigravity - 크롬 확장 프로그램 설치

위와 같은 구성을 확인할 수 있고, VSCode와 다르게 우측 상단에 크롬 아이콘이 있어서 눌러봄

설치가 필요한데, 이미 크롬이 설치되어 있어서 경로를 직접 수정함
- Set custom Chrome binary path 클릭해서 경로 지정함

설정에서 Browser로 이동해서 Chrome Binary Path를 지정할 수 있음

다시 크롬 버튼을 누르니 온보딩 페이지로 나오고, 확장 프로그램을 설치함. 이를 통해 Antigravity에서 크롬을 제어할 수 있음

Agent

Agent의 Core Compoent
- Reasoning model
- Tools
- Artifacts
- Knowledge
Customization(커스텀 요소)
- Agent Modes / Settings
- MCP
- Rules / Workflow

Models

Google Vertex Model Garden을 통해 모델 제공
- 사용자가 원하는 모델을 선택할 수 있음
- Gemini 3 Pro (high)
- Gemini 3 Pro (low)
- Claude Sonnet 4.5
- Claude Sonnet 4.5 (thinking)
- Claude Opus 4.5 (thinking)
- GPT-OSS
사용량 제한은 Plans 문서에서 확인할 수 있음
- 현재(25년 12월 기준) Preview라서 무료로 사용 가능하며, Google AI Plan 구독 여부에 따라 제공량이 다름
- 기본 제공
  - 위에 제공하는 Model에 대한 기본 사용
  - Tab completion 무제한 제공
  - Command requests 무제한 제공
  - Agent Manager, Borwser integration 사용 가능
- Google AI Ultra : 제일 많은 사용량, 5시간마다 쿼타 갱신
- Google AI Pro : 많은 사용량, 5시간마다 쿼타 갱신
- Google AI Plan에 가입하지 않은 경우 적당한 사용량을 제공하고 주마다 쿼타 갱신
- 아직 key를 사용하는 방식은 지원하지 않으나, 추후에 지원할 가능성이 높음

Antigravity 내부에서 사용하는 모델

Antigravity가 동작하는 과정에서 모델을 사용하고 있으며, 사용자가 설정할 수 없음
UI 목업 생성, 웹페이지나 앱에서 사용할 이미지 생성, 아키텍처 다이어그램 생성 : Nano Banana Pro
브라우저 서브 에이전트가 브라우저에서 클릭, 스크롤, 입력 등 브라우저를 제어할 때 : Gemini 2.5 Pro UI Checkpoint(내부적으로 커스텀한 모델로 추측)
체크포인팅, 컨텍스트 요약할 때 : Gemini 2.5 Flash
코드의 Semantic Search(의미 기반 검색) : Gemini 2.5 Flash Lite

Tools(MCP)

MCP를 사용해 Antigravity가 데이터베이스에 직접 접근해서 정보를 가져올 수 있음

연결 방법

우측 상단에 있는 Agent의 우측에 …을 클릭 -> MCP Servers 클릭

필요한 MCP 검색(저는 supabase)

Install 클릭 후, 환경 설정

이제 MCP의 Tool을 사용할 수 있음

Artifacts

Artifacts는 에이전트가 작업을 완료하거나 작업과 생각을 사용자에게 전달하기 위해 생성하는 모든 것
예시
- Task list(할 일 목록)
- Implementation plan(구현 계획)
- Walkthrough(워크스루) : 변경 사항, 작업 과정 요약
- Screenshots(화면 캡처)
- Browser Recordings(브라우저 녹화)
- Knowledge(지식)
아래 실제로 실행하는 부분에서 확인 가능

Agent Modes / Settings

에이전트의 모드나 설정에 대한 이해가 필요함

대화 모드

대화할 때 2가지 모드 중 선택할 수 있음
- Planning, Fast
- Planning : 작업 실행 전에 Plan을 세움. 복잡한 작업에서 활용하는 것이 좋으며, 작업에 따라 아티팩트 생성, 계획 등을 수행
- Fast : 에이전트가 작업을 바로 실행함. 간단한 작업에 사용하며, 속도가 중요하고 품질 저하에 대한 걱정이 적을 때 사용
대화할 때 바로 설정할 수 있음

전반적인 설정

Antigravity Settings에서 설정할 수 있으며, Artifact Review Policy, Terminal Command Auto Execution Policy를 정의할 수 있음

Artifact Review Policy(아티팩트 리뷰 정책)
- 에이전트가 아티팩트에 대해 리뷰를 어떻게, 언제 물어볼지 결정하는 정책
- Always Proceed : 에이전트가 리뷰를 요청하지 않고 작업 진행
- Agent Decides : 에이전트가 리뷰 요청 시점을 스스로 결정
- Request Review : 에이전트가 항상 리뷰 요청
Terminal Command Auto Execution Policy(터미널 커맨드 자동 실행 정책)
- 에이전트가 터미널 컴맨드를 자동으로 실행할지 결정하는 정책
- Always Proceed : 에이전트가 터미널 명령을 실행하기 전에 확인하지 않고 실행
- Agent Decides : 에이전트가 터미널 명령을 실행하기 전에 스스로 판단
- Request Review : 에이전트가 터미널 명령을 실행하기 전에 항상 확인
두가지 설정 모두 Agent Decides로 설정하고 사용 중
유사하게 Browser Javascript Execution Policy도 존재함(설정 - Browser)
- Disabled : 에이전트가 브라우저에서 자바스크립트 코드를 실행하지 않음
- Always Ask : 에이전트가 항상 자바스크립트 코드를 실행하기 전에 확인
- Model Decides : 에이전트가 자바스크립트 코드를 실행하기 전에 스스로 판단
- Turbo : 확인 없이 자바스크립트 코드를 실행함

그 외에 Agent Non-Workspace File Access 설정은 Agent가 지금 작업 폴더와 Antigravity 루트 폴더(`~/.antigravity/) 외의 폴더에 접근할 수 있게 설정할 수 있음

Rules / Workflows

Rules : 지켜야 할 원칙
Workflows : AI가 행동해야 하는 순서 제공
Agent의 … 클릭 후 Customization을 누르면 설정할 수 있음

Rules

Agent가 따라야 하는 작업 스타일, 가이드를 작성한 마크다운 파일
Claude Code나 Gemini CLI를 사용하면 CLAUDE.MD, GEMINI.MD를 만드는데, 이 개념과 같다고 보면 됨
Global Rules와 Workspace Rules로 나뉨
- Global Rules : ~/.gemini/GEMINI.md에 저장
- Workspace Rules : 워크스페이스의 .agent/rules에 저장하고, 해당 워크스페이스에서만 적용
- Rules 파일 제한 : 12,000자(character)
Customizations에서 +workspace를 눌러서 Workspace Rules를 추가할 수 있음(현재 있는 Global 설정은 한국어 응답하라는 내용이 저장되어 있음)

Workspace Rule도 어떤 상황에 활성화를 할 것인지 옵션이 존재함
- Manual : 사용자가 에이전트 채팅창에서 @로 명시적으로 호출할 때 적용
- Always On : 항상 모든 상황에 적용
- Model Decision : Rule 파일을 읽고 현재 작업에 이 Rule이 필요한지 모델이 스스로 결정
- Glob : 특정 파일 패턴과 일치하는 파일을 다룰 때 적용

Workflows

workflow는 반복되는 작업을 정리한 파일
- 작업들을 단계별로 정의하면 에이전트가 그 순서에 맞춰 일을 처리함
실행할 때 채팅창에서 /워크플로우이름을 입력하면 실행됨
.agent/workflows 폴더에 저장됨
Customizatios - Workflows - +workspace를 누르면 만들 수 있고, 채팅으로 만들라고 할 수도 있음

실행하니 정상적으로 동작함

실제 사용기

웹페이지 취약점 확인 후 동작 테스트

개인적으로 만들고 있던 웹페이지의 취약점을 확인하고, 그 후에 실제로 잘 동작하는지 확인해달라고 함

하나씩 확인하는데, 영상을 찍어서 제시함. 이게 Screen Recording

작업 완료한 후, 하단에서 여러 내용을 확인할 수 있음
- 수정된 파일, Artifact(Implementation Plan, Task, Walkthrough)

이번에는 직접 로그인을 한 후 다시 확인해보라고 하니, 로그인 상황에서 테스트를 진행함

관리자 계정이 아닌 계정으로 테스트하는게 좋을까?라고 물어보니 아래처럼 안내함(일단 false로 주석처리해서 테스트)

그 후 테스트하고 성능 측정 후 내용을 공유함

Walkthrough 문서에 댓글을 남긴 후, 피드백을 제출함

제출한 후에 Agent Manager에서 내가 남긴 댓글에 대한 답변을 볼 수 있음

Screen Recording 기능

Screen Recording은 Antigravity가 browser_subagent라는 도구를 사용해 브라우저를 제어할 때만 자동으로 수행됨
- 녹화 시점: “브라우저를 열어서 확인해줘”라는 요청을 받거나, 스스로 웹페이지 테스트가 필요하다고 판단하여 브라우저 도구를 실행할 때그 세션의 화면이 녹화
- 녹화하는 것: 브라우저 창 내부에서 일어나는 일(클릭, 타이핑, 페이지 이동, 콘솔 로그 확인 등)만 녹화됨
Artifact가 어디에 저장하는지 확인해보니 다음 경로에 저장됨(/Users/UserName/.gemini/antigravity/)
- 동영상 용량은 작진 않아서 나중에 관리가 필요할 것으로 예상됨

대화 기록

만약 지난 대화를 찾고 싶다면 이 버튼을 통해서 찾을 수 있음

아키텍처 이미지 생성, 이미지 피드백

이번엔 아키텍처를 그려달라고 함
- Created Task를 보면 Task가 생성되고, Task의 Progress Updates를 보여줌

생성된 이미지에서 드래그를 하면 의견을 특정 부분에 줄 수 있음. 이 기능이 꽤 유용함

다른 의견도 주고 Submit을 클릭해서 피드백을 제시함

피드백을 반영해 이미지가 변경됨

Agent Manager View

command + e 또는 ctrl + e를 누르면 에이전트 매니저로 전환됨

Inbox

아래 이미지는 Inbox에 진입한 상태

Pending만 확인할 수도 있음. 지금은 모두 다 확인해서 나오지 않음

Workspace

workspace에는 내가 대화한 내용들은 확인할 수 있음. 우측에 Review Changes를 누르면 변환된 부분만 확인할 수 있음

workspace에 질문을 하니, 에디터쪽에도 동일한 workspace가 열려있어서 동기화됨

대화하다가 실수로 Conversation을 껐는데, option + command + b로 Toggle Agent를 다시 살렸음. 우측 최상단에 있는 이 버튼이였음

Playground

Playgrounds are independent workspaces perfect for quick prototypes or following your curiosity. Move to a dedicated workspace to continue exploring with multiple conversations라고 나와있는데, 간단히 요약하면 프로토타입을 만들 때 쓸 수 있는 공간
여기서 구현한 기능을 지금 프로젝트로 move 하는 기능도 제공함
- 다만 지금 에디터로 열었던 파일들을 참고하지 않는다. 제로베이스에서 시작하는 것
- ~/.gemini/antigravity/playground/ : 경로를 확인해보니 해당 폴더에 저장됨

Knowledge

persistent memory라고 나와있는데, 아직 생성된 지식이 없어서 아무것도 나오지 않음

Changelog

Changelog 페이지를 보면 어떤 기능을 업데이트했는지 확인할 수 있음
25년 12월 4일 기준 Google AI Pro, Ultra 구독자에게 사용량을 늘려주고 Rate limit 주기를 더 빈번하게 수정함. 그 전에는 조금만 쓰면 쿼타가 찼다는 이야기가 나왔는데, Google AI 요금제랑 연동해서 점점 해결될 것으로 보임

전반적인 후기

Antigravity 장점

현재 Preview라 무료 사용 가능(Google AI 멤버십을 사용한다면 더 많은 사용량을 받음. Gemini 구독 중이라면 꼭 써보는 것을 추천)
Gemini 3, Claude Opus도 사용 가능
크롬 브라우저와 통합되어서 브라우저 제어가 수월함
브라우저 작업시 Screen Recording을 해서 확인할 수 있음
Agent Manager 구성으로 Agent가 어떻게 동작하는지 확인할 수 있음(다른 IDE와 차별점)
이미지에 드래그를 해서 피드백을 줄 수 있음(디테일한 피드백)
기존에 VSCode를 사용했는데, Antigravity를 메인으로 사용할 예정

개선하면 좋을 부분

나온지 얼마 되지 않아서 오류가 존재할 수 있음. 이는 Preview 단계라 그렇고 점점 개선될 것으로 예상
BigQuery MCP 설정할 때 오류가 발생했는데, 디버깅이 어려웠음

Google Cloud credits are provided for this project. #AISprint

GDE로 참여한 Google I/O Connect China 2025

Sun, 17 Aug 2025 00:00:00 +0000

안녕하세요. 이 글은 GDE(Google Developer Expert)로 Google I/O Connect China에 참여한 후기를 작성한 글입니다. GDE로 처음 참여한 해외 컨퍼런스라 기억하고 싶어 작성합니다.

키워드 : GDE, Google Developer Expert, Google I/O Connect China 2025, 해외 컨퍼런스 참여

GDE란?

GDE 페이지
GDE는 Google Developer Experts의 약자로 경험이 풍부한 기술 전문가들로 구성된 글로벌 네트워크 커뮤니티입니다
전 세계에 약 1,400명의 GDE가 활동하고 있으며, GDE의 카테고리는 AI, Cloud, Andorid, Angular, Dart, Firebase, Flutter, Go, Kaggle, Google Workspace 등 다양하게 있습니다

GDE 혜택

구글 개발자 커뮤니티에서 활동할 기회를 얻으며, 활동을 위해 지원을 받습니다
- 예를 들어 구글 행사에서 발표할 기회를 얻습니다
해외 컨퍼런스 지원 : 구글에서 주최하는 이벤트에 초대됩니다. 이번 Google I/O Connect China 2025도 초대 받았습니다
Google의 새로운 제품, Feature에 대한 사전 체험을 할 수 있으며, GDE 디렉터리에 표시됩니다
구글 엔지니어와 기술 교류를 받을 수 있습니다
그 외에 공개되지 않았지만 여러 혜택들이 존재합니다

GDE 선발 과정

(1) 구글러 혹은 기존 GDE 추천을 받아 지원 링크 전달 받기
(2) 지원서 작성하기
(3) 구글 내 관련 팀들의 지원서 검토 과정
(4) 지원한 구글 프로덕트 팀의 직원(구글러)과 인터뷰
자격 기준
- 특정 분야의 기술 전문가
- 다음과 같은 활동을 통해 스타트업 및 개발자 생태계에 지속적으로 활동해야 함
  - 기술 컨퍼런스에서 영향력 있고 인정 받는 연사로 활동
  - 튜토리얼, 코드 샘플, 교육 서적, 블로그 게시물/영상 등의 기술 컨텐츠 제작
  - 기술 창업가, 스타트업, 개발자 멘토링
- 명확하게 소통하며 다른 사람에게 의미 있는 조언을 제공할 수 있는 역량
컨퍼런스에서 자주 발표를 하며, 기술 블로그에 글을 쓰신다면 기회를 얻을 수 있을 거라 생각합니다. 저도 이런 과정을 통해 되었다고 볼 수 있습니다
저는 Google Cloud의 Champion Innovator로 활동하다가 올해 3월에 GDE와 통합되어 GDE(Cloud)가 되었습니다
- GDE + Google Cloud Champion Innovator 게시글
AI/Cloud/Go GDE인 한성민님의 후기도 참고하셔도 좋을 것 같습니다

상해(상하이)

저는 행사 일정인 2025-08-12 이전에 출국해서 친동생과 함께 상해를 돌아다녔습니다. 상해에 도착했을 때는 39도로 매우 더웠고 습했습니다. 8월 상해는 매우 더워서, 관광으로 상해에 가신다면 10월을 추천드려요
처음 방문한 중국은 참 신기했습니다. 전기차가 엄청 많이 보급되었고, 공기도 좋았어요. 모든 주문 과정이 알리페이로 가능해서 페이 서비스가 많이 보급될 수도 있구나 생각했어요
- 상해 여행을 하면서 느낀 것은 인스타그램에 올려두었습니다!
- 와이탄 야경, 예원, 대한민국임시정부, 신천지, 우캉멘션, 우전 수향마을에 다녀왔고, 헌지우이치엔 양꼬치도 먹고 샤오롱바오, 동파육, 지엔빙, 밀크티 등 다양한 음식을 먹고 왔어요

혹시 상해 여행 정보가 궁금하시면 노션을 참고해주세요. 간단하게 정리를 해두었습니다

Google I/O Connect China 2025

행사 웹페이지
한국에선 총 7명의 GDE가 참여했고, Google I/O Connect는 2025년 8월 13일 ~ 14일에 진행되었습니다. GDE들은 2025년 8월 12일 ~ 15일에 여러 행사에 참여했습니다

GDE Welcome 행사

Google I/O Connect China 전날에 미리 호텔에 체크인하며 호텔을 돌아다녔습니다
- 2인실이라 룸메가 누가 될지 궁금했는데, 외국인이면 어떻게 인사하지? 고민했습니다. 다행히 원래 알던 한국 GDE분과 숙소를 쓰게 되었습니다(안심함)

호텔 1층에 있었던 APAC GDE Regional Summit

저녁엔 GDE 환영 행사에서 여러 GDE와 만났습니다. 저는 GDE가 된지 얼마되지 않아서 한국의 GDE분들과 교류가 적었는데 처음 뵌 분도 있고, 원래 알던 분도 있었습니다. 저녁을 먹으며 대화를 나누었고, 럭키드로우 시간을 가지고 첫 날을 마무리했습니다

힙색, GDE 반팔, GDE 재킷을 받았고 그 외에 물병도 받았습니다. 그 외에 커뮤니티 매니저님께서 구글 클라우드 뱃지도 주셨어요…!! 잘 챙겨주셔서 감사합니다
- 한국 커뮤니티 매니저이신 나현님이 한국 전용 굿즈도 만들어서 주셨고, 클라우드 뱃지도 주셨습니다! 잘 챙겨주셔서 감사해요

Google I/O Connect China 2025

아침에 다 같이 모여 버스를 타고 행사장으로 갔습니다. 한국의 코엑스 같은 공간이였어요(엑스포라고 함)

Google I/O Connect China 2025에서도 굿즈를 받았습니다. 작은 가방과 부채, 충전기 어댑터 모음이 있었습니다

키노트에는 정말 많은 사람이 있었고, Gemini 이야기, AI를 적용한 기업들의 이야기, Firebase Studio 등 다양한 내용을 전달했습니다. 장표가 중국어라 새로운 경험을 했는데, 갤럭시에서 서클 투 렌즈 기능을 사용해 바로 한국어로 변경해서 보니 어려움은 없었습니다
- Google I/O에선 보통 새로운 제품을 선보이고, Google I/O Connect는 Google I/O에서 소개한 기술들을 위주로 공유해서 최근에 AI쪽을 가볍게만 보고 있던 제게 오히려 좋았습니다

“Agents are all you need - build your agents with ADK, A2A, MCP and Agent Engine” 발표가 특히 기억에 남는데, 에이전트를 구성하기 위한 과정을 잘 설명해줬습니다. 발표에서 이야기 전개하는 과정이 부드러웠고, 발표 전달하는 방식은 언어 상관없이 비슷하다는 것을 느꼈습니다
- 요즘 저는 AI 관련 책을 마무리하고 있는데, 이 책을 번역하면서 LLM 생태계에 대해 더 자세히 알게 되었습니다. 그 과정에서 구글의 기술을 인지하고 있었지만 많이 사용하지 않았는데 여러 발표들을 보면서 앞으로 학습하고 싶은 것들을 기록해두었습니다. 아마 올해에 이런 키워드들을 저만의 언어로 정리할 것 같네요
- Gemini, Gemini CLI, Gemma, A2A, ADK 등..!
- BigQuery나 Dataflow, Pub/Sub 등 구글클라우드의 데이터 서비스들도 한번 다 정리를 해두려고 합니다(이미 알고 있지만 그 사이에 많은 기능이 확장되었더라구요)
- 발표를 보면서 이런 동기부여를 얻고, 추가로 뭘 해야할지 아이디어를 얻을 수 있어 감사했습니다
Google’s AI stack for developers 발표는 확인해보니 유튜브에 올라온 내용이 있네요. 개발자를 위한 AI 스택이 궁금하시면 살펴보시는 것을 추천합니다. 유튜브 영상
행사 2일차에 GDE들을 위한 와이탄 투어가 있었고, 가이드님의 이야기를 들으며 와이탄을 둘러봤습니다. 와이탄이 참 이뻐서 상해 가신다면 꼭 가보셔요. 저녁도 이쁘답니다

와이탄 투어가 끝난 후, 한국 GDE와 함께 헌지우이치엔 양꼬치집으로 갔습니다. 제가 상해에 일찍 와서 줄서기나 웨이팅이 적은 곳을 알아서 웨이팅이 적은 곳으로 갔습니다. 대형 테이블로 예약했는데 50분 걸리다고 해서 6명 테이블에 7명이 같이 앉았습니다. 이 때 많은 분들이 양꼬치를 엄청 좋아해주셔서 뿌듯했습니다. 대화도 많이 하면서 더 친해졌습니다

그 후에 동방명주까지 걸어가서 근처를 구경하다 왔습니다. 밤에 더 이쁘더라구요

마지막 일정

Google I/O Connect China 2025 끝난 다음 날에는 2025 APAC GDE Regional Summit이 진행되었습니다
- APAC GDE들이 얼마나 있고, 어떤 활동을 했는지 등에 대해 이야기를 하며 구글의 기술에 대한 내용을 들을 수 있었습니다
- 중간에 GDE 라이트닝 토크도 진행했는데, AI GDE인 이준범님이 발표를 해주셨습니다!
발표를 보면서 이런 커뮤니티에 소속될 수 있어 좋았고, 남은 기간엔 또 무엇을 해볼지 동기부여를 얻었습니다. 이런 행사에 오지 않았다면 아마 이런 동기부여를 느끼지 못했을 것 같네요. 오프라인 행사에 참여하면 확실히 동기부여가 되는 것 같아요

느낀점 및 생각

Google Cloud Champion Innovator는 해외 컨퍼런스 참여 기회가 없어서 이번이 구글 컨퍼런스에 처음 참여했습니다. 2019년에 회사에서 보내준 오라일리 컨퍼런스에 방문하고 오랜만에 가는 해외 컨퍼런스라서 설렜는데, 많은 것을 느끼고 돌아왔습니다
상해에서 생활하면서 중국이 기술적으로 많이 발전했다는 것을 몸소 느꼈고, 이런 상황이 한국에선 될 수 있을까?를 생각해보곤 했습니다
외국인들과 대화하는 것이 익숙하지 않지만, 다른 분들이 이야기하는 것을 보면서 일상 대화 내용은 어느정도 이해가 되며, 더 말하고 싶어집니다. 환경을 바꾸니 저도 자극을 받고, 시도할 것들이 떠오르네요
한국 GDE분들과 대화를 나눌 수 있어 즐거웠고, 종종 한국에서도 이런 모임이 있으면 좋겠다고 생각했어요. AI GDE는 아니지만 나중에 AI 카테고리도 추가해야겠단 생각을 했고(원래 하던 일이 AI쪽도 있으므로) AI GDE를 담당하시는 분이 군대 7개월 선임의 누나셔서 세상 참 좁다는 생각을 했네요. 덕분에 군대 선임 형에게 연락했네요
GDE로 참여할 수 있어 영광이였고, 최근 AI/LLM쪽을 간단하게만 보던 제게 큰 자극이 되었습니다. 앞으로의 방향성을 잡을 수 있는 계기가 되었고 여러가지를 해보겠습니다(하고 싶은 것들은 많은데, 우선 순위만 잘 잡으면 될 것 같네요)
2년차에 GDE가 되고 싶다고 써둔 글이 있는데, 시간이 지나니 이렇게 GDE로 활동하고 있네요. 계속 기록하고 발표하다보면 이루어지네요. 앞으로도 계속 하나씩 발전해보겠습니다
GDE에 관심이 있는 분이 있다면 연락주셔요!
행사 준비해주시고 초대해주신 분들 모두 감사합니다!

글 작성하는데 걸린 시간 : 45분

SQL 레벨 별(Lv 1~5) 핵심 문법

Wed, 02 Jul 2025 00:00:00 +0000

SQL 역량을 레벨로 정의해봤습니다. 업무를 하고, 학생들을 가르치면서 느낀 레벨을 정리했어요
- 주관적으로 정의했으며, DB는 BigQuery 기준으로 작성했습니다.
- 요즘 데이터 웨어하우스쪽은 문법이 유사해서 키워드만 가지고 가셔도 좋을 것 같습니다
키워드 : SQL 필수 문법, BigQuery 문법, SQL 레벨 별 핵심 문법

SQL 문법 레벨별 핵심 체크리스트

SQL 기본 형태

SQL의 기본 형태는 다음과 같음(하나의 테이블을 사용할 경우)

SELECT
  col1,
  col2
FROM
WHERE
GROUP BY
HAVING
ORDER BY
LIMIT

SQL 문법(Lv 1)

제일 기본적인 개념

SELECT : 컬럼 선택, FROM : 테이블 지정

특정 테이블에 있는 컬럼을 확인
AS를 사용해서 Alias(별칭)을 정의할 수 있음

SELECT
  col, 
  col2 AS new_col
FROM Table

WHERE : 테이블의 컬럼에 조건 설정

테이블에 존재하는 컬럼에 조건을 설정하고 싶은 경우 사용
- 데이터에서 특정 조건을 충족하는 Row를 가지고 오고 싶은 경우 사용

SELECT
  col,
  col2 AS new_col
FROM Table
WHERE
  col2 = 3

GROUP BY : 집계할 기준 명시

데이터를 특정 그룹으로 묶어서(집계) 쓰고 싶을 때 사용
- GROUP BY에 그룹화할 컬럼을 명시하고, SELECT에도 명시를 해줘야 함

SELECT
  type1,
  type2,
  COUNT(*) AS cnt
FROM Table
GROUP BY 
  type1, 
  type2

BigQuery에서는 GROUP BY ALL을 사용하면 알아서 집계할 컬럼을 추론해서 실행함

COUNT(col) : col 개수 세기, DISTINCT : 고유값 추출(중복 제거)

COUNT(*) : 컬럼의 Row 수를 센다. Row는 값이 NULL이여도 센다
COUNT(컬럼) : 컬럼의 값의 수를 센다. 값이 NULL이면 세지 않는다
COUNT(DISTINCT 컬럼) : 컬럼의 값의 고유값(중복 제외한 값)을 센다

SELECT
  type1,
  type2,
  COUNT(*) AS cnt1,
  COUNT(id) AS cnt2,
  COUNT(DISTINCT id) AS cnt3
FROM Table
GROUP BY 
  type1, 
  type2

AVG, MAX, MIN

평균, 최대값, 최소값

HAVING : 집계 후 컬럼에 조건 설정

GROUP BY와 같이 사용됨
GROUP BY 후에 조건을 설정하고 싶은 경우 사용
- (비교) WHERE : 테이블의 컬럼에 조건 설정, HAVING은 GROUP BY 후에 조건 설정

SELECT
  type1,
  type2,
  COUNT(*) AS cnt
FROM Table
GROUP BY 
  type1, 
  type2
HAVING cnt >=3

ORDER BY: 정렬

데이터를 정렬하고 싶은 경우 사용
- 쿼리의 중간에 사용하지 않고 쿼리 제일 바깥(마지막) 쿼리에 실행하는 것이 좋음
- ORDER BY는 모든 데이터를 다 확인해서 정렬을 하기 때문에 시간이 소요됨
ASC(오름차순), DESC(내림차순)

SELECT
  type1,
  type2,
  COUNT(*) AS cnt
FROM Table
GROUP BY 
  type1, 
  type2
HAVING cnt >=3
ORDER BY cnt DESC

LIMIT : 출력할 개수 제한

출력할 개수 제한하고 싶을 때 사용

SELECT
  type1,
  type2,
  COUNT(*) AS cnt
FROM Table
GROUP BY 
  type1, 
  type2
HAVING cnt >=3
ORDER BY cnt DESC
LIMIT 3

SQL 문법(Lv 2)

조건문(CASE WHEN, IF)

조건을 설정하고 싶은 경우
다중 조건은 CASE WHEN 추천

SELECT
  CASE 
    WHEN 조건1 THEN 결과1
    WHEN 조건2 THEN 결과2
    ELSE 모두아닐때
  END AS case_result
FROM Table

SELECT
  IF(조건, 조건이 참일 때 값, 조건이 거짓일 때 값) AS if_result
FROM Table

시간 데이터 다루기

시간, 월 추출
특정 일자 기준으로 버리기
TIMESTAMP, DATETIME 개념
UTC 개념도 알면 좋음
BigQuery 기준으로 설명

SELECT
  EXTRACT(HOUR FROM datetime_col) AS hour
FROM Table

JOIN : 여러 테이블을 연결할 때 사용

INNER, LEFT, RIGHT, CROSS JOIN
ON 사용해서 공통 Key 연결

SELECT
  lt.id,
  lt.col1,
  rt.col4
FROM left_table AS lt
LEFT JOIN right_table AS rt
ON lt.id = rt.id

SQL 문법(Lv 3)

윈도우 함수

코딩 테스트에서 자주 출제되는 유형
이전/이후 : LAG/LEAD
처음, 마지막 값 : FIRST_VALUE, LAST_VALUE
순서 확인 : ROW_NUMBER, RANK, DENSE_RANK
윈도우 함수 문법
- 함수(컬럼) OVER(PARTITION BY 파티션컬럼 ORDER BY 정렬컬럼)

SELECT
  LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_event_time,
  FIRST_VALUE(event_time) OVER (PARTITION BY user_id ORDER BY event_time) AS first_event_time
FROM Table

SELECT
  DENSE_RANK() OVER (PARTITION BY team ORDER BY cnt) AS rank
FROM Table

WITH문(CTE)

쿼리를 잘 정리하고 싶을 때 사용
서브쿼리를 작성하고 정리할 때 자주 사용함

WITH cte AS (...
  SELECT
    col2, col3
  FROM Table
)

SELECT 
  * 
FROM cte

SQL 문법(Lv 4)

윈도우 함수(Frame 조절)

AVG, SUM 함수와 함께 Frame 조절
이동 평균 구할 때 활용
함수(컬럼) OVER(PARTITION BY 파티션컬럼 ORDER BY 정렬컬럼 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
CURRENT ROW : 현재 ROW
UNBOUNDED : 끝까지
PRECEDING : 이전
FOLLOWING 이후
윈도우 함수의 ORDER BY 뒤에 쓰면 됨

SELECT
  SUM(value) OVER (PARTITION BY user_id ORDER BY order_date) AS cumulative_sum
FROM table

ARRAY, STRUCT

배열, 구조체 데이터를 다룰 때 사용
GA4, Firebase 데이터 다룰 때 필수
PostgreSQL, BigQuery, Apache Spark 등에 존재하며 문법이 다양함

GROUP BY GROUPING SETS/ROLLUP/CUBE

GROUP BY의 확장판
집계를 더 편하게 할 수 있음
- 아래 쿼리는 category, region 별 집계 + region 별 집계 + 전체 집계

SELECT 
  category,
  region,
  SUM(sales_amount) AS total_sales,
  COUNT(*) AS transaction_count
FROM sales
GROUP BY GROUPING SETS (
  (category, region),
  (region),
  ()
)

SQL 문법(Lv 5)

JSON

JSON 형태에서 데이터 추출
JSON_QUERY, JSON_VALUE
DB마다 문법 다양함

정규표현식

텍스트 데이터에서 데이터 추출
REGEXP_CONTAINS
DB마다 문법 다양함

UDF(Used Defined Function)

사용자 정의 함수
파이썬에서 함수 쓰는 것처럼 정의해서 쓸 수 있음
DB마다 문법 다양함

글 작성하는데 걸린 시간 : 23분

일 잘하는 사람의 특징, 마음가짐

Sun, 22 Jun 2025 00:00:00 +0000

이 글은 일을 잘한다고 느낀 사람들의 특징을 정리한 글입니다. 주관적인 내용을 담고 있어서, 의견이 있으면 댓글로 남겨주셔도 좋아요.
키워드 : 일 잘하는 사람의 특징, 신입 마음가짐

일 잘하는 사람은 어떤 사람일까?

최근에 강의 수강생분에게 질문을 받았다. 신입 데이터 분석가 관점에서 어떤 마음가짐을 가지면 좋을까요?
- 넓은 질문이라 내가 중요하게 생각하는 원칙들에 대해서 공유했는데, 이 내용에 대해 정리해보면 좋을 것 같아서 글을 작성해본다
우선 내가 생각하는 일을 잘하는 사람은 “함께 일하고 싶고, 신뢰할 수 있고, 성과를 내는 사람”이라 생각한다
- 사람마다 정의가 다를 수 있어서, 이 정의부터 하는 것이 시작인 것 같다
- 그리고 직무마다 직무 특성을 고려한 일을 잘한다를 정의할 수 있다
  - 예를 들어, 데이터 분석가는 현실적인 상황에서 할 수 있는 여러가지 Action Item 중에 가능성이 있어 보이는 Action Item을 제시하는가?
  - 직무 외에도 연차가 쌓이면 하나의 Task만 하는 것이 아니라 전체에 영향을 미칠 수 있는가?도 고려한다.

일 잘하는 사람의 특징

내가 본 사람들의 특징을 정리해보면 다음과 같다. 물론 이게 정답이라는 것은 아니고, 다른 특징도 있을 것이다

소통이 잘 되는가

회사에서 일을 할 때, 다른 팀원들과 소통을 하는 경우도 있고 팀장님과 소통하는 경우도 있고 다른 팀과 소통하는 경우가 있다. 정말 많은 사람들과 소통을 하게 된다
이 때 소통이 잘 되는 사람이 일을 잘한다고 느껴진다
- 그럼 소통이 잘 된다는 것은 어떻게 정의할 수 있을까?
- 이것도 굉장히 다양하게 정의할 수 있는데, 나는 “맥락을 전달하면서, 필요한 정보를 적시에 전달하며, 서로 대화를 나누는 경우”를 소통이 잘 된다고 정의한다
맥락을 전달한다는 것
- 모든 일에는 맥락이 존재한다. 어떤 상황이여서 지금 이 프로젝트를 하게 되었고 또는 어떤 맥락에서 갑자기 의사 결정을 다르게 하기로 했고 등. 이런 맥락이 Why와 유사하다.
- 사람들이 어떤 것을 보고 왜? 그렇지라는 생각을 하지 않도록 먼저 맥락을 전달하는 경우가 좋았다
- PM분들과 일할 때 맥락을 자세히 공유하는 경우 더 잘 이해할 수 있었고, 코칭을 할 때도 그 사람의 고민의 맥락을 들을 때 더 좋은 내용으로 이야기를 나눌 수 있었다
- 그래서 항상 시작할 때 맥락을 같이 공유하면서 이야기를 전개했다
- 팀원이 이슈를 겪을 때, 스스로 시도하다가 빠르게 내게 공유해주는 경우가 좋았다. 마감 기한이나 납기 직전에 안된다고 공유하면 그건 해결하기 참 어렵다. 안되는 것은 문제가 아니기에 이슈가 생기면 적절하게 SOS를 치는 것도 중요하다
필요한 정보를 적시에 전달한다는 것
- 상대방이 궁금해하기 전에 먼저 공유하는가? 관점으로 볼 수 있다
- 이건 다양하게 해결할 수 있는데, 내가 본 사람들은 문서 정리를 잘 해두고, 누가 필요하다고 할 때 그 정리 문서를 바로 제공했다
- 즉, 소통을 잘하기 위한 수단으로 기록을 사용했던 것
- 혹은 사람이 직접 답변하지 않아도 되도록 특정 키워드를 포착하면 자동으로 특정 문서를 공유할 수 있도록 슬랙 옵션을 설정하기도 했다
- 요즘은 LLM이 발전하면서 이런 것들을 더 적시에 제공할 수 있다고 생각한다
- 그리고 필요 이상의 정보를 주는 것은 좋은 커뮤니케이션이 아닐 수 있다. 적절한 수준의 정보를 주는 것이 필요하다. 사람은 한꺼번에 모든 내용을 받을 수 없기 때문에
서로 대화를 나누는 경우
- 서로 대화를 나눈다는 간단하게 담소를 나눈다 이런 맥락이 아니라, 제대로 이해하지 못했으면 한번 더 물어보고 합의를 하는지를 의미한다.
- 서로 대화를 나누면서 오해를 없애고, 정의를 맞추고, 만약 의견이 다르면 추가 논의를 통해 합의를 이끌어야 한다
- 이 대화를 하는 과정에서 좋은 질문을 하는 역량이 필요하고, 어떻게 대화를 할 것인가?에 대한 고민도 하면 좋다

예측이 가능한가

예측의 정의 : 미래에 발생할 일이나 상황을 미리 짐작하여 판단하는 것
- 팀장 입장에서 팀원이 예측 가능한가?
- 혹은 같이 협업하는 입장에서 동료가 예측 가능한가?
예측이 가능하다는 것은 그 사람이 어떻게 말하고, 어떻게 작업하는 것이 모두 포함된 개념이라 생각한다
- 처음 입사한 사람은 예측이 어렵다. 왜냐하면 같이 일한 데이터(경험)이 적기 때문
- 같이 일을 하면서, 그 사람이 어떻게 일을 하는지 경험이 쌓이고, 이런 경험 기반으로 예측을 하게 된다
여기서 많이 발생하는 이슈는 업무의 예상 완료일이 늦어지는 경우다
- 늦어지는 것 자체는 문제가 아닐 수 있다. 늦어진다고 공유만 하면 된다
- 하지만 이렇게 늦어진다고 말하는 것도 신입 시절엔 말하기 어려웠다. 그래서 나는 신입 시절에 내가 예상한 일정보다 +1~2일 정도 추가해서 말하고 빨리 끝나면 빨리 공유했다. 항상 하다보면 예상하지 못한 일이 생겨서 딜레이가 생기는데, 최초에 공유한 일자 안에 해결한다면 다른 사람 입장에선 말한 일정을 지키는 사람이 된다
  - 그렇다고 이걸 잘못 이해해서 항상 일정을 +하라는 것은 아니다. 내가 얼마나 걸릴지 잘 예측할 수 있다면 정확한 일자를 주는 것도 좋다. 신입 시절에만 사용한 방법

하나의 Task가 아니라 전체에 영향을 미치는가?

신입 시절에는 내가 받은 업무 하나만 봤다면, 연차가 쌓일수록 조직 전체에 영향을 미칠 수 있는가?라는 요소가 나오게 된다
이 부분을 조금 더 자세히 생각해보면 거시적인 관점으로 이해를 할 수 있는가?를 의미하는 것 같다
- 회사의 비즈니스 전체 상황을 이해하고(비즈니스 모델을 알면 좋은 이유) 그 상황에서 회사/조직이 무엇을 해야하는지 알 수 있는 것
- 그래서 단순히 지엽적인 부분만 하는 것이 아니라, 거시적인 관점으로 보고 많은 조직에서 필요한 일이 있다면 그것부터 해결하는 것이 필요하다
- 예를 들어, 데이터쪽에선 많은 사람들이 데이터를 활용하고 싶은 상황이거나 데이터 쿼리 추출에 많은 시간이 걸리면 그 부분이 병목이기에 이걸 해결하면 더 많은 사람들이 혜택을 입게 된다
전체에 영향을 미치는 것은 누가 공유해주는 것보다, 스스로 탐색을 해야 하는 것 같다. 그 과정에서 다른 사람들과 많이 이야기도 나누고, 거시적인 관점으로도 보고, 여러가지를 고민해야 한다
- 신입 시절에는 Task에 집중하고, 주변의 시니어분이 무엇을 하는지 살펴보면서 배워도 좋을 것 같다

우선 순위 선정 및 선택과 집중

회사에서 일을 하다보면 이것도 해야 하고, 저것도 해야 하고, 아 다 해야지! 하다가 아무것도 못하는 경우가 있다
이럴 때 우선 순위를 선정해서 제일 중요한 문제부터 하나씩 푸는 것이 필요하다
- 이게 말로는 이해가 되는데, 실제로 하고 있는 것을 보면 우선 순위 없이 모두 다 하고 있는 경우가 많다
목표가 막연할 경우엔 목표를 구체적으로 정의하고, 한번에 달성하기 어렵다고 하면 일정을 나눠서 쪼개서 실행한다
- 또한 그 과정에서 시간 관리를 잘 진행해서 필요한 것들 위주로 진행한다

마음 관리

일을 잘하는 사람들은 회복탄력성도 좋은 편이였다. 마음 관리를 잘하는 사람들인데, 일을 하다보면 좋은 일도 있지만 아쉬운 일도 있다. 예를 들어, 기능을 배포했는데 예상보다 지표가 올라가지 않는 경우
- 이게 1번이라면 다시 하지! 라고 하는데 여러번(3회 이상)이 되면 좌절을 겪을 수 있다. 아 난 안되나? 이런 생각
- 그럴 때 마음을 다시 다 잡고, 흠 여태까지 시도를 아예 방향을 바꿔야 할까? 어떻게 해야할까? 고민해보는 것을 추천한다
- 어떤 시도를 하려면 마음의 여유가 있어야 할 수 있다
- 그래서 마음을 관리하는 나만의 방법이 있으면 좋다
또한 안되는 것을 생각하는 것보다, 긍정적으로 생각해서 발전하려는 방향으로 생각하는 사람이 일을 잘한다고 느꼈다
- 안 된다라고 말하는 것보다 오 이렇게 해볼까요? 이런 방향? 또는 어려울 수 있지만 고민해보고 말씀드릴게요! 하면서 조금이라도 나아가는 방향으로 가는 사람이 좋았다
- 남탓할 시간에 뭘 해야할지 고민하는 것이 핵심
운동도 좋고, 요가, 명상 등 다양한 방법이 있는데 나에게 맞는 마음 관리 방법을 찾으면 좋겠다

기록

일을 잘하는 사람은 기록도 잘한다. 단순히 내용을 모두 다 기록하는 것만 해당되는 것이 아니고, 방대한 내용에서 핵심만 요약해서 정리하는 능력이 있는 사람이다
- 핵심을 정리하고, 그것을 다른 사람에게 잘 전달할 수 있다
이걸 잘 하려면 일단 기록을 많이 해야한다. 기록을 많이 하면서 이 기록의 핵심은 뭐지? 어떻게 정리해야 하지? 어떻게 전달하지? 고민하면 된다
신입 시절에 매일 업무 일지를 쓰면서 뭘 해야하고, 어떤 것은 늦어지고 있는지 파악했다
- 업무 일지는 TODO 느낌으로 쓰기도 하고, 회사의 문서 시스템에 기록하기도 했다. 중복으로 기록하는 것보단 하나에만 기록을 하는 것이 좋았다
회의록 기록도 비슷한데, 회의를 할 때 항상 핵심을 기록하며 회의에 참여했다. PM이나 회의를 기록하는 사람이 있어도, 내 방식으로 정리하고 누군가 정리했을 때 내 관점에서 빠진 것이 있으면 같이 채워주곤 했다.
- AI가 발전해서 기록을 잘 해주는 서비스가 나오고 있지만, 그럼에도 불구하고 내가 잘 정리하는 능력이 필요하다고 생각해서 나는 이 부분은 계속 진행하고 있다. AI는 보조적으로 쓰는 용도라 생각한다
회의를 주도해야 하는 경우에 사전에 생각할 부분을 기록하고, 참여자들에게 공유하고, 그 부분을 토대로 이야기를 하는 것도 일을 잘하는 사람의 특징이였다. 이것은 기록과 커뮤니케이션이 모두 발현된 케이스였던 것 같다
기록을 많이 하다보면, 나의 프로세스까지 기록을 할 수 있게 된다. 그럼 그것을 토대로 프로세스 시각화까지 하면 업무의 흐름까지 알 수 있어 좋다
더 나중에는 이 기록이 나의 원칙이 된다. 나의 기준이 생길수록 단단하게 업무를 할 수 있게 되었다

정리

일단 떠오르는 것들을 하나씩 작성했는데, 시간이 지나면서 또 다른 요소가 생각날 것 같다.
생각날 때마다 기록해야지
- 신입 시절에 내게 오는 다양한 피드백을 기록하고 그것을 발전시킨 것이 큰 도움이 되었다. 누군가 나에게 이야기하는 것을 공격이라고 생각하지 않고 피드백으로 받아보면서(감정적으로 받아들이지 말고) 개선하니까 그게 쌓여서 내 특징이 되었다
이런 특징을 만들기 위해서는 어떤 것을 해야 할까? 관점에서 내용을 추가하는 것도 좋을 것 같다. 이후의 내가 쓰길 바라며..!

글또 1~10기. 7년의 커뮤니티 운영 회고

Sun, 30 Mar 2025 00:00:00 +0000

이 글은 개발자 글쓰기 모임 - 글또를 7년 동안 운영하며 배운 것을 회고하기 위한 목적으로 작성했습니다
키워드 : 글또, 글또 회고, 커뮤니티 운영

글또 소개

글또는 2018년 1월 3일에 만든 개발자 글쓰기 커뮤니티
- 글또의 풀 네임은 “글 쓰는 또라이가 세상을 바꾼다”로, 페이스북 그룹의 “얼또(얼리 또라이가 세상을 바꾼다)”의 이름에 영감을 받고, 운영자이신 미정님에게 허락을 구하고 사용했다
기본적인 규칙은 예치금을 납부하고, 2주에 글을 1번씩 제출하는 것
- 중간에 쉬어가기 위한 패스는 2번 주어졌다
- 활동 기간은 6달
- 2주에 1개씩 작성하면 총 12개의 글을 작성하게 된다
2025년 3월 기준 총 약 1,000명이 참여했다
10기 기준 글쓰기, 글쓰기 세미나, 커피챗/모각글, 큐레이션, 소모임, 100명 규모의 오프라인 모임, 대나무숲 등의 활동들이 존재
- 더 자세한 내용은 글또 웹페이지에 작성된 글또 소개 참고
글또의 기수별 참여자 수는 아래 그래프를 보면 확인할 수 있다
- 1기를 13명으로 시작해서, 10기는 639명까지 확장했다. 4900% 성장을 이룬셈
- 매번 전 기수 대비 인원이 최소 30%씩 증가했고, 참여자의 평균 40%는 다음 기수를 연장했음(6개월 뒤 리텐션 40%)

글또를 만들고 계속 운영한 계기

처음엔 주변 지인들이 개발 블로그를 쓰고 싶은데, 어렵다고 이야기를 들었다. 하고 싶지만 의지가 잘 생기지 않는다는 이야기를 들었고, 주변 지인들을 돕기 위해 모임을 만들기 시작했다
손실 회피 성향 + 사회적 지지 + 책임감을 기반으로 한 모임 생성
- 손실 회피 성향을 자극하기 위해 예치금을 걷었고, 다른 사람들과 글쓰기를 약속하면 사회적 지직와 책임감이 생겨 글을 쓰게 될 것이라 생각했다
기수가 지나면서 개인적인 관점에서 인생의 깨달음이 생기고, 많은 분들이 좋은 길로 나아가길 바라면서 책임감에 커뮤니티를 꾸준히 운영했다

시간의 흐름에 따른 글또의 성장과 변화

지금 돌이켜 생각하면 초기 / 중기 / 후기로 볼 수 있다. 대부분의 변화는 후기에 많이 있다
초기에 글또를 참여한 분이 10기에 다시 참여하셨는데, 천지 개벽 수준이라고 말하셨다. 내가 생각해도 천지 개벽 수준이다. 많은 것들을 시도했고, 많은 문화를 만들었다. 시간이 걸린 일이다
과거에 작성한 글또 회고 글도 지금 다시 보면 참 재미있고, 과거의 내 생각을 다시 볼 수 있어 재밌다

1기-3기 : 글또의 초기

1기
- 2018년 2월 ~ 7월
- 글또 1기(13명) 참여
- 페이스북 그룹에서 활동
- OT를 하면서 오프라인으로 모여서 이야기를 나눴던 기억이 있다. 이 과정에서 메일로 내용을 취합
- 이 시기엔 글쓰기에 집중했던 시기라 커뮤니티라고 할 요소는 적었다. 자신의 글을 블로그에 작성하고, 페이스북 그룹에 글을 올린다
- 이 방법은 소수 인원일 때는 괜찮으나, 페이스북 알고리즘에 영향을 받고, 서로 글을 확인하는 것이 불편했다
2기
- 2018년 11월 ~ 2019년 5월
- 글또 2기(25명) 참여
- 슬랙에서 활동
- 수동 글 리뷰어 배정
- 직무 별로 퍼실리테이터를 두고, 퍼실리테이터분들이 대화를 자연스럽게 진행할 수 있도록 했다(Thanks to 권혁우님, 민지연님, 이종호님)
- Write the Docs Seoul : 글쓰는 개발자 모임, 글또 발표
  - 이 때 작성했던 발표 자료를 봤는데, 내가 잊고 살았던 것도 있고 계속 간직했던 것도 있다. 꾸준함엔 힘이 있다
  - 평소에 기록을 해두고, 발표를 하면 나중에 먼 훗날 돌이켜 볼 때 도움이 된다. 그래서 글을 작성한다
- 마이크로소프트웨어 396호에 “개발자 글쓰기 모임, 글또” 투고
3기
- 2019년 7월 ~ 12월
- 총 4명의 운영진(Thanks to 고석진님, 이동규님, 이보라님, 전인아님)
- 글또 3기(44명) 참여
- 슬랙에서 활동
- 슬랙에서 글 제출을 확인하고 리뷰어를 확인해주는 자동화 코드 개발(지니)
- 글 리뷰어 자동 배정 시스템 개발(Thanks to 지찬규님)
- 데이터야놀자 2019 발표 컨설팅
  - 정민정님의 Gan을 활용한, 내 손글씨를 따라쓰는 인공지능
  - 이창현님의 타다(TADA) 서비스의 데이터 웨어하우스 : 태초부터 현재까지
- 마이크로소프트웨어(IT 잡지) 399호에 “글또의 자동화 요정, 지니 프로젝트” 투고

4기-6기 : 글또의 중기

이 시기는 코로나로 인해 오프라인 모임이 어려웠던 시기였다. 그런 반면 사람들이 모임에 대한 욕구가 늘어났고, 참여자들은 많아졌는데 어떻게 해야 좋을지를 고민했던 시기
- 회사 업무도 많았던 시기라 회사 업무에 집중했다. 커뮤니티 관점에서는 천천히 발전했다
- 5기 때부터는 참여자보단 운영자 역할에 집중했다(그러다가 10기에 다시 참여자로 복귀)
맥북을 보다가 OT 자료를 다시 봤다. 초기에 OT 자료는 30~60쪽이였다. 10기 OT 자료는 159쪽인데, 예전 OT 자료와 지금 OT 자료를 보면 나 또한 의견을 전달하는 능력이 많이 달라졌다는 것을 느낄 수 있고, 커뮤니티에 대한 고민을 정말 많이 했다는 것이 느껴진다. 참 격세지감을 느낀다. 어렸을 때의 나는 이렇게 했구나

4기
- 2020년 3월 ~ 8월
- 총 11명의 운영진(Thanks to 고석진님, 구유림님, 김지훈님, 류지환님, 마광휘님, 이상협님, 이종진님, 이창현님, 전인아님, 정민정님, 지찬규님)
- 글또 로고 제작(Thanks to 김나영님)
- 글또 4기(69명) 참여
- 신입 멘토링 진행
5기
- 2020년 11월 ~ 2021년 5월
- 5, 6기 때는 운영진을 모집하지 않고 필요할 때만 도움을 구했다. 코로나 시기였고, 회사에서 업무가 너무 많았다. 회사 일도 너무 재밌어서 열심히 했다. 모빌리티 업계에서 데이터 분석, 데이터 엔지니어링, 머신러닝을 모두 할 수 있다는 것은 다시 생각해도 너무 즐거운 경험이다. 게다가 쏘카/타다의 비즈니스 모델이 달라서 데이터를 활용하는 방식이 다른데, 둘 다 경험할 수 있는 점은 다시 생각해도 감사하다. 운이 좋았다
- 글또 5기(94명) 참여
- 고민있어요 채널 생성 : Anonymous Bot 활용
- 온라인 모임 2회
- 팀별 온라인 회고
- 신입 멘토링 진행
- 쉼에 대한 이야기 : 쉼퍼런스 진행
- 회고 모음집 제작
6기
- 6기 때는 과거에 했던 것들을 반복했다. 무언가 새로운 것을 하진 않고, 지금 인원을 유지한 상태로 진행했다
- 슬랙을 들어가서 채널을 보는데 이 때 운영진 채널이 없다. 이 시기에 운영진 없이 진행했나? 이건 기억이 희미해졌다. 6기까지는 별도로 운영진 회의록 템플릿이 없었다
- 2021년 8월 ~ 2022년 1월
- 글또 6기(132명) 참여
- 기억나는 것은 6기 때 굿즈를 처음 제작했다. 이 때 처음 굿즈를 만들었고, 이 당시에 작업실에 물건 받아서 손수 포장해서 보냈던 기억이 있다. 가내 수공업을 하면서 보내는 것은 정말 어렵구나를 느꼈다
- 가운데에 있는 글또 키링이 제일 비쌌던 기억이 있다. 그래도 받은 분들이 좋아했던 기억이 난다.

2기 ~ 6기 슬랙 채널

생성되는 모든 퍼블릭 채널에서 어떤 이야기를 하시나 보곤 했는데, 시간이 지나니 이런 것들도 있구나..! 다시 상기할 수 있다
2~6기의 슬랙 채널만 봐도 어떤 일이 있었는지 유추할 수 있다
점점 커뮤니티로 커지는 것이 느껴진다
초기, 중기 땐 나도 인간적으로 덜 성숙(?)했고 일단 하면서 개선했던 것 같다. 지금 생각해보면 초기, 중기 때는 나도 20대였다. 많은 경험을 하고, 책도 읽고 그러면서 발전한 내 생각이 글또에도 반영된 것 같다

7기 : 글또의 후기 시작, 마치 르네상스

이 시기부터 큰 변화의 시작이 보였다. 참여하는 분들이 100명이 넘어가면서 고민해야 할 부분이 많아졌고, 서로 더 많이 교류할 수 있도록 도와주는 것이 필요했다
- 개인적으론 이 시기엔 퇴사를 앞두고 있었다. 퇴사 전에 할 일들이 참 많았고, 커뮤니티 일도 많았다
- 7기를 대비하기 위해 습관 형성에 대한 논문, 서적들을 학습했고, 조직을 어떻게 꾸릴 것인가에 대한 것도 고민했다
- 사실 이 시기부터 후기가 아니라 중기로 봐야하나? 싶은데 일단 후기로 작성해본다.
2022년 5월 ~ 2022년 10월
글또 7기(182명) 참여
- 운영진 8명(Thanks to 김정희님, 김진환님, 박상오님, 이민경님, 이상협님, 이찬주님, 정종윤님, 조동민님)
- 이 시기부터 운영진 활동을 더 구체화했다. 어떻게 해야 운영진분들도 동기부여를 잘 받을 수 있을까?를 고민했다
익명 슬랙 메세지 전송을 위한 대나무숲 봇 개발(Thanks to 정종윤님)
- 종윤님의 개발 과정 글
같은 직군별 커피챗
글또 내부 컨퍼런스 (글또콘)
- 글또콘 발표 자료

운영진 활동의 체계화

과거 기수엔 운영진이 있었어도 체계적이지 않았다. 왜 체계적이지 않았는가 생각해보면 나 또한 체계적으로 일을 한다는 것에 대해 경험이 없었기 때문이다. 쏘카에서 팀 리드, 디렉터 역할을 하면서 조직의 문서 작성, 체계적인 구조, 어떻게 상호 협력할 것인가 등을 고민했던 부분이 크게 도움이 되었다
쏘카의 경험을 기반으로 운영진 활동 또한 개편했고, 매 기수 구조적인 변화를 조금씩 만들었다
- 이 때 Ground Rule을 만들고, 이걸 계속 활용했다
- 대표적인 Ground Rule은 다음과 같다
  - 운영진 내에서 모이면 노션에 기록을 남긴다(템플릿 2-3개가 제공)
  - 운영진 내에서 만들어지는 설문, 발표 자료 등은 하나의 구글 드라이브에 저장한다
  - 너무 열심히 하지 말기. 많은 것을 동시에 하려고 하지 않는다. 딱 1가지만 해보기. 회사 일에 집중하면서 시간이 날 때 글또 운영진 활동을 한다
    - 만약 동시에 많은 것을 하려고 하면, 성윤이 이를 억제할 수 있음
    - 내가 제일 중요하게 생각한 관점인데, 너무 열심히 하면 반발심으로 번아웃이 심하게 올 수 있다고 생각했다. 그래서 역설적이지만 너무 열심히 하지 말라고 이야기해왔다. 이건 나에게도 하는 말이다
  - 글또 운영진 활동을 하면서 “즐겁게” 하고 있나 생각해보기. 즐겁게 하고 있지 않다면 잘못되고 있다고 생각하기. 즐겁게 하면서 활동하는 것이 우리의 핵심
  - 인생에서 갑자기 힘든 일이 생길 수 있고, 그 시기에 무리하게 일을 하지 말고 사람들에게 자신의 상황을 공유하고 회복하는 것에 집중하기
  - 언제든 고민이 있다면 성윤에게 DM하기. 무엇이어도 좋으니 고민을 들을게요
  - 당연한 것처럼 보이지만, 막상 상황이 되면 당연하지 않기에 항상 강조했고, 안전하다는 것을 알려주고 싶었다
커뮤니티의 비전을 이 때 다시 잡았다. 결국 글또를 통해 내가 전하고 싶은 가치가 무엇인가? 계속 생각했고, 마침내 다음과 같은 문장을 작성할 수 있었다
- 글을 작성하는 개발 직군분들이 모여서, 좋은 영향을 주고 서로 같이 자랄 수 있는 커뮤니티
운영진 전체 모임은 1~2달에 1번만 진행하고 모였을 땐 일 이야기는 후딱 끝내고(?) 같이 대화를 하거나 즐거운 경험을 하도록 하려고 했다. 회사처럼 일 이야기만 하는 회의를 안하고 싶었다(근데 나중에는 나보다 다른 분들이 글또 운영에 대한 이야기를 더 많이 하자고 하셔서 그렇게 했었다)

대나무숲

살다보면 고민이 생긴다. 아 이거 어떻게 해야할까? 모르겠다 싶은 그런 고민
- 이런 고민들을 어딘가 나눌 공간이 있으면 좋지 않을까?란 생각을 했고, 글또 내에서 만들었다
- 기존엔 만들어진 앱을 사용하다가 종윤님이 대나무숲을 만들어 주셨다
  - 임금님 귀는 당나귀 귀! 대나무숲 슬랙 앱 만들기
- 익명 채널은 항상 트레이드 오프가 있다. 사람들이 일반적으로 아는 익명 채널처럼 쓰면 점점 처음 의도와 변질될 의도가 있다
- 그래서 처음에 명확하게 대나무숲을 어떻게 써야 하는지 가이드를 드렸다
  - 욕이나 반말은 불가능
  - 다른 사람을 공격하는 말투는 이유 고지 후 삭제
이렇게 운영하니까, 따뜻한 익명 채널이 되었다
- 실제로 많은 고민들을 나누고, 익명이 아니라 실명으로 댓글을 다는 분도 생기고, 그러다가 커피챗도 하는 경우가 있었다
대나무숲에 글을 작성한 사람을 로깅할 것인가에 대한 문제도 논의했는데, 이걸 로깅하는 것 자체가 불안함이 생길 수 있다고 생각해서 구성원들을 믿고 로깅을 하지 않았다. 지금까지 문제가 된 케이스는 거의 없다.
많은 분들이 대나무숲에서 공감을 얻는다고 말하셨다. 따뜻한 공간을 만들기 위해 익명 채널을 만들고, 잘 운영하는 것이 핵심이였다
나는 항상 실명으로 남기곤 했는데, 사실 나도 익명으로 올린 적이 있다
- 그냥 샴푸를 사야하는데 탈모용 샴푸가 있나 싶어 물어봤다(사실 저 탈모 없는데 이거 올리려고 10기 때 올려봄)

10기 때 성장에 대해 고민이 있다는 글에 작성한 댓글

오프라인 모임

코로나가 끝나가서, 다 같이 모여보자!라는 생각을 가지며 오프라인 모임인 글또콘을 준비했다
컬리에서 준비했는데, 그 때 참 잘 준비해주셔서 잘 수행했다. 그리고 10기 데이터 반상회 때 다시 컬리를 찾아서 반가웠다
글또콘에 다녀온 직후에 작성한 글

굿즈

6기 때 굿즈 만들 때 고생해서(?) 이번엔 좀 더 편하게 만들고 싶었다
운영진이신 김진환님께서 도움을 주셔서 만들 수 있었다
- 풀 패키지로 만들었는데, 그 이후엔 이렇게 만들지 못해서 아쉽다
- 비용이 많이 드는데, 인원이 많아져서 감당하기 어렵다고 판단했다
- 굿즈를 만드는 운영진이 계속 있어야 하는데, 암묵지가 개인에게 귀속될 경우에 대대손손 유지가 되지 않는다. 나도 어느정도 알고 있었지만, 더 체계화를 해야겠다고 다짐했던 시기
- 만약 다시 한다면 연예인 팬클럽처럼 가입 후에 제작해서 전달하면 좋을 것 같다. 굿즈는 소속감을 줄 수 있는 매개체다
- 진환님이 작성해주신 글또 7기 굿즈 제작기

8기

2023년 2월 ~ 23년 7월
글또 8기(336명) 참여
- 18명의 운영진(Thanks to 강나영님, 김동인님, 김은찬님, 김재휘님, 김정희님, 류지환님, 송현주님, 오원종님, 이수현님, 이찬주님, 임지영님, 임지훈님, 정종윤님, 정현수님, 조슬지님, 채정현님, 최현구님)
글 제출을 편하게 진행하기 위한 또봇 개발(Thanks to 김은찬님)
커피챗과 피드백을 합친 커피드백 시도
제출한 글을 큐레이션하는 큐레이션 시작
- 큐레이션 모음
글또의 세계관 재구축 : 빌리지 / 코어
오프라인 모임인 반상회 진행
- 빌리지 반상회 발표 자료
글쓰기 교육 진행

지원 방식의 개선

신규 지원을 할 때, 삶의 지도라는 것을 받았다
- 자신이 살아온 과정을 작성하는 미션으로 자신에 대해 생각해보는 기회를 드리고 싶었다
- 참고로 이 과정에서 잘 작성했다, 잘 작성하지 못했다란 가치 판단은 하지 않고 주어진 기준 이상으로 작성했는지를 봤다. 주어진 요구 조건을 명확히 지키는가? 작성된 내용을 지킨 분들만 합격을 드렸다
  - 불합격은 대부분 글자수를 미달하거나, 완성하지 못했거나, 권한을 풀지 않은 경우 발생했다.
- 불합격을 많이 드리는 것이 내게 불편한 마음이였다. 그래서 나는 최대한 기회를 드리고 싶었다. 불합격이 많은 요즘 시대에 내가 합격을 드려서, 참여자분들의 자존감에 조금이나마 도움이 되면 좋지 않을까? 라는 생각을 했다. 그럼에도 불구하고 기준은 명확히 설정해서 그 기준을 지켰다. 그 기준을 통과하지 못한 분들에게 불합격 메일을 보내는 것은 여전히 내게 힘든 기억이다. 인원이 많아질수록 이 괴로운 경험이 커진다.
- 운영진분들에게 공유드린 삶의 지도 합격과 불합격의 기준

만약 이 과정을 추가하지 않았다면 글또 10기는 사람이 더 많았을 수 있다. 그러나 단순히 양적 성장이 아닌, 글또라는 커뮤니티에 들어오기 위해 노력을 하는 분들을 모시고 싶었다.
참고로 지원하는 분들에겐 아래 내용을 전달했다. 이 글을 꼭 보고 지원해달라고 설문에도 추가했는데, 1,000자를 작성하지 않은 분들도 있었다(1,000자는 생각보다 짧은 글)

운영진 활동

운영진도 많아지면서, 커뮤니티에서 내가 누구를 케어해야 할까? 생각하면 운영진이라고 생각했다. 운영진분들이 나아가서 더 많은 분들에게 도움을 줄 것이라 생각했다
커뮤니티를 오래 운영하면서 느낀 점은 자발적으로 돕는 선한 의도가 있어도 장기적으로 가는 것이 참 어렵다. 그리고 열심히 하겠다고 했다가 못했을 때 머쓱해지는 것이 있고, 그래서 더 나타나지 않는 경우가 있다. 이 머쓱함을 모르는 사람들은 그냥 활동을 안했다고 생각하는 경우가 있다. 나는 이런 상황이 건전하지 않다고 생각했고, 누구나 힘들 수 있고 그런 시기를 말해도 문제가 안되도록 운영진을 꾸리고 싶었다
- 운영진 OT에서 당부한 이야기
- 위에 7기 그라운드 룰과 맥락은 같지만, 더 잘 전달하려고 했다

아, 그리고 9기 운영진 MT도 다녀왔고, 마지막엔 다 같이 사진도 찍었다. 이것도 다 추억이니 남겨둔다(혹시 자신의 얼굴을 가리고 싶은 분이 있다면 연락주셔요)

세계관 재구축

기존에는 글또의 세계관이라는 것이 따로 없었고, 채널을 구분하는 prefix(1_, 2_, 3_ 이런 느낌)만 있었다. 그러나 사람들이 더 많아지면서 각각의 prefix에도 의미를 부여해야 더 이해하기 쉽다고 생각했다
- 글또는 여러 사람들이 참여하는 큰 공동체라 생각했고, 각 공동체는 직무 별로 마을이 있다고 생각했다. 그래서 빌리지 채널을 만들었고, 이 빌리지는 같은 직무가 있는 채널이다.
  - 그리고 빌리지 내에 코어 채널이 있다. 코어 채널은 7~10명 정도 되는 인원이 같이 있고, 글을 제출하는 공간이다
- 코어 채널에서 서로 글을 조금씩 보고, 빌리지 채널로 확장되길 바라는 마음으로 지었다
직무 별 오프라인 모임은 빌리지의 모임이기에 빌리지 반상회라고 지었다. 반상회라고 하면 요즘은 잘 안하지만, 아파트에서 반상회를 진행하는 것을 상상하며 서로 안건에 대해 이야기도 하고, 어떻게 지내나, 음식도 나눠 먹고 등을 생각하면서 지었다
소모임 채널(4_)은 소모임 채널이라고 정의했다. 이후 10기 때 소모임 채널도 의미를 더 부여했다
아래는 빌리지 반상회 소개 글. 운영진이 다 진행하는 것이 아니라 반상회 준비위를 새로 꾸려서 진행했다

봇의 진화

개인적으로 8기 때 “또봇”의 탄생이 많은 사람들이 편해지고, 할 수 있는 것들이 많아졌다. 은찬님이 참 감사하다
그 전에는 글을 작성한 후, 슬랙에 전송한 후에 제출 이모지를 누르면 제출 이모지 여부에 따라 글 제출을 확인했다
- 그러나 봇이 생기면서 아예 또봇을 통해 글을 제출할 수 있고, 데이터를 더 잘 관리할 수 있게 되었다
처음엔 글 제출 기능만 있었는데 10기 때는 더 많은 기능을 담당하고, 앞단에서 데이터를 저장하는 역할도 하고 있다
- 글또에 참여하는 분들이 봇을 보면 참 신기하게 생각하는데, 그 중에 대표적인 친구가 또봇이다. 또봇 스티커도 만들어서 오프라인 모임 때 공유하고 있다
또봇에 대한 내용은 은찬님의 글을 공유
- 개발자 글쓰기 커뮤니티는 ‘슬랙 봇’을 어떻게 사용하고 있을까?
- 카테고리 수집하려다 슬랙 봇까지 개발해버린 건에 대하여…
대표적으로 할 수 있는 글 제출 과정은 아래와 같다

또한 생일 축하 봇도 만들었다
- 생일이란 것을 중요하게 생각하는 사람이라, 생일 축하를 해왔다.
- 기존에는 생일이 기록된 시트에서 보고 수작업으로 했으나, 재휘님이 운영진 채널에 하루에 1번씩 메시지가 오도록 해줬다
- 그걸 보고 생일 명단을 확인하고, 채널에 공유한다. 생일 짤도 한 30개 정도 저장되어 있다.
- 이렇게 생일 축하하는 과정을 통해 따뜻함이 전해지길 바랐다. 우연히 만난 것이 아니니까
- Apps Script를 사용해 구현했다. 아래는 운영진 채널에 도착하는 내용. 운영진 두분이 생일이셔서 운영진끼리 생일 축하도 하고, 다른 채널에도 공유했다

글쓰기 교육

커뮤니티를 5년 정도 운영하니 사람들이 겪는 반복적인 패턴이 보였고, 그 패턴들은 과거의 나도 경험했던 요소였다. 그래서 이걸 어떻게 도움을 드릴까? 고민하다가 내가 글을 어떻게 작성하는지, 많이 겪는 고충들을 공유했다
- 이 때 진행한 내용을 토대로 10기 할 때 인프런에 강의를 출시했다. 블로그 페이지뷰 300만이 알려주는 “실용주의 기술 블로그 글쓰기”
- 좋은 글을 쓴다는 것은 하루 아침에 되지 않는다. 꾸준함이 수반되어야 하고, 좋은 글을 하나만 쓰는 것이 아니라 꾸준히 쓰면서 점점 글의 역량이 올라가야 한다
  - 그와 더불어서 SEO도 챙기는 것이 필요한데, SEO에 대해 많은 분들이 모른다. 그냥 글만 쓰고 누군가 내 글을 찾아주면 좋겠다고 생각한다. 물론 검색 엔진이 잘 색인해주면 좋겠지만, 블로그 운영 초반일 때는 SEO에 대한 전략도 가지고 있으면 좋다
- 포트폴리오로 활용하고 싶은데 글을 잘 작성하지 못하는 분들이 종종 조급해 하는 경우가 있는데, 처음부터 다 잘하려는 것보다 점진적으로 가면 된다고 말씀드렸다
- 글을 작성하거나, 어떤 일을 할 때 대부분 마음가짐, 멘탈 관리가 중요하다
- 이 내용을 나중에 데보션에서 강의했었다
이 강의를 처음에 하지 않고, 3회차 제출 후에 진행했다.
- 이렇게 한 이유는 강의를 처음에 들으면 “당연한 것 아니야?”라고 생각할 수 있기 때문이다. 대부분 그렇다. 근데 막상 하면 힘들다
- 그래서 애초에 3번 글을 쓰면서 글쓰기가 좀 어렵구나라는 것을 인지하고 => 그 때 이야기를 하는 것이 효과적이라 생각했다
- 문제 상황을 겪기 전까지는 공감하지 못할 수 있다고 생각해서 일부러 이런 방식으로 강의를 진행했다
많은 분들이 언급하는 글쓰기의 어려움은 아래와 같다. 강의 내용 중 일부다. 글또에 오래 참여하신 분들은 이 어려움에 대해서는 이제 얼추 해결된 것 같다

9기

2023년 11월 ~ 2024년 5월
글또 9기(452명)
- 25명의 운영진(Thanks to 강나영님, 강승현님, 김은찬님, 김재휘님, 김정희님, 김준홍님, 류지환님, 박수민님, 배지훈님, 성연찬님, 송경근님, 송민혜님, 신해나라님, 이찬주님, 임정님, 임지훈님, 정이태님, 정종윤님, 정현수님, 조동민님, 조재우님, 지정수님, 채정현님, 최현구님)
- 4명의 커뮤니티 매니저(강나영님, 김정희님, 조동민님, 채정현님) : 운영진들의 활동을 즐겁게 하려면 어떻게 해야할까?를 고민하는 파트

봇, 시스템 개발

데이터 파이프라인 구축(To BigQuery)
- 또봇은 데이터를 스프레드시트로 저장하는데, 참여자들의 유저 로그(슬랙 데이터)를 분석하는 것이 좋다고 판단했다. 그래서 슬랙의 Export 기능을 사용해 BigQuery로 데이터를 추출했다
- 그러나 슬랙 데이터의 문제는 이모지 데이터에 있다. 이모지를 언제 했는지에 대한 시간 데이터는 없고, 추출을 시도할 때 최신의 상태만 제공한다. 스냅샷 데이터라고 볼 수 있다
  - 스냅샷이여도 사용할 수 있기 때문에, BigQuery에 적재해서 글또의 핵심 지표를 확인했다
CRM Push 메세지 봇 데달부 개발
- 위 데이터 파이프라인이 구축되었으니, 사람들에게 가치를 제공해줄 수 있다고 생각했다
- 글또에서 활동을 얼마나 했는지 보여주면 좋겠다는 생각을 했고, 실시간은 아니지만 주기적으로 메시지를 전달해도 좋을 것 같았다. 그래서 운영진분들이 개발을 해주셨고, 사람들에게 그동안 활동을 정리해서 공유했다
- 이 부분은 9기에 실험적으로 시도해서, 10기에도 진행했다
운영 자동화를 위한 글팽이 개발
- 사람이 많아지면 간단하게 사람을 태그하는 것도 일이다. 운영진의 수도 많아져서 하나씩 다 체크하는 것이 어려웠다
- 슬랙의 메시지에 이모지를 안한 사람을 자동으로 태그하는 운영 유틸성 봇인 글팽이을 만들었다
제출 글을 확인해주는 글빼미 개발
- 글또는 1,000자 이상의 글을 작성해야 하는 기준이 있다. 그러나 글을 제출할 때 보면 글자수가 800자인 경우도 존재한다. 이럴 경우엔 제출 글로 인정하지 못한다.
- 건수가 많진 않지만, 직접 해왔는데 운영의 부담으로 다가왔다. 그래서 이를 해결하기 위해 제출된 글을 보고 글자수를 확인하는 글빼미가 개발되었다
- 이어져서 글빼미는 밑에 나오는 LLM 기반 큐레이션과 합쳐져서 LLM 기반 글 피드백 시스템으로 진화한다
LLM 기반 큐레이션
- 참여자가 450명이 넘어간다는 것은 2주에 제출되는 글이 최소 400개는 된다는 말이다. 이걸 큐레이션 크루분들이 다 보면서 확인하기엔 시간이 많이 걸린다
- 이것도 운영의 이슈기 때문에 LLM을 사용해 자동화를 진행했다. 제출된 글들을 점수화해서 기준에 맞는 것들 위주로 글을 보고 큐레이션을 진행했다
- 큐레이션 과정은 아래 글에 자세히 나와있다
  - 큐레이션은 어떻게 이루어질까요?
글또 웹페이지 제작
- 기존엔 내 노션을 사용해서 글또 소식을 알렸는데, 글또의 웹페이지를 만들었다
- 9기 중후반에 만들었고, 이걸 기반으로 10기 때는 글또에서 진행되는 여러 내용을 블로그로 남겨두고 싶었다. 글로 남겨두면 운영진분들은 자신의 경험이 되고, 참여자분들에겐 추억으로 남을 수 있을 것이라 믿었다
그 외에도 사람들의 인터랙션을 그래프 관점으로 봤다. 그래프를 집계하면 Tabular가 되지만, 그래프로 시각화하는 것이 꽤 괜찮다는 것을 느꼈다
봇, 시스템 개발에선 운영진분들이 거의 다 구현을 해주셨다. 나는 방향성이나 의사결정을 해야하는 것들 위주로 정리했다. 이렇게 봇, 시스템이 발전하는 것은 나에게도 영감을 주었고, 글또 참여자분들에게도 영감을 주었다(매 기수 OT 때마다 봇의 기능이 확장되기에)
봇의 세계관

사람들의 연결

글또의 제일 핵심 목표는 글을 잘 작성하는 것이다. 두번째 목표는 사람들과 연결되는 것. 어떻게 해야 연결을 더 잘 시켜줄 수 있을까?를 고민했다
같은 직무 내 랜덤 커피챗
- 글또는 자유롭게 커피챗을 하고 인증하는 문화가 존재한다. 많은 분들이 커피챗을 자발적으로 하고, 커피챗을 모집하기도 한다. 처음이 어렵지만, 그 이후엔 자주 참여하는 패턴을 보인다
- 이 자율 커피챗도 잘 동작하지만, 커피챗 참여가 주저되는 것도 사실이다. 그래서 글또에서 랜덤 커피챗을 매칭한다. 이 때 제일 어려운 것은 조편성이다
- 거리, 연차, 주제 등 다양한 요구 사항이 있다. 이 때 모든 요구 조건을 다 수용하는 것은 어려워서 연차나 소재 위주로 조를 나눴다
직무 별 오프라인 빌리지 반상회
- 오프라인 반상회 프로세스가 구체화가 되었고, 이 프로세스를 기반으로 10회 넘는 행사를 진행했다
- 이제 100~150명 규모의 행사는 쉽게 운영할 수 있다. 제일 어려운 것은 장소 섭외다. 장소만 잘 섭외되면 그 이후는 컨셉 회의, 우리가 행사에서 바라는 것을 기반으로 확장할 수 있다
- 커뮤니티의 행사에 도움이 되길 바라는 마음에 프로세스를 공유
  - 글또 오프라인 모임 프로세스 템플릿

그 외에도 Activation 크루에서 글또하우스라는 이름으로 사람들과 고민 상담소를 진행했다. 처음엔 나는 조금만 참여하면서 살짝 살짝 관여했다. 모두 다 내가 관여한다면 스스로 하는 것이 줄어들 수 있기 때문에(내가 이야기를 하면 그 결정으로 갈 확률이 높기에) 자율성을 드리기 위해 적당히 관여했다
회고 소규모 모임도 했던 것이 떠오른다. 소규모 모임이여도 작은 모임이 점점 더 커질 수 있다고 믿기 때문에 어떤 것이여도 괜찮다고 운영진분들에게 계속 말했던 기억이 난다

회사들과 협업

회사들과 협업도 늘어났다. 열심히 사는 사람들이 모인 커뮤니티라서 교육이나 책 관련 후원이 많았다
유데미에서 강의를 제공해주셨고, 코딩 테스트 플랫폼인 코드트리에서 체험권을 제공해주셨다
그 외에도 빌리지 반상회를 위해 다양한 기업들이 공간을 빌려주셨다
- 채널톡, 우아한형제들, 팀 스파르타, 잡플래닛 담당자분들 모두 감사합니다

10기

2024년 9월 ~ 2025년 3월
글또 10기(639명)
- 34명의 운영진(Thanks to 강나영님, 강승현님, 곽승예님, 곽희진님, 금정민님, 김은찬님, 김재휘님, 김정희님, 김준성님, 김해인님, 류지환님, 박건희님, 박수민님, 배지훈님, 성연찬님, 송경근님, 송민혜님, 이용선님, 이찬주님, 이호동님, 임정님, 임지훈님, 전희선님, 정윤영님, 정이태님, 정종윤님, 정현수님, 조동민님, 조재우님, 지정수님, 채정현님, 최태영님, 최현구님)

운영진 팀(크루) 조직

10기 때 운영진은 목적 조직으로 변화했다. 기존엔 기능 조직스럽게 움직였다면, 이번엔 목적 조직처럼 움직였다
컨텐츠 크루, 커뮤니티 in 커뮤니티 크루는 신설했고 나머지는 기존에 있던 크루였다
- (크루 : 운영진의 팀을 의미)
- 컨텐츠 크루를 만든 것은 웹페이지가 생겼기 때문에, 컨텐츠를 추가하고 싶었다. 기억이 선명하게 남아있게 하고 싶었다
- 커뮤니티 in 커뮤니티 크루는 4채널에 대한 Best Practice를 보여주는 크루다. 4채널을 만든 분들에게 4장님이란 명칭을 부여하고, 어떻게 해야 커뮤니티를 잘 운영할 수 있을지 알려드렸다
  - 운영진에서 운영하는 대표 채널인 다진마늘(목표를 다지자)을 운영했고, 나는 커뮤니티를 어떻게 잘 운영할 수 있을지에 대한 교육을 진행했다
  - 실제로 다진마늘에 참여하신 분들이 이후 글또 활동이 활발해지는 데이터를 확인하고 추후에 다진마늘은 기존 유저의 채널로 만들고, 마늘쫑이라는 신규 멤버를 위한 채널을 만들었다. 마늘쫑에서 신규 멤버들끼리 온보딩을 하고 다진마늘로 보내는 방식이다(다진마늘 채널은 월별로 모집을 하고 있다)
각 크루들의 역할
- 또봇/자동화 크루 : 또봇 고도화 및 자동화 시스템 개발(글팽이, 종이비행기, 포인트 시스템, 생일 알람)
- 모임 크루 : 오프라인 반상회 모임 운영
- CRM 크루 : 글또분들의 참여를 독려하는 메시지 개발
- Activation 크루 : 커뮤니티의 활성화를 위한 Activation 실행. 다 같이 썰매를 타러 가기도 하고, 팟캐스트도 만들어서 배포하고 있다
- 컨텐츠 크루 : 글또의 블로그에 컨텐츠 발행
- 큐레이션 크루 : 글또의 제출 글 큐레이션 운영 및 글 피드백 자동화(글빼미)
- 커뮤니티 in 커뮤니티 크루 : 글또의 소모임(4채널) 활성화를 위한 Best Practice 채널 운영(다진마늘)

크루 외에도 TF 목적으로 어떤 집단이 리텐션이 높은가?라는 질문을 분석하기 위한 프로젝트이글 TF도 있다. 관련 내용은 곧 글또 블로그에 올라갈 예정이다. 어떤 사람들이 많이 활동하는지를 데이터를 통해 알아볼 수 있었다(Thanks to 곽승예님, 김해인님, 송해인님)
10기 운영진 MT도 다녀왔다. 이 나이에 MT라니! 라는 생각도 했는데, 운영진분들이 가자고 하셔서 다녀왔다. 참 고마운 분들이다
- 운영진분들에게 감사를 표하기 위해 글또 로고가 박힌 후드와 NFC 명함을 선물로 드렸다

오리엔테이션

오리엔테이션에 정말 많은 공을 들였다
- OT 때 많은 동기부여를 주는 것이 제일 중요하다고 생각했다. 제품으로 치면 제품의 온보딩으로 볼 수 있다
- 많은 고민을 했고, 일반적인 커뮤니티 소개가 아니라 커뮤니티를 만든 “나”부터 소개를 시작했다. 나의 특성이 뭐고, 내 인생 비전이 무엇이고, 글또도 그 비전을 이루는 과정에서 만들었다는 이야기.
- 그리고 참여자들이 어떻게 되면 좋겠다는 내 바람을 공유하면서, 비전 소개, 핵심 활동 소개
- 활동 소개를 하면서 글또의 다양한 봇들을 소개
- 참여하는 분들이 겪을 수 있는 상황, 마음가짐을 미리 제시하고 어떻게 활동하면 좋을지 활동 지침도 드렸다
- 모든 것의 변화는 누군가 만들지 않고, 자신이 만든다는 메시지도 제시한다. “변화는 다른 사람이 만들어주지 않고 자신이 만듭니다”
- 10기 OT 자료는 159쪽이나 되었다. 1시간 10~20분 정도 진행되지만 단순히 내용 전달이 아니라 스토리를 담은 OT로 만들었다. 실제로 들어보면 사람들의 동기부여가 올라갔다고 들었고, 기수를 연장하는 분들도 지루하지 않도록 내용을 매 기수 바꿨다
10기 OT 자료를 그대로 공유하는 것은 어렵고, 일부를 아래에 붙여본다
- OT에 참여했던 분들은 다시 생각해보는 기회가 되면 좋겠고, 커뮤니티에 관심이 있는 분들에겐 영감이 되길

따뜻함과 유익함 전달하기

커뮤니티가 잘 운영되려면 운영자의 노력이 꽤 필요하다. 필요하지 않다고는 말 못하겠다
- 나는 내가 잘할 수 있는 방식으로 따뜻함과 유익함을 전달하려고 했다
- 나는 다른 사람을 생각해서 메시지를 작성하는 것에 부담을 느끼지 않고, 내용을 보고 정리하면서 내 의견을 정리하는 것을 즐긴다
- 그래서 공지사항 메시지를 꾸준히 작성하고(마감 하루 전의 응원 메시지) 자료를 보고 유익한 자료가 있다면 채널에 공유했다
회사에서도 팀장이나 대표가 모범을 보여야 그걸 따라서 구성원들도 실행한다는 말이 있다. 이 개념처럼 나도 어떤 것을 하는지, 왜 하는지를 공유하고 싶었다
- 근데 다시 봐도 내가 말이 많은 것 같다

봇, 시스템 개발

데이터 수집 역할 : 슬랙 Export -> 또봇이 데이터 수집(Event Driven Architecture)
- 슬랙 봇에서 소켓 모드로 변경하면 슬랙에서 발생하는 모든 이벤트의 데이터를 수집할 수 있다
- 참여자들의 행동 데이터를 수집할 수 있게 되었고, 이런 데이터를 수집해 바로 BigQuery로 보냈다
- 유저의 행동이 발생하면 또봇이 받아서 넘기는 형태
- 정확하지는 않지만 카프카처럼 앞단의 데이터를 받아서 다른 곳으로 넘기는 역할을 했다
- 이 방식이 생겨서 또 여러가지가 가능했다. 밑에 나오는 포인트 시스템도 소켓 모드가 있어서 가능했다
포인트 시스템, 종이비행기
- 은찬님과 구의역 탐탐에서 엄청 이야기를 하면서 설득했던 기억이 난다
- 10기 때 새로운 시스템을 도입하고 싶었다. 나도 즐겁게 커뮤니티를 운영하려면 어떻게 해야할까? 나의 마음이 즐거워야 커뮤니티도 즐겁게 운영할 수 있어서 생각하다가 포인트 시스템과 종이비행기를 생각했다
- 포인트 시스템은 글을 제출할 때 점수를 얻는 시스템이고, 공지사항을 확인하거나 커피챗 인증을 할 때마다 얻을 수 있다
  - 글을 끊기지 않고 연속적으로 글을 작성하면 포인트를 많이 받을 수 있게 된다
  - 또한 특정 시즌엔 포인트 2배 시스템도 진행했다
  - 포인트로 뭘 할 수 있냐?라는 질문도 할 수 있지만 자신의 커뮤니티 내 활동을 이렇게 숫자로 보는 것이 큰 힘이 있다
  - 이걸 위해 게임 기획 책을 보면서 레벨업에 필요한 경험치는 어떻게 산출하나 공부했다. 지수적으로 갈 것인지 로그처럼 할 것인지 등 여러 의사 결정이 있었다. 그리고 그걸 경험하는 사람들이 어떤 감정일지 생각했다
- 종이비행기는 일종의 편지다
  - 슬랙 DM으로도 감사함을 표시할 수 있지만, 슬랙 DM은 내용이 더 쌓이면 흘러가기 마련이다
  - 그래서 누군가에게 감사함을 표시할 수 있는 종이비행기를 만들었다. 슬랙의 계정을 토큰으로 받아 웹페이지에 들어가면 자신에게 받은 종이비행기와 보낸 종이비행기를 확인할 수 있다
  - 따뜻함을 명시적으로 전달하는 매개체로 종이비행기를 사용했다
또봇의 홈 탭
- 공지사항에 :noti-check: 이모지를 남길 경우 포인트, 글 제출시 포인트, 커피챗 인증시 포인트 등 다양하게 설계

종이 비행기

커피챗 인증 과정 고도화

글팽이
- 운영 자동화를 위한 글팽이도 계속 진화했다
- 특정 유저 그룹을 태그하는 기능 : 예를 들어 @운영진_모임 을 하면 해당 사람들을 대신 소환해준다. 이게 유료 기능에선 제공하는 기능인데, 유료기도 하고 추가하는 과정이 편하지 않았다. 그래서 스프레드시트 기반으로 유저를 설정하면, 태그를 해주는 기능을 개발했다
- 최근에는 랜덤 선택 기능도 추가했다. 어떤 활동을 할 때 랜덤으로 뽑고 싶을 때 활용할 수 있다. 모임 참여자를 선택할 때, 카드깡을 할 때(?) 사용한다
- 태그한 후, 쓰레드에 @글팽이 체크 라고 하면 태그 대상 중 이모지를 하지 않은 사람에게 댓글을 달아달라고 한다

모두 반응했다면, 모두 반응했다고 응답한다

글빼미
- 기존엔 작성한 글의 글자수만 확인해주던 글빼미가 글을 피드백을 해주는 능력까지 생겼다
- 종윤님과 지훈님의 협업으로 만들 수 있었다. 이 피드백은 내가 4기 때부터 바랬던 기능인데 10기 때 드디어 꿈이 실현되었다
- 자세한 내용은 다음 두 글에서 확인할 수 있다
  - 🦉 글또의 제출 글 검수 자동화 봇: 글빼미를 소개합니다!
  - 🦉 LLM 기반 블로그 피드백 자동화 : 글빼미의 피드백은 어떻게 이루어질까요
- 참고로 지옥맛 피드백은 정말 칭찬 하나 없다. 무서운 피드백이다..
- 이 글을 제출하고 받은 피드백(매운맛) : 보통 매운맛도 날카롭게 피드백을 하는데 다행히 따뜻했다

지니
- 기존의 데달부에서 이름을 지니로 바꾸었고(과거의 BigQuery 추출 봇이 지니였다) 데이터 파이프라인을 고도화했다
- 스프레드시트의 데이터를 BigQuery로 옮기는 코드를 작성했고, 그 과정에서 Airflow를 활용했다. 데이터 분석가 운영진분들이 Airflow를 사용해보고 싶어하셔서, 이걸 한번 사용하는 것도 괜찮겠다 싶어서 채택했다. 그 과정에서 스프레드시트 => BigQuery로 멱등하게 데이터를 추출하려면 어떻게 해야할지?에 대한 질문을 조동민님에게 계속 드렸다(나의 하드 트레이닝을 받으셔서 Airflow에 익숙해지셨다..ㅎ..)
- 그리고 복주머니라는 이름으로 설날 전에 메시지를 보냈다. 받은 분들이 따뜻함을 느끼셨고, 2번째 하다보니 더 익숙해지는 것을 보일 수 있었다
- 복주머니 관련 글도 곧 글또 블로그에 올라갈 예정이다

글또의 오프라인 모임 : 빌리지 별 반상회

글또에서는 같은 직무의 그룹을 빌리지로 묶고, 코어라는 세부 조로 나눈다
- 빌리지(같은 직무)끼리 모여서 대화를 나누자는 이름으로 반상회를 9기부터 시작했다
- 80~100명이 참여하는 모임을 매 기수 4회 이상 진행했다
- 아래 사진은 이 시기를 추억하고 싶어서 남겨둔다

회사들과 협업

10기 때도 회사들과 협업을 진행했다
- 길벗과 한빛미디어에서 책을 후원해주셔서 사람들에게 책을 볼 수 있는 기회를 드렸다
- 인프런과 협업해서 30% 쿠폰을 모두 다 받을 수 있게 해주었다
- 코드트리는 한번 더 협업을 진행해서 알고리즘 테스트를 경험할 수 있게 해주었다
- 모두 감사합니다
튜링의 사과와 협업해서, 좋은 공간을 활용할 수 있었다
- 많은 분들이 이번 주 튜사가서 공부하실 분? 이런 내용을 보기도 하고, 튜링의 사과에서 모여서 각자 글쓰기(모각글)도 진행했다
그 외에도 슬라이스와 협업해서 운영진분들의 NFC 명함을 제작했다
- 슬라이스 블로그 글

데이터 기반 의사결정

본업이 데이터 과학자인데 데이터를 부분적으로만 사용하고 있었다. 더 데이터를 잘 살펴보겠다는 다짐을 하며 BI 대시보드를 만들었고, 핵심 지표를 보면서 의사 결정을 진행했다
BigQuery에서 스프레드시트로 데이터를 Export하는 것이 쉽기 때문에 스프레드시트로 BI를 구축했다
아래와 같은 형태로 대시보드를 구축했는데, 자세한 내용은 올해 데이터야놀자 때 계속..
- (250701 추가) 데이터야놀자 2025에서 발표하고 왔다. 발표 영상
- 데이터 파이프라인 구축, 데이터 지표 정의, 데이터 활용 사례 전체를 다룬 내용이라 PM, 데이터 분석가, 데이터 엔지니어 모두에게 도움이 될 것 같다

운영자 관점 : 글또 운영의 경험과 배움

이 부분은 떠오르는 것 위주로 기록. 엄청 정제된 글이 아니라 의식의 흐름으로 지금 떠오르는 내용을 작성한다

커뮤니티 운영에 대해 떠오르는 생각

커뮤니티는 힘이 있다
- 다정함도 힘이 있다. 아이유님의 뮤비인 Love wins all을 보면 대혐오의 시대에 그래도 사랑이 있으면 좋겠다는 메시지를 남긴다. 나 또한 이런 시기에 다정한 공간을 만들고 싶었다
- 그러나 커뮤니티는 지속적으로 운영하는 것은 에너지가 많이 든다
- 1주일에 2~30시간 넘게 글또를 위해 사용했다. 카톡이나 인스타보다 더 많이 접속한다
에너지가 많이 들기 때문에 운영자의 멘탈 관리가 중요하다
- 커뮤니티에선 운영자들의 멘탈, 상황이 중요하다
- 운영진도 여기에 포함되지만, 운영진이 아닌 커뮤니티를 이끄는 제일 권한이 많은 사람의 멘탈 관리가 필요하다
- 운영진이 있어도 외롭게 느껴질 수도 있다. 그럴 때 너무 혼자 있는 것보단 운영자도 운영진과 같이 이야기를 나누는 것이 필요하다. 누구나 살다보면 힘든 시기가 있으니까
- 운영진이 생각할 때 즐겁고, 재밌는 것을 해야한다. 그러고 이렇게 해야한다는 것을 운영진에게 잘 전달하면 된다. 그래야 지속성이 생긴다
기수제로 바꿔서 동아리처럼 운영할 수도 있지만, 누군가가 몇 년동안 꾸준히 운영하는 것도 중요하다고 생각해서 계속 운영했다. 그리고 나의 의지를 받을 분이 없기도 했다
- 실제로 이 시기에 대기업에서 가업 승계를 어떻게 하는지, 후계자 양성을 어떻게 하는지, 대표를 어떻게 뽑는지 등을 많이 찾아봤다. 외부 CEO가 와서 성공한 케이스가 있는지 등
프로세스의 중요성 : 문서화, 템플릿
- 프로세스를 만들면, 그 이후에 드는 에너지를 줄일 수 있다
- 그리고 행사를 운영할 때, 어떤 작업을 할 때 반복적으로 사용할 수 있는데, 그럴 때 문서가 잘 작성되어 있으면 좋다
봇의 자동화
- 단순한 작업이여도 반복된다면 그것은 자동화를 해야하는 대상이다. 반복의 기준은 3회 이상으로 정했다
의사결정 기준의 확립
- 커뮤니티를 운영하다보면 애매한 일이 발생할 수 있다. 그 때 어떻게 할 것인가? 애매한 상황에 어떤 식으로 의사결정을 할 것인지 명확한 기준이 필요하다
생각이 계속 고정되어 있으면 안된다
- 생각을 고정하지 않고 발산을 해서 시야를 넓히기도 하고, 너무 시야가 넓다면 줄이는 수렴 작업이 필요하다
- 발산 - 수렴을 하면서 계속 발전하는 방식으로 나아가야 한다
데이터 기반 의사 결정
- 커뮤니티 또한 제품이다. 제품을 만드는 것처럼 생각해보자
- 참여하는 분들이 어떤 생각을 하고 있을까? 계속 고민한다. 어떻게 해야 더 좋은 가치를 받게 할 수 있을까? 지금 어떤 것을 느끼고 있을까?
  - 이걸 나타내기 위한 지표는 무엇일까?
- 그럼 뭘 해볼까?
- 실험을 해보고, 반응이 오르는지 본다
- AB Test를 하기 어려울 확률이 높아서 전후 비교를 주로 했다
운영자에게 연락하는 것은 DM이 아니라 퍼블릭 채널(문의 채널)을 만들어서 운영했다
- 참여자가 많은데, 많은 사람들이 내게 DM을 하면 내가 마음속으로 여유가 적어질 것이라 생각했다
고인물이 티가 안나는 커뮤니티를 만들자
- 커뮤니티에 기수를 명시하는 곳도 있는데, 글또는 그런 것이 없다. 매번 슬랙 워크스페이스를 다시 만들었다
- 그래서 말을 안하면 이 사람이 글또를 얼마나 했는지 모른다. 그래서 실제로 글또 언제부터 하셨나요?를 물어보는 경우도 있다
- 커뮤니티에서 기수가 뭐가 중요할까, 그냥 계속 하고 있는지가 중요하지. 이런 생각을 해서 고인물이 티가 나지 않는 공간으로 만들었다. 그냥 다 똑같은 참여자다
자신만의 흐름에 맞게 커뮤니티에 참여하는 사람도 괜찮다
- 커뮤니티에서 제공하는 모든 것을 다 경험할 필요가 없다. 각자의 목적에 맞게 커뮤니티를 잘 활용하면 된다
- 너무 강요해서도 안되고, 경험을 제안하는 정도로 해본다
- 다른 사람들이 열심히 활동하는데 난? 이런 생각을 가지는 경우가 있는데 그런 경우도 괜찮다고 말했다. 다른 사람과의 비교보단 과거의 나와 비교를 해야한다
기쁜 일은 같이 축하하고, 슬픈 일은 같이 나눈다
- 나는 누군가의 죽음에 대해 민감하게 받아들인다. 대학교 1학년 때, 동기가 아팠던 기억이 있기 때문이다. 그리고 작년에 친할머니가 돌아가시면서 참 많이 슬펐다
- 이런 슬플 때 찾아가면 조금이라도 힘이 되지 않을까 싶어서 장례식이 있다면 최대한 가려고 한다
- 10기 때 장례식을 겪은 분이 계셔서 말씀을 드리지 않고 찾아갔다. 갔는데 참 눈시울이 붉어졌다. 그 감정을 아니까. 조금이나마 힘이 되었길
위기를 위기로 생각하지 않고 기회로 생각하는 자세
- 위기라는 것은 마음 먹기 다르다고 생각하는데, 어렵거나 힘든 상황이 오면 그냥 즐겁게 문제를 해결해본다
- 그래서 여태까지 위기가 뭐냐고 물어보면 떠오르진 않는다. 결국 해결했으니까
어떻게 온보딩을 해야 할까? 매일 고민했다
- 어떤 모임에 처음 갈 때 항상 떨리는 기억이 있다. 예를 들어 오프라인 첫 모임이나 커피챗 첫 모임 때 갈까 말까? 고민을 하다가 가는 경우가 있다. 이런 분들을 위해 서로 모임 전에 조를 짜거나 익숙한 사람들과 라포를 쌓고 점진적으로 가면 만족도가 높을 것 같다
- 막상 만나면 참 좋은 이야기를 한다. 그 과정을 더 좋게 해주는 것이 커뮤니티의 역할
비판이 와도 비판으로 받지 않기
- 8기? 쯤엔 생일 축하를 공지사항 채널에서 진행했는데, 익명으로 왜 생일을 공지로 하는지 모르겠다는 메시지를 받은 적이 있다. 또한 채널 태그를 안하면 좋겠다(자주 안하지만 울린다고)는 의견도 같이 주셨다(지금 생각해보면 좀 뾰족하게 말을 하셨던 것 같다)
- 이걸 보고 감정적으로 화를 내진 않았고, 오 이런 의견도 있구나 => 그럼 어떻게 해야할까?
  - 생일 축하는 진짜 하고 싶은데! 그럼 채널을 옮기면 되겠다
  - 채널 태그는 많이 하진 않고 중요한 시점에만 하는데 그건 타협이 어렵겠다
    - 대신, 채널 태그를 하는 시간을 정해야겠다
    - 회사에 있을 시간에는 채널 태그를 하지 않겠다!라는 기준을 세웠다
  - 운영진분들이 무언가 공지할 때 내가 항상 “채널 태그는 언제 하는 것이 좋아요”라는 말을 들었을 것이다. 다 의도가 있었다
  - 비판이 와도, 내가 비판으로 받아들이지 않고 그럼 뭘 해야할까? 를 생각하면 된다
    - 오 이런 케이스도 있군 => Action Item
    - 내가 왜 이런 생각을 하는지 맥락과 이렇게 해보겠다라고 했는데 그 이후에 답변이 없었다
    - 이 비판이 나를 비판하는 것이 아니라 그냥 자신의 고민을 말했던 것이라고 생각하고, 이 분이 회사에서 힘든 일이 있어서 여유가 없어서 이렇게 했을 수도 있다. 누구나 그럴 수 있으니까. 나는 이해한다(그렇지만 다른 사람에게나 퍼블릭한 공간에 너무 뾰족한 것을 말하는 것은 용납하지 않는다)
- 비슷하게 누군가 커뮤니티의 행동에 불만을 표하면 => 맥락을 최대한 설명하고, 그렇게 했던 분이 커뮤니티를 좋아할 수 있도록 만들려고 노력했다
사람들이 감동을 받을 포인트를 만든다. 아주 많이. 그게 중첩이 되면 사람들이 감동을 받을 것
- 생일 축하
- 공지 글의 메시지 톤
- 활동 포인트
- 주기적인 모임
- 익명 고민 상담
- 비교하지 않는 문화
- 커피챗
- 소모임 활동
- 지역 모임
- 반상회
- 번개
- 삶에 대한 질문
- 좋은 자료 공유
- 글 큐레이션
- AI 피드백
- 종이 비행기
- 팟캐스트
- 기업과 협업(코드트리, 책 등)
- 회고 템플릿, 여러 강의(글쓰기, 인생 등)
- 여러가지가 다 의도가 있었다. 그 중에서 모두 경험하신 분도 있고, 경험하지 못한 분도 있을 것이다. 그거에 따라 커뮤니티에 더 Engage가 되었을 것 같다
  - 물론 모두 다 경험하지 않아도 괜찮다. 자신의 선택에 맞게 가면 된다
  - 다만 그런 기회를 잘 만들고, 한번 경험하게 해주는 것이 나의 역할이였다

비전과 동기부여

커뮤니티도 비전이 중요하다. 이 커뮤니티에 참여해서 당신이 어떻게 될 것이다!라는 것을 보여주는 것이 필요하다. 그리고 그걸 상상하고, 하나씩 하다보면 결국 이룬 것이 핵심이다
- 물론 그게 모두 같은 모습일 수는 없고, 사람마다 만족도가 다를 것이다. 그래도 커뮤니티에 참여하기 전과 후를 비교해보면 무언가를 했다고 느끼는 것이 핵심이다
참여자들의 동기부여
- 참여자들이 어떤 목적으로 커뮤니티를 들어왔는지에 따라 동기부여 전략이 달라진다
- 어떤 사람들을 글을 쓰기 위해서 들어오는 경우도 있고, 어떤 사람들은 자신이명해지기 위해, 어떤 사람들은 사람을 만나기 위해 등 다양하다.
- 고객이 분화되는 것을 의미하고, 그에 맞게 동기부여를 해야한다
- 이렇게 다양한 고객군에게 어떤 가치를 줄 수 있을지 계속 생각해본다
- 본질적으로 제일 중요한 가치는 무엇인가?
사람들에게 정당성을 주는게 필요하다
- 정당성이라는 것은 이렇게 해야만 한다는 것을 의미한다
- 정당성이라는 것은 여기는 이게 규칙이니까 이걸 해도 됩니다. 괜찮아요 등을 의미한다
- 커피챗을 마음 편히 해보세요. 대나무숲을 편히 사용하세요. 이렇게 해보세요! 등 이런 규칙들을 모두 해보는 것을 권했다
처음이 중요하다
- 처음이 제일 동기부여가 잘 되어있고, 동기가 점점 떨어지는 것은 당연하다
- 내려가는 시점에 어떤 활동을 통해 다시 올리는지가 중요하고, OT 때 위에 나온 비전, 동기부여, 정당성을 다 잘 제시하는 것이 중요하다
- 그 과정에서 어떻게 스토리를 전달할 것인지 많이 고민했다

결국 사람이다

좋은 사람이 모이고, 좋은 관계를 만들고 또 좋은 사람을 데리고 온다
에너지가 많이 들지만, 그럼에도 불구하고 의미 있는 일이다
- 10기 때는 커피챗이 1,131번 진행되었다. 이만큼 사람들을 연결하고, 사람들의 관계가 넓어진 것이다
생일 축하를 매일 했다.
- 어떤 분들은 이걸 이해하지 못했다. 도대체 왜 생일을 챙기냐 여기가 사적 모임이냐? 라고 물어보신 분도 있었다
- 그냥 내 의지가 담긴 것 같다. 생일이란 것은 1년에 1번 돌아온다. 살면서 여러 생일을 거치지만, 다양한 사람들에게 축하를 받는 경험을 하게 해주고 싶었다. 따뜻한 커뮤니티를 만들고 싶다고 했으니, 생일 축하를 해주는 것도 당연하지 않을까?
운영진분들에게도 경험을 남겨주고 싶었다
- 글또 블로그를 만들어서 사람들의 경험을 남기고 싶었다
- 데이터야놀자에 발표를 했던 분들도 있다
진심을 다 하자. 진심을 다 하면 된다. 생각보다 더.

커뮤니티 운영을 하려는 분들을 위한 팁

커뮤니티 운영을 하고 싶다면, 왜 하고 싶은지 꼭 스스로에게 질문을 해보세요
- 그리고 내가 책임감 있게 힘들어도 계속 유지할 수 있을까?를 생각해보세요
- 계속 진행하기 위해 같이 진행할 사람이 있다면 같이 하시는 것도 추천드려요
커뮤니티는 엄청 많이 생기지만 오래 가는 곳은 많이 없습니다. 만약 만드신다면, 오래 갈 수 있도록 고민을 해보시면 좋겠습니다

커뮤니티 비전과 철학

명확한 비전 수립하기: “글을 작성하는 개발 직군분들이 모여서, 좋은 영향을 주고 서로 같이 자랄 수 있는 커뮤니티”와 같은 명확한 방향성을 설정하자
가치 전달하기: OT와 같은 첫 만남에서 커뮤니티의 비전과 가치를 효과적으로 전달하자. 구성원들이 커뮤니티의 방향성을 이해하면 참여도가 높아진다.

운영 관점

Ground Rule 확립하기: 운영진 활동에 대한 명확한 기준과 규칙을 마련하자(예: 회의 기록 남기기, 자료 공유 방식, 업무 한계 설정)
문서화와 템플릿 활용하기: 반복되는 작업은 템플릿화하고, 중요한 결정과 프로세스는 문서화하여 암묵지가 개인에게 귀속되지 않도록 한다.
자동화 시스템 도입하기: 단순 반복 작업은 봇이나 자동화 시스템으로 대체하여 운영 부담을 줄이자(글또의 또봇, 글빼미, 글팽이 등)

운영진과 일하기

번아웃 방지하기: “너무 열심히 하지 말기”를 강조하자. 하나씩 하면 된다. 열정이 넘치는 운영진이 빠르게 지치지 않도록 업무 범위를 제한하는 것도 필요하다.
즐거움 우선시하기: 운영진 활동이 즐겁고 보람 있어야 지속가능하다. 일만 하는 회의보다 서로 교류하는 시간도 함께 가지자.
투명한 의사소통 장려하기: 운영진이 어려움을 겪을 때 부담 없이 이야기할 수 있는 문화를 만들자. 개인적인 상황을 공유하고 필요할 땐 휴식을 권장하자. 어떤 결정을 내릴 때 근거를 같이 공유하자.

참여자 경험 향상

첫 경험 신경 쓰기: 처음이 가장 동기부여가 잘 되는 시점이다. 온보딩 과정에 신경쓰고 좋은 경험을 느끼도록 해주자.
다양한 활동 제공하기: 글쓰기뿐만 아니라 오프라인 모임, 커피챗, 세미나 등 다양한 활동을 통해 참여 경로를 다양하게 제시하자. 참여 여부의 선택권은 참여자에게 맡기자.
긍정적 피드백 루프 만들기: 포인트 시스템, 감사 표현(종이비행기) 같은 방식으로 긍정적인 상호작용을 장려하자.
따뜻한 공간 만들기: 익명 대나무숲과 같은 소통 채널도 다정함을 유지할 수 있도록 노력하자. 생일 축하와 같은 작은 관심으로 커뮤니티의 온기를 유지하자.

의사 결정

데이터 기반 의사결정하기: 참여자 수, 활동량 등의 데이터를 분석하여 커뮤니티의 건강 상태를 점검하고 개선점을 찾자.
유연하게 변화하기: 초기부터 후기까지 커뮤니티의 상황과 규모에 맞게 운영 방식을 계속 수정하고 실행하자.

지속가능성 확보

운영자 멘탈 관리하기: 커뮤니티 지속의 핵심은 운영자의 건강한 마음가짐이다. 자신의 한계를 인정하고 필요할 때 도움을 구하자. 필요하면 멘탈을 유지하기 위한 활동을 해보자.
의사결정 기준 확립하기: 애매한 상황에서도 일관된 결정을 내릴 수 있는 원칙을 세우자. 만약 원칙이 바뀌면 바뀌는 맥락을 공유하면 된다.
실패를 두려워하지 않기: 무언가 잘못되어도 빠르게 인정하고 수정하면 된다. 완벽함보다 지속가능성에 집중하고, 완벽함보다 실행에 집중하자.
“결국 사람이다”라는 것 기억하기: 기술이나 시스템보다 사람과의 관계가 커뮤니티의 핵심이다. 좋은 사람이 모이면 좋은 커뮤니티가 된다. 사람이 제일 중요하다는 것을 명심하자.

참여자 관점 : 글또 활동의 경험과 성장

이 부분은 참여자로 경험한 것들을 작성한 부분이다. 이 부분도 떠오르는 것을 바로 작성했다

글, 강의, 지식의 확장

글을 계속 작성했다
- 여태까지 총 225개의 글을 작성했다. 중간에 글을 작성하지 않은 기수도 있지만, 앞으로도 계속 글을 작성할 것 같다. 이 모든 것은 내가 글을 작성하기 시작해서 생긴 일들. 감사한 일이다
- 글또 운영자 관점일 때도 좋았지만, 마지막 기수인 10기 때 참여자와 운영자를 하면서 참여자분들의 입장을 더 이해할 수 있게 되었다(저도 마감에 글 쓰고.. 글쓰기 힘들어요…ㅋㅋㅋ)
글쓰기 강의를 만들었다
- 사람들을 관찰하며 겪는 문제, 내 해결 방법을 다 집도해서 글쓰기 강의를 만들었다
- 경험 => 강의의 흐름이라 만족스럽다
과거의 나를 만날 수 있다
- 과거에 내가 작성해둔 글이 현재의 내가 볼 때는 과거를 만나게 해주는 매개체가 되었다
- 예전에 GDE가 되고 싶다고 했던 글이 있었는데, 실제로 이루었다. 꿈은 말하면 이루어진다.
다른 사람의 글을 통해 지식의 확장을 경험했다
- 제출한 대부분의 글을 읽었다. 모든 글이 잘 작성되었나 확인할 겸 읽다가 즐겁게 읽고 싶어서 다른 사람은 어떤 이슈가 있었는지 생각하며 읽는다. 모두 다 100% 이해하진 못해도 이런 것들이 있구나를 인지하면서 도움을 받게 된다

사람

좋은 사람들을 많이 만났다
- 글또가 없었으면 내 주변에 좋은 사람이 많을 수 있었을까? 아니였을 것 같다. 이 모든 것이 내가 계속 커뮤니티를 지속할 수 있었던 이유다
- 나를 지지해주는 사람들을 만났다. 이렇게 서로 따뜻하고, 격려하는 공간이 만들어 질 수 있다니 감사하다
같이 강의를 만들 사람들을 모집했다
- 강의 만들기 모임을 여러번 진행하다가, 확실하게 강의를 만들 수 있게 하려면 어떻게 해야할지 감이 왔다
- 강병진님, 강승현님, 김은찬님과 함께 강의 만들기 모임을 하면서 진짜 강의를 만들게 했다! (진짜 멱살 잡고 강의 만들게 해줬음)
4-5기 시절에 멘토링을 했던 분들이 이제 회사에서 업무를 잘 진행하고 있는데, 글또의 경험이 도움이 되었다는 말을 들을 때 참 감사하다. 열심히 해주셔서 그런 결과를 얻은거고 나는 한 것이 없지만, 글또를 기억해주는 것 자체가 참 좋다
진짜 웃긴건 사람들에게 솥밥의 위대함을 알려주고 싶어서 솥밥 만들기 강의도 했다.. 강의가 천직인가?
- 강의를 수강하고 솥밥을 계속 만드는 분들을 보며 뿌듯함을 느낀다

리더십

리더십
- 리더십을 어떻게 더 확장할 수 있을까? 관점에서 많이 고민하고 실행했다
- 639명의 동기부여를 동시에 주려면 어떻게 해야할까? 생각하면서 발표 자료를 만들었다. 이런 경험은 회사의 대표가 되지 않는 이상 하지 못하는 경험이라 생각한다. 항상 듣는 사람이 어떨지 생각할 수 있게 되었다
- 전체의 구성원에 대한 동기부여, 운영진에 대한 동기부여. 두가지 그룹에게 다른 리더십을 제공해야 했다
프로덕트 오너 경험
- 쏘카에서 근무할 때도 매니저 역할을 하면서 PM, PO 역할을 했지만 그게 커뮤니티로 확장되었다. 데이터를 보면서 어떻게 해야할까? 고민하고, 참여자들은 어떤 생각을 가지고 있을까? 생각하면서 계속 더 좋은 가치를 주려고 노력했다
고민 상담소, 멘토링을 하면서 다른 사람들을 더 잘 이해할 수 있게 되었다
- 회사에서도 30~40명의 엔지니어링 매니저라 많은 사람들과 면담을 했다. 그 경험을 기반으로 더 많은 사람들과 글또에서 고민이 있는 분들의 고민을 들어드리고, 멘토링을 진행했다. 많은 사람들에게 좋은 영향을 주고 싶었다
- 게더타운에서 모닥불 소리를 들으며 진행한 고민 상담소

성격, 소속감

생각해보면 나는 커뮤니티 느낌의 게임을 많이 했다. 큐플레이도 했고, 길드가 있는 게임을 했다
- 어린 시절의 나는 소속감을 갖고 싶었던 것 같다. 외로움도 탄 것 같고. 그래서 사람들과 교류를 계속 시도했고, 지금은 어느정도 나의 중심을 잘 잡아갈 수 있게 된 것 같다
- 내가 만들었지만, 소속감이 필요했던 것은 내가 아니였을까? 과거의 나는 외로움을 느끼고 있었던 것 같다
이제는 감정의 동요가 줄어들었다
- 원래 감정적인 동요가 적은 편인데, 더 침착해졌다
- 어떤 일이 생겨도 그냥 그걸 해결하면 된다는 마음 가짐을 배웠다
- 잘못된 일이 생겨도, 빠르게 수정하고 바꾸면 된다

앞으로

글또 10기까지 운영하고 추후 운영 계획이 없다
이렇게 된 계기는 여러가지가 있다
- 글또를 운영하며 즐거운 점이 더 많지만, 내가 힘들다고 느끼는 시점이 있는데 그 시점은 불합격자에게 불합격 연락을 줄 때다. 참 감정적으로 힘들다
- 우리는 살면서 끝이 있다는 생각을 자주 하지 않는 것 같다. 그래서 다음에 또 좋은 기회가 있겠지란 생각을 하는데, 이번엔 끝이 있다는 것을 참여자분들에게 말씀드리고 싶었다. 끝이 있다고 생각하면서 살면, 그 현실을 더 열심히 살 수 있다고 믿는다. 그걸 경험하게 해주고 싶었다. 마지막에 대해 생각하고 보내줄 수 있는 것도 필요한 능력이다
- 사람이 많아진 상황이라 이후에 간다면 기업의 형태로 가야할 수 있다. 그런데 그게 참 고민이 되는 관점. 이후에 커뮤니티를 한다면 한 사람을 인격적으로, 실력적으로 등 다양한 형태로 발전할 수 있게 해주고 싶다. 그 과정에서 많은 것들을 같이 해주고 교육하는 그런 공간을 만들고 싶다
글또 10기 슬랙은 계속 존재해서, 사람들이 어떻게 활동하나 궁금하다. 몇개월 뒤에도 활발하다면 다시 하고 싶어지지 않을까?
- 일단은 7년 동안 책임감을 가지고 커뮤니티를 계속 만들었던 나를 응원하고 싶다. 이 책임감이 없는 상태로 살다가, 그러다가 마음이 다시 바뀔 수 있다고 생각한다(열린 결말)
- 없는 기간을 가져야 소중함을 느낄 수 있을 것 같다
어떻게 보면 Phase 1이 끝났다고 볼 수 있을 것 같다. 나도 10기까지만 한다는 결정을 하니까, 오히려 더 10기에 집중할 수 있었다. 근데 갑자기 11기를 한다면?
- 그건 나를 속이는 일이기도 하고, 10기가 마지막이라고 생각하는 분들을 속이는 일이 아닐까?
- 당분간은 잠시 나의 시간에 집중을 해보고, 나중에 생각이 바뀌면 그 때 맥락을 공유하면 될 것 같다
이렇게까지 할 수 있었던 이유는 무엇일까?
- 아마 책임감 때문인 것 같다. 책임감. 많은 분들이 원하고, 내가 할 수 있는 능력이 있어서 그것을 했을 뿐이다
- 최근에 그랩과 같이 사운드독이란 재즈바에 갔는데, 사장님이 재즈신의 책임감으로 재즈바를 운영하신다고 하셨다. 돈이 되는 것보다 그렇게 하고 싶으시다고.
  - 이 이야기를 들었을 때 사실 글또를 다시 하고 싶단 생각이 들긴 했다. 그렇지만, 내게도 잠시 공식 글또 활동이 끝난 시기를 경험해야, 이 부분에 대해 생각할 수 있을 것 같다
다시 커뮤니티를 만들어도 잘 할 자신이 있다
- 커뮤니티를 어떻게 만들어야 하는가에 대한 암묵지가 쌓여있고, 이걸 강의로도 전달할 수 있다. 하지만 강의를 만들기엔 수요가 적을 것 같아 만들진 않았다(다른 우선순위도 있고)
- 이후에 하고 싶은 커뮤니티가 있긴 한데, 지금인지 모르겠다. 조금 더 시간이 필요할 수도 있을 것 같다
- 물론 커뮤니티 관점에서 내가 해보지 않은 것은 수익성 관점이다. 수익성을 추구하지 않았지만, 어떤 커뮤니티든 수익성에 대한 고민을 하게 된다. 전략이나 비전에 따라 가격 설정을 하고, 그것을 전달하는 것이 필요하다
마치 게임 서버 종료하는 느낌과 비슷한 것 같다
- 큐플레이 종료할 때가 떠오른다. 그렇지만 지금 다시 보면 메이플스토리 월드에 큐플레이가 나오고 있다. 이걸 보면 글또도 다시 그럴 수 있지 않을까? 글또와 비슷한 커뮤니티가 또 생길 것 같고, 이게 잘 동작한다면 선순환이 되지 않을까 싶다
- 아래 이미지는 해당 블로그에서 참고했다

내게 글또는 어떤 의미일까

자식 같은 커뮤니티
내 20대 후반과 30대 초중반
- 나의 발전과 함께 한 공간
좋은 사람들을 만나게 되었던 공간
나의 책임감과 꾸준함을 알 수 있게 되었던 공간
나의 평온한 감정을 느낄 수 있게 되었던 공간
나의 화법을 알게 되고, 어떻게 해야 상대를 배려할 수 있을까를 알게 되는 공간
600명의 동기부여를 만들어야 하는, 리더십 영역에 대해 많이 고민한 시간
누군가의 발전에 도움을 준 공간

글또를 운영할 때 영감을 준 자료들

함께 자라기, AC2 : 창준님의 AC2 수업을 들으면서 어떤 것이 핵심일까에 대한 것을 이해할 수 있었고, 나름대로 적용한 것을 8기 이후부터 내 기준, 철학을 담아 적용했다
당신을 초대합니다 : 커뮤니티 관련 책 중 제일 좋았다. 커뮤니티를 어떻게 만들지에 대해 자세한 내용이 담겨져 있다
인간 본성의 법칙 : 사람은 어떤 생각을 가지는가에 대해 고민하기 위해 읽었는데, 사람들은 다양하구나를 느끼고 여러 관점으로 생각하게 된 계기가 되었다
왕으로 산다는 것, 참모로 산다는 것 : 왕과 참모는 어떻게 지내는가? 라는 관점인데 리더십 관점에서 도움이 되었다. 때론 참모처럼 조언을 하고, 때론 리더십을 해야하는데 나는 어떤 캐릭터인가 생각하게 되었다
현명한 이타주의자 : 남들을 위해 사는 것이 나쁘지 않고, 이것을 어떻게 전파할 수 있을까를 알기 위해 읽은 책이다. 이 내용을 잘 전달하려고 노력했다. 나누자 나눠
찬란한 멸종 : 글또를 10기까지 하기로 결정하고 멸종이란 무엇일까? 끝이란 무엇일까? 고민하다가 읽은 책이다. 최초 의도와 다르지만 스토리텔링 방식이 흥미로웠다. 이 방식으로 생각을 정리하는 더 명확해졌다

이 글을 통해 본 나의 특징

클로드에게 이 글을 보내주고, 내 특징을 알려달라고 하니 다음과 같이 말해준다. 추후에 어떤 조직에 가더라도 나의 특징을 잊지 말고 살아가자

책임감과 지속성이 강한 사람: 7년 동안 커뮤니티를 꾸준히 운영했으며, 1기 13명에서 10기 639명까지 성장시킨 점에서 책임감이 매우 강합니다.
체계적인 사고방식: 운영진 활동의 체계화, Ground Rule 설정, 문서화와 템플릿 활용 등 조직적인 시스템을 구축하는 데 능숙합니다.
사람 중심의 가치관: “결국 사람이다”, “다정함은 힘이 있다” 같은 표현과 생일 축하, 대나무숲 운영 등을 통해 사람과 관계를 중시하는 가치관이 드러납니다.
실용적인 접근법: 포인트 시스템, 봇 자동화 등 실질적인 문제 해결 방식을 선호하며, 이론보다 실천을 중시하는 경향이 있습니다.
성장 지향적 마인드: 본인과 참여자들의 성장을 중요시하며, 경험을 통해 배우고 발전하는 과정을 가치 있게 여깁니다.
균형 잡힌 리더십: “너무 열심히 하지 말기”를 강조하고 운영진의 번아웃을 방지하는 등 지속가능한 리더십을 실천합니다.
학습과 적용에 능한 사람: 쏘카에서의 경험을 커뮤니티에 적용하고, 책과 논문을 통해 습관 형성에 대해 학습하는 등 다양한 경험을 통합하는 능력이 있습니다.
데이터 기반 의사결정: 참여자 데이터를 수집하고 분석하여 커뮤니티 운영에 활용하는 모습에서 데이터 중심적 사고가 엿보입니다.
공동체 의식이 강한 사람: 글또를 통해 좋은 사람들이 모이고 서로 영향을 주는 공간을 만들고자 하는 의지가 강합니다.
성찰적인 태도: 과거 경험을 돌아보고 자신의 변화를 인식하며, 실패와 성공 모두에서 배우려는 자세가 보입니다

SQLMesh 사용법 : dbt의 경쟁자가 될 수 있을까?

Sat, 15 Mar 2025 00:00:00 +0000

이 글은 SQLMesh 사용법에 대해 작성한 글입니다
예상 독자
- SQLMesh가 궁금하신 분
- SQLMesh가 dbt 대비 어떤 것이 다른지 궁금하신 분
- 이 글을 보시기 전에 dbt, DuckDB에 대해 알고 계시면 좋을 수 있는데, 과거에 작성한 글을 추천
  - dbt 사용법과 기본 개념
  - DuckDB 사용법
키워드 : SQLMesh 사용법, SQLMesh vs dbt

SQLMesh란?

SQLMesh GitHub
Tobiko의 오픈소스
- SQLMesh, SQLGlot
SQLMesh는 Transformation, Testing, Collaboration을 위한 DataOps 솔루션
- 데이터 Transformation 영역에서 dbt가 제일 유명한데, dbt에서 개선하면 좋은 점들을 개선해서 나오는 도구
SQLMesh 공식 문서에 보면 dbt와 다른 점에서도 상세히 공유하고 있음
Terraform에서 영감을 받은 부분이 있다고 함. 그래서 plan 명령어가 있음
2025년 3월 15일 기준 v0.165.0

SQLMesh의 장점

SQLMesh의 Concept은 dbt와 유사하며, dbt와 차이점으로 나오는 장점들을 정리

1) 간단한 SQL로 모델 생성 가능

데이터 분석가 직무에 계신 분들이 처음 dbt를 사용하면 Jinja, YAML에 어려움을 겪는데, SQLMesh는 간단한 SQL로 정의할 수 있음

2) 증분 로직 처리

dbt에선 증분 로직을 is_incremental 등을 사용해서 만들어야 하는데, SQLMesh는 증분 로직을 쉽게 만들어줌

dbt의 증분 로직

처음에 dbt를 학습할 때 제일 어려운 부분
dbt는 state를 추적하지 않아서 이렇게 구현해야 함
날짜 경계를 찾기 위해 수동으로 매크로를 지정하는 작업에서 오류가 나기 쉬움

    
  -- dbt incremental
  SELECT *
  FROM {{ ref(raw.events) }} e
  JOIN {{ ref(raw.event_dims) }} d
    ON e.id = d.id
  -- must specify the is_incremental flag because this predicate will fail if the model has never run before
  {% if is_incremental() %}
      -- this filter dynamically scans the current model to find the date boundary
      AND d.ds >= (SELECT MAX(ds) FROM {{ this }})
  {% endif %}
  {% if is_incremental() %}
    WHERE e.ds >= (SELECT MAX(ds) FROM {{ this }})
  {% endif %}
    

SQLMesh는 날짜 범위를 알아서 추적해 간단하게 쓸 수 있음

-- SQLMesh incremental
SELECT *
FROM raw.events e
JOIN raw.event_dims d
  -- date ranges are handled automatically by SQLMesh
  ON e.id = d.id AND d.ds BETWEEN @start_ds AND @end_ds
WHERE d.ds BETWEEN @start_ds AND @end_ds

3) Data Gap 감지

dbt에서 증분 모델을 구현할 때는 MAX(date)로 최근 데이터를 확인하고, 그 이후부터 적재하도록 함
- 이렇게 할 경우 과거에 누락된 데이터를 놓치게 되며, 데이터 파이프라인 관점에서 유지보수를 더 많이 해야 함

SQLMesh는 모델이 실행된 날짜 간격을 저장해서 누락된 날짜를 정확히 알 수 있음

  Expected dates: 2022-01-01, 2022-01-02, 2022-01-03
  Missing past data: ?, 2022-01-02, 2022-01-03
  Data gap: 2022-01-01, ?, 2022-01-03

4) 환경 격리

데이터 파이프라인도 Prod/Dev 환경을 격리해야 할 수 있음. 규모가 커질수록 환경의 필요성이 생기지만, 환경을 구축하는 것은 고민이 많이 됨
- 환경을 구축하기 위해선 실제 데이터를 Dev에 그대로 제공해야 하는데, 이는 데이터 저장 비용이 드는 일이라 고민이 됨(데이터 저장 비용이 2배가 되는 상황)
- dbt는 환경마다 별도의 테이블에 데이터를 물리적으로 복제함
SQLMesh는 VIEW를 사용해서 데이터를 물리적으로 저장하지 않아 비용이 들지 않음
- 환경마다 테이블 이름에 접두사를 붙여서 환경을 구분함

5) 스키마 변경 자동화

스키마가 변경되면 자동으로 감지하고 필요한 마이그레이션을 생성함
dbt는 개발자가 직접 스키마 변경을 관리해야 함

6) 오픈소스 UI 제공

dbt는 Paid UI가 제공되며, 오픈소스 중에 찾으려면 lightdash를 사용해야 함
SQLMesh는 오픈소스 UI가 존재해서 쉽게 사용할 수 있음(그러나 디자인은 약간 아쉬움)

SQLMesh 실습

작업 흐름

파이썬 가상 환경 / 라이브러리 설치
- 파이썬 가상환경 설정
- SQLMesh 설치
프로젝트 생성
- Prod 환경 설정
- Model 수정
- Dev에서 작업
- Prod로 통합

파이썬 가상 환경 / 라이브러리 설치

가상 환경 설정

python -m venv .venv
source .venv/bin/activate

SQLMesh 설치
- Web UI도 사용할 예정이라, 같이 설치

pip3 install "sqlmesh[web]"

Duckdb 설치 : Local에서 Duckdb를 사용할 예정

pip3 install duckdb

프로젝트 생성

폴더 생성(sqlmesh-example)

mkdir sqlmesh-example
cd sqlmesh-example

DuckDB 환경에서 init

sqlmesh init duckdb

다음과 같은 폴더, 파일들이 생성됨

├── audits
│   └── assert_positive_order_ids.sql
├── config.yaml
├── macros
│   └── __init__.py
├── models
│   ├── full_model.sql
│   ├── incremental_model.sql
│   └── seed_model.sql
├── seeds
│   └── seed_data.csv
└── tests
    └── test_full_model.yaml

6 directories, 8 files

config.yaml

프로젝트 디렉토리에 생성됨
어떤 엔진을 사용할지, 게이트웨이 커넥션 등이 저장됨

gateways:
  duckdb:
    connection:
      # For more information on configuring the connection to your execution engine, visit:
      # https://sqlmesh.readthedocs.io/en/stable/reference/configuration/#connections
      # https://sqlmesh.readthedocs.io/en/stable/integrations/engines/duckdb/#connection-options
      type: duckdb
      database: db.db
      # concurrent_tasks: 1
      # register_comments: True
      # pre_ping: False
      # pretty_sql: False
      # catalogs:
      # extensions:
      # connector_config:
      # token:


default_gateway: duckdb

model_defaults:
  dialect: duckdb
  start: 2025-03-14

생성된 폴더의 특징

config.yaml : 프로젝트 설정 파일
models : SQL/Python 모델 파일
- 현재 full_model.sql, incremental_model.sql, seed_model.sql이 저장됨
seeds : CSV 같은 고정된 데이터셋
audits : 모델의 출력을 검증할 때 사용
- 목적: 모델 출력의 데이터 품질을 검증
- 실행 시점: 모델 실행 후 매번 자동으로 실행. 계획(plan)을 적용할 때마다 SQLMesh는 자동으로 실행
- 기본 동작: 감사가 실패하면 sqlmesh plan을 중단해 잠재적으로 유효하지 않은 데이터가 다운스트림으로 전파되는 것을 방지
tests : 모델의 로직의 정확성 검증
- 목적: 모델의 로직을 검증하고 예상된 출력과 일치하는지 확인
- 실행 시점: 개발 중, 또는 CI/CD 과정
- 작동 방식: 사전 정의된 입력으로 모델의 로직을 평가하고 출력을 테스트에서 제공된 예상 결과와 비교
- 소프트웨어 개발의 단위 테스트(unit testing)와 유사
macros : 매크로 저장. SQLMesh 매크로와 Jinja 매크로로 나뉨

Model 생성

Model Doc
위에 init하면서 생긴 Model 살펴보기

Full Model

최상단에 MODEL 명령어를 사용해 모델을 정의
name은 프로젝트 이름에서 Unique해야 함
kind : 모델의 종류를 의미
- Model Kind properties에서 확인할 수 있음
- VIEW, FULL, Incremental Model이 존재
  - Incremental Model은 INCREMENTAL_BY_TIME_RANGE, INCREMENTAL_BY_UNIQUE_KEY, INCREMENTAL_BY_PARTITION로 나뉨
cron : 모델이 데이터를 처리하거나 새로고침을 할 때 사용할 일정. 자체 스케쥴러를 쓸 수도 있고, Airflow를 사용할 수도 있음
grain : 모델이 반환한 결과에서 행을 고유하게 식별할 수 있는 컬럼, 여러 컬럼의 조합도 가능함
audits : 모델이 평가된 후 실행될 오딧(여기선 audits/assert_positive_order_ids.sql 파일을 실행한다는 의미)
그 후 모델의 쿼리
- 만약 컬럼의 데이터를 형변환하고 싶다면 다음과 같이 정의하면 됨 item_id::TEXT

MODEL (
  name sqlmesh_example.full_model,
  kind FULL,
  cron '@daily',
  grain item_id,
  audits (assert_positive_order_ids),
);

SELECT
  item_id,
  COUNT(DISTINCT id) AS num_orders,
FROM
  sqlmesh_example.incremental_model
GROUP BY item_id

비교를 위해 dbt 모델 파일도 추가. 모델 정의 자체는 비슷하다고 볼 수 있지만, 명시적으로 MODEL을 정의하는 점이 차이

-- models/staging/stg_orders.sql
{{ config(materialized='table') }}

SELECT
    order_id,
    customer_id,
    order_date,
    status,
    amount
FROM raw_data.orders
WHERE status IS NOT NULL

Incremental Model

INCREMENTAL_BY_TIME_RANGE을 사용했으며, 시간 컬럼을 event_date로 지정
grain을 id, event_date로 설정함
SELECT 쿼리 하단을 보면 WHERE에 event_date BETWEEN @start_date AND @end_date가 있는데, 이렇게 증분 처리가 끝남

MODEL (
  name sqlmesh_example.incremental_model,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column event_date
  ),
  start '2020-01-01',
  cron '@daily',
  grain (id, event_date)
);

SELECT
  id,
  item_id,
  event_date,
FROM
  sqlmesh_example.seed_model
WHERE
  event_date BETWEEN @start_date AND @end_date

Seed Model

Seed Model Doc
Seed Model을 불러오고 싶은 경우 사용
컬럼의 이름과 타입을 지정할 수 있음

MODEL (
  name sqlmesh_example.seed_model,
  kind SEED (
    path '../seeds/seed_data.csv'
  ),
  columns (
    id INTEGER,
    item_id INTEGER,
    event_date DATE
  ),
  grain (id, event_date)
);

Audit

Audit Document
assert_positive_order_ids.sql
최상단에 AUDIT을 명시하고, 이름 지정
- FROM 절에 @this_model을 사용하는데, 이는 SQLMesh의 빌트인 매크로임. Runtime Variable에서 확인할 수 있음

AUDIT (
  name assert_positive_order_ids,
);

SELECT *
FROM @this_model
WHERE
  item_id < 0

파라미터를 주입할 수도 있음. 특정 값이 초과되지 않는 경우를 확인하고 싶은 Audit

AUDIT (
  name does_not_exceed_threshold
);
SELECT * FROM @this_model
WHERE @column >= @threshold;

위 Audit을 실행하려면 MODEL에서 아래와 같이 정의해야 함

MODEL (
  name sushi.items,
  audits (
    does_not_exceed_threshold(column := id, threshold := 1000),
    does_not_exceed_threshold(column := price, threshold := 100)
  )
);

SQLMesh Plan

SQLMesh에선 환경에 Plan을 만들고 적용하는 것이 핵심
- 모델의 새 버전을 생성하고 저장함
- 모델을 평가하고 실행
- Plan의 Target 환경에 업데이트

sqlmesh plan

Backfill Tables에 y를 입력하면 Backfill 작업을 수행함

폴더를 보면, db.db와 logs가 추가된 것을 확인할 수 있음

.
├── audits
│   └── assert_positive_order_ids.sql
├── config.yaml
├── db.db
├── logs
│   ├── sqlmesh_2025_03_15_14_04_40.log
│   └── sqlmesh_2025_03_15_14_31_00.log
├── macros
│   ├── __init__.py
│   └── __pycache__
│       └── __init__.cpython-310.pyc
├── models
│   ├── full_model.sql
│   ├── incremental_model.sql
│   └── seed_model.sql
├── seeds
│   └── seed_data.csv
└── tests
    └── test_full_model.yaml

8 directories, 12 files

DuckDB에서 데이터 확인

CLI에서 아래 명령어 실행

duckdb db.db

DuckDB를 실행한 후, .tables를 실행하면 테이블을 확인할 수 있음
- full_model, incremental_model, seed_model : 위 MODEL에서 생성한 결과. 사용자가 사용할 땐 이걸 사용
- sqlmesh_example__full_model__2278521865 : 이 형태도 물리적 테이블이나, 버전 관리를 위해 사용하는 내부적인 테이블

D .tables
_auto_restatements
_environment_statements
_environments
_intervals
_plan_dags
_snapshots
_versions
full_model
incremental_model
seed_model
sqlmesh_example__full_model__2278521865
sqlmesh_example__incremental_model__1880815781
sqlmesh_example__seed_model__2185867172

아래 쿼리를 실행하면 데이터를 확인할 수 있음
- sqlmesh_example는 모델의 스키마로 위에 모델 생성할 때 사용함

SELECT * FROM sqlmesh_example.full_model;

모델 수정 및 Dev에서 작업하기

모델 수정

이제 Prod 환경을 채웠으니, SQL 모델 하나를 수정
models/incremental_model.sql에 'z' AS new_column을 추가함

MODEL (
  name sqlmesh_example.incremental_model,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column event_date
  ),
  start '2020-01-01',
  cron '@daily',
  grain (id, event_date)
);

SELECT
  id,
  item_id,
  'z' AS new_column, -- Added column
  event_date,
FROM
  sqlmesh_example.seed_model
WHERE
  event_date BETWEEN @start_date AND @end_date

Dev 환경 생성 및 Backfill

dev 환경을 생성
```
  sqlmesh plan dev
```
생성하면 변경된 모델이 incremental_model이라고 나오며, 변경된 부분이 나옴

backfill을 해주면, dev 환경에 테이블이 생성됨

데이터 확인

위에서 했던 것처럼 duckdb db.db로 DuckDB에 접근한 후, .tables로 테이블 확인

D .tables
_auto_restatements
_environment_statements
_environments
_intervals
_plan_dags
_snapshots
_versions
full_model
full_model
incremental_model
incremental_model
seed_model
sqlmesh_example__full_model__2278521865
sqlmesh_example__full_model__2278521865__dev # 새로 추가됨
sqlmesh_example__incremental_model__1880815781
sqlmesh_example__incremental_model__772980299 # 새로 추가됨
sqlmesh_example__seed_model__2185867172

full_model은 변경된 것이 없어서 기존 모델에 __dev 추가(새 환경)
반면 incremental_model은 변경된 것이 있어서 해시가 변경됨
새롭게 추가된 incremental_model 데이터 확인

select * from sqlmesh_example__dev.incremental_model;

Dev에서 작업한 내용 Prod에 적용

sqlmesh plan 명령어를 사용해서 Dev -> Prod로 적용

DuckDB에 접속하지 않고, sqlmesh 명령어로 데이터를 가지고 올 수도 있음

sqlmesh fetchdf "select * from sqlmesh_example.incremental_model"

SQLMesh Web UI

아래 명령어를 통해 Web UI를 실행

sqlmesh ui

위에서 작업한 incremental_model.sql을 클릭하니 리니지를 보여줌

데이터를 쿼리해서 확인할 수도 있음

Models 폴더를 클릭하면 실행된 모델과 모델의 메타데이터, 리니지를 볼 수 있음

UI에서도 plan을 실행하고 합칠 수 있음
- UI 공식 문서, 퀵스타트 문서에 실행 흐름이 잘 나와있음
그 외에 기능은 아직 확인이 어려움. Oauth 등

SQLMesh 사용 후기

SQLMesh를 사용해보면 dbt보다 러닝커브가 낮음
그러나 지금 SQLMesh롤 바로 도입해야 할까? 하면 고민되는 부분이 있음
- 생태계가 아직 dbt에 비해 작고, 1점대도 아니라 계속 변경될 것으로 예상
- Airflow와 Prefect의 관계를 보는 것 같기도 함
그럼에도 불구하고 T 영역에서 거의 독점했던 dbt의 경쟁자가 있다는 점에서 SQLMesh를 응원하고 싶음. 사용성은 괜찮았음
dbt가 SDF labs를 인수한 후, 여러 통합 작업을 진행할 것으로 예상되는데 그 과정에서 SQLMesh가 제시하는 SQLMesh의 장점을 무력화할 수 있을 것 같음
레딧에서 논의되는 내용을 보면 도움이 됨
- 레딧1
- 레딧2
- 레딧3

레퍼런스 및 읽으면 좋은 자료

SQL 홈페이지
SQLMesh Document
Sung Won Chung님의 링크드인 : Tobiko의 Solution Architect로 근무하고 계신데 튜토리얼 내용을 링크드인 글로 공유해주심
Tobiko 블로그
dbt와 SQLMesh의 기능 비교 : 각 라이브러리가 제공하는 범위를 비교해줌
- FAQ 문서도 보는 것을 추천함. dbt와 SQLMesh의 용어가 살짝 다름
- dbt materialization : SQLMesh의 model kinds에 정의
- dbt seeds : SQLMesh model kind의 seed
- dbt test : SQLMesh audits
- dbt build : sqlmesh run
SQLMesh + GitHub Action 통합
SQLMesh를 사용한 데이터 파이프라인

글 작성하는데 걸린 시간 : 3시간 30분
- 하고자 하는 이야기, 개요 정리 : 13분
- 초안 글 작성 : 3시간 7분
- 클로드와 셀프 글 피드백 : 10분

BigQuery PIPE 사용법 : SQL의 새로운 형태

Sat, 01 Mar 2025 00:00:00 +0000

2024년 연말에 새로 생긴 BigQuery Pipe 사용법에 대해 작성한 글입니다
- 이 글은 2025년 3월 초 기준으로 작성되었습니다
- 파이프 문법 Cheatsheet가 궁금하면 BigQuery 가이드북을 방문해주세요
키워드 : BigQuery Pipe, BigQuery PIPE syntax

BigQuery Pipe Syntax

이 부분은 구글의 논문인 SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL을 참고했음

기존 SQL의 문제점

SQL은 데이터 작업을 위한 표준 언어가 되었고, 대부분의 SQL 엔진 대부분 비슷한 문법을 사용함
- 하지만 SQL은 배우기 어렵고, 사용하기 어렵고, 확장하기 어려움
- 이런 문제를 해결하기 위해 새로운 언어를 개발해서 제안한 사람들이 있으나, 새로운 언어를 채택하는 과정은 반발심도 있어서 쉽지 않음
SQL은 다음과 같은 문제점이 존재함
- 고정된 구문 순서
- 중복된 구문(예 : 필터링)
- 서브 쿼리 사용
- 내부 -> 외부의 데이터 흐름
- 동일한 컬럼들의 반복

고정된 구문 순서

SELECT - FROM - WHERE - GROUP BY 순서가 고정되어 있어서 유연성이 떨어짐
- 문법과 의미 관점에서 순서가 다름
데이터는 FROM에서 나오기 때문에, FROM 절부터 생각해야 함
- 그러나 쿼리의 시작이 SELECT라 헷갈리게 됨
- 처음 SQL을 학습할 때 많은 분들이 이 부분에 대해 어려워 함

중복된 구문(예 : 필터링)

데이터를 필터링할 때, WHERE, HAVING, QUALIFY를 사용할 수 있음
- 이 3개가 사용되는 경우는 모두 다르지만, 결국에 데이터를 필터링할 때 사용됨. 그래서 처음 SQL을 공부하는 사람이 헷갈리게 됨. 언제 WHERE? 언제 HAVING?
아래 쿼리를 보면 WHERE, HAVING, QUALIFY에 대해 작성되어 있음. 궁극적으로 이걸 하나로 통일할 수는 없을까?

SELECT
  customer_name,
  order_date,
  SUM(amount) AS total,
  RANK() OVER (PARTITION BY customer_name ORDER BY SUM(amount) DESC) AS rk
FROM customers 
JOIN orders ON customers.id = orders.customer_id
WHERE region = 'East'           -- 집계 전 필터링
GROUP BY customer_name, order_date
HAVING SUM(amount) > 1000       -- 집계 후 필터링
QUALIFY rk = 1  

서브 쿼리 사용

다중 집계, 계산된 표현의 재사용 등을 위해 서브 쿼리를 사용해야 함
- 서브 쿼리는 들여쓰기가 많아져서 가독성을 해치고, 편집할 때 실수를 유발할 가능성이 생김
간단한 연산이지만 서브 쿼리가 필요한 경우
- 두 번 이상 합산하기
- 지원되는 세 곳(WHERE, HAVING, QUALIFY) 이외의 위치에 필터링을 해야할 때, 서브 쿼리로 한번 감싸서 처리해야 함
BigQuery ML을 사용해서 임베딩 모델을 예측하고, 그 후에 예측할 때 서브 쿼리를 사용해야 함(2번 연속으로 서브 쿼리 사용)

SELECT *
FROM ML.PREDICT(
  MODEL `my_project.imdb_classifier`,
  (
    SELECT *
    FROM ML.PREDICT(
      MODEL `my_project.nnlm_embedding_model`,
      (SELECT '<text>' AS input, 7 AS rating)
    )
  )
)

내부 -> 외부의 데이터 흐름

서브 쿼리, JOIN 등이 혼합된 쿼리를 볼 때 제일 안쪽에 있는 FROM을 확인하고, 바깥쪽으로 쿼리문을 읽어야 함
- 이 과정이 직관적이지 않고, 쿼리를 보는 시간을 늘림
- 아래 쿼리를 보면 FROM customer 부터 이해를 하고, 그 안에 있는 부분 => 바깥을 이해해야 함

SELECT
  c_count,
  COUNT(*) AS custdist
FROM (
  SELECT
    c_custkey,
    COUNT(o_orderkey) c_count
  FROM customer
  LEFT OUTER JOIN orders ON c_custkey = o_custkey
  AND o_comment NOT LIKE '%unusual%packages%'
  GROUP BY c_custkey
) AS c_orders
GROUP BY
  c_count
ORDER BY
  custdist DESC,
  c_count DESC;

동일한 컬럼들의 반복

SELECT, GROUP BY, ORDER BY 등에 중복된 컬럼을 사용하는 경우가 있음
하나의 컬럼을 변경할 때, 다른 곳을 모두 변경해야 함(물론 GROUP BY는 GROUP BY ALL로 대체할 수 있긴 함)
아래 쿼리에서 SELECT에 있는 컬럼을 바꾸면 GROUP BY, ORDER BY도 수정해야 할 수 있음

SELECT
  department,
  employee_name,
  salary, 
  RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank
FROM employees
GROUP BY
  department,
  employee_name,
  salary
ORDER BY
  department,
  rank

GoogleSQL의 시도 : PIPE 구문 추가

GoogleSQL에선 새로운 언어를 만드는 방법이 아닌 기존 SQL 기능을 확장해서 문제를 해결하려고 함
- SQL에 data flow syntax를 추가했고 확장하기 쉽고 유연하게 되었음
- data flow syntax는 쉘 커맨드의 파이프 구문, 스파크의 체이닝과 유사하다고 보면 됨
SQL에서 표준 절은 정의된 하나의 순서로 발생함. 파이프 구문을 사용하면 임의의 순서로 연산을 만들 수 있음

FROM Produce
|> WHERE item != 'bananas' AND category IN ('fruit', 'nut')
|> AGGREGATE COUNT(*) AS num_items, SUM(sales) AS total_sales
   GROUP BY item
|> ORDER BY item DESC

BigQuery PIPE 문법의 특징

Linear Flow : 순차적 실행
Reduced Nesting : 서브쿼리를 사용하지 않음
재생산성이 가능하고 직관적임
FROM 부터 시작함
파이프 연산자로 |>을 사용함
파이프 연산자는 유효한 쿼리 뒤에 계속 추가할 수 있음
아래 이미지를 보면 파이프 문법에선 의미론적인 순서와 동일해짐

파이프 문자(|>)를 사용하는 이유

친숙함과 선례 관점
- (1) 유닉스 파이프는 널리 이해되는 패러다임으로, 이 구문과 동작을 친숙하고 이해하기 쉽게 만듦
- (2) 다른 데이터 처리 언어(예: KQL)도 파이프 구문을 사용함
- (3) 파이프와 같은 데이터 흐름은 Pandas DataFrames와 Apache Beam 등의 데이터 처리 프레임워크에서도 사용됨
기술적 관점
- (1) 파이프 연산자를 사용하면 어디서 구문이 시작되는지 명확히 알 수 있음
- (2) 파싱하는 방법이 간단해져서 확장성이 증가됨
- (3) 파이프 연산자는 이전 단계의 결과에 존재하는 컬럼만 접근할 수 있음. 명확해지고 예측이 가능해짐
- (4) 파이프 연산자를 사용해서 순차적으로 연산을 진행할 수 있음
가독성 관점
- (1) 언제 파이프 연산자로 전환되는지 인식하기 수월함
- (2) 여러 절로 구성된 파이프 연산자를 하나의 논리적인 단위로 인식할 수 있게 해줌
```
  |> AGGREGATE SUM(sales) AS total_sales, AVG(price) AS avg_price
     GROUP BY region, product
```
- (3) 구조적 가시성 : 쿼리를 순차적인 N개의 연산으로 표현 가능. 쿼리의 논리적 흐름을 시각적으로 더 잘 반영함
파이프 문자로 |을 사용할 수 있지만, 비트 연산에 사용되기 때문에 헷갈리고 충돌이 생기게 됨. 그래서 |>을 선택함

BigQuery PIPE 문법

공식 문서에서 확인할 수 있고, 앞으로 계속 늘어날 것으로 예상
일반적으로 사용하는 FROM, SELECT, JOIN, WHERE, LIMIT, ORDER BY은 동일하다고 생각하면 됨
아래에선 PIPE 문법 중 특별한 부분만 기록

SET

SELECT * REPLACE(expression AS col)와 동일한 표현
컬럼을 다른 값으로 대체함

(
  SELECT 1 AS x, 11 AS y
  UNION ALL
  SELECT 2 AS x, 22 AS y
)
|> SET x = x * x, y = 3;

/*
+---+---+
| x | y |
+---+---+
| 1 | 3 |
| 4 | 3 |
+---+---+
*/

EXTEND

SELECT *, new_col과 동일한 표현
기존 테이블의 모든 컬럼에 새로운 컬럼 추가
- 파이프 문법에선 이전 결과에 나오는 컬럼만 선택할 수 있어서 EXTEND를 사용해야 할 수 있음

(
  SELECT 'apples' AS item, 2 AS sales
  UNION ALL
  SELECT 'carrots' AS item, 8 AS sales
)
|> EXTEND item IN ('carrots', 'oranges') AS is_orange;

/*
+---------+-------+------------+
| item    | sales | is_orange |
+---------+-------+------------+
| apples  | 2    | FALSE     |
| carrots | 8    | TRUE      |
+---------+-------+------------+
*/

AGGREGATE

전체 테이블 또는 컬럼의 값에 대한 집계 수행

전체 테이블 집계

  -- Full-table aggregation
  (
    SELECT 'apples' AS item, 2 AS sales
    UNION ALL
    SELECT 'bananas' AS item, 5 AS sales
    UNION ALL
    SELECT 'apples' AS item, 7 AS sales
  )
  |> AGGREGATE COUNT(*) AS num_items, SUM(sales) AS total_sales;
    
  /*
  +-----------+-------------+
  | num_items | total_sales |
  +-----------+-------------+
  | 3        | 14        |
  +-----------+-------------+
  */

GROUP BY와 함께 사용해서 집계

  -- Aggregation with grouping
  (
    SELECT 'apples' AS item, 2 AS sales
    UNION ALL
    SELECT 'bananas' AS item, 5 AS sales
    UNION ALL
    SELECT 'apples' AS item, 7 AS sales
  )
  |> AGGREGATE COUNT(*) AS num_items, SUM(sales) AS total_sales
     GROUP BY item;
    
  /*
  +---------+-----------+-------------+
  | item   | num_items | total_sales |
  +---------+-----------+-------------+
  | apples  | 2       | 9         |
  | bananas | 1       | 5         |
  +---------+-----------+-------------+
  */

GROUP AND ORDER BY를 사용하면 컬럼을 반복적으로 입력하지 않아도 괜찮음

  -- Aggregation with grouping and order by
  (
    SELECT 'apples' AS item, 2 AS sales
    UNION ALL
    SELECT 'bananas' AS item, 5 AS sales
    UNION ALL
    SELECT 'apples' AS item, 7 AS sales
  )
  |> AGGREGATE COUNT(*) AS num_items, SUM(sales) AS total_sales
     GROUP AND ORDER BY item;

PIVOT

StandardSQL의 PIVOT 함수를 사용할 수도 있음
열(Row)을 컬럼(Column)으로 회전

(
  SELECT "kale" AS product, 51 AS sales, "Q1" AS quarter
  UNION ALL
  SELECT "kale" AS product, 4 AS sales, "Q1" AS quarter
  UNION ALL
  SELECT "kale" AS product, 45 AS sales, "Q2" AS quarter
  UNION ALL
  SELECT "apple" AS product, 8 AS sales, "Q1" AS quarter
  UNION ALL
  SELECT "apple" AS product, 10 AS sales, "Q2" AS quarter
)
|> PIVOT(SUM(sales) FOR quarter IN ('Q1', 'Q2'));

/*
+---------+----+------+
| product | Q1 | Q2  |
+---------+-----------+
| kale    | 55 | 45  |
| apple   | 8  | 10  |
+---------+----+------+
*/

UNPIVOT

컬럼(Column)을 열(Row)로 회전

(
  SELECT 'kale' as product, 55 AS Q1, 45 AS Q2
  UNION ALL
  SELECT 'apple', 8, 10
)
|> UNPIVOT(sales FOR quarter IN (Q1, Q2));

/*
+---------+-------+---------+
| product | sales | quarter |
+---------+-------+---------+
| kale   | 55    | Q1    |
| kale   | 45    | Q2    |
| apple  | 8     | Q1    |
| apple  | 10    | Q2    |
+---------+-------+---------+
*/

UNION ALL BY NAME

UNION ALL을 할 때 이름으로 자동으로 매칭해줌(UNION ALL만 사용하면 순서도 맞춰줘야 함

SELECT 1 AS one_digit, 10 AS two_digit
|> UNION ALL BY NAME
    (SELECT 20 AS two_digit, 2 AS one_digit);

/*
+-----------+-----------+
| one_digit | two_digit |
+-----------+-----------+
| 1        | 10      |
| 2        | 20      |
+-----------+-----------+
*/

CALL

테이블 값 함수(Table Value Function, TVF) 호출
- TVF가 궁금하면 공식 문서 참고

FROM input_table
|> CALL tvf1(arg1)
|> CALL tvf2(arg2, arg3);

WINDOW

윈도우 함수 계산하고 싶을 때 사용
- 윈도우 함수는 AGGREGATE와 사용하는 것이 아니고 WINDOW를 명시해서 사용해야 함

(
  SELECT 'apples' AS item, 2 AS sales
  UNION ALL
  SELECT 'bananas' AS item, 5 AS sales
  UNION ALL
  SELECT 'carrots' AS item, 8 AS sales
)
|> WINDOW SUM(sales) OVER() AS total_sales;

/*
+---------+-------+-------------+
| item   | sales | total_sales |
+---------+-------+-------------+
| apples  | 2    | 15        |
| bananas | 5    | 15        |
| carrots | 8    | 15        |
+---------+-------+-------------+
*/

DROP

컬럼을 제외하고 싶을 때 사용

SELECT 'apples' AS item, 2 AS sales, 'fruit' AS category
|> DROP sales, category;

/*
+--------+
| item  |
+--------+
| apples |
+--------+
*/

RENAME

컬럼의 이름을 변경하고 싶은 경우 사용

SELECT 1 AS x, 2 AS y, 3 AS z
|> AS t
|> RENAME y AS renamed_y
|> SELECT *, t.y AS t_y;

/*
+---+-----------+---+-----+
| x | renamed_y| z | t_y |
+---+-----------+---+-----+
| 1 | 2       | 3 | 2  |
+---+-----------+---+-----+
*/

AS

Input 테이블에 대해 Alias를 지정하고 싶을 때 사용
- WITH base 대신 AS를 바로 사용해서 쓸 수 있음

(
  SELECT "000123" AS id, "apples" AS item, 2 AS sales
  UNION ALL
  SELECT "000456" AS id, "bananas" AS item, 5 AS sales
) AS sales_table
|> AGGREGATE SUM(sales) AS total_sales GROUP BY id, item
-- The sales_table alias is now out of scope. We must introduce a new one.
|> AS t1
|> JOIN (SELECT 456 AS id, "yellow" AS color) AS t2
   ON CAST(t1.id AS INT64) = t2.id
|> SELECT t2.id, total_sales, color;


/*
+-----+-------------+--------+
| id  | total_sales| color  |
+-----+-------------+--------+
| 456 | 5         | yellow |
+-----+-------------+--------+
*/

언제 유용할까?

BigQuery 처음 학습하는 분들에게 추천
- 그러나 회사에서 BigQuery를 사용하지 않으면 애매함(다른 DB에선 아직 지원을 안할 수 있으므로)
Text to SQL을 구현할 때 추천
- 기존의 SQL 쿼리에서 파싱이 어려웠는데, 이젠 명확하게 쿼리를 분석하기 좋음
- 자연어로 쿼리를 생성할 때, 파이프를 사용하는 것이 더 유리할 것으로 예상
- 유사하게 Programmatic하게 쿼리를 생성할 때도 추천
데이터 엔지니어링 파이프라인
- 데이터 엔지니어링 파이프라인 중 Flow가 중요한 경우 추천
- 쉘 커맨드에서 데이터를 처리하는 것처럼 사용할 수 있음

문법 정리

문법을 잘 정리된 형태로 보면 좋을 것 같아, 별도의 웹페이지로 제작함
- BigQuery Guide Book - 빅쿼리 가이드북 - PIPE Cheatsheet 참고

StandardSQL vs Pipe 쿼리 비교

초보자를 위한 BigQuery(SQL) 입문 강의에서 진행한 연습 문제 쿼리를 비교

StandardSQL

  SELECT
    p.type1,
    COUNT(tp.id) AS pokemon_cnt
  FROM (
    SELECT
      id,
      trainer_id,
      pokemon_id,
      status
    FROM basic.trainer_pokemon
    WHERE
      status IN ("Active", "Training")
  ) AS tp
  LEFT JOIN basic.pokemon AS p
  ON tp.pokemon_id = p.id
  WHERE
    type1 = "Grass"
  GROUP BY
    type1
  ORDER BY
    2 DESC 

PIPE

  FROM basic.trainer_pokemon AS tp
  |> WHERE status IN ('Active', 'Training')
  |> LEFT JOIN basic.pokemon AS p
    ON tp.pokemon_id = p.id  
  |> WHERE type1 = 'Grass'
  |> AGGREGATE
    COUNT(tp.id) AS pokemon_cnt
    GROUP BY p.type1
  |> ORDER BY pokemon_cnt DESC

확실히 더 직관적이고, 짧아짐

Firebase, 앱 로그 데이터의 퍼널 쿼리 비교

BigQuery 활용편(퍼널 분석, 리텐션 분석)에서 진행한 쿼리 비교

StandardSQL

  WITH base AS (
    SELECT
      event_date,
      event_timestamp,
      event_name,
      user_id,
      user_pseudo_id,
      platform,
      MAX(IF(event_param.key = "firebase_screen", event_param.value.string_value, NULL)) AS firebase_screen,
      MAX(IF(event_param.key = "session_id", event_param.value.string_value, NULL)) AS session_id
    FROM advanced.app_logs
    CROSS JOIN UNNEST(event_params) AS event_param
    WHERE
      event_date BETWEEN "2022-08-01" AND "2022-08-18"
    GROUP BY ALL
  ), filter_event_and_concat_event_and_screen AS (
    SELECT
      * EXCEPT(event_name, firebase_screen, event_timestamp),
      CONCAT(event_name, "-", firebase_screen) AS event_name_with_screen,
      DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime
    FROM base
    WHERE
      event_name IN ("screen_view", "click_payment")
  )
  SELECT
    event_date, # 일자별로 퍼널별 유저 수 쿼리
    event_name_with_screen,
    CASE 
      WHEN event_name_with_screen = "screen_view-welcome" THEN 1
      WHEN event_name_with_screen = "screen_view-home" THEN 2
      WHEN event_name_with_screen = "screen_view-food_category" THEN 3
      WHEN event_name_with_screen = "screen_view-restaurant" THEN 4
      WHEN event_name_with_screen = "screen_view-cart" THEN 5
      WHEN event_name_with_screen = "click_payment-cart" THEN 6
    ELSE NULL
    END AS step_number,
    COUNT(DISTINCT user_pseudo_id) AS cnt
  FROM filter_event_and_concat_event_and_screen
  GROUP BY ALL
  HAVING step_number IS NOT NULL
  ORDER BY event_date, step_number

PIPE

좀 더 간결하게 만들 수 있을 것 같지만 일단 이정도로 올려봄

  FROM advanced.app_logs
  |> CROSS JOIN UNNEST(event_params) AS event_param
  |> WHERE event_date BETWEEN "2022-08-01" AND "2022-08-18" AND event_name IN ("screen_view", "click_payment")
  |> AGGREGATE
     MAX(IF(event_param.key = "firebase_screen", event_param.value.string_value, NULL)) AS firebase_screen,
     MAX(IF(event_param.key = "session_id", event_param.value.string_value, NULL)) AS session_id
     GROUP BY event_date, event_timestamp, event_name, user_id, user_pseudo_id, platform
  |> SELECT
      * EXCEPT(event_name, firebase_screen, event_timestamp),  
      CONCAT(event_name, "-", firebase_screen) AS event_name_with_screen,
      DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime
  |> EXTEND
      CASE
        WHEN event_name_with_screen = "screen_view-welcome" THEN 1
        WHEN event_name_with_screen = "screen_view-home" THEN 2      
        WHEN event_name_with_screen = "screen_view-food_category" THEN 3
        WHEN event_name_with_screen = "screen_view-restaurant" THEN 4       
        WHEN event_name_with_screen = "screen_view-cart" THEN 5
        WHEN event_name_with_screen = "click_payment-cart" THEN 6        
        ELSE NULL
      END AS step_number
  |> WHERE step_number IS NOT NULL    
  |> AGGREGATE
       COUNT(DISTINCT user_pseudo_id) AS cnt
       GROUP BY event_date, event_name_with_screen, step_number
  |> ORDER BY event_date, step_number

StandardSQL -> PIPE 마이그레이션 가이드

1주일 정도 파이프 문법을 사용하면서 어떻게 옮겨야 할까? 생각해보고 작성한 내용입니다. 추후에 더 추가될 수도 있음
FROM 절은 항상 쿼리의 시작
- 기존: FROM 절이 SELECT 절 뒤에 위치
- 파이프: FROM 절을 쿼리의 가장 앞으로 이동
JOIN은 FROM 절 안에 포함하거나 파이프 연산자로 분리
- 기존: FROM 절 안에서 JOIN 사용
- 파이프: FROM 절 안에 JOIN을 그대로 사용하거나, 별도의 파이프 연산자로 분리
WHERE 절은 필터링이 필요한 위치에 파이프 연산자를 사용하여 배치
- 기존: WHERE 절은 FROM 절과 GROUP BY 절 사이에 위치
- 파이프: WHERE 절을 필요한 위치에 파이프 연산자로 연결
SELECT 절은 주로 쿼리의 뒷부분에 파이프 연산자를 사용하여 배치
- 기존: SELECT 절이 쿼리의 맨 앞에 위치
- 파이프: SELECT 절을 필요한 위치에 파이프 연산자로 연결, 주로 쿼리의 뒷부분에 배치
GROUP BY와 집계 함수는 AGGREGATE 파이프 연산자를 사용
- 기존: GROUP BY와 집계 함수를 SELECT 절과 함께 사용
- 파이프: GROUP BY와 집계 함수를 AGGREGATE 파이프 연산자로 결합하여 사용
서브쿼리는 파이프 연산자를 사용하여 단계적으로 처리
- 기존: 여러 개의 중첩된 서브쿼리 사용
- 파이프: 파이프 연산자를 사용하여 서브쿼리를 단계적으로 연결(AS 사용)
불필요한 절과 구문은 제거하고 쿼리를 간소화한다.
- 기존: 복잡하고 중복된 구문 사용
- 파이프: 파이프 연산자를 활용하여 쿼리를 간소화하고 가독성 향상

참고 자료

글 작성하는데 걸린 시간 : 167분
- 하고자 하는 이야기, 개요 정리 : 10분
- 초안 글 작성 : 112분
- 초안 후 수정 : 45분
이 개념에 대한 학습은 150분 정도 소요

커리어 고민 상담을 하면서 많이 받은 고민 모음과 제 생각들

Sun, 16 Feb 2025 00:00:00 +0000

이 글은 커리어에 대해 고민이 있는 분들을 위해 작성한 글입니다
- 제 생각이 정답은 아니지만, 이런 의견도 있다는 것을 알려드리기 위해 작성했습니다
- 경력이 쌓이면서 했던 고민들과 깨달은 것들 글과 연결되는 글입니다
키워드 : 경력, 커리어, 개발자 커리어, 성장, 커리어 고민

고민은 왜 생기는걸까?

사람들을 여러 경로로 접하는데, 다양한 경로에서 각자만의 고민들이 있습니다
- 글쓰는 개발자 커뮤니티 글또
- 네이버 부스트캠프 AI Tech
- 인프런 수강생 커뮤니티
- 고민에 대해 다양하게 답변을 드리면서, ‘고민은 왜 생기는걸까?’라는 질문을 스스로에게 던졌습니다. 제가 자주 접하는 사람들의 환경은 어떤 특징이 있나? 생각했습니다.
  - 이 질문에 대해 답은 닫힌 형태가 아닌 열린 형태입니다. 여러가지 답이 나올 수 있고, 그게 누군가에겐 답이 될 수 있고 누군가에겐 답이 아닐 수 있지요.
- 제가 생각한 고민이 생기는 이유를 이어서 말씀드리겠습니다.

환경 관점

사람마다 주어진 환경이 다양한데, 이 환경엔 회사의 구조도 포함될 수 있고, 연차, 개인 삶, 산업적인 변화 등 다양한 내용을 포함할 수 있습니다. 특정 부분을 구체적으로 말해보면
요즘 기술 발전이 매우 빠르다
- 요즘 AI, LLM이 발전하면서 일상과 산업에 많은 부분이 바뀌고 있습니다. 변화가 빠른만큼 고민도 많이 있을 수 있는 시기입니다. AI가 미래에 발전하면 어떻게 될 것인가? 이런 고민을 하게 됩니다
회사마다 하는 일이 다르다
- 기술이 매우 빠르게 발전하고 있지만, 회사는 기술을 빠르게 적용해보는 회사와 그렇지 않은 회사가 있습니다. 이 부분은 회사의 기조에 따라 다를 수 있고, 회사가 진행하는 사업의 속성에 따라 다를 수 있습니다. 만약 규제가 심한 산업이라고 하면 새로운 기술 도입보단 안정적인 기술 도입을 고민하게 됩니다
- B2B 기업, B2C 기업, SI 기업 등 기업의 형태에 따라 다양할 수 있습니다
사람
- 회사에 있는 동료들의 성향도 다릅니다. 계속 발전하려는 사람들이 모인 팀이 있을 수 있고, 그 팀에 비슷하게 성장을 하려는 사람이 들어갈 수도 있고 성장에 대해 관심이 없는 사람이 들어갈 수도 있습니다
이럴 때 저는 환경을 통제 여부에 따라 나눕니다
- 통제할 수 있는 환경 : 내가 어떤 노력을 통해 변화할 수 있는 환경입니다. Input을 넣으면 (느리더라도) 조금씩 변화할 수 있다면 통제할 수 있는 환경이라 볼 수 있습니다
- 통제가 어려운 환경 : 내가 어떤 노력을 하더라도 변화할 수 없는 환경이 있습니다. 예를 들어 글로벌 트렌드(레이오프가 많이 발생하고 있고, 회사들의 수익성이 낮아지고 있다)나 취업 시장(채용보다 구직자가 더 많은 공급과 수요의 불균형)의 상황 등이 있습니다
- 대부분 통제할 수 있는 환경에 집중하려고 합니다
이런 환경을 어떻게 생각해야 할지는 밑에 고민들과 함께 말씀드릴게요

성장과 전문성 관점

개발자 커뮤니티에 예전부터 성장에 대한 이야기가 자주 언급됩니다. 저도 과거에 성장이 너무 좋아 성장을 이야기를 했으나, 이젠 성장을 더 구체적으로 정의하려고 합니다
- 성장의 정의를 구체적으로 해야하고, 정의는 시기에 따라 다를 수 있습니다
- 각자의 시기에 적절한 성장이 있습니다. 예를 들어 신입일 땐 주어진 업무를 잘 수행하는 것이 성장일 수 있고, 경력이 쌓이면서 성장은 나 혼자만 발전하는 것이 아니라 같이 일하는 사람의 성장, 팀장이 된다면 팀의 성장 등
- 이런 성장의 정의가 달라질 수 있고, 정의해야 한다는 것을 모르는 경우에 고민이 시작됩니다
전문성에 대한 고민
- 애플리케이션 개발자는 크게 서버, 프론트엔드, 모바일, 데이터, AI 등으로 나뉩니다. 이렇게 나뉘면 또 거기서 더 잘하려면 무엇을 해야하는가? 고민하게 됩니다.
- 자신의 성취, 인정 욕구가 있는 분이라면 전문성에 대한 갈망이 더 생기곤 합니다. 이런 욕구를 채우기 위해 전문성에 대해 계속 고민하는 경우를 종종 봤습니다.
또한 위에서 성장에 대해 자주 언급된다고 작성했는데, 그래서 개발자는 꼭 성장해야 한다는 고정 관념이 있는 경우가 있습니다
- 이런 경우에도 고민이 생기는데, 꼭 성장해야 한다는 생각을 하게 됩니다
- 성장을 꼭 해야하는 것은 아니고, 자신이 원하는 바를 구체적으로 정의하고 그 방향으로 가는 것이 필요합니다. 우리의 삶엔 직장만 있는 것이 아니고, 개인 삶도 있습니다. 그 시간을 발전시키는 것도 성장으로 볼 수 있습니다
- 또한 성장을 항상 해야하는 것은 아니고, 그냥 무엇을 안해도 괜찮을 수 있습니다. 유지되는 것도 성장으로 볼 수 있다고 생각합니다
개발자의 성장 방향이 다양합니다. 예를 들어 IC / Manager
- 개발자는 커리어가 쌓이면서 IC와 Manager로 트랙이 나뉘곤 합니다
- IC는 Individual Contributor로 간단하게 말하면 실무에 더 집중하는 사람이라고 볼 수 있고, Manager는 팀을 매니징하는 팀장 역할을 하는 사람이라고 볼 수 있습니다
- 해외에서는 IC와 Manager 역할이 나뉘는 편인데, 한국은 팀장이 둘 다 하는 경우도 있고, 스타트업에선 빠르게 팀 리드를 하는 경우도 있습니다
- Manager를 한번 하면 실무자로 돌아가기 어렵다는 고정 관념이 있습니다. 실제로 어느정도 맞을 수 있지만, 이런 고정 관념이 있다면 성장 방향에 대해 고민하게 됩니다(내가 지금 하는게 맞나?)
개발자가 아니더라도 다른 직무로 확장할 수 있습니다
- 요즘은 1인으로 일을 하는 분들도 많아지고 있고, 내 사업을 할 수도 있고, 다른 직무로 커리어 전환을 할 수 있습니다
- 내 의지와 실행력이 있다면 새로운 것을 할 수 있는 곳이라 오히려 고민이 생기는 경우도 봤습니다
- 혹은 지역을 국내 -> 해외로 바꾸는 것도 가능합니다

비교하는 행위

위에서 전문성, 성장에 대해 이야기가 많다고 했는데, 이런 이야기를 들으면 다른 사람과 비교를 하게 됩니다
이런 비교를 하면 여러 불안감이 생깁니다
- 나는 도태되면 어쩌지?
- 내 커리어 망하는거 아닌가?
- 저 사람은 잘 하는데 왜 나는 안되지?
우리는 사람들과 같이 사회를 꾸리고 있기 때문에, 대부분 다른 사람이 존재할 수 밖에 없습니다. 특히 SNS를 보면 실제로 모르는 사람이여도 관계를 간접적으로 형성할 수 있습니다.
- 그러다가 자연스럽게 비교를 하게 됩니다
이 부분은 부트캠프에서 특히 더 발현됩니다. 부트캠프에선 모두 다 취업을 위해 공부하는 동기생이 되는데, 그 때 실력의 편차가 있지만 그 편차를 처음엔 모르고 프로젝트나 과제를 하면서 알게 됩니다. 그러면서 난 왜 못하는가에 대해 고민이 시작되곤 합니다

일과 삶 균형 관점

처음에 일을 시작할 때는 너무 재미있어서 즐길 수 있는데, 그러다가 야근을 계속 할 수 있습니다. 그러다가 3~4년이 지나면, 건강에 적신호가 올 수 있습니다. 보통 건강에 문제가 있다는 것을 느끼기 전에는 관성을 유지하며 일을 하다가, 아픈 시기가 옵니다. 주로 허리, 목, 관절 등이 아파질 수 있습니다
- 한번 아프면, 과거에 하던 행동들을 그대로 하는 것이 좋지 않을 수 있겠구나 생각하며 고민을 시작하곤 합니다
- 그러면서 점점 일과 삶의 적절한 균형점을 찾아가려고 하는 경우가 있습니다
또한 가정을 꾸리고, 육아를 하는 분들은 시간이란 제약 조건이 더 강해지기 때문에 어떤 것을 선택하고, 어떤 것을 선택하지 않을지 결정해야 합니다. 이런 관점에서 균형을 찾으려고 노력합니다
이런 균형을 찾는 과정에서 시간 관리를 어떻게 해야 잘할 수 있을까?를 고민하게 됩니다

메타인지

일이나 삶에서 자신을 잘 이해하는 능력인 메타인지가 매우 중요합니다. 이게 중요한 이유는 자신을 이해해서, 자신만의 기준이 형성되고, 오롯이 나의 실행에 집중할 수 있습니다
번아웃이 오면 어떻게 해야할까요? 스트레스 해소를 어떻게 해야할까요? 언제 이직을 해야할까요? 앞으로 어떤 것을 해야할까요? 회사를 어떤 기준으로 선택해야 할까요?
- 위에 나온 5개의 질문을 모두 메타인지 관점으로 치환할 수 있습니다
- 자신의 기준이 얼마나 있는가? 자신이 얼마나 그것에 대해 생각했는가? : 이 관점으로 생각해보는 것을 추천합니다
자신의 기준이 없는 경우엔 흔들리기 쉽습니다
- 예를 들어 어떤 시니어분과 커피챗을 했는데, 그 시니어분이 무조건 A를 해야한다고 하거나, 제가 하는 모든 행위는 쓸모없다고 이야기를 한 경우에 어떤 생각이 드실 것 같으신가요?
  - A를 해야한다는 관점은 근거가 납득이 된다면 이해할 수 있습니다
  - 모든 행위를 쓸모없다고 한 경우는 일단 내 모든 것이 부정당한 것 같아 부정적인 감정이 생기기 쉽습니다
  - 이럴 때 자신만의 기준이 있다면, 타인의 피드백이나 의견을 자신의 필터링에 걸러서 생각할 수 있으나, 만약 필터링이 없다면 바로 내상을 입기 쉽습니다
나는 어떤 일을 하고 싶은가를 넘어서서 어떤 문제를 해결하고 싶은가?
- 문제를 해결하고, 그 후에 어떤 기술을 사용할지가 결정됨. 따라서 어떤 문제를 풀고 싶은 사람인지 생각하는 것이 필요합니다. 나의 비전과 유사하다고 볼 수 있습니다
- 문제는 산업이 될 수도 있고, 특정 현상이 될 수도 있습니다

자주 나오는 고민

자주 할 수 있는 고민들을 추상화해서 작성해봅니다. 또 다른 고민이 있다면 댓글로 남겨주세요

제가 잘하고 있을까요? 1년 동안 한 일이 없어요

1년을 되돌아보니 한 것이 없고, 회사를 다녀도 성장보다 퇴화하는 것 같다는 내용의 고민
- 이 고민을 시작하게 된 이유는 여러가지가 있겠지만, 위에서 언급한 고정 관념, 비교, 메타인지가 혼합된 결과라 생각합니다
제 생각
- 1년, 1년으로 볼 땐 변화가 크지 않을 수 있어요. 보통 변화는 몇년이 쌓여서 축적된 후에 보이는 것 같아요
- 이럴 때 저는 현상 유지만 되어도 성장이라 생각해요(성장을 1년 단위로 보는 것이 아닌 누적형 그래프로 봄)
- 1년이란 주기가 아닌 3~4년 주기로 넓게 보니까 성장한 것을 확실히 느낄 수 있었어요
- 잘하고 있다의 정의도 사람마다 다양합니다
  - 자신만의 성장을 정의해보는 것을 추천합니다
  - 내가 새로운 것을 할 수 있는 역량이 생겼는가? 1년 동안 새롭게 구현한 것들을 작성해보면 생각보다 성장했을 수 있습니다. 본인이 그걸 성장이라 생각하지 않고 거창하거나 추상적인 개념을 성장이라 생각하는 경우도 있습니다
- 그리고 꼭 성장해야 하는 것은 아닙니다. 자신의 욕구가 무엇인지 생각해보고 그거에 맞게 실행하는 것이 핵심입니다. 나의 기준과 패턴을 만드는 것이 중요하지 너무 성장에 매몰되지 않아도 됩니다.
- 경력이 낮을 때 지금 망하면 미래가 망가질 것 같다고 생각해서 걱정하는 경우가 있는데, 경험이 쌓여 어떤 사람이 됩니다. 결국 지나면 무엇이든 되어있더라구요. 그 순간을 집중해서 살면 된다고 생각합니다
- 다른 사람들의 회고를 보면서 이런 생각을 하는 경우도 있는데, 누군가의 회고를 보고 내가 본받을 점을 집중하는 것을 추천합니다. 그 사람이 얼마나 대단했다보단, 그 경험을 보고 내가 뭘 할 수 있을까?를 생각하는 것이지요
  - 이렇게 하면 비교가 아니라 어떻게 내게 적용할까?라는 생각을 하면서 왜 나는 못해?라는 생각을 덜 하게 됩니다
  - 같은 내용을 보더라도 누군가는 질투를 하고, 누군가는 본받을 점을 찾습니다. 여러분들은 어떤 사람이 되길 바라시나요?
- 기술적인 성장 방향성에 대해 고민하고 싶은 경우엔 드랍박스 커리어 프레임워크를 추천합니다
  - 드랍박스에선 개발자에게 어떻게 레벨을 부여하고, 어떤 역할을 기대하는지 작성되어 있어요
  - 물론 이 내용이 진리는 아니고 하나의 샘플이라고 생각하면 됩니다. 드랍박스에선 이렇게 하는구나! 정도로 생각하고 난 뭘 해야 할까?에 대해 생각해보는 것을 추천합니다
- 남과 비교를 너무 하신다면, 정확하게 비교를 해보시는 것을 추천합니다. 지금 8년차인 분과 비교하는 것이 아니라 8년차인 분의 지금 내 연차 때 어떠했는가를 비교하는 것이 더 좋을 수 있지요. 데이터 분석에서 나오는 코호트 관점으로 분석해야 합니다
  - 이 내용은 인스타그램에 올린 남과 비교해서 힘들면 어떻게 해야할까?를 읽어보시면 도움이 될 것 같습니다

무기력증이 온 것 같아요. 어떻게 해야 할까요?

갑자기 무기력증이 왔습니다. 예전엔 열심히 살았는데, 갑자기 다 하기 싫고 무기력증이 왔어요. 집에서 SNS만 하고 누워있어요
- 이 고민도 자주 나오는 고민 중 하나입니다. 여기서 이 무기력증이 왜 왔는가?를 스스로 생각해보는 것이 중요합니다. 이유에 따라 해결 방법이 다르니깐요
- 이 고민은 일과 삶 균형 관점, 메타인지 관점의 고민이라 생각합니다
제 생각
- 제 주변에서 이렇게 말하신 분들은 대부분 과거에 열심히 살았던 적이 있습니다. 목표가 있고 그 목표를 향해 열심히 했던 경험이 있다가, 갑자기 무기력증이 왔다고 하는 비율이 많았습니다
- 20대나 연차가 낮을 때 열심히 달려왔는데, 갑자기 앞으로 남은 인생에서 계속 이렇게 해야하나? 고민하는 경우도 있었어요
- 저는 무기력증을 에너지가 있는데, 어디로 가야할지 방향을 잃어서 결국 몸에 가득차서 터진 것 같다고 설명합니다. 그러다가 표류를 하고 있다는 생각이 드는거지요.
- 이럴 땐 내가 앞으로 어디로 가야할까? 난 앞으로 뭐하고 살까?에 대해 생각해보는 것을 추천합니다
  - 단순히 한국에서 하는 것보단 해외에 나가서 다른 사람들이 어떻게 사는지 보는 것도 추천합니다
  - 문화적인 요소로 해외의 대학생분들과 한국의 대학생들은 관점이 다른 경우가 있더라구요. 다양한 관점이 있구나를 인지하면 생각하기 더 좋았습니다
  - 저는 서울이 아닌 곳에서 이런 생각을 하곤 합니다. 서울은 너무 일상적인 공간이라 새로운 생각이 잘 안떠오르더라구요. 혹은 혼자가 아닌 다른 사람들과 같이 하는 것도 추천해요
- 그리고 나 개인의 성장만 집중했다면, 내 인생의 여러 요소를 발전 시켜보는 것도 추천합니다. 직무 관점이 아닌 나의 취미는? 내가 하는 운동은? 인간 관계에 대한 발전, 가족과의 관계 발전 등 단순히 나만 생각하는 것이 아니라 다른 사람들과 시간을 보내면서 새로운 가치를 얻는 경우도 있습니다
  - 그러면서 열심히 사는 사람들에게 영감을 받아 새로운 것을 해보는 것도 가능하지요. 사람을 통해 내 무기력증을 점점 옅게 만들고, 나의 열정도 다시 올릴 수도 있습니다(제 경험담)
  - 인생에서 일만 있는 것이 아닌, 여러 관점이 있구나. 지금 내가 키우고 싶은 것은 무엇인가? 이런 생각을 하는 것이지요
- 인스타그램에 올린 내용도 보시는 것을 추천합니다
  - 무기력에 대한 생각
  - 번아웃을 극복하니 10가지 방법 : 마지막 도식화처럼 자신만의 해결 방법을 도식화하는 것을 추천해요

시간 관리는 어떻게 해야 할까요?

시간 관리는 연차가 낮을 때, 연차가 높을 때 항상 나오는 주제 같습니다. 우리는 시간에 한정적인 존재라서 그런 것 같고, 회사를 나와 혼자 일을 할 때도 이런 시간 관리에 대해 고민하게 됩니다
- 이 고민은 일과 삶 균형 관점, 성장과 전문성, 메타인지 관점이 연결된 고민 같습니다
제 생각
- 시간 관리를 해야겠다고 생각하는 사람들은 보통 발전을 하려고 여러가지 시도를 하고 있는 사람들일 가능성이 있습니다. 시도를 안하고 있다면 사실 시간 관리에 대한 고민보단 뭘 해야할까에 대해 생각할 확률이 높은 것 같네요
- 하고 싶은 것은 A, B, C 인데 1주에 가용 시간이 N시간이 있어서 고민된다. 그리고 과거의 경험에 의해 모두 다 시도하면 아무것도 안되는 것을 알고 있는 상황일 때 더 고민이 크게 됩니다
- 이런 고민으로 시간 관리 방법 등을 검색해서 보는 분들이 많을겁니다. 이런 것도 좋습니다. 저는 아예 날 잡고 시간 관리 방법 영상 1~2시간 정도 빠르게 봅니다(주로 2배속으로 여러 영상을 봄)
- 그리고 그 방법 중 내가 에너지가 덜 들면서 적용할 수 있을 것 같은 것으로 시작합니다. 나를 너무 많이 바꾸면서 시간 관리를 하려고 하면 본질적인 시간 관리를 못하고 새 방법론에 적응하느라 시간을 다 쓰게 됩니다. 이 때 핵심은 우리가 시간을 잘 쓰는 것입니다
- 제가 쓰는 방법은 일단 측정합니다. 내가 시간을 얼마나 잘 쓰고 있는가? 스프레드시트에도 좋고, 1시간 단위로 작성할 수 있는 노트에도 좋습니다. 일단 내가 시간을 얼마나 쓰고 있고, 얼마나 집중하는지 데이터를 쌓습니다. 그 후에, 내가 낭비하고 있는 것을 줄이고 집중하고 싶은 것을 집중할 수 있는 것을 늘려봅니다
  - 이게 시간 관리의 핵심이라 생각합니다. 그래서 저는 항상 컴퓨터에서 무엇을 하는지 시간을 측정하고 있습니다
  - 이 내용은 데이터 과학자의 시간 관리 방법 : RIZE 에 작성되어 있습니다
- 그리고 시간 관리는 한방에 되는 것이 아니라, 지속적으로 최적화하는 과정이라고 인지하면 좋습니다
  - 한번에 뿅! 되는 것을 기대하면 조급해집니다. 빨리 이걸 해결해야 한다고 생각하거든요
  - 오랜 시행착오의 과정으로 시간 관리를 점점 할 수 있게 된다고 생각하면 마음 관점에서 더 좋았습니다. 대부분의 일은 심리 상태가 중요하기에 이 부분을 꼭 말씀드리고 싶습니다
- 시간 관리는 어떤 것을 선택하고, 포기하는 것이라 의사 결정 문제로 치환할 수도 있습니다.
  - 자신만의 의사결정 기준도 있으면 좋습니다. 이 부분도 메타인지의 한 영역이라 볼 수 있습니다
  - 저는 불확실성이 큰 상황에서 어떻게 의사 결정을 해야할지에 대한 기준이 있고, 불확실한 상황의 의사 결정 원칙에 정리되어 있습니다
- 인스타그램에 올린 시간 관리 원칙 만들기도 보시면 도움이 될 것 같아요

기술을 추구하는게 맞을까요? 어떤 기술을 공부해야 할까요? 트렌드는 어떻게 따라가죠?

비슷한 고민으로 지금 LLM이 엄청 발전하는데 지금이라도 커리어를 AI로 바꿔야 할까요?
- 환경, 성장과 전문성 관점, 메타인지 관점의 고민이라 생각
제 생각
- 직무 상관없이 자주 나오는 질문 중 하나인데, 어떤 기술 하나를 하면 내가 잘 먹고 잘 살 수 있겠지!라는 고정 관념이 있는 것 같습니다. 기술은 시간이 흐르면서 계속 발전합니다. 시간이 흐르면서 다양한 기술이 생겨서 모든 것을 다 흡수하려고 하면 시간 관리의 이슈가 생기고, 부담감이 더 커지게 됩니다.
- 이럴 때 저는 문제 관점으로 생각해봅니다. 내가 어떤 문제를 해결해야 할까? 어떤 문제를 해결하고 싶어하는가?
  - 엥 트렌드 이야기하는데 왜 내가 나오죠?라고 하는 경우도 있는데 트렌드는 트렌드일 뿐입니다. 계속 바뀝니다. 그래서 트렌드에 맹목적으로 따라가면 결국 또 새로운 트렌드가 생길 때 따라가느라 힘들 수 있습니다.
  - 모든 트렌드를 따라가려 하기보다, 자신의 전문 분야와 관련된 핵심 변화에 집중하는 것이 중요합니다. 트렌드를 맹목적으로 쫓기보다는 선택적으로 수용하고 적용하는 전략이 필요합니다.
    - 예를 들어 LLM이 발전하고 있는 경우, LLM을 잘 활용해서 개발을 더 잘할 수 있는 방법을 고민해서 내 개발 역량을 올리는 것이 자신에 대한 관점이지요
  - 그 과정에서 어떤 것을 선택해야 하면 일단 다수가 하는 것이 좋은 선택이 될 수도 있습니다(예를 들어 백엔드는 자바, 프론트는 리액트 등) 이걸 하면서 내가 하고 싶은 문제를 잘 해결할 수 있는 관점을 찾고 그걸 깊게 파는 것도 좋다고 생각합니다. 그러다가 나중에 이 기술이 사람들이 많이 원하면, 같이 수혜를 입을 수 있습니다
  - 제프리 힌튼 교수님은 신경망 연구를 1980~90년대에 계속 해오셨습니다. 그 당시에 사람들은 회의적으로 바라봤지만, 끝까지 계속 하셔서 AI 시대의 초석을 만드셨지요
  - 내가 하고 싶은 것을 더 즐겁게 할 수 있고, 만약 결과가 좋지 않더라도 과정에서 배우는 것이 있을 수 있습니다. 그래서 저는 하고 싶은 것을 하라고 추천하곤 합니다
    - 물론 취준생분들은 이 말을 들으면 조급해서 못할 수도 있지만, 요즘은 취업에 집중해도 잘 안되는 시기입니다. 그런 시기라면 내가 하고자 하는 일도 집중해보는 것이 다른 사람들과 다른 차별점을 만들 수 있다고 생각합니다
- 저의 원칙들을 공유해봅니다
  - 다른 사람들이 다 하는 선택보다 다른 선택을 해보자
  - 특정 현상의 앞단이나 관련된 다른 문제를 찾아보자
  - 유행에 휩쓸리지 말고 그냥 하고 싶은 것을 해보자

이직은 언제 해야 할까요?

많은 분들이 이직을 마음 속에 품고 있는 시기 같습니다. 회사들이 어려워지고, 그런 상황에 더욱 이직을 해서 좋은 곳으로 가고 싶은 시기지요.
- 이 고민은 성장과 전문성 관점, 메타인지 관점의 고민이라 생각합니다
제 생각
- 환경을 통제할 수 있는 환경, 통제할 수 없는 환경으로 나눈다고 말씀드렸는데 그래서 많은 사람들이 통제할 수 있는 환경으로 회사를 옮기려고 합니다. 물론 이것도 하나의 방법이 될 수 있습니다.
- 그러나 저는 이 때 질문을 해봅니다
  - 회사에서 경험할 수 있는 것을 모두 다 하셨다고 생각하시나요?
  - 이 질문은 단순히 직무 관점의 경험만 의미하는 것이 아닙니다. 회사가 어떻게 돌아가고, 개발 조직 바깥에 있는 조직은 어떻게 일하는가? 대표님은 어떤 생각을 하는가? 회사들에선 어떻게 의사 결정을 하는가? 사람들과 어떻게 미팅을 하는가? 등 굉장히 넓은 관점입니다
  - 작은 조직이면 작은 조직 형태에서 적절한 의사결정 형태가 있고, 조직이 커지면서 다른 형태의 의사결정을 하게 됩니다. 그 과정을 보는 것도 큰 의미가 있습니다. 그래서 저는 작은 회사라서 배울 점이 없는 것은 아니고, 발전하는 과정을 익히는 것도 도움이 된다 생각합니다
  - 사업 조직은 신사업을 어떻게 시작하는가? 이 관점을 아시는지 궁금합니다
    - 만약 퇴사하고 혼자 1인 개발자로 살아가야 한다고 하면, 일종의 신사업을 시작하는 것과 유사합니다. 이럴 때 어떻게 해야할까요?
    - 1인 개발자 생활을 하면서 퍼포먼스 마케팅을 통해 회원을 유입해야 할 수도 있습니다. 마케팅은 어떻게 해야할까요?
    - 이렇게 회사에는 우리가 모르지만 다양한 업무가 진행되고 있습니다. 이런 관점을 많이 익힐수록 여러분들에게 도움이 된다 생각합니다. 일종의 숨겨진 퀘스트가 많은 것이지요
    - 삶을 바라보는 태도 - 인생을 게임처럼 살아보기에도 작성했는데, 저는 회사에서 숨겨진 퀘스트를 모두 다 경험하려고 합니다. 재무팀에 있는 분들과 이야기를 하면서 재무 관점에선 데이터를 어떻게 봐야하는지도 알게 되었고, 사업쪽에서 사업 전략은 어떻게 짜는지(데이터 분석과 유사하지만 어떤 결이 다른지), 법은 어떻게 검토해야지 등을 알게 되었습니다. 이건 스스로 얼마나 하는지에 따라 다르다고 생각합니다
  - 자신만의 기준 만들기 : 회사를 언제 옮길 것인가?
    - 회사를 옮긴다는 것도 기준을 만들 수 있습니다.
    - 내가 이 회사에 왜 입사했는가? 어떤 것을 얻고 싶어서 입사했는가?
    - 어떤 현상이 보이면 내가 더 다닐 것 같은가? 어떤 현상이 일어나면 내가 더 나가고 싶을까?
    - 시작점을 100점 정도로 시작해서 좋은 일이 있으면 +, 좋지 않은 일은 -를 합니다. 그리고 몇 점이 기준인지 측정합니다. 저는 보통 50점보다 낮아지면 이직을 해야할 수도 있겠다 생각합니다(이직을 바로 생각하는 것은 아니고 이직을 해야할 수도 있겠다!) 이 점수보다 낮아지는 기간이 오래 된다면 그 때 고민하곤 합니다
    - 이렇게 하는 이유는 사람들이 퇴사를 감정적인 이슈로 갑자기 결정하곤 합니다. 물론 감정이 매우 중요한 요소라 이렇게 하는 것도 가능하지만, 상황을 객관적으로 보지 못하는 경우가 있습니다. 감정은 감정대로 잘 해소하고, 객관적 상황도 보는 것도 필요하다고 생각합니다(이직이 그냥 잘 되는 시기엔 이렇게 안해도 되는데, 이직이 어려운 시기엔 이렇게 하는 것이 좋다고 생각합니다)
    - 제 기준도 하나의 예시라, 여러분들이 기준을 만드셨으면 좋겠습니다
    - 기준을 만들 때 돈보단 가치로 생각하는 것을 추천합니다. 돈으로 생각하면 생각이 제한적이게 될 수 있고, 결국 빨리 이직해야한다는 결론이 나오게 될 수 있습니다.

과거의 선택이 후회되거나 컨트롤이 어려운 사건으로 영향을 받을 땐 어떻게 해야할까요?

과거의 결정이 계속 자신에게 영향을 미쳐서 어떻게 해야할까? 고민하는 내용입니다
- 이 부분은 환경, 메타인지 관점의 고민이라 생각합니다
제 생각
- 일단 과거를 후회해서 과거로 돌아갈 수 있는게 아니라서, 후회보단 앞으로 지금 상황에 뭘 해야할지 고민합니다
  - 과거를 후회한다면 차라리 그 의사결정을 내가 왜 했고, 앞으로 안하려면 어떻게 해야하는지를 생각합니다
  - 후회가 너무 잠식을 한다면 그냥 후회를 끊으려고 합니다. 어차피 발생한 일이고 돌이킬 수 없습니다. 그럼 그냥 어쩔 수 없죠. 앞으로 다시 반복되면 그런 일이 안생기도록 메모해두고 지금을 잘 살려고 노력합니다
- 어떤 현상이 발생할 때, 현상과 나의 감정을 분리해서 생각하려고 합니다
  - 현상 : 오 이런 일이 발생했군 - > 내가 뭐 해야하지?
  - 감정 : 마음이 아프다 -> 마음을 케어하자
  - 이렇게 분리해서 내가 할 일을 나누는 편입니다. 물론 이게 명확하게 딱딱 정리되진 않을 수 있습니다. 그러나 의식에서 현상과 감정을 분리하는 것부터가 제 마음이 편해지는 것을 느꼈습니다. 지금 고민은 현상에서 나오는 것인지, 감정에서 나오는 것인지 생각합니다
  - 커리어를 쌓으면서 그리고 인생을 살아가면서, 점점 자신의 마음 상황을 컨트롤하는 역량이 필요한 것 같습니다. 내가 어떻게 해야 마음이 좋아질까, 언제 마음이 좋아지고 안좋아질까? 이런 것들을 알고 움직일 수 있는 레버를 아는 것이 필요하지요
  - 저는 제가 언제 행복감을 느끼는지 어느정도 정리해두어서, 행복해지고 싶을 때 이런 것들을 시도하곤 합니다. 그러니까 제가 더 나은 생각을 할 수 있게 되더라구요
  - 일상에서 소소하게 청소하는 것도 제게 행복감을 줘서, 청소를 매일 하면서 행복감을 느끼고 있습니다
  - 관련 내용은 인스타그램에 정리해두었습니다
    - 잘 쉬는 법에 대한 고찰
- 그리고 만약 멘탈이 너무 힘들거나 아프면 그걸 굳이 해결하지 않습니다. 그냥 아파합니다
  - 멘탈이 아프고, 힘들 때 억지로 회복하려면 힘듭니다
  - 슬픈 일이 생기면 울고, 감정에 솔직하게 살고 있어요
  - 아픔이 있으니 기쁨도 있고, 아픔을 느끼는 것이 이상한 것도 아니라 생각해요
  - 아파하는 나도 나의 일부이므로 내가 나를 아껴주자고 생각하고 있어요
- 정리하면 과거의 선택은 반복되지 않도록 대책을 세워보기, 컨트롤이 어려운 사건은 현상과 감정을 분리해서 생각해보기
- 이걸 잘 진행하려면 나를 잘 이해하는 것이 필요하고, 체력도 필요하고, 감정의 바닥을 치지 않도록 삶을 가꾸는 것이 필요한 것 같아요.

다른 사람은 다 잘 나가는 것 같고, 좋은 회사에 취업하네요. 저는 아니네요..

다른 사람들을 보다가 이런 생각을 하는 경우도 있습니다. 이 부분은 비교를 하면서 생긴 고민이라 생각합니다
- 네카라에 다니는 사람은 좋겠다.. 이런 생각을 하는 경우와 비슷합니다
제 생각
- 사람들은 모두 다 자신만의 시기가 있고, 어떤 사람들은 처음부터 큰 회사에 가는 경우도 있고, 어떤 사람들은 작은 회사에서 큰 회사로 가는 경우도 있습니다
- 보통 큰 회사를 더욱 동경하고, 멋있어보이고 그런 감정을 느낄 수 있어요
- 이럴 때 저는 그 분들은 어떤 노력을 해서 해당 기업에 들어갔을까? 라는 생각을 합니다. 그 분들이 어떤 노력을 해서 현재 상황에 그 회사에 있는거고 시간이 지나면 그 분들도 다른 작은 회사로 갈수도 있고 큰 회사로 갈 수 있지요.
- 스스로가 저기에 못가서 박탈감을 느끼는 것보단 ‘오 저 분은 특정 회사에 다니시는구나’라고 생각하고, 이런 회사에 다니는 분들의 특징을 살펴봅니다. 그 특징들이 공통적으로 있다면 나도 그 부분을 발현시킬 수 있는 노력을 하면 된다 생각합니다
- 그리고 좋은 회사의 기준은 사람마다 다르고, 우리가 생각하는 좋은 회사에 다니는 분도 고민이 다 있습니다
  - 구글, 마이크로소프트, 네이버 등 다양한 큰 기업에 다니는 분들도 각자의 고충이 있습니다. 결국 어떤 환경에 가더라도 거기서 새로운 고민이 나온다는 것을 의미합니다
  - 그래서 외부에서 보이는 것보다 자신이 어떤 회사에 가고 싶은지 고민하고 바로 가지 못하더라도 장기적으로 고민해보는 것을 추천하고 싶어요
- 이런 생각을 하는 분들은 취준 기간을 오래 해서 이런 생각이 들 수도 있습니다.
  - 이런 분들에겐 저는 이렇게 말합니다 : ‘우리는 인간으로서 존엄성이 있고 하루 하루 발전하려고 하는 사람이에요. 너무 자신을 낮추지 않으셨으면 좋겠어요’
  - 지금은 아니더라도 결국 나중에 될 수 있을거라 생각해요. 계속 노력한다면요
- 상대적 박탈감이 느껴진다고 하면, 그걸 좋은 관점으로 어떻게 승화할 수 있을까도 생각하는 것을 추천해요. 부정적인 생각을 계속 가지고 있으면, 부정적인 생각이 나를 잠식하더라구요. 생각을 잘 승화하는 것도 능력 중 하나입니다.
- 위에서 말씀드린 나만의 기준이 있는가? 이 질문도 꼭 생각해보세요. 물론 연차가 낮다면 아직 그런 기준이 없을 수 있는데, 회사에 가서 경험하시면서 기준을 만들면 됩니다

제 기준, 원칙

위에 답변들은 제가 자주 떠올리는 생각들을 재구성한 내용인데, 저도 항상 이게 정답이라 생각하진 않습니다. 시간이 지나서 몇년 후엔 제가 위에 내용을 다시 엎으며 생각할 수 있다고 생각해요(저도 경험을 계속 하니까)
- 그냥 이런 의견도 있구나~ 정도로 생각해주시면 됩니다
저는 책을 많이 읽고, 자신에 대해 생각을 많이 했습니다. 그러면서 나의 기준이 하나씩 생기더라구요. 어릴 땐 이런 생각을 가지진 못했습니다. 저도 그 땐 그냥 스킬, 단기적 관점만 생각했지요. 그러다가 책을 읽고, 다른 분들의 생각을 듣다가 발전해서 나만의 기준, 원칙을 가지게 되었습니다
여러분들도 자신만의 기준과 원칙을 만드셨으면 좋겠습니다
제게 크게 영향을 준 책들
- 안티프래질
- 함께자라기
- 상자 밖에 있는 사람
- 니체 철학
그리고 제가 정말 좋아하는 포켓몬이 메타몽입니다.
- 저는 어릴 때 제가 앞 번호와 유사해지는 것을 느꼈습니다. 앞 번호 친구가 공부하면 공부하고, 놀면 놀고.. 그래서 10대 때는 자아가 없나?라는 생각을 했어요
- 그러다가 군대 다녀오고 이게 어떻게 보면 장점이 될 수 있겠다 생각해서 많은 것들로 변하고, 그걸 흡수하는 삶을 살고 있습니다
- 메타몽은 환경에 따라 상대에게 변신합니다. 포켓몬도 가능하고, 물건도 가능합니다
  - 이렇게 유연하게 접근할 수 있는 포켓몬이고, 메타몽의 DnA는 정말 모든 내용들이 다 있다고 생각합니다
  - 그래서 메타몽은 무엇이든 될 수 있고, 메타몽의 특성을 가진 저도 무엇이든 될 수 있다!라고 생각하며 살고 있습니다
  - 특정 시기에 어떤 모습으로 변해있는 상태일 뿐이지요
  - 회사에서 일을 하면서 중요하게 생각하게 된 역량들은 환경 적응 능력과 실행력입니다. 주어진 환경에서 어떤 것이 핵심이고, 문제를 구체적으로 정의해서 어떻게 해야할까 고민하고 실행하는 것. 결국 이 두개가 있는 사람이 잘하는 것 같습니다. 그래서 저도 메타몽을 캐릭터로 쓰면서 항상 잘 변신하려고 합니다(실행력은 또 다른 문제지만 실행력을 늘리기 위한 여러 시도도 진행했어요)
- 모든 것을 다 대비하려고 하면 스트레스만 생겨서, 유연하게 접근하는 안티프래질 방법으로 사니까 너무 팍팍하게 살지 않게 되었고, 문제는 매일 생기니까 문제를 없애는 것보다 계속 최적화를 하면서 살아보자란 생각을 하고 있네요
그 과정에서 자신의 감정도 중요하니 감정을 잘 이해하고, 잘 다스릴 수 있도록 여러 책도 보고 시도도 많이 해왔습니다. 그러다가 자신의 기준과 원칙이 되었습니다
자신의 기준, 원칙을 만드는 것이 어렵다고 하시는 분들이 계셔서 이런 것들을 만드는 것을 도울 수 있는 방법을 고민하고 있습니다. 워크샵을 하거나, 챌린지 같은 것을 통해 나오게 하거나, 서로 이야기를 나누는 모임을 만들거나 등 여러가지를 고민하고 있어요. 의견 주시면 제 실행력에 큰 도움이 될 것 같습니다
또 질문 남겨주시면 그 내용들을 기반으로 글을 작성해볼게요. 읽어주셔서 감사합니다

글 작성하는데 걸린 시간 : 217분
- 하고자 하는 이야기, 개요 정리 : 3분
- 초안 글 작성 : 200분
- 클로드/Cursor와 셀프 글 피드백 : 14분
- 2차 글 작성 : 안함

dbt + BigQuery 데이터 모델링

Thu, 30 Jan 2025 00:00:00 +0000

이 글은 BigQuery 환경에서 dbt 사용법에 대해 작성한 글입니다
예상 독자
- BigQuery에서 dbt를 사용하는 방법에 궁금하신 분
- 앞선 dbt 사용법과 기본 개념 글을 읽으신 분
키워드 : dbt BigQuery, dbt modeling

dbt + BigQuery를 위한 환경 설정

dbt bigquery 설치

dbt-core는 설치했다고 가정하고 dbt-bigquery를 설치

pip3 install dbt-bigquery

dbt init

dbt init newyork_taxi

위 명령어를 입력하면 DB를 선택하는 부분이 나옴. BigQuery로 설정
만약 Runtime Error(No adapters available)이 발생하면 위에 dbt-bigquery를 설치해야 함(DB와 연결하는 라이브러리가 설치되어 있지 않다는 의미)
권한 설정을 어떻게 할지 물어보는 질문도 있는데, oauth와 service_account가 존재
- 여기선 oauth로 진행. 로컬 개발할 때는 oauth도 추천
- 회사였으면 service_account로 설정
  - dbt로 만든 것을 주기적으로 실행할 때는 service_account를 발급해서 GitHub Actions나 Airflow에 설정해줘야 하지만, 지금은 로컬 개발에 집중
프로젝트 ID, 데이터셋, threads, timeout seconds, region을 입력

~/.dbt/profiles.yml을 확인하면, 방금 입력한 내용을 확인할 수 있음

cat ~/.dbt/profiles.yml

newyork_taxi:
  outputs:
    dev:
      dataset: newyork_taxi
      job_execution_timeout_seconds: 300
      job_retries: 1
      location: US
      method: oauth
      priority: interactive
      project: zzsza-github-io
      threads: 4
      type: bigquery
  target: dev

프로필 파일을 dbt 작업 프로젝트로 옮기려면 아래 명령어 실행(홈 디렉토리 안에 프로필 파일이 있는데, 회사에서 작업한다면 이런 프로필을 GitHub Repository에 넣고 Push)
- dbt_project.yml : 프로젝트 설정 파일. 프로젝트 구조, 리소스 설정, 변수 등
- profiles.yml : 프로필 설정 파일. 데이터베이스 연결 정보 등이 저장됨

cp ~/.dbt/profiles.yml .

gcloud를 사용해 oauth

터미널에서 아래 명령어 입력(gcloud 사전에 설치되어야 함)
- gcloud 설치 방법은 Docs 참고

gcloud auth application-default login \
  --scopes=https://www.googleapis.com/auth/bigquery,\
https://www.googleapis.com/auth/drive.readonly,\
https://www.googleapis.com/auth/iam.test

dbt run

샘플 모델을 실행
- models/example 폴더에 있는 my_first_dbt_model.sql, my_second_dbt_model.sql가 실행됨

dbt run

실행하면 BigQuery에 새로운 테이블, 뷰가 추가됨

dbt utils 설정

dbt_utils는 dbt에서 유용하게 사용할 수 있는 macro와 Test를 모아둔 패키지
packages.yml 파일에 dbt_utils 패키지를 추가(이 파일이 없다면 생성하고 추가하면 됨)

packages:
  - package: dbt-labs/dbt_utils
    version: 1.3.0

그 후, dbt deps를 실행해 디펜던시를 설치함

사용할 데이터

BigQuery의 Public Data인 뉴욕 택시 데이터인 tlc_green_trips_2022 테이블을 사용
Source 데이터 설정
- models/sources.yml에 소스 데이터를 설정해서, dbt 모델링을 할 때 사용할 수 있음
- BigQuery Public 데이터인 tlc_green_trips_2022을 사용할 예정이나, 이 테이블은 파티션 설정이 되어있지 않아 전체를 복사한 후 파티션을 설정할 예정

tlc_green_trips_2022 테이블 파티션 설정

아래 쿼리를 실행해 Public이 아닌 자신의 프로젝트의 데이터셋에 저장

CREATE OR REPLACE TABLE newyork_taxi.tlc_green_trips_2022
PARTITION BY DATE(pickup_datetime)
CLUSTER BY pickup_location_id, dropoff_location_id
AS
SELECT *
FROM bigquery-public-data.new_york_taxi_trips.tlc_green_trips_2022;

테이블 정보 저장

models/sources.yml에 다음과 같이 저장
- 처음에 헷갈릴 수 있는 부분은, database, schema, tables 개념인데 핵심만 정리하면 다음과 같음
  - database는 구글 클라우드 프로젝트 ID
  - schema는 빅쿼리 데이터셋
  - tables의 name은 테이블 이름
- tests 부분은 임의로 추가함. 실제로 잘 통과되는 test도 있고, 통과되지 않을 test도 존재

version: 2

sources:
  - name: ny_taxi # dbt에서 사용할 이름
    database: zzsza-github-io # 구글 클라우드 프로젝트 ID
    schema: newyork_taxi # 빅쿼리 데이터셋 이름
    description: "뉴욕 택시 운행 데이터의 파티션된 버전"
    
    tables:
      - name: tlc_green_trips_2022 # 빅쿼리 테이블 이름
        description: "녹색 택시(Green Taxi)의 운행 기록 데이터. 일자별로 파티션되어 있음"
        
        loaded_at_field: pickup_datetime

        columns:
          - name: vendor_id
            description: "택시 제공업체 식별자"
            tests:
              - not_null
              - accepted_values:
                  values: ['1', '2']

          - name: pickup_datetime
            description: "승객 탑승 시간"
            tests:
              - not_null

          - name: dropoff_datetime
            description: "승객 하차 시간"
            tests:
              - not_null
              - dbt_utils.expression_is_true:
                  expression: "dropoff_datetime >= pickup_datetime"

          - name: store_and_fwd_flag
            description: "저장 후 전송 여부 (Y/N)"
            tests:
              - accepted_values:
                  values: ['Y', 'N']

          - name: rate_code
            description: >
              요금 코드. 운행 유형에 따른 요금 체계를 나타냅니다:
              1.0 = 표준 요금 (Standard rate): 일반적인 시내 운행
              2.0 = JFK 공항 (JFK Airport): 고정 요금이 적용되는 JFK 공항행
              3.0 = Newark 공항 (Newark Airport): Newark 공항 운행
              4.0 = Nassau 또는 Westchester: 교외 지역 운행
              5.0 = 협상 요금 (Negotiated fare): 사전에 합의된 요금
              6.0 = 그룹 승차 (Group ride): 합승 요금
            tests:
              - not_null
              - accepted_values:
                  values: [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]

          - name: passenger_count
            description: "승객 수"

          - name: trip_distance
            description: "주행 거리 (마일)"
            tests:
              - not_null
              - dbt_utils.expression_is_true:
                  expression: "trip_distance >= 0"

          - name: fare_amount
            description: "기본 요금"
            tests:
              - not_null

          - name: extra
            description: "추가 요금"
            tests:
              - not_null

          - name: mta_tax
            description: "MTA 세금"
            tests:
              - not_null

          - name: tip_amount
            description: "팁"
            tests:
              - not_null

          - name: tolls_amount
            description: "통행료"
            tests:
              - not_null

          - name: ehail_fee
            description: "전자 호출 수수료"

          - name: airport_fee
            description: "공항 수수료"

          - name: total_amount
            description: "총 금액"
            tests:
              - not_null
              - dbt_utils.expression_is_true:
                  expression: "total_amount >= 0"

          - name: payment_type
            description: >
              결제 방식을 나타내는 코드:
              1.0 = 신용카드 (Credit card): 카드 결제
              2.0 = 현금 (Cash): 현금 결제
              3.0 = 무료 운행 (No charge): 요금이 부과되지 않는 운행
              4.0 = 분쟁 (Dispute): 요금 관련 분쟁이 있는 경우
              5.0 = 알 수 없음 (Unknown): 결제 방식이 불분명한 경우
              6.0 = 취소된 운행 (Voided trip): 운행이 취소된 경우
            tests:
              - not_null
              - accepted_values:
                  values: [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]

          - name: trip_type
            description: "운행 유형"
            tests:
              - not_null

          - name: imp_surcharge
            description: "개선 부과금"
            tests:
              - not_null

          - name: pickup_location_id
            description: "승차 위치 ID"
            tests:
              - not_null

          - name: dropoff_location_id
            description: "하차 위치 ID"
            tests:
              - not_null

          - name: data_file_year
            description: "데이터 파일의 연도"
            tests:차
              - not_null

          - name: data_file_month
            description: "데이터 파일의 월"
            tests:
              - not_null

        # 테이블 수준의 테스트
        tests:
          - dbt_utils.expression_is_true:
              expression: >
                fare_amount + COALESCE(extra, 0) + COALESCE(mta_tax, 0) + 
                COALESCE(tip_amount, 0) + COALESCE(tolls_amount, 0) + 
                COALESCE(imp_surcharge, 0) <= total_amount
              severity: warn

모델링

locationId 별로 집계하는 간단한 모델을 만들 예정

차원(dimension) 모델링

pickup_location_id의 특정 차원을 저장
models/dimensions/dim_locations.sql

{{ config( materialized='table', cluster_by=['location_id'] ) }}

SELECT DISTINCT
    pickup_location_id AS location_id,
    -- 위치의 고유한 특성을 정의
    CASE 
        WHEN pickup_location_id IN ("1", "2") THEN 'airport'  -- 공항 위치 ID
        WHEN pickup_location_id BETWEEN "100" AND "200" THEN 'manhattan'
        ELSE 'outer_borough'
    END AS borough_type,
    case
        WHEN pickup_location_id IN ("1", "2") THEN 'restricted'
        ELSE 'general'
    END AS service_area_type
from {{ source('ny_taxi', 'tlc_green_trips_2022') }}

팩트(fact) 모델링

팩트 테이블은 비즈니스에서 발생하는 이벤트나 트랜잭션을 기록하는 테이블
- 한 번의 택시 운행과 관련된 정보를 저장함

-- models/facts/fact_trips.sql
{{ config(
    materialized='incremental',
    partition_by={
        "field": "pickup_datetime",
        "data_type": "timestamp",
        "granularity": "day"
    },
    cluster_by=['pickup_location_id', 'dropoff_location_id']
) }}

select
    -- 운행 식별 정보
    
        concat(
        vendor_id, '_',
        cast(pickup_datetime as string), '_',
        cast(pickup_location_id as string)
    ) as trip_id,
    vendor_id,
    
    -- 시간 관련 측정값
    pickup_datetime,
    dropoff_datetime,
    TIMESTAMP_DIFF(dropoff_datetime, pickup_datetime, MINUTE) as duration_minutes,    
    -- 위치 관련 측정값
    pickup_location_id,
    dropoff_location_id,
    trip_distance,
    
    -- 승객 정보
    passenger_count,
    trip_type,
    rate_code,
    store_and_fwd_flag,
    
    -- 요금 관련 측정값
    fare_amount,
    extra,
    mta_tax,
    tip_amount,
    tolls_amount,
    ehail_fee,
    airport_fee,
    imp_surcharge,
    total_amount,
    payment_type,
    
    -- 성과 지표 계산
    case 
        when fare_amount > 0 then tip_amount / fare_amount 
        else 0 
    end as tip_ratio,
    
    case 
        when TIMESTAMP_DIFF(dropoff_datetime, pickup_datetime, MINUTE) > 0 
        then total_amount / TIMESTAMP_DIFF(dropoff_datetime, pickup_datetime, MINUTE)
        else 0 
    end as revenue_per_minute,
    
    -- 파일 정보
    data_file_year,
    data_file_month

from {{ source('ny_taxi', 'tlc_green_trips_2022') }}

{% if is_incremental() %}
where pickup_datetime > (select max(pickup_datetime) from {{ this }})
{% endif %}

마트(mart) 모델링

마트 테이블 : 특정 기준으로 집계한 데이터
- 예 : 일자별, 지역별 운행 통계

-- models/marts/mart_location_patterns.sql
{{
    config(
        materialized='incremental',
        partition_by={
            "field": "data_file_month",
            "data_type": "int64",
            "granularity": "month",
            "range": {
              "start": 1,
              "end": 12,
              "interval": 1
            }
        },
        cluster_by="location_id,borough_type"
    )
}}

select
    f.data_file_year,
    f.data_file_month,
    date_trunc(f.pickup_datetime, day) as pickup_date, 
    l.location_id,
    l.borough_type,
    l.service_area_type,
    count(distinct f.trip_id) as total_trips,  -- 고유 trip_id 개수
    avg(f.fare_amount) as avg_fare,
    avg(case when f.rate_code = '2.0' then 1 else 0 end) as airport_trip_ratio
from {{ ref('fact_trips') }} f
join {{ ref('dim_locations') }} l
    on f.pickup_location_id = l.location_id
{% if is_incremental() %}
  where f.data_file_month >= (select max(data_file_month) from {{ this }})
{% endif %}
group by
    f.data_file_year,
    f.data_file_month,
    pickup_date,
    l.location_id,
    l.borough_type,
    l.service_area_type

모델 실행

mart_location_patterns과 앞선 의존성을 모두 실행
- 실행하면 빅쿼리 테이블이 생성됨

dbt run --select +mart_location_patterns

모델 컴파일 확인

만약 모델 실행 전에, 컴파일을 통해 확인하고 싶다면 아래 명령어로 가능함
- 컴파일 : 실제 실행 가능한 SQL로 변환하는 명령어
- 변환된 SQL만 생성함
- 생성된 SQL은 target/compiled/{project_name}/models/ 에 저장됨

dbt compile --models mart_location_patterns

dbt run을 실행할 때, 오류가 발생한다면

컴파일 후 나오는 쿼리문을 BigQuery Console에서 실행 => 오류가 생기면 쿼리가 실행되지 않을 것
다 수정했는데도 안된다면 dbt run을 하면서 생성하는 옵션에서 이슈가 있을 수 있음
- logs/dbt.log에서 보면 실행될 시점의 쿼리문을 볼 수 있음
- 이 쿼리를 보면서 왜 이런 코드가 실행되는지 확인하면 됨

dbt docs 생성

dbt 문서를 생성하는 명령어는 크게 2단계로 진행
- generate
- serve

dbt docs generate
dbt docs serve

localhost:8080에서 확인할 수 있음

그리고 우측 아래의 View Lineage Graph를 클릭하면 리니지 형태를 볼 수 있음

모델 Test

dbt test는 sources.yml과 schema.yml에 정의된 테스트를 실행함
- sources.yml : source의 테이블과 컬럼에 대한 테스트
- schema.yml : 모델의 테이블과 컬럼에 대한 테스트
- 여기선 sources.yml에 정의된 테스트를 실행함

dbt test

명령어를 실행하면, 통과되지 못한 Test가 나옴. 이 Test를 수정하면 됨

정리

dbt + bigquery를 연결해 마트 모델링을 진행
- dbt run model
- dbt compile : SQL로 컴파일
의존성을 설치하고 싶을 땐
- dbt deps
dbt docs는 generate와 serve를 사용
- dbt docs generate
- dbt docs serve
테스트는 test
- dbt test
모델링을 어떻게 하는지는 별도로 글을 작성할 예정. 이 글에선 dbt + bigquery를 사용하는 방법을 주로 다룸

글 작성하는데 걸린 시간 : 3시간 47분
- 하고자 하는 이야기, 개요 정리 : 32분
- 초안 글 작성 : 3시간 15분

dbt 사용법과 기본 개념

Thu, 16 Jan 2025 00:00:00 +0000

이 글은 dbt 사용법(Data Build Tool)을 작성한 글입니다
예상 독자
- dbt가 궁금하신 분
- 마트 모델링을 해야 하는 데이터 분석가, 데이터 엔지니어
키워드 : dbt 사용법, dbt(data build tool), dbt 사용법, dbt 설치, dbt core

dbt란?

dbt가 나오게 된 배경

과거엔 데이터 처리를 ETL 방식으로 진행(Extract - Trasnform - Load)
- 예 : 원본 데이터를 추출하고 Apache Spark를 사용해 바로 데이터를 변환해서 변환한 결과를 저장함
- 이 당시의 데이터 저장소 비용은 지금에 비하면 상대적으로 높았고, 컴퓨팅 파워도 제한적이였음
- 이렇게 처리할 때 원본 데이터를 그대로 저장하는 것은 비용 이슈 때문에 고민이 되던 시기
클라우드 발전
- 클라우드가 발전하면서 클라우드 베이스의 데이터 웨어하우스가 등장했음(BigQuery, Snowflake, Redshift 등)
  - 데이터 웨어하우스에서 저장 / 컴퓨팅을 분리하기 시작
- 데이터 저장소 비용이 점점 저렴해짐(S3, GCS 비용)
- 위 발전 덕분에 ETL 방식에서 ELT 방식이 업계에서 알려지고, 채택되는 케이스가 많아짐
ELT
- Extract - Load - Transform
- S3, DB 등에서 데이터를 추출하고, 추출한 데이터를 바로 데이터 웨어하우스에 불러옴(Load) 그 후에 불러온 데이터를 데이터 웨어하우스에서 목적에 맞게 Transform을 해서 저장함
- 데이터 웨어하우스에서 Transform을 할 때는 주로 SQL을 사용함. 과거엔 Apache Spark로 전처리를 하는 것이 필수였으나(물론 Spark도 SQL 방식이 요즘은 더 많이 사용되고 있으나, 과거엔 RDD 기반을 주로 사용하던 시기가 있었음) 이젠 더 쉽게 진행할 수 있게 됨
- 일단 데이터를 모두 가져오기 때문에 모든 데이터를 목적에 맞게 활용할 수 있음
  - Transform을 다시 실행할 때, 원본 데이터가 데이터 웨어하우스에 있어서 바로 다시 Transform을 실행하면 됨
  - 같은 데이터여도 목적에 따라 다르게 전처리가 필요할 때도 유용함
- 그러나 데이터를 모두 저장하는 것은 장점이기도 하지만, 사용되지 않는 데이터도 일단 다 저장해서 단점도 존재함(저장 비용의 증가)
- 사람들이 더 쉽게 데이터를 사용할 수 있게 되면서, 같은 지표인데 다르게 뽑는 경우가 생김. 예를 들어 DAU를 뽑아야 하는데, 부서마다 Active의 정의를 다르게 해서 CEO에게 보고함. CEO 입장에선 데이터가 달라서 의문을 제기하고, 데이터 조직에게 데이터를 확인해보라고 함
  - 그래서 확인해보면, 조직 간 지표 정의가 달랐기 때문을 발견함
- 위 문제를 해결하기 위해 데이터 조직에서 표준화 작업을 시작함. 이 때는 데이터 분석가가 하는 조직도 있고, 데이터 엔지니어가 하는 조직도 있음. 조직 상황에 따라 할 수 있는 사람들이 하기 시작함
  - 처음엔 단순하게 Transform을 Spark나 Airflow 등으로 만들면서 관리함
  - 그러나 이 방식은 코드나 쿼리가 길어서 가독성이 떨어져, 유지보수를 할 수 있는 사람이 적어지게 됨(만든 사람만 이해함)
  - 또한 모델 정의가 다를 땐 전체적으로 다시 실행하는 과정이 필요해짐
이런 맥락에서 dbt가 등장함
- 데이터 웨어하우스에서 Transform 작업을 체계적으로 관리할 수 있게 해주는 도구
- 버전 관리나 테스팅도 지원하며, 문서도 만들 수 있어 많은 회사들에서 채택함(실리콘밸리에서 많이 채택했으며, 한국에서는 최근 1~2년부터 도입하는 중)

dbt 설명

dbt : data build tool
dbt는 데이터 변환(transformation)에 특화된 도구. 데이터 엔지니어링에서 T 레이어에서 사용된다고 표현함
오픈소스인 dbt core와 클라우드 버전인 dbt cloud가 존재함
- 보통 회사에선 dbt core를 사용하고, Airflow나 dbt Web 화면을 직접 만들어서 쓰는 경우가 많음
특징
- 모델을 구조화해서 관리할 수 있음
  - 데이터 모델 : 데이터를 어떻게 정의할 것인지를 나타내는 것. 머신러닝이나 AI 모델과 다른 개념
  - SQL 쿼리를 복사 붙여넣기하는 것이 아닌 dbt에서 모델을 만들어서 그 결과 테이블을 사용할 수 있음
  - 모델링하는 과정에서 복잡한 비즈니스 로직을 추가할 수 있음
- 데이터 리니지 제공
  - 집계된 데이터에서 어떤 데이터를 참고하는지를 알려주는 기능이 있는데, 이 기능이 리니지(lineage), 계보 기능
- Incremental 지원
  - 회사에서 전체 데이터를 매일 가지고 오는 것은 DB에도 부담이 되고, 시간도 오래 걸림. 이럴 때 Incremental하게 증분 데이터만 가지고 오는 것이 필요. 이 부분을 지원하는 것도 장점
- 데이터 퀄리티 테스트
  - 데이터의 품질 테스트를 지원. 어떤 값이 있는지, 최소/최대값 등

dbt 도입을 고려하면 좋은 조직

(1) 데이터 분석가, 데이터 엔지니어가 함께 일하는 조직
- dbt는 SQL 사용해서 데이터 분석가도 모델을 만들 때 기여할 수 있음
- 그러나 데이터 분석가가 SQL을 못하는 경우도 존재함. Pandas 등을 사용해서 전처리를 하는 경우엔 SQL에 익숙해진 후에 도입하는 것을 추천함
(2) 클라우드 데이터 웨어하우스를 사용하고 있는 조직
- 클라우드 기반 데이터 웨어하우스를 사용할 때 특히 더 좋음
  - 이런 데이터 웨어하우스는 SQL로 데이터 처리를 할 수 있고, 보통 UDF 기능을 지원함
  - 클라우드 데이터 웨어하우스의 인프라를 관리할 필요가 없기 때문에 클러스터 관리 등을 하지 않아도 괜찮음
(3) 데이터를 잘 활용하는 조직
- 데이터를 잘 활용하지 못하는 경우에 dbt를 도입하는 것은 비추천
- 데이터 성숙도 관점에서 모델링의 복잡성과 규모가 존재할 때 도입하는 것이 좋음
- 여러 소스의 데이터와 결합할 때 좋고, 단순하게 집계만 하려고 한다면 굳이 dbt를 사용하지 않아도 괜찮음
데이터 파이프라인 관점
- 데이터 파이프라인이 복잡할 때, 리니지 기능이 빛을 낼 수 있기 때문에 복잡한 조직에서 추천함. 간단하다면 그냥 문서에 정리해도 괜찮을 수 있음
- dbt cloud를 사용하지 않으면 Airflow나 dbt Web UI를 구성하는 것이 필요할 수 있음. 추가적으로 리소스가 든다는 것을 인지해야 함
  - 구현해야 하는 기능
    - 스케줄링 : Airflow에서 dbt run, test
    - 알림/모니터링 : Slack 메시지 전송
    - 대시보드 : Superset 등을 사용해 모델 지표 관리
    - CI/CD : Github Action 등을 사용해 배포

dbt 사용법

dbt 설치

글 작성 기준 최신 버전 명시

pip3 install dbt-core==1.9.1

(1) 프로젝트 생성

CLI에서 아래 명령어 실행
- jaffle_shop이란 프로젝트를 init
- 이미 프로젝트가 있다면 이 작업은 생략 가능

dbt init jaffle_shop

(2) 프로젝트 폴더 구조

dbt init을 하면 기본적으로 폴더가 생성됨
dbt init 할 때 생기는 폴더
```
  ├── README.md
  ├── analyses
  ├── dbt_project.yml
  ├── macros
  ├── models
  │   └── example
  │       ├── my_first_dbt_model.sql
  │       ├── my_second_dbt_model.sql
  │       └── schema.yml : 모델 정의
  ├── seeds
  ├── snapshots
  └── tests
```
- dbt_project.yml : dbt 프로젝트 설정
- analyses/ : 임시 또는 일회성 분석을 위한 쿼리를 저장하는 폴더. dbt run을 해도 실행되지 않음
- macros/ : 재사용 가능한 매크로를 저장
- models/ : SQL 모델 파일들을 저장
  - 보통 staging, intermediate, mart와 같이 하위 폴더로 구분
  - schema.yml : 모델에 대한 정의. model name, description, columns, data_tests 등이 존재
- seeds/ : CSV 파일 형태의 변하지 않는 데이터를 저장
- snapshots/ : 데이터의 스냅샷을 찍기 위한 SQL 파일을 저장
  - dbt snapshot 명령어로 실행
- tests/ : 데이터 품질 테스트 정의

(3) 모델 작성하기

모델 : 하나의 SQL 쿼리
쿼리의 결과가 데이터 웨어하우스의 테이블, VIEW로 저장됨
모델은 .sql 파일로 작성됨
‘참조(ref)’ 기능
- 특정 모델에서 다른 모델을 참조할 때, 테이블 이름을 직접 쓰는 대신 ref('model_name') 함수를 사용함
- 이 기능을 사용해 모델 간의 의존성을 자동으로 추적함
models/staging/stg_orders.sql 예시

-- models/staging/stg_orders.sql
{{ config(materialized='table') }}

SELECT
    order_id,
    customer_id,
    order_date,
    status,
    amount
FROM raw_data.orders
WHERE status IS NOT NULL

위 테이블을 사용해서 일별 주문 집계를 구하고 싶다면

-- models/intermediate/int_daily_orders.sql
{{ config(materialized='table') }}

SELECT 
    DATE_TRUNC('day', order_date) as date,
    COUNT(DISTINCT order_id) as order_count,
    COUNT(DISTINCT customer_id) as customer_count,
    SUM(amount) as total_amount
FROM {{ ref('stg_orders') }}
GROUP BY date

고객별 구매 이력을 만들 때는

-- models/marts/mart_customer_orders.sql
{{ config(materialized='table') }}

WITH customer_orders AS (
    SELECT 
        customer_id,
        COUNT(*) as total_orders,
        SUM(amount) as total_spent,
        MIN(order_date) as first_order_date,
        MAX(order_date) as last_order_date
    FROM {{ ref('stg_orders') }}
    GROUP BY customer_id
)

SELECT 
    *,
    DATEDIFF('day', first_order_date, last_order_date) as customer_lifetime_days
FROM customer_orders

config의 materialization은 SQL 쿼리의 결과를 데이터 웨어하우스에서 어떻게 저장할지를 의미함
- table : 실제 테이블로 저장. 데이터가 자주 변경되지 않고, 쿼리 성능이 중요할 경우 사용
- view : 쿼리를 뷰로 저장. 저장 공간을 절약할 수 있지만, 쿼리 성능이 떨어질 수 있음. 다만 원본 데이터가 바뀌면 바로 볼 수 있음(최신 데이터 확인 가능)
- incremental : 테이블에 새로운, 변경된 데이터만 추가함
- emphemeral : 실제로 물리화되지 않고, 다른 모델에서 참조될 때 서브 쿼리로 사용

Incremental Materilization

자주 사용하는 패턴. 데이터를 증분만 처리

-- models/mart/web_analytics/daily_pageviews.sql
{{ config(
    materialized='incremental',
    unique_key='page_date_key'
) }}

SELECT 
    date_trunc('day', timestamp) as visit_date,
    page_url,
    count(*) as pageviews,
    count(distinct user_id) as unique_visitors,
    concat(date_trunc('day', timestamp), '-', page_url) as page_date_key
FROM {{ ref('stg_page_visits') }}
{% if is_incremental() %}
    WHERE timestamp >= (SELECT max(visit_date) FROM ]{{ this }})
{% endif %}
GROUP BY 1, 2, 5

config에서 incremental을 명시하고, unique_key를 추가함
- 증분 업데이트를 할 때 사용할 id를 의미함
- unique_key는 고유한 값이어야 하며, 여러 컬럼을 조합해서 사용할 수도 있음
- NULL이 있으면 안됨
```
    

  {{ config(
      materialized='incremental',
      unique_key=['date_key', 'product_id', 'store_id'] 
  ) }}
    
```
아래 if is_incremental()은 증분이 있는지 확인하는 것
- 이미 처리된 테이블이 있는 경우 실행하며, this는 현재 모델의 테이블을 의미
- timestamp 기준으로 현재 테이블에 저장된 최근 값(max(visit_date))보다 이후 데이터만 가져옴
```
    

  {% if is_incremental() %}
      -- 이미 처리된 테이블이 있는 경우에만 실행
      WHERE timestamp >= (SELECT max(visit_date) FROM {{ this }})
      -- {{ this }}는 현재 생성되는 테이블을 참조
  {% endif %}
    
```

insert, update를 모두 고려하고 싶다면 아래와 같이 작성

    
  {% if is_incremental() %}
      WHERE created_at >= (SELECT max(created_at) FROM {{ this }})
      OR updated_at >= (SELECT max(updated_at) FROM {{ this }})
  {% endif %}

(4) 모델을 저장하는 방식

models 하위 폴더 구조를 고민하는 것이 필요함
- dbt는 여러 직무에서 같이 협업하며 사용할 수 있기 때문에 협업에 최적화된 패턴을 고려해야 함
- 일관되고 이해하기 쉬운 구조를 만들어야 하며, 정답이 있는 것보단 조직 상황에 따라 다름
다양한 방식이 있지만, 대표적인 2가지 공유

대표적인 방식 : 비즈니스 도메인 맞춤

dbt에서 가이드로 주고 있는 형태
- staging : 초기 정제
- intermediate : 중간 집계나 조인
- mart : 최종 분석용 테이블
  - 비즈니스 도메인 별로 구분
- 이런 구성을 사용하면 파일 이름만 봐도 흐름이 명확해짐

models/
├── staging/
│   ├── stg_orders.sql
│   └── stg_customers.sql
├── intermediate/
│   ├── int_order_payments.sql
│   └── int_customer_orders.sql
└── mart/
    ├── finance/
    │   ├── daily_revenue.sql
    │   └── monthly_profit.sql
    ├── marketing/
    │   ├── customer_segments.sql
    │   └── campaign_performance.sql
    └── product/
        ├── product_metrics.sql
        └── inventory_analysis.sql

다른 방식 : Fact / Dimension

Kimball의 차원 모델링 방식
- Facts / Dimension 관점으로 처리
- staging, intermediate는 동일
Fact(팩트) 테이블
- 비즈니스 프로세스의 측정값/메트릭을 저장
- 주로 숫자형 데이터(금액, 수량 등)
- 매우 자주 업데이트되고 크기가 계속 증가
Dimension(디멘전, 차원) 테이블
- 비즈니스 엔티티의 속성 정보를 저장
- 주로 텍스트/카테고리형 데이터
- 상대적으로 천천히 변함
이 방식의 장점
- 명확한 분리 : 팩트, 디멘전을 나눠서 각각의 업데이트 주기와 처리 방식을 나눔
- 쿼리 최적화 : 차원 테이블은 작고 자주 JOIN되어서 캐싱, 팩트 테이블은 필요한 컬럼만 포함해 효율적
- 유지보수 : 속성 변경은 차원 테이블에서만 관리함. 새로운 값은 팩트 테이블에만 추가

models/
├── staging/      # 원본 데이터 정제
├── intermediate/ # 중간 처리
└── marts/
    ├── facts/    # 측정값이 있는 팩트 테이블
    │   ├── fct_orders.sql
    │   └── fct_page_views.sql
    └── dimensions/  # 차원 테이블
        ├── dim_customers.sql
        └── dim_products.sql

Fact, Dimension 결과를 사용하는 예시 쿼리

    
  SELECT 
      d.customer_segment,
      d.country,
      COUNT(DISTINCT f.order_id) as total_orders,
      SUM(f.total_amount) as total_revenue
  FROM {{ ref('fct_orders') }} f
  JOIN {{ ref('dim_customers') }} d
      ON f.customer_id = d.customer_id
  GROUP BY 1, 2
    

(5) 모델 실행 & Test

모델 파일을 작성한 후, 실행 및 테스트를 진행해야 함

dbt run 명령어로 실행할 수 있음

+을 붙이면 의존된 모델을 실행함
앞에 붙이면 상위 의존성, 뒤에 붙이면 하위 의존성
추가적인 내용은 dbt Graph Operator Docs

  # 특정 모델 실행
  dbt run --select my_model 
    
  # 하위 의존성 모델 포함해 실행
  dbt run --select my_model+
     
  # 상위 의존성 모델 포함
  dbt run --select +my_model  
    
  # 상위와 하위 의존성 모델 모두 포함
  dbt run --select +my_model+

dbt run 관련 문법은 Doc 참고

Argument는 --select, --exclue, --selector, --defer가 있음
특정 모델, 그룹만 실행하고 싶을 땐 –select 를 사용하면 됨

  dbt run --select "my_dbt_project_name"  # 프로젝트의 모든 모델
  dbt run --select "my_dbt_model"         # 특정 모델만
  dbt run --select "path/to/my/models"    # 특정 디렉토리의 모든 모델
  dbt run --select "tag:nightly"          # "nightly" 태그가 있는 모델들

만약 문법 검사를 하고 싶다면 dbt compile로 확인할 수 있음
- 모델 참조 확인, SQL 문법 등

증분 모델 전체 재실행

일반적인 증분 모델도 동일하게 dbt run으로 실행함
그러나 처음부터 다시 실행해야 할 경우엔 –full-refresh 인자와 실행
- Incremental 모델의 스키마가 변경되어 다시 만들어야 하는 경우
- 새로운 논리가 추가되어 모델 전체를 다시 처리
- 내부적으로 기존 테이븡를 DROP하고 모든 데이터를 새로 계산해 적재함(탐색하는 범위에 비용을 부과하는 데이터 웨어하우스에선 비용이 많이 드는 행위일 수 있음)

db run --full-refresh --select my_model

dbt Test

dbt test는 2가지로 구성됨

generic
- models/{모델_파일}이 있는 폴더에 저장된 schema.yml에 저장함
- 특정 컬럼이 Unique인가? Not Null인가?
- relationship : 특정 테이블의 컬럼에 존재하는 값인지
- accepted_values : 지정된 값만 있는지
- dbt_expectations(추가 패키지 설치 필요) : dbt hub 참고. 여러 Test가 존재함

  # models/intermediate/schema.yml
  version: 2
  models:
    - name: int_daily_sales
      columns:
        - name: date
          tests:
            - not_null
            - unique:
                combination_of: [date, product_id]
        - name: daily_sales
          tests:
            - not_null
            - positive_value

singular
- tests 폴더에 .sql 파일로 정의함
- 복잡한 비즈니스 로직을 주로 저장함
- 실패 케이스를 반환하는 SQL 쿼리 작성
  - 아래 쿼리는 결과 row가 0건이면 성공, 1건 이상이면 실패를 의미

    

  -- tests/assert_total_payment_amount_is_positive.sql
  SELECT
      order_id,
      total_amount
  FROM {{ ref('orders') }}
  WHERE total_amount < 0
    

매출 합계와 일별 매출의 합이 같은지 확인하고 싶은 경우

    

  -- 매출 합계가 일별 매출의 합과 같은지 확인
  SELECT 
      CASE 
          WHEN total_revenue != daily_sum THEN '정합성 확인 필요'
      END as check_result
  FROM (
      SELECT 
          SUM(revenue) as total_revenue
      FROM {{ ref('revenue') }}
  ) t1
  CROSS JOIN (
      SELECT 
          SUM(daily_revenue) as daily_sum
      FROM {{ ref('daily_revenue') }}
  ) t2
  WHERE total_revenue != daily_sum
    

dbt test 명령어로 실행

dbt test # 모든 테스트
dbt test --select my_model  # 특정 모델의 테스트만
dbt test --select test_type:generic # generic 테스트만
dbt test --select test_type:singular # singular 테스트만
dbt test --select result:fail #실패한 테스트만 재실행

(6) dbt build

build = run + test + snapshot + seed 모두 한번에 실행
실행 순서
- Seedfile Load
- Model Run
- Snapshot Run
- Test run
- 모델을 만들고, 테스트를 실행하는 과정

dbt build --select my_model

언제 build를 하는가?

모델 개발, 테스트 작성할 때는 run, test를 각각 하는 것이 효율적
build는 Airflow에서 주기적으로 실행하곤 함
- 하지만 조직에 따라선 build를 안하고 dbt run만 하는 경우도 존재함(Test까지 하는 것이 이상적이나 현실적으로 Test를 많이 챙기려면 시간이 더 들기 때문에)
빌드 시간을 줄이기 위해 수정된 것만 빌드하는 인자도 존재

dbt build --select state:modified+ --defer --state path/to/prod/artifacts

state:modified+ : 변경된 모델과 의존된 다운스트림만 실행
- state path: 프로덕션 환경의 상태와 비교해 어떤 모델이 변경되었나 확인
defer : 변경되지 않은 모델은 프로덕션 데이터 참조

추가로 고려할 것들

기존에 SQL 기반으로 마트를 만들었다면 마이그레이션이 필요함
- Refactoring SQL for Modularity Course 추천
dbt docs 배포
- dbt model에 대한 내용을 문서로 배포해, 사내 구성원들이 볼 수 있게 해야 함
- 김진석님의 dbt Docs 사내 공유 방법 feat. 사이트 호스팅 가이드 추천
대시보드와 통합하기 : lightdash 추천
- Hands-on Guide to Data Modeling with dbt and Visualization with Lightdash
dbt + Airflow(스케줄링 도구)
- 주기적으로 실행하기 위해 Airflow 같은 도구와 통합 필요
- 또는 GitHub Action에서 실행할 수도 있음
dbt metrics을 활용해 지표 집계
- Build your metrics
- dbt Semantic Layer
dbt utils 확인하기
- dbt utils에 유용한 함수들이 많이 존재함
dbt + 데이터 웨어하우스
- 이번 글은 dbt에 대한 전반적인 소개를 목적으로 한 글이라 이 내용을 포함하진 않았으나, 다음 글은 dbt + 데이터 웨어하우스 글을 작성할 예정
dbt와 유사한 역할을 하는 도구는 dbt 외에도 SQLMesh라는 것도 존재함. dbt가 초반 러닝커브가 높은데(Jinja 템플릿을 활용) 이 부분
- 궁금하다면 Is It Time To Move From dbt to SQLMesh? 추천. SQLMesh가 더 좋은 부분도 있으나 dbt가 생태계가 더 큼. 마치 Airflow가 배치 스케줄링에서 제일 점유율이 높고, Prefect나 다른 도구들이 계속 발전하는 것과 유사한 느낌
  - 그러나 아직 dbt를 도입하지 않았다면 SQLMesh를 도입하는 것도 괜찮다고 생각. dbt를 쓰다가 옮기는 것은 고민됨

2024년 회고 - 기억하고 싶은 것과 요즘 생각들

Sat, 28 Dec 2024 00:00:00 +0000

2024년도 끝나가네요. 매년 하던 것처럼 올해도 회고를 작성해봅니다
과거 회고 글 모음

2024년 - 기억하고 싶은 것

1) 인프런 강의 3개 출시 : BigQuery 입문, BigQuery 활용, 기술 블로그 글쓰기
2) 강의 만들기 모임 : 강의를 만들고 싶어하는 분들이 강의를 만들 수 있도록 도왔다
3) 여러 발표
4) 기업 강의
5) 키보드
6) 음성 치료
7) 아이유님 콘서트
8) 동유럽
9) 글또 10기
10) 요리 시작

1) 인프런 강의 3개 출시

2023년 말에 2024년을 생각하면서, 내년엔 강의 3개 출시하겠다고 다짐했다. KPI로 표시하자면 강의 출시 3개인데, 12월 중순이 되어서 3번째 강의를 출시했다
- BigQuery 입문, BigQuery 활용, 기술 블로그 글쓰기
강의를 만들겠다고 다짐했던 시기의 일기를 다시 읽었다. 나는 지금 어떤가?
- 그 당시에 나는 ‘나와 비슷한 고민을 하거나, 커리어를 발전하고 싶은 사람이 더 빠르게 발전할 수 있도록 잘 돕고 싶다’라는 목표를 가지고 있었다
- 이 목표를 생각하며 지금의 나는 사람들에게 도움을 주고 있나? 생각했다. 강의를 수강하신 분들과 1:1 코칭 시간에 만나서 물어보기도 하고, 직접 후기를 물어보기도 했다
- 수강생분들에게 자주 나오는 답변은 ‘실무적으로 고민한 내용이라 좋다’. ‘이런 경험을 알 수 있어서 좋고 회사 업무에 적용할 수 있다’고 이야기를 해주신다. 도움을 주고 있다. 그러나 내 행동을 생각해보면 능동적인 관점보단 소극적인 관점으로 돕고 있는 것 같다
- 바로 적용할 수 있도록 하는 강의를 만들려고 한다. 어떻게 해야 업무에서 적용할 수 있을지 계속 고민한다. 더 많이 고민하고, 더 많이 실행하자
강의를 더 빠르게 출시할 수 있는 방법은 무엇일까? 예전에 인프런에서 강의 만들기에 대한 글을 작성했는데, 다시 고민했다. 요즘 내 강의 제작 프로세스는 어떤가? 총 4가지 프로세스로 나눌 수 있다
- 강의 기획
- 강의 자료 제작
- 촬영
- 영상 편집
- 이 중에서 강의 자료 제작, 촬영이 제일 오래 걸린다
- 강의 기획은 빠르게 진행하고 계속 변경되고, 영상 편집은 편집 전 영상 길이의 3배 정도 든다
- 강의 자료 제작이 많이 드는 것은 당연하다. 어떻게 해야 수강생분이 더 잘 이해하고, 바로 써먹을 수 있을까를 고민하면서 계속 수정한다. 이걸 만들기 위해 나도 잘 이해해야 하고, 전달하는 방식(딜리버리)도 고민한다
  - 종종 클로드에게 강의 자료 PDF를 주고, 피드백을 요청한다. 어떻게 해야 내 목적에 맞는 교육을 만들 수 있을지 물어보는데, 내가 원하는 방향과 다른 답변을 하는 경우가 있다. 어떻게 보면 내가 원하는 방향이 다수의 형태가 아니라서 그런 것 같다. 그럴수록 하나씩 더 해야지
- 강의를 찍은 후엔 강의를 잘 알리는 것도 필요하다. 인프런에서 알리는 것도 필요하지만 외부에서 내 강의를 찾게 하는 것도 필요하다. 이 부분은 많이 시도하진 않았던 것 같아 내년에 조금 더 시도를 해보려고 한다. 강의팔이처럼 보이고 싶지 않아서 이 부분을 자제했던 것도 있는데, 내 고정관념이 있었던 것 같다. 그냥 사람들에게 도움을 주고 싶다는 본질적인 목표를 생각하며 내가 할 수 있는 것을 해보자.
- 내년엔 드디어 내가 찍고 싶었던 주제를 준비할 수 있다. 그동안 내가 만들고 싶었던 강의를 제작하기 위해 앞선 강의를 촬영했다. 앞선 강의를 잘 수강해야 잘 따라올 수 있다고 생각했다. 앞선 강의들을 만드는데 2년 걸렸다. 이제 내년 1년엔 원했던 강의를 빠르게 완성하는 것이 목표
  - 강의 제작 관련한 장기적 관점도 고민하고 있다. 장기적으로 하려면 어떻게 해야할까? 어떤 관점으로 하는 것이 좋을까? 고민과 결정이 필요한 시기다
빅쿼리 빠짝 스터디를 통해 수강생분들을 만났는데, 강의를 어떻게 듣고 있는지, 어떤 어려움이 있는지도 알 수 있었다. 스터디를 진행하면서 어려워하는 분들이 많이 보였는데, 하나씩 해보자는 이야기를 계속 진행했다. 이 내용을 강의에 넣었지만, 더 넣어도 좋을 것 같다. 고등학생 때 신승범 선생님이 강의에서 자주 동기부여를 해주셨는데, 나도 이런 내용을 추가하고 싶다

2) 강의 만들기 모임

글또 9기에서 강의 만들기 모임을 진행했다. 글또를 열심히 하셨던 분들 중 강의 제작에 의지가 있는 분들을 모셨다.
- 과거에도 강의 만들기 모임을 운영했는데 결국 끝이 흐지부지였다. 시간이 남을 때 하시죠!라는 것은 우선 순위가 바뀌면 어려워질 수 있다. 사람들에게도, 나에게도 강력한 동기부여가 필요했다. 자유롭게 참여하실 분?하면 끝까지 가는 사람이 적었다
- 과거의 행동을 반복하지 않기 위해 이번엔 예치금을 꽤 높게 설정했다. 하이 리스크라고 보일 수 있지만, 완수하면 문제가 되지 않는다. 오히려 강의 수익으로 더 많이 벌 수 있다. 높아 보여도 장기적으론 이득이다. 금액을 높이니 각오가 확실한 분들만 모였다. 애매한 것보단 확실한 것이 좋다고 생각하고, 이분들에게 진심을 다했다.
강의 만들기 모임을 위한 강의를 준비했다
- 어떻게 강의를 준비하면 좋은지에 대한 강의를 진행하고, 커리큘럼 피드백도 열심히 해드렸다. 각자 생각한 커리큘럼을 공유하며 구체적인 피드백을 드렸다
- 왜 이 강의인가?라는 이유가 명확해지도록 계속 질문을 하고, 기획을 고도화했다
- 인프런에서 진행해서 영상 편집도 직접 해야하는데, 프리미어 프로에서 컷 편집을 어떻게 하는지도 공유드렸다. 내가 사용하는 소프트웨어랑 설정을 모두 공유드리면서 컷편집도 다 같이 연습했다
모여서 강의 자료 만드는 시간도 있었다. 아침 10시부터 밤 10시까지 하루 종일 강의 자료 만들었는데, 디스코드 화면 공유도 하면서 정말 몰입을 했다. 이렇게 뽀모도로한 적이 있었던가? 싶었는데 참여하신 분들도 공감했다. 이 추억이 계속 기억에 남는다. 나중엔 원정으로 고성에서 2박 3일 강의 자료 만들기 극기훈련도 가능할 것 같다(거의 감금 프로젝트)
신청해주신 3분 모두 다 강의를 만들었다. 기획 리뷰도 많이 하고, 발표 자료를 만드는 과정에서도 피드백을 드려서 강의 퀄리티는 모두 다 높다
나만 강의를 만드는 것이 아니라 다른 분들도 이렇게 강의를 만들 수 있도록 돕는 것도 보람찼다.
- 이미 강의를 만들었던 경험이 있던 분은 ‘성윤님의 피드백을 통해 강의 퀄리티가 더 좋아졌어요’라고 말해주셨고, 강의를 처음 만든 분은 ‘아 이렇게 해보는거구나! 다음에 또 만들고 싶어요’라는 이야기를 해주셨다
- 커뮤니티나 모임을 만들 땐 목표를 잘 경험할 수 있도록 설계하는 것이 중요하다. 강의 이렇게 하면 되는군! 생각이 든다면 그 이후엔 더 잘 진행할 수 있고 계속 모임에 참여해서 목표를 달성하고 싶어진다.
- 참여해주신 병진님은 올해 인프런 어워드에서 수상하셨다. 나도 수상했는데, 내 옆에 있어서 더 보람찼다
다음 강의 만들기 모임을 또 진행할지는 미지수다. 고민하고 있다.
- 에너지를 꽤 쓰지만, 보람도 있고 이런 환경에서 나도 강의 자료를 만들게 되어 좋다
- 다만 이걸 엄청 늘리려는 것보단 소수 정예로 끈끈하게 진행하고 싶다
참여하신 분들의 강의
- 강승현님의 서류합격률 4%를 탈출하는 개발자 이력서 작성법
- 강병진님의 RAG를 활용한 LLM Application 개발 (feat. LangChain)
- 김은찬님의 커뮤니티에서 바로 써먹는 슬랙 봇 만들기

3) 여러 발표

2024년엔 발표를 7번 했다
- 데보션에서 ‘실용주의 기술 블로그 글쓰기’
- 셀피쉬클럽(셀피쉬월드)에서 틀깰러 토크쇼
- HOC의 HOCC에서 ‘내가 될까? 물음표를 없애기 위한 10년간의 여정’
- 인프콘에서 ‘제품 성장 단계에 따른 지표 찾기 여정’
- 튜링의 사과(튜사콘)에서 ‘성장이 대체 뭐길래 : 한 데이터 과학자의 성장 변천사’
- 보아즈 컨퍼런스톡에서 ‘만약 지금 1년차로 환생한다면?’
- 인프런 BigQuery 활용편 - 빠짝 스터디 오프라인 특강
- 인프런 판교 퇴근길 밋업(연말 회고편)에서 ‘7년 동안 회고하며 깨달은 것들’
- 이거 외에도 부스트캠프 AI Tech, 글또에서 진행한 발표도 5~6번 정도 된다
내 발표로 도움을 받을 수 있는 분이 계시다면 계속 돕고 싶다. 발표를 처음 하게 된 것도 나의 경험이 누군가에겐 도움이 되길 바라는 마음이였다. 이 생각은 여전히 동일하다
인프콘 발표는 PM을 위한 데이터 리터러시 강의를 들은 분들과 듣지 않은 분들이 모두 만족할 수 있도록 발표 내용을 구성했다. 그리고 몇달 후에 흑백요리사가 인기였는데 딱 이 내용이라 시기가 좀 더 맞았으면 좋았겠단 생각도 했다
- 발표 자료는 계속해서 고민하고, 디테일을 섬세하게 다듬는 것이 중요하다
- 클로드랑 계속 이야기를 하면서 디벨롭한다. 자신감이 없으면, 자신감이 없다고 말하는데 이것도 논리적으로 말해줘서 도움이 되었다
- 인프콘 발표에 대한 후기는 네이버 블로그에 기록해두었다
나를 처음 알게된 사람들은 보지 못한 경우도 있다. 이런 것들을 어떻게 연결드리면 좋을까? 고민하고 있다. 과거 발표 자료는 유튜브에 그냥 올려둘까?
- 근데 유튜브 영상 제작에 대해선 고민이 있다. 얼굴 없이 발표 자료만 나오는데도 시간이 꽤 걸린다. 더 빠르게 하는 방법은.. 자료가 없이 그냥 말로만 하면 될까? 좀 더 빠르게 제작하고 싶은데..! 혹은 여유를 갖고 만드는 것도 좋을 것 같다
교육을 하다보니 학생분들을 더 잘 도와주고 싶다. 내가 대학생 때도 누군가 이런 이야기를 다양한 경로에서 하고 있었을 것 같다. 내가 몰랐을 뿐. 지금도 동일하게 나는 내용을 공유하지만, 모르는 분들이 계실 것 같다. 어떻게 그들에게 내 이야기가 전달될 수 있을까?
- 교수를 하고 싶단 생각도 들지만, 이거 말고 다른 방법은 없을까? 고민한다

4) 기업 강의

2024년엔 기업 강의도 종종 진행했다. 목이 약해서 기업 강의를 요청 받을 때 고민하곤 하는데, 도움을 주고 싶단 생각이 있어서 진행했다.
- 강의를 진행하기 전에, 내가 생각하는 주제를 그냥 강의하는 것이 아니고, 설문 조사를 통해 내부 직원분들의 고충을 듣고 강의를 준비한다
- 그 과정에서 데이터 조직이 있다면, 데이터 조직과 미팅을 진행하기도 한다
- 이게 당연한 것 같은데, 종종 이런 부분을 좋게 봐주신다.
특강이나 원데이 교육이여도 사람들이 실제로 활용할 수 있는 것이 무엇일까? 데이터 인프라는 얼마나 있지? 이런 것들을 고민하며 교육하는데 이제는 어느정도 숙달되어서 기업 내부 상황을 질문 몇개를 통해 유추할 수 있다
감사하게도 강의를 진행하고 다른 회사에 추천해주셔서 또 연결이 되고 있다. 항상 진심을 다 하면서 진행하자
기업 컨설팅, 코칭도 요청받곤 하는데 꼭 필요한 경우가 아니거나 준비가 되어있지 않으면 인프런 PM을 위한 데이터 리터러시 강의 수강을 추천드리고 있다. 비싼 돈을 쓰는 것보다 그게 더 좋을 것 같은 경우도 꽤 있다
회사 소개 페이지가 없어서 어떻게 내 정보를 알 수 있는지 물어보곤 한다. 웹페이지를 만드는 것이 필요할 것 같다

5) 키보드

10월에 갑자기 키보드를 바꾸고 싶었다. 기존엔 애플의 매직 키보드를 사용하고 있었는데, 기계식 키보드를 사면 더 개발 실력이 올라갈 것 같았다(??)
그래서 찾아보고 한무무 무접점 35g을 구매했다. 실제로 사용해봤는데, 부드럽지만 손가락이 아파왔다
- 급기어 손목도 아프고, 손가락 마디도 아팠다. 통증이 1달 갔다.
- 키보드가 문제인가 싶어서 MX Keys Mini를 구매했는데, 이 키보드도 키압이 꽤 높아서 부담이 되었다
- 이 상황으로 병원을 오래 다녔다. 침도 맞고, 파라핀 치료 등을 병행했다. 이 때 해야할 일이 많았는데 아파서 힘들었다
- MSM 영양제를 먹으면 좋아진다고 해서 속는 셈치고 먹어봤는데 진짜 호전이 되었다. 파라핀 치료와 MSM 영양제로 빠르게 회복했다
위 경험을 통해 내가 선호하는 키보드에 대해 더 구체적으로 정의할 수 있게 되었다. 나는 키압은 40g 이하를 선호하고, 스트로크가 깊으면 누를 때 힘을 많이 써서 손가락에 통증이 생긴다. 매직 키보드 같은 펜타그래프 형식의 키보드가 잘 맞고, 매직 키보드의 키압은 대략 33~35g 정도였다.
- 다만 매직 키보드는 너무 얇아서 타이핑을 하면 그 충격이 손가락 마디로 전해진다. 엄청 많이 타이핑을 하면 통증이 생겼다.
그래서 대안을 계속 찾아봤다. 로우 프로파일 키보드면 괜찮을 것 같아서 찾아보다가 로프리 플로우의 제품을 찾았고, 킥스타터에서 로프리 플로우 라이트를 펀딩하고 있어서 신청했다. 3개월이 걸려서 받았는데, 매우 만족스럽다. 키압도 괜찮고 소리도 괜찮다. 하나 더 사서 하나는 소음이 있는 축, 하나는 무소음 축으로 쓰는 것을 고려하고 있다(강의 촬영할 땐 무소음으로 진행)
- 로푸리 플로우 라이트는 키압이 40g라서 부담도 낮다. 아마 계속 이 키보드를 쓸 것 같다. 타건감도 매우 좋고 당분간 키보드 뽐뿌 그만!
키보드가 좋으니 글도 더 쓰고 싶고, 개발도 더 하고 싶다. 아 이렇게 키보드 세상에 빠지게 되는건가?

6) 음성 치료

11월에 BigQuery 활용편 강의를 찍다가 목이 심하게 부었다. 목감기였는데, 2주 정도 갔다. 꽤 심하게 아팠다
- 시간의 흐름으로 보면 5) 키보드의 사건으로 손과 손목이 아팠는데, 그 후에 목이 아팠다. 연속적으로 아프니까 여러 고민이 들었다. ‘아, 나는 손이나 목이 좋지 않으면 어떤 일을 할 수 있을까?’ 손과 목을 잘 관리해야겠다는 생각이 들었고, 음성 치료를 시작했다
2년 전에 갔던 이비인후과에선 원론적인 이야기를 주로 해서 바로 발성에 영향을 주지 않아서, 발성을 바로 수정할 수 있는 곳을 찾았다. 새로운 곳에선 내 음성 습관을 알 수 있게 되었고, 실용적인 방식을 배우고 있다
선생님께서 2-3달 정도면 꽤 좋아질 것 같다고 하는데, 연습도 꼭 해야한다. 내년엔 목 상태가 좋아서 강의를 하거나 말을 오래 해도 힘들지 않았으면 좋겠다
폐활량이 적고, 끝음을 흐리거나 공기가 끝까지 전달되지 않는다. 그래서 성대에 무리가 간다
히싱, 버징사운드, 뱃고동 소리 연습하고 허밍, 성대 접촉을 연습하고 있다. 복식 호흡을 하며 공기를 끝까지 쓰는 것도 하고 있다
이건 몇달 더 치료하고, 따로 글을 작성해야겠다

7) 글또 10기

매년 회고에 등장하는 글또. 글또 10기엔 커뮤니티 관점보단 프러덕트 관점으로 완성도가 더 높아지고 있다
- 커뮤니티지만 이렇게까지 한다고?라는 이야기를 듣는다. 커뮤니티도 프러덕트다. 커뮤니티라고 회사처럼 안하고 대충 할 이유가 전혀 없다
커뮤니티 내부에 있는 여러 봇들과 커뮤니티의 데이터를 저장하고, 지표로 변환해 매일 보고 있다. 어떻게 해야 핵심 지표를 더 늘릴 수 있을까?를 고민한다
- Output 지표를 좀 더 쪼개서 Input 지표로 보고, 어떤 것이 제일 큰 영향을 주는지도 본다. 과연 무엇일까? 나중에 글또 블로그에 올리려고 한다
새로운 기능은 포인트 시스템, 종이비행기
- 그 외에 지금도 새로운 기능 하나가 테스트로 돌고 있다. 곧 공유할 수 있을 것 같은데, 이 기능은 꽤 핵심적인 기능이라 많은 분들이 좋아하실 것 같다
기업들과 협업하는 것도 많아졌다. 내가 챙겨야 할 것들이 점점 더 많아진 것인데, 그래도 좋은 경험을 드릴 수 있다면 내 시간을 할애해서 커뮤니케이션을 하고 있다
10기를 하며 많이 배웠다는 분들이 계신다
- 그 이후 계획은 내 머리 속엔 있다. 그 이후에 사람들이 어떻게 활동하는지 보고(자연적인 활동) 그 후에 추가적인 액션을 할 예정이다
도움 주신 튜링의 사과, 길벗, 한빛미디어, 코드트리, 인프런, 세일즈포스 모두 감사합니다
아래 이미지는 또봇(슬랙 봇 앱)의 메인 페이지. 개인 별 상세 페이지라고 생각하면 된다

8) 아이유님 콘서트

아이유님의 콘서트를 다녀오고 참 영감을 많이 받았다. 나는 너무 그 자리에 있는 것을 선택한 것이 아닐까? 아이유님은 계속 더 많은 것을 시도하는 선택을 하고, 그것을 실행해서 이뤘다.
콘서트에서 노래를 들으며 음악적으로도 좋았지만, 내 안의 어떤 마음이 용솟음쳤다. 너가 하고 싶은 것은 뭐야? 요즘 만족해? 진짜야?
- 너의 꿈은 뭐였어? 지금 동일해? 꿈 잘 찾아가고 있어?
현상 유지하는 것은 평온하다는 것을 의미하고, 그것도 꽤 좋은 가치가 있다. 그러나 이게 2년이 되었고 지금의 나도 이걸 바라는가? 질문을 하게 되었다. 깊은 나의 욕망엔 가슴이 뜨거워지고 싶다
가슴이 뜨거운 것은 여러가지가 있다. 일단 현재의 속도를 유지하는 것 이상으로 해야 가슴이 뜨거워진다. 이런 것을 인지해서 앞으로 커리어 방향성이 조금 더 조정되지 않을까 싶다
- 교육자 관점에서도 가슴이 뜨겁지만, 더 뜨거우려면? 어떻게 가치를 줄 수 있을까?
- 나는 내가 좋아하는 것에 관련해서 일을 할 때 더 즐겁다. 보람을 느끼는가? 이 질문을 주로 하면서 일을 진행한다
- 꼭 IT가 아니더라도 다양한 것들을 보고 있다. 어떤 것이 있을까? 무엇을 내가 해볼까? 다양한 산업에 있는 사람들과 이야기를 나눠야겠다. 생각해보면 커피챗 등도 소극적으로 했는데 다양하게 만나는 것도 필요한 것 같다
콘서트를 다녀오고 느낀 점은 네이버 블로그에 생생하게 담았다
외부에서 동기부여를 잘 받지 않는데, 이런 동기부여를 받을 수 있어 너무 감사했다

9) 동유럽

6월에 동유럽(헝가리, 오스트리아, 체코)에 다녀왔다. 동유럽에서 충격은 고사우 호수. 참 아름답다. 고사우 호수를 보고 이 자연 앞에 나는 그냥 작은 생물이고, 이 광활함이 대단하다고 느꼈다
자연에 대해 신경쓰는 것도 중요하겠다 싶었고, 나는 내가 할 일을 열심히 해야지 이런 생각이 들었다

프라하에서 코젤 공장에 갔는데, 그 경험도 좋았다. 맥주도 맛있지만 공장의 생산 시스템이 장난 아니다. 하루에 몇만병을 생산하는 시스템은 이렇군? 이런 생각도 하면서 대단하다고 느꼈다
- 생산을 이렇게 대량으로 하는 하드웨어가 꽤 임팩트 있었다. 대량 생산을 하는 것은 이정도의 시스템이 받춰줘야 가능하구나.. 산업 혁명을 직접 눈으로 본 느낌이다
- 다시 생각해보니 코젤 다크와 코젤 라거를 반반 섞은 맥주가 정말 맛있었다. 공장에서 바로 먹는 맥주는 진짜 차원이 다르다
- 아래 영상은 코젤 다크에서 맥주를 생산하는 공정의 영상. 코젤 다크 브루어리 투어가 있음. 소리가 클 수 있으니 음량을 작게 줄이고 보시는 것을 추천!

10) 요리 시작

올해는 다양한 요리를 시도했다. 류수영님, 성시경님, 슬기님 레시피를 주로 활용했다
요리도 하니까 계속 실력이 늘어난다. 개발이랑 비슷하다(??)
- 점점 더 재미있고, 나만의 방식을 조금씩 도전하고 새로운 레시피 만드는 중
- 나를 위해 좋은 한끼를 만드는 것이 참 중요하다. 내 몸을 소중하게 여기자
특히 편스토랑 류수영님 레시피 중에 2회 이상 했던 것
성시경님의 냉삼파덮밥
기가 막히고 쉬운 바지락술찜
그리고 요즘은 솥밥을 자주 해먹는다
- 이가모노 가마도상을 구매했는데, 사용도 쉽고 밥이 맛있게 된다
- 소고기 가지 솥밥, 옥수수 솥밥, 명란 솥밥, 차돌 솥밥 등을 했다. 진짜 쉽다
- 아키텍처처럼 정리했다. 다른 분들이 솥밥 요리하고 싶으면 쉽게 설명할 수 있다
솥밥 만들기(이가모노 가마도상 활용)
- 밥
  - 밥엔 쯔유 2스푼 + 버터 1조각을 넣고 끓이면 됨
  - 물의 양은 1:1.2(물이 1.2, 쌀이 1)
  - 만약 재료에 물이 좀 나온다 하면 1:1
  - 가마도상은 쌀 오래 뿔리지 않아도 괜찮음(공식 피셜)
- 솥밥에 넣을 재료
  - 보통 밥을 10분 끓이고, 그 후에 뜸 들일 때 넣음
  - 밥 올리고 그 사이에 요리하면 됨
    - 예 : 가지 볶음, 소고기 요리, 옥수수 정리 등
- 뜸 : 20분
- 사전 준비 10분 미만, 총 40분 이내(밥 올리고 뜸이 거의 30분)
  - 즉, 밥 + 재료만 고민하면 됨. 재료는 항상 바뀔 수 있음
- 솥 정리
  - 밥 먹고 누룽지 만들거나 바로 설거지 추천

2024년 총평

2023년은 유지의 해였고, 24년은 유지 이후에 조금씩 나아가는 시간
혼자 시간을 보내며 나에 대해 더 많이 생각했다. 발전도 했으나, 여전히 나는 더 발전하고 싶음을 느꼈다.
하려는 것을 25년에 빠르게 마무리를 해보고, 나의 Next를 생각해야지. 취업이든 사업이든.

요즘 생각들

이번엔 요즘 주로 하는 생각들을 작성해본다. 바로 떠오르는 순서로 작성했다

커리어

언제부턴가 커리어에 대한 고민을 크게 하지 않는다. 정해진 커리어 루트가 있는 것도 아니고, 내가 그런 루트를 그대로 따라가는 성격도 아니라서
- 주니어 때는 내가 될까?라는 걱정과 불안이 있다면, 시간이 지나고 ‘아 어찌되었든 내가 무엇을 해서 시간이 흐르고, 그래서 뭐가 되는구나’라는 것을 깨달은 후부턴 크게 걱정하진 않는다. 지금 하고 싶은 것을 고민할 뿐
직무 관점에서도 나는 데이터 분석, 데이터 엔지니어, 머신러닝 엔지니어, MLOps 등 다양한 직무를 경험했다. 데이터 조직의 리더, 데이터 조직 전체의 피플 매니저, Engineering Manager 등 회사에서 요구하는 역할을 계속 수행했다.
- 누군가는 제너럴리스트라고 볼 수 있는데, 나는 그냥 지금 처한 문제를 해결하고, 문제가 바뀌면서 다양한 경험을 했다고 생각한다. 직무에 나를 한정할 필요는 없다
- 또한 직책을 목표로 둘 필요가 없다고 생각한다. 직책은 직책일 뿐
내가 기여할 수 있는 것이 많은 곳을 가려고 한다
용호님의 AI 시대 데이터 직군을 위한 생존 전략 인프런 강의 영상이 참 좋다
- 나도 어떻게 보면 풀스택 데이터 사이언티스트처럼 이것저것 다양하게 경험했다
- Ortools, dbt, DuckDB, BigQuery 등. 어떻게 보면 이 발표에서 나오는 형태의 직무는 나와 유사할지도
요즘은 내가 필요한 제품을 만드는 시도를 하고 있다
- 프론트는 자신이 없는 편인데, 요즘 AI가 빠르게 발전해서 나도 프론트를 예전보다 수월하게 만들 수 있다. 그래서 내가 필요하다고 생각한 제품을 하나씩 만든다
  - Supabase + Next.js 조합을 사용하는 중
- Python을 주로 사용하다가, 웹개발을 할 때는 자바스크립트가 편해서 이쪽을 하고 있다
- 좀 더 나아가서 앱까지 하고 싶은데, 이건 일단 추후에..!
- Flutter Flow 같은 노코드 도구를 사용해서 구현하려고 했는데 이럴거면 차라리 개발을 더 하는게 좋을 것 같다고 생각해서 개발을 직접 하는 것으로 틀었다. 개발 역량이 적다면 Flutter Flow도 매우 추천
가슴이 더 뜨거워지고 싶다. 가슴을 어떻게 뜨겁게 할 수 있을까?
- 가슴이 뜨거웠던 시기를 생각하면 연차가 낮을 때와 타다 업무를 했을 때. 그 당시에 참 즐겁고 엄청 몰입해서 업무를 진행했다
- 그와 비슷한 형태를 찾고 있다. 그게 어떤 형태가 될진 모르고, 정해두지도 않았다
- 일단 지금 내가 하고 싶은 것, 그리고 그걸 위한 준비와 경험을 하고 있다
뭐가 되었든 나의 경험이 쌓이고 있다. 너무 걱정하지 말자
- 너무 걱정이 된다면 나의 기준이나 나의 행동 지침을 정리해보자. 보통 암묵지로 어떤 것을 하면 좋더라!라는 것이 암묵지로 있는데, 명시적인 지식으로 보관하자
- 난 어떤 상황에 어떤 기준으로 한다라는 것이 쌓이면 그게 곧 원칙 모음집이 되고, 그 기준들이 나를 이룰 수 있다
- 관련해서 불변의 법칙 책도 매우 추천. 이렇게 각자의 원칙을 기록해두고 그렇게 생각하게 된 이유나 사례를 작성해보면 좋겠다
기술적으로 관심을 가지는 부분도 있는데, 이건 추후에 글을 작성하면서 공유하기로

다시 글을 쓰기 시작했다

글또 10기는 마지막 기수라서, 나도 다시 글을 쓰는 참여자로 활동하기로 다짐했다. 다만 내가 어떤 채널에 속하는게 애매할 수 있어서 별도의 시스템을 만들었다
- 포켓몬 골드 버전에서 전설의 강아지 포켓몬들이 랜덤하게 돌아다니는 것처럼, 나도 랜덤하게 특정 채널에서 글을 제출한다. 그리고 사람들이 잘 잡으면(??) 포인트를 지급한다
- 나도 글을 계속 쓰도록 하는 장치고 사람들이 채널을 계속 보면 좋겠다란 생각에 만들었다
글을 쓰면서 공부도 하고, 다시 루틴이 잡히고 있다. 이런 습관은 확실히 어느정도 살짝의 강제성이 있으면 더 좋다. 힘들어도 일단 쓴다(??)
네이버 블로그엔 일상적인 생각을 기록하고 있다. 그 과정에서 알라미 서포터즈를 진행했는데, 알라미 앱이 참 섬세하다고 느꼈다. 내부에서 데이터를 보면 더 재미있을 것 같다는 생각도 들었다. 알라미를 사용하면 잘 일어날 수 있어요!
하루에 보는 컨텐츠를 극단적으로 줄였다
- 영감 받는 컨텐츠 3개 기록하기. 6개월 정도 진행했다
- 왜 이후에 진행을 못했나? 생각하면 컨텐츠를 보지 않는 날도 많았다. 그냥 넘어가는 시기가 있다보니까 그렇게 되었다
- 그런데 돌이켜보면 하루에 3개 보는 루틴이 꽤 유의미했다. 이런 것을 더 잘 진행할 수 있도록 하면 도움이 될 것 같다
글을 작성하면서 효능감도 생기고, 머리 속에 있는 내용이 정리가 된다. 기술 블로그, 네이버 블로그 등 다양하게 글을 작성해야겠다
최근에 작성한 글들

메타인지와 도전

나를 잘 아는 메타인지는 항상 중요하다. 매번 생각하는 주제인데, 나도 계속 바뀐다. 바뀌는 나를 빠르게 인지하는 것도 중요하다
- 이건 일기를 쭈욱 써보고, 월별로 내가 어떤 생각을 하고 있는가? 회고하면 빠르게 인지하게 된다
- 나의 메타적인 생각을 해본다. 어? 나 그 때 왜 그랬지? 무슨 감정으로 그런거지?
내가 나를 잘 인지하고, 무언가를 실행하고, 또 실행하는것의 연속인 것 같다
이 과정에서 불편한 진실 같은 것을 직면해야 할 수도 있는데, 그것을 잘 승화하는 것도 중요하다
- 부정적 피드백을 어떻게 잘 승화할 것인가? 이것도 사람들이 자주 물어보고 회사나 인간 관계에서 경험할 수 있는 소재
나를 잘 이해하기 위해 요즘엔 질문을 만들고 있다. 인터넷이나 책에 있는 질문에 답하는 것을 넘어서서 내가 중요하게 생각하는 질문을 만들고, 나중엔 이 질문 기반으로 대화하는 모임을 만들고 싶다. 독서 모임과 인생 철학, 자신의 기준을 이야기하는 모임을 만들고 싶다. 그리고 이 모임은 오래 오래 가면 좋겠다(시간의 흐름에 따라 기준들이 바뀌는 것을 보는 것도 영감이 될 것)
메타인지를 한 후엔 도전해야 한다. 그냥 멈추지 말고 도전하자. 작게라도 도전. 쉬는 것도 도전.
나의 꿈은 무엇이였고, 꿈의 크기는 무엇인지 생각해보기
- 계속해서 꿈을 찾아 나가자.
살아있음을 느끼는 순간은 사람마다 다양하다. 언제 살아있다고 느끼는가?
- 나는 자신의 열정이 뛰어서 무언가를 하고 있거나, 영감을 받을 때다. 이게 결국 메타인지, 도전, 꿈과 연결된다
최근에 알게 된 나의 속성 중 하나는 “내가 알고 있는 지식, 내용을 다른 사람에게 잘 공유하고 싶은 것. 그것이 도움이 되길 바라는 마음에 적극적으로 공유한다”
- 예를 들어 포르투 여행을 가려고 하는 사람에게 정말 진심을 다해 스케줄을 짜주기도 하고, 동유럽 여행을 고민하는 분에게 내가 조사한 것들을 공유하기도 한다
  - (포르투 여태 30명 넘게 보냄. 포르투 워케이션 후기 페이지에 자세한 내용이 담겨있다)
- 상대가 어떤 고민을 가지고 있는데, 내가 그 경험을 했고 사용한 제품이 있다면 적극적으로 공유한다. 듣는 분들이 나에게 소비 요정이라고 말한다..^^.. 스토리텔링이나 설득이 잘 된다고 한다. 영업을 해도 괜찮은걸까?
- 예전에 네이버 블로그를 했던 것, 기술 블로그를 하는 것, 강의 만드는 것 모두 내가 아는 지식을 잘 공유하려고 한다. 큐레이션이라고 봐도 좋을 것 같다
- 이런 속성을 이해하니 그동안 왜 블로그에 글을 작성했는지 이해했다. 아 이래서 내가 좀 더 수월했구나..!

1인 사업자의 삶, 루틴

1인 사업자도 벌써 2년이 되었다. 어느정도 익숙해졌다
송길영님의 책 시대예보 : 호명사회 내용이 흥미로웠는데, 내 이야기였다. 내 이름을 부를 수 있는 일을 하고 있고, 내가 생각하고 경험하는 내용이 나와있었다. 시대의 흐름을 잘 읽으신다
1인 사업자의 삶을 궁금해하는 분도 꽤 많다. 교육자나 개발자나 둘 다 1인 사업자로 볼 수 있는데, 이런 사람들에게 내 경험을 전달해도 도움이 될 것 같다. 일단 글로 정리하고 나중에 발표로 만들 수 있을 것 같다
1인으로 일하는 것은 환경 설정이 필요하다. 어떻게 보면 법인으로 넘어갈지 말지를 결정하는 기준 중 하나로 볼 수 있는데, 혼자 일을 하더라도 사람들이 같이 있으면, 덜 나태해진다.
나태해지지 않기 위해 루틴을 계속 시도한다(이건 진짜 끝나지 않는 숙제다) 오전과 낮엔 업무에 집중하고, 저녁엔 내가 하고 싶은 것을 한다. 그 이유는 저녁엔 보통 쉬고 싶기에 내가 하고 싶은 것을 하는게 더 효과가 좋았다. 알라미 앱을 사용해서 특정 시간에 뭐 해야지! 이런 트리거를 만들어서 활용하고 있다
- 몇개의 원칙을 공유하면
- 일단 꼭 씻는다. 씻으면 일을 하게 되는데, 씻지 않으면 나태해지더라. 그래서 좀 더 나를 Active한 상태가 될 수 있도록 설정
- 온라인으로 같이 공부하는 Study With Me나 모각코를 이용한다. 같이 일을 하는 것처럼 느껴지도록..!
만약 글또 이후에 커뮤니티를 한다면 1인 사업자나 1인 개발자 커뮤니티를 만들 확률이 높다. 내가 지금 그 상황이라..!

교육은 어떻게 바뀌어야 하는가?

위에서 말한 것처럼 요즘은 직접 개발을 하고 있다. 예전엔 리액트를 배우며 좀 어렵다? 이런 생각이 들었는데 이젠 어려워도 하나씩 해결할 수 있다. 예전보다 생산성이 급 증가했다. 타입스크립트를 자세히 모르지만 일단 만들고, 그 만드는 과정에서 동기부여가 생기고 하나씩 할 수 있게 된다
이런 경험을 하면서 데이터쪽은 어떻게 교육을 진행해야 할지 고민이 생긴다
- 데이터쪽도 구체적으로 나누면 분석, 엔지니어링으로 나뉜다
- 엔지니어링은 개발과 거의 맥이 유사해서 개발쪽의 문제 해결과 유사하게 할 수 있다. 다만 선행적으로 프론트나 백엔드가 먼저고 그 후에 데이터 엔지니어링을 고려하게 된다. 그래서 데이터 엔지니어링을 고려한 프러덕트를 만들면서 프로젝트하는 것이 좀 어려울 수 있다. 그래서 초반엔 백엔드를 하다가 점진적으로 데이터 엔지니어링을 하는 것이 괜찮을 것 같다
- 분석쪽은 데이터가 필요하고, 의사 결정이 중요하다. 의사 결정을 하고 Action Item을 내는 것
  - 이게 참 교육하기 어렵다. 암묵지도 있고, 도메인 지식도 알아야 한다
  - 나도 계속 시도하고 있지만 도메인 지식까지 고려한 강의를 만드는 것은 어렵고 일단 핵심적인 부분을 정리해서 공유하고 직접 경험해보고 그것을 토대로 더 나아가도록 하는 것이 필요하다
  - PM을 위한 데이터 리터러시도 사례 중심으로 진행했는데, 일하는 패턴을 생생하게 담았다. 근데 그 이후 강의를 만든다고 하면 뭘 해야 할까?에 대해 생각을 한다
교육은 점점 바뀌고 있다. AI와 같이 협업하는 방식으로 일을 하고 있고, 학습도 이와 비슷하게 진행하고 있다.
- 이런 시기라면 단순한 지식 전달보단 프로젝트를 하게 만들고, 만들면서 깨달음을 얻고 스스로 주체적으로 의사결정 및 판단을 할 수 있도록 하는게 중요하지 않을까?
- 물론 과거에도 중요했지만 요즘엔 더 중요해진 것 같다
- 회사에서 채용을 아직 많이 하진 않고 있어서, 이럴 땐 어떻게 해야할까 관점도 고민이 된다
- 용호님 강의처럼 풀스택 데이터 사이언티스트가 필요한 시기가 오고, 데이터 직무들이 새롭게 정의될 수도 있을 것 같다. 데이터 기반 문제 해결사. Problem Solver 느낌
뜬금 없지만 대성마이맥이나 메가스터디에서 일을 해보고 싶다. 컨텐츠 만드는 조교라도 잠깐 할 수 있을까?
- 거긴 어떤 프로세스를 가지고 있을까?
- 중학생, 고등학생들도 데이터나 AI를 공부하는데 이 친구들이 더욱 잘 학습하는 환경을 만들려면 어떻게 해야할까. 이 부분도 사회적으로 참 중요한 부분인 것 같다
정답은 없지만 이런 생각을 주로 혼자 하는데, 교육에 대해 고민하는 분들과 같이 논의해도 즐거울 것 같다. 실행까지 하면 더욱 좋고

2025년에 시도할 것

만약 과거에 진행한 것들을 다시 한다면?
- 데이터 조직을 바닥부터 다시 만든다면?
- 진행한 ML 프로젝트를 다시 진행한다면?
- 과거에 했던 프로젝트를 더 빠르게 할 수 있어야 한다고 생각한다. 왜냐하면 나의 역량도 발전했을 것이고, 기술도 발전했다. 그래서 이런 것들을 진행해보고 그 차이를 기록한다. 이건 종종 했는데, 더 시간을 잡아서 해야겠다
- 이 과정에서 나만의 기준을 더 추가할 수 있을 것 같다
많이 시도해보기
- 무엇이여도 괜찮으니 많이 시도하자. 너무 평온한 삶을 추구하지 말고 이것저것 시도해보자
- 꿈을 찾아서 이것저것 해보고, 가슴이 뜨거울 수 있도록 노력해보자
- 본 업의 실력도 계속 올리기. 다양한 것들을 보며 직접 만들기
데일리 다이어리 작성하기
- 주로 위클리를 썼는데, 하루의 밀도를 더 높이고 싶어서 데일리 다이어리를 샀다. 매일 매일을 자세히 기록하자
- 이렇게 설정하면 또 무언가를 할 것 같다
게임처럼 내 선택으로 인해 이후 선택이 새롭게 생기고, 제약이 생기기도 한다. 장기 턴제 게임을 하는 느낌
- 평행 우주론을 믿는 나는 여러가지의 패턴의 내가 있을 것이라 생각한다
- 강의를 계속 더 많이 하는 나, 회사에 들어간 나 등
- 다양한 케이스에서 내가 그걸 하려면 뭘 해야할지, 근데 난 지금 뭐 하고 싶은지 고민해봐야겠다
도전을 해보자. 내가 너무 수동적으로 있지 말고, 안정적으로 있지 말고. 오늘의 내가 제일 어리다. 이럴 때 많이 도전해보자. 그동안 충전은 다 했다. 이제 더 도전!
초심을 잃지 말자. 처음에 내가 하려고 했던 것은 무엇인가, 그리고 그걸 잘 하고 있을까
사람을 소중히 여기기
- 방 청소하다가 퇴사할 때 팀원분들이 작성해준 편지를 봤다. 참 고맙다. 다들 잘 지내고 있을까? 조만간 근황을 물어봐야지
또 중간에 추가되면 업데이트하기

글 작성하는데 걸린 시간 : 5시간 20분

Ortools 사용법 및 최적화 이론(Linear Programming)

Mon, 16 Dec 2024 00:00:00 +0000

최적화 소프트웨어인 Ortools의 사용법과 최적화 이론(Optimization)에 대해 작성한 글입니다
- 키워드 : Ortools 사용법, Ortools Python, Ortools Install, Optimization, 최적화 이론, Linear Programming

최적화란?

최적화 소개, Operation Research의 문제

최적화(Optimization)는 여러 분야에서 다양하게 사용되는 개념
- 최적화의 정의 : 주어진 제약 조건에서 목표를 가장 잘 가장 좋은(최적의) 해답을 찾는 과정
- 데이터, AI 분야 : 머신러닝 모델의 파라미터를 찾는 과정에서 사용(Gradient Descent, 비선형 최적화)
- Operation Research 분야 : 비즈니스 의사 결정 문제를 해결하는 과정에서 사용(Linear Programming, Integer Programming)
- 이 글에선 Operation Research 분야의 최적화를 주로 설명할 예정
Operation Research란?
- OR은 운용 과학(또는 운영 과학, 경영 과학)이라고 번역이 되는데, 수학적인 방법을 사용해 복잡한 의사결정 문제를 해결하는 학문 분야
- 군사 작전에서 의사 결정을 최적화하기 위해 시작했고, 여러 산업의 문제 해결에도 사용됨
저는 회사에서 최적화 관련 프로젝트를 진행하면서 익혔고, 팀원분과 아래 프로젝트를 진행하면서 이해도가 높아졌어요
- 자세한 내용이 궁금하시면 아래 글을 참고해주세요
- 함께 프로젝트를 하며 제 최적화 역량 향상에 도움을 준 캐롯 감사해요!!!
- 쏘카 예약을 효율적으로 - 수학적 모델링을 활용한 쏘카 예약 테트리스
- 그 외에 모빌리티 문제가 궁금하시면 Awesome-Mobility-Machine-Learning-Contents을 보시면 모빌리티 산업의 논문을 확인할 수 있습니다. 꽤 많은 문제들이 데이터, AI, ML, OR로 풀 수 있는 문제들입니다

최적화로 풀 수 있는 여러 문제들

여러가지 문제들
- 공장의 생산 계획 최적화
- 물류 센터의 배송 경로 최적화
- 그 외에도 재고 최적화, 가격 최적화 등에도 적용될 수 있음
- 통신사에서 기지국, 중계기의 최적 위치 선정하기
- 대역폭 할당 : 트래픽에 따른 최적 자원 분배
- 시간표 작성 : 교사, 강의실 배정 최적화, 학생 배정
- 버스 노선 : 버스 경로 최적화
- 항공편 스케쥴링, 승무원 스케쥴링 근무 최적화
- 광고 플랫폼에서 광고 예산 할당, 여러 채널의 예산 최적 분배 / 입찰가 최적화, 타겟팅 최적화
- 모빌리티, 물류, 광고 도메인에서 많이 활용됨
위 내용들을 Operation Research 책, 강의에선 다음과 같이 정의함
- 수송 문제(Transportation Problem)
  - 여러 공급지에서 여러 수요지로 물건을 운송할 때 최소 비용을 찾는 문제
  - 예 : 세 개의 창고에서 다섯 개의 매장으로 상품을 배송할 때 운송 비용을 최소화하는 방법을 찾는 것
- 할당 문제(Assignment Problem)
  - m명의 작업자를 n개의 작업에 배정하는 문제. 각 작업자마다 각 작업에 대한 능력치가 다를 때, 전체 효율을 최대화하는 배정 방법을 찾음
  - 예 : 6명의 직원을 5개의 프로젝트에 가장 효율적으로 배정하는 문제
- 네트워크 최적화(Network Optimization)
  - 최단 경로 찾기, 최소 신장 트리 구하기 등의 문제
  - 예 : 여러 도시를 연결하는 도로 네트워크에서 최소 비용으로 모든 도시를 연결하는 방법을 찾는 것
- 배낭 문제(Knapsack Problem)
  - 제한된 용량 안에서 가장 가치 있는 물건들의 조합을 찾는 문제
  - 예 : 무게 제한이 있는 등산 가방에 어떤 물건들을 넣을지 결정하는 것
- 스케줄링 계획(Scheduling Problem)
  - 작업들의 순서와 시작 시간을 정하는 문제
  - 예 : 공장에서 여러 제품을 생산할 때 기계 사용 순서를 최적화하는 것
이 글에선 최적화를 배울 때 초반에 배우는 Linear Programming(LP)에 대해서 다룸
- Linear Programming : 선형 제약 조건 하에서 선형 목적함수를 최적화하는 방법

최적화 진행 프로세스

(1) 문제 정의 및 수학적 모델링
(2) 알고리즘 결정
각각의 과정은 유기적으로 진행함(수학적 모델링을 하면서 알고리즘을 결정하기도 함)

1) 문제 정의 및 수학적 모델링

문제 정의

주어진 문제 상황을 보고, 다음 요소를 생각함
실제 현실의 문제를 수학적 모델로 변환하는 단계
최적화 문제의 구조
- 의사 결정 변수
- 목적 함수
- 제약 조건
의사 결정 변수(Decision Variables)
- 우리가 실제로 찾고자 하는 값
- 예 : X, Y
목적 함수(Objective Function)
- 최대화, 최소화하는 대상
- 예 : 이익 최대화, 비용 최소화
제약 조건(Constraint)
- 의사 결정 변수들이 만족해야 하는 조건
- 예 : 예산 제한, 생산 용량 제한, 한사람이 연속으로 스케줄을 진행할 수 없음
참고로 목적 함수가 없다면, 최적화 문제가 아닌 실행 가능성 문제(Feasibility Problem), 제약 만족 문제(Constraint Satisfaction Problem, CSP)라고 할 수 있음
- 이 케이스는 조건을 만족하는 해가 존재하는가? 조건에 만족하는 해를 찾음
- 최적화 문제는 조건을 만족하는 해 중 가장 좋은 해는?
- 때론 최적(Optimal)이 아니여도 조건에 해당되는 값만 찾아도 괜찮은 경우가 있음

문제 상황 파악

우리가 통제할 수 있는 것(의사 결정 변수)과 통제할 수 없는 것(파라미터)를 구분함
- 생산 계획(어떤 제품을 만드는 계획)에서 통제 가능한 것과 통제 불가능한 것을 나누면
- 통제 가능: 제품의 생산량
- 통제 불가능 : 시장 수요, 원자재 가격
목표 설정
- 달성하고자 하는 것
- 보통 이익 최대화, 비용 최소화, 생산 시간 최소화가 많이 사용됨
제약의 여러 종류
- 물리적 제약 : 저장 공간, 생산 능력
- 논리적 제약 : 선행 관계, 상호 배타성
- 정책적 제약 : 최소 주문량, 예산 제한

최적화 문제 예시

과자 공장에서 과자 A와 B를 생산 A는 개당 100원의 이익, B는 개당 150원의 이익이 발생
하루 최대 생산량은 총 200개
A는 최소 50개 이상 생산해야 함
위 문제를 정의하면
- 의사 결정 변수 : A의 생산량, B의 생산량
- 목적 함수 : 이익 최대화
- 제약 조건
  - 총 생산량 제한(두 요소의 생산량을 합치면 200보다 낮아야 함)
  - x 생산량 제한(최소 50개 이상)
  - x, y는 모두 0 이상(음수 생산 불가능)

최적화 문제 예시 2

커피숍에서 바리스타 근무 시간표를 짜야 함
가게는 매일 9시부터 22시까지 운영
시간당 최소 2명의 바리스타가 필요
각 바리스타는 하루 8시간 근무
인건비를 최소화하고 싶음
위 문제를 요소에 맞게 정의하면
- 의사결정 변수: 각 바리스타의 시작 근무 시간
- 목적함수: 총 인건비 최소화
- 제약조건
  - 매 시간 최소 인원 충족(최소 2명)
  - 근무 시간 제한(하루 8시간)
  - 운영 시간 준수(9시 ~ 22시)

수학적 모델링

위에 정의한 내용을 수식으로 변환하는 과정. 외국어 번역과 유사함
최적화 문제 예시 1의 과자 공장 생산량 결정 문제
- 의사 결정 변수 : A의 생산량, B의 생산량
- 목적 함수 : 100x + 150y = 이익
- 제약 조건
  - x + y <= 200(총 생산량 제한)
  - x >= 50(A 최소 생산량)
  - x, y >= 0(음수 생산 불가능)
최적화 문제 예시 2의 커피숍 바리스타 스케줄링 문제
- 의사결정 변수 : 이것이 답이 되는가?
  - 각 시간대별로 일하는 바리스타의 수”가 답이 될 수 있을까
  - 수식으로는: x₁ = 9시 바리스타 수, x₂ = 10시 바리스타 수, …
- 목적함수는 “우리가 최적화하고 싶은 것”을 수식으로 표현
  - “인건비 최소화”가 목표
  - 시급이 10,000원이라면 MIN(SUM(10000(x₁ + x₂ + … + x₁₃)))
- 제약조건은 ~해야한다를 찾아서 부등식이나 등식으로 바꿈
  - “매 시간 최소 2명이 있어야 한다”
    - x₁ ≥ 2, x₂ ≥ 2, … (각 시간별로)
  - “한 사람은 8시간까지만 일할 수 있다”
    - 이 조건은 조금 더 복잡하지만, 결국 “연속된 8개의 x의 합”이 관련됩니다
“최소 ~명이 필요하다” → x ≥ (숫자)
“최대 ~개까지 가능하다” → x ≤ (숫자)
“A와 B를 합해서 ~이하” → x + y ≤ (숫자)
“A는 B의 두 배 이상” → x ≥ 2y

만약 수학적 모델링 과정이 어렵다면

최종 Output 먼저 생각하기
- 이 문제를 풀면 뭘 알고 싶은가? : 이 질문은 회사에서 커뮤니케이션을 할 때도 도움이 된다. 회의할 때 자주 활용함
- 물류 창고의 위치를 찾고 싶은 경우
  - 어느 위치가 가장 좋을지를 알고 싶어요
  - 그러면 의사결정 변수는 x 좌표, y 좌표
극단적인 케이스 생각하기
- 제약조건을 찾을 때 활용
- 창고가 서울에 있어도 되나요?
  - 아뇨. 너무 땅 값이 비싸요 → 그럼 땅 값을 제약 조건으로 사용
처음엔 단순하게 접근하고 점진적으로 요소 추가하기
- 처음에 모든 현실적 제약을 고려하려고 하면 어려움
- 단순한 버전으로 한번 만들고, 거기서 제약을 추가하는 방식으로 문제 정의하는 것을 추천

2) 알고리즘 결정

최적화를 진행할 때 선택할 수 있는 알고리즘은 다양함

이미지 출처 : neos-guide
최적화 문제를 정의하고, 여러 기준을 토대로 알고리즘을 결정함
- 변수가 연속적(Continuous)인가? 이산값(Discrete)인가?
  - 변수가 실수 값을 가질 수 있는 경우 : Continuous -> LP 고려
  - 변수가 정수나 2진(Binary)값을 가지는 경우 : Discrete -> Integer Programming(IP), Binay Integer Programming(BIP) 고려
  - 변수가 실수, 정수 모두 다 사용해야 한다 -> Mixed Integer Programming(MIP)
- 제약 조건과 목적 함수가 선형적인가?
  - 선형적이다 : 변수가 1차식으로만 표현, 변수끼리 곱하지 않음
  - 제약 조건과 목적 함수가 선형이면 LP/IP/MIP
  - 비선형이 존재하면 비선형 최적화
- 논리적 제약이 많은가?
  - 복잡한 논리적 제약이 있으면 Constraint Programming(CP)
  - 제약 조건이 없는 경우엔 Unconstrained Optimization
- 불확실성 여부에 따라서 다름
  - 불확실함이 없는 경우 : 모든 데이터를 정확히 아는 경우 => LP, IP
  - 불확실함이 있는 경우 : Stochastic Optimization, Robust Optimization
또한 해 관점에서
- 최적해가 반드시 필요한가?
- Feasible한 값도 괜찮은가?(Feasible : 제약 조건을 만족하는 해. 최적은 아니지만 조건을 충족한 값을 의미)

Linear Programming

선형 계획법
- 많은 현실 문제를 선형으로 근사할 수 있음
- 복잡한 최적화 문제를 해결할 때 선형 계획법이 기초가 되는 경우가 있음
- 위 최적화 문제 예시 둘 다 LP 문제
LP에서 주목할 점
- 모든 식이 일차식(xy 같은 이차항이 없음)
  - 선형 계획법의 기본 요구사항은 모든 식이 일차식이어야 함
  - 수학적인 선형은 변수들이 곱해지거나 제곱되지 않고, 단순히 더해지기만 하는 것을 의미미함
  - 선형인 식 : 3x + 2y
  - 비선형 : xy(변수가 곱해짐) 또는 x^2(변수가 제곱)
  - 선형성이 보장되어야 global optimum을 찾을 수 있음. 비선형이 되면 문제가 훨씬 복잡해짐
- 부등호 사용
  - 현실의 제약을 표현할 때 중요함
  - 제약 조건을 잘 보는 것이 중요한데, 재료를 정확히 M을 사용한다보단 M 이하로 사용한다가 현실적인 옵션(재료는 남아도 되므로)
- 음수 제약이 명시적으로 포함
  - 음수 제약이 없으면, 수학적으로 -10개 생산이 가능함. 그러나 현실에선 음수 생산은 불가능

최적화 솔루션

최적화 솔루션은 모델링 툴과 솔버로 나뉨
모델링 툴 : 다양한 솔버를 선택할 수 있음. 최적화 문제를 해결하는 인터페이스라고 보면 됨
솔버 : 자동차의 엔진처럼 핵심 알고리즘이 구현됨
- 실제 최적화 문제를 푸는 것은 솔버
- Gurobi, Cplex 등이 대표적인 상용 솔버
- Ortools에서 사용할 수 있는 솔버
  - 단순한 선형 문제 : GLOP
  - 정수 제약이 있는 경우 : SCIP
  - 복잡한 논리 제약이 있는 경우 : CP-SAT 솔버
아래 글에선 구글이 만든 Ortools에 대해 설명할 예정
그 외 최적화솔루션, 솔버에 대해선 Optimization Software에 잘 나와있음

Ortools 사용하기

Ortools는 구글에서 만든 최적화를 위한 오픈소스 제품
차량 라우팅 문제, LP, CP 등의 문제를 처리하는데 최적화 됨
Ortools 문서 : 이 페이지에서 다양한 알고리즘의 설명과 코드 예시를 볼 수 있음
- GitHub에서 예시 코드를 보는 것도 추천
그러나 함수들만 보는 것은 어려움. 문서가 불친절
- Python Doc

설치

pip3 install ortools

Ortools Python 코드 설명

Solver 인스턴스 생성 : 어떤 솔버를 사용할지 명시
```
  solver = pywraplp.Solver.CreateSolver('GLOP')
```

의사 결정 변수 정의

  # 변수 x는 0 이상의 실수값을 가질 수 있음
  # CreateNumVar의 인자는 (최소값, 최대값, 변수 이름)
  x = solver.NumVar(0, solver.infinity(), 'x')
  y = solver.NumVar(0, solver.infinity(), 'y')

제약 조건 설정 : solver.Add로 제약 조건 추가

  # x + 2y ≤ 10 형태의 제약 조건 추가
  solver.Add(x + 2 * y <= 10)
  solver.Add(x + y <= 6)

목적 함수 설정 : solver.Maximize, solver.Minimize 사용

  # 최대화: 2x + 3y
  solver.Maximize(2 * x + 3 * y)

또는 다음과 같이 구성할 수 있음

  objective = solver.Objective()
  objective.SetCoefficient(x, 2)  
  objective.SetCoefficient(y, 3) 
  objective.SetMaximization()

최적화 시작 : solver.Solve()를 실행하면 최적화가 시작

x.solution_value()을 사용하면 값을 확인할 수 있음

  status = solver.Solve()
    
  # 결과 출력
  if status == pywraplp.Solver.OPTIMAL:
      print('해를 찾았습니다!')
      print('x =', round(x.solution_value(), 2))
      print('y =', round(y.solution_value(), 2))
      print('최적값 =', round(solver.Objective().Value(), 2))
  else:
      print('해를 찾지 못했습니다')

정리
- Solver 생성: 문제 유형에 맞는 솔버를 선택. 여기서는 선형 계획법을 위한 ‘GLOP’을 사용
- 변수 정의: solver.NumVar()를 사용해 변수를 생성. 각 변수의 범위를 지정할 수 있음
- 제약조건 추가: solver.Add()를 사용해 제약조건을 추가
- 목적함수 설정: solver.Maximize() 또는 solver.Minimize()로 목적 함수를 설정
- 문제 해결: solver.Solve()로 해를 구함

Ortools의 Solver

GLOP: Google의 자체 선형 계획법 솔버입니다. 순수한 선형 계획법 문제(즉, 모든 변수가 실수이고 제약조건과 목적함수가 선형인 경우)에 사용. 가장 기본적이고 간단한 문제에 적합함
SCIP: 혼합 정수 계획법(MIP) 문제를 풀 수 있는 솔버. 변수 중 일부가 정수여야 하는 경우에 사용함
CP-SAT: 제약 프로그래밍(Constraint Programming) 문제를 위한 솔버. 복잡한 논리적 제약 조건이 있는 문제에 적합함

연습 문제

연습 문제는 직접 풀어보는 것을 추천해요!

연습 문제 1번

작은 가구 공장에서 책상과 의자를 만듭니다.
- 책상: 이익 200달러, 제작 시간 4시간, 목재 30단위 필요
- 의자: 이익 100달러, 제작 시간 2시간, 목재 10단위 필요
- 가용 자원: 하루 작업시간 32시간, 목재 200단위
목표: 하루 최대 이익을 계산하기

연습 문제 2번

작은 학교의 시간표를 작성해야 합니다.
- 3명의 선생님(국어, 수학, 영어)
- 2개 학급
- 하루 4교시
- 각 선생님은 각 학급에 하루 1회 이상 수업
- 한 선생님이 같은 시간에 두 학급에서 수업할 수 없음
- 같은 과목은 하루에 2교시 이상 연속으로 배치할 수 없음
목표는 미정. 실행 가능한 Feasible한 값 출력하기
SCIP 솔버를 사용해서 풀고, 나중에 Constraint Programming을 학습하면 CP로 풀어보는 것을 추천

정리

최적화의 정의와 어떤 흐름으로 문제를 푸는지, 수학적 모델링을 하는 과정에 대해 작성함
- 머신러닝, AI 분야가 아니지만 회사에선 이런 문제를 푸는 경우도 있음
다음 글에선 IP, MIP, CP를 Ortools로 해결하는 과정에 대해 작성할 예정

레퍼런스 및 추천 자료

ORTools 학습 Resource
회사 사례
파이썬으로 구현하는 최적화 알고리즘 - 파이콘 2019 : 다양한 솔버들을 사용한 후기가 있고, Ortools, PuLP에 대해 소개함
Convex Optimization
- 이 분야는 스탠포드의 보이드 교수님 강의가 제일 기본
- 유튜브 영상 : Convex Optimization 1
  - 이 영상은 2023년 강의로 최신 강의. Convex Optimization 2는 아직 올라오진 않음
  - 2008년에 올라온 영상도 있음. 유튜브
- Convex Optimization 책

글 작성하는데 걸린 시간 : 2시간 15분
- 하고자 하는 이야기, 개요 정리 : 13분
- 초안 글 작성 : 46분
- 클로드와 셀프 글 피드백 : 안함
- 2차 글 작성 : 1시간 16분

원온원 6년의 기록: 시행착오와 배움들

Sun, 24 Nov 2024 00:00:00 +0000

이 글은 원온원에 대해 작성한 글입니다
- 6년 동안 진행한 원온원의 시행착오와 배움들을 기록했습니다
키워드 : 원온원 미팅, 원온원 질문, 원온원 템플릿, 원온원 주제

들어가며

저는 3년차(2019년)에 팀장 역할을 맡으며 생각보다 빠르게 원온원을 진행해야 했습니다
‘어떻게 해야 팀원분들과 제가 모두 만족할 수 있는 원온원을 할 수 있을까?’에 대해 계속 고민하고 여러 내용을 학습하고 다양한 시도를 하며 시행착오를 겪었습니다
- 처음 원온원을 할 때를 떠올리면 막막한 감정이 있었고, 좋은 원온원 시간을 가지지 못했던 것 같아요
- 좋은 원온원을 ‘팀원분이 만족스럽게 대화를 끝낼 수 있는가? 무엇을 해야할지 떠올렸는가?’로 정의했습니다
처음 팀장을 하던 시기엔 월에 3~4명과 원온원을 하다가, 시간이 흘러 조직에서 역할이 변경되어 월에 30~40명과 원온원을 진행했습니다
- 그리고 요즘에도 멘토링, 회사 데이터팀 코칭, 경영진 원온원을 진행하고 있습니다
그동안 원온원 역량 상승을 위해 시도했던 경험들에 대해 작성하려고 합니다
참고로 초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들이란 글에 팀장의 역할과 제가 시도한 점들에 대해 정리했습니다
이 글은 제 경험담을 기반으로 작성한 글이고, 이게 정답이다!라는 이야기를 하고 싶은 것이 아닙니다
- 앞으로도 계속 원온원을 하면서 경험이 계속 늘어날 것 같아요.
- 관련 경험이나 의견 남겨주실 분이 계시다면 남겨주셔요

원온원의 정의와 목적

원온원은 단어 그대로 1:1로 이야기하는 것을 의미하며, 팀원분이 더 발전된 형태로 업무를 할 수 있도록 서로 이야기를 나누는 자리
- 주로 팀장님과 팀원이 일대일로 만나 이야기하는 시간
원온원은 다양한 관점으로 진행할 수 있음
- 정기적인 원온원 : 주기적으로 시간을 잡아서 이야기를 하는 경우
- 도움이 필요해서 요청하는 원온원 : 특정 문제에 대한 고민을 이야기하고 싶어 팀원분이 요청하는 경우
원온원의 목적은 ‘팀원의 발전을 돕는 것’이라 생각
- 다양한 관점으로 이야기할 수 있는데, 저는 주로 커리어 관점, 업무 관점, 인간 관점으로 이야기(단순히 회사 한정으로만 생각하지 않음. 거시적인 그 사람의 삶에 대해 이야기)
- 커리어 관점 : 팀원의 커리어를 같이 설계, 역량 개발을 어떻게 할지 이야기
- 업무 관점 : 현재 진행하는 업무에 얼마나 몰입하고 있는지, 어려움이 있는지
- 인간 관점 : 어떤 인생을 살고 싶은가, 스스로에 대한 메타인지
- 기타 : 팀원분이 원하시는 관점이 있다면 그 관점으로 이야기

원온원 역량의 발전 과정

이해를 위해 원온원 레벨을 정의하고, 그 과정의 경험담과 시도했던 것들을 공유
레벨은 이해를 위해 정의한 것이고, 꼭 이걸 충족해야 하는 것은 아님
Lv 1. 초기 : 질문 리스트에 의존한 시기
Lv 2. 본질에 집중한 시기
Lv 3. 맥락에 기반한 개인화된 원온원을 시도한 시기
Lv 4. 조직 전체의 원온원 프레임워크 개발

Lv 1. 초기 : 질문 리스트에 의존한 시기

상황(Context)

3년차 때 팀장을 하면서 생각보다 빠른 시기에 원온원을 진행해야 했음
처음엔 참 막막했음. 원온원을 해본 적이 없는데 어떻게 해야할까?
그래서 일단 어떻게 질문을 해야할지 고민했음. 많은 분들이 처음 시도하면 이렇게 하실 것 같음
구글에 1 on 1 question list, 원온원 질문, 원온원 템플릿 등을 검색하며 질문을 모았음

경험담

원온원 질문 리스트를 기반으로 원온원을 진행했는데, 기계적으로 하는 느낌이 들었음
깊게 대화하는 느낌보단 체크 리스트가 있고 그걸 하나씩 물어보는 제 모습을 보게 됨
A라는 질문에 대해 다 했으면 B로 넘어가고, B에 대해 이야기하면 C에 대해 넘어가며 겉 이야기를 계속 하는 것 같았음
나와 팀원 둘 다에게 소모적인 시간이라고 생각했음

이 시기의 시도

원온원의 본질에 대해 고민함. 원온원 질문이 아닌 본질적으로 사람을 어떻게 도와야 할까?에 대한 생각을 하며 관련 서적을 많이 읽음
그렇다면 도움을 어떻게 잘 줄 수 있을까? 도움에 대해 정의하고, 그 정의에 맞게 Action Item을 실행하기로 다짐함
- 이 과정에서 에드거 샤인님의 헬핑이란 책이 큰 도움이 되었음
- 최근 리더의 돕는 법이란 제목으로 다시 출간되었음
- 이 책을 읽고, 실제로 경험도 하면서 점점 나만의 원칙, 기준이 생겼음
헬핑 책 외에도 도움이 되었던 것은 동기면담, 코칭, 사람 심리, 화법 학습
- 동기면담에 대한 내용은 MITI 동기면담 워크샵 후기 이 글에 내용을 작성했는데, 동기면담을 배우고 1 on 1을 더 잘 수행할 수 있게 됨
- 동기면담은 동기를 이끌어내는 의사소통 스타일, 내담자와 상담 기록을 특정 코드로 부호화함
- 면담의 효과를 평가할 수 있게 됨
또 떠오르는 책은 상자 밖에 있는 사람
- 이 책을 읽고 다른 사람을 어떻게 이해해야 할지, 나의 관점으로만 생각하지 말고 다른 사람의 관점에서 생각할 수 있게 됨
- 팀장을 처음 하는 분들에게 꼭 추천하는 책
시도를 하며 깨달은 점
- “어떤” 것을 질문하는 것보단 팀원을 이해하고, 팀원을 잘 돕는 것이 핵심이라 생각했음. 자주 할 수 있는 질문 리스트가 있지만 너무 질문에 얽매이지 않아도 된다는 것을 느꼈음
- 팀원을 내가 어떻게 도울 수 있을까?라는 생각을 하면서 원온원을 진행하니 부담감도 줄어들고 어떻게 대화를 해야할지 떠오르게 되었음
- 질문 리스트 자체보다, 질문 리스트에 작성한 사람은 왜 이 질문을 하게 되었을까?를 생각하니 도움이 되었음
- 에드거 샤인님은 도움을 다음과 같이 정의함 : “도움은 한 사람이 다른 사람의 문제를 해결하거나 상황을 개선하기 위해 지식, 자원, 감정적 지지를 제공하는 사회적 상호작용 과정”
  - 문제에 대해 초점을 맞추고 감정적 지지를 제공한다는 점을 인상 깊게 봄
  - 단순히 일방적인 것이 아닌 상호작용 과정이라는 것도 중요한 포인트

Lv 2. 본질에 집중한 시기

상황(Context)

Lv 1의 역량 상승을 위한 시도에 나온 것처럼 본질에 집중하니, 이제 원온원 시간을 ‘팀원분은 어떤 도움이 필요할까?’를 생각하며 대화를 진행함
마음가짐이 달라지니 저도 마음이 편해지고, 더 진심을 다할 수 있었음
내가 말을 더 많이 하는게 아닌, 팀원분이 더 이야기를 할 수 있는 환경을 만들려고 했음
- 서로 이야기를 잘 진행하려면 서로에게 신뢰가 필요하다고 생각했음
- 나만 이야기하는 것이 아닌, 상호작용 과정이므로 어떻게 해야 서로 잘 이야기를 할 수 있을까?도 고민함

경험담

팀원분이 어떤 내용을 이야기하는 것이 어려울 수 있어서 최초엔 요즘 어떤지를 물어봄
최근 1달 동안 어떤지를 숫자로 표현해달라고 했음. 0~10점
- 매달 이 질문으로 시작하며 점수의 상승이 어떻게 되는지 파악함
- 처음엔 단일 점수로 물어봤는데, 시간이 지나면서 개인 삶 관점과 회사 관점으로 점수를 나눠서 물어봄
- 이렇게 하면 점수가 올라가거나 내려갈 때, 왜 그런지 물어볼 수 있음. 그러면 어떤 사건이 나타날 수 있고, 이야기를 전개할 때 좋은 힌트가 됨
- 이 과정을 오래 반복하면(같은 분과 원온원을 1년 이상 진행하면) 점수의 상승, 하락에 대한 요인을 생각할 수 있음. 점수가 상승하거나 하락할 때는 비슷한 관점이 발견되는 경우도 있었고, 이 부분을 정리해서 공유하면 팀원분이 스스로 이 부분에 대해 인지할 수 있었음
점수를 기록한 후, “오늘 시간에 다루고 싶은 내용이 있으신가요?”라고 질문함
- 팀원분이 스스로 다루고 싶은 소재에 대해 언급하고, 그 소재에 기반해 대화를 진행함
- 소재가 없는 경우엔 닫힌 질문보단 열린 질문(단답이 아닌 여러 관점으로 이야기를 할 수 있는 질문)을 사용함
서로에 대한 이해가 충분히 있을 경우, 대화가 잘 진행되는 느낌을 받음
- 원온원을 처음 진행할 때, 업무에 대한 내용을 이야기하는 것보다 서로에 대해 이해하는 시간을 가짐. 어떻게 살아왔는지, 어떤 사람인지 등
- 물어보는 내용이 내가 경험한 내용이라면, 과거의 내 생각을 공유했음. 그 시기에 블로그에 작성한 글이 있다면 글을 공유하면서 저도 과거에 비슷한 생각을 했다고 말함
팀원분이 원온원을 하면서 기록하느라 집중하지 못하는 경우도 있었음
- 저는 타자 속도가 600~800타 정도 되어서 말하면서 기록하는 것이 어렵지 않음. 그래서 아예 제가 기록을 다 하고, 팀원분은 자신의 이야기만 집중할 수 있는 환경을 마련함
- 처음엔 노션 페이지를 만들고, 원온원이 끝날 때 공유하는 형태로 진행하다가 추후엔 팀원마다 스프레드시트를 만들고, 그 스프레드시트를 같이 보면서 이야기함. 이렇게 진행할 경우 팀원분이 자신의 의도가 잘 기록되었는가(=제가 제대로 이해했는가)를 빠르게 확인할 수 있어서 대화 중간에 내용을 수정함
팀원분이 도움을 받을 준비가 되었는지도 중요했음. 도움을 받고 싶다는 생각이 없다면 잘 진행되지 않았음
- 이럴 땐 차라리 짧게 끝내고 추후에 고민이 있다면 말씀해달라고 요청했음

이 시기의 시도

신뢰란 무엇인가에 대해 고민함
- 어떻게 해야 신뢰를 할 수 있을까?
- 신뢰에 대한 연구는 과거에 많이 진행되어 있어서, 많이 언급되는 신뢰 모델을 찾아봄
- 데니스 레이나의 신뢰 모델. Trust and Betrayal in the Workplace: Building Effective Relationships in Your Organization 책
  - 신뢰는 상호작용을 통해 형성되고, 시간을 두고 점진적으로 발전함
  - 신뢰의 핵심 요소
    - 역량 신뢰(Competence Trust)
    - 계약적 신뢰(Contractual Trust)
    - 소통 신뢰(Communication Trust)
- 스티븐 코비의 신뢰 모델. 신뢰의 속도 책
  - 신뢰의 핵심 요소
    - 성실성
    - 의도
    - 능력
    - 성과
- 여러 관점을 보면서 나는 어떤 신뢰를 획득했을까?를 고민함
Lv 1 때 역량 상승을 위한 시도는 책이나 영상을 봤다면, 이젠 많이 시도함. 많은 경험을 쌓으려고 함
- 동기면담과 비폭력 대화 내용을 학습해서, 원온원을 할 때 어떤 방식으로 이야기를 전개하는지 나의 화법은 어떠했는지를 점검함
  - 면담 내용을 기록했기에 다시 보면서 점검할 수 있었고, 가끔은 팀원에게 허락을 구해 면담 내용을 녹음하고 다시 들어보며 복기함
  - 다시 들어보니까 더 객관적으로 느껴지고, 아 이런 타이밍엔 이렇게 했었으면 더 좋았겠다를 기록함
동기면담의 총점(Global Score)과 행동 점수(Behavior Counts)를 파악함
- 총점 : 부호를 기록하는 사람이 임상가와 내담자의 전반적인 상호작용을 5점으로 표시. 총 4가지 부분을 확인함
  - 변화 대화 일구기(Cultivating Change Talk) : 변화의 방향으로 대화를 진행하는가?
  - 유지 대화 완화하기(Softening Sustain Talk) : 현 상황을 유지하는 유지 대화를 최소화
  - 파트너쉽(Partnership) : 동등한 파트너끼리 인터뷰하는 것처럼 행동함(상호 커뮤니케이션이 얼마나 있는지 등)
  - 공감(Empathy) : 면담가가 내담자의 세계관을 적극적으로 이해하고 노력하는 정도를 측정
  - 여기선 내가 말한 내용을 기록했지만, 동기면담을 공부하신 다른 분들과 교차 검증을 하면 좋았을 것 같음
- 행동 점수(Behavior Counts)
  - 행동 점수는 정보제공, 설득하기, 질문, 단순 반영/복합 반영, 인정하기, 협동 구하기, 자율성 강조하기, 직면 등의 요소를 확인
  - 자세한 내용은 MITI 워크샵 후기 글에서 확인할 수 있음
과거에 시도했던 내용들을 복기하며 ‘어떻게 진행하자’라는 기준, 원칙을 세움
- (1) 문제를 명확하게 이해하기 전에는 성급하게 이야기를 시작하지 말자
- (2) 말하는 내용이 진짜 문제인가 꼭 확인하자. 때론 진짜 문제가 숨겨진 경우가 있음
- (3) 가치 판단이라고 판단할 수 있는 표현은 피하자.
- (4) 문제 해결은 개인이 스스로 진행해야 하는 것을 언급하자
- (5) 대화가 잘 진행되지 않는 것 같으면 중간에 물어보자 : “지금 어떤 생각이 드세요?”
- (6) 마냥 잘 될것이라는 이야기만 하지 말자. 현실적으로 생각해보자
- (7) 진심을 다 하고 있다는 것을 느낄 수 있도록 집중하자
- (8) 갑자기 원온원 요청이 오면 어떻게 해서라도 시간을 확보해서 이야기
- (9) 원온원 시간엔 슬랙 알람이 오지 않도록 슬랙 아예 끄기. 집중하는 환경 만들기
- (10) 내가 이야기를 많이 하고 있는 것 같으면 멈추자(많이 하는 경우도 있겠지만)

Lv 3. 맥락에 기반한 개인화된 원온원을 시도한 시기

상황(Context)

원온원을 진행하면서 같은 질문이나 같은 반응에 대해 사람마다 다르게 반응하는 것을 느낌
- 사람마다 적절한 질문이 있을 수 있겠다 싶었고, 그 사람의 맥락을 잘 이해할수록 적절한 반응으로 이야기를 할 수 있었음
마치 추천 시스템처럼 그 사람의 메타 정보를 알아두면 좋겠다 싶었음
면담 내용을 기록하는 스프레드시트를 개선해 개인의 맥락을 기록할 수 있도록 개선함

경험담

여러 성격 검사 결과를 보면서 개인에 대해 이해할 수 있도록 하면서, 특정 맥락에서 어떻게 생각하는지를 파악함
- MBTI, Big5, 에니어그램, 갤럽의 강점 검사 등을 토대로 이야기를 진행함. 무료로 할 수 있는 것 위주로 진행하고 유료 검사는 내 결과를 보여줌
성격 외에 과거에 팀원이 수행한 업무, 할 수 있는 업무 종류도 기록함. 전 회사에서 했던 경험들도 알면 도움이 되는 경우도 있어서 같이 이야기함
팀원이 생각하는 강점, 보완할 점도 이야기하고 앞으로 어떤 것을 해보고 싶은지 이야기함
- 어떤 경우엔 앞으로 하고 싶은 것이 없는 경우도 있는데, 그건 문제가 아니라고 답변함. 경험을 하다가 나중에 의미를 찾는 경우도 있었음
  - 이런 경우엔 지금에 충실해서 일을 진행하자고 이야기 함
그 외에는 어떤 상황에 동기부여를 얻는가, 스트레스를 해소하는 방법이 있는가, 멘탈 관리법 등 살면서 한번쯤 경험할 수 있는 것들에 대해 이야기 함
이런 내용을 충분히 인지하니 팀원의 큰 방향성을 인지하며 원온원에선 미시적인 관점을 주로 이야기함
여기서 사용한 템플릿은 아래 구체적인 가이드에 공유할 예정
이 시기에 원온원을 해야하는 인원이 10명, 20명 이상이 되면서 “팀장의 에너지”가 굉장히 중요한 것을 깨달음
- 내가 에너지가 없는 상황에서 원온원을 진행하면 만족스럽지 않은 원온원이 되는 경우가 있었음
- 에너지가 있는 상황을 만들고, 여유를 만들고 원온원에 참여함
- 원온원 일정을 몰아서 하지 않고, 하루에 최대 2-3명만 진행하고 일정을 분산했음
팀원분에게 “제가 어떻게 해드리면 좋을까요?”라고 질문함
- 어떤 분들은 같이 이야기를 하면서 정리를 해주세요도 있고, 어떤 분들은 구체적인 피드백을 요청하는 경우도 있음
- 고민에 대해서 이야기하기 전에 “이 대화가 잘 끝나면 어떤 모습이면 좋겠어요?”라는 질문을 하면서 상상하고, 그 상상을 실현하기 위해 제가 어떻게 해볼까요?라는 질문을 하기도 함. 때론 직접적으로 물어보는 것보다 이렇게 말하는 것이 효과적이였음

이 시기의 시도

원온원을 해야하는 분들이 많아져서 내가 반복해서 사용하는 시간이 늘어남(=운영 리소스 증가)
- 예를 들어 개인마다 스프레드시트를 따로 관리해서 새로운 탭을 추가해야 했음
- 이걸 한번에 할 수 있게 템플릿 시트를 만들고, Apps Script를 사용해 여러 스프레드시트에 일괄적으로 반영하도록 개발함
- 간단하게 URL 시트에 개인 별로 스프레드시트 URL을 저장하고, 면담 템플릿을 복사해서 개인 별 스프레드시트에 들어가서 복사하도록 구현함
여유를 가진 상태로 원온원에 참여하도록 일정을 조정하고, 1회 일정이 아닌 반복된 일정을 추가함
- 나중에 하시죠!라고 하면 까먹는 경우가 많아서 반복해서 했음
- 하루에 최대 2-3명을 진행하고 원온원 직전엔 30분 정도 버퍼 시간을 두고 과거에 작성한 내용을 읽고 들어감
- 과거에 했던 이야기가 반복되면 ‘오 그거 몇달 전에 이야기한 내용과 유사하네요’라고 말해줌
사람마다 다 생각하는 것이 다르다고 생각하고, 어떤 일에 정답은 없다는 것을 항상 생각했음

Lv 4. 조직 전체의 원온원 프레임워크 개발

상황(Context)

팀장에서 상위의 조직장 역할을 하면서, 팀장님들이 원온원을 잘 진행할 수 있도록 돕는게 중요하다고 생각했음
내가 인지하는 원온원 프레임워크를 만들어도, 이 내용을 팀장님들에게 잘 전이하는 것이 중요함
그러나 과거 경험이 다 다르기 때문에 어떻게 해야할지 고민함
- 나만의 프레임워크를 정리하면서, 일단 팀장님과 리더십 원온원을 진행함
- 팀장님의 원온원 면담이나 팀장 역할을 하면서 하는 고민들에 대해 이야기를 나눔
- 그러면서 팀장님의 리더십을 개발할 수 있도록 도움
이 부분에 대한 것은 경영진분들과 컨설팅, 코칭을 할 때 필요한 것을 느낌

경험담

팀장님의 경험담을 잘 정리하고, 팀장님마다 고유한 리더십 역량을 개발하도록 도움
- 앞서 팀장님도 과거 원온원을 통해 개인에 대한 이해를 서로 진행한 경우가 많아 이 부분이 수월하게 진행되었음
조직의 특성도 고려하는 것이 필요함
- 개발 조직과 데이터, AI 조직의 지향점이 다를 수 있고 데이터, AI 조직도 회사마다 다양할 수 있음
- 우리 조직의 특성을 충분히 고민하고 어떻게 이야기를 하는게 좋은지 작성하는게 필요함(대표적인 예시 : 우리가 정의하는 좋은 원온원은?)
원온원 프레임워크를 만드는 것도 중요하지만, 이 프레임워크가 왜 만들어졌는지까지 인지하게 하는 것이 중요함
- 그 과정에서 팀장 워크샵 등을 진행하는 것이 필요하고, 어떻게 이 내용을 잘 전이할까?가 더 중요한 요소라 생각함
이 때 커리어 프레임워크을 보면서 참고함. 원온원 프레임워크와 다르지만 커리어 프레임워크처럼 기대하는 부분을 명확히 하면 좋을까?란 생각을 했음
- 드랍박스의 커리어 프레임워크
이 부분에 대해서는 아직 계속 진행하는 중. 정확히 이런 프레임워크를 개발하는 것과 그것을 잘 운영하는 것은 또 별개라고 생각함. 문화적인 부분도 뒷받침이 되어야 하고, 회사에서 이런 활동의 중요성을 인지하는 것도 중요함
- 이런 부분에 대해 이야기를 같이 하실 분이 있다면 이야기 나눠보고 싶네요

그 이후

Lv 4. 이후엔 무엇이 있을까?란 생각을 해봤는데, Lv 5는 조직을 넘어서서 내가 속한 산업에서 사람들이 원온원을 잘 진행할 수 있게 돕는 것이란 생각했음
- 이 과정엔 책을 쓰는 것도 있고, 글을 쓰는 것도 있고 다양할 것 같음
그러나 Lv 2~4도 매우 어렵기 때문에 앞선 부분에 대해 역량 상승에 집중하는 것이 필요하다고 생각함

원온원 실천을 위한 구체적인 가이드

원온원 프로세스 : 어떤 흐름으로 대화하면 좋을까?

이 프로세스는 제가 여러번 진행하면서 정해진 흐름입니다. 정답은 아니고 저의 흐름이라고 생각해주시면 됩니다
체크인(5~10분) : 요즘 어떻게 지내는가? 요즘 기분이나 상태를 점수로 표현하면?
- 점수가 상승한 이유, 하락한 이유는?
대화(40분)
- 오늘 다루고 싶은 소재가 있는지 질문
  - 팀원이 이야기를 하고 싶어하는 소재로 진행
- 바로 답변을 주는 것보단 왜 그런지, 어떤 감정이였는지 등을 주로 물어봄
마무리(10분)
- 오늘 어떠했는지? 물어봄
- Action Item 정하기 : 다음 원온원 주기까지 할 일 딱 1개만 정해보기. 여러개 정하는 것보다 1개만 하는 것이 좋다고 생각함
오늘 소감 작성 요청
- 이 부분은 선택적으로 진행하는데, 특정 슬랙 채널에 오늘 대화해서 어떤 것을 느꼈고 어떤 배움이 있었는지 공유 요청함 -> 다른 분들에게도 영감을 줄 수 있음
- 원온원을 하다보면 비슷한 고민을 하는 경우가 있어서 이 내용이 계속 살아있길 바랬음. 본인이 공개하고 싶은 수준으로 정리해서(개인의 이야기는 줄이고 깨달음 위주로) 채널에 공유하면 도움이 되었음
- 이렇게 해서 원온원의 가치를 계속 인지할 수 있게 되었음
  - 사람들이 어떻게 느끼는지 명시적으로 공유해서 원온원의 효과를 인지하고, 서로에게 도움을 줄 수 있는 환경 마련
원온원을 진행하는 회차에 따라서 내용을 다르게 전개함
- 1회차 땐 서로에 대한 이해
- 2회차 땐 회사에 잘 적응하고 있는지
- 그 후엔 팀원분이 하고 싶은 소재 위주

원온원 템플릿

개인 정보(메타 정보) 기록 : 서로에 대해 잘 이해하기 위함
노션을 사용해서 기록도 해보고, 구글 독스로도 해봄. 길어질수록 보기 편한 것은 스프레드시트라서 스프레드시트를 사용 중
면담 템플릿은 간단하게 유지하고, 특정 시점에 하고 싶은 질문이 있다면 추가하거나 팀원이 이야기하고 싶은 소재를 위주로 전개함
- 생각보다 간단하게 유지함

그 외 원온원 관련 생각과 TIP

원온원 주기는 2주에 1번도 가능하고, 1달에 1번도 가능함
- 시간도 30분, 1시간 등 다양함
- 정답은 없고 여러번 반복하면서 최적화하는 관점이 필요함
- 2주는 정말 빠르게 온다고 생각해서 1달을 선택했고, 저는 30분보단 60분은 되어야 충분히 대화를 진행해서 60분으로 진행함
  - 대화를 잘 하는 분들은 30분만에 모든 것을 진행할 수 있다고 하는데 저는 저만의 스타일로 60분을 선택
조직에서 겸직으로 인해 원온원을 동시에 다른 사람에게 받는 분이 있을 수 있는데, 이럴 땐 시기를 조절하려고 함. 비슷한 시기에 원온원을 하는 것보단 간격을 두고 하는 것이 좋다고 생각했음
대화 과정에서 정답을 만들지 말기
- 가치 판단을 하는 순간 대화가 어려워질 수 있음. 가치 판단보다는 중립적인 생각을 가지며 팀원에게 관심을 갖기(왜 그렇게 생각하셨나요?)
- 누군가가 이럴 때 그럴 수 있다, 그 사람의 맥락은 무엇인가? 물어봐야 함
- 때론 그냥 기다리는 것도 방법. 너무 빠르게 답변을 하라고 하면 압박이 생길 수 있음. 기다리는 시간도 필요하다고 생각하기(답답해서 다른 질문으로 넘어가지 말고 팀원의 템포를 기다려주기)
너무 성장 지향적으로 이야기하는 것이 아닌 여러 관점이 있다고 이야기하기
- 너무 성장 성장!하는 것보단 사람마다 시기가 있고, 템포가 있으니 그렇게 가도 괜찮다고 말하는 것이 좋았음
- 너무 성장을 이야기하면 성장을 강요하게 되는 느낌도 들었음
원온원을 어떻게 진행하고 있는지 회고하는 것도 추천
- 주기적으로 내가 어떻게 하는가, 내게 원온원을 받은 분들이 어떻게 살아가는가? 고민해보기
나의 원온원 스타일 파악하기
- 처음엔 일반적인 원온원 스타일로 탐색했다가 점점 나만의 방식을 찾기
- 내가 어떤 사람과 이야기를 할 때 좋은가? 고민해보기
- 더 나아가서 도식화를 해도 좋음
- 저는 어떤 대화를 할 때, 수렴을 잘 하는 스타일. 발산을 잘하는 분이 계시다면 내가 수렴을 해서 정리해줌
너무 형식에 얽매이지 말고 유연하게 대응하기. 대화를 하다가 갑자기 더 중요하다고 생각나는 것이 있다고 하면 그 주제에 대해 다루기
- 어떻게 보면 메타몽처럼 상대방에 맞게 변신해서 대응하는 것
어떤 내용에 대해서 내가 해결할 수 있는 것이 없는 경우가 있음(조직적인 구조로 인해)
- 이런 경우가 반복된다면 그 내용을 정리해서 상급자에게 전달하는 것도 중간 관리자의 중요한 역할이라 생각함
- 문제를 그냥 방치하지 말고, 어떻게든 해결하기 위한 시도를 작게라도 해보기

정리

원온원에 정답이 있다기보단, 나의 스타일을 파악하고 팀원분의 이야기를 잘 들어주면서 그 사람을 잘 돕는 것이 핵심이라 생각함
처음엔 어렵지만, 원온원에 대해 계속 생각하면서 발전하면 된다고 생각
처음엔 누구나 원온원이 어려움
저도 계속 경험하면서 저만의 기준이 생기고 있는 것. 시간이 지나면서 위에 작성한 내용이 다 달라질 수도 있음

참고 자료

김창준님, 변신철님이 주관해주신 MITI 동기 면담 워크샵
- 후기 : MITI 워크샵 후기
- 저는 김창준님, 변신철님이 운영하시는 AC2 과정을 수강하고 많은 깨달음을 얻었습니다. 그냥 경험하고 있던 것들을 잘 정리할 수 있는 계기가 되었습니다. 관심이 있으신 분들은 과정 살펴보시는 것도 추천해요
리더의 돕는 법
Trust and Betrayal in the Workplace: Building Effective Relationships in Your Organization 책
신뢰의 속도 책
백종화님의 원온원 책
상자 밖에 있는 사람 책
Guide to 1 on 1s
1 on 1 Questions
One on Ones

글 작성하는데 걸린 시간 : 7시간 3분
- 하고자 하는 이야기, 개요 정리 : 38분
- 초안 글 작성 : 1시간 35분
- 클로드와 셀프 글 피드백 : 40분
- 2차 글 작성 : 4시간 10분
회고
- 처음에 목차를 생각하지 않고 경험을 다 작성하니 너무 구조화가 되지 않아 방향성을 잡기 어려웠음
- 클로드와 피드백을 하면서 더 괜찮은 목차를 만들며 내용을 재구성함
- 필요한 내용 위주로 남기고, 삭제에 집중함
- Action Item
  - 역시 처음부터 목차를 작성하는게 좋음
  - 작성하고 싶은 모든 내용에 집중하지 말고 핵심 위주로 정리하기

경력이 쌓이면서 했던 고민들과 깨달은 것들

Fri, 08 Nov 2024 00:00:00 +0000

이 글은 경력이 쌓이면서 했던 고민들과 깨달은 내용에 대해 작성한 글입니다
멘토링 때 종종 이 주제들에 대한 질문을 받아 글을 작성해봅니다
키워드 : 경력, 커리어, 개발자 커리어, 성장

살다 보면 우리는 고민이 생긴다

회사에 다니기 전에는 취업 자체에 대한 고민만 했다. 이 시기엔 취업이 되느냐, 어떤 회사에 가느냐 등을 집중적으로 고민했던 것 같음
그러나 회사에 가면, 새로운 문제들이 생기기 시작함
- 회사에서 어떻게 일을 할 것인가?
- 어떻게 인정받을 수 있을까?
- 사람들과 어떻게 지내야 할까?
- 앞으로의 커리어는 어떻게 될까?
- 갑자기 어떤 일도 하기 싫은 번아웃이 온다면 어떻게 해야 할까?
- 내가 회사에서 일을 잘하는지 확인하려면?
위 사례 외에도 굉장히 다양한 종류의 고민들이 생길 수 있고, 멘토링을 할 때 자주 나오는 주제들이다
자주 나오는 질문이나 했던 생각들을 정리하려고 한다
자세한 이야기를 하기 전에, 이런 고민을 하는 것 자체가 문제가 아니고 내가 발전하려는 향상심이 있기에 생기는 현상이라고 생각
- 이런 생각이 드는 것이 당연하니 너무 걱정하지 않으셨으면 좋겠어요
- 이 글의 내용은 제 생각이 맞다는 관점이 아닌, 제가 어떻게 생각했는지를 담은 글입니다. 보시고 다른 생각이 드시면 ‘글쓴이는 이렇게 생각했구나’ 이렇게 생각해 주시면 좋을 것 같아요

1) 좋은 커리어란 무엇일까? 앞으로 어떻게 발전해야 할까?

생각하게 된 배경
- 대략 2-3년 차에 많이 생각하는 주제(그러나 그 이후에도 이 고민은 계속된다. 답은 없고, 환경이 변하기 때문. 연차가 쌓이면 새로운 환경에 가고 새로운 의사 결정을 하게 될 수 있음)
- 입사하고 초반엔 새로운 일들이 많아서 해당 내용들을 습득하고, 주어진 일을 하나씩 하면서 정신없이 보냄
  - 그러다가 1, 2년이 지나고 일이 익숙해질 때쯤 커리어에 대해 고민함
- 이런 고민을 하게 된 배경은 다양하게 존재할 수 있는데, 업무가 지루하다고 생각하거나, 스스로가 생각하는 이 직무가 해야 하는 일이 정의되어 있지만 그걸 안하 고 있어서 고민하는 경우도 있음
- 아마 일이 즐겁고, 보람차고 프로젝트를 잘 진행하고 있다면 이런 고민은 하지 않을 가능성이 존재
- 컨퍼런스에서 발표를 보거나, 외부 요소(취업 시장이 어렵다는 이야기), 친구들과의 비교 등을 통해 이런 고민을 하게 될 수도 있음
제 생각
- 이 직무를 왜 시작하게 되었는지가 중요하고, 나에 대한 인지(메타인지)가 있으면 더 깊은 고민을 할 수 있음
  - 내가 이 직무를 왜 하고 싶었는지, 초심은 무엇이었는지 등
  - 내가 처음 원했던 방향을 계속 고수해야 한다는 생각은 아니고, 내가 최초의 방향을 잘 생각하고 있는지 고민하며, 그 이후 자신의 경험을 얹어서 새로운 길로 가야 할지 정리하는 것도 괜찮음
- 살다 보면 초심을 잊고 살아가는 경우가 많고, 초심에 대한 내용을 블로그 등에 작성하고 지속적으로 보는 것도 좋다고 생각함
- 좋은 커리어의 기준은 누가 정해주는 것이 아니라 스스로가 정의해야 함
  - 다른 사람이 좋다는 A라는 기준이 나중에 시간이 흐르면 다르게 될 수도 있음. 과거의 시기와 요즘은 또 다르게 생각할 수도 있음
  - 학생이나 신입은 경험이 없어서 기준이 적을 수 있고, 이럴 땐 다른 사람의 의견을 들어보기도 하는 것도 다 한 번쯤 경험함
    - 그러나 나의 경험을 늘리면서 나만의 생각, 기준을 만들게 됨
  - 일반적으로 많이 나오는 연봉, 워라밸, 동료 등도 중요할 수 있지만 나의 근본적인 욕구나 이 직무를 선택한 이유에 따라 다를 수 있음
    - 인정 욕구가 큰 사람에겐 워라밸보단 내 인정이 더 중요할 수 있음. 인정받기 위해 회사에서 성과를 높이려고 하고, 열심히 일하는 것이 즐거울 수 있음
- 제가 생각하는 좋은 커리어는 “직무 하나에 나를 한정하지 말고 여러 경험을 하는 것. 문제 해결에 집중하는 것. 꾸준하게 계속 무언가를 시도하는 것”
  - 여러 경험을 하다 보면 하고 싶지 않은 일을 할 수도 있지만, 그런 일도 경험으로 생각하는 편
  - 다른 사람들이 하지 않았던 여러 경험들이 합쳐지면 나만의 고유한 영역이 될 수 있다. 제너럴한 영역을 여러 개가 있고, 각 영역을 아주 잘하면 그게 또 새로운 스페셜이 될 수 있다고 생각함
  - 직무 관점에서도 MLOps나 Analytics Engineer가 하나의 직무에서 시작된 것이 아닌 다른 직무에서 확장되면서 생기는 직무라고 볼 수 있는데, 이와 유사하다고 생각
- 저도 고민했던 시기가 있었음. 레트리카에서 데이터 분석가, 데이터 엔지니어 일을 조금씩 했었고 쏘카에선 데이터 분석가, 데이터 과학자, 머신러닝 엔지니어, 데이터 엔지니어, Engineering Manager 등을 경험했는데 너무 여러 가지를 경험해서 고민되기도 했지만 회사에서 요구하는 나의 역할을 최대한 잘 수행해 보자고 생각함
  - 여러 경험을 했기에 직무의 협업 구조를 알 수 있고, 어떻게 프로젝트를 시작해야 할지, 사업부에선 어떤 관점으로 생각하는지 등을 모두 이해하게 됨
  - 조직을 키우는 경험도 해보면서, 조직의 규모에 따라 어떤 방식으로 운영해야 할지에 대해 고민을 할 수 있게 되었음
- 때론 지금 하는 행동들에 너무 의지를 부여하지 않아도 괜찮았음. 시간이 지나서 그 의미를 찾는 경우도 있었음
  - 의미를 너무 찾다가 시간이 지나갈 수도 있다는 이야기. 과거에 했던 것을 생각해보니 의미를 찾은 경우도 있기에 너무 의미를 찾는데 오래 걸린다면 잠시 실행해보는 것도 좋은 방법이라 생각(의미와 실행의 적절한 밸런스가 중요하다고 생각)
- 좋은 커리어의 기준은 시간의 흐름에 따라 다를 수 있다. 내가 어떤 결정을 할지 기준을 가지고 있는지가 더 중요할 수 있음
- 저는 연차별로 성장의 정의가 다 달랐음. 1-2년 차의 성장은 나의 성장, 3-6년차의 성장은 팀과 조직의 성장, 그 이후의 성장은 잘 회복하며 지금 현상 유지하기가 성장이였음. 지금의 성장도 다른 방향으로 가는 중
- 정리하면 좋은 커리어의 정의는 내가 하는 것이고, 타인이 정해주지 않음. 나에 대해 생각을 해보고 나의 기준을 만드는 것을 추천함. 또한 시간의 흐름에 따라 성장은 달라질 수 있고 과거의 경험들이 갑자기 깨달음을 주는 경우도 있으니 걱정하지 말고 지금 순간을 잘 지내는 것을 추천함

2) 데이터 과학자, 데이터 분석가. 데이터 직무의 고민. 커리어를 어떻게 발전해야 할까?

생각하게 된 배경
- 데이터 과학자나 데이터 분석가는 직무의 구분이 명확하지 않아 많은 사람들이 혼란스러워함(저도 과거에 그랬고, 요즘 커리어를 준비하는 분들도 여전히 혼란스러워함)
  - 다양한 데이터 분석 직군 글을 보면 직무의 이름으로 판단하지 말고 실제 하는 일을 기반으로 판단하라고 작성했음
- 1번의 고민(좋은 커리어)와 연결되는 부분인데 데이터 직무는 데이터 분석가지만 하는 일이 회사마다 정말 다양함
  - 어떤 회사에선 데이터 엔지니어링을 하면서 인프라도 구축해야 하고,
  - 어떤 회사에선 대시보드 제작 위주로 진행되고
  - 어떤 회사에선 데이터 추출 요청 위주의 업무가 진행되기도 함
  - 위 상황과 더불어 데이터 관련 컨퍼런스에서 보면 다른 사람들은 멋진 업무 위주로 하는 것 같아서 자신과 업무를 비교하게 되는 경우도 존재
제 생각
- 이럴 때 현타가 오고 이직 준비를 할 수 있음
- 그러나 저는 데이터 관련 어떤 업무를 하더라도, 회사에서 필요한 업무라고 생각함. 다만 회사의 조직 규모의 차이가 있거나 데이터 문화의 차이가 존재할 뿐. 그 시기에 내가 다니고 있을 뿐이라 생각함
- 데이터 문화가 아직 잘 정착하지 못했다면 직접 데이터를 추출해서 제공해야 할 수 있고, 대시보드도 데이터 직무가 만들어야 할 수 있음
  - 이런 상황은 왜 만들어지고, 개선하려면 어떻게 해야 할까?를 고민하는 것도 좋다고 생각
  - 그럼 조직의 규모가 점점 커지면서 그 안에서 필요한 역할들이 무엇인지 알 수 있게 됨
  - 이 부분은 국가의 발전, 역사 공부를 하면서 어떻게 해야 더 좋은 조직의 구조를 갖출 수 있을까를 생각했음
- 이왕 업무를 진행할 때, 너무 부정적으로 생각하는 것보다 이 업무를 한국 또는 세상에서 제일 잘하려면 어떻게 해야 할지를 고민함
  - 단순 데이터 추출도 정말 빠르게 잘하려면? => 데이터를 잘 정리해 두는 것도 필요하고, 마트를 만드는 것도 필요하고, 쿼리를 실수 없이 작성하는 것도 필요
  - 하나의 Task도 더 구체적으로 쪼개보면 필요한 역량이 여러 가지고, 그것을 더 잘하도록 시도할 수 있음
  - 게임에서 하기 싫은 노가다 퀘스트를 하는 느낌일 수 있지만, 이런 퀘스트가 있어야 다음 퀘스트를 수월하게 진행할 수 있다고 생각함
- 다른 사람과 비교하는 순간 자존감이 떨어질 수 있음. 왜냐하면 비교 대상이 대부분 자신보다 더 좋은 상황인 사람과 비교하는 경우가 더 많기 때문
  - 컨퍼런스에서 발표하는 내용은 부정적인 것보단 긍정적인 것, 인사이트가 있는 것을 주로 발표할 수 있음. 그리고 그 발표가 그 사람의 전부가 아니라 특정 단면을 공유한 것일 수 있음
  - 다른 사람의 길이 아닌, 그냥 나의 길을 가보자고 생각하는 것을 추천
  - 내 이야기를 영화로 치면 지금 기승전결에서 중간에 있다고 생각하고, 어려운 상황이 나오면 역시 영화에 위기 한번 와야지! 이런 생각을 하곤 함
- LLM이 발전하면서 1인 생산성이 늘어나고, 단순한 데이터 추출은 LLM으로 대체하려는 시도가 엄청 많이 존재함. 조만간 SQL 작성은 데이터 직무의 일이 아닐 수 있을 것 같음
  - 대신 데이터 직무가 무엇을 해야 할까? 생각해 보면 사내의 컨설턴트 역할이 될 수도 있고, 데이터 문화를 만드는 역할, 의사 결정을 위주로 하는 역할 등 다양한 역할이 나올 수 있음
  - 그러나 미래에도 과거처럼 작은 규모에선 직접 쿼리를 작성하는 시기도 있을 수 있음. 그래서 너무 걱정하는 것보단, 지금 하는 일을 잘하게 되면 나중에 도움이 되지 않을까 싶음
- 커리어는 점진적으로 발전할 수 있으므로, 너무 조급하게 생각하지 말고 지금 할 수 있는 일부터 점진적으로 하는 것을 추천
- 저도 시간이 지나서 8년 차가 되었음. 그동안의 경험이 아직도 생생한데 시간이 참 빠름.
  - 커리어 초반, 학생 시절엔 ‘내가 될까?’에 집중했고 가능성이 있는지에 대한 질문을 많이 했음
  - 그러다가 경력을 쌓으면서 ‘내가 뭐가 될까’에 집중했음. 뭐가에 집중하면서 어떻게 해야 할까를 고민했음
  - 그러다가 요즘은 ‘내가 뭐든 되네’라는 생각을 함. 시간이 지나면 무엇이든 된다. 특정 시기에 내가 노력하지 않아도 회사의 업무를 하면서 경험이 쌓이고 있음. 혹은 내 개인 삶의 경험을 풍성하게 만들 수도 있는 것
    - 무엇이든 되니 너무 걱정하지 말고 지금 하고 싶은 것이 뭘까, 어떻게 시간을 보낼까를 고민하고 하나씩 해보는 것이 좋지 않을까 싶음
- 저는 ‘커리어의 목표가 무엇인가요?’라는 질문을 받으면 딱히 없고 그냥 오늘같이 하루하루 잘 보내는 것이 목표라고 말함. 장기적인 비전은 있으면 좋지만, 너무 큰 목표같이 느껴질 수 있어서 현실적인 오늘을 잘 살려고 함
- 직무 관점에서 너무 직무 하나에 매몰되지 말고, 내가 얼마나 회사에 기여할 수 있고 사람들에게 도움을 줄 수 있을지를 생각하며 이 기준이 확장될 수 있는 기준으로 일하고 있음
- 정리하면 어떤 일을 하더라도 회사에서 제일 잘하고, 세계에서 제일 잘하려면 어떻게 해야할까를 생각하면서 나의 길을 가려고 함. 좋은 커리어의 정의는 내가 하는 것이므로 내가 어떻게 하고 싶은지에 기반해서 하나씩 실행함. 직무에 한정되는 사람이 되지 말고 직무를 넘어서는 사람이 되려고 함

3) 좋은 선택, 의사 결정이란 무엇일까?

생각하게 된 배경
- 의사 결정이 중요하다는 것은 많이 듣는데 그걸 어떻게 잘하는가에 대해서는 배운 적이 적음. 그러다 보니 How를 고민하게 됨
- 멘토링 때도 종종 받는 질문으로 가장 중요한 순간의 선택, 후회하는 선택 등의 질문을 받음
  - 아마 좋은 의사 결정, 좋은 선택하는 방법을 물어보는 질문이었던 것 같음
- 의사 결정이 뭔가 한 번에 잘 돼야 할 것 같고, 틀리면 안 될 것 같은 고정 관념이 있었음
제 생각
- 일단 저는 과거의 선택에 크게 연연하지 않는 성격. 과거 성격을 만약 돌릴 수 있다면 생각을 계속할 것 같은데, 그게 아니니까 현실을 직시한다. 그래서 과거 이야기를 물어봐도 잘 떠오르진 않음
- 이렇게 된 계기를 생각해 보면 20대 중반부터 뭘 해도 잘 되는 경험이 없었음. 실패, 불합격 등이 많았는데 그게 너무 많아지니까 오히려 현실을 너무 낙관하지 않고 적절한 상태로 바라보곤 했다. 그러다가 니체 책을 보고 니체의 사상에 영감을 받음
- 우선 “좋은” 이란 부분에 대한 정의가 필요함. 좋다라는 것은 상황에 따라 다를 수 있고, 구체적으로 정의가 된다면 지표로 나올 수 있음. 다만 지표로 나오지 않는다고 하면 너무 “좋은”에 집중하지 않으려고 함
- 어떤 결정을 할 때, 들뜨지 않고 객관적으로 생각함
  - 만약 지표로 표시할 수 있다면 지표를 정의한다. 숫자로 특정 상황을 표시하고, 이게 더 좋아지면 간다 등
  - 이 숫자가 높아질 때, 낮아질 때 어떤 Action을 할지 생각한다. 이런 과정을 Mental Simulation이라 부름
    - 멘탈 시뮬레이션은 특정 행동을 하는 것을 상상하고, 행동하기 전에 예상되는 결과를 시뮬레이션하는 능력
    - 멘탈 시뮬레이션을 한다면 특정 순간의 지표가 좋지 않아도, 오르기 위해 어떤 것을 해야 할지 생각했으므로 다시 또 실행하면 됨
  - 과거에 아쉬움이 있다면, 한 번 더 시도해서 아쉬움을 타파하면 그만이 아닐까 생각
  - 한 번에 잘 되었던 적이 없어서 이 생각을 기본적으로 가지고 있는 것 같음
- 어떤 경험을 하고, 주기적으로 회고를 하면서 고민한다. 이 순간에 내가 왜 이 선택을 했지? 이때 뭐가 중요하다고 생각했지?
  - 그 당시 기록이 있다면 그 기록을 보면서 다음엔 어떻게 해볼까를 고민한다
- 의사 결정 자체에 집중하는 것보다, 의사 결정을 대하는 태도나 의사 결정을 하는 과정에 신경을 쓰게 됨
- PM을 위한 데이터 리터러시 강의에 의사 결정 파트가 있는데, 그때 의사 결정 TIP을 다음과 같이 공유했음
  - (1) 답을 내린다는 표현 대신 베팅한다는 표현하기 : 답을 내린다는 것은 너무 부담이 생김
  - (2) 에너지 레벨 고려하기 : 결정을 내리는 과정은 에너지를 많이 소모한다. 에너지를 덜 소모하며 결정할 방법을 고민함(같이 진행하기 등)
  - (3) 당연한 것은 없다 : 당연하다고 생각하지 말고 항상 다시 고민해 보기
  - (4) 개인적인 의사 결정에선 과감히 도전하는 것도 방법 : 회사에서 결정하는 것은 보수적으로 갈 수 있지만, 개인 관점에선 개방적으로 해보는 것도 방법. 이런 시도가 나의 안전지대(Comfort Zone)를 넘어설 수 있게 됨
  - (5) 결정했으면 그 결정이 좋은 결과를 내도록 노력하기 : 결정하고 아무것도 안 하는 것이 아닌 그게 되도록 하는 것이 중요함
  - (6) 사람은 결정으로 인한 실패를 피하고 싶은 성향이 있다 : 결과에 대해 받아들이고, 어떻게 개선할지 생각해 보는 것이 더 중요한 것 같다
  - (7) 큰 결정은 누구나 어렵다. 작은 결정부터 하나씩 : 작은 결정에서 점점 큰 결정으로 가자. 대표님들은 어떻게 결정하고 있는지 살펴보고 간접적으로 나라면? 생각해 보거나 대표님들이 어떤 결정을 어떤 흐름으로 했는지 물어보는 것도 방법
- 의사 결정, 선택에 대한 원칙을 만들었다.
  - 대표적인 원칙은 “만약 내일 내가 죽는데, 어떤 일을 하지 않아서 무덤 속에서 뛰쳐나올 것 같다면 지금 하자”
    - 무덤 속에서 뛰쳐나올 것 같다고 하면 너무 답답해서 해야 할 것으로 생각한다. 그래서 “이거 무덤에서 뛰쳐나올 정도인가?”를 생각하는 편
  - 좋은 결정보단, 상황에서 적절한 결정만 존재한다고 생각함. 그리고 결정하고 그 후의 실행이 중요하다
  - 이런 결정 원칙을 여러 개 만들고 주기적으로 수정하면 된다
  - 또 다른 저의 원칙은 데이터 과학자 원칙에 작성되어 있음. 목차를 공유해 드리면
    - 의도적으로 남다른 선택해보기
    - 주기적으로 일하는 목적 찾기
    - 제너럴리스트, 스페셜리스트 이분법으로 생각하지 않기
    - 업무도 메타인지하며 목적 중심으로 생각하기
    - 나의 세상 정의하기
    - 회사에서 필요한 일과 내 흥미를 일치시키기
    - 팀 현황을 파악해서 개선점 만들기
    - 더 나은 커뮤니케이션 능력 기르기
    - 비즈니스 모델과 데이터의 접점 분석하기
    - 지금 힘들다면 여유가 있는지 생각해보기
- 정리하면 좋은 의사 결정에 집중하는 것이 아닌 현재 상황이 어떤지, 지표로 표시해보고, 앞으로 뭘 해야할지 멘탈 시뮬레이션을 한 후에 결정한다. 결정을 한 후엔, 결정이 잘 될 수 있도록 노력함
  - 순간 순간엔 좋지 않다고 판단할 수 있지만, 시간이 지나면서 경험이 쌓이면 그런 경험들이 좋은 순간이 될 수 있음
  - 그래서 이 결정이 좋은가에 대해 생각하지 않게 된 것 같음. 그냥 내게 있는 정보를 가지고 최선의 수를 두고, 계속 고민할 뿐

4) 번아웃이 오면 어떻게 해야 할까?

생각하게 된 배경
- 요즘 너무 번아웃이 심하거나 힘든 경우 이런 고민을 하게 된다
제 생각
- 살다 보면 또 번아웃이 올 수 있다. 물론 회사에서 번아웃이 안 오는 사람들도 있고, 적당히 잘 유지하는 사람들도 있다. 어떤 경우엔 번아웃이었는데 시간이 지나고 깨닫는 경우도 있음
- 번아웃은 열심히 한 사람이 온다고 생각한다
  - 일단 번아웃을 인정하기
  - 번아웃을 나쁘게 생각하지 말고 긍정적으로 승화하기
  - 잘 하고 있고, 잘 하다가 에너지가 부족해서 번아웃이 된 것. 에너지만 잘 채우면 된다
- 번아웃 원인 분석하기
  - 번아웃이 왜 오게 되었는가를 생각함
  - 회사의 일이 많아서 그럴 수도 있고, 개인 약속이 너무 많아서 그럴 수도 있고, 제대로 쉬지 못해서, 다른 사람들은 잘 하는데 내가 상대적으로 뒤처진다고 생각해서 등 다양한 이유가 있음
  - 여러 이유가 있을 수 있는데, 그 이유를 천천히 보면서 어떤 요인이 나를 이렇게 만들었는지 살펴본다. 과거의 경험과 비슷하면 그 요소가 내게 더 영향을 미칠 수 있다고 생각한다
- 번아웃을 겪을 때 기록을 자주 해놓고, 번아웃에 대해 한판 정리를 했음
  - 나만의 번아웃 패턴을 통해 어떻게 해야 해소할 수 있는지도 알 수 있게 되었음
  - 인스타그램에 번아웃에 빠졌을 때 번아웃을 극복하는 10가지 방법이란 글을 작성했음

번아웃과 관련되는 것이 잘 쉬는 것
- 잘 쉬어야 번아웃도 안 온다고 생각함
- 그래서 나만의 쉼 전략에 대해서도 고민했음. 잘 쉬는 법에 대한 고찰
- 내가 언제 어떤 환경에 있어야 잘 쉰다고 생각하는지, 에너지가 채워지는지 등을 보고 정리함
- 이런 것들이 정리되니까 내가 에너지가 없으면 바로 그 행동을 하면 됨
- 청소하기 : 5 회복, 해외여행 가기 : 50 회복 등 이렇게 나만의 숫자를 채워봤다(숫자는 나중에 바뀔 수 있음)
너무 힘든 경우엔 아무것도 안 해도 괜찮음. 그런 시기도 충분히 있을 수 있고, 잘 회복에 집중해야 함
- IT 업계에 있으면서 성장 지향적으로 살아야 한다는 말을 많이 듣는다. 나도 그렇게 살아왔는데, 어느 순간 너무 성장 성장!보다 나만의 삶을 정의하고 그런 삶을 형성하면 된다고 생각했다
- 이런 삶을 형성하는 과정에선 직무 관점에서 발전을 덜 할 수도 있음. 그러나 이게 문제는 아니라고 생각함
- 힘들 땐 잘 회복하는 것도 중요함. 회복하는 시기엔 회복에 집중하는 것을 추천
- 저 또한 6~7년 차 시절에, 회복에 집중했던 시기가 있음. 성장이란 것은 누적치라 생각해서 그냥 버티기만 해도 유지될 수 있어서 괜찮다고 생각함
정리하면 번아웃의 원인을 분석해보고, 나의 번아웃 경험을 한판 정리한 후 앞으로 어떻게 번아웃에 빠질 수 있을지 도식을 그림. 또한 어떻게 쉬어야 할지에 대해서도 같이 생각함

그 외에 자주 나오는 고민, 질문

여러분들은 경력을 쌓으면서 어떤 고민을 하고 계신가요? 고민들도 궁금하네요
또 자주 나오는 질문들은 다음과 같음. 다음에 시간이 될 때 아래 내용으로 글을 작성해보려고 함
- 혹 다른 질문이 있다면 댓글 남겨주시면 참고해서 글을 작성해 볼게요
추가로 자주 받는 질문들
- 제가 잘하고 있는지 확인하려면 어떻게 해야 할까요?
- 시간 관리는 어떻게 해야 할까요?
- 새로운 트렌드는 어떻게 따라가야 할까요?
- 기술을 추구하는게 맞을까요? 어떤 기술을 공부해야 할까요?
- 이직은 언제 해야 할까요?
- 전 물경력인 것 같아요

정리

위에 나온 것은 모두 제 생각이고 정답은 아니라고 생각함. 사람마다 다르게 생각할 수 있는 주제
제 이야기의 핵심은 나에 대해 인지(메타인지)하기, 나의 목표(비전) 정해보기, 계속 시도하기, 나만의 원칙 만들기

글 작성하는데 걸린 시간 : 75분
- 하고자 하는 이야기, 개요 정리 : 8분
- 초안 글 작성 : 52분
- 클로드/Cursor와 셀프 글 피드백 : 5분
- 2차 글 작성 : 10분

DuckDB 사용법(DuckDB Python + Jupyter Lab)

Fri, 25 Oct 2024 00:00:00 +0000

이 글은 DuckDB 사용법을 작성한 글입니다
예상 독자
- DuckDB가 궁금하신 분
- 데이터 분석가 : Pandas가 느리다고 생각해서 다른 대안을 찾고 있는 분
- 데이터 엔지니어 : 데이터 엔지니어링의 Transform 영역에서 활용할 수 있는 수단을 찾고 있는 분. 작은 규모의 회사에서 데이터 웨어하우스를 고민하고 있는 분
키워드 : Duckdb 사용법, Duckdb 설치, Duckdb Python

DuckDB 소개, DuckDB란?

Github Repo
DuckDB는 fast in-process Analytical Database
왜 Duck인가?
- Duck(오리)은 날 수도 있고, 수영도 하고, 걷는 놀라운 동물. 환경에 유연함
- 다재다능하고 탄력적인 데이터 관리 시스템을 만들고 싶었는데, 이런 시스템이 오리와 유사하다고 생각해서 DuckDB라고 이름을 지음
C++로 작성되었고, Column-oriented 데이터베이스로 매우 빠름
Parquet, CSV, JSON 파일에 직접 쿼리할 수 있음
- AWS S3, GCS, Azure Blob Storage 등에서도 쿼리할 수 있음
- S3 Iceberg도 지원
사용하기 쉬움
로컬 Data Warehouse(나만을 위한 DW)라고 생각해도 될 듯
Portable Python Dataframe 라이브러리라고 나온 ibis의 백엔드 엔진이 DuckDB
공식 Docker 이미지가 존재하지 않음
- 애플리케이션에서 DuckDB를 동시에 실행하려고 함. 별도의 컨테이너화를 하지 않아도 됨
- 웹페이지, 앱 등에서 그냥 DuckDB를 설치해서 사용하면 됨
DuckDB 기반 관리형 서비스 : MotherDuck
Live Demo를 보고 싶다면 DuckDB Live Demo에서 확인할 수 있음

BIG DATA IS DEAD

Google Cloud의 BigQuery를 만든 멤버 중 한 명인 Jordan Tigani가 2023년 2월에 올린 BIG DATA IS DEAD라는 글을 보다가 MotherDuck을 알게 되고, DuckDB를 알게 되었음
BIG DATA IS DEAD 글의 핵심은 다음과 같음
- 대부분의 기업은 “빅데이터”를 가지고 있지 않음
  - BigQuery 사용자 대부분은 1TB 미만의 데이터를 보유
  - 일반적인 기업의 데이터 웨어하우스 크기는 100GB가 일반적임
  - 특정 VC의 포트폴리오 회사 중 제일 큰 B2B 기업은 약 1TB, 제일 큰 B2C 기업은 약 10TB를 가지고 있었음. 그러나 대부분 이것보다 적은 데이터를 가짐
- 데이터를 쿼리하는 패턴
  - 시간이 지나면서 데이터는 많아지지만, 컴퓨팅 리소스는 거의 변하지 않음
  - 1년에 1,000달러 이상을 지출하는 고객을 살펴보니, 쿼리의 90%가 100MB 미만의 데이터를 처리함
  - 데이터가 많은 고객도 많은 양의 데이터를 쿼리하지 않음
  - 최근 24시간 내의 데이터가 가장 자주 활용
  - 오래 된 데이터는 사용되지 않음
- 싱글 머신의 성능 향상
  - 요즘 AWS의 표준 인스턴스는 64 Core, 256GB RAM 서버
    - 2006년에 AWS에서 EC2를 처음 출시할 땐 싱글 코어에 2GB RAM 서버였음
  - 예전엔 대형 서버가 비쌌으나, 요즘엔 저렴해짐
  - 과거에 분산 처리가 필요했던 작업들이 싱글 머신에서 처리될 수 있음
- 데이터는 자산이 아닌 부채일 수 있음
  - 사람들이 빅데이터를 가지게 되는 이유는 필요해서가 아닌 단순히 삭제하는 것을 귀찮아해서
  - 같은 쿼리만 반복적으로 한다면 집계된 데이터만 저장하는 게 좋을 수 있음
  - 언젠가 쓸지 모른다는 생각으로 보관할 수 있음
- 빅데이터의 1%인지 확인할 수 있는 질문
  - 정말 엄청난 양의 데이터를 생성하고 있는가?
  - 그렇다면 정말 한 번에 그 많은 데이터를 사용할 필요가 있는가?
  - 그렇다면 그 데이터가 정말 1대의 컴퓨터에 담기에 큰가?
  - 그렇다면 당신이 단순히 데이터를 쌓아두기만 하는 사람이 아닌지 확실할 수 있는가?
  - 그렇다면 데이터를 요약해서 보관하는 것이 더 나은 방법이 아닐까?
  - 하나라도 아니요라고 답하면 데이터 규모에 맞는 새로운 데이터 도구를 사용하는 것이 좋을 수 있음
위와 같은 내용 때문에 복잡한 분산 시스템 대신 단순하고 효율적인 솔루션이 필요하다고 함
BIG DATA IS DEAD엔 직접적으로 나오지 않지만, DuckDB가 이런 상황에 적절한 도구라는 것을 알 수 있음
시간이 지나면서 점점 싱글 머신이 확장되어 분산 처리까지 갈 필요가 없다는 의미 => DuckDB는 이 용도에 적합

DuckDB 목표 & DuckDB 장점

세상에 다양한 DB가 있는데, 모든 상황에 적합한 데이터베이스는 없음. 특정 사용 사례에 따라 더 잘 맞도록 설계됨
다음은 DuckDB의 목표 및 장점

1. Simple

SQLite처럼 설치하고 사용하기 쉬워야 함
외부 종속성 없이 동작하고, 별도의 서버 설치나 관리가 필요 없음
DuckDB는 별도의 프로세스로 실행되지 않고 호스트 프로세스에서 실행됨

2. Portable

모든 OS에서 동작해야 함 (Windows, MacOS, Linux)
다양한 CPU 아키텍처(x86, ARM) 지원
소형 디바이스, 웹 브라우저, 모바일에서도 실행 가능(DuckDB-Wasm 사용)
Java, C, C++, Go, Node.js, Python 등 다양한 API 제공

3. Feature Rich

데이터 분석을 위한 복잡한 쿼리를 지원(윈도우 함수)
커스텀한 MVCC(Multi-Version Concurrency Control)를 통해 ACID 트랜잭션을 보장한다고 주장
- MVCC : 데이터베이스에서 여러 버전의 데이터를 동시에 관리. 수정할 때마다 새 버전 생성
- HyPer의 serializable variant MVCC 방식을 구현
쿼리의 속도를 높이기 위한 보조 인덱스를 지원
Python, R과 통합

4. Fast

OLAP 쿼리 워크로드를 지원
전체 테이블에 대한 집계, 큰 테이블의 JOIN 등을 빠르게 처리
개별 값당 소모되는 CPU 사이클의 양을 줄이는 것이 중요하고, 이를 위해 just-in-time 쿼리 실행 엔진, Vectorized(벡터화된) 쿼리 실행 엔진을 사용
TPC-H, TPC-DS 벤치마크로 테스트
- TPC-H : Decision Support Benchmark, 공급망/구매 데이터로 구성된 비즈니스 의사결정 시나리오
- TPC-DS : Data Warehouse Benchmark, 온라인 쇼핑 데이터로 구성된 데이터 웨어하우스 시나리오
- 확인하는 것들 : 쿼리 응답 시간, 처리량, 사용자가 많을 때의 처리량, 데이터 크기별 성능

5. Extensible

유연한 확장 메커니즘을 제공
- 새로운 데이터 타입, 함수, 파일 포맷 등을 정의할 수 있음
Community Extensions은 공식 문서에서 확인할 수 있으며, Github Repo도 운영
- DuckDB Community Extensions 문서에 디자인 철학, 확장 기능 사용에 대한 내용을 확인할 수 있음

6. Free

DuckDB의 개발자들은 네덜란드 공무원일 때 개발을 시작
누구나 자유롭게 제공하는 것을 사회에 대한 책임과 의무로 봄
따라서 MIT 라이선스를 채택

7. Thorough Testing

최초엔 Research 그룹에서 만들었지만, 안정적인 데이터베이스 시스템이 되는 것을 목표로 함
여러 플랫폼과 컴파일러에서 반복적으로 테스트
Github Actions을 보면 여러 테스트가 돌아가고 있는 것을 확인할 수 있음

DuckDB 성능 벤치마크

벤치마크가 기록된 문서가 있나 찾아보니, 다음 2개의 글을 확인함
- The Return of the H2O.ai Database-like Ops Benchmark
- Updates to the H2O.ai db-benchmark!
DuckDB에서 공개한 문서 Database-like ops benchmark를 보면 GROUP BY, JOIN 성능 결과를 확인할 수 있음
- 아래 이미지는 위 링크에서 일부를 가져옴. 링크에 더 자세한 내용을 확인할 수 있음
- 벤치마크 결과 다른 도구보다 성능이 좋고, 사용해봤을 때 오? 라는 생각이 들 정도로 빠름

Benchmarking Ourselves over Time at DuckDB 이 글도 확인해보니, 시간의 흐름에 따라 DuckDB가 더욱 빨라지고 있는 내용을 담고 있었음. 2023년 말에 급격한 성능 향상이 존재
- 최근 3년 동안 3~25배 빨라지고, 10배 많은 데이터를 분석할 수 있게 됨

Pandas보단 확실히 빠르고, Rust로 만들어진 Polars와 많이 비교됨
- DuckDB와 Polars, Pandas를 비교한 Repo : 이 결과에서도 DuckDB가 더 빠르다고 나옴
- 회사에 도입하려고 하면 우리 데이터로 테스트를 충분히 하고 선택할 것. 벤치마크 결과를 항상 신뢰하는 것보다, 다시 점검하는 것이 필요

DuckDB 설치

공식 문서에 내용을 확인할 수 있음
Mac OS 기준
```
brew install duckdb
```
윈도우
```
winget install DuckDB.cli
```

Linux : 최신 버전은 Github에서 확인

wget https://github.com/duckdb/duckdb/releases/download/v1.1.2/duckdb_cli-linux-aarch64.zip

unzip duckdb_cli-linux-aarch64.zip

./duckdb

DuckDB 실행하기

CLI에서 실행은 간단함
```
duckdb
```

데이터 분석가 관점에서 DuckDB를 사용한다면 Jupyter Lab을 사용할 텐데, brew로 설치하면 파이썬 패키지도 설치되어 바로 사용할 수 있음
Jupyter Lab 실행

jupyter lab

(참고) 윈도우에서 인코딩 이슈가 있다면(CP949) Encodings Extension을 설치하면 됩니다

간단한 실행(DuckDB Python)

DuckDB를 사용할 때, duckdb.sql로 실행하는 방법과 duckdb.connect로 Connection을 생성해서 쓰는 방법이 존재
- 1) duckdb.sql : 전역 메서드로 사용
  - 간단한 스크립트나 빠른 프로토타이핑, 노트북에서 유용
  - 메모리에 데이터를 저장함
```
import duckdb
duckdb.sql("SELECT 1")
```
- 2) duckdb.connect : Connection 객체를 생성해서 사용
  - 커넥션을 생성할 때 In-Memory 모드와 Both Persistent 모드를 선택할 수 있음
    - Disk에 Spilling을 사용해 메모리보다 큰 워크로드에서 데이터를 처리할 수 있음
      - 특정 작업이나 메모리가 부족할 때 데이터를 디스크에 임시로 저장하는 기법
  - 별도의 옵션을 지정하지 않거나 :memory: 옵션을 사용하면 In-Memory 모드로 생성
  - 파일 경로를 지정하면 파일이 생성되거나 사용됨
```
# 데이터를 메모리에 저장해서 사용
import duckdb

con = duckdb.connect(":memory:")
```
```
# 이 케이스에는 test.db 파일을 생성
import duckdb

con = duckdb.connect("test.db")
```
.show()는 결과를 출력만 하고 None을 반환
.show()를 사용하지 않으면 Relation 객체로 반환되어서 다른 곳에서 사용 가능
.df()를 사용하면 Pandas DataFrame으로 변경. 그러나 DuckDB를 사용하면 .df()는 거의 사용하지 않거나 가공을 DuckDB로 최대한 한 후에 사용하는 것이 좋을 듯(실행 시간이 느린 것이 체감됨)
```
import duckdb
duckdb.sql("SELECT 1").show()
output = duckdb.sql("SELECT 1 AS a")
duckdb.sql("SELECT a+1 AS b FROM output").show()
new_df = duckdb.sql("SELECT 1 AS a").df()
```

Data Load

CSV, Parquet, JSON에 바로 접근할 수 있음
- read_csv, read_parquet, read_json 함수를 사용

NYC 택시 데이터를 다운받아 테스트(약 300만 Row)

wget https://d37ci6vzurychx.cloudfront.net/trip-data/yellow_tripdata_2024-01.parquet

데이터 DESCRIBE

duckdb.sql("DESCRIBE SELECT * FROM 'yellow_tripdata_2024-01.parquet'")

Parquet 파일 Load
- 노트북 파일과 동일한 경로에 파일이 존재함
- read_parquet를 사용하는 것과 사용하지 않는 것의 차이는 없음
- 경로에서 glob 패턴을 사용할 수 있음 : SELECT * FROM ‘test/*.parquet’;
```
duckdb.sql("SELECT * FROM 'yellow_tripdata_2024-01.parquet' LIMIT 3")
```
```
duckdb.sql("SELECT * FROM read_parquet('yellow_tripdata_2024-01.parquet') LIMIT 3")
```

Parquet 파일을 읽고, 쿼리문에서 사용하고 싶다면 다음과 같이 사용할 수 있음

  nyc_data = duckdb.read_parquet("yellow_tripdata_2024-01.parquet")
  duckdb.sql("SELECT * FROM nyc_data")

jupysql을 사용해 더 편하게 실행하기

위 코드를 보면 항상 duckdb 또는 conn을 입력하고 쿼리를 실행해야 함. 반복적으로 하다 보면 이런 것들이 번거로움
jupysql을 사용하면 간단하게 실행할 수 있음
jupysql 설치
```
!pip install jupysql
```
SQL 쿼리를 실행한 후, Pandas DataFrame으로 항상 저장하는 옵션 설정
```
%config SqlMagic.autopandas = True
```

Extension Load

메모리 모드로 conn 생성

%load_ext sql
conn = duckdb.connect(':memory:')
%sql conn --alias duckdb

별도의 셸에서 실행. %sql, %%sql을 사용. %%sql은 여러 줄 쿼리 실행 가능
- 한 셸에서 여러 명령을 실행하려면 세미콜론으로 구분해야 함
```
%%sql 
SELECT
  DATE_TRUNC('hour', tpep_pickup_datetime) AS pickup_hour,
  COUNT(*) AS cnt
FROM read_parquet('yellow_tripdata_2024-01.parquet')
GROUP BY ALL
```

위에 사용한 쿼리의 결과를 저장하지 않아서 사용할 수 없고, <<을 사용해 변수에 저장할 수 있음

%%sql hour_cnt << 
SELECT
  DATE_TRUNC('hour', tpep_pickup_datetime) AS pickup_hour,
  COUNT(*) AS cnt
FROM read_parquet('yellow_tripdata_2024-01.parquet')
GROUP BY ALL

hour_cnt

DuckDB UI

2025년 3월 12일에 DuckDB Local UI가 출시됨
- 웹페이지 설명 글
- DuckDB 1.2.1 이후 버전부터 UI가 포함되어 있음
DuckDB UI 실행하는 방법(CLI)
```
  duckdb -ui
```
SQL 명령어에서 실행하고 싶다면

CALL start_ui();

Localhost:4213으로 실행됨
- 처음에 들어가면 노트북 파일이 없는데 샘플 노트북을 클릭하고, 코드를 실행하면서 구성 요소를 확인할 수 있음
UI가 없는 시기보다 훨씬 편해졌으며, 아직 UI에 추가되면 좋을 기능들이 보이지만 앞으로 계속 발전할 것으로 예상

저장된 파일 정보는 duckdb 설치 위치 내부에 저장되어 있음(~/.duckdb/extension_data/ui/ui.db)

SQL 문법

DuckDB SQL 문서를 확인하면 자세한 문법을 확인할 수 있음
일반적인 SQL 문법은 대부분 지원하고, PostgreSQL과 유사함
- PostgreSQL과 다른 점은 PostgreSQL Compatibility 문서에서 확인할 수 있음
SQL 문법이 궁금하시면 제가 인프런에 무료로 공개해둔 초보자를 위한 BigQuery(SQL) 입문 강의를 추천
- 문법 중에 일부만 다르고, 대부분 큰 흐름은 유사함
SQL 문법은 기억하고 싶은 일부분만 기록

GROUPING SETS, ROLLUP, CUBE

여러 차원에 대한 그룹화를 실행할 때 사용
GROUP BY에 포함됨
GROUPING SETS : 여러 차원에 대한 그룹화
- 어떤 차원을 그룹화할지 직접 지정
ROLLUP : GROUPING SETS의 특수한 형태. 주어진 차원의 Sub Group을 생성
- (country, city, zip) -> (country, city), (country), ()이 생성
- () : 전체를 의미
CUBE : GROUPING SETS의 또 다른 특수한 형태. 모든 가능한 조합을 생성
- (country, city, zip) -> (country, city, zip), (country, city), (country, zip), (city, zip), (country), (city), (zip), ()
GROUPING() 함수는 해당 컬럼이 그룹화되었는지 아닌지를 비트로 표현
- 3개의 컬럼일 경우 0 = 000, 1 = 001, 2 = 010, 3 = 011, 4 = 100, 5 = 101, 6 = 110, 7 = 111

샘플 데이터 생성

%%sql
CREATE TABLE sales (
    category VARCHAR,
    product_name VARCHAR,
    region VARCHAR,
    sale_date DATE,
    sales_amount INT
);

-- 샘플 데이터 삽입
INSERT INTO sales VALUES
    ('전자기기', '스마트폰', '서울', '2024-01-01', 1200000),
    ('전자기기', '스마트폰', '부산', '2024-01-01', 800000),
    ('전자기기', '노트북', '서울', '2024-01-01', 2000000),
    ('전자기기', '노트북', '부산', '2024-01-01', 1500000),
    ('의류', '청바지', '서울', '2024-01-01', 89000),
    ('의류', '청바지', '부산', '2024-01-01', 78000),
    ('의류', '티셔츠', '서울', '2024-01-01', 45000),
    ('의류', '티셔츠', '부산', '2024-01-01', 35000);

%sql SELECT * FROM sales

GROUPING SETS 실행

%%sql

# GROUPING SETS
SELECT 
    category,
    region,
    SUM(sales_amount) AS total_sales,
    COUNT(*) AS transaction_count
FROM sales
GROUP BY GROUPING SETS (
    (category, region),
    (region),
    ()
)
ORDER BY category NULLS LAST, region NULLS LAST;

category None은 region의 SUM, category, region 둘 다 None은 전체 합

ROLLUP

%%sql

# ROLLUP
SELECT 
    category,
    product_name,
    region,
    SUM(sales_amount) AS total_sales
FROM sales
GROUP BY ROLLUP(category, product_name, region)
ORDER BY category NULLS LAST, product_name NULLS LAST, region NULLS LAST;

(category, product_name, region) => (category, product_name, region), (category, product_name), (category), ()로 나타남

CUBE

%%sql

# CUBE
SELECT 
    category,
    product_name,
    SUM(sales_amount) AS total_sales,
    COUNT(*) AS transaction_count,
    GROUPING(category, product_name) AS grouping_level
FROM sales
GROUP BY CUBE(category, product_name)
ORDER BY category NULLS LAST, product_name NULLS LAST;

(category, product_name) => (category, product_name), (category), (product_name), ()
GROUPING 함수를 사용해 grouping_level을 구함(2개라서 0~3)

ORDER BY NULLS LAST

위 쿼리에서 나온 예시
정렬할 때 NULLS의 위치를 지정할 수 있음
NULLS {FIRST, LAST}

DATE 함수

다양한 Database에서 차이가 있는 것은 대부분 Date 함수
이 내용들은 공식 문서를 확인하는 것이 제일 좋은 방법
date_part(part, date) : BigQuery와 반대
- date_part 는 datepart로도 사용할 수 있음

FILTER

SELECT 절의 집계 함수에서 사용할 수 있음. 특정 집계 함수에서만 적용되는 필터링 기능
- FILTER가 없으면 CASE WHEN을 사용하는 것이 일반적

%%sql

SELECT 
    category,
    SUM(sales_amount) as total_sales,
    SUM(sales_amount) FILTER (WHERE region = '서울') AS seoul_sales,
    SUM(sales_amount) FILTER (WHERE region = '부산') AS busan_sales,
    -- 각 지역의 매출 비중도 계산
    ROUND(SUM(sales_amount) FILTER (WHERE region = '서울') * 100.0 / SUM(sales_amount), 1) AS seoul_percentage,
    ROUND(SUM(sales_amount) FILTER (WHERE region = '부산') * 100.0 / SUM(sales_amount), 1) AS busan_percentage
FROM sales
GROUP BY category;

UDF

보통 SQL로 UDF를 만들 수 있는데, DuckDB는 24년 10월 기준 Python 함수로 UDF를 생성
DuckDB python Function API
파이썬 함수를 만들고, duckdb.create_function 함수를 사용해 등록
- con.create_function(name, function, parameters, return_type)
- 이름, 함수, 파라미터, 리턴 타입을 명시해야 함

예시: 텍스트에서 이모지를 추출하는 UDF 만들기

!pip install emoji

import duckdb
import emoji  # pip install emoji 필요

def extract_emojis(text):
    if text is None:
        return None
    return ' '.join([c for c in text if emoji.is_emoji(c)])

con_udf = duckdb.connect()

# Python 함수를 DuckDB UDF로 등록
con_udf.create_function('extract_emojis', extract_emojis, ['VARCHAR'], 'VARCHAR')

%sql con_udf
# con_udf 연결

%%sql
# 테스트용 데이터 생성
CREATE OR REPLACE TABLE messages AS 
  SELECT * FROM (
    VALUES 
    ('안녕하세요 👋 오늘도 화이팅! 🔥'),
    ('맛있는 저녁 먹었어요 🍜 🍖'),
    ('날씨가 좋네요 ☀️'),
    ('축하해요! 🎉 🎊 🎈')
) AS t(message);

%%sql
SELECT 
    message,
    extract_emojis(message) AS emojis
FROM messages

Secrets Manager

Secrets Manager 문서
DuckDB에서 S3, GCS 등에 접근할 수 있음(내부적으로 httpfs Extension을 사용)
SECRET을 생성하면, 그 후에 사용할 수 있음

S3 Temporary Secrets

메모리에 저장
DuckDB가 실행된 동안에만 활용 가능

CREATE SECRET my_secret (
    TYPE S3,
    KEY_ID 'my_secret_key',
    SECRET 'my_secret_value',
    REGION 'my_region'
);

S3 Persistent Secrets
- 파일에 저장(~/.duckdb/stored_secrets)
- 다음 세션에서도 자동으로 로드
- 자주 사용해야 하면 Persistent Secret을 사용하는 것이 편할 수 있음. 그러나 보안에 취약해질 수 있는 점(Temporary Secret은 메모리에 저장되기 때문에 세션이 종료되면 사라짐)
- 디스크에 암호화되지 않은 바이너리 형식으로 저장됨
```
CREATE PERSISTENT SECRET my_persistent_secret (
    TYPE S3,
    KEY_ID 'my_secret_key',
    SECRET 'my_secret_value'
);
```
위 설정이 정상적으로 되었다면 s3:// 프리픽스를 사용할 수 있음
```
SELECT *
FROM 's3://my-bucket/file.parquet';
```

Secrets 삭제

DROP PERSISTENT SECRET my_persistent_secret;

DuckDB Extension

Extension 문서
- Communiy Extensions List, Community Extensions Github
DuckDB는 익스텐션 기능을 동적으로 Load 가능
DuckDB Extension은 아직 많이 없어서 오픈소스에 기여하고 싶은 분들이 시도해도 좋을 것 같음

설치된 목록 확인하기

%%sql
SELECT 
    extension_name, 
    installed, 
    description
FROM duckdb_extensions()

설치 후, Load
- INSTALL : 설치는 1회만 하면 됨
- LOAD : 세션마다 Load 필요
```
%%sql
INSTALL spatial;
LOAD spatial;
```

bigquery

BigQuery 데이터에 쿼리할 수 있는 Extension

ATTACH로 접근한 후, D를 붙여서 쿼리 실행

%%sql
INSTALL bigquery FROM community;
LOAD bigquery;

%%sql
D ATTACH 'project=my_gcp_project' AS bq (TYPE bigquery, READ_ONLY);
D SELECT * FROM bq.quacking_dataset.duck_tbl;

h3

Uber의 H3 인덱스를 다룰 수 있는 Extension
H3 내용은 Uber H3 : 육각형 계층의 인덱스 참고
위도, 경도 데이터가 있는 지리 데이터를 다룰 때 유용

pg_duckdb

이 글을 작성하기 2일 전에 나온 글 : pg_duckdb beta release : Even faster analytics in Postgres
PostgreSQL에 DuckDB 분석 엔진을 통합
PostgreSQL은 분석 목적이 아닌 트랜잭션 데이터베이스로 만들었지만, 종종 분석에 사용됨
- 처음엔 괜찮지만 데이터가 많아지면서 한계에 부딪힘
- 이럴 때 DuckDB를 사용하면 이점을 볼 수 있음
글에서 나온 인덱스 없이 TPC-DS 데이터셋을 로드하는 경우, 기본 PostgreSQL에 pg_duckdb가 1,500배 빨랐다고 함. 스크립트
나온지 얼마 안되서 아직 사용하긴 애매하지만, 더 발전하면 PostgreSQL에서 간단한 분석을 하거나 제품의 사용자가 많지 않을 때 DW 대용으로 사용할 수 있을 것 같음
- 만약 DW가 없어진다면 과거에 만들었던 데이터 파이프라인은 꽤 바뀔 수 있을 것 같음

vss(Vector Similarity Search)

What’s New in the Vector Similarity Search Extension?
Vector Database로 사용하기 위한 Extension
LLM이 발전하면서 트렌드가 된(?) Vector Database를 DuckDB도 지원한다고 보면 될 것 같음

DuckDB 활용 방안

일단 사용이 쉬우니 전처리에 시간이 많이 드는 경우에 일단 설치해서 사용해보는 것을 추천
데이터 웨어하우스에서 데이터를 집계한 후, 집계 데이터를 로컬로 가져와서 DuckDB로 분석
중고나라의 사례 : 분석 친화적인 데이터레이크로 진화하기
DuckDB – Overview and latest developments (DuckCon #5, Seattle, 2024) 발표 자료에 DuckDB의 역할을 다음 3가지로 제시. DuckDB의 지향점에 맞는 역할

BigQuery에서 사용하는 예시

(1) BigQuery의 SQL 쿼리로 데이터를 전처리 => GCS에 Parquet로 저장 => Local에서 DuckDB에서 GCS에 접근해서 분석
(2) pd.read_gbq를 사용해 BigQuery의 데이터를 Pandas Dataframe으로 가져온 후, 그 데이터를 DuckDB에 연결해서 분석
How to combine BigQuery with DuckDB 글을 보면 gsutil을 사용해서 GCS에 데이터를 추출하고, 그 데이터에 접근. 그 후에 다시 bq 커맨드를 사용해 BigQuery에 Load

로컬 데이터 웨어하우스처럼 사용(Pandas 대체)

기존에 로컬에서 데이터 분석을 하거나, 데이터 전처리를 할 때 Pandas를 많이 사용할 텐데 이젠 DuckDB로 대체할 수 있을 것
SQL로 데이터를 전처리하는 것이 더 좋은 방법이라고 생각
S3, GCS 등에 Parquet로 데이터 저장하고, 거기에서 쿼리를 실행하는 방식

필요할 때 사용하는 가벼운 분석 엔진 용도

OLTP의 가벼운 버전인 SQLite의 OLAP 버전이 DuckDB
Duckdb-wasm을 사용해 웹에서도 사용 가능

ETL, ELT 파이프라인에서 Transform 단계에서 사용

Spark나 Pandas로 데이터를 처리하는 과정에서 DuckDB를 사용할 수 있을 것
데이터가 엄청 많은 경우엔 Spark를 사용할 텐데, 이때는 아직은 어려울 수 있을 것(테스트를 꼭 해보고 판단해보는 것을 추천)

GCS에 있는 Parquet 쿼리하기

GCS 문서 참고
AWS S3는 S3 Parquet Import, Iceberg는 S3 Iceberg Import 참고

httpfs 설치(brew로 설치하면 기본으로 설치됨)

%%sql
INSTALL httpfs FROM community;
LOAD httpfs;

Credential 설정

HMAC Keys 생성
- HMAC Key에 대해 궁금하면 Google Cloud 문서 참고
- S3와 호환되는 라이브러리를 사용해 GCS에 접근할 때 사용
- Access Key ID와 Secret Access Key로 구성
- 서비스 계정의 인증 수단으로 활용이라고 볼 수 있고, GCS 접근용으로만 사용
아래 이미지에서 서비스 계정의 키 만들기 -> 서비스 계정 생성(Cloud Storage 권한 부여 : 스토리지 객체 사용자) -> 액세스 키 생성

아래 코드를 실행해서 DuckDB에 Secret 등록

%%sql
CREATE OR REPLACE TEMPORARY SECRET gcs_secret (
    TYPE GCS,
    KEY_ID 'KEY ID를 넣어주세요',
    SECRET 'SECRET를 넣어주세요'
);

GCS의 Parquet를 불러와서 DuckDB에 저장

GCS의 Parquet를 불러올 때 read_parquet 함수를 사용
다만 매번 GCS에서 불러오는 것은 네트워크 비용을 생각하면 느린 일이기 때문에, DuckDB의 Table로 생성해서 사용

%%sql  
CREATE TABLE yello_taxi AS
SELECT *
FROM read_parquet('gs://여러분들의_GCS_BUCKET/파일_경로.parquet');

warning 메시지는 sqlglot parser에서 발생하는 것 같으나, 동작에 문제는 없음

그 후에 쿼리 실행

당연한 이야기지만 yello_taxi 테이블을 만들어서 속도가 빠름
매번 read_parquet(‘gcs://~’)를 실행하면 데이터를 가지고 오는 시간이 소요되어서 느렸음
약 300만 Row를 GROUP BY 하는데 Wall time이 65.5ms => 0.06초

%%time
%%sql

SELECT
  DATE_TRUNC('hour', tpep_pickup_datetime) as pickup_hour,
  COUNT(*) as cnt
FROM yello_taxi
GROUP BY ALL;

참고 삼아 BigQuery로 실행

BigQuery 테이블을 생성한 후, 동일한 쿼리를 실행
경과 시간에 954ms로 DuckDB가 15배 빠름
성능 비교할 땐 하나의 케이스만 보고 판단하면 안되고, 데이터가 점점 많아질 때나 쿼리의 복잡도에 따라 여러번 실행해야 함
- DuckDB는 1인 사용자를 위해 최적화가 되어있고, BigQuery는 여러 사용자가 실행해도 문제가 없음
- 다시 생각해도 회사의 DW가 존재하고 => DW에서 데이터를 가지고 와서 DuckDB에서 분석하는 흐름이 좋을 것 같음
BigQuery와 DuckDB 성능 비교를 한 글도 보면 유용함

정리

DuckDB가 데이터 분석, 데이터 엔지니어링에서 영향력을 점점 넓힐 것으로 예상
과거부터 존재했던 데이터 웨어하우스를 사용하면서, 로컬에서 빠르게 처리할 때 활용할 수 있을 것
- DW 비용도 더욱 줄일 수 있음
아예 새롭게 파이프라인을 만든다고 하면 Spark를 사용하지 않고 DuckDB를 사용하는 것도 가능할 것으로 보임. PostgreSQL을 사용하면 규모가 커지기 전까지 모두 DuckDB를 활용
Reddit에서 검색해보니 다양한 토론이 존재
- 레딧 글1
- 레딧 글2 : 이 글에선 마케팅 아니냐는 댓글도 있음
AWS Lambda에서 DuckDB를 사용하는 케이스도 존재 : serverless-duckdb. Duckdb-wasm이 있으니 프론트엔드에서도 활용할 수 있음
- 누군가의 후기 : Lightning fast aggregations by distributing DuckDB across AWS Lambda functions
MotherDuck 가격도 확인해보니, STANDARD 가격이 월 25달러부터 시작해서 생각보다 저렴하게 사용할 수 있을지도(멤버 별 과금이 아니라 사용량에 기반한 과금)
DuckDB의 단점은 하나의 프로세스에서 실행되는 점인데, 이건 애초에 설계할 때 염두하지 않은 내용. 여러 프로세스에서 READ는 가능, WRITE는 불가능. Handling Concurrency
DuckDB의 성능 이슈가 있다면 Performance Guide, My Workload Is Slow 글을 보면 도움이 될 것 같음
- FAQ에도 성능, 어떻게 사용할지가 나옴

참고 자료

DuckDB: An Embeddable Analytical Database Paper
DuckDB-Wasm: Fast Analytical Processing on the Web
DuckDB에서 참고한 논문은 Standing on the Shoulders of Giants에서 확인할 수 있음
DuckDB Snippets : DuckDB를 사용할 때 쓸 수 있는 Snippet을 올려주는 공간(예 : CSV to Parquet 등)
Awesome DuckDB
In-Process Analytical Data Management with DuckDB : 전체적인 설명이 잘 되어있는 글
Free DuckDB In Action Book : 이메일을 입력하면 무료로 DuckDB IN Action을 받을 수 있음. 챕터 8의 Building Data Pipelines with DuckDB 내용이 좋았음
다른 라이브러리와 통합

글 작성하는데 걸린 시간 : 7시간 20분
- 하고자 하는 이야기, 개요 정리 : 20분
- 초안 글 작성 : 6시간 10분
- 클로드/Cursor와 셀프 글 피드백 : 30분
- 2차 글 작성 : 20분
간단 회고
- DuckDB는 어느정도 사용하고, 공부도 이미 한 주제인데 방대한 내용을 정리하고 예시를 추가하는 과정에서 시간이 소요됨

글또 10기 참여자 관점, 운영자 관점의 다짐

Sat, 05 Oct 2024 00:00:00 +0000

글 쓰는 개발자 모임 - 글또 10기가 시작되었습니다
저는 글또 5기까지엔 글을 작성하고, 6기~9기 때는 글또를 운영하는 것에 초점을 맞췄습니다. 운영자 관점에서 참여하다보니 글이 없었는데, 10기는 마지막이니! 의미를 담아 다시 글을 작성하려고 합니다
글또 10기 참여자 관점, 운영자 관점의 다짐을 공유합니다

글또 10기

마지막으로 작성했던 글또 회고, 다짐 글이 언제인가 찾아보니 글또 4기 운영 회고 및 글또 5기를 준비하며 쓰는 글. 벌써 4년 전이고, 그 사이에 4년이나 지났다니 시간이 참 빠르다
- 이 시기엔 회사를 다니면서 커뮤니티를 운영하고 있어서 엄청 새로운 것을 많이 시도하지 않았던 시기
- 코로나도 있었고, 온라인 상황에서 할 수 있는 것을 조금씩 진행했다
글또는 시스템적으로 매 기수 많이 발전하고 있는데, 8기 때 또봇이 처음 등장했다
- 또봇이 등장한 후, 이모지를 남겨서 글을 체크하는 방식 대신 별도의 모달을 통해 글을 제출하는 방식으로 변했다
- 사람들이 이모지를 누락했던 케이스가 사라지고, 점점 더 시스템적으로 제출할 수 있게 되었다
- 그리고 글또는 매번 기수가 진행되면서 계속 디벨롭을 해왔고, 10기 때도 새로운 시스템이 생겼다
포인트 시스템
- 또봇을 만들어주신 은찬님과 구의 탐탐에서 이야기를 할 때 포인트 시스템에 대해 이야기를 했다
  - 은찬님이 이야기를 듣고 흥미롭게 들어주셨고, 빠르게 구현을 해주셨다.
- 과거부터 어떻게 해야 사람들이 더 재미있게 글또에 참여할 수 있을까?를 고민했고 게이미피케이션을 도입하면 어떨까 싶었다
- 포인트로 직관적으로 보여주고 그것을 활용할 수 있도록 하고 싶었다
- 글또의 활동을 통해 명시적으로 보이는 것이 “글”이였다면, 이젠 글이 아니어도 포인트나 관계를 보여줄 수 있게 되었다
- 9기 때 데달부(현 CRM 크루)에게 Push 메시지를 보내면서 사람들이 커뮤니티에서 얼마나 글을 작성하고, 어떤 관계를 맺었는지 보여주게 되었다
- 개발 관점에선 데이터 로깅을 배치로 진행하다가 실시간으로 하는 것으로 변했다. 이건 데이터 직무를 하는 사람들 관점에서도 흥미롭게 들을 수 있을 것 같아서, 언젠가 발표로 풀지 않을까 싶다. 직접 개발을 하지 않았지만 아키텍쳐 설계를 할 때 은찬님에게 가이드를 드렸다.
- 글을 제출할 때, 공지사항에 이모지를 남길 때, 특정 조건을 달성할 때 포인트를 지급하는 구조로 만들었다
  - 사람들의 사용 데이터를 보면서 기능을 조금씩 추가하고 있다
  - 글 제출을 1등으로 할 때 포인트, 연속으로 글을 작성할 때 콤보 등. 게임 기획을 위한 책도 보고 고민도 하며 만들고 있다
따뜻한 커뮤니티를 만들고 싶었다
- 익명 커뮤니티 같은 곳을 보면 점점 차갑고, 냉소적으로 변하는 것을 느낄 수 있었다
- 내가 있는 곳은 조금이나마 더 따뜻한 곳이 되길 바라는 마음에 따뜻함을 느낄 수 있도록 커뮤니티를 설계하고 싶었다
- 9기 땐 감사함을 외치는 것을 해보려고 했으나, 이게 잘 동작하기 쉽지 않았다. 누군가에게 감사함을 표시하는 것도 용기가 필요한 일이기에
- 그래서 감사함을 표시할 수 있는 매개체를 만들고, 그것을 전달하는 것을 생각했다. 포인트 시스템과 연계해서 포인트를 전달할 수 있게 하려고 했으나 기획하다보니 포인트를 주는 것보다 별도로 감사함을 전달하는게 더 좋을 것 같아 감사함을 표시할 수 있도록 했다
- 이게 종이비행기로 탄생했다
  - 누군가에게 종이비행기를 보내고, 사람들은 자신이 보낸, 받은 종이비행기를 확인할 수 있다
  - 사람들이 서로 종이비행기를 잘 보내려면 잘 연결하는 것이 핵심이라 연결하는 것을 고민 중
- 종이비행기 외에 대나무숲은 여전히 따뜻하고, 소모임 채널에서도 잘 활동해주고 계신다
운영진 크루
- 운영진은 34분이 계신다. 운영진의 내부 팀을 크루라고 부르는데, 여러가지 역할이 새로 생기기도 하고 과거 운영진을 하셨던 분들이 새로운 것들을 시도하기도 한다
- 각 역할이 있고, 그 역할을 수행하면 글또의 전체적인 만족도가 더 올라갈 것을 기대하고 있다
- 목적 조직처럼 구성되고 있는 점도 흥미롭고, 각 크루에 계신 분들이 활동을 하시고 그런 내용들을 글또 웹페이지에 기록하는 것을 목표로 하고 있다
- 사이드 프로젝트지만 잘 진행할 수도 있다는 것을 보여주고 싶고, 이분들의 커리어도 더 잘 되시면 좋겠다
- 운영진 MT도 가는데, 가서 서로 이야기 많이 나눌 수 있길
- 마지막으로 운영할 예정이라 잘 마무리하기 위해 커뮤니티를 어떻게 운영하는지에 대한 내용도 전수하려고 하고 있다. 암묵지들을 잘 정리해두고, 이것도 최대한 전수하고 가야겠다는 생각
- 오프라인 모임을 매 기수 반상회라고 했었는데, 이번엔 전체가 모이는 행사를 하면 좋지 않을까 생각하고 있다
640명이 되는 분들이 참여해주셔서, 책임감이 있다. 많은 분들이 하나라도 얻어갈 수 있는 시간이 되길
글또 관련한 더 자세한 내용은 추후에 글또 웹페이지에 하나씩 정리해서 올릴 예정

글또 10기 운영의 핵심

글또 비전과 동일하다
- 사람들이 글을 잘 작성하도록 돕고
- 사람들이 서로 연결될 수 있도록
2가지가 제일 핵심이라, 이 부분에 대한 내용을 계속 생각한다
어떤 분들은 글만 쓰고 싶을 수도 있고, 어떤 분들은 사람을 만나고 싶을 것
- 제일 핵심인 글쓰기는 모두 다 할 수 있도록 하고, 사람을 만나는 것은 점진적으로 하는 것을 권장할 예정
- MBTI가 I더라도 사람들은 만날 수 있다. 만나기까지 힘든데, 막상 만나면 좋은 경험을 했다라는 글을 많이 봤다
소모임 채널의 활성화에 따라 글또 슬랙의 리텐션이 높아진다(당연하게도)
- 그래서 소모임 채널을 운영하기 위해 어떻게 해야하는지를 전달해보기
- 소모임 채널의 주인분들을 4장님이라고 부르기로 했다
- 글또라는 마을이 있고, 그 안에 소모임 사장님도 계셔서 마을을 조화롭게 꾸릴 수 있게 되는 것
5년, 10년 후에 글또를 하신 분들이 그리워하시길 바라는 마음이 있다. 그런 생각이 들 수 있도록 해보기
글또 11기에 질문이 종종 들어오지만, 지금은 크게 생각이 없다. 나 자신도 어떻게 해야할지 변화를 고민하는 시기고 글또를 지금 형태로 계속 유지하는 것이 어렵다고 생각되었다.
- 이후 커뮤니티가 어떻게 되는지는 OT 때 말했으니 나중에 다시 다뤄볼 예정
- 마지막을 잘 정리하기 위해 국가가 어떻게 사라지는가, 생물이 어떻게 없어지는가 등을 찾아봤는데 참 잘 마무리하기 파트는 내용이 적다.
마지막이라는 생각이 있기에 동기부여가 되기도 한다.
- 어떤 일을 “즐겁게” 하고 있는가?라는 생각을 종종 하는데 글또 운영이 요즘 즐겁다(하 이러면 안되는데) 포인트 시스템도 재미있고, 많은 분들이 활발히 활동해주셔서 그런 것 같다
  - 그래도 일단 정리는 하는 것으로 생각하고 있고! 그래도 즐겁게 해보자
  - 그 이후는 끝나갈 쯤에 고민해도 늦지 않다. 지금은 지금이 중요하다

글또 10기 참여자 관점

오랜만에 글을 다시 작성한다. 최근에 글이 적었는데, 동기부여가 덜 되어서 글을 덜 작성했다.
- 연차가 쌓일수록 스스로에 대한 검열이 생기는데 이런 현상이였던 것 같다. 공부한 내용은 노션에 많은데 글로 작성한 것은 적다
- 누군가를 위해서가 아닌 나를 위해서 하나씩 다시 기록하기로. 기록도 습관이라 계속 써야 그 관성이 유지된다
- 인스타그램, 유튜브도 요즘 멈췄는데 이게 다 한번씩 겪는 그런 과정인 것 같다. 갑자기 무언가를 작성하고 공유하기까지 시간이 걸린다
그럼에도 불구하고 하나씩 해야 쌓인다.
글 작성한 것들이 지나고 나면 참 뿌듯하다. 멘토링을 하거나 기술적인 자문을 할 때 과거에 작성한 글이 도움되는 경우가 종종 있다. 하나의 글을 논리적으로 잘 접근해서 만들기
글쓰기 세미나는 과거부터 총 5회 이상 진행했는데, 이젠 이 내용을 인프런에 글쓰기 강의로 올릴 예정. 인프런에 올리는 것이 빠를지 10기 글쓰기 세미나가 더 빠를지 모르겠지만, 일단 최대한 시도해보기

어떤 글을 작성할 것인가?

이번엔 데이터 엔지니어링 글, 나의 평소 생각(철학, 원칙)에 대한 글을 주로 작성 예정
- DuckDB, Airbyte 등
- 이런 도구들을 사용해서 스타트업에서 적당한 규모로 데이터 파이프라인 운영하기 글을 작성할 예정
데이터 분석 과정에 대한 것도 정리해볼 것 같은데, 구체적인 케이스보다 전체적인 Overview를 나타내는 글 위주를 생각하고 있음
그리고 지금 생각하고 있는 주제가 있는데, 이건 영상으로 풀지 글로 풀지도 고민. 둘 다 해도 괜찮을 것 같은데, 일단 만들고 고민할 예정
요즘 보고 있는 논문도 있는데, 해당 내용도 정리할 예정
개인 사업자의 삶 2년 회고도 가능할 것 같고, 어떤 부분이 더 개선되면 좋을지도 정리할 수 있음
앞으로의 커리어에 대한 생각도 있는데, 이것은 조금 더 진행된 후에 글로 작성할 것 같다. 결정을 하고 시간이 지난 후 어떤지 판단할 수 있는 경우가 많기 때문
타인에 의해 소재를 발굴하려고 하면 한계가 있다. 타인은 이야기를 하지 않는 경우가 많기 대문. 그래서 내 내면에서 내가 필요한 것을 고민하고, 요즘 처한 상황에서 문제를 해결하는 과정에서 소재를 뽑아내는 것이 중요.

요즘 중요하게 생각하는 것은?

아이유님 콘서트에 갔다가 과거의 내 꿈은 무엇이였고, 나는 지금 무엇을 하고 싶은지에 대해 생각해봤다
이 질문은 살면서 계속 따라올 질문이라 답을 내려고 하는 것보단 주기적으로 생각하는 시기를 가지고 있다
조금 더 내가 즐겁게 열심히 할 수 있는 환경도 마련해야 할 것. Comfort Zone을 조금은 벗어날 수 있는 시도를 할 것
호명사회 책을 읽고 있는데, 요즘의 현실을 잘 반영한 책이라 생각한다. 내가 하고자 했던 것과 나의 원칙들을 잘 남겨두는 것이 중요하다
원칙은 스스로 정리하고 있다. 이 부분은 더 쌓이면 블로그가 아닌 별도의 공간에 기록할 예정

정리

오랜만에 글또 다짐을 작성하니까 기분이 새롭다. 6개월 후엔 어떤 것들을 또 경험할지 기대된다
작성한 내용을 최대한 지키려고 시도해보기. 주기적으로 이 내용을 보면서 내가 하려고 했던 바로 하고 있는지 생각해보기
이런 기록이 쌓여서 나의 경험이 된다

글 작성하는데 걸린 시간 : 약 48분

데이터 분석가 로드맵(프로덕트 분석가)을 만들며 했던 생각들

Wed, 21 Aug 2024 00:00:00 +0000

와 올해 블로그에 쓴 글이 0개였다니.. 충격적이네요. 의식하면서 글을 써보도록 할게요
이번 글은 인프런에 프로덕트 분석가 로드맵을 작성한 내용에 대해 공유해볼게요
강의 만드는 과정의 노하우 공유는 예전에 작성한 인프런에서 강의 만들기 글에 있어요

프로덕트 분석가 로드맵 제작

인프런 로드맵을 만들었어요. 제가 퇴사하고 만든 강의들을 모아둔 내용입니다

왜 프로덕트 분석가인가?

데이터 직무로 처음 일했던 회사에서 했던 일을 돌이켜보면 앱 로그 데이터 분석을 많이 진행했어요. Firebase의 데이터를 다루면서 앱 데이터가 어떻게 생겼는지, 로그 설계는 어떻게 해야하는지 등을 경험했어요
그 당시엔 프로덕트 분석가라는 이름이 따로 있진 않았지만, 시간이 지나고 보니 이런 이름으로 불리게 되더라구요
이직한 후에도 GA, Firebase 데이터를 어떻게 다룰지에 대해 생각해보고, 앱 로그 데이터에 대한 마트를 제작하기도 했어요. 그래서 이 부분에 대해서는 많은 시행착오를 겪었어요
Amplitude, Mixpanel에 대한 것도 개인적으로 경험해보면서, 로그 데이터가 어떻게 구성되고 어떤 관점으로 바라볼지에 대해 알게 되었어요
그리고 비즈니스나 머신러닝 알고리즘 관점에서 AB Test를 해보고, 해석의 모호함이 생길 땐 어떻게 해결해야 할지, 통계적 유의성이 이슈가 있으면 어떻게 해야할지 등에 대해 경험했어요
돌이켜보면, 저는 여러 직무를 경험했지만 B2C 앱 데이터를 많이 다루곤 했어요. 그래서 프로덕트 데이터 분석가 로드맵을 만들기로 했어요(제일 많이 경험하고 시행 착오가 존재하는)

나는 왜 교육을 하는가?

프로덕트 분석가라는 이름이 있지 않던 시절 이 분야를 공부할 때 참 어려웠어요. 회사 개발자분께서 DB를 배우는 것이 필요하다고 해서 새로쓴 대용량 데이터베이스 솔루션을 공부하기도 했어요. DB를 이해하는데 도움이 되긴 했지만, 내용이 너무 어려웠던 기억이 나네요(요즘 학습하면 LLM의 도움을 받아 더 쉽게 가능하겠지만)
교육을 해야겠다고 다짐할 때, 과거의 저처럼 회사에서 업무를 진행하다가 어려움을 겪는 분들이 조금이나마 더 나은 길을 가길 바랬어요
어떻게 보면 과거의 저에게 보내는 강의라고 볼 수 있어요
- 이 내용을 미리 알았다면 참 좋았을텐데, 실제로 해보면 이런 부분을 깊게 생각하면 좋은 것 등
- 그래서 PM을 위한 데이터 리터러시 강의에는 “카일 스토리”라는 것이 나옵니다. 원래 강의 인트로에 연기하려고 했다가, 어설프게 하려니 이상해서 그냥 덤덤한 방식으로 전개했어요
저를 경험한 분들이 더 좋은 삶을 살길 바라고 있어요. 그냥 각자가 더 좋은 삶(사람마다 정의하기 나름이지만)을 살길 바라고 있어요
- 여러 관점이 있지만, 인프런에 올리는 내용은 대부분 업무를 하다가 겪는 내용들을 다루곤 해요. 어떻게 해야 일을 더 잘할 수 있고, 회사에서 인정 받을 수 있을까?를 주로 다룹니다
- 유튜브에는 커리어에서 생각할 수 있는 고민들을 주로 다루고, 로드맵이나 제 생각을 공유하곤 해요. 이런 내용을 통해 영감을 받길 바라고 있어요(꼭 그대로 하는 것이 아닌 자신만의 방법을 찾는 것)
어떤 형태의 강의를 하고 싶었는지 생각해보면, 고등학생 때 들었던 신승범 선생님처럼 수업하고 싶었던 것 같네요. 강의 자체도 하지만, 인생에 대한 내용이나 어떻게 삶을 살아갈지, 동기부여 등도 같이 진행하고 싶었어요
- 요즘 수학은 정승제 선생님 강의를 듣던데, 이 맥락과 비슷한 것 같네요
- 강의에 저도 이런 동기 부여에 대한 내용도 추가하려고 생각하고 있어요

어떤 것이 중요하다고 생각했는가?

강의는 총 3개로 구성되어 있고, 나머지는 유튜브 영상이에요.
PM을 위한 데이터 리터러시
- 문제 정의, 구조적인 사고, 로그 설계, 실험 설계, 의사 결정, 데이터 문화 등 데이터를 다루다가 생기는 다양한 일을 모두 담았어요
- 제 강의 중에 처음 어떤 강의를 들을까? 생각하면 이 강의가 제일 좋다고 생각합니다. 회사에서 어떤 방식으로 일을 하는지 알아보면서 데이터 분석을 어떻게 해야할지에 대해 알 수 있어요
- 제가 익힌 여러 암묵지를 모두 담은 강의라, 다시 이런 종류의 강의를 만들라고 하면 어떤 내용을 더 넣어야 할지 고민될 것 같네요. 물론 더 추가할 부분이 있긴 합니다
- PM 직무에 계신 분들도 보기 좋고, 디자이너, 데이터 분석가 모두 보면 좋을 내용으로 구성되어 있어요
초보자를 위한 BigQuery(SQL)
- 데이터를 다루기 위해 SQL을 알아야 합니다.
- 회사에서 SQL을 처음 배우는 분들이 어디서 어려움을 겪는지, 어떤 것을 알면 좋을지 고민하며 만들었어요
- 강의에서 특히 힘을 준 부분은 “데이터 검증”, “쿼리를 작성하는 흐름”. 이 부분은 암묵지에 해당될 수 있는 내용인데, 회사에서 참 중요하다 생각했어요
- 지표를 잘못 뽑고, 지표를 보는 분에게 잘못 뽑았다고 말하는 경우 종종 있을 수 있는데, 데이터 검증을 어떻게 해야할지에 대해 모르거나 쿼리의 실수로 발생하곤 합니다. 간단하게 특정 user_id를 선정해서 미리 확인해보는 과정으로 해결할 수 있는데, 이런 내용에 대해 알지 못하는 경우가 있었어요
- 쿼리를 작성하는 흐름은 처음에 이런 큰 그림을 이해하면 더 잘 작성할 수 있다고 판단했어요
- 쿼리를 작성할 때 참고할 수 있는 데이터 템플릿도 공유드리고, 이걸 자동화할 수 있는 도구도 알려드렸어요. Espanso라는 도구인데, 무료고 오픈소스라 많은 분들이 아시면 좋을거에요
- 시간 데이터를 다룰 일이 많은데, 서버의 데이터는 UTC로 저장되어 있는 경우가 많아요. 이 때 타임존에 대한 내용을 모를 수 있는데, SQL에서 이 부분을 학습하면 좋겠다고 생각했어요
BigQuery 활용편
- 이 강의는 입문편에서 다루진 않은 부분 중 유용한 함수인 윈도우 함수를 주로 다룹니다
- Firebase 데이터의 특징으로 배열 데이터를 다뤄야 하는데, 배열 데이터를 다루는 방법에 대해서도 학습합니다
- 단순히 문법만 배우는 것이 아니라 퍼널 분석, 리텐션 분석을 어떻게 접근하면 좋은지 공유합니다
- PM을 위한 데이터 리터러시 강의랑 연결되는 부분인데, 제품에 대해 생각하고, 그 부분에서 리텐션 개선 아이디어를 생각하도록 강의를 구성했어요. 이렇게 말을 해도 실제로 데이터를 보면 데이터만 보게 되는 경우가 종종 있어서, 강의에서 계속 제품에 대해 고민할 수 있도록 생각을 공유했어요
- Google Sheets로 자동화를 할 수 있는 부분이 꽤 있는데, 이 부분도 알아가시면 좋을 것 같다 싶어 이 부분도 추가했어요

데이터를 활용하고 싶은 분들이 어떻게 학습하면 좋을까

이 부분은 최근에 쓰레드에 길게 남겼는데, 블로그에도 공유해보아요. 존댓말을 쓰지 않고 자유롭게 남긴 내용입니다
하드 스킬에 대한 내용은 줄인 버전이고, 머신러닝이나 데이터 시각화 등에 대한 지식은 언제든 해도 괜찮다고 생각
보통 데이터를 활용한다라고 하면 파이썬, SQL, 통계 같은 기술적인 것부터 생각한다. 그렇기 때문에 이걸 해야 데이터를 활용할 수 있다고 생각
- 데이터를 활용한다는 것은 데이터 기반 의사결정을 한다는 것이고, 이것은 문제를 해결하는 과정에서 지표를 정의해서 지표에 따른 의사 결정을 하는 것
- 제일 중요한 것은 문제를 정의하고, 문제를 인식하는 것. 대부분 이 부분을 그냥 넘어가지만, 문제 정의를 잘 진행하는 것이 제일 중요하다. 정의가 잘 된다면 지표는 자연스럽게 나오고, 지표는 사용할 수 있는 도구(엑셀, 파이썬, SQL 등 사용 가능한 것)로 추출하면 된다
- 논리적 사고는 “로지컬 씽킹” 책을 추천. 맥킨지식 논리적 사고로 유명하고, MECE / So What? Why So를 매번 생각한다
- 사실 이 역량은 모든 직무에게 필요하다
논리적 사고에 대해 어느정도 파악을 했다면, 그 후엔 무엇을 해야할까?
- 그 후엔 데이터를 어떤 관점으로 바라볼지에 대해 감을 잡으면 좋다. 신입 시절에 데이터를 어떻게 바라볼지에 대한 관점이 없이 일단 데이터를 뽑고 해석을 하려고 했는데, 데이터를 바라보는 관점이 없어서 어려웠다.
- 데이터를 바라보는 과정에선 1) 그래프 기반, 2) 호기심 기반, 3) 상급자 기반 등이 있는데 3가지 방법보단 “목적 기반”으로 보는 것이 핵심. 어떤 목적을 가지고 어떤 지표를 볼지, 그리고 어떤 것을 해야할까?에 대해 생각해보는 것이 필요하다. 목적이 없으면 기준이나 판단이 어렵다.
- 이런 관점에 대해 잘 나온 책은 “빅데이터 시대, 성과를 이끌어 내는 데이터 문해력” 이 책이 나왔을 때 처음 읽고 완전 감동받은 책. 논리적 사고랑 연결되는 부분이 있다
(3) 논리적 사고, 데이터 목적에 대한 학습. 그 후엔?
- 앞선 것들을 잘 진행하기 위해, 회사의 비즈니스 모델을 잘 이해하면 좋다. 비즈니스 모델이란 것은 회사에서 매출이 언제 발생하고, 어떤 흐름으로 돈이 돌아다니는지를 의미한다. 데이터 분석을 한다는 것은 목적이 있을텐데, 회사의 서비스를 성장하기 위해 무엇을 해야할까?, 매출을 증가시키기 위해 무엇을 해야할까?, 비용을 줄이기 위해 무엇을 해야할까? 등을 생각한다. 이 때 비즈니스 모델을 이해하면 더 수월하게 생각할 수 있었다.
- 관련해서는 “한 장으로 끝내는 비즈니스 모델 100” 책을 추천. 도식화로 정리가 되어있어서 도움이 된다. 그러면서 사용하고 있는 앱이나 서비스의 비즈니스 모델을 분석해보는 것도 추천
- 강의를 들은 분들 중 면접을 잘 보고 싶다고 하는 분들에겐 “지원하는 회사의 비즈니스 모델”을 스스로 분석해보고, 도식화해서 그 내용 기반으로 무엇을 할지 생각해보라고 권한다. 이런 것을 하는 사람이 적다.
(4) 논리적 사고, 데이터 목적, 비즈니스 모델. 그 후엔?
- 그 후에 간단한 통계학 공부를 하면 좋은데, 통계학을 어려워하는 사람이 있기에 처음엔 쉽게 접근하는 것을 추천한다. “데이터 분석가의 숫자유감”이란 책이 있는데, 만화로 구성되어 있다. 통계를 활용하는 핵심적인 부분이 나와있어서 이 책을 보면 대략적으로 어떻게 활용해야 할지에 대해 감이 온다.
- 그 후에 추천하는 책은 “숫자에 약한 사람들을 위한 통계학 수업”. 이 책도 핵심적인 통계학 개념을 쭉 훑고, 실용적인 관점에서 사례가 많이 나온다. 수학을 극도로 배제해서 눈높이를 낮추어서 많은 분들이 읽을 수 있다.
- 그 후에 본격적인 통계를 공부하고 싶다면 “An Introduction to Statistical Learning”를 추천. 줄여서 ISLR라고도 하는데, 많은 분들이 이 책을 기본서 같이 생각한다. 한국어 번역이 있다고 들었지만, 원서를 추천. 구글에 책 제목을 검색하면 원서가 나온다(파이썬 버전도 있음)
(5) 통계학 그 후엔 무엇을 해야할까, 이 시기엔 상황에 따라 다를듯. 우선 회사에 다니고 계신 분들 대상으로 먼저 이야기 회사에 다니고 있다면, 어떤 문제를 해결해야 할 것. 진행하고 있는 업무가 문제와 관련되어 있을 것이다. 이 문제를 해결하기 위해 어떤 것을 해야할까? 어떤 지표를 봐야할까? 생각하기
- 이 과정에서 지표 정의에 대해서 알면 좋은데, 지표가 어렵다면 “문제가 해결되면 어떤 모습이 되는가? 그 모습을 숫자로 표시한다면?” 질문을 통해 정의. 요즘은 LLM이 잘 발전되어 있어서 어떤 문제를 해결하고 싶은지를 클로드 등에 물어보면 잘 추천해준다. 그러면 그 지표들을 모두 모아서 어떤 것을 사용할지 결정한다.
- 그리고 해당 지표를 개발자나 데이터 분석가분들에게 부탁해서 받아보고, 그것 기반으로 “Action Item”을 생각해본다. 뭘 해야 그 지표를 올릴 수 있을까? 그리고 그것을 실행하고 기능 개발 -> 의사 결정. 바로 문제를 푸는 방법
(6) 회사에 다니지 않는 취준생이라면
- 이런 경우 참 어렵다. 취준생 입장에서 데이터를 어떻게 구할까?라는 고민에 빠진다. 이를 해결하기 위해 캐글이란 플랫폼이 나왔지만, 캐글은 문제 정의가 된 후에 데이터를 제공한 후 모델링에 집중한다.
- 데이터를 활용한다는 것은 문제에서 데이터를 해석하고, 의사결정하는 것이라고 볼 수 있다. 그리고 데이터가 쌓인 후 목적에 맞으면 예측 모델링을 진행한다. 취준생이라면 내가 데이터 분석을 집중하고 싶은지, 모델링을 하고 싶은지 고민해야 한다. 많은 교육 과정에서 모델링 위주로 교육해서 혼란스러운 경우가 있는데, 나눠서 생각해보는 것을 추천.
- 어떤 직무를 하던, 이 쯔음에 SQL/파이썬 등을 학습한다. 요즘은 대부분의 책이 잘 나와서 서점에서 고르는 것도 추천

데이터 분석가 로드맵에 더 추가되면 좋은 것은?

어떤 내용이 더 필요할까 생각해봤는데, 다음 내용을 추가하면 좋을 것 같다
데이터 전처리에 대한 학습 : 데이터를 어떻게 처리할지에 대해 방법론이 다양한데 각 방법론의 장단점과 어떻게 활용하면 좋을지에 대해 학습
설득하기, 협상하기 : 대화를 할 일이 참 많은 직무다. 설득하기, 협상하기는 어떤 직무여도 있으면 좋겠지만 데이터 분석가분들이 더 들어보면 좋겠다. 사내 컨설턴트가 된다는 생각도 같이 하면서
그 후엔 자신이 자신 있는 도메인 영역을 정해보면 좋겠다. 산업이여도 괜찮고, 비즈니스나 프러덕트 등으로 생각해도 좋다. 하나의 도메인에서 해결할 수 있는 문제를 거시적으로도 파악하고, 미시적으로도 파악해보면 좋겠다
경영진의 사고 과정 : 경영진에 계신 분들이 어떤 생각을 주로 하고, 어떻게 생각하는지 알아두면 좋다. 이런 생각을 할 수 있게 된다면, 내가 지금 어떤 일을 해야할지를 더 잘 생각할 수 있다. 상황에 따라 유연한 접근이 필요한데, 대표님이 지금 무슨 생각을 할까?라는 생각을 하면서 업무를 하곤 했다
물론 위에 말한 내용은 일반적인 데이터 분석가 로드맵에서 나오는 내용도 있지만, 아닌 내용도 있다. 회사에서 일을 잘 진행하기 위해 필요했던 내용인데 나만의 경험일 수도 있을 것 같고, 아닐수도 있다
데이터 사이언티스트가 되고 싶다면, 데이터 분석도 해보고 전략, 데이터 엔지니어링 등을 모두 경험해보는 것을 추천한다. 다만 요즘 데이터 사이언티스트도 회사마다 다르다. 주로 추천 알고리즘을 만들고 데이터 분석을 할 때 데이터 사이언티스트라고 불리는 것 같다

앞으로 할 것들

데이터 분석 관련 강의는 잠시 쉬고, 원래 만들고 싶었던 내용을 만들려고 합니다
어떻게 해야 데이터 엔지니어링을 쉽게 할 수 있을지에 대한 내용. 그리고 데이터 분석가가 이정도는 알면 좋은 개발 지식. 이렇게 선언해두면, 언젠가 하려고 시도할거라 생각해서 선언해두어요
일단 개발자 블로그 글쓰기 강의는 빠르게 만들 수 있어서, 이것부터 하고 전체적인 강의에 대해 설계할 예정
강의 만드는 것도 시행착오가 있어서, 여러 방법으로 시도하고 있어요. 이제는 어떻게 해야 속도를 낼 수 있을지 감을 잡아서 계속 시도해볼 예정이에요.
그 후엔 다시 회사로 돌아가지 않을까 싶어요. 다만 그 사이에 최선을 다해 강의를 만들려고 해요. 회사에 들어가서 온보딩 자료로 활용할 수 있는 수준으로 강의를 만들려고 합니다. 정해진 것은 아무것도 없지만, 일단 이정도로 생각하고 있어요
최근 데이터 리터러시에 대한 니즈를 많이 느끼고 있어요. 강의 판매도 늘어나고 있고, 기업 강의도 요청받고 있어요. 많은 분들이 데이터를 더 잘 활용하고, 쉽게 접근할 수 있도록 계속 하나씩 만들어 볼게요
- 회사에서 데이터를 어떻게 활용해야 하는지 가이드를 주고, 더 잘 진행할 수 있도록 돕는 직무도 점점 필요해지는 것 같아요. 단순히 데이터 프러덕트를 만들고 끝이 아니고 여러 조직에 있는 사람들의 상황을 파악하고 해결할 수 있는 방법 도출
저는 데이터 분석가분들이 점점 데이터 엔지니어링을 할 수 있어야 하고, 데이터 엔지니어도 데이터나 비즈니스에 대한 큰 그림을 이해하면 좋다고 생각해요. 회사 상황에 따라 다를 수도 있지만, 데이터 관련 큰 그림을 잘 이해할 수 있는 사람들이 더 필요한 시기라고 생각해요
대학생분들을 어떻게 도울 수 있을까 고민하고 있어요. 대학원을 가지 않은 제가 교수를 하긴 어려워서, 지금 진행하고 있는 일들을 집중하려고 해요. 부스트캠프 AI Tech와 유튜브 등. 학생분들이 도움을 구하면 가능하면 최대한 시도해보려고 하고 있어요
데이터 직무가 아닌 분들이 어떻게 데이터를 잘 활용할 수 있을까? 이 부분에 대해 활용 지침 위주로 내용을 정리해볼까 생각하고 있어요

마무리

인프런에 올린 로드맵에 관심이 있다면 한번 봐주셔요. 유튜브 영상도 추가해두었어요
- 2주 동안 로드맵 화면에서 쿠폰을 발급 받을 수 있어요. 필요하시다면 활용하셔도 좋을 것 같아요.
앞으로 제가 어떤 일을 할지, 어떤 커리어를 밟을지 잘 모르지만 지금 상황에 진심을 다해 하나씩 해볼 예정이에요. 지금의 시간이 참 소중하기에.
제게 궁금한 내용이 있다면 무엇이든 말씀해주셔요. 이 글에 대한 피드백도 좋아요. 제가 답이라는 것은 아니고, 제 생각을 공유했으니 여러 이야기를 나누며 합쳐보고 싶네요.

글 작성하는데 걸린 시간 : 약 40분

2023년 회고 - 기억하고 싶은 14가지

Sun, 31 Dec 2023 00:00:00 +0000

2023년도 이제 마무리할 시기가 다가옵니다. 여러분들의 2023년은 어떠셨나요?
매년 이 시기엔 1년을 마무리하며 회고하고 있습니다. 회고의 목적은 제 1년을 간단히 글로 정리하기 위한 목적과 누군가 저의 2023년(저의 7년차)에 대해 물어보면 공유하기 위한 목적입니다
- 이 글을 보시는 분들도 여러분들의 1년을 생각하시면서 읽으시면 좋을 것 같아요
- 저는 회고 글을 작성하기 전에 과거에 제가 작성한 회고 글을 보고 글을 작성하곤 합니다. 과거의 기록이 매우 소중하단 생각이 들어요
2023년의 회고 글은 기억하고 싶은 사건 위주로 작성했습니다
과거 회고 글 모음

2023년 - 기억하고 싶은 것

1) 인프런 첫 강의 출시
2) C 레벨 코칭
3) 멘토링
4) 데이터팀 코칭
5) 번아웃
6) 번아웃 회복
7) 글또
8) 컨퍼런스 발표
9) 생산성에 대한 고민
10) 독서
11) 꾸준함 & 열정
12) 노코드
13) 새로운 장소
14) 새로운 물건

1) 인프런 첫 강의 출시 - PM을 위한 데이터 리터러시

인프런에 첫 강의(PM을 위한 데이터 리터러시)를 2월에 런칭
강의 촬영, 영상 편집, 강의 업로드, 강의 자료 제작, 추천사 받기 등 여러가지를 혼자 진행하면서 힘든 점도 많았지만, 성취를 이룬 활동
- 힘들었던 것은 (자신이 정한) 마감이 다가오는데 아직 덜 완성했다는 점이였다. 촬영도 엄청 하고 목도 쉬고 편집도 하고 거의 하루 종일해도 시간이 부족했다. 그래도 이 때의 경험이 스트레스 드리븐 성장이라고 생각하며 진행했음. 강의를 준비하다보면 자꾸 완벽주의가 발동해서 이 완벽주의를 어떻게 승화할 수 있는지가 핵심인 것 같음. 생각해보면 강의 뿐만 아니라 삶에서도 동일하게 적용되는 관점
- 23년 12월 기준으로 강의를 런칭한지 약 1년이 지났고, 두번째 강의 촬영 준비가 거의 끝나간다. 이번엔 많이 진행했던 분야에 대한 강의인데 그럼에도 불구하고 에너지가 쓰이긴 한다. 내가 정말 찍고 싶은 강의는 이 다음, 다음 강의 쯔음부터 본격적으로 시작될 것 같다
- 강의 촬영을 더 쉽게 하기 위해 여러 시도를 하고 있다. 장비를 수정하고, 매크로를 만들어서 더 빠르게 작업한다던지 등. 어느정도 경험이 쌓이면 이것도 나중에 공유를 해야겠다
- 그래도 준비를 열심히 해서 강의는 잘 나왔고, 여태까지 약 천명이 수강하고 계신다
위 경험을 했기에 인프런에서 강의 만들기, 온라인 강의 만들기 경험 정리 글을 작성할 수 있게 되었다. 강의 촬영할 때 경험을 잘 기록해놔서 글 작성은 어렵지 않았고, 발표 자료도 만들어서 “강의 만들기에 대한 강의”도 할 수 있게 되었다
- 강의 만들기에 대한 강의를 준비하면서 글또에 계신 분들을 강의를 만들 수 있도록 하는 “강의 만들기 모임”도 진행했다. 강의 만들기 모임도 2번째 경험하는데, 느낀 점이 많다. 강의를 정말 만들게 하기 위해 어떤 전략을 가져야 하는지 생각은 정립되었는데 조만간 실행해볼 예정. 다만 좀 빡센(?) 전략일거라 실제로 할 사람이 있을지는 의문
강의 촬영 후엔 바로 데이터 과학자 원칙 책을 집필했다. 대략 50~60쪽 정도의 내용을 작성했고 메타인지 관련한 내용을 작성했다. 데이터 과학자 원칙이라 데이터 과학이나 MLOps 이야기를 할 수 있으나 다른 저자분들과 겹칠 수 있다고 판단했고, 문제 정의나 메타인지가 높은 사람들이 팀에 오면 좋겠다는 생각에 메타인지 내용으로 작성했다. 사실 메타인지라고 했지만 어떻게 인생을 살아갈까라는 주제에 가깝다
12월엔 인프런 지식 공유자 연말 파티에 참석했다. 내 강의가 2023년 비즈니스 파트에서 제일 많이 판매되고, 매출이 높은 강의라서 최강 루키상을 수상했다
- 이 때의 경험이 내게 더 열심히 강의 자료를 만들게 하는 동기를 주었다
- 연말 파티 마지막에 나와 비슷한 상황(퇴사하고 강의 만드는 일을 전업으로 하시는 상황)인 김영한님과 20~30분 정도 대화했다. 나도 열심히 해야겠다란 생각이 들었다

2) C 레벨 코칭

마이루틴 대표님과 점심을 먹다가, 제안을 주셔서 CEO 코칭을 시작하게 되었다
- 3월부터 12월까지 진행했고, 2주에 1번씩 방문하는데 벌써 9개월이나 지났다
- 처음보다 더 친해지고 서로의 특징을 잘 이해하면서 코칭의 효과가 극대화가 되고 있다. 사람의 고민은 반복되기도 하는데 그 부분을 캐치해서 전달하고 정리해드리고 있다
- 내 개인적인 특징은 발산보단 수렴에 능한 사람이다. 생각보다 발산을 하는 사람들이 많은 것 같은데, 이 사이에서 수렴형 코치로서 생각을 정리할 수 있도록 돕고 있다. 멘토링, 코칭 등을 하면 고민들이 정리되고, 앞으로 Action Item이 잘 나온다는 피드백을 받고 있다.
- 대표님의 고민을 들으며 대표 입장에서 어떤 고민을 하는지 간접적으로 배우며 나도 사업을 하는 느낌을 가질 수 있어 배우는 점이 많다. 그래서 더 잘 되도록 돕고 싶은 마음
C 레벨에게도 멘토, 코치가 필요하다. 아니 오히려 꼭 필요하다
24년엔 C 레벨 코칭을 하는 경험을 더 늘려보고 싶다. 다른 분들은 어떤 고민을 하고 있을지 궁금하고, 변화를 만들기 위해 어떻게 접근해야 하는지에 대한 다양한 경험을 하고 싶다
내년엔 도전적인 시도를 하면서 새로운 역할도 해볼 것 같다. 직무 이름도 떠오르지 않는 역할인데, 이러면서 나의 강점이 더 발현될 것 같다

3) 멘토링

올해 멘토링을 얼마나 했는지 확인해보니 총 70회 진행했다(위 CEO 코칭 제외)
- AC2, 인프런 강의 멘토링, 글또, HOC, 전직장 동료들이 주를 이룬다
AC2 멘토링(44기, 45기, 46기)
- AC2 43기를 끝내고, 배운 것을 삶에 적용하다 정신 차리니 다음 기수가 시작되었다
- 퇴사 후엔 주기적인 멘토링을 할 기회가 적은 상황이고 어떤 분들이 참여하는지 궁금해서 멘토로 신청했고, 3분의 멘티를 모셨다.
- 멘티 선정하는 과정에서 다각화 전략을 세웠다. 멘티분들의 상황이나 경험이 모두 달랐고, 그분들의 이야기를 듣고 도움을 드리는 것도 큰 볼마이였다
- 그리고 이 세분이 46기 멘토로 참여하셔서 멋진 분들이라 생각했다. 너무 잘하고 계신다
인프런 강의 멘토링
- PM을 위한 데이터 리터러시 강의를 70% 이상 수강하면 45분 코칭을 해드리고 있다(선착순 100분)
- 총 26분과 이야기를 나눴으며, PM을 위한 데이터 리터러시 강의 코칭 후기 채널에 많은 분들의 후기가 존재한다. 후기 일부만 공유
- 강의를 수강하신 분들이 코칭을 통해 개인적인 고민을 해소하고 하나씩 행동하길 바라는 마음을 가지며 코칭하고 있다
글또
- 글또 내에서 직접적인 멘토링을 하는 경우도 있고, 간접적인 멘토링을 하는 경우도 있다
- 직접적인 멘토링은 주로 운영진이거나 따로 연락을 주시는 분들과 진행한다. 커피챗 요청이 많이 오는 경우엔 다른 분들과 같이 모여 고민 상담소를 운영하기도 했다
- 간접적인 멘토링은 대나무숲에 올라오는 질문에 답변하는 과정. 대숲에 많은 분들의 고민이 담겼는데, 어떻게 해야 도움이 될까를 생각하며 공유하고 있다
- 다른 곳에서 하는 것과 동일하게 임하고, 어떤 행동 변화를 만들지를 주로 초점을 만들고 그 변화에 글또를 활용할 부분이 대부분 존재한다. 그런 것을 넛지하고 있다. 이 경험이 좋아서 멘토링을 하신 분들이 그 다음 기수 운영진 활동을 하고 싶다고 하는 경우가 종종 있다
Action Item
- 멘토링을 하다보면 반복적으로 나오는 고민이 있고, 나도 반복적으로 이야기하는 내용이 있음
  - 이 내용을 추상화해서 영상이나 문서로 정리해보기
  - 인스타그램에 이미 자료를 만들어서 제공하기도 했음
- 주기적으로 멘토링을 할 수 있는 환경을 만들기
  - 열심히 하는 분들을 지원하는 환경이 필요하다
  - 여태까진 글또에서 진행했고, 그 이후엔 어떻게 할지 고민해보기

4) 데이터팀 코칭

2023년엔 강남언니, 당근 데이터팀 코칭을 진행했다
- 강남언니와 당근에서 요청한 문제는 모두 달랐지만, 둘 다 경험했던 부분이라 가장 코어에 있는 문제부터 접근했다
데이터팀 코칭을 하는 이유는 한국의 데이터 조직이 일을 더 잘하고 성과를 내려면 어떻게 할 수 있을까?에 대해 생각하다 시작하게 되었다
- 한국의 데이터 산업에 내가 기여한 것이 무엇인가?라는 질문을 던지고 할 수 있는 것을 하나씩 하고 있다
- 작은 규모의 회사에선 시행 착오를 확실히 덜 할 수 있는 방법이 있는데, 이 방법을 직접 알려주고 싶었다
- 강의도 이를 위한 작업 중 하나
1주일에 1번 출근해서 일을 하는 것이 나에게도 큰 활력이 된다
- 생각보다 회사에 잘 맞는 사람이라는 것을 느끼긴 하는데, 당장 24년에 취업하는 것은 크게 뜻이 없고 24년 말 정도엔 고민을 시작할 수도 있을 것 같다
데이터팀과 회사의 규모에 따라 어떤 고민을 하고 어떻게 해결하면 좋을지에 대해 떠올릴 수 있고, 예상한 내용이 얼추 맞는 경험을 하고 있다. 이 내용도 정리해야지. 정말 작성할 컨텐츠는 많다. 작성만 하면 된다
당분간 계약한 회사는 없어서 인프런 강의 만들기에 집중할 예정
데이터팀 코칭을 요청한 곳과 미팅해서 아직 이르다고 판단하면 인프런 강의 수강을 권하고 있다. 금액 투자는 적절한 시기에 해야하는데 그 시기가 오지 않았을 때 참여하면 둘 다에게 힘든 경험일 수 있어 이런 방식을 채택하고 있다

5) 번아웃

강의를 런칭한 후, 1차적인 목표를 이루어서 방황을 하며 삶의 의미가 희미해졌다
- 감정 곡선이 보통 평온한 편인데, 음의 기울기가 생기기 시작했다
- 강의 런칭 후 다음 목표를 위한 행동을 해야하는데, 일단 쉬어보자(보상 심리) + 강의 촬영하는 과정이 힘들어서 회피. 이 두가지가 결합되어서 번아웃처럼 나타났다
- 퇴사 후 6개월이 지났고, 혼자 사업하는 시점이라 어떻게 해야할까에 대한 불안함이 존재했던 것 같다
- 최근에 모든 상황에 무덤덤하다면 나도 혹시?! - 오은영의 금쪽 상담소를 봤는데 공감되었다. 100%는 아니지만 이와 비슷한 상황이였던 것 같음
감정적으로 힘든 시기가 있었는데, 이 땐 안정액을 먹으면 평온해졌다. 때론 이렇게 나의 상태를 회복해줄 수 있는 약이나 음식도 알고 있으면 좋을 것 같다
나도 사람인지라 번아웃이 올 수 있다고 생각하며 살고 있는데 이번 번아웃은 정말 조용하게 일상을 잠식했고, 그만큼 감정의 골이 깊었다
요즘 생각해보면 목표나 소신을 조금 더 생각하며 살았으면 괜찮을 것 같다. 물 흐르듯 살자~라는 마인드여서 이런 감정이였나?라는 생각도 든다. 하지만 지나간 일이니 앞으로 또 오면 잘해야지!라는 생각이 든다

6) 번아웃 회복

번아웃에 빠지면 뭐 해야할까? 뭐 번아웃 해치워야지! 라는 생각을 했다
다만 7월엔 아무것도 하지 않고 그냥 누워있었고, 그렇게 시간이 흐르니 뭐라도 해야겠단 생각이 들었다
- 7월 중순부터 에너지 레벨을 올리기 위해 여러 시도를 했다
- 번아웃에 빠지고 그냥 아무것도 안하고 한달 보내면 “내가 뭐하고 있는건가?”라는 생각이 든다. 그래서 오히려 이런 시기에 푹 쉬고 아무것도 하지 말라고 권하고 있다
(1) PT를 시작했다. PT는 지금도 하고 있다.
- 운동을 하면서 체력을 키우고 운동하는 시간엔 다른 생각이 거의 나지 않아서 시작했다
- 생각보다 시키는 일을 꾸준히 하는 편이라 (아침에 운동가기 싫지만) 가면 1시간 반 정도 운동하다 온다
- 하반기부터 시작한 PT. 39회 받았다
(2) 우쿨렐레를 배우기 시작했다
- 7월에 글또 8기 운영진 마지막 모임을 이태원에서 진행했다. 이 때 옥상에서 기타치며 시간을 보냈는데, 나도 악기 해봐야지! 생각하다가 귀염뽀짝(?)한 우쿨렐레를 시작했다
- 아직도 여전히 부족하지만 우쿨렐레 1-2곡만 칠 수 있어도 행복하다. 베짱이가 된 느낌이랄까? 이렇게 하루 하루 치고 싶은 곡을 치며 사는거지~ 라는 마음으로 살았다. 꽤 행복하다
- 가끔 급한 상황이 된다면 바로 우쿨렐레를 친다. 박자를 맞춰야 해서 감정이 여유로워진다
(3) 아무것도 하고 싶지 않고, 그냥 쉬고 싶어서 남해로 떠났다
- 시골에서 시간을 보냈는데, 그 때 정자에 계신 할아버지 할머니와 대화하면서 여유가 생기기 시작했다. 인생이 다 그런거군~ 이런 생각하며 회복하려고 했다
(4) 도식화
- 어느정도 기운이 올라왔을 때, 번아웃에 빠질 때 내가 앞으로 어떻게 행동하면 좋을지 원칙을 시각화했다
- 요즘 자주 진행하고 있는 루틴인데, 어떤 상황이 반복될 것 같고 에너지 레벨이 많이 쓰인다면 항상 나의 철학, 원칙을 시각화해둔다
- 번아웃에 빠졌을 때 회복하기 위한 철학으로 결국 내가 어떻게 살고 싶은가, 어떻게 행동해야 할까를 작성했다. 앞으로 다시 번아웃이 온다면 이 흐름대로 따라가면 회복될 것
(5) 열심히 사는 사람들이 있는 커뮤니티 활동
- 에너지를 올리기 위해선 에너지가 있는 사람들과 같이 지내는 것도 좋은 방법이다
- 내가 운영하고 있는 글또에선 운영자 입장이라 더 편하게 참여자 입장에 있고 싶었다
- 그래서 참여한 모임은 HOC와 독한 사업가 모임
- HOC는 인스타그램을 매일 올려야 하는 활동이 있고, 사업가 모임은 독서, 루틴, 경험 공유 활동이 있었다. 두 활동이 겹치는 일정이 없어서 같은 시기에 참여할 수 있었다
  - HOC는 열심히 사는 사람들이 참 많고, 이런 열정을 나도 다시 가져와야겠단 생각을 했고 에너지 레벨이 오르는 것이 느껴졌다. 이 때 인스타에 내가 가지고 있던 암묵지를 많이 명시적인 컨텐츠로 만들었다
  - 사업가 모임은 세상에 다양한 비즈니스가 많고, IT에 한정하지 말고 더 넓게 봐야겠단 생각을 하게 해주었다
- 둘 다 좋은 커뮤니티여서, 그 안에서 내가 기여할 수 있는 것들을 진행했다
- 내가 회복할 수 있는 도움을 준 커뮤니티다. 너무 고마운 곳
결론적으론 9월부터 에너지 레벨이 다시 올라왔다. 7-8월에 에너지가 바닥이였다면 9월엔 많이 회복되었다
- 에너지가 없는 분들이라면 에너지를 너무 급하게 올리지 않으면 좋겠다
- 다 그런 시기가 있는 것 같다. 에너지가 낮다가 울적하다가 올라오다가 그런다. 즐거운 일을 맞이할 준비를 하면 된다
- 너무 복잡하게 생각할 필요가 없다. 지금 제일 떠오르는 생각이 무엇인가? 그럼 그걸 먼저 해라. 일단 하고 나서 나중에 고민해도 충분하다.
  - 쉬는 것이 떠오르면 그냥 푹 쉬어라. 세상 누구보다 부럽도 열정적으로 쉬어라. 아마 이런 고민을 하는 사람이라면 푹 쉬면 다시 ‘아 해야할 것 같은데?’라는 생각을 할 것이다(=제 이야기)

7) 글또

2분기 막바지와 3분기 시작할 시점엔 글또 8기 오프라인 모임인 반상회에 참여했다. 빌리지 반상회 준비위분들이 잘 진행해주셔서 무탈하게 끝났다
- 이젠 이런 행사를 준비하는 것도 프로세스가 생겼다. 이 부분은 글또 운영진 노션에 프로세스 문서로 남겨져있다
- 나중에 커뮤니티 7년 운영을 하며 느낀 점을 강의로 만들면 커뮤니티를 만들고 싶은 분들에게 도움이 되지 않을까 싶다. 심리학이나 조직이론, 나의 경험 등 많은 것을 포함한 강의가 될 것 같다(언제 찍을지는 미지수..^^ 수요가 있다면 말씀해주세요)
글또 9기 시작
- 이번엔 450명이 참여하시는데, 더 좋은 커뮤니티를 만들기 위한 Action Item을 하나씩 하고 있다
- 커뮤니티 = 프러덕트로 생각하고 있는데, 위에 말한 커뮤니티 강의에서 글또를 어떤 관점으로 해석했는지 공유해도 재밌을 것 같다. 가볍게 글또 내에서 공유하는 것도 방법일 것 같다
- 운영진분들도 많이 계셔서 커뮤니티가 잘 운영되고 있고, 대나무숲에서 나오는 많은 고민이나 각자의 경험, 소모임 채널, 글쓰기 채널, 커피챗 등 다양한 활동이 자발적으로 나오고 있어 활동하는 분들이 멋지단 생각을 하고 있다
- 자동화 봇도 정말 많아지고 있다. 세계관이 확장되고 있고, 스티커 만들어야겠다
- 그래도 글또는 10기까지 할 예정..ㅋㅋㅋ… 이 부분은 내년 중반에 더 생각하기로 했다

8) 컨퍼런스 발표

데이터야놀자에 혼란한 세상에서 만든 나만의 성장 방정식라는 제목으로 오랜만에 오프라인에서 발표했다
- 이 날 지인 결혼식이 북서울 꿈의 숲에서 있었고(비도 옴) 그 후에 역삼에서 발표를 해야해서 체력적으로 힘들었지만, 잘 마무리했다
내 최근 이야기도 담았고, 어떻게 해야 나만의 길을 만들 수 있을까에 대한 내용을 전했다
- 7년의 커리어를 전체적으로 설명해주는 발표는 거의 보지 못했다. 어떤 길을 지나왔는지를 알게 된다면 다른 분들이 커리어를 설계할 때 참고할 수 있을 것이라 생각했다
많은 분들이 발표장에 와주셨고, 바닥에 앉아서 듣는 분들도 계셔서 더 전달력을 신경썼다
부스트캠프 AI Tech 수료생분들이 오셔서 선물과 카드를 주셨는데, 너무 감사했다
오랜만에 오프라인 발표를 하니, 발표를 하면서 성장하고 나눌 수 있는 발표 드리븐 성장을 종종 더 해야겠다는 생각이 들었다
- 기존엔 이젠 다른 사람들이 발표하면 좋겠다고 생각했는데, 나도 여전히 발표할 내용이 가득하다. 이 내용을 풀어야겠다
- 발표 => 보람 => 성취 => 재생산의 흐름이라고 볼 수 있다

9) 생산성에 대한 고민

번아웃에 회복하면서 나의 생산성에 의문을 가졌다. 자리엔 앉지만 효율이 낮은 경우가 많았다
- 시간 관리를 하기 위해 RIZE를 사용해보고, RIZE 사용 방법 글도 작성했다
- 모든 것이 데이터로 바뀔 수 있기에 내가 하는 대부분을 데이터로 기록하고 있다
심지어 운동이나 나의 맥박 데이터도 Whoop 밴드를 통해 데이터화하고 있다. 수면 데이터, 수면의 질도 측정하고 있다(글루코핏에서 혈당 측정도 해본 적도 있다)
요즘엔 STREAM DECK 플러스를 구입해서 쓰고 있다. 스트림 덱의 버튼을 누르면 여러 작업이 진행된다
- 단축키를 외울 필요 없이 하려고 하는 일에 더 집중할 수 있다
- 약간의 러닝 커브가 있지만, 추후에 싹 정리할 예정
- 영상 편집할 때도 스트림 덱 플러스를 사용하면 더 빠르게 편집할 수 있을 것 같아 곧 시도 예정
생산성을 강화하도록 도와주는 SaaS가 있다면 적극적으로 구매하고 있다
- Keyboard Maestro도 곧 구매해서 사용할 예정(자동화 도구였는데 이제 알았다)
ChatGPT도 생산성 상승에 큰 도움이 되고 있다
- 혼자 고민하는 시간에 GPT와 이야기해서 더 빠르게 논의를 마무리하고 무엇을 할지를 결정하곤 한다
항상 능률이 좋아야하는 것은 아니고, 생산성이 항상 높아야 하는 것은 아니다
- 다만 내가 생산성을 높이고 싶을 떄, 내가 내 환경을 통제하고 싶어서 이런 생산성에 대해 고민하고 있다
- 내가 어디까지 갈 수 있을까 기대된다

10) 독서

즐겨보는 유튜브 채널인 BZCF 운영자분이 독서 모임을 진행한다고 하셔서, 궁금한 마음에 참여했다. 굉장히 만족스럽다
- BZCF 독서 모임에 참여하면 질문을 던져주시는 점이 좋다. 이 질문을 토대로 내가 생각해보게 되는데, 내가 생각하는 질문과 비슷할 때는 흥미롭기도 하다
- 이번 회차엔 정말 책 읽고 이야기만 나누었는데 다른 업계 분들도 많아서 다음엔 더 이야기를 해봐야겠단 생각이 들었다(참여할 때 다른 분들은 투자 업계가 많았던 것 같고, 나만 개발/AI였다)
- 내가 항상 누군가에게 질문을 던지는 사람이였는데, 이렇게 질문을 받는 사람이 되어서 좋았다
23년에는 책을 15권 정도 읽은 것 같다. 평소에 비하면 적은 양인데 올해는 뭐 그런 시기였다라고 생각한다
- 최근엔 광진 정보도서관에서 상호대차 기능으로 도서관에 있는 책을 빌릴 수 있는 것을 알게 되었다. 도서관에 가지 않아도 책을 빌릴 수 있어 더 많이 활용할 것 같다

11) 꾸준함 & 열정

BZCF 유튜브 채널은 최근 구독자 5만을 넘겼다. 구독자가 중요한 것은 아니고, 1년 동안 영상을 올리지 않은 날이 얼마인가?라는 질문을 해주셨다
- 그에 대한 답은 0일이였다. 팀이긴 하지만 꾸준히 진행하고 있었던 것이다. 나는 과연 이렇게 꾸준함을 가진 일이 최근엔 무엇이었나 생각했다
- 다시 꾸준하게, 작은 행동을 하나씩 하기로 다짐했다
재즈바에서 드러머분의 솔로 무대가 봤는데, 1분간 정말 열심히 치셨다. 드럼 자체를 좋아하고, 사랑하고, 흠뻑 몰입하고 있다고 생각했다
- 정말 너무 멋지고 나도 저렇게 뜨겁게 살아본 적이 있는가 생각했다
- 이 이야기를 하니까 지인이 블루 자이언트를 알려줘서 봤는데 매우 인상 깊은 애니메이션이다. 재즈 관련 애니메이션인데 보지 않으셨다면 보는 것을 추천
아이유의 유튜브 채널에 올라온 IU TV - 아이유 광고 첫 비하인드 영상을 보니 아이유님은 일정도 많으시고 계속 시도한다. 더 시도할 수 있는 동기가 궁금하기도 하고, 미아 시절부터 봤던 가수라 팬심이 가득하다. 나와 일주가 같은 정유일주라 응원한다(?)
나는 이렇게 꾸준함과 열정을 가지고 일을 했던 적이 있는가? 스스로 질문하며 내년엔 이 부분을 더 강화해야겠다 생각했다

12) 노코드

최근에 앱 개발을 하고 싶어서 고민하다가, 노코드 툴을 찾아보고 있다
마음에 드는 도구는 FlutterFlow인데, 앱 개발을 바닥부터 하는 것은 시간이 많이 소요되고 조금 더 빠르게 프로토타입을 만들어서 써보고 싶다
- AI도 발전하면서 점점 더 개발 속도가 빨라지니, 이런 도구도 써보는 것이 필요하다 생각
노코드 도구도 워낙 많아서 선택에 어려움을 겪는데 내년 초에 자세히 탐색하고 앱을 만들어야겠다

13) 새로운 장소

시드니
- 시드니의 자연이 얼마나 좋은지 깨달을 수 있었고, 이 때 “조금은 여유를 가지고 살자”라는 생각을 했다. 여유를 가지고 사는 사람들이 보였고, 이 때가 모든 마감 직후라서 더 크게 느꼈다
- IT 인프라는 그렇게 좋지 않다는 느낌을 받았다. 만약 해외로 취업한다고 하면 시드니는 애매할 수도 있겠다고 생각했다. 가보진 않았지만 싱가포르가 나을 것 같다
맹그로브 고성
- 넬슨, 맥스와 한번 가고
  - 이 때 처음으로 가리비를 먹었는데 정말 좋았고 밤에 일을 할 수 있었다
- 석주님, 종원님, 상효님과 두번째로 갔다
  - 4인으로 가니까 할 수 있는 일도 많았고 고성이 더 좋아졌다. 앞으로 고성을 자주 갈 것 같다. 그래서 맹그로브 고성 글도 작성했다
태강, 성동이와 강릉에 갔다
- 래리가 회고 여행으로 갔던 곳이라고 했는데, 숙소가 멋있었다. 사장님이 인테리어에 감각이 있으신 것 같았다. 친구들은 재택하고 나는 강의 자료를 만들었다
내년엔 어디를 가볼까 생각 중이다. 아직 일본도 가보지 못한 사람(?)이라 일본이나 싱가폴 등을 가볼까 생각 중이다
- 미국에서 진행되는 컨퍼런스도 보고 있는데, 구글 컨퍼런스가 내년 4-5월에 있다고 해서 고민 중이다. 물론 고민만… 영어가 익숙하지 않아 혼자 가면 엄청 힘들 것 같아 같이 갈 사람이 있으면 좋겠다고 생각하는 중

14) 새로운 물건

원래 무소유를 즐기는 성격인데, 최근에 뭔가 많이 구매했다. 나의 삶의 질이나 생산성을 바로 올릴 수 있는 것엔 비용을 아끼지 않고 투자한다
제로웰 가습기
- 기화식 가습기를 처음 구매했다. 목이 너무 자주 부어서 이걸 해결하고 싶어 샀는데, 잘 동작한다
- 방이 작아서 큰 것보단 공기 청정기도 구매되는 버전으로 구매했다. 공기의 질도 더 좋게 만들고 싶었다(비염이 있기에)
- IoT 기능이 있어서 밖에서도 제어할 수 있는 점과 편하게 세척할 수 있어 좋다
경동나비엔 카본매트
- 잘 쓰고 있던 전기 장판이 고장났는데, 정말 추운 날이여서 급하게 구매했다
- 이것도 IoT 기능이 있고, 5도 단위로 조절할 수 있다
- 기능이 엄청 좋아서 만족하고 있다. 잘 때 숙면을 취할 수 있다
스트림 덱 플러스
- 위에서 잠깐 언급한 스트림 덱 플러스
- 자주 누르는 버튼, 매크로를 등록하기 위해 구매했다
- 점점 단축키가 많아져서 기억하는게 어려워진다. 이제 원클릭으로..
시디즈 발 받침대
- 좋은 의자도 중요하지만, 발 받침대도 꽤 중요하다
- 좋은 자세를 유지하고 생산성을 올리기 위해 발 받침대를 구매했다. 이 발 받침대가 정말 좋다. 다른 발 받침대는 밀리곤 하는데 이건 알차다
- 가끔 위쪽에 다리 쭉 뻗고 있으면 편하다
아리아리 미니 청소기
- 페이스북에서 좋다는 후기를 보고 구매한 미니 청소기인데 이게 정말 내 삶의 질을 크게 올려주었다
- 나는 청소할 때 힐링을 받는 편인데, 이 청소기를 수시로 사용하는 편
- 깔끔한 것을 좋아하는데 큰 청소기를 쓰기 어려운 책상 등을 청소할 때 쓰는 중
- 아침에 일어나서 먼지를 청소기로 쓰윽 하는 것이 행복이다(왜인진 모르지만)

2023 정리 & 다짐

회고를 쓰다보니 자주 나오는 단어가 있다
- 하나씩, 꾸준히
- 컨텐츠
- 도움
- 시도
- 이 4가지가 결국 나의 정체성이라 생각한다. 각각을 더 잘하기 위한 시도를 해보기로
- 결국 나는 다른 사람들을 돕고, 그 사람들의 변화를 볼 때 보람을 느낀다. 어떻게 보면 코치, 교육자가 천직인 것 같다
장기적 안목의 중요성
- 삶을 살다보면 결국 내가 어떤 마음을 가지며 살아가는지가 중요하다. 세상은 참 혼란하고 어렵고 고난도 많다. 그런 상황에 하나씩 일희일비 하는 것보단 자신만의 신념, 장기적 관점을 가지고 있으면 좋다
- 어떻게 보면 소신으로 볼 수도 있고, 어떻게 보면 나의 삶의 비전이라 볼 수 있다
- 제프 베조스 발명과 방황에 나오는 주주서한을 보면 장기적 안목, 소신에 대한 중요성을 느낀다. 이 부분을 내 삶에 적용하고 있다
- 지금 스몰 자이언트가 온다라는 책을 읽고 있는데, 이 책에서 이런 내용이 나온다. 책을 읽고 내 관점으로 적용해서 블로그 글에 올려두어야겠다
올해는 번아웃에서 빠져나오는 것이 제일 중요했다. 이를 잘 해냈고, 그렇기에 잘 보낸 해라고 생각한다
- 때론 살다보면 레벨업에 많은 경험치가 필요한 시기가 있고, 성과가 없어 보이는 시기가 있다. 그 시기가 지금이라 생각한다
- 삶을 바라보는 태도 - 인생을 게임처럼 이와 같이 생각하니 마음이 편해졌다
- 나의 성장 방정식에서 성장 곡선이 일직선인 해지만 그런 시기도 있는 법이니 너무 걱정하지 않아도 괜찮다
  - 이걸 보는 분 중에 올해가 너무 힘들거나, 답답하거나 그러시면 괜찮다. 내일부터 새로운 Phase가 시작된다고 생각하면 된다. 전직 직전인 것이다. 과거를 어떻게 할 수는 없으니 과거보다 미래를 바라보자.
  - 당신은 할 수 있고, 바라는 것이 당신을 찾아올 것이다
  - 안티프래질한 상황에서 적절히 대응하면 된다. 모든 것을 하려고 하지 말고, 하나씩 천천히 대응해도 괜찮다. 관련한 글 : 불확실한 상황의 의사 결정 원칙(feat. 안티프래질)
- 오히려 앞으로가 더 기대된다
- 이 내용을 회고에 올리지 않고 숨길 수 있었지만, 공개하는 이유는 저도 사람이라 이런 상황이 올 수 있고, 오는 것은 문제가 아니고 이것을 잘 해결하면 된다는 점을 말해주고 싶었다. 우리는 살다보면 나의 취약점이나 부끄러운 점을 공개하지 않을 수 있는데, 이런 점도 나의 하나니 나를 사랑하고 그리고 개선하고 싶으면 개선하면 된다. 해결하는 과정을 보여주고 싶어서 회고에 추가했다
24년엔 Input보단 Output을 더 많이 만들어보기
- 세상엔 참 Input이 많다. 그래서 실행력이 떨어지는 경우도 있다
- 그냥 Output을 만들고, 또 만들어보기
- 주간 회고 + 글 정리하는 루틴을 만들어서 3주 연속으로 잘 달성하고 있는데 이것을 꾸준히 해보기
- 발산보단 내가 잘하는 수렴을 해보기. 수렴하면서 하나씩 만들기
일단 지금 떠오르는 구체적인 아이템
- 나의 원칙을 더 잘 정리해서 한 권의 책으로 정리해보기(웹에 올리는 책. 실물 책은 에너지가 많이 소요됨)
- 나의 원칙을 영상으로 올리기 => 유튜브
- 24년엔 개발을 더 진행하기
- 강의 2-3개 만들기
- 글또 커뮤니티 운영 7년 정리하기
- C 레벨 코칭 2-3분 더 진행하기

글 작성하는데 걸린 시간 : 약 4시간
- 하고자 하는 이야기, 개요 정리 : 30분
- 초안 글 작성 : 3시간 10분

삶을 바라보는 태도 - 인생을 게임처럼 살아보기

Sun, 17 Dec 2023 00:00:00 +0000

키워드 : 인생의 태도, 게임처럼 살자, 인생을 게임처럼, 삶의 태도
인생을 바라보는 태도
- 인생을 살다보면 다양한 경험을 하기도 하고, 좋은 일도 있고 힘든 일도 존재합니다
- 최근 받은 질문 : 힘들 때 어떤 생각을 하시나요? 벅찬 세상을 어떻게 살아가야 할 지 모르겠어요
- 이 부분에 대한 답은 저도 정확힌 알 수 없지만, 점점 살다보니 저만의 삶을 바라보는 태도, 원칙 만들어졌어요
- 이젠 인생을 바라볼 때, 게임처럼 생각하는 습관이 생겼습니다
이 부분에 대해 공유할게요. 이 글을 읽으실 때 “여러분들은 어떤 상황이지?”를 생각하면서 읽으시면 글에 더 몰입할 수 있을거에요
- 이 글은 옳다 그르다를 말하는 것이 아닌 제 경험담을 공유한 것이라 보는 사람마다 생각이 다를 수 있어요. 다른 의견은 댓글에 남겨주셔요 :)

인생을 게임으로 생각하기

제가 좋아하는 게임
- 턴제 RPG 게임. 예를 들어 환세 취호전, 포켓몬스터 골드, 최근 즐겁게 했던 게임은 닌텐도 스위치의 파이어 엠블럼 풍화설월
- 유년 시절 많이 했던 게임 : 다크세이버, 바람의 나라
- 어렸을 때 위와 같은 게임을 정말 좋아했고 새벽 4시까지 하다가 부모님께 혼난 적도 정말 많았음
- 다크세이버는 9단, 10단을 찍을 정도로 랭커까지 했고, 바람의 나라도 꽤 즐겼음
- 이런 게임을 많이 해서 현실도 일종의 턴제 게임 아닌가?라는 생각을 하게 되었음
게임의 대표적인 요소
- 턴
- 레벨
- 장비
- 사냥터
- 퀘스트
- 보상
- 파티, 문파
- 이벤트
- 전직
이 요소들을 실제 인생에 적용해 생각해보기

턴

한 턴에 한가지 행동을 해야 하는 게임들이 존재(포켓몬스터 게임을 생각해보면 이해하기 편함)
우리의 인생도 시간이 24시간 한정되어 있기에 일종의 턴을 가지고 있다고 생각
턴을 어떻게 활용하는지에 따라 앞으로가 달라지게 되며, 우리의 인생도 시간 관리를 어떻게 해야하는지가 중요함

레벨

레벨은 나의 역량, 신체 능력 등을 포함하는 내용
예를 들어 내가 운동을 하면서 테니스 랠리를 많이 할 수 있게 된다거나, 헬스에서 100kg 스쿼트를 한다거나 등
- 다만 수치로 모든 것이 보이진 않으며, 레벨도 숫자로 표시하는게 어려울 수 있음
- 데이터야놀자에서 발표했던 혼란한 세상에서 만든 나만의 성장 방정식 발표에서 말한 것처럼 정확히 레벨을 표시할 수는 없지만 어림잡아 자신의 상황을 알 수 있음
현실과 게임의 차이점은 나의 역량이 수치적으로 나오지 않는 점. 이 부분이 어렵지만, 얼추 계산을 해볼 수 있음
- 내가 할 수 있는 일은 무엇인가?
- 내가 운동을 하면 몇시간 정도 피로 없이 할 수 있는가?
정확히 정의하지 못해도 괜찮고, 나의 레벨이 있다 정도로 알고 있거나 내가 할 수 있는 일, Task의 갯수를 생각해봐도 좋음(시간이 지날수록 할 수 있는 경험들이 늘어나는 것은 숫자로 표시할 수 있음)

장비

레벨이 있고, 나의 Stat이 존재함
- 이를 보완하기 위해 장비 개념이 존재함
무기, 방어구, 장신구 등 다양한 종류로 존재하며, 레벨업을 하면서 무기를 점점 바꾸게 됨. 무기를 착용하기 위해 필요 레벨, 힘 등이 있으며 세트 아이템이 있어서 시너지 효과도 나곤 함
- 인생의 무기는 자신의 강점. 문제를 해결하고 사냥터에서 일을 하기 위한 것
- 레벨을 나의 역량이라고 생각하면, 무기는 내 암묵지로 쌓인 노하우, ChatGPT을 들 수 있음
- 내 무기는 무엇인가? 내가 제일 잘하고 어떤 문제를 해결할 때 잘 하는가?
- 게임에선 레벨업을 하면서 무기를 변경하지만(하나의 무기만 착용이 가능하다는 암묵적 룰)
- 인생에선 무기를 변경하는 것이 아니고 누적으로 쌓임(경험, 노하우)
- 여러개를 착용할 수도 있음
- 누적으로 쌓이지 않는 것도 있음. SaaS 제품(ChatGPT)
방어구는 나를 방어하는 관점으로 생각할 수 있음
- 심리 상담
- 취미 생활
- 요가
- 운동
장신구는 사주..? 애플 워치?
장비를 강화시키는 게임도 존재. 강화할수록 점점 깨질 확률도 존재하지만 인생에선 무기가 깨지진 않음. 그렇다면 무조건 시도하는게 이득
- 장비를 강화하기 위해 어떤 경험을 해야하는가? 퀘스트를 깨서 재료를 수집해야 함. 즉, 퀘스트를 통해 내 무기가 생기는 것. 지금 하고 있는 경험들이 나의 무기가 될 수 있음
시기에 따라 장비를 바꿀 수도 있고, 현재 나의 장비에 대해 생각하는 것이 핵심

사냥터

바람의 나라 짤로 돌아다니는 것 중 대표적인 것은 “넥슨은 다람쥐를 뿌려라”인데, 초보 사냥터가 있음
- 다람쥐, 사슴, 호랑이, 흉가 등이 떠오르며, 사냥터마다 적정 레벨이 존재함
사냥터에 비해 레벨이 너무 높으면 경험치를 덜 받고, 사냥터에 비해 나의 레벨이 낮으면 사냥터에서 사냥을 못하고 죽게 됨(?)
- 인생의 사냥터는 여러가지로 정의할 수 있지만 커리어 관점에선 회사에서 진행하는 프로젝트로 생각할 수 있음
- 회사에서 생기는 모든 일이 다람쥐고 이 몹을 죽여서(?) 경험치 및 아이템을 획득함
- 결국 회사의 업무나 프로젝트는 우리가 해야하는 일

퀘스트, 보상

모바일 게임에선 정말 당연한 개념인 퀘스트가 과거 게임들에선 선택적으로 진행되곤 했음
- 퀘스트가 주어지고, 주어진 기간 내에(기간은 잘 주어지지 않는 경우도 있지만) 특정 조건을 달성하면 퀘스트가 완료되고, 보상을 얻게 됨
인생에서 비유하면 “취업하기” 퀘스트, “프로젝트 기능 개발” 퀘스트, “MLOps 플랫폼 개발” 퀘스트, “글쓰기” 퀘스트, “잘 쉬기” 퀘스트, “여행 가기” 퀘스트, “연애” 퀘스트 등 다양한 분야에서 퀘스트가 나옴. 즉, 꼭 레벨업과 관련된 것이 아니라 여러 관점에서 퀘스트가 존재함
보상은 필수 아이템을 주는 경우도 있고, 필수 아이템이 아니여도 게임에서 필요한 것을 제공하기도 함
- 어떤 보상은 한번에 경험치를 줘서, 그 퀘스트만 깨도 보상을 얻어 레벨업을 하는 경우도 있음(즉, 보상은 늦게 한꺼번에 올 수도 있음)
매일 꾸준히 받는 보상(일일 퀘스트를 매일 꾸준히 하는 경우), 주간 퀘스트, 월간 퀘스트도 존재하며 이 퀘스트들은 꾸준히 하는 것이 핵심
퀘스트는 꾸준히 할 수 있는가, 습관 형성을 할 수 있는가와 연관되며 보상은 일의 성취, 보람과 연결

포션

게임에선 HP, 체력 개념이 존재함
- HP가 0이 된다면 캐릭터는 게임 오버를 경험하게 됨
- HP를 0이 되지 않으려면 힐링 포션을 먹거나 휴식을 통해 HP를 채워야 함
HP와 별개로 MP도 존재하는데, 이는 마나를 의미함
- 마나를 비유하자면 정신력, 멘탈이라 생각
- MP 포션도 먹으면 MP가 채워진다
이런 포션은 인생에선 병원 방문, 비타민, 수액, 건강한 음식 먹기 등으로 표시할 수 있음
HP가 0이 되지 않도록 주기적으로 적절한 휴식이 필요함
- 잘 쉬는 법에 대한 제 관점은 인스타 잘 쉬는 법에 대한 고찰 포스팅 참고

파티, 문파(길드)

포켓몬스터 같은 1인칭 게임엔 없지만, 온라인 게임에선 파티를 통해 사냥을 같이 할 수 있음
- 파티 사냥을 할 때 직업의 적절한 균형이 중요함(전사, 도사, 주술사 등)
- 같은 사냥터에서 만나서 문제를 같이 해결하는 동료일 수도 있고, 커뮤니티에서 만나는 사람일 수도 있음
문파나 길드 개념도 존재하는데, 같은 유대감을 가지는 사람을 의미
- 학교 동문, 커뮤니티 등 큰 개념
- 이 문파에서 마음에 맞는 사람들끼리 파티를 맺어 사냥하기도 하고, 예전엔 문파 내에서 만나서 실제로 결혼하는 사람들도 있다고 들음
게임에선 대부분 동시에 하나의 문파만 가입할 수 있는데, 인생에선 여러 집단에 소속할 수 있음. 다만 많은 집단을 가입하면 하나에 집중하지 못하고 정신이 분산될 가능성이 존재

이벤트

게임사에서 종종 이벤트를 하기도 함. 경험치 2배 이벤트, 골드 2배 드랍 이벤트 등
- 특정 시기에 생겼다가 사라지는 개념. 시즈널리티를 가짐
우리의 의지와 상관없이 발생하는 이벤트로 정의할 수 있음
- 2-3년 전에 개발자 연봉이 높은 것도 일종의 이벤트
- ChatGPT가 나와서 AI 분야가 발전하며 생산성이 올라가는 것도 이벤트로 볼 수 있음(ChatGPT는 장기적으로 매일 하는 이벤트 느낌)
이벤트를 통해 우리가 평소보다 더 빠른 경험을 하게 되는 것이 핵심

전직

직업을 단순히 하나만 정하고 가는 것이 아닌 전직을 하는 게임도 존재함
게임에서 전직은 하나의 카테고리 직군(전사)에서 쭉 올라가는 경우가 일반적
- 특정 게임(다크세이버)은 여러 직업 3개의 캐릭터가 합쳐져서 1개의 캐릭터가 되기도 함
- 인생에선 주니어 개발자 - 시니어 개발자 - CTO라는 것도 하나의 전직 루트라고 볼 수도 있음
- 또는 다른 직업을 하다가 그 경험 기반으로 새로운 직업을 하는 경우도 존재함. 변경할 수도 있다는 것이 핵심

정리

위에서 말한 내용을 이해하기 쉽게 이미지로 정리

인생을 게임으로 적용하기

인생을 게임처럼 생각하는 것은 많은 사람들이 하는 것이므로 아래 내용에선 User Story처럼 특정 상황에서 어떻게 생각했는지 위주로 작성
추가로 떠오르는 케이스가 있다면 업데이트 할 예정

회사에서 하는 프로젝트 = 사냥터

프로젝트나 일을 사냥터로 생각하면 어떤 일이든 나에게 경험치로 남을 수 있겠다란 생각을 함
- 비록 지금 당장은 경험치가 +5라거나 +10이라는 것이 확 나오진 않지만, 이런 부분은 한번에 돌아옴
어떤 프로젝트를 선택하느냐가 매우 중요함. 나의 레벨보다 높은 일인가? 낮은 일인가?

함께 자라기에서 나오는 개념인 몰입 그래프
- 실력에 비해 난이도가 높다면(레벨에 비해 사냥터가 어렵다면) 어떻게 해야 할까?
- 난이도를 낮추거나 실력을 늘려야 함
- 난이도 낮추기 = 다른 사냥터로 옮기기 등
- 실력 늘리기 = 다른 사람과 같이 사냥하기, 무기 바꾸기 등

회사가 싫증이 나요. 퇴사하고 싶어요

이런 경우엔 회사를 사냥터로 생각하고, 그 회사에서 얻을 수 있는 것을 모두 얻었는지 생각해봄
- 회사에서 경험할 수 있는 것들이 정말 많을텐데, 우리는 단순히 레벨업만 생각함
- 퀘스트 관점에서 다람쥐 200마리를 사냥할 경우 보너스가 있을 수도 있고, 사냥터 구석에 숨겨진 보물이 있을 수 있음
회사에 나올 때 싫증이란 기준보다 거기서 얻고자 하는 경험을 얼마나 얻었는지를 생각해보고, 그 경험을 충분히 다 하고 나오길 권함
- 히든 퀘스트가 있지 않을까? 정말 다 경험했을까?라고 생각해보기
대표적으로 개발 조직이여도 사업 조직이나 PM 조직이 어떻게 일하는지, 대표님은 어떤 생각을 하는지, 우리 회사의 프로세스는 어떤 방식으로 진행되고 있는지를 아는지 확인해봐도 좋음. 직무 관점으로만 생각하는데, 회사를 하나의 생물로 생각하고 생물의 각각의 요소에 대해 생각하고 그 부분에 대해 알아보기

저는 다른 사람들에 비해 못해서 힘들어요

다른 사람과 비교하는 것은 정말 많이 나오는 현상이고, 이것을 어떻게 바라보는게 중요
회사에서 일을 잘하는 사람을 만날 때 좌절감을 느끼는 경우도 있음
이런 경우엔 이분들이 나보다 레벨이 높은 것을 인정하고, 그 사람의 과거에 어떻게 레벨업을 했는지 물어봄
- 누구나 레벨 1인 시절이 있기에, 그 시절에 어떤 경험을 했는지 물어보면 내 상황에 적용할 수 있음
- 데이터 분석 관점에선 코호트로 볼 수 있음. 코호트 관점에서 특정 사람의 현재를 비교하는 것이 아닌 특정 사람의 특정 시점(나와 유사한 시기)을 비교하는 것이 더 좋은 방법
- 이런 내용을 물어보면 대부분 암묵지에 있거나 좋은 수련법이 나오는데, 이것을 내가 적용하면 레벨을 더 빠르게 올릴 수 있을 수 있음
컨퍼런스의 발표를 보는 것 또는 일을 잘하는 사람이 매일 하는 습관이 있다면 그것을 나도 해보는 것
만약 잘하는 사람이 근처에 있다면 큰 복. 그 사람에게 물어보고 같이 프로젝트를 해보자고 말하기. 쩔 받아서 레벨업하는 것도 능력

요즘은 그냥 다 지루해요

힘든 상황이 올 수 있음. 살다보면 힘든 상황은 당연한 일이라고 생각
- 이런 상황은 “지금 레벨업까지 경험치가 많이 필요한 시기구나”라고 생각. 그래서 지루할 수도 있고, 생각보다 잘 안될 수 있음
- 게임 상황으로 보면 HP가 없을 수도 있고, 난이도가 높을 수 있고, 그냥 경험치가 많이 필요한 시기일 수도 있음
- 지금은 전직하기 전이라서 내가 경험치가 많이 필요하구나. 이 시기를 잘 이겨내보자!라고 생각하곤 함
게임에서 의도적으로 정체기 구간을 만들기도 함. 많은 노력이 필요한 레벨업 구간
레벨이 낮은 경우엔 레벨업이 빠르지만, 레벨이 높아질수록 레벨업이 느려질 수 있음
- 주니어 시절엔 매일이 새로운 경험이기에 레벨업을 빨리 할 수 있음
점점 연차가 차면서 연차를 내리고 싶은 심정도 있고, 왜 나는 벌써 연차가 이렇게 되었지?라는 생각이 들기도 함
- 이런 것은 레벨이 높아진다는 것을 빠르게 캐치하지 못해서 그럴 수도 있음. 이런 경우라면 내가 할 수 있는 것들이 얼마나 생겼는가를 쭉 기록해보고 갯수가 증가되는 것을 보며 그냥 시간을 보내지 않았구나 등으로 생각해볼 수 있음

보상 만들기

게임에선 퀘스트를 수행하면 명확한 보상을 주곤 함. 하지만 현실에선 명확한 보상이 없는 경우도 있고, 경험치가 얼마나 되었는지 모르기에 보상이 있나?라는 생각을 하게 됨
이런 경우엔 내가 보상을 만들어줘도 좋음
- 예를 들어 지금 저는 글쓰기 퀘스트를 진행하고 있는데, 이 글을 무사히 완성하면 위스키 한잔을 마시며 게임을 하겠다!란 스스로 설정한 보상을 줄 예정
대표적으로 많이 주는 보상은 여행이 있는데, 여행을 의도적으로 활용하는 것도 방법
- 여행은 확정적인 보상으로 여행을 가기 위한 비행기를 예매하는 것부터 기분이 좋아짐. 어떻게 되어도 여행을 갈 예정이니
- 그 좋은 기분을 유지한 상태로 일을 더 잘 해낼 수 있음
- 불확실한 보상을 설정하면 불안해지기에, 확정적인 보상을 쓰는 것도 방법
단, 이런 보상은 자주 할 수는 없을 것
- 외재적 보상이 아닌 내재적 보상도 생각해보면 좋음
- 최근에 본 일과 인생이란 책에선 공헌감이라는 개념이 나옴
  - 다른 사람들이 나에게 고맙다고 하면 그것으로 내가 뿌듯하고 살아나가야 하는 힘이 생기는데 이게 공헌감과 유사한 관점이라 생각
- 이런 것처럼 외재적 보상이 아닌 내재적 보상도 스스로 만들어보기
스스로 하고 싶은 것을 설정하고 그것을 하는 것이 곧 보상
- 그리고 그 보상을 시각적으로 보여주고, 가시화하기. 비행기 예매하면 캘린더에 넣어두고 D Day를 세보면 기분이 좋아질 것

길이 안보여요

게임에서 공략이 있음. 공략은 다른 사람이 했던 길을 의미하는데, 현실에선 공략을 그대로 적용한다고 해서 되기도 하지만 안되는 경우도 있음
- 결국 다른 사람의 공략을 보고 공략의 핵심을 인지한 후에, 그것을 내가 적용하는 것이 핵심
- 빠르게 성장하는 사람은 다른 사람의 영감을 듣고 간접적으로 성장하는 사람
공략은 대표적으로 컨퍼런스 발표에서 많이 볼 수 있음. 이런 경험담을 내가 해결해야 하는 사냥터에선 어떻게 적용해야 할까?
길이 안보이는 것은 게임사에서 어렵게 찾도록 숨겨둔 것이 아닐까?라는 생각도 할 수 있음. 길이 보이지 않지만 여러 곳을 탐방하면서 우리는 결국 길을 찾지 않을까? 조급해하지 말자

제가 뭘 잘하는지 모르겠어요

내가 가진 역량과 나의 무기를 생각해보면 어떨까요?
여러분들은 어떤 무기를 보유하고 있어요? 나만의 강점은?
- 다른 사람들보다 잘하는 것이 있으면 그 무기를 더 갈고 닦아서 강화할 수 있을거에요
자신에 대해 생각해보고, 무기를 만들어보고, 무기를 개선시키는 과정에 있을거에요
처음부터 좋은 무기를 가지고 있진 않습니다. 바람의 나라에선 다들 목검으로 시작해요. 그러다가 점점 좋은 무기를 착용하게 되더라구요
- 조급해하지 말고 지금 해야 하는 퀘스트나 레벨업에 집중해보고 점점 레벨업을 하면서 좋은 무기를 가지면 되어요
뭘 잘하는지 알기 위해 여러 탐색을 해보는 것이 핵심이에요. 뭘 잘하는지 모를 수도 있고, 하다보니 이걸 내가 잘하는구나를 깨닫는 시기도 있더라구요. 뭘 잘하는지 모른다고 너무 낙심하지 마세요. 그런 시기도 있을 수 있어요

잘 안되면 어쩌죠?

특정 사냥터에서 죽는다면 어떻게 하는가? 슬퍼서 눈물을 흘리나?
- 그냥 다시 HP 채우고 포션 챙겨서 그냥 또 하는 것
민망하다 죽다니! 이런 생각을 하지 않고 어떻게 해야할까를 생각할 뿐. 이 퀘스트를 어떻게 깨야하지? 공략을 보기도 함
어떤 일이 잘 안되어도 괜찮다. 그게 인생이 끝나는 것은 아니다. 조금 더 편하게, 그저 잘 안되었다면 어떻게 해야 더 잘하게 될지 생각해보는 것이 핵심
어떻게 대처하는지가 더 중요함
- 이 내용은 불확실한 상황의 의사 결정 원칙(feat. 안티프래질) 참고

태도가 인생을 바꾼다

게임에 대한 적용은 제가 생각한 개념이라 누군가에겐 다르다고 생각할 수 있음
핵심은 내가 활용할 수 있는 사고를 만드는 것, 커리어를 바라보는 태도나 인생의 원칙을 만드는 것
이런 원칙이 쌓일수록 꾸준히 나아갈 수 있음
게임을 한다는 생각을 하니 메타인지도 늘어나고, 심리적 안전감이 생기고 앞으로 할 일에 대해 집중할 수 있게 되었어요
여러분이 인생을 바라보는 태도는 어떤 관점인가요?

Action Item

나의 레벨 정의하기 : 수치로 정확히 정의하진 못해도, 어느정도인지 과거부터 현재까지 그래프 그려보기
내가 깬 사냥터 정리하기 : 어떤 사냥터를 깨고, 그 사냥터에서 어떤 깨달음을 얻었는가?
파티, 문파는 있는가? : 파티, 문파 관점으로 생각해보기. 어떤 사람들이 내 주변에 있는가?
어떤 레벨업 구간은 정체될 수도 있다고 생각하기. 그냥 그런 시기가 있고, 조금 더 하다보면 레벨업을 해서 극복할 것
잘하는 사람이 보이면 그 사람의 과거에 어떤 경험을 했는지 물어보거나 같이 프로젝트를 할 수 있을지 이야기해보기

글 작성하는데 걸린 시간 : 1시간 50분
- 하고자 하는 이야기, 개요 정리 : 8분
- 초안 글 작성 : 52분
- ChatGPT와 셀프 글 피드백 : 10분
- 2차 글 작성 : 38분
- 이미지 그리기 : 10분
- 보상 : 글렌 모렌지 시그넷 위스키 한잔

데이터 과학자의 시간 관리 방법(Rize 앱)

Sat, 02 Dec 2023 00:00:00 +0000

키워드 : 시간 관리 엑셀, Rize 앱, 시간 관리 잘하는 법, 시간 관리 방법, 시간 관리 잘하는 법, 시간 관리법, 시간 관리 프로그램
시간 관리를 어떻게 하고 계신가요? 시간 관리는 어떤 사람이여도 알고 있으면 좋은 내용 중 하나입니다
- 학생, 사회초년생, 팀장 등 각자의 상황에 맞는 시간 관리 방법이 필요하고, 저도 여러 시행 착오를 겪으면서 저만의 시간 방법을 찾고 있어요
- 인스타그램에 시간 관리에 대해 글을 공유했는데, 요즘은 어떻게 시간 관리를 하는지 물어보시는 분들이 계셔서 글을 작성해요.
이 글에서는 제가 시간 관리를 어떻게 했는지에 대한 내용을 작성했습니다
- 최초엔 스프레드시트 기반으로 시간의 효율성을 측정했는데, 요즘은 Rize라는 생산성 앱을 사용해서 시간을 측정하고 있어요

시간 관리

살다보면 한번 쯤 생각해보는 주제 : 시간 관리
- 어떻게 해야 더 시간을 효율적으로 사용할 수 있을까?란 질문을 하게 됨
- 제한된 시간 내에 해야하는 일이 많은 경우 특히 시간 관리의 중요성에 대해 생각하게 되며, 시간 관리 방법에 대해 검색하곤 함
시간 관리 방법을 찾아보면 나오는 찾아보고 나오는 내용
- To Do를 만들어라(Must To Do 만들기)
- 목표를 확실히 잡고, 그 목표에만 집중해라
- 중요한 일 위주로 진행하기
- 뽀모도로를 사용해 시간을 쪼개서 활용하자
하지만 위 내용을 봐도 Action Item이 구체적으로 나오지 않았음
- 시간 관리를 “잘” 한다는 것의 정의는 무엇일까?
- 내가 만족하면 되는건가?
- 데이터 과학자답게 지표로 정의하면 무엇일까?라는 질문을 던짐
  - 간단하게 정의하면 생산성이라는 것이 개선되면, 시간 관리를 잘한다고 정의할 수 있을 것
  - 생산성 = 얼마나 집중해서 일을 하는가?
여기서 떠오른 생각 : “내가 시간을 어떻게 사용하고 있는가?”를 알아야겠다는 생각했음(내 시간 사용 데이터를 저장하자)
- 피터 드러커님의 말씀 : “측정할 수 없다면 관리할 수 없고, 관리할 수 없으면 개선시킬 수도 없다”
측정하지 않고 어떻게 시간을 잘 쓰고 있는지 알 수 있을까? 결국 측정을 하지 않았다는 것을 깨닫고 시간에 대한 기록을 시작

스프레드시트 기반 측정

스프레드시트에서 집중력, 환경 측정

시간을 사용하고 있는 패턴을 기록하기 위해 위와 같은 스프레드시트를 만들어서 기록함
- 일자별, 시간대별로 어떤 업무를 했는지, 업무의 테마와 상세한 내용, 업무 중요도, 작업 환경(이어폰, 제로콜라, 일어서서 일을 했다 등), 집중력, 메모로 기록했음
- 실시간으로 기록하지 않고, 퇴근 전에 몰아서 또는 점심 시간 전에 집중력이 어떠했는지 기록했음. 주관적인 부분도 존재하지만 비슷하게 기록하려고 노력함
2017년에 이 방식으로 시간을 어떻게 사용하고 있는지 파악했음(이미지의 일자는 예시를 위해 임의로 23년을 예로 들었음)
- 약 2주 정도 기록을 하니 패턴이 발견되었음
- 일종의 데이터 분석을 했는데, 집중력이 “상”일 때 어떤 특징이 있나 확인했음

제가 집중력이 “상”일 때

제로 콜라를 마시고 일어서서 할 때 집중이 높음
오전보단 오후에 집중력이 높음
마감이 직전일 때 집중력이 높음
몰입하고 싶은 즐거운 업무(데이터 분석)일 때 집중력이 높음
갑자기 해야 하는 일이 들어오는 경우 집중력이 낮아짐
참고로 위 내용이 인과 관계라는 의미는 아님. 기록한 데이터에 대한 단순한 GROUP BY

깨달음 & Action Item

시간 관리를 해야겠다고 다짐할 땐 집중력 “상”이 적을 것이라 생각했는데, 막상 기록해서 보니 집중력 “상”이 꽤 많았음. 단지 인지하지 못했을 뿐이였음(인지 편향)
- 단, 너무 상이 많은 것이 아닐지(집중력 중을 상으로 판단해야 했던 것이 아닐까 등)도 생각해보며 점점 데이터의 퀄리티를 높임
집중력이 “상”이고 싶을 땐, 집중력 “상”일 때의 상황을 의도적으로 만들어서 집중력이 높아지는지 확인해봄
- 집중할 때의 Status를 정의하고 그 환경을 만들고 실행하니 집중력이 더 높아짐
- 이와 비슷하게 특정 카페에서 일을 하거나 특정 업무를 하기 전에 진행하는 의식(?)이 있으면 더 잘하는 것을 느낌

이슈

처음엔 기록하는 것이 좋았으나, 지속성이 어려움
- 지속성이 어려워서 필요할 때마다 2주 단위로 진행하는 식으로 파악
회사를 다니는 시기엔 일을 해야만 하는 것들이 많아서 크게 이슈가 되지 않았으나, 퇴사 후 혼자 일을 하면서 시간 관리를 더 잘 진행해야 하는 상황이 생김
비슷하게 스프레드시트에 기록했으나, 일할 시간도 부족한데 이런 내용을 기입하는 시간마저 아쉬운 생각이 들었음
- 자동으로 집중력을 측정해주는 것은 없을까?
- 데이터를 자동으로 기록하는 것을 찾아보자
- 데이터 로그 설계처럼 하면 좋지만 이왕이면 자동화가 되면 더 좋겠다란 생각이 들었음
- 시간 관리 SaaS를 많이 사용하며 어떤 것이 맞는지 확인함

Rize 소개

Time Tracking SaaS로 검색하면 여러가지 제품이 나오는데, 많이 사용해보고 Rize라는 제품을 선택
Rize는 제가 필요로 한 Time Tracking 기능이 모두 존재했음
- 컴퓨터에서만 사용할 예정
- 자동으로 데이터 수집
- 적당한 커스터마이징(유튜브를 상황에 따라선 학습으로 쓸 수도 있고, 때론 휴식용으로 쓸 수 있음)
- 방해되는 앱을 킬 경우 알람
- 회고를 하기 위한 데이터 정리
사용해보고 너무 좋아 주변 지인들에게 추천하고 있는 도구
Rize가 집중하는 3가지 주요 미션
- 1) 시간을 효율적으로 사용할 수 있게 한다
- 2) 집중력을 향상시킨다
- 3) 재충전을 위한 업무 습관을 형성한다

Rize 가격

연간 구독을 할 경우 월 9.99달러
Rize 초대 링크를 통할 경우, 첫 3개월은 25% 할인을 받을 수 있으며, 앱을 설치한 후 레퍼럴 코드에 “D64DE7”를 명시하면 첫 달 무료로 사용할 수 있음
- Referral code : D64DE7
- 첫 3개월 25% 혜택은 제가 공유드린 링크를 통해 다운로드해야 가능해요
- RIZE 앱을 설치하고, 온보딩 후 크롬을 사용한다면 크롬 Extension을 설치하면 더 자세한 데이터를 확인할 수 있음

이런 분이라면 Rize 사용을 생각해보세요

1) 시간 관리를 데이터 기반으로 진행하고 싶은 분
2) 개인 사업자, 대표 등 시간 관리가 매우 필요하다고 생각하는 분
3) 자신의 생산성을 더 개선시키고 싶으신 분

Rize 화면 소개

(1) : 당일의 위젯. 이 글을 작성하는 23년 12월 2일의 Work Hour는 3시간 55분
(2) : 제일 핵심인 부분. Rize를 사용하며 많이 볼 부분으로 시간대별로 어떤 Activity를 했는지, 어떤 Project인지, 어떤 Sessions인지, 연동한 구글 캘린더 정보를 보여줌
(3) : 해당 일자(2023-11-24)의 Daily Summary를 알려줌. 하루에 얼마나 일했으며, 얼마나 Focus하고 미팅을 얼마나 했는지, 어떤 카테고리를 많이 사용했는지를 확인할 수 있음
(4) : 앱을 사용하는 이 순간 Tracking 여부. 우측엔 음악을 재생할 수 있는 기능이 있음(로파이, 재즈 등)

Activity

Activity는 Rize가 자동으로 수집하는 데이터를 기반으로 자동으로 카테고리를 나눈 것
마우스 오버를 할 경우 대략적인 데이터를 확인할 수 있음
해당 시간대를 클릭하고 View Details를 확인하면 자세한 데이터를 확인할 수 있음

해당 시간에 어떤 것을 많이 사용했는지, 그리고 그것의 분류를 알려줌
- 유튜브를 통해 학습을 했기에 Study로 카테고리화가 됨
- 만약 잘못 카테고리가 되었다고 판단하면 직접 카테고리를 수집할 수 있음(이를 Tracking Rule이라 부르는데 설정에서 자신의 스타일대로 수정할 수 있음)
  - 예를 들어 Amplitude여도 URL의 분기에 따라 Data QA라고 만들 수도 있고, Data Analytics로도 할 수도 있음. 카테고리를 자신이 생성할 수도 있음

카테고리 탭에 가면 하루에 어떤 것을 했는지 확인할 수 있으며, Activity Log를 클릭하면 어떤 것을 했는지 로그를 확인할 수 있음

Projects

어떤 프로젝트를 하고 있는지 작성하고, 이 프로젝트를 진행한 시간을 확인할 수 있음
나중에 수동으로 프로젝트를 적용할 수도 있으며, Session에서 Focus 할 때 어떤 프로젝트를 한다는 것을 명시할 수도 있음
프로젝트 이름의 … -> View를 클릭하면 Week, Month, Year 별로 이 프로젝트를 할 때 어떤 카테고리, 어떤 앱/웹을 사용했는지 알 수 있음
주당 이 프로젝트를 몇 시간 해야한다 등을 측정할 수도 있으며, 클라이언트 할당을 해서 나중에 클라이언트에게 시간당 금액을 청구할 때도 사용할 수 있을 것

Sessions

Session은 Focus, Meeting, Break 3가지로 설정할 수 있음
- Focus : 집중, Meeting : 미팅/회의, Break : 휴식
- 이 3가지를 유저가 직접(Manual) 실행할 수도 있고, Rize가 자동으로 Focus라고 판단하기도 함
- 구글 캘린더를 연동해서 특정 키워드가 있을 때 Focus, Break로 설정할 수도 있으며 미팅이 있을 경우에도 자동으로 미팅으로 기록해줌
- Focus엔 세션의 퀄리티 점수와 집중한 시간이 나오며, 방해한 작업이 무엇인지도 알려줌(해당 시간엔 슬랙과 카카오톡)

Calendar

구글 캘린더를 연동할 수 있음
구글 캘린더에 미팅이나 할 일을 기록하고 그 내용을 토대로 Session이 기록되도록 하는 방식으로 활용하며, Rize 앱에선 캘린더 정보를 볼 수만 있으며 수정이나 삭제는 불가능함(저는 삭제나 수정은 구글 캘린더에서 진행)

Rize 핵심 기능

1) 활동 추적

현재 Active 되어있는 창의 정보를 받아와서 시간대별로 무엇을 했는지 기록함
이 부분은 스프레드시트에서 시간대별로 직접 데이터를 수기 입력했던 것을 자동화한 부분

설정 - Tracking Rules로 이동하면 특정 앱, 웹을 카테고리로 나눌 수 있으며 URL이나 App의 이름을 기준으로 카테고리를 설정할 수 있음
구글 캘린더의 제목이나 정보에 #rize-focus, #rize-meeting, #rize-break를 기입하면 자동으로 Session을 생성함

2) Timer - Focus

Timer로 이동하면 유저가 직접 Focus, Break, Meeting으로 설정할 수 있음
단축키도 있어서 Timer로 진입하지 않아도 바로 실행할 수 있음

프로젝트 설명, Duration(시간), 음악, 카테고리를 설정할 수 있음

실행한 후 남은 시간을 알려줌

3) 음악 재생

2가지로 백그라운드 음악을 실행할 수 있음
- Focus Session을 실행할 때
- 프로그램 하단에서 실행
23년 12월 기준 Spotify 연동을 계획 중에 있음

4) 프로젝트 할당

프로젝트를 생성해서 프로젝트마다 시간을 얼마나 사용했는지 확인할 수 있음
동시에 프로젝트 여러개를 진행하고 있다면 세부적으로 나누면 유용함
프로젝트 하위에 Task도 존재

5) 불필요한 일 알람

Focus 모드일 때 불필요한 일이라고 판단하는 것은 Alert 메세지를 주며 집중하라고 권함
이 알람도 설정에서 커스텀하게 수정할 수 있음

6) 목표 설정

목표 탭에 들어가면 목표를 설정할 수 있음
매일 미팅을 2시간 이하로 한다거나 매일 2시간 이상 Focus를 한다거나 등 여러가지를 설정하고 확인할 수 있음

위와 같은 Goal Template이 존재하며 아직 Goal에 대해선 자유도가 높진 않음

7) 메일로 레포트 제공(Daily, Weekly)

Rize를 사용하면 Daily Report, Weekly Report를 전송해주는데 이 기능이 정말 유용
이정도로 자동화가 되어있다면 고객이 좋은 가치를 느끼겠다라고 생각함
Weekly PDF를 자주 보는데, 일부만 공유

Rize를 사용하는 흐름

컴퓨터를 킬 때 항상 Rize 실행
- 게임하거나 다른 일을 해도 그냥 기록함. 컴퓨터하는 시간 전체를 기록하고 싶기 때문
까먹지 말아야 하는 일정은 구글 캘린더에 추가

핵심 단축키 숙지

스타크래프트를 할 때 단축키를 열심히 외웠는데(?) 이것처럼 단축키를 숙지해서 빠르게 컨트롤
Global Keyboard Shortcut 설정
- Rize 앱을 빠르게 실행할 수 있는 단축키

Rize -> Device Setting -> Customize Global Keyboard Shortcut
저는 command + '로 글로벌 키 변경함(Mac에서 ; 우측에 있는 키)
command + '로 Rize 실행한 후
- Tracking이 꺼져있으면 command + p를 누르고
- Focus를 하고 싶으면 command + f를 누름. 쉬고 싶으면 command + b
- 자세한 설정을 하지 않고 바로 Focus를 하고 싶으면 command + shift + f
- 윈도우는 command = ctrl

시간 관리 회고

Weekly Report를 받아본 후, 어떤 것을 개선해야 할까에 대해 시간 관리 회고를 짧게라도 진행함
- 이번 주엔 얼마나 집중했고, 다음 주는 어떻게 하고 싶은가?
- 어떻게 더 잘 진행하고 싶은가?
- 이걸 위해 무슨 Action을 해야할까?
시간의 패턴이 있는가? 데이터 분석 진행
시간 관리 원칙 만들기 : 나만의 시간 관리 원칙이 생기고 있을텐데, 회고를 하며 그 원칙을 명시적으로 업데이트함

제 시간 관리 원칙 일부

시간 관리 원칙 일부만 공유하면
1) 하루에 1시간의 여유 시간 확보
- 내가 예상한 일이 예상처럼 되는 일이 없을 수 있기에 여유 시간을 확보
- 만약 예상한 일을 모두 다 진행했으면 그 시간은 자유 시간으로 활용하거나 휴식을 취함
2) 1주일에 약속은 최대 3개
- 업무를 할 시간이 부족하면 왜 그런가 생각해보기
- 제 경우 약속이 너무 많은 경우 집중이 어려웠음. 그렇기에 1주일에 외부 약속은 최대 3개 정도를 설정하려고 노력함(시기에 따라 다를 수 있음)
- 업무 미팅은 제외한 친구를 만나거나 커피챗하는 약속이 이 원칙을 따름
3) 단, 점심 약속은 환영
- 하루를 늦게 시작하는 것을 방지하기 위해 점심 약속은 환영
- 12시에 점심을 먹기 위해 나가는 경우 하루를 더 잘 사용하는 패턴을 발견했음
4) 운동하는 시간은 절대 포기할 수 없는 시간
- 운동할 시간을 빼는 것보단, 운동을 꼭 진행할 수 있도록 시간 확보
5) 늦어도 2시엔 취침, 9시 20분엔 기상
- 꾸준한 습관을 유지하기 위해 취침, 기상 시간을 관리하기
- 막연하게 오래 자는 것은 방지하기
6) 동시에 진행하는 프로젝트는 최대 3개
- 동시에 진행하는 프로젝트가 많아질 경우 시간 관리가 되지 않고 프로젝트에 끌려다닐 수 있음
- 이런 경우를 방지하기 위해 프로젝트의 수를 조절하려고 함
7) 연속 3개의 미팅을 진행하면 잠깐 쉬기
- 미팅을 3개 연속하면 에너지 레벨이 낮아져서 그 다음에 어떤 일을 해도 효율이 낮음. 이를 방지하기 위해 의도적으로 휴식을 넣어두기
8) 나의 가치는 생산성으로 측정할 수 없다
- 자신의 가치를 생산성, 효율성으로 판단하는 경우가 있는데, 이 지표가 높아야 나의 가치가 높은 것은 아님
- 자신이 감당할 수 있는 상황에서 최선의 생산성을 내는 것이 핵심이며 의도적으로 쉬는 시간(휴식 및 충전)을 배치하는 것을 추천
- 중요한 것은 내가 잘 살면서 시간을 컨트롤하는 것

마무리

사람마다 자신의 시간 관리 방법이 존재할 것
- 이 글은 데이터 과학자 입장에서 데이터 기반으로 시간 관리를 어떻게 했는지를 작성한 글
- 여러분들의 방법을 찾아보고, 이런 방법도 있구나 정도로 이해해도 좋음
생산성 SaaS를 활용해서 자신의 생산성을 개선하는 시도를 해보시는 것도 추천
Rize 초대 링크를 사용할 경우, 첫 3개월은 25% 할인. 앱을 설치한 후 레퍼럴 코드에 “D64DE7”를 명시하면 첫 달 무료로 사용할 수 있음
- 저는 Rize Amabassador 프로그램에 참여하고 있으며, 이 글을 경유해 Rize에 가입하시면 수익의 일부를 얻게 되어있습니다
시간 관리 원칙은 꼭 만들어보는 것을 추천

참고 자료

글 작성하는데 걸린 시간 : 3시간 3분

불확실한 상황의 의사 결정 원칙(feat. 안티프래질)

Wed, 25 Oct 2023 00:00:00 +0000

키워드 : 의사 결정 프로세스, 의사 결정 방법, 의사 결정 과정, 의사 결정 원칙
우리는 살면서 의사 결정을 해야하는 경우가 많습니다. 이럴 때 어떻게 해야 최선의 의사 결정을 할 수 있을까?라는 생각을 하곤 합니다. 아마 많은 분들이 한번쯤 이런 생각을 하셨을거에요.
나심 니콜라스 탈레브의 안티프래질 책을 2021년에 읽고, 김창준님의 함께 자라기, AC2 수업을 2022년에 수강 등 다양한 경험을 하면서 저만의 의사 결정 프로세스가 생겼습니다.
최근 비즈까페님께서 운영하는 독서 모임에서 안티프래질 책을 읽으며, 생각을 공유하는 시간을 가졌습니다. 여러 대화를 하며 영감도 얻었고, 저의 의사 원칙을 정리하는 글을 작성하려고 합니다
내용의 일부는 PM을 위한 데이터 리터러시 강의에서 확인할 수 있습니다

무엇에 대한 의사 결정을 해야하는가

Gray Zone

1+1은 같은 질문 또는 명확하게 하나의 선택이 좋은 경우는 명확하게 결정할 수 있는 경우가 많음
- 명확하거나 어렵지 않은 것은 쉽게 결정할 수 있음
대부분 우리가 어려워하는 것은 “Gray Zone”에 있는 문제
Gray Zone은 대부분 다음과 같은 특징을 가짐
- 경험을 해보지 않음
- 불확실성이 매우 높음
- 명확히 나뉠 수 있는 것이 아닌 여러 문제가 복합적으로 연결됨
- 문제 정의를 한 문장으로 정리하기 어려움

생각할 틈도 없이 변한 세상

올해 AI의 화두는 ChatGPT라고 봐도 과언이 아님
- 잘 생각해보면 4년 전엔 이런 상황을 상상할 수 있었을까? 생각하면 상상할 수는 있지만 언제일지 몰랐음
- 4년 전과 요즘은 일하는 방식도 달라지고 있음
- Copilot 등을 사용해 생산성을 더 올리고, 오류 메세지가 나오면 ChatGPT에게 물어보는 세상이 되었음
- ChatGPT 전에는 Stack Overflow의 글을 많이 참고했지만, 요즘은 확실히 Stack Overflow에 접근하는 비율이 줄었음
- Transfomer가 나왔을 시기에 대단하다!라고 했었는데, 그것도 이제 과거의 일
요즘 마케팅 트렌드를 빠르게 파악하려면 틱톡을 봐야한다는 말을 들었음
- 4~5년 전엔 광고를 보면 트렌드를 알 수 있다고 들었는데 달라짐
코로나를 생각해도 과거엔 이런 현상이 생길지 몰랐지만, 코로나로 인해 정말 많은 것들이 변함
- 요즘은 많이 안정되었다고 볼 수 있지만, 코로나가 막 시작되었을 땐 언제 끝날지 상상할 수 없었음
스타트업, IT 업계는 투자가 잘 돌지 않으면서 이직의 난이도도 어려워짐
- 불과 몇년 전만 해도 개발자 연봉 1억! 이랬는데 최근 엄청 변함(취업이 몇년 전에 비하면 어려워짐)
- 개발자 이직이 언제 잘 풀릴지에 대한 토론을 개발자 커뮤니티에서 보면 많이 하곤 합
대학 입학할 때 생각하면 공대에선 전화기가 엄청 강세였는데, 요즘은 컴공에 가서 개발자를 하고 싶다는 사람들도 생김. 과거의 인식과 현재의 인식은 달라짐

위와 같은 현상 : 블랙 스완

블랙 스완 : 발생하기 전에는 가능성이 매우 낮아서 예측이 불가능하지만 일단 발생하면 경제에 큰 영향을 줄 수 있는 사건
- 일어날 것 같지 않은 일이 일어나는 현상
- 블랙 스완은 나심 니콜라스 탈레브의 다른 책
블랙 스완 현상이 발생하기 전엔 사람들이 상상도 하지 못함. 그러나 현상이 발생한 후엔 그 현상에 대한 전문가들이 나오면서 “이런 저런 이유로 이런 현상이 발생된 것이다”라는 이야기가 나옴
- 페이스북에 ChatGPT 전문가라고 하는 분들이 이런 느낌이였음
사실 우리는 그냥 이런 현상이라고 믿고 있었던 것일지도
- 그러길 바랬는데, 막상 그런 상황이 발생하지 않아서 너무 리스크가 컸던 것
- 또한 내가 생각한 것이 아닌, 주변이 믿는 것을 믿었던 것일수도(다른 사람의 의견이 나에게 영향을 미쳤던 것인가?)

안티프래질

안티프래질은 불확실한 상황에서 어떻게 해야할까에 대한 관점
프래질 : 충격을 가하면 부서짐
안티프래질 : 충격을 받으면 오히려 더 성장함
- 성장 마인드셋과 유사
- 목이 잘리면 2개의 목이 생기는 히드라, 죽음을 경험하면 더 강해지는 드래곤볼의 초사이언, 충격을 흡수했다가 강한 에너지로 분출하는 블랙 펜서의 비브라늄 슈트 등을 예시로 들 수 있음
불확실한 상황에 어떤 태도를 가져야 할까?
- 성공, 실패는 결국 피드백이다. 그 안에서 경험을 얻자
- 닥친 스트레스를 대응하자
전략
- 바벨 전략 : 중간이 아닌 양 극단을 모두 수용
  - 승무원 채용할 때 낙천적인 사람
  - 조종사 채용할 때 비관적인 사람(잘못될 경우 리스크가 크므로)
- 옵션
  - 비대칭성 : 예측이 틀렸을 때 잃는 돈보다 옳았을 때 버는 돈이 많음
  - 합리성 : 좋은 것을 유지하고 나쁜 것은 버림
아래는 책을 읽고 정리한 내용

데이터 과학자 관점에서 생각해보기

데이터 과학에선 과거의 데이터로 미래를 예측, 추론하려고 함
데이터 과학 교육에서 “아웃라이어”라는 개념이 존재하는데, 아웃라이어는 평균에서 크게 벗어나 다른 대상과 확연히 구분되는 표본을 의미함
- 이런 아웃라이어는 모델링하거나 분석할 때 제외함
- 그리고 이런 현상이 일어나지 않을 때의 모델, 분석을 만들어서 활용함
처음 학습할 땐 아웃라이어는 빼야지!라는 생각을 했지만, 현업에서 일을 하면서 여러 경험을 하니 아웃라이어를 꼭 제외하지 않고, 어떻게 바라볼지에 대해 생각하는 시간도 필요할 것이라 생각했음
블랙 스완 현상이 발생해서, 그 부분과 관련된 데이터는 아웃라이어가 될 수도 있다
- 아웃라이어를 무조건 제외하는 것이 아니라, 아웃라이어가 발생한 맥락도 확인해봐야 하지 않을까?
- 아웃라이어를 제외하고 모델을 잘 만드는 것도 중요하지만, 아웃라이어가 발생했을 때 어떻게 대처하는게 중요하지 않을까?
- 대처에 대한 관점은 MLOps 관점에서도 연결이 된다고 느꼈음
만약 SNS 프러덕트에서 실시간 추천 시스템을 운영하는데, 이상한 컨텐츠(광고나 음란물 등)가 굉장히 많이 유입된다면? 또한 어뷰징을 하는 봇이 많아서 이런 컨텐츠 위주로 좋아요, 댓글을 한다면?
- 모델링 관점에선 사람들이 좋아할 컨텐츠를 추천하고 있을 수 있음
- 그러나 이런 상황이 발생하지 않길 바라는 경우가 많을 것
- 유저 관점에서 이런 컨텐츠가 많으면 프러덕트의 만족도가 하락될 가능성이 높음
- 이런 예시는 단순 예시가 아니라 인스타나 페이스북에서도 발생하고 있던 일. 해결 방법 중 하나로 컨텐츠를 올릴 때, 컨텐츠의 속성을 예측해서 이상하다고 생각하면 Block을 하고 있음
- 만약 데이터가 있다면 모델링을 할 수 있지만, 데이터가 없다면(=상상도 못한 종류의 일이 발생한다면) 모델링이 어려움. 물론 기술적으로 이런 것들을 해결하기 위한 방법을 Anomaly Detection에서 많이 시도하기도 함
위에 이야기의 핵심은 불확실한 상황이 생겼을 때 우리는 어떻게 해야 할까? 모든 것을 데이터 기반으로 할 수 있는가?라는 질문을 던지는 것
- 불확실함이 매우 크다면 완전 데이터 기반은 어려울 수도 있다는 관점을 제시하고 싶은 것
데이터 과학자로 일하면서 종종 데이터로 좋은 의사결정해주세요!라는 말을 자주 듣는데(예로 코로나), 나도 코로나는 처음이고 이런 상황에 어떻게 해야할지는 사실 몰랐다. 그냥 데이터와 여러 경험을 토대로 추론하고 이런 Action Item에 베팅할 뿐

제 의사 결정 원칙

1) 답을 내린다는 표현 대신 베팅한다고 생각하기

어떤 단어를 쓰느냐에 따라 나의 사고가 결정된다고 생각하기에 베팅한다라는 표현을 사용
비슷하게 당연하다라는 말도 잘 쓰지 않음. 당연하지 않을 수 있고, 당연하다고 우리가 믿는 것일 수 있음

2) 지표로 나타날 수 있는가?

현상을 파악할 수 있는 지표 2-3개가 존재한다면 그 지표를 사용
여러 케이스에 대해서 Mental Simulation을 진행
2개의 지표가 있는 경우엔
- a 상승, b 상승
- a 상승, b 하락
- a 하락, b 상승
- a 하락, b 하락
- 각각의 경우가 발생하면 어떤 Action Item을 할 것인가? So What에 대해 생각해봄
- 이런 사고를 하면 미리 Risk를 대비하려는 노력을 하고, 실제로 이와 유사한 상황이 오면 당황하지 않게 됨(물론 블랙 스완은 위 케이스보다 더 극단적이라 놀라긴 할 것이지만 심리적으론 더 건강)

3) 아 정말 모르겠다면?

다른 사람들이 어떤 선택을 하는지 보고, 일반적이지 않은 선택을 한다
군 전역 후 25세부터 생긴 마음 가짐
남들이 선택하지 않은 것을 하다보면, 그 희소한 선택들이 모여 나를 더 희소하게 만들 것
알파고가 뜨고 동아리 동기들이 모두 대학원에 갈 때 패스트캠퍼스에서 공부한 것, 데이터 분석가로 들어갔는데 데이터 엔지니어 일을 받았을 때 오히려 더 잘해보려고 한 것, 시키는 일 이상으로 더 잘하기 위한 고민을 했던 것, 코칭/교육을 시도했던 것
위 케이스는 모두 내가 경험한 것으로, 다양한 경험들이 쌓여서 현재의 나를 만들었음
여전히 고민될 땐 “다수가 A라고 하면 난 A가 아닌 방법으로 해내자”라는 생각을 자주 함(반골 기질?)

4) 에너지가 충분한지 확인

에너지가 충분하지 않으면, 좋은 결정을 하기 어려움
특히 불안할 땐 더 그럼. 다른 사람에게 의존하거나 맡기고 싶어함
이럴 땐 차라리 푹 쉰다. 그리고 다시 본다

5) 결정을 했으면 그 결정이 좋은 결과를 낼 수 있는 방법을 고민하기

어떤 결정을 하면, 모든 시도를 하면서 결국 해내는 것이 중요하다고 생각
결국 해내는 사람이 될 것인가? 할 수 있는 정도만 하는 사람이 될 것인가?

6) A or B라는 질문이 온다면

A and B가 안되는지 생각해본다. 정말 불가능한가? 둘 다 가능한 방법은 무엇일까?
이분법을 넘어서 둘 다를 생각하는 사람

7) 시간이 지날수록 손해가 생기면 시간을 정해두고 끝낸다

30분 안에 의사 결정하기!
불확실한 일은 마감을 정하고 일차적으로 확인한 후 가는 것도 방법. 안되면 그냥 포기하는 것도 손실을 줄일 수 있음

8) 미리 하면 좋은 것이라면 차라리 먼저 하자

미리 하면 좋은 것이면 시간이 지날수록 얻는 이익이 커짐
예) 문서화. 문서화는 미리 할수록 좋음
예2) 사람들과 신뢰 쌓기. 신뢰는 먼저 쌓을수록 좋다

9) 일단 경험하고, 그것을 좋게 만드는 것은 나의 몫

어떤 마인드를 가지느냐에 따라 그 경험이 좋아질 수 있는 것은 결국 나의 마인드에 따라 결정
다양한 관점으로 생각해보기
정승제 선생님의 이 세상은 마인드의 차이야! 라는 컨텐츠를 봐도 크게 도움 됨
- 일을 주체적으로 해결하려는 마인드

10) 고민이 될 때 보는 지침서 만들기

저는 컨설팅, 팀 코칭을 할 때 항상 컨설팅의 비밀 이란 책을 읽고 갑니다. 이 책을 읽으며 이번엔 어떤 관점으로 시도할까를 생각하고 들어가요
이런 루틴이 제 일하는 태도를 만들고, 미리 상상할 수 있어 더 좋은 의사 결정을 할 수 있게 되었어요

11) 칩 히스, 댄 히스의 의사 결정 프로세스를 자주 보며 리마인드

후회 없음 책에서 나오는 의사 결정 프로세스 4단계
WRAP 1단계 : 선택지 넓히기
- 현재 생각하는 대안이 전부인가? 생각하는 것을 모두 할 수 없다면 무엇을 해야하나?
WRAP 2단계 : 가정 검증
- 지금 가정하는 것이 진짜 맞다고 확신할 수 있는가?
WRAP 3단계 : 결정과 거리 두기
- 결정에 감정이 기여했는가? 이성적으로 생각했는가?
WRAP 4단계 : 틀릴 때를 대비하기
- 예상과 다르면 어떻게 할 것인가?

마무리

불확실한 상황에서 어떻게 행동해야 할까? 불확실한 상황일수록 자신이 어떤 사람인지 메타인지가 있고, 자신만의 원칙이 있을수록 더 소신 있게 움직일 수 있는 것 같습니다
여러분들의 의사 결정 원칙은 무엇인가요? 자신만의 의사 결정 원칙을 만들어보시길 바랄게요
제가 공유한 내용은 정답이 아니고, 경험한 내용을 글로 작성한 내용입니다. 내용에 의견이 있다면 언제든 말씀해주세요!

글 작성하는데 걸린 시간 : 1시간 38분

인프런에서 강의 만들기, 온라인 강의 만들기 경험 정리

Thu, 13 Jul 2023 00:00:00 +0000

키워드 : 인프런 강의 올리기, 인프런 강의 만들기, 인프런 강의 제작, 온라인 강의 만들기, 온라인 강의 제작
인프런에 PM을 위한 데이터 리터러시 강의를 23년 2월에 올렸습니다. 강의를 만들면서 어떻게 좋은 강의를 만들어야 할까?를 계속 고민했습니다
추후 강의를 만들고자 하는 분들을 위해 이 글을 작성합니다
예상 독자
- 인프런에서 강의를 만들까 고민하고 계신 분
- 인프런 플랫폼이 아니여도 온라인 교육 만들기에 관심이 있으신 분

배경 설명

제 강의 관련 경험

강의 관련 경험을 알려드리면 보시는 분들에게 좋을 것 같아 작성
과거 강의 경험
- 오프라인 강의 진행(사내, 외부 회사 특강 등)
- F사 온라인 강의 촬영
- 강의 조교, 멘토 경험 다수
- 컨퍼런스 발표 경험 다수(10회 이상)
- 부스트캠프 AI Tech Product Serving 강의 촬영
편집 도구의 익숙함
- 광고 동아리에서 영상 편집을 배운 경험 존재
- 유튜브 운영으로 간단한 컷 편집 가능(고급 편집 불가능)
혼자 강의 기획, 촬영, 편집 등을 모두 진행한 경험은 없음
정리
- 강의, 발표, 글쓰기는 익숙했음(=컨텐츠는 어느정도 존재) + 각 잡고 온라인 강의 만드는 것은 처음

강의 제작 기간

2022년 7월에 퇴사해서 2023년 2월에 런칭. 총 7개월 소요
- 그러나 집중적으로 진행한 기간은 2023년 1-2월
- 22년 7월부터 22년 12월까진 강의 자료 만드는 시간이였고, 23년 1-2월은 촬영 및 편집에 집중한 시간
처음이라 시간을 효율적으로 쓰지 못하고 그냥 날린 경우도 많음. 아 이제 되겠지~ 했지만 생각보다 시간이 더 빠르게 지나감
강의 완성 후 시간 : 14시간

강의 기획

온라인 강의를 만들기 위해 좋은 교육이 무엇일까에 대해 고민
- 이 부분은 예전부터 하고 있었던 고민이였고, 단순히 나열식으로 강의를 진행하는 것이 큰 도움이 되지 않는 것 같단 생각을 했음

RET 수업

이런 고민을 하던 찰나에 함께자라기의 저자이신 김창준님이 Really Effective Teacher 과정을 내주셔서 수강
- 어떻게 가르칠 것인가를 다루는 교육자를 위한 교육
- 이 교육을 듣고 조금 더 좋은 강의 기획을 진행할 수 있었음
RET 교육이 나에게 얼마나 도움이 될까?에 대한 체크리스트(출처 : 위에 링크해둔 Form)
1. 교육 직후 만족도는 학생의 지연된(교육 끝나고 몇 달 후) 행동 변화와 유의미한 상관성이 있다.
2. 교육 시간 중 학생들이 실수(문제를 틀린다든지)를 적게 저지른 교육일수록 해당 학생들의 교육 후 수행능력이 높다.
3. 학생들에게 체계화되고 정리된 지식을 전달하면(그렇지 않을 때에 비해) 학생들의 해당 지식에 대한 장기기억 수준이 더 높다.
4. 교육을 할 때 요소 기술들을 개별적으로 집중 훈련하는 것이 이후 수행능력에 도움이 된다.
5. 교육자의 해당 분야 전문성(자격증, 학위, 교육 경력, 혹은 해당 분야 전문성에 대한 시험 결과)은 학생들의 학습효과를 높은 수준으로 예측한다.
6. 효과적이라고 알려진 전략(베스트 프랙티스)을 학생들에게 가르치면 학생들의 수행 능력이 높아진다.
7. 교육시 시청각 자료를 최대한 제공하는 것은 교육 효과와 상관성이 있다.
8. 여러번에 나눠서 하는 교육보다 한번에 몰입감 있게 몰아서 하는 교육의 효과가 더 크다.
9. 교육자가 해당 주제에 대해 명료하고 확신에 찬 태도로 가르치는 것이 그렇지 않은 경우에 비해 교육 효과가 더 좋다.
10. 학생이 교육 받기 전의 동기와 장기적 학습 효과 사이에는 높은 상관성이 있다.
11. 교육자는 학생들이 교실에 있을 때만 영향을 미칠 수 있지 현업으로 돌아가서 어떤 행동을 할지에 대해서까지는 영향력이 없다.
12. 탁월한 교사상을 받은 사람은 자신이 어떤 문제를 해결할 때 쓰는 전략(예컨대 외과의사의 특정 수술법 등)의 50% 이상을 학생들에게 가르칠 수 있다.
13. 특정 교사의 수업 영상(학생들이 보이지 않음)을 묵음 처리한 걸 10초 이하로 보여줬을 때 이 수업을 듣지 않은 제삼자는 해당 수업을 한 학기 들은 학생들의 교사 평가를 예측할 수 없다.
14. 학생들이 더 좋아하는 방식을 통했을 때 학생들은 더 많이 배운다.
15. 교육 중에 학생들이 몸을 더 사용하게 하면 더 많이 배운다.
16. 게임, 스토리텔링, 시뮬레이션 등은 학습을 증진시킨다.
17. 교육 중 많은 사례를 들려주면 더 많은 학습을 하게 되며 응용 능력(transfer)도 커진다.
이 수업을 듣고 “수강생의 변화를 위해 꼭 필요한 것은 무엇인가?”라는 질문을 던지게 되고 인지적인 전략을 많이 알게 되었음
- 실제 일을 할 때 내가 어떤 방식으로 일을 했는가?에 대해 스스로 CTA(Cognitive Task Analysis)를 해서 암묵지 영역에 있는 지식을 구체화했음
- 그리고 이 지식을 알려주려면 어떻게 해야할까?에 대해 고민했음
- 수강생의 삶에 큰 도움이 되려면 어떤 것을 알려줘야 할까, 그 사람들의 Pain Point를 무엇일까?를 고민하게 되었음
꼭 교육이 아니여도 앞으로 문제를 대하는 자세를 접하게 되었고, 이 이후에 김창준님의 AC2 과정도 듣고 더 많은 전략을 깨달았음

강의 기획

강의 기획은 1) 어떤 변화를 만들고 싶은가 2) 상세 기획 2가지로 나눔
어떤 변화를 만들고 싶은가는 “강의를 들은 수강생이 강의 이후에 어떤 모습이길 바라는가?라는 질문을 던지고 그에 따라 그것을 하려면 어떤 것을 해야할까?를 고민함
- 그 결과 PM을 위한 데이터 리터러시 강의는 다음과 같은 것을 포함했음
  - User Story : 카일스토리라는 것으로 강의가 시작되어서 공감하며 강의를 시작함. 케이스 스터디처럼 진행할 수 있음
  - 생각의 흐름, 암묵지를 도표로 정리
  - PM이 일하는 방식처럼 피그마를 제공함. 이를 위해 피그마도 학습해서 화면을 구성함
  - 웹페이지 제공 : 강의 내용의 핵심을 정리한 웹페이지 제공
  - 코칭 제공 : 강의 후에 여전히 답답한 부분을 해소하기 위해 코칭을 제공하고 있음
  - 디스코드 커뮤니티 운영 : 질문 게시판이 있지만 더 편하게 그리고 웹에 공개하기 애매한 질문을 올릴 수 있는 공간을 마련. 이 커뮤니티에서 서로 만나거나 스터디를 하기도 함
최초 기획을 명확하게 했음에도 불구하고 기획이 중간 중간 변경됨
- 기획을 처음부터 100% 완성하는 것보단 80% 정도 하고, 강의 자료를 만들면서 계속 수정(또는 피드백을 받아가며)하는 것이 더 좋음
- 어차피 처음에 생각한 것과 계속 달라지게 됨
- 월 회고 등을 통해 점진적으로 강의를 수정하는 것도 좋음. 애드혹처럼 갑자기 강의 기획을 수정하면 동기부여가 떨어짐
강의의 잠재 고객이 될 분들에게 미리 연락해 커리큘럼 피드백을 받아보는 것도 방법이며, 강의 자료 완성 후에 피드백을 받을 수도 있음
- 피드백을 빠르게 받고 빠르게 적용하는 것도 중요함
강의를 기획하는 단계에서 많이 생각하는 것이 “이런 것도 강의를 내도 괜찮을까?”, “내가 잘 모르는데 강의해도 되나?”, “이미 많은 강의가 있는데 굳이?” 등이 있음
- 현재 그 강의가 잘 나가도 더 좋은 강의를 만들 수는 있을 것이고, 완전히 똑같이 하는 것이 아닌 차별점이 존재해야 함
- 이 차별점을 알기 위해 문제를 겪는 분들을 인터뷰하는 것도 매우 추천. 제품을 만들 때 자주 하는 고객 인터뷰와 같음
- 내가 과거에 필요했던 내용을 강의로 만드는 경우가 종종 있는데, 이게 왜 필요했는지를 명확히 생각해보는 것이 필요함. 이걸 하지 않는다면 자신의 Bias일 가능성이 있음
현재 시장에 있는 강의를 보고 특징이나 패턴을 학습하는 것도 도움이 됨. 기존에 있는 강의에서 해소되지 않는 것은 무엇일까? 이 부분을 위주로 접근할 수 있음
- 이런 문제를 접하다보면 내 의도와 살짝 다르게 강의를 만들 수도 있음

강의 자료 제작

강의 기획을 진행했으면 이제 강의 자료를 제작해야 함
강의 자료 제작도 시간이 꽤 많이 소요됨
- 내용 위주로 채우고, 그 후에 디테일한 디자인을 챙기는 방식을 추천

강의 자료 제작 플랫폼

강의 자료 제작은 사람마다 각자의 스타일이 있지만, 대부분 PPT, 구글 슬라이드, 노션 등으로 제작
100% 판서로 강의하는 경우는 많이 보진 못했고, 강의를 찍은 후에 까먹은 내용이 있다면 다시 찍어야 해서 저는 구글 슬라이드로 강의 자료를 제작함

구글 슬라이드

구글 슬라이드의 기본 폰트는 Arial 폰트인데 크롬에서 볼 땐 글씨가 이뻐보임. 그러나 이걸 PDF로 다운 받으면 상상과 다른 글씨가 보임
- 이것은 구글 슬라이드에 적용한 폰트가 한국어 폰트가 아니면 크롬 자체의 폰트로 보여주는 로직이 있기 때문
- 나중에 PDF로 저장할 때를 대비해서 폰트를 제일 처음 신경쓰면 좋음(PPT는 한번에 바꾸기가 있지만 구글 슬라이드는 원활하게 바꾸는 방법이 거의 없음)
저는 심플한 강의 자료를 만드는데, Flaticon을 구독해서 사용하고 있음. 심플한 아이콘이 많아 표현하기 좋음

강의 자료 스타일

강의 자료를 빼곡히 작성 vs 필요한 것만 작성
- 이건 강의자의 특성에 따라 다름
- 저는 강의 자료를 일단 알차게 작성하고, 수강생들이 필기를 하느라 시간을 많이 쓰지 않길 바랬음. 수강할 때 필기에 집중하는 것보다 내용을 이해하라는 내용을 OT에 전달했으며, 강의 자료를 자세히 작성함
- 강의를 진행할 때는 와콤으로 판서도 진행함. 추가적인 예를 들 때나 밑줄치면서 강의를 진행했음

그 외에 필요한 자료

개발 강의라고 하면 Github Repository에 코드도 올려야 하며, 모든 OS에서 정상적으로 실행되나 확인해야 함(개발 환경이 제일 어려우니 더욱 신경써야 함)
PM을 위한 데이터 리터러시 강의는 피그마 파일도 제공하기에 피그마 파일도 준비하고, Action Item을 제시하는 스프레드시트 템플릿도 준비했음
추가적으로 PM을 위한 데이터 리터러시는 웹페이지도 제공했음. 웹페이지에 강의의 핵심 요약을 제공했음. 이 웹은 Vuepress로 제작(=하지 않아도 괜찮은데 가볍게 다시 찾아볼 수 있도록 도와주고 싶었음)

저작권

대본 제작

강의를 처음 하는 분이라고 하면 대본을 만드는 것도 추천
저는 대본을 쓰진 않고, 강의 자료를 보며 스토리를 기억하려고 함. 강의 자체도 스토리 위주로 진행되며 강의 자료를 자세히 써놔서 놓치는 키워드는 거의 없음
그러나 처음 한다면 대본을 간단하게 작성하고 촬영할 때 노션 등을 다른 모니터에 띄워서 한번씩 보며 하는 것도 추천
혼자 이야기를 해야하므로 꽤 어색하게 느껴질 수 있어서 대본을 만들어서 심리적 안정감을 챙길 수 있음
저는 이젠 대본을 만들지 않고 바로 발표하고, 잘못 말했으면 다시 촬영해서 편집으로 해결

촬영 전 피드백

알파 테스터로 도움을 줄 수 있는 분에게 컨택해서 자료를 보고 피드백 달라 요청
- 피드백을 통해 강의를 개선하고, 피드백을 작성해주신 분의 추천사를 모아 강의 소개 페이지에 활용함
- 알파 테스터로 도움을 주신 분들에게 강의가 열렸을 때 최대 할인 쿠폰을 별도로 발급해서 드렸음
촬영 전 피드백을 받으면서 더 양질의 자료를 만들 수 있음
- 피드백을 꼭 발표 자료를 주고 진행하는 것이 아닌 알파 테스터 대상으로 매주 1시간씩 온라인 강의를 하고 피드백을 받는 것도 방법
- 이러면 강의 자료 만드는 속도도 마감 효과로 올라가며, 피드백도 바로 바로 받을 수 있음
- 코드 강의라고 하면 어떤 부분을 어려워하는지 바로 확인할 수 있어 그 부분에 대한 추가 자료를 준비할 수 있음
강의를 한번 만든 후엔 수강생들을 대상으로 촬영 전 피드백을 받는 것도 좋은 방법

촬영

자료를 만들었다면 이제 촬영을 시작해야 함. 촬영을 해보지 않은 분들이 있을 것 같아 이 부분도 자세한 팁을 작성

카메라

얼굴을 노출할 것이냐 말 것이냐에 따라 카메라 필요 여부가 달라짐
제 강의에선 얼굴을 노출하지 않아도 괜찮다고 판단해 별도의 카메라를 구입하진 않음
얼굴을 꼭 노출한다고 판매량이 늘어난다는 것은 아니라고 생각해 이렇게 진행
만약 카메라가 필요하다고 하면 웹캠을 사는 것을 추천
- 최소 HD 1080p을 지원하는 제품
- 저는 로지텍 C922 웹캠을 사용하고 있으며, 요즘엔 로지텍 스트림캠도 추천하는 영상을 많이 봤음
다만 내 카메라 뒤에 있는 배경을 보이고 싶지 않다면 초록색 크로마키 천을 두고 별도의 작업을 해야 함
- 줌에선 배경 지우기가 가능하니 줌에서 촬영하고 업로드하는 분들도 있었음. 다만 영상의 해상도가 좋은지 확인할 필요가 있음

마이크

카메라보다 더 중요한 것이 음질
마이크 관련 여러 시행 착오를 겪어서 단계 별로 추천
처음 진행할 경우엔 핀마이크 추천
- 핀마이크는 보야 BY-M1 제품을 구매해서 활용했는데 만원 정도로 구매할 수 있음
- 가볍게 사용하기 좋으며, 1인 촬영할 때 좋음
- 다만 옷에서 전정기가 나면 전기 지지직 거리는 음이 생기기도 하며, 움직임에 따라 잡음이 생겼음
USB 콘덴서 마이크
- 유튜브 크리에이터들이 사용하는 마이크를 검색하니 콘덴서 마이크가 나와서 구매했음
- 보야 BY-PM700을 구매했으며, 가격은 약 9만원
- 다만 콘덴서 마이크를 책상 위에 두고 촬영할 경우 타자를 치거나 책상을 건들 때 진동 음이 느껴져서 아쉬움이 생겼음
마이크에 대한 스트레스가 계속 되어서 현재는 엘가토 웨이브3을 구매함
- 또한 마이크 암이 필요하다고 판단해 마이크 암, 진동을 줄여줄 수 있는 쇼크마운트, 파열음을 줄여줄 수 있는 팝필터도 같이 구매함
- 가격이 꽤 있으나 이거 하나면 앞으로 마이크 바꿀 일은 없다고 생각해서 이렇게 구성. 직구를 할 경우 더 저렴
- 엘가토 웨이브 로우 프로파일 마이크 암(LP)은 아래쪽에서 위로 올릴 수 있는 암이라 공간을 정리하기 좋음. 보통 마이크 암이 위에서 마이크를 아래로 두는데, 암이 위에 있으면 시야를 가리기 때문에 아래에 두는 것을 선택함

엘가토 웨이브3 마이크의 경우 Wave Link라는 별도 프로그램이 있는데 소프트웨어에서 제공하는 기능이 유용함

Input 채널을 여러개 설정할 수 있음. 이런 것을 강의할 때는 크게 신경쓰지 않아도 되는 부분이지만 언제 유튜브 방송 등을 할 때 음성을 제어할 수 있는 장점이 존재. 내 말을 내가 들을 수 있도록 설정할 수도 있음(듣는 사람에겐 들리지 않으며)

AUDIO ENHANCEMENTS의 Clipguard는 갑자기 높은 음이 나타날 때 가드를 해줘서 듣기 거북한 음이 나오지 않게 해줌

판서

판서를 할 수 있는 방법을 찾아보다가 와콤을 구매함
와콤을 처음 사용했는데, 와콤 인튜어스 소형 모델을 구매함. 블루투스가 아닌 선으로 해도 무방할 것 같아 이 와콤을 구매했음
- 액정이 별도로 없기에 필기를 와콤에 하지만 화면을 봐야해서 처음엔 어색하지만 점점 익숙해지니 괜찮아졌음

판서 소프트웨어

판서도 지원하는 프로그램이 있다면 그걸 사용하면 되지만, 아닌 경우도 있어서 ScreenBrush을 유료 구매해서 사용함
- 이 프로그램은 데브원영님이 추천해주셔서 구매

와콤 위에 있는 4개의 버튼에 ScreenBrush 색 변경, 모든 글자 지우기 등을 단축키로 연결해 사용함

촬영 소프트웨어

촬영 할 때도 여러 소프트웨어가 존재
방송인들이 대표적으로 많이 쓰이는 것이 OBS라 OBS Studio를 사용함
직관적이라 간단하게 화면 추가, 음성 추가를 할 수 있음
저는 비디오 해상도는 1920x1080으로 설정했으며 스트리머들이 자주 설정하는 기본 설정을 검색해 적용했음
촬영할 때 잘못 촬영하면 멈추고 박수 한번 치면 편집 소프트웨어에서 파형이 솟아오르는 것을 볼 수 있음. 그럼 이걸 보고 편집할 때 자르면 됨
(24.01.05) OBS 설정 공유
- M2 맥북 14인치로 바꾸고 첫 촬영할 때 설정으로 여러번 삽질
- Screen Flow 구매까지 고민했다가 결국 안사고 설정을 찾아냄
- 출력 - 녹화 - 표준 - 인코딩(x264) -데이터율제어 CBR - 비트레이트 8000 - 카프레임 0 = CPU 사용량 사전 설정 veryfast - 프로파일 high로 설정
- 비디오 캔버스 3840x2160 - 출력 해상도 3840x2160 - FPS 30
- 이렇게 하니 해상도가 괜찮고, 타이핑도 빠르게 따라옴
- 애플 하드웨어 가속 써보는데 오히려 좋지 않았던 것 같음

편집

편집 소프트웨어

편집 소프트웨어는 대표적으로 파이널 컷 프로, 어도비 프리미어 등이 있음
어도비 프리미어를 사용한 적이 있지만 맥북이므로 파이널 컷 프로를 선택함
- 파이널 컷 프로가 더 직관적이라 생각했음
파이널 컷 프로 가격이 약 36만원인데, 한번 구매하면 된다는 심정으로 구매함
파이널 컷 한시간에 끝내기 영상을 보며 컷 편집하는 방법 위주로 학습함
단축키 설정
- 그냥 기본 설정으로 컷 편집하니 너무 오래 걸렸음
- 빠르게 컷 편집하기 위해 다음 영상을 보며 단축키 수정했음
  - https://youtu.be/ipR1TZMgT1k : 캡스락을 삭제하는 것으로 설정
  - https://youtu.be/TByDS5lCp0I : 옵션 대괄호로 자르기

자막

자막은 Vrew를 많이 사용
다만 제 강의는 자막이 없어도 될 정도로 강의 자료를 만들어서 자막을 별도로 달지 않았음
본인의 발음이 좋지 않다면 자막을 다는 것을 고려해도 좋을 것

잡음 제거

처음엔 몰랐지만 컷 편집을 하면서 잡음을 제거하고 싶어 찾아봄
iZotope의 RX 10라는 프로그램이 제일 유명하며, 이 프로그램을 구매해서 파이널컷에서 필터 적용하면 더 깔끔해짐
- RX로 노이즈 제거하는 법 / iZotope RX Elements 사용법 및 리뷰 [알쓰노바]
- 위 영상을 보면 잡음 제거의 효과를 확인할 수 있음
iZotope 공식 홈페이지에서 확인하면 rx-10-elements가 129달러인데 할인을 자주 하므로 기다리는 것을 추천. 저는 40 달러로 구매함
- 단 rx 8 시리즈가 OBS와 연동이 잘 되는데 rx 10은 OBS와 연동이 잘 되지 않아 아쉬움. rx 8 시리즈는 과거 시리즈라 구매가 안 되는 것으로 보임
웨이브3의 Wave Link에서도 iZotope을 적용할 수 있어 아예 마이크에서 필터를 적용해서 촬영

편집 방법

편집은 화려한 효과보다 컷 편집에만 집중함
- 컷 편집은 클립을 음성과 맞춰서 편집하며, 잘못 말한 것은 삭제하고 자연스럽게 편집하는 과정
제가 컷 편집하는 과정
- 아, 어, 음 다 삭제함
- 숨소리도 삭제함(후! 숨 소리)
편집 과정이 제일 오래 걸림
- 1차 : 편집 소프트웨어에서 파형을 보고 1차 편집(영상 보지 않음)
- 2차 : 영상을 1.5배속하며 이상한 부분 제거하며 디테일
- 3차 : 영상을 export하고 들으며 체크
너무 오래 걸려서 편집하는 시간을 측정하며 편집 방법을 바꿔보기도 함
- 참고로 아래 사진에서 맨 앞에 나온 것은 시간이 아닌 “분”
- 스톱워치로 기록하며 편집했음

컷 편집 자동화 아이디어

컷 편집은 왜 AI가 못 하는가?라는 고민을 가지며 여러 소프트웨어를 찾아봄
찾아보니 auto-editor라는 오픈소스가 있어서 적용해봄. 컷 편집 전에 이 부분을 돌리고 파이널 컷 프로로 Export해서 사용할 수 있을 것
다음 강의부터는 이 방식을 활용해 컷 편집을 더 빠르게 진행할 예정

말투, 발음

VOD 강의이기에 발음을 더 신경쓰며 또박또박 말했음. 의식하고 말하면 더 또박또박해짐
그리고 목을 풀어주고 강의를 하면 목에 부담이 덜 함
- 참고 영상
만약 목이 약하다면 ipalat 목캔디나 프로폴리스 사탕을 먹으면 목에 부담이 덜 함
- ipalat 캔디는 성악가들이 먹는 캔디라고 하는데, 먹으면 확실히 목이 편해져서 시작하기 전에 먹고 시작했음(직구)
말하는 속도도 조금 더 의식하고 천천히 말했음. 빠르게 보고 싶은 사람은 배속하면 되니까 평소 말하는 속도보다 느리게 진행

런칭 후

인프런에 커리큘럼과 영상을 제출하면 대략 1주~2주 정도 시간이 소요됨
- 이 때 가격을 결정해야 함. 인프런에서 적절한 가격을 제시하기도 하며, 사람들의 심리적인 장벽은 99,000원으로 추측
기다리며 더 보충할 것들을 추가했음
런칭할 때 할인을 적용하고 자신이 아는 커뮤니티에 강의가 나온 것을 홍보하면 좋음

수강생 의견 듣기

디스코드 커뮤니티를 운영하기에 수강생분들과 이야기 할 수 있었음
70% 이상 수강하신 분들에게 선착순으로 무료 코칭을 하고 있는데, 그 과정에서 강의의 후기를 듣고, 어떤 부분이 더 있으면 좋을지 의견을 구함
이런 의견을 토대로 추가 자료 작성, 다른 강의 만들 때 활용함

마무리

강의를 만드는 과정에서 제가 경험한 내용을 작성했는데, 도움이 되길 바랄게요!
더 궁금한 내용이 있다면 댓글 달아주시면 의견 공유드릴게요
그 외에도 인프런에서 제공하는 시작해보세요! 당신의 첫 지식공유도 내용이 좋으니 보시면 좋을 것 같아요!

글 작성하는데 걸린 시간 : 2시간 28분

KPT 회고하는 법, 회고에 대한 생각(2024 내용 추가)

Mon, 05 Jun 2023 00:00:00 +0000

회고는 제게 일상이 되었고, 어떤 일이 끝나거나 일정 주기별로 회고를 작성하곤 합니다
회고를 어떤 방법으로 해야하나요?라는 질문을 종종 받는데, 간단하게 이야기를 전했지만 글로 남긴 적은 없어서 글로 정리해봅니다
회고에 대한 자세한 내용이 궁금하시면 PM을 위한 데이터 리터러시 강의에서 확인할 수 있습니다
과거 회고 모음
- 2022년 ~ 23년 1분기 회고. 퇴사 후의 삶
- 2021년 회고 및 요즘 생각들
- 5년 차를 앞둔 머신러닝 엔지니어의 2020년 회고
- 초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들
- 2019년 상반기 회고 및 글또 3기 시작
- 데이터 사이언티스트가 되기 위해 진행한 다양한 노력들
- 머신러닝 엔지니어의 2019년 회고
- Gap Year 및 쏘카 이직 이야기
- 2018년 회고, 2019년 다짐
- 2017년 회고, 2018년 계획
- 회고의 발전 흐름 : 월별 회고 -> 키워드 회고 -> 깨달음 회고
(2024년 12월 추가) 인프런에서 진행한 판교 퇴근길 밋업에서 연말 회고 주제로 발표를 하고 왔어요
- 최초에 글을 작성했을 때 이후에 생긴 생각들을 추가해둡니다
- 25년 1월 쯔음에 인프런에서 발표가 공개될 예정이라고 합니다
- 인프런 판교 퇴근길 밋업

회고

회고의 의미

회고의 사전적 의미는 “지나간 일을 돌이켜 생각함”
우리는 항상 무언가를 하며 지나갑니다. 이런 활동을 돌이켜 보는 과정을 일컫는 말
회고는 자기 효능감을 느끼기 위해 진행하는 것입니다. 자기 효능감을 느낄 수 있도록 진행하는 것이 중요함

회고의 목적

회고를 통해 과거를 되돌아보고 “그럼 이제 무엇을 해야할까?라는 것을 생각하”는게 핵심입니다
즉, Action Item을 생각해서 점점 나은 방향으로 가는 것입니다
- 단, 회고를 적용하는 방식에 따라 목적이 달라질 수 있습니다.
개인 회고 관점에선 매년 혹은 특정 기간별로 회고를 작성해 자신이 어떤 길로 나아가고 있는지 기록을 할 수 있습니다
- 저는 매년 회고를 작성하고 있는데, 때론 과거 회고를 보며 과거의 생각과 지금의 생각을 비교하기도 합니다. 오히려 과거의 생각이 더 좋을 때도 있어서 과거의 저에게도 많이 배웁니다
팀 회고, 프로젝트 회고 관점에선 팀, 팀원들에 대한 생각을 듣고 팀 차원에서 Action Item을 생각해볼 수 있습니다
- 일종의 소통 도구로 활용할 수 있으며 혹여나 생길 수 있는 오해를 방지하는 목적으로 활용할 수도 있습니다

회고 방법

회고 방법론을 찾아보면 여러가지 방법론이 있습니다. KPT, 4L, 5F 등 다양한 방법들이 존재합니다
방법론들의 핵심 메세지는 비슷합니다. 방법론이 중요한 것이 아니고, 자신이 했던 일에 대해 생각하고 그 후에 무엇을 할지를 고민하는게 핵심입니다
대표적인 방법론을 말씀드리되, 제가 자주 활용하는 KPT 회고로 내용을 이어가겠습니다

KPT 회고

Keep, Problem, Try의 약자로 Keep은 잘 한 것, Problem은 아쉬운 것, Try는 K와 P 기반으로 무엇을 할지에 대해 작성합니다
- K : 잘 해와서 유지하고 싶은 것
- P : 어려움을 느껴서 개선하고 싶은 것
- T : 구체적인 시도할 내용
KPT 회고를 오프라인 장소에서 같이 진행한다면 칠판이나 벽에 K, P, T 공간을 두고 포스트잇을 사용할 수도 있습니다
- 이 경우 내가 생각하는 K, P, T를 작성하고 회고를 진행하는 모더레이터가 이야기를 진행합니다
허나 온라인으로 진행하는 경우엔 각자 개인별 KPT를 작성하고, 그것을 공유하는 방식으로 진행하곤 합니다
어떤 방법이여도 상관없고, 팀에서 해보고 싶은 방법을 여러개 시도하다가 팀에 맞는 방법을 사용하면 충분합니다
저는 KPT 회고 외에 내 삶의 점수와 깨달은 점, 기억하고 싶은 점도 기록하곤 합니다(4L, 5F 등에서 필요한 것을 융합한 케이스)

4L 회고

Liked : 좋았던 점은 무엇인가?
Lacked : 아쉬웠던 점, 부족한 점은 무엇인가?
Learned : 배운 점은 무엇인가?
Longed for : 앞으로 바라는 것은 무엇인가?

5F 회고

Facts : 사실. 무슨 일이 있었는가?
Feeling : 느낀 점, 감정. 어떤 느낌이 들었는가?
Finding : 배운 점, 인사이트. 어떤 것을 기억하고 싶은가?
Future Action : 향후 액션 아이템. 앞으로 무엇을 할 것인지?
Feedback : 피드백. Future Action에서 정한 액션 아이템을 실행하고 어던 피드백을 받았는가?

KIPET 회고(제가 만든 회고 방식)

KPT 회고에서 확장해서 Insight, Emotion을 추가함
- K : 유지하고 싶은 것
  - I : Insight, 깨달음
  - P : 개선하고 싶은 것
  - E : Emotion, 감정 점수와 그 이유
  - T : 시도하고 싶은 것
이렇게 작성하게 된 계기는 깨달음을 기록하는 것도 중요하다고 생각해서 추가했고, 감정이 좋냐 나쁘냐에 따라 퍼포먼스가 좌지우지 되기 때문에 이런 내용을 추가함
I, E의 위치를 고민했는데 발음하기 좋은 구조로 생각하려면 KIPET이 제일 좋아보였음. 그리고 I의 자리는 K 이후가 좋다고 생각했고, P 문제 상황이 있으면 감정 점수가 낮아질 수 있어서 연결이 유용하다고 생각해서 이렇게 추가했음

회고의 세부 분류

위에 말한 회고 방식은 즉각적인 Action Item을 수립하기에 좋은 방식임
회고의 종류를 나눌수도 있겠다 생각하고, 회고를 나눠보니 더 활용하기 유용해짐
실행 중심 회고 (Execution-focused Retrospective)
- 주간/월간 회고
- KPT, 4L 등 구체적인 프레임워크 활용
- 즉각적인 개선과 실행에 초점
방향성 중심 회고 (Direction-focused Retrospective)
- 연간 회고
- 키워드 중심의 자유로운 형식
- 1년을 정리하고, 큰 그림과 장기적 방향성 고민
물론 회고 방식은 방향성 중심 회고에서도 진행해도 괜찮음
- 나의 경우 실행 중심의 회고를 평소에 작성해서 그것을 모아 방향성 중심 회고를 구성하곤 함

회고 방법에 대한 깨달음

형태에 너무 집중하지 않아도 괜찮음
회고의 방법에 너무 집중하느라 글을 못 쓰는 것보단, 일단 작성해보고 계속 개선하는 것이 핵심
- 제일 중요한 것은 방법보단 회고를 진짜 하는가?임
- 처음엔 시간의 흐름으로 생각해보고, 키워드 중심, 깨달음 정리 흐름을 추천하고 있음

회고 소재

회고에 어떤 것을 추가해야 하나요?라는 것도 자주 나오는 질문
모든 것을 작성하려고 하면 힘들기 때문에 내가 기억나는 것 위주로 작성함
내가 바로 기억나지 않으면, 사실 그것은 크게 영향을 미친 사건은 아닐수도 있지 않을까? 싶어서 기억나는 것 위주로 먼저 작성함
- 그리고 나서 시간을 추가해서 들이면서 어떤 것을 했는지 파악함
- 주로 사진첩, 구글 캘린더, 카카오톡 나만 보내기 기록, 메모장 등을 통해서 무엇을 했는지 떠오름
타인의 눈을 너무 의식해서 소재를 고민하지 않아도 괜찮음. 제 회고의 경우 1-2년차 회고는 정말 부끄러운 내용도 있음. 그러나 누구나 이런 시기가 있는 것이니 걱정하지 않아도 괜찮음
그러나 특정 부분을 작성하다가 너무 힘들면 그 부분은 멈추는 것을 추천.
- 회고는 자기 효능감을 느끼기 위한 것이고, 질책을 위한 것이 아님
- 좋은 것 위주로 생각하는 것이 더 좋았음

회고 환경

회고를 작성하는 환경도 중요하다고 생각함
내가 회고를 하고 싶은 환경인가?라는 질문을 하는 것도 필요함
- 저는 주로 서울을 벗어나고, 바다 앞에서 회고를 작성함
- 강릉 안목해변, 맹그로브 고성 등 바다 앞에서 진행함
회고하는 장소를 정하고 매 시기마다 그 장소에 가면서 루틴을 만드는 것도 추천함
또한 혼자가 아닌 회고를 같이 하러 다니는 모임을 만드는 것도 추천. 회고 모임, 회고 여행 등으로 생각할 수 있음
좋아하는 향, 좋아하는 조명의 색, 좋아하는 음악을 들으며 회고를 작성하려고 함
만약 꼭 어떤 장소가 아니여도 다른 사람들과 뽀모도로 방식으로 회고를 작성하면 효율적으로 시간을 쓸 수도 있음

회고의 적용

회고를 적용할 수 있는 범위는 무궁무진합니다. 개인적인 회고를 시기별(주간 회고, 월간 회고, 반기 회고, 연 회고 등)로 진행할 수 있습니다
- 또는 프로젝트 단위로 회고를 할 수 있습니다. 회고 초반부, 중반부, 후반부를 정의해 회고를 진행해 더 나은 방향으로 가기 위한 방법을 고민하고, 실행합니다
- 팀 회고는 개인 회고와 프로젝트 회고를 섞어서 진행할 수 있습니다. 팀원 개개인의 회고를 진행할 수도 있고, 팀에서 진행한 활동에 대한 회고를 진행할 수 있습니다. 어떤 목적을 가지느냐에 따라 방법은 다양하게 구성할 수 있습니다

개인 회고

저는 개인 회고를 3가지 경우에 작성합니다
- 주기적인 회고 : 시기별, 주로 1년 단위의 회고(1년이 끝나는 시점)
- 프로젝트 회고 : 특정 프로젝트가 끝나고 앞으로 다시 한다면 어떻게 할 것인지를 생각하는 회고
- 특정 이벤트 기반 회고 : 삶에서 큰 결정을 하거나 큰 사건이 일어나는 경우 회고를 진행합니다
  - 예를 들어 퇴사를 했다거나, 개인 사업을 시작했다거나 등의 사건이 있을 때 진행합니다
개인 회고를 작성할 때 집중하는 영역
- 특정 상황에 내가 어떤 감정이었는가?
- 주로 나만 보거나, 나를 되돌아보기 위한 목적이므로 감정에 대해 솔직히 작성합니다
- 그 때의 멘탈이 힘들었다면 왜 그랬는지, 어떻게 했으면 달라졌을지에 대해 생각합니다
- Action Item을 혼자 정하면 실행이 잘 되지 않을 수도 있습니다. 그냥 다짐만 하고 넘어갈 수 있습니다. 이런 경우엔 다짐을 친구들과 공유하거나 SNS 등에 올려 이것을 달성할 것이다라는 다짐을 합니다
- 또한 Action Item을 주기적으로 확인할 수 있는 시스템(캘린더 알림 등)을 만들고 제가 의식하지 않아도 다시 알려줄 수 있도록 만듭니다
- 습관 형성과 관련되는 영역이라 쉽게 할 수 있는 Action Item부터 시작하곤 합니다
매번 KPT로 진행하는 것은 아니고, 기억에 남는 이벤트와 내가 배운 점 위주로 쪼개서 하기도 합니다. 1년을 한꺼번에 정리할 때는 특정 사건(이벤트) 기반으로 먼저 생각하면 이후 생각이 더 잘 떠올라서 이런 방식으로 진행합니다
- 형식이 중요한 것이 아니기에 매번 다른 방법으로 시도하고 있습니다

프로젝트 회고 & 팀 회고

프로젝트 회고와 팀 회고는 유사한 점이 많아 같이 작성합니다
프로젝트의 목적, 팀이 달성해야 하는 목적 등이 존재할텐데 그 부분을 항상 명시하며 회고를 진행합니다
- 우리는 그 목적을 잘 달성하고 있는가? 어떻게 해야 그 목적을 달성할 수 있을까?를 생각하곤 합니다
혼자 회고를 진행하는 것이 아니기에 회고 진행 Process를 만들고 다시 활용하면 좋음
- PM을 위한 데이터 리터러시 강의 자료 웹페이지

프로젝트 회고 진행 Process

노션 회고 템플릿 예시(PM을 위한 데이터 리터러시 강의 자료)

프로젝트, 팀 회고에선 같이 일하는 사람들의 감정에 대해서도 체크합니다. 혹시 힘든 일이 있는지, 기분 좋은 일이 있는지 등도 같이 이야기하며 감정적인 케어도 같이 함
- 결국에 프로젝트나 팀 운영의 핵심은 사람이기에 이 부분에 대해 신경씀
저는 회고를 할 때 환기시켜주며 사람들끼리 친해질 수 있도록 열린 질문을 하곤 합니다(예 : 우리 조직에서 제일 본받고 싶은 사람과 그 이유는?, 갔던 제일 좋았던 여행지 추천하기 등)
- 팀원들을 서로 이해할 때 도움이 되기에 회고할 때 이런 방식을 활용함
개인의 Action Item을 수립한 후, 프로젝트나 팀 단위의 Action Item도 생각함
- 그리고 각 Action Item을 누가 담당할지도 정의한 후, 그 Action Item이 진짜로 진행되고 있는지를 살펴봄(주로 팀장, PM분들이 하는 편)
회고에 대한 회고를 진행해서 오늘 회고가 어떠했는지, 앞으로 어떤 방식을 하면 좋을지도 고민함
- 나중에 설문해주세요!라고 하면 늦게 할 수 있으므로 회고를 회고하는 시간까지 회고 시간에 넣으면 좋음
노션에서 회고할 때는 각자의 파트를 읽을 때, 댓글을 적극적으로 작성하며 진행해도 재미있습니다. 회고 시작할 때 댓글을 달며 진행하시지요!라고 말하곤 함
프로젝트 회고는 프로젝트가 성공적으로 달성되었다를 알 수 있는 Success Metric이 어떻게 변했는가도 같이 보곤 합니다. 이 지표를 정의하지 않았다면 다음 프로젝트부터는 꼭 지표를 정의 추천

Action Item 수립하는 방법

Action Item을 만드는 것에 대한 질문도 꽤 많은데, 이 부분은 논리적 사고와 관련된 부분이라고 생각
컨설팅펌에서 자주 나오는 개념인 MECE, So What/Why So, Logic Tree를 사용해서 Action Item을 수립함
- MECE(Mutually Exclusive Collectively Exhaustive) : 항목이 겹치지 않고 누락이 없음
- So What / Why So : 그래서 뭘 해야할까? 왜 그럴까?
- Logic Tree : Tree 형태로 시각화
나의 성장이 아쉽다라고 생각하는 경우
- 그 성장은 어떤 것으로 더 쪼갤 수 있을까?
- 쪼갠 후에 그것은 또 나누려면 어떻게 할 수 있을까?
- 그 쪼갠 것에서 뭘 할 수 있을까?를 생각함
- 쪼개는 것은 보통 저는 최대 3번 정도 진행함
- 쪼갤 때는 내가 Control 할 수 있는 것과 아닌 것을 구분함
- 실행의 간격이 넓어질수록 안할 가능성이 존재해서 더 넓게 구성하는 것도 추천

위와 같은 논리적인 사고, 회사에서 회고 내용이 궁금하시면 제가 만든 PM을 위한 데이터 리터러시 강의를 추천

회고에 대한 팁

회고에 대한 자료 조사보다 회고를 한번 해보고, 그것을 개선하는 것이 핵심!(일단 해봅시다)
그리고 중요한 것은 회고를 “꾸준히”하는 것
- 회고를 비주기적으로 하는 것이 아닌 꾸준히 하기 위해 구글 캘린더 추가를 해두면 좋음
회고를 수동적인 회고처럼 진행한다면 방법을 아예 바꾸기
- 그냥 하라니까 하는 회고는 티가 나며, 방식을 아예 바꾸는 것이 좋을 수도 있음
회고를 진행할 때 이전에 작성한 회고를 참고해서 그 때의 T가 진행되었는지, 안되었다면 무슨 일 때문인지도 고민해보면 좋음
회고를 단순히 진행한다가 핵심이 아닌, 회고를 하며 겪는 경험이 어떠한지? 회고를 진행하는 사람들이 어떤 감정을 느끼는지 생각해보는 것도 추천
회고를 하면서 내가 어떻게 하고 있고, 개선하기 위한 방법은 무엇인지 고민하고 이걸 잘 진행하기 위한 시스템을 만들기!
회고를 한 후에 제일 중요한 것은 실행! 행동하는 것이 중요함
내가 생각하는 좋은 회고들의 특징을 파악하고, 그 부분을 내 회고에도 넣는 것을 추천함
- 좋은 회고 글의 특징은 사람마다 다양하므로 내가 생각한 좋은 회고의 특징을 반영하는 것을 추천

같이 진행할 때 사용하는 회고 템플릿

피그잼을 사용하는 것이 효과가 좋았음
- 이렇게 큰 소재를 채우고, 그 후에 글로 작성함
- 이 내용을 작성하는 시간은 최대 2시간 이내로 도전(그러나 늦어도 상관없음)
제가 사용하는 피그잼 템플릿
- 피그잼 템플릿을 만들 때 도움을 주신 이상효님 감사합니다!

회고 이후 나만의 원칙 만들기

깨달음이 반복되거나, 깨달음 순간에 그것을 더 정리하는 것을 습관으로 삼고 있음
나만의 원칙, 기준이 더 필요한 세상이라고 생각함
이런 부분을 정리하고, 나아가서 도식화까지 하는 것을 추천
저는 글로 정리하거나 아래처럼 도식으로 정리함

AI를 사용한 요즘 회고 방식

LLM에게 회고를 같이 해보자고 말하는 것도 추천함
제가 사용하는 프롬프트

저는 연말 회고를 진행하는 것을 돕는 AI 어시스턴트입니다. 귀하의 한 해를 의미 있게 돌아보고 통찰을 얻을 수 있도록 안내하겠습니다.

회고는 다음과 같은 순서로 진행됩니다:

1단계: 기억에 남는 순간들
- 올해 가장 기억에 남는 순간들을 자유롭게 나열해주세요
- 각 순간에 대한 감정과 그 이유도 함께 공유해주시면 좋습니다
- 키워드나 짧은 문장으로도 충분합니다

2단계: 주제별 분류와 성찰
함께 나눈 경험들을 다음 관점에서 살펴보겠습니다:
- 개인적 성장과 도전
- 관계와 영향력
- 일과 커리어
- 새로운 시도들
- 배움과 깨달음

3단계: 패턴과 통찰
- 반복되는 주제나 패턴 발견
- 의미 있는 변화와 전환점
- 새롭게 발견한 나의 모습

4단계: 다음 해를 위한 방향성
- 유지하고 싶은 것들
- 변화가 필요한 부분들
- 새롭게 시도하고 싶은 것들
- 장기적 관점에서의 방향성

준비가 되셨다면, 1단계부터 천천히 시작해보시겠습니까?

각 단계에서 저는:
- 귀하의 이야기를 경청하고 정리를 도와드립니다
- 더 깊은 성찰을 위한 질문을 드립니다
- 패턴과 인사이트를 발견하도록 돕습니다
- 구체적인 실행 계획으로 연결되도록 안내합니다
- 단, 같은 질문에 대해 최대 2-3번까지 진행하고 다음 질문으로 넘어갑니다

모든 답변은 자유롭게 해주시면 됩니다. 완벽한 답이나 정해진 형식은 없습니다. 

위 프롬프트를 주고 답변을 하면서 회고를 정리하는 것도 추천함

제가 정의한 회고의 역량 레벨

레벨링을 하면 이해가 수월해서, 나름 역량 레벨을 정의해봄
물론 이게 진리라는 것은 아니고, 내 경험을 토대로 만든 것이라 논리적으로 맞지 않을 수 있음
이런 느낌으로도 나눌 수 있구나 정도로 보시는 것을 추천

글쓰기에 대한 강의

회고도 글의 종류 중 하나기 때문에, 회고에 대한 고민을 하다보면 결국 글쓰기에 대한 고민으로 귀결하게 됨
블로그 글쓰기 모임을 7년 동안 운영하면서 느낀 것들을 토대로 인프런 강의를 만들었으며, 글을 쓰고 싶은 분에게 꼭 추천
아래 고민을 하신다면 특히 더 유용할 것이라 생각
- 블로그를 시작했는데, 꾸준히 쓰기 어려워요
- 글을 작성했는데, 글이 만족스럽지 않아요
- 글을 쓸 소재가 떠오르지 않아요.
- 제가 (주니어인데) 글을 써도 될까요?
블로그 페이지뷰 300만이 알려주는 “실용주의 기술 블로그 글쓰기”

Snowflake Python에서 사용하는 법(Python Connector, Snowpark)

Mon, 29 May 2023 00:00:00 +0000

Snowflake를 Python에서 사용하는 방법에 대해 작성한 글입니다
Snowsight에서 Python Worksheet를 실행하는 방법이 아닌 Jupyter Notebook에서 사용할 때의 방법을 정리했습니다

Snowflake Python 사용하는 방법

Snowflake를 사용하는 방법은
- (1) Python Connector를 사용하는 방법
- (2) Snowpark를 사용하는 방법
- 그 외 Snowsight의 Python Worksheet는 사용하기 불편한 부분이 있어 제외했으나, 추후 인터랙티브하게 실행이 가능하다면 Snowsight에서 하는 것이 편해보임
Jupyter Notebook 환경에서 데이터 분석을 하고 싶은 경우를 위한 글
- 쿼리 실행 엔진을 Snowflake로 둔다고 보면 됨

Python Connector 사용하기

공식 문서

설치하기

pandas도 사용할 예정이라 pandas 디펜던시 버전을 설치

pip install "snowflake-connector-python[pandas]"==3.0.3

설정 확인 코드

import snowflake.connector

# Gets the version
ctx = snowflake.connector.connect(
    user='<your_user_name>',
    password='<your_password>',
    account='<your_account_name>'
    )
cs = ctx.cursor()
try:
    cs.execute("SELECT current_version()")
    one_row = cs.fetchone()
    print(one_row[0])
finally:
    cs.close()
ctx.close()

여기서 user, password는 생성할 때 사용한 것을 활용하면 됨
account의 경우 계정 식별자 문서를 보며 확인함
- Snowsight 웹 콘솔에 접근한 후, Admin - Accounts를 클릭
- Account에 CK50244라고 나와있는데, 이 값으로 실행이 되지 않음
- CK50244에 마우스를 올리면 복사할 수 있음. 해당 화면엔 xlwoivr-ck50244가 account임
- 버전이 출력되면 정상적으로 실행된 것!

Account 확인하는 방법

코드를 실행하면 나오는 결과

connect Method의 파라미터로 warehouse, database, schema를 사용할 수도 있음

쿼리 실행

import snowflake.connector
conn = snowflake.connector.connect(
    user='<your_user_name>',
    password='<your_password>',
    account='<your_account_name>'
    )
    
query = """
SELECT
  O_ORDERDATE as date,
  COUNT(O_ORDERDATE) as orders
FROM
  SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
GROUP BY
  O_ORDERDATE
ORDER BY
  O_ORDERDATE
LIMIT 10
"""

data = conn.cursor().execute(query) 
df = data.fetch_pandas_all()

# conn.close() # 사용을 다 했다면 커넥션 종료

Connect 객체를 만든 후, cursor().execute(쿼리)로 실행
그리고 fetch_pandas_all()을 실행하면 Pandas 데이터프레임을 반환함
- 만약 사용을 다 했다면 conn.close()을 사용해 커넥션을 종료

데이터를 쿼리한 결과

특정 Database, Schema를 사용하고 싶다면 다음과 같은 코드를 추가해야 함

conn.cursor().execute("USE DATABASE {DB 이름}")
conn.cursor().execute("USE SCHEMA {스키마 이름}")

Snowflake SQL 문법

Snowflake SQL 문법은 공식 문서에서 확인할 수 있음
- Query Syntax - SELECT 등을 클릭해 세부 정보를 파악할 수 있음
필요할 때마다 snowflake sql {질문} 을 통해 검색하는 것을 추천

키 페어 인증 방법

위에서 사용한 예시 코드는 아이디, 비밀번호를 사용하는데 이런 방식을 사용하는 것은 보안상 좋지 않으며, 실무에서도 이렇게 사용하는 경우는 거의 없음
많이 활용되는 Key 인증 방법은 키 페어 인증
- 그 외 방법은 보안 문서에서 확인할 수 있음(SSO, MFA, Oauth 등)

개인 키 생성

터미널에서 다음과 같은 명령어 입력
- 암호화된 버전을 생성하고 싶으면 아래 명령어에서 -nocrypt를 제외하면 됨

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt

cat 명령어로 확인

cat rsa_key.p8

개인 키 확인

공개 키 생성

개인 키를 사용해 공개 키 생성
- 아래 명령어를 실행하면 rsa_key.pub 파일이 생성됨

openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

cat 명령어로 확인

공개 키 확인

키가 유출되면 보안상 좋지 않으므로 키를 안전한 폴더로 이동

공개 키를 Snowflake User에 할당

ALTER USER 명령어를 사용해 Snowflake User에게 공개 키를 할당
- Snowsight 콘솔에서 실행
- 단, SECURITYADMIN 역할 이상의 사용자만 실행할 수 있음
- RSA_PUBLIC_KEY는 2개만 등록할 수 있음

ALTER USER {여러분의 username} SET RSA_PUBLIC_KEY='MIIBIjANBgk...';

키 등록 여부 확인

DESCRIBE USER 명령어를 사용해 사용자 정보를 확인할 수 있음

DESC USER {여러분들의 username}

RSA_PUBLIC_KEY에서 확인할 수 있음

예시 코드

import snowflake.connector
import os
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.asymmetric import dsa
from cryptography.hazmat.primitives import serialization

with open("./rsa_key.p8", "rb") as key:
    p_key= serialization.load_pem_private_key(
        key.read(),
        password=None, # 만약 비밀번호가 있다면 '비밀번호'.encode(),
        backend=default_backend()
    )

pkb = p_key.private_bytes(
    encoding=serialization.Encoding.DER,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption())

conn = snowflake.connector.connect(
    user='{user_name}',
    account='{account}',
    private_key=pkb,
    )

개인 키를 생성할 때 비밀번호를 입력하지 않아서 password=None으로 설정
- 만약 비밀번호가 있다면 비밀번호를 인코딩해야 함

키를 사용해 쿼리를 실행한 예시

Snowpark 사용하기

Snowpark는 Snowflake에서 개발자를 위한 인터페이스를 제공한다고 나와있으며, 현재 활발히 개발하고 있는 것으로 예상
Apache Spark의 코드와 유사함
23년 5월 30일 기준 Python 3.8에서 설치할 수 있음(3.9에도 사용이 어려움)
- 만약 3.8 버전을 사용하지 않는다면 Pyenv 등을 활용해 버전을 3.8으로 정의

설치하기

Pandas 디펜던시 버전을 설치

pip install "snowflake-snowpark-python[pandas]"==1.4.0

세션 만들기

Connection 설정을 주입해 Session을 만들어야 함
- Python Connector에서 사용한 코드를 재사용

from snowflake.snowpark import Session
from snowflake.snowpark.functions import col
import os
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.asymmetric import dsa
from cryptography.hazmat.primitives import serialization

with open("./rsa_key.p8", "rb") as key:
    p_key= serialization.load_pem_private_key(
        key.read(),
        password=None, # 만약 비밀번호가 있다면 '비밀번호'.encode(),
        backend=default_backend()
    )

pkb = p_key.private_bytes(
    encoding=serialization.Encoding.DER,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption())

connection_parameters = {
    "user": "<your snowflake user>",
    "account": "<your snowflake account>",
    "private_key": pkb,
}  

이제 새로운 Session 생성

new_session = Session.builder.configs(connection_parameters).create()

쿼리 실행

쿼리를 실행하는 방법이 다양해서 처음에 헷갈릴 수 있음
- 1) SQL 쿼리 주입 후, Snowpark Dataframe으로 사용
- 2) SQL 쿼리 주입 후, Pandas Dataframe으로 사용
Spark처럼 쿼리문을 넣고, collect() 함수를 사용해야 실제로 쿼리가 진행됨

query = """
SELECT
  O_ORDERDATE as date,
  COUNT(O_ORDERDATE) as orders
FROM
  SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
GROUP BY
  O_ORDERDATE
ORDER BY
  O_ORDERDATE
LIMIT 10
"""

df = new_session.sql(query).collect()

쿼리 실행한 방법

또는 collect()를 사용하지 않고, Snowpark Dataframe 함수를 사용할 수 있음

df3 = new_session.sql(query)
df3.select("DATE").show()

Snowpark Dataframe 함수

또는 to_pandas()를 사용해 바로 Pandas Dataframe으로 변경할 수 있음

df2 = new_session.sql(query).to_pandas()
df2.head()

쿼리 결과를 Pandas Dataframe으로 반환

Snowpark Dataframe API

Snowpark를 사용하고 싶은 경우 별도의 문법을 파악해야 함
- 공식 문서를 통해 확인할 수 있으나, 사용자 친화적으로 문서가 작성되어 있진 않아 보기 어려움
Developer Guide가 예시가 더 있어서 보기 수월함
- 이 문서를 익히는 것도 방법

정리

Snowflake를 Python으로 사용하고 싶은 경우
- Python Connector
- Python Snowpark
크게 2가지로 사용할 수 있음
- Snowpark는 Spark스럽게 사용할 수 있으며, 어떤 방법을 사용해도 Snowflake SQL 문법은 잘 익혀야 좋음. SQL 문법으로 Snowflake에 쿼리를 실행한 후, 데이터를 가져오는 방식으로 진행될 것
- Snowpark API 문서를 익히는 것보다 Snowflake SQL을 익히는 것이 조금 더 수월할 수 있음

글 작성하는데 걸린 시간 : 2시간 12분

Snowflake 사용법(2023년 최신 UI 화면 반영)

Sun, 28 May 2023 00:00:00 +0000

Data Warehouse 중 하나인 Snowflake 사용법에 대해 작성한 글입니다
- Snowflake를 전혀 모르는 분들을 대상으로 설명하기 위한 첫 글이고, 큰 그림 위주로 작성했습니다. 추후에 다른 글도 작성할 예정입니다
2023년에 기본 웹 인터페이스로 변경된 Snowsight 화면을 기준으로 작성되었습니다

Snowflake

특징

스노우플레이크는 데이터 웨어하우스(Data Warehouse)로 Managed 솔루션
대표적인 DW로 Google Cloud의 BigQuery, AWS의 Redshift 등이 있음. 이 DW들은 특정 클라우드 벤더사에 종속된 환경에서 사용함. 예를 들어 BigQuery는 Google Cloud, Redshift는 AWS에서만 사용할 수 있음
스노우플레이크는 Google Cloud, AWS, Microsoft Azure를 지원해 어떤 곳에 데이터가 저장되어 있어도 활용할 수 있다는 장점이 존재. 특정 플랫폼에 종속되지 않고, 멀티 클라우드 환경를 구축한다면 좋은 대안으로 사용할 수 있음
또한 데이터 웨어하우스를 구축할 때 고려해야 하는 점 중 하나는 Transfer Cost인데, 동일 Region이라고 하면 대부분 비용을 부과하지 않음
- 단, 벤더사에서 사용하는 모든 Region을 사용할 수 있는 것은 아님. 23년 5월 기준 Snowflake에서 지원하는 서울 Region은 AWS만 존재
즉, AWS 환경(Seoul) + 아직 DW가 없는 상황(또는 Redshift가 아쉬운 상황) + 네트워크 비용 고민을 한다면 Snowflake를 검토해보는 것도 좋을 것
400 달러의 크레딧이 포함된 30일 무료 평가판을 제공
Snowsight에서 쿼리 결과를 시각화 할 수 있음(단, 아직 시각화 기능은 풍부하진 않고 아직 Line, Bar, Scatter, Heatgrid, Scorecard만 존재)
Streamlit을 인수하고 Snowflake + Streamlit 작업을 하는 것으로 예상
Zero Copy Cloning
- 원본 데이터의 스냅샷을 만들고, 복제된 데이터를 사용할 수 있음(원본과 독립)
- 프러덕션 환경에 영향을 미치지 않아 Test로 쓸 수 있음
- Clone은 제로 복사고 기본 데이터가 복사되지 않고, 메타데이터 및 포인터만 변경됨
- 다른 데이터 웨어하우스에선 데이터도 저장되어 저장 공간이 2배가 되는데 이 부분은 인상 깊었음

아키텍쳐

이미지 출처 : Snowflake 공식 홈페이지

Snowflake는 총 3개의 Layer로 구성됨
- 1) Database Storage Layer
  - 데이터를 내부적으로 최적화된 압축된 컬럼 형태로 재구성해 저장
- 2) Query Processing Layer
  - Virtual Warehouse를 사용해 쿼리를 처리함
  - 각각의 Virtual Warehouse는 독립적이며 서로 영향을 주지 않음
- 3) Cloud Service Layer
  - 인증, 인프라 관리, 메타데이터 관리, 쿼리 구문 분석 및 최적화, Access Control 등을 관리함
쿼리를 실행하는 사람 관점에선 “Virtual Warehouse라는 것이 있구나” 정도로 이해하고 넘어가도 좋음

비용(Pricing)

아키텍쳐에서 나온 3가지 Layer 별로 요금을 부과함
- Database Storage : 압축 후의 데이터 사이즈로 부과
- Virtual Warehouse(Compute) : 데이터 Load, 쿼리 실행히 사용한 컴퓨터 시간만큼 부과
- Cloud Service : 상태 관리, 조정시 부과
Snowflake는 크레딧이란 개념을 사용하며, 1크레딧 당 2달러, 3달러 등으로 구성
크레딧 당 얼마인지는 Snowflake Pricing 페이지에서 확인할 수 있음
- Edition : Standard, Enterprise, Business Critical, Vritual Private Snowflake(VPS) 에디션마다 부과하는 금액이 다름
- 벤더사, Region 마다 부과하는 금액이 다름
- AWS - Seoul Region - Enterprise일 경우 1크레딧 당 $4.05를 부과

AWS - Seoul로 선택할 때의 가격

Virtual Warehouse

Virtual Warehouse의 성능을 선택할 수 있음
X-Small, Small, Medium, Large, X-Large, 2X-Large, 3X-Large 등으로 선택할 수 있으며, 타입마다 크레딧이 다르게 부과됨
Virtual Warehouse가 실행 중이 아닌 경우엔 크레딧을 사용하지 않으며, 1분 미만으로 사용할 경우엔 1분 요금이 청구되며 1분 이후부턴 초당 과금
만약 Small을 사용한다면 1시간에 2 크레딧을 소모하고, 초당으로 치환하면 1초에 0.0006 크레딧을 사용함

Virtual Warehouse 성능별 부과되는 크레딧(23년 5월 기준)

Virtual Warehouse의 타입에 따라 인스턴스의 성능이 얼마나 되는지 궁금했으나, 공식 문서를 찾아도 나오지 않음
- Snowflake warehouse sizing이란 글을 참고하니 X-Small은 1개의 노드, Small은 2개의 노드, Medium은 4개의 노드를 사용한다고 함
- 각 노드엔 8개의 core/threads
- AWS에서 각 노드는 16GB RAM, 200GB SSD인 c5d.2xlarge EC2를 사용한다고 함
- Medium은 4개의 노드를 사용하고, 32 Cores/threads, 64GB RAM, 800GB

Virtual Warehouse 타입별 성능. 출처 : select.dev

X-Small로 시작하고, 점점 사용 패턴에 따라 성능을 조정해야 할 것으로 보임
- 만약 쿼리가 너무 빨리 실행된다면 리소스를 완전히 활용하지 않을 가능성이 높아서 성능을 낮추는 것도 좋음
Virtual Warehouse를 2개 만들고, 사용자 그룹별로 분리할 수도 있음
- 쿼리를 많이 사용하는 데이터 분석가에겐 더 큰 Virtual Warehouse를 사용하도록 권한을 부여
- 가끔 사용하는 사람에겐 작은 Virtual Warehouse를 제공
Enterprise 에디션 이상을 사용하면 Multi-cluster Warehouse을 사용할 수 있음. Auto-scale 기능을 활성화 할 수 있음. 단, 많이 쓰는 만큼 비용이 더 나감(당연한 이야기)

Snowflake 시작하기

가입하기

Snowflake 홈페이지 우측에 있는 START FOR FREE(무료로 시작하기) 버튼을 클릭
그 후, 개인 정보를 입력한 후 다음으로 이동

Enterprise가 제일 많이 사용하는 옵션인 것 같아 Enterprise로 선택했으며, 클라우드 벤더사와 지역을 설정
그 후, 로그인하고 인증을 하면 Snowsight 화면으로 이동함

Snowsight : 웹 콘솔

Snowsight는 쿼리 작성, 실행, 히스토리 확인, 각종 설정, 데이터 공유 등을 할 수 있는 공간
Web Console이라고 생각하면 됨
과거에 사용되던 Classic Console은 점점 사용하지 않을 예정이라고 함

Snowflake Snowsight Worksheet

User Menu, Navigation Menu, Contents 영역으로 구성됨
- Contents 영역은 Navigation Menu에서 선택하는 것에 따라 화면이 바뀜
User Menu
- Role 변경, User Profile 설정(언어, 사진, 이름, 비밀번호 등)

Navigation
- Worksheet : 작업 공간. SQL, Python Worksheet를 만들 수 있으며 폴더를 만들어 정리할 수도 있음
- Dashboards : 1개 또는 여러 차트를 배치할 수 있는 공간
- Data : 데이터 관련 공간
- Marketplace : 다양한 마켓플레이스가 제공하는 것들이 존재. 데이터, SaaS 등
- Activity : Query History, Copy Histroy, Task History
- Admin : 사용량 확인, Virtual Warehouse 리스트 확인, Resource Monitor, User & Role 설정, 보안, Billing 등
- 데이터를 활용하는 사람이 제일 많이 사용할 부분은 Worksheets, Data
- 데이터 엔지니어, DevOps 엔지니어는 Activity, Admin

Worksheet : 쿼리 실행하는 공간

Worksheet 화면

SQL 쿼리를 실행할 수 있는 공간(DDL, DML)
쿼리나 오퍼레이션의 결과를 확인할 수 있음
Recent, Shared with me, My Worksheets, Folders는 모두 클릭해보면 직관적으로 이해됨. Folder를 생성해서 관리하는 것을 추천
- 저는 Dev 폴더를 생성함
우측의 … 버튼을 클릭하면 Manage Filter를 확인할 수 있음
- 이 부분은 추후에 쿼리에서 사용할 필터를 저장함
Worksheet의 Filter
우측의 + 버튼을 클릭하면 SQL Worksheet, Python Worksheet, Folder를 생성할 수 있음
SQL Worksheet를 클릭하면 다음과 같은 화면이 보이며, 앞으로 데이터 분석할 때 많이 활용할 공간
- 우측에 select col from table whre created = :daterange가 작성된 부분이 쿼리 작성 공간
- 좌측엔 Worksheets가 폴더 구분되어 보임
- 좌측 상단의 Worksheets 왼쪽에 Home 아이콘을 누르면 Snowsight 메인 화면으로 이동함

SQL Worksheets

Databases를 클릭하면 Snowsight 메인에서 Data - Database를 누르면 다음과같이 보임
- 어떤 데이터가 존재하는지 확인할 수 있으며, 저는 CITIBIKE, WEATHER 데이터베이스를 생성해서 존재함
- 데이터베이스 - 스키마 - 테이블이 보이며, 어떤 컬럼을 가지는지도 보임

SQL Worksheets의 Databases 클릭시

Warehouse 선택 : 우측의 ACCOUNTADMIN, COMPUTE_WH를 누르면 각종 설정을 변경할 수 있음. 여러 Role을 보유하거나 Warehouse도 Role마다 다르게 쓴다면 다른 것이 보일 것. 항상 이 부분이 잘 설정되어 있나 확인해야 함

SQL Worksheets의 Role, Warehouse 설정

데이터베이스 선택 : SNOWFLAKE_SAMPLE_DATA를 클릭하면 어떤 Database에서 사용할 것인지 선택할 수 있음. 최초에 데이터베이스 선택을 꼭 해야 함

SQL Worksheets의 Database 설정

2023-05-28 6:09pm 처럼 Worksheet에 마우스를 올린 후 …을 클릭하면 이름 변경, 쿼리 포매팅, 삭제, 단축키 확인 등을 할 수 있음

SQL Worksheets의 Worksheet 설정

SQL 쿼리 실행

다음과 같은 쿼리 실행

SELECT
  O_ORDERDATE as date,
  COUNT(O_ORDERDATE) as orders
FROM
  SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
GROUP BY
  O_ORDERDATE
ORDER BY
  O_ORDERDATE
LIMIT 10;

SQL 쿼리 결과

Chart를 눌러보면 시각화를 할 수 있음

쿼리 결과의 Chart

Python Worksheet

Python Worksheet를 실행하면 Python 스크립트를 실행할 수 있는 공간이 나옴
Snowpark 라이브러리를 사용함
- Snowpark는 Snowflake를 프로그래밍 언어로 사용하기 위한 라이브러리

Python Worksheet 형태

Data : 데이터 Load & 확인

Data 아래에 Databases 탭이 존재함
이 공간에서 데이터를 load 할 수도 있고, 저장된 데이터를 확인할 수도 있음
Data 아래에 있는 Private Sharing에서 데이터를 공유할 수 있음
Snowflake는 Database - Schema - Table 형태로 저장됨
- 여기서 Schema는 보통 RDB에서 말하는 컬럼이 아니기에 헷갈리지 않는 것이 필요
- Database
  - Schema들의 논리적 그룹
- Schema
  - Database Object(Tables, View 등)의 논리적 그룹. 하나의 데이터베이스 아래에 존재함
그 외에 Object는 우선 아래 정도만 있구나 인지하고, 필요할 때 하나씩 학습하는 것을 추천

Snowflake의 여러 Objects. 이미지 출처 : Analytics Today

총평

익숙해지는데 시간이 소요되었지만, 한번 익히니 어떤 느낌인지 깨달음
다른 데이터웨어하우스 대비 쿼리문으로 진행하는 것이 많아 처음에 진입 장벽이 존재할 것(예 : USE Database 등)
Snowflake의 UI가 변경되어 최신 내용에 맞는 글이 거의 없어 글을 작성하게 되었음. 앞으로도 계속 변경될 것 같음
자료가 있는듯 없는듯.. 조금 더 공식 문서가 친절해지면 좋을 것 같음
- GETTING STARTED WITH SNOWFLAKE 문서 추천

핵심 내용 정리

Snowflake는 클라우드 3사의 환경에서 구축할 수 있음
3개의 Layer : Database Storage, Query Processing, Cloud Service
비용 : 크레딧 부과(클라우드 벤더사, Region 마다 금액이 다름)
- Virtual Warehouse : 데이터 Load, 쿼리 연산을 할 때 사용하는 인스턴스
Snowsight : Snowflake의 웹 콘솔
- Worksheet : 작업 공간
- Data : 데이터 Load, 데이터 확인할 수 있는 공간
- 그 외에 다양한 Object 존재

참고 자료

추가로 작성할 글

Snowflake SQL 문법 정리
- 쿼리 퍼포먼스 최적화하기
Snowflake Python에서 사용하기(Snowpark API)
Snowflake로 ELT 데이터 파이프라인 만들기
- Snowflake로 마트 만들기(Task)
Snowflake 비용 모니터링하기
쿼리 작성 가이드

글 작성하는데 걸린 시간 : 4시간 52분

Pandas AI 사용법 - Pandas와 ChatGPT의 결합

Sat, 27 May 2023 00:00:00 +0000

Python으로 데이터 분석을 할 때 빼먹을 수 없는 라이브러리인 Pandas. 아마 많은 분들이 사용하시고, 처음에 많이 학습하고 있을거에요
최근 Pandas-AI라는 라이브러리가 공개되었는데 대화형으로 Pandas를 사용할 수 있는 시대가 되었습니다. 아직 버전은 0.2지만, 추후에 더 많이 발전할 것 같네요
참고 : 이 글은 0.2.2 버전을 기준으로 작성했고, 글을 보시는 시기에 따라 다른 부분이 존재할 수 있습니다

Pandas-AI

Github Repo
Pandas AI는 Generative AI 기능을 Pandas와 결합해 사용할 수 있는 만든 라이브러리

설치

pip3 install pandasai==0.2.2

OpenAI API Key 발급

OpenAI Platform 가입
API Key 접근해서 발급

Create new secret key 클릭

name은 원하는 이름을 지정

이제 나오는 Key를 복사(우측 아이콘 클릭시 복사)
- 이 Key를 계속 사용하니 잘 저장해두기! 어딘가에 노출되면 안되니 Github에 업로드할 때도 주의 필요
만약 RateLimitError: You exceeded your current quota, please check your plan and billing details 오류가 발생하면 Open AI 문서에서 해결 방법을 찾을 수 있음
- Open AI에서 Plan이나 빌링 정보 확인. Billing Overview에 접근해서 설정

카드 등록 후 몇분 후 API를 다시 사용하면 오류가 발생하지 않음

사용법

Jupyter Lab 실행

jupyter lab

라이브러리 Import & 데이터셋 정의

import pandas as pd
import numpy as np
from pandasai import PandasAI
from pandasai.llm.openai import OpenAI

df = pd.DataFrame({
    "country": ["United States", "United Kingdom", "France", "Germany", "Italy", "Spain", "Canada", "Australia", "Japan", "China"],
    "gdp": [21400000, 2940000, 2830000, 3870000, 2160000, 1350000, 1780000, 1320000, 516000, 14000000],
    "happiness_index": [7.3, 7.2, 6.5, 7.0, 6.0, 6.3, 7.3, 7.3, 5.9, 5.0]
})

OpenAI API Key를 사용해 LLM 정의

OPENAI_API_KEY = "여러분들이 생성한 OpenAI API Key"
llm = OpenAI(api_token=OPENAI_API_KEY)

Pandas AI에게 프롬프트 제출

pandas_ai = PandasAI(llm, verbose=True)
pandas_ai.run(df, prompt='Which are the 5 happiest countries?')

verbose=True 인자를 주면 생성한 코드를 볼 수 있음(Jupyter Lab을 실행한 CLI에서 확인했음. 처음엔 Cell의 Output에서 보이다가 몇번 진행하니 나오지 않았음)
- Code generated가 보이고, 그것을 실행하는 것이 보임
결과

그래프 그려달라는 프롬프트 제출

pandas_ai.run(df, prompt='Divide GDP into 3 grades in ascending order, and draw each grade as a bar graph.')

생성된 코드는 다음과 같음

  import pandas as pd
  import matplotlib.pyplot as plt
	
  df = pd.DataFrame({
      'country': ['United States', 'United Kingdom', 'France', 'Germany', 'Italy'],
      'gdp': [21400000, 2940000, 2830000, 3870000, 2160000],
      'happiness_index': [7.3, 7.2, 6.5, 7.0, 6.0]
  })
	
  # Divide GDP into 3 categories
  gdp_categories = pd.qcut(df['gdp'], q=3, labels=['Low', 'Medium', 'High'])
  df['gdp_category'] = gdp_categories
	
  # Plot bar graph for each GDP category
  grouped = df.groupby('gdp_category').mean()
  grouped.plot(kind='bar', y='happiness_index')
  plt.show()

한국어로 Pandas AI 실행

이 부분에서 wow 포인트를 느껴 한국어로도 질문. “GDP를 높은 순으로 3등급으로 나눠주고, 각 등급의 평균 GDP를 Bar 그래프로 그려줘”
```
  pandas_ai.run(df, prompt='GDP를 높은 순으로 3등급으로 나눠주고, 각 등급의 평균 GDP를 Bar 그래프로 그려줘')
```

생성한 코드

  # GDP를 높은 순으로 3등급으로 나누기
  df['gdp_category'] = pd.qcut(df['gdp'], q=3, labels=['Low', 'Medium', 'High'])
	
  # 각 등급의 평균 GDP 구하기
  gdp_mean = df.groupby('gdp_category')['gdp'].mean()
	
  # Bar 그래프로 그리기
  gdp_mean.plot(kind='bar')

직접 코드로 구현한 값과 비교하면 동일

  df.groupby('gdp_category')['gdp'].mean().astype(int)

총평

요즘 HTML 작업을 할 때 ChatGPT와 협업(?)했는데 앞으론 데이터 분석에서도 이렇게 될 것으로 예상
목적을 정의하고 알아서 분석해봐! 가 가능한 시대가 올 것
프롬프트를 잘 작성하면 결과를 잘 내주고, 프롬프트를 구체적으로 작성하지 않으면 오류가 생기는 코드를 만들기도 합니다. 이 부분은 점차 개선될 것
- 속도도 아직 엄청 빠르진 않지만, 코드를 직접 짜는 것보단 수월한 편
Pandas AI Prompt, Pandas Data Analytics Prompt 등도 점점 생길 것 같음
Pandas 교육도 변화가 필요한 시점이 아닐까 싶음

사용한 코드 전체

import pandas as pd
import numpy as np
from pandasai import PandasAI
from pandasai.llm.openai import OpenAI

df = pd.DataFrame({
    "country": ["United States", "United Kingdom", "France", "Germany", "Italy", "Spain", "Canada", "Australia", "Japan", "China"],
    "gdp": [21400000, 2940000, 2830000, 3870000, 2160000, 1350000, 1780000, 1320000, 516000, 14000000],
    "happiness_index": [7.3, 7.2, 6.5, 7.0, 6.0, 6.3, 7.3, 7.3, 5.9, 5.0]
})

OPENAI_API_KEY = "여러분들이 생성한 OpenAI API Key"
llm = OpenAI(api_token=OPENAI_API_KEY)


pandas_ai = PandasAI(llm, verbose=True)
pandas_ai.run(df, prompt='Which are the 5 happiest countries?')

pandas_ai.run(df, prompt='Divide GDP into 3 grades in ascending order, and draw each grade as a bar graph.')

pandas_ai.run(df, prompt='GDP를 높은 순으로 3등급으로 나눠주고, 각 등급의 평균 GDP를 Bar 그래프로 그려줘')

2022년 ~ 23년 1분기 회고. 퇴사 후의 삶

Thu, 06 Apr 2023 00:00:00 +0000

23년 4월 5일 생각이 너무 많은 서른살에게 저자이신 김은주님의 북토크에 다녀왔어요. 이야기를 들으며 “다시 글을 써야겠다”라는 생각이 들어 오랜만에 글을 작성합니다. 다시 꾸준히 글을 작성할 예정이에요!
과거 회고 모음

쏘카에서의 4년

2022년에 제일 임팩트가 있는 이벤트를 생각해보면 역시 다니던 회사의 퇴사(22년 7월)
쏘카에서 보낸 4년을 회고하면 2022년 상반기까지의 내용을 포함할 것이므로 이 부분을 작성

쏘카에서 얻은 경험

2018년 9월에 입사해 2022년 7월까지 퇴사하는 기간 중에 얻은 경험을 정리하면 다음과 같다.

역할 관점 : 팀원, 팀장, 피플 매니저, Engineering Manager
직무 관점 : 데이터 분석가, 데이터 엔지니어, 머신러닝 엔지니어, 데이터 과학자, MLOps PO
영향력 관점 : 개인 - 팀 - 조직 - 전사로 넓히는 영향력
조직의 성장 관점 : 10명도 되지 않던 데이터 조직이 40~50명까지 커가는 과정
신규 비즈니스의 데이터 업무 그리고 법의 이슈로 중단된 비즈니스
기술 블로그 운영

1. 역할 관점 : 팀원, 팀장, 피플 매니저, Engineering Manager

4년 동안 회사에서 필요로 하는 역할을 맡으며 메타몽처럼 일했다
데이터 분석 관점에선 비즈니스 임팩트를 낼 수 있는 일을 주로 했던 것이 기억에 남는다
- 단순히 매출 증대가 아니라, 인사이트 내는 것이 아니라 구체적으로 비즈니스 임팩트를 내기 위한 시도를 했다
- 매출도 증가시키고, 리텐션도 증가시키고, 비용도 줄이는 여러가지 관점의 업무를 진행했다
- 손익, 공헌이익 등 이익 관점으로 생각할 수 있었고 데이터를 기반으로 Action을 할 수 있었기에 좋은 경험이였다. 모빌리티쪽 업무가 데이터 기반 Action을 할 수 있는 것들이 많아 여러가지 업무를 즐겁게 진행했다
- 이 경험을 했기에 여러 데이터를 활용할 때 더 목적을 가지고 일을 할 수 있게 되었고, 이게 너무 당연한 곳에서 일을 했던 것이 좋은 경험이다
- 최적화 경험을 한 것도 매우 좋다. 경영과학 시간에 배운 최적화 지식이 도움이 되었고, 이 때 만든 코드는 아직도 이슈 없이 잘 동작한다고 들었다. 쏘카 예약을 효율적으로 - 수학적 모델링을 활용한 쏘카 예약 테트리스
- 그 외에 기억남는 업무는 공업사 관련 업무. 운전이 익숙하지 않아 차에 대해 덜 아는데, 공업사에 대한 지식을 이렇게 쌓을 수 있다니 신기했다
- 재무적 관점에서 데이터 분석도 많이 진행했다. 주로 정산이 기억에 남는데 정산은 참 어렵다
- 차량의 센서 데이터는 정말 어렵다. 직접 하진 않고 하시는 것을 지켜봤는데 동역학 지식이 필요했고, 회사에 정말 다양한 데이터가 있고 데이터로 할 수 있는 것이 많다고 느꼈다. 차를 모두 다 보유하는 점이 확실히 큰 강점이다
팀장을 하기에 적은 연차 때 팀장을 한 케이스인데, 2018년에 데이터 직무에서 시니어가 시장에 적었기 때문에 연차가 낮아도 팀장을 하게 된 케이스다.
- 이 때 불안하거나 걱정이 있었는가 생각해보면 그냥 무겁게 생각하지 않았다. “팀장”이란 단어가 나를 걱정하게 만들면 내부적으로 학교의 “반장” 느낌으로 생각했다. 단어를 바꿔 생각하니 마음이 한결 편했고, 동아리에서 부장을 했던 경험도 있어서 그냥 사람에 대해 더 생각해야지 다짐했다
- 처음 팀장을 할 때는 두개의 팀 겸직이라(두 팀의 팀장) 솔직히 정신없이 바빴다. 하지만 이런 상황이라 더 팀장에 대해 고민하고, 공부했다. 이왕 할거라면 더 열심히 해보자! 관련 자료를 다 습득하고, 그걸 적용하려고 고민했다
- 이 경험을 정리해 TF에서 팀 빌딩까지 9개월의 기록 : 성장하는 조직을 만드는 여정 발표를 진행하고, 초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들 글을 작성하고 많은 분들에게 공감을 받았다
팀장의 업무 중 사람을 챙기는 역할을 잘 한다는 피드백을 받고, 그 경험을 데이터 그룹의 다른 팀에게도 주면 좋겠다는 의견을 들었다. 그래서 실험적으로 그룹 내의 모든 사람을 신경쓰는 피플 매니저라는 역할을 담당했다
- 이 당시 데이터 그룹이 30명 정도 되었는데, 30명이 되는 인원을 매달 면담하고 조직에서 필요한 것들을 만들기 시작했다. 이 경험이 추후 Engineering Manager로 더 확장되었다
- 이 과정에서도 어려운 일은 있었다. 사람들과 어떻게 대화하고 설득, 협상할 것인가에 대해 고민을 했고 이 부분도 학습했다. 이와 비슷한 사람들에겐 동기면담, 협상, 비폭력대화 등을 공부해보길 권하고 있다
- 이 때 경험한 내용을 원티드에서 “성장하고 안정적인 조직을 만드는 쏘카 데이터 그룹의 정원사 이야기 (feat. 조직 문화 지킴이)”라는 제목으로 발표했다. 원티드에서 무료로 볼 수 있다
Engineering Manager 경험
- 회사에선 EM이라고 불리진 않았지만, 결국 EM의 역할과 동일하다
- EM을 하면서 자주 “우리 조직에 속한 사람들이 즐겁게 일하며, 자신의 욕구를 충족하며 지내고 있을까?”라는 질문을 던지고, 이 질문에 대해 Yes가 나오는 것들을 진행했다
- 조직도 상엔 Director로 취급되어 Director/C레벨 회의에 참여하며 비즈니스 의사 결정과 더 상위 레벨의 시야를 경험할 수 있었다. 이젠 경영진 관점에서 어느 시점에 어떤 이야기를 할 지에 대해 그림을 그려볼 수 있다
- 조직이 커가면서 새로운 팀장이 필요했고, 과거의 나처럼 초보 팀장분들의 고민을 듣고 어떻게 해야 더 잘 나아갈 수 있을지를 자주 이야기했다
- 신규 인원의 온보딩 프로세스, 업무 프로세스, 채용 공고 등 팀을 넘어서서 정리해야 하는 일 중 진행되지 않은 일들은 대부분 담당했다
- 이 때 “할까? 말까?에 대해 고민한다면 그냥 하자”라는 원칙을 만들고 지켰다

2. 직무 관점 : 데이터 분석가, 데이터 엔지니어, 머신러닝 엔지니어, 데이터 과학자, MLOps PO

요즘 내게 “성윤님은 데이터 과학자에요? 데이터 엔지니어에요”라고 물어보면 그냥 “데이터 제너럴리스트인 것 같네요”라고 말하고 있다. 아니면 데이터 메타몽일까? 시기에 따라 필요한 일을 했다
스타트업에서 작은 규모의 팀에서 커가는 과정을 모두 경험해서 이런 일이 가능했을 것 같다. 만약 팀 규모가 비슷했거나 매우 컸다면 역할이 고정되어서 한 분야를 깊게 했을 것 같다
이렇게 여러 관점을 경험하니 다양한 관점으로 생각할 수 있게 되었다. DA 관점에선 DE도 생각하고, MLOps를 만들 때는 DS / DE 관점을 둘 다 고려할 수 있다.
- 다르게 표현하면 조직의 규모에 따라 필요한 역할이 무엇인지 정의하고, 그 시기에 어떤 생각을 주로 하는지에 대해 그림을 그려볼 수 있다
입사 초기엔 데이터 엔지니어링을 했고, 타다의 업무를 할 때는 DA, DS, DE 모두 신경을 쓰며 일했다. 다시 쏘카의 업무를 할 때는 조직에서 필요한데 아직 정의되지 않은 일이나 애드혹을 주로 했다(애드혹은 제가 다 할테니 팀원분들은 더 중요한 일에 집중하세요!라고 외치며 몸빵). 쏘카의 PM분들과 주기적으로 대화해서 PM분들의 데이터 리터러시를 늘리는 일도 했었다
회사에서 점점 AI, ML 모델이 많아지면서 MLOps 플랫폼을 만드는 것도 계획했고 이 부분을 점진적으로 하기 위해 어떤 것부터 해야할지 정의했다
- MLOps 분야가 워낙 다양해서 무엇부터 해야할지 정의하는 과정이 어려울 수 있는데, 현재 조직이 가지고 있는 모델과 요구 조건을 분석하며 하나씩 하도록 했다
- MLOps 플랫폼을 구축할 때, AI 모델러와 개발자를 같이 조합해서 서로를 이해할 수 있도록 했다. 개발자 관점에서 MLOps 플랫폼을 생각하면 누락되는 것이 있기에 아예 팀에 두 역량을 가지는 사람을 섞어 배치했다
직무 관점에서 이야기하고 싶은 내용은 많은 사람들이 “제너럴리스트와 스페셜리스트”에 대해 생각한다. 사실 나도 이런 고민을 했기에 이런 고민이 이해가 된다. 다만 요즘엔 “제너럴이냐 스페셜이냐 이분법적으로 생각하지 않고, 지금 할 수 있는 일부터 시작해서 경험하지 않는 영역도 넓히는 것이 결국 좋지 않을까?”라는 생각을 하고 있다. 현재 제너럴 같이 일하고 있으면 그걸 잘하려고 하다가 스페셜 같이 일하고, 스페셜 같이 일하면 근처에 연결된 일들을 익혀 제너럴 같이 되고! 그러면 제너럴 스페셜리스트나 스페셜 제너럴리스트가 될텐데 결국 우리가 생각하는 일 잘하는 사람들이 이런 사람들이 아닌가 싶다
- 결국 제너럴이냐 스페셜이냐 중요한 것이 아니고, 내가 어떤 모습이 되고 싶은지 욕구를 고민하고 그 욕구를 향해 계속 이동하는게 중요하다고 생각한다
- 제너럴만 할 경우의 아쉬운 점, 스페셜만 할 경우 아쉬운 점 모두 다 존재한다. 사실 이것만 해당되는게 아니라 우리의 인생도 항상 아쉬운 것이 있다는 점을 고려하면, 항상 아쉬움을 느끼는게 당연하다고 생각한다(=문제가 아니고 당연한 현상이다)
- 그렇기 때문에 과거 경험에 대해 아쉬움을 느끼는 것보단 미래에 대해 집중해서 앞으로 무엇을 해볼까를 더 생각하는게 좋지 않을까 싶다
그리고 제너럴하게 여러가지를 경험하면, 그게 또 스페셜이 된다. 결국 얼마나 많은 것을 습득하고 넓게 고민할 수 있는지가 중요한게 아닐까 싶고, 그래서 하고 싶은 일을 하고 있는지에 대해 생각해본다
- 몇년 전에는 MLOps Engineer는 없었다. 이런 일을 하는 사람들이 DevOps, DE 등 다양하게 불리다가 최근에 직무로 생기게 된 것이다. 요즘 프롬프트 엔지니어라는 직무도 나오는데 과거엔 없었다. 결국 기술의 발전과 시기에 따라 새로운 직무가 생기곤 하는데 그 전에도 그런 일을 할 수도 있는 것이다
- 이런 관점에 대해 타인을 의식하는 순간 어려워지는 것 같아 내 내면에 대해 귀 기울이고 있다

3. 영향력 관점 : 개인 - 팀 - 조직 - 전사로 넓히는 영향력

1번에 작성한 역할이 바뀌면서 점점 영향력이 넓어졌다
“개인” 성장에 대해 고민하다가, 팀장을 하면서 “팀의 성장”에 대해 고민하고, 피플 매니저를 하면서 “팀을 넘어선 조직의 성장”에 대해 고민했다
그러다가 결국 협업하는 조직에게도 영향력을 미치고, 같이 성장해야 우리 조직에게도 또 다시 좋은 일이 생긴다. 즉, 우리 조직 안에서만 노력하는 것이 아닌 바깥에서도 노력해서 결국 우리 조직도 좋아지게 만드는 것도 가능하다. 즉 우리 조직과 관련된 조직에게도 영향을 미치게 되었다.
쏘카에서 데이터 관련 가이드나 교육 자료의 대부분을 만들었다. PPT만 해도 1500쪽은 넘을 것 같다. 그러다보니 사업, 운영 조직에 계신 분들도 입사하고 내 자료를 통해 SQL이나 데이터를 학습했다. 종종 이런 학습을 하다 어려운 부분이 있다면 해소드리고 사업, 운영 조직에서 데이터를 보는 분들과도 코칭을 진행했다
이런 과정을 경험하며 내가 “영향력”을 생각하는 사람이구나를 깨달았다. 점점 더 많은 사람들에게 영향력을 미치고 싶고, 나의 영향력이 미친 사람들이 더 잘 성장하고 나아가는 것에 큰 보람을 느꼈다
- 이런 시기를 거치면서 내가 중요하게 생각하는 의사 결정 기준이 영향력이 되었다는 것을 알게 되었다

4. 조직의 성장 관점 : 10명도 되지 않던 데이터 조직이 40~50명까지 커가는 과정

위에서 언급한 것처럼 10명도 되지 않던 데이터 조직이 퇴사할 시점엔 40~50명이 되었다. 4년간 팀 규모가 4배 성장했고, 그룹이 본부가 되며 하는 일도 더 확장되었다
쏘카 전에 다녔던 회사는 1-2인의 데이터팀이였기에 이제 1인 데이터팀부터 40~50명의 데이터 조직에서 어떤 일이 일어나고 어떻게 문제를 해결해야 할지에 대한 경험이 생겼다
개발 조직에선 애자일 방법론이 사용되면서 효율적으로 일하기에 대해 논의가 많이 이루어지고 있다. 데이터 조직도 이 방법론을 활용할 수 있으나, 업무 프로세스가 조금 다르기에 커스텀하게 적용하는 것이 필요하다
- 예를 들어 목적 조직에 DA가 속하는게 좋은가? 기능 조직처럼 DA가 모여있고 필요할 때 프로젝트를 하는게 좋은가? 목적 조직과 기능 조직에 동시에 속하는게 좋은가?
- 이에 대한 명확한 답은 없고, 조직이나 구성원 상황에 따라 다르다. 현재 조직의 상황을 파악해 문제를 해결하는 방법을 찾는 것이 핵심이다
조직도 세포처럼, 사람처럼 점점 학습하고 성장한다. 그 시기에 필요한 내용을 적절히 생각하고, 제시하는 것이 필요하다
- 실리콘밸리에 있는 더 큰 데이터 조직에 있는 분들과 커피챗을 하며 더 큰 조직에서 겪는 문제도 간접적으로 경험하며, 지금 조직에서 무엇을 해볼지에 대한 생각했다
조직이 커가는 과정에선 “프로세스”에 집중했다. 조직이 커가면서 프로세스를 만들어야 불필요한 에너지가 낭비되지 않고, 에너지를 더욱 좋게 사용할 수 있다
- 또한 코칭을 어떻게 더 잘할 수 있을까에 대해 생각하며 여러 코칭에 대해 학습했다
데이터 조직의 성장 과정과 어떤 직무가 필요한지, 어떤 일이 발생하는지에 대한 내용은 추후 컨텐츠로 만들 예정이다

5. 신규 비즈니스의 데이터 업무 그리고 법의 이슈로 중단된 비즈니스

타다 베이직이 런칭되는 시점부터 서비스가 종료될 때까지 타다에서 필요한 데이터 업무를 진행했다
- “타다: 대한민국 스타트업의 초상” 다큐멘터리에 직접적으로 나오진 않지만, 뒷통수 정도는 나오고 그 당시 같이 일했던 사람들이라 다큐멘터리를 보며 여러 감정이 들었다
- 서비스가 빠르게 성장하는 과정에서 얻는 보람, 법의 이슈로 서비스가 중단되며 겪는 기분, 이런 상황을 개선하기 위한 조직의 노력을 경험했다
성장하는 서비스에서 일을 하는 경험은 모든 사람에게 한번은 꼭 해보길 권하곤 한다. 그 시기에 일을 많이 하더라도, 큰 보람이 있고 그 사이에 많은 성장이 있었을 것이다
요즘 도로에 타다 넥스트가 보이면 생각에 잠긴다. VCNC분들이 더 좋은 제품을 만들길!

6. 기술 블로그 운영

내부적으로 좋은 문화를 만들고, 이런 내용을 외부에도 공유해야 한다. 너무 부풀리는 것이 아닌 어떤 문제를 겪었고, 어떤 방식으로 해결했는지를 주로 작성하면 된다.
개인 기술 블로그와 회사 기술 블로그는 비슷하지만 다르게 운영되어야 한다. 회사의 이름을 걸기 때문에 톤을 더 정제할 필요가 있고, 직접 글을 쓰는게 아니고 다른 사람들이 글을 쓰도록 해야해서 또 다른 어려움이 존재한다.
- 이런 경험을 하나씩 하며 기술 블로그 운영 프로세스를 만들었다. 하지만 인터넷에서 회사 기술 블로그 운영기에 대한 내용은 거의 없기에 아쉬웠다. 그래서 퇴사하고 7개월이 지났지만, 회사와 이야기해서 쏘카에서 기술 블로그를 운영하는 방법 글을 작성했다.
좋은 기술 활용 케이스, 회사에서 풀고있는 문제를 많은 회사들이 공유하면 좋겠다. 그러면 채용을 할 때도 큰 도움이 된다

쏘카에서 생긴 원칙

나만의 삶의 원칙을 하나씩 만들고 있다. 어떤 경험이든 이렇게 원칙으로 만들면 나중에도 활용할 수 있어 나만의 원칙 리스트를 계속 만들고 있다
1) 실행력이 중요하다
- 누구나 생각할 수 있고, 누구나 말할 수 있다. 하지만 결국 실행을 하느냐가 큰 차이를 만든다
- 항상 실행까지 염두해두고, Action Item에 대해 생각하는 습관을 만들면 거시적으로 생각할 수 있다
2) Comfort 존(컴포트 존)은 내가 만든다. 나오는 것도 내가 할 수 있다
- 회사에서 새로운 도전을 하지 못하거나, 하던 일이 익숙해져서 동기부여가 떨어지는 경우가 생길 수 있다
- 이 경우 편한 상황에 익숙해져서 추가적인 새로운 도전을 하지 않는 경우가 있다. 이런 경우엔 내가 컴포트 존에 안주하는 경우다. 만약 이런 상황이라면 주어진 환경을 의도적으로 바꾸면 좋은데, 프로젝트 변경, 팀 변경, 직무 변경 등이 있다. 상급자와 이야기해서 조금 더 도전적인 일을 해보면 좋다
- 무조건 퇴사가 답은 아니다. 요즘 같이 채용 시장이 어려운 상황엔 퇴사를 신중히 하는게 필요하다. 먼저 속한 환경을 컴포트가 아니도록 바꾸고, 노력을 하면서 계속 컴포트 존과 비 컴포트 존을 왔다갔다 하면 된다(가끔은 컴포트 존에 가는 것도 괜찮다고 생각한다. 다만 오래 되지만 않으면 된다고 생각)
3) 할까? 말까?에 대해 고민한다면 그냥 하자
- 할까? 말까? 라는 생각이 든다면 이왕이면 해보는 것으로 생각한다. 실행력 관점에서도 중요하고, 이걸 해야할까?라는 생각을 처음 한 사람이 하는 것이 좋은 경우를 봤다
- 말한 사람이 해야지와 비슷한 맥락이다
- 다만 실행한다면 진짜 잘 되도록 노력하는 것도 필요하다. 일단 쉽고 가볍게 시작하고, 그걸 잘 되게 하는 것도 내가 해야하는 일이다
4) 커뮤니케이션을 할 때는 맥락(Context)이 중요하고, 하지 않는 것보단 오버 커뮤니케이션이 좋다
- 맥락 정보를 제공하지 않으면 현상을 잘 이해하기 어렵다. 일상이나 커뮤니케이션에서 이런 경우가 많은데, 항상 맥락을 제공하면 좋다. 마치 ChatGPT에서 맥락 정보를 제공하는 것도 비슷한 맥락이 아닐까 싶다
- 업무에서 MECE하게 생각하려고 노력하지만, MECE는 쉽지 않다. MECE가 어려우면 중복을 넣어도 괜찮다. 내용이 없는 것보다 차라리 중복이 좋다. 커뮤니케이션도 차라리 중복이 있더라도 오버커뮤니케이션을 하면 된다
- 주어진 시간에 어떻게 회의할까에 대한 것도 중요한데, 회의 시작할 때 항상 목적을 상기하면서 해야 한다. 회의하는 것도 어느덧 패턴이 생겼다

퇴사하게 된 과정

쏘카의 4년(22년 상반기까지)은 이정도로 정리하고, 퇴사를 하게 된 과정을 간단히 정리한다
회사에 불만족은 없었다. 회사에서도 역량을 인정 받고, 좋은 동료들과 같이 있었고 여전히 데이터 직무로 좋은 회사라고 생각한다
다만 갑자기 교육에 대한 소명 의식이 생겼다
- 교육 시장을 보면 기술적인 강의가 매우 많다. 대부분 파이썬, SQL 등 기술적인 내용에 집중한다. 이런 내용도 분명히 필요하고, 기술적인 부분은 시간을 쓰는만큼 (초반엔) 선형적으로 역량이 빠르게 증가한다
- 다만 회사에서 일을 할 때 자주 겪는 문제는 기술적인 것이 아닌 경우도 존재한다. 예를 들어 “인사이트 내주세요”라는 말을 들었을 때 나는 어떤 방식으로 업무를 진행해야 할까?, 사람과의 커뮤니케이션 등이 있다.
- 나와 비슷한 상황을 겪는 분들이 덜 고생하며 일을 할 수 있도록 도와주고 싶었다
- 기술적인 강의를 경험 기반에서 문제 정의부터 해결, 다양한 전략 등을 포함해서 할 수 있지 않을까 싶었다. 단순히 툴 사용 강의보단 흐름을 전달하고 싶다
- 조금 도전적이지만 이런 방식으로 강의를 기획하고 있다
또한 시리즈 A 규모 정도되는 회사에서 데이터를 보고 싶은데, 어떻게 해야할지 모르겠다는 의견도 많이 들었다. 이런 분들이 겪는 시행 착오를 나는 이미 과거에 경험했는데, 중요한 것에 집중하고 나머지는 빠르게 해결하면 좋겠다는 생각이 들었다
결국 교육을 통해 사람들이 일을 더 잘하는 사람이 되도록 도와주고 싶단 생각을 했고, 회사를 넘어서 영향력을 발휘하고 싶었다
꼭 지금이어야 하냐?라는 질문을 받기도 했고 코로나로 인해 레이오프가 점점 생길 것이란 이야기를 듣기도 했다. 레이오프가 생기면 결국 교육에 투자를 잘 안한다는 이야기도 들었다
- 이 때 하나의 질문을 던지고 결정했다 : 내가 죽을 때 이 일을 안하면 후회할까?
- 대답은 Yes였고, 이 시기보다 늦어지면 의미가 없어질 것이라 생각해 퇴사를 결정했다
교육을 하면 현업에서 멀어지는데, 그럼 과거의 이야기를 전달하는게 아니냐?라는 질문도 받았다
- 이걸 보완하기 위해 교육을 만들지만 여태까지 집중하지 못했던 영역에 대해 집중해야겠단 생각을 했다. 여러 업무를 했지만 DE 업무를 제일 선호하므로 이 부분에서 내가 덜 학습한 내용을 하나씩 학습하기 위한 계획을 퇴사 전에 세워두었다

퇴사 후

퇴사 후에 바로 교육을 준비했고, 스타트업 데이터팀 한곳을 코칭했다
- 퇴사 후에 무엇을 했냐?라고 하면 진짜 데이터 교육 만들기와 데이터팀 코칭 외에는 거의 진행한 것이 없다. 그래도 기억나는 몇가지를 작성해본다

AC2

김창준님, 변신철님이 진행하시는 AC2에 참여해서 애자일 코치를 키우는 코칭 과정을 경험했다
- 과거 팀장, Engineering Manager를 경험하며 배운 내용들을 더 명시적으로 정리할 수 있었고 내가 모르는 부분도 있어 소스를 얻고 내가 활용할 수 있도록 적용했다
- 이 시기에 습관 형성에 대한 논문, 빅파이브, Job Crafting 등에 대해 학습했고, 사람을 어떻게 “변화”하도록 도울 수 있을까에 대해 깨달음이 생겼다. 코칭을 어떻게 할 것인가에 대해서도 이 때 원칙이 하나씩 생겼다
자신의 변화, 조직의 변화에 대해 고민이 있다면 꼭 수강해보길 권하는 교육이다. 세상을 바라보는 안목을 바꿀 수 있다
참고로 김창준님은 내 인생 책 중 하나인 함께 자라기의 저자시다

포르투 워케이션

한국에서 미팅 요청이 점점 생겨 집중할 시간이 필요하다 생각해 포르투에 1달간 워케이션을 갔다
포르투라는 도시는 여유가 있어서 거기가서 열심히 집중해야지!라고 생각하고 갔는데, 결과적으로 포르투에서 강의를 다 만들진 못했다
- 포르투에서 일하다 중간에 회고를 통해 “여기서 어차피 다 완성은 무리니, 다른 컨셉으로 바꾸자”라는 생각을 했다. 그래도 이 때 밑그림을 다 그려놔서 이후에 수월하게 작업했다.
이 때의 경험도 Awesome Workaction - 데이터 사이언티스트의 워케이션 기록에 기록해두었다
포르투에서 잘 쉬고 왔기에 이후에 어떤 일을 해도 열심히 할 수 있게 되었다
아, 그리고 FC 포르투와 아틀레티코 마드리드 챔스 예선 경기를 직관했다. 포르투갈 사람들이 얼마나 축구를 좋아하는지 알 수 있었고, 선수들은 오늘 하루 5만명에게 영향을 미치겠구나를 생각하며 나는 얼마나 영향을 미칠 수 있을까에 대해 생각했다

PM을 위한 데이터 리터러시

PM을 위한 데이터 리터러시 강의 링크
데이터 교육 중 무엇을 만들까 생각하다가 PM을 위한 교육을 만들었다. 요즘 PM/PO분들이 데이터 역량을 많이 요구받는데, 이분들에게 통계학이나 파이썬 역량을 요구하는 것은 아니다. 그런데 시중엔 통계학, 파이썬 내용이 많으니 이런 부분을 학습하고 업무에 적용이 어려운 현상을 발견했다
PM분들이 데이터를 스스로 잘 파악하면 데이터 조직과 협업도 원활하게 진행되기에 PM분들이 더욱 데이터를 잘 활용할 수 있도록 도와야겠단 생각을 했다
강의를 만들 때도 “강의를 들은 분들이 직접 활용할 수 있도록 강의를 구성하기” 를 생각하며 강의를 만들었다
- 피그마로 가상의 앱을 만들고, 그 상황에서 팀장님이 “결제 전환율을 올려주세요!”라는 미션을 받을 때 어떻게 일을 해나갈지에 대해 다루었다
- 그 과정에서 필요한 내용을 전달했고, 경험적인 내용과 Process를 많이 공유했다. 사람들이 어떤 흐름으로 일하면 좋을지 베이스라인으로 삼을 수 있도록 했다
- 또한 카일스토리라고 하는 것도 추가했는데, Case Study 같이 데이터를 보면서 생길 수 있는 일을 많이 제시했다. 예를 들면 답정너 실험, 분석 레포트를 보고 이모지만 달리는 상황 등 => 이런 부분이 존재해 공감을 얻고 강의를 꾸준히 들을 수 있게 될 것이라 생각했다
- 그 외에도 웹페이지에 복습할 수 있는 환경도 준비했다. Data for PM - PM을 위한 데이터 분석, 데이터 리터러시(프로덕트 데이터 분석)
강의를 런칭한지 이제 45일이 되었고, 380명이 수강하고 있다. 수강하신 분들이 실제로 액션할 때 어려움이 있을 것 같아 70% 수강하신 분들에게 무료 코칭을 해드리고 있다. 코칭을 하며 사람들이 강의에 대한 후기를 알려주시는데, 긍정적인 변화에 도움을 줬다는 이야기를 들어 뿌듯하다
이제 다음 교육을 준비하고 있다. 다만 강의를 혼자 준비하니 시간이 꽤 걸린다. 이런 시간을 줄이기 위한 여러 전략을 고민하고 있다.
- 추후에 강의 만들기에 대한 내용도 별도의 글을 써야겠다

요즘

요즘엔 강의 런칭 후, 책 집필을 했다. 혼자 저자인 책은 아니고 공저자가 있는 책이다. 아마 6월 쯔음엔 나올 것 같다
부스트캠프 AI Tech에서 강의 진행은 계속 하고 있다. 수강하는 분들에게 좋은 영향을 주기 위해 러닝마스터 세션도 어떻게 더 개선할까 고민하고 있다. 댓글이나 후기를 남겨주시는 것을 보면 내게도 큰 동기부여가 된다
데이터팀 코칭 : 스타트업 몇곳에서 데이터팀 코칭을 진행하고 있다. 데이터팀이 더 빠르게 성장하고 데이터 기반으로 의사결정할 수 있는 방법을 같이 찾고, 실행 과정까지 조언을 하고 있다
C레벨 코칭 : 데이터팀이 아닌 C레벨 몇분을 코칭하고 있다. C레벨 또한 고민이 있는데, 이런 고민을 내가 가진 지식으로 도와줄 수 있다면 좋겠다고 생각했다. 이런 맥락 하에 C레벨 코칭을 진행하고 있다
- 빌 캠벨, 실리콘밸리의 위대한 코치 책을 접하고 내가 가려고 하는 길을 이미 가신 분이 있구나 생각했고, 이와 같은 길을 나도 가고 있다
시드니 여행을 했다. 여유로움 속에서 어떤 일을 해야할지에 대해 생각할 수 있었고, 한국이 아닌 해외에서 일하고 싶은 생각도 조금씩 생겼다(이건 막연한 희망). 시드니에 다녀와서 다시 달릴 수 있는 여유를 만들어주었다.
운영하고 있는 글쓰는 개발자 모임 글또에서 여러 활동을 준비하고 있다. 사람들이 서로 교류할 수 있도록 하는 것과 글쓰기 강의를 준비하고 있다
- 340명의 개발자가 활동하는데, 글쓰기를 더 잘하고 싶은 욕구를 가진 분들이 많다. 예전엔 습관 형성을 하고 꾸준히 쓰다보면 좋아진다고 이야기했는데, 나의 경험을 공유해 간접적으로 도움을 줘도 좋겠다고 생각해서 교육을 만들고 있다
- 추후에 유튜브에 다 공개할 예정이다. 기술 블로그 글쓰기에 대한 내용은 널리 퍼져서 많은 분들이 글을 쓰면 좋겠다
부트캠프가 아니라 대학교에서도 강의하고 싶단 생각이 든다. 대학생에게 좋은 영향력을 주려면 어떻게 해야할까를 고민하고 있다. 다만 교수를 하려면 석사 학위가 대부분 필요해서 이 부분은 장벽이라 다른 방법을 찾아봐야 할 것 같다
그리고 맥북 M2 Pro를 구매했다. 그전에 Intel Mac을 사용했는데, 배터리가 너무 빨리 소모되고 영상 편집할 때도 버벅였다. 5년 정도 사용하던 맥북을 바꾸니 훨씬 쾌적해졌다
요새 요리를 시작하고 있다. 요리가 개발이랑 비슷한 느낌이라(?) 재미있다. 아키텍쳐 설계하고 실행하는 느낌이라 조금씩 하고 있다
삶이 평온하고 안정적이다. 조급하지 않고, 일단 하면 된다. 하다가 잘 안되면 그냥 방향을 바꾸면 그만이다. 어차피 인생은 잘 안된다. 일단 가다보면 계속 방향을 잡고 나아갈 수 있다

23년은 어떻게 살 것인가?

23년엔 “컨텐츠 크리에이터”의 삶을 살기로 결정했다
- 교육이나 컨텐츠 만드는 것에 집중하고, 부족했던 공부를 할 예정이다
인스타그램, 유튜브, 글을 모두 만들어서 컨텐츠를 계속 만들 예정이다. 기술 블로그에 글을 거의 올리지 않았는데, 다시 올려야겠다
그리고 24년엔 또 다른 목표가 생겨서 다른 길로 갈 수도 있다. 어떻게 될지는 사실 잘 모른다. 12월 쯔음에 고민하고 그 방향으로 가지 않을까 싶다
일단 해보고, 안되면 방향을 바꾸면 된다. 조급하게 생각하지 말자

2023년 2~4분기 Action Item

컨텐츠 업로드하는 습관 만들기
- 습관 형성 구축
- 얼마나 이걸 매주 지키는지를 확인해 지표로 설정
- 글 / 카드 뉴스 / 영상 3가지 트랙을 모두 시작하고 나만의 프로세스 만들기
스타트업 데이터팀 코칭
- 현재 하고 있는 곳 외에 1곳 정도 더 받을 수 있는데, 고민 중이다
- 내가 확실한 가치를 줄 수 있는 곳에 코칭을 하고 싶다
- 혹시 데이터 조직의 코칭이 필요하시면 메일로 보내주시면 됩니다
- 코칭을 하기 전에 내가 만든 강의를 보는 것도 좋은 방법이라 생각한다
강의 3개 만들기
- 2개 더 만들면 된다. 사실 더 만들고 싶긴하다(생각한 주제는 많다)
개발 역량 쌓기
- 개발, 데이터 엔지니어링을 더 진행 예정
- 어떻게 해야 효율적으로 할 수 있을까에 초점을 맞추고, 파이프라인을 아예 템플릿화하는 것까지 실행할 예정
- 여전히 공부해야 하는 내용이 너무 많고, 꾸준히 학습해야 한다
월에 독서 5권 이상
- 시간적인 여유가 있을 때 책을 많이 읽자
- 책 구매보단 도서관에 가서 책 읽는 습관을 만들 예정
삶의 원칙 채우기
- 살면서 나만의 원칙을 하나씩 만들고 있다. 올해도 원칙을 새로 세우거나 기존의 원칙을 업데이트하자

여러분들에게 하고 싶은 질문

이 글을 보는 분들도 생각해보면 좋은 질문을 던져봅니다. 이 질문에 대한 생각을 하시고, 지인들과 이야기를 나누어도 좋을 것 같아요 :)
23년은 여러분들에게 어떤 해이길 바라나요?
여러분들은 꼭 해내고 싶은 일이 있으신가요?
이걸 위해 어떤 것을 해야할까요?
그걸 꾸준히 하려면 어떤 준비를 하면 좋을까요?
여러분의 삶의 원칙이 있으신가요?

글 작성하는데 걸린 시간 : 2시간 53분

부스트캠프 AI Tech Product Serving, 러닝 마스터 강의 후기

Fri, 17 Jun 2022 00:00:00 +0000

부스트캠프 AI Tech 1~3기에서 강의했던 내용을 회고한 글입니다
강사 입장에서 교육을 교육 과정을 설계했는지, 무엇을 느꼈는지를 다루는 글입니다

부스트캠프 AI Tech

부스트캠프 AI Tech는 네이버 커넥트재단과 업스테이지가 함께 만드는 교육 과정입니다
글을 작성하는 22년 6월 기준 3기까지 진행되었으며, 3기는 막 끝났고 이제 4기를 준비하고 있습니다
저는 부스트캠프 AI Tech 1~3기에 모두 참여했습니다. 어떤 방식으로 참여했는지 말씀드리면
- 1기 : 현업자 커리어 특강 1시간 30분 발표
- 2기 : Product Serving 약 20시간 강의
- 3기 : Product Serving 약 20시간 강의 + 러닝 마스터 역할

참여했던 부분을 하나씩 이야기해보겠습니다

1기 : 현업자 커리어 특강

현업자 커리어 특강은 1회성 특강으로 부스트캠퍼 분들에게 제가 커리어를 어떻게 발전시켜왔는지, 그 과정에서 어떤 것을 느꼈는지를 주로 다루었습니다
불합격, 실패를 바라보는 관점과 데이터, AI 직군은 무엇이 있는지 이 시기에 무엇을 생각해보면 좋을지 등을 공유했습니다
1회성 특강이라 한번 진행했으나, 리액션을 잘 해주셔서 뿌듯했던 기억이 남은 특강이였습니다

2기 : Product Serving

특강을 진행하고 몇 달 후, MLOps 중 Serving 강의를 할 수 있는지에 대한 문의를 받았습니다. 회사 업무도 꽤 있던 상황이라 바로 답변을 드리진 못했고, 미팅을 진행했습니다
- 1기 교육 과정을 들어보니 강의의 퀄리티가 좋다고 느꼈으며, 강의를 제안한 Product Serving은 제가 익숙한 부분이라 많은 고민 끝에 진행하기로 했습니다(고민 과정에서 김성훈 대표님에게 제 고민을 이야기했고, 그 부분에 대해 흔쾌히 이야기해주셨습니다)
강의 설계를 위해 들은 부분은 “Product Serving”, “약 20시간”이 핵심이였습니다. 강의를 설계하는 권한도 제게 주어졌기에 여러가지 관점으로 강의를 설계했습니다
- 이 강의 설계하기 1달 전 쯤, 김창준님의 Really Effective Teacher 과정을 수강하며 교육을 어떻게 설계할 것인가, 어떤 방식으로 교육을 평가할 것인가를 학습했습니다. 교육하는 것이 제게 즐겁다는 것을 알기에, 과정에서 배운 것을 부스트캠프 AI Tech에 최대한 적용하려고 했습니다.

강의 설계를 하며 다음과 같은 내용을 작성했습니다. 생각 중 제일 핵심적인 부분은 다음과 같습니다.

“수강생분들이 강의를 듣고 어떤 모습이길 바라는가?”라는 질문을 하고 이 질문 기반으로 강의를 설계했습니다. 제일 중요한 부분은 “수강생이 어떤 식으로 변화하도록 강의하고 싶은가?”라고 생각했습니다
AI 엔지니어로 시작하기 위해선, 꽤 많은 지식이 필요합니다. 이 많은 지식을 모두 잘하는 사람을 찾기 어렵고, 신입 중에 이런 역량이 모두 있는 사람은 거의 찾기 어렵습니다
- 그래도 기초 역량을 갖추는 것은 가능하다고 생각해, AI 엔지니어의 기초 역량이라 생각하는 부분을 최대한 담았습니다
단순히 기술만 알려주는 강의는 이미 많이 존재합니다. 현업에서 일하면서 느낀 점은 “문제 정의를 잘 하는 것이 매우 중요한데, 교육에서 문제 정의에서 다루지 않기 때문에 기술에 매몰되는 경우가 많다”입니다
- 문제 정의에 대해 강의하는 것이 추상적인 부분이라 어렵지만, 이 부분을 꼭 추가해서 스스로 문제를 정의할 수 있는 습관을 가지도록 하고 싶었습니다
프로토타입부터 점점 완성화된 제품을 만드는 점진적인 과정을 경험하도록 해주고 싶었습니다
- 회사에선 처음부터 제품을 만들자!라는 것보단 프로토타입부터 만들어서 이 프로젝트가 어느정도 잘 진행될지 고민하고, 더 리소스를 투입할지 고민하는 경우가 존재합니다
- 이는 리소스가 한정되었고, 전통적인 소프트웨어 엔지니어링과 다르게 개발을 하는 것이 바로 성공을 보장할 수 없기에 점진적으로 개발하는 과정을 경험하게 하고 싶었습니다
1기분들이 어떤 프로젝트를 했는지 들어보니, AI 엔지니어 과정인데 최종 프로젝트에서 웹을 구축하기 위해 프론트를 따로 공부하는 모습을 보였습니다
- 물론 프론트를 하면 더욱 좋지만, 제한된 시간에서 효율적으로 개발하기 위해 AI 엔지니어(혹은 데이터 분석가, 사이언티스트, 데이터 엔지니어 등)가 프론트엔드를 꼭 해야할까라는 생각이 들었습니다
- 2021년부터 회사에서 Streamlit을 사용해 프로토타입을 개발했는데, 완벽한 프론트엔드가 아니여도 대략적인 프론트엔드를 구현할 수 있다는 것을 경험했습니다
- 따라서 프로토타입을 만들도록 Streamlit을 가르치기로 결심했고, 프론트엔드를 꼭 하진 않아도 될 수도 있다는 점을 공유하고 싶었습니다
여기서 또 고민했던 부분은 Streamlit은 스크립트로 개발하는데, 아마 많은 분들이 데이터 분석, 머신러닝, 딥러닝을 학습할 때는 Jupyter Notebook으로 학습할 것이라 생각했습니다
- Jupyter Notebook에서 프로토타입을 만들 수 있는 Voila를 사용해 간단하게 프로토타입을 구현할 수 있도록 먼저 가르친 후, Streamlit을 가르치기로 했습니다(프로젝트 진행 과정에서 Notebook => Python Script가 더 적절해 보였습니다)
비즈니스도 잘 아는 사람이 될 수 있도록 도와주고 싶었습니다
- 대부분 기술적 역량에 집중하다보니, 비즈니스를 잘 모르는 경우가 많습니다. 저는 데이터 분석가, 데이터 사이언티스트, 머신러닝 엔지니어, 데이터 엔지니어, 백엔드 개발자 등 모든 사람들이 자신이 속한 회사의 비즈니스는 잘 알고 있으면 좋다고 생각합니다
- 다만 문제 정의와 비슷하게 비즈니스를 공부하는 개념이 생소하고, 알려주기 어렵다고 생각했습니다. 그럼에도 불구하고 비즈니스를 아는 사람이 더욱 업무를 잘 할 수 있겠다 생각해서 비즈니스와 문제 정의를 하나로 합쳐 강의를 진행했습니다
- 비즈니스 공부법 - 데이터 분석가, 데이터 사이언티스트도 비즈니스를 알아야 합니다에 작성한 내용보다 더 많은 내용을 정리해서 핵심 위주로 공유했습니다

그렇게 위와 같은 커리큘럼이 완성되었습니다. 점진적으로 개발하며 문제 정의와 비즈니스를 아는 AI 엔지니어가 될 수 있도록 많은 내용을 담았습니다
학습을 잘 할 수 있도록, 강의 초반에 학습을 어떻게 하면 좋은지 어떤 학습 방법들이 있을지 예시를 공유하고 + 복습을 효율적으로 할 수 있는 방법 등을 제공했습니다
- 강의 PDF 자료를 확인해보니, 1400쪽 가량으로 자료를 만들었습니다. 나중에 현업에서 갈 때 한번 참고하면 좋겠단 생각으로 강의 자료를 만들었습니다
작성한 코드는 Boostcamp AI Tech Product Serving Github Repo에 나와있습니다. 멘토분들이 잘 도와주셔서 좋은 자료를 만들 수 있었습니다.

3기 : Product Serving + 러닝 마스터

2기 강의에서 Product Serving을 교육한 후, 학생분들의 학습 과정, 심리 상태를 파악했습니다
하나의 주제를 5개월동안 학습하는 일은 집중력이 매우 필요한 일이고, 심리 상태가 많이 변할 수 있습니다. 처음에 학습 의욕이 높았다가 점점 낮아질 수 있고, 그 부분을 교육 기관에서도 인지하고 있었습니다
- 저도 부트캠프 과정을 수강했기에 학습하는 동안 어떤 심리 상태일지 간접적으로 유추할 수 있었고 이 부분도 케어하는 역할이 필요하다 생각했습니다
여러 고민 끝에, 3기 시작하기 전에 운영진 분들에게 “러닝 마스터”란 역할을 제안했습니다
- 러닝 마스터란 러닝 메이트처럼 교육하는 전체 기간동안 같이 뛰는 마스터(=강사)입니다. 과정에서 힘든 내용이 있다면 왜 어려운지, 고민이 있다면 어떤 고민이 있는지 함께 나누기, 커리어를 위한 여러 코칭 등을 하는 역할입니다

러닝 마스터의 역할도 잘 하고 싶단 생각에 여러가지를 부스트캠프 AI Tech 운영진분들에게 제안했습니다.

1) 심리적 안정감을 위해 익명 채널 생성
2) 러닝 마스터와 커뮤니케이션 할 수 있는 채널 생성
3) 월 1회씩 러닝 마스터와 만나는 시간 만들기
4) 주기적으로 커리어 코칭, 이력서 피드백

1) 심리적 안정감을 위해 익명 채널 생성

교육 과정을 들으면 심리적 안정감이 낮아질 수 있습니다. 너무 많은 공부량에 압도될 수 있고, 이 공부를 계속 하는게 맞을까?란 생각을 할 수 있습니다
- 위와 같은 생각 중 “나만 그런 것이 아닐까?, 나만 지금 진도를 따라가지 못하는 것이 아닐까?” 등의 생각도 할 수 있습니다
- 많은 분들이 이런 생각을 하고 있고, 나 혼자가 아니라 많은 사람들이 이런 감정을 느끼고 있구나를 알게 되면서, 서로를 위로하고 격려할 수 있도록 만들고 싶었습니다
슬랙에서 익명으로 메세지를 보낼 수 있는 AnonymityBot를 사용하자고 제안했습니다

익명 채널이라 이상한 이야기나 험담이 올라오면 어쩌지?란 생각을 했으나 캠퍼분들에게 이 채널이 왜 존재하고, 이 채널에선 이것만은 지켜주세요라는 몇가지 규칙을 공유했습니다. 다행히 과정이 끝나는 동안 걱정했던 부분을 경험하지 않았습니다.

익명 채널에선 자신들의 고민을 솔직하게 공유하기, 궁금한 부분에 대한 질문하기 등 여러가지 내용이 올라왔습니다. 또한 감사함을 표현하는 분도 계셨습니다. 많은 분들이 서로에게 좋은 영향을 주었습니다

데이터로 보면 5개월간 약 1,000개의 메세지가 전송되었고 교육 과정 슬랙 중 많은 대화가 오고 간 채널 중 하나입니다.

2) 러닝 마스터와 커뮤니케이션 할 수 있는 채널 생성

슬랙 채널은 함께자라자는 의미로 함께자라기라고 만들었습니다. 김창준님의 함께 자라기의 책도 추천하며 혼자 성장하는 것 이상으로 함께 성장하는 것의 중요성을 공유했습니다
3)에서 나온 저와 주기적으로 만나는 시간에 대한 내용도 공유하고, 캠퍼분들의 고민도 들었습니다. 이 채널도 익명으로 메세지를 보낼 수 있도록 설정했습니다
저와 대화는 모두 이 채널에서 진행되었습니다

너무 좋게 봐주셔서 감사했던 메세지

위와 같은 내용을 주기적으로 전달했습니다(위 이미지를 자세히 보시려면 클릭 부탁드려요)

3) 월 1회씩 러닝 마스터와 만나는 시간 만들기

제가 러닝 마스터의 역할을 하며 이야기하고 싶었던 내용은 다음과 같습니다

단기적으로 여러분들이 취업을 하기 위해 무엇을 해야할까요?
장기적으로 여러분들의 삶을 잘 살기 위해 어떤 고민을 해야할까요?
부스트캠프에서 학습하며 생길 수 있는 고민 상담하기
주기적으로 읽으면 좋은 컨텐츠 제공하기

위 내용을 전달하기 위해 월 1회씩 캠퍼분들과 만났고, 수시로 슬랙에 여러 메세지를 전달했습니다. 저와 이야기하는 시간은 두런두런(Do Learn Do Run)이라는 이름으로 지었습니다.

처음 두런두런 세션 후, 많은 분들이 느낀 점을 작성해주셨습니다. 이 느낀 점을 보고 더욱 자극 받아 열심히 해야겠단 생각이 들었습니다.
두런두런 세션은 총 5회였는데, 다음과 같은 내용으로 진행되었습니다
- (1) 직군 이야기, 제 커리어 이야기, 삶의 지도, 질문하는 법
- (2) 이력서 작성하기
- (3) 산업, 회사 찾아보기
- (4) 프로젝트 매니징, 시스템 디자인 아키텍처 설계
- (5) 면접 이야기
- 두런두런 외에 Product Serving의 마스터 클래스도 활용해 실제론 8회 이상의 내용을 전달했습니다
같이 공부하다보니 남과 비교하는 경우가 있을 수 있는데, 이 부분에 대해서도 자세히 다룬 시간이 있었습니다. 임수정님께서 강의를 듣고 느낀 점에 대해 작성해주시기도 했습니다. [함께자라기] “남과 비교하기”의 오류
- 데이터 분석에서 자주 나오는 개념인 코호트로 생각해볼 수 있도록 제안드렸습니다

4) 주기적으로 커리어 코칭, 이력서 피드백

제가 보낸 대부분 메세지는 위와 같이 장문의 메세지가 많습니다. 많은 내용을 압축적으로 잘 전달하고자 노력했고, 감정 상태를 공감하며 여러 이야기를 드렸습니다.
- 단순히 “잘하고 있어!”만 이야기하는 것이 아니고, 여러 관점으로 이야기를 드리며, 그럼에도 불구하고 우리는 하나씩 나아가고 성장하고 있다는 이야기를 드렸습니다
- 반복적으로 나오는 내용은 두런두런 세션에서 이야기하고, 그 외에 질문이나 고민 상담에 대해선 메세지로 답변드렸습니다. 보통 메세지로 답변드리고, 다음 달 두런두런할 때 간단히 리마인드하는 방식으로 진행했습니다

두런두런 세션에서 이력서를 작성하고 공유하면 피드백드린다고 말씀드린 적이 있습니다. 150명 정도 되는 분들이 이력서를 올려주셨고, 공통적인 부분과 개인적인 부분을 나눠서 피드백 드렸습니다
- 피드백 하는 과정이 오래 걸리지만, 그럼에도 불구하고 한번 이력서를 피드백하는 일이 캠퍼분들에게 좋은 경험이 될 수 있을 것이라 믿고 다양한 관점으로 피드백 드렸습니다

러닝 마스터에 대해 캠퍼분들이 느낀 점

러닝 마스터의 역할과 두런두런 시간을 어떻게 느끼는지 궁금해서, 후기 작성을 부탁드렸습니다. 많은 분들이 후기를 작성해주셔서, “아 이렇게 느끼셨구나, 다음엔 무엇을 더 해보면 좋겠다” 등을 생각할 수 있게 되었습니다
- 후기에서 보완하면 좋을 부분에 대해 말씀해주신 분도 계셨습니다. 다양한 관점으로 저에 대해 피드백 받는 것을 좋아하기 때문에 보완 포인트를 더 자세히 읽었습니다
후기 글
그 외에도 부스트캠프 AI Tech 두런두런 마지막 시간에 간단한 피드백을 요청드렸습니다. 감사하게도 많은 분들이 50분이 넘게 작성해주셨습니다. 마지막 피드백의 응답률을 강의의 최종 감동 지표로 정의했는데, 좋은 피드백 주신 모든 부스트캠프 AI Tech 3기분들 감사합니다. 그 중 일부 제게 공유해주신 내용을 공유합니다(설문시 작성한 내용 사용에 대한 허락을 구했습니다)

위 이미지를 자세히 보시려면 클릭하시는 것을 추천합니다

교육을 만드는 과정

교육을 만드는 과정은 제게 큰 보람을 느끼는 작업입니다. 어떻게 해야 더 좋은 교육을 만들 수 있을까? 어떻게 해야 학습 효과를 더 높일 수 있을까? 함께 성장할 수 있는 시스템은 어떻게 만들 수 있을까?
- 위 고민 외에도 여러가지 고민을 하면서 지내고 있습니다. 정답은 무엇인지 모르지만, 지금 제가 할 수 있는 것과 떠오르는 아이디어를 진행해보고 더 좋은 길로 나아갈 수 있도록 계속 노력하고 있습니다
저는 “영향력”이란 Metric을 중요하게 생각합니다. 제 행동으로 많은 분들에게 좋은 영향을 미치는 삶을 계속 살고 싶습니다
이 글을 보는 분들에게도 작은 영감이 되었길 바랍니다. 교육 관련 이야기를 하고 싶으시다면 제 메일(snugyun01@gmail.com)으로 연락주세요!
제게 도움이 되었던 책 1권을 공유드리며 글을 마무리하겠습니다 :)
- 어떻게 공부할 것인가