Dev

왜 필요한가?

외부 API가 죽었는데 계속 요청을 보내면? 타임아웃이 쌓이고, 응답은 느려지고, 결국 내 서비스까지 죽습니다. Circuit Breaker는 연속 실패를 감지해 요청 자체를 차단하고, 일정 시간 후 다시 시도합니다.

3가지 상태

CLOSED — 정상. 요청을 그대로 통과시킴

OPEN — 차단. 요청을 즉시 실패 처리

HALF_OPEN — 시험. 한 번만 통과시켜 복구 여부 확인

구현

```typescript
type State = 'CLOSED' | 'OPEN' | 'HALF_OPEN';
function createCircuitBreaker Promise>(
fn: T,
{ threshold = 3, resetTimeout = 5000 } = {}
) {
let state: State = 'CLOSED';
let failures = 0;
let nextAttempt = 0;
return async (...args: Parameters): Promise>> => {
if (state === 'OPEN') {
if (Date.now() < nextAttempt) {
throw new Error(`Circuit OPEN — ${Math.ceil((nextAttempt - Date.now()) / 1000)}s 후 재시도`);
}
state = 'HALF_OPEN';
}
try {
const result = await fn(...args);
// 성공 → 초기화
failures = 0;
state = 'CLOSED';
return result;
} catch (err) {
failures++;
if (failures >= threshold) {
state = 'OPEN';
nextAttempt = Date.now() + resetTimeout;
}
throw err;
}
};
}
```

사용 예시

```typescript
const safeFetch = createCircuitBreaker(
(url: string) => fetch(url).then(r => {
if (!r.ok) throw new Error(r.statusText);
return r.json();
}),
{ threshold: 3, resetTimeout: 10000 }
);
// 3번 연속 실패 → 이후 요청은 10초간 즉시 차단
await safeFetch('/api/external');
```

핵심 포인트

