User Stories에 대해서 관심을 가지기 시작한지는 솔직히 얼마 되지 않습니다. ^^; 몸담고 있는 조직이 개발 조직이 아니라서, 사실 개발 방법론쪽으로 관심을 가지는 것이 그다지 도움이 되는 상황은 아니죠.

하지만 그렇다고 개발을 아주 안 할 수는 없는 노릇이라, 가급적이면 개발을 잘 하는 것이 좋겠다... 뭐 이런 생각은 항상 가지고 있었습니다. 그래서 최근에 Extreme Programming, User Stories, TDD, CVS 등등 연관되어 있는 방법론, 기법, 기술 등을 열심히 보고 있는 중입니다. 과연 이 상태 (지적 욕구에 충만한 이런 상태) 가 얼마나 오래 갈 지는 알 수 없습니다만 ㅋㅋ 지속되는 동안에는 이 블로그에도 엇비슷한 글들이 계속 올라오게 되리라 생각합니다.

각설하고.

이 글은 "User Stories: 실무 적용 사례"의 첫 번째 글입니다. 제가 하고 있는 업무에 실제로 User Story를 적용해 본 사례에 대해서 이야기를 해 보려고 합니다. (사실 완료된 업무는 아니고 지금 진행중인 업무입니다.) 업무 내용에 대해서도 소상히 말씀을 드릴 수 있으면 좋겠습니다만 사실 업무 성격상 외부에 공개가 조금 어려울 수도 있는 부분이 있기 때문에, 자세히 말씀 드리지 못하고 건너뛰는 부분도 있을 수 있습니다. (어쩌면 잘 몰라서 그러는 것일지도 모릅니다 *쿨럭*) 그런 부분에 대해서는 양해를 부탁드립니다. :-)

- - -

올해, 저는 대략 다음과 같은 이름의 시스템을 개발하게 되었습니다. (저는 네트워크 분야에서 일을 하고 있습니다.)

"VoIP, VoD 세션 요청에 대한 대역폭 기반 호 수락 제어 시스템"

이름 자체는 거창하기 짝이 없습니다만 하는 내용은 그렇지 않을지도 모릅니다. :-) 아무튼 위의 시스템이 하려고 하는 바는 이런 겁니다. 네트워크의 자원은 유한합니다. 대역폭은 무한히 주어질 수 없습니다. 그런데 대략적으로나마 그 자원의 크기(즉, 링크당 대역폭의 크기)를 알수 있다고 가정하고 (그 정보는 장비에 질의해보면 알 수 있다고 치겠습니다) 하나의 VoIP(혹은 VoD) 플로우가 보장받아야 할 대역폭의 양을 절대적으로 지원해 줄 수 있는 네트워크 장비가 있다고 치면, '이미 알고 있는 자원의 크기'를 기준으로 해서, '얼마나 많은 VoIP(혹은 VoD) 세션을 지원할 수 있는지'를 알 수 있습니다. 간단하죠. 그냥 나눗셈을 하면 됩니다. :-)

그런 간단한 가정에 기반한 호 수락 제어 시스템을 만들겠다는 겁니다. 현재 몇 개의 플로우가 특정한 링크에 흘러다니고 있는지를 알면, 현재 얼마만큼의 대역폭이 그 링크에 대해서 사용되고 있는지를 알 수 있습니다. 그런 정보에 의거하여 '새로운 VoIP/VoD세션을 받아들일 것인지 말 것인지'를 결정하는 수락제어 시스템을 만들어 보겠다, 는 겁니다. 이런 시스템을 통상 "Accounting Based 수락제어 시스템"이라고도 부르죠.

수락제어 시스템을 만드는 동기도 단순합니다. 어떤 특정한 링크에 허용되어 있는 대역폭 이상의 트래픽이 그 링크에 흘러들어오게 되면, 패킷들이 그 순간부터 랜덤하게 drop되기 시작합니다. 그러면 네트워크 링크상의 모든 플로우들이 성능 저하를 경험하게 되죠. 그런 상황을 피해보겠다는 겁니다.

그런데 말로 풀어보면 간단하기 짝이 없는 이 시스템을 실제로 구현하려고 해 보니, 그다지 간단하지가 않습니다. 우선 망에서 자원들(주로 네트워크 노드들과 그 사이의 링크들) 및 그 자원에 부여된 대역폭 크기를 수집을 해 와야 하고, Call Server는 SIP 요청들(INVITE, BYE 등등)을 처리해야 하고, ... 등등 할 일이 꽤나 많습니다.

개발을 어떻게 진행할까, 머리를 싸매던 끝에

