1. 1M 시대의 도래 Anthropic은 2025년 Claude Sonnet 4.5에서 처음 1M 토큰 컨텍스트 윈도우를 도입했고, 이후 Opus 4.6(2025), Sonnet 4.6(2026년 2월)까지 이어지며 1M 컨텍스트가 표준으로 자리 잡았습니다. 단일 요청으로 약 750페이지 분량의 문서를 처리할 수 있습니다. Amazon Bedrock에서도 context-1m 베타 기능이 활성화되면서, 기업 환경에서도 대규모 문서 처리가 가능해졌습니다. 200K 토큰으로도 충분히 넓다고 생각했던 시절이 불과 1년 전입니다. 그런데 1M 토큰이 주어진 지금, 과연 모든 작업에 긴 컨텍스트를 사용하는 것이 최선일까요? 많은 개발자들이 “길면 길수록 좋다"는 직관을 따르지만, 실제로는 컨텍스트 길이가 늘어날수록 성능이 떨어지는 현상이 연구를 통해 확인되었습니다. ...
1. 왜 엔터프라이즈 지식 그래프인가 — Palantir Ontology가 보여준 것 최근 RAG(Retrieval-Augmented Generation) 파이프라인이 사실상 표준으로 자리 잡으면서, 많은 팀이 “벡터 검색만으로 충분한가?“라는 질문에 부딪히고 있습니다. 이 질문에 가장 설득력 있는 답을 내놓은 사례가 바로 Palantir의 Ontology입니다. Palantir Ontology 핵심 요소 Palantir Foundry 플랫폼은 엔터프라이즈 데이터를 세 가지 축으로 구조화합니다. Object Type: 도메인의 핵심 엔티티를 정의합니다. 고객, 장비, 계약 등 비즈니스가 관심을 두는 대상 그 자체입니다. Link (Relationship): 객체 간 관계를 명시적으로 연결합니다. 고객 → 보유 → 장비, 계약 → 포함 → 서비스 항목처럼 멀티홉 탐색이 가능한 그래프 구조를 만듭니다. Action: 온톨로지 위에서 실행 가능한 비즈니스 로직을 정의합니다. 단순 조회가 아니라 “이 장비의 유지보수 일정을 재배치하라” 같은 의사결정과 실행까지 이어집니다. ...
비정형 문서 파싱이 어려운 이유 엔터프라이즈 환경에서 RAG(Retrieval-Augmented Generation) 파이프라인을 구축해 보신 분이라면, 가장 먼저 부딪히는 벽이 “원본 문서에서 의미 있는 구조를 살려 텍스트를 뽑아내는 것"이라는 데 공감하실 겁니다. 전통적 접근법이 왜 한계에 부딪히는지, 그리고 구조 보존이 왜 중요한지 정리해 보겠습니다. PDF 내부 구조의 복잡성 PDF는 본질적으로 화면 렌더링을 위한 포맷이지, 시맨틱 구조를 전달하기 위한 포맷이 아닙니다. 스캔된 PDF는 텍스트 레이어 자체가 존재하지 않습니다. 디지털 네이티브 PDF조차 다단(multi-column) 레이아웃이나 표·차트·이미지가 혼재된 페이지에서는 텍스트 추출 순서가 뒤엉키기 일쑤입니다. 실제로 써보면 PyPDF2나 pdfplumber 같은 라이브러리는 단순 문서에서는 잘 동작하지만, 복잡한 레이아웃 앞에서는 금세 무너집니다. ...
왜 하이브리드 추천인가 — 단일 추천 엔진의 한계 개인화 추천 시스템을 설계할 때 가장 먼저 부딪히는 질문은 “어떤 엔진 하나로 충분하지 않을까?“입니다. 결론부터 말씀드리면, 단일 엔진만으로는 실서비스 수준의 추천 품질을 달성하기 어렵습니다. 각 접근법의 한계를 짚어 보겠습니다. 협업 필터링(Collaborative Filtering) — Amazon Personalize Amazon Personalize는 사용자-아이템 상호작용 데이터를 기반으로 개인화 추천을 제공합니다. 그러나 신규 사용자나 신규 아이템처럼 상호작용 이력이 부족한 콜드스타트(Cold Start) 상황에서는 추천 품질이 눈에 띄게 떨어집니다. “왜 이 아이템을 추천했는지"에 대한 콘텐츠 맥락(Content Context)도 부족해서, 사용자가 지금 검색하거나 관심을 보이는 주제와 동떨어진 결과가 나올 수 있습니다. ...