AI 시대의 소프트웨어 개발 방법론: 요구사항 정의 편

 

이전 글에서는 사람 주도 AI 개발의 전체 흐름을 정리했다.

핵심은 간단했다.

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

이번 글에서는 그 첫 번째 실무 단계인 요구사항 정의를 다룬다.

AI와 함께 개발할 때 요구사항은 단순한 기능 목록이 아니다.
AI가 무엇을 만들어야 하는지, 어디까지 만들어야 하는지, 무엇을 만들면 안 되는지를 판단하는 기준이다.

요구사항이 흔들리면 구현도 흔들린다.
반대로 요구사항이 잘 정리되어 있으면 AI는 훨씬 안정적으로 작업한다.

---

왜 요구사항 정의가 더 중요해졌는가

AI 개발 도구를 쓰면 구현 속도는 빠르다.

예전에는 요구사항이 조금 애매해도 구현 과정에서 시간이 걸렸기 때문에 중간에 생각을 정리할 여지가 있었다.
하지만 AI는 다르다.

요구사항이 애매한 상태에서도 빠르게 코드를 만든다.
문제는 그 코드가 “내가 원한 것”인지, “AI가 추측한 것”인지 구분하기 어렵다는 점이다.

자주 생기는 문제는 다음과 같다.

• 처음 말한 의도와 다른 기능이 구현된다.
• 대화 중 나온 결정이 다음 작업에서 사라진다.
• 비슷한 기능이 중복으로 만들어진다.
• MVP에 들어가지 않아야 할 기능이 섞인다.
• 수정할수록 전체 기준이 흐려진다.
• 검증할 때 무엇이 맞는지 판단하기 어렵다.

결국 요구사항 정의는 AI에게 일을 시키기 위한 문장이 아니라,
사람과 AI가 같은 기준으로 작업하기 위한 계약에 가깝다.

---

요구사항은 기능 목록이 아니다

요구사항을 적는다고 하면 보통 이런 식으로 시작한다.

- 로그인 기능
- 게시글 작성 기능
- 검색 기능
- 관리자 화면

이런 목록도 출발점으로는 괜찮다.
하지만 AI와 협업하기에는 부족하다.

왜냐하면 각각의 항목이 너무 많은 해석을 허용하기 때문이다.

예를 들어 “검색 기능”이라고만 쓰면 AI는 여러 가지를 추측해야 한다.

• 제목만 검색하는가?
• 본문도 검색하는가?
• 태그도 검색하는가?
• 부분 일치를 허용하는가?
• 대소문자를 구분하는가?
• 삭제된 항목도 검색 대상인가?
• 검색 결과는 어디에 표시하는가?
• 검색 조건을 초기화할 수 있는가?

사람은 머릿속으로 대충 알고 있다고 생각하지만, AI는 그 기준을 모른다.
그래서 요구사항은 기능 이름보다 조금 더 구체적이어야 한다.

---

좋은 요구사항의 기본 형태

내가 사용하는 기본 형태는 다음과 같다.

ID
제목
설명
단계
우선순위
유형
상태

예를 들면 이렇게 쓴다.

ID: REQ-001
제목: 요구사항 등록
설명: 사용자는 화면에서 새 요구사항을 등록할 수 있어야 한다.
단계: MVP
우선순위: high
유형: feature
상태: approved

여기서 중요한 것은 문장을 복잡하게 쓰는 것이 아니다.
각 요구사항이 독립적으로 추적 가능해야 한다는 점이다.

특히 ID가 중요하다.

요구사항에 ID가 없으면 나중에 이런 대화가 된다.

검색 기능 수정해줘.
아니, 그 검색 말고 왼쪽 목록에 있는 검색.
아니, 삭제된 항목 포함할 때 검색되는 그 부분.

반면 ID가 있으면 이렇게 말할 수 있다.

REQ-031의 검색 대상에 태그를 포함해줘.
REQ-022B 검증에서 그래프 제외 조건도 확인해줘.
REQ-035C는 원본 파일 삭제가 아니라 등록 삭제만 해야 해.

AI에게도 훨씬 명확하고, 사람도 변경 이력을 따라가기 쉽다.

---

요구사항 ID를 붙이는 이유

