TL;DR​

AI 에이전트가 복잡한 프로덕션 환경에서 안정적으로 동작하려면 프롬프트와 컨텍스트 설계만으로는 부족합니다. 하네스 엔지니어링(Harness Engineering)은 에이전트를 감싸는 전체 환경—저장소 구조, CI/CD, 린터, 외부 도구 연결, 피드백 루프—을 설계하는 새로운 엔지니어링 패러다임입니다. OpenAI의 실험에서 하네스만 제대로 구축했을 뿐인데 AI가 백만 라인의 프로덕션 소프트웨어를 완성했으며, 이는 엔지니어의 역할이 "코드 작성"에서 "환경 설계"로 전환되고 있음을 보여줍니다. 프롬프트 엔지니어링이 "무엇을 물어볼까"에 집중한다면, 컨텍스트 엔지니어링은 "무엇을 보여줄까", 하네스 엔지니어링은 "전체 환경을 어떻게 설계할까"라는 질문에 답합니다.

Key Takeaways​

• 하네스는 에이전트의 "운영체제"다: 린터, CI/CD, 아키텍처 가드레일, 외부 도구 연결 등 에이전트 바깥의 모든 제약과 피드백 장치가 하네스를 구성하며, 이것이 프롬프트보다 더 큰 영향을 미친다.
• 프롬프트 → 컨텍스트 → 하네스 순서로 범위가 확장된다: 프롬프트 엔지니어링이 "지시문 최적화"라면, 컨텍스트 엔지니어링은 "LLM이 보는 모든 정보 설계", 하네스 엔지니어링은 "에이전트를 감싸는 시스템 전체 설계"다.
• 컨텍스트는 많이 넣는다고 좋은 게 아니다: Context Poisoning, Distraction, Confusion 같은 실패 패턴이 존재하며, 컨텍스트 윈도우를 "딱 맞는 정보"로 채우는 것이 핵심이다(Karpathy의 정의).
• MCP와 Agent Skills는 하네스의 핵심 구성 요소다: MCP(Model Context Protocol)는 외부 시스템 연결을, Agent Skills는 반복 작업의 재사용 가능한 지침화를 담당하며, 이 둘이 에이전트의 실행 환경을 구성한다.
• 엔지니어의 역할이 재정의되고 있다: 수동 코딩에서 벗어나 "에이전트가 자율적으로 소프트웨어를 구축할 수 있는 환경 설계"로 초점이 이동하며, 이는 단순한 도구 변화가 아닌 엔지니어링 패러다임의 전환이다.

상세 내용​

하네스 엔지니어링의 정의와 등장 배경​

AI 에이전트를 실제 운영 환경에 투입하면 흥미로운 현상이 발생합니다. 같은 모델을 사용하는데도 프로젝트 A에서는 완벽하게 동작하고, 프로젝트 B에서는 엉뚱한 결과를 내놓습니다. 프롬프트를 아무리 다듬어도 이 격차는 좁혀지지 않습니다. 원인은 대부분 에이전트를 "감싸는 환경"의 차이에 있습니다.

2026년 2월, OpenAI는 놀라운 실험 결과를 발표했습니다. 에이전트를 감싸는 환경만 제대로 구축했을 뿐인데, 수동으로 작성된 코드 없이 AI가 생성한 백만 개 라인에 달하는 프로덕션 소프트웨어를 완성했습니다. 이 결과는 모델 성능이 아닌 "환경 설계"가 에이전트의 실제 성과를 결정한다는 것을 보여줍니다.

**하네스(Harness)**는 AI 에이전트가 안정적으로 작업을 수행할 수 있도록 감싸는 스캐폴딩(scaffolding)이자 피드백 루프가 구축된 전체 환경을 의미합니다. 저장소 구조, CI 설정, 포맷 규칙, 패키지 관리자, 애플리케이션 프레임워크, 프로젝트 지시 사항, 외부 도구 연결, 린터 등 에이전트 바깥에서 동작하는 모든 시스템이 하네스에 포함됩니다. 이는 에이전트가 궤도를 이탈하지 않도록 돕는 기반 인프라 역할을 합니다.

**하네스 엔지니어링(Harness Engineering)**은 엔지니어의 주된 역할이 수동 코드 작성에서 벗어나, 에이전트가 소프트웨어를 자율적으로 구축하고 유지보수할 수 있도록 환경을 설계하고 의도를 명확히 지정하며 피드백 루프를 구축하는 작업으로 재정의된 것을 의미합니다.

프롬프트, 컨텍스트, 하네스의 관계​

세 개념은 포함 관계를 이루며 안쪽부터 바깥쪽으로 확장됩니다:

비유를 들자면, 프롬프트 엔지니어링이 말에게 "오른쪽으로 돌아"라는 음성 명령을 내리는 것이라면, 컨텍스트 엔지니어링은 말에게 지도와 이정표를 보여주는 것이고, 하네스 엔지니어링은 고삐, 안장, 울타리, 도로 정비까지 합쳐서 말 열 마리를 동시에 안전하게 달리게 만드는 전체 설계에 해당합니다.

개념의 진화 과정​

2023~2024: 프롬프트 엔지니어링 시대 ChatGPT에 질문 하나를 던지고 답변 하나를 받는 단순한 구조였습니다. 역할을 부여하고, 단계별로 지시하고, 예시를 넣는 것만으로 원하는 결과를 얻을 수 있었습니다.

2025 중반: 컨텍스트 엔지니어링의 부상 2025년 6월, 전 OpenAI 연구원 안드레이 카르파티(Andrej Karpathy)가 "프롬프트보다 컨텍스트 엔지니어링이 핵심"이라고 언급하면서 패러다임이 전환되었습니다. 단순히 질문을 잘 쓰는 것이 아니라, LLM이 추론할 때 "무엇을 보게 할지" 시스템 수준에서 관리하는 접근이 필요해졌습니다.

