기업용 대규모 언어 모델(LLM) 도입이 가속화되고 있지만, 실무 투입을 가로막는 치명적인 장벽이 있습니다. 바로 AI가 거짓 정보를 사실처럼 지어내는 ‘할루시네이션(Hallucination)’ 현상입니다. 본 문서에서는 실제 공공입찰 데이터 파이프라인을 구축하며 겪었던 뼈아픈 실패와 경험을 바탕으로, AI 할루시네이션의 기술적 원인을 분석하고 이를 해결하기 위한 RAG(검색 증강 생성) 아키텍처와 마스터 데이터 관리(MDM)의 융합 방안을 심층적으로 다룹니다. 1. AI 할루시네이션(Hallucination)의 … 더 읽기
웹 크롤링을 통한 공공입찰 데이터 수집, pandas를 활용한 MDM 정규화, 그리고 퍼지 매칭(Fuzzy Matching)을 통한 중복 제거까지. 우리는 지난 시리즈를 통해 흩어진 외부 데이터를 완벽한 ‘단일 진실 공급원(SSOT)’으로 연성하는 파이프라인 로직을 완성했습니다. 하지만 진정한 엔터프라이즈 데이터 아키텍처는 사람의 개입 없이 365일 24시간 스스로 작동해야 합니다. 본 문서에서는 완성된 파이썬(Python) 수집 봇을 서버에 올리고, 지정된 시간에 … 더 읽기
파이썬 수집 엔진으로 데이터를 긁어오고(1단계), pandas를 통해 전사 마스터 데이터(MDM) 기준에 맞춰 정제(2단계)하는 데 성공하셨다면 데이터 파이프라인의 8할은 완성된 것입니다. 하지만 실제 엔터프라이즈 환경에서 데이터 엔지니어들을 가장 괴롭히는 숨겨진 적은 바로 ‘중복(Duplication)’입니다. 조달청 나라장터(G2B)와 자체 조달 시스템을 병행하는 발주처의 경우, 동일한 입찰 건을 양쪽에 이중으로 올리는 경우가 빈번합니다. 더 큰 문제는 띄어쓰기 하나, 특수문자 하나만 … 더 읽기
파이썬 수집 봇(Bot)을 통해 조달청 나라장터(G2B)와 LH의 입찰 데이터를 긁어오는 데 성공하셨다면, 데이터 엔지니어링의 첫 관문을 통과하신 것입니다. 하지만 수집된 엑셀이나 CSV 파일을 열어보면, 겉보기엔 화려한 데이터들이 실상은 ‘정제되지 않은 쓰레기(Raw Garbage)’에 가깝다는 것을 깨닫게 됩니다. 한국토지주택공사가 ‘LH’, ‘토지주택공사’, 심지어 오타가 섞인 ‘한국토지주탹공사’로 제각각 표기되어 있다면, 이 데이터로는 어떤 유의미한 비즈니스 인사이트도 뽑아낼 수 없습니다. … 더 읽기
지난 데이터 파이프라인 아키텍처 기획에 이어, 이번 포스팅에서는 외부의 비정형 공공 데이터를 우리 시스템으로 끌어오는 3계층 중 첫 번째, 수집 계층(Ingestion Layer)의 파이썬(Python) 코드를 직접 구현해 봅니다. 실제 현업에서 조달청 나라장터(G2B)나 한국토지주택공사(LH)의 입찰 데이터를 수집해 보면, 교과서적인 API 호출만으로는 해결되지 않는 수많은 변수와 마주하게 됩니다. 단순한 데이터 스크래핑을 넘어, 서버 차단을 방지하고 예외 상황을 철저히 … 더 읽기
앞선 포스팅에서 우리는 데이터 파이프라인의 전체적인 3계층(3-Tier) 아키텍처를 설계하며, 외부의 혼란스러운 비정형 데이터를 내부의 질서 있는 자산으로 편입시키는 밑그림을 그렸습니다. 기획이 끝났다면 이제는 실제 코드가 불을 뿜으며 구동될 차례입니다. 조달청 나라장터(G2B)나 한국토지주택공사(LH)의 방대한 입찰 공고와 개찰 결과를 매일 수작업으로 엑셀에 다운로드하여 확인하는 것은 엄청난 리소스 낭비이자 휴먼 에러의 온상입니다. 본 문서에서는 파이썬(Python)을 활용하여 이 과정을 … 더 읽기
엔터프라이즈 환경에서 데이터 거버넌스와 마스터 데이터 관리(MDM)의 체계를 잡았다면, 다음 과제는 외부의 가치 있는 데이터를 우리 시스템 내부로 안전하고 정확하게 끌어오는 것입니다. 특히 조달청 나라장터(G2B)나 한국토지주택공사(LH)에서 매일 쏟아지는 공공입찰 데이터는 비즈니스 기회를 포착하기 위한 핵심 자산입니다. 하지만 공공데이터는 발주처마다 양식이 다르고, 수작업 입력으로 인한 오탈자가 난무하는 비정형(Unstructured) 텍스트의 바다와 같습니다. 이를 비즈니스 인사이트로 변환하기 위해서는 … 더 읽기
지난 두 번의 포스팅을 통해 우리는 현대 데이터 아키텍처의 양대 산맥인 ‘데이터 패브릭(Data Fabric)’의 기술 중심적 연결성과 ‘데이터 메시(Data Mesh)’의 조직 중심적 분산 철학을 깊이 있게 살펴보았습니다. 많은 기업의 리더들이 “우리 회사는 패브릭으로 갈 것인가, 메시로 갈 것인가?”라는 양자택일의 딜레마에 빠지곤 합니다. 하지만 현업 아키텍트들의 결론은 명확합니다. 이 둘은 상호 배타적인 것이 아니며, 진정한 데이터 … 더 읽기
앞선 포스팅에서 우리는 차세대 데이터 아키텍처의 양대 산맥인 ‘데이터 패브릭(Data Fabric)’과 ‘데이터 메시(Data Mesh)’의 개념적 차이를 조망해 보았습니다. 기술 중심의 패브릭과 달리, 데이터 메시는 철저하게 ‘조직과 사람’ 중심의 분산 아키텍처를 지향합니다. 기존의 거대한 데이터 레이크(Data Lake)나 데이터 웨어하우스(DW) 중심의 중앙 집중형 모델은 데이터 엔지니어링 팀에 엄청난 병목(Bottleneck) 현상을 유발했습니다. 자막 데가니(Zhamak Dehghani)가 창안한 ‘데이터 메시’는 … 더 읽기
지난 30편의 연재를 통해 우리는 엔터프라이즈 환경에서 마스터 데이터 관리(MDM)와 데이터 거버넌스의 거대한 뼈대를 완성했습니다. 중앙 집중형 허브와 데이터 레이크를 통해 ‘단일 진실 공급원(SSOT)’을 확보하는 것은 데이터 관리의 훌륭한 정석입니다. 하지만 비즈니스 규모가 기하급수적으로 커지고 하이브리드 멀티 클라우드 환경이 복잡해지면서, 모든 데이터를 물리적으로 한 곳에 모으는 전통적인 중앙 집중형 방식은 속도와 유연성 측면에서 서서히 한계를 … 더 읽기