# AI 비서 시스템 아키텍처 논의 기록

> 작성일: 2026-04-05
> 상태: 논의 중

---

## 1. 하드웨어 조건

- **GPU: RTX 3060 12GB × 2장 (총)**
- Machine A: 현재 머신 (Modern CPU, 96GB RAM) → API 서버 전용
- Machine B: i7-7700, 64GB RAM → 워크스테이션 (코딩, Discord 등)
- Machine B는 내장그래픽(HD 630)으로 디스플레이 사용
- Machine A에서 7700+64GB RAM+3060 조합으로 유사한 결과 확인 완료

## 2. GPU 배치 결정: 1+1 vs 2+0

### 2+0 (Machine A에 2장 집중) — 추천

| 장점 | 설명 |
|------|------|
| 코딩 속도 2.5배 향상 | 35B 모델: 30 t/s → 50-80 t/s |
| 모델 완전 VRAM 수용 | 35B (20.5GB) → 24GB에 수용, cpu-moe 불필요 |
| 비서도 오히려 빠름 | API 호출해도 50-80 t/s > 로컬 42 t/s |
| 아키텍처 단순 | LLM 엔드포인트 1곳만 관리 |

| 단점 | 설명 |
|------|------|
| Machine A 의존 | 장애 시 추론 전체 중단 |
| 동시 처리 제한 | 솔로유저라 실질적 문제 적음 |
| 122B 핫스왑 중 비서 중단 (~3-5분) | 빈도 낮으면 수용 가능 |

### 1+1 (각 1장씩)

| 장점 | 설명 |
|------|------|
| 병렬 처리 가능 | 양쪽 동시 추론 |
| 장애 시 독립 동작 | Machine B가 자체 LLM 보유 |
| 122B 핫스왑 중에도 비서 유지 | Machine B가 대체 |

| 단점 | 설명 |
|------|------|
| 코딩 속도 30 t/s (2+0 대비 절반) | 메인 작업 속도 희생 |
| 35B 모델 cpu-moe 의존 | RAM 대역폭 제한 |
| 관리 복잡 | LLM 2곳 관리 |

### 결론: 솔로 유저 + 메인 코딩 → 2+0 추천

---

## 3. Machine A 모델 후보 비교 (2x 3060, 24GB VRAM)

### 모델 스펙 비교

| 모델 | 크기 | 활성 파라미터 | 1x 3060 속도 | **2x 3060 예상** | VRAM 여유 |
|------|:----:|:----------:|:----------:|:-----------:|:---------:|
| **Gemma4 26B-A4B** | 15.6 GB | 4B | 42 t/s | **70-100+ t/s** | 8.4 GB |
| **Qwen3.5 35B-A3B** | 20.5 GB | 3B | 30 t/s | **50-80 t/s** | 3.5 GB |
| Qwen3.5 122B-A10B | 71.3 GB | 10B | 11 t/s | 11 t/s (cpu-moe) | N/A |

### Gemma4 26B-A4B 장점

- **속도**: 15.6 GB로 작아서 VRAM에 여유롭게 수용 → 2x GPU에서 70-100+ t/s 가능
- **도구 호출**: function calling / tool use에 안정적 (구글 설계)
- **VRAM 여유**: 8.4 GB 남음 → 더 큰 컨텍스트, 더 높은 양자화(Q5/Q6), 멀티슬롯 가능
- **로딩 시간**: 15.6 GB → ~20초 (핫스왑 빠름)
- **범용성**: 코딩 + 도구 호출 + 일반 대화 균형

### Qwen3.5 35B-A3B 장점

- **코딩 품질**: Qwen3.5 시리즈가 코딩 벤치마크에서 Gemma4보다 강세
- **추론 능력**: 35B 전체 파라미터 → 더 깊은 지식/추론
- **한국어**: Qwen 시리즈가 한국어 성능 우수
- **3B 활성**: 4B보다 적어 토큰당 읽기 데이터 적음 (그러나 모델 크기가 더 커서 상쇄)

### Qwen3.5 122B-A10B 장점

- **최고 품질**: 122B 파라미터 → 가장 정확하고 깊은 추론
- **복잡한 설계**: 아키텍처 리뷰, 수학, 어려운 디버깅에 탁월
- **단점**: 11 t/s → 일상 사용에는 느림

### 제안: 3단계 핫스왑 전략

