TypeScript의 정확한 타입: 견고한 코드를 위한 엄격한 객체 모양 일치

JavaScript의 상위 집합인 TypeScript는 동적인 웹 개발 세계에 정적 타이핑을 도입합니다. TypeScript는 타입 안전성과 코드 유지 관리 측면에서 상당한 이점을 제공하지만, 구조적 타이핑 시스템은 때때로 예상치 못한 동작을 유발할 수 있습니다. 여기서 "정확한 타입"이라는 개념이 등장합니다. TypeScript에는 명시적으로 "정확한 타입"이라고 명명된 내장 기능은 없지만, TypeScript 기능과 기술의 조합을 통해 유사한 동작을 달성할 수 있습니다. 이 블로그 게시물에서는 TypeScript에서 더 엄격한 객체 모양 일치를 강제하여 코드 견고성을 개선하고 일반적인 오류를 방지하는 방법에 대해 자세히 알아보겠습니다.

TypeScript의 구조적 타이핑 이해

TypeScript는 구조적 타이핑(덕 타이핑이라고도 함)을 사용하며, 이는 타입 호환성이 선언된 이름보다는 타입의 멤버에 의해 결정된다는 것을 의미합니다. 객체가 타입에 필요한 모든 속성을 가지고 있다면, 추가 속성이 있는지 여부에 관계없이 해당 타입과 호환되는 것으로 간주됩니다.

예를 들어:

interface Point {
  x: number;
  y: number;
}

const myPoint = { x: 10, y: 20, z: 30 };

function printPoint(point: Point) {
  console.log(`X: ${point.x}, Y: ${point.y}`);
}

printPoint(myPoint); // myPoint에 'z' 속성이 있더라도 정상적으로 작동합니다.

이 시나리오에서 TypeScript는 `myPoint`에 추가 `z` 속성이 있더라도 필요한 `x` 및 `y` 속성을 포함하고 있기 때문에 `printPoint`에 `myPoint`를 전달하는 것을 허용합니다. 이 유연성이 편리할 수 있지만, 예상치 못한 속성이 있는 객체를 실수로 전달하는 경우 미묘한 버그를 유발할 수도 있습니다.

과도한 속성의 문제

구조적 타이핑의 관대함은 때때로 오류를 숨길 수 있습니다. 구성 객체를 예상하는 함수를 고려해 보세요.

interface Config {
  apiUrl: string;
  timeout: number;
}

function setup(config: Config) {
  console.log(`API URL: ${config.apiUrl}`);
  console.log(`Timeout: ${config.timeout}`);
}

const myConfig = { apiUrl: "https://api.example.com", timeout: 5000, typo: true };

setup(myConfig); // TypeScript는 여기서 불평하지 않습니다!

console.log(myConfig.typo); // true를 출력합니다. 추가 속성이 조용히 존재합니다.

이 예에서 `myConfig`에는 `typo`라는 추가 속성이 있습니다. `myConfig`가 `Config` 인터페이스를 계속 만족하기 때문에 TypeScript는 오류를 발생시키지 않습니다. 그러나 오타는 전혀 감지되지 않으며, 오타가 `typoo`를 의도했다면 애플리케이션이 예상대로 작동하지 않을 수 있습니다. 중첩된 객체를 다룰 때 이러한 사소해 보이는 문제는 사소한 버그로 커질 수 있습니다. 특히 중첩된 객체를 다룰 때 누락되거나 잘못 입력된 속성은 감지하기 어렵습니다.

TypeScript에서 정확한 타입 강제 적용 방법

TypeScript에 직접 "정확한 타입"이 제공되지는 않지만, 유사한 결과를 얻고 더 엄격한 객체 모양 일치를 강제하기 위한 몇 가지 기술이 있습니다.

1. `Omit`을 사용한 타입 단언

`Omit` 유틸리티 타입은 기존 타입에서 특정 속성을 제외하여 새 타입을 만들 수 있게 해줍니다. 타입 단언과 함께 사용하면 과도한 속성을 방지하는 데 도움이 될 수 있습니다.

interface Point {
  x: number;
  y: number;
}

const myPoint = { x: 10, y: 20, z: 30 };

// Point의 속성만 포함하는 타입 생성
const exactPoint: Point = myPoint as Omit & Point;

