0. 들어가며DE to MLOps 시리즈 14일차입니다. 벌써 2주차 마지막, 두 번째 주간 회고입니다. 이번 주는 제 주 무대인 데이터 엔지니어링으로 깊이 들어간 한 주였는데, 매일 쓰다 보니 각 편이 따로 노는 것 같기도 했습니다. 그래서 오늘은 한 발 물러서서, 이번 주 여섯 편(8~13일차)이 사실 하나의 이야기였다는 걸 정리해보려고 합니다. 1. 이번 주 전체 지도먼저 Week 2의 흐름을 한 장으로 정리했습니다.이번 주는 "왜 → 무엇을 → 어떻게"의 순서로 흘렀습니다. 먼저 "왜"로 시작했습니다. 8일차에서 데이터 엔지니어링이 왜 AI의 백본이 됐는지, 그리고 기존 역량을 "깨지 말고 확장하라"는 원칙을 세웠죠. 그다음 "무엇을" 만들어야 하는지로 들어갔습니다. 9일차에서 임베딩 파이프라인을..

0. 들어가며DE to MLOps 시리즈 13일차입니다. Week 2의 마지막 실무 편이자, 제 주력인 Spark로 돌아오는 글이라 쓰면서 제일 신났습니다.지난 며칠간 임베딩(9일차), 검색(10일차), 저장(11일차), 스트리밍(12일차)을 다뤘는데, 한 가지 빠진 게 있었습니다. "그 임베딩, 수백만 건을 대체 어떻게 빨리 만들지?"입니다. 문서 몇 개를 벡터로 바꾸는 건 노트북에서 for문으로도 되지만, 수백만~수천만 건을 다뤄야 하면 얘기가 완전히 달라집니다. 그리고 "대량으로 분산 처리하는 것"은 정확히 우리 데이터 엔지니어, 특히 Spark를 다루는 사람의 영역이죠. 오늘은 PySpark로 임베딩을 대량 생성하는 실무 패턴을 코드와 함께 정리해보겠습니다. 1. 가장 먼저 피해야 할 함정: 일반..

0. 들어가며DE to MLOps 시리즈 12일차입니다. 어제 11일차 멀티모달 레이크하우스 얘기 끝에 "실시간 처리"가 잠깐 나왔는데요, 오늘은 그 주제를 제대로 파봅니다. 배치에서 스트리밍으로, 그리고 이벤트 기반 아키텍처(Event-Driven Architecture) 전환 얘기입니다.사실 이건 제가 개인적으로도 정리하고 싶었던 주제입니다. 저는 그동안 배치 파이프라인을 주로 다뤄왔는데, 요즘은 어딜 가나 "실시간", "스트리밍"이 당연한 것처럼 얘기되거든요. 그러다 보니 "내가 하는 배치는 이제 구식인가?" 하는 생각이 들 때도 있었습니다. 그래서 이번에 자료를 찾아보면서, 배치와 스트리밍의 관계를 제대로 정리해봤습니다. 결론부터 말하면, 생각이 많이 정리됐고 조금 안심도 됐습니다. 1. 배치는 ..

0. 들어가며DE to MLOps 시리즈 11일차입니다. 지난 이틀간(9·10일차) 임베딩을 만들고, 그걸로 검색 품질을 끌어올리는 얘기를 했습니다. 그런데 여기서 한 가지 현실적인 질문이 생깁니다. "그래서 그 벡터들, 이미지들, 원본 문서들을 다 어디에 어떻게 저장하지?"보통은 각자 편한 곳에 따로 둡니다. 이미지는 S3에, 벡터는 벡터DB에, 메타데이터는 웨어하우스에. 저도 처음엔 이게 당연한 줄 알았는데, AI 워크로드가 본격화되면서 이 "따로따로"가 생각보다 큰 비용이 된다는 걸 알게 됐습니다. 오늘은 그 문제를 푸는 새로운 저장 구조, 멀티모달 레이크하우스(Multimodal Lakehouse)를 정리해보겠습니다. 아직 제가 실무에 도입해본 건 아니라, 개념을 잡는 정리 노트로 봐주시면 됩니다..