```
Fast (기본): Gemma4 26B-A4B → 70-100+ t/s
  └── 빠른 대화, 도구 호출, 간단한 코딩, 비서 업무
  └── 로딩: ~20초

Balanced: Qwen3.5 35B-A3B → 50-80 t/s  
  └── 본격적 코딩, 리팩토링, 복잡한 작업
  └── 로딩: ~30-40초

Deep: Qwen3.5 122B-A10B → ~11 t/s
  └── 아키텍처 설계, 고난도 추론, 심층 분석
  └── 로딩: ~3-5분
```

또는 **자주 쓰는 2개만 유지**:

| 전략 | 기본 모델 | 온디맨드 | 적합한 경우 |
|------|----------|---------|-----------|
| A) 코딩 중심 | Qwen 35B (50-80 t/s) | 122B (11 t/s) | 코딩이 압도적 다수일 때 |
| B) 균형형 | Gemma4 26B (70-100+ t/s) | Qwen 35B (50-80 t/s) | 비서+코딩 혼합일 때 |
| C) 속도형 | Gemma4 26B (70-100+ t/s) | 122B (11 t/s) | 빠른 일상 + 가끔 딥 |

---

## 4. 시스템 구조 (2+0 기준)

```
Machine A (API 서버, 2x 3060, 헤드리스)
┌─────────────────────────┐
│ llama-server             │
│ (포트 8000, OpenAI API)  │
│                          │
│ 모델: Gemma4/Qwen35B/122B│
│ 핫스왑 API (포트 8001?)   │
└────────────┬─────────────┘
             │ REST API (LAN)
             │
Machine B (워크스테이션, GPU 없음)
┌────────────┴─────────────┐
│ VS Code Extension         │ → Machine A API 호출 (코딩)
│ Discord Bot               │ → Machine A API 호출 (비서)
│ MCP/도구 서버:             │
│  · 캘린더 (Google API)    │
│  · 이메일 (Gmail API)     │
│  · 웹 검색 (SearXNG)     │
│  · 쉘/파일 (subprocess)  │
│  · 서버 관리 (Machine A)  │
└──────────────────────────┘
```

### 에이전트 루프 구조

```python
MACHINE_A = "http://192.168.x.x:8000/v1/chat/completions"

while not done:
    response = call_llm(MACHINE_A, messages, tools=local_tools)
    if response.has_tool_calls:
        results = execute_tools_locally(response.tool_calls)
        messages.append(results)
    else:
        show_to_user(response.content)
        done = True
```

- LLM은 Machine A에서 "생각"
- 도구는 Machine B에서 "실행"
- 이 분리가 깔끔하고 확장 용이

---

## 5. 기술 스택

| 컴포넌트 | 기술 | 위치 |
|---------|------|:----:|
| LLM 서버 | llama-server (OpenAI API) | Machine A |
| VS Code Extension | TypeScript + VS Code API | Machine B |
| Discord Bot | discord.py | Machine B |
| 도구 프레임워크 | 직접 구현 (function calling 기반) | Machine B |
| 웹 검색 | SearXNG (Docker) | Machine B |
| 코드/쉘 실행 | subprocess (직접) | Machine B |
| 에이전트 루프 | 직접 구현 (LangChain 등 불필요) | Machine B |

---

## 6. 구현 로드맵

### Phase 1: 인프라 (1-2일)
- Machine A: 2x 3060 설치, llama-server 자동 시작
- LAN API 통신 확인
- 핫스왑 스크립트 (모델 전환 자동화)

### Phase 2: VS Code Extension (3-5일)
- Extension 기본 구조
- Machine A API 연동 (에이전트 루프)
- 로컬 도구: 파일 R/W, 터미널, 프로젝트 탐색

### Phase 3: Discord Bot (2-3일)  
- 기본 봇 구조
- Machine A API 연동
- 슬래시 명령어

### Phase 4: 도구 통합 (3-5일)
- SearXNG 자체 호스팅
- Google Calendar/Gmail API
- 서버 관리 도구

---

## 7. 미결 사항

1. VS Code Extension 먼저 vs Discord Bot 먼저?
2. Machine A 기본 모델: Gemma4 26B vs Qwen 35B?
3. SearXNG 위치: Machine A vs Machine B?
4. Machine A 자동 시작: Windows 서비스 vs 작업 스케줄러?
5. 핫스왑 트리거 방식: 수동(명령어) vs 자동(복잡도 판단)?