LangChain은 이를 컴퓨터에 비유합니다: "LLM은 CPU이고, 컨텍스트 윈도우는 RAM이다. 운영체제가 CPU의 RAM에 무엇을 올릴지 관리하듯, 컨텍스트 엔지니어링도 같은 역할을 한다."

2026년 2월: 하네스 엔지니어링의 등장 AI 에이전트가 본격적으로 운영 환경에 투입되면서 컨텍스트 설계만으로는 해결되지 않는 문제들이 드러났습니다. 팀 컨벤션 위반, 아키텍처 의존성 방향 문제, 병렬 실행 시 파일 충돌, 생성 코드의 점진적 품질 저하 등입니다. 이는 "모델에게 무엇을 보여줄까"가 아니라 "시스템이 무엇을 막고, 측정하고, 고칠 것인가"의 문제입니다.

해시코프(HashiCorp) 공동 창업자 미첼 하시모토(Mitchell Hashimoto)가 2026년 2월 5일 자신의 블로그에서 에이전트의 실수를 방지하는 장치를 쌓아가는 작업을 "하네스 엔지니어링"이라 명명했고, 며칠 뒤 OpenAI도 공식 보고서를 발표하면서 용어가 빠르게 확산되었습니다.

하네스의 핵심 구성 요소​

하네스는 다음과 같은 요소들로 구성됩니다:

1. 저장소 구조와 컨벤션

• 폴더 구조, 네이밍 규칙, 코드 스타일 가이드
• 린터, 포매터 설정
• 아키텍처 가드레일(의존성 방향 검증 등)

2. CI/CD와 자동화 파이프라인

• 자동 테스트, 빌드, 배포 워크플로우
• 에이전트가 생성한 코드에 대한 즉각적인 피드백

3. 외부 도구 연결 (MCP)

• 이슈 트래커, 데이터베이스, API 등 외부 시스템과의 통합
• Model Context Protocol을 통한 표준화된 연결

4. 재사용 가능한 작업 지침 (Agent Skills)

• 반복적인 작업 절차의 문서화
• SKILL.md 형태로 작성된 실행 가능한 가이드

컨텍스트 엔지니어링: 정보 환경 설계​

컨텍스트 엔지니어링은 LLM의 컨텍스트 윈도우에 "무엇을 넣고 무엇을 버릴지" 설계하는 작업입니다. 컨텍스트 윈도우가 수백만 토큰으로 확장되면서 "넣을 수 있는 공간"이 커졌지만, 정보량이 아니라 적합성이 핵심입니다.

컨텍스트 윈도우에 들어갈 수 있는 요소들:

• 시스템 프롬프트: 역할, 제약, 출력 형식
• 대화 이력: 이전 질문과 답변의 흐름
• 검색 문서: RAG로 가져온 관련 문서
• 도구 출력: API 응답, 코드 실행 결과
• 사용자 입력: 현재 질문과 첨부 파일
• 메모리: 장기 기억으로 주입하는 요약 정보

컨텍스트 실패 패턴:

1. Context Poisoning (컨텍스트 오염): 한 번 잘못 들어간 정보가 이후 대화 전체에 걸쳐 사실처럼 전달되는 현상
2. Context Distraction (컨텍스트 산만): 관련 없는 정보가 너무 많아 핵심 근거를 놓치는 현상 (2025년 연구에서 평균 45% 성능 저하)
3. Context Confusion (컨텍스트 혼란): 불필요한 정보가 모델의 판단에 영향을 미치는 현상

프롬프트 vs 컨텍스트 엔지니어링 비교:

고객 문의를 처리하는 CS 챗봇을 예로 들면:

• 프롬프트만 사용: "배송 관련 문의를 하면 조회 방법을 알려줘" → 일반적 응대는 가능하지만 실시간 데이터 접근 불가
• 컨텍스트 설계 추가: 주문 DB와 배송 API를 연결하고, 실시간 상태를 컨텍스트에 주입해 정확한 답변 생성

MCP: 외부 시스템 연결의 표준​

Model Context Protocol(MCP)은 Claude Code 같은 AI 에이전트가 외부 데이터 소스나 도구에 접근할 수 있게 해주는 프로토콜입니다. 전동드릴에 비트를 바꿔 끼우듯, MCP 서버를 연결하면 에이전트가 접근할 수 있는 정보의 범위가 달라집니다.

MCP 서버 연결 방식:

1. HTTP 원격 서버 (권장):

claude mcp add --transport http notion https://mcp.notion.com/mcp

2. 로컬 stdio 서버:

claude mcp add --transport stdio github -- npx -y @modelcontextprotocol/server-github

3. 환경 변수 전달:

claude mcp add --transport stdio --env GITHUB_TOKEN=ghp_xxx github -- npx -y @modelcontextprotocol/server-github

적용 범위(Scope) 설정:

• --scope local: 현재 프로젝트에서만 (기본값)
• --scope project: 팀 공유 (.mcp.json 파일에 저장)
• --scope user: 모든 프로젝트에서 사용

project 스코프를 사용하면 서버 정의는 팀과 공유하되, 인증 토큰은 각 개발자의 로컬 환경에서 관리하는 구조가 됩니다.

Agent Skills: 재사용 가능한 작업 지침​

Agent Skills는 반복되는 작업 절차를 문서화하여 에이전트가 읽고 수행할 수 있게 만드는 방식입니다. Anthropic이 2025년 10월 발표하고 12월에 오픈 스탠다드로 공개한 이 개념은 SKILL.md 파일을 중심으로 작동합니다.

스킬 디렉터리 구조:

code-review/
├── SKILL.md              # 필수: 에이전트가 따를 지침
├── scripts/              # 선택: 실행 스크립트
│   └── run-lint.sh
├── references/           # 선택: 보조 문서
│   └── review-checklist.md
└── assets/               # 선택: 템플릿, 설정 파일
    └── comment-template.md

