자바 17 Sealed Class 완벽 가이드: 예측 가능하고 견고한 코드를 위한 제한된 상속

안녕하세요, 여러분! 끊임없이 발전하는 자바의 세계에서 견고하고 유지보수하기 쉬운 소프트웨어를 만드는 것은 모든 개발자의 염원입니다. 특히 객체 지향 설계의 핵심인 상속(Inheritance)은 강력한 도구이지만, 잘못 사용하면 예측 불가능한 복잡성을 초래하고 코드의 안정성을 해칠 수 있습니다. 무분별한 상속은 버그를 유발하고, 나아가 시스템 전체를 취약하게 만들기도 합니다.

이러한 문제의식 속에서, 자바 17에서 표준화된 ‘Sealed Class’는 상속의 복잡성을 관리하고, 개발자가 의도한 대로 클래스 계층 구조를 명확하게 제한할 수 있는 혁신적인 방법을 제시합니다. 마치 특정 공간에 출입 가능한 사람을 미리 정해두는 것처럼, 특정 클래스를 상속받을 수 있는 자식 클래스를 명시적으로 선언하여 코드의 안정성과 예측 가능성을 극대화하는 것이죠.

이 가이드에서는 자바를 이제 막 배우기 시작한 분들부터, 보다 견고하고 유지보수하기 쉬운 객체 지향 설계를 고민하는 숙련된 개발자분들까지, 모두가 Sealed Class를 완벽하게 이해하고 실제 프로젝트에 적용할 수 있도록 쉽고 친절하게 설명해 드릴 것입니다. Sealed Class의 등장 배경부터 문법, 규칙, 활용 사례, 그리고 다른 자바 문법들과의 비교를 통해 이 강력한 기능이 여러분의 코드 품질을 어떻게 한 단계 더 끌어올릴 수 있는지 함께 탐구해 봅시다.

---

Sealed Class 도입 배경 및 핵심 개념

소프트웨어 개발에서 클래스 간의 관계, 특히 상속 관계는 매우 중요합니다. 상속은 코드 재사용성을 높이고, 특정 기능을 확장하는 데 유용하지만, 무분별하게 사용될 경우 예상치 못한 부작용을 낳을 수 있습니다. 예를 들어, 어떤 클래스를 설계했는데, 나중에 개발자가 의도하지 않은 방식으로 해당 클래스가 확장되어 시스템에 문제를 일으키는 경우가 종종 발생합니다. 이러한 상황은 코드의 견고성을 해치고, 디버깅을 어렵게 만들며, 장기적으로 소프트웨어 유지보수 비용을 증가시키는 주범이 됩니다.

기존 자바에서는 상속을 제한하기 위해 final 키워드를 사용했지만, final은 더 이상 상속을 허용하지 않는다는 의미일 뿐, 어떤 특정 클래스들만 상속할 수 있는지 명확하게 지정하는 방법은 없었습니다. 이는 라이브러리나 프레임워크를 개발할 때 특히 큰 단점으로 작용했습니다. API 설계자는 자신의 클래스 계층 구조가 어떻게 확장될지 통제할 수 없었고, 이는 곧 외부 개발자들이 의도치 않게 불안정한 코드를 만들 위험을 높였습니다. 마치 중요한 건물의 출입문을 잠가 아무도 들어오지 못하게 막는 것(final)과, 건물에 들어올 수 있는 특정 사람들을 미리 지정하여 명단을 작성해 두는 것(sealed)의 차이와 같습니다. 전자는 완전히 폐쇄적이지만, 후자는 통제된 범위 내에서만 개방하는 형태인 것이죠.

이러러한 배경 속에서 자바 개발자들은 클래스 계층 구조를 더욱 세밀하게 통제하고, 개발자가 명시적으로 허용한 특정 서브클래스들만 상속받을 수 있도록 하는 메커니즘의 필요성을 강하게 느끼게 되었습니다. 이것이 바로 자바 17에서 표준화된 Sealed Class의 핵심 등장 배경이자 목적입니다. Sealed Class는 이름 그대로 '봉인된 클래스'를 의미하며, 특정 클래스나 인터페이스를 상속받거나 구현할 수 있는 클래스들을 명확하게 지정합니다.

Sealed Class의 핵심 원리: 제한된 상속(Restricted Inheritance)

Sealed Class의 핵심은 제한된 상속입니다. 이는 개발자가 어떤 클래스(또는 인터페이스)가 자신의 자식 클래스(또는 구현 클래스)가 될 수 있는지를 코드에 직접 명시하는 것을 말합니다. 이렇게 명시적으로 허용된 클래스들만이 Sealed Class를 상속받거나 Sealed Interface를 구현할 수 있습니다. 예를 들어, Shape라는 Sealed Class가 있다면, 개발자는 오직 Circle, Square, Triangle만이 Shape를 상속받을 수 있음을 선언할 수 있습니다. 다른 어떤 클래스도 Shape를 상속받을 수 없으며, 만약 시도한다면 컴파일 시점에서 오류가 발생합니다.

이러한 제한은 코드의 예측 가능성을 비약적으로 향상시킵니다. Shape 클래스를 사용하는 개발자는 Shape의 자식 클래스가 Circle, Square, Triangle뿐이라는 것을 확실히 알 수 있으므로, 모든 경우의 수를 처리하는 코드를 작성할 때 누락되는 부분이 없음을 컴파일러로부터 보장받을 수 있습니다. 이는 특히 switch 표현식이나 instanceof 패턴 매칭과 함께 사용될 때 강력한 시너지를 발휘하여, 코드의 안정성을 높이고 잠재적인 버그를 줄이는 데 크게 기여합니다. 더 이상 예상치 못한 새로운 자식 클래스가 등장하여 기존 로직을 깨뜨릴까 걱정할 필요가 없어지는 것입니다. 이는 마치 퍼즐 조각을 맞출 때, 전체 그림을 구성하는 조각들이 무엇인지 정확히 알고 있는 것과 같습니다. 모든 조각의 형태와 개수를 알기 때문에, 빠진 조각 없이 완벽한 그림을 완성할 수 있다는 확신을 가질 수 있게 됩니다. Sealed Class는 바로 이러한 확신을 코드에 부여하는 강력한 도구입니다.

요약하자면, Sealed Class는 다음과 같은 필요성 때문에 등장했습니다:

