Posts

1편 요약과 2편의 문제의식: 왜 LLM은 “무난한 답"만 하는가 1편에서는 LLM의 출력을 구조적으로 제어하는 패턴들을 살펴보았습니다. JSON Schema를 활용한 Output Structuring, 유해 출력을 차단하는 Guardrails, Few-shot Prompting을 통한 포맷 유도까지, 이 패턴들의 공통 목표는 “LLM이 어떤 형태로 답하는가"를 통제하는 것이었습니다. 하지만 실무에서 LLM을 도메인 전문가로 활용하려 할 때, 형태보다 더 근본적인 문제에 부딪힙니다. “무엇을 말하는가” 자체가 지나치게 무난하다는 점입니다. 중립화(Neutralization)는 어디서 오는가 현대 LLM은 RLHF(Reinforcement Learning from Human Feedback)와 안전성 정렬(Safety Alignment) 과정을 거칩니다. 이 과정에서 모델은 논쟁적 주장, 단정적 판단, 한쪽으로 치우친 추천을 체계적으로 회피하도록 학습됩니다. 개인적으로 이 현상을 “Neutralization"이라고 부르는데, 모델이 가진 지식의 문제가 아니라 출력 정책의 문제라는 점이 핵심입니다. ...

왜 LLM 출력 제어가 프로덕션의 핵심 과제인가 프로덕션 환경에서 LLM 기반 애플리케이션을 운영해 보신 분이라면, 프롬프트 엔지니어링(Prompt Engineering)만으로는 출력 품질을 안정적으로 보장하기 어렵다는 사실을 체감하셨을 것입니다. “JSON으로 응답해 주세요"라고 명시했는데도 중괄호가 빠지거나, 고객 응대 챗봇이 갑자기 반말로 전환되거나, 민감한 콘텐츠가 필터 없이 그대로 노출되는 상황. 실제로 써보면 이런 문제는 예외가 아니라 일상입니다. 특히 하루 수만 건의 요청을 처리하는 서비스에서는 낮은 확률의 실패도 곧 대규모 장애로 이어집니다. 이런 문제를 체계적으로 해결하기 위해, 출력 제어 패턴을 크게 두 가지 축으로 나눠볼 수 있습니다. ...

1. 왜 모델 성능만으로는 코딩 에이전트를 설명할 수 없는가 AI 코딩 에이전트의 성능을 이야기할 때, 우리는 습관적으로 “어떤 모델을 쓰느냐"부터 묻게 됩니다. 하지만 SWE-bench 리더보드를 조금만 주의 깊게 살펴보면, 같은 기반 모델(base model)을 사용하면서도 에이전트 시스템에 따라 상당한 성능 격차가 발생하는 사례를 어렵지 않게 발견할 수 있습니다. 동일한 모델인데 결과가 크게 달라진다면, 그 차이는 어디에서 오는 걸까요? 핵심은 하니스(Harness), 즉 모델이 코드를 읽고, 수정하고, 실행 결과를 받아보는 도구 인터페이스(tool interface) 설계에 있습니다. 구체적으로 분해하면 다음 요소들이 실질적 병목으로 작용합니다. ...

1. 설비 예방정비(Predictive Maintenance)의 핵심 과제 제조·플랜트·테마파크 할 것 없이, 설비가 멈추는 순간 비용은 기하급수적으로 늘어납니다. 예방정비(Predictive Maintenance, PM)는 이 다운타임을 줄이기 위한 핵심 전략이며, 기술적으로는 크게 두 가지 축으로 나뉩니다. PM의 두 축: 이상탐지와 잔여수명 예측 과제 핵심 질문 비즈니스 임팩트 시계열 이상탐지 (Anomaly Detection) “지금 설비가 정상인가?” 돌발 고장 방지, 즉각 대응 잔여수명 예측 (Remaining Useful Life, RUL) “이 부품이 언제 교체 시점에 도달하는가?” 정비 일정 최적화, 부품 재고 관리 이상탐지는 실시간성이 생명이고, RUL 예측은 장기 트렌드를 읽어야 하므로 모델 설계 철학 자체가 다릅니다. 개인적으로 현장에서 느끼는 건, 이상탐지는 비교적 빠르게 도입할 수 있지만 RUL은 충분한 고장 이력 데이터가 확보되지 않으면 정확도를 담보하기 어렵다는 점입니다. ...

1. Mechanistic Interpretability란 무엇인가? 대규모 언어 모델(LLM)의 성능이 올라갈수록, “이 모델은 왜 이런 답을 내놓는가?“라는 질문이 점점 절실해지고 있습니다. Mechanistic Interpretability(기계적 해석 가능성)는 바로 이 질문에 가장 근본적인 수준에서 답하려는 연구 분야입니다. 기존 XAI와 무엇이 다른가? 우리가 익숙한 Explainable AI(XAI) 기법들, 이를테면 SHAP, LIME, Attention Visualization 같은 것들은 대부분 사후 설명(post-hoc explanation) 방식입니다. 모델을 블랙박스로 두고, 입력과 출력의 관계를 외부에서 근사적으로 해석하는 것이죠. 반면 Mechanistic Interpretability는 신경망 내부의 가중치(weight)와 활성화(activation) 패턴을 직접 분석합니다. 모델이 실제로 학습한 알고리즘 자체를 역공학(reverse engineering)하려는 접근입니다. ...

