subflow 만들기 ③ — 갈라지고, 틀리고, 흐름이 되기까지

subflow 가 주행마다 한 칸씩 갈라진 과정, 틀렸을 때 고치는 방법, 그리고 subflow 를 줄 세워 하나의 흐름(rootflow)으로 조립하는 단계를 정리합니다.

7분 읽기

subflow 만들기 시리즈 ① AI 를 예측 가능하게 만드는 가장 작은 단위 · ② 사고 한 건에서 계약 한 줄까지 · ③ 갈라지고, 틀리고, 흐름이 되기까지 (이 글)

2편에서 subflow 하나가 만들어지는 절차를 봤습니다. 이번 편은 그 뒤의 이야기입니다. subflow 는 한 번 만들고 끝나지 않았습니다. 갈라지고 흡수되고 틀리고 고쳐지면서 하나의 흐름이 됐습니다.

1. 한 칸씩 갈라진다 — 조사 단계의 계보

가장 많이 갈라진 것은 조사 단계(survey)입니다. 처음부터 다섯 축으로 설계한 게 아닙니다. 주행이 «축이 섞였다» 를 보여 줄 때마다 한 칸씩 갈랐습니다.

판 시기 모양 계기
v0 7월 말 단계 하나 골격을 옮겨 올 때부터 있던 «조사» 칸
v1 8월 초 survey 로 이름 붙임, 산출에 «세는 축» 같은 조사를 두 번 했는데 두 번 다 축이 틀렸다. 셋으로 갈라 세야 할 파일 22개를 한 덩어리로 셌다
v2 8월 중순 화면 축 / 도메인 축 + 둘을 잇는 이음새 화면이 쓰는 멤버 50개에서 도메인의 주인을 거꾸로 짐작해 주인을 4건 잘못 붙였다
v3 같은 날 계층을 따라 4축(entry · ui · domain · infra) + 이음새 3 앱 → 기능 모듈 사이 import 493개(73파일)를 보는 축도 가드도 없었다. 기능 → 브리지 사이 38개도 마찬가지였다
v4 다음 날 5번째 축 survey/figma (Figma 작업일 때만) 따로 세웠던 Figma 흐름을 갈래로 흡수했다 (아래 2절)
v5 10월 초 축 산출을 상태 × 이벤트 전이표 하나로 조립 (survey/ledger) 한 화면의 같은 3×7 전이표 세 벌이 «입력 6 · 칸 18» 로 따로 놀며 서로 어긋났다 
v0  [ 조사 ]

v1  [ survey ]

v2  [ ui ] ─ 이음새 ─ [ domain ]

v3  [ entry ] ─J1─ [ ui ] ─J2─ [ domain ] ─J3─ [ infra ]
      app          feature       module        bridge · data

v4  v3 + [ figma ]   (Figma 작업일 때만)

v5  v4 ──→ [ ledger ] ──→ 전이표 하나

규칙은 하나로 정리됐습니다. 축은 접촉한 것만 돌고 이음새 셋은 항상 돈다. 작업이 화면만 건드리면 화면 축만 돌지만 축과 축이 맞물리는 이음새는 매번 확인합니다.

이음새가 왜 따로 있을까요. 두 축이 서로를 전제로 조사하면, 둘 다 틀려도 부딪힐 상대가 없기 때문입니다. 화면 축이 «이걸 요구한다» 고 적고 도메인 축이 «이걸 제공한다» 고 적으면, 이음새가 둘을 1:1 로 맞춰 봅니다. 어긋나면 처음 주장한 축으로 돌려보냅니다.

2. 위에서 만든 흐름은 흡수됐다 — Figma 의 경우

한번은 위에서부터 흐름을 만들어 본 적이 있습니다.

어느 하루에 Figma 화면 작업에서 사고가 4건 났습니다. 하트가 흰색으로 나오고 토스트가 2초 만에 사라지고 간격이 0이 되고 상태 판정을 엉뚱한 기준으로 했습니다. 넷 다 조사 문서에 답이 있었는데 구현이 읽지 않은 것이었습니다.

그래서 Figma 화면 개발용 흐름을 따로, 6단계로 세웠습니다. 그리고 이틀 만에 기존 흐름의 갈래로 흡수했습니다. 새 흐름으로 설 요건을 넘지 못했기 때문입니다.

