최재훈

TL;DR​

Sebastian Raschka가 운영하는 LLM Architecture Gallery는 GPT-2부터 최신 Frontier 모델까지 주요 LLM들의 아키텍처를 시각화하여 비교할 수 있는 참고 자료입니다. 각 모델의 파라미터 규모, 컨텍스트 길이, 어텐션 메커니즘, 디코더 타입 등 핵심 사양을 한눈에 파악할 수 있으며, GPT-2의 기본 Dense 구조부터 DeepSeek V3의 MoE, xLSTM 등 다양한 아키텍처 진화를 추적할 수 있습니다. AI Research Engineer가 문제 상황에 맞는 적절한 모델 선택과 아키텍처 설계 인사이트를 얻을 수 있는 실무 레퍼런스입니다.

Key Takeaways​

• 아키텍처 진화 추적: GPT-2(1.5B, MHA)부터 최신 Frontier 모델(DeepSeek V3 671B, Llama 4 400B 등)까지 디코더 구조, 어텐션 메커니즘(MHA → GQA → MoE), 정규화 기법의 변화를 체계적으로 비교 가능
• 스케일별 설계 패턴: 소형(1B-8B), 중형(24B-32B), 대형(120B-400B), 초대형(671B-1T) 파라미터 범위별로 서로 다른 아키텍처 선택(Dense vs MoE, Attention 전략)을 확인할 수 있어 프로젝트 요구사항에 맞는 모델 선택 기준 제공
• 기술적 디테일 확인: 각 모델의 config.json, 라이선스, 컨텍스트 길이, 포지셔널 임베딩 방식(Absolute → RoPE), Key detail 등 실무 구현에 필요한 정보를 팩트시트로 제공
• 다양한 혁신 사례: xLSTM(7B)처럼 Transformer 외 아키텍처, Linear Attention을 활용한 Kimi 시리즈, MoE 최적화를 보여주는 Qwen3/DeepSeek 계열 등 실험적 접근법 학습 가능
• 지속적 업데이트: 2026년 3월까지 업데이트되며(최신 Mistral Large 3 673B, GLM-5 744B 등 포함) 물리적 포스터로도 제공되어 팀 학습 및 레퍼런스용으로 활용 가능

상세 내용​

LLM Architecture Gallery 소개​

Sebastian Raschka 박사가 운영하는 LLM Architecture Gallery는 현대 대규모 언어모델들의 아키텍처를 체계적으로 정리한 시각적 참고 자료입니다. 이 갤러리는 그의 주요 아티클인 "The Big LLM Architecture Comparison", "From GPT-2 to gpt-oss", "From DeepSeek V3 to V3.2", "A Dream of Spring for Open-Weight LLMs" 등에서 다룬 아키텍처 다이어그램과 팩트시트를 한 곳에 모아놓은 것입니다.

Provider LLM(Frontier 급 모델)을 주로 사용하는 실무 환경에서도 각 모델의 내부 아키텍처를 이해하면 LLM 기반 문제에 더 유연하고 전략적으로 접근할 수 있습니다. 예를 들어 레이턴시가 중요한 상황에서는 Dense 모델을, 대규모 처리에는 MoE 구조를 선택하는 등의 의사결정이 가능해집니다.

베이스라인: GPT-2부터 시작하기​

갤러리는 GPT-2 XL (1.5B) 을 Late-2019 dense baseline으로 포함하여, Transformer 디코더 스택이 GPT-2 이후 얼마나 변화했는지 비교할 수 있는 기준점을 제공합니다.

GPT-2 XL 주요 사양:

• Scale: 1.5B 파라미터
• Context: 1,024 토큰
• Decoder type: Dense
• Attention: MHA(Multi-Head Attention) with learned absolute positional embeddings
• Key detail: Dropout, GELU, LayerNorm을 사용한 클래식 GPT-2 레시피

이 기본 구조를 이해하면 이후 모델들이 어떤 방향으로 최적화되었는지(GQA 도입, RoPE 사용, Pre-norm 전환 등) 명확히 파악할 수 있습니다.

주요 모델 아키텍처 비교​

Llama 계열의 진화​

**Llama 3 (8B)**는 GPT-2 대비 진화된 Reference dense stack을 보여줍니다:

• Attention: GQA(Grouped Query Attention) with RoPE
• Context: 8,192 토큰 (GPT-2의 8배)
• Key detail: Pre-norm 구조로 학습 안정성 향상
• License: Llama 3 Community License

**Llama 3.2 (1B)**는 소형 모델 카테고리에서 Qwen 등과 비교되는 벤치마크를 제공하며, **Llama 4 Maverick (400B)**는 초대규모 모델의 최신 사례를 보여줍니다.

MoE 아키텍처: DeepSeek & Qwen​

DeepSeek V3 (671B) 와 V3.2는 Mixture-of-Experts 구조를 활용한 효율적인 초대규모 모델의 대표 사례입니다:

• 전체 671B 파라미터를 가지면서도 실제 활성화되는 파라미터는 일부만 사용
• DeepSeek R1 (671B)는 Reasoning 능력을 강화한 변형

Qwen3 계열은 다양한 스케일에서 MoE를 적용:

• Qwen3 (235B-A22B): 235B 총 파라미터, 22B 활성 파라미터
• Qwen3 Next (80B-A3B): 더욱 aggressive한 sparsity
• Qwen3 (32B), (8B), (4B): Dense 구조로 다양한 규모 지원

극소형 모델: SmolLM & Nanbeige​

SmolLM3 (3B) 와 Gemma 3 (270M) 같은 소형 모델들은 Edge 디바이스나 리소스 제약 환경에서 중요합니다. Nanbeige 4.1 (3B) 와 Tiny Aya (3.35B) 는 특정 언어나 도메인에 특화된 경량 옵션을 제공합니다.

실험적 아키텍처: xLSTM​

xLSTM (7B) 은 Transformer가 아닌 LSTM 기반 접근법으로, 장기 의존성 처리와 메모리 효율성에서 다른 관점을 제시합니다. 이는 Attention 메커니즘의 대안을 탐구하는 연구자들에게 중요한 레퍼런스가 됩니다.

초대규모 모델들​

1T(1조) 파라미터급 모델들도 포함되어 있습니다:

• Kimi K2 (1T), K2.5 (1T): Linear Attention 활용
• Ling 2.5 (1T): 중국어 특화
• GLM-5 (744B): 최신 초대규모 모델

이들은 주로 MoE 구조를 통해 실제 inference 비용을 관리하며, 각기 다른 최적화 전략을 보여줍니다.

핵심 기술 요소 비교​

Attention 메커니즘 진화​

1. MHA (Multi-Head Attention): GPT-2 시대 표준
2. GQA (Grouped Query Attention): Llama 3, OLMo 등에서 KV cache 효율화
3. MoE: DeepSeek, Qwen, Mistral Large 등에서 조건부 계산
4. Linear Attention: Kimi 시리즈에서 긴 컨텍스트 처리 최적화

포지셔널 임베딩​

• Learned Absolute: GPT-2
• RoPE (Rotary Position Embedding): 대부분의 현대 모델 표준

정규화 전략​

• Post-norm: 초기 Transformer
• Pre-norm: Llama, OLMo 등 현대 모델의 표준 (학습 안정성)

실무 활용 방법​

1. 모델 선택 기준 수립: 프로젝트의 레이턴시, 처리량, 메모리 제약에 따라 Dense(작은 규모, 예측 가능한 성능) vs MoE(큰 규모, 효율적 처리) 선택
2. 아키텍처 벤치마킹: 유사 규모 모델들(예: 7B-8B Dense 그룹)의 설계 차이점 비교로 최적화 아이디어 도출
3. 라이선스 확인: 각 팩트시트의 License 정보로 상업적 사용 가능 여부 즉시 파악
4. 구현 레퍼런스: config.json 링크와 Tech report로 재현 가능한 구현 세부사항 확인
5. 팀 교육 자료: Redbubble 포스터(Medium 사이즈: 26.9 x 23.4 inches 권장)를 활용한 오프라인 학습 환경 구축

지속적인 업데이트​

갤러리는 2026년 3월 20일까지 업데이트되었으며, 새로운 모델이 출시될 때마다 지속적으로 추가됩니다. 부정확한 팩트시트나 링크 오류는 Architecture Gallery issue tracker를 통해 제보할 수 있습니다.

최근 추가된 모델 예시:

• Mistral Large 3 (673B)
• GLM-4.7 (355B)
• Nemotron 3 Super (120B-A12B)
• Arcee AI Trinity Large (400B)
• Sarvam (30B, 105B)

학습 커뮤니티와 지속적 성장​

Sebastian Raschka는 이 갤러리 외에도 "LLMs From Scratch" 코스, AI Newsletter, Reasoning Models 분석 등을 통해 LLM 생태계의 최신 지식을 공유하고 있습니다. LLM 아키텍처는 계속 진화하고 있으며, Frontier 모델을 사용하는 엔지니어도 내부 동작 원리를 이해함으로써 더 나은 프롬프트 엔지니어링, 파인튜닝 전략, 배포 최적화를 수행할 수 있습니다.

"다같이 평생 공부합시다"라는 원본 문서의 메시지처럼, 이 갤러리는 AI Research Engineer가 지속적으로 최신 아키텍처 트렌드를 따라가고 더 넓은 시각에서 LLM 기반 문제에 유연하게 대응할 수 있도록 돕는 살아있는 레퍼런스입니다.

References​

• LLM Architecture Gallery - Sebastian Raschka
• Architecture Gallery Issue Tracker
• LLM Architecture Gallery Poster - Redbubble
• Sebastian Raschka's Blog

TL;DR​

Claude Code 사용 시 context token을 압축하는 오픈소스 도구인 rtk-ai를 소개합니다. AI 코딩 어시스턴트를 활용할 때 불필요하게 많은 토큰이 소비되는 문제를 해결하여 비용 효율성을 높일 수 있습니다. 특히 대규모 코드베이스를 다루는 Research Engineer들에게 API 비용 절감과 성능 개선에 유용한 도구입니다.

Key Takeaways​

• Context Token 압축: Claude Code와 같은 AI 코딩 어시스턴트 사용 시 전송되는 컨텍스트 토큰을 압축하여 API 비용을 절감할 수 있습니다.
• 비용 최적화: 대규모 코드베이스나 긴 대화 세션에서 누적되는 토큰 비용을 효과적으로 관리할 수 있어, 반복적인 실험이 많은 연구 환경에서 특히 유용합니다.
• 오픈소스 접근성: 오픈소스로 제공되어 자체 환경에 맞게 커스터마이징하거나 내부 시스템과 통합할 수 있습니다.

