유스케이스는 다이어그램이 아니다

By | 2011년 1월 10일

어제 소개해드린 새 옷으로 갈아입은 로버트 C. 마틴의 『UML 실전에서는 이것만 쓴다』 기억하시죠?
이 책에서 로버트 마틴은 유스케이스를 다음과 같이 정의합니다.

“유스케이스는 훌륭한 아이디어로 시작했지만 나중에 괜히 엄청나게 복잡해진 경우다. 나는 유스케이스를 작성하려고 자리에 앉아 시간만
질질 끄는 팀을 정말 많이 보았다. 대개 이런 팀은 본질보다는 형식에 관한 문제 때문에 계속 부딪힌다. (…중략…)
우리는 유스케이스를 그리지 않고 글로 적는다. 유스케이스는 다이어그램이 아니다. 유스케이스는 특정한 관점에서 보는 시스템의 동작을 글로 기술한 것이다.”

유스케이스라는 용어가 사용된 지는 꽤 되었지만, 유스케이스에 대한 오해는 아직 많이 남아있습니다.
가장 흔한 오해가 아래와 같은 다이어그램이 유스케이스라고 생각하는 것이지요.

유스케이스는 다이어그램이다?

이런 오해가 만들어지게 된 데는 여러 가지 이유가 있겠지만
유스케이스의 본질보다는 형식에 치우쳐 사용하다가 비롯된 게 아닐지 모르겠습니다.

과연 어떻게 하면 ‘형식’보다는 ‘본질’을 살리는 유스케이스를 작성할 수 있을까요?
유스케이스가 무엇인지는 잘 알고 있다고 생각하면서도 막상 유스케이스를 작성하려고 하면 손이 움직이지 않는 분들을 위해 소개해 드립니다.

『앨리스터 코오번의 유스케이스』!
2002년에 국내에 번역서가 출간되었던 『Writing Effective Use Cases』입니다.
몇 년 전에 절판된 도서인데, 로버트 C. 마틴을 비롯한 전문가들이 유스케이스는 이 책 하나만 보면 된다고 할 정도로 유스케이스의 거의 모든 것을 다룬 책입니다. 게다가 국내에 이 책을 대체할 만한 도서도 없고, 이만큼 유스케이스를 효과적으로 쓰는 방법을 알려주는 책도 없다고 판단했기에 복간하여 출간하게 되었습니다.

여러분이 유스케이스를 더 자세히 알아야 할 때가 오면, 이 주제에 대한 정석인 Alistair Cockburn의 Writing Effective Use Cases를 읽으면 된다.

그렇다면 책 제목으로 내세운 앨리스터 코오번은 어떤 사람일까요?

유스케이스 분야에 정통한 전문가다. 30년 이상 보험, 소매, 전자상거래 관련 회사, 그리고 노르웨이 센트럴 뱅크, IBM 같은
대규모 조직에서 하드웨어와 소프트웨어 개발 프로젝트를 이끌었다. 최근에 나오는 서적이나 발표자료에서 유스케이스 관련 내용은 대부분
코오번의 의견을 참조하고 있다.


『Agile Software Development의 저자이기도 한 코오번은 개발 방법론에 관심있는 사람들 사이에서 많이 알려져 있습니다. 대부분의 객체지향 및 컴포넌트 기반 관련 책들이 유스케이스에 대한 내용은 코오번의 글을 참고한다고 합니다.

이 책에서 코오번은 유스케이스란 원래부터 텍스트 기반의 서술 형식임을 강조합니다.
그리고 결국 유스케이스는 ‘사람이 읽기 위한 글’이기 때문에 이해하기 쉽게 써야한다고 말합니다.
이 책은 유스케이스의 기본 개념부터 실무자들을 위한 실전 예제까지 담고 있어서 유스케이스에 관심을 가지고 있는 독자들을 폭넓게 아우를 수 있으리라 기대합니다.

과연 유스케이스가 필요한 시점은 언제일까요?