따로 세웠던 단계 흡수 뒤
Figma 조사 survey/figma (조사의 5번째 축)
디자인 시스템 대조 cds-diff (그대로)
상태 도출 설계 단계 sdd 에 흡수
렌더 계약 · 바인딩 실행 단계 execute 에 흡수
검증 verify

새 흐름이 아니라 같은 흐름에 단계가 더 도는 것이 됐습니다.

몇 주 뒤에는 반대 방향의 판단도 있었습니다. Figma 화면마다 «새로 만들기 / 고치기 / 이미 맞음» 을 가르는 자리가 없어서 사고가 3건 났을 때, 에이전트는 기존 subflow 를 넓히자고 권했고 사용자는 새로 만들자 고 뒤집었습니다(disposition). 이유는 이랬습니다.

한 subflow 에 귀속과 대조, 두 축을 넣으면 통과 체크가 뭉개진다.

넓힐지 새로 만들지는 통과 체크가 하나로 서는가로 정합니다.

3. 표는 언제나 하나씩 뒤처졌다

subflow 가 늘 때마다 세 곳을 같이 고쳐야 합니다. 흐름 문서의 선언, 단계 사이를 잇는 계약 표, 이름을 찾는 키워드 표입니다. 커밋마다 셋을 세어 봤습니다.

시기 선언 계약 표 키워드 표
8월 초 10 10 10
8월 중순 ① 12 10 12
8월 중순 ② 16 16 16
8월 중순 ③ 17 17 16
8월 중순 ④ 18 18 16
8월 중순 ⑤ 20 18 18
8월 말 20 20 20
9월 초 21 21 21
9월 중순 24 24 24
10월 초 25 25 25

subflow 개수 계단 그래프. 선언·계약 표·키워드 표가 8월 초 10개에서 10월 초 25개로 늘었고, 8월 중순에 네 번 표 하나가 선언보다 뒤처졌다

네 번 중 네 번, 표 하나가 뒤처졌습니다. 8월 말에 한 번에 맞췄고 그 뒤로는 사람이 아니라 가드가 «선언 = 계약 표 = 키워드 표» 를 셉니다. 셋이 다르면 검사가 실패합니다.

더 큰 규칙 문서는 실물을 더 늦게 따라왔습니다. 그 문서는 subflow 수를 10 다음에 바로 17로 적었습니다. 12와 16이었던 시절은 한 번도 적히지 않았습니다. 정의는 실물을 뒤따라온다는 것을 숫자가 보여 줬습니다.

4. 틀리면 — 먼저 가르고, 아래에서 위로 고친다

subflow 가 틀렸을 때 바로 규칙을 고치지 않습니다. 먼저 문제가 어디서 왔는지 가릅니다.

원인 뜻 처분
(a) 규칙이 있었는데 안 읽혔다 규칙은 그대로. 집행 수단(가드 · 스킬)을 고친다
(b) 규칙이 잘못 읽히게 쓰여 있다 이것만 규칙 개정 후보
(c) 규칙이 없다 새로 만든다

이 구분이 왜 중요한지는 숫자로 봤습니다. 규칙 문서를 정비하면서 그동안의 결정 기록 93건을 모두 다시 분류했더니 «안 읽혀서» 난 문제 25건 중 14건에서 규칙 문장을 더 써 넣고 있었습니다. 읽히지 않는 문서에 문장을 더한 셈입니다.

이 구분을 세운 뒤에는 규칙 문서를 한 줄도 바꾸지 않고 가드만 늘려서 같은 문제를 처리했습니다. 정비의 발단이 된 말은 이것이었습니다.

헌법들을 정비해줘. 지금 너무 복잡하고, 계속 문제를 일으키고 있어.

고치는 순서는 아래에서 위입니다.

subflow 에서 어긋남 발견
  → 원인 분류 (a) / (b) / (c)
      (a) → 가드 · 스킬을 고친다
      (b)(c) → 계약 행을 고치거나 새로 만든다 + 결정 기록
  → 가드가 센다 (선언 = 계약 표 = 다른 문서의 열거)
  → rootflow 단계 표에 반영
  → Supervisor 는 실물이 생긴 뒤에만

5. 줄 세우면 흐름이 된다 — rootflow 로 조립

계약이 선 subflow 들을 앞의 산출이 뒤의 입력이 되도록 줄 세우면 rootflow, 우리가 비즈니스 플로우라고 부르는 흐름이 됩니다.