요구사항 ID는 단순한 번호가 아니다.
개발 전체를 연결하는 기준점이다.

요구사항 ID가 있으면 다음을 연결할 수 있다.

• 요구사항
• 분석 내용
• 설계 요소
• API
• UI 화면
• 테스트
• 검증 결과
• 변경 로그

예를 들어 다음처럼 추적할 수 있다.

REQ-035 프로젝트 등록과 등록 해제
-> API: POST /api/projects, DELETE /api/projects/{id}
-> UI: 프로젝트 관리 패널
-> 테스트: 프로젝트 등록/삭제 테스트
-> 검증: api-smoke-tested, pending-browser-test

이렇게 되면 “기능을 만들었다”에서 끝나지 않는다.
어떤 요구사항이 어디에 반영되었고, 무엇이 아직 검증되지 않았는지 알 수 있다.

AI와 협업할수록 이 추적성이 중요해진다.

AI는 코드를 빠르게 바꾸지만, 바뀐 코드가 어떤 요구사항을 만족하는지 스스로 안정적으로 관리하지 못한다.
그 연결은 사람이 기준을 만들고, AI가 문서와 테스트로 보조하게 해야 한다.

---

요구사항은 단계로 나눈다

모든 요구사항을 한 번에 만들려고 하면 프로젝트가 쉽게 커진다.

그래서 요구사항에는 단계를 붙인다.

MVP
Future
Optional
Out of Scope

나는 보통 이렇게 구분한다.

                       단계                                                            의미  

MVP	첫 버전에 반드시 들어갈 것
Future	필요하지만 첫 버전에서는 제외할 것
Optional	있으면 좋지만 필수는 아닌 것
Out of Scope	이번 프로젝트에서는 하지 않을 것

이 구분이 없으면 AI는 사용자가 말한 모든 것을 지금 구현하려고 한다.

예를 들어 요구사항 관리 도구를 만든다고 할 때, 처음부터 다음 기능을 모두 넣고 싶어질 수 있다.

• 요구사항 CRUD
• 관계 관리
• 그래프 시각화
• Mermaid 다이어그램
• 사용자 계정
• 권한 관리
• DB 저장
• 변경 이력
• 알림
• 외부 프로젝트 연동
• 배포 자동화

하지만 첫 버전에서 중요한 것은 “작동하는 핵심 흐름”이다.
그래서 MVP를 정해야 한다.

MVP:
- 요구사항 등록, 수정, 삭제
- 요구사항 관계 등록, 수정, 삭제
- 요구사항 그래프 조회
- 기본 검증

Future:
- 사용자 계정
- 권한 관리
- RDBMS 전환
- 저장형 보기

이렇게 나누면 AI에게도 명확하게 말할 수 있다.

이번 구현에서는 MVP 항목만 반영하고, Future 항목은 문서에만 남겨줘.

이 한 문장이 프로젝트 범위를 지켜준다.

---

상위 요구사항과 세부 요구사항을 나눈다

요구사항은 너무 크면 구현하기 어렵고, 너무 작으면 관리하기 어렵다.

그래서 상위 요구사항과 세부 요구사항을 나누는 방식이 유용하다.

예를 들어 다음과 같이 나눌 수 있다.

REQ-035 프로젝트 등록과 등록 해제
REQ-035A 프로젝트 등록 입력
REQ-035B 프로젝트 등록 검증
REQ-035C 외부 프로젝트 등록 삭제
REQ-035D 기본 프로젝트 표시 설정
REQ-035E 프로젝트 루트 선택과 등록값 추천

상위 요구사항은 사용자의 목적을 표현한다.
세부 요구사항은 구현과 검증이 가능한 단위로 나눈다.

이 구조가 있으면 AI에게 일을 나누어 맡기기 좋다.

REQ-035A부터 REQ-035C까지만 구현해줘.
REQ-035E는 보류하고 Future로 남겨줘.
REQ-035 전체가 설계와 추적표에 연결되어 있는지 검증해줘.

요구사항을 이렇게 나누면 기능 추가도 깔끔해진다.

