SRS — 요구사항 명세서¶

AI 에이전트에게 가장 중요한 것¶

AI 에이전트는 코드를 매우 빠르게 만들 수 있습니다.
하지만 무엇을 만들어야 하는지를 AI가 결정하게 두면 안 됩니다.

모호한 요구사항은 AI가 임의로 채웁니다.
그 결과는 작동은 하지만, 원하던 것과는 다른 무언가입니다.

"AI는 패턴을 완성하는 데 뛰어나지만, 마음을 읽지는 못한다."

명확하게 정제한 요구사항을 AI에 제공하면 모호한 지시에 비해 코드 오류가 최대 50% 감소합니다.

SRS는 AI 에이전트에게 전달할 가장 중요한 입력값입니다.

SRS란?¶

SRS = Software Requirements Specification — 소프트웨어 요구사항 명세서

이 소프트웨어가 무엇을 해야 하는지를 명확하고 검증 가능한 언어로 정의한 문서

SRS는 인간(기획자, 개발자, 고객)과 AI 에이전트 모두가 참조하는 단일 진실 공급원(Single Source of Truth)입니다.

SRS, SDD, 코드의 관계¶

SRS (무엇을 만드는가?)
  → SDD 스펙 (어떻게 만드는가?)
     → 코드 (AI 에이전트가 구현)
        → 검증 (SRS의 인수 조건과 대조)

SRS가 흔들리면 아래 모든 것이 흔들립니다.

왜 SRS를 먼저 써야 하는가¶

요구사항 없이 개발하면 생기는 일¶

고객:   "간단한 게시판 만들어줘"
AI:     (열심히 구현)
고객:   "댓글 기능은요? 파일 첨부도요? 알림은요?"

요구사항이 없으면 AI도, 개발자도 무엇이 완성인지 알 수 없습니다.

좋은 SRS의 조건¶

조건	나쁜 예	좋은 예
명확성 — 해석이 하나뿐	"빠르게 동작해야 함"	"API 응답시간 500ms 이내"
완전성 — 빠진 기능 없음	"로그인 기능 있음"	이메일+비밀번호, 소셜 로그인(구글) 명시
검증 가능 — 충족 여부 확인 가능	"편리해야 함"	"3번 이하 클릭으로 게시글 작성 가능"
일관성 — 서로 모순 없음	비로그인 허용 + 모든 기능 로그인 필요	—

요구사항의 두 가지 종류¶

기능적 요구사항 (Functional Requirements)¶

시스템이 해야 하는 일 — "~할 수 있어야 한다"

예) Todo 서비스
- 사용자는 이메일과 비밀번호로 회원가입할 수 있어야 한다
- 로그인한 사용자는 할 일을 추가할 수 있어야 한다
- 사용자는 자신의 할 일 목록만 볼 수 있어야 한다
- 할 일은 완료/미완료 상태를 가져야 한다

비기능적 요구사항 (Non-Functional Requirements)¶

시스템이 어떻게 동작해야 하는지 — 성능, 보안, 제약 조건

분류	예시
성능	API 응답시간 500ms 이내
보안	비밀번호는 bcrypt 해시 저장
가용성	월 99% 이상 서비스 유지
제약	무료 플랜은 할 일 최대 20개

AI 시대의 요구사항 작성법¶

유저 스토리 (User Story)¶

사용자 관점에서 요구사항을 서술합니다.
AI 에이전트는 이 유저 스토리를 컨텍스트로 삼아 코드를 생성합니다.

형식:
"나는 [사용자 유형]으로서,
 [기능]을 하고 싶다.
 왜냐하면 [이유] 때문이다."

예시:
나는 서비스 사용자로서,
할 일에 마감일을 설정하고 싶다.
왜냐하면 언제까지 완료해야 하는지 잊지 않고 싶기 때문이다.

인수 조건 (Acceptance Criteria)¶

유저 스토리마다 "완성됐다"는 기준을 체크리스트로 명시합니다.
이 체크리스트는 나중에 AI가 생성한 코드를 검증하는 기준이 됩니다.

유저 스토리: 할 일에 마감일을 설정하고 싶다

인수 조건:
- [ ] 할 일 추가 시 날짜 선택 가능 (선택 사항)
- [ ] 마감일이 있는 할 일은 목록에 날짜가 표시된다
- [ ] 오늘이 마감일이면 날짜가 빨간색으로 강조된다
- [ ] 마감일 지난 할 일은 별도 표시된다

인수 조건이 구체적일수록 AI가 만든 코드가 의도에 가까워집니다.

요구사항 우선순위 — MoSCoW¶

기능이 많을 때 무엇을 먼저 만들지 결정하는 기법입니다.

등급	의미	예시
Must	반드시 있어야 함	로그인, 할 일 CRUD
Should	있으면 좋음	마감일, 카테고리
Could	여유 있으면	색상 태그, 통계
Won't	이번엔 안 함	모바일 앱, 소셜 로그인

Must부터 SDD 스펙으로 넘깁니다.

SRS 문서 구조¶

1. 프로젝트 개요
   서비스명 / 목적 / 대상 사용자

