# AI 워크플로우 업데이트

[지난 글](https://kdy1.dev/2026-9-6-humans-are-always-the-bottleneck)에서는 Labor0와 Codex로 수십 개의 작업을 병렬로 처리하는 워크플로우를 소개했다. 그 이후로도 내 개발 방식은 계속 바뀌었다. 지금은 Labor0를 쓰지 않고, 공개해 둔 스킬들을 활용하고 있다.

이번에 해결한 문제는 PR을 많이 만든 다음에 생기는 병목이다. PR을 만드는 것까지는 쉬운데, 그걸 전부 머지하는 데 시간이 너무 오래 걸렸다.

## 이슈 트래커를 프롬프트 저장소로 쓰기

나는 구체적인 이슈를 남기기 위해 항상 `$add-issue` 스킬을 사용한다. 이슈 트래커를 일종의 프롬프트 저장소처럼 쓰는 셈이다.

발상은 단순하다. 구체적인 이슈들을 미리 만들어 두면, 그것들을 병렬로 처리하는 건 쉽다. 무엇을 해야 하는지가 이슈에 들어 있으니, 나중에는 처리할 이슈들을 지정해서 실행하면 된다.

그런데 작업을 엄청나게 많이 처리하다 보니 다른 문제가 생겼다. PR이 30개쯤 쌓이면 머지 충돌이 계속 발생했다. 충돌을 해결하고 리베이스하는 데 너무 오래 걸렸다.

Labor0는 의존성 분석으로 이 문제를 해결해 줬지만, 나는 더 이상 Labor0를 쓰지 않는다. 처음에는 Codex에서 세션을 병렬로 만들어 해결하려고 했다. 하지만 그렇게 만들어진 PR들을 모두 머지하는 일은 여전히 오래 걸렸다.

최근에는 Stacked PR이 더 낫다는 걸 깨달았고, 이 방식을 스킬로 만들어 쓰고 있다.

## 이슈 수십 개를 Stacked PR로 만들기

지금은 스킬로 이슈 수십 개를 만들어 둔 뒤, 라벨 등으로 대상을 지정해서 `$slop-fix-batch`를 한 번 실행한다. 그러면 스킬이 이슈들을 처리하고 Stacked PR을 만들어 준다.

오픈소스 저장소인 [delinoio/oss](https://github.com/delinoio/oss)에서는 이런 식으로 호출한다.

```text
$slop-fix-batch sort:updated-desc is:issue state:open label:slop-batch author:kdy1
```

스킬이 PR을 만들었다고 바로 끝나는 것은 아니다. 리뷰를 반영하고 CI 실패를 고치는 과정은 필요하다. CI를 수정할 때는 이렇게 지시했다.

> CI 실패 전부 다 고쳐줘

[PR #1726이 포함된 Stack](https://github.com/delinoio/oss/pull/1726)이 실제 사례다. 이 Stack에는 PR 11개가 들어 있었다. 리뷰 반영과 CI 수정을 몇 차례 거친 뒤, Stack 안의 PR을 전부 한 번에 머지했다.

수정 없이 한 번에 끝났다는 뜻은 아니다. 준비가 끝난 PR들을 하나씩 머지하면서 충돌을 계속 해결해야 했던 문제가 해결됐다는 뜻이다. 예전 방식으로 이 정도 PR을 모두 처리하려면 머지 충돌을 고치는 데 한참 걸렸다.

이번 Stack에서 처리한 작업은 다음과 같다.

| PR | 작업 | 이슈 |
| --- | --- | --- |
| [#1716](https://github.com/delinoio/oss/pull/1716) | Usage 필터 자동 적용 | [#1698](https://github.com/delinoio/oss/issues/1698) |
| [#1717](https://github.com/delinoio/oss/pull/1717) | 전역 검색 단축키 제거 | [#1697](https://github.com/delinoio/oss/issues/1697) |
| [#1718](https://github.com/delinoio/oss/pull/1718) | 키보드 도움말에서 단축키 실행 | [#1696](https://github.com/delinoio/oss/issues/1696) |
| [#1719](https://github.com/delinoio/oss/pull/1719) | 워크플로우 간 Runner 선택 기억 | [#1695](https://github.com/delinoio/oss/issues/1695) |
| [#1720](https://github.com/delinoio/oss/pull/1720) | 구독 아이콘과 저장된 사용 한도 표시 | [#1694](https://github.com/delinoio/oss/issues/1694) |
| [#1721](https://github.com/delinoio/oss/pull/1721) | Usage 상세 정보를 탭으로 구성 | [#1693](https://github.com/delinoio/oss/issues/1693) |
| [#1722](https://github.com/delinoio/oss/pull/1722) | 세션 목록에 상태 표시와 작업 메뉴 추가 | [#1692](https://github.com/delinoio/oss/issues/1692) |
| [#1723](https://github.com/delinoio/oss/pull/1723) | Server 설정 안에 Network 설정 배치 | [#1691](https://github.com/delinoio/oss/issues/1691) |
| [#1724](https://github.com/delinoio/oss/pull/1724) | 시작 시 프로세스 인덱스 생성 조건 수정 | [#1690](https://github.com/delinoio/oss/issues/1690) |
| [#1725](https://github.com/delinoio/oss/pull/1725) | Account storage 표시 제거 | [#1689](https://github.com/delinoio/oss/issues/1689) |
| [#1726](https://github.com/delinoio/oss/pull/1726) | 실패 원인과 복구 방법을 해당 화면에 표시 | [#1699](https://github.com/delinoio/oss/issues/1699) |

## 배치는 자기 전에

배치를 언제 시작할지는 적당히 상황을 보고 정한다. 써 보니 자러 가기 전에 돌리는 게 가장 좋았다.

`$slop-fix-batch`는 서브에이전트를 활용해서 여러 이슈를 병렬로 고친다. 그만큼 작업 기기의 CPU와 메모리를 많이 점유한다. 내가 기기를 쓰지 않는 시간에 돌리는 편이 좋다.

단점도 있다. 이슈를 모아서 배치로 처리하다 보니, 발견하자마자 고쳐지는 방식은 아니다.

그래도 PR을 잔뜩 만든 다음 머지 충돌을 해결하느라 시간을 쓰던 문제는 이 방식으로 해결했다. 내가 사용하는 스킬들은 모두 [kdy1/kdy1-scripts](https://github.com/kdy1/kdy1-scripts)에 공개해 두었다.