[2025.07.11 주간 개발 트렌드] TypeScript 5.9 Beta 정리 (import defer, node20, tsconfig)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Deno 2.4에서 뭐가 바뀌었나

JavaScript 프로젝트를 시작하려고하면 코드보다 먼저 정할게 꽤 많다. TypeScript는 어떻게 실행할지, 린터와 포매터는 뭘 쓸지, 테스트와 빌드는 어떻게 할지 골라야한다.

작은 기능 하나 만들려고했는데 설정 파일부터 늘어나는 경우도 있다.. 서비스로 운영하려면 여기에 로그와 성능 지표까지 붙여야한다.

이번주 7월 2일에 [Deno 2.4](https://deno.com/blog/v2.4)가 공개됐다. 이번주 개발트렌드로 어떤 부분이 바뀌었는지 정리해보려고 한다.

큰 변화는 deno bundle의 복귀, 내장 OpenTelemetry 안정화, Node.js 호환성과 tsconfig.json 지원 개선이다. 코드를 실행하는것부터 운영 중에 무슨 일이 생겼는지 확인하는것까지 같은 도구 안에서 다루려는 방향으로 보인다.

# 1. 우선 Deno가 묶어주는것부터 살펴보자

Deno에는 실행기와 함께 포매터, 린터, 타입 검사, 테스트 같은 도구가 들어있다. 여러 도구를 따로 설치하고 연결하는 작업을 줄일 수 있다는게 특징이다.

```text
JavaScript / TypeScript 코드
            ↓
개발·검사: fmt / lint / check / test
            ↓
빌드·실행: bundle / run
            ↓
운영 관찰: OpenTelemetry
```

예를 들어 사내에서 사용할 파일 변환 CLI를 만든다고 해보자. 기능은 작은데 실행기, 타입 검사기, 테스트 도구를 각각 고르다보면 주변 설정이 더 커질 수 있다.

이런 경우에는 같은 명령 체계 안에서 개발 과정을 정리할 수 있는게 편할것 같다. 새로 들어온 사람에게 실행 방법을 설명할때도 확인할 곳이 줄어든다.

다만 기존 프로젝트에 이미 잘 맞는 설정과 CI가 있다면 얻는 이득은 다를 수 있다. 도구가 한개로 묶였다는 이유만으로 지금 환경보다 무조건 편해지는것은 아니다.

우리 팀이 반복해서 손보는 설정이 무엇인지 먼저 보면 도입할 이유도 구체적으로 정리할 수 있다.

# 2. deno bundle이 다시 돌아왔다

번들링은 여러 모듈을 분석해서 배포하기 편한 결과물로 묶는 작업이다. 2.4의 deno bundle은 esbuild를 기반으로 하고 Deno와 브라우저용 번들을 만들 수 있다.

다만 **아직은 실험 기능**이다. 기존 빌드 환경을 바꾸려면 필요한 동작이 실제로 지원되는지 확인해야한다. [번들링 설명](https://docs.deno.com/runtime/reference/bundling/)

브라우저용 스크립트라면 다음처럼 결과물을 만들 수 있다.

```bash
deno bundle --platform browser --minify --output public/widget.js src/widget.ts
```

여기서 번들링과 최소화는 구분해서 보면 좋다. 번들링은 모듈을 묶는 일이고 최소화는 코드 표현을 줄여 파일 크기를 낮추는 일이다. 트리 셰이킹은 안전하게 제거할 수 있는 미사용 코드를 줄이는 과정이다.

그렇다고 파일 하나가 나왔으니 모든 배포 문제가 끝나는것은 아니다. 서버용 JavaScript라면 여전히 실행할 런타임이 필요하고, 브라우저용 번들이 서버 API를 사용할 수 있게 만들어주지도 않는다.

작은 위젯이나 단순한 페이지를 만들때는 검토해볼만하다. 반면 프레임워크의 라우팅, 서버 렌더링, CSS 처리까지 필요하다면 그 부분을 누가 담당하는지도 봐야한다.

결과물이 만들어지는지만 확인하지말고 실제 기능과 오류 추적까지 기존처럼 되는지 확인하는게 좋겠다.

# 3. Node.js 프로젝트를 가져오기는 쉬워졌을까

새 런타임을 검토할때 가장 걱정되는건 기존 라이브러리다. 언어가 같아도 모듈을 찾는 방식이나 전역 객체가 다르면 생각보다 손볼곳이 많아질 수 있다.

Deno 2.4는 Buffer, global, setImmediate, clearImmediate를 사용자 코드에서도 기본 제공하고 fs.glob 계열을 추가했다. DENO_COMPAT=1로 여러 호환성 옵션을 묶어 적용하는 방법도 들어왔다.

기존 Node.js 코드를 실행하기 위해 여기저기 수정해야하는 일이 줄어든다는 점에서 의미가 있다.

우선 Node.js 내장 모듈을 사용하는 서버 예제를 보자.

```javascript
// compat-server.mjs
import { createServer } from "node:http";

const server = createServer((_request, response) => {
  response.end(JSON.stringify({ status: "ok" }));
});

server.listen(8080, "127.0.0.1");
```

```bash
deno run --allow-net=127.0.0.1:8080 compat-server.mjs
```

위의 코드처럼 node: 모듈을 사용하는 방식으로 호환성을 확인해볼 수 있다. 다만 npm 패키지에 따라 네이티브 애드온이나 node_modules 구성이 필요한 경우도 있다. [Node.js 호환성 설명](https://docs.deno.com/runtime/fundamentals/node/)

**서버가 켜졌다는것만으로 전체 서비스가 호환된다고 보면 안된다.** 인증 SDK, DB 연결, 파일 업로드처럼 실제로 사용하는 흐름을 확인해야한다.

특히 일부 모듈의 호환성 수치를 전체 npm 패키지의 성공률로 읽으면 안된다. 내 프로젝트가 사용하는 API와 실행 환경에서 확인하는게 가장 정확하다.

# 4. TypeScript 실행과 타입 검사는 다르다

2.4에서는 tsconfig.json의 references, extends, files, include, exclude 처리도 개선됐다. 여러 패키지가 설정을 공유하는 프로젝트라면 확인해볼 부분이다.

기존 설정을 다시 옮겨 적는 작업이 줄어들면 런타임을 비교하기도 쉬워진다. 다만 프레임워크나 빌드 플러그인의 설정까지 전부 동일하게 처리된다고 가정해서는 안된다.

그리고 TypeScript 파일을 실행할 수 있다는것과 타입 검사를 통과했다는것은 다르다. 타입 문법을 처리해서 실행하더라도 코드에 타입 오류가 남아있을 수 있다.

```bash
deno check src/server.ts
deno lint
deno fmt --check
deno test
```

위처럼 타입 검사와 코드 규칙, 형식, 테스트를 따로 확인할 수 있다. 실행 전에 검사하려면 deno run --check를 사용할 수도 있다. [TypeScript 지원 설명](https://docs.deno.com/runtime/fundamentals/typescript/)

개발할때 빠르게 실행하는 명령과 배포 전에 확인하는 명령을 같이 정리해두면 좋겠다. 도구가 묶여있다는건 검증을 생략한다는 뜻이 아니라 같은 방식으로 반복하기 쉬워진다는 의미로 보는게 맞을것 같다.

# 5. OpenTelemetry는 왜 들어가는걸까

운영하다보면 에러가 났다는 사실보다 어디에서 왜 났는지 찾는게 더 어려울때가 있다. 로그는 많은데 같은 요청에서 나온 기록인지 구분이 안되면 분석하기가 힘들다.

OpenTelemetry에서는 로그, 메트릭, 트레이스 같은 관측 데이터를 다룬다. 간단하게 정리하면 다음과 같다. [관측 데이터 설명](https://opentelemetry.io/docs/concepts/signals/)

| 구분 | 확인하는 내용 |
| --- | --- |
| 로그 | 어떤 일이 있었는가 |
| 메트릭 | 오류나 지연이 얼마나 발생하는가 |
| 트레이스 | 한 요청이 어떤 작업을 거쳤는가 |

예를 들어 상품 조회가 느리다면 메트릭으로 지연이 늘어난 구간을 보고, 트레이스로 외부 재고 API가 오래 걸렸는지 확인하고, 관련 로그에서 오류를 찾는 식이다.

Deno 2.4에서는 내장 OpenTelemetry 지원이 안정화되어 unstable 플래그가 필요없어졌다. 다만 계측을 켜려면 OTEL_DENO=1은 여전히 설정해야한다.

```bash
OTEL_DENO=1 deno run --allow-net src/server.ts
```

위 명령은 서버 실행과 계측 활성화를 보여주는 예시다. 실제 데이터를 조회하려면 수집기나 관측 백엔드, 내보내기 설정을 함께 준비해야한다. --allow-net도 운영에서는 필요한 범위로 제한하는게 좋다.

자동 계측이 업무 흐름을 전부 이해하는것도 아니다. 할인 계산이나 캐시 우회처럼 우리 서비스에서 중요한 구간은 추가로 표시해야할 수 있다.

어떤 요청인지 연결할 수 있는지, 필요한 구간이 보이는지, 기록 비용은 어느정도인지까지 확인해야 실제로 도움이 되는지 알 수 있다.

# 6. 실제로 써본다면 어디서 시작할까

처음부터 서비스 전체를 옮기기보다는 입력과 출력이 분명한 작업 하나로 비교해보는게 좋겠다. 내부 CLI나 작은 API라면 결과를 확인하기도 쉽다.

1. 사용하는 Deno 버전을 고정한다.
2. 기존과 같은 입력에서 같은 결과가 나오는지 확인한다.
3. 패키지와 파일 접근, 환경 변수에 필요한 조건을 정리한다.
4. 정상 요청뿐 아니라 오류와 종료 처리도 확인한다.
5. 관측 기능을 켰을때 지연과 메모리 변화를 비교한다.

서버리스나 Edge에 올릴거라면 해당 플랫폼이 어떤 런타임과 API를 지원하는지도 먼저 봐야한다. 로컬에서 된다고 모든 환경에서 그대로 배포할 수 있는것은 아니다.

성능도 같은 조건에서 비교해야한다. 시작 시간, 메모리, 처리량뿐 아니라 느린 요청이 얼마나 걸리는지도 확인하면 좋겠다.

그리고 설정을 얼마나 줄였는지도 같이 기록해보자. 처리 속도에 큰 차이가 없어도 개발 환경과 CI를 유지하는 작업이 줄었다면 그 자체로 도입 이유가 될 수 있다.

# 마무리

이번 Deno 업데이트는 실행 속도 하나보다 개발부터 운영까지 연결하는 방향으로 보면 이해하기 쉬운것 같다.

번들링은 배포할 결과물을 만들고, Node.js 호환성은 기존 코드를 가져오는 부담을 줄이고, OpenTelemetry는 실행 중인 서비스를 확인하는데 도움을 준다.

그렇다고 지금 쓰는 Node.js를 당장 바꿔야한다는 의미는 아니다. 기존 라이브러리와 배포 환경, 팀의 운영 경험까지 같이 봐야한다.

개인적으로는 작은 도구부터 같은 기능을 만들어보고 설정과 운영 과정이 얼마나 달라지는지 확인해보고 싶다. 새로운 도구도 신기하지만 결국 내가 반복해서 고생하는 부분을 줄여주는지가 더 중요한것 같다..


[2025.07.04 주간 개발 트렌드] Deno 2.4, Node.js 호환성과 관측 가능성 강화

독자의 메모