상세 내용​

rtk-ai란?​

rtk-ai는 Claude Code와 같은 AI 코딩 어시스턴트를 사용할 때 발생하는 context token 소비를 최적화하기 위한 오픈소스 도구입니다. AI 모델에 코드 컨텍스트를 전달할 때, 불필요하거나 중복된 정보를 압축하여 전송함으로써 토큰 사용량을 줄이는 것이 핵심 기능입니다.

왜 Context Token 압축이 필요한가?​

AI Research Engineer들이 Claude Code와 같은 도구를 활용할 때 다음과 같은 상황에서 토큰 비용이 급증할 수 있습니다:

• 대규모 코드베이스: 전체 프로젝트 구조를 컨텍스트로 전달할 때
• 반복적인 쿼리: 비슷한 코드 블록을 여러 번 참조할 때
• 긴 대화 세션: 이전 대화 히스토리가 누적될 때
• 모델 실험: 다양한 프롬프트와 코드 변형을 테스트할 때

이러한 시나리오에서 토큰 압축은 실질적인 비용 절감으로 이어집니다.

활용 시나리오​

연구 코드 개발: 실험적인 모델 구현 시 반복적으로 코드를 수정하고 AI 어시스턴트와 대화하는 과정에서 비용을 절감할 수 있습니다.

코드 리뷰 및 리팩토링: 대규모 코드베이스의 특정 부분을 분석하거나 개선할 때, 필요한 컨텍스트만 효율적으로 전달할 수 있습니다.

문서화 및 설명 생성: 복잡한 연구 코드에 대한 문서를 AI로 생성할 때, 관련 코드만 선별적으로 압축하여 전달할 수 있습니다.

오픈소스의 장점​

rtk-ai가 오픈소스로 제공됨에 따라 다음과 같은 이점이 있습니다:

• 투명성: 토큰 압축 로직을 직접 확인하고 검증할 수 있습니다
• 커스터마이징: 특정 프로젝트나 팀의 니즈에 맞게 수정 가능합니다
• 통합 용이성: 기존 개발 워크플로우나 CI/CD 파이프라인에 통합할 수 있습니다
• 커뮤니티 기여: 개선 사항을 공유하고 다른 사용자들의 피드백을 받을 수 있습니다

도입 시 고려사항​

rtk-ai를 프로젝트에 도입할 때는 다음을 고려해야 합니다:

• 압축으로 인해 손실되는 컨텍스트 정보가 있는지 확인
• 특정 코드 패턴이나 프로젝트 구조에 최적화된 압축 설정
• 팀원들의 워크플로우와의 호환성
• 압축 효과와 실제 비용 절감 효과 측정

References​

• rtk-ai (오픈소스 프로젝트) - 원본 문서 참조

TL;DR​

AI 에이전트 생태계에서 파일시스템이 '영속적 기억 장치'로 재조명받고 있습니다. LLM의 컨텍스트 윈도우는 일시적인 화이트보드에 불과하지만, CLAUDE.md 같은 파일 기반 접근은 에이전트에게 장기 기억과 정체성을 제공합니다. Anthropic의 Agent Skills(SKILL.md) 포맷이 Microsoft, OpenAI, GitHub 등에 채택되며 사실상 표준으로 자리잡았고, 파일 포맷이 곧 API가 되는 '조율 없는 상호운용성' 시대가 열리고 있습니다. 다만 ETH Zürich 연구에 따르면 과도한 컨텍스트 파일은 오히려 성능을 저하시키므로, 최소한의 필수 요구사항만 담아야 합니다.

Key Takeaways​

• 파일시스템은 LLM의 일시적 컨텍스트 윈도우를 보완하는 가장 단순한 영속적 저장소입니다. Claude Code, Cursor 등 주요 AI 코딩 도구들이 파일 기반 컨텍스트 관리를 핵심 기능으로 채택했습니다.
• SKILL.md 포맷이 AI 에이전트 간 사실상 표준으로 부상하며, Microsoft, OpenAI, GitHub, Cursor가 Anthropic의 Agent Skills 포맷을 채택해 도구 간 컨텍스트 이식성을 확보했습니다.
• 과도한 컨텍스트는 독이 됩니다. ETH Zürich 연구 결과, 장황한 컨텍스트 파일은 태스크 성공률을 낮추고 추론 비용을 20% 이상 증가시킵니다. 최소한의 핵심 요구사항만 기술해야 합니다.
• 파일 포맷이 곧 API가 되는 시대: 마크다운 기반 스킬 파일은 특정 앱에 종속되지 않고 이동·조합·감사가 가능하며, MCP 서버나 플러그인 마켓플레이스 없이도 '조율 없는 상호운용성'을 달성합니다.
• LlamaIndex의 Jerry Liu가 제안한 원칙: 수백 개 도구를 가진 에이전트 하나보다, 파일시스템과 5~10개 핵심 도구만으로 구성된 에이전트가 더 범용적이고 효과적일 수 있습니다.

상세 내용​

왜 지금 파일시스템인가?​

AI 에이전트 생태계에서 파일시스템이 다시 주목받고 있습니다. LlamaIndex는 "Files Are All You Need"를 발표했고, LangChain은 에이전트의 파일시스템 기반 컨텍스트 엔지니어링을 다뤘으며, Oracle조차 에이전트 메모리 관리에서 파일시스템과 데이터베이스를 비교하는 글을 게시했습니다.

이 움직임의 핵심은 데이터베이스와는 다른 지속적 맥락 관리 수단으로서 파일시스템의 재발견입니다. Andrej Karpathy는 Claude Code가 성공한 이유를 "사용자의 컴퓨터·환경·데이터·컨텍스트 위에서 직접 실행되기 때문"이라고 지적하며, OpenAI의 클라우드 컨테이너 중심 접근이 잘못된 방향이었다고 평가했습니다.

실제로 Anthropic은 CLI 도구인 Claude Code가 수익의 상당 부분을 견인하면서 흑자에 근접하고 있으며, 현재 코딩 에이전트가 실질적 AI 활용 사례의 대부분을 차지하고 있습니다.

컨텍스트 윈도우의 한계: 화이트보드 vs 영속적 기억​

LLM의 컨텍스트 윈도우는 흔히 '기억'으로 오해되지만, 실제로는 계속 지워지는 화이트보드에 가깝습니다. 인간의 기억은 장기 저장, 선택적 회상, 불필요한 정보 망각 기능을 포함하지만, LLM은 이런 기능이 없습니다.

Claude Code를 사용하다 보면 "context left until auto-compact" 알림을 마주하게 됩니다. 이때 에이전트가 축적한 코드베이스, 선호도, 결정 사항 등의 컨텍스트가 압축되거나 소실됩니다. 파일시스템은 이를 가장 단순한 방식으로 해결합니다: 기록을 파일에 쓰고, 필요할 때 다시 읽는 것입니다.

실무에서 활용되는 예시:

• CLAUDE.md: 프로젝트에 대한 영속적 컨텍스트 제공
• Cursor의 채팅 히스토리: 과거 대화를 검색 가능한 파일로 저장
• aboutme.md: 개발자의 선호도, 기술 스택, 작업 스타일을 담은 이동 가능한 신원 기술자. API 조율 없이 앱 간 이동 가능

ETH Zürich 연구: 컨텍스트 파일의 역설​

ETH Zürich의 최근 논문은 리포지토리 수준의 컨텍스트 파일이 실제로 코딩 에이전트의 태스크 완수에 도움이 되는지 평가했습니다. 결과는 반직관적이었습니다.

주요 발견:

• 여러 에이전트와 모델에 걸쳐 컨텍스트 파일이 태스크 성공률을 오히려 낮춤
• 추론 비용은 20% 이상 증가
• 컨텍스트 파일을 받은 에이전트는 더 넓게 탐색하고, 더 많은 테스트를 실행하고, 더 많은 파일을 순회했지만, 정작 수정이 필요한 코드에 도달하는 것은 지연

이 현상의 원인은 파일이 에이전트가 지나치게 진지하게 따르는 체크리스트처럼 작동했기 때문입니다. 논문의 결론은 "컨텍스트 파일을 쓰지 말라"가 아니라, **"불필요한 요구사항이 태스크를 어렵게 만들며, 컨텍스트 파일은 최소 요구사항만 기술해야 한다"**는 것입니다.

문제는 파일시스템의 영속 계층 자체가 아니라, CLAUDE.md를 2,000단어짜리 온보딩 문서처럼 작성하는 관행입니다.

파일 포맷이 곧 API: 표준화의 여정​

현재 CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursorrules 등이 공존하며, 에이전트에 영속적 파일시스템 기반 컨텍스트가 필요하다는 점은 합의되었으나 파일 이름과 내용 형식은 아직 미합의 상태입니다.

Anthropic의 Agent Skills: 사실상 표준의 등장

Anthropic은 Agent Skills를 오픈 표준으로 발표하며 SKILL.md 포맷을 제안했습니다. 이는 빠르게 채택되어:

• Microsoft, OpenAI, Atlassian, GitHub, Cursor가 공식 채택
• Claude Code용으로 작성한 스킬이 Codex, Copilot에서도 작동
• 파일 포맷이 곧 API가 되는 패러다임 실현

Dan Abramov의 소셜 파일시스템 제안

Dan Abramov는 AT Protocol 기반 소셜 파일시스템을 제안하며 핵심 설계 원칙을 제시했습니다:

• 사용자 데이터를 개인 리포지토리 내 파일로 취급
• 앱들이 "포스트가 무엇인지" 합의할 필요 없이 도메인 네임 기반 네임스페이스로 충돌 방지
• 모든 앱의 데이터베이스는 파생 데이터, 즉 모든 사용자 폴더의 캐시된 구체화 뷰

실용적 사례: NanoClaw와 스킬 기반 아키텍처​

NanoClaw는 경량 개인 AI 어시스턴트 프레임워크로, 기능 대신 스킬 모델을 채택했습니다:

• Telegram 지원이 필요하면 Telegram 모듈이 아닌 /add-telegram 스킬(마크다운 파일)이 Claude Code에 통합 방법을 가르침
• 스킬은 파일이므로 이동 가능하고, 감사 가능하며, 조합 가능
• MCP 서버나 플러그인 마켓플레이스 불필요

이것이 조율 없는 상호운용성(interoperability without coordination)입니다. 두 앱이 마크다운을 읽을 수 있으면 컨텍스트를 공유할 수 있습니다.

LlamaIndex의 미니멀리즘: 도구보다 파일시스템​

