본문 바로가기
이론/Frontend

타입 안정성을 위한 as unknown as Type

by 유세지 2024. 10. 21.

 

 

 

 

as

 

타입스크립트를 사용하면 가끔 as를 사용한 타입 단언을 해야 할 때가 있습니다.

보통 아래처럼, 컴파일러의 자연스러운 타입 추론이 불가능한 경우 강제로 타입을 지정해줄 때 사용합니다.

 

// 1. DOM 요소
const element = document.querySelector("#App") as HTMLInputElement;

// 2. API의 응답 값
const data = getNativeAPIValue() as APIResponse;

// etc...

 

 

이런 케이스에서는 개발자가 타입을 지정해주고, 타입 시스템은 개발자를 신뢰합니다.

단언은 타입 시스템을 무시 할 정도로 강력하지만, 그만큼 휴먼 에러를 일으킬 가능성이 있기 때문에

타입 시스템이 정상적으로 동작할 수 없는 특수한 상황에만 사용하는게 좋습니다.

 

 

종종 마주하게 되는 타입 에러

 

 

다만, 그냥 as를 사용하게 되면 위처럼 에러를 마주할 때가 있는데요.

실제와 다른 타입으로 단언을 시도했을때, 타입 체커가 개발자의 실수가 아닌지 확인해주는 에러입니다.

 

여기서 타입 체커가 추천하는 방법으로, 타입 단언을 조금 더 안정적으로 사용할 수 있는 방법이 있습니다.

바로 as unknown as Type 을 사용하는 것입니다.

 

 

as unknown as Type

먼저 unknown으로 한 번 타입 단언을 해주고, 원하는 타입으로 한 번 더 단언을 실행합니다.

예를 들면 아래와 같습니다.

 

const processValue = (value: any) => {
    const num = value as unknown as number;
    
    if (typeof num === "number") {
        return num.toFixed(2);
    }
    
    throw new Error("주어진 값이 number가 아닙니다.");
}

processValue(123.123); // 123.12
processValue('문자열'); // "Error: 주어진 값이 number가 아닙니다."

 

 

unknown을 통해 타입 단언을 진행하였으니, 단언 이후 조건문을 통해 타입 체크 과정을 넣어줍니다.

이러한 타입 내로잉이 안전 장치 역할을 수행해주기 때문에 더 안정적인 타입 시스템을 유지할 수 있게 해줍니다.

 

대부분의 타입 확인은 타입 시스템이 담당해주지만 이런식의 타입 단언이 들어가게 되면 타입 안정성이 깨지기 쉬운데, 이처럼 unknown을 사용했을때 타입 내로잉을 추가해주는 패턴을 적용하게 되면 타입이 깨졌을때의 위험을 최소화 시킬 수 있습니다.

 

추가로 타입 내로잉을 위해 ts-pattern과 같은 라이브러리를 사용하여 명시적으로 예외 처리를 강제해주는 것도 휴먼 에러를 줄일 수 있는 좋은 방법입니다. 만약 팀 내에서 사용하게 된다면 이러한 패턴을 컨벤션으로 공유하여 지켜주면 더욱 좋을 것 같습니다.

 

 

반응형

댓글