비결정적 시스템 테스트하기

먼저 해보고 말해요. 시나리오 A는 진짜 HTTP 장애 서버예요: 동작을 큐에 세우고, 요청마다 하나를 소모하며, 클라이언트가 어떻게 받는지 봐요. 시나리오 B는 결정적 리플레이: 실제 세션 로그로 리플레이 스크립트를 한 번에 유도해 다시 돌리고, 한 줄을 변조해 diff가 그 자리에서 증언하는 걸 봅니다.

비결정적 시스템을 테스트하는 생각은 하나뿐이에요: 불확실한 부분을 가두고 나머지는 전부 결정적으로 만들어요. DSH의 테스트 계층(docs/testing.zh.md)은 그 생각 위에 쌓여 있어요. 유닛 테스트는 경계 조건, 오류 경로, 이벤트 순서, 동시성 레이스를 노리고; CI 커버리지 게이트는 packages/*/*/src에 파일별 100%를 요구해요(AGENTS.md 65행 Commands 절). 문서도 단호해요: 행 커버리지는 필요조건이지 충분조건이 아니며, 안 돈 행은 대개 지워야 할 죽은 코드이지 채워야 할 테스트가 아니에요.

키가 있는 실제 API 테스트는 또 다른 층이에요. 정체성이 드러나는 한 구절:

추론이 우리에게는 싸니까 스모크 테스트는 진짜로 가요: 실제 예제를 띄우고, 프롬프트 하나를 보내고, 바깥세상을 확인해요. 단언도 까다로워야 해요. e2e는 파일을 다시 읽고 명령을 다시 돌려 결과를 검증해야 하며, agent 자기 출력에 키워드만 탐지하면 치팅 agent가 통과해요. 키가 없는 환경은 자동으로 건너뛰고, 누구의 막지도 않아요.

본편은 리플레이예요. 지난 레슨에서 다뤘죠( LLM 어댑터 계층 참고): 스트리밍 청크마다 assistant/chunk 이벤트로 세션 로그에 그대로 남아요. dsh-llm-replay 플러그인은 그걸 거꾸로 써요. 녹음된 session.jsonl을 가져와 chunk 이벤트를 (turn, step)으로 묶으면, 각 그룹이 그때 한 번 모델 호출의 완전한 청크 시퀀스예요. 테스트에서는 실제 agent가 그대로 돌고, 모델 쪽만 리플레이 어댑터로 바꿔 녹음된 청크를 프레임마다 토해내요. 비결정성은 녹음 그 한 번에만 있고, 이후 재실행은 바이트 단위로 같고 API Key도 필요 없어요.

이게 “로그가 곧 테스트 자산”의 뜻이에요. fixture는 손으로 쓴 mock이 아니라 프로덕션 포맷 세션 로그 그 자체예요. 스냅샷 테스트로 조립된 전체 동작을 고정하고, 코드 한 줄이 동작을 갈라놓으면 diff가 그 자리에서 빨개져요. fork(분기 세션)에도 정교한 디테일이 있어요: 자식 세션 로그 앞머리는 부모의 시드 이벤트를 물려받으니, 리플레이 스크립트를 유도할 때 seedLength 경계 뒤에서 잘라야 해요. 안 그러면 부모 청크가 자식 호출로 잘못 재생돼요:

    const text = readFileSync(childFile, 'utf8')
    const header = parseSessionHeader(text)
    // Derive the child's script from its own events only — events AT OR after the seed
    // boundary.
    const ownEvents = parseSessionLog(text).slice(header.seedLength)
    children.push({
      recordedId: header.id,
      createdAt: header.createdAt,
      entries: deriveReplayScript(ownEvents),
      primary: false,
    })

크로스 플랫폼 규율도 여기서 나와요. 체크인한 fixture는 macOS와 Linux에서 모두 리플레이돼야 하고, 녹음된 스냅샷이 어느 플랫폼에서든 깨지면 fixture 자체를 고치세요. AGENTS.md 123행 원문은 “fix fixtures, not normalizers”: fixture를 고치고, 정규화기를 쓰지 마세요. 정규화기는 테스트와 현실 사이에 솜을 끼우는 일이고, 많이 끼우면 현실을 테스트하지 못하게 돼요.

