[카테고리:] IT

UML 다이어그램 속 네모 상자로 표현되는 클래스와 객체들이 단순한 섬으로 존재하지 않게 생명을 불어넣는 것, 그것이 바로 ‘관계(Relationship)’입니다. 이 관계들은 시스템을 구성하는 요소들 사이에 어떤 상호작용과 구조적인 연결이 있는지를 정의하는 UML의 핵심 문법입니다. 정보처리기사 시험에서는 이 관계들의 종류와 표기법을 구분하는 문제가 단골로 출제되며, 실무에서는 이 관계를 얼마나 정확하게 모델링하느냐가 시스템 설계의 품질을 좌우하는 척도가 됩니다.

이 글에서는 UML의 가장 중요한 여섯 가지 관계인 연관, 집합, 포함, 일반화, 의존, 그리고 실체화에 대해 심도 있게 파헤쳐 보겠습니다. 각 관계의 본질적인 의미와 정확한 표기법을 알아보고, 실생활의 비유와 코드 수준의 예시를 통해 그 미묘한 차이점을 명확히 구분할 것입니다. 이 글을 통해 여러분은 흩어져 있던 여섯 개의 구슬을 하나의 실로 꿰어, 시스템의 정적 구조를 꿰뚫어 보는 날카로운 통찰력을 얻게 될 것입니다.

---

연관 관계 (Association): 가장 일반적인 연결고리

서로를 인지하는 구조적 링크

연관 관계는 UML의 여러 관계 중 가장 일반적이고 광범위하게 사용되는 관계로, 두 클래스의 객체들이 서로의 존재를 인지하고 구조적으로 연결되어 있음을 나타냅니다. 한 객체가 다른 객체의 기능을 이용하거나 정보를 필요로 할 때, 이들 사이에 연관 관계가 있다고 말합니다. 다이어그램에서는 두 클래스를 실선으로 연결하여 표현하며, 이는 한 클래스의 인스턴스가 다른 클래스 인스턴스에 대한 참조(reference)를 속성(attribute)으로 가지고 있음을 의미합니다.

예를 들어, ‘학생(Student)’ 클래스와 ‘강의(Course)’ 클래스를 생각해 봅시다. 한 학생은 여러 개의 강의를 수강할 수 있고, 하나의 강의는 여러 명의 학생들로 구성됩니다. 이 경우, 학생 객체는 자신이 수강하는 강의 객체들의 목록을 속성으로 가지고, 강의 객체는 자신을 수강하는 학생 객체들의 목록을 속성으로 가질 수 있습니다. 이처럼 두 클래스가 개념적으로 연결되어 있고, 그 관계가 일정 기간 지속될 때 우리는 연관 관계를 사용합니다.

방향성과 다중도: 관계의 깊이를 더하다

연관 관계는 단순히 선 하나로 끝나지 않고, 방향성(Navigability)과 다중도(Multiplicity)를 통해 더 풍부한 정보를 표현할 수 있습니다. 방향성은 실선 끝에 열린 화살표를 추가하여 표현하며, 어느 쪽이 상대방을 인지하고 참조할 수 있는지를 나타냅니다. 만약 ‘학생’ 클래스에서 ‘강의’ 클래스로만 화살표가 있다면, 학생 객체는 자신과 연관된 강의 객체를 알 수 있지만, 강의 객체는 자신을 수강하는 학생을 알 수 없다는 단방향 관계를 의미합니다. 화살표가 양쪽에 모두 있다면 서로를 아는 양방향 관계입니다.

다중도는 관계선의 양 끝에 숫자로 표기하며, 한 클래스의 인스턴스 하나가 상대 클래스의 인스턴스 몇 개와 관계를 맺을 수 있는지를 나타냅니다. ‘1’은 정확히 하나, ‘0..1’은 없거나 하나, ‘‘ 또는 ‘0..‘은 0개 이상, ‘1..‘은 1개 이상을 의미합니다. 앞선 예시에서 학생은 여러 강의를 들을 수 있으므로 ‘학생’ 쪽 끝에는 ‘‘를, 강의 역시 여러 학생을 가질 수 있으므로 ‘강의’ 쪽 끝에도 ‘*’를 표기하여 다대다(N:M) 관계임을 명확히 할 수 있습니다.

---

집합과 포함: 전체와 부분의 이야기

집합 관계 (Aggregation): ‘가지다(has-a)’의 느슨한 형태

집합 관계는 연관 관계의 특별한 형태로, 전체(Whole)와 부분(Part)의 관계를 나타낼 때 사용됩니다. 다이어그램에서는 전체 클래스 쪽에 속이 빈 다이아몬드를 붙여 표현하며, 이는 ‘A가 B를 가진다(A has a B)’는 의미를 내포합니다. 집합 관계의 핵심적인 특징은 ‘느슨한 결합’입니다. 즉, 전체가 사라진다고 해서 부분이 반드시 함께 사라지는 것은 아닙니다. 부분은 독립적인 생명주기(Life Cycle)를 가질 수 있습니다.

예를 들어, ‘컴퓨터(Computer)’와 ‘마우스(Mouse)’, ‘키보드(Keyboard)’의 관계를 생각해 봅시다. 컴퓨터는 마우스와 키보드를 ‘부분’으로 가집니다. 하지만 컴퓨터가 없어진다고 해서 마우스나 키보드가 존재 가치를 잃고 함께 사라지지는 않습니다. 이 부품들은 다른 컴퓨터에 연결하여 계속 사용할 수 있습니다. 이처럼 전체와 부분이 독립적으로 존재할 수 있는 관계가 바로 집합 관계입니다. 팀과 선수, 학과와 교수 등의 관계도 좋은 예시가 될 수 있습니다.

포함 관계 (Composition): 생명을 함께하는 강한 결합

포함 관계, 또는 합성 관계라고도 불리는 이 관계는 집합 관계보다 훨씬 강력한 전체와 부분의 관계를 나타냅니다. 다이어그램에서는 전체 클래스 쪽에 속이 꽉 찬 다이아몬드를 붙여 표현하며, 집합 관계와 마찬가지로 ‘A가 B를 가진다’는 의미를 가집니다. 하지만 포함 관계의 핵심적인 특징은 ‘강한 결합’과 ‘생명주기의 의존성’입니다. 즉, 전체가 사라지면 부분도 반드시 함께 사라져야 합니다. 부분은 전체 없이는 독립적으로 존재할 수 없습니다.

가장 대표적인 예시는 ‘집(House)’과 ‘방(Room)’의 관계입니다. 방은 집의 명백한 ‘부분’이지만, 집이 철거되어 사라지면 그 안에 있던 방도 더 이상 존재할 수 없습니다. 방은 집이라는 전체에 완전히 소속되어 생명주기를 함께합니다. 주문(Order)과 주문 항목(OrderLine)의 관계도 마찬가지입니다. 특정 주문이 취소되어 사라지면, 그 주문에 속해 있던 주문 항목들도 의미를 잃고 함께 사라져야 합니다. 이처럼 강력한 소유의 개념을 표현할 때 포함 관계를 사용합니다.

---

일반화 관계 (Generalization): ‘이다(is-a)’의 상속 계층

부모와 자식, 그리고 상속

일반화 관계는 객체지향 프로그래밍의 ‘상속(Inheritance)’ 개념을 그대로 표현하는 관계입니다. 이는 ‘A는 B의 한 종류이다(A is a kind of B)’라는 ‘is-a’ 관계를 나타냅니다. 다이어그램에서는 더 구체적인 자식 클래스(Subclass)에서 더 추상적인 부모 클래스(Superclass) 쪽으로 속이 빈 삼각형 화살표가 달린 실선을 그어 표현합니다.

예를 들어, ‘동물(Animal)’이라는 부모 클래스가 있고, ‘개(Dog)’와 ‘고양이(Cat)’라는 자식 클래스가 있다고 합시다. 개와 고양이는 모두 동물의 한 종류이므로, 이들은 동물 클래스를 상속받는 일반화 관계에 있습니다. 이를 통해 자식 클래스들은 부모 클래스가 가진 속성(예: 이름, 나이)과 행동(예: 먹다, 자다)을 그대로 물려받아 사용할 수 있으며, 여기에 더해 자신만의 고유한 속성(예: 꼬리 길이)이나 행동(예: 짖다, 야옹하다)을 추가하거나, 부모의 행동을 자신에 맞게 재정의(Override)할 수 있습니다.

코드 재사용과 다형성의 실현

일반화 관계를 사용하는 가장 큰 이유는 코드의 재사용성을 높이고 구조를 체계화하기 위함입니다. 여러 클래스에 공통으로 존재하는 속성과 행동들을 부모 클래스로 추출하여 한 곳에서 관리함으로써, 중복 코드를 줄이고 유지보수성을 향상시킬 수 있습니다. 새로운 종류의 동물이 추가되더라도, 동물 클래스를 상속받기만 하면 기본적인 기능들을 다시 구현할 필요가 없어 확장에도 용이합니다.

더 나아가 일반화 관계는 객체지향의 핵심 원리 중 하나인 ‘다형성(Polymorphism)’을 실현하는 기반이 됩니다. 다형성이란 ‘하나의 타입으로 여러 다른 형태의 객체를 참조할 수 있는 성질’을 의미합니다. 예를 들어, 우리는 ‘동물’이라는 타입의 변수에 ‘개’ 객체를 담을 수도 있고, ‘고양이’ 객체를 담을 수도 있습니다. 그리고 이 변수에 ‘소리를 내라’는 동일한 메시지를 보내더라도, 실제 담겨있는 객체가 개라면 ‘멍멍’하고 짖고, 고양이라면 ‘야옹’하고 우는 등 각자 재정의한 방식으로 동작하게 됩니다. 이는 유연하고 확장 가능한 소프트웨어를 만드는 핵심적인 원리입니다.

---

의존과 실체화: 행위와 약속의 관계

의존 관계 (Dependency): 잠시 스쳐 가는 인연

의존 관계는 여섯 가지 관계 중 가장 약한 연결고리를 나타내며, 한 클래스가 다른 클래스를 매우 짧은 시간 동안만 사용하는 일시적인 관계를 표현합니다. 다이어그램에서는 사용하는 쪽(Client)에서 사용되는 쪽(Supplier)으로 점선 화살표를 그어 표현합니다. 이는 연관 관계처럼 속성으로 참조를 유지하는 영구적인 관계가 아니라, 특정 메서드를 실행하는 동안에만 지역 변수나 매개변수 등을 통해 잠시 참조하고 사용하는 경우를 의미합니다.

예를 들어, ‘주방장(Chef)’ 클래스가 ‘요리하다(cook)’라는 메서드 안에서 ‘소금(Salt)’ 클래스를 사용한다고 생각해 봅시다. 주방장은 소금을 소유하거나 항상 들고 다니는 것이 아니라, 요리하는 특정 순간에만 잠시 가져다 사용하고 돌려놓습니다. 이처럼 ‘Chef’가 ‘Salt’를 ‘uses-a’ 하는 관계가 바로 의존 관계입니다. 한 클래스가 변경될 때 다른 클래스가 영향을 받는다면 일단 의존 관계가 있다고 볼 수 있으며, 이는 클래스 간의 결합도를 나타내는 중요한 지표가 됩니다.

