[Typescript] 인터페이스(1)

🔍서론

인터페이스는 연관된 이름으로 객체 형태를 설명하는 방법이다.

인터페이스는 별칭으로 된 객체 타입과 여러면에서 유사하다.

하지만 일반적으로

① 읽기 쉬운 오류 메시지

② 빠른 컴파일러 성능

③ 클래스와의 더 나은 상호 운용성

3가지의 장점을 가진다.

1️⃣타입 별칭 vs 인터페이스

타입별칭

type Poet = {
    born: number;
    name: string;
};

인터페이스

interface Poet {
    born : number;
    name : string;
}

TypeScript의 할당 가능성 검사와 오류 메시지는 객체 타입 별칭에서의 경우와 거의 동일하다.

하지만 인터페이스와 타입 별칭 사이에는 4가지 주요 차이점이 있다.

✨  4가지 차이점

1️⃣ 인터페이스는 속성 증가를 위해 병합(merge)할 수 있다. 이 기능은 내장된 전역 인터페이스 또는 npm패키지와 같은 외부 코드를 사용할때 특히 유용하다.

/* node_modules/@types/express/index.d.ts 에 정의된 Request 인터페이스의 일부 */
import { Request as ExpressRequest } from 'express';

declare module 'express-serve-static-core' {
  interface Request {
    /* 기본적으로 포함된 속성들 */
    body: any;
    params: any;
    query: any;
  }
}

이 코드는 Express.js의 Request 인터페이스의 기본형태이다.

이 인터페이스에 속성을 커스텀하고 싶다면 아래와 같이 코드를 작성하고 사용한다.

import { Request as ExpressRequest } from 'express';

/* 기존의 Request 인터페이스에 새로운 속성을 추가 */
declare module 'express-serve-static-core' {
  interface Request {
    user?: {
      id: string;
      name: string;
      email: string;
    };
  }
}

/* 예시 사용 코드 */
import express from 'express';

const app = express();

app.use((req, res, next) => {
  /* req.user에 사용자 정보 저장 */
  req.user = {
    id: '123',
    name: 'Alice',
    email: 'alice@example.com',
  };
  next();
});

app.get('/', (req: ExpressRequest, res) => {
  /* req.user를 타입 안전하게 사용할 수 있음 */
  res.send(`Hello ${req.user?.name}`);
});

 

이렇게 인터페이스의 속성을 추가하고 사용하며 타입에 대한 안정성과 유지보수하기 쉬운 클린코드를 만들 수 있다.

2️⃣ 인터페이스는 클래스가 선언된 구조의 타입을 확인할 수 있지만 타입별칭은 불가능 하다.

인터페이스로 타입 확인

interface Person {
  name: string;
  age: number;
}

class Employee implements Person {
  constructor(public name: string, public age: number) {}
}

const emp: Person = new Employee('Alice', 30);
console.log(emp.name); /* 'Alice' */
console.log(emp.age);  /* 30 */

 

인터페이스는 클래스가 특정 구조(프로퍼티와 메서드)를 따라야 하는지 강제할 수 있으며, 클래스가 그 구조를 충족하면 타입 체크를 통과한다.

 

타입별칭으로 타입 확인

type PersonType = {
  name: string;
  age: number;
}

class EmployeeType {
  constructor(public name: string, public age: number) {}
}

/* 타입 별칭은 클래스를 타입으로 사용할 수는 있지만,
   타입 별칭을 클래스와 직접적으로 연결하거나 implements 할 수는 없다.*/ 
const empType: PersonType = new EmployeeType('Bob', 25);
console.log(empType.name); /* 'Bob' */
console.log(empType.age);  /* 25 */

 

타입 별칭은 클래스의 구조를 확인할 수 없으며, 단순히 구조적인 타입 정의로 사용된다.

3️⃣인터페이스에서 TypeScript 타입 검사기가 더 빨리 작동한다. 

인터페이스는 타입 별칭이 하는 것처럼 새로운 객체 리터럴의 동적인 복사 붙여넣기보다 내부적으로 더 쉽게 캐시할 수 있는 명명된 타입을 선언한다.

 

💠타입별칭이 TypeScript 컴파일러에서 동작하는 방식

type UserAlias = {
  id: number;
  name: string;
  email: string;
};

type AdminAlias = {
  id: number;
  name: string;
  email: string;
  role: string;
};

