AI 시대의 소프트웨어 개발 방법론: 사람 주도 AI 개발

AI로 코드를 만드는 일은 이제 특별한 일이 아니다.
간단한 웹앱, 자동화 스크립트, 내부 도구, 문서 정리 도구 정도는 자연어 설명만으로도 빠르게 만들 수 있다.

하지만 막상 작업을 해보면 한 가지 문제가 반복된다.

AI는 빠르게 만들지만, 내가 무엇을 만들고 있는지 놓치면 결과물도 쉽게 흔들린다.

처음에는 “이런 기능 만들어줘”로 시작한다.
AI는 코드를 작성한다.
조금 고쳐달라고 하면 또 고친다.
그런데 어느 순간부터 요구사항이 섞이고, 이전 결정이 사라지고, 기능의 기준이 애매해진다.

결국 문제는 AI의 속도가 아니라 개발을 이끄는 기준이 없다는 것이다.

이 글은 내가 정리하고 있는 사람 주도 AI 소프트웨어 개발 방법론의 첫 번째 글이다.
이번 글에서는 전체 컨셉과 목적을 설명하고, 이후 글에서 요구사항, 분석, 설계, MVP, 검증 단계를 하나씩 다룰 예정이다.

---

왜 방법론이 필요한가

AI 개발 도구를 쓰면 구현 속도는 확실히 빨라진다.
하지만 속도가 빨라진 만큼 다음 문제가 더 자주 생긴다.

• 요구사항이 명확하지 않은 상태로 구현이 시작된다.
• 대화 중 결정한 내용이 문서에 남지 않는다.
• 기능을 추가할수록 처음 의도와 달라진다.
• AI가 이전 맥락을 잘못 기억하거나 누락한다.
• 검증 없이 “그럴듯한 결과”를 완료로 착각한다.

AI가 코드를 잘 만든다고 해서 소프트웨어 개발의 기본 단계가 사라지는 것은 아니다.

오히려 AI를 제대로 쓰려면 사람이 더 명확하게 해야 한다.

• 무엇을 만들 것인가
• 왜 만드는가
• 어디까지 만들 것인가
• 어떤 기준이면 완료인가
• 무엇은 이번 버전에서 하지 않을 것인가
• 변경과 결정은 어디에 기록할 것인가

이 기준이 있어야 AI는 단순한 코드 생성기가 아니라 개발을 돕는 작업 에이전트가 된다.

---

사람 주도 AI 개발이란

사람 주도 AI 개발은 말 그대로 사람이 방향과 판단 기준을 잡고, AI가 정리와 구현과 검증을 돕는 개발 방식이다.

핵심은 AI에게 모든 판단을 맡기지 않는 것이다.

AI는 빠르게 정리하고, 코드를 만들고, 문서를 비교하고, 누락을 찾는 데 강하다.
하지만 “이 제품이 왜 필요한가”, “이번 버전에서 무엇을 제외할 것인가”, “이 결정이 비즈니스나 사용자에게 맞는가” 같은 판단은 사람이 해야 한다.

그래서 이 방법론에서는 역할을 이렇게 나눈다.

                       역할                                                                             책임

사람	목적, 우선순위, 최종 판단
작업 에이전트	문서 작성, 설계 보강, 구현, 로그 기록
검증 에이전트	독립 검증, 불일치 탐지, 누락 확인

AI는 개발을 대신하는 존재라기보다, 사람이 정한 기준을 빠르게 실행하고 점검하는 협업자에 가깝다.

---

전체 흐름

이 방법론의 기본 흐름은 다음과 같다.

의도 정의
-> 요구사항 정의
-> 분석
-> 관계와 모순 정리
-> 설계
-> MVP 범위 고정
-> 구현
-> 검증
-> 로그 기록
-> 피드백
-> 규칙/템플릿 개선

각 단계는 다음 질문에 답하기 위한 것이다.

                             단계                                                                      핵심 질문

의도 정의	왜 이걸 만드는가?
요구사항 정의	무엇을 만들어야 하는가?
분석	이것은 어떤 문제 구조인가?
관계 정리	요구사항끼리 어떻게 연결되는가?
설계	어떤 구조로 만들 것인가?
MVP	첫 버전은 어디까지인가?
구현	실제로 무엇을 바꿀 것인가?
검증	기준대로 되었는가?
로그	왜 그렇게 결정했는가?
피드백	다음에는 무엇을 개선할 것인가?