# 조립 단계 하는 일
1 줄 세우기 앞 subflow 의 산출이 뒤 subflow 의 입력이 되게 놓는다 (입력 의존표)
2 경계 체크 각 단계가 이전 산출을 빠짐없이 받았는지 확인한다
3 검수 붙이기 계약 단계마다 별도 세션에서 독립 검수
4 루프 닫기 실패는 rework 로 틀린 판정을 만든 단계에, 질문은 resolve 로 규칙에 먼저
5 결정 모으기 결정 대장 한 곳에 모은다
6 사람 게이트 계획의 완료 기준을 사람이 판정한다 — 유일한 정지점
7 실행 작은 단위로 나눠 단계마다 커밋하고 검수
8 검증 · 마감 기계 · 화면 · 로그 → 보고서 → «완료 / 일부 / 중단»

조립하고 나면 안드로이드에서는 이런 흐름이 됩니다.

1 Survey → 2 Architecture → 3 BDD → 4 SDD·API → 5 Plan → 6 DoD 게이트 → ⏸ → 7 Execute → 8 검증

1~5 는 계약을 만드는 단계라 멈추지 않고 이어서 돕니다. 멈추는 곳은 실행 직전 하나입니다. 계약은 문서라 되돌리기 싸지만 실행은 되돌리는 비용이 다르기 때문입니다.

한 번 돌고 나면 대상 폴더에 이런 파일들이 남습니다.

대상 모듈/
├── ARCHITECTURE.md      ← architecture
├── BDD.md  *.feature    ← bdd
├── SDD.md               ← sdd
├── TEST_PLAN.md         ← test-plan
├── …_PLAN.md            ← plan (진행 · 미완 · Report)
└── audit/               ← 독립 검수 기록

다음 사람이나 다음 세션의 AI 는 대화가 아니라 이 파일들에서 이어 갑니다.

6. 조립한 뒤 — 넓히는 규칙

흐름이 선 뒤에도 요구는 계속 옵니다. 그때 지키는 규칙은 셋입니다.

상황 규칙
새 요구가 왔다 갈래로 넣는다. 새 rootflow 는 성립 요건을 모두 넘을 때만 만든다 (Figma 의 교훈)
subflow 를 별도 문서로 떼고 싶다 두 rootflow 가 같은 subflow 를 필요로 할 때만
위층(Supervisor)을 늘리고 싶다 실물이 생긴 순서대로. 실물이 없으면 «미정» 으로 두고 지어내지 않는다

감독 층의 단계도 이 규칙대로 쌓였습니다. 처음 네 개(부르기 · 읽기 · 판정 · 개입), 완주한 작업이 생긴 뒤 둘(찾기 · 닫기), 그 뒤 하나(지켜보기), 마지막으로 쪼개기. 마지막 것은 «이 저장소에는 아직 실물이 없다» 는 꼬리표를 단 채로 들어왔습니다.

직접 해 보기

subflow 를 만드는 감을 잡는 가장 빠른 방법은 계약 행 하나를 직접 써 보는 것입니다.

  1. 지금 하는 작업에서 «매번 비슷하게 반복되는 단계» 하나를 고릅니다.
  2. 다음 순서로 한 줄씩 씁니다.
    • 입력 — 어느 단계의 무엇을 받나
    • 산출 — 무엇을 내놓고, 무엇을 어떤 축으로 세나
    • 통과 체크 — 입력을 빠짐없이 소비했나를 어떻게 확인하나
    • 반송지 — 틀리면 어디로 돌아가나
  3. AI 에게 그 계약만 주고 단계를 돌려 봅니다. 결과의 모양이 매번 같아지는지 봅니다.

시리즈를 마치며

편 한 줄
① subflow 는 단계 하나의 계약이고, 층은 «무엇을 모르나» 로 정한다
② subflow 는 사고 한 건에서 시작해 7단계를 거쳐 계약 한 줄이 된다
③ subflow 는 한 칸씩 갈라지고, 틀리면 원인부터 가르고, 줄 세우면 흐름이 된다

셋을 관통하는 것은 하나입니다. 실물이 먼저, 이름은 뒤. 위에서 먼저 정의한 것은 되돌려졌고 실제 작업이 보여 준 빈자리에 이름을 붙인 것만 남았습니다.

← ② 사고 한 건에서 계약 한 줄까지 · 처음으로: 셋이 남았을 때