남의 방법론을 내 프로젝트에 심는 법

AI 협업 개발 방법론을 처음부터 제가 발명할 필요는 없었습니다. 이미 똑똑한 사람들이 정리해 둔 체계가 여럿 공개돼 있었습니다. 진짜 기술은 그것들을 발견하는 게 아니라, 가져와서 내 프로젝트에 **이식(graft)**하고, 충돌하는 부분을 솎아내고, 작업 크기에 맞게 차등 적용하는 일이었습니다. 이 글은 “왜 발명보다 채택인지”, “이식이 왜 복붙이 아닌지”, “방법론을 너무 많이 넣으면 왜 독이 되는지”를 차례로 풀어 쓴 기록입니다.

바퀴를 다시 발명하지 않기

AI 협업 개발이 처음이라 막막했습니다. “AI에게 어떻게 일을 시켜야 좋은 결과가 나오나”에 대한 정답이 제 머릿속에 없었습니다. 다행히 같은 고민을 먼저 한 사람들의 방법론이 공개돼 있었습니다. 작업을 발산 → 수렴 → 구현 → 디버그 → 리뷰 → 완료 단계로 나누는 체계, 브라우저 자동화·코드리뷰·배포 같은 흐름을 슬래시 명령으로 묶은 도구 모음, 문서를 먼저 쓰고 코드를 나중에 쓰는 흐름을 강조하는 접근 등이었습니다.

용어: 방법론 이식(graft)

남이 만든 개발 방법론·규칙·절차를, 처음부터 다시 발명하지 않고 내 프로젝트 구조에 맞게 옮겨 심는 것입니다. 식물 접붙이기(graft)처럼, 좋은 가지를 가져와 내 나무에 붙이되 거부반응이 나는 부분은 잘라냅니다.

여기서 가장 중요한 원칙은 우리 프로젝트 규칙에도 그대로 박아 넣었습니다.

이미 있는 것을 다시 짜는 것이 가장 낭비적인 작업이다.

이건 코드에만 해당하는 말이 아닙니다. 방법론을 고를 때도 똑같이 적용됩니다. 새 유틸·기능을 만들기 전에 ① 레포 안에 이미 있나 ② 패키지 레지스트리에 정답이 있나 ③ 기존 도구로 되나 ④ 공개 코드에 있나를 먼저 뒤지는 “탐색 우선(search-first)” 절차를 규칙으로 강제했습니다. 발명은 이 네 채널을 다 뒤지고도 답이 없을 때의 마지막 선택지입니다.

탐색 결과	행동	한 줄 설명
레포 안에 이미 있음	재사용	복사하지 말고 그대로 import
딱 맞는 공개 방법론·패키지	그대로 채택	보편적인 건 손대지 않고 가져옴
부분 일치, 좋은 기반	고쳐서 채택	얇게 감싸 내 구조에 맞춤
아무것도 없음	발명	탐색 결과를 근거로 최소한만 직접 만듦

이식은 복붙이 아니다

남의 방법론을 가져오는 건 압축파일을 푸는 것과 다릅니다. 그대로 넣으면 충돌합니다. 다른 사람의 프로젝트 구조를 전제로 만들어진 규칙은, 내 구조와 부딪힙니다. 예를 들어 “여러 백엔드로 나눠라”를 전제한 절차는, 단일 백엔드 하나로 모든 도메인을 처리한다는 우리 원칙과 정면으로 충돌합니다. 그대로 끼우면 오히려 사고가 납니다.

그래서 방법론 하나하나를 가져올 때마다 세 갈래로 판단해야 했습니다.

그대로 채택	고쳐서 채택 / 버림
단계 구분, 탐색-우선 원칙, 완료 검증 게이트, TDD처럼 보편적인 것은 거의 손대지 않고 가져왔다. 어떤 프로젝트에서도 통하는 원칙들이다.	우리 단일 백엔드 구조나 도메인 불변식과 부딪히는 건 얇게 감싸 고치거나, 아예 버렸다. 맞지 않는 규칙을 억지로 끼우면 독이 된다.

방법론을 스킬 단위로 잘게 쪼개 보관(개념도). 한 덩어리로 통째 로드하면 토큰만 먹고 안 지켜집니다. 작업 단계에 맞는 스킬 하나만 꺼내 읽게 하면 가볍고 잘 지켜집니다.

이식의 진짜 핵심은 방법론을 “스킬” 단위로 잘게 쪼개 보관한 것입니다. 거대한 한 덩어리가 아니라, 브레인스토밍·계획 작성·TDD·체계적 디버그·코드리뷰 루프·검증 게이트 같은 독립된 작은 문서로 나눴습니다. AI가 작업 단계에 맞는 스킬 하나만 꺼내 읽으면 되도록 말입니다. 한꺼번에 다 읽히면 토큰만 잡아먹고 정작 안 지킵니다.

방법론 과적의 함정

좋은 방법론을 발견하면 전부 다 넣고 싶어집니다. “이것도 좋고 저것도 좋으니 다 적용하자.” 그런데 이게 정확히 함정이었습니다.

함정: 규칙이 많을수록 좋은 게 아니다

