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도, 이미지 생성 모델도 결국 이 아이디어 위에 서 있습니다. 이 시리즈에..

0. 들어가며지난 세 편에서 CNN, RNN, LSTM을 정리해봤는데요. 다시 보면 셋 다 공통점이 하나 있습니다. 정답 레이블이 있어야 학습이 됐다는 거죠. 이미지에는 "고양이"라는 label이, 문장에는 "긍정"이라는 label이 붙어 있어야 했잖아요. 그런데 현실에서 일하다 보면 이게 제일 아쉬운 지점이더라고요. 데이터는 쌓여 있는데 레이블이 거의 없거나, 붙이려면 사람 손이 한참 들어가야 하는 경우가 훨씬 많으니까요. 로그도 그렇고 거래 기록도 그렇습니다.그래서 이번에 다룰 오토인코더(AutoEncoder)는 질문 자체가 좀 다릅니다. "정답이 없어도 데이터 자체에서 뭔가 배울 수 있을까?" 아이디어는 의외로 단순한데요, 입력을 좁은 통로로 압축했다가 다시 원래대로 복원하게 시키는 겁니다. 잘 복..

0. 들어가며DE to MLOps 시리즈 8일차이자, Week 2의 첫 글입니다. 지난 한 주는 에이전트와 개발 방식이 어떻게 바뀌고 있는지에 초점을 뒀는데요, 이번 주부터는 제 주 무대인 데이터 엔지니어링 쪽으로 이야기를 가져와 보려고 합니다.첫 주제로 고른 건 조금 도발적인 문장입니다. "2026년 데이터 엔지니어링은 AI의 백본(backbone)이 되었다." 사실 저도 이 표현을 처음 봤을 때는 그냥 흔한 마케팅 문구인가 싶었습니다. 그런데 요즘 온프렘 환경을 클라우드로 옮기는 작업을 하고, 팀에서 AI 관련 요구가 하나둘 들어오는 걸 겪다 보니, 이 말이 생각보다 진짜였구나 하는 걸 체감하게 되더라고요. 오늘은 왜 이 말이 빈말이 아닌지, 그리고 그게 우리 데이터 엔지니어의 일을 어떻게 바꾸고 있..

0. 들어가며DE to MLOps 시리즈 7일차입니다. 오늘은 새로운 주제 대신, 지난 6일을 돌아보는 회고 시간을 가지려 합니다. 매일 글을 쓰다 보면 나무 하나하나에 몰입하게 되는데, 일주일에 한 번쯤은 숲 전체를 보는 게 필요하다고 생각합니다. 이번 주에 다룬 여섯 편이 사실 하나의 이야기였다는 걸, 저 자신도 이 회고를 쓰며 다시 확인했습니다. 1. 이번 주 전체 지도 도식화먼저 Week 1의 여섯 편이 어떻게 연결되는지 한 장으로 정리했습니다. 돌아보면 이번 주의 흐름은 세 단계였습니다. 트렌드로 큰 지도를 그리고(1일차), 개발 방식의 전환을 파고들고(2~5일차), 마지막에 시장의 현실로 착지했습니다(6일차). 1일차에서는 2026년 IT 트렌드 10선으로 "하이프에서 실증으로"라는 큰 흐름과..