1. 왜 엔터프라이즈 지식 그래프인가 — Palantir Ontology가 보여준 것 최근 RAG(Retrieval-Augmented Generation) 파이프라인이 사실상 표준으로 자리 잡으면서, 많은 팀이 “벡터 검색만으로 충분한가?“라는 질문에 부딪히고 있습니다. 이 질문에 가장 설득력 있는 답을 내놓은 사례가 바로 Palantir의 Ontology입니다. Palantir Ontology 핵심 요소 Palantir Foundry 플랫폼은 엔터프라이즈 데이터를 세 가지 축으로 구조화합니다. Object Type: 도메인의 핵심 엔티티를 정의합니다. 고객, 장비, 계약 등 비즈니스가 관심을 두는 대상 그 자체입니다. Link (Relationship): 객체 간 관계를 명시적으로 연결합니다. 고객 → 보유 → 장비, 계약 → 포함 → 서비스 항목처럼 멀티홉 탐색이 가능한 그래프 구조를 만듭니다. Action: 온톨로지 위에서 실행 가능한 비즈니스 로직을 정의합니다. 단순 조회가 아니라 “이 장비의 유지보수 일정을 재배치하라” 같은 의사결정과 실행까지 이어집니다. ...

1. 왜 HVAC 제어에 강화학습인가 — RL 기초와 HVAC 문제의 궁합 건물 에너지 소비에서 HVAC(Heating, Ventilation, and Air Conditioning) 시스템이 차지하는 비중은 상당합니다. 그렇다면 이 시스템을 어떻게 하면 더 똑똑하게 제어할 수 있을까요? 이번 포스트에서는 강화학습(Reinforcement Learning, RL)이 HVAC 최적화에 왜 주목받고 있는지, 핵심 논문 다섯 편을 중심으로 살펴보겠습니다. RL 핵심 개념을 HVAC에 매핑하기 RL은 마르코프 결정 과정(MDP)으로 정의됩니다. HVAC 제어에 매핑하면 다음과 같습니다. MDP 구성요소 HVAC 제어에서의 의미 상태(State) 실내 온도, 습도, 재실자 수, 외기 온도·일사량, 현재 시각 등 행동(Action) 냉난방 설정 온도, 팬 속도, 밸브 개도율 조절 보상(Reward) 에너지 절감량 ↑, 쾌적 범위 이탈 패널티 ↓ 의 가중합 전이(Transition) 현재 제어 입력 후 건물 열역학에 의해 변화하는 다음 상태 에이전트(Agent)는 이 MDP 위에서 정책(Policy), 즉 “이 상태에서 어떤 행동을 선택할지"의 전략을 학습합니다. 가치함수(Value Function)를 통해 장기적 누적 보상을 추정하는 구조입니다. 간단한 보상함수 예시를 코드로 표현하면 아래와 같습니다. ...

비정형 문서 파싱이 어려운 이유 엔터프라이즈 환경에서 RAG(Retrieval-Augmented Generation) 파이프라인을 구축해 보신 분이라면, 가장 먼저 부딪히는 벽이 “원본 문서에서 의미 있는 구조를 살려 텍스트를 뽑아내는 것"이라는 데 공감하실 겁니다. 전통적 접근법이 왜 한계에 부딪히는지, 그리고 구조 보존이 왜 중요한지 정리해 보겠습니다. PDF 내부 구조의 복잡성 PDF는 본질적으로 화면 렌더링을 위한 포맷이지, 시맨틱 구조를 전달하기 위한 포맷이 아닙니다. 스캔된 PDF는 텍스트 레이어 자체가 존재하지 않습니다. 디지털 네이티브 PDF조차 다단(multi-column) 레이아웃이나 표·차트·이미지가 혼재된 페이지에서는 텍스트 추출 순서가 뒤엉키기 일쑤입니다. 실제로 써보면 PyPDF2나 pdfplumber 같은 라이브러리는 단순 문서에서는 잘 동작하지만, 복잡한 레이아웃 앞에서는 금세 무너집니다. ...

왜 하이브리드 추천인가 — 단일 추천 엔진의 한계 개인화 추천 시스템을 설계할 때 가장 먼저 부딪히는 질문은 “어떤 엔진 하나로 충분하지 않을까?“입니다. 결론부터 말씀드리면, 단일 엔진만으로는 실서비스 수준의 추천 품질을 달성하기 어렵습니다. 각 접근법의 한계를 짚어 보겠습니다. 협업 필터링(Collaborative Filtering) — Amazon Personalize Amazon Personalize는 사용자-아이템 상호작용 데이터를 기반으로 개인화 추천을 제공합니다. 그러나 신규 사용자나 신규 아이템처럼 상호작용 이력이 부족한 콜드스타트(Cold Start) 상황에서는 추천 품질이 눈에 띄게 떨어집니다. “왜 이 아이템을 추천했는지"에 대한 콘텐츠 맥락(Content Context)도 부족해서, 사용자가 지금 검색하거나 관심을 보이는 주제와 동떨어진 결과가 나올 수 있습니다. ...

왜 프루닝인가 — 모델 압축의 필요성과 프루닝의 위치 GPT-3의 175B 파라미터가 세상을 놀라게 한 것이 불과 몇 년 전인데, 이제는 LLaMA 70B를 “비교적 작은 모델"이라 부르는 시대가 되었습니다. 모델 크기가 폭증하면서 추론 비용, GPU 메모리, 응답 지연(latency) 문제는 더 이상 연구실만의 고민이 아니라 서비스 전체의 병목이 되고 있습니다. 개인적으로 70B 모델을 단일 A100 80GB에 올려보려 할 때마다 OOM(Out of Memory)을 마주치는데, 이럴 때 압축의 필요성을 절실히 느끼게 됩니다. 모델 압축 기법의 전체 지형도 이 문제를 해결하기 위한 대표적인 모델 압축(Model Compression) 기법은 다음과 같습니다. ...