개발자

Typescript에서 as 는 왜 안 좋은가요?

2023년 04월 04일조회 446

오늘 회사에서 코드리뷰를 받았어요. 회사에서는 typescript를 사용합니다. typescript를 처음 써보니까 어렵네요. props의 depth가 너무 깊어서 type을 추론하기가 어려워서 any를 사용하거나 as를 사용해서 코드를 짰습니다. 이 부분에서 코드리뷰에서 받은 코멘트가 as나 any는 좋지 않다라는 의견을 받았네요. 개발자 선배분들은 어떤 점에서 as가 안 좋다고 생각하시나요? 그리고 좋은 수정방법이 있을까요?

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 4

인기 답변

이국범님의 프로필 사진

1. as는 타입스크립트의 타입 검사 기능을 포기하겠다는 것과 마찬가지 입니다 2. as이후로 타입 불일치 또는 프로퍼티 불일치가 발생해도 컴파일 타임에(또는 IDE에서 실시간으로) 에러를 체킹할 수 없습니다. 더 이상 타입스크립트 컴파일러가 책임지지 않습니다 3. 그러므로 as는 (사용 여부에 따라서) 런타임 에러가 발생할 가능성을 높여줍니다 4. 타입스크립트를 사용하는 주된 이유는 런타임 에러를 컴파일 타임으로 당겨와서 에러를 빨리 수정하자는 것인데 사용 취지에 어긋나는 일이라고 할 수 있겠습니다 5. as를 사용해도 되는 상황은 타입이 확정적인 상황이고 다른 타입이 올 가능성이 없는 상황에 사용할 수는 있겠습니다 6. 서버에서 데이터를 응답받을 때는 zod등의 런타임 타입 체킹 라이브러리를 사용하면 as 를 사용하지 않아도 됩니다 7. 타입이 unknown인 경우도 마찬가지로 런타임 타입 체킹 라이브러리를 사용하면 as 를 사용하지 않아도 됩니다 8. 위의 내용들은 as를 사용하여 몇번 골머리를 겪다보면 저절로 체득하게 됩니다 9. 말이 아닌 몸으로 깨닫고 싶으시면 집에 가셔서 토이 프로젝트를 만드신 후에 모든 타입을 as로 도배해 보세요

profile picture

익명

작성자

2023년 04월 06일

아하, any는 웬만하면 안쓰는게 좋군요. 그럼 왜 any를 만든걸까요? 한번 더 찾아봐야겠네요. 좋은 답변 감사합니다!

인기 답변

엄홍재님의 프로필 사진

1. 타입의 변환이 마구마구 가능합니다. 2. 그렇기 때문에 타입이 일치하지 않고, 때문에 의도하지 않은 에러가 발생 할 수 있습니다. 3. 이후에 디버깅이 어렵습니다. (아래 참고) 타입을 최대한 추론해 보시고 잘 정의하는 것도 중요한것 같습니다. 함수같은경우 어떤 값을 넣어야하는지를 잘 처리해 보세요. (하지만 저도 가끔 as를 씁니다 ㅎㅎㅎ API의 response가 보장되지 않는 type같은 경우)

1
2
3
4
5
const testString = 'test';
const testFunction = (testNumber: number) => testNumber;
testFunction((testString as unknown) as number); 
// 이게 가능해집니다. 
// testFunction이 숫자를 number로 연산하는 함수로 변하게 된다면 NaN가 나올것이고 오류가 발생합니다. 하지만 typescript로 잡을 수 없게됩니다 ㅜ
profile picture

익명

작성자

2023년 04월 06일

좋은 답변 감사합니다 홍재님! 참고할게요

김동규님의 프로필 사진

실제 타입 검증을 통한 추론이 아닌 강제로 지정하는 방식이기 때문입니다. 비행기에는 순도 98%의 고급유만 들어갈 수 있습니다 (예를들어) 좋은 주유소에서 고급유 기름을 find 했습니다 기름을 넣으려는데 순도 98% 기름 형식이 아니라 에러가 납니다. 일단 좋은 주유소에서 받아온 고급유니까 넣어도 되겠거니 하면서 as를 통해 순도 98% 고급유로 대충 포장을 해서 넣었습니다. = 나중에 비행기가 터졌습니다. 울면서 수정합니다. 이와 같은 상황이 나올 수 있습니다 차라리 TypeGuard 같은 문법을 통해 타입 요소를 검사하는 방식은 어떨지 제안드립니다 https://radlohead.gitbook.io/typescript-deep-dive/type-system/typeguard ---- 추가로 any의 경우 타입스크립트 역시 자바스크립트 기반이다보니까 기존 모듈 호환성 (현실적으로 모든 npm libs 에 타입을 강제화 할 수 없음) 등등의 현실적인 문제로 타협한 결과물이 아닐까 라는 생각입니다 (절대 개발자의 귀찮음을 해소해주는 역할의 효자손은 아니라고 생각해요)

커리어리 AI 봇님의 프로필 사진

' as '와 ' any '를 사용하는 것이 TypeScript에서 좋지 않은 이유는 두 가지입니다. 1. 타입 안정성(Type Safety) 손실 TypeScript의 핵심 목표 중 하나는 타입 안정성을 제공하는 것입니다. 이를 통해 개발자가 코드를 작성할 때 오류를 미리 발견할 수 있고, 보다 명확한 코드를 작성할 수 있습니다. 그러나 ' as '와 ' any '를 사용하면 타입 추론과 타입 검사가 제대로 이루어지지 않아 타입 안정성이 손실됩니다. 이로 인해 런타임 오류가 발생할 가능성이 높아집니다. 2. 코드의 가독성 저하 ' as '와 ' any '를 사용하면 코드의 가독성이 저하됩니다. 다른 개발자들이 코드를 읽을 때, 타입이 명시되지 않아 어떤 값이 들어있는지 쉽게 이해하기 어렵습니다. 이로 인해 코드를 유지보수하는 데 어려움을 겪을 수 있습니다. 좋은 수정 방법은 다음과 같습니다: 1. 명시적인 타입 정의 가능한 한 명시적으로 타입을 정의하고 사용하세요. 이렇게 하면 코드의 가독성이 향상되고, 타입 오류를 미리 발견할 수 있습니다. 2. 타입 가드(Type Guard) 사용 타입 가드를 사용하여 런타임에 타입을 확인할 수 있습니다. 이를 통해 타입 안정성을 보장하면서 ' as '의 사용을 줄일 수 있습니다. 3. 제네릭(Generic) 사용 제네릭을 사용하면 다양한 타입을 처리할 수 있는 유연한 코드를 작성할 수 있습니다. 이를 통해 ' as '와 ' any '의 사용을 줄일 수 있습니다. 4. 인터페이스(Interface)와 타입 별칭(Type Alias) 활용 인터페이스와 타입 별칭을 활용하여 복잡한 타입 구조를 명확하게 표현할 수 있습니다. 이를 통해 코드의 가독성과 타입 안정성을 높일 수 있습니다. 위의 방법들을 적용하여 코드를 수정하면, 타입 안정성과 코드의 가독성이 향상되어 좋은 코드로 리팩토링할 수 있습니다.

커리어리 AI 봇의 답변을 평가해 주세요!

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

목록으로
키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!