유스케이스만으로 설계를 완성시킬 수 있을까?

유스케이스는 사용자 관점에서 시스템이 무엇을 해야 하는지를 시나리오로 풀어낸 요구사항 분석 방법이다. 그렇다면 유스케이스만으로 설계를 완성할 수 있을까? 물론 완벽한 설계는 불가능하다. 요구사항은 계속 추가되고, 유스케이스가 담지 못하는 영역도 있다. 다만 여기서 말하는 완성은 그런 뜻이 아니다. 유스케이스만 읽고도 이 서비스가 무엇인지 설명할 수 있느냐, 그 정도를 말한다. 총 22개의 유스케이스를 그리면서 든 생각을 그대로 적어두려 한다.

간단하게 유스케이스의 구성요소부터 간단하게 확인해보자.

구성요소에는 다이어그램에서 사용이 되어지는 구성요소와 명세(다이어그램 옆에 따로 쓰는 글로)에서 사용이 되어지는 구성요소로 구분이 되어있다.

UML

요소	내용
액터	시스템 외부에서 상호작용하는 주체. 사람일 수도, 외부 시스템·스케줄러일 수도 있다
유스케이스	액터가 얻어내는 하나의 목표. 타원 하나 = 목표 하나
시스템 경계	무엇이 우리 책임이고 무엇이 바깥인지 긋는 선
관계	연관(액터-유스케이스), include(항상 포함), extend(조건부 확장), 일반화

명세 구성요소

요소	내용
이름	동사구로 쓴 액터의 목표. "쿠폰 발급" 보다 "사용자가 쿠폰을 발급받는다"
범위	이 유스케이스가 말하는 시스템의 크기
수준	사용자 목표 / 하위 기능 / 요약. 섞이면 다이어그램이 지저분해진다
주 액터	목표를 가진 쪽
이해관계자와 관심사	성공했을 때 누가 무엇을 보장받는지
사전조건	시작 시점에 이미 참이어야 하는 것
성공 보장(사후조건)	정상 종료 시 참이 되는 것
최소 보장	실패해도 깨지지 않아야 하는 것
트리거	이 흐름을 시작시키는 사건
주 성공 시나리오	번호 매긴 단계. 분기 없이 일직선
확장	각 단계에서 갈라지는 대안·예외 흐름 (3a, 3b …)
부가	빈도, 특수 요구사항, 미결 이슈

구성요소를 훑었으니, 이제 글을 어떻게 끌고 갈지 정하자. 먼저 전체를 한눈에 보는 조감도(== '버드뷰')부터 그려봤다.

대표적인 UML로 얼마나 설계가 잘 되었는지 확인해보자.

커머스의 브랜드, 상품, 재고, 주문, 포인트, 좋아요 여섯 도메인을 놓고 이야기한다. 모든 유스케이스를 다룰 수는 없으니 대표적인 한 가지만 본다. 

여기서 확인할 UML은 주문 생성 UML이다.

고객이 주문을 요청하면 주문서가 만들어진다. 이후 확정 단계에서 쿠폰을 적용하고, 재고를 차감하고, 포인트를 차감해 결제 결과를 저장한 뒤 주문 상태를 CONFIRMED로 바꾼다. 흐름만 보면 순서대로 한 번씩 하면 될 일처럼 보인다.

 예전에는 이 흐름을 그림으로 그려놓고도 할 일이 많이 남았다. 주문의 도메인 이름을 무엇으로 할지, 주문서 제작·주문 확정·주문 완료를 각각 어떤 상태값으로 표현할지 하나씩 정해야 했다. 다이어그램에는 그 답이 없다. AI는 이 정리를 빠르게 해준다. 이름 후보와 상태 목록을 몇 분 안에 뽑아주니 예전만큼 시간이 들지 않는다. 다만 어느 이름을 쓸지, 상태를 몇 개로 나눌지는 여전히 내가 정해야 한다. 빨라진 것은 정리고, 판단은 그대로 남는다.

흐름 파악은 UML이 해주고 나머지는 AI로 구현하면 된다고 생각할 수 있다. 이 생각은 반은 맞고 반은 틀리다. 어쨌든 흐름은 파악됐으니 구현하는 데는 큰 문제가 없어 보이기 때문이다.

UML으로만 설계하면 위험한 이유

하지만 몇 가지 걸림돌이 있다. 당장 주문 아이템을 OrderItem으로 부를지 OrderLine으로 부를지부터 정하지 않았다. 이는 도메인을 어디서 어떻게 찢을 것인가에 대한 답은 흐름도에서 나오지 않는다는 뜻이 된다. 결국 UML만 가지고 설계하는 건 생각보다 위험하다. 단순히 완성하는 것이라면 그것만으로 충분할 수도 있다. 하지만 '설계'라는 관점으로 보면 얘기가 달라진다. 돌아가게 만드는 것과 내가 통제하며 만드는 것의 차이가 여기에 있다.

결국, AI 시대에 내가 통제하면서 개발하려면 어떻게 해야 할까? 그 기준을 세워야 한다. 도메인을 어디까지 쪼갤 것인지, 각 도메인이 어떤 상태값을 갖는지 같은 것들이다. 다만, 어떤 아키텍처를 고르는지가 중요한 게 아니다. 이러한 정보들은 AI 시대에 처음 등장한 개념들은 아니다. 처음부터 있었다. 다만 이전과 다른 점은, 이런 규칙이 하나도 없어도 개발이 된다는 것이다.

UML로 흐름을 파악하는 것도 중요하다. 하지만 코드를 통제한다는 건 도메인을 어떻게 판단하고 정의하느냐의 문제다.

마무리

UML을 22개 그리고 그 정보를 AI에 넘겨 구현시켰습니다. 어떤 아키텍처를 쓸지는 간단히 정해뒀으니 그에 맞춰 코드가 나왔습니다. 처음에는 잘하는 것처럼 보였습니다. UML만 가지고도 개발이 되는구나 싶었습니다.

그런데 주문 항목 도메인을 보고 놀랐습니다. 저는 주문 항목에 대해 아무것도 정의하지 않았더라고요. 그게 어떤 기준으로 쪼개졌는지 저는 전혀 몰랐습니다. 그러면 이 개발을 제가 주도한 게 맞을까요.

간단한 개발이라면 UML만으로 충분합니다. 하지만 코드를 통제하고 어떤 방식이 옳은지 판단하려면 부족하였습니다. 결국, UML은 흐름을 파악하는 도구였고, 정작 신경 써야 할 것은 도메인을 어떻게 가져가느냐였습니다.