CrisisIQ: 상충되는 사건에 대한 AI 조사 워크스페이스

이 글은 Sanity Challenge의 Path Two: Vibe-Code Something Strange 제출물입니다.

제가 만든 것 (What I Built)
사건 조사는 정보가 부족해서 실패하는 경우가 드뭅니다. 오히려 너무 많은 정보, 즉 서로 다른 출처에서 왔고 발생한 일에 대한 버전이 다른 정보들 때문에 실패합니다.

그래서 저는 CrisisIQ를 만들었습니다. 이 워크스페이스는 구조화된 Sanity 콘텐츠를 증거 계층(evidence layer)으로 사용하고 Gemini를 조사 에이전트(investigation agent)로 활용하는 사건 조사 도구입니다.

단순히 AI에게 다음과 같이 질문하는 대신:
"무엇이 이 사건을 야기했습니까?"

CrisisIQ는 다른 질문을 중심으로 설계되었습니다:
"사용 가능한 증거가 실제로 무엇을 뒷받침합니까?"

이 앱을 사용하면 조사관이 다음 작업을 수행할 수 있습니다:

• 사건 타임라인 재구성
• 개별 증거 기록 검토
• 상충되는 주장 비교
• 모순점 식별
• 불확실성 가시화 유지
• 기저의 Sanity 지식 기반에 대해 AI 조사 에이전트에게 질문하기
• 답변을 생성하기 전에 관련 구조화된 콘텐츠 검색

첫 번째 사례는 PulsePay: 37분 서비스 중단이라는 가상의 사건입니다.

데모 (Demo)
🚀 라이브 데모:
https://crisis-chmb8ibjr-northstar-e8ce.vercel.app/

배포된 앱은 다음 기능을 포함합니다:
인증(Authentication) → 조사 워크스페이스(Investigation Workspace) → 타임라인(Timeline) → 증거(Evidence) → 모순 분석(Contradiction Analysis) → AI 조사

메인 조사 워크스페이스 (Main investigation workspace)
The 인터페이스는 일반적인 AI 챗봇보다는 내부 조사 도구처럼 느껴지도록 의도적으로 설계되었습니다. 조사관은 케이스의 맥락을 잃지 않으면서 사건 개요, 타임라인, 증거 사이를 이동할 수 있습니다.
증거 및 모순 보기 (Evidence & contradiction view)

중요한 설계 결정 중 하나는 단일 근본 원인을 강제하기보다 상충되는 설명들을 보여주는 것이었습니다.
예를 들어, 배포 기록은 특정 시점에 롤백(rollback)이 발생했음을 나타낼 수 있지만, 모니터링 데이터는 사고가 더 일찍 시작되었음을 시사할 수 있습니다. UI는 이러한 불일치를 가시적으로 만듭니다.
AI 조사

조사 에이전트는 프론트엔드에 표시된 정보만으로 단순히 답변해서는 안 됩니다.
의도된 흐름은 다음과 같습니다:

조사자(Investigator)
↓
CrisisIQ
↓
Gemini
↓
Sanity Context MCP
↓
Sanity Knowledge Base
↓
검색된 증거(Retrieved evidence)
↓
증거 기반 응답(Evidence-grounded response)

이러한 구분이 프로젝트에 중요했습니다.
코드
전체 프로젝트는 여기에서 확인할 수 있습니다:
GitHub:
CrisisIQ GitHub Repository
레포지토리에는 프로젝트에 사용된 프론트엔드, API 라우트 및 배포 구성이 포함되어 있습니다.
제 빌드 프로세스
아마도 이 프로젝트에서 가장 흥미로운 부분일 것입니다.
저는 완벽하게 설계된 아키텍처로 시작하지 않았습니다.
단순한 아이디어, 즉

1. 조사 개념부터 시작하여 첫 번째 버전은 기본적인 사건 대시보드에 초점을 맞췄습니다:
2. 사건 개요 (incident overview)
3. 타임라인
4. 증거 (evidence)
5. 상충되는 주장 (conflicting claims)
6. 조사 인터페이스 이 제품이 실제 사건 분석가가 사용할 수 있는 도구처럼 느껴지도록 하는 것이 목표였습니다. 저는 의도적으로 화면 중앙에 텍스트 상자가 있는 또 다른 일반적인 챗봇처럼 보이게 하는 것을 피했습니다.
7. 콘텐츠 구조화 다음 단계는 AI가 실제로 무엇을 조사해야 할지 파악하는 것이었습니다. 모든 것을 프론트엔드 코드에 직접 넣는 대신, 프로젝트는 사례 인터페이스와 조사를 위해 사용되는 지식을 분리합니다. 이것이 Sanity 레이어로 이어졌습니다. 개념적 콘텐츠 모델은 다음과 같아졌습니다: 콘텐츠 (Content) 목적 (Purpose) 사건 (Incident) 주요 조사 맥락 (Main investigation context) 타임라인 (Timeline) 발생 사건 재구성 (Event Reconstruct what happened) 증거 저장소 (Evidence Store supporting source material) 주장 설명이나 진술을 나타냄 (Claim Represent an explanation or statement) 모순 연결되는 경쟁적인 증거 (Contradiction Connect competing evidence) 조사 맥락 에이전트에게 구조화된 정보를 제공함 (Investigation Context Provide structured information to the agent)

