UseCase 모델

유스케이스 모델이란

유스케이스 모델(Use Case Model)은 개발 대상 시스템이 외부에 제공해야 할 기능의 범위를, 사용자와 시스템의 상호작용 관점에서 다이어그램으로 표현한 분석 산출물이다. 시스템 경계 안에 들어갈 기능 단위를 유스케이스로, 그 기능을 사용하는 주체를 액터로 두어, 누가 무엇을 할 수 있는지를 한 장의 그림으로 드러낸다.

줄글로만 적힌 요구사항은 전체 윤곽을 잡기 어렵지만, 유스케이스 모델은 개발 범위의 경계선을 시각적으로 합의하게 해 준다. 그래서 이 모델은 요구사항 정의서와 한 짝을 이루어 분석·설계 단계의 골격이 된다.

액터와 시스템 경계

유스케이스 모델의 출발점은 시스템의 경계를 긋는 일이다. 경계 안쪽은 우리가 구현할 책임 범위이고, 경계 밖에서 시스템과 주고받는 사람이나 외부 시스템이 액터가 된다.

액터를 식별한다는 것은 곧 누가 이 시스템을 쓰고 누가 책임 밖에 있는지를 명확히 하는 작업이다. 경계가 흐릿하면 개발해야 할 것과 연계만 하면 되는 것이 뒤섞여 공수 산정이 어긋난다.

따라서 액터와 경계의 정의는 단순한 그림 그리기가 아니라 계약 범위를 확정하는 행위에 가깝다.

요구사항 명세서와의 짝

유스케이스 모델은 그 자체로 완결되지 않고 요구사항 명세서와 상호 보완해야 의미를 갖는다. 다이어그램은 어떤 기능들이 있는지를 한눈에 보여 주지만, 각 기능이 구체적으로 어떤 흐름과 예외를 갖는지는 담지 못한다.

그래서 유스케이스마다 정상 흐름과 대안 흐름, 사전·사후 조건을 서술하는 명세가 따라붙어야 한다. 그림과 서술이 어긋나면 개발자는 어느 쪽을 믿어야 할지 혼란에 빠진다.

두 산출물의 식별자를 일치시켜 추적성을 확보하는 것이 분석 품질의 기본이다.

범위 합의의 도구

유스케이스 모델의 진짜 가치는 발주사와 수행사가 개발 범위를 같은 그림 위에서 합의하게 만드는 데 있다. 텍스트 요구사항은 해석의 여지가 커 나중에 범위 분쟁의 빌미가 되지만, 경계와 유스케이스 목록은 무엇이 포함되고 무엇이 빠졌는지를 분명히 한다.

모델에 그려지지 않은 기능은 이번 범위가 아니라는 합의가 가능해진다. 이 합의가 검수 기준과 변경관리의 근거로 작동한다.

결국 잘 그린 유스케이스 모델은 분석 문서이자 일종의 범위 계약서 역할을 겸한다.

객체지향 설계로의 연결

유스케이스 모델은 분석에서 멈추지 않고 객체지향 설계로 자연스럽게 이어진다. ooCBD와 같은 방법론에서는 식별된 유스케이스를 실현하기 위해 어떤 객체들이 협력해야 하는지를 분석해 설계 모델로 전개한다.

사용자 관점의 기능 단위가 내부 구조의 책임 분배로 변환되는 것이다. 이 과정에서 유스케이스가 지나치게 크면 설계가 비대해지고, 너무 잘게 쪼개면 흐름이 흩어진다.

그래서 적정한 단위로 유스케이스를 도출하는 감각이 설계 품질을 좌우한다.

흔한 오용과 한계

유스케이스 모델을 형식적인 보고용 그림으로만 그리면 분석의 본래 효용을 잃는다. 화면 단위나 메뉴 구조를 그대로 유스케이스로 옮기는 것은 흔한 오해로, 사용자가 달성하려는 목적이 아니라 구현 화면을 나열하는 데 그치기 쉽다.

또한 모든 세부 로직을 다이어그램에 욱여넣으려는 시도는 가독성을 떨어뜨려 합의 도구로서의 강점을 갉아먹는다. 모델은 범위와 상호작용의 큰 그림을 담고, 세부는 명세서에 위임하는 역할 분담이 바람직하다.

이 균형을 지킬 때 유스케이스 모델이 분석·설계의 신뢰할 만한 기준이 된다.