개발을 여러 층의 케익으로 나누기

2017-11-17

* 이 글은 제품 설계와 관리 전문가 Luis Mizutani가 ThoughtWorks 블로그에 올린 Slicing your development work as a multi-layer cake을 번역한 글입니다.

애자일 프로젝트에서는, 흔히 목적을 쪼개어 개별 작업 단위로 나누어서 최종 사용자 관점에서 동작을 수행하는 기능feature 으로 만든다. 이러한 작업 단위를 보통 '사용자 스토리user story’라고 부른다.

이때, 분명한 의문이 떠오른다. 사용자 스토리로 일을 나누는 최선의 방법은 무엇인가? 인생의 많은 일이 그렇듯이 그것에 대한 답이 있다. 그때그때 달라요.

우리는 평소 농담조로 컨설턴트가 즐겨 쓰는 대답이라고 말하곤 한다. 그러나, 실제로 스토리 작성 방법에 왕도가 없기는 하다.

그렇다고, 사용자 스토리 작성 방법에 관해 유용한 문헌이 없다는 말은 아니다. 단지, 어느 시점에 특정 방법을 쓰라고 알려주는 식의 이론은 없다는 의미다. 그만큼 사용자 스토리로 일을 나누는 길은 부단한 연습이 있을뿐 뾰족한 방법이 없는 고된 작업이다.

나쁜 소식은 제쳐 두자. 반가운 소식은 효과적인 스토리 작성을 돕는 기법도 많이 있다는 사실이다.

시스템을 여러 층의 케익으로 구성하기

스토리를 작성할 때, 자주 적용하는 프레임워크 중에는 사용자, 업무 범위, 궁극적인 전달 가치 순으로 전제를 풀어가는 방법이 있다. "......로서, 내가 원하는 것은......, 그래서......”와 같은 식^[1]이다. 이는 시작하기에 좋은 방법이지만, 작업을 작게 나누어 기능 단위로 만드는 방법에 대한 통찰까지 제공하지는 못한다. 작은 기능 단위로 가치를 전달하고, 테스트를 실행하여 제품이 진화하는 간격을 좁히고 범위가 바뀌더라도 유연성을 높이려면 작은 기능 단위가 필요하다.

이제 '여러 층의 케익'이 필요한 시점이다. 2003년에 Bill Wake가 이 아이디어를 처음 지지했는데, 그 개념은 다음과 같다.

전체 시스템을 여러 층의 케익으로 간주한다. 이를테면, 네트워크 계층, 영속성 계층, 논리 계층, 프리젠테이션 계층 등으로 구성한다. 우리가 스토리를 한 개 꺼내면, 케익의 일부를 대접 받는 것과 같다. 고객에게 전체 케익의 진수를 줄 수 있는 가장 좋은 방법은 케익 각 계층을 아우르도록 수직으로 자르는 것이다. 개발자들은 주로 수평으로 한 계층씩 작업을 진행하는 경향이 있다(그것도 ‘올바른’ 방법이다). 그런데 경우에 따라서는 전체 데이터베이스 계층을 만들었더라도 프리젠테이션 계층이 없다면 고객은 별 가치를 느끼지 못할 수도 있다.

수평 분할의 단점

케익 맛을 보려면 완전히 굽고 난 후에나 가능하다. 케익을 수평으로 나누는 것은 여러분이 시스템을 한 계층씩 배포하는 것에 비유할 수 있다. 이러한 접근 방식의 단점은 완전히 끝나고 나서야 사용자가 시스템을 경험할 수 있다는 점이다. 애자일 접근은 최소 기능 집합으로 투자 수익 창출을 선호한다. 그래서 리듬^[2]을 유지하고, 가치를 극대화 하자는 것이다.

케익 맛을 보고 나서 여러분 마음에 들지 않을 수도 있다. 이때는 맛없는 케익 출시를 고객이 알기 전에 얼른 케익 전체를 다시 구워내야 한다. 다시 말해 피드백 루프는 길어지고, 뒤따라 위험은 증가한다. 게다가, 피드백 주기가 늘어나면 애자일 방법론으로 얻으려던 의도와는 반대로 간다. 여러 층의 케익 아이디어는 학습을 통해 습득한 지식으로 제품을 변경하고 진화 시키자는 것이다. 학습의 필수 원천은 바로 사용자나 고객으로부터 받은 피드백을 통해 얻는 지식이다.

