TypeScript

타입이 런타임 오류를 막지 못한다면, 타입 시스템은 절반짜리다 우리 TypeScript 개발자들은 종종 착각에 빠집니다. "타입을 붙였으니 안전하다"는 믿음입니다. 그러나 string 타입의 userId 와 string 타입의 orderId 는 TypeScript 컴파일러 눈에 동일하게 보입니다. 우리

TypeScript 고급 타입 시스템: 더 안전하고 우아한 코드를 향하여 JavaScript의 자유로움에 타입 안정성을 결합한 TypeScript(타입스크립트) 는 이제 현대 프론트엔드 및 백엔드 웹 개발 환경에서 선택이 아닌 필수가 되었습니다. 단순한 타입을 선언하고 interface 를 작성하는 수준

\n\nTypeScript를 사용하다 보면 비슷하지만 조금씩 다른 타입들을 매번 새로 정의해야 하는 상황을 마주합니다. API 응답에는 id 가 필수지만, 데이터를 생성하는 요청 폼(Form)에서는 id 가 없어야 한다거나, 특정 상태 값 중 일부만 수정하고 싶을 때 말이죠. 이때마다 interface

TypeScript는 JavaScript에 정적 타입을 더한 언어입니다. 하지만 단순히 변수에 타입을 붙이는 것을 넘어, TypeScript의 강력한 타입 시스템을 활용하면 버그를 컴파일 타임에 잡고, 더 안전하고 유지보수하기 쉬운 코드를 작성할 수 있습니다. 이 글에서는 실무에서 유용한 TypeScri

소프트웨어 개발에는 수십 년간 검증된 지혜가 담긴 설계 원칙이 있습니다. 1994년 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — 흔히 "Gang of Four (GoF)"로 불리는 네 명의 저자가 23가지 디자인 패턴을 체계화한 이후, 이 패턴

에러 처리는 실패를 숨기지 않는 설계다 애플리케이션은 항상 실패합니다. 네트워크는 끊기고, 외부 API는 timeout이 나고, 사용자는 잘못된 값을 보내고, 데이터베이스 제약 조건은 요청을 거부합니다. 문제는 실패 자체가 아니라 실패를 어떻게 표현하고 전달하느냐입니다. 모든 오류를 Error 객체 하나