할 일 목록에는 '정체됨'이라고 적혀 있지 않았다. 하지만 내 AI가 그것을 찾아냈다.
요약
Founders OS는 오픈 소스 MCP 서버로, 단순한 할 일 목록을 넘어 CRM, 재무(Ledger), 작업 관리(Tasks) 세 가지 시스템의 정보를 결합하여 '정체된' 업무를 찾아냅니다. 이는 개별 도구보다 강력하며, 사용자의 자체 Postgres DB에 배포되어 데이터 통제권을 보장합니다.
핵심 포인트
- 단순한 할 일 목록을 넘어 CRM, 재무, 작업 상태를 통합 분석합니다.
- 세 가지 이질적인 시스템의 정보를 결합하는 '조인(Join)' 문제 해결에 초점을 맞춥니다.
- MCP 서버 구조로 설계되어 어떤 AI 클라이언트와도 연결 가능하며 데이터 종속성이 낮습니다.
- 사용자 자체 Postgres DB를 대상으로 하여 데이터 통제권을 완벽하게 유지합니다.
저는 작은 컨설팅 회사를 운영합니다. 실패 모드는 결코 극적이지 않습니다. 그저 3주 전에 조용히 움직임을 멈춘 것인데, 할 일 목록에서는 여전히 괜찮아 보였기 때문에 아무도 알아차리지 못했습니다.
할 일 목록은 이런 부분에 취약합니다. '진행 중' 상태의 작업은 어제 옮겨졌든 지난 6월에 옮겨졌든 똑같이 보입니다. 실제로 죽었다는 신호는 다른 곳에 있습니다. 즉, 해당 고객에게 2주 동안 연락이 없었거나, 연결된 인보이스가 아직 미결제 상태이고, 마지막 메모는 아무도 답하지 않은 질문이었던 경우 같은 것입니다.
이것은 세 가지의 서로 다른 시스템입니다. 그래서 저는 이 세 가지를 한 번에 읽어내는 것을 만들었습니다.
실제로 쿼리가 하는 일은 무엇인가요?
Founders OS는 오픈 소스 MCP 서버입니다. 제가 AI 클라이언트에게 '무엇이 정체되었나요?'라고 물으면, 단순히 할 일 목록에서 상태 플래그를 검색하지 않습니다. 대신 세 가지 영역에서 정보를 가져와 결합합니다:
- Tasks: 개방된 상태이며 임계일 이후 활동이 없는 작업
- CRM: 연결된 고객에게 마지막으로 연락한 시점과 그 상호작용의 내용
- Ledger: 해당 작업과 관련된 돈이 미결제인지 여부
답변은 목록이 아니라 그림(picture) 형태로 돌아옵니다. 예를 들어, '이 작업은 11일 동안 움직이지 않았고, 이 고객은 범위에 대해 질문한 후 연락을 끊었으며, 지난달 인보이스가 아직 미결제 상태입니다.'와 같은 것입니다.
이 세 가지 사실 중 어느 하나만으로는 놀랍지 않습니다. 하지만 함께라면, 그 관계는 업무 진행이 멈추고 오늘 이메일을 보내야 한다는 것을 의미합니다.
이것이 프로젝트의 전체적인 논지입니다. CRM, 재무, 기억을 가로질러 추론하는 단 하나의 질문이 각 부분만 완벽하게 답변하는 세 가지 도구보다 더 강력하다는 것입니다.
왜 이것이 앱이 아닌 MCP 서버인가요?
저는 또 다른 대시보드를 원하지 않았습니다. 이미 충분한 대시보드가 있습니다. 저는 맥락(context)이 제가 생각하는 곳, 즉 저에게는 Claude이고 다른 사람들에게는 Cursor나 완전히 다른 무언가 안에 존재하기를 바랐습니다.
MCP는 이것을 이식 가능하게 만듭니다. 같은 서버에 어떤 클라이언트든 연결할 수 있습니다. 저는 주중에 도구 사이를 이동하고 비즈니스 맥락은 탭에 고립되는 대신 저를 따라다닙니다.
데이터가 위치하는 곳
이것은 사용자의 자체 Postgres를 대상으로 stdio 위에서 실행됩니다. 배포하면 데이터베이스는 사용자 소유가 되며, 사용자 자신의 인스턴스를 가리키게 됩니다.
이는 의도된 바였습니다. 저는 AI 어시스턴트를 조금 더 편리하게 만든다고 해서 제 클라이언트 목록, 연락 기록, 그리고 책들을 제가 통제하지 않는 호스팅 서비스에 넣을 생각이 없었습니다. 만약 다른 누군가가 자신의 인프라를 대상으로 실행하기를 원한다면, 그들에게 설정은 저에게 하는 것과 동일합니다. 설계상 락인(lock-in)이 없습니다. 왜냐하면 이 설계는 중간 관리자(middleman)를 가정하지 않았기 때문입니다.
이는 MIT 라이선스이며, 제가 매일 사업을 운영하는 데 실제로 사용하는 것입니다.
GitHub: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os
제가 계속 곱씹는 질문은 이것입니다.
지금 AI 툴링을 구축하는 모든 사람들은 검색(retrieval) 문제를 해결하고 있습니다. 하지만 적은 수의 사람들만이 조인(join) 문제를 해결하고 있습니다. 올바른 문서를 컨텍스트에 넣는 것은, 서로 다른 시스템에 있는 세 개의 레코드 간의 올바른 관계를 컨텍스트에 넣는 것보다 쉽습니다.
만약 이 분야에서 무언가를 구축하고 있다면, 어떻게 처리하는지 듣고 싶습니다. 조인(joins)이 진짜 작업이 이루어지는 곳입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기