AI-DLC와 Spec Kit을 태스크 보드 소재로 비교한 메모

목차

서론

본고는 사양 주도 개발 (Specification-Driven Development) 문맥에서 주목받고 있는 AI-DLC (이하 AIDLC)와 Spec Kit에 대해, 동일한 소재로 테스트한 결과를 정리한 것입니다. Spec Kit은 GitHub 상에 공개되어 있는 사양 주도 개발용 템플릿 군과 CLI (speckit 등)로 구성된 시도로, 개요는 github/spec-kit을 참조해 주십시오.

당사에서는 Zenn의 기사 「Github의 Spec-kit을 사용하여 사양 주도 개발(SDD)을 시도해 보았다」를 통해 Spec Kit 측의 흐름을 공유했으므로, 본고에서는 그 부분을 생략하고 AIDLC 측의 사용법과 비교 방식 및 소감을 기재합니다.

AIDLC란

AIDLC는 AI를 동반하며 요구사항·설계·구현·검증에 이르는 흐름을 규칙과 산출물로 뒷받침하는 개발 라이프사이클 (Development Lifecycle)의 개념입니다.

모든 공정을 동일한 비중으로 밟는 것이 아니라, 기존 코드의 유무나 변경 규모에 따라 필요한 단계만을 두텁게 하는 「적응형 (Adaptive)」 설계가 전면에 나옵니다.

산출물은 워크스페이스 직하의 문서 영역 (aidlc-docs/ 등)에 축적되며, 상태 파일 및 감사 로그 (Audit Log)와 함께 대화가 단절되더라도 문맥을 복구하기 쉽게 하는 것을 의도하고 있습니다.

리포지토리 상의 문서 배치 (그림 1·그림 2)

그림 1·그림 2는 툴을 도입한 직후의 스냅샷이 아니라, 본고의 비교에서 소재가 되는 프로덕트를 한 차례 진행한 후에 익스플로러 상에서 어떤 폴더·배치가 되었는지를 잘라낸 예시입니다. 나열된 스크린샷은 **「비교 관점」**의 소재를 한 차례 진행한 후의 폴더 모습 행에 모아두었습니다.

AIDLC의 사용법 (본고에서의 접근 방식)

실무상으로는 Cursor에 규칙 (.cursor/rules 및 .aidlc-rule-details/ 등)을 배치하고, 채팅으로 개발 의뢰를 할 때 AIDLC의 워크플로우 (Workflow)를 따른다는 방식의 사용이 중심이 됩니다.

워크플로우 시작 후, 요구사항 심층 분석 단계에서는 질문 파일에 대한 답변 등 사용자 측의 입력이 요구되는 장면이 있습니다.

그 시간이 짧지는 않지만, 나중에 문서를 다시 읽었을 때 「지금 어느 단계인가」, 「무엇을 결정했는가」를 자신과 타인 모두 추적하기 쉽게 만든다는 의미에서의 수고라고 파악했습니다.

이하는 본고의 비교에서 실제로 수행했을 때의 조작 흐름의 예시입니다 (화면은 당시의 채팅/에디터 캡처입니다).

초기 프롬프트 (Initial Prompt)

소재로 「태스크 보드」를 다루기에 앞서, 워크플로우를 기동하기 위한 첫 채팅 입력의 예시입니다. 짧은 의뢰로 시작하여, 상세 사양은 나중에 전달한다는 방침에 맞추고 있습니다.

AI로부터 요청받는 사항 (사용자 측의 대응)

시작 후, AI 측으로부터 「requirement-verification-questions.md에 있는 질문에 모두 답하고, 끝나면 채팅으로 짧게 알려달라」와 같은 다음에 사용자가 해야 할 일이 제시됩니다. 답변을 확인한 후 requirements.md 작성 등 다음 단계로 진행한다는 흐름의 설명이 포함된 예시입니다.

답변을 전달하는 방법 (본고에서는 채팅에 직접 기재)

본래는 aidlc-docs/inception/requirements/requirement-verification-questions.md에 각 문항의 [Answer]: 뒤에 선택지 (A/B 등)를 파일 상에 추가해 나갑니다.

