포스트

[Antigravity #8] 반복 업무 자동화: '딸깍' 한 번으로 퇴근하기 (Workflows)

[Antigravity #8] 반복 업무 자동화: '딸깍' 한 번으로 퇴근하기 (Workflows)

Antigravity Workflows

Editor’s Note
매일 아침 출근해서 하는 일: git pull 받고, npm install 하고, 서버 켜고…
배포할 때 하는 일: 빌드하고, 테스트 돌리고, 버전 올리고…
이 지겨운 반복 업무, Workflows로 매크로를 만들어버립시다. “김 대리, 배포해” 한마디면 끝납니다.


1. Workflows가 뭔가요?

게임의 ‘매크로’나 엑셀의 ‘함수’라고 생각하면 됩니다. 여러 단계의 복잡한 작업을 하나의 명령어로 묶어두는 기능입니다.

다만 Workflows를 단순 자동 실행 버튼으로만 보면 아깝습니다. 좋은 워크플로우는 반복 명령을 묶는 동시에, 작업 순서와 중단 조건을 문서화합니다.

예를 들어 배포 전 확인은 “포맷 -> 린트 -> 테스트 -> 빌드 -> 결과 보고”처럼 순서가 중요합니다. 중간에 실패했는데 다음 단계로 넘어가면 더 큰 문제가 생길 수 있죠. Workflow에는 바로 이런 안전장치를 넣어야 합니다.


2. 실습: “배포 준비(Pre-deploy)” 자동화

배포하기 전에 꼭 확인해야 할 것들이 있죠?

  1. 코드 포맷팅 (prettier)
  2. 린트 검사 (eslint)
  3. 테스트 통과 (test)

이걸 하나씩 치기 귀찮으니까, /deploy라는 명령어를 만들어봅시다.

.antigravity/workflows.yaml 작성

아래 예시는 개념을 설명하기 위한 형태입니다. 실제 파일명이나 설정 방식은 사용하는 Antigravity 버전의 Workflow 설정 화면과 문서를 기준으로 맞추세요.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
name: 배포 준비 (Safe Deploy)
command: /deploy # 내가 채팅창에 칠 명령어

steps:
  - name: 1. 코드 예쁘게 정리하기
    run: npm run format

  - name: 2. 문법 검사하기
    run: npm run lint

  - name: 3. 최종 테스트
    run: npm test

  - name: 4. 보고하기
    action: report
    message: "모든 검사가 통과되었습니다! 배포해도 안전합니다. 🚀"

3. 사용법: 그냥 치세요

이제 매니저 뷰 채팅창에 이렇게만 치면 됩니다.

1
/deploy

그러면 Antigravity가 알아서 1번부터 4번까지 순서대로 촥촥촥 실행합니다. 만약 중간에 테스트가 실패하면? “3번 단계에서 에러가 났습니다! 작업을 중단합니다.” 라고 멈춥니다. 실수로 에러 있는 코드를 배포할 일이 사라지는 거죠.

여기서 핵심은 실패를 숨기지 않는 것입니다. 자동화는 성공했을 때보다 실패했을 때 더 중요합니다.

실패 리포트에는 최소한 아래 정보가 있어야 합니다.

  • 실패한 단계 이름
  • 실행한 명령어
  • 핵심 에러 메시지
  • 다음에 사람이 확인해야 할 파일이나 로그

이 정보가 없으면 자동화가 아니라 “어딘가에서 뭔가 실패했다”는 알림만 받게 됩니다.


4. 응용: “오늘의 요약(Daily Briefing)”

밤새 우리 팀원이 뭘 고쳤는지 궁금한가요? 출근하자마자 알람처럼 받아보세요.

1
2
3
4
5
6
7
8
name: 아침 브리핑
command: /morning

steps:
  - name: 변경사항 확인
    run: git pull && git log --since="yesterday" --oneline
  - name: 요약하기
    prompt: "위의  로그를 보고, 어제 우리 팀이 무슨 작업을 했는지 3줄 요약해줘."

이제 출근해서 /morning만 치고 커피 한 잔 가져오면, AI가 브리핑 준비를 끝내놓습니다.

이 워크플로우는 편하지만, 실제 팀 저장소에서는 git pull처럼 작업 트리를 바꾸는 명령을 자동 실행할 때 조심해야 합니다. 커밋하지 않은 변경이 있는 상태에서 실행하면 충돌이 날 수 있기 때문입니다.

더 안전한 버전은 먼저 상태를 확인하는 단계부터 시작합니다.

1
2
3
4
5
6
7
8
9
10
name: 안전한 아침 브리핑
command: /morning-safe

steps:
  - name: 작업 트리 확인
    run: git status --short
  - name: 최근 변경 확인
    run: git log --since="yesterday" --oneline
  - name: 요약하기
    prompt: "최근 커밋을 보고 어제 작업 내용을 3줄로 요약해줘. 작업 트리에 변경이 있으면 먼저 알려줘."

자동화가 저장소 상태를 바꾸기 전에 현재 상태를 보여주게 만들면, 예기치 않은 충돌을 줄일 수 있습니다.


5. Workflow로 만들면 좋은 작업

처음부터 모든 것을 자동화하려고 하지 말고, 자주 반복하면서도 성공 기준이 명확한 작업부터 시작하세요.

작업 좋은 이유
PR 전 점검 format, lint, test, build 순서가 고정됨
릴리스 노트 초안 최근 커밋과 PR 목록을 요약하기 쉬움
E2E 스모크 테스트 주요 화면 확인 기준이 명확함
의존성 점검 오래된 패키지와 보안 알림을 정리하기 좋음

반대로 결제 승인, 운영 DB 변경, 사용자 데이터 삭제처럼 되돌리기 어려운 작업은 완전 자동화보다 사람 승인 단계를 남겨두는 편이 안전합니다.


6. 오늘의 요약

  1. 맨날 하는 반복 작업은 .antigravity/workflows.yaml에 정의한다.
  2. 성공 경로뿐 아니라 실패했을 때의 보고 방식까지 설계한다.
  3. 저장소나 운영 환경을 바꾸는 작업은 사람 승인 단계를 남긴다.

이제 개인 작업 효율은 끝판왕을 찍었습니다. 하지만 우리에겐 ‘동료’들이 있죠? 다음 편 [Antigravity #9] 에서는 AI 에이전트들을 여러 명 고용해서 “나만의 AI 개발팀”을 꾸리는 고급 기술을 다룹니다.

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.