이를 통해 Sanity는 단순히 텍스트를 저장하는 곳 이상의 것이 되었습니다.
조사 경험 뒤에 있는 지식 레이어가 된 것입니다.

1. 일반적인 Sanity 프론트엔드를 넘어 확장하기 이곳에서 프로젝트가 더 흥미로워졌습니다. 다음과 같이 구축하는 대신:
   Sanity → React → 표시 콘텐츠 (Display Content)

저는 다음을 원했습니다:
Sanity
↓
맥락 검색 (Context retrieval)
↓
AI 조사 (AI investigation)
↓
맞춤형 조사 인터페이스 (Custom investigation interface)

이 애플리케이션은 서버 측 조사 경로를 사용하며 AI 레이어를 Sanity Context MCP에 연결합니다.
의도된 아키텍처는 다음과 같습니다:
CrisisIQ 조사 흐름 (Investigation Flow)

CrisisIQ 조사 UI
↓
조사 API (Investigation API)
↓
Gemini 조사 에이전트 (Gemini Investigation Agent)
↓
Sanity Context MCP
↓
Sanity 지식 기반 (Sanity Knowledge Base)

CrisisIQ 조사 UI
사용자는 질문을 하고, 사건을 탐색하며, 증거, 타임라인, 모순점, 그리고 AI가 생성한 통찰력을 검토합니다.

조사 API
조사 요청을 처리하고, 맥락을 관리하며, 애플리케이션을 Gemini 및 Sanity에 안전하게 연결합니다.

Gemini Investigation Agent
검색된 컨텍스트를 분석하고, 증거들을 비교하며, 모순점을 식별하고, 증거 기반의 조사 답변을 생성합니다.

Sanity Context MCP
Sanity로부터 관련 구조화된 사고 내용(incident content), 증거(evidence), 타임라인(timelines), 주장(claims) 및 관련 기록을 검색합니다.

Sanity Knowledge Base
사고, 증거, 타임라인 이벤트, 주장, 모순점, 그리고 지원 출처를 포함한 구조화된 조사 데이터를 저장합니다.

이 부분이 제가 가장 중요하게 생각했던 부분입니다.
AI가 답을 아는 척하는 것을 원하지 않았습니다.
오히려 AI가 먼저 증거를 검색하고 그 증거로부터 추론하기를 바랐습니다.
효과적이었던 프롬프트(The Prompts That Worked)
빌드를 하면서 얻은 가장 큰 교훈 중 하나는 모호한 프롬프트는 모호한 구현을 낳는다는 것이었습니다.
기술 자체에 대한 설명보다는 원하는 동작 방식을 설명했을 때 프롬프트가 훨씬 유용해졌습니다.
예를 들어:

'사용 가능한 증거가 불완전할 때 AI가 근본 원인을 지어내지 않도록, 증거와 모순점을 중심으로 조사 경험을 구축하세요. 경쟁하는 여러 설명을 보여주고 불확실성을 보이게 하세요.'라는 프롬프트는 단순히 '사고 관리 대시보드를 만드세요(Make an incident management dashboard)'라고 말하는 것보다 훨씬 나은 제품 결정을 이끌어냈습니다.

또 다른 유용한 패턴은 AI에게 한 번에 하나의 시스템으로 작업하도록 요청하는 것이었습니다:

증거 모델 구축
↓
타임라인 구축
↓
모순 분석 구축
↓
Sanity 연결
↓
조사 API 연결
↓
Gemini 연결
↓
배포
↓
디버깅

