Statey는 여러 AI 대화와 에이전트가 함께 사용할 수 있는 구조화 데이터 저장소를 MCP(Model Context Protocol)로 제공하는 제품이다. 핵심은 AI에게 기억 기능을 조금 더 붙이는 것이 아니라, 티켓·고객·연구 자료·실행 기록처럼 계속 갱신되는 작업 상태를 별도의 데이터베이스에 남기는 데 있다. Claude에서 만든 기록을 Cursor, Codex, ChatGPT 같은 다른 MCP 클라이언트에서도 다시 조회하고 수정하는 사용 방식을 제안한다.

제품 자체에는 일반적인 업무 도구처럼 목록이나 보드를 클릭하는 전용 인터페이스가 없다. 사용자는 대화 중에 “이 버그를 기록해 줘”, “진행 중인 티켓을 담당자별로 보여 줘”라고 요청하고, 연결된 AI가 Statey의 MCP 도구를 호출한다. 보드나 표가 필요하면 AI 클라이언트가 현재 데이터를 바탕으로 그때그때 표현한다. 따라서 Statey를 검토할 때는 화면이 편리한지를 보기보다, 사용하는 AI가 데이터를 정확히 생성·조회·수정하는지부터 확인해야 한다.

채팅 기억과 데이터베이스의 차이

AI의 대화 기록이나 메모리는 배경 정보와 선호를 유지하는 데는 유용하지만, 지속적으로 변하는 업무 상태를 관리하기에는 한계가 있다. 예를 들어 “담당자별 미완료 티켓”, “지난달 실패한 에이전트 실행 비율”, “특정 고객과 연결된 의사결정”을 안정적으로 조회하려면 필드, 상태 값, 관계와 변경 이력이 필요하다. 한 대화에 남겨 둔 정보는 다른 AI 클라이언트가 자동으로 알지 못하며, 컨텍스트가 닫힌 뒤 다시 활용하기도 어렵다.

Statey는 작업을 채팅 문장이 아니라 레코드로 보관한다. 티켓에는 상태와 담당자를, 고객에는 요금제나 갱신일을, 연구 자료에는 출처와 발견 사항을 둘 수 있다. 필드 형식과 열거형 값을 검증한다는 설명도 제공한다. 같은 완료 상태가 여러 철자로 흩어지거나, 필요한 필드가 대화마다 달라지는 문제를 줄이려는 설계다.

다만 “구조가 자동으로 만들어진다”는 점이 데이터 설계가 필요 없다는 뜻은 아니다. AI가 처음 생성한 컬렉션과 필드가 실제 분류 기준에 맞는지 사람이 검토해야 한다. 상태 값의 의미, 필수 필드, 레코드 사이의 관계가 모호하면 검증 기능이 있어도 잘못 설계된 구조를 일관되게 유지할 수 있다.

Statey가 제시하는 작동 방식

  1. 저장: 사용자가 버그, 리드, 문서 또는 조사 결과를 기록해 달라고 요청하면 AI가 적절한 컬렉션에 검증된 레코드를 생성한다.
  2. 조회: 같은 대화뿐 아니라 다른 MCP 클라이언트에서도 조건에 맞는 현재 레코드를 조회한다. 결과 표현은 표, 보드, 요약 수치 등 AI가 만들 수 있다.
  3. 수정: 사람과 여러 에이전트가 같은 데이터를 갱신하며, 각 변경에는 작업 주체가 기록된다.
  4. 구조 변경: 필드 추가, 상태 이름 변경, 컬렉션 분리 같은 요구를 대화로 전달할 수 있다. 제품 설명상 스키마는 버전으로 관리되고 변경 이력은 유지된다.
  5. 반응형 자동화: 데이터 변경을 계기로 에이전트를 실행하는 트리거 기능은 향후 기능으로 소개된다. 현재 바로 사용할 수 있는 기능으로 간주해서는 안 된다.

