라이브 사이트를 프로덕션 컴포넌트로 복제하는 다중 에이전트 파이프라인

수동으로 페이지 섹션을 재구축하는 것은 DOM을 검사하고, 디자인 토큰(design tokens)을 복사하며, 호버 상태(hover states)를 추적하고, 반응형 브레이크포인트(responsive breakpoints)를 수정하는 것을 의미합니다. 이는 느리고 대부분 기계적인 작업입니다. 저는 이러한 기계적인 부분을 처리하고 검토는 인간에게 남기는 Claude Code 서브에이전트 파이프라인을 구축했습니다.

클론 실행 흐름

섹션은 엄격하게 한 번에 하나씩 실행되므로, 각 에이전트는 작고 깨끗한 컨텍스트를 유지합니다.

ONCE PER PAGE
      Input  (Live URL or Figma frames)
  ──▶ Phase 0 · Discover  (Scroll, find sections, capture 4 breakpoints)
...

에이전트를 분리하는 이유

• 각 단계는 하나의 작업과 하나의 출력 파일(sections.json, harvest.json, 생성된 위젯)을 가집니다. 실패한 단계는 다른 단계를 다시 수행할 필요 없이 재실행할 수 있습니다.
• 메인 세션이 중첩된 오케스트레이터 에이전트 대신 오케스트레이션(orchestration)을 담당합니다. 이는 컨텍스트를 절약해주며, 저는 단계 사이에 개입할 수 있게 해줍니다.
• Figma 브랜치는 디스커버리(discovery) 및 하베스트(harvest) 에이전트만 대체합니다. 동일한 파일을 방출하므로 UI 에이전트는 손대지 않고 재사용됩니다.

신뢰성을 유지하는 요소들

• 하드 빌드 게이트(hard build gate): 프로젝트가 빌드될 때만 섹션이 완료된 것으로 간주됩니다. 오류는 최대 세 번의 재시도(retries)를 위해 에이전트로 되돌아갑니다.
• 파이프라인에 작성된 가드레일(guardrails): 공유 디렉토리는 접근 금지이며, 보호 파일은 원본을 삭제하는 것이 아니라 주석 처리(commenting out)함으로써만 변경될 수 있습니다.
• 학습 루프(learning loop). 모든 실행의 노트와 실패 사항은 다음 실행이 읽는 규칙으로 정제되어 동일한 실수가 반복되지 않도록 합니다.

결과적으로: 예전에는 며칠 걸리던 새로운 섹션들이 이제 몇 시간밖에 걸리지 않으며, 그 시간의 대부분은 픽셀을 조정하는 것(pixel-pushing)이 아니라 인간의 검토에 할애됩니다.

원래는 내 포트폴리오에 게시되었습니다.