Production LLM 도구의 신뢰성 문제를 해결하는 아키텍처 패턴
LLMMixer라는 CLI-to-LLM 브릿지 도구의 production readiness를 확보하는 작업을 했다. 이 글에서는 interactive CLI 처리, adapter pattern 설계, SSE deduplication 등 복잡한 멀티모델 도구에서 마주치는 신뢰성 문제를 AI와 함께 해결한 과정을 다룬다. 배경: 무엇을 만들고 있는가 LL...

Source: DEV Community
LLMMixer라는 CLI-to-LLM 브릿지 도구의 production readiness를 확보하는 작업을 했다. 이 글에서는 interactive CLI 처리, adapter pattern 설계, SSE deduplication 등 복잡한 멀티모델 도구에서 마주치는 신뢰성 문제를 AI와 함께 해결한 과정을 다룬다. 배경: 무엇을 만들고 있는가 LLMMixer는 Claude, GPT, Gemini 등 여러 LLM을 하나의 인터페이스로 섞어 쓸 수 있는 도구다. 사용자가 터미널 명령어를 입력하면 LLM이 실행하고, 결과를 웹 대시보드에서 실시간으로 볼 수 있다. v0.3에서는 node-pty를 도입해 interactive CLI 지원을 추가했다. npm install -g some-cli처럼 사용자 입력이 필요한 명령어도 처리할 수 있게 됐다. 하지만 production에서 쓰려면 신뢰성 문제부터 해결해야 했다. 주요 목표: Interactive CLI 명령어 안정적 처리 멀티 어댑터 간 consistency 확보 SSE 중복 이벤트 제거 Singleton 인스턴스 persistence 보장 Interactive CLI 처리 — lazy loading과 제약 조건이 핵심 node-pty는 pseudo-terminal을 만들어서 실제 shell처럼 동작한다. 문제는 이 패키지가 네이티브 모듈이라 import 시점에 실패할 수 있다는 점이다. 프롬프팅 전략 AI에게 이런 문제를 해결하게 할 때는 제약 조건을 명확히 줘야 한다: node-pty를 lazy loading으로 처리해서 import 실패 시에도 애플리케이션이 죽지 않게 만들어줘. 조건: interactive 모드가 아닐 때는 node-pty를 로드하지 않는다 import 실패 시 graceful fallback으로 일반 child_process.spawn 사용 기존 non-interactive 명령어는 영향받지 않는다 TypeScript 타입 안전성 유지 이렇게 쓰면 안 된다: "node-pty 문제 해