규칙이 너무 많으면 AI가 그걸 다 따르지 못합니다. 그리고 작은 버그 픽스 한 건에도 “브레인스토밍 → 계획 → 위임 → 리뷰 → 검증”이라는 무거운 절차가 통째로 붙어 속도가 죽습니다. 실제로 한 줄짜리 수정에 한두 시간씩 걸린 적이 있었습니다. 좋은 방법론을 욱여넣은 결과가 오히려 생산성을 깎는 역설이었습니다.

그래서 작업 크기에 따라 절차를 차등 적용하는 “패스트 레인(Fast Lane)“을 따로 뒀습니다. 작업을 크기로 분류하고, 작은 작업은 무거운 절차를 면제했습니다.

작업 크기	예시	적용 절차
작음(S)	버그 픽스, 동작 보존, 적은 줄 수	수정 → 영향 테스트 → 커밋. 무거운 의식 면제
중간(M)	멀티파일 기능, 새 엔드포인트	파급범위 1회 확인 → 구현 → 테스트. 일부 검토는 선택
큼(L)	거대 리팩토링, 신규 모듈, 스키마 변경	풀 파이프라인 + 강제 게이트 전부 켬

핵심은 안전망 — 테스트·린트·보안 검사 — 은 작업 크기와 무관하게 항상 유지하되, 발산·계획·위임 같은 무거운 의식만 작업 크기에 맞춰 켜고 끈 것입니다. 방법론은 많이 가질수록 좋은 게 아니라, 상황에 맞게 꺼낼수록 좋습니다.

실제 이식은 이렇게 흘러갔다

추상적으로 들릴 수 있으니, 공개 방법론 하나를 우리 프로젝트에 심는 과정을 단계로 펼쳐 봅니다. 실제로 매번 이 흐름을 탔습니다.

1. 발견 — “작업을 발산→수렴→구현으로 나누고, 각 단계에 전용 스킬 문서를 둔다”는 공개 체계를 찾았습니다.
2. 충돌 점검 — 그 체계가 전제하는 구조(예: 여러 백엔드로 분리)가 우리 단일 백엔드 원칙과 부딪히는지 확인했습니다. 부딪히는 부분을 표시했습니다.
3. 분해 — 한 덩어리로 가져오지 않고, “브레인스토밍·계획·TDD·디버그·리뷰·검증”이라는 독립 스킬 문서로 쪼갰습니다.
4. 선별 — 보편적인 스킬은 거의 그대로, 충돌하는 건 얇게 감싸 고치거나 버렸습니다.
5. 차등화 — 작은 작업이 무거운 절차에 깔리지 않도록, 작업 크기별로 어떤 스킬을 꺼낼지(패스트 레인) 규칙을 달았습니다.
6. 강제 — 남긴 스킬 중 꼭 지켜야 할 것은 권고가 아니라 게이트로 묶어, 안 지키면 작업이 막히게 했습니다.

핵심은 1단계(발견)와 6단계(강제) 사이에, **2~5단계의 “솎아내기”**가 반드시 들어간다는 점입니다. 발견하자마자 통째로 강제하면 거부반응이 납니다 — 접붙인 가지가 거부반응 없이 살아남으려면, 중간의 다듬는 단계가 필요합니다.

이식의 진짜 가치

여러 방법론을 심으면서 배운 건, 방법론 자체보다 **“내 맥락에 맞게 취사선택하는 안목”**이 진짜 자산이라는 점이었습니다. 어떤 규칙이 우리 도메인 불변식과 충돌하는지, 어떤 게 1인 개발에는 과한지, 어떤 게 작은 작업엔 사치인지를 판단하는 능력입니다. 이건 책으로 안 생깁니다. 직접 충돌을 겪고, 속도가 죽는 걸 체감하고, 솎아내 봐야 생깁니다.

그러니 “어떤 방법론이 최고인가”는 사실 잘못된 질문입니다. 진짜 질문은 **“내 프로젝트의 이 상황에, 이 작업 크기에, 어떤 절차가 맞는가”**입니다. 같은 방법론도 큰 작업엔 약이고 작은 작업엔 독입니다.

한 가지 더. 이식한 방법론은 한 번 심고 끝이 아니라 계속 다듬어야 합니다. 처음엔 좋아 보였던 규칙이 실제로 굴려 보니 과하거나, 거꾸로 빈틈이 보일 수 있습니다. 그럴 때 망설이지 않고 고쳤습니다 — 너무 빡빡한 게이트는 자동 만료 시간을 달거나 작은 작업엔 면제하고, 자주 새는 구멍엔 새 검사를 더했습니다. 남의 방법론을 심는다는 건 그 체계를 존중하되 신봉하지는 않는다는 뜻입니다. 내 프로젝트의 실제 마찰이 언제나 원저자의 의도보다 우선합니다.

교훈

AI 협업 방법론은 처음부터 발명하지 말고, 공개된 체계를 탐색 우선으로 채택하세요. 단 복붙은 금물입니다. ① 보편적인 건 그대로 가져오고, ② 내 구조와 충돌하는 건 고치거나 버리고, ③ 방법론을 스킬 단위로 잘게 쪼개 작업 단계에 맞는 것만 꺼내 읽히고, ④ 작업 크기에 따라 절차를 차등 적용하세요(작은 작업에 무거운 의식은 독입니다).

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 이렇게 솎아낸 규칙들이 어떻게 강제로 작동하는지는 〈루프를 닫다〉에, 그 규칙을 떠받치는 큰 그림은 〈하네스〉에 있습니다.