3년 동안 진행해온 프로젝트에서 애자일(Agile) 개발방법인 스크럼을 적용해왔습니다. 제품 백로그, 스프린트 백로그로 요구사항 목록을 만들고 스프린트 계획회의, 일일
회의를 통해 사용자 스토리를 작성한 다음 스토리 점수 추정으로 일정을 계획하고 관리했습니다. 거의 대부분의
경우 사용자 스토리 그리고 고객과의 대화로 요구사항을 파악할 수 있었고, 개발 범위에 대한 합의를 할
수 있었습니다. 그러나 그것만으로는 해결할 수 없는 문제가 있었습니다.
첫 번째는 개발자나 담당고객이 교체되거나, 신규 개발자를 투입해야 하거나, 원격지 개발을 해야 하는 경우 등에서 개발자 간에 고객과 합의된 요구사항 내역과 예외상황에서의 처리 방법을
공유할 수 있는 수단이 없다는 문제였습니다. 두 번째로 주요 이해관계자 식별이나 관심사항 분리, 트리거, 전반적인 시스템 규모 등을 파악하는 수단도 필요했습니다. 대부분의 고객은 시스템의 기능목록과 언제 프로젝트가 종료되는지를 알고 싶어 하기 때문입니다.

 

유스케이스는 이런 문제를 아주 훌륭하게 해결해 주었습니다. 유스케이스는
소프트웨어 공학적인 접근방법으로 적용할 땐 작성하기 어렵고 유지하는 비용도 만만치 않습니다. 하지만
실용적인 애자일 방법으로 접근한다면 살아있는 유스케이스를 만들어 이해관계자와 개발자가 하나의 목표를 바라보고 달려갈 수 있게 합니다.

『앨리스터 코오번의 유스케이스』 옮긴이의 글

앨리스터 코오번의 유스케이스 표지는 이번에 『UML 실전에서는 이것만 쓴다』의 신판을 찍으면서
표지디자인을 일관성있게 맞춰 봤습니다.

두 권 세트로 구비하면 왠지 마음이 든든할 것 같은……?!

직접 유스케이스를 사용하여 프로젝트를 수행해오신 옮긴이 임병인 님의 글 전문을 붙여드립니다. ^ ^

