- Phase 0 추가: 1-2일 단일 CLI(Claude) PoC 개발 - pexpect 사용 (pty 대신) - 안정성과 패턴 매칭 우수 - JSONL 메시지 스키마 정의 (request/chunk/final/error) - CLI 어댑터 계약 및 인터페이스 명시 - 파싱 규칙 및 에러 복구 전략 구체화 - 골든 로그 기반 테스트 체계 - 개발 일정 조정: PoC 1-2일 + 확장 3-5일
8.7 KiB
8.7 KiB
date, author, tags, status
| date | author | tags | status | ||||
|---|---|---|---|---|---|---|---|
| 2025-09-29 | happybell80 |
|
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)
#!/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 래퍼 (1주일)
- subprocess.Popen으로 각 CLI 프로세스 제어
- asyncio.gather로 동시 질의 및 응답 수집
- 세션 파일 경로: ~/.config/claude, ~/.config/gemini
- stdin/stdout 스트림 비동기 처리
3. FastAPI 웹 대시보드 (2-3주)
- WebSocket으로 실시간 스트리밍 응답 처리
- 3열 레이아웃으로 동시 응답 표시
- 대화 이력 SQLite/LMDB 저장
주요 기능:
- 단일 입력창으로 모든 AI에 동시 질의
- 실시간 응답 스트리밍 (3열 레이아웃)
- 대화 이력 저장/검색
- 응답 비교 및 최선 선택
- 세션 관리 (쿠키/토큰 경로 공유)
4. 기대 효과
시나리오 1: 코드 리뷰
- 입력: "이 함수의 문제점과 개선 방안"
- Claude: 버그 및 엣지케이스 분석
- Gemini: 성능 최적화 제안
- OpenAI: 리팩토링 패턴 추천
- 결과: 다각도 검토로 코드 품질 향상
시나리오 2: 장애 대응
- 입력: "서버 응답 지연 원인 분석"
- Claude: 로그 패턴 분석
- Gemini: 시스템 리소스 진단
- OpenAI: 즉시 적용 가능한 해결책
- 결과: 신속한 문제 해결
시나리오 3: 아키텍처 설계
- 입력: "마이크로서비스 분리 전략"
- Claude: 도메인 경계 분석
- Gemini: 기술 스택 제안
- OpenAI: 마이그레이션 로드맵
- 결과: 균형잡힌 설계 결정
구현 로드맵
개발 일정
- Phase 0 (1-2일): 단일 CLI PoC - Claude만으로 PTY/파싱 검증
- Phase 1 (즉시): tmux 스크립트 작성 및 테스트
- Phase 2 (3-5일): Python pexpect 래퍼 개발 및 확장
- Phase 3 (2주): FastAPI 백엔드 구축
- Phase 4 (3주): 웹 UI 및 실시간 통신
- Phase 5 (1개월): 세션 공유, 응답 분석 기능
산출물
- PoC 스크립트: 단일 CLI 제어 검증 코드
- 재현 스크립트: 각종 에러 상황 시뮬레이션
- 골든 로그: raw/clean 출력 샘플
- 파서 규칙 문서: ANSI 제거, 프롬프트 패턴
- 계약 테스트: 어댑터 인터페이스 검증
배포 방식
UV 가상환경 사용 (Docker 대신)
- 세션 파일(~/.config/claude, ~/.config/gemini) 직접 접근
- 브라우저 인증 자연스럽게 연동
- tmux는 pipx로 설치
- FastAPI는 uv로 관리
PoC 개발 계획
Phase 0: 단일 CLI 프로토타입 (1-2일)
- 대상: 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 제거, 프롬프트 재출현, 타임아웃 규칙 내장
파싱 규칙
- 종료 판단: 프롬프트 패턴 + 침묵 타임아웃(1-2초) + 길이 상한
- 정규화: 코드블록/표 정상화, fence 언어 보정
- 골든 로그: raw/clean 출력 비교로 파서 규칙 확정
에러 복구 전략
- 분류: Auth/Rate/Parse/Timeout
- 복구: 지수 백오프, 재시도, 세션 만료시 수동 로그인 안내
기술적 고려사항
세션 관리
- 세션 파일 위치: strace/fs_usage로 CLI가 읽는 파일 추적
- 인증 오류 감지: "Session expired", "Please log in" 패턴 매칭
- 헬스 체크: claude me, gemini whoami로 세션 상태 확인
입출력 제어
- pexpect 사용: pty 모듈보다 안정적, 패턴 매칭 우수
- 비동기 처리: asyncio.subprocess로 여러 CLI 동시 제어
- 입력 전송: expect/send 메소드 활용
응답 파싱
- ANSI 코드 제거: 색상 코드, 스피너, ASCII 아트 정규식 제거
- 응답 종료 판단:
- 프롬프트 재출현 감지
- 1-2초 타임아웃 기반 종료
- CLI별 커스텀 파서: 각 CLI 출력 형식에 맞춘 개별 파서
유지보수 리스크
- CLI 업데이트시 파싱 로직 깨짐
- 지속적인 출력 형식 변경 추적 필요
- 각 CLI 버전별 호환성 테스트 필수
리스크
- CLI 업데이트로 인한 호환성 깨짐
- 세션 만료 처리
- 각 서비스의 rate limiting
- 자동화 관련 제약사항
최종 배포 전략
개발 및 배포 워크플로우
- 로컬 개발: 코드 작성 및 테스트
- Git Push: 로컬 → Git 저장소
- 서버 배포: 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 지원 헤더 설정 필요
실현 가능성 평가
최종 평가
- 51124 서버 기준: 80-85% (모든 CLI 설치됨, 세션 파일 접근 가능)
- 핵심 결론: 51124에서 구축 + 51123 nginx 프록시로 웹 제공
Phase별 평가
- Phase 1 (tmux 스크립트): 100% 즉시 가능
- Phase 2 (Python 래퍼): 70% (PTY 제어, 응답 종료 판단)
- Phase 3-4 (FastAPI+웹 UI): 65%
- Phase 5 (세션 공유·응답 분석): 50%
100% 실현성 달성 방안
검증된 아키텍처 참조 (2024년 기준)
- Microsoft Magentic-One: Orchestrator + 4개 특화 에이전트 (WebSurfer, FileSurfer, Coder, Terminal)
- AWS Multi-Agent Orchestrator: Amazon Bedrock 기반 동적 에이전트 할당
- AutoGen Framework: Microsoft의 대화형 에이전트 간 메시지 전달 프로토콜
핵심 개선사항
- 프로파일 기반 에이전트 정의: 각 CLI를 명확한 역할과 능력으로 정의
- 메모리 시스템: SQLite로 대화 컨텍스트 유지, 에이전트 간 정보 공유
- 동적 오케스트레이션: 관리 에이전트가 태스크 분배 및 응답 집계
- 계약 기반 테스트: 각 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/컨테이너 조작 (항상 수동)