210 lines
8.2 KiB
Markdown
210 lines
8.2 KiB
Markdown
# v7 아키텍처 엄밀 비판
|
|
|
|
---
|
|
|
|
## 보안 비판
|
|
|
|
### 🔴 1. 정보 예산이 추적하는 것이 잘못됨
|
|
|
|
현재 `InformationBudget`은 **노출된 함수명 수, 모듈명 수**를 센다.
|
|
하지만 진짜 정보 유출은 **이름이 아니라 로직**에서 발생:
|
|
|
|
```
|
|
"TABLE_A에서 DATE와 TENOR로 인덱싱된 금리 커브를 조회하고,
|
|
보간법으로 중간 만기를 추정한 뒤, HW 모델 파라미터로 변환"
|
|
```
|
|
|
|
→ 함수명 0개, 테이블 원명 0개 노출. **정보 예산 카운터: 0**.
|
|
→ 하지만 이 문장만으로 **DB 스키마 + 비즈니스 로직의 핵심이 노출됨**.
|
|
|
|
**문제: 이름을 세는 건 무의미. 로직의 깊이/구체성을 측정해야 함.**
|
|
|
|
> 대응: 정보 예산을 "추상화 레벨"로 전환 — 허용 수준 정의
|
|
> - Level 1: "이 모듈은 평가를 담당한다" (허용)
|
|
> - Level 2: "금리 커브 조회 → 보간 → 모델 계산" (주의)
|
|
> - Level 3: "DATE+TENOR 인덱싱, 선형보간, mean-reversion 파라미터" (위험)
|
|
> - Level 4: 소스 원문 (절대 금지)
|
|
>
|
|
> 각 라운드의 응답을 별도 LLM이나 규칙으로 레벨 분류
|
|
|
|
---
|
|
|
|
### 🔴 2. 정규식 필터는 시맨틱 유출을 못 막음
|
|
|
|
정규식이 잡는 것: `swap_curve`, `192.168.x.x`, `user@company.com`
|
|
정규식이 못 잡는 것:
|
|
|
|
```
|
|
"수익률 곡선 데이터를 날짜와 기간으로 인덱싱해서 가져온다"
|
|
```
|
|
|
|
→ 키워드 없음 → 필터 통과 → **하지만 DB 스키마 의미가 그대로 전달됨**
|
|
|
|
**정규식은 구문(syntax) 필터이지 의미(semantic) 필터가 아님.**
|
|
|
|
> 대응: 정규식은 1차 방어선(키워드 차단)으로만 사용.
|
|
> 2차 의미 필터는 로컬 LLM 프롬프트의 추상화 레벨 규칙에 의존할 수밖에 없음.
|
|
> **결국 보안의 최종 책임은 로컬 LLM의 판단력에 있음** → 이 한계를 수용해야 함.
|
|
|
|
---
|
|
|
|
### 🟡 3. 추상화-검증 순환 오류
|
|
|
|
로컬 LLM이 **추상화도 하고 검증도 함**:
|
|
|
|
```
|
|
[오류 시나리오]
|
|
LLM이 소스를 잘못 이해: "함수 A가 B를 호출한다" (실제: A→C→B)
|
|
↓
|
|
Analyst(Gemini): "A→B 호출에서 B 진입 시 검증 누락"
|
|
↓
|
|
Critic(LLM): 소스 재확인 → 같은 오해 반복 → "맞아, A→B야. LGTM"
|
|
```
|
|
|
|
**자기가 만든 추상화를 자기가 검증하면, 같은 실수를 반복할 수 있음.**
|
|
|
|
> 대응:
|
|
> - 검증 시 **다른 관점으로 소스 재독**: "A가 호출하는 함수 목록을 나열해"처럼 구체적 질문
|
|
> - Worker가 **반문**할 수 있게 허용: "정말 A→B인가? A→C→B는 아닌가?" → LLM이 재확인
|
|
> - 완전 해결은 불가 — 로컬 LLM 능력의 한계
|
|
|
|
---
|
|
|
|
## 구조 비판
|
|
|
|
### 🔴 4. Mode A와 B의 품질 격차가 클 것
|
|
|
|
| | Mode A | Mode B |
|
|
|---|--------|--------|
|
|
| Analyst | Gemini (강) | Gemini (강) |
|
|
| Critic | **Qwen 3.5 (약)** | **Gemini (강)** |
|
|
| 소스 접근 | 추상화 경유 (정보 손실) | 직접 (무손실) |
|
|
|
|
**Mode A의 품질은 가장 약한 고리(로컬 LLM)에 의해 결정됨.**
|
|
Critic이 약하면:
|
|
- 잘못된 반론 → Analyst 혼란
|
|
- 부실한 검증 → 오류 통과
|
|
- 과도하거나 부족한 추상화 → Analyst 분석 품질 저하
|
|
|
|
**솔직히: Mode A의 분석 품질은 Mode B의 50~70% 수준일 가능성이 높음.**
|
|
|
|
> 수용: 이것은 보안 비용. 보안을 지키면서 100% 품질은 원리적으로 불가능.
|
|
> 완화: 분석 유형별로 모드 선택 — 민감하지 않은 분석은 Mode B로.
|
|
|
|
---
|
|
|
|
### 🟡 5. 대화의 주도권이 불명확
|
|
|
|
**누가 다음 질문을 결정하는가?**
|
|
|
|
- **Analyst(Gemini)가 주도**: "다음으로 caller를 확인해줘" → 정보 흐름을 Gemini가 통제 → **보안 위험** (원하는 방향으로 유도 가능)
|
|
- **Critic(LLM)이 주도**: "다음은 이 부분을 분석해" → Gemini의 분석력이 과소 활용 → **품질 저하**
|
|
|
|
현재 설계는 이 주도권이 정의되지 않음.
|
|
|
|
> 대응: **턴제 혼합**
|
|
> - 홀수 턴: Critic이 주제 설정 ("이 함수를 분석해줘")
|
|
> - 짝수 턴: Analyst가 후속 질문 ("다음 확인 사항은?")
|
|
> - Critic은 Analyst의 질문에 **거부권** 보유: "그 정보는 제공 불가"
|
|
> → Critic이 게이트, Analyst가 추진력
|
|
|
|
---
|
|
|
|
### 🟡 6. Analyst↔Critic 교착(Deadlock) 처리 없음
|
|
|
|
```
|
|
Analyst: "이건 버그다"
|
|
Critic: "아니다, 정상이다"
|
|
Analyst: "아니, 0 나누기 발생한다"
|
|
Critic: "호출 경로상 0은 들어오지 않는다"
|
|
... 10라운드 → 결론 없음
|
|
```
|
|
|
|
`max_rounds` 도달 시 어떻게 되는가? 현재 설계에 정의 없음.
|
|
|
|
> 대응:
|
|
> - **교착 감지**: 3라운드 연속 결론 변화 없으면 교착 선언
|
|
> - **사용자 중재**: 교착 시 양쪽 주장을 사용자에게 제시 → 방향 결정
|
|
> - **합의 불가 마킹**: "이 분석은 확정되지 않음" 태그 부착
|
|
|
|
---
|
|
|
|
### 🟢 7. "파이프라인 공유" 주장이 실제보다 과장됨
|
|
|
|
| 컴포넌트 | 정말 공유? |
|
|
|---------|-----------|
|
|
| 대화 루프 프로토콜 | △ — Mode A는 LLM↔CLI, Mode B는 CLI↔CLI. 인터페이스만 같고 구현 다름 |
|
|
| MCP 서버 | ❌ — Mode B 전용. Mode A는 MCP 안 씀 |
|
|
| Worker Runner | ✅ — `gemini -p` 호출은 동일 |
|
|
| Rate Limiter | ✅ |
|
|
| Session Manager | ✅ (세션 격리 전제) |
|
|
|
|
**실제 코드 공유율은 100%가 아니라 ~60%에 가까움.**
|
|
|
|
> 수용: 과장을 제거하고 현실적으로 서술. 공유되는 것과 안 되는 것 구분.
|
|
|
|
---
|
|
|
|
## 실용성 비판
|
|
|
|
### 🟡 8. Mode A에서 Gemini 투입 가치가 있는가?
|
|
|
|
Mode A에서 Analyst(Gemini)는 **추상화된 정보만** 받음.
|
|
추상화 과정에서 정보 손실이 필연적 → Gemini의 분석 품질 제한.
|
|
|
|
**그렇다면:** 로컬 LLM이 직접 분석하는 것 대비 Gemini 투입의 실익은?
|
|
|
|
| 접근법 | 장점 | 단점 |
|
|
|--------|------|------|
|
|
| 로컬 LLM 단독 분석 | 소스 전체 접근, 보안 완벽 | 분석 품질 낮음 |
|
|
| 로컬 LLM + Gemini 협력 (현재) | Gemini 추론력 활용 | 추상화 비용, 복잡성, RPD 소비 |
|
|
|
|
> **Gemini 투입이 정당화되는 경우:**
|
|
> - 수백 줄 이상의 복잡한 로직 추론 (LLM 단독 한계)
|
|
> - 알려진 패턴/안티패턴 매칭 (Gemini 학습 데이터 활용)
|
|
> - 코드 리뷰 관점 (보안 취약점, 성능 이슈)
|
|
>
|
|
> **정당화 안 되는 경우:**
|
|
> - 단순 함수 설명, 호출 추적 → LLM 단독으로 충분
|
|
> → **Complexity Router가 이 판단을 해야 함**:
|
|
> Simple/Medium → 로컬 LLM 단독, Complex → Gemini 투입
|
|
|
|
---
|
|
|
|
### 🟢 9. Mode B에서 Critic의 독립성
|
|
|
|
Mode B의 Critic은 **별도 Gemini CLI 인스턴스**.
|
|
하지만 **같은 모델(Gemini)**이 Analyst와 Critic.
|
|
→ 같은 모델이 같은 소스를 보고 → 같은 편향 공유 가능.
|
|
|
|
> 이것은 v4 비판의 "자기 선호 편향"과 유사하나,
|
|
> **별도 프롬프트 + 별도 컨텍스트**이므로 단일 자기 평가보다는 낫다.
|
|
> 완전 독립 검증은 아니지만 현실적 타협점.
|
|
|
|
---
|
|
|
|
## 종합
|
|
|
|
| # | 이슈 | 심각도 | 해결 가능? |
|
|
|---|------|--------|-----------|
|
|
| 1 | 정보 예산이 로직 깊이를 못 셈 | 🔴 | △ 추상화 레벨 분류로 전환 |
|
|
| 2 | 정규식은 의미 유출 못 막음 | 🔴 | ✗ LLM 판단에 의존할 수밖에 없음 |
|
|
| 3 | 추상화-검증 순환 오류 | 🟡 | △ Analyst 반문 + 다른 관점 재독 |
|
|
| 4 | Mode A/B 품질 격차 | 🔴 | ✗ 보안 비용으로 수용 |
|
|
| 5 | 대화 주도권 미정의 | 🟡 | ◎ 턴제 + 거부권으로 해결 |
|
|
| 6 | 교착 처리 없음 | 🟡 | ◎ 교착 감지 + 사용자 중재 |
|
|
| 7 | 파이프라인 공유 과장 | 🟢 | ◎ 현실적 서술로 수정 |
|
|
| 8 | Mode A Gemini 투입 가치 | 🟡 | ◎ Complexity Router에서 분류 |
|
|
| 9 | Mode B Critic 독립성 한계 | 🟢 | △ 별도 프롬프트로 완화 |
|
|
|
|
> [!WARNING]
|
|
> **이번 비판의 핵심 메시지:**
|
|
>
|
|
> 이전 비판의 🔴 이슈였던 "자기 평가 불신뢰"와 "과잉 동원"은 v7에서 **해결됨**.
|
|
> 하지만 새로운 🔴가 등장:
|
|
> - **보안의 최종 방어선이 LLM의 판단력**이라는 구조적 한계
|
|
> - **Mode A 품질이 Mode B보다 본질적으로 낮다**는 트레이드오프
|
|
>
|
|
> 이 두 가지는 **구조로 해결할 수 없는 원리적 한계**이며,
|
|
> "어디까지 수용할 것인가"의 정책 결정이 필요합니다.
|