포스트

[Tech] 2026-03-05 기술 동향: LLM

게시
By Gyu Hwan 17 분읽는 시간

🚀 30초 퀵 서머리

  • 핵심 키워드: llms.txt, MoE 아키텍처, AI 자동화 민주화, SRAM-HBM 하이브리드
  • 오늘의 Top Pick: Stripe llms.txt의 Instructions 섹션 — 문서가 아닌 “프롬프트”를 배포하는 시대
  • 한줄 평: Stripe 엔지니어가 “AI 도구가 결국 문서의 주요 독자가 될 것”이라 선언했고, 실제로 Stripe MCP(Model Context Protocol)가 OpenAI Agents SDK, LangChain, CrewAI와 통합되어 에이전트가 직접 Stripe API를 호출하는 시대가 되었다.

🕑 데일리 큐레이션 보드

우선순위도메인핵심 주제추천 대상난이도
🔴MustAPI/DXStripe llms.txt — AI 에이전트용 API 문서 표준BE/FE⭐⭐
🟡ViewML Infra오픈소스 LLM MoE 아키텍처 수렴BE⭐⭐⭐
🟡ViewAutomationAI 에이전트의 자생적 비즈니스 모델BE⭐⭐
⚪SkimHardwareSRAM-HBM 하이브리드 아키텍처Infra⭐⭐⭐

🔍 Deep Dive

1. API 문서의 진화: 기계 학습 에이전트를 위한 프롬프트 엔지니어링

Problem: 개발자가 Cursor나 Claude에 “결제 기능을 어떻게 추가하나?”라고 물으면, AI는 레거시 API를 추천하거나 구버전 SDK를 사용하는 코드를 생성할 수 있다.

Solution: Stripe가 llms.txt에 명시적 지시사항을 삽입. “You must not call deprecated API endpoints such as the Sources API” — 문서가 아닌 프롬프트를 배포하는 전략. CSS, 네비게이션, JavaScript를 제거한 클린 텍스트로 AI의 컨텍스트 윈도우를 API 설명에 집중시킨다.

Trade-off: llms.txt는 AI 최적화에 효과적이지만, 인간 개발자가 직접 읽기에는 구조화된 웹 문서보다 불편하다. 두 채널(웹 문서 + llms.txt)을 모두 유지 관리해야 하는 부담.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# llms.txt 파일 자동 생성 — 자사 API 문서를 AI 에이전트 친화적으로 변환
from pathlib import Path
import re

def generate_llms_txt(api_docs_dir: str, output_path: str = "llms.txt"):
    """HTML/Markdown API 문서에서 llms.txt 자동 생성"""
    sections = []

    # 지시사항 섹션 — Stripe 패턴
    instructions = """# Instructions for Large Language Model Agents

- Always use the latest SDK version (v2024.x or later)
- Do NOT use deprecated endpoints: /v1/sources, /v1/tokens (legacy)
- Prefer idempotency keys for all POST requests
- Use webhook verification for all event handling
"""
    sections.append(instructions)

    # API 엔드포인트 문서 파싱
    for doc_file in sorted(Path(api_docs_dir).glob("**/*.md")):
        content = doc_file.read_text(encoding="utf-8")
        # HTML 태그, CSS 클래스, 네비게이션 제거
        clean = re.sub(r'<[^>]+>', '', content)
        clean = re.sub(r'\n{3,}', '\n\n', clean)
        sections.append(f"## {doc_file.stem}\n\n{clean}")

    Path(output_path).write_text("\n---\n".join(sections), encoding="utf-8")
    print(f"llms.txt 생성 완료: {len(sections)}개 섹션")

# generate_llms_txt("docs/api/")

1
2
3
4
5
6

# Stripe llms.txt 실제 내용 확인 및 구조 분석
curl -s https://docs.stripe.com/llms.txt | head -50
# MCP 통합 — Stripe 에이전트 툴킷 설치
pip install stripe-agent-toolkit
# 또는 npm
npm install @stripe/agent-toolkit