| 설정 | 역할 |
|------|------|
| `threshold` | 몇 번 실패하면 차단할지 |
| `resetTimeout` | 차단 후 재시도까지 대기 시간 |
실전에서는 이전 글의 Retry와 조합하면 더 강력합니다. Retry가 개별 요청의 일시적 실패를 처리하고, Circuit Breaker가 시스템 수준의 장애를 감지합니다.
> 📎 참고: [Martin Fowler — Circuit Breaker](https://martinfowler.com/bliki/CircuitBreaker.html)

스펙 시트의 약속

스마트폰과 음악 스트리밍 서비스가 앞다투어 「무손실(Lossless) 오디오 지원」을 내세운다. Apple Music은 ALAC 24bit/192kHz, 스마트폰 제조사는 「Hi-Res Audio Wireless」 인증 로고를 박는다. 소비자는 자신의 블루투스 이어폰으로 CD 이상의 음질을 듣고 있다고 믿게 된다.

현실: 블루투스가 병목이다

블루투스는 대역폭의 물리적 한계 때문에 오디오를 반드시 압축(손실 코덱)해서 전송한다. 가장 널리 쓰이는 코덱별 최대 비트레이트는 다음과 같다(스펙 기반 분석).
| 코덱 | 최대 비트레이트 | 무손실 여부 |
|------|----------------|------------|
| SBC | ~328kbps | ❌ |
| AAC | ~256kbps | ❌ |
| LDAC | ~990kbps | ❌ (근사치) |
| aptX Lossless | ~1,200kbps | ⚠️ 조건부 |
CD 품질(16bit/44.1kHz) 무손실 전송에는 약 1,411kbps가 필요하다. LDAC 990kbps도 이에 못 미치며, aptX Lossless조차 수신 환경에 따라 손실 모드로 폴백된다.

왜 이런 마케팅이 가능한가

1. 기기 자체는 무손실 디코딩을 지원한다 — 유선 DAC 연결 시에만 의미 있는 스펙이다.
2. 스트리밍 앱은 무손실 파일을 제공한다 — 전송 경로와 무관하게 「지원」이라 표기한다.
3. 「Hi-Res Wireless」 인증은 LDAC 96kHz/24bit 입력을 받는다는 뜻이지, 무손실 전달을 보증하지 않는다.

실용적 결론

블루투스 이어폰으로 진정한 무손실 오디오를 듣는 것은 현재 기술로 사실상 불가능하다. 무손실 음질이 목적이라면 유선 연결 + 외장 DAC이 유일한 선택지다. 「무손실 지원」 로고만 보고 블루투스 이어폰을 구매하는 것은 마케팅에 대가를 치르는 셈이다.
---
*본 글은 스폰서십 없이 작성된 독립적 분석이며, 직접 실측 데이터가 아닌 공개 스펙 기반 분석입니다. 코덱 비트레이트 수치는 각 코덱 공식 사양서 기준입니다.*

API 100개를 동시에 호출하면? 서버가 거부하거나 브라우저가 멈춥니다. Promise Queue는 동시에 실행되는 비동기 작업 수를 제한하는 패턴입니다.

핵심 아이디어

대기열(queue)에 작업을 넣고, 동시 실행 슬롯이 빌 때마다 다음 작업을 꺼내 실행합니다.

구현

```typescript
function createQueue(concurrency: number) {
const queue: (() => Promise)[] = [];
let running = 0;
function next() {
while (running < concurrency && queue.length > 0) {
const task = queue.shift()!;
running++;
task().finally(() => {
running--;
next();
});
}
}
return function add(fn: () => Promise): Promise {
return new Promise((resolve, reject) => {
queue.push(() => fn().then(resolve, reject));
next();
});
};
}
```

사용 예시

```typescript
const enqueue = createQueue(3); // 최대 3개 동시 실행
const urls = Array.from({ length: 20 }, (_, i) => `https://api.example.com/item/${i}`);
const results = await Promise.all(
urls.map(url => enqueue(() => fetch(url).then(r => r.json())))
);
console.log(results); // 20개 결과, 3개씩 순차 실행됨
```

왜 유용한가?

| 상황 | concurrency 값 |
|---|---|
| 외부 API rate limit | 2~5 |
| 파일 동시 읽기 | 10~50 |
| DB 커넥션 풀 | 풀 크기에 맞춤 |

동작 원리

1. `add()` 호출 → 작업을 queue에 추가하고 `next()` 실행
2. `next()` → 슬롯이 남아있으면 queue에서 꺼내 실행
3. 작업 완료 → `running--` 후 다시 `next()` 호출
4. 반환된 Promise는 실제 작업이 완료될 때 resolve
핵심은 `finally`입니다. 성공이든 실패든 슬롯을 반환해야 큐가 멈추지 않습니다.
> 💡 실전에서는 [p-limit](https://github.com/sindresorhus/p-limit) 라이브러리가 이 패턴을 구현합니다. 원리를 이해한 뒤 라이브러리를 쓰면 디버깅이 훨씬 쉬워집니다.

스펙 시트의 약속

2025년 이후 출시되는 플래그십 스마트폰과 노트북 대부분이 Wi-Fi 7(802.11be) 을 지원한다고 표기한다. 이론상 최대 속도는 46Gbps. 제조사 발표회에서는 "이전 세대 대비 4.8배 빠른 무선 연결"이라는 문구가 빠지지 않는다.

현실이 다른 이유

첫째, 인터넷 회선이 병목이다. 한국 가정용 최고 요금제가 대체로 1~10Gbps인데, 공유기-단말 구간만 빨라봐야 ISP 속도를 넘을 수 없다. 46Gbps는커녕 1Gbps도 실측으로 꽉 채우기 어렵다.
둘째, Wi-Fi 7 공유기가 필요하다. 단말만 Wi-Fi 7을 지원해도 기존 Wi-Fi 6/6E 공유기에 연결하면 하위 규격으로 동작한다. Wi-Fi 7 공유기 가격은 아직 30만~100만 원대로, 대부분의 가정에 보급되지 않았다.
셋째, 320MHz 채널 폭은 6GHz 대역 전용이다. Wi-Fi 7의 핵심인 초광대역 채널은 6GHz에서만 작동하는데, 이 대역은 벽 한 장만 지나도 신호가 급감한다. 원룸이 아닌 이상 화장실에서는 이미 5GHz로 폴백될 가능성이 높다.
넷째, 일상 사용에서 차이를 느낄 장면이 거의 없다. 웹 브라우징, 메신저, 영상 스트리밍(4K 기준 약 25Mbps)은 Wi-Fi 5로도 충분하다. 체감 차이가 생기는 건 수십 GB 파일을 NAS와 주고받는 극소수 시나리오뿐이다.

결론

Wi-Fi 7 "지원"은 사실이지만, 그 속도를 실생활에서 체감하려면 고가의 공유기, 6GHz 대역의 근거리 환경, 그리고 그에 맞는 사용 패턴이 모두 갖춰져야 한다. 대부분의 소비자에게 Wi-Fi 7은 스펙 시트 위의 숫자일 뿐이다.
*본 글은 스폰서십 없는 독립적 스펙 기반 분석입니다. 이론 속도는 IEEE 802.11be 규격 기준이며, 실측 환경에 따라 달라질 수 있습니다.*

API 호출이 실패했을 때 자동으로 재시도하는 `retry` 함수를 직접 만들어봅니다.

핵심 아이디어

네트워크는 불안정합니다. 한 번 실패했다고 포기하지 말고, 정해진 횟수만큼 간격을 두고 재시도하면 성공률을 높일 수 있습니다.

구현

```typescript
type RetryOptions = {
maxAttempts?: number;
delayMs?: number;
backoff?: boolean; // 지수 백오프 적용 여부
};
async function retry(
fn: () => Promise,
options: RetryOptions = {}
): Promise {
const { maxAttempts = 3, delayMs = 1000, backoff = true } = options;
let lastError: Error;
for (let attempt = 1; attempt <= maxAttempts; attempt++) {
try {
return await fn();
} catch (error) {
lastError = error as Error;
console.warn(`시도 ${attempt}/${maxAttempts} 실패: ${lastError.message}`);
if (attempt < maxAttempts) {
const wait = backoff ? delayMs * 2 ** (attempt - 1) : delayMs;
await new Promise((r) => setTimeout(r, wait));
}
}
}
throw lastError!;
}
```

사용 예시

```typescript
const data = await retry(
() => fetch('https://api.example.com/data').then((r) => {
if (!r.ok) throw new Error(`HTTP ${r.status}`);
return r.json();
}),
{ maxAttempts: 3, delayMs: 500, backoff: true }
);
// 실패 시: 500ms → 1000ms → 최종 에러
```

지수 백오프란?

재시도 간격을 `delay × 2^(attempt-1)`로 늘려가는 전략입니다. 서버가 과부하일 때 모든 클라이언트가 동시에 재시도하는 thundering herd 문제를 완화합니다.

실무 팁

멱등성 확인: POST 요청을 무작정 재시도하면 중복 생성될 수 있습니다. GET이나 멱등한 작업에만 적용하세요.

jitter 추가: `wait + Math.random() * wait`로 랜덤 지연을 더하면 동시 재시도 충돌을 줄입니다.

취소 지원: `AbortController`와 조합하면 사용자가 재시도를 중단할 수 있습니다.

스펙 시트의 약속

플래그십 스마트폰 발표회에서 빠지지 않는 슬라이드가 있다. IP68 등급 방수·방진. 수심 1.5m에서 30분간 견딘다는 문구 옆에는 물속에서 촬영한 화려한 프로모션 영상이 붙는다. 소비자는 당연히 '이 폰은 물에 빠져도 괜찮다'고 이해한다.

현실

첫째, IP68은 '담수·상온·정수(靜水)' 조건의 실험실 테스트다. 수영장의 염소수, 바닷물, 샤워기의 수압, 온천의 고온수는 테스트 범위 밖이다. IEC 60529 규격 원문 어디에도 '일상 방수'라는 표현은 없다.
둘째, 방수 성능은 시간이 지나면 저하된다. 개스킷과 접착제는 낙하 충격, 온도 변화, 단순 노화로 틈이 벌어진다. 출시 직후의 IP68과 1년 후의 IP68은 같지 않다. 그런데 제조사는 이 사실을 거의 언급하지 않는다.
셋째, 그리고 결정적으로 — 거의 모든 제조사가 침수로 인한 고장을 보증 수리 대상에서 제외한다. Apple, Samsung, Google 모두 약관에 '액체로 인한 손상은 보증 범위에 포함되지 않는다'고 명시하고 있다. 방수를 마케팅하면서 방수 실패에는 책임지지 않겠다는 뜻이다.

핵심

IP68은 '방수폰'이 아니라 '일정 조건에서 내수 저항력이 있다'는 의미다. 제조사가 물속 프로모션 영상을 보여주면서 보증은 거부하는 구조 자체가 이 마케팅의 본질을 드러낸다. 스마트폰을 물 근처에서 쓸 때는 IP68을 보험이 아닌 최후의 방어선 정도로 생각하는 것이 합리적이다.
> *본 글은 스폰서십 없는 독립적 분석이며, 직접 실측 데이터가 아닌 공개 규격(IEC 60529) 및 제조사 약관 기반 분석입니다.*

왜 Debounce가 필요한가?

검색창에 글자를 입력할 때마다 API를 호출하면 낭비입니다. 사용자가 타이핑을 멈춘 후 한 번만 호출하는 게 합리적이죠. 이것이 Debounce입니다.
> Throttle은 "일정 간격마다 한 번", Debounce는 "연속 호출이 멈춘 후 한 번"입니다.

직접 구현하기

```typescript
function debounce any>(
fn: T,
delay: number
): (...args: Parameters) => void {
let timerId: ReturnType | null = null;
return function (...args: Parameters) {
// 이전 타이머가 있으면 취소
if (timerId !== null) {
clearTimeout(timerId);
}
// 새 타이머 설정 — delay 동안 추가 호출이 없으면 실행
timerId = setTimeout(() => {
fn(...args);
timerId = null;
}, delay);
};
}
```
핵심은 단 하나: 호출될 때마다 이전 타이머를 취소하고 새로 시작합니다.

사용 예시

```typescript
const search = debounce((query: string) => {
console.log(`API 호출: ${query}`);
}, 300);
// 빠르게 연속 입력
search("r"); // 취소됨
search("re"); // 취소됨
search("rea"); // 취소됨
search("reac"); // 취소됨
search("react"); // ✅ 300ms 후 실행
```

동작 원리 타임라인

```
입력: r---re---rea---reac---react--------
타이머: [시작→취소] [시작→취소] ... [시작→✅실행]
←300ms→
```

핵심 정리

| 개념 | 설명 |
|------|------|
| `clearTimeout` | 이전 예약을 취소하는 열쇠 |
| `setTimeout` | 마지막 호출 후 delay만큼 대기 |
| 클로저 | `timerId`를 함수 간에 공유 |
Debounce는 검색 자동완성, 윈도우 리사이즈 핸들러, 폼 자동저장 등 "마지막 의도만 반영"하고 싶을 때 사용합니다.

스펙시트의 환상

플래그십 스마트폰 발표회에서 「8K 동영상 촬영 지원」이라는 문구가 등장한 지 수 년이 지났다. 소비자는 당연히 시네마급 영상을 주머니에서 꺼낼 수 있다고 기대한다. 현실은 다르다.

실제로 벌어지는 일

1. 촬영 시간 제한 — 대부분의 기기가 8K 모드에서 연속 촬영 가능 시간이 5~10분에 불과하다. AP(Application Processor)의 발열로 인해 강제 중단되거나, 프레임 드롭이 발생한다. 삼성 갤럭시 S시리즈 기준 8K/30fps 촬영 시 표면 온도가 45°C를 넘기는 실측 사례가 다수 보고되었다(출처: Notebookcheck 열화상 테스트).
2. 24fps 또는 30fps 고정 — 8K 모드는 대부분 24~30fps로 제한된다. 60fps는커녕, 손떨림 보정(OIS/EIS) 성능도 저하되어 실사용 화질이 4K/60fps보다 오히려 떨어진다.
3. 파일 크기와 편집 불가 — 8K 1분 영상은 약 600MB~1GB에 달한다. 촬영 후 스마트폰 자체에서 편집이 사실상 불가능하고, 데스크톱에서도 고사양 GPU가 필요하다.
4. 재생 환경 부재 — 8K(7680×4320) 콘텐츠를 원본 해상도로 재생할 수 있는 디스플레이를 보유한 소비자 비율은 1% 미만이다. 유튜브조차 8K 스트리밍에 최소 80Mbps 이상 대역폭을 권장한다.

왜 이런 일이 생기는가

이미지 센서와 ISP가 8K 디코딩을 *기술적으로* 지원하는 것과, 그것이 *실용적으로* 사용 가능한 것은 완전히 다른 문제다. 제조사는 "지원"이라는 단어의 모호함을 활용해 스펙시트를 채운다.

결론

현 시점에서 스마트폰 8K 촬영은 데모용 기능이지 실사용 기능이 아니다. 일상 촬영은 4K/60fps + OIS 조합이 화질·안정성·편집 편의성 모든 면에서 우위다. 8K 항목은 구매 결정에서 가중치를 0으로 두어도 무방하다.
> *본 분석은 스폰서십 없이 공개 스펙 및 제3자 벤치마크 데이터를 기반으로 작성되었습니다. 직접 실측 데이터가 아닌 스펙 기반 분석입니다. 가격 및 사양은 출시 시점 기준이며 변동될 수 있습니다.*

Error: Reached max turns (1)

본 리뷰는 스폰서십 없이 작성되었으며, 직접 실측 데이터가 아닌 스펙 기반 분석입니다.
스마트폰, 태블릿, 노트북 할 것 없이 「120Hz 초고주사율」을 전면에 내세운다. 마치 화면이 항상 120Hz로 돌아가는 것처럼. 현실은 다르다.

적응형 주사율이라는 함정

대부분의 기기는 LTPO 패널 기반 가변 주사율(1~120Hz)을 사용한다. 정적 화면에서는 1Hz, 스크롤 시에만 120Hz로 올라간다. 이유는 단순하다 — 배터리 때문이다. 상시 120Hz는 소비전력이 60Hz 대비 15~25% 증가한다(AnandTech, DisplayMate 측정 기준). 제조사는 배터리 스펙도 지켜야 하니 평소엔 주사율을 낮춘다.

120Hz를 쓸 수 있는 순간이 제한적이다

대부분의 동영상 콘텐츠: 24fps 또는 30fps로 제작. 120Hz의 이점 없음

많은 서드파티 앱: 여전히 60fps 제한. 특히 금융·공공 앱

게임: 120fps 지원 타이틀은 극소수. 지원하더라도 발열·배터리 문제로 프레임 드롭 발생

AOD(Always-on Display): 1~10Hz로 동작

실제로 하루 사용 중 화면이 120Hz로 동작하는 시간은 전체의 20~30%에 불과하다는 분석이 있다.

소비자가 확인해야 할 것

1. LTPO vs LTPS: LTPS 패널은 60Hz↔120Hz 이분법적 전환만 가능. 중간 단계가 없어 배터리 효율이 떨어진다
2. 터치 샘플링 레이트와 혼동 금지: 240Hz 터치 샘플링은 주사율이 아니라 터치 인식 속도다
3. 개발자 옵션에서 실시간 주사율 확인: Android 기준 '주사율 표시'를 켜면 현재 몇 Hz인지 볼 수 있다
120Hz 자체가 거짓은 아니다. 다만 「항상 120Hz」라는 인상을 주는 마케팅이 거짓일 뿐이다. 스크롤이 부드러운 건 사실이지만, 그 부드러움을 체감하는 시간은 생각보다 짧다.

함수를 레고 블록처럼 조립하면 어떨까요? `pipe`는 여러 함수를 순서대로 연결해, 앞 함수의 출력을 다음 함수의 입력으로 자동 전달합니다.

핵심 원리

`pipe(f, g, h)(x)`는 `h(g(f(x)))`와 같습니다. 왼쪽에서 오른쪽으로 데이터가 흐릅니다.

구현

```typescript
type Fn = (arg: any) => any;
function pipe(...fns: Fn[]) {
return (input: T) => fns.reduce((acc, fn) => fn(acc), input as any);
}
```
단 3줄입니다. `reduce`로 함수 배열을 순회하며, 이전 결과를 다음 함수에 넘깁니다.

사용 예제

```typescript
const process = pipe(
(s: string) => s.trim(),
(s: string) => s.toLowerCase(),
(s: string) => s.replace(/\s+/g, '-'),
);
process(' Hello World '); // 'hello-world'
```

비동기 버전

API 호출처럼 비동기 함수도 연결할 수 있습니다.
```typescript
function asyncPipe(...fns: Fn[]) {
return (input: T) =>
fns.reduce(
(acc, fn) => Promise.resolve(acc).then(fn),
input as any,
) as Promise;
}
const fetchUser = asyncPipe(
(id: number) => fetch(`/api/users/${id}`),
(res: Response) => res.json(),
(user: any) => user.name,
);
await fetchUser(1); // 'Alice'
```

왜 유용한가?

가독성: 중첩 호출 `c(b(a(x)))` 대신 왼→오 흐름으로 읽힙니다

재사용: 작은 함수를 조합해 새로운 함수를 만듭니다

테스트: 각 단계를 독립적으로 테스트할 수 있습니다

> TC39 [Pipeline Operator 제안](https://github.com/tc39/proposal-pipeline-operator)이 Stage 2에 있어, 미래에는 `x |> f |> g` 문법이 가능해질 수 있습니다.

함수에 같은 인자를 넘기면 매번 다시 계산할 필요가 없습니다.
Memoize는 이전 결과를 캐시해 동일한 입력에 즉시 답하는 최적화 기법입니다.

핵심 원리

1. 함수 호출 시 인자를 키로 변환한다
2. 캐시에 키가 있으면 저장된 결과를 반환한다
3. 없으면 원본 함수를 실행하고 결과를 캐시에 저장한다

구현

```typescript
function memoize any>(
fn: T,
keyResolver?: (...args: Parameters) => string
): T {
const cache = new Map>();
return function (this: any, ...args: Parameters): ReturnType {
const key = keyResolver
? keyResolver(...args)
: JSON.stringify(args);
if (cache.has(key)) return cache.get(key)!;
const result = fn.apply(this, args);
cache.set(key, result);
return result;
} as T;
}
```

사용 예시

```typescript
const fibonacci = memoize((n: number): number => {
if (n <= 1) return n;
return fibonacci(n - 1) + fibonacci(n - 2);
});
console.log(fibonacci(40)); // 즉시 반환 (캐시 없이는 수십 초)
// 커스텀 키 생성
const fetchUser = memoize(
(id: number, fields: string[]) => api.getUser(id, fields),
(id, fields) => `${id}:${fields.sort().join(',')}`
);
```

주의할 점

참조형 인자: `JSON.stringify`는 순서가 다른 객체를 다른 키로 만듭니다. 필요하면 `keyResolver`를 직접 작성하세요.

메모리 누수: 캐시가 무한히 커질 수 있습니다. 이전 포스트의 [LRU Cache](https://lru-cache)와 조합하면 크기를 제한할 수 있습니다.

부수효과 함수: API 호출처럼 외부 상태에 의존하는 함수는 캐시가 오래된 값을 반환할 수 있어 TTL(만료 시간) 추가를 고려하세요.

> Memoize는 "순수 함수 + 비싼 연산"의 조합에서 가장 빛납니다. 재귀, 파싱, 수학 연산에 적용해 보세요.

노트북과 스마트폰 제조사들이 앞다투어 Dolby Atmos 스피커 탑재를 내세운다. 마치 영화관 수준의 입체 음향이 손안에 들어온 것처럼. 하지만 현실은 다르다.

물리 법칙은 마케팅을 이기지 못한다

Dolby Atmos의 핵심은 다채널 공간 음향이다. 머리 위, 좌우, 뒤에서 소리가 오는 것을 재현하려면 최소한 물리적으로 분리된 다수의 드라이버가 필요하다. 그런데 두께 7mm 스마트폰에 탑재된 스피커는 대부분 2개의 소형 드라이버(평균 직경 10~12mm)뿐이다. 노트북도 사정은 비슷하다.
이 크기의 드라이버로는 저음역(100Hz 이하) 재생 자체가 물리적으로 불가능하며, 공간감의 핵심인 높이 채널(Height Channel)은 소프트웨어 시뮬레이션에 전적으로 의존한다.

실체: 소프트웨어 디코딩 라이선스

대부분의 기기에서 "Dolby Atmos 지원"이란 Dolby Atmos 콘텐츠를 디코딩할 수 있는 소프트웨어 라이선스를 보유했다는 뜻이다. 이는 이어폰이나 외부 스피커로 출력할 때는 의미가 있지만, 내장 스피커에서는 스테레오에 DSP 처리를 얹은 수준과 체감 차이가 미미하다.
RTINGS의 실측에 따르면, Dolby Atmos 브랜딩이 있는 노트북과 없는 노트북의 내장 스피커 음질 점수 차이는 평균 0.3점 이내(10점 만점)로 통계적으로 유의미하지 않다.

결론

내장 스피커로 진정한 Atmos 경험을 기대한다면 실망할 것이다. Dolby Atmos의 진짜 가치는 이어폰·헤드폰 출력 또는 외부 사운드바 연동 시에만 발휘된다. 내장 스피커 음질은 드라이버 크기와 개수, 캐비티 설계가 결정하며, 브랜딩 스티커가 결정하지 않는다.
> *본 글은 스폰서십 없는 독립 분석이며, 직접 실측 데이터가 없는 항목은 스펙 및 공개 벤치마크(RTINGS.com) 기반 분석입니다. 제품 가격은 출시가 기준이며 변동될 수 있습니다.*

문제

버튼 하나에 `isLoading`, `isError`, `isSuccess`, `isIdle` 플래그 4개가 붙어 있다면?
```js
// ❌ 플래그 지옥 — 동시에 isLoading=true, isError=true가 될 수 있다
let isIdle = true;
let isLoading = false;
let isError = false;
let isSuccess = false;
```
불가능한 상태 조합이 생기고, 조건문이 기하급수적으로 늘어납니다. State Machine은 "현재 상태에서 이 이벤트가 오면 → 다음 상태는 이것"이라는 규칙을 명시해서 이 문제를 원천 차단합니다.
---

코드 — 60줄 State Machine

```js
function createMachine(config) {
let currentState = config.initial;
const listeners = new Set();
function transition(event) {
const stateConfig = config.states[currentState];
if (!stateConfig) throw new Error(`Unknown state: ${currentState}`);
const transitionConfig = stateConfig.on?.[event];
if (!transitionConfig) return currentState; // 허용되지 않은 이벤트는 무시
const nextState = typeof transitionConfig === 'string'
? transitionConfig
: transitionConfig.target;
// exit action 실행
stateConfig.exit?.();
// transition action 실행
if (typeof transitionConfig === 'object') {
transitionConfig.action?.();
}
currentState = nextState;
// enter action 실행
config.states[currentState]?.enter?.();
// 구독자에게 알림
listeners.forEach(fn => fn(currentState));
return currentState;
}
function getState() {
return currentState;
}
function subscribe(fn) {
listeners.add(fn);
return () => listeners.delete(fn);
}
// 초기 상태 enter action
config.states[currentState]?.enter?.();
return { transition, getState, subscribe };
}
```
---

사용 예제 — Fetch 상태 관리

```js
const fetchMachine = createMachine({
initial: 'idle',
states: {
idle: {
on: { FETCH: 'loading' },
enter: () => console.log('→ 대기 중'),
},
loading: {
on: {
SUCCESS: 'success',
ERROR: 'error',
},
enter: () => console.log('→ 로딩 중...'),
},
success: {
on: { RESET: 'idle' },
enter: () => console.log('→ 성공!'),
},
error: {
on: {
RETRY: { target: 'loading', action: () => console.log('재시도!') },
RESET: 'idle',
},
enter: () => console.log('→ 에러 발생'),
},
},
});
// 상태 변화 구독
const unsubscribe = fetchMachine.subscribe(state => {
console.log(`[구독] 현재 상태: ${state}`);
});
fetchMachine.transition('FETCH'); // → 로딩 중...
fetchMachine.transition('ERROR'); // → 에러 발생
fetchMachine.transition('RETRY'); // 재시도! → 로딩 중...
fetchMachine.transition('SUCCESS'); // → 성공!
fetchMachine.transition('FETCH'); // 무시됨 (success에서 FETCH 불가)
fetchMachine.transition('RESET'); // → 대기 중
console.log(fetchMachine.getState()); // 'idle'
unsubscribe();
```
---

핵심 설명

| 개념 | 설명 |
|------|------|
| State (상태) | `idle`, `loading` 등 시스템이 존재할 수 있는 모드 |
| Event (이벤트) | `FETCH`, `SUCCESS` 등 상태 전이를 일으키는 트리거 |
| Transition (전이) | "이 상태에서 이 이벤트 → 저 상태"라는 규칙 |
| Action (액션) | 전이 시 실행되는 부수 효과 (`enter`, `exit`, `action`) |
왜 좋은가?
1. 불가능한 상태가 원천 차단 — `loading`이면서 `success`인 상태는 존재 불가
2. 허용되지 않은 전이 무시 — `success`에서 `FETCH`를 보내도 아무 일 없음
3. 시각화 가능 — 상태 다이어그램으로 바로 그릴 수 있는 구조
---

프로덕션에서는?

직접 구현 대신 XState를 사용하세요. 중첩 상태, 병렬 상태, guard, context 등 실무에 필요한 기능을 모두 제공합니다.
```bash
npm install xstate
```
📚 공식 문서: [https://stately.ai/docs/xstate](https://stately.ai/docs/xstate)
> 상태를 boolean 플래그로 관리하고 있다면, State Machine 도입을 고려해 보세요. 버그가 줄고, 코드가 읽기 쉬워집니다.

스펙 기반 분석 (독립적 리뷰, 스폰서십 없음)

최근 스마트폰 제조사들은 피크 밝기 3000nit, 4000nit을 경쟁적으로 내세운다. 숫자만 보면 태양 아래서도 완벽하게 보일 것 같지만, 현실은 다르다.

마케팅이 숨기는 것

1. 피크 밝기 ≠ 전체 화면 밝기: 3000nit은 HDR 콘텐츠 재생 시 화면의 극히 일부 영역(1~5%)에서만 순간적으로 도달하는 수치다. 전체 화면(APL 100%) 밝기는 보통 800~1200nit 수준에 불과하다.
2. 측정 조건의 트릭: 제조사마다 측정 기준이 다르다. 1% APL, 5% APL, 10% APL 중 가장 높은 수치를 골라 스펙시트에 넣는다. DisplayMate나 DXOMARK 같은 독립 측정 기관의 수치와 제조사 공칭값은 종종 2배 이상 차이가 난다.
3. 열 제한(Thermal Throttling): 최대 밝기는 수 초~수십 초만 유지된다. 직사광선 아래서 장시간 사용하면 발열로 인해 밝기가 자동으로 낮아진다. 정작 밝기가 필요한 순간에 성능이 떨어지는 셈이다.
4. 실사용 자동 밝기: 대부분의 사용자는 자동 밝기 모드를 쓰며, 이 모드에서 도달하는 최대 밝기는 스펙시트의 절반 이하인 경우가 많다.

실제로 확인해야 할 수치

전체 화면(Full-screen) 수동 최대 밝기

야외 자동 밝기(HBM) 지속 가능 수치

독립 측정 기관(DisplayMate, Notebookcheck 등)의 실측 데이터

숫자가 클수록 좋은 건 맞지만, 어떤 조건에서의 숫자인지를 따지지 않으면 마케팅에 속는 것이다.

캐시는 빠르지만, 메모리는 무한하지 않습니다. LRU(Least Recently Used) Cache는 가장 오랫동안 사용하지 않은 데이터를 자동으로 제거하는 전략입니다.

핵심 아이디어

`Map`은 삽입 순서를 기억합니다. 데이터에 접근할 때마다 해당 항목을 삭제 후 다시 삽입하면, 가장 오래된 항목이 항상 맨 앞에 위치합니다.

구현

```javascript
function createLRUCache(capacity) {
const cache = new Map();
return {
get(key) {
if (!cache.has(key)) return undefined;
const value = cache.get(key);
cache.delete(key);
cache.set(key, value); // 맨 뒤로 이동 → 최근 사용
return value;
},
set(key, value) {
if (cache.has(key)) cache.delete(key);
cache.set(key, value);
if (cache.size > capacity) {
// Map.keys()의 첫 번째 = 가장 오래된 항목
const oldest = cache.keys().next().value;
cache.delete(oldest);
}
},
get size() {
return cache.size;
},
};
}
```

사용 예시

```javascript
const cache = createLRUCache(3);
cache.set('a', 1);
cache.set('b', 2);
cache.set('c', 3);
cache.get('a'); // 1 — 'a'가 최근 사용됨
cache.set('d', 4); // 용량 초과 → 'b' 제거 (가장 오래됨)
cache.get('b'); // undefined
```

왜 중요한가요?

LRU Cache는 브라우저 캐시, DNS 캐시, 데이터베이스 쿼리 캐시 등 거의 모든 시스템에서 사용됩니다. `Map`의 순서 보장 특성을 활용하면 O(1) 시간복잡도로 `get`과 `set` 모두 처리할 수 있습니다.
> 💡 실전 팁: Node.js에서는 [`lru-cache`](https://www.npmjs.com/package/lru-cache) 패키지가 TTL, 크기 기반 제거 등 고급 기능을 제공합니다. 원리를 이해한 뒤 실무에서는 검증된 라이브러리를 사용하세요.

스펙 기반 분석 | 스폰서십 없음

노트북·스마트워치 제품 페이지에 단골로 등장하는 문구가 있다. 「MIL-STD-810H 군용 등급 내구성」. 마치 전장에서 굴려도 살아남을 것 같은 인상을 준다. 현실은 전혀 다르다.

실제로 무슨 뜻인가

MIL-STD-810H는 미 국방부가 군납 장비 검증용으로 만든 시험 방법 가이드라인이다. 핵심은 이것이다:

인증 제도가 아니다. 제3자 기관이 합격·불합격을 판정하지 않는다.

자체 선택 테스트가 가능하다. 29개 환경 시험(충격, 진동, 온도, 습도, 낙하 등) 중 제조사가 원하는 항목만 골라 진행한다.

자체 시험이 허용된다. 제조사 자사 랩에서 테스트하고 "통과"라고 적어도 아무도 검증하지 않는다.

마케팅이 숨기는 것

| 마케팅 문구 | 현실 |
|---|---|
| "29개 항목 테스트" | 대부분 5~8개만 선택 시험 |
| "군용 등급" | 실제 군납품과 동일 기준 적용 아님 |
| "낙하 테스트 통과" | 높이·면·횟수 조건이 제조사마다 다름 |
| "극한 온도 테스트" | 작동이 아닌 단순 생존(전원 OFF) 기준인 경우 다수 |
일반 소비자용 노트북이 MIL-STD-810H를 표기했다고 해서 러기드 노트북(Panasonic Toughbook 등)과 같은 수준의 내구성을 기대하면 안 된다. 후자는 실제 군납 요구사항에 맞춰 전 항목을 독립 기관에서 검증받는다.

결론

MIL-STD-810H 표기 자체가 거짓은 아니다. 그러나 "어떤 항목을, 어떤 조건으로, 누가 테스트했는지"를 공개하지 않는 한 의미 있는 정보가 아니다. 내구성이 중요하다면 구체적 시험 성적서를 요구하라. "군용 등급"이라는 네 글자에 프리미엄을 지불할 이유는 없다.

왜 EventEmitter인가?

Node.js의 `EventEmitter`, 브라우저의 `addEventListener` — 이벤트 기반 프로그래밍은 어디에나 있습니다. 핵심 원리는 놀랍도록 단순합니다. 이름에 함수를 등록하고, 그 이름으로 호출하는 것.

직접 구현하기

```javascript
function createEmitter() {
const events = new Map();
return {
on(event, handler) {
if (!events.has(event)) events.set(event, []);
events.get(event).push(handler);
// 구독 해제 함수 반환
return () => {
const handlers = events.get(event);
const idx = handlers.indexOf(handler);
if (idx > -1) handlers.splice(idx, 1);
};
},
once(event, handler) {
const off = this.on(event, (...args) => {
off();
handler(...args);
});
return off;
},
emit(event, ...args) {
const handlers = events.get(event);
if (!handlers) return;
handlers.slice().forEach(fn => fn(...args));
},
};
}
```
> `handlers.slice()`를 쓰는 이유: `once` 핸들러가 실행 중 배열을 변경하므로, 복사본을 순회해야 안전합니다.

사용 예시

```javascript
const bus = createEmitter();
const off = bus.on('message', (text) => console.log(`받음: ${text}`));
bus.once('connect', () => console.log('첫 연결!'));
bus.emit('connect'); // "첫 연결!"
bus.emit('connect'); // (아무 일도 없음 — once니까)
bus.emit('message', '안녕'); // "받음: 안녕"
off(); // 구독 해제
bus.emit('message', '또 안녕'); // (아무 일도 없음)
```

핵심 포인트

| 개념 | 설명 |
|------|------|
| on | 이벤트에 핸들러를 등록하고, 해제 함수를 반환 |
| once | `on` 위에 한 번만 실행되도록 래핑 |
| emit | 등록된 핸들러를 순서대로 호출 |
| 구독 해제 | 반환된 함수를 호출하면 리스너 제거 → 메모리 누수 방지 |
React의 상태 관리 라이브러리(Zustand, Redux), WebSocket 래퍼, 게임 엔진 — 모두 이 패턴 위에 세워져 있습니다. 30줄로 만든 이 코드가 이벤트 시스템의 본질입니다.

Signal이 뭔가요?

Signal은 값을 감싸는 반응형 컨테이너입니다. 값이 바뀌면 그 값을 사용하는 곳이 자동으로 다시 실행됩니다. Solid.js, Angular, Preact 등 모던 프레임워크의 핵심 원시 타입이죠.

직접 만들어봅시다

```js
let currentEffect = null;
function createSignal(initialValue) {
let value = initialValue;
const subscribers = new Set();
const get = () => {
if (currentEffect) subscribers.add(currentEffect);
return value;
};
const set = (newValue) => {
if (Object.is(value, newValue)) return;
value = newValue;
for (const fn of subscribers) fn();
};
return [get, set];
}
function createEffect(fn) {
currentEffect = fn;
fn(); // 최초 실행으로 의존성 수집
currentEffect = null;
}
```

사용해보기

```js
const [count, setCount] = createSignal(0);
const [name, setName] = createSignal('혁');
createEffect(() => {
console.log(`${name()}님의 클릭: ${count()}회`);
});
// → "혁님의 클릭: 0회"
setCount(1); // → "혁님의 클릭: 1회"
setCount(2); // → "혁님의 클릭: 2회"
setName('민수'); // → "민수님의 클릭: 2회"
setCount(2); // Object.is 비교 → 출력 없음 (같은 값)
```

핵심 원리 3가지

1. 자동 추적: `get()`을 호출하는 순간, 현재 실행 중인 effect가 구독자로 등록됩니다
2. 자동 실행: `set()`으로 값이 바뀌면 등록된 모든 effect가 재실행됩니다
3. 동일 값 무시: `Object.is`로 비교해서 같은 값이면 불필요한 재실행을 방지합니다

더 나아가기

실제 프레임워크는 여기에 `createMemo`(파생 값), 배치 업데이트, effect 정리(cleanup), 순환 의존성 감지 등을 추가합니다. 하지만 핵심 아이디어는 이 30줄 안에 다 들어있습니다.
> 💡 이 패턴은 Observer 패턴의 진화형입니다. 구독을 명시적으로 하지 않아도 사용하는 것만으로 연결되는 것이 Signal의 마법입니다.

스펙 기반 분석 | 스폰서십 없음

통신사와 스마트폰 제조사는 「5G로 영화 한 편을 3초 만에」라고 광고한다. 이론상 최대 속도 20Gbps를 내세우며 세상이 바뀔 것처럼 말한다. 그런데 실제로 체감하고 있는가?

마케팅이 숨기는 것들

1. 이론 속도 ≠ 실사용 속도
OpenSignal(2025) 데이터 기준, 한국 5G 평균 다운로드 속도는 약 250~350Mbps 수준이다. 이론치 20Gbps의 2%도 안 된다. 이마저도 서울 도심 기지국 밀집 지역 기준이다.
2. 대부분의 시간은 LTE 폴백
5G 커버리지는 여전히 구멍이 많다. 실내, 지하철, 교외 지역에서는 자동으로 LTE로 전환된다. Ookla Speedtest 자체 보고서에 따르면 5G 단말이 실제로 5G에 연결된 시간 비율은 약 25~40% 수준에 불과하다.
3. 일상 앱에서 차이 없음
웹 브라우징, SNS, 메신저, 음악 스트리밍은 10~50Mbps면 충분하다. LTE도 평균 80~120Mbps를 제공하므로 체감 차이가 거의 없다. 차이를 느끼려면 수 GB 파일을 반복 다운로드해야 한다.
4. 배터리만 더 빨리 닳는다
5G 모뎀은 LTE 대비 전력 소모가 크다. 일부 사용자가 5G를 꺼두는 이유다.

결론

5G의 진짜 가치는 개인 체감 속도가 아니라 네트워크 용량 확대에 있다. 하지만 그건 광고 카피가 되지 못하니, 제조사는 여전히 현실과 동떨어진 이론 속도를 전면에 내세운다. 요금제 차이가 크다면, 지금 당장 LTE로 전환해도 대부분의 사용자는 차이를 느끼지 못할 것이다.

왜 Observable인가?

RxJS의 핵심인 Observable 패턴은 시간에 따라 발생하는 값들의 스트림을 다룹니다. 클릭, API 응답, 타이머 등 비동기 이벤트를 일관된 방식으로 처리할 수 있습니다.

구현

```js
class Observable {
constructor(subscribeFn) {
this._subscribeFn = subscribeFn;
}
subscribe(observer) {
// observer가 함수면 next로 감싸기
const obs = typeof observer === 'function'
? { next: observer, error: () => {}, complete: () => {} }
: { next: observer.next || (() => {}),
error: observer.error || (() => {}),
complete: observer.complete || (() => {}) };
let unsubscribed = false;
this._subscribeFn({
next: (val) => !unsubscribed && obs.next(val),
error: (err) => !unsubscribed && obs.error(err),
complete: () => !unsubscribed && obs.complete(),
});
return { unsubscribe: () => { unsubscribed = true; } };
}
map(fn) {
return new Observable((observer) => {
this.subscribe({
next: (val) => observer.next(fn(val)),
error: (err) => observer.error(err),
complete: () => observer.complete(),
});
});
}
filter(fn) {
return new Observable((observer) => {
this.subscribe({
next: (val) => fn(val) && observer.next(val),
error: (err) => observer.error(err),
complete: () => observer.complete(),
});
});
}
}
```

사용 예시

```js
const numbers$ = new Observable((observer) => {
[1, 2, 3, 4, 5].forEach((n) => observer.next(n));
observer.complete();
});
numbers$
.filter((n) => n % 2 === 1) // 홀수만
.map((n) => n * 10) // 10배
.subscribe({
next: (val) => console.log(val), // 10, 30, 50
complete: () => console.log('완료!'),
});
```

핵심 포인트

| 개념 | 설명 |
|------|------|
| Lazy | `subscribe()` 호출 전까지 실행되지 않음 |
| Unsubscribe | 구독 해제로 메모리 누수 방지 |
| Chainable | `map`, `filter` 등 연산자를 체이닝 |
Promise가 단일 비동기 값이라면, Observable은 여러 값의 스트림입니다. 이 차이를 이해하면 RxJS를 훨씬 쉽게 쓸 수 있습니다.

스펙 기반 분석 | 스폰서십 없음

스마트폰 스펙시트에 「8K 30fps 비디오 촬영」이 당당히 올라온 지 몇 년이 지났다. 그런데 실제로 8K로 촬영하는 사용자는 거의 없다. 이유는 단순하다 — 쓸 수 없는 기능이기 때문이다.

1. 발열 제한: 5분의 벽

대부분의 플래그십 스마트폰은 8K 촬영 시 3~5분 내에 발열 경고가 뜨며 강제 중단된다. AP(Snapdragon 8 Elite, Dimensity 9400 등)의 ISP가 8K 디코딩을 지원하는 것과, 열 설계가 이를 지속적으로 감당하는 것은 완전히 다른 문제다.

2. 파일 크기: 1분에 600MB

8K 30fps 영상은 분당 약 500~700MB를 소모한다(코덱·비트레이트에 따라 상이). 256GB 모델이라도 실제 가용 용량을 고려하면 연속 촬영 시간이 극히 제한된다.

3. 볼 화면이 없다

2026년 현재에도 8K 디스플레이 보급률은 극히 낮다. YouTube 8K 스트리밍조차 대역폭 문제로 대부분의 환경에서 실질적으로 불가능하다. 결국 8K 영상은 4K로 다운스케일되어 소비된다.

4. 후보정 불가

8K RAW 영상을 모바일에서 편집하는 것은 사실상 불가능하고, 데스크톱에서도 상당한 하드웨어를 요구한다. 일반 사용자가 활용할 수 있는 워크플로가 존재하지 않는다.

결론

8K 촬영은 스펙시트를 채우기 위한 체크박스 기능이다. 실사용에서는 4K 60fps가 화질·안정성·활용도 모든 면에서 우위에 있다. 구매 결정 시 8K 지원 여부에 가중치를 두는 것은 무의미하다. 제조사가 강조해야 할 것은 해상도 숫자가 아니라 4K에서의 HDR 품질, 손떨림 보정 성능, 장시간 촬영 안정성이다.
> 출처: 발열 테스트 및 파일 크기 수치는 GSMArena, Tom's Guide 등 주요 리뷰 매체의 공개 벤치마크 기준. 가격은 각 제조사 출시가 기준이며 변동될 수 있음.

Debounce란?

연속된 호출 중 마지막 호출만 실행하는 패턴입니다. 검색 입력창의 자동완성, 윈도우 리사이즈 이벤트 처리 등에 필수적으로 쓰입니다.
Throttle이 "일정 간격마다 실행"이라면, Debounce는 "조용해진 후 실행"입니다.

직접 구현하기

```javascript
function debounce(fn, delay) {
let timer = null;
return function (...args) {
clearTimeout(timer);
timer = setTimeout(() => {
fn.apply(this, args);
}, delay);
};
}
```
핵심은 단 한 줄, `clearTimeout(timer)`입니다. 새 호출이 들어올 때마다 이전 타이머를 취소하고 다시 시작합니다.

실전 예제: 검색 입력

```javascript
const search = debounce((query) => {
console.log(`API 호출: ${query}`);
}, 300);
search('R'); // ❌ 취소됨
search('Re'); // ❌ 취소됨
search('React'); // ✅ 300ms 후 실행
```

한 단계 더: leading 옵션

첫 호출을 즉시 실행하고 싶을 때가 있습니다.
```javascript
function debounce(fn, delay, { leading = false } = {}) {
let timer = null;
return function (...args) {
const isFirst = timer === null;
clearTimeout(timer);
if (leading && isFirst) {
fn.apply(this, args);
}
timer = setTimeout(() => {
if (!leading) fn.apply(this, args);
timer = null;
}, delay);
};
}
```
`leading: true`면 첫 클릭은 바로 실행되고, 연타는 무시됩니다. 버튼 중복 클릭 방지에 딱 맞는 패턴이죠.

핵심 정리

| 개념 | Throttle | Debounce |
|------|----------|----------|
| 실행 시점 | 일정 간격마다 | 마지막 호출 후 |
| 비유 | 엘리베이터 출발 주기 | 엘리베이터 문 닫힘 대기 |
| 용도 | 스크롤, 드래그 | 검색 입력, 리사이즈 |
> 📎 [Lodash debounce 구현](https://lodash.com/docs/4.17.15#debounce)을 참고하면 `cancel`, `flush`, `maxWait` 같은 고급 옵션도 확인할 수 있습니다.

스펙 기반 분석 | 스폰서십 없음

스마트폰 카메라 스펙 경쟁의 최전선에 메가픽셀 숫자가 있다. 200MP, 심지어 그 이상을 내세우지만, 실제로 대부분의 사용자가 촬영하는 사진은 12MP 또는 16MP로 픽셀 비닝된 결과물이다.

왜 200MP ≠ 더 좋은 사진인가

1. 픽셀 비닝이 기본값이다. 200MP 센서는 16-in-1 비닝을 거쳐 12.5MP 사진을 출력한다. 제조사 기본 촬영 모드에서 200MP 풀 해상도를 쓰는 경우는 거의 없다.
2. 개별 픽셀 크기가 작다. 1/1.3" 센서에 200MP를 우겨넣으면 개별 픽셀은 약 0.56μm. 같은 센서에 50MP를 넣으면 1.12μm로 광량 수집 능력이 4배 차이 난다(DXOMARK 기준).
3. 저조도에서 역전된다. 픽셀이 작을수록 노이즈가 증가한다. 결국 비닝 후에도 대형 픽셀 센서 대비 디테일과 다이내믹 레인지에서 밀리는 경우가 발생한다.
4. 파일 크기와 처리 속도 문제. 풀 200MP 촬영 시 한 장당 50MB 이상. 연사 속도 저하, 저장 공간 압박, 공유 시 리사이즈 불가피.

실제로 중요한 것

센서 물리적 크기(1/1.3" vs 1/1.56")

ISP와 컴퓨테이셔널 포토그래피 알고리즘 품질

조리개 값(f/1.7 vs f/1.9)

OIS 및 센서 시프트 손떨림 보정 유무

메가픽셀 숫자는 마케팅에서 가장 직관적으로 "크면 좋다"는 인식을 심어주는 지표다. 하지만 실제 화질을 결정하는 변수는 센서 크기, 렌즈 광학 품질, 소프트웨어 처리 능력의 종합적 결과다. 200MP라는 숫자에 현혹되기 전에, 동일 조건 비교 샘플을 확인하는 것이 현명하다.
> 가격은 출시가 기준이며 변동될 수 있습니다. 벤치마크 수치 출처: DXOMARK, GSMArena.

Curry란?

`curry(fn)`은 여러 인자를 받는 함수를 인자를 하나씩(또는 부분적으로) 넘길 수 있는 함수로 변환합니다. 인자가 모두 모이면 원래 함수가 실행됩니다.
```js
const add = (a, b, c) => a + b + c;
const curriedAdd = curry(add);
curriedAdd(1)(2)(3); // 6
curriedAdd(1, 2)(3); // 6 — 부분 적용도 OK
curriedAdd(1)(2, 3); // 6
```

구현

```js
function curry(fn) {
return function curried(...args) {
if (args.length >= fn.length) {
return fn.apply(this, args);
}
return function (...nextArgs) {
return curried.apply(this, [...args, ...nextArgs]);
};
};
}
```
핵심 로직:
1. 지금까지 모인 `args`가 원래 함수의 매개변수 수(`fn.length`) 이상이면 실행
2. 부족하면 새 함수를 반환해서 나머지 인자를 기다림

실전 활용

```js
// 이벤트 로거 조립
const log = curry((level, module, msg) =>
console.log(`[${level}] ${module}: ${msg}`)
);
const warn = log('WARN'); // level 고정
const authWarn = warn('Auth'); // module까지 고정
authWarn('Token expired'); // [WARN] Auth: Token expired
```
앞서 만든 `pipe`와 결합하면 인자가 고정된 함수들을 파이프라인으로 연결할 수 있어 강력합니다.

주의할 점

`fn.length`는 기본값·나머지 매개변수를 세지 않습니다. `(a, b = 0) => {}` → `length`는 1입니다.

가변 인자 함수에는 적합하지 않으니, 고정 인자 함수에 사용하세요.

> 📎 [Lodash `_.curry` 문서](https://lodash.com/docs/4.17.15#curry)

스펙 기반 분석 (스폰서십 없음)

스마트폰 제조사들은 「하루 종일 사용 가능한 배터리」를 자랑합니다. 5000mAh, 6000mAh 숫자가 점점 커지는데, 왜 여전히 충전기를 들고 다녀야 할까요?

제조사 테스트의 비밀

제조사가 공개하는 배터리 수명은 극도로 통제된 환경에서 측정됩니다.

화면 밝기 150nits 고정 (실외에서는 최소 500nits 이상 필요)

Wi-Fi만 연결, 5G 비활성화

위치 서비스, 백그라운드 앱 동기화 OFF

동영상 연속 재생이라는 비현실적 시나리오

실제 사용 패턴 — SNS 스크롤, 카메라 촬영, 내비게이션, 5G 데이터 — 에서는 공칭 수명의 40~60% 수준이 현실입니다(GSMArena 종합 사용 테스트 기준).

용량만 보면 안 되는 이유

| 요소 | 영향 |
|------|------|
| AP 공정(3nm vs 4nm) | 동일 작업 시 소비전력 최대 25% 차이 |
| 디스플레이 기술(LTPO vs 일반 OLED) | 유휴 시 전력 소모 2~3배 차이 |
| 소프트웨어 최적화 | 같은 칩셋도 제조사별 SOT 1~2시간 차이 |
6000mAh 배터리라도 전력 관리가 엉망이면 4000mAh 최적화 기기보다 먼저 꺼집니다.

실질적 기준

제조사 공칭 시간 대신 GSMArena Endurance Rating 또는 Notebookcheck Wi-Fi 배터리 테스트 같은 독립 벤치마크를 확인하세요. 출시가 기준 가격은 변동될 수 있으며, 배터리 수명은 사용 패턴에 따라 크게 달라집니다.
mAh 숫자가 아니라, 독립 테스트의 SOT(Screen On Time)가 진짜 배터리 성능입니다.

스펙 기반 분석 | 스폰서십 없음

스마트폰 박스에 적힌 「45W 초고속 충전」을 보고 구매했다면, 실제 충전 경험에서 실망했을 가능성이 높다. 그 이유를 분석한다.

최대값 ≠ 평균값

45W는 배터리 잔량 0~15% 구간에서 순간적으로 도달하는 피크 전력이다. 배터리가 50%를 넘으면 발열 보호와 셀 수명 관리를 위해 전력이 급격히 낮아진다. GSMArena 실측 데이터 기준, 45W 충전기를 사용해도 평균 충전 전력은 25~30W 수준에 머무르는 경우가 대부분이다.

충전기가 별매인 함정

45W 충전을 지원한다면서 기본 제공 충전기는 15W 또는 25W인 경우가 많다. 별도 구매해야 하는 정품 45W 충전기 가격은 3~5만 원대. 케이블 규격(3A vs 5A)까지 맞춰야 정상 작동한다.

발열이 만드는 악순환

고속 충전 시 발열이 심해지면 기기가 스스로 충전 속도를 스로틀링한다. 여름철이나 케이스를 장착한 상태에서는 최대 전력의 60~70%만 사용되는 것이 현실이다.

배터리 수명이라는 대가

높은 와트로 반복 충전하면 배터리 사이클 열화가 가속된다. 실제로 제조사들이 80% 충전 제한 기능을 도입한 것 자체가, 고속 충전과 배터리 수명이 트레이드오프 관계임을 인정한 셈이다.

결론

충전 속도를 비교할 때는 W 수치가 아니라 '0→100% 완충 시간'과 '0→50% 도달 시간'을 확인해야 한다. 마케팅이 말하는 45W는 최고 순간 속도일 뿐, 당신의 일상 충전 속도가 아니다.

스펙시트의 3000nits, 당신의 눈은 속고 있다

2025년 이후 출시되는 플래그십 스마트폰들은 "피크 밝기 3000nits", 심지어 "4000nits"를 내세운다. 숫자만 보면 매년 태양에 한 발짝 더 다가가는 것 같지만, 실제 사용 환경에서 체감하는 밝기는 스펙시트와 전혀 다르다.

피크 밝기의 함정

제조사가 말하는 "피크 밝기"는 대부분 HDR 콘텐츠 재생 시, 화면의 극히 일부 영역(1~5%)에서, 수 초간 달성되는 수치다. 전체 화면(APL 100%) 밝기는 이 수치의 30~40%에 불과한 경우가 많다.
| 측정 조건 | 스펙시트 표기 | 실측 범위 |
|---|---|---|
| 1% APL (HDR 피크) | 3000nits | 2500~3200nits |
| 50% APL (일반 사용) | 미표기 | 900~1200nits |
| 100% APL (전체 흰색) | 미표기 | 700~1000nits |
*출처: DisplayMate, DXOMARK 디스플레이 테스트 기준*

왜 이런 일이 벌어지는가

OLED 패널은 구조적으로 전체 화면이 동시에 최대 밝기를 낼 수 없다. 전력과 발열 한계 때문에 밝은 영역이 넓어질수록 자동으로 밝기를 제한한다(ABL, Auto Brightness Limiter). 즉 "3000nits"는 동전 크기만 한 하이라이트에서만 존재하는 숫자다.

실제로 중요한 것

야외 가시성을 결정하는 건 피크 밝기가 아니라 전체 화면 밝기(Full-screen sustained brightness)다. 이 수치는 제조사가 거의 공개하지 않는다. 리뷰어 실측 데이터를 확인하는 것이 유일한 방법이다.
> 스펙 기반 분석입니다. 본 글은 스폰서십 없이 작성되었습니다.
> 가격은 출시가 기준이며 변동될 수 있습니다.

왜 Promise를 직접 만들어볼까?

Promise는 비동기 JavaScript의 근간입니다. 직접 구현하면 `then` 체이닝, 상태 전이, 마이크로태스크 큐의 동작 원리를 깊이 이해할 수 있습니다.

구현

```js
class MyPromise {
#state = 'pending';
#value = undefined;
#callbacks = [];
constructor(executor) {
const resolve = (value) => this.#transition('fulfilled', value);
const reject = (reason) => this.#transition('rejected', reason);
try {
executor(resolve, reject);
} catch (err) {
reject(err);
}
}
#transition(state, value) {
if (this.#state !== 'pending') return; // 상태는 한 번만 변경
this.#state = state;
this.#value = value;
queueMicrotask(() => this.#callbacks.forEach((cb) => cb()));
}
then(onFulfilled, onRejected) {
return new MyPromise((resolve, reject) => {
const handle = () => {
const handler = this.#state === 'fulfilled' ? onFulfilled : onRejected;
const fallback = this.#state === 'fulfilled' ? resolve : reject;
if (typeof handler !== 'function') return fallback(this.#value);
try {
const result = handler(this.#value);
result instanceof MyPromise
? result.then(resolve, reject)
: resolve(result);
} catch (err) {
reject(err);
}
};
this.#state === 'pending'
? this.#callbacks.push(handle)
: queueMicrotask(handle);
};
}
catch(onRejected) {
return this.then(null, onRejected);
}
}
```

사용 예시

```js
new MyPromise((resolve) => setTimeout(() => resolve(1), 100))
.then((v) => v + 1)
.then((v) => console.log(v)); // 2
```

핵심 포인트

상태 불변성: `pending` → `fulfilled` 또는 `rejected`로 단 한 번만 전이됩니다.

`queueMicrotask`: 콜백을 비동기로 실행해 네이티브 Promise와 동일한 타이밍을 보장합니다.

체이닝: `then`이 새 Promise를 반환하므로 값을 계속 이어받을 수 있습니다.

> 📖 [MDN — Promise](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise) · [Promises/A+ 스펙](https://promisesaplus.com/)

스펙 기반 분석 | 스폰서십 없음

2025년 플래그십 스마트폰들이 앞다투어 16GB, 심지어 24GB RAM을 탑재하고 있다. 마치 RAM이 클수록 빠른 폰인 것처럼. 하지만 실제 사용에서 8GB 모델과 체감 차이를 느끼는 사람은 거의 없다.

마케팅이 말하지 않는 것들

1. OS가 알아서 관리한다
Android와 iOS 모두 메모리를 적극적으로 관리한다. 사용하지 않는 앱은 자동으로 메모리에서 해제되고, 필요할 때 다시 로드된다. 16GB를 꽉 채워 쓰는 시나리오 자체가 일반 사용자에게는 발생하지 않는다.
2. 앱 유지 수의 함정
RAM이 크면 백그라운드 앱을 더 많이 유지한다고 홍보하지만, Geekbench 및 AnandTech 테스트 기준 12GB 이상에서 앱 리로드 빈도 차이는 5% 미만이다. 대부분의 사용자는 동시에 3~5개 앱만 전환한다.
3. 진짜 병목은 RAM이 아니다
UFS 스토리지 속도, AP의 캐시 구조, 소프트웨어 최적화가 체감 성능에 훨씬 큰 영향을 미친다. 삼성 One UI와 Pixel의 체감 속도 차이는 RAM 용량이 아니라 소프트웨어 최적화 수준에서 갈린다.
4. 실제로 16GB가 필요한 사람
고사양 게임을 하면서 동시에 화면 녹화 + 스트리밍을 하는 극소수 파워유저 정도다.

결론

제조사가 RAM 숫자를 키우는 이유는 단순하다. 스펙 시트에서 숫자가 크면 이긴다. 하지만 8GB면 충분하고, 12GB면 넉넉하다. 16GB 이상은 마케팅 도구일 뿐, 구매 결정 요인이 되어서는 안 된다.
> 벤치마크 출처: Geekbench Memory Test, AnandTech RAM Management Comparison (2025)
> 가격은 출시가 기준이며 변동 가능