호스팅형 서비스이므로 사용자가 별도의 데이터베이스 서버를 운영하지 않는다는 점도 특징이다. 제품 설명에 따르면 각 워크스페이스는 격리된 데이터베이스를 사용하고, 현재 저장 계층은 MongoDB이며, 쓰기 작업은 트랜잭션으로 처리되고 추가 전용 활동 스트림에 기록된다. 조회 결과는 일반 JSON으로 받을 수 있다고 안내한다. 실제 도입 전에는 이 설명이 어떤 플랜과 사용 환경에 적용되는지 공식 문서에서 다시 확인할 필요가 있다.

기존 대안과 비교할 때 볼 차이

대안 유리한 상황 Statey와 비교할 기준
AI 메모리와 채팅 기록 개인 선호나 간단한 사실을 이어서 사용할 때 조건 검색, 상태 관리, 관계형 기록, 변경 주체 추적이 필요한지 확인한다.
스프레드시트 사람이 직접 검토하고 수정하며 화면에서 빠르게 훑어야 할 때 필드 검증, 컬렉션 간 관계, 여러 에이전트의 동시 수정과 감사 기록이 더 중요한지 본다.
Jira·Linear·Notion·CRM 완성된 화면, 알림, 보고서와 조직 운영 기능이 필요할 때 기존 제품의 UI와 생태계를 포기해도 될 만큼 AI 중심 작업 비율이 높은지 비교한다.
직접 만든 SQLite·Postgres MCP 데이터 위치와 구현을 직접 통제해야 하거나 사내 환경에 맞춘 기능이 필요할 때 서버, 인증, 스키마 변경, 감사 로그를 관리하는 비용과 호스팅 서비스 의존성을 함께 계산한다.

기존 업무 도구는 사람이 클릭하는 화면과 승인 절차, 알림, 필터, 대시보드를 이미 제공한다. Statey는 이런 화면을 없애고 AI가 필요한 표현을 만드는 방향이다. 따라서 Jira나 Linear의 완전한 대체재라고 바로 결론 내리기보다는, 실제로 사람이 UI를 얼마나 사용하고 있는지 측정하는 것이 먼저다. AI가 대부분의 등록과 조회를 담당하더라도 관리자가 전체 상태를 직접 점검하거나 대량 수정해야 한다면 전용 UI의 부재가 오히려 비용이 될 수 있다.

잘 맞을 가능성이 있는 작업

  • 에이전트 작업 큐: 여러 에이전트가 작업을 가져가고 상태를 갱신하며 다음 담당자에게 넘기는 흐름
  • 버그와 티켓 관리: 상태, 담당자, 관련 고객과 변경 이력을 구조화해야 하는 경우
  • 에이전트 실행 및 평가 기록: 입력, 결과, 비용, 성공 여부를 레코드로 남겨 나중에 조건별로 집계하는 경우
  • 연구 자료 저장소: 출처, 발견 사항, 인용 정보와 판단을 연결해 여러 세션에서 재사용하는 경우
  • 간단한 CRM이나 콘텐츠 일정: AI가 등록과 갱신을 주로 수행하고 사용자가 대화로 현황을 확인하는 경우

반대로 사람이 매일 직접 보드를 이동하고, 세밀한 권한 승인이나 복잡한 보고서를 사용하며, 외부 고객까지 같은 화면에서 협업하는 환경이라면 적합성을 더 신중하게 봐야 한다. 전용 UI가 없다는 선택은 단순한 기능 누락이 아니라 제품의 중심 가정이다. AI 호출이 실패했을 때 사람이 데이터를 확인하고 복구할 방법도 테스트해야 한다.

가격보다 먼저 권한과 데이터 경계를 확인해야 한다

제공된 제품 설명만으로는 무료·유료·팀 플랜의 범위, 사용량 제한, 레코드 또는 워크스페이스 한도, 추가 비용을 판단할 수 없다. 비용 비교는 공식 가격표에서 저장 용량뿐 아니라 MCP 호출량, 사용자와 에이전트 수, 활동 이력 보존 기간, 지원 범위를 확인한 뒤 해야 한다. 좌석 기반 업무 도구보다 저렴할 것이라고 미리 가정해서는 안 된다.