실체화 관계 (Realization): 약속을 구현하다

실체화 관계는 ‘인터페이스(Interface)’와 그 인터페이스를 실제 기능으로 구현하는 ‘구현 클래스(Implementation Class)’ 사이의 관계를 나타냅니다. 인터페이스는 ‘무엇을 해야 하는지’에 대한 기능의 목록, 즉 메서드의 이름과 입출력 형식만을 정의한 ‘약속’ 또는 ‘규격’입니다. 실체화 관계는 바로 이 추상적인 약속을 구체적인 클래스가 실제로 ‘어떻게 할 것인지’를 코드로 구현했음을 의미합니다. 다이어그램에서는 구현 클래스에서 인터페이스 쪽으로 속이 빈 삼각형 화살표가 달린 점선을 그어 표현합니다.

예를 들어, Flyable이라는 ‘날 수 있는’ 기능에 대한 인터페이스가 있고, 여기에는 fly()라는 추상 메서드가 정의되어 있다고 합시다. ‘새(Bird)’와 ‘비행기(Airplane)’ 클래스는 모두 날 수 있으므로, 이 Flyable 인터페이스를 상속받아 fly() 메서드를 각자의 방식대로 구체적으로 구현해야 합니다. 이때 ‘Bird’와 ‘Airplane’은 Flyable 인터페이스를 실체화했다고 말합니다. 이는 “나는 날 수 있다는 약속을 지켰습니다”라고 선언하는 것과 같으며, 다중 상속이 불가능한 언어에서 다중 상속의 효과를 내는 중요한 메커니즘이기도 합니다.

---

마무리하며: 관계를 통해 시스템의 구조를 그리다

지금까지 우리는 클래스 다이어그램의 뼈대를 이루는 여섯 가지 핵심 관계들을 하나씩 자세히 살펴보았습니다. 객체 간의 일반적인 연결을 나타내는 ‘연관’, 전체와 부분의 관계를 표현하는 ‘집합’과 ‘포함’, 상속 계층을 그리는 ‘일반화’, 일시적인 사용을 의미하는 ‘의존’, 그리고 약속의 구현을 나타내는 ‘실체화’까지. 이 여섯 가지 관계는 각각 뚜렷한 의미와 뉘앙스를 가지고 있으며, 어떤 관계를 선택하여 사용하느냐에 따라 설계의 의도가 완전히 달라질 수 있습니다.

정보처리기사 시험을 준비하는 여러분에게 이 관계들을 구분하는 능력은 필수적입니다. 하지만 여기서 더 나아가, 각 관계가 실제 코드에서 어떻게 표현되고, 시스템의 유연성, 재사용성, 유지보수성에 어떤 영향을 미치는지를 이해하는 것이야말로 진정한 실력의 척도가 될 것입니다. 이 여섯 가지 관계라는 풍부한 표현 도구를 손에 쥔 여러분은 이제 복잡하게 얽힌 시스템의 구조를 명쾌하게 풀어내고, 견고하며 유연한 소프트웨어를 설계하는 유능한 아키텍트로 성장해 나갈 수 있을 것입니다.

시퀀스 다이어그램이라는 정교한 언어를 유창하게 구사하기 위해서는 그 언어를 구성하는 기본적인 문법 요소들을 완벽하게 이해해야 합니다. 바로 상호작용의 주체인 ‘객체(Object)’, 객체의 존재를 나타내는 ‘생명선(Lifeline)’, 객체가 활발히 동작하는 순간을 보여주는 ‘실행(Execution)’, 그리고 객체들 사이의 소통을 담당하는 ‘메시지(Message)’가 그 주인공입니다. 이 네 가지 요소는 마치 문장을 구성하는 주어, 시간, 동사, 목적어처럼 각자의 명확한 역할을 가지고 유기적으로 결합하여 하나의 완성된 시나리오를 만들어냅니다.

이 글은 정보처리기사 시험을 준비하고 실무 역량을 키우고자 하는 여러분을 위해, 시퀀스 다이어그램의 가장 근본적인 네 가지 구성요소를 뼛속까지 파고드는 깊이 있는 탐험을 제공할 것입니다. 각 요소의 정확한 표기법과 본질적인 의미를 파헤치고, 다른 개념과의 차이점을 명확히 하며, 다양한 유형과 그 안에 숨겨진 미묘한 뉘앙스까지 상세히 설명할 것입니다. 이 글을 마치고 나면, 여러분은 단순한 다이어그램 독해를 넘어, 시스템의 복잡한 상호작용을 정확하고 우아하게 표현하는 설계자로서의 자신감을 갖게 될 것입니다.

---

객체 (Object): 상호작용의 주인공들

객체의 표현과 본질

시퀀스 다이어그램의 가장 상단에 위치하여 상호작용의 출발점이자 경유지, 목적지가 되는 참여자들을 바로 객체라고 합니다. 객체는 시스템을 구성하는 소프트웨어적인 부품으로, 자신만의 데이터와 행동(메서드)을 가지고 있습니다. 다이어그램에서는 일반적으로 ‘객체이름:클래스이름’ 형식으로 사각형 안에 표기하며, 이름 아래에는 밑줄을 긋는 것이 표준 표기법입니다. 예를 들어, ‘Order’라는 클래스로부터 생성된 특정 주문 객체는 myOrder:Order 와 같이 표현할 수 있습니다.

여기서 중요한 점은 다이어그램에 표현되는 것이 ‘클래스’라는 설계도 자체가 아니라, 그 설계도로부터 만들어진 실제 ‘인스턴스(객체)’라는 사실입니다. 클래스는 빵 틀이고, 객체는 그 빵 틀로 찍어낸 빵에 비유할 수 있습니다. 시퀀스 다이어그램은 이 실제 빵(객체)들이 서로 어떻게 정보를 주고받으며 하나의 요리를 완성하는지를 보여주는 레시피와 같습니다. 때로는 특정 객체의 이름을 명시할 필요 없이 클래스의 역할만 표현하고 싶을 때 _ :Order_ 와 같이 익명(Anonymous) 객체로 표기하기도 합니다.

액터와 객체의 구분

시퀀스 다이어그램을 처음 접할 때 많은 이들이 유스케이스 다이어그램의 액터와 시퀀스 다이어그램의 객체를 혼동하곤 합니다. 액터는 시스템 외부에 존재하는 역할이며, 객체는 시스템 내부에 존재하는 부품이라는 근본적인 차이가 있습니다. 하지만 시퀀스 다이어그램에서 액터는 상호작용을 시작하는 매우 중요한 참여자로 등장합니다. 일반적으로 다이어그램의 가장 왼쪽에 사람 모양의 아이콘과 함께 액터의 이름을 표기하여, 이 액터의 행동으로부터 모든 시나리오가 시작됨을 알립니다.

예를 들어, ‘사용자’라는 액터가 ‘로그인’ 버튼을 클릭하는 행위는 시퀀스 다이어그램에서 ‘:사용자’ 액터가 :로그인화면 객체에게 ‘로그인요청()’ 메시지를 보내는 것으로 표현됩니다. 즉, 액터는 시스템 외부에서 시스템 내부의 객체에게 최초의 메시지를 전달하는 역할을 수행합니다. 그 이후의 상호작용은 시스템 내부의 객체들, 예를 들어 :로그인화면이 :인증서버에게, :인증서버가 :데이터베이스에게 메시지를 보내는 식으로 연쇄적으로 일어납니다. 액터는 이 모든 내부 동작의 시발점인 셈입니다.

---

생명선과 실행: 객체의 삶과 활동

생명선(Lifeline): 시간의 흐름을 따르는 객체의 존재

생명선은 다이어그램 상단의 각 객체 사각형으로부터 아래쪽으로 곧게 뻗어 나가는 점선을 의미합니다. 이 선은 이름 그대로 해당 객체가 특정 시나리오가 진행되는 동안 메모리 상에 존재하며 살아있음을 나타내는 시간의 축입니다. 다이어그램의 위쪽은 이른 시간, 아래쪽은 늦은 시간을 의미하므로, 생명선은 객체의 전체적인 수명 또는 상호작용에 참여하는 기간을 시각적으로 보여줍니다.

모든 메시지는 하나의 생명선에서 출발하여 다른 생명선으로 향하며, 객체의 실행(Activation) 또한 이 생명선 위에서 일어납니다. 생명선 자체는 객체가 존재하는 상태를 나타낼 뿐, 무언가를 하고 있음을 의미하지는 않습니다. 객체가 실제로 작업을 수행하는 활성화된 순간은 생명선 위에 ‘실행’을 나타내는 별도의 상자로 표현됩니다. 따라서 생명선은 객체라는 배우가 서 있는 무대 위의 시간 축이며, 모든 드라마는 이 축을 따라 펼쳐집니다.

실행(Activation): 생명선 위의 활기찬 순간

실행, 또는 활성 상자(Activation Box)는 생명선 위에 그려지는 얇고 긴 직사각형으로, 객체가 메시지를 받아 특정 연산을 능동적으로 수행하고 있는 기간을 나타냅니다. 즉, 객체가 잠자코 있는 상태가 아니라, 무언가에 집중하여 ‘일하고 있는’ 활성화된 상태임을 보여줍니다. 동기 메시지를 수신하는 순간 이 실행 상자가 시작되고, 관련된 모든 작업을 마친 후 결과를 반환하거나 제어권을 넘겨줄 때 상자가 끝나게 됩니다.

예를 들어, :주문서비스 객체가 :결제게이트웨이에게 결제요청()이라는 동기 메시지를 보냈다고 가정해 봅시다. :주문서비스의 생명선 위에는 :결제게이트웨이가 응답을 줄 때까지 기다리는 기간 동안 실행 상자가 그려져 있을 것입니다. 동시에 메시지를 받은 :결제게이트웨이의 생명선 위에도 결제를 처리하는 동안 실행 상자가 그려집니다. 이 상자들의 시작과 끝, 그리고 길이를 통해 어떤 객체가 언제 작업을 시작하고 끝내는지, 그리고 다른 객체의 작업이 끝날 때까지 기다리는지 등의 상세한 시간적 관계를 명확히 파악할 수 있습니다.

생성(Create)과 소멸(Destroy) 메시지

모든 객체가 시나리오 시작부터 끝까지 계속 존재하지는 않습니다. 특정 조건에서 새로운 객체가 생성되거나, 역할이 끝난 객체가 소멸될 수도 있습니다. 시퀀스 다이어그램은 이러한 객체의 생성과 소멸 또한 표현할 수 있습니다. 객체 생성은 <<create>> 스테레오타입을 가진 메시지를 객체 사각형으로 직접 연결하여 표현합니다. 이 경우, 생성되는 객체의 생명선은 다이어그램의 맨 위가 아닌, 생성 메시지를 받는 시점부터 시작됩니다.

반대로 객체의 소멸은 해당 객체의 생명선 끝에 큰 ‘X’ 표시를 하고, 다른 객체로부터 <<destroy>> 스테레오타입을 가진 메시지를 받아 표현합니다. 예를 들어, 사용자가 임시 장바구니에 상품을 담았다가 주문을 완료하면, 해당 주문을 처리하기 위해 _ :주문상세_ 객체가 동적으로 생성될 수 있습니다. 그리고 주문 처리가 모두 끝나면 이 객체는 더 이상 필요 없으므로 소멸 메시지를 통해 메모리에서 해제될 수 있습니다. 이러한 생성과 소멸의 표현은 시스템의 자원 관리를 어떻게 설계할지 보여주는 중요한 정보가 됩니다.

