Interface on kastori

[TS #2] interface vs type — 언제 뭘 쓰는가

Sun, 21 Jun 2026 00:00:00 +0900

TypeScript를 처음 쓰면 금방 이 질문에 부딪힌다. “타입 정의할 때 interface 써야 해, type 써야 해?” 둘 다 되는 것 같고, 문서마다 다르게 쓰여 있다. 결론부터 말하면 객체 형태는 interface, 유니온·복잡한 조합은 type이 실무 기준이다.

interface — 객체의 계약을 정의한다

interface User {
 id: number
 name: string
 email: string
}

const user: User = {
 id: 1,
 name: '홍길동',
 email: 'hong@example.com',
}

Java의 interface와 비슷하다. 객체가 어떤 프로퍼티를 가져야 하는지 정의한다.

선택 프로퍼티와 읽기 전용

interface UserProfile {
 id: number
 name: string
 bio?: string // ? — 있어도 없어도 됨
 readonly createdAt: string // readonly — 수정 불가
}

const profile: UserProfile = { id: 1, name: '홍길동', createdAt: '2026-06-20' }
profile.createdAt = '2026-01-01' // ❌ 컴파일 오류

확장 — extends로 상속

interface Admin extends User {
 role: 'SUPER' | 'MANAGER'
 permissions: string[]
}

Java의 extends와 동일하다.

함수 타입 정의

interface Repository<T> {
 findById(id: number): Promise<T | null>
 save(entity: T): Promise<T>
 delete(id: number): Promise<void>
}

선언 합병 — interface만 가능한 기능

// 같은 이름을 두 번 선언하면 합쳐진다
interface Window {
 myCustomProp: string
}

// 이제 window.myCustomProp 사용 가능

외부 라이브러리 타입에 프로퍼티를 추가할 때 유용하다. type으로는 불가능하다.

type 별칭 — interface가 못하는 것을 한다

// 객체 타입 — interface와 동일
type Point = {
 x: number
 y: number
}

// 유니온 타입 — interface로 불가
type Status = 'pending' | 'approved' | 'rejected'
type ID = string | number

// 인터섹션 — 두 타입을 합침
type AdminUser = User & { role: string }

// 튜플
type Coordinate = [number, number]

// 함수 시그니처 별칭
type Handler = (event: Event) => void

type의 핵심은 유니온과 인터섹션이다. Status처럼 문자열 리터럴의 유니온으로 상태값을 표현하는 것은 TypeScript에서 매우 흔한 패턴인데, 이건 type으로만 할 수 있다.

확장 — &로 합성

type Animal = { name: string }
type Dog = Animal & { breed: string }

interface의 extends와 결과는 같지만 문법이 다르다.

언제 뭘 쓰는가 — 실무 기준

기능	interface	type
객체 타입 정의	✅	✅
확장	`extends`	`&`
유니온 타입	❌	✅
선언 합병	✅	❌
조건부·매핑 타입	❌	✅

interface를 쓸 때:
 - 객체 형태 정의 (DTO, Props, API 응답 구조)
 - 클래스가 구현할 계약
 - 외부 라이브러리 타입 확장 (선언 합병 필요 시)

type을 쓸 때:
 - 유니온 타입 (Status, Role, Direction 등 상태값)
 - 인터섹션으로 타입 합성
 - 조건부·매핑 타입 등 고급 패턴
 - 튜플, 함수 시그니처 별칭

실무 패턴 예시

실제 프로젝트에서 어떻게 나뉘는지 보면 기준이 명확해진다.

// API 응답 구조 — interface
interface ApiResponse<T> {
 data: T
 message: string
 status: number
}

// 상태값 — type (유니온)
type OrderStatus = 'PENDING' | 'PAID' | 'SHIPPED' | 'DELIVERED' | 'CANCELLED'

// React 컴포넌트 Props — interface
interface ButtonProps {
 label: string
 variant?: 'primary' | 'secondary' | 'danger'
 disabled?: boolean
 onClick: () => void
}

// 기존 타입에서 파생 — type
type CreateUserRequest = Omit<User, 'id' | 'createdAt'>
type UpdateUserRequest = Partial<Omit<User, 'id'>>

Omit, Partial 같은 유틸리티 타입을 쓰는 파생 타입은 type으로 만든다. 다음 글에서 이 유틸리티 타입들을 자세히 다룬다.

동적 키 — 인덱스 시그니처

키 이름을 미리 알 수 없는 경우에 쓴다.

interface StringMap {
 [key: string]: string
}

const map: StringMap = {
 name: '홍길동',
 city: '서울',
 // 어떤 string 키든 추가 가능
}

// Record<K, V>가 더 명확한 표현
type StringMap = Record<string, string>

마치며

둘 다 쓸 수 있는 상황에서는 interface를 기본으로 쓰고, 유니온이나 타입 조합이 필요할 때 type으로 전환하면 된다. 팀이 있다면 컨벤션을 하나로 통일하는 것이 중요하다.

다음 글에서는 interface와 type 모두에서 쓸 수 있는 제네릭 — 타입을 파라미터로 받는 방법을 다룬다.

인터페이스 vs 추상 클래스 — 면접 단골 질문, 제대로 이해하기

Sun, 14 Jun 2026 00:00:00 +0900

표를 외우는 것보다 중요한 것

인터페이스와 추상 클래스의 차이를 묻는 면접 질문에 많은 사람이 표를 외워서 답한다. 다중 구현 가능 여부, 생성자 유무, 필드 허용 여부…

하지만 진짜 중요한 건 왜 그렇게 설계됐는지다. 이걸 이해하면 표를 외우지 않아도 언제 무엇을 써야 할지 판단할 수 있다.

인터페이스 — “무엇을 할 수 있는가"의 계약

인터페이스는 구현 클래스가 “어떤 기능을 제공하겠다"는 약속이다.

public interface PaymentService {
 void process(int amount);
 boolean cancel(String orderId);
}

public class KakaopayService implements PaymentService {
 @Override
 public void process(int amount) { /* 카카오페이 결제 로직 */ }

 @Override
 public boolean cancel(String orderId) { /* 취소 로직 */ }
}

public class NaverPayService implements PaymentService {
 @Override
 public void process(int amount) { /* 네이버페이 결제 로직 */ }

 @Override
 public boolean cancel(String orderId) { /* 취소 로직 */ }
}

PaymentService 인터페이스 하나로 카카오페이, 네이버페이를 동일하게 다룰 수 있다. Spring DI에서 이 패턴을 그대로 쓴다.

@Service
public class OrderService {
 private final PaymentService paymentService; // 구현체가 아닌 인터페이스에 의존

 // Spring이 KakaopayService 또는 NaverPayService를 주입
 public OrderService(PaymentService paymentService) {
 this.paymentService = paymentService;
 }
}

다중 구현이 가능한 이유

Java는 클래스 단일 상속만 허용하지만 인터페이스는 여러 개 구현할 수 있다.

// 오리는 날 수도, 헤엄칠 수도 있다
public class Duck extends Animal implements Flyable, Swimmable {
 @Override public void fly() { ... }
 @Override public void swim() { ... }
}

Java 8+ default 메서드

인터페이스에 구현을 추가할 수 있게 됐다. 기존 인터페이스에 메서드를 추가해도 구현 클래스들이 깨지지 않는 장점이 있다.

public interface PaymentService {
 void process(int amount);

 default void processWithLog(int amount) {
 System.out.println("결제 시작: " + amount);
 process(amount);
 System.out.println("결제 완료");
 }
}
// 기존 KakaopayService, NaverPayService는 수정 없이 processWithLog() 사용 가능

추상 클래스 — “공통 구현을 공유”

추상 클래스는 “is-a” 관계에서 공통 로직을 여러 자식이 공유할 때 쓴다.

public abstract class BaseService<T, ID> {
 protected final Logger log = LoggerFactory.getLogger(getClass());

 // 공통 구현 — 모든 자식이 동일하게 사용
 public T findById(ID id) {
 log.debug("조회: {}", id);
 return doFindById(id); // 실제 구현은 자식에게 위임
 }

 // 추상 메서드 — 자식이 반드시 구현
 protected abstract T doFindById(ID id);
}

public class UserService extends BaseService<User, Long> {
 @Override
 protected User doFindById(Long id) {
 return userRepository.findById(id).orElseThrow();
 }
}

이것이 Template Method 패턴이다. 알고리즘 골격(로그 출력 → 조회 → 반환)은 부모가 정의하고, 세부 구현만 자식이 담당한다.

추상 클래스는 생성자와 인스턴스 변수를 가질 수 있어서 상태를 공유할 때도 유리하다.

public abstract class AbstractRepository<T> {
 protected final EntityManager em; // 모든 Repository가 공유

 public AbstractRepository(EntityManager em) {
 this.em = em;
 }
}

언제 무엇을 선택하는가

한 문장으로 정리하면:

인터페이스 → "무엇을 할 수 있는가 (can-do)" — 계약, 다형성
추상 클래스 → "무엇인가 (is-a)" — 공통 구현, 상태 공유

인터페이스를 선택할 때:

1. 관련 없는 클래스들이 같은 기능을 가져야 할 때
 → Serializable, Comparable — Dog, Integer, String 모두 구현 가능

2. 다중 구현이 필요할 때
 → Flyable + Swimmable 동시에

3. Spring DI에서 구현체를 교체할 수 있게 할 때
 → 테스트 시 MockPaymentService로 교체

추상 클래스를 선택할 때:

1. 관련 클래스들이 공통 코드를 공유해야 할 때
 → BaseController, AbstractEntity

2. 상태(필드)를 공유해야 할 때
 → EntityManager, Logger 공유

3. Template Method 패턴 — 알고리즘 골격 고정

함수형 인터페이스와 람다

추상 메서드가 딱 1개인 인터페이스를 함수형 인터페이스라 한다. 람다 표현식으로 구현할 수 있다.

// 익명 클래스로 구현 (Java 8 이전)
Comparator<String> comp = new Comparator<String>() {
 @Override
 public int compare(String a, String b) {
 return a.compareTo(b);
 }
};

// 람다로 구현 (Java 8+)
Comparator<String> comp = (a, b) -> a.compareTo(b);

// 메서드 레퍼런스로 더 간결하게
Comparator<String> comp = String::compareTo;

자주 쓰는 함수형 인터페이스:

Predicate<String> notEmpty = s -> !s.isEmpty(); // 조건 검사
Function<String, Integer> length = String::length; // 변환
Consumer<String> print = System.out::println; // 소비 (반환 없음)
Supplier<String> uuid = () -> UUID.randomUUID().toString(); // 공급

default 메서드 충돌

두 인터페이스가 같은 이름의 default 메서드를 가지면 구현 클래스에서 직접 해결해야 한다.

interface A { default void hello() { System.out.println("A"); } }
interface B { default void hello() { System.out.println("B"); } }

class C implements A, B {
 @Override
 public void hello() {
 A.super.hello(); // A의 default 명시적 선택
 }
}

마치며

인터페이스와 추상 클래스의 차이를 외우는 것보다, “이 설계가 계약(can-do)인가, 공통 구현 공유(is-a)인가"를 생각하는 습관이 더 중요하다.

실무에서는 Spring DI 덕분에 인터페이스를 훨씬 더 많이 쓰게 된다. 다음 편에서는 코드가 실행되는 환경인 JVM 메모리 구조와 GC를 살펴본다.