• 클래스 계층 구조의 무분별한 확장 제한: 개발자가 의도하지 않은 상속으로 인해 발생할 수 있는 문제를 방지합니다.
• 설계의 명확성 및 안정성 강화: 어떤 클래스가 상속될 수 있는지 명시함으로써 코드의 의도를 명확히 하고, 시스템의 안정성을 높입니다.
• 컴파일 타임 안전성 보장: 컴파일러가 제한된 계층 구조를 기반으로 잠재적인 오류를 미리 감지할 수 있도록 돕습니다.
• 향상된 패턴 매칭 지원: 특히 자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능과 결합하여, 모든 경우의 수를 처리했음을 보장받을 수 있게 합니다.

Sealed Class는 자바가 더욱 강력하고 유연하며 안전한 언어로 발전하고 있음을 보여주는 중요한 이정표입니다. 이제 다음 섹션에서는 이 매력적인 기능의 실제 문법과 사용 방법을 자세히 살펴보겠습니다.

---

Java Sealed Class 문법: 선언과 사용법 완벽 이해

Sealed Class를 사용하기 위한 문법은 비교적 직관적이지만, 몇 가지 새로운 키워드와 규칙을 이해해야 합니다. 핵심은 sealed, permits, 그리고 자식 클래스에서 사용해야 하는 final, non-sealed, sealed 키워드입니다.

이미지: Java 17 Sealed Class의 문법 예시. Shape가 sealed 키워드로 선언되고, permits 키워드를 통해 허용되는 Circle, Square 클래스들이 명시적으로 표시된 코드 스니펫입니다.

1. sealed 키워드를 사용한 Sealed Class/Interface 선언

가장 먼저, 부모 클래스나 인터페이스를 '봉인된' 상태로 만들기 위해 sealed 키워드를 사용합니다. 이 키워드는 해당 클래스나 인터페이스가 특정 서브타입만을 허용한다는 것을 명시합니다.

// Sealed Class 선언 예시
public sealed class Shape permits Circle, Square, Triangle {
    // Shape의 공통 속성이나 메서드
    public abstract double area();
    public abstract double perimeter();
}

위 코드에서 public sealed class Shape는 Shape가 봉인된 클래스임을 선언합니다. 즉, Shape는 무한정 확장될 수 있는 것이 아니라, 정해진 특정 클래스들만 상속받을 수 있습니다.

2. permits 키워드를 사용한 허용된 서브타입 지정

sealed 키워드 뒤에는 반드시 permits 키워드가 따라와야 합니다. permits 다음에는 쉼표(,)로 구분하여 해당 sealed 클래스나 인터페이스를 직접 상속받거나 구현할 수 있는 클래스(또는 인터페이스)들의 목록을 나열합니다.

public sealed class Shape permits Circle, Square, Triangle { ... }

이 예시에서는 Shape 클래스를 상속받을 수 있는 유일한 클래스는 Circle, Square, Triangle뿐임을 명시하고 있습니다. 다른 어떤 클래스도 Shape를 상속받을 수 없습니다. 만약 permits 목록에 없는 Rectangle이라는 클래스가 Shape를 상속받으려고 한다면, 컴파일 시점에 오류가 발생하게 됩니다. 이는 개발자가 의도한 클래스 계층 구조의 무결성을 강력하게 보장하는 핵심 메커니즘입니다. permits 목록은 마치 '화이트리스트'와 같아서, 여기에 명시된 클래스들만 상속 관계를 형성할 수 있는 특권을 가지게 됩니다.

3. 허용된 서브타입의 선언: final, non-sealed, sealed

permits 키워드로 허용된 서브클래스들은 반드시 다음 세 가지 키워드 중 하나로 선언되어야 합니다. 이는 해당 서브클래스가 자신의 상속 계층을 어떻게 이어갈지를 명확히 합니다.