---

메시지 (Message): 객체 간의 소통 방식

동기 메시지(Synchronous): 기다림의 미학

동기 메시지는 시퀀스 다이어그램에서 가장 흔하게 사용되는 소통 방식으로, 메시지를 보낸 객체(Sender)가 받는 객체(Receiver)의 작업이 끝나고 응답이 돌아올 때까지 자신의 다음 동작을 멈추고 기다리는 호출 방식을 의미합니다. 이는 속이 꽉 찬 삼각형 머리를 가진 실선 화살표로 표현됩니다. 마치 우리가 누군가에게 중요한 질문을 던지고 그 대답을 들을 때까지 가만히 기다리는 것과 같은 이치입니다.

예를 들어, :로그인컨트롤러가 :사용자인증서비스에게 사용자검증(id, pw)이라는 동기 메시지를 보냈다면, :로그인컨트롤러는 :사용자인증서비스가 “인증 성공” 또는 “인증 실패”라는 응답을 돌려줄 때까지 다른 어떤 작업도 수행하지 않고 대기 상태에 있게 됩니다. 이 방식은 작업의 순서가 매우 중요하고, 앞선 작업의 결과값이 다음 작업에 반드시 필요한 경우에 사용됩니다. 시스템의 대부분의 핵심 로직은 이러한 동기적 호출의 연속으로 이루어집니다.

비동기 메시지(Asynchronous): 독립적인 실행의 약속

비동기 메시지는 동기 메시지와는 정반대로, 메시지를 보낸 객체가 받는 객체의 응답을 기다리지 않고 즉시 자신의 다음 작업을 수행하는 호출 방식입니다. 이는 일반적인 열린 화살촉을 가진 실선 화살표로 표현됩니다. 상대방이 확인하든 안 하든 상관없이 일단 메시지만 보내놓고 내 할 일을 계속하는 이메일이나 문자 메시지를 보내는 행위에 비유할 수 있습니다.

이러한 방식은 응답을 즉시 받을 필요가 없거나, 처리하는 데 시간이 오래 걸리는 작업을 요청할 때 매우 유용합니다. 예를 들어, 사용자의 주문이 완료된 후 :주문서비스가 :알림서비스에게 주문완료이메일발송()이라는 비동기 메시지를 보낼 수 있습니다. 이메일을 발송하는 데 몇 초가 걸리더라도, :주문서비스는 그 작업을 기다릴 필요 없이 즉시 사용자에게 “주문이 성공적으로 완료되었습니다”라는 화면을 보여줄 수 있습니다. 이처럼 비동기 메시지는 시스템의 응답성을 높이고 사용자 경험을 향상시키는 데 중요한 역할을 합니다.

반환 메시지(Return): 작업 완료의 증거

반환 메시지는 동기 메시지 호출에 대한 응답이 돌아오는 것을 명시적으로 표현하는 데 사용됩니다. 이는 점선으로 된 열린 화살표로 표현되며, 동기 메시지를 받았던 객체의 실행 상자 끝에서 동기 메시지를 보냈던 객체의 실행 상자로 향합니다. 이 메시지는 단순히 제어권이 돌아왔음을 알릴 수도 있고, 화살표 위에 isSuccess:boolean 이나 orderId:String 과 같이 구체적인 반환값을 함께 표기하여 작업의 결과물을 명확히 할 수도 있습니다.

다만, 시퀀스 다이어그램에서는 모든 동기 호출에 대해 반환 메시지를 반드시 그려야 하는 것은 아닙니다. 제어권이 반환되는 흐름이 명확하고 굳이 반환값을 표현할 필요가 없다면, 다이어그램을 간결하게 유지하기 위해 생략하는 경우가 많습니다. 하지만 특정 작업의 성공 여부나 결과값이 이후의 로직 흐름에 중요한 분기 조건이 되는 경우에는, 반환 메시지를 명확히 그려주어 흐름을 이해하는 데 도움을 주는 것이 좋습니다.

---

마무리하며: 시나리오를 연주하는 네 개의 악기

지금까지 우리는 시퀀스 다이어그램이라는 정교한 악보를 구성하는 네 개의 핵심 악기, 즉 객체, 생명선, 실행, 그리고 메시지에 대해 깊이 있게 알아보았습니다. 무대 위에 등장하는 배우인 ‘객체’, 그들이 존재하는 시간의 축인 ‘생명선’, 배우들이 열연을 펼치는 순간인 ‘실행’, 그리고 그들이 주고받는 대사인 ‘메시지’. 이 네 가지 요소가 어떻게 조화롭게 어우러지느냐에 따라 시스템의 시나리오가 얼마나 명확하고 아름답게 연주될 수 있는지가 결정됩니다.

정보처리기사 시험을 준비하는 과정에서 이들의 표기법과 개념을 정확히 암기하는 것은 기본입니다. 그러나 여기서 더 나아가, 각 요소가 왜 필요하며 어떤 뉘앙스의 차이를 만들어내는지를 이해할 때 비로소 여러분은 단순한 악보 독해자를 넘어, 복잡한 아이디어를 명쾌한 시나리오로 작곡해내는 능숙한 지휘자가 될 수 있습니다. 이 네 가지 문법 요소를 자유자재로 다루는 능력은 여러분이 마주할 모든 설계 문제에 대한 자신감의 원천이 될 것입니다.

유스케이스 다이어그램이 시스템의 ‘무엇을’ 보여주는 영화 포스터였다면, 시퀀스 다이어그램은 그 포스터 속 장면이 실제로 어떻게 펼쳐지는지를 상세히 보여주는 영화의 ‘시나리오’ 또는 ‘콘티’와 같습니다. 이 다이어그램은 특정 기능을 완성하기 위해 시스템 내부의 객체들이 어떤 순서로, 그리고 어떤 메시지를 주고받으며 협력하는지를 시간의 흐름에 따라 생생하게 보여줍니다. 정보처리기사 시험에서는 동적 모델링의 핵심으로 출제되며, 실무에서는 개발자와 기획자 사이의 오해를 막고 복잡한 로직을 명확히 하는 가장 강력한 설계 도구 중 하나입니다.

이 글에서는 시퀀스 다이어그램을 완벽하게 마스터하기 위한 모든 것을 다룰 것입니다. 다이어그램의 본질적인 역할과 목적에서부터 시작하여, 상호작용을 구성하는 핵심 요소들인 객체, 생명선, 메시지 등을 상세히 알아봅니다. 나아가 ‘if-else’나 ‘loop’와 같은 복잡한 제어 흐름을 표현하는 인터랙션 프래그먼트의 사용법을 마스터하고, 실제 온라인 주문 시나리오를 통해 다이어그램을 단계별로 작성하는 과정을 따라가 볼 것입니다. 마지막으로 이 강력한 도구를 실무에서 어떻게 활용하고, 작성 시 무엇을 주의해야 하는지 알아보며 성공적인 시스템 설계를 위한 통찰력을 얻게 될 것입니다.

---

시퀀스 다이어그램이란 무엇인가?

동적 상호작용의 시각화

시퀀스 다이어그램은 UML(Unified Modeling Language)의 여러 다이어그램 중 상호작용 다이어그램(Interaction Diagram)에 속하며, 이름 그대로 시스템의 ‘동적’인 측면을 모델링하는 데 특화되어 있습니다. 여기서 동적이라는 말은 시스템이 멈춰 있는 구조가 아니라, 시간의 흐름에 따라 객체들 간에 메시지를 주고받으며 상태가 변해가는 살아있는 모습을 의미합니다. 다이어그램의 가로축에는 상호작용에 참여하는 객체들이 나열되고, 세로축은 위에서 아래로 흐르는 시간을 나타냅니다.

이 다이어그램의 가장 큰 강점은 복잡한 상호작용의 순서를 명확하게 보여준다는 것입니다. 어떤 객체가 먼저 메시지를 보내고, 그 메시지를 받은 객체는 어떤 처리를 한 뒤 누구에게 다음 메시지를 보내는지, 그리고 최종적으로 어떤 결과가 반환되는지의 전 과정을 한눈에 파악할 수 있습니다. 이는 텍스트로 된 요구사항 명세서만으로는 파악하기 어려운 로직의 순서나 타이밍 문제를 시각적으로 명확하게 드러내 줍니다.

유스케이스를 구체화하는 설계도

시퀀스 다이어그램은 독립적으로 존재하는 것이 아니라, 앞서 우리가 배웠던 유스케이스 다이어그램과 긴밀한 관계를 맺습니다. 하나의 유스케이스는 사용자의 관점에서 본 ‘하나의 목표’를 나타내는데, 시퀀스 다이어그램은 바로 그 목표를 달성하기 위해 시스템 내부의 객체들이 ‘어떻게’ 협력하는지를 상세하게 풀어내는 역할을 합니다. 즉, 유스케이스 하나를 실현(Realize)하기 위해 하나 이상의 시퀀스 다이어그램이 작성될 수 있습니다.

예를 들어, ‘상품을 주문하다’라는 유스케이스가 있다면, 주문이 정상적으로 성공하는 시나리오에 대한 시퀀스 다이어그램이 하나 만들어질 수 있습니다. 그리고 ‘재고가 부족할 경우’나 ‘결제에 실패할 경우’와 같은 예외적인 시나리오에 대해서도 별도의 시퀀스 다이어그램을 작성하여 각 상황에 대한 시스템의 동작을 명확하게 정의할 수 있습니다. 이처럼 시퀀스 다이어그램은 추상적인 수준의 유스케이스와 실제 코드로 구현될 상세한 설계 사이의 간극을 메워주는 핵심적인 다리 역할을 수행합니다.

---

시퀀스 다이어그램의 핵심 구성요소

객체 (Object)와 생명선 (Lifeline): 상호작용의 참여자들

시퀀스 다이어그램의 가장 위쪽에는 상호작용에 참여하는 주체들, 즉 객체(Object)가 사각형 안에 이름과 함께 표시됩니다. 객체는 ‘객체이름:클래스이름’ 형식으로 표기하며, 밑줄을 긋는 것이 원칙입니다. 예를 들어, 주문을 처리하는 컨트롤러 객체는 :주문컨트롤러 와 같이 표현할 수 있습니다. 유스케이스의 액터 역시 상호작용의 시작점이 되는 중요한 참여자로서 다이어그램의 첫 번째 객체로 등장할 수 있습니다.

각 객체의 사각형 아래로는 세로로 점선이 길게 뻗어 나오는데, 이를 생명선(Lifeline)이라고 부릅니다. 생명선은 말 그대로 해당 객체가 메모리에 생성되어 상호작용이 진행되는 동안 살아있음을 나타냅니다. 다이어그램의 모든 상호작용은 이 생명선 위에서 펼쳐지며, 만약 특정 시점에 객체가 소멸한다면 생명선 끝에 ‘X’ 표시를 하여 표현할 수도 있습니다. 이처럼 객체와 생명선은 시퀀스 다이어그램이라는 무대 위에서 연기하는 배우들과 같다고 할 수 있습니다.