본고의 작업에서는 에디터로 Markdown을 열어 가며 써 내려가는 것이 다소 불편했기 때문에, 채팅 입력란에 질문 번호별로 답변을 나열하는 형태로 그대로 보냈습니다. 내용은 파일에 쓰는 것과 동일하며, 답변의 위치가 「파일」인가 「채팅」인가의 차이일 뿐입니다.

Question 6을 몰랐을 때의 되묻기

Question 6(Property-Based Testing Extension)의 의도를 잘 이해하지 못했기 때문에, 채팅상에서 "구체적인 예를 들어 설명해 달라"고 되물었습니다. 그 결과, AI로부터 PBT를 채택할지의 선택지(A/B/C/X), PBT에 대한 대략적인 설명, 일반적인 단위 테스트(Unit Test)와의 이미지 차이, 태스크 보드에 대입한 예시, 선택지의 기준, 재선택 권유 등이 돌아왔습니다(이하는 그 대화 도중에 프롬프트란에 입력한 예시입니다).

PBT(Property-Based Testing) 요약 (위 설명을 요약하면 다음과 같습니다. 전문은 생략합니다):

• 특정 값을 지정한 하나의 케이스만 작성하는 것이 아니라, 무작위로 생성한 다수의 입력에 대해 "항상 성립해야 하는 성질(Property)"이 깨지지 않았는지 자동으로 확인하는 테스트 사고방식 및 운용 규칙에 관한 이야기입니다. AI-DLC의 Question 6은 그 방침을 프로젝트의 필수 규칙에 포함할지를 선택하게 하려는 의도였습니다.
• 일반적인 단위 테스트는 add(2,3)===5와 같이 예시를 고정하는 경향이 있지만, PBT에서는 "임의의 a, b에 대해 add(a,b)===add(b,a)"와 같이 입력 클래스 전체에 대한 규칙을 작성하고, 툴이 무작위 입력을 대량으로 시도한다는 이미지로 대비되었습니다.
• 태스크 보드에 대한 예로는, localStorage용 JSON으로의 저장 및 불러오기 왕복 과정에서 카드 매수나 ID 집합이 변하지 않는 것, 조작 후에 반드시 참이 되는 조건을 무작위 조작 시퀀스로 확인하는 것, 순수 함수(Pure Function)에만 PBT를 적용하는 것 등이 언급되었습니다.
• 선택지의 기준은 로직 전체에 PBT를 강력하게 적용(A), 순수 함수와 직렬화(Serialization) 왕복에만 적용(B), 초판은 CRUD 및 UI 중심으로 구성하며 PBT는 규칙화하지 않음(C) 등의 구분입니다. 정적 호스트, Vue, 브라우저 저장, 기본 조작만 있는 초판이라면 C 또는 B가 현실적인 경우가 많다는 주석도 포함되어 있었습니다(최종 판단은 팀의 품질 방침에 달려 있다는 취지였습니다).

질문표 파일 자체의 모습

inception 단계에서는 aidlc-docs/inception/requirements/requirement-verification-questions.md와 같은 Markdown 질문표가 놓이며, 헤더 아래에 선택지(A~E 등)가 나열되고, 답변은 [Answer]: 뒤에 추가해 나가는 형식이 됩니다(태스크 보드 소재의 경우 "요건 확인용 질문(태스크 보드)"와 같은 제목이 되는 예입니다). 파일상에서 편집할 때의 모습은 다음과 같습니다.

aidlc-state.md에 대하여

워크스페이스 직하(또는 규칙에 따른 경로)에 놓이는 상태 파일로, AIDLC의 워크플로우가 "현재 어느 단계에 있는지", "어느 체크 항목까지 완료되었는지", "최근의 감사나 의사결정 메모" 등을 대화가 단절되어도 동일한 리포지토리 내에서 추적할 수 있도록 하기 위한 메모 저장소입니다. 사람이 에디터로 열어 추가 및 업데이트하는 것을 상정하며, 헤더나 체크리스트로 구분되어 있는 경우가 많습니다.

본고에서 실제로 연 화면의 캡처는 후술할 **"비교 관점"**의 진행 상황·참조 경로(그림 3)에 나타내었습니다.

AIDLC와 Spec Kit 비교

본고에서는 AIDLC와 Spec Kit을 사용했을 때의 결과물(Product)과 리포지토리에 남는 자료의 차이를 확인하기 위해,