const user: UserAlias = { id: 1, name: 'Alice', email: 'alice@example.com' };
const admin: AdminAlias = { id: 2, name: 'Bob', email: 'bob@example.com', role: 'admin' };

1. 동적 복사

타입 별칭을 사용할 때, UserAlias나 AdminAlias 같은 타입 정의는 각 사용 지점에서 해당 타입의 구조를 직접적으로 사용한다. 컴파일러는 이 타입 구조를 그대로 가져와서 사용할 수밖에 없다.

이는 컴파일러가 마치 이 구조를 복사해서 사용 지점에 붙여넣는 것과 같다.

2. 중복된 정의

만약 여러 곳에서 동일한 타입 별칭을 사용한다면, 컴파일러는 이 구조를 매번 새로 해석하게 된다.

즉, AdminAlias에서 UserAlias와 유사한 구조를 정의하고 있지만, 타입 별칭은 컴파일러가 이를 캐시하거나 최적화하지 않으므로, 코드의 각 사용 지점에서 이 구조를 다시 복사해서 해석하는 것처럼 동작한다.

---

💠인터페이스가 TypeScript 컴파일러에서 동작하는 방식

인터페이스는 "명명된 타입" 이므로 컴파일러가 이를 한 번 정의하고 나면 여러 곳에서 재사용할 때 캐시하여 효율적으로 처리할 수 있다.

interface UserInterface {
  id: number;
  name: string;
  email: string;
}

interface AdminInterface extends UserInterface {
  role: string;
}

위 코드에서는 AdminInterface가 UserInterface를 확장한다.

UserInterface의 구조가 한 번 정의되고, AdminInterface에서 이를 재사용하므로, 컴파일러는 이 구조를 효율적으로 캐시하며 타입별칭때와 같이 반복적으로 해석할 필요가 없다.

4️⃣ 인터페이스는 이름 없는 객체 리터럴의 별칭이 아닌 명명된 객체로 간주되므로 여러운 특이 케이스에서 나타나는 오류 메시지의 가독성이 좋다.

/* 타입 별칭 */
type UserAlias = {
    id: number;
    name: string;
    email: string;
};

function processUserAlias(user: UserAlias) {
    /* UserAlias 타입의 객체를 처리하는 함수 */
    console.log(user);
}

/* 인터페이스 */
interface UserInterface {
    id: number;
    name: string;
    email: string;
}

function processUserInterface(user: UserInterface) {
    /* UserInterface 타입의 객체를 처리하는 함수 */
    console.log(user);
}

/* 오류 발생 시나리오 */

/* 타입 별칭을 사용하는 경우 */
processUserAlias({
    id: 1,
    name: 'Alice',
    /* 'email' 속성이 빠졌습니다. TypeScript는 오류를 발생시킵니다. */
});

/* 인터페이스를 사용하는 경우 */
processUserInterface({
    id: 1,
    name: 'Bob',
    /* 'email' 속성이 빠졌습니다. TypeScript는 오류를 발생시킵니다. */
});

타입별칭 에러메시지

Argument of type '{ id: number; name: string; }' is not assignable to parameter of type 'UserAlias'.
  Property 'email' is missing in type '{ id: number; name: string; }' but required in type 'UserAlias'.

기본적으로 오류가 발생한 객체 리터럴의 구조와 타입 별칭의 이름을 보여준다.
그러나 객체 리터럴이 복잡해지면, 오류 메시지가 더 길고 복잡해질 수 있다.

 

 

인터페이스 에러메시지

Argument of type '{ id: number; name: string; }' is not assignable to parameter of type 'UserInterface'.
  Property 'email' is missing in type '{ id: number; name: string; }' but required in type 'UserInterface'.

이 메시지는 명명된 인터페이스(UserInterface)를 참조하기 때문에, 타입 구조를 명확하게 인식할 수 있게 해준다.
이로 인해 개발자가 오류의 원인을 더 쉽게 파악할 수 있다.

 

타입 별칭의 유니언 타입과 같은 기능이 필요할때 까지는 인터페이스를 사용하는 것이 좋다.

---

2️⃣속성 타입

2️⃣ - 1. 선택적 속성

객체타입과 마찬가지로 모든 객체가 필수적으로 인터페이스 속성을 가질 필요는 없다.