LlamaIndex의 Jerry Liu는 흥미로운 주장을 펼쳤습니다:

"수백 개 도구를 가진 에이전트 하나 대신, 파일시스템과 5~10개 도구만으로 100개 이상의 MCP 도구를 가진 에이전트보다 더 범용적일 수 있다."

이는 에이전트 설계에서 복잡도를 줄이고 기본 인터페이스에 집중하라는 메시지입니다. 파일시스템은:

• 특정 앱에 종속되지 않음
• AI 에이전트 시대에 도구 간 전환, 워크플로 결합, 연속성 유지를 가능하게 하는 개방형 인터페이스

Archil과 POSIX 파일시스템​

Archil은 "에이전트가 POSIX 파일시스템을 원하기 때문에" 클라우드 볼륨을 구축 중이라고 밝혔습니다. 이는 에이전트가 표준 파일시스템 API를 통해 작동할 때 가장 효율적이며, 클라우드 환경에서도 이런 접근이 필요함을 시사합니다.

References​

• 파일시스템이 주목받는 이유 - GeekNews
• 원문: Why Files Are Having a Moment
• Anthropic Agent Skills Documentation
• LlamaIndex: Files Are All You Need
• ETH Zürich: Context Files in Code Agents Research
• Dan Abramov: AT Protocol Social Filesystem

TL;DR​

LLM Post Training은 사전학습된 언어 모델을 실제 사용 가능한 AI 어시스턴트로 변환하는 핵심 과정입니다. Supervised Fine-Tuning(SFT)으로 instruction-following 능력을 학습한 후, Reinforcement Learning from Human Feedback(RLHF)를 통해 인간의 선호도에 맞춰 모델을 정렬합니다. 최근에는 Direct Preference Optimization(DPO) 같은 방법으로 RL 없이도 효과적인 선호도 학습이 가능해졌으며, Rejection Sampling과 iterative training을 통해 지속적인 성능 개선을 달성할 수 있습니다.

Key Takeaways​

• Post Training은 3단계 프로세스: SFT → Reward Modeling → RL/DPO로 구성되며, 각 단계는 모델의 유용성(helpfulness)과 무해성(harmlessness)을 점진적으로 개선
• DPO는 RL의 실용적 대안: Reward model과 복잡한 RL 파이프라인 없이 preference pair 데이터만으로 직접 최적화 가능하여 구현 및 안정성 측면에서 유리
• Rejection Sampling으로 데이터 품질 향상: 모델이 생성한 여러 샘플 중 높은 reward를 받은 응답만 선별하여 SFT 데이터셋을 강화하는 self-improvement 기법
• Iterative training이 핵심: SFT와 RL/DPO를 반복적으로 수행하며, 매 iteration마다 새로운 데이터로 학습하여 모델의 지속적인 성능 향상 달성
• 실무 적용 시 trade-off 고려: Helpfulness와 harmlessness 간의 균형, 학습 안정성과 성능 간의 trade-off를 도메인 특성에 맞게 조정 필요

상세 내용​

Post Training의 전체 구조​

LLM Post Training은 사전학습(Pre-training)된 base model을 실제 사용자와 상호작용할 수 있는 대화형 AI로 변환하는 과정입니다. 사전학습 단계에서는 대규모 텍스트 코퍼스로 next-token prediction을 학습하지만, 이것만으로는 사용자의 지시를 따르거나 안전한 응답을 생성하기 어렵습니다.

Post Training은 크게 세 가지 주요 단계로 구성됩니다:

1. Supervised Fine-Tuning (SFT): Instruction-response 쌍으로 모델을 fine-tuning
2. Reward Modeling: 인간의 선호도를 학습하는 reward model 구축
3. Reinforcement Learning (RL) / Direct Preference Optimization (DPO): 선호도에 맞춰 모델 정렬

Supervised Fine-Tuning (SFT)​

SFT는 Post Training의 첫 번째 단계로, 고품질의 instruction-response 데이터셋을 사용하여 모델이 사용자의 요청을 이해하고 적절히 응답하는 능력을 학습합니다.

핵심 특징:

• 기존의 일반적인 supervised learning과 동일한 방식으로 학습
• 입력(instruction)과 출력(response) 쌍으로 구성된 데이터 필요
• 모델이 instruction-following 능력을 획득하는 기초 단계

SFT 데이터의 품질이 최종 모델의 성능을 크게 좌우합니다. 따라서 다양한 도메인과 태스크를 포괄하면서도 높은 품질을 유지하는 데이터셋 구축이 중요합니다.

Reward Model Training​

Reward Model은 인간의 선호도를 수치화하여 모델 응답의 품질을 평가하는 역할을 합니다. RLHF(Reinforcement Learning from Human Feedback)의 핵심 구성요소입니다.

학습 방식:

• 동일한 입력에 대해 여러 응답을 생성하고, 인간 평가자가 선호도를 매깁니다
• Preference pair 형태의 데이터: (prompt, chosen_response, rejected_response)
• Bradley-Terry 모델을 기반으로 ranking loss를 최소화하도록 학습

Reward Model은 이후 RL 단계에서 모델의 행동을 guide하는 신호로 사용되며, 인간의 피드백을 효율적으로 스케일업할 수 있게 해줍니다.

Reinforcement Learning from Human Feedback (RLHF)​

RLHF는 Reward Model을 활용하여 LLM을 인간의 선호도에 맞게 최적화하는 단계입니다. 주로 Proximal Policy Optimization (PPO) 알고리즘이 사용됩니다.

학습 프로세스:

1. SFT 모델에서 prompt에 대한 응답 생성
2. Reward Model이 생성된 응답의 점수를 평가
3. PPO를 통해 높은 reward를 받는 방향으로 policy 업데이트
4. KL divergence penalty를 추가하여 원본 SFT 모델로부터 너무 멀어지지 않도록 규제

장단점:

• 장점: 인간의 복잡한 선호도를 효과적으로 학습 가능
• 단점: 학습이 불안정하고, reward model, reference model, policy model 등 여러 모델을 동시에 관리해야 하는 복잡성

Direct Preference Optimization (DPO)​

