Skip to content

TypeScript

화면이 커지면서 어느 컴포넌트가 어떤 데이터를 받는지, 문서 구조가 어떤 모양인지가 헷갈리기 시작하면 버그가 생기기 쉬워져요. 특히 캔버스처럼 노드와 연결이 자유롭게 얽히는 화면은 "이 값이 실제로 뭔지"를 코드만 보고 확신하기 어렵죠. TypeScript는 타입으로 도메인을 고정하는 언어입니다. JavaScript에 타입 시스템을 얹어, 코드를 실행하기 전에 잘못된 값을 미리 잡아줘요. 데이터스케쳐스에서는 프론트엔드 전체와 백엔드 일부까지 아우르는 공통 언어로 쓰입니다.

기술 하이라이트 / 핵심 개념

  • 정적 타입 — 변수·함수의 값 형태를 미리 선언해, 잘못된 조합을 컴파일 단계에서 걸러줍니다. 객체의 필드 이름을 잘못 적거나, 있을 리 없는 속성에 접근하는 실수를 코드를 돌리기 전에 알려주죠.
  • 도메인 모델 고정 — 캔버스 노드, 문서 블록 같은 데이터 구조를 타입으로 정의해 두면, 코드 전체가 그 계약을 따르게 돼요. 아래처럼 "노드는 어떤 필드를 가져야 하는지"를 한 번 정의해 두면, 그걸 쓰는 모든 곳이 같은 기준을 따릅니다.
// 캔버스 노드가 가져야 할 모양을 타입으로 고정해요.
type CanvasNode = {
  id: string;
  x: number;
  y: number;
  type: 'mindmap' | 'diagram';
  label: string;
};
  • JavaScript와 호환 — 컴파일하면 JavaScript가 되기 때문에 기존 생태계와 그대로 어울립니다. 라이브러리 교체나 리팩터링을 할 때도 JavaScript 코드 위에 점진적으로 도입할 수 있어요.
  • 편집기 지원 — 자동 완성과 리팩터링이 JavaScript보다 정확해서 대규모 코드베이스를 다루기 쉬워요. 함수 시그니처를 바꾸면 그 함수를 쓰는 모든 호출부가 한꺼번에 드러나죠.

사용 사례 / 실제 적용

  • 프론트엔드 전체 — React + Vite 캔버스와 Next.js 웹빌더 모두 TypeScript 위에서 돌아갑니다. 컴포넌트가 주고받는 props의 형태가 타입으로 고정돼 있어, 화면 조각을 조립할 때의 실수가 줄어요.
  • 백엔드 — 캔버스 API의 NestJS(TypeScript) + TypeORM, 웹빌더 문서·동기화 API의 NestJS/TypeScript도 같은 타입 언어예요. 프론트와 백엔드가 한 언어로 묶이는 것도 큰 장점이죠. 같은 도메인 타입을 앞뒤에서 공유할 수 있어요.
  • JSON Canvas — 캔버스 노드·연결을 표현하는 공개 포맷의 구조를 타입으로 잡아, 저장·렌더링 로직이 표준과 어긋나지 않게 해요. 포맷 스펙을 타입으로 옮겨 두면 그 스펙을 지키는 코드가 타입 검사만으로도 자주 걸러져요.

프론트엔드와 백엔드가 한 타입 언어로 묶이는 건 협업에서도 느껴져요. 프론트 개발자가 백엔드 API의 응답 형태를 타입으로 이미 알고 있으니, "이 필드가 뭘 뜻하는지"를 여기저기 물어볼 필요가 줄죠. E2E 검증(Playwright)과 함께, 타입이 컴파일 시점의 실수를, Playwright가 실행 시점의 동작을 각각 검증하면서 프론트엔드 품질의 양축을 이룹니다.

더 알아보기