그래서 TypeScript는 선택적 속성임을 나타낼 수 있는데, 선언 방식은 타입 애너테이션 : 앞에 ?를 사용헤 인터페이스의 속성이 선택적 속성임을 나타낼 수 있다.

interface Book {
    author: string;
    pages : number;
    translator?: string;
}

const Book1:Book={
    author: "Danny",
    pages: 25,
    translator: "Kim"
}
/* OK */
const Book2:Book={
    author: "Jenny",
    pages: 25,
}
/* OK */

2️⃣ - 2. 읽기 전용 속성

경우에 따라 인터페이스에 정의된 객체의 속성을 재할당하지 못하도록 차단하고 싶을때 사용한다.

readonly 키워드를 속성앞에 추가해 다른값으로 설정할 수 없음을 나타낸다.

interface Page {
    readonly text: string;
}

function read(page:Page){
    console.log(page.text);
    let pageText = page.text;
    console.log(pageText);
    /* OK */
    
    page.text += "."
    /*
        Error: Cannot assign to text because it is a read-only property.
    */
}

readonly 제한자는 타입 시스템에만 존재하며 인터페이스에서만 사용할 수 있다. 

readonly 제한자는 객체의 인터페이스를 선언할때만 사용되며 실제 객체에는 적용하지 않는다.

 

아래의 코드 예제를 보자.

interface Page {
    readonly text: string;
}

function read(page:Page){
    console.log(page.text);
    let pageText = page.text;
    console.log(pageText);
}
/* OK */
const pageIsh = {
    text:"Hello world"
}
/* OK */
pageIsh.text += "!!";
read(pageIsh);

 

 

함수 내부에서 pageIsh.text를 읽기만 하고 수정하지 않기 때문에, 함수 외부에서 pageIsh.text를 자유롭게 수정할 수 있다는 뜻이다. 

1. 함수 내부에서의 동작: read 함수는 pageIsh 객체를 받아서 그 객체의 text 속성을 콘솔에 출력한다. 함수는 text 속성을 수정하지 않고 단순히 읽기만 한다.
2. 함수 외부에서의 동작: pageIsh.text += "!!"; 코드에서 text 속성을 수정하고 있다. 이 코드가 함수 외부에서 실행되기 때문에 readonly 속성의 제약을 받지 않는다.

왜 이런 일이 가능한가?

Page 인터페이스에서는 text 속성을 readonly로 지정했지만, pageIsh 객체 자체는 Page 인터페이스의 엄격한 구현체가 아니다.

즉, pageIsh 객체의 text 속성은 readonly가 아니므로, 외부에서 자유롭게 수정할 수 있다.

함수 내부에서 text를 수정하지 않기 때문에 TypeScript는 이 객체가 Page 인터페이스와 호환된다고 판단하는 것이다.

 

readonly는 코드영역에서 객체를 의도치 않게 수정하는 것을 막는 편리한 방법이다. 그러나 readonly는 컴파일된 JavaScript코드에는 존재하지 않는다.

즉, readonly제한자는 타입 검사기를 사용해 개발중에 그 속성이 수정되지 않게 하는 역할만 수행한다.

2️⃣ - 3. 함수와 메서드

TypeScript에서도 JavaScript와 마찬가지로 인터페이스 멤버를 함수타입으로 선언할 수 있다.

방법은 2가지가 있다.

1. 메서드 구문
2. 속성 구문

interface HasBothFunctionTypes {
    property : () => string;
    method() : string;
}

const hasBoth : HasBothFunctionTypes = {
    property : () => "",
    method(){
        return "";
    }
};

hasBoth.property();  /* OK */
hasBoth.method();   /* OK */

함수속성 또한 선택적 속성을 사용할 수 있다.

interface HasBothFunctionTypes {
    property? : () => string;	/* 선택적 속성 */
    method?() : string;		/* 선택적 속성 */
}

const hasBoth : HasBothFunctionTypes = {
    property : () => "123",
    method(){
        return "";
    }
};

console.log(hasBoth.property?.());  /* OK */
hasBoth.method?.();   /* OK */

함수를 불러오는 부분

console.log(hasBoth.property?.());

을 보면 알 수 있듯이 옵셔널 체이닝을 통해 객체의 함수에 접근한 모습이다.

만약 아래와 같이 불러온다면

console.log(hasBoth.property());
/*
	Error: Cannot invoke an object which is possibly undefined
*/

에러를 일으킨다.

