Dynamic Workflow 품질 검증을 위한 7가지 패턴

Claude Code Dynamic Workflow에서 품질을 지키기 위한 핵심 패턴 일곱 가지를 정리했습니다. 먼저 한 줄 요약부터.

1. 적대적 검증 (Adversarial Verify)

발견된 주장이나 결과를 그대로 믿지 않고, 여러 독립 검증자가 반증을 시도하게 만드는 패턴입니다. 검증자의 기본 태도를 “맞는지 확인”이 아니라 “틀렸는지 찾아라”로 설정해 확증편향을 줄입니다.

작동 방식 — 하나의 claim에 대해 3명 이상의 검증자를 병렬로 실행하고, 각 검증자는 해당 claim을 반박할 근거를 찾습니다. 과반이 반증에 실패하면 결과를 채택하고, 과반이 반증하면 폐기합니다.

언제 쓰나 — 버그 리포트, 사실 주장, 수치 검증, 보안 취약점처럼 틀린 결과가 살아남으면 위험한 작업에 적합합니다.

같은 결과를 여러 번 검증하는 것이 아니라, 서로 다른 관점의 검증자가 서로 다른 실패 모드를 찾게 하는 패턴입니다. 단순 반복 검증보다 누락 가능성을 더 잘 줄입니다.

작동 방식 — 하나의 결과를 계산 정합성, 출처 신뢰도, 단위·기준 일관성, 재현 가능성 같은 독립적인 렌즈로 나누어 평가합니다. 모든 렌즈를 통과해야 최종 채택합니다.

언제 쓰나 — 코드 리뷰, 수치 검증, 정책 검토, 리서치 검증처럼 오류 원인이 여러 축으로 나뉘는 작업에 적합합니다.

주의점 — 렌즈가 실제로 달라야 합니다. 비슷한 관점 4개를 붙이면 검증이 아니라 중복 질문이 됩니다.

하나의 안을 만들고 고치는 방식이 아니라, 여러 접근법을 독립적으로 생성한 뒤 병렬 심사를 거쳐 가장 강한 안을 합성하는 패턴입니다.

작동 방식 — 예를 들어 MVP 우선, 리스크 우선, 사용자 우선 같은 서로 다른 관점의 초안을 생성합니다. 이후 각 안을 기준별로 채점하고, 1등 안을 기반으로 하되 2·3등 안의 장점을 이식합니다.

언제 쓰나 — 전략 수립, 설계, 카피라이팅, 레이아웃, 아키텍처 선택처럼 정답이 하나가 아니고 접근 방식이 품질을 좌우하는 작업에 적합합니다.

주의점 — 심사 기준이 불명확하면 점수가 노이즈가 됩니다. 또한 1등 안을 그대로 복사하면 패널의 의미가 사라집니다.

목표 개수를 채우는 것이 아니라, 더 이상 새로운 발견이 나오지 않을 때까지 반복하는 패턴입니다. 미리 몇 개를 찾을지 알 수 없는 문제에서 특히 강력합니다.

작동 방식 — 각 라운드에서 여러 파인더가 발견을 수행합니다. 이미 본 항목은 seen 기준으로 제거하고, 신규 발견이 없으면 dry 카운터를 올립니다. 예를 들어 2라운드 연속 신규 발견이 없으면 종료합니다.

언제 쓰나 — 버그 감사, 리스크 탐색, 엣지케이스 발굴, 보안 점검처럼 “전부 찾아라”에 가까운 작업에 적합합니다.

주의점 — 중복 제거 기준은 채택된 항목이 아니라 본 적 있는 전체 항목이어야 합니다. 탈락한 항목을 다시 검토 대상으로 넣으면 루프가 수렴하지 않습니다.

같은 대상을 여러 방식으로 동시에 훑어 커버리지를 넓히는 패턴입니다. 한 가지 검색 방식이나 한 가지 관점으로는 놓치는 정보가 생기기 때문입니다.

작동 방식 — 동일한 검증 대상을 문서별, 키워드별, 엔티티별, 시간별, 출처별로 나누어 병렬 탐색합니다. 이후 결과를 병합하고 중복을 제거합니다.

언제 쓰나 — 리서치, 실적 검증, 대규모 문서 분석, 코드베이스 감사처럼 검색 누락이 품질 저하로 이어지는 작업에 적합합니다.

주의점 — 주제 분해와 혼동하면 안 됩니다. Multi-modal Sweep은 여러 주제를 나누는 것이 아니라 같은 타깃을 서로 다른 경로로 찾는 것입니다.

최종 결과를 내기 직전에 “무엇이 빠졌는가?“를 전담해서 묻는 비평가를 두는 패턴입니다. 결과의 정확성뿐 아니라 누락 여부를 별도로 점검합니다.

작동 방식 — 현재 산출물, 분석 결과, 검증 결과, 참고 출처를 비평가에게 전달합니다. 비평가는 안 돌린 탐색 모달리티, 미검증 주장, 안 읽은 출처, 누락된 분기나 세그먼트를 찾아냅니다. 발견된 갭은 다음 보완 라운드의 작업 항목이 됩니다.

언제 쓰나 — 망라성이 중요한 리서치, 감사, 리뷰, 보고서 작성에 적합합니다.

주의점 — “빠진 게 있나?“처럼 막연히 묻지 말고, 모달리티·주장·출처·세그먼트처럼 구체적인 점검 항목을 줘야 합니다.

처리 범위를 줄였거나 일부만 검토했다면, 무엇을 버렸는지 반드시 드러내는 패턴입니다. 조용한 생략은 사용자에게 “전부 처리했다”는 잘못된 인상을 줍니다.

작동 방식 — 후보가 128개인데 상위 20개만 분석했다면, 108개가 미처리되었다고 log() 또는 결과 보고서에 명시합니다. 추정값, 역산값, 불완전한 출처도 confidence와 notes로 표시합니다.

언제 쓰나 — Top-N 필터링, 샘플링, 예산 제한, 시간 제한, 무재시도 처리 등 커버리지를 줄이는 모든 상황에 적용해야 합니다.

주의점 — 침묵이 가장 큰 위험입니다. 생략 자체보다 생략을 숨기는 것이 품질 문제를 만듭니다.