답변

typealias는 코틀린에서 기존 타입(클래스, 인터페이스, 함수, 제네릭 타입 등)에 대한 대체 이름을 선언하는 메커니즘입니다. 사용 목적은 다음과 같습니다:

• 복잡하고 중첩된 타입의 가독성 향상
• 구현 세부 사항 숨기기
• API 버전 간의 호환성 편리성 제공

제한 사항:

• typealias는 새로운 타입을 생성하지 않으며 단지 두 번째 이름(동의어)을 만들기 때문에 컴파일러가 타입 지정 시 이를 구분하지 않습니다.
• typealias를 사용하여 새로운 기능을 추가할 수 없습니다.
• 별칭은 파일 수준에서만 선언할 수 있으며, 클래스/함수 밖에 있어야 합니다.

적용 예시:

typealias ClickHandler = (View, MotionEvent) -> Unit

fun setClickHandler(handler: ClickHandler) {
    // ...
}

val handler: ClickHandler = { view, event ->
    // 처리 로직
}

유지보수 및 가독성:

• 함수 타입이 너무 복잡할 때 API의 명확성을 향상시킵니다.
• 외부 클라이언트와 호환성을 유지하면서 내부 구현 간의 유연한 마이그레이션이 가능하게 합니다.

함정 질문

질문: "코틀린의 typealias는 컴파일러 관점에서 새로운 타입으로 간주되며 변수 값 제한에 사용할 수 있나요?"

답변: 아닙니다, typealias는 단지 타입의 동의어입니다. 새로운 타입을 형성하지 않으며 컴파일 시 추가적인 검사를 제공하지 않습니다. typealias 타입을 가진 모든 함수, 변수 및 매개변수는 모두 원래 타입과 동일합니다.

예시:

typealias UserId = String
typealias Email = String

fun process(id: UserId) {}
fun process(email: Email) {}

process("abc@def.com") // 오류 없음 — 구분할 수 없음!

주제의 세부 사항을 몰라서 발생한 실제 오류 예시

---

이야기

서로 다른 개체의 식별자(UserId, OrderId)에 대한 typealias를 사용했으며, 컴파일러가 이를 구분할 것이라 생각했지만 실제로는 서로 다른 값을 전달하면서 컴파일 타임 오류 없이 논리 혼란과 버그로 이어졌습니다.

---

이야기

오래된 API에서 마이그레이션할 때 복잡한 람다 표현식에 typealias를 부여했지만 문서에 새로운 정의를 명시하지 않았습니다. 결과적으로 프로그래머는 별칭이 의미하는 바를 이해하지 못하고 잘못 사용하여 런타임 오류를 일으켰습니다.

---

이야기

한 프로젝트에서 서로 다른 파일에 서로 다른 서명을 가진 typealias ViewClickHandler를 재정의하였고, 별칭이 전역적으로 연결될 것이라고 생각했습니다. 결과적으로 문서 자동 생성 시 중복이 발생하게 되었고 컴파일 시 이름 충돌이 발생했습니다.