245 lines
9.0 KiB
Markdown
245 lines
9.0 KiB
Markdown
---
|
||
date: 2025-09-29
|
||
author: happybell80
|
||
tags: [ai, cli, integration, automation]
|
||
status: idea
|
||
---
|
||
|
||
# Multi-AI CLI 통합 시스템 구상
|
||
|
||
## 현황
|
||
- **사용 중인 AI CLI**: Claude (23/24 서버), Gemini CLI, OpenAI Codex CLI (로컬)
|
||
- **인증 방식**: 브라우저 세션 기반 (쿠키/토큰 사용, API 미사용)
|
||
- **현재 워크플로우**: 수동으로 각 CLI에 질문하고 답변 종합
|
||
|
||
### CLI 설치 현황
|
||
- **로컬**: Claude, Gemini 설치 (OpenAI 없음)
|
||
- **51123 서버**: Claude만 설치
|
||
- **51124 서버**: Claude, Gemini, OpenAI 모두 설치, 세션 파일 접근 가능
|
||
|
||
## 목표
|
||
여러 AI의 의견을 동시에 얻어 더 나은 의사결정을 내리고 개발 생산성 향상
|
||
|
||
## 구현 방안 우선순위
|
||
|
||
### 1. tmux + bash
|
||
```bash
|
||
#!/bin/bash
|
||
# multi-ai.sh
|
||
tmux new-session -d -s ai-panel
|
||
tmux split-window -h -t ai-panel
|
||
tmux split-window -v -t ai-panel
|
||
tmux send-keys -t ai-panel:0.0 "claude" Enter
|
||
tmux send-keys -t ai-panel:0.1 "gemini" Enter
|
||
tmux send-keys -t ai-panel:0.2 "openai" Enter
|
||
tmux attach -t ai-panel
|
||
```
|
||
- 장점: 구현 간단, 즉시 사용 가능
|
||
- 단점: 수동 입력 필요, 응답 통합 어려움
|
||
|
||
### 2. Python 래퍼
|
||
- subprocess.Popen으로 각 CLI 프로세스 제어
|
||
- asyncio.gather로 동시 질의 및 응답 수집
|
||
- 세션 파일 경로: ~/.config/claude, ~/.config/gemini
|
||
- stdin/stdout 스트림 비동기 처리
|
||
|
||
### 3. FastAPI 웹 대시보드
|
||
- WebSocket으로 실시간 스트리밍 응답 처리
|
||
- 3열 레이아웃으로 동시 응답 표시
|
||
- 대화 이력 SQLite/LMDB 저장
|
||
|
||
**주요 기능**:
|
||
- 단일 입력창으로 모든 AI에 동시 질의
|
||
- 실시간 응답 스트리밍 (3열 레이아웃)
|
||
- 대화 이력 저장/검색
|
||
- 응답 비교 및 최선 선택
|
||
- 세션 관리 (쿠키/토큰 경로 공유)
|
||
|
||
### 4. 기대 효과
|
||
|
||
#### 시나리오 1: 코드 리뷰
|
||
- **입력**: "이 함수의 문제점과 개선 방안"
|
||
- **Claude**: 버그 및 엣지케이스 분석
|
||
- **Gemini**: 성능 최적화 제안
|
||
- **OpenAI**: 리팩토링 패턴 추천
|
||
- **결과**: 다각도 검토로 코드 품질 향상
|
||
|
||
#### 시나리오 2: 장애 대응
|
||
- **입력**: "서버 응답 지연 원인 분석"
|
||
- **Claude**: 로그 패턴 분석
|
||
- **Gemini**: 시스템 리소스 진단
|
||
- **OpenAI**: 즉시 적용 가능한 해결책
|
||
- **결과**: 신속한 문제 해결
|
||
|
||
#### 시나리오 3: 아키텍처 설계
|
||
- **입력**: "마이크로서비스 분리 전략"
|
||
- **Claude**: 도메인 경계 분석
|
||
- **Gemini**: 기술 스택 제안
|
||
- **OpenAI**: 마이그레이션 로드맵
|
||
- **결과**: 균형잡힌 설계 결정
|
||
|
||
## 구현 로드맵
|
||
|
||
### 개발 단계
|
||
1. **Phase 0**: 단일 CLI PoC - Claude만으로 PTY/파싱 검증
|
||
2. **Phase 1**: tmux 스크립트 작성 및 테스트
|
||
3. **Phase 2**: Python pexpect 래퍼 개발 및 확장
|
||
4. **Phase 3**: FastAPI 백엔드 구축
|
||
5. **Phase 4**: 웹 UI 및 실시간 통신
|
||
6. **Phase 5**: 세션 공유, 응답 분석 기능
|
||
|
||
### 산출물
|
||
- **PoC 스크립트**: 단일 CLI 제어 검증 코드
|
||
- **재현 스크립트**: 각종 에러 상황 시뮬레이션
|
||
- **골든 로그**: raw/clean 출력 샘플
|
||
- **파서 규칙 문서**: ANSI 제거, 프롬프트 패턴
|
||
- **계약 테스트**: 어댑터 인터페이스 검증
|
||
|
||
## 배포 방식
|
||
**UV 가상환경 사용** (Docker 대신)
|
||
- 세션 파일(~/.config/claude, ~/.config/gemini) 직접 접근
|
||
- 브라우저 인증 자연스럽게 연동
|
||
- tmux는 pipx로 설치
|
||
- FastAPI는 uv로 관리
|
||
|
||
## PoC 개발 계획
|
||
|
||
### Phase 0: 단일 CLI 프로토타입
|
||
- **대상**: Claude CLI만으로 시작
|
||
- **기술**: pexpect (pty 대신) - PTY 제어, 타임아웃, 패턴 매칭에 강점
|
||
- **검증 시나리오**:
|
||
- 정상 스트리밍 응답
|
||
- 세션 만료 처리
|
||
- Rate limit 대응
|
||
- 느리거나 중단된 스트림
|
||
- 프롬프트 미복귀 상황
|
||
|
||
### 메시지 스키마 (JSONL)
|
||
```
|
||
{"type": "request", "model": "claude", "prompt": "...", "timestamp": "..."}
|
||
{"type": "chunk", "model": "claude", "content": "...", "timestamp": "..."}
|
||
{"type": "final", "model": "claude", "content": "...", "latency": 1.23}
|
||
{"type": "error", "model": "claude", "error": "session_expired", "timestamp": "..."}
|
||
```
|
||
|
||
### CLI 어댑터 계약
|
||
- **인터페이스**: healthcheck() | ask()->async iterator | cancel() | resume()
|
||
- **모드**: PTY/STDIO 모드 지원
|
||
- **정규화**: ANSI 제거, 프롬프트 재출현, 타임아웃 규칙 내장
|
||
- **pexpect 패턴**:
|
||
- Claude: "❯" 프롬프트, timeout=30
|
||
- Gemini: ">" 프롬프트, timeout=25
|
||
- Codex: ">>>" 프롬프트, timeout=20
|
||
|
||
### 파싱 규칙
|
||
- **종료 판단**: 프롬프트 패턴 + 침묵 타임아웃 + 길이 상한
|
||
- **정규화**: 코드블록/표 정상화, fence 언어 보정
|
||
- **골든 로그**: raw/clean 출력 비교로 파서 규칙 확정
|
||
|
||
### 에러 복구 전략
|
||
- **분류**: Auth/Rate/Parse/Timeout
|
||
- **복구**: 지수 백오프, 재시도, 세션 만료시 수동 로그인 안내
|
||
|
||
## 기술적 고려사항
|
||
|
||
### 세션 관리
|
||
- **세션 파일 위치**: strace/fs_usage로 CLI가 읽는 파일 추적
|
||
- **인증 오류 감지**: "Session expired", "Please log in" 패턴 매칭
|
||
- **헬스 체크**: claude me, gemini whoami로 세션 상태 확인
|
||
- **세션 파일 권한**:
|
||
- ~/.config/claude: 600 (user read/write only)
|
||
- ~/.config/gemini: 600 (user read/write only)
|
||
- ~/.config/codex: 600 (user read/write only)
|
||
|
||
### 입출력 제어
|
||
- **pexpect 사용**: pty 모듈보다 안정적, 패턴 매칭 우수
|
||
- **비동기 처리**: asyncio.subprocess로 여러 CLI 동시 제어
|
||
- **입력 전송**: expect/send 메소드 활용
|
||
|
||
### 응답 파싱
|
||
- **ANSI 코드 제거**: 색상 코드, 스피너, ASCII 아트 정규식 제거
|
||
- **응답 종료 판단**:
|
||
- 프롬프트 재출현 감지
|
||
- 타임아웃 기반 종료
|
||
- **CLI별 커스텀 파서**: 각 CLI 출력 형식에 맞춘 개별 파서
|
||
|
||
### 유지보수 리스크
|
||
- CLI 업데이트시 파싱 로직 깨짐
|
||
- 지속적인 출력 형식 변경 추적 필요
|
||
- 각 CLI 버전별 호환성 테스트 필수
|
||
|
||
## 리스크
|
||
- CLI 업데이트로 인한 호환성 깨짐
|
||
- 세션 만료 처리
|
||
- 각 서비스의 rate limiting
|
||
- 자동화 관련 제약사항
|
||
|
||
## 최종 배포 전략
|
||
|
||
### 개발 및 배포 워크플로우
|
||
1. **로컬 개발**: 코드 작성 및 테스트
|
||
2. **Git Push**: 로컬 → Git 저장소
|
||
3. **서버 배포**: 51124에서 git pull 후 실행
|
||
|
||
### 구현 위치
|
||
- **51124 서버**: 모든 CLI 설치되어 있음, FastAPI 서버 실행
|
||
- **51123 서버**: nginx 프록시로 51124:8888 연결
|
||
|
||
### 51124 서버 설정
|
||
- UV 버전: 0.8.4 (이미 설치됨)
|
||
- 전용 디렉토리: /home/admin/multi-ai-cli/
|
||
- UV 가상환경 패키지: FastAPI, asyncio, pty
|
||
- CLI 제어: Python subprocess/PTY (tmux 대신)
|
||
- 리소스 격리: nice -n 19 적용
|
||
- 포트: 8888
|
||
|
||
### 51123 nginx 프록시
|
||
- location /multi-ai/ → proxy_pass http://51124:8888/
|
||
- WebSocket 지원 헤더 설정 필요
|
||
- root_path 프리픽스 설정: FastAPI(root_path="/multi-ai")
|
||
|
||
## 실현 가능성 평가
|
||
|
||
### 최종 평가
|
||
- **51124 서버 기준**: 80-85% (모든 CLI 설치됨, 세션 파일 접근 가능)
|
||
- **핵심 결론**: 51124에서 구축 + 51123 nginx 프록시로 웹 제공
|
||
|
||
### Phase별 평가
|
||
- **Phase 1** (tmux 스크립트): 즉시 가능
|
||
- **Phase 2** (Python 래퍼): PTY 제어, 응답 종료 판단 난제
|
||
- **Phase 3-4** (FastAPI+웹 UI): 구현 가능
|
||
- **Phase 5** (세션 공유·응답 분석): 복잡도 높음
|
||
|
||
## 100% 실현성 달성 방안
|
||
|
||
### 검증된 아키텍처 참조 (2024년 기준)
|
||
- **Microsoft Magentic-One**: Orchestrator + 4개 특화 에이전트 (WebSurfer, FileSurfer, Coder, Terminal)
|
||
- **AWS Multi-Agent Orchestrator**: Amazon Bedrock 기반 동적 에이전트 할당
|
||
- **AutoGen Framework**: Microsoft의 대화형 에이전트 간 메시지 전달 프로토콜
|
||
|
||
### 핵심 개선사항
|
||
1. **프로파일 기반 에이전트 정의**: 각 CLI를 명확한 역할과 능력으로 정의
|
||
2. **메모리 시스템**: SQLite로 대화 컨텍스트 유지, 에이전트 간 정보 공유
|
||
3. **동적 오케스트레이션**: 관리 에이전트가 태스크 분배 및 응답 집계
|
||
4. **계약 기반 테스트**: 각 CLI 어댑터의 입출력 명세 정의 및 자동 검증
|
||
|
||
### 논문 기반 검증 필요 항목
|
||
- Multi-agent collaboration mechanisms 연구
|
||
- LLM tool use reliability 패턴
|
||
- Stream processing backpressure 처리
|
||
- Contract testing for microservices 적용
|
||
|
||
## 반자동화 범위 정의
|
||
|
||
### 자동화 영역
|
||
- **입력 브로드캐스트**: 1회 입력 → 다중 모델·23/24 서버에 전송, 응답 수집·요약·충돌 정리
|
||
- **코드/문서 생성**: 파일별 unified diff, 커밋/PR 본문 템플릿, 체크리스트·재현 스크립트 자동 생성
|
||
- **모니터링**: 헬스체크·로그 수집은 읽기 전용으로 자동화, 실행할 서버 명령은 "미리보기"로 제시
|
||
- **세션 관리**: 쿠키 관리·만료 감지·재로그인 안내 자동, 만료 시만 수동 로그인 요구
|
||
|
||
### 승인 필요 지점
|
||
- 패치 적용
|
||
- 테스트 실행
|
||
- git push/PR 생성
|
||
- 23/24 서버 배포/롤백 트리거
|
||
- 운영 DB/컨테이너 조작 (항상 수동) |