공통 소재로 태스크 보드를 다룹니다.

먼저 소재의 이미지로서, AI와 상담하며 만든 참조용 태스크 보드(기능이 갖춰진 완성 예시)를 준비했습니다. 비교에서는 각 툴에 짧은 의뢰만 전달하여 구현하고, 그 참조 모델에 가깝게 만드는 형태로 진행하는 것을 상정합니다. 참조 구현은 비교 대상인 구현과는 별개의 것이며, 이후 AIDLC / Spec Kit으로 실제로 만든 결과물과는 구별하여 기재합니다.

비교의 공정성을 위해 상세 요건을 미리 읽히지 않는 방침으로 정하였고, 초기 프롬프트는 "태스크 보드를 만들고 싶다" 정도로 단순화했습니다. 두 툴 모두 AI가 주도하기 쉬운 전제로 하여, AI의 질문이나 제시에는 답변 및 확인하는 형태로 진행했습니다.

위와 같은 필요 최소한의 지시 하에 얻은 앱은, 참조 구현(주제의 이미지)과 비교했을 때 화면이나 기능의 완성도 면에서 크게 다릅니다. 차이의 주된 원인은 툴의 우열뿐만 아니라, 전달한 정보의 부족함에도 있습니다. 세부 요구사항이나 와이어프레임(Wireframe)을 처음부터 전달했다면 다른 결과가 나왔을 수도 있지만, 본고의 목적은 동일하게 부족한 정보가 입력되었을 때, 진행 방식이나 결과물의 형태가 어떻게 다른지를 기록하는 것입니다.

본고의 스크린샷은 가능한 절에서 AIDLC 열과 Spec Kit 열을 나란히 배치한 표로 나타냅니다(툴을 가로질러 비교하기 쉽게 하기 위함입니다). 참조 구현의 주제를 나타내는 표에서는 이미지 개요 · 참조 구현 · AIDLC · Spec Kit의 4개 열로 구성하며, 각 툴 측에 해당하는 화면이 없는 경우에는 그 취지를 기재합니다.

• 주제: 브라우저에서 동작하는 태스크 보드(프론트엔드 중심 · 저장은 브라우저 내부라는 조건입니다).
• 초기 프롬프트(Prompt): 가능한 한 단순하게 하여, "태스크 보드를 만들고 싶다"와 같은 짧은 의뢰에 가깝게 설정했습니다(상세 사양은 미리 전달하지 않았습니다).
• 진행 방식: AI가 주체가 되기 쉬운 툴이라는 점을 고려하여, AI의 질문에는 답하고 제시된 사양 및 설계는 확인하는 자세로 진행했습니다.
• 환경: Cursor 상에서 실시했습니다. 사용한 AI 모델이나 확장 버전은 특정하지 않았으므로, 재현 결과는 환경에 따라 달라질 수 있습니다.

그림 5와 그림 6·7을 나란히 놓는다고 해서 "동일 주제의 완성도 비교"가 되지는 않습니다. 그림 5는 주제로서의 풍부한 참조이며, 그림 6·7은 짧은 의뢰만으로 생성된 결과입니다. 후자가 전자에 미치지 못하는 것은 주로 지시의 입도(Granularity) 차이 때문이라고 이해하면 좋습니다.

참조 구현의 태스크 보드 (비교 주제 · 앱 화면)

모두 브라우저상의 UI이며, 목록 · 입력 · 필터 등의 시각적 이미지를 위한 것입니다(복수 화면).
"이러한 태스크 보드를 주제로 삼는다"라는 공유용이며, 다음 절의 각 툴의 결과물과 동일한 것을 목표로 맞춘 것은 아닙니다.

아래 표는 참조 구현의 화면과, 동일한 짧은 의뢰로부터 얻은 AIDLC / Spec Kit 측의 화면을 나란히 배치한 것입니다. 참조 구현의 (중) (하)에 해당하는 UI는, 본 비교의 결과물에서는 어느 툴에서도 준비되지 않았기 때문에 해당 열에는 그 취지를 기재하고 있습니다 (그림 6 · 그림 7은 "기동 직후의 목록 주변"에 가까운 행만 대응합니다).

비교 구현으로 완성된 결과물 (앱 화면)