우선 수평 조각은 당신 취향에 맞춰 선택할 수 없다. 모든 수평적인 스토리를, 여러 계층에 나누어 정렬한 후에 지속적으로 바뀌는 비즈니스 우선 순위에 맞춰 조정하는 일은 거의 불가능하고 비현실적이다. 시스템을 계층별로 조립한다면 융통성이 떨어지고, 제품 관리자가 제품 출시일자를 조정하기도 어렵다. 프로젝트 관리자는 서로 얽힌 작업을 조율하느라 분투하고, 팀 역량 관리로 머리를 쓰느라 눈코 뜰 새 없이 바쁠 것이다. 두 경우 모두 제품 개발 프로젝트에서는 흔히 있는 일이다. 따로 개발한 계층을 하나로 통합하는 일은 악몽으로 나타날 수 있으며, 결과를 내는데 급급해 프로젝트에 투입된 비용과 시간, 전반적인 품질 모두에 악영향을 끼친다.

케익 조각은 어떻게 생겼을까?

‘여러 층의 케익’ 이론은 훌륭하다. 하지만 이론에 더해 실용적인 경험으로 균형을 맞출 때, 효과적인 스토리 작성이 가능하다. 'INVEST 모델'^[3] 은 완고하게 이론만 추종했을 때의 위험을 보여주는 좋은 예다.

좋은 사용자 스토리의 요건은 독립적이고(I), 협상할 수 있고(N), 가치 있고(V), 예측할 수 있고(E), 작고(S), 시험할 수 있어야(T) 하겠으나, 이상적인 이야기일 뿐임을 깨닫는 것이 중요하다.

'사용자 스토리'와 'INVEST 모델’을 두고 대화하다 보면, 스토리의 가치를 지나치게 강조하는 사례를 많이 보았다. 듣다보면 모든 스토리는 예외 없이, 스토리 자체가 가치를 전달해야 할 것만 같다.

여러 시스템 간에 교류가 일어나는 업무에서 통신 흐름을 구축하는 작업에 대한 스토리를 작성할 때, 관점을 너무 고집하면 대화가 막힌다. 만일 가치관이 지나치게 강조된다면, 매우 길고 복잡한 스토리로 이어질 수 있고, 전체 흐름이 모두 작동해야 결과를 얻는다. 어떤 가치관으로는 타당할 수 있지만, 테스트 하는 입장에선 악몽이 될 수 있다. 게다가 팀의 동기 부여측면에서도 스토리가 길고 지루해지면, 지식이 팀 안에만 머물면서 팀의 고립을 자초할 수 있다.

특별한 예지만, 가치를 지나치게 강조하면 사용자와 벤더 시스템 양측으로부터 신속한 피드백을 받지 못하게 된다. 이러한 상황에서는, 복잡성 수준을 주로 관찰하여 작업을 나누는 것이 좋다. 이것은 가장 단순한 작업부터 가장 복잡한 작업까지 진행하고, 피드백을 정기적으로 받으면서 점차 정교해 진다는 의미다.

시스템 복잡도 대對 긴 스토리

아래는 스토리를 적용해 웹 사이트에서 여행 티켓을 파는 새로운 기능을 만드는 사례다.

"XYZ 여행사 이용자로서,

내가 선정한 두 도시를 오가는 항공편을 세금이 포함된 요금과 함께 보고자 한다.

그래서 가장 적합한 항공편을 선택할 수 있다"

웹 사이트 UI에 항공편 목록을 표시하는 일은 간단한 작업으로 보일지 모르겠다. 그러나 올바른 정보를 생성하려면 많은 논리가 필요하다. 아래와 같이 여러 계층이 필요하고, 때로는 여러 시스템이 참여할 수도 있다.

그림 1. 숨겨진 시스템 복잡성

이 작업은 보기보다 훨씬 더 크고, 개발을 시작하면 복잡성과 업무량은 더 불어날 수 있다. 결국, 여러분의 사용자 스토리는 하염없이 길어질지도 모른다. 긴 스토리는 다른 스토리를 가로막고, 고객의 불안감을 가중시킨다. 게다가, 팀의 준비기간에 영향을 미치는 문제를 숨길 수 있고, 팀 역량을 제대로 인지하는 것도 어렵게 만든다.

스토리가 너무 긴 경우, 손쉽게 수평으로 잘라 버리는 경향이 있는데, 그렇게 하면 안 된다는 게 우리 소신이다. 스토리는 분명히 횡단선transversal^[4]으로 유지해야 한다. 그렇다면, 어떻게 해야 거대한 스토리를 피할 것인가?