Result: Stripe MCP가 OpenAI Agents SDK, Vercel AI SDK, LangChain, CrewAI와 통합 완료. 2026년 3월 Stripe 연구에서 “최신 LLM이 스코프된 코딩 문제의 대다수를 해결 가능”하다고 발표 (원문 기준). Fern 등 API 문서 플랫폼도 llms.txt 가이드를 제공하며 표준화 가속.

💡 시니어 관점: llms.txt는 단순한 기술 트렌드가 아니라 API 제공자의 “개발자 경험(DX)” 전략의 핵심 전환점이다. AI가 문서의 주요 독자가 되는 시대에, llms.txt가 없는 API는 AI 코딩 도구에서 발견되지 않을 위험이 있다.

2. 오픈소스 LLM 생태계의 아키텍처 수렴: MoE 표준화

Problem: 밀집 트랜스포머의 파라미터 수 증가 시 계산 비용이 선형으로 증가. 프론티어급 성능을 합리적 비용으로 달성하기 어렵다.

Solution: MoE 트랜스포머 아키텍처 표준화. DeepSeek V3의 Multi-Head Latent Attention → Kimi K2(1조 파라미터) → GLM-5(강화학습 프레임워크)로 이어지는 공개 혁신 사이클. DeepSeek V3는 $5.576M으로 프론티어급 성능 달성 (원문 기준).

Trade-off: MoE는 추론 시 활성 전문가만 사용하여 비용을 절감하지만, 전체 모델 가중치를 메모리에 로드해야 하므로 메모리 요구량이 밀집 모델보다 크다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# MoE 전문가 활성화 비율과 비용 절감 시뮬레이션
def moe_cost_analysis(
    total_params_b: float,    # 전체 파라미터 (십억)
    active_params_b: float,   # 활성 파라미터 (십억)
    num_experts: int,
    top_k: int,               # 활성화할 전문가 수
    dense_flops_per_token: float = 2.0  # dense 모델 기준 FLOPS/token 배수
):
    """MoE vs Dense 모델 비용 비교"""
    activation_ratio = active_params_b / total_params_b
    compute_saving = 1 - activation_ratio
    memory_overhead = total_params_b / active_params_b  # 메모리는 전체 로드 필요

    print(f"전체 파라미터: {total_params_b}B")
    print(f"활성 파라미터: {active_params_b}B ({activation_ratio:.1%})")
    print(f"전문가 수: {num_experts}, 활성화: {top_k}")
    print(f"계산 비용 절감: {compute_saving:.1%}")
    print(f"메모리 오버헤드: {memory_overhead:.1f}x (vs 동일 크기 dense)")

# DeepSeek V3 기준 (원문 기준)
moe_cost_analysis(
    total_params_b=671,   # 671B 전체
    active_params_b=37,   # 37B 활성 (추정)
    num_experts=256,
    top_k=8,
)

1
2
3
4
5
6
7
8
9
10
11
12