중요한 점은 이 흐름이 거창한 대형 프로젝트에만 필요한 것이 아니라는 점이다.
개인 홈페이지, 작은 업무 도구, 자동화 스크립트에도 적용할 수 있다.

작은 프로젝트일수록 문서는 짧아도 된다.
다만 기준은 있어야 한다.

---

이 방법론에서 중요한 산출물

이 방식에서는 대화만 믿지 않고, 기준을 문서로 남긴다.

기본 산출물은 다음과 같다.

README.md
AGENTS.md
docs/session-start.md
docs/requirements.md
docs/analysis.md
docs/system-design.md
docs/mvp-spec.md
docs/verification-agent.md
logs/conversation-log.md

각 문서의 역할은 분명히 나눈다.

                                       문서                                                                      역할

requirements.md	무엇을 만들지 정의
analysis.md	요구사항을 문제 구조로 분석
system-design.md	어떤 구조로 만들지 정의
mvp-spec.md	첫 버전의 정확한 범위 정의
verification-agent.md	검증 기준 정의
conversation-log.md	결정과 변경 이력 기록
AGENTS.md	작업 에이전트가 따라야 할 규칙

이렇게 나누는 이유는 간단하다.

요구사항, 분석, 설계, 로그가 한 문서에 섞이면 나중에 기준을 복원하기 어렵다.
AI에게 다시 작업을 맡길 때도 어떤 문서를 우선해야 하는지 모호해진다.

문서의 목적이 분리되어 있어야 다음 세션에서도 같은 기준으로 이어갈 수 있다.

---

검증은 왜 따로 두는가

AI와 함께 작업할 때 특히 중요한 단계가 검증이다.

작업을 한 에이전트는 자신이 만든 결과를 그럴듯하게 설명할 수 있다.
하지만 설명이 그럴듯하다고 해서 결과가 맞는 것은 아니다.

그래서 검증은 가능하면 독립적으로 수행한다.

검증 기준은 네 가지로 나눈다.

1. 산출물 구조 검증
2. 내용 정합성 검증
3. 방법론/인수인계 검증
4. 통합 흐름 검증

나눠서 보면 세부 문제를 잘 찾을 수 있고, 마지막에 통합 흐름으로 보면 전체 연결이 끊기지 않았는지 확인할 수 있다.

또한 검증 후 수정은 다음 흐름을 따른다.

분할 검증
-> 발견사항 목록화와 우선순위 결정
-> 묶음 수정
-> 통합 검증
-> 연결 문제 수정
-> 최종 스모크 검증

즉, 문제를 발견하자마자 하나씩 고치기보다 먼저 모아서 우선순위를 정한다.
그 다음 같은 원인을 가진 문제를 묶어서 수정하고, 마지막에 전체 흐름을 다시 확인한다.

---

이 방법론의 목적

이 방법론의 목적은 AI를 쓰면서도 개발 기준을 잃지 않는 것이다.

AI가 코드를 빠르게 만드는 시대에는 “얼마나 빨리 만들었는가”보다 “무엇을 기준으로 만들었는가”가 더 중요해진다.

사람 주도 AI 개발은 다음을 목표로 한다.

• 요구사항을 명확히 기록한다.
• 분석을 통해 문제 구조를 드러낸다.
• MVP 범위를 분명히 정한다.
• 구현 전에 판단 기준을 만든다.
• 검증을 통해 누락과 불일치를 찾는다.
• 결정과 변경 이유를 로그로 남긴다.
• 반복되는 방식은 규칙과 템플릿으로 만든다.

결국 핵심은 하나다.

AI가 빠르게 달릴 수 있도록, 사람이 방향과 기준을 세운다.

---

다음 글

다음 글에서는 첫 번째 단계인 요구사항 정의를 다룰 예정이다.

단순히 “기능 목록을 적는 것”이 아니라, AI와 협업하기 위해 요구사항을 어떻게 나누고, ID를 붙이고, MVP와 후속 범위를 어떻게 구분할지 정리해보겠다.