Progressive Disclosure 원칙: 스킬은 한꺼번에 로드되지 않고 세 단계로 읽힙니다:

• Phase 1: Metadata (~100 tokens) - name, description만 읽음
• Phase 2: Instructions (< 5000 tokens 권장) - SKILL.md 전체 읽음
• Phase 3: Resources (필요한 만큼) - scripts, references 파일 읽음

SKILL.md 작성 예시:

---
name: api-test-runner
description: >-
  API 엔드포인트의 응답 상태, 스키마, 성능을 자동으로 검증한다.
  API 테스트, 엔드포인트 점검, 응답 검증이 필요할 때 사용한다.
---

## 목적
프로덕션 배포 전 API 엔드포인트의 정상 동작을 확인한다.

## 실행 방법
1. `scripts/run-api-test.sh` 실행
2. 실패 시 `references/troubleshooting.md` 참고

중요 작성 포인트:

• description은 WHAT(무엇을 하는지)과 WHEN(언제 쓰는지)을 모두 포함
• 1/2인칭 표현("나는", "당신은") 피하고 3인칭으로 서술
• name은 디렉터리 이름과 일치, 소문자-하이픈만 사용

실무 적용 시나리오​

시나리오: 이슈 기반 코드 수정 자동화

1. 프롬프트만 사용: "ISSUE-1234를 고쳐줘" → 이슈 내용을 모르므로 추가 설명 필요
2. 컨텍스트 추가: GitHub API로 이슈 내용을 가져와 컨텍스트에 주입 → 이슈 내용 파악
3. 하네스 구축:
   • MCP로 GitHub 연결
   • Agent Skill로 "이슈 분석 → 코드 수정 → 테스트 → PR 생성" 워크플로우 정의
   • CI에서 자동 테스트 실행
   • 린터로 코드 스타일 검증

결과: "ISSUE-1234를 고쳐줘"라는 한 문장으로 전체 프로세스가 자동 실행됩니다.

References​

• OpenAI: Harness engineering: leveraging Codex in an agent-first world (2026.02)
• Can Boluk: I Improved 15 LLMs at Coding in One Afternoon (2026.02)
• MadPlay: 프롬프트와 컨텍스트를 넘어, AI 에이전트를 위한 하네스 엔지니어링
• MadPlay: 컨텍스트 엔지니어링: 프롬프트를 넘어 맥락을 설계하는 방법
• MadPlay: Claude Code에서 MCP 서버를 연동하는 방법과 주의할 점
• MadPlay: 에이전트 스킬(Agent Skills)이란 무엇이고, 어떻게 만들까
• Agent Skills Official Specification
• Anthropic: Context Engineering Guide

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는 이를 다음과 같이 해결합니다:

초기에는 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계층 메모리 시스템​

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

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

모듈러 스킬 팩 시스템​

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

기타 핵심 기능​

• 훅 시스템: 작업 전후에 자동 실행되는 사용자 정의 스크립트 (예: 코드 작성 전 보안 검사, 완료 후 자동 커밋)
• 알고리즘: 관찰→생각→계획→실행→검증→학습의 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가지 유형으로 구분할 수 있다:

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

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

Gen.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​

프롬프트 캐싱은 AI 에이전트의 비용을 최대 90% 절감하고 응답 속도를 획기적으로 개선하는 핵심 기술입니다. 접두사 매칭(Prefix Matching) 원리에 기반하여, 변하지 않는 컨텍스트는 앞에 배치하고 동적 요소는 뒤로 보내는 전략이 필수적입니다. 시스템 프롬프트에 타임스탬프를 넣거나 도구 세트를 수시로 변경하는 등 캐시를 무효화하는 안티패턴을 피하고, 캐시 히트율을 시스템 가용성만큼 중요한 지표로 모니터링해야 합니다. Claude Code 팀의 실전 경험에서 나온 5가지 골든 룰을 따르면 비용 효율성과 사용자 경험을 동시에 극대화할 수 있습니다.

Key Takeaways​

• 프롬프트 레이아웃 설계가 핵심: 전역 정적 콘텐츠 → 프로젝트 컨텍스트 → 세션 컨텍스트 → 대화 기록 순으로 계층화하여 여러 세션이 상단부 캐시를 공유하도록 설계
• 캐시 무효화 방지 원칙: 시스템 프롬프트에 동적 정보(타임스탬프 등) 절대 삽입 금지, 모델과 도구 세트는 고정하고 서브 에이전트로 유연성 확보
• 도구 기반 상태 관리: 프롬프트를 직접 수정하는 대신 EnterPlanMode 같은 도구 호출로 상태 전환을 구현하여 정적 프롬프트 구조 보호
• 지연 로딩 패턴 활용: 수십 개의 도구는 스텁(Stub)으로 제공하고 ToolSearch로 필요할 때만 상세 스키마 로드하여 접두사 안정성 유지
• 캐시 히트율을 SLA로 관리: 히트율을 시스템 가용성 수준의 KPI로 취급하고, 일정 수준 이하로 떨어지면 알람을 발생시키는 운영 체계 구축

상세 내용​

왜 프롬프트 캐싱이 AI 에이전트의 생존 전략인가​

현대적인 AI 에이전트는 Claude Code처럼 긴 대화 세션을 유지하고, 대규모 코드베이스를 참조하며, 반복적인 도구 호출(Tool Call)을 수행합니다. 이 과정에서 매 요청마다 수만 개의 토큰을 모델에 새로 입력하는 것은 두 가지 치명적인 문제를 야기합니다.

첫째, 비용 폭증입니다. 일반적인 입력 토큰 비용은 프로덕션 환경에서 빠르게 누적되며, 특히 장시간 세션이나 대규모 컨텍스트를 다루는 에이전트의 경우 운영 비용이 비즈니스 모델 자체를 위협할 수 있습니다.