케익을 자르는 방법은?

'케익 조리법'은 없지만, 스토리를 나눌 때 사용할 수 있는 몇 가지 유용한 전략이 있다.

업무흐름 단계
비즈니스 규칙
성공 / 실패 경로
매개 변수의 데이터 유형
입력 옵션 / 플랫폼
모호한 용어와 접속사

업무흐름 단계

업무흐름 즉, 사용자 여정을 더 작은 단계로 나누어 갈 때, 나뉘어진 알갱이 크기에 주의를 기울인다. 사용자나 고객에게 유용한 무언가 제공할 수만 있다면, 스토리 한 개로 업무흐름의 한 단계를 다루어도 된다. 한 단계로 비즈니스 가치를 제공하지 않는다고 판단하면 두 단계 이상을 묶어서 한 스토리로 작성할 수 있다.

다른 대안은 업무흐름을 다른 방식으로 분할하는 것이다. 그러나, 조심해야 한다. 앞서 강조했지만, 흐름 단계가 개별로는 가치가 없더라도 한 번에 한 개씩 제공하는 것이 나은 경우가 있다.

복잡한 업무흐름을 작업할 때, 한 가지 좋은 전략은 매우 기본적인 기능 흐름에서 시작하여 복잡한 계층을 반복해서 새롭게 추가하는 식이다. 이후 사용자의 피드백을 보면서 다음 스토리로 건너 뛸 것인지, 개선 작업을 계속할 것인지 선택한다. 같은 흐름을 성공 시나리오와 실패 시나리오로 나누어 설명할 수도 있다. 아래 그림은 전자 상거래 웹 사이트의 구매 업무흐름에 적용한 개념을 설명한다.

그림 2: 단순한 흐름 단계로 시작하기

비즈니스 규칙

비즈니스 규칙을 지침으로 사용하여 일을 나눌 때는 보편적인 사건을 다루는 규칙과 예외 사건을 다루는 규칙을 서로 구분하자. 의뢰인은 종종 모든 가능한 사건 매핑에 관심이 큰 나머지, 때에 따라서 예외 사건은 비용이 덜 드는 방법이 있다는 것을 잊곤한다.

가장 일반적인 시나리오 혹은 주요 가정(가설)을 다루는 규칙 먼저 시작하고, 특수한 규칙은 다음 개발 주기로 넘기자.

현실에서 기본 규칙을 테스트하는 일은 대안이 되는 시나리오를 식별하는데 필요한 데이터와 정보를 추출하는 최선의 방법 중 하나이며, 추가로 구현해야 할 규칙도 식별할 수 있다.

다음은 전자 상거래 웹 사이트에서 주문을 거부할 수 있는지 여부를 결정하는 데 사용할 수 있는 규칙의 예다. 여기서 기준은 제품을 제공하는 비용이나 운영상의 복잡성에 근거한다. 기본 배송비를 고려해 5달러 이상의 판매만 가정하고 시작한다. 또한, 해외 주문은 더디게 진행되지만, 보상 규칙은 따로 마련하지 않는 것으로 가정한다. 만약 우리가 해외로부터 대량 주문을 받지 않는 한, 해외 주문 거절 규칙 마련은 시간과 노력의 낭비만 초래할 뿐이다. 하지만 확실하게 알려면, 실제 데이터를 확보해야 한다.

그림 3: 당신의 스토리에 영향을 미치는 비즈니스 논리

성공 경로와 실패 경로

'성공과 실패 경로happy and unhappy path'의 프레임워크는 스토리 분할에 유익하다. 특히, 다른 접근이 안 통할 때 적용한다. 어떤 경우에는 실패 경로를 구현할 때까지 그것을 임시로 대체하는 수동 프로세스를 이용할 수 밖에 없다는 점을 강조하는 것도 중요하다.

예를 들어, 사용자 가입 기능^[5]이 아직 없어도 간단한 등록 기능을 제공하면 로그인 기능을 사용자에게 제공할 수 있다. 사용자 가입 기능을 제공할 때까지, 임시로 팀원 중 누군가에게 지원요청 이메일을 보내면 처리해 주는 식으로 가능하다. 물론, 확장이나 보안에 문제가 있지만, 당분간 쓸 수 있다.

그림 4: 실패 경로 따라가기

