백엔드와 프론트엔드가 같은 API를 각자의 타입으로 중복 정의하던 문제를 공통 IDL로 통일한 과정입니다. interface.ts와 models.ts 작성 규칙, 주석 컨벤션, 프로젝트 관리 방식을 예제와 함께 정리했습니다. || 시작하게 된 계기
안녕하세요, 똑닥에서 Frontend 개발을 하고 있는 이태홍입니다.
똑닥에는 javascript를 사용할 때 typescript를 사용하고 있습니다.
하지만 각각 별도로 작업을 하다 보니 서로 각자에게 맞는 타입을 작성해서 사용하고 있었습니다.
그래서 왜? 굳이? 라는 생각을 하게 됩니다.
그래서 한번 하나로 통일해서 써볼 수 있게 해볼까? 라는 생각으로 시작하게 됩니다.
Backend , Frontend 공통 IDL 적용해 보자!
기존 문제점
우리는 회사를 입사하기전 회사에 진행 방식에 대해서 여러가지 이상적인 상상을 하게 됩니다.
가령 아래와 같이? 
기획에 맞추어 (디자인팀,기술팀) 일사불란하게 병렬적으로 움직이는 모습~! 
하지만 회사에 입사해 현실을 마주하면 좌절하게 될지도...?
이러한 상황속 반복적인 작업을 줄이고 일에 효율성을 높이는 일은 필수적이라고 봤습니다.
앞서 언급드리렸던 것처럼 Backend와 Frontend는 같은 api 속 다른 type을 바라보고 있는 단점이 있었습니다.
이러한 문제는 설계가 공통 type을 정의하는데에 중복적인 type을 반복적으로 선언하고, 비슷한 type들이 지속적으로 늘어나고, 미친듯한 파편화가 발생될 우려 등 여러 문제점을 야기할 수 있습니다.
또한 Frontend에서 선제적으로 작업을 진행하게 될때 예상되는 type으로 response가 내려오지 않았을때 설계해놓은 로직을 재설계 하고 컴포넌트의 분리를 처음부터 다시 시작해야하는 상황이 발생될 여지가 있습니다.
그렇기에 공통적으로 운영하는 type은 우리의 작업을 많은 부분에서 간소화 시킬 수 있었습니다.
IDL 이란?
IDL 
?
이름 모를 축약어처럼 생긴 녀석은 뭘 뜻하는 걸까? 
MDN 정의
인터페이스 정의 언어(Interface Description Language, IDL) 는 특정 프로그래밍 언어와 별도로 지정된 객체의 인터페이스에 사용되는 일반 언어입니다.
이와 같이 특정 객체에 대한 정의를 할 때 사용되는 것이라고 알 수 있습니다.
IDL 의 장점
언어 중립성: IDL은 어느 한 언어에 국한되지 않기 때문에, 다양한 프로그래밍 언어로 작성된 컴포넌트 사이의 통신을 가능하게 합니다.
플랫폼 중립성: IDL은 플랫폼에 의존하지 않기 때문에, 다양한 운영 체제에서 실행되는 컴포넌트 사이의 통신을 가능하게 합니다.
코드 재사용성: IDL은 인터페이스를 명확하게 정의하기 때문에, 코드 재사용성을 높일 수 있습니다.
개발 효율성: IDL은 인터페이스 정의를 자동화하여 개발 효율성을 높일 수 있습니다.
다른 곳들은 어떻게 정의하고 있을까? 
여러 사례를 찾아보다 마음에 들었던 사례를 찾아보게 됬습니다.
그건 바로 강남언니의 기술 블로그 사례 였습니다.
첫 내용부터 강렬한 단어가 꽃히더라고요
프론트엔드 주도로 인터페이스를 설계한다
바로 이 글을 보자마자 이거다! 라고 생각하고 읽었던거 같습니다. (정말 단순해...🫠)
자세히 읽어보니 강남언니는 Google Protocol buffers를 도입한것으로 보였습니다.
선택한 이유는 다음과 같았습니다.
다양한 언어로 Generate 할 수 있습니다
무엇보다 인터페이스 작성이 매우 쉽습니다.
여기서 우리의 환경을 생각했을 때
1번 의 경우 같은 typescript를 사용했기에 굳이?
2번 의 경우 쉽다는 가정은 러닝커브를 넘어서 익숙해 졌을때의 얘기가 아닌가 생각했습니다.
그래서 간단하게 별도의 프로젝트로 만들어 type 만 정의하는 ts 파일을 만드는것으로 시작하기로 마음 먹었습니다.
이 부분에 대해 백엔드와 협의가 필요했기에 설득 하는 시간이 필요했고, 마감 회의때 발의하여 안건을 올렸고
이후 협의를 진행하는 회의
기획에 맞추어 (디자인팀,기술팀) 일사불란하게 병렬적으로 움직이는 모습~!
하지만 회사에 입사해 현실을 마주하면 좌절하게 될지도...?
이러한 상황속 반복적인 작업을 줄이고 일에 효율성을 높이는 일은 필수적이라고 봤습니다.
앞서 언급드리렸던 것처럼 Backend와 Frontend는 같은 api 속 다른 type을 바라보고 있는 단점이 있었습니다.
이러한 문제는 설계가 공통 type을 정의하는데에 중복적인 type을 반복적으로 선언하고, 비슷한 type들이 지속적으로 늘어나고, 미친듯한 파편화가 발생될 우려 등 여러 문제점을 야기할 수 있습니다.
또한 Frontend에서 선제적으로 작업을 진행하게 될때 예상되는 type으로 response가 내려오지 않았을때 설계해놓은 로직을 재설계 하고 컴포넌트의 분리를 처음부터 다시 시작해야하는 상황이 발생될 여지가 있습니다.
그렇기에 공통적으로 운영하는 type은 우리의 작업을 많은 부분에서 간소화 시킬 수 있었습니다.
IDL 이란?
IDL ?
이름 모를 축약어처럼 생긴 녀석은 뭘 뜻하는 걸까?
MDN 정의
인터페이스 정의 언어(Interface Description Language, IDL) 는 특정 프로그래밍 언어와 별도로 지정된 객체의 인터페이스에 사용되는 일반 언어입니다.
이와 같이 특정 객체에 대한 정의를 할 때 사용되는 것이라고 알 수 있습니다.
IDL 의 장점
언어 중립성: IDL은 어느 한 언어에 국한되지 않기 때문에, 다양한 프로그래밍 언어로 작성된 컴포넌트 사이의 통신을 가능하게 합니다.
플랫폼 중립성: IDL은 플랫폼에 의존하지 않기 때문에, 다양한 운영 체제에서 실행되는 컴포넌트 사이의 통신을 가능하게 합니다.
코드 재사용성: IDL은 인터페이스를 명확하게 정의하기 때문에, 코드 재사용성을 높일 수 있습니다.
개발 효율성: IDL은 인터페이스 정의를 자동화하여 개발 효율성을 높일 수 있습니다.
다른 곳들은 어떻게 정의하고 있을까?
여러 사례를 찾아보다 마음에 들었던 사례를 찾아보게 됬습니다.
그건 바로 강남언니의 기술 블로그 사례 였습니다.
첫 내용부터 강렬한 단어가 꽃히더라고요
프론트엔드 주도로 인터페이스를 설계한다
바로 이 글을 보자마자 이거다! 라고 생각하고 읽었던거 같습니다. (정말 단순해...🫠)
자세히 읽어보니 강남언니는 Google Protocol buffers를 도입한것으로 보였습니다.
선택한 이유는 다음과 같았습니다.
다양한 언어로 Generate 할 수 있습니다
무엇보다 인터페이스 작성이 매우 쉽습니다.
여기서 우리의 환경을 생각했을 때
1번 의 경우 같은 typescript를 사용했기에 굳이?
2번 의 경우 쉽다는 가정은 러닝커브를 넘어서 익숙해 졌을때의 얘기가 아닌가 생각했습니다.
그래서 간단하게 별도의 프로젝트로 만들어 type 만 정의하는 ts 파일을 만드는것으로 시작하기로 마음 먹었습니다.
이 부분에 대해 백엔드와 협의가 필요했기에 설득 하는 시간이 필요했고, 마감 회의때 발의하여 안건을 올렸고
이후 협의를 진행하는 회의