Development
type과 interface를 나눈 이유가 뭘까요?
#회고
개요
1년이 넘는시간동안 러너스에 몸담아, 이제 새로운 자극과 인사이트를 얻기위해 이직준비에 힘쓰고있는 요즘이다.
감사하게도 면접을 불러주신 곳이 있어 흠씬 얻어터지고 왔다.
이미 사용하고있는 ErrorBoundary 와 Suspense 같은 기본적인 React 기술도 똑부러지게 설명하지 못하는 내모습에 실망도 많이 했지만, 배워갈게 많은 시간이었다.
그중 가장 인상깊었던 질문에 대한 나름대로의 해답을 뒤늦게나마 정리해보려 한다. 뒷북
interface 와 type 의 차이가 뭘까요?
신입 프론트엔드 개발자에게도 단골소재인 간단한 질문이지만, 이마저도 제대로 대답을 못했다.
불행중 다행으로 이론적으로 빠삭하게 준비를 못해갔지만 실무에서의 경험을 토대로 얼기설기
‘type은 파일내에 같은 이름으로 타이핑을 못하고요, interface는 확장이 됩니다.’
같은 식으로 대답했다.
기술면접 시간에서의 모범답안은
‘interface는 객체의 타입만을 설정하며, 모듈 스코프 내에서 선언적 확장(병합)이 가능합니다. type 은 객체 뿐만 아니라 원시값이나 유니온 타입을 선언할 수 있지만, 선언적 확장이 불가능합니다.’
정도일 것같다.
여기서 끝났다면 아마 블로그를 쓰지도 않았을거다.
진짜 질문은 지금부터…
왜 타입스크립트의 창시자는, 역할이 비슷한 type과 interface 를 굳이 나눠놓았을까요?
→ 혹은 당신이 타입스크립트를 만든 사람이라면, 이렇게 type과 interface를 나누게된 이유를 추론해보시겠어요?
면접은 이미 조졌끝났고, 돌아오는 길과 집에 도착해서도 열심히 찾아봤지만 그런 이유를 정리한 블로그나 아티클은 못찾았다.
회사에 가서 팀원들에게 공유했을때도, ‘이거다!’ 싶은 기발한 답변은 들을 수 없었다.
타입스크립트 공식문서와 Typescript Deep Dive 를 찾아보았지만, 다들 type과 interface의 차이와 사용법에 대해 알려줄 뿐, 그 역사와 기원을 설명해주진 않았다.
그나마 사용법을 제시해준 문서는 typescriptlang.org 였다.
Documentation - Everyday Types
The language primitives.
For the most part, you can choose based on personal preference, and TypeScript will tell you if it needs something to be the other kind of declaration. If you would like a heuristic, useinterfaceuntil you need to use features fromtype.
볼드 처리한곳을 해석해보면
typescript를 탐구적으로 학습중이라면,type의 기능이 필요해질 때 까지는interface를 사용하세요.
이렇게 interface의 우선 사용을 권장하고 있었다.
왜?
나름대로 열심히 찾아봤지만 결국 ‘왜 type과 interface를 구분했는지’ 에 대한 합당한 이론은 모르겠다.
찾으면 찾을수록, 면접때 했던 대답이 내 나름의 최고의 답변이구나 라는걸 느꼈다.
type은 선언적 확장 정도를 제외하면 객체또한 담을 수 있으니 interface를 대신할수 있지 않냐 하겠지만 깊은 인터섹션이 일어나는 타입의 경우 interface 가 성능적으로 이점이 있으며,
Performance
TypeScript is a superset of JavaScript that compiles to clean JavaScript output. - microsoft/TypeScript
복합타입(Complex Types) 의 경우도 interface로 타입추론이 될 경우 컴파일러에서 더 많은 캐싱이 이뤄진다고 한다.
Performance
TypeScript is a superset of JavaScript that compiles to clean JavaScript output. - microsoft/TypeScript
interface 는 열려있고(open), type 은 닫혀있습니다(closed).
TS Playground - An online editor for exploring TypeScript and JavaScript
The Playground lets you write TypeScript or JavaScript online in a safe and sharable way.
핸드북 playground에서 발견한 문구다.
원문은 약 51번 line 부터 있다.
참고로 맨 아래 링크돼있는 stackoverflow 스레드도 이번 주제의 궁금증을 풀어주진 않지만 타입스크립트 버전별 interface 와 type의 차이에 대해 명확히 설명해주고있어서, 둘러보기 좋다.
Interfaces vs Types in TypeScript
What is the difference between these statements (interface vs type) in TypeScript?
interface X {
 a: number
 b: string
}