0. 들어가며DE to MLOps 시리즈 10일차입니다. 어제 9일차에서는 문서를 잘라(청킹) 벡터로 만들어 저장소에 넣는 임베딩 파이프라인을 다뤘습니다. 그런데 벡터를 잘 만들어 넣어두는 것과, 질문이 들어왔을 때 "제대로 된 걸 찾아오는 것"은 또 다른 얘기더라고요.사실 RAG를 처음 접하면 "질문을 벡터로 바꿔서 제일 비슷한 걸 가져오면 끝 아닌가?" 싶은데, 실무에서 이렇게만 하면 생각보다 엉뚱한 걸 자주 가져옵니다. 오늘은 그 "검색 품질"을 끌어올리는 방법을 정리해보겠습니다. 핵심은 세 가지입니다. 벡터 검색만 쓰지 말고 키워드 검색과 섞을 것(하이브리드), 한 번 찾은 걸 다시 걸러낼 것(리랭킹), 그리고 반드시 측정할 것. 저도 이번에 공부하면서 "아, 검색이 이렇게까지 공들이는 영역이구나..

0. 들어가며지난 32편 끝에서 질문 하나를 남겨뒀습니다. 어텐션만으로는 안 되나? 그때까지 어텐션은 조연이었습니다. 인코더도 RNN, 디코더도 RNN이고 그 사이를 어텐션이 이어주는 구조였습니다. 그런데 2017년에 나온 논문이 그 조연을 주연으로 올렸습니다. 바로 지금의 모든 LLM의 시작이 되는 논문인 「Attention Is All You Need」 인데요. 제목이 답을 그대로 말해줍니다. RNN을 완전히 걷어내고 어텐션만으로 쌓은 구조, Transformer입니다. 지금 쓰이는 GPT도 BERT도 Claude도, 이미지 쪽의 ViT와 Stable Diffusion까지 전부 이 구조에서 출발합니다. 이번 글은 이런 순서로 정리해보겠습니다.RNN을 버려야 했던 진짜 이유 (성능이 아니라 속도입니다)..

0. 들어가며DE to MLOps 시리즈 9일차입니다. 어제 8일차에서는 "데이터 엔지니어링이 AI의 백본이 됐다"는 큰 그림을 그리면서, 우리 결과물이 테이블에서 임베딩·벡터로 넓어진다는 얘기를 했습니다. 그런데 거기까진 개념이었고, 막상 "그래서 그 임베딩 파이프라인을 어떻게 짜는데?"라는 질문엔 답을 안 했죠.오늘은 그 부분을 파봅니다. 임베딩 파이프라인을 설계할 때 실제로 부딪히는 세 가지 고민, 그러니까 문서를 어떻게 자를지(청킹), 바뀐 걸 어떻게 효율적으로 다시 벡터화할지(증분 처리), 그리고 모델이 바뀌면 어떻게 할지(버전 관리)를 하나씩 정리해보겠습니다. 저도 아직 프로덕션에 벡터 파이프라인을 굴려본 건 아니라서, 이번 글은 공부하며 정리한 설계 노트에 가깝습니다. 1. 먼저 짚고 갈 것..

0. 들어가며지난 편에서 오토인코더를 다루면서 "전체를 고정 크기 벡터 하나로 압축한다"는 발상을 봤습니다. 거기서는 그게 장점이었습니다. 좁은 통로로 밀어 넣어야 중요한 것만 남으니까요.그런데 같은 발상이 29편 RNN에서는 정반대로 지적됐습니다. 기계 번역 이야기를 하면서, 문장이 아무리 길어도 벡터 하나에 다 밀어 넣어야 한다는 점을 병목으로 짚었습니다.이번에 다룰 어텐션(Attention)은 그 지점을 정면으로 건드립니다. 발상 자체는 한 문장으로 줄어듭니다. "압축해서 들고 다니지 말고, 필요할 때마다 원본을 다시 보자." 말로만 들으면 단순해 보이는데, 이후 딥러닝의 흐름은 대부분 여기서 갈라져 나왔습니다. 지금의 LLM도, 이미지 생성 모델도 결국 이 아이디어 위에 서 있습니다. 이 시리즈에..