당신의 다음 소프트웨어 프로젝트에서 가장 중요한 파일이 .java, .ts, 또는 .py 파일이 아니라 .md 파일라면 어떨까요?

AI 코딩 어시스턴트(AI coding assistants)의 부상은 우리 중 많은 이들이 소프트웨어를 작성하는 방식을 변화시켰습니다.

모든 클래스(class), 엔드포인트(endpoint), 또는 컴포넌트(component)를 수동으로 구현하는 대신, 우리는 점점 더 우리가 원하는 것이 **무엇(what)**인지 기술하고, AI가 그것이 어떻게(how) 구축될지를 생성하도록 맡기고 있습니다.

이는 흥미로운 질문을 던집니다:

만약 AI가 코드를 작성한다면, 소프트웨어 공학의 주요 산출물(artifact)은 무엇이 될까요?

저는 그 답이 **명세(specification)**라고 믿습니다.

더 구체적으로, 저는 구조화된 Markdown 명세가 인간과 AI 사이의 인터페이스가 되는 반면, 소스 코드(source code)는 구현 산출물(implementation artifact)이 되는 세상으로 나아가고 있다고 생각합니다.

이 아이디어는 흔히 **명세 기반 개발 (Spec-Driven Development, SDD)**이라고 불립니다.

오늘날 AI 개발의 문제점

대부분의 개발자는 다음과 같은 경험을 해보았을 것입니다:

사용자:
사용자 인증 시스템을 만들어줘.

...

AI가 실패하고 있는 것이 아닙니다.

AI는 추측하고 있는 것입니다.

모든 새로운 프롬프트(prompt)는 처음부터 존재했어야 할 컨텍스트(context)를 추가합니다.

이것은 종종 _바이브 코딩 (vibe coding)_이라고 불리는데, 대화를 통해 원하는 결과에 도달할 때까지 반복적으로 AI를 조종하는 것을 의미합니다.

이는 프로토타입(prototype) 제작에는 놀라울 정도로 잘 작동합니다.

하지만 복잡한 시스템에서는 확장성(scale)이 떨어집니다.

명세 기반 개발의 등장

대화가 진실의 원천(source of truth)이 되는 대신, 명세(specification)가 진실의 원천이 됩니다.

당신이 의도한 바를 AI에게 반복해서 말하는 대신, 시스템을 한 번 정의합니다.

아이디어 (Idea)
  ↓
명세 (Specification)
...

이제 모든 AI 에이전트(AI agent)는 동일하게 공유된 이해를 바탕으로 작동합니다.

왜 Markdown인가?

Markdown은 놀라울 정도로 강력합니다.

그 이유는 다음과 같습니다:

• 인간이 읽기 쉬움 (readable by humans)
• 버전 관리 가능 (version-controlled)
• 차이점 확인 용이 (diff-friendly)
• 제품 팀이 사용하기에 충분히 단순함
• AI 에이전트가 사용하기에 충분히 구조화됨

프로젝트는 다음과 같은 모습일 수 있습니다:

specs/
├── constitution.md
├── product-spec.md
...

(또는 어쩌면 단 하나의 PRD.md -- 제품 요구사항 문서 (Product Requirements Document) -- 만으로도 충분할 수도 있습니다.)

이 파일들 중 어느 것도 실행되지 않습니다.

하지만 이 파일들이 모여 소프트웨어를 구축하는 데 필요한 거의 모든 것을 설명합니다.

명세(Specification)가 제어 평면(Control Plane)이 된다

다음과 같이 프롬프트(Prompt)를 작성하는 대신:

"결제 API를 만들어줘."

당신은 다음과 같은 것들을 정의합니다:

• 비즈니스 목표 (business objectives)
• 사용자 역할 (user roles)
• 도메인 엔티티 (domain entities)
• API 계약 (API contracts)
• 검증 규칙 (validation rules)
• 보안 요구사항 (security requirements)
• 성능 목표 (performance targets)
• 수락 기준 (acceptance criteria)
• 엣지 케이스 (edge cases)

이제 AI는 단 한 줄의 코드를 작성하기 전에 문맥(Context)을 갖게 됩니다.

추측은 줄어들고.

엔지니어링은 늘어납니다.

AI 에이전트가 전문가가 된다

SDD(명세 기반 개발)에서 저를 흥분시키는 한 가지 측면은, 이것이 여러 AI 에이전트(AI agents)가 협업하는 방식을 얼마나 자연스럽게 지원하느냐 하는 점입니다.

예를 들어:

                 명세 (Specification)
                        │
        ┌───────────────┼───────────────┐
...

단일 어시스턴트와 거대한 대화를 나누는 대신, 각 에이전트는 집중된 책임을 갖습니다.

명세는 에이전트들 사이의 공유된 계약(Contract)이 됩니다.

이것은 소프트웨어 엔지니어의 역할을 변화시킨다

어떤 이들은 AI가 소프트웨어 엔지니어를 대체할 것이라고 걱정합니다.