2. 사용자 역할 (Actors)
   서비스를 사용하는 사람의 유형

3. 기능적 요구사항
   유저 스토리 + 인수 조건 목록 (MoSCoW 우선순위 표기)

4. 비기능적 요구사항
   성능, 보안 등 주요 제약 (2개 이상)

5. 범위 밖 (Out of Scope)
   이번 버전에서 만들지 않는 것 명시

범위 밖(Out of Scope)이 중요한 이유¶

범위 밖을 명시하지 않으면:
AI:   소셜 로그인 기능도 구현했습니다
개발자: 그건 만들지 않기로 했는데요?

"하지 않을 것"을 명확히 해야 AI도, 개발자도 낭비 없이 움직입니다.

Todo 서비스 SRS 예시¶

1. 프로젝트 개요¶

항목	내용
서비스명	MyTodo
목적	개인 할 일을 등록하고 관리하는 웹 서비스
대상 사용자	할 일 관리가 필요한 개인

2. 사용자 역할¶

역할	설명
비로그인 사용자	회원가입, 로그인만 가능
로그인 사용자	할 일 CRUD 가능

3. 기능적 요구사항¶

[Must]

US-01: 회원가입
나는 신규 사용자로서, 이메일과 비밀번호로 가입하고 싶다.
인수 조건:
  - [ ] 이메일 형식이 올바르지 않으면 가입 불가
  - [ ] 이미 가입된 이메일은 중복 가입 불가
  - [ ] 비밀번호 8자 미만이면 가입 불가
  - [ ] 가입 성공 시 로그인 페이지로 이동

US-02: 로그인
나는 가입한 사용자로서, 이메일과 비밀번호로 로그인하고 싶다.
인수 조건:
  - [ ] 틀린 정보 입력 시 오류 메시지 표시
  - [ ] 로그인 성공 시 할 일 목록으로 이동
  - [ ] 로그인 상태 7일 유지

US-03: 할 일 추가
나는 로그인한 사용자로서, 새 할 일을 추가하고 싶다.
인수 조건:
  - [ ] 제목 필수, 1자 이상 100자 이하
  - [ ] 추가 즉시 목록 최상단에 표시
  - [ ] 빈 제목으로는 추가 불가

US-04: 할 일 목록 조회
인수 조건:
  - [ ] 내가 추가한 할 일만 표시
  - [ ] 미완료 항목이 완료 항목보다 위에 표시

US-05: 완료 처리
인수 조건:
  - [ ] 체크박스로 완료/미완료 전환
  - [ ] 완료 항목 제목에 취소선 표시

US-06: 할 일 삭제
인수 조건:
  - [ ] 삭제 전 확인 메시지 표시
  - [ ] 삭제 후 목록에서 즉시 제거

4. 비기능적 요구사항¶

- 보안: 비밀번호 bcrypt 해시 저장 (평문 저장 금지)
- 보안: 타인의 할 일은 API로도 접근 불가 (403 반환)
- 성능: 목록 조회 1초 이내 (항목 100개 기준)

5. 범위 밖 (Out of Scope — v1.0)¶

- 소셜 로그인 (구글, 카카오)
- 이메일/푸시 알림
- 할 일 공유 및 협업
- 모바일 앱
- 마감일 설정

실습 미션¶

미션 1: 요구사항 분류¶

아래 항목을 기능적 / 비기능적 요구사항으로 분류하세요.

1. 사용자는 게시글에 사진을 첨부할 수 있다
2. 페이지 로딩은 2초 이내여야 한다
3. 비밀번호는 암호화해서 저장한다
4. 사용자는 댓글을 작성할 수 있다
5. 동시 접속자 500명을 처리할 수 있어야 한다
6. 회원은 자신의 게시글만 삭제할 수 있다

미션 2: 유저 스토리 + 인수 조건 작성¶

본인이 만들 서비스의 유저 스토리를 Must 3개 이상 작성하고, 각각 인수 조건을 3개 이상 추가하세요.

미션 3: 범위 밖 정의¶

미션 2의 서비스에서 이번 버전에 포함하지 않을 기능 3개 이상을 작성하고, 제외 이유를 적으세요.

미션 4: AI에게 SRS 전달해보기¶

완성한 SRS를 Claude나 ChatGPT에 붙여넣고 아래 프롬프트를 입력해보세요.

아래 SRS를 읽고, 빠진 요구사항이나 모순된 항목이 있으면 알려줘.
[SRS 내용 붙여넣기]

AI가 어떤 점을 지적하는지 확인하고, SRS를 보완하세요.

핵심 요약¶

개념	설명
SRS	무엇을 만들지 정의한 요구사항 명세서
기능적 요구사항	시스템이 해야 하는 일
비기능적 요구사항	성능, 보안, 제약 등 품질 조건
유저 스토리	사용자 관점에서 기능을 서술하는 방법
인수 조건	기능 완성 기준 — AI 코드 검증의 기준이 됨
MoSCoW	요구사항 우선순위 결정 기법
범위 밖	만들지 않을 것을 명시 — AI의 과도한 구현 방지
작성 순서	SRS → SDD 스펙 → 구현 → 인수 조건으로 검증