둘째, 레이턴시 증가입니다. 모델이 입력을 처음부터 다시 처리(Prefilling)하는 시간은 사용자 경험에 직접적인 영향을 미칩니다. 특히 실시간 코딩 어시스턴트처럼 빠른 피드백이 중요한 애플리케이션에서는 몇 초의 지연도 사용 가능성을 크게 저하시킵니다.

프롬프트 캐싱(Prompt Caching)은 이전 요청에서 계산된 컨텍스트를 재사용하여 이 두 문제를 동시에 해결합니다:

• 최대 90%의 비용 절감: 캐시된 토큰은 신규 입력 토큰 대비 대폭 할인된 가격으로 처리됩니다
• 응답 속도 향상: Prefilling 단계를 건너뛰어 응답 시작 시간(Time to First Token)이 비약적으로 단축됩니다

접두사 매칭(Prefix Matching): 캐싱의 작동 원리​

프롬프트 캐싱은 '접두사 매칭'이라는 엄격한 규칙에 따라 작동합니다. API는 요청의 시작 부분부터 특정 캐시 브레이크포인트(Breakpoint)까지의 내용이 이전 요청과 완전히 동일할 때만 캐시를 적용합니다.

여기서 "완전히 동일"이란 표현이 핵심입니다:

• 단 하나의 문자가 다르거나
• 공백 하나가 추가되거나
• 도구 정의의 순서가 바뀌거나
• JSON 키의 직렬화 순서가 달라지면

해당 지점 이후의 모든 캐시는 즉시 무효화(Invalidate)됩니다.

이러한 특성 때문에 캐싱 전략의 핵심 원칙이 도출됩니다:

"변하지 않는 것은 앞으로, 자주 변하는 것은 뒤로"

이 원칙을 지키지 않으면 캐시가 지속적으로 깨지면서 오히려 캐시 생성 비용만 발생하여 역효과가 납니다.

프롬프트 레이아웃의 4계층 구조​

Claude Code 팀이 실전에서 검증한 최적의 프롬프트 구조는 변경 빈도에 따라 다음과 같이 4계층으로 구성됩니다:

1. 전역 정적 컨텐츠 (Static System Prompt & Tools)

• 모든 사용자, 모든 세션에서 공통으로 사용되는 시스템 지침
• 기본 도구(Tool) 정의 세트
• 가장 변경이 적고, 가장 많은 세션이 공유하는 레이어

2. 프로젝트 컨텍스트 (Project-specific Context)

• 특정 프로젝트의 코딩 규칙이나 아키텍처 가이드
• CLAUDE.md 같은 프로젝트 설정 파일
• 프로젝트 내 모든 세션이 공유

3. 세션 컨텍스트 (Session Context)

• 현재 사용자 세션의 고유 정보
• 작업 중인 파일 목록이나 초기 상태
• 한 세션 내에서는 안정적으로 유지

4. 대화 기록 (Conversation Messages)

• 실시간으로 추가되는 사용자-모델 간 메시지
• 가장 빈번하게 변경되는 레이어

이 순서를 엄격히 지켜야 여러 사용자와 세션이 상위 레이어의 캐시를 효과적으로 공유하여 전체 시스템의 캐시 히트율(Hit Rate)을 극대화할 수 있습니다.

캐시 무효화를 방지하는 5가지 골든 룰​

1. 시스템 프롬프트에 동적 정보 삽입 금지​

가장 흔한 실수는 시스템 프롬프트에 타임스탬프를 포함하는 것입니다:

❌ 나쁜 예:
You are a helpful assistant. Current time: 2024-02-20 14:32:15

이렇게 하면 매분마다 캐시가 무효화되어 캐싱의 효과가 완전히 사라집니다.

✅ 좋은 예:
시스템 프롬프트: You are a helpful assistant.
최신 사용자 메시지: [현재 시각: 2024-02-20 14:32:15] 사용자 질문...

날짜, 시간, 세션 ID 같은 동적 정보는 반드시 대화의 최신 메시지나 별도의 시스템 메시지로 전달하여 상단부의 정적 접두사를 보호해야 합니다.

2. 모델 및 도구 세트 고정​

모델 전환의 함정 비용을 절감하려고 대화 중간에 claude-opus-4 → claude-haiku-3.5로 모델을 바꾸면 캐시를 처음부터 다시 쌓아야 하므로 오히려 더 많은 비용이 발생할 수 있습니다.

해결책: 주요 에이전트는 고성능 모델로 고정하고, 비용 최적화가 필요한 서브 태스크는 별도의 서브 에이전트(Sub-agent)로 분리하여 각각 최적의 모델을 사용하게 합니다.

도구 세트의 안정성 특정 상황에만 도구를 노출하려고 도구 정의를 동적으로 추가/제거하면 캐시가 지속적으로 깨집니다.

해결책: 모든 가능한 도구를 항상 정의해두고, 시스템 지침이나 컨텍스트를 통해 "지금은 이 도구만 사용하라"고 모델을 가이드합니다. 모델은 충분히 똑똑해서 이런 지침을 잘 따릅니다.

3. 상태 전환을 도구로 구현하기 (Plan Mode 사례)​

사용자가 "계획 모드"에 진입할 때 시스템 프롬프트를 수정하는 대신, 다음과 같이 도구를 활용합니다:

# ❌ 나쁜 예: 프롬프트 직접 수정
system_prompt = base_prompt + "\n\nYou are now in plan mode..."

# ✅ 좋은 예: 도구 호출로 상태 전환
tools = [
    {
        "name": "EnterPlanMode",
        "description": "Switch to planning mode for high-level design"
    }
]

# 모델이 EnterPlanMode를 호출하면
# tool_result로 상태 메시지 반환
tool_result = {
    "type": "system",
    "content": "Now in plan mode. Focus on architecture..."
}

