cmdboard 개발 v3 — LibreChat 적용 검토 (스택 차이·최소 도입 경로)
작성: 채티 / 2026-05-26 / 목적: cmdboard 백엔드를 LibreChat에 "적용"하는 것이 가능한지, OS·언어 차이를 중심으로 검토하고 최소 개발로 Claude 기능을 도입하는 경로를 확정한다. 개인 사용 단일 사용자 전제.
1. 한 줄 결론
cmdboard 백엔드(Flask/Python/MySQL)는 LibreChat(Node.js/MongoDB) 안으로 코드 병합이 불가능하다. "백엔드 적용"이 아니라 두 시스템을 네트워크(MCP)로 연결하는 것이 유일하게 합리적인 경로다. 최소 개발 경로는 cmdboard API를 MCP 서버로 노출 + LibreChat이 MCP로 연결 + LibreChat은 Anthropic을 API key로 사용이다.
2. 스택 차이 비교
| 구분 | cmdboard | LibreChat | 통합 가능성 |
|---|---|---|---|
| 언어 | Python (Flask) | Node.js (JavaScript) | ❌ 코드 병합 불가. 별도 프로세스 + HTTP 통신만 가능 |
| DB | MySQL (RDS) | MongoDB (+ 선택 PGVector·Meilisearch) | ❌ 별개 유지. 통합 불가 |
| 실행 환경 | EC2 Ubuntu(:8002), Bridge=Windows PC | Docker 컨테이너(Linux 기반) | ⚠️ Docker가 OS 차이 흡수. 같은 EC2 또는 Windows PC에 배치 가능 |
| Claude 연결 | Bridge(claude-agent-sdk + OAuth, 단일 사용자) | Anthropic API key 네이티브 | ⚠️ 인증 방식 상이 — 트레이드오프 발생(§4) |
| 에이전트 | MCP 도구 5종 + Sara 페르소나 | 자체 Agents(LangGraph) + Subagents | ⚠️ 두 에이전트 시스템 별개 → 중복 위험 |
| ## 3. 핵심 분석 — OS·언어 차이 | |||
| ### 3-1. OS 차이는 장벽이 아니다 | |||
| LibreChat은 Docker로 배포된다(Linux 컨테이너). cmdboard EC2(Ubuntu)에 같이 올리거나 Windows PC에 올릴 수 있어, OS 차이는 Docker가 흡수한다. OS는 문제의 핵심이 아니다. | |||
| ### 3-2. 언어 차이가 진짜 장벽이다 | |||
| cmdboard는 Python(Flask), LibreChat은 Node.js다. Flask 코드를 LibreChat 프로세스 안에 "넣을" 수 없다. 두 시스템은 반드시 별도 프로세스로 남고 HTTP/네트워크로만 통신한다. 따라서 "백엔드 적용"이라는 표현 자체가 성립하지 않으며, 실제 작업은 연결(integration)이다. | |||
| ### 3-3. 연결의 표준 수단 = MCP | |||
| cmdboard는 이미 MCP 도구 5종(get_projects, get_tasks, create_task, update_task, add_task_log)을 보유한다. 현재는 Bridge 내부(in-process)에 있다. 이를 독립 MCP 서버로 노출하면 LibreChat이 MCP 엔드포인트로 연결해 그대로 사용할 수 있다. LibreChat은 MCP·custom endpoint를 네이티브 지원하므로 LibreChat 측 수정은 최소다. | |||
| ## 4. 인증 트레이드오프 (정직한 한계) | |||
| 최소 개발과 OAuth(구독)는 양립하기 어렵다. | |||
| - 최소 개발 = LibreChat 네이티브 = API key(종량제). 구독 OAuth 크레딧을 못 쓴다. | |||
| - 구독 OAuth를 LibreChat에 쓰려면 Anthropic 연결 레이어를 claude-agent-sdk 기반으로 대폭 개조해야 한다 → 최소 개발이 아니며, 제3자 하네스로 구독 토큰을 라우팅하는 ToS 회색지대에 진입한다(2026-04부터 차단 이력 있음). | |||
| - 참고: 2026-06-15부터 구독 플랜에 Agent SDK 크레딧이 생겨 "Agent SDK 기반 개인용 앱"의 구독 사용 경로가 열린다. 단 이는 Agent SDK 백엔드일 때의 이야기이며, LibreChat 네이티브(API key) 경로와는 다르다. | |||
| 판단: 구독 비용 절감이 1순위면 → 기존 Bridge(Agent SDK + OAuth) 유지가 오히려 최소. LibreChat 도입은 API key를 전제로 할 때만 "최소 개발"이 성립한다. | |||
| ## 5. 선택지 | |||
| ### 옵션 A — LibreChat(API key) + cmdboard MCP 서버 [최소 개발 / 추천 조건부] | |||
| - cmdboard 기존 API를 MCP 서버로 래핑(Python, 신규 소량) | |||
| - LibreChat은 Anthropic API key로 네이티브 연결(수정 0) | |||
| - Sara 페르소나 → LibreChat Agent(시스템 프롬프트 + MCP 도구) | |||
| - Bridge 폐기 가능(LibreChat이 Claude 연결 담당) | |||
| - 비용: API key 종량제 (구독 OAuth 불가) | |||
- 개인 사용 잠금: ALLOW_REGISTRATION=false, 1인 전용 |
|||
| ### 옵션 B — 기존 Bridge(Agent SDK + OAuth) 유지, LibreChat 미도입 [현상 유지] | |||
| - 이미 동작 중인 구조(Bridge + MCP + Sara + 프론트 채팅) 유지 | |||
| - 구독 OAuth 활용(개인 단일 사용자, 6-15 이후 정식 크레딧 경로) | |||
| - LibreChat의 UI/메모리/멀티에이전트 이점은 포기 | |||
| ### 옵션 C — LibreChat 포크 후 Anthropic 레이어만 Agent SDK로 개조 [비추천] | |||
| - 가능하나 upstream 업데이트 충돌 + 유지보수 부담 큼 | |||
| - LibreChat 자체 Agents(LangGraph)와 Agent SDK 중복 | |||
| ## 6. 권장안 | |||
| - LibreChat UI/메모리/멀티에이전트가 꼭 필요하다 → 옵션 A (API key 전제, MCP로 cmdboard 연결, Bridge 폐기) | |||
| - 구독 비용 절감이 1순위다 → 옵션 B (기존 Bridge 유지) | |||
| - 옵션 C(백엔드 개조)는 "최소 개발" 목적과 배치되므로 권장하지 않음 | |||
| ## 7. 라이선스·ToS 체크 | |||
| - LibreChat: MIT 라이선스 — 사용·수정·자체 운영 자유. 공개 배포 안 하므로 제약 사실상 없음 | |||
| - 개인 단일 사용 + API key(옵션 A) 또는 개인 단일 사용 + Agent SDK OAaut(옵션 B) → ToS 경계선 안쪽 | |||
| - 주의: LibreChat은 멀티유저 시스템이므로 반드시 1인 전용으로 잠글 것(회원가입 차단) | |||
| ## 8. 미결 / 다음 결정 포인트 | |||
| - [ ] 옵션 A vs B 선택 (UI 이점 vs 구독 비용 절감) | |||
| - [ ] A 선택 시: cmdboard MCP 서버 노출 범위(읽기 5종 그대로 vs 확장) | |||
| - [ ] A 선택 시: LibreChat 배치 위치(EC2 동거 vs Windows PC) | |||
| - [ ] Sara 페르소나의 LibreChat Agent 이식 방식 | |||
| - [ ] (공통) 개인 사용 잠금 설정 확정 |