업무나 연구 데이터를 넣는다면 인증과 권한 모델이 더 중요하다. 한 번 연결한 클라이언트가 워크스페이스 전체를 읽고 쓸 수 있는지, 컬렉션별 또는 작업별 권한을 제한할 수 있는지, 팀원과 에이전트의 자격 증명을 분리할 수 있는지 확인해야 한다. “누가 무엇을 바꿨는지 기록한다”는 기능과 “누가 무엇을 바꿀 수 있는지 제한한다”는 접근 제어는 서로 다른 문제다.

워크스페이스별 데이터베이스 격리도 실제 보안 요구를 자동으로 충족시키지는 않는다. 데이터가 저장되는 지역, 전송 및 저장 시 암호화, 백업과 삭제 절차, 로그 보존 기간, 하위 처리자, 장애 대응, 계정 해지 후 데이터 처리 방식을 공식 정책에서 확인해야 한다. 개인정보, 미공개 코드, 고객 정보, 연구 참여자 자료처럼 민감한 데이터는 이 조건을 확인하기 전까지 넣지 않는 편이 안전하다.

MCP 연결에서 확인할 호환성

제품 페이지는 Claude Desktop, Claude Code, Codex, ChatGPT, Cursor를 연결 대상으로 제시한다. 그러나 이름이 표시된다는 사실만으로 모든 계정과 환경에서 같은 기능을 쓸 수 있다고 단정할 수는 없다. 각 클라이언트의 MCP 지원 범위, 원격 서버 연결 방식, 조직 관리자의 외부 도구 허용 여부, 모바일과 데스크톱의 차이를 확인해야 한다.

  • 사용 중인 계정 유형에서 원격 MCP 서버를 등록할 수 있는가?
  • 로그인과 토큰 갱신 방식이 개인 및 팀 보안 정책에 맞는가?
  • 읽기 전용 연결과 쓰기 가능한 연결을 구분할 수 있는가?
  • AI가 어떤 도구 호출을 실행하려는지 사용자가 승인하거나 검토할 수 있는가?
  • 연결이 끊기거나 서비스가 중단됐을 때 기존 레코드를 조회할 대체 경로가 있는가?
  • 동일한 레코드를 여러 에이전트가 동시에 수정할 때 충돌을 어떻게 감지하고 해결하는가?

제품은 트랜잭션과 변경 기록을 강조하지만, 동시 수정에서 어떤 값이 최종 반영되는지, 낙관적 잠금이나 버전 충돌 처리가 제공되는지는 별도로 확인해야 한다. 중요한 상태가 조용히 덮어써지지 않는지 작은 충돌 테스트로 검증하는 것이 좋다.

작은 실험으로 판단하는 방법

처음부터 프로젝트 관리나 연구 저장소 전체를 옮기기보다, 민감하지 않은 샘플 컬렉션 하나로 시작하는 편이 현실적이다. 예를 들어 테스트용 버그 20여 건처럼 사람이 직접 대조할 수 있는 규모를 준비하고, 두 개 이상의 MCP 클라이언트에서 생성·조회·수정을 반복한다. 정확한 건수는 작업 특성에 맞게 정하되, 정상 입력뿐 아니라 누락 필드, 잘못된 상태 값, 중복 레코드와 동시 수정도 포함해야 한다.

  1. AI에게 컬렉션을 만들게 한 뒤 생성된 필드 형식과 상태 값을 확인한다.
  2. 한 클라이언트에서 레코드를 만들고 다른 클라이언트에서 즉시 조회한다.
  3. 사람과 에이전트가 같은 레코드를 수정한 뒤 변경 주체와 이전 값이 남는지 본다.
  4. 필드를 추가하거나 상태 이름을 바꾸고 기존 레코드와 조회가 유지되는지 점검한다.
  5. JSON 조회 결과를 받아 다른 저장소로 옮길 수 있는지 시험한다.
  6. 잘못된 AI 요청으로 대량 변경이 발생했을 때 탐지와 복구가 가능한지 확인한다.