활성 상자 (Activation Box): 객체가 일하는 시간

생명선 위에 그려지는 얇고 긴 직사각형을 활성 상자(Activation Box) 또는 실행 명세(Execution Specification)라고 부릅니다. 이는 해당 객체가 어떤 메시지를 받아 특정 연산을 수행하고 있는 기간, 즉 ‘활성화’되어 일하고 있는 상태임을 나타냅니다. 메시지가 객체에 도달하면 활성 상자가 시작되고, 객체가 자신의 일을 모두 마치고 제어권을 반환하면 활성 상자가 끝나게 됩니다.

활성 상자의 길이는 해당 작업이 소요되는 시간의 길이를 시각적으로 표현합니다. 만약 한 객체가 다른 객체에게 메시지를 보내고 응답을 기다리는 동안에는, 첫 번째 객체의 활성 상자가 두 번째 객체의 활성 상자가 끝날 때까지 계속 이어집니다. 또한, 한 객체가 내부적으로 복잡한 작업을 수행하기 위해 자기 자신에게 다시 메시지를 보내는 경우(재귀 호출), 기존의 활성 상자 위에 새로운 활성 상자가 겹쳐서 그려지기도 합니다. 이를 통해 어떤 객체가 언제, 얼마나 오랫동안 작업에 관여하는지를 직관적으로 파악할 수 있습니다.

메시지 (Message): 객체 간의 대화

메시지는 객체들이 서로 주고받는 신호이자 요청으로, 시퀀스 다이어그램의 핵심적인 동적 요소를 구성합니다. 메시지는 객체의 생명선 사이를 연결하는 화살표로 표현되며, 그 종류에 따라 화살표의 모양과 의미가 달라집니다. 가장 일반적으로 사용되는 것은 동기 메시지(Synchronous Message)로, 속이 채워진 삼각형 화살표로 그립니다. 이는 메시지를 보낸 객체(Sender)가 메시지를 받은 객체(Receiver)로부터 응답이 올 때까지 아무 작업도 하지 않고 기다리는 것을 의미합니다. 마치 전화를 걸고 상대방이 말을 마칠 때까지 기다리는 것과 같습니다.

반면, 비동기 메시지(Asynchronous Message)는 일반적인 선 모양 화살표로 그리며, 보낸 객체가 응답을 기다리지 않고 즉시 자신의 다음 작업을 계속 진행하는 것을 나타냅니다. 문자 메시지나 이메일을 보내는 것에 비유할 수 있습니다. 동기 메시지에 대한 응답을 나타내는 반환 메시지(Return Message)는 점선 화살표로 표현하며, 작업의 결과값이나 제어권이 반환됨을 보여줍니다. 마지막으로 객체가 자기 자신의 메서드를 호출하는 자체 메시지(Self-Message)는 자기 자신의 생명선으로 돌아오는 화살표로 그립니다.

---

시나리오를 제어하는 힘: 인터랙션 프래그먼트

조건 분기 (alt: Alternative): ‘if-else’ 로직의 표현

실제 시스템의 로직은 단순히 순서대로만 흘러가지 않고, 특정 조건에 따라 다른 경로를 선택하는 경우가 많습니다. 이러한 ‘if-else’와 같은 조건 분기 로직을 표현하기 위해 사용하는 것이 바로 대안(alternative)을 의미하는 alt 인터랙션 프래그먼트입니다. alt 프래그먼트는 ‘alt’라는 이름표가 달린 사각형으로 표현되며, 사각형 내부는 점선으로 여러 구획(operand)으로 나뉩니다.

각 구획은 대괄호 [] 안에 보호 조건(Guard Condition)을 가집니다. 예를 들어, 주문 처리 과정에서 재고를 확인한 후, [재고 있음] 이라는 조건이 참일 경우 첫 번째 구획의 상호작용(결제 요청 등)이 실행됩니다. 만약 이 조건이 거짓이고 [재고 없음] 이라는 조건이 참이라면, 점선 아래의 두 번째 구획에 정의된 상호작용(오류 메시지 표시 등)이 실행됩니다. 이처럼 alt 프래그먼트를 사용하면 복잡한 조건부 시나리오를 명확하고 구조적으로 표현할 수 있습니다.

선택적 실행 (opt: Optional): ‘if’ 로직의 표현

선택(optional)을 의미하는 opt 프래그먼트는 alt와 유사하지만, ‘else’가 없는 단일 ‘if’ 문과 같은 로직을 표현할 때 사용합니다. 즉, 특정 조건이 만족될 경우에만 실행되고, 그렇지 않으면 아무 일도 일어나지 않고 그냥 지나가는 시나리오를 모델링합니다. opt 프래그먼트 역시 ‘opt’라는 이름표가 달린 사각형과 대괄호 안의 보호 조건을 가집니다.

예를 들어, 사용자가 상품을 주문할 때, [쿠폰 보유] 라는 조건이 참일 경우에만 쿠폰 적용과 관련된 상호작용이 일어나고, 쿠폰이 없다면 해당 프래그먼트 전체를 건너뛰고 다음 절차로 진행됩니다. alt 프래그먼트는 여러 대안 중 하나를 반드시 선택해야 하는 상황에 사용되는 반면, opt 프래그먼트는 특정 로직을 실행할 수도 있고, 안 할 수도 있는 선택적인 상황을 간결하게 표현하는 데 매우 유용합니다.

반복 실행 (loop: Loop): ‘for’ 또는 ‘while’ 로직의 표현

반복(Loop) 프래그먼트는 이름 그대로 ‘for’나 ‘while’문과 같이 특정 상호작용을 여러 번 반복해서 실행해야 할 때 사용합니다. loop라는 이름표가 달린 사각형으로 표현하며, 보호 조건에는 반복 횟수나 반복 조건을 명시합니다. 예를 들어, 장바구니에 담긴 모든 상품의 목록을 화면에 표시하는 시나리오를 생각해 볼 수 있습니다.

이때 loop [장바구니에 상품이 있는 동안] 과 같은 조건을 사용하여, 장바구니의 각 상품에 대해 ‘상품 정보 조회’, ‘화면에 표시’와 같은 일련의 메시지 교환을 반복적으로 수행하는 과정을 표현할 수 있습니다. 또는 loop(1, 5) 와 같이 최소, 최대 반복 횟수를 명시하여 고정된 횟수만큼 반복하는 로직을 나타낼 수도 있습니다. 이를 통해 반복적인 작업의 흐름을 다이어그램 상에서 명확하게 인지할 수 있습니다.

---

실전! 시퀀스 다이어그램 작성하기: 온라인 주문 예시

1단계: 참여 객체 정의

이제 실제 시나리오를 바탕으로 시퀀스 다이어그램을 작성해 보겠습니다. 가장 대표적인 예시인 ‘사용자가 온라인 쇼핑몰에서 상품을 주문하는’ 시나리오를 선택하겠습니다. 이 시나리오를 실현하기 위해 어떤 참여자들이 필요할지, 즉 객체들을 먼저 정의해야 합니다.

가장 먼저 상호작용을 시작하는 액터인 :사용자가 필요합니다. 사용자가 직접 상호작용하는 화면인 :상품상세페이지도 객체로 정의할 수 있습니다. 사용자의 요청을 받아 비즈니스 로직을 총괄하는 :주문컨트롤러, 실제 주문 관련 핵심 로직을 처리하는 :주문서비스, 상품의 재고를 관리하는 외부 시스템인 :재고시스템, 그리고 결제를 담당하는 :결제게이트웨이를 참여 객체로 식별할 수 있습니다. 이렇게 정의된 객체들을 다이어그램 상단에 가로로 나열하는 것이 첫 번째 단계입니다.

2단계: 시간 순서에 따른 메시지 흐름 그리기

객체 정의가 끝났다면, 이제 시나리오의 흐름에 따라 객체 간에 오가는 메시지를 시간 순서대로 그려나갑니다. 상호작용은 사용자의 행동으로 시작됩니다. :사용자가 :상품상세페이지에서 ‘주문하기’ 버튼을 클릭하는 것으로 첫 메시지가 발생합니다. 그러면 :상품상세페이지는 입력된 주문 정보를 담아 :주문컨트롤러에게 주문요청() 이라는 동기 메시지를 보냅니다.

요청을 받은 :주문컨트롤러는 다시 핵심 로직을 담고 있는 :주문서비스에게 주문생성() 메시지를 보냅니다. :주문서비스는 주문을 생성하기 전, 먼저 :재고시스템에게 재고확인() 메시지를 보내 해당 상품의 재고가 충분한지 확인을 요청합니다. :재고시스템은 재고 확인 후 그 결과를 :주문서비스에게 반환 메시지로 전달합니다. 이처럼 하나의 요청이 여러 객체들을 거치며 처리되는 과정을 순서대로 그려나갑니다.

3단계: 인터랙션 프래그먼트로 시나리오 구체화

기본적인 메시지 흐름이 완성되었다면, 이제 인터랙션 프래그먼트를 사용하여 조건과 반복이 포함된 상세한 시나리오를 표현할 차례입니다. 앞선 2단계에서 :재고시스템으로부터 재고 확인 결과를 반환받은 시점을 기준으로 alt 프래그먼트를 추가할 수 있습니다.

첫 번째 구획의 보호 조건을 [재고 있음]으로 설정하고, 그 안에는 주문을 계속 진행하는 흐름을 그립니다. :주문서비스가 :결제게이트웨이에게 결제요청() 메시지를 보내고, 결제가 성공하면 최종적으로 :사용자에게 주문 완료 페이지를 보여주는 흐름입니다. 그리고 점선 아래 두 번째 구획의 보호 조건은 [재고 없음]으로 설정하고, 그 안에는 :주문서비스가 :주문컨트롤러에게 재고 부족 오류를 반환하고, 최종적으로 :사용자에게 “재고가 부족합니다”라는 알림을 보여주는 흐름을 그립니다. 이로써 하나의 다이어그램 안에서 성공 시나리오와 예외 시나리오를 모두 명확하게 표현할 수 있게 됩니다.

---

실무적 관점: 시퀀스 다이어그램의 가치와 활용

개발자와 기획자를 잇는 소통의 다리

시퀀스 다이어그램은 특정 기술에 대한 지식이 없는 기획자나 현업 담당자도 시스템의 로직 흐름을 직관적으로 이해할 수 있게 해줍니다. 이는 텍스트로만 작성된 요구사항 문서에서 발견하기 어려운 로직의 허점이나 모호함을 조기에 발견하는 데 결정적인 역할을 합니다. 기획자는 이 다이어그램을 통해 자신의 의도가 설계에 정확히 반영되었는지 검증할 수 있으며, 개발자는 이를 기반으로 어떤 클래스와 메서드를 구현해야 할지 명확한 청사진을 얻을 수 있습니다.

특히 외부 API 연동과 같이 여러 시스템이 복잡하게 얽혀있는 기능을 설계할 때 시퀀스 다이어그램의 가치는 극대화됩니다. 어떤 시스템이 어떤 순서로 호출되어야 하고, 각 시스템 간에 어떤 데이터를 주고받아야 하는지를 명확히 보여줌으로써 통합 과정에서 발생할 수 있는 수많은 시행착오를 줄여줍니다. 결국, 시퀀스 다이어그램은 서로 다른 언어를 사용하는 사람들 사이에서 공통의 이해를 만들어내는 강력한 소통의 다리가 됩니다.

