고칠 수 없는 도구는 내 것이 아니다 — 오픈소스 워크플로 둘을 계승해 내 파이프라인으로
왜 완성품을 그대로 쓰지 못했나
공개된 AI 개발 워크플로 두 가지를 각각 실사용했다. 하나는 단계별로 산출물을 강제하는 방법론 계열 BMAD V6, 다른 하나는 TDD·검증 규율을 스킬로 묶은 하니스 계열 superpowers다. 둘 다 MIT로 공개돼 있고 둘 다 잘 만들어져 있다.
그런데 그대로 쓰기는 어려웠다. 막힌 곳은 기능이 아니라 두 군데였다.
첫째, 안 쓰는 것이 너무 많았다. BMAD는 스킬이 넓게 깔려 있는데 내 작업에서 실제로 타는 건 그중 일부였다. 쓰지 않을 것까지 일단 익혀야 어느 게 내 것인지 판별된다. 첫 번째 문제는 여기에 있었다. 무엇을 안 써도 되는지 알아내는 데만 학습 비용이 들었고 그 비용은 내가 실제로 쓰는 기능의 양과 무관했다. 도구가 크면 진입 비용은 쓰는 만큼이 아니라 전체 표면적에 비례한다.
둘째, 내가 만든 게 아니라서 고칠 수가 없었다. 이게 결정적이었다. 쓰다 보면 반드시 어긋나는 지점이 나오는데 남의 워크플로에서는 그 한 줄을 고치는 일이 간단하지 않다. 어디를 건드리면 무엇이 따라 움직이는지 모르고, 고쳐 놓아도 원본이 갱신되면 그 수정이 어디로 가는지 알 수 없다. 문제가 생겼을 때 내가 손댈 수 있는가가 도구를 계속 쓸 수 있는지를 갈랐다.
첫째는 불편이고 둘째는 제약이다. 불편은 참고 쓰면 되지만 제약은 시간이 갈수록 쌓인다.
고르지 않고 나눠 맡겼다, 그리고 뺐다
둘 중 하나를 고르는 대신 나는 둘을 섞어 여섯 단계짜리 파이프라인으로 다시 짰다. 분석·아키텍처·UX·스토리·개발·테스트다. 다만 통째로 포개지는 않았다. 각자 어느 구간에서 강한지 확인하고 그 구간만 맡겼다.
분석 단계를 예로 들면 이렇게 갈랐다.
분석 = BMAD의 발산(넓게 벌리기) → superpowers의 수렴(좁혀서 확정)
BMAD는 아이디어를 100개 넘게 벌려 놓는 쪽이 강했고, superpowers는 벌어진 것을 승인 게이트로 조여 산출물로 굳히는 쪽이 강했다. 한 흐름 안에서도 앞 구간과 뒤 구간이 요구하는 성질이 반대다. 이게 둘을 각각 써보며 얻은 판단이었고, 그래서 앞뒤를 갈라 맡겼다.
붙이는 것보다 오래 걸린 건 빼는 쪽이었다. 원본을 그대로 옮기면 앞서 말한 첫 번째 문제가 그대로 따라온다. 그래서 단계마다 무엇을 뺄지 따로 판단했다. 이를테면 발산 단계에서 원본은 탐색 → 패턴인식 → 발전 → 액션플랜 네 걸음을 밟는데, 뒤 두 걸음은 내 구조에서 다음 단계가 담당하므로 발산은 두 걸음으로 잘랐다. 시각 보조 도구처럼 별도 스크립트에 기대는 부가 기능도 뺐다.
빼는 데도 함정이 있다. 눈에 띄는 것만 걷어내면 뺀 것이 아니라 안 본 것이 된다. 그래서 원본의 분석·설계 스킬을 목록째 놓고 하나씩 짚어, 내 파이프라인이 판단조차 안 한 자리가 있는지 따로 점검했다. 빼기는 판단이라, 무엇을 뺐는지 말하려면 무엇이 있었는지부터 알아야 한다.
한 가지는 일부러 안 뺐다. 발산의 강도다. 도구를 줄이는 원칙을 세워두고도 발산만은 원본 그대로 100개 넘게 벌리도록 뒀다. 그게 이 융합의 핵심 가치라고 봤기 때문이다.
호출하지 않고 계승했다
가장 중요한 결정은 원본을 호출하지 않는 것이었다.
원본 스킬을 불러 쓰는 방식이면 두 번째 문제가 그대로 남는다. 원본이 설치돼 있어야 하고, 원본이 바뀌면 내 워크플로가 같이 흔들리고, 고치고 싶은 한 줄은 여전히 남의 파일 안에 있다. 그래서 구조와 기법만 가져와 새로 썼다. 결과적으로 두 원본이 하나도 설치돼 있지 않은 환경에서도 파이프라인이 단독으로 동작한다.
대신 두 가지를 문서로 못 박았다.
귀속. 원본 저작권자와 라이선스를 명시하고 어느 원본의 어느 스킬이 어디로 갔는지 매핑 표를 남겼다. 계승이지 발명이 아니라는 걸 문서가 먼저 말하게 했다.
변형 내역. 무엇을 왜 바꿨는지를 변형 / 원본 / 우리 / 이유 네 칸짜리 표로 단계마다 기록했다. 이 표가 실제로 제값을 한다. 원본이 갱신되면 이 표로 차이를 대조해 필요한 것만 다시 들여올 수 있다. 실제로 최근에는 원본들의 새 버전에서 몇 가지 개념을 골라 다시 수입했는데, 그때 기준이 된 게 이 표였다.
graph LR
B["BMAD V6
발산 구간이 강함"] -.->|"구조·기법 계승
(호출 아님)"| P
S["superpowers
수렴 구간이 강함"] -.->|"구조·기법 계승
(호출 아님)"| P
P["내 6단계 파이프라인
원본 미설치에도 단독 동작"]
B -.->|"신버전 갱신"| T["변형내역 표
변형·원본·우리·이유"]
S -.->|"신버전 갱신"| T
T -->|"필요한 것만 재수입"| P
style B fill:#eef5ff,stroke:#8aa9d9,color:#1a1a1a
style S fill:#eef5ff,stroke:#8aa9d9,color:#1a1a1a
style P fill:#e0ffe0,stroke:#8ab98a,color:#1a1a1a
style T fill:#fffacc,stroke:#c9b84a,color:#1a1a1a
무엇을 왜 바꿨는지 적어두지 않은 fork는 시간이 지나면 원본과 대조할 수 없게 된다. 그러면 갱신을 따라갈 수도, 되돌릴 수도 없다.
결과
변경 요청이 들어오면 파급 범위를 가늠해 닿는 단계만 타고, 각 단계는 산출물을 루브릭으로 후행검증한다. 첫 커밋에서 지금까지 석 달, 예순 번 넘게 고쳤다. 사이드 프로젝트 세 곳에 설치돼 돌아간다.
효과는 정성으로만 말할 수 있다. 수치로 재두지 않았다. 작업 시간이나 재작업 횟수를 남겨 두지 않았고 지금 와서 만들 수도 없다.
다만 체감은 분명하다. 가장 자주 느끼는 건 발산 단계다. 요구를 넓게 벌리는 구간에서 내가 떠올리지 못했던 항목이 나온다. 혼자 생각할 때는 익숙한 방향으로 먼저 좁아지는데, 100개를 강제로 벌려 놓으면 그 바깥이 몇 개 걸린다. 앞서 발산의 강도만은 줄이지 않기로 한 판단이 여기서 제값을 한다.
학습
- 외부 도구의 비용은 기능이 아니라 개입 가능성에서 온다. 기능이 모자라면 안 쓰면 그만이지만, 고칠 수 없는 도구는 어긋나는 지점이 쌓여도 손쓸 방법이 없다. 오래 쓸 도구를 고를 때는 무엇을 해주는가만큼 내가 어디까지 건드릴 수 있는가를 본다.
- 변형을 기록하지 않은 fork는 그 순간부터 원본과 남남이 된다. 무엇을 왜 바꿨는지 원본과 나란히 적어두지 않으면 원본이 갱신됐을 때 따라갈 수도 되돌릴 수도 없다. 이 대조표가 있느냐 없느냐가 계승을 갈랐다. 표가 있으면 계승이 갱신 가능한 상태로 남고 없으면 한 번의 복사로 끝난다.
- 줄이는 원칙에도 예외를 정해야 한다. 안 쓰는 것을 걷어내는 게 이 작업의 절반이었지만, 발산만은 원본 그대로 뒀다. 무엇을 줄일지만 정하고 무엇은 줄이지 않을지를 안 정하면, 도구를 다듬다가 도구의 강점까지 깎게 된다.
- 도구를 합칠 때 기준은 「둘 다 좋다」가 아니라 「어느 구간에서 좋은가」다. 좋은 것 둘을 통째로 포개면 기능이 겹치고 고르는 비용만 는다. 각자 강한 구간을 확인해 그 구간만 맡겨야 두 도구가 하나의 흐름이 된다. 합성의 단위는 도구가 아니라 구간이다.