type X = {
 a: number
 b: string
};
인터페이스는 열려있고 타입은 닫혀있다? 열려있고 닫혀있다?
그순간 어떤 키워드가 뇌리를 스쳤다.
SOLID - OCP (Open Closed Principle)
💠 완벽하게 이해하는 OCP (개방 폐쇄 원칙)
개방 폐쇄 원칙 - OCP (Open Closed Principle) 개방 폐쇄의 원칙(OCP)이란 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계가 되어야 한다는 원칙을 말한다. 보통 OCP를 확장에 대해서는 개방적(open)이고, 수정에 대해서는 폐쇄적(closed)이어야 한다는 의미로 정의한다. 여기서 확장이란 새로운 기능이 추가됨을 의미한다. 따라서 해석하자면, 기능 추가 요청이 오면 클래스를 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화 하도록 프로그램을 작성해야 하는 설계 기법을 말한다고 보면 된다. [ 확장에 열려있다 ] - 모듈의 확장성을 보장하는 것을 의미한다. - 새로운 변경 사항이 발생했을 때 유연하게 코드를 추가함으로써 애플리케이션의 기능을 큰 힘..
OCP는 SOLID 원칙의 O에 해당하는 개념이다.
인파님 블로그에 너무 잘 정리되어있지만, 요약하면
확장에는 열려있으나 변경에는 닫혀있다
Java, C# 등 의무적(mandatory) OOP 프로그래밍 언어를 다루는 사람이라면 못 들어본 적이 없을, 누구나 지향하는 원칙이다.
실제로 자바에는 추상화(interface)의 개념과 상속(extends)이 정말 중요하게 사용되고 있고, 타입스크립트의 interface 는 이 의무적 OOP 프로그래밍 문법을 설령 생김새만 똑같다고 해도 유사하게 사용 할 수 있다.
정확한 결론은 내릴 수 없지만, Java, C# 개발자를 위한 타입스크립트 핸드북까지 만들어주는 친절한 마이크로소프트에서 초기 설계단계에서 이런 경우들을 생각해 선택지를 제공해준게 아닐까 ?
OCP적 확장이 자유로운 interface와, 한번 정의되면 변경할 수 없도록(immutable) 설계된 type 을 모두 허용함으로써, 자바스크립트에 친숙하지 않은 프로그래머도 타입스크립트를 쉽게 사용할 수 있도록 열어둔 것 같다.
어쨌든 자바스크립트 개발자로서, 타입스크립의 기원과 역사를 찾아보겠다는 빌미로 많은 공식문서와 레퍼런스를 찾아보고, ‘나였으면 어떤 패러다임을 제시할 수 있을까’ 에 대한 깊은 고민을 해볼 수 있는 시간이었다.
그리고 면접당시 내 답변이 그리 이상하진 않았구나 라는걸 interface 를 우선 사용하라는 수많은 레퍼런스를 보고 다시 느낄 수 있었다. 뿌듯!
번외) 직접 물어봤다. type vs interface
면접때 말을 너무 못했다고 생각했는데, 감사하게도 2차면접을 불러주셔서 이번엔 내가 직접 물어봤다.
“저는 이러이러해서 이렇게 생각했는데, 면접관님의 생각이 궁금합니다!”
간과하기 쉽지만 명쾌한 답변을 들을 수 있었다.
type과 interface 두개의 다른 특징 만큼이나 예악어 자체에서 갖고있는 이름의 역할이 있기 때문에, 개념적으로 구분하는것이 맞는것같다 라는 생각이셨다.
예를 들어, 컴포넌트 타이핑이나 API의 response 타입 등을 정의할때는 주로 interface로 많이 하게 된다. interface 라는 사전적 의미인 ‘연결짓는’ 의도로 보았을때 하나의 도메인을 잇기위한 용도이기에 type 보다는 interface가 자연스럽다.
컴포넌트는 특히 그러한데, 리액트에서 사용되는 아토믹 패턴, 컴파운드 패턴 등의 여러 사례에서 작은 컴포넌트부터 큰 단위의 컴포넌트들은 모두 사용자가 보는 페이지/템플릿을 완성하기 위해 서로 촘촘하게 엮여있고, 이것을 연결짓기위한 예악어는 불변성을 보장하는 느낌의 type 보다는 interface가 적합해보인다.
이런 개념적 추론을 어렴풋이나마 알고있는지에 대한 질문이었다고 한다. 정답이 없는 논술형(?)에 가까운 고난이도 질문이라는것도 한번더 강조해주셔서 배려심에 약간은 감동..
시니어 프론트엔드 개발자의 개인적인 생각을 들을 수 있는 시간이라 좋은 경험이었다.