효과적인 작성을 위한 주의점

시퀀스 다이어그램의 효용을 극대화하기 위해서는 몇 가지 주의사항을 기억해야 합니다. 첫째, 하나의 다이어그램에 너무 많은 것을 담으려 하지 말아야 합니다. 모든 예외 케이스와 상세 로직을 하나의 다이어그램에 표현하려고 하면, 오히려 너무 복잡해져서 아무도 이해할 수 없는 그림이 되어버립니다. 주된 성공 시나리오 하나에 집중하고, 중요한 예외 케이스들은 별도의 다이어그램으로 분리하여 작성하는 것이 훨씬 효과적입니다.

둘째, 적절한 추상화 수준을 유지하는 것이 중요합니다. 너무 상세한 수준으로 모든 내부 변수나 자잘한 메서드 호출까지 표현할 필요는 없습니다. 시스템의 주요 객체들 간의 의미 있는 상호작용에 초점을 맞춰야 합니다. 마지막으로, 다이어그램은 살아있는 문서여야 합니다. 개발 과정에서 로직이 변경되면 반드시 시퀀스 다이어그램도 함께 수정하여 최신 상태를 유지해야 합니다. 오래되어 실제 코드와 다른 내용을 담고 있는 다이어그램은 없는 것보다 해로울 수 있습니다.

---

마무리하며: 상세 설계를 위한 명쾌한 시나리오

지금까지 우리는 시간의 흐름 속에서 객체들이 어떻게 협력하는지를 보여주는 시퀀스 다이어그램의 세계를 깊이 있게 탐험했습니다. 핵심 구성요소의 의미부터 복잡한 시나리오를 제어하는 인터랙션 프래그먼트, 그리고 실제 작성 과정까지 살펴보며 시퀀스 다이어그램이 단순한 그림이 아닌, 매우 정교하고 강력한 설계 언어임을 확인했습니다.

시퀀스 다이어그램을 마스터한다는 것은 시스템의 동적인 맥박을 짚을 수 있게 된다는 것을 의미합니다. 이는 정보처리기사 시험 합격을 위한 필수 역량이자, 실무에서 명확한 커뮤니케이션과 견고한 설계를 이끌어내는 핵심 기술입니다. 눈에 보이지 않는 소프트웨어 내부의 동작을 눈에 보이는 명쾌한 시나리오로 풀어내는 힘, 그것이 바로 시퀀스 다이어그램의 진정한 가치이며 여러분이 앞으로 만들어갈 성공적인 시스템의 든든한 기반이 되어줄 것입니다.

유스케이스 다이어그램을 이해하는 여정은 세 명의 핵심 주인공을 만나는 것에서부터 시작합니다. 바로 시스템과 상호작용하는 ‘액터(Actor)’, 액터가 달성하고자 하는 목표인 ‘유스케이스(Use Case)’, 그리고 이 모든 이야기가 펼쳐지는 무대인 ‘시스템(System)’입니다. 이 세 가지 구성요소는 마치 연극의 배우, 대본, 무대와 같이 각자의 명확한 역할을 수행하며, 이들의 관계를 정확히 이해하는 것이야말로 명확한 요구사항 정의의 첫걸음이자 정보처리기사 합격의 초석이 됩니다.

이 글은 유스케이스 다이어그램의 가장 근본적인 세 가지 기둥인 액터, 유스케이스, 시스템에 대해 그 어떤 자료보다 깊고 상세하게 파고들 것입니다. 각각의 개념을 단순히 정의하는 것을 넘어, 실무에서 마주할 수 있는 다양한 유형과 좋은 요소를 식별하는 노하우, 그리고 흔히 저지르는 실수까지 꼼꼼하게 짚어보겠습니다. 이 글을 통해 여러분은 흩어져 있던 개념의 조각들을 하나로 꿰어, 시스템의 요구사항을 꿰뚫어 보는 단단한 관점을 갖게 될 것입니다.

---

액터 (Actor): 시스템에 생명을 불어넣는 존재

액터의 정의: 단순한 ‘사람’을 넘어서

액터는 우리가 만들고자 하는 시스템의 외부에 존재하면서 시스템과 의미 있는 상호작용을 하는 모든 것을 지칭합니다. 많은 사람이 액터를 사람 모양의 아이콘 때문에 ‘사용자’나 ‘사람’으로 한정하여 생각하지만, 이는 액터라는 개념의 일부만을 이해한 것입니다. 액터는 시스템에 어떤 행위를 유발하고 그 결과에 영향을 받는 역할(Role)의 개념이며, 그 주체는 사람일 수도, 다른 시스템일 수도, 심지어 시간일 수도 있습니다.

가장 흔한 유형은 사람 액터(Human Actor)입니다. 쇼핑몰의 ‘고객’, 은행 시스템의 ‘은행원’, 회사 내부 시스템의 ‘관리자’처럼 시스템을 직접 조작하는 사용자의 역할을 의미합니다. 두 번째는 시스템 액터(System Actor)로, 최신 서비스 아키텍처에서 그 중요성이 날로 커지고 있습니다. 우리가 만드는 시스템이 신용카드 결제를 위해 외부 ‘결제 게이트웨이’와 통신하거나, 소셜 로그인을 위해 ‘카카오 인증 서버’와 정보를 주고받을 때, 이 외부 시스템들이 바로 액터가 됩니다. 마지막으로 시간 액터(Time Actor)라는 특별한 유형도 있습니다. ‘매일 자정’이 되면 자동으로 통계 데이터를 생성하는 배치 작업처럼, 특정 시간이 시스템의 기능을 촉발하는 경우 이 ‘시간’이 액터의 역할을 수행하게 됩니다.

주 액터 vs 부 액터: 이야기의 주인공과 조연

모든 액터가 시스템과 동일한 무게감으로 상호작용하는 것은 아닙니다. 액터는 그 역할의 능동성에 따라 이야기의 주인공인 주 액터(Primary Actor)와 조연인 부 액터(Secondary Actor)로 나뉩니다. 이 둘을 구분하는 것은 시스템의 핵심 가치가 누구를 향하는지, 그리고 시스템의 주요 흐름이 어떻게 흘러가는지를 파악하는 데 결정적인 단서를 제공합니다.

주 액터는 시스템을 사용하여 자신의 목표를 달성하려는 능동적인 존재입니다. 즉, 유스케이스를 먼저 시작(initiate)시키는 쪽입니다. 예를 들어, 사용자가 온라인 강의 사이트에서 ‘강의를 수강하다’라는 유스케이스를 실행할 때, 이 ‘사용자’가 바로 주 액터입니다. 시스템은 주 액터의 목표를 달성시켜주기 위해 존재하며, 시스템의 핵심 기능은 대부분 주 액터를 위해 설계됩니다. 반면, 부 액터는 주 액터의 목표 달성 과정을 돕기 위해 시스템에 의해 호출되는 수동적인 존재입니다. 시스템이 ‘강의 수강’ 요청을 처리하기 위해 해당 사용자의 수강 이력을 ‘학사 관리 시스템’에서 조회해야 한다면, 이때 시스템의 요청에 응답하는 ‘학사 관리 시스템’이 부 액터가 됩니다.

좋은 액터를 식별하는 실무 팁

프로젝트 초기 단계에서 정확하게 액터를 식별하는 것은 요구사항의 누락을 막는 중요한 활동입니다. 액터를 효과적으로 찾아내기 위해서는 다음과 같은 질문들을 스스로 또는 고객에게 던져보는 것이 좋습니다. “누가 시스템에 로그인하여 주된 기능을 사용할 것인가?”, “누가 시스템의 유지보수나 관리를 담당하는가?”, “시스템이 동작하는 데 필요한 정보를 제공하거나, 시스템으로부터 정보를 받아보는 대상은 누구인가?”, “우리가 만드는 시스템이 통신해야 하는 외부의 다른 하드웨어나 소프트웨어 시스템은 없는가?”, “특정 시간이 되면 자동으로 실행되어야 하는 기능이 있는가?”

액터를 식별할 때 몇 가지 흔한 실수를 피해야 합니다. 가장 대표적인 실수는 역할을 사람 그 자체와 혼동하는 것입니다. ‘영업팀 김대리’가 액터가 아니라, 김대리가 수행하는 역할인 ‘판매 담당자’가 액터가 되어야 합니다. 또한, 시스템의 일부를 액터로 착각해서는 안 됩니다. 예를 들어, 시스템이 사용하는 ‘데이터베이스’는 시스템의 내부에 속한 구성요소이지, 시스템 외부에서 상호작용하는 액터가 아닙니다. 액터는 항상 시스템 경계선 바깥에 존재한다는 원칙을 기억하는 것이 중요합니다.

---

유스케이스 (Use Case): 액터의 목표이자 시스템의 존재 이유

유스케이스의 본질: 관찰 가능한 가치의 전달

유스케이스는 특정 액터가 시스템을 통해 달성하고자 하는 하나의 완전한 목표를 의미하며, 이는 시스템의 가장 중요한 존재 이유가 됩니다. 좋은 유스케이스의 핵심 조건은 ‘액터에게 관찰 가능한 가치를 제공해야 한다’는 것입니다. 즉, 유스케이스가 성공적으로 완료되었을 때, 액터는 자신의 목표가 달성되었음을 명확하게 인지하고 그로부터 어떤 이득을 얻어야 합니다.

예를 들어 ‘비밀번호를 입력하다’나 ‘아이디 중복을 체크하다’는 그 자체만으로는 액터에게 아무런 가치를 주지 못합니다. 이것들은 ‘회원가입을 하다’라는 더 큰 목표를 달성하기 위한 과정의 일부일 뿐입니다. 반면, ‘회원가입을 하다’는 성공적으로 완료되면 사용자가 사이트의 회원이 되어 다양한 서비스를 이용할 수 있다는 명확한 가치를 제공하므로 훌륭한 유스케이스가 될 수 있습니다. 이처럼 유스케이스는 시스템의 기능 목록이 아니라, 액터의 관점에서 의미 있는 작업의 완결된 단위를 나타내야 합니다.

유스케이스 명명법과 상세화 수준

유스케이스를 명확하게 정의하기 위한 가장 기본적인 규칙은 명명법을 지키는 것입니다. 유스케이스의 이름은 반드시 ‘동사 + 명사’ 형태의 서술형으로, 액터의 행위를 명확히 표현해야 합니다. ‘주문’, ‘검색’과 같은 명사형이 아니라 ‘상품을 주문하다’, ‘도서를 검색하다’와 같이 구체적인 목표를 서술하는 것이 올바른 표현입니다. 이는 유스케이스가 정적인 기능이 아닌, 액터의 동적인 목표 달성 과정임을 상기시켜 줍니다.

