유저 스토리 예제로 살펴보는 스펙 작성법

이상적인 세상에선 사람들이 서로의 마음을 단번에 이해할 뿐만 아니라 혼란을 가져올 그 어떤 것도 없겠지만, 실상 현실에선 다른 동료들이 내 생각을 오해하지 않게끔 명료하게 전달할 수 있는 방법을 모색해야 한다. 소프트웨어 개발 시, 잘 정의한 스펙은 클라이언트가 기대하는 바에 맞게 서비스를 제작하는 데 도움된다. “나는 우리 앱 서비스가 멋지고, 최대한 많은 사람들에게 인기가 많길 바라"와 같은 기준은 별로 득 될 것이 없으며, 명확한 스펙을 정의하고 있는 유저 스토리를 참고했을 때 개발팀과 클라이언트 사이에 혹시나 있을 잘못된 의사소통을 방지할 수 있다. 이 아티클에서는 스크럼, 칸반과 같은 애자일 방법론에서 참고할 수 있는 ‘스펙'에 대해 설명하면서 잘 작성된 사례 몇 가지를 짚어보고자 한다. 스크럼, 유저 스토리, 그리고 스펙은 2020년 반짝 유행어가 아니다. 우리 주변에 스크럼이 자주 언급되는 데에는 다 그럴 만한 이유가 있다. 먼저 스크럼이란, 소프트웨어 개발팀이 복잡한 제품을 제작할 때 도움되는 애자일 프레임 워크라 설명할 수 있는데, 우리 회사에서는 이 스크럼 방법론에 따라 일 하는 것을 선호하는 편이다. 최근에는 *스크럼 포커를 위한 사내 앱인 스크럼머(Scrummer)을 출시 하기도 했다. (참고; 번역자 추가 설명) * 스크럼 포커: 개발 및 제작 공수를 산정하는 일종의 카드 뽑기, 관련된 다른 용어로는 플래닝 포커, 에스티메이션 등을 생각해볼 수 있습니다. (다른 애자일 방법론과 마찬가지로) 우리는 이 스크럼 방식 안에서, 사용자가 앱을 어떻게 사용하게 할 것인지, 이를 위해 각 팀은 어떻게 작업을 수행해야 하는지에 대해 명확하게 정의하고자 ‘유저 스토리', ‘스펙’과 같은 방법론을 프레임 워크에 도입해 운영하고 있다. 제품을 만들기 시작할 때, 우리는 클라이언트와 협력해 유저 스토리를 정의하는데, 이때 유저 스토리는 다음과 같은 형식으로 작성된다. As a: (~ 유형의 사용자)로서 I want: (어떤 행동을 수행)하고 싶다. so that: (~어떤 목표/결과/가치를 달성)하고자 유저 스토리의 목적은, 이를 잘 작성하여 시스템 내 사용자의 역할, 원하는 활동 및 달성하고자 하는 바를 설명하는 데 있다. 애자일 팀의 경우에는 유저 스토리가 사용자의 니즈를 파악하는 주된 방법이기도 하다. 스펙 정의하기 그렇다면, 어떻게 하면 클라이언트의 요구에 부합하는 유저 스토리를 완성할 수 있을까? 먼저 스펙을 짚고 넘어가야 한다. 스펙이란 유저 스토리 작성 시 고려할 수 있는 모든 시나리오를 보장하는, 일종의 공식화된 요구 사항 목록이라 할 수 있다. 간단히 말해, 스펙은 유저 스토리가 충족되는 조건을 명시하는 것이다. 이때 간결하고 명확하게 작성된 스펙은 개발팀이 클라이언트의 요구에 대한 모호한 이해를 피할 수 있고 자칫 발생할 수 있는 잘못된 의사소통을 방지하는 데 도움된다. 스펙을 잘 작성하는 것은 클라이언트로부터 제품의 비전을 이끌어내는 데는 물론 개발 프로세스에도 중요하다. 사람마다 같은 문제를 다른 각도에서 보는 것은 당연하기 때문에, 잘 작성된 스펙은 구현하고자 하는 기능에 대하여 하나의 해결책만을 명확히 명시하는 것이 중요하다. 스펙은 어떤 경우에 유용할까? 개발 범위 정의가 필요할 때 스펙은 개발팀이 유저 스토리의 개발 범위를 정의하는 데 도움된다. 즉, 다시 말해 스펙은 앱 서비스가 계획한 대로 기능 구현이 되는 것을 확인하는 데 도움되며, 이는 곧 유저 스토리가 잘 작성되었음을 의미한다. 합의에 도달하고자 할 때 스펙을 정의한다는 것은 곧 개발팀과 클라이언트가 함께 의견을 조율한다는 것과 같은 말이다. 클라이트가 이 앱에서 무엇을 기대해야 할지 아는 것과 마찬가지로 개발팀은 그러기 위해서는 어떤 조건이 충족되어야 하는지 스펙을 보고 명확히 이해할 수 있다. 테스트 가이드라인이 필요할 때 마지막으로 스펙은 시스템이 예상대로 작동하는지 확인하는 것이 목표인 테스트의 초석이 될 수 있다. 정확한 계획과 산정이 필요할 때 스펙은 유저 스토리를 업무 범위를 분할하여 일을 정확하게 산정 및 계획할 수 있도록 돕는다. 그럼, 스펙은 누가/언제 작성해야 할까? 클라이언트 또는 개발팀이 보통 스펙을 작성한다. 원칙적으로는 프로덕트 오너(PO, 또는 클라리언트)가 작성한 스펙을 개발팀 구성원이 검토하여 스펙이 명확히 명시되어 있는지, 개발 관점에서 기술적 제약이나 불일치가 없는지 확인한다. 이러한 흐름은 클라이언트가 소프트웨어 개발에 어느 정도 경험이 있고 프로젝트 문서 작성 방법을 알고 있다면 협업할 수 있는 최고의 방법이다. 만약 개발팀에서 스펙을 작성해야 한다면, 기술 스택과 개발 가능성을 잘 이해하고 있는 요구 사항 분석가, 프로젝트 매니저(PM) 또는 QA 전문가들이 작성하는 것이 좋다. 여기서 꼭 기억해야 할 것은 개발 단계가 시작되기 전 스펙이 미리 작성되어야 한다는 것이다. 즉, 개발팀과 프로덕트 오너(또는 클라이언트)가 본인의 요구 사항에 부합하는 최소한의 산출물에 대하여 사전에 충분히 인지/예상하고 스펙을 정의하는 과정이 필요하다. 스펙 작성 방법 시나리오 중심 접근 방식을 사용해 스펙을 작성하는 일반적인 템플릿은 행동 중심 개발(BDD)에서 파생된 Given/When/Then이 있다. Given/When/Then 형식은 모든 요구 사항이 충족 되는지 확인하는 테스트 시나리오 작성에도 참고/사용된다. 이 형식은 인과관계 형식으로 쓰여있기 때문에 작업자에게 편리할 뿐만 아니라 Cucumber, RSpec과 같은 자동화된 테스트 작업 툴에도 쉽게 적용할 수 있다. 예를 들어, 로그인한 사용자, 게스트와 같은 두 가지 유형의 사용자가 존재하는 웹사이트를 구축할 경우, 로그아웃한 사용자의 로그인 기능을 정의하는 유저 스토리를 다음과 같은 스펙으로 작성할 수 있다. As a: 로그아웃된 사용자로서 I want: 나는 웹사이트에 로그인할 수 있기를 원한다. so that: 내 개인 프로필에 접근하고자 ✏️Scenario: 시스템에 이미 가입된 사용자인 ‘나'는 로그인하려고 한다. Given: ‘나’는 현재 로그아웃된 사용자이고 and 로그인 페이지에 진입한다. When: ID와 비밀번호 필드에 해당 정보를 입력한다. and 로그인 버튼을 클릭하면, Then: 시스템은 나를 로그인시켜준다. Given / When / Then 템플릿은 시스템의 동작을 미리 설명하기 때문에 테스트 사례 작성에 소요되는 시간을 줄이는 데 도움되는 것이다. 우리의 경우 1인칭 ‘나’로 스펙을 작성하는 것을 선호하는데, 그 이유는 1인칭으로 작성할 때 사용자의 관점에서 이야기할 뿐만 아니라 사용자의 니즈를 염두할 수 있도록 도와주기 때문이다. 다음은 괜찮은 스펙을 작성하는데 도움될 몇 가지 팁을 적어봤다. 당신의 아이디어를 다른 프로젝트 구성원들이 충분히 이해할 수 있도록 기준을 정의하자. 스펙은 현실적이고 달성 가능하게끔 작성하도록 하자. 즉, 최소한의 기능을 정의하고 이를 고수하는 것이다. 모든 세부사항을 설명하는 등, 스스로 자잘한 일에 자진해서 파묻히려 하지 마라. 모든 이해당사자들과 협력하여 여러분의 스펙 기준을 합의하는데 주력하라. 예산과 개발 시간에 제약이 없도록 적절히 추정/산정할 수 있는 측정 가능한 스펙을 만들어라. 유저 스토리가 스펙에 알맞게 적용되는지 확인할 수 있는 체크리스트를 제공하는 것을 고려해보자. 명확한 스펙으로 개발 시간을 효율적으로 절약하기 스펙 작성 사례 이 섹션에서는 대부분의 웹사이트에서 봤을 법한 기능에 대하여 작성된 스펙의 사례를 살펴보기로 하자. 유저 스토리를 통해 피처를 설정한 다음에서야 스펙을 작성할 수 있기 때문에, 제일 먼저 유저 스토리를 정의해야 한다. 예시 #1 첫 번째 유저 스토리는 웹페이지 내 검색 기능에 대해 설명한다. As a: 웹사이트 사용자로서 I want: 웹페이지에서 검색할 수 있기를 원한다. so that: 필요한 정보를 찾고자 Given/When/Then 템플릿에 따르면, 스펙은 다음과 같다. ✏️Scenario: 사용자는 ‘이름’ 정보를 이용해 특정 항목을 검색하려고 한다. Given: 게스트 혹은 등록된 사용자인 내가 When: 제품 페이지를 열면 Then: 시스템은 나에게 모든 제품 목록을 보여준다 and 화면 오른쪽 상단 모서리에 ‘검색' 섹션을 보여준다. When: 제품 목록에 중 존재하는 이름을 ‘검색 필드에 작성하고 and ‘적용'버튼을 클릭하거나 키보드의 엔터키를 누른다. Then: 시스템은 검색 결과 섹션에 입력된 제품 이름과 일치하는 이름을 가진 제품을 표시한다. and 결과 섹션의 상단에는 검색 결과의 수를 보여준다. 예시 #2 다음 유저 스토리는 웹페이지 내 피드백 제출 기능과 관련해 정리된 스펙이다. As a: 웹사이트 사용자로서 I want: 웹페이지에서 피드백을 제출할 수 있기를 원한다. so that: 관리자들이 향후 웹사이트를 업데이트할 때 내 의견을 고려할 수 있게끔 하고자 이 기능에 대한 스펙은 다음과 같다. ✏️Scenario: 사용자(나)는 피드백 제출 양식에 내 의견을 작성해 제출하고자 한다. Given: 로그인 또는 게스트 사용자인 내가 When: 피드백 페이지를 오픈할 때 Then: 시스템은 ‘이메일', ‘이름' 및 ‘코멘트' 필드가 필수 항목으로 포함된 피드백 제출 양식을 보여준다. When: ‘이메일' 필드에 해당하는 정보를 기입한다. and 내 이름을 ‘이름' 필드에 기입하고 and 내 의견을 ‘코멘트' 필드에 채운 다음 and ‘피드백 제출하기' 버튼을 클릭한다. Then: 시스템은 ‘피드백을 성공적으로 제출했다'는 플래시 메시지를 보여준다. and 앞에 작성했던 필드 내 데이터는 시스템에서 모두 삭제된다 예시 #3 마지막으로, 블로그에 댓글을 달기 위한 유저 스토리 및 그에 따른 스펙을 살펴보기로 하자. 이때 로그인한 사용자만 댓글을 남길 수 있으며, ‘댓글 남기기' 기능에 대한 유저 스토리는 다음과 같다. As a: 나는 로그인한 사용자가 I want: 블로그 게시물에 댓글을 남길 수 있기를 원한다. so that: 해당 게시물과 관련된 다른 사용자의 피드백을 얻고자 이 기능에 대한 스펙은 다음과 같다. ✏️Scenario: 로그인한 사용자가 블로그 게시물에 댓글을 남기려고 한다. Given: 로그인 사용자인 내가 When: 특정 블로그의 게시물 페이지에 진입했을 때 Then: 시스템은 블로그 게시물 아래에 “댓글" 섹션과 다른 사용자들이 작성한 댓글 목록을 보여준다. and 시스템은 이 섹션 상위에 ‘댓글 입력' 필드를 함께 보여준다. When: 이 댓글 섹션에 댓글을 남긴 다음 and ‘댓글 등록’ 버튼을 클릭한다. Then: 이로써 시스템은 내가 남긴 댓글 데이터를 저장하고 and 댓글 섹션 중 최상위에 방금 등록된 내 댓글이 노출된다. and 내 댓글 왼쪽에는 프로필 사진과 이름이 함께 노출되고, and 댓글과는 상반되는 위치에 ‘제거'와 ‘편집' 아이콘이 존재한다. 마무리 하며 보시다시피, 스펙을 작성하는 것은 클라이언트와 개발팀 모두에게 꼭 필요한 과정이다. 팀에서는 무엇을 어떻게 해야 하는지 정확히 판단하는 데 도움될 뿐만 아니라, 클라이언트가 개발 프로세스를 이해하고 개발된 소프트웨어가 실제 비지니스 요구 사항을 충족하는지 확인할 수 있는 과정인 것이다. 유저 스토리와 스펙을 작성하는 데 주저하지 말자. 모든 기능을 정의하고 설명하는 데 투자하는 시간은 결과적으로 성과로 돌아올 것이다. 스펙은 비지니스 목표를 달성함과 동시에 버그가 없는 앱을 제작하는데 필요한 사용 사례 및 테스트의 기초가 된다는 것을 기억하자. + 더 알고 싶다면 애자일이 도대체 뭐길래? - Evan Moon 애자일에 대한 정의 및 프로세스, 또, 본문과는 다른 방식의 유저 스토리 예시를 살펴보실 수 있는 글입니다. 서론에 잠깐 언급됐던 '플래닝 포커'와 유사한, 에스티메이션 단계도 쉽게 정리되어 있으니 업무를 산정/조율하는 방법에 대해 궁금하시다면 읽어보시기를 추천드려요! 애자일 Scrum(스크럼) 이해하기 - 민현기 애자일 방법론 중 가장 대표적인 프로세스 프레임 워크인 스크럼에 대한 글입니다. 유저 스토리 작성법 외에 스크럼에 관련해서 좀 더 이해하고 싶으신 분들께 추천드립니다!