스펙 기반 개발(SDD)이란, 마이크로소프트가 PM에게 맡긴 역할 3가지

TL;DR

- 코드는 빨라졌는데 팀은 안 빨라졌어요: 개발자 한 명의 생산성은 올랐지만 팀 전체 결과물은 그대로였다는 게 마이크로소프트 내부 진단이었어요.
- 해법은 순서를 바꾸는 거였어요: AI에게 바로 코드를 맡기던 방식 대신, 문서로 요구사항을 먼저 맞추고 나서 실행을 넘기는 쪽으로 돌아섰어요.
- PM은 기획자에서 스펙(요구사항·목적·완료 기준을 정리한 문서)의 주인으로 바뀌었어요.

코드는 AI가 순식간에 뽑아내는데, 왜 팀 전체 진행 속도는 그대로일까요? 마이크로소프트 내부 조직이 이 질문에 답을 찾으면서 실제로 바꾼 것 세 가지를 정리해봤어요.

1️⃣ 빨라진 건 사람인데, 느려진 건 팀이었어요

AI 도구를 쓰면서 개발자 한 명이 짜는 코드량은 확실히 늘었어요. 그런데 마이크로소프트 내부 IT 조직(마이크로소프트 디지털)이 들여다보니 팀 전체가 내놓는 결과물은 그만큼 늘지 않았더라고요. 사람 사이에 일을 넘길 때마다 의도를 다시 맞춰야 하는 틈이 생기는데, 코드만 빨리 짠다고 그 틈이 저절로 메워지진 않았던 거예요.

2️⃣ 코드보다 먼저 쓰는 문서, 스펙 기반 개발

그래서 꺼낸 방법이 스펙 기반 개발(SDD, 요구사항과 완료 기준을 문서로 먼저 정리하고 그걸 기준으로 AI에게 구현을 맡기는 방식)이에요. 기존엔 일단 코드부터 던지고 고치는 바이브 코딩(직감에 의존해 즉흥적으로 코드를 짜는 방식)이 흔했는데, 이제는 사람이 아니라 AI 에이전트가 읽기 쉽게 의도를 먼저 정리해두는 쪽으로 순서를 바꿨어요. 마이크로소프트는 이걸 에이전트부터 설계하는 방식이라고 불러요.

📎 예시

마이크로소프트 내부 문서엔 속도에 방향이 없으면 그건 그냥 비싼 혼란일 뿐이라는 말이 나와요. 아무리 빨리 코드를 뽑아도 방향이 안 맞으면 처음부터 다시 짜야 하니, 결국 손해라는 뜻이죠.

3️⃣ PM은 일정표 대신 스펙을 떠안았어요

이 방식에서 제품 관리자(PM)의 자리도 달라졌어요. 예전엔 기획서 쓰고 일정 조율하는 역할이 컸는데, 이제는 그 스펙 문서 하나가 끝까지 안 틀어지게 지키는 주인이 됐어요. 애매한 부분을 정리하고, 완료 기준을 정하고, 개발자와 AI 에이전트 양쪽이 같은 걸 보고 있는지 확인하는 일이 PM의 중심 업무가 된 거예요.

결국 셋 중에서 가장 중요한 건 두 번째예요. 코드보다 스펙을 먼저 쓰는 순서를 바꾸지 않으면, 사람도 PM도 그 뒤를 못 따라가거든요.

출처

• 마이크로소프트가 밝힌 AI 네이티브 소프트웨어 개발 방식

---

💬 AI 얘기하다 점심 메뉴 얘기로 새도 괜찮은 편한 오픈채팅방이에요, 눈팅만 하셔도 좋아요 → 오픈채팅 참여하기