자동화 파이프라인 설계

01절이 "에이전트를 어떻게 깨우는가"였다면, 02절은 "여러 단계로 이루어진 파이프라인을 왜 그렇게 구성해야 정답인가"를 다룬다. CCA-F 시험은 YAML 문법을 외웠는지가 아니라, 멱등성·비용·실패 처리·게이팅 같은 운영 제약 아래에서 단계 구성을 정당화할 수 있는지를 묻는다.

파이프라인 패턴 세 갈래

자동화 파이프라인은 트리거 성격에 따라 세 패턴으로 나뉜다. 첫째, 이벤트 기반 리뷰다. pull_request의 opened·synchronize에 반응해 PR이 갱신될 때마다 리뷰를 돈다. 둘째, 멘션 기반 수정이다. 사람이 이슈나 PR에 @claude 이 버그 고쳐줘처럼 요청하면 에이전트가 수정안을 만들고 브랜치에 푸시한다. 셋째, 예약 작업이다. schedule 트리거로 정해진 주기마다 의존성 점검, 보안 스캔, 문서 동기화를 자동 수행한다.

시험은 요구사항을 주고 "어떤 트리거가 정답인가"를 묻는다. "모든 PR을 사람 개입 없이 리뷰"는 이벤트 기반 agent 모드, "개발자가 원할 때만 도움"은 멘션 기반 tag 모드, "매일 새벽 의존성 확인"은 schedule이다. 트리거를 잘못 고르면 비용이 폭증하거나(모든 푸시마다 도는데 멘션 기반이라 영영 안 도는) 의도와 어긋난다.

멱등성: 같은 트리거가 여러 번 울려도 안전한가

synchronize 이벤트는 PR에 커밋이 추가될 때마다 발생한다. 리뷰 워크플로우가 매번 새 코멘트를 누적하면 PR이 중복 코멘트로 도배된다. 멱등성 있는 설계는 "이전 리뷰 코멘트를 갱신하거나, 변경된 부분만 다시 보거나, 중복을 억제"한다. 시험에서 "리뷰 봇이 같은 지적을 반복해서 단다, 무엇이 문제인가"를 물으면 멱등성 부재가 정답이다. 에이전트가 동작을 푸시하는 경우(수정안 커밋)도 같은 문제가 있다. 같은 트리거가 두 번 울려 두 개의 거의 같은 커밋을 만들면 안 되므로, 작업 전 기존 브랜치·PR 존재 여부를 확인하도록 프롬프트를 설계한다.

비용과 동시성 제어

CI에서 도는 에이전트는 호출마다 토큰 비용과 러너 시간이 든다. 비용 폭주를 막는 설계 레버가 몇 가지 있다. paths 필터로 관련 파일이 바뀐 PR에서만 돌리고, concurrency 그룹으로 같은 PR에 대해 이전 실행을 취소해 중복 실행을 막으며, agent 모드의 prompt를 좁혀 에이전트가 불필요하게 탐색하지 않게 한다. 아래 워크플로우는 API 코드가 바뀐 PR에서만 문서를 갱신하고, 같은 PR의 이전 실행은 취소한다.

# .github/workflows/claude-api-docs.ymlname: Claude API Docs Updateon:  pull_request:    paths:      - "src/api/**/*.ts"concurrency:  group: claude-docs-${{ github.event.pull_request.number }}  cancel-in-progress: truejobs:  update-docs:    runs-on: ubuntu-latest    permissions:      contents: write      pull-requests: write      id-token: write    steps:      - uses: actions/checkout@v6        with:          fetch-depth: 1      - uses: anthropics/claude-code-action@v1        with:          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}          prompt: |            이 PR에서 바뀐 API 엔드포인트에 맞춰 README.md의 문서를 갱신하라.

