AI 에이전트 테스트, 분산시스템의 주장부터 검증한다

GitHub의 distributed-system-testing은 AI 코딩 에이전트가 분산·상태 시스템을 테스트하도록 설계된 두 개의 SKILL.md 파일을 제공한다. README에 따르면 이 워크플로는 Claude Code, Codex, Copilot CLI, Cursor, Gemini처럼 Markdown을 읽고 셸을 실행할 수 있는 에이전트에서 동작한다. 하나의 스킬은 테스트 계획을 만들고, 다른 스킬은 실행한다. 결과물은 구조화된 Markdown 테스트 계획과 findings report다.

핵심은 claim-driven testing이다. 제품이 약속하는 주장을 먼저 쓰고, 각 시나리오는 그 주장을 특정 장애 조건에서 반증하려고 한다. 일관성 관련 시나리오는 register, queue, log, lock, lease, ledger 같은 추상 모델, operation-history schema, named checker, nemesis, 관측 가능한 증거를 함께 요구한다. README는 9-state verdict와 SUT, harness, checker, environment blame classification도 강조한다. 관련 배경으로 Jepsen analyses, OWASP Testing Guide, TLA+를 함께 볼 수 있다. 내부 기사로는 Statewright 상태기계 신뢰성, AI 시대 시니어 개발자의 언어, LLM 위임 작업의 문서 손상을 연결할 수 있다.

에이전트에게 테스트를 맡길 때 생기는 문제

AI 코딩 에이전트는 코드를 빨리 만든다. 하지만 분산시스템 버그는 보통 빠른 happy path 테스트로 잡히지 않는다. 네트워크 파티션, crash-recovery, replay, idempotency, timing-sensitive ordering 같은 문제는 의도적으로 괴롭혀야 드러난다. 에이전트에게 막연히 '테스트해'라고 하면 기존 테스트를 돌리고 통과했다고 말하기 쉽다. distributed-system-testing은 이 느슨함을 형식으로 막는다.

Markdown 스킬이라는 포맷이 중요하다

이 프로젝트는 별도 SaaS보다 SKILL.md를 택했다. 이는 에이전트 시대의 흥미로운 제품 형태다. 사람이 읽는 운영 문서와 에이전트가 실행하는 절차가 같은 파일 안에 있다. 특정 벤더 API가 아니라, Markdown을 읽고 명령을 실행할 수 있는 에이전트라면 이식 가능하다.

물론 자동화가 전부는 아니다. README도 최종적으로 reviewer가 계획과 findings report를 읽고 ship 여부를 결정한다고 설명한다. 좋은 구조다. 에이전트는 넓은 테스트 탐색과 기록 생산을 맡고, 사람은 위험 수용과 제품 판단을 맡는다. 이것이 AI 코딩을 안전하게 쓰는 기본 패턴이다.

한국 개발팀에 필요한 변화

한국 SaaS와 핀테크, 커머스 기업은 분산 큐, 결제 ledger, 재고 lock, 알림 queue 같은 상태 시스템을 많이 운영한다. 장애가 나면 단순 버그가 아니라 금전 피해와 신뢰 하락으로 이어진다. AI 코딩 에이전트를 도입한다면 생산성 지표만 보지 말고, 에이전트가 어떤 주장에 대해 어떤 실패를 시도했는지 기록하게 해야 한다.

또한 테스트 산출물을 PR의 일부로 넣는 문화가 필요하다. 'AI가 테스트 추가함'이 아니라 'claim C-03은 partition 후 no-lost-ack checker로 검증했고, 환경 원인으로 inconclusive가 남았다'처럼 말해야 한다. 이 언어가 생겨야 시니어 리뷰어가 AI 산출물을 신뢰할 수 있다.

결론

distributed-system-testing은 에이전트가 분산시스템 테스트를 더 잘하게 만드는 작은 도구처럼 보이지만, 실제 메시지는 크다. AI 코딩의 다음 단계는 더 많은 코드를 만드는 것이 아니라, 더 엄격한 실패 증거를 만드는 것이다. 한국 개발 조직은 에이전트 도입과 동시에 주장 기반 테스트, 판정 상태, 책임 분류, 재현 가능한 로그를 표준으로 삼아야 한다.

FAQ

distributed-system-testing은 무엇인가?

AI 코딩 에이전트가 분산·상태 시스템의 테스트 계획을 만들고 실행하도록 돕는 두 개의 SKILL.md 워크플로다.

claim-driven testing이란?

제품이 보장한다고 말하는 주장을 먼저 정의하고, 각 테스트가 그 주장을 특정 장애에서 반증하도록 설계하는 방식이다.

왜 9-state verdict가 필요한가?

분산시스템 테스트는 결과가 단순 pass 또는 fail로 떨어지지 않는 경우가 많다. 모호성과 환경 문제를 별도로 기록해야 한다.

어떤 에이전트에서 쓸 수 있나?

README는 Claude Code, Codex, Copilot CLI, Cursor, Gemini 등 Markdown을 읽고 셸을 실행하는 에이전트를 언급한다.

실무 도입의 첫 단계는?

핵심 제품 주장 목록을 만들고, 큐·락·ledger 등 상태 모델별로 checker와 실패 시나리오를 정의하는 것이다.