평가할 때는 데모의 자연스러운 대화보다 운영 지표를 남기는 것이 좋다. 레코드 생성 성공률, 잘못 분류된 항목 수, 사람이 수정한 횟수, 조회 결과를 얻는 데 걸린 대화 횟수, 연결 실패 시 복구 시간, 예상 월 사용량을 기록하면 기존 도구와 비교하기 쉽다. 매주 반복되는 입력과 조회를 실제로 줄인다면 검토 가치가 커지지만, 매번 프롬프트를 다듬고 결과를 수동 검증해야 한다면 전용 UI보다 효율적이라고 보기 어렵다.

도입 여부를 가르는 체크포인트

항목 확인할 질문 판단 기준
적용 범위 내 계정과 클라이언트에서 원격 MCP 연결 및 쓰기가 가능한가? 주로 사용하는 환경 두 곳 이상에서 같은 레코드를 안정적으로 다룰 수 있어야 한다.
가격 사용자, 에이전트, 호출량, 저장량에 따라 비용이 어떻게 달라지는가? 기존 도구 비용뿐 아니라 구축·운영·검수 시간까지 함께 비교한다.
권한 사람과 에이전트의 읽기·쓰기 범위를 분리할 수 있는가? 최소 권한 원칙을 적용할 수 없으면 민감한 자료에는 사용하지 않는다.
변경 이력 필드별 이전 값과 작업 주체를 조회하고 필요한 경우 복구할 수 있는가? 기록 열람만 가능한지, 실제 되돌리기까지 가능한지를 구분한다.
데이터 이동 전체 레코드, 관계, 스키마와 활동 이력을 내보낼 수 있는가? 일반 JSON 조회와 완전한 백업·이관이 같은지 확인한다.
운영 안정성 장애, 연결 만료, 중복 실행과 동시 수정은 어떻게 처리되는가? 실패가 발생해도 중복이나 데이터 손실을 발견하고 복구할 수 있어야 한다.
대안 기존 업무 도구나 직접 운영하는 데이터베이스로도 같은 결과를 얻을 수 있는가? 전환 비용보다 반복 작업 절감과 다중 클라이언트 공유 효과가 클 때 도입한다.

결론

Statey의 가장 분명한 제안은 “AI가 일하는 화면”이 아니라 “AI들이 공유하는 기록 계층”을 제공하겠다는 것이다. 여러 채팅과 에이전트가 동일한 티켓, 고객, 연구 결과와 실행 기록을 이어서 다뤄야 한다면 채팅 메모리나 로컬 파일보다 구조적인 접근이다. 스키마 버전, 필드 검증, 변경 주체 기록과 MCP 중심 연결도 이 목적에 맞춰져 있다.

하지만 UI가 없는 호스팅 데이터베이스라는 특성 때문에 권한 관리, 잘못된 대량 수정, 동시 쓰기 충돌, 서비스 장애와 데이터 반출이 실사용의 핵심 변수가 된다. 가격과 플랜 조건도 제공된 설명만으로는 판단할 수 없다. 따라서 민감하지 않은 작은 데이터로 다중 클라이언트 연결과 복구 절차를 먼저 검증하고, 공식 문서에서 보안·보존·권한·비용 조건을 확인한 뒤 범위를 넓히는 것이 적절하다.

출처와 검증

제품의 기능 설명과 지원 대상으로 제시된 MCP 클라이언트는 Statey 공식 페이지를 기준으로 정리했다. 가격, 플랜별 제한, 보안 및 데이터 보존 정책, 세부 권한 모델, 향후 기능의 제공 시점은 실제 적용 전에 공식 문서와 계정 화면에서 다시 확인해야 한다.