Java 인터페이스 private 메서드 — 구현 캡슐화와 중복 제거
Java 9에서 도입된 인터페이스 private 메서드의 규칙, private vs private static 차이, default/static 메서드의 공통 로직 분리, 실전 설계 패턴을 상세히 정리한다
지난 글에서 Java 8 인터페이스 static 메서드가 어떻게 팩토리·유틸리티 역할을 맡는지 살펴봤다. Java 9는 한 발 더 나아가 private 메서드를 인터페이스에 허용했다. 겉으로 드러나지 않으면서 여러 default/static 메서드가 공유하는 공통 로직을 깔끔하게 분리할 수 있게 된 것이다.
왜 private 메서드가 필요했나
Java 8에서 default 메서드가 생기면서 인터페이스 안에 구현 코드를 둘 수 있게 됐다. 그런데 default 메서드가 여러 개 생기면 같은 검증 로직, 같은 포맷팅 코드가 중복되기 시작했다. 문제는 이 공통 로직을 별도 메서드로 뽑아내도 인터페이스에서는 public default 말고는 선택지가 없었다는 점이다. 구현 세부 사항이 API 표면에 노출되는 꼴이었다.
Java 9는 이 문제를 private 메서드로 해결했다. 인터페이스 내부에서만 호출 가능하고, 구현 클래스에는 전혀 노출되지 않는다.
4가지 핵심 규칙
① 반드시 구현 body를 가져야 한다
abstract와 함께 쓸 수 없다. 선언만 하고 body를 생략하면 컴파일 오류다.
interface Foo {
// 컴파일 오류: abstract + private 불가
// private void bar();
private void bar() { System.out.println("ok"); } // 반드시 body
}② 구현 클래스에서 접근·오버라이드 불가
private이므로 클래스에서 상속받지 못하고, 메서드 이름이 같아도 완전히 별개의 메서드다.
interface Validator {
private boolean isBlank(String s) {
return s == null || s.isBlank();
}
}
class EmailValidator implements Validator {
// isBlank() 호출 불가 — 컴파일 오류
// isBlank("test");
}③ private vs private static
인스턴스 맥락이 필요한 공통 코드는 private으로, static 메서드가 공유할 로직은 private static으로 분리한다.
interface Parser {
default String parseTrimmed(String raw) {
return normalize(raw); // private 호출 가능
}
static String parseStrict(String raw) {
return normalizeStatic(raw); // private static만 호출 가능
}
private String normalize(String s) {
return s == null ? "" : s.strip();
}
private static String normalizeStatic(String s) {
return s == null ? "" : s.strip().toLowerCase();
}
}static 메서드는 인스턴스가 없으므로 인스턴스 private 메서드를 호출하면 컴파일 오류가 난다.
④ 중복 제거가 주 목적
여러 default 메서드가 공유하는 검증·변환 로직을 단일 private 메서드로 모은다.
interface FileProcessor {
default void processText(String path) {
validatePath(path);
// 텍스트 처리 로직
}
default void processBinary(String path) {
validatePath(path);
// 바이너리 처리 로직
}
private void validatePath(String path) {
if (path == null || path.isBlank()) {
throw new IllegalArgumentException("경로가 비어 있습니다: " + path);
}
}
}validatePath 없이 두 default 메서드가 같은 null 체크를 반복해야 했을 것이다.
접근 제어 매트릭스
호출 규칙을 한 줄로 요약하면: private은 default에서만, private static은 default와 static 양쪽에서 호출 가능하며, 구현 클래스는 어느 쪽도 직접 접근할 수 없다.
실전 패턴: 이벤트 핸들러 인터페이스
interface EventHandler<T> {
void handle(T event);
default void handleSafely(T event) {
if (isValid(event)) {
handle(event);
}
}
default void handleWithLog(T event) {
logEvent(event);
if (isValid(event)) {
handle(event);
}
}
private boolean isValid(T event) {
return event != null;
}
private void logEvent(T event) {
System.out.println("[EVENT] " + event);
}
}isValid와 logEvent는 구현 클래스가 알 필요 없는 내부 세부 사항이다. private으로 숨김으로써 API 표면을 handle, handleSafely, handleWithLog 세 가지로 깔끔하게 유지한다.
default 메서드 설계 시 고려할 것
private 메서드를 적절히 쓰면 인터페이스가 훨씬 깔끔해지지만 몇 가지 주의할 점이 있다.
인터페이스는 여전히 계약이다. private 메서드가 생겼다고 해서 인터페이스가 추상 클래스를 완전히 대체하는 건 아니다. 상태(필드)가 필요하거나, 계층 구조를 표현해야 하거나, 단일 상속 제약이 문제라면 추상 클래스를 선택한다.
너무 많은 private 메서드는 인터페이스 비대화 신호다. default와 private 메서드가 늘어나면 인터페이스 역할을 재검토할 시점이다. 공통 로직이 충분히 무거워졌다면 별도 유틸리티 클래스나 추상 클래스로 분리하는 것이 낫다.
Java 8 호환이 필요하다면 사용 불가. private 메서드는 Java 9 이상에서만 동작한다. 멀티 버전 라이브러리를 만든다면 반드시 타깃 버전을 확인한다.
Java 9 이후 인터페이스 메서드 전체 그림
| 종류 | 도입 | body | 상속 | static 호출 |
|---|---|---|---|---|
abstract | Java 1 | 없음 | 강제 구현 | — |
default | Java 8 | 있음 | 상속됨 | — |
static | Java 8 | 있음 | 안 됨 | Interface.method() |
private | Java 9 | 있음 | 안 됨 | — |
private static | Java 9 | 있음 | 안 됨 | 인터페이스 내부만 |
이 다섯 종류를 조합하면 인터페이스 하나로도 상당히 풍부한 계약과 공통 구현을 표현할 수 있다. 다음 글에서는 이 중 abstract 메서드 하나만 가진 특별한 인터페이스, 즉 함수형 인터페이스를 살펴본다.
지난 글: Java 인터페이스 static 메서드 — 팩토리와 유틸리티 설계
다음 글: Java 함수형 인터페이스 — @FunctionalInterface와 람다의 기반
읽어주셔서 감사합니다. 😊