8.2 KiB
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보다 본질적으로 낮다는 트레이드오프
이 두 가지는 구조로 해결할 수 없는 원리적 한계이며, "어디까지 수용할 것인가"의 정책 결정이 필요합니다.