모델은 도구 호출 결과로 전달된 시스템 메시지를 통해 현재 상태를 인식하고, 정적 프롬프트는 전혀 변경되지 않아 캐시가 유지됩니다.

4. 도구 검색(Tool Search)과 지연 로딩(Deferred Loading)​

수십 개의 도구를 모두 정의하면 초기 컨텍스트가 너무 커져 비용이 증가합니다. 하지만 도구를 제거하면 캐시가 깨지는 딜레마가 발생합니다.

해결책: 스텁(Stub) + 지연 로딩 패턴

# 초기에는 이름과 간단한 설명만 제공
tools = [
    {"name": "ToolA", "description": "Brief description"},
    {"name": "ToolB", "description": "Brief description"},
    # ... 수십 개
    {"name": "ToolSearch", "description": "Get detailed schema for a tool"}
]

# 모델이 ToolSearch("ToolA")를 호출하면
# 그때 상세 스키마를 반환
detailed_schema = {
    "name": "ToolA",
    "parameters": {...},  # 상세 파라미터 정보
    "examples": [...]
}

이 패턴을 사용하면 도구 목록 자체는 안정적으로 유지되어 접두사 캐시가 보존되면서도, 필요한 순간에만 상세 정보를 로드하여 초기 컨텍스트 크기를 최소화할 수 있습니다.

5. 캐시 세이프 포킹(Cache-safe Forking)​

대화가 길어져 컨텍스트 윈도우가 가득 차면 요약(Compaction)이 필요합니다. 이때 새로운 빈 세션을 만들어 요약하면 기존 캐시를 전혀 활용하지 못합니다.

최적화된 요약 전략:

# ❌ 비효율적: 새 세션으로 요약
new_request = {
    "system": system_prompt,
    "messages": [{"role": "user", "content": "Summarize this: " + full_history}]
}

# ✅ 효율적: 기존 컨텍스트 유지 + 요약 요청 추가
fork_request = {
    "system": system_prompt,  # 캐시됨
    "tools": tools,             # 캐시됨
    "messages": [
        ...existing_messages,    # 캐시됨
        {"role": "user", "content": "Summarize the conversation so far"}
    ]
}

기존 대화의 모든 컨텍스트를 그대로 포함한 채 마지막에 요약 요청만 추가하면, 이전 계산량을 100% 재사용하면서 요약본만 새로 생성할 수 있습니다. 이를 "캐시 세이프 포킹"이라고 부르며, Claude Code 팀이 실전에서 검증한 강력한 패턴입니다.

운영 및 모니터링: 캐시 히트율을 SLA처럼 관리하기​

Claude Code 팀은 프롬프트 캐시 히트율을 시스템 가용성(Uptime)과 동등한 수준의 핵심 지표로 관리한다고 밝혔습니다.

모니터링 전략:

• 캐시 히트율 대시보드: 실시간으로 히트율을 추적하고 시각화
• 알람 설정: 히트율이 기준치(예: 85%) 이하로 떨어지면 즉시 경고 발생
• 장애 대응: 히트율 급락을 서비스 장애와 동일하게 취급하여 긴급 조사

비결정성(Non-determinism) 제거: 캐시가 예상치 못하게 깨지는 가장 흔한 원인은 직렬화(Serialization) 과정의 비결정성입니다.

# ❌ 문제 있는 코드: Dictionary 순서가 랜덤
tools = {
    "tool_a": {...},
    "tool_b": {...}
}
json_str = json.dumps(tools)  # 순서가 매번 달라질 수 있음

# ✅ 안전한 코드: 순서 명시적 보장
tools = OrderedDict([
    ("tool_a", {...}),
    ("tool_b", {...})
])
json_str = json.dumps(tools, sort_keys=True)

Python의 일반 dict, Java의 HashMap 등은 삽입 순서를 보장하지 않거나 버전에 따라 동작이 다를 수 있습니다. 캐시 안정성을 위해서는 항상 순서를 명시적으로 제어해야 합니다.

Claude Code의 실전 활용​

Claude Code는 터미널, IDE(VS Code, JetBrains), 데스크톱 앱, 웹 브라우저 등 다양한 환경에서 동작하는 AI 코딩 어시스턴트입니다. 전체 코드베이스를 이해하고, 여러 파일을 동시에 편집하며, 개발 도구와 통합되어 작동합니다.

이러한 복잡한 멀티턴 상호작용에서 프롬프트 캐싱은 선택이 아닌 필수입니다. Claude Code 팀이 공유한 전략들은 실제 프로덕션 환경에서 수십만 세션을 처리하며 검증된 베스트 프랙티스입니다.

설치 및 시작:

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# 프로젝트에서 실행
cd your-project
claude

Claude Code는 Native Install 방식으로 설치하면 자동 업데이트가 활성화되어 최신 기능과 보안 패치를 자동으로 받을 수 있습니다.

결론: 설계 단계부터 캐시를 고려하라​

프롬프트 캐싱은 단순히 비용을 줄이는 최적화 기법이 아닙니다. 이것은 다음을 결정짓는 핵심 설계 원칙입니다:

• 사용자 경험: 응답 속도가 빠른 에이전트는 사용자 만족도와 리텐션을 크게 향상시킵니다
• 비즈니스 모델: 90%의 비용 절감은 수익성과 확장성을 직접적으로 개선합니다
• 시스템 안정성: 캐시 히트율을 SLA로 관리하면 예측 가능한 운영이 가능합니다

AI 에이전트를 개발할 때 프로토타입 단계부터 프롬프트 레이아웃을 캐시 친화적으로 설계하는 것이 현대적인 AI 엔지니어링의 표준입니다. 나중에 리팩토링하려면 훨씬 큰 비용이 들기 때문입니다.

Claude Code 팀의 5가지 골든 룰을 따르고, 캐시 히트율을 핵심 지표로 모니터링하면, 비용 효율적이면서도 뛰어난 사용자 경험을 제공하는 AI 에이전트를 구축할 수 있습니다.