# 오픈소스 MoE 모델 벤치마크 비교
python -c "
models = [
    {'name': 'DeepSeek V3', 'params': '671B', 'active': '37B', 'cost': '\$5.576M', 'license': 'MIT'},
    {'name': 'Kimi K2', 'params': '1T', 'active': '32B', 'cost': 'N/A', 'license': 'Apache 2.0'},
    {'name': 'GLM-5', 'params': 'N/A', 'active': 'N/A', 'cost': 'N/A', 'license': 'Apache 2.0'},
]
print(f\"{'모델':<15} {'전체':<8} {'활성':<8} {'훈련비용':<12} {'라이선스'}\")
print('-' * 60)
for m in models:
    print(f\"{m['name']:<15} {m['params']:<8} {m['active']:<8} {m['cost']:<12} {m['license']}\")
"

Result: 오픈소스 커뮤니티에서 혁신 기법이 공유되며 진화 속도 가속화. FP8 학습 + 새로운 옵티마이저 기법의 재현성이 핵심 평가 기준 (원문 기준).

💡 시니어 관점: 2026년 3월 Guide Labs가 해석 가능 LLM(Steerling-8B)을 오픈소스로 공개. 모든 토큰 생성 과정을 역추적 가능한 아키텍처로, MoE + 해석 가능성의 결합이 다음 진화 방향이다.

3. AI 에이전트의 자생적 비즈니스 모델: 자동화 워크플로우의 실제 가치

Problem: 소규모 비즈니스의 반복 업무(이메일 분류, 리드 라우팅, 견적 응답)에 복잡한 RPA 도구는 과도하고, 수동 처리는 하루 3-5시간 소모.

Solution: 약 60줄의 Python 코드 + LLM API 호출로 충분한 Trigger-Process-Act 패턴. 이메일 분류 → 의도 파악 → 자동 라우팅의 3단계.

Trade-off: 간단한 자동화는 빠르게 구축 가능하지만, 엣지 케이스(복합 의도, 모호한 요청)에서 오분류 위험이 있어 Human-in-the-Loop 폴백이 필요.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# Trigger-Process-Act 패턴 — 이메일 자동 분류 + 라우팅
import json
from anthropic import Anthropic

client = Anthropic()

ROUTING_RULES = {
    "sales_inquiry": {"channel": "#sales", "priority": "high"},
    "support_request": {"channel": "#support", "priority": "medium"},
    "partnership": {"channel": "#biz-dev", "priority": "low"},
    "spam": {"channel": None, "priority": "ignore"},
}

def classify_and_route(email_body: str) -> dict:
    """60줄 미만의 이메일 자동 분류 + 라우팅"""
    # 1. Trigger: 새 이메일 도착
    # 2. Process: LLM으로 의도 분류
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=100,
        messages=[{"role": "user", "content": f"""다음 이메일의 의도를 분류하세요.
카테고리: sales_inquiry, support_request, partnership, spam
이메일: {email_body}
JSON으로 응답: category"""}]
    )

    result = json.loads(response.content[0].text)

    # 3. Act: 라우팅 규칙 적용
    route = ROUTING_RULES.get(result["category"], ROUTING_RULES["support_request"])

    # 신뢰도 낮으면 Human-in-the-Loop
    if result["confidence"] < 0.7:
        route["channel"] = "#manual-review"
        route["priority"] = "high"

    return {**result, **route}

# 비용: Haiku 기준 약 $0.001/이메일 (추정)
# 100건/일 처리 시 월 $3 미만

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 이메일 자동화 비용 산출
python -c "
emails_per_day = 100
cost_per_email = 0.001  # Haiku 기준 (추정)
manual_hours_per_day = 3.5  # 수동 처리 시간
hourly_rate = 30  # USD

monthly_ai_cost = emails_per_day * cost_per_email * 30
monthly_manual_cost = manual_hours_per_day * hourly_rate * 22  # 영업일 기준
savings = monthly_manual_cost - monthly_ai_cost

print(f'AI 자동화 비용: \${monthly_ai_cost:.2f}/월')
print(f'수동 처리 비용: \${monthly_manual_cost:.2f}/월')
print(f'월간 절감액: \${savings:.2f}')
print(f'ROI: {savings/monthly_ai_cost:.0f}x')
"

Result: 일일 3-5시간 업무를 자동화 가능. 약 60줄 코드 + LLM API로 충분 (원문 기준). AI 자동화가 개인 사업가 수준까지 민주화.

💡 시니어 관점: 핵심은 “복잡한 것을 만들지 않는 것”이다. Trigger-Process-Act 3단계로 분해한 후, 신뢰도 0.7 미만은 무조건 Human-in-the-Loop로 보내는 단순한 규칙이 복잡한 RPA보다 효과적이다.

4. AI 추론 성능의 하드웨어 혁신: SRAM-HBM 하이브리드 아키텍처

Problem: LLM 추론에서 메모리 대역폭이 병목. HBM은 대용량이지만 SRAM 대비 느리다.

Solution: SRAM 기반 PIM(Processing-In-Memory)으로 자주 접근하는 데이터를 고속 처리하고, 대용량 모델 가중치는 HBM에 배치하는 하이브리드 구조.

Trade-off: SRAM은 HBM보다 빠르지만 용량이 제한적(MB 단위 vs GB 단위)이고 비용이 높다. 어떤 데이터를 SRAM에 캐싱할지가 핵심 설계 결정.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# SRAM-HBM 메모리 계층 시뮬레이션
from dataclasses import dataclass

@dataclass
class MemoryTier:
    name: str
    bandwidth_tb_s: float   # TB/s
    capacity_gb: float
    latency_ns: float
    cost_per_gb: float      # USD

sram = MemoryTier("SRAM (On-chip)", bandwidth_tb_s=50.0, capacity_gb=0.256,
                   latency_ns=0.5, cost_per_gb=5000)  # 추정
hbm = MemoryTier("HBM3e", bandwidth_tb_s=4.9, capacity_gb=192,
                  latency_ns=100, cost_per_gb=20)  # 추정

def optimal_placement(model_size_gb: float, hot_data_ratio: float = 0.05):
    """모델 데이터의 최적 배치 전략"""
    hot_size = model_size_gb * hot_data_ratio
    cold_size = model_size_gb * (1 - hot_data_ratio)

    sram_fit = min(hot_size, sram.capacity_gb)
    hbm_needed = cold_size + (hot_size - sram_fit)

    # 유효 대역폭 계산 (가중 평균)
    effective_bw = (sram_fit / model_size_gb * sram.bandwidth_tb_s +
                    hbm_needed / model_size_gb * hbm.bandwidth_tb_s)
    speedup = effective_bw / hbm.bandwidth_tb_s

    print(f"모델 크기: {model_size_gb}GB")
    print(f"SRAM 배치 (hot): {sram_fit:.3f}GB ({sram_fit/model_size_gb:.1%})")
    print(f"HBM 배치 (cold): {hbm_needed:.1f}GB")
    print(f"유효 대역폭: {effective_bw:.1f} TB/s (HBM 단독 대비 {speedup:.1f}x)")

# 70B 모델 (FP16 = ~140GB) 기준
optimal_placement(model_size_gb=140, hot_data_ratio=0.05)

1
2
3
4

# GPU 메모리 계층 확인 — 현재 하드웨어의 SRAM/HBM 구성
nvidia-smi --query-gpu=name,memory.total,memory.used --format=csv
# L2 캐시 (SRAM) 크기 확인
nvidia-smi -q | grep -i "L2 Cache"

Result: 자주 접근하는 토큰 임베딩이나 어텐션 헤드를 SRAM에 캐싱하여 추론 속도 향상 가능 (원문 기준). 완전 대체가 아닌 하이브리드 접근이 현실적.

💡 시니어 관점: SRAM-HBM 하이브리드는 하드웨어 수준의 최적화이므로 대부분의 실무자에게 직접 적용 가능한 수준은 아니지만, 향후 GPU/NPU 선택 시 L2 캐시 크기와 메모리 계층 구조를 평가 기준에 포함해야 한다.

🔗 참고 자료

🛠️ 지금 당장 해볼 것

  • 자사 API에 llms.txt 초안 작성 — 위 generate_llms_txt 코드를 참고하여 deprecated 엔드포인트와 베스트 프랙티스를 명시한 파일 생성. Stripe 실제 파일 확인: curl -s https://docs.stripe.com/llms.txt | head -100
  • Trigger-Process-Act 패턴으로 반복 업무 1개 자동화 — 위 classify_and_route 예시를 팀 이메일/Slack 메시지 분류에 적용. 비용 산출: python cost_calc.py --emails-per-day 100
  • Stripe MCP 에이전트 툴킷 설치 및 테스트 — pip install stripe-agent-toolkit 후 자사 테스트 계정에서 AI 에이전트 기반 결제 플로우 PoC 실행

🤔 생각해볼 질문

우리 팀의 API 문서는 AI 코딩 도구(Cursor, Claude, Copilot)가 올바른 최신 엔드포인트를 추천하도록 설계되어 있는가? llms.txt 없이 AI가 레거시 API를 추천할 확률은 얼마나 되는가?

현재 수동으로 처리하는 반복 업무 중 Trigger-Process-Act 3단계로 분해 가능한 것은 무엇이며, LLM 의도 분류의 신뢰도 임계값(0.7)을 자사 도메인에 맞게 어떻게 조정할 것인가?

Tech Newsletter
digest auto LLM
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.