// 오류: 타입 '{ x: number; y: number; z: number; }'은(는) 타입 'Point'에 할당할 수 없습니다.
// 객체 리터럴은 알려진 속성만 지정할 수 있으며 'z'는 타입 'Point'에 존재하지 않습니다.

function printPoint(point: Point) {
  console.log(`X: ${point.x}, Y: ${point.y}`);
}


// 수정
const myPointCorrect = { x: 10, y: 20 };
const exactPointCorrect: Point = myPointCorrect as Omit & Point;
printPoint(exactPointCorrect);

이 접근 방식은 `myPoint`에 `Point` 인터페이스에 정의되지 않은 속성이 있는 경우 오류를 발생시킵니다.

설명: `Omit`는 `myPoint`의 타입에서 `Point`에 존재하는 모든 키를 생략한 타입을 생성합니다. 그런 다음 `& Point`는 이 타입을 `Point` 타입과 교차하여 객체가 `Point` 타입을 준수하도록 요구합니다. 객체를 이 결합된 타입으로 단언함으로써 컴파일러는 추가 속성을 확인하고 발견되면 오류를 발생시킵니다. 이를 통해 객체를 처음 정의할 때 올바른 모양을 선언해야 합니다.

2. 객체 생성을 위한 함수 사용

인터페이스에 정의된 속성만 허용하는 팩토리 함수를 만들 수 있습니다. 이 접근 방식은 객체 생성 시점에 강력한 타입 검사를 제공합니다.

interface Config {
  apiUrl: string;
  timeout: number;
}

function createConfig(config: Config): Config {
  return {
    apiUrl: config.apiUrl,
    timeout: config.timeout,
  };
}

const myConfig = createConfig({ apiUrl: "https://api.example.com", timeout: 5000 });

//컴파일되지 않습니다:
//const myConfigError = createConfig({ apiUrl: "https://api.example.com", timeout: 5000, typo: true });
// 타입 '{ apiUrl: string; timeout: number; typo: true; }'의 인수는 타입 'Config'의 매개변수에 할당할 수 없습니다.
// 객체 리터럴은 알려진 속성만 지정할 수 있으며 'typo'는 타입 'Config'에 존재하지 않습니다.

`Config` 인터페이스에 정의된 속성만으로 구성된 객체를 반환함으로써 추가 속성이 끼어들지 않도록 할 수 있습니다. 이렇게 하면 구성을 더 안전하게 생성할 수 있습니다.

3. 타입 가드 사용

타입 가드는 특정 범위 내에서 변수의 타입을 좁히는 함수입니다. 직접적으로 과도한 속성을 방지하지는 않지만, 명시적으로 확인하고 적절한 조치를 취하는 데 도움이 될 수 있습니다.

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

function isUser(obj: any): obj is User {
  return (
    typeof obj === 'object' &&
    obj !== null &&
    'id' in obj && typeof obj.id === 'number' &&
    'name' in obj && typeof obj.name === 'string' &&
    Object.keys(obj).length === 2 // 키 개수 확인. 참고: 취약하며 User의 정확한 키 개수에 따라 달라집니다.
  );
}

const potentialUser1 = { id: 123, name: "Alice" };
const potentialUser2 = { id: 456, name: "Bob", extra: true };

if (isUser(potentialUser1)) {
  console.log("유효한 사용자:", potentialUser1.name);
} else {
  console.log("유효하지 않은 사용자");
}

if (isUser(potentialUser2)) {
  console.log("유효한 사용자:", potentialUser2.name); // 여기에 도달하지 않습니다.
} else {
  console.log("유효하지 않은 사용자");
}

이 예에서 `isUser` 타입 가드는 필수 속성의 존재뿐만 아니라 해당 타입 및 속성의 *정확한* 개수도 확인합니다. 이 접근 방식은 더 명시적이며 유효하지 않은 객체를 적절하게 처리할 수 있습니다. 그러나 속성 개수 확인은 취약합니다. `User`에 속성이 추가/삭제될 때마다 확인을 업데이트해야 합니다.

4. `Readonly` 및 `as const` 활용

`Readonly`는 기존 속성의 수정을 방지하고, `as const`는 모든 속성이 깊이 읽기 전용이며 리터럴 타입을 갖는 읽기 전용 튜플 또는 객체를 생성하는 반면, 다른 방법과 결합하여 더 엄격한 정의 및 타입 검사를 만드는 데 사용할 수 있습니다. 하지만 둘 중 어느 것도 단독으로는 과도한 속성을 방지하지 못합니다.