References​

• AI 에이전트 최적화의 핵심: 프롬프트 캐싱(Prompt Caching) - LinkedIn Post
• Claude Code Documentation - Getting Started

TL;DR​

OpenAI의 공동 창립자 Ilya Sutskever가 John Carmack에게 제시한 약 30편의 딥러닝 필독 논문 목록입니다. "이것들을 제대로 학습하면 오늘날 중요한 것의 90%를 알게 될 것"이라는 말과 함께 공유된 이 리스트는 Transformer 아키텍처, RNN/LSTM, ResNet 같은 핵심 모델부터 복잡도 이론과 Kolmogorov Complexity 같은 이론적 기초까지 망라합니다. 현대 딥러닝의 필수 개념들을 체계적으로 학습할 수 있는 커리큘럼으로, AI Research Engineer라면 반드시 숙지해야 할 핵심 지식의 정수입니다.

Key Takeaways​

• 선별된 핵심 논문들: 방대한 딥러닝 연구 중에서 실제로 중요한 90%를 커버하는 약 30편으로 압축된 ��리큘럼
• 이론과 실무의 균형: Attention 메커니즘, ResNet 같은 실용적 아키텍처부터 Kolmogorov Complexity, MDL 같은 이론적 기초까지 포괄
• 시대를 초월한 기초: RNN/LSTM 같은 초기 시퀀스 모델부터 Transformer, Scaling Laws까지 진화 과정을 이해할 수 있는 구성
• 실용적 구현 자료: 대부분의 논문에 코드 구현이나 주석이 달린 튜토리얼이 포함되어 있어 학습과 동시에 실습 가능
• 압축과 복잡도 관점: MDL, Kolmogorov Complexity 등을 통해 신경망을 정보 이론적 관점에서 이해하는 깊이 있는 시각 제공

상세 내용​

리딩 리스트의 배경과 의의​

OpenAI의 Chief Scientist이자 공동 창립자인 Ilya Sutskever는 게임 개발의 전설 John Carmack에게 "만약 이것들을 제대로 학습한다면, 오늘날 중요한 것의 90%를 알게 될 것"이라는 말과 함께 이 리스트를 공유했습니다. 이는 단순한 논문 목록이 아니라, 현대 딥러닝의 핵심을 관통하는 체계적인 학습 경로입니다.

이 목록의 특징은 최신 논문만을 추구하지 않고, 시대를 초월한 기본 원리와 실용적인 최신 기술을 균형있게 배치했다는 점입니다. 이론적 기초(Kolmogorov Complexity, MDL)부터 실용적 아키텍처(Transformer, ResNet), 그리고 스케일링 법칙까지 딥러닝의 과거, 현재, 미래를 아우릅니다.

핵심 아키텍처 논문들​

Transformer와 Attention 메커니즘

• Attention Is All You Need (Vaswani et al.): 현대 LLM의 근간이 되는 Transformer 아키텍처의 원조 논문
• The Annotated Transformer: Harvard NLP 팀이 제공하는 line-by-line 구현과 주석. 단순히 논문을 읽는 것을 넘어 실제로 작동하는 코드와 함께 학습 가능
• Neural Machine Translation by Jointly Learning to Align and Translate (Bahdanau et al.): Attention 메커니즘의 초기 제안으로, Transformer 이전에 어떻게 시퀀스 모델에서 선택적 집중이 가능했는지 이해하는 데 필수

RNN과 LSTM의 이해

• The Unreasonable Effectiveness of Recurrent Neural Networks (Andrej Karpathy): RNN의 놀라운 생성 능력을 직관적으로 보여주는 블로그 포스트. 문자 단위 언어 모델이 어떻게 의미 있는 텍스트를 생성하는지 설명
• Understanding LSTM Networks (Christopher Olah): LSTM의 내부 구조를 시각적으로 명쾌하게 설명한 고전적 튜토리얼
• Recurrent Neural Network Regularization (Zaremba et al.): RNN 학습의 실용적 측면을 다루며, dropout 같은 정규화 기법의 적용

Convolutional Networks와 Computer Vision

• ImageNet Classification with Deep Convolutional Neural Networks (AlexNet): 딥러닝 부흥의 시발점이 된 역사적 논문
• Deep Residual Learning for Image Recognition (ResNet): Skip connection을 통해 매우 깊은 네트워크 학습을 가능하게 한 혁신
• Identity Mappings in Deep Residual Networks: ResNet의 개선 버전으로, 왜 특정 구조가 더 잘 작동하는지에 대한 이론적 이해 제공

이론적 기초와 철학​

복잡도와 정보 이론

• The First Law of Complexodynamics (Scott Aaronson): Kolmogorov complexity를 활용하여 물리 시스템의 복잡도가 시간에 따라 어떻게 변하는지 설명. 엔트로피는 단조 증가하지만 "재미있음(interestingness)"은 증가했다 감소한다는 통찰 제공

• Keeping Neural Networks Simple by Minimizing the Description Length of the Weights (Hinton): MDL(Minimum Description Length) 원리를 신경망에 적용. 모델의 복잡도를 가중치를 설명하는 데 필요한 비트 수로 측정

• A Tutorial Introduction to the Minimum Description Length Principle: 압축과 학습의 관계에 대한 근본적 이해. 좋은 모델은 데이터를 잘 압축하는 모델

• Kolmogorov Complexity and Algorithmic Randomness: 객체의 본질적 복잡도를 정의하는 수학적 프레임워크. 일반화와 압축의 관계를 이해하는 이론적 토대

철학적 고려사항

• Machine Super Intelligence (Shane Legg): DeepMind 공동 창립자의 박사 논문. AGI에 대한 수학적이고 철학적인 접근

실용적 기법과 시스템​

스케일링과 병렬화

