Claude Code 다이나믹 워크플로우 공식 발표 이미지
이미지: claude.com/blog (Introducing dynamic workflows in Claude Code)

여러 파일에 걸친 변경을 PR로 올리기 전에 직접 리뷰를 시키면, 보통 하나의 세션이 정합성·성능·재사용성을 한 번에 훑고 지나갑니다. 문제는 발견한 것 전부를 그대로 믿기가 애매하다는 점입니다. "이 부분이 N+1 쿼리가 될 수 있다"는 지적이 실제로 호출 경로를 추적해보면 과장인 경우도 있고, 반대로 가볍게 적어둔 지적이 진짜 버그인 경우도 있습니다. 세션 하나가 지적하고 바로 그 세션이 스스로 맞다고 결론 내리면 같은 맹점을 두 번 거치는 셈입니다.

어떤 작업이었나

직렬화 포맷을 바꾸는 PR이었습니다. 데이터 모델 열 개 남짓과 그걸 읽고 쓰는 레포지토리 코드가 같이 바뀌었는데, 관점이 서로 다른 지적이 나올 걸 알고 있었습니다. 정합성(마이그레이션 중 기존 데이터를 못 읽는 경우), 성능(역직렬화 비용), 재사용성(중복된 매핑 코드) 세 관점을 전부 보고 싶었지만, 한 세션에 세 관점을 다 맡기면 뒤쪽 관점일수록 앞쪽 지적에 끌려가면서 얕게 훑고 지나가는 경향이 있었습니다.

AI를 어떻게 활용했나

이번에는 Claude Code의 Workflow 도구를 처음 써봤습니다. 일반 Agent 도구와 다른 점은, 서브에이전트 여러 개를 스크립트로 미리 짜서 어떤 순서로 실행할지, 어디서 병렬로 갈라질지를 직접 정할 수 있다는 것이었습니다. 먼저 이렇게 요청했습니다.

use a workflow: 이번 직렬화 포맷 변경 diff를 정합성/성능/재사용성 세 관점으로 각각 리뷰하고,
각 관점에서 나온 발견마다 실제로 그 문제가 일어나는 입력·호출 경로가 있는지 별도로 검증해줘.

"use a workflow"라는 문구가 핵심이었습니다. 처음에 그냥 "세 관점으로 나눠서 리뷰하고 검증까지 해줘"라고만 썼더니 평범한 Agent 호출 몇 개로 처리됐습니다. Workflow 도구는 서브에이전트를 수십~수백 개까지 띄울 수 있어서 토큰을 많이 쓰기 때문에, 사용자가 명시적으로 워크플로우 실행에 동의한 경우에만 켜지도록 되어 있었습니다.

다시 요청한 뒤 세션이 만든 스크립트는 대략 이런 모양이었습니다.

export const meta = {
  name: 'review-serialization-migration',
  description: '직렬화 포맷 변경 diff를 3관점으로 리뷰하고 발견마다 검증',
  phases: [{ title: '리뷰' }, { title: '검증' }],
}

const DIMENSIONS = [
  { key: 'correctness', prompt: '정합성 관점: 마이그레이션 중 기존 포맷 데이터를 읽는 경로가 빠짐없이 처리되는지 확인' },
  { key: 'performance', prompt: '성능 관점: 역직렬화 경로에서 반복 파싱·불필요한 복사가 생기는지 확인' },
  { key: 'reuse', prompt: '재사용성 관점: 모델 간 매핑 코드가 중복되는지 확인' },
]

const reviews = await parallel(
  DIMENSIONS.map(d => () => agent(d.prompt, { label: `review:${d.key}`, phase: '리뷰', schema: FINDINGS_SCHEMA }))
)

const verified = await pipeline(
  reviews.flatMap(r => r.findings),
  f => agent(`이 지적이 실제 입력/호출 경로로 재현되는지 검증: ${f.title}`,
    { label: `verify:${f.file}`, phase: '검증', schema: VERDICT_SCHEMA })
    .then(v => ({ ...f, verdict: v }))
)

return { confirmed: verified.filter(f => f.verdict.isReal) }

세 관점은 parallel로 동시에 돌고, 각 관점에서 나온 발견은 끝나는 즉시 pipeline을 통해 검증 단계로 넘어갔습니다. 정합성 리뷰가 먼저 끝나면 그 발견들은 성능·재사용성 리뷰가 아직 돌고 있는 동안에도 검증이 시작됐습니다. 실행 중에는 /workflows 화면에서 각 단계가 몇 개 에이전트를 썼는지, 토큰을 얼마나 썼는지 실시간으로 볼 수 있었습니다.

결과와 얻은 팁

  • 세 관점 리뷰에서 총 7개 지적이 나왔는데, 검증 단계를 거치고 나니 실제로 재현 경로가 있는 건 3개였습니다. 나머지 4개 중 2개는 이미 상위 호출부에서 널 체크가 끝난 뒤라 도달 불가능한 경로였고, 2개는 영향받는 코드량에 비해 지적 자체가 과장돼 있었습니다.
  • parallel과 pipeline을 같이 쓰면 "다 끝나고 나서 검증 시작"이 아니라 "끝난 것부터 검증 시작"이 됐습니다. 관점 하나가 유난히 오래 걸릴 때도 전체 실행 시간이 그만큼 늘어지지 않았습니다.
  • Workflow는 기본적으로 사용자가 명시적으로 요청했을 때만 켜지는 도구였습니다. "복잡해 보이니 알아서 여러 에이전트로 처리해줘" 정도로는 트리거되지 않았고, 매번 서브에이전트를 몇 개까지 쓸지 가늠하기 전에 먼저 작은 범위로 한 번 돌려보고 결과를 봤습니다.
  • 세션이 끝나도 실행 결과(어떤 스크립트를 썼는지, 각 단계가 뭘 반환했는지)는 run ID로 남아서, 똑같은 리뷰를 다시 돌릴 필요 없이 바뀐 부분만 다시 실행할 수 있다고 안내받았습니다. 이번엔 diff가 작아서 재실행까지는 안 갔지만, 파일 수가 많은 마이그레이션이었다면 이 캐싱이 더 크게 느껴졌을 것 같습니다.