property를 호출할 때, TypeScript는 이 속성이 undefined일 가능성을 인지하고 경고를 발생시킨다.

따라서 property속성이 옵셔널 체이닝을 통해 값이 있을때만 호출하도록 구현하는것이 옳다. (타입가드도 옳은 방법이다)

선언 : 메서드 vs 속성 

1. 메서드는 readonly로 선언할 수 없지만 속성은 가능
2. 인터페이스 병합은 메서드와 속성을 다르게 처리

스타일 가이드

• 기본 함수가 this를 참조할 수 있다는 것을 알고 있다면 메서드 함수를 사용한다.
  • 일반적으로 클래스의 인스턴스에서 사용됨
• 반대의 경우 속성함수를 사용한다.

2️⃣ - 4. 호출 시그니처

📌호출 시그니처는 함수가 어떤 매개변수를 받고 어떤 타입의 값을 반환하는지를 정의하는 것이다.

호출 시그니처가 선언한 방식으로 호출되는 값만 인터페이스에 할당할 수 있다. 

function add(x: number, y: number): number {
    return x + y;
}

여기서의 호출 시그니처는 (x : number, y: number) => number 이다.

TypeScript에서는 이 호출 시그니처를 타입으로도 만들 수 있다. (아래의 코드)

type FunctionAlias = (input:string) => number;

type FunctionAlias = (input:string) => number;

interface CallSignature {
    (input:string) : number;
}

/* Type : (input:string) => number */
const typedFunctionAlias : FunctionAlias = (input) => input.length;
const typedCallSignature: FunctionAlias = (input:string) => input.length;

interface FunctionWithCount {
    count: number;
    () : void;
}

let hasCallCount: FunctionWithCount;

function keepsTrackOfCalls() {
    keepsTrackOfCalls.count += 1
    console.log(`I've been called ${keepsTrackOfCalls.count} times!`);
}

keepsTrackOfCalls.count = 0

hasCallCount = keepsTrackOfCalls;   /* OK */

function doesNotHaveCount() {
    console.log("No Idea");
}

hasCallCount = doesNotHaveCount()
/*Error: Type void is not assignable to type FunctionWithCount */

위의 코드를 보면 interface:FunctionWithCount에 count 속성이 존재하기 때문에 함수인 keepsTrackOfCalls는 FunctionWithCount 타입의 hasCallCount에 할당될 수 있다.

하지만 doesNotHaveCount 함수를 보면 count속성을 쓰지 않고 있기에 FunctionWithCount 타입의 hasCallCount 에 할당할 수 없다.

interface FunctionWithCount {
    count: number;
    () : void;
}

let hasCallCount: FunctionWithCount;

function keepsTrackOfCalls() {
    keepsTrackOfCalls.count += "!"
    console.log(`I've been called ${keepsTrackOfCalls.count} times!`);
}

keepsTrackOfCalls.count = ""

hasCallCount = keepsTrackOfCalls;   
/* 
    Error: Type typeof keepsTrackOfCalls is not assignable to type FunctionWithCount
    Types of property count are incompatible.
    Type string is not assignable to type number
*/

당연하게도 위의 코드처럼 count의 초기화를 " " 로 한다면 interface의 count:number에 타입이 맞지 않기 때문에 타입 에러를 일으킨다. 

2️⃣ - 5. 인덱스 시그니처

인덱스 시그니처는 인터페이스의 key:value 각각의 타입을 동적으로 정의하는 것이다.

아래의 코드를 보자.

interface TsPractice{
    [key:string] : number;
}

 

새로 선언할 객체의 모든 키는 string 타입이어야하며 value는 number타입이어야함을 명시하고 있다.

interface TsPractice{
    [key:string] : number;
}

const practice: TsPractice = {};
practice.apple = 0;     /* OK */
practice.banana = 1;    /* OK */
practice.cap = "Teket"; /* Error: Type string is not assignable to type number */

 

인덱스 시그니처는 객체에 값을 할당할때 편리하지만 타입 안정성을 완벽하게 보장하지는 않는다.

interface DatesByName {
    [i:string] : Date;
}

const publishDates : DatesByName = {
    Frankenstein : new Date("1 January 1818")
}

console.log(publishDates.Frankenstein.toString()); /* OK */
publishDates.Beloved;
console.log(publishDates.Beloved.toString()); /* OK, But Runtime Error*/

