소프트웨어 개발에서 가장 중요한 과정 중 하나는 요구사항을 명확히 정의하는 것입니다. 하지만 경험이 없는 사람에게 요구사항을 작성하는 일은 쉽지 않을 수 있습니다. 그렇다고 소프트웨어 요구사항 관련 공부를 무겁게 하는 것은 현실적이지 않습니다. 이럴 때 유저스토리(User Story)는 매우 유용한 도구가 됩니다. 전통적인 소프트웨어 요구사항 문서에 비해 유저스토리 기반의 요구사항 문서는 이해하기 쉬운 언어와 구조로 구성되어 있기 때문입니다.
이번 시간에는 유저스토리가 무엇인지, 그리고 이를 어떻게 작성할 수 있는지에 대한 기초적인 내용을 살펴보겠습니다. 더불어, 에픽(Epic)과 인수조건(Acceptance Criteria)을 어떻게 활용해야 하는지도 다뤄보겠습니다.
1. 유저스토리란 무엇인가?
유저스토리는 소프트웨어 개발 요구사항을 간결하고 명확하게 표현하는 방식입니다. 주로 애자일(Agile) 개발 방법론에서 많이 사용되며, 개발자와 비개발자 간의 소통을 원활하게 돕는 도구로 자리 잡고 있습니다. 유저스토리는 다음과 같은 형식으로 작성됩니다:
유저스토리 기본 템플릿:
“나는 [사용자]로서, [목표]를 달성할 수 있다. (optional) 따라서 나는 어떤 [가치]를 얻을 수 있다.”
이 구조는 특정 사용자가 어떤 목표를 달성하고, 그로 인해 얻을 수 있는 이익을 간결하게 설명합니다. 예를 들어:
• “사용자로서, 나는 비밀번호를 변경할 수 있다. 이를 통해 내 계정의 보안을 유지할 수 있다.”
이 간단한 형식을 통해 요구사항을 명확히 전달할 수 있어, 비전문가도 쉽게 작성하고 이해할 수 있습니다.
2. 에픽(Epic)과 유저스토리(User Story)의 차이점
유저스토리와 혼동되기 쉬운 개념 중 하나가 에픽(Epic)입니다. 에픽은 단일 스토리로는 표현하기 어려운 큰 요구사항을 의미하며, 여러 개의 유저스토리로 나눌 수 있는 상위 개념입니다.
예를 들어 아래와 같은 에픽 예시를 살펴봅시다.
• 에픽: “사용자 계정 관리”
이 에픽을 완료하기 위해서는 다양한 유저스토리가 필요합니다. 각각의 유저스토리는 에픽에서 파생된 작은 기능 단위이며, 실제 개발에서 구현 가능한 단위입니다. 예를 들어 위 에픽을 나누면 다음과 같은 유저스토리들이 나올 수 있습니다:
• “사용자로서, 나는 비밀번호를 변경할 수 있다.”
• “관리자로서, 나는 다른 각각의 일반 사용자 계정을 비활성화할 수 있다.”
에픽과 유저스토리의 관계는 상위-하위 관계로 볼 수 있습니다. 에픽은 큰 그림을 그리며, 이를 구체적으로 실행하기 위해 더 작은 유저스토리로 나누어지는 것입니다.
각각의 유저스토리는 또 다시 하위 작업(task) 혹은 사용하는 도구에 따라 issue or ticket 등으로 구성됩니다. 실제 개발자들은 이 하위 작업 단위로 개발하는 경우가 많습니다. 개발 작업 및 백로그 등에 대한 내용은 이번 글의 범위가 아니므로 이후 기회에서 다뤄보도록 하겠습니다.
3. 좋은 유저스토리 작성의 원칙
유저스토리를 잘 작성하려면 몇 가지 원칙을 따르는 것이 중요합니다. 다음은 좋은 유저스토리를 작성하기 위한 6가지 주요 원칙입니다:
1. 독립성(Independent): 유저스토리는 다른 스토리와 독립적으로 존재해야 합니다.
2. 협상 가능성(Negotiable): 유저스토리는 고정된 요구사항이 아니라, 변경될 수 있어야 합니다.
3. 가치 중심(Valuable): 유저스토리는 고객에게 직접적인 가치를 제공해야 합니다.
4. 추정 가능성(Estimable): 유저스토리는 구현에 필요한 시간과 자원을 추정할 수 있어야 합니다.
5. 작은 크기(Small): 유저스토리는 단기간에 개발할 수 있는 작은 크기로 나누어져야 합니다.
6. 테스트 가능성(Testable): 유저스토리는 테스트 가능한 기준을 제공해야 합니다.
이 원칙들을 지키면, 명확하고 구체적인 유저스토리를 작성할 수 있습니다.
4. 유저스토리 작성 실습: 좋은 예시 vs 나쁜 예시
나쁜 유저스토리 예시:
유저스토리: “사용자로서, 나는 회원가입을 할 수 있다.”
이 예시는 너무 모호합니다. 사용자가 왜 로그인이 필요한지, 구체적인 목표, 인수조건 및 가치가 명확하지 않습니다.
좋은 유저스토리 예시:
유저스토리: “사용자로서, 나는 이메일과 비밀번호를 사용하여 회원 가입을 할 수 있다. 회원가입은 이메일 확인 링크 클릭을 통해 확인된 이메일로만 가입 완료가 가능하다. 이를 통해 무분별하게 유입되는 유사 이메일의 회원가입을 막을 수 있다.”
인수조건: 1. 회원가입 이후 이메일 인박스로 보내진 확인 링크로 검증된 이메일만 로그인에 사용될 수 있다. 확인되지 않은 이메일은 로그인에 사용될 수 없다. 2. 비밀번호는 6자리 이상이어야 하며 문자와 숫자로 조합되어야 한다.
이 예시는 사용자가 무엇을 원하는지 명확하고, 그로 인해 얻을 수 있는 이익도 구체적으로 설명하고 있습니다. 이런 방식으로 구체적이고 명확한 유저스토리를 작성하는 것이 중요합니다.
여기서 새로운 개념이 등장하는데요. 유저스토리가 완료되었다고 판단하려면, 인수조건(Acceptance Criteria)이 반드시 필요합니다. 인수조건은 유저스토리가 성공적으로 구현되었는지 확인하기 위한 기준을 명시합니다. 개발팀과 비즈니스 팀 간의 기대치를 일치시키고, 개발된 기능이 사용자의 요구를 충족하는지 테스트할 수 있는 기준을 제공합니다.
5. 결론
이렇게 개발 팀은 유저스토리를 통해 기능을 정의하고, 각 기능을 작은 작업으로 나누어 우선순위를 정합니다. 이 과정을 통해 개발이 점진적으로 이루어지며, 필요 시 요구사항을 유연하게 변경할 수 있습니다.
유저스토리는 백로그 관리에서 중요한 역할을 하며, 특히 에픽을 작은 유저스토리로 쪼개어 단계별로 작업을 진행할 수 있도록 돕습니다.
유저스토리, 에픽, 인수조건을 효과적으로 활용하면 비전문가도 상대적으로 쉽게 요구사항을 정의할 수 있고, 개발팀은 이를 바탕으로 명확하게 개발을 진행할 수 있습니다. 특히 유저스토리 기반의 요구사항은, 비즈니스 상황 및 고객 상황이 변화함에 따라 함께 유연하게 수정, 관리하기에 적합합니다. 전문가 대비 요구사항 산출물 및 관리 수준에 차이가 있을 수 있지만, 경험이 없는 담당자나 의사결정권자, 대표님 역시 짧은 시간 안에 배우고 연습해서 적용할 수 있다는 점은 분명 매력적인 부분입니다. 여러분도 이제 프로젝트에 유저스토리를 도입하여 개발 과정에서의 소통을 원활하게 하여 원하는 비즈니스 결과를 달성하시기 바랍니다.
의견을 남겨주세요