팀 8명이 매일 쓰는 워크플로우 자동화

← cd ..

배경

태스크 하나 처리하려면 Asana, GitLab, Slack을 오가며 50~65분을 써야 했습니다. 팀 테크토크에서 Asana MCP 자동화 이야기를 듣고 '개발 작업 자체를 자동화하자’고 시작했지만, 태스크 정보 부족과 기획서 권한 문제에 막혀 방향을 바꿨습니다.

결국 개발보다 반복되는 비개발 워크플로우가 더 큰 병목이었습니다. Asana, GitLab, Slack API를 Claude가 직접 호출하는 방식으로 풀기로 했습니다.

해결 방법

워크샵 전날 밤에 시작해서 당일 4시간 만에 v1을 돌릴 수 있었습니다. Claude Code Custom Command(.md)로 각 커맨드 스펙을 정의하고, Asana/GitLab/Slack API를 curl로 직접 호출해 MCP 서버 의존도를 최소화했습니다.

V1 — 기본 워크플로우 자동화 (2026.02.12)

4개의 커맨드로 Asana → GitLab → Slack을 하나의 플로우로 연결했습니다.

/init: 최초 환경 설정 — Asana/GitLab/Slack 토큰 등록, 설정 파일 생성
/my: 내 Asana 미완료 태스크 목록 조회 (마감일순 정렬)
/setup-asana: 태스크 프로젝트/태그 자동 추가 + GitLab 이슈 확인 + 브랜치 생성
/done: 커밋/푸시 → MR 생성 → 코드리뷰 요청 → 배포 → QA 코멘트 → QA 요청 → 머지 요청까지

V2 — 멀티레포 & 병렬 작업 지원 (2026.02.20)

팀원들이 실제로 쓰면서 나온 피드백을 반영해 병렬 작업과 배포 자동화를 추가했습니다.

Git Worktree 기반 병렬 작업: 태스크별 독립 워크트리로 여러 태스크 동시 작업, 브랜치 전환 불필요
ArgoCD 배포 전처리 자동화: 통합 브랜치 수동 생성 없이 CI 빌드 → Slack ArgoCD 리로드 요청까지 자동화
/merge 분리: QA 결과 대기를 별도 커맨드로 분리하여 /done 후 바로 다음 태스크 착수 가능
API/CMS 이슈 자동 생성: 수동 이슈 생성 → 자동 이슈 생성 + 브랜치 생성

V3 — AI 리뷰 자동 처리 / 스마트 태스크 관리

AI Review Bot 자동 처리: 파이프라인 완료 후 AI 리뷰 봇 코멘트 감지 → 자동 분석 → 코드 수정 → 커밋/푸시
/done 재실행 감지: QA 피드백 반영 후 재배포 시 이미 완료된 단계 자동 스킵 → 재배포 시간 단축
스마트 태스크 상태 추적: 6단계 상태 자동 판별 — 미시작 → 셋업/개발 → 리뷰 → QA → 머지요청 → 머지완료
공통 규칙 (common.md): lint 체크 필수, import 정리, 진행 상태 바 표시 등 모든 커맨드 공유 규칙

V3.1 — 코드분석 · 개발 자동화 커맨드 업데이트

기존 워크플로우(/setup-asana → /done → /merge)에 분석과 개발 단계를 추가하여 세분화했습니다.

v3.0: /setup-asana → /done → /merge
v3.1: /setup-asana → /analyze → /build → /done → /merge

신규 커맨드: `/analyze`, `/build`

/analyze — 태스크 분석 + 작업 계획 수립. /setup-asana 이후 코드 작성 전에 실행합니다.
- Asana 태스크의 모든 정보(본문, 댓글, 하위태스크, 첨부파일) 수집
- 외부 링크(기획서, 디자인 등) 자동 확인
- 코드베이스 분석(관련 컴포넌트, API, 라우팅 등)
- 구체적인 작업 계획을 .claude/analyze-plans/{GID}.md에 저장
- 7단계 절차: 태스크 심층 분석 → 외부 링크 확인 → 정보 보완 → 코드베이스 분석 → 작업 계획 수립 → 사용자 컨펌 → 계획 저장
/build — 작업 실행 + 셀프 코드리뷰. /analyze에서 승인된 작업 계획을 기반으로 코드를 구현합니다.
- 계획 파일(.claude/analyze-plans/{GID}.md) 기반 자동 코드 구현
- 구현 완료 후 11단계 셀프 코드리뷰 자동 수행
- 5단계 절차: 계획 로드 → 작업 실행 → 셀프 코드리뷰 → 리뷰 결과 보고 → 완료

로컬 태스크 상태 저장 + `/my` 즉시 조회

기존에는 /my로 태스크 상태를 확인할 때 Asana, GitLab, Slack API를 매번 호출하여 느리고 불필요한 API 호출이 발생했습니다. 이를 각 커맨드 실행 시마다 로컬 파일(.claude/task-state/{GID}.json)에 상태를 저장하고, /my 조회 시 이 파일을 우선 읽어 즉시 응답하도록 개선했습니다.

