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 인터페이스를 실체화했다고 말합니다. 이는 “나는 날 수 있다는 약속을 지켰습니다”라고 선언하는 것과 같으며, 다중 상속이 불가능한 언어에서 다중 상속의 효과를 내는 중요한 메커니즘이기도 합니다.
마무리하며: 관계를 통해 시스템의 구조를 그리다
지금까지 우리는 클래스 다이어그램의 뼈대를 이루는 여섯 가지 핵심 관계들을 하나씩 자세히 살펴보았습니다. 객체 간의 일반적인 연결을 나타내는 ‘연관’, 전체와 부분의 관계를 표현하는 ‘집합’과 ‘포함’, 상속 계층을 그리는 ‘일반화’, 일시적인 사용을 의미하는 ‘의존’, 그리고 약속의 구현을 나타내는 ‘실체화’까지. 이 여섯 가지 관계는 각각 뚜렷한 의미와 뉘앙스를 가지고 있으며, 어떤 관계를 선택하여 사용하느냐에 따라 설계의 의도가 완전히 달라질 수 있습니다.
정보처리기사 시험을 준비하는 여러분에게 이 관계들을 구분하는 능력은 필수적입니다. 하지만 여기서 더 나아가, 각 관계가 실제 코드에서 어떻게 표현되고, 시스템의 유연성, 재사용성, 유지보수성에 어떤 영향을 미치는지를 이해하는 것이야말로 진정한 실력의 척도가 될 것입니다. 이 여섯 가지 관계라는 풍부한 표현 도구를 손에 쥔 여러분은 이제 복잡하게 얽힌 시스템의 구조를 명쾌하게 풀어내고, 견고하며 유연한 소프트웨어를 설계하는 유능한 아키텍트로 성장해 나갈 수 있을 것입니다.