데이터 유형 또는 매개 변수

데이터 유형 정의는 검색 기능 또는 등록 양식을 개발할 때 스토리를 분할하는 이상적인 방법이다. 사용자 연구를 하면 검색 필터를 생성할 때 쓰일 기준을 정할 수 있다.

등록 양식에 관해서는 필수 정보로 시작하거나 자신이 설정한 주요 가정 검증에 도움이 되는 것부터 한다. 다른 예로는 검색 결과 페이지에서 검색 속성이나 필터링 옵션을 구현하는 일이다. 마지막 사례는 아래에 이미지로 나와 있다.

그림 5: 검색 기능 개발을 돕는 데이터 유형

입력 옵션 / 플랫폼

반응형 웹 설계responsive web design에서는, 보통 다수 플랫폼을 취급한다. 하지만 일을 쉽게 하려면 한 번에 하나씩 집중한다(아래 그림 참조). 같은 식으로 작업을 복수의 스토리로 나눌 때도 적용할 수 있다. 고객으로부터 나온 데이터를 활용하여 의사결정을 지원한다. 예를 들어, 가장 많은 고객이 있는 플랫폼에서 시작한다. 초기 단계에서 설계와 기본 제품 기능을 검증하는 시기라면 이상적이다. 반응형 설계를 할 때 의사 결정을 너무 늦춘다면, 뒤늦게 반응형 수준을 높이느라 시간과 노력을 추가해야 한다.

그림 6: 플랫폼별 개별 스토리 작성

모호한 용어와 접속사

여러분은 또한 높은 수준의 아이디어를 구체화하면서 스토리를 나누어가며 작성할 수 있다. 이렇게 하면 더 작아진 스토리 덕분에 피드백과 가치를 빠르게 얻을 수 있다. 또 다른 장점은 개발자들에게 명확한 의도를 제공하여, 스토리 완성을 위해 무엇을 테스트해야 하는지 알게 한다.

다음과 같은 용어 정의를 생각해보자.

모호한 용어

여행을 즐기는 사람으로서, 며칠 동안의 날씨 데이터를 저장해서 오프라인에서 표시할 수 있는 날씨 애플리케이션이 필요하다. 그래서 내가 목적지에 도착했을 때 휴대폰 서비스가 안 되더라도 일기 예보를 볼 수 있어야 한다.

1. 다음 날의 날씨 데이터 저장^[7]

2. 다음 5일 간의 날씨 데이터 저장

접속사

서비스 재방문자로서, 나는 신용 카드 번호를 저장하는 옵션을 입력해 둔다. 그리고 추후 구매 할 때 선택한다. 그래서 매번 구매할 때마다 긴 번호를 다시 넣지 않아야 한다.

1. 신용 카드 번호를 내 프로필에 저장

2. 구매 시 저장된 신용 카드 번호를 사용할 수 있는 옵션 제공

참고 문헌과 유용한 링크

주석

[1] 사용자 스토리 템플릿은 여러 형태가 제안되어 있다. 여기서 저자는 다음 템플릿을 사용하고 있다. “어떤 <역할>로서, 나는 <기능> 을 원하는데, <이득 얻기> 위함이다.” 또는, “어떤 <사용자 타입>으로서, 나는 <어떤 목표> 를 원하는 데, <어떤 이유> 때문이다.” https://en.wikipedia.org/wiki/User_story

[2] 짧은 주기로 지속적으로 결과물이 사용자에게 노출되는 흐름을 리듬으로 표현

[3] INVEST 모델: Bill Wake가 제안한 모델로서 사용자 스토리 작성에 관한 참조 모델이다. http://wiki.c2.com/?InvestModelForUserStories

[4] 기하학 용어로서 같은 평면에 두 선이 있을 때, 두 선을 가르고 통과 하는 제 3의 선을 말한다. 이 글에서는 계층별로 대응해서 구성된 수평면을 수직으로 지나가는 종단면을 의미한다.

[5] 원문에는 ability to edit their login 라고 표현했으나 우리말로 로그인 편집이라고 하면 어색하여 근접한 기능인 사용자 가입을 예로 들었다.

[6] 모호한 용어와 접속사에 대한 친절한 설명은 아래 사이트에 있다.

http://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/

[7] 아래 숫자와 함께 명시한 내용이 굵은 기울임꼴 글씨로 표시한 부분을 명확하게 하는 방법이다. 접속사의 경우도 같다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.