[SWE-001][입문] 큰 요구사항을 작은 기능으로 나누기
페이지 정보
본문
[이번 수업]
‘학습 기록 서비스를 만들어 주세요’라는 문장은 방향은 알려 주지만 바로 개발하기에는 너무 큽니다. 이번 수업에서는 큰 요구사항을 사용자가 확인할 수 있는 작은 기능으로 나누고, 각 기능의 완료 조건을 적습니다. 기능을 작게 나누면 한꺼번에 모든 것을 추측하지 않고, 실제 결과를 일찍 확인해 다음 결정을 고칠 수 있습니다.
[선수지식]
프로그램이 입력을 받아 처리하고 결과를 보여 준다는 정도만 알면 됩니다. 프로젝트 관리 도구나 특정 개발 방법론을 사용해 본 경험은 필요하지 않습니다.
[학습목표]
1. 요구사항, 기능, 구현 작업의 차이를 설명한다.
2. 큰 요구사항을 사용자 가치가 남는 작은 기능으로 나눈다.
3. 조건·행동·관찰 가능한 결과로 완료 기준을 작성한다.
[핵심개념]
요구사항은 사용자가 원하는 결과나 시스템이 지켜야 할 조건입니다. 기능은 그 요구를 충족해 사용자가 얻는 동작 단위이고, 구현 작업은 화면·서버·데이터베이스처럼 개발자가 만드는 내부 작업입니다. ‘화면 만들기’와 ‘테이블 만들기’만 따로 끝내면 사용자는 아직 아무 가치도 얻지 못합니다. 반면 ‘제목을 입력해 학습 항목 한 개를 추가하고 목록에서 확인한다’는 작은 기능은 화면부터 저장까지 세로로 얇게 연결한 조각입니다.
Scrum Guide는 제품 백로그 정제를 큰 항목을 더 작고 정밀한 항목으로 나누고 설명·순서·크기 같은 세부 정보를 더하는 지속 활동으로 설명합니다. 작은 항목의 기준은 무조건 코드 몇 줄이 아닙니다. 한 번에 이해할 수 있고, 독립적으로 결과를 확인할 수 있으며, 팀이 정한 짧은 기간 안에 완료 가능한지가 중요합니다.
나누는 순서는 다음과 같습니다. ① 누가 어떤 문제를 해결하려는지 한 문장으로 적습니다. ② 사용자가 목표를 이루는 흐름을 처음부터 끝까지 나열합니다. ③ 각 단계에서 가장 단순한 정상 동작 하나를 먼저 떼어 냅니다. ④ 예외, 편의 기능, 성능 개선은 별도 항목으로 둡니다. ⑤ 각 항목에 완료 조건을 붙입니다.
완료 조건은 ‘주어진 상태(Given)에서 어떤 행동(When)을 하면 어떤 관찰 가능한 결과(Then)가 나온다’로 쓰면 명확해집니다. Cucumber의 Gherkin 참고 문서도 이 흐름을 초기 상황, 사건, 기대 결과로 설명합니다. 내부 테이블 값보다 사용자가 보는 목록·메시지처럼 밖에서 확인 가능한 결과를 적으세요.
[따라하기]
큰 요구사항을 ‘사용자가 학습 항목을 관리한다’로 정하고 다음을 backlog.py로 저장합니다.
features = [
{
"name": "학습 항목 추가",
"value": "공부할 내용을 잊지 않는다",
"done": "빈 목록에서 제목을 입력하면 항목 한 개가 보인다",
},
{
"name": "학습 항목 완료",
"value": "공부한 내용을 구분한다",
"done": "미완료 항목을 선택하면 완료 표시가 보인다",
},
]
for number, feature in enumerate(features, start=1):
assert all(feature.values())
print(f"{number}. {feature['name']} -> {feature['done']}")
Windows에서는 py backlog.py, macOS와 Linux에서는 python3 backlog.py를 실행합니다. 예상 결과는 다음 두 줄입니다.
1. 학습 항목 추가 -> 빈 목록에서 제목을 입력하면 항목 한 개가 보인다
2. 학습 항목 완료 -> 미완료 항목을 선택하면 완료 표시가 보인다
assert는 이름·가치·완료 조건 중 빈 값이 있으면 실행을 멈춥니다.
[흔한 실수]
‘프런트엔드, 백엔드, DB’처럼 기술 계층만 나누지 마세요. 각 조각이 끝나도 사용자가 확인할 동작이 없기 때문입니다. ‘로그인 기능’처럼 여전히 큰 표현도 정상 로그인, 잘못된 입력 안내, 로그아웃 등 관찰 가능한 행동으로 더 나눌 수 있습니다. 반대로 버튼 색 하나처럼 사용자 가치와 무관한 수준까지 잘게 쪼개거나, 완료 조건 없이 제목만 짧게 만드는 것도 피하세요.
[보안 주의]
작게 출시한다는 이유로 인증, 권한 검사, 입력 검증, 개인정보 보호를 마지막으로 미루면 안 됩니다. 민감한 기능은 각 조각의 완료 조건에 ‘권한 없는 사용자는 볼 수 없다’, ‘입력 길이와 형식을 검사한다’, ‘비밀값을 로그에 남기지 않는다’ 같은 방어 조건을 포함하세요. 실습에는 실제 개인정보나 운영 서비스 계정을 넣지 말고 로컬의 가상 데이터만 사용합니다.
[직접 해볼 과제]
‘사용자가 독서 기록을 관리한다’를 책 추가, 목록 보기, 읽음 표시의 세 기능으로 나누세요. 각 기능에 사용자 가치 한 줄과 Given·When·Then 완료 조건을 하나씩 적습니다. 그다음 첫 기능을 더 작은 정상 동작으로 만들 수 있는지 검토하세요.
[확인문제]
1. 기능과 구현 작업은 어떻게 다른가요?
2. 작은 기능에도 사용자 가치가 남아야 하는 이유는 무엇인가요?
3. 완료 조건의 Then에는 내부 구현보다 무엇을 적는 것이 좋은가요?
[다음 학습]
순환 커리큘럼의 다음 수업은 MOBILE-001 ‘모바일 앱과 웹앱의 차이’입니다. 소프트웨어 공학 트랙에서는 SWE-002 ‘읽기 쉬운 이름·함수·모듈’로 이어집니다.
[공식 참고 자료]
ISO/IEC/IEEE 29148:2018 요구사항 공학 표준 개요
https://www.iso.org/standard/72089.html
The 2020 Scrum Guide
https://scrumguides.org/scrum-guide.html
Principles behind the Agile Manifesto
https://agilemanifesto.org/principles.html
Cucumber Gherkin Reference
https://cucumber.io/docs/gherkin/reference/
‘학습 기록 서비스를 만들어 주세요’라는 문장은 방향은 알려 주지만 바로 개발하기에는 너무 큽니다. 이번 수업에서는 큰 요구사항을 사용자가 확인할 수 있는 작은 기능으로 나누고, 각 기능의 완료 조건을 적습니다. 기능을 작게 나누면 한꺼번에 모든 것을 추측하지 않고, 실제 결과를 일찍 확인해 다음 결정을 고칠 수 있습니다.
[선수지식]
프로그램이 입력을 받아 처리하고 결과를 보여 준다는 정도만 알면 됩니다. 프로젝트 관리 도구나 특정 개발 방법론을 사용해 본 경험은 필요하지 않습니다.
[학습목표]
1. 요구사항, 기능, 구현 작업의 차이를 설명한다.
2. 큰 요구사항을 사용자 가치가 남는 작은 기능으로 나눈다.
3. 조건·행동·관찰 가능한 결과로 완료 기준을 작성한다.
[핵심개념]
요구사항은 사용자가 원하는 결과나 시스템이 지켜야 할 조건입니다. 기능은 그 요구를 충족해 사용자가 얻는 동작 단위이고, 구현 작업은 화면·서버·데이터베이스처럼 개발자가 만드는 내부 작업입니다. ‘화면 만들기’와 ‘테이블 만들기’만 따로 끝내면 사용자는 아직 아무 가치도 얻지 못합니다. 반면 ‘제목을 입력해 학습 항목 한 개를 추가하고 목록에서 확인한다’는 작은 기능은 화면부터 저장까지 세로로 얇게 연결한 조각입니다.
Scrum Guide는 제품 백로그 정제를 큰 항목을 더 작고 정밀한 항목으로 나누고 설명·순서·크기 같은 세부 정보를 더하는 지속 활동으로 설명합니다. 작은 항목의 기준은 무조건 코드 몇 줄이 아닙니다. 한 번에 이해할 수 있고, 독립적으로 결과를 확인할 수 있으며, 팀이 정한 짧은 기간 안에 완료 가능한지가 중요합니다.
나누는 순서는 다음과 같습니다. ① 누가 어떤 문제를 해결하려는지 한 문장으로 적습니다. ② 사용자가 목표를 이루는 흐름을 처음부터 끝까지 나열합니다. ③ 각 단계에서 가장 단순한 정상 동작 하나를 먼저 떼어 냅니다. ④ 예외, 편의 기능, 성능 개선은 별도 항목으로 둡니다. ⑤ 각 항목에 완료 조건을 붙입니다.
완료 조건은 ‘주어진 상태(Given)에서 어떤 행동(When)을 하면 어떤 관찰 가능한 결과(Then)가 나온다’로 쓰면 명확해집니다. Cucumber의 Gherkin 참고 문서도 이 흐름을 초기 상황, 사건, 기대 결과로 설명합니다. 내부 테이블 값보다 사용자가 보는 목록·메시지처럼 밖에서 확인 가능한 결과를 적으세요.
[따라하기]
큰 요구사항을 ‘사용자가 학습 항목을 관리한다’로 정하고 다음을 backlog.py로 저장합니다.
features = [
{
"name": "학습 항목 추가",
"value": "공부할 내용을 잊지 않는다",
"done": "빈 목록에서 제목을 입력하면 항목 한 개가 보인다",
},
{
"name": "학습 항목 완료",
"value": "공부한 내용을 구분한다",
"done": "미완료 항목을 선택하면 완료 표시가 보인다",
},
]
for number, feature in enumerate(features, start=1):
assert all(feature.values())
print(f"{number}. {feature['name']} -> {feature['done']}")
Windows에서는 py backlog.py, macOS와 Linux에서는 python3 backlog.py를 실행합니다. 예상 결과는 다음 두 줄입니다.
1. 학습 항목 추가 -> 빈 목록에서 제목을 입력하면 항목 한 개가 보인다
2. 학습 항목 완료 -> 미완료 항목을 선택하면 완료 표시가 보인다
assert는 이름·가치·완료 조건 중 빈 값이 있으면 실행을 멈춥니다.
[흔한 실수]
‘프런트엔드, 백엔드, DB’처럼 기술 계층만 나누지 마세요. 각 조각이 끝나도 사용자가 확인할 동작이 없기 때문입니다. ‘로그인 기능’처럼 여전히 큰 표현도 정상 로그인, 잘못된 입력 안내, 로그아웃 등 관찰 가능한 행동으로 더 나눌 수 있습니다. 반대로 버튼 색 하나처럼 사용자 가치와 무관한 수준까지 잘게 쪼개거나, 완료 조건 없이 제목만 짧게 만드는 것도 피하세요.
[보안 주의]
작게 출시한다는 이유로 인증, 권한 검사, 입력 검증, 개인정보 보호를 마지막으로 미루면 안 됩니다. 민감한 기능은 각 조각의 완료 조건에 ‘권한 없는 사용자는 볼 수 없다’, ‘입력 길이와 형식을 검사한다’, ‘비밀값을 로그에 남기지 않는다’ 같은 방어 조건을 포함하세요. 실습에는 실제 개인정보나 운영 서비스 계정을 넣지 말고 로컬의 가상 데이터만 사용합니다.
[직접 해볼 과제]
‘사용자가 독서 기록을 관리한다’를 책 추가, 목록 보기, 읽음 표시의 세 기능으로 나누세요. 각 기능에 사용자 가치 한 줄과 Given·When·Then 완료 조건을 하나씩 적습니다. 그다음 첫 기능을 더 작은 정상 동작으로 만들 수 있는지 검토하세요.
[확인문제]
1. 기능과 구현 작업은 어떻게 다른가요?
2. 작은 기능에도 사용자 가치가 남아야 하는 이유는 무엇인가요?
3. 완료 조건의 Then에는 내부 구현보다 무엇을 적는 것이 좋은가요?
[다음 학습]
순환 커리큘럼의 다음 수업은 MOBILE-001 ‘모바일 앱과 웹앱의 차이’입니다. 소프트웨어 공학 트랙에서는 SWE-002 ‘읽기 쉬운 이름·함수·모듈’로 이어집니다.
[공식 참고 자료]
ISO/IEC/IEEE 29148:2018 요구사항 공학 표준 개요
https://www.iso.org/standard/72089.html
The 2020 Scrum Guide
https://scrumguides.org/scrum-guide.html
Principles behind the Agile Manifesto
https://agilemanifesto.org/principles.html
Cucumber Gherkin Reference
https://cucumber.io/docs/gherkin/reference/
- 이전글[MOBILE-001][입문] 모바일 앱과 웹앱의 차이 이해하기 26.08.29
- 다음글[DATA-001][입문] 정형·반정형·비정형 데이터 구분하기 26.08.29
댓글목록
등록된 댓글이 없습니다.