들어가며 - LLM은 아는 것을 말하는 게 아니라 확률적으로 생성한다 ChatGPT나 Claude에 같은 질문을 두 번 던져 보신 적 있으신가요? 분명 동일한 프롬프트인데, 돌아오는 답변의 문장 구조나 단어 선택이 미묘하게 달라집니다. 처음에는 버그처럼 느껴질 수 있지만, 이것은 LLM의 근본적인 작동 원리에서 비롯된 의도된 설계입니다. LLM은 질문에 대한 정답을 데이터베이스에서 꺼내오는 시스템이 아닙니다. 주어진 문맥을 바탕으로 다음에 올 토큰의 확률 분포를 계산하고, 그 분포에서 하나를 샘플링하는 과정을 반복합니다. 면이 수만 개인 주사위를 매 토큰마다 새로 깎아서 굴리는 셈입니다. ...
1. 추천 시스템, 무엇이 부족한가 추천 시스템(Recommendation System)은 디지털 서비스의 핵심 인프라입니다. Netflix의 콘텐츠 추천, Amazon의 상품 추천, YouTube의 영상 추천까지, 사용자 경험의 상당 부분을 추천 알고리즘이 결정합니다. 이 중 가장 널리 사용되는 방식이 협업 필터링(Collaborative Filtering, CF)입니다. “나와 비슷한 행동을 보인 사용자가 좋아한 아이템을 추천한다"는 단순하지만 강력한 원리입니다. 수십 년간 검증된 이 접근법은 여전히 대규모 프로덕션 시스템의 근간이며, 필자가 이전에 다룬 Amazon Personalize 하이브리드 추천 아키텍처도 이 패러다임 위에 설계된 것입니다. ...
1. 코딩 에이전트 시대, 왜 비교가 필요한가 2025년 하반기부터 AI 코딩 에이전트 시장이 급격히 달라졌습니다. 단순 코드 자동완성을 넘어, 프로젝트 구조를 설계하고 테스트를 작성하며 배포까지 수행하는 에이전틱(agentic) 코딩 도구가 본격적으로 등장했습니다. 문제는 선택지가 너무 많다는 것입니다. Cursor, Windsurf, Claude Code, Kiro, Copilot, Devin, Google Antigravity 등 수십 개의 도구가 저마다 “최고의 코딩 에이전트"를 표방하고 있습니다. 벤치마크 숫자만 보면 어떤 도구가 좋은지 판단하기 어렵습니다. SWE-bench에서 80%를 달성한 모델이 실제 프로젝트에서도 80%의 문제를 해결해 주는 것은 아니기 때문입니다. ...
1. 들어가며: LLM API 호출만으로는 부족한 이유 최근 개발 워크플로우에 LLM을 도입하는 팀이 빠르게 늘고 있습니다. 대부분의 첫 시도는 Anthropic API를 직접 호출하는 아래와 같은 형태일 것입니다. import anthropic client = anthropic.Anthropic() response = client.messages.create( model="global.anthropic.claude-sonnet-4-6", max_tokens=1024, messages=[{"role": "user", "content": "Fix the bug in my auth module"}], ) print(response.content.text) 코드 한 줄의 버그를 잡거나 간단한 유틸 함수를 생성할 때는 이 단순 프롬프트-응답 루프(Single-turn Prompt-Response Loop)만으로도 충분합니다. 하지만 실제로 써보면, 프로덕션 수준의 코딩 작업에서는 금세 벽에 부딪힙니다. 먼저 컨텍스트 유실(Context Loss) 문제가 있습니다. 프로젝트의 디렉터리 구조, 의존성 그래프, 기존 코드 컨벤션 같은 정보가 매 호출마다 사라집니다. 개발자가 매번 수동으로 컨텍스트를 재구성해야 하고, 이는 토큰 낭비이자 품질 저하로 이어집니다. ...
1. 왜 지금 동물 AI인가 테마파크와 동물원, 야생 보전 현장에서 동물 개체 단위의 행동 모니터링 수요가 빠르게 늘고 있습니다. 동물 복지 규제가 강화되고 멸종위기종 보전 프로젝트가 확대되면서, “지금 이 개체가 어디서 무엇을 하고 있는가"를 실시간으로 파악해야 하는 상황이 일상이 되었습니다. 하지만 사육사와 현장 연구자의 수작업 관찰(Manual Observation)에는 분명한 병목이 있습니다. 야행성 동물의 심야 행동이나 넓은 사파리 구역의 동시 모니터링은 인력만으로 물리적으로 불가능합니다. 같은 행동을 두고도 관찰자마다 기록이 달라지는 관찰자 간 변이(Inter-observer Variability) 문제도 있고, 개체 수가 수십에서 수백으로 늘어나면 개체 식별과 행동 분류를 동시에 수행하는 것 자체가 비현실적입니다. Nature Communications에 게재된 동물 행동 자동 분석 서베이 논문에서도 이러한 수작업 한계를 지적하며 딥러닝 기반 자동화의 필요성을 강조한 바 있습니다. ...
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)하려는 접근입니다. ...