interface Options {
  width: number;
  height: number;
}

// Readonly 타입 생성
type ReadonlyOptions = Readonly;

const options: ReadonlyOptions = { width: 100, height: 200 };

//options.width = 300; // 오류: 읽기 전용 속성이므로 'width'에 할당할 수 없습니다.

// as const 사용
const config = { api_url: "https://example.com", timeout: 3000 } as const;

//config.timeout = 5000; // 오류: 읽기 전용 속성이므로 'timeout'에 할당할 수 없습니다.

//하지만 과도한 속성은 여전히 허용됩니다:
const invalidOptions: ReadonlyOptions = { width: 100, height: 200, depth: 300 }; //오류 없음. 여전히 과도한 속성을 허용합니다.


interface StrictOptions {
  readonly width: number;
  readonly height: number;
}

//이제 오류가 발생합니다:
//const invalidStrictOptions: StrictOptions = { width: 100, height: 200, depth: 300 };
// 타입 '{ width: number; height: number; depth: number; }'은(는) 타입 'StrictOptions'에 할당할 수 없습니다.
//  객체 리터럴은 알려진 속성만 지정할 수 있으며 'depth'는 타입 'StrictOptions'에 존재하지 않습니다.

이는 불변성을 향상시키지만, 변성을 방지할 뿐 추가 속성의 존재를 방지하지는 않습니다. `Omit` 또는 함수 접근 방식과 결합하면 더 효과적입니다.

5. 라이브러리 사용 (예: Zod, io-ts)

Zod 및 io-ts와 같은 라이브러리는 강력한 런타임 타입 검증 및 스키마 정의 기능을 제공합니다. 이러한 라이브러리를 사용하면 과도한 속성을 방지하는 것을 포함하여 데이터의 예상 모양을 정확하게 설명하는 스키마를 정의할 수 있습니다. 런타임 종속성을 추가하지만 매우 견고하고 유연한 솔루션을 제공합니다.

Zod 예시:

import { z } from 'zod';

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
});

type User = z.infer;

const validUser = { id: 1, name: "John" };
const invalidUser = { id: 2, name: "Jane", extra: true };

const parsedValidUser = UserSchema.parse(validUser);
console.log("파싱된 유효한 사용자:", parsedValidUser);

try {
  const parsedInvalidUser = UserSchema.parse(invalidUser);
  console.log("파싱된 유효하지 않은 사용자:", parsedInvalidUser); // 여기에 도달하지 않습니다.
} catch (error) {
  console.error("유효성 검사 오류:", error.errors);
}

Zod의 `parse` 메서드는 입력이 스키마를 준수하지 않으면 오류를 발생시켜 효과적으로 과도한 속성을 방지합니다. 이는 런타임 유효성을 제공하고 스키마에서 TypeScript 타입을 생성하여 타입 정의와 런타임 유효성 검사 로직 간의 일관성을 보장합니다.

정확한 타입 강제를 위한 모범 사례

TypeScript에서 더 엄격한 객체 모양 일치를 강제할 때 고려할 몇 가지 모범 사례는 다음과 같습니다.

• 올바른 기술 선택: 최상의 접근 방식은 특정 요구 사항과 프로젝트 요구 사항에 따라 달라집니다. 간단한 경우에는 `Omit` 또는 팩토리 함수를 사용한 타입 단언으로 충분할 수 있습니다. 더 복잡한 시나리오 또는 런타임 유효성 검사가 필요한 경우 Zod 또는 io-ts와 같은 라이브러리를 사용하는 것을 고려하십시오.
• 일관성 유지: 선택한 접근 방식을 코드베이스 전체에 일관되게 적용하여 통일된 수준의 타입 안전성을 유지하십시오.
• 타입 문서화: 예상되는 데이터 모양을 다른 개발자에게 전달하기 위해 인터페이스와 타입을 명확하게 문서화하십시오.
• 코드 테스트: 타입 제약 조건이 예상대로 작동하고 코드가 유효하지 않은 데이터를 적절하게 처리하는지 확인하는 단위 테스트를 작성하십시오.
• 절충점 고려: 더 엄격한 객체 모양 일치를 강제하면 코드의 견고성이 향상될 수 있지만 개발 시간이 늘어날 수도 있습니다. 이점과 비용을 비교하고 프로젝트에 가장 적합한 접근 방식을 선택하십시오.
• 점진적 채택: 대규모 기존 코드베이스에서 작업하는 경우 가장 중요한 부분부터 시작하여 이러한 기술을 점진적으로 채택하는 것을 고려하십시오.
• 객체 모양 정의 시 타입 별칭보다 인터페이스 선호: 인터페이스는 선언 병합을 지원하므로 일반적으로 다른 파일에서 타입을 확장하는 데 유용하기 때문에 선호됩니다.