효과적이지 않았던 프롬프트 (The Prompts That Didn't Work) 😭
모든 것이 첫 시도에 성공한 것은 아니었습니다.
솔직히 말해, 그것이 프로젝트에서 가장 유용했던 부분 중 하나가 되었습니다.
여러 단계에 걸쳐 다음과 같은 문제들에 직면했습니다:

• 배포 구성 (deployment configuration)
• 인증 경로 (authentication routes)
• 환경 변수 (environment variables)
• Sanity Context 자격 증명 (credentials)
• Gemini API 구성
• Vercel 배포 동작 (Vercel deployment behavior)
• 조사 API가 답변을 반환하지 않는 경우 (the investigation API returning no answer)
• UI 상태가 백엔드 상태와 일치하지 않는 경우 (UI state not matching the backend state) 한때 애플리케이션 자체는 작동했지만, 조사 에이전트는 다음과 같이 반환했습니다: "조사 서비스에 서버 자격 증명이 누락되었습니다."

이는 전혀 프론트엔드의 문제가 아니었습니다.
누락된 서버 측 구성은 다음과 같았습니다:
SANITY_API_READ_TOKEN
GOOGLE_GENERATIVE_AI_API_KEY

이 디버깅 과정은 제가 AI 네이티브 개발에 대해 생각하는 방식을 바꾸어 놓았습니다.
AI는 매우 빠르게 엄청난 양의 코드를 생성할 수 있습니다.
하지만 제품을 출시한다는 것은 그것이 실제로 무엇을 하는지 반복적으로 테스트하고, 오류를 읽고, 실패한 경계를 찾아내고, 다시 프롬프트를 입력하는 것을 의미합니다.

방향 수정 (Course-Correcting) - 처음부터 다시 시작하기보다
무언가 고장 날 때마다 프로젝트를 버리는 대신, 저는 문제를 계속 좁혀나갔습니다.
예를 들어:
"AI 조사가 작동하지 않음"
↓
"API가 답변을 반환하지 않음"
↓
"서버 자격 증명 누락"
↓
"Sanity 토큰 / Gemini 키 구성"
↓
"Vercel 환경 확인"
↓
"재배포 (Redeploy)"
↓
"실제 조사 요청 테스트"

이 반복적인 루프는 구축의 주요 부분이 되었습니다.

Sanity가 여기서 중요한 이유

저는 Sanity가 프로젝트 뒤에 놓인 장식용 CMS가 되기를 원하지 않았습니다. 아이디어는 조사 에이전트가 프런트엔드에서 보이는 모든 것에 전적으로 의존하기보다는, 사건에 대한 구조화된 지식에 접근할 수 있어야 한다는 것입니다.

이는 중요한 분리를 만듭니다:

• 프런트엔드 콘텐츠 → 조사관이 보는 것
• Sanity 콘텐츠 → 조사 시스템이 검색할 수 있는 것
• Gemini → 검색된 정보에 대한 이유(근거)

이러한 분리가 CrisisIQ를 단순히 AI 버튼이 붙은 대시보드 이상의 것으로 만듭니다.

제가 집중한 부분

이 프로젝트는 네 가지 원칙을 중심으로 구축되었습니다:

다음으로 구축할 것들 (What I Would Build Next)

챌린지 이후에도 CrisisIQ 개발을 계속한다면, 저는 조사 워크플로우를 더욱 발전시킬 것입니다. 몇 가지 아이디어가 있습니다:

• 조사 결론에 대한 승인 상태(approval states)
• AI가 생성한 발견 사항에 대한 인간 검토
• 사건 간 비교(incident-to-incident comparison)
• 자동 증거 클러스터링
• 조사 기록(investigation history)
• 더 풍부한 Sanity 워크플로우
• 실시간 협업 조사
• 자동화된 사건 보고서
• 증거 신뢰도 점수화(evidence confidence scoring)

흥미로운 점은 콘텐츠 모델이 이미 애플리케이션이 성장할 수 있는 공간을 제공한다는 것입니다. Sanity 프로젝트 세부 정보: Sanity 프로젝트 ID: PASTE YOUR SANITY PROJECT ID HERE

데이터셋:
production

Sanity 컨텍스트:
Sanity Context MCP
읽기 전용 조사 지식 검색

이 프로젝트는 조사 에이전트의 구조화된 지식 계층으로 Sanity를 사용합니다.
중요: 저는 이 게시물에 개인 API 토큰이나 자격 증명을 의도적으로 포함하지 않았습니다.

Agent Session

에이전트 세션(Agent Session):
PASTE YOUR PUBLIC DEV AGENT SESSION LINK HERE
이 기록은 특히 빌드의 반복적인 과정: 프롬프트, 실패한 시도, 디버깅 및 경로 수정 과정을 보여주는 데 유용합니다.
빌드 과정의 몇 가지 화면들
조사 워크스페이스(Investigation workspace)

증거 비교(Evidence comparison)

AI 조사(AI investigation)