AI/ML 기술 심층분석

1. 왜 분산해야 하나? 2012년 구글의 DistBelief 논문 이후, 딥러닝 모델과 데이터셋은 빠르게 커졌습니다. GPT-3는 1750억 개의 파라미터를 가지고 있고, 최신 멀티모달 모델은 수조 개의 토큰으로 학습됩니다. 단일 GPU 메모리로는 감당할 수 없습니다. 그런데 “여러 노드에서 학습한다"는 전제는 같지만, 목적은 다릅니다. 분산 학습(Distributed Training)은 속도가 목적입니다. 중앙 데이터센터에서 데이터를 여러 GPU로 분할하여 학습 시간을 단축합니다. Facebook은 2017년 논문에서 ImageNet을 1시간 만에 학습했다고 보고했습니다. 연합 학습(Federated Learning)은 프라이버시가 목적입니다. 데이터를 중앙으로 모을 수 없을 때, 모델을 각 클라이언트로 보내서 로컬 학습 후 결과만 집계합니다. 구글 키보드는 사용자의 타이핑 데이터를 서버로 보내지 않고도 예측 모델을 개선합니다. ...

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 토큰이 주어진 지금, 과연 모든 작업에 긴 컨텍스트를 사용하는 것이 최선일까요? 많은 개발자들이 “길면 길수록 좋다"는 직관을 따르지만, 실제로는 컨텍스트 길이가 늘어날수록 성능이 떨어지는 현상이 연구를 통해 확인되었습니다. ...

들어가며 - LLM은 아는 것을 말하는 게 아니라 확률적으로 생성한다 ChatGPT나 Claude에 같은 질문을 두 번 던져 보신 적 있으신가요? 분명 동일한 프롬프트인데, 돌아오는 답변의 문장 구조나 단어 선택이 미묘하게 달라집니다. 처음에는 버그처럼 느껴질 수 있지만, 이것은 LLM의 근본적인 작동 원리에서 비롯된 의도된 설계입니다. LLM은 질문에 대한 정답을 데이터베이스에서 꺼내오는 시스템이 아닙니다. 주어진 문맥을 바탕으로 다음에 올 토큰의 확률 분포를 계산하고, 그 분포에서 하나를 샘플링하는 과정을 반복합니다. 면이 수만 개인 주사위를 매 토큰마다 새로 깎아서 굴리는 셈입니다. ...

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