586 lines
29 KiB
Markdown
586 lines
29 KiB
Markdown
# AI 에이전트 기술 동향 세미나
|
|
### 2026년 3월 | 시장 조사 · 논문 분석 · 핵심 기술 해설
|
|
|
|
> **발표 대상**: 기술임원
|
|
> **발표자**: AX연구소 AI팀
|
|
|
|
---
|
|
|
|
## 1. 시장 트렌드 — AI 코딩 도구의 현재
|
|
|
|
### 산업 전환: "웹 채팅" → "데스크탑 에이전트"
|
|
|
|
2024년까지 AI는 브라우저 안의 채팅(ChatGPT, Claude.ai)이 주류였습니다.
|
|
2026년 현재, **모든 주요 서비스가 데스크탑/터미널 네이티브로 전환**했습니다.
|
|
|
|
```
|
|
2024 2025 2026
|
|
──────────────────────────────────────────────────────────────────
|
|
웹 채팅 시대 전환기 데스크탑 에이전트 시대
|
|
───────────── ────── ────────────────
|
|
코드를 복사해서 붙여넣기 Claude Code 출시 AI가 로컬 파일을
|
|
결과를 수동으로 적용 Cursor 에이전트 모드 직접 읽고, 쓰고, 실행
|
|
파일을 업로드/다운로드 Windsurf Cascade 빌드·테스트·Git 자동화
|
|
실행 환경과 완전 분리 GitHub Copilot Agent 이슈→코드→PR 자동화
|
|
```
|
|
|
|
**왜 데스크탑인가?**
|
|
|
|
| 웹 AI의 한계 | 데스크탑 AI의 해법 |
|
|
|-------------|-------------------|
|
|
| 코드를 복사해서 붙여넣기 | **프로젝트 전체를 AI가 직접 탐색** |
|
|
| 결과를 수동으로 적용 | **파일을 AI가 직접 수정** |
|
|
| 별도 브라우저 탭 전환 | **런처/단축키로 즉시 호출** |
|
|
| 실행 환경과 분리 | **빌드·테스트·Git을 AI가 직접 실행** |
|
|
|
|
> **핵심**: AI가 실제 생산성을 높이려면 **사용자의 실제 데이터에 직접 접근**해야 합니다.
|
|
|
|
### 시장 규모와 채택률
|
|
|
|
- 개발자의 **85%가 AI 코딩 도구를 일상 사용** (GitHub Survey 2026)
|
|
- 단순 자동완성 → **자율 에이전트**로 빠르게 전환 중
|
|
- 주요 플레이어 간 **에이전트 지능 경쟁**이 핵심 전장
|
|
|
|
---
|
|
|
|
## 2. 주요 서비스 현황과 포지셔닝
|
|
|
|
### 서비스별 포지션 맵
|
|
|
|
```
|
|
고수준 자율성
|
|
│
|
|
Claude Code ● ● Cursor
|
|
│
|
|
● ● Windsurf
|
|
│
|
|
GitHub Copilot ●│
|
|
│
|
|
─────────────────── │ ──────────────────────
|
|
터미널 기반 │ IDE 통합
|
|
│
|
|
Raycast ●│ ● Flow Launcher
|
|
│
|
|
단순 도구
|
|
```
|
|
|
|
### Claude Code (Anthropic) — 터미널 에이전트의 기준
|
|
|
|
| 핵심 기능 | 설명 |
|
|
|-----------|------|
|
|
| **SWE-bench 80.8%** | 업계 최고 소프트웨어 엔지니어링 벤치마크 달성 |
|
|
| **서브에이전트 10팀 동시** | 복잡한 작업을 10개 병렬 에이전트로 분할 실행 |
|
|
| **Plan Mode** | 실행 전 계획 수립 → 사용자 승인 → 실행. 실수를 사전에 방지 |
|
|
| **MCP 프로토콜** | Model Context Protocol — 외부 도구 연결 표준 직접 제정 |
|
|
| **Skills** | 마크다운 기반 재사용 워크플로우 정의 |
|
|
| **Hooks** | 도구 실행 전후에 사용자 스크립트를 자동 실행 |
|
|
| **1M 토큰 컨텍스트** | Opus 4.6 모델로 대규모 코드베이스 전체를 한 번에 분석 |
|
|
|
|
### Cursor — IDE 통합 에이전트의 선두
|
|
|
|
| 핵심 기능 | 설명 |
|
|
|-----------|------|
|
|
| **멀티파일 에이전트** | 프로젝트 전체를 이해하고 여러 파일을 동시 수정 |
|
|
| **백그라운드 에이전트 8개** | 클라우드에서 8개 에이전트를 병렬 실행하여 작업 분산 |
|
|
| **Tab 자동완성** | 다음 코드 흐름을 예측 → Tab 한 번으로 승인 |
|
|
| **프로젝트 규칙** | `.cursorrules` 파일로 프로젝트별 AI 행동을 커스터마이징 |
|
|
| **멀티파일 Diff** | 변경된 모든 파일을 한 화면에서 파일별/헌크별 승인/거부 |
|
|
| **러닝 메모리** | 사용자 피드백 기반으로 코딩 스타일을 자동 학습 |
|
|
| **LSP 통합** | 언어 서버 프로토콜로 코드 구조를 의미 기반 분석 |
|
|
|
|
### GitHub Copilot — 개발 파이프라인 자동화
|
|
|
|
| 핵심 기능 | 설명 |
|
|
|-----------|------|
|
|
| **코딩 에이전트** | 이슈 할당 → 코드 작성 → PR 생성 → 테스트까지 자동 파이프라인 |
|
|
| **자동 PR 생성** | 이슈 번호만 할당하면 코드 변경 + PR을 자동 생성 |
|
|
| **반복 테스트-수정** | 테스트 실패 → 원인 분석 → 코드 수정 → 재실행을 자동 반복 |
|
|
| **Multi-Agent** | 코드리뷰·테스트·문서 작성을 각각 전담하는 에이전트 협업 |
|
|
|
|
### Windsurf — 컨텍스트 지능
|
|
|
|
| 핵심 기능 | 설명 |
|
|
|-----------|------|
|
|
| **Cascade** | 복잡한 작업을 단계별로 분해하여 멀티스텝 에이전트가 실행 |
|
|
| **48시간 자동 인덱싱** | 코드베이스를 48시간 주기로 자동 분석, 관련 파일을 사전 수집 |
|
|
| **영속 메모리** | 세션이 끝나도 이전 작업 기억을 유지, 프로젝트 컨텍스트 누적 학습 |
|
|
| **브라우저 통합** | 웹 페이지 내용을 에이전트가 직접 참조하여 코드에 반영 |
|
|
|
|
### Raycast — 런처 + AI 융합 (macOS)
|
|
|
|
| 핵심 기능 | 설명 |
|
|
|-----------|------|
|
|
| **1,500+ 확장 생태계** | 커뮤니티 기반 확장 프로그램 스토어 |
|
|
| **Auto 모델** | 작업 유형에 따라 GPT/Claude/Gemini 중 최적 모델 자동 선택 |
|
|
| **AI 스니펫** | `;email {수신자} {주제}` → AI가 이메일 초안을 즉시 생성 |
|
|
| **리치 클립보드** | 이미지·링크 프리뷰·코드 하이라이트가 있는 고급 클립보드 |
|
|
|
|
### 서비스별 기능 비교 매트릭스
|
|
|
|
| 기능 | Claude Code | Cursor | Copilot | Windsurf | Raycast |
|
|
|------|:-----------:|:------:|:-------:|:--------:|:-------:|
|
|
| 에이전트 루프 | ✅ | ✅ | ✅ | ✅ | ❌ |
|
|
| MCP 프로토콜 | ✅ | ✅ | ✅ | ❌ | ❌ |
|
|
| 서브에이전트 (병렬) | 10팀 | 8개 | 다중 | ❌ | ❌ |
|
|
| Plan Mode | ✅ | ❌ | ❌ | ❌ | ❌ |
|
|
| LSP 코드 분석 | 자체 | ✅ | ✅ | ✅ | ❌ |
|
|
| 에이전트 메모리 | ✅ | ✅ | ✅ | ✅ | ❌ |
|
|
| 프로젝트 규칙 | ✅ | ✅ | ❌ | ❌ | ❌ |
|
|
| 자동 테스트-수정 | ✅ | ❌ | ✅ | ❌ | ❌ |
|
|
| 런처 통합 | ❌ | ❌ | ❌ | ❌ | ✅ |
|
|
| 오프라인 동작 | ❌ | ❌ | ❌ | ❌ | ❌ |
|
|
|
|
---
|
|
|
|
## 3. 핵심 기술 개요 — 에이전트를 구성하는 7대 축
|
|
|
|
Agentic Coding Survey (arXiv 2025)는 AI 코딩 에이전트의 기술 지형을 **7대 축**으로 정리합니다:
|
|
|
|
| # | 기술 축 | 핵심 질문 | 대표 서비스 |
|
|
|---|---------|-----------|-------------|
|
|
| 1 | **계획 (Planning)** | 어떤 순서로 작업할 것인가? | Claude Code Plan Mode |
|
|
| 2 | **도구 사용 (Tool Use)** | 파일·검색·빌드를 어떻게 호출하는가? | 전체 (Function Calling) |
|
|
| 3 | **메모리 (Memory)** | 이전 작업을 어떻게 기억하는가? | Windsurf, Cursor |
|
|
| 4 | **성찰 (Reflection)** | 실패를 어떻게 분석하고 재시도하는가? | Claude Code |
|
|
| 5 | **협업 (Multi-Agent)** | 여러 에이전트가 어떻게 분업하는가? | GitHub Copilot, Claude Code |
|
|
| 6 | **검색 (Retrieval)** | 관련 코드를 어떻게 찾는가? | Cursor, Windsurf |
|
|
| 7 | **검증 (Verification)** | 결과가 맞는지 어떻게 확인하는가? | GitHub Copilot |
|
|
|
|
이하 섹션에서 각 기술의 **학술 근거, 작동 원리, 적용 서비스, 효과**를 설명합니다.
|
|
|
|
---
|
|
|
|
## 4. 기술별 상세
|
|
|
|
### 4-1. Function Calling — 에이전트의 "손과 발"
|
|
|
|
**개념**: LLM은 텍스트만 출력할 수 있습니다. 파일을 읽거나 코드를 실행하는 것은 불가능합니다.
|
|
Function Calling은 LLM이 **"이 도구를 이 파라미터로 호출해줘"라는 요청서를 JSON으로 출력**하면, 앱이 실제로 실행하는 구조입니다.
|
|
|
|
```
|
|
┌───────────────────────────────────────────┐
|
|
│ ① 앱 → LLM │
|
|
│ 사용자 메시지 + 도구 목록 (JSON Schema) │
|
|
│ "이 중에 쓸 게 있으면 JSON으로 출력해" │
|
|
└────────────────┬──────────────────────────┘
|
|
▼
|
|
┌───────────────────────────────────────────┐
|
|
│ ② LLM → 텍스트 출력 (이게 전부) │
|
|
│ { "tool": "file_write", │
|
|
│ "arguments": { "path": "report.html",│
|
|
│ "content": "<h1>보고서</h1>..." │
|
|
│ } │
|
|
│ } │
|
|
│ → 이것도 그냥 텍스트. 실제 파일을 만든 │
|
|
│ 건 아님. │
|
|
└────────────────┬──────────────────────────┘
|
|
▼
|
|
┌───────────────────────────────────────────┐
|
|
│ ③ 앱 → 실제 실행 │
|
|
│ 1. JSON 파싱 │
|
|
│ 2. File.WriteAllText() 실행 │
|
|
│ 3. 결과를 다시 LLM에게 전달 │
|
|
│ 4. LLM이 다음 행동 결정 │
|
|
└───────────────────────────────────────────┘
|
|
```
|
|
|
|
**업계 표준**: OpenAI, Anthropic, Google, Ollama 등 **모든 LLM API**가 동일한 방식.
|
|
"Function Calling" 또는 "Tool Use"라고 불리며, 2024년 이후 에이전트의 핵심 인프라.
|
|
|
|
| LLM 서비스 | 도구 호출 방식 |
|
|
|-----------|--------------|
|
|
| Ollama / vLLM | OpenAI 호환 tools 파라미터 |
|
|
| Gemini | functionDeclarations |
|
|
| Claude | tool_use 블록 |
|
|
|
|
**모델 성능에 따른 차이**: 도구 호출은 LLM이 올바른 JSON을 출력해야 하므로 모델 성능에 의존합니다.
|
|
|
|
| 모델 수준 | 도구 호출 정확도 | 예시 |
|
|
|----------|:---:|------|
|
|
| 대형 모델 | ✅ 정확 | Claude Opus, GPT-4, Gemini Pro |
|
|
| 중형 모델 | ⚠️ 대부분 OK | Gemini Flash, Qwen-30B |
|
|
| 경량 모델 | ❌ 종종 실패 | Gemini Flash Lite, 소형 로컬 모델 |
|
|
|
|
**관련 논문**: SWE-Agent v2 (Yang et al., Princeton 2025) — **Agent-Computer Interface (ACI)** 설계
|
|
|
|
---
|
|
|
|
### 4-2. Plan Mode — 계획 후 실행
|
|
|
|
**개념**: 에이전트가 도구를 즉시 실행하지 않고, **먼저 구조화된 실행 계획을 생성 → 사용자가 검토/수정/승인 → 승인 후 실행**하는 패턴.
|
|
|
|
```
|
|
사용자 요청: "인증 모듈을 JWT로 교체해줘"
|
|
│
|
|
▼
|
|
┌─ 계획 수립 (도구 호출 차단) ──────────────┐
|
|
│ 1. 현재 인증 로직 분석 (grep, file_read) │
|
|
│ 2. JWT 라이브러리 설치 (process) │
|
|
│ 3. 토큰 생성/검증 모듈 작성 (file_write) │
|
|
│ 4. 기존 세션 로직 교체 (file_edit) │
|
|
│ 5. 단위 테스트 작성 및 실행 (test_loop) │
|
|
│ 6. Git 커밋 (git_tool) │
|
|
└────────────────┬──────────────────────────┘
|
|
▼
|
|
[승인] [수정] [취소] ← 사용자 검토
|
|
│
|
|
▼ 승인
|
|
계획대로 순차 실행
|
|
```
|
|
|
|
**왜 필요한가?** — FeatureBench (Anthropic 2025)
|
|
|
|
| 벤치마크 | AI 성능 | 의미 |
|
|
|----------|:------:|------|
|
|
| SWE-bench (버그 수정) | **80%+** | 에이전트가 매우 잘하는 영역 |
|
|
| FeatureBench (신기능 구현) | **11~12%** | 에이전트가 아직 어려운 영역 |
|
|
|
|
> 에이전트는 **"기존 코드 수정"은 잘하지만 "새로운 기능 설계"는 인간 감독이 필수**.
|
|
> Plan Mode는 이 한계를 인정하고 **인간-루프(Human-in-the-Loop)** 를 전제로 설계된 패턴.
|
|
|
|
**적용 서비스**: Claude Code (Plan Mode), GitHub Copilot Workspace
|
|
|
|
---
|
|
|
|
### 4-3. Reflexion — 실패에서 배우는 에이전트
|
|
|
|
**논문**: Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., NeurIPS 2023)
|
|
|
|
**핵심 아이디어**: 에이전트가 실패하면 **"왜 실패했는지" 자연어로 구조화된 성찰문을 생성**하고, 이를 메모리에 저장하여 다음 시도에 활용합니다.
|
|
|
|
```
|
|
에이전트 실행
|
|
│
|
|
▼
|
|
실행 결과 관찰
|
|
│
|
|
├── 성공 → 완료
|
|
│
|
|
└── 실패 → 구조화된 자기 성찰 (Self-Reflection)
|
|
│
|
|
│ "파일 경로를 상대경로로 지정했으나 작업 폴더가
|
|
│ 다른 위치였다. 다음에는 절대 경로를 사용하거나
|
|
│ 먼저 현재 작업 디렉터리를 확인해야 한다."
|
|
│
|
|
▼
|
|
성찰 결과를 메모리에 저장
|
|
│
|
|
▼
|
|
다음 시도에 성찰 결과 주입 → 재시도
|
|
```
|
|
|
|
**효과**:
|
|
|
|
| 벤치마크 | 일반 에이전트 | Reflexion 적용 | 향상 |
|
|
|----------|:-----------:|:-------------:|:----:|
|
|
| HumanEval (Python) | 80.1% | **91.0%** | +10.9% |
|
|
| MBPP (Python) | 72.4% | **77.1%** | +4.7% |
|
|
| AlfWorld (작업 수행) | 75% | **97%** | +22% |
|
|
|
|
**핵심 차이**: 기존의 단순 재시도(같은 프롬프트로 다시 실행)와 달리, **실패 원인을 분석한 텍스트를 다음 프롬프트에 추가**하여 같은 실수를 반복하지 않음.
|
|
|
|
**적용 서비스**: Claude Code (에러 후 자동 성찰), GitHub Copilot (반복 수정 루프)
|
|
|
|
---
|
|
|
|
### 4-4. Agent-Computer Interface (ACI) — LLM을 위한 도구 설계
|
|
|
|
**논문**: SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering (Yang et al., Princeton 2024-2025)
|
|
|
|
**핵심 아이디어**: 에이전트의 성능은 LLM 모델 자체보다 **LLM이 사용하는 도구의 설계**에 크게 좌우됩니다. 사람을 위한 UI(GUI)가 아닌, **LLM을 위해 최적화된 도구 인터페이스(ACI)** 를 설계해야 합니다.
|
|
|
|
**ACI 설계 원칙**:
|
|
|
|
| 원칙 | 나쁜 설계 | 좋은 설계 (ACI) |
|
|
|------|----------|----------------|
|
|
| 출력 간결성 | `ls -la` 전체 출력 (수백 줄) | 필요한 정보만 구조화하여 반환 |
|
|
| 명확한 파라미터 | 복잡한 플래그 조합 | JSON Schema로 정의된 명확한 파라미터 |
|
|
| 에러 메시지 | 스택 트레이스 전체 | 원인 + 해결 방법을 한 줄로 요약 |
|
|
| 상태 피드백 | "완료" | "3개 파일 수정, 테스트 5/5 통과" |
|
|
|
|
**효과**: 동일한 LLM 모델이라도 ACI를 잘 설계하면 SWE-bench에서 **12~23%p 성능 향상**.
|
|
|
|
**적용 서비스**: Claude Code (커스텀 CLI 도구), SWE-Agent (전용 도구 셋)
|
|
|
|
---
|
|
|
|
### 4-5. CodeAct — 코드로 행동하는 에이전트
|
|
|
|
**논문**: CodeAct: Code Actions for Multi-Turn Agent Interactions (Wang et al., 2024)
|
|
|
|
**핵심 아이디어**: 에이전트의 행동(Action)을 JSON 도구 호출 대신 **실행 가능한 코드**로 표현합니다.
|
|
|
|
```
|
|
일반 도구 호출 (JSON) CodeAct (코드)
|
|
────────────────── ──────────────
|
|
{"tool": "search", import os
|
|
"args": {"query": "auth"}} results = []
|
|
for f in os.listdir('src'):
|
|
{"tool": "file_read", if 'auth' in f.lower():
|
|
"args": {"path": "src/auth.py"}} with open(f'src/{f}') as fh:
|
|
results.append(fh.read())
|
|
→ 2번의 도구 호출 필요 → 1번의 코드 실행으로 복잡한 로직 표현
|
|
```
|
|
|
|
**효과**: 멀티턴 대화에서 작업 성공률 **20%+ 향상**. 복잡한 조건 분기, 반복, 예외 처리를 한 번에 표현할 수 있어 도구 호출 횟수가 줄고 정확도가 올라감.
|
|
|
|
**적용 서비스**: Claude Code (bash 도구), OpenCode, Aider (코드 실행 에이전트)
|
|
|
|
---
|
|
|
|
### 4-6. 에이전트 메모리 — 세션을 넘어서 기억하는 AI
|
|
|
|
**개념**: 대화가 끝나면 모든 문맥이 사라지는 기존 LLM과 달리, **프로젝트 수명 주기 전체에 걸쳐 학습한 내용을 유지**하는 구조.
|
|
|
|
```
|
|
세션 1: "이 프로젝트는 camelCase를 쓰고, 테스트는 Jest를 사용합니다"
|
|
│
|
|
▼ 저장
|
|
세션 2: (새 대화) AI가 자동으로 camelCase + Jest 스타일로 코드 작성
|
|
│
|
|
▼ 누적
|
|
세션 N: 프로젝트의 아키텍처, 관례, 의사결정 이력을 모두 기억
|
|
```
|
|
|
|
**메모리 계층** (CrewAI/LangChain 연구 기반):
|
|
|
|
| 계층 | 역할 | 예시 |
|
|
|------|------|------|
|
|
| **단기 기억** | 현재 대화의 도구 호출 이력 | "방금 auth.py를 읽었으니 다시 안 읽어도 됨" |
|
|
| **에피소드 기억** | 과거 작업의 성공/실패 경험 | "지난번에 이 패턴으로 하니까 빌드 실패했었음" |
|
|
| **영속 기억** | 프로젝트 규칙, 코딩 관례 | "이 프로젝트는 항상 ESLint를 통과해야 함" |
|
|
|
|
**적용 서비스**: Windsurf (영속 메모리), Cursor (러닝 메모리), Claude Code (CLAUDE.md 프로젝트 파일)
|
|
|
|
---
|
|
|
|
### 4-7. MCP (Model Context Protocol) — 도구 연결 표준
|
|
|
|
**제정**: Anthropic (2025년 12월)
|
|
|
|
**개념**: LLM 에이전트가 외부 도구/서비스에 접근하는 **표준 프로토콜**.
|
|
각 서비스마다 다른 연동 방식을 쓰는 대신, **하나의 표준으로 통일**.
|
|
|
|
```
|
|
┌──────────────┐ JSON-RPC 2.0 ┌──────────────┐
|
|
│ AI 에이전트 │ ◄─────────────────► │ MCP 서버 A │ (JIRA)
|
|
│ (MCP 클라이언트) │ │ │
|
|
│ │ ◄─────────────────► │ MCP 서버 B │ (Slack)
|
|
│ │ │ │
|
|
│ │ ◄─────────────────► │ MCP 서버 C │ (DB 조회)
|
|
└──────────────┘ └──────────────┘
|
|
│
|
|
├── 서버의 도구(tools) 목록 자동 발견
|
|
├── 에이전트 도구로 자동 래핑 (LLM에게 구분 없이 노출)
|
|
└── LLM이 내장 도구와 동일하게 호출
|
|
```
|
|
|
|
**LLM 입장에서**: 내장 도구와 MCP 도구의 구분이 없습니다.
|
|
|
|
```
|
|
도구 목록 (LLM에게 전달):
|
|
file_read ← 내장
|
|
file_write ← 내장 LLM은 이 구분을
|
|
jira_search ← MCP 모릅니다.
|
|
slack_send ← MCP 그냥 목록에서
|
|
db_query ← MCP 골라서 호출할 뿐.
|
|
```
|
|
|
|
**업계 채택**: Claude Code, Cursor, GitHub Copilot, OpenCode 등 모든 주요 서비스가 지원.
|
|
|
|
---
|
|
|
|
### 4-8. LSP (Language Server Protocol) — 의미 기반 코드 분석
|
|
|
|
**제정**: Microsoft
|
|
|
|
**개념**: 텍스트 검색(grep)이 아닌 **코드의 의미 구조**를 기반으로 분석.
|
|
|
|
```
|
|
텍스트 검색 (grep) LSP 기반 분석
|
|
────────────────── ──────────────
|
|
"authenticate" 글자 포함 줄 반환 함수 정의 위치 정확히 반환
|
|
→ 주석/문자열에 있는 것도 포함 → "이 함수를 호출하는 곳" 목록
|
|
→ 동의어("auth", "login") 누락 → 타입, 시그니처, 참조 관계 분석
|
|
→ 노이즈가 많음 → 정확도 높음
|
|
```
|
|
|
|
**적용 서비스**: Cursor (OmniSharp, pyright 등), GitHub Copilot, Windsurf
|
|
|
|
---
|
|
|
|
### 4-9. Multi-Agent — 역할 기반 에이전트 팀
|
|
|
|
**개념**: 단일 에이전트 대신 **역할이 다른 여러 에이전트가 메시지를 주고받으며 협업**.
|
|
|
|
```
|
|
┌─────────────────────────────────────────┐
|
|
│ 오케스트레이터 (Orchestrator) │
|
|
│ "JWT 인증 모듈로 교체해줘" │
|
|
│ │
|
|
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
|
│ │ 코드 작성 │ │ 테스트 │ │ 코드 리뷰│ │
|
|
│ │ 에이전트 │ │ 에이전트 │ │ 에이전트 │ │
|
|
│ └─────┬────┘ └────┬─────┘ └────┬─────┘ │
|
|
│ │ 작성 완료 │ 테스트 실패 │ 리뷰 │
|
|
│ └────────► │ ◄──────── ┘ │
|
|
│ ▼ │
|
|
│ 수정 → 재테스트 → 통과 │
|
|
└─────────────────────────────────────────┘
|
|
```
|
|
|
|
**적용 서비스**: Claude Code (서브에이전트 10팀), Cursor (백그라운드 에이전트 8개), GitHub Copilot (Multi-Agent)
|
|
|
|
---
|
|
|
|
## 5. 구현 방법 — 에이전트의 실행 구조
|
|
|
|
### 에이전트 루프 (Agent Loop)
|
|
|
|
모든 AI 코딩 에이전트의 핵심 아키텍처는 **동일한 반복 루프**입니다:
|
|
|
|
```
|
|
사용자 요청
|
|
│
|
|
▼
|
|
┌────────────────────────────────────────┐
|
|
│ 반복 (최대 N회): │
|
|
│ │
|
|
│ ① LLM에게 전송 │
|
|
│ (사용자 메시지 + 도구 목록 + 이력) │
|
|
│ │
|
|
│ ② LLM 응답 수신 │
|
|
│ ├── 텍스트만 → 종료 (최종 답변) │
|
|
│ └── 도구 호출 JSON → ③으로 │
|
|
│ │
|
|
│ ③ 도구 실행 │
|
|
│ · 경로 검증 (작업 폴더 내?) │
|
|
│ · 권한 확인 (Ask/Auto/Deny) │
|
|
│ · 차단 확장자 검사 │
|
|
│ · 실행 → 결과를 이력에 추가 │
|
|
│ │
|
|
│ ④ 결과를 다시 ①로 (다음 반복) │
|
|
│ │
|
|
│ 안전장치: │
|
|
│ · 최대 반복 횟수 제한 │
|
|
│ · 연속 오류 시 자동 중단 │
|
|
│ · 취소 토큰으로 사용자 중단 지원 │
|
|
└────────────────────────────────────────┘
|
|
```
|
|
|
|
### 스킬 시스템 — 업무 지시서
|
|
|
|
스킬은 **LLM에게 주는 업무 지시서**입니다. `.skill.md` 파일 하나로 정의합니다.
|
|
|
|
```yaml
|
|
---
|
|
name: report-writer
|
|
label: 보고서 작성
|
|
allowed-tools: # 이 스킬이 사용할 수 있는 도구를 제한
|
|
- file_read
|
|
- folder_map
|
|
- html_create
|
|
---
|
|
## 지시사항
|
|
1. 작업 폴더의 데이터 파일을 먼저 확인하세요
|
|
2. 핵심 지표를 추출하세요
|
|
3. 전문적인 보고서를 HTML로 작성하세요
|
|
```
|
|
|
|
> 스킬은 도구를 추가하거나 삭제할 수 **없습니다**. "LLM 시스템 프롬프트"로만 작동하며, 실제 도구 목록은 앱이 관리합니다. 따라서 악성 스킬을 로드해도 **앱의 보안 경계를 넘을 수 없습니다**.
|
|
|
|
**표준**: Anthropic이 **SKILL.md** 오픈 포맷(agentskills.io)을 제정하여 스킬 호환성을 표준화.
|
|
|
|
---
|
|
|
|
## 6. 사용자 데이터 보호
|
|
|
|
### 외부 서비스의 보안 구조
|
|
|
|
| 서비스 | 실행 환경 | 격리 방식 | 위험 요소 |
|
|
|--------|-----------|-----------|-----------|
|
|
| **Claude Code** | 터미널 (로컬 PC) | 없음 | 잘못된 `rm -rf` 실행 가능 |
|
|
| **Cursor** | IDE 내장 | 프로젝트 폴더 한정 | 터미널 명령은 제한 없음 |
|
|
| **Devin / Codex** | **Docker 컨테이너** | 완전 격리 | 컨테이너 밖 접근 불가 |
|
|
| **GitHub Copilot Workspace** | **클라우드 VM** | 서버 격리 | 로컬 파일 접근 자체 불가 |
|
|
|
|
> **왜 Docker?**: 터미널 에이전트(Claude Code)는 `rm -rf /`, `curl | bash` 같은 위험 명령을 LLM이 실행할 수 있습니다. Devin/Codex는 이를 해결하기 위해 Docker 컨테이너 안에서만 코드를 실행합니다.
|
|
|
|
### 사내 환경에서의 보안 원칙
|
|
|
|
사내에서 AI 에이전트를 운영하려면 Docker 대신 **앱 레벨에서 3중 방어**가 필요합니다:
|
|
|
|
```
|
|
방어 ①: 워크스페이스 격리
|
|
──────────────────────
|
|
사용자 PC 전체 디스크
|
|
├── C:\Windows\ ← 🚫 차단
|
|
├── C:\Program Files\ ← 🚫 차단
|
|
├── C:\Users\...\AppData\ ← 🚫 차단
|
|
└── D:\Projects\MyProject\ ← ✅ 작업 폴더 (사용자 지정)
|
|
└── AI가 읽고 쓸 수 있는 유일한 영역
|
|
|
|
방어 ②: 파일 접근 동의 (3단계 권한)
|
|
──────────────────────────────
|
|
· Ask — 파일을 쓸 때마다 사용자 확인 팝업
|
|
· Auto — 작업 폴더 내 자동 허용 (숙련자용)
|
|
· Deny — 모든 파일 수정 차단 (읽기만 허용)
|
|
|
|
방어 ③: 삭제 도구 자체가 없음
|
|
────────────────────────────
|
|
· file_read (읽기) ✅
|
|
· file_write (생성/덮어쓰기) ✅
|
|
· file_edit (부분 수정) ✅
|
|
· file_delete → 도구 자체가 존재하지 않음 ❌
|
|
· .exe, .dll, .sys 등 실행 파일 생성 차단
|
|
```
|
|
|
|
> **설계 원칙**: LLM이 "이 파일 삭제해"라고 판단해도, 실행할 도구가 없으므로 **물리적으로 삭제 불가능**.
|
|
|
|
---
|
|
|
|
## 7. 결론 — 기술 방향 제시
|
|
|
|
### 2026년 10대 기술 동향 요약
|
|
|
|
| # | 동향 | 근거 | 영향도 |
|
|
|---|------|------|:------:|
|
|
| 1 | **데스크탑 네이티브 전환** | Claude Code·Cursor·Windsurf 모두 로컬 실행 | ★★★ |
|
|
| 2 | **자율 에이전트 전환** | 자동완성 → 이슈→코드→PR 자동화 파이프라인 | ★★★ |
|
|
| 3 | **계획 후 실행 (Human-in-the-Loop)** | FeatureBench 11% — 인간 감독 필수 인식 확산 | ★★★ |
|
|
| 4 | **성찰 루프 (Reflexion)** | NeurIPS 2023 — 실패 분석→재시도로 정확도 91% | ★★☆ |
|
|
| 5 | **멀티 에이전트 협업** | Claude Code 10팀, Cursor 8개 병렬 실행 | ★★☆ |
|
|
| 6 | **영속 메모리** | 세션→프로젝트 수명 전체 기억 유지 | ★★☆ |
|
|
| 7 | **표준 프로토콜 (MCP, LSP)** | Anthropic MCP 제정, 전 서비스 채택 | ★★☆ |
|
|
| 8 | **ACI 도구 설계** | SWE-Agent — 도구 설계만으로 12~23%p 성능 차이 | ★★☆ |
|
|
| 9 | **런처 + AI 융합** | Raycast — 단축키로 AI 즉시 호출 | ★☆☆ |
|
|
| 10 | **오프라인 AI** | 네트워크 없이 로컬 모델로 기본 작업 처리 | ★☆☆ |
|
|
|
|
### 핵심 메시지
|
|
|
|
```
|
|
① AI 코딩 도구가 "보조 도구"에서 "자율 에이전트"로 전환되었습니다.
|
|
② 에이전트의 핵심 기술(계획·도구·메모리·성찰·협업)은 학술적으로 검증되었습니다.
|
|
③ 그러나 FeatureBench 11%가 보여주듯, 인간 감독은 여전히 필수입니다.
|
|
④ 사내 환경에서는 데이터 보호(워크스페이스 격리, 권한 제어)가 전제 조건입니다.
|
|
⑤ 이 기술들을 사내 환경에 빠르게 적용하는 것이 경쟁력의 핵심입니다.
|
|
```
|
|
|
|
---
|
|
|
|
### 참고 문헌
|
|
|
|
| 논문/자료 | 출처 | 핵심 기여 |
|
|
|-----------|------|-----------|
|
|
| Reflexion: Language Agents with Verbal Reinforcement Learning | Shinn et al., NeurIPS 2023 | 자기 성찰로 코드 생성 정확도 91% 달성 |
|
|
| SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering | Yang et al., Princeton 2024 | ACI 설계 원칙, SWE-bench 80%+ |
|
|
| CodeAct: Code Actions for Multi-Turn Agent Interactions | Wang et al., 2024 | 코드 기반 행동으로 성공률 20%+ 향상 |
|
|
| A Survey on Agentic AI for Software Engineering | arXiv 2025 | 에이전트 코딩 7대 기술 축 체계화 |
|
|
| FeatureBench: Can AI Implement New Features? | Anthropic Research, 2025 | 신기능 구현 11% — 인간 감독 필수 근거 |
|
|
| Model Context Protocol Specification | Anthropic, 2025 | 도구 연결 표준 프로토콜 |
|
|
| SKILL.md Agent Skills Open Format | agentskills.io, 2025 | 에이전트 스킬 표준 포맷 |
|
|
|
|
---
|
|
|
|
*발표 자료 작성: AX연구소 AI팀 | 문의: 내부 메신저*
|