Medium
지시문(directives)과 플랫폼의 경계
'use client', 'use server', 'use cache' 는 표준 자바스크립트가 아니다. 프레임워크가 *언어처럼 보이는 문법* 으로 동작을 끼워 넣으면 학습/툴링/이식성 비용이 누적된다. 함수 API 가 더 정직하다.
핵심 요약
지시문은 (1) 파일 최상단 문자열이라 언어 기능처럼 보이고 (2) import 가 없어 제공자/버전 정보가 사라지며 (3) 옵션을 자연스럽게 담을 곳이 없다. 함수 API 는 같은 일을 명시적인 import + 함수 인자 로 표현하므로 출처·버전·타입·테스트 가능성을 모두 얻는다. 'use server' 처럼 번들러 간 합의가 필요한 최소 신호 만 지시문으로 두고, 옵션이 있는 모든 동작 은 함수 API 로 가는 것이 책임 있는 설계다. 네임스페이스('use next.js cache') 는 인간 가독성만 약간 개선할 뿐 플랫폼처럼 보이는 문제 를 풀지 못한다. 진짜 공유 프리미티브가 필요하다면 프레임워크 간 공동 명세 + TC39 제안 으로 풀어야 한다.
지시문을 '언어 기능' 으로 받아들이는 시각에서 '프레임워크 동작을 문자열로 위장한 import' 로 시각을 바꾼다. 출처(어떤 패키지가 제공하는가), 버전(어느 시점의 의미인가), 옵션(인자/설정) 을 자연스럽게 담는 것은 지시문이 아니라 import 기반 함수 API 다. 지시문은 드물고, 안정적이고, 표준화된 곳에만 — 'use strict' 처럼.
RSC 시대에 'use client'/'use server' 가 익숙해지면서 지시문이 자바스크립트의 한 부분 이라는 오해가 빠르게 퍼지고 있다.
- 표준이 아니라 각 번들러의 합의 일 뿐이라 의미 해석이 프레임워크마다 다를 위험
- import 가 없으니 어떤 패키지의 동작인지 가 코드만 봐선 보이지 않음
- 옵션이 필요해지면
'use cache:remote'같은 변형 문자열 이나cacheLife()같은 지시문-인접 API 가 따라붙음 → 결국 두 시스템을 동시에 다루게 됨 - 마이그레이션 비용이 import 교체 보다 훨씬 크다
이 관점은 단순한 미감 문제가 아니다. 언어와 프레임워크의 경계 를 어디에 그을지를 결정한다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
import 가 없으면 *출처/버전* 이 사라진다
import 는 단순한 코드 가져오기가 아니라 출처·버전·탐색 가능성 의 메타데이터다. 지시문은 이 셋을 모두 잃는다.
// ❌ 지시문 - 누가 제공하는지 알 수 없음
'use cache';
const data = () => fetch('...');
// ✅ 함수 API - 출처/버전/옵션 모두 import 에 담김
import { cache } from 'next/cache';
export const data = cache(() => fetch('...'), { ttl: 60 });
버전을 바꾸면 npm 의 의존성 으로 추적되지만, 지시문 의미가 바뀌면 프레임워크 changelog 를 읽어야 안다.
'프레임워크 문서에 적혀 있으니 충분하다'. 코드 검색/IDE 점프/타입 체크의 1차 신호는 import 인데, 지시문은 그 신호를 막는다.
옵션이 필요해지는 순간 지시문은 깨진다
지시문은 불리언 에 가까운 신호. 캐시 전략·메서드·미들웨어·인증 같은 옵션을 자연스럽게 담을 자리가 없다.
// ❌ 변형 문자열로 옵션 흉내
'use cache:remote';
// ❌ 지시문 + 인접 함수의 병행 사용
'use cache';
import { cacheLife } from 'next/cache';
cacheLife(60);
// ✅ 처음부터 함수
import { cache } from 'next/cache';
export const fn = cache(() => '...', { strategy: 'remote', ttl: 60 });
옵션이 한 개라도 추가될 가능성이 있다면 이미 함수 API 로 가야 한다.
'지금은 옵션이 없으니 지시문이 더 짧다'. 1년 뒤 'use cache:remote' 류로 옵션이 폭발하면 마이그레이션이 비싸진다.
공유 프리미티브가 필요하면 *명세*, 벤더 프리픽스가 아니다
여러 프레임워크가 같은 지시문을 채택하면 문법은 공유 하지만 의미는 제각각 인 최악의 상태가 된다.
| 접근 | 위험 |
|---|---|
| 같은 지시문, 다른 의미 | 겉보기 이식성 만 있고 동작이 달라 디버깅 지옥 |
네임스페이스 ('use next.js cache') | 가독성만 개선, 출처/버전/툴링 문제 그대로 |
| 공동 명세 + TC39 제안 | 진짜 표준화 — 시간이 걸리지만 옳은 방향 |
| 프레임워크 함수 API + 호환 어댑터 | 즉시 가능한 현실적 해결책 |
과거 데코레이터처럼 비표준이 사실상 표준이 됐다가 TC39 가 다른 방향으로 갈 때 의 마이그레이션 비용을 기억하자.
'다 같이 쓰면 표준이 된다'. 명세 없는 합의는 문법만 공유 하고 의미는 점점 갈라진다.
읽는 순서
- 1이론
TC39 의 use strict 명세와 React docs 의 use client/use server 가이드를 비교 정리. 표준화의 차이가 무엇인지 적는다.
- 2구현
Vite 플러그인을 작성해
'use cache'같은 지시문이 있는 모듈에 메타데이터를 주입해보고, 같은 일을 import 기반 HOC 로 다시 구현한다. 디버깅 경험 비교. - 3실무
팀의 빌드 파이프라인에 지시문 사용 위치 를 주기적으로 lint 하는 규칙을 추가, 의도하지 않은 확산을 막는다.
- 4설명
'왜 모든 동작을 지시문으로 만들지 않는가' 5분 발표. 축: 출처/버전, 옵션 공간, 마이그레이션 비용, 명세 부재.
면접 연결 질문
[감점 답변] '전부 똑같이 나쁘다'. [좋은 답변] 전자는 번들러가 코드를 어디에 두는지 만 결정하는 불리언 경계 신호 라 옵션이 본질적으로 없다. 후자는 전략·TTL·태그·무효화 같은 옵션이 처음부터 필요하므로 함수가 자연스럽다. 옵션 공간의 크기 가 지시문/함수의 갈림길이다.
[감점 답변] '멋져 보이니 찬성'. [좋은 답변] 반대 근거: 출처·버전이 사라지고 IDE 가 그 의미 를 모르며, 마이그레이션이 어렵고, 다른 프레임워크와 의미가 충돌할 수 있음. 같은 기능을 import { myCache } from '@org/cache' 로 제공하면 툴링·테스트·타입 모두 표준 메커니즘에 올라탄다.
자기 점검
'프레임워크가 권장하면 그게 정답'. 권장 방식과 책임 있는 추상화 는 다른 문제다.