챗봇 하나 만들 때는 프롬프트만 잘 쓰면 됐다. 하지만 에이전트는 다르다. 에이전트는 수십 번의 추론 턴을 반복하고, 도구를 호출하고, 외부 데이터를 끌어오면서 컨텍스트가 끝없이 부풀어 오른다. 어느 순간 모델은 사용자가 3번째 메시지에서 한 지시를 잊어버리고, 비용은 턴당 $0.50씩 치솟고, 응답 품질은 급락한다.
Anthropic은 2025년 9월 “Effective context engineering for AI agents”라는 글에서 이 문제에 정면으로 접근했다. 핵심 메시지는 간단하다: 프롬프트 엔지니어링의 시대는 지났고, 컨텍스트 엔지니어링의 시대가 왔다. 이 글에서는 그 의미를 풀고, 실전에서 즉시 써먹을 수 있는 구체적인 전략과 코드를 정리한다.
프롬프트 엔지니어링은 “어떤 단어와 문장을 쓰면 모델이 원하는 출력을 내는가”에 집중한다. 시스템 프롬프트를 다듬고, few-shot 예시를 넣고, temperature를 조정하는 것이 전부였다.
컨텍스트 엔지니어링은 한 차원 위의 질문을 던진다: “모델이 추론할 때 컨텍스트 윈도우 안에 어떤 정보 구성을 넣을 것인가?” 여기에는 시스템 프롬프트뿐 아니라 도구 정의, MCP 서버가 제공하는 외부 데이터, 이전 대화 이력, 검색 결과, 에이전트가 스스로 생성한 중간 결과물이 모두 포함된다.
결정적인 차이는 반복이다. 프롬프트 엔지니어링은 한 번 작성하면 끝나는 정적인 작업이지만, 컨텍스트 엔지니어링은 에이전트가 매 추론 턴마다 수행해야 하는 동적 최적화다. 에이전트 루프가 돌 때마다 새로운 정보가 쌓이고, 그중 무엇을 컨텍스트에 유지하고 무엇을 버릴지 결정해야 한다.
Anthropic이 지적한 핵심 개념은 컨텍스트 부패(context rot)다. 컨텍스트 윈도우가 길어질수록 모델의 정보 회상 능력이 저하되는 현상이다. needle-in-a-haystack 벤치마크에서 확인된 이 특성은 모든 모델에서 공통으로 나타난다.
원인은 트랜스포머 아키텍처 자체에 있다. 트랜스포머는 모든 토큰 쌍 사이의 어텐션을 계산하므로 n개 토큰에 대해 n²의 관계를 처리해야 한다. 컨텍스트가 길어지면 이 관계망이 희박해지고, 모델은 “중간에 있는” 정보를 놓치기 쉬워진다. 위치 인코딩 보간 기법으로 긴 시퀀스를 처리할 수는 있지만, 토큰 위치 이해도에는 저하가 생긴다.
실전에서는 세 가지 실패 모드가 반복해서 나타난다:
이건 환각이 아니다. 컨텍스트 관리 실패다. 토큰은 기술적으로 윈도우 안에 있지만, 모델의 어텐션이 닿지 않는 것이다.
가장 단순하고 예측 가능한 전략. 토큰 수가 임계치를 넘으면 가장 오래된 메시지부터 버린다.
def truncate_history(messages: list[dict], max_tokens: int, count_tokens) -> list[dict]:
system = [m for m in messages if m['role'] == 'system']
rest = [m for m in messages if m['role'] != 'system']
total = sum(count_tokens(m) for m in system)
kept = []
for msg in reversed(rest):
total += count_tokens(msg)
if total > max_tokens:
break
kept.append(msg)
return system + list(reversed(kept))
시스템 프롬프트는 항상 보존하고, 나머지는 최신 메시지부터 거꾸로 세어서 예산 안에 들어오는 만큼만 유지한다. “이 버그 수정하고 테스트 돌려” 같은 순차적 태스크에 적합하다. 한 번 해결된 이전 단계의 대화는 더 이상 필요 없기 때문이다.
한계: 버려진 정보는 영영 사라진다. 이전 맥락이 계속 중요한 대화에서는 위험하다.
주기적으로 이전 대화의 절반을 요약된 문단으로 교체한다. 정보의 핵심은 유지하면서 토큰을 크게 줄인다.
import anthropic
client = anthropic.Anthropic()
def summarize_history(messages: list[dict], keep_recent: int = 6) -> list[dict]:
system = [m for m in messages if m['role'] == 'system']
rest = [m for m in messages if m['role'] != 'system']
if len(rest) <= keep_recent:
return messages
to_summarize = rest[:-keep_recent]
recent = rest[-keep_recent:]
# 대화를 텍스트로 변환
conversation_text = "\n".join(
f"{m['role']}: {m['content']}" for m in to_summarize
)
summary_response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=500,
messages=[{
"role": "user",
"content": f"다음 대화의 핵심 결정, 사용자 요구사항, 이미 해결된 문제를 "
f"간결하게 요약하세요. 기술적 세부사항을 보존하세요:\n\n{conversation_text}"
}]
)
summary = summary_response.content[0].text
return system + [{
"role": "user",
"content": f"[이전 대화 요약]\n{summary}"
}, {
"role": "assistant",
"content": "이전 대화 내용을 숙지했습니다. 계속 진행하겠습니다."
}] + recent
LLM을 한 번 더 호출하는 비용이 발생하지만, 180K 토큰의 원본을 2K 토큰의 요약으로 압축하면 이후 매 턴마다 절약되는 비용이 훨씬 크다.
컨텍스트에 모든 것을 넣는 대신, 현재 질문에 관련 있는 정보만 검색해서 동적으로 주입한다.
from openai import OpenAI
import numpy as np
client = OpenAI()
class ContextRetriever:
def __init__(self, embedding_model="text-embedding-3-small"):
self.embedding_model = embedding_model
self.memory_store = [] # (embedding, text, metadata)
def store_message(self, text: str, metadata: dict):
embedding = client.embeddings.create(
input=text, model=self.embedding_model
).data[0].embedding
self.memory_store.append((np.array(embedding), text, metadata))
def retrieve_relevant(self, query: str, top_k: int = 5) -> list[str]:
query_emb = np.array(
client.embeddings.create(
input=query, model=self.embedding_model
).data[0].embedding
)
scores = []
for emb, text, meta in self.memory_store:
similarity = np.dot(query_emb, emb) / (
np.linalg.norm(query_emb) * np.linalg.norm(emb)
)
scores.append((similarity, text))
scores.sort(reverse=True)
return [text for _, text in scores[:top_k]]
이 패턴은 장기 세션에서 빛을 발한다. 사용자가 “아까 말한 그 데이터베이스 마이그레이션 이슈 어떻게 됐어?”라고 물으면, 임베딩 유사도로 해당 대화를 찾아 현재 컨텍스트에 삽입할 수 있다.
Anthropic이 권장하는 방식. 컨텍스트를 명확한 섹션으로 나누고, 각 섹션에 XML 태그나 마크다운 헤더를 사용해 모델이 구조를 인식하게 한다.
def build_structured_context(
system_prompt: str,
tools: list[dict],
recent_messages: list[dict],
retrieved_context: list[str],
agent_scratchpad: str
) -> list[dict]:
enriched_system = f"""{system_prompt}
<available_context>
<retrieved_documents>
{chr(10).join(f'<doc>{c}</doc>' for c in retrieved_context)}
</retrieved_documents>
<agent_working_notes>
{agent_scratchpad}
</agent_working_notes>
</available_context>"""
return [{"role": "system", "content": enriched_system}] + recent_messages
핵심은 최소 정보 원칙이다. 원하는 동작을 이끌어내는 데 필요한 최소한의 토큰 세트만 구성하는 것. Anthropic은 “최소가 반드시 짧다는 뜻은 아니다”라고 강조한다. 에이전트가 제대로 동작하려면 충분한 정보가 필요하지만, 그중 불필요한 것은 과감히 제거해야 한다.
단일 전략만으로는 부족하다. 실제 프로덕션 에이전트에서는 다음과 같이 계층적으로 조합한다:
┌─────────────────────────────────────┐
│ 시스템 프롬프트 (항상 유지) │
├─────────────────────────────────────┤
│ 이전 대화 요약 (요약 전략) │
├─────────────────────────────────────┤
│ RAG 검색 결과 (선택적 검색) │
├─────────────────────────────────────┤
│ 최근 N턴 대화 (잘라내기 전략) │
├─────────────────────────────────────┤
│ 에이전트 작업 노트 (구조화) │
├─────────────────────────────────────┤
│ 도구 정의 및 MCP 컨텍스트 │
└─────────────────────────────────────┘
이 계층 구조에서 각 레이어는 독립적으로 관리된다. 요약은 주기적으로 갱신되고, RAG 결과는 매 질문마다 교체되며, 최근 대화는 토큰 예산에 맞게 잘라낸다.
과도한 압축은 독이다. 핵심 정보를 잃은 요약은 180K 토큰의 원본보다 더 위험하다. 모델이 잘못된 요약을 사실로 받아들이면, 차라리 아예 없는 편이 낫다.
검색 품질이 전체 품질을 결정한다. RAG 기반 선택 전략에서 임베딩 모델이 관련 문서를 찾지 못하면, 컨텍스트에는 쓸모없는 정보만 들어간다. 검색 성능을 지속적으로 모니터링해야 한다.
컨텍스트 격리를 잊지 마라. 멀티 에이전트 시스템에서 한 에이전트의 컨텍스트가 다른 에이전트에 간섭하면 예측 불가능한 동작이 발생한다. 각 에이전트의 컨텍스트는 독립적으로 관리되어야 한다.
AI 서비스를 운영하다 보면 어느 순간 API 비용이 폭발한다. 사용자는 느는데 비용은 더 빨리 늘고, 레이턴시도 점점 길어진다. 원인의 상당 부분은 같은 질문을 반복해서 LLM에 보내고 있다는 데 있다.
업계 사례를 종합하면, 고객 지원 챗봇에서 25~45%의 쿼리가 의미상(semantically) 중복이다. “프랑스 수도가 뭐야?”와 “프랑스의 수도는?”은 다른 문자열이지만 같은 질문이다. 이걸 캐싱하면 비용을 20~60% 줄일 수 있다.
먼저 헷갈리기 쉬운 두 가지를 구분하자.
프로바이더 프롬프트 캐싱은 OpenAI, Anthropic이 제공하는 기능이다. 시스템 프롬프트처럼 긴 접두사가 반복될 때, 입력 토큰을 캐시해서 재처리하지 않는다. Anthropic은 90% 할인, OpenAI는 50% 할인을 적용한다.
# Anthropic 프롬프트 캐싱 예시
import anthropic
client = anthropic.Anthropic()
SYSTEM_PROMPT = """
당신은 계약서 검토 전문가입니다.
다음 지침에 따라 분석하세요... (3000+ 토큰의 상세 지침)
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2000,
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}
}],
messages=[{"role": "user", "content": "이 계약서를 분석해줘: ..."}]
)
# 첫 요청: 전체 입력 토큰 과금
# 이후 요청: 캐시된 프롬프트 부분 90% 할인
시맨틱 캐싱은 애플리케이션 레벨에서 동작한다. 사용자 질문을 임베딩으로 변환하고, 벡터 유사도가 임계값 이상인 기존 응답을 반환한다. 질문의 의미가 같으면 캐시 히트다.
둘은 상호 보완적이다. 시스템 프롬프트는 프로바이더 캐싱으로, 사용자 질문은 시맨틱 캐싱으로 처리하면 된다.
사용자 질문 → 임베딩 모델 → 벡터 변환
↓
벡터 DB에서 유사도 검색
↓
유사도 ≥ 임계값 → 캐시된 응답 반환 (25~60ms)
유사도 < 임계값 → LLM 호출 후 캐시에 저장 (500~3000ms)
핵심은 임계값 설정이다. 너무 낮으면 관련 없는 질문이 같은 응답을 받고, 너무 높으면 캐시 히트율이 떨어진다. 실전에서는 0.85~0.92 사이가 적당하다.
가장 빠르게 도입할 수 있는 오픈소스 라이브러리는 GPTCache다.
from gptcache import Cache
from gptcache.adapter import openai
from gptcache.embedding import OpenAI as EmbedOpenAI
from gptcache.similarity_evaluation import Cosine
from gptcache.manager import manager_factory
# 캐시 초기화
cache = Cache()
cache.init(
pre_embedding_func=lambda x: x, # 질문 전처리
embedding_func=EmbedOpenAI(), # 임베딩 모델
data_manager=manager_factory("sqlite,faiss",
data_dir="./cache_data"),
similarity_evaluation=Cosine(),
config={"similarity_threshold": 0.85}
)
# OpenAI 호출 대신 캐시 래퍼 사용
response = openai.ChatCompletion.create(
model="gpt-4o",
messages=[{"role": "user", "content": "환불 규정이 어떻게 되나요?"}],
cache_obj=cache # 이 한 줄로 캐싱 활성화
)
# 첫 호출: LLM API 호출 (정상 과금)
# "환불 정책 알려주세요" 같은 유사 질문: 캐시 히트 (API 비용 0원)
GPTCache보다 더 세밀한 제어가 필요하면 Redis + 임베딩을 직접 조합한다.
import redis
import numpy as np
import json, hashlib, time
from openai import OpenAI
r = redis.Redis(host="localhost", port=6379, decode_responses=True)
client = OpenAI()
SIMILARITY_THRESHOLD = 0.88
def get_embedding(text: str) -> list[float]:
resp = client.embeddings.create(
model="text-embedding-3-small",
input=text
)
return resp.data[0].embedding
def cosine_similarity(a: list[float], b: list[float]) -> float:
a_np, b_np = np.array(a), np.array(b)
return np.dot(a_np, b_np) / (np.linalg.norm(a_np) * np.linalg.norm(b_np))
def cached_chat(user_query: str) -> str:
query_emb = get_embedding(user_query)
# Redis에서 모든 캐시 키 조회 (실제로는 HNSW 인덱스 권장)
for key in r.scan_iter("cache:*"):
stored_emb = json.loads(r.hget(key, "embedding"))
sim = cosine_similarity(query_emb, stored_emb)
if sim >= SIMILARITY_THRESHOLD:
# 캐시 히트 — 히트 카운트 증가
r.hincrby(key, "hits", 1)
return r.hget(key, "response")
# 캐시 미스 — LLM 호출
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": user_query}]
).choices[0].message.content
# 캐시에 저장
cache_id = hashlib.md5(user_query.encode()).hexdigest()[:12]
r.hset(f"cache:{cache_id}", mapping={
"query": user_query,
"embedding": json.dumps(query_emb),
"response": response,
"hits": 0,
"created": str(int(time.time()))
})
return response
Redis Stack을 쓰면 FT.SEARCH로 HNSW 벡터 인덱스를 만들어 O(log n)으로 유사도 검색이 가능하다. 캐시가 수만 개 이상이면 필수다.
| 유스케이스 | 히트율 | 비용 절감 | 참고 |
|---|---|---|---|
| 고객 지원 챗봇 | 35~45% | 30~50% | 자주 묻는 질문 패턴이 뚜렷함 |
| 제품 FAQ | 40~55% | 35~60% | 질문 범위가 좁아 히트율 최고 |
| 코드 어시스턴트 | 15~25% | 10~20% | 질문이 다양하지만 일부 반복 존재 |
| 창의적 글쓰기 | 5~15% | 3~10% | 거의 매번 다른 질문 |
100K 쿼리/월 Claude Sonnet 기준 계산:
임계값은 서비스마다 다르다. 실전에서는 이렇게 접근한다:
# 도메인별 임계값 설정 예
THRESHOLDS = {
"faq": 0.85, # 단답형, 높은 허용
"support": 0.88, # 일반 지원
"billing": 0.92, # 결제 관련은 엄격
"legal": 0.95 # 법률 자문은 거의 캐싱 안 함
}
1. TTL 없이 캐시 무한 누적 시간이 지나면 정보가 바뀐다. “오늘 날씨” 캐시를 영구 저장하면 안 된다. 유스케이스에 따라 1시간~7일 TTL을 설정하자.
2. 임베딩 모델과 LLM을 다르게 쓸 때 차이 무시
임베딩 모델이 한국어에 약하면 한국어 질문의 유사도 판별이 부정확해진다. 다국어 서비스라면 text-embedding-3-large나 Cohere의 multilingual 모델을 쓰자.
3. 캐시 히트율만 보고 판단하기 히트율이 높아도 캐시된 응답이 틀리면 의미 없다. 정확도 메트릭을 병행 측정해야 한다. 샘플링해서 human evaluation을 주기적으로 수행하자.
시맨틱 캐싱은 AI API 비용 최적화에서 가장 과소평가된 기법이다. 구현 난이도에 비해 효과가 압도적이다.
핵심은 프로바이더 프롬프트 캐싱과 시맨틱 캐싱을 같이 쓰는 것이다. 시스템 프롬프트는 프로바이더가, 사용자 질문은 시맨틱 캐시가 잡는 구조를 만들면 비용을 50~70%까지 줄일 수 있다.
오늘 당장 해볼 것: 기존 API 호출 로그에서 중복 질문 비율을 확인해보자. 20%만 넘어도 시맨틱 캐싱 도입의 근거가 충분하다.
]]>프로덕션에 AI 에이전트를 배포한 경험이 있다면 이런 상황을 겪었을 것이다. 사용자가 “회의 요약해 줘”라고 했는데, 에이전트가 아주 그럴듯한 문장으로 답했다. 그런데 자세히 보니 회의에 없었던 사람 이름이 들어 있고, 결정된 적 없는 사항이 포함되어 있으며, 날짜까지 틀렸다. 겉보기엔 완벽해 보이지만 전부 거짓이다.
로그를 확인해 보니 프롬프트도 있고 최종 응답도 있다. 하지만 그 사이에 일어난 16번의 도구 호출, 3번의 재시도, 더 싼 모델로의 자동 폴백, 컨텍스트가 잘린 지점 두 곳은 어디에도 기록되어 있지 않다. 버그는 프롬프트에 있지 않았다. 에이전트가 거치는 중간 단계들을 관찰할 수 없었던 게 진짜 문제였다.
이 글에서는 AI 에이전트의 옵저버빌리티를 구축하는 실전 방법을 다룬다. Langfuse, OpenTelemetry, 그리고 이 둘을 연결하는 구체적인 코드까지 함께 살펴보자.
전통적인 웹 서비스는 요청이 들어오면 정해진 코드 경로를 따라 응답이 나간다. 입력과 출력이 1:1로 매핑되고, 예외가 발생하면 스택 트레이스가 알려준다. 하지만 AI 에이전트는 다르다.
에이전트 하나의 요청 안에는 LLM 호출, 도구 사용, 조건 분기, 상태 전이, 메모리 읽기/쓰기가 뒤섞인다. 같은 질문을 넣어도 매번 다른 경로를 탈 수 있다. 이런 비결정적 시스템에서는 “어떤 경로를 거쳤는지”를 아는 게 “결과가 뭐였는지” 아는 것만큼 중요하다.
에이전트 옵저버빌리티가 해결하려는 문제는 다음과 같다:
옵저버빌리티를 구축하려면 먼저 데이터 모델을 이해해야 한다. OpenTelemetry의 개념을 LLM 세계에 맞게 변형한 구조다.
트레이스(Trace): 사용자의 하나의 요청에서 시작된 전체 실행 흐름. 하나의 트레이스 안에는 여러 개의 스팬이 포함된다.
스팬(Span): 트레이스 안의 개별 단계. LLM 호출 한 번, 도구 호출 한 번, 검색 한 번 각각이 스팬이 된다. 각 스팬에는 입력, 출력, 소요 시간, 메타데이터가 기록된다.
세션(Session): 여러 트레이스를 묶는 단위. 대화형 에이전트라면 하나의 대화 세션이 여러 턴(각 턴이 하나의 트레이스)으로 구성된다.
이 구조를 시각화하면 다음과 같다:
Session: 사용자 대화 #42
├── Trace: 턴 1 "회의 요약해 줘"
│ ├── Span: LLM 호출 (GPT-4o)
│ ├── Span: 도구 호출 - calendar_lookup
│ ├── Span: 도구 호출 - document_search
│ └── Span: LLM 호출 (최종 응답 생성)
├── Trace: 턴 2 "거기서 누가 발표했어?"
│ ├── Span: LLM 호출
│ ├── Span: 도구 호출 - context_lookup
│ └── Span: LLM 호출
Langfuse는 LLM 애플리케이션을 위한 오픈소스 옵저버빌리티 플랫폼이다. 트레이싱, 평가(Evaluation), 프롬프트 관리, 비용 추적을 한 곳에서 제공한다. 직접 호스팅할 수도 있고 클라우드 버전을 쓸 수도 있다.
# pip install langfuse
from langfuse import Langfuse
langfuse = Langfuse(
public_key="pk-...",
secret_key="sk-...",
host="https://cloud.langfuse.com" # 또는 자체 호스팅 URL
)
간단한 RAG 에이전트를 예로 들어 보자. 사용자 질문이 들어오면 검색하고, 컨텍스트와 함께 LLM을 호출하는 흐름이다.
from langfuse.decorators import observe, langfuse_context
@observe(as_type="generation")
def call_llm(prompt: str, model: str = "gpt-4o") -> str:
"""LLM 호출을 추적하는 래퍼 함수"""
# Langfuse가 자동으로 입력/출력/토큰/비용을 기록
response = openai_client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
)
return response.choices[0].message.content
@observe(as_type="span")
def search_documents(query: str, top_k: int = 5) -> list[dict]:
"""문서 검색 스팬"""
# 검색 결과를 스팬의 출력으로 기록
results = vector_store.similarity_search(query, k=top_k)
return [{"content": r.page_content, "score": r.score} for r in results]
@observe(as_type="trace")
def answer_question(user_question: str) -> str:
"""전체 에이전트 실행을 하나의 트레이스로 추적"""
# 1단계: 검색
docs = search_documents(user_question)
# 2단계: 컨텍스트 구성
context = "\n".join([d["content"] for d in docs])
prompt = f"""다음 문서를 참고해서 질문에 답해라.
문서:
{context}
질문: {user_question}"""
# 3단계: LLM 호출
answer = call_llm(prompt)
# 커스텀 메타데이터 추가
langfuse_context.update_current_trace(
metadata={
"user_question": user_question,
"retrieved_doc_count": len(docs),
"top_score": docs[0]["score"] if docs else 0,
}
)
return answer
@observe 데코레이터만으로 각 함수의 입력, 출력, 실행 시간이 자동으로 기록된다. Langfuse 대시보드에서 트리 형태로 각 단계를 시각적으로 확인할 수 있다.
LLM 호출 시 토큰 사용량을 명시적으로 기록하면 모델별 비용 추적이 가능하다:
@observe(as_type="generation")
def call_llm_with_cost(prompt: str, model: str = "gpt-4o") -> str:
response = openai_client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
)
# 토큰 사용량을 Langfuse에 기록
langfuse_context.update_current_observation(
model=model,
usage={
"input": response.usage.prompt_tokens,
"output": response.usage.completion_tokens,
"total": response.usage.total_tokens,
},
)
return response.choices[0].message.content
Langfuse SDK만으로도 충분하지만, 이미 OpenTelemetry를 사용 중인 인프라라면 OTLP(OpenTelemetry Protocol)를 통해 Langfuse로 트레이스를 직접 보낼 수 있다. Langfuse는 OTLP 백엔드로 동작한다.
OpenTelemetry의 GenAI 시맨틱 컨벤션(Semantic Conventions)은 LLM 호출을 표준화된 속성으로 기록하는 방법을 정의한다. 이 컨벤션에 따르면 LLM 스팬은 다음 속성을 포함한다:
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# Langfuse를 OTLP 백엔드로 설정
otlp_exporter = OTLPSpanExporter(
endpoint="https://cloud.langfuse.com/api/public/otel",
headers={
"Authorization": "Basic <base64(pk:sk)>",
},
)
provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(otlp_exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("my-agent")
from opentelemetry.semconv.attributes.error_attributes import ERROR_TYPE
TRACER = trace.get_tracer("agent-service")
def trace_llm_call(prompt: str, model: str, system_prompt: str = ""):
with TRACER.start_as_current_span("gen_ai.chat.completion") as span:
# GenAI 시맨틱 컨벤션 속성 설정
span.set_attribute("gen_ai.system", "openai")
span.set_attribute("gen_ai.request.model", model)
span.set_attribute("gen_ai.request.max_tokens", 4096)
span.set_attribute("gen_ai.prompt", prompt[:1000]) # 토큰 제한
try:
response = openai_client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": prompt},
],
)
# 응답 메타데이터 기록
span.set_attribute("gen_ai.response.finish_reason",
response.choices[0].finish_reason)
span.set_attribute("gen_ai.usage.input_tokens",
response.usage.prompt_tokens)
span.set_attribute("gen_ai.usage.output_tokens",
response.usage.completion_tokens)
return response.choices[0].message.content
except Exception as e:
span.set_attribute(ERROR_TYPE, type(e).__name__)
span.set_status(trace.StatusCode.ERROR, str(e))
raise
이렇게 하면 기존 인프라의 앱 성능 모니터링(APM)과 LLM 호출 트레이스를 하나의 대시보드에서 볼 수 있다. 데이터베이스 쿼리, API 호출, LLM 호출이 하나의 트레이스 안에 연결되어 전체 요청 흐름을 파악할 수 있다.
에이전트가 프로덕션에서 초당 수십~수백 건의 요청을 처리하면 트레이스 데이터가 급격히 늘어난다. Langfuse 클라우드 플랜의 경우 스토리지 비용도 문제지만, 더 큰 문제는 수천 개의 트레이스 속에서 의미 있는 것을 찾기 어려워진다는 점이다.
import random
TRACE_SAMPLE_RATE = 0.1 # 10%만 트레이싱
def should_trace() -> bool:
# 항상 트레이싱해야 하는 케이스
if is_high_value_user():
return True
if has_error_in_recent_calls():
return True
# 일반 요청은 샘플링
return random.random() < TRACE_SAMPLE_RATE
Langfuse에서는 트레이스에 스코어를 매길 수 있다. 낮은 스코어의 트레이스를 우선적으로 확인하는 방식으로 디버깅 효율을 높인다:
@observe(as_type="trace")
def answer_question_scored(user_question: str) -> str:
answer = answer_question(user_question)
# 응답 품질 자동 평가
score = evaluate_answer_quality(user_question, answer)
langfuse_context.update_current_trace(
scores={"answer_quality": score}
)
# 낮은 스코어만 알림
if score < 0.5:
send_alert(f"Low quality answer detected: score={score}")
return answer
옵저버빌리티의 궁극적 목표는 관찰 그 자체가 아니라 개선이다. 프로덕션 트레이스를 기반으로 평가 데이터셋을 구축하고, 에이전트 성능을 지속적으로 측정하는 파이프라인이 필요하다.
Langfuse 대시보드에서 좋은 트레이스와 나쁜 트레이스를 직접 골라 데이터셋을 만들 수 있다. API로도 가능하다:
from langfuse import Langfuse
langfuse = Langfuse()
# 낮은 스코어의 트레이스 수집
low_score_traces = langfuse.get_traces(
tags=["production"],
score_threshold=0.3,
limit=50,
)
# 데이터셋 생성
dataset = langfuse.create_dataset(
name="rag-agent-regression-v2",
description="낮은 품질의 프로덕션 응답 기반 회귀 테스트"
)
for trace in low_score_traces:
input_msg = trace.input
expected = trace.output # 정답은 직접 수정 가능
langfuse.create_dataset_item(
dataset_name="rag-agent-regression-v2",
input=input_msg,
expected_output=expected,
)
@observe(as_type="trace")
def run_eval(dataset_name: str):
dataset = langfuse.get_dataset(dataset_name)
for item in dataset.items:
# 에이전트 실행
actual = answer_question(item.input)
# LLM-as-judge로 평가
eval_prompt = f"""다음 질문에 대한 두 답변을 비교해라.
질문: {item.input}
기대 답변: {item.expected_output}
실제 답변: {actual}
정확성, 완전성, 관련성을 각각 1~5점으로 평가하고 JSON으로 응답해라."""
eval_result = call_llm(eval_prompt)
scores = parse_eval_json(eval_result)
# Langfuse에 평가 결과 기록
langfuse_context.update_current_trace(
scores=scores
)
run_eval("rag-agent-regression-v2")
에이전트 옵저버빌리티 도구를 선택할 때 고려할 점을 정리했다.
| 기준 | Langfuse | LangSmith | 자체 구축 (OTel + Grafana) |
|---|---|---|---|
| 오픈소스 | ✅ 오픈소스 (Apache 2.0) | ❌ 독점 | ✅ |
| 자체 호스팅 | ✅ Docker로 간단 | ❌ 클라우드만 | ✅ |
| OTel 통합 | ✅ OTLP 백엔드 | ❌ 자체 포맷 | ✅ 네이티브 |
| 프롬프트 관리 | ✅ | ✅ | ❌ 별도 도구 |
| 평가 파이프레인 | ✅ 내장 | ✅ 내장 | ❌ 직접 구현 |
| LangChain 통합 | ✅ | ✅ (1차 파티) | ⚠️ 수동 |
| 비용 | 무료(자체) / 종량제 | 종량제 | 인프라 비용만 |
빠르게 시작하려면 Langfuse가 가장 무난하다. 이미 Grafana/Prometheus 스택을 쓰고 있다면 OTel 트레이스를 기존 인프라로 보내는 것도 좋은 선택이다.
1. 로그와 트레이스를 혼동하기: print()나 logging으로 남기는 로그는 트레이스가 아니다. 트레이스는 구조화된 데이터로, 각 스팬의 관계(부모-자식)가 명확해야 한다.
2. 프롬프트 전체를 기록하기: 프롬프트에 사용자 개인정보가 포함될 수 있다. PII 마스킹을 적용하거나, 최소한 프롬프트의 앞부분만 기록하는 전략이 필요하다:
def sanitize_for_logging(text: str, max_len: int = 500) -> str:
"""PII를 마스킹하고 길이를 제한하는 유틸리티"""
# 이메일, 전화번호 등 패턴 마스킹
text = re.sub(r'\b[\w.-]+@[\w.-]+\.\w+\b', '[EMAIL]', text)
text = re.sub(r'\b\d{3}[-.]?\d{3,4}[-.]?\d{4}\b', '[PHONE]', text)
return text[:max_len]
3. 모든 트레이스를 동등하게 취급하기: 에러가 발생한 트레이스, 높은 비용이 든 트레이스, 낮은 평가 점수의 트레이스를 우선적으로 분석해야 한다.
4. 개발 환경만 트레이싱하기: 가장 많이 배우는 건 프로덕션 트레이스다. 실 사용자 데이터를 기반으로 문제를 발견하고, 그 트레이스를 테스트 케이스로 변환하는 루프가 핵심이다.
AI 에이전트 옵저버빌리티는 단순히 “무슨 일이 일어났는지”를 아는 것으로 끝나지 않는다. 진짜 가치는 관찰 → 분석 → 평가 → 개선의 사이클을 만드는 데 있다.
핵심 요약:
@observe 데코레이터 몇 줄로 트레이싱, 비용 추적, 평가를 한 번에 구축할 수 있다당장 해볼 수 있는 첫 단계: 기존 에이전트 코드에 Langfuse SDK를 추가하고 @observe 데코레이터를 메인 함수에 붙여 보라. 그 다음 요청 하나를 실행하고 Langfuse 대시보드를 열면, 에이전트가 실제로 무슨 일을 하고 있었는지 처음으로 명확하게 보게 될 것이다.
RAG(Retrieval-Augmented Generation)는 2026년 현재 프라이빗 데이터를 다루는 AI 애플리케이션의 표준 아키텍처가 됐다. 파인튜닝과 달리 데이터가 바뀌어도 즉시 반영되고, 비용도 훨씬 낮다.
하지만 대부분의 RAG 튜토리얼이 보여주는 “임베딩 → 벡터 DB 저장 → top-k 검색 → LLM 생성” 파이프라인은 프로덕션에서 한계에 부딪힌다. 업계 분석에 따르면 RAG가 실패하는 원인의 약 73%가 검색 단계에 있으며, 순수 벡터 검색 기반 파이프라인은 전체 쿼리의 약 40%에서 관련 없는 문서를 검색한다. LLM은 잘못된 컨텍스트 위에 자신감 넘치는 답변을 생성한다.
이 글에서는 검색 품질을 근본적으로 끌어올리는 세 가지 핵심 전략을 다룬다: 하이브리드 서치(BM25 + 벡터 검색 결합), 리랭킹 모델 도입, 그리고 이를 실제로 구현할 때의 벡터 데이터베이스 선택 기준이다.
벡터 검색은 의미적 유사성을 잘 포착하지만 세 가지 근본적 약점이 있다.
첫째, 어휘 불일치(lexical gap) 문제다. 사용자가 “구독 취소하는 방법”이라고 물었을 때, 문서의 제목이 “계정 해지 정책”이라면 임베딩 벡터 간 거리가 가깝더라도 완벽한 매칭이 어려울 수 있다. 특히 고유명사, 제품명, 에러 코드 같은 정확한 문자열 매칭이 필요한 경우 벡터 검색은 신뢰할 수 없다.
둘째, 컨텍스트 윈도우 오염이다. top-10을 검색했는데 그중 2개만 관련 있다면, 나머지 8개의 노이즈가 LLM의 답변 품질을 떨어뜨린다. LLM은 모든 컨텍스트를 평균적으로 반영하려는 경향이 있어, 관련 없는 문서가 섞이면 답변이 흐릿해진다.
셋째, 청킹 아티팩트다. 고정 크기로 문서를 자르면 문장 중간, 표 중간, 코드 중간이 끊긴다. 기술적으로 관련성 점수는 높지만 실제로는 쓸모없는 청크가 검색되는 현상이 발생한다.
하이브리드 서치는 키워드 기반 검색(BM25)과 시맨틱 벡터 검색의 결과를 결합하는 방식이다. 두 방식은 서로 다른 종류의 관련성을 포착하므로, 합치면 양쪽의 약점을 상호 보완한다.
PostgreSQL은 pgvector와 전문검색(ts_vector)을 같은 쿼리에서 결합할 수 있다. 별도 서비스를 추가할 필요가 없다.
-- 하이브리드 서치: 벡터 유사도 + 전문검색 결합
WITH vector_results AS (
SELECT
id,
content,
metadata,
1 - (embedding <=> $1::vector) AS vector_score
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 50
),
bm25_results AS (
SELECT
id,
content,
metadata,
ts_rank_cd(
textsearchable_index_col,
plainto_tsquery('korean', $2)
) AS bm25_score
FROM documents
WHERE textsearchable_index_col @@ plainto_ts_query('korean', $2)
LIMIT 50
)
SELECT
COALESCE(v.id, b.id) AS id,
COALESCE(v.content, b.content) AS content,
COALESCE(v.metadata, b.metadata) AS metadata,
-- 정규화된 점수 결합 (가중치 조정 가능)
(COALESCE(v.vector_score, 0) * 0.6) +
(COALESCE(
b.bm25_score / NULLIF(MAX(b.bm25_score) OVER (), 0),
0
) * 0.4) AS combined_score
FROM vector_results v
FULL OUTER JOIN bm25_results b ON v.id = b.id
ORDER BY combined_score DESC
LIMIT 10;
포인트는 두 가지다. (1) 각 검색 방식에서 충분히 많은 후보(50개)를 가져온 뒤 결합한다. (2) 결합 점수의 가중치(여기서 0.6:0.4)는 데이터셋에 따라 튜닝해야 한다. 키워드 매칭이 중요한 도메인(법률, 의료)에서는 BM25 비중을 높이고, 자연어 질의가 주된 도메인(고객 지원)에서는 벡터 비중을 높인다.
Qdrant는 페이로드 필터링에 최적화된 구조를 제공한다. 필터링 비율이 높은 워크로드(예: 멀티테넌트 환경에서 특정 조직의 데이터만 검색)에서 유리하다.
from qdrant_client import QdrantClient
from qdrant_client.models import (
SearchRequest, FusionQuery, Prefetch, Filter, FieldCondition
)
client = QdrantClient(host="localhost", port=6333)
# 하이브리드 서치: dense + sparse 벡터 결합
results = client.query_points(
collection_name="documents",
prefetch=[
# 시맨틱 검색 (dense vector)
Prefetch(
query=dense_embedding, # 1536차원 임베딩
using="dense",
limit=50,
),
# 키워드 검색 (sparse vector - SPLADE/BM25)
Prefetch(
query=sparse_embedding, # 희소 벡터
using="sparse",
limit=50,
),
],
# RRF (Reciprocal Rank Fusion)로 결과 결합
query=FusionQuery(fusion="rrf"),
limit=10,
)
Qdrant는 네이티브로 sparse vector를 지원하며, RRF(Reciprocal Rank Fusion) 알고리즘을 내장하고 있어 별도 정규화 로직이 필요 없다.
하이브리드 서치로 후보를 넓혔으면, 이중에서 진짜 관련 있는 것만 골라내야 한다. 이게 리랭킹의 역할이다.
리랭킹 모델은 검색 쿼리와 각 후보 문서의 쌍을 직접 비교(cross-encoder 방식)하여 정밀한 관련성 점수를 매긴다. bi-encoder(임베딩 검색)가 쿼리와 문서를 독립적으로 벡터화하는 것과 달리, cross-encoder는 둘을 함께 처리하므로 더 정확하지만 더 느리다. 그래서 1차 검색 후 상위 N개에만 적용하는 구조가 효율적이다.
import cohere
co = cohere.Client("your-api-key")
# 하이브리드 서치로 검색된 후보 문서들
candidate_docs = [
"계정 해지는 설정 > 구독 관리에서 진행할 수 있습니다...",
"환불 정책은 결제일로부터 14일 이내에 적용됩니다...",
# ... 총 20~30개 후보
]
response = co.rerank(
model="rerank-v3.5",
query="구독 취소하는 방법 알려줘",
documents=candidate_docs,
top_n=5, # 최종적으로 5개만 선택
)
for result in response.results:
print(f"순위 {result.index}: "
f"점수 {result.relevance_score:.3f} - "
f"{candidate_docs[result.index][:80]}...")
API 비용이 부담되거나 프라이빗 환경이 필요하다면 로컬 모델을 쓴다.
from FlagEmbedding import FlagReranker
reranker = FlagReranker(
'BAAI/bge-reranker-v2-m3',
use_fp16=True # GPU 메모리 절약
)
pairs = [
["구독 취소하는 방법", doc] for doc in candidate_docs
]
scores = reranker.compute_score(pairs)
# 점수 기준 정렬 후 상위 5개 선택
ranked = sorted(
zip(scores, candidate_docs),
key=lambda x: x[0],
reverse=True
)[:5]
bge-reranker-v2-m3는 다국어를 지원하며, 한국어 RAG 파이프라인에서도 안정적인 성능을 보여준다. GPU 한 장(T4 이상)에서 초당 수십 건의 리랭킹이 가능하다.
하이브리드 서치와 리랭킹을 도입하려면 벡터 DB 선택이 중요하다. 2026년 기준 실전적인 선택 기준을 정리한다.
-- pgvector 기본 설정: HNSW 인덱스 (정확도 중심)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
metadata JSONB,
embedding vector(1536)
);
-- HNSW 인덱스 생성 (ef_construction과 m이 핵심 파라미터)
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);
-- 검색 시 ef_search로 정확도-속도 트레이드오프 조정
SET hnsw.ef_search = 100;
HNSW 인덱스의 m 값은 그래프의 연결성을, ef_construction은 빌드 시 탐색 폭을 결정한다. 일반적으로 m=16~32, ef_construction=128~256이 좋은 시작점이다. 검색 시 ef_search를 높이면 정확도가 올라가지만 속도가 느려진다.
from qdrant_client import QdrantClient
from qdrant_client.models import (
Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue
)
client = QdrantClient(host="localhost", port=6333)
# 컬렉션 생성
client.create_collection(
collection_name="documents",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
# 페이로드 인덱스 생성 (필터링 성능 핵심)
client.create_payload_index(
collection_name="documents",
field_name="metadata.org_id",
field_schema="keyword",
)
# 필터링 검색 예시
results = client.search(
collection_name="documents",
query_vector=embedding,
query_filter=Filter(
must=[
FieldCondition(
key="metadata.org_id",
match=MatchValue(value="org_123"),
)
]
),
limit=10,
)
Qdrant에서 페이로드 인덱스를 만들면 필터링이 포함된 쿼리 성능이 크게 향상된다. pgvector에서는 메타데이터 필터링이 벡터 인덱스와 독립적으로 동작해 규모가 커지면 병목이 된다.
처음부터 Qdrant를 도입할 필요는 없다. 실제 추천하는 경로는:
위 내용을 종합하면 2026년 기준 프로덕션 RAG의 검색 레이어는 다음 구조가 된다.
사용자 쿼리
│
├── BM25 검색 (키워드 매칭) ──┐
│ │
└── 벡터 검색 (시맨틱 매칭) ──┤
│
RRF로 결과 결합 ────┤
│
상위 30~50개 후보 ──┤
│
리랭킹 모델 적용 ────┤
│
최종 top-5 컨텍스트 ──┘
│
LLM 생성 ─┘
이 구조에서 핵심은 각 단계가 독립적으로 튜닝 가능하다는 점이다. BM25 가중치, 벡터 모델 선택, 결합 비율, 리랭킹 임계값을 개별적으로 조정하면서 전체 파이프라인을 최적화할 수 있다.
ts_vector 컬럼을 추가하고 결합 쿼리를 작성한다. Qdrant라면 sparse vector를 추가하라. 대부분의 경우 이것만으로 검색 정확도가 체감된다.context_precision, context_recall 메트릭을 추적하면 개선 효과를 수치로 확인할 수 있다.RAG에서 생성 모델은 이미 충분히 좋다. 남은 병목은 검색이고, 하이브리드 서치와 리랭킹은 그 병목을 해결하는 가장 비용 효율적인 방법이다.
]]>ChatGPT, Claude, Gemini와 대화하다 보면 놀랍게도 AI가 당신을 꽤 잘 알고 있다. 직업, 취향, 최근 고민거리까지. 하지만 이 “기억”은 사실 납작한 텍스트 덩어리일 뿐이다. 같은 사실이 5번 반복되면 5개의 증거처럼 보이지만, 실제로는 동일한 정보의 재탕이다.
이 문제를 해결하려는 움직임이 2024~2026년 사이 폭발적으로 늘었다. LLM의 메모리를 구조화된 지식 그래프(Knowledge Graph)로 변환하는 것이다. 이 글에서는 현재 존재하는 주요 프로젝트, 논문, 그리고 온톨로지 구축 방법론을 체계적으로 정리한다.
대부분의 LLM 메모리 시스템은 키-값(key-value) 형태다. 예를 들어:
사용자 선호: Node.js가 편함
프로젝트 상태: 포시냥 부품 주문 완료
이 구조의 치명적 한계는 세 가지다:
이걸 해결하려면 메모리를 노드(사실)와 엣지(관계)로 구성된 그래프로 재구성해야 한다.
Mem0는 현재 생태계에서 가장 성숙한 AI 메모리 레이어다. ⭐54,800개의 스타가 말해주듯, 커뮤니티 지지가 압도적이다.
대화에서 자동으로 메모리를 추출·저장·검색하며, 최근 그래프 기반 메모리를 지원하기 시작했다. MCP(Model Context Protocol) 플러그인으로 Claude Desktop, Cursor 등에 바로 연결할 수 있다.
핵심 차별점: 범용성. 특정 도메인에 국한되지 않고 모든 AI 에이전트에 메모리 레이어를 제공한다.
GraphRAG는 마이크로소프트가 만든 그래프 기반 RAG 시스템으로 ⭐32,800개의 스타를 보유하고 있다.
비정형 텍스트에서 자동으로 엔티티와 관계를 추출해 지식 그래프를 구축한다. 커뮤니티 감지(Community Detection) 알고리즘으로 자동으로 주제별 클러스터를 형성하고, 글로벌/로컬 검색 모드를 제공한다. v3까지 발전했다.
한계: 개인 메모리보다는 문서 분석에 특화되어 있다.
Graphiti는 ⭐25,700스타로, 시간적(temporal) 지식 그래프 구축에 특화되어 있다. 에피소드(대화나 이벤트)에서 자동으로 엔티티와 관계를 추출하고, Neo4j에 저장한다.
가장 흥미로운 점은 에피소드 메모리 → 의미 메모리 변환이 자동으로 이루어진다는 것. “어제 대화에서 사용자가 이직을 고민한다”는 에피소드가 “사용자는 현재 경력 전환기를 맞이하고 있다”는 의미로 압축된다. 중복 제거와 병합도 자동 처리된다.
핵심 차별점: 시간 축. 정보가 언제 생성되고 언제 만료되는지 추적한다.
Letta는 ⭐22,400스타로, LLM이 스스로 메모리를 관리하는 혁신적 아키텍처를 제안한다.
컨텍스트 윈도우를 넘어서는 장기 메모리를 위해 코어 메모리 / 아카이브 메모리 / 리콜 메모리의 3계층 구조를 사용한다. 마치 운영체제의 RAM/디스크/캐시 계층과 유사하다.
핵심 차별점: LLM 스스로가 무엇을 기억하고 무엇을 잊을지 결정하는 자율 메모리 관리.
Cognee는 ⭐17,000스타로, 비정형 데이터를 지식 그래프로 변환하는 파이프라인을 단 6줄의 코드로 구현할 수 있다.
import cognee
await cognee.add("data://example.txt")
await cognee.cognify()
results = await cognee.search("QUERY", "GRAPH_COMPLETION")
Neo4j, 버터DB 등 다양한 그래프 스토어를 지원하고 MCP 서버도 포함되어 있다.
HippoRAG (⭐3,500, NeurIPS 2024)는 인간 해마의 장기 기억 메커니즘에서 영감을 받은 프레임워크다.
문서에서 지식 그래프를 지속적으로 구축하고, Personalized PageRank로 그래프를 검색한다. 다중 홉(multi-hop) 추론에 특히 강점이 있다. “A는 B를 알고, B는 C에서 일한다 → A와 C의 관계는?” 같은 질문에 기존 RAG보다 훨씬 정확하다.
HippoRAG 2에서는 개인화와 시간 정보가 추가되었다.
MCP Knowledge Graph (⭐848)는 외부 DB 없이 로컬 파일 기반으로 동작하는 경량 지식 그래프다. 엔티티-관계-관찰(observation)의 3층 구조를 사용한다.
Memento MCP (⭐418)는 Neo4j 기반 MCP 서버로, 시간적 엔티티(temporal entities)를 지원한다. Claude Desktop이나 Cursor에서 바로 사용할 수 있다.
여기까지는 “저장소”에 대한 이야기였다. 그렇다면 무엇을 어떻게 저장할지의 규칙, 즉 온톨로지(ontology)는 어떻게 만들까?
KNOW: A Real-World Ontology for Knowledge Capture with Large Language Models (2024)는 LLM이 개인 정보를 체계적으로 캡처하기 위해 설계된 온톨로지다.
사람, 장소, 이벤트, 조직 등 일상 지식을 모델링하며, 12개 프로그래밍 언어용 코드 생성 라이브러리를 제공한다. 개인 AI 어시스턴트용으로 설계되었다는 점이 핵심이다.
ndoli는 W3C 표준인 RDF, OWL, SHACL을 사용해 개인 지식 그래프를 구축하는 프로젝트다. schema.org 온톨로지를 기반으로 하며, Claude Code와 통합되어 작동한다.
automatic-KG-creation-with-LLM (⭐341)은 가장 인기 있는 자동 온톨로지 생성 프로젝트다. NER(개체명 인식) → 온톨로지 생성 → 지식 그래프 구축 → 평가의 전체 파이프라인을 제공한다.
논문 Automatic Ontology Construction Using LLMs as an External Layer of Memory, Verification, and Planning for Hybrid Intelligent Systems (2026)는 RDF/OWL 기반 지식 그래프 구축 자동화 파이프라인을 제안한다. NER → 관계 추출 → 정규화 → triple 생성 → SHACL/OWL 검증 → 지속적 업데이트의 완전한 파이프라인이다.
Generative Agents: Interactive Simulacra of Human Behavior — LLM 기반 에이전트가 인간 같은 행동을 시뮬레이션하는 이정표 논문. 관찰 → 반성 → 계획의 3단계 메모리 구조를 제안했다. 25개의 에이전트가 자율적으로 발렌타인데이 파티를 기획하는 실험은 유명하다.
MemGPT: Towards LLMs as Operating Systems — LLM을 운영체제처럼 다루는 혁신적 접근. 가상 컨텍스트 관리 기법으로 제한된 컨텍스트 윈도우를 극복한다. 현재 Letta 오픈소스 프로젝트로 발전했다.
The AI Hippocampus: How Far are We From Human Memory? — LLM 메모리 메커니즘의 가장 포괄적인 서베이. 암묵적 메모리 → 명시적 메모리 → 에이전트 메모리의 3분류 체계를 제안한다.
An Ecosystem for Personal Knowledge Graphs: A Survey and Research Roadmap — PKG 연구의 바이블. PKG의 정의, 구축 방법론, 응용 분야, 연구 로드맵을 체계적으로 정리했다.
GAAMA: Graph Augmented Associative Memory for Agents — Generative Agents의 메모리 스트림을 그래프 구조로 확장. 다중 세션 대화에서 영속적 장기 메모리를 유지한다.
A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty — “기억 주권(Mnemonic Sovereignty)”이라는 개념을 제안하며, 공격자가 에이전트의 메모리를 조작하는 시나리오를 분석한다. 63페이지 분량의 심층 연구.
전체 생태계를 놓고 보면, 각 프로젝트가 해결하려는 문제가 다르다:
이 중에서 개인 AI 비서에 가장 적합한 조합은:
이 네 가지를 결합하면, 기존 어느 단일 프로젝트보다 강력한 개인 메모리 시스템을 구축할 수 있다. W3C PROV-O 표준과 Toulmin 논증 모델을 결합하면, 모든 메모리에 출처(attribution), 근거(evidence), 파생(derivation)을 추적할 수 있다.
LLM 메모리를 단순한 텍스트에서 구조화된 그래프로 변환하는 기술은 2024~2026년 사이 급격히 성숙했다. Mem0, Graphiti, Letta 같은 프로젝트는 이미 프로덕션 수준이며, HippoRAG, KNOW 온톨로지 같은 연구成果는 학술적 기반을 제공한다.
다음 단계는 이것들을 실제로 통합하는 것이다. 오픈소스 조각들은 있지만, 이걸 end-to-end로 묶어 개인 AI 비서에 적용한 사례는 아직 드물다. 바로 여기가 기회다.
참고 링크 모음:
]]>서버에 AI 모델을 두고 API로 호출하는 것이 당연한 시대다. 하지만 매 요청마다 네트워크 왕복이 발생하고, API 비용은 누적되며, 민감한 데이터를 외부로 보내야 한다. 2026년 들어 이 패러다임에 균열이 생기고 있다. 브라우저 자체에서 AI 모델을 실행하는 기술이 프로덕션 수준에 도달했다.
핵심은 두 기술의 결합이다. WebAssembly(WASM) 가 이식성과 샌드박스 보안을 제공하고, WebGPU 가 GPU 연산을 브라우저로 가져온다. 이 글에서는 이 기술 스택이 2026년 어디까지 왔는지, 실제 어떻게 쓰는지를 코드와 함께 정리한다.
브라우저 기반 AI 추론이 의미 있는 상황은 구체적이다.
첫째, API 비용 문제. 이미지 분류, 텍스트 임베딩, 감정 분석 같은 경량 작업을 매번 클라우드 API로 처리하면 비용이 빠르게 누적된다. 이런 작업은 브라우저에서 로컬로 처리하면 서버 측 비용이 0원이 된다.
둘째, 지연 시간. 서버 왕복이 200ms 걸리는 작업을 로컬에서 50ms 이내에 끝낼 수 있다면, 사용자 경험이 근본적으로 달라진다. 실시간 인터랙션이 필요한 애플리케이션에서 이 차이는 결정적이다.
셋째, 데이터 프라이버시. 의료, 금융, 개인 문서 등 민감한 데이터를 외부 서버로 전송하지 않고 브라우저 내에서 처리할 수 있다. 규제가 엄격한 산업에서 특히 중요하다.
물론 제약도 있다. 브라우저 메모리는 보통 2~4GB로 제한되고, 모델 크기에 따라 초기 로딩 시간이 길어진다. GPT-4 급 대형 모델은 아직 브라우저에서 돌리기 어렵지만, 3B~7B 파라미터 모델은 충분히 현실적이다.
2026년 1월, WebGPU가 마지막 보루였던 Firefox와 Safari에서 지원을 활성화하면서 모든 주요 브라우저에서 사용 가능해졌다. Firefox 147이 1월 13일 WebGPU를 탑재했고, Safari는 iOS 26과 macOS Tahoe 26에서 기본 활성화되었다. Chrome과 Edge는 이미 2023년부터 지원했다. 전체 브라우저 커버리지는 약 70%에 달한다.
WebGPU가 WebGL과 근본적으로 다른 점은 GPU를 저수준에서 직접 제어할 수 있다는 것이다. WebGL이 고수준 상태 기계 API였다면, WebGPU는 비동기 멀티스레드 명령 버퍼를 통해 GPU 병렬 처리를 가능하게 한다. 컴퓨트 워크로드 기준으로 WebGL 대비 15~30배 성능 향상이 보고되었다.
Hugging Face의 Transformers.js는 2026년 2월 v4를 릴리스했다. 가장 큰 변화는 WebGPU 런타임을 C++로 완전히 재작성한 것이다. ONNX Runtime 팀과 협력해 약 200개 모델 아키텍처에서 테스트를 마쳤다.
성능 개선도 눈에 띈다. com.microsoft.MultiHeadAttention 오퍼레이터를 도입해 BERT 기반 임베딩 모델에서 약 4배 속도 향상을 달성했다. 또한 Node.js, Bun, Deno 같은 서버 사이드 런타임에서도 WebGPU 가속 모델을 실행할 수 있게 되었다. 브라우저와 서버에서 동일한 코드가 돌아가는 건 의미 있는 변화다.
현재 브라우저 AI 추론의 3대 프레임워크는 Transformers.js, ONNX Runtime Web, WebLLM이다. 각각의 특징과 실제 코드를 비교해본다.
Transformers.js는 Hugging Face 생태계와 직접 연동되어 수천 개의 사전 학습 모델을 브라우저에서 바로 사용할 수 있다.
npm install @huggingface/transformers
감정 분석 파이프라인 예시:
import { pipeline } from "@huggingface/transformers";
// 파이프라인 생성 (첫 실행 시 모델 다운로드, 이후 캐시)
const classifier = await pipeline("sentiment-analysis");
const result = await classifier("이 제품 정말 좋아요!");
console.log(result);
// [{ label: "POSITIVE", score: 0.9998 }]
텍스트 임베딩으로语义 검색 구현:
import { pipeline } from "@huggingface/transformers";
const embedder = await pipeline("feature-extraction",
"BAAI/bge-small-en-v1.5",
{ dtype: "fp32" }
);
const embeddings = await embedder("검색할 문장", {
pooling: "mean",
normalize: true,
});
// 384차원 벡터 반환 → 코사인 유사도로 문서 검색
v4에서는 모델 레지스트리(ModelRegistry)가 추가되어 모델 캐시와 버전 관리가 개선되었다. 환경 설정(Environment Settings)으로 백엔드(WASM 또는 WebGPU)를 명시적으로 선택할 수도 있다.
Microsoft의 ONNX Runtime Web은 ONNX 포맷 모델을 브라우저에서 실행한다. WASM 백엔드와 WebGPU 백엔드를 모두 지원하며, SIMD와 스레딩을 활용한 최적화가 잘 되어 있다.
<script src="https://cdn.jsdelivr.net/npm/onnxruntime-web/dist/ort.all.min.js"></script>
<script>
// WebGPU 백엔드 사용 설정
ort.env.wasm.numThreads = navigator.hardwareConcurrency || 4;
const session = await ort.InferenceSession.create(
"model.onnx",
{ executionProviders: ["webgpu", "wasm"] }
);
// 입력 텐서 생성
const inputTensor = new ort.Tensor("float32",
new Float32Array([/* 데이터 */]),
[1, 3, 224, 224]
);
const results = await session.run({ input: inputTensor });
console.log(results.output.data);
</script>
ONNX Runtime Web의 장점은 PyTorch, TensorFlow, scikit-learn 등 다양한 프레임워크에서 학습한 모델을 ONNX로 변환만 하면 바로 사용할 수 있다는 것이다. Transformers.js가 Hugging Face 생태계에 종속적인 것과 대비된다.
MLC AI의 WebLLM은 LLaMA, Mistral, Gemma, Phi, Qwen 같은 LLM을 브라우저에서 직접 실행한다. WebGPU를 활용해 네이티브 성능의 약 80%에 도달한다고 보고되었다.
import { CreateMLCEngine } from "@mlc-ai/web-llm";
// LLM 엔진 초기화 (모델 다운로드 포함)
const engine = await CreateMLCEngine("Llama-3.2-1B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
messages: [
{ role: "system", content: "한국어로 답변하세요." },
{ role: "user", content: "WebAssembly를 한 줄로 설명해줘." },
],
temperature: 0.7,
max_tokens: 256,
});
console.log(reply.choices[0].message.content);
WebLLM은 OpenAI 호환 API를 제공하는 것이 특징이다. 기존에 OpenAI API를 사용하던 코드에서 baseUrl만 WebLLM 엔드포인트로 바꾸면 로컬 추론으로 전환할 수 있다. 마이그레이션 비용이 거의 없다.
실제 프로덕션 환경에서 측정된 대략적인 성능 수치를 정리한다. (모델과 하드웨어에 따라 편차가 크므로 참고 수치로 활용할 것)
| 작업 | 모델 크기 | WASM + SIMD | WebGPU | 비고 |
|---|---|---|---|---|
| 감정 분석 | ~60MB | ~30ms | ~10ms | BERT-tiny 기준 |
| 텍스트 임베딩 | ~130MB | ~80ms | ~20ms | bge-small 기준 |
| 이미지 분류 | ~100MB | ~150ms | ~40ms | MobileNet-v3 기준 |
| 텍스트 생성 | ~1.5GB | ~15 tok/s | ~45 tok/s | Llama-3.2-1B q4 기준 |
| 텍스트 생성 | ~4GB | 불가능 | ~20 tok/s | Llama-3.2-3B q4 기준 |
프레임워크 선택 기준은 다음과 같다.
모델 로딩 시간. 브라우저에서 모델을 처음 다운로드할 때 시간이 걸린다. 1GB 모델은 빠른 네트워크에서도 5~10초가 소요된다. Cache API나 IndexedDB를 활용해 모델을 로컬에 캐시하는 것이 필수적이다.
// Transformers.js v4에서는 내부적으로 캐시를 관리하지만,
// 명시적 제어가 필요하면 환경 설정 활용
import { env } from "@huggingface/transformers";
env.allowLocalModels = false; // 로컬 파일 시스템 접근 비활성화
env.useBrowserCache = true; // 브라우저 캐시 사용 (기본값)
메모리 관리. 브라우저 탭 하나가 사용할 수 있는 메모리는 제한적이다. 모델을 여러 개 로드하면 탭이 크래시될 수 있다. 사용하지 않는 모델은 명시적으로 dispose해야 한다.
WebGPU 미지원 환경 폴백. WebGPU 커버리지가 70%라도 나머지 30% 사용자를 무시할 수는 없다. WASM 백엔드로 폴백하는 로직이 필요하다.
// WebGPU 지원 확인 후 백엔드 선택
const useWebGPU = typeof navigator !== "undefined" &&
!!navigator.gpu;
const session = await ort.InferenceSession.create("model.onnx", {
executionProviders: useWebGPU ? ["webgpu", "wasm"] : ["wasm"],
});
모바일 환경. 모바일 브라우저에서는 메모리와 GPU 성능이 더 제한적이다. 모바일 타겟이라면 1B 이하 모델과 양자화(q4, q8)를 적극 활용해야 한다.
WebGPU의 전 브라우저 지원, Transformers.js v4의 WebGPU 런타임 재작성, WebLLM의 실용적 성능 달성 — 이 세 가지가 2026년 상반기에 동시에 이루어졌다. 브라우저 AI 추론은 더 이상 실험 단계가 아니다.
당장 시도해볼 수 있는 첫 단계를 제안한다.
서버 없이, API 키 없이, 데이터가 외부로 나가지 않으면서도 실용적인 속도로 AI가 동작하는 시대가 열렸다. 한 번 직접 경험해보면 가능성이 보일 것이다.
]]>2026년 4월, 오픈소스 AI 모델의 지형이 완전히 바뀌었다. 1년 전만 해도 GPT-4나 Claude를 대체할 만한 오픈 모델을 찾기 어려웠지만, 지금은 DeepSeek V4, Llama 4, Qwen 3.5, Gemma 4, GLM-5.1이 각각 다른 영역에서 상용 모델을 압도하거나 필적하는 성능을 보여주고 있다.
문제는 “가장 좋은 모델”이 하나가 아니라는 점이다. 코딩에 강한 모델, 추론에 뛰어난 모델, 가볍게 로컬에서 돌릴 수 있는 모델, 초장문 컨텍스트가 필요한 작업에 적합한 모델이 각각 다르다. 이 글에서는 각 모델의 실제 벤치마크 수치, 아키텍처 특징, 자가 호스팅 요구사항, API 가격을 비교하고, 용도별로 어떤 모델을 선택해야 하는지 실용적인 가이드를 제공한다.
비교 대상은 현재 가장 활발하게 사용되는 5개 모델 패밀리다.
| 모델 | 개발사 | 총 파라미터 | 활성 파라미터 | 라이선스 | 컨텍스트 |
|---|---|---|---|---|---|
| DeepSeek V4-Pro | DeepSeek | ~1.6조 | ~49B | MIT | 1M |
| Llama 4 Maverick | Meta | 400B | 17B | Llama 4 커뮤니티 | 1M |
| Llama 4 Scout | Meta | 109B | 17B | Llama 4 커뮤니티 | 10M |
| Qwen 3.5 (397B) | Alibaba | 397B | 17B | Apache 2.0 | 128K |
| Gemma 4 (31B) | 31B | 31B (dense) | Apache 2.0 | 256K | |
| GLM-5.1 | Zhipu AI | 754B | ~45B | MIT | 200K |
여기서 주목할 점이 있다. 대부분의 모델이 Mixture-of-Experts(MoE) 아키텍처를 채택했다는 것. 총 파라미터는 수백억~조 단위지만, 실제로 각 토큰 처리에 활성화되는 파라미터는 17B~45B 수준이다. 이 덕분에 과거보다 훨씬 적은 GPU 메모리로 대형 모델을 실행할 수 있다.
예외는 Gemma 4 31B. 이 모델은 dense(밀집) 구조를 유지하면서도 31B 파라미터로 400B+ MoE 모델들과 경쟁하는 성능을 보여준다.
개발자에게 가장 중요한 지표는 코딩 능력이다. 실제 소프트웨어 엔지니어링 작업을 평가하는 SWE-bench Verified 기준으로 보자.
| 모델 | SWE-bench Verified | LiveCodeBench v6 | HumanEval |
|---|---|---|---|
| DeepSeek V4-Pro | 83.7%* | — | 90.0% |
| DeepSeek V4-Pro (독립검증) | 80.6% | 93.5% | — |
| GLM-5.1 | ~78% | — | — |
| Qwen 3.5 (35B-A3B) | 73.4% | 80.4% | — |
| Gemma 4 31B | 52.0% | 80.0% | — |
| Llama 4 Maverick | ~65% | — | 82.4% |
*DeepSeek 자체 발표 수치. 독립 검증에서는 80.6%로 측정됨.
코딩 분야에서 DeepSeek V4-Pro가 확실히 선두다. SWE-bench Verified에서 80.6~83.7%, HumanEval에서 90%를 기록했다. 특히 주목할 것은 LiveCodeBench v6에서 93.5%를 기록했다는 점인데, 이는 Claude Opus 4.6의 88.8%를 상회하는 수치다. 가격은 API 기준 입력 $1.74/M, 출력 $3.48/M으로, Claude Opus 4.6의 입력 $5/M, 출력 $25/M과 비교하면 약 3~7배 저렴하다.
GLM-5.1은 SWE-bench Pro(더 어려운 난이도)에서 58.4%를 기록하며 이 부문 최고 점수를 보여준다. 복잡한 멀티스텝 코딩 작업에 강점이 있다.
Gemma 4 31B는 SWE-bench에서 상대적으로 낮은 52%를 보이지만, 31B 파라미터 모델임을 감안하면 인상적이다. 경량 코딩 보조 도구로는 충분히 실용적이다.
코딩 외에 수학, 과학, 일반 지식 추론 능력도 중요하다.
| 모델 | GPQA Diamond | MMLU | AIME 2026 |
|---|---|---|---|
| DeepSeek V4-Pro | — | — | — |
| Gemma 4 31B | 84.3% | — | 89.2% |
| Llama 4 Maverick | — | 85.2% | — |
| Qwen 3.5 (397B) | — | — | — |
Gemma 4 31B가 AIME 2026(수학 경시대회)에서 89.2%를 기록하며 수학 추론에서 강력한 모습을 보인다. GPQA Diamond(대학원 수준 과학 문제)에서도 84.3%로 준수하다. 31B 모델이 이 정도 성능이라는 건 로컬 호스팅 관점에서 매우 매력적이다.
Llama 4 Maverick은 MMLU 85.2%로 일반 지식 분야에서 견고하다. 하지만 전문 추론 벤치마크에서는 DeepSeek V4나 GLM-5.1에 뒤처지는 경향이 있다.
직접 모델을 호스팅하려면 하드웨어가 핵심 제약이다. 양자화(Q4_K_M) 기준으로 정리했다.
| 모델 | Q4_K_M 크기 | 최소 RAM/VRAM | 추천 하드웨어 |
|---|---|---|---|
| Gemma 4 31B | ~18GB | 24GB VRAM | RTX 4090, Mac M2 Ultra |
| Qwen 3.5 (35B-A3B) | ~4GB | 8GB VRAM | RTX 4070, Mac M1 16GB |
| Llama 4 Scout | ~25GB | 32GB RAM | Mac M2 Max, 2×RTX 4070 |
| Llama 4 Maverick | ~60GB | 64GB+ RAM | 2×A100, Mac M2 Ultra |
| DeepSeek V4 | ~300GB+ | 멀티 GPU | 4~8×H100 클러스터 |
| GLM-5.1 | ~150GB+ | 멀티 GPU | 4×H100 클러스터 |
가장 실용적인 선택: Qwen 3.5 35B-A3B는 활성 파라미터가 3B에 불과해 RTX 4070이나 Mac M1 16GB에서도 실행 가능하다. 그러면서도 SWE-bench 73.4%, LiveCodeBench 80.4%를 기록하는 준수한 성능을 보여준다. 개인 개발자의 로컬 코딩 어시스턴트로는 최적의 선택이다.
Gemma 4 31B는 RTX 4090 한 장으로 실행 가능하면서 수학 추론 89.2%를 보여준다. 연구나 데이터 분석 작업에 활용하기 좋다.
DeepSeek V4나 GLM-5.1은 조직 단위에서 GPU 클러스터를 운영할 수 있어야 현실적이다.
# Qwen 3.5 — 가장 가벼운 옵션, 8GB VRAM에서도 가능
ollama pull qwen3:8b
ollama run qwen3:8b "파이썬으로 이진 탐색 트리를 구현해줘"
# Gemma 4 — 24GB VRAM 필요, 수학/추론에 강점
ollama pull gemma4:31b
ollama run gemma4:31b "n-queen 문제를 백트래킹으로 풀어줘"
# Llama 4 Scout — 10M 컨텍스트, 32GB RAM
ollama pull llama4-scout:q4_k_m
ollama run llama4-scout:q4_k_m "이 코드베이스 전체에서 아키텍처 문제를 찾아줘"
자가 호스팅은 하드웨어 비용과 관리 부담이 있으므로, 소규모 사용에는 API가 더 경제적일 수 있다.
| 모델 | API 제공자 | 입력 가격 | 출력 가격 | 참고 |
|---|---|---|---|---|
| DeepSeek V4-Flash | DeepSeek API | $0.14/M | $0.28/M | 최저가 |
| DeepSeek V4-Pro | DeepSeek API | $1.74/M | $3.48/M | 고품질 저가 |
| Llama 4 Maverick | Together AI | ~$0.10/M | ~$0.49/M | 오픈웨이트 경쟁 |
| Llama 4 Scout | Together AI | ~$0.10/M | ~$0.15/M | 가장 저렴 |
| GPT-5.4 | OpenAI | ~$2.50/M | ~$10.00/M | 참고용 |
| Claude Opus 4.6 | Anthropic | $5.00/M | $25.00/M | 참고용 |
DeepSeek V4-Flash는 입력 $0.14/M, 출력 $0.28/M로 압도적인 가격 경쟁력을 보여준다. Claude Opus 4.6($5/$25)과 비교하면 입력 기준 약 35배, 출력 기준 약 90배 저렴하다. 반복 프롬프트에 적용되는 캐시 적중 가격($0.028/M)을 활용하면 비용이 더욱 낮아진다. DeepSeek V4-Pro도 $1.74/$3.48로 Claude Opus 대비 약 3~7배 저렴하면서 코딩 벤치마크에서 동급 이상의 성능을 보여준다.
Llama 4 Scout는 Together AI 기준 $0.15/M로, 10M 컨텍스트를 제공하면서도 가장 저렴하다. 대규모 문서 분석 파이프라인에 적합하다.
import openai
# DeepSeek V4-Flash — 가장 저렴한 옵션
client = openai.OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{"role": "system", "content": "당신은 전문 Python 개발자입니다."},
{"role": "user", "content": "FastAPI로 JWT 인증 미들웨어를 구현해줘"}
],
temperature=0.3,
max_tokens=4000
)
print(response.choices[0].message.content)
# Llama 4 Scout — 10M 컨텍스트로 대규모 코드 분석
from openai import OpenAI
client = OpenAI(
api_key="your-together-api-key",
base_url="https://api.together.xyz"
)
# 전체 코드베이스를 컨텍스트에 넣고 질문
with open("entire_codebase.txt") as f:
codebase = f.read()
response = client.chat.completions.create(
model="meta-llama/Llama-4-Scout",
messages=[
{"role": "user", "content": f"다음 코드베이스를 분석하고 아키텍처 개선점을 제안해줘:\n\n{codebase}"}
],
max_tokens=4000
)
지금까지의 분석을 종합해 실제 용도별 추천을 정리한다.
1순위: DeepSeek V4-Flash → 2순위: Qwen 3.5 35B-A3B (로컬)
API로 쓸 때는 DeepSeek V4-Flash의 가격대 성능비가 압도적이다. 로컬에서 쓰고 싶다면 Qwen 3.5 35B-A3B가 일반 GPU에서도 돌아가면서 코딩 성능이 준수하다.
1순위: Gemma 4 31B → 2순위: DeepSeek V4-Pro
Gemma 4 31B는 AIME 2026 89.2%, GPQA Diamond 84.3%로 수학·과학 추론에서 특히 강하다. RTX 4090 한 장으로 실행 가능하다는 점도 연구자에게 매력적이다.
1순위: Llama 4 Scout (10M 컨텍스트)
10M 토큰 컨텍스트는 경쟁 모델의 10~100배에 해당한다. 전체 코드베이스나 수백 페이지의 문서를 한 번에 처리해야 할 때 유일한 선택지다.
1순위: GLM-5.1 → 2순위: DeepSeek V4-Pro
GLM-5.1은 600+ 반복 최적화 루프를 설계할 정도로 장기 에이전트 작업에 특화되어 있다. MIT 라이선스로 상업적 제한도 없다. DeepSeek V4-Pro도 Engram 조건부 메모리 모듈로 지속적 컨텍스트 유지에 강하다.
1순위: Gemma 4 E2B/E4B → 2순위: Qwen 3.5 소형 변종
Gemma 4 E2B는 Android AICore를 통해 스마트폰에서 직접 실행된다. 오프라인 환경이나 지연 시간이 민감한 애플리케이션에 적합하다.
1순위: DeepSeek V4-Flash
입력 $0.14/M, 출력 $0.28/M. 대량 배치 처리나 프로토타이핑에서 비용을 최소화해야 할 때 선택의 여지가 없다.
벤치마크 수치를 맹신하면 안 된다. 몇 가지 주의할 점이 있다.
벤치마크 과적합 의심: SWE-bench나 HumanEval 같은 공개 벤치마크는 모델 훈련 데이터에 포함되었을 가능성이 있다. 특히 새로운 벤치마크가 아닌 오래된 벤치마크일수록 이 위험이 크다. 실제 프로젝트에서는 벤치마크보다 10~20% 낮은 성능을 보이는 경우가 많다.
자체 발표 vs 독립 검증: DeepSeek V4-Pro의 SWE-bench 점수는 자체 발표에서 83.7%, 독립 검증에서 80.6%로 차이가 있다. 모델 개발사가 발표한 수치는 항상 독립 검증과 비교해보아야 한다.
라이선스 확인: Llama 4는 월간 활성 사용자 7억 명 제한이 있다. B2C 서비스에서 대규모로 사용할 경우 라이선스 위반 가능성을 검토해야 한다. 반면 Gemma 4, Qwen 3.5, GLM-5.1은 Apache 2.0이나 MIT로 제한이 거의 없다.
컨텍스트 길이와 실제 품질: Llama 4 Scout의 10M 컨텍스트는 길이만 긴 것이 아니라, 그 길이 내에서도 품질이 유지되어야 한다. 컨텍스트가 길어질수록 중간 정보를 잊는 “lost in the middle” 현상이 발생할 수 있으므로, 실제 사용 시에는 필요한 만큼만 컨텍스트를 제공하는 것이 좋다.
2026년 오픈소스 LLM 생태계를 한 줄로 요약하면: “상용 모델을 대체할 수 있는 모델이 하나가 아니라 여럿이다.” 핵심은 자신의 용도에 맞는 모델을 선택하는 것이다.
당장 시도해볼 추천: Ollama로 Qwen 3.5를 설치해 로컬 코딩 어시스턴트로 써보라. 8GB VRAM만 있으면 되고, 설치는 ollama pull qwen3:8b 한 줄이다. 상용 API에 의존하지 않고도 강력한 AI 코딩 보조를 경험할 수 있다.
GPT-4o API 호출 한 번에 몇 원이 나가는지 계산해 본 적 있는가? 하루에 수천 번 호출하는 서비스라면 월간 API 비용만 수십만 원에서 수백만 원까지 가볍게 넘어간다. 그리고 데이터가 OpenAI 서버를 거친다는 건, 의료 기록이나 법무 문서 같은 민감 정보를 다루는 팀에는 선택지가 아니다.
2026년, 로컬 LLM 추론은 취미용 실험을 넘어 실제 프로덕션 선택지가 됐다. 이 글에서는 어떤 하드웨어가 필요한지, 양자화(quantization)가 뭘 줄이고 뭘 잃는지, Ollama로 5분 안에 모델을 띄우는 법부터 프로덕션급 서빙까지, 숫자와 코드로 구체적으로 정리한다.
세 가지 실제 이유가 있다.
비용 교차점. 자체 하드웨어를 소유한 상태에서 월 약 5천만 토큰 이상을 처리할 때, 로컬 배포가 API 단가를 역전한다. 그 이하면 클라우드 추론이 더 싸다. 단순히 “멋있어서” 로컬을 고르면 투자 대비 효율이 떨어진다.
데이터 주권. 금융권, 의료, 법무 등 규제 산업에서는 데이터가 외부 서버를 거치는 것 자체가 컴플라이언스 위반이다. 이 경우 비용과 무관하게 로컬 배포가 필수다.
오프라인·엣지 환경. 인터넷 연결이 불안정하거나 불가능한 환경(선박, 공장, 군사 시설)에서는 로컬이 유일한 선택지다. 레이턴시도 클라우드 왕복 시간(수십~수백 ms) 없이 sub-50ms로 떨어뜨릴 수 있다.
핵심은 이것이다: 로컬 LLM을 “멋있으니까” 쓰지 마라. 데이터 주권 요구사항이 있거나, 초대용량 반복 작업이 있거나, 오프라인 환경이거나, 이 셋 중 하나가 있을 때 선택하라.
LLM 추론의 병목은 연산량(FLOPS)이 아니라 메모리 대역폭이다. 토큰 하나를 생성할 때마다 전체 모델 파라미터를 메모리에서 읽어야 하기 때문이다. 따라서 “GPU가 빠르다”보다 “메모리가 빠르고 크다”가 핵심 기준이다.
주요 하드웨어의 실제 벤치마크를 보자. Q4_K_M 양자화 기준, llama.cpp로 측정한 토큰 생성 속도다.
| GPU/칩 | VRAM/메모리 | 대역폭 | 7B 모델 | 70B 모델 |
|---|---|---|---|---|
| NVIDIA RTX 4090 | 24 GB | 1,008 GB/s | ~135 tok/s | 18 tok/s (Q2_K) |
| NVIDIA RTX 3090 | 24 GB | 936 GB/s | ~95 tok/s | 10 tok/s (Q2_K) |
| Apple M4 Pro Mac Mini | 48 GB | 273 GB/s | ~45 tok/s | 5 tok/s |
| Apple M3 Max | 64 GB | 400 GB/s | ~40 tok/s | 5 tok/s |
| NVIDIA RTX 4060 Ti | 16 GB | 288 GB/s | ~55 tok/s | OOM |
| CPU only (DDR5) | 32 GB | ~80 GB/s | 6-10 tok/s | <1 tok/s |
참고: 40 tok/s 이상이면 체감상 즉각적이다(읽는 속도보다 빠름). 20-40 tok/s는 쾌적. 10-20 tok/s는 쓸 만함. 10 tok/s 미만은 대화형으로는 고통스럽고 배치 처리용이다.
실전 추천:
원래 모델은 16비트 부동소수점(FP16)으로 저장된다. 7B 모델이면 14GB, 70B 모델이면 140GB가 필요하다. 현실적인 하드웨어에서 돌리려면 양자화(quantization)로 모델 크기를 줄여야 한다.
GGUF 포맷의 주요 양자화 등급을 정리한다.
| 등급 | 7B 모델 크기 | 70B 모델 크기 | 품질 손실 | 추천 용도 |
|---|---|---|---|---|
| F16 (원본) | ~14 GB | ~140 GB | 없음 | 연구/정밀 작업 |
| Q8_0 | ~7.7 GB | ~77 GB | 거의 없음 | VRAM 여유가 충분할 때 |
| Q5_K_M | ~5.3 GB | ~53 GB | 미미 | 정밀도가 중요한 작업 |
| Q4_K_M | ~4.4 GB | ~44 GB | 약간 | 대부분의 실전 용도 |
| Q2_K | ~2.8 GB | ~28 GB | 상당함 | VRAM이 모자랄 때的最后 수단 |
핵심 인사이트: Q4_K_M이 대부분의 사용자에게 최적의 균형점이다. 품질 손실은 인지하기 어려울 정도지만, 모델 크기는 FP16 대비 약 70% 감소한다. VRAM이 충분하다면 Q5_K_M 또는 Q8_0으로 올리면 좋지만, 체감 차이는 미미하다.
주의할 점: Q2_K는 모델이 돌아가긴 하지만, 복잡한 추론이나 코드 생성에서 품질 저하가 뚜렷하게 나타난다. 24GB GPU에서 70B를 돌리려다 Q2_K를 쓰느니, 차라리 13B를 Q4_K_M으로 돌리는 게 낫다.
Ollama는 현재 로컬 LLM 실행의 사실상 표준이다. 설치부터 모델 실행까지 터미널 명령 몇 개면 끝난다.
설치 (macOS / Linux):
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# 설치 확인
ollama --version
모델 실행:
# 7B 모델 (대부분의 랩탑에서 동작)
ollama run qwen2.5:7b
# 14B 모델 (16GB+ VRAM 권장)
ollama run qwen2.5:14b
# 72B 모델 (48GB+ 메모리 필요)
ollama run qwen2.5:72b
첫 실행 시 자동으로 모델을 다운로드한다. Q4_K_M 양자화 버전이 기본으로 내려받아진다.
Apple Silicon에서 MLX 백엔드 활성화 (2026년 3월 추가):
Ollama 0.19부터 Apple Silicon에서 MLX 백엔드를 사용할 수 있다. 기존 Metal 백엔드 대비 약 2배 빠른 추론 속도를 보여준다.
# MLX 백엔드 활성화
OLLAMA_MLX=1 ollama serve
# 확인: 실행 시 로그에 "using MLX"가 표시되는지 확인
# Mac Studio M2 Ultra 64GB에서 Q4_K_M 기준
# Metal: ~22 tok/s (7B) → MLX: ~40+ tok/s (7B) 로 향상 보고됨
Ollama는 실행 시 자동으로 로컬 API 서버를 시작한다. OpenAI 호환 엔드포인트를 제공하므로 기존 코드를 최소한으로 수정해서 연동할 수 있다.
# Ollama 서버 시작 (백그라운드)
ollama serve &
# API 호출 테스트
curl http://localhost:11434/api/chat -d '{
"model": "qwen2.5:7b",
"messages": [
{"role": "user", "content": "Python으로 피보나치 수열을 작성해줘"}
],
"stream": false
}'
Python에서 OpenAI SDK로 연동:
from openai import OpenAI
# Ollama 서버를 가리키도록 base_url 변경
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama" # Ollama는 API key가 필요 없지만 필드는 채워야 함
)
response = client.chat.completions.create(
model="qwen2.5:7b",
messages=[
{"role": "system", "content": "한국어로 답변해."},
{"role": "user", "content": "RAG 파이프라인의 기본 구조를 설명해줘"}
],
temperature=0.7,
max_tokens=1000
)
print(response.choices[0].message.content)
이 코드는 OpenAI API를 호출하던 기존 애플리케이션에서 base_url과 api_key만 바꾸면 로컬 모델로 전환된다는 걸 보여준다. 프롬프트 엔지니어링이나 함수 호출 스키마도 그대로 동작한다.
로컬 LLM을 실제 서비스에 적용할 때 겪게 되는 현실적인 문제들이다.
2026년 3월 기준, 용도별 추천 모델 계층이 정리되어 있다.
단일 GPU에서 동시 요청이 몰리면 처리량이 급감한다. 프로덕션에서는 vLLM이나 LocalAI 같은 서빙 프레임워크를 사용해 continuous batching을 활성화해야 한다.
# vLLM으로 Qwen2.5 7B 서빙 (CUDA GPU 필요)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--quantization awq \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--port 8000
vLLM은 continuous batching과 PagedAttention을 통해 GPU 메모리를 효율적으로 관리하며, 단순 Ollama 서빙보다 동시 요청 처리량이 3~5배 높다.
하드웨어 구매 비용 외에도 전력과 유지보수 비용이 있다. RTX 4090 서버를 24시간 가동하면 월 전기료만 10~15만 원 가량 발생한다. 반면 Mac Mini M4 Pro는 전력 소모가 30W 수준이라 월 2~3만 원이다. 자체 하드웨어 기준 월 5천만 토큰 이상 처리할 때 API 비용을 역전한다는 점을 다시 강조한다.
간단한 의사결정 흐름이다.
혼합 전략도 유효하다. 민감한 데이터 전처리와 분류는 로컬 7B 모델로 처리하고, 복잡한 생성 작업은 클라우드 API로 넘기는 식이다. 앞서 보여준 OpenAI SDK 코드에서 base_url만 조건부로 바꾸면 된다.
당장 시도해볼 첫 걸음: brew install ollama && ollama run qwen2.5:7b를 실행해 보라. 5분 안에 여러분의 기기에서 AI가 돌아가는 걸 확인할 수 있다.
LLM에 “JSON으로 줘”라고 했더니, 마크다운 코드 블록으로 감싸서 온다. 친절하게 설명까지 한 줄 덧붙이고. 그래서 코드 블록 벗기는 정규식을 하나 짠다. 해설 떼는 정규식도 하나 짠다. 어느 날은 {"result": ...}로 한 겹 더 감싸서 오고, 어느 날은 score 필드가 문자열 "0.85"인지 숫자 0.85인지도 모른 채 데이터베이스에 밀어 넣는다.
이건 2024년까지의 이야기다. 2026년 현재, 메이저 LLM 프로바이더 전부가 네이티브 구조화 출력(Structured Output) API를 제공한다. 출력이 생성되는 그 순간에 스키마를 강제하는, 정규식 따위가 필요 없는 방식이다. 이 글에서는 세 프로바이더의 구조화 출력이 어떻게 다르고, 내부에서 무슨 일이 일어나며, 프로덕션에서 어떤 함정이 기다리는지를 실전 코드와 함께 정리한다.
구조화 출력이라는 말 아래에 사실 세 가지 완전히 다른 기술이 섞여 있다. 이걸 구분하지 않으면 버그 추적에 며칠을 쓰게 된다.
레벨 1: 프롬프트 엔지니어링 — “다음 JSON 스키마에 맞춰서 응답해줘”라고 프롬프트에 적는 방식이다. 80~95%는 작동하지만, 엣지 케이스에서 조용히 실패한다. score를 "0.85"(문자열)로 주거나, 요청하지 않은 confidence 필드를 추가로 만들어낸다. 타입 보장이 없다.
레벨 2: JSON 모드 — response_format: { type: "json_object" } 같은 설정으로, 출력이 문법적으로 유효한 JSON임은 보장한다. 하지만 키와 값은 모델 마음대로다. 수프 레시피를 JSON으로 달라고 했는데 송장 데이터를 JSON으로 줘도 JSON 모드는 통과시킨다. 이게 가장 위험한 레벨이다. “작동하는 것 같다”는 착각을 준다.
레벨 3: 스키마 제약 디코딩 — JSON Schema를 전달하면, 토큰이 생성되는 시점에 스키마를 위반하는 토큰을 원천 차단한다. 100% 스키마 준수를 보장하며, 타입과 값의 범위까지 강제한다. 프로덕션이라면 이 레벨을 써야 한다.
LLM이 텍스트를 생성할 때, 매 스텝마다 어휘 전체(약 10만 개 토큰)에서 다음 토큰을 선택한다. 제약 디코딩은 이 선택 과정에 유한 상태 머신(FSM)을 끼워 넣는다.
일반 생성:
토큰 확률: {"hello": 0.3, "{": 0.1, "The": 0.2, ...}
→ 어떤 토큰이든 선택 가능
제약 생성 (JSON 객체 시작을 기대하는 상태):
토큰 확률: {"hello": 0.3, "{": 0.1, "The": 0.2, ...}
마스크: {"hello": 0, "{": 1, "The": 0, ...}
→ "{"와 공백 토큰만 유효 → 반드시 "{"로 시작
{"name": string, "age": integer} 스키마의 상태 머신을 따라가 보면:
{ 기대{"name" 기대: 기대, 또는 } 기대,면 → "age" 기대 → : 기대 → 정수 값 기대} → 완료매 상태마다 FSM이 스키마를 어기는 토큰을 마스킹한다. 구조는 확실히 보장하면서도, 모델은 유효한 토큰 중 가장 확률이 높은 것을 고를 수 있어 출력 품질도 유지된다.
response_format + json_schemafrom openai import OpenAI
from pydantic import BaseModel
class Invoice(BaseModel):
buyer: str
seller: str
amount: float
currency: str = "KRW"
client = OpenAI()
response = client.responses.parse(
model="gpt-4o-2024-08-06",
input=[
{"role": "system", "content": "송장 정보를 추출하세요."},
{"role": "user", "content": "삼성전자가 LG전자에 500만 원어치 부품을 납품했습니다."}
],
text_format=Invoice,
)
invoice = response.output_parsed
print(invoice.buyer) # "LG전자"
print(invoice.seller) # "삼성전자"
print(invoice.amount) # 5000000.0
OpenAI는 2024년 8월에 Structured Outputs를 정식 출시했다. response_format: { type: "json_schema", json_schema: {...} } 형태로 JSON Schema를 직접 전달하거나, 최신 responses.parse() API에서는 Pydantic 모델을 직접 넘길 수 있다. 스키마 준수를 100% 보장한다.
주의점: OpenAI는 스키마에 additionalProperties: false를 요구하고, 최대 깊이와 키 개수에 제한이 있다. 선택적 필드는 반드시 기본값을 가져야 한다.
output_format (베타) 또는 tool_usefrom anthropic import Anthropic
from pydantic import BaseModel
class Invoice(BaseModel):
buyer: str
seller: str
amount: float
currency: str = "KRW"
client = Anthropic()
# 방법 1: output_format 사용 (2025년 11월 베타 출시)
# 베타 헤더 필요: anthropic-beta: structured-outputs-2025-11-13
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=1024,
messages=[
{"role": "user", "content": "삼성전자가 LG전자에 500만 원어치 부품을 납품했습니다."}
],
output_format={
"type": "json",
"schema": Invoice.model_json_schema()
},
betas=["structured-outputs-2025-11-13"]
)
import json
invoice = Invoice.model_validate_json(response.content[0].text)
# 방법 2: tool_use를 활용한 방식 (베타 이전부터 사용 가능)
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=1024,
tools=[{
"name": "extract_invoice",
"description": "송장 정보를 추출합니다",
"input_schema": Invoice.model_json_schema()
}],
tool_choice={"type": "tool", "name": "extract_invoice"},
messages=[
{"role": "user", "content": "삼성전자가 LG전자에 500만 원어치 부품을 납품했습니다."}
]
)
Anthropic은 2025년 11월 14일에 구조화 출력을 공개 베타로 출시했다. output_format 파라미터로 JSON Schema를 전달하면 제약 디코딩이 적용된다. 스키마는 24시간 캐시되어 반복 요청 시 오버헤드가 줄어든다. 현재 Claude Sonnet 4.5와 Opus 4.1을 지원하며, 베타 헤더(structured-outputs-2025-11-13)가 필요하다. 베타 이전부터 tool_use를 통한 간접 방식도 가능했고, 여전히 유효하다.
response_schemaimport google.generativeai as genai
from pydantic import BaseModel
class Invoice(BaseModel):
buyer: str
seller: str
amount: float
currency: str = "KRW"
genai.configure(api_key="YOUR_KEY")
response = genai.GenerativeModel("gemini-2.0-flash").generate_content(
"삼성전자가 LG전자에 500만 원어치 부품을 납품했습니다.",
generation_config=genai.GenerationConfig(
response_mime_type="application/json",
response_schema=Invoice
)
)
invoice = Invoice.model_validate_json(response.text)
Gemini는 generation_config에 response_schema를 직접 전달한다. Pydantic 모델을 그대로 넘길 수 있어 코드가 가장 간결하다. 다만 일부 복잡한 스키마(예: 중첩된 anyOf)에서 제한이 있을 수 있다.
구조화 출력이 스키마 준수를 100% 보장한다는 건 알겠다. 하지만 스키마는 맞으면서 의미적으로 틀린 값은 잡아주지 않는다.
# 스키마는 완벽하게 준수하지만, buyer와 seller가 뒤바뀐 케이스
{
"buyer": "삼성전자", # 실제로는 seller
"seller": "LG전자", # 실제로는 buyer
"amount": 5000000.0,
"currency": "KRW"
}
이건 JSON Schema 레벨에서는 절대 잡을 수 없다. 해결 방법은 세 가지다.
첫째, 프롬프트에 필드 정의를 명확히 적는다. “buyer는 물품을 구매하는 측, seller는 물품을 판매하는 측”처럼 각 필드의 의미를 프롬프트에 적어야 한다. 구조화 출력이 제약 디코딩을 사용하더라도, 모델은 프롬프트를 기반으로 “어떤 값을 넣을지”를 결정한다.
둘째, 검증 로직을 별도로 둔다. Pydantic validator나 별도 검증 단계에서 비즈니스 로직을 확인한다.
from pydantic import BaseModel, field_validator
class Invoice(BaseModel):
buyer: str
seller: str
amount: float
currency: str = "KRW"
@field_validator("amount")
@classmethod
def amount_must_be_positive(cls, v):
if v <= 0:
raise ValueError("금액은 양수여야 합니다")
return v
셋째, 평가(eval)를 구축한다. 구조화 출력도 평가 대상이다. 정확한 필드 매핑률, 값의 정확도를 지속적으로 측정해야 한다.
여러 프로바이더를 동시에 쓰는 환경이라면 Instructor 라이브러리가 유용하다. Pydantic 모델 하나로 OpenAI, Anthropic, Gemini, Ollama 등을 모두 지원한다.
import instructor
from openai import OpenAI
from anthropic import Anthropic
from pydantic import BaseModel
class Analysis(BaseModel):
summary: str
sentiment: float # -1.0 ~ 1.0
keywords: list[str]
# OpenAI
openai_client = instructor.from_openai(OpenAI())
result = openai_client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "오늘 날씨가 좋아서 기분이 최고야"}],
response_model=Analysis,
)
# Anthropic — 모델만 바꾸면 된다
claude_client = instructor.from_anthropic(Anthropic())
result = claude_client.messages.create(
model="claude-sonnet-4-20250514",
messages=[{"role": "user", "content": "오늘 날씨가 좋아서 기분이 최고야"}],
response_model=Analysis,
max_tokens=1024,
)
Instructor는 내부적으로 각 프로바이더의 구조화 출력 API를 최우선으로 사용하고, 지원하지 않는 모델에서는 함수 호출(function calling)로 폴백한다. 재시도 로직도 내장되어 있어, 파싱 실패 시 자동으로 재요청한다.
간단한 결정 기준을 정리하면:
| 상황 | 추천 레벨 | 이유 |
|---|---|---|
| 프로토타입, 내부 도구 | 프롬프트 엔지니어링 | 빠르게 구현, 실패해도 치명적이지 않음 |
| 단순한 JSON 파싱 | JSON 모드 | 문법적 유효성만 보장돼도 충분한 경우 |
| 프로덕션 데이터 파이프라인 | 스키마 제약 디코딩 | 100% 스키마 보장 필수 |
| 다중 프로바이더 환경 | Instructor + Pydantic | 통일된 인터페이스 |
| 스트리밍이 필요한 경우 | 프로바이더 네이티브 API | Instructor는 스트리밍 제약이 있을 수 있음 |
당장 해볼 것: 기존 프로젝트에서 json.loads() + 정규식으로 LLM 출력을 파싱하는 부분을 찾아서, 해당 프로바이더의 네이티브 구조화 출력 API로 교체해 보라. 보통 15분 안에 끝나고, 그 즉시 묻어있던 파싱 버그들이 사라진다.
2025년까지만 해도 AI 코딩 도구라면 GitHub Copilot 하나를 떠올리는 것이 당연했다. 그러나 2026년, 상황이 완전히 바뀌었다. AI 코딩 에이전트는 단순한 자동완성을 넘어 독립적으로 코드를 작성하고, 테스트하고, PR까지 올리는 “에이전트”로 진화했다.
이 글에서는 2026년 5월 현재 개발자들이 실제로 사용하는 주요 AI 코딩 에이전트들을 벤치마크, 가격, 실전 적합도 기준으로 비교한다.
Anthropic의 Claude Code는 CLI와 IDE를 모두 지원하며, 특히 복잡한 리팩토링과 대규모 코드베이스 이해에서 압도적인 성능을 보인다.
강점:
약점:
# Claude Code 실행 예시
claude "이 프로젝트의 인증 모듈을 JWT에서
OAuth 2.0 + PKCE로 마이그레이션해줘"
OpenAI의 Codex는 1,000 토큰/초의 처리 속도(Cerebras 기반)를 자랑하며, 클라우드 샌드박스에서 독립적으로 작업을 수행한다.
강점:
약점:
Copilot은 여전히 가장 많은 사용자를 보유하며, 다중 모델 지원(GPT-4o, Claude, Gemini 등)으로 유연성을 제공한다.
강점:
약점:
Cursor는 VS Code 포크로, IDE 자체에 AI를 깊이 통합했다. 인라인 편집, 채팅, 코드베이스 검색이 하나의 환경에서 이루어진다.
강점:
@codebase, @docs 등으로 프로젝트 전체를 참조약점:
Aider는 git과 깊게 통합된 오픈소스 CLI 도구다. 자체 모델 없이 BYOK(Bring Your Own Key) 방식으로 동작한다.
# Aider로 파일 수정하기
aider main.py --model gpt-4o
# > 에러 핸들링을 추가하고, 로깅을 structured JSON으로 바꿔줘
강점:
| 도구 | 시작 가격 | 무료 티어 | 오픈소스 |
|---|---|---|---|
| Claude Code | $20/월 | 제한적 | ❌ |
| OpenAI Codex | $20/월 | 제한적 | ❌ |
| GitHub Copilot | 무료~$10/월 | ✅ | ❌ |
| Cursor | $20/월 | 제한적 | ❌ |
| Aider | 무료 (BYOK) | ✅ | ✅ |
| Cline/Roo Code | 무료 (BYOK) | ✅ | ✅ |
| OpenCode | 무료 (BYOK) | ✅ | ✅ |
선택은 작업 방식에 달려 있다:
그리고 개발자의 70%가 2~4개 도구를 함께 쓴다는 점을 기억하자. 하나만 고를 필요 없다. 상황에 맞게 조합하는 것이 2026년의 실용적인 전략이다.
2026년의 AI 코딩 에이전트 경쟁은 단순한 자동완성을 훨씬 넘어섰다. 각 도구가 명확한 강점과 약점을 가지고 있으며, 자신의 개발 워크플로우에 맞는 도구를 선택하는 것이 핵심이다. 무료 티어와 BYOK 옵션이 널리 available하니, 직접 사용해보고 결정하는 것을 추천한다.
]]>