[#M_더보기|접기|

옮긴이의 글

 

3년 동안 진행해온 프로젝트에서 애자일(Agile) 개발방법인 스크럼을 적용해왔습니다. 제품 백로그, 스프린트 백로그로 요구사항 목록을 만들고 스프린트 계획회의, 일일
회의를 통해 사용자 스토리를 작성한 다음 스토리 점수 추정으로 일정을 계획하고 관리했습니다. 거의 대부분의
경우 사용자 스토리 그리고 고객과의 대화로 요구사항을 파악할 수 있었고, 개발 범위에 대한 합의를 할
수 있었습니다. 그러나 그것만으로는 해결할 수 없는 문제가 있었습니다.
첫 번째는 개발자나 담당고객이 교체되거나, 신규 개발자를 투입해야 하거나, 원격지 개발을 해야 하는 경우 등에서 개발자 간에 고객과 합의된 요구사항 내역과 예외상황에서의 처리 방법을
공유할 수 있는 수단이 없다는 문제였습니다. 두 번째로 주요 이해관계자 식별이나 관심사항 분리, 트리거, 전반적인 시스템 규모 등을 파악하는 수단도 필요했습니다. 대부분의 고객은 시스템의 기능목록과 언제 프로젝트가 종료되는지를 알고 싶어 하기 때문입니다.

 

유스케이스는 이런 문제를 아주 훌륭하게 해결해 주었습니다. 유스케이스는
소프트웨어 공학적인 접근방법으로 적용할 땐 작성하기 어렵고 유지하는 비용도 만만치 않습니다. 하지만
실용적인 애자일 방법으로 접근한다면 살아있는 유스케이스를 만들어 이해관계자와 개발자가 하나의 목표를 바라보고 달려갈 수 있게 합니다.

 

그렇다면 유스케이스가 어떤 특장점을 갖고
있기에
이런 문제를 해결할 수 있을까요? 저자인 앨리스터 코오번(Alistair Cockburn)은 유스케이스를 다음과 같이 소개하고 있습니다.

 

유스케이스는 이해관계자와 시스템 간의 행위와 관련된 계약 내용을 담고 있다. 유스케이스는 일차 액터라 불리는 이해관계자의 요청에 응답을 하는 시스템을 서술하는데, 요청과 응답 행위는 다양한 조건 아래서 이루어진다. 일차 액터는
어떤 목표를 달성하기 위해 시스템과 상호작용을 시작한다. 시스템은 응답하되, 모든 이해관계자의 입장을 고려한다. 서로 다른 일련의 행위, 또는 시나리오는 특정 요청이나 그 요청을 둘러싼 조건에 따라 전개할 수 있다.
유스케이스는 서로 다른 여러 시나리오의 묶음이다.”

유스케이스가 가치를 발하는 첫 번째 순간은 시스템이 지원할 사용자
목표에 유스케이스 이름을 붙이고 목록으로 작성할 때다. 이 목록은 시스템이 해야 할 일과 시스템의 범위와 목적을 나타낸다. 이 목록은 프로젝트 이해관계자 간의 의사교환
수단
이다.

두 번째로 유스케이스가 가치를 발하는 순간은 유스케이스 작성자가 성공 시나리오에서 잘못될 수 있는 모든 경우에 대해 브레인스토밍 하며, 그 결과를 나열하고, 시스템 응답을 문서로 작성할 때다. 그 순간, 수행 측 팀 구성원이나 사용자 측 요구사항 담당자들이 미처 생각하지 못했던 놀라운 것들을 발견하고는 한다.”

 

물론 유스케이스는 앞에서 얘기했던 문제를 해결할 유일한 대안이 아니라, 단지
훌륭한 대안 중하나일 뿐입니다.

 

2002Writing
Effective Use Cases
가 처음 우리말로 옮겨질 당시 우리 회사는 UP/RUP
개발방법론을 지향하고 UCDD(Use Case Driven Development)를 중심으로 개발했으므로
자연스럽게 유스케이스를 많이 강조했습니다. 새로운 프로젝트를 할 때마다 점점 풍부해지는 고객들의 사용자
경험(UX: User eXperience)에 의한 요구사항을 유스케이스로 작성해 왔습니다. 이러한 개발경험으로 이번에 다시 우리말로 옮기다 보니 예전에는 보지 못했던 것들을 볼 수 있었고 더 정확히
이해할 수 있게 되었으며 잘못 이해했던 부분과 오역된 부분들을 찾을 수 있었습니다. 이 책을 통해 죽어있는(사용되지 않는) 유스케이스가 아닌 살아있는(사용되는) 유스케이스를 제대로 활용할 수 있게 되길 바랍니다. 이 책이 최근 인기가 있는 애자일(Agile) 개발방법의 부족한
부분을 확실히 채워 줄 수 있다고 확신합니다.

 

바쁘고 힘들 때 격려의 말과 아낌없는 지원을 해준 아내와 자주 놀아주지 못한 우리 딸 수정, 우리 아들 도연에게 항상 미안하고 사랑합니다. 2002년 처음 이
책을 우리말로 옮기셨으며 수 차례의 검토 작업으로 완성도를 높여준 넥스트리소프트 송태국 부사장님과 프로젝트 중에도 1차 검토회의에 참여하여 열띤 토론을 해준 넥스트리소프트 개발서비스 2팀원들(박윤미 과장, 최영목 대리, 최인혜
대리, 강병규 대리, 박기영 대리, 김진호 사원, 최재두 사원, 임재락
사원) 정말 고맙습니다. 마지막으로 인사이트 한기성 사장님과
넥스트리소프트 손문일 사장님께도 격려와 지원에 고맙다는 말씀을 전합니다.

 

2010 12

임병인

_M#]

.

2 thoughts on “유스케이스는 다이어그램이 아니다

댓글 남기기