객체 지도 | 불안정한 재료: 기능

유스케이스는 소프트웨어가 어떤 기능을 제공해야 하는지 이해하는 데 도움이 되는 좋은 도구다. 여기서 말하는 '기능'이란, 사용자가 어떤 목표를 이루기 위해 시스템과 주고받는 흐름을 의미한다. 이 흐름을 글로 정리한 것이 바로 유스케이스다. 단순히 버튼이 뭘 한다는 설명이 아니라, 사용자가 왜 그것을 하고 싶어 하는지를 중심으로 정리한다. 그래서 유스케이스는 기능 그 자체보다는 '사용자의 목표를 이루기 위한 이야기'에 가깝다.

예를 들어, 정기예금을 가진 사용자가 중도 해지할 때 받을 수 있는 이자를 알고 싶어 한다면, 이 목표를 이루기 위해 어떤 흐름이 필요한지 차례대로 적는다. 사용자가 계좌를 선택하고, 시스템이 정보를 보여주고, 이자를 계산해 결과를 알려주는 일련의 과정을 이야기처럼 풀어내는 것이다. 때로는 해지 날짜를 변경하는 옵션 같은 다른 시나리오도 포함된다. 이런 식으로 유스케이스는 하나의 시나리오가 아니라, 목표를 중심으로 한 여러 개의 유사한 상황들을 묶은 것이다.

유스케이스는 단순히 '할 수 있는 일' 목록인 피처(feature) 목록과는 다르다. 피처는 '이 시스템은 무엇을 할 수 있다'라는 식으로 기능만 나열하지만, 유스케이스는 '누가 왜 그것을 하려고 하는가'라는 질문에서 출발한다. 그렇기 때문에 유스케이스는 시스템이 제공해야 할 기능을 더 깊이 있게 이해하고 설명하는 데 유리하다.

또한 유스케이스는 화면이 어떻게 생겼는지, 버튼이 어디에 있는지 같은 사용자 인터페이스 정보는 포함하지 않는다. 그런 정보가 들어가면 너무 구체적인 설계가 되어버려서, 오히려 본질을 흐릴 수 있다. 그래서 핵심 유스케이스는 화면 구성이나 내부 처리 방식 같은 세부사항은 뺀 채로 작성하는 것이 원칙이다. 설계나 구현 방법은 유스케이스를 바탕으로 나중에 고민하면 된다.

유스케이스는 객체지향 설계 기법도, 프로그램 구조를 정의하는 기법도 아니다. 어떤 기능이 필요한지, 어떤 목표가 존재하는지를 이해하는 도구일 뿐이다. 그렇기 때문에 유스케이스를 기반으로 객체를 설계할 때는 그저 유스케이스를 코드로 옮기는 것이 아니라, 창의적인 해석과 재구성이 필요하다. 어떤 책임을 어떤 객체에 맡길 것인지, 어떤 협력이 필요한지 등은 유스케이스가 아니라 설계자가 판단해야 하는 부분이다.

결국 유스케이스는 기능이라는 불안정한 재료를 다루기 위한 첫걸음이다. 하지만 그 자체로 완전한 설계를 만들어주지는 않는다. 그 안에 담긴 목표와 흐름을 읽어내고, 객체와 책임, 협력의 구조로 바꾸는 과정이 뒤따라야만 객체지향적인 설계로 이어질 수 있다. 유스케이스는 단순한 요구사항 문서가 아니라, 소프트웨어 설계로 가는 다리라고 생각하면 좋을 것 같다.