동일한 초기 방침(짧은 의뢰로부터 시작)으로, AIDLC를 사용하여 만든 태스크 보드와 Spec Kit을 사용하여 만든 태스크 보드의 브라우저상 모습 예시입니다. 로컬에서 npm run dev 등으로 실행한 직후의 메인 화면을 캡처했습니다.

여기서 보여주는 것은 툴별로 "처음 나타나는 화면"의 인상이며, 참조 구현(그림 5)과의 외관 · 기능의 우열을 결정하기 위한 스크린샷이 아닙니다. 필요 최소한의 지시로 한 의도대로, 심플한 UI에 머물러 있다고 이해하시면 됩니다.

그림 6 · 그림 7(기동 직후의 목록 주변)은 위의 "참조 구현의 태스크 보드" 표의 그림 5 (상) 행의 AIDLC / Spec Kit 열에 포함되어 있습니다.

비교 관점

다음 표는 본고의 비교 결과를 관점별로 정리한 것입니다. 설명과, 나중에 다시 볼 수 있는 참고 이미지를 같은 셀에 모아두었습니다.

이미지는 해당 관점을 보완하는 예시이며, 수치만으로 된 관점이나 적합성/부적합성 정리는 표에서 다루지 않습니다.

(전자는 후술할 "시간과 진행 방식의 체감", 후자는 후술할 "분기 가설"입니다.)

그림 번호는 다른 절과 동일합니다.

주(Traceability)

트레이서빌리티 (Traceability) (일본어로는 요구사항 트레이서빌리티 등으로도 불립니다)는 요구사항·사양·설계·테스트·구현 등의 산출물 사이에서, 「어떤 기술·결과물이 어디와 대응하는가」를 추적할 수 있는 것을 의미합니다. 본고의 표에서는 범위를 좁혀 문서(요구사항 정의서·사양서 등)와 실제 화면(UI) 및 그 설명과의 대응을 나중에 다시 읽었을 때 찾기 쉬운가라는 관점에서 사용하고 있습니다.

| 구현 완료까지의 시간 |
이번 사례에서는 질의응답 및 문서 작성을 포함하여 대략 1시간 정도 소요되었습니다. 요구사항의 왕복(Iteration)이 늘어날수록 시간이 길어지기 쉽습니다(후술할 「시간과 진행 방식의 체감」을 참조해 주세요). ※ 측정 조건은 엄밀하지 않습니다. (이미지 없음) 수치 및 요인의 정리는 본문과 「시간과 진행 방식의 체감」에 맡깁니다. |
이번 사례에서는 사양 묶음(Specification bundle)의 확인이 중심이 되어, 대략 15분 정도 만에 구현에 들어갈 수 있었다는 체감입니다(후술 참조). 전제 조건이 갖춰져 있을수록 확인이 더 빠르게 느껴졌습니다. ※ 마찬가지로 하나의 사례일 뿐입니다 (통계에서 말하는 n=1, 즉 시행이 단 1회뿐이므로 평균이나 재현을 보장하는 것은 아닙니다). (이미지 없음) 위와 동일합니다. |

시간과 진행 방식의 체감

AIDLC는 요구사항이 모호한 상태에서도 질문이 앞서기 쉬우며, 본인이 짧은 프롬프트 (Prompt)로 입력했을 때일수록 왕복이 늘어나기 쉽다는 인상을 받았습니다.

질의응답에 응하는 형태로 진행한 결과, 대략 1시간 정도 소요되었습니다 (문서를 두텁게 남긴 것도 시간에 포함됩니다). 이것이 이번의 한 사례입니다.

Spec Kit 측(본고에서는 설명 생략)은 이번 조건에서 AI가 사양서나 관련 문서를 정리된 형태로 준비하고, 본인은 그것을 읽고 확인하는 비중이 상대적으로 컸습니다.

이미 머릿속에서 "이렇게 하고 싶다"라는 것이 정리되어 있을수록 확인하는 수고가 적어, 대략 15분 정도 만에 구현에 들어갈 수 있었습니다. 이것이 이번의 한 사례입니다.

여기서 중요한 것은 시간 차이를 오직 "도구의 성능 차이"로만 환원하지 않는 것입니다.