• Scaling Laws for Neural Language Models (Kaplan et al.): 모델 크기, 데이터, 컴퓨팅의 관계를 정량화한 획기적 연구. 현대 LLM 개발의 나침반 역할

• GPipe: Easy Scaling with Micro-Batch Pipeline Parallelism: 거대 모델을 효율적으로 학습시키기 위한 파이프라인 병렬화 기법

특수 아키텍처와 응용

• Pointer Networks: 출력이 가변 길이 이산 토큰인 문제(조합 최적화 등)를 다루는 혁신적 접근

• Neural Turing Machines: 외부 메모리를 가진 신경망으로, 알고리즘 학습 가능성 탐구

• Deep Speech 2: End-to-end 음성 인식의 실용적 구현

• Order Matters: Sequence to sequence for sets: 순서가 없는 집합을 다루면서도 순서가 중요한 시퀀스 모델의 특성 활용

관계 추론과 구조​

• A simple neural network module for relational reasoning: 객체 간 관계를 추론하는 네트워크 모듈

• Relational recurrent neural networks: RNN에 관계 추론 능력을 부여

• Neural Message Passing for Quantum Chemistry: 그래프 신경망을 화학 분자 특성 예측에 적용

생성 모델과 표현 학습​

• Variational Lossy Autoencoder: VAE의 개선된 형태로, 더 나은 생성과 압축의 균형

교육 자료​

• CS231n: Convolutional Neural Networks for Visual Recognition: Stanford의 유명한 딥러닝 강의. 체계적인 기초 학습을 위한 커리큘럼

학습 순서와 전략​

이 리스트를 효과적으로 학습하기 위한 제안:

1. 기초부터 시작: CS231n으로 기본 개념 확립
2. RNN 계열 이해: Karpathy와 Olah의 블로그로 직관 형성 → LSTM 정규화로 실용 지식 습득
3. Attention과 Transformer: Bahdanau attention → Transformer 논문 → Annotated Transformer로 구현까지
4. 컴퓨터 비전 기초: AlexNet → ResNet으로 발전 과정 이해
5. 이론적 심화: MDL, Kolmogorov Complexity로 깊이 있는 이해
6. 스케일링과 실용화: Scaling Laws, GPipe 등으로 현대적 관점 확보

대부분의 자료가 코드나 상세한 튜토리얼과 함께 제공되므로, 단순히 읽는 것을 넘어 직접 구현하고 실험하는 것이 핵심입니다. The Annotated Transformer처럼 working notebook 형태의 자료들은 학습과 실습을 동시에 가능하게 합니다.

References​

• Original Reading List - Ilya 30u30 Folder
• The Annotated Transformer
• The Annotated Transformer - GitHub
• The First Law of Complexodynamics - Scott Aaronson
• The Unreasonable Effectiveness of Recurrent Neural Networks - Andrej Karpathy
• Understanding LSTM Networks - Christopher Olah
• char-rnn GitHub Repository
• Recurrent Neural Network Regularization (ArXiv)
• LSTM Regularization Code
• Attention Is All You Need
• Scaling Laws for Neural Language Models

TL;DR​

디퓨전(diffusion) 기반 LLM은 기존 오토리그레시브 방식과 달리 여러 토큰을 병렬로 생성·정제하여 5~10배 빠른 추론 속도를 제공합니다. 이미지 생성에 혁신을 가져온 디퓨전 기술이 텍스트 생성으로 확장되고 있으며, 내장된 오류 수정 메커니즘과 메모리 대역폭 효율성이 핵심 장점입니다. 한편 엔터프라이즈 AI 도입에서는 기술보다 ROI가 우선이며, 레거시 시스템 통합과 실질적 비즈니스 가치 측정이 성공의 핵심입니다.

Key Takeaways​

• 디퓨전 LLM의 병렬 처리: 순차적 토큰 생성 대신 여러 토큰을 동시에 생성·정제하여 유사 품질 대비 5~10배 속도 향상 달성
• 메모리 효율성이 속도의 핵심: 가중치를 한 번 로드하여 여러 토큰에 적용하므로 메모리 대역폭 병목 현상을 크게 완화
• 내장된 오류 수정 메커니즘: 반복 정제 과정에서 자체적으로 실수를 교정할 수 있는 구조적 장점 (단, 환각 문제는 여전히 존재)
• 엔터프라이즈 AI는 ROI First: AI 투자 1달러당 실제 가치를 추적하는 것이 기술 선택보다 우선이며, TCO 기반 ROI 계산이 필수
• 레거시 시스템이 실제 시장: COBOL과 메인프레임 같은 레거시 코드 유지보수가 바이브코딩 도구보다 실질적 수요가 크며, 특화 LLM이 필요

상세 내용​

디퓨전 LLM의 작동 원리와 차별점​

기존 LLM(ChatGPT, Gemini 등)은 토큰을 왼쪽에서 오른쪽으로 하나씩 순차 생성하는 오토리그레시브(autoregressive) 방식을 사용합니다. 이는 본질적으로 순차적 연산이라 구조적 병목이 발생할 수밖에 없습니다.

반면 Inception이 개발 중인 디퓨전 LLM은 완전히 다른 접근법을 취합니다. 랜덤 토큰으로 시작해 여러 토큰을 병렬로 동시에 수정하면서 점진적으로 정제(denoising)합니다. 이는 이미지 디퓨전 모델이 노이즈 이미지에서 선명한 결과물을 만들어가는 것과 동일한 원리입니다.

학습 방식의 근본적 차이​

학습 방법론도 근본적으로 다릅니다:

• 기존 LLM: "다음 토큰 예측(next token prediction)" 목표로 학습
• 디퓨전 LLM: 깨끗한 텍스트에 의도적으로 오류를 주입한 뒤 "실수를 교정(error correction)" 하도록 학습