처음에는 프로젝트 ID와 경로를 직접 입력하는 방식만 있었다가, 나중에 “디렉터리 선택과 자동 추천도 있으면 좋겠다”는 생각이 들 수 있다.
그때 기존 요구사항을 애매하게 고치는 대신 REQ-035E처럼 세부 요구사항을 추가하면 된다.

---

요구사항에는 하지 않을 것도 적어야 한다

요구사항 정의에서 자주 빠지는 것이 있다.

바로 “하지 않을 것”이다.

사람은 암묵적으로 알고 있다고 생각하지만, AI는 그렇지 않다.
말하지 않으면 AI는 필요하다고 판단한 기능을 추가할 수 있다.

예를 들어 프로젝트 등록/삭제 기능을 만든다고 할 때, “삭제”라는 말은 위험하다.

삭제가 의미하는 것이 무엇인지 분명히 해야 한다.

사용자는 등록된 외부 프로젝트를 목록에서 삭제할 수 있어야 한다.
삭제는 원본 프로젝트 파일을 삭제하지 않아야 한다.

이렇게 써야 한다.

그렇지 않으면 AI가 실제 디렉터리를 삭제하는 기능으로 해석할 여지가 생긴다.

요구사항에서는 특히 다음을 명확히 해야 한다.

• 삭제가 실제 삭제인지 등록 해제인지
• 읽기 전용인지 쓰기 가능한지
• 기본값은 무엇인지
• 오류 상황에서는 어떻게 해야 하는지
• 이번 버전에서 제외할 기능은 무엇인지

AI와 협업할 때는 애매함이 곧 버그가 된다.

---

요구사항 관계도 관리한다

요구사항은 서로 독립적이지 않다.

어떤 요구사항은 다른 요구사항을 포함하고, 어떤 요구사항은 더 작은 요구사항으로 분해된다.
또 어떤 요구사항은 서로 충돌하거나, 하나가 바뀌면 다른 것도 영향을 받는다.

그래서 관계를 기록하는 것이 좋다.

예를 들면 다음과 같다.

REQ-034 includes REQ-035
REQ-035 breaks_down_to REQ-035A
REQ-035 breaks_down_to REQ-035B
REQ-035 breaks_down_to REQ-035C

이렇게 하면 “여러 프로젝트 조회”라는 요구사항 안에 “프로젝트 등록과 등록 해제”가 포함된다는 것을 알 수 있다.

관계가 있으면 변경 영향도 확인하기 쉽다.

예를 들어 REQ-035를 수정하면 그 아래의 REQ-035A부터 REQ-035E까지 같이 봐야 한다.
반대로 REQ-035E만 수정한다면 디렉터리 선택과 추천 기능만 집중해서 보면 된다.

AI에게도 이런 식으로 요청할 수 있다.

REQ-035E와 직접 연결된 요구사항만 보고 영향 범위를 검토해줘.

이것이 가능하려면 요구사항 관계가 문서나 데이터로 남아 있어야 한다.

---

요구사항 문서와 로그를 분리한다

요구사항을 정리하다 보면 대화 내용, 결정 이유, 변경 이력이 함께 섞이기 쉽다.

하지만 현재 기준과 과거 대화는 분리하는 것이 좋다.

나는 보통 이렇게 나눈다.

docs/requirements.md
logs/conversation-log.md

requirements.md에는 현재 기준만 둔다.
즉, 지금 이 프로젝트가 만족해야 하는 요구사항을 정리한다.

반면 conversation-log.md에는 왜 그렇게 결정했는지 남긴다.

예를 들면 다음과 같다.

requirements.md:
REQ-035C 사용자는 등록된 외부 프로젝트를 목록에서 삭제할 수 있어야 하며, 삭제는 원본 프로젝트 파일을 삭제하지 않아야 한다.

conversation-log.md:
사용자가 다른 PC에서 외부 프로젝트를 확인하는 흐름을 요청했다.
프로젝트 삭제는 원본 파일 삭제가 아니라 로컬 설정에서 등록만 제거하는 의미로 결정했다.

이렇게 나누면 나중에 AI에게 다시 작업을 맡길 때도 기준이 흔들리지 않는다.

AI에게는 현재 기준을 먼저 읽게 하고, 필요할 때 로그를 참고하게 하면 된다.

---

요구사항 정의 단계에서 AI에게 시킬 일