또한, 유스케이스는 필요에 따라 여러 상세화 수준(Level of Detail)으로 표현될 수 있습니다. 가장 상위 레벨은 ‘요약 수준(Summary Level)’으로, ‘고객을 관리하다’처럼 여러 하위 목표를 포함하는 거시적인 비즈니스 프로세스를 나타냅니다. 이는 주로 경영진 보고나 프로젝트의 큰 그림을 설명할 때 유용합니다. 가장 일반적으로 사용되는 레벨은 ‘사용자 목표 수준(User-goal Level)’으로, ‘신규 고객을 등록하다’처럼 액터가 시스템에 앉아서 한 번에 끝낼 수 있는 구체적인 단일 목표를 의미합니다. 대부분의 유스케이스 다이어그램은 이 레벨을 기준으로 작성됩니다. 이보다 더 상세한 ‘하위 기능 수준(Sub-function Level)’은 ‘우편번호를 검색하다’와 같이 상위 유스케이스를 구성하는 작은 단계를 의미하는데, 이러한 기능들은 다이어그램을 복잡하게 만들 수 있어 별도의 유스케이스로 그리기보다는 상위 유스케이스의 명세서에 기술하는 것이 일반적입니다.

유스케이스를 효과적으로 도출하는 방법

효과적인 유스케이스 도출은 체계적인 접근법을 통해 이루어집니다. 가장 좋은 출발점은 앞에서 식별한 액터 목록을 활용하는 것입니다. 각각의 액터에게 빙의하여, “이 시스템을 통해 궁극적으로 이루고 싶은 목표는 무엇인가?”, “업무를 처리하기 위해 시스템으로 해야 하는 주요 과업들은 무엇인가?”, “시스템에서 어떤 정보를 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)해야 하는가?”와 같은 질문을 던지는 것이 핵심입니다.

‘액터-목표 목록(Actor-Goal List)’을 작성하는 것은 매우 실용적인 기법입니다. 표를 하나 만들고 왼쪽 열에는 액터의 이름을, 오른쪽 열에는 해당 액터가 시스템을 통해 달성하고자 하는 목표를 모두 나열하는 것입니다. 예를 들어 ‘학생’ 액터의 목표 목록에는 ‘수강 신청하다’, ‘강의 계획서를 조회하다’, ‘성적을 확인하다’ 등이 포함될 수 있습니다. 이렇게 작성된 목표 목록이 바로 유스케이스의 후보가 되며, 이 목록을 정제하고 다듬어 최종적인 유스케이스 집합을 완성하게 됩니다. 이 과정은 요구사항을 누락 없이 꼼꼼하게 챙기는 데 큰 도움이 됩니다.

---

시스템 (System): 기능이 펼쳐지는 무대

시스템 경계(System Boundary)의 역할과 중요성

시스템 경계는 유스케이스 다이어그램에서 사각형으로 표현되며, 우리가 개발하고자 하는 시스템의 범위, 즉 ‘안’과 ‘밖’을 구분하는 명확한 선입니다. 이 사각형 안쪽에 그려지는 유스케이스들은 이번 프로젝트를 통해 개발팀이 책임지고 만들어야 할 기능들을 의미합니다. 반면, 사각형 바깥에 존재하는 액터들은 시스템의 사용 주체이거나 연동 대상이지만, 우리 팀의 개발 범위는 아님을 명시적으로 보여줍니다.

시스템 경계의 가장 중요한 역할은 바로 ‘프로젝트 범위 관리(Scope Management)’입니다. 프로젝트 초기에 모든 이해관계자가 이 경계선을 통해 “우리가 만들 것”과 “만들지 않을 것”에 대해 명확하게 합의할 수 있습니다. 이는 “이 기능도 추가해 주세요”와 같은 요구사항이 무분별하게 늘어나는 것을 방지하는 강력한 방어벽이 됩니다. 마치 집을 지을 때 대지의 경계를 명확히 측량해야 하는 것처럼, 시스템 개발 역시 이 경계선을 명확히 긋는 것에서부터 안정적으로 시작될 수 있습니다.

시스템 경계 설정 시 고려사항

시스템의 경계는 절대적인 것이 아니라 프로젝트의 맥락과 목표에 따라 유연하게 설정될 수 있습니다. 예를 들어 ‘결제 기능’을 생각해 봅시다. 만약 프로젝트의 목표가 우리 회사만의 독자적인 결제 솔루션을 처음부터 끝까지 만드는 것이라면, ‘신용카드로 결제하다’, ‘계좌이체로 결제하다’ 등의 상세한 유스케이스들이 모두 시스템 경계 안쪽에 위치할 것입니다.

하지만 대부분의 서비스처럼 외부 PG(결제 대행)사의 모듈을 연동하여 사용하는 경우, 상황은 달라집니다. 이때 우리 시스템의 역할은 고객의 결제 정보를 받아 외부 PG사에 전달하고 그 결과를 받는 것입니다. 따라서 우리 시스템 경계 안에는 ‘결제를 요청하다’라는 유스케이스가 존재하고, 실제 결제를 처리하는 ‘결제 게이트웨이’는 시스템 경계 바깥에 존재하는 외부 액터가 됩니다. 이처럼 경계를 어떻게 설정하느냐에 따라 프로젝트의 개발 범위와 책임 소재가 완전히 달라지므로, 이는 기술적인 결정인 동시에 매우 중요한 비즈니스적인 결정이기도 합니다.

‘블랙박스’ 관점의 유지

시스템 경계는 자연스럽게 시스템을 ‘블랙박스(Black Box)’로 바라보는 관점을 유지하도록 돕습니다. 블랙박스 관점이란, 시스템의 내부 구조나 동작 원리를 알지 못하더라도, 무엇을 넣으면(Input) 무엇이 나오는지만(Output) 알면 시스템을 사용할 수 있다는 개념입니다. 액터는 시스템 경계 바깥에 존재하므로, 경계 안에서 유스케이스들이 어떤 복잡한 기술과 로직으로 구현되는지 알 필요가 없습니다. 그저 약속된 기능을 올바르게 수행하고 자신이 원하는 목표(가치)를 달성시켜 주는지만이 중요할 뿐입니다.

이러한 추상화는 매우 중요한 설계 원칙입니다. 시스템의 내부 구현 방식(How)을 외부의 요구사항(What)으로부터 분리(decoupling)시키기 때문입니다. 덕분에 개발팀은 나중에 내부 기술 스택을 바꾸거나 로직을 개선하더라도, 시스템 경계 바깥의 액터와의 약속, 즉 유스케이스의 기능만 그대로 유지한다면 외부에 미치는 영향 없이 자유롭게 시스템을 발전시켜 나갈 수 있습니다. 시스템 경계는 이처럼 시스템의 유연성과 유지보수성을 높이는 데에도 기여하는 보이지 않는 힘을 가지고 있습니다.

---

마무리하며: 명확한 설계를 위한 세 가지 초석

지금까지 우리는 유스케이스 다이어그램을 구성하는 가장 본질적인 세 요소인 액터, 유스케이스, 그리고 시스템에 대해 깊이 있게 탐험했습니다. 시스템과 상호작용하는 ‘누가(Who)’를 정의하는 액터, 그들이 이루려는 ‘무엇을(What)’을 정의하는 유스케이스, 그리고 이 모든 일이 일어나는 ‘어디서(Where)’를 정의하는 시스템 경계. 이 세 가지 개념은 각각 독립적으로 존재하지 않고, 서로를 정의하며 유기적으로 연결되어 하나의 완성된 요구사항 그림을 만들어냅니다.

정보처리기사 시험을 준비하며 이들의 관계와 정의를 암기하는 것도 중요하지만, 더 나아가 각 요소가 왜 필요하며 실무에서 어떻게 작용하는지를 이해하는 것이 핵심입니다. 액터, 유스케이스, 시스템이라는 세 가지 초석을 단단히 다질 때, 여러분은 비로소 흔들림 없는 시스템 설계의 첫 단추를 성공적으로 꿰었다고 말할 수 있을 것입니다. 명확하게 정의된 이 세 가지 요소는 복잡한 요구사항의 안개를 걷어내고, 프로젝트의 모든 구성원을 성공이라는 동일한 목적지로 이끄는 가장 확실한 나침반이 되어줄 것입니다.

소프트웨어 개발의 광활한 여정에서 길을 잃지 않게 해주는 첫 번째 지도, 그것이 바로 유스케이스 다이어그램입니다. 정보처리기사 시험을 준비하는 수험생이라면 반드시 넘어야 할 산이자, 현업의 기획자나 개발자에게는 사용자와 시스템 사이의 오해를 막아주는 가장 확실한 소통의 도구입니다. 유스케이스 다이어그램은 복잡한 시스템의 기능을 사용자의 눈높이에서 직관적으로 표현함으로써, ‘우리가 무엇을 만들어야 하는가?’라는 근본적인 질문에 가장 명확한 답을 제시합니다.

이 글에서는 정보처리기사 자격증 합격은 물론, 실무 역량까지 한 단계 끌어올릴 수 있도록 유스케이스 다이어그램의 모든 것을 상세히 다룰 것입니다. 핵심적인 구성요소와 그들 사이의 관계를 명확히 정의하고, 간단한 예시부터 최신 기술 트렌드가 반영된 복잡한 사례까지 단계별로 분석해 보겠습니다. 또한, 다이어그램만으로는 부족한 2%를 채워주는 유스케이스 명세서의 작성법을 알아보고, 마지막으로 이 강력한 도구를 현업에서 효과적으로 사용하기 위한 중요성과 주의점까지 꼼꼼하게 정리해 드리겠습니다.

---

유스케이스 다이어그램이란 무엇인가?

사용자 관점의 시스템 기능 명세서

유스케이스 다이어그램은 시스템이 사용자에게 어떤 기능(가치)을 제공하는지를 그림으로 표현한 설계도입니다. 여기서 가장 중요한 핵심은 ‘사용자 관점’이라는 것입니다. 개발자의 시선에서 시스템의 내부 구조나 데이터 처리 방식을 설명하는 것이 아니라, 오로지 시스템을 사용하는 ‘액터(Actor)’가 특정 목표를 달성하기 위해 시스템과 어떤 상호작용을 하는지에 집중합니다. 즉, 시스템이 ‘어떻게(How)’ 동작하는지가 아닌 ‘무엇을(What)’ 하는지를 정의하는 데 목적이 있습니다.

예를 들어, 우리가 온라인 쇼핑몰에서 ‘상품을 주문한다’는 기능을 만든다고 상상해 봅시다. 개발자에게는 데이터베이스에 주문 정보를 저장하고, 재고를 차감하며, 결제 모듈을 호출하는 복잡한 과정이겠지만, 사용자에게는 그저 ‘주문하기’라는 하나의 목표 달성 과정일 뿐입니다. 유스케이스 다이어그램은 바로 이 사용자 관점의 목표, 즉 ‘상품을 주문하다’라는 유스케이스를 시각적으로 명확하게 보여줌으로써, 프로젝트에 관련된 모든 이해관계자가 동일한 목표를 공유하게 만듭니다.

소프트웨어 개발의 첫 단추

모든 건축이 설계도에서 시작되듯, 모든 소프트웨어 개발은 요구사항 분석에서 시작됩니다. 유스케이스 다이어그램은 바로 이 요구사항 분석 단계에서 가장 먼저, 그리고 가장 중요하게 활용되는 산출물 중 하나입니다. 고객이나 현업 담당자 등 비전문가도 쉽게 이해할 수 있는 직관적인 형태를 하고 있어, 개발자와 비개발자 사이의 의사소통 장벽을 허무는 데 결정적인 역할을 합니다.