이번에는 AIDLC에서 요구사항의 왕복이 많아진 점, Spec Kit 측은 전제 조건이 갖춰지기 쉬웠던 점 등 여러 요인이 겹쳤을 가능성이 있습니다.

따라서 수치는 하나의 사례 기록으로서 취급하는 것이 좋습니다.

개인적인 감상 (일반화할 때의 유보 사항)

• 소규모이며 즉시 동작하면 되는 것에 대해서는, 상황에 따라 짧은 프롬프트로 단번에 만들게 하는 편이 더 빠르다고 느꼈습니다. 다만, 나중에 다시 읽어볼 수 있는 사양이나 의사결정 기록이 얇아지기 쉽다는 트레이드오프 (Trade-off)도 있습니다.
• 중규모 이상, 혹은 여러 명이 계승하는 상황에서는 사양 주도형 (Specification-driven) 모델(문서와 구현의 대응)을 맞추는 의미가 생긴다는 인상입니다.
• 어떤 도구가 어떤 개발에 적합할지(요구사항의 모호함이나 브라운필드 (Brownfield)에 가까운지, 사양을 리포지토리 중심으로 둘 것인지 등)는 비교 관점 표에서는 다루지 않고, 직후의 **「분기의 가설」**에 정리해 두었습니다. 내용이 겹치므로 여기서는 반복하지 않습니다.

분기의 가설 ("어느 쪽이 적합한가")

이번에 가장 납득이 갔던 분기는 요구사항이나 사양이 명확한지 여부였습니다.

• 요구 및 요구사항이 아직 모호한 단계에서는, 질문을 통해 형태를 채워 나가는 AIDLC 쪽이 더 적합한 장면이 있었습니다.
• 어느 정도 구상이나 사양의 골격이 머릿속에서 굳어져 있는 경우에는, Spec Kit이 먼저 정리한 사양 묶음을 확인하며 진행하기 쉽다는 인상이었습니다.

덧붙여 경험칙으로서 거칠게 말하자면,

• 기존 시스템에 대한 추가·수정에서는, 기존 코드의 이해나 차분 (Diff)의 리스크를 다루기 쉬운 AIDLC적인 "브라운필드 (기존 시스템상에서의 추가·개수)에 가까운 준비 방식"이 상상하기 쉽습니다.
• 0에서 1을 만드는 단계에서 우선 사양을 리포지토리의 중심으로 두고 싶다면, Spec Kit의 spec $\rightarrow$ plan $\rightarrow$ tasks 흐름이 상상하기 쉽습니다.

라고 정리할 수 있습니다 (예외는 많으므로 자신의 팀의 전제 조건에서 시도하는 것이 안전합니다).

전반적인 이미지로서, AIDLC는 공정이나 심층 분석에 유연성이 있는 반면, Spec Kit은 사양과 산출물의 형태의 엄격함 및 일치시키기 쉬움이 강조되기 쉽다고 느꼈습니다.

마치며

본고는 개인의 체험과 하나의 사례 측정 (n=1)에 기반합니다. 시간 차이의 요인은 여러 가지가 있을 수 있으므로, 수치나 소감은 하나의 사례 기록으로서 취급해 주십시오.

독자가 재현할 때는 동일한 초기 프롬프트, 동일한 시간 구분 방식, 산출물을 취하는 방식을 맞추면 비교를 설명하기 쉬워집니다.

보충으로서 다음 점들도 파악해 두면 해석이 흔들리지 않습니다.

• 도구의 "정답"을 결정하는 글이 아닙니다. 조건을 고정한 상태에서의 진행 방식 및 자료의 차이에 대한 메모이며, 제품 선정의 유일한 근거로 삼지 않는 것이 좋습니다.
• 재현성: AI의 응답이나 확장 버전에 따라 결과는 달라질 수 있습니다. 동일한 절차라도 화면이나 소요 시간은 일치하지 않을 가능성이 있습니다.
• 참조 구현과의 차이: 앞서 언급한 바와 같이, 짧은 프롬프트로 진행한 결과로서 그림 6·7이 그림 5와 다른 것은 자연스러운 일입니다. 더 풍부하게 만들고 싶다면 요구사항, 화면 이미지, 우선순위를 처음부터 전달한다는 전제로 별도로 시도한다는 정리로 이해하시면 됩니다.