8단계 상태 흐름: 셋업완료 → 분석중 → 분석완료 → 개발중 → 개발완료 → 코드리뷰 진행중 → QA 진행중 → 머지요청 완료
/my 목록 테이블에 상태 컬럼 추가 — 목록 조회만으로 각 태스크의 진행 상태를 즉시 확인 가능
진행 중인 커맨드가 있으면 단계 정보도 함께 표시 (예: 🔴 코드리뷰 진행중 — /done [4/12] AI 리뷰 검토)

상태바 세션 격리

기존 CWD(작업 디렉토리) 해시 기반 세션 식별은 같은 디렉토리에서 여러 터미널을 열면 상태가 섞이는 문제가 있었습니다. Claude Code 프로세스 PID 기반으로 세션을 격리하여, 각 터미널이 고유한 상태를 갖도록 해결했습니다. statusLine 설정은 프로젝트 레벨(.claude/settings.local.json)에 자동 적용됩니다.

작업 이력 기반 학습

각 커맨드(/analyze, /build, /done)가 종료될 때 작업 이력을 .claude/work-history/ 디렉토리에 저장합니다. 다음 작업 시 과거 이력을 참고하여 더 정확한 분석과 구현이 가능합니다.

이력 파일: .claude/work-history/{TASK_GID}-{커맨드}.md
인덱스 파일: .claude/work-history/index.json (태그별 빠른 검색)

Auto 모드 — 커맨드 자동 체이닝

커맨드 실행 시 auto 키워드를 붙이면, 완료 후 다음 커맨드를 자동으로 이어서 실행합니다.

/setup-asana 1234567890 auto  → setup → analyze → build → done
/analyze 1234567890 auto      → analyze → build → done
/build 1234567890 auto        → build → done

/merge는 QA 완료 후 사용자가 직접 실행하므로 Auto 체인에 포함되지 않습니다
각 커맨드 내부의 사용자 확인 단계(예: /analyze 계획 컨펌)는 그대로 유지됩니다. 자동화되는 것은 커맨드 간 전환뿐입니다

`/board` — 실시간 칸반 보드

로컬 태스크 상태와 Asana 백로그를 기반으로 실시간 칸반 보드를 브라우저에서 제공합니다.

Python3 로컬 서버 (포트 8787) — /board 실행 시 자동 시작
SSE(Server-Sent Events) — 파일 변경 감지 시에만 브라우저에 push (불필요한 폴링 없음)
7개 컬럼: 작업전 → 셋업완료 → 분석 → 개발 → 코드리뷰 → QA → 머지요청 완료
Asana 백로그 자동 감지: Asana에만 있고 로컬 상태 파일이 없는 태스크를 “작업전” 컬럼에 표시
완료 태스크 자동 정리: Asana에서 태스크를 완료 처리하면 다음 /board 실행 시 보드에서 제거

효과

단계	Before	After	절감
/my	5분	30초	~4.5분
/setup-asana	10~15분	2~3분	~10분
/done	30~40분	5~10분	~28분
/merge	5분	1~2분	~3.5분
합계	50~65분	9~16분	~80% 절감

한 사람이 주 3태스크를 처리하면 매주 2.3시간이 절약됩니다
8명이 한 달 쓰면 72시간, 일 년이면 864시간이 돌아옵니다

앞으로의 계획

ArgoCD API 직접 연동: Slack 리로드 요청 방식 → ArgoCD API 직접 호출로 전환, 배포 자동화 완성도 향상
타팀 확장 적용: 커맨드 스펙(.md)만 조정하면 동일한 자동화 구조를 타팀 프로세스에도 적용 가능

핵심 구조(Asana → GitLab → Slack)는 대부분의 개발팀이 이미 쓰고 있어, 커맨드 스펙만 맞추면 바로 적용할 수 있습니다.

눈여겨볼 점

4시간 만에 v1을 만들고 v3까지 진화시킨 속도가 돋보입니다. 아이디어에 머무르지 않고 팀원 8명이 매일 쓰는 도구로 발전시켰습니다. MCP의 assignee 필터 문제를 발견하자마자 curl 직접 호출로 전환한 판단도 현장에서 바로 써먹을 수 있는 접근입니다.
Git Worktree로 병렬 작업을 지원한 것이 실무 개발자의 급소를 짚었습니다. 태스크별 독립 워크트리로 브랜치 전환 없이 여러 작업을 동시에 돌릴 수 있게 한 것은, 단순 자동화를 넘어 개발자 경험까지 고려한 설계입니다.
태스크당 50분이 9분으로 줄었다는 수치를 커맨드별로 실측한 점이 신뢰를 줍니다. /my, /setup-asana, /done, /merge 각각의 Before/After가 있어 어디서 시간이 빠졌는지 명확합니다. 8명이 일 년 쓰면 864시간 — 이 숫자는 결과가 아니라 출발점입니다.

배경