Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Archie는 사용자가 대화하며 시스템 설계를 할 수 있는 인터랙티브 보드입니다. 음성 또는 타이핑 명령을 통해 다이어그램 업데이트, 실시간 부하 시뮬레이션, 장애 주입 등을 수행합니다. 특히 AI 계층은 추측 대신 명확한 질문을 던지도록 설계되어 사용자의 취약점을 파악하는 데 중점을 둡니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기첫 번째 비(非)평가 실행(eval run)에서 Archie는 91.2%를 기록했습니다. 점수보다 더 걱정했던 것은 세 가지 실수 중 하나였습니다. 저는 그것에게 “워커들을 데이터베이스에 연결하라”고 지시했고, 보드에는 두 개의 데이터베이스가 있었는데, 그것은 조용히 그중 하나를 선택했습니다.
아무것도 충돌하지 않았습니다. 다이어그램만 잘못되었을 뿐이고, 잘못된 아키텍처 다이어그램은 정확한 것과 똑같이 보입니다. 이 글은 제가 Archie를 어떻게 구축했는지, 그리고 제가 가장 중요하게 생각하는 기능이 왜 멈추고 질문하도록 만드는 것인지에 대한 내용입니다.
Archie는 사용자가 대화할 수 있는 시스템 설계 보드입니다. “API 복제본 다섯 개” 또는 “Redis를 종료하라(kill Redis)”라고 말하면 다이어그램이 업데이트되고, 시뮬레이터가 시스템이 어느 지점에서 포화되는지, 어떤 요청이 실패하는지, 그리고 그 이유를 보여줍니다. 저는 이 도구를 Hacker House Goa 2026의 Wispr Flow 챌린지를 위해 만들었으며, 주로 구술(dictation)을 통해 두 종류의 사람들을 위해 설계되었습니다: 설계를 스케치하는 엔지니어와 시스템 설계 인터뷰를 연습하는 학생들.
모든 명령은 두 개의 계층을 거치며, 둘 다 같은 규칙을 따릅니다. 만약 어느 한 계층도 확신하지 못하면, 행동하지 않습니다.
**빠른 경로(The fast path)**는 앵커링된 문법(anchored grammar)을 가진 결정론적 파서(deterministic parser)입니다. 이는 “그 DB(the db)”, “그것(it)”, 또는 “postgres 복제본 하나(postgres replica one)”와 같은 이름을 해결하고, 브라우저에서 “Postgres를 두 개로 샤딩하라(shard Postgres into two)”와 같은 명령을 처리합니다. 이 파서는 14,000회 실행 동안 P50 기준 0.006ms의 속도를 보입니다. 92개 사례 평가 세트(92-case eval set)에서는 8개의 사례만 처리했지만, 그 8개 모두 정확했습니다. 다른 모든 경우에 대해서는 침묵하며 거절하는 것이 핵심입니다.
**AI 계층(The AI tier)**은 빠른 경로(fast path)가 처리하지 못하는 모든 것을 담당합니다. 서버는 모델에게 보드, 시뮬레이터 요약, 마지막 몇 차례의 채팅 턴, 그리고 명령을 포함하는 압축된 텍스트 형태를 전송합니다. 이 모델은 free-tier Gemini 모델 계층에서 Groq를 폴백(fallback)으로 사용하여 실행됩니다. 모델이 반환할 수 있는 것은 오직 다섯 가지 중 하나입니다: 수정 사항(edits), 명확화 질문(a clarifying question), 확인 요청(a confirmation request), 답변(an answer), 또는 아무 작업 없음(no-op).
모델은 보드를 직접 수정하지 않습니다. 대신 유형화된 연산(typed operations)을 제안하고, 코드가 이를 검증하며, 유효하지 않은 배치(batch)는 질문으로 바뀌기 전에 한 번의 복구 시도 기회를 받습니다. 연산은 원자적으로 적용되므로(atomically), 잘못된 하나의 연산이 아무것도 변경하지 않으며 모든 것을 되돌릴 수 있습니다.
command
→ fast path (결정론적, 확정적이거나 무음)
→ AI tier (Gemini → Groq) → 제안된 연산(proposed ops)
...
가드레일은 제가 분리된 테스트 세트(held-out test split)를 처음 실행했을 때 이미 존재했습니다. 모델은 여전히 “데이터베이스”를 보고 두 개의 후보를 발견했으며, 자신감을 가지고 하나를 선택했습니다. 이는 34건 중 1번의 잘못된 행동이었습니다.
프롬프트 수정만으로도 간단한 해결책이었을 것입니다. 대신 저는 코드에 가드(guard)를 추가했습니다: 참조가 둘 이상의 구성 요소와 일치하는 경우, Archie는 '어떤 데이터베이스요?'라고 물으며 탭 가능한 답변을 제시합니다. 이는 모델의 행동에 의존하지 않습니다.
분리된 세트에 대한 두 번째 실행은 잘못된 행동이 전혀 없는 상태로 97.1%(34건 중 33건)를 기록했습니다. 이 점프의 일부는 free-tier 모델에서 발생하는 실행 간 편차(run-to-run variance)이며, 저는 이를 저장소에 결과 옆에 작성해 두었습니다. 제가 신뢰하는 수치는 '잘못된 행동이 없음'인데, 이는 코드 내 가드에 의해 강제되기 때문입니다.
모든 수정 사항은 대기열 모델(queueing model)을 재실행합니다: 정상 상태의 복제본당 M/M/1이며, 캐시 어사이드 읽기(cache-aside reads), 읽기 복제본(read replicas), 샤딩(sharding), 백로그 및 장애 조치 기능이 있는 대기열, 그리고 지연 시간을 위한 10,000 샘플의 몬테카를로 시뮬레이션(Monte Carlo)을 포함합니다. 100개 구성 요소 시스템은 P95에서 2.39ms 만에 시뮬레이션되므로, 사용자가 말하는 동안에도 보드는 따라옵니다.
저는 시뮬레이터가 단순히 노드를 빨간색으로 칠하기만 하기를 원하지 않았습니다. 병목 지점에는 산술 계산과 함께 메모를 추가했습니다:
1,500 reads/s + 5,000 writes/s on 1 샤드
(샤드당 용량: read 10,000 / write 4,000)
→ ρ = 1.40 → 요청의 28.6%가 드롭됨
이 수치들은 수동 계산을 통해 골든 테스트(golden-tested)되었습니다. 이것은 공급업체 벤치마크가 아닌 교육용 모델이며, 문서에는 모든 가정이 나열되어 있습니다.
동일한 엔진이 인터뷰 모드(interview mode)에도 사용됩니다. SLO 체크리스트(성공률, read 및 write p99, 헤드룸(headroom), 단일 장애 생존 여부, 비용)는 모델에 의해 판단되는 것이 아니라 시뮬레이터가 계산합니다. 최종 점수표는 이러한 검사들을 5개 항목의 루브릭(rubric)과 결합하며, 모든 점수는 보드의 증거를 인용해야 합니다.
제가 달성하지 못한 목표 중 하나가 있습니다. 답변의 95%가 시뮬레이터의 수치만을 인용하기를 바랐습니다. 테스트 분할에서는 3개 중 2개였습니다. 다음으로 다중 턴 평가(multi-turn eval) 카테고리와 함께 개선할 부분입니다.
Next.js 16, React 19 및 TypeScript, Web Worker 내의 ELK 레이아웃을 가진 React Flow, 상태 관리를 위한 Zustand와 IndexedDB, API를 위한 Hono, 검증(validation)을 위한 Zod, 테스트를 위한 Vitest, fast-check, Playwright로 구성되어 있습니다. Render에서 단일 Docker 컨테이너로 실행됩니다.
사람들이 신뢰하는 것을 편집하는 도구는 영리하기보다는 더 조심해야 합니다. 명확히 하는 가드(clarifying guard)를 추가했을 때 Archie의 정확도는 거의 변하지 않았지만, 모호한 명령어에 대해 어떤 행동을 할지 걱정하는 것은 멈췄습니다.
Live: archie-rb2x.onrender.com (무료 호스팅이므로 첫 로드는 약 1분이 걸릴 수 있습니다)
GitHub: github.com/im-shourya/Archie
50k rps 데모를 열고 “shard Postgres into two”라고 말해 보세요.
본 내용은 shouryaparashar.in에 원래 게시되었습니다.