AI 구현전에 스펙을 먼저 검증하는 OSS 프로젝트를 만들어봤습니다.
최근 Codex, Claude Code 같은 AI 코딩 도구들로 스펙 주도 개발을 하며 느낀 점이 하나 있습니다.
사용할수록 AI가 생성한 코드의 구조가 무너지는 원인이 대부분 AI 자체에 있다고 생각했는데 여러 번 실험하다 보니 오히려 스펙 주고 개발을 하며 아래와 같은 문제들이 더 자주 발생하더라고요.
ownership boundary 누락
delete/update 정책 불명확
contract 불일치
구현 드리프트
요구사항 범위를 벗어나는 기능 확장
애매한 요구사항으로 인한 구조 불안정
흥미로웠던 건 많은 경우 AI는 실제로 “주어진 스펙”을 최대한 따르려고 하고 있었다는 점입니다.
즉 AI가 문제라기보다, 입력된 스펙 자체가 불완전하거나 안전하지 않은 경우가 많았습니다.
그래서 최근에는 구현 전에 먼저 스펙 자체를 검증하는 흐름을 실험하고 있습니다.
개인적으로는 이걸 VFW(Validation-First Workflow)라고 부르고 있습니다.
대략적인 흐름은 아래처럼 생각하고 있습니다.
Discovery → spec.md → technical-design.md → SpecGuard Reviee(validation) → implementation handoff → coding agent → Pull Request → SpecGuard PR Review
목적은 간단합니다.
Discovery 단계에서 사용자의 요구사항에 따라 기본 스펙 틀을 생성합니다. (Spec Kit 형태로 로컬에서 연동한 Codex가 생성)
사용자는 개발을 위한 스펙을 보완 및 추가합니다.
SpecGuard Review에서 휴리스틱 기반 검사 또는 Codex 기반 스펙을 검증합니다.
명백한 스펙의 취약이 발견될 경우(NOT READY) 리포트를 제공하며 사용자는 그것을 토대로 스펙을 보완합니다.
스펙의 취약이 발견되지 않을 경우(READY) implementation-output.md 파일을 생성하며 사용자은 이 산출물을 AI(코덱스, 클코 등)에게 전달하여 스펙 기반 개발을 진행합니다.
대략적인 워크플로우는 저정도 이고, PR Review 기능은 선택사항으로 별도로 설정할 수 있는 명령어를 제공합니다.
PR Review에선 OpenAI 기반으로 PR에 올라온 코드가 스펙의 요구사항을 잘 반영 하였는지 확인하며, 결함이 보일 경우 PR 코멘트를 작성합니다.
위의 모든 단계는 선택 사항으로 특정 단계로 건너뛰어도 상관없습니다.
아직 heuristic 기반이라 오탐도 많고 benchmark coverage도, 프롬프트 엔지니어링도 부족한 매우 초기 단계 프로젝트입니다.
현재는 아래 같은 것들을 실험 중입니다.
Spec Readiness Review
Critical / Major / Minor Findings
Validation First Workflow(VFW)
PR Drift Review
Contract Validation
Implementation Handoff Review
아직 실제 프로덕션 레벨 도구라기보다는 아이디어 검증에 가까운 상태이긴 합니다.
다만 AI 기반 개발이 많아질수록 “AI가 얼마나 좋은 코드를 생성하는가” 보다 “입력 스펙이 얼마나 안전하고 명확한가” 가 더 중요해질 수도 있겠다는 생각이 들어 계속 실험 중입니다.
실무에서 스펙 주도 개발을 하고 계시거나, 비슷한 고민을 해보셨던 선후배님들이 계시다면 방향성이나 아이디어 측면에서 어떤 의견이든 듣고 싶습니다.
또한 OSS 프로젝트이다 보니 관심 있으신 분들의 이슈, 컨트리뷰션도 언제든 환영합니다 🙂
예전엔 홍보 게시판이 있던것같은데.. 혹시 문제가 되면 말씀해주시면 삭제하겠습니다.