기왕 하는 김에 Extreme Programming을 해 볼까

하는 무모한 생각을 하게 됩니다. -_-

그래서 일단 "들은 풍월도 있고 하니" 유저 스토리부터 한 번 작성을 해 봐야겠다, 하는 생각을 하게 되었습니다. User Story하면 모두들 "User Story Applied"를 읽는 것 같아, 저도 읽어봤습니다. 그리고 나서 아무 생각없이 유저 스토리를 작성하기 시작했(?)습니다. 유저 스토리는 시스템 사용자가 '시스템을 어떻게 사용하느냐'를 기술하는 것을 그 목적으로 합니다. 그래서 '누가' '무엇을 위해' 시스템을 사용하는지를 중심으로 기술하게 되죠. 하지만 Use Case 보다는 매우 간단합니다. Use Case는 가능한 모든 경우를 자세하게 기술하는 것을 목적으로 하는 반면, 사용자 스토리는 그 밑바탕부터가 '점진적인 개선'이나 '점진적 상세화'를 목적으로 하기 때문에, 그렇게 자세할 필요는 없습니다. 상세히 적어야 할 부분이 있다면 테스트 항목에 나열하면 되죠. (뭐 다 아시는 내용이겠습니다만...)

그러니 이런 것도 스토리가 될 수 있을 것 같습니다.

사용자는 VoIP 전화기를 사용해 전화를 걸 수 있다.

이 경우에는 '사용자'가 성취하려는 목적이 '전화를 거는' 것이죠. 그런데 이 사용자 스토리는 너무 커서 구현이 일이주 안에는 좀 어려울 것 같네요. 이런 스토리를 흔히 에픽(Epic)이라고 합니다. 이런 것은 나중에 사용자 스토리를 더 작은 단위로 나누는 과정에서 그 크기가 줄어들게 됩니다.

아무튼 그건 그렇고.

스토리가 이렇다 보니, '좋은 스토리'를 작성하려면 '시스템을 사용할 사용자'가 명확하면 명확할 수록 좋겠다', 뭐 이런 결론에 이르게 됩니다. 책에서는 사실 사용자 부류를 식별하려면 워크샵같은 자리를 마련해서 관련된 사람들이 전부 모인 다음에 사용자들을 식별해 나가도록 하는 게 좋다고 권고하고 있습니다만(뭐 일종의 브레인 스토밍이죠), 저는 저 혼자 실습을 진행하는 관계로 -_- 혼자 해 보기로 했습니다.

혼자 하려니 사용자 식별 과정에서 이용되는 '카드' 같은것을 만들기도 귀찮아서, 일단은 Note+라는 포스트잇 프로그램을 써 보기로 했습니다.

처음에 식별된 사용자들

처음에 식별된 사용자들


우선 생각할 수 있는 것으로, 네트워크 서비스 가입자가 있습니다. (저도 집에서는 그런 가입자 중 한사람입니다.) 이 가입자들을 좀 더 세분화해 보자면 VoIP 서비스 사용자가 있을 수 있고, VoD 서비스 사용자가 있을 수 있습니다. 그 이외에, 개발될 시스템을 사용할 주 고객으로, 네트워크 운영자가 있을 수 있습니다. 네트워크 운영자는 VoIP나 VoD 서비스에 의해 대역폭이 어떻게 소모되고 있는지를 항시 모니터링할 수 있었으면 좋겠다, 는 바램을 가지고 있는 부류의 사람들입니다.

그런데 이정도의 사용자만 식별하면 충분한걸까요?

(다음 글에 이어서...)
 

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. daliot

    켄트 벡이 한국에 옵니다. 관심이 있으실 것 같아 링크를 남깁니다.
    http://www.sten.or.kr/bbs/board.php?bo_table=news&wr_id=1807

    2009.08.27 19:00 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. daliot

    9월 4일 열리는 Kent Beck의 Responsive Design 세미나에 대한 호응이 너무 좋아서 정원이 이미 꽉차고 말았습니다. 9월 2일에도 같은 세미나를 하기 때문에 혹시라도 선착순에 밀리신 분이시라면 한번더 기회가 있다는 것을 알려 드립니다.

    http://sten.or.kr/bbs/board.php?bo_table=news&wr_id=1822

    2009.08.30 17:07 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 저도 알고 있었습니다. 다만 참석할 시간 내기 어려운 상황이어서요. 제가 9월 8일까지는 프로젝트 마무리에 전념해야 하는 상황이라...

      2009.08.31 10:01 신고 [ ADDR : EDIT/ DEL ]