이 다이어그램을 통해 프로젝트 초기에 시스템의 전체적인 범위와 경계를 명확히 할 수 있습니다. 어떤 기능이 시스템에 포함되고, 어떤 기능이 포함되지 않는지를 한눈에 파악할 수 있어 불필요한 기능 개발을 막고 프로젝트의 방향이 잘못된 길로 빠지는 것을 방지합니다. 이는 통합 모델링 언어인 UML(Unified Modeling Language)의 여러 다이어그램 중에서도 가장 먼저 작성되며, 이후에 만들어질 다른 상세 다이어그램들의 기준점이 되는, 그야말로 소프트웨어 개발의 첫 단추라고 할 수 있습니다.

---

유스케이스 다이어그램의 핵심 구성요소

액터 (Actor): 시스템과 상호작용하는 모든 것

액터는 우리가 만들고자 하는 시스템의 외부에 존재하면서 시스템과 직접적으로 상호작용하는 사람, 다른 시스템, 또는 하드웨어 장치 등을 의미합니다. 흔히 사람 모양의 아이콘(스틱맨)으로 표현되어 ‘사용자’와 동일한 의미로 오해하기 쉽지만, 그 범위는 훨씬 넓습니다. 예를 들어, 은행 ATM 시스템에서 돈을 인출하는 ‘고객’은 사람이므로 액터가 될 수 있고, 고객의 카드 정보를 인증해주는 ‘카드사 인증 시스템’ 역시 우리 ATM 시스템과 정보를 주고받으므로 액터가 될 수 있습니다.

액터는 크게 주 액터(Primary Actor)와 부 액터(Secondary Actor)로 나뉩니다. 주 액터는 특정 유스케이스를 먼저 시작하여 시스템의 서비스를 요청하는 능동적인 존재입니다. ‘고객’이 ATM에 카드를 넣고 ‘현금 인출’을 요청하는 경우가 이에 해당합니다. 반면, 부 액터는 주 액터의 요청을 처리하기 위해 시스템이 도움을 요청하는 수동적인 존재입니다. ‘현금 인출’ 과정에서 시스템이 고객의 계좌 잔액을 확인하기 위해 ‘은행 중앙 서버’에 정보를 요청한다면, 이때 ‘은행 중앙 서버’가 부 액터가 됩니다. 이 둘을 구분하는 것은 시스템의 주된 흐름을 파악하는 데 매우 중요합니다.

유스케이스 (Use Case): 사용자가 원하는 목표

유스케이스는 액터가 시스템을 통해 달성하고자 하는 구체적인 목표 하나하나를 의미합니다. 타원형으로 표현되며, 이름은 반드시 ‘동사 + 명사’ 형태의 서술형으로 작성해야 합니다. 예를 들어, ‘로그인’, ‘회원가입’이 아니라 ‘로그인하다’, ‘회원가입하다’, ‘상품을 검색하다’와 같이 액터의 행위를 명확하게 나타내는 것이 규칙입니다. 이는 유스케이스가 시스템의 기능 목록이 아니라, 액터의 입장에서 의미 있는 하나의 완전한 작업 단위임을 강조하기 위함입니다.

좋은 유스케이스는 그 자체로 액터에게 가치를 제공해야 합니다. 예를 들어, ‘비밀번호를 입력하다’는 그 자체만으로는 아무런 가치가 없습니다. ‘로그인하다’라는 더 큰 목표를 이루기 위한 과정의 일부일 뿐입니다. 따라서 이것은 독립적인 유스케이스가 되기 어렵습니다. 반면, ‘로그인하다’는 성공 시 사용자에게 개인화된 서비스를 제공한다는 명확한 가치를 주므로 훌륭한 유스케이스가 될 수 있습니다. 이처럼 유스케이스의 단위를 적절하게 설정하는 것이 요구사항을 명확히 하는 핵심입니다.

관계 (Relationships): 구성요소들을 연결하는 선

액터와 유스케이스, 또는 유스케이스와 유스케이스 사이의 상호작용은 여러 종류의 관계선으로 표현됩니다. 이 관계를 정확히 이해하고 사용하는 것이 유스케이스 다이어그램 작성의 핵심이며, 정보처리기사 시험에서도 빈번하게 출제되는 포인트입니다. 관계는 크게 연관, 포함, 확장, 일반화 네 가지로 나뉩니다.

연관 관계(Association)는 액터와 유스케이스 사이에 실선으로 표현되며, 둘 사이에 상호작용이 있음을 나타내는 가장 기본적인 관계입니다. 포함 관계(Include)는 하나의 유스케이스가 다른 유스케이스의 기능을 반드시 실행해야 할 때 사용합니다. 예를 들어, ‘게시글을 작성하다’와 ‘댓글을 달다’ 유스케이스는 모두 ‘로그인하다’라는 기능이 선행되어야 합니다. 이때, 점선 화살표와 함께 <<include>>라고 표기하여 두 유스케이스가 ‘로그인하다’를 포함함을 나타냅니다.

확장 관계(Extend)는 특정 조건에서만 선택적으로 실행되는 기능을 표현할 때 사용합니다. 예를 들어, ‘상품을 주문하다’라는 기본 흐름에서, 사용자가 쿠폰을 가지고 있을 경우에만 ‘쿠폰을 적용하다’라는 기능이 추가될 수 있습니다. 이때, <<extend>>라고 표기된 점선 화살표를 사용하여 확장 관계를 나타냅니다. 마지막으로 일반화 관계(Generalization)는 사람의 ‘부모-자식’ 관계처럼 더 일반적인 개념과 더 구체적인 개념 사이의 관계를 나타냅니다. 속이 빈 화살표로 표현하며, 예를 들어 ‘일반 회원’과 ‘기업 회원’이라는 구체적인 액터들은 모두 ‘회원’이라는 일반적인 액터의 한 종류라고 표현할 수 있습니다.

시스템 범위 (System Boundary): 우리가 만들 시스템의 영역

시스템 범위는 다이어그램에서 사각형의 박스로 표현되며, 개발하고자 하는 시스템의 경계를 명확하게 정의하는 역할을 합니다. 이 사각형 안쪽에 위치한 유스케이스들은 이번 프로젝트에서 개발해야 할 기능임을 의미하고, 사각형 바깥에 존재하는 액터들은 시스템의 일부가 아님을 명시적으로 보여줍니다.

이 경계선은 프로젝트의 범위를 시각적으로 제한함으로써 매우 중요한 역할을 합니다. 예를 들어, ‘상품 주문 시스템’을 개발할 때 ‘주문하다’, ‘결제하다’ 등의 유스케이스는 시스템 범위 안에 위치하게 됩니다. 하지만 주문 정보를 받아 실제 배송을 처리하는 ‘배송 시스템’은 우리 시스템이 직접 개발하는 것이 아닌, 외부 연동의 대상이므로 액터로서 시스템 범위 바깥에 그려져야 합니다. 이처럼 시스템 경계는 ‘여기까지가 우리가 할 일’이라는 것을 모든 팀원이 명확하게 인지하도록 도와주어, 프로젝트가 산으로 가는 것을 막아주는 든든한 울타리가 됩니다.

---

유스케이스 다이어그램 작성법 및 예시

1단계: 액터 식별하기

유스케이스 다이어그램 작성의 첫걸음은 시스템과 상호작용할 액터를 모두 찾아내는 것입니다. 액터를 식별하기 위해 다음과 같은 질문을 스스로에게 던져볼 수 있습니다. “누가 이 시스템을 사용하는가?”, “누가 시스템의 주된 기능을 사용하는가?(주 액터)”, “시스템이 동작하는 데 필요한 정보를 누가 제공하거나 받게 되는가?(부 액터)”, “이 시스템과 연동되는 외부 시스템이나 하드웨어는 무엇인가?”.

예를 들어, 간단한 ‘도서관 좌석 예약 시스템’을 만든다고 가정해 봅시다. 가장 먼저 떠오르는 액터는 ‘학생’입니다. 학생은 좌석을 예약하고, 사용 시간을 연장하고, 예약을 취소하는 주된 사용자입니다. 또 다른 액터는 ‘관리자’가 될 수 있습니다. 관리자는 시스템 설정을 변경하거나, 특정 학생의 이용을 제한하는 등의 관리 기능을 수행합니다. 마지막으로, 예약 시간이 다 되었을 때 학생에게 알림을 보내주는 ‘SMS 발송 시스템’이 있다면, 이것 역시 우리 시스템과 정보를 주고받는 외부 시스템 액터가 될 수 있습니다.

2단계: 유스케이스 식별 및 정의

액터를 모두 식별했다면, 다음은 각 액터가 시스템을 통해 어떤 목표를 이루고 싶어 하는지, 즉 유스케이스를 찾아낼 차례입니다. 각 액터의 입장에서 “이 시스템을 통해 무엇을 하고 싶은가?”라고 질문하는 것이 가장 효과적인 방법입니다. 앞선 ‘도서관 좌석 예약 시스템’ 예시를 계속 이어가 보겠습니다.

‘학생’ 액터의 입장에서 생각해 봅시다. 학생은 도서관에 와서 빈자리를 ‘예약하고’ 싶을 것입니다. 공부를 더 하고 싶으면 ‘사용 시간을 연장하고’ 싶을 것이고, 갑자기 일이 생기면 ‘예약을 취소하고’ 싶을 것입니다. 또한, 현재 어떤 좌석이 비어있는지 ‘좌석 현황을 조회하고’ 싶을 수도 있습니다. 이 각각이 모두 ‘학생’ 액터와 연관된 유스케이스가 됩니다. ‘관리자’ 액터의 입장에서는 ‘학생 이용을 제재하다’, ‘공지사항을 등록하다’와 같은 유스케이스를 식별할 수 있습니다.

3단계: 관계 설정 및 다이어그램 완성

액터와 유스케이스라는 재료가 준비되었으니, 이제 관계라는 양념을 쳐서 다이어그램을 완성할 차례입니다. 먼저 각 액터와 그들이 수행하는 유스케이스를 기본적인 연관 관계(실선)로 연결합니다. ‘학생’은 ‘좌석 예약하다’, ‘예약 취소하다’ 등과 연결되고, ‘관리자’는 ‘공지사항 등록하다’ 등과 연결됩니다.

다음으로 유스케이스들 사이의 관계를 분석하여 포함(include), 확장(extend), 일반화(generalization) 관계를 적용합니다. 예를 들어, ‘좌석 예약하다’, ‘사용 시간 연장하다’ 등 학생이 사용하는 모든 기능은 반드시 ‘학생 인증을 하다'(학생증 태깅 등)라는 절차를 거쳐야 한다고 가정해 봅시다. 이 경우, 여러 유스케이스에서 공통으로 사용되는 ‘학생 인증을 하다’를 별도의 유스케이스로 만들고, 다른 유스케이스들이 이 유스케이스를 포함(<<include>>)하도록 관계를 설정할 수 있습니다. 또한, ‘좌석 예약하다’라는 유스케이스를 실행할 때, 사용자가 선호하는 창가 자리를 먼저 보여주는 ‘선호 좌석 추천’ 기능이 선택적으로 동작한다면, 이는 ‘좌석 예약하다’를 확장(<<extend>>)하는 유스케이스가 될 수 있습니다. 이런 과정을 거쳐 모든 구성요소와 관계를 시스템 범위(사각형) 안에 배치하면 하나의 유스케이스 다이어그램이 완성됩니다.