추론 시에도 이 철학이 이어져, 한 번에 최대한 많은 실수를 고치면서 깨끗한 출력을 만들어갑니다.

5~10배 속도 향상의 비밀: 메모리 대역폭​

디퓨전 LLM이 유사한 품질의 오토리그레시브 모델 대비 5~10배 빠른 이유는 메모리 대역폭 효율 덕분입니다.

기존 LLM은 각 토큰을 생성할 때마다 가중치를 메모리에서 로드해야 합니다. 이 과정에서 메모리 대역폭이 병목이 됩니다. 반면 디퓨전 모델은 가중치를 한 번 로드하면 여러 토큰에 동시에 적용할 수 있어 메모리 이동 횟수를 획기적으로 줄입니다.

내장된 오류 수정 메커니즘​

오토리그레시브 모델의 근본적 한계는 한 번 출력한 토큰을 되돌릴 수 없다는 점입니다. 한 번 잘못된 방향으로 가면 계속 잘못된 경로를 따라갈 수밖에 없습니다.

디퓨전 모델은 반복 정제 과정에서 실수를 수정할 수 있는 메커니즘이 구조적으로 내장되어 있습니다. 다만 Stefano Ermon CEO는 솔직하게 환각(hallucination) 문제가 완전히 해결된 것은 아니라고 인정했습니다.

현재 직면한 기술적 도전들​

디퓨전 LLM이 극복해야 할 과제들:

1. 반복 루프 문제 비슷한 내용을 계속 반복 생성하는 현상이 발생합니다. 이는 이미지 디퓨전의 "손가락 6개 문제"에 해당하며, Google의 Gemini Diffusion에서도 동일한 문제가 관찰되었습니다.

2. 가변 길이 처리 이미지는 고정 크기(예: 512×512)이지만 텍스트는 길이가 가변적입니다. 이를 처리하는 것이 핵심 기술적 도전입니다.

3. 이산(discrete) 데이터 처리 디퓨전 수학은 본질적으로 연속적입니다(편미분방정식, Fokker-Planck 방정식 기반). 반면 토큰은 유한하고 이산적이라, 이를 변환하는 새로운 수학적 프레임워크가 필요했습니다.

4. 설계 선택의 재검토 토크나이저를 비롯한 많은 설계 요소들이 오토리그레시브 모델에 최적화되어 있습니다. 디퓨전 모델에는 비최적적이며, 아직 개선 여지가 많습니다.

미래 방향: 추론, 새로운 아키텍처, 월드 모델​

Inception은 현재 추론(reasoning) 능력을 개발 중이며, 기존 o1이나 DeepSeek 방식과는 완전히 다른 접근이라고 합니다.

또한 트랜스포머 외에 상태 기반 모델(State Space Model) 같은 대안 아키텍처와도 결합 가능합니다. 월드 모델(world model) 분야에서는 디퓨전이 이미 핵심 기술로 자리잡고 있다고 언급했습니다.

ROI First: 엔터프라이즈 AI의 실질적 접근법​

업계에 "AI First", "Data First" 같은 버즈워드가 넘쳐나지만, Roomie의 Aldo Luévano 회장은 경영진이 실제로 원하는 것은 **"ROI First"**라고 강조합니다.

Roomie의 핵심 철학은 명확합니다: AI에 투자한 1달러당 얼마의 가치가 돌아오는지 추적하는 것입니다. 이를 위해 플랫폼에 ROI 추적 모듈을 내장했습니다.

프로세스는 다음과 같습니다:

1. 컨설턴트가 GPT 기반 대화를 통해 비즈니스 요구사항 파악
2. 수동/반자동 프로세스의 현재 TCO(Total Cost of Ownership) 계산
3. AI 도입 후의 TCO 예측
4. ROI 산출 및 추적

레거시 시스템: 간과된 거대 시장​

Cursor, Replit, Lovable 같은 바이브코딩 도구는 새로운 소프트웨어를 만드는 데 초점이 맞춰져 있습니다. 하지만 Luévano는 실제 시장의 대부분은 메인프레임과 COBOL 같은 레거시 시스템이라고 지적합니다.

Roomie는 11년간 금융, 은행, 소비재, 유통, 공공부문 등 다양한 프로젝트 경험에서 축적한 데이터로 모델을 학습시켰습니다. 특히 자연어로 레거시 코드의 유지보수와 신규 기능 개발을 지원하는 특화 LLM/SLM을 보유하고 있습니다.

COBOL 개발자들이 고령화되고 있어 이 문제가 더욱 절실해지고 있으며, 이는 많은 기업들이 직면한 실질적 과제입니다.

피지컬 AI와 로보틱스 통합​

Roomie는 원래 B2B 로보틱스 스타트업으로 시작했으며, 현재도 물리적 AI 모듈을 운영합니다.

에이전틱 AI와 물리적 디바이스(휴머노이드 로봇, 엣지 디바이스)를 통합하며, **컴퓨터 비전(CNN 기반)**으로 다음을 수행합니다:

• 공장 피킹(picking)
• 셀프 체크아웃
• 이상 패턴 감지

차별점은 단순 알림이 아니라, 패턴 인식 후 에이전트가 실제 액션을 취한다는 점입니다.

AI와 일자리: 솔직한 대화​

많은 회사들이 "AI가 일자리를 줄이지 않는다"고 말하지만, Luévano는 AI 도입이 인력 감축으로 이어질 수 있음을 솔직하게 인정했습니다.

다만 동시에 새로운 직종도 생겨날 것이라고 언급했습니다:

• 로봇 원격 조작
• 로봇 훈련 및 관리
• AI/로보틱스 UI 관리

이것이 사회 전체의 전환 과정이며, 투명한 대화가 필요하다는 입장입니다.

References​

• Generating text with diffusion (and ROI with LLMs) - Stack Overflow Blog
• Inception - Diffusion Language Models
• Roomie - Enterprise AI and Robotics Platform