AI 시대 개발 방법론 (SDD+TDD)
AI 사용이 보편화 되면서(아직은 아닌 분야도 많지만 공공과제 보고있나??!!) 소프트웨어 개발에서 인간은 시스템의 의도(Intent)와 규약(Contract)을 정의하는 설계자이자 검증자가 되고있습니다. 이러한 흐름속에서 명세 주도 개발 (Spec-Driven Development)은 단순한 방법론을 넘어 핵심적인 아키텍처 패턴으로 부상하고 있습니다.
기존의 전통적인 환경에서는 명세서는 개발에 참고하기 위한 참고자료였고 실제 구현단계를 지나면 명세서와 코드간의 괴리가 발생하는 아키텍처 표류(Architectuaral Drift)가 고질적인 문제로 지적되어왔습니다. 하지만 코드 생산의 속도와 AI의 능력이 특정 임계점을 넘어서면서 코드의 명확한 의도를 전달하는 명세가 가장 중요한 핵심 자산이 되어가고 있습니다.
특히 인간의 코드 가독 능력과 이해 속도가 AI생산 속도를 따라가지 못하는 소위 인간이 병목이 되는 현상이 발생함에 따라 기존의 코드리뷰가 병목이 되는 현상이 발생하고 있으며 이로 인하여 TDD(Test-Driven Development)를 SDD에 결합하면서 강력한 시너지를 내고있습니다.
명세 주도 개발(SDD)의 구조와 메커니즘
AI개발에서의 SDD는 정의하면 잘 정제된 소프트웨어 요구사항 명세서를 AI 코딩 에이전트의 프롬프트로 사용하여 실행 가능한 코드를 생성하고 검증하는 개발 패러다임입니다. SDD에서 명세는 단순한 무서를 넘어 '실행 가능한 아티팩트'로 취급합니다. 즉 명세와 구현의 결과가 일치하지 않을 경우 빌드실패 혹은 오류로 설정함으로써 명세를 벗어난 구현을 원천적으로 차단합니다.
SDD는 다음과 같은 아키텍처적 통제 평면(Control Plane)을 제공합니다.
선언적 의도 정의: 시스템이 무엇을 수행해야 하는지 선언적으로 정의하며, 구체적인 구현 방식은 AI와 도구에 위임
결정론적 물질화(Deterministic Materialization): 동일한 명세는 다양한 언어와 플랫폼에서 동일한 아키텍처 결과물을 생성
지속적 제약 조건 검증: 스키마 유효성 검사, 계약 테스트, 페이로드 검사 등을 통해 시스템이 설계 의도에서 벗어나지 않도록 실시간으로 감시
또한 일반적으로 SDD는 그 적용 깊이에 따라 세가지 단계로 구분합니다.
가장 급진적인 Spec-as-Source의 단계까지가면 명세는 소스코드와 동일한 위상을 가지게 됩니다.
SDD와 TDD의 시너지와 "Spec = TC"의 실현
현재 TDD는 AI 코딩 과정에서 발생할 수 있는 '환각(Hallucination)'이나 '논리적 비약'을 차단하는 가장 현실적인 방안으로 떠오르고 있습니다. AI 에이전트에게 구현을 맡기기 전, 기대하는 동작을 테스트 코드로 먼저 정의함으로써 AI의 창의성을 요구사항이라는 범위 안에 가두는 '가드레일' 역할을 수행하기 때문입니다.
따라서 TDD의 Red-Green-Refactor 사이클은 AI 시대에 다음과 같이 재해석됩니다.
Red (명세 기반 테스트 생성): 엔지니어는 명세로부터 도출된 테스트 케이스를 AI에게 요구하거나 직접 작성하여 실패하는 상태를 만듬
Green (자동화된 구현): AI 에이전트는 해당 테스트를 통과하기 위한 최소한의 코드를 신속하게 생성함
Refactor (AI 지원 설계 개선): 생성된 코드의 아키텍처적 일관성을 유지하면서 설계를 개선하도록 AI에게 지시함
테스트 스위트는 AI가 작성한 코드의 건전성을 확인하는 체크포인트가 되며, 엔지니어는 코드를 일일이 읽는 대신 테스트의 통과 여부와 에지 케이스(Edge Case) 커버리지를 확인하는 것으로 업무의 질을 높일 수 있습니다.
명세가 테스트 케이스가 되고 테스트 케이스가 명세가 되는 관계
AI 네이티브 환경의 정점은 명세(Spec)와 테스트 케이스(TC)가 동일한 정보를 다른 형태로 표현하는 것을 넘어, 서로 교환 가능한 상태가 되는 것이다. 사용자가 언급한 "Spec = TC"의 관계는 현대적인 SDD 도구들이 지향하는 핵심 목표입니다.
실행 가능한 명세로서의 테스트: BDD(Behavior-Driven Development) 시나리오나 API 계약 테스트는 명세인 동시에 실행 가능한 검증 수단
명세로부터의 자동 테스트 생성: GitHub Spec Kit이나 Kiro 같은 도구들은 정의된 명세를 바탕으로 시스템이 준수해야 할 불변량을 테스트 코드로 자동 변환
테스트 실패를 통한 명세의 진화: 구현 과정에서 발견된 예외 상황은 테스트 케이스에 추가되고, 이는 다시 상위 명세에 반영되어 시스템의 전체적인 지식 베이스를 강화
이러한 선순환 구조는 "명세(의도) → 계획 → 작업 분할 → 구현 → 검증"이라는 단단한 피드백 루프를 형성합니다. 명세가 명확할수록 AI의 작업 성공률은 급격히 상승하며, 이는 결과적으로 개발 주기를 단축시키고 품질을 향상시킵니다.
개발자가 가져야 할 새로운 마인드셋과 전문성
AI가 코드 작성을 100%에 가깝게 수행하는 환경에서 인간 개발자는 '벽돌을 쌓는 사람(Bricklayer)'에서 '명령을 내리는 사령관(Commander)' 혹은 '시스템 설계자(Architect)'로 정체성을 전환해야 합니다.. 이는 단순히 생산성이 높아지는 것을 넘어, 엔지니어링의 본질이 변하는 과정이라고 할 수 있습니다.
앞으로 개발자의 기술자인 해자는 다음 역량에서 결정된다고 보고있습니다.
제품 및 디자인 비전: 무엇이 '가짜 요구사항'인지 파악하고 제품의 본질적인 가치를 정의하는 능력
고가용성 시스템 설계: AI가 채워 넣을 수 있는 견고한 모듈 구조와 아키텍처를 설계하는 능력
엄격한 수용 기준(Acceptance Criteria) 설정: AI의 논리적 허점을 간파하고 무엇이 '성공'인지 정의하는 전문 테스터의 시각
인지적 위축에 대한 경계와 실력의 진화
AI에 대한 의존도가 높아짐에 따라 개발자의 문제 해결 능력이 퇴보할 수 있다는 우려, 즉 '인지적 위축'에 대한 경계가 필요합니다. 실제 코딩을 수행하지 않음으로 인하여 코드레벨의 감각을 잃어버릴 수 있기 때문입니다.
따라서 앞으로의 개발자는 AI가 만든 결과물을 '비판적으로 검토(Discrimination)'할 수 있는 상위 수준의 지식을 갖추어야 합니다. 또한 AI는 훌륭한 '조수'이지만 때로는 '환각을 일으키는 전문가'이기도 합니다. AI가 생성한 코드가 보안상 안전한지, 효율적인 알고리즘을 사용했는지, 아니면 단순히 그럴듯해 보이는 '스파게티 코드'인지를 판별할 수 있는 깊은 안목이 곧 실력이 되는 시대가 오고있습니다.
AI 네이티브 개발
앞으로의 개발자는 단순히 코드를 치는(Typing) 사람이 아니라, 의도를 설계하고(Design Intent), 규약을 정의하며(Define Contract), 가치를 검증하는(Verify Value) 시스템 오케스트레이터가 되어야 합니다.
이에따라 본 글에서는 다음 세가지의 마인드셋을 제시하고 싶습니다.
추상화 계층의 상향 이동: 세부 구현(How)은 AI에게 위임하되, 시스템의 불변량과 비즈니스 로직의 의도(What/Why)를 선언적으로 정의하는 데 집중하라
검증 기반의 신뢰 구축: AI가 작성한 코드를 맹신하지 말고, TDD와 SDD를 결합한 강력한 자동화 검증 체계를 구축하여 시스템의 건전성을 확보하라
지속적인 학습과 비판적 사고: 기술적 해자가 코드 작성 능력에서 시스템 설계 및 문제 정의 능력으로 이동함을 인식하고, AI의 결과물을 판별할 수 있는 깊은 도메인 지식과 컴퓨터 과학의 근본 원리를 끊임없이 연마하라
AI 시대에 개발자들이 불안을 느끼는 것은 당연합니다. 하지만 변화에 적응하고 따라간다면 개발자의 수요는 줄어들지않고 오히려 늘어날 것이라고 판단합니다. 이 글을 읽는 모든 개발자 분들이 이 글이 도움이되어 아키텍처로 나아가시기를 소망하고 기원합니다.