---

최신 기술 트렌드를 반영한 실무 사례

사례 연구: AI 챗봇 기반 맛집 추천 서비스

유스케이스 다이어그램은 전통적인 소프트웨어뿐만 아니라, 인공지능, 빅데이터 등 최신 기술이 접목된 복잡한 서비스를 설계하는 데에도 매우 유용하게 사용됩니다. 예를 들어, 사용자의 취향과 현재 위치를 기반으로 맛집을 추천해주는 ‘AI 챗봇 서비스’의 유스케이스 다이어그램을 구상해 봅시다. 이 서비스는 단순히 기능이 많은 것을 넘어, 여러 시스템이 유기적으로 연결되어 동작한다는 특징이 있습니다.

이 서비스의 액터는 누구일까요? 먼저 챗봇과 대화하며 맛집을 추천받는 ‘일반 사용자’가 있습니다. 자신의 가게 정보를 시스템에 등록하고 홍보하는 ‘식당 주인’도 중요한 액터입니다. 여기서 더 나아가, 사용자의 대화 내용을 분석하고 최적의 맛집을 찾아내는 ‘AI 추천 엔진’과, 사용자가 챗봇을 통해 바로 예약과 결제를 진행할 수 있도록 돕는 ‘결제 게이트웨이’는 시스템 외부에 존재하는 중요한 시스템 액터가 됩니다. 이처럼 복잡한 서비스일수록 사람 외의 시스템 액터를 정확히 식별하는 것이 중요합니다.

서비스의 기능과 관계 분석

이제 각 액터와 연관된 유스케이스를 정의해 봅시다. ‘일반 사용자’는 ‘챗봇으로 맛집 문의하다’, ‘위치 기반으로 검색하다’, ‘음식 종류로 필터링하다’, ‘맛집을 예약하다’, ‘리뷰를 작성하다’ 등의 목표를 가집니다. ‘식당 주인’은 ‘가게 정보를 등록/수정하다’, ‘프로모션을 관리하다’, ‘예약 현황을 확인하다’와 같은 유스케이스를 수행합니다.

이제 이들 사이의 관계를 설정해 봅시다. ‘맛집을 예약하다’ 유스케이스는 반드시 사용자가 누구인지 확인하는 ‘사용자 인증’ 과정과 실제 돈이 오가는 ‘결제 처리’ 과정을 포함해야 합니다. 따라서 이들은 포함(<<include>>) 관계로 묶일 수 있습니다. ‘리뷰를 작성하다’라는 유스케이스는 기본적으로 텍스트만 작성하지만, 사용자가 원할 경우 ‘사진을 첨부하다’라는 기능이 선택적으로 동작할 수 있습니다. 이는 확장(<<extend>>) 관계로 표현하는 것이 적절합니다. 또한 ‘챗봇으로 맛집 문의하다’ 유스케이스는 ‘AI 추천 엔진’ 액터와 직접적인 연관 관계를 맺으며, ‘맛집을 예약하다’는 ‘결제 게이트웨이’ 액터와 상호작용하게 됩니다. 이처럼 다이어그램을 통해 복잡한 서비스의 기능과 외부 시스템과의 연동 지점을 한눈에 파악할 수 있습니다.

---

유스케이스 명세서: 다이어그램의 숨겨진 힘

다이어그램을 보완하는 상세 시나리오

유스케이스 다이어그램은 시스템의 전체적인 기능과 흐름을 조망하는 데 매우 효과적이지만, 각 기능의 구체적인 동작 방식까지 알려주지는 않습니다. ‘상품을 주문하다’라는 유스케이스가 있다는 것은 알지만, 주문 과정에서 어떤 정보를 입력해야 하고, 어떤 순서로 진행되며, 만약 재고가 부족할 때는 어떻게 처리되는지에 대한 상세한 정보는 다이어그램에 나타나지 않습니다. 바로 이 부분을 보충해주는 문서가 ‘유스케이스 명세서(Use Case Specification)’입니다.

유스케이스 명세서는 다이어그램의 각 유스케이스(타원) 하나하나에 대해 상세한 설명을 붙이는 문서입니다. 여기에는 유스케이스의 이름, 목적, 관련된 액터, 실행되기 위한 전제 조건(사전 조건), 실행된 후의 시스템 상태(사후 조건) 등이 포함됩니다. 그리고 가장 중요한 ‘시나리오’가 기술되는데, 기능이 문제없이 정상적으로 처리되는 과정인 ‘기본 흐름(정상 시나리오)’과, 오류가 발생하거나 예외적인 상황에 대처하는 ‘대안 흐름(예외 시나리오)’으로 나누어 구체적으로 작성됩니다. 이 명세서가 있어야만 개발자는 사용자의 요구사항을 오해 없이 정확하게 코드로 구현할 수 있습니다.

명세서 작성 예시: ‘로그인하다’ 유스케이스

유스케이스 명세서가 어떻게 작성되는지 ‘로그인하다’ 유스케이스를 예로 들어 살펴보겠습니다. 이 명세서는 개발자와 테스터, 그리고 기획자 모두에게 중요한 기준 문서가 됩니다.

유스케이스 ID: UC-001

유스케이스명: 로그인하다

개요: 사용자가 시스템에 자신의 신원을 증명하고, 개인화된 서비스를 이용할 수 있는 권한을 얻는다.

액터: 회원 (주 액터)

사전 조건: 사용자가 회원가입을 통해 시스템에 아이디와 비밀번호를 등록한 상태여야 한다.

사후 조건:

• (성공 시) 시스템은 사용자를 인증하고, 해당 사용자의 정보로 세션을 생성한다. 사용자는 개인화된 메인 페이지로 이동한다.
• (실패 시) 시스템의 상태는 로그인 시도 이전과 동일하게 유지된다.기본 흐름 (정상 시나리오):

1. 사용자가 아이디와 비밀번호 입력 필드를 확인한다.
2. 사용자는 자신의 아이디와 비밀번호를 입력하고 ‘로그인’ 버튼을 클릭한다.
3. 시스템은 입력된 아이디와 비밀번호가 데이터베이스에 저장된 정보와 일치하는지 검증한다.
4. 검증에 성공하면, 시스템은 사용자의 로그인 상태를 기록하고 개인화된 메인 페이지를 표시한다.대안 흐름 (예외 시나리오):

• 3a. 입력된 아이디가 존재하지 않거나 비밀번호가 일치하지 않을 경우:
  1. 시스템은 “아이디 또는 비밀번호가 올바르지 않습니다.”라는 오류 메시지를 표시한다.
  2. 사용자는 다시 아이디와 비밀번호를 입력할 수 있다.
• 3b. 5회 연속으로 로그인에 실패했을 경우:
  1. 시스템은 해당 아이디의 계정을 30분간 잠금 처리한다.
  2. 시스템은 “로그인 시도 횟수 초과로 계정이 잠겼습니다.”라는 메시지를 표시한다.

---

실무적 관점: 유스케이스 다이어그램의 중요성과 주의점

왜 유스케이스 다이어그램이 중요한가?

유스케이스 다이어그램은 단순히 정보처리기사 시험에 나오는 이론이 아니라, 성공적인 프로젝트를 위해 실무에서 반드시 필요한 핵심 도구입니다. 첫째, 최고의 의사소통 도구입니다. 고객, 기획자, 디자이너, 개발자, 테스터 등 프로젝트에 참여하는 모든 사람이 시스템의 기능과 범위를 동일한 그림을 보며 이해하게 만들어 오해의 소지를 줄여줍니다. 둘째, 요구사항을 명확하게 정의하고 관리하는 기준이 됩니다. 프로젝트 초기에 ‘무엇을 만들지’를 명확히 합의함으로써, 프로젝트가 진행되는 동안 기능이 무분별하게 추가되거나 변경되는 ‘스코프 크립(Scope Creep)’ 현상을 방지할 수 있습니다.

셋째, 개발과 테스트의 기반을 제공합니다. 잘 작성된 유스케이스와 명세서는 개발자가 구현해야 할 기능의 명확한 지침이 되며, 테스터에게는 어떤 시나리오를 테스트해야 하는지에 대한 훌륭한 테스트 케이스 목록이 됩니다. ‘로그인하다’ 유스케이스의 기본 흐름과 대안 흐름은 그대로 정상 케이스 테스트와 예외 케이스 테스트의 근거가 될 수 있습니다. 결국, 유스케이스 다이어그램은 프로젝트의 시작부터 끝까지 모든 단계에 긍정적인 영향을 미치는 핵심적인 산출물인 셈입니다.

작성 시 반드시 기억해야 할 주의사항

유스케이스 다이어그램은 강력한 도구이지만, 잘못 사용하면 오히려 혼란을 가중시킬 수 있습니다. 첫째, 너무 상세하게 그리려는 욕심을 버려야 합니다. 유스케이스 다이어그램은 숲을 보는 지도이지, 나무 하나하나를 묘사하는 그림이 아닙니다. ‘데이터베이스에 저장하다’, ‘화면에 색상을 표시하다’와 같은 내부 구현 로직은 유스케이스가 아닙니다. 항상 사용자 입장에서 의미 있는 목표 단위로 기능을 묶어야 합니다.

둘째, 사용자 관점을 잃지 말아야 합니다. 다이어그램을 그리다 보면 자기도 모르게 시스템 내부의 동작 방식에 집중하게 될 수 있습니다. 항상 “이 기능이 액터에게 어떤 가치를 주는가?”를 기준으로 유스케이스를 도출해야 합니다. 셋째, 관계를 남용하지 말아야 합니다. 특히 포함(<<include>>)과 확장(<<extend>>) 관계는 꼭 필요한 경우에만 최소한으로 사용해야 합니다. 이 관계들이 너무 복잡하게 얽히면 다이어그램의 가독성이 급격히 떨어져, 소통을 돕는다는 본래의 목적을 잃게 됩니다. 단순하고 명확한 것이 최고의 다이어그램임을 항상 기억해야 합니다.

---

마무리하며: 성공적인 시스템 설계를 위한 첫걸음

지금까지 우리는 유스케이스 다이어그램의 기본 개념부터 구성요소, 작성법, 그리고 실무 사례와 주의점까지 모든 것을 깊이 있게 살펴보았습니다. 유스케이스 다이어그램은 단순히 네모와 동그라미, 선으로 이루어진 그림이 아닙니다. 그것은 사용자의 요구를 시스템의 언어로 번역하는 첫 번째 단계이자, 프로젝트의 성공과 실패를 가를 수 있는 가장 중요한 설계 과정입니다.

정보처리기사 시험을 준비하는 여러분에게 유스케이스 다이어그램은 합격을 위한 필수 관문일 것입니다. 하지만 여기서 한 걸음 더 나아가, 이 도구가 가진 본질적인 가치를 이해하고 활용할 수 있다면 여러분은 단순한 자격증 소지자를 넘어, 사용자를 이해하고 성공적인 제품을 만드는 유능한 IT 전문가로 성장할 수 있을 것입니다. 복잡한 요구사항 속에서 길을 잃지 않고, 모든 팀원과 같은 목표를 향해 나아가는 첫걸음, 그 시작에 유스케이스 다이어그램이 함께할 것입니다.