개발 ④ AI 네이티브 개발: 스펙이 코드를 만든다 (09/10)

AI 시대의 프로젝트 방법론 · Ep.09

코드가 산출물이던 시대가,
조용히 끝나가고 있다.

개발 ④ AI 네이티브 개발: 스펙이 코드를 만든다 · HFC Consulting

---

장애 대응 회의. 원인이 된 모듈을 어떻게 고칠지 논의가 길어지자, 젊은 개발자가 조심스럽게 말한다. "고치지 말고 다시 생성하면 안 됩니까. 스펙은 그대로 있으니까요." 회의실의 절반은 무슨 말인지 이해하지 못했고, 나머지 절반은 표정이 바뀌었다. 코드를 자산으로 여기고 평생을 일해 온 사람들 앞에서, 코드가 소모품이고 스펙이 자산이라는 세계관이 처음으로 발언권을 얻은 순간이었다.

개발방법론 3부작의 마지막은 계보의 끝이 아니라 시작점이다. AI 네이티브 개발 — 아직 이름도 정착하지 않은 이 흐름을, 같은 프레임으로 본다.

전제 — 지금까지 코드는 정본(正本)이었다

모든 기존 방법론 — 폭포수든 애자일이든 — 의 공통 전제가 하나 있다. 최종 진실은 코드에 있다는 것. 문서는 낡아도 코드는 돌아가는 그대로가 사실이었고, 그래서 코드가 자산이고 문서는 보조였다. 요구사항 정의서가 아무리 정교해도 결국 사람이 코드로 번역했고, 번역 과정의 해석이 곧 개발자의 전문성이었다.

균열 — 번역이 자동화되면 원문이 자산이 된다

스펙에서 코드로의 번역을 AI가 맡는 순간, 가치의 무게중심이 이동한다. 같은 스펙에서 코드를 몇 번이고 다시 생성할 수 있다면, 자산은 생성물이 아니라 생성의 원천 — 스펙이다. 1기 3화에서 "요구사항을 프롬프트로 썼는데 산출물이 없다"고 걱정했던 바로 그 프롬프트가, 다듬어지고 관리되면 차세대의 정본이 된다. 문제는 대부분의 조직이 스펙을 그렇게 다룰 준비가 되어 있지 않다는 것이다. 요구사항 정의서는 한 번 쓰고 버리는 문서였지, 형상관리되는 자산이 아니었다.

존속 — 요구의 명확화가 왕좌로 돌아온다

흥미로운 존속이 하나 있다. 방법론 역사에서 가장 오래된 기술 — 요구사항을 명확하게 쓰는 일 — 이 가장 새로운 방법론의 중심으로 복귀한다. 모호한 스펙은 모호한 코드를 대량 생산할 뿐이므로, 스펙의 품질이 곧 시스템의 품질이 된다. 검증과 책임도 사람의 자리로 남는다. 생성은 자동이어도 "이것이 맞는가"의 판정과 그 결과에 대한 책임은 3기 6화의 권한 경계 안에서 사람이 진다.

재구성 — 스펙 주도 개발의 골격

항목	코드 중심 (현재)	스펙 중심 (전환)
정본	코드 (문서는 보조)	스펙 (코드는 재생성 가능한 파생물)
형상관리 대상	소스코드	스펙 + 검증 테스트 + 코드의 3종 세트
수정 방식	코드를 직접 고침	스펙을 고치고 재생성, 예외만 코드 수정
개발자의 전문성	구현 기술	스펙 설계 + 생성물 검증 + Agent 지휘

스펙 주도 착수 점검 5 — ① 스펙이 형상관리되고 있는가 ② 스펙과 검증 테스트가 쌍으로 관리되는가 ③ 재생성 시의 기준선(무엇은 보존하는가)이 정의됐는가 ④ Agent의 생성 권한이 분류표 안에 있는가 ⑤ 규제·검수 환경이 재생성 방식을 수용하는가 (수용 못 하면 부분 적용부터)

예상 반론과 대응

반론 1. "시기상조입니다. 재생성한 코드가 기존 동작을 다 보존한다는 보장이 없습니다."
대응. 옳다. 그래서 이 편의 제안은 전면 전환이 아니라 준비다. 신규·독립 모듈부터 스펙-테스트 쌍 관리를 시작하고, 레거시는 코드 중심으로 남긴다. 다만 준비를 미루면 전환기가 왔을 때 스펙이라는 자산이 없는 조직이 된다 — 그것이 더 큰 리스크다.

반론 2. "개발자의 역할이 없어진다는 이야기입니까."
대응. 번역가의 일이 줄고 설계자와 감리자의 일이 는다. 체스에서 사람이 말을 직접 옮기지 않게 되어도 전략은 사람의 것이듯, 무엇을 만들지 정의하고 만들어진 것을 판정하는 자리는 오히려 넓어진다. 위협받는 것은 역할이 아니라, 역할의 정의를 갱신하지 않는 조직이다.

AI 네이티브 체크포인트 — 스펙의 형상관리 착수 / 스펙-테스트 쌍 관리 / 재생성 기준선 정의 / Agent 권한 분류 연동 / 신규 모듈부터 부분 적용, 레거시는 유지

네 개의 계보를 모두 지났다. 폭포수의 뼈대, 애자일의 정신, DevOps의 인프라, AI 네이티브의 방향. 마지막 질문이 남는다 — 이것들을 어떻게 조합하는가. 완결편이다.

※ 본 연재의 비교·재구성 원칙은 일반적 참고용이며, 조직의 표준과 사업 특성에 맞는 조정이 필요합니다.

📎 더 읽을거리
· NIST AI Risk Management Framework — AI 중심 개발 체계의 리스크 관리 참조 틀
· Architectural Decision Records (ADR) — 스펙·결정을 자산으로 관리하는 기록 양식

HFC Consulting의 관점

스펙 주도 전환은 방향은 분명하되 속도는 조직마다 달라야 합니다. 어느 모듈부터 시작할지 고민이라면 시스템 구성 개요를 보내 주십시오. 부분 적용 후보를 함께 선별해 드립니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI 시대의 프로젝트 방법론
◀ 이전 편 (08/10) 개발 ③ DevOps와 파이프라인: 자동화가 표준이 될 때
다음 편 ▶ (10/10) 하이브리드 설계 원칙
연재 전체 보기 →