Enterprise 환경에서 LLM 기반 시스템을 프로덕션에 배포하려면, 단순히 API를 호출하는 것 이상의 설계가 필요합니다. PoC에서는 잘 동작하던 시스템이 실제 트래픽과 다양한 질의를 만나면 hallucination, 검색 품질 저하, 보안 취약점 같은 문제가 수면 위로 올라옵니다. 이 글에서는 Enterprise LLM 시스템을 설계할 때 반복적으로 등장하는 5가지 핵심 패턴을 정리합니다. 각 패턴은 독립적으로 적용할 수도 있고, 하나의 시스템 안에서 조합할 수도 있습니다. 1. Enterprise RAG: 검색 품질이 답변 품질을 결정합니다 RAG(Retrieval-Augmented Generation)는 LLM이 외부 지식을 참조해서 답변을 생성하는 기법입니다. 원리 자체는 단순하지만, 5만 건 이상의 내부 문서를 다루는 Enterprise 환경에서는 설계 난이도가 급격히 올라갑니다. ...
2026년, AI 에이전트가 도구를 쓰기 시작했다 AI가 질문에 답하는 걸 넘어 실제 업무 도구를 사용하기 시작했습니다. 이메일을 보내고, 문서를 편집하고, 캘린더를 관리합니다. Anthropic의 Claude Cowork는 Gmail, Google Drive, DocuSign 같은 서비스를 플러그인으로 연결해서 반복 작업을 자동화합니다. Spotify는 고객 지원 티켓을 AI 에이전트로 처리하고 있고, Novo Nordisk는 내부 문서 검색과 요약에 활용합니다. AWS가 2026년 3월 발표한 OpenClaw on Lightsail도 비슷한 방향입니다. 터미널 명령을 실행하고, Git 커밋을 만들고, 코드 리뷰를 진행하는 자율 AI 에이전트를 Lightsail 인스턴스 하나로 띄울 수 있습니다. 한 달에 몇 달러면 팀 전용 AI 개발자를 둘 수 있는 셈입니다. ...
1. 왜 모델 성능만으로는 코딩 에이전트를 설명할 수 없는가 AI 코딩 에이전트의 성능을 이야기할 때, 우리는 습관적으로 “어떤 모델을 쓰느냐"부터 묻게 됩니다. 하지만 SWE-bench 리더보드를 조금만 주의 깊게 살펴보면, 같은 기반 모델(base model)을 사용하면서도 에이전트 시스템에 따라 상당한 성능 격차가 발생하는 사례를 어렵지 않게 발견할 수 있습니다. 동일한 모델인데 결과가 크게 달라진다면, 그 차이는 어디에서 오는 걸까요? 핵심은 하니스(Harness), 즉 모델이 코드를 읽고, 수정하고, 실행 결과를 받아보는 도구 인터페이스(tool interface) 설계에 있습니다. 구체적으로 분해하면 다음 요소들이 실질적 병목으로 작용합니다. ...