저는 이것이 우리가 무엇을 최적화하느냐를 바꾸고 있다고 생각합니다.

가장 가치 있는 엔지니어는 다음과 같은 분야에서 뛰어난 역량을 발휘하는 사람이 될 것입니다:

• 시스템 설계 (system design)
• 아키텍처 (architecture)
• 도메인 모델링 (domain modeling)
• 제품 사고 (product thinking)
• 정밀한 명세 작성 (writing precise specifications)
• AI가 생성한 구현체 검토 (reviewing AI-generated implementations)
• 품질 표준 정의 (defining quality standards)

다시 말해:

우리는 컴퓨터에게 무언가를 어떻게(how) 할지 말하는 데 쓰는 시간을 줄입니다.

대신 _무엇이 존재해야 하는지(what should exist)_를 정의하는 데 더 많은 시간을 씁니다.

이것이 프로그래밍 언어를 대체하는 것은 아니다

Java가 사라지는 것은 아닙니다.

Python, Go, Rust, TypeScript, 또는 C#도 마찬가지입니다.

코드(Code)는 여전히 중요합니다.

성능(Performance)도 여전히 중요합니다.

아키텍처(Architecture)도 여전히 중요합니다.

인간의 판단(Human judgment)도 여전히 중요합니다.

차이점은 코드가 더 이상 가장 높은 수준의 산출물(Artifact)이 아닐 수도 있다는 점입니다.

명세가 다른 모든 것이 파생되는 토대가 될 수 있습니다.

도전 과제

모든 엔지니어링 접근 방식과 마찬가지로, SDD에도 트레이드오프(Trade-offs)가 존재합니다.

좋은 명세를 작성하는 데는 시간이 걸립니다.

잘못된 명세는 잘못된 구현을 만들어냅니다.

모든 프로젝트에 이 정도 수준의 엄격함이 필요한 것은 아닙니다.

또한 AI가 생성한 코드도 여전히 리뷰(Review), 테스트(Testing), 그리고 검증(Validation)이 필요합니다.

명세 기반 개발(Spec-Driven Development, SDD)은 프로세스에서 엔지니어를 제거하는 것에 관한 것이 아닙니다.

그것은 AI에게 충분한 컨텍스트(Context)를 제공하여 더 나은 엔지니어링 파트너가 되도록 만드는 것에 관한 것입니다.

마치며

Markdown이 말 그대로 프로그래밍 언어가 되고 있다고 생각하지는 않습니다.

하지만 저는 그것이 그만큼 중요한 무언가가 되고 있다고 생각합니다:

인간이 소프트웨어의 의도(Intent)를 AI에게 전달하는 언어 말입니다.

이것이 미묘한 차이처럼 들릴 수도 있습니다.

하지만 저는 그렇지 않다고 생각합니다.

이것은 엔지니어링 노력이 어디에 투입되는지, 팀이 어떻게 협업하는지, 그리고 코드베이스에서 무엇이 장기적인 신뢰할 수 있는 단일 원천(Source of Truth)이 되는지를 변화시킵니다.

AI가 계속해서 발전함에 따라, 우리는 구현(Implementation)을 작성하는 데 쓰는 시간은 줄어들고 의도(Intent)를 작성하는 데 쓰는 시간은 늘어날 것이라고 예상합니다.

그리고 그 의도는 점점 더 구조화된 명세(Structured Specifications) 안에 존재하게 될 것입니다.

아마도 우리가 새로운 프로젝트에서 가장 먼저 만들 파일은 다음과 같지 않을 수도 있습니다:

main.py

또는

App.java

그것은 아마도 단순히 다음과 같을 것입니다:

product-spec.md

참고 문헌

참고 문헌

• Martin Fowler — Exploring GenAI: Spec-Driven Development
  https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

• GitHub Spec Kit
  https://github.com/github/spec-kit

• Spec Kit Documentation
  https://github.com/github/spec-kit/blob/main/spec-driven.md

• Kiro Documentation
  https://kiro.dev/docs/specs/

• Heeki Park — Using Spec-Driven Development with Claude Code
  https://medium.com/@heekipark

• CJ Roth — Building an Elite Engineering Culture
  https://www.cjroth.com/blog/2026-02-18-building-an-elite-engineering-culture

여러분의 생각은 어떠신가요?

우리가 **명세 우선 엔지니어링(spec-first engineering)**으로 나아가고 있는 것일까요, 아니면 코드가 언제나 주된 진실 공급원(primary source of truth)으로 남을 것이라고 생각하시나요?

여러분의 개발 워크플로우에서 AI를 어떻게 사용하고 계신지 듣고 싶습니다.

저자 소개

Wallace Espindola
Senior Software Engineer | Solution Architect | AI Enthusiast

• 💼 LinkedIn: https://www.linkedin.com/in/wallaceespindola/
• 💻 GitHub: https://github.com/wallaceespindola
• 🌐 Website: https://wtechitsolutions.com