위의 코드를 보면 Beloved는 key로서 string으지만 value가 undefined다.

하지만 타입스크립트는 Beloved가 정의되지 않았음에도 정의되었다고 생각하도록 속인다.

따라서 타입시스템에선 에러가 발생하지 않는다..

 

11th row: 코드 실행하기전엔 에러가 없는것처럼 보인다.

key/value 쌍을 저장하려고 하는데 키를 미리 알 수 없다면 Map을 사용하는 편이 더 안전하다.
.get 메서드는 항상 키가 존재하지 않음을 나타내기 위해서 | undefined 타입을 반환한다.

속성과 인덱스 시그니처 혼합

인터페이스는 명명된 속성과 포괄적인 용도의 string인덱스 시그니처를 한번에 포함할 수 있다.

interface Novels {
    Oroonoko : number;
    [i:string] : number;
}

/* OK */
const novels : Novels = {
    Oroonoko : 1688,
    Outlander : 1991,
}
const missingOroonoko : Novels = {
    Outlander : 1991,
    /*
        Error: Property Oroonoko is missing in type { Outlander: number; } but required in type Novels
        index.ts(2, 5): Oroonoko is declared here.
    */
}

명명된 interface를 사용하는 객체는 반드시 해당 속성을 포함해야하기 때문에 Oroonoko를 빼먹은 위의 상황은 허용되지 않는다.

또한 명명된 속성의 타입이 인덱스 시그니처에 할당될 수 있는 경우 TypeScript는 더 구체적인 속성 타입 리터럴을 사용하는 것을 허용한다.

interface ChapterStarts {
    preface : 0;
    [i:string] : number;
}
const correctPreface :ChapterStarts = {
    preface : 0,
    night: 1,
    shopping : 3
};
const wrongPreface :ChapterStarts = {
    preface : 1
    /*
        Error: Type 1 is not assignable to type 0
    */
}

숫자 인덱스 시그니처

TypeScript에서 객체의 프로퍼티 키가 숫자일 때 해당 키와 값의 타입을 정의하는 방법이다.

숫자 인덱스 시그니처는 아래와 같이 정의된다.

interface NumberIndexedObject {
    [key: number]: string;
}

const example: NumberIndexedObject = {
    1: "One",
    2: "Two",
    100: "Hundred"
};

 

 

TypeScript에서는 숫자 인덱스 시그니처가 문자열 인덱스 시그니처의 서브타입이어야 한다는 규칙이 있다.
예를 들어, arr[0]과 arr["0"]은 같은 값을 참조한다.

/*
    OK
*/
interface MoreNarrowNumbers{
    [i:number] : string;
    [i:string] : string | undefined;
}
/*
    OK
*/
const mixesNumbersAndStrings : MoreNarrowNumbers = {
    0 : '',
    key1 : '',
    key2: undefined
}

interface MoreNarrowStrings{
    [i:number] : string | undefined;
    /*
        Error: number index type string | undefined
        is not assignable to string index type string
     */
    [i:string] : string;
}

📢 오류가 발생한 이유

interface MoreNarrowStrings {
    [i: number]: string | undefined;
    [i: string]: string;
}

여기서 문제가 되는 부분은, 숫자 인덱스 시그니처의 값 타입이 string | undefined라는 점이다.

TypeScript는 모든 숫자 인덱스 시그니처가 문자열 인덱스 시그니처로도 사용될 수 있다고 가정한다.

따라서, 이 경우 숫자 인덱스 시그니처의 값 타입은 문자열 인덱스 시그니처의 값 타입인 string의 서브타입이어야 한다.

 

그러나 string | undefined는 string의 서브타입이 아니고.

오히려 string 타입이 string | undefined의 서브타입이다. 이 때문에 오류가 발생하는것...

2️⃣ - 6. 중첩 인터페이스

인터페이스 타입도 자체 인터페이스 타입 혹은 객체 타입을 속성으로 가질 수 있다.

interface Employee {
    name: string;
    age: number;
    department: Department;
}

interface Department {
    name: string;
    roles: Role[];
}

interface Role {
    title: string;
    salary: number;
}

const employee: Employee = {
    name: "Alice",
    age: 30,
    department: {
        name: "Engineering",
        roles: [
            {
                title: "Software Engineer",
                salary: 70000
            },
            {
                title: "Team Lead",
                salary: 90000
            }
        ]
    }
};

console.log(employee);

 

---