# 2024년 회고

---

## Table of Contents

- [일상](#일상)
    - [독립!](#독립)
    - [운동](#운동)
    - [여행](#여행)
- [업무](#업무)
- [사이드 프로젝트](#사이드-프로젝트)
    - [글또](#글또)
    - [앱 제작](#앱-제작)
- [25년에는..](#25년에는)


시간이 정말 빠르다. 벌써 24년이 끝나고 25년이라니.
기록의 중요성을 알게 되면서 24년에 있던일들을 정리해 두려 한다. 미래의 나에게 도움이 되면 좋겠다.

## 일상

### 독립!
23년 말에 독립을 하게 되면서 24년부터 본격적으로 독립을 하게 되었다.
집을 P처럼 알아보고 P처럼 계약했다.
다행히도 집은 깔끔 했지만..? 바선생 이슈가 많았고.. 결국 세스코 선생님의 도움을 받아 지금은 안전한 집이 되었다.

독립 전에는 출퇴근 시간이 왕복 세시간 이였는데 현재는 걸어서 15분 거리로 회사에 출근하다 보니 확실히 삶의 질이 달라졌다. 출근전 시간과 퇴근 후 시간을 활용할 수 있다는게 정말 삶의 질이 달라진다.. 서울 집값 비싼 이유가 있다.

### 운동
출퇴근 시간의 여유가 생기니 더 발전적인 삶을 살고 싶었다. 그리고 해가 갈 수록 건강이 안 좋아졌다ㅠㅠ 기존에 체력적으로 많이 안 좋아서, 주말에 하루는 꼭 두통에 시달렸다. 소중한 주말을 통째로 날리고 퇴근 후에도 하고 싶은걸 제대로 못 하게 되서 운동을 시작했다.

하지만 아직은 운동이 즐겁지만은 않다. 운동 하시는 분들을 보면 정말 행복하게 하시는데(맛있다고들 하죠..) 나는 아직 괴롭게 운동한다. 그래도 확실하게 느끼는건 두통이 굉장히 많이 줄었고, 식욕이 생겼다. 원래는 입맛도 없어서 잘 안 챙겨 먹었는데 운동을 하면서 점점 늘어가는것 같다.

### 여행
올해는 정말 오랜만에 여행도 다녀왔다. 그 동안은 마음의 여유도 없고 냥이도 걱정되어서 여행을 못 갔었었는데 좋은 기회가 있어서 큰맘 먹고 갔다 왔다. 도쿄에 다녀왔는데 그중 가마쿠라가 굉장히 좋았다. 여행이 이렇게 좋았던건지 잊고 있었다. 1년에 한번씩은 가야겠다고 생각했다. 

올해는 후쿠오카나 대만에 다녀오려 한다. 둘 중 어디라도 기대된다.

## 업무
업무적으로는 여러가지 시도와 여러 시행착오를 겪으면서 한 해를 보냈다.
서비스가 늘어나게 되면서 역할과 책임이 늘어났는데, 프로젝트를 처음으로 주도하면서 하다보니 시행착오가 많았다. 그 과정에서 내부적으로 많이 소통하려 노력했고 결국엔 이성적이지만 솔직한 대화로 소통하는것이 가장 중요한것 같다는 생각이 들었다.

내 이야기를 들어주려는 상대방의 태도도 중요하다는걸 알았다. 결국엔 서로 서비스가 잘 되길 바란다는 목적이 같기 때문에 서로의 최종 목표는 같기 때문이다. 과정은 다를 수 있지만 그 과정을 소통으로 잘 맞춰가는게 중요한것 같다. 이래서 최고의 복지는 동료라는 말이 이해가 갔다.

회사 내부에서 올해는 서비스를 더 크게 확장할 준비를 하고 있는데 걱정되면서도 기대가 된다. 한편으로는 웹이나 앱 중심의 서비스는 결국 아니기 때문에 내가 이 회사에서 더 할수 있는것들이 많을지는 모르겠지만 그래도 최선을 다해보고 싶다. 서비스가 잘 되길 바라기 때문이다.


## 사이드 프로젝트

### 글또
업무적으로 할 수 있는 것과 없는것을 알게 되면서 나의 성장에 대한 고민이 생겼다. 회사 생활 만으로도 성장할 수 있다면 가장 좋겠지만, 현실은 그러기가 쉽지 않았다. 현재 회사 특성 상 같은 직무의 사람들과 많이 이야기하거나 논의할 수 없다보니 다른 사람들은 어떤식으로 일 하고 있는지 궁금했다. 때문에 글또를 시작하면서 새로운 동기부여와 자극을 받고 싶었다.

아직 진행중이지만 2주에 한번 글 쓰기는 생각보다 바쁘게 살아야 가능하다는걸 알았다. 다들 어쩜 그렇게 부지런히 생활하는지 존경스럽다. 그 와중에 각각의 소모임 활동을 하면서 멋지게 사는 사람들을 보고 진짜 자극을 많이 받았다. 그리고 쓰면 쓸수록 글 쓰기는 정말 어려운것 같다. 다른 사람의 글들도 꾸준한 노력끝에 얻은 결과겠지만 그래도 부럽다. 언젠간 나도 멋진 글을 쓰기 위해 꾸준함을 잃지 않아야겠다. 

다양한 소모임들과 커피챗들에 많이 참여하고 싶었지만 생각보다 그러지는 못했다. 앞으로 그래도 절반이나 남았으니! 아직 기회가 많다.

### 앱 제작
좋은 기회가 생겨서 사이드 프로젝트로 앱 제작을 시작하게 되었다. 연말에 시작하게 되었지만 개발만 하면 되는 단계에서 합류하게 되어서 진행을 하고 있다.
프로젝트의 세팅부터 앱 제작을 하게 되는건 처음이라 아주아주 많은 시행착오를 겪으면서 진행하고 있다. 때문에 개발 속도가 예상보단 느린것 같아서 마음이 초조하다. 하지만 기간은 정해져있고 기간내에는 작업을 할 수 있을것 같다. 올해 초에 런칭을 목표로 하고 있는데 서비스가 성공했으면 좋겠다.

expo + RN 조합으로 서비스를 제작하고 있다. expo는 최근 RN에서 많이 밀어줘서 선택하게 되었는데 사용하면서 느낀점을 틈틈히 기록해두려 한다.

## 25년에는..
작년에 있었던 일들을 돌아보니 그래도 꽤 많은 것들을 시도한것 같아서 나름 뿌듯한것 같다. 하지만 하루하루는 그렇게 생각하지 못했었는데 지나고보니 희극이였나 싶기도 하다. 결국 글또에서 말하는것 처럼 꾸준함이 나를 바꾸는것 같다. 꾸준하게 내가 세운 목표들을 이루기 위해 노력하면서 과정을 조금 더 즐기는 태도를 가져야겠다.

2024년 회고

# 모듈 시스템 비교하기(2편) - ESM이란

---

## Table of Contents

- [ESM(ECMAScript Modules) 의 등장](#esmecmascript-modules-의-등장)
  - [1. 브라우저 네이티브 지원](#1-브라우저-네이티브-지원)
  - [2. 정적 분석 가능](#2-정적-분석-가능)
  - [3. 모듈 캐싱](#3-모듈-캐싱)
- [ESM의 현재](#esm의-현재)


지난번에 cjs의 등장 배경과 히스토리들을 간단하게 살펴보았다. 그렇다면 ESM의 등장 배경에 대해서도 알아보자.

## ESM(ECMAScript Modules) 의 등장
node.js, npm으로 인해 자바스크립트 생태계가 확장 되었지만 브라우저에 최적화 되지 않은 CommonJS 모듈 시스템의 한계로 인해 자바스크립트 생태계는 호환성 문제를 겪기 시작했다. 
자바스크립트의 호환성 문제와 CommonJS의 한계를 극복하기 위해서 ECMAScript 표준 위원회(TC39)가 새로운 모듈 시스템을 제안했는데 그게 바로 ESM이다.
ES6/ES2015 에서 공식적으로 도입 되었으며 다음과 같은 특징을 가지고 있다.

### 1. 브라우저 네이티브 지원
ESM은 최신 브라우저(크롬 등)에서 기본적으로 지원된다. 이를 통해 번들링 없이도 모듈을 로드할 수 있어 간단한 프로젝트에서 빌드 도구 없이 직접 모듈을 사용할 수 있다. 아래 코드는 직접 브라우저에 바로 실행되며 greet.js가 동적으로 실행된다. script 태그에 `type="module"` 로 손쉽게 설정이 가능하다.

```html

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>ESM in Browser</title>
</head>
<body>
  <script type="module">
    import { greet } from './greet.js';
    console.log(greet('World'));
  </script>
</body>
</html>

```

```js
export function greet(name) {
  return `Hello, ${name}`;
}
```

### 2. 정적 분석 가능
ESM은 `import`와 `export`가 정적으로 정의되므로, 빌드 도구(Webpack, Rollup 등)는 의존성을 분석해 사용되지 않는 코드를 제거(Tree Shaking)할 수 있다. 아래 예시에서 빌드 도구는 `subtract`와 `multiply`가 사용되지 않음을 감지하여 최종 번들에서 제거한다.

```js
// math.js
export const add = (a, b) => a + b;
export const subtract = (a, b) => a - b;
export const multiply = (a, b) => a * b;

// main.js
import { add } from './math.js';

console.log(add(2, 3)); // 5

```

### 3. 모듈 캐싱
ESM은 한 번 로드된 모듈을 동일한 페이지 내에서 재사용(캐싱)한다. 동일한 모듈을 여러 번 가져와도 실제 네트워크 요청은 한 번만 발생한다.

```js
// logger.js
export function logMessage(message) {
  console.log(`Log: ${message}`);
  return Date.now();
}

// main.js
import { logMessage } from './logger.js';

const timestamp1 = logMessage('First Message');
const timestamp2 = logMessage('Second Message');

console.log(timestamp1 === timestamp2); // true, 동일한 인스턴스 사용

```

## ESM의 현재
현재 ESM 시스템은 서버 사이드 환경에서도 지원이 확장 되었으며 Node.js에서는 12버전부터 ESM을 실험적으로 지원하였고, 14버전 이후로는 안정적인 지원이 이루어졌다. 이러한 변화는 서버 사이드에서의 모듈 시스템 통합을 가능하게 하여, 브라우저와 서버 코드에서 동일한 모듈 시스템을 사용할 수 있게 되었다.

ESM의 도입은 자바스크립트 생태계에 큰 변화를 가져왔다. 브라우저와 서버에서 동일한 모듈 시스템을 사용함으로써 개발자 경험이 향상되었고, 코드의 이식성과 유지보수가 더 쉬워졌다. 특히, 다양한 빌드 도구와 패키지 관리 시스템이 ESM을 기본적으로 지원하게 되면서 현대적인 자바스크립트 프로젝트의 표준으로 자리 잡았다.

그러나 ESM의 도입 초기에는 호환성 문제가 있었다. 예를 들어, 기존 CommonJS 모듈과의 상호작용에서 어려움이 발생하거나, 초기 버전의 Node.js 환경에서 `import`와 `export`를 사용하는 데 제약이 있었다. 이러한 문제를 해결하기 위해 Node.js는 ESM 지원을 강화하면서도 CommonJS와의 공존 방안을 제공하고 있으며, 현재는 `type: "module"`과 같은 설정을 통해 두 모듈 시스템을 함께 사용할 수 있다.

또한, ESM은 기본적으로 비동기적 로드를 수행하므로, 파일 시스템 접근과 같은 동기적 모듈 로드 방식에 익숙했던 개발자들에게는 새로운 패턴을 학습해야 하는 부담을 주기도 했다. 이를 보완하기 위해 Node.js는 `import.meta`와 `Dynamic Import`와 같은 새로운 기능을 도입하여 더 유연한 방식으로 모듈을 사용할 수 있도록 했다.

결론적으로, ESM은 자바스크립트의 모듈 관리에 있어 더 강력하고 현대적인 대안을 제공하며, 현재와 미래의 웹 개발 환경에서 핵심적인 역할을 하고 있다. 앞으로도 ESM은 꾸준히 발전하며 더 많은 생태계 전반에서 주요 모듈 시스템으로 자리 잡을 것으로 보인다.

모듈 시스템 비교하기(2편) - ESM

# 모듈 시스템 비교하기(1편): CJS는 어떻게 등장하고 표준이 되었던걸까?

---

## Table of Contents

- [모둘 시스템의 등장 배경](#모듈-시스템의-등장-배경)
- [CommonJS의 등장](#commonjs의-등장)
- [Node.js의 등장](#nodejs의-등장)
- [npm의 등장](#npm의-등장)
- [CommonJS의 한계](#commonjs의-한계)
  - [동기적 모듈 로딩](#1-동기적-모듈-로딩)
  - [정적 분석 불가능](#2-정적-분석-불가능)
  - [브라우저 호환성 부족](#3-브라우저-호환성-부족)
  - [이중 생태계의 복잡성](#4-이중-생태계의-복잡성)
- [Ref](#ref)

여러 프로젝트를 진행하면서 새로운 패키지를 추가해야할 때가 있다. 새로운 패키지를 리서치 하던 중 흥미로운 PR을 본 적이 있다.

https://github.com/TanStack/table/pull/4552

약 2년전 PR 인데, 빠르게 수정되고 빠르게 머지되었다. 저때 cjs와 esm에 대해서 정리해두자! 라고 생각한게 벌써.. 시간이 그렇게 되었다.. 지금이라도 모듈 시스템에 대해 정리해보려 한다.

## 모듈 시스템의 등장 배경

초기에 웹이 등장했을때는 단순히 문서(HTML) 를 전세계로 보여주는게 전부였다. 초기 웹은 정보를 공유하는 목적이였기 때문에 동적인 기능은 거의 없었다. 하지만 전 세계적으로 웹이 도입되면서 정적인 웹 페이지에 동적인 기능을 추가하기 위해서 JavaScript가 개발 되었다. 초기에는 주로 다음과 같은 작업들에 js가 사용되었다.

- 사용자 입력 확인 (form validation)
- 간단한 인터렉션 (버튼 클릭시 이벤트 처리)
- 페이지 일부를 동적으로 변경

이런 이유로 웹에 동적인 동작이 가능해지면서 기술적인 요구사항은 점점 늘어가게 되었다.
다음 예시 코드를 한번 보자.

```html
<!DOCTYPE html>
<html lang="ko">
	<head>
		<meta charset="UTF-8" />
		<meta name="viewport" content="width=device-width, initial-scale=1.0" />
		<title>간단한 폼 예제를 만들어보자</title>
	</head>
	<body>
		<h1>폼 예제</h1>

		<form onsubmit="return handleSubmit(this)">
			<label for="name">이름:</label>
			<input type="text" id="name" name="name" required />
			<br /><br />

			<label for="email">이메일:</label>
			<input type="email" id="email" name="email" required />
			<br /><br />

			<button type="submit">확인</button>
		</form>

		<script>
			function handleSubmit(form) {
				const name = form.name.value;
				const email = form.email.value;

				alert(`이름: ${name}, 이메일: ${email}`);
				return false;
			}
		</script>
	</body>
</html>
```

위 예시처럼 JavaScript는 작은 단위의 스크립트를 브라우저에서 실행하기 위해 개발되었다. 하지만 예시만 봐도 알 수 있듯 `<script>` 태그를 이용해서 여러 파일을 관리하는 방식은 프로젝트가 커질수록 유지보수성이 떨어졌다. 이와 함께 다음과 같은 문제점들이 존재했다.

1. 전역 변수 충돌
   - 여러 스크립트 파일들이 전역 변수를 공유하다보니, 의도하지 않은 동작이 일어나기 쉬웠다.
2. 의존성 관리 어려움
   - `<script>` 태그로 파일을 순서대로 로드해야했기 때문에, 특정 파일의 의존성이 해결되지 않으면 잘못된 순서로 실행되는 문제가 있었다.
3. 코드 재사용성
   - 동일한 코드를 여러곳에서 사용하려면 복사 - 붙여넣기 방식에 의존할 수 밖에 없었다.

이러한 이유로 모듈화의 필요성이 증가하게 되었다.

## CommonJS의 등장

한편 위와 같이 브라우저 환경에서만 실행되던 JavaScript를 서버 환경에서도 사용하고자 하는 필요성이 있었다. JavaScript의 비동기적 특성(이벤트 기반 처리와 비동기 요청을 통한 데이터 처리)은 서버 측에서도 유용하게 사용될 수 있다는 생각 때문이였다. 서버 측 JavaScript 모듈화를 위해 제안된 규격이 바로 **CommonJS**다.

CommonJS는 각 **하나의 파일을 하나의 모듈**로 취급한다. 이 규격에 따르면

- 각 파일은 독립적인 코드 실행 환경을 가진다.
- 모듈을 `module.exports` 또는 `exports`로 내보내고, 다른 파일에서는 `require()`를 사용해 로드할 수 있다.
- `require()`는 동기적으로 작동하여 모듈을 모두 로드한 뒤 코드를 실행한다.
- 이후 동일한 모듈을 호출하면, 이미 로드된 모듈이 반환된다.(캐싱)

이 방식은 서버 환경에 적합한 설계였고, `Node.js`의 기본 모듈 시스템으로 채택되었다.

## Node.js의 등장

서버 사이드에서 JavaScript를 실행하기 위한 각고의 노력 끝에 `Node.js`가 등장했다. `Node.js`는 JavaScript 런타임 환경으로, JavaScript가 브라우저 외부에서도 실행될 수 있도록 설계되었다. `Node.js`는 프레임워크를 포함하지 않고 기본적인 런타임과 내장 모듈만을 제공하며, 다음과 같은 특징이 있다

1. 비동기 처리
   - 기존 서버 환경에서는 블로킹 I/O 방식이 일반적이였지만, `Node.js` 는 비동기 I/O을 채택하여 서버가 높은 성능과 확장성을 가질 수 있도록 설계했다.
2. Chrome V8 javascript 엔진 기반 동작
   - js코드를 기계어로 직접 변환(JIT, Just-In-Time Compilation) 하여 실행 성능을 극대화했다.
3. 모듈 시스템
   - 서버에서 다양한 기능을 모듈화 하여 재사용할 수 있는 환경을 제공하기 위해 **CommonJS** 모듈 시스템을 채택한다.

`Node.js`의 등장은 JavaScript로 모듈 관리와 서버 개발을 용이하게 했으며, 이로 인해 모듈을 공유하려는 필요성이 증가했다.(잘 설계된 코드를 공유함으로써 생태계 확장, 개발생산성 증가를 이룰수 있기 때문)

## npm의 등장

npm(Node Package Manager)은 Node.js 기반으로 설계된 패키지 관리 도구다.  
npm의 도입으로

- JavaScript 프로젝트의 의존성 관리가 용이
- 오픈 소스 라이브러리가 빠르게 확산되며 JavaScript 커뮤니티가 성장

과 같은 효과가 있었다.
npm은 단순히 서버용 패키지 관리에서 출발했으나, 현재는 클라이언트와 서버 모두를 아우르며 JavaScript 생태계 전반에서 사용되고 있다.

## CommonJS의 한계

위와 같은 히스토리를 바탕으로 CommonJS 모듈 시스템은 그 때 당시에는 최적의 선택이였던것 같다. 하지만 현재는 ESM(ECMAScript Module) 로 대부분 전환하고 있는데, CommonJS는 다음과 같은 한계점을 명확하게 가지고 있기 때문이다.

### 1. 동기적 모듈 로딩

CommonJS는 `require()`를 통해 동기적으로 모듈을 로드한다. 이 방식은 서버 환경에서는 적합하지만 브라우저 환경에서는 비효율적이다. 브라우저는 네트워크 요청이 포함된 모듈 로딩에서 **비동기**가 기본이기 때문이다.

```js
// moduleA.js
console.log("A 로딩 중...");
module.exports = { value: 42 };

// main.js
console.log("Main 시작");
const moduleA = require("./moduleA");
console.log("moduleA 값:", moduleA.value);
console.log("Main 종료");
```

위 코드는 `require()` 호출 시 `moduleA.js`를 완전히 실행한 후 `main.js`가 실행된다. 서버 환경에서는 파일이 로컬에 있어 빠르지만, 브라우저에서는 네트워크 요청으로 인해 로딩 속도가 느려질 수 있다.

### 2. **정적 분석 불가능**

CommonJS는 동적으로 `require()`를 호출하기 때문에, 빌드 도구가 코드에서 의존성을 미리 파악하기 어렵다. 이로 인해 **Tree Shaking**과 같은 최적화가 어렵다.

```js
// dynamicRequire.js
const moduleName = process.argv[2]; // 런타임에 모듈 이름 결정
const module = require(moduleName); // 동적 로딩
console.log(module);
```

위와 같이 모듈 이름이 동적으로 결정되면 빌드 도구는 어떤 모듈이 사용될지 예측할 수 없어 최적화를 할 수 없다.

### 3. 브라우저 호환성 부족

CommonJS는 기본적으로 브라우저 환경에서 지원되지 않는다. 브라우저에서 CommonJS 모듈을 사용하려면 Webpack 등의 번들러를 통해 변환해야 한다. 반면 ESM은 브라우저에서 네이티브로 지원된다.

```js
// 브라우저 환경에서 ESM
// module.js
export const greet = () => console.log("Hello from ESM!");

// main.js
import { greet } from "./module.js";
greet();
```

위 코드는 브라우저에서 바로 실행될 수 있지만, CommonJS는 변환 없이 실행이 불가능하다.

### 4. 이중 생태계의 복잡성

CommonJS와 ESM은 상호 호환성이 완벽하지 않아 두 모듈 시스템을 혼용할 경우 문제가 발생할 수 있다. 예를 들어 CommonJS는 ESM 모듈을 `import`하는 데 제약이 있고, 반대로 ESM은 CommonJS를 동기적으로 가져오는 데 어려움이 있다.

```js
// ESM에서 CommonJS 사용
// module.cjs (CommonJS)
module.exports = { value: 42 };

// main.mjs (ESM)
import cjsModule from "./module.cjs"; // 이 경우 Node.js에서 플래그를 설정해야 함
console.log(cjsModule.value);
```

Node.js에서는 ESM과 CommonJS를 함께 사용하는 프로젝트에서 `package.json`의 `type` 설정과 추가 플래그를 요구해 개발 복잡도가 증가한다.(package.json 에서 `"type": "modules"` 설정을 추가하거나, `.mjs`, `.cjs`등의 파일 확장자를 사용해본 경험이 있을거다)

위와 같은 이유로 CommonJS 현재 old-style 모듈 시스템으로 취급되고 있으며 다양한 프로젝트들이 ESM 모듈 시스템으로 전환하고자 노력하고 있다. 다음과 같이 쉽게 마이그레이션 할 수 있도록 가이드를 제공하기도 한다.

- [node-commonjs-to-esm](https://github.com/tsmx/node-commonjs-to-esm)
- [Automatically upgrade from CommonJS to ESM with TS2ESM](https://www.youtube.com/watch?embeds_referring_euri=https%3A%2F%2Fdev.to%2F&source_ve_path=Mjg2NjQsMTY0NTAz&v=bgGQgSQSpI8&feature=youtu.be)

---

개인적으로 기술의 히스토리를 아는 일을 좋아한다. 과거의 어떤 결정을 통해 어떤 결과로 인해 지금에 이르렀는지를 알게 되면 나의 현재의 선택에도 도움이 된다고 생각하기 때문이다. 또한 과거에는 최선의 선택 이였다고 생각했지만 현재에 이르러서 아쉬운 선택일 수도 있다. 하지만 과거의 생각을 계속 고집하지 않고 받아들이면서 새롭게 다시 하려는 시도가 중요하다고 생각한다. `Node.js` 가 CommonJS 모듈 시스템을 선택했던 것 처럼 나 또한 그런 선택을 할 수 있고, ESM 스타일로 마이그레이션 하는것 처럼 나도 그런 선택을 현재에 계속 하면 되는게 아닐까 싶다.

## Ref

- https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1
- https://nodejs.org/api/modules.html
- https://nodejs.org/api/packages.html#determining-module-system
