마지막 레슨입니다. 지금까지 배운 다섯 부품을 하나의 실전 시나리오로 엮어 보겠습니다. 무대는 이렇습니다. 당신은 '한국 소상공인용 정산 대시보드'를 혼자 운영하는 1인 개발자이고, 클라이언트가 방금 개선 요청 10건을 보내왔습니다. 예전 같으면 반나절이 걸릴 일을, 파이프라인으로 30분에 끝내는 과정을 따라갑니다.
8단계 풀 파이프라인
1인 개발자 풀 파이프라인 — 피드백 10건을 30분에
- ① 음성으로 피드백 전달 받아쓰기로 클라이언트 요청 10건을 그대로 클로드에 쏟아냄
- ② 플랜 모드 설계 10건을 파일·작업 단위로 쪼갠 구현 계획 수립
- ③ 교차 모델 플랜 리뷰 커스텀 MCP로 다른 모델에게 리스크·누락 검토
- ④ 서브에이전트 병렬 구현 FE·BE·테스트 담당을 나눠 동시에 진행
- ⑤ 완료 시 훅 알림 구현이 끝나면 소리·Slack으로 통지
- ⑥ 코드리뷰 플러그인 여러 리뷰 에이전트를 병렬로 돌려 품질 점검
- ⑦ 커스텀 스킬 리포트 변경 내역을 클라이언트용 리포트로 자동 정리
- ⑧ 반나절 → 30분 사람은 판단·검토에만 집중, 나머지는 파이프라인이 처리
다섯 부품이 순서대로 맞물립니다. ②③은 설계, ④⑤는 실행, ⑥⑦은 검증·마무리. 사람은 각 이음매에서 '이대로 가도 되나'만 판단합니다.
직접 따라하기
정산 대시보드 개선 요청 10건 처리하기
- 받아쓰기 도구로 클라이언트 요청 10건을 말로 풀어 클로드에 전달한다. (긴 요구를 타이핑하는 것보다 빠르다)
- plan 모드로 전환해, 10건을 '어느 파일을 어떻게 고칠지' 단위로 쪼갠 구현 계획을 세우게 한다.
- 커스텀 교차리뷰 MCP에 그 플랜을 넘겨, 다른 모델에게 놓친 엣지케이스·의존성·리스크를 지적받고 타당한 것만 반영한다.
- 보강된 플랜을 FE·BE·테스트 세 갈래로 나눠 서브에이전트에 병렬 위임한다. (모델은 Opus 대신 Sonnet 계열로 두어 토큰 절약)
- 구현이 끝나면 Stop·Notification 훅이 소리와 Slack으로 완료를 알린다. 그동안 당신은 다른 일을 봐도 된다.
- 코드리뷰 플러그인으로 여러 리뷰 에이전트(버그·보안·타입 등)를 병렬로 돌려 변경분을 점검하고, 지적된 것을 수정한다.
- '클라이언트 리포트 생성' 커스텀 스킬을 불러, 무엇을 왜 바꿨는지 클라이언트가 읽기 좋은 한 장으로 정리시킨다.
- 리포트와 변경 요약을 당신이 최종 검토한 뒤 클라이언트에게 전달하고, 배포한다.
여기서 각 부품이 어디에 쓰였는지 되짚어 보세요. 스킬(⑦ 리포트 생성), 서브에이전트(④ 병렬 구현), 에이전트 팀/플러그인(⑥ 병렬 리뷰), 훅(⑤ 완료 알림), 커스텀 MCP(③ 교차 리뷰). 다섯 부품이 따로 노는 기능이 아니라, 하나의 작업 흐름 안에서 각자의 자리를 갖는다는 것이 이 과정의 결론입니다.
| 단계 | 쓰인 부품 | 사람이 하는 판단 |
|---|---|---|
| ② 플랜 | plan 모드 | 쪼갠 단위가 맞는가 |
| ③ 교차리뷰 | 커스텀 MCP | 지적을 받아들일까 |
| ④ 구현 | 서브에이전트 | 역할 분담이 독립적인가 |
| ⑥ 리뷰 | 코드리뷰 플러그인 | 지적된 이슈가 진짜인가 |
| ⑦ 리포트 | 커스텀 스킬 | 클라이언트에게 이대로 보낼까 |
처음부터 8단계를 다 갖추려 하지 마세요. 오늘은 ②플랜과 ④병렬 구현만으로 시작하고, 다음 주에 ⑤완료 알림 훅을 붙이고, 그다음에 ⑦리포트 스킬을 더하는 식으로 파이프라인을 키우세요. 각 부품은 독립적으로도 가치가 있어서, 하나씩 붙일 때마다 곧바로 시간이 절약됩니다.
파이프라인이 화려해도, 각 단계의 검증은 끝까지 사람의 몫입니다. 교차리뷰가 통과했다고, 리뷰 플러그인이 '이상 없음'이라고 해서 그대로 배포하지 마세요. 표에서 보듯 모든 이음매에는 사람의 판단이 한 번씩 들어갑니다. 자동화는 당신의 손을 자유롭게 할 뿐, 책임까지 가져가지는 않습니다.
축하합니다. 여기까지 왔다면, 당신은 더 이상 코드를 한 줄씩 타이핑하는 사람이 아닙니다. 반복되는 지식을 스킬로 굳히고, 일을 서브에이전트와 팀에 나누고, 검증을 훅과 교차 모델로 자동화하며, 그 모두를 하나의 파이프라인으로 지휘하는 사람 — 에이전틱 엔지니어입니다. 이제 당신의 상한선은 타이핑 속도가 아니라, 얼마나 좋은 시스템을 설계하고 그 결과를 현명하게 판단하느냐에 달려 있습니다.