요구사항 정의는 사람이 다 써야 하는 작업이 아니다.
AI를 잘 활용하면 빠르게 초안을 만들고 누락을 찾을 수 있다.

다만 최종 판단은 사람이 해야 한다.

AI에게 시키기 좋은 일은 다음과 같다.

• 대화 내용을 요구사항 목록으로 정리하기
• 요구사항에 ID 붙이기
• 상위 요구사항과 세부 요구사항 나누기
• MVP와 Future 구분 제안하기
• 중복 요구사항 찾기
• 애매한 표현 찾기
• 검증 가능한 문장으로 바꾸기
• 요구사항 간 관계 정리하기
• 추적표 초안 만들기

예를 들어 이렇게 요청할 수 있다.

지금까지 대화 내용을 기준으로 요구사항을 정리해줘.
각 요구사항에는 ID, 제목, 설명, 단계, 우선순위를 붙여줘.
MVP와 Future를 구분하고, 애매한 요구사항은 질문 목록으로 따로 빼줘.

또는 이렇게 요청할 수도 있다.

REQ-035를 세부 요구사항으로 분해해줘.
각 세부 요구사항은 구현과 검증이 가능한 단위로 나눠줘.
삭제 기능은 원본 파일 삭제가 아니라 등록 해제라는 점을 명확히 반영해줘.

AI는 이런 정리 작업에 강하다.
하지만 AI가 제안한 요구사항을 그대로 확정하면 안 된다.

사람이 봐야 할 것은 이것이다.

• 정말 필요한가?
• 이번 버전에 들어가야 하는가?
• 사용자의 목적과 맞는가?
• 너무 크거나 작지 않은가?
• 검증 가능한가?
• 빠진 예외 상황은 없는가?

---

요구사항 정의 체크리스트

요구사항을 작성한 뒤에는 다음을 확인한다.

1. 각 요구사항에 ID가 있는가?
2. 요구사항이 사용자의 행동이나 시스템 책임으로 표현되어 있는가?
3. MVP와 Future가 구분되어 있는가?
4. 삭제, 읽기 전용, 오류 처리처럼 위험한 동작이 명확한가?
5. 상위 요구사항과 세부 요구사항이 연결되어 있는가?
6. 중복되거나 서로 충돌하는 요구사항이 없는가?
7. 구현 가능한 단위로 나뉘어 있는가?
8. 검증 기준을 만들 수 있는가?
9. 현재 기준 문서와 대화 로그가 분리되어 있는가?
10. AI가 다음 세션에서 읽어도 같은 의미로 이해할 수 있는가?

이 체크리스트를 통과하지 못하면 바로 구현으로 가면 안 된다.

AI는 빠르게 만들 수 있기 때문에, 잘못된 요구사항도 빠르게 구현해버린다.
그래서 구현 전에 요구사항을 한 번 멈춰서 보는 과정이 필요하다.

---

요구사항 정의의 목표

요구사항 정의의 목표는 완벽한 문서를 만드는 것이 아니다.

목표는 이것이다.

AI와 사람이 같은 기준으로 개발을 이어갈 수 있게 만드는 것.

요구사항은 길 필요가 없다.
작은 프로젝트라면 짧아도 된다.

하지만 다음은 반드시 있어야 한다.

• 무엇을 만들 것인가
• 왜 필요한가
• 어디까지가 이번 버전인가
• 무엇은 하지 않을 것인가
• 어떻게 검증할 것인가
• 변경되면 어디에 기록할 것인가

이 기준이 있으면 AI는 단순히 코드를 생성하는 도구가 아니라, 요구사항을 따라 움직이는 작업 에이전트가 된다.

---

다음 글

다음 글에서는 요구사항을 바탕으로 분석 단계를 다룰 예정이다.

요구사항을 단순 목록으로 두는 것이 아니라,
어떤 문제 구조인지, 어떤 개념이 반복되는지, 어떤 관계와 충돌이 있는지를 정리하는 방법을 살펴보겠다.

요구사항이 “무엇을 만들 것인가”를 정리하는 단계라면,
분석은 “이 문제를 어떻게 이해할 것인가”를 정리하는 단계다.

---

참고한 원문: https://barisein.tistory.com/1326