실제 사례

정확한 타입이 유용할 수 있는 실제 시나리오를 살펴보겠습니다.

• API 요청 페이로드: API로 데이터를 보낼 때 페이로드가 예상 스키마를 준수하도록 하는 것이 중요합니다. 정확한 타입을 강제하면 예상치 못한 속성을 보내서 발생하는 오류를 방지할 수 있습니다. 예를 들어, 많은 결제 처리 API는 예상치 못한 데이터에 매우 민감합니다.
• 구성 파일: 구성 파일에는 종종 많은 속성이 포함되며 오타가 발생하기 쉽습니다. 정확한 타입을 사용하면 이러한 오타를 조기에 감지하는 데 도움이 될 수 있습니다. 클라우드 배포에서 서버 위치를 설정하는 경우 위치 설정의 오타 (예: eu-west-1 대 eu-wet-1)는 사전에 감지되지 않으면 디버깅하기가 매우 어려워집니다.
• 데이터 변환 파이프라인: 한 형식에서 다른 형식으로 데이터를 변환할 때 출력 데이터가 예상 스키마를 준수하도록 하는 것이 중요합니다.
• 메시지 큐: 메시지 큐를 통해 메시지를 보낼 때 메시지 페이로드가 유효하고 올바른 속성을 포함하도록 하는 것이 중요합니다.

예: 국제화 (i18n) 구성

다국어 애플리케이션의 번역을 관리한다고 상상해 보세요. 다음과 같은 구성 객체가 있을 수 있습니다.

interface Translation {
  greeting: string;
  farewell: string;
}

interface I18nConfig {
  locale: string;
  translations: Translation;
}

const englishConfig: I18nConfig = {
  locale: "en-US",
  translations: {
    greeting: "Hello",
    farewell: "Goodbye"
  }
};


// 과도한 속성이 존재하여 조용히 버그를 도입하므로 문제가 됩니다.
const spanishConfig: I18nConfig = {
  locale: "es-ES",
  translations: {
    greeting: "Hola",
    farewell: "Adiós",
    typo: "unintentional translation"
  }
};

// 솔루션: Omit 사용
const spanishConfigCorrect: I18nConfig = {
  locale: "es-ES",
  translations: {
    greeting: "Hola",
    farewell: "Adiós"
  } as Omit & Translation
};

정확한 타입이 없으면 번역 키의 오타 (예: `typo` 필드 추가)는 눈치채지 못하고 사용자 인터페이스에서 번역 누락을 유발할 수 있습니다. 더 엄격한 객체 모양 일치를 강제함으로써 이러한 오류를 개발 중에 감지하고 프로덕션에 도달하는 것을 방지할 수 있습니다.

결론

TypeScript에는 내장 "정확한 타입"이 없지만, `Omit`을 사용한 타입 단언, 팩토리 함수, 타입 가드, `Readonly`, `as const` 및 Zod 및 io-ts와 같은 외부 라이브러리와 같은 TypeScript 기능과 기술을 조합하여 유사한 결과를 얻을 수 있습니다. 더 엄격한 객체 모양 일치를 강제함으로써 코드의 견고성을 개선하고 일반적인 오류를 방지하며 애플리케이션을 더 안정적으로 만들 수 있습니다. 요구 사항에 가장 적합한 접근 방식을 선택하고 코드베이스 전체에 일관되게 적용하는 것을 잊지 마십시오. 이러한 접근 방식을 신중하게 고려하면 애플리케이션의 타입에 대한 더 큰 제어를 얻고 장기적인 유지 관리성을 높일 수 있습니다.