![](https://prod-files-secure.s3.us-west-2.amazonaws.com/bb84b169-cb88-81fc-90c3-00032f05f905/75298940-c149-426f-81e4-cf709b8b691d/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=ASIAZI2LB4663GPPEBMS%2F20260325%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20260325T065709Z&X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEN%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLXdlc3QtMiJIMEYCIQDZrbugPUCbzgt%2FOXDqMwyPEqw4l91MjfgrjlbZGwwVXgIhAK%2Bv%2Bowqi17EMdRgWEvO%2B3PZIK2wacd%2B484IB8H5InLSKogECKf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEQABoMNjM3NDIzMTgzODA1IgzgVVeN9sn5VNRnpCcq3ANLPfIq5vvCnEMvmXjBH0xPG%2BdtFlb3BwYyNy9S1lWVhKBH%2FwUVnoToCFAbapCtJuzLJAVg%2Bc%2Fg48bDqjjdH6otZKAyqCSFQsIn6LXfV2OBJ2dgWUDjKQIW%2FsYQPhiGmFXfyKfPAInDlUAnjGio%2FyAUTB0YoekjhKU2pJSZfsCSv1fh7RbvrCgyye231Kdf3eet%2B7oKAUPJICqpfgTOxNHz8zXhNgwIMFnQGw1ygsWzxiPcd22vot1oa5QoOt9qdcVXhh9kvSHzlf%2ByFGoQ9fP%2Fy1csOeNVw05UHv%2FoajCTRYjUFAW86EzyGDdboqhSkK2CHWDZFfDgMjGunIffzGpkTGDl7%2BjrMbaNj1Syxsq8kafa6LQFaRxCJt8MBE47moH0mZATK%2FQiVvreFL5bQK9bshsO1jbhRT3zPyM3KUkpBfW9XfI0qCjbQj81hZ4n8spJ%2BE1MUvCV8K3dCzyaQi2h21EpuiRVBWlzxu34TRX5TBz9qrTnXnukzR8vS0M59Smv4Bhg%2BnTEujeeBEcYWFgF4sD8ITvusPpSsyGnoPStyWizCJh6kyKWHS6TvoKx%2FvDWbJajZbFlTz0nOnvTVTwwqWTnok8tzWRunkDag59Y54mfU1iVWkijj9CY%2FDC7%2FY3OBjqkAbP%2F2ef6A8887gUbu%2F80lGRhpzTHeaqoAq0Qw5F5YZCbx11ADz4cGXWG%2BbAF9tcmZG0i4eMiQU5CjnRNP1yjYUblP%2Bp2cLzcZhsYpMM%2FM08X%2F1sYR2LyanJsfczKYLpZxR%2

TL;DR​

AWS EC2에서 GPU 인스턴스를 프로비저닝하는 실무 가이드입니다. P/G/Inf 시리즈 등 인스턴스 타입 선택부터 AMI 설정, 네트워크 구성, 스토리지 최적화까지 GPU 워크로드 배포 시 필수적으로 고려해야 할 사항들을 단계별로 다룹니다. 특히 리전별 가용성, Deep Learning AMI 활용, 캐퍼시티 블록 구매 시 주의사항, 인스턴스 스토어의 임시성 등 실제 운영에서 마주칠 수 있는 함정들을 강조합니다.

Key Takeaways​

• 인스턴스 타입 선택의 중요성: P 시리즈(학습용), G 시리즈(추론/렌더링), Inf 시리즈(추론 최적화)를 목적에 맞게 선택해야 하며, 리전별 가용성 사전 확인 필수 (예: 서울 리전에서는 H100 인스턴스 불가)
• Deep Learning AMI 활용: NVIDIA 드라이버, CUDA, cuDNN이 사전 설치된 AMI를 사용하면 초기 설정 시간을 대폭 절약 가능
• 캐퍼시티 블록 구매 주의: GPU 경쟁 과열 시 1시간 단위 즉시 예약이며 환불 불가이므로 신중한 검토 필요
• 스토리지 전략: gp3/io2 EBS를 기본으로 사용하되, 인스턴스 스토어(NVMe)는 인스턴스 중지 시 데이터 손실되므로 임시 데이터(캐시, 버퍼)에만 활용
• 자원 최소화 원칙: GPU 인스턴스는 고비용 리소스이므로 사용 전 리뷰 프로세스를 거치고, 불필요한 가동 시간 최소화 필요

상세 내용​

GPU 리소스 사용 승인 프로세스​

GPU 인스턴스는 높은 비용이 발생하는 리소스이므로, 사용 전 내부 리뷰 프로세스를 통해 적절한 타입과 용량을 검증받아야 합니다. 이는 불필요한 자원 낭비를 방지하고 비용 효율성을 확보하기 위한 필수 단계입니다.

GPU 인스턴스 타입 이해​

AWS는 용도에 따라 구분된 GPU 인스턴스 패밀리를 제공합니다:

• P 시리즈 (P3, P4, P5): 머신러닝 학습 및 고성능 컴퓨팅(HPC)에 최적화. 대규모 모델 학습이나 분산 학습 워크로드에 적합
• G 시리즈 (G4dn, G5, G6): 그래픽 렌더링, 게임 스트리밍, ML 추론 등 그래픽 집약적 작업에 특화
• Inf 시리즈: Amazon 자체 Inferentia 칩을 사용한 ML 추론 최적화 인스턴스. 비용 대비 추론 성능이 우수

리전별 가용성 사전 확인​

모든 AWS 리전에서 모든 GPU 인스턴스 타입을 사용할 수 있는 것은 아닙니다. 특히 최신 GPU를 탑재한 인스턴스의 경우 제한적입니다.

중요 예시: ap-northeast-2(서울) 리전에서는 H100 1EA 인스턴스(p5.4xlarge) 사용이 불가능합니다. 프로젝트 시작 전 목표 리전에서 필요한 인스턴스 타입의 가용성을 반드시 확인해야 합니다.

AMI 선택 전략​

GPU 워크로드를 위한 인스턴스는 적절한 NVIDIA 드라이버, CUDA 툴킷, cuDNN 등이 사전 설치된 AMI를 사용하는 것이 권장됩니다.

권장 AMI:

• Deep Learning AMI (Ubuntu/Amazon Linux): NVIDIA 드라이버, CUDA, cuDNN이 사전 설치되어 있어 즉시 딥러닝 프레임워크 사용 가능
• AWS Marketplace의 GPU 최적화 AMI: PyTorch, TensorFlow 등 특정 프레임워크가 미리 설정된 이미지

일반 AMI를 선택하는 경우 NVIDIA 드라이버를 수동으로 설치해야 하므로 초기 설정 시간이 증가합니다.

인스턴스 생성 프로세스​

1. 인스턴스 타입 및 용량 결정​

GPU 리소스 검토 과정에서 승인받은 내역을 바탕으로 적절한 인스턴스 유형, VRAM 용량을 선택합니다.

![인스턴스 설정 4](https://prod-files-secure.s3.us-west-2.amazonaws.com/bb84b169-cb88-81fc-90c3-00032f05f905/576f9463-ab24-45ae-a26b-081dc9018a46/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=ASIAZI2LB466XOL2RWTI%2F20260325%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20260325T064504Z&X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEN%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLXdlc3QtMiJHMEUCIQDqPcWww2%2FpQ%2Be1RS0GoLH2PqRGairWhkf5VAqDzJjrDgIgDFxY3LBTm2DChRO06qiqQORa%2BTwwwAGB4Irhokw2nnkqiAQIp%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARAAGgw2Mzc0MjMxODM4MDUiDHWk54hH51hF8rmCtCrcA8SybE%2Bcehb2%2Bxjqq9d6ZrsWnzwPaWhd310kPdYge9qDhfuTquJLhuwQcydhVE3LkJeo8LjYfrE1noL6PPxX5KdYBS2OsUe822kgvtmslCvNWwl897%2Bdlw6A%2FKYpXBadSwsUbtdCmDM2CWy9UnqSPvc1MVuX26RJ7grJzCZ3FwJ%2BN0RioHjzyyQpgHNnBjzCOc5T0P639oKy%2F5%2B9vNAYW4BZqW5X5U50nf%2BhCk8%2F0It2nYhZm2fxi0jHp%2BybPeI2xY1lrcGM%2BB4M1dljm7C%2BdWI2CLLDe1%2FMwhQo5GX10j1ALiHiEBNN8aMePUlAek4CtbmJ7MxtRN1cPhkFfO7pqB1JLKI5PHvDlycWmHih%2BWftE6eJ3Es5DmY8zJ2GlrL6llNGp%2FujdYfYXfszKydwMys5s5FeurJ6IfhXC%2F24QdVJQnLjVJF6SSC29%2B1tF5Iy1gwSQr4K2bgHNkW6qBK%2FNG32gESCN9X6e2adDdyxh3Pe%2B99nKzDAZP9R72XRiOT2GYrwf9tmnGynn3cIQSn2Oc3f16V1srluXAUxx19tmZk39KFjMccQGUO37wfn5dfg6qcm%2BEHlqr3sS7aVdWgrWLKnx%2BN5tkREfAA0DRwnHAXJbwSgcbwIXb7iPkukMLv9jc4GOqUB%2BeM2AI%2BAgNC%2FLYyXnjFoaBm1dUwt%2FtgqITp8E8GcmhAxjiHbWr%2FBsOJShvWO2evdkrG8rq8Wo1o1kFTQBrkPgJGsf%2BSJSvM%2BSZvU1f9XQXFeR%2Bs%2B2oNARyVNv3RFxSbvy9pc84q8KCpgKOIL%2FidQ%2FWiTrZ7MK8ddm6oGiwh%2BheLj3BOrdd9mImjLSbeJBeG%2BcpT38ig

TL;DR​

AI Agent 시스템은 메신저 기반의 접근성(Manus Agents)부터 로컬 학습 시스템(PAI)까지 빠르게 진화 중입니다. 특히 메신저 환경에서 QR 코드 스캔만으로 동작하는 Manus Agents는 설정 복잡도를 제거하며 대중화를 노리고, PAI는 로컬 데이터 기반으로 사용자를 지속적으로 학습하는 개인 AI 비서를 제공합니다. 하지만 AI 코딩 도구 연구 결과는 상반됩니다 - 56% 생산성 향상과 19% 저하가 공존하며, 체감과 실제 성능의 괴리가 존재합니다. Agent 시스템의 실질적 효과는 작업 유형, 사용자 숙련도, 측정 방식에 따라 크게 달라집니다.

Key Takeaways​

• 메신저 기반 Agent의 전략적 전환: Manus Agents는 복잡한 설정 없이 QR 코드로 연결되며, 지속 메모리를 통해 사용자 스타일·선호도를 장기 학습합니다. 개발자 도구가 아닌 일상 커뮤니케이션 레이어로 AI를 확장하는 접근입니다.
• 생산성 측정의 복잡성: AI 코딩 도구는 실제 코딩 시간을 단축시키지만, 프롬프트 작성·검토·응답 대기 등 새로운 오버헤드를 생성합니다. 체감 생산성과 실측 데이터는 일치하지 않으며, 커밋 수 증가가 품질 향상을 의미하지 않습니다.
• 초급 개발자에게 더 큰 효과: 여러 연구에서 AI 도구는 초급 개발자의 속도를 더 크게 향상시킵니다. 이는 "AI가 있으니 주니어 채용 불필요"가 아니라 "주니어+AI 조합이 최대 효과"를 의미합니다.
• 로컬 우선 개인화 시스템: PAI는 모든 대화·작업을 로컬에 저장하는 3계층 메모리 구조(Hot/Warm/Cold)로 프라이버시를 보호하며, 모듈러 스킬 팩 시스템으로 필요한 기능만 선택적으로 확장할 수 있습니다.
• 속도보다 지속 가능성: Continuous Delivery 관점에서 AI 도구의 가치는 단순 속도가 아니라 "안전하게 빠르게 지속 가능하게" 전달하는 능력에 있습니다. 코드 리뷰·품질 단계 생략은 장기적 기술 부채를 초래합니다.

상세 내용​

메신저 기반 AI Agent의 부상: Manus Agents​

실리콘밸리를 중심으로 AI Agent 경쟁이 격화되고 있습니다. Meta가 약 20억 달러에 인수한 Manus는 복잡한 설정을 제거하고 메신저 환경에서 작동하는 개인 AI Agent를 제시합니다.

기존 시스템의 한계와 Manus의 차별점​

OpenClaw와 같은 기존 개인 AI Agent는 강력한 기능을 제공하지만, 설정 과정의 복잡성과 유지 관리 부담이 진입 장벽으로 작용했습니다. Manus Agents는 이를 다음과 같이 해결합니다:

구분	OpenClaw	Manus Agents
설정 난이도	복잡	QR 기반 간편 연결
유지 관리	필요	최소화 지향
사용 환경	별도 시스템 중심	메신저 중심
타깃 사용자	고급 사용자	일반 사용자 포함

초기에는 Telegram을 통해 출시되며, 향후 WhatsApp, LINE, Slack, Discord, Messenger로 확장될 예정입니다. Windows 및 Mac용 네이티브 애플리케이션도 준비 중입니다.

핵심 기술 특징​

1. 지속 메모리 기반 개인화 시스템

Manus Agents는 단발성 질의응답이 아닌 장기적 컨텍스트 유지를 핵심으로 합니다. 시스템은 사용자의 글쓰기 스타일, 어조, 개인 선호도를 지속적으로 학습하며, 이렇게 학습된 패턴은 이후 새로운 작업에 자동으로 반영됩니다.

2. 멀티스텝 작업 자동 실행

사용자가 "발표 자료 생성" 또는 "웹사이트 프로그래밍"과 같은 메시지를 보내면, AI는 내부적으로 작업 단계를 계획하고 실행합니다. 각 단계를 수동으로 지시할 필요가 없습니다.

3. 외부 서비스 연동

Gmail, Google Calendar, Notion 등 외부 서비스에 접근하여 메시지 맥락을 분석해 필요한 작업을 자동으로 수행합니다. 사용자는 별도의 파일 관리나 API 설정을 직접 다루지 않아도 됩니다.

보안 설계와 접근 권한​

Manus는 프라이버시 우려를 최소화하기 위해 제한적 접근 권한을 설계했습니다:

• AI는 자신의 채팅 기록 내 직접 메시지만 읽음
• 다른 대화, 그룹, 연락처 목록에는 접근 불가

사용자 커스터마이징 옵션​

모델 선택:

• Manus 1.6 Max: 심층 사고 중심
• Manus 1.6 Lite: 빠른 작업 처리

응답 스타일:

• 간결한 스타일
• 구조화된 스타일
• 대화형 스타일

또한 Telegram 내에서 음성 메시지(자동 전사 및 의도 분석), 이미지(내용 해석), 문서 파일(즉시 분석 및 작업 수행) 등 멀티미디어를 직접 처리합니다.

로컬 우선 개인 AI 인프라: PAI​

PAI(Personal AI Infrastructure)는 보안 전문가이자 AI 연구자인 Daniel Miessler가 개발한 오픈소스 개인 AI 인프라입니다. GitHub에서 7,300개 이상의 스타를 보유하고 있으며, MIT 라이선스로 무료 공개되어 있습니다.

PAI의 핵심 차별점: "AI가 나를 학습한다"​

일반 AI 챗봇과 달리 PAI는 모든 대화와 작업 결과를 로컬에 저장하고, 이를 통해 사용자의 선호도, 작업 스타일, 프로젝트 맥락을 지속적으로 학습합니다. 새로운 대화를 시작할 때마다 배경을 처음부터 설명할 필요가 없어집니다.

3계층 메모리 시스템​

계층	설명	접근 속도
Hot Data	현재 세션에서 사용 중인 정보	빠름
Warm Data	이전 세션들의 대화 기록	중간
Cold Data	오래된 정보지만 중요한 것	느림 (백업용)

이 구조 덕분에 다음이 가능합니다:

• "지난주에 우리가 만들었던 파이썬 함수를 다시 보여줘" → 로컬 저장소에서 즉시 검색
• "내가 선호하는 코드 스타일이 뭐지?" → 과거 작업 패턴 분석으로 자동 파악
• "이 프로젝트에서 우리가 어떤 의사결정을 했었지?" → 모든 의사결정 기록 검색

모듈러 스킬 팩 시스템​

PAI는 필요한 기능을 선택적으로 추가/제거할 수 있는 스킬 팩을 제공합니다:

스킬 팩	기능	난이도
Art Skill	AI 이미지 생성, 디자인	초급
Research Skill	웹 검색, 정보 수집, 데이터 분석	초급
Browser Skill	웹 자동화, 스크래핑	중급
Red Team Skill	보안 분석, 취약점 진단	고급
Algorithm Skill	7단계 문제 해결 프레임워크	중급

기타 핵심 기능​

• 훅 시스템: 작업 전후에 자동 실행되는 사용자 정의 스크립트 (예: 코드 작성 전 보안 검사, 완료 후 자동 커밋)
• 알고리즘: 관찰→생각→계획→실행→검증→학습의 7단계 문제 해결 프로세스
• 음성 알림: ElevenLabs TTS 연동으로 작업 진행 상황을 음성으로 안내

기술 요구사항​

• 운영체제: macOS, Linux (WSL2 포함), Windows(WSL2)
• Node.js: v18 이상
• 메모리: 최소 8GB RAM (16GB 권장)
• 디스크: 최소 2GB 여유 공간
• Claude Code: Anthropic AI 계정 및 설치 필요

PAI는 TypeScript로 개발되었으며, 2025년 9월 공개 이후 일일 평균 46.8개의 스타를 기록하며 빠르게 성장 중입니다.

AI 코딩 도구의 생산성 논쟁: 56% vs 19%​

AI 코딩 도구의 실제 효과에 대해 상반된 연구 결과가 제시되고 있습니다.

56% 빨라졌다: GitHub 협업 실험 (2023)​

Microsoft Research, GitHub, MIT의 협업 실험에서 개발자에게 JavaScript로 HTTP 서버를 구현하는 과제를 부여했습니다:

• AI 사용 그룹: 평균 71분
• 비사용 그룹: 평균 161분
• 결과: 약 55.8% 더 빠름

특히 초급 개발자에게서 속도 향상이 두드러졌으며, 과제 성공률은 두 그룹 간 큰 차이가 없었습니다.

연구의 한계:

• 도구 공급사가 실험 설계에 참여
• 통제된 환경의 단일 과제 중심
• 실제 복잡한 프로젝트와는 상황이 다름

19% 느려졌다: METR의 현실 프로젝트 분석 (2025)​

METR 연구는 실제 오픈소스 프로젝트에서 16명의 개발자가 수행한 246개 작업을 분석했습니다:

• 전체 작업 완료 시간: 평균 19% 증가

세부 변화:

• ✅ 실제 코딩 시간 감소
• ✅ 검색, 테스트, 디버깅 시간 감소
• ❌ 새로운 작업 유형 증가: AI 출력 검토, 프롬프트 작성, 응답 대기
• ❌ 오버헤드 시간 증가

인지 편향의 함정: 흥미롭게도 개발자들은 실제로는 19% 느려졌음에도 "AI가 시간을 절약해줬다"고 체감했습니다. 이는 멀티태스킹이 생산성을 높인다고 믿었던 과거의 인지 편향과 유사합니다.

Multitudes 연구의 복잡성 (2025)​

10개월간의 데이터 분석 결과:

• 코드 변경 수 증가
• 근무 시간 외 커밋도 함께 증가

이는 두 가지 해석이 가능합니다:

1. AI 덕분에 처리량이 증가했다
2. 안정성을 희생하면서 속도를 올렸다

야간 커밋 증가는 새로운 기능 개발이 아니라 오류 수정이나 불안정성 대응일 가능성도 있습니다. 단순히 커밋 수 증가 = 생산성 증가로 볼 수 없다는 점을 시사합니다.

초급 개발자에게 더 큰 효과​

여러 연구에서 반복적으로 나타나는 패턴:

• AI 코딩 도구는 초급 개발자에게 더 큰 효과를 제공
• 숙련 개발자에게는 상대적으로 효과가 제한적

장기적 인재 구조 영향:

일부 조직은 "AI가 있으니 주니어를 채용하지 않아도 된다"는 판단을 내리고 있습니다. 그러나 연구 결과는 오히려 주니어 개발자가 AI와 함께 사용할 때 가장 큰 속도 향상을 보인다고 말합니다.

단기적 비용 절감이 장기적 인재 부족으로 이어질 가능성이 있으며, 이는 닷컴 버블 이후 주니어 채용 중단으로 숙련 개발자 부족 현상이 발생했던 사례와 유사할 수 있습니다.

속도보다 지속 가능성: Continuous Delivery의 관점​

일부에서는 AI로 생성된 코드를 빠르게 배포하기 위해 코드 리뷰나 품질 단계를 줄이자는 주장도 제기됩니다. "속도가 곧 경쟁력"이라는 논리입니다.

그러나 **지속적 전달(Continuous Delivery)**의 관점은 다릅니다. 핵심은 단순한 속도가 아니라:

1. 안전하게 빠르게
2. 지속 가능하게 빠르게
3. 품질을 유지하며 빠르게

코드 리뷰와 품질 단계 생략은:

• 단기적으로는 배포 속도를 높일 수 있음
• 장기적으로는 기술 부채와 유지보수 비용 증가
• 시스템 안정성 저하와 보안 취약점 증가

생산성은 체감이 아니라 데이터로 판단해야 하며, AI 도구의 가치는 장기적 코드 품질과 팀 역량 유지 여부로 측정되어야 합니다.

AI Agent 시스템의 진화 방향​

현재 AI Agent 시스템은 다음과 같은 방향으로 진화하고 있습니다:

1. 접근성 향상

• 복잡한 설정 제거 (QR 코드, 메신저 기반)
• 전문 개발자가 아닌 일반 사용자 타깃

2. 맥락 지속성 강화

• 지속 메모리 시스템
• 로컬 데이터 기반 학습
• 장기적 사용자 이해

3. 플랫폼 확장

• 단일 환경에서 다중 플랫폼으로 (Telegram → WhatsApp, Slack 등)
• 메신저와 업무용 소프트웨어의 경계 약화

4. 실행 능력 확대

• 대화형 응답에서 실제 소프트웨어 제어로
• 멀티스텝 작업 자동화
• 외부 서비스 통합

5. 프라이버시 우선 설계

• 로컬 데이터 저장
• 제한적 접근 권한
• 사용자 통제 강화

References​

• 메신저 안에서 완성하는 개인 AI 에이전트 경쟁: Manus Agents와 OpenClaw의 전략 분석
• AI 코딩 도구는 개발자를 56% 빠르게 만들까, 19% 느리게 만들까? 상반된 연구 결과로 본 생산성의 진실
• 완전 무료! GitHub 9k! 나를 학습하는 PAI로 개인 AI 비서 구축하기
• PAI GitHub Repository

TL;DR​

RAG에서 AI Agent로 빠르게 전환되는 시점에서, 실무자는 LLM·RAG·Agent의 본질적 개념을 정확히 이해해야 한다. Gen.AI 서비스는 기술·BM·아키텍처 관점에서 다층적으로 분류되며, 기존 서비스 대비 복잡도가 높다. 효과적인 서비스 구축을 위해서는 서비스를 명확히 정의하고, Product·Data·RAG 팀이 각자의 전문성을 기반으로 역할을 분업화해야 한다.

Key Takeaways​

• 기술 트렌드 이해: RAG는 이미 정착되었으나 Agent 중심으로 빠르게 전환 중이며, 실무자는 각 기술의 본질적 차이와 적용 시점을 명확히 구분해야 한다.
• 서비스 분류 체계: Gen.AI 서비스는 기술 관점(Content-Centric, Conversational, Automation 등 6가지)과 BM 관점(B2B/B2C × SaaS/IaaS/PaaS)으로 분류 가능하며, 자사 서비스의 위치를 파악하는 것이 전략 수립의 출발점이다.
• 4-Layer 아키텍처: Gen.AI 서비스는 Application, Platform, Model, Infrastructure 4개 레이어로 구성되며, 기존 서비스 대비 복잡성이 높아 레이어별 역할 정의가 중요하다.
• 전문성 기반 분업: Product(개발·운영), Data(파이프라인), RAG(기술 연구·적용) 팀이 각자의 전문 영역에 집중하는 것이 스타트업 환경에서도 효율적이다.
• 문제 진단 역량: 표면적 기술 적용보다 개념 이해가 선행되어야 실전에서 신속정확한 문제 진단과 대응이 가능하다.

상세 내용​

AI Service 이해의 중요성​

AI 기술의 발전 속도는 가속화되고 있다. RAG(Retrieval Augmented Generation)는 이미 많은 실무자에게 익숙한 개념이 되었지만, 투입 리소스 대비 성능 향상에 대한 고도화는 여전히 진행 중이다. 그럼에도 불구하고 업계는 AI Agent를 향해 빠르게 움직이고 있다.

이러한 빠른 전환 과정에서 실무자들이 간과하기 쉬운 점이 있다. LLM, RAG, Agent의 본질적 개념과 특징에 대한 깊이 있는 이해 없이 서비스 구축에만 집중하는 경우가 많다는 것이다. 이는 문제 상황에서 신속정확한 대처를 어렵게 만들고, 심각한 경우 명확한 문제 진단조차 불가능하게 만든다.

본 문서는 실무자가 마주하는 AI Service의 개괄적 특징과 명확히 알아야 할 본질적 개념을 정리하여, 실전에서 활용 가능한 참고 자료를 제공하고자 한다.

Gen.AI Service의 분류 체계​

기술 관점에서의 분류​

현존하는 생성형 AI 서비스는 기술적 특성에 따라 6가지 유형으로 구분할 수 있다:

구분	설명	대표 서비스
Content-Centric	텍스트·이미지·영상·음성 등 콘텐츠를 생성·편집·변환	Midjourney, ElevenLabs
Conversational	자연어 기반 대화를 통한 질의응답, 상담, 업무 지원	ChatGPT, Perplexity AI
Automation	반복적·규칙적 업무를 AI 기반으로 자동 수행	UiPath AI Center
Platform	AI 모델·API·개발환경 등을 제공하는 인프라형 서비스	AWS Bedrock
Insight Driven	데이터 분석을 통한 예측, 의사결정 지원, 인사이트 도출	Palantir AIP
Hybrid	앞선 특징들이 적절히 혼합된 복합형 서비스	Microsoft 365 Copilot, n8n, Dify

자사 서비스가 어느 유형에 속하는지, 혹은 여러 유형의 특성을 조합하고 있는지 파악하는 것이 서비스 전략 수립의 첫 단계다.

비즈니스 모델 관점에서의 분류​

Gen.AI 서비스는 타겟 고객과 제공 형태에 따라 다음과 같이 분류할 수 있다:

	SaaS	IaaS	PaaS
B2B	기업용 AI 업무자동화 SaaS (예: DeepL Pro)	GPU 클라우드, AI 서버 인프라 제공 (예: AWS EC2 GPU)	AI 모델 API, 개발 플랫폼 제공 (예: Anthropic API)
B2C	개인용 생성형 AI 구독 서비스 (예: Duolingo Max, Canva AI)	직접 소비자 대상 인프라 제공은 제한적 (예: Runpod)	크리에이터용 AI 개발툴, 노코드 AI 제작 플랫폼 (예: Zapier AI)

이 분류를 통해 자사 서비스의 수익 모델과 경쟁 구도를 명확히 이해할 수 있다.

아키텍처 관점: 4-Layer 구조​

Gen.AI 서비스는 BM과 특성이 다양하더라도, 기본적으로 4개의 레이어로 구성된 아키텍처를 따른다:

1. Application Layer

• 실제 고객과 직접 접점을 형성하는 레이어
• 서비스의 접근 형태(B2B, B2C), UI/UX, 사용자 경험을 담당
• 고객의 요구사항이 시스템으로 전달되는 진입점

2. Platform Layer

• 비즈니스 로직과 AI 기능을 연결하는 중간 레이어
• API 게이트웨이, 오케스트레이션, 워크플로우 관리 등을 담당
• RAG, Agent와 같은 AI 기능이 실제로 구현되는 영역

3. Model Layer

• LLM, Embedding 모델 등 AI 모델이 위치하는 레이어
• 모델 선택, 파인튜닝, 프롬프트 엔지니어링이 이루어지는 영역
• 서비스의 AI 성능을 직접 결정하는 핵심 레이어

4. Infrastructure Layer

• GPU, 스토리지, 네트워크 등 물리적·클라우드 인프라
• 모델 서빙, 스케일링, 모니터링을 지원
• 비용과 성능의 트레이드오프가 결정되는 레이어

Gen.AI 서비스는 이 4개 레이어가 유기적으로 연결되어야 하며, 기존 서비스 대비 복잡성이 높다. 각 레이어의 역할을 명확히 이해하고 레이어 간 인터페이스를 잘 설계하는 것이 중요하다.

실무자의 역할 분담​

회사가 올바른 방향성을 가지고 시너지를 극대화하려면, 각 팀의 실무자가 전문성을 기반으로 명확한 역할을 수행해야 한다. 다음은 효과적인 역할 분담의 예시다:

Product Team

• 서비스 기능의 직접 개발
• 배포된 서비스의 전반적인 유지보수, 운영, 대응
• 고객 피드백 수렴 및 기능 개선

Data Team

• 서비스 기능에 필요한 데이터 수급 및 전처리
• 데이터 레이크, 파이프라인 등 전반적인 데이터 인프라 운용/관리
• 데이터 품질 관리 및 거버넌스

RAG Team

• RAG/Agent에 대한 지엽적인 기술 연구
• 연구 결과를 바탕으로 한 서비스 적용 및 반영
• 프롬프트 엔지니어링, 모델 최적화 등 AI 성능 개선

물론 스타트업 환경에서는 인력 규모의 제약으로 인해 역할의 경계가 모호할 수 있다. 하지만 LLM, RAG, Agent는 기존 방식과 다른 특성을 가지고 있기 때문에, 모든 팀원이 표면적인 부분만 다루기보다는 각 팀이 강점을 가진 영역에 집중하여 전문성을 높이는 것이 장기적으로 효과적이다.

서비스 정의의 중요성​

모든 논의의 출발점은 "만들고 운용하고자 하는 서비스의 명확한 정의"다. 서비스의 기술적 분류, BM, 아키텍처, 타겟 고객을 명확히 정의하지 않으면 팀 간 협업이 비효율적이고 방향성이 흐려진다.

서비스 정의가 명확해지면:

• 각 팀이 집중해야 할 우선순위가 분명해진다
• 레이어별 책임 영역이 구분되어 병목 지점 파악이 쉬워진다
• 기술 선택과 투자 결정이 데이터 기반으로 이루어진다
• 문제 발생 시 근본 원인 분석과 빠른 대응이 가능하다

References​

• 원본 문서: 여러분은 AI Service에 대해 얼마나 알고 계신가요?

TL;DR​

LLM 서빙에 필요한 GPU 메모리는 M = (P × 4B × Q) / 32 × 1.2 공식으로 계산할 수 있습니다. 여기서 P는 파라미터 수, Q는 정밀도(16 or 32bit), 1.2는 추론 시 활성화 함수 등을 위한 20% 오버헤드입니다. 예를 들어 70B 파라미터 모델을 16-bit로 서빙하려면 약 168GB GPU 메모리가 필요하며, 이는 80GB A100 GPU 2대에 해당합니다. 프로덕션 환경에서 LLM 배포 시 하드웨어 리소스를 정확히 예측하는 것은 비용 최적화와 서비스 안정성 확보에 필수적입니다.

Key Takeaways​

• 메모리 추정 공식 숙지: M = (P × 4B × Q) / 32 × 1.2를 이해하면 모델 배포 전 필요한 GPU 리소스를 정확히 예측하여 인프라 비용을 최적화할 수 있습니다
• 정밀도 선택의 중요성: 16-bit precision을 사용하면 32-bit 대비 메모리 사용량을 절반으로 줄이면서도 대부분의 경우 충분한 정확도를 유지할 수 있습니다
• 20% 오버헤드는 필수: 추론 중 활성화 함수, 중간 결과물, KV 캐시 등을 위한 추가 메모리를 반드시 고려해야 실제 운영 환경에서 OOM 에러를 방지할 수 있습니다
• 멀티-GPU 전략 필요: 대규모 모델(70B+)은 단일 GPU로 서빙이 불가능하므로, 모델 병렬화(Model Parallelism)나 텐서 병렬화(Tensor Parallelism) 전략을 미리 계획해야 합니다

상세 내용​

GPU 메모리 추정이 중요한 이유​

LLM 인터뷰에서 가장 자주 등장하는 질문 중 하나는 "LLM 서빙에 얼마나 많은 GPU 메모리가 필요한가?"입니다. 이는 단순한 암기 문제가 아니라, 프로덕션 환경에서 모델의 배포 가능성과 확장성을 이해하고 있는지를 평가하는 핵심 지표입니다.

GPT, LLaMA 등의 대규모 언어 모델을 다룰 때, 필요한 GPU 메모리를 정확히 예측하는 능력은 필수적입니다. 7B 파라미터 모델이든 그 이상의 대규모 모델이든, 하드웨어 리소스를 올바르게 산정하는 것은 성공적인 배포의 핵심입니다.

GPU 메모리 추정 공식​

LLM 서빙에 필요한 GPU 메모리는 다음 공식으로 계산할 수 있습니다:

공식 구성 요소:

• M: GPU 메모리 (Gigabytes)
• P: 모델의 파라미터 수
• 4B: 파라미터당 4바이트
• Q: 모델 로딩 시 사용하는 비트 수 (16-bit 또는 32-bit)
• 1.2: 20% 오버헤드

공식의 각 구성 요소 상세 분석​

파라미터 수 (P)​

모델의 크기를 나타내는 핵심 지표입니다. 예를 들어 LLaMA 70B 모델은 700억 개의 파라미터를 가지고 있으므로 P = 70,000,000,000이 됩니다. 모델 크기가 클수록 더 많은 메모리가 필요합니다.

파라미터당 바이트 (4B)​

각 파라미터는 일반적으로 4바이트의 메모리를 차지합니다. 이는 부동소수점 연산에서 표준적으로 사용되는 32비트(4바이트) 정밀도를 기반으로 합니다. Half-precision(16비트)을 사용할 경우 이 값은 조정됩니다.

비트 정밀도 (Q)​

• 32-bit (Full Precision): 가장 높은 정확도를 제공하지만 메모리 사용량이 큽니다
• 16-bit (Half Precision): 메모리 사용량을 절반으로 줄이면서도 대부분의 LLM 배포에서 충분한 정확도를 유지합니다
• 많은 LLM 배포에서 16-bit precision이 표준으로 사용되는 이유는 메모리 효율성과 정확도 사이의 최적 균형점이기 때문입니다

오버헤드 (1.2)​

1.2 배수는 단순한 안전 버퍼가 아닙니다. 이는 추론 과정에서 실제로 필요한 추가 메모리를 고려한 것입니다:

• 활성화 함수(Activations): 각 레이어를 통과하며 생성되는 중간 결과물
• KV 캐시: Attention 메커니즘에서 사용되는 Key-Value 캐시
• 그래디언트 및 옵티마이저 상태: 파인튜닝 시 추가로 필요
• 기타 시스템 오버헤드: CUDA 컨텍스트, 드라이버 메모리 등

실전 계산 예시: LLaMA 70B 모델​

70B 파라미터를 가진 LLaMA 모델을 16-bit precision으로 서빙하는 경우를 계산해보겠습니다:

이를 단순화하면:

결과: 약 168GB의 GPU 메모리가 필요합니다.

실무적 함의와 하드웨어 선택​

이 계산은 단순한 이론이 아니라 실제 배포에서 중요한 의사결정 근거가 됩니다:

• 단일 GPU 한계: NVIDIA A100 80GB 단일 GPU로는 이 모델을 서빙할 수 없습니다
• 멀티-GPU 필요: 최소 80GB A100 GPU 2대가 필요합니다
• 대안적 접근:
  • 모델 병렬화(Model Parallelism)를 통한 분산 배포
  • 양자화(Quantization)를 통한 메모리 사용량 감소 (예: 8-bit, 4-bit)
  • 효율적인 Attention 메커니즘 적용 (Flash Attention 등)

비용 최적화를 위한 고려사항​

이 공식을 마스터하면:

1. 인터뷰에서 자신감 있게 답변 가능
2. 배포 전 정확한 하드웨어 요구사항 산정으로 예산 낭비 방지
3. 확장 가능한 아키텍처 설계를 위한 기반 마련
4. 프로덕션 환경에서 OOM 에러 등 치명적인 병목 현상 사전 방지

다음 LLM 배포를 계획할 때, 이 공식을 활용하여 필요한 GPU 메모리를 정확히 추정하고, 효율적이고 안정적인 서비스를 구축할 수 있을 것입니다.

References​

• How Much GPU Memory is Needed to Serve a Large Language Model (LLM)? - Mastering LLM

TL;DR​

OpenAI는 ChatGPT와 API를 지원하기 위해 단일 Primary PostgreSQL 인스턴스와 50개의 Read Replica를 활용해 80만 사용자를 지원하며, 연간 10배 이상의 트래픽 증가를 처리하고 있습니다. MVCC(Multi-Version Concurrency Control)의 write amplification 문제를 완화하기 위해 write-heavy 워크로드를 샤딩된 시스템(Azure Cosmos DB)으로 마이그레이션하고, 쿼리 최적화, 워크로드 격리, 연결 풀링, 캐싱 등의 최적화를 통해 PostgreSQL을 초당 수백만 쿼리를 처리하는 규모로 확장했습니다. 이는 적절한 엔지니어링과 최적화를 통해 단일 Primary 아키텍처로도 대규모 read-heavy 워크로드를 충분히 지원할 수 있음을 증명합니다.

Key Takeaways​

• 단일 Primary 아키텍처의 가능성: Read-heavy 워크로드에 대해서는 샤딩 없이도 Primary 하나와 다수의 Read Replica로 대규모 트래픽을 처리할 수 있으며, 이는 샤딩에 수반되는 복잡한 애플리케이션 변경을 피할 수 있게 함
• MVCC의 근본적 한계 이해: PostgreSQL의 MVCC 구현은 update 시 전체 row를 복사하여 write/read amplification을 유발하고, dead tuple, table bloat, autovacuum 튜닝 등 운영 복잡도를 증가시키므로 write-heavy 워크로드는 다른 시스템으로 분리해야 함
• 계층화된 트래픽 관리: 우선순위 기반 워크로드 격리, PgBouncer를 통한 연결 풀링, 캐시 락/리스 메커니즘을 통해 트래픽 급증 시 cascading failure를 방지하고 시스템 안정성을 확보할 수 있음
• 쿼리 최적화의 중요성: ORM이 생성한 다중 테이블 조인(12개 테이블 조인 사례)과 같은 expensive query 하나가 전체 서비스 장애를 유발할 수 있으므로, 복잡한 join은 애플리케이션 레이어로 이동하고 SQL 동작을 엄격히 검토해야 함
• 단일 장애 지점(SPOF) 완화 전략: 대부분의 critical read를 replica로 오프로드하고, HA 모드로 hot standby를 운영하며, 각 region에 충분한 headroom을 가진 다수의 replica를 배치하여 Primary 장애 시에도 read 서비스는 유지할 수 있도록 설계

상세 내용​

OpenAI의 PostgreSQL 스케일링 여정​

OpenAI는 수년간 PostgreSQL을 ChatGPT와 API의 핵심 데이터 시스템으로 운영해왔습니다. 사용자 기반이 급격히 증가하면서, 지난 1년간 PostgreSQL 부하는 10배 이상 증가했고 계속해서 빠르게 상승하고 있습니다.

이러한 성장을 지탱하기 위한 프로덕션 인프라 개선 작업을 통해 새로운 인사이트를 얻었습니다: PostgreSQL은 많은 사람들이 생각했던 것보다 훨씬 더 큰 read-heavy 워크로드를 안정적으로 지원할 수 있도록 확장 가능합니다.

현재 OpenAI는 단일 Primary Azure PostgreSQL Flexible Server 인스턴스와 전 세계 여러 region에 분산된 약 50개의 read replica를 통해 8억 명의 사용자를 위한 대규모 글로벌 트래픽을 지원하고 있습니다. Azure Database for PostgreSQL은 완전 관리형 서비스로서 compute와 storage를 분리한 아키텍처를 제공하며, zone redundant 고가용성을 지원하여 동일 Azure region 내 availability zone 간 동기식 복제를 통해 무손실 failover를 가능하게 합니다.

초기 설계의 한계​

ChatGPT 출시 후 트래픽이 전례 없는 속도로 증가했습니다. 이를 지원하기 위해 애플리케이션과 PostgreSQL 데이터베이스 레이어 모두에서 광범위한 최적화를 신속히 구현했고, 인스턴스 크기를 늘리는 scale-up과 read replica를 추가하는 scale-out을 수행했습니다.

단일 Primary 아키텍처가 OpenAI 규모의 요구사항을 충족시킬 수 있다는 것은 놀랍게 들릴 수 있지만, 실제로 이를 작동시키는 것은 단순하지 않습니다. PostgreSQL 과부하로 인한 여러 심각한 장애(SEV)를 경험했으며, 이들은 종종 동일한 패턴을 따릅니다:

• 캐싱 레이어 장애로 인한 광범위한 캐시 미스
• CPU를 포화시키는 expensive 다중 조인(multi-way join) 급증
• 새 기능 출시로 인한 write storm

리소스 사용률이 증가하면 쿼리 지연시간이 늘어나고 요청이 타임아웃되기 시작합니다. 재시도는 부하를 더욱 증폭시키고, 전체 ChatGPT 및 API 서비스를 저하시킬 수 있는 악순환을 촉발합니다.

PostgreSQL MVCC의 문제점​

PostgreSQL은 read-heavy 워크로드에 대해 잘 확장되지만, write 트래픽이 많은 기간에는 여전히 어려움을 겪습니다. 이는 주로 PostgreSQL의 MVCC(Multi-Version Concurrency Control) 구현 때문입니다.

MVCC의 기본 개념은 DBMS가 여러 쿼리가 가능한 한 서로 간섭 없이 동시에 데이터베이스에 읽고 쓸 수 있도록 하는 것입니다. 쿼리가 실행될 때 DBMS는 트랜잭션이 시작된 시점의 데이터베이스 스냅샷을 관찰합니다(snapshot isolation). 이 접근 방식은 reader가 데이터에 접근하는 것을 차단하는 명시적인 레코드 락의 필요성을 제거합니다.

그러나 PostgreSQL의 MVCC 구현에는 심각한 문제가 있습니다:

Write Amplification: 쿼리가 tuple을 업데이트하거나 단일 필드만 수정할 때도 전체 row를 복사하여 새 버전을 생성합니다. Write가 많은 워크로드에서는 상당한 write amplification이 발생합니다.

Read Amplification: 쿼리가 최신 버전을 검색하기 위해 여러 tuple 버전(dead tuple)을 스캔해야 하므로 read amplification도 증가합니다.

운영 복잡도: Table과 index bloat, index 유지관리 오버헤드 증가, 복잡한 autovacuum 튜닝 등 추가적인 문제를 야기합니다.

Carnegie Mellon University의 Andy Pavlo 교수와 함께 작성한 블로그 "The Part of PostgreSQL We Hate the Most"에서 이러한 이슈에 대한 심층 분석을 제공하고 있으며, 이는 PostgreSQL Wikipedia 페이지에서도 인용되고 있습니다. 이 글에서는 PostgreSQL의 MVCC 구현이 MySQL, Oracle, Microsoft SQL Server를 포함한 다른 주요 관계형 DBMS 중 최악이라고 지적합니다.

초당 수백만 쿼리로 PostgreSQL 확장하기​

이러한 한계를 완화하고 write 압력을 줄이기 위해 다음과 같은 전략을 채택했습니다:

Write 워크로드 마이그레이션​

샤딩 가능한(수평 파티셔닝 가능한) write-heavy 워크로드를 Azure Cosmos DB와 같은 샤딩된 시스템으로 마이그레이션하고, 불필요한 write를 최소화하도록 애플리케이션 로직을 최적화했습니다. 또한 현재 PostgreSQL 배포에 새로운 테이블 추가를 더 이상 허용하지 않으며, 새 워크로드는 기본적으로 샤딩된 시스템을 사용합니다.

현재 인프라가 발전했음에도 PostgreSQL은 샤딩되지 않은 상태로, 단일 Primary 인스턴스가 모든 write를 처리합니다. 주된 이유는 기존 애플리케이션 워크로드를 샤딩하는 것이 매우 복잡하고 시간이 많이 걸리며, 수백 개의 애플리케이션 엔드포인트를 변경해야 하고 몇 달 또는 몇 년이 걸릴 수 있기 때문입니다. 워크로드가 주로 read-heavy이고 광범위한 최적화를 구현했기 때문에, 현재 아키텍처는 여전히 트래픽 증가를 지원할 충분한 여유를 제공합니다.

Primary 부하 감소​

과제: 단일 writer만 있는 경우 write를 확장할 수 없습니다. write 급증은 Primary를 빠르게 과부하시켜 ChatGPT 및 API와 같은 서비스에 영향을 줄 수 있습니다.

솔루션: Primary에서 read와 write 모두 가능한 한 부하를 최소화하여 write 급증을 처리할 충분한 용량을 확보합니다. Read 트래픽은 가능한 한 replica로 오프로드됩니다. 그러나 write 트랜잭션의 일부인 일부 read 쿼리는 Primary에 남아야 합니다. 이러한 경우 쿼리가 효율적이고 느린 쿼리를 피하도록 보장하는 데 집중합니다.

쿼리 최적화​

과제: PostgreSQL에서 여러 expensive 쿼리를 식별했습니다. 과거에는 이러한 쿼리의 볼륨 급증이 대량의 CPU를 소비하여 ChatGPT와 API 요청을 모두 느리게 만들었습니다.

솔루션: 12개 테이블을 조인하는 매우 비용이 많이 드는 쿼리를 발견했으며, 이 쿼리의 급증이 과거 고심각도 SEV의 원인이었습니다. 복잡한 다중 테이블 조인은 가능한 한 피해야 합니다. 조인이 필요한 경우 쿼리를 분해하고 복잡한 조인 로직을 애플리케이션 레이어로 이동하는 것을 고려해야 합니다.

이러한 문제 쿼리 중 다수는 ORM(Object-Relational Mapping) 프레임워크에 의해 생성되므로, 생성된 SQL을 주의 깊게 검토하고 예상대로 동작하는지 확인하는 것이 중요합니다. 또한 idle_in_transaction_session_timeout과 같은 timeout을 구성하여 장기 실행 idle 쿼리가 autovacuum을 차단하는 것을 방지해야 합니다.

단일 장애 지점(SPOF) 완화​

과제: Read replica가 다운되면 트래픽을 다른 replica로 라우팅할 수 있습니다. 그러나 단일 writer에 의존한다는 것은 단일 장애 지점이 있다는 의미이며, 다운되면 전체 서비스가 영향을 받습니다.

솔루션: 가장 중요한 요청은 read 쿼리만 포함합니다. Primary의 단일 장애 지점을 완화하기 위해 writer에서 replica로 이러한 read를 오프로드하여 Primary가 다운되어도 해당 요청이 계속 서비스될 수 있도록 합니다.

Primary 장애를 완화하기 위해 Hot Standby와 함께 고가용성(HA) 모드로 Primary를 실행합니다. Hot Standby는 지속적으로 동기화되는 replica로 항상 트래픽을 인계받을 준비가 되어 있습니다. PostgreSQL에서는 Primary 서버가 continuous archiving 모드로 작동하고 각 standby 서버는 continuous recovery 모드로 작동하며 Primary에서 WAL 파일을 읽습니다. Azure PostgreSQL 팀은 매우 높은 부하에서도 이러한 failover가 안전하고 안정적으로 유지되도록 상당한 작업을 수행했습니다.

워크로드 격리​

과제: 특정 요청이 PostgreSQL 인스턴스에서 불균형적으로 많은 리소스를 소비하는 상황이 자주 발생합니다. 이는 동일한 인스턴스에서 실행되는 다른 워크로드의 성능 저하로 이어질 수 있습니다.

솔루션: "noisy neighbor" 문제를 완화하기 위해 워크로드를 전용 인스턴스로 격리하여 리소스 집약적 요청의 급증이 다른 트래픽에 영향을 주지 않도록 합니다. 구체적으로 요청을 low-priority와 high-priority tier로 분할하고 별도의 인스턴스로 라우팅합니다. 이렇게 하면 low-priority 워크로드가 리소스 집약적이 되어도 high-priority 요청의 성능이 저하되지 않습니다.

연결 풀링(Connection Pooling)​

과제: 각 인스턴스에는 최대 연결 제한이 있습니다(Azure PostgreSQL에서 5,000개). 연결이 부족하거나 idle 연결이 너무 많이 누적되기 쉽습니다. 이전에 모든 사용 가능한 연결을 소진시킨 connection storm으로 인한 장애가 있었습니다.

솔루션: PgBouncer를 프록시 레이어로 배포하여 데이터베이스 연결을 풀링합니다. Statement 또는 transaction 풀링 모드로 실행하면 연결을 효율적으로 재사용하여 활성 클라이언트 연결 수를 크게 줄일 수 있습니다. 또한 연결 설정 지연시간을 줄입니다: 벤치마크에서 평균 연결 시간이 50밀리초에서 5밀리초로 감소했습니다.

Region 간 연결과 요청은 비용이 많이 들 수 있으므로 프록시, 클라이언트, replica를 동일한 region에 배치하여 네트워크 오버헤드와 연결 사용 시간을 최소화합니다.

각 read replica에는 여러 PgBouncer 파드를 실행하는 자체 Kubernetes 배포가 있습니다. 동일한 Kubernetes Service 뒤에서 여러 Kubernetes 배포를 실행하여 파드 간 트래픽을 로드 밸런싱합니다.

캐싱 전략​

과제: 캐시 미스의 급증은 PostgreSQL 데이터베이스에 read 급증을 유발하여 CPU를 포화시키고 사용자 요청을 느리게 만들 수 있습니다.

솔루션: PostgreSQL의 read 압력을 줄이기 위해 캐싱 레이어를 사용하여 대부분의 read 트래픽을 제공합니다. 그러나 캐시 hit rate가 예기치 않게 떨어지면 캐시 미스의 burst가 대량의 요청을 직접 PostgreSQL로 푸시할 수 있습니다.

캐시 미스 storm 동안 과부하를 방지하기 위해 캐시 락킹(및 리싱) 메커니즘을 구현하여 특정 키에 대해 미스가 발생한 단일 reader만 PostgreSQL에서 데이터를 가져오도록 합니다. 여러 요청이 동일한 캐시 키에 대해 미스가 발생하면 한 요청만 락을 획득하고 다른 요청은 해당 요청이 데이터를 가져올 때까지 대기합니다.

결론​

OpenAI의 경험은 적절한 최적화와 엔지니어링을 통해 PostgreSQL을 초당 수백만 쿼리를 처리하고 수억 명의 사용자를 지원하는 규모로 확장할 수 있음을 보여줍니다. MVCC의 근본적인 한계를 이해하고 이를 완화하기 위한 전략적 접근(write 워크로드 분리, 쿼리 최적화, 워크로드 격리, 연결 풀링, 캐싱)을 통해 단일 Primary 아키텍처의 한계를 극복하고 안정적인 서비스를 제공할 수 있었습니다.

References​

• Scaling PostgreSQL to power 800 million ChatGPT users - OpenAI
• What is Azure Database for PostgreSQL? - Microsoft Learn
• The Part of PostgreSQL We Hate the Most - Andy Pavlo, Carnegie Mellon University
• PostgreSQL - Wikipedia
• PostgreSQL Documentation: Log-Shipping Standby Servers

TL;DR​

Oh-My-OpenCode는 최근 화제가 된 오픈소스 프로젝트로, 코드 레벨에서의 심층 분석이 필요한 도구입니다. 본 문서는 해당 프로젝트의 내부 동작 원리를 상세히 파헤쳐 AI Research Engineer들이 실무에 적용할 수 있는 인사이트를 제공합니다. 코드 레벨의 구현 분석을 통해 설계 철학과 기술적 의사결정을 이해할 수 있습니다.

Key Takeaways​

• Oh-My-OpenCode의 코드 아키텍처를 분석하여 유사 프로젝트 구현 시 참고할 수 있는 설계 패턴을 파악할 수 있습니다.
• 오픈소스 프로젝트의 내부 동작 원리를 이해함으로써 커스터마이징 및 확장 가능성을 평가할 수 있습니다.
• 코드 레벨 분석은 단순 사용을 넘어 근본적인 작동 메커니즘을 이해하는 데 필수적입니다.
• 화제성 있는 오픈소스 도구를 빠르게 분석하고 실무 적용 가능성을 판단하는 방법론을 습득할 수 있습니다.

상세 내용​

Oh-My-OpenCode 개요​

Oh-My-OpenCode는 최근 개발자 커뮤니티에서 주목받고 있는 오픈소스 프로젝트입니다. 새로운 도구나 프레임워크를 실무에 도입하기 전, AI Research Engineer는 표면적인 기능뿐만 아니라 내부 구조와 동작 원리를 정확히 이해해야 합니다. 이는 프로덕션 환경에서의 안정성, 확장성, 그리고 팀의 기술 스택과의 호환성을 평가하는 데 필수적입니다.

코드 레벨 분석의 중요성​

오픈소스 프로젝트를 분석할 때 단순히 README와 문서만 읽는 것으로는 충분하지 않습니다. 특히 AI/ML 연구 및 개발 환경에서는 다음과 같은 이유로 코드 레벨의 심층 분석이 필요합니다:

성능 특성 파악: 실제 구현 방식을 통해 시간/공간 복잡도와 병목 지점을 식별할 수 있습니다.

의존성 관리: 프로젝트가 사용하는 라이브러리와 프레임워크의 버전 호환성을 확인할 수 있습니다.

확장 가능성 평가: 코드 구조를 통해 커스터마이징이나 기능 추가가 얼마나 용이한지 판단할 수 있습니다.

보안 및 안정성: 잠재적인 보안 취약점이나 엣지 케이스 처리 방식을 직접 검증할 수 있습니다.

장기 분석 접근법​

오픈소스 프로젝트의 장기 분석은 다음과 같은 단계적 접근이 효과적입니다:

1. 프로젝트 구조 파악: 디렉토리 구조, 모듈 분리, 설계 패턴을 먼저 이해합니다.

2. 핵심 로직 추적: 메인 실행 흐름을 따라가며 주요 알고리즘과 데이터 처리 방식을 분석합니다.

3. 의존성 분석: requirements.txt, package.json 등을 통해 외부 라이브러리 의존성을 파악합니다.

4. 테스트 코드 검토: 유닛 테스트와 통합 테스트를 통해 의도된 사용 방식과 엣지 케이스를 이해합니다.

5. 커밋 히스토리 분석: Git 히스토리를 통해 프로젝트의 진화 과정과 주요 의사결정을 추적합니다.

AI Research Engineer를 위한 실무 적용​

코드 분석을 통해 얻은 인사이트는 다음과 같이 실무에 활용할 수 있습니다:

벤치마킹: 유사한 문제를 해결하는 자체 솔루션과 비교하여 성능과 효율성을 평가합니다.

모듈 재사용: 잘 설계된 컴포넌트를 자신의 프로젝트에 통합하거나 참고할 수 있습니다.

기여 기회 파악: 개선 가능한 부분을 발견하여 오픈소스 기여를 통해 커뮤니티에 환원할 수 있습니다.

학습 자료: 실전 코드를 통해 베스트 프랙티스와 안티패턴을 학습할 수 있습니다.

지속적인 모니터링​

오픈소스 프로젝트는 지속적으로 진화합니다. 장기 분석은 일회성이 아니라 다음과 같은 지속적인 활동이 되어야 합니다:

• 주요 릴리스의 변경사항 추적
• 이슈 트래커와 PR을 통한 커뮤니티 동향 파악
• 성능 및 보안 업데이트 모니터링
• 대체 솔루션과의 비교 분석 지속

References​

• 본 문서는 내부 분석 자료를 기반으로 작성되었습니다.