Apr 3, 2026

어댑터 패턴 가이드: 맞지 않는 인터페이스를 연결하는 방법

실무에서는 내가 원하는 인터페이스와 실제로 받은 인터페이스가 다를 때가 많습니다. 외부 라이브러리, 레거시 코드, 서드파티 API를 붙일 때 특히 그렇습니다. 이럴 때 기존 코드를 전부 뜯어고치지 않고 사이를 이어주는 방식이 어댑터 패턴입니다.

이 글에서는 아래 내용을 정리합니다.

어댑터 패턴이 무엇인지
왜 유용한지
어떤 상황에서 자주 쓰이는지
래퍼와는 어떤 차이로 이해하면 좋은지

핵심은 어댑터 패턴은 맞지 않는 인터페이스를 호출부가 기대하는 형태로 변환해서, 기존 코드 변경을 줄이는 연결 구조라는 점입니다.

어댑터 패턴이란 무엇인가

어댑터 패턴은 기존 구현을 그대로 두고, 그 앞에 중간 변환 계층을 두어 원하는 인터페이스처럼 보이게 만드는 방식입니다.

즉:

실제 구현은 그대로 두고
호출부가 기대하는 형태로 감싸서
연결하는 구조입니다

왜 유용할까

인터페이스가 맞지 않는다고 해서 기존 코드 전체를 바꾸기 시작하면:

영향 범위가 커지고
외부 의존성 세부사항이 퍼지며
테스트와 변경이 어려워질 수 있습니다

어댑터는 이런 변환 책임을 한곳에 모을 수 있습니다.

어떤 상황에서 자주 쓰일까

외부 라이브러리 도입
레거시 API 연결
기존 코드와 새 코드 사이 인터페이스 차이
팀 내부 표준 인터페이스에 맞추고 싶을 때

즉, “완전히 새로 짜기보다 연결해야 하는 상황”에서 특히 잘 맞습니다.

래퍼와는 어떻게 다를까

겹치는 부분이 많지만, 어댑터는 특히 “형태가 안 맞는 것을 맞추는 것”에 더 초점이 있습니다.

즉:

단순 포장
기능 추가

보다는 인터페이스 변환의 의미가 더 강합니다.

자주 하는 오해

1. 인터페이스가 다르면 그냥 호출부를 고치면 된다

작은 경우는 가능하지만, 영향이 커질수록 어댑터가 훨씬 안전한 경우가 많습니다.

2. 어댑터는 임시 땜질이다

잘 설계된 어댑터는 오히려 변경 지점을 격리해주는 좋은 구조가 될 수 있습니다.

3. 어댑터와 데코레이터는 같다

둘 다 감싸는 구조일 수 있지만, 어댑터는 변환, 데코레이터는 기능 추가 쪽에 더 가깝습니다.

Simple Example

class LegacyMailer {
	sendMail(text: string): void {
		console.log(`legacy mail: ${text}`);
	}
}

interface Notifier {
	send(message: string): void;
}

class MailAdapter implements Notifier {
	constructor(private legacyMailer: LegacyMailer) {}

	send(message: string): void {
		this.legacyMailer.sendMail(message);
	}
}

class NotificationService {
	constructor(private notifier: Notifier) {}

	sendWelcome(): void {
		this.notifier.send('Welcome!');
	}
}

const service = new NotificationService(new MailAdapter(new LegacyMailer()));
service.sendWelcome();

The main code expects Notifier, while the adapter translates that expectation into the legacy sendMail interface.

FAQ

Q. 입문자는 어디서 어댑터를 떠올리면 좋을까

외부 라이브러리나 오래된 코드의 인터페이스가 현재 코드 스타일과 맞지 않을 때 좋습니다.

Q. 어댑터는 테스트에도 도움이 되나

그렇습니다. 외부 구현 세부사항을 한곳에 가두면 테스트와 교체가 쉬워질 수 있습니다.

Q. 어댑터를 너무 많이 쓰면 안 복잡할까

그럴 수 있습니다. 그래서 의미 있는 경계에만 두는 것이 중요합니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.