• final: 해당 서브클래스는 더 이상 다른 클래스에게 상속될 수 없습니다. 즉, 이 지점에서 상속 계층이 완전히 종료됩니다. 이는 계층 구조의 최하단에 위치하는 클래스에 주로 사용됩니다.Circle은 Shape의 자식 클래스이지만, final로 선언되었기 때문에 Circle을 상속받는 또 다른 클래스를 만들 수 없습니다.
• public final class Circle extends Shape { private double radius; public Circle(double radius) { this.radius = radius; } @Override public double area() { return Math.PI * radius * radius; } @Override public double perimeter() { return 2 * Math.PI * radius; } }
• sealed: 해당 서브클래스 또한 sealed 클래스로 선언되어, 자신만의 permits 목록을 통해 그 아래의 상속을 제한할 수 있습니다. 이는 다단계의 제한된 상속 계층을 만들 때 유용합니다.이 예시에서 Triangle은 Shape의 자식 클래스이면서 동시에 sealed 클래스입니다. 따라서 Triangle은 EquilateralTriangle과 IsoscelesTriangle이라는 특정 자식 클래스만을 허용합니다.
• public sealed class Triangle extends Shape permits EquilateralTriangle, IsoscelesTriangle { // Triangle의 공통 속성이나 메서드 // ... } public final class EquilateralTriangle extends Triangle { /* ... */ } public final class IsoscelesTriangle extends Triangle { /* ... */ }
• non-sealed: 해당 서브클래스는 sealed의 제한을 풀고, 일반적인 클래스처럼 자유롭게 상속될 수 있도록 허용합니다. 이는 특정 지점부터는 상속의 제약을 없애고 싶을 때 사용합니다.Square는 Shape의 자식 클래스이지만, non-sealed로 선언되었기 때문에 Square를 상속받는 FancySquare와 같은 클래스는 permits 목록에 없어도 허용됩니다. non-sealed는 특정 부분에서 제한을 해제하여 유연성을 제공하는 역할을 합니다.
• public non-sealed class Square extends Shape { private double side; public Square(double side) { this.side = side; } @Override public double area() { return side * side; } @Override public double perimeter() { return 4 * side; } // Square는 non-sealed이므로, 누구든지 Square를 상속받아 확장할 수 있습니다. } // Square는 non-sealed이므로, 누구든지 자유롭게 상속 가능 public class FancySquare extends Square { public FancySquare(double side) { super(side); } // ... }

Sealed Interface

Sealed Class와 마찬가지로 인터페이스도 sealed 키워드를 사용하여 봉인할 수 있습니다. sealed interface는 특정 인터페이스만이 구현하거나 확장할 수 있도록 제한합니다. 이는 다형성을 활용하면서도 구현체의 범위를 명확히 하고자 할 때 매우 유용합니다.

public sealed interface Command permits StartCommand, StopCommand, PauseCommand {
    void execute();
}

public final class StartCommand implements Command {
    @Override public void execute() { System.out.println("Starting..."); }
}

public final class StopCommand implements Command {
    @Override public void execute() { System.out.println("Stopping..."); }
}

public final class PauseCommand implements Command {
    @Override public void execute() { System.out.println("Pausing..."); }
}

위 예시에서 Command 인터페이스는 StartCommand, StopCommand, PauseCommand 세 가지 클래스만이 구현할 수 있음을 명시하고 있습니다. 다른 어떤 클래스도 Command 인터페이스를 구현할 수 없으므로, 커맨드 패턴을 구현할 때 예상치 못한 커맨드 클래스가 추가되는 것을 방지하고, 모든 커맨드 유형을 철저히 관리할 수 있게 됩니다.

이처럼 Sealed Class와 Sealed Interface 문법은 명확하고 강력한 제약 조건을 제공하여, 개발자가 의도한 설계가 흔들림 없이 유지되도록 돕습니다. 다음 섹션에서는 이러한 문법을 사용할 때 지켜야 할 구체적인 규칙과 제약 사항들에 대해 더 깊이 알아보겠습니다.

---

Sealed Class의 핵심 규칙 및 상속 제약 조건

Sealed Class와 Sealed Interface는 강력한 기능을 제공하는 만큼, 그 사용에도 몇 가지 명확한 규칙과 제약 사항이 따릅니다. 이러한 규칙들은 Sealed Class의 핵심 목적인 '제한된 상속'을 효과적으로 달성하고, 컴파일러가 코드의 완전성을 검증할 수 있도록 돕는 기반이 됩니다. 이 규칙들을 정확히 이해하는 것은 Sealed Class를 올바르고 효과적으로 사용하는 데 필수적입니다.

1. permits 목록의 접근성 및 위치

permits 키워드로 지정된 서브클래스들은 sealed 클래스나 인터페이스와 같은 모듈 내에 존재해야 합니다. 만약 모듈을 사용하지 않는 경우(즉, unnamed module)에는 같은 패키지 내에 존재해야 합니다. 이 규칙은 Sealed Class의 '봉인'이 유효하도록 유지하는 데 매우 중요합니다. 만약 다른 모듈이나 패키지에 있는 클래스가 자유롭게 Sealed Class를 상속받을 수 있다면, 그 '봉인'은 의미가 없어질 것입니다. 이는 마치 특정 건물의 출입 허가 명단이 건물 관리자의 통제 범위 내에 있어야 하는 것과 같습니다. 외부에서 명단을 임의로 수정할 수 있다면, 보안은 무너지게 됩니다.

예를 들어, com.example.shapes 패키지에 Shape Sealed Class가 있다면, Circle, Square 클래스 또한 com.example.shapes 패키지에 있어야 합니다.

// src/main/java/com/example/shapes/Shape.java
package com.example.shapes;

public sealed class Shape permits Circle, Square {
    // ...
}

// src/main/java/com/example/shapes/Circle.java
package com.example.shapes;

public final class Circle extends Shape {
    // ...
}

// src/main/java/com/example/shapes/Square.java
package com.example.shapes;

public non-sealed class Square extends Shape {
    // ...
}

만약 Circle이나 Square가 다른 패키지에 있다면 컴파일 오류가 발생할 것입니다.

2. 모든 허용된 서브타입은 final, non-sealed, sealed 중 하나로 선언되어야 합니다.

앞서 문법 섹션에서 살펴보았듯이, permits 목록에 있는 모든 직접적인 서브클래스나 서브인터페이스는 반드시 final, non-sealed, 또는 sealed 키워드 중 하나로 선언되어야 합니다. 이는 자바 컴파일러가 해당 계층 구조의 다음 단계를 명확히 이해하고 검증할 수 있도록 강제하는 규칙입니다.

• final: 해당 클래스에서 상속 계층이 최종적으로 끝남을 알립니다.
• sealed: 이 서브클래스 역시 봉인되어, 자신만의 허용된 자식 클래스 목록을 가진다는 것을 나타냅니다. 이는 계층적인 봉인을 가능하게 합니다.
• non-sealed: 이 서브클래스부터는 상속 제한을 풀어, 일반적인 클래스처럼 자유롭게 확장될 수 있음을 선언합니다.

이러한 강제성은 Sealed Class의 중요한 장점 중 하나인 완전성 검사(Exhaustiveness Checking)를 가능하게 합니다. 컴파일러는 이 키워드들을 통해 전체 계층 구조의 끝이 어디인지, 또는 어디까지가 제한되고 어디부터 자유로운지 파악할 수 있으며, 이를 바탕으로 자바 21에서 표준화된 switch 표현식의 패턴 매칭 등에서 모든 가능한 서브타입이 처리되었는지 검사할 수 있습니다. 이는 개발자가 모든 경우의 수를 고려했음을 명확히 해주어, 런타임에 발생할 수 있는 잠재적 오류를 컴파일 타임에 방지하는 데 결정적인 역할을 합니다.

3. 허용된 서브타입은 Sealed Class/Interface를 직접 상속/구현해야 합니다.

permits 목록에 지정된 서브타입들은 sealed 클래스나 인터페이스를 직접 상속(extends)하거나 구현(implements)해야 합니다. 간접적인 상속/구현은 허용되지 않습니다. 예를 들어, A permits B 일 때 C extends B는 가능하지만, C extends A는 허용되지 않습니다. B가 A를 상속받은 후에 C는 B를 상속받아야 하는 것이죠.

public sealed class Animal permits Mammal, Bird { /* ... */ }

public sealed class Mammal extends Animal permits Dog, Cat { /* ... */ } // 직접 상속
public final class Dog extends Mammal { /* ... */ } // Mammal을 직접 상속
// public class SomeOtherDog extends Animal { /* ... */ } // 오류! Animal을 직접 상속할 수 없음

이 규칙은 상속 계층의 직관적인 이해를 돕고, permits 목록의 의미를 명확하게 유지합니다.

4. 추상 클래스와 인터페이스의 Sealed 특성

Sealed Class나 Sealed Interface는 abstract 키워드와 함께 사용될 수 있습니다. 추상 Sealed Class는 일부 메서드의 구현을 강제하면서도, 동시에 그 구현체를 특정 클래스들로 제한할 수 있습니다. 마찬가지로 추상 Sealed Interface도 특정 구현체만을 허용하면서 계약을 정의할 수 있습니다.

public sealed abstract class Vehicle permits Car, Bike {
    public abstract void drive();
}

public final class Car extends Vehicle {
    @Override public void drive() { System.out.println("Driving a car."); }
}

public final class Bike extends Vehicle {
    @Override public void drive() { System.out.println("Riding a bike."); }
}

여기서 Vehicle은 sealed abstract class이므로, drive() 메서드 구현을 강제하면서도, 오직 Car와 Bike만이 Vehicle을 상속받을 수 있도록 제한합니다.

이러한 제약들이 설계에 주는 이점

이러한 엄격한 규칙과 제약 사항들은 단순히 개발자에게 불편을 주기 위함이 아닙니다. 오히려 이는 다음과 같은 중요한 설계 이점을 제공합니다.

• API 설계의 명확성 및 의도 표현: 라이브러리 개발자가 자신의 API가 어떻게 확장되기를 원하는지 명확하게 표현할 수 있게 됩니다. "이 인터페이스를 구현할 수 있는 것은 오직 이 세 가지 클래스뿐이다"와 같은 의도를 코드 자체에 녹여낼 수 있습니다.
• 컴파일 타임 안전성 극대화: 예상치 못한 서브클래스의 등장을 원천 봉쇄하여, 런타임에 발생할 수 있는 ClassCastException 같은 오류를 컴파일 시점에 잡아낼 수 있습니다. 이는 소프트웨어의 신뢰성을 크게 향상시킵니다.
• 완전성 검사를 통한 유지보수성 향상: 자바 21에서 표준화된 switch 표현식의 패턴 매칭과 함께 사용할 때, 컴파일러는 sealed 클래스의 모든 서브타입이 처리되었는지 확인할 수 있습니다. 새로운 서브타입이 추가되면 컴파일러가 경고나 오류를 발생시켜, 기존 코드를 업데이트해야 함을 알려줍니다. 이는 장기적인 코드 유지보수와 확장을 훨씬 용이하게 만듭니다.
• 도메인 모델의 일관성 유지: 특정 도메인 개념을 표현하는 클래스들이 정해진 범위 내에서만 존재하도록 강제함으로써, 도메인 모델의 일관성과 무결성을 강력하게 보장할 수 있습니다.

결론적으로, Sealed Class의 규칙과 제약 사항은 단순한 문법적인 강제가 아니라, 견고하고 예측 가능하며 유지보수하기 쉬운 소프트웨어를 만들기 위한 강력한 설계 원칙을 담고 있습니다. 다음 섹션에서는 이러한 원칙들이 실제 어떤 시나리오에서 빛을 발하는지 구체적인 사용 사례들을 통해 알아보겠습니다.

---

Sealed Class 활용 사례 및 주요 장점

Sealed Class는 단순한 문법적 추가를 넘어, 특정 설계 패턴을 구현하거나 도메인 모델을 구성할 때 혁신적인 개선을 가져올 수 있습니다. 특히 클래스 계층 구조가 '닫혀 있어야' 하고, 그 안의 모든 가능한 서브타입을 명확히 정의하고 싶을 때 Sealed Class는 빛을 발합니다.

1. 상태 패턴 (State Pattern) 구현

상태 패턴은 객체의 내부 상태가 변경될 때 객체의 동작을 변경하는 데 사용됩니다. Sealed Class는 특정 객체가 가질 수 있는 모든 상태를 명확하게 정의하고 제한할 때 완벽하게 들어맞습니다.

예시: 주문 처리 시스템의 OrderStatus

// Sealed Interface로 상태 정의
public sealed interface OrderStatus permits Created, Processing, Shipped, Delivered, Cancelled {
    String getDescription();
}

public final class Created implements OrderStatus {
    @Override public String getDescription() { return "주문이 생성되었습니다."; }
}

public final class Processing implements OrderStatus {
    @Override public String getDescription() { return "주문 처리 중입니다."; }
}

public final class Shipped implements OrderStatus {
    @Override public String getDescription() { return "상품이 배송되었습니다."; }
}

public final class Delivered implements OrderStatus {
    @Override public String getDescription() { return "배송 완료되었습니다."; }
}

public final class Cancelled implements OrderStatus {
    @Override public String getDescription() { return "주문이 취소되었습니다."; }
}

여기서 OrderStatus는 sealed 인터페이스이므로, 오직 Created, Processing, Shipped, Delivered, Cancelled만이 OrderStatus를 구현할 수 있습니다. 이렇게 하면 주문 상태를 처리하는 로직에서 모든 가능한 상태를 자바 21에서 표준화된 switch 표현식으로 안전하게 처리할 수 있으며, 미래에 새로운 상태가 추가될 경우 컴파일러가 해당 로직의 업데이트를 강제하여 누락된 처리를 방지할 수 있습니다.

2. 표현식 트리 (Expression Trees) 또는 추상 구문 트리 (AST)

컴파일러, 파서, 계산기 등에서 복잡한 수식이나 문장을 표현하는 트리 구조를 만들 때 Sealed Class가 유용합니다. 트리의 각 노드 타입(예: 숫자, 덧셈, 뺄셈, 변수)을 특정 집합으로 제한할 수 있습니다.

예시: 간단한 산술 표현식

// Sealed Class로 표현식의 기본 구조 정의
public sealed interface Expression permits NumberLiteral, Addition, Subtraction, Multiplication {
    int evaluate();
}

public record NumberLiteral(int value) implements Expression {
    @Override public int evaluate() { return value; }
}

public record Addition(Expression left, Expression right) implements Expression {
    @Override public int evaluate() { return left.evaluate() + right.evaluate(); }
}

public record Subtraction(Expression left, Expression right) implements Expression {
    @Override public int evaluate() { return left.evaluate() - right.evaluate(); }
}

public record Multiplication(Expression left, Expression right) implements Expression {
    @Override public int evaluate() { return left.evaluate() * right.evaluate(); }
}

이러한 구조는 evaluate() 메서드를 통해 재귀적으로 표현식을 평가할 수 있게 하며, Expression 인터페이스를 구현할 수 있는 노드의 종류를 명확히 제한하여 파싱 로직의 안정성을 높입니다.
sealed 클래스의 모든 permits 서브타입을 switch 표현식의 패턴 매칭으로 처리할 때 (자바 21부터 표준 기능), 컴파일러가 모든 가능한 경우의 수가 처리되었는지 검사합니다. 만약 새로운 서브타입이 추가되었는데 해당 switch 문이 업데이트되지 않았다면, 컴파일러 오류(또는 경고)를 발생시켜 잠재적인 런타임 오류를 미리 방지합니다.
컴파일러는 Expression의 모든 가능한 서브타입을 알고 있으므로, switch 표현식으로 각 노드 유형을 처리할 때 누락되는 부분이 없음을 보장할 수 있습니다.

3. 데이터 모델링 및 메시지 처리

특정 데이터 모델이 가질 수 있는 형태가 제한적이거나, 다양한 유형의 메시지를 처리해야 할 때 Sealed Class는 강력한 도구가 됩니다. 이는 도메인 주도 설계(DDD)에서 "값 객체(Value Object)"나 "도메인 이벤트(Domain Event)"를 모델링할 때 특히 유용합니다.

예시: 고객 알림 메시지

public sealed interface NotificationMessage permits EmailNotification, SMSNotification, PushNotification {
    String getRecipient();
    String getContent();
}

public record EmailNotification(String recipient, String subject, String content) implements NotificationMessage {
    @Override public String getRecipient() { return recipient; }
}

public record SMSNotification(String recipient, String content) implements NotificationMessage {
    @Override public String getRecipient() { return recipient; }
}

public record PushNotification(String recipient, String title, String content) implements NotificationMessage {
    @Override public String getRecipient() { return recipient; }
}

NotificationMessage 인터페이스는 Email, SMS, Push라는 세 가지 알림 유형으로만 제한됩니다. 메시지 발송 시스템은 이 세 가지 유형만을 고려하면 되며, 새로운 알림 유형이 추가되면 컴파일러가 메시지 처리 로직을 업데이트하도록 강제할 수 있습니다. 이를 통해 유연하면서도 강력하게 제어되는 메시지 처리 시스템을 구축할 수 있습니다.

Sealed Class 사용의 주요 장점 정리

Sealed Class를 활용함으로써 얻을 수 있는 장점들은 다음과 같습니다.

• 코드의 명확성 및 의도 표현: 어떤 클래스 계층이 존재하며, 그 계층이 어디까지 확장될 수 있는지 코드 자체로 명확하게 드러냅니다. 이는 코드의 가독성을 높이고, 개발자가 설계자의 의도를 쉽게 파악할 수 있도록 돕습니다.
• 컴파일 타임 안전성 (Exhaustiveness Checking): sealed 클래스의 모든 permits 서브타입을 switch 표현식이나 instanceof 패턴 매칭으로 처리할 때, 컴파일러가 모든 가능한 경우의 수가 처리되었는지 검사합니다. 만약 새로운 서브타입이 추가되었는데 해당 switch 문이 업데이트되지 않았다면, 컴파일러 오류(또는 경고)를 발생시켜 잠재적인 런타임 오류를 미리 방지합니다. 이는 시스템의 견고성을 비약적으로 향상시킵니다.
• 예측 가능한 확장성 (Controlled Extensibility): 무분별한 상속을 방지하고, 허용된 범위 내에서만 확장을 가능하게 합니다. 이는 라이브러리나 프레임워크 설계 시 API의 안정성을 보장하면서도, 필요한 만큼의 유연성을 제공할 수 있게 합니다.
• 안전한 리팩토링 및 유지보수: 클래스 계층 구조가 변경될 때, 컴파일러의 도움을 받아 관련 코드를 안전하게 리팩토링할 수 있습니다. 새로운 서브타입을 추가하거나 기존 서브타입을 제거할 때, 어떤 부분이 영향을 받는지 명확히 파악하고 수정할 수 있습니다.
• 향상된 패턴 매칭 지원: 자바 17에서 도입된 패턴 매칭(instanceof 패턴)과 자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능과 결합될 때, Sealed Class는 그 진가를 발휘합니다. switch 표현식에서 sealed 클래스의 모든 서브타입을 처리했다면, 자바 21에서 표준화된 패턴 매칭 기능을 통해 default 케이스를 생략할 수 있어 코드가 더욱 간결해지고 명확해집니다.

Sealed Class는 단순한 새로운 문법이 아니라, 객체 지향 설계를 더욱 견고하고 안전하게 만들 수 있는 강력한 도구입니다. 이러한 장점들을 잘 이해하고 적절한 상황에 적용한다면, 여러분의 자바 애플리케이션은 한층 더 높은 수준의 품질과 유지보수성을 가지게 될 것입니다.

반응형

---

Sealed Class vs. Enum, Interface, Abstract Class 비교

자바에는 객체 지향 설계에서 특정 계층 구조나 타입 집합을 표현하기 위한 다양한 문법 요소들이 있습니다. interface, abstract class, enum 등이 그 대표적인 예시인데요, Sealed Class는 이들과 유사하면서도 독특한 특징을 가지고 있습니다. 각 문법이 어떤 상황에 더 적합한지 비교 분석하여, 개발자가 상황에 맞는 최적의 선택을 할 수 있도록 돕는 것이 중요합니다.

1. Sealed Class vs. 일반 Interface

일반 Interface:

• 목적: 특정 동작(계약)을 정의하고, 해당 동작을 구현하는 모든 클래스가 따르도록 강제합니다. 다중 상속을 허용하여 유연성을 제공합니다.
• 제한: 어떤 클래스든 인터페이스를 구현할 수 있습니다. 구현 클래스의 종류나 개수에 제한이 없습니다.
• 적합한 상황: 광범위한 다형성이 필요하고, 구현체의 종류를 미리 알 수 없거나 알 필요가 없을 때 (예: List, Map 인터페이스).

Sealed Interface:

• 목적: 일반 인터페이스와 동일하게 동작을 정의하지만, 해당 인터페이스를 구현하거나 확장할 수 있는 클래스/인터페이스의 집합을 명시적으로 제한합니다.
• 제한: permits 키워드를 통해 허용된 특정 클래스/인터페이스만이 Sealed Interface를 구현하거나 확장할 수 있습니다.
• 적합한 상황: 특정 계약을 정의하되, 그 계약을 따르는 구현체의 종류가 한정적이고, 이들을 미리 알고 있어야 할 때 (예: 특정 메시지 유형, 상태 패턴의 상태 정의). 컴파일 타임에 모든 가능한 구현체를 파악하여 안전성을 높이고 싶을 때 유용합니다.

선택 가이드:

• 모든 종류의 구현체가 가능해야 한다면: 일반 interface
• 특정 종류의 구현체만 허용하고, 그 목록이 고정되어 있다면: sealed interface

2. Sealed Class vs. Abstract Class

Abstract Class:

• 목적: 공통적인 속성과 메서드를 정의하고, 일부 메서드는 추상으로 남겨두어 자식 클래스에서 구현하도록 강제합니다. 코드 재사용성을 높입니다. 단일 상속만 허용합니다.
• 제한: 어떤 클래스든 추상 클래스를 상속받을 수 있습니다. 상속받는 클래스의 종류나 개수에 제한이 없습니다.
• 적합한 상황: 공통적인 기본 구현이 필요하며, 자식 클래스 간에 유사한 동작을 공유하지만 완전히 동일하지는 않을 때 (예: java.io.InputStream).

Sealed Class (Abstract Sealed Class 포함):

• 목적: 추상 클래스의 기능(공통 구현, 추상 메서드 정의)을 포함하면서, 동시에 해당 클래스를 상속받을 수 있는 자식 클래스의 집합을 명시적으로 제한합니다.
• 제한: permits 키워드를 통해 허용된 특정 클래스만이 Sealed Class를 상속받을 수 있습니다.
• 적합한 상황: 공통적인 기본 구현이 필요하고, 해당 구현을 확장하는 클래스들의 종류가 한정적이며, 이를 미리 알고 있어야 할 때 (예: 특정 도형의 기본 속성을 가지되, Circle, Square 등 정해진 도형만 허용할 때).

선택 가이드:

• 공통 구현이 필요하고, 모든 종류의 자식 클래스가 가능해야 한다면: abstract class
• 공통 구현이 필요하고, 특정 종류의 자식 클래스만 허용해야 한다면: sealed class (추상 메서드가 필요하면 abstract sealed class)

3. Sealed Class vs. Enum

Enum (열거형):

• 목적: 고정된 상수 집합을 정의합니다. 컴파일 타임에 모든 인스턴스가 생성되며, 런타임에 새로운 인스턴스를 추가할 수 없습니다.
• 제한: enum 자체는 확장될 수 없습니다. 각 열거형 상수는 고유한 인스턴스입니다.
• 적합한 상황: 완전히 고정된, 변경되지 않는 값의 집합이 필요할 때 (예: 요일, 트래픽 라이트 색상, 방향). 각 상수가 고유한 데이터를 가지거나 메서드를 오버라이드할 수 있지만, '타입'을 확장하는 개념은 아닙니다.

Sealed Class:

• 목적: 고정된 타입(Type)의 집합을 정의합니다. 각 permits된 서브클래스는 일반 클래스처럼 여러 인스턴스를 가질 수 있으며, 자체적인 상태와 동작을 가질 수 있습니다.
• 제한: permits 키워드를 통해 허용된 서브클래스만 존재할 수 있지만, 각 서브클래스는 여러 인스턴스를 생성할 수 있고, 상태를 가질 수 있으며, 추가적인 상속(non-sealed 또는 sealed)도 가능합니다.
• 적합한 상황: 고정된 '종류'의 객체들이 필요하지만, 각 종류가 자체적인 상태와 다양한 인스턴스를 가질 수 있어야 할 때 (예: Shape Sealed Class 아래의 Circle(반지름), Square(변)). 각 서브타입이 단순한 상수가 아니라 복합적인 데이터를 가지거나 복잡한 로직을 수행해야 할 때 유용합니다.

선택 가이드:

• 완전히 고정된, 불변의 '값'의 집합이 필요하고 각 값이 고유한 인스턴스를 가져야 한다면: enum
• 고정된 '종류'의 객체들이 필요하지만, 각 종류가 여러 인스턴스를 가질 수 있고 상태 및 복잡한 동작을 포함해야 한다면: sealed class

결론: 최적의 선택은 상황에 따라

Sealed Class는 기존의 자바 문법들이 제공하지 못했던 "제한된 다형성"과 "완전성 검사"라는 독특한 이점을 제공합니다. 이는 특히 도메인 모델링, 상태 패턴, 표현식 트리 등 특정 타입의 집합이 고정되어 있고, 그 집합의 모든 구성 요소를 명시적으로 관리해야 할 때 매우 강력한 도구가 됩니다.

따라서 어떤 문법을 선택할지는 여러분이 해결하려는 문제의 본질과 요구 사항에 따라 달라집니다.

• 유연하고 광범위한 계약 정의가 필요하면 interface.
• 공통 구현과 확장성이 필요하면 abstract class.
• 고정된 상수 집합이 필요하면 enum.
• 특정 타입의 집합을 명확히 제한하고, 컴파일 타임에 완전성을 보장받고 싶을 때는 sealed class (또는 sealed interface).

자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능과 결합될 때, 이전에 switch 문에서 default 케이스를 반드시 넣어야 했던 불편함을 해소하고, "이 클래스는 오직 이 자식들만 가질 수 있다"라는 설계 의도를 코드에 직접적으로 표현할 수 있게 함으로써, 자바 개발의 새로운 지평을 열었습니다. 다음 섹션에서는 이 모든 이론을 바탕으로 실제 애플리케이션에서 Sealed Class를 활용하는 구체적인 예제를 살펴보겠습니다.

---

Sealed Class 실전 예제: 안전한 도형 면적 계산

이제 Sealed Class에 대한 개념, 문법, 규칙, 그리고 다른 문법들과의 비교를 통해 그 강력함을 충분히 이해하셨을 것입니다. 이 섹션에서는 실제 자바 애플리케이션에서 Sealed Class를 활용하는 구체적인 코드 예제를 통해, 학습한 내용을 실질적으로 적용하는 방법을 보여드리겠습니다. 여기서는 "도형의 면적 계산"이라는 고전적인 예제를 통해 Sealed Class가 어떻게 코드의 안정성과 명확성을 높이는지 살펴보겠습니다.

시나리오: 다양한 도형의 면적 계산

우리는 여러 가지 도형(원, 사각형, 삼각형)의 면적을 계산하는 시스템을 구축하고 있습니다. 이 시스템은 현재 이 세 가지 도형만을 지원하며, 앞으로도 다른 종류의 도형이 추가될 가능성은 매우 낮거나, 추가되더라도 엄격하게 통제되어야 한다고 가정합니다.

기존 방식에서는 Shape라는 추상 클래스를 만들고, Circle, Rectangle, Triangle이 이를 상속받는 형태로 구현했을 것입니다. 하지만 Sealed Class를 사용하면, 이 Shape 계층 구조를 더욱 강력하게 제어할 수 있습니다.

// src/main/java/com/example/shapes/Shape.java
package com.example.shapes;

/**
 * 도형을 나타내는 Sealed Interface.
 * 이 인터페이스는 Circle, Rectangle, Triangle 세 가지 도형만을 허용합니다.
 * 모든 도형은 면적(area)과 둘레(perimeter)를 계산하는 기능을 가져야 합니다.
 */
public sealed interface Shape permits Circle, Rectangle, Triangle {
    /**
     * 도형의 면적을 계산합니다.
     * @return 계산된 면적 값
     */
    double area();

    /**
     * 도형의 둘레를 계산합니다.
     * @return 계산된 둘레 값
     */
    double perimeter();
}

Shape를 sealed interface로 선언하고, permits 키워드를 사용하여 Circle, Rectangle, Triangle만을 허용하도록 명시했습니다. 이제 이 인터페이스를 구현하는 각 도형 클래스를 만들어보겠습니다. 여기서는 record 타입을 활용하여 불변 객체로 간단하게 모델링할 수 있습니다. record 타입은 자바 16에서 표준화된 기능으로, 데이터 홀더 클래스를 간결하게 정의하는 데 매우 유용하며, Sealed Class와 함께 사용될 때 강력한 시너지를 발휘합니다.

// src/main/java/com/example/shapes/Circle.java
package com.example.shapes;

/**
 * 원을 나타내는 record 클래스.
 * Shape 인터페이스를 구현하며, 반지름(radius)을 가집니다.
 */
public record Circle(double radius) implements Shape {
    public Circle {
        if (radius < 0) {
            throw new IllegalArgumentException("반지름은 음수가 될 수 없습니다.");
        }
    }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }

    @Override
    public double perimeter() {
        return 2 * Math.PI * radius;
    }
}

// src/main/java/com/example/shapes/Rectangle.java
package com.example.shapes;

/**
 * 직사각형을 나타내는 record 클래스.
 * Shape 인터페이스를 구현하며, 너비(width)와 높이(height)를 가집니다.
 */
public record Rectangle(double width, double height) implements Shape {
    public Rectangle {
        if (width < 0 || height < 0) {
            throw new IllegalArgumentException("너비와 높이는 음수가 될 수 없습니다.");
        }
    }

    @Override
    public double area() {
        return width * height;
    }

    @Override
    public double perimeter() {
        return 2 * (width + height);
    }
}

// src/main/java/com/example/shapes/Triangle.java
package com.example.shapes;

/**
 * 삼각형을 나타내는 record 클래스.
 * Shape 인터페이스를 구현하며, 밑변(base)과 높이(height)를 가집니다.
 * (단순화를 위해 직각 삼각형으로 가정합니다.)
 */
public record Triangle(double base, double height) implements Shape {
    public Triangle {
        if (base < 0 || height < 0) {
            throw new IllegalArgumentException("밑변과 높이는 음수가 될 수 없습니다.");
        }
    }

    @Override
    public double area() {
        return 0.5 * base * height;
    }

    @Override
    public double perimeter() {
        // 직각 삼각형으로 가정하고 빗변 계산 (피타고라스 정리)
        double hypotenuse = Math.sqrt(base * base + height * height);
        return base + height + hypotenuse;
    }
}

보시다시피, 각 도형 클래스는 final로 선언되지 않았지만, record 클래스는 암묵적으로 final이므로 명시적으로 final 키워드를 붙일 필요가 없습니다. 이는 Circle, Rectangle, Triangle이 더 이상 상속될 수 없다는 것을 의미하며, Shape 계층 구조의 끝을 명확히 합니다.

Sealed Class와 switch 표현식의 시너지

이제 이 Shape 계층 구조를 활용하여 면적을 계산하는 유틸리티 메서드를 만들어보겠습니다. 여기서 Sealed Class의 진정한 강점이 드러납니다. 자바 17 이상에서 Sealed Class를 사용하고, 자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능을 함께 사용하면, Shape 인터페이스가 Circle, Rectangle, Triangle만을 허용한다는 것을 컴파일러가 인지하여 '완전성 검사(Exhaustiveness Checking)'를 수행해줍니다. 즉, 모든 가능한 Shape 타입이 처리되었는지 확인해준다는 의미입니다.

// src/main/java/com/example/Main.java
package com.example;

import com.example.shapes.*; // Shape, Circle, Rectangle, Triangle 임포트

public class Main {
    public static void main(String[] args) {
        Shape circle = new Circle(5.0);
        Shape rectangle = new Rectangle(4.0, 6.0);
        Shape triangle = new Triangle(3.0, 4.0);

        System.out.println("원의 면적: " + calculateArea(circle));
        System.out.println("직사각형의 면적: " + calculateArea(rectangle));
        System.out.println("삼각형의 면적: " + calculateArea(triangle));

        System.out.println("원의 둘레: " + calculatePerimeter(circle));
        System.out.println("직사각형의 둘레: " + calculatePerimeter(rectangle));
        System.out.println("삼각형의 둘레: " + calculatePerimeter(triangle));
    }

    /**
     * 주어진 도형의 면적을 계산합니다.
     * Sealed Class의 모든 서브타입을 switch 표현식으로 처리합니다.
     */
    public static double calculateArea(Shape shape) {
        // Java 17 Sealed Class와 Java 21 표준화된 switch 표현식의 패턴 매칭 활용
        return switch (shape) {
            case Circle c      -> c.area();
            case Rectangle r   -> r.area();
            case Triangle t    -> t.area();
            // Sealed Class의 모든 허용된 서브타입을 처리했으므로 (자바 21 표준 기능),
            // default 케이스를 생략할 수 있습니다. (컴파일러가 보장)
        };
    }

    /**
     * 주어진 도형의 둘레를 계산합니다.
     * Sealed Class의 모든 서브타입을 switch 표현식으로 처리합니다.
     */
    public static double calculatePerimeter(Shape shape) {
        return switch (shape) {
            case Circle c      -> c.perimeter();
            case Rectangle r   -> r.perimeter();
            case Triangle t    -> t.perimeter();
        };
    }
}

이 코드의 주요 장점:

1. 컴파일 타임 안전성 (Exhaustiveness Checking): 자바 17 이상에서 Sealed Class를 사용하고, 자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능을 함께 사용하면, Shape 인터페이스가 Circle, Rectangle, Triangle만을 허용한다는 것을 컴파일러가 인지하여 '완전성 검사'를 수행해줍니다. 따라서 모든 가능한 Shape의 서브타입을 처리했음을 컴파일러가 보장해줍니다. 만약 우리가 Shape 인터페이스에 permits Hexagon을 추가했는데, calculateArea 메서드의 switch 문에 Hexagon에 대한 처리가 없다면, 컴파일 시점에 오류가 발생합니다. 이는 런타임에 발생할 수 있는 IncompatibleClassChangeError나 논리적 오류를 미연에 방지합니다.
2. 코드의 명확성: switch 표현식을 보면 Shape라는 개념이 어떤 구체적인 도형들로 구성되어 있는지 즉시 파악할 수 있습니다. 이는 코드의 가독성을 크게 향상시킵니다.
3. 유지보수 용이성: 새로운 도형 타입이 추가될 때, Shape 인터페이스의 permits 목록을 업데이트하고, switch 표현식을 사용하는 모든 위치에서 컴파일러의 도움을 받아 변경 사항을 반영할 수 있습니다. 이는 대규모 프로젝트에서 코드의 일관성과 유지보수성을 극대화하는 데 기여합니다.

이 예제는 Sealed Class가 어떻게 자바 코드의 안정성과 명확성, 그리고 유지보수성을 향상시키는 강력한 도구가 될 수 있는지 명확하게 보여줍니다. 특히 record 타입과 switch 표현식의 패턴 매칭 기능과 결합될 때, Sealed Class는 더욱 빛을 발하며, 현대적인 자바 애플리케이션 개발에 필수적인 요소로 자리매김할 것입니다.

---

결론 및 다음 단계

오늘 우리는 자바 17에서 표준화된 Sealed Class의 모든 것을 깊이 있게 탐구했습니다. 무분별한 상속이 초래하는 복잡성과 불안정성을 해결하기 위해 등장한 Sealed Class는, 개발자가 클래스 계층 구조를 명시적으로 제한하고 제어할 수 있는 강력한 메커니즘을 제공합니다. 이는 코드의 예측 가능성을 높이고, 컴파일 타임에 잠재적 오류를 방지하며, 나아가 더욱 견고하고 유지보수하기 쉬운 소프트웨어 아키텍처를 구축하는 데 필수적인 역할을 합니다.

우리는 Sealed Class의 도입 배경과 핵심 개념부터 시작하여, sealed, permits, final, non-sealed와 같은 핵심 문법 요소를 자세히 살펴보았습니다. 또한, Sealed Class 사용 시 지켜야 할 엄격한 규칙과 제약 사항들이 왜 필요한지, 그리고 이러한 제약들이 설계에 어떤 이점을 가져다주는지 깊이 있게 분석했습니다. 상태 패턴, 표현식 트리, 데이터 모델링 등 Sealed Class가 빛을 발하는 주요 사용 사례들을 통해 그 실용적인 가치를 확인했으며, 마지막으로 interface, abstract class, enum과 같은 기존 자바 문법들과의 비교를 통해 Sealed Class가 어떤 상황에서 최적의 선택이 될 수 있는지 명확한 가이드를 제시했습니다. 최종적으로는 실제 도형 면적 계산 예제를 통해 record 타입과 switch 표현식의 패턴 매칭과 결합된 Sealed Class의 강력함을 직접 코드로 경험했습니다.

Sealed Class는 단순한 문법적 추가를 넘어, 객체 지향 설계의 새로운 패러다임을 제시합니다. 이제 여러분은 특정 도메인 모델을 명확하고 안전하게 정의하거나, 특정 타입의 집합을 완벽하게 통제해야 할 때 이 강력한 도구를 자신 있게 활용할 수 있게 되었습니다.

다음 단계:

1. 자바 17+ 환경 설정: 아직 자바 17 이상을 사용하고 있지 않다면, 개발 환경을 업그레이드하여 Sealed Class를 직접 사용해 보세요. 특히 자바 21을 설치하여 switch 표현식의 패턴 매칭 기능을 활용하는 것을 권장합니다.
2. 실제 프로젝트 적용: 여러분이 현재 개발 중인 프로젝트나 사이드 프로젝트에서 Sealed Class를 적용할 수 있는 부분을 찾아보고 시도해 보세요. 특히 상태 머신, 메시지 처리, 이벤트 모델링 등 제한된 타입 계층이 필요한 곳에서 큰 효과를 볼 수 있을 것입니다.
3. 패턴 매칭과 함께 활용: 자바 21에서 표준화된 switch 표현식의 패턴 매칭 기능과 Sealed Class를 함께 사용해 보면서, 컴파일러가 제공하는 완전성 검사의 이점을 직접 경험해 보세요. 이는 코드의 간결함과 안정성을 동시에 향상시키는 핵심적인 조합입니다.

Sealed Class는 자바가 계속해서 현대적인 개발 요구사항에 발맞춰 진화하고 있음을 보여주는 중요한 증거입니다. 이 새로운 기능을 여러분의 자바 개발 역량에 추가하여, 더욱 견고하고 안전하며 효율적인 애플리케이션을 구축하시기를 바랍니다. 지속적인 학습과 실험을 통해 자바의 매력을 더욱 깊이 경험하시길 응원합니다!

---