리플레이는 동작이 변하지 않는지를 봐요 — 아직 한 조각이 남아요: 전송 계층의 화려한 죽는 법. 연결 거부, 전송 중 socket 리셋, 정상 종료인데 [DONE] 없음, Retry-After가 있는 레이트 리밋, 아예 멈춰 있기. 각각은 어댑터와 복구 계층 눈엔 다른 것이고, 프로세스 안 mock으로는 전부 못 잡아요. mock이 fetch, SSE 프레이밍, socket 종료, 유휴 워치독 같은 실제 경계를 우회하거든요. 그래서 DSH는 dsh-llm-mock-server를 만들었어요: OpenAI 방언을 쓰는 진짜 Node HTTP 서버, 동작은 전부 스크립트 제어, 요청마다 동작 하나 소모, 스크립트가 바닥나면 명시적으로 오류(설계 동기는 Agent Note 2026-07-25-scriptable-llm-wire-fault-server.zh.md). 개발자가 수동으로 장애를 재현하려면 base URL과 key만 바꿔 어떤 앱이든 붙이면 돼요.

random 모드도 있어요. 가중치로 장애를 뽑아 스트레스 테스트하고, seed는 공개·재현 가능해요. 기본 가중치 표 자체가 LLM 클라이언트가 현장에서 만나는 것의 체크리스트예요: 정상 성공 48, 느린 성공 10, 중간 끊김(partial_disconnect) 10, 연결 리셋·끊김·빈 응답·레이트 리밋 각 5, 서버 오류 4, max_tokens 도달·정지 hang·503 각 2, 제일 고약한 둘은 각 1 — 스트림은 정상 끝나지만 덜 보낸 partial_eof, 그리고 깨진 JSON을 뱉는 malformed_json. 소스 주석도 짚어요: 이건 조절 가능한 테스트 압력 설정이지, 프로덕션 사고 빈도 추정이 아니에요.

출처: packages/test-support/llm-mock-server/src/index.ts 56–70행 DEFAULT_MOCK_LLM_RANDOM_WEIGHTS, 확인일 2026-08-13.

서버의 절제는 분명해요: 프로토콜 계층 사실만 보고하고, 재시도할지 말지는 판단하지 않아요 — 정책은 harness 몫이에요. 실제 조합 테스트는 요청을 DeepSeek 어댑터, agent loop, 재시도 플러그인 순으로 통과시키며, 검증은 구체적이에요: 요청 횟수 정확, 재시도 단계에 번호, 실패한 반쪽 청크가 히스토리로 새지 않음, 정상 EOF의 반쪽 출력은 STREAM_CLOSED로 분류되고 기본은 재시도 안 함.

마지막 무기는 아무도 생각 못 한 교차예요. 프로토콜 형태 코드(청크 스트림, 이벤트 로그, 인박스 스케줄링)의 입력 공간은 조합 폭발이고, 예시 테스트는 이미 떠올린 케이스만 고정해요. DSH는 프로토콜 형태 패키지마다 fast-check 기반 속성 테스트를 붙여요: 생성기가 현실적이지만 적대적인 입력(중복 인덱스, 지연 청크, block-start 없는 기형 스트림)을 만들고, 단언은 구체 출력이 아니라 불변조건이에요 — 조립된 블록 수는 본 서로 다른 인덱스를 넘을 수 없고, 반복 호출 결과는 안정해야 해요. 실패하면 재현 가능한 seed를 자동으로 찍어요.

전과는 Agent Note 첫 줄에 적혀 있어요:

이 인프라의 부산물도 있어요. BENCHMARK.md의 공식 벤치마크 경로는 Python SDK에 minimal 변형이고, 작업마다 독립 workspace예요. 테스트 체계가 탄탄하면 평가는 입력만 바꾸면 돼요.