시험은 "리뷰 봇 때문에 비용이 너무 많이 나온다, 어떻게 줄이나"를 묻는다. 정답 후보는 paths 필터, concurrency 취소, 트리거 범위 축소, 더 좁은 프롬프트다. 모델을 바꿔 비용을 줄인다는 선택지가 있다면, 그것은 일반적으로 사용자(조직)의 결정이지 자동으로 다운그레이드할 일이 아니라는 점을 기억한다.

실패 처리와 게이팅

자동화 파이프라인은 에이전트의 출력을 무조건 신뢰하면 안 된다. 에이전트가 만든 수정안은 사람 리뷰나 테스트 게이트를 통과해야 머지되도록 설계한다. 즉 에이전트는 PR을 "여는" 데까지만 하고, 실제 머지는 기존 CI(테스트·린트)와 사람 승인 뒤에 일어나게 한다. 이것이 "오류를 잡고 복구할 수 있는가"라는 에이전트 도입 판단 기준과 직결된다. 자동 머지까지 에이전트에 맡기는 설계는 되돌리기 어려운 작업을 게이트 없이 수행하는 안티패턴이다.

실패 처리도 명시해야 한다. 에이전트 호출이 실패하거나 모델이 거부(refusal)했을 때 워크플로우가 조용히 성공으로 끝나면 안 된다. 또한 에이전트가 CI 실패 원인을 분석하게 하려면 워크플로우 로그를 읽을 수 있어야 하므로 permissions에 actions: read를 부여한다(01절의 권한 최소화 원칙과 일관되게, 필요한 만큼만).

Claude Code 액션이 정답인 경우 vs API/Managed Agents가 정답인 경우

마지막으로 도구 선택이다. 시험은 "이 자동화에 무엇을 써야 하는가"를 묻는다. 판단 기준은 다음과 같다.

GitHub 저장소 컨텍스트에서 PR·이슈에 반응하고, 파일을 읽고 고치고 코멘트·브랜치를 푸시하는 깃 워크플로우 자동화라면 claude-code-action이 정답이다. GitHub App·트리거·러너 통합이 이미 다 갖춰져 있기 때문이다. 반면 GitHub와 무관하게 코드 안에서 단발성 LLM 호출(분류·요약·추출)을 넣거나, 자체 오케스트레이션 루프를 직접 제어해야 한다면 Anthropic API + 도구 사용이 정답이다. Anthropic이 에이전트 루프를 돌리고 세션별 컨테이너를 호스팅하길 원하는 서버 관리형 상태 에이전트가 필요하면 Managed Agents가 정답이다.

요약하면, "GitHub 이벤트에 묶인 깃 자동화"는 액션, "코드 안의 단발 호출이나 커스텀 루프"는 API, "Anthropic이 루프와 샌드박스를 운영하는 장기 에이전트"는 Managed Agents다. 액션을 써야 할 자리에 API를 직접 호출하는 워크플로우를 짜는 것은 이미 만들어진 통합을 재구현하는 낭비이며, 시험에서 자주 오답 선택지로 등장한다.

정리

• 파이프라인 패턴은 이벤트 기반 리뷰(agent 모드) · 멘션 기반 수정(tag 모드) · 예약 작업(schedule) 세 갈래이며, 요구사항이 트리거 선택을 정한다.
• synchronize처럼 반복되는 트리거에는 멱등성 설계가 필수다. 중복 코멘트·중복 커밋을 막도록 갱신·중복 억제·기존 산출물 확인을 넣는다.
• 비용은 paths 필터, concurrency 취소, 좁은 프롬프트로 제어한다. 모델 다운그레이드는 자동으로 결정할 일이 아니다.
• 에이전트 출력은 테스트·사람 승인 게이트를 통과한 뒤 머지되게 설계한다. 자동 머지까지 맡기는 것은 되돌리기 어려운 작업을 게이트 없이 수행하는 안티패턴이다.
• 도구 선택의 정답은 "GitHub 깃 자동화는 액션, 코드 내 단발 호출·커스텀 루프는 API, 관리형 장기 에이전트는 Managed Agents"다.