
파레토 법칙을 설명하는 글은 쓰지 않겠다. 검색하면 수천 개 나온다. 대신 이 글은 내가 직접 숫자를 뒤져보고 "진짜 이러네"하고 놀란 순간들의 기록이다. 이론이 아니라 데이터다.

## 버그 트래커를 열었더니

시작은 팀 리드의 한마디였다. 작년 결제 시스템 리뉴얼 프로젝트가 끝나고 스프린트 회고 때, 팀 리드가 말했다. "이번에 버그가 어디서 많이 나왔는지 한번 정리해봐. QA 리포트 보면 될 거야."

단순한 숙제라고 생각하고 Jira에서 버그 티켓을 전부 뽑았다. 총 34개. 하나하나 어느 모듈에서 발생한 건지 태깅했다.

결과를 스프레드시트에 정리했을 때, 숫자가 눈에 띄었다.

- 결제 플로우 (카드 결제, 간편결제, 포인트 적용): **14개**
- 폼 유효성 검사 (카드 번호, CVC, 유효기간, 주소): **8개**
- 장바구니 상태 동기화: **3개**
- 상품 리스트 렌더링: **4개**
- 주문 내역: **2개**
- 기타 (헤더, 푸터, 404 등): **3개**

결제 플로우 + 폼 유효성 검사 + 장바구니. 이 세 모듈에서 **25개, 전체의 73%**가 나왔다. 코드베이스에서 이 세 모듈이 차지하는 비중은 파일 수 기준으로 약 28%. 28%의 코드가 73%의 버그를 만들고 있었다.

왜 이 세 곳에 버그가 몰릴까? 공통점이 있었다. **상태 전이가 복잡한 모듈이다.** 결제 플로우는 사용자 입력 -> 유효성 검증 -> API 호출 -> PG사 응답 -> 성공/실패 분기 -> 에러 복구까지, 상태 전이가 12가지가 넘는다. 폼 유효성 검사는 입력값의 경계값, 특수문자, 포맷 체크, 실시간 피드백, 포커스/블러 시점의 로직 분기까지 엣지 케이스가 셀 수 없다. 장바구니는 서버 상태와 클라이언트 상태의 동기화 문제.

반면에 상품 리스트는 데이터를 받아서 보여주는 게 전부다. 상태 전이가 거의 없다. 그러니 버그도 적다.

이 데이터를 스프린트 회고에서 공유했더니 팀 리드가 말했다. "그러면 다음 프로젝트에서는 이 세 모듈에 테스트를 더 두껍게 쓰자." 단순한 분석이었는데 팀의 테스트 전략이 바뀌었다.

## 테스트 전략이 바뀐 방법

이 분석 전에는 테스트를 '고르게' 쓰고 있었다. 커버리지 80%를 목표로, 버튼 컴포넌트에도 테스트를 쓰고, 결제 로직에도 테스트를 쓰고, 같은 비중으로.

Kent C. Dodds가 쓴 글에서 비슷한 이야기를 읽은 적이 있다. 그가 만든 "Testing Trophy"라는 프레임워크가 있다. 전통적인 테스팅 피라미드(유닛 테스트 많이, E2E 테스트 적게)와 다르게, **통합 테스트(integration test)에 가장 많은 비중을 두라**는 거다. 이유가 명쾌하다. "When you mock something, you're removing all confidence in the integration between what you're testing and what's being mocked." 뭔가를 목(mock)하는 순간, 테스트 대상과 목 사이의 통합에 대한 신뢰가 사라진다는 말이다.

그리고 또 하나. Dodds는 커버리지 100%를 추구하지 말라고 한다. "You get diminishing returns on your tests as the coverage increases much beyond 70%." 70%를 넘어가면 추가 테스트의 효율이 급격히 떨어진다는 거다. 버그가 안 나는 단순한 코드에까지 테스트를 쓰는 건, 파레토 법칙의 반대편에 시간을 쓰는 거다.

이걸 팀에 적용했다. 결제 플로우, 폼 유효성 검사, 장바구니 동기화 모듈에는 통합 테스트를 두껍게 썼다. 실제 사용자 시나리오를 기반으로, 상태 전이의 경로를 하나하나 테스트했다. 카드 결제 성공, 실패, 타임아웃, 네트워크 에러, 유효하지 않은 카드, 잔액 부족, 포인트 부족 등. 테스트 케이스가 40개가 넘었다.

반면에 상품 리스트, 헤더, 푸터 같은 단순한 컴포넌트는 스냅샷 테스트나 Storybook 시각적 확인 정도로 가볍게 갔다.

결과? 다음 프로젝트(작년 하반기)의 QA 기간에 결제 관련 버그가 14개에서 **3개**로 줄었다. 같은 수준의 복잡도를 가진 프로젝트였는데, 테스트를 '어디에' 집중했느냐가 달라진 거다. 전체 테스트 작성 시간은 비슷했다. 분배만 바꿨다.

## GA 데이터를 열었더니

두 번째 발견은 프로덕트 쪽이다.

작년에 어드민 대시보드를 만들 때, 기획서에 기능이 15개 있었다. 실시간 매출 현황, 주문 검색, 환불 처리, 일별/주별/월별 통계, 사용자 관리, 상품 등록/수정, 쿠폰 관리, 리뷰 관리, 배송 추적, 알림 설정, 정산 내역, 리포트 다운로드, 로그 조회, 권한 설정, 시스템 설정. 기획서만 50페이지.

2개월에 걸쳐 전부 만들었다. 디자인대로, 기획서대로. 배포하고 한 달 뒤에 GA 데이터를 처음으로 뽑아봤다.

사용자가 매일 쓰는 기능은 **2개**였다. 실시간 매출 현황과 주문 검색. 이 두 페이지의 일일 활성 사용자 수가 전체의 **61%**를 차지했다. 환불 처리와 일별 통계를 포함하면 4개 기능이 전체 사용량의 **89%**.

나머지 11개 기능의 사용량을 보면서 좀 허탈했다. 시스템 설정 페이지는 한 달 동안 접속한 사람이 3명이었다. 초기 설정할 때만 들어간 거겠지. 리포트 다운로드는 월 7회. 로그 조회는 월 12회. 내가 권한 설정 페이지를 만드는 데 3일을 쓴 건데, 그 페이지를 월 5명이 쓴다.

Addy Osmani가 웹 퍼포먼스에 대해 쓴 글에서 비슷한 프레임을 본 적이 있다. 퍼포먼스 버짓(performance budget) 이야기인데, 핵심은 이거다. "Deciding a page can't exceed 500kB when mockups contain three carousels and high-resolution images isn't effective." 모든 페이지를 동일하게 최적화하는 게 아니라, 사용자에게 중요한 경로(critical path)에 집중하라는 거다. 비핵심 기능은 크리티컬 패스에서 아예 빼버리는 게, 전체를 중간 정도로 최적화하는 것보다 낫다.

어드민 대시보드에도 같은 원리가 적용된다. 15개 기능을 모두 동일한 퀄리티로 만드는 것보다, 매출 현황과 주문 검색 2개를 정말 잘 만들었으면 더 큰 가치를 줬을 거다. 매출 현황 페이지의 로딩 속도를 0.5초 줄이는 게, 월 5명이 쓰는 권한 설정 페이지를 만드는 것보다 임팩트가 크다.

이 경험 이후로 기획 단계에서 질문을 하게 됐다. "이 기능을 쓸 사용자가 몇 명일까요?" "이게 없으면 사용자가 어떤 불편을 겪을까요?" PM이 싫어할 수 있는 질문이다. 기획서에 넣은 건 다 이유가 있을 테니까. 근데 이 질문이 때로는 우선순위를 바꾸기도 했다. "그러고 보니 이건 다음 분기에 넣어도 될 것 같네요."

## 번들 사이즈를 분석했더니

세 번째 발견은 프론트엔드 퍼포먼스에서였다.

프로젝트의 초기 로딩 속도가 느려서 원인을 찾고 있었다. Webpack Bundle Analyzer를 돌렸다. 전체 번들 사이즈 1.2MB. 어디서 용량을 잡아먹고 있나?

트리맵을 보는 순간 바로 보였다. **moment.js가 전체의 28%를 차지하고 있었다.** 그 다음이 lodash 15%, 차트 라이브러리 12%. 이 세 개가 전체 번들의 55%.

moment.js는 날짜 포맷팅에 쓰고 있었는데, 실제로 사용하는 함수는 `format()`과 `diff()` 두 개뿐이었다. 두 개의 함수를 위해 전체 라이브러리(280KB gzipped)를 로딩하고 있었다. lodash도 마찬가지. `debounce`, `throttle`, `cloneDeep` 세 개를 쓰는데 전체를 임포트하고 있었다.

moment.js를 date-fns로 교체하고 (트리 셰이킹 가능), lodash를 개별 함수 임포트로 바꿨다. 차트 라이브러리는 dynamic import로 필요할 때만 로드하게 변경.

결과: 번들 사이즈 1.2MB -> **520KB.** 57% 감소. 초기 로딩 시간 3.1초 -> 1.4초.

Osmani가 퍼포먼스 버짓 글에서 쓴 표현이 딱 맞는 상황이었다. "Performance budgets are not just thresholds. Much like a financial budget, they're something consciously spent." 퍼포먼스 버짓은 재정 예산과 같다. 한정된 용량을 '어디에 쓸 것인가'의 문제다. 280KB를 날짜 포맷팅 하나에 쓸 것인가, 아니면 사용자에게 의미 있는 기능에 쓸 것인가.

번들 분석에서도 80/20이 작동했다. 전체 의존성의 약 20%(3개 라이브러리)가 번들 사이즈의 55%를 차지하고 있었다. 이 3개만 최적화해도 전체 사이즈가 절반 이하로 줄었다. 나머지 수십 개의 라이브러리를 하나하나 최적화하는 것보다, 큰 3개를 손대는 게 압도적으로 효율적이었다.

## 디버깅의 패턴

2년간의 프론트엔드 버그를 뜯어보면 또 비슷한 패턴이 나온다. 내가 겪은 버그의 대부분은 다섯 가지 카테고리에 속한다.

1. **상태 관리 문제** - 불필요한 리렌더링, stale closure, useEffect 의존성 배열 누락
2. **비동기 처리 문제** - race condition, 에러 핸들링 누락, 컴포넌트 언마운트 후 setState
3. **CSS 레이아웃 문제** - 반응형 깨짐, z-index 충돌, overflow
4. **API 응답 형식 불일치** - null/undefined 미처리, 옵셔널 필드 누락
5. **브라우저 호환성** - Safari에서만 안 되는 것들

체감상 85% 이상이 이 다섯 가지 안에 든다. 특히 1번(상태 관리)과 2번(비동기 처리)이 전체의 절반 이상이다.

이걸 알면 디버깅이 빨라진다. 버그 리포트가 들어오면 전체 코드를 훑는 대신, "상태 문제인가?" -> "비동기 문제인가?" -> "CSS인가?" 순서로 체크한다. 범인 후보를 5명으로 줄이고 시작하면 수사가 빠르다.

Kent C. Dodds가 테스트에 대해 쓴 철학과 연결된다. "Write tests. Not too many. Mostly integration." 테스트를 쓰되, 너무 많이 쓰지 말고, 대부분 통합 테스트로. 여기서 "Not too many"가 핵심이다. 모든 경우를 테스트하는 건 불가능하고 비효율적이다. 버그가 집중되는 영역(상태 관리, 비동기 처리)의 통합 테스트를 두껍게 쓰는 게, 모든 함수에 유닛 테스트를 쓰는 것보다 실제 버그를 잡는 확률이 높다.

## 시간의 80/20

가장 실용적인 발견은 시간에 대한 거다.

하루 동안 내 작업 로그를 분석해봤다. 가장 의미 있는 아웃풋이 나온 시간은 오전 10시~12시, 딱 2시간이었다. 이 시간에 핵심 코딩 작업의 대부분이 완성됐다. 나머지 6시간은 미팅, 코드 리뷰, 슬랙, Jira 정리, 자잘한 수정에 쓰였다. 중요하지 않은 일이라는 게 아니다. 근데 '핵심 가치를 만드는' 시간은 2시간이었다.

이걸 인식하면 그 2시간을 보호하게 된다. 아침에 가장 어려운 코딩 작업을 먼저 한다. 에너지가 높은 시간에 가장 중요한 일을 한다. 오후에 미팅이 몰려도 "오전에 핵심 작업은 끝냈으니까"라는 안정감이 있다.

코드 리뷰에서도 같은 원리를 쓴다. PR 전체를 동일한 강도로 리뷰하지 않는다. 비즈니스 로직이 들어있는 파일, 상태 관리가 복잡한 파일에 집중하고, 단순한 스타일 변경은 가볍게 본다. 리뷰 시간이 같아도 잡아내는 버그 수가 다르다.

## 사후 분석의 한계

주의할 점이 있다. 이 글에서 나온 숫자들은 전부 '사후' 분석이다. 버그가 어디서 나올지, 어떤 기능이 많이 쓰일지, 어떤 라이브러리가 번들을 잡아먹을지는 미리 알기 어렵다.

GA 데이터는 배포 후에야 나온다. 버그 분석은 QA 후에야 가능하다. 번들 분석도 빌드 후에야 보인다. "어디에 집중해야 하는가?"에 대한 답은 대부분 사전이 아니라 사후에 명확해진다.

그래서 80/20 사고방식의 진짜 가치는 예측이 아니라 **피드백 루프**다. 만들고, 측정하고, 집중점을 재조정한다. 첫 번째 프로젝트에서는 어디에 버그가 몰리는지 몰랐다. 분석하고 나서야 알았다. 두 번째 프로젝트에서는 그 정보를 바탕으로 테스트를 다르게 분배했다. 세 번째에서는 더 정밀해질 거다.

"20%만 하면 되잖아"라는 식으로 나머지 80%를 무시하면 안 된다. 시스템 설정 페이지를 월 5명이 쓰더라도, 그 5명에게는 100%의 문제다. 저빈도 기능이라고 퀄리티를 낮추는 건 다른 이야기다. 핵심은 '같은 시간이 있을 때 어디에 먼저 쓸 것인가'의 우선순위 문제이지, '나머지는 안 해도 된다'는 뜻이 아니다.

2년 동안 개발을 하면서 느낀 건, 모든 곳에 동일한 에너지를 쏟는 건 불가능하고 비효율적이라는 거다. 어디에 힘을 더 쓸지 판단하는 것도 실력이다. 그리고 그 판단의 가장 좋은 재료는 직감이 아니라 데이터다. 버그 트래커를 열어봐라. GA를 분석해봐라. 번들 분석기를 돌려봐라. 숫자가 어디에 집중해야 하는지 알려준다.



검색 인풋에 "react"를 타이핑하면 요청이 다섯 번 나간다. "r", "re", "rea", "reac", "react". 네트워크 상태에 따라 "rea"의 응답이 "react"보다 늦게 도착할 수 있다. 그러면 사용자는 "react"를 검색했는데 "rea"의 결과를 보게 된다.

이게 race condition이다. 그리고 AbortController가 이걸 해결한다.

## AbortController 기본

AbortController는 진행 중인 비동기 작업을 취소하는 웹 표준 API다.

```javascript
const controller = new AbortController();

fetch('/api/search?q=react', {
  signal: controller.signal,
});

// 요청을 취소하고 싶을 때
controller.abort();
```

`abort()`를 호출하면 해당 signal에 연결된 fetch가 `AbortError`를 던지며 중단된다. 브라우저가 실제로 네트워크 요청을 취소하기 때문에 대역폭도 절약된다.

## 패턴 1: 검색 자동완성의 race condition 방지

이전 요청을 새 요청이 시작될 때 취소하면 된다.

```typescript
function useSearch(query: string) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    if (!query) {
      setResults([]);
      return;
    }

    const controller = new AbortController();

    fetch(`/api/search?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    })
      .then((res) => res.json())
      .then(setResults)
      .catch((err) => {
        if (err.name !== 'AbortError') throw err;
        // AbortError는 의도적 취소이므로 무시
      });

    return () => controller.abort();
  }, [query]);

  return results;
}
```

`useEffect`의 cleanup 함수에서 `abort()`를 호출한다. `query`가 바뀔 때마다 이전 요청이 취소되고 새 요청만 살아남는다. "rea"의 응답이 "react"보다 늦게 도착하는 문제가 원천적으로 해결된다.

<Callout type="info">
`AbortError`는 정상적인 취소이므로 catch에서 걸러줘야 한다. 안 그러면 에러 모니터링에 불필요한 노이즈가 쌓인다.
</Callout>

## 패턴 2: 버튼 중복 클릭 방지

"저장" 버튼을 빠르게 두 번 클릭하면 같은 요청이 두 번 나간다. 데이터가 두 번 생성될 수 있다. 보통 버튼을 disable 시키는데, AbortController로도 처리할 수 있다.

```typescript
function useMutation<T>(mutationFn: (signal: AbortSignal) => Promise<T>) {
  const controllerRef = useRef<AbortController | null>(null);
  const [isPending, setIsPending] = useState(false);

  const mutate = useCallback(async () => {
    // 이전 요청이 진행 중이면 취소
    controllerRef.current?.abort();

    const controller = new AbortController();
    controllerRef.current = controller;
    setIsPending(true);

    try {
      const result = await mutationFn(controller.signal);
      return result;
    } catch (err) {
      if (err instanceof Error && err.name === 'AbortError') return;
      throw err;
    } finally {
      setIsPending(false);
    }
  }, [mutationFn]);

  return { mutate, isPending };
}
```

```typescript
// 사용
const { mutate: savePost, isPending } = useMutation((signal) =>
  fetch('/api/posts', {
    method: 'POST',
    body: JSON.stringify(postData),
    signal,
  })
);
```

두 번 클릭해도 첫 번째 요청이 취소되고 두 번째만 실행된다. 물론 서버 사이드 멱등성 처리도 필요하지만, 클라이언트에서 1차 방어를 하는 셈이다.

## 패턴 3: 타임아웃 구현

fetch에는 기본 타임아웃이 없다. `AbortSignal.timeout()`으로 간단하게 구현할 수 있다.

```typescript
// 5초 안에 응답이 없으면 취소
const response = await fetch('/api/data', {
  signal: AbortSignal.timeout(5000),
});
```

직접 구현할 필요 없이 한 줄이다. 수동으로 AbortController와 `setTimeout`을 조합하는 것보다 깔끔하다.

여러 조건을 조합하고 싶으면 `AbortSignal.any()`를 쓴다:

```typescript
const controller = new AbortController();

const response = await fetch('/api/data', {
  signal: AbortSignal.any([
    controller.signal,           // 수동 취소
    AbortSignal.timeout(5000),   // 5초 타임아웃
  ]),
});
```

사용자가 취소 버튼을 누르거나, 5초가 지나거나, 둘 중 하나라도 발생하면 요청이 취소된다.

## 패턴 4: 페이지 이동 시 진행 중인 요청 정리

SPA에서 페이지를 이동하면 이전 페이지의 컴포넌트가 언마운트된다. 그런데 진행 중이던 fetch는 그대로 살아있고, 응답이 도착하면 이미 없는 컴포넌트의 state를 업데이트하려고 한다.

React 18부터는 경고가 사라졌지만, 불필요한 네트워크 요청이 계속 진행되는 건 여전히 낭비다.

```typescript
function useData(url: string) {
  const [data, setData] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    fetch(url, { signal: controller.signal })
      .then((res) => res.json())
      .then(setData)
      .catch((err) => {
        if (err.name !== 'AbortError') throw err;
      });

    return () => controller.abort(); // 언마운트 시 요청 취소
  }, [url]);

  return data;
}
```

TanStack Query를 쓰고 있다면 내부적으로 AbortController를 처리해주니까 직접 관리할 필요가 없다. `queryFn`에 `signal`이 자동으로 전달된다:

```typescript
useQuery({
  queryKey: ['search', query],
  queryFn: ({ signal }) =>
    fetch(`/api/search?q=${query}`, { signal }).then((res) => res.json()),
});
```

## 정리

AbortController는 화려한 기술이 아니다. 하지만 제대로 쓰면 race condition, 중복 요청, 메모리 낭비를 깔끔하게 해결한다. 특히 검색, 자동완성, 무한 스크롤처럼 요청이 빈번한 UI에서는 사실상 필수다.

fetch를 쓸 때 `signal`을 넘기는 습관만 들여도 대부분의 문제를 예방할 수 있다.



코드 리뷰가 병목이었다. PR을 올리면 리뷰어가 볼 때까지 반나절에서 하루. 리뷰어도 바쁘니까 꼼꼼하게 보기 어렵다. "LGTM" 한 줄로 승인되는 PR이 늘어났다. 리뷰의 질이 떨어지고 있다는 건 다들 알고 있었는데, 뾰족한 수가 없었다.

AI 코드 리뷰를 붙여보자는 아이디어가 나왔다. 사람 리뷰를 대체하는 게 아니라, 1차 필터로 쓰자는 거다. AI가 기본적인 것들을 잡아주면 사람 리뷰어가 로직과 설계에 집중할 수 있지 않을까.

## 어떻게 붙였나

GitHub Action으로 PR이 열리면 자동으로 AI 리뷰가 달리게 했다. diff를 추출해서 Claude API에 보내고, 리뷰 코멘트를 PR에 남기는 방식이다.

```yaml
# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get diff
        run: git diff origin/${{ github.base_ref }}...HEAD > diff.txt

      - name: AI Review
        run: node scripts/ai-review.js
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
```

리뷰 스크립트에서 중요한 건 프롬프트였다. 처음에는 "이 코드를 리뷰해줘"라고 했더니 모든 줄에 코멘트를 달았다. 변수명 제안, 스타일 지적, 심지어 칭찬까지. 노이즈가 너무 많았다.

프롬프트를 구체적으로 바꿨다:

```
아래 diff를 리뷰해주세요. 다음 항목만 코멘트하세요:
1. 버그 또는 잠재적 런타임 에러
2. 보안 취약점
3. 성능 문제 (불필요한 리렌더링, N+1 쿼리 등)
4. 누락된 에러 처리

스타일, 네이밍, 포맷팅은 코멘트하지 마세요.
문제가 없으면 빈 배열을 반환하세요.
```

이렇게 바꾸니까 코멘트 수가 PR당 평균 12개에서 2~3개로 줄었고, 유의미한 지적의 비율이 올라갔다.

## AI가 잘 잡아낸 것

**1. 누락된 에러 처리**

```typescript
// AI가 지적한 코드
const response = await fetch('/api/users');
const data = await response.json(); // response.ok 체크 없음
```

이런 건 사람 리뷰에서 자주 놓치는데 AI는 거의 100% 잡아냈다. 기계적으로 패턴을 체크하는 데 강하다.

**2. 옵셔널 체이닝 누락**

```typescript
// AI가 지적한 코드
const userName = user.profile.name;
// user.profile이 null일 수 있는 타입인데 옵셔널 체이닝 없음
```

TypeScript strict mode에서 잡히는 것도 있지만, `any`나 타입 단언으로 우회한 경우에는 타입 체커가 놓치고 AI가 잡아내는 경우가 있었다.

**3. useEffect 의존성 배열 문제**

```typescript
// AI가 지적한 코드
useEffect(() => {
  fetchData(userId);
}, []); // userId가 의존성에 빠져 있음
```

ESLint exhaustive-deps 규칙으로도 잡히지만, 이미 disable 주석이 달려 있는 경우에 AI가 "이 disable이 정당한가?"를 물어봤다.

## AI가 놓친 것

**1. 비즈니스 로직 오류**

할인율 계산에서 퍼센트와 소수점을 혼동한 코드가 있었다. `discount * 100`을 해야 하는데 `discount`를 그대로 쓴 건데, AI는 이걸 지적하지 못했다. 코드 자체는 문법적으로 완벽했으니까. 도메인 지식이 필요한 버그는 여전히 사람의 몫이다.

**2. 아키텍처 판단**

"이 로직이 여기 있는 게 맞는가?", "이 추상화가 적절한가?" 같은 설계 수준의 질문은 AI가 하지 않았다. 현재 diff만 보니까 전체 코드베이스의 맥락을 모른다.

**3. 팀 컨벤션**

"우리 팀은 이런 경우 커스텀 훅으로 빼는데"라든가, "이 패턴은 지난번에 문제가 생겨서 안 쓰기로 했는데" 같은 팀 고유의 맥락은 AI가 알 수 없다.

## 팀 반응

처음 2주는 반응이 갈렸다.

긍정적: "기본적인 실수를 잡아줘서 리뷰할 때 로직에 집중할 수 있다", "PR 올리기 전에 셀프 체크 리마인더가 되는 느낌"

부정적: "뻔한 걸 지적해서 거슬린다", "이거 고치라는 건지 참고하라는 건지 모르겠다"

부정적 반응의 원인은 대부분 노이즈였다. 프롬프트를 다듬고, 심각도를 나눠서 표시하게 바꾸니 불만이 줄었다. "bug"는 빨간색, "suggestion"은 회색으로 라벨을 달았다.

3개월이 지나자 팀에서 자연스럽게 받아들여졌다. AI 코멘트가 달리면 훑어보고, 맞는 지적이면 반영하고, 아니면 무시한다. 존재감은 낮은데 가끔 유용한, 딱 그 정도의 포지션을 찾은 것 같다.

## 비용

Claude API 비용은 월 2만 원 정도였다. PR이 하루 평균 3~4개, diff 크기는 보통 수백 줄. 토큰 비용이 크지 않다. 사람 리뷰어의 시간 절약을 생각하면 충분히 합리적이다.

사람 리뷰를 대체하려 하면 실패한다. AI 코드 리뷰는 린터의 연장선에 가깝다. 린터가 문법을 잡듯이, AI는 패턴 수준의 실수를 잡는다. 설계와 맥락은 여전히 사람이 봐야 한다.



작년 9월, 팀에 GitHub Copilot Business 라이선스가 들어왔다.

팀 리드가 슬랙에 "다들 써보고 2주 뒤에 후기 공유합시다"라고 올렸다. 첫 주에 팀원 6명 전원이 반응이 비슷했다. "와 이건 진짜 사기다." 자동완성이 내가 쓰려는 코드를 척척 맞추고, 함수 시그니처만 적으면 구현이 쭉 나오고, 주석 한 줄에 유틸 함수가 완성됐다. 우리는 이게 미래라고 생각했다. 그 흥분이 약 3주 정도 갔다.

## 현실은 데모 영상이 아니다

Twitter(X)에 올라오는 AI 코딩 데모는 항상 깔끔하다. 빈 파일에서 시작해서 Todo 앱을 만들거나, 간단한 CRUD API를 뚝딱 찍어내거나, 알고리즘 문제를 풀어내는 영상들. 저런 걸 보면 "개발자 필요 없겠는데?"라는 생각이 드는 게 당연하다.

근데 실무는 빈 파일에서 시작하지 않는다. 이미 200개 넘는 컴포넌트가 있는 프로젝트에서 기존 디자인 시스템을 따르고, API 응답 구조에 맞추고, 에러 핸들링 컨벤션을 지키고, 비즈니스 로직의 히스토리를 이해해야 하는 게 실무다. AI한테 "결제 페이지에서 쿠폰 적용 시 배송비 할인과 상품 할인이 동시에 들어올 때의 우선순위 로직 짜줘"라고 하면 그럴듯한 코드가 나오긴 한다. 근데 그게 우리 서비스의 규칙과 맞는지는 전혀 다른 문제다.

## AI가 진짜 잘하는 것들

이건 인정해야 한다. 특정 영역에서 AI 코딩 도구는 시간을 확실히 줄여준다.

**보일러플레이트 코드.** React 컴포넌트 기본 구조, API 호출 함수, TypeScript 인터페이스 정의 같은 반복적인 코드. 2025년 11월에 어드민 대시보드의 테이블 컴포넌트를 8개 만들어야 하는 작업이 있었다. 각 테이블이 컬럼 정의, 정렬, 페이지네이션, 필터링을 포함해야 했는데, 첫 번째 테이블을 직접 짜고 나서 나머지 7개는 Copilot이 컨텍스트를 잡고 거의 다 완성해줬다. 원래 이틀은 걸렸을 작업을 반나절 만에 끝냈다.

**정규표현식.** 이건 누가 뭐래도 AI가 사람보다 낫다. 전화번호 포맷 검증, 이메일 유효성 체크, 특정 패턴의 문자열 파싱. 예전에는 regex101.com에서 30분씩 시행착오를 거쳤다면, 지금은 ChatGPT한테 "한국 휴대폰 번호 010-XXXX-XXXX 또는 01X-XXX-XXXX 형식, 하이픈 선택적"이라고 말하면 10초 만에 나온다.

```typescript
// ChatGPT가 짜준 정규표현식 — 바로 적용 가능했던 경우
const phoneRegex = /^01[016789]-?\d{3,4}-?\d{4}$/;
```

**테스트 코드 생성.** 유틸 함수의 단위 테스트를 짤 때 특히 유용하다. 함수를 붙여넣고 "edge case 포함해서 테스트 짜줘"라고 하면 내가 생각 못 한 케이스까지 잡아준다. 0, undefined, 빈 배열, 음수 같은 경계값들. 올해 1월에 가격 계산 유틸 함수의 테스트를 Claude에게 시켰는데, 부동소수점 오차 케이스를 포함시킨 걸 보고 감탄했다. 그건 내가 놓쳤을 케이스였다.

**익숙하지 않은 언어나 도구.** 이게 개인적으로 가장 큰 이점이었다. 프론트엔드 개발자인 나한테 Dockerfile 작성, GitHub Actions 워크플로우 설정, 간단한 Python 스크립트 같은 건 매번 구글링의 연속이었다. 지금은 Cursor에서 컨텍스트를 주고 물어보면 프로젝트에 맞는 설정을 뱉어준다. 작년 12월에 CI 파이프라인에 Lighthouse 성능 체크를 추가하는 작업을 맡았는데, GitHub Actions yaml 파일을 처음부터 직접 짰으면 반나절은 걸렸을 거다. Claude Code한테 기존 워크플로우 파일을 보여주고 요구사항을 설명했더니 15분 만에 동작하는 워크플로우가 나왔다.

## 프로덕션에서 터진 AI 코드

10월 말, 상품 목록 페이지의 무한 스크롤을 Copilot 자동완성에 많이 의존해서 짰다. IntersectionObserver 설정, 다음 페이지 fetch, 로딩 상태 관리까지 꽤 그럴듯하게 완성됐다. 코드 리뷰도 통과했다. 스테이징에서도 잘 돌았다.

프로덕션 배포 후 이틀 뒤에 슬랙 알림이 왔다. 특정 유저들에게서 페이지가 먹통이 된다는 CS.

원인을 추적해보니 이랬다. Copilot이 짜준 코드에서 cleanup 함수가 observer를 제대로 해제하지 않고 있었다. 컴포넌트가 언마운트되고 다시 마운트될 때 observer가 중복 등록됐다. 대부분의 유저는 페이지를 한 번 보고 나가니까 문제가 없었는데, 상품 상세 페이지를 갔다가 뒤로가기로 돌아오는 패턴을 반복하는 유저에게서 observer가 쌓이면서 API 호출이 폭발한 거다.

```typescript
// Copilot이 짜준 코드 (문제 있는 버전)
useEffect(() => {
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting && hasNextPage) {
      fetchNextPage();
    }
  });

  if (targetRef.current) {
    observer.observe(targetRef.current);
  }

  // cleanup이 빠져있었다
}, [hasNextPage, fetchNextPage]);
```

```typescript
// 수정 후
useEffect(() => {
  const currentTarget = targetRef.current;
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting && hasNextPage) {
      fetchNextPage();
    }
  });

  if (currentTarget) {
    observer.observe(currentTarget);
  }

  return () => {
    if (currentTarget) {
      observer.unobserve(currentTarget);
    }
    observer.disconnect();
  };
}, [hasNextPage, fetchNextPage]);
```

cleanup 함수 하나 빠진 거다. 근데 이게 AI 코드의 전형적인 문제점이다. 겉보기엔 완벽하고, 대부분의 케이스에서 동작하고, 코드 리뷰에서도 눈에 잘 안 띈다. 하지만 엣지 케이스에서 조용히 터진다. AI는 "보통은 이렇게 짜더라"는 패턴을 학습한 거지, "이 코드가 언마운트 후 다시 마운트될 때 어떤 상태가 되는지"를 추론한 게 아니다.

## AI가 못하는 것들

**여러 파일에 걸친 맥락 이해.** 우리 프로젝트에서 결제 플로우는 8개 파일에 걸쳐 있다. 장바구니 → 주소 입력 → 결제 수단 → 쿠폰 → 최종 확인 → PG 연동 → 결과 처리 → 주문 완료. 이 흐름 안에서 상태가 어떻게 전달되고 변환되는지를 AI는 이해하지 못한다. Cursor의 codebase 인덱싱 기능이 이 문제를 좀 줄여주긴 하지만, "쿠폰 적용 후 PG 연동 단계에서 금액이 원래로 돌아가는 버그"를 AI한테 디버깅 시키는 건 아직 불가능에 가깝다.

**Race condition 디버깅.** 올 1월에 실시간 재고 표시 기능에서 발생한 버그가 있었다. WebSocket으로 받은 재고 업데이트와 사용자의 장바구니 수량 변경이 동시에 일어날 때 UI가 깜빡이면서 잘못된 값을 보여주는 문제. 이걸 Claude한테 설명하면 "debounce를 써라" "optimistic update를 써라" 같은 일반적인 조언이 나온다. 근데 실제 문제는 WebSocket 메시지의 도착 순서가 보장되지 않는 환경에서 React 상태 업데이트의 batching 타이밍과 맞물려 발생하는 거였다. 이건 코드를 읽는 게 아니라 실행 흐름을 머릿속에서 시뮬레이션해야 찾을 수 있다.

**비즈니스 로직의 "왜".** 코드에 주석으로 // 2025년 3분기 프로모션 정책 변경으로 인한 예외 처리 라고 적혀 있어도, AI는 그 정책이 왜 바뀌었고 어떤 맥락에서 이 예외가 필요한지 알 수 없다. 우리 서비스에는 "이 조건에서는 배송비를 0원으로 해야 한다"는 규칙이 14개 있다. 기획 문서, PM과의 대화 히스토리, 과거 장애 보고서 안에 흩어져 있는 맥락이다. AI는 코드 패턴은 볼 수 있지만 조직의 기억은 볼 수 없다.

## 도구별 체감 비교

6개월간 네 가지 도구를 돌아가면서 쓴 체감 정리다.

**GitHub Copilot.** 에디터 안에서의 자동완성이 핵심. 새 코드를 처음부터 짤 때보다 기존 패턴을 반복하는 작업에서 빛난다. 한 파일 안에서의 컨텍스트는 잘 잡는데, 프로젝트 전체를 보는 건 아니라서 가끔 엉뚱한 import를 추천한다. 체감 생산성 향상은 하루에 30분~1시간 정도. 무시할 수 없는 수준이다.

**Cursor.** 코드베이스 인덱싱이 Copilot과의 가장 큰 차이점. `@codebase`로 프로젝트 전체를 참조할 수 있어서 "이 프로젝트에서 에러 핸들링은 어떤 패턴으로 하고 있어?"라고 물으면 실제 코드를 기반으로 답해준다. Composer 기능으로 여러 파일을 동시에 수정하는 것도 가능한데, 큰 작업에서는 아직 믿고 쓰기엔 부족하다. 작은 수정 단위로 쪼개서 써야 안전하다.

**Claude Code.** CLI 기반이라 처음에는 낯설었는데, 익숙해지니까 가장 자주 쓰게 됐다. 긴 맥락을 유지하면서 대화하는 게 가능해서, 복잡한 리팩토링 계획을 세울 때 특히 좋았다. "이 컴포넌트를 이런 방향으로 바꾸려는데 영향 범위가 어디까지일까?" 같은 질문에 프로젝트 파일들을 직접 읽고 답해주는 게 유용했다. 다만 실행 결과를 실시간으로 확인하면서 반복하는 흐름이라 시간이 걸릴 때도 있다.

**ChatGPT.** 코드 에디터와 연결 없이 독립적으로 쓴다. 개념 설명, 설계 상담, 코드 리뷰 관점에서의 피드백 요청에 주로 쓴다. "이 아키텍처의 단점이 뭘까?" 같은 열린 질문에 강하다. 코드를 직접 적용하기보다는 방향을 잡을 때 대화 상대로 쓰는 느낌이다.

## 팀의 AI 사용 가이드라인

올 2월에 팀에서 AI 도구 사용 원칙을 정했다. 형식적인 규칙이 아니라, 몇 달간 쓰면서 자연스럽게 합의된 것들이다.

1. **AI가 생성한 코드는 반드시 한 줄씩 이해하고 커밋한다.** "Copilot이 짠 건데 잘 모르겠어요"는 코드 리뷰에서 받아들여지지 않는다.
2. **비즈니스 로직에는 AI를 보조로만 쓴다.** 금액 계산, 권한 처리, 개인정보 관련 코드는 AI 출력물을 초안으로 쓸 수는 있지만, 로직의 정확성은 기획 문서와 대조해서 사람이 검증한다.
3. **테스트 코드 생성은 적극 권장한다.** 테스트 커버리지를 올리는 데 AI가 효과적이니까, 단위 테스트 작성에 AI를 쓰는 건 장려한다. 다만 생성된 테스트가 실제로 의미 있는 케이스를 검증하는지는 확인해야 한다.
4. **PR 리뷰에서 AI 사용 여부를 밝힌다.** 강제는 아니고 권장이다. "이 부분은 Cursor Composer로 생성 후 수정했습니다" 같은 코멘트를 달면 리뷰어가 어디를 더 꼼꼼히 봐야 하는지 판단할 수 있다.

이게 거창한 정책이 아니라 그냥 "AI 코드 때문에 장애 났던 경험"에서 나온 실용적인 합의다.

## "AI가 내 직업을 대체하나?"

이 질문을 안 해본 개발자가 있을까. 나도 Copilot을 처음 쓴 날 밤에 이 생각을 했다. 내가 3년간 쌓은 게 Tab 키 한 번으로 대체되는 건가.

6개월 뒤의 답은 이렇다. AI는 타이핑을 대체하지, 판단을 대체하지 않는다.

내가 하루에 하는 일을 나눠보면 코드를 치는 시간은 전체의 30%도 안 된다. 나머지는 기획 문서 읽기, PM이랑 엣지 케이스 논의하기, 코드 리뷰하기, 장애 대응하기, 아키텍처 결정하기, 동료한테 맥락 설명하기. AI가 빠르게 해주는 건 그 30% 중에서도 일부분이다.

불안은 이해한다. 나도 여전히 가끔 느낀다. 근데 그 불안의 방향이 좀 바뀌었다. "AI 때문에 직업을 잃을까?"에서 "AI를 잘 못 쓰면 뒤처질까?"로. 솔직하게, 같은 작업을 AI 도움 없이 두 배 시간 들여서 하는 개발자와 AI를 적절히 활용해서 절반 시간에 끝내는 개발자가 있다면, 시간이 지나면서 차이가 벌어질 거다.

그래서 요즘 생각은 이런 쪽에 가깝다. AI 도구를 쓰는 능력 자체가 하나의 스킬이 되고 있다. 좋은 프롬프트를 쓰는 것, AI 출력물에서 문제를 빠르게 발견하는 것, AI에게 맡길 일과 직접 할 일을 나누는 판단. 이런 게 1~2년 안에 개발자 채용 기준에 들어갈 수도 있다고 생각한다.

## 결국 도구는 도구다

몇 달 전에 읽은 트윗이 있다. 누군가가 "AI is like an intern with infinite stamina and no judgment"이라고 적었다. 끝없이 일하는 인턴인데 판단력이 없다. 꽤 정확한 비유라고 느꼈다.

인턴한테 일을 잘 시키려면 명확한 지시, 작은 단위의 태스크, 그리고 결과물 검토가 필요하다. AI도 똑같다. "이거 만들어줘"라고 던지면 결과물의 질이 들쭉날쭉하다. "이 함수의 input은 이거고, output은 이거고, 이런 엣지 케이스가 있고, 우리 프로젝트에서는 에러를 이렇게 처리해"라고 주면 쓸만한 코드가 나온다.

나는 AI 코딩 도구를 매일 쓴다. 안 쓰던 때로 돌아가고 싶지 않다. 그런데 AI가 짠 코드를 내가 이해할 수 없으면 그건 내 코드가 아니다. 이 한 줄이 6개월간 AI 도구를 쓰면서 내가 내린 결론 같은 건데, 사실 결론이라기보다는 매일 반복되는 판단에 가깝다. 오늘도 Copilot이 제안한 코드에서 Tab을 누를지 Esc를 누를지 0.5초간 생각한다. 그 0.5초가 아마 당분간은 사람의 몫으로 남아 있을 거다.



요즘 AI와 각종 자동화 도구가 확산되면서, Amplitude 이벤트를 수집하다 보면 **bot traffic**이 눈에 띄게 증가하고 있다.

문제는 이러한 bot 요청까지 Amplitude 이벤트로 그대로 로깅되면서 다음과 같은 불편함이 발생한다는 점이다.

- 실제 사용자 행동과 bot 이벤트가 섞여 데이터 신뢰도가 떨어진다
- 분석 과정에서 불필요한 필터링 작업이 늘어난다
- 무엇보다도 **의미 없는 이벤트가 쌓이면서 quota를 낭비하게 된다**

그래서 이번 글에서는 **Amplitude를 사용할 때 bot traffic을 어떻게 차단할 수 있는지**에 대해 정리해보려고 한다.

## 1. Amplitude **Data Blocking** 기능 활용하기

Amplitude에서는 기본적으로 [Block Bot Traffic](https://amplitude.com/docs/data/block-bot-traffic) 기능을 제공한다.

이 기능을 활용하면 특정 조건에 해당하는 이벤트를 **수집 단계에서 아예 차단**할 수 있다.

### ✔️ Bot Traffic Block filter란?

- Amplitude의 **Bot Traffic Block Filter**는 주로 **User-Agent** 정보를 기반으로 bot이나 crawler로 판단되는 트래픽을 식별하고, 해당 이벤트를 **Amplitude에 저장하지 않도록 차단하는 기능**이다.
- 내부적으로는 **IAB / ABC International Spiders and Bots List**를 기준으로 User-Agent를 검사해 bot 여부를 판단한다.

설정만으로 손쉽게 적용할 수 있다는 점은 장점이지만, 실제로 적용해보니 이 방식만으로는 모든 bot 트래픽을 걸러내기에는 한계가 있었다.

특히 **IAB/ABC Bot List의 범위가 생각보다 제한적**이라, 일부 자동화 트래픽이나 AI 기반 요청은 여전히 이벤트로 수집되는 경우가 있었다.

## 2. [`is_bot`](https://www.npmjs.com/package/isbot) 라이브러리 사용하기

좀 더 정교하게 bot을 구분하고 싶다면, 애플리케이션 레벨에서 bot 여부를 판별한 뒤 **Amplitude 이벤트 자체를 보내지 않는 방식**을 고려해볼 수 있다.

이때 많이 사용되는 방법이 [`is_bot`](https://www.npmjs.com/package/isbot) 라이브러리를 활용하는 것이다.

### [`is_bot`](https://www.npmjs.com/package/isbot) 라이브러리란?

[`is_bot`](https://www.npmjs.com/package/isbot) 라이브러리는 요청에 포함된 **User-Agent를 분석해 해당 요청이 bot인지 여부를 판별**해주는 라이브러리다.

### Amplitude와 함께 사용하는 방법

전체 흐름은 단순하다.

1. 서버 또는 클라이언트에서 요청을 수신한다
2. `is_bot` 라이브러리를 이용해 bot 여부를 판별한다
3. bot으로 판단되면 **Amplitude 이벤트를 전송하지 않는다**
4. 일반 사용자 요청만 이벤트로 로깅한다

## 마무리

Amplitude에서 bot traffic을 방치하면 데이터 신뢰도와 비용, 두 가지 모두에 악영향을 미치기 쉽다.

bot traffic이 점점 늘어나는 요즘, 이벤트 관리 역시 한 단계 더 신경 써야 할 시점이다.



프론트엔드에서 에러 핸들링은 "잘 안 해도 일단 돌아가는" 영역이다. happy path만 구현해도 기능은 동작한다. 문제는 유저가 실제로 쓸 때 터진다. 네트워크가 끊기고, 서버가 500을 뱉고, 토큰이 만료된다. 이 상황들을 안 다루면 유저는 흰 화면을 보거나, 아무 반응 없는 버튼을 계속 누르게 된다.

회사에서 처음 에러 핸들링을 제대로 잡은 건, QA에서 "결제 버튼 누르면 아무 일도 안 일어나요"라는 리포트가 3건 연속 올라온 뒤였다. 전부 API 에러를 catch하지 않아서 생긴 문제였다.

## try-catch의 한계

가장 기본적인 에러 핸들링이다.

```typescript
async function handleSubmit() {
  try {
    setIsLoading(true);
    const result = await createOrder(orderData);
    router.push(`/orders/${result.id}`);
  } catch (error) {
    console.error(error);
    alert("주문에 실패했습니다.");
  } finally {
    setIsLoading(false);
  }
}
```

동작은 한다. 근데 문제가 있다.

모든 에러를 같은 방식으로 처리하고 있다. 네트워크 에러든, 400 Bad Request든, 401 Unauthorized든 전부 "주문에 실패했습니다." 하나로 퉁친다. 유저 입장에서는 왜 실패했는지 모른다. 입력값이 잘못된 건지, 로그인이 필요한 건지, 서버가 죽은 건지.

```typescript
async function handleSubmit() {
  try {
    setIsLoading(true);
    const result = await createOrder(orderData);
    router.push(`/orders/${result.id}`);
  } catch (error) {
    if (error instanceof ApiError) {
      switch (error.status) {
        case 400:
          setFieldErrors(error.data.errors);
          break;
        case 401:
          router.push("/login?redirect=/checkout");
          break;
        case 409:
          toast.error("이미 처리된 주문입니다.");
          break;
        case 429:
          toast.error("잠시 후 다시 시도해주세요.");
          break;
        default:
          toast.error("일시적인 오류가 발생했습니다.");
      }
    } else if (error instanceof NetworkError) {
      toast.error("네트워크 연결을 확인해주세요.");
    } else {
      toast.error("알 수 없는 오류가 발생했습니다.");
    }
  } finally {
    setIsLoading(false);
  }
}
```

이건 제대로 된 처리지만, 이걸 매번 모든 API 호출마다 써야 한다. 주문도, 장바구니 추가도, 프로필 수정도. 코드가 중복된다.

## API 클라이언트 레벨의 에러 처리

공통 에러(401, 500, 네트워크 에러)는 API 클라이언트에서 한 번에 처리하는 게 낫다.

```typescript
// api/client.ts
import axios, { AxiosError } from "axios";

export class ApiError extends Error {
  constructor(
    public status: number,
    public data: any,
    message: string
  ) {
    super(message);
    this.name = "ApiError";
  }
}

export class NetworkError extends Error {
  constructor() {
    super("네트워크 연결에 실패했습니다.");
    this.name = "NetworkError";
  }
}

const client = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_URL,
  timeout: 10000,
});

client.interceptors.response.use(
  (response) => response,
  (error: AxiosError) => {
    // 네트워크 에러
    if (!error.response) {
      return Promise.reject(new NetworkError());
    }

    const { status, data } = error.response;

    // 401: 인증 만료 → 자동 로그아웃
    if (status === 401) {
      // 토큰 갱신 로직 또는 로그아웃
      window.location.href = "/login";
      return new Promise(() => {}); // 이후 처리 차단
    }

    // 500+: 서버 에러 → 에러 리포팅
    if (status >= 500) {
      reportError(error); // Sentry 등
    }

    return Promise.reject(new ApiError(status, data, data?.message || "요청에 실패했습니다."));
  }
);

export default client;
```

이제 개별 호출에서는 해당 API에 특화된 에러만 처리하면 된다.

```typescript
async function handleSubmit() {
  try {
    setIsLoading(true);
    const result = await createOrder(orderData);
    router.push(`/orders/${result.id}`);
  } catch (error) {
    if (error instanceof ApiError && error.status === 400) {
      setFieldErrors(error.data.errors);
    } else if (error instanceof ApiError && error.status === 409) {
      toast.error("이미 처리된 주문입니다.");
    } else {
      // 네트워크 에러, 서버 에러 등은 이미 인터셉터에서 처리됨
      toast.error(error instanceof ApiError ? error.message : "오류가 발생했습니다.");
    }
  } finally {
    setIsLoading(false);
  }
}
```

## Error Boundary

React의 Error Boundary는 렌더링 중 발생하는 에러를 잡아준다. API 에러와는 다른 맥락이지만, 전체적인 에러 핸들링 전략에서 중요한 역할을 한다.

```tsx
import { Component, ErrorInfo, ReactNode } from "react";

interface Props {
  children: ReactNode;
  fallback: ReactNode | ((error: Error, reset: () => void) => ReactNode);
}

interface State {
  error: Error | null;
}

class ErrorBoundary extends Component<Props, State> {
  state: State = { error: null };

  static getDerivedStateFromError(error: Error): State {
    return { error };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    reportError(error, errorInfo);
  }

  reset = () => {
    this.setState({ error: null });
  };

  render() {
    if (this.state.error) {
      const { fallback } = this.props;
      if (typeof fallback === "function") {
        return fallback(this.state.error, this.reset);
      }
      return fallback;
    }
    return this.props.children;
  }
}
```

Error Boundary를 어디에 배치하느냐가 중요하다. 앱 최상단에 하나만 두면 에러가 발생했을 때 전체 화면이 에러 페이지로 바뀐다. 유저가 다른 기능도 쓸 수 없게 된다.

```tsx
// 나쁜 예: 최상단에만 Error Boundary
<ErrorBoundary fallback={<FullScreenError />}>
  <App />
</ErrorBoundary>

// 좋은 예: 기능 단위로 Error Boundary
<div className="dashboard">
  <ErrorBoundary fallback={<WidgetError />}>
    <SalesChart />
  </ErrorBoundary>

  <ErrorBoundary fallback={<WidgetError />}>
    <RecentOrders />
  </ErrorBoundary>

  <ErrorBoundary fallback={<WidgetError />}>
    <UserStats />
  </ErrorBoundary>
</div>
```

SalesChart에서 에러가 나도 RecentOrders와 UserStats는 정상 동작한다. 에러가 발생한 영역만 대체 UI를 보여준다.

## 토스트 vs 인라인 에러

에러를 유저에게 보여주는 방식이 두 가지다.

**토스트(Toast)**: 화면 모서리에 뜨는 알림. 잠시 보이다가 사라진다.
**인라인 에러**: 에러가 발생한 위치에 직접 표시한다.

둘을 언제 쓸지 기준이 필요하다.

```tsx
// 토스트: 전역적 알림. 유저의 현재 작업을 방해하지 않음
toast.error("네트워크 연결을 확인해주세요.");
toast.error("서버에 일시적인 문제가 있습니다.");
toast.success("저장되었습니다.");

// 인라인: 특정 입력값이나 영역에 대한 에러
<div className="field">
  <input
    value={email}
    onChange={(e) => setEmail(e.target.value)}
    className={errors.email ? "input-error" : ""}
  />
  {errors.email && (
    <span className="error-text">{errors.email}</span>
  )}
</div>
```

내가 쓰는 기준은 이렇다.

인라인을 쓰는 경우: 유저가 **직접 고칠 수 있는** 에러. 폼 유효성 검사 실패, 중복된 이메일, 잘못된 형식 등. 어디가 잘못됐는지 바로 보여줘야 한다.

토스트를 쓰는 경우: 유저가 **직접 고칠 수 없는** 에러. 네트워크 문제, 서버 에러, 권한 부족 등. 또는 성공/완료 알림.

```tsx
async function handleProfileUpdate(data: ProfileData) {
  try {
    await updateProfile(data);
    toast.success("프로필이 수정되었습니다.");
  } catch (error) {
    if (error instanceof ApiError && error.status === 400) {
      // 유효성 에러 → 인라인
      const fieldErrors = error.data.errors;
      setErrors({
        nickname: fieldErrors.nickname?.[0],
        bio: fieldErrors.bio?.[0],
      });
    } else {
      // 서버/네트워크 에러 → 토스트
      toast.error("프로필 수정에 실패했습니다. 잠시 후 다시 시도해주세요.");
    }
  }
}
```

## React Query와의 조합

React Query(TanStack Query)를 쓰면 에러 핸들링 패턴이 달라진다. retry, 에러 상태, 로딩 상태가 내장되어 있어서 직접 관리할 게 줄어든다.

```tsx
function OrderList() {
  const { data, error, isLoading, refetch } = useQuery({
    queryKey: ["orders"],
    queryFn: fetchOrders,
    retry: (failureCount, error) => {
      // 4xx 에러는 재시도하지 않음
      if (error instanceof ApiError && error.status < 500) {
        return false;
      }
      return failureCount < 3;
    },
  });

  if (isLoading) return <Skeleton />;

  if (error) {
    return (
      <div className="error-state">
        <p>주문 목록을 불러올 수 없습니다.</p>
        <button onClick={() => refetch()}>다시 시도</button>
      </div>
    );
  }

  return (
    <ul>
      {data.map((order) => (
        <OrderItem key={order.id} order={order} />
      ))}
    </ul>
  );
}
```

`retry` 옵션에서 에러 종류에 따라 재시도 여부를 결정한다. 서버 에러(500)는 일시적일 수 있으니 재시도하고, 클라이언트 에러(400, 404)는 재시도해도 같은 결과이니 바로 에러를 보여준다.

mutation에서의 에러 핸들링도 깔끔해진다.

```tsx
function useCreateOrder() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: createOrder,
    onSuccess: (data) => {
      queryClient.invalidateQueries({ queryKey: ["orders"] });
      router.push(`/orders/${data.id}`);
    },
    onError: (error) => {
      if (error instanceof ApiError && error.status === 400) {
        // 유효성 에러는 상위 컴포넌트에서 처리
        return;
      }
      toast.error("주문에 실패했습니다.");
    },
  });
}

// 컴포넌트에서
function CheckoutForm() {
  const { mutate, error, isPending } = useCreateOrder();

  const fieldErrors =
    error instanceof ApiError && error.status === 400
      ? error.data.errors
      : null;

  return (
    <form onSubmit={(e) => {
      e.preventDefault();
      mutate(formData);
    }}>
      <input
        name="address"
        className={fieldErrors?.address ? "input-error" : ""}
      />
      {fieldErrors?.address && (
        <span className="error-text">{fieldErrors.address[0]}</span>
      )}

      <button type="submit" disabled={isPending}>
        {isPending ? "처리 중..." : "주문하기"}
      </button>
    </form>
  );
}
```

## 에러 리포팅

에러를 유저에게 보여주는 것만큼 개발자에게 알려주는 것도 중요하다. 프로덕션에서 발생하는 에러를 모르면 고칠 수 없으니까.

```typescript
// utils/errorReporting.ts
export function reportError(error: unknown, context?: Record<string, any>) {
  if (process.env.NODE_ENV === "development") {
    console.error("[Error Report]", error, context);
    return;
  }

  // Sentry 등 에러 리포팅 서비스
  Sentry.captureException(error, {
    extra: context,
  });
}
```

API 인터셉터에서 500 에러가 발생하면 자동으로 Sentry에 보고한다. 여기에 요청 URL, 응답 상태 코드, 사용자 정보 등을 함께 넘기면 디버깅이 수월해진다.

에러 핸들링을 잘 해놓으면 "이상한 버그가 있는데 재현이 안 돼요" 같은 상황이 줄어든다. Sentry에 스택 트레이스와 컨텍스트가 다 찍혀 있으니까. 에러 핸들링은 유저 경험을 위한 것이기도 하지만, 개발자 자신을 위한 것이기도 하다. 새벽에 장애 콜 받을 때 에러 로그가 없으면 진짜 막막하다.


API 응답 값을 config 객체에 매핑하는 코드를 짰다. 타입 에러 없이 빌드도 잘 됐다. 그런데 QA에서 "결제 수단 선택이 안 된다"는 티켓이 올라왔다.

원인은 허무했다. `paymentMethod`를 `"card" | "bank" | "phone"` 세 가지로 제한해 둔 함수에, config 객체에서 꺼낸 값을 넘기고 있었는데 TypeScript가 그 값을 `string`으로 추론하고 있었다. 타입 체크를 통과한 건 내가 중간에 `as string`을 한 줄 넣었기 때문이다. 지금 생각하면 범인이 바로 나였던 건데, 당시에는 "왜 string이 안 들어가지?"라는 의문에 그냥 타입 단언을 때려버린 거다.

이 문제의 근본 원인은 TypeScript의 **type widening**이다. 그리고 해결책은 `as const` 두 단어다.

## Type Widening이 뭔데

TypeScript는 기본적으로 변수의 타입을 "넓게" 잡는다.

```typescript
const status = "active";
// status의 타입: "active" (리터럴 타입)

let status2 = "active";
// status2의 타입: string (넓어짐!)
```

`const`로 선언하면 재할당이 불가능하니까 리터럴 타입으로 잡아준다. 여기까진 직관적이다. 문제는 객체다.

```typescript
const config = {
  theme: "dark",
  language: "ko",
  maxRetry: 3,
};
// typeof config = { theme: string; language: string; maxRetry: number }
```

분명 `const`로 선언했는데 안의 프로퍼티는 전부 `string`, `number`로 넓어진다. `const`는 변수의 재할당을 막을 뿐, 객체 내부 프로퍼티의 변경은 막지 않기 때문이다. `config.theme = "light"`가 가능하니까 TypeScript 입장에서는 `"dark"`가 아니라 `string`으로 잡는 게 맞다.

이게 왜 문제가 되냐면, 이런 코드에서 터진다.

```typescript
function applyTheme(theme: "dark" | "light" | "system") {
  document.documentElement.dataset.theme = theme;
}

const config = {
  theme: "dark",
  language: "ko",
};

applyTheme(config.theme);
// Error: Argument of type 'string' is not assignable
// to parameter of type '"dark" | "light" | "system"'
```

실제로는 `"dark"`만 들어가는데 TypeScript는 `string`으로 보고 있으니 타입 에러가 난다.

## as const가 바꾸는 것

`as const`를 붙이면 객체 전체가 readonly가 되면서, 모든 프로퍼티가 리터럴 타입으로 좁아진다.

```typescript
const config = {
  theme: "dark",
  language: "ko",
  maxRetry: 3,
} as const;

// typeof config = {
//   readonly theme: "dark";
//   readonly language: "ko";
//   readonly maxRetry: 3;
// }
```

`config.theme`이 이제 `string`이 아니라 `"dark"`다. 아까 터졌던 `applyTheme(config.theme)`이 에러 없이 통과한다.

여기서 주목할 건 `readonly`다. `as const`는 단순히 타입만 좁히는 게 아니라, 객체를 완전히 읽기 전용으로 만든다. `config.theme = "light"`를 시도하면 컴파일 에러가 난다. 런타임에서 실수로 config 값을 바꿔버리는 사고도 막아주는 거다.

## 배열에서 as const

배열에서 as const의 효과는 더 극적이다.

```typescript
const roles = ["admin", "editor", "viewer"];
// type: string[]

const roles = ["admin", "editor", "viewer"] as const;
// type: readonly ["admin", "editor", "viewer"]
```

첫 번째는 `string[]`. 아무 문자열이나 들어갈 수 있는 배열이다. 두 번째는 `readonly` 튜플이면서 각 원소가 리터럴 타입이다.

이걸로 뭘 할 수 있냐면, 배열에서 유니온 타입을 뽑아낼 수 있다.

```typescript
const PAYMENT_METHODS = ["card", "bank", "phone"] as const;

type PaymentMethod = (typeof PAYMENT_METHODS)[number];
// type PaymentMethod = "card" | "bank" | "phone"
```

이전에는 이런 식으로 따로 관리해야 했다.

```typescript
type PaymentMethod = "card" | "bank" | "phone";
const PAYMENT_METHODS: PaymentMethod[] = ["card", "bank", "phone"];
```

문제가 뭐냐면, `PaymentMethod` 타입에 `"kakao"`를 추가하면서 배열에는 안 넣는 실수가 생긴다. 혹은 그 반대도. 두 곳을 동기화해야 하는 건 언젠가 반드시 어긋난다. `as const`로 배열 하나를 source of truth로 만들면 이 문제가 사라진다.

내가 실제로 이 패턴을 쓰게 된 건 어드민 대시보드의 필터 드롭다운을 만들 때였다. 주문 상태 필터가 있었는데, 기획에서 상태값이 계속 추가됐다. "배송중" 추가, "교환요청" 추가... 매번 타입 정의와 상태 배열 두 군데를 고쳐야 했고, 한쪽을 빼먹어서 드롭다운에 선택지가 안 뜨는 버그가 두 번이나 났다. `as const` 패턴으로 바꾼 뒤로는 배열 하나만 고치면 타입이 자동으로 따라오니까 그런 일이 없어졌다.

## satisfies + as const 콤보

TypeScript 4.9에서 `satisfies`가 나왔다. 이걸 `as const`와 같이 쓰면 강력해진다.

`as const`의 한 가지 약점은 타입 체크를 포기한다는 거다. 오타를 내도 모른다.

```typescript
const config = {
  theme: "drak", // 오타! dark가 아님
  language: "ko",
} as const;
// 에러 없음. "drak"이라는 리터럴 타입이 될 뿐.
```

`satisfies`를 붙이면 타입 체크와 리터럴 타입 보존을 동시에 할 수 있다.

```typescript
type AppConfig = {
  theme: "dark" | "light" | "system";
  language: "ko" | "en" | "ja";
};

const config = {
  theme: "drak",
  language: "ko",
} as const satisfies AppConfig;
// Error: Type '"drak"' is not assignable to type '"dark" | "light" | "system"'
```

오타를 잡아주면서도, 타입은 여전히 리터럴로 유지된다.

```typescript
const config = {
  theme: "dark",
  language: "ko",
} as const satisfies AppConfig;

// config.theme의 타입: "dark" (string이 아님!)
```

만약 `satisfies`만 쓰고 `as const`를 안 쓰면?

```typescript
const config = {
  theme: "dark",
  language: "ko",
} satisfies AppConfig;

// config.theme의 타입: "dark" | "light" | "system"
```

타입 체크는 통과하지만 `theme`이 유니온 타입으로 넓어진다. `as const satisfies`를 같이 써야 "체크도 하고, 좁히기도 하는" 최적의 결과가 나온다.

이 콤보가 빛나는 실전 사례를 하나 보자. 라우트 설정이다.

```typescript
type Route = {
  path: string;
  label: string;
  requireAuth: boolean;
};

const ROUTES = {
  home: { path: "/", label: "홈", requireAuth: false },
  dashboard: { path: "/dashboard", label: "대시보드", requireAuth: true },
  settings: { path: "/settings", label: "설정", requireAuth: true },
} as const satisfies Record<string, Route>;
```

`Record<string, Route>`로 각 라우트 객체의 구조를 강제하면서, `ROUTES.dashboard.path`의 타입은 `"/dashboard"`라는 리터럴로 남는다. 나중에 `path`를 기반으로 뭔가 분기할 때 타입이 정확하게 좁아지니까 실수할 여지가 줄어든다.

## const Type Parameter (TS 5.0)

TypeScript 5.0에서 추가된 const type parameter는 제네릭 함수에서 `as const`와 같은 효과를 주는 기능이다.

먼저 문제 상황을 보자.

```typescript
function createRoute<T extends string>(path: T) {
  return { path };
}

const route = createRoute("/dashboard");
// route.path의 타입: string? "/dashboard"?
```

다행히 이 경우는 TypeScript가 `"/dashboard"`로 추론한다. 하지만 객체를 넘기면 이야기가 달라진다.

```typescript
function defineConfig<T extends Record<string, unknown>>(config: T) {
  return config;
}

const config = defineConfig({
  theme: "dark",
  maxRetry: 3,
});
// config.theme의 타입: string (넓어짐)
```

호출하는 쪽에서 `as const`를 붙일 수도 있지만, 매번 사용하는 사람이 기억해야 한다.

```typescript
const config = defineConfig({
  theme: "dark",
  maxRetry: 3,
} as const);
// 이러면 되긴 하는데, 까먹으면 끝
```

const type parameter를 쓰면 함수 선언 쪽에서 강제할 수 있다.

```typescript
function defineConfig<const T extends Record<string, unknown>>(config: T) {
  return config;
}

const config = defineConfig({
  theme: "dark",
  maxRetry: 3,
});
// config.theme의 타입: "dark"
// config.maxRetry의 타입: 3
```

`<const T>`에 주목하자. 제네릭 파라미터 앞에 `const`를 붙이면, 이 함수에 전달되는 인자가 자동으로 `as const` 처리된다. 사용하는 쪽에서 아무것도 안 해도 리터럴 타입이 보존된다.

라이브러리를 만드는 입장에서 이건 큰 차이다. 내가 만든 유틸 함수를 동료가 쓸 때, "이거 `as const` 붙여야 해요"라고 말할 필요가 없다. 함수 시그니처가 알아서 처리해준다.

실제로 이 패턴은 Zod 같은 스키마 라이브러리나 tRPC의 라우터 정의에서 내부적으로 쓰이고 있다. 사용자가 정의한 스키마 값을 그대로 타입으로 끌어올려야 하니까.

## 실전 패턴: 이벤트 맵

내가 가장 자주 쓰는 패턴 하나를 공유한다. 프론트엔드에서 분석 이벤트를 트래킹할 때다.

```typescript
const ANALYTICS_EVENTS = {
  page_view: {
    category: "navigation",
    requiredParams: ["page_name", "referrer"],
  },
  button_click: {
    category: "interaction",
    requiredParams: ["button_id", "button_text"],
  },
  purchase_complete: {
    category: "conversion",
    requiredParams: ["order_id", "amount", "currency"],
  },
} as const satisfies Record<
  string,
  { category: string; requiredParams: readonly string[] }
>;

type EventName = keyof typeof ANALYTICS_EVENTS;
// "page_view" | "button_click" | "purchase_complete"

type EventParams<T extends EventName> =
  (typeof ANALYTICS_EVENTS)[T]["requiredParams"][number];
// EventParams<"purchase_complete"> = "order_id" | "amount" | "currency"

function trackEvent<T extends EventName>(
  event: T,
  params: Record<EventParams<T>, string>
) {
  // 전송 로직
}

trackEvent("purchase_complete", {
  order_id: "123",
  amount: "50000",
  currency: "KRW",
}); // OK

trackEvent("purchase_complete", {
  order_id: "123",
}); // Error: amount, currency 빠짐

trackEvent("puchase_complete", {
  // Error: 오타. "purchase_complete"여야 함
  order_id: "123",
  amount: "50000",
  currency: "KRW",
});
```

이벤트 이름도 자동완성이 되고, 각 이벤트에 필요한 파라미터도 타입으로 강제된다. 이전에는 이벤트 이름을 문자열로 넘기고 파라미터는 `Record<string, string>`으로 받았는데, 오타가 나도 모르고 필수 파라미터를 빼먹어도 모르는 상태였다. Amplitude 대시보드에서 "왜 이벤트가 안 잡히지?" 하고 삽질한 적이 여러 번 있었다.

이 패턴으로 바꾼 뒤 트래킹 관련 버그가 확실히 줄었다. 코드 리뷰에서 "이 이벤트 파라미터 맞아?"를 확인하는 시간도 없어졌고.

## 주의할 점

`as const`가 만능은 아니다.

동적으로 값이 바뀌는 객체에는 쓸 수 없다. `readonly`니까 프로퍼티 재할당이 컴파일 에러가 난다. React의 `useState`로 관리하는 상태 같은 건 당연히 대상이 아니다.

깊게 중첩된 객체에 쓰면 타입이 복잡해진다. IDE에서 hover했을 때 타입 표시가 몇 줄씩 나오면서 오히려 가독성이 떨어질 수 있다. 나는 보통 2단계 이상 중첩되면 별도 타입을 정의하고 `satisfies`로 연결하는 식으로 균형을 맞춘다.

그리고 `as const`로 만든 객체를 함수 인자로 넘길 때, 해당 함수가 `readonly` 타입을 받도록 되어 있어야 한다.

```typescript
const items = ["a", "b", "c"] as const;

function process(arr: string[]) {
  arr.push("d");
}

process(items);
// Error: readonly ["a", "b", "c"]는 string[]에 할당 불가
```

`readonly string[]`으로 받으면 해결된다. 이건 라이브러리 코드 짤 때 특히 신경 써야 하는 부분이다.

## 언제 쓸까

내 기준은 단순하다. "이 값이 런타임에 변하면 안 되는 설정값인가?" 그렇다면 `as const`. 라우트 정의, 이벤트 이름, HTTP 메서드, 에러 코드, 권한 목록 같은 것들. 코드에서 하드코딩된 상수 역할을 하는 값이면 `as const`를 붙여라.

한 번 습관이 되면 자연스럽게 손이 간다. 그리고 어느 순간 `string`으로 추론되는 걸 보면 불안해지기 시작한다. 그게 TypeScript를 제대로 쓰기 시작했다는 신호다.



주니어 시절 질문하는 게 두려웠다. "이것도 모르나?"라는 반응이 올까 봐. 그래서 혼자 끙끙대면서 반나절을 쓰고, 결국 물어보면 5분 만에 해결되는 경우가 많았다.

시간이 지나면서 깨달은 건, 문제는 "질문을 한다/안 한다"가 아니라 "어떻게 질문하느냐"였다는 것이다.

## 나쁜 질문의 패턴

**"안 돼요" 질문**

```
이거 안 되는데 어떻게 해야 하나요?
```

받는 사람 입장에서는 답할 수가 없다. 뭘 하려는지, 뭐가 안 되는지, 어디까지 해봤는지 모른다. "이거"가 뭔지부터 물어봐야 한다.

**스크린샷 하나 던지기**

에러 스크린샷만 올리고 아무 설명 없는 질문. 받는 사람이 스크린샷을 해독해야 한다. 에러 메시지를 텍스트로 복사해서 올리는 것만으로도 검색 가능하고, 맥락을 파악하기 쉬워진다.

**"해주세요" 질문**

```
이 기능 어떻게 만드나요? 코드 좀 짜주세요.
```

이건 질문이 아니라 업무 위임이다. 본인이 시도한 흔적이 없으면 답변하는 사람도 의욕이 안 난다.

## 좋은 질문의 구조

좋은 질문에는 네 가지 요소가 있다:

**1. 하려는 것 (Goal)**

"Next.js에서 특정 페이지만 ISR로 동작하게 하려고 합니다."

**2. 한 것 (Attempt)**

"`revalidate` 옵션을 `generateStaticParams`에 넣어봤는데..."

**3. 기대한 결과 (Expected)**

"빌드 후 해당 페이지가 60초마다 재생성될 거라고 예상했습니다."

**4. 실제 결과 (Actual)**

"그런데 페이지가 항상 SSR로 동작합니다. `x-nextjs-cache` 헤더가 없습니다."

이걸 합치면:

```
Next.js 14에서 `/products/[id]` 페이지만 ISR로 동작하게 하려고
generateStaticParams에 revalidate: 60을 설정했는데,
배포 후 응답 헤더에 x-nextjs-cache가 없고 매 요청마다 서버에서
렌더링됩니다.

page.tsx의 관련 코드:
(코드 붙여넣기)

next.config.js:
(코드 붙여넣기)

Node.js 20, Next.js 14.1.0, Vercel 배포 환경입니다.
```

이 질문은 답변하는 사람이 바로 문제를 파악하고 해결 방향을 제시할 수 있다.

## 질문 전에 해야 할 것

좋은 질문을 만드는 과정 자체가 디버깅이다. 놀라운 건, 질문을 정리하다 보면 스스로 답을 찾는 경우가 꽤 많다는 것이다.

"이런 상황에서 이걸 했는데 안 된다"를 정리하려면, 상황을 재현하고, 시도한 것을 나열하고, 기대와 현실의 차이를 명확히 해야 한다. 이 과정에서 "아, 이걸 안 해봤네"가 발견되기도 한다.

이걸 러버덕 디버깅이라고 부른다. 고무 오리에게 설명하듯이 문제를 말로 풀어보면, 생각이 정리되면서 답이 보인다. 질문을 쓰는 행위 자체가 생각을 정리하는 도구다.

그래서 실천하는 습관: 질문을 다 작성한 다음, 보내기 전에 5분만 더 고민한다. 그 5분 안에 답을 찾으면 좋고, 못 찾으면 잘 정리된 질문을 보내는 거다.

## 질문을 잘 하면 생기는 일

**답변 속도가 빨라진다.** 맥락이 충분한 질문은 읽자마자 답할 수 있다. 추가 질문을 주고받는 핑퐁이 없어진다.

**신뢰가 쌓인다.** "이 사람은 충분히 고민하고 질문한다"는 인상을 주면, 다음에 질문할 때도 기꺼이 도와주는 사람이 생긴다.

**본인의 문제 해결력이 올라간다.** 질문을 정리하는 과정이 디버깅 훈련이다. 이걸 반복하면 질문하기 전에 스스로 해결하는 비율이 올라간다.

질문은 실력이 부족해서 하는 게 아니다. 시니어도 질문한다. 다만 시니어의 질문은 "이걸 모르겠다"가 아니라 "이 두 가지 접근 중 어떤 게 더 적합할까?"인 경우가 많다. 좋은 질문의 형태가 다를 뿐, 질문 자체를 멈추는 건 아니다.



작년 초에 TypeScript를 제대로 공부하겠다고 결심했다. Udemy 강의를 결제하고, 노션에 학습 계획표를 만들고, 주말마다 4시간씩 공부하기로 했다.

2주 버텼다.

첫 주말은 의지가 넘쳤다. 4시간 동안 섹션 3개를 끝냈다. 둘째 주는 3시간쯤 하다가 유튜브로 빠졌다. 셋째 주는 토요일에 약속이 있어서 일요일로 미뤘고, 일요일에는 "평일에 하지 뭐" 하다가 안 했다. 넷째 주에는 강의 앱을 열지도 않았다.

이 패턴이 처음이 아니었다. React 공부도, 알고리즘도, 영어도 다 이랬다. 거창하게 시작하고 조용히 포기하는 루프.

## 2%의 개선이라는 관점

James Clear의 *Atomic Habits*를 읽은 건 그 실패 직후였다. 핵심 아이디어는 단순했다. "매일 1% 나아지면 1년 뒤에 37배가 된다." 수학적으로야 맞는 말인데, 처음엔 좀 뻔하다고 느꼈다.

근데 나를 진짜 멈추게 한 문장은 따로 있었다.

> "You do not rise to the level of your goals. You fall to the level of your systems."

목표가 아무리 거창해도, 시스템이 없으면 결국 기존 수준으로 돌아간다. 나는 "TypeScript 마스터"라는 목표는 있었지만, 그걸 위한 시스템은 없었다. "주말에 4시간"은 시스템이 아니라 일회성 이벤트다.

## 매일 25분

시스템을 만들기로 했다. 규칙은 하나. **평일 아침, 출근 전에 25분 코딩 공부.** 단 25분.

왜 25분이냐면, 뽀모도로 타이머 하나 분량이라 시간 관리가 쉬웠다. 그리고 "25분이면 뭘 하겠어"라는 생각이 드는 게 핵심이다. 부담이 없으니까 시작하기 쉽다.

처음 일주일은 TypeScript 공식 문서를 읽었다. 25분 동안 제네릭 챕터 절반 읽는 게 전부였다. 별로 한 게 없는 것 같았다. 근데 다음 날 나머지 절반을 읽고, 그다음 날은 간단한 예제를 직접 쳐봤다.

한 달이 지나니까 제네릭, 유틸리티 타입, 조건부 타입까지 왔다. 두 달째에는 회사 코드에서 `any`를 하나씩 지워나가기 시작했다. 세 달째에는 동료가 "타입 어떻게 짜야 돼?"라고 나한테 물어봤다.

4시간 몰아치기로는 2주 만에 포기한 걸, 25분씩 매일 해서 3개월 만에 체감되는 변화를 만들었다.

## 습관 쌓기(Habit Stacking)

25분 습관이 정착된 데는 "습관 쌓기" 전략이 컸다. 기존에 이미 하고 있는 습관에 새 습관을 붙이는 거다.

나의 경우: **커피 내리기 → 커피 들고 책상에 앉기 → 타이머 25분 시작 → 코딩 공부**

커피 내리는 건 이미 매일 하는 행동이니까, 그 뒤에 공부를 끼워 넣으면 별도의 의지력이 덜 든다. "오늘 공부해야지"라고 매일 결심하는 대신, 커피를 내리면 자동으로 공부 모드에 들어가는 루틴이 된다.

한 달쯤 지나면 생각 없이 몸이 움직인다. 커피 머신 버튼 누르고, 컵 들고 가서, VS Code 열고, 타이머 시작. 의지력의 문제가 아니라 관성의 문제가 된다.

## 2일 연속으로 빼먹지 않는다

매일 하겠다는 건 거짓말이다. 현실에서는 빼먹는 날이 반드시 온다. 아침에 컨디션이 안 좋거나, 일찍 출근해야 하거나, 그냥 하기 싫은 날이 있다.

James Clear가 제안하는 규칙이 하나 있다. **"하루는 빼먹어도 된다. 이틀 연속은 안 된다."** 이 규칙이 나를 살렸다. 하루 빼먹었을 때 "아 망했다, 다시 시작해야 하나"가 아니라, "내일만 하면 된다"고 생각할 수 있게 해준다.

완벽주의가 습관의 적이다. 한 번 빼먹었다고 전체를 포기하는 게 가장 흔한 실패 패턴이다. 3일 연속 빼먹으면 다시 시작하기가 심리적으로 어려워진다. 근데 1일은 괜찮다. 다음 날 바로 돌아오면 연속성이 유지된다.

## 정체성의 변화

3개월쯤 지나니까 재미있는 변화가 생겼다. "TypeScript 공부해야 하는 사람"에서 "매일 아침에 코딩 공부하는 사람"으로 스스로에 대한 인식이 바뀌었다. James Clear 식으로 말하면 "identity shift"다.

"나는 꾸준히 공부하는 개발자다"라는 정체성이 생기면, 하루 빼먹는 게 불편해진다. 의지력으로 버티는 게 아니라, 내 이미지와 맞지 않아서 불편한 거다. 이게 습관이 자동화되는 단계다.

지금은 TypeScript 말고도 아침 25분에 여러 가지를 돌아가며 한다. 한 주는 새 라이브러리 문서 읽기, 다음 주는 알고리즘 한 문제, 그다음 주는 기술 블로그 읽기. 25분이라는 그릇은 그대로인데, 안에 담는 내용물만 바뀐다.

---

매일 25분이 인생을 바꾼다고 하면 과장이다. 근데 매일 25분이 "나는 꾸준한 사람이 아니야"라는 믿음을 바꿔준 건 사실이다. 그리고 그 믿음의 변화가, 생각보다 많은 걸 바꿨다.



새벽 2시에 슬랙 알림이 울렸다. 보안팀에서 보낸 메시지였다. "XSS 취약점 발견. 사용자 토큰 탈취 가능. 긴급 대응 필요." 위에서 빨간불이 켜졌고, 나는 잠들기 직전에 노트북을 다시 열었다.

문제는 단순했다. JWT를 localStorage에 저장하고 있었다. 보안 감사 과정에서 한 입력 필드에 스크립트 인젝션이 가능한 게 발견됐고, 그 스크립트가 `localStorage.getItem("token")`을 호출할 수 있다는 게 증명됐다. 실제 공격이 일어난 건 아니었지만, 취약점이 존재한다는 것 자체가 문제였다.

"우리 사이트에 XSS가 없으니까 괜찮다"는 논리로 localStorage를 썼었다. 그런데 서드파티 스크립트가 포함된 페이지에서 100% XSS가 없다고 장담할 수 있는가? 분석 도구, 광고 SDK, 채팅 위젯. 전부 외부 JavaScript를 로드한다. 그중 하나라도 뚫리면 localStorage의 토큰은 그대로 노출된다.

이 사건을 계기로 인증 방식을 처음부터 다시 공부했다. 그리고 인증은 절대로 복사-붙여넣기로 구현하면 안 된다는 걸 뼈저리게 배웠다.

## localStorage에서 httpOnly 쿠키로의 마이그레이션

보안팀의 권고는 명확했다. "JWT를 httpOnly 쿠키로 옮겨라." 개념은 간단하다.

```typescript
// 이전: localStorage에 저장
const { accessToken } = await response.json();
localStorage.setItem("token", accessToken);

// 요청 시
fetch("/api/data", {
  headers: { Authorization: `Bearer ${localStorage.getItem("token")}` },
});
```

```typescript
// 이후: httpOnly 쿠키
// 서버에서 Set-Cookie: token=eyJhbG...; HttpOnly; Secure; SameSite=Strict
// 프론트에서는 그냥 credentials만 포함
fetch("/api/data", {
  credentials: "include",
});
```

httpOnly 쿠키는 JavaScript에서 접근이 불가능하다. `document.cookie`로도 읽을 수 없다. XSS가 발생해도 토큰을 빼갈 수 없다.

개념은 간단한데, 마이그레이션 과정에서 예상 못한 것들이 터졌다.

첫 번째, CORS 설정이 전부 틀어졌다. localStorage에 토큰을 넣고 Authorization 헤더로 보낼 때는 CORS가 비교적 단순했다. 쿠키를 쓰기 시작하면 `credentials: "include"`가 필요하고, 서버에서 `Access-Control-Allow-Credentials: true`를 보내야 하고, `Access-Control-Allow-Origin`에 와일드카드(`*`)를 쓸 수 없게 된다. 정확한 도메인을 지정해야 한다.

개발 환경에서 프론트(`localhost:3000`)와 백엔드(`localhost:4000`)의 포트가 다르니까, 쿠키가 안 붙는 문제가 생겼다. `SameSite=None; Secure`로 설정해야 하는데, `Secure`는 HTTPS에서만 동작한다. 로컬에서는 HTTPS가 아니니까 또 안 된다. 결국 개발 환경에서만 `SameSite=Lax`로 바꾸고, 프록시로 동일 도메인처럼 만들었다. 이 삽질에 하루가 날아갔다.

두 번째, CSRF 방어가 필요해졌다. localStorage + Authorization 헤더 방식은 CSRF에 강하다. 토큰이 자동으로 전송되지 않으니까. 쿠키로 바꾸면 모든 요청에 쿠키가 자동으로 붙는다. 악의적인 사이트에서 우리 API로 요청을 보내면 쿠키가 같이 간다. `SameSite=Strict`로 대부분 막을 수 있지만, 완벽하지는 않아서 CSRF 토큰도 추가했다.

## 새벽 2시의 리프레시 토큰 레이스 컨디션

마이그레이션을 끝내고 한숨 돌렸는데, 2주 후에 또 다른 버그가 터졌다. 사용자가 탭을 여러 개 열어놓으면 간헐적으로 로그아웃되는 현상이었다.

원인은 리프레시 토큰 로직에 있었다. Access Token이 만료되면 Refresh Token으로 새 Access Token을 발급받는 패턴이다.

```typescript
let accessToken: string | null = null;

async function refreshAccessToken(): Promise<string> {
  const response = await fetch("/api/auth/refresh", {
    method: "POST",
    credentials: "include",
  });
  const { accessToken: newToken } = await response.json();
  accessToken = newToken;
  return newToken;
}

axios.interceptors.response.use(
  (response) => response,
  async (error) => {
    if (error.response?.status === 401) {
      accessToken = null;
      const newToken = await refreshAccessToken();
      error.config.headers.Authorization = `Bearer ${newToken}`;
      return axios.request(error.config);
    }
    return Promise.reject(error);
  }
);
```

문제는 이거다. 탭 A에서 API 요청 3개가 동시에 401을 받는다. 인터셉터가 3번 동작하면서 refresh 요청이 3개 동시에 나간다. 서버에서 Refresh Token은 1회용으로 설정되어 있었다. 첫 번째 refresh 요청은 성공하지만, 두 번째와 세 번째는 이미 사용된 Refresh Token으로 요청하니까 실패한다. 서버가 "의심스러운 토큰 재사용"으로 판단하고 모든 세션을 무효화한다. 사용자 입장에서는 갑자기 로그아웃된다.

해결은 refresh 요청을 하나로 합치는 거다.

```typescript
let refreshPromise: Promise<string> | null = null;

async function getAccessToken(): Promise<string> {
  if (accessToken) return accessToken;

  if (!refreshPromise) {
    refreshPromise = refreshAccessToken().finally(() => {
      refreshPromise = null;
    });
  }

  return refreshPromise;
}
```

이렇게 하면 동시에 여러 요청이 401을 받아도, refresh 요청은 하나만 나간다. 나머지 요청들은 같은 Promise를 await한다. 간단한 코드인데, 이걸 생각해내기까지 새벽 2시부터 5시까지 걸렸다. 멀티탭 환경에서의 토큰 갱신은 진짜 까다로운 문제다.

## 세션 방식이 더 나았을까?

이 삽질들을 겪고 나서 "그냥 세션 쓸 걸" 하는 생각이 들었다. 세션 기반 인증은 프론트엔드 입장에서 할 일이 거의 없다.

```typescript
const response = await fetch("/api/login", {
  method: "POST",
  credentials: "include",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email, password }),
});

// 이후 모든 요청에 credentials: "include"만 넣으면 됨
const userData = await fetch("/api/me", {
  credentials: "include",
});
```

쿠키는 브라우저가 자동으로 관리한다. 토큰을 저장할 곳을 고민할 필요 없다. 리프레시 토큰도 필요 없다. 세션 만료는 서버가 알아서 처리한다. "모든 기기에서 로그아웃" 같은 기능도 서버에서 세션을 삭제하면 끝이다.

세션의 단점은 서버 쪽에 있다. 세션 저장소(보통 Redis)가 필요하고, 서버가 여러 대면 세션을 공유해야 하고, 매 요청마다 세션 저장소를 조회하는 비용이 있다. 하지만 솔직히, 대부분의 서비스에서 이게 병목이 되는 경우는 드물다.

## JWT를 써야 하는 진짜 이유

그래도 JWT를 쓰는 프로젝트가 많은 건 이유가 있다.

마이크로서비스 아키텍처에서 JWT가 유리하다. 서비스 A가 발급한 토큰을 서비스 B가 검증할 수 있다. 공유 세션 저장소 없이. 토큰 자체에 사용자 정보가 들어있으니까 디코딩만 하면 된다.

모바일 앱과 웹이 같은 API를 쓸 때도 JWT가 편하다. 모바일 앱에서 세션 쿠키를 관리하는 건 꽤 번거롭다.

서드파티 인증(OAuth)에서도 JWT가 자연스럽다. Google, GitHub 같은 외부 서비스의 인증 토큰을 검증하는 패턴과 잘 맞는다.

문제는 이런 이유 없이 "JWT가 모던하니까" "세션은 옛날 방식이니까"라는 이유로 JWT를 선택하는 경우다. 서버가 한 대이고, 같은 도메인이고, 웹만 서비스한다면 세션이 훨씬 간단하다. 인증은 복잡할수록 버그가 생길 확률이 높다.

## JWT의 구조적 함정: 토큰 무효화

JWT의 가장 큰 약점은 발급된 토큰을 서버에서 무효화할 수 없다는 거다. 토큰 만료가 1시간이면, 비밀번호를 바꿔도 기존 토큰이 1시간 동안 유효하다.

이걸 해결하려면 서버에 블랙리스트를 관리해야 한다. "무효화된 토큰 목록"을 Redis에 저장하고, 매 요청마다 확인한다. 그런데 이렇게 하면 JWT의 장점인 "stateless"가 무색해진다. 결국 세션이랑 다를 바 없어지는 거다.

타협점은 Access Token의 만료 시간을 짧게(5분~15분) 잡고, Refresh Token으로 갱신하는 패턴이다. Access Token이 탈취되어도 짧은 시간 내에 만료되니까 피해를 최소화한다. Refresh Token은 httpOnly 쿠키에 넣고, 서버에서 관리한다.

## 프론트엔드에서의 인증 상태 관리

어떤 방식을 쓰든, "현재 로그인 상태인지"를 프론트에서 관리해야 한다. 여기서도 흔한 실수가 있다.

```tsx
function AuthProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    async function checkAuth() {
      try {
        const response = await fetch("/api/me", {
          credentials: "include",
        });
        if (response.ok) {
          const userData = await response.json();
          setUser(userData);
        }
      } catch {
        // 인증 실패
      } finally {
        setIsLoading(false);
      }
    }
    checkAuth();
  }, []);

  if (isLoading) {
    return <FullScreenSpinner />;
  }

  return (
    <AuthContext.Provider value={{ user, setUser }}>
      {children}
    </AuthContext.Provider>
  );
}
```

`isLoading` 상태가 핵심이다. 이걸 빼먹으면 인증 확인이 끝나기 전에 "로그인 안 됨"으로 판단해서 로그인 페이지로 리다이렉트된다. 새로고침할 때마다 로그인 페이지가 깜빡이는 현상이 생긴다. 간단한 건데, 처음 구현할 때 놓치기 쉽다.

## 현실적인 선택 기준

많은 프로젝트에서 결국 "JWT를 httpOnly 쿠키에 넣는" 하이브리드 방식을 채택한다. JWT의 자기 완결성(서버가 디코딩만 하면 됨)과 쿠키의 보안성(JavaScript에서 접근 불가)을 동시에 가져간다. 이러면 프론트엔드 구현이 세션 방식과 거의 같아진다. `credentials: "include"`만 넣으면 끝이다. 차이는 서버 내부에서만 존재한다.

정리하면 이렇다.

- **서버 한 대, 같은 도메인, 웹만 서비스**: 세션이 간단하고 안전하다.
- **마이크로서비스, 모바일 + 웹, 서드파티 인증**: JWT가 유리하다.
- **어떤 방식이든 localStorage에 토큰을 넣지 않는다.** httpOnly 쿠키를 쓴다.
- **리프레시 토큰을 쓴다면 동시 갱신 문제를 반드시 처리한다.**

인증은 "동작하는 것"과 "안전한 것"이 다른 영역이다. Stack Overflow에서 복사한 코드가 동작은 하겠지만, 보안 감사를 통과할지는 모른다. 새벽 2시에 긴급 대응하는 경험을 한 번 하고 나면, 인증 코드를 대충 짜는 게 얼마나 위험한지 체감하게 된다. 인증은 프론트엔드에서 가장 지루하지만, 가장 신중해야 하는 부분이다.



처음 면접관 역할을 맡았을 때 떨렸다. 면접 보는 것도 긴장되는데, 면접관은 다른 종류의 긴장이었다. 이 사람의 합불을 내가 판단해야 한다는 책임감. 좋은 사람을 떨어뜨리면? 부족한 사람을 통과시키면?

면접을 몇 번 진행하고 나서야 깨달은 게 있다. 면접관이 보는 것은 내가 지원자일 때 생각했던 것과 꽤 달랐다.

## 정답을 맞히는 게 중요한 게 아니다

지원자일 때는 "정답을 모르면 떨어진다"고 생각했다. 면접관이 되어보니, 정답 자체보다 정답에 도달하는 과정이 훨씬 중요했다.

"클로저가 뭔가요?"라고 물었을 때, 교과서적 정의를 외워서 말하는 사람과 "이런 상황에서 이렇게 쓰이는데, 내부적으로는 이런 원리로 동작한다"고 자기 언어로 설명하는 사람이 있다. 정의는 검색하면 되지만, 자기 경험과 연결 지어 설명할 수 있는 건 실제로 이해하고 있다는 증거다.

모르는 질문이 나왔을 때의 반응도 본다. "모르겠습니다"로 끝내는 사람과, "정확히는 모르지만 이런 것과 관련이 있을 것 같고, 이런 방향으로 추론해보면..."이라고 시도하는 사람. 현업에서 모르는 문제를 만났을 때 어떻게 접근할지가 보인다.

## 기술보다 커뮤니케이션

기술 면접인데 커뮤니케이션을 본다니 아이러니하지만, 실무에서 개발은 혼자 하는 일이 아니다. 요구사항을 이해하고, 기술적 판단을 설명하고, 동료와 합의하는 능력이 코딩 실력만큼 중요하다.

면접에서 이게 드러나는 순간은 몇 가지 있다.

**질문을 명확히 하는 사람.** "사용자가 많은 환경인가요?", "모바일도 고려해야 하나요?" — 문제를 풀기 전에 범위를 확인하는 사람은 실무에서도 요구사항을 꼼꼼히 파악할 가능성이 높다. 반면 질문 없이 바로 코드를 쓰기 시작하는 사람은 가정을 많이 한다는 뜻이다.

**트레이드오프를 말하는 사람.** "이 방법은 이런 장점이 있지만 이런 단점이 있어서, 이 상황에서는 이걸 선택하겠다." 정답이 하나가 아니라는 걸 아는 사람이다.

**모르는 걸 인정하는 사람.** "그 부분은 경험이 없어서 잘 모르겠습니다"라고 솔직하게 말하는 사람이 오히려 신뢰가 간다. 아는 척하다가 꼬리 질문에서 무너지는 것보다 낫다.

## 포트폴리오에서 보는 것

이력서에 "React, TypeScript, Next.js"라고 써놓은 건 의미가 없다. 누구나 쓸 수 있으니까. 포트폴리오에서 진짜 보는 건 "왜 이 기술을 선택했는지", "어떤 문제를 어떻게 해결했는지"다.

블로그에 트러블슈팅 기록이 있으면 반가웠다. "배포했더니 이런 에러가 나서, 원인을 분석해보니 이거였고, 이렇게 해결했다." 이런 글은 이 사람이 실제로 문제를 해결해본 경험이 있다는 걸 보여준다.

깃허브 커밋 히스토리도 본다. 한 번에 수천 줄을 커밋하는 사람과, 의미 단위로 나눠서 커밋하는 사람의 차이. 커밋 메시지에 "fix", "update"만 쓰는 사람과 변경 이유를 적는 사람의 차이.

## 면접관도 긴장한다

이건 지원자일 때 몰랐다. 면접관도 좋은 질문을 해야 한다는 부담이 있다. 이 질문이 이 사람의 실력을 제대로 평가하는 질문인가? 너무 어렵거나 너무 쉽지는 않은가?

지원자가 긴장해서 평소 실력을 못 보여주는 것 같으면 면접관도 마음이 불편하다. 편한 분위기를 만들려고 시도하지만 한계가 있다. 1시간 안에 서로를 파악해야 하는 구조 자체가 완벽할 수 없다.

불합격 결정을 내릴 때가 가장 어렵다. "이 사람이 우리 팀에서 성장할 수 있을까?"를 판단하는 건, 1시간의 대화로는 불완전하다는 걸 안다. 그래도 판단해야 한다. 그래서 면접은 완벽한 평가 시스템이 아니라, 불완전하지만 현실적인 방법일 뿐이라는 것도 이제는 안다.

지원자분들에게 하고 싶은 말이 있다면 — 면접에서 떨어졌다고 해서 실력이 부족한 게 아니다. 면접은 "이 팀에 이 시점에 맞는 사람인가"를 보는 거지, 개발자로서의 가치를 평가하는 게 아니다. 면접관 쪽에서 보면 그게 더 명확하게 보인다.



점심 메뉴를 고를 때 두 부류의 사람이 있다. 네이버 지도를 열고 반경 500m 내 모든 식당의 별점을 비교하면서 "오늘 가능한 최선의 한 끼"를 찾는 사람. 그리고 회사 앞 국밥집 문을 열고 "여기 괜찮겠다" 하며 앉는 사람.

의사결정 과학에서는 전자를 maximizer, 후자를 satisficer라고 부른다. 허버트 사이먼이라는 경제학자가 만든 개념인데, 흥미로운 연구 결과가 있다. maximizer가 객관적으로 더 나은 선택을 하는 경우가 많다. 연봉도 높고, 식당도 맛있는 곳을 고른다. 그런데 만족도는 satisficer가 더 높다. 더 좋은 걸 골랐는데 더 불행하다. "혹시 더 나은 선택지가 있었을까?" 하는 생각이 끊이지 않으니까.

개발자 커리어에도 이 구조가 그대로 적용된다는 걸 최근에야 제대로 깨달았다.

## 기대치라는 트레드밀

한 투자 칼럼니스트가 쓴 글에 이런 문장이 있었다. "기대치가 수입보다 빠르게 올라가면, 아무리 벌어도 절대 부자가 된 기분이 들지 않는다." 이건 돈 이야기였지만, 커리어에 대입하면 섬뜩할 정도로 정확하다.

트위터를 열면 20대 초반에 오픈소스 메인테이너인 사람이 있다. 컨퍼런스에서 발표하고, 개인 SaaS를 운영하고, 팔로워가 만 명이 넘는다. 프로필에 "Staff Engineer"라고 적혀 있다. 이런 사람을 매일 보면 기준선이 올라간다. 나도 저 정도는 해야 하는 거 아닌가. 매일 JIRA 티켓 처리하고, 코드 리뷰하고, 점심 먹고, 퇴근하는 내 하루가 초라해진다.

3년 전의 내가 지금의 나를 보면 "대단하다"고 했을 거다. 그때는 useEffect에서 cleanup 함수를 왜 써야 하는지도 몰랐으니까. 지금은 비동기 상태 관리 패턴을 설계하고, 성능 병목을 프로파일러로 잡고, 주니어 코드 리뷰를 한다. 객관적으로 많이 성장했다. 그런데 지금의 나는 5년차, 7년차의 기준으로 나를 본다. 트위터에서 보이는 동년배 천재는 극단적인 아웃라이어인데, 그걸 기본값으로 놓고 나를 깎아내리고 있다.

이게 트레드밀이다. 실력은 올라가는데 기대치가 더 빨리 올라가니까 영원히 "부족하다"는 느낌에서 못 벗어난다.

## Satisficing은 게으름이 아니라 전략이다

Satisficing을 처음 알았을 때는 "그냥 대충 살라는 거 아닌가" 싶었다. 그런데 파고 들어가면 전혀 다른 이야기다.

핵심은 이거다. "충분히 좋은" 기준을 먼저 정하고, 그 기준을 넘으면 더 이상 비교하지 않는다. 이건 기준이 낮다는 뜻이 아니다. 기준을 의식적으로 선택한다는 뜻이다. 한 에세이스트는 성공한 사람들의 공통점이 "거의 모든 것에 No라고 말하는 능력"이라고 썼다. 더 많은 걸 쌓는 게 아니라, 불필요한 걸 빼는 것이 전략의 본질이라고.

개발자 커리어에서 maximizing은 이런 모습이다. 기술 블로그 주 1회, 오픈소스 기여, 사이드 프로젝트, 새벽 알고리즘, 영어 공부, 독서 모임. 전부 "좋은 개발자"가 해야 하는 일이라고 생각하고 동시에 달린다.

나도 해봤다. 한 달 만에 전부 포기했다. 아무것도 제대로 못 하면서 "왜 나는 이것도 못 하지" 하는 자책만 남았다. 전형적인 maximizer의 함정이다. 가능한 최선을 쫓으니까 어떤 것도 "충분히" 하지 못한다.

지금은 딱 두 가지만 한다. 회사 일 잘 하기, 가끔 블로그 쓰기. 이게 내 "충분히 좋은" 기준이다. 이 기준 안에서는 에너지가 집중되니까 퀄리티가 올라간다. 회사 업무에 집중하니까 코드 리뷰에서 "이 부분 좋네요"라는 코멘트 빈도가 늘었다. 블로그에 집중하니까 검색 유입이 조금씩 생기기 시작했다. 열 가지를 50%로 하는 것보다 두 가지를 90%로 하는 게 결과적으로 더 많은 걸 만들어낸다.

## 빼기가 더하기를 이기는 경우

흥미로운 실험이 하나 있다. 사람들에게 레고 구조물을 개선하라고 했더니, 대부분 블록을 추가하는 방식을 선택했다. 블록을 빼는 게 더 효과적인 상황에서도. 인간의 뇌는 "더하면 나아진다"는 편향이 있다.

개발자 커리어에서도 똑같다. "뭘 더 해야 성장할까?"는 항상 묻는데, "뭘 안 해야 성장할까?"는 잘 안 묻는다.

내 경우, 가장 효과적이었던 성장 전략은 트위터에서 다른 개발자의 성과를 구경하는 시간을 줄인 거였다. 비교 대상이 줄어드니까 불안이 줄었다. 불안이 줄어드니까 눈앞의 코드에 더 집중할 수 있었다. 집중하니까 결과물의 퀄리티가 올라갔다. 뭘 추가한 게 아니라 뭘 뺐을 뿐인데 실력이 느는 속도가 빨라졌다.

사이드 프로젝트를 억지로 유지하는 것도 그만뒀다. 주말에 쉬기로 했다. 이상하게도 월요일에 코드를 보는 게 전보다 덜 싫어졌다. 주말 내내 코드를 봤을 때는 월요일에 이미 지쳐 있었다. 쉬고 나니까 "어 이거 이렇게 하면 되겠는데"라는 생각이 자연스럽게 떠올랐다. 번아웃 상태에서 억지로 짜낸 아이디어보다 회복된 상태에서 떠오른 아이디어가 훨씬 쓸 만했다.

## 평범함의 복리

여기서 하나 짚고 넘어가고 싶은 게 있다. "평범해도 괜찮다"가 "성장 안 해도 된다"는 뜻은 절대 아니다. 성장의 방식이 다른 거다.

10x를 추구하는 성장은 단거리 달리기다. 단기간에 화려한 결과를 만들어내고, 눈에 보이는 성과를 쌓는다. 문제는 지속성이다. 그 속도를 2년, 3년, 5년 유지할 수 있는 사람은 거의 없다. 번아웃이 따라오고, 방향이 흔들리고, 기대치와 현실의 간극에 무너진다.

"충분히 좋은" 성장은 복리 구조다. 투자 세계에서 복리의 핵심은 수익률의 크기가 아니라 중단하지 않는 것이다. 연 50% 수익을 3년 내다가 원금을 날리는 것보다, 연 8%를 20년간 유지하는 게 최종 결과가 훨씬 크다. 커리어도 마찬가지다.

매일 조금씩 나아지는 게 어떤 모습인지 구체적으로 보면 이렇다. 어제는 코드 리뷰에서 "LGTM"만 남겼는데, 오늘은 개선 제안을 하나 달았다. 어제는 에러가 나면 console.log만 찍었는데, 오늘은 소스맵을 따라가서 원인을 찾았다. 어제는 PR 설명에 "로그인 기능 추가"만 썼는데, 오늘은 왜 이 방식을 선택했는지 한 줄 추가했다.

트위터에 올릴 만한 건 아니다. 좋아요 0개짜리 성장이다. 그런데 이런 게 6개월, 1년 쌓이면 꽤 달라진다. 복리의 무서운 점은 초반에는 거의 안 보인다는 거다. 매일 1%씩 나아지는 건 처음 석 달은 아무도 모른다. 6개월이 지나면 슬슬 보이기 시작하고, 1년이 지나면 "이 사람 언제 이렇게 됐지?" 소리를 듣게 된다.

우리 팀에 이걸 증명하는 동료가 한 명 있다. 매일 PR 하나씩 올리는 사람이다. 엄청 빠르지도 않고, 코드가 예술적이지도 않다. 그런데 절대 밀리지 않는다. 스프린트 완수율 100%. 화려하지 않지만 팀에서 제일 신뢰받는다. "이 사람한테 맡기면 나온다"는 신뢰. 1년 전에 합류했을 때는 평범하다고 생각했는데, 지금은 이 사람 없으면 팀이 안 돌아간다. 한 방이 아니라 매일의 반복이 만든 결과다.

## Good enough가 exceptional을 이긴 세 번의 경험

돌이켜보면, 내 커리어에서 "적당한"이 "최고"를 이긴 경우가 확실히 있었다.

첫 번째는 사이드 프로젝트다. 최고의 기술 스택, 최고의 아키텍처를 만들겠다며 3개월을 끌었다. 결국 출시 못 했다. 그 다음에 "그냥 작동하면 된다"는 마인드로 주말 이틀 만에 만든 개인 블로그는 지금까지 운영 중이다. 완벽한 0개보다 적당한 1개가 낫다. 이건 산술이 아니라 진짜 경험한 결과다.

두 번째는 기술 선택이다. 새 프로젝트를 시작할 때 한 동료가 최신 기술을 강하게 밀었다. 더 빠르고, 타입 안정성도 높고, 커뮤니티가 성장 중이라고. 나는 "팀원 전부가 이미 잘 아는 기술을 쓰자"고 했다. 결국 익숙한 기술을 골랐고, 프로젝트는 일정 안에 끝났다. 6개월 뒤에 그 최신 기술은 메이저 버전이 바뀌면서 breaking change가 잔뜩 생겼다. 만약 그걸 골랐으면 마이그레이션 지옥을 겪었을 거다.

세 번째는 이직 타이밍이다. 부트캠프 동기 중에 6개월마다 이직하면서 연봉을 빠르게 올린 사람이 있었다. 나는 첫 회사에 2년 넘게 있었다. 조급했지만 그 2년 동안 같은 코드베이스를 유지보수하면서 배운 게 있다. 기술 부채의 무게, 설계 결정이 6개월 뒤에 어떻게 돌아오는지, 팀원이 바뀔 때 문서의 가치가 얼마나 올라가는지. 이건 6개월 만에 이직하면 절대 배울 수 없는 종류의 지식이다. 그리고 이 지식이 결국 다음 이직에서 시니어 레벨의 면접 질문에 답할 수 있게 해줬다.

세 경우 모두 maximizing을 포기하고 satisficing을 선택한 결과다.

## 기대치를 조절하는 구체적인 방법

이건 체념이 아니다. 의식적인 기대치 설정이다.

내가 실제로 하는 건 이거다. 6개월 전에 짠 코드를 가끔 열어본다. "이걸 내가 짰다고?" 하면서 부끄러워지면, 그게 성장의 증거다. 6개월 전에 만든 컴포넌트를 열면, 왜 이렇게 긴 useEffect를 쓰고 있는지, 왜 상태를 이렇게 많이 만들었는지 바로 보인다. 이 부끄러움이 트위터의 좋아요 백 개보다 확실한 성장 지표다. 비교 대상이 남이 아니라 과거의 나이기 때문에 트레드밀에 빠지지 않는다.

투자 칼럼니스트의 글에 이런 문장도 있었다. "부유해지는 과정이 부유해진 상태보다 기분이 좋다." 커리어도 마찬가지다. "나는 아직 성장 중이다"라는 상태가 "나는 이제 다 됐다"보다 실제로 더 만족스럽다. 도달해야 할 지점이 아니라 걷고 있는 과정 자체에서 의미를 찾는 거다.

## 평범함의 수학

소프트웨어 산업에서 "평범한" 개발자의 역할은 구조적으로 과소평가되어 있다. 대부분의 소프트웨어는 평범한 개발자들이 만든다. 매일 출근해서 이슈 처리하고, 코드 리뷰하고, 미팅하고, 퇴근하는 사람들. 화려하지 않지만 서비스가 돌아가게 하는 사람들.

10x 엔지니어 한 명이 없어도 회사는 돌아간다. "평범한" 개발자 열 명이 동시에 나가면 서비스가 멈춘다. 구조적으로 보면 시스템의 안정성은 소수의 천재가 아니라 다수의 평범한 사람들의 꾸준함에 의존한다.

가끔 비개발자 친구들이 "개발자면 대단하지 않냐"고 묻는다. 안에 들어와서 보면 나도 그냥 직장인이다. 출근하기 싫은 월요일이 있고, 회의가 지루한 오후가 있고, 퇴근하면 치킨 시켜 먹으면서 예능 보는 저녁이 있다.

그런데 그게 나쁜 게 아니다. 어쩌면 그게 최적의 전략이다. 점심 메뉴를 고를 때 모든 식당을 비교하는 사람보다, "여기 괜찮겠다" 하고 들어간 사람이 식사를 더 즐기는 것처럼. 최선을 쫓느라 소진되는 것보다 충분히 좋은 기준 안에서 복리를 굴리는 게 장기적으로 더 멀리 간다. 그리고 장기전에서는 멈추지 않는 사람이 이긴다. 화려한 사람이 아니라.


2023년 가을, 새 프로젝트 킥오프 미팅이 있었다. 기존 서비스를 완전히 새로 만드는 거대한 리라이트 프로젝트. 프론트엔드 스택을 처음부터 다시 정할 수 있는, 개발자라면 누구나 설레는 그 순간이었다.

스택 논의 회의에서 한 동료가 말했다. "이번엔 Svelte로 가면 어때요? 번들 사이즈도 작고, DX도 React보다 훨씬 좋고, 벤치마크 보면 성능이 압도적이에요." 다른 동료가 거들었다. "Solid도 괜찮지 않아요? Signal 기반이라 렌더링 최적화가 기본으로 되고, React의 re-render 문제를 근본적으로 해결한 거잖아요." 회의실 분위기가 확 달아올랐다. 새로운 기술을 쓸 수 있다는 가능성에 다들 눈이 반짝였다.

그때 팀 리드가 조용히 물었다. "그럼 Svelte로 복잡한 폼 상태 관리할 때 라이브러리 뭐 쓸 건데? 서버 상태 캐싱은? 모노레포에서 빌드 파이프라인은 어떻게 잡을 건데?" 회의실이 조용해졌다.

## 이노베이션 토큰이라는 개념

Dan McKinley라는 엔지니어가 있다. Etsy에서 일했던 사람인데, "Choose Boring Technology"라는 유명한 발표를 했다. 핵심 아이디어는 간단하다. 모든 회사, 모든 팀에는 **이노베이션 토큰**이라는 게 있고, 그건 **대략 3개**뿐이다.

이 토큰은 새롭고 검증되지 않은 기술을 도입할 때 쓰는 일종의 예산이다. 새 기술 하나를 도입할 때마다 토큰을 1개 쓴다. 왜 3개뿐이냐면, 새로운 기술은 문서화되지 않은 문제들, 즉 unknown unknowns를 갖고 있기 때문이다. 오래된 기술은 어디서 터질지 대충 알 수 있다. MySQL이 어떤 조건에서 느려지는지, React의 re-render가 언제 문제가 되는지는 Stack Overflow에 답이 있다. 근데 6개월 된 프레임워크의 프로덕션 이슈? 누구도 모른다. 직접 부딪혀야 한다.

그래서 토큰은 정말 비즈니스에 핵심적인 곳에 써야 한다. 기술 스택 선택 같은 인프라 레벨이 아니라, 제품의 차별점이 되는 곳에. McKinley의 표현을 빌리면, "경제를 재편하거나 인터넷 GDP를 올리는" 문제에 써야 한다.

## 우리 팀의 선택

결국 우리는 React + Redux(정확히는 Redux Toolkit)를 선택했다. 2023년에 Redux라니, 올드하다고 느낄 수 있다. Zustand, Jotai, Recoil 같은 모던한 상태 관리 라이브러리가 넘쳐나는 시대에. 근데 이유가 있었다.

첫째, 팀원 7명 전원이 React 경험이 있었다. Svelte 경험자는 0명이었고, Solid를 실무에서 써본 사람도 없었다. 팀 전원이 새로운 프레임워크를 배우면서 동시에 복잡한 비즈니스 로직을 구현한다? 그건 도박이다.

둘째, Redux Toolkit은 "지루하지만 예측 가능"했다. 모든 상태 변경이 액션으로 추적되고, DevTools로 타임 트래블 디버깅이 되고, 미들웨어로 사이드 이펙트를 관리하는 패턴이 수년간 검증되어 있었다. 코드가 좀 verbose할 수는 있어도, 새로 합류하는 주니어가 패턴을 파악하는 데 하루면 충분했다.

셋째, 생태계의 크기. React로 X를 어떻게 하나요? 라고 검색하면 답이 나온다. 공식 문서, 블로그, 강의, Stack Overflow 답변, 유료 강의까지. Svelte로 같은 질문을 하면? 답이 있긴 한데, 그 답이 현재 버전에서도 유효한지 확인하는 데 또 시간이 든다.

## 지루하지 않은 선택이 불러온 재앙

이 결정을 내리기 1년 전 경험이 크게 작용했다. 2022년에 내부 어드민 툴을 만들 때 한 동료가 Remix를 강력 추천했다. 당시 Remix는 정말 핫했다. React Router를 만든 팀이 만들었고, nested routing과 loader 패턴이 혁명적이라는 평가가 넘쳤고, Kent C. Dodds가 열정적으로 밀고 있었다.

우리는 도입했다. 처음 2주는 정말 좋았다. loader에서 데이터를 가져오고, action에서 뮤테이션을 처리하고, 에러 바운더리가 자연스럽게 잡히는 그 느낌. "이게 웹 개발의 미래다"라고 진심으로 생각했다.

문제는 3주 차부터 시작됐다. 어드민 툴 특성상 복잡한 폼이 많았는데, 여러 단계에 걸친 폼 상태를 Remix의 철학대로 관리하려니 loader/action 패턴만으로는 부족했다. 클라이언트 사이드 상태와 서버 사이드 상태를 어떻게 조합할 것인지에 대해 명확한 가이드가 없었다. 공식 문서를 뒤지고, Discord를 탐색했지만, 비슷한 상황의 레퍼런스가 부족했다. 우리만의 패턴을 만들어야 했다.

그러다 6개월 뒤, Remix가 React Router에 합병된다는 발표가 나왔다. 방향 자체가 바뀐 거다. 우리가 학습하고 구축한 것들의 미래가 불투명해졌다. 결국 그 어드민 툴은 1년도 안 돼서 "레거시"가 됐다. 유지보수하는 사람이 "이건 도대체 왜 이렇게 되어 있는 거야?"라고 묻는 코드가 됐다.

## 매슬로의 욕구 위계와 기술 선택

McKinley가 재밌는 비유를 했다. 매슬로의 욕구 위계처럼, 엔지니어링 팀에도 위계가 있다는 거다. 기본 욕구(안정적인 인프라, 예측 가능한 배포)가 충족되지 않으면, 상위 욕구(혁신적인 제품, 차별화된 UX)에 집중할 수 없다. 데이터베이스 선택 때문에 매주 회의하는 팀이 어떻게 제품 전략을 논의할 수 있을까.

이걸 프론트엔드에 대입하면 이렇다. 빌드 시스템이 매일 깨지고, 상태 관리 패턴에 대해 팀원마다 의견이 다르고, 프레임워크 업데이트 때마다 breaking change가 터지는 팀은 — 정작 사용자 경험을 개선할 여유가 없다. 번들 사이즈를 최적화하고, 인터랙션을 개선하고, 접근성을 높이는 진짜 중요한 일을 할 시간이 인프라 소방에 다 빠지는 거다.

우리 팀이 React + Redux를 고른 뒤 실제로 벌어진 일이 이걸 증명한다. 스택에 대한 논쟁이 사라지니까, 에너지가 제품으로 갔다. 검색 UX를 완전히 새로 설계하는 데 2주를 집중할 수 있었다. 만약 Svelte를 학습하느라 그 2주를 썼다면, 검색 UX는 기존 패턴을 복붙하는 선에서 끝났을 거다. 이노베이션 토큰을 스택이 아니라 제품에 쓴 거다.

## 도구를 마스터하라

사람들이 기술을 바꾸려는 시점이 있다. McKinley에 따르면, 모든 기술에는 "행복 곡선"이 있다. 처음에는 새롭고 신선해서 좋다. 그 다음 한계에 부딪히면서 불만이 생긴다. "이 프레임워크 왜 이래?"라는 불만이 최고조에 달하는 시점이 온다. 근데 그 골짜기를 지나면, 도구를 진짜로 이해하기 시작한다. 한계를 알고 있으니 우회할 수 있고, 패턴이 손에 익으니 생산성이 확 올라간다. 문제는, 대부분의 개발자가 골짜기에서 새 기술로 갈아탄다는 거다. 그러면 또 새 기술의 골짜기가 시작된다. 영원히 골짜기만 경험하는 셈이다.

React가 정확히 이런 케이스다. useEffect가 짜증나고, re-render 최적화가 귀찮고, 상태 관리가 복잡하다고 느끼는 시점이 온다. "Svelte면 이런 고민 안 해도 되는데..." 하는 생각이 든다. 근데 Svelte로 가면 거기엔 또 다른 골짜기가 있다. Svelte 5의 Runes가 기존 문법을 크게 바꿔서 생태계가 혼란스러운 시기, SvelteKit의 라우팅 관련 edge case, 대형 프로젝트에서의 상태 관리 패턴 부재 같은 것들.

## 지루함은 자신감이다

Dan Abramov가 자신의 블로그에서 흥미로운 접근을 보여준다. React의 핵심 개발자였던 그가 강조하는 건 항상 "기본기"다. 새로운 API나 패턴보다, JavaScript 클로저가 어떻게 동작하는지, 컴포넌트의 생명주기를 정확히 이해하고 있는지, 사이드 이펙트를 왜 이렇게 다루는지 — 이런 근본적인 이해를 강조한다. 화려한 새 프레임워크보다, 지금 쓰고 있는 도구를 깊이 이해하는 게 먼저라는 뜻이다.

지루한 기술을 선택한다는 건, 자신감의 표현이다. "우리는 이미 검증된 도구로도 훌륭한 제품을 만들 수 있어"라는 선언이다. 반대로, 항상 새로운 기술을 쫓는 건 어쩌면 "기존 도구로는 한계가 있어"라는 불안의 표현일 수도 있다.

물론, 영원히 지루한 기술만 고수하라는 건 아니다. React도 한때는 "지루하지 않은 선택"이었다. 2015년에 jQuery 대신 React를 도입하는 건 분명히 이노베이션 토큰을 쓰는 결정이었다. 핵심은 **의도적인 선택**이다. "이게 새롭고 멋있으니까"가 아니라, "이 토큰을 여기에 쓰는 것이 우리 팀과 제품에 가장 큰 가치를 줄 것인가"라는 질문.

## 3개의 토큰을 어디에 쓸 것인가

지금 프로젝트를 되돌아보면, 우리는 이노베이션 토큰을 이렇게 썼다.

**토큰 1**: 서버 상태 관리에 TanStack Query를 도입했다. 당시 팀에서 처음 쓰는 라이브러리였지만, API 캐싱과 동기화 문제를 근본적으로 해결해줬다. 학습 곡선이 있었지만, 쓸 가치가 충분했다.

**토큰 2**: 모노레포 구조를 Turborepo로 잡았다. 패키지 간 의존성 관리와 빌드 최적화가 필요했고, 이건 직접 스크립트를 짜서 해결하기엔 너무 복잡했다.

**토큰 3**: 디자인 시스템을 자체 구축하기로 했다. 이건 제품 차별화에 직접 기여하는 결정이었고, 기존 UI 라이브러리로는 요구사항을 맞출 수 없었다.

프레임워크(React)와 상태 관리 패턴(Redux Toolkit)은 토큰을 안 쓴 거다. "지루한" 선택이었지만, 덕분에 토큰을 진짜 필요한 곳에 집중할 수 있었다.

## 지루함의 역설

아이러니한 건, 지루한 기술을 선택한 결과가 전혀 지루하지 않다는 거다. 스택 논쟁에 에너지를 안 쓰니까, 실제 제품 경험이 혁신적이 될 수 있었다. 사용자는 우리가 Svelte를 쓰든 React를 쓰든 신경 안 쓴다. 검색이 빠르고, 결제가 매끄럽고, 에러가 적은 걸 원할 뿐이다.

가끔 트위터에서 프레임워크 논쟁이 벌어지면 구경하면서 생각한다. 저 에너지를 제품에 쓰면 더 좋을 텐데. 근데 또 그런 논쟁 속에서 배우는 것도 있으니까 마냥 무의미하진 않다. 다만, 회사의 프로덕션 코드를 가지고 그 실험을 하지 않았으면 좋겠다.

McKinley의 말을 프론트엔드 버전으로 바꾸면 이렇다. "당신의 React 프로젝트가 지루해 보인다면, 그건 아마 제대로 하고 있다는 뜻이다."

지루한 기술을 선택하는 데는 용기가 필요하다. 회의에서 "우리 그냥 React 쓰죠"라고 말하는 건, "Svelte 써봅시다!"보다 훨씬 덜 흥미진진하다. 근데 그 지루한 선택이, 나중에 팀이 야근 안 하고 집에 가는 이유가 된다. 프로덕션에서 새벽 3시에 알림이 울리지 않는 이유가 된다. 그게 진짜 용기다.


면접에서 "브라우저에 URL을 입력하면 무슨 일이 일어나나요?"라는 질문을 받은 적이 있다. DNS 조회부터 TCP 연결, HTML 파싱까지는 어렵지 않게 답했는데, "그 다음에 화면이 어떻게 그려지나요?"에서 막혔다. "DOM 트리를 만들고... 렌더링하고..."라고 얼버무렸다. 면접관이 고개를 끄덕이긴 했는데, 내가 봐도 얕은 답이었다.

그때는 그냥 면접 지식이라고 생각했다. 렌더링 파이프라인을 외우면 면접에서 한 문제 더 맞출 수 있겠지, 정도. 그런데 실무에서 성능 문제를 디버깅하면서 이 지식이 진짜 쓸모 있다는 걸 알게 됐다. 파이프라인을 설명하는 글은 인터넷에 넘치니까, 이 글에서는 파이프라인을 알고 나서 실제로 문제를 해결한 세 가지 이야기를 하려고 한다.

## 파이프라인을 간단하게만 짚고

브라우저가 HTML을 받아서 픽셀을 화면에 찍기까지 5단계를 거친다.

**JavaScript → Style → Layout → Paint → Composite**

각 단계가 뭘 하는지는 짧게 요약한다.

- **Style**: CSS 규칙을 DOM 요소에 매칭하고 최종 computed style을 계산한다.
- **Layout**: 각 요소의 크기와 위치를 계산한다. `width`, `height`, `padding`, `margin`, `top`, `left` 같은 속성이 여기서 처리된다.
- **Paint**: 배경색, 텍스트, 테두리, 그림자 등 실제 픽셀을 채운다.
- **Composite**: 페인트된 레이어들을 합성해서 최종 화면을 만든다. GPU가 담당한다.

핵심은 이거다. 어떤 CSS 속성을 바꾸느냐에 따라 파이프라인의 어디서부터 다시 실행되는지가 달라진다.

- `width`를 바꾸면? Layout부터 다시. 가장 비싸다.
- `background-color`를 바꾸면? Paint부터 다시. Layout은 안 한다.
- `transform`이나 `opacity`를 바꾸면? Composite만 다시. 가장 싸다. GPU가 처리하니까 메인 스레드도 안 막는다.

web.dev의 렌더링 퍼포먼스 가이드에서 이걸 세 가지 경로로 정리하고 있다. 전체 파이프라인을 타는 경로, Paint부터 타는 경로, Composite만 타는 경로. 그리고 프레임 예산이라는 개념을 쓴다. 60fps를 유지하려면 프레임 하나에 16.66ms가 주어지는데, 브라우저의 오버헤드를 빼면 실제로 개발자가 쓸 수 있는 시간은 약 10ms라는 거다. 10ms 안에 한 프레임의 작업을 끝내야 버벅거림이 없다.

이 정도만 알고 있으면 된다. 이제 이걸로 실제 문제를 해결한 이야기를 하겠다.

## 이야기 1: 매 프레임마다 Layout을 돌리고 있었다

커머스 프로젝트에서 모바일 슬라이드 메뉴를 만들었다. 햄버거 버튼을 누르면 왼쪽에서 메뉴가 슬라이드인 되는 전형적인 패턴이다. 처음에는 `left` 속성으로 구현했다.

```css
.menu {
  position: fixed;
  top: 0;
  left: -280px;
  width: 280px;
  height: 100vh;
  transition: left 0.3s ease;
}
.menu.open {
  left: 0;
}
```

데스크탑에서는 부드러웠다. QA 팀이 "모바일에서 끊김이 있어요"라고 리포트했을 때, "디바이스 성능 문제겠지" 하고 넘겼다. 그런데 저사양 안드로이드에서 직접 확인해보니 진짜 뚝뚝 끊겼다. 애니메이션 중간에 프레임이 드롭되는 게 눈에 보였다.

Chrome DevTools의 Performance 탭을 녹화해봤다. 프레임 차트에서 보라색(Layout)이 매 프레임마다 큰 덩어리로 찍히고 있었다. `left` 값이 변할 때마다 Layout이 재계산되고 있었던 거다. 메뉴뿐 아니라, 메뉴 뒤에 있는 페이지 콘텐츠의 레이아웃까지 영향을 받고 있었다.

`transform`으로 바꿨다.

```css
.menu {
  position: fixed;
  top: 0;
  left: 0;
  width: 280px;
  height: 100vh;
  transform: translateX(-100%);
  transition: transform 0.3s ease;
}
.menu.open {
  transform: translateX(0);
}
```

Performance 탭을 다시 확인했다. 보라색이 사라졌다. 초록색(Composite)만 얇게 찍혔다. 저사양 안드로이드에서도 부드럽게 동작했다. `transform`은 Composite 단계에서만 처리되니까 Layout과 Paint를 건너뛰고, GPU가 레이어를 움직이기만 하면 되는 거다.

이 한 번의 경험으로 "위치 이동 애니메이션은 무조건 `transform`을 쓴다"가 몸에 각인됐다. `top`, `left`, `right`, `bottom`으로 애니메이션하는 코드를 보면 바로 PR에 코멘트를 남기게 됐다.

## 이야기 2: will-change가 오히려 성능을 악화시킨 건

두 번째 경험은 좀 뼈아팠다. 첫 번째 경험 이후에 "GPU 가속이 좋구나"라는 걸 배웠고, 좀 과하게 적용했다. 상품 리스트 페이지에서 카드 호버 애니메이션이 있었는데, 모든 카드에 `will-change: transform`을 넣었다.

```css
.productCard {
  will-change: transform;
  transition: transform 0.2s;
}
.productCard:hover {
  transform: translateY(-4px);
}
```

"미리 레이어를 만들어두면 호버할 때 더 빠르겠지"라는 생각이었다. 상품이 12개인 페이지에서는 괜찮았다. 문제는 무한 스크롤로 상품이 100개, 200개 쌓이기 시작했을 때 터졌다. 페이지가 점점 느려지다가 탭이 크래시나는 리포트가 들어왔다.

Chrome DevTools의 Layers 패널을 열어봤다. 레이어가 200개 넘게 찍혀 있었다. `will-change: transform`은 요소를 별도의 합성 레이어로 승격시킨다. 레이어가 많아지면 GPU 메모리를 많이 쓰고, 레이어 합성 자체에도 비용이 든다. 상품 200개 = 레이어 200개 = GPU 메모리 폭발.

해결법은 두 가지였다. 우선 `will-change`를 CSS에서 제거하고, JavaScript로 호버 시에만 동적으로 붙이는 방법을 썼다.

```tsx
function ProductCard({ product }: Props) {
  const handleMouseEnter = (e: React.MouseEvent<HTMLDivElement>) => {
    e.currentTarget.style.willChange = "transform";
  };
  const handleMouseLeave = (e: React.MouseEvent<HTMLDivElement>) => {
    e.currentTarget.style.willChange = "auto";
  };

  return (
    <div
      className="product-card"
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
    >
      {/* ... */}
    </div>
  );
}
```

호버가 시작될 때 레이어를 만들고, 끝나면 해제한다. 동시에 존재하는 레이어 수가 최대 1~2개로 제한된다.

사실 더 좋은 해결법은 `will-change` 자체를 안 쓰는 거였다. `transform` 애니메이션은 브라우저가 이미 잘 최적화하고 있어서, 명시적으로 `will-change`를 붙이지 않아도 대부분의 경우 충분히 부드럽다. `will-change`는 정말 복잡한 애니메이션에서 마지막 수단으로만 쓰는 게 맞다.

```css
/* 이건 절대 하면 안 된다 */
* {
  will-change: transform;
}
```

이런 코드를 Stack Overflow에서 본 적이 있다. "성능 개선 팁"이라면서. 정반대의 결과를 가져온다.

## 이야기 3: Forced Reflow로 리스트 렌더링이 3초 걸린 건

대시보드 페이지에 데이터 테이블이 있었다. 행이 100개 정도인데, 각 행의 높이를 측정해서 가상 스크롤에 쓰는 로직이 있었다. 테이블을 렌더링할 때 체감상 3초 정도 멈추는 현상이 있었다.

Performance 탭을 보니 Layout이 반복적으로 수백 번 찍혀 있었다. 코드를 확인해보니 이런 패턴이었다.

```typescript
// 문제의 코드
rows.forEach((row) => {
  const height = row.offsetHeight; // 읽기 → Forced Reflow
  row.style.minHeight = height + "px"; // 쓰기
  row.dataset.measured = "true";
});
```

루프를 돌면서 읽기와 쓰기를 반복하고 있었다. `offsetHeight`를 읽으려면 브라우저가 최신 레이아웃을 계산해야 한다. 그런데 바로 직전에 `style.minHeight`를 바꿨으니까, 레이아웃이 무효화된 상태다. 그래서 매 반복마다 레이아웃 전체를 다시 계산한다. 행이 100개면 Layout 계산이 100번 일어나는 거다. 이걸 Forced Reflow, 또는 Layout Thrashing이라고 한다.

리플로우를 트리거하는 속성들이 따로 있다.

```typescript
// 이것들을 읽으면 Forced Reflow가 발생할 수 있다
element.offsetTop;
element.offsetHeight;
element.scrollTop;
element.clientHeight;
element.getComputedStyle();
element.getBoundingClientRect();
```

해결은 읽기를 먼저 다 하고, 쓰기를 나중에 모아서 하는 거다.

```typescript
// 수정된 코드: 읽기를 먼저, 쓰기를 나중에
const heights: number[] = [];
rows.forEach((row) => {
  heights.push(row.offsetHeight); // 읽기만
});

rows.forEach((row, i) => {
  row.style.minHeight = heights[i] + "px"; // 쓰기만
  row.dataset.measured = "true";
});
```

이렇게 바꾸니까 Layout 계산이 1~2번으로 줄었다. 3초 걸리던 게 50ms로 줄었다. 60배 차이.

React에서는 직접 DOM을 조작하는 일이 적어서 이 문제를 덜 마주치지만, `useLayoutEffect`에서 DOM 측정을 할 때 주의해야 한다.

```tsx
function useElementSize(ref: RefObject<HTMLElement>) {
  const [size, setSize] = useState({ width: 0, height: 0 });

  useLayoutEffect(() => {
    if (!ref.current) return;
    const { width, height } = ref.current.getBoundingClientRect();
    setSize({ width, height });
  }, []);

  return size;
}
```

`useLayoutEffect`는 Paint 전에 실행되기 때문에, DOM 측정 후 상태를 업데이트해도 화면 깜빡임이 없다. `useEffect`에서 하면 화면이 한 번 그려진 후에 업데이트되어서 레이아웃이 깜빡일 수 있다.

## DevTools가 "감"을 "측정"으로 바꿔준다

세 가지 이야기에서 공통점이 있다. 전부 Chrome DevTools의 Performance 탭으로 확인했다는 거다.

1. Performance 탭을 열고 녹화 버튼을 누른다.
2. 문제가 되는 인터랙션을 실행한다.
3. 녹화를 멈추고 프레임 차트를 본다.

보라색이 Layout, 초록색이 Paint, 노란색이 JavaScript다. Layout이 매 프레임 큰 블록으로 찍히면 레이아웃 쪽을 의심하면 된다.

Rendering 탭에서 "Paint flashing"을 켜면 Paint가 일어나는 영역이 초록색으로 깜빡인다. 스크롤할 때 전체 페이지가 초록색으로 번쩍이면 뭔가 문제가 있다는 뜻이다. 고정 헤더가 매 프레임마다 리페인트되고 있거나, 불필요한 영역이 다시 그려지고 있다는 거다.

Layers 패널은 `will-change` 이슈를 디버깅할 때 쓴다. 레이어가 예상보다 많으면 불필요한 레이어 승격이 일어나고 있을 가능성이 높다.

## 렌더링 예산이라는 사고방식

웹 성능에 대해 깊이 쓰는 한 엔지니어가 "성능 예산"이라는 개념을 강조한다. JavaScript 예산, 이미지 예산처럼, 렌더링에도 예산이 있다는 거다. 한 프레임에 10ms. 이 예산 안에서 JavaScript 실행, Style 계산, Layout, Paint, Composite을 전부 끝내야 한다.

이 사고방식이 좋은 이유는, "이 코드가 느린가?"라는 모호한 질문을 "이 코드가 프레임 예산 10ms를 초과하는가?"라는 측정 가능한 질문으로 바꿔주기 때문이다. Performance 탭에서 한 프레임이 10ms를 넘으면 문제고, 안 넘으면 괜찮은 거다. 감이 아니라 숫자로 판단할 수 있다.

INP(Interaction to Next Paint)라는 Core Web Vitals 지표도 같은 맥락이다. 사용자가 클릭이나 키 입력을 했을 때, 다음 프레임이 화면에 그려지기까지 걸리는 시간을 측정한다. 200ms 이하가 권장값이다. 렌더링 파이프라인의 어느 단계에서 시간이 오래 걸리는지를 알아야, INP를 개선할 방향이 보인다.

## 면접 지식이 아니었다

렌더링 파이프라인을 처음 공부했을 때는 면접용이라고 생각했다. `left` 대신 `transform`을 쓰라는 팁도 "그냥 외워두면 되는 것" 정도였다. 직접 성능 문제를 마주하고 나서야 이게 실무 도구라는 걸 깨달았다.

슬라이드 메뉴의 `left`를 `transform`으로 바꿨을 때 Performance 탭에서 보라색이 사라지는 걸 눈으로 확인한 순간, `will-change`를 잘못 써서 레이어가 200개 생긴 걸 Layers 패널에서 발견한 순간, Forced Reflow를 분리해서 3초가 50ms로 줄어든 순간. 이런 경험이 쌓이면 렌더링 파이프라인은 외우는 지식이 아니라, 문제를 보는 눈이 된다.

코드를 쓸 때 무의식적으로 "이건 Layout을 트리거하나?" "이건 Composite만으로 되나?"를 생각하게 된다. 성능 문제가 생겼을 때 어디부터 봐야 하는지 감이 온다. 브라우저와 같은 편에 서서 작업하는 느낌이랄까. 브라우저가 어떻게 일하는지를 이해하면, 브라우저에게 효율적인 일을 시킬 수 있다.



스탠드업 미팅에서 "오늘까지 할게요"라고 말한 일이 있었다. 오후에 예상 못한 이슈가 터져서 결국 못 끝냈다. 다음 날 스탠드업에서 "어제 말한 건 좀 밀렸고요..."라고 했을 때, 팀 리드 표정이 미묘하게 변했다. 화난 건 아닌데, 뭔가 실망한 느낌. 그 표정이 머릿속에 남았다.

일주일 뒤에 비슷한 상황이 또 왔다. 이번에는 달랐다. 오후 3시쯤 "이 이슈 때문에 오늘 안에 끝내기 어려울 것 같은데, 내일 오전까지 가능할 것 같습니다"라고 슬랙으로 미리 공유했다. 팀 리드가 "ㅇㅇ 알겠어, 내일 오전까지 부탁"이라고 답했다. 같은 결과인데 반응이 완전히 달랐다.

## 신뢰는 능력이 아니라 예측 가능성이다

이때 깨달은 건, 팀에서의 신뢰는 "일을 잘하는 것"이 아니라 "이 사람이 뭘 할지 예측할 수 있는 것"이라는 거다.

시니어 한 분이 있었는데, 기술적으로 팀에서 가장 뛰어난 사람은 아니었다. 근데 모두가 신뢰했다. 이유를 관찰해보니 패턴이 있었다. 이 분은 "된다"고 말하면 무조건 됐다. "모르겠다"고 말하면 정말 모르는 거였다. "금요일까지"라고 하면 금요일에 나왔다. 목요일에 나올 때도 있었는데, "금요일"이라고 말한 이상 금요일을 넘긴 적은 없었다.

이 분은 한 번도 "이건 쉬워"라고 말한 적이 없다. 항상 현실적인 예상을 했다. 때로는 보수적이라고 느낄 정도로. 근데 그게 신뢰의 핵심이었다. 기대치를 낮게 잡고 초과 달성하는 게, 높게 잡고 못 미치는 것보다 100배 낫다.

반대의 경우도 봤다. 기술적으로는 훌륭한데 신뢰도가 낮은 동료가 있었다. 일정을 항상 낙관적으로 잡았다. "이틀이면 될 것 같은데요"라고 해서 기다리면 4일이 걸렸다. 한 번 두 번은 괜찮은데, 이게 반복되면 "이 사람이 이틀이라고 하면 실제로는 일주일 잡아야 한다"는 인식이 생긴다. 능력이 부족한 게 아니라 예측이 안 되는 거다.

## 작은 약속들

큰 프로젝트에서 일정을 잘 맞추는 것도 중요하지만, 일상적인 작은 약속이 더 영향이 크다.

"오늘 중으로 리뷰 남길게요"라고 했으면 정말 그날 남기기. "내가 확인해볼게"라고 했으면 확인하고 결과를 공유하기. "다음 스탠드업 때 공유할게"라고 했으면 잊지 않고 공유하기. 이런 것들이다.

나도 처음에는 이걸 자주 놓쳤다. 바쁘다 보면 "리뷰 남기겠다"고 해놓고 까먹는 경우가 생겼다. 상대방 입장에서는 기다리고 있는데 아무런 연락이 없으니 답답하다. 그래서 나는 약속한 일을 바로 캘린더에 적기 시작했다. "3시: A 리뷰 남기기", "퇴근 전: B에게 확인 결과 공유". 이게 별거 아닌 것 같지만 실제로 해보면 하루에 이런 약속이 3~4개는 생긴다. 캘린더에 안 적으면 하나쯤은 반드시 빠뜨린다. 사소하지만 이게 쌓이면 "이 사람한테 부탁하면 된다"는 인식으로 이어진다.

한번은 야근하면서 힘들게 끝낸 작업이 있었는데, 그보다 더 고마웠다고 팀원이 말한 건 다른 거였다. "그때 리뷰 빨리 해줘서 일정 맞출 수 있었어." 리뷰하는 데 20분밖에 안 걸렸는데, 상대방한테는 블로커가 풀린 거라 임팩트가 컸던 거다.

## 모르는 건 모른다고 말하기

신뢰를 깎아먹는 가장 빠른 방법은 아는 척하는 거다.

미팅에서 기술적인 논의가 나왔는데, 내가 잘 모르는 영역이었다. 근데 모른다고 말하기가 민망해서 적당히 고개만 끄덕였다. 그러다 "이 부분 어떻게 생각해?"라는 질문을 받았을 때, 대충 아는 것만으로 답했다. 틀린 말을 한 건 아닌데, 정확하지도 않았다. 나중에 시니어가 조용히 말해줬다. "그 부분 좀 달라, 다음에는 잘 모르면 모른다고 해도 돼."

그 뒤로는 모르는 건 바로 말한다. "그 부분은 제가 잘 몰라서 찾아보고 공유할게요." 이게 오히려 신뢰를 쌓는다. 이 사람이 "안다"고 말하면 정말 아는 거라는 확신을 주니까.

## 투명하게 일하기

슬랙에서 진행 상황을 공유하는 습관이 신뢰에 영향을 많이 줬다.

예전에는 작업이 끝나면 결과만 공유했다. "A 작업 완료했습니다." 지금은 중간중간에도 공유한다. "A 작업 시작합니다. 예상 소요 시간 3시간." 그리고 중간에 이슈가 생기면 "B 이슈 때문에 1시간 정도 추가 소요될 것 같습니다." 작업이 끝나면 "A 작업 완료. PR 올렸습니다."

과하다고 느낄 수도 있는데, 이렇게 하면 다른 사람이 내 상태를 물어볼 필요가 없다. 리드 입장에서도 팀원의 상태를 파악하기 위해 매번 "어디까지 했어?"라고 물어보는 건 부담이다. 알아서 공유해주면 그만큼 마이크로매니징을 줄일 수 있고, 자율성이 생긴다.

## 실수했을 때가 진짜 시험이다

신뢰는 쌓는 데는 오래 걸리지만 무너지는 건 한순간이라는 말이 있다. 근데 내 경험은 좀 달랐다. 실수를 어떻게 처리하느냐에 따라 오히려 신뢰가 올라가기도 했다.

한번 배포 후에 특정 페이지에서 레이아웃이 깨지는 버그가 발견됐다. 내 코드였다. CSS 변경이 다른 페이지에 영향을 준 건데, 로컬에서는 확인이 안 됐던 케이스였다.

바로 세 가지를 했다. 첫째, 슬랙에 "이 이슈 제 코드에서 발생한 거 맞습니다, 지금 수정 중입니다"라고 올렸다. 둘째, 원인과 수정 방향을 간단하게 공유했다. 셋째, 핫픽스를 배포하고 "수정 완료, 재발 방지를 위해 해당 영역 스타일 격리 처리했습니다"라고 마무리했다. 전체 과정이 40분이었다.

나중에 팀 리드가 "대응 빨랐다"고 했다. 버그를 낸 것보다 빠르게 인정하고 해결한 과정이 더 인상적이었다고. 실수 자체는 누구나 한다. 중요한 건 실수 이후의 행동이다.

## 일관성의 힘

이것저것 썼지만 결국 하나로 모인다. 일관성.

좋은 날에만 약속을 지키는 게 아니라, 바쁜 날에도, 컨디션이 안 좋은 날에도 같은 태도를 유지하는 것. 기분이 좋을 때만 친절하게 리뷰하는 게 아니라, 항상 같은 톤으로 피드백하는 것. 이게 쌓이면 동료들이 나를 예측할 수 있게 되고, 예측 가능한 사람에게 일이 맡겨진다.

솔직히 항상 일관되기는 어렵다. 나도 컨디션 나쁜 날에는 리뷰가 대충 되기도 하고, 피곤하면 약속을 잊기도 한다. 완벽할 수는 없다. 다만 그런 날에도 "의식적으로 노력하고 있다"는 것 자체가 차이를 만드는 것 같다.

## 리모트에서의 신뢰

재택근무 날에는 신뢰가 더 중요해진다. 얼굴이 안 보이니까.

우리 팀은 주 2일 재택을 하는데, 재택하는 날에 응답이 느린 사람이 있으면 "일 안 하나?"라는 의심이 은근히 생긴다. 실제로는 집중해서 코딩하고 있는 건데, 슬랙 응답이 안 오면 그렇게 보일 수 있다. 그래서 나는 재택하는 날에 오히려 더 자주 슬랙에 상태를 공유한다. "지금 이 작업 집중 중이라 슬랙 확인이 늦을 수 있어요"라고 미리 말해두면 상대방도 기다릴 수 있다.

한번은 재택하는 날 컨디션이 안 좋아서 오후에 잠깐 낮잠을 잔 적이 있다. 30분 정도였는데, 일어나보니 슬랙에 멘션이 3개 와 있었다. 다행히 급한 건 아니었지만, 바로 답하면서 "잠깐 자리 비웠습니다"라고 솔직하게 말했다. 이런 작은 솔직함이 쌓이면 "이 사람은 안 보이는 곳에서도 성실하다"는 인식으로 이어진다. 반대로 한번이라도 거짓말이 들키면 그 신뢰를 되찾기가 정말 어렵다.

## 신뢰와 속도

신뢰가 쌓이면 업무 속도가 빨라진다는 것도 느꼈다.

리드가 나를 신뢰하게 된 이후로, 마이크로매니징이 줄었다. 예전에는 중간 점검이 잦았는데, 이제는 "이거 맡길게, 금요일까지 부탁"으로 끝난다. 자율성이 높아지니까 내 방식대로 일할 수 있고, 효율도 올라갔다. 신뢰가 곧 자유라는 걸 체감한 셈이다.

코드 리뷰에서도 차이가 있다. 내 PR에 대한 리뷰가 빨라졌다. 이건 내 추측인데, 리뷰어가 "이 사람 PR은 기본적인 건 잘 챙겼을 거야"라는 기대가 있으면 리뷰에 쓰는 에너지가 줄어드는 것 같다. 반대로 신뢰가 없는 상태에서는 한 줄 한 줄 의심하면서 봐야 하니까 시간이 더 걸린다.

팀에서 신뢰받는 사람이 되고 싶다면 화려한 기술 스택이나 대단한 성과보다, 매일매일의 작은 약속을 지키는 것부터 시작하는 게 빠르다. 적어도 내 경험에서는 그랬다.


어느 날 아침에 맥북을 열었는데 코드를 치고 싶지 않았다. 처음이었다. 나는 코드 치는 게 좋아서 이 일을 시작한 사람이다. 퇴근하고 집에 와서도 사이드 프로젝트를 하고, 주말에 새로운 라이브러리 나오면 만져보는 게 재미있었다. 그런 내가 VS Code 창을 띄워놓고 커서만 깜빡이는 걸 5분 동안 멍하니 보고 있었다.

그때는 몰랐다. 이게 번아웃이라는 걸.

## 서서히 무너지는 과정

돌이켜보면 신호는 몇 달 전부터 있었다. 당시 팀에서 대규모 리뉴얼 프로젝트를 맡고 있었다. 기존 서비스를 Next.js로 마이그레이션하면서 동시에 신규 기능도 추가해야 했다. 릴리즈 일정은 8주. 어떻게 봐도 12주짜리 작업이었는데 비즈니스 쪽에서 이미 날짜를 잡아버렸다.

야근이 시작됐다. 처음에는 "이번 스프린트만" 이라고 생각했다. 그 다음 스프린트도 마찬가지였다. 저녁 9시, 10시에 퇴근하는 게 당연해졌다. 주말에 슬랙 알림이 울리면 반사적으로 확인했다. "혹시 프로덕션 장애일 수도 있으니까"라고 스스로를 합리화했는데, 실제로 긴급한 건 열 번에 한 번 정도였다. 나머지 아홉 번은 다음 주에 봐도 되는 것들이었다.

문제는, 쉬는 시간에도 머릿속이 코드였다는 거다. 샤워하면서 컴포넌트 구조를 생각하고, 자기 전에 "내일 저 API 연동 어떻게 하지" 고민하고, 꿈에서 git conflict를 해결하고 있었다. 몸은 퇴근했는데 뇌는 아직 회사에 있었다.

어느 순간부터 코드 리뷰가 짜증나기 시작했다. 예전에는 동료가 남긴 코멘트를 보면 "아 그렇네" 하고 배웠는데, 그때는 "이걸 왜 지적하지, 동작하잖아"라는 생각이 먼저 들었다. PR을 올리는 것 자체가 귀찮았다. 커밋 메시지도 대충 썼다. `fix`, `update`, `wip`. 그전까지 나는 커밋 메시지를 꽤 성의 있게 쓰는 편이었다.

그러다가 그 아침이 온 거다. 맥북 앞에 앉아서 아무것도 할 수 없었던 아침.

## "쉬면 되지"라는 말의 함정

처음에는 단순하게 생각했다. 피곤해서 그런 거다. 주말에 푹 쉬면 괜찮아질 거다.

금요일 저녁, 의식적으로 노트북을 닫았다. 토요일은 늦잠 자고, 넷플릭스 보고, 낮잠도 잤다. 일요일도 비슷하게 보냈다. 충분히 쉬었다고 생각했다.

월요일 아침. 출근길 지하철에서 슬랙을 열었는데 읽지 않은 메시지가 43개였다. 가슴이 답답해졌다. 자리에 앉아서 모니터를 켜는데 지난주랑 똑같은 느낌이었다. 쉬었는데 하나도 나아지지 않았다.

그래서 다른 방법을 시도했다. 코딩을 "재미있게" 하면 되지 않을까. 주말에 간단한 사이드 프로젝트를 시작했다. 요즘 핫한 라이브러리를 써서 뭔가 만들어보자. 예전에는 이런 게 최고의 충전이었으니까.

30분 만에 닫았다. `npm create`를 치고 프로젝트 구조가 생성되는 걸 보는 순간 피로감이 밀려왔다. 또 컴포넌트, 또 상태 관리, 또 API 호출. 업무에서 매일 하는 것들이었다. 놀이가 아니라 초과 근무 같았다.

이때 깨달았다. 이건 단순한 피로가 아니다. 쉰다고 해결되는 게 아니다. 뭔가 근본적으로 잘못된 게 있다.

## 코드와 전혀 관계없는 것들

전환점은 사소한 데서 왔다. 어느 일요일 오후, 할 게 없어서 냉장고에 있는 재료로 요리를 해봤다. 유튜브에서 파스타 레시피를 검색해서 따라 만들었다. 올리브 오일에 마늘을 볶을 때 나는 소리, 면이 익어가는 과정, 접시에 담았을 때의 모양. 40분 동안 코드는 한 번도 생각나지 않았다.

먹어보니 맛있었다. 이게 중요하다. 결과물이 바로 눈앞에 있고, 바로 맛볼 수 있고, 그걸로 끝이다. 배포할 필요도 없고, 코드 리뷰를 받을 필요도 없고, 장애가 날 일도 없다. 완결된 경험.

그 다음 주에는 동네 뒷산에 올라갔다. 등산이라고 하기에도 민망한, 왕복 1시간짜리 야트막한 산이었다. 올라가면서 숨이 차고 다리가 뻐근한데, 신기하게 머리는 비어 있었다. 정상에서 멍하니 앉아 있다가 내려왔다. 집에 돌아오니 기분이 이상하게 개운했다.

주중에는 퇴근하고 만화를 읽었다. 예전에 좋아했는데 언제부턴가 "시간 낭비"라고 생각해서 안 읽고 있었다. 한 권을 집어 들었는데 멈출 수가 없어서 새벽 1시까지 읽었다. 다음 날 졸렸지만, 이상하게 기분은 좋았다.

이런 것들이 쌓이면서 뭔가가 달라졌다. 월요일 아침이 여전히 반갑지는 않았지만, 적어도 가슴이 답답하지는 않았다. 코드를 볼 수 있게 됐다.

## 슬랙 알림을 껐다

알림을 끄는 건 생각보다 큰 결심이 필요했다.

"내가 안 보면 장애 대응이 늦어지면 어쩌지." "팀에서 나한테 필요한 게 있는데 답을 안 하면 어떡하지." "내가 슬랙을 안 본다는 걸 알면 성의 없어 보이지 않을까."

이런 생각들이 머릿속에서 계속 돌았다. 근데 가만히 따져보면 말이 안 되는 것들이었다. 장애 대응에는 on-call 로테이션이 있었고, 내 담당이 아닌 날에는 내가 할 수 있는 게 없었다. 팀에서 급한 게 있으면 전화가 온다. 슬랙 안 본다고 회사가 망하지는 않는다.

그래서 퇴근 후에는 슬랙 알림을 끄기로 했다. 7시 이후에는 확인하지 않는다. 주말에도 마찬가지다.

처음 이틀은 불안했다. 폰을 자꾸 들어서 확인하고 싶은 충동이 있었다. 셋째 날부터 익숙해졌다. 일주일이 지나니까 자연스러워졌다. 그리고 월요일 아침에 밀린 메시지를 확인해보면 — 긴급한 건 하나도 없었다.

의외의 부수 효과가 있었다. 저녁 시간이 진짜 내 시간이 됐다. 예전에는 TV를 보면서도 옆에 슬랙을 켜놓았으니까, 온전히 쉬는 게 아니었다. 반쯤은 일하는 상태. 알림을 끄니까 저녁이 비로소 저녁이 됐다.

## 팀 리드에게 말한 것

제일 어려웠던 건 이거다. 힘들다고 말하는 것.

개발자, 특히 주니어에서 갓 벗어난 시점의 개발자에게 "일이 힘들어요"는 "제 실력이 부족해요"처럼 느껴진다. 다른 사람들은 다 괜찮아 보이는데 나만 버거워하는 것 같고. 그래서 꾹 참고 있었다.

결정적인 계기가 있었다. 스프린트 회고에서 팀 리드가 각자 컨디션 점수를 매겨보자고 했다. 10점 만점에. 다들 6, 7점을 매겼다. 나는 고민하다가 4점을 적었다. 팀 리드가 회고 끝나고 1:1을 잡았다.

"요즘 어때?"

이 질문에 "괜찮아요"라고 말하려다가 멈췄다. 안 괜찮으니까 4점을 적은 거잖아. 그래서 그냥 말했다. 아침에 코드를 보기가 싫을 때가 있다고. 주말에 쉬어도 월요일에 나아지지 않는다고. 재미있던 게 재미없어졌다고.

팀 리드의 반응이 예상 밖이었다. 놀라지 않았다. "나도 3년 차 때 비슷했어"라고 했다. 그리고 바로 이번 스프린트에서 내 태스크를 줄여줬다. "이번 주는 이것만 해. 나머지는 내가 분배할게." 미안하기도 하고 고맙기도 했다.

솔직하게 말한 뒤로 달라진 게 있다. 일의 양이 줄어든 것도 있지만, 그보다 더 큰 건 혼자 끌어안고 있지 않아도 된다는 안도감이었다. 힘든 걸 숨기느라 쓰는 에너지가 생각보다 크다. 그 에너지를 안 쓰게 되니까 조금씩 숨통이 트였다.

## "일만 하는 상태"의 결과

번아웃에서 빠져나오면서 가장 크게 바뀐 생각이 있다.

예전에는 번아웃을 "일을 못 하는 상태"라고 생각했다. 능력이 부족하거나, 멘탈이 약하거나, 체력이 딸리는 사람에게 오는 거라고. 그래서 나한테 오면 안 되는 거라고.

근데 번아웃은 "일만 하는 상태"가 지속된 결과다. 일을 못 해서 오는 게 아니라, 일 밖의 것들이 사라졌을 때 온다. 나의 경우 코딩이 일이자 취미이자 정체성이었다. 모든 계란을 한 바구니에 담고 있었던 셈이다.

바구니 하나가 무거워지면 전부 무너진다.

요리하고, 산에 오르고, 만화를 읽으면서 바구니를 늘린 거다. 코딩 말고도 나를 채우는 것들이 있다는 걸 다시 발견한 과정이었다. 대단한 취미가 아니어도 된다. 코드와 관계없는 무언가. 결과를 측정할 필요 없는 무언가. 그냥 하고 싶어서 하는 무언가.

## 지금은

완벽하게 관리하고 있다고 말하면 거짓말이다.

지금도 번아웃의 기미는 주기적으로 온다. 큰 릴리즈 전에, 야근이 며칠 이어질 때, 피드백 없이 혼자 작업하는 시간이 길어질 때. 완전히 막을 수 있는 건 아닌 것 같다. 이 업계에서 일하는 한 어느 정도는 같이 가야 하는 것이라고 생각한다.

다만 신호를 알아보게 됐다. 커밋 메시지가 대충 써지기 시작하면. 코드 리뷰에서 짜증이 먼저 나면. 주말에 아무것도 하기 싫으면. 이런 것들이 보이면 "아, 오고 있구나" 하고 인지한다.

인지하면 대응할 수 있다. 알림을 끄고, 저녁을 비우고, 산에 가고, 필요하면 팀에 말한다. 매번 잘 되는 건 아니다. 타이밍을 놓칠 때도 있다. 하지만 첫 번째 번아웃 때처럼 "이게 뭐지, 나한테 무슨 문제가 있는 거지" 하면서 몇 달을 보내지는 않는다.

이 글을 읽는 사람 중에 지금 비슷한 상태인 사람이 있을 수 있다. 아침에 코드가 보기 싫고, 쉬어도 안 나아지고, 예전에 재미있던 게 재미없어진 상태. 하나만 말하고 싶다. 그건 당신 탓이 아니다. 그리고 혼자 해결하려고 하지 않아도 된다.

나는 그 사실을 너무 늦게 알았다.



사이드 프로젝트를 시작할 때 가장 큰 장벽은 초기 세팅이다. 보일러플레이트 만들고, 린트 설정하고, CI 붙이고, 배포 파이프라인 만들고 — 본격적인 기능 개발에 들어가기 전에 지쳐버린다. 이번에는 Claude Code를 써서 이 과정을 얼마나 단축할 수 있는지 실험해봤다.

만든 건 간단한 북마크 관리 웹앱이다. URL을 저장하면 메타데이터를 자동으로 추출하고, 태그로 분류하고, 검색할 수 있는 도구.

## 프로젝트 초기화

터미널에서 Claude Code를 열고 의도를 설명했다.

```
"Next.js App Router, TypeScript, Tailwind CSS, Prisma, SQLite로
북마크 관리 앱을 만들 거야. 프로젝트 초기화해줘."
```

프로젝트 구조, 패키지 설치, 기본 설정 파일까지 한 번에 만들어줬다. `tsconfig.json`의 path alias, ESLint 설정, Prisma 스키마까지. 이 과정이 보통 30분~1시간인데 2분 만에 끝났다.

여기서 중요한 건 CLAUDE.md 파일을 바로 만든 것이다:

```markdown
# Bookmark Manager

## 기술 스택
- Next.js 15 App Router
- TypeScript strict mode
- Tailwind CSS
- Prisma + SQLite
- Server Actions

## 컨벤션
- 컴포넌트는 named export
- 서버 컴포넌트 기본, 클라이언트 컴포넌트는 'use client' 명시
- API 대신 Server Actions 사용
```

CLAUDE.md가 컨텍스트 역할을 해서, 이후 대화에서 일관된 코드를 생성해준다. 이걸 안 만들면 Claude가 매번 다른 패턴으로 코드를 만들어서 프로젝트가 중구난방이 된다.

## 기능 개발 과정

**스키마 설계**

```
"북마크에는 URL, 제목, 설명, 썸네일, 태그(다대다), 생성일이 필요해.
Prisma 스키마 만들어줘."
```

스키마를 만들고 `npx prisma db push`까지 실행해줬다. 다대다 관계를 위한 중간 테이블도 알아서 만들었다.

**OG 메타데이터 추출**

URL을 입력하면 Open Graph 태그에서 제목, 설명, 이미지를 가져오는 Server Action이 필요했다. "URL에서 OG 메타데이터를 추출하는 Server Action 만들어줘"라고 하니까 `cheerio`로 HTML을 파싱하는 코드를 만들었다.

그런데 에러 처리가 빠져 있었다. OG 태그가 없는 사이트, 타임아웃, 잘못된 URL — 이런 엣지 케이스를 하나씩 알려주니까 추가해줬다. AI한테 한 번에 완벽한 코드를 기대하면 안 된다. 코드를 받고, 빠진 부분을 찾고, 수정을 요청하는 반복이 필요하다.

**검색 기능**

SQLite의 전문 검색을 쓸까 했는데, 데이터 규모가 작아서 그냥 Prisma의 `contains`로 충분했다. Claude에게 "검색 기능인데, 제목과 설명에서 검색되게 해줘. 디바운스도 걸어줘"라고 했더니 서버 컴포넌트 + useSearchParams 조합으로 만들어줬다. URL에 검색어가 남으니까 공유도 가능하고 새로고침해도 유지된다.

## 잘 된 것

**보일러플레이트와 반복 코드.** CRUD의 C, R, U, D는 패턴이 비슷하니까 AI가 빠르게 만들어준다. 하나를 잘 만들어놓으면 나머지를 그에 맞춰서 만든다.

**CSS/스타일링.** "이 카드 컴포넌트를 그리드로 배치하고, hover 시 살짝 올라오는 효과 넣어줘" — 이런 지시에 Tailwind 클래스를 척척 붙여준다. CSS 속성 이름이 기억 안 날 때 특히 편하다.

**에러 메시지 해석.** 빌드 에러나 타입 에러가 나면 에러 메시지를 붙여넣고 "이거 왜 그래?"라고 물어보면 된다. 스택오버플로우 검색보다 빠르다.

## 안 된 것

**복잡한 상태 관리 설계.** 태그 필터, 정렬, 검색이 동시에 적용되는 상태를 어떻게 관리할지 — 이건 AI가 여러 방향을 제안하지만 "어떤 게 이 프로젝트에 맞는지"는 내가 판단해야 했다. URL state로 갈지, zustand로 갈지, 그냥 useState로 충분한지.

**디버깅.** "저장 버튼을 누르면 가끔 두 번 저장되는데?"라고 하면, 가능성을 여러 개 나열해주지만 정확한 원인은 직접 찾아야 했다. React Strict Mode의 이중 호출이 원인이었는데, AI는 그 가능성을 세 번째쯤에 언급했다.

**UI/UX 감각.** 기능적으로는 동작하는 UI를 만들어주지만, "이게 사용자 입장에서 직관적인가?"는 스스로 판단해야 한다. 버튼 위치, 피드백 타이밍, 빈 상태 처리 같은 건 내가 하나씩 지시해야 했다.

## 소요 시간

총 8시간 정도 걸렸다. AI 없이 했으면 주말 이틀은 잡아야 했을 분량이다.

| 작업 | 소요 시간 |
|------|----------|
| 프로젝트 초기화 + 스키마 | 30분 |
| CRUD + Server Actions | 2시간 |
| OG 메타데이터 추출 | 1시간 |
| 검색 + 필터링 | 1.5시간 |
| UI 다듬기 | 2시간 |
| 버그 수정 + 엣지 케이스 | 1시간 |

AI가 시간을 절약해주는 건 맞다. 그런데 절약된 시간의 상당 부분을 "AI가 만든 코드를 이해하고 검증하는 데" 다시 쓰게 된다. 이해하지 못하는 코드를 그대로 쓰면, 나중에 수정할 때 처음부터 다시 파악해야 한다.

AI 코딩 도구의 최적 사용법은 "시니어 개발자의 속도를 높이는 것"이지, "코딩을 모르는 사람이 앱을 만드는 것"이 아니다. 무엇을 만들어야 하는지 알고, 만들어진 결과를 평가할 수 있어야 제대로 쓸 수 있다.



입사 2년차 때 일이다. 지금 생각하면 그때가 제일 위험한 시기였다. 뭔가 알 것 같은데 실제로는 잘 모르는, 그 어중간한 구간. 코드를 짜는 속도는 빨라졌고, PR을 올리면 대부분 한두 번의 리뷰로 머지됐다. "나 꽤 잘하는 거 아닌가?"라는 생각이 은연중에 있었다.

그러다 그 PR을 올렸다.

## 500줄짜리 자신감

당시 맡은 작업은 대시보드 페이지의 필터 시스템이었다. 사용자가 날짜 범위, 카테고리, 상태값 등을 조합해서 데이터를 필터링하는 기능. 기획서를 보면 필터 조건이 7개였고, 조합에 따라 API 호출 파라미터가 달라져야 했다.

나는 꽤 열심히 짰다. `useFilter`라는 커스텀 훅을 만들고, 각 필터의 상태를 하나의 객체로 관리했다. 필터 값이 바뀔 때마다 URL 쿼리 스트링과 동기화하고, 뒤로 가기를 누르면 이전 필터 상태가 복원되도록 했다. `useReducer`를 써서 상태 변경 로직을 깔끔하게 분리했다고 생각했다. 리듀서 안에 액션 타입이 12개였는데, 각 케이스마다 주석을 달아놨으니 "가독성도 좋다"고 자부했다.

PR은 약 500줄이었다. 길긴 했지만 파일을 잘 나눠놨다고 생각했다. `useFilter.ts`, `filterReducer.ts`, `filterUtils.ts`, `FilterPanel.tsx`, `FilterChips.tsx`. 이름만 봐도 뭐 하는 건지 알 수 있잖아. 나름 자랑스러운 PR이었다.

코멘트가 하나둘 달리기 시작했다. 대부분 소소한 것들이었다. 타입 네이밍 컨벤션, optional chaining 하나 빠진 곳, 테스트 케이스 추가 요청 같은. 예상 범위 안이었고, 금방 반영했다.

그런데 팀의 시니어 개발자가 코멘트를 하나 남겼다. `filterReducer.ts` 파일의 29번째 줄 근처, 리듀서 함수 전체를 가리키는 코멘트였다.

## 그 한 줄

> "이 리듀서가 아니라 URL이 진실의 원천(source of truth)이 되면 어떨까요?"

끝이었다. 수정 요청이 아니었다. "이렇게 바꿔라"도 아니었다. 그냥 질문 하나.

처음에는 무슨 말인지 이해를 못 했다. URL이 source of truth? 지금도 URL이랑 동기화하고 있는데? `useEffect`로 필터 상태가 바뀌면 URL을 업데이트하고, URL이 바뀌면 필터 상태를 업데이트하고. 양방향으로 싱크하고 있으니까 잘 하고 있는 거 아닌가?

답변을 달려다가 멈췄다. "잘 하고 있는데요"라고 달기 전에 한 번 더 생각해보자.

URL이 source of truth가 되면. 그러니까 필터 상태를 따로 useState나 useReducer로 관리하지 않고, URL 쿼리 스트링 자체가 상태가 되면.

잠깐. 그러면 리듀서가 필요 없어진다.

## 머릿속이 무너지는 순간

자리에서 일어나서 커피를 타왔다. 종이에 그림을 그려봤다. 지금 내 코드의 데이터 흐름은 이랬다.

사용자 액션 → 리듀서로 상태 변경 → useEffect로 URL 업데이트 → URL 변경 감지 → 리듀서로 상태 다시 세팅 → API 호출

이게 왜 복잡하냐면, 상태가 두 곳에 있기 때문이다. 리듀서 안에도 있고 URL에도 있다. 두 곳을 계속 동기화해야 하니까 useEffect가 두 개 필요하고, 동기화 타이밍이 어긋나면 깜빡이는 현상이 생긴다. 실제로 개발하면서 이 이슈를 만났는데, `setTimeout`으로 대충 해결하고 넘어간 부분이 있었다.

시니어 개발자가 말한 방식은 이랬다.

사용자 액션 → URL 직접 변경 → URL에서 필터 값 파싱 → API 호출

상태가 한 곳에만 있다. 동기화할 게 없다. useEffect도, setTimeout도 필요 없다. 리듀서도 필요 없다. 그 12개의 액션 타입도, 깔끔하게 달아놓은 주석도, 전부 필요 없어진다.

500줄 중에 200줄 넘게 쳐낸다는 뜻이었다.

자존심이 상했다. 솔직히 말하면. 이틀 동안 열심히 짠 코드를 반 넘게 삭제해야 한다니. 리듀서 패턴 적용하면서 "오, 이거 구조 진짜 깔끔하다" 했는데, 그게 통째로 불필요하다니.

근데 아무리 생각해도 시니어 개발자가 맞았다. URL이 source of truth가 되면 코드가 단순해질 뿐만 아니라, 사용자 경험도 좋아진다. 필터를 적용한 상태에서 링크를 복사해서 동료에게 보내면 동일한 필터 상태가 재현된다. 새로고침해도 필터가 유지된다. 브라우저 뒤로 가기가 자연스럽게 동작한다. 전부 URL이 상태니까 당연히 되는 것들이다.

내 원래 코드에서는 이것들을 하나하나 구현해야 했다. 뒤로 가기 지원을 위해 `popstate` 이벤트를 리슨하고, 링크 공유를 위해 상태를 URL에 인코딩하고... 이미 URL이라는 완벽한 상태 저장소가 있는데 옆에 리듀서라는 상태 저장소를 하나 더 만들어놓고 둘을 억지로 연결하고 있었던 거다.

## 고치고 나서 느낀 것

PR을 다시 작성했다. `useFilter` 훅은 내부적으로 `useSearchParams`를 감싸는 얇은 래퍼가 됐다. 리듀서 파일은 삭제했다. 유틸 함수 절반도 삭제했다. 500줄이 200줄 조금 넘는 정도로 줄었다. 그리고 가장 중요한 건, setTimeout 핵이 사라졌다는 거다.

기능은 완전히 동일했다. 사실 더 나았다. 이전에는 특정 순서로 필터를 빠르게 바꾸면 상태가 꼬이는 엣지 케이스가 있었는데, URL 기반으로 바꾸니까 그게 원천적으로 불가능해졌다.

근데 기술적인 개선보다 더 중요한 게 있었다. 그 코멘트가 남긴 진짜 교훈은 "URL을 source of truth로 써라"가 아니었다.

**"너의 솔루션이 문제를 복잡하게 만들고 있는 건 아닌지 한 발 물러서 봐라"**였다.

나는 필터 기능을 구현하면서 문제를 있는 그대로 본 게 아니라, 내가 알고 있는 패턴에 끼워 맞춘 거다. 상태 관리? useReducer. 복잡한 상태 로직? 액션 타입 나누기. 이렇게 기계적으로 도구를 꺼내들었다. "이 문제에 가장 적합한 상태 관리 방식이 뭘까?"를 먼저 물어봤어야 했는데, "useReducer를 어떻게 쓸까?"부터 생각했다.

솔루션이 너무 빨리 나왔다. 문제를 충분히 들여다보기 전에.

## 그 후로 바뀐 것들

이 경험 이후로 내가 코드 리뷰를 하는 방식이 완전히 바뀌었다.

예전에는 눈에 보이는 걸 지적했다. 변수명이 이상하다, 이 함수는 너무 길다, 여기 타입이 빠졌다. 물론 이런 것도 필요하다. 하지만 이건 린터가 할 수 있는 수준의 리뷰다.

지금은 먼저 전체 구조를 본다. 이 PR이 풀려는 문제가 뭔지, 그리고 선택한 접근 방식이 그 문제에 적합한지를 본다. 코드의 줄 하나하나를 보기 전에 파일 구조와 데이터 흐름을 훑는다.

그리고 지적 대신 질문을 한다.

"이 상태를 여기서 관리하는 특별한 이유가 있나요?"
"이 useEffect 없이도 같은 결과를 얻을 수 있을까요?"
"이 추상화가 나중에 요구사항이 바뀌면 어떻게 될까요?"

지적은 방어를 부른다. "이거 틀렸어요"라고 하면 상대방은 본능적으로 "왜 그게 틀린 건데"를 생각한다. 하지만 질문은 사고를 부른다. "이게 아니라 저러면 어떨까요?"라고 하면 상대방은 "음, 그러면..." 하고 직접 생각하기 시작한다. 결론에 스스로 도달하면 훨씬 깊이 이해하게 된다.

시니어 개발자가 나한테 그렇게 한 것처럼.

그 사람은 "리듀서 삭제하고 URL 기반으로 바꾸세요"라고 할 수 있었다. 그게 더 빠르기도 하다. 하지만 그랬으면 나는 시키는 대로 고쳤을 거다. 왜 그래야 하는지 깊이 이해하지 못한 채로. 그리고 다음번에 비슷한 상황이 오면 또 같은 실수를 했을 거다.

질문 형태의 코멘트는 시간이 좀 더 걸린다. 상대방이 스스로 깨달을 때까지 기다려야 하니까. 하지만 그 깨달음은 오래 남는다. 3년이 넘었는데 아직도 PR을 올릴 때마다 스스로에게 묻는다. "지금 이 솔루션이 문제를 복잡하게 만들고 있는 건 아닌가?"

## 좋은 코멘트의 조건

그 이후로 코드 리뷰를 많이 하면서 나름대로 정리한 게 있다. 좋은 코멘트가 되려면 몇 가지가 필요하다.

첫째, 맥락을 이해해야 한다. 왜 이 코드가 이렇게 작성됐는지를 먼저 이해하려고 노력해야 한다. 내가 리듀서를 쓴 데는 이유가 있었다. 필터 상태가 복잡하고, 상태 변경 로직을 한곳에 모으고 싶었으니까. 시니어 개발자는 이 의도를 이해한 상태에서 더 나은 방법을 제안한 거다. 맥락 없이 "이거 왜 이렇게 짰어요?"라고 물으면 공격처럼 느껴진다.

둘째, 구체적이어야 한다. "구조가 좀 이상한데요"보다 "이 리듀서가 아니라 URL이 source of truth가 되면 어떨까요?"가 훨씬 유용하다. 방향을 제시하되 답을 주지는 않는 수준. 상대방이 생각할 여지를 남겨두면서도 막막하지 않을 만큼.

셋째, 톤이 중요하다. 같은 내용이라도 어떻게 말하냐에 따라 완전히 다르게 느껴진다. "이건 안티패턴인데요"와 "이런 식으로 하면 더 단순해질 것 같은데 어떻게 생각하세요?"는 천지 차이다. 코드 리뷰는 코드를 리뷰하는 거지 사람을 리뷰하는 게 아니다. 그런데 받는 사람 입장에서는 구분이 안 될 때가 있다.

넷째, 모든 걸 지적하지 않아야 한다. PR에 개선할 점이 10개 보여도 진짜 중요한 2-3개만 집는다. 나머지는 다음에, 또는 아예 안 하는 게 낫다. 코멘트가 20개 달린 PR은 받는 사람이 지친다. 의욕이 꺾인다. 코드 퀄리티를 위해 사람의 의욕을 갉아먹으면 장기적으로는 코드 퀄리티가 더 떨어진다.

## 완벽한 코드 리뷰는 없다

솔직히 말하면 나도 아직 잘 못한다. 바쁠 때는 "LGTM"으로 대충 넘기기도 하고, 가끔은 톤 조절에 실패해서 상대방이 기분 나빠한 적도 있다. 질문 형태로 코멘트를 남겼는데 의도가 전달이 안 돼서 "그래서 어떻게 하라는 건데요?"라는 답변을 받은 적도 있다.

코드 리뷰는 결국 커뮤니케이션이다. 코드를 매개로 한 대화다. 모든 대화가 그렇듯 완벽할 수 없고, 매번 다르다. 상대방의 경험 수준, 그날의 컨디션, 프로젝트의 긴급도에 따라 같은 코멘트도 다르게 작용한다.

다만 하나 확실한 건, "이걸 고쳐라"보다 "이러면 어떨까?"가 더 오래 남는다는 거다.

3년 전 그 시니어 개발자의 코멘트처럼. 한 줄이었는데, 아직도 코드를 짤 때마다 떠오른다. 가장 좋은 코드 리뷰 코멘트는 PR이 머지된 한참 후에도 효력이 남아있는 코멘트다.

누군가의 PR에 코멘트를 남길 때, 나도 그런 한 줄을 쓸 수 있으면 좋겠다고 생각한다. 매번은 무리지만, 가끔이라도.



회사에서 쓰는 기술 스택이 있다. React, TypeScript, Next.js, Zustand, Tailwind CSS. 이 조합이 손에 완전히 익었다. 새 프로젝트가 시작돼도 초기 세팅을 30분 안에 끝낼 수 있고, 웬만한 UI 패턴은 머리보다 손이 먼저 움직인다. 리스트 렌더링, 폼 핸들링, 모달, 토스트, 무한 스크롤. 다 해봤고, 다 할 수 있다. 편하다.

근데 최근에 이 "편함"이 좀 무섭다.

## 익숙함의 함정

작년에 팀에서 Vue.js로 된 레거시 프로젝트를 유지보수할 사람이 필요했다. 사내 다른 팀에서 넘어온 프로젝트인데, Vue 2 기반에 Vuex를 쓰고 있었다. 아무도 자원 안 했다. 나도. React만 하고 싶었으니까. "Vue는 안 해봐서요"라는 말이 편한 핑계였다. 결국 외부 프리랜서를 데려왔는데, 그 사람은 React도 Vue도 Svelte도 했다. 프레임워크를 가리지 않았다. 첫 주에 코드베이스를 파악하고, 둘째 주부터 바로 피처를 찍어냈다.

그 사람이 점심 먹으면서 한 말이 머리에 남았다. "프레임워크는 결국 UI를 그리는 도구인데, 근본 원리는 비슷하니까요. 상태가 바뀌면 화면이 바뀐다는 거. React든 Vue든 Svelte든." 맞는 말이다. 근데 나는 그 "근본 원리"를 React라는 렌즈로만 이해하고 있었다. 다른 렌즈를 끼워본 적이 없으니까, 내가 보는 게 전체인 줄 알았다.

그 사람이 떠나고 나서 Vue 문서를 한번 열어봤다. template 문법이 낯설었다. JSX에 익숙한 눈에는 "이게 뭐지?" 싶었다. `v-if`, `v-for`, `v-model`. 30분 읽다가 닫았다. "지금 당장 필요 없으니까"라는 이유로. 합리적인 이유 같지만, 사실은 불편해서 도망친 거였다.

## 불편한 시도들

그래서 올해 초부터 일부러 불편한 걸 하려고 한다. 작게라도.

첫 번째로 Rust를 조금 건드려 봤다. 프론트엔드와 직접 관련은 없지만, WASM 쪽으로 연결될 수 있고, 요즘 빌드 도구들이 다 Rust 기반이라서. SWC, Turbopack, Biome, oxc. 프론트엔드 도구 생태계의 밑바닥이 Rust로 깔리고 있다. 직접 Rust로 뭔가 만들 일은 없겠지만, 이 도구들이 어떤 원리로 동작하는지 감이라도 잡고 싶었다.

Rust 공식 튜토리얼을 시작했다. 소유권(ownership) 개념에서 막혔다. JavaScript에서는 생각해본 적 없는 개념이다. 변수를 다른 변수에 할당하면 원래 변수를 못 쓴다? 메모리를 직접 관리해야 한다? 3일 만에 덮었다. 아직 이른가 싶었다. 근데 그 3일 동안 "가비지 컬렉션이 없는 세계"를 잠깐이나마 본 건 의미가 있었다. JavaScript가 얼마나 편한 언어인지 체감했다.

두 번째로 백엔드를 좀 해봤다. Express로 간단한 REST API를 만들어봤다. 라우팅, 미들웨어, 데이터베이스 연결. 생각보다 재미있었다. 프론트에서 API를 "쓰는" 입장에서만 보다가, "만드는" 입장으로 가니까 시야가 달라졌다. 왜 백엔드 개발자가 특정 형태로 응답을 주는지 이해가 됐다. 페이지네이션을 offset 기반으로 할지 cursor 기반으로 할지, 에러 응답 형식을 어떻게 통일할지, 인증 미들웨어를 어디에 둘지. 이전에는 "왜 이렇게 주는 거야" 하고 불만만 가졌는데, 직접 만들어보니 "아 이럴 수밖에 없구나" 하는 경우가 많았다.

세 번째로 디자인 시스템을 공부하기 시작했다. Figma를 열어서 디자이너가 어떻게 컴포넌트를 구성하는지 봤다. 오토 레이아웃이라는 개념이 CSS Flexbox랑 거의 같다는 걸 처음 알았다. 디자이너와 대화할 때 "여기 패딩 좀 주세요" 대신 "이 오토 레이아웃의 gap을 12에서 16으로 해볼까요?" 같은 말을 쓸 수 있게 됐다. 디자이너가 놀란 눈으로 봤다. "개발자가 오토 레이아웃을 안다고?" 이 작은 공통 언어가 협업을 꽤 편하게 만들었다.

## 불편함의 비용

불편한 걸 하면 당연히 느려진다. Rust 튜토리얼 하는 시간에 React 고급 패턴을 공부했으면 회사 일에 바로 도움이 됐을 거다. Express API 만드는 시간에 Next.js Server Action을 깊게 팠으면 프로젝트에 바로 적용할 수 있었을 거다. Figma 공부하는 시간에 CSS 애니메이션을 연습했으면 더 화려한 UI를 만들 수 있었을 거다.

이 기회비용 때문에 망설여진다. 지금 당장 써먹을 수 있는 걸 깊게 할 것인가, 당장은 안 써먹지만 폭을 넓힐 것인가. 정답은 없는 것 같다. 사람마다 상황이 다르고, 시기마다 필요한 게 다르니까.

팀 리드한테 이 고민을 말했더니, "둘 다 해"라고 했다. 평일에는 깊게, 주말에는 넓게. 근데 주말에 코딩하고 싶지 않은 마음도 있어서, 현실적으로는 평일 퇴근 후 30분-1시간 정도를 "불편한 공부" 시간으로 쓰고 있다. 솔직히 안 하는 날이 더 많다. 3일에 한 번 정도? 피곤하면 넷플릭스가 이긴다.

## 시장은 기다려주지 않는다

작년에 AI 코딩 도구가 본격적으로 퍼지기 시작했다. 처음에는 "이걸로 코딩하다니 장난감 아닌가" 했는데, 옆에서 시니어가 Copilot으로 보일러플레이트를 뚝딱 만드는 걸 보고 생각이 바뀌었다. 반복적인 코드 작성 시간이 확 줄었다. 타입 정의, 테스트 케이스, API 연동 코드 같은 것들. 그 시간에 설계나 리뷰에 더 집중할 수 있었다.

AI 도구를 안 쓰면 뒤처지는 게 아니라, 불필요하게 시간을 쓰는 거다. 이것도 컴포트존이었다. "나는 직접 코드를 쳐야 해"라는 고집. "자동 완성에 의존하면 실력이 안 늘어"라는 믿음. 결국 AI 도구를 쓰기 시작했고, 지금은 없으면 답답하다. 이전의 나를 설득하는 데 한 달이 걸렸다.

프론트엔드 시장 자체도 변하고 있다. 서버 컴포넌트, 엣지 컴퓨팅, 마이크로 프론트엔드, Islands Architecture. 2년 전 부트캠프에서 배운 내용만으로는 따라가기 어려운 방향으로 가고 있다. CRA(Create React App)로 SPA 만들던 시절이 불과 2-3년 전인데, 지금은 완전히 다른 세계다. "나는 React 잘 해"만으로는 3년 후에 어떻게 될지 모르겠다.

## 불편함을 버티는 법

사실 특별한 방법은 없다. 그냥 불편한 걸 시작하고, 잘 안 되면 좀 답답하고, 그래도 조금씩 하다 보면 어느 순간 불편하지 않게 된다. 그러면 또 새로운 불편함을 찾는다. 이 사이클의 반복.

TypeScript를 처음 배울 때가 생각난다. JavaScript가 편한데 왜 타입을 일일이 써야 하냐고 투덜거렸다. `any`를 남발했다. 인터페이스 정의하는 게 코드만 길어지는 것 같아서 짜증났다. 지금? `any` 쓰면 코드 리뷰에서 스스로도 불편하다. strict mode 없이는 코드를 쓸 수 없다. 익숙해진 거다. 그 불편했던 시간이 지금의 편안함을 만들었다.

불편함은 성장의 신호라는 말이 있는데, 경험적으로 맞는 것 같다. 편하다는 건 새로운 걸 안 하고 있다는 뜻이고, 불편하다는 건 뭔가 확장하고 있다는 뜻이다. 다만 모든 불편함이 좋은 불편함은 아니다. 의미 없는 삽질은 그냥 삽질이다. 어떤 불편함이 성장으로 이어지고 어떤 불편함이 시간 낭비인지, 그걸 구별하는 감각은 아직 없다. 이것도 경험으로 쌓이는 건지, 아니면 영원히 모르는 건지.

한 가지 확실한 건, 편한 상태에서는 아무것도 안 바뀐다는 거다. React만 할 줄 알던 나는 1년 전이나 지금이나 React만 할 줄 안다. 근데 Express를 만져본 나는, 프론트에서 API를 설계할 때 백엔드 사정을 고려할 수 있게 됐다. Figma를 열어본 나는, 디자이너와 같은 언어로 이야기할 수 있게 됐다. 작은 불편함이 작은 변화를 만들었다. 그 작은 변화가 쌓여서 뭐가 될지는 아직 모르겠지만, 적어도 가만히 있는 것보다는 나을 거라고 생각한다.

요즘은 Vue 문서를 다시 열어볼까 생각 중이다. 작년에 30분 보고 닫았던 그 문서. 이번에는 좀 더 버텨볼 수 있을 것 같다. template 문법이 낯설어도, JSX와 다른 관점에서 UI를 생각하는 경험 자체가 의미 있을 거라고 본다.


일요일 저녁이었다. 소파에 누워서 트위터를 보다가 동기의 리트윗이 눈에 들어왔다. "00에 합류하게 되었습니다!" 유명한 시리즈B 스타트업이었다. 축하한다는 마음이 먼저였는데, 3초쯤 지나니까 묘한 감정이 올라왔다. 나는 아직 여기 있는데.

그 감정이 뭔지 이름을 붙이기까지 시간이 좀 걸렸다. 조급함? 질투? 아니면 불안? 정확히는 모르겠지만, 확실한 건 기분이 좋지 않았다는 거다. 축하 메시지를 쓰고 보내는데 손이 좀 무거웠다. 그 무거움이 싫었다. 진심으로 축하하고 싶은데, 몸이 따로 움직인다.

## 잔디밭 스트레스

깃허브 프로필을 열 때마다 제일 먼저 보이는 게 잔디다. 초록색이 빽빽하면 왠지 뿌듯하고, 비어 있으면 게을렀던 것 같다. 그런데 이게 진짜 문제가 되기 시작한 건 다른 사람 잔디를 구경하면서부터였다.

팀 리드 깃허브에 들어갔다가 잔디가 거의 매일 초록색인 걸 보고 충격받은 적이 있다. 거기에 오픈소스 기여까지 꾸준히 하고 있었다. 나는 회사 코드 커밋이 대부분인데, 이 사람은 개인 프로젝트까지 돌리고 있었다. 그 날부터 의미 없는 README 수정 커밋을 하고 있는 나를 발견했다. 잔디를 채우기 위해서. `docs: update README`라는 커밋 메시지가 일주일에 세 번씩 올라갔다. 내용은 마침표 하나 추가하거나, 줄바꿈을 수정하는 거였다.

한 달쯤 그러다가 깨달았다. 이건 누구한테 보여주려고 하는 거지? 채용 담당자? 아니면 그냥 나 자신한테? 잔디가 빽빽하다고 실력이 느는 건 아닌데, 그 초록색 네모에 이상하게 집착하고 있었다. 오히려 의미 없는 커밋을 남기는 데 쓰는 에너지를 진짜 공부에 쏟았으면 훨씬 나았을 거다.

요즘은 잔디를 신경 안 쓰려고 노력한다. 아예 프로필에서 잔디 섹션을 접어놓았다. 안 보이면 신경이 덜 쓰인다. 근데 가끔 다른 사람 프로필 들어가면 또 보게 된다. 습관이 무섭다.

## 연봉이라는 숫자

개발자 커뮤니티에서 연봉 이야기가 나올 때마다 심장이 좀 빨라진다. 블라인드에서 "3년차 프론트엔드 연봉 어느 정도?" 같은 글을 보면 꼭 열어본다. 그리고 댓글을 읽으면서 계산을 시작한다. 저 사람은 나보다 1년 적은데 더 받네. 저건 대기업이니까 그런 거겠지. 아 근데 스타트업도 저 정도는 주나?

한번은 대학 동기 모임에서 자연스럽게 연봉 이야기가 나왔다. 금융권 SI에 간 친구가 숫자를 말했는데, 나보다 꽤 높았다. 물론 그 친구는 야근이 일상이고 기술 스택도 10년 전이라고 했지만, 숫자만 머리에 남았다. 집에 오는 지하철에서 괜히 잡플래닛을 켰다. "프론트엔드 2년차 평균 연봉" 검색. 나오는 숫자들을 보면서 한숨을 쉬기도 하고, 안도하기도 하고. 그 30분이 정말 쓸데없는 시간이었다는 걸 지하철에서 내리면서 깨달았다.

그런데 생각해보면, 연봉이 높은 사람이 행복한 사람인 건 아니다. 당연한 말인데 비교 모드가 켜지면 이 당연한 걸 잊어버린다. 내가 좋아하는 기술로 일하고, 팀 분위기가 괜찮고, 성장하고 있다는 느낌이 있으면 그게 꽤 괜찮은 거다. 근데 숫자 앞에서는 이런 정성적인 가치가 무력해진다. 적어도 그 순간에는. 숫자는 명확하니까. "나는 성장하고 있어"는 주관적이지만, "나는 연봉이 00이야"는 객관적이다. 비교가 쉬운 건 항상 숫자 쪽이다.

## 이직 뉴스의 파급력

개발자 세계에서 이직은 자연스러운 일이다. 평균 재직 기간이 2년도 안 된다는 통계를 본 적이 있다. 그래서 오히려 더 자주 비교하게 된다. 슬랙 커뮤니티에서 "00 합류했습니다" 포스트가 올라올 때마다 반응이 폭발하고, 나도 축하 이모지를 누르면서 동시에 "나는 언제쯤?" 하는 생각이 스친다.

작년에 같은 부트캠프 출신 동기가 유명 테크 회사에 입사했다. 부트캠프 슬랙에 소식이 올라왔고, 모두가 축하했다. 나도 축하 메시지를 보내고 나서 밤에 잠이 안 왔다. 같은 시기에 시작했는데 왜 저 사람은 저기 있고 나는 여기 있지? 포트폴리오를 꺼내서 다시 보고, 이력서를 고치기 시작했다. 새벽 2시에. 글씨가 흐릿하게 보일 때까지.

아침에 일어나서 보니까 이력서에 쓴 내용이 전부 "남들한테 좋아 보이는 것"이었다. 사용한 기술 스택 나열, 참여한 프로젝트 규모, 처리한 트래픽 수치. 내가 진짜 하고 싶은 게 뭔지, 어떤 환경에서 일하고 싶은지는 빠져 있었다. 그냥 저 사람이 간 회사가 좋아 보여서 따라가려고 한 거였다. 그 회사가 어떤 문화인지, 어떤 제품을 만드는지도 제대로 안 알아보고.

가장 웃긴 건, 그 동기가 몇 달 후에 "생각보다 안 맞아서 힘들다"고 말한 거다. 겉에서 보는 것과 안에서 사는 건 다르다. 알고 있는데 매번 잊어버린다.

## 비교의 함정

비교가 나쁜 게 아니다. 방향을 잡는 데 도움이 되는 비교도 있다. "저 사람은 성능 최적화를 잘하네, 나도 저 분야를 공부해볼까" 같은 건 건강한 비교다. 문제는 비교 대상이 틀렸을 때, 그리고 비교의 목적이 "참고"가 아니라 "평가"일 때다.

트위터에서 보이는 건 하이라이트다. 합격 소식은 올리지만 탈락은 안 올린다. 성공한 사이드 프로젝트는 자랑하지만 중간에 포기한 건 말 안 한다. 잔디가 빽빽한 건 보이지만, 그 사람이 번아웃 와서 3개월 쉰 건 안 보인다. 배포에 성공한 트윗은 올라오지만, 그 전에 빌드가 47번 실패한 건 안 올라온다.

나도 마찬가지다. 내 SNS에는 괜찮은 것만 올린다. 블로그에 올리는 글도 "이건 좀 괜찮다" 싶은 것만. 그러면 누군가는 내 프로필을 보고 비교하고 있을 수도 있다. 서로 편집된 버전만 보면서 비교하는 거다. 인스타에서 여행 사진만 보고 그 사람의 일상이 늘 화려할 거라고 착각하는 것과 같다.

시니어한테 이 이야기를 한 적이 있다. 점심 먹으면서 "다른 사람 보면 조급해진다"고 했더니 웃으면서 이렇게 말했다. "나도 아직도 그래. 7년 차인데 10년 차 보면 아직 멀었다 싶고, CTO 보면 나는 언제 저기 가나 싶고." 7년차도 비교한다는 사실이 좀 위로가 되면서도, 이게 끝나지 않는 건가 싶어서 약간 막막했다. 비교가 인간의 기본 설정이면, 우리는 평생 이걸 안고 사는 건가.

## 내가 시도하는 것들

완벽한 해결책은 없다. 그냥 몇 가지 시도하고 있는 것들이 있다.

트위터 알림을 껐다. 아예 안 보는 건 아닌데, 의도적으로 보는 시간을 줄였다. 특히 일요일 저녁에는 안 본다. 월요일 출근 전에 쓸데없이 조급해지는 걸 막으려고. 대신 그 시간에 다른 걸 한다. 러닝을 하거나, 넷플릭스를 보거나, 그냥 아무것도 안 하거나.

블라인드 연봉 글은 안 연다. 이건 꽤 힘들다. 제목이 눈에 들어오면 손가락이 먼저 움직이는데, 최근에는 "이걸 읽고 나서 기분이 좋아진 적이 있나?" 하고 자문한다. 답은 항상 아니오다. 내 연봉보다 높은 글을 보면 우울하고, 낮은 글을 보면 잠깐 안도하다가 "그래도 더 받아야 하는데" 하는 욕심이 생긴다. 어떤 결과든 좋지 않다.

그리고 비교 대상을 바꾸려고 한다. 6개월 전의 나와 지금의 나를 비교하는 거다. 6개월 전에는 TypeScript 제네릭이 무서웠는데 지금은 유틸리티 타입을 직접 만든다. 6개월 전에는 코드 리뷰 받으면 위축됐는데 지금은 "왜 이렇게 했냐"는 질문에 근거를 대고 설명한다. 6개월 전에는 Next.js의 렌더링 전략이 헷갈렸는데 지금은 SSR, SSG, ISR을 상황에 맞게 선택할 수 있다. 이런 변화는 남과 비교할 때는 보이지 않는다. 나한테만 보인다.

노션에 "6개월 전 나 vs 지금 나" 페이지를 만들었다. 분기마다 업데이트한다. 이걸 보면 "아 나도 나름 왔구나" 하는 느낌이 든다. 잠깐이지만.

## 그래도

솔직히 말하면 아직도 흔들린다. 어제도 링크드인에서 동기 이직 소식을 봤고, 잠깐 조급해졌다. 이 글을 쓰면서도 "이런 글 쓸 시간에 알고리즘 문제 하나 더 풀어야 하나?" 하는 생각이 스쳤다.

비교를 완전히 안 할 수는 없을 것 같다. 인간이니까. 다만 비교가 시작됐을 때 "아, 또 시작이네" 하고 알아차리는 속도가 좀 빨라진 것 같다. 예전에는 비교 모드에 들어가면 며칠을 끌었는데, 요즘은 반나절 정도면 돌아온다.

그게 성장인지는 모르겠다. 근데 뭐, 일단은 그 정도면 괜찮지 않나.


Morgan Housel이 이런 말을 했다. "복리는 치트키를 쓰려고 하면 작동하지 않는다." 이건 돈 이야기였지만, 나는 이걸 읽으면서 돈이 아니라 개발 공부가 떠올랐다.

3년 전의 나를 떠올려보면, 배움에 대한 접근이 완전히 달랐다. "이번 달에 React 마스터하겠다" 같은 목표를 세우고, 주말에 8시간씩 몰아서 강의를 들었다. 첫 주말은 열정이 넘치고, 둘째 주는 좀 힘들고, 셋째 주에는 "다음 달부터 다시 하자"가 된다. 그리고 2달 뒤에 또 다른 강의를 결제한다.

이 패턴을 3번쯤 반복하고 나서 뭔가 이상하다는 걸 깨달았다.

## 복리가 배움에서도 작동하는 이유

투자에서 복리는 단순하다. 원금에 이자가 붙고, 그 이자에 다시 이자가 붙는다. 시간이 지날수록 가속이 붙는 구조. James Clear는 이걸 학습에 적용해서 "매일 1% 나아지면 1년 뒤에 37배가 된다"고 말했다.

수학적으로야 맞지만, 처음엔 와닿지 않았다. 1%가 대체 뭔데? 근데 개발 공부에서의 1%는 생각보다 구체적이다.

- 오늘 `Array.reduce()`의 동작 원리를 이해한다
- 내일 그걸 써서 장바구니 합산 함수를 짠다
- 모레 그 패턴을 응용해서 그룹별 통계를 만든다

여기서 핵심은, 어제 배운 게 오늘의 밑거름이 된다는 거다. `reduce`를 모르면 그룹별 통계를 짤 때 `for`문을 중첩하게 된다. `reduce`를 알면 한 줄로 끝난다. 그리고 `reduce`를 자유자재로 쓸 줄 알면, 나중에 함수형 프로그래밍 개념을 배울 때 진입 장벽이 확 낮아진다.

이게 복리다. 배운 것 위에 다음 배움이 쌓이고, 쌓인 위에 또 쌓인다.

## 나의 경험: CSS Grid가 디자인 시스템으로 이어지기까지

2년 전에 CSS Grid를 제대로 공부했다. 당시에는 그냥 "레이아웃 잡는 법 하나 더 배워두자" 정도의 마음이었다. `grid-template-columns`, `fr` 단위, `grid-area` 같은 걸 일주일 정도 매일 30분씩 연습했다.

그 다음 달에 Flexbox를 다시 복습할 일이 있었는데, Grid를 이해하고 나니까 Flexbox의 한계가 명확하게 보였다. 이전에는 "둘 다 레이아웃 잡는 건데 뭐가 다른 거야"였는데, Grid를 배운 뒤에는 "아 이건 1차원 정렬이고 저건 2차원 배치구나"가 직관적으로 이해됐다.

6개월 뒤, 회사에서 디자인 시스템을 만드는 프로젝트에 투입됐다. 레이아웃 컴포넌트를 설계하는 역할이었는데, Grid와 Flexbox의 차이를 정확히 이해하고 있어서 "이 컴포넌트는 Grid 기반으로, 저 컴포넌트는 Flex 기반으로" 같은 판단이 자연스럽게 나왔다. 그 판단을 근거와 함께 설명할 수 있었고, 팀 리드가 그 설계를 거의 그대로 채택했다.

CSS Grid 하나 배운 게, Flexbox 이해도를 높이고, 디자인 시스템 설계까지 이어진 거다. 처음부터 "디자인 시스템을 만들기 위해 Grid를 공부하자"고 한 게 아니었다. 그냥 매일 조금씩 배웠을 뿐인데, 그게 예상치 못한 곳에서 터졌다.

## 몰아치기 vs 매일 조금씩

같은 팀에 입사 동기가 있었다. 비슷한 시기에 프론트엔드를 시작했고, 실력도 비슷했다. 차이가 있다면 공부 방식이었다.

동기는 6개월마다 부트캠프 스타일로 공부했다. "이번 달은 TypeScript 집중의 달"을 선언하고, 2주 동안 하루 3-4시간씩 몰아서 했다. 나는 매일 출근 전 30분, 점심 먹고 15분 틈틈이 공부하는 스타일이었다.

1년 뒤 차이가 눈에 보이기 시작했다.

동기는 TypeScript를 2주 집중 학습한 뒤 한 달을 쉬었다. 한 달 뒤에 다시 보니까 절반은 까먹어 있었다. 다시 복습하느라 시간을 쓰고, 그 뒤에 또 한 달 공백. 반복이었다. 에빙하우스 망각곡선이 정확히 작동하고 있었다.

나는 매일 조금씩 했더니 까먹을 틈이 없었다. 월요일에 배운 제네릭을 화요일에 회사 코드에 써보고, 수요일에 에러가 나서 디버깅하면서 더 깊이 이해하고, 목요일에는 동료 코드 리뷰하면서 다른 사람의 타입 설계를 읽게 되고. 학습 → 적용 → 실패 → 교정의 사이클이 일주일 안에 여러 번 돌았다.

2년이 지난 지금, 솔직히 말해서 실력 차이가 꽤 벌어졌다. 동기가 게을렀던 게 아니다. 오히려 공부할 때는 나보다 더 열심히 했다. 다만 복리가 작동하려면 "끊기지 않는 것"이 핵심이다. 몰아치기는 원금을 넣었다 뺐다 하는 것과 같다. 이자가 쌓일 시간을 안 주는 거다.

## 지식은 서로 연결된다

복리의 진짜 마법은 "예상치 못한 연결"에서 온다.

HTTP 상태 코드를 공부한 적이 있다. 프론트엔드 개발자인데 백엔드 쪽 지식이 필요할 때가 있어서 가볍게 훑었다. 200, 400, 404, 500 정도만 알고 있었는데, 301 리다이렉트, 304 캐시, 429 요청 제한 같은 것들을 알게 됐다.

그로부터 3개월 뒤, 서비스에 원인 불명의 느려짐이 있었다. 네트워크 탭을 까보니 같은 API를 반복 호출하고 있었는데, 304 응답을 제대로 활용하지 못하고 있었다. HTTP 캐시 메커니즘을 이해하고 있어서 원인 파악이 빨랐고, `Cache-Control` 헤더를 백엔드 팀에 요청해서 문제를 해결했다.

만약 HTTP 상태 코드를 공부하지 않았다면? 아마 "API가 느려요"라고 백엔드 팀에 던지고 끝났을 거다. 내 문제가 아니니까.

이런 식이다. JavaScript의 이벤트 루프를 이해하면 → React의 상태 업데이트가 비동기인 이유가 자연스럽게 이해되고 → 그러면 useEffect의 의존성 배열이 왜 필요한지도 명확해지고 → 그러면 React Query의 staleTime 개념도 직관적으로 와닿는다.

하나를 깊이 이해하면, 다음 것을 배우는 비용이 줄어든다. 그리고 그다음 것의 비용은 더 줄어든다. 이게 배움의 복리다.

## 복리의 적: 조급함

Morgan Housel의 글에서 가장 기억에 남는 문장이 있다. "기대가 소득보다 빠르게 자라면, 아무리 돈을 많이 벌어도 만족하지 못한다." 배움에도 똑같이 적용된다.

매일 30분씩 공부하면 한 달 뒤에 눈에 보이는 변화가 거의 없다. 주변에서는 "나 이번에 Next.js 부트캠프 완주했어" 같은 소리가 들리고, 나는 아직 TypeScript 제네릭 하나 붙잡고 있다. 조급해진다. "나도 뭔가 큰 걸 해야 하나" 싶어진다.

근데 3개월이 지나면 감이 온다. 6개월이 지나면 확실히 달라진 걸 느낀다. 1년이 지나면 주변에서 "언제 그렇게 된 거야"라고 묻는다. 복리는 그런 거다. 초반에는 변화가 안 보이고, 어느 순간 가속이 붙는다.

James Clear는 이걸 "실망의 계곡(Valley of Disappointment)"이라고 불렀다. 기대하는 성장 곡선은 직선인데, 실제 성장 곡선은 초반에 한참 바닥을 기다가 나중에 치솟는 모양이다. 대부분의 사람들은 그 바닥에서 포기한다. "이거 효과 없는 거 아냐?" 하면서.

나도 처음 3개월은 의심이 있었다. 매일 30분이 정말 의미가 있는 건지. 차라리 주말에 몰아서 하는 게 낫지 않은지. 근데 3개월을 버텼더니 4개월째부터 뭔가 달라지기 시작했다. 코드를 읽는 속도가 빨라지고, 에러 메시지를 보면 원인이 직관적으로 떠오르고, 새로운 라이브러리의 공식 문서를 읽을 때 이해 속도가 확 올랐다.

## 매일 배우기를 지속하는 방법

거창한 건 없다. 내가 2년 동안 유지한 방법은 이렇다.

**1. 단위를 작게 쪼갠다.** "TypeScript를 공부한다"가 아니라 "오늘은 `Partial<T>`이 뭔지 알아본다." 30분 안에 끝낼 수 있는 크기로 쪼개야 한다. 끝내지 못하면 다음 날 이어서 하면 된다.

**2. 배운 걸 바로 써본다.** 30분 공부하고 끝내는 게 아니라, 그날 회사 코드에서 써볼 기회를 찾는다. 기회가 없으면 사이드 프로젝트에라도 써본다. 적용하지 않은 지식은 3일 안에 절반이 사라진다.

**3. 기록한다.** 나는 노션에 "오늘 배운 것" 페이지를 만들어두고 한 줄이라도 적는다. "Partial\<T\>은 모든 프로퍼티를 optional로 만드는 유틸리티 타입이다. 폼 업데이트 함수에서 유용." 이 정도면 충분하다. 기록의 목적은 나중에 검색하기 위해서가 아니라 배운 걸 한 번 더 정리하기 위해서다.

**4. 완벽하지 않아도 된다.** 오늘 컨디션이 안 좋으면 10분만 해도 된다. 핵심은 "안 하는 날"을 만들지 않는 거다. 10분이라도 하면 습관의 연결 고리가 유지된다. 0분은 그 고리를 끊는다.

## 시간이 아니라 방향이다

Housel은 또 이런 말을 했다. "과거는 기억하는 것만큼 좋지 않았고, 현재는 생각하는 것만큼 나쁘지 않으며, 미래는 예상하는 것보다 나을 것이다."

지금 이 글을 읽으면서 "나는 이미 늦었다"고 생각할 수도 있다. 근데 복리의 본질은 시작 시점이 아니라 지속 기간이다. 지금 시작해서 2년 뒤에 터지는 게, 6개월 전에 시작해서 3개월 만에 포기한 것보다 낫다.

개발 공부에서 가장 과소평가되는 전략은 "매일 조금씩, 오래"다. 화려하지 않고, 인스타에 올릴 것도 없고, "이번 주 공부 기록"으로 보여줄 것도 별로 없다. 근데 복리가 작동하려면 원래 그래야 한다. 조용하고 꾸준하게.

10년 뒤 나를 만들 가장 강력한 투자는 오늘 30분의 공부다. 복리는 치트키를 쓰려고 하면 작동하지 않으니까. 그냥 매일 조금씩, 끊기지 않게 하는 수밖에 없다.

돈에서든 지식에서든, 복리의 원리는 같다. 기간이 길수록, 끊기지 않을수록, 결과는 기하급수적으로 커진다. 그리고 대부분의 사람들은 그 기하급수를 기다리지 못해서 직선적인 결과만 얻는다.

매일 30분. 그게 전부다.



"다음 테크 토크 발표자 지원 받습니다."

슬랙 공지를 보고 스크롤을 내리려다가 멈췄다. 격주로 하는 사내 테크 토크. 30분 발표, 10분 Q&A. 입사한 지 8개월인데 한 번도 안 했다. 팀 리드가 한 번 넌지시 물어봤을 때 "준비 좀 하고요"라고 얼버무렸다. 솔직히 무서웠다. 사람들 앞에서 말하는 게. 대학교 때 팀 프로젝트 발표에서도 항상 코드 데모를 맡았다. 설명하는 역할은 피했다.

근데 계속 피할 수만은 없다는 건 알고 있었다. 손을 떨면서 댓글을 달았다. "저 하겠습니다."

## 주제 선정에서 이미 삽질

발표 일정이 2주 뒤로 잡혔다. 처음 든 생각은 "뭔가 대단한 걸 해야 한다"였다. React Server Components 딥다이브, 마이크로 프론트엔드 아키텍처, 서버리스 렌더링 최적화. 그런 거창한 주제를 떠올렸다.

3일 동안 자료를 찾다가 포기했다. 발표 준비가 공부가 됐다. 내가 충분히 모르는 주제를 발표하겠다고 한 거였다. 발표의 핵심은 내가 잘 아는 것을 다른 사람이 이해할 수 있게 전달하는 건데, 나 자신도 이해하지 못하는 걸 전달하려고 했다.

시니어한테 조언을 구했더니 "네가 최근에 실제로 겪은 문제를 말하는 게 가장 좋아"라고 했다. 추상적인 기술 설명보다 "이런 문제가 있었는데 이렇게 해결했다"가 듣는 사람한테도 더 재미있다고.

기술 발표에 대해 글을 쓴 한 개발자가 비슷한 말을 했다. 좋은 발표의 출발점은 외부적 동기(커리어, 인정)가 아니라 내부적 동기라고. "이미 존경과 돈이 충분하다고 가정해도 이 발표를 할 건가?"라는 질문을 던져보라고. 핵심은 자기가 진짜 흥미로운 아이디어를 공유하고 싶은가, 아니면 잘 보이고 싶은가의 차이라는 거였다.

내가 진짜 흥미롭게 느꼈던 건 거창한 아키텍처가 아니라, 지난 달에 상품 상세 페이지의 이미지 로딩 성능을 개선한 경험이었다. LCP가 4.2초에서 1.8초로 줄었다. 과정에서 실패한 시도도 있었고, 예상 밖의 발견도 있었다. 이게 내가 직접 겪은 거라 따로 자료를 찾을 필요가 없었다.

## 슬라이드 40장, 그리고 뺄셈

첫 번째 버전의 슬라이드가 40장이었다. 30분 발표에 40장이면 장당 45초. 너무 빠르다.

문제는 양이 아니라 밀도였다. 슬라이드에 설명을 전부 적어놨다. 한 장에 문단이 3개. 발표자가 입으로 할 말을 화면에 다 적어놓으면 청중은 발표자 말을 안 듣고 슬라이드를 읽는다. 동료한테 리뷰를 부탁했더니 딱 한마디 했다. "글이 너무 많아."

25장으로 줄이는 과정이 발표 준비에서 가장 어려운 부분이었다. 15장을 빼는 게 아니라 15장분의 내용을 포기하는 거다. 성능 측정 방법에 대한 5분짜리 설명, Lighthouse 점수 해석 방법, 번들 분석 도구 비교. 전부 "넣으면 좋은 내용"이었지만 "없으면 안 되는 내용"은 아니었다.

이 뺄셈이 나중에 최선의 결정이었다는 걸 알게 된다.

## 새벽 3시의 슬라이드

발표 전날 밤이었다. 혼자 리허설을 4번째 하고 있었다. 시간은 잘 맞았다. 흐름도 괜찮았다. 근데 뭔가 찝찝했다. 17번째 슬라이드에서 자꾸 걸렸다. 이미지 지연 로딩의 원리를 설명하는 슬라이드였는데, Intersection Observer API의 동작 원리를 코드로 보여주는 부분이었다. 기술적으로 정확했다. 근데 전체 흐름에서 템포를 죽이고 있었다.

새벽 3시에 결정했다. 그 슬라이드를 통째로 잘라냈다. 대신 한 줄로 요약했다. "뷰포트에 이미지가 보일 때만 로드합니다. 구현은 Intersection Observer API를 사용했습니다." 기술 상세는 "코드는 PR 링크 참고"로 대체했다.

이게 왜 좋은 결정이었는지는 발표 당일에 알았다. 그 슬라이드가 있었다면 거기서 2~3분을 쓰면서 청중의 집중력이 떨어졌을 거다. API 동작 원리는 듣는 사람의 절반은 이미 알고 있었고, 나머지 절반은 코드를 보면서 따라가느라 전체 흐름을 놓쳤을 거다. 빼니까 발표가 매끈하게 흘러갔다.

발표 후에 기술 블로그를 운영하는 한 개발자의 글에서 비슷한 원칙을 봤다. 좋은 발표에는 "What(핵심 아이디어 하나)", "Why(왜 청중이 관심을 가져야 하는가)", "How(구체적인 방법)"의 세 가지가 필요한데, 그 중에서 What은 12단어 이내여야 한다고. 하나의 핵심 아이디어에 집중하라는 거다. 내가 잘라낸 슬라이드는 How에 해당하는 세부 내용이었는데, 그걸 빼도 What과 Why는 충분히 전달됐다.

## 발표 당일 아침

아침부터 배가 아팠다. 진짜 물리적으로. 긴장하면 배가 아픈 체질이다. 출근길 지하철에서 슬라이드를 처음부터 끝까지 머릿속으로 돌렸다. 역을 한 번 지나쳤다.

발표 시간 10분 전에 회의실에 들어갔다. 모니터 연결 확인, 슬라이드 확인. 사람들이 하나둘 들어왔다. 15명. 생각보다 많았다. 다른 팀 사람도 몇 명 있었다. 내 발표를 보러 온 건가? 아니면 그냥 테크 토크니까 온 건가? 어느 쪽이든 심장이 빨라졌다.

첫 슬라이드를 띄웠다. "상품 상세 페이지 이미지 로딩 최적화." 입을 열었는데 목소리가 떨렸다. "안녕하세요, 오늘은..." 이 다섯 글자가 이렇게 어려울 줄 몰랐다. 손에 들고 있던 프레젠터가 흔들렸다. 청중 중 한 명과 눈이 마주쳤는데, 그 사람이 살짝 고개를 끄덕였다. 그게 조금 도움이 됐다.

2분쯤 지나니까 가라앉기 시작했다. 문제 상황을 설명하면서 코드를 보여줬는데, 코드 얘기를 하니까 편해졌다. 익숙한 영역이었다. 내가 직접 짠 코드, 내가 직접 겪은 문제. 이건 "발표"가 아니라 "동료한테 내가 한 일을 설명하는" 거였다. 그 프레이밍이 긴장을 줄여줬다.

그 블로그에서 본 조언과 맞닿는 부분이 있었다. 발표자의 역할은 "무대 위의 퍼포머"가 아니라 "아이디어의 메신저"라는 거. 사람들이 나를 판단하러 온 게 아니라, 유용한 정보를 듣고 싶어서 온 거라고 생각하면 긴장이 줄어든다고. 실제로 그랬다. "이 사람들이 내 발표를 평가하고 있다"에서 "이 사람들한테 내가 겪은 걸 공유하고 있다"로 관점을 바꾸니까 몸이 풀렸다.

## 중간에 막혔다

다음 슬라이드로 넘기고 나서 뭘 말해야 할지 까먹었다. 2초. 그 2초가 영원처럼 느껴졌다. 머릿속이 하얘졌다. 슬라이드에 적힌 키워드를 봤다. "CDN 캐시 설정 변경." 아, 맞다. CDN 얘기. 기억이 돌아왔다.

나중에 동료한테 물어봤다. "중간에 내가 멈춘 거 눈치 챘어?" 못 챘다고 했다. 발표자가 느끼는 2초의 침묵과 청중이 느끼는 2초의 침묵은 다르다. 발표자한테는 치명적인 실수 같지만, 청중한테는 그냥 "잠깐 생각을 정리하는 시간" 정도로 보인다. 이걸 알게 된 게 큰 수확이었다. 완벽하지 않아도 된다. 그리고 완벽하지 않은 부분을 청중은 대부분 모른다.

## 대답 못한 질문

발표 자체보다 Q&A가 더 무서웠다. 예상 못한 질문이 올 수 있으니까. 리허설은 가능하지만 Q&A 리허설은 불가능하다.

질문 두 개가 나왔다. 첫 번째는 쉬웠다. "이 최적화를 다른 페이지에도 적용할 계획이 있나요?" "네, 다음 스프린트에 목록 페이지에도 적용할 예정입니다."

두 번째 질문이 문제였다. "이미지 포맷을 WebP로 변환하는 건 고려했나요? 현재 JPEG 대비 얼마나 개선이 될 수 있을까요?"

고려는 했다. 근데 도입하지 않은 이유가 있었다. 그 이유가 순간적으로 기억이 안 났다. CDN 설정 변경 때문이었는지, 호환성 문제였는지, 인프라 팀 리소스 부족이었는지. 머릿속에서 세 가지가 뒤섞였다. 2초가 지나고, 3초가 지나고.

대충 답할 수 있었다. "네, 고려했고, 여러 이유로 이번에는 도입하지 않았습니다." 이 정도로 넘어갈 수도 있었다. 근데 발표 전에 시니어가 해준 조언이 떠올랐다. "모르는 건 모른다고 해. 대충 답하는 거보다 100배 낫다."

솔직하게 말했다. "고려는 했는데, 당시에 도입하지 않은 구체적인 이유를 지금 바로 말씀드리기 어렵네요. 확인해서 슬랙으로 공유드릴게요."

그 순간에는 "발표자가 질문에 답 못하면 창피한 거 아닌가?"라는 생각이 스쳤다. 근데 회의실 분위기는 전혀 이상하지 않았다. 질문한 분도 "네, 궁금해서 물어본 거예요"라고 자연스럽게 넘어갔다.

다음 날 이유를 정리해서 슬랙에 올렸다. CDN 설정 변경에 인프라 팀의 작업이 필요했고, 그 분기에 인프라 팀의 리소스가 이미 꽉 차 있어서 다음 분기로 미뤘다는 거였다. 그리고 WebP 변환 시 예상 개선치도 추가로 조사해서 같이 적었다.

이 후속 메시지가 발표 자체보다 반응이 좋았다. "오 이거 정리 잘 해주셨네요", "우리 팀에도 비슷한 이슈가 있는데 참고할게요." 발표에서 답 못한 질문이 더 깊은 대화의 시작점이 된 거다.

## 발표 후에 달라진 것들

발표가 끝나고 박수를 받았다. 형식적인 건지 진심인 건지는 모르겠다. 근데 "끝났다"는 안도감이 밀려왔다. 회의실을 나오는데 다른 팀 동료가 다가와서 "발표 좋았어요, 저도 비슷한 이슈가 있었는데 참고할게요"라고 했다. 2주 동안의 준비가 보상받는 느낌.

그리고 예상 못한 변화가 있었다. 발표를 하고 나니까 팀에서 "이미지 최적화 관련 사람"이 됐다. 이미지 관련 이슈가 생기면 "이거 전에 발표한 사람한테 물어보자"가 된다. 발표 하나가 팀 내 포지셔닝에 영향을 준 거다.

기술 문서 쓰는 것도 쉬워졌다. 슬라이드를 만드는 과정에서 "복잡한 내용을 구조화하는 연습"을 한 거다. 문제 상황, 시도한 방법, 결과. 이 흐름이 몸에 배니까 문서 작성에도 바로 적용됐다.

미팅에서 의견 말하기도 수월해졌다. 15명 앞에서 30분 발표한 사람이 5명 미팅에서 1분 발언 못 할 이유가 없다. 여전히 긴장은 되지만, "그 정도는 해봤으니까"라는 경험치가 심리적 버팀목이 된다.

## 다시 한다면 다르게 할 것들

첫 발표를 복기하면서 적은 메모가 있다.

**영상을 찍어둘 것.** 다른 분 발표는 녹화해서 노션에 올려놓는데, 내 발표는 녹화를 깜빡했다. 자기 발표를 돌려보는 게 제일 효과적인 피드백이라는데, 기회를 놓쳤다.

**리허설을 동료 앞에서 더 일찍 할 것.** 혼자 4번 하고 동료 앞에서 1번 했는데, 동료 앞에서 하는 1번이 혼자 하는 4번보다 배우는 게 많았다. 사람이 앞에 있으면 완전히 다르다. 다음에는 슬라이드 초안이 나오는 시점에 바로 동료 앞에서 리허설한다.

**코드 슬라이드의 폰트 크기를 키울 것.** 20줄짜리 코드를 한 번에 보여주면 뒷자리에서 안 보인다. 중요한 부분만 먼저 보여주고, 전체 코드는 별도 링크로 제공하는 게 낫다.

**Q&A 예상 질문을 더 많이 준비할 것.** 5개 정도 준비했는데 부족했다. 다음에는 10개. 그리고 "모른다"라고 말하는 연습도 해둘 것. 첫 번째로 "모르겠습니다"라고 말하는 순간이 제일 어렵다. 두 번째부터는 좀 편해진다.

## 두 번째 발표

6개월 후에 두 번째 발표를 했다. 주제는 디자인 시스템 컴포넌트의 접근성 개선. 이번에는 준비 과정이 훨씬 수월했다. 주제 선정에 3일 대신 1일, 슬라이드 제작에 1주 대신 4일, 리허설에 5번 대신 3번. 그리고 처음부터 동료 앞에서 리허설했다.

여전히 떨렸다. 근데 첫 번째 때의 "세상이 무너지는 것 같은" 떨림이 아니라 "좀 긴장되네" 수준의 떨림이었다. 크게 다른 건 없었다. 준비하고, 연습하고, 떨면서 하고, 끝나면 안도한다. 이 사이클은 바뀌지 않았다.

다만 하나 확신하게 된 건 있다. 발표는 준비한 사람이 가장 많이 배운다. 듣는 사람은 30분 동안 유용한 정보를 얻지만, 발표하는 사람은 2주 동안 그 주제에 대해 이전보다 2배는 더 깊이 이해하게 된다. 발표는 청중을 위한 것이기도 하지만, 결국 발표자 본인을 위한 거다. 떨면서라도 하는 이유가 거기에 있다.


카드 컴포넌트를 만들었다. 메인 페이지에서는 3열 그리드로, 사이드바에서는 1열로, 모달 안에서도 쓰인다. 미디어 쿼리로 반응형을 잡았더니 금방 문제가 생겼다.

미디어 쿼리는 **뷰포트** 너비를 기준으로 한다. 그런데 카드의 너비는 뷰포트가 아니라 부모 컨테이너가 결정한다. 데스크톱 뷰포트(1440px)에서 사이드바 안의 카드는 좁은데, 미디어 쿼리는 "뷰포트가 넓으니까 가로 레이아웃으로 가자"고 판단한다.

```css
/* 이게 문제다 */
@media (min-width: 768px) {
  .card {
    flex-direction: row; /* 뷰포트가 넓으면 가로 레이아웃 */
  }
}
```

사이드바(300px) 안에 있는 카드가 가로 레이아웃으로 렌더링되면서 텍스트가 찌그러진다. 뷰포트는 넓지만 카드가 놓인 공간은 좁으니까.

이 문제를 해결하려면 `.sidebar .card`, `.modal .card` 같은 컨텍스트별 스타일을 추가해야 한다. 컴포넌트가 자신이 어디에 놓이는지 알아야 한다는 뜻이다. 컴포넌트의 재사용성이 깨진다.

## Container Queries로 해결하기

Container Queries는 뷰포트 대신 **부모 컨테이너**의 크기를 기준으로 스타일을 적용한다.

```css
/* 부모를 컨테이너로 지정 */
.card-wrapper {
  container-type: inline-size;
}

/* 컨테이너 너비에 따라 스타일 적용 */
@container (min-width: 400px) {
  .card {
    flex-direction: row;
  }
}

@container (max-width: 399px) {
  .card {
    flex-direction: column;
  }
}
```

이제 카드가 어디에 놓이든 — 메인 그리드든, 사이드바든, 모달이든 — 자신이 차지하는 공간에 맞게 스스로 레이아웃을 결정한다.

## 실제 마이그레이션 과정

기존 미디어 쿼리 기반 컴포넌트를 Container Queries로 바꾸는 건 기계적인 작업은 아니었다. 사고방식을 바꿔야 했다.

**미디어 쿼리 사고방식:** "화면이 768px 이상이면 이 레이아웃"

**Container Query 사고방식:** "이 컴포넌트가 400px 이상의 공간을 가지면 이 레이아웃"

브레이크포인트의 기준이 달라진다. 뷰포트의 768px과 컨테이너의 400px은 완전히 다른 기준이다. 컴포넌트를 다양한 크기의 컨테이너에 넣어보면서 적절한 브레이크포인트를 새로 찾아야 했다.

Storybook이 여기서 도움이 됐다. 스토리 하나에 여러 너비의 래퍼를 만들어서 카드가 각 크기에서 어떻게 보이는지 한 눈에 확인했다.

```typescript
export const ResponsiveCard: Story = {
  render: () => (
    <div style={{ display: 'flex', gap: '24px', flexWrap: 'wrap' }}>
      {[200, 300, 400, 600].map((width) => (
        <div key={width} style={{ width, containerType: 'inline-size' }}>
          <p style={{ fontSize: 12, color: '#888' }}>{width}px</p>
          <Card title="제목" description="설명..." />
        </div>
      ))}
    </div>
  ),
};
```

## container-type 선택

`container-type`에는 세 가지 값이 있다:

- `inline-size`: 가로 방향만 쿼리 가능. 대부분 이걸 쓴다
- `size`: 가로·세로 모두 쿼리 가능. 높이 기반 레이아웃 변경이 필요할 때
- `normal`: 기본값. 컨테이너 쿼리 대상이 아님

`size`를 쓰면 브라우저가 해당 요소의 크기를 고정해야 해서 레이아웃 계산이 달라질 수 있다. 명시적으로 높이를 지정하지 않은 요소에 `container-type: size`를 넣으면 높이가 0이 될 수 있다. 대부분의 경우 `inline-size`로 충분하다.

## Container Query Units

컨테이너 크기를 기준으로 한 단위도 사용할 수 있다.

```css
.card-title {
  font-size: clamp(14px, 3cqi, 24px);
}
```

`cqi`는 컨테이너 인라인 크기의 1%다. 컨테이너가 좁으면 글자가 작아지고, 넓으면 커진다. `clamp`와 함께 쓰면 최소/최대를 제한할 수 있다.

| 단위 | 의미 |
|------|------|
| `cqw` | 컨테이너 너비의 1% |
| `cqh` | 컨테이너 높이의 1% |
| `cqi` | 컨테이너 인라인 크기의 1% |
| `cqb` | 컨테이너 블록 크기의 1% |

## 미디어 쿼리를 완전히 대체하나?

아니다. 페이지 전체 레이아웃(네비게이션 숨기기, 사이드바 접기)은 여전히 미디어 쿼리가 맞다. 이건 뷰포트에 대한 판단이니까.

경험적으로 이런 구분이 잘 맞았다:

- **미디어 쿼리:** 페이지 레벨 레이아웃. 네비게이션, 사이드바, 전체 그리드 구조
- **Container Queries:** 컴포넌트 레벨 레이아웃. 카드, 리스트 아이템, 위젯

둘을 섞어 쓰면 된다. 페이지 레이아웃은 미디어 쿼리로 잡고, 그 안의 컴포넌트들은 Container Queries로 자율적으로 반응하게.

2026년 기준 모든 주요 브라우저에서 지원하니까, 폴리필 걱정 없이 프로덕션에 쓸 수 있다. 재사용 가능한 컴포넌트를 만든다면, Container Queries는 선택이 아니라 기본이 되어야 한다.



개발자라면 누구나 복사-붙여넣기를 한다. 이걸 부정하는 사람은 거짓말을 하거나, 기억력이 나쁘거나, 둘 중 하나다.

Stack Overflow에서, 블로그에서, GitHub 이슈 코멘트에서, 심지어 같은 프로젝트의 다른 파일에서. 우리는 매일 코드를 복사하고, 붙여넣고, 동작하면 넘어간다. 나도 그렇다. 솔직히 내 코드의 상당 부분이 어딘가에서 시작된 코드다.

복사 자체가 문제는 아니다. 문제는 그 다음이다.

## 동작하면 이해한 거 아니야?

주니어 시절 나의 작업 흐름은 이랬다. 기능을 구현하다가 막힌다. 에러 메시지를 구글에 붙여넣는다. Stack Overflow에서 답변을 찾는다. 코드를 복사한다. 에러가 사라진다. 다음 기능으로 넘어간다.

이 과정에서 빠진 게 있다. "왜 이 코드가 문제를 해결하는지" 이해하는 단계. 에러가 사라졌으니까, 동작하니까, 이해한 거라고 착각했다. 동작과 이해 사이에는 거대한 간극이 있는데, 당시에는 그 간극이 보이지 않았다.

한동안은 별 문제 없이 지나갔다. 복사한 코드가 대부분 간단한 것들이었으니까. 배열 메서드 사용법, CSS 레이아웃 트릭, 날짜 포맷팅 유틸. 이런 것들은 복사해서 쓰다 보면 자연스럽게 익혀지기도 한다.

문제는, 복사하는 코드의 복잡도가 올라가기 시작하면서 터졌다.

## useEffect와 클로저, 그리고 메모리 누수

그 사건은 실시간 알림 기능을 만들 때 일어났다. WebSocket으로 서버에서 알림을 받아서 화면에 표시하는 기능이었다. useEffect 안에서 WebSocket 연결을 맺고, 메시지를 수신하면 상태를 업데이트하는 구조.

WebSocket을 useEffect에서 다루는 패턴을 블로그에서 찾았다. 코드는 대충 이런 모양이었다.

```javascript
useEffect(() => {
  const ws = new WebSocket(url);

  ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    setNotifications(prev => [...prev, data]);
  };

  return () => {
    ws.close();
  };
}, [url]);
```

깔끔해 보였다. 복사해서 붙여넣고, 변수명만 프로젝트에 맞게 바꿨다. 로컬에서 테스트해보니 잘 동작했다. PR을 올리고 머지했다.

일주일 후, QA에서 리포트가 왔다. "알림 페이지에 오래 있으면 브라우저가 느려져요." 개발자 도구를 열어봤다. 메모리 사용량이 시간이 지날수록 계속 올라가고 있었다. 전형적인 메모리 누수 패턴이었다.

원인을 찾는 데 반나절이 걸렸다. 문제는 내가 복사한 코드에 있었지만, 코드 자체의 문제는 아니었다. 내가 이해하지 못한 채 붙여넣은 맥락의 문제였다.

실제 프로젝트에서는 단순히 `url`만 의존성 배열에 넣으면 안 되는 상황이었다. 유저의 인증 토큰이 갱신될 때마다 WebSocket을 재연결해야 했는데, 토큰이 바뀌어도 `url`은 같았기 때문에 이전 연결이 닫히지 않고 새 연결이 추가로 열렸다. 클린업 함수가 실행되지 않으니 이전 WebSocket 인스턴스가 계속 살아 있었고, 각각의 `onmessage` 핸들러가 상태를 업데이트하고 있었다.

클로저의 동작 방식을 이해했다면 이 문제를 미리 잡을 수 있었다. 의존성 배열의 의미를 제대로 알았다면 `url`만으로는 부족하다는 걸 알았을 거다. 하지만 나는 복사한 코드가 "이런 상황에서 동작하는 코드"라는 걸 모른 채, 내 상황에 그대로 적용한 거다.

## 복사한 코드의 숨은 가정

이 사건 이후로 복사한 코드를 다르게 보기 시작했다. 모든 코드에는 가정이 들어 있다. 원본 코드의 작성자는 특정 상황을 전제로 그 코드를 썼다. 그 가정이 내 상황과 맞는지 확인하지 않으면, 코드는 동작하는 것처럼 보이다가 예상치 못한 순간에 깨진다.

Stack Overflow 답변을 다시 읽어보면, 종종 "이건 X 상황을 가정한 예제입니다"라는 주석이 달려 있다. 예전에는 그런 주석을 무시했다. 코드만 복사하면 되니까. 하지만 그 주석이 말하는 "X 상황"이 내 상황과 다르면, 그 코드는 내 프로젝트에서 시한폭탄이다.

비슷한 일이 또 있었다. 무한 스크롤을 구현할 때, Intersection Observer를 사용하는 코드를 블로그에서 가져왔다. 잘 동작했다. 그런데 리스트 아이템 안에 이미지가 있으면 스크롤이 버벅거렸다. 원본 코드는 텍스트 리스트를 전제로 작성된 거였고, 이미지 로딩에 따른 높이 변화를 고려하지 않았다. `rootMargin`을 조정하고 이미지 placeholder를 넣어야 했는데, 원본 코드에서는 그런 처리가 필요 없었으니 당연히 없었다.

또 한 번은 debounce 유틸 함수를 복사해서 검색 입력에 적용했다. 동작은 잘 됐는데, 컴포넌트가 언마운트될 때 타이머가 정리되지 않아서 "Can't perform a React state update on an unmounted component" 경고가 떴다. 원본 코드는 React 바깥에서 쓰이는 순수 JavaScript debounce였고, 컴포넌트 라이프사이클은 고려 대상이 아니었다.

매번 같은 패턴이었다. 코드 자체는 맞다. 하지만 내 맥락에서는 틀렸다.

## 세 단계: 복사, 이해, 적응

이제 내가 따르는 원칙이 있다. 거창한 건 아니고, 복사-붙여넣기를 할 때 세 단계를 밟는 거다.

**1단계: 복사.** 이건 그대로다. 좋은 코드를 찾으면 복사한다. 바퀴를 재발명하는 데 시간을 쓸 이유는 없다.

**2단계: 이해.** 복사한 코드를 한 줄씩 읽는다. 각 줄이 왜 있는지 설명할 수 있는지 자문한다. 설명하지 못하는 줄이 있으면, 그 줄을 검색하거나 지워보거나 바꿔본다. 예를 들어 `return () => { ws.close(); }`에서 `return`이 하는 역할을 설명할 수 없으면, useEffect의 클린업 함수가 뭔지부터 찾아본다.

이 단계에서 시간이 꽤 걸린다. 원래 5초면 끝나던 복사-붙여넣기가 10분, 20분이 되기도 한다. 하지만 이 10분이 나중에 디버깅에 쓸 반나절을 아껴준다.

**3단계: 적응.** 원본 코드의 가정을 내 상황에 맞게 수정한다. 의존성 배열에 빠진 값은 없는지, 에러 처리가 되어 있는지, 클린업이 필요한지, 내 프로젝트의 컨벤션에 맞는지. 이 단계를 거치면 "복사한 코드"가 "내 코드"가 된다. 문제가 생겨도 디버깅할 수 있다. 왜 이렇게 작성했는지 설명할 수 있다.

## 복사 코드가 쌓여서 만들어진 것

사실 이 이야기의 핵심은 복사 자체가 아니다. 이해하지 않고 넘어가는 습관이 쌓이면 어떻게 되는가에 대한 거다.

복사한 코드가 한두 개일 때는 괜찮다. 그런데 프로젝트가 커지면서 이해하지 못한 코드가 여기저기 쌓이기 시작하면, 어느 순간 코드베이스 전체가 블랙박스가 된다. 내가 작성한 코드인데 내가 설명하지 못하는 부분이 점점 늘어난다.

이런 코드베이스에서 버그가 터지면 공포스럽다. 어디가 문제인지 감도 안 잡힌다. 이 함수가 정확히 뭘 하는지 모르니까, 여기가 원인인지 저기가 원인인지 판단할 수 없다. 결국 전부 콘솔 로그를 찍어가면서 하나씩 확인해야 한다.

반면에, 모든 코드를 이해하고 있는 코드베이스는 다르다. 버그 리포트가 들어오면 "아, 아마 저기일 거야"라는 직감이 생긴다. 그 직감이 맞는 경우가 많다. 코드를 이해하고 있기 때문에 가능한 거다.

## 같은 팀 안에서의 복사

외부에서 가져오는 코드만 문제가 아니다. 같은 프로젝트 안에서의 복사도 함정이 있다.

새로운 페이지를 만들 때, 기존의 비슷한 페이지를 복사해서 시작하는 경우가 많다. 빠르고 효율적인 방법이다. 문제는, 기존 페이지에 있던 코드 중 새 페이지에는 필요 없는 부분을 그대로 두는 거다. 안 쓰는 상태 변수, 필요 없는 API 호출, 관련 없는 이벤트 핸들러. "나중에 정리하지" 하고 넘어가는데, 그 "나중"은 오지 않는다. 그렇게 프로젝트 전체에 죽은 코드가 쌓인다.

더 나쁜 건, 기존 페이지에 있던 버그까지 복사되는 거다. A 페이지에서 발견 못한 버그가 B, C, D 페이지로 퍼진다. 나중에 A 페이지의 버그를 고쳐도, B, C, D는 여전히 같은 버그를 안고 있다. 복사의 원본을 추적하기 어렵기 때문에, 고쳐야 할 곳을 전부 찾아내는 것 자체가 일이 된다.

## 복사를 부끄러워하지 않기

한 가지 더. 복사-붙여넣기를 부끄러워할 필요는 없다고 생각한다. 모든 코드를 처음부터 직접 작성해야 한다는 강박은 비효율적이다. 이미 좋은 코드가 있는데 왜 다시 쓰나.

다만, 복사한 코드에 대한 책임은 복사한 사람에게 있다. Stack Overflow에서 가져온 코드가 프로덕션에서 문제를 일으키면, 그건 원본 답변자의 잘못이 아니라 내 잘못이다. "Stack Overflow에서 이렇게 하라고 했는데요"는 변명이 안 된다.

동료와 코드 리뷰를 할 때도 이 기준을 적용한다. "이 코드 어디서 가져왔어요?"라고 물어볼 때, 출처를 물어보는 게 아니라 이해도를 확인하는 거다. "이 부분은 왜 이렇게 되어 있어요?"에 대답할 수 있으면, 복사든 직접 작성이든 상관없다.

가끔 후배 개발자들이 "검색 안 하고 코드 쓸 수 있으려면 얼마나 걸려요?"라고 물어본다. 답은 "영원히 안 된다"이다. 경력이 쌓여도 검색한다. 라이브러리 API를 매번 외우지 못해서, 가끔 만나는 엣지 케이스의 해법을 기억하지 못해서, 이전에 해본 적 없는 새로운 작업이어서. 달라지는 건, 검색한 결과를 이해하는 속도와 깊이다.

복사하되, 이해하고, 내 것으로 만들자. 그게 복붙 주도 개발의 함정에서 빠져나오는 유일한 방법이다. 거창한 방법이 아니라서 미안한데, 실제로 이게 전부다.

그리고 한 가지만 더. 이해하는 과정이 느리다고 조급해하지 않았으면 한다. 처음 보는 패턴을 완전히 이해하는 데 30분이 걸려도 괜찮다. 그 30분은 낭비가 아니라 투자다. 다음에 비슷한 패턴을 만나면 5분 만에 이해할 수 있다. 그리고 그 다음에는 직접 쓸 수 있게 된다. 복사에서 이해로, 이해에서 체득으로. 이 과정이 성장이다.


개발자 커뮤니티에서 "2년마다 이직해야 연봉이 오른다"는 말이 정설처럼 돌아다닌다. 링크드인을 열면 "OO에서 XX로 이직했습니다" 소식이 끝없이 올라온다. 모든 사람이 더 좋은 곳으로, 더 빠르게 움직이고 있는 것 같다.

3년째 같은 회사에 있다. 가끔 불안하다. 시장에서 뒤처지고 있는 건 아닌가? 더 좋은 기회를 놓치고 있는 건 아닌가?

그런데 이 불안을 가만히 들여다보면, 실체가 없는 경우가 많다.

## 빠른 이직이 항상 좋은가

이직하면 연봉이 오르는 건 사실이다. 그런데 연봉만 놓고 판단하면 놓치는 게 있다.

**깊이.** 한 도메인에서 2년 이상 일하면, 표면적 구현을 넘어 시스템의 구조적 문제가 보이기 시작한다. 왜 이 아키텍처를 선택했는지, 왜 이 기술 부채가 생겼는지, 어떻게 점진적으로 개선할 수 있는지. 이런 감각은 프로젝트를 처음부터 끝까지 경험해봐야 생긴다.

2년마다 이직하면 항상 "새 프로젝트 적응기"에 있게 된다. 온보딩하고, 코드베이스를 파악하고, 팀 문화에 적응하고. 이 시기가 지나야 진짜 기여가 시작되는데, 그 전에 다시 이직하는 패턴.

**관계.** 오래 일하면 동료와의 신뢰가 쌓인다. 슬랙 한 줄로 해결되는 일이 새 팀에서는 미팅 두 번이 필요하다. 이 신뢰의 가치는 연봉으로 환산되지 않지만, 일의 효율에 큰 영향을 준다.

**영향력.** 오래 있으면 팀과 조직에 영향을 줄 수 있는 위치가 된다. 기술 방향을 제안하고, 프로세스를 개선하고, 후임을 키우는 것. 이런 경험은 매니지먼트 트랙이든 IC 트랙이든 시니어로 가는 데 필수적이다.

## 머무르기의 가치

같은 자리에 머무르는 건 정체가 아니다. 같은 회사에서도 성장할 수 있다.

기존 시스템을 개선하는 경험이 있다. 처음부터 만드는 것보다 어렵고, 배우는 것도 많다. 레거시 코드를 리팩토링하고, 기술 부채를 갚고, 성능을 개선하는 과정에서 설계 판단력이 길러진다.

팀을 성장시키는 경험도 있다. 주니어가 들어와서 시니어로 성장하는 과정을 함께하는 건, 자기 자신의 기술적 깊이와는 다른 차원의 성장이다.

제품이 실제 사용자에게 쓰이면서 생기는 문제를 장기간 추적하는 경험도 이직하면 얻기 어렵다. "6개월 전에 내린 아키텍처 결정이 지금 이런 결과를 만들었다"는 피드백 루프. 이게 판단력을 키운다.

## 불안과 함께 살기

그래도 불안은 사라지지 않는다. SNS에서 동료가 이직 소식을 올릴 때마다 흔들린다.

이 불안에 대처하는 방식을 하나 찾았다. "나는 지금 이 회사에서 아직 배울 게 있는가?"라고 자문하는 거다.

배울 게 남아 있으면 머무른다. 배울 게 정말 없다고 느끼면 — 같은 일을 반복하고 있고, 도전이 없고, 성장 방향이 보이지 않으면 — 그때 이직을 고민해도 늦지 않다.

중요한 건 이직의 타이밍이 아니라 이유다. "다들 이직하니까"가 아니라 "여기서 더 이상 성장하기 어렵기 때문에"라는 이유. 전자는 불안에 의한 결정이고, 후자는 판단에 의한 결정이다.

느리게 간다고 틀린 게 아니다. 깊이와 속도는 종종 반비례한다. 빠르게 많은 곳을 경험하는 것도 전략이고, 한 곳에서 깊이 파는 것도 전략이다. 자기에게 맞는 속도를 찾는 게 중요하지, 남의 속도에 맞추는 건 의미 없다.



CSS Grid를 "알고는 있는데 실무에서 잘 안 쓰게 되는" 기술이라고 말하는 사람이 많다. Flexbox로 대부분 해결되니까. 나도 그랬다. 그런데 어느 순간부터 Flexbox로 하면 코드가 지저분해지는 레이아웃이 자꾸 생겼다. 특히 2차원 배치가 필요한 경우.

Grid를 실무에서 쓰기 시작한 건 대시보드 리뉴얼 작업 때였다. 그때 만든 레이아웃 패턴 중에서 지금까지 반복적으로 재사용하는 5개를 정리한다.

## 1. 대시보드 그리드

대시보드는 Grid의 가장 자연스러운 사용처다. 카드 크기가 다르고, 특정 카드는 2칸을 차지하고, 화면 크기에 따라 배치가 달라져야 한다.

```css
.dashboard {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: 200px;
  gap: 16px;
  padding: 24px;
}

.card-wide {
  grid-column: span 2;
}

.card-tall {
  grid-row: span 2;
}

.card-large {
  grid-column: span 2;
  grid-row: span 2;
}

@media (max-width: 1024px) {
  .dashboard {
    grid-template-columns: repeat(2, 1fr);
  }
}

@media (max-width: 640px) {
  .dashboard {
    grid-template-columns: 1fr;
  }

  .card-wide,
  .card-tall,
  .card-large {
    grid-column: span 1;
    grid-row: span 1;
  }
}
```

이걸 Flexbox로 하면 어떻게 될까. `flex-wrap`을 쓰고, 각 카드에 `flex-basis`를 퍼센트로 주고, gap 대신 margin을 계산해서 넣고... 가능은 하지만 코드가 두 배는 길어진다. 특히 `card-tall`처럼 세로로 2칸을 차지하는 건 Flexbox로는 자연스럽게 구현이 안 된다.

## 2. 사이드바 + 메인 콘텐츠

전형적인 어드민 레이아웃이다. 왼쪽 사이드바는 고정 너비, 오른쪽 메인은 남은 공간을 차지한다.

```css
.layout {
  display: grid;
  grid-template-columns: 260px 1fr;
  grid-template-rows: 64px 1fr;
  height: 100vh;
}

.header {
  grid-column: 1 / -1;
  border-bottom: 1px solid #e5e7eb;
}

.sidebar {
  grid-row: 2;
  border-right: 1px solid #e5e7eb;
  overflow-y: auto;
}

.main {
  grid-row: 2;
  overflow-y: auto;
  padding: 24px;
}
```

"이건 Flexbox로도 쉽게 되잖아"라고 할 수 있다. 맞다. 이 정도는 Flexbox로도 충분하다. 그런데 여기서 요구사항이 추가된다.

사이드바를 접었다 펼 수 있어야 하고, 접었을 때 아이콘만 보여야 한다. Grid에서는 `grid-template-columns`만 바꾸면 된다.

```css
.layout {
  display: grid;
  grid-template-columns: 260px 1fr;
  transition: grid-template-columns 0.2s ease;
}

.layout.collapsed {
  grid-template-columns: 64px 1fr;
}
```

한 줄로 끝난다. 사이드바 안의 내용물은 CSS나 컴포넌트 레벨에서 조건부 렌더링하면 된다. `transition`도 부드럽게 걸린다.

## 3. 반응형 카드 그리드

이건 진짜 많이 쓴다. 상품 목록, 블로그 포스트 목록, 갤러리 등. 카드가 화면 크기에 따라 자동으로 열 수가 바뀌는 패턴.

```css
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  gap: 20px;
}
```

이 한 줄이 미디어 쿼리 없이 반응형 그리드를 만들어준다. `auto-fill`은 가능한 많은 열을 채우고, `minmax(280px, 1fr)`은 각 카드가 최소 280px, 최대로는 남은 공간을 균등 분할한다.

`auto-fill`과 `auto-fit`의 차이가 종종 헷갈리는데, 실무적으로 중요한 차이는 아이템 수가 적을 때 나타난다.

```css
/* auto-fill: 빈 열도 공간을 차지함 */
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));

/* auto-fit: 빈 열은 공간을 0으로 줄여서 기존 아이템이 늘어남 */
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
```

카드가 2개인데 화면이 넓을 때, `auto-fill`은 카드 오른쪽에 빈 공간이 남고, `auto-fit`은 카드 2개가 전체 너비를 나눠 가진다. 대부분의 목록 UI에서는 `auto-fill`이 더 자연스럽다. 카드가 3개인데 한 줄에 2개씩 들어가는 화면에서 카드가 비정상적으로 커 보이면 안 되니까.

## 4. Holy Grail 레이아웃

헤더, 푸터, 사이드바 2개, 메인 콘텐츠. 웹의 고전적인 레이아웃인데, Grid의 `grid-template-areas`를 쓰면 코드가 시각적으로 읽힌다.

```css
.page {
  display: grid;
  grid-template-areas:
    "header  header  header"
    "nav     main    aside"
    "footer  footer  footer";
  grid-template-columns: 200px 1fr 200px;
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
}

.header { grid-area: header; }
.nav    { grid-area: nav; }
.main   { grid-area: main; }
.aside  { grid-area: aside; }
.footer { grid-area: footer; }

@media (max-width: 768px) {
  .page {
    grid-template-areas:
      "header"
      "main"
      "nav"
      "aside"
      "footer";
    grid-template-columns: 1fr;
    grid-template-rows: auto;
  }
}
```

`grid-template-areas`의 장점은 미디어 쿼리에서 레이아웃 순서를 바꾸기가 쉽다는 거다. 모바일에서 `nav`를 `main` 아래로 내리고 싶으면 areas 문자열만 수정하면 된다. HTML 순서를 건드릴 필요가 없다.

단점도 있다. 이름을 붙이는 게 귀찮고, 복잡한 레이아웃에서는 area 이름이 많아져서 오히려 가독성이 떨어질 수 있다. 팀 내에서는 "3영역 이하일 때만 areas를 쓰자"는 암묵적 합의가 있다.

## 5. 폼 레이아웃

폼을 Grid로 만들면 라벨과 인풋의 정렬이 깔끔해진다. 특히 라벨이 왼쪽, 인풋이 오른쪽인 가로 배치 폼에서.

```css
.form {
  display: grid;
  grid-template-columns: 140px 1fr;
  gap: 12px 16px;
  align-items: start;
  max-width: 600px;
}

.form label {
  text-align: right;
  padding-top: 8px;
  font-weight: 500;
  color: #374151;
}

.form .full-width {
  grid-column: 1 / -1;
}

.form .actions {
  grid-column: 2;
  display: flex;
  gap: 8px;
}

@media (max-width: 640px) {
  .form {
    grid-template-columns: 1fr;
  }

  .form label {
    text-align: left;
    padding-top: 0;
  }

  .form .actions {
    grid-column: 1;
  }
}
```

```tsx
<form className="form">
  <label htmlFor="name">이름</label>
  <input id="name" type="text" />

  <label htmlFor="email">이메일</label>
  <input id="email" type="email" />

  <label htmlFor="message">메시지</label>
  <textarea id="message" rows={4} />

  <div className="full-width">
    <p className="help-text">* 개인정보 처리 방침에 동의합니다</p>
  </div>

  <div className="actions">
    <button type="submit">제출</button>
    <button type="reset">초기화</button>
  </div>
</form>
```

`gap: 12px 16px`에서 앞이 row gap, 뒤가 column gap이다. 이걸 Flexbox로 하면 각 행을 div로 감싸야 한다. Grid에서는 label과 input을 그냥 나열하면 된다. 2열로 정의했으니까 자동으로 줄바꿈된다.

## subgrid는 아직 이르다

CSS subgrid를 쓰면 자식 요소가 부모의 그리드 트랙을 물려받을 수 있다. 카드 내부의 제목, 설명, 버튼 높이를 다른 카드와 맞출 때 유용한데, 브라우저 지원이 아직 완전하지 않다. 2024년 기준 Chrome, Firefox, Safari 최신 버전에서는 되지만, 사내 시스템처럼 IE나 구형 브라우저를 지원해야 하는 프로젝트에서는 못 쓴다.

나도 아직 프로덕션에서 subgrid를 쓴 적은 없다. 써보고 싶은 마음은 있는데, "아직 너무 이르지 않나"라는 생각과 "지원 안 되는 브라우저에서 레이아웃이 깨지면 어쩌지"라는 걱정이 앞선다. 이런 새로운 CSS 기능들은 항상 그렇다. 알고는 있되, 프로덕션에 투입하는 건 1~2년 기다려야 마음이 편하다.

CSS에서 부모 요소를 선택하는 건 오랫동안 불가능했다. "자식이 특정 상태일 때 부모의 스타일을 바꾸고 싶다"는 요구사항이 나오면 JavaScript를 꺼내야 했다. `:has()` 선택자가 이걸 바꿨다.

`:has()`는 말 그대로 "~을 가진 요소"를 선택한다. `A:has(B)`는 "B를 자식으로 가진 A"를 선택한다.

```css
/* 이미지를 포함한 카드만 패딩을 다르게 */
.card:has(img) {
  padding: 0;
}

/* 체크된 체크박스를 가진 label */
label:has(input:checked) {
  background-color: #e0f2fe;
  border-color: #2563eb;
}
```

2025년 기준으로 모든 주요 브라우저에서 지원한다. Chrome 105+, Firefox 121+, Safari 15.4+. 실무에서 써도 되는 수준이다.

## 폼 유효성 시각화

이전에는 입력 필드의 유효성에 따라 부모 요소의 스타일을 바꾸려면 JavaScript가 필요했다.

```css
/* input이 invalid일 때 감싸는 div의 스타일 변경 */
.form-group:has(input:invalid:not(:placeholder-shown)) {
  --border-color: #ef4444;
  --label-color: #ef4444;
}

.form-group:has(input:valid:not(:placeholder-shown)) {
  --border-color: #22c55e;
  --label-color: #22c55e;
}

.form-group:has(input:focus) {
  --border-color: #2563eb;
  --label-color: #2563eb;
}

.form-group {
  border: 2px solid var(--border-color, #e5e7eb);
  border-radius: 8px;
  padding: 12px;
}

.form-group label {
  color: var(--label-color, #374151);
  font-size: 0.875rem;
}
```

```html
<div class="form-group">
  <label for="email">이메일</label>
  <input id="email" type="email" placeholder="이메일을 입력하세요" required />
</div>
```

`:not(:placeholder-shown)`은 사용자가 뭔가 입력했을 때만 유효성 스타일을 보여주기 위해서다. 빈 필드에서부터 빨간색이 보이면 사용자 경험이 안 좋으니까.

## 빈 상태 처리

리스트가 비었을 때 "데이터가 없습니다" 메시지를 보여주는 것도 CSS만으로 가능하다.

```css
.list:not(:has(.list-item)) .empty-state {
  display: block;
}

.list:has(.list-item) .empty-state {
  display: none;
}
```

```html
<ul class="list">
  
  <li class="empty-state">표시할 항목이 없습니다</li>
</ul>
```

이전에는 JavaScript에서 배열 길이를 체크하고 조건부 렌더링을 해야 했던 패턴이다. 물론 React에서는 여전히 조건부 렌더링이 자연스럽지만, 서버에서 내려주는 정적 HTML이나 CMS 기반 페이지에서는 이 CSS 패턴이 유용하다.

## 카드 레이아웃

카드의 내용물에 따라 레이아웃을 다르게 가져가는 패턴.

```css
/* 이미지가 있는 카드: 이미지 위 + 텍스트 아래 */
.card:has(.card-image) {
  display: grid;
  grid-template-rows: 200px 1fr;
}

/* 이미지 없는 카드: 텍스트만 */
.card:not(:has(.card-image)) {
  display: flex;
  flex-direction: column;
  justify-content: center;
  padding: 24px;
}

/* 태그가 3개 이상인 카드: 태그 영역을 넓게 */
.card:has(.tag:nth-child(3)) .tag-container {
  flex-wrap: wrap;
  gap: 4px;
}
```

## 네비게이션 활성 상태

현재 활성화된 링크가 있는 네비게이션 그룹의 스타일을 바꾸는 것.

```css
/* 활성 링크를 가진 nav-group에 배경색 */
.nav-group:has(.nav-link.active) {
  background-color: #f0f9ff;
  border-radius: 8px;
}

/* 활성 링크가 있으면 그룹 제목도 강조 */
.nav-group:has(.nav-link.active) .nav-group-title {
  color: #2563eb;
  font-weight: 600;
}
```

## 형제 선택과의 조합

`:has()`는 자식뿐 아니라 형제 선택자와도 조합할 수 있다.

```css
/* 다음 형제에 에러 메시지가 있는 input */
input:has(+ .error-message) {
  border-color: #ef4444;
}
```

```html
<input type="email" />
<span class="error-message">올바른 이메일을 입력하세요</span>
```

`+`는 바로 다음 형제를 의미한다. `input:has(+ .error-message)`는 "바로 다음 형제가 `.error-message`인 input"을 선택한다.

## 테이블 인터랙션

```css
/* 체크박스가 체크된 행 강조 */
tr:has(input[type="checkbox"]:checked) {
  background-color: #eff6ff;
}

/* 체크된 행이 하나라도 있으면 bulk action 바 표시 */
table:has(tr input[type="checkbox"]:checked) + .bulk-actions {
  display: flex;
}

/* 모든 체크박스가 체크되면 헤더 체크박스 스타일 변경 */
thead:has(input:checked) {
  background-color: #dbeafe;
}
```

어드민 대시보드에서 자주 쓰는 패턴이다. 행을 선택하면 배경색이 바뀌고, 하나라도 선택하면 "선택 삭제" 같은 bulk action UI가 나타나는 것. 이전에는 JavaScript로 상태를 관리하고 클래스를 토글해야 했다.

## 다크 모드와의 조합

```css
/* 시스템 다크 모드에서 이미지가 있는 카드의 이미지 밝기 조절 */
@media (prefers-color-scheme: dark) {
  .card:has(img) img {
    filter: brightness(0.85);
  }
}

/* data-theme으로 다크 모드를 관리하는 경우 */
[data-theme="dark"] .card:has(img) img {
  filter: brightness(0.85);
}
```

## 주의할 점

**성능.** `:has()`는 다른 선택자에 비해 브라우저가 처리하는 비용이 크다. 특히 `*:has(.something)` 같이 전체 선택자와 결합하면 모든 요소를 검사해야 한다. 범위를 좁혀서 쓰는 게 좋다.

```css
/* 피해야 할 패턴 */
*:has(.error) { /* 모든 요소 검사 */ }

/* 범위를 좁히자 */
.form-group:has(.error) { /* .form-group만 검사 */ }
```

**:has()는 forgiving selector list를 사용한다.** `:has()` 안에 유효하지 않은 선택자가 있어도 전체 규칙이 무효화되지 않는다. 이건 장점이기도 하지만, 오타를 발견하기 어려울 수도 있다.

`:has()`가 나오기 전에는 "CSS로 부모를 선택할 수 없다"가 프론트엔드 면접 단골 질문이었다. 이제 그 답이 바뀌었다. 바뀐 게 단순히 선택자 하나가 추가된 게 아니라, CSS가 할 수 있는 것의 범위가 확장된 거다. JavaScript로 클래스를 토글하던 코드, 상태를 관리하던 코드 중에서 `:has()`로 대체할 수 있는 게 생각보다 꽤 있다. 기존 코드를 쭉 훑어보면서 "이거 :has()로 되지 않나?" 하고 찾아보면 놀라울 거다.


"CSS는 프로그래밍이 아니잖아요."

신입 시절에 회식 자리에서 누군가 이런 말을 했다. 백엔드 개발자였다. 웃으면서 한 말이었고, 악의는 없었을 거다. 나도 그때는 대충 웃어넘겼다. 왜냐하면 그때는 나도 그렇게 생각했으니까.

2년이 지난 지금은 생각이 완전히 다르다. CSS는 어렵다. 진짜 어렵다. 어려운 정도가 아니라 예측 불가능하다. 그리고 예측 불가능하다는 건, 제대로 이해하고 있지 않다는 뜻이다.

## 4시간짜리 specificity 버그

지난해에 있었던 일이다. 디자인 시스템에서 버튼 컴포넌트의 스타일을 수정하는, 아주 사소한 작업이었다. secondary 버튼의 호버 색상을 바꾸는 거. 5분이면 될 줄 알았다.

`.btn-secondary:hover`의 `background-color`를 바꿨다. 로컬에서 확인했다. 적용이 안 됐다. 왜?

DevTools를 열었다. 내 스타일이 취소선이 그어져 있었다. 다른 규칙에 의해 덮어씌워지고 있었다. 범인을 찾아보니 `.card .btn.btn-secondary`라는 셀렉터가 있었다. 누가 언제 이걸 작성한 건지 git blame을 돌려봤다. 8개월 전. 이미 퇴사한 사람이 작성한 코드였다.

이 셀렉터의 specificity가 더 높았다. 클래스 3개 vs 클래스 1개 + 가상 클래스 1개. 당연히 전자가 이긴다.

"그러면 specificity를 높이면 되지." 그래서 `.card .btn.btn-secondary:hover`로 바꿨다. 됐다. 끝. 이라고 생각했는데 다른 페이지에서 같은 버튼이 또 다르게 보였다. 거기는 `.modal .content .btn-secondary`라는 셀렉터가 있었다. 또 specificity 싸움.

이걸 하나하나 잡기 시작하면 끝이 없다. specificity를 높이면 다른 곳에서 또 깨진다. 이건 두더지 게임이다. 머리를 하나 때리면 다른 데서 올라온다.

결국 근본 원인은 디자인 시스템의 CSS 구조 자체에 있었다. 컴포넌트 스타일이 전역 CSS로 관리되고 있었고, 여기저기서 specificity를 높여가면서 덮어쓰는 패턴이 쌓여 있었다. 8개월 전 그 코드는 당시에는 문제를 해결했겠지만, 시한폭탄이었던 거다.

버튼 호버 색상 하나 바꾸는 데 4시간이 걸렸다. 그리고 이건 근본적으로 해결한 게 아니라 일단 그 페이지들에서만 안 깨지게 패치한 거다. 진짜 해결은 CSS 구조를 리팩토링하는 것이었는데, 그건 몇 주짜리 작업이었다.

## Safari가 등장하면 모든 게 변한다

크로스 브라우저 호환성이라는 게 있다. 이론적으로는 CSS 명세가 있고, 브라우저가 그 명세를 구현하니까 어디서든 같게 보여야 한다. 현실은 다르다. 특히 Safari.

한번은 flexbox 레이아웃이 Safari에서만 깨졌다. Chrome, Firefox에서는 완벽했다. Safari에서만 아이템의 높이가 이상하게 늘어났다. 원인은 `flex` 아이템 안에 이미지가 있었는데, Safari가 이미지의 기본 `aspect-ratio`를 다르게 처리하는 거였다.

또 한번은 `gap` 속성이 Safari 구 버전에서 먹히지 않았다. flexbox의 `gap`은 비교적 최근에 Safari가 지원하기 시작했다. 근데 우리 사용자 중 상당수가 아이폰을 쓰고, iOS의 Safari 업데이트는 OS 업데이트에 묶여 있어서, 꽤 오래된 버전의 Safari가 살아 있었다.

`position: sticky`도 Safari에서 독특하게 동작한다. `overflow` 속성이 있는 조상 요소의 범위 안에서만 스티키가 작동하는 건 모든 브라우저가 같지만, Safari는 그 범위를 해석하는 방식이 미묘하게 다를 때가 있다. 이걸 디버깅하면서 반나절을 날렸다.

이런 이슈들을 겪으면 "Can I Use"를 습관적으로 확인하게 된다. 그리고 모든 CSS 속성에 대해 "Safari에서도 되나?"를 자동으로 의심하게 된다. 이 습관이 형성되기까지 꽤 많은 핫픽스를 배포했다.

## "그냥 Tailwind 쓰면 되잖아"

이런 말을 종종 듣는다. Tailwind를 쓰면 CSS의 복잡한 부분을 몰라도 된다는 뉘앙스. 나도 Tailwind를 쓴다. 생산성이 좋다. 클래스 이름 고민 안 해도 되니까 빠르다.

근데 Tailwind가 CSS를 대체하는 건 아니다. Tailwind는 CSS 위에 있는 추상화다. CSS를 모르고 Tailwind를 쓰면, Tailwind의 유틸리티 클래스가 뭘 하는 건지 모르면서 쓰는 거다. 작동하는 것처럼 보이지만, 뭔가 이상하게 동작할 때 디버깅을 못 한다.

`flex items-center justify-between`을 붙이면 원하는 레이아웃이 나온다. 그런데 특정 화면 크기에서 아이템이 넘쳐서 잘린다면? `flex-wrap`을 추가해야 하는데, 왜 `flex-wrap`이 필요한지 이해하려면 flexbox의 기본 동작을 알아야 한다. flex 아이템은 기본적으로 줄바꿈 없이 한 줄에 다 들어가려 하고, `min-width: auto`가 기본값이라 내용물보다 작아지지 않는다는 것. 이걸 모르면 Tailwind를 써도 레이아웃이 깨질 때 멘붕이 온다.

Ahmad Shadeed라는 CSS 전문 개발자가 "Defensive CSS"라는 개념을 정리했다. 미래에 깨지지 않을 CSS를 미리 방어적으로 작성하는 방법론인데, 이 사람의 글을 읽다 보면 CSS가 얼마나 예측 불가능한 상황을 만드는지 잘 보인다.

예를 들어 이런 것들이다. `height: 350px`을 hero 섹션에 주면, 내용이 많아졌을 때 overflow가 발생한다. `min-height: 350px`을 써야 한다. `justify-content: space-between`으로 아이템을 배치하면, 아이템이 예상보다 적을 때 양 끝에 붙어서 어색해진다. `gap`을 쓰는 게 더 안전하다. 스크롤바가 나타나면서 레이아웃이 밀리는 현상은 `scrollbar-gutter: stable`로 방어할 수 있다.

이런 디테일 하나하나가 실전에서 버그로 나타난다. 그리고 이건 Tailwind를 쓰든 CSS Modules를 쓰든 styled-components를 쓰든 똑같이 알아야 하는 것들이다. 도구가 뭐든 결국 CSS 자체의 동작을 이해해야 한다.

Stephanie Eckles가 운영하는 ModernCSS.dev에도 비슷한 맥락의 컨텐츠가 많다. 셀렉터 마스터리, 폼 요소 커스텀 스타일링, 미디어 쿼리 없이 반응형 만드는 방법 같은 것들. 하나하나가 "이거 알아야 실전에서 안 깨진다"는 내용이다. CSS의 기본기가 탄탄하지 않으면 이 중 아무것도 제대로 이해할 수 없다.

## CSS의 반직관적인 부분들

CSS가 어려운 이유 중 하나는 직관적이지 않다는 거다. 경험과 다르게 동작하는 경우가 많다.

`margin` 겹침(collapse) 현상이 대표적이다. 위아래로 인접한 두 요소에 각각 `margin-bottom: 20px`, `margin-top: 30px`을 주면 둘 사이 간격이 50px일 것 같지만 30px이다. 큰 쪽이 이긴다. 이건 규칙이 있긴 한데, 그 규칙이 여러 조건에 따라 달라진다. 부모 요소에 `padding`이나 `border`가 있으면 겹침이 안 일어난다든가, flexbox나 grid 컨텍스트 안에서는 안 일어난다든가.

`z-index`도 단순해 보이지만 실전에서는 지옥이다. `z-index: 9999`를 줬는데 밑에 깔리는 상황. stacking context라는 개념을 이해해야 한다. `position`, `opacity`, `transform`, `filter` 같은 속성이 새로운 stacking context를 만든다. 부모가 `z-index: 1`이면 자식에 `z-index: 99999`를 줘도 부모 밖으로 못 나간다.

`width: 100%`가 의도와 다르게 동작하는 경우도 잦다. 부모의 `padding`을 포함하는 건지 아닌지는 `box-sizing`에 달려있다. `border-box`를 전역으로 설정 안 해놓으면 계산이 미묘하게 어긋나면서 가로 스크롤이 생긴다. 대부분의 리셋 CSS가 `box-sizing: border-box`를 전역으로 설정하는 이유가 이거다.

이런 것들을 하나하나 익히는 데 시간이 걸린다. 그리고 안 겪어보면 모른다. 문서를 읽어도 실감이 안 난다. 직접 레이아웃이 깨지고, 삽질하고, 원인을 찾고 나서야 "아 이게 이렇게 동작하는 거구나" 하게 된다.

## 그럼에도 CSS를 제대로 배워야 하는 이유

여기까지 읽으면 "CSS 힘들다 그만하고 싶다"가 될 수 있는데, 반대다. 이래서 제대로 배워야 한다는 거다.

CSS를 잘하는 프론트엔드 개발자와 못하는 프론트엔드 개발자의 차이는 시간이 지날수록 벌어진다. JavaScript는 에러가 나면 콘솔에 빨간 글씨가 뜬다. 뭐가 잘못됐는지 알려준다. CSS는 조용히 잘못된다. 에러 메시지가 없다. 그냥 화면이 이상하게 보인다. 그리고 왜 이상한지 추론해야 한다. 이 추론 능력이 CSS 실력이다.

디자이너가 시안을 주면 "이건 CSS로 어려운데요"라고 말하는 게 아니라, "이건 이렇게 구현하면 되는데, 이 부분은 Safari에서 이슈가 있을 수 있으니 대안을 같이 정하면 좋겠어요"라고 말할 수 있어야 한다. 이게 전문성이다.

CSS를 잘하면 JavaScript에 대한 의존도도 줄어든다. 많은 인터랙션이 CSS만으로 가능하다. 트랜지션, 애니메이션, 반응형 레이아웃, 다크모드, 스크롤 기반 효과. JavaScript로 억지로 구현하면 성능도 떨어지고 코드도 복잡해진다. CSS가 네이티브로 할 수 있는 걸 CSS로 하면 성능도 좋고 코드도 깔끔하다.

## CSS는 프로그래밍이다

CSS에는 변수(custom properties)가 있다. 계산(`calc`, `min`, `max`, `clamp`)이 있다. 조건 분기(`@media`, `@supports`, `@container`)가 있다. 스코프가 있다(cascade layers, `@scope`). 상속이 있다. 요즘은 `@property`로 타입까지 지정할 수 있다.

이게 프로그래밍이 아니면 뭘까. 문법이 중괄호와 세미콜론이라서 프로그래밍 같아 보이지 않을 뿐, 로직을 작성하고, 조건에 따라 다르게 동작하게 하고, 변수를 관리하고, 스코프를 신경 쓰는 건 다른 언어와 다르지 않다.

다만 CSS의 독특한 점은 선언적이라는 거다. "이렇게 해라"가 아니라 "이 조건에서는 이런 상태이다"를 기술한다. 그래서 명령형 프로그래밍에 익숙한 사람에게는 사고 방식 자체가 전환이 필요하다. 이 전환이 쉽지 않기 때문에, CSS가 어렵게 느껴지는 거다.

CSS가 쉽다고 말하는 사람은 두 종류다. CSS를 정말 잘하는 사람이거나, CSS로 뭔가 복잡한 걸 만들어본 적이 없는 사람이거나. 후자가 훨씬 많다.

만약 "CSS 좀 할 줄 안다"고 생각하면, Ahmad Shadeed의 Defensive CSS 글을 한번 읽어보길 권한다. 자기가 모르는 게 얼마나 많은지 알게 된다. 나도 그랬다.

CSS는 겸손하게 대해야 하는 기술이다. 쉬워 보이는 순간, 반드시 뒤통수를 친다.



작년에 캐러셀 컴포넌트를 만들었다.

Swiper.js를 설치하고, 옵션을 맞추고, 리사이즈 이벤트 리스너를 달고, 클린업 함수를 작성했다. 번들 사이즈가 38KB 늘었다. PR 리뷰에서 동료가 한마디 했다. "이거 CSS `scroll-snap`으로 안 돼?" 됐다. JS 0줄에, 라이브러리 설치도 필요 없었다. 그 38KB와 내가 쓴 60줄의 코드가 CSS 10줄로 대체되는 걸 보면서, 내가 얼마나 관성적으로 JavaScript부터 꺼내 드는지 깨달았다.

Ahmad Shadeed의 ishadeed.com과 Stephanie Eckles의 moderncss.dev를 뒤지다 보면, 요즘 CSS가 할 수 있는 게 정말 많아졌다는 걸 체감한다. 문제는 우리가 그걸 모른다는 게 아니라, 습관적으로 npm install부터 친다는 거다.

여기 정리한 6가지는 전부 내가 실제 프로젝트에서 JS를 걷어내고 CSS로 바꾼 것들이다.

## Scroll Snap: 캐러셀 라이브러리 이제 그만

위에서 말한 그 캐러셀 이야기다. 전형적인 가로 스크롤 캐러셀을 만든다고 해보자.

JS로 하면 보통 이렇게 된다:

```tsx
import { useRef, useEffect } from 'react';

function Carousel({ items }) {
  const containerRef = useRef(null);

  const scrollTo = (index) => {
    const container = containerRef.current;
    const child = container.children[index];
    child.scrollIntoView({ behavior: 'smooth', inline: 'start' });
  };

  useEffect(() => {
    const container = containerRef.current;
    // 리사이즈 대응
    const handleResize = () => {
      // 현재 위치 재계산...
    };
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);

  return (
    <div ref={containerRef} style={{ display: 'flex', overflow: 'auto' }}>
      {items.map(item => <Card key={item.id} {...item} />)}
    </div>
  );
}
```

이걸 CSS `scroll-snap`으로 바꾸면:

```css
.carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  gap: 16px;
}

.carousel > * {
  scroll-snap-align: start;
  flex-shrink: 0;
  width: 300px;
}
```

```tsx
function Carousel({ items }) {
  return (
    <div className="carousel">
      {items.map(item => <Card key={item.id} {...item} />)}
    </div>
  );
}
```

리사이즈 핸들러도 필요 없고, `scrollIntoView` 계산도 필요 없다. 브라우저가 알아서 가장 가까운 snap point로 스크롤을 잡아준다. `scroll-snap-type: x mandatory`가 핵심인데, `mandatory`는 스크롤이 끝나면 반드시 snap point에 정렬되도록 강제한다. `proximity`로 바꾸면 좀 더 부드럽게 동작한다.

내가 만들었던 제품 상세 페이지의 이미지 뷰어에서 Swiper.js를 걷어내고 이걸로 대체했을 때, 번들 사이즈가 눈에 띄게 줄었고 성능 점수도 올라갔다. 모바일에서의 터치 스크롤 느낌도 오히려 더 자연스러웠다.

## :has() — 드디어 부모를 볼 수 있다

CSS에서 가장 오래된 불만 중 하나가 "부모 선택자가 없다"는 거였다. 자식 상태에 따라 부모 스타일을 바꾸려면 항상 JS가 필요했다.

예를 들어 폼에서 input이 focus되면 감싸고 있는 div의 테두리 색을 바꾸고 싶다고 하자.

JS 시절:

```tsx
function InputGroup() {
  const [focused, setFocused] = useState(false);

  return (
    <div className={`input-group ${focused ? 'focused' : ''}`}>
      <label>이메일</label>
      <input
        type="email"
        onFocus={() => setFocused(true)}
        onBlur={() => setFocused(false)}
      />
    </div>
  );
}
```

```css
.input-group {
  border: 2px solid #ddd;
  border-radius: 8px;
  padding: 8px 12px;
}

.input-group.focused {
  border-color: #3b82f6;
  box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.1);
}
```

state 하나, 이벤트 핸들러 둘, 클래스 토글 하나. 이걸 위해서?

CSS `:has()`로 바꾸면:

```css
.input-group {
  border: 2px solid #ddd;
  border-radius: 8px;
  padding: 8px 12px;
}

.input-group:has(input:focus) {
  border-color: #3b82f6;
  box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.1);
}
```

```tsx
function InputGroup() {
  return (
    <div className="input-group">
      <label>이메일</label>
      <input type="email" />
    </div>
  );
}
```

state가 사라졌다. 컴포넌트가 순수해졌다. `:has()`는 "이 요소의 자손 중에 조건에 맞는 게 있으면"이라는 뜻이다. 부모 선택자라고 불리지만, 사실은 관계 선택자에 가깝다.

실무에서 이게 진짜 빛나는 건 카드 컴포넌트다. 카드 안에 이미지가 있으면 패딩을 없애고, 없으면 패딩을 넣는 식으로:

```css
.card {
  padding: 24px;
  border-radius: 12px;
  background: white;
}

.card:has(> img:first-child) {
  padding: 0;
  overflow: hidden;
}

.card:has(> img:first-child) > :not(img) {
  padding: 0 24px;
}
```

이전에는 이 로직을 컴포넌트에서 props로 분기했다. `variant="with-image"` 같은. 지금은 CSS가 콘텐츠를 보고 알아서 판단한다.

2025년 기준으로 모든 주요 브라우저가 `:has()`를 지원한다. Can I Use에서 확인해보면 글로벌 지원율이 90%를 넘는다.

## Container Queries: 뷰포트가 아니라 부모가 기준이다

media query의 한계는 명확하다. 뷰포트 기준이다. 사이드바에 들어간 카드 컴포넌트는 화면이 1200px여도 실제로는 300px 안에서 살고 있는데, media query는 그걸 모른다.

이걸 해결하려면 결국 JS로 부모의 크기를 측정해야 했다. `ResizeObserver`를 쓰거나, 라이브러리를 가져오거나.

```tsx
function Card() {
  const ref = useRef(null);
  const [isCompact, setIsCompact] = useState(false);

  useEffect(() => {
    const observer = new ResizeObserver(([entry]) => {
      setIsCompact(entry.contentRect.width < 400);
    });
    observer.observe(ref.current);
    return () => observer.disconnect();
  }, []);

  return (
    <div ref={ref} className={isCompact ? 'card compact' : 'card'}>
      <img src="/thumb.jpg" alt="" />
      <h3>제목</h3>
      <p>설명 텍스트</p>
    </div>
  );
}
```

이제 container queries로:

```css
.card-wrapper {
  container-type: inline-size;
}

.card {
  display: grid;
  grid-template-columns: 200px 1fr;
  gap: 16px;
}

@container (max-width: 400px) {
  .card {
    grid-template-columns: 1fr;
  }

  .card img {
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }
}
```

`container-type: inline-size`를 부모에 선언하면, 그 안의 자식들이 `@container` 쿼리를 쓸 수 있다. 뷰포트가 아니라 부모 컨테이너의 크기를 기준으로 반응한다.

이게 진짜 중요한 이유가 있다. 컴포넌트를 재사용 가능하게 만들려면, 그 컴포넌트가 어디에 배치되든 알아서 적응해야 한다. 메인 콘텐츠 영역에서도, 사이드바에서도, 모달 안에서도. media query로는 이걸 할 수가 없었다. Container queries는 진짜 의미에서의 반응형 컴포넌트를 가능하게 한다.

## CSS Nesting: Sass 없이도 된다

짧게 가자.

CSS nesting이 네이티브로 들어왔다. Sass를 쓰는 주된 이유 중 하나가 사라진 거다.

```css
/* 예전: Sass 없이 CSS */
.nav { display: flex; gap: 8px; }
.nav a { color: #333; text-decoration: none; }
.nav a:hover { color: #3b82f6; }
.nav a.active { font-weight: 700; color: #3b82f6; }

/* 지금: 네이티브 CSS nesting */
.nav {
  display: flex;
  gap: 8px;

  a {
    color: #333;
    text-decoration: none;

    &:hover {
      color: #3b82f6;
    }

    &.active {
      font-weight: 700;
      color: #3b82f6;
    }
  }
}
```

완전히 같은 문법이다. `&`도 된다. media query도 안에 넣을 수 있다:

```css
.hero {
  padding: 64px 24px;
  font-size: 48px;

  @media (max-width: 768px) {
    padding: 32px 16px;
    font-size: 28px;
  }
}
```

Sass 설정, 빌드 파이프라인, 의존성 관리. 이런 거 없이 그냥 `.css` 파일에 쓰면 된다. 프로젝트 초기 셋업이 한 단계 단순해진다.

한 가지 주의할 점이 있는데, nesting이 너무 깊어지면 Sass 때와 똑같은 문제가 생긴다. specificity가 올라가고 코드가 읽기 어려워진다. 3단계까지만 쓰자는 규칙은 여전히 유효하다.

## accent-color: 폼 요소 커스텀의 고통이 끝났다

checkbox, radio, range input의 색상을 브랜드 컬러로 바꾸려면 얼마나 고통스러웠는지 다들 기억할 거다.

기본 checkbox를 숨기고, 가짜 checkbox를 만들고, 클릭 이벤트를 연결하고, 접근성 속성을 하나하나 달아주고. 이 과정이 너무 싫어서 아예 Headless UI 같은 라이브러리를 쓰기도 했다.

```css
/* 예전의 커스텀 checkbox... 이런 걸 했었다 */
input[type="checkbox"] {
  appearance: none;
  width: 20px;
  height: 20px;
  border: 2px solid #ccc;
  border-radius: 4px;
  position: relative;
  cursor: pointer;
}

input[type="checkbox"]:checked {
  background: #3b82f6;
  border-color: #3b82f6;
}

input[type="checkbox"]:checked::after {
  content: '';
  position: absolute;
  left: 5px;
  top: 1px;
  width: 6px;
  height: 12px;
  border: solid white;
  border-width: 0 2px 2px 0;
  transform: rotate(45deg);
}
```

체크 표시를 `::after`로 그리고 있다. CSS로 체크 모양을 만드는 거다. 여기에 focus 스타일, disabled 스타일까지 추가하면 checkbox 하나에 CSS가 30줄이 넘는다.

`accent-color` 한 줄이면 된다:

```css
input[type="checkbox"],
input[type="radio"],
input[type="range"],
progress {
  accent-color: #3b82f6;
}
```

끝이다. 브라우저 기본 UI를 유지하면서 색상만 바꾼다. 접근성도 그대로고, focus ring도 그대로다. 브랜드 컬러만 입히면 되는 상황이라면 이걸로 충분하다.

물론 디자이너가 완전히 새로운 형태의 checkbox를 원한다면 `accent-color`로는 안 된다. 근데 "색상만 바꿔주세요"라는 요청이 체감상 80%다. 그 80%를 한 줄로 처리할 수 있다는 게 핵심이다.

## text-wrap: balance — 제목 줄바꿈의 미학

이건 기능적인 문제라기보다 디자인 품질의 문제다.

긴 제목이 두 줄로 넘어갈 때, 첫 줄은 빽빽하고 둘째 줄에 단어 하나만 덩그러니 남는 경우가 있다. 영어에서는 이걸 "widow"라고 부른다. 한국어에서도 마찬가지로 보기 안 좋다.

```
JavaScript 없이 CSS만으로 할 수 있는 놀라운
것들                    ← 이런 거
```

이걸 고치려고 JS로 글자 수를 세거나, `<br>`을 수동으로 넣거나, 혹은 그냥 무시했다.

```css
h1, h2, h3 {
  text-wrap: balance;
}
```

이 한 줄이면 브라우저가 알아서 두 줄의 길이를 비슷하게 맞춰준다.

```
JavaScript 없이 CSS만으로
할 수 있는 놀라운 것들      ← 이렇게 됨
```

주의할 점이 있다. `text-wrap: balance`는 성능상의 이유로 6줄 이하의 텍스트에서만 동작한다. 그래서 본문에 쓰는 건 의미가 없고, 제목이나 캡션 같은 짧은 텍스트에 쓰는 거다.

긴 본문에서 마지막 줄이 너무 짧아지는 걸 방지하고 싶으면 `text-wrap: pretty`를 쓴다. `balance`보다 가볍고, 마지막 줄만 신경 쓴다.

```css
p {
  text-wrap: pretty;
}
```

디자이너가 "이 제목 줄바꿈 좀 이상한데" 하고 슬랙에 메시지를 보내기 전에, 글로벌 스타일에 저 한 줄을 넣어두자.

## 언제 JS를 쓰고 언제 CSS를 쓸까

여기까지 읽으면 "그럼 JS는 다 필요 없는 건가" 싶을 수 있는데, 당연히 아니다.

CSS가 잘하는 건 선언적인 상태 변화다. hover, focus, 스크롤 위치, 부모 크기, 콘텐츠 유무. 이런 건 CSS가 브라우저 레벨에서 처리하니까 JS보다 빠르고 안정적이다.

JS가 필요한 건 외부 데이터가 개입하는 경우다. API 응답에 따라 UI가 바뀌어야 하거나, 유저 인터랙션의 히스토리를 추적해야 하거나, 타이머나 애니메이션 시퀀스를 세밀하게 제어해야 하는 경우.

내가 쓰는 기준은 단순하다. "이 동작이 CSS 속성의 변화만으로 표현 가능한가?" 그렇다면 CSS를 먼저 시도한다. 안 되면 그때 JS를 쓴다. 순서가 중요하다. JS부터 생각하면 CSS로 되는 것도 JS로 하게 된다.

다음 프로젝트에서 이 중 하나라도 써보면, 코드가 얼마나 단순해지는지 직접 느낄 수 있을 거다. 번들 사이즈가 줄고, state가 줄고, 버그가 줄어든다. 그리고 가끔은 그게 가장 큰 비즈니스 임팩트다.



AI 코딩 도구를 처음 쓸 때 가장 흔한 불만이 "맥락을 모른다"는 거다. 우리 프로젝트의 컨벤션, 사용하는 라이브러리, 선호하는 패턴 — 이런 걸 모르니까 매번 다른 스타일의 코드를 만들어낸다. 한 파일에서는 `axios`를 쓰고 다른 파일에서는 `fetch`를 쓰는 식이다.

이 문제를 해결하는 게 프로젝트 컨텍스트 파일이다. Cursor에서는 `.cursorrules`, Claude Code에서는 `CLAUDE.md`. 이름은 다르지만 역할은 같다. AI에게 "이 프로젝트에서는 이렇게 해"라고 알려주는 설명서다.

## 왜 필요한가

AI는 프롬프트에 없는 것은 모른다. "Server Actions를 쓰세요"라고 안 쓰면 API Route를 만든다. "named export를 쓰세요"라고 안 쓰면 default export를 쓴다. 매번 채팅에서 수정 요청을 할 수도 있지만, 컨텍스트 파일에 한 번 적어두면 모든 대화에 자동으로 적용된다.

## 구조: 뭘 넣어야 하나

세 가지 카테고리로 나눈다.

### 1. 기술 스택과 제약 조건

프로젝트가 어떤 도구를 쓰는지 명시한다. 의외로 이게 가장 중요하다.

```markdown
## 기술 스택
- Next.js 15 App Router (Pages Router 아님)
- TypeScript strict mode
- Tailwind CSS (CSS Modules 사용하지 않음)
- TanStack Query v5 (React Query)
- Prisma + PostgreSQL
```

"Pages Router 아님", "CSS Modules 사용하지 않음" 같은 부정형이 핵심이다. AI는 비슷한 기술 중 아무거나 골라서 쓰려 하니까, 안 쓰는 걸 명시적으로 배제해야 한다.

### 2. 코드 컨벤션

팀이 합의한 패턴을 적는다.

```markdown
## 컨벤션
- 컴포넌트는 named export (default export 사용하지 않음)
- 서버 컴포넌트 기본. 클라이언트 컴포넌트는 파일 최상단에 'use client'
- API 호출은 Server Actions으로. API Route는 웹훅 등 외부 연동에만 사용
- 에러 처리: try-catch 대신 Result 타입 패턴 사용
- 테스트: Vitest + Testing Library. E2E는 Playwright
- 커밋 메시지: Conventional Commits (feat:, fix:, chore:)
```

### 3. 프로젝트 구조

디렉토리 구조와 각 역할을 설명한다.

```markdown
## 프로젝트 구조
- app/ — Next.js App Router 라우트
- components/ — 공유 UI 컴포넌트
- features/ — 도메인별 기능 모듈 (components, hooks, actions)
- lib/ — 유틸리티, 설정, 외부 서비스 클라이언트
- prisma/ — DB 스키마, 마이그레이션
```

## 효과적인 작성법

**구체적으로 쓴다.** "깔끔한 코드를 작성하세요"는 의미 없다. "함수는 20줄 이내, 매개변수는 3개 이내"가 실행 가능한 지시다.

```markdown
# 나쁜 예
- 좋은 코드를 작성하세요
- 성능을 고려하세요

# 좋은 예
- 하나의 함수는 하나의 책임만
- 컴포넌트 props는 5개를 넘지 않도록. 넘으면 객체로 묶기
- 이미지는 next/image 사용. 외부 이미지는 next.config.js에 도메인 등록
```

**하지 말 것을 명시한다.** AI가 자주 하는 실수를 "하지 마라"로 적는다.

```markdown
## 하지 않는 것
- any 타입 사용하지 않음
- console.log를 커밋하지 않음 (디버깅 후 제거)
- 인라인 스타일 사용하지 않음 (Tailwind 사용)
- useEffect 안에서 데이터 fetching하지 않음 (Server Components 또는 TanStack Query 사용)
- index.ts에서 re-export하지 않음 (직접 import)
```

**예시 코드를 넣는다.** 말로 설명하기 어려운 패턴은 코드 예시가 효과적이다.

````markdown
## Server Action 패턴 예시
```typescript
'use server'

import { revalidatePath } from 'next/cache';

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string;

  const post = await prisma.post.create({
    data: { title },
  });

  revalidatePath('/posts');
  return post;
}
```
````

## 유지보수

컨텍스트 파일도 코드처럼 관리해야 한다. 프로젝트가 발전하면서 컨벤션이 바뀌면 업데이트해야 한다. 안 쓰는 라이브러리가 남아 있으면 AI가 그걸 계속 쓰려고 한다.

팀 프로젝트라면 컨텍스트 파일을 코드 리뷰 대상에 포함시키는 것도 좋다. 새 팀원이 합류했을 때 컨텍스트 파일을 읽으면 프로젝트 컨벤션을 빠르게 파악할 수 있다. AI를 위해 만든 문서가 사람에게도 유용하다.

길게 쓸 필요는 없다. 50줄이면 충분하다. AI에게 가장 중요한 건 "여기서는 이렇게 하고, 저건 하지 마라"는 명확한 경계선이다.



다크 모드를 "대충" 구현하는 건 쉽다. `prefers-color-scheme` 미디어 쿼리 하나면 된다. 문제는 "제대로" 구현하려고 할 때 시작된다. 사용자가 수동으로 전환할 수 있어야 하고, 새로고침해도 유지돼야 하고, 전환할 때 깜빡이면 안 되고, 시스템 설정도 존중해야 한다.

이 블로그의 다크 모드를 구현하면서 겪은 과정을 정리했다.

## CSS 변수로 테마 정의

먼저 색상을 CSS 변수로 관리한다. 컴포넌트마다 색상을 하드코딩하면 나중에 전부 바꿔야 하니까.

```css
:root {
  /* 라이트 모드 (기본) */
  --color-bg: #ffffff;
  --color-bg-secondary: #f5f5f5;
  --color-text: #1a1a1a;
  --color-text-secondary: #666666;
  --color-border: #e0e0e0;
  --color-primary: #2563eb;
  --color-primary-hover: #1d4ed8;
  --color-code-bg: #f1f5f9;
  --color-code-text: #334155;
}

[data-theme='dark'] {
  --color-bg: #0f0f0f;
  --color-bg-secondary: #1a1a1a;
  --color-text: #e0e0e0;
  --color-text-secondary: #999999;
  --color-border: #2a2a2a;
  --color-primary: #60a5fa;
  --color-primary-hover: #93bbfd;
  --color-code-bg: #1e293b;
  --color-code-text: #e2e8f0;
}
```

`[data-theme='dark']` 대신 `.dark` 클래스를 쓰는 방법도 있다. Tailwind CSS를 쓴다면 `darkMode: 'class'` 설정과 함께 `.dark` 클래스를 쓰는 게 자연스럽다.

컴포넌트에서는 이 변수를 참조한다.

```css
.card {
  background-color: var(--color-bg-secondary);
  color: var(--color-text);
  border: 1px solid var(--color-border);
}

.button-primary {
  background-color: var(--color-primary);
  color: white;
}

.button-primary:hover {
  background-color: var(--color-primary-hover);
}
```

색상을 바꿀 때 CSS 변수 값만 바꾸면 모든 컴포넌트에 반영된다.

## 테마 전환 로직

테마 상태는 세 가지 경우를 고려해야 한다.

1. 사용자가 명시적으로 선택한 테마가 있으면 그걸 따른다.
2. 선택한 적 없으면 시스템 설정을 따른다.
3. 시스템 설정이 바뀌면 (시스템 설정을 따르는 중일 때) 자동으로 반영한다.

```tsx
// hooks/useTheme.ts
import { useState, useEffect, useCallback } from 'react';

type Theme = 'light' | 'dark';
type ThemePreference = Theme | 'system';

function getSystemTheme(): Theme {
  if (typeof window === 'undefined') return 'light';
  return window.matchMedia('(prefers-color-scheme: dark)').matches
    ? 'dark'
    : 'light';
}

function getStoredPreference(): ThemePreference {
  if (typeof window === 'undefined') return 'system';
  return (localStorage.getItem('theme-preference') as ThemePreference) || 'system';
}

function applyTheme(theme: Theme) {
  document.documentElement.setAttribute('data-theme', theme);
}

export function useTheme() {
  const [preference, setPreference] = useState<ThemePreference>('system');
  const [resolvedTheme, setResolvedTheme] = useState<Theme>('light');

  // 초기화
  useEffect(() => {
    const stored = getStoredPreference();
    setPreference(stored);
    const resolved = stored === 'system' ? getSystemTheme() : stored;
    setResolvedTheme(resolved);
    applyTheme(resolved);
  }, []);

  // 시스템 테마 변경 감지
  useEffect(() => {
    const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)');

    const handleChange = () => {
      if (preference === 'system') {
        const newTheme = getSystemTheme();
        setResolvedTheme(newTheme);
        applyTheme(newTheme);
      }
    };

    mediaQuery.addEventListener('change', handleChange);
    return () => mediaQuery.removeEventListener('change', handleChange);
  }, [preference]);

  const setTheme = useCallback((newPreference: ThemePreference) => {
    setPreference(newPreference);
    localStorage.setItem('theme-preference', newPreference);
    const resolved = newPreference === 'system' ? getSystemTheme() : newPreference;
    setResolvedTheme(resolved);
    applyTheme(resolved);
  }, []);

  return { theme: resolvedTheme, preference, setTheme };
}
```

토글 버튼 UI는 이런 식이다.

```tsx
function ThemeToggle() {
  const { preference, setTheme } = useTheme();

  const options: { value: ThemePreference; label: string }[] = [
    { value: 'light', label: '라이트' },
    { value: 'dark', label: '다크' },
    { value: 'system', label: '시스템' },
  ];

  return (
    <div className="theme-toggle">
      {options.map(({ value, label }) => (
        <button
          key={value}
          onClick={() => setTheme(value)}
          className={preference === value ? 'active' : ''}
        >
          {label}
        </button>
      ))}
    </div>
  );
}
```

라이트/다크 두 가지만 토글하는 것보다 "시스템" 옵션을 주는 게 좋다. macOS나 Windows에서 자동 다크 모드를 쓰는 사용자가 많으니까.

## 깜빡임(Flash) 방지

이게 다크 모드에서 가장 까다로운 부분이다. 사용자가 다크 모드를 선택했는데, 페이지를 새로고침하면 잠깐 라이트 모드가 번쩍 보이는 현상. FOUC(Flash of Unstyled Content)와 비슷한 문제다.

원인은 이렇다. HTML이 먼저 로드되고, CSS가 적용되고, 그 다음에 JavaScript가 실행돼서 테마를 설정한다. JavaScript가 실행되기 전까지는 기본 테마(라이트)가 보이는 거다.

해결 방법은 **JavaScript가 실행되기 전에** 테마를 적용하는 거다. `<head>` 안에 인라인 스크립트를 넣으면 된다.

Next.js App Router에서는 `layout.tsx`에 이렇게 넣는다.

```tsx
// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ko" suppressHydrationWarning>
      <head>
        <script
          dangerouslySetInnerHTML={{
            __html: `
              (function() {
                var preference = localStorage.getItem('theme-preference') || 'system';
                var theme;
                if (preference === 'system') {
                  theme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
                } else {
                  theme = preference;
                }
                document.documentElement.setAttribute('data-theme', theme);
              })();
            `,
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}
```

이 스크립트는 파싱 차단(render-blocking)이지만, 아주 짧아서 성능에 영향이 거의 없다. 그 대가로 깜빡임을 완전히 방지할 수 있다.

`suppressHydrationWarning`을 넣는 이유는 서버에서 렌더링한 `data-theme`과 클라이언트에서 설정한 `data-theme`이 다를 수 있어서다. 이 경고는 무시해도 안전하다.

## 전환 애니메이션

테마가 바뀔 때 부드럽게 전환하려면 transition을 건다.

```css
:root {
  --transition-theme: background-color 0.2s ease, color 0.2s ease, border-color 0.2s ease;
}

body,
.card,
.button,
.input {
  transition: var(--transition-theme);
}
```

주의할 점은 **초기 로드 시에는 transition을 끄는** 거다. 안 그러면 페이지가 처음 로드될 때 라이트에서 다크로 전환되는 애니메이션이 보인다.

```tsx
// 초기 로드 시 transition 비활성화
useEffect(() => {
  // 초기 렌더 후 약간의 딜레이를 주고 transition 활성화
  const timer = setTimeout(() => {
    document.documentElement.classList.add('theme-transitions-enabled');
  }, 100);
  return () => clearTimeout(timer);
}, []);
```

```css
/* transition은 클래스가 있을 때만 적용 */
.theme-transitions-enabled body,
.theme-transitions-enabled .card {
  transition: var(--transition-theme);
}
```

## 이미지 처리

다크 모드에서 놓치기 쉬운 게 이미지다. 밝은 배경의 이미지가 다크 모드에서 눈을 찌를 수 있다.

```css
/* 다크 모드에서 이미지 밝기를 약간 낮추기 */
[data-theme='dark'] img:not([data-no-dim]) {
  filter: brightness(0.9);
}

/* 로고처럼 배경이 투명한 이미지 반전 */
[data-theme='dark'] .invertible {
  filter: invert(1) hue-rotate(180deg);
}
```

모든 이미지에 일괄 적용하는 것보다, 필요한 이미지에만 클래스를 붙이는 게 안전하다.

## next-themes 쓸까?

`next-themes`라는 라이브러리가 있다. 위에서 설명한 것들을 대부분 처리해준다.

```tsx
// app/layout.tsx
import { ThemeProvider } from 'next-themes';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ko" suppressHydrationWarning>
      <body>
        <ThemeProvider attribute="data-theme" defaultTheme="system">
          {children}
        </ThemeProvider>
      </body>
    </html>
  );
}
```

```tsx
// 컴포넌트에서
import { useTheme } from 'next-themes';

function ThemeToggle() {
  const { theme, setTheme } = useTheme();
  // ...
}
```

깜빡임 방지, 시스템 설정 감지, localStorage 저장을 전부 해준다. 직접 구현하는 것보다 이걸 쓰는 게 실용적이긴 하다. 다만 내부에서 어떤 일이 일어나는지 이해하고 쓰는 거랑 모르고 쓰는 건 다르다. 그래서 위에서 직접 구현하는 과정을 먼저 설명했다.

다크 모드를 구현하다 보면 "색상"만 바꾸는 게 아니라는 걸 알게 된다. 그림자의 강도, 이미지의 밝기, 보더의 가시성, 텍스트의 대비. 라이트와 다크에서 같은 값이 같은 느낌을 주지 않는다. 디자이너 없이 혼자 색상을 정하면 십중팔구 다크 모드의 대비가 너무 강하거나 너무 약하게 나온다. 피그마에서 라이트/다크 모두 검수받는 게 맞고, 그게 안 되면 실제 기기에서 밤에 직접 써보면서 조정하는 수밖에 없다.


2년차 때, 백엔드 개발자와 API 스펙을 논의하고 있었다. 대시보드 페이지에 필요한 데이터를 정리해서 전달했다. 사용자 정보, 최근 활동, 통계 수치, 설정값, 알림 목록. 한 화면에 보여줘야 하는 게 많았고, 나는 API 하나에서 전부 내려받으면 편할 것 같았다.

"이 응답에 필드가 50개가 넘는데, 다 필요해요?"

백엔드 개발자가 물었다. 당연히 필요하지, 화면에 다 보여줘야 하니까. 그렇게 답했다.

그 사람이 잠시 멈추더니 이렇게 말했다. "이 데이터를 한 번에 내리려면 테이블 6개를 조인해야 하고, 알림 목록은 서브쿼리가 필요해요. 이 API가 호출될 때마다 DB에 꽤 무거운 쿼리가 날아가요."

솔직히 그때는 그 말이 잘 와닿지 않았다. 조인? 서브쿼리? 무거운 쿼리? 프론트엔드에서 그건 그냥 `fetch` 한 번이고 JSON 하나인데. 내 입장에서는 API가 느리면 로딩 스피너를 보여주면 되는 거 아닌가 싶었다.

하지만 그 생각이 얼마나 좁았는지를 나중에야 깨달았다.

## API 하나의 뒷편

프론트엔드에서 API를 호출하면 JSON이 온다. 깔끔하다. 화면에 필요한 데이터가 구조화되어 들어있다. 이걸 받아서 상태에 넣고 렌더링하면 끝이다.

그 JSON이 만들어지기까지 뒤에서 무슨 일이 일어나는지를 프론트엔드 개발자는 잘 모른다. 나도 몰랐다.

대략 이런 일이 벌어진다. HTTP 요청이 서버에 도착한다. 라우터가 해당 엔드포인트의 핸들러를 찾는다. 핸들러가 비즈니스 로직을 실행한다. 대부분의 비즈니스 로직은 데이터베이스에서 데이터를 읽거나 쓰는 걸 포함한다. DB 드라이버가 SQL 쿼리를 데이터베이스 서버에 보낸다. 데이터베이스가 쿼리를 파싱하고, 실행 계획을 세우고, 디스크(또는 캐시)에서 데이터를 읽어서 결과를 반환한다. 서버가 이 결과를 가공해서 JSON으로 직렬화하고, HTTP 응답으로 보낸다.

이 과정에서 가장 시간이 많이 걸리는 건 보통 데이터베이스다. 네트워크 왕복, 쿼리 실행, 데이터 전송. API가 느리면 백엔드 코드의 문제일 수도 있지만, 대부분은 데이터베이스 쿼리가 느린 거다.

내가 50개 필드를 요구하면서 "다 필요해요"라고 했을 때, 그건 "테이블 6개를 조인하는 무거운 쿼리를 매 요청마다 실행해주세요"라고 한 것과 같았다. 프론트 입장에서는 JSON 필드 50개지만, DB 입장에서는 여러 테이블을 읽어서 합치는 비용이 드는 작업이다.

## 인덱스라는 게 왜 중요한지

데이터베이스를 공부하기 시작하면서 가장 먼저 "아하" 한 개념이 인덱스다.

책의 맨 뒤에 있는 색인(index)을 생각하면 된다. "React"라는 단어가 어디에 나오는지 찾고 싶을 때, 책을 1페이지부터 끝까지 넘기면서 찾을 수도 있지만, 색인을 보면 바로 찾을 수 있다. 데이터베이스 인덱스도 마찬가지다.

테이블에 100만 행이 있다고 하자. `WHERE email = 'user@example.com'`으로 검색할 때, 인덱스가 없으면 100만 행을 전부 읽어야 한다(풀 스캔). 인덱스가 있으면 바로 찾는다. 차이가 극적이다.

이걸 알고 나니 API 설계를 보는 눈이 달라졌다. 예를 들어 사용자 목록을 검색하는 API를 만든다고 하자. 프론트엔드에서 "이메일로 검색, 이름으로 검색, 가입일로 정렬"을 하고 싶다. 이 각각이 DB에서는 해당 컬럼에 인덱스가 있어야 빠르게 동작한다.

만약 "전화번호로도 검색하고 싶어요"라고 요구하면, 전화번호 컬럼에 인덱스를 추가해야 할 수 있다. 인덱스는 공짜가 아니다. 읽기는 빨라지지만 쓰기는 느려진다. 데이터를 넣거나 수정할 때마다 인덱스도 업데이트해야 하니까. 그래서 인덱스를 무한히 추가할 수는 없고, 실제로 자주 사용되는 검색 조건에 대해서만 추가하는 게 좋다.

프론트엔드 개발자가 이걸 알면 뭐가 좋으냐. 백엔드 개발자한테 "이 필터 추가해주세요"라고 할 때 좀 더 맥락 있는 대화를 할 수 있다. "이 필터는 사용 빈도가 높으니까 인덱스가 필요할 것 같은데, 어떻게 생각하세요?" 이런 식의 논의를 할 수 있다.

## N+1 문제를 아는 프론트엔드 개발자

N+1 문제. 백엔드 개발자에게는 기본 상식인데, 프론트엔드 개발자는 모르는 경우가 많다. 나도 몰랐다.

예를 들어보겠다. 게시글 목록을 보여주는 페이지가 있다. 각 게시글에 작성자의 프로필 이미지와 이름을 보여줘야 한다. 게시글이 20개면, 이걸 어떻게 가져올까.

순진한 구현은 이렇다. 먼저 게시글 20개를 가져온다 (쿼리 1개). 그 다음 각 게시글의 작성자 정보를 가져온다 (쿼리 20개). 총 21개의 쿼리. 이게 N+1이다. 게시글 N개에 대해 N+1개의 쿼리가 실행되는 것.

20개면 체감이 안 될 수도 있다. 그런데 페이지에 게시글이 100개면? 쿼리가 101개 날아간다. 각 쿼리에 네트워크 왕복 시간과 실행 시간이 있으니까, 이게 누적되면 API 응답이 눈에 띄게 느려진다.

해결책은 보통 조인이나 배치 로딩이다. 게시글을 가져올 때 작성자 정보도 같이 조인해서 가져오면 쿼리 1개로 끝난다. 또는 작성자 ID를 모아서 `WHERE id IN (1, 2, 3, ...)` 같은 배치 쿼리를 날리면 쿼리 2개로 끝난다.

이걸 프론트엔드 개발자가 왜 알아야 하냐고? API를 설계할 때 같이 논의하기 위해서다.

프론트에서 "게시글 목록에 작성자 이름도 보여줘야 해요"라고 하면, 백엔드 개발자는 그걸 어떻게 가져올지 고민한다. 프론트가 API 구조를 같이 논의할 수 있으면 더 효율적인 결과가 나온다. "게시글과 작성자 정보를 별도 API로 분리하면 프론트에서 병렬 호출할 수 있는데, 한 번에 조인해서 내려주는 게 나을까요?" 이런 대화를 할 수 있다.

## 정규화를 알면 컴포넌트 설계가 달라진다

데이터베이스 정규화를 공부하면서 재미있는 걸 발견했다. DB 테이블 설계와 프론트엔드 상태 설계가 생각보다 비슷하다는 거다.

정규화의 핵심은 데이터 중복을 줄이는 거다. 예를 들어, 게시글 테이블에 작성자 이름을 직접 저장하면 중복이 발생한다. 같은 사용자가 10개의 게시글을 쓰면 그 이름이 10번 저장된다. 사용자가 이름을 바꾸면 10곳을 다 수정해야 한다. 그래서 작성자 ID만 저장하고, 이름은 사용자 테이블에서 참조한다.

프론트엔드 상태 관리에서도 동일한 원칙이 적용된다. Redux나 Zustand 같은 전역 상태에서 데이터를 정규화하는 패턴이 있다. 게시글 목록과 사용자 목록을 각각 별도의 슬라이스에 저장하고, 게시글에는 작성자 ID만 가지고 있는 식이다. 이렇게 하면 사용자 정보가 업데이트됐을 때 한 곳만 수정하면 된다.

이걸 DB 정규화를 공부하기 전에는 그냥 "패턴"으로만 알고 있었다. "상태 정규화가 좋은 패턴이래" 수준이었다. 근데 DB 정규화를 이해하고 나니 왜 좋은 패턴인지가 명확해졌다. 데이터 무결성, 갱신 이상, 삭제 이상 같은 문제를 프론트엔드 상태에서도 동일하게 겪을 수 있다는 걸 알게 됐다.

## 스키마를 읽으면 컴포넌트가 보인다

요즘은 새 기능을 만들기 전에 DB 스키마를 먼저 본다. 백엔드 개발자한테 "이 기능 관련 테이블 구조 좀 보여주세요"라고 한다. ERD(Entity Relationship Diagram)가 있으면 그걸 보고, 없으면 테이블 정의라도 본다.

이게 왜 도움이 되냐면, 데이터의 관계를 먼저 이해하면 컴포넌트 구조를 더 잘 잡을 수 있다.

예를 들어 주문 관리 페이지를 만든다고 하자. 스키마를 보면 주문(orders) 테이블, 주문 항목(order_items) 테이블, 상품(products) 테이블, 결제(payments) 테이블이 있다. 주문과 주문 항목은 1:N 관계이고, 주문 항목과 상품은 N:1 관계이고, 주문과 결제는 1:1 관계다.

이걸 알면 컴포넌트를 어떻게 나눌지가 자연스럽게 보인다. `OrderDetail` 안에 `OrderItemList`가 있고, 각 `OrderItem`은 `ProductInfo`를 참조하고, `PaymentInfo`는 `OrderDetail`과 같은 레벨에 있다. 데이터 관계가 곧 컴포넌트 관계다.

API도 어떻게 요청해야 효율적인지 감이 온다. 주문 상세를 볼 때 결제 정보도 같이 필요한지, 주문 항목의 상품 상세까지 필요한지, 아니면 상품 이름 정도만 있으면 되는지. 스키마를 알면 백엔드에 더 구체적으로 요청할 수 있다. "주문 상세 API에서 order_items는 product의 name과 price만 포함시켜 주세요. thumbnail은 목록에서는 필요하지만 상세에서는 안 쓰거든요."

## 페이지네이션의 진짜 의미

프론트엔드에서 페이지네이션은 그냥 UX 패턴이다. 데이터가 많으니까 나눠서 보여주는 거. "다음 페이지" 버튼을 누르면 다음 데이터를 보여주는 거.

DB 관점에서 보면 얘기가 달라진다.

`SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 0` — 이게 첫 페이지다. `OFFSET 20`이면 두 번째 페이지. 여기까지는 괜찮다.

문제는 `OFFSET 10000`이다. 500번째 페이지쯤 되면 DB는 앞의 10000개 행을 건너뛰어야 한다. 건너뛴다는 게 공짜가 아니다. 실제로 10000개를 읽고 버린다. 데이터가 많을수록, 뒤쪽 페이지로 갈수록 느려진다.

이 때문에 대규모 데이터에서는 커서 기반 페이지네이션(cursor-based pagination)을 쓴다. "다음 20개"가 아니라 "이 ID 이후의 20개"를 가져오는 방식. 이렇게 하면 OFFSET 없이 인덱스를 타고 바로 접근할 수 있어서 항상 일정한 속도가 나온다.

프론트엔드 개발자가 이걸 알면 뭐가 달라지냐. 무한 스크롤을 구현할 때 "page=1, page=2" 방식으로 요청할 건지, "cursor=abc123" 방식으로 요청할 건지를 백엔드와 논의할 수 있다. 데이터가 수만 건 이상이면 커서 방식이 낫다는 걸 알고, 처음부터 그에 맞는 프론트엔드 구조를 잡을 수 있다.

## SELECT *의 비용

처음에 50개 필드 얘기로 돌아가보겠다.

`SELECT *`는 편하다. 필요한 컬럼을 일일이 안 적어도 되니까. 백엔드에서 API를 빠르게 만들 때 자주 쓴다. 프론트에서 "어떤 필드가 필요할지 아직 확실하지 않으니 일단 다 내려주세요"라고 하면 자연스럽게 `SELECT *`가 된다.

하지만 불필요한 데이터를 읽고 전송하는 건 비용이다. DB에서 디스크 I/O가 늘어나고, 네트워크 대역폭을 차지하고, JSON 직렬화 시간이 늘어나고, 프론트엔드에서 파싱하는 시간도 늘어난다. 한 번의 요청에서는 차이가 미미하지만, 동시 접속자가 수천 명이면 누적된다.

지금은 API를 요청할 때 정말 필요한 필드만 명시한다. "이 화면에서는 user의 id, name, avatar만 필요합니다. email, phone, address는 안 씁니다." 이렇게 구체적으로 말하면 백엔드에서도 최적화된 쿼리를 작성할 수 있다.

GraphQL이 인기를 얻은 이유 중 하나도 이거다. 프론트엔드가 필요한 필드만 정확히 명시할 수 있으니까. REST에서는 API 설계 시점에 이걸 합의해야 하지만, GraphQL에서는 프론트엔드가 런타임에 결정할 수 있다.

## 풀스택이 아니어도 된다, T자만 되면

내가 하고 싶은 말은 "프론트엔드 개발자도 풀스택이 되어야 한다"가 아니다. 그럴 필요 없다. SQL을 능숙하게 쓰거나, 데이터베이스를 설계할 수 있을 필요는 없다.

하지만 기본적인 개념 — 인덱스, 조인, N+1, 정규화, 페이지네이션 방식 — 정도는 알면 좋다. 이게 "T자형 인재"의 가로 막대 부분이다. 깊은 전문성은 프론트엔드에 두되, 인접 분야에 대한 기본적인 이해가 있으면 협업의 질이 달라진다.

The Pragmatic Engineer의 Gergely Orosz가 쓴 글을 보면, 시니어 엔지니어에게 기대하는 역량 중 하나가 "자기 전문 분야를 넘어서 시스템 전체를 이해하는 능력"이다. 프론트엔드 개발자가 DB를 전혀 모르면, API를 블랙박스로 대할 수밖에 없다. "요청하면 응답이 온다. 느리면 백엔드 문제." 이 사고방식에서 벗어나면, 더 나은 설계를 할 수 있고, 백엔드 개발자와 훨씬 생산적인 대화를 할 수 있다.

2년 전의 나한테 돌아가서 다시 그 미팅을 한다면, "50개 필드 다 필요합니다"가 아니라 이렇게 말할 것 같다.

"대시보드 상단의 요약 영역은 user 테이블과 stats 테이블만 조인하면 될 것 같고, 알림 목록은 별도 API로 분리해서 lazy load 하면 초기 로딩이 빨라질 것 같은데, 어떻게 생각하세요?"

같은 프론트엔드 개발자인데, 대화의 수준이 다르다. 그 차이를 만드는 건 DB를 "조금" 아는 것이다.

조금이면 충분하다. 그 조금이 생각보다 크다.



입사하고 처음 받은 업무가 기존 어드민 패널의 기능 추가였다. 코드베이스를 열었을 때의 첫 느낌을 잊을 수 없다. Class 컴포넌트가 섞여있었다. jQuery가 부분적으로 남아있었다. CSS는 전역 스타일시트 하나에 3,000줄이 들어있었다. 상태 관리는 Redux인데, 액션 타입이 문자열 상수로 별도 파일에 200개 넘게 정의되어 있었다.

```js
// actionTypes.js
export const FETCH_USERS_REQUEST = 'FETCH_USERS_REQUEST';
export const FETCH_USERS_SUCCESS = 'FETCH_USERS_SUCCESS';
export const FETCH_USERS_FAILURE = 'FETCH_USERS_FAILURE';
export const UPDATE_USER_REQUEST = 'UPDATE_USER_REQUEST';
export const UPDATE_USER_SUCCESS = 'UPDATE_USER_SUCCESS';
// ... 200개 더
```

TypeScript는 없었다. PropTypes를 쓰고 있었는데, 절반 정도의 컴포넌트에서는 그마저도 없었다. ESLint 설정은 있는데 `eslint-disable` 주석이 파일마다 붙어있었다.

나는 속으로 생각했다. "이걸 다 갈아엎어야 하는 거 아닌가?"

## 대규모 리팩토링의 유혹

팀 리드에게 말했다. "이 코드베이스를 TypeScript로 마이그레이션하고, Redux를 걷어내고, 컴포넌트를 전부 함수형으로 바꾸면 좋겠다." 팀 리드는 "좋은 생각이야. 근데 일정은 어떻게 되지?"라고 물었다.

주말에 대략적인 계획을 세워봤다. TypeScript 마이그레이션에 2주, Redux에서 Zustand로 전환에 3주, Class 컴포넌트를 함수형으로 변환에 1주, CSS 모듈화에 2주. 총 8주. 그 사이에 신규 기능 개발은 멈춰야 한다.

팀 리드가 한마디 했다. "비즈니스 팀에 '8주 동안 새 기능 없다'고 말할 수 있어?" 당연히 없었다. 어드민을 쓰는 운영팀에서는 매주 새로운 요구사항이 들어오고 있었다. 필터 추가해달라, 엑셀 다운로드 기능 넣어달라, 대시보드에 차트 추가해달라.

"그러면 어떻게 해요?"

"같이 가는 거지."

## 첫 번째 실패: Big Bang 마이그레이션

사실 팀 리드의 말을 듣기 전에 몰래 시도를 한 적이 있다. 주말에 혼자 브랜치를 파서, 가장 큰 페이지인 유저 관리 페이지를 통째로 다시 작성했다. Class 컴포넌트를 함수형으로, Redux를 React Query로, CSS를 Tailwind로. 이틀 동안 꽤 열심히 했다.

월요일에 PR을 올렸다. Changed files: 47. 시니어가 PR을 보더니 "이건 리뷰가 불가능해"라고 했다. 맞는 말이었다. 47개 파일이 동시에 바뀐 PR을 누가 제대로 리뷰할 수 있겠나. 하나의 버그를 놓치면 유저 관리 페이지 전체가 터진다. 그리고 이 기간에 다른 사람이 유저 관리 페이지 관련 작업을 하면 머지 충돌이 걷잡을 수 없이 커진다.

PR을 닫았다. 그 주말의 작업이 전부 버려졌다. 아까웠지만, 시니어 말이 맞았다.

## 점진적 개선 전략

시니어가 알려준 방법은 이랬다. "새로 만드는 건 새 기준으로 만들고, 기존 코드는 건드릴 때만 조금씩 고쳐."

원칙은 단순했다.

1. 새 파일은 TypeScript로 작성한다.
2. 기존 파일을 수정할 때, 해당 파일을 TypeScript로 전환할 수 있으면 한다. 못 하면 그냥 둔다.
3. 새 컴포넌트는 함수형 + hooks로 작성한다.
4. 새 API 호출은 React Query를 쓴다. 기존 Redux 로직은 건드리지 않는다.
5. PR 하나에 리팩토링과 기능 추가를 섞지 않는다.

5번이 특히 중요했다. 기능 추가 PR에 "김에 이것도 리팩토링했어요"를 넣으면, 버그가 생겼을 때 기능 변경 때문인지 리팩토링 때문인지 구분이 안 된다.

## tsconfig의 strict: false부터 시작

TypeScript 전환은 `tsconfig.json`에 `strict: false`를 넣는 것부터 시작했다. `strict: true`로 하면 기존 JS 파일에서 에러가 수백 개 뜨니까.

```json
{
  "compilerOptions": {
    "strict": false,
    "allowJs": true,
    "checkJs": false
  }
}
```

`allowJs: true`로 JS 파일과 TS 파일이 공존할 수 있게 했다. 새로 만드는 파일은 `.tsx`로, 기존 파일은 `.jsx`로 그대로 뒀다. 한 프로젝트에 `.jsx`와 `.tsx`가 섞여있는 게 보기 좋지는 않았지만, 현실적인 선택이었다.

3개월쯤 지나니까 새로 작성한 파일이 전체의 40% 정도가 됐다. 그즈음에 `strict: true`로 전환하고, 기존 JS 파일에서 나오는 에러를 하나씩 잡았다. 이때쯤이면 기존 코드에 대한 이해도가 높아져 있어서, 타입을 붙이는 과정에서 숨어있던 버그도 몇 개 발견했다.

## Redux는 아직도 남아있다

입사한 지 거의 2년이 다 되어가는 지금도 Redux 코드는 일부 남아있다. 유저 인증 관련 전역 상태가 Redux에 있는데, 이걸 Zustand로 옮기면 영향 범위가 앱 전체다. 로그인, 로그아웃, 토큰 갱신, 권한 체크. 다 연결되어 있다.

"언젠가 옮기겠지"라고 생각했는데, 사실 지금 잘 돌아가고 있다. 코드가 예쁘지 않아도 동작하는 코드를 리스크를 감수하면서까지 바꿀 이유가 있을까? 이 질문에 대한 답이 "아니"인 한, Redux는 그냥 둔다. 새로운 상태가 필요하면 Zustand를 쓰면 되니까.

그래서 지금 코드베이스는 혼종이다. TypeScript와 JavaScript가 섞여있고, 함수형 컴포넌트와 Class 컴포넌트가 공존하고, React Query와 Redux가 같이 돌아간다. 보기에 깔끔하지 않다. 하지만 돌아간다. 그리고 방향은 명확하다. 새로운 코드는 모두 TypeScript + 함수형 + React Query다.

## Strangler Fig 패턴

나중에 알게 된 건데, 우리가 한 방식에 이름이 있었다. Strangler Fig 패턴. 마틴 파울러가 이름 붙인 건데, 기존 시스템을 새 시스템으로 점진적으로 교체하는 방식이다. 무화과나무(fig)가 숙주 나무를 서서히 감싸면서 대체하는 것에서 따온 이름이라고 한다.

우리의 경우, 새로운 페이지를 만들 때는 완전히 새 스택으로 만들었다. 그리고 기존 페이지의 라우팅을 새 페이지로 하나씩 돌렸다. 사용자 입장에서는 변화를 느끼지 못한다. 내부적으로는 코드가 조금씩 새로운 것으로 교체되고 있을 뿐.

이 패턴이 좋은 건, 롤백이 쉽다는 거다. 새 페이지에서 문제가 생기면 라우팅만 원래대로 돌리면 된다. Big Bang 마이그레이션에서는 이게 안 된다. 전부 바꿨으니 전부 롤백해야 한다.

## 레거시의 맥락을 이해하기

레거시 코드를 볼 때 처음에는 "이걸 왜 이렇게 짰지?"라는 생각이 먼저 들었다. 근데 Git blame을 보면 이유가 나온다.

한 번은 이상하게 복잡한 날짜 처리 로직을 발견했다. 왜 이렇게 하드코딩을 했나 봤더니, 커밋 메시지에 "서버 타임존 이슈 핫픽스 — 아시아/서울 기준으로 강제 변환"이라고 적혀있었다. 그 커밋이 새벽 2시에 올라와 있었다. 프로덕션 장애 상황에서 급하게 고친 코드였다. 그 맥락을 알고 나니까, "이걸 왜 이렇게 짰지"가 "그때는 이렇게밖에 못 했겠구나"로 바뀌었다.

모든 레거시 코드에는 그때의 사정이 있다. 일정이 촉박했거나, 당시에는 더 나은 방법을 몰랐거나, 임시로 넣었는데 영구적이 되어버렸거나. 어떤 이유든 그 코드를 작성한 사람을 탓하는 건 의미가 없다. 중요한 건 지금부터 어떻게 개선할 것인가다.

## 완벽한 코드베이스는 없다

2년 가까이 일하면서 느낀 건, 완벽한 코드베이스란 존재하지 않는다는 거다. 아무리 깔끔하게 시작해도, 시간이 지나면 레거시가 된다. 지금 우리가 "새 기준"으로 작성하는 코드도 2년 뒤에 새로 온 개발자가 보면 "이걸 왜 이렇게 짰지?" 할 거다.

레거시는 제거해야 할 대상이 아니라, 같이 가야 할 동반자다. 어쩔 수 없이 공존해야 하는 거니까, 적어도 방향은 정해놓고 조금씩 나아가는 수밖에 없다. 그게 느리더라도.

가끔 처음 봤던 그 3,000줄짜리 전역 CSS 파일을 떠올린다. 지금은 1,200줄 정도로 줄었다. 나머지는 CSS Modules나 Tailwind로 이전됐다. 아직 1,200줄이 남았다는 게 찝찝하긴 한데, 처음보다는 나아졌고, 내일은 오늘보다 나을 거다. 아마도.


한 에세이스트가 이런 말을 했다. "사람들은 놀라움에서 배운다. 정답을 들었을 때가 아니라, 기대와 현실 사이에 간극이 생겼을 때 배운다." 커리어도 마찬가지인 것 같다. 돌아보면 내 커리어를 바꾼 건 거창한 결심이 아니라, 그 순간에는 별 의미 없어 보였던 작은 선택들이었다.

투자 세계에서 복리가 무서운 이유는 초기에는 거의 안 보이기 때문이다. 100만 원에 연 8%를 붙이면 1년 뒤에 108만 원이다. 별것 아니다. 그런데 20년 뒤에는 466만 원이 된다. 초반의 8만 원과 후반의 수십만 원은 같은 8%인데 결과가 완전히 다르다. 커리어에서의 작은 결정도 이 구조를 따른다. 당시에는 8만 원짜리 선택 같았는데, 몇 년이 지나고 보면 커리어의 방향 자체를 바꿔놓은 경우가 있다.

다섯 가지가 떠오른다.

## 1. Angular 대신 React를 고른 것

2020년에 처음 프론트엔드를 배울 때, 부트캠프 커리큘럼에는 Angular가 있었다. 국내 SI 업체에서 Angular를 많이 쓰니까 취업에 유리하다는 논리였다. 합리적인 이야기였다. 그런데 나는 React를 골랐다. 이유는 솔직히 별거 없었다. React 관련 한국어 자료가 더 많아서 독학하기 편할 것 같았다. 그게 전부다.

이 선택이 커리어에 미친 영향을 그때는 전혀 몰랐다. React 생태계가 폭발적으로 성장하면서 구직 시장에서의 수요가 완전히 달라졌다. Next.js, React Native, React Server Components로 생태계가 확장되면서 하나의 기술 선택이 접근할 수 있는 기회의 범위를 계속 넓혀줬다. 만약 Angular를 골랐다면 나쁜 커리어를 갖진 않았겠지만, 지금 내가 있는 자리에는 확실히 없었을 거다.

여기서 배운 게 있다. 기술 선택에서 "지금 당장의 취업률"보다 "생태계의 성장 방향"이 장기적으로 더 중요하다. 그런데 문제는 이걸 선택하는 시점에는 어느 쪽이 맞는지 알 수 없다는 거다. 나는 운이 좋았다. 다만 그 운을 만든 건 "자료가 많은 쪽을 고르자"라는 소박한 기준이었다. 학습 자원이 풍부한 기술은 커뮤니티가 활발하다는 뜻이고, 커뮤니티가 활발한 기술은 성장할 확률이 높다. 완벽한 논리는 아니지만, 꽤 쓸 만한 휴리스틱이다.

## 2. 아무도 안 하려던 프로젝트에 손을 든 것

입사 6개월쯤에 사내 어드민 페이지를 리뉴얼하는 프로젝트가 떨어졌다. 팀 미팅에서 "이거 누가 할래?"라고 물었을 때 아무도 손을 안 들었다. 어드민은 사용자가 사내 인원 20명뿐인 데다, 기술적으로 재미있는 게 없었다. CRUD의 반복이다. 테이블 보여주고, 필터 달고, 수정 폼 만들고. 화려한 것과는 거리가 멀었다.

3초 정도 침묵이 흐르고, 내가 "해볼게요"라고 했다. 특별한 의지가 있었던 건 아니다. 신입이니까 일을 가려서는 안 될 것 같다는 소박한 판단이었다.

그런데 이 프로젝트가 생각보다 많은 걸 가르쳐줬다. 어드민은 프로덕트 전체의 데이터 구조를 한눈에 볼 수 있는 창이었다. 유저 테이블, 주문 테이블, 결제 테이블이 어떻게 연결되는지, API가 어떤 구조로 응답을 주는지, 백엔드 개발자가 어떤 제약 조건 안에서 일하는지를 어드민을 만들면서 전부 배웠다. 고객용 프로덕트만 만들었으면 이 전체 그림을 이렇게 빨리 파악하지 못했을 거다.

그리고 하나 더. 어드민을 쓰는 운영팀 사람들과 직접 대화하면서 "사용자의 피드백을 바로 받는 경험"을 했다. "여기 이 버튼 위치 불편해요"라는 말을 듣고 다음 날 수정해서 배포하면 "오 바로 고쳐졌네요"라는 반응이 온다. 이 짧은 피드백 루프가 개발의 재미를 알려줬다. 사용자가 수십만 명인 프로덕트에서는 이런 직접적인 피드백을 받기 어렵다.

한 유명 에세이스트가 "확장되지 않는 일을 하라"고 쓴 적이 있다. 사용자 20명짜리 어드민은 확장과는 거리가 먼 일이었다. 그런데 거기서 배운 것들이 나중에 확장 가능한 프로덕트를 설계하는 데 직접적인 밑거름이 됐다.

## 3. 첫 블로그 글을 쓴 것

입사 1년쯤에 팀에서 겪은 API 에러 핸들링 삽질기를 블로그에 올렸다. "이걸 누가 읽겠어"라는 생각이었고, 실제로 처음 두 달은 아무도 안 읽었다. 조회수가 한 자릿수였다.

그런데 석 달쯤 지나서 검색 유입이 생기기 시작했다. 특정 에러 메시지로 검색하면 내 글이 나왔다. "axios interceptor에서 refresh token 처리할 때 무한 루프 해결" 같은, 아주 구체적인 문제를 겪고 있는 사람이 내 글에 도착하기 시작한 거다.

글을 하나 더 쓰고, 또 하나 더 쓰고, 반년이 지나자 열 개 정도가 쌓였다. 그때부터 뭔가가 달라졌다. 이직 준비를 할 때 면접관이 "블로그 글 몇 개 읽어봤는데"라는 말을 했다. 이력서에 "React 3년"이라고 적는 것과, 실제로 어떤 문제를 어떻게 풀었는지가 글로 남아있는 것은 전달력이 전혀 다르다.

복리 구조가 여기서도 작동한다. 글 하나하나는 별거 아닌데, 열 개가 쌓이면 "이 사람은 꾸준히 정리하는 습관이 있구나"라는 인상을 준다. 스무 개가 쌓이면 특정 주제에 대해 "이 블로그 한번 보세요"라고 추천받는 일이 생긴다. 글 하나의 가치가 선형이 아니라 지수적으로 올라간다. 초반에는 거의 0인데, 일정 임계점을 넘으면 급격히 올라간다.

처음 그 글을 쓸 때의 나는 이런 걸 전혀 예상하지 못했다. 그냥 삽질한 게 아까워서 적어둔 거였다.

## 4. 커피챗 요청을 수락한 것

어느 날 링크드인으로 메시지가 왔다. 다른 회사의 프론트엔드 개발자인데, 내 블로그 글을 읽고 궁금한 게 있어서 30분만 이야기할 수 있겠냐고. 처음에는 좀 귀찮았다. 모르는 사람이고, 퇴근 후 시간을 써야 하고, 특별히 내가 얻을 게 있을 것 같지도 않았다.

그래도 "뭐 30분이니까"라는 마음으로 수락했다.

그 30분이 꽤 유익했다. 다른 회사의 기술 스택, 팀 문화, 코드 리뷰 프로세스를 들었다. 우리 팀에서는 당연하게 쓰는 도구가 그 팀에서는 전혀 다른 것으로 대체되어 있었다. 시야가 넓어지는 느낌이었다. 상대방도 비슷하게 느꼈는지, 한 달 뒤에 또 연락이 왔고, 이번에는 세 명이서 만났다.

이게 반년 정도 이어지면서 느슨한 개발자 네트워크가 만들어졌다. 거창한 "커뮤니티"가 아니라, 가끔 기술 관련 질문을 주고받는 정도. 그런데 이 네트워크에서 이직 정보가 왔다. "우리 팀에서 프론트엔드 뽑는데, 관심 있으면 내가 추천해줄까?" 공개 채용 공고에 지원하는 것과 내부 추천을 받는 것은 서류 통과율이 전혀 다르다.

작은 결정의 복리가 여기서도 작동한다. 커피챗 한 번이 네트워크가 되고, 네트워크가 기회가 되고, 기회가 커리어의 분기점이 된다. 처음의 30분이 별것 아닌 것 같아도, 그 30분이 없었으면 그 이후의 모든 것도 없었다.

## 5. 클래스 컴포넌트 대신 함수형 컴포넌트를 일찍 선택한 것

이건 기술적인 이야기다. 2021년쯤, 팀에서 새 프로젝트를 시작할 때 함수형 컴포넌트와 Hooks를 기본으로 쓰자고 제안했다. 당시 팀의 기존 코드베이스는 대부분 클래스 컴포넌트였다. 시니어 한 분이 "검증된 패턴을 굳이 바꿀 필요가 있나"라고 했고, 다른 팀원도 비슷한 반응이었다.

나는 React 공식 문서에서 "새 프로젝트는 함수형 컴포넌트를 권장한다"는 문장을 근거로 밀었다. 새 프로젝트니까 기존 코드와의 호환성 문제도 없었다. 결국 "새 프로젝트만 함수형으로"라는 타협안이 나왔고, 그대로 진행했다.

이 선택이 가져온 변화는 생각보다 컸다. 함수형 컴포넌트에 익숙해지면서 커스텀 훅이라는 패턴을 자연스럽게 쓰게 됐다. 로직 재사용이 쉬워지니까 코드 구조가 깔끔해졌다. 팀원들도 한 명씩 함수형으로 넘어왔다. 6개월 뒤에는 "클래스 컴포넌트를 왜 썼지?"라는 분위기가 됐다.

그리고 React 18, 19에서 Concurrent Mode, Server Components 같은 새 기능이 나왔을 때, 이것들이 전부 함수형 컴포넌트 기반이었다. 클래스 컴포넌트로 된 코드베이스는 이 기능들을 쓰려면 먼저 마이그레이션을 해야 했다. 우리는 이미 함수형이었으니까 바로 적용할 수 있었다.

기술의 방향을 정확히 예측한 게 아니다. 공식 문서의 권장 사항을 따른 것뿐이다. 그런데 그 소박한 근거가 맞는 방향이었고, 일찍 움직인 덕에 나중에 전환 비용을 안 치를 수 있었다.

## 작은 선택이 큰 선택보다 중요한 이유

다섯 가지를 돌아보면 공통점이 있다. 전부 그 순간에는 "별거 아닌" 선택이었다는 거다. Angular vs React를 고를 때 한 달을 고민한 게 아니라 이틀 만에 정했다. 어드민 프로젝트에 손을 든 건 3초 만의 판단이었다. 블로그 글을 쓴 건 주말 오후의 충동이었다. 커피챗은 "뭐 30분이니까"였다. 함수형 컴포넌트 제안은 팀 미팅 중 10분짜리 논의였다.

큰 결정은 신중하게 하면서 작은 결정은 대충 넘기는 경우가 많다. 이직, 연봉 협상, 기술 스택 전환 같은 큰 결정에는 몇 주를 고민한다. 반면에 "이 프로젝트 해볼까 말까", "이 글 써볼까 말까", "이 사람 만나볼까 말까" 같은 건 감으로 정한다.

그런데 커리어의 방향을 실제로 바꾼 건 후자였다. 큰 결정은 이미 작은 결정들이 만들어놓은 경로 위에서 이루어진다. 이직 면접에서 좋은 결과를 얻은 건 블로그를 써왔기 때문이고, 블로그를 쓰기 시작한 건 어드민 프로젝트에서 삽질한 경험이 있었기 때문이고, 어드민 프로젝트를 맡은 건 아무도 안 하려던 일에 손을 들었기 때문이다.

작은 결정들이 서로를 강화하면서 복리처럼 쌓인다. 한 에세이스트가 쓴 것처럼, 초기의 노력은 하찮아 보여도 가파른 곡선의 시작점에 서 있는 거다. 그걸 당시에는 알 수 없다. 사후적으로만 보인다. 그래서 작은 선택을 할 때 너무 무겁게 생각할 필요는 없다. 대신 "일단 해보자" 쪽으로 약간의 편향을 두는 게 나쁘지 않다. 해본 결정은 복리의 재료가 되지만, 안 한 결정은 아무것도 남기지 않으니까.


작년 여름, 하루 종일 코딩했는데 커밋이 하나도 없는 날이 있었다.

뭘 했는지 되짚어봤다. 오전에 슬랙 메시지 5개 답하고, PR 리뷰 2개 하고, 스탠드업 참석하고, 점심 먹고 돌아와서 Jira 티켓 정리하고, 오후에 코드 좀 보다가 또 슬랙, 그러다 퇴근. 자리에 8시간 앉아 있었지만 코드에 진짜 집중한 시간은 40분도 안 됐을 것이다.

Cal Newport의 *Deep Work*을 읽은 건 그즈음이었다. "딥워크는 인지적으로 까다로운 작업에 방해 없이 집중하는 상태"라는 정의가 마음에 남았다. 근데 책을 읽고 나서도 한동안은 달라진 게 없었다. 이론을 안다고 집중이 되는 건 아니니까.

## 슬랙 알림 끄기는 반만 맞다

처음에 시도한 건 뻔한 것들이었다. 슬랙 알림 끄기, 핸드폰 뒤집어 놓기, 이어폰 쓰기. 일주일 정도는 효과가 있었다. 근데 알림을 꺼도 습관적으로 슬랙을 열게 된다. "혹시 뭐 놓친 거 있나?" 하는 불안감 때문에.

결국 깨달은 건, 문제가 환경이 아니라 내 머릿속에 있다는 거였다. 집중하려면 "지금 이 시간에는 슬랙에서 뭐가 오든 상관없다"는 확신이 필요한데, 그 확신은 팀과의 합의 없이는 생기지 않는다.

그래서 팀 리드한테 말했다. "오전 10시부터 12시까지는 슬랙 응답이 느릴 수 있는데 괜찮을까요?" 예상보다 쉽게 "당연하지"라는 답이 돌아왔다. 알고 보니 팀원 대부분이 비슷한 고민을 하고 있었다.

## 2시간이 한계다

딥워크 시간을 아침에 4시간 잡겠다고 큰소리쳤다가 3일 만에 포기했다. 4시간 연속 집중은 인간의 뇌가 할 수 있는 게 아니었다. 적어도 내 뇌는.

결국 2시간이 현실적인 한계라는 걸 인정했다. 오전 10시~12시. 이 2시간 동안 가장 인지적으로 어려운 작업 하나만 한다. 새 기능의 핵심 로직 설계, 복잡한 버그 디버깅, 아키텍처 리팩토링 같은 것들. PR 리뷰나 Jira 정리는 오후로 미룬다.

작아 보이지만 이 2시간이 하루 생산성의 80%를 만든다. 나머지 6시간은 미팅, 리뷰, 소통, 잡무에 써도 괜찮다. 2시간의 진짜 집중이 8시간의 분산된 노력보다 낫다.

## 시작이 제일 어렵다

집중 시간을 확보해도, 막상 그 시간이 되면 코드를 열기가 싫을 때가 있다. 뇌가 저항하는 거다. 복잡한 문제를 마주하면 본능적으로 쉬운 일로 도망치고 싶어진다. "일단 메일 확인만..." "이 PR 리뷰 먼저 빠르게..." 하다 보면 2시간이 사라진다.

내가 쓰는 트릭은 단순하다. **"5분만 하자."** 타이머를 5분 맞추고 시작한다. 5분 후에 정말 하기 싫으면 그만둬도 된다는 규칙이다. 근데 신기하게도, 5분이 지나면 이미 몰입해 있는 경우가 대부분이다. 시작의 마찰만 넘기면 된다.

뇌과학에서 말하는 "작업 흥분(task momentum)"이 이거다. 하기 싫어도 일단 시작하면 뇌가 그 작업에 맞춰 활성화된다. 의욕이 생겨서 시작하는 게 아니라, 시작하면 의욕이 생긴다.

## 환경 설계가 의지력보다 세다

의지력으로 집중하겠다는 건 매번 실패한다. 대신 환경을 설계한다.

내 딥워크 루틴은 이렇다.

1. 10시가 되면 슬랙 상태를 "집중 모드"로 바꾼다
2. 브라우저에서 슬랙, 메일 탭을 닫는다 (안 닫으면 무의식적으로 클릭한다)
3. VS Code를 전체 화면으로 띄운다
4. 노이즈 캔슬링 이어폰에 가사 없는 음악을 건다
5. 어제 퇴근 전에 적어둔 "내일 딥워크에서 할 일"을 본다

5번이 핵심이다. 딥워크 시간이 시작됐는데 "오늘 뭐 하지?"부터 고민하면 그것만으로 20분이 날아간다. 전날 퇴근 전에 다음 날 집중할 작업을 구체적으로 적어두면, 아침에 바로 시작할 수 있다. "장바구니 쿠폰 적용 로직에서 중복 할인 처리하는 부분 구현" 이 정도 구체성으로.

## 딥워크가 안 되는 날도 있다

솔직히 말하면 일주일에 5일 다 딥워크를 하지는 못한다. 월요일은 스프린트 플래닝으로 오전이 통째로 날아가고, 금요일은 회고가 있다. 컨디션이 안 좋은 날도 있고, 급한 장애 대응이 끼어드는 날도 있다.

일주일에 3일, 하루 2시간씩 확보하면 잘한 거다. 주 6시간의 딥워크. 이게 현실적인 목표다.

완벽하게 하려다가 아예 안 하게 되는 것보다, 가능한 날에만이라도 하는 게 낫다. 어떤 주는 2일밖에 못 할 수도 있다. 그래도 0일보다는 낫다.

---

딥워크에 대해 2년 동안 이것저것 시도해보고 남은 결론은 간단하다. 하루에 진짜 집중할 수 있는 시간은 생각보다 짧고, 그 짧은 시간을 지키는 게 생각보다 어렵다. 근데 그걸 지키는 사람과 안 지키는 사람의 아웃풋 차이는 생각보다 크다.



"디자인 패턴 공부해야 하나요?"

주니어 시절에 이 질문을 커뮤니티에 올렸다. 답변은 두 부류였다. "당연하죠, GoF 책은 필수입니다" vs "프론트엔드에서는 별로 안 씁니다." 나는 후자의 의견을 믿었다. GoF의 디자인 패턴 책을 펼쳐봤는데, 자바 코드에 UML 다이어그램에 AbstractFactory니 뭐니 하는 이름들이 나와서 10페이지 만에 덮었다. "이건 백엔드 얘기지, 나한테는 해당 안 되겠지."

2년이 지나서야 깨달았다. 나는 디자인 패턴을 매일 쓰고 있었다. 이름을 몰랐을 뿐.

Addy Osmani와 Lydia Hallie가 만든 patterns.dev에서 JavaScript와 React의 디자인 패턴을 정리한 걸 보고 나서 "아하" 순간이 왔다. 내가 매일 치는 코드에 이름이 붙어있었다.

## Observer 패턴: 이벤트 리스너

Observer 패턴의 정의를 보면 "어떤 이벤트가 발생하면 구독자에게 알린다"이다. 뭔가 학술적으로 들리지만, 프론트엔드 개발자가 첫 주에 배우는 게 바로 이거다.

```javascript
// 이게 Observer 패턴이다
button.addEventListener("click", handleClick);
window.addEventListener("resize", handleResize);
document.addEventListener("scroll", handleScroll);
```

`addEventListener`가 Observer 패턴의 구현이다. 버튼(Subject)에 클릭 이벤트가 발생하면, 등록된 핸들러(Observer)에게 알려준다. 여러 개의 핸들러를 등록할 수도 있고, 특정 핸들러만 제거(`removeEventListener`)할 수도 있다.

React에서는 이게 더 자연스럽게 녹아있다.

```tsx
// React의 상태 업데이트도 Observer 패턴이다
const [count, setCount] = useState(0);

// count가 바뀌면 이 컴포넌트와 하위 컴포넌트가 자동으로 리렌더링된다
// 상태(Subject)를 구독(Observe)하고 있는 UI가 변경을 감지하는 구조
```

`useState`로 상태를 만들면 React가 자동으로 그 상태를 구독한다. 상태가 바뀌면 관련 컴포넌트가 리렌더링된다. "상태 변경을 감지해서 UI를 업데이트한다" — 이게 Observer 패턴의 핵심 아이디어다.

더 명시적인 예시는 브라우저의 `IntersectionObserver`다.

```javascript
const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      loadImage(entry.target);
    }
  });
});

observer.observe(imageElement);
```

이름 자체에 Observer가 들어있다. 요소가 뷰포트에 진입하는 "이벤트"를 관찰(observe)하다가, 진입하면 콜백을 실행한다. 이미지 lazy loading을 만들 때 자연스럽게 쓰게 되는데, 이게 디자인 패턴이었다.

## Strategy 패턴: 함수를 인자로 넘기기

Strategy 패턴은 "알고리즘을 캡슐화하고 교체 가능하게 만든다"이다. 말이 어렵지만, JavaScript에서는 그냥 함수를 인자로 넘기는 거다.

```javascript
// 이게 Strategy 패턴이다
const numbers = [3, 1, 4, 1, 5, 9];

numbers.sort((a, b) => a - b); // 오름차순 전략
numbers.sort((a, b) => b - a); // 내림차순 전략
numbers.sort((a, b) => a.toString().localeCompare(b.toString())); // 문자열 비교 전략
```

`Array.sort()`에 비교 함수를 넘긴다. 정렬이라는 행위는 같은데, "어떻게 비교할 것인가"라는 전략을 바꿔 끼울 수 있다. 이게 Strategy 패턴이다.

React에서는 render props가 이 패턴의 대표적 구현이었다. Kent C. Dodds가 React 패턴을 설명할 때 composition을 강조하는 이유도 이거다.

```tsx
// 렌더링 전략을 외부에서 주입한다
function List({ items, renderItem }) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{renderItem(item)}</li>
      ))}
    </ul>
  );
}

// 사용하는 쪽에서 전략을 결정한다
<List items={users} renderItem={(user) => <UserCard user={user} />} />
<List items={products} renderItem={(product) => <ProductRow product={product} />} />
```

같은 `List` 컴포넌트인데, `renderItem`이라는 전략을 바꿔 끼우면 완전히 다른 UI가 된다. "렌더링 방법"이라는 알고리즘을 캡슐화하고 교체 가능하게 만든 거다. Strategy 패턴 그 자체다.

## Decorator 패턴: HOC

Decorator 패턴은 "기존 객체에 새로운 기능을 덧씌운다"이다. React에서 Higher-Order Component(HOC)가 정확히 이 역할을 한다.

```tsx
// Decorator 패턴: 컴포넌트에 인증 기능을 덧씌운다
function withAuth(WrappedComponent) {
  return function AuthenticatedComponent(props) {
    const { user, isLoading } = useAuth();

    if (isLoading) return <Spinner />;
    if (!user) return <Navigate to="/login" />;

    return <WrappedComponent {...props} user={user} />;
  };
}

// 원본 컴포넌트는 건드리지 않고 인증 기능이 추가된다
const ProtectedDashboard = withAuth(Dashboard);
const ProtectedSettings = withAuth(Settings);
```

`Dashboard` 컴포넌트 자체는 인증에 대해 아무것도 모른다. `withAuth`가 그 위에 인증 로직을 "장식(decorate)"한다. 원본을 수정하지 않고 기능을 추가하는 거다.

요즘은 HOC보다 커스텀 훅을 더 많이 쓰긴 한다. 근데 패턴의 본질은 같다.

```tsx
// 커스텀 훅도 Decorator적 사고방식이다
function useDashboard() {
  const { user } = useAuth();        // 인증 기능 장식
  const data = useFetchData(user.id); // 데이터 패칭 장식
  const analytics = useAnalytics();   // 분석 기능 장식

  return { user, data, analytics };
}
```

여러 기능을 하나씩 "장식"처럼 쌓아 올리는 구조. 각 훅은 독립적이고, 필요에 따라 추가하거나 제거할 수 있다.

## Mediator 패턴: 상태 관리 라이브러리

Mediator 패턴은 "컴포넌트들이 직접 통신하지 않고, 중앙의 중재자를 통해 통신한다"이다. patterns.dev에서도 이 패턴을 미들웨어 패턴과 연결지어 설명한다.

Redux가 Mediator 패턴의 교과서적 구현이다.

```
컴포넌트A ──dispatch──→ Store(Mediator) ──notify──→ 컴포넌트B
컴포넌트C ──dispatch──→ Store(Mediator) ──notify──→ 컴포넌트D
```

컴포넌트A가 컴포넌트B에게 직접 데이터를 전달하지 않는다. Store라는 중재자에게 액션을 보내면, Store가 상태를 업데이트하고, 해당 상태를 구독하는 모든 컴포넌트에게 알린다.

컴포넌트끼리 서로의 존재를 모르게 만드는 게 핵심이다. A는 B가 있는지 없는지 모른다. 그냥 Store에 액션을 보낼 뿐이다. 이 덕분에 컴포넌트를 자유롭게 추가하거나 제거할 수 있다.

```tsx
// 채팅 앱을 예로 들면
function ChatInput() {
  const dispatch = useDispatch();

  const sendMessage = (text) => {
    // 이 컴포넌트는 메시지가 어디에 표시되는지 모른다
    // 그냥 Store에 "메시지 보냈다"고 알릴 뿐
    dispatch({ type: "SEND_MESSAGE", payload: text });
  };

  return <input onSubmit={sendMessage} />;
}

function MessageList() {
  // 이 컴포넌트는 메시지가 어디서 오는지 모른다
  // 그냥 Store에서 메시지 목록을 가져올 뿐
  const messages = useSelector((state) => state.messages);

  return messages.map((msg) => <Message key={msg.id} text={msg.text} />);
}
```

`ChatInput`과 `MessageList`는 서로를 모른다. Store가 중재한다. 나중에 `NotificationBadge`라는 새 컴포넌트를 추가해도, 기존 코드는 한 줄도 안 고쳐도 된다. Store에서 메시지 개수를 구독하기만 하면 된다.

## Singleton 패턴: 전역 상태

Singleton 패턴은 "인스턴스가 하나만 존재하도록 보장한다"이다. JavaScript 모듈 시스템 자체가 Singleton이다.

```javascript
// config.js
// 이 모듈은 앱 전체에서 하나의 인스턴스만 존재한다
export const config = {
  apiUrl: process.env.API_URL,
  maxRetries: 3,
  timeout: 5000,
};
```

`import { config } from './config'`를 어디서 하든 같은 객체를 참조한다. 모듈이 처음 import될 때 한 번 평가되고, 이후에는 캐시된 결과를 반환한다. 별도의 Singleton 구현 없이도 JavaScript 모듈 시스템이 알아서 해준다.

React에서 Context도 비슷한 역할을 한다.

```tsx
// ThemeContext는 앱 전체에서 하나의 테마 상태를 공유한다
const ThemeContext = createContext("light");

function App() {
  return (
    <ThemeContext.Provider value="dark">
      {/* 어떤 하위 컴포넌트든 같은 테마 값을 참조한다 */}
      <Header />
      <Main />
      <Footer />
    </ThemeContext.Provider>
  );
}
```

Provider가 하나이고, 모든 하위 컴포넌트가 같은 값을 참조한다. "하나의 출처(Single Source of Truth)"라는 React의 철학 자체가 Singleton적 사고방식이다.

## Proxy 패턴: 접근 제어

patterns.dev에서 소개하는 Proxy 패턴은 "객체에 대한 접근을 가로채서 제어한다"이다. JavaScript의 `Proxy` 객체가 이름 그대로 이 패턴이다.

```javascript
const handler = {
  set(target, property, value) {
    if (property === "age" && typeof value !== "number") {
      throw new TypeError("나이는 숫자여야 합니다");
    }
    if (property === "age" && value < 0) {
      throw new RangeError("나이는 0 이상이어야 합니다");
    }
    target[property] = value;
    return true;
  },
};

const user = new Proxy({}, handler);
user.age = 25;  // 통과
user.age = -1;  // RangeError
user.age = "스물다섯"; // TypeError
```

이걸 매일 직접 쓰지는 않겠지만, 반응형 상태 관리 라이브러리들이 내부적으로 이걸 쓴다. MobX, Vue의 반응형 시스템이 Proxy 기반이다. 상태 변경을 "가로채서" 자동으로 리렌더링을 트리거하는 구조.

## "아하" 이후에 달라지는 것

디자인 패턴의 이름을 아는 것 자체가 코딩 실력을 올려주지는 않는다. 이미 쓰고 있었으니까. 근데 이름을 알면 달라지는 게 있다.

**1. 소통이 빨라진다.** "이거 Observer 패턴으로 하면 되겠네"라고 하면, 패턴을 아는 팀원은 즉시 구조가 머릿속에 그려진다. "이벤트를 발행하고 구독하는 구조로 만들어서, 새 기능을 추가할 때 기존 코드를 안 건드려도 되게..."라고 길게 설명할 필요가 없다.

**2. 설계 판단의 근거가 생긴다.** "여기는 Mediator 패턴을 쓰면 컴포넌트 간 의존성을 줄일 수 있다"는 말에는 근거가 있다. GoF 이후 수십 년간 검증된 패턴이다. "뭔가 중간에서 관리하는 걸 두면 좋을 것 같아요"보다 설득력 있다.

**3. 새로운 코드를 읽을 때 구조가 보인다.** 처음 보는 라이브러리의 소스 코드를 읽을 때, "아 이건 Observer 패턴이구나"하고 인식하면 코드의 흐름을 훨씬 빨리 파악할 수 있다. 패턴을 모르면 함수 하나하나를 따라가야 하지만, 패턴을 알면 큰 구조가 먼저 잡힌다.

## 디자인 패턴은 발명이 아니라 발견이다

내가 느끼기에 디자인 패턴의 본질은 이거다. 뛰어난 누군가가 "이렇게 코드를 짜라"고 발명한 게 아니다. 많은 개발자들이 비슷한 문제를 풀다 보니 비슷한 구조에 도달했고, 거기에 이름을 붙인 거다.

Kent C. Dodds가 React 패턴을 설명할 때도 비슷한 접근을 한다. 추상적인 패턴부터 시작하는 게 아니라, 실제 문제를 풀다 보면 자연스럽게 패턴이 나온다는 식이다.

그러니까 "디자인 패턴을 공부해야 하나요?"라는 질문에 대한 내 대답은 이렇다. 이미 쓰고 있는 것에 이름을 붙이는 과정이라고 생각하면 부담이 없다. GoF 책 처음부터 읽을 필요 없다. 내가 매일 짜는 코드에서 출발해서, "이거 혹시 패턴이 있나?" 하고 찾아보면 된다.

`addEventListener`를 쓰고 있다면 이미 Observer 패턴을 알고 있는 거다. `Array.sort()`에 비교 함수를 넘기고 있다면 이미 Strategy 패턴을 알고 있는 거다. 모르고 있었을 뿐, 몸은 이미 알고 있었다.

이름을 아는 순간, "아 이게 그거였어?" 하는 감탄이 온다. 그리고 그 감탄 이후에 코드를 보는 눈이 달라진다. 거창한 변화는 아닌데, 한번 보이면 계속 보인다. 어디서든.



회사에 입사하고 6개월 정도 지났을 때, 프로젝트 세 개를 동시에 운영하고 있었다. 어드민 패널, 유저 대시보드, 랜딩 페이지. 세 프로젝트 모두 React + TypeScript 기반인데, 버튼 스타일이 전부 달랐다. 같은 "확인" 버튼인데 어드민에서는 파란색 라운드, 대시보드에서는 초록색 사각, 랜딩에서는 그라데이션이었다.

디자이너분이 피그마에서 컴포넌트를 정리하면서 "버튼 스타일을 통일하면 좋겠다"고 했다. 팀 리드가 나를 보며 "디자인 시스템 한번 만들어볼래?"라고 했다. 가벼운 톤이었는데, 그게 몇 달짜리 여정이 될 줄은 몰랐다.

## 처음에는 큰 그림을 그렸다

솔직히 의욕이 넘쳤다. Material UI 같은 거 만들면 되는 거 아닌가. 토큰 시스템 설계하고, 테마 프로바이더 만들고, Storybook으로 문서화하고. 첫 주에 노션에 정리한 계획서가 A4 열 장 분량이었다. 컬러 토큰, 타이포그래피 스케일, 스페이싱 시스템, 브레이크포인트, 아이콘 시스템, 모션 가이드라인까지.

팀 리드가 계획서를 보더니 한마디 했다. "이거 다 하려면 전담 인원 두 명은 필요한데." 우리 팀은 프론트엔드 개발자가 나 포함 두 명이었다. 나머지 한 명은 시니어였는데 당시 대시보드 리뉴얼로 바빠서 손 쓸 여유가 없었다.

현실을 직시해야 했다. 디자인 시스템을 "제대로" 만들려면 팀 규모가 부족하다. 하지만 아무것도 안 하면 세 프로젝트의 UI 파편화는 계속 심해질 거였다.

## 버튼 하나에서 시작했다

시니어가 조언을 줬다. "일단 Button 하나만 만들어봐. 그것만으로도 꽤 많은 걸 배울 수 있어." 그래서 정말 버튼 하나부터 시작했다.

처음에 만든 Button 컴포넌트는 이랬다.

```tsx
interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost';
  size: 'sm' | 'md' | 'lg';
  children: React.ReactNode;
  onClick?: () => void;
  disabled?: boolean;
  loading?: boolean;
}

export function Button({
  variant = 'primary',
  size = 'md',
  children,
  onClick,
  disabled = false,
  loading = false,
}: ButtonProps) {
  return (
    <button
      className={cn(
        baseStyles,
        variantStyles[variant],
        sizeStyles[size],
        disabled && disabledStyles,
      )}
      onClick={onClick}
      disabled={disabled || loading}
    >
      {loading ? <Spinner size={size} /> : children}
    </button>
  );
}
```

심플하다. 근데 이 심플한 버튼 하나 만드는 데 일주일이 걸렸다. variant를 몇 개로 할지, size는 세 단계면 충분한지, loading 상태에서 버튼 너비가 변하면 안 되는 건 어떻게 처리할지. 디자이너분과 피그마 앞에 앉아서 하나하나 결정했다.

특히 고민했던 건 `as` prop이었다. 버튼인데 실제로는 `<a>` 태그여야 하는 경우가 있다. 링크처럼 생긴 버튼, 버튼처럼 생긴 링크. polymorphic component라는 개념을 이때 처음 알았는데, 타입 추론이 생각보다 까다로웠다.

```tsx
type ButtonProps<T extends React.ElementType = 'button'> = {
  as?: T;
  variant: 'primary' | 'secondary' | 'ghost';
  size: 'sm' | 'md' | 'lg';
} & Omit<React.ComponentPropsWithoutRef<T>, 'as' | 'variant' | 'size'>;
```

이 타입 하나 잡는 데 이틀을 썼다. TypeScript 제네릭이랑 `React.ComponentPropsWithoutRef`의 동작 방식을 제대로 이해하게 된 건 이때가 처음이었다.

## Input은 버튼보다 세 배는 복잡했다

Button 다음에 Input을 만들었다. 단순하게 생각하면 `<input>` 태그에 스타일 입히면 끝인데, 실제로는 그렇지 않았다.

라벨이 필요하다. 에러 메시지 영역이 필요하다. 헬퍼 텍스트가 있을 수도 있다. 왼쪽에 아이콘이 들어갈 수 있고, 오른쪽에 버튼이 들어갈 수도 있다. 비밀번호 필드면 show/hide 토글이 필요하다. disabled 상태, error 상태, focus 상태의 스타일이 전부 다르다.

```tsx
interface InputProps {
  label?: string;
  error?: string;
  helperText?: string;
  leftIcon?: React.ReactNode;
  rightElement?: React.ReactNode;
  // ... input 기본 props
}
```

여기서 가장 큰 실수를 했다. error prop으로 문자열을 받으면서 동시에 React Hook Form의 `register`를 spread하면 ref가 꼬이는 문제가 있었다. `forwardRef`를 빼먹은 거였다. 이거 때문에 프로덕션에서 폼 제출이 안 되는 버그가 생겼고, 핫픽스를 올렸다.

그때 깨달은 거다. 디자인 시스템 컴포넌트는 예쁘게 만드는 게 아니라, 다른 개발자가 실수 없이 쓸 수 있게 만드는 거라는 걸. 내가 유일한 사용자가 아니다. 시니어도 쓰고, 나중에 들어올 신규 입사자도 쓸 거다.

## Storybook은 도입했다가 반쪽짜리로 운영했다

컴포넌트를 몇 개 만들고 나서 Storybook을 붙였다. 문서화 없이 디자인 시스템을 운영하면 "이 컴포넌트 어떻게 쓰는 거야?" 질문이 매일 올 게 뻔했으니까.

근데 Storybook 관리가 은근히 손이 많이 간다. 컴포넌트를 수정할 때마다 스토리도 같이 업데이트해야 한다. 처음에는 성실하게 했다. Controls 패널도 달고, 각 variant별로 스토리를 분리하고, 사용 예시도 적었다. 한 달 정도 지나니까 슬슬 밀리기 시작했다. 새로운 prop을 추가하면서 스토리는 안 고치는 일이 생기고, 그러면 문서와 실제 컴포넌트가 안 맞는 상태가 되고.

결국 "최소한 각 컴포넌트의 기본 스토리는 항상 최신 상태로 유지하자"는 규칙만 남겼다. 완벽한 문서화는 포기했다. 현실적으로 우리 팀 규모에서는 그게 최선이었다.

## 토큰 시스템은 세 번 갈아엎었다

컬러 토큰을 정의하는 과정이 생각보다 험난했다.

첫 번째 시도는 그냥 색상 이름이었다. `blue-500`, `gray-100` 같은 식. Tailwind에서 영감을 받았는데, 문제는 "이 파란색이 Primary인지 Info인지 Link인지" 의미를 모른다는 거였다.

두 번째 시도는 시맨틱 토큰만 쓰는 거였다. `color-primary`, `color-error`, `color-background`. 의미는 명확한데, 실제 개발할 때 "이 텍스트는 좀 연한 회색이어야 하는데 토큰이 없네?"라는 상황이 계속 생겼다.

세 번째 시도에서 두 레이어를 합쳤다.

```ts
// Primitive tokens - 실제 색상값
const colors = {
  blue: { 50: '#eff6ff', 100: '#dbeafe', /* ... */ 600: '#2563eb' },
  gray: { 50: '#f9fafb', 100: '#f3f4f6', /* ... */ 900: '#111827' },
};

// Semantic tokens - 의미 기반
const semantic = {
  primary: colors.blue[600],
  'primary-hover': colors.blue[700],
  background: colors.gray[50],
  'text-primary': colors.gray[900],
  'text-secondary': colors.gray[600],
  error: colors.red[500],
  border: colors.gray[200],
};
```

이 구조가 되고 나서야 디자이너분과 대화가 수월해졌다. "이 텍스트 색상은 text-secondary로 하면 될 것 같아요"라고 하면 바로 통했다.

## 모노레포는 안 했다

인터넷 아티클을 보면 디자인 시스템은 모노레포로 별도 패키지를 만들라고 한다. Turborepo나 Nx 써서 packages/design-system으로 분리하고, npm에 퍼블리시하고. 맞는 말이다. 이상적으로는.

우리는 그냥 대시보드 프로젝트의 `src/components/ui` 폴더에 때려넣었다. 다른 프로젝트에서 필요하면 파일을 복사했다. 더럽다는 거 안다. 하지만 세 프로젝트 간에 디자인 시스템 패키지를 관리하는 오버헤드가, 파일 복사의 불편함보다 컸다. 우리 팀 사이즈에서는.

나중에 프로젝트가 더 늘어나면 그때 패키지로 분리해도 된다고 판단했다. 실제로 이후에 프로젝트가 다섯 개로 늘었을 때 시니어가 "이제 패키지로 빼자"고 했고, 그때서야 Turborepo를 도입했다. 타이밍이 맞았다.

## 6개월 후

Button, Input, Select, Modal, Toast, Badge, Tag, Tooltip. 8개의 기본 컴포넌트가 만들어졌다. 화려하지 않다. Material UI나 Chakra에 비하면 초라하다. 근데 우리 서비스에 필요한 건 다 있었다.

가장 큰 변화는 개발 속도였다. 새 페이지를 만들 때 버튼 스타일 고민하는 시간이 사라졌다. "여기는 primary md로 넣으면 돼"라고 말하면 끝이었다. 디자이너분도 피그마에서 같은 토큰 이름을 쓰기 시작하면서, 디자인 핸드오프가 훨씬 깔끔해졌다.

실패한 것도 있다. 너무 일찍 추상화한 컴포넌트가 몇 개 있었다. Select를 처음에 Headless UI 스타일로 만들었는데, 써보니까 우리 유스케이스의 90%는 단순 드롭다운이어서 인터페이스가 과하게 복잡했다. 다시 심플하게 고쳤다.

작은 팀에서 디자인 시스템을 만들 수 있냐고 묻는다면, 만들 수 있다. 근데 "디자인 시스템"이라는 거창한 이름보다는, "우리 팀에서 반복되는 UI 패턴을 정리한 것"에 가까운 형태로. 스케일은 팀이 커질 때 같이 키우면 된다.

요즘은 가끔 다른 회사 디자인 시스템 문서를 구경한다. 토스의 TDS나 라인의 컴포넌트 시스템 같은 거. 보면서 "우리도 언젠가 이 정도까지 가려면 뭐가 필요할까" 생각하는데, 그 답은 아직 잘 모르겠다. 아마 팀이 커지면 자연스럽게 필요해지는 것들이겠지. 그때 가서 또 고민하면 되는 거다.


화요일 오전, 슬랙에 메시지를 하나 보냈다. "결제 쪽 API 바뀐 거 같은데 확인 부탁드려요." 백엔드 팀의 담당자가 두 시간 뒤에 답했다. "어떤 API 말씀이세요?" 내가 다시 답했다. "주문 생성 API요. 응답 구조가 달라진 것 같아서." 또 한 시간 뒤에 답이 왔다. "주문 생성 API는 변경된 적 없는데요. 혹시 스테이징에서 테스트하신 건가요?" 그때서야 깨달았다. 내가 로컬에서 테스트한 건데, 환경 변수가 잘못 설정돼서 다른 서버를 가리키고 있었다. API는 바뀐 적이 없었다.

이 에피소드에서 내가 낭비한 시간: 30분. 상대방이 낭비한 시간: 1시간(메시지 확인, 코드 히스토리 확인, 답변 작성). 그리고 그 사이에 둘 다 컨텍스트 스위칭 비용을 치렀다. 총 비용을 따지면 반나절이다. 원인은 하나다. 내가 보낸 첫 메시지에 정보가 부족했다.

이건 시작에 불과했다.

## 2일을 날린 슬랙 메시지

더 큰 사건은 3개월 뒤에 터졌다. 프론트엔드에서 새 기능을 개발하고 있었는데, 디자이너가 슬랙에 이렇게 올렸다. "이 화면 인터랙션 좀 바꿔야 할 것 같아요." 그 메시지 아래에 피그마 링크가 하나 있었다.

나는 피그마를 열어봤다. 기존 디자인과 달라진 부분이 있었다. 모달 안의 버튼 위치가 바뀌어 있었고, 새로운 상태(로딩 중)가 추가되어 있었다. "아, 디자인이 업데이트됐구나"라고 판단하고, 그에 맞춰 코드를 수정하기 시작했다. 버튼 위치를 바꾸고, 로딩 상태를 추가하고, 관련 테스트도 업데이트했다. 하루가 걸렸다.

다음 날 디자이너한테 확인을 받으려고 했더니, 그 디자이너가 당황했다. "아, 그건 아직 확정된 게 아니에요. 검토 중인 시안이었는데... '바꿔야 할 것 같다'는 건 의견을 물어본 거였어요."

하루 치 작업을 롤백했다. 개발 시간 하루, 롤백 시간 반나절, 그리고 디자이너와의 후속 미팅 1시간. 총 2일을 날렸다.

원인을 분석하면 양쪽 다 문제가 있었다. 디자이너는 "의견 요청"인지 "작업 요청"인지를 명확히 하지 않았다. 나는 확인 없이 바로 작업을 시작했다. 근데 더 근본적인 문제는, **우리 팀에 커뮤니케이션 프로토콜이 없었다**는 거다.

이 사건 이후 팀에서 간단한 규칙을 만들었다. 슬랙 메시지 앞에 태그를 붙이기로. `[의견요청]` `[작업요청]` `[공유]` `[긴급]`. 이 네 글자 태그 하나가, 수신자가 메시지를 어떻게 처리해야 하는지를 즉시 알려준다. 사소해 보이지만 효과는 컸다. 2달 뒤에 비슷한 종류의 오해가 눈에 띄게 줄었다.

## 제대로 된 버그 리포트의 힘

QA 팀에서 버그 리포트가 올라온다. "결제 화면에서 오류가 발생합니다."

이걸로 뭘 할 수 있을까? 아무것도 못 한다. 어떤 브라우저? 어떤 디바이스? 어떤 계정? 어떤 상품? 어떤 결제 수단? 오류 메시지가 뭐였는지? 재현 경로가 어떻게 되는지? 콘솔에 에러가 찍혔는지? 네트워크 탭에서 뭐가 보이는지?

정보가 하나도 없으니까, 나는 질문을 하기 시작한다. 한 번에 다 물어보면 좋겠지만, 보통 하나 물어보면 답이 오고, 그 답을 보고 다시 물어보게 된다. 이 핑퐁이 3-4번 반복되면 반나절이 지나간다. 그사이에 다른 작업을 하다가 돌아오다가를 반복하니까 집중력도 깨진다.

반대 경험도 있다. 같은 QA 팀에서 다른 사람이 올린 버그 리포트는 이랬다:

> **제목**: 결제 화면 - 신용카드 결제 시 "결제 처리 중" 상태에서 무한 로딩
>
> **환경**: Chrome 121 / macOS Sonoma / 프로덕션
>
> **재현 경로**:
> 1. 상품 A (상품 ID: 12345)를 장바구니에 추가
> 2. 결제 진행
> 3. 결제 수단: 신용카드 선택
> 4. 카드 정보 입력 후 "결제하기" 클릭
> 5. "결제 처리 중" 스피너가 표시되고 이후 변화 없음
>
> **예상 동작**: 결제 완료 후 주문 완료 페이지로 이동
> **실제 동작**: 스피너가 무한히 표시됨 (5분 이상 대기해도 변화 없음)
>
> **콘솔 로그**: `Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'orderId')` (스크린샷 첨부)
>
> **네트워크**: POST /api/payments 응답 200이지만 response body가 비어 있음 (스크린샷 첨부)
>
> **재현율**: 100% (3회 테스트)

이 리포트를 받으면 바로 원인을 찾으러 갈 수 있다. 네트워크 탭 스크린샷에서 API 응답이 비어 있다는 정보가 핵심이었다. 백엔드 쪽을 확인해보니 결제 게이트웨이와의 연동에서 응답 파싱이 누락된 부분이 있었다. 리포트부터 수정 완료까지 2시간. 첫 번째 리포트 방식이었으면 최소 하루가 걸렸을 거다.

## 기술 제안서(RFC)를 쓰는 법

시니어가 되면서 가장 많이 하는 일 중 하나가 기술 제안서를 쓰는 거다. 새로운 아키텍처를 제안하거나, 기술 부채를 해결하는 방안을 내놓거나, 새 도구를 도입하자고 설득하거나. 이걸 잘하느냐 못하느냐가 실제로 영향력에 큰 차이를 만든다.

처음에 기술 제안서를 쓸 때 실수했던 건, **결론부터 말하지 않은 것**이다. 장황하게 배경을 설명하고, 현재 상황의 문제점을 나열하고, 대안을 비교하고, 마지막에 "따라서 X를 도입하자"로 끝나는 구조. 20분 읽어야 결론을 알 수 있는 문서. 바쁜 사람(특히 리드, CTO)은 그 20분을 참지 못한다. 처음 2분에서 핵심을 파악하지 못하면 닫아버린다.

지금은 이런 구조로 쓴다:

```
# 제안 요약
"X를 도입하자. 현재 Y 문제가 있고, X가 이걸 해결한다.
예상 비용은 2주, 예상 효과는 Z."

# 문제
[현재 무엇이 문제인가. 가능하면 숫자로.]

# 제안
[구체적으로 무엇을 하자는 건가.]

# 대안
[다른 선택지는 뭐가 있고, 왜 이 제안이 더 나은가.]

# 리스크
[이 제안의 단점과 리스크는 뭔가. 솔직하게.]

# 실행 계획
[구체적으로 어떤 단계로 진행하는가.]
```

핵심은 첫 세 줄이다. 의사결정자가 첫 세 줄만 읽고도 "이건 추진할 가치가 있겠다" 또는 "이건 지금 타이밍이 아니다"를 판단할 수 있어야 한다. 나머지는 궁금한 사람이 더 읽는 거다.

또 하나 중요한 건 **리스크 섹션**이다. 제안서에 리스크를 솔직하게 쓰면 오히려 신뢰도가 올라간다. "이 방법은 완벽하다"는 제안은 의심을 산다. "이 방법에는 A, B 리스크가 있지만, A는 이렇게 완화할 수 있고, B는 발생 확률이 낮다"는 제안이 훨씬 설득력 있다.

## "모르겠다"의 힘

개발자 커리어에서 가장 강력한 말 중 하나가 "모르겠다"이다.

주니어 시절엔 이 말이 무능하게 들릴까 봐 무서웠다. 회의에서 "이 방법이 맞을까요?" 하고 물어보면, 확신이 없어도 "네, 괜찮을 것 같아요"라고 대답했다. 아는 척하는 게 안전하다고 생각했다.

시니어가 되면서 깨달은 건, 아는 척이 가장 위험하다는 거다.

한번은 아키텍처 미팅에서 데이터베이스 선택에 대한 논의가 있었다. 나는 프론트엔드가 주 분야라 백엔드 인프라에 깊은 지식이 없었다. 근데 미팅 분위기상 의견을 내야 할 것 같아서, 얕은 지식으로 "MongoDB가 스키마 유연성 측면에서 좋을 것 같다"고 말했다. 나중에 알고 보니, 우리 서비스의 데이터 특성상 관계형 DB가 훨씬 적합했다. 내 의견이 크게 반영된 건 아니었지만, 잘못된 방향으로 논의를 끌고 간 건 사실이었다.

그 이후로 모르는 건 "모르겠다"고 말하기 시작했다. 근데 그냥 "모르겠다"가 아니라, 이런 식이다:

"이 부분은 내 전문 영역이 아니라서 정확하게 판단하기 어렵다. 근데 내가 아는 범위에서 말하면, A 측면은 이렇게 보인다. B 측면은 해당 분야 전문가한테 확인이 필요할 것 같다."

이렇게 말하면 두 가지 좋은 일이 벌어진다. 첫째, 내가 아는 부분과 모르는 부분의 경계가 명확해져서, 논의가 더 정확한 방향으로 간다. 둘째, 팀에서 나의 의견에 대한 신뢰도가 오히려 올라간다. 내가 "이건 확실하다"고 말할 때, 진짜 확실하다는 걸 다들 알게 되니까.

Gergely Orosz(The Pragmatic Engineer 저자)가 여러 차례 강조한 내용이 있다. 시니어 엔지니어를 구별하는 건 코드 실력이 아니라 커뮤니케이션이라는 거다. 같은 수준의 기술력을 가진 두 엔지니어가 있을 때, 자기 생각을 명확하게 전달하고, 다른 사람의 의견을 정확히 이해하고, 복잡한 기술적 결정의 맥락을 문서로 남기고, "모르는 걸 안다"고 솔직하게 말하는 사람이 시니어가 된다. 코드만 잘 짜는 사람은 시니어까지는 갈 수 있지만, 그 이상은 어렵다.

## 비동기 커뮤니케이션의 기술

원격 근무가 늘면서 비동기 커뮤니케이션의 중요성이 커졌다. 슬랙 메시지, PR 코멘트, 문서 — 전부 비동기다. 이건 대면 대화와 근본적으로 다른 규칙이 적용된다.

**대면**: 말이 애매해도, 상대방 표정을 보면서 즉시 보충 설명을 할 수 있다. "아 그게 아니라..."가 가능하다.

**비동기**: 한 번 보낸 메시지가 전부다. 상대방이 읽는 시점에 나는 다른 작업을 하고 있다. 애매한 부분이 있으면 상대방은 혼자 해석해야 한다. 그 해석이 내 의도와 다르면 핑퐁이 시작된다.

그래서 비동기 메시지에는 **과할 정도로 맥락을 넣어야** 한다.

나쁜 예: "이거 수정해주세요."
좋은 예: "결제 화면(payment/checkout.tsx)의 쿠폰 적용 로직에서, 할인 금액이 원가보다 큰 경우 음수가 되는 케이스가 있습니다. 결제 금액이 음수가 되지 않도록 `Math.max(0, discountedPrice)` 같은 가드가 필요합니다. 관련 이슈: #234"

두 번째 메시지가 길지만, 이 한 번의 메시지로 끝난다. 첫 번째 메시지는 최소 3번의 핑퐁이 필요하다.

## 회의에서의 커뮤니케이션

개발자들이 회의를 싫어하는 이유 중 하나는, 대부분의 회의가 비효율적이기 때문이다. 근데 회의 자체가 나쁜 게 아니라, 커뮤니케이션 방식이 나쁜 거다.

Gergely Orosz가 "Talk First, Code Later"라는 제목의 글에서 말한 것처럼, 복잡한 기술적 결정은 코드를 짜기 전에 이야기를 먼저 해야 한다. 근데 그 이야기가 생산적이려면 구조가 필요하다.

기술 논의 회의에서 내가 쓰는 패턴은 이렇다:

**시작 전**: 논의할 내용을 미리 문서로 공유한다. 회의에서 처음 설명하면 시간이 낭비된다. 읽어오지 않은 사람이 있으면? "5분 드릴 테니 읽고 시작합시다"가 "30분 동안 설명하겠습니다"보다 낫다.

**논의 중**: "이건 어떻게 생각해요?"보다 "이 두 가지 중 어떤 게 나은 것 같아요?"가 생산적이다. 열린 질문은 논의를 확산시키고, 닫힌 질문은 논의를 수렴시킨다. 확산이 필요한 단계가 있고, 수렴이 필요한 단계가 있다.

**끝나기 전**: "오늘 결정된 것"과 "다음에 할 것"을 명확히 정리한다. "다들 알겠죠?"로 끝나면, 다음 회의에서 "지난번에 뭐라고 결론 났었죠?"가 나온다.

## 커뮤니케이션은 기술이다

"나는 코딩은 잘하는데 커뮤니케이션이 부족해"라는 말을 종종 듣는다. 이 말에는 "커뮤니케이션은 타고나는 것"이라는 전제가 깔려 있다. 근데 커뮤니케이션은 코딩과 똑같이 **배울 수 있는 기술**이다.

처음부터 좋은 버그 리포트를 쓰는 사람은 없다. 처음부터 명확한 기술 제안서를 쓰는 사람도 없다. 처음부터 회의를 잘 진행하는 사람도 없다. 다 연습과 피드백으로 좋아지는 거다. React의 state 관리를 배우듯이, 명확한 메시지 작성법도 배울 수 있다. TypeScript의 타입 시스템을 익히듯이, 기술 제안서의 구조도 익힐 수 있다.

차이가 있다면, 코딩 실력은 혼자서도 올릴 수 있지만, 커뮤니케이션 실력은 상대방이 있어야 올라간다는 거다. 그래서 더 의도적인 연습이 필요하다. 슬랙 메시지를 보내기 전에 "이 메시지를 받는 사람이 필요한 맥락이 다 있나?" 3초만 생각해보는 것. PR 코멘트를 달기 전에 "이 코멘트가 상대방한테 어떻게 읽힐까?" 잠깐 생각해보는 것. 이런 작은 습관이 쌓이면, 1년 뒤에는 확연히 다르다.

코드는 결국 사람이 읽는다. 그리고 코드 이전에, 사람과 사람 사이에 오가는 메시지가 있다. 그 메시지의 품질이 코드의 품질을 결정한다.


입사 초기에 팀 리드가 PR 리뷰에서 "이 부분은 React 공식 문서의 useEffect 섹션 읽어보면 좋을 것 같아"라고 코멘트를 남겼다. 링크를 열었다. 영어였다. 한국어 번역 페이지로 전환하려고 했는데, 번역이 아직 안 된 섹션이었다.

그때의 나는 영어 문서를 보면 반사적으로 뒤로 가기를 눌렀다. 영어를 못 하는 건 아닌데, 기술 문서를 영어로 읽으면 속도가 한국어의 3분의 1로 떨어졌다. 그래서 늘 한국어 블로그 글이나 번역본을 먼저 찾았다. 한국어 자료가 없으면 그냥 넘어가는 경우도 있었다.

이게 한계가 되기 시작한 건 입사 3개월 차쯤이었다.

## 에러 메시지가 영어인 건 어쩔 수 없다

개발하면서 매일 마주치는 건 에러 메시지다. 그리고 에러 메시지는 전부 영어다.

```
TypeError: Cannot read properties of undefined (reading 'map')
```

이 정도는 괜찮다. 근데 이런 게 나오면 당황했다.

```
Hydration failed because the initial UI does not match what was rendered on the server.
```

Next.js hydration 에러. 처음 봤을 때는 "hydration이 뭐고 initial UI가 뭐지" 싶었다. 각 단어는 아는데 문장이 무슨 뜻인지 바로 와닿지 않았다. 지금은 보자마자 "서버에서 렌더링한 HTML이랑 클라이언트에서 렌더링한 결과가 다르다는 거구나"라고 이해하는데, 이건 영어 실력이 늘어서라기보다는 해당 개념을 반복해서 접했기 때문이다.

개발 영어의 핵심은 이거다. 단어 자체의 뜻보다 그 단어가 기술적으로 무엇을 의미하는지를 아는 것. `property`는 "속성"이 아니라 객체의 프로퍼티다. `render`는 "표현하다"가 아니라 컴포넌트를 DOM에 그리는 것이다. `hydrate`은 사전적으로 "수분을 공급하다"인데, 프론트엔드에서는 서버에서 보낸 정적 HTML에 이벤트 리스너를 붙이는 과정이다.

이런 용어들은 영어 공부를 해서 늘는 게 아니라, 개발 공부를 하면서 자연스럽게 쌓인다.

## 공식 문서는 사실 읽기 쉬운 편이다

이상하게 들릴 수 있는데, 기술 공식 문서는 영어 원서 중에서 쉬운 축에 속한다. 문학적 표현이 없다. 비유가 거의 없다. 문장 구조가 단순하다. 그리고 코드 예시가 많다.

React 문서를 예로 들면 이런 식이다.

> `useEffect` is a React Hook that lets you synchronize a component with an external system.

주어(`useEffect`) + 동사(`lets you`) + 목적(`synchronize a component with an external system`). 문장 구조가 뻔하다. 여기에 코드 예시가 바로 따라오기 때문에, 영어를 다 이해 못 해도 코드를 보면 감이 온다.

내가 영어 문서 읽는 습관을 들인 방법은 단순했다. 브라우저 번역 기능을 옆에 두고, 먼저 영어로 읽어보고, 모르는 부분만 번역을 확인하는 식이었다. 처음에는 문장마다 번역을 확인했는데, 한 달쯤 지나니까 단락 단위로 확인하게 됐고, 석 달쯤 되니까 번역을 거의 안 봤다. 특히 MDN 같은 사이트는 문서 구조가 일정해서, 몇 번 읽다 보면 패턴이 보인다. Syntax, Parameters, Return value, Examples. 이 순서로 되어있으니 영어를 다 읽지 않아도 필요한 정보를 빨리 찾을 수 있다.

## Stack Overflow에서 질문하기

영어 읽기가 좀 되기 시작하면 Stack Overflow에서 질문하는 것도 어렵지 않다. 사실 Stack Overflow 질문에는 특유의 템플릿이 있다.

```
I'm trying to [목표].
I expected [기대 결과].
But I'm getting [실제 결과].
Here's my code: [코드 블록]
I've already tried: [시도한 것들]
Environment: [환경 정보]
```

이 패턴만 알면 된다. 문법이 좀 틀려도 상관없다. Stack Overflow에서 중요한 건 문제를 명확하게 설명하는 거지, 영어를 잘 쓰는 게 아니다. 실제로 비영어권 개발자들이 쓴 질문을 보면 문법은 엉망인데 문제 설명이 명확해서 답변이 잘 달리는 경우가 많다.

내가 처음 Stack Overflow에 질문을 올린 건 Next.js에서 dynamic import 할 때 타입 에러가 나는 문제였다. 한 시간 동안 영어로 질문을 작성했다. 지금 보면 되게 어색한 영어인데, 코드 블록이랑 에러 메시지를 정확히 붙여넣었더니 30분 만에 답변이 달렸다. 그때 느꼈다. 영어를 잘 하는 게 아니라, 문제를 잘 설명하면 된다는 걸.

## GitHub Issue와 PR 코멘트

회사에서 오픈소스 라이브러리에 이슈를 올리거나, 외부 라이브러리의 PR을 리뷰할 일은 많지 않다. 하지만 가끔 있다. 우리가 쓰는 라이브러리에서 버그를 발견했을 때, GitHub Issue를 올려야 하는데, 이것도 패턴이 있다.

```markdown
## Description
Brief description of the issue.

## Steps to Reproduce
1. Do this
2. Then this
3. See error

## Expected Behavior
What should happen.

## Actual Behavior
What actually happens.

## Environment
- Library version: x.x.x
- Browser: Chrome 120
- OS: macOS
```

이 템플릿을 따라서 쓰면 된다. 나는 라이브러리 이슈 두 번 올려봤는데, 두 번 다 메인테이너가 답장을 줬다. 문법 지적은 한 번도 없었다. 재현 가능한 버그 리포트를 올리면 고맙다고 한다.

## 불필요한 영어에 대해서

여기서 하고 싶은 말은 "개발자니까 영어를 잘해야 한다"가 아니다. 오히려 반대다. 개발자에게 필요한 영어는 생각보다 범위가 좁다.

영어 회화? 외국계 회사가 아니면 거의 안 쓴다. 영작? 이메일 쓸 일이 있어도 지금은 번역 도구가 워낙 좋아서 큰 문제가 안 된다. TOEIC 점수? 개발자 채용에서 영어 점수를 보는 곳은 거의 없다.

필요한 건 딱 세 가지다.

1. 기술 문서를 영어로 읽을 수 있는 능력
2. 에러 메시지와 로그를 해석할 수 있는 능력
3. 기술적 문제를 영어로 검색하고, 필요하면 간단히 질문할 수 있는 능력

이 세 가지는 의식적으로 공부하지 않아도, 개발을 하면서 영어 자료를 피하지 않으면 자연스럽게 늘어난다. "영어 공부를 해야지"라고 압박을 받을 필요 없이, 그냥 한국어 자료를 찾기 전에 영어 자료를 먼저 한번 열어보는 습관만 들이면 된다.

## 커밋 메시지와 변수명

영어가 개발에서 필요한 또 다른 영역이 있다. 커밋 메시지와 변수명이다.

입사 초기에 커밋 메시지를 한국어로 쓸지 영어로 쓸지 고민했다. 우리 팀은 영어로 쓰는 컨벤션이었다. `feat: add user profile page`, `fix: resolve infinite loop in useEffect`. 이런 식. 처음에는 커밋 메시지 하나 쓰는 데도 구글 번역기를 켰는데, 커밋 메시지에 쓰이는 영어 패턴이 한정적이어서 금방 익숙해졌다. add, update, fix, remove, refactor. 이 다섯 개 동사면 대부분의 커밋 메시지를 쓸 수 있다.

변수명도 마찬가지다. `isLoading`, `handleSubmit`, `fetchUserData`, `formatDate`. 프로그래밍에서 쓰는 영어 단어는 일상 영어보다 범위가 훨씬 좁다. 자주 쓰는 패턴을 익히면 된다. `is`로 시작하면 불리언, `handle`로 시작하면 이벤트 핸들러, `fetch`로 시작하면 API 호출. 네이밍 규칙 자체가 일종의 문법이다.

가끔 변수명이 안 떠오를 때는 다른 오픈소스 프로젝트에서 비슷한 기능을 어떻게 이름 지었는지 본다. GitHub에서 검색하면 대부분 나온다. 남이 쓴 좋은 이름을 참고하는 건 부끄러운 게 아니다.

## 요즘 드는 생각

입사 2년 차인 지금은 영어 문서를 읽는 게 자연스러워졌다. React 문서, MDN, TypeScript Handbook 같은 건 영어로 읽는 게 더 편하다. 한국어 번역이 원문의 뉘앙스를 놓치는 경우가 종종 있어서.

다만 최근에 느끼는 건, 영어 리스닝 능력이다. 해외 컨퍼런스 영상을 자막 없이 보려면 아직 버겁다. React Conf나 Next.js Conf 같은 거 볼 때 자막을 켜야 편한데, 자막 없이도 알아들을 수 있으면 좋겠다는 생각은 가끔 한다. 근데 이건 솔직히 "있으면 좋고 없어도 되는" 영역이라, 따로 시간을 들여서 공부하고 싶진 않다.

개발자 영어는 거창한 게 아니다. 에러 메시지 보고 당황하지 않고, 공식 문서 링크 받았을 때 뒤로 가기 안 누르는 정도면 충분하다고 생각한다. 나머지는 시간이 해결해준다.


작년 가을, 오른쪽 어깨부터 팔꿈치까지 뻐근한 느낌이 2주째 안 사라졌다. 처음에는 잠을 잘못 잔 줄 알았다. 베개를 바꿔봤다. 안 나았다. 스트레칭을 좀 해봤다. 여전했다. 그러다 어느 날 아침에 고개를 왼쪽으로 돌리는데 목에서 "뚝" 소리가 나면서 통증이 확 왔다. 그 길로 정형외과에 갔다.

X-ray를 찍었다. 의사가 모니터에 목뼈 사진을 띄워놓고 말했다. "목디스크 초기예요. 경추 5-6번 사이 디스크가 좀 튀어나왔네요." 입사한 지 1년 됐을 때였다. 스물다섯 살이었다.

## 어떻게 이렇게 된 건지

돌이켜보면 원인은 뻔하다.

하루에 10시간 이상 모니터를 봤다. 회사에서 8시간, 집에서 2~3시간 더. 퇴근하고 사이드 프로젝트 하거나 기술 블로그 글 읽으면서 또 컴퓨터 앞에 앉았다. 주말에도 마찬가지였다.

자세가 나빴다. 모니터를 내려다보는 자세로 코딩했다. 노트북을 데스크 위에 그냥 올려놓고, 외장 키보드 없이 노트북 키보드를 썼다. 거북목이 심해지는 건 당연했다. 회사 의자가 나름 좋은 건데, 등받이에 기대는 법이 없었다. 항상 상체를 앞으로 숙이고 모니터에 얼굴을 들이밀었다.

운동은 안 했다. "운동해야지"라고 매주 생각했고 매주 안 했다. 대학교 때까지는 가끔 풋살을 했는데, 입사하고 나서는 퇴근하면 지쳐서 아무것도 하기 싫었다.

## 정형외과에서 들은 말

의사가 말했다. "이 나이에 이 정도면, 2~3년 뒤에는 많이 심해질 수 있어요. 지금부터 관리 안 하면." 물리치료를 2주간 받았다. 전기 치료, 도수치료. 도수치료 받을 때 목 뒤쪽을 누르는데 진짜 아팠다. 근육이 딱딱하게 굳어있었다.

물리치료사가 모니터 높이를 물어봤다. "눈높이보다 낮죠?" 맞았다. "모니터를 눈높이에 맞추세요. 그리고 의자 높이를 조절해서 팔꿈치가 90도가 되게 하세요." 기본적인 인체공학 세팅인데, 그전까지 한 번도 신경 쓴 적 없었다.

## 바꾼 것들

병원 다녀온 후에 바꾼 것들을 정리해보면 이렇다.

**모니터 세팅**. 회사에 27인치 외장 모니터가 있었는데, 모니터 암에 연결해서 눈높이에 맞췄다. 노트북은 서브 모니터로 쓰고, 외장 키보드와 마우스를 연결했다. 이것만으로도 자세가 크게 달라졌다. 모니터를 올려다보지도, 내려다보지도 않고, 정면을 바라보게 됐다.

집에서도 노트북 거치대를 샀다. MOFT 접이식 거치대인데, 1만 원대에 꽤 괜찮다. 외장 키보드는 회사에서 쓰던 것과 같은 모델을 하나 더 샀다.

**스탠딩 데스크**. 회사에 전동 스탠딩 데스크가 있길래 신청했다. 처음에는 하루 종일 서서 일하려고 했는데, 30분 만에 다리가 아파서 포기했다. 지금은 앉았다 서기를 반복한다. 대략 50분 앉아있다가 10분 서있는 식. 타이머를 맞춰놓는다. 맥에 `Stretchly`라는 앱을 깔았는데, 시간마다 알림을 줘서 괜찮다.

**스트레칭**. 물리치료사가 알려준 목 스트레칭을 하루에 세 번 한다. 아침, 점심 후, 퇴근 전.

목을 왼쪽으로 천천히 기울이고 10초, 오른쪽으로 10초. 고개를 앞으로 숙이고 10초, 뒤로 젖히고 10초. 그리고 어깨를 으쓱 올렸다가 탁 떨어뜨리는 걸 10번. 전부 해도 2분도 안 걸린다. 근데 이 2분이 은근히 차이가 난다. 안 하면 오후 4시쯤 목이 뻣뻣해지는데, 하면 그게 확실히 덜하다.

**손목**. 손목은 아직 큰 문제가 없는데, 예방 차원에서 손목 받침대를 쓴다. 그리고 마우스를 버티컬 마우스로 바꿨다. 로지텍 MX Vertical. 처음에는 어색했는데 일주일이면 적응된다. 손목이 비틀리지 않는 각도로 잡게 되어있어서, 장시간 사용해도 손목에 무리가 덜 간다.

**눈**. 20-20-20 규칙이라는 게 있다. 20분마다 20피트(약 6미터) 떨어진 곳을 20초간 바라보기. 솔직히 이걸 정확히 지키지는 못한다. 근데 의식적으로 가끔 창밖을 보려고 한다. 모니터만 빤히 보다가 먼 곳을 보면 눈의 피로가 확 풀리는 게 느껴진다.

모니터 밝기도 조절했다. 이전에는 밝기를 거의 최대로 놓고 썼는데, 주변 조명에 맞게 낮췄다. macOS의 True Tone 기능도 켜놓았다.

## 허리

목 다음으로 걱정되는 건 허리다. 목디스크 진단받고 나서 자세를 의식하기 시작했는데, 의식하지 않으면 금세 원래대로 돌아간다. 특히 집중해서 코딩할 때. 버그를 추적하다 보면 어느새 상체가 앞으로 기울어져 있고, 등이 구부러져 있다.

허리를 위해서 한 건 의자 세팅이다. 회사 의자가 허먼밀러 에어론이었는데 (이직 때 이것 때문에 회사를 고른 건 아니지만, 솔직히 체크리스트에 있긴 했다), 이 의자도 제대로 세팅 안 하면 소용없다. 등받이 텐션, 좌석 깊이, 팔걸이 높이를 전부 조절했다. 유튜브에 "에어론 세팅법"이라고 검색하면 영상이 많다.

집 의자는 그렇게 좋은 게 아니어서, 허리 쿠션을 하나 붙여서 쓴다. 완벽하지는 않은데 없는 것보다 낫다.

## 운동

정형외과 진단을 받고 나서야 운동을 시작했다. 처음에 피트니스 센터를 등록했는데, 한 달 다니고 안 갔다. 퇴근 후에 헬스장까지 가는 게 너무 귀찮았다. 동기부여가 부족했다.

그 다음에 시도한 건 클라이밍이었다. 동기가 같이 가자고 해서 따라갔는데, 이건 꽤 재미있었다. 문제를 푸는 느낌이 있어서 개발자한테 맞는다고들 하는데, 실제로 그런 면이 있다. 루트를 관찰하고, 어떤 순서로 올라갈지 계획을 세우고, 실행하고. 성공하면 성취감이 있다. 일주일에 두 번 정도 간다.

클라이밍을 시작하고 나서 어깨와 등 근육이 확실히 좋아졌다. 코어 힘도 생기니까 앉아있는 자세도 덜 무너진다. 의사도 6개월 뒤 경과 관찰에서 "많이 좋아졌다"고 했다.

한 가지 팁이 있다면, 운동은 재미있어야 지속된다. 건강을 위해 억지로 하는 운동은 오래 못 간다. 헬스장이 안 맞으면 클라이밍이든 수영이든 배드민턴이든, 일단 재미있는 걸 찾는 게 우선이다. 나는 클라이밍이 맞았고, 동료는 크로스핏이 맞았고, 다른 동료는 아침 조깅이 맞았다. 정답은 없다. 그냥 꾸준히 할 수 있는 거면 된다.

출퇴근 때 한 정거장 먼저 내려서 걷는 것도 효과가 있다. 사소하지만, 하루에 20분 걷기가 추가된다. 점심시간에 회사 주변을 한 바퀴 도는 것도 좋다. 밥 먹고 바로 자리에 앉으면 졸리기도 하고.

## 동료들의 건강

주변을 보면 비슷한 사람이 많다. 같은 팀 동료는 손목터널증후군으로 부목을 차고 출근한 적이 있다. 다른 팀 개발자는 허리디스크로 서서 일했다. 시니어는 안구건조증이 심해서 모니터를 15분 이상 못 보고 눈을 감아야 한다.

다들 젊다. 이십대 후반에서 삼십대 초반. 근데 몸은 이미 경고를 보내고 있다. 문제는 개발이라는 직업 자체가 몸을 혹사하는 구조라는 거다. 앉아서, 모니터를 보면서, 손가락만 움직이는 일을 하루에 8시간 이상. 인간의 몸은 이런 식으로 쓰도록 설계되지 않았다.

## 습관이 되기까지

솔직히 말하면, 위에 적은 것들을 매일 빠짐없이 지키지는 못한다. 바쁜 날에는 스트레칭을 까먹고, 마감이 다가오면 스탠딩 데스크를 올리는 것도 잊어버린다. 20-20-20 규칙은 집중하고 있을 때 지키기가 특히 어렵다. 코드에 몰입하면 2시간이 훌쩍 지나있을 때가 있다.

그래도 정형외과 다녀오기 전에 비하면 많이 나아졌다. 완벽하지 않아도, 의식하는 것과 안 하는 것의 차이는 크다. 모니터 높이 하나 맞추는 것만으로도 목의 부담이 확 줄었고, 클라이밍을 시작하면서 전체적인 체력이 올라갔다.

최근에는 물 마시는 양도 신경 쓰고 있다. 개발하다 보면 물 마시는 걸 까먹는다. 커피만 마시고 물은 안 마시는 날이 있었다. 탈수는 집중력 저하의 원인 중 하나라고 하는데, 실제로 물을 충분히 마신 날과 안 마신 날의 오후 컨디션이 다르다. 책상 위에 큰 물병을 놔두고, 하루에 최소 1리터는 마시려고 한다.

개발자로 오래 일하고 싶으면 건강 관리는 선택이 아니라 필수다. 이걸 스물다섯에 목디스크로 깨달은 건 일찍 깨달은 편인지 늦게 깨달은 편인지 모르겠다. 다만 지금 이 글을 읽으면서 "나는 괜찮겠지"라고 생각하는 사람이 있다면, 나도 그랬다고만 말해두고 싶다.


개발자는 다른 직군에 비해 연봉이 높은 편이다. 그래서인지 돈 관리를 소홀히 하는 경우가 많다. "어차피 잘 버니까 괜찮겠지"라는 생각. 나도 그랬다. 월급이 들어오면 쓰고, 남으면 저축하고, 투자는 언젠가 하겠지 하고 미루고 있었다.

그러다 Morgan Housel의 "돈의 심리학"을 읽고 생각이 바뀌었다.

## 연봉은 소득이지 자산이 아니다

Housel의 핵심 메시지 중 하나는 "부를 만드는 건 소득이 아니라 저축률"이라는 것이다. 연봉 1억을 벌어도 9천만 원을 쓰면 남는 건 천만 원이다. 연봉 6천만 원을 벌고 3천만 원을 쓰면 남는 건 3천만 원이다.

개발자는 소득이 높으니까 소비도 늘어나기 쉽다. 좋은 장비, 자기계발 비용, 외식 — 하나하나는 합리적이지만 전체 합산하면 놀랍다. 가계부를 처음 써봤을 때 한 달 지출을 보고 놀랐다. "이만큼 쓰고 있었나?"

## 처음 시작한 것들

**비상금 확보.** 6개월 치 생활비를 현금성 자산으로 확보했다. 개발자 시장이 좋다고 해도, 이직 기간이 생기거나 예상치 못한 일이 생길 수 있다. 비상금이 있으면 급한 마음에 잘못된 선택을 안 하게 된다.

**인덱스 펀드.** 개별 종목을 고르는 건 나한테 맞지 않았다. 시장을 이기려면 전문가도 어려운데, 코딩하면서 주식 차트를 보는 건 비효율적이다. S&P 500이나 코스피 200 같은 시장 전체를 추종하는 인덱스 펀드에 매월 자동이체를 걸었다. 타이밍을 잡으려는 유혹을 줄이려고 자동화한 거다.

**연금.** 개인연금을 시작했다. 세액공제도 되고, 복리 효과가 20~30년 쌓이면 크다. "은퇴는 한참 뒤인데"라고 생각했지만, 한참 뒤이기 때문에 일찍 시작하는 게 유리하다.

## 개발자에게 유리한 점

개발자의 사고방식은 돈 관리와 잘 맞는다.

**데이터 기반 의사결정.** 감으로 투자하는 대신, 수익률 데이터, 수수료 구조, 세금 효과를 비교한다. 스프레드시트로 시뮬레이션하는 게 자연스럽다. 30년간 연 7% 복리 vs 연 5% 복리의 차이를 직접 계산해보면 수수료 0.5%의 무게를 체감한다.

**자동화.** 자동이체, 자동 리밸런싱, 세금 최적화를 시스템으로 만든다. 매달 고민할 필요 없이 한 번 설정해두면 돌아간다. 코드로 자동화하듯이 돈도 자동화할 수 있다.

**장기적 사고.** 좋은 코드는 미래의 유지보수를 고려한다. 돈도 마찬가지다. 지금의 소비가 미래의 선택지를 얼마나 좁히는지 생각하게 됐다.

## 달라진 생각

돈 공부를 시작한 뒤로 연봉 협상을 다르게 본다. 예전에는 "연봉 얼마"에만 집중했는데, 이제는 스톡옵션의 행사 조건, 퇴직연금 회사 부담금, 자기계발 비용 지원 같은 것도 본다. 전체 보상 패키지를 볼 수 있게 됐다.

이직할 때도 달라졌다. "연봉 500만 원 더 주는 곳" vs "연봉은 비슷하지만 성장 가능성이 높은 곳". 예전에는 당장의 숫자를 좇았는데, 5년 뒤의 시장 가치를 생각하면 판단이 달라진다.

가장 큰 변화는 "충분한" 기준이 생긴 거다. 이전에는 "많을수록 좋다"였는데, 지금은 "이 정도면 내가 원하는 삶을 살 수 있다"는 숫자를 알고 있다. 그 숫자를 알면 쓸데없는 비교와 욕심에서 자유로워진다.

돈은 목적이 아니라 도구다. 좋은 도구를 잘 다루면 선택의 자유가 생긴다. 억지로 싫은 일을 하지 않아도 되는 자유, 하고 싶은 일을 시도해볼 수 있는 자유. 개발자에게 돈 공부는 기술 공부만큼이나 커리어에 도움이 된다.



"퍼스널 브랜딩"이라는 단어를 들으면 반사적으로 거부감이 드는 개발자가 많을 거다. 나도 그랬다. 개발자가 무슨 인플루언서도 아니고, 코드나 잘 치면 되지. 브랜딩이라니. 링크드인에 "passionate about..."을 적으라는 건가. 아니면 트위터에서 매일 "오늘의 TIL" 스레드를 올리라는 건가.

그런데 이 거부감의 원인을 곰곰이 생각해보면, "브랜딩"이라는 단어 자체의 문제다. 브랜딩은 의도적으로 이미지를 설계하고 관리하는 뉘앙스가 있다. 마케팅 용어니까 당연하다. 개발자에게 이걸 적용하면 어색해진다. "나라는 상품을 포지셔닝합니다"라니 오글거리지 않을 수 없다.

그래서 이 글에서는 "브랜딩"이라는 단어를 안 쓰려고 한다. 대신 "찾아지는 사람"이라는 프레임으로 이야기하려고 한다. 본질은 같지만 접근 방식이 전혀 다르다.

## 3년 전에 나를 도운 그 사람

한번 떠올려보면 좋겠다. 지난 1~2년 동안 개발하면서 막혔던 순간들. 특정 에러 메시지를 구글에 치면 나오는 블로그 글. Stack Overflow에서 정확히 내 상황에 맞는 답변을 달아준 사람. GitHub 이슈에서 "나도 같은 문제 겪었는데 이렇게 해결했어요"라고 댓글을 남긴 사람.

그 사람들의 이름을 기억하는가? 아마 대부분 기억하지 못할 거다. 그런데 중요한 건, 그 사람들이 의도적으로 "브랜딩"을 한 게 아니라는 거다. 그들은 그냥 자기가 겪은 문제와 해결 과정을 어딘가에 적어둔 거다. 그게 검색에 걸려서 누군가에게 도움이 됐다.

이게 "찾아지는 사람"의 본질이다. 소셜 미디어 전략이 아니다. 도움이 되는 빵 부스러기를 인터넷에 남기는 거다.

한 개발자가 "Learn in Public"이라는 개념을 정리한 적이 있다. 핵심은 이거다. 학습의 배기가스를 공개적으로 남겨라. 블로그를 쓰든, 튜토리얼을 만들든, Stack Overflow에 답변을 달든, 형태는 상관없다. 중요한 건 닫힌 공간(슬랙, 디스코드, 노션)이 아니라 열린 공간에 남기는 거다. 그래야 검색에 잡힌다. 검색에 잡혀야 누군가에게 도달한다.

그리고 그 글에서 가장 인상적이었던 부분은 이거다. 이 모든 것의 첫 번째 수혜자는 다른 사람이 아니라 3개월 뒤의 자기 자신이라는 것.

## 이력서와 블로그의 간극

이직을 준비할 때 이걸 뼈저리게 느꼈다. 이력서에는 "React 기반 프론트엔드 개발 3년"이라고 적혀 있다. 같은 포지션에 지원하는 수십 명도 비슷한 이력서를 낸다. "Next.js 경험", "TypeScript 사용", "성능 최적화 경험". 채용 담당자 입장에서 이 사람들이 전부 비슷하게 보인다.

이때 차이를 만드는 게 "찾아지는 흔적"이다. 블로그에 "Next.js App Router 마이그레이션 중 겪은 캐싱 이슈와 해결 과정"이라는 글이 있으면, 이력서에 "Next.js 경험"이라고 적는 것과는 전달력이 완전히 다르다. 면접관이 "블로그 글 읽어봤는데, 캐싱 문제 해결한 과정이 인상적이었어요"라고 말하는 순간, 서류 더미 속의 이력서가 구체적인 사람으로 바뀐다.

이건 "브랜딩"이 아니다. 자기가 겪은 걸 적어둔 것뿐이다. 근데 그 기록이 나를 "찾아지는 사람"으로 만들어준다.

## 도움의 빵 부스러기

"찾아지는 사람"이 되는 가장 자연스러운 방법은 자기가 해결한 문제를 기록하는 거다.

구체적일수록 좋다. "React 성능 최적화"라는 제목보다 "React.memo를 useMemo로 교체했더니 리렌더링이 300ms에서 50ms로 줄어든 과정"이 검색에 훨씬 잘 잡힌다. 왜냐하면 실제로 그 문제를 겪고 있는 사람은 "React 성능 최적화" 같은 일반적인 키워드가 아니라, 아주 구체적인 상황을 검색하기 때문이다.

"이 정도 내용을 글로 쓸 가치가 있나?"라는 생각이 드는 글이 오히려 가치가 높은 경우가 많다. 너무 기초적인 것 같아서 망설여지는 주제. 근데 누군가에게는 딱 그 기초적인 설명이 필요한 시점이 있다. 그리고 기초적인 내용을 정확하게 설명하는 것도 실력이다.

한 개발자 교육자의 철학이 이거다. "다른 사람이 웹을 더 잘 만들 수 있도록 돕다 보면, 가시성은 자연스럽게 따라온다." 자기 PR을 하려고 글을 쓰는 게 아니라, 도움이 되는 글을 쓰다 보면 결과적으로 "찾아지는 사람"이 된다는 거다. 순서가 반대다. 가시성이 목표가 되면 어색해지고, 도움이 목표가 되면 자연스러워진다.

## 사내에서 "찾아지는 사람"

"찾아지는 사람"이 반드시 외부 활동을 해야 하는 건 아니다. 사내에서도 같은 논리가 적용된다.

회사 노션이나 위키에 기술 문서를 꾸준히 남기는 사람이 있다. 트러블슈팅 과정, 기술 선택의 배경, 삽질 기록. 처음에는 아무도 안 읽는 것 같다. 그런데 3개월쯤 지나면 다른 팀에서 "혹시 이 문서 쓰신 분이에요?"라고 물어오는 일이 생긴다. 비슷한 문제를 겪다가 검색으로 찾은 거다.

이게 사내에서 "찾아지는 사람"이 되는 과정이다. "이 문제는 그 사람한테 물어봐"라는 말을 듣기 시작하면, 그게 사내에서의 "찾아지는 사람"이다.

장점이 있다. 외부 블로그와 달리 피드백 루프가 빠르다. 동료가 바로 읽고 코멘트를 준다. "이 부분 설명 좋았는데, 실제로는 좀 다른 것 같아"라는 피드백이 오면 글쓰기 실력도 느는 거다. 그리고 사내 문서를 꾸준히 쓴 사람은 팀 내 기술적 의사결정에서 발언권이 자연스럽게 높아진다. 문서로 근거를 남겨온 사람의 말에는 무게가 실린다.

## 80%의 개발자는 보이지 않는다

한 가지 구조적인 사실이 있다. 개발자의 대다수는 온라인에서 보이지 않는다. 블로그를 안 쓰고, SNS에 기술 글을 안 올리고, 오픈소스에 기여하지 않는다. 조용히 일하고 조용히 퇴근한다.

이건 나쁜 게 아니다. 대부분의 개발자에게 합리적인 선택이다. 글쓰기는 에너지가 들고, SNS는 피곤하고, 오픈소스 기여는 시간이 없다. 충분히 이해한다.

다만, 이 구조에서 파생되는 현상이 있다. 조금이라도 보이는 사람이 실제 실력 대비 과대평가되는 경향이 있다. 80%가 안 보이니까, 20% 안에만 들어가도 상대적으로 눈에 띈다. 블로그 글 다섯 개만 있어도 "이 사람은 정리하는 습관이 있구나"라는 인상을 준다. 글이 0개인 사람과 5개인 사람의 실력 차이는 크지 않을 수 있는데, 인식의 차이는 크다.

이걸 "불공평하다"고 볼 수도 있고, "활용할 수 있는 구조"라고 볼 수도 있다. 나는 후자 쪽이다. 특별히 뛰어나지 않아도, 기록하고 공유하는 것만으로 "찾아지는 사람"이 될 수 있다면 그건 꽤 효율적인 투자다.

## 과잉 포장의 문제

반대로 너무 적극적으로 "보이려는" 사람의 문제도 짚어야 한다.

SNS에서는 대단해 보이는데 실제로 같이 일해보면 기대에 못 미치는 경우. 이건 "찾아지는 사람"이 아니라 "포장하는 사람"이다. 포장과 실체 사이의 간극이 생기면, 그 간극이 신뢰를 깎는다. 한 번 깎인 신뢰는 복구하기 어렵다.

"찾아지는 사람"의 핵심은 솔직함이다. 성공한 경험만 쓰지 않는다. 실패한 시도, 잘못된 판단, 아직 모르는 것도 적는다. "이 접근으로 해봤는데 안 됐다. 그래서 다른 방법을 찾았다." 이런 글이 "최적의 방법은 이것이다"라는 글보다 오히려 더 신뢰를 준다. 실제 업무에서 문제를 푸는 과정이 깔끔한 경우는 거의 없으니까. 삽질 과정이 드러나는 글이 현실적이고, 현실적인 글이 도움이 된다.

틀릴 수도 있다는 걸 인정하는 것도 중요하다. "이렇게 했는데, 더 좋은 방법이 있으면 알려주세요"라는 한 줄을 추가하는 것만으로도 글의 톤이 달라진다. 완벽한 전문가의 강의가 아니라, 같이 배우는 동료의 공유가 된다.

## 꾸준함이 깊이를 이기는 영역

이건 흥미로운 점인데, "찾아지는 사람"의 세계에서는 한 편의 대작보다 열 편의 짧은 기록이 더 효과적이다.

팀에서 1년 넘게 매주 짧은 TIL(Today I Learned)을 올리는 동료가 있다. 글 하나하나는 500자 정도, 대단한 깊이는 아니다. 근데 1년치가 쌓이니까 그 사람의 프로필에 들어가면 "꾸준하다"는 인상을 먼저 받게 된다. 한 달에 한 편씩 대작을 쓰는 것보다, 매주 작은 기록을 남기는 게 "찾아지는 사람"으로서는 더 효과적이다.

이유가 있다. 검색 유입은 글의 수에 비례한다. 한 편의 완벽한 글은 한 가지 키워드로만 검색에 잡힌다. 열 편의 짧은 글은 열 가지 키워드로 검색에 잡힌다. 진입점이 열 배다. 그리고 방문자가 하나의 글을 읽고 다른 글도 클릭할 확률은 글의 수가 많을수록 올라간다. 양이 질을 만드는 구조다.

이건 "대충 쓰라"는 뜻이 아니다. "완벽하게 쓰려다가 아예 안 쓰는 것보다, 적당히 쓰고 발행하는 게 낫다"는 뜻이다. 완벽한 글 0편과 괜찮은 글 10편 사이의 선택이다.

## 작은 시작

큰 전략이 필요한 게 아니다.

오늘 업무 중에 겪은 에러 하나를 해결했으면, 그 과정을 어딘가에 적어두는 거다. 사내 위키든, 개인 블로그든, 노션이든 상관없다. 형식도 중요하지 않다. "문제: OO 에러 발생. 원인: OO. 해결: OO." 이 세 줄이면 된다.

이걸 한 달에 두세 번만 해도 반년이면 열다섯 개가 쌓인다. 열다섯 개의 에러 해결 기록이 있는 사람과 0개인 사람. 실력 차이가 아니라 기록 차이인데, 외부에서 보이는 인상은 꽤 다르다.

그리고 한 가지 더. 글을 쓸 때 검색 유입을 약간만 신경 쓰면 도달 범위가 달라진다. "React 성능 최적화"보다 "React 리스트 렌더링에서 key를 index로 쓰면 안 되는 이유"가 검색에 잘 잡힌다. 사람들이 실제로 검색하는 건 포괄적인 주제가 아니라 구체적인 문제 상황이니까. 제목에 에러 메시지나 구체적인 상황을 넣으면 같은 문제를 겪고 있는 사람이 도달할 확률이 높아진다.

"브랜딩"이라고 하면 거창해지고 부담스러워진다. 소셜 미디어 전략, 콘텐츠 캘린더, 타겟 오디언스. 이런 건 다 필요 없다. 내가 겪은 문제와 해결을 열린 공간에 남기는 거다. 그게 검색에 잡히고, 누군가에게 도움이 되고, 그 누군가가 나를 기억한다. 이 흐름이 충분히 반복되면, 어느 순간 "찾아지는 사람"이 되어 있다.

그 3년 전에 Stack Overflow에서 나를 도운 사람처럼. 그 사람은 아마 자기가 나를 도왔다는 사실도 모를 거다. 의도하지 않았는데 도움이 된 거다. 그게 "찾아지는 사람"의 가장 좋은 형태라고 생각한다. 의도적으로 보이려는 게 아니라, 도움이 되는 흔적을 남기다 보니 자연스럽게 보이게 되는 것.


어느 날 깨달았다. 최근 3개월 동안 새로 배운 게 뭐지?

생각이 안 났다. 매일 코드를 치고 있는데, 새로운 게 없었다. 이미 알고 있는 패턴으로 이미 해봤던 종류의 작업을 반복하고 있었다. 리스트 페이지, 상세 페이지, 폼 페이지. 유사한 컴포넌트를 만들고, 비슷한 API를 연동하고, 같은 방식으로 상태를 관리한다. 손이 먼저 움직여서 코드가 나오는 건 좋은 건데, 머리를 안 쓰게 된다는 뜻이기도 하다.

처음 이 느낌이 들었을 때는 나만 이런 줄 알았다. 다른 사람들은 매일 새로운 걸 배우면서 즐겁게 일하고 있는 것 같았다. SNS에서 "오늘 배운 것" 시리즈를 올리는 사람들을 보면 부러웠다. 나는 오늘 배운 게 뭐지? 잘 모르겠는데.

## 정체기라는 걸 인지하기까지

처음에는 정체기인 줄도 몰랐다. 바빴으니까. 매일 티켓을 처리하고, PR을 올리고, 리뷰를 하면서 하루가 갔다. 일은 하고 있으니까 성장하고 있다고 착각했다. 근데 "바쁜 것"과 "성장하는 것"은 다른 문제다.

이걸 인지하게 된 건 채용 공고를 보다가였다. 다른 회사 프론트엔드 시니어 공고에 적힌 요구사항을 읽었는데, 내가 자신 있게 "할 수 있다"고 말할 수 있는 항목이 1년 전과 똑같았다. 1년 동안 실무를 했는데 역량이 제자리라는 느낌. 그게 무서웠다.

주변 동료들도 비슷한 시기를 겪는 것 같았다. 동기 한 명이 "요즘 재미없다"고 했을 때, 나도 같은 생각이었다. 재미가 없다기보다, 도전이 없다는 느낌. 안전지대 안에서 편하게 일하고 있는 건데, 그게 장기적으로 좋은 건지 의문이 들었다.

## 첫 번째 시도: 새로운 기술 공부하기

정체기를 느끼면 보통 처음 하는 게 "뭔가 새로운 걸 공부하자"다. 나도 그랬다. Rust를 시작해봤다. 프론트엔드와는 전혀 다른 세계라서 새로운 자극이 될 거라고 생각했다.

2주 정도 열심히 했다. ownership 개념이 신선했고, 컴파일러가 에러를 잡아주는 게 인상적이었다. 근데 3주차쯤에 포기했다. 실무에서 쓸 일이 없으니까 동기 부여가 유지되지 않았다. 퇴근하고 집에 와서 피곤한데 "당장 쓸 데 없는 걸" 공부하는 게 점점 힘들어졌다.

이 경험에서 배운 건, 새로운 기술을 공부하는 것 자체는 정체기의 해결책이 아니라는 거다. 기술이 아니라 "문제"가 새로워야 한다.

## 두 번째 시도: 관점을 바꾸기

같은 일을 하더라도 다른 관점에서 보면 새로운 게 보일 때가 있다.

그전까지 나는 "기능 구현"에만 집중했다. 디자인대로 만들고, 정상 동작하면 끝. 근데 같은 작업을 할 때 관점을 바꿔봤다. "이 페이지 로딩 속도를 어떻게 줄일 수 있을까?" "이 컴포넌트의 접근성은 어떤가?" "이 폼의 에러 처리가 사용자 관점에서 괜찮은가?"

리스트 페이지 하나를 만들더라도, 무한 스크롤의 성능을 최적화하려고 Intersection Observer를 파고들면 새로운 영역이 열린다. 같은 폼 페이지인데 키보드만으로 모든 동작이 가능한지 확인하면 접근성이라는 새로운 과제가 생긴다. "하는 일"이 같아도 "깊이"를 달리하면 성장할 수 있다.

이 접근은 실제로 효과가 있었다.

팀에서 성능 개선 이니셔티브를 자발적으로 시작했다. 상품 리스트 페이지의 LCP가 3초 넘어가는 걸 발견하고, 이미지 최적화부터 시작해서 코드 스플리팅, 프리페칭까지 건드려봤다. 결과적으로 1.2초까지 줄였는데, 이 과정에서 웹 성능에 대해 이전보다 훨씬 깊이 알게 됐다. 같은 회사, 같은 프로덕트에서도 새로운 도전은 만들 수 있다.

## 세 번째: 다른 역할 경험하기

개발만 하다 보면 시야가 좁아진다.

기획자가 작성한 PRD를 보면서 "이 기능은 이렇게 만들면 되겠다"만 생각했었는데, 어느 날 기획자한테 물어봤다. "이 기능의 목표가 뭐예요? 어떤 지표를 올리려는 건가요?" 기획자가 설명해줬는데, 개발자인 내가 생각도 못한 비즈니스 맥락이 있었다. 이 기능은 사용자 리텐션을 위한 거고, 핵심 지표는 7일 재방문율이고, 경쟁사는 이미 이 기능을 가지고 있다는 것.

그 대화가 나한테는 꽤 충격이었다. 나는 PRD에 적힌 기능 명세만 보고 코드를 쳤는데, 그 뒤에 이런 전략이 있었다니. 이 맥락을 알고 개발하니까 의사결정이 달라졌다. "이 부분은 사용자가 빠르게 접근해야 하니까 로딩 속도가 중요하겠다", "이건 A/B 테스트를 할 수도 있으니까 플래그를 미리 넣어두자" 같은 판단을 할 수 있게 됐다. 코드를 치는 기술은 같은데, 뭘 왜 만드는지 이해하면 결과물의 질이 달라진다. 기획 미팅에도 참여하기 시작했다. 예전에는 "개발자는 기획 끝나고 들어가면 되지"라고 생각했는데, 초기 단계부터 참여하면 기술적으로 불가능한 부분을 미리 잡을 수 있고, 더 나은 대안을 제안할 수도 있다. 이건 코딩 실력과는 다른 종류의 성장이다.

## 글쓰기의 힘

정체기를 돌파하는 데 의외로 도움이 된 게 기술 블로그였다.

글을 쓰려면 제대로 알아야 한다. 대충 쓰면 티가 난다. "React의 reconciliation이 어떻게 동작하는지"를 설명하는 글을 쓰려면, 내가 정확히 이해하고 있어야 한다. 모호하게 알고 있던 부분이 글을 쓰는 과정에서 드러난다. "이 부분 설명이 안 되는데?"라는 순간이 오면, 그게 내가 정확히 모르는 부분이라는 뜻이다.

그리고 글을 쓰면 "내가 이번 달에 뭘 배웠는지"가 기록으로 남는다. 정체기에 빠지면 "나는 아무것도 성장 안 했다"는 감정에 사로잡히기 쉬운데, 지난 글들을 보면 "아 그래도 이건 새로 알게 됐구나"라는 게 보인다. 성장은 느끼기보다 기록으로 확인하는 게 정확하다.

## 정체기는 반복된다

솔직하게 말하면, 위의 방법들로 정체기를 "해결"한 건 아니다. 한동안 새로운 걸 배우면서 성장하는 느낌이 돌아왔다가, 또 어느 순간 비슷한 감정이 찾아온다. 정체기는 한 번 겪고 끝나는 게 아니라 주기적으로 반복되는 것 같다.

다만 처음 겪었을 때와 다른 건, 이제는 "아 이 느낌"하고 알아차린다는 거다. 무작정 불안해하는 대신 "지금 내가 편한 영역에 너무 오래 있었구나"라고 해석할 수 있게 됐다.

성장 곡선이라는 게 직선이 아니라 계단 형태라는 말이 있다. 한동안 제자리인 것 같다가 갑자기 올라가는 시기가 온다. 그 "제자리" 구간에서 포기하지 않는 게 중요한 건데, 이게 말은 쉽다. 막상 그 안에 있으면 끝이 안 보이니까.

## 환경을 바꾸는 것도 방법이다

결국 정체기가 너무 길어지면 환경을 바꾸는 것도 선택지다.

나는 같은 회사에서 팀을 이동한 적이 있다. 프로덕트 A 팀에서 프로덕트 B 팀으로. 같은 기술 스택인데 도메인이 달라지니까 새로운 게 많았다. A 팀에서는 쇼핑 도메인이었고, B 팀에서는 결제 도메인이었다. 같은 React인데 고려해야 하는 것들이 완전히 달랐다. 보안, 트랜잭션 무결성, 에러 핸들링의 중요도가 다른 차원이었다.

이직하지 않고도 환경을 바꿀 수 있다는 걸 그때 알았다. 회사 내에서 팀 이동, 프로젝트 변경, 역할 확장 같은 선택지가 있는데, 의외로 많은 사람이 이걸 고려하지 않는다. "이 팀에 배정됐으니까 여기서 해야 한다"고 생각하는데, 리드에게 말하면 의외로 유연하게 대응해주는 경우가 많다.

## 사람을 통해 배우기

정체기를 돌파하는 또 다른 방법은 사람이었다.

기술적으로 뛰어난 시니어의 PR을 의식적으로 읽기 시작했다. 내 리뷰 대상이 아닌 PR도. 어떤 구조로 코드를 짜는지, 변수명을 어떻게 짓는지, 에러를 어떻게 처리하는지. 같은 문제를 나라면 어떻게 풀었을지 비교하면서 읽으면 배우는 게 많다. 시니어한테 직접 "이거 왜 이렇게 하셨어요?"라고 물어보면 생각의 과정을 들을 수 있다. 코드 한 줄 뒤에 있는 판단의 근거를 아는 게 진짜 배움이다.

요즘은 약간 다른 생각도 한다. 성장에 집착하는 것 자체가 피로의 원인이 되기도 한다는 거. 매일매일 성장하고 있어야 한다는 강박. 가끔은 그냥 익숙한 일을 편하게 하는 시간도 필요한 거 아닐까. 그 기간에 체력을 비축하고, 다음 도전에 쓸 에너지를 모으는 거라고 생각하면 정체기도 나쁘지만은 않다. 아직 잘 모르겠지만.


AI 코딩 어시스턴트가 발전하면서 "이제 개발자가 필요 없어진다"는 우려의 목소리가 나오고 있습니다. 하지만 실제로는 개발자의 역할이 바뀌고 있을 뿐, 여전히 중요합니다. AI 시대에 개발자가 갖춰야 할 새로운 역량을 알아봅시다.

## 변화하는 개발자의 역할

### 과거: 코드 작성자

과거 개발자의 주요 역할은 코드를 작성하는 것이었습니다.

```
요구사항 분석 → 설계 → 코딩 → 테스트 → 배포
```

### 현재: 문제 해결자 + AI 협력자

현재 개발자는 AI와 협력하여 문제를 해결하는 역할을 합니다.

```
요구사항 분석 → 설계 → AI와 협력하여 코딩 → 검증 → 배포
```

## AI 시대에 중요한 개발자 역량

### 1. 문제 정의 능력

AI는 문제를 해결하는 데는 뛰어나지만, 문제를 정의하는 것은 사람의 영역입니다.

#### 왜 중요한가?

- AI는 명확한 요구사항이 있을 때만 좋은 결과를 만듭니다
- 모호한 문제를 구체화하는 능력이 필요합니다
- 비즈니스 요구사항을 기술적 솔루션으로 변환하는 능력

#### 개발 방법

```
✅ 좋은 예:
"사용자가 로그인할 때 이메일 인증을 거치도록 해줘.
인증 링크는 24시간 유효하고, 한 번만 사용 가능해야 해."

❌ 나쁜 예:
"로그인 기능 만들어줘"
```

### 2. 아키텍처 설계 능력

전체 시스템 구조를 설계하는 것은 여전히 사람의 영역입니다.

#### 왜 중요한가?

- AI는 개별 기능 구현에는 뛰어나지만 전체 구조 설계는 어렵습니다
- 확장성, 유지보수성, 성능을 고려한 설계가 필요합니다
- 비즈니스 요구사항을 아키텍처로 변환하는 능력

#### 개발 방법

- 마이크로서비스 vs 모놀리식
- 상태 관리 전략
- 데이터베이스 설계
- API 설계

### 3. 코드 검증 및 품질 관리 능력

AI가 만든 코드를 검증하고 품질을 관리하는 능력이 중요합니다.

#### 왜 중요한가?

- AI 코드에는 버그, 보안 취약점, 성능 이슈가 있을 수 있습니다
- 코드 리뷰와 테스트가 필수입니다
- 품질 기준을 설정하고 관리하는 능력

#### 체크리스트

- [ ] 코드가 요구사항을 만족하는가?
- [ ] 보안 취약점이 없는가?
- [ ] 성능이 최적화되었는가?
- [ ] 테스트 코드가 작성되었는가?
- [ ] 문서화가 되어 있는가?

### 4. AI 프롬프트 엔지니어링 능력

AI에게 효과적으로 요청하는 능력이 생산성을 크게 좌우합니다.

#### 왜 중요한가?

- 좋은 프롬프트 = 좋은 코드
- 컨텍스트를 잘 제공하는 능력
- 반복적 개선을 통한 최적화

#### 개발 방법

```
명확한 요구사항 + 컨텍스트 제공 + 구체적인 제약사항
```

### 5. 비즈니스 이해 능력

기술뿐만 아니라 비즈니스를 이해하는 능력이 중요합니다.

#### 왜 중요한가?

- 기술적 해결책이 비즈니스 가치를 만들어야 합니다
- 사용자 경험을 고려한 개발
- ROI를 고려한 기술 선택

#### 개발 방법

- 사용자 관점에서 생각하기
- 비즈니스 목표 이해하기
- 기술 선택 시 비용-효과 고려하기

### 6. 학습 능력 및 적응력

기술이 빠르게 변화하는 시대에 빠르게 학습하고 적응하는 능력이 중요합니다.

#### 왜 중요한가?

- 새로운 도구와 기술이 계속 등장합니다
- 학습 속도가 경쟁력이 됩니다
- 지속적인 성장이 필요합니다

#### 개발 방법

- 새로운 기술을 빠르게 익히기
- 실험하고 실패하며 학습하기
- 커뮤니티와 지식 공유하기

### 7. 협업 및 소통 능력

AI와의 협업뿐만 아니라 사람과의 협업도 중요합니다.

#### 왜 중요한가?

- 복잡한 프로젝트는 혼자 할 수 없습니다
- 비개발자와의 소통이 필요합니다
- 팀 내 지식 공유가 중요합니다

#### 개발 방법

- 명확한 문서 작성
- 코드 리뷰 문화
- 지식 공유 세션

## 코딩 능력의 변화

### 과거: 문법과 API 암기

```
- 언어 문법을 정확히 알고 있어야 함
- API를 외우고 있어야 함
- 복잡한 알고리즘을 구현할 수 있어야 함
```

### 현재: 문제 해결과 검증

```
- 문제를 정의하고 해결 방법을 찾을 수 있어야 함
- AI가 만든 코드를 이해하고 검증할 수 있어야 함
- 필요할 때 적절한 도구를 선택할 수 있어야 함
```

## 실전 역량 개발 방법

### 1. 문제 정의 능력 향상

```
- 요구사항을 명확히 정리하는 습관
- 비즈니스 요구사항을 기술적 요구사항으로 변환 연습
- AI에게 명확한 프롬프트 작성 연습
```

### 2. 아키텍처 설계 능력 향상

```
- 다양한 아키텍처 패턴 학습
- 실제 프로젝트 설계 경험
- 다른 사람의 설계 리뷰하기
```

### 3. 코드 검증 능력 향상

```
- 코드 리뷰 문화 참여
- 테스트 작성 습관
- 보안 및 성능 검토 경험
```

### 4. AI 활용 능력 향상

```
- 다양한 AI 도구 시도해보기
- 프롬프트 작성 연습
- AI와의 협업 워크플로우 구축
```

## 주니어 개발자를 위한 조언

### 집중해야 할 역량

1. **기본기 탄탄히**
   - 프로그래밍 기본 개념 이해
   - 데이터 구조와 알고리즘
   - 소프트웨어 공학 원칙

2. **문제 해결 능력**
   - 복잡한 문제를 작은 문제로 분해
   - 다양한 해결 방법 고려
   - 최적의 해결책 선택

3. **학습 능력**
   - 빠르게 학습하는 방법
   - 실험하고 실패하며 배우기
   - 지속적인 성장

### 피해야 할 함정

1. **AI에만 의존**
   - 코드를 이해하지 않고 사용
   - 학습 기회를 놓침

2. **기본기 소홀**
   - AI가 있으니 기본기를 안 해도 된다는 생각
   - 기본기가 없으면 AI 코드도 검증 못함

3. **적응 실패**
   - 변화를 거부하고 기존 방식만 고집
   - 새로운 도구를 배우지 않음

## 마무리

AI 시대에 개발자의 역할은 바뀌고 있지만, 여전히 중요합니다. 코딩 능력보다 중요한 것은:

1. **문제 정의 능력** - 명확한 요구사항 정리
2. **아키텍처 설계 능력** - 전체 구조 설계
3. **코드 검증 능력** - 품질 관리
4. **AI 협업 능력** - 효과적인 프롬프트 작성
5. **비즈니스 이해** - 기술과 비즈니스 연결
6. **학습 능력** - 빠른 적응과 성장
7. **협업 능력** - 사람과의 소통

**핵심 메시지:**

- AI는 도구이지 대체재가 아닙니다
- 개발자의 역할이 바뀌고 있을 뿐, 사라지지 않습니다
- 코딩 능력보다 문제 해결 능력이 중요해졌습니다
- 지속적인 학습과 적응이 필요합니다

**"AI와 함께 성장하는 개발자"가 되어야 합니다.**

AI 시대에 성공하려면, AI를 활용하면서도 기본기를 탄탄히 하고, 문제 해결 능력을 키우고, 지속적으로 학습해야 합니다. 코딩 능력만으로는 부족하지만, 코딩 능력이 전혀 필요 없다는 것도 아닙니다. 균형잡힌 역량 개발이 중요합니다.



작년쯤부터 주변에서 창업 얘기가 부쩍 늘었다. 같이 부트캠프 나온 동기 한 명은 퇴사하고 뭔가를 만들고 있고, 전 직장 동료는 주말마다 사이드 프로젝트를 돌리다가 법인을 냈다고 한다. 개발자 커뮤니티에서도 "아이디어가 있는데 같이 할 사람 구합니다" 같은 글이 눈에 자주 띈다.

나도 창업에 관심이 있다. 솔직히 말하면 꽤 오래 전부터. 근데 관심이 있다는 것과 실제로 뛰어드는 것 사이에는 엄청난 간극이 있다. 그 간극 사이에서 이것저것 읽고, 주변 사람들 지켜보고, 내 나름대로 정리한 것들을 써본다.

## 개발자라서 빠지기 쉬운 함정

개발자가 창업을 생각할 때 가장 먼저 하는 게 뭘까. 코드를 짠다. 아이디어가 떠오르면 바로 터미널을 열고 프로젝트를 세팅한다. `npx create-next-app`, DB 스키마 설계, API 라우팅. 이게 우리한테는 가장 자연스러운 행동이다. 문제를 보면 코드로 해결하는 게 몸에 배어 있으니까.

근데 여기서부터 꼬인다.

Paul Graham이 Y Combinator를 운영하면서 수천 개의 스타트업을 봤는데, 그가 반복적으로 강조하는 게 있다. "Make something people want." 사람들이 원하는 걸 만들라는 거다. 당연한 말 같지만, 여기서 핵심은 순서다. "사람들이 원하는 것"을 먼저 확인하고, 그다음에 만들어야 한다. 대부분의 개발자 창업자는 이 순서가 뒤집혀 있다. 먼저 만들고, 그다음에 원하는 사람을 찾으려 한다.

내 주변에서도 이 패턴을 봤다. 한 선배가 "개발자 전용 타임 트래킹 앱"을 만들겠다고 했다. 3개월 동안 혼자서 프론트, 백엔드, 인프라를 다 구축했다. GitHub 연동, 커밋 기반 자동 시간 측정, 대시보드까지. 기술적으로는 훌륭했다. 근데 베타를 열었을 때 가입자가 23명이었고, 일주일 뒤에 활성 사용자는 3명이었다. 그 선배가 한 말이 기억난다. "만드는 건 재밌었는데, 왜 아무도 안 쓰는지 모르겠어."

왜 안 쓰는지는 간단하다. 아무한테도 물어보지 않았으니까. 개발자들이 시간 추적에 불편을 느끼는지, 기존 도구의 어떤 점이 부족한지, 돈을 낼 만큼 절실한 문제인지를 확인하지 않았다.

## 사이드 프로젝트와 사업은 다르다

이걸 구분하는 게 생각보다 중요하다. 사이드 프로젝트는 내가 만들고 싶은 걸 만드는 거다. 기술을 배우고 싶어서, 포트폴리오에 넣고 싶어서, 그냥 재밌어서. 동기가 나한테 있다.

사업은 다르다. 다른 사람이 돈을 내고 쓸 만큼의 가치를 만들어야 한다. 동기가 나한테 있는 게 아니라 시장에 있어야 한다. 이 차이가 사소해 보이는데, 모든 의사결정을 바꿔놓는다.

사이드 프로젝트를 할 때는 기술 스택이 중요하다. "이번에 Rust 배워볼까?" "Next.js 15 써볼까?" 이런 고민이 의미가 있다. 사업에서는 그런 고민이 의미 없다. 사용자한테 중요한 건 내 코드가 Rust로 짜여졌는지가 아니라, 자기 문제가 해결되는지다.

물론 사이드 프로젝트에서 출발한 사업이 많다. 근데 그 전환 지점이 어디인지를 인식해야 한다. "이거 사람들이 진짜 쓰네?"라는 신호가 오는 순간, 마인드셋을 바꿔야 한다. 더 이상 내 기술 호기심을 충족시키는 게 우선이 아니라, 사용자가 뭘 원하는지를 파악하는 게 우선이 된다.

Sam Altman이 한 말 중에 이런 게 있다. "Fast iteration can make up for a lot; it's usually ok to be wrong if you iterate quickly." 빠르게 반복하면 많은 걸 만회할 수 있다는 거다. 근데 이 반복의 기준이 "내가 원하는 기능을 추가하는 것"이 되면 안 된다. "사용자한테 보여주고, 피드백 받고, 고치는 것"이 되어야 한다.

## 퇴사 타이밍이라는 난제

창업 관련 글을 읽으면 퇴사 타이밍에 대한 조언이 많다. "충분히 준비가 되면 뛰어들어라", "기회비용을 계산해봐라", "나이가 젊을수록 유리하다." 다 맞는 말인데, 구체성이 없다. 충분한 준비라는 게 대체 뭔데.

내가 관찰한 바로는, 잘 된 케이스에서 공통적으로 보이는 패턴이 있다. 퇴사 전에 이미 "신호"가 있었다. 사이드 프로젝트로 만든 걸 누군가 쓰고 있었다거나, 특정 문제에 대해 업계 사람들이 반복적으로 불만을 토로하는 걸 직접 목격했다거나, 함께할 공동창업자가 이미 있었다거나. 아무 신호도 없이 "이번 달에 퇴사하고 뭔가 해야지"로 시작한 경우는 대부분 몇 달 안에 다시 취업 준비를 하게 됐다.

Derek Sivers가 "Don't start a business until people are asking you to"라고 했는데, 이게 극단적으로 들릴 수 있지만 핵심은 맞다. 시장에서 어떤 형태로든 수요의 신호가 있어야 한다. 그 신호 없이 만드는 건 도박에 가깝다.

한 가지 현실적인 접근법은, 재직 중에 할 수 있는 데까지 해보는 거다. 퇴근 후와 주말에 프로토타입을 만들고, 잠재 사용자한테 보여주고, 반응을 확인한다. 이 단계에서 "돈 낼 의향이 있냐"까지 물어본다. 여기서 긍정적인 반응이 나오면, 그때 퇴사를 구체적으로 고민한다.

회사를 다니면서 이걸 하는 게 쉽지 않다는 건 안다. 퇴근하면 지쳐서 넷플릭스 틀고 싶은 날이 더 많다. 근데 이 과정을 견딜 수 없으면, 퇴사하고 풀타임으로 해도 비슷한 상황이 온다. 창업은 지칠 때 멈출 수 있는 게 아니니까. 어떤 의미에서는, 재직 중에 사이드로 얼마나 하느냐가 본인의 의지를 테스트하는 과정이기도 하다.

## YC가 실제로 보는 것

YC(Y Combinator) 합격/불합격 이야기는 온라인에 많다. 근데 대부분 합격 후기 위주라서 편향이 있다. 내가 여러 글이랑 영상을 보면서 정리한 바로는, YC가 보는 건 크게 세 가지다.

첫째, 창업자. 이게 압도적으로 중요하다. Paul Graham이 "Relentlessly Resourceful"이라는 글에서 좋은 창업자의 특성을 한마디로 요약했다. 끈질기게 자원을 찾아내는 사람. 문제가 생기면 멈추지 않고 어떻게든 돌파하는 사람. 기술적 능력도 중요하지만, 그보다 "이 사람이 벽에 부딪혔을 때 어떻게 할까"가 더 큰 판단 기준이다.

둘째, 시장. "이 문제를 겪는 사람이 얼마나 많은가?"와 "이 문제가 얼마나 절실한가?"를 본다. 대단한 기술을 가지고 있어도, 그걸 원하는 사람이 없으면 의미가 없다.

셋째, 진행 상황. 아이디어만 가지고 오는 팀보다, 뭔가를 이미 만들었고 사용자가 있는 팀이 유리하다. 완성도보다 속도를 본다. "6개월 동안 이걸 만들었습니다"보다 "3주 만에 이걸 만들고 사용자 50명을 모았습니다"가 더 좋은 신호다.

이건 YC에 지원하지 않더라도 유효한 프레임워크다. 자기 자신에게 물어보면 된다. "나는 끈질긴가?", "이 문제를 겪는 사람이 충분한가?", "나는 빠르게 움직이고 있는가?"

## 기술로 해결할 수 있는 문제와 없는 문제

개발자가 창업에서 가지는 가장 큰 장점은 명확하다. 직접 만들 수 있다는 거다. 비개발자 창업자는 MVP 하나 만드는 데 외주를 쓰거나 기술 공동창업자를 찾아야 한다. 우리는 바로 만들 수 있다. 이건 진짜 큰 장점이다.

근데 이 장점이 함정이 되기도 한다. 모든 문제를 기술로 풀려고 하니까. "마케팅이 안 돼? SEO를 최적화하자." "사용자가 안 늘어? 새 기능을 추가하자." "이탈률이 높아? UI를 리디자인하자." 기술적 해결책에만 손이 간다.

근데 초기 스타트업에서 가장 중요한 문제들은 기술로 풀 수 없는 경우가 많다. "이 사람이 진짜 돈을 낼까?"는 대화를 해봐야 안다. "우리 제품이 어떤 가치를 제공하는가?"는 포지셔닝 문제다. "왜 사람들이 기존 솔루션에서 넘어와야 하는가?"는 시장 이해의 문제다.

Paul Graham이 "Do Things That Don't Scale"에서 강조한 게 이거다. Airbnb 창업자들이 초기에 뉴욕의 호스트를 한 명 한 명 방문했다. Stripe 창업자들이 잠재 고객한테 직접 가서 결제 시스템을 대신 세팅해줬다. 이건 코드 한 줄로 해결되는 게 아니다. 사람을 만나고, 대화하고, 불편한 일을 손으로 하는 거다.

내가 아는 한 CTO가 창업 초기에 고객 지원을 직접 했다고 한다. Zendesk 설정하는 것보다 카카오톡으로 일일이 답장하는 게 더 빠르기도 했고, 사용자가 뭘 불편해하는지를 직접 체감할 수 있었다고. 처음에는 "이런 건 내 일이 아닌데"라고 느꼈지만, 나중에 돌이켜보니 그때 고객 대화에서 얻은 인사이트가 이후 제품 방향을 결정했다고 한다.

## 공동창업자에 대해

혼자 창업할까, 같이 할까. 이것도 많이 고민되는 부분이다.

통계적으로 보면 공동창업이 유리하다고 한다. YC에서도 공동창업 팀을 선호한다고 알려져 있다. 이유는 여러 가지인데, 서로 보완이 되고, 힘들 때 의지할 수 있고, 판단을 견제할 수 있고.

근데 내가 주변에서 본 현실은, 공동창업자 관계가 깨지는 게 스타트업 실패의 가장 흔한 원인 중 하나라는 거다. 원래 친한 친구였는데 지분 문제로 사이가 틀어진 경우, 비전이 달라지면서 방향 갈등이 생긴 경우, 한 명은 풀타임이고 한 명은 사이드로 하면서 기여도 갈등이 생긴 경우.

그래서 결론이 "그래도 공동창업이 좋다"는 아니고, "잘 맞는 공동창업자를 찾는 게 쉽지 않다"는 거다. 오히려 혼자 빠르게 검증하고, 확신이 생겼을 때 팀을 꾸리는 것도 방법이다. 특히 개발자는 혼자서 MVP를 만들 수 있으니까, 초기 검증 단계에서는 혼자 해도 불리하지 않다.

다만 혼자 하면 빠지기 쉬운 게, 사업 전체를 기술의 관점으로만 보게 된다는 거다. 개발 말고도 해야 할 일이 산더미인데, 코딩하는 시간이 가장 편하니까 계속 코드만 짜게 된다. 이건 의식적으로 경계해야 한다.

## 창업이 맞는 사람, 아닌 사람

불편한 진실을 쓰자면, 창업은 모든 사람에게 맞는 선택이 아니다. "도전하면 뭐든 할 수 있다"는 말은 동기부여에는 좋지만 현실적이지 않다.

내가 관찰한 바로는, 창업에 적합한 사람에게는 몇 가지 공통점이 있다. 불확실성을 견디는 능력. 매달 같은 날에 월급이 들어오지 않는 상황이 스트레스인 사람도 있고, 그게 오히려 동기부여가 되는 사람도 있다. 거절을 일상적으로 받아들이는 자세. 영업, 투자 유치, 채용, 거의 모든 과정에서 거절당한다. 이게 축적되면 꽤 힘들다.

그리고 무엇보다, 특정 문제에 대한 집착. "이건 이렇게 되어야 하는데 왜 아무도 안 만들지?"라는 생각이 몇 달째 안 떠나는 상태. 이런 집착이 없으면 어려운 시기에 포기하기 쉽다.

반대로, "좀 더 자유롭게 일하고 싶어서", "연봉 천장을 깨고 싶어서", "남의 밑에서 일하기 싫어서"라는 이유만으로 창업을 생각하고 있다면, 프리랜서나 1인 개발 같은 선택지가 더 맞을 수도 있다. 창업은 자유로운 게 아니라 다른 종류의 구속이다. 상사 대신 고객, 투자자, 팀원한테 책임이 생긴다.

## 그래서 지금 뭘 하면 좋을까

당장 퇴사할 생각이 없더라도 할 수 있는 게 있다.

하나, 문제를 모으기 시작한다. 일상에서, 업무에서, 주변 사람들한테서 반복적으로 불편해하는 것들을 메모한다. 아이디어를 모으는 게 아니라 문제를 모으는 거다. 해결책은 나중에 생각해도 된다.

둘, 사용자랑 대화하는 연습을 한다. 우리한테 가장 어색한 일이다. 근데 창업의 절반 이상이 사람과의 대화다. 지금 다니는 회사의 고객 지원 내용을 읽어보는 것만으로도 시작이 된다. 사용자가 뭘 불편해하는지, 어떤 말로 표현하는지를 관찰하는 거다.

셋, 작게 만들어서 공개한다. 완벽하지 않아도 된다. 주말에 만든 작은 도구를 트위터에 올리고, 사람들 반응을 본다. 이게 습관이 되면 "만들고 공개하고 피드백 받는" 사이클이 자연스러워진다. 이 사이클이 창업의 기본 단위다.

넷, 돈 관련 준비를 한다. 비상금이 얼마 있는지, 최소한의 생활비가 얼마인지, 몇 개월을 버틸 수 있는지를 숫자로 파악한다. 막연하게 "좀 모아야지"가 아니라 구체적인 숫자가 필요하다. 이 숫자가 퇴사 타이밍의 현실적인 기준이 된다.

나도 아직 창업을 하지 않았다. 관심만 가지고 몇 년째다. 근데 그 기간 동안 읽고 관찰하면서 알게 된 게 있다면, 창업은 어느 날 갑자기 결심하고 뛰어드는 게 아니라 서서히 준비되는 거라는 것. 지금 하고 있는 사이드 프로젝트가, 매일 마주치는 문제들이, 나누는 대화들이 언젠가 연결될 수도 있다.

그 연결이 올 때 움직일 수 있도록, 지금은 안테나를 세워두는 시기라고 생각한다.


기획서가 내려왔다. "쿠폰 시스템을 만들어주세요. 관리자가 쿠폰을 생성하고, 사용자가 적용할 수 있어야 합니다."

바로 코드를 쓰기 시작했다. 쿠폰 생성 API, 적용 API, 관리자 페이지, 사용자 UI. 2주 만에 완성했다. 기획서에 적힌 대로 동작했다.

그런데 출시 후 문제가 생겼다. 마케팅팀이 "특정 상품에만 적용되는 쿠폰"을 원했다. 기획서에는 없었지만, 비즈니스 관점에서 당연히 필요한 기능이었다. 쿠폰 모델의 설계를 처음부터 바꿔야 했다.

기획서를 받았을 때 "왜 쿠폰 시스템이 필요한가?"를 물어봤다면, "이번 프로모션에서 특정 카테고리 할인을 하려고요"라는 답을 들었을 거다. 그러면 처음부터 카테고리/상품 필터를 고려한 설계를 했을 거다.

## What vs Why

기획서는 대부분 "What"을 알려준다. 무엇을 만들어야 하는지. 그런데 개발자가 "Why"를 모르면, 기획서에 명시되지 않은 중요한 요구사항을 놓친다.

```
What: 사용자 프로필 페이지에 "활동 뱃지"를 보여주세요
Why: 사용자 이탈이 늘고 있어서, 활동에 대한 보상감을 주려는 거예요
```

Why를 알면 생각이 달라진다. "뱃지를 그냥 보여주는 것"이 아니라, "뱃지를 획득했을 때 성취감을 줘야 한다"로 목표가 바뀐다. 그러면 획득 순간의 애니메이션, 알림, 공유 기능을 제안할 수 있다. 기획서에 없더라도.

## 질문하는 법

PM에게 "왜요?"라고 대놓고 물으면 도전적으로 들릴 수 있다. 질문의 프레이밍이 중요하다.

**"이 기능의 성공 지표가 뭔가요?"** 이 질문 하나로 비즈니스 목표가 명확해진다. "DAU를 높이려는 건지, 결제 전환율을 올리려는 건지"에 따라 기술적 접근이 달라진다.

**"사용자가 이 기능을 가장 많이 쓸 상황이 어떤 건가요?"** 사용 맥락을 이해하면, UI 설계와 성능 최적화의 우선순위가 보인다.

**"이 스펙에서 꼭 있어야 하는 것과 나중에 추가해도 되는 게 뭔가요?"** MVP 범위를 명확히 한다. 이걸 안 물어보면 전부 필수인 줄 알고 과도하게 만들게 된다.

## 기술적 판단으로 기획을 바꾸기

때로는 개발자의 기술적 판단이 기획을 더 좋게 만든다.

기획서에 "실시간 알림"이 적혀 있다고 하자. WebSocket을 붙이면 되지만, 요구사항을 자세히 보니 "주문 상태가 바뀌면 알림을 보내줘야 한다"는 거다. 주문 상태 변경은 평균 1시간에 한 번 정도. 이걸 위해 WebSocket 연결을 계속 유지할 필요가 있을까?

"폴링으로 30초마다 체크하면 충분하고, WebSocket보다 구현과 운영이 훨씬 단순합니다. 사용자 경험 차이도 거의 없습니다."

이렇게 제안하면 PM도 동의하는 경우가 많다. 불필요한 복잡도를 줄이면서 같은 사용자 경험을 제공할 수 있으니까.

반대로, 기획서에는 "정적 페이지"로 되어 있지만 기술적으로 "사실 이건 ISR로 하면 관리자가 직접 수정할 수 있게 됩니다. 개발 요청 없이도요"라고 제안할 수도 있다. PM은 기술적 가능성을 다 알지 못한다. 개발자가 가능성을 보여주면 더 좋은 프로덕트가 나온다.

## 스펙을 줄이는 용기

PM이 가장 고마워하는 개발자는 일정을 잘 지키는 사람이 아니라, "이건 안 만들어도 됩니다"라고 말해주는 사람이라는 걸 알게 됐다.

기능이 추가될수록 복잡도가 올라가고, 일정이 밀리고, 버그가 늘어난다. "이 기능은 사용률이 낮을 것 같은데, 출시 후 데이터를 보고 추가해도 되지 않을까요?"라는 제안은 PM에게 의사결정 근거를 주는 것이다.

물론 이건 신뢰가 쌓인 후에 할 수 있는 이야기다. 신입이 첫날부터 "이거 필요 없는 것 같은데요"라고 하면 곤란하다. 먼저 요청받은 일을 잘 해내서 신뢰를 쌓고, 그 위에서 제안해야 받아들여진다.

코드만 잘 쓰는 개발자는 많다. 비즈니스를 이해하고, 기획에 기여하고, 불필요한 일을 줄여주는 개발자는 드물다. 그 차이가 시니어와 주니어를 가르는 기준 중 하나다.



"취미가 뭐예요?"

이 질문을 받으면 멈칫한다. 코딩? 그건 일이다. 기술 블로그 읽기? 그것도 일의 연장이다. 사이드 프로젝트? 일과 다를 게 없다. 일하고, 일과 관련된 걸 공부하고, 일과 관련된 글을 읽는다. 이게 내 일상이었다.

처음에는 이게 문제라고 생각하지 않았다. 코딩이 재미있으니까. 새로운 기술을 배우는 게 즐거우니까. 그런데 몇 년이 지나니까 뭔가 빠져 있다는 느낌이 들었다.

## 코딩만 하면 생기는 일

**대화 주제가 좁아진다.** 개발자 모임에서는 자연스럽지만, 비개발자 친구들과 만나면 할 이야기가 점점 줄어든다. "요즘 뭐 해?" — "코딩." "그 외에는?" — "..."

**사고가 한쪽으로 기운다.** 모든 문제를 기술적으로 해결하려는 습관이 생긴다. 효율성, 최적화, 시스템 사고 — 이게 좋을 때도 있지만, 세상의 모든 것이 코드로 해결되지는 않는다.

**번아웃에 취약해진다.** 취미가 코딩이면, 일에서 지쳤을 때 쉴 곳이 없다. 쉬는 시간에도 같은 종류의 인지 활동을 하고 있으니까. 뇌가 모드를 전환할 기회가 없다.

## 시도한 것들

의식적으로 코딩과 관련 없는 활동을 시도해봤다.

**요리.** 레시피를 따라 하는 것부터 시작했다. 요리가 좋은 건 결과물이 즉시 나온다는 거다. 코드는 배포하고 사용자가 써봐야 피드백이 오지만, 음식은 만들고 바로 먹으면 된다. 그리고 맛이 있든 없든 30분이면 끝난다. 커밋할 필요도, 테스트할 필요도 없다.

**러닝.** 달리는 동안에는 아무것도 안 해도 된다. 기술 팟캐스트를 끄고, 음악도 끄고, 그냥 발소리만 듣고 달린다. 머리를 비우는 데 이것만 한 게 없다.

**소설 읽기.** 기술서적 대신 소설을 읽기 시작했다. 소설은 효율적이지 않다. 요약해서 핵심만 뽑아낼 수 없다. 그게 좋다. 느리게 읽고, 등장인물의 감정에 공감하고, 다 읽고 나서 여운에 잠기는 시간. 비효율적이지만 풍요로운 시간이다.

## 취미의 기준

처음에는 "생산적인 취미"를 찾으려고 했다. 외국어 공부, 악기 연주 — 뭔가 스킬이 쌓이는 것. 이것도 결국 개발자의 성장 강박이다. 취미에도 성과를 기대하는 거다.

취미의 기준을 바꿨다. "이걸 하면서 시간 가는 줄 몰랐는가?" 그게 전부다. 잘할 필요도 없고, 발전할 필요도 없고, 남에게 보여줄 필요도 없다. 그냥 하고 있으면 즐거운 것.

아직 "이게 내 취미입니다"라고 자신 있게 말할 수 있는 걸 찾지는 못했다. 이것저것 해보는 중이다. 어쩌면 평생 찾는 중일지도 모른다.

그래도 코딩만 하던 때보다는 낫다. 가끔 서투르게 요리를 하고, 느리게 달리고, 소설을 읽으면서 코딩과 전혀 다른 종류의 만족감을 느끼고 있다. 그리고 이상하게도, 취미 시간이 생기고 나서 코딩이 다시 재미있어졌다.



개발자의 업무 중 코드를 직접 작성하는 시간은 생각보다 적다. 나머지는 읽고 쓰는 시간이다. PR 설명을 쓰고, 슬랙에서 기술적 결정을 설명하고, 장애 보고서를 작성하고, 기술 제안서를 쓴다. 이 글쓰기의 질이 팀의 생산성에 직접 영향을 준다.

## PR 설명

PR 설명이 없거나 "기능 구현"이라고만 적힌 PR을 리뷰해본 적 있는가? 리뷰어는 코드를 한 줄씩 읽으며 "이게 뭘 하려는 거지?"를 추론해야 한다. 시간이 오래 걸리고, 의도를 잘못 파악하면 엉뚱한 코멘트를 단다.

좋은 PR 설명은 리뷰어의 시간을 줄여준다:

```markdown
## 변경 사항
결제 페이지에서 쿠폰 적용 시 할인 금액이 음수로 표시되는 버그 수정

## 원인
쿠폰 할인율(`discountRate`)이 0~1 사이 소수인데,
UI에서 퍼센트(0~100)로 표시할 때 100을 곱하지 않고 그대로 사용함.
`0.15 * 10000 = 1500`이어야 하는데 `15 * 10000 = 150000`으로 계산됨.

## 해결
`formatDiscount()` 함수에서 discountRate에 100을 곱하는 로직 추가.
관련 유닛 테스트 3개 추가.

## 테스트
- [x] 10%, 50%, 100% 쿠폰으로 테스트
- [x] 쿠폰 없는 경우 기존 동작 확인
```

이 PR은 코드를 보기 전에 이미 "무엇이 문제였고, 어떻게 고쳤는지" 파악이 된다. 리뷰어는 "이 수정이 맞는지"만 확인하면 된다.

## 장애 보고서

장애가 나면 보고서를 쓴다. 이걸 어떻게 쓰느냐에 따라 같은 장애의 재발을 막을 수도, 묻어버릴 수도 있다.

나쁜 장애 보고서:
```
결제 오류 발생. 서버 재시작으로 해결.
```

좋은 장애 보고서:
```
## 타임라인
- 14:23 — 결제 실패 알림 (Sentry)
- 14:25 — 확인 시작. 결제 API 타임아웃 확인
- 14:30 — PG사 상태 페이지 확인, 정상
- 14:35 — DB 커넥션 풀 고갈 확인 (max 10, active 10, waiting 47)
- 14:40 — 원인 파악: 배치 작업이 커넥션을 점유하고 반환하지 않음
- 14:42 — 배치 작업 중지, 커넥션 반환 확인
- 14:45 — 결제 정상 동작 확인

## 근본 원인
배치 작업에서 트랜잭션 에러 시 커넥션을 반환하지 않는 코드.
try-catch에서 catch 블록에 커넥션 release가 빠져 있었음.

## 조치
1. catch 블록에 커넥션 release 추가 (PR #234)
2. 커넥션 풀 사용량 모니터링 알림 추가
3. 커넥션 풀 최대값 10 → 30으로 조정

## 재발 방지
- 커넥션 풀 사용률 80% 이상 시 슬랙 알림
- 배치 작업은 별도 커넥션 풀 사용하도록 분리 (다음 스프린트)
```

두 번째 보고서는 3개월 후에 비슷한 상황이 발생했을 때, 이전 경험을 바탕으로 빠르게 대응할 수 있는 자산이 된다.

## 기술 제안서 (RFC)

새로운 기술이나 아키텍처를 도입하고 싶을 때 "이거 좋으니까 쓰자"로는 설득이 안 된다. 기술 제안서를 쓸 수 있어야 한다.

```markdown
# 상태 관리 라이브러리 마이그레이션 제안

## 현재 상태
Redux + Redux Saga로 전역 상태 관리.
보일러플레이트 코드가 과도하고, 새 기능 추가 시 action/reducer/saga를
매번 작성해야 해서 개발 속도 저하.

## 제안
Zustand로 마이그레이션

## 근거
1. 보일러플레이트 감소: 같은 기능을 30% 적은 코드로 구현 가능
2. 번들 사이즈: Redux Toolkit(~11KB) + Saga(~14KB) vs Zustand(~1KB)
3. 학습 곡선: 새 팀원 온보딩 시간 단축
4. 커뮤니티: npm 주간 다운로드 3배, GitHub 이슈 응답 속도

## 대안 검토
- Jotai: 원자적 상태에 적합하나 우리 앱의 전역 상태 패턴과 안 맞음
- Recoil: Meta 내부 지원 불확실, 업데이트 빈도 저조

## 마이그레이션 계획
1. 새 기능은 Zustand로 작성 (즉시)
2. 기존 기능을 점진적으로 전환 (분기 1건)
3. Redux 완전 제거 목표: 3개월

## 리스크
- 마이그레이션 중 두 시스템 공존으로 인한 복잡도 증가
- 기존 Redux devtools 대비 디버깅 경험 변화
```

이 문서 하나로 팀 미팅에서 30분이면 결정이 난다. 문서 없이 회의하면 1시간을 써도 "다음에 다시 이야기하자"로 끝나기 쉽다.

## 슬랙 메시지

짧은 슬랙 메시지도 글쓰기다.

나쁜 예:
```
이거 안 돼요
```

좋은 예:
```
결제 페이지에서 "적용" 버튼 클릭 시 콘솔에
"TypeError: coupon.discount is not a function" 에러가 나면서
할인이 적용되지 않습니다. Chrome 최신, 로컬 dev 환경.
스크린샷 첨부합니다.
```

두 번째 메시지는 읽는 사람이 바로 원인을 추론할 수 있다. "어떤 페이지에서, 어떤 동작을 했더니, 어떤 에러가 나며, 어떤 환경에서" — 이 네 가지만 포함해도 메시지의 질이 완전히 달라진다.

코드를 잘 쓰는 사람이 글도 잘 쓰는 건 아니다. 그런데 글을 잘 쓰는 개발자는 팀 안에서 다른 종류의 영향력을 갖게 된다. 기술적 결정을 주도하고, 장애 상황을 정리하고, 팀의 지식을 체계화하는 사람. 코딩 실력만으로는 얻기 어려운 위치다.



작년 가을, VS Code가 느려졌다. 파일을 열 때 2초, 자동완성이 뜨는 데 1초. 체감 속도가 눈에 띄게 떨어졌는데 원인을 찾지 못하고 있었다. 그러다 우연히 익스텐션 목록을 열어봤다. 38개. 언제 이렇게 됐는지 기억도 안 났다. 하나씩 확인해봤더니 절반 이상이 "이거 좋다더라" 하고 깔아놓고 한 번도 쓰지 않은 것들이었다. 테마만 4개, 깃 관련이 중복으로 3개, 린터가 2개. 쓸모없는 익스텐션이 에디터 시작 시간을 300ms씩 잡아먹고 있었다.

전부 끄고 하나씩 필요할 때만 다시 켰다. 12개가 남았다. 에디터가 다시 빨라졌다. 파일 여는 데 0.5초. 근데 문제는 속도가 아니었다. 진짜 문제는 38개의 익스텐션이 깔려 있을 때 내 머릿속에서 벌어지고 있던 일이었다.

## 모든 도구에는 인지 비용이 붙어 있다

어떤 블로거가 디지털 미니멀리즘에 대해 이런 취지의 말을 한 적이 있다. 기술 도구를 평가할 때 "이걸 쓰면 뭘 얻는가"가 아니라 "이걸 쓰면 뭘 잃는가"를 먼저 봐야 한다고. 대부분의 사람은 전자만 본다. 이 앱을 깔면 편리해진다, 이 서비스에 가입하면 정보를 얻는다, 이 슬랙 워크스페이스에 들어가면 기회가 생긴다. 전부 맞는 말이다. 근데 그 편리함과 정보와 기회에는 보이지 않는 인지 비용이 청구서 없이 따라붙는다.

VS Code 익스텐션 38개는 각각 조그만 비용을 부과하고 있었다. 에디터가 느려지는 물리적 비용도 있었지만, 더 큰 건 인지적 비용이었다. 파일을 열 때마다 무의식적으로 사이드바에 뜨는 아이콘을 스캔한다. 커맨드 팔레트를 열면 안 쓰는 익스텐션의 명령어가 섞여 나온다. 자동완성 목록에 모르는 제안이 끼어든다. 각각은 0.1초짜리 작은 방해지만, 그게 하루에 몇 백 번 쌓이면 뇌가 처리해야 할 잡음의 총량이 어마어마해진다.

이건 에디터만의 문제가 아니다. 핸드폰에 깔린 앱, 가입한 서비스, 들어간 슬랙 채널, 팔로우한 뉴스레터, 브라우저에 열어둔 탭. 전부 인지 비용을 발생시킨다. 그리고 그 비용은 눈에 안 보이니까 청구서가 없다. 신용카드 명세서처럼 월말에 "이번 달 인지 비용 총액: 생산적인 시간 43시간"이라고 찍혀 나오지 않는다. 그래서 계속 추가만 하고 제거는 안 한다.

## 슬랙 워크스페이스 5개

작년에 슬랙 워크스페이스가 5개였다. 회사 슬랙, 사이드 프로젝트 슬랙, 프론트엔드 커뮤니티 슬랙, 오픈소스 프로젝트 슬랙, 그리고 친구가 "일단 들어와봐" 해서 들어간 스타트업 커뮤니티 슬랙. 알림이 하루 종일 울렸다. 빨간 뱃지가 5개 워크스페이스에서 번갈아가며 떴다. 워크스페이스를 전환하는 것 자체가 컨텍스트 스위칭이었다.

프론트엔드 커뮤니티 슬랙에서 실질적으로 유용한 정보를 얻은 적이 얼마나 되는지 세어봤다. 3개월 동안 실제로 내 업무에 적용한 정보는 하나도 없었다. 가끔 흥미로운 대화가 올라오긴 했지만, 그건 "흥미로운" 것이지 "유용한" 것이 아니었다. 흥미로움과 유용함의 차이는 생각보다 크다. 흥미로운 건 머릿속 대역폭을 차지하면서 아무것도 바꾸지 않는다.

그 스타트업 커뮤니티 슬랙은 더 심했다. "혹시 나중에 기회가 있을 수도 있으니까"라는 이유로 남아 있었는데, 3개월 동안 읽은 메시지가 거의 없었고, 읽어도 내용이 내 상황과 관련이 없었다.

둘 다 나왔다. 회사 슬랙과 사이드 프로젝트 슬랙만 남겼다. 알림이 줄었고, 슬랙을 열 때마다 "어느 워크스페이스부터 확인하지"라는 미세한 의사결정이 사라졌다.

## "혹시 모르니까"라는 함정

도구를 쌓아두게 만드는 핵심 심리가 있다. "혹시 모르니까." 이 슬랙을 나가면 혹시 기회를 놓칠 수 있으니까. 이 뉴스레터를 구독 취소하면 혹시 중요한 정보를 놓칠 수 있으니까. 이 앱을 삭제하면 혹시 다시 깔아야 할 수 있으니까.

"혹시 모르니까"는 두려움이다. 기회를 놓치는 두려움. 근데 기회를 놓치는 것보다 더 위험한 건, 모든 기회를 다 잡으려다가 정작 중요한 한 가지에 집중하지 못하는 거다. 주의력 연구자들이 말하는 "인지적 인내심"이라는 게 있다. 하나의 일에 오래 집중하는 능력. 스마트폰과 소셜 미디어가 이걸 깎아먹는다는 건 이제 상식이 됐지만, 생산성 도구도 같은 일을 한다는 건 잘 모른다. 슬랙 알림이 생산성 도구의 탈을 쓴 집중력 파괴자일 수 있다.

어떤 미니멀리즘 블로거가 의사결정에 대해 이런 말을 했다. "지금 이 결정에 대해 진심으로 흥분되지 않는다면, 거절하라." 도구 선택에도 똑같이 적용된다. 이 앱이 내 워크플로우에 진짜 필수적인가? "있으면 좋을 것 같다" 수준이면 없어도 된다.

## 도구 감사(audit)를 해봤다

올해 초에 전체 도구 스택을 감사해봤다. 핸드폰 앱, 브라우저 북마크, 구독 서비스, 슬랙 채널, VS Code 익스텐션, npm 의존성까지. 기준은 단순했다. "지난 2주 동안 실제로 써서 가치를 얻은 적이 있는가."

결과가 참담했다.

핸드폰 앱 73개 중 매일 쓰는 건 9개. 가끔 쓰는 건 12개. 나머지 52개는 지난 2주간 한 번도 안 열었다. 전부 삭제했다.

뉴스레터 구독이 14개였다. 매주 금요일에 오는 기술 뉴스레터들. 실제로 열어서 읽는 건 3개뿐이었다. 나머지 11개는 받은편지함에 쌓이면서 "안 읽은 메일이 있다"는 미세한 죄책감만 유발했다. 전부 구독 취소했다.

브라우저 탭은 항상 20개 이상 열려 있었다. "나중에 볼 거"라고 열어둔 탭인데, 3일 이상 열려 있는 탭을 나중에 볼 확률은 거의 0이다. 퇴근 전에 탭을 5개 이하로 줄이는 규칙을 만들었다. 나중에 볼 건 Pocket에 저장하고 닫는다. Pocket에서 다시 여는 확률도 높지 않지만, "닫아도 잃어버리지 않는다"는 안전망이 있으면 닫기가 쉬워진다.

## 빈 에디터에서 시작하기

도구 감사의 핵심 원칙은 "추가"가 아니라 "제거"다. 기본값을 "전부 설치"에서 "아무것도 없음"으로 바꾸는 거다. 코드 리팩토링과 같은 원리다. 기존 코드를 다 지우고, 진짜 필요한 것만 다시 작성한다. 도구도 마찬가지다. 전부 치우고, 하나씩 필요할 때만 다시 추가한다.

새 맥북을 셋업할 일이 있었다. 예전이었으면 기존 맥에서 앱과 설정을 전부 마이그레이션했을 거다. 이번에는 안 했다. 빈 상태에서 시작해서 일하다가 필요한 도구만 하나씩 설치했다. 첫 주가 좀 불편했다. "아 이것도 안 깔려 있네" 하면서 설치하는 일이 하루에 두세 번 있었다. 근데 둘째 주부터는 설치할 게 거의 없었다. 진짜 필요한 도구는 첫 주에 다 드러났다. 이전 맥에서 쓰던 앱의 절반 이상이 필요 없었다는 뜻이다.

이 실험에서 배운 건, 불편함이 꼭 나쁜 게 아니라는 거다. 도구가 없어서 불편한 순간이 진짜 필요한 도구를 알려주는 신호다. 불편함 없이 도구를 미리 깔아두면, 필요 없는 것과 필요한 것이 구분되지 않는다.

## npm 의존성도 같은 논리다

프론트엔드 개발자라면 `node_modules` 폴더의 크기를 한 번쯤 보고 놀란 적이 있을 거다. 프로젝트 하나에 패키지가 1,200개. 직접 설치한 건 30개 정도인데 나머지는 의존성의 의존성의 의존성이다.

사이드 프로젝트에서 `package.json`을 정리한 적이 있다. `dependencies`에 23개가 있었는데, 실제로 import해서 쓰는 건 14개였다. 나머지 9개는 한때 시도해보고 안 쓰게 된 라이브러리, 또는 이미 다른 라이브러리에 포함된 기능을 중복 설치한 것들이었다. 9개를 지웠더니 빌드 시간이 8초에서 5초로 줄었다. 번들 사이즈도 120KB 줄었다.

코드에서는 이걸 당연하게 한다. 안 쓰는 코드는 지운다. 안 쓰는 변수는 린터가 경고한다. 근데 도구에 대해서는 안 한다. 안 쓰는 앱, 안 읽는 뉴스레터, 안 보는 슬랙 채널은 린터가 경고해주지 않는다. 직접 감사해야 한다.

## 문제 해결형 도구 vs 행동 생성형 도구

모든 도구가 나쁜 건 아니다. 도구를 두 종류로 구분하면 판단이 쉬워진다.

문제 해결형 도구는 기존에 있던 문제를 해결한다. 구글 맵은 길을 찾는 문제를 해결한다. VS Code는 코드를 작성하는 문제를 해결한다. 깃은 버전 관리 문제를 해결한다. 이런 도구는 내가 하던 행동을 더 효율적으로 만들어준다.

행동 생성형 도구는 새로운 행동을 만들어낸다. 인스타그램을 깔기 전에는 다른 사람의 점심 사진을 스크롤하는 행동이 없었다. 특정 소셜 앱을 깔기 전에는 140자 의견을 읽고 감정적으로 반응하는 행동이 없었다. 이런 도구는 문제를 해결하는 게 아니라, 존재하지 않던 습관을 만들어내서 시간을 먹는다.

도구를 추가하기 전에 "이 도구는 내가 이미 하던 일을 더 잘하게 해주는가, 아니면 안 하던 일을 하게 만드는가"를 물어보면 된다. 후자라면 정말 그 새로운 행동이 내 가치관에 부합하는지 한 번 더 생각할 필요가 있다.

## 정보를 줄여야 생각이 시작된다

도구를 줄이면서 가장 의외였던 변화가 있다. 머릿속이 조용해졌다.

예전에는 항상 뭔가를 소비하고 있었다. 출근길에 팟캐스트, 점심에 유튜브, 퇴근길에 뉴스레터, 저녁에 트위터. 뇌에 입력되는 정보가 쉬는 시간이 없었다. 그러다 도구를 줄이니까 빈 시간이 생겼다. 지하철에서 아무것도 안 하는 시간, 커피를 기다리면서 멍하니 서 있는 시간, 저녁에 소파에 앉아서 천장을 보는 시간.

그 빈 시간에 생각이 올라오기 시작했다. "오늘 짠 그 코드, 이렇게 바꾸면 더 깔끔하지 않을까." "저번에 읽은 리팩토링 패턴, 이번 프로젝트에 적용해볼 수 있겠다." "프로젝트 구조를 이런 식으로 바꾸면 확장성이 좋아지겠다."

신경과학에서 디폴트 모드 네트워크라고 부르는 게 있다. 뇌가 외부 자극 없이 유휴 상태에 있을 때 활성화되는 영역인데, 이 상태에서 창의적인 연결이 일어난다. 샤워 중에 좋은 아이디어가 떠오르는 이유가 이거다. 근데 항상 콘텐츠를 소비하고 있으면 이 네트워크가 작동할 틈이 없다. 도구를 줄이는 건 단순히 시간을 아끼는 게 아니라, 뇌에게 생각할 공간을 돌려주는 거다.

## 불편한 진실 하나

디지털 미니멀리즘에 대해 글을 쓰면 반드시 나오는 반론이 있다. "실시간 정보에서 뒤처지면 어떡하냐." 프론트엔드 개발자로서 이 불안은 특히 크다. 새 프레임워크가 매달 나오고, 라이브러리 생태계가 빠르게 바뀌니까.

근데 솔직하게 돌아보면, 실시간으로 따라가야 하는 정보의 99%는 내 일과 직접적인 관련이 없다. 새로운 자바스크립트 런타임이 나왔다는 뉴스, 어떤 프레임워크가 새 버전을 냈다는 소식, 어떤 라이브러리가 뭘 발표했다는 트윗. 이 중에서 내가 다음 주에 실제로 쓸 정보가 있는가? 거의 없다.

진짜 중요한 건 어차피 걸러져서 온다. 팀 슬랙에서, 기술 뉴스레터에서, 동료와의 대화에서. 나머지는 소음이다. 소음을 소음으로 인식하는 게 첫 번째 단계다.

## 6개월 후

도구를 줄인 지 6개월이 됐다. 핸드폰 앱은 21개, 슬랙 워크스페이스는 2개, VS Code 익스텐션은 11개, 뉴스레터 구독은 3개다. 이전과 비교하면 전부 절반 이하로 줄었다.

생산성이 얼마나 올랐는지 수치로 말하기는 어렵다. 근데 확실한 건 하루가 끝날 때 "오늘 뭐 했지?"라는 자괴감이 줄었다는 거다. 예전에는 하루 종일 바빴는데 한 건 없는 느낌이 자주 있었다. 정보를 소비하느라 바빴던 거지 뭔가를 만들어서 바빴던 게 아니었다.

도구를 줄이는 건 "금욕적으로 살자"는 게 아니다. 기술이 내 가치를 위해 존재해야지, 내가 기술을 위해 존재하면 안 된다는 거다. 모든 도구에 인지 비용이 있다는 걸 인식하고, 그 비용을 감당할 가치가 있는 도구만 남기는 거다. 나머지는 과감하게 치운다.

치우고 나면 처음에는 불안하다. "이거 없으면 어쩌지?" 2주 지나면 안다. 아무 일도 안 일어난다.


금요일 오후 4시, 슬랙에 메시지가 올라왔다. "저는 되는데 스테이징에서 안 되네요." 백엔드 개발자가 보낸 메시지에 프론트 팀 전체가 반응했다. "저도요." "저는 아예 빌드가 안 돼요." 확인해보니 원인은 Node.js 버전이었다. 한 명은 18, 한 명은 20, 한 명은 21. `package-lock.json`의 lockfileVersion이 달라서 `npm ci`가 실패하고, 특정 패키지의 네이티브 바이너리가 버전에 따라 다르게 빌드됐다. "nvm으로 맞추면 되잖아"라고 할 수 있는데, 프로젝트가 3개이고 각각 Node 버전이 다르면 매번 `nvm use`를 치는 것도 까먹기 쉽다.

이 문제를 해결하는 데 2시간이 걸렸다. 스프린트 마지막 날에 배포 대신 환경 맞추기로 시간을 날린 거다. 그 다음 주 회고에서 누군가가 "Docker 쓰면 이런 거 안 생기지 않나요?"라고 했다.

## "내 컴퓨터에서는 되는데"의 근본 원인

이 문장이 나올 때 원인은 거의 정해져 있다. Node 버전, OS 차이로 인한 네이티브 바이너리 문제, 환경변수 누락, 로컬에만 있는 설정 파일. 전부 "환경이 다르다"는 한 문장으로 요약된다.

Docker는 이 문제를 컨테이너라는 격리된 환경으로 해결한다. "Node 20이 설치되어 있고, 이 프로젝트의 코드가 들어 있고, npm install이 완료된 상태"를 Dockerfile이라는 텍스트 파일로 정의한다. 이 파일만 있으면 누가, 어디서, 어떤 OS에서 실행하든 같은 환경이 만들어진다.

```dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["npm", "run", "dev"]
```

처음에 이 파일을 봤을 때 "이게 끝이야?" 싶었다. 근데 이 6줄이 "내 컴퓨터에서는 되는데"를 없애준다. 팀원 전원이 정확히 같은 Node 20 Alpine 이미지 위에서 개발한다. lockfileVersion이 다를 수가 없다.

`package.json`을 소스 코드보다 먼저 복사하는 이유가 있다. Docker는 각 명령어를 레이어로 캐싱하는데, 소스 코드가 바뀌어도 `package.json`이 안 바뀌었으면 `npm ci` 레이어를 캐시에서 가져온다. 매번 의존성을 새로 설치하지 않으니까 빌드가 훨씬 빠르다. 이걸 모르고 `COPY . .`을 맨 위에 놓으면 코드 한 줄 바꿀 때마다 npm ci가 돌아간다. 처음에 이 실수를 했는데, 빌드가 3분씩 걸려서 뭐가 문제인지 한참 찾았다.

## docker-compose로 백엔드까지 한 방에 띄우기

프론트엔드만 Docker에 넣으면 효과가 반감된다. 진짜 편해지는 건 백엔드 API, 데이터베이스, Redis까지 한 번에 띄울 때다.

```yaml
services:
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - ./frontend/src:/app/src
      - ./frontend/public:/app/public
    environment:
      - NEXT_PUBLIC_API_URL=http://localhost:4000
    depends_on:
      - api

  api:
    build:
      context: ./backend
    ports:
      - "4000:4000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/myapp
      - REDIS_URL=redis://redis:6379
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:
```

`docker-compose up` 하나로 전부 뜬다. 새 팀원이 합류해도 Docker Desktop 설치하고 이 명령어 하나만 치면 된다. PostgreSQL이 로컬에 있는지, Redis 설정은 어떻게 하는지 신경 쓸 필요 없다.

이전 프로젝트에서는 신규 입사자 온보딩에 반나절이 걸렸다. "Node 버전 맞추고, Postgres 설치하고, .env 파일 받아서 넣고, Redis도 깔아야 하고..." Docker 도입 후에는 15분이면 전체 개발 환경이 돌아갔다. 이것만으로도 Docker를 배운 보람이 있었다.

## 1.2GB에서 180MB로: 멀티 스테이지 빌드

개발용 Dockerfile은 간단하다. 문제는 프로덕션이다. 처음에 프로덕션 이미지를 빌드했더니 1.2GB가 나왔다. `node_modules` 전체가 이미지에 들어가 있었다. CI/CD에서 이미지 푸시하는 데만 4분씩 걸렸다.

멀티 스테이지 빌드로 해결했다. 아이디어는 간단하다. 빌드에 필요한 것(소스 코드, 전체 node_modules)은 1단계에서만 쓰고, 2단계에서는 빌드 결과물만 가져간다.

```dockerfile
# Stage 1: 빌드
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: 실행
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

COPY --from=builder /app/next.config.js ./
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

EXPOSE 3000
CMD ["node", "server.js"]
```

Next.js의 `standalone` 출력 모드가 핵심이다.

```javascript
// next.config.js
module.exports = {
  output: "standalone",
};
```

이 한 줄을 추가하면 Next.js가 `node_modules`에서 실제로 필요한 파일만 추출해서 `.next/standalone` 디렉토리에 넣어준다. 결과적으로 이미지 크기가 1.2GB에서 180MB로 줄었다. CI/CD 시간도 4분에서 45초로 단축됐다. 배포 속도가 빨라지니까 핫픽스 대응도 빨라졌다.

## macOS 볼륨 마운트: 아무도 안 알려주는 함정

Docker를 쓰면서 가장 고통스러웠던 삽질이 이거다. macOS에서 Docker 볼륨 마운트가 느리다. 엄청나게 느리다. 아무도 미리 경고해주지 않았다.

처음에 프로젝트 전체를 볼륨으로 마운트했다.

```yaml
volumes:
  - ./frontend:/app
```

두 가지 문제가 터졌다. 첫째, 로컬의 macOS용 `node_modules`가 컨테이너의 Linux 환경을 덮어쓴다. `sharp`, `esbuild` 같은 네이티브 바이너리 패키지가 전부 에러를 뱉었다. 플랫폼이 다르니까 당연한 건데, 처음에는 원인을 몰라서 한참 헤맸다.

둘째, Hot Module Replacement가 안 됐다. Docker 볼륨은 기본적으로 macOS의 파일 시스템 이벤트(inotify)를 전달하지 않는다. 코드를 수정해도 컨테이너가 변경을 감지하지 못한다. 파일을 저장하고, 브라우저를 새로고침하고, "왜 안 바뀌지?" 하면서 20분을 날렸다.

해결은 두 단계였다. 먼저 마운트 범위를 소스 코드만으로 제한한다.

```yaml
volumes:
  - ./frontend/src:/app/src
  - ./frontend/public:/app/public
```

`node_modules`는 마운트하지 않고 컨테이너 내부 걸 쓰게 한다. 그러면 네이티브 바이너리 문제가 해결된다.

HMR 문제는 webpack의 polling 모드로 해결했다.

```javascript
// next.config.js
module.exports = {
  webpack: (config) => {
    config.watchOptions = {
      poll: 1000,
      aggregateTimeout: 300,
    };
    return config;
  },
};
```

1초마다 파일 변경을 체크하는 거라 CPU를 좀 더 먹지만, 확실하게 동작한다. 이 두 가지를 해결하는 데 반나절이 걸렸다. 블로그나 튜토리얼에서 이 문제를 제대로 다루는 곳이 거의 없어서 더 오래 걸렸다.

`.dockerignore` 파일도 빼먹으면 안 된다. 이걸 설정 안 하면 `COPY . .` 할 때 `node_modules`, `.next`, `.git` 전부가 빌드 컨텍스트에 포함된다. Docker 데몬에 컨텍스트를 보내는 것만 30초씩 걸린 적이 있다.

```
node_modules
.next
.git
*.md
```

## Docker가 과하다는 것을 인정하는 것도 실력이다

여기까지 읽으면 "Docker 좋으니까 무조건 쓰자"로 들릴 수 있는데, 솔직히 말하면 대부분의 프론트엔드 프로젝트에서 Docker는 과하다.

프론트만 단독으로 개발하고, API는 mock으로 대체하고, Vercel이나 Netlify로 배포하는 환경이라면 Docker를 쓸 이유가 거의 없다. 이런 플랫폼은 프레임워크를 자동 감지하고, 빌드하고, 배포하고, 스케일링까지 해준다. 설정이 zero에 가깝다. 프리뷰 URL, 자동 배포, 롤백까지 컨테이너 오케스트레이션의 복잡함 없이 다 된다. 이런 환경에서 Docker를 도입하면 복잡성만 늘어난다. 모던 프론트엔드 배포 플랫폼이 인프라 관심사를 완전히 추상화해버린 시대인 거다.

Docker가 진짜 필요한 순간은 명확하다.

1. **백엔드와 함께 로컬에서 돌려야 할 때.** API, DB, Redis를 한 번에 띄워야 하는 상황.
2. **팀원 간 환경 차이가 반복적으로 문제를 일으킬 때.** "내 컴퓨터에서는 되는데"가 스프린트마다 나오는 상황.
3. **AWS, GCP에 직접 배포할 때.** Vercel을 못 쓰는 사정이 있는 경우.
4. **CI/CD 파이프라인에서 빌드 환경을 일관되게 유지해야 할 때.**

이 네 가지 중 하나라도 해당되면 Docker를 배울 가치가 충분하다. 하나도 해당 안 되면 지금 당장은 안 배워도 된다.

한 엔지니어링 블로그에서 읽은 글이 인상적이었다. 도구 도입의 기준은 "이 도구가 멋있는가"가 아니라 "이 도구가 우리 팀의 구체적인 문제를 해결하는가"여야 한다고. Docker도 마찬가지다. 금요일 오후에 "내 컴퓨터에서는 되는데"로 2시간을 날려본 적이 있다면, 그때가 Docker를 배울 때다. 그런 경험이 없다면, Dockerfile 작성법과 docker-compose 기본 사용법 정도만 알아두고 넘어가도 충분하다. Kubernetes나 Docker Swarm 같은 오케스트레이션은 프론트엔드 범위를 한참 벗어난다. 적어도 지금은.



3개월 전에 팀에 새로운 개발자가 합류했다. 첫 주에 온보딩을 진행하면서 "프로젝트 관련 문서는 Confluence에 있으니까 한번 읽어봐"라고 말했다. 이틀 뒤에 그 개발자가 DM을 보냈다. "Confluence에 문서가 되게 많은데, 어떤 걸 먼저 읽어야 할지 모르겠어요. 그리고 몇 개 읽어봤는데 현재 코드랑 다른 것 같아서요."

마음이 찔렸다. 맞는 말이었다. Confluence에 문서가 200개 넘게 있었지만, 최근 6개월 내에 업데이트된 건 10개도 안 됐다. 나머지는 2년 전 아키텍처를 설명하고 있거나, 이미 삭제된 기능의 스펙이거나, 누군가 "나중에 정리하겠다"고 만들어놓고 제목만 있는 빈 페이지들이었다.

우리 팀의 Confluence는 문서 저장소가 아니라 무덤이었다.

## 왜 문서는 무덤이 되는가

원인을 분석해보면 결국 하나로 수렴한다. **문서의 종류를 구분하지 않았다.** 모든 문서를 "문서"라는 하나의 카테고리에 넣고, 같은 방식으로 쓰고, 같은 곳에 보관했다. 그러니까 기술 스펙 문서 옆에 회의록이 있고, 온보딩 가이드 옆에 브레인스토밍 메모가 있었다. 찾는 데만 10분이 걸리니까, 차라리 옆 사람한테 물어보는 게 빠르다.

Divio라는 회사에서 만든 문서화 프레임워크가 이 문제를 정확히 짚는다. 핵심 통찰은 이거다. **"문서"라는 건 없다. 4가지 종류의 서로 다른 것이 있을 뿐이다.**

### 1. 튜토리얼 (Tutorial) — 학습 중심

처음 접하는 사람을 위한 가이드. "이 프로젝트에 처음 온 사람이 따라 하면 동작하는 결과를 볼 수 있는 문서." 핵심은 **해보는 것**이다. 설명보다 행동이 우선이다. "왜 이렇게 하는지"보다 "이렇게 하면 이렇게 된다"에 집중한다.

우리 팀에서 이 카테고리에 해당하는 건 "로컬 개발 환경 세팅 가이드"와 "첫 번째 PR 올리기" 같은 문서다. 새 개발자가 첫날 따라 하면 로컬에서 프로젝트가 돌아가야 한다. 여기서 Docker의 네트워킹 모델을 설명하거나 Webpack 설정의 역사를 서술하면 안 된다. 그냥 `pnpm install` 치고, `pnpm dev` 치고, `localhost:3000`이 뜨면 성공이라는 것만 전달하면 된다.

### 2. 하우투 가이드 (How-to) — 작업 중심

특정 작업을 완수하기 위한 레시피. "API 엔드포인트 추가하는 법", "새 컴포넌트를 디자인 시스템에 등록하는 법", "스테이징 환경에 배포하는 법". 튜토리얼과 다른 점은, 이미 기본을 아는 사람이 보는 거다. "이걸 어떻게 하지?"라는 질문에 답하는 문서.

이게 가장 실용적이면서도 가장 잘 안 쓰이는 종류다. 왜냐하면, 이걸 쓸 수 있는 사람은 이미 하는 방법을 알고 있어서 문서로 남길 동기가 약하다. "나는 알고 있으니까 굳이 안 써도 되지 않나?" 근데 이 문서가 없으면, 매번 누군가가 물어볼 때마다 구두로 설명해야 한다. 같은 설명을 3번 이상 하고 있으면, 그건 문서가 없다는 신호다.

### 3. 레퍼런스 (Reference) — 정보 중심

API 문서, 컴포넌트 props 목록, 환경 변수 목록, 에러 코드 목록 같은 것. 설명이 아니라 사실의 나열이다. 사전과 같다. 처음부터 끝까지 읽는 게 아니라, 필요할 때 찾아보는 거다.

이건 자동 생성이 가능한 영역이 많다. TypeScript 타입 정의에서 컴포넌트 props 문서를 뽑아내거나, Swagger/OpenAPI에서 API 레퍼런스를 생성하거나. 자동 생성의 좋은 점은 코드와 문서가 동기화된다는 거다. 수동으로 작성한 레퍼런스는 코드가 바뀌면 거짓말이 된다. 그 거짓말 문서가 Confluence 무덤의 주요 거주자다.

### 4. 설명 (Explanation) — 이해 중심

"왜 이렇게 했는지"를 다루는 문서. 아키텍처 결정 기록(ADR), 기술 선택의 배경, 특정 패턴을 채택한 이유. 시간이 지나도 가치가 유지되는 유일한 종류의 문서다.

6개월 전에 쓴 "왜 우리가 CSS Modules 대신 Tailwind를 선택했는가" 문서는 지금도 유효하다. Tailwind 버전이 올라가고 설정이 바뀌어도, 선택의 배경은 변하지 않으니까. 새로 온 개발자가 "왜 Tailwind 쓰는 거예요?"라고 물었을 때, 그 문서 링크 하나로 30분짜리 대화를 대체할 수 있다.

## 3주를 아낀 한 장의 문서

이 분류를 알기 전에, 우연히 좋은 문서를 하나 쓴 적이 있다. 지금 돌이켜보면 "설명" 카테고리에 해당하는 문서였다.

프로젝트의 인증 플로우가 복잡했다. OAuth + 자체 토큰 + 리프레시 토큰 + 세션 관리가 여러 서비스에 걸쳐 돌아가고 있었다. 코드만 봐서는 전체 흐름이 안 보였다. 시퀀스 다이어그램 없이는 이해가 불가능한 구조. 내가 이걸 파악하는 데 2주가 걸렸다.

2주 동안 삽질한 게 아깝기도 하고, 다시는 이 고통을 겪고 싶지 않아서 문서를 썼다. 인증 플로우의 전체 그림, 각 서비스의 역할, 토큰이 언제 발급되고 언제 갱신되고 언제 만료되는지, edge case(토큰 갱신 중 다른 탭에서 요청이 오면?), 그리고 왜 이런 구조가 됐는지의 히스토리.

3개월 뒤에 그 문서가 빛을 발했다. 새로 합류한 백엔드 개발자가 인증 관련 수정을 해야 했는데, 그 문서를 읽고 하루 만에 전체 플로우를 파악했다. 내가 2주 걸린 걸 하루 만에. 그리고 또 3개월 뒤에 프론트엔드 개발자가 합류했을 때도 같은 일이 벌어졌다. 대략 계산하면, 그 문서 하나가 최소 3주의 시간을 아꼈다. 내가 문서 쓰는 데 든 시간은 반나절이었다.

## Julia Evans의 교훈: 복잡한 걸 단순하게

Julia Evans라는 개발자가 있다. 이 사람은 기술 블로그와 zine(일종의 미니 만화 가이드)으로 유명하다. DNS 동작 원리, 디버깅 기법, 시스템 콜 같은 어려운 주제를 놀라울 정도로 쉽게 설명한다.

Evans의 접근법에서 배울 게 있다. 그는 "지식의 빈틈을 채운다"는 철학을 갖고 있다. 사람들이 실무에서 매일 마주치지만 제대로 설명된 적 없는 것들을 찾아서, 그걸 설명한다. 이론적으로 완벽한 설명이 아니라, 실무자가 "아, 그거 그렇게 되는 거였어?"라고 느끼는 수준의 설명.

이걸 팀 문서에 적용하면 이렇다. 모든 걸 문서화하려고 하면 실패한다. 대신, **팀에서 같은 질문이 반복되는 것**을 관찰한다. "스테이징 배포는 어떻게 해요?" "이 API의 에러 코드가 뭐뭐 있어요?" "이 컴포넌트는 언제 쓰는 거예요?" 이런 질문이 3번 이상 나오면, 거기에 문서가 필요하다는 뜻이다.

Evans처럼 복잡한 걸 단순하게 만드는 핵심은 **독자를 명확히 하는 것**이다. "이 문서를 읽는 사람은 누구인가? 그 사람이 이미 알고 있는 것은 뭔가? 이 문서를 읽고 나서 할 수 있어야 하는 것은 뭔가?" 이 세 가지만 정하면, 문서의 범위와 깊이가 자연스럽게 결정된다.

## 문서를 쓰는 건 이기적인 행위다

사실, 내가 문서를 쓰는 가장 큰 동기는 이타심이 아니다. 이기심이다.

**미래의 내가 첫 번째 독자다.** 6개월 뒤의 나는 지금 작성한 코드의 맥락을 다 까먹는다. 이건 확실하다. 왜 이 라이브러리를 골랐는지, 왜 이 아키텍처를 택했는지, 왜 이 워크어라운드를 넣었는지. 코드에 주석을 달아도 한계가 있다. 주석은 "무엇을"은 설명하지만 "왜"를 설명하기 어렵다. "왜"를 담는 건 문서의 영역이다.

**설명하면 이해가 깊어진다.** 뭔가를 문서로 정리하다 보면, 내가 제대로 이해하지 못한 부분이 드러난다. "이 부분은... 음... 그냥 이렇게 되는 건데..." 이런 순간이 오면, 그건 내 이해에 구멍이 있다는 뜻이다. 문서를 쓰기 위해 그 구멍을 채우는 과정이, 결국 나의 역량을 높이는 과정이다.

**질문을 비동기로 처리할 수 있다.** "이거 어떻게 해요?"라는 DM이 올 때마다 15분씩 설명하는 대신, 문서 링크를 보내면 된다. 15분이라는 시간도 시간이지만, 더 큰 문제는 컨텍스트 스위칭이다. 집중해서 코드를 짜고 있는데 질문이 오면, 답변을 하고 다시 원래 작업으로 돌아오는 데 추가 시간이 든다. 문서가 있으면 이 비용이 사라진다.

## Confluence 무덤을 살리는 법

팀의 문서 문화를 한 번에 바꾸기는 어렵다. 근데 몇 가지를 실천하면서 조금씩 나아졌다.

**만료일을 정한다.** 모든 문서에 "이 문서의 유효 기간"을 명시한다. 6개월이면 6개월, 1년이면 1년. 유효 기간이 지나면 리뷰하고, 여전히 유효하면 기간을 연장하고, 아니면 아카이브한다. 이것만으로도 무덤화를 상당히 막을 수 있다.

**문서를 코드 리뷰에 포함시킨다.** 새로운 기능의 PR에 관련 문서 업데이트가 포함되어 있는지 확인한다. PR 템플릿에 "관련 문서 업데이트 여부" 체크리스트를 넣었다. 처음엔 귀찮다고 했지만, 3개월 지나니까 습관이 됐다.

**검색 가능하게 만든다.** 문서가 100개여도 찾을 수 있으면 괜찮다. 일관된 제목 규칙, 태그, 분류 체계를 잡는다. Divio 프레임워크대로 "튜토리얼", "하우투", "레퍼런스", "설명" 네 폴더로 나누는 것만으로도 체감이 달라진다.

**작게 시작한다.** 전체 프로젝트를 문서화하겠다는 야심찬 계획은 실패한다. 대신, 이번 주에 내가 3번 이상 구두로 설명한 것 하나를 문서로 만든다. 다음 주에 또 하나. 한 달이면 4개, 1년이면 50개가 된다. 그 50개가 팀의 운영 방식을 바꾼다.

## 아무도 안 읽는 문서

그래도 현실적으로, 아무도 안 읽는 문서가 있다. 공들여 쓴 아키텍처 문서를 올렸는데 리액션이 0개인 경험. "다들 바쁘니까 나중에 읽겠지"라고 스스로 위안했지만, 3개월이 지나도 조회수가 5다. 그중 3은 내가 들어간 거다.

이런 경험이 반복되면 문서 쓰는 의욕이 떨어지는 게 당연하다. 근데 중요한 건, 그 문서가 필요한 순간은 예측할 수 없다는 거다. 장애가 터졌을 때, 새 팀원이 왔을 때, 6개월 뒤에 "이거 왜 이렇게 되어 있지?" 하는 순간에 그 문서가 빛난다. 평소에는 잠자고 있지만, 필요할 때 깨어나는 보험 같은 거다.

그래서 나는 아무도 안 읽을 거라는 걸 알면서도 문서를 쓴다. 미래의 나를 위해, 아직 합류하지 않은 팀원을 위해, 새벽 3시에 장애가 터졌을 때 당황하지 않기 위해. 그리고 한 가지 더, 글로 정리하는 과정에서 내 생각이 명확해지기 때문에.

아무도 안 읽는 문서라도, 쓰는 행위 자체가 가치 있다. 근데 솔직히, 누가 읽으면 더 좋긴 하다.


Edge Runtime이 좋다는 건 알겠다. 사용자와 가까운 CDN 엣지 노드에서 코드가 실행되니까 레이턴시가 줄어든다. Cold start도 Node.js 서버리스 함수보다 빠르다. 그래서 API Route 하나를 Edge로 바꿔봤다가, 생각보다 많은 것이 안 되는 걸 알았다.

## Edge Runtime ≠ Node.js

Edge Runtime은 Node.js가 아니다. V8 엔진 위에서 돌아가지만, 브라우저의 Web API에 가까운 환경이다. Node.js의 코어 모듈을 쓸 수 없다.

Next.js에서 Edge Runtime을 쓰려면:

```typescript
// app/api/hello/route.ts
export const runtime = 'edge';

export async function GET() {
  return new Response('Hello from Edge');
}
```

이 한 줄(`export const runtime = 'edge'`)이 실행 환경을 완전히 바꾼다.

## 안 되는 것들

**1. Node.js 네이티브 모듈**

`fs`, `path`, `crypto`의 일부, `child_process`, `net` — 전부 안 된다. 파일 시스템이 없으니 `fs.readFile`은 당연히 안 되고, `path.resolve`도 안 된다.

```typescript
// Edge에서 이건 에러
import fs from 'fs';
import path from 'path';
```

**2. 대부분의 npm 패키지**

내부적으로 Node.js API를 쓰는 패키지는 다 안 된다. 놀라운 건 꽤 많은 패키지가 어딘가에서 Node.js API를 쓰고 있다는 것이다.

실제로 겪은 사례:
- `jsonwebtoken` — 내부에서 Node.js `crypto` 사용. 대신 `jose` 라이브러리를 써야 한다
- `bcrypt` — C++ 네이티브 바인딩. 대신 `bcryptjs`(순수 JS)를 써야 한다
- `sharp` — 이미지 처리. Edge에서 동작하지 않음

```typescript
// Node.js Runtime
import jwt from 'jsonwebtoken';
const token = jwt.sign(payload, secret);

// Edge Runtime
import { SignJWT } from 'jose';
const token = await new SignJWT(payload)
  .setProtectedHeader({ alg: 'HS256' })
  .sign(new TextEncoder().encode(secret));
```

`jose`는 Web Crypto API를 기반으로 만들어져서 Edge에서 잘 동작한다.

**3. 실행 시간 제한**

Vercel Edge Functions는 기본 30초 타임아웃이 있고, Cloudflare Workers 무료 플랜은 10ms CPU 시간 제한이 있다. 무거운 연산이나 느린 외부 API를 호출하면 타임아웃에 걸린다.

**4. 전역 상태/메모리**

Edge 함수는 요청마다 새로 실행될 수 있고, 같은 인스턴스가 재활용될 수도 있다. 전역 변수에 의존하면 예측 불가능한 동작이 된다. 인메모리 캐시? 안 된다.

## 돌아가는 것들

**1. Web 표준 API**

`fetch`, `Request`, `Response`, `URL`, `URLSearchParams`, `Headers`, `TextEncoder`, `TextDecoder`, `crypto.subtle` — Web 표준 API는 다 된다.

```typescript
export const runtime = 'edge';

export async function GET(request: Request) {
  const url = new URL(request.url);
  const query = url.searchParams.get('q');

  const response = await fetch(`https://api.example.com/search?q=${query}`);
  const data = await response.json();

  return Response.json(data, {
    headers: { 'Cache-Control': 'public, max-age=60' },
  });
}
```

**2. KV/D1 같은 엣지 스토리지**

Cloudflare의 KV, D1, R2 같은 엣지 네이티브 스토리지는 당연히 잘 동작한다. Vercel도 Edge Config, KV를 제공한다.

```typescript
// Vercel KV
import { kv } from '@vercel/kv';

export const runtime = 'edge';

export async function GET(request: Request) {
  const cached = await kv.get('popular-posts');
  if (cached) return Response.json(cached);

  const posts = await fetchPopularPosts();
  await kv.set('popular-posts', posts, { ex: 300 }); // 5분 캐시
  return Response.json(posts);
}
```

## 언제 Edge를 쓰고, 언제 Node.js를 쓰나

모든 걸 Edge로 바꿀 필요는 없다. 오히려 대부분의 API Route는 Node.js Runtime이 맞다.

**Edge가 적합한 경우:**
- 인증 토큰 검증 (미들웨어)
- 리다이렉트/리라이트 로직
- A/B 테스트 분기
- 지역 기반 콘텐츠 제공
- 단순한 API 프록시

**Node.js가 적합한 경우:**
- 데이터베이스 직접 연결 (대부분의 DB 드라이버가 Node.js 전용)
- 파일 처리
- 무거운 연산
- Node.js 전용 라이브러리에 의존하는 로직

경험적으로, 미들웨어는 거의 항상 Edge가 맞고, API Route는 대부분 Node.js가 안전하다. Edge Runtime의 제약을 이해하고 적재적소에 쓰는 게 포인트다. 전부 Edge로 가겠다는 건 욕심이다.



입사 초기에 PR을 올렸다. 일주일간 공들여 만든 기능이었다. 기존 코드를 분석하고, 팀 컨벤션을 따르려고 노력했고, 테스트도 꼼꼼히 작성했다.

리뷰가 달렸다. 코멘트가 14개. 대부분 수긍할 수 있는 지적이었는데, 하나가 걸렸다.

"이 접근 자체가 잘못됐습니다. 처음부터 다시 설계해야 할 것 같아요."

그 한 줄에 일주일의 노력이 부정당한 느낌이었다. 머리로는 코드에 대한 피드백이라는 걸 알지만, 감정은 "나"에 대한 평가로 받아들였다.

## 코드 = 나?

개발자에게 코드는 자기 표현의 수단이다. 시간과 고민을 쏟아서 만든 결과물이니까, 그게 부정되면 자신이 부정당하는 것 같다. 특히 경험이 적을수록 코드와 자아를 분리하기 어렵다.

시간이 지나면서 깨달은 건, 코드 리뷰에서 상처받는 건 실력 문제가 아니라 관점의 문제라는 거다. 코드는 "내 작품"이 아니라 "팀의 산출물"이다. 리뷰어가 "이 접근이 잘못됐다"고 할 때, 그건 더 나은 방향을 찾자는 제안이지 나를 깎아내리는 게 아니다.

이걸 머리로 이해하는 것과 감정으로 받아들이는 건 다른 문제다. 솔직히, 지금도 날카로운 코멘트를 보면 잠깐 움찔한다.

## 상처가 됐던 패턴들

돌아보면, 내용보다 톤이 문제인 경우가 많았다.

**"왜 이렇게 했어요?"** 이 질문은 두 가지로 읽힌다. 순수한 궁금함일 수도 있고, "이러면 안 되는 거 아시죠?"의 완곡한 표현일 수도 있다. 텍스트에서는 뉘앙스가 전달되지 않는다. 나중에 그 리뷰어와 대화해보니 진짜 궁금해서 물어본 거였다. 그런데 텍스트로 읽을 때는 비난으로 느꼈다.

**수정 요청만 있고 이유가 없는 코멘트.** "이거 바꿔주세요." 왜? 뭐가 문제인지 모르니까 배울 수도 없고, 단순히 취향 차이인지 실질적인 문제인지 판단할 수도 없다. 이런 코멘트를 받으면 "시키는 대로 해야 하는 건가" 하는 무력감이 든다.

**공개 채널에서의 지적.** PR 코멘트는 팀 전체가 본다. 기초적인 실수를 공개적으로 지적당하면 창피하다. 이건 리뷰어가 의도한 게 아니라 코드 리뷰라는 시스템의 특성인데, 그래도 감정은 어쩔 수 없다.

## 내가 바뀐 것

**코멘트를 바로 반응하지 않는다.** 날카로운 코멘트를 보면 일단 닫는다. 30분 뒤에 다시 읽으면 감정이 빠지고 내용만 보인다. 즉각적으로 반응하면 방어적인 답변을 쓰게 된다. "그건 이래서 이렇게 한 건데요"라는 정당화. 30분만 기다리면 "아, 맞네. 이렇게 바꾸겠습니다"로 끝날 수 있다.

**모르면 물어본다.** "왜 이렇게 했어요?"에 대해 "이런 이유로 이렇게 했는데, 더 나은 방법이 있을까요?"라고 묻는다. 방어 대신 질문. 이러면 대화가 열리고, 대부분의 리뷰어는 기꺼이 설명해준다.

**리뷰어에게 맥락을 먼저 제공한다.** PR 설명에 "왜 이 접근을 선택했는지"를 적어둔다. 리뷰어가 의사결정 배경을 알면, "왜 이렇게 했어요?"라는 질문 자체가 줄어든다.

## 리뷰어가 됐을 때

내가 리뷰를 할 때는, 받는 입장에서 상처가 됐던 패턴을 의식적으로 피하려고 한다.

"이거 바꿔주세요" 대신 "이렇게 하면 ~한 이유로 더 좋을 것 같아요". 이유를 붙이면 지시가 아니라 제안이 된다.

잘 된 부분에도 코멘트를 남긴다. "이 부분 깔끔하게 처리했네요" 한 줄이면 된다. 문제만 지적하면 코드 리뷰가 "틀린 곳 찾기"가 되는데, 긍정 피드백이 섞이면 "같이 더 좋은 코드를 만드는 과정"이 된다.

코드 리뷰는 기술적 활동이지만, 결국 사람과 사람 사이의 커뮤니케이션이다. 좋은 코드를 만드는 것만큼, 서로의 감정을 존중하는 것도 중요하다. 이걸 깨닫는 데 꽤 오래 걸렸다.



작년 12월, 결제 모듈에서 복잡한 상태 관리 버그를 잡고 있었다. 카드 결제에서 포인트 적용, 쿠폰 적용, 최종 금액 계산으로 이어지는 플로우에서 특정 순서로 조작하면 금액이 음수가 되는 버그. 상태가 여러 곳에서 업데이트되면서 꼬이는 문제였다.

오후 2시 반에 시작해서 4시간 30분을 자리에 앉아 있었다. console.log를 찍고 결과를 보는데, 5분 전에 뭘 확인하려고 이걸 찍었는지 까먹는다. 브레이크포인트를 걸어놓고 딴 생각을 하고 있다. useReducer로 관리하는 상태의 흐름을 따라가다가 중간에 끊긴다. 퇴근할 때 "나 정말 바보인 건가" 싶었다.

다음 날 아침 9시 반. 같은 코드를 열었다. 15분 만에 원인을 찾았다. useEffect 안에서 setState를 호출할 때 이전 상태를 참조하는 방식이 잘못되어 있었다. 콜백 형태로 바꾸니까 해결. 어제 4시간 반 동안 못 본 걸 오늘 15분 만에 봤다.

같은 사람, 같은 코드, 같은 버그. 시간만 달랐다.

## 시간 관리 시스템의 전제가 잘못됐다

포모도로, GTD, 아이젠하워 매트릭스, 세컨드 브레인. 전부 시도해봤고, 전부 2주 안에 흐지부지됐다. 이 시스템들의 공통점이 있다. "시간이 균질하다"는 전제 위에서 작동한다는 거다. 오전 10시의 1시간과 오후 4시의 1시간이 같은 가치를 가진다는 전제. 근데 실제로는 전혀 다르다. 오후 3시의 나와 오전 10시의 나는 다른 개발자다.

습관에 대해 많이 쓰는 한 저자가 비슷한 맥락의 말을 한 적이 있다. 좋은 습관을 만드는 핵심은 의지력이 아니라 환경 설계라고. 의지력에 의존하면 실패한다. 환경을 바꿔서 좋은 행동이 자연스럽게 나오게 만들어야 한다고. 이걸 에너지에 적용하면, "의지력으로 오후 3시에 집중하자"가 아니라 "오후 3시에는 집중이 필요 없는 일을 배치하자"가 된다.

## 30일 에너지 로그

이 경험 이후에 에너지 로그를 찍기로 했다. 근데 2주가 아니라 30일을 했다. 2주는 패턴을 보기에 짧다고 판단했다. 월요일과 금요일의 에너지가 다르고, 월초와 월말이 다르니까.

방법은 단순했다. 매 시간 정각에 알람을 걸고, 그 순간의 집중도를 1~5점으로 기록했다. 노션 테이블에 날짜, 시간, 점수, 그리고 직전 1시간 동안 한 일을 적었다. 1점은 "눈이 감긴다", 2점은 "코드가 안 읽힌다", 3점은 "보통", 4점은 "집중 잘 된다", 5점은 "몰입 상태, 시간 가는 줄 모른다".

처음 며칠은 점수를 매기는 것 자체가 귀찮았다. 알람이 울리면 "아 또" 하면서 대충 찍었다. 근데 5일째부터 루틴이 됐다. 알람이 울리면 반사적으로 노션을 열게 됐다.

30일치 데이터를 평균 내봤다. 놀라운 패턴이 보였다.

## 피크 타임은 아침이 아니었다

보통 "아침에 집중이 잘 된다"고 알려져 있다. 딥 워크 개념을 제시한 사람도 아침 시간대를 강조한다. 근데 내 데이터는 달랐다.

- **오전 9시~9시 반**: 평균 3.4점. 생각보다 낮다.
- **오전 9시 반~11시**: 평균 4.3점. 피크.
- **오전 11시~12시**: 평균 3.8점. 살짝 하강.
- **오후 1시~2시**: 평균 1.9점. 바닥.
- **오후 2시~3시**: 평균 2.7점. 회복 중.
- **오후 3시~4시**: 평균 3.5점. 의외로 괜찮다.
- **오후 4시~5시**: 평균 3.1점. 하강.
- **오후 5시~6시**: 평균 2.4점. 퇴근 모드.

핵심 발견: 피크 타임이 9시가 아니라 9시 반이었다. 출근해서 자리에 앉고 슬랙 확인하고 커피 마시고 어제 하던 일의 맥락을 복구하는 데 30분이 걸렸다. 뇌가 "일 모드"로 전환되는 시간이 필요했다. 아침에 출근하자마자 어려운 코딩을 시작하는 건 준비운동 없이 전력 질주하는 것과 같았다.

또 하나. 오후 3시~4시의 점수가 생각보다 높았다. 보통 오후는 전부 안 좋을 거라고 예상했는데, 점심 식곤증에서 회복된 후 작은 피크가 하나 더 있었다. 이걸 "오후 미니 피크"라고 부르기로 했다.

## 에너지를 깎아먹는 것들

30일치 데이터에서 에너지 점수에 가장 큰 영향을 미치는 변수도 보였다.

**미팅 직후 에너지 드랍**: 미팅이 끝난 직후 1시간의 평균 점수가 2.6이었다. 미팅이 없는 같은 시간대의 평균인 3.8보다 1.2점 낮았다. 30분짜리 미팅이든 1시간짜리 미팅이든, 끝난 후의 에너지 드랍은 비슷했다. 미팅 자체의 길이보다 컨텍스트 스위칭 비용이 더 큰 거다.

이건 숫자로 보니까 더 명확했다. 미팅은 시간만 먹는 게 아니라 에너지를 불균형적으로 소모한다. 1시간짜리 미팅의 실제 비용은 1시간이 아니라, 미팅 1시간 + 회복 시간 30분~1시간이다. 미팅 전에 "이거 마무리하고 가야지" 하면서 허둥대는 10분까지 합치면, 1시간 미팅의 실제 비용은 2시간에 가깝다.

**점심 메뉴의 영향**: 이건 좀 부끄럽지만 데이터가 명확했다. 탄수화물 많은 점심(돈까스, 볶음밥, 파스타)을 먹은 날의 오후 1시~2시 평균이 1.5점이었다. 가벼운 점심(샐러드, 포케)을 먹은 날은 2.3점이었다. 0.8점 차이. 작아 보이지만 체감으로는 "졸려서 아무것도 못 하는" 상태와 "졸리지만 간단한 건 할 수 있는" 상태의 차이다.

**수면 시간**: 7시간 이상 잔 날의 오전 피크가 평균 4.5점, 6시간 이하로 잔 날은 3.7점. 그리고 6시간 이하로 잔 날은 피크 시간 자체가 30분 늦게 시작됐다. 10시 반에야 엔진이 걸렸다. 1시간 일찍 자는 게 1시간 야근하는 것보다 다음 날 생산성에 확실히 이득이었다.

## 배치를 바꿨다

데이터를 보고 나서 한 건 단순하다. 에너지가 높은 시간에 어려운 일을, 낮은 시간에 쉬운 일을 배치한 거다. 말로 하면 당연한 소리인데, 실제로 이렇게 하는 사람은 많지 않다. 대부분 출근하면 슬랙부터 열고 메일부터 확인한다. 가장 에너지 높은 시간을 잡무에 쓰는 거다.

내 배치는 이렇게 바뀌었다.

**9시~9시 반 (웜업 30분)**: 어제 마무리 못한 것 훑어보기, 오늘의 메인 작업 코드 열어두기. 슬랙은 아직 안 본다. 뇌가 "일 모드"로 전환되는 시간을 확보한다.

**9시 반~11시 (피크)**: 그날의 가장 어려운 코딩 작업. 새 기능 구현, 복잡한 디버깅, 아키텍처 설계. 이 90분이 하루 전체의 가장 중요한 시간이다. 슬랙 상태를 "집중 모드"로 바꾸고 알림을 끈다.

**11시~12시 (높음)**: 코드 리뷰, PR 작성. 아직 뇌가 돌아가니까 리뷰 퀄리티가 좋다.

**오후 1시~2시 (바닥)**: 슬랙 답장, Jira 정리, 문서 업데이트. 인지 부하가 낮은 일들. 또는 10분 산책. 건물 1층을 한 바퀴 도는 것만으로도 식곤증이 좀 풀렸다.

**오후 2시~4시 (회복 + 미니 피크)**: 이미 설계가 끝난 기능의 구현, 단위 테스트 작성, CSS 작업. 새로 생각할 건 적고 실행만 하면 되는 일들. 3시~4시의 미니 피크에 약간 복잡한 작업을 끼워넣는다.

**오후 4시~6시 (하강)**: 내일 할 일 정리, 스탠드업 준비, 블로그 읽기. 새 코딩을 시작하지 않는다. 이 시간에 시작한 코드는 내일 아침에 "이게 뭐야" 하고 다시 짜야 할 확률이 높다.

## 미팅은 적이다 (그리고 그걸 말할 수 있어야 한다)

배치를 바꾸면서 가장 어려운 건 미팅이었다. 오전 10시에 1시간짜리 미팅이 잡히면 피크 타임의 대부분이 날아간다.

팀 리드에게 부탁했다. "가능하면 제가 참석하는 미팅을 11시 이후로 잡아주실 수 있을까요? 아침에 집중 시간을 확보하고 싶어서요." 한 번 말하는 게 어려웠지만, 말하고 나니까 생각보다 반응이 좋았다. "그럼 팀 전체로 적용해볼까?"라는 반응이 돌아왔다. 결국 우리 팀은 "오전 11시 전에는 미팅 없음"을 비공식 규칙으로 만들었다.

물론 회사 전체가 이 규칙을 따르지는 않는다. 다른 팀과의 미팅은 오전에 잡힐 수도 있다. 그런 날은 전략을 바꾼다. "오늘은 딥워크 날이 아니다"라고 인정하고, 코드 리뷰나 문서 작업을 한다. 미팅 사이 30분에 코딩을 억지로 끼워넣으려다가 좌절하는 것보다 낫다. 컨텍스트 스위칭의 비용은 대부분의 사람이 과소평가한다.

내가 주최하는 미팅은 무조건 오후 2시~4시에 잡는다. 에너지가 코딩하기엔 부족하지만 대화하기엔 충분한 시간대. 미팅과 코딩의 에너지 요구가 다르다는 걸 알면, 미팅 시간을 전략적으로 고를 수 있다.

## 에너지 총량을 올리는 요소들

배치를 최적화해도, 에너지 총량 자체가 낮으면 한계가 있다. 30일 로그에서 에너지 총량에 영향을 미치는 요소도 보였다.

**커피 타이밍이 의외로 중요했다**: 9시에 마시면 피크(9시 반~11시)에 효과가 겹친다. 그러면 피크가 더 높아지는 게 아니라, 피크 후 드랍이 더 심해졌다. 10시 반에 마시면 오전 피크가 자연스럽게 끝나는 11시 이후를 커피로 버틸 수 있었다. 그리고 오후 2시에 한 잔 더 마시면 미니 피크(3시~4시)를 살짝 높일 수 있었다. 오후 3시 이후에 마시면 밤에 잠이 안 왔다.

**월요일의 에너지가 가장 높았다**: 직관적으로는 금요일이 피로 누적으로 가장 낮을 것 같은데, 실제로는 수요일이 가장 낮았다. 월요일은 주말에 쉬고 나서 에너지가 충전된 상태. 수요일은 이틀 동안의 피로가 쌓이면서 아직 금요일까지 남아있다는 심리적 무게까지 더해지는 시점. 금요일은 "곧 쉰다"는 기대감이 에너지를 약간 끌어올렸다.

이 데이터로 주간 배치도 조정했다. 가장 어려운 작업은 월요일과 화요일 오전에 배치한다. 수요일은 가급적 가벼운 업무와 미팅으로 채운다. 금요일 오후는 다음 주 계획과 기술 블로그 읽기.

## 3개월 후

에너지 기반 배치를 3개월 했다. 정확한 측정은 어렵지만 체감은 확실하다.

"오늘 하루 왜 이렇게 안 됐지?" 하는 날이 주 3~4일에서 주 1일 정도로 줄었다. 완전히 없어지지는 않는다. 컨디션이 안 좋은 날은 아침에도 집중이 안 되고, 갑자기 프로덕션 이슈가 터지면 모든 배치가 뒤집어진다.

근데 기본 틀이 있는 것과 없는 것의 차이는 크다. 비가 올 때 우산이 있는 것과 없는 것의 차이. 비를 완전히 막지는 못하지만, 없는 것보다는 확실히 낫다.

그리고 하나 더. 퇴근 후 피로감이 줄었다. 이전에는 하루가 끝나면 뇌가 쥐어짜인 느낌이었는데, 지금은 "오늘 꽤 했네" 하면서도 여유가 남는다. 에너지를 효율적으로 쓰니까 같은 총량으로 더 많이 하고도 덜 지친다. 에너지를 관리한다는 건 결국, 내가 가진 유한한 자원을 가장 가치 있는 곳에 쓰겠다는 결정이다.

## 에너지 로그를 추천하는 이유

사람마다 에너지 패턴이 다르다. 밤에 집중이 잘 되는 올빼미형도 있고, 새벽 5시에 일어나서 일하는 사람도 있고. 내 패턴이 정답이 아니다. 중요한 건 "자기" 패턴을 아는 것이다.

에너지 로그는 30일이면 충분하다. 매 시간 1~5점 찍는 데 10초면 된다. 한 달에 10초 x 8시간 x 22일 = 약 30분 투자. 이 30분이 앞으로 몇 년의 일하는 방식을 바꿀 수 있다.

느낌이 아니라 데이터로 판단해야 한다. "나는 아침형이야"라는 믿음이 데이터로 검증 안 되면 그건 그냥 믿음이다. 내가 그랬다. "아침에 집중이 잘 되겠지"라고 생각했는데, 실제로는 출근 후 30분이 지나야 엔진이 걸렸다. 그 30분을 몰랐으면 아직도 9시에 복잡한 코드를 열어놓고 멍하니 앉아 있었을 거다.

시간은 통제할 수 없다. 하루 24시간은 모두에게 동일하고, 그걸 늘릴 수는 없다. 근데 에너지의 배치는 통제할 수 있다. 같은 8시간을 어떻게 쓰느냐에 따라, 어떤 날은 8시간이 4시간의 성과를 내고, 어떤 날은 8시간이 12시간의 성과를 낸다. 차이는 시간이 아니라 에너지다.


트위터에서 "failure resume"라는 개념을 봤다. 이력서에는 성공한 것만 쓰는데, 실패한 것만 모아서 써보라는 거다. 학계에서 시작된 개념이라고 한다. 탈락한 학회, 떨어진 펀딩, 리젝된 논문 같은 걸 적는 거다. 프린스턴 교수가 쓴 failure CV가 유명해지면서 퍼졌다고.

재미있을 것 같아서 노션을 열고 써봤다. 제목은 "실패 이력서". 날짜순으로 정리하기 시작했다.

생각보다 많았다.

## 면접 탈락 3건

지금 회사에 오기 전에 세 곳에서 떨어졌다. 부트캠프 끝나고 한 달 동안 이력서를 돌린 시기다.

첫 번째는 시리즈A 스타트업이었다. 교육 관련 서비스. 코딩 테스트에서 떨어졌다. 알고리즘 두 문제 중 하나를 시간 내에 못 풀었다. BFS 문제였는데, 큐를 안 쓰고 재귀로 풀려다가 시간초과가 났다. 재귀 호출이 깊어지면서 스택이 터진 거다. 끝나고 나서 바로 BFS 구현을 찾아봤는데 10줄짜리 코드였다. 배열로 큐를 만들고, shift로 꺼내고, 인접 노드를 push하고. 외울 정도의 분량을 몰라서 떨어진 거다. 그날 밤에 BFS/DFS를 3시간 동안 반복해서 풀었다.

두 번째는 중견 IT 회사. 기술 면접까지 갔다. 면접관이 두 명이었는데, 한 명이 "가상 DOM이 왜 빠른지 설명해보세요"라고 했다. "실제 DOM 조작을 줄여주니까요"라고 대답했다. 틀린 말은 아니지만 너무 표면적이었다. 그다음 질문이 "구체적으로 diffing 알고리즘이 어떻게 동작하나요?"였는데, 말문이 막혔다. "트리를 비교해서... 바뀐 부분만..." 더듬거리다가 끝났다. 면접관 표정이 좀 굳었다. 개념만 알고 동작 원리를 몰랐다. 면접 끝나고 집에 오는 버스에서 React 공식 문서의 Reconciliation 페이지를 읽었다. 버스에서 내릴 때쯤 "이걸 왜 미리 안 읽었지" 하는 후회가 밀려왔다.

세 번째는 꽤 가고 싶었던 곳이었다. 프로덕트가 좋았고, 기술 블로그도 재미있게 읽고 있던 회사. 서류 통과, 코딩 테스트 통과, 기술 면접도 괜찮았다고 느꼈다. 면접관이 웃으면서 "잘 하셨어요"라고 했다. 컬쳐 핏 면접도 좋은 분위기였다. 이직을 왜 하고 싶은지, 어떤 환경에서 일하고 싶은지. 진솔하게 대답했다. 손에 땀이 나면서도 "이거 될 수도 있겠다" 하는 기대가 있었다.

결과는 "최종 탈락." 이메일 한 줄. 이유를 물어볼 수 없었다. 그래서 더 괴로웠다. 뭐가 문제였는지 모르니까 고칠 수도 없었다. 기술이 부족했나? 컬쳐 핏이 안 맞았나? 더 좋은 후보가 있었나? 한 일주일 동안 면접 내용을 복기하면서 "그때 그렇게 말할 걸" 후회만 했다. 대답 하나하나를 다시 떠올리면서 "이 부분이 문제였을까?" 추측하는 게 고문이었다.

## 프로젝트 실패 2건

회사에서 맡은 프로젝트 중 사실상 실패한 게 두 개 있다.

하나는 내부 어드민 대시보드. 운영팀이 쓰는 도구인데, 기획이 계속 바뀌었다. 첫 주에 받은 기획서에는 차트가 3개였는데 둘째 주에 5개로 늘었다. 필터 기능도 처음에는 날짜만이었는데, 사용자 유형별, 지역별, 결제 방식별로 계속 추가됐다. 셋째 주에는 대시보드 레이아웃 자체가 바뀌었다. 나는 매번 코드를 갈아엎었다. 기획이 바뀔 때마다 컴포넌트를 새로 만들고, 상태 관리를 다시 잡고.

결국 데드라인을 2주 넘기고 나서야 "일단 이거로 가자"가 됐는데, 코드가 누더기였다. 세 번 갈아엎은 흔적이 고스란히 남아 있었다. 사용하지 않는 컴포넌트 파일, 주석 처리된 코드, 의미를 잃은 변수명. 리팩토링할 시간도 없었고, 지금도 그 코드는 건드리기 무서운 상태로 남아 있다. 누가 그 프로젝트 유지보수를 맡으면 미안할 것 같다.

이건 내 탓만은 아니었지만, "기획이 불안정하면 먼저 범위를 정해야 한다"는 걸 그때 배웠다. 시키는 대로만 코드를 바꾸면 안 되고, "이번 스프린트에서는 이것까지만 하겠습니다"라고 선을 긋는 게 필요했다. 주니어라서 그런 말을 하기 어려웠지만, 안 하면 코드가 망가진다. 지금은 기획이 흔들리면 "범위를 먼저 확정하고 싶습니다"라고 말할 수 있다. 그때의 실패 덕분에.

다른 하나는 검색 자동완성 기능이었다. 사용자가 검색창에 글자를 입력하면 아래에 추천 검색어가 나오는 기능. 디바운스 로직을 잘못 설계해서, 빠르게 타이핑하면 이전 요청의 응답이 나중에 와서 최신 결과를 덮어씌우는 버그가 있었다. "React"를 입력했는데 "Rea"에 대한 검색 결과가 마지막에 와서 그게 화면에 보이는 거다. race condition이었는데, 그때는 그 단어를 몰랐다. "왜 결과가 이상하게 나오지?" 하면서 디바운스 시간을 늘렸다 줄였다 하고 있었다.

QA에서 잡혀서 핫픽스를 했는데, 핫픽스한 코드도 엣지 케이스가 있어서 또 고쳤다. 결국 AbortController를 도입해서 이전 요청을 취소하는 방식으로 해결했는데, 처음부터 이걸 알았으면 반나절이면 끝났을 일을 일주일 넘게 붙잡은 거다. 그래도 이 경험 덕분에 비동기 요청의 race condition은 확실히 이해하게 됐다.

## 포기한 사이드 프로젝트 5개

이건 쓰면서도 좀 부끄러웠다. 깃허브에 아카이브된 레포들을 뒤져봤다.

1. **개발자 독서 기록 앱** - Next.js + Supabase로 시작. 구글 Books API로 책 검색, 독서 상태 관리, 메모 기능. 로그인까지 만들고 방치. 이유: "기존 독서 앱이면 되는데 이걸 왜 만들고 있지?" 하는 회의감. 3주 작업.
2. **포모도로 타이머 크롬 익스텐션** - 타이머 UI까지 만들고 방치. 25분 타이머, 5분 휴식, 4사이클 후 긴 휴식. 이유: 이미 좋은 게 너무 많았다. 만들면서 "이걸 누가 쓰지?"라는 의문. 1주 작업.
3. **블로그 테마 직접 만들기** - Gatsby로 시작했는데 빌드가 너무 느려서 Next.js로 갈아타다가 방치. 이유: 테마 디자인 고르는 데 시간을 다 씀. 폰트 5개, 컬러 팔레트 8개를 비교하다가 지침. 2주 작업.
4. **면접 질문 정리 사이트** - 노션에 정리하던 면접 질문들을 웹사이트로 만들려고 했다. 카테고리별 분류, 검색, 즐겨찾기 기능. 이유: "이거 그냥 노션 링크 공유하면 되잖아." 2주 작업.
5. **가계부 앱** - React Native로 시도. 수입/지출 기록, 카테고리별 통계, 월간 리포트. 이유: React Native 개발 환경 세팅에서 이틀 날리고 의지 소멸. Xcode 에러, Android Studio 에러, 시뮬레이터 안 뜨는 에러. 환경만 잡다가 코드 한 줄 못 쓰고 포기. 3일 작업.

5개 중 3개는 "이미 더 좋은 게 있다"는 이유로 포기했다. 근데 지금 생각해보면, 그게 포기의 진짜 이유였을까? 아마 만드는 과정이 재미없어진 시점에서 합리화를 한 것 같다. 재미있으면 이미 좋은 게 있어도 계속 만들었을 거다.

## 적어보니 보이는 것

실패 목록을 적으면서 패턴이 좀 보였다.

면접 탈락은 전부 "깊이 부족"이었다. 표면적으로는 알지만 한 꺼풀만 벗기면 대답을 못 했다. "가상 DOM을 안다"와 "가상 DOM의 동작 원리를 설명할 수 있다"는 완전히 다른 레벨이다. 이건 지금도 과제이긴 한데, 그때보다는 나아졌다고 생각한다. 면접 탈락 경험이 "깊게 공부하자"는 방향을 잡아준 셈이다.

프로젝트 실패는 "커뮤니케이션"이었다. 기술 문제가 아니라 사람 문제. 기획이 흔들릴 때 "안 됩니다"를 말하는 용기, 모르는 걸 모른다고 빨리 인정하는 것. 혼자 끙끙거리면서 시간을 날리지 않고 "이거 모르겠는데 도와주세요"라고 말하는 것. 이것도 아직 연습 중이다.

사이드 프로젝트 포기는 "목적 부재"였다. 왜 만드는지가 불분명하니까, 재미가 떨어지면 바로 놓는다. 유일하게 완성한 프로젝트는 내가 진짜 필요해서 만든 거였다. "이거 있으면 편하겠다"에서 출발한 프로젝트는 끝까지 갔고, "포트폴리오에 넣어야지"에서 출발한 프로젝트는 중간에 멈췄다.

실패 이력서를 쓴 뒤로 실패가 좀 덜 무섭다. 왜냐하면 이미 많이 실패해봤고, 그래도 여기까지 왔으니까. 면접 3번 떨어지고 4번째에 붙었고, 프로젝트 2개 말아먹고도 아직 회사에서 일하고 있다. 사이드 프로젝트 5개 포기하고도 결국 하나는 완성했다.

이런 말이 허세처럼 들릴 수 있는데, 진짜로 목록을 적어보면 생각보다 많은 실패를 겪고도 멀쩡하게 출근하고 있는 나를 발견하게 된다. 실패가 끝이 아니었다는 걸, 목록으로 보니까 확실히 느껴진다.

한번 써보는 거 추천한다. 30분이면 된다. 노션이든 메모장이든.


코드 리뷰에서 이런 코멘트를 받은 적이 있다. "이 로직 왜 이렇게 짰어요?"

기술적으로 틀린 부분이 있었던 거라 지적 자체는 맞았다. 근데 기분이 안 좋았다. "왜 이렇게 짰어요?"는 코드에 대한 질문인데, 읽는 사람 입장에서는 "이것도 모르냐"로 느껴질 수 있다. 같은 내용을 "이 부분은 이렇게 하면 성능이 더 나을 것 같은데 어떻게 생각해요?"라고 썼다면 느낌이 완전히 달랐을 거다.

이 경험 이후로 피드백이라는 걸 의식적으로 생각하게 됐다. 어떻게 말하느냐에 따라 같은 내용도 건설적인 조언이 되기도 하고, 그냥 기분 나쁜 지적이 되기도 한다는 걸. 개발자 커리어에서 코드 리뷰는 매일 하는 건데, 피드백 스킬은 아무도 가르쳐주지 않는다. 스스로 부딪히면서 배우는 수밖에 없었다.

## 피드백을 받는 게 어려운 이유

개발자한테 코드는 본인의 연장선이다. 코드에 대한 피드백을 자신에 대한 평가로 받아들이기 쉽다. 특히 주니어일수록 그렇다. 내가 그랬다.

입사 초기에 PR에 코멘트가 5개 이상 달리면 맥북 앞에서 한숨부터 쉬었다. "또 뭘 잘못했지." 하나하나 읽으면서 속으로 변명을 준비했다. "이건 이런 이유가 있어서 그렇게 한 건데..." 리뷰어가 말한 의도는 "이렇게 하면 더 좋지 않을까"인데, 나는 "너 이것도 못하냐"로 해석하고 있었다.

이게 바뀐 건 시니어 한 분의 말 한마디 덕분이었다. 점심을 먹다가 코드 리뷰 얘기가 나왔는데, 시니어가 이렇게 말했다. "리뷰 코멘트가 많다는 건 리뷰어가 네 코드를 꼼꼼하게 봤다는 뜻이야. 코멘트 없이 approve만 달리면 오히려 걱정해야 해." 그 말이 관점을 바꿔줬다.

그 뒤로는 코멘트를 읽을 때 "이 사람이 나를 공격하려는 건가, 코드를 더 낫게 만들려는 건가?"를 먼저 생각한다. 거의 대부분은 후자다. 간혹 공격적인 톤의 리뷰를 만나면, 그건 그 사람의 커뮤니케이션 스타일 문제이지 내 코드의 문제가 아니다.

## 피드백을 잘 받는 연습

피드백을 받을 때 가장 효과적이었던 건, 바로 반박하지 않고 일단 이해하려고 하는 거다.

코멘트를 보면 반사적으로 "근데 이건..."이라고 답하고 싶은 충동이 올 때가 있다. 그럴 때 10분만 기다린다. 10분 뒤에 다시 읽으면 처음과 느낌이 다를 때가 많다. 감정이 가라앉으면 내용 자체에 집중할 수 있다.

그리고 리뷰어의 의도가 명확하지 않으면 물어본다. "이 부분은 어떤 관점에서 말씀하신 건가요?"라고. 추측으로 반박하면 대화가 산으로 간다. 확인하고 나서 논의하면 훨씬 생산적이다.

한번은 리뷰에서 "이 상태 관리 방식이 복잡해 보인다"는 코멘트를 받았다. 처음에는 "이게 최선인데"라고 생각했는데, 왜 복잡하다고 느꼈는지 물어봤더니 "새로 합류하는 사람이 이해하기 어려울 것 같다"는 거였다. 나는 기능적인 관점에서만 봤는데 리뷰어는 유지보수 관점에서 본 거다. 그 코멘트 덕분에 구조를 단순화했고, 실제로 나중에 후배가 그 코드를 수정할 때 큰 어려움 없이 이해했다.

## 피드백을 주는 게 더 어렵다

받는 것보다 주는 게 더 어렵다고 느꼈다.

후배 코드를 리뷰할 때 "이건 아닌데"라는 생각이 드는 부분이 있다. 근데 어떻게 말해야 상처를 안 주면서 정확하게 전달할 수 있을까. 딱 맞는 표현을 찾는 게 힘들다. 너무 돌려 말하면 의도가 전달이 안 되고, 직설적으로 말하면 상처를 줄 수 있다.

시행착오 끝에 나름의 원칙을 만들었다.

**코드를 비판하지, 사람을 비판하지 않기.** "왜 이렇게 짰어요?"가 아니라 "이 부분을 이렇게 바꾸면 어떨까요?" 주어를 사람이 아니라 코드로 만든다.

**이유를 함께 쓰기.** "이 변수명 바꿔주세요"보다 "이 변수명이 역할을 좀 더 명확하게 드러내면 좋을 것 같은데, 예를 들어 `userList`보다 `activeUsers`가 이 맥락에서 의미가 더 명확해 보여요" 같이 이유와 예시를 함께 쓴다. 시간이 좀 더 걸리지만 받는 사람 입장에서는 훨씬 이해하기 쉽다.

**좋은 부분도 언급하기.** 이건 억지로 칭찬하라는 게 아니다. 진짜 좋은 부분이 있으면 말해주는 거다. "이 에러 핸들링 깔끔하게 잘 처리했네요"라는 한마디가 분위기를 바꾼다. 피드백이 전부 지적이면 받는 사람이 방어적이 된다.

## 1:1에서의 피드백

코드 리뷰는 그나마 비동기적이라 생각할 시간이 있다. 1:1이나 대면 상황에서의 피드백은 난이도가 다르다.

한번은 팀 리드와 1:1에서 "커뮤니케이션에서 좀 더 적극적이면 좋겠다"는 피드백을 받았다. 구체적으로 뭘 의미하는지 물어봤더니, "작업 중에 막히면 혼자 끙끙대는 시간이 길어 보인다, 좀 더 빨리 공유하면 팀 전체 효율이 올라갈 것 같다"고 했다.

듣는 순간에는 좀 찔렸다. 근데 돌아와서 생각해보니 맞는 말이었다. 3시간 혼자 고민한 걸 5분 만에 해결한 적이 실제로 있으니까. 이 피드백을 받은 뒤로 "30분 룰"을 만들었다. 30분 동안 안 풀리면 누군가한테 공유한다. 무조건.

## 피드백 문화를 만드는 것

개인의 기술도 중요하지만 팀의 문화가 더 영향이 크다.

예전 팀에서는 코드 리뷰가 형식적이었다. 대부분 approve만 달리고, 가끔 사소한 컨벤션 지적만 있었다. 깊이 있는 피드백을 받기 어려웠다. 지금 팀은 다르다. 리뷰에서 설계 관련 논의가 오가고, 때로는 코멘트 스레드가 10개 넘게 달리기도 한다. 처음에는 부담스러웠는데, 이런 환경에서 성장 속도가 확실히 빠르다.

이런 문화는 리드의 역할이 크다. 우리 팀 리드는 자기 PR에도 리뷰를 요청하고, 코멘트를 달면 성실하게 답한다. 리드가 그러니까 팀원들도 자연스럽게 따라간다. 리드가 피드백에 방어적이면 팀원들도 방어적이 된다. 리드가 "오 좋은 지적이네, 고칠게"라고 하면 팀원들도 피드백을 편하게 받아들이게 된다. 문화는 위에서 아래로 흐른다.

나도 작은 시도를 하나 했다. PR 올릴 때 "이 부분은 고민이 되는데 의견 부탁드려요"라고 직접 질문을 달기 시작한 거다. 리뷰어 입장에서는 뭘 봐야 하는지 명확해지니까 더 구체적인 피드백이 온다.

## 비동기 vs 동기 피드백

코드 리뷰는 비동기 피드백이다. 쓰고, 읽고, 답하고. 시간 여유가 있다. 근데 가끔은 동기적으로 대화하는 게 더 효과적일 때가 있다.

한번 코드 리뷰 코멘트에서 의견이 갈린 적이 있다. 나는 A 방식이 낫다고 생각했고, 리뷰어는 B 방식을 제안했다. 코멘트로 3번 왔다 갔다 했는데 합의가 안 됐다. 글로 쓰니까 미묘한 뉘앙스가 전달이 안 되는 거다.

결국 "잠깐 통화 가능해요?" 하고 5분 전화를 했다. 목소리로 얘기하니까 3분 만에 합의가 됐다. 서로의 관점을 이해하고, 절충안을 찾았다. 글로는 30분 동안 코멘트를 주고받아도 안 됐던 게, 대화로는 금방 해결됐다.

이후로 코멘트가 2번 이상 왔다 갔다 하면 바로 "통화 한번 할까요?"라고 제안한다. 코멘트 스레드가 길어지면 감정도 섞이기 쉽다. 빨리 대화로 전환하는 게 효율적이기도 하고 관계를 위해서도 낫다.

## 셀프 피드백

남한테 받는 피드백 말고, 스스로한테 하는 피드백도 중요하다.

나는 2주에 한 번 정도 최근에 올린 PR을 다시 본다. 2주 전의 내 코드를 보면 "이걸 왜 이렇게 했지?"라는 부분이 꼭 보인다. 그때는 최선이라고 생각했는데 시간이 지나면 더 나은 방법이 떠오른다. 이걸 기록해두면 같은 실수를 줄일 수 있다.

한번은 3개월 전에 작성한 컴포넌트를 다시 봤는데, props가 8개였다. 지금 보면 명백하게 분리해야 할 컴포넌트인데, 당시에는 "하나의 컴포넌트로 처리하는 게 효율적"이라고 생각했다. 이런 걸 발견할 때마다 성장하고 있다는 걸 느낀다. 과거의 코드가 부끄러운 건 좋은 신호다.

피드백은 결국 근육이다. 주고받는 걸 반복하면서 점점 자연스러워진다. 처음에는 어색하고 불편하지만, 그 불편함을 넘어가야 성장이 있다. 적어도 내 경험에서는 날카로운 피드백을 받았을 때 가장 많이 배웠다. 그때는 아팠지만.


주니어 때 디자인 파일을 받으면 바로 코드를 치기 시작했다. 위에서부터 아래로, 보이는 대로 옮겼다. 그러다 보면 항상 같은 문제가 생겼다. 중간에 컴포넌트 구조를 바꿔야 하거나, 디자이너가 의도한 인터랙션을 놓치거나, 반응형을 나중에 붙이려니 처음부터 다시 짜야 하거나.

지금은 코드를 치기 전에 하는 단계가 더 많아졌다. 그리고 그게 오히려 전체 시간을 줄여준다.

## 1단계: 디자인 파일 전체를 먼저 훑는다

피그마 파일을 열면 바로 Inspect 패널을 보는 게 아니라, 전체 페이지 흐름을 먼저 파악한다.

- 이 기능에 화면이 몇 개인지
- 화면 간의 이동 흐름이 어떻게 되는지
- 공통으로 쓰이는 요소가 뭔지
- 반응형 디자인이 있는지 (모바일/데스크탑)
- 에러 상태, 빈 상태, 로딩 상태가 디자인에 포함되어 있는지

특히 마지막이 중요하다. 에러/빈/로딩 상태가 디자인에 없으면 개발할 때 임의로 만들게 되고, 나중에 디자이너가 보고 "이건 의도한 게 아닌데요"라고 한다. 빠진 상태가 있으면 **코드를 치기 전에** 디자이너에게 물어본다.

## 2단계: 컴포넌트 분리

디자인을 보면서 머릿속으로 컴포넌트를 나눈다. 이때 기준은 크게 세 가지다.

**반복되는 요소.** 리스트 아이템, 카드, 태그 같은 것들. 한 화면에서 같은 패턴이 2번 이상 나오면 컴포넌트로 뺀다.

**독립적인 영역.** 헤더, 사이드바, 모달처럼 나머지 UI와 독립적으로 존재하는 영역. 이건 당연히 분리한다.

**복잡도.** 하나의 컴포넌트가 너무 커지면 (JSX가 100줄 이상이면) 의미 있는 단위로 쪼갠다. 여기서 "의미 있는"이라는 게 애매한데, 나는 "이 부분을 한 문장으로 설명할 수 있는가"를 기준으로 삼는다. "유저 프로필 카드", "결제 수단 선택 섹션", "주문 요약 테이블" 같은 식으로.

예를 들어 이런 상품 상세 페이지가 있다고 하자.

```
ProductDetailPage
├── ProductImageGallery     (상품 이미지 슬라이더)
├── ProductInfo             (상품명, 가격, 설명)
│   ├── PriceDisplay        (할인가/정가 표시)
│   └── ColorSelector       (색상 선택 옵션)
├── ProductTabs             (상세정보/리뷰/문의 탭)
│   ├── DetailTab
│   ├── ReviewTab
│   │   └── ReviewItem      (개별 리뷰)
│   └── InquiryTab
└── FloatingPurchaseBar     (하단 고정 구매 버튼)
```

이 구조를 코드 치기 전에 먼저 잡아둔다. 노트앱에 적거나, 피그마 코멘트로 남기거나.

## 3단계: 디자인 스펙 읽기

피그마의 Dev Mode나 Inspect 패널에서 확인할 것들.

**spacing과 sizing.** 요소 간의 간격, 패딩, 마진. 피그마에서 요소를 선택하고 다른 요소에 마우스를 올리면 간격이 나온다. 이때 4의 배수인지 확인한다. 디자이너가 8px 그리드를 쓰고 있다면 4, 8, 12, 16, 20, 24, 32, 40, 48 같은 값들이 나올 거다. 가끔 13px이나 7px 같은 애매한 값이 나오면, 디자이너의 의도인지 실수인지 확인한다. 대부분 실수다.

**typography.** 폰트 패밀리, 사이즈, weight, line-height, letter-spacing. 피그마에서 텍스트를 클릭하면 전부 나온다. 이때 디자인 시스템의 typography scale과 맞는지 확인한다. `text-sm`, `text-base`, `text-lg` 같은 이미 정의된 스타일이 있으면 그걸 쓰고, 피그마에 나온 px 값을 하드코딩하지 않는다.

**color.** 색상이 디자인 토큰으로 정의되어 있는지 확인한다. `#2563EB` 같은 원시 값이 아니라 `primary-500` 같은 토큰으로 매핑할 수 있어야 한다. 피그마의 Color Styles를 확인하면 된다.

**Auto Layout 속성.** 피그마의 Auto Layout은 CSS Flexbox와 거의 1:1 대응된다.

| 피그마 Auto Layout | CSS Flexbox |
|---|---|
| Horizontal | flex-direction: row |
| Vertical | flex-direction: column |
| Gap | gap |
| Padding | padding |
| Fill container | flex: 1 |
| Hug contents | width: fit-content |

이 대응 관계를 알고 있으면 피그마 속성을 바로 CSS로 옮길 수 있다.

## 4단계: 정적 UI부터 만든다

인터랙션, API 연동, 상태 관리는 전부 뒤로 미루고, 먼저 눈에 보이는 UI만 만든다.

```tsx
// 1차: 정적 UI
function ProductInfo() {
  return (
    <div className="flex flex-col gap-4">
      <h1 className="text-2xl font-bold">프리미엄 러닝화</h1>
      <PriceDisplay original={129000} discounted={89000} />
      <p className="text-gray-600 text-sm leading-relaxed">
        가볍고 쿠셔닝이 뛰어난 러닝화입니다.
      </p>
      <ColorSelector
        colors={['black', 'white', 'navy']}
        selected="black"
        onSelect={() => {}}
      />
    </div>
  );
}
```

하드코딩된 데이터로 먼저 화면을 만든다. 이 단계에서 디자이너에게 보여주고 1차 피드백을 받는다. API 연동 후에 UI 수정 요청이 오면 양쪽을 다 고쳐야 하니까, UI 확정을 먼저 받는 게 효율적이다.

## 5단계: 반응형

모바일 디자인이 있다면 모바일 우선(mobile-first)으로 작업한다. 이유는 간단하다. 작은 화면에서 시작해서 넓히는 게, 넓은 화면에서 시작해서 줄이는 것보다 쉽다.

```tsx
<div className="
  grid grid-cols-1 gap-4
  md:grid-cols-2 md:gap-6
  lg:grid-cols-3 lg:gap-8
">
  {products.map(product => (
    <ProductCard key={product.id} product={product} />
  ))}
</div>
```

반응형에서 자주 실수하는 것: 피그마에 모바일(375px)과 데스크탑(1440px)만 있고 태블릿이 없는 경우. 이때 768px~1024px 사이에서 UI가 어정쩡하게 깨지는 경우가 많다. 디자인이 없더라도 이 구간을 직접 확인하면서 조정해야 한다.

## 디자이너와의 커뮤니케이션

경험에서 배운 몇 가지.

**구현이 어려운 게 아니라 비용이 큰 것을 설명한다.** "이건 못 해요"보다 "이건 할 수 있는데, 이 방식으로 하면 3일이 더 걸려요. 이렇게 바꾸면 반나절이면 됩니다"가 훨씬 생산적이다. 디자이너도 일정을 안다. 대안을 함께 고민하면 더 좋은 결과가 나올 때가 많다.

**"이거 인터랙션이 어떻게 되는 거예요?"를 빨리 물어본다.** 정적 화면만 보면 모르는 게 많다. 드롭다운이 열릴 때 나머지 콘텐츠가 밀리는지 오버레이로 뜨는지. 모달이 닫힐 때 애니메이션이 있는지. 에러 메시지가 인풋 아래에 나오는지 토스트로 나오는지. 나중에 물어보면 이미 구조를 잘못 잡은 경우가 있다.

**피그마 코멘트를 적극적으로 쓴다.** 슬랙 메시지는 묻힌다. 피그마 코멘트는 해당 디자인 옆에 붙어 있으니까 컨텍스트가 유지된다. "이 부분 line-height가 디자인 시스템의 text-sm과 2px 차이가 나는데, 의도인가요?"같은 질문을 코멘트로 남기면 디자이너가 정확한 맥락에서 확인할 수 있다.

코드를 빨리 치는 것보다 코드를 덜 고치는 게 빠르다. 그리고 코드를 덜 고치려면 코드를 치기 전에 더 많이 확인해야 한다. 좀 귀찮아도 이 과정을 습관으로 만들면 전체 개발 시간이 줄어드는 걸 몸으로 느끼게 된다. 최소한 나는 그랬다.


내 GitHub에는 private repo가 12개 있다. 완성한 건 2개다. 나머지 10개는 README.md에 거창한 기능 목록만 남긴 채 마지막 커밋이 6개월 전이다.

이게 나만의 이야기는 아닐 거다. 개발자 커뮤니티에서 "사이드 프로젝트 시작했다"는 글은 넘쳐나는데, "완성했다"는 글은 거의 없다. 시작은 쉽다. `npx create-next-app`을 치는 순간에는 누구나 의욕이 넘친다. 문제는 그 다음이다.

나는 왜 10개를 버렸고, 2개는 어떻게 끝냈는지 돌아봤다. 거기서 찾은 패턴이 있다.

## 죽은 프로젝트들의 공통점

작년 여름, "개발자를 위한 독서 기록 앱"을 만들겠다고 했다. 아이디어가 좋다고 생각했다. Notion이 너무 무겁고, 기존 독서 앱들은 개발 서적에 특화되지 않았으니까. 이틀 만에 피그마를 열고 화면 7개를 디자인했다. 책 검색, 독서 노트, 하이라이트, 태그 시스템, 통계 대시보드, 소셜 공유, 알림 설정. 그리고 기술 스택을 고르기 시작했다.

Next.js로 할까, Remix로 할까. DB는 Supabase? PlanetScale? 아니면 이참에 Drizzle ORM을 배워볼까. 상태 관리는 Zustand가 요즘 핫하다는데. 인증은 NextAuth vs Clerk...

일주일이 지났다. 코드는 한 줄도 없었다.

그 다음 주에는 회사에서 큰 기능 출시가 있어서 바빴고, 그 다음 주에는 피로가 쌓여서 쉬었고, 한 달 뒤에 "아 그거 만들고 있었지" 하면서 폴더를 열어봤다. 피그마 파일과 빈 프로젝트 스캐폴딩만 있었다. 다시 시작하기엔 관성이 사라진 뒤였다.

이 패턴이 10개 중 7개에서 반복됐다. 나머지 3개는 좀 달랐는데, 실제로 코딩은 시작했지만 "좀 더 다듬으면 되겠지" 하다가 소리 없이 사라졌다.

## 범위를 극단적으로 줄이기

살아남은 프로젝트 중 하나는 "오늘 뭐 먹지 결정기"였다. 이름부터 유치하다. 하지만 이게 완성된 이유가 있다.

처음에는 이것도 거창했다. 위치 기반 맛집 추천, 메뉴 사진, 리뷰, 찜하기 기능까지 생각했다. 근데 전에 몇 번 실패한 경험이 있으니까 이번에는 스스로에게 물어봤다. "이 중에서 진짜 핵심이 뭐야?"

답은 간단했다. 점심시간에 메뉴 고르기가 귀찮은 거. 그래서 MVP를 이렇게 정했다.

- 카테고리 몇 개 중에서 랜덤으로 하나 골라주는 것
- 끝

위치 기반? v2. 맛집 DB? v2. 리뷰? v2. 사실 v2는 영원히 오지 않았지만 상관없다. 핵심은 v1이 완성됐다는 것이다. 버튼 하나 누르면 "오늘은 국밥 어때요?" 하고 알려주는 웹앱. 웃기지만 실제로 팀원들이 점심마다 쓰기 시작했다. 사용자가 생기니까 v2에 대한 동기도 자연스럽게 생겼다.

"v2에서 하겠다"는 말은 "안 하겠다"가 아니라 "지금은 안 하겠다"는 뜻이다. 근데 대부분의 사이드 프로젝트에서 "지금 안 하면 영원히 안 하는" 유일한 것은 완성 그 자체다. 기능은 나중에 붙일 수 있다. 하지만 "이걸 끝까지 만들어본 경험"은 지금 아니면 안 생긴다.

## 데드라인이 없으면 끝이 없다

회사 업무는 왜 끝이 나는가? 마감이 있으니까. 사이드 프로젝트는 왜 끝이 안 나는가? 마감이 없으니까.

너무 당연한 소리 같지만 나는 이걸 한참 뒤에야 깨달았다. 두 번째로 완성한 프로젝트는 "개발 블로그 테마"였는데 (지금 이 블로그의 전신이다), 이게 완성된 결정적 이유가 있다. 회사 동기한테 "다음 주 금요일까지 블로그 올린다"고 말해버린 것이다.

그 동기는 그냥 "오 좋네" 하고 넘어갔을 수도 있다. 근데 나는 그 말을 한 순간부터 압박감이 생겼다. 금요일에 "블로그 됐어?" 하고 물을 게 뻔하니까. 약속을 안 지키면 체면이 깎이니까.

2주라는 시간은 기능을 막 붙일 수 있는 시간이 아니었다. 그래서 자연스럽게 "뭘 빼야 하지?"를 고민하게 됐다. 댓글 기능? 없어도 된다. 다크 모드? 나중에. SEO 최적화? 일단 기본만. 이렇게 빼고 나니까 만들어야 할 것이 확 줄었다. 그 데드라인이 범위 축소까지 강제한 셈이다.

인위적인 마감이라도 괜찮다. 아무한테나 말해라. 트위터에 써라. 커뮤니티에 올려라. "이번 달 안에 배포합니다." 그 한 마디가 만드는 압박감이 당신의 프로젝트를 살린다.

## 기술 스택 고민은 함정이다

앞에서 독서 기록 앱이 기술 스택 고르다가 죽었다고 했다. 이건 사이드 프로젝트에서 정말 흔한 함정이다.

새로운 기술을 배우는 것과 프로젝트를 완성하는 것은 다른 목표다. 둘 다 가치 있지만, 동시에 하려고 하면 둘 다 실패한다. 새 기술을 배우면서 프로젝트를 만들면, 막히는 지점이 두 배로 늘어난다. 기술적 문제와 기획적 문제가 동시에 나타난다. 그러면 "이거 왜 안 되지?" 하면서 삽질하는 시간이 길어지고, 그 시간이 길어지면 흥미가 식는다.

내가 "오늘 뭐 먹지 결정기"를 만들 때 쓴 기술은 Next.js, Tailwind CSS, Vercel이었다. 전부 회사에서 매일 쓰던 것들이다. 새로 배운 건 하나도 없다. 덕분에 막히는 구간이 거의 없었다. 아이디어에서 배포까지 주말 이틀이면 됐다.

Rust로 CLI 도구를 만들어보고 싶다면 그건 "Rust를 배우겠다"는 목표로 따로 시간을 잡아라. "프로젝트를 완성하겠다"는 목표와 섞지 마라.

## 디자인에서 멈추지 않기

개발자가 사이드 프로젝트에서 디자인을 신경 쓰기 시작하면 끝이 없다. 나도 그랬다. 버튼 radius를 4px로 할지 8px로 할지, 컬러 팔레트를 어떻게 잡을지, 폰트는 Pretendard가 나은지 Noto Sans KR이 나은지. 이런 걸로 반나절을 날린 적이 한두 번이 아니다.

shadcn/ui를 발견한 게 전환점이었다. 디자인 시스템을 통째로 가져다 쓸 수 있으니까 "디자인" 단계가 사라졌다. 그냥 컴포넌트를 조합하면 됐다. 못생기진 않고, 일관성 있고, 반응형까지 된다. 완벽하진 않지만 사용자가 불편하지 않을 정도면 충분하다.

사이드 프로젝트에서 디자인은 "나중에 개선하기 가장 쉬운 것" 중 하나다. 기능 구조를 나중에 바꾸는 건 어렵지만, 버튼 색깔을 바꾸는 건 5분이면 된다. 초기에 디자인에 시간을 쏟는 건 투자 대비 효율이 가장 낮은 행동이다.

## 배포를 먼저 해라

이건 나한테 가장 효과가 컸던 방법이다.

프로젝트를 시작하면 대부분 이런 순서를 따른다. 기획 → 디자인 → 개발 → 테스트 → 배포. 배포가 맨 마지막에 있다. 그래서 "배포할 만큼 완성되면 올려야지" 하고 계속 미룬다. 그 "완성"은 절대 오지 않는다.

나는 이제 프로젝트를 시작하면 제일 먼저 Vercel에 올린다. `npx create-next-app`을 치고, GitHub repo 만들고, Vercel에 연결한다. 빈 화면이어도 상관없다. URL이 생긴다. 그 URL이 존재한다는 사실이 심리적으로 완전히 다르다.

"내 프로젝트가 인터넷에 살아 있다"는 감각. 빈 화면이라도 거기에 뭔가를 채워 넣고 싶어진다. git push 한 번이면 바로 반영되니까 "한 줄이라도 더 써서 올려볼까" 하는 마음이 생긴다. 반대로 로컬에서만 돌리고 있으면 "아직 보여줄 단계가 아니야" 하면서 계속 미루게 된다.

배포된 상태에서 시작하면 또 하나 좋은 점이 있다. 배포 관련 삽질을 미리 해결할 수 있다. 환경 변수, 빌드 설정, 도메인 연결 같은 걸 마지막에 하면 "거의 다 만들었는데 배포가 안 돼" 하면서 좌절하는 경우가 있다. 처음부터 배포 상태로 개발하면 이런 문제를 커밋할 때마다 잡을 수 있다.

## "이걸 왜 만들고 있지?"

죽은 프로젝트 중에 하나가 "개발자 북마크 매니저"였다. 브라우저 북마크가 너무 지저분해서 시작한 프로젝트였는데, 만들다 보니까 깨달았다. 나는 북마크를 잘 정리하고 싶은 게 아니라 그냥 브라우저 탭을 너무 많이 여는 게 문제였다. 북마크 매니저를 만든다고 해결되는 게 아니었다.

그 깨달음이 오는 순간 흥미가 뚝 떨어졌다. "이걸 내가 왜 만들고 있지?" 이 질문에 답을 못 하면 프로젝트는 죽는다.

완성한 2개의 프로젝트는 공통점이 있었다. 둘 다 내가 실제로 매일 쓰는 것이었다. 점심 메뉴 결정기는 진짜로 매일 점심에 썼다. 블로그 테마는 지금 이 글을 쓰고 있는 바로 이 사이트다. 내가 쓰니까 불편한 점이 보이고, 불편한 점이 보이니까 고치고 싶고, 고치면 바로 내 삶이 나아진다. 이 피드백 루프가 동기를 유지시킨다.

"포트폴리오에 넣을 프로젝트"를 만들겠다는 동기로 시작하면 높은 확률로 실패한다. 그건 동기가 외부에 있는 거다. 면접관이 볼까? 이력서에 한 줄 추가될까? 그런 불확실한 보상은 밤 11시에 코드를 열게 만들 만큼 강하지 않다. 반면 "이거 없으면 내가 불편하다"는 감각은 강하다. 단순하지만 진짜다.

## 그래서 지금은

요즘 새로 만들고 있는 게 하나 있다. 회사 스탠드업 미팅 전에 "어제 뭐 했더라" 하고 git log를 뒤지는 게 귀찮아서, 매일 자동으로 내 커밋 요약을 만들어주는 작은 도구다. 범위는 딱 그것뿐이다. 예쁜 UI도 없다. 터미널에서 돌아가는 스크립트 하나. Vercel 배포 대상도 아니고 그냥 로컬에서 cron으로 돌린다.

근데 매일 아침 쓴다. 그러니까 매일 저녁에 "이 부분 좀 고치면 좋겠는데" 하는 생각이 든다. 그리고 실제로 고친다. 누가 시키지 않아도.

사이드 프로젝트를 완성하는 법은 결국 의지력이 아니다. 의지력으로 되는 건 아무것도 없다. 완성을 가능하게 만드는 환경을 세팅하는 거다. 범위를 줄이고, 마감을 만들고, 아는 기술을 쓰고, 디자인은 빌려오고, 배포를 먼저 하고, 내가 진짜 쓸 걸 만든다. 이 중 하나만 해도 확률이 올라간다. 다 하면 거의 확실하다.

GitHub에 잠들어 있는 repo가 있다면, 지금 열어서 기능 목록의 80%를 지워봐라. 남은 20%로 이번 주 안에 배포할 수 있는지 생각해봐라. 아마 될 거다.


입사 첫날, 맥북을 받고 개발 환경을 세팅하는데 README에 적힌 대로 했는데 안 됐다. Node 버전이 달랐다. 슬랙에서 물어보려는데 어느 채널에 물어봐야 하는지도 몰랐다. 옆자리 동료한테 조심스럽게 물어봤더니 "아 그거 README가 오래됐어요, 잠깐만요" 하고 5분 만에 해결해줬다. 그 5분이 고마우면서도, 내가 이렇게 아무것도 모르는 사람이 됐다는 게 묘하게 불편했다.

전 회사에서는 코드베이스를 거의 외우고 있었다. 어떤 컴포넌트가 어디서 쓰이는지, API 응답 구조가 어떤지, 심지어 어떤 코드가 왜 이상하게 생겼는지까지 다 알았다. 그런 사람이 갑자기 "이 프로젝트 폴더 구조가 뭔가요"부터 시작해야 하는 건 생각보다 자존심이 상하는 일이다.

## 첫 2주: 코드보다 사람을 먼저 파악하기

처음에는 코드를 열심히 읽었다. 출근하면 바로 에디터를 열고 컴포넌트 트리를 따라가면서 이해하려고 했다. 근데 이틀 정도 하고 나니까 깨달은 게 있다. 코드만 봐서는 "왜 이렇게 했는지"를 알 수 없다는 거다.

예를 들어 상품 상세 페이지에서 가격 표시 로직이 이상하게 복잡했다. 할인율 계산하는 함수가 3개나 있었고, 하나는 deprecated 주석이 달려 있는데 아직 쓰이고 있었다. 코드만 보면 "이거 왜 이래?"인데, 나중에 팀원한테 물어보니까 사정이 있었다. 이전에 결제 시스템을 바꾸면서 과도기에 두 개를 같이 써야 했고, 마이그레이션이 아직 안 끝났다고. 그 맥락을 모르면 코드를 아무리 오래 봐도 이해할 수 없는 부분이었다.

그 뒤로는 코드를 읽다가 이해 안 되는 부분이 나오면 먼저 git blame을 봤다. 누가 언제 수정했는지 확인하고, 그 사람한테 직접 물어봤다. "이 부분 컨텍스트가 궁금한데 잠깐 시간 괜찮으세요?"라고. 대부분 흔쾌히 알려줬다. 오히려 "아 그거 물어봐줘서 고마워, 나도 정리해야 하는데 계속 미루고 있었어"라는 반응도 있었다.

첫 2주 동안 가장 도움이 된 건 코드 리딩이 아니라 사람들과의 대화였다. 누가 어떤 도메인을 담당하는지, 의사결정은 어떤 흐름으로 이루어지는지, 팀 내에서 암묵적으로 지켜지는 규칙 같은 것들. 문서에는 안 적혀 있지만 모두가 알고 있는 것들이 꽤 많았다.

## 온보딩 문서를 믿지 말라는 건 아니고

온보딩 문서가 아예 없는 건 아니었다. 노션에 꽤 잘 정리된 페이지가 있었다. 아키텍처 다이어그램도 있고, 주요 서비스 간 의존성도 그려져 있었다. 근데 문제는 이게 6개월 전 버전이라는 거다. 그 사이에 마이크로서비스 하나가 합쳐졌고, 새로운 BFF 레이어가 추가됐다. 문서상으로는 서비스 A가 서비스 B를 직접 호출하는데, 실제로는 중간에 게이트웨이를 거치고 있었다.

그래서 나는 온보딩 과정에서 알게 된 것들을 노션에 따로 정리하기 시작했다. "실제 구조"라는 이름으로. 이게 나중에 꽤 유용했는데, 나 이후에 입사한 분이 "이거 진짜 도움됐어요"라고 말해줬을 때 뿌듯했다. 작은 기여인데 의외로 임팩트가 있었다.

## 첫 번째 PR

입사 후 일주일쯤 됐을 때 첫 PR을 올렸다. 버튼 컴포넌트의 disabled 상태에서 툴팁이 안 뜨는 버그 수정이었다. 코드 변경은 8줄 정도. 팀 리드가 "온보딩 중인데 벌써 PR 올렸네"라고 했는데, 솔직히 이걸 빨리 올리고 싶었던 이유가 있다.

새 회사에서 처음 머지되는 코드가 의미가 있다고 생각했다. 아무리 작아도 "이 사람이 기여한 코드가 프로덕션에 나가 있다"는 사실이 소속감을 준다. 그리고 PR 과정을 통해 팀의 코드 리뷰 문화를 파악할 수 있다. 리뷰를 얼마나 꼼꼼하게 하는지, 어떤 부분을 중요하게 보는지, 컨벤션이 어떤지. 이걸 직접 겪어봐야 감이 온다.

리뷰에서 컨벤션 관련 코멘트를 2개 받았다. 하나는 CSS 클래스 네이밍 방식이었고, 하나는 테스트 파일 위치였다. 전 회사에서 하던 방식이 몸에 배어 있어서 무의식적으로 그렇게 쓴 거였다. 이런 것도 빨리 경험할수록 좋다.

## 30일 차: 흐름이 보이기 시작하다

한 달쯤 지나니까 슬랙에서 대화 흐름을 따라갈 수 있게 됐다. 처음에는 약어랑 내부 용어 때문에 무슨 말인지 절반도 못 알아들었다. "TMS에서 FE 쪽 CDC 체크해줄 수 있어?" 같은 메시지를 보면 단어 하나하나 검색해야 했다. 그게 한 달쯤 되니까 자연스럽게 이해가 됐다.

스프린트 플래닝에서도 변화가 있었다. 처음 몇 번은 그냥 듣기만 했다. 티켓 설명을 읽어도 맥락을 모르니까 "이건 얼마나 걸릴까요?"라는 질문에 답할 수가 없었다. 한 달쯤 되니까 "이 부분은 기존 컴포넌트를 재사용하면 될 것 같은데요"라는 식으로 의견을 낼 수 있게 됐다. 처음으로 플래닝에서 말을 했을 때 팀 리드가 고개를 끄덕여준 게 기억난다.

## 60일 차: 실수하고 배우는 시기

두 달 차에 사고를 하나 쳤다. 스테이징 환경이라고 생각하고 API를 호출했는데 프로덕션이었다. 다행히 읽기 전용 API라서 데이터가 변경되지는 않았지만, 모니터링 대시보드에 이상한 트래픽이 찍혀서 시니어가 물어봤다. 솔직하게 말했다. "제가 환경 변수를 확인 안 하고 호출했습니다." 시니어가 "괜찮아, 나도 입사 초기에 비슷한 거 한 적 있어. 근데 앞으로는 환경 변수 확인하는 습관 들이자" 하고 넘어갔다.

이때 배운 게 있다. 실수했을 때 숨기거나 변명하지 않는 게 신뢰를 쌓는 가장 빠른 방법이라는 거다. 특히 신입일 때는 실수 자체보다 실수를 어떻게 처리하는지를 사람들이 본다. "아 이 사람은 솔직하게 말하고 같은 실수를 반복하지 않으려는 사람이구나"라는 인상을 주는 게 중요하다.

그 이후로 나는 `.env` 파일에 환경 이름을 콘솔에 찍는 스크립트를 추가했다. 개발 서버 켤 때마다 "현재 환경: staging"이 보이게. 사소한 건데 이걸 팀 채널에 공유했더니 다른 분이 "오 좋은데, 저도 적용해야지"라고 해서 팀 전체 세팅에 반영됐다.

## 90일 차: 돌아보니

세 달이 지나고 나서야 "여기가 내 회사다"라는 느낌이 살짝 들기 시작했다. 완전히 적응한 건 아니다. 아직도 모르는 도메인이 많고, 코드베이스에서 처음 보는 패턴을 발견하기도 한다. 근데 "모르는 게 있으면 누구한테 물어봐야 하는지"는 알게 됐다. 그게 적응의 핵심인 것 같다.

돌이켜보면 잘한 것과 아쉬운 것이 있다.

잘한 것: 질문을 많이 한 것. 처음에는 "이런 것도 모르냐"고 생각할까 봐 겁났는데, 실제로 그렇게 반응하는 사람은 없었다. 오히려 "일찍 물어봐서 좋다"는 반응이 대부분이었다. 그리고 질문할 때 "이 부분을 이렇게 이해했는데 맞나요?"라는 식으로 내 이해를 먼저 말하고 확인 받는 방식이 효과적이었다.

아쉬운 것: 처음 2주 동안 너무 코드만 읽으려고 한 것. 그 시간에 팀원들이랑 점심이라도 더 먹을 걸. 코드는 어차피 매일 보게 된다. 근데 관계를 만들 수 있는 기회는 초반에 집중되어 있다. 첫 달에 "새로 오신 분이니까" 하고 먼저 다가와주는 분위기가 있는데, 그 시기를 놓치면 나중에 관계를 만드는 게 더 어렵다.

지금 이직을 앞두고 있거나 막 새 회사에 합류한 분들에게 하나만 말하자면, 첫 90일의 목표는 "뛰어난 성과를 내는 것"이 아니라 "이 사람이랑 같이 일하고 싶다"는 인상을 주는 거다. 그리고 그 인상은 대단한 기술력이 아니라 성실함, 솔직함, 질문하는 태도에서 온다.

## 점심의 중요성

사소하지만 빼놓을 수 없는 게 점심이다. 처음에는 "밥 같이 드실래요?"라는 말에 "네 감사합니다" 하고 따라갔다. 누가 어떤 사람인지도 모르는 채로. 근데 이 점심 시간이 생각보다 중요했다. 업무 시간에는 못하는 가벼운 대화를 점심에 한다. 전 회사 어디 다녔는지, 주말에 뭐 하는지, 요즘 뭐에 관심 있는지. 이런 대화를 통해서 "직장 동료"가 "아는 사람"이 된다.

한 번은 점심을 먹다가 시니어 한 분이 "나 입사했을 때 이 코드베이스 보고 충격받았어"라는 얘기를 했다. 3년 전에 급하게 만든 프로토타입이 아직도 프로덕션에 살아있다는 거였다. 그 히스토리를 아는 것만으로도 코드를 이해하는 데 도움이 됐다. 점심에서 나온 얘기가 업무에 도움이 된 셈이다.

## 입사 초기에 하면 좋은 작은 것들

온보딩 중에 발견한 문서 오류를 수정하는 PR을 올렸다. README의 Node 버전이 실제와 다른 것, 환경 변수 설명이 빠진 것, 더 이상 쓰이지 않는 스크립트 안내. 이런 거 하나하나 고치면서 PR을 올리면 두 가지 효과가 있다. 팀에 기여하면서 동시에 코드 리뷰를 통해 팀의 프로세스를 배울 수 있다.

그리고 궁금한 건 바로바로 물어보되, 같은 질문을 두 번 하지 않으려고 답변을 기록했다. 노션에 "QnA 로그"라는 페이지를 만들어서, 질문과 답을 쌓아갔다. 2달쯤 되니까 이게 내 개인 위키가 됐다. 가끔 기억 안 나는 거 있으면 여기서 검색한다.

물론 이건 내 경험일 뿐이고, 회사마다, 팀마다 다를 거다. 다음에 또 이직하게 되면 그때는 또 다른 교훈이 생기겠지. 그게 좀 무섭기도 하고 기대되기도 한다.


우리 사무실은 전형적인 오픈 오피스다. 높이 120cm짜리 파티션으로 나뉜 책상이 길게 이어져 있고, 고개를 들면 팀원들의 모니터가 보인다. 왼쪽에는 백엔드 개발자, 오른쪽에는 디자이너, 뒤에는 PM이 앉아 있다.

입사할 때는 "소통이 편하겠다"고 생각했다. 6개월 후에는 "제발 집중 좀 하게 해주세요"가 됐다. 여기까지는 오픈 오피스에서 일하는 개발자라면 누구나 비슷할 거다. 이 글은 그 다음 이야기다. 3개월 동안 6가지 전략을 순서대로 시도하면서, 실제로 집중 시간을 측정하고, 뭐가 됐고 뭐가 안 됐는지 기록한 이야기.

## 측정부터 했다

뭔가를 바꾸려면 먼저 현재 상태를 알아야 한다. 9월 첫째 주, 한 주 동안 '진짜 집중한 시간'을 기록했다. 기준은 단순하다. 코드를 작성하거나 읽으면서, 외부 방해 없이 15분 이상 연속으로 작업한 시간만 센다. 슬랙 확인, 미팅, 코드 리뷰, 대화는 제외.

결과: 일주일 평균 하루 **1시간 47분.**

충격이었다. 회사에 9시간 있는데 진짜 집중하는 시간이 2시간이 안 된다니. 나머지 7시간은 뭘 하고 있었나? 기록을 뜯어봤다.

- 미팅: 하루 평균 1.5시간
- 슬랙 대화 + DM 응답: 하루 평균 1.5시간
- 코드 리뷰: 하루 평균 45분
- 어깨 탭 대응 (자리에서 받는 질문): 하루 평균 30분
- 컨텍스트 전환 후 재집중 시간: 하루 평균 1시간
- 기타 (점심, 커피, 화장실, 잡담): 하루 평균 1.5시간

마지막 줄은 어쩔 수 없다. 미팅과 코드 리뷰도 필요한 일이다. 근데 슬랙 대화, 어깨 탭, 컨텍스트 전환 비용을 합치면 하루 3시간이 '방해와 그 여파'에 소비되고 있었다. UC Irvine의 Gloria Mark 교수 연구에 따르면 업무가 중단된 후 원래 작업으로 복귀하는 데 평균 23분이 걸린다. 하루에 4~5번 중단되면, 재집중 비용만으로 1시간 이상이 날아간다. 내 기록과 정확히 일치했다.

이 데이터를 기준선으로 잡고, 매주 하나씩 전략을 바꿔가면서 집중 시간이 어떻게 변하는지 추적했다.

## 전략 1: 노이즈 캔슬링 헤드폰 (2주차)

가장 먼저 시도한 건 하드웨어 교체였다. 에어팟 프로에서 소니 WH-1000XM5 오버이어 헤드폰으로 바꿨다. 에어팟 프로의 노이즈 캔슬링은 오픈 오피스에서 부족했다. 사람 목소리를 완전히 차단하지 못한다. 오버이어로 바꾸니까 물리적으로 귀를 감싸서 패시브 차단만으로도 차이가 크고, 거기에 액티브 노이즈 캔슬링까지 더하면 웬만한 대화 소리는 안 들린다. 가사 없는 앰비언트 음악을 틀면 거의 완벽에 가깝다.

부수 효과도 있었다. 큰 헤드폰을 쓰고 있으면 시각적 신호가 된다. "이 사람은 지금 집중하고 있다"는 무언의 메시지. 인이어 이어폰은 밖에서 잘 안 보여서 이 효과가 없다. 실제로 헤드폰을 쓴 뒤로 어깨 탭이 줄었다. 대신 슬랙 DM이 온다. "시간 될 때 이거 좀 봐줄 수 있어?" 이게 훨씬 낫다. 내 타이밍에 확인할 수 있으니까.

**결과: 일주일 평균 하루 2시간 12분.** 기준선 대비 약 25분 증가. 나쁘지 않지만 획기적이지도 않다. 소리를 차단해도, 슬랙 알림은 화면에 뜨고, 시야에 들어오는 사람들의 움직임은 여전하다.

## 전략 2: 폰부스/회의실 탈출 (3~4주차)

사무실에 1인용 폰부스가 세 개 있다. 약 1.5m x 1.5m 크기의 방음 공간. 환기가 안 돼서 30분 이상 있으면 답답하지만, 여기 들어가서 작업하면 확실히 집중이 잘 된다. 시야에 움직이는 사람이 없고, 문을 닫으면 소리도 거의 안 들린다.

폰부스가 비어있지 않으면 빈 회의실을 잡았다. 30분~1시간짜리 예약을 걸고 혼자 들어가서 코딩했다. 좀 사치스러운 사용법이라 눈치가 보이긴 했다.

**결과: 폰부스에서 작업한 날은 하루 3시간 15분.** 기준선의 거의 두 배. 물리적 분리의 효과는 확실했다.

**문제: 지속 불가능하다.** 폰부스가 세 개뿐인데 쓰려는 사람은 많다. 매일 확보하는 게 불가능하다. 회의실도 마찬가지. 점심 전후로 회의가 몰리면 빈 회의실이 없다. 한 달에 회의실을 혼자 쓸 수 있는 날이 5~6일 정도였다. 나머지 날은 자리에서 버텨야 한다.

물리적 탈출에 의존하면 근본적인 해결이 안 된다. 자리에서도 집중할 수 있는 방법이 필요했다.

## 전략 3: 슬랙 알림 끄기 (5~6주차)

슬랙 상태를 적극적으로 쓰기 시작했다. 집중할 때 상태를 "집중 모드 - 12시 이후 확인"으로 바꾸고, 알림을 전부 끈다. DM이든 채널이든 전부. 긴급한 건 전화해달라고 상태에 추가했다. 전화가 오면 진짜 급한 거고, 슬랙이면 나중에 봐도 되는 거다.

**결과: 일주일 평균 하루 2시간 31분.** 헤드폰만 쓸 때보다 19분 증가. 이 숫자가 의미하는 게 있다. 슬랙 알림을 끄는 게 소리를 차단하는 것보다 효과가 컸다. 생각해보면 당연하다. 헤드폰은 귀를 막지만, 슬랙 알림은 화면 오른쪽 하단에 뜨면서 시선을 잡아간다. 그리고 "누가 뭘 보냈지?"라는 궁금증이 생기면 안 보기가 힘들다. 알림 자체를 없애버리면 그 궁금증이 발생하지 않는다.

**문제: 불안감.** 알림을 끄면 "내가 놓치고 있는 게 있으면 어쩌지?"라는 불안이 올라온다. 처음 2주는 30분마다 알림을 켜서 확인했다. 의미 없는 짓이다. 켜서 확인하는 순간 집중이 끊기니까. 3주차부터 참는 데 익숙해졌다. 2시간 동안 알림 없이 작업하고, 한 번에 모아서 확인하는 패턴이 자리 잡았다. 2시간 동안 세상이 무너지는 일은 없었다.

## 전략 4: 팀 코어 타임 (7~8주차)

여기서 중요한 전환이 있었다. 전략 1~3은 전부 '나 혼자'의 해결책이다. 내가 헤드폰을 쓰고, 내가 자리를 피하고, 내가 알림을 끈다. 근데 방해의 원천은 '다른 사람'이다. 내가 아무리 차단해도 옆에서 모니터 너머로 "이거 잠깐만" 하면 끝이다.

스탠드업에서 제안했다. "오전 10시~12시를 팀 집중 시간으로 정하면 어떨까요? 이 시간에는 미팅 안 잡고, 급한 게 아니면 말도 안 걸기로." 이 말을 꺼내기까지 2주를 고민했다. "이런 말 하면 이기적인 사람처럼 보이지 않을까." 다행히 팀 리드가 바로 지지했다. "좋은 생각이네. 다른 사람도 비슷한 시간을 잡으면 어때?"

팀 전체가 오전 10시~12시를 코어 타임으로 합의했다. 한 번은 다른 팀 사람이 10시 30분에 와서 말을 거는데, 옆에 있던 팀원이 "지금 코어 타임이라 좀 이따 가능할까요?"라고 대신 말해줬다. 팀이 보호해주는 느낌이었다.

**결과: 일주일 평균 하루 3시간 2분.** 처음으로 3시간을 넘었다. 기준선 대비 약 75분 증가. 폰부스에서 혼자 작업한 것(3시간 15분)과 거의 비슷한 효과를 자리에서 냈다.

이게 가장 큰 발견이었다. 혼자 노력하는 것보다, 팀 합의가 훨씬 강력하다. "이 시간에 말을 걸면 안 된다"는 공감대가 있으면, 헤드폰을 안 써도 방해가 줄어든다. 사람들이 의식적으로 자제하니까.

Derek Sivers가 쓴 글 중에 "subtract" 이야기가 있다. 무언가를 추가해서 해결하려 하지 말고, 방해물을 제거하라는 철학이다. 그가 하는 말이 인상적이었다. "Successful people have narrow focus, protect themselves against time-wasters, and say no to almost everything." 좁은 집중, 시간 낭비 차단, 거의 모든 것에 거절. 노이즈 캔슬링 헤드폰은 도구를 '추가'하는 접근이다. 코어 타임은 방해를 '제거'하는 접근이다. 제거가 더 효과적이었다. Sivers의 표현을 빌리면, "No amount of adding will get me to where I want to be." 더하기로는 원하는 곳에 도달할 수 없다.

## 전략 5: 작업 진입 의식 (9~10주차)

코어 타임이 정착되고 나서, 한 가지 더 실험했다. 물리적 환경은 어느 정도 정리됐으니, 이번에는 내 머릿속을 정리하는 시도였다.

코어 타임이 시작되는 10시에, 바로 코드를 열지 않는다. 먼저 3분 동안 종이에 적는다. "지금부터 2시간 동안 할 일" 딱 하나. "결제 페이지 에러 핸들링 구현" 같은 구체적인 문장. 그리고 그 문장을 모니터 옆에 붙인다.

이게 바보 같아 보이지만 효과가 있었다. 이유는 두 가지다.

첫째, 목표가 명확하면 '이것도 해야 하나 저것도 해야 하나' 하는 방황이 줄어든다. 코드를 열고 "뭐부터 하지?"로 시작하면 Jira를 뒤지고 슬랙을 확인하고 PR 리뷰를 보다가 30분이 지나간다. 이미 뭘 할지 정해놓으면 바로 시작할 수 있다.

둘째, 종이에 쓰는 행위 자체가 모드 전환 스위치 역할을 한다. "지금부터 집중 모드에 들어간다"는 신호를 뇌에 보내는 거다. 이걸 한 달 하니까, 종이를 펴는 순간 자동으로 집중 모드로 들어가는 조건 반사 비슷한 게 생겼다. James Clear의 습관 연구에서 말하는 '큐(cue)'와 같은 원리다. 특정 행동이 특정 상태를 유발하도록 반복해서 연결하는 것.

**결과: 일주일 평균 하루 3시간 24분.** 코어 타임만 할 때보다 22분 증가. 큰 차이는 아닌 것 같지만, 이 22분이 질적으로 달랐다. 코어 타임 2시간 중에서 처음 30분을 방황하던 게 사라지고 바로 작업에 들어가니까, 집중의 깊이가 달랐다.

## 전략 6: 방해 대응 프로토콜 (11~12주차)

마지막으로 실험한 건, 방해가 들어왔을 때의 대응 방식이다. 코어 타임에도 불구하고 방해는 들어온다. 프로덕션 이슈, 급한 질문, PM의 "이거 잠깐만." 문제는 방해 자체가 아니라, 방해에 어떻게 반응하느냐였다.

이전의 나는 방해가 들어오면 즉시 응답했다. 하던 작업을 멈추고, 질문에 답하고, 다시 돌아온다. 이 "다시 돌아오는" 과정에서 Gloria Mark 연구의 23분이 소비된다.

새로운 프로토콜은 이렇다. 방해가 들어오면 즉시 응답하지 않는다. 대신 종이에 한 줄 적는다. "내가 지금 어디까지 했는지." 예를 들어 "PaymentForm.tsx 34번 줄, catch 블록 에러 메시지 분기 작성 중." 이걸 적는 데 10초. 그 다음에 질문에 응답한다.

이게 왜 효과적이냐면, 재집중의 가장 큰 비용은 "내가 어디까지 했더라?"를 떠올리는 거기 때문이다. 복잡한 상태 머신 로직을 머릿속에 구축해놓은 상태에서 끊기면, 그 상태를 처음부터 재구축해야 한다. 어떤 변수가 어떤 값을 갖고 있었는지, 어떤 분기를 타고 있었는지, 전부 다시 떠올려야 한다. 근데 한 줄만 적어놓으면, 돌아왔을 때 "아, 여기까지 했구나" 하고 바로 이어갈 수 있다.

**재집중 시간이 15분에서 3~5분으로 줄었다.**

**결과: 일주일 평균 하루 3시간 41분.** 기준선(1시간 47분) 대비 약 2시간 증가.

## 3개월의 데이터가 말해주는 것

6가지 전략의 효과를 정리하면 이렇다.

| 전략 | 일평균 집중 시간 | 기준선 대비 |
|---|---|---|
| 기준선 (아무것도 안 함) | 1시간 47분 | - |
| 노이즈 캔슬링 헤드폰 | 2시간 12분 | +25분 |
| 슬랙 알림 끄기 | 2시간 31분 | +44분 |
| 팀 코어 타임 | 3시간 2분 | +75분 |
| 작업 진입 의식 | 3시간 24분 | +97분 |
| 방해 대응 프로토콜 | 3시간 41분 | +114분 |

놀라운 패턴이 하나 보인다. 물리적 환경을 바꾸는 것(헤드폰, 폰부스)보다 정신적 프로토콜(코어 타임, 진입 의식, 대응 프로토콜)이 훨씬 효과가 컸다. 직감적으로는 소음을 차단하면 집중이 될 것 같지만, 실제로는 소음 차단은 전체 개선의 22%(25분/114분)밖에 차지하지 않았다.

이유를 생각해봤다. 오픈 오피스에서 집중을 방해하는 건 소리만이 아니다. 시각적 움직임, 슬랙 알림, "누가 날 찾지 않을까"라는 불안, "뭐부터 하지"라는 방황, 중단 후 재집중의 비용. 이것들은 헤드폰으로 해결되지 않는다. 전부 머릿속에서 일어나는 일이다.

코어 타임은 "말 걸어도 되나?"라는 상대방의 판단을 바꿔주고, 진입 의식은 "뭐부터 하지?"를 없애주고, 대응 프로토콜은 재집중 비용을 줄여준다. 하드웨어가 아니라 소프트웨어를 업데이트한 거다.

## 오픈 오피스의 장점도 있다

불만만 쓰면 안 될 것 같다. 오픈 오피스가 나쁘기만 한 건 아니다.

옆자리 백엔드 개발자와 API 스펙을 논의할 때, 모니터를 돌려가며 바로 이야기할 수 있다. 디자이너에게 "여기 패딩이 12px이야 16px이야?" 하면 3초 만에 답이 온다. 피그마 코멘트 남기고 답변 기다리는 시간이 없다. 팀의 분위기를 느낄 수 있는 것도 장점이다. 누군가 한숨을 쉬면 "뭐 힘든 거 있어?"라고 물어볼 수 있다.

소통이 쉬운 만큼 방해도 쉽다. 이 균형을 찾는 게 핵심인데, 나는 코어 타임이라는 경계선으로 어느 정도 해결했다고 생각한다. 10시~12시는 집중, 나머지는 소통. 완벽하지 않지만 양쪽 모두를 살리는 타협점이다.

## 남은 것

3시간 41분으로 올렸지만, 회사에 9시간 있는 것 대비 아직 41%다. 이 이상 올리기는 어려울 것 같다. 미팅, 코드 리뷰, 소통은 줄일 수 없는 일이고, 그것 자체가 가치 있는 일이니까.

가끔 완전 리모트인 회사에 다니는 친구가 부럽다. "나는 하루에 5~6시간은 코딩에 쓸 수 있어"라는 말을 들으면 진심으로 부럽다. 근데 그 친구도 "집에서 혼자 일하니까 외로워서 코워킹 스페이스를 전전한다"고 한다. 코워킹 스페이스도 결국 오픈 오피스와 비슷한 환경이다. 어디서든 트레이드오프가 있다.

내일도 오전 10시에 종이를 펴고, "오늘 할 일" 한 줄을 적고, 코드를 열 거다. 1시간 47분에서 시작해서 3시간 41분까지 온 건, 나쁘지 않다고 생각한다.



외주 개발이 점점 어려워지고 있습니다. 그냥 어려워지는 게 아닙니다. 이 변화의 흐름을 읽지 못하면 몇 년 뒤 개발자로 살아남기 어려울 수도 있습니다.

AI 혁명의 초기 시장이 지금 펼쳐지고 있습니다. 이걸 제대로 활용하면 큰 기회를 잡을 수 있지만, 가만히 있으면 있는 직장까지 위험할 수 있습니다.

## 외주 개발이 점점 힘들어지는 5가지 이유

### 1. 개발자 공급 증가와 경쟁 심화

예전에는 개발자 수가 적어서 프리랜서 외주 시장이 활발했습니다. 하지만 이제는 부트캠프, 국비지원 교육, 온라인 강의 등으로 개발자가 급증했습니다.

프리랜서 개발자 수가 늘어나면서 경쟁이 심해졌고, 단가도 낮아지고 있습니다. 단순 실력만으로는 더 이상 차별화가 어려운 상황이 된 것입니다.

### 2. AI 및 자동화 도구 발전

GPT 기반의 AI 개발 도구, 노코드/로우코드 플랫폼(버블, 웹플로우 등)이 나오면서 단순한 웹 서비스나 챗봇 같은 건 개발자 없이도 만들 수 있는 시대가 되었습니다.

특히 기업들이 내부에서 AI 코딩 도구를 활용하거나 GPT 같은 기술을 도입하면서 외주 의존도가 줄어드는 경향이 있습니다.

### 3. 해외 개발자와의 가격 경쟁

위시켓, 파이버, 업워크 같은 글로벌 플랫폼을 통해 인도, 베트남, 동남아 개발자들과 직접 경쟁해야 하는 시대입니다.

한국 개발자들이 받는 시급이 동남아, 인도 개발자보다 높다 보니 가격 경쟁에서 밀리는 경우가 생깁니다. 특히 웹이나 모바일앱 개발은 국경의 제약이 적어서 해외 아웃소싱이 늘어나는 추세입니다.

### 4. 경기 침체로 신규 프로젝트 감소

경제가 어려워지면서 많은 기업들이 불필요한 신규 프로젝트를 줄이고 유지보수 위주로 운영하는 경향이 강해지고 있습니다. 자연스럽게 외주 시장의 일도 줄어들 수밖에 없습니다.

### 5. 저가형 외주 시장 확산

크몽, 위시켓, 숨고 같은 외주 플랫폼들이 활성화되면서 가격 경쟁이 심해지고 있습니다. 기업들이 여러 개발자를 비교하면서 최저가로 계약하려는 경향이 강해지고, 결과적으로 개발자들의 단가가 계속 낮아지는 문제가 생기는 것입니다.

**한마디로, 외주 개발 프리랜서만으로 먹고 살려는 건 추천드리지 않습니다.** 부업 포지션으로 가져가는 게 현실적입니다.

## 직장인 개발자라면 어떻게 해야 할까?

일단 지금 다니는 직장을 그만두면 다시 취업하기 쉽지 않습니다. 직장은 유지하되, 다음을 염두에 두세요.

### AI 활용 개발 방식 익히기

지금부터라도 AI를 활용한 개발 방식에 익숙해져야 합니다. 자동화, 데이터 분석, AI 기반 서비스 개발 능력을 키우는 게 필수입니다.

### 사이드 프로젝트 운영하기

회사를 다니면서도 나만의 사이드 프로젝트를 운영하는 습관을 가져야 합니다. AI 시대에는 나 혼자서도 수익을 낼 수 있는 능력을 갖춘 사람이 살아남습니다.

## 1인 개발자로 외주나 창업을 준비한다면?

### 단순 웹 개발 외주는 이제 어렵다

가격 경쟁에서 밀리거나 외주를 따기가 힘들 수 있습니다. 현재 인맥만으로 먹고 살아보겠다는 건 **99% 확률로 실패**합니다.

관련 커뮤니티, 오픈 카톡방, 카페 등에서 하루 종일 활동해서 일을 따내는 방법도 있지만, 정말 어렵고 지속 가능하지도 않습니다.

### 지속적인 수익 모델 만들기

단기적인 외주보다 **지속적인 수익 모델**을 만들어야 합니다.

```
- 웹사이트 한 번 만들어 주고 끝내는 게 아니라
- 월구독 유지보수 서비스를 제공해서 장기 계약 유도
- 앱이나 웹 서비스를 직접 운영하며 광고 수익 창출
```

### 해외 시장 공략

한국에서는 가격 경쟁이 치열하지만, 해외 고객들은 기술력만 확실하다면 훨씬 높은 비용을 지불할 의사가 있습니다.

### 퍼스널 브랜딩

1인 개발자로 활동하려면 **퍼스널 브랜딩이 중요**합니다. 블로그, 유튜브, SNS 등을 활용해 본인의 기술력과 경험을 꾸준히 공유하세요. 그렇게 하면 자연스럽게 고객이 찾아오는 구조를 만들 수 있습니다.

## 요약

지금은 AI 혁명의 초입입니다. 이 기회를 활용하면 엄청난 부를 얻을 수도 있지만, 준비하지 않으면 몇 년 뒤에 도태될 수도 있습니다.

외주 개발 시장이 어려워지는 건 사실이지만, 개발자로 살아남을 방법이 없는 건 아닙니다. **중요한 건 변하는 시장에서 나만의 차별화된 강점을 만드는 것**입니다.

| 상황 | 해야 할 것 |
|------|-----------|
| 직장인 개발자 | AI 익히고, 사이드 프로젝트 시작하기 |
| 1인 개발자 지망 | 차별화된 기술 갖추고, 장기 수익 모델 만들기 |

변화에 적응하는 개발자만이 살아남습니다.



우리 팀에는 아키텍트가 없다. 공식적으로 "프론트엔드 아키텍처를 결정하는 사람"이라는 역할은 존재하지 않는다. 그런데 아키텍처 결정은 매일 일어난다. 폴더 구조를 어떻게 잡을지, 상태 관리를 뭘로 할지, API 호출 레이어를 어디에 둘지, 에러 처리 패턴을 어떻게 통일할지. 이런 결정들이 코드베이스의 형태를 만든다.

문제는, 이 결정들이 "결정"의 형태로 이루어지지 않는다는 거다.

## 먼저 머지하는 사람이 이긴다

현실은 이랬다. 누군가 새로운 기능을 만들면서 특정 패턴을 도입한다. PR이 올라오고, 리뷰어가 "LGTM"을 누르고, 머지된다. 다음에 비슷한 기능을 만드는 사람이 코드를 참고하면서 자연스럽게 같은 패턴을 따른다. 몇 번 반복되면 그게 "팀의 패턴"이 된다.

아무도 이걸 결정한 적 없다. 회의도 없었고, 문서도 없었고, 합의도 없었다. 단지 처음에 머지된 코드가 기정사실이 된 것뿐이다.

이게 잘 돌아가는 경우도 있다. 팀원의 실력이 고르고, 암묵적으로 공유하는 기준이 비슷하면 큰 문제 없이 흘러간다. 하지만 팀이 커지거나 새로운 사람이 들어오면 균열이 생긴다.

한번은 이런 일이 있었다. 프로젝트 내에서 API 호출 방식이 세 가지였다. 한 사람은 `fetch`를 직접 래핑해서 쓰고, 다른 사람은 `axios` 인스턴스를 만들어서 쓰고, 또 다른 사람은 React Query의 `queryFn` 안에 바로 `fetch`를 넣어서 쓰고 있었다. 셋 다 동작한다. 셋 다 나름의 이유가 있다. 하지만 코드베이스를 처음 보는 사람 입장에서는 혼란 그 자체다.

"왜 이 방식이에요?"라고 물으면 대답은 항상 비슷했다. "원래 이렇게 되어 있어서요." 원래라는 게 언제부터인지, 누가 정한 건지는 아무도 모른다.

## 결정의 부재가 만드는 비용

이런 상태가 지속되면 눈에 보이지 않는 비용이 쌓인다.

**온보딩 비용.** 새로운 팀원이 들어올 때마다 "이건 왜 이래요?"라는 질문에 답해야 한다. 일관된 패턴이 없으니 문서화도 불가능하다. "이 폴더에서는 A 방식이고, 저 폴더에서는 B 방식인데, 최근 것은 C 방식으로 가고 있어요"라는 식의 구두 설명을 매번 반복한다.

**의사결정 피로.** 매번 코드를 쓸 때마다 "이걸 어떤 방식으로 하지?"를 고민해야 한다. 팀 컨벤션이 명확하면 생각 없이 따르면 되는 것들을, 매번 판단해야 한다. 사소해 보이지만 하루에 열 번씩 이런 판단을 하면 실제 비즈니스 로직에 쓸 에너지가 줄어든다.

**코드 리뷰에서의 불필요한 논쟁.** 기준이 없으니 코드 리뷰가 취향 싸움이 되기 쉽다. "저는 이 방식이 더 깔끔하다고 생각하는데요"라는 코멘트에 "저는 이 방식이 더 직관적이라고 보는데요"라는 답이 달린다. 둘 다 틀리지 않았다. 기준이 없기 때문에 뭐가 맞는지 판단할 근거도 없다.

Pragmatic Engineer 블로그에서 읽은 내용이 떠올랐다. 엔지니어링 조직에서 기술적 의사결정이 암묵적으로 이루어지면, 그 결정의 맥락이 사라진다는 거다. 왜 A가 아니라 B를 선택했는지, 당시 어떤 제약 조건이 있었는지, 어떤 대안을 검토했는지. 이런 맥락 없이 코드만 남으면, 나중에 그 결정을 뒤집어야 할 때도 근거가 없다. "왜 이렇게 했는지 모르니까 건드리지 말자"가 된다.

## ADR이라는 걸 알게 되다

ADR(Architecture Decision Record)을 처음 접한 건 기술 블로그를 읽다가였다. 개념은 단순하다. 아키텍처에 관한 결정을 내릴 때, 그 결정의 배경, 고려한 대안, 선택의 이유, 예상되는 결과를 문서로 남기는 거다.

형식은 간단하다.

```markdown
# ADR-001: API 호출 레이어 통일

## 상태
승인됨 (2025-09-15)

## 맥락
현재 프로젝트 내에서 API 호출 방식이 fetch 래퍼, axios 인스턴스,
queryFn 직접 호출 등 세 가지로 혼재되어 있다.
새로운 팀원의 온보딩 시 혼란을 유발하고 있다.

## 결정
모든 API 호출은 /api 디렉토리의 함수로 정의하고,
컴포넌트에서는 React Query를 통해서만 서버 데이터에 접근한다.
HTTP 클라이언트는 fetch를 기본으로 하되,
인터셉터가 필요한 경우 래퍼 함수를 사용한다.

## 대안
1. axios 인스턴스 통일 - 번들 사이즈 고려로 기각
2. 현상 유지 - 혼란 지속으로 기각

## 결과
- 기존 코드는 새로 작성하거나 수정할 때 점진적으로 마이그레이션
- 신규 코드는 반드시 이 패턴을 따름
```

이걸 읽고 "우리 팀에 필요한 게 정확히 이거다"라고 생각했다. 결정 자체보다 "결정의 기록"이 중요하다는 관점이 신선했다.

## 팀에 제안했을 때의 반응

다음 주 회고에서 ADR을 제안했다. 반응은 내 예상과 많이 달랐다.

첫 번째 반응은 침묵이었다. 팀 리드가 "그거 좋은 생각인데"라고 했지만, 나머지 팀원들은 표정이 애매했다. 한 시니어가 질문했다. "그걸 누가 작성해요?" 또 다른 사람은 "문서를 또 쓰라고요? 코드 짜기도 바쁜데?"라고 했다.

예상했어야 했는데, 솔직히 이 반응에 좀 상처받았다. 팀의 문제를 해결하자는 건데 왜 귀찮다는 반응이 먼저 나올까.

며칠 후 시니어와 1:1에서 이 얘기를 다시 꺼냈다. 시니어가 솔직하게 말해줬다. "취지는 좋은데, 문서를 쓰는 게 개발자한테는 진입 장벽이 높아. 코드 리뷰는 무조건 해야 하니까 하는 거지, 문서는 안 써도 당장 뭐가 달라지지 않으니까." 그리고 덧붙였다. "한 번에 프로세스를 바꾸려고 하면 안 돼. 니가 먼저 몇 개 써봐. 그게 유용하다는 걸 보여주면 자연스럽게 따라온다."

## 혼자 시작하기

시니어의 조언을 따랐다. 팀 전체에 "앞으로 ADR 씁시다"라고 선포하는 대신, 조용히 혼자 시작했다.

마침 프로젝트에서 에러 바운더리 전략을 정해야 하는 시점이었다. 페이지 레벨에서 잡을지, 컴포넌트 레벨에서 잡을지, 어떤 에러는 무시하고 어떤 에러는 폴백 UI를 보여줄지. 이걸 그냥 코드로 구현하는 대신, 먼저 ADR을 작성했다.

배경, 세 가지 대안, 각 대안의 장단점, 최종 선택과 이유. A4로 한 장 반 정도. 이걸 PR에 함께 올렸다. "에러 바운더리 구현인데, 왜 이 방식을 선택했는지 ADR로 정리했습니다."

의외의 일이 벌어졌다. 코드 리뷰 코멘트가 구현 디테일이 아니라 ADR에 달렸다. "대안 2번의 단점에서 이 부분은 좀 다르게 볼 수도 있지 않나요?"같은 코멘트. 코드에 대한 논쟁이 아니라, 결정에 대한 논의가 이루어졌다. 이게 완전히 다른 대화였다.

한 팀원이 슬랙에서 말했다. "ADR 덕분에 왜 이런 구조인지 코드 안 봐도 이해가 됐다. 리뷰하기 편했다." 이게 첫 번째 성공이었다.

## 천천히 퍼지다

두 번째 ADR은 이미지 최적화 전략에 대한 것이었다. 세 번째는 폼 상태 관리 패턴에 대한 것. 이쯤 되니 팀원 한 명이 자기가 맡은 기능에서도 ADR을 써봤다. "비슷한 형식으로 쓰면 되는 거죠?"

두 달쯤 지나자 ADR이 10개가 됐다. 이때부터 진짜 효과가 나타났다.

새로운 팀원이 입사했을 때, "이 프로젝트 구조는 왜 이래요?"라는 질문에 "ADR 폴더를 먼저 읽어보면 흐름이 이해될 거예요"라고 말할 수 있게 됐다. 예전에는 커피 한 잔 놓고 30분씩 구두 설명을 해야 했던 것들이다.

코드 리뷰에서의 논쟁도 줄었다. "이거 왜 이렇게 했어요?"라는 질문에 "ADR-007 참고해주세요"로 끝나는 경우가 생겼다. 결정의 맥락이 기록되어 있으니, 같은 논의를 반복하지 않아도 된다.

기존 결정을 뒤집어야 할 때도 근거가 생겼다. 6개월 전에 A를 선택한 이유가 "당시에는 서버 컴포넌트 지원이 불안정해서"였는데, 지금은 안정화됐다면 그 근거가 사라진 거다. ADR에 "폐기됨: ADR-012로 대체"라고 쓰면 된다. 결정이 바뀌는 과정까지 추적할 수 있다.

## 실패한 것들

전부 성공적이었다고 하면 거짓말이다.

**너무 많이 쓰려고 했다.** 초반에는 사소한 결정까지 ADR로 남기려고 했다. "버튼 컴포넌트의 기본 패딩 값"같은 것까지. 이건 오버킬이다. ADR은 뒤집기 어려운 결정, 팀 전체에 영향을 미치는 결정에만 쓰는 게 맞다. 사소한 건 코드 컨벤션 문서로 충분하다.

**형식에 집착했다.** 초반에 ADR 템플릿을 너무 정교하게 만들었다. 필수 항목 10개짜리. 아무도 이 템플릿을 쓰고 싶어하지 않았다. 나중에 세 항목으로 줄였다. 맥락, 결정, 이유. 이것만 있으면 충분하다. 형식보다 내용이다.

**합의를 강제하려 했다.** 모든 ADR에 팀 전원의 승인을 받으려고 했는데, 현실적으로 어려웠다. 일정에 쫓기는 팀원이 "바빠서 못 봤는데 그냥 진행하세요"라고 하면 그게 합의인가 아닌가. 결국 "작성자 + 리뷰어 1명"이면 충분하다는 현실적인 기준으로 바꿨다.

## 결국 사람의 문제다

ADR을 도입하면서 깨달은 건, 기술적 의사결정의 문제는 결국 기술의 문제가 아니라 커뮤니케이션의 문제라는 거다.

"먼저 머지하는 사람이 이기는" 구조가 나쁜 건, 그 결정이 나쁘기 때문이 아니다. 그 결정에 참여하지 못한 사람이 있기 때문이다. 좋은 코드를 머지한 것과, 합의된 코드를 머지한 것은 다르다. 전자는 개인의 능력이고, 후자는 팀의 역량이다.

ADR은 도구일 뿐이다. 중요한 건, 결정을 투명하게 만들고, 맥락을 공유하고, 누구나 의견을 낼 수 있는 구조를 만드는 거다. ADR이 아니라 슬랙 스레드여도 되고, 노션 페이지여도 된다. 형태는 중요하지 않다. "왜 이렇게 했는지"가 어딘가에 남아 있는지가 중요하다.

아키텍트가 없는 팀에서 아키텍처를 결정하는 건 누구인가. 결론은 팀 전체다. 하지만 "팀 전체"가 결정에 참여하려면, 결정이 눈에 보여야 한다. 보이지 않는 결정에는 참여할 수 없다.

우리 팀은 지금도 아키텍트가 없다. 하지만 아키텍처 결정은 더 이상 우연히 일어나지 않는다. 여전히 완벽하지는 않지만, 적어도 "이걸 왜 이렇게 했는지"를 물었을 때 "모르겠다"가 아닌 답을 할 수 있게 됐다. 그게 작은 차이 같지만, 팀의 일하는 방식을 완전히 바꿔놓은 차이였다.


작년 여름, 이직을 결심하고 프로그래머스를 열었다. 레벨 2 문제 하나를 골라 풀기 시작했는데, 30분이 지나도 for 루프 하나 제대로 못 짰다. 매일 React 코드를 수백 줄씩 쓰는 사람이, 배열에서 조건에 맞는 값을 찾는 문제 앞에서 멍하니 앉아 있었다.

현실 자각이 빨리 온 건 다행이었다. 프론트엔드 개발자라고 해서 프론트엔드만 시키는 회사는 거의 없다. 토스, 카카오, 네이버, 라인 — 이런 회사들은 전부 코딩 테스트를 본다. 그것도 알고리즘만이 아니라, 과제형 테스트에 라이브 코딩까지 조합해서.

3개월 동안 준비했다. 그 과정에서 효과 있었던 것, 완전히 시간 낭비였던 것이 꽤 뚜렷하게 갈렸다.

## 프론트엔드 코딩 테스트의 세 가지 유형

먼저 지형도부터 파악하자. 내가 지원한 6개 회사의 전형을 정리해 보면 이런 패턴이었다.

**알고리즘 테스트**: 프로그래머스나 자체 플랫폼에서 2~4문제, 제한 시간 2시간 내외. 카카오, 네이버가 대표적이다. 보통 1차 필터 역할을 한다.

**과제형 테스트**: "이 API를 사용해서 검색 기능이 있는 고양이 사진 갤러리를 만드세요" 같은 과제를 3일~1주일 안에 제출. 토스 프론트엔드 챌린지가 유명하고, 중소 스타트업에서도 많이 쓴다.

**라이브 코딩**: 면접관 앞에서 실시간으로 코드를 짠다. 화면 공유를 켜고, 문제를 받고, 풀어 나간다. 보통 30분~1시간. 이게 제일 긴장된다.

회사마다 조합이 다르다. 카카오는 알고리즘 → 면접이고, 어떤 스타트업은 과제형만 보기도 한다. 내가 지원한 한 곳은 알고리즘 + 과제형 + 라이브 코딩을 전부 다 봤다. 각각 평가하는 게 다르기 때문에 준비 방법도 달라야 한다.

## 알고리즘: 프론트엔드에 필요한 범위는 생각보다 좁다

이걸 일찍 깨달았으면 한 달은 아꼈을 거다.

처음에 나는 "코딩 테스트 준비" 하면 떠오르는 그 루트를 탔다. 백준에서 DP 문제를 풀고, 세그먼트 트리를 공부하고, 위상 정렬을 보고. 한 달을 그렇게 썼다. 결과? 실제 시험에서 DP가 나온 적은 딱 한 번, 그것도 점화식이 단순한 레벨이었다. 세그먼트 트리는 당연히 안 나왔다.

프론트엔드 코딩 테스트에서 실제로 자주 나오는 주제는 이렇다:

- **문자열 처리**: 파싱, 변환, 정규표현식. 프론트엔드가 결국 사용자 입력을 다루는 일이라 그런지 체감상 가장 자주 나왔다.
- **배열/객체 조작**: 정렬, 필터링, 그룹핑, 중복 제거. JavaScript의 `Array.prototype` 메서드를 자유자재로 쓸 수 있는지.
- **BFS/DFS**: 그래프 탐색보다는 트리 구조 탐색이 많이 나온다. DOM 트리를 생각하면 왜 나오는지 이해가 된다.
- **구현**: 말 그대로 "요구사항을 정확히 구현할 수 있느냐". 시뮬레이션 문제에 가까운 것들.

반면에 시간 낭비였던 것들:

- 고난도 DP (배낭 문제, LIS 변형 등)
- 고급 그래프 알고리즘 (다익스트라, 플로이드-워셜)
- 복잡한 자료구조 (세그먼트 트리, 트라이)

물론 네이버나 카카오 3번, 4번 문제에서 가끔 나온다. 하지만 프론트엔드 지원자가 그 문제까지 풀어야 통과하는 경우는 드물다. 1~2번을 빠르고 정확하게 푸는 게 3~4번을 끙끙대다 시간 날리는 것보다 훨씬 낫다.

## 내가 실제로 따른 알고리즘 학습 경로

프로그래머스 레벨 1에서 시작했다. 자존심 상했지만 필요한 과정이었다. JavaScript 내장 메서드의 감을 되찾는 시간이라고 생각했다.

```javascript
// 프로그래머스 "같은 숫자는 싫어" - 레벨 1
// 이런 문제부터 시작했다
function solution(arr) {
  return arr.filter((val, idx) => val !== arr[idx + 1]);
}
```

이렇게 간단한 문제도 처음엔 `for` 루프로 풀려고 했다. filter 한 줄이면 되는 걸. 실무에서 매일 쓰는 메서드인데도 "알고리즘 문제"라는 프레임이 씌워지니까 갑자기 기본부터 흔들렸다. 이런 감각을 되찾는 데 1주일 정도 걸렸다.

레벨 1을 20문제 정도 풀고 나서 레벨 2로 올렸다. 여기가 핵심 구간이다. 프론트엔드 코딩 테스트의 1~2번 문제가 대략 이 난이도에 해당한다.

```javascript
// 프로그래머스 "기능개발" - 레벨 2
// 큐 개념을 활용하는 문제. 이런 류가 실제 시험에도 잘 나온다.
function solution(progresses, speeds) {
  const answer = [];
  const days = progresses.map((p, i) => Math.ceil((100 - p) / speeds[i]));

  let maxDay = days[0];
  let count = 1;

  for (let i = 1; i < days.length; i++) {
    if (days[i] <= maxDay) {
      count++;
    } else {
      answer.push(count);
      maxDay = days[i];
      count = 1;
    }
  }
  answer.push(count);
  return answer;
}
```

레벨 2를 약 50문제 풀었다. 그 다음 백준 골드 하위(골드 5~4)로 넘어갔다. 여기서 BFS/DFS와 구현 문제를 집중적으로 풀었다. 이 단계에서 효과적이었던 건 문제를 유형별로 묶어서 푸는 것이었다. BFS를 일주일 동안 10문제, 그다음 주에 문자열 10문제. 이렇게 하면 패턴이 몸에 배인다.

하루에 몇 문제를 풀었냐고? 평일에는 출근 전 1문제, 주말에는 3~4문제. 이 페이스를 2개월 유지했다. 총 100문제 좀 넘게 풀었다. "하루 5문제씩 풀었다"는 후기들을 보면 대단하다고 느끼겠지만, 회사 다니면서 그 페이스를 유지하는 건 현실적으로 불가능했다.

## 과제형 테스트: 여기서 진짜 차이가 난다

알고리즘이 "통과/탈락" 필터라면, 과제형은 "이 사람이 실제로 어떻게 일하는지"를 보는 테스트다.

내가 받았던 과제 중 하나는 이랬다. 공개 API를 사용해서 이미지 검색 앱을 만들어라. 기능 요구사항은 검색, 페이지네이션, 상세 보기. 기한은 5일.

기능 자체는 어렵지 않다. 솔직히 하루면 "동작하는" 수준으로는 만들 수 있다. 하지만 과제형에서 평가하는 건 "동작하느냐"가 아니다. 어떤 구조로 짰는지, 에러는 어떻게 처리했는지, 코드를 읽는 사람을 얼마나 배려했는지를 본다.

### 폴더 구조

과제를 제출하고 나서 면접에서 들은 피드백 중 기억나는 게 있다. "폴더 구조를 보면 이 사람이 어떤 규모의 프로젝트를 해봤는지 감이 온다"는 말이었다.

```
src/
├── components/
│   ├── common/
│   │   ├── Button.tsx
│   │   ├── Input.tsx
│   │   └── ErrorFallback.tsx
│   └── search/
│       ├── SearchBar.tsx
│       ├── SearchResults.tsx
│       └── ImageCard.tsx
├── hooks/
│   ├── useDebounce.ts
│   └── useIntersectionObserver.ts
├── api/
│   ├── client.ts
│   └── imageApi.ts
├── types/
│   └── image.ts
└── utils/
    └── formatDate.ts
```

거창한 구조가 아니다. 하지만 컴포넌트가 역할별로 분리되어 있고, API 호출 로직이 컴포넌트 밖에 있고, 커스텀 훅이 재사용 가능한 형태로 빠져 있다. 이것만으로도 "이 사람은 관심사 분리를 안다"는 인상을 준다.

### 에러 핸들링

과제형에서 제일 차별화되는 포인트가 에러 핸들링이라고 나는 확신한다. 대부분의 지원자가 happy path만 구현한다. 검색이 잘 되는 경우, API가 정상 응답하는 경우, 네트워크가 빠른 경우. 그런데 현실은 그렇지 않다.

```tsx
// 이런 코드를 많이 본다
const { data } = await fetch(url);
return data.results.map(item => <ImageCard key={item.id} {...item} />);
```

```tsx
// 과제에서 이렇게 짜면 눈에 띈다
function SearchResults({ query }: { query: string }) {
  const { data, error, isLoading } = useImageSearch(query);

  if (isLoading) return <SearchSkeleton />;
  if (error) return <ErrorFallback error={error} onRetry={() => refetch()} />;
  if (data.results.length === 0) return <EmptyState query={query} />;

  return (
    <div className="grid grid-cols-3 gap-4">
      {data.results.map(image => (
        <ImageCard key={image.id} image={image} />
      ))}
    </div>
  );
}
```

로딩 상태, 에러 상태, 빈 결과 상태. 이 세 가지를 처리하는 것만으로도 과제의 수준이 확 올라간다. 거기에 retry 버튼까지 달면 "이 사람은 프로덕션을 경험해봤구나"라는 느낌을 준다.

### README의 힘

과제를 제출할 때 README를 대충 쓰거나 아예 안 쓰는 사람이 많다. 나도 처음엔 그랬다. "코드를 보면 알 텐데 뭘 굳이."

동료 프론트엔드 개발자 민지가 이직할 때 과제형 피드백을 공유해 줬는데, 면접관이 README를 먼저 읽었다고 했다. 코드를 실행하기도 전에. 그 말을 듣고 README에 공을 들이기 시작했다.

내가 쓴 README에 포함한 것들:

- 실행 방법 (clone → install → dev server 실행까지 복붙 가능하게)
- 기술 선택 이유 ("React Query를 쓴 이유: 서버 상태 캐싱과 자동 refetch가 필요했기 때문")
- 고민했던 지점 ("페이지네이션을 offset 방식 대신 cursor 방식으로 선택한 이유")
- 개선하고 싶은 부분 ("시간이 더 있었다면 이미지 lazy loading과 가상 스크롤을 적용했을 것")

마지막 항목이 특히 중요하다. 과제의 한계를 스스로 인식하고 있다는 걸 보여주기 때문이다. 면접에서 이 부분을 가지고 대화가 이어지는 경우가 많았다.

## 라이브 코딩: 손이 떨린다

라이브 코딩은 다른 차원의 테스트다.

혼자 방에서 문제를 푸는 것과, 화면 공유를 켜고 면접관이 지켜보는 가운데 코드를 치는 것은 완전히 다른 경험이다. 나는 첫 라이브 코딩에서 `Array.prototype.reduce`의 초기값을 까먹었다. 매일 쓰는 메서드다. 면접관 두 명이 보고 있으니까 머리가 하얘진 거다.

```javascript
// 긴장해서 이렇게 썼다
const sum = arr.reduce((acc, cur) => acc + cur);
// 빈 배열이 들어오면 에러가 난다는 걸 면접관이 물어보고 나서야 깨달았다

// 이렇게 했어야 했다
const sum = arr.reduce((acc, cur) => acc + cur, 0);
```

이런 사소한 실수가 쌓이면 자신감이 무너진다. 한 번 무너지면 그 다음부터는 쉬운 것도 어렵게 느껴진다.

라이브 코딩에서 평가하는 건 최종 결과물이 아니다. **문제를 풀어나가는 과정**을 본다. 어떤 질문을 하는지, 어떻게 접근하는지, 막혔을 때 어떻게 대처하는지.

내가 두 번째 라이브 코딩부터 적용한 방법이 있다.

**코드를 치기 전에 말로 먼저 설명한다.** "이 문제는 입력을 파싱해서 트리 구조로 만든 다음, DFS로 탐색하면 될 것 같습니다. 먼저 파싱 함수를 만들고, 그다음 탐색 로직을 짜겠습니다." 이렇게 로드맵을 깔아놓으면 중간에 막혀도 면접관이 내 의도를 알고 있으니까 힌트를 주기도 한다.

**모르면 모른다고 한다.** 한 라이브 코딩에서 정규표현식의 lookahead 문법이 필요한 상황이 있었다. 문법이 정확히 기억 안 났다. "lookahead가 필요한 건 아는데, 정확한 문법이 바로 떠오르지 않습니다. 일단 다른 방식으로 구현하고, 시간이 남으면 정규표현식으로 리팩토링해도 될까요?"라고 말했다. 면접관이 고개를 끄덕였고, 결과적으로 그 회사에서 오퍼를 받았다.

긴장을 관리하는 건 기술적인 준비만큼 중요하다. 나는 라이브 코딩 전에 친구한테 부탁해서 모의 면접을 3번 했다. Discord 화면 공유를 켜고, 친구가 프로그래머스에서 문제를 하나 골라서 불러주고, 내가 풀었다. 처음에는 친구 앞에서도 긴장했는데, 세 번째쯤 되니까 "누군가 보고 있는 상태에서 코드를 치는 것" 자체에 익숙해졌다. 이게 실전에서 꽤 도움이 됐다.

## 시간 낭비였던 것들

3개월 준비 기간 중 체감상 1개월은 비효율적으로 썼다. 돌아간다면 안 했을 것들.

**LeetCode hard 문제 풀기.** 영어 면접을 볼 것도 아니었고, 한국 회사 프론트엔드 코딩 테스트에서 LeetCode hard 수준이 나오는 경우는 거의 없다. 프로그래머스와 백준에 집중하는 게 맞다.

**알고리즘 이론서 정독.** '알고리즘 문제 해결 전략' 책을 펼쳐놓고 처음부터 읽기 시작했다. 좋은 책이지만 취준 기간에 읽을 책은 아니다. 문제를 풀다가 모르는 개념이 나오면 그때 찾아보는 게 맞다.

**완벽한 풀이에 집착하기.** 한 문제에 3시간씩 매달렸던 적이 있다. 30분 안에 방향이 안 잡히면 풀이를 보고 이해하는 게 훨씬 효율적이다. 풀이를 본 뒤 다음 날 다시 푸는 게 내 방식이었다.

## 각 유형별 실질적인 타임라인

내가 실제로 따른 3개월 스케줄이다.

**1개월 차**: 프로그래머스 레벨 1~2. 하루 1문제. JavaScript 기본기를 되살리는 시간. 주말에는 과제형 연습으로 간단한 토이 프로젝트를 하나 만들었다.

**2개월 차**: 프로그래머스 레벨 2 + 백준 골드 하위. BFS/DFS, 구현 문제 집중. 이 시기에 과제형 모의 연습을 2번 했다. 공개 API를 골라서 3일 안에 앱을 완성하는 자체 훈련이었다.

**3개월 차**: 실전 지원 시작. 알고리즘은 유지 모드로 하루 1문제만. 나머지 시간은 과제형 제출물 다듬기와 라이브 코딩 모의 연습에 썼다.

## 면접관이 진짜 보는 것

알고리즘 테스트에서는 "이 사람이 논리적으로 사고하는가"를 본다. 과제형에서는 "이 사람이 실무에서 어떤 코드를 짜는가"를 본다. 라이브 코딩에서는 "이 사람과 같이 일할 수 있는가"를 본다.

세 가지가 전부 다르다. 알고리즘만 잘해서는 안 되고, 코드만 잘 짜서도 안 되고, 커뮤니케이션만 좋아서도 안 된다. 근데 셋 다 완벽할 필요도 없다. 각각에서 "이 사람은 기본은 되는구나"라는 확신을 주면 된다.

나는 알고리즘에서 한 회사를 떨어졌고, 과제형에서 한 회사를 떨어졌고, 최종 면접에서 한 회사를 떨어졌다. 그리고 두 곳에서 오퍼를 받았다. 6전 2승. 이게 현실적인 숫자다.

준비 과정은 길고 지치지만, 한 가지 좋은 점이 있다. 코딩 테스트를 준비하면서 다시 기본기를 잡게 된다. `Array.prototype`의 메서드들을 다시 한번 훑게 되고, 평소에 안 쓰던 Map이나 Set을 써보게 되고, 시간 복잡도를 의식하면서 코드를 짜는 습관이 생긴다. 그게 실무에도 돌아온다. 내가 준비 기간에 익힌 `useDebounce` 커스텀 훅은 지금도 프로젝트에서 쓰고 있다.

누군가 "프론트엔드인데 알고리즘을 왜 봐야 하나"라고 물으면, 나는 이렇게 대답한다. 좋아서 하는 건 아니다. 하지만 이 과정을 거치면 분명히 더 나은 개발자가 돼서 나온다. 그리고 그 회사 뱃지를 달고 있으면 다음 커리어에서도 선택지가 넓어진다. 싫어도 해야 하는 게 있고, 해보면 남는 게 있다.


작년 여름, 백엔드 개발자 재원이형과 화상 미팅을 하면서 30분을 날렸다.

신규 주문 상세 페이지를 만들고 있었는데, API 응답에서 `items`가 배열 안에 객체로 오는 줄 알았다. Figma 보고 당연히 그렇겠거니 했다. 그런데 실제 응답은 `items`가 pagination된 별도 endpoint였고, 주문 정보에는 `itemIds`만 달랑 들어있었다. 나는 "이거 왜 items가 안 와요?"를 반복했고, 재원이형은 "아니 그건 원래 따로 호출하는 건데..."를 반복했다. 서로 다른 그림을 보면서 같은 단어를 쓰고 있었다.

미팅이 끝나고 나서야 깨달았다. 나는 REST API가 어떤 원칙으로 설계되는지를 전혀 몰랐다. Resource 단위로 endpoint가 나뉜다는 개념 자체가 없었으니, 왜 한 번에 다 안 주는지를 이해할 수 없었던 거다.

## HTTP, 생각보다 모르고 쓰고 있었다

프론트엔드 개발하면서 `fetch`나 `axios`를 매일 쓰지만, HTTP 자체를 제대로 이해하고 있는 건 아니었다.

상태 코드부터 그랬다. 200이면 성공, 400이면 에러, 500이면 서버 문제. 이 정도만 알고 있었다. 그런데 어느 날 API가 `201 Created`를 반환하는데 내 에러 핸들링 코드에서 `status === 200`만 체크하고 있어서 생성 성공인데 에러 토스트가 뜨는 버그가 났다. 그때 상태 코드를 제대로 공부했다.

```typescript
// 이렇게 쓰고 있었다
if (response.status === 200) {
  showSuccess();
} else {
  showError(); // 201도 여기로 빠짐
}

// 이렇게 바꿨다
if (response.ok) { // 200-299 전부 커버
  showSuccess();
}
```

작은 차이인데 이걸 모르면 버그가 된다.

그리고 CORS. 프론트엔드 개발자라면 한 번쯤 로컬에서 API 호출하다가 빨간 CORS 에러를 본 적 있을 거다. 나도 처음엔 "아 CORS 에러 났어요, 백엔드에서 풀어주세요"만 말할 줄 알았다. 왜 CORS가 존재하는지, preflight 요청이 뭔지, `Access-Control-Allow-Origin` 헤더가 어떻게 동작하는지는 몰랐다.

CORS는 브라우저의 보안 정책이다. 서버가 "이 origin에서 오는 요청은 허용해"라고 명시적으로 알려줘야 브라우저가 응답을 읽을 수 있다. 이걸 이해하면 "백엔드에서 풀어주세요"가 아니라 "staging 서버의 origin을 allow list에 추가해주실 수 있나요?"라고 구체적으로 요청할 수 있다. 백엔드 개발자 입장에서도 이렇게 말하는 프론트엔드가 훨씬 일하기 편하다.

헤더도 마찬가지다. `Content-Type`, `Authorization`, `Cache-Control` — 이런 기본 헤더들이 뭘 하는지 알면 디버깅 속도가 확 달라진다. Network 탭에서 request/response 헤더를 읽을 수 있게 되면, 문제가 프론트에 있는지 백엔드에 있는지를 스스로 판단할 수 있다.

## REST API 설계를 이해하면 협업이 달라진다

처음에 말한 재원이형과의 30분 헛소리 사건 이후로, REST API 설계 원칙을 공부했다. Roy Fielding의 논문까지 읽진 않았고, 실무에서 자주 쓰이는 패턴 위주로.

핵심은 **resource 중심 사고**다. REST에서 URL은 동사가 아니라 명사다.

```
# 이런 게 아니라
POST /getOrderDetail
POST /createNewOrder

# 이런 식이다
GET /orders/123
POST /orders
GET /orders/123/items
```

이걸 알고 나니까 API 문서를 읽는 속도가 빨라졌다. endpoint를 보면 "아, 주문이라는 resource 아래에 items가 sub-resource로 있구나"라는 게 바로 보인다. 새 페이지를 만들 때도 어떤 API를 호출해야 하는지 감이 온다.

그리고 한 가지 더. 백엔드가 왜 한 API에 모든 데이터를 안 담아주는지를 이해하게 됐다. 예전에는 "그냥 한 번에 다 주면 프론트에서 편한데 왜 나눠놓는 거야"라고 불만이 있었다. 근데 이유가 있다.

하나의 API에 너무 많은 데이터를 넣으면 그 API의 응답 시간이 느려진다. 주문 상세를 호출하는데 배송 추적, 리뷰, 추천 상품까지 전부 join해서 한 방에 주면 DB 쿼리가 무거워진다. 프론트에서는 화면에 보이는 영역만 먼저 로딩하고, 나머지는 lazy하게 호출하는 게 UX도 더 좋다. 백엔드의 설계 의도를 이해하면 "왜 이렇게 했어요?"가 "이렇게 나눠주셨으니 프론트에서 이렇게 호출할게요"로 바뀐다. 이 차이가 크다.

## 인증은 프론트엔드의 영역이기도 하다

JWT, 세션, OAuth. 이런 단어를 들으면 "그건 백엔드 일 아닌가?"라고 생각할 수 있다. 나도 그랬다. 근데 아니다. 토큰을 어디에 저장할지 결정하는 건 프론트엔드다.

한번은 로그인 기능을 구현하면서 JWT 토큰을 `localStorage`에 저장했다. 동작은 잘 됐다. 코드 리뷰에서 시니어분이 물었다.

> "XSS 공격으로 localStorage 털리면 어떻게 돼?"

대답을 못 했다. `localStorage`는 JavaScript로 자유롭게 접근할 수 있으니까, XSS 취약점이 하나라도 있으면 토큰이 통째로 노출된다. `httpOnly` 쿠키에 저장하면 JavaScript에서 접근이 불가능하니까 XSS에 안전하다. 대신 CSRF를 신경 써야 한다.

```typescript
// localStorage 방식 - XSS에 취약
const token = localStorage.getItem('accessToken');
fetch('/api/data', {
  headers: { Authorization: `Bearer ${token}` }
});

// httpOnly 쿠키 방식 - 브라우저가 자동으로 쿠키를 보냄
fetch('/api/data', {
  credentials: 'include' // 이것만 하면 된다
});
```

OAuth 흐름도 마찬가지다. "카카오 로그인 구현해주세요"라는 요구사항을 받으면, authorization code flow가 어떻게 돌아가는지를 알아야 한다. redirect URI 설정, authorization code를 받아서 백엔드에 넘기기, 백엔드가 access token을 받아서 유저 정보를 가져오는 흐름. 이걸 전체적으로 알아야 프론트에서 어디를 담당하는지가 명확해진다.

refresh token rotation이 뭔지, access token 만료 시 어떻게 갱신하는지, 401이 왔을 때 자동 refresh 후 원래 요청을 재시도하는 interceptor를 어떻게 짜는지. 이런 건 프론트엔드가 직접 구현해야 하는 영역이다.

## DB를 조금만 알면 질문이 달라진다

DB를 알아야 한다고 해서 SQL 마스터가 되라는 뜻이 아니다. 기본 개념 몇 가지만 알면 된다.

N+1 문제를 예로 들어보자. 주문 목록 API가 있다. 주문 10개를 가져온다. 그런데 각 주문마다 유저 정보를 별도로 조회한다. 결과적으로 쿼리가 1 + 10 = 11번 나간다. 주문이 100개면 101번. 이게 N+1 문제다.

프론트엔드 개발자가 이걸 알면 뭐가 좋은가? 주문 목록 페이지가 갑자기 느려졌을 때 "이 API 느린데 확인해주세요"가 아니라 "혹시 주문 목록 조회할 때 유저 정보를 N+1으로 가져오는 건 아닌가요?"라고 물을 수 있다. 백엔드 개발자 입장에서 이런 질문을 받으면 "오, 이 친구 좀 아는구나"가 되면서 소통 비용이 확 줄어든다.

인덱스 개념도 알아두면 좋다. "이 검색 API가 왜 2초나 걸려요?"라고 물을 때, 인덱스가 안 걸려있을 수 있다는 가능성을 떠올릴 수 있으면 대화가 빨라진다.

pagination도 마찬가지다. offset 기반과 cursor 기반의 차이를 알면, 무한 스크롤 구현할 때 왜 cursor 방식이 더 안정적인지 이해할 수 있다. 데이터가 실시간으로 추가되는 피드에서 offset 기반 pagination을 쓰면 같은 아이템이 중복으로 보이는 문제가 생긴다. 이런 걸 알면 설계 미팅에서 의견을 낼 수 있게 된다.

## Docker, 로컬에서 백엔드 한번 띄워봐라

이건 의외로 추천하고 싶은 건데, Docker로 로컬에서 백엔드를 띄워보는 경험이 프론트엔드 개발에 꽤 도움이 된다.

우리 팀은 `docker-compose.yml` 파일이 있어서 `docker-compose up` 하면 백엔드 서버, DB, Redis가 로컬에 뜬다. 처음에 이걸 모르고 항상 staging 서버에 붙어서 개발했다. staging이 불안정할 때마다 내 작업도 멈췄다. 어느 날 백엔드 동료가 "로컬에서 띄우면 되는데?"라고 하길래 한번 해봤다.

```bash
# 이게 전부다
git clone backend-repo
docker-compose up -d

# 로컬 백엔드가 localhost:8080에 뜬다
# 프론트 .env에서 API_URL만 바꾸면 끝
```

Docker를 깊이 알 필요는 없다. image, container, volume이 뭔지 정도. `Dockerfile`을 읽을 수 있는 정도면 충분하다. 이걸로 얻는 이점은 명확하다. staging 서버 상태에 의존하지 않고 독립적으로 개발할 수 있다. API 응답을 직접 수정해볼 수도 있다. 백엔드 코드에서 에러가 나면 로그를 직접 볼 수 있다.

`docker logs -f backend-container` 한 줄이면 백엔드 로그가 실시간으로 보인다. "이 API 호출하면 500 에러 나요"를 말하면서 동시에 "로그 보니까 NullPointerException이 이 라인에서 나네요"라고 말할 수 있으면 문제 해결 속도가 완전 다르다.

## 여기서 멈춰라

여기까지 읽으면 "오 그러면 Spring Boot도 배워볼까?" 같은 생각이 들 수 있다. 하지 마라.

나도 한때 그런 적 있다. 백엔드가 재밌어 보여서 NestJS로 사이드 프로젝트를 시작했다. Controller, Service, Repository 패턴을 배우고, TypeORM으로 DB 연동하고, JWT 인증까지 직접 구현했다. 2주 정도 재밌었다. 그런데 그 2주 동안 프론트엔드 실력은 1도 안 늘었다. 회사에서 맡은 성능 최적화 작업은 진전이 없었고, 팀에서 논의되던 디자인 시스템 구축에도 참여를 못 했다.

프론트엔드 개발자로서 가치를 만들어야 하는 영역은 프론트엔드다. 접근성, 성능 최적화, 상태 관리 아키텍처, 테스트 전략, 디자인 시스템. 이런 것들을 잘하는 게 먼저다. 백엔드 지식은 이 위에 얹는 양념이다.

내가 위에서 말한 것들 — HTTP 기본, REST 설계 원칙, 인증/인가 기초, DB 개념, Docker 로컬 환경 — 이 정도만 알면 된다. 깊이 팔 필요 없다. 각 주제별로 하루 이틀이면 실무에 필요한 수준은 충분히 채울 수 있다.

백엔드를 깊이 파는 프론트엔드 개발자보다, 백엔드를 적당히 이해하면서 프론트엔드를 깊이 파는 개발자가 팀에 훨씬 도움이 된다. 재원이형과의 30분 헛소리 이후로 백엔드 기초를 익히는 데 투자한 시간은 총 2주 정도였다. 그 2주의 투자로 이후 1년간의 협업 속도가 체감상 2배는 빨라졌다.

그러니까 결론은 이거다. 백엔드를 "할 줄 알" 필요는 없다. 백엔드 개발자가 하는 말을 "알아들을 수 있으면" 된다. 그 차이는 생각보다 작은 노력으로 만들 수 있다.



에러가 터져도 몰랐다. 사용자가 CS팀에 "화면이 안 떠요"라고 문의하면, CS팀이 슬랙에 올리고, 개발팀이 재현하려고 이것저것 시도해보고, 결국 콘솔에서 에러를 발견하는 흐름이었다. 사용자가 문의하지 않으면? 그냥 조용히 묻혔다.

이 흐름을 바꾸기로 했다. 에러가 발생하면 개발팀이 사용자보다 먼저 알아야 한다.

## Sentry 도입

에러 모니터링 서비스는 여러 가지가 있는데 Sentry를 골랐다. 이유는 단순하다. React, Next.js 공식 SDK가 잘 되어 있고, 소스맵 연동이 편하고, 무료 플랜으로 시작할 수 있다.

Next.js에 Sentry를 붙이는 건 `@sentry/nextjs` 하나면 된다:

```bash
npx @sentry/wizard@latest -i nextjs
```

위저드가 `sentry.client.config.ts`, `sentry.server.config.ts`, `sentry.edge.config.ts`, `next.config.js` 설정을 자동으로 만들어준다.

```typescript
// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1, // 성능 트레이싱 10%만 샘플링
  replaysSessionSampleRate: 0,
  replaysOnErrorSampleRate: 1.0, // 에러 발생 시 세션 리플레이 100% 수집
});
```

`tracesSampleRate`를 1.0으로 하면 모든 요청의 성능 데이터를 수집하는데, 프로덕션에서는 비용과 성능에 영향을 준다. 0.1~0.2 정도가 적당하다.

## 소스맵 연동

프로덕션 빌드는 코드가 minify되어 있어서 에러 스택트레이스가 이렇게 보인다:

```
TypeError: Cannot read properties of undefined (reading 'map')
    at a.render (main-abc123.js:1:23456)
```

어디서 터진 건지 전혀 모른다. 소스맵을 Sentry에 업로드하면 원본 코드 위치로 매핑해준다:

```
TypeError: Cannot read properties of undefined (reading 'map')
    at PostList (src/components/PostList.tsx:24:18)
```

`@sentry/nextjs`의 webpack 플러그인이 빌드 시 자동으로 소스맵을 업로드한다. `next.config.js`에서 `withSentryConfig`로 감싸면 끝:

```javascript
const { withSentryConfig } = require('@sentry/nextjs');

module.exports = withSentryConfig(nextConfig, {
  sourcemaps: {
    deleteSourcemapsAfterUpload: true, // 업로드 후 소스맵 삭제 (보안)
  },
});
```

<Callout type="warning">
소스맵을 프로덕션 서버에 남겨두면 누구나 원본 코드를 볼 수 있다. `deleteSourcemapsAfterUpload: true`로 Sentry에만 업로드하고 서버에서는 삭제하자.
</Callout>

## 노이즈 필터링

Sentry를 켜자마자 에러가 쏟아졌다. 하루에 수백 건. 대부분은 의미 없는 노이즈였다.

- 크롬 확장 프로그램이 주입한 스크립트 에러
- 봇 크롤러의 JavaScript 실행 실패
- 네트워크 순단으로 인한 fetch 실패
- 사용자가 탭을 닫으면서 발생하는 AbortError

이것들을 걸러내지 않으면 진짜 중요한 에러가 묻힌다.

```typescript
Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  ignoreErrors: [
    'AbortError',
    'ResizeObserver loop',
    'Non-Error promise rejection',
    /^Loading chunk \d+ failed/,
    /^Network request failed/,
  ],
  beforeSend(event) {
    // 크롬 확장 프로그램에서 발생한 에러 필터링
    const frames = event.exception?.values?.[0]?.stacktrace?.frames;
    if (frames?.some((frame) => frame.filename?.includes('extension://'))) {
      return null;
    }
    return event;
  },
});
```

`ignoreErrors`로 패턴 매칭하고, `beforeSend`에서 더 세밀한 필터링을 했다. 이걸로 노이즈의 80% 정도가 사라졌다.

## 의미 있는 컨텍스트 추가

에러 메시지만으로는 원인을 파악하기 어려울 때가 많다. "Cannot read properties of null"이 뜨면, 뭐가 null인데? 어떤 상황에서?

사용자 컨텍스트와 브레드크럼을 추가했다:

```typescript
// 로그인 후 사용자 정보 설정
Sentry.setUser({
  id: user.id,
  segment: user.plan, // free, pro, enterprise
});

// 중요한 액션에 브레드크럼 추가
function handlePayment(amount: number) {
  Sentry.addBreadcrumb({
    category: 'payment',
    message: `결제 시도: ${amount}원`,
    level: 'info',
  });
  // ...결제 로직
}
```

에러가 발생하면 Sentry 대시보드에서 "이 사용자가 어떤 경로로 이 페이지에 왔고, 어떤 버튼을 눌렀고, 어떤 API를 호출했는지" 타임라인으로 볼 수 있다.

## 슬랙 알림 파이프라인

Sentry에 에러가 쌓이는 것만으로는 부족하다. 팀이 Sentry 대시보드를 매일 확인할 리가 없으니까.

Sentry의 Alert Rules를 설정해서 슬랙으로 알림이 오게 했다:

- **새로운 이슈 발생:** 처음 보는 에러가 생기면 즉시 알림
- **이슈 회귀:** 해결했던 에러가 다시 발생하면 알림
- **빈도 임계값:** 같은 에러가 1시간에 50건 이상이면 알림 (대규모 장애 감지)

모든 에러를 다 슬랙에 보내면 채널이 묘지가 된다. "새로운 이슈"와 "회귀"만 보내는 게 핵심이다. 이미 알고 있는 에러는 Sentry에서 확인하면 된다.

## 에러 바운더리와 연동

React Error Boundary에서 Sentry에 추가 정보를 보내도록 했다:

```typescript
import * as Sentry from '@sentry/nextjs';

class ErrorBoundary extends React.Component<Props, State> {
  componentDidCatch(error: Error, errorInfo: React.ErrorInfo) {
    Sentry.withScope((scope) => {
      scope.setTag('boundary', this.props.name);
      scope.setExtra('componentStack', errorInfo.componentStack);
      Sentry.captureException(error);
    });
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback;
    }
    return this.props.children;
  }
}
```

어떤 Error Boundary에서 잡혔는지 태그로 남기니까, "결제 섹션에서 에러가 집중되고 있다" 같은 패턴을 빠르게 파악할 수 있었다.

## 도입 후

에러 발생부터 인지까지의 시간이 "CS 문의가 올 때까지"에서 "수 분 이내"로 줄었다. 배포 직후 에러가 급증하면 바로 알 수 있으니까 빠른 롤백 판단도 가능해졌다.

가장 큰 변화는 팀의 태도다. 예전에는 "에러가 있을 수도 있다" 정도의 막연한 불안이었다면, 이제는 "현재 미해결 이슈가 3건이고, 모두 낮은 빈도"라는 정량적인 상태 파악이 가능하다. 모르는 것보다 아는 게 낫다.



2년 전, 이직을 준비하면서 처음으로 기술 면접이란 걸 봤다. 면접관이 물었다. "클로저가 뭔가요?" 나는 속으로 쾌재를 불렀다. 이건 준비했던 거니까. "클로저는 함수와 그 함수가 선언된 렉시컬 환경의 조합으로, 외부 함수의 실행이 끝난 후에도 내부 함수가 외부 함수의 변수에 접근할 수 있는..." 면접관의 표정이 미세하게 변하는 걸 느꼈다. 그 다음 질문은 "그래서 실무에서 클로저를 어디에 쓰셨어요?"였는데, 나는 말문이 막혔다.

탈락했다. 면접 후기를 노션에 정리하면서 뭐가 잘못됐는지 곱씹어봤다. 내가 한 건 MDN 문서를 읊은 것뿐이었다. 면접관 입장에서 보면, "이 사람이 진짜 이해하고 있는 건가, 아니면 외운 건가"를 판별하는 가장 쉬운 방법이 후속 질문이다. 교과서 정의만 갖고 있으면 후속 질문에서 바로 무너진다.

그 뒤로 면접을 몇 번 더 보고, 반대로 면접관으로도 몇 번 들어가보면서 깨달은 게 있다. 면접관이 듣고 싶은 건 "정답"이 아니다. **어떤 경로를 거쳐서 그 답에 도달했는지**, 그 사고 과정을 보고 싶어한다.

## "React에서 state가 바뀌면 어떤 일이 일어나나요?"

이 질문을 받으면 대부분 이렇게 시작한다. "state가 바뀌면 리렌더링이 일어납니다." 틀린 말은 아닌데, 여기서 멈추면 아무 인상도 남기지 못한다. 면접관은 이미 알고 있는 사실을 확인하려고 이 질문을 하는 게 아니다.

붙는 답변은 흐름을 따라간다. `setState`가 호출되면 React는 즉시 렌더링을 하지 않는다. 업데이트를 큐에 넣고 batching 한다. React 18부터는 이벤트 핸들러 바깥의 `setTimeout`이나 `fetch` 콜백 안에서도 automatic batching이 된다는 점까지 말할 수 있으면 좋다.

```jsx
// React 18 이전: setTimeout 안의 setState는 각각 리렌더링을 트리거
setTimeout(() => {
  setCount(1);   // 리렌더링
  setFlag(true); // 리렌더링
}, 1000);

// React 18 이후: 자동으로 batching되어 한 번만 리렌더링
setTimeout(() => {
  setCount(1);   // batched
  setFlag(true); // batched → 리렌더링 1회
}, 1000);
```

그 다음은 reconciliation이다. React가 render phase에서 새로운 virtual DOM 트리를 만들고, 이전 트리와 비교(diffing)해서 실제로 바뀐 부분만 찾는다. 이때 fiber 아키텍처 덕분에 이 작업을 잘게 쪼개서 할 수 있고, 우선순위가 높은 업데이트를 먼저 처리할 수 있다는 점까지 이어가면 면접관의 눈빛이 달라진다.

핵심은 **단계를 구분해서 설명하는 것**이다. "state 변경 → batching → render phase(virtual DOM 생성) → diffing → commit phase(실제 DOM 업데이트)" 이 흐름을 자기 말로 풀어낼 수 있으면, 면접관은 "아 이 사람은 내부 동작을 이해하고 있구나"라고 판단한다.

한 가지 팁. 여기서 "저는 이 부분을 이런 상황에서 체감했는데요"라고 실무 경험을 연결하면 완전히 다른 차원의 답변이 된다. 예를 들어 "리스트를 렌더링하는데 key를 index로 줬다가 순서가 바뀔 때 input 값이 꼬이는 버그를 겪었어요. diffing에서 key를 기준으로 비교하니까 당연한 결과였죠"라는 식으로.

## 클로저, 이번에는 제대로

내가 망했던 그 질문. 지금이라면 이렇게 답할 것 같다.

정의부터 시작하되 한 문장으로 끝내고, 바로 실무 맥락으로 넘어간다. "함수가 자신이 생성될 때의 스코프를 기억하는 것"이면 충분하다. 면접관은 여기서 더 긴 정의를 원하지 않는다.

그 다음 `debounce`를 예로 드는 게 효과적이다.

```js
function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}
```

이 코드에서 반환된 함수는 `timer`와 `fn`에 계속 접근할 수 있다. `debounce`의 실행은 이미 끝났는데도. 이게 클로저다. 여기까지 하면 "아 이 사람 실무에서 써봤구나"라는 인상을 준다.

그런데 진짜 차별화되는 건 클로저가 **문제를 일으키는 경우**를 말할 수 있을 때다. React에서 흔히 겪는 stale closure 문제.

```jsx
function Timer() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // 항상 0 — stale closure
      setCount(count + 1); // 항상 1로만 설정됨
    }, 1000);
    return () => clearInterval(id);
  }, []); // 빈 의존성 배열이 원인

  return <div>{count}</div>;
}
```

의존성 배열이 비어 있으면 effect 안의 함수는 첫 렌더링 시점의 `count`를 캡처한 채로 계속 실행된다. 이게 클로저 때문에 생기는 버그라는 걸 설명하고, 해결법(`setCount(prev => prev + 1)` 같은 함수형 업데이트)까지 이어가면 된다.

면접에서 이런 식으로 답했을 때 면접관이 "정확해요"라고 하면서 자기 경험담을 꺼낸 적이 있다. 질문이 대화로 바뀌는 순간이 오면, 그 면접은 거의 성공이다.

## "브라우저에 URL을 입력하면 어떤 일이 일어나나요?"

이 질문은 범위가 넓다. DNS 조회, TCP 연결, TLS 핸드셰이크, HTTP 요청, 서버 응답, HTML 파싱, CSSOM 구성, 렌더 트리, 레이아웃, 페인트... 전부 나열할 수 있으면 대단하긴 한데, 면접관이 진짜 보는 건 **어디에 깊이를 두느냐**다.

떨어지는 답변은 위키피디아식으로 전 과정을 얇게 훑는다. 붙는 답변은 전체 흐름을 간략히 잡은 뒤, 자기가 잘 아는 영역에서 깊이 들어간다.

프론트엔드 개발자라면 브라우저 렌더링 파이프라인에서 깊이를 보여주는 게 자연스럽다. HTML을 파싱해서 DOM을 만드는 과정에서 `<script>` 태그를 만나면 파싱이 멈춘다는 것, 그래서 `defer`와 `async`가 존재한다는 것. CSSOM이 완성되기 전에는 렌더링이 block된다는 것. 이런 지점에서 구체적인 경험을 덧붙이면 된다.

나는 이 질문에 답할 때 critical rendering path를 중심으로 이야기하고, "그래서 저는 프로젝트에서 CSS를 `<head>`에, 스크립트를 `<body>` 하단에 배치하거나 `defer`를 쓰는 이유가 여기에 있다고 생각합니다"로 연결한다. 이론과 실무가 하나로 이어지는 느낌을 주는 거다.

면접관으로 들어갔을 때, 한 후보자가 이 질문에 "전체 흐름은 이런데요, 저는 특히 HTTP 캐싱 쪽을 깊이 봤습니다"라고 하면서 `Cache-Control`, `ETag`, `stale-while-revalidate` 전략을 자기 프로젝트 경험과 엮어서 설명한 적이 있다. 프론트엔드 면접인데 네트워크 캐싱을 깊게 파고든 거다. 솔직히 그 답이 가장 기억에 남았다. 남들과 다른 지점에서 깊이를 보여주면 그 자체가 차별점이 된다.

## 성능 최적화 — 숫자 없이 말하면 안 믿는다

"성능 최적화 경험 있으세요?"

이 질문에 "React.memo 써봤습니다", "이미지를 lazy loading 했습니다" 정도로 끝나면 아쉽다. 면접관은 속으로 이렇게 생각한다. "그래서 얼마나 좋아졌는데?"

작년에 회사에서 랜딩 페이지 Lighthouse Performance 점수가 42점이었던 적이 있다. LCP가 3.2초, hero 이미지가 1.8MB짜리 PNG로 CSS background-image로 박혀 있었다. 이걸 `next/image`로 교체하고 WebP 변환 + `priority` 속성을 넣은 것만으로 LCP가 1.4초로 떨어졌다. 그 다음 번들 분석해서 lodash 전체 import를 tree-shaking 가능한 개별 import로 바꾸고, 사용하지 않는 moment.js를 day.js로 교체했다. 최종적으로 LCP 0.9초, Performance 점수 91점.

면접에서는 이 흐름 그대로 말한다. **측정 → 원인 분석 → 조치 → 결과 측정**. 이 사이클을 돌렸다는 걸 보여주는 게 핵심이다.

```
Before: Lighthouse Performance 42, LCP 3.2s, Bundle 1.2MB
After:  Lighthouse Performance 91, LCP 0.9s, Bundle 480KB
```

구체적인 수치가 있으면 면접관이 더 깊이 물어본다. "번들 분석은 어떤 도구로 했어요?" "CLS는 어떻게 잡았어요?" 이런 후속 질문이 오면 오히려 기회다. 그 질문 하나하나가 자신의 경험을 더 보여줄 수 있는 창구니까.

측정 없는 최적화는 최적화가 아니다. "느린 것 같아서 memo를 넣었다"는 면접에서 감점 요소에 가깝다. React DevTools Profiler를 켜서 어떤 컴포넌트가 불필요하게 리렌더링되는지 확인하고, 그 다음에 `useMemo`나 `React.memo`를 적용했다는 식으로 말해야 한다. 도구를 알고, 그 도구로 문제를 진단한 뒤에 해결책을 적용했다는 과정이 중요하다.

## "최근에 공부한 것 있으세요?"

이 질문이 제일 가벼워 보이는데, 의외로 당락을 가르는 경우가 많다.

"TypeScript 공부하고 있습니다"나 "Next.js 문서 읽고 있어요"는 나쁘지 않지만 인상적이지도 않다. 거의 모든 프론트엔드 개발자가 하는 말이니까.

내가 면접관일 때 가장 좋았던 답변은 이거였다. 한 후보자가 "개인 블로그를 Next.js App Router로 만들면서 RSC(React Server Components)를 써봤는데, 클라이언트 컴포넌트랑 서버 컴포넌트의 경계를 어디서 나눠야 하는지가 생각보다 어려웠어요"라고 했다. 그러면서 자기가 겪은 구체적인 문제를 설명했다. 서버 컴포넌트에서 `useState`를 써서 에러가 나서 한참 헤맨 이야기, 결국 `'use client'` 지시어의 의미를 제대로 이해하게 된 과정.

이게 왜 좋은 답변이냐면, 세 가지를 동시에 증명하기 때문이다. 첫째, 실제로 코드를 작성했다. 둘째, 막혔을 때 스스로 해결하는 과정을 경험했다. 셋째, 그 경험에서 무엇을 배웠는지 정리되어 있다.

블로그도 같은 맥락이다. "블로그에 기술 글을 쓰고 있습니다"는 강력한 답변인데, 한 가지 조건이 있다. 진짜 글이 있어야 한다는 거다. 면접 끝나고 블로그 URL을 확인하는 면접관은 생각보다 많다. 글이 3개 있는데 전부 "Hello World" 수준이면 오히려 역효과다. 하나라도 제대로 깊이 파고든 글이 있으면 그게 면접 답변 10분보다 더 강한 증거가 된다.

## 면접을 대화로 바꾸는 기술

여기까지 읽으면 패턴이 보일 거다. 잘 답변하는 사람들의 공통점은 "정의 → 실무 경험 → 문제 상황 → 배운 점"으로 이어지는 흐름을 갖고 있다는 것. 물론 매번 이 순서를 기계적으로 따르라는 건 아니다. 질문에 따라 유연하게 변형하되, 핵심은 **"나는 이걸 단순히 외운 게 아니라 실제로 부딪혀봤다"**는 인상을 주는 거다.

그리고 모르는 질문이 나왔을 때의 대처가 사실 가장 중요하다. 모르는 건 모른다고 하면 된다. 다만 "잘 모르겠습니다"로 끝내지 말고, "정확히는 모르겠는데, 제가 아는 범위에서 추론해보면..."이라고 사고 과정을 보여주면 전혀 다른 평가를 받는다. 면접관으로 앉아봐서 아는데, 모르는 걸 인정하면서도 논리적으로 접근하는 후보자에게는 오히려 가산점을 주고 싶어진다.

내가 두 번째 이직 면접에서 합격한 건, 모든 질문에 완벽하게 대답해서가 아니었다. 웹 접근성 관련 질문에서 ARIA 속성을 정확히 몰라서 버벅거렸는데, "이 부분은 깊이 다뤄본 적이 없어서 정확하지 않은데, 시맨틱 HTML을 우선 쓰고 부족한 부분을 ARIA로 보완한다는 원칙 정도만 알고 있습니다"라고 했다. 면접이 끝나고 합격 통보를 받을 때, 면접관이었던 분이 "모르는 것과 아는 것의 경계를 명확히 구분하시는 게 좋았어요"라고 피드백을 줬다.

기술 면접은 시험이 아니다. 내가 어떤 개발자인지를 보여주는 대화다. 정의를 많이 외우는 것보다, 하나를 깊이 경험하고 그걸 자기 말로 풀어내는 연습이 훨씬 효과적이다. 지금 면접을 준비하고 있다면, 가장 먼저 할 일은 질문 리스트를 100개 모으는 게 아니라 자기가 작업한 코드 중에서 이야기가 되는 것 5개를 골라 정리하는 거다.



"프론트엔드 로드맵"을 검색하면 다 비슷한 그림이 나온다. HTML → CSS → JavaScript → React → Next.js, 그 옆에 가지치기처럼 뻗어나가는 수십 개의 기술 이름들. 나도 1년 전에 저 그림을 보면서 공부 순서를 짰다. 그리고 6개월을 낭비했다.

Webpack config를 직접 짜보겠다고 3주를 썼다. CSS-in-JS 라이브러리를 세 개나 비교하면서 블로그 글을 읽었다. jQuery도 "혹시 모르니까" 하면서 튜토리얼을 돌렸다. 결과? 면접에서 "이 컴포넌트의 re-render 조건이 뭔가요?"라는 질문에 제대로 대답을 못 했다. 기초가 안 잡힌 채로 가지만 넓히고 있었던 거다.

지금 우리 팀에 들어오는 신입 면접을 보면서, 그리고 옆 팀 채용 과정을 지켜보면서 느낀 점이 있다. 한국 프론트엔드 시장에서 신입에게 요구하는 건 생각보다 범위가 좁다. 대신 그 좁은 범위를 제대로 아는지를 본다. 그래서 이 글은 "무엇을 배워야 하는가"보다 "무엇을 어디까지 배워야 하는가"에 집중한다.

## Phase 1: 기초 — 근데 진짜 필요한 것만

### HTML: 태그 외우기가 아니다

HTML을 "다 안다"고 생각하는 사람이 많다. 나도 그랬다. `div`랑 `span` 차이 알고, `form`에 `input` 넣을 줄 알면 끝이라고 생각했다.

그런데 실무에서 처음으로 접근성 관련 QA 피드백을 받았을 때 당황했다. 스크린 리더에서 우리 페이지의 네비게이션이 전혀 인식이 안 됐다. `div`에 `onClick`을 달아서 버튼처럼 쓰고 있었기 때문이다. semantic HTML이 뭔지는 알았는데, 왜 중요한지 체감한 적은 없었던 거다.

신입이 HTML에서 확실히 알아야 할 것:

- **시맨틱 태그**: `header`, `nav`, `main`, `section`, `article`, `aside`, `footer`. 이걸 적재적소에 쓸 줄 알면 된다. `div` soup을 만들지 않는 감각.
- **form 요소**: `input` 타입들, `label`과 `for` 연결, `fieldset`, 폼 validation의 기본 동작. React에서 form 라이브러리 쓰더라도 네이티브 동작을 이해하고 있어야 한다.
- **메타 태그와 SEO 기본**: `title`, `meta description`, Open Graph 태그. Next.js에서 `metadata` 객체를 채울 때 이게 뭔지 모르면 곤란하다.

"HTML 공부"에 일주일 이상 쓸 필요 없다. 프로젝트 만들면서 자연스럽게 익히면 된다.

### CSS: Flexbox와 Grid면 실무의 80%다

CSS 전체를 마스터하려고 하면 끝이 없다. `float` 레이아웃의 역사부터 시작해서 `BEM` 방법론, CSS 변수, 애니메이션 키프레임까지. 하지만 실무에서 내가 매일 쓰는 CSS는 놀라울 정도로 범위가 좁다.

**반드시 익숙해야 하는 것:**
- **Flexbox**: `justify-content`, `align-items`, `flex-grow`, `flex-shrink`, `gap`. 이것만 자유자재로 쓸 수 있으면 레이아웃의 70%는 해결된다.
- **Grid**: 2차원 레이아웃이 필요할 때. 대시보드, 카드 리스트, 갤러리 같은 것. `grid-template-columns`와 `fr` 단위, `repeat()`, `minmax()` 정도.
- **반응형 디자인**: `media query` 기본, `rem`/`em` 단위 이해, 모바일 퍼스트 사고방식. 한국 서비스 대부분이 모바일 트래픽이 60~70%다.
- **position**: `relative`, `absolute`, `fixed`, `sticky`의 차이. 모달, 드롭다운, 툴팁 만들 때 매번 나온다.

Tailwind CSS를 쓰는 회사가 많아졌는데, Tailwind를 쓰더라도 위에 적은 개념을 모르면 클래스 이름을 의미 없이 복붙하게 된다. 기본 CSS를 이해한 상태에서 Tailwind를 쓰면 생산성이 폭발적으로 올라간다. 순서가 중요하다.

### JavaScript: 면접에서 물어보는 건 정해져 있다

JavaScript는 범위가 넓어서 뭘 어디까지 해야 할지 막막한 언어다. 내가 면접 보면서, 그리고 면접관으로 들어가면서 느낀 패턴이 있다.

**거의 무조건 나오는 것:**
- **비동기 처리**: `Promise`, `async/await`, `then` 체이닝. API 호출 한 번이면 반드시 쓴다. 에러 핸들링(`try/catch`)까지 포함.
- **배열 메서드**: `map`, `filter`, `reduce`, `find`, `some`, `every`. 데이터를 가공하는 일이 프론트엔드 업무의 절반이다.
- **구조 분해 할당과 스프레드 연산자**: React에서 props 다루고, 상태 업데이트할 때 매 순간 쓴다.
- **클로저와 스코프**: 왜 `setTimeout` 안에서 변수가 예상과 다른 값을 갖는지. React의 stale closure 문제를 이해하려면 이게 기초다.
- **이벤트 루프**: 깊이 있게 알 필요는 없지만, "JavaScript는 싱글 스레드이고 비동기를 이벤트 루프로 처리한다"는 정도는 설명할 수 있어야 한다.

**알면 좋지만 신입 면접에서 잘 안 나오는 것:**
- 프로토타입 체인의 내부 동작
- `Symbol`, `WeakMap`, `WeakSet`
- 제너레이터 함수

여기까지가 Phase 1이다. 이 정도면 프론트엔드 부트캠프 수료 수준이고, 인턴이나 아주 초기 스타트업에 지원할 수 있는 단계다. 하지만 여기서 멈추면 서류 통과가 어렵다.

## Phase 2: React + TypeScript

### 왜 하필 React인가

2026년 현재, 한국 채용 공고에서 프론트엔드 프레임워크 요구사항의 체감 70% 이상이 React다. 원티드에서 "프론트엔드"로 검색하면 대부분의 공고에 React 또는 Next.js가 적혀 있다. Vue.js를 쓰는 곳도 있고(특히 네이버 계열), Svelte를 도입한 팀도 있다. 하지만 신입이 "하나만 제대로 하겠다"고 할 때, React가 가장 안전한 선택이라는 건 부정하기 어렵다.

React에서 신입이 알아야 하는 수준:

- **컴포넌트 설계**: 어떤 단위로 컴포넌트를 나누는지. props로 뭘 내리고, 상태를 어디에 둘지.
- **hooks**: `useState`, `useEffect`, `useRef`, `useMemo`, `useCallback`. 이 다섯 개를 자유롭게 쓰면 실무에서 만나는 상황 대부분을 처리할 수 있다.
- **상태 관리 기본**: 전역 상태가 왜 필요한지, Context API의 한계가 뭔지. Zustand나 Jotai 같은 라이브러리 하나를 경험해보면 좋다. Redux는 여전히 레거시 프로젝트에 많지만, 신규 프로젝트에서 선택하는 비율은 줄었다.
- **데이터 페칭**: TanStack Query(구 React Query)는 거의 필수다. 캐싱, 로딩/에러 상태, refetch 로직을 직접 구현하는 것과 라이브러리를 쓰는 것의 차이를 한 번이라도 겪어보면 왜 쓰는지 바로 이해된다.
- **라우팅**: React Router 또는 Next.js의 App Router. SPA에서 페이지 전환이 어떻게 동작하는지.

### TypeScript: 제네릭 고수가 될 필요는 없다

TypeScript 얘기를 하면 "어디까지 공부해야 하나요?"가 가장 많이 나오는 질문이다. 답부터 말하면, 신입 수준에서 advanced generics를 자유자재로 쓸 줄 알 필요는 없다.

내가 입사하고 처음 3개월 동안 TypeScript에서 주로 한 일:

```typescript
// 1. 컴포넌트 props 타입 정의
interface ProductCardProps {
  title: string;
  price: number;
  imageUrl: string;
  onAddToCart: (productId: string) => void;
}

// 2. API 응답 타입 정의
interface ApiResponse<T> {
  data: T;
  message: string;
  status: number;
}

// 3. 유니온 타입으로 상태 표현
type Status = 'idle' | 'loading' | 'success' | 'error';
```

이 정도다. `interface`와 `type`의 차이, 유니온 타입, 제네릭의 기본적인 사용법, `as const`, 유틸리티 타입 중 `Partial`, `Pick`, `Omit` 정도. 나머지는 필요할 때 찾아서 쓰면 된다.

TypeScript를 "잘 모르겠으니까 나중에"라고 미루는 분들이 있는데, 이건 좋은 전략이 아니다. React 프로젝트를 TypeScript로 시작하면 처음엔 빨간 줄이 많아서 짜증나지만, 2주만 버티면 오히려 JavaScript로 돌아가기 싫어진다. 에디터가 자동완성을 해주고, 실수를 실시간으로 잡아주니까.

**여기까지 하면 대부분의 주니어 프론트엔드 포지션에 지원할 수 있다.** 채용 공고의 "자격 요건"에 적힌 기술 스택 대부분을 커버하는 수준이다. 포트폴리오 프로젝트 하나를 React + TypeScript + TanStack Query로 만들어서 GitHub에 올려놓으면 서류 통과율이 확 달라진다.

## Phase 3: 실무에서 모르면 당황하는 것들

면접에서는 안 물어보는데 입사 첫 주에 필요한 것들이 있다. 나는 이걸 "면접 사각지대"라고 부른다.

### Git: rebase를 모르면 첫 PR부터 막힌다

`git add`, `git commit`, `git push` 정도는 다들 안다. 문제는 실무에서 그것만으로는 안 된다는 거다.

입사 첫 주에 PR을 올렸더니 리뷰어가 "rebase 해서 커밋 정리해주세요"라고 했다. 나는 rebase가 뭔지 몰랐다. 구글링하면서 했는데 conflict가 나서 30분을 헤맸다. 옆자리 동기는 나보다 먼저 입사했는데, 아직도 merge만 쓰고 있어서 커밋 히스토리가 스파게티였다.

**신입이 Git에서 알아야 하는 것:**
- branch 전략 (최소한 feature branch 워크플로우)
- `rebase`와 `merge`의 차이, interactive rebase로 커밋 정리
- conflict 해결
- `stash`: 작업 중에 급하게 다른 브랜치로 가야 할 때
- `.gitignore` 관리

### 패키지 매니저와 번들러

`npm install`만 할 줄 아는 것과 `package.json`을 읽을 줄 아는 건 다르다. `dependencies`와 `devDependencies` 차이, `^`와 `~`의 의미, `lock` 파일이 왜 있는지. pnpm을 쓰는 회사가 빠르게 늘고 있으니 한 번쯤 써보면 좋다.

번들러는 Vite를 기본으로 알면 된다. Webpack은 설정을 직접 짤 줄 알 필요 없다. 레거시 프로젝트에서 `webpack.config.js`를 만나면 그때 읽으면 된다. "번들러가 무슨 일을 하는가"를 개념적으로 이해하는 것이 중요하다. 모듈을 합치고, 코드를 변환하고, 최적화한다. 이 정도.

### 브라우저 DevTools

Chrome DevTools를 얼마나 잘 쓰느냐가 디버깅 속도를 결정한다. 우리 팀에서 신입 온보딩할 때 가장 먼저 알려주는 것 중 하나다.

- **Elements 탭**: DOM 구조 확인, 스타일 실시간 수정, computed 스타일 보기
- **Console 탭**: 당연히 쓰겠지만, `console.table`, `console.group` 같은 것도 알면 편하다
- **Network 탭**: API 요청/응답 확인, 상태 코드, 응답 시간, 페이로드 크기. 이걸 자유롭게 볼 줄 알면 백엔드와 소통할 때 "API가 이상한 것 같아요"가 아니라 "이 엔드포인트가 500 내려주고 있어요, response body는 이거예요"라고 말할 수 있다.
- **Performance 탭**: 당장 깊게 파지 않아도 되지만, 한 번쯤 프로파일링을 돌려보면 "렌더링이 느리다"는 게 구체적으로 무슨 뜻인지 감이 잡힌다

**여기까지 하면 실무 투입이 가능한 수준이다.** 시니어가 옆에서 도와주는 환경이라면, 이 정도 준비로 첫 번째 티켓을 잡을 수 있다.

## Phase 4: 차별화 — 여기서부터 경쟁력이 갈린다

Phase 1~3은 "기본"이다. 취업을 위한 최소 요건이라고 봐도 된다. Phase 4는 선택이지만, 이걸 하느냐 안 하느냐에 따라 이력서에서 눈에 띄는 정도가 확연히 다르다.

### 테스트

"신입한테 테스트를 기대하냐?"라고 물을 수 있다. 기대하지 않는다. 그래서 오히려 차별화가 된다.

포트폴리오 프로젝트에 테스트 코드가 있으면, 면접관 입장에서는 "이 사람 혼자서도 코드 품질을 챙길 줄 아는구나"라고 생각하게 된다. 전체를 커버할 필요 없다. 핵심 유틸 함수에 단위 테스트 몇 개, 중요한 유저 플로우에 통합 테스트 하나. 이것만으로 충분하다.

- **Vitest**: 단위 테스트. Jest보다 설정이 간단하고 Vite 프로젝트와 찰떡이다.
- **React Testing Library**: 컴포넌트 테스트. "사용자가 보는 것"을 기준으로 테스트하는 철학이 실무와 맞다.
- **Playwright** 또는 **Cypress**: E2E 테스트. 하나만 가볍게 경험해보면 된다.

### 성능

웹 성능은 깊게 파면 한도 끝도 없는 분야인데, 신입 수준에서 알면 좋은 건 이 정도다.

Core Web Vitals가 뭔지 (LCP, CLS, INP). 이미지 최적화 (`next/image`나 `srcset`). 코드 스플리팅의 개념 (`React.lazy`와 `Suspense`). Lighthouse를 돌려보고 점수를 읽을 줄 아는 것. 이 정도만 해도 "성능에 관심 있는 신입"이라는 인상을 줄 수 있다.

### 접근성 (a11y)

한국에서 웹 접근성을 신경 쓰는 회사가 확실히 늘었다. 특히 공공기관, 금융, 대기업 서비스. "접근성 준수"가 프로젝트 요구사항에 들어가는 경우가 많아졌다.

신입 수준에서는 ARIA 스펙을 다 외울 필요 없고, 키보드 네비게이션이 되는지 확인하는 습관, semantic HTML을 쓰는 습관, 색상 대비를 체크하는 습관. 이 세 가지 습관만 가져도 충분하다.

### CI/CD

GitHub Actions로 간단한 파이프라인 하나 만들어본 경험. push하면 lint 돌리고, 테스트 돌리고, 빌드가 성공하는지 확인하는 워크플로우. 이걸 포트폴리오 프로젝트에 넣어두면 "이 사람은 개발 프로세스를 이해하고 있구나"라는 인상을 준다. YAML 파일 하나 작성하는 데 30분이면 된다.

**여기까지 하면 경쟁력 있는 신입이다.** 면접에서 "테스트 경험 있으세요?"라는 질문에 자신 있게 대답할 수 있고, "성능 개선 해본 적 있나요?"에도 할 말이 있다. 대기업, 유명 스타트업을 포함해서 어디든 지원할 수 있는 수준이다.

## 과감하게 건너뛸 것들

시간은 유한하다. 아래 항목들은 2026년 신입 기준으로 우선순위가 낮다.

**jQuery**: 레거시 프로젝트에서 만날 수는 있다. 하지만 미리 배울 필요는 전혀 없다. 필요하면 그때 5분이면 기본 문법을 파악할 수 있다.

**Webpack 설정 직접 작성**: Vite가 대세가 된 지금, Webpack config를 처음부터 짤 줄 아는 건 신입에게 기대하는 역량이 아니다. 면접에서도 안 물어본다.

**CSS-in-JS 라이브러리 비교**: styled-components vs emotion vs vanilla-extract. 이 논쟁에 시간을 쓰지 마라. 회사에서 쓰는 거 쓰면 된다. 어차피 CSS 기본이 탄탄하면 어떤 도구든 적응하는 데 이틀이면 충분하다.

**GraphQL**: 흥미롭긴 한데, 한국 시장에서 REST가 여전히 압도적이다. GraphQL을 쓰는 회사에 지원하는 게 아니라면 나중으로 미뤄도 된다.

**모노레포, 마이크로프론트엔드**: 대규모 조직에서나 의미 있는 아키텍처다. 신입이 이걸 공부하는 건 운전면허 따기 전에 F1 전략을 분석하는 거랑 비슷하다.

## CS 기초, 프론트엔드에 필요한가

이 질문을 정말 많이 받는다. 그리고 답은 "어디에 지원하느냐에 따라 다르다"이다.

카카오, 네이버, 토스 같은 곳은 코딩 테스트를 본다. 알고리즘과 자료구조 문제가 나온다. 이 회사에 가고 싶으면 프로그래머스나 백준에서 실버~골드 수준 문제를 꾸준히 풀어야 한다. 피할 수 없다.

반면 많은 스타트업은 코딩 테스트 대신 과제 전형이나 기술 면접 위주다. 이런 곳에서는 "이진 탐색을 구현하세요"보다 "이 화면을 만들어보세요"가 나온다. CS 기초보다 실제 구현 능력을 본다.

그런데 하나 덧붙이고 싶은 게 있다. 자료구조와 알고리즘을 코딩 테스트 통과용으로만 보면 아깝다. `Set`이 왜 `Array`의 `includes`보다 빠른지, 객체를 깊은 복사할 때 재귀가 왜 필요한지, 이런 감각은 실무 코드 품질에 직접적으로 영향을 준다. 다만 우선순위의 문제다. Phase 1~3를 먼저 탄탄히 다지고, 그 다음에 알고리즘을 병행하는 게 효율적이다. 둘 다 동시에 하려다 둘 다 어중간해지는 경우를 너무 많이 봤다.

## 현실적인 타임라인

사람마다 다르겠지만, 하루 4~5시간 집중해서 공부한다는 전제 하에 내가 생각하는 현실적인 기간이다.

- **Phase 1** (HTML/CSS/JS 기초): 2~3개월. 이 기간에 간단한 프로젝트 2~3개를 만들어보는 게 중요하다. 투두 앱 말고, 실제 API를 호출하는 뭔가. 공공 API 활용한 검색 서비스 같은 것.
- **Phase 2** (React + TypeScript): 2~3개월. 포트폴리오 프로젝트 하나를 이 기간에 완성한다.
- **Phase 3** (실무 도구): Phase 2와 병행 가능. 프로젝트를 만들면서 자연스럽게 Git을 쓰고, pnpm으로 패키지를 관리하고, DevTools로 디버깅하면 된다.
- **Phase 4** (차별화): 1~2개월. 포트폴리오 프로젝트에 테스트를 추가하고, 성능을 측정하고, CI/CD를 붙인다.

합치면 6~8개월 정도. "너무 긴 거 아니냐"고 할 수 있는데, 현실적으로 이 정도 시간을 투자해야 경쟁력 있는 포트폴리오가 나온다. 3개월 만에 취업했다는 후기가 있지만, 그건 이전 경력이 있거나 관련 전공이거나, 아니면 정말 예외적인 케이스다.

## 로드맵보다 중요한 한 가지

마지막으로 하나만 더. 나도 로드맵을 열심히 따라갔는데, 결국 가장 도움이 된 건 "실제 서비스를 만들어본 경험"이었다. 튜토리얼을 따라 하는 건 공부다. 에러를 만나고, 구글링하고, 삽질하고, 결국 해결하는 건 경험이다. 면접에서 빛나는 건 후자다.

로드맵은 방향만 잡아주는 거다. 어떤 기술을 배우든, "이걸로 뭘 만들어볼까?"를 항상 같이 생각하면 좋겠다. 기술은 도구고, 도구는 써봐야 내 것이 된다.


커버리지 80%를 찍은 날, 팀 전체가 축하 메시지를 보냈다.

스프린트 두 번을 통째로 투자한 결과였다. 기존 컴포넌트마다 unit test를 붙이고, util 함수에도 빠짐없이 테스트를 작성했다. SonarQube 대시보드에 초록불이 켜졌을 때 팀 리드가 슬랙에 "드디어 80% 돌파"라고 올렸다. 다들 축하 리액션을 달았다. 그런데 그 다음 달 프로덕션 버그 수는 이전 달과 거의 같았다.

왜?

## 우리가 테스트하고 있던 것들

그때 작성한 테스트를 지금 다시 보면 패턴이 보인다. `formatDate('2025-01-01')`이 `'2025년 1월 1일'`을 반환하는지, `calculateDiscount(10000, 0.1)`이 `9000`을 반환하는지, `Button` 컴포넌트에 `disabled` prop을 넘기면 `disabled` attribute가 붙는지. 이런 테스트가 수백 개였다.

하나하나는 틀린 테스트가 아니었다. 문제는 이런 테스트들이 실제 유저가 마주치는 버그를 잡아주지 못한다는 거였다. 유저는 `formatDate` 함수를 직접 호출하지 않는다. 유저는 주문 내역 페이지에 들어가서 날짜가 제대로 보이는지 확인한다. 그리고 프로덕션에서 터진 버그들은 대부분 "API 응답이 예상과 다를 때 화면이 어떻게 되는지", "로딩 중에 유저가 다른 버튼을 누르면 어떻게 되는지" 같은 것들이었다. 컴포넌트 단위로 잘게 쪼갠 unit test로는 절대 잡을 수 없는 영역.

## Testing Pyramid에서 Testing Trophy로

전통적인 testing pyramid는 unit test를 가장 많이, integration test를 중간, E2E test를 가장 적게 작성하라고 말한다. 빠르고 싸니까 unit을 많이 쓰라는 논리다.

Kent C. Dodds가 제안한 testing trophy는 이 비율을 뒤집는다. 가장 두꺼운 부분이 integration test다. 그 위에 얇은 E2E, 아래에 얇은 unit, 맨 아래에 static analysis(TypeScript, ESLint). 트로피 모양이라 testing trophy라고 부른다.

핵심 논리는 단순하다. **테스트가 소프트웨어를 사용하는 방식과 비슷할수록, 테스트가 더 많은 신뢰를 준다.** unit test는 함수 하나가 제대로 작동하는지 확인할 수 있지만, 그 함수들이 조합되어 유저에게 올바른 결과를 보여주는지는 확인할 수 없다. integration test는 여러 컴포넌트와 Hook이 함께 동작하는 걸 검증한다. 비용 대비 잡아내는 버그의 범위가 가장 넓다.

이전 팀에서 커머스 상품 목록 페이지를 예로 들면, 이 페이지에 관련된 unit test가 12개 있었다. `useProductList` Hook의 반환값 테스트, `ProductCard` 컴포넌트의 렌더링 테스트, `filterProducts` util 함수 테스트 등등. 근데 "필터를 선택하고 → 정렬을 바꾸면 → 필터가 초기화되는" 버그를 잡은 건 QA 담당자였다. unit test 12개 중 어떤 것도 이 시나리오를 커버하지 못했다. integration test 하나면 됐을 일이다.

## 테스트 안 해도 되는 것들

시간은 유한하다. 뭘 테스트하지 않을지 결정하는 게 뭘 테스트할지 결정하는 것만큼 중요하다.

**스타일 테스트.** `color`가 `red`인지, `margin-top`이 `16px`인지 테스트하는 코드를 본 적 있다. 디자인은 자주 바뀐다. 이런 테스트는 디자인 변경할 때마다 같이 고쳐야 해서 유지보수 비용만 올라간다. 스타일은 Storybook이나 visual regression test로 검증하는 게 맞다.

**라이브러리 내부 동작.** React Query가 캐시를 제대로 관리하는지, Zustand의 selector가 리렌더링을 막는지, 이런 건 해당 라이브러리가 자체 테스트로 보장하는 영역이다. 우리가 다시 테스트할 이유가 없다. react-hook-form의 `register`가 input에 올바른 ref를 전달하는지 테스트하고 있다면, 그건 react-hook-form 메인테이너의 일이다.

**implementation detail.** 이게 가장 흔한 실수다. state가 특정 값으로 변하는지 직접 확인하거나, 특정 함수가 몇 번 호출됐는지 체크하거나, 내부 컴포넌트 구조를 테스트하는 것. 리팩토링하면 바로 깨진다. 동작은 그대로인데 테스트가 실패하면, 그건 나쁜 테스트다.

```tsx
// 나쁜 테스트: implementation detail을 검증
test('버튼 클릭 시 setCount가 호출된다', () => {
  const setCount = jest.fn();
  jest.spyOn(React, 'useState').mockReturnValue([0, setCount]);
  render(<Counter />);
  fireEvent.click(screen.getByRole('button'));
  expect(setCount).toHaveBeenCalledWith(1);
});

// 좋은 테스트: 유저가 보는 결과를 검증
test('버튼 클릭 시 카운트가 증가한다', () => {
  render(<Counter />);
  fireEvent.click(screen.getByRole('button'));
  expect(screen.getByText('1')).toBeInTheDocument();
});
```

## 테스트해야 하는 것들

반대로, 시간을 들여야 하는 영역이 있다.

**유저 인터랙션 흐름.** 버튼을 클릭하면 모달이 열리고, 모달에서 확인을 누르면 리스트에서 항목이 사라지는 것. 이런 흐름이 깨지면 유저가 바로 알아챈다.

**조건부 렌더링.** 로그인 상태에 따라 다른 UI가 보이는 것, 권한에 따라 버튼이 활성화/비활성화되는 것, 빈 상태(empty state) 처리. 이런 건 조건문 하나 빠뜨리면 프로덕션 이슈가 된다.

**폼 검증.** 이메일 형식이 틀릴 때 에러 메시지가 뜨는지, 필수 필드를 비워두고 제출하면 막히는지, 비밀번호 조건이 충족되지 않을 때 어떤 안내가 나오는지. 폼은 유저가 데이터를 입력하는 핵심 접점이고, 여기서 문제가 생기면 전환율이 직접 떨어진다.

**API 에러 핸들링.** 네트워크 에러일 때 "잠시 후 다시 시도해주세요"가 뜨는지, 401일 때 로그인 페이지로 리다이렉트하는지, 서버가 예상과 다른 응답을 줄 때 화면이 터지지 않는지. 프로덕션에서 가장 많이 터지는 버그 유형이 바로 이거다.

## React Testing Library 철학

React Testing Library의 기본 원칙이 있다.

> The more your tests resemble the way your software is used, the more confidence they can give you.

유저는 컴포넌트의 state를 모른다. props가 뭔지도 모른다. 유저는 화면에서 텍스트를 읽고, 버튼을 누르고, 입력 필드에 타이핑한다. 테스트도 그렇게 해야 한다.

쿼리 우선순위도 이 철학을 반영한다. `getByRole`이 1순위다. 유저가 인식하는 방식(버튼, 텍스트박스, 링크)으로 요소를 찾는다. `getByText`가 그 다음이다. 유저가 읽는 텍스트로 찾는다. `getByTestId`는 최후의 수단이다. 유저는 `data-testid`를 모른다.

```tsx
// 피해야 할 쿼리
const button = container.querySelector('.submit-btn');
const input = screen.getByTestId('email-input');

// 권장하는 쿼리
const button = screen.getByRole('button', { name: '로그인' });
const input = screen.getByRole('textbox', { name: '이메일' });
```

`getByRole`을 쓰면 자연스럽게 접근성도 챙기게 된다. `getByRole('button', { name: '로그인' })`이 동작하려면 해당 버튼에 접근 가능한 이름이 있어야 한다. 테스트가 통과하면 스크린 리더도 그 버튼을 "로그인"으로 읽는다는 뜻이다.

## 실전 예제: 로그인 폼 테스트

말로만 하면 와닿지 않으니 실제 코드를 보자. 간단한 로그인 폼이 있다고 가정한다.

```tsx
// LoginForm.tsx
export function LoginForm({ onSuccess }: { onSuccess: () => void }) {
  const [error, setError] = useState('');
  const [isLoading, setIsLoading] = useState(false);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const formData = new FormData(e.currentTarget);
    const email = formData.get('email') as string;
    const password = formData.get('password') as string;

    setIsLoading(true);
    setError('');

    try {
      const res = await fetch('/api/login', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password }),
      });

      if (!res.ok) {
        const data = await res.json();
        throw new Error(data.message || '로그인에 실패했습니다');
      }

      onSuccess();
    } catch (err) {
      setError(err instanceof Error ? err.message : '알 수 없는 오류가 발생했습니다');
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">이메일</label>
      <input id="email" name="email" type="email" required />

      <label htmlFor="password">비밀번호</label>
      <input id="password" name="password" type="password" required />

      {error && <p role="alert">{error}</p>}

      <button type="submit" disabled={isLoading}>
        {isLoading ? '로그인 중...' : '로그인'}
      </button>
    </form>
  );
}
```

이 폼의 테스트를 작성한다. 유저 관점에서 중요한 시나리오는 세 가지다. 성공, 실패, 그리고 로딩 상태.

```tsx
// LoginForm.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';
import { server } from './mocks/server';
import { http, HttpResponse } from 'msw';

const mockOnSuccess = jest.fn();

beforeEach(() => {
  mockOnSuccess.mockClear();
});

test('이메일과 비밀번호를 입력하고 제출하면 로그인에 성공한다', async () => {
  const user = userEvent.setup();

  server.use(
    http.post('/api/login', () => {
      return HttpResponse.json({ token: 'fake-token' });
    })
  );

  render(<LoginForm onSuccess={mockOnSuccess} />);

  await user.type(screen.getByRole('textbox', { name: '이메일' }), 'test@example.com');
  await user.type(screen.getByLabelText('비밀번호'), 'password123');
  await user.click(screen.getByRole('button', { name: '로그인' }));

  await waitFor(() => {
    expect(mockOnSuccess).toHaveBeenCalledTimes(1);
  });
});

test('잘못된 인증 정보로 로그인하면 에러 메시지가 표시된다', async () => {
  const user = userEvent.setup();

  server.use(
    http.post('/api/login', () => {
      return HttpResponse.json(
        { message: '이메일 또는 비밀번호가 올바르지 않습니다' },
        { status: 401 }
      );
    })
  );

  render(<LoginForm onSuccess={mockOnSuccess} />);

  await user.type(screen.getByRole('textbox', { name: '이메일' }), 'wrong@example.com');
  await user.type(screen.getByLabelText('비밀번호'), 'wrongpassword');
  await user.click(screen.getByRole('button', { name: '로그인' }));

  const alert = await screen.findByRole('alert');
  expect(alert).toHaveTextContent('이메일 또는 비밀번호가 올바르지 않습니다');
  expect(mockOnSuccess).not.toHaveBeenCalled();
});

test('제출 중에는 버튼이 비활성화되고 로딩 텍스트가 표시된다', async () => {
  const user = userEvent.setup();

  server.use(
    http.post('/api/login', async () => {
      await new Promise((resolve) => setTimeout(resolve, 100));
      return HttpResponse.json({ token: 'fake-token' });
    })
  );

  render(<LoginForm onSuccess={mockOnSuccess} />);

  await user.type(screen.getByRole('textbox', { name: '이메일' }), 'test@example.com');
  await user.type(screen.getByLabelText('비밀번호'), 'password123');
  await user.click(screen.getByRole('button', { name: '로그인' }));

  expect(screen.getByRole('button', { name: '로그인 중...' })).toBeDisabled();

  await waitFor(() => {
    expect(screen.getByRole('button', { name: '로그인' })).toBeEnabled();
  });
});
```

각 테스트의 구조를 보면: render → 유저 인터랙션 → 결과 확인. 내부 state를 직접 체크하는 곳이 없다. `setError`가 호출됐는지, `isLoading`이 `true`로 바뀌었는지 같은 건 안 본다. 유저가 화면에서 확인할 수 있는 것만 검증한다. 에러 메시지가 보이는지, 버튼이 비활성화됐는지, 성공 콜백이 호출됐는지.

## MSW로 API mocking

위 예제에서 이미 MSW(Mock Service Worker)를 쓰고 있다. MSW가 다른 mocking 방식보다 나은 이유를 짧게 정리한다.

`jest.mock`이나 `jest.spyOn`으로 `fetch`를 직접 mock하면 implementation detail에 묶인다. `fetch` 대신 `axios`로 바꾸면 테스트가 깨진다. MSW는 네트워크 레벨에서 가로채기 때문에 HTTP 클라이언트가 뭐든 상관없다. 컴포넌트 입장에서는 진짜 서버에 요청을 보내는 것과 차이가 없다.

설정도 간단하다.

```tsx
// mocks/handlers.ts
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get('/api/user', () => {
    return HttpResponse.json({
      id: 1,
      name: '조상현',
      email: 'test@example.com',
    });
  }),

  http.get('/api/products', ({ request }) => {
    const url = new URL(request.url);
    const category = url.searchParams.get('category');

    const products = [
      { id: 1, name: '상품 A', category: 'electronics' },
      { id: 2, name: '상품 B', category: 'clothing' },
    ];

    const filtered = category
      ? products.filter((p) => p.category === category)
      : products;

    return HttpResponse.json(filtered);
  }),
];

// mocks/server.ts
import { setupServer } from 'msw/node';
import { handlers } from './handlers';

export const server = setupServer(...handlers);
```

```tsx
// jest.setup.ts 또는 vitest.setup.ts
import { server } from './mocks/server';

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());
```

기본 handler를 설정해두고, 특정 테스트에서 다른 응답이 필요하면 `server.use()`로 오버라이드한다. 로그인 폼 테스트에서 성공/실패 케이스마다 다른 handler를 넣은 게 그 패턴이다.

네트워크 에러도 시뮬레이션할 수 있다.

```tsx
test('네트워크 에러 시 적절한 메시지가 표시된다', async () => {
  const user = userEvent.setup();

  server.use(
    http.post('/api/login', () => {
      return HttpResponse.error();
    })
  );

  render(<LoginForm onSuccess={mockOnSuccess} />);

  await user.type(screen.getByRole('textbox', { name: '이메일' }), 'test@example.com');
  await user.type(screen.getByLabelText('비밀번호'), 'password123');
  await user.click(screen.getByRole('button', { name: '로그인' }));

  const alert = await screen.findByRole('alert');
  expect(alert).toHaveTextContent('알 수 없는 오류가 발생했습니다');
});
```

## "이 테스트가 깨졌을 때 진짜 문제인가?"

팀에서 정한 기준이 하나 있다. 테스트가 실패했을 때 스스로에게 묻는다: **"이게 프로덕션에서도 문제인가?"**

대답이 "아니오"면 그 테스트는 삭제하거나 수정해야 한다.

실제로 겪은 케이스. 컴포넌트 내부에서 `div` 구조를 변경했더니 snapshot test가 20개 깨졌다. 유저가 보는 화면은 완전히 동일했다. 텍스트 같고, 버튼 같고, 인터랙션 같았다. 하지만 DOM 구조가 바뀌어서 snapshot이 일치하지 않았다. 이 20개 테스트를 업데이트하는 데 시간을 쓸 것인가? 아니면 처음부터 snapshot test 대신 행동 기반 테스트를 작성할 것인가?

snapshot test가 무조건 나쁘다는 건 아니다. API 응답 스키마 검증이나 에러 메시지 포맷 확인 같은 데는 유용하다. 하지만 컴포넌트 UI에 대한 snapshot test는 대부분 노이즈만 만든다. 변경할 때마다 `jest --updateSnapshot`을 무의식적으로 실행하게 되면, 그 테스트는 이미 역할을 잃은 거다.

거꾸로, 깨졌을 때 즉시 대응해야 하는 테스트가 있다. 결제 금액 계산 테스트가 깨졌으면 무조건 프로덕션에도 문제가 있을 가능성이 높다. 로그인 성공/실패 분기 테스트가 깨졌으면 유저가 로그인을 못 하고 있을 수 있다. 이런 테스트는 시간을 들여 유지할 가치가 있다.

## E2E는 언제 쓰나

E2E 테스트는 비싸다. 느리고, 불안정하고(flaky), 유지보수 비용이 높다. 그래서 모든 기능에 E2E를 붙이면 CI가 30분 넘게 돌아간다.

E2E는 critical path에만 쓴다. 이 기능이 안 되면 비즈니스가 안 돌아가는 것들.

- 회원가입 → 이메일 인증 → 로그인 전체 흐름
- 상품 선택 → 장바구니 → 결제 → 주문 완료
- 핵심 검색 → 결과 노출 → 상세 페이지 진입

Playwright나 Cypress로 이 3~5개 시나리오만 커버하면 된다. 나머지는 integration test로 충분하다.

이전 프로젝트에서 E2E를 30개 넘게 작성한 적이 있다. 결과는 비참했다. 매주 1~2개씩 flaky test가 발생했고, "이번에도 타이밍 이슈"라며 재실행하는 게 루틴이 됐다. 결국 CI에서 E2E 실패를 무시하기 시작했다. 테스트를 무시하는 습관이 생기면 테스트가 아무리 많아도 의미가 없다. 그 이후로는 critical path 5개만 E2E로 유지하고 나머지는 전부 integration test로 전환했다. E2E 실행 시간은 12분에서 3분으로 줄었고, flaky test는 거의 사라졌다.

## 어디서부터 시작할까

테스트가 하나도 없는 프로젝트라면 전부 다 작성하려 하지 말고, 가장 자주 버그가 나는 페이지 하나를 골라서 integration test를 붙여보자. 대부분의 경우 폼이 있는 페이지다. 로그인, 회원가입, 주문서 작성.

그 하나의 테스트가 CI에서 돌아가고, PR마다 자동으로 실행되는 걸 보면, 다음 테스트를 작성하고 싶어진다. 커버리지 숫자를 채우려고 작성하는 테스트가 아니라, "이게 깨지면 진짜 문제니까" 작성하는 테스트. 그 차이가 프로덕션 버그 수에 반영된다.


rebase 처음 쓴 날, 커밋 3개를 날렸다.

정확히는 날린 줄 알았다. 금요일 오후 4시, 3일간 작업한 피처 브랜치에서 `git rebase main`을 쳤는데 conflict가 터졌다. 패닉 상태에서 이것저것 누르다가 터미널에 내 커밋이 사라진 걸 봤다. `git log`를 쳐봤다. 없다. 진짜 없다. 심장이 떨어지는 느낌이었다. 슬랙에 "rebase 하다가 커밋이 날아갔는데요..."라고 보낸 게 그날 가장 부끄러운 순간이었다.

팀 리드가 와서 `git reflog`를 치더니 30초 만에 복구해줬다. 그런데 그 뒤로 6개월 동안 나는 rebase를 안 썼다. merge만 썼다. 안전하니까. 익숙하니까.

이 글은 그런 나 같은 사람을 위한 것이다. rebase가 뭔지 설명하는 글은 차고 넘친다. 나는 rebase를 **왜 두려워했고, 어떻게 두려움을 없앴는지** 쓰려고 한다.

## merge만 쓰던 시절의 git log

merge만 쓰면 히스토리가 이렇게 된다.

```bash
$ git log --graph --oneline --all

*   e7a1b3c (HEAD -> main) Merge branch 'feature/payment'
|\
| * d4f2a1e 결제 로직 수정
| * b3c8e7f 결제 페이지 UI
|/
*   a1d9f3b Merge branch 'feature/cart'
|\
| * 9e7c2d4 장바구니 수량 변경
| * 7f1a8b3 장바구니 페이지 추가
|/
*   5c3d6e9 Merge branch 'feature/login'
|\
| * 3b8f1c7 로그인 에러 핸들링
| * 1a4d7e2 로그인 폼 구현
|/
* f9e2c5a 초기 설정
```

보면 안다. 모든 피처가 갈라졌다 합쳐지는 모양이 반복된다. 피처 브랜치가 3개면 괜찮다. 근데 팀원 5명이 각각 브랜치 2~3개씩 돌리면? `git log --graph`를 치면 지하철 노선도가 나온다. 어떤 커밋이 어떤 맥락인지 따라가기가 어렵다.

rebase를 쓰면 이렇게 바뀐다.

```bash
$ git log --graph --oneline --all

* e7a1b3c (HEAD -> main) 결제 로직 수정
* d4f2a1e 결제 페이지 UI
* a1d9f3b 장바구니 수량 변경
* 9e7c2d4 장바구니 페이지 추가
* 5c3d6e9 로그인 에러 핸들링
* 3b8f1c7 로그인 폼 구현
* f9e2c5a 초기 설정
```

일직선이다. 한눈에 읽힌다.

## rebase가 하는 일

merge는 두 브랜치를 합치면서 "merge commit"을 만든다. 두 줄기를 하나로 묶는 매듭 같은 것이다.

rebase는 다르다. 내 브랜치의 커밋들을 떼어내서, 대상 브랜치의 최신 커밋 위에 하나씩 다시 쌓는다. 마치 내가 처음부터 최신 main 위에서 작업한 것처럼 만들어준다.

```bash
# feature 브랜치에서 작업 중
git checkout feature/payment

# main의 최신 커밋 위로 내 커밋들을 옮기기
git rebase main
```

이게 전부다. 개념 자체는 단순하다. 문제는 conflict가 날 때다.

## conflict, 그리고 패닉

merge conflict는 한 번에 다 터진다. 전부 고치고 커밋 하나 만들면 끝이다.

rebase conflict는 커밋 하나하나 적용하면서 터진다. 커밋이 5개면 최악의 경우 5번 conflict를 해결해야 한다. 처음 겪으면 "이게 언제 끝나지?"라는 공포가 온다.

내가 처음 rebase를 망친 날도 이 상황이었다. 두 번째 커밋에서 conflict가 터졌고, 해결하는 법을 몰랐다. `git rebase --abort`를 치면 된다는 걸 그때는 몰랐다.

```bash
# conflict가 터졌을 때 선택지

# 1. 포기하고 원래 상태로 돌아가기
git rebase --abort

# 2. conflict 해결 후 계속 진행
# 파일 수정 → git add →
git rebase --continue

# 3. 현재 커밋을 건너뛰기 (거의 안 씀)
git rebase --skip
```

`--abort`만 알아도 rebase의 공포 절반은 사라진다. 뭘 해도 원래대로 돌아갈 수 있으니까.

## reflog: 진짜 안전망

`--abort`가 안 먹히는 상황이 올 수도 있다. rebase를 끝까지 해버렸는데 결과가 이상할 때. 그때 쓰는 게 `git reflog`다.

```bash
$ git reflog

e7a1b3c (HEAD -> feature/payment) HEAD@{0}: rebase (finish): returning to refs/heads/feature/payment
d4f2a1e HEAD@{1}: rebase (pick): 결제 로직 수정
b3c8e7f HEAD@{2}: rebase (pick): 결제 페이지 UI
a1d9f3b HEAD@{3}: rebase (start): checkout main
9c4f7d2 HEAD@{4}: commit: 결제 로직 수정
8b3e6a1 HEAD@{5}: commit: 결제 페이지 UI
```

reflog는 HEAD가 움직인 모든 기록을 보여준다. rebase 이전 상태가 `HEAD@{4}`와 `HEAD@{5}`에 그대로 있다. 여기로 돌아가면 된다.

```bash
# rebase 이전 상태로 돌아가기
git reset --hard HEAD@{4}
```

이걸 처음 알았을 때의 안도감을 아직도 기억한다. Git은 뭔가를 진짜로 삭제하는 경우가 거의 없다. reflog에 90일간 보관된다. 90일이면 충분하다.

Julia Evans가 자기 블로그에서 이런 말을 한 적 있다. "Git에서 작업을 잃어버리는 건 생각보다 훨씬 어렵다." 나도 이제 동의한다.

## interactive rebase: 진짜 강력한 부분

`git rebase main`은 단순히 커밋을 옮기는 것이다. `git rebase -i`는 커밋 히스토리를 **편집**하는 것이다.

우리 팀에서 내가 실제로 작업한 피처 브랜치의 커밋 로그를 보자.

```bash
$ git log --oneline

a7b3c1d WIP: 결제 페이지
f2e8d4a 아 이거 왜 안 되지
c9d1f7b 결제 API 연동
b4a6e2c 타입 에러 수정
d8f3a5e 결제 페이지 UI 완성
e1c7b9f lint 수정
```

이런 히스토리를 main에 merge하면? 리뷰어가 "아 이거 왜 안 되지"라는 커밋 메시지를 영원히 보게 된다.

```bash
git rebase -i HEAD~6
```

이러면 에디터가 열린다.

```
pick a7b3c1d WIP: 결제 페이지
pick f2e8d4a 아 이거 왜 안 되지
pick c9d1f7b 결제 API 연동
pick b4a6e2c 타입 에러 수정
pick d8f3a5e 결제 페이지 UI 완성
pick e1c7b9f lint 수정
```

각 줄 앞의 `pick`을 바꿀 수 있다.

```
pick d8f3a5e 결제 페이지 UI 완성
squash a7b3c1d WIP: 결제 페이지
squash f2e8d4a 아 이거 왜 안 되지
squash e1c7b9f lint 수정
pick c9d1f7b 결제 API 연동
squash b4a6e2c 타입 에러 수정
```

- **pick**: 이 커밋 유지
- **squash**: 이전 커밋에 합치기 (메시지 수정 가능)
- **fixup**: squash와 같지만 커밋 메시지 버림
- **reword**: 커밋 메시지만 수정
- **drop**: 커밋 삭제
- **edit**: 커밋 내용 수정 후 계속

저장하고 닫으면 커밋 메시지를 정리할 수 있는 에디터가 다시 뜬다. 결과는 깔끔한 2개 커밋이 된다.

```bash
$ git log --oneline

f4d2a8c 결제 API 연동 및 에러 처리
e9b7c3a 결제 페이지 UI 구현
```

PR 리뷰어 입장에서 생각해보면, 6개 커밋을 하나하나 보는 것보다 논리적으로 정리된 2개 커밋을 보는 게 훨씬 낫다. 실제로 우리 팀에서 이 습관을 들인 후 코드 리뷰 속도가 눈에 띄게 빨라졌다. 측정한 건 아니다. 체감이다. 하지만 체감이 확실했다.

## rebase 하면 안 되는 때

이게 중요하다. rebase는 커밋의 해시를 바꾼다. 같은 내용이어도 새로운 커밋이 된다는 뜻이다.

혼자 쓰는 브랜치에서는 아무 문제 없다. 하지만 다른 사람과 같이 쓰는 브랜치에서 rebase를 하면?

내가 rebase로 커밋 해시를 바꿨다. 팀원은 원래 해시를 기준으로 작업 중이다. 둘이 push하면 난리가 난다.

```bash
# 절대 하면 안 되는 것
git checkout main
git rebase some-branch
git push --force  # main에 force push = 팀 전체 혼란
```

규칙은 간단하다.

**이미 push한 커밋, 다른 사람이 보고 있는 브랜치에서는 rebase 하지 않는다.**

내 로컬 브랜치, 아직 push 안 한 커밋, 혹은 나만 쓰는 피처 브랜치에서만 rebase를 쓴다. 이 규칙만 지키면 사고가 안 난다.

## 우리 팀이 정한 rebase 컨벤션

처음에는 "rebase 쓸 사람은 쓰고, merge 쓸 사람은 쓰고" 식이었다. 당연히 히스토리가 엉망이 됐다. 2개월쯤 지나서 팀 미팅에서 컨벤션을 정했다.

**1. 피처 브랜치는 PR 올리기 전에 main 위로 rebase한다.**

```bash
git checkout feature/my-work
git fetch origin
git rebase origin/main
# conflict 해결 후
git push --force-with-lease
```

`--force-with-lease`는 일반 `--force`보다 안전하다. 내가 마지막으로 fetch한 이후에 누군가 같은 브랜치에 push했다면 거부된다. 실수로 남의 작업을 덮어쓰는 걸 막아준다.

**2. PR의 커밋은 interactive rebase로 정리한다.**

"WIP", "fix typo", "lint 수정" 같은 커밋은 squash한다. PR 하나에 커밋 1~3개가 이상적이다. 커밋 하나하나가 "이것만 revert해도 말이 되는" 단위여야 한다.

**3. main 브랜치에는 squash merge를 쓴다.**

```bash
# GitHub PR 설정에서 "Squash and merge"를 기본으로
# 또는 CLI에서
gh pr merge --squash
```

이러면 피처 브랜치의 커밋이 아무리 지저분해도 main에는 깔끔한 커밋 하나만 들어간다. interactive rebase를 아직 안 익힌 팀원도 main 히스토리를 어지럽히지 않게 된다.

이 세 규칙을 정한 뒤로 `git log --oneline main`을 치면 피처 단위로 깔끔하게 읽히는 히스토리가 나온다. 새로 입사한 사람이 "이 프로젝트 히스토리 깔끔하네요"라고 했을 때 좀 뿌듯했다.

## 실전에서 자주 쓰는 패턴 몇 가지

커밋 메시지 하나만 고치고 싶을 때:

```bash
# 마지막 커밋 메시지 수정
git commit --amend -m "새 메시지"

# 3개 전 커밋 메시지 수정
git rebase -i HEAD~3
# 해당 커밋의 pick을 reword로 바꾸기
```

작업 중간에 main이 많이 앞서갔을 때:

```bash
git fetch origin
git rebase origin/main

# conflict가 많으면 포기하고 merge로 전환하는 것도 방법이다
git rebase --abort
git merge origin/main
```

이게 중요한 포인트다. rebase가 무조건 좋은 건 아니다. conflict가 너무 많으면 merge가 나을 수 있다. 오래된 브랜치를 main에 rebase하면 모든 커밋에서 conflict가 터질 수 있다. 그럴 때는 merge 한 번이 훨씬 효율적이다.

방금 커밋한 걸 이전 커밋에 합치고 싶을 때:

```bash
# "oops" 수정을 직전 커밋에 합치기
git add .
git commit --fixup HEAD~1
git rebase -i --autosquash HEAD~3
```

`--fixup`과 `--autosquash` 조합은 한번 익히면 매일 쓰게 된다. fixup 커밋을 만들면 interactive rebase에서 자동으로 해당 커밋 아래에 fixup으로 배치해준다.

## 두려움이 사라진 시점

돌이켜보면 전환점은 reflog를 직접 써서 복구에 성공한 날이었다.

rebase 중에 뭔가 꼬여서 히스토리가 이상해졌다. 예전 같으면 패닉에 빠져서 팀 리드를 불렀을 것이다. 대신 `git reflog`를 쳤다. rebase 시작 직전의 HEAD를 찾았다. `git reset --hard`로 돌아갔다. 다시 rebase를 쳤다. 이번엔 conflict를 차분하게 하나씩 해결했다.

5분이면 끝날 일이었다.

두려움의 대부분은 "되돌릴 수 없다"는 착각에서 온다. Git에서는 거의 모든 것을 되돌릴 수 있다. reflog가 그걸 보장한다. 그걸 직접 경험하고 나면, rebase는 그냥 도구 중 하나가 된다. 무서운 명령어가 아니라 편한 명령어가 된다.

지금 팀에서 rebase를 매일 쓴다. 특별한 일이 아니다. `git fetch` 하고 `git rebase origin/main` 치는 게 아침에 커피 내리는 것만큼 자연스럽다. 거기까지 오는 데 6개월 정도 걸렸다. 그리고 그 6개월 동안 실제로 작업을 잃어버린 적은 한 번도 없었다.



CI/CD를 처음 셋업한 건 입사 3개월 차였다. 그 전까지 우리 팀의 배포 프로세스는 이랬다.

1. 개발자가 로컬에서 `npm run build` 실행
2. 빌드된 파일을 S3에 수동 업로드
3. CloudFront 캐시 무효화를 AWS 콘솔에서 클릭

매주 금요일 오후에 이 작업을 하는데, 한 번은 빌드를 잘못된 브랜치에서 하는 바람에 개발 중인 피처가 프로덕션에 배포된 적이 있다. 다행히 10분 만에 발견했지만, 그 뒤로 "이건 자동화해야 한다"는 공감대가 형성됐다.

## 린트 + 타입 체크

가장 먼저 한 건 PR에 린트와 타입 체크를 붙이는 거였다. 코드 리뷰에서 "여기 세미콜론 빠졌네요" 같은 코멘트를 안 달아도 되게 하는 게 목적이었다.

```yaml
# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main, develop]

jobs:
  lint-and-typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "npm"

      - run: npm ci

      - name: ESLint
        run: npx eslint . --max-warnings 0

      - name: TypeScript
        run: npx tsc --noEmit

      - name: Prettier
        run: npx prettier --check "src/**/*.{ts,tsx,css}"
```

`--max-warnings 0`이 중요하다. 이걸 안 넣으면 warning이 수백 개 쌓여도 CI가 통과한다. warning은 "나중에 고칠 것"이 아니라 "지금 고칠 것"이어야 한다. 안 그러면 영원히 안 고친다.

`npm ci`는 `npm install`과 다르다. `package-lock.json`을 기준으로 정확한 버전을 설치한다. CI에서는 항상 `npm ci`를 써야 한다. `npm install`을 쓰면 lock 파일과 다른 버전이 설치되는 경우가 있다.

처음에 이것만 돌렸는데, 실행 시간이 3분 정도 걸렸다. 대부분 `npm ci`에서 소모되는 시간이었다. `actions/setup-node`의 `cache: "npm"` 옵션으로 node_modules 캐싱을 하면 1분 정도로 줄어든다.

## 테스트

다음으로 테스트를 추가했다. 테스트를 린트와 별개의 job으로 분리한 이유가 있다.

```yaml
jobs:
  lint-and-typecheck:
    runs-on: ubuntu-latest
    steps:
      # ... 위와 동일

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "npm"

      - run: npm ci

      - name: Unit & Integration Tests
        run: npx vitest run --coverage

      - name: Upload Coverage
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: coverage-report
          path: coverage/
```

job을 분리하면 병렬로 실행된다. 린트가 끝날 때까지 기다렸다가 테스트를 돌리는 게 아니라, 동시에 돌아간다. 전체 CI 시간이 줄어든다.

`if: always()`는 테스트가 실패해도 커버리지 리포트를 업로드하라는 뜻이다. 실패했을 때 어디가 문제인지 리포트를 보고 파악하기 위해서.

## 빌드

빌드는 테스트와 린트가 모두 통과한 뒤에 실행되어야 한다. `needs` 키워드를 쓴다.

```yaml
  build:
    runs-on: ubuntu-latest
    needs: [lint-and-typecheck, test]
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "npm"

      - run: npm ci

      - name: Build
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ vars.API_URL }}
          NEXT_PUBLIC_GA_ID: ${{ vars.GA_ID }}

      - name: Upload Build
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: .next/
          retention-days: 1
```

환경 변수를 GitHub의 Variables에서 관리한다. `secrets`는 로그에 마스킹되는 비밀 값(API 키 등)에 쓰고, `vars`는 공개되어도 괜찮은 설정 값에 쓴다. `NEXT_PUBLIC_`으로 시작하는 환경 변수는 클라이언트 번들에 포함되는 값이니까 `vars`로 충분하다.

빌드 아티팩트를 `upload-artifact`로 올리는 이유는, 배포 job에서 다시 빌드하지 않기 위해서다. 빌드는 한 번만.

## 배포

main 브랜치에 merge되면 자동 배포를 한다. Vercel을 쓰면 이 과정이 거의 필요 없는데, 우리는 AWS를 쓰고 있어서 직접 구성해야 했다.

```yaml
  deploy:
    runs-on: ubuntu-latest
    needs: [build]
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    environment: production
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/

      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: Deploy to S3
        run: aws s3 sync .next/static s3://${{ vars.S3_BUCKET }}/_next/static --delete

      - name: Invalidate CloudFront
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ vars.CF_DISTRIBUTION_ID }} \
            --paths "/*"
```

`environment: production`을 설정하면 GitHub에서 환경별로 시크릿을 관리할 수 있고, 배포 이력도 추적된다. 그리고 환경에 protection rule을 걸어서 특정 사람의 승인이 있어야 배포가 진행되게 할 수도 있다.

처음에는 `--paths "/*"`로 전체 캐시를 무효화했는데, 이러면 CDN 비용이 올라간다. 나중에 변경된 파일만 무효화하도록 개선했다. Next.js의 `_next/static` 경로는 해시가 포함되어 있어서 무효화할 필요가 없고, `index.html` 같은 진입점만 무효화하면 된다.

## Preview 배포

PR마다 프리뷰 환경을 만드는 건 코드 리뷰의 질을 높여줬다. 코드만 보는 것과 실제 화면을 보는 건 차이가 크다.

```yaml
  preview:
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    needs: [build]
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/

      # 프리뷰 배포 로직 (Vercel, Netlify, 또는 S3 + 별도 도메인)

      - name: Comment PR
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `🔗 Preview: https://preview-${context.issue.number}.example.com`
            })
```

PR에 프리뷰 URL이 코멘트로 달린다. 코드 리뷰어가 브랜치를 checkout 받아서 로컬에서 빌드할 필요가 없다. 링크만 클릭하면 된다. 디자이너나 PM도 바로 확인할 수 있어서 피드백 루프가 짧아졌다.

## 삽질했던 것들

**node_modules 캐시가 안 맞는 문제.** `package-lock.json`의 해시를 캐시 키로 쓰는데, OS 버전이 달라지면 네이티브 바이너리가 호환이 안 될 수 있다. `runs-on`을 바꿨더니 캐시가 터진 적이 있다.

**환경 변수 빠뜨림.** 로컬에서는 `.env.local`에 있어서 잘 되는데, CI에서 환경 변수를 안 넣어서 빌드가 깨지는 경우. 환경 변수가 추가될 때마다 GitHub Settings에도 넣어야 한다는 걸 잊는다. 이것 때문에 CI에서 빌드 직전에 필수 환경 변수가 있는지 체크하는 스크립트를 넣었다.

```bash
#!/bin/bash
# scripts/check-env.sh
required_vars=("NEXT_PUBLIC_API_URL" "NEXT_PUBLIC_GA_ID")

for var in "${required_vars[@]}"; do
  if [ -z "${!var}" ]; then
    echo "ERROR: $var is not set"
    exit 1
  fi
done

echo "All required environment variables are set"
```

**시크릿 노출.** `echo`로 디버깅하다가 시크릿을 로그에 찍은 적이 있다. GitHub Actions는 secrets으로 등록된 값은 로그에서 자동 마스킹해주지만, 그 값을 가공한 결과는 마스킹이 안 될 수 있다. CI에서 디버깅할 때는 `echo`를 되도록 안 쓰는 게 좋다.

## CI 시간 최적화

최종적으로 전체 CI 파이프라인이 PR 기준 4분, 배포 기준 6분 정도 걸린다. 처음에 10분 넘게 걸렸던 걸 줄인 방법은 이렇다.

- `npm ci` 캐싱: 2분 → 30초
- 린트/테스트 병렬 실행: 순차 5분 → 병렬 3분
- 빌드 아티팩트 재사용: 배포 시 빌드 중복 제거

더 줄이려면 테스트를 sharding해서 여러 머신에서 나눠 돌리는 방법이 있다. 아직 테스트가 그 정도로 많지 않아서 안 했지만, 테스트가 200개를 넘어가면 고려해야 할 것 같다.

CI/CD를 한 번 제대로 구축해놓으면 팀 전체의 생산성이 올라간다. "빌드 돌리는 동안 기다리는 시간"이 사라지고, "배포하다가 실수하면 어쩌지"라는 불안감도 없어진다. 투자 대비 리턴이 확실한 작업 중 하나다.


사이드 프로젝트를 4개 시작해서 0개를 완성한 적이 있다. 한 해 동안. 다 이유가 있었다. 디자인이 마음에 안 들어서, 폴더 구조를 다시 잡고 싶어서, 상태 관리를 Zustand에서 Jotai로 바꾸고 싶어서, 아니 그것보다 전역 상태가 이렇게 많을 필요가 있나 싶어서. 이유는 항상 달랐는데 패턴은 같았다. 시작은 열정적으로, 중간에 "이건 아닌데" 하면서 멈추고, 결국 방치. 깃허브에 4개의 레포가 마지막 커밋 날짜 3개월 전인 상태로 남아 있다.

완벽주의라고 하면 좀 거창하다. 그냥 "내가 만족 못 하면 공개 안 해"라는 마인드였다. 근데 이게 결과적으로는 아무것도 공개 안 하는 거랑 같았다. 만족의 기준이 끝없이 올라가니까. 90%에서 "여기가 좀 아쉬운데" 하면서 95%를 만들면, 95%에서 또 "저기가 눈에 밟힌다" 하면서 97%를 향해 간다. 100%는 영원히 오지 않는다.

## 80%의 발견

회사에서 일할 때는 다르다. 데드라인이 있으니까. 스프린트가 끝나면 뭐라도 나가야 한다. 그래서 "일단 동작하는 것"을 만든다. 완벽하지 않아도.

처음에는 이게 불편했다. 이 코드가 프로덕션에 이대로 나간다고? 에러 핸들링도 제대로 안 했는데? 로딩 상태도 스켈레톤으로 안 바꿨는데? 빈 화면에 스피너만 도는 건 2024년 기준으로 좀 그런데? 근데 나가고 나면 재밌는 일이 생긴다. 유저가 생각지도 못한 방식으로 쓴다. 내가 고민했던 부분은 아무도 신경 안 쓰고, 신경도 안 쓴 부분에서 버그 리포트가 온다.

한번은 검색 필터 기능을 만들었는데, 필터 조합이 복잡해질 때의 UX를 엄청 고민했다. 3개 이상 필터가 걸리면 태그 형태로 보여줄지, 드롭다운으로 접을지, 초기화 버튼 위치는 어디가 좋을지. Figma에서 세 가지 시안을 직접 그려봤다. 디자이너도 아닌데. 일주일을 고민했다. 결국 출시하고 한 달 후 어드민에서 데이터를 봤더니, 필터 3개 이상 쓰는 유저가 전체의 2%였다. 98%의 유저한테는 필요 없는 고민을 일주일 동안 한 거다.

그때부터 "일단 출시하고 보자"가 조금 편해졌다. 유저가 실제로 뭘 쓰는지는 출시 전에는 알 수 없다. 내 머릿속의 유저와 실제 유저는 거의 항상 다르다.

## 완벽주의자의 하루

내 완벽주의는 코드에만 있는 게 아니었다. 블로그 글 하나 쓰는 데도 그랬다.

글을 쓰기 시작하면 구조부터 잡는다. 서론, 본론, 마무리. 각 섹션에 뭘 쓸지 메모한다. 그리고 쓰기 시작하면 첫 문장에서 막힌다. "이 첫 문장이 사람을 끌어당겨야 하는데." 한 시간 동안 첫 문장만 고치다가 지쳐서 창을 닫는다. 초안도 완성 못 한 글이 노션에 12개 있다. 제목만 쓰고 방치된 것까지 합치면 20개가 넘을 것 같다.

커밋 메시지도 그렇다. conventional commit을 쓰는데, `feat`인지 `fix`인지 `refactor`인지 고민하다가 시간을 쓴다. 기존 함수를 수정해서 새 기능을 추가한 건 `feat`인가 `refactor`인가? 이걸 3분 동안 생각한다. 3분이 뭐 대수냐 싶지만, 하루에 커밋을 10번 하면 30분이다. 한번은 커밋 메시지에 오타가 있어서 `git rebase -i`로 메시지를 고친 적도 있다. 그것도 개인 프로젝트에서. 아무도 안 볼 메시지를.

코드 리뷰를 올릴 때도 마찬가지다. PR 올리기 전에 내 코드를 세 번은 본다. "이 변수명이 좀 애매한데", "이 함수 길이가 좀 긴데", "이 로직을 커스텀 훅으로 빼야 하나?" 고민하다 보면 간단한 피처인데 PR 올리는 데 반나절이 걸린다. PR 설명도 장문으로 쓴다. 변경 사항, 이유, 스크린샷, 관련 이슈. 꼼꼼한 건 좋은데, 30분짜리 작업에 PR 설명 쓰는 데 1시간 걸리면 본말전도다.

## 팀 리드가 해준 말

분기 회고 때 팀 리드가 피드백을 줬다. "코드 퀄리티는 좋은데, 속도가 좀 아쉽다." 직접적이었다. 나는 퀄리티를 위해 속도를 희생한다고 생각했는데, 팀 리드 입장에서는 그냥 느린 거였다.

좀 충격이었다. 나는 "꼼꼼한 개발자"라고 생각했는데, 팀에서는 "느린 개발자"로 보고 있었던 거다. 물론 팀 리드가 그렇게 직접적으로 말한 건 아니지만, 뉘앙스가 그랬다.

그때 팀 리드가 이런 말을 했다. "완벽한 코드는 없어. 지금 좋은 코드도 6개월 후에 보면 고치고 싶어져. 그러니까 지금 시점에서 적당한 걸 빠르게 내고, 문제 생기면 그때 고치는 게 낫다." 머리로는 알겠는데 손이 안 따라갔다. 적당한 게 뭔지를 모르겠는 거다. "적당히"라는 말이 제일 어렵다. 기준이 없으니까.

나중에 생각해보니까, 팀 리드가 올리는 PR은 간결했다. 설명도 핵심만 쓰고, 코드도 필요한 것만 담겨 있었다. 그런데 퀄리티가 떨어지는 건 아니었다. 불필요한 게 없을 뿐이었다. "이게 적당함이구나" 하는 걸 코드로 보여준 셈이었다.

## 적당함을 배우는 중

요즘은 규칙을 하나 만들어서 쓴다. "이 고민이 1시간 넘어가면 일단 현재 상태로 간다." 타이머를 쓰는 건 아니고, 체감으로. 변수명 고민이 길어지면 일단 지금 이름으로 커밋한다. 나중에 더 좋은 이름이 떠오르면 그때 바꾸면 된다. 보통은 안 떠오르고, 안 떠오르면 지금 이름도 괜찮았다는 뜻이다.

PR 설명도 줄였다. "뭘 했는지"와 "왜 했는지"만 쓴다. 스크린샷은 UI 변경이 있을 때만. 이전에는 콘솔 로그 하나 추가해도 스크린샷을 찍었는데, 이제는 안 한다.

사이드 프로젝트에도 적용 중이다. 최근에 만든 건 작은 크롬 익스텐션인데, CSS가 좀 구린 상태로 크롬 웹 스토어에 올렸다. 버튼 호버 효과도 없고, 반응형도 안 된다. 근데 기능은 동작한다. 탭에서 중복된 URL을 찾아서 닫아주는 기능. 다운로드 수는 6이다. 6명 중 4명이 나와 내 지인이다. 근데 괜찮다. "완성해서 배포한" 프로젝트가 생긴 거니까. 4개를 시작하고 0개를 완성한 것보다 낫다.

블로그도 마찬가지다. 이 글도 사실 구조가 좀 들쭉날쭉하다. 예전 같으면 "흐름이 자연스럽지 않아"라면서 발행을 미뤘을 텐데, 지금은 그냥 올린다. 발행 버튼 누르는 게 고치는 것보다 중요하다. 드래프트 상태로 영원히 남는 것보다 구린 글이라도 나간 게 낫다.

## 이상한 역설

재미있는 건, 적당함을 추구하기 시작하니까 오히려 결과물이 많아졌다는 거다. 예전에는 한 달에 블로그 0개, 사이드 프로젝트 진행도 0%였는데, 요즘은 한 달에 글 2-3개, 사이드 프로젝트도 조금씩 나간다. 퀄리티는? 솔직히 예전에 공들여서 쓴 글과 비교하면 좀 떨어질 수 있다. 근데 예전 글은 세상에 나오지 않았으니까 비교 자체가 불가능하다. 서랍 속 명작보다 세상에 나온 졸작이 100배 낫다는 건 과장이 아니다.

완벽한 0개보다 적당한 10개가 낫다. 이건 틀린 말이 아닌데, 체화하는 건 진짜 어렵다.

아직도 PR 올리기 전에 코드를 두 번은 본다. 세 번에서 두 번으로 줄인 거다. 미세한 발전. 커밋 메시지 오타도 이제는 그냥 둔다. 대부분은. 가끔은 아직도 고치지만. 뇌의 어딘가에서 "고쳐야 해"라는 알람이 울리는 걸 무시하는 연습을 하고 있다.

적당함도 연습이 필요한 기술인 것 같다. 아이러니하게도 그 연습을 완벽하게 하려는 나를 발견할 때가 있다. "오늘은 적당함 연습을 제대로 했나?" 하고 되돌아보는 순간, 이게 또 완벽주의의 변형이라는 걸 깨닫는다.

최근에 읽은 글에서 "done is better than perfect"라는 말이 있었다. 실리콘밸리에서 자주 쓰는 말이라고. 끝내는 게 완벽한 것보다 낫다. 머리로는 백 번 동의하는데, 키보드 위에서는 아직 자주 잊어버린다. 어제도 컴포넌트 이름을 15분 동안 고민하다가 "아 그냥 이거로 하자" 하고 넘겼다. 15분이 짧아 보이지만, 그 15분 동안 다른 일을 할 수 있었다는 걸 생각하면 아깝다. 근데 예전에는 30분이었으니까, 절반으로 줄인 거다.

어쩌면 완전히 고쳐지는 건 아닌지도 모르겠다. 그냥 같이 가는 거다.


첫 회사는 10명 규모의 스타트업이었다. 프론트엔드 개발자는 나 혼자. 코드 리뷰해줄 사람도, 아키텍처를 논의할 사람도 없었다. 구현은 할 수 있는데, 이게 맞는 방향인지 확인할 길이 없었다. "이 코드가 좋은 코드인지 모르겠다"는 불안이 항상 있었다.

사수가 있으면 좋겠다는 생각을 많이 했다. 하지만 없다고 성장을 멈출 수는 없었다.

## 코드 리뷰를 대체하는 것들

혼자서도 코드 리뷰의 효과를 얻는 방법이 있었다.

**시간 차 셀프 리뷰.** PR을 올리고 바로 머지하지 않는다. 다음 날 아침에 다시 본다. 하루만 지나도 코드가 다르게 보인다. "이 변수명이 왜 이러지?", "이 로직 너무 복잡한데?" — 어제의 나는 당연하다고 생각했던 것이 오늘은 어색하다.

**오픈소스 PR 읽기.** TanStack Query, Zustand 같은 라이브러리의 PR과 이슈를 읽었다. 메인테이너들이 어떤 기준으로 코드를 리뷰하고, 어떤 패턴을 선호하는지 보인다. 실력 있는 개발자의 코드 리뷰를 간접 체험하는 셈이다.

**커뮤니티 코드 리뷰.** 프론트엔드 디스코드, 오픈 카카오톡 방에서 코드 리뷰를 부탁했다. 처음에는 부끄러웠는데, 의외로 기꺼이 봐주는 사람이 많았다. 내 코드를 남에게 보여주는 것 자체가 성장의 기회다.

## 방향을 잡는 방법

사수가 없을 때 가장 힘든 건 "뭘 공부해야 하는지 모르는 것"이다. 사수가 있으면 "이번 분기에는 이걸 해보자"라고 방향을 제시해주는데, 혼자면 무한한 선택지 앞에서 방황한다.

**로드맵을 따라가지 않는다.** 프론트엔드 로드맵에 나열된 기술을 순서대로 공부하는 건 비효율적이다. 실무에서 마주치는 문제를 해결하면서 공부하는 게 훨씬 효과적이다. "이번 주에 성능 최적화가 필요하니까 Lighthouse를 파보자", "이미지 로딩이 느리니까 lazy loading을 배우자" — 문제가 공부의 방향을 정해준다.

**블로그와 뉴스레터를 읽는다.** 매일 아침 15분, 기술 블로그 RSS를 훑어본다. 모든 글을 정독하는 게 아니라, 제목만 읽으면서 "이건 지금 내 프로젝트에 써볼 수 있겠다" 싶은 것만 북마크한다. 일주일에 한두 개 정도 깊이 읽으면 충분하다.

**컨퍼런스 발표 영상을 본다.** FEConf, 인프콘, React Conf 같은 컨퍼런스 발표를 본다. 현업에서 어떤 문제를 어떻게 해결하는지, 업계의 흐름이 어디로 가는지 파악된다.

## 외부 멘토 찾기

사수가 없다고 멘토가 없는 건 아니다. 형태가 다를 뿐이다.

**온라인 멘토링 플랫폼.** 프로그래머스, 인프런, ADPList 같은 곳에서 멘토를 찾을 수 있다. 월 1~2회 30분 통화만으로도 방향 확인이 된다.

**밋업과 컨퍼런스.** 직접 가서 사람을 만나는 게 제일 좋았다. 발표 후 질문하거나, 네트워킹 시간에 대화를 걸었다. "저 혼자 프론트엔드 하고 있는데, 이런 상황에서 어떻게 하시나요?" — 이 한마디로 시작된 대화에서 많이 배웠다.

**블로그 글의 저자에게 연락하기.** 글을 읽고 도움이 됐으면, 저자에게 감사 메일이나 트윗을 보냈다. 놀라울 정도로 많은 사람이 답장해준다. 거기서 이어진 대화가 멘토링이 되기도 했다.

## 혼자여서 좋은 점도 있다

역설적으로, 혼자라서 빠르게 성장한 부분도 있다.

모든 결정을 내가 했다. 기술 선택, 아키텍처 설계, 배포 전략 — 전부 내 판단이었다. 사수가 있었으면 따라했을 결정을 직접 내리면서, 판단의 결과를 몸으로 겪었다. 잘못된 선택의 대가를 직접 치르니까 배움이 깊었다.

주인 의식이 강해졌다. "이 코드는 내 책임"이라는 인식이 있으니까 대충 못 한다. 코드 리뷰어가 잡아줄 거라는 안전망이 없으니까 스스로 꼼꼼해진다.

사수 없이 성장하는 건 분명 비효율적이다. 사수가 5분 만에 알려줄 수 있는 걸 혼자서 이틀 삽질하는 경우가 있으니까. 하지만 그 삽질이 쌓이면, 어떤 환경에서도 문제를 해결할 수 있는 자생력이 생긴다.



입사 3개월 차에 결제 페이지가 터졌다.

특정 유저만 주문 내역이 안 보이는 버그였다. QA에서 올라온 티켓에는 "간헐적으로 주문 목록이 비어 있음"이라고만 적혀 있었다. 나는 코드를 열고, 눈으로 읽기 시작했다. API 호출하는 부분을 보고, 상태 관리 쪽을 보고, 컴포넌트 렌더링 로직을 봤다. 2시간을 썼다. `console.log`를 열다섯 개쯤 찍었다. 원인을 못 찾았다.

그때 팀의 시니어 개발자가 슬랙에 메시지를 보냈다.

> "재현은 돼?"

나는 대답을 못 했다. 재현을 시도한 적이 없었다. 그냥 코드를 읽고 있었을 뿐이다.

그 사람은 내 자리로 와서 5분 만에 재현 조건을 찾았다. 신규 가입 유저가 첫 주문을 넣고 바로 주문 내역 페이지로 가면 발생한다. 거기서부터 컴포넌트를 하나씩 빼기 시작했다. 30분 만에 원인까지 도달했다. 나는 2시간 동안 코드를 읽었고, 그 사람은 30분 동안 코드를 줄였다.

그게 내가 "체계적 디버깅"이라는 걸 처음 배운 날이다. 나중에 Dan Abramov가 "How to Fix Any Bug"에서 거의 같은 방법론을 글로 정리한 걸 보고, 그때 배운 게 정확히 맞았다는 걸 확인했다.

## 1단계: 재현

디버깅은 재현에서 시작한다. 재현할 수 없으면 고쳤는지도 확인할 수 없다.

"가끔 안 돼요"는 버그 리포트가 아니다. 재현이란 "이 순서대로 하면 100% 발생한다"는 조건을 찾는 것이다. 위의 결제 페이지 예시라면:

```
1. 신규 계정으로 가입
2. 상품 하나 주문
3. /orders 페이지로 이동
4. 주문 목록이 비어 있음
5. 새로고침하면 정상 표시
```

눈으로만 확인되는 버그는 코드로 측정 가능한 형태로 바꿔야 한다. "스크롤이 이상하다"는 주관적이지만, 이건 객관적이다:

```tsx
const scrollBefore = container.scrollTop;
button.click();

setTimeout(() => {
  const scrollAfter = container.scrollTop;
  if (scrollAfter === scrollBefore) {
    console.error(`스크롤 안 됨: ${scrollBefore} → ${scrollAfter}`);
  }
}, 500);
```

나는 처음에 이 단계를 자주 건너뛰었다. "대충 여기가 문제인 거 아는데 뭘 재현까지 해." 근데 그 "대충"이 맞았던 적이 반도 안 됐다.

## 2단계: 격리

재현에 성공하면, 이제 질문이 바뀐다. 원인을 찾는 게 아니라 **원인이 아닌 걸 빼는 것**이다.

실제로 내가 겪었던 주문 목록 버그의 코드를 단순화하면 이런 구조였다:

```tsx
function OrderList() {
  const { data } = useQuery({ queryKey: ['orders'], queryFn: fetchOrders });
  const { user } = useAuth();

  return (
    <PageLayout>
      <UserHeader user={user} />
      <OrderTable items={data?.items ?? []} />
      <RecommendSection />
    </PageLayout>
  );
}
```

다 빼고 데이터만 찍어본다:

```tsx
function OrderList() {
  const { data } = useQuery({ queryKey: ['orders'], queryFn: fetchOrders });
  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}
```

데이터가 잘 나온다. API 문제는 아니다.

그러면 `OrderTable`을 넣어본다:

```tsx
function OrderList() {
  const { data } = useQuery({ queryKey: ['orders'], queryFn: fetchOrders });
  return <OrderTable items={data?.items ?? []} />;
}
```

빈 테이블. `OrderTable`이 문제다.

한 번에 하나만 바꿔야 한다. 이걸 지키는 게 생각보다 어렵다. 버그를 보고 있으면 "아 이거 분명 비동기 타이밍 문제일 거야" 같은 추측이 자꾸 떠오른다. 추측을 따라가면 코드를 이리저리 고치게 되고, 5분 전에 뭘 하고 있었는지 까먹는다. 한 번 그렇게 삽질해보면 "한 번에 하나만"이 왜 중요한지 몸으로 안다.

## 3단계: 축소

`OrderTable`이 범인이라는 건 알았는데, 이 컴포넌트가 150줄이다. 여기서부터는 이진 탐색이다.

```tsx
function OrderTable({ items }: { items: Order[] }) {
  const filtered = useFilteredOrders(items);
  const sorted = useSortedOrders(filtered);

  return (
    <table>
      <thead>...</thead>
      <tbody>
        {sorted.map(order => (
          <OrderRow key={order.id} order={order} />
        ))}
      </tbody>
    </table>
  );
}
```

훅을 다 빼고 `items`를 직접 렌더링하면?

```tsx
function OrderTable({ items }: { items: Order[] }) {
  return (
    <div>
      {items.map(order => <div key={order.id}>{order.name}</div>)}
    </div>
  );
}
```

정상이다. 그러면 `useFilteredOrders`만 넣어보면?

```tsx
function OrderTable({ items }: { items: Order[] }) {
  const filtered = useFilteredOrders(items);
  return (
    <div>
      {filtered.map(order => <div key={order.id}>{order.name}</div>)}
    </div>
  );
}
```

빈 화면. 여기다.

절반 자르고 테스트. 또 절반 자르고 테스트. 150줄도 7번이면 한 줄까지 좁힐 수 있다. 이 과정에 추측은 필요 없다. 기계적으로 반복하면 된다.

처음 이 방법을 배웠을 때는 좀 허탈했다. 시니어의 비밀 병기가 고작 이진 탐색이라니. 근데 실전에서 진짜 어려운 건 방법을 모르는 게 아니라, 추측하고 싶은 유혹을 참는 거다.

## 4단계: 원인

`useFilteredOrders`까지 좁혔다. 안을 보자.

```tsx
function useFilteredOrders(orders: Order[]) {
  const [status] = useQueryState('status');

  return orders.filter(order => {
    if (!status) return true;
    return order.status === status;
  });
}
```

이 코드 자체는 문제가 없다. 근데 호출하는 쪽을 다시 보면:

```tsx
<OrderTable items={data?.items ?? []} />
```

`data`가 `undefined`이면 빈 배열이 전달된다. React Query의 `data`는 최초 로딩 시 `undefined`다. 신규 유저가 첫 주문 직후에 `/orders`로 오면 캐시가 없으니까 `data`는 `undefined`이고, `data?.items ?? []`는 빈 배열이 된다. 빈 배열을 필터링하면 당연히 빈 배열.

새로고침하면 되는 이유도 설명된다. 첫 요청에서 캐시가 생기니까.

에러가 나면 차라리 빨리 알았을 텐데, `?? []`가 에러를 조용히 삼켜버렸다.

```tsx
function OrderList() {
  const { data, isLoading } = useQuery({
    queryKey: ['orders'],
    queryFn: fetchOrders,
  });

  if (isLoading) return <OrderSkeleton />;

  return (
    <PageLayout>
      <OrderTable items={data.items} />
    </PageLayout>
  );
}
```

수정은 간단했다. 로딩 상태를 명시적으로 처리하고, `?? []`를 제거했다. 찾는 데 걸린 시간에 비하면 고치는 건 30초였다.

## 추측과 제거

이 경험 이후로 디버깅할 때 의식적으로 순서를 따른다. 재현, 격리, 축소, 원인. 매번 이 순서를 지키는 건 아니고, 경험이 쌓이면 직감으로 바로 맞추는 경우도 많다. 시니어들이 코드를 보자마자 "아 이거네" 하는 건 같은 패턴을 수십 번 봤기 때문이다.

근데 직감이 안 맞을 때가 문제다. 예전에 스크롤 애니메이션이 안 먹는 버그가 있었는데, "비동기 타이밍 문제겠지" 하고 `async/await`를 1시간 동안 뜯어봤다. 원인은 부모 컴포넌트의 CSS `overflow: hidden`이었다.

그때 느꼈다. 추측이 맞으면 빠르다. 근데 틀리면 끝이 없다. 제거는 느리지만, 틀릴 수가 없다.

디버깅이 막힐 때 이 네 단계로 돌아와 보자.

1. 재현 — 100% 다시 만들 수 있는가?
2. 격리 — 관련 없는 코드를 빼도 재현되는가?
3. 축소 — 최소한의 코드로 좁혔는가?
4. 원인 — 왜 이 코드가 문제인지 설명할 수 있는가?

디버깅에서 가장 어려운 건 고치는 게 아니라 찾는 거다. 그리고 찾는 데에는 천재적인 직감보다, 지루할 만큼 성실한 제거가 더 잘 먹힌다. 적어도 내 경험에서는 그랬다.

<Callout type="tip">
AI 코딩 도구에게 버그를 맡길 때도 마찬가지다. "이거 고쳐줘"보다 "이 재현 조건에서 이 컴포넌트가 원인이야. 왜 빈 배열이 렌더링되는지 분석해줘"라고 줘야 쓸 만한 답이 온다.
</Callout>


상품 페이지의 로드 타임이 6초였다. 6초. 모바일에서는 더 심했다. PM이 "페이지가 너무 느려요"라고 할 때 나는 "렌더링 최적화를 해봐야겠네요"라고 대답했다. React.memo를 넣고, useMemo를 추가하고, 번들 사이즈를 분석했다. 효과가 미미했다. 원인이 거기가 아니었으니까.

Lighthouse를 돌렸다. Performance 47점. 빨간색. 진단 섹션을 열어보니 "Properly size images"와 "Serve images in next-gen formats"가 둘 다 빨간 경고를 내고 있었다. 네트워크 탭을 열었다. 페이지 총 전송량 21MB. 그중 이미지가 18MB. **전체 페이지 무게의 87%가 이미지였다.**

상품 리스트에 이미지 30개가 있었고, 전부 원본 크기(3000x2000px) JPEG로 내려보내고 있었다. 모바일 화면에 300px로 보이는 이미지를 3000px로 다운로드하고 있었던 거다. 10배 큰 이미지를 받아서 브라우저가 축소해서 보여주고 있었다.

JavaScript 번들을 아무리 깎아봐야, 이미지 18MB 앞에서는 의미가 없었다. 결국 이미지 최적화 하나로 로드 타임을 6초에서 1.8초로 줄였다. 4초 이상을 이미지에서만 벌었다. 이건 그 과정의 기록이다.

## 1단계: 포맷을 바꾸다

가장 먼저 한 건 이미지 포맷 변환이었다. JPEG를 WebP로 바꾸는 것만으로도 용량이 25~35% 줄어든다. AVIF로 바꾸면 WebP보다 20% 더 줄어든다.

처음에 AVIF로 전부 바꾸려고 했다. 용량이 가장 작으니까. 그런데 문제가 터졌다. **Safari에서 AVIF가 깨졌다.**

정확히는 Safari 16.3 이하에서 AVIF를 지원하지 않았다. 16.4부터 지원인데, 우리 유저의 약 12%가 16.3 이하였다. 그 유저들에게는 이미지가 아예 안 보였다. QA에서 잡혔는데, 개발 환경이 최신 Chrome이다 보니 배포 전까지 몰랐다.

`<picture>` 태그로 해결했다. 브라우저가 지원하는 포맷을 자동으로 선택하게 만드는 거다.

```html
<picture>
  <source srcset="/product.avif" type="image/avif" />
  <source srcset="/product.webp" type="image/webp" />
  <img src="/product.jpg" alt="상품 이미지" />
</picture>
```

AVIF를 지원하면 AVIF를, 아니면 WebP를, 둘 다 안 되면 JPEG를 쓴다. 점진적 향상(progressive enhancement)의 교과서적인 패턴이다.

이것만으로 이미지 용량이 18MB에서 약 8MB로 줄었다. 아직 충분하지 않았다.

## 2단계: 크기를 줄이다

3000x2000px 원본을 그대로 보내는 게 두 번째 문제였다. 모바일에서는 400px, 태블릿에서는 800px, 데스크탑에서는 1200px이면 충분한데 전부 3000px을 받고 있었다.

`srcset`으로 여러 크기를 제공했다.

```html
<img
  srcset="
    /product-400w.webp 400w,
    /product-800w.webp 800w,
    /product-1200w.webp 1200w
  "
  sizes="
    (max-width: 640px) 100vw,
    (max-width: 1024px) 50vw,
    33vw
  "
  src="/product-800w.webp"
  alt="상품 이미지"
/>
```

`sizes`가 중요하다. 브라우저에 "이 이미지가 뷰포트에서 얼마나 차지하는지" 힌트를 주는 거다. 모바일에서 100vw(화면 전체), 태블릿에서 50vw, 데스크탑에서 33vw라고 알려주면 브라우저가 적절한 크기를 선택한다.

이걸 수동으로 관리하면 미칠 것 같아서, 빌드 스크립트로 자동화했다.

```ts
import sharp from 'sharp';
import { glob } from 'glob';
import path from 'path';

async function optimizeImages() {
  const images = await glob('public/images/**/*.{jpg,jpeg,png}');
  const widths = [400, 800, 1200];

  for (const imagePath of images) {
    const ext = path.extname(imagePath);

    for (const w of widths) {
      await sharp(imagePath)
        .resize(w)
        .webp({ quality: 80 })
        .toFile(imagePath.replace(ext, `-${w}w.webp`));

      await sharp(imagePath)
        .resize(w)
        .avif({ quality: 65 })
        .toFile(imagePath.replace(ext, `-${w}w.avif`));
    }
  }
}

optimizeImages();
```

이 스크립트를 CI/CD에 넣었다. 원본 이미지를 커밋하면 빌드 시 자동으로 3가지 크기 x 2가지 포맷(WebP, AVIF)의 변환본이 생성된다.

포맷 변환 + 리사이징으로 이미지 용량이 8MB에서 2MB 아래로 줄었다.

## 3단계: lazy loading과 그 함정

이미지 30개를 페이지 로드 시 전부 다운로드할 필요가 없다. 화면에 보이는 것만 먼저 로드하고, 스크롤하면서 나머지를 로드하면 된다.

```html
<img src="/product.webp" alt="상품" loading="lazy" />
```

`loading="lazy"` 하나 추가하면 끝이다. 뷰포트에 가까워지면 로드를 시작한다.

여기서 함정이 있었다. **히어로 이미지까지 lazy loading을 걸어버린 거다.**

페이지 최상단의 큰 배너 이미지에 `loading="lazy"`를 넣었는데, 이게 LCP(Largest Contentful Paint)를 악화시켰다. web.dev의 LCP 최적화 가이드에서 명확하게 경고하고 있다. "LCP 이미지를 lazy-load하지 마라. 항상 불필요한 리소스 로드 지연을 초래한다." lazy loading은 뷰포트 진입 후에 로드를 시작하기 때문에, 이미 화면에 보이는 이미지에 적용하면 로드가 늦어진다.

수정은 간단했다. 첫 화면에 보이는 이미지(히어로 배너, 첫 번째 줄의 상품 카드 3~4개)에는 lazy loading을 제거하고, 나머지에만 적용했다.

```tsx
// next/image를 쓴다면 priority prop으로 해결
<Image
  src="/hero-banner.webp"
  alt="히어로 배너"
  fill
  priority  // lazy loading 대신 preload
  sizes="100vw"
/>
```

`priority`를 넣으면 `<link rel="preload">`가 자동으로 추가된다. 브라우저가 HTML을 파싱하면서 이미지를 미리 다운로드하기 시작한다. LCP가 확 줄어들었다.

추가로 `fetchpriority` 속성도 있다. next/image를 안 쓸 때 유용하다.

```html
<img fetchpriority="high" src="/hero.webp" alt="히어로" />
```

## 4단계: 이미지 CDN이 모든 걸 바꿨다

여기까지 하고 나서도, 이미지 관리가 고통스러웠다. 새 상품이 추가될 때마다 원본을 여러 크기로 변환하고, WebP와 AVIF를 생성하고, CDN에 올리는 과정이 번거로웠다. 상품팀에서 이미지를 올리면 개발팀이 수동으로 최적화하는 흐름이었다.

웹 퍼포먼스에 대해 깊이 다루는 한 엔지니어의 책에서 이미지 CDN을 강력히 추천하는 걸 읽었다. 이미지 CDN은 URL 파라미터로 크기, 포맷, 품질을 제어한다. 원본 하나만 올리면 CDN이 알아서 변환해준다.

```html

<img
  src="https://cdn.example.com/product.jpg?w=800&f=webp&q=80"
  alt="상품"
/>
```

Cloudinary, imgix, Cloudflare Images 같은 서비스를 검토했고, 결국 도입했다. 원본 이미지 하나만 업로드하면 CDN이 요청 브라우저에 따라 AVIF나 WebP를 자동 선택하고, 디바이스에 맞는 크기를 생성해준다. 빌드 스크립트가 필요 없어졌다. 상품팀이 원본만 올리면 끝이었다.

다만 web.dev에서 지적하는 트레이드오프가 있다. 서드파티 도메인에서 이미지를 서빙하면 DNS 조회, TCP 연결 등 추가 커넥션 비용이 든다. 가능하면 이미지 CDN을 자기 도메인으로 프록시하는 게 좋다. `images.example.com`을 CDN으로 연결하는 식으로.

## 최종 결과: 숫자로 보는 차이

전체 최적화 과정의 전후 비교다.

| 지표 | 이전 | 이후 |
|------|------|------|
| 이미지 총 용량 | 18MB | 1.6MB |
| 페이지 로드 시간 | 6초 | 1.8초 |
| LCP | 5.2초 | 1.1초 |
| Lighthouse Performance | 47 | 92 |

이미지 용량이 91% 줄었다. LCP가 4초 이상 개선됐다. Lighthouse 점수가 빨간색에서 초록색으로 바뀌었다.

정리하면 이렇게 했다.

1. **포맷 변환**: JPEG를 WebP + AVIF로. `<picture>` 태그로 폴백 처리.
2. **반응형 이미지**: `srcset`과 `sizes`로 디바이스에 맞는 크기 제공.
3. **lazy loading**: 뷰포트 밖 이미지에만 적용. **첫 화면 이미지는 절대 lazy loading하지 않는다.**
4. **LCP 이미지 우선 로드**: `priority` 또는 `fetchpriority="high"` 사용.
5. **이미지 CDN 도입**: 수동 변환 파이프라인을 없애고 자동화.

## next/image를 쓰면 대부분 해결된다

Next.js 프로젝트라면 `next/image`가 위의 대부분을 자동으로 해준다.

```tsx
import Image from 'next/image';

<Image
  src="/products/shoe.jpg"
  alt="운동화"
  width={800}
  height={600}
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
/>
```

WebP/AVIF 자동 변환, 디바이스별 리사이징, lazy loading 기본 적용, CLS 방지까지 해준다. `priority` prop 하나로 LCP 이미지도 처리된다.

외부 이미지를 쓸 때는 도메인 등록이 필요하다.

```js
// next.config.js
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cdn.example.com',
        pathname: '/images/**',
      },
    ],
  },
};
```

## 이미지가 먼저다

성능 최적화를 할 때 대부분의 개발자(나 포함)가 JavaScript부터 건드린다. React.memo, useMemo, 코드 스플리팅, 번들 분석. 그런데 실제로 페이지 무게에서 가장 큰 비중을 차지하는 건 이미지다. HTTP Archive 데이터에 따르면 평균 웹 페이지에서 이미지는 전체 무게의 절반 이상을 차지한다.

JavaScript 번들을 10KB 줄이는 노력보다, 이미지 포맷을 바꾸는 게 10배 효과적일 수 있다. 성능 문제가 있다면, Lighthouse를 돌리고, 네트워크 탭을 열어서 이미지 비중부터 확인하는 게 맞다. 의외로 답이 거기에 있는 경우가 많다.


입사 첫 주에 팀 슬랙 채널의 대화를 읽었다. 무슨 말인지 하나도 모르겠었다. "hydration mismatch 때문에 SSR fallback 처리 바꿔야 할 것 같아요"라는 문장에서 내가 아는 단어는 '때문에'와 '바꿔야'뿐이었다.

그 주에 나는 매일 퇴근 후에 동료들이 슬랙에서 언급한 기술 키워드를 노트에 적고 하나씩 검색했다. hydration이 뭔지, SSR에서 fallback이 왜 필요한지, mismatch는 어떤 상황에서 발생하는지. 한 가지를 이해하면 그 안에서 또 모르는 게 세 개씩 튀어나왔다. 구멍을 메울수록 구멍이 더 많이 보이는 기분이었다.

그래도 괜찮았다. 아직은. 신입이니까 모르는 게 당연하다고 스스로를 달랠 수 있었으니까. 문제는 그다음 달부터 시작됐다.

## 옆자리의 PR

입사 한 달쯤 됐을 때, 옆자리 동료의 PR을 봤다. 같은 팀이니까 코드 리뷰에 참여해보라는 팀 리드의 권유 때문이었다. 열어보는 순간 숨이 막혔다.

Custom hook 하나로 폼 상태 관리, 유효성 검사, 서버 동기화를 전부 처리하고 있었다. 타입 추론이 자연스럽게 흘러가서 사용하는 쪽에서는 타입을 하나도 안 써도 됐다. 에러 핸들링도 깔끔했다. 나는 리뷰 코멘트를 하나도 달지 못했다. 이해하는 데만 이틀이 걸렸으니까. 내가 뭔가를 지적하거나 제안할 수 있는 수준이 아니었다.

나는 저런 코드를 절대 못 짤 것 같았다.

일주일 뒤에 기술 공유 시간이 있었다. 팀에서 돌아가면서 최근에 공부한 것이나 프로젝트에서 겪은 기술적 문제를 공유하는 시간이었다. 한 팀원이 React Server Components의 직렬화 제약에 대해 발표했다. 다른 팀원이 Suspense boundary 설계에 대해 이야기했다. 또 다른 팀원은 번들 사이즈 최적화를 위해 barrel export를 제거한 경험을 공유했다.

다들 고개를 끄덕이고 있었다. 중간중간 날카로운 질문도 나왔다. 나만 멍하니 앉아서 모르는 용어를 받아 적고 있었다.

그날 저녁, 집에 오는 지하철 안에서 생각했다. '아 나 여기 있으면 안 되는 사람인가.'

## 끝없는 비교의 늪

회사 안에서의 비교만으로도 충분히 힘들었는데, 바깥 세계가 더 잔인했다.

트위터를 열면 나와 비슷한 연차의 개발자가 오픈소스 프로젝트에 기여한 PR을 자랑스럽게 공유하고 있었다. 어떤 사람은 React 생태계에서 꽤 쓰이는 라이브러리의 메인테이너였다. 같은 연차. 나는 회사 프로젝트의 버튼 컴포넌트 하나 만드는 데도 쩔쩔매고 있는데.

컨퍼런스 발표 영상도 그랬다. "주니어 개발자의 성능 최적화 여정"이라는 제목에 끌려서 봤는데, 발표자의 연차가 나보다 적었다. LCP를 어떻게 줄였고, CLS를 어떻게 잡았는지 명확하게 설명하고 있었다. 나는 LCP가 뭔지 지난주에 겨우 알았다.

자괴감이라는 단어로는 부족한 감정이었다. 정확히 말하면 '나는 개발자를 하면 안 되는 사람인데 실수로 개발자가 돼버린 것 같다'는 공포에 가까웠다. 면접에서 운 좋게 내가 아는 질문만 나와서 합격한 거고, 팀에서도 곧 내 실력이 들통나면 "이 사람을 왜 뽑았지?" 하게 될 거라는 시나리오가 머릿속에서 반복 재생됐다.

그 시기에 나는 아침마다 출근 준비를 하면서 속이 울렁거렸다. 코드를 치는 것 자체가 두려웠다. 내가 작성한 코드가 리뷰에 올라가면 "이것도 모르고 이렇게 짰어?"라는 반응이 올 것 같았다. 물론 실제로 그런 리뷰를 받은 적은 한 번도 없었다. 전부 내 머릿속에서 만들어낸 시나리오였다.

## 시니어의 한마디

전환점은 정말 사소한 데서 왔다.

어느 날 PR을 올렸는데, `IntersectionObserver`를 사용해서 무한 스크롤을 구현한 코드였다. 나름 검색도 많이 하고, 여러 블로그 글을 참고해서 작성했다. threshold 옵션이나 rootMargin 같은 것도 신경 써서 넣었다. 자신 없었지만 일단 올렸다.

시니어 한 분이 리뷰를 남겼다.

> "rootMargin 이렇게 쓸 수 있는 거 나도 이번에 처음 알았네요. 좋은 접근인 것 같아요."

짧은 코멘트였다. 그런데 그 한 줄을 읽었을 때 뭔가 균열이 생겼다. 그 사람도 모르는 게 있구나.

5년 차 시니어, 팀에서 기술적 의사결정을 주도하는 사람, 내가 PR을 올릴 때마다 날카로운 피드백을 주는 그 사람도 `IntersectionObserver`의 `rootMargin`을 이번에 처음 알았다고 했다. 충격이라고 하면 과장이지만, 분명히 인식의 전환이 일어나는 순간이긴 했다.

그때부터 좀 다르게 보이기 시작했다. 기술 공유 시간에 Server Components에 대해 발표하던 그 팀원 — 그 사람은 CSS 관련 질문이 나오면 은근히 말을 아꼈다. Suspense boundary를 설명하던 팀원은 상태 관리 라이브러리 논의에서는 "나는 잘 모르겠는데"를 자주 말했다.

아는 것의 총량이 다른 게 아니었다. 아는 영역이 다른 거였다.

내가 모르는 건 그 사람들이 더 많이 아는 게 아니라 그 사람들이 그 영역에 시간을 더 썼기 때문이었다. 나도 내가 시간을 쓴 영역에서는 다른 사람이 모르는 걸 알고 있었다. 다만 그걸 '당연한 것'이라고 생각해서 가치를 부여하지 않았을 뿐이다.

이건 나중에 읽은 글에서 본 개념인데, 사람은 자기가 아는 것의 가치를 과소평가하고 남이 아는 것의 가치를 과대평가하는 경향이 있다고 한다. 내가 딱 그랬다.

## 비교 대상을 바꿨다

깨달음이 왔다고 해서 임포스터 신드롬이 바로 사라지는 건 아니다. 머리로는 이해했는데 감정이 따라오지 않았다. 트위터를 열면 여전히 자괴감이 밀려왔고, 다른 팀원의 코드를 보면 여전히 "나는 왜 저렇게 못 짜지" 하는 생각이 들었다.

그래서 방법을 바꿨다. 비교를 안 하겠다는 건 비현실적이었다. 대신 비교 대상을 바꿨다. 다른 사람이 아니라, 6개월 전의 나.

6개월 전의 나는 `useEffect`의 cleanup 함수가 왜 필요한지 몰랐다. 지금은 안다. 6개월 전의 나는 TypeScript에서 제네릭을 쓸 때마다 에러가 나서 `any`를 갈겼다. 지금은 최소한 기본적인 제네릭 패턴은 자연스럽게 쓴다. 6개월 전의 나는 "이 컴포넌트 왜 리렌더링 되지?"라는 질문에 답을 못 했다. 지금은 React DevTools Profiler를 열고 원인을 추적할 수 있다.

이 비교는 항상 내가 이긴다. 당연하다. 시간이 흘렀으니까.

그리고 하나 더. 매달 말에 "이번 달에 새로 알게 된 것" 3개를 적기 시작했다. 거창한 게 아니다. 노션에 페이지 하나 만들어서 짧게 적는 거다.

```
2025년 11월
1. Next.js에서 revalidateTag 쓰면 특정 캐시만 선택적으로 날릴 수 있다
2. CSS의 :has() 선택자로 부모 스타일링이 가능하다
3. Promise.allSettled가 Promise.all보다 에러 핸들링에 유리한 경우가 있다
```

이게 쌓이니까 시각적으로 보인다. 내가 성장하고 있다는 증거가 문서로 남는다. 자괴감이 밀려올 때 이 목록을 스크롤 해보면 "아, 나 꽤 많이 알게 됐네"라는 감각이 돌아온다. 감정을 데이터로 이기는 방식이다.

회고까지 할 필요는 없다. 그냥 적기만 하면 된다. 3개가 안 떠오르는 달이 있으면 그때 좀 위기감을 느끼면 된다. 매달 3개도 새로 모르면 정말 정체된 거니까. 근데 실제로 3개가 안 되는 달은 거의 없었다. 의식하지 못할 뿐 매일 뭔가를 배우고 있더라.

## 또 다른 발견

비교를 멈추니까 예상 못 한 부수 효과가 있었다. 질문을 더 잘하게 됐다.

예전에는 모르는 걸 질문하는 것 자체가 무서웠다. "이런 것도 모르나"라는 소리를 들을 것 같아서. 그래서 혼자 2시간씩 검색하다가 결국 물어보고, 5분 만에 해결되는 일이 반복됐다. 모르는 걸 숨기는 데 에너지를 쓰고 있었다.

비교를 멈추고 나니까 "이거 모르는 게 부끄러운 게 아니라 모르면서 아는 척하는 게 부끄러운 거구나" 하는 생각이 들었다. 그래서 모르면 바로 물어보기 시작했다. "이 부분 제가 잘 모르는데 설명해주실 수 있나요?"라고. 놀랍게도 아무도 이상하게 생각하지 않았다. 오히려 "아 이거 저도 헷갈리는 부분이에요"라는 답이 돌아오는 경우가 많았다.

다들 각자의 '모르는 것'을 안고 일하고 있었다. 나만 모르는 게 아니었다.

## 사라지지 않는 것

솔직하게 쓰자면, 지금도 임포스터 신드롬이 완전히 사라지진 않았다.

새 프로젝트를 시작할 때마다 "이거 내가 할 수 있나?" 하는 생각이 든다. 처음 써보는 기술 스택으로 뭔가를 만들어야 할 때, 팀에서 나한테 기대하는 수준이 높아졌다고 느낄 때, 후배 개발자가 나한테 기술 질문을 했는데 바로 답을 못 할 때. 그때마다 가슴 어딘가가 서늘해진다.

근데 요즘은 그 감정을 다르게 해석한다.

그 불안이 완전히 사라지면 성장도 멈추는 거 아닌가 싶다. 내가 모든 걸 다 아는 것 같고, 어떤 프로젝트든 자신 있고, 배울 게 없다고 느끼는 상태 — 그게 오히려 더 위험한 거 아닌가. 불안은 내가 아직 성장 중이라는 신호다. 내 능력의 경계선 바깥에 있다는 뜻이고, 그 경계선이 넓어지고 있다는 뜻이다.

물론 이건 건강한 수준의 불안에 한해서 그렇다. 아침에 출근이 두렵고, 코드 에디터를 여는 것 자체가 스트레스이고, 잠을 못 이루는 수준이라면 그건 다른 문제다. 그때는 무리하지 말고 누군가에게 이야기해야 한다.

나의 경우는, 그 극심한 시기를 지나고 나서 불안의 농도가 많이 옅어졌다. 완전히 투명해지진 않았지만, 이제는 같이 갈 수 있는 정도가 됐다. "또 이 감정이네" 하고 알아채고, 6개월 전의 나를 떠올리고, 이번 달에 새로 알게 된 것 목록을 열어보고, 다시 코드를 친다.

반복이다. 화려한 해결책은 없다. 그냥 매일 조금씩, 어제보다 한 줄이라도 더 이해하면 되는 거다.



이벤트 루프를 "이해한다"와 "체감한다"는 완전히 다른 일이다. Call Stack이 비면 Task Queue에서 꺼내온다, Microtask가 Macrotask보다 먼저 실행된다. 이런 건 면접 준비하면서 외웠다. 근데 그걸 외운 상태에서도 버그를 만들었다. 세 번이나.

한 웹 개발 교육자가 이벤트 루프를 시각적으로 설명하는 시리즈를 만든 적이 있다. Call Stack에 함수가 쌓이고 빠지는 걸 애니메이션으로 보여주는 방식이었는데, 그걸 보고 "아 이제 완전히 이해했다"고 생각했다. 착각이었다. 시각화를 보고 이해한 건 메커니즘이었고, 내가 부족했던 건 "그래서 이게 내 코드에서 어떻게 터지는가"에 대한 감각이었다.

Julia Evans라는 개발자가 기술 글을 쓸 때 "지식의 빈틈을 채우는 것"에 집중한다고 한 적이 있다. 포괄적인 설명이 아니라, 사람들이 실제로 헷갈리는 지점을 정확히 짚는 방식. 이 글도 그 접근을 따라가려고 한다. 이벤트 루프의 전체 구조를 처음부터 설명하는 대신, 내가 실제로 만난 버그 3개를 통해 "아, 이래서 이벤트 루프를 알아야 하는구나"를 보여주려 한다.

## 버그 1: 폼이 두 번 제출됐다

입사 후 3개월쯤 됐을 때 일이다. 결제 페이지에서 "주문하기" 버튼을 누르면 가끔 주문이 두 번 들어간다는 CS가 올라왔다. 재현이 잘 안 됐는데, 특정 조건에서만 발생했다. 네트워크가 느린 환경에서 버튼을 빠르게 두 번 누르면 생기는 문제였다.

코드는 대충 이런 구조였다.

```typescript
const [isSubmitting, setIsSubmitting] = useState(false);

const handleSubmit = async () => {
  if (isSubmitting) return;
  setIsSubmitting(true);

  await submitOrder(orderData);
  setIsSubmitting(false);
};
```

얼핏 보면 문제가 없다. `isSubmitting`이 `true`면 early return하니까 중복 제출을 막을 수 있을 것 같다. 근데 실제로는 막지 못했다.

문제는 `setIsSubmitting(true)` 다음 줄에서 바로 `isSubmitting`이 `true`가 되지 않는다는 거다. React의 상태 업데이트는 동기적으로 즉시 반영되지 않는다. `setState`를 호출하면 React는 그 업데이트를 내부 큐에 넣고, 현재 실행 중인 이벤트 핸들러가 끝난 뒤에 배치로 처리한다.

이벤트 루프 관점에서 보면 이렇다.

```
첫 번째 클릭 이벤트 → Call Stack
  handleSubmit() 실행
  isSubmitting은 아직 false (이전 렌더의 값)
  setIsSubmitting(true) → React 내부 큐에 등록
  submitOrder() 시작 → Web API로 위임
  handleSubmit()이 Call Stack에서 빠짐

두 번째 클릭 이벤트 → 아직 리렌더링이 안 됐다!
  handleSubmit() 실행
  isSubmitting은 여전히 false ← 여기가 문제
  setIsSubmitting(true) → 또 큐에 등록
  submitOrder() 또 시작
```

두 번째 클릭 이벤트가 Call Stack에 올라갈 때, 아직 React의 리렌더링이 일어나지 않은 상태다. 리렌더링은 상태 업데이트가 배치된 후, 이벤트 루프의 다음 턴에서 발생한다. 두 클릭이 같은 이벤트 루프 턴에서, 혹은 리렌더링 전에 연달아 처리되면 둘 다 `isSubmitting === false`를 본다.

해결은 React 상태가 아니라 ref를 쓰는 거였다.

```typescript
const isSubmittingRef = useRef(false);

const handleSubmit = async () => {
  if (isSubmittingRef.current) return;
  isSubmittingRef.current = true;

  try {
    await submitOrder(orderData);
  } finally {
    isSubmittingRef.current = false;
  }
};
```

`useRef`는 리렌더링과 무관하게 값이 즉시 변경된다. `isSubmittingRef.current = true`가 실행되는 순간 바로 `true`가 되기 때문에, 두 번째 클릭 핸들러가 실행될 때 이미 `true`를 본다. React의 배치 업데이트 타이밍을 이벤트 루프와 연결해서 이해하지 못하면 절대 찾을 수 없는 버그다.

이 경험 이후로 "클릭 핸들러에서 상태로 중복 방지"를 쓸 때마다 한 번 더 생각하게 됐다. 상태가 반영되는 시점은 내가 코드를 쓰는 시점이 아니라 React가 결정한다.

## 버그 2: 스크롤 애니메이션이 버벅거렸다

두 번째 버그는 좀 더 미묘했다. 상품 리스트 페이지에서 무한 스크롤을 구현했는데, 스크롤할 때 페이지가 끊기듯 멈추는 현상이 있었다. 데이터 로딩 때문인 줄 알았는데 아니었다. 이미 로드된 데이터를 화면에 뿌리는 과정 자체가 문제였다.

원인은 스크롤 이벤트 핸들러 안에서 너무 많은 동기 작업을 하고 있었다는 거다.

```typescript
window.addEventListener('scroll', () => {
  // 1. 스크롤 위치 계산
  const scrollTop = document.documentElement.scrollTop;
  const scrollHeight = document.documentElement.scrollHeight;
  const clientHeight = document.documentElement.clientHeight;

  // 2. 각 상품 카드의 가시성 체크 (DOM 읽기)
  productCards.forEach(card => {
    const rect = card.getBoundingClientRect();
    if (rect.top < clientHeight) {
      card.classList.add('visible');
    }
  });

  // 3. 헤더 스타일 변경 (DOM 쓰기)
  if (scrollTop > 100) {
    header.classList.add('scrolled');
  } else {
    header.classList.remove('scrolled');
  }

  // 4. 하단 도달 시 다음 페이지 로드
  if (scrollTop + clientHeight >= scrollHeight - 200) {
    loadNextPage();
  }
});
```

스크롤 이벤트는 초당 수십 번 발생한다. 이벤트가 발생할 때마다 이 핸들러 전체가 Call Stack에 올라가서 동기적으로 실행된다. `getBoundingClientRect()`는 강제 리플로우를 유발하고, 그 다음에 `classList.add`로 DOM을 변경하면 또 리플로우가 필요해진다. 이걸 상품 카드 개수만큼 반복한다.

이벤트 루프의 규칙을 떠올려보면, 렌더링은 Microtask Queue가 비고, Task Queue에서 작업을 하나 처리한 다음에 발생한다. 근데 스크롤 핸들러가 Call Stack에서 오래 머물면 브라우저가 렌더링할 타이밍을 잡지 못한다. 16ms(60fps 기준) 안에 핸들러가 끝나야 프레임이 안 밀리는데, DOM을 수십 번 읽고 쓰는 작업이 16ms 안에 끝날 리가 없다.

해결은 두 가지를 조합했다.

```typescript
// 1. 가시성 체크는 IntersectionObserver로 분리
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
    }
  });
}, { threshold: 0.1 });

productCards.forEach(card => observer.observe(card));

// 2. 나머지 작업은 requestAnimationFrame으로 스케줄링
let ticking = false;

window.addEventListener('scroll', () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      updateHeaderStyle();
      checkInfiniteScroll();
      ticking = false;
    });
    ticking = true;
  }
});
```

`IntersectionObserver`는 브라우저가 내부적으로 최적화된 타이밍에 콜백을 호출한다. 매 스크롤 이벤트마다 `getBoundingClientRect()`를 부르는 것과는 차원이 다르다.

`requestAnimationFrame`은 브라우저의 렌더링 사이클에 맞춰 실행된다. 이벤트 루프에서 렌더링 단계 직전에 rAF 콜백이 실행되기 때문에, DOM 변경을 여기서 하면 불필요한 리플로우 없이 다음 프레임에 반영된다. `ticking` 플래그로 프레임당 한 번만 실행되게 막는 것도 중요하다.

이 버그를 잡으면서 "이벤트 루프에서 렌더링이 언제 발생하는가"를 처음으로 진지하게 생각했다. Call Stack이 비고 → Microtask Queue를 비우고 → 렌더링이 필요하면 하고 → Task Queue에서 하나 꺼냄. 이 순서에서 "렌더링이 필요하면"이라는 조건이 핵심이다. Call Stack을 오래 점유하면 렌더링 기회 자체가 사라진다.

## 버그 3: API 응답이 꼬여서 이전 검색 결과가 표시됐다

세 번째 버그가 제일 교훈이 컸다. 검색 페이지에서 사용자가 타이핑할 때마다 API를 호출하는 기능이었다. "React"를 검색하려고 "R", "Re", "Rea", "Reac", "React"를 순서대로 타이핑하면, 각 입력마다 API 호출이 나간다.

문제는 API 응답이 요청 순서대로 오지 않는다는 거다.

```
요청 순서: "R" → "Re" → "Rea" → "Reac" → "React"
응답 순서: "R" → "Rea" → "React" → "Re" → "Reac"
          (네트워크 상황에 따라 뒤죽박죽)
```

마지막으로 화면에 표시되는 건 가장 마지막에 도착한 "Reac"의 결과다. 사용자는 "React"를 검색했는데 "Reac"의 결과가 보이는 거다. 이게 stale data 문제다.

처음에는 이렇게 짰다.

```typescript
const [query, setQuery] = useState('');
const [results, setResults] = useState([]);

useEffect(() => {
  const fetchResults = async () => {
    const data = await searchAPI(query);
    setResults(data);
  };

  if (query) {
    fetchResults();
  }
}, [query]);
```

`searchAPI(query)`는 Promise를 반환한다. Promise의 `.then` (여기서는 `await` 이후 코드)은 Microtask Queue에 들어간다. 네트워크 응답이 올 때마다 해당 Promise가 resolve되고, `setResults(data)`가 Microtask로 실행된다.

문제는 각 `useEffect`의 클로저가 서로 독립적이라는 거다. "Re"의 응답이 "React"의 응답보다 늦게 오면, "React" 결과가 먼저 화면에 뜨고 그 다음에 "Re" 결과가 덮어쓴다. 이벤트 루프는 도착한 순서대로 Microtask를 처리할 뿐, "이건 오래된 요청이니까 무시해야 해"라는 판단을 하지 않는다.

해결 방법은 `useEffect`의 cleanup에서 요청을 무효화하는 거다.

```typescript
useEffect(() => {
  let cancelled = false;

  const fetchResults = async () => {
    const data = await searchAPI(query);
    if (!cancelled) {
      setResults(data);
    }
  };

  if (query) {
    fetchResults();
  }

  return () => {
    cancelled = true;
  };
}, [query]);
```

`query`가 바뀌면 이전 effect의 cleanup이 실행되면서 `cancelled = true`가 된다. 이전 요청의 응답이 뒤늦게 와도 `cancelled`가 `true`이므로 `setResults`가 실행되지 않는다.

더 확실한 방법은 `AbortController`를 쓰는 거다.

```typescript
useEffect(() => {
  const controller = new AbortController();

  const fetchResults = async () => {
    try {
      const data = await searchAPI(query, {
        signal: controller.signal,
      });
      setResults(data);
    } catch (err) {
      if (err instanceof DOMException && err.name === 'AbortError') {
        // 의도된 취소. 무시.
      } else {
        throw err;
      }
    }
  };

  if (query) {
    fetchResults();
  }

  return () => {
    controller.abort();
  };
}, [query]);
```

`AbortController`는 cleanup 실행 시점에서 아예 네트워크 요청 자체를 취소한다. 응답을 무시하는 것보다 한 단계 더 나은 방법이다. 불필요한 네트워크 트래픽도 줄인다.

이 버그는 이벤트 루프를 "비동기 작업의 완료 시점은 예측할 수 없다"는 관점에서 이해해야 풀린다. Promise가 resolve되는 순서는 네트워크 상황에 달려 있고, 이벤트 루프는 도착한 순서대로 처리할 뿐이다. 코드 작성자가 직접 "이 응답은 더 이상 유효하지 않다"는 로직을 넣어야 한다.

## 세 가지 버그에서 배운 것

세 버그의 공통점이 있다. 전부 "코드가 실행되는 시점"에 대한 잘못된 가정 때문에 발생했다.

- 버그 1: `setState` 호출 직후에 상태가 바뀌었을 거라는 가정
- 버그 2: 이벤트 핸들러가 충분히 빠르게 끝날 거라는 가정
- 버그 3: API 응답이 요청 순서대로 올 거라는 가정

이벤트 루프를 공부할 때 `console.log`의 출력 순서를 맞추는 퀴즈가 많이 나온다. "1, 4, 3, 2" 같은 거. 그것도 의미 있지만, 실무에서 이벤트 루프가 중요한 진짜 이유는 **비동기 코드의 실행 시점이 내가 생각한 것과 다를 수 있다**는 걸 알려주기 때문이다.

이벤트 루프의 전체 구조를 암기하는 것보다, 이 세 가지를 기억하는 게 더 실용적이라고 생각한다.

첫째, **상태 업데이트는 즉시 반영되지 않는다.** React든 Vue든 상태 업데이트는 배치된다. 업데이트 직후에 그 값을 읽으면 이전 값을 볼 수 있다. 동기적으로 즉시 반영되어야 하는 플래그는 ref를 쓴다.

둘째, **Call Stack을 오래 점유하면 화면이 멈춘다.** 이벤트 루프가 렌더링할 틈을 주지 않기 때문이다. 무거운 작업은 `requestAnimationFrame`, `requestIdleCallback`, 또는 Web Worker로 분산해야 한다.

셋째, **비동기 작업의 완료 순서는 보장되지 않는다.** Promise의 resolve 순서는 네트워크 상황에 달려 있다. 여러 비동기 작업이 경쟁하는 상황에서는 반드시 "오래된 결과를 무시하는" 로직이 필요하다.

이벤트 루프를 이론으로 아는 건 시작일 뿐이다. 버그를 만나고, 원인을 추적하고, "아, 이게 이벤트 루프 때문이었구나"라고 연결하는 순간이 진짜 이해의 시작이다. 나는 세 번의 버그가 필요했다. 운이 좋으면 이 글을 읽고 한 번 정도는 아낄 수 있을지도 모른다.


"백준 1000번도 어려운데, 카카오 코딩테스트는 어떻게 준비하죠?"

취업을 준비하는 신입 개발자라면 누구나 한 번쯤 이런 고민을 해봤을 겁니다. 포트폴리오도 만들어야 하고, CS 지식도 공부해야 하는데, 코딩테스트까지 준비하려니 막막하기만 합니다. 더욱이 요즘 기업들의 코딩테스트 난이도는 점점 높아지고 있고, "코딩테스트 탈락"이라는 벽에 막혀 면접 기회조차 얻지 못하는 경우가 많습니다.

저도 신입 개발자로 취업을 준비할 때 똑같은 고민을 했습니다. 처음에는 무작정 문제만 풀다가 시간만 낭비했고, 어떤 알고리즘부터 공부해야 할지, 어느 정도 수준까지 준비해야 할지 감을 잡지 못했습니다. 하지만 체계적인 로드맵을 세우고 나니, 3개월 만에 네이버, 카카오, 라인 등 주요 기업의 코딩테스트를 통과할 수 있었습니다.

이 글에서는 제가 직접 경험하고 검증한 신입 개발자를 위한 코딩테스트 준비 전략을 단계별로 공유하겠습니다. 막연한 조언이 아닌, 오늘 당장 실천할 수 있는 구체적인 방법을 담았습니다.

## 1단계: 기초 다지기 (1-2주)

코딩테스트 준비의 첫 단계는 프로그래밍 언어 선택과 기본 문법 숙달입니다. 2025년 기준, 국내 기업 코딩테스트에서 가장 많이 사용되는 언어는 Python(43%), C++(28%), Java(21%) 순입니다.

### 언어 선택 기준

**Python을 추천하는 경우:**

- 알고리즘 구현에 집중하고 싶을 때
- 코딩테스트만을 위한 준비일 때
- 문자열 처리, 리스트 조작이 많은 문제 해결 시

```python
# Python의 간결한 문법 예시
# 배열 회전 (한 줄로 가능)
arr = [[1,2,3], [4,5,6], [7,8,9]]
rotated = list(zip(*arr[::-1]))

# 순열/조합 내장 함수
from itertools import permutations, combinations
perms = list(permutations([1,2,3], 2))
```

**C++을 추천하는 경우:**

- 실행 속도가 중요한 문제 (시간 제한이 빡빡한 경우)
- 삼성 SW 역량테스트 준비 시
- 포인터, 메모리 관리를 직접 다루고 싶을 때

```cpp
// C++ STL 활용 예시
#include <vector>
#include <algorithm>
using namespace std;

vector<int> v = {3, 1, 4, 1, 5};
sort(v.begin(), v.end()); // 정렬
auto it = lower_bound(v.begin(), v.end(), 3); // 이진 탐색

```

### 필수 기본 개념

이 단계에서 반드시 익혀야 할 것들:

1. **입출력 처리**: 대부분의 실수가 여기서 발생합니다

```python
# Python 빠른 입력 (시간 초과 방지)
import sys
input = sys.stdin.readline

# 여러 줄 입력
n = int(input())
arr = [list(map(int, input().split())) for _ in range(n)]
```

2. **시간복잡도 계산**: 문제를 보고 어떤 알고리즘을 써야 할지 판단

- N ≤ 11: O(N!) - 완전탐색, 백트래킹
- N ≤ 25: O(2^N) - 비트마스크, DFS
- N ≤ 100: O(N^3) - 플로이드-워셜
- N ≤ 5,000: O(N^2) - 이중 반복문
- N ≤ 100,000: O(N log N) - 정렬, 이진탐색
- N ≤ 10,000,000: O(N) - 선형 탐색

3. **기본 자료구조 사용법**

```python
# 스택, 큐, 딕셔너리 기본 사용
from collections import deque

stack = []
stack.append(1)  # push
stack.pop()      # pop

queue = deque()
queue.append(1)  # enqueue
queue.popleft()  # dequeue

hash_map = {}
hash_map['key'] = 'value'
```

**추천 문제 (백준 기준):**

- 2558: A+B - 2 (입출력 연습)
- 10818: 최소, 최대 (배열 기본)
- 2920: 음계 (배열 응용)
- 10828: 스택 (자료구조 구현)

## 2단계: 핵심 알고리즘 마스터 (4-6주)

이제 본격적으로 코딩테스트에 자주 출제되는 알고리즘을 학습합니다. 2025년 주요 기업 코딩테스트 출제 빈도 분석 결과, 다음 순서로 학습하는 것이 가장 효율적입니다.

### 주차별 학습 계획

**1주차: 구현 & 그리디**

실제 코딩테스트의 30%가 구현 문제입니다. 복잡한 알고리즘보다는 문제를 정확히 이해하고 구현하는 능력을 테스트합니다.

```python
# 그리디 예제: 거스름돈 문제
def min_coins(change):
    coins = [500, 100, 50, 10]
    count = 0

    for coin in coins:
        count += change // coin
        change %= coin

    return count

# 시뮬레이션 예제: 로봇 청소기
dx = [-1, 0, 1, 0]  # 북, 동, 남, 서
dy = [0, 1, 0, -1]

def clean_robot(x, y, direction, room):
    cleaned = 1

    while True:
        turned = False
        for _ in range(4):
            direction = (direction - 1) % 4
            nx = x + dx[direction]
            ny = y + dy[direction]

            if room[nx][ny] == 0:  # 청소 가능
                x, y = nx, ny
                room[x][y] = 2
                cleaned += 1
                turned = True
                break

        if not turned:
            # 후진 로직
            break

    return cleaned
```

**추천 문제:**

- 백준 14503: 로봇 청소기
- 프로그래머스: 문자열 압축 (2020 카카오)

**2주차: DFS/BFS**

그래프 탐색은 코딩테스트의 필수입니다. 특히 BFS는 최단 거리 문제에서 빠지지 않습니다.

```python
from collections import deque

# BFS 기본 템플릿 (최단 거리)
def bfs(graph, start):
    visited = [False] * len(graph)
    queue = deque([(start, 0)])  # (노드, 거리)
    visited[start] = True

    while queue:
        node, dist = queue.popleft()

        for next_node in graph[node]:
            if not visited[next_node]:
                visited[next_node] = True
                queue.append((next_node, dist + 1))

    return visited

# DFS 기본 템플릿 (경로 탐색)
def dfs(graph, node, visited, path):
    visited[node] = True
    path.append(node)

    for next_node in graph[node]:
        if not visited[next_node]:
            if dfs(graph, next_node, visited, path):
                return True

    path.pop()  # 백트래킹
    return False

# 2D 그리드 BFS (미로 탐색)
def grid_bfs(grid, start_x, start_y):
    n, m = len(grid), len(grid[0])
    visited = [[False] * m for _ in range(n)]
    queue = deque([(start_x, start_y, 0)])
    visited[start_x][start_y] = True

    dx = [-1, 1, 0, 0]
    dy = [0, 0, -1, 1]

    while queue:
        x, y, dist = queue.popleft()

        if grid[x][y] == 'E':  # 목적지 도착
            return dist

        for i in range(4):
            nx, ny = x + dx[i], y + dy[i]

            if 0 <= nx < n and 0 <= ny < m:
                if not visited[nx][ny] and grid[nx][ny] != '#':
                    visited[nx][ny] = True
                    queue.append((nx, ny, dist + 1))

    return -1
```

**추천 문제:**

- 백준 2178: 미로 탐색 (BFS 기본)
- 백준 7576: 토마토 (다중 시작점 BFS)
- 백준 1987: 알파벳 (DFS + 백트래킹)

**3-4주차: DP (동적 계획법)**

DP는 신입에게 가장 어려운 주제이지만, 패턴만 익히면 해결할 수 있습니다.

```python
# DP 기본 패턴 1: 피보나치 (Bottom-up)
def fibonacci(n):
    if n <= 1:
        return n

    dp = [0] * (n + 1)
    dp[1] = 1

    for i in range(2, n + 1):
        dp[i] = dp[i-1] + dp[i-2]

    return dp[n]

# DP 패턴 2: 배낭 문제 (Knapsack)
def knapsack(weights, values, capacity):
    n = len(weights)
    dp = [[0] * (capacity + 1) for _ in range(n + 1)]

    for i in range(1, n + 1):
        for w in range(1, capacity + 1):
            if weights[i-1] <= w:
                # 현재 물건을 넣는 경우 vs 안 넣는 경우
                dp[i][w] = max(
                    values[i-1] + dp[i-1][w - weights[i-1]],
                    dp[i-1][w]
                )
            else:
                dp[i][w] = dp[i-1][w]

    return dp[n][capacity]

# DP 패턴 3: LIS (최장 증가 부분 수열)
def lis(arr):
    n = len(arr)
    dp = [1] * n

    for i in range(1, n):
        for j in range(i):
            if arr[j] < arr[i]:
                dp[i] = max(dp[i], dp[j] + 1)

    return max(dp)
```

**DP 문제 접근법:**

1. 작은 문제로 분해 (부분 문제 정의)
2. 점화식 세우기
3. 초기값 설정
4. Bottom-up으로 계산

**추천 문제:**

- 백준 1463: 1로 만들기
- 백준 9251: LCS (최장 공통 부분 수열)
- 백준 12865: 평범한 배낭

**5-6주차: 이진탐색 & 투 포인터**

```python
# 이진탐색 기본 템플릿
def binary_search(arr, target):
    left, right = 0, len(arr) - 1

    while left <= right:
        mid = (left + right) // 2

        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1

    return -1

# 파라메트릭 서치 (최적값 찾기)
def parametric_search(arr, target):
    left, right = 1, max(arr)
    result = 0

    while left <= right:
        mid = (left + right) // 2

        if can_make(arr, mid, target):
            result = mid
            left = mid + 1  # 더 큰 값 시도
        else:
            right = mid - 1

    return result

# 투 포인터 기본 템플릿
def two_pointers(arr, target):
    left, right = 0, len(arr) - 1
    result = []

    while left < right:
        current = arr[left] + arr[right]

        if current == target:
            result.append((left, right))
            left += 1
            right -= 1
        elif current < target:
            left += 1
        else:
            right -= 1

    return result
```

**추천 문제:**

- 백준 1654: 랜선 자르기 (파라메트릭 서치)
- 백준 2470: 두 용액 (투 포인터)

## 3단계: 실전 문제 풀이 (2-4주)

알고리즘 학습이 끝났다면 이제 실전 감각을 키울 차례입니다. 실제 기업 코딩테스트와 유사한 환경에서 연습해야 합니다.

### 일일 학습 루틴

09:00 - 09:30 | 어제 푼 문제 복습 (코드 리뷰)
09:30 - 11:00 | 새로운 문제 2개 풀이 (중급)
11:00 - 12:00 | 틀린 문제 다시 풀기
14:00 - 16:00 | 고급 문제 1개 도전
16:00 - 17:00 | 다른 사람 풀이 분석

### 기업별 출제 경향 (2025년 기준)

**네이버:**

- 구현 + 알고리즘 조합 (난이도 중상)
- 효율성 테스트 중시 (시간 복잡도 체크)
- 실제 서비스 시나리오 문제 출제

**카카오:**

- 문제 해석이 어려운 시뮬레이션 문제
- 문자열 처리, 정규표현식 활용
- Level 3 이상 1-2문제 포함

**삼성:**

- 시뮬레이션 + 구현 중심
- 긴 문제 지문 (이해력 테스트)
- DFS/BFS 필수

**라인:**

- 카카오와 유사하지만 난이도 약간 낮음
- 자료구조 활용 문제 많음

### 모의 코딩테스트 활용법

**추천 플랫폼:**

- 프로그래머스: 기업별 기출문제 (월 2회 모의고사)
- 백준: 삼성 SW 역량테스트 기출
- LeetCode: 해외 기업 준비 시

**실전 시뮬레이션 방법:**

1. 실제 시험 시간 맞춰서 풀기 (2-3시간)
2. 검색, 참고자료 금지
3. 디버깅 도구 최소화
4. 종이에 손으로 먼저 풀어보기

```python
# 실전 팁: 템플릿 미리 준비
# main 함수 기본 구조
def solution():
    import sys
    input = sys.stdin.readline

    # 입력 받기
    n, m = map(int, input().split())
    arr = [list(map(int, input().split())) for _ in range(n)]

    # 로직 구현
    answer = solve(n, m, arr)

    # 출력
    print(answer)

# 자주 쓰는 함수 템플릿 모음
def gcd(a, b):  # 최대공약수
    return a if b == 0 else gcd(b, a % b)

def lcm(a, b):  # 최소공배수
    return a * b // gcd(a, b)

def is_prime(n):  # 소수 판별
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True
```

### 자주 하는 실수와 예방법

1. **시간 초과**

```python
# Bad: O(N^2) - 이중 반복문
for i in range(n):
    for j in range(n):
        if arr[i] == arr[j]:
            count += 1

# Good: O(N) - 해시맵 사용
from collections import Counter
counter = Counter(arr)
count = sum(v * (v-1) // 2 for v in counter.values())
```

2. **인덱스 에러**

```python
# 항상 범위 체크
if 0 <= nx < n and 0 <= ny < m:
    # 안전한 접근
    value = grid[nx][ny]
```

3. **잘못된 자료구조 선택**

- 삽입/삭제 많음 → deque, set
- 검색 많음 → dict, set
- 순서 유지 + 정렬 → list + sort

## 4단계: 최종 점검 (1주)

시험 1주일 전에는 새로운 문제보다 복습에 집중합니다.

### D-7 체크리스트

**알고리즘 복습:**

- [ ] DFS/BFS 템플릿 암기
- [ ] DP 점화식 세우기 연습
- [ ] 이진탐색 구현 (외우기)
- [ ] 정렬 알고리즘별 시간복잡도

**실수 방지:**

- [ ] 입출력 형식 다시 확인
- [ ] 시간복잡도 계산 연습
- [ ] Edge case 확인 (N=1, 최대값, 0 등)

**환경 설정:**

- [ ] IDE 단축키 숙달 (디버깅, 실행)
- [ ] 자주 쓰는 라이브러리 import 확인
- [ ] 코드 템플릿 정리

### 시험 당일 전략

1. 문제 전체 훑어보기 (5분)

   - 쉬운 문제부터 파악
   - 배점 확인

2. 쉬운 문제부터 해결 (60분)

   - 구현 문제 우선
   - 빠른 정답 확보

3. 중급 문제 도전 (60분)

   - 부분 점수라도 획득
   - 시간 배분 중요

4. 남은 시간 (30분)
   - 어려운 문제 부분 풀이
   - 이미 푼 문제 재검토

**부분 점수 전략:**

```python
# 완전 탐색으로 작은 케이스 통과
def solve_brute_force(n, arr):
    if n <= 100:  # 작은 케이스만
        # O(N^3) 완전 탐색
        return brute_force(arr)
    else:
        # 최적화된 알고리즘
        return optimized(arr)
```

## 실전 꿀팁 모음

### 디버깅 노하우

```python
# 1. 중간 결과 출력 (제출 전 삭제)
print(f"DEBUG: current state = {state}")

# 2. assert로 검증
assert len(arr) > 0, "배열이 비어있습니다"

# 3. 작은 테스트케이스 먼저
def test():
    assert solution([1,2,3]) == 6
    assert solution([]) == 0
    print("All tests passed!")
```

### 시간 단축 팁

```python
# 1. 빠른 입력
import sys
input = sys.stdin.readline

# 2. PyPy3 선택 (Python보다 빠름)

# 3. 불필요한 연산 제거
# Bad
if condition == True:

# Good
if condition:
```

### 추천 학습 자료

**무료 자료:**

- 백준 문제집: "코딩테스트 대비 문제집"
- 프로그래머스: 고득점 Kit
- YouTube: "동빈나 코딩테스트" 채널

**유료 강의 (선택):**

- 인프런: "이것이 취업을 위한 코딩 테스트다" (30,000원)
- 코드잇: 알고리즘 트랙 (월 25,000원)

**커뮤니티:**

- 백준 질문 게시판
- 프로그래머스 디스커스
- 알고리즘 카카오톡 오픈채팅방

## 결론: 지금 바로 시작하기

코딩테스트 준비는 단거리 달리기가 아닌 마라톤입니다. 하지만 올바른 방향으로 꾸준히 노력한다면, 3개월이면 충분히 주요 기업의 코딩테스트를 통과할 수 있습니다.

**오늘부터 실천할 액션 플랜:**

1. **이번 주 (1주차):**

   - 사용할 언어 선택 (Python 추천)
   - 백준 알고리즘 분류에서 "구현" 10문제 풀기
   - 입출력 템플릿 정리

2. **다음 주 (2주차):**

   - DFS/BFS 개념 학습 (유튜브 1시간)
   - 관련 문제 15개 풀기
   - 틀린 문제는 다음날 다시 풀기

3. **한 달 후:**
   - 프로그래머스 Level 2 문제 30개 돌파
   - 주 1회 모의 코딩테스트 참여
   - 알고리즘 스터디 참여 (선택)

기억하세요. 코딩테스트는 재능이 아닌 훈련의 영역입니다. 매일 2시간씩 투자한다면, 반드시 원하는 회사의 합격 통지서를 받을 수 있습니다.

마지막으로, 코딩테스트 준비 중 가장 중요한 것은 **포기하지 않는 것**입니다. 처음에는 Bronze 문제도 어렵겠지만, 100문제를 풀고 나면 Silver 문제가 쉬워지고, 300문제를 풀면 Gold 문제도 해결할 수 있습니다.

여러분의 취업 성공을 진심으로 응원합니다. 화이팅!



서류 검토할 때 포트폴리오를 30초 본다. 그 30초 안에 뭘 보는지 이야기해보려 한다. 지난 1년간 우리 팀 채용에 참여하면서 프론트엔드 신입 지원자 이력서를 60개 넘게 봤는데, 그중 포트폴리오 링크를 눌러서 1분 이상 머문 건 10개도 안 됐다.

왜 30초냐면, 현실적으로 그 이상 볼 시간이 없다. 서류 검토는 보통 업무 사이사이에 한다. 스프린트 플래닝 끝나고 점심 전 40분, 배포 대기하는 동안 20분. 그 시간에 이력서 5~6개를 훑어야 하니까, 포트폴리오 하나에 할애할 수 있는 시간은 진짜 30초에서 길어야 1분이다. 그래서 첫인상이 전부다.

## README가 없으면 그냥 닫는다

GitHub 링크를 눌렀을 때 제일 먼저 보이는 게 README다. 그런데 놀랍게도 지원자 절반 이상이 README를 안 쓴다. Create React App이 자동 생성한 기본 README가 그대로 있거나, 아예 빈 파일인 경우가 많다.

이건 식당으로 치면 간판 없이 문만 열어놓은 거랑 비슷하다. 안에 음식이 아무리 맛있어도, 뭐 파는 집인지 모르면 들어가기 꺼려진다. README도 마찬가지다. 이 프로젝트가 뭔지 30초 안에 파악이 안 되면, 코드를 뜯어볼 이유가 없다.

README에 뭘 써야 하냐고 물으면, 세 가지만 있으면 된다.

**프로젝트 한 줄 설명.** "쇼핑몰 클론"이 아니라 "실시간 재고 반영이 되는 의류 쇼핑몰"처럼 이 프로젝트의 핵심이 뭔지 한 문장으로. 한 줄이면 된다. 길게 쓸 필요 없다.

**기술 선택 이유.** React를 썼으면 왜 React인지. "많이 써서"는 이유가 아니다. "컴포넌트 단위로 UI를 조합하고 싶었고, 상품 목록처럼 반복되는 패턴이 많아서 재사용성이 중요했다" 정도면 충분하다. 상태 관리 라이브러리를 선택한 이유, CSS 방법론을 고른 이유 같은 것도 마찬가지다. 이걸 쓸 수 있다는 건 기술을 의식적으로 선택했다는 뜻이고, 그건 면접관 입장에서 꽤 큰 신호다.

**본인 기여도.** 팀 프로젝트라면 이게 특히 중요하다. "프론트엔드 전체 담당"이라고만 쓰면 뭘 했는지 알 수가 없다. "상품 검색 페이지 구현 (debounce 적용, 검색어 하이라이팅), 장바구니 상태 관리 (Zustand), 반응형 레이아웃" 이런 식으로 구체적으로 적혀 있으면 바로 해당 코드를 찾아서 볼 수 있다.

작년에 본 지원자 중에 README를 거의 기술 블로그 수준으로 쓴 사람이 있었다. 프로젝트 설명, 기술 스택 선정 이유, 아키텍처 다이어그램, 트러블슈팅 과정까지 정리돼 있었다. 그 README만 읽고도 이 사람이 어떤 사고방식으로 개발하는지 감이 왔다. 코드를 뜯어보기도 전에 이미 면접 보고 싶다는 생각이 들었다.

## 클론 코딩이 나쁜 건 아닌데

이건 좀 민감한 주제다. 신입 지원자 포트폴리오의 70~80%가 클론 코딩이다. 넷플릭스 클론, 인스타그램 클론, 당근마켓 클론. 클론 자체가 나쁜 건 아니다. 실제로 잘 만들어진 서비스를 따라 만들면서 배우는 게 분명히 있다.

문제는 "따라 만들기"에서 끝나는 경우다.

유튜브 강의를 보면서 똑같이 따라 치고, 강의 코드를 그대로 가져다 쓰고, 거기에 자기만의 생각이 하나도 안 들어가 있으면 — 그건 면접관 입장에서 볼 게 없다. 왜냐하면 코드를 짠 건 그 사람이 아니라 강의를 만든 사람이니까.

클론이라도 차별화되는 순간이 있다. 넷플릭스 클론을 만들면서 "무한 스크롤 구현할 때 Intersection Observer를 써봤는데, 이미지가 많아서 성능이 안 나왔다. 그래서 가상 스크롤을 직접 구현해봤다"라는 과정이 README에 적혀 있으면 이건 클론이 아니라 학습 프로젝트가 된다. "왜 이 기술을 썼는지", "어떤 문제를 만났고 어떻게 해결했는지"가 있냐 없냐의 차이다.

반면에 실제 문제를 해결한 프로젝트는 그 자체로 눈에 띈다. 규모가 작아도 상관없다. 내가 기억나는 건 대학교 동아리 출석 관리 앱을 만든 지원자였다. 기능 자체는 단순했다. QR 코드 출석 체크, 출석률 통계, 관리자 페이지 정도. 근데 README에 이렇게 적혀 있었다.

> "기존에 구글 설문지로 출석을 받았는데 대리 출석이 가능하고, 통계를 수동으로 집계해야 했습니다. QR 코드에 위치 정보를 포함시켜 반경 100m 이내에서만 체크인이 되도록 했고, 주차별 출석률이 자동 집계되도록 만들었습니다."

이 한 단락에 문제 정의, 해결 방법, 구체적 구현이 다 들어가 있다. 이런 게 좋은 포트폴리오다. 대단한 기술을 쓸 필요가 없다. 실제 문제를 발견하고, 그걸 코드로 해결한 경험 자체가 가치 있다.

## GitHub 잔디는 안 본다

솔직한 얘기를 하면, 잔디를 보는 면접관도 물론 있을 거다. 근데 나는 잔디를 거의 안 본다. 왜냐하면 잔디는 조작이 너무 쉽다. 매일 빈 커밋 하나씩 찍어도 잔디는 초록색으로 채워진다.

대신 커밋 메시지를 본다.

커밋 히스토리를 3~4개만 훑어봐도 이 사람의 개발 습관이 보인다. "fix", "update", "asdf", "ㅋㅋ" 같은 커밋 메시지가 줄줄이 있으면 솔직히 인상이 좋지 않다. 반대로 "feat: 상품 검색 debounce 적용 (300ms)", "fix: 장바구니 수량 변경 시 총 금액 미반영 버그 수정", "refactor: useCart 훅에서 계산 로직 분리" 같은 메시지가 있으면 이 사람이 작업 단위를 어떻게 나누고, 변경 사항을 어떻게 설명하는지가 바로 느껴진다.

커밋 메시지가 깔끔한 사람은 실무에서 PR 설명도 잘 쓰고, 이슈 트래킹도 잘 한다. 그게 경험상 꽤 정확한 상관관계다. 개발 실력이랑 직접적인 관계가 있다고까지는 안 하겠지만, 협업 역량의 지표로는 꽤 신뢰할 만하다.

## 배포 안 된 프로젝트

이것도 많이 보이는 패턴이다. GitHub 링크만 있고, 배포 링크가 없는 경우.

코드만 보면 되는 거 아니냐고 생각할 수 있는데, 면접관 입장에서는 배포된 프로젝트를 더 신뢰한다. 이유가 몇 가지 있다. 첫째, 배포까지 해봤다는 건 빌드 에러, 환경 변수 설정, CORS 같은 실전 이슈를 한 번이라도 겪었다는 뜻이다. 둘째, 돌아가는 화면을 직접 클릭해볼 수 있으면 코드를 읽기 전에 전체적인 맥락을 빠르게 파악할 수 있다. 그 30초 안에 "아 이런 서비스구나"를 이해하는 데 도움이 된다.

Vercel이나 Netlify를 쓰면 Next.js나 React 프로젝트 배포하는 데 10분이면 된다. GitHub repo 연결하고 몇 번 클릭하면 끝이다. 이 10분을 투자 안 한 건 아쉽다.

한 가지 주의할 게 있다. 배포해놓고 서버가 죽어있거나, API 키가 만료돼서 빈 화면만 뜨는 경우. 이건 안 한 것보다 인상이 더 나쁘다. 배포 링크를 넣을 거면, 주기적으로 한 번씩 접속해서 살아있는지 확인하자.

## 1개의 완성 > 5개의 미완성

포트폴리오에 프로젝트를 5~6개 넣어놓은 지원자가 있다. 하나씩 눌러보면 README가 없거나, 커밋이 3개뿐이거나, 기능이 반만 구현돼 있다. 이러면 오히려 역효과다.

"많이 해봤다"를 보여주고 싶은 마음은 이해한다. 근데 면접관이 보는 건 양이 아니라 깊이다. 하나의 프로젝트를 제대로 끝냈는지. 에러 처리는 했는지. 반응형은 잡았는지. edge case는 고려했는지. 그런 게 보고 싶다.

내가 실제로 높게 평가했던 지원자는 포트폴리오 프로젝트가 딱 2개였다. 하나는 팀 프로젝트, 하나는 개인 프로젝트. 둘 다 README가 탄탄했고, 배포가 돼 있었고, 커밋 히스토리가 깔끔했다. 개인 프로젝트는 할 일 관리 앱이었는데 — 네, 투두리스트다. 근데 이게 범상치 않았다. 드래그 앤 드롭으로 순서 변경, 카테고리별 필터링, 로컬 스토리지 동기화, 그리고 키보드만으로 모든 기능을 사용할 수 있는 접근성 처리까지 돼 있었다. README에는 "기존 투두 앱들을 써보면서 불편했던 점들을 개선하는 방향으로 만들었다"고 적혀 있었고, 각 기능별로 왜 그렇게 구현했는지 설명이 있었다.

투두리스트를 이렇게까지 깊이 만들 수 있다는 걸 보여준 거다. 주제가 뻔해도 상관없다. 깊이가 보이면 된다.

## 이력서의 기술 스택 나열

이건 포트폴리오가 아니라 이력서 얘기인데, 같이 보는 거니까 짚고 넘어간다.

"React, TypeScript, Next.js, Redux, Styled-components, Jest, Storybook, GraphQL, Docker..."

이렇게 기술 스택을 쭉 나열해놓은 이력서가 정말 많다. 이걸 보면 드는 생각은 "이 기술들을 진짜 다 쓸 줄 아나?"다. 신입인데 이 목록이 전부 가능하다? 현실적으로 어렵다. 그래서 스택 나열 자체가 오히려 신뢰를 떨어뜨리는 경우가 있다.

차라리 이렇게 쓰는 게 낫다.

> "상품 검색 페이지에서 입력할 때마다 API를 호출하던 구조를 debounce로 개선해서 API 호출 횟수를 80% 줄였습니다."

> "이미지 lazy loading과 WebP 변환을 적용해서 상품 목록 페이지 LCP를 3.2초에서 1.1초로 줄였습니다."

기술 이름이 아니라, 그 기술로 뭘 했는지를 쓰는 거다. 숫자가 들어가면 더 좋다. 면접관은 "React를 할 줄 안다"보다 "React로 이런 문제를 이렇게 해결했다"에 훨씬 더 관심이 있다. 면접에서도 이런 성과 중심으로 이력서를 쓴 사람한테는 자연스럽게 "그거 어떻게 측정했어요?" "다른 방법은 고려 안 했어요?" 같은 깊이 있는 질문을 하게 된다. 대화가 풍성해진다.

기술 스택을 아예 안 쓰라는 건 아니다. 스택은 간단하게 정리하되, 각 프로젝트 설명에서 "이 기술로 이런 걸 했다"를 보여주는 구조가 이상적이다.

## 눈에 띄었던 포트폴리오

지금까지 봤던 것 중에 특히 기억에 남는 케이스 두 개를 익명으로 공유한다.

**A 지원자.** 이 사람은 포트폴리오 사이트 자체가 인상적이었다. Next.js로 만든 개인 사이트였는데, 프로젝트 소개가 단순 나열이 아니라 각 프로젝트마다 "문제 → 시도 → 결과" 흐름으로 정리돼 있었다. 그리고 프로젝트 페이지 하단에 "아쉬운 점과 다음에 개선할 것"이 적혀 있었다. "상태 관리를 Context API로 했는데 리렌더링 이슈가 있어서 다음에는 Zustand를 써볼 예정"이라는 식으로. 이게 좋았던 건, 이 사람이 자기 코드를 객관적으로 볼 줄 안다는 걸 보여줬기 때문이다. 신입한테 완벽한 코드를 기대하는 사람은 없다. 대신 뭐가 부족한지 아는 사람을 원한다.

**B 지원자.** 프로젝트가 하나였다. 동네 소규모 카페의 주문 관리 시스템. README 첫 줄이 "부모님이 운영하는 카페에서 종이로 주문을 받는 게 비효율적이라 만들었습니다"였다. 기술적으로 대단한 건 아니었다. 근데 이 사람은 실제 사용자(부모님과 카페 직원)의 피드백을 반영한 커밋 히스토리가 있었다. "사장님이 글씨가 작다고 해서 폰트 사이즈 조정", "주문 취소 기능 요청으로 추가 구현" 같은. 실제 사용자가 있는 프로젝트는 그 자체가 강력한 차별점이다. 사용자의 요구사항을 듣고 반영하는 경험은 실무에서 매일 하는 일이니까.

## 30초를 넘기는 법

길게 썼지만 핵심은 단순하다. 면접관은 "이 사람이 우리 팀에 들어오면 같이 일할 수 있겠다"를 판단하려는 거다. 코드를 잘 짜는지도 보지만, 그보다 자기가 뭘 했는지 설명할 수 있는 사람인지, 문제를 인식하고 해결하려고 시도한 사람인지를 본다.

README를 쓰자. 커밋 메시지를 신경 쓰자. 하나라도 제대로 배포하자. 기술 나열 대신 성과를 쓰자.

포트폴리오에 들이는 시간 중 절반은 코드를 짜는 데, 나머지 절반은 그 코드를 설명하는 데 쓰는 게 맞다. 아무리 좋은 코드를 짜도, 그걸 전달하지 못하면 30초 안에 탭이 닫힌다.


2025년 7월 어느 월요일 오전, PM이 슬랙에 메시지를 올렸다. "우리 사이트 왜 이렇게 느려요? 경쟁사는 바로 뜨는데." 그 메시지 아래에 경쟁사 URL이 덩그러니 붙어 있었다. 나는 그날 오후 우리 랜딩 페이지를 Lighthouse로 돌렸고, 숫자를 보고 의자에서 미끄러질 뻔했다.

Performance 점수 42점. LCP 3.2초. CLS 0.28.

우리 팀은 5명이었고, 프론트엔드는 나 포함 2명이었다. 전담으로 성능 최적화만 할 여유 같은 건 없었다. 스프린트 사이사이에 시간을 쪼개서, 약 3주에 걸쳐 LCP를 0.9초까지 끌어내렸다. 그 과정을 기록해둔다.

## 현실 파악: 느린 건 알겠는데 뭐가 느린 거야

성능 최적화에서 제일 위험한 건 "감으로" 시작하는 거다. 나도 처음에 "번들이 크겠지" 하고 webpack-bundle-analyzer부터 켰다. 결과적으로 그것도 문제긴 했는데, **가장 큰 문제는 거기가 아니었다**.

Lighthouse의 LCP 항목을 클릭하면 어떤 element가 LCP로 잡혔는지 보여준다. 우리 랜딩 페이지의 LCP element는 hero 섹션의 배경 이미지였다. 2400x1600 사이즈의 PNG 파일, 1.8MB.

```bash
# 이미지 크기 확인
curl -sI https://example.com/hero-bg.png | grep content-length
# content-length: 1887436
```

1.8MB짜리 PNG를 아무 최적화 없이 CSS background-image로 불러오고 있었다. `loading="lazy"`도 안 먹히는 CSS 배경이미지라서, 브라우저가 HTML 파싱하다가 CSS 만나고, CSS 파싱하다가 이미지 URL 발견하고, 그제서야 이미지를 요청하는 구조였다. 이미지 다운로드 시작까지만 해도 이미 1초가 넘게 걸리고 있었다.

DevTools의 Network 탭에서 Waterfall을 보면 이게 명확하게 보인다. HTML → CSS → 이미지 순서로 직렬 로딩되고 있었다.

## 1차 시도: hero 이미지 최적화

가장 임팩트가 클 게 뻔한 곳부터 건드렸다.

우리 프로젝트는 Next.js 기반이었으니까 `next/image`를 쓸 수 있었다. CSS background-image를 걷어내고 `next/image`로 교체했다.

```tsx
// Before: CSS background-image
<section className="hero" style={{ backgroundImage: 'url(/hero-bg.png)' }}>
  <h1>서비스 소개</h1>
</section>

// After: next/image + priority
import Image from 'next/image';

<section className="hero">
  <Image
    src="/hero-bg.png"
    alt="서비스 메인 배경"
    fill
    priority
    sizes="100vw"
    style={{ objectFit: 'cover' }}
  />
  <h1>서비스 소개</h1>
</section>
```

`priority` prop이 핵심이다. 이걸 붙이면 Next.js가 자동으로 `<link rel="preload">`를 HTML `<head>`에 삽입한다. 브라우저가 CSS를 기다리지 않고 바로 이미지를 요청할 수 있게 된다.

여기에 추가로 이미지 포맷을 WebP로 변환했다. Next.js의 Image Optimization을 쓰면 자동으로 해주지만, 우리는 CDN에서 직접 서빙하고 있어서 수동으로 변환했다.

```bash
# cwebp로 변환 (Google에서 제공하는 CLI 도구)
cwebp -q 80 hero-bg.png -o hero-bg.webp

# 결과 확인
ls -la hero-bg.*
# hero-bg.png  1.8MB
# hero-bg.webp  187KB
```

1.8MB에서 187KB로. 약 90% 감소. 이것만으로 LCP가 3.2초에서 1.9초로 떨어졌다.

**1차 Lighthouse 결과: 42점 → 61점, LCP 3.2s → 1.9s**

## 폰트 삽질기

이미지 다음으로 눈에 들어온 건 폰트였다. 우리는 Pretendard를 쓰고 있었는데, woff2 파일 4개를 로드하고 있었다. Regular, Medium, SemiBold, Bold. 합쳐서 약 400KB.

처음에는 `font-display: swap`으로 설정해뒀었다. FOUT(Flash of Unstyled Text)가 발생하긴 하지만, 텍스트는 바로 보이니까 LCP에 유리할 거라고 생각했다.

그런데 문제가 있었다. hero 섹션의 `<h1>` 텍스트가 LCP element로 잡히는 경우가 있었다. 이미지를 최적화하고 나니까, 이미지보다 `<h1>`이 더 늦게 "최종 렌더링"되는 케이스가 생긴 거다. `font-display: swap`이면 시스템 폰트로 먼저 렌더링하고 웹폰트가 로드되면 교체하는데, 이 교체 순간이 LCP로 잡힌다.

`font-display: optional`로 바꿨다.

```css
@font-face {
  font-family: 'Pretendard';
  font-weight: 400;
  font-display: optional;
  src: url('/fonts/Pretendard-Regular.subset.woff2') format('woff2');
  unicode-range: U+AC00-D7A3, U+0020-007E;
}
```

`optional`은 폰트가 이미 캐시에 있으면 사용하고, 없으면 시스템 폰트로 그냥 간다. 교체가 일어나지 않으니 layout shift도 없고, LCP 재계산도 없다. 첫 방문 유저에게는 시스템 폰트가 보이지만, 두 번째 방문부터는 웹폰트가 적용된다.

디자이너한테 얘기했더니 처음엔 난색을 표했다. "첫 방문 유저에게 Apple SD Gothic이 보인다고요?" 근데 LCP 수치를 보여주니까 납득했다. 사실 대부분의 유저는 차이를 못 느낀다. Pretendard 자체가 시스템 폰트와 비슷한 느낌으로 디자인된 폰트이기도 하고.

추가로 `unicode-range`를 지정해서 한글과 기본 ASCII만 포함하는 subset 폰트를 만들었다. 원본 400KB에서 subset 후 95KB로 줄었다.

## preload의 함정

여기서 욕심이 났다. "preload를 더 걸면 더 빨라지지 않을까?"

```html

<link rel="preload" href="/fonts/Pretendard-Regular.subset.woff2" as="font" crossorigin>
<link rel="preload" href="/fonts/Pretendard-Bold.subset.woff2" as="font" crossorigin>
<link rel="preload" href="/hero-bg.webp" as="image">
<link rel="preload" href="/api/main-data" as="fetch" crossorigin>
<link rel="preload" href="/chunks/landing-abc123.js" as="script">
```

결과? **오히려 느려졌다.** LCP가 1.6초에서 1.8초로 올라갔다.

이유는 간단했다. preload가 너무 많으면 브라우저의 네트워크 대역폭을 놓고 리소스끼리 경쟁한다. 모든 걸 "높은 우선순위"로 올려놓으면, 결국 아무것도 높은 우선순위가 아닌 것과 같다. web.dev에서도 이 점을 명확하게 경고하고 있다: preload는 현재 페이지에서 반드시 필요한 리소스에만 써야 한다.

hero 이미지 preload만 남기고 나머지를 전부 제거했다. 폰트는 `font-display: optional`이니까 preload할 필요가 없다. 안 와도 괜찮은 리소스를 preload하는 건 모순이다.

## 번들 사이즈 줄이기

`next build`를 하고 나오는 빌드 결과를 살펴봤다.

```bash
npx next build

Route (app)                    Size     First Load JS
┌ ○ /                          142 kB   387 kB
├ ○ /about                     28 kB    273 kB
├ ○ /dashboard                 89 kB    334 kB
└ ○ /settings                  45 kB    290 kB

First Load JS shared by all routes: 245 kB
```

공통 번들이 245KB. 이 안에 뭐가 들어있는지 까봐야 했다.

```bash
# bundle analyzer 실행
ANALYZE=true npx next build
```

범인이 보였다. `core-js` polyfill이 공통 번들의 약 30%를 차지하고 있었다. 우리 서비스의 타겟 브라우저는 Chrome 90+, Safari 15+, Edge 90+ 정도였는데, IE 지원용 polyfill이 잔뜩 들어가 있었다.

원인은 `.browserslistrc` 파일이었다.

```
# 기존 설정 (누가 이렇게 해둔 거야...)
> 0.5%
last 2 versions
not dead
```

이 설정이면 전 세계 사용률 0.5% 이상인 브라우저를 전부 지원하게 된다. Samsung Internet 구버전이나 UC Browser 같은 것까지 포함된다.

```
# 수정 후
last 2 Chrome versions
last 2 Firefox versions
last 2 Safari versions
last 2 Edge versions
not dead
```

그리고 `next.config.js`에서 불필요한 polyfill import를 제거했다.

```js
// next.config.js
module.exports = {
  experimental: {
    optimizePackageImports: ['lodash-es', '@headlessui/react'],
  },
};
```

추가로 `lodash` 전체를 import하고 있는 파일이 3개 있었다. `import _ from 'lodash'` 대신 개별 함수만 가져오도록 바꿨다.

```tsx
// Before
import _ from 'lodash';
const sorted = _.sortBy(items, 'date');
const grouped = _.groupBy(items, 'category');

// After
import sortBy from 'lodash-es/sortBy';
import groupBy from 'lodash-es/groupBy';
const sorted = sortBy(items, 'date');
const grouped = groupBy(items, 'category');
```

공통 번들이 245KB에서 156KB로 줄었다.

**2차 Lighthouse 결과: 61점 → 78점, LCP 1.9s → 1.3s**

## Code Splitting: 안 보이는 건 나중에

랜딩 페이지 하단에 FAQ 아코디언, 고객 후기 캐러셀, 문의 폼이 있었다. 이것들은 스크롤하지 않으면 보이지 않는다. 그런데 초기 번들에 전부 포함되어 있었다.

Next.js의 `dynamic`을 썼다.

```tsx
import dynamic from 'next/dynamic';

const FAQ = dynamic(() => import('@/components/landing/FAQ'), {
  loading: () => <div className="faq-skeleton" />,
});

const Testimonials = dynamic(() => import('@/components/landing/Testimonials'), {
  loading: () => <div className="testimonials-skeleton" />,
});

const ContactForm = dynamic(() => import('@/components/landing/ContactForm'), {
  loading: () => <div className="contact-skeleton" />,
});
```

이렇게 하면 이 컴포넌트들의 JS가 초기 번들에서 빠지고, 실제로 렌더링될 때 별도 chunk로 로드된다.

한 가지 주의할 점. skeleton UI를 `loading`에 넣어줘야 CLS가 안 생긴다. 처음에 빈 div만 넣었다가 컴포넌트 로드되면서 레이아웃이 밀리는 문제가 있었다.

## 이미지 lazy loading 세부 튜닝

랜딩 페이지에 이미지가 총 12개 있었다. hero 이미지만 `priority`로 하고 나머지는 기본 lazy loading을 적용했는데, 여기서 한 가지 더 신경 쓴 게 있다.

```tsx
// viewport 바로 아래에 있는 이미지들은 loading="eager"로
// 스크롤 많이 해야 보이는 이미지들만 loading="lazy"로

// hero 바로 아래 섹션의 이미지
<Image
  src="/feature-1.webp"
  width={600}
  height={400}
  alt="기능 소개 1"
  loading="eager"  // fold 근처이므로 eager
  sizes="(max-width: 768px) 100vw, 50vw"
/>

// 페이지 하단의 이미지
<Image
  src="/team-photo.webp"
  width={800}
  height={500}
  alt="팀 사진"
  loading="lazy"  // 스크롤 많이 해야 보이므로 lazy
  sizes="(max-width: 768px) 100vw, 50vw"
/>
```

`sizes` 속성도 중요하다. 이걸 제대로 안 쓰면 모바일에서 데스크톱 사이즈 이미지를 받아온다. 모바일 네트워크에서 불필요하게 큰 이미지를 받는 건 LCP에 직격탄이다.

## 서드파티 스크립트 정리

거의 다 왔다 싶었는데 Lighthouse가 아직 뭔가를 불평하고 있었다. "Reduce the impact of third-party code" 항목이었다.

우리 랜딩 페이지에 붙어 있던 서드파티 목록:

- Google Analytics (gtag.js)
- Hotjar
- Channel Talk (채널톡)
- Facebook Pixel

이 네 개가 합쳐서 약 200KB의 JS를 초기 로딩 때 가져오고 있었다. 특히 Hotjar가 무거웠다.

전부 다 `afterInteractive` 전략으로 바꿨다. Next.js의 `next/script`를 쓰면 된다.

```tsx
import Script from 'next/script';

// GA는 afterInteractive (기본값)
<Script
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"
  strategy="afterInteractive"
/>

// Hotjar와 채널톡은 lazyOnload
<Script id="hotjar" strategy="lazyOnload">
  {`(function(h,o,t,j,a,r){ ... })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');`}
</Script>

<Script id="channel-talk" strategy="lazyOnload">
  {`(function(){var w=window; ... })();`}
</Script>
```

Hotjar와 채널톡은 `lazyOnload`로 설정했다. 페이지 로딩이 완전히 끝나고 브라우저가 idle 상태일 때 로드된다. 유저가 페이지를 보는 시점에는 이미 히어로 섹션이 다 렌더링된 후다.

Facebook Pixel은 PM한테 물어봤더니 "그거 지금 안 쓰는데?"라고 해서 그냥 제거했다. 안 쓰는 스크립트가 200ms를 잡아먹고 있었던 거다.

**3차 Lighthouse 결과: 78점 → 91점, LCP 1.3s → 0.9s**

## 최종 결과 비교

| 지표 | Before | After |
|------|--------|-------|
| Lighthouse Performance | 42 | 91 |
| LCP | 3.2s | 0.9s |
| CLS | 0.28 | 0.04 |
| Total Blocking Time | 890ms | 180ms |
| First Load JS (랜딩) | 387KB | 198KB |

3주 동안 스프린트 틈틈이 작업한 결과다. 풀타임으로 했으면 일주일이면 됐을 것 같다.

## 효과가 컸던 것, 작았던 것

임팩트 순서대로 정리하면 이렇다.

hero 이미지를 WebP로 변환하고 `next/image` + `priority` 적용한 게 가장 컸다. LCP의 절반 이상이 여기서 줄었다. 성능 최적화에서 이미지는 거의 항상 1순위다.

번들 사이즈 줄이기와 code splitting은 예상보다 LCP 자체에 미치는 영향은 적었다. 하지만 TBT(Total Blocking Time)와 TTI(Time to Interactive)에는 확실한 효과가 있었다. 유저가 버튼을 눌렀을 때 반응하는 속도가 체감될 정도로 빨라졌다.

서드파티 스크립트 정리는 "이렇게 쉬운 걸 왜 안 했지?" 싶은 작업이었다. 안 쓰는 Facebook Pixel 하나 제거하고 나머지를 lazy로 바꾸는 건 30분도 안 걸렸는데 효과가 좋았다.

반대로 **preload를 여러 개 거는 건 역효과가 났다**. 그리고 `font-display` 값을 `swap`에서 `optional`로 바꾼 건 수치상으로는 의미 있었지만, 디자이너와의 논의가 필요한 트레이드오프였다. 팀마다 판단이 다를 수 있다.

## 그 이후

PM이 다시 슬랙에 글을 올렸다. "요즘 사이트 빨라진 것 같은데 뭐 한 거예요?" 팀 올핸즈에서 Before/After Lighthouse 점수를 보여줬더니 박수를 받았다. 나쁘지 않은 기분이었다.

근데 사실 아직 할 게 남아 있다. 모바일 3G 환경에서의 성능은 여전히 아쉽고, 서버 응답 시간(TTFB) 자체가 느린 API가 몇 개 있다. ISR이나 Edge Runtime 같은 것도 검토해봐야 하는데, 그건 프론트엔드만으로는 해결이 안 되니까 백엔드 팀과 같이 봐야 한다.

성능 최적화는 한 번 하고 끝나는 게 아니라, 새 기능이 추가될 때마다 조금씩 다시 나빠진다. 그래서 나는 CI에 Lighthouse CI를 붙여놨다. PR마다 성능 점수가 일정 기준 이하로 떨어지면 경고가 뜨게 했다.

```yaml
# .github/workflows/lighthouse.yml
name: Lighthouse CI
on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build
      - uses: treosh/lighthouse-ci-action@v11
        with:
          urls: |
            http://localhost:3000/
          budgetPath: ./budget.json
          uploadArtifacts: true
```

```json
// budget.json
[
  {
    "path": "/",
    "timings": [
      { "metric": "largest-contentful-paint", "budget": 1500 },
      { "metric": "cumulative-layout-shift", "budget": 0.1 },
      { "metric": "total-blocking-time", "budget": 300 }
    ]
  }
]
```

이걸 돌려놓으니까 마음이 좀 편해졌다. 누가 거대한 라이브러리를 무심코 import하거나 최적화 안 된 이미지를 올려도, 머지 전에 알 수 있으니까.

성능 최적화를 하면서 느낀 건, 대부분의 성능 문제는 "몰라서" 생기는 게 아니라 "신경 안 써서" 생긴다는 거다. next/image를 쓰면 된다는 걸 모르는 프론트엔드 개발자는 거의 없다. 근데 실제로 프로젝트에서 img 태그를 쓰고 있는 곳이 얼마나 많은가. 알고 있는 것과 적용하는 것 사이의 간극이 성능 문제의 본질인 것 같다. 그 간극을 줄이는 건 결국 "측정"이다. 숫자를 보면 움직이게 된다.


목요일 오후 2시 13분. 슬랙의 #alert 채널에 메시지가 올라왔다.

> 🚨 [CRITICAL] Checkout conversion rate dropped to 0% (threshold: < 5%)

결제 전환율이 0%. 장바구니에서 결제로 넘어가는 사람이 0명이라는 뜻이다. 처음엔 모니터링 오류인 줄 알았다. 0%는 너무 극단적이니까. 5분 뒤 CS팀에서 메시지가 왔다. "고객 문의가 폭주하고 있어요. 결제 버튼이 안 눌린다는 문의가 벌써 40건입니다."

모니터링 오류가 아니었다.

## 47분

47분. 결제가 완전히 멈춰 있던 시간이다.

나중에 분석한 원인은 이랬다. 오후 1시 50분에 배포가 나갔다. 결제 플로우와는 관계없는, 마이페이지의 UI를 수정하는 작은 PR이었다. 근데 그 PR에 포함된 변경 중 하나가, 공통 유틸 함수가 있는 파일을 건드렸다. `formatPrice`라는 함수의 import 경로를 변경한 거였다.

문제는 이 `formatPrice` 함수가 결제 확인 화면에서도 쓰이고 있었다는 거다. import 경로 변경 과정에서 tree-shaking이 달라졌고, 프로덕션 빌드에서 이 함수가 `undefined`가 됐다. 결제 확인 화면이 렌더링될 때 `formatPrice(totalAmount)`를 호출하면 TypeError가 터지고, Error Boundary가 fallback UI를 보여주는데, 그 fallback에 결제 버튼이 없었다.

로컬에서는 잘 됐다. 스테이징에서도 잘 됐다. 프로덕션 빌드에서만 터졌다. 빌드 최적화 과정에서 import 구조가 달라지면서 발생한 프로덕션 전용 버그.

타임라인을 정리하면:

- **2:13 PM** - 모니터링 알림 발생
- **2:18 PM** - CS팀 보고로 실제 장애 확인
- **2:25 PM** - 프론트엔드 팀 긴급 소집, 원인 조사 시작
- **2:35 PM** - 최근 배포와의 연관성 의심, 롤백 결정
- **2:42 PM** - 롤백 배포 시작
- **2:48 PM** - 롤백 완료, CDN 캐시 퍼지
- **2:55 PM** - 일부 사용자에서 정상 동작 확인
- **3:00 PM** - 전체 정상화 확인

발견부터 정상화까지 47분. 그 47분 동안 결제가 0건이었다.

## 비난이 시작되는 순간

장애가 복구되고 나면, 자연스럽게 "누구 때문에"라는 질문이 나온다. 이번에도 그랬다.

PR을 올린 건 주니어 개발자였다. 마이페이지 UI 수정이라는 단순한 작업이었고, 리뷰어도 2명이 승인했다. 근데 결과적으로 결제를 47분간 멈추게 만든 PR이었다.

장애 직후 긴급 미팅에서, 공기가 무거웠다. 그 주니어 개발자 표정이 하얗게 질려 있었다. 팀 리드가 먼저 입을 열었다. "원인은 파악됐고, 일단 복구됐으니까 다행이야. 내일 포스트모템 하자. 오늘은 다들 쉬어."

그리고 덧붙였다. "이건 개인의 실수가 아니야. 시스템의 문제야."

이 한 마디가 분위기를 완전히 바꿨다.

## 비난 없는 포스트모템

다음 날 포스트모템을 진행했다. Netflix에서 유명한 "blameless postmortem"(비난 없는 포스트모템) 방식을 참고했다. 핵심 원칙은 간단하다. **원인을 사람에게서 찾지 않고, 시스템에서 찾는다.**

Netflix의 철학을 빌리면 이렇다. "We look for causes in the system, not causes in people." 사람은 실수를 한다. 그건 바꿀 수 없다. 바꿀 수 있는 건 시스템이다. 실수를 해도 장애가 발생하지 않는 시스템, 장애가 발생해도 빠르게 복구되는 시스템을 만드는 게 포스트모템의 목적이다.

포스트모템 문서의 구조는 이랬다:

### 1. 타임라인

분 단위로 뭐가 일어났는지. 이건 사실의 기록이다. 해석이 아니라.

### 2. 영향

- 결제 불가 시간: 47분
- 영향 받은 사용자 수: 약 1,200명 (해당 시간대 결제 시도 기준)
- 예상 매출 손실: 약 X만 원
- CS 문의 건수: 87건

숫자로 정리하는 게 중요하다. "심각했다"가 아니라 "47분, 1,200명"으로.

### 3. 근본 원인 (Root Cause)

여기서 5 Whys를 적용했다.

**Why 1**: 결제 확인 화면이 렌더링 에러를 일으켰다. → `formatPrice`가 `undefined`였다.
**Why 2**: `formatPrice`가 `undefined`가 된 이유는? → 프로덕션 빌드에서 tree-shaking이 import 경로 변경으로 달라졌다.
**Why 3**: 왜 이걸 배포 전에 못 잡았나? → 프로덕션 빌드 환경에서의 E2E 테스트가 결제 플로우를 커버하지 않았다.
**Why 4**: 왜 결제 플로우 E2E 테스트가 없었나? → 결제 플로우는 외부 PG 연동이 있어서 테스트 환경 구성이 복잡했고, "나중에 하자"고 미뤄뒀다.
**Why 5**: 왜 미뤄졌나? → 다른 기능 개발 일정에 밀려서 우선순위가 계속 내려갔다.

5 Whys의 끝에 도달하면, "주니어가 실수했다"가 아니라 **"결제 플로우의 E2E 테스트가 없었다"**와 **"프로덕션 빌드 환경에서의 검증 프로세스가 부족했다"**가 나온다. 시스템의 문제다.

### 4. 잘한 것

이 섹션이 중요하다. 포스트모템이 반성문이 되면 안 된다. 잘한 것도 기록해야 한다.

- 모니터링 알림이 5분 이내에 발생했다. (모니터링 시스템이 잘 동작했다)
- 롤백 결정이 10분 만에 내려졌다. (원인 분석에 시간을 쓰지 않고 빠르게 롤백한 판단이 좋았다)
- 롤백 파이프라인이 정상 동작해서 6분 만에 배포가 완료됐다.
- CS팀이 빠르게 상황을 공유해줘서 모니터링과 크로스체크가 됐다.

### 5. 액션 아이템

각 항목에 담당자와 기한을 붙인다. "좋은 아이디어"가 아니라 "누가 언제까지 한다"여야 한다.

- **[프론트엔드]** 결제 플로우 E2E 테스트 작성 (담당: OO, 기한: 2주)
- **[인프라]** 프로덕션 빌드 후 주요 페이지 스모크 테스트 자동화 (담당: OO, 기한: 3주)
- **[프론트엔드]** Error Boundary fallback에 최소한의 주요 기능(결제 버튼) 포함 (담당: OO, 기한: 1주)
- **[공통]** 공통 유틸 파일 변경 시 영향 범위 분석 도구 도입 검토 (담당: OO, 기한: 4주)

## 포스트모템 이후 바뀐 것들

포스트모템 자체는 1시간짜리 회의였다. 근데 그 이후 팀에서 바뀐 것들이 상당했다.

**첫째, 결제 플로우 E2E 테스트가 생겼다.** 진작 했어야 하는 건데, 장애가 터지고 나서야 우선순위가 올라갔다. PG 연동 부분은 mock 서버로 처리하고, 결제 버튼 클릭부터 주문 완료 화면까지의 전체 플로우를 테스트하는 시나리오가 만들어졌다. 이 테스트 하나가 이후 3개월 동안 비슷한 종류의 문제를 2번 사전에 잡아냈다.

**둘째, 프로덕션 빌드 스모크 테스트가 배포 파이프라인에 들어갔다.** 배포 전에 프로덕션 빌드를 올린 뒤, 주요 페이지(메인, 검색, 상세, 장바구니, 결제)가 정상 렌더링되는지 자동으로 확인한다. 렌더링 에러가 있으면 배포가 멈춘다. 이것도 장애 전에는 "있으면 좋겠다" 수준이었는데, 장애 후에는 필수가 됐다.

**셋째, Error Boundary 전략이 바뀌었다.** 기존에는 에러가 나면 "문제가 발생했습니다" 같은 범용 fallback을 보여줬다. 이제는 페이지별로 다른 fallback을 제공한다. 결제 화면의 fallback에는 최소한 "다시 시도" 버튼과 CS 연락처가 포함되어 있다. 에러가 나도 사용자가 완전히 막히지 않도록.

**넷째, 배포 자신감이 올라갔다.** 아이러니하게도, 장애를 겪고 나서 배포에 대한 두려움이 줄었다. 테스트가 추가되고, 스모크 테스트가 있고, 롤백 프로세스가 검증됐으니까. "배포하면 뭔가 터질 수 있다"는 막연한 불안이 "터지더라도 빠르게 잡을 수 있다"는 자신감으로 바뀌었다.

## 장애가 가르쳐 준 것들

이 경험에서 배운 게 몇 가지 있다.

**장애의 직접 원인과 근본 원인은 다르다.** 직접 원인은 "import 경로가 변경돼서 프로덕션 빌드에서 함수가 누락됐다"이다. 이걸 고치면 이 특정 장애는 재발하지 않는다. 근데 근본 원인은 "프로덕션 환경에서의 검증이 부족하다"이다. 이걸 고치지 않으면, 비슷한 종류의 다른 장애가 언젠가 또 터진다. 직접 원인을 고치는 건 소방이고, 근본 원인을 고치는 건 방화다. 둘 다 필요하다.

**"나중에 하자"는 리스크의 다른 이름이다.** 결제 플로우 E2E 테스트는 6개월 전부터 "해야 하는데"라고 모두가 알고 있었다. 근데 항상 더 급한 기능 개발에 밀렸다. 이건 의식적인 결정이 아니라 관성이었다. 장애가 터지고 나서야 그 "나중"의 비용이 얼마인지 체감했다. E2E 테스트를 6개월 전에 만들었으면, 47분의 장애와 X만 원의 매출 손실을 막을 수 있었다.

**장애 대응은 근육이다.** Netflix가 Chaos Engineering과 GameDay를 하는 이유가 이거다. 장애 대응을 평소에 연습해둬야 실전에서 제대로 동작한다. Netflix에서는 팀들이 의도적으로 장애를 일으키고 복구하는 훈련을 한다. 우리 팀이 47분 만에 복구할 수 있었던 건, 롤백 프로세스를 이전에 몇 번 써본 적이 있었기 때문이다. 한 번도 롤백을 해본 적 없는 팀이었으면, 현장에서 롤백 방법을 찾느라 2시간은 더 걸렸을 거다.

## 비난 문화 vs 학습 문화

장애 이후 팀의 반응은 크게 두 갈래로 나뉜다.

**비난 문화**: "누가 이 PR을 올렸어?" "리뷰어가 왜 이걸 못 잡았어?" "배포 전에 확인 안 했어?" 이런 반응이 반복되면, 사람들은 변화를 두려워하게 된다. 배포를 미루고, PR을 작게 쪼개는 게 아니라 아예 안 올리려 하고, "내가 안 건드리면 내 책임이 아니다"는 방어적 태도가 생긴다.

**학습 문화**: "어떤 시스템적 원인이 있었지?" "같은 종류의 문제를 앞으로 어떻게 방지하지?" "이번 대응에서 잘한 건 뭐고 개선할 건 뭐지?" 이런 반응이 반복되면, 장애가 무서운 게 아니라 배움의 기회가 된다. 사람들이 더 적극적으로 문제를 공유하고, 잠재적 리스크를 미리 말하게 된다.

Netflix가 인시던트의 정의를 확장한 것도 같은 맥락이다. 큰 장애만 인시던트가 아니라, "서비스를 저하시키거나 방해하는 모든 현상"을 인시던트로 다루겠다는 거다. 작은 문제도 기록하고, 분석하고, 배우겠다는 뜻이다. 이게 가능하려면 비난이 없어야 한다. "이 정도도 인시던트로 올려?"라는 반응이 있으면, 아무도 작은 문제를 공유하지 않게 된다.

## 그 주니어 개발자

장애를 일으킨(것처럼 보인) 주니어 개발자. 포스트모템 이후 그 개발자가 DM을 보내왔다. "솔직히 많이 무서웠는데, 포스트모템이 시스템 문제에 집중한 게 다행이었어요. 근데 여전히 죄책감이 있어요."

이렇게 답했다. "그 PR을 리뷰한 사람이 2명 있고, 그 리뷰어들도 이 문제를 못 잡았어. 프로덕션 빌드에서만 터지는 문제를 코드 리뷰로 잡는 건 현실적으로 불가능해. 네가 아니라 다른 누가 그 PR을 올렸어도 같은 결과였을 거야. 이건 진짜로 시스템 문제야."

그리고 한 가지 더. "이번에 네가 결제 플로우 E2E 테스트를 작성하기로 했잖아. 그 테스트가 앞으로 같은 종류의 장애를 막을 거야. 장애를 경험한 사람이 방어 코드를 만드는 게 가장 효과적이거든. 동기 부여가 다르니까."

2주 뒤, 그 개발자가 만든 E2E 테스트가 머지됐다. 꽤 꼼꼼했다. 결제 플로우의 모든 분기를 커버하고 있었고, 에러 시나리오까지 포함되어 있었다. 장애를 겪은 사람의 테스트 케이스는 확실히 다르다. 어떤 부분이 깨질 수 있는지를 체감으로 아니까.

## 장애는 가장 비싼 수업료다. 근데 가장 효과적이기도 하다

이상적으로는 장애 없이 배우면 좋겠다. 다른 회사의 포스트모템을 읽고, 기술 블로그의 사례를 보고, 미리 대비하면 좋겠다. 근데 현실은, 직접 경험한 장애만큼 강렬한 학습은 없다.

서버 상태 캐싱의 중요성을 글로 100번 읽는 것보다, 캐시가 꼬여서 사용자에게 다른 사람의 데이터가 보인 경험 1번이 더 강렬하다. 배포 파이프라인에 테스트를 넣어야 한다는 걸 이론으로 아는 것보다, 테스트 없이 배포했다가 장애를 겪는 게 더 확실한 동기 부여가 된다.

다만, 장애에서 배우려면 조건이 있다. 비난이 아니라 분석이 있어야 하고, 분석에서 끝나는 게 아니라 구체적인 액션이 나와야 하고, 그 액션이 실제로 실행되어야 한다. 포스트모템 문서를 쓰고 서랍에 넣으면 아무 의미가 없다.

결제가 47분간 멈춘 그날 이후, 한 가지 확실해진 게 있다. 장애는 실패가 아니라 피드백이다. 시스템이 "여기가 약해"라고 알려주는 신호다. 그 신호를 무시하면 같은 자리에서 다시 터진다. 그 신호를 분석하고 대응하면, 시스템이 더 강해진다.

그리고 솔직히, 그날의 긴장감은 아직도 생생하다. 슬랙 알림이 울리고, 회의실에 모이고, 화면을 같이 보면서 원인을 추적하던 그 47분. 무서웠지만, 그때만큼 팀이 하나로 뭉친 적도 없었다. 장애는 팀을 시험하고, 동시에 팀을 단단하게 만든다.


Learn in Public이라는 개념을 처음 접한 건 Swyx(Shawn Wang)의 블로그 글이었다. 2024년 말, 트위터에서 누가 공유한 걸 타고 들어갔다. 핵심은 간단하다. 뭔가를 배우면 그 과정을 공개적으로 기록하라. 블로그, 트위터, 유튜브, 깃허브, 뭐든 좋다. 완벽하지 않아도 된다. 틀린 내용이 있어도 된다. 배우는 중이라는 걸 드러내라. 그러면 같은 레벨의 사람들이 공감하고, 더 높은 레벨의 사람들이 피드백을 주고, 기회가 찾아온다.

읽었을 때 "그래, 좋은 말이네" 하고 넘길 뻔했다. 블로그에서 읽고 감명받았다가 일주일 뒤에 까먹는 건 한두 번이 아니니까. 근데 마침 2025년 새해 목표를 세우는 시점이었고, 기술 블로그를 시작하려던 참이었다. "한번 해보자. 1년 동안 해보고 아무 일도 안 생기면 그만두지 뭐."

## 첫 글의 조회수: 7

2025년 1월 둘째 주에 첫 블로그 글을 썼다. "Next.js App Router에서 삽질한 기록"이라는 제목이었다. 업무에서 App Router 마이그레이션을 하면서 겪은 문제들을 정리한 거다. 서버 컴포넌트에서 useEffect를 쓰려다 에러난 것, layout.tsx에서 metadata를 dynamic하게 설정하다 삽질한 것, fetch 캐싱이 예상과 다르게 동작해서 한 시간을 날린 것. 전부 내가 직접 겪은 삽질.

글을 쓰는 데 3시간 걸렸다. 말이 3시간이지, 실제로는 토요일 오후 내내 붙잡고 있었다. 머릿속에 있는 걸 글로 옮기는 게 생각보다 어려웠다. 알고 있다고 생각한 것을 설명하려면 다시 공식 문서를 열어서 확인해야 했다. "이게 너무 기초적인 내용 아닌가?" "틀린 말 쓰면 어쩌지? 이 블로그 하나 때문에 내 커리어가 망하면?" "누가 이걸 읽겠어?" 하는 생각이 계속 들었다.

어쨌든 올렸다. 심장이 뛰었다. 퍼블리시 버튼을 누르는 게 PR 올리는 것보다 긴장됐다.

일주일 후 조회수를 확인했다. 7. 일곱 명. 그중 몇 명은 내가 다른 브라우저로 접속한 건지 봇인지도 모르겠다. 트위터에도 공유했는데 좋아요 1개. 아마 자동 좋아요 봇.

실망하지 않았다고 하면 거짓말이다. 3시간을 들여서 일곱 명한테 읽혔다. 시급으로 따지면 끔찍한 숫자다. 근데 Swyx의 글에 이런 말이 있었다. "대부분의 사람들은 한 번 글을 쓰고 반응이 없으면 그만둔다. 계속 하는 것만으로도 상위 1%에 든다." 그 말을 믿기로 했다.

## 3개월: 아무도 안 읽는 시기

1월부터 3월까지 총 8개의 글을 올렸다. 2주에 한 개 꼴. 평균 조회수는 20~30. 댓글은 0. 진짜 단 한 개도 없었다. 트위터에도 학습 내용을 올리기 시작했다. "오늘 배운 것: React Query에서 staleTime과 gcTime의 차이" 같은 짧은 글. 좋아요 1~2개. 가끔 0개.

이 시기가 제일 힘들었다. 글을 쓰는 건 시간이 드는 일인데, 아무도 안 읽으니까 의미가 없는 것처럼 느껴졌다. 토요일 오후를 투자해서 글을 썼는데 조회수 23. "그냥 혼자 노션에 정리하는 게 낫지 않나?" 하는 생각이 매주 들었다. 두 번째 달 말에는 진심으로 그만둘까 고민했다.

그래도 계속한 이유가 하나 있었다. 글을 쓰는 과정 자체가 학습에 도움이 됐기 때문이다. 뭔가를 설명하려면 정확히 이해하고 있어야 한다. "내가 안다고 생각하는 것"과 "남에게 설명할 수 있는 것" 사이에는 꽤 큰 간극이 있다. 블로그 글을 쓰면서 "아, 나 이거 대충 알고 있었네"를 깨닫는 순간이 많았다. React의 Fiber 아키텍처에 대해 글을 쓰다가 "재조정(reconciliation)과 커밋(commit) 페이즈의 차이가 뭐지?"를 스스로 답하지 못해서 2시간을 더 공부한 적도 있다. 그 2시간의 공부는 글을 안 썼으면 하지 않았을 거다.

독자가 아무도 없어도 글 쓰는 행위 자체가 공부의 일부라는 걸 이 시기에 배웠다. 그래도 조회수가 0이면 허탈하다.

## 4개월 차: 첫 번째 반응

4월에 쓴 "CSS Container Query를 실무에서 써본 후기"라는 글이 의외의 반응을 얻었다. 트위터에서 프론트엔드 개발자 커뮤니티에 공유했는데, 리트윗이 15개 정도 됐고 조회수가 800을 찍었다. 나한테는 엄청난 숫자였다. 조회수 20에서 800. 40배.

이유를 분석해봤다. Container Query를 실무에 적용한 사례가 당시에 많지 않았다. 대부분 "Container Query란 무엇인가", "Container Query 사용법" 같은 개념 설명 글이었는데, 내 글은 실제 프로덕션 코드에서 어떻게 쓰고, 어떤 문제를 겪었는지를 다뤘다. 반응형 사이드바에 적용했다가 Safari에서 안 되는 문제를 만났던 이야기, 결국 @supports로 폴백 처리한 이야기. 이런 실전 경험이 가치 있었던 거다.

이 경험에서 배운 게 있다. 주니어 개발자의 콘텐츠가 가치 있는 이유가 따로 있다. 시니어가 쓰는 글은 추상적이고 개념적인 경우가 많다. "좋은 아키텍처란 무엇인가", "확장 가능한 코드의 원칙" 같은 것들. 물론 좋은 글이지만, 주니어가 바로 적용하기 어렵다. 반면에 주니어가 쓰는 글은 "실제로 해봤는데 이런 삽질을 했다"는 구체적인 경험담이다. 이게 같은 레벨의 개발자들한테 훨씬 더 와닿는다. "아 나도 이거 겪었는데!" 하는 공감.

## 6개월 차: 커피챗 제안

6월에 트위터 DM이 왔다. 스타트업 CTO라고 자기 소개를 한 분이 "블로그 글 잘 읽고 있습니다. 특히 성능 최적화 시리즈가 좋더라고요. 커피챗 한 번 하실래요?" 라고 메시지를 보냈다.

처음에는 스팸인 줄 알았다. 요즘 DM 스팸이 많으니까. 프로필을 확인해보니 실제 회사의 CTO였다. 50명 정도 되는 시리즈 B 핀테크 스타트업. 프론트엔드 팀을 3명에서 6명으로 확장하고 있는데 관심이 있으면 이야기를 나눠보고 싶다고 했다.

강남역 근처 카페에서 커피챗을 했다. 채용 제안까지는 가지 않았다. 내가 아직 이직 생각이 없다고 솔직히 말해서. 근데 프론트엔드 아키텍처에 대한 이야기를 나누면서 내가 모르는 것들을 많이 배웠다. 마이크로 프론트엔드 도입 경험, 디자인 시스템 구축 과정, 프론트엔드 팀의 코드 리뷰 문화. 1시간이 순식간에 갔다. "나중에 이직 생각이 생기면 언제든 연락해"라는 말과 함께 끝났다.

이 경험은 Learn in Public의 가장 큰 장점을 체감하게 해줬다. 내가 먼저 기회를 찾아 나선 게 아니라, 기회가 나를 찾아온 거다. 이력서를 넣지 않았는데 CTO가 DM을 보냈다. 블로그가 일종의 포트폴리오이자 비동기 네트워킹 도구가 된 셈이다. 내가 자는 동안에도 블로그 글은 일하고 있었다.

## 9개월 차: 밋업 발표

이건 진짜 예상 못했다. 9월에 국내 프론트엔드 밋업 운영진으로부터 이메일이 왔다. "10월 밋업에서 20분 정도 발표를 해주실 수 있을까요? 블로그에서 다루신 LCP 최적화 주제로 이야기해주시면 좋을 것 같아서요."

심장이 멈추는 줄 알았다. 나는 사람 앞에서 발표하는 걸 좋아하지 않는다. 대학교 때 조별 발표도 겨우 했던 사람이다. 목소리가 떨리고, 대본을 까먹고, 얼굴이 빨개진다. 50명 앞에서 발표를 하라고?

2주를 고민하다가 수락했다. 거절하면 이런 기회가 다시 오지 않을 것 같아서. 그리고 Learn in Public의 정신이기도 하니까. 불편한 걸 해야 성장한다는 거.

준비하는 한 달이 고통이었다. 슬라이드를 만들고 부수고 다시 만들고. 20분 분량인데 처음에는 45분 분량으로 만들어서 반을 잘라냈다. 혼자서 발표 연습을 열 번은 한 것 같다. 발표 당일에는 떨려서 물을 5잔을 마셨다. 화장실을 세 번 갔다.

발표 자체는... 괜찮았다고 해야 하나. 훌륭하지는 않았다. 중간에 한 번 말이 막혔고, 시간 배분을 잘못해서 마지막 파트를 좀 급하게 넘겼다. 근데 끝나고 나니까 "내가 이걸 했다"는 사실 자체가 자신감을 줬다. 그리고 발표 후에 몇 명이 와서 질문하고 이야기를 나누면서 네트워크가 생겼다. 한 사람은 같은 회사에서 비슷한 성능 이슈를 겪고 있다면서 서로 연락처를 교환했다.

## 1년이 지나고

2025년 1월에 시작해서 지금 2026년 2월. 블로그 글이 30개 정도 쌓였다. 트위터 팔로워는 400명 정도. 유명 개발자의 기준에서 보면 아무것도 아닌 숫자다. 근데 1년 전 0에서 시작한 걸 생각하면, 그리고 내가 목표로 했던 건 유명해지는 게 아니라 학습 효과를 높이는 거였다는 걸 생각하면, 나쁘지 않다.

가장 큰 성과는 숫자가 아니다. "나도 공유할 만한 경험이 있다"는 자기 인식이 생긴 거다. 주니어라서, 아직 많이 모르니까, 내 경험은 별 거 아니니까 — 이런 생각이 Learn in Public을 방해하는 가장 큰 벽이다. 근데 2년 차인 나의 삽질 기록이 1년 차한테는 보물이다. 5년 차의 아키텍처 글은 1년 차가 이해하기 어렵지만, 2년 차의 삽질 기록은 바로 공감이 된다.

한 가지 주의할 점도 생겼다. 공개 학습에 조회수나 반응이 목적이 되면 동기가 왜곡된다. 조회수 높은 주제만 쓰게 되고, 진짜 배우고 싶은 것과 글로 쓸 것이 분리된다. 나도 한때 "React vs Vue 비교" 같은 떡밥 글을 쓸까 고민한 적이 있다. 조회수는 높겠지만, 내 학습과는 아무 관련이 없다. 그건 콘텐츠 마케팅이지 Learn in Public이 아니다.

배우고 싶은 걸 배우고, 그중에 글로 쓸 만한 걸 쓰는 거다. 순서가 중요하다. 학습이 먼저고, 공유는 그 다음이다.

아직도 글을 쓸 때마다 "이거 올려도 되나" 하는 불안이 있다. 완전히 사라지지는 않을 것 같다. 그래도 올린다. 올리고 나서 후회한 적은 아직 한 번도 없으니까.



안녕, 오늘 입사 첫날이지? 양복 입을까 후드 입을까 30분 고민하다가 결국 셔츠에 청바지 입고 왔을 거다. 정답이었어. 팀 사람들 대부분 후드인데 혼자 양복 입고 왔으면 좀 어색했을 거다. 참고로 나는 지금 맨투맨에 청바지를 입고 있어. 복장에 신경 쓰는 건 첫 주까지더라.

노트북 받고 개발 환경 세팅하는 데 하루 종일 걸렸지? Node 버전 맞추고, .env 파일 받고, Docker 띄우다가 에러 나고. README에 "이 순서대로 하면 됩니다"라고 적혀 있는데, 3번 항목에서 바로 에러가 나서 멘붕 왔을 거다. Docker Desktop 버전 문제였는데, 그걸 혼자 찾느라 두 시간을 쓰지 마. 옆에 앉은 시니어한테 바로 물어봐. "이거 어떻게 해요?" 물어보는 게 아직 어색할 거다. 그 사람 집중하고 있는 것 같아서 방해하는 것 같고, 이런 기본적인 걸 모르면 무능해 보일까 봐 걱정되고.

한 가지 말해줄게. 그 사람 진짜 좋은 사람이야. 지금 얼굴이 무표정한 건 집중하고 있어서 그런 거고, 물어보면 항상 잘 알려줘. 하던 일 멈추고 내 화면을 보면서 같이 에러를 읽어줘. 1년 후에 그 사람이 제일 고마운 사람이 될 거다. 이 편지를 쓰는 지금도 그 시니어 옆자리에 앉아 있어.

## 첫 PR에 대해서

첫 PR 올리는 데 3일 걸릴 거다. 버튼 색상 하나 바꾸는 건데 3일. 지금 듣기엔 말이 안 되지? 근데 그렇게 된다.

코드 어디를 바꿔야 하는지 찾는 데 하루. 프로젝트 구조가 처음이니까 파일이 100개 넘는데 어디가 어딘지 모르겠고, 글로벌 검색으로 해당 텍스트를 찾았는데 그게 상수 파일인지, 컴포넌트인지, 스타일인지 헷갈리고. 바꾸고 나서 다른 데 영향 없는지 확인하는 데 하루. 이 버튼이 다른 페이지에서도 쓰이는 건 아닌지, 공용 컴포넌트인지, 이 페이지에만 있는 건지. PR 설명 쓰고 올리는 데 반나절. "이 PR은 무엇을 왜 변경했는지" 영어로 쓸지 한국어로 쓸지도 고민하고.

느린 거 아니야. 다 그래. 코드베이스가 낯설면 버튼 하나도 무섭다. 지금의 나도 새 프로젝트 들어가면 처음 며칠은 비슷해. 다만 찾는 속도가 빨라졌을 뿐이야.

리뷰가 올 거다. 코멘트 7개. 처음에는 7개나 달렸다고 놀랄 텐데, 그건 문제가 많다는 게 아니라 관심을 가져준다는 뜻이야. 리뷰 안 받는 것보다 훨씬 낫다. 코멘트 하나하나 읽으면서 "아 이런 것도 신경 써야 하는구나" 하고 배우는 게 많을 거다. 접근성(a11y) 관련 코멘트가 있을 텐데, 버튼에 `aria-label`을 달아야 한다는 내용이야. 그때 처음 알게 되는 개념인데, 이게 나중에 꽤 큰 도움이 돼. 1년 후에는 접근성을 먼저 챙기는 습관이 생겨 있을 거야.

## 점심시간이 어색한 기간

처음 한 달은 점심시간이 제일 긴장된다. 누구랑 먹을지, 뭘 시킬지, 대화 주제를 뭘로 할지. 11시 반쯤 되면 슬슬 신경이 쓰이기 시작해. 혼자 먹으면 "혼밥 하는 신입"으로 보일까 봐 불안하고, 같이 먹으면 대화에 끼어들 타이밍을 모르겠고. 다들 사내 이야기나 이전 프로젝트 이야기를 하는데, 맥락을 모르니까 그냥 웃고만 있게 된다.

걱정 안 해도 돼. 한 달만 지나면 자연스러워져. 그리고 혼자 먹는 날도 생기는데, 그것도 괜찮아. 혼자 먹으면서 유튜브 보는 게 편한 날이 있거든. 개발팀 사람들은 대부분 그 감각을 이해해. 매일 같이 먹자고 하는 사람도 없고, 혼자 먹는다고 서운해하는 사람도 없어.

점심 때 기술 이야기 나오면 모르는 단어가 엄청 많을 거다. "쿠버네티스", "카프카", "테라폼", "gRPC" 같은 거. 프론트엔드랑 직접 관련 없는 것들인데, 뭔지도 모르면서 고개를 끄덕이겠지. 나도 그랬어. 괜찮아. 1년 후에도 쿠버네티스가 정확히 뭔지는 모르지만, "컨테이너 오케스트레이션 도구"라는 한 문장 정도는 말할 수 있어. 그 정도면 충분해.

## 실수들에 대해서

스테이징 환경이랑 프로덕션 환경을 헷갈려서, 스테이징에 올려야 할 걸 프로덕션에 배포하는 일이 생길 거다. 입사 2개월 차쯤. 금요일 오후에. 하필 금요일이야. 식은땀이 날 거다. 심장이 쿵쿵 뛸 거고, 손이 떨릴 거다. 근데 CI/CD 파이프라인이 잘 되어 있어서 롤백이 금방 된다. 5분이면 돌아가. 팀 리드가 "괜찮아, 다들 한 번씩은 해"라고 할 텐데, 위로가 안 되겠지. "나는 왜 이런 실수를 했을까" 자책할 거다. 실수한 당일은 퇴근하고 나서도 계속 생각날 거다. 주말 내내.

근데 그 실수 덕분에 배포 프로세스를 확실히 이해하게 돼. 어떤 브랜치가 어디로 가는지, PR 머지 후 파이프라인이 어떤 순서로 도는지, 스테이징과 프로덕션의 환경 변수가 어떻게 다른지. 실수 전에는 그냥 버튼 누르면 나간다고만 알았는데, 실수 후에는 전체 흐름이 머리에 들어온다. 값비싼 수업료였지만 효과는 확실했어. 1년 후에는 배포할 때 무의식적으로 브랜치를 두 번 확인하는 습관이 생겨 있어.

## 코드 리뷰에서 울 뻔한 날

3개월차쯤에 큰 피처를 맡게 된다. 사용자 프로필 페이지. 여러 섹션이 있고, 각 섹션마다 편집 모드가 있는 꽤 복잡한 페이지야. 혼자 맡는 첫 번째 큰 피처라서 열심히 했다. 일주일 동안 밤 9시까지 남아서 코드를 쳤어.

리뷰를 올렸는데 코멘트가 23개 달릴 거다. 스물세 개. 알림이 계속 와서 세다가 지칠 정도. 대부분 "이 부분은 왜 이렇게 했나요?"라는 질문인데, 3개월 차 눈에는 "다 틀렸다"로 읽힌다. "이 상태 관리 방식은 적절하지 않은 것 같습니다", "이 컴포넌트는 책임이 너무 많습니다", "이 useEffect의 의존성 배열을 확인해주세요." 빨간 줄이 23개. 화장실에 가서 잠깐 멍하니 서 있었지.

1년 후에 깨닫게 되는 건데, 그때 받은 리뷰 내용이 지금 내 코딩 습관의 90%를 만들었다. "컴포넌트가 너무 많은 걸 알고 있다"는 코멘트에서 단일 책임 원칙을 배웠다. "이 상태는 여기서 관리할 게 아니라 부모에서 내려주는 게 맞다"에서 상태 끌어올리기를 배웠다. "이 useEffect는 정리 함수가 필요하다"에서 클린업의 중요성을 배웠다. "이 함수는 컴포넌트 밖으로 빼도 되지 않을까요?"에서 순수 함수의 개념을 배웠다. 다 그때 리뷰에서 배운 거다.

23개 코멘트가 공격이 아니라 투자였다는 걸, 그때는 몰랐을 거다. 23개나 써준 건 그만큼 시간을 쏟아준 거야.

## 비교하지 말라는 건 어렵지만

같은 시기에 입사한 동기가 있을 거다. 백엔드 개발자인데, 그 사람이 빠르게 적응하는 것처럼 보일 거다. 경력이 있는 사람이거든. 첫 주에 바로 피처를 올리는 걸 보면서 "나는 아직 환경 세팅도 못 했는데" 할 거다. 비교하게 될 텐데, 출발선이 다르다는 걸 기억해. 비교해봤자 자기 페이스가 흔들릴 뿐이야.

6개월쯤 지나면 "나는 왜 아직도 이런 것도 모르지?" 하는 시기가 온다. 이걸 "정체기"라고 부르더라. 매일 같은 일을 반복하는데 성장하는 느낌이 없는 시기. 무섭겠지만 정상이야. 거기서 꾹 참고 계속 하면 어느 날 갑자기 "어, 이거 알겠는데?" 하는 순간이 온다. 계단처럼.

## 지금의 내가 해줄 수 있는 말

1년 후에 너는 팀에서 프론트엔드 피처 하나를 온전히 맡아서 설계부터 배포까지 할 수 있게 돼. 기획서를 받으면 컴포넌트 구조가 머리에 그려지고, 어떤 라이브러리를 쓸지 판단할 수 있어. 새로 들어오는 인턴한테 온보딩을 해줄 정도가 된다. 첫날에 Node 버전 맞추는 것도 못 하던 사람이.

완벽한 개발자는 아니야. 아직도 모르는 게 산더미고, 시니어한테 질문하는 일이 많고, 코드 리뷰에서 배우는 게 더 많다. 근데 "성장하고 있다"는 건 확실해. 느리지만 확실해.

첫날의 긴장감을 기억해. 1년 후에 그 긴장감이 그리워질 때가 있다. 모든 게 새롭고, 모든 게 배움이던 그 감각. 지금은 좀 무뎌졌거든. 루틴에 익숙해지면 새로운 자극을 일부러 찾아야 해. 그게 좀 아쉽다.

그러니까 첫날을 즐겨. 어색하고 불안하겠지만, 그게 시작이니까.

추신: 회사 근처 골목에 김치찌개 맛집이 있다. 간판이 허름해서 안 가게 생겼는데, 꼭 가봐. 두부 김치찌개 7,000원. 1년 후에도 거기 다녀. 아, 가격은 7,500원으로 올랐다.


회사에서 주 2일 재택, 주 3일 출근을 하다가 프로젝트 사정으로 3개월간 풀 재택을 한 적이 있다. 사무실 이전 기간이었는데, 임시 사무실이 너무 멀어서 팀 전체가 재택으로 전환했다. 처음에 공지가 왔을 때 내심 기뻤다. "3개월 동안 출퇴근 안 해도 된다고?"

처음 일주일은 천국이었다.

출근 시간이 사라졌다. 편도 50분, 지하철 환승 한 번에 버스 한 번. 왕복 1시간 40분을 돌려받았다. 아침에 30분 더 자고, 운동복 차림으로 맥북을 열었다. 세수하고 이 닦고 바로 데스크에 앉으니까 9시에 이미 코드를 치고 있었다. 사무실에서는 9시에 겨우 도착해서 커피 타고 슬랙 확인하고 하면 실질적으로 코딩 시작이 9시 반이었는데.

점심도 직접 해먹으니까 돈이 안 나갔다. 회사 근처 식당은 만 원대인데, 집에서 라면이나 볶음밥 해먹으면 3천 원이면 됐다. 집이 조용해서 집중도 잘 됐다. 사무실에서는 옆 팀 미팅 소리, 전화 소리, 누군가 간식 먹는 소리가 배경음이었는데, 집은 고요했다. "이게 되는데 왜 출근을 해?" 하는 생각이 진심으로 들었다.

2주차까지는 이 감각이 유지됐다.

## 슬슬 이상한 느낌

3주차쯤부터 뭔가 달라졌다. 몸이 아픈 건 아닌데, 에너지가 없었다. 아침에 맥북을 열면 슬랙 알림만 있고, 사람 얼굴이 없었다. 화상 미팅은 있지만, 카메라를 끄는 사람이 많아서 프로필 아이콘만 보면서 대화했다. 화면에 동그란 이니셜만 떠 있고, 목소리만 들리는 미팅. 하루 종일 모니터에 있는 텍스트랑 대화한다는 느낌.

말을 안 하는 시간이 길어졌다. 사무실에서는 의식하지 않아도 말을 한다. "좋은 아침이에요", "점심 뭐 먹을까요?", "이거 잠깐 봐줄 수 있어요?", "수고하세요." 이런 사소한 대화들. 재택에서는 이게 다 슬랙 텍스트로 대체됐다. 화상 미팅 빼고는 입을 열 일이 없는 날도 있었다. 하루에 말을 10문장도 안 하는 날.

점심도 혼자 먹었다. 처음에는 편했는데, 3주째 되니까 좀 심심했다. 회사에서는 점심 때 동료랑 이런저런 이야기를 하잖아. "어제 뭐 했어?", "그 드라마 봤어?", "이번 주말에 뭐 해?", 기술 이야기가 아닌 잡담. 이게 사라지니까 하루가 너무 평면적이었다. 코드-식사-코드-식사. 중간에 사람이 없었다. 생활에 질감이 없다고 해야 할까.

## 업무적으로도 미묘하게

재택이 길어지면서 커뮤니케이션 비용이 올라갔다. 사무실에서는 "이거 잠깐만" 하고 옆자리에서 물어보면 30초에 끝나는 질문이, 슬랙으로는 메시지를 쓰고, 상대방이 읽을 때까지 기다리고(초록불이 안 켜져 있으면 언제 볼지 모르고), 텍스트로 설명하다 보니 오해가 생기고, 다시 설명하고. 간단한 확인 하나에 5분-10분이 걸렸다.

한번은 디자인 수정 사항을 슬랙으로 논의했는데, 나는 "왼쪽 정렬"이라고 생각한 게 디자이너는 "컨테이너 내에서 왼쪽"이 아니라 "전체 레이아웃 기준으로 왼쪽"을 말한 거였다. 이걸 파악하는 데 메시지 10개가 오갔다. 스크린샷을 찍어서 보내고, "이거 말하는 거예요?" "아뇨 이게 아니라", 다시 스크린샷. 옆에 앉아 있었으면 화면 가리키면서 "여기" 하고 3초에 끝났을 텐데.

코드 리뷰도 미묘하게 달라졌다. 대면에서는 "이 부분은 이렇게 하면 어때?"가 자연스러운데, 텍스트로는 같은 말이 딱딱하게 느껴진다. 톤이 전달이 안 되니까. "이 부분은 왜 이렇게 했나요?"가 순수한 궁금함인지, 지적인지 텍스트로는 구분이 어렵다. 이모지를 붙여도 한계가 있다. 코멘트 톤에 대해 고민하는 시간이 늘었다. 예전에는 5초면 쓸 코멘트를 2분 동안 다듬고 있었다.

## 경계가 사라진다

재택의 가장 큰 문제는 일과 생활의 경계가 없다는 거였다.

퇴근 시간이 애매해졌다. 사무실에서는 6시 반쯤 되면 사람들이 하나둘 일어나고, 가방을 챙기는 소리가 나고, "수고하셨습니다" 인사가 들리고. 그걸 보면서 "나도 슬슬" 하고 퇴근한다. 물리적인 퇴근 신호가 있는 거다. 재택에서는 그런 신호가 없다. 슬랙에 마지막 메시지가 7시에 오면 7시까지 보고 있고, 8시에 오면 8시까지. "어차피 집이니까 잠깐만 더" 하다가 10시까지 일한 날도 있었다. 지하철 탈 필요가 없으니까 퇴근의 물리적 행위가 사라진 거다.

침대에서 슬랙을 보는 습관이 생겼다. 아침에 눈 뜨자마자 핸드폰으로 슬랙 확인. 밤에 자기 전에도 확인. 이건 내가 근면해서가 아니라, 혼자 있으니까 놓치는 게 있을까 봐 불안했던 거다. 사무실에서는 중요한 일이 있으면 누가 와서 말해주니까 놓칠 일이 없는데, 재택에서는 슬랙을 안 보면 진짜로 놓친다.

한 달 반쯤 됐을 때 주말에도 "월요일에 뭐 해야 하지" 생각이 자동으로 돌았다. 토요일 아침에 침대에서 일어나자마자 슬랙을 열어봤다. 주말인데. 몸은 집에 있는데 머리는 일에 가 있는 상태. 이건 출근할 때는 없었던 현상이다. 사무실이라는 물리적 공간이 "여기서는 일, 집에서는 쉼"이라는 구분을 만들어줬는데, 재택에서는 24시간 일터에 사는 셈이 됐다.

## 시도한 것들

3개월 동안 나름대로 적응하려고 한 것들이 있다.

아침 루틴을 만들었다. 출근은 안 해도 "출근 의식"을 만들었다. 커피를 내리고, 옷을 갈아입고(운동복이라도 잠옷은 벗기), 책상에 앉아서 노션에 오늘 할 일을 쓴다. 이게 "지금부터 일이다"라는 신호. 잠옷 차림으로 바로 코드를 치면 일과 생활이 더 뒤섞인다.

산책을 넣었다. 점심 먹고 20분 산책. 이건 좀 효과가 있었다. 바깥 공기를 마시는 것만으로도 갇혀 있는 느낌이 좀 줄었다. 사람들이 걸어 다니는 걸 보는 것만으로도 "나도 세상에 살고 있구나" 하는 느낌이 든다. 좀 과장이지만 진짜 그런 기분이었다.

카메라를 켰다. 화상 미팅에서 나만이라도 카메라를 켜기로 했다. 다른 사람은 안 켜도, 나는 켠다. 서로 얼굴을 보면서 이야기하는 게 확실히 다르다. 표정이 보이니까 농담에 웃는 것도 보이고, 고민하는 얼굴도 보이고. 한 명이 켜면 다른 사람도 슬슬 켜기 시작했다.

퇴근 시간을 정했다. 6시 반에 맥북을 닫는다. 닫으면서 노션에 "퇴근"이라고 쓴다. 긴급한 게 아니면 슬랙도 안 본다. 알림도 끈다. 이건 지키기 제일 어려웠다. 지금도 가끔 어기지만, 의식적으로 노력하는 중이다.

## 3개월 후

사무실 이전이 끝나고 다시 주 3일 출근으로 돌아왔다. 첫 출근날, 팀원들 얼굴을 보는데 좀 반가웠다. 화상 미팅에서 매일 봤던 얼굴인데, 실물이 다르다. "아, 사람이다" 하는 느낌. 좀 오글거리긴 한데, 진심이었다.

풀 재택을 경험하고 나서 생각이 복잡해졌다. 재택이 좋기는 좋다. 집중 시간이 확실히 더 길고, 시간 효율도 좋다. 딥 워크가 필요한 날에는 재택이 압도적이다. 근데 사람이 필요하다는 걸도 알게 됐다. 슬랙 텍스트가 아니라, 옆에 앉아서 잡담하는 그런 종류의 사람. 기술 이야기가 아니라 "어제 치킨 시켰는데 맛있었어" 같은 그런 대화.

지금의 주 2일 재택이 나한테는 적당한 것 같다. 재택일에 집중해서 코드를 치고, 출근일에 사람들과 이야기한다. 이 균형이 맞는 거지, 어느 한쪽으로 완전히 기울면 다른 뭔가가 빠진다.

풀 재택을 꿈꾸는 사람들한테 "안 좋다"고 말하고 싶은 건 아니다. 사람마다 다르니까. 외향적인 사람은 더 힘들 수 있고, 내향적인 사람은 오히려 편할 수 있다. 나는 내향적이라고 생각했는데 3개월 풀 재택을 하고 나서 "나는 생각보다 사람이 필요한 사람이구나" 하는 걸 알게 됐다. 다만 외로움은 예상 못 한 곳에서 온다는 건 알아두면 좋겠다.

한 가지 더. 풀 재택 3개월 동안 코드 생산성은 확실히 올라갔다. 집중 시간이 길었으니까. 근데 그게 전부는 아니었다. 코드만 잘 치면 되는 직업이면 풀 재택이 최고였겠지만, 이 일은 결국 사람과 함께 하는 일이다. 기획자와 의도를 맞추고, 디자이너와 UI를 조율하고, 백엔드와 API 스펙을 합의하고. 이런 것들이 텍스트만으로는 한계가 있다는 걸, 3개월 동안 배웠다.


"이거 왜 이렇게 동작하는 건가요?"

신입 한 분이 내 옆자리로 배정됐다. 온보딩 가이드 역할이 나한테 떨어졌다. 입사한 지 1년 반밖에 안 됐는데 후배라니. 팀 리드가 "너도 이제 좀 됐으니까" 하고 자연스럽게 넘겼는데, 속으로는 당황스러웠다. 나도 아직 모르는 게 많은데.

첫날 개발 환경 세팅을 도와주면서 시작했다. Node 버전, 패키지 매니저, 에디터 설정. 여기까지는 괜찮았다. 문제는 코드베이스 설명이었다. "이 프로젝트 구조가 어떻게 되어 있냐면..." 하고 말을 시작했는데, 내 설명이 횡설수설이었다. 머릿속에서는 다 아는 건데 입으로 설명하려니까 어디서부터 시작해야 할지 모르겠더라.

## 아는 것과 설명하는 건 다르다

후배가 두 번째 주에 질문을 했다. "useEffect에서 cleanup 함수가 왜 필요한 거예요?" 나는 매일 useEffect를 쓴다. cleanup도 당연히 쓴다. 근데 "왜"를 설명하려니까 막혔다.

"어... 컴포넌트가 언마운트될 때 정리를 해줘야 하니까." "정리를 안 하면 어떻게 되는데요?" "메모리 릭이 날 수 있어." "어떤 경우에요?"

순간 구체적인 예시가 바로 안 떠올랐다. 대충 알고 있었던 거다. setInterval을 걸어놓고 정리 안 하면 컴포넌트가 사라져도 계속 돌아간다, 이벤트 리스너를 등록하고 해제 안 하면 중복 실행된다, 이런 얘기를 하려면 좀 더 정확하게 알고 있어야 했다. 그날 퇴근하고 React 공식 문서의 useEffect 섹션을 처음부터 다시 읽었다. 1년 반 동안 쓰면서 한 번도 안 돌아봤던 내용이 있더라.

이런 일이 반복됐다. 후배가 질문할 때마다 내가 "감으로 알고 있던 것"과 "정확하게 아는 것"의 차이를 직면하게 됐다. TypeScript의 interface와 type의 차이, Next.js에서 서버 컴포넌트와 클라이언트 컴포넌트의 경계, CSS의 specificity 계산 방법. 전부 매일 쓰면서도 막상 설명하려면 애매한 것들이었다.

## 코드 리뷰가 달라지다

후배의 PR을 리뷰하게 됐다. 처음에는 "어디를 어떻게 봐야 하지?"부터 고민이었다.

첫 번째 PR을 봤는데, 동작은 하지만 구조가 좀 아쉬웠다. 하나의 컴포넌트에 API 호출, 상태 관리, 렌더링이 전부 들어가 있었다. 나도 처음에 그렇게 했으니까 이해는 됐다. 근데 이걸 어떻게 말해야 할지 고민이 됐다. "이거 분리해야 해"라고만 하면 감이 안 올 것 같았다.

고민 끝에 이렇게 코멘트를 달았다. "이 컴포넌트가 하는 일이 세 가지인데, 나중에 로직 수정할 때 어디를 고쳐야 할지 찾기 어려울 수 있어요. API 호출하는 부분을 커스텀 훅으로 빼면 컴포넌트는 렌더링에만 집중할 수 있을 것 같은데 어떻게 생각해요?" 지시가 아니라 제안으로. 근데 이게 의외로 어렵다. "~하세요"와 "~하면 어떨까요?"의 차이가 크다는 걸 이때 알았다.

코드 리뷰를 하면서 나도 많이 배웠다. 다른 사람의 코드를 읽고 "왜 이렇게 했을까"를 생각하고, 더 나은 방법을 찾아서 설명하는 과정에서 내 코드도 나아졌다. 후배 PR에서 발견한 패턴을 내 코드에서도 하고 있었다는 걸 깨달은 적이 한두 번이 아니다.

## 질문을 대하는 자세

처음에는 후배가 질문할 때마다 바로 답을 알려줬다. "아 그거? 이렇게 하면 돼." 빠르게 해결되니까 효율적이라고 생각했는데, 2주쯤 지나니까 같은 유형의 질문이 반복되더라.

시니어한테 조언을 구했더니 이렇게 말하더라. "답을 바로 알려주면 그 순간은 해결되지만, 답을 찾는 방법을 가르쳐주면 다음번에는 혼자 해결해." 그 뒤로는 질문을 받으면 일단 "어디까지 찾아봤어요?"를 먼저 물어봤다. 그리고 "이 키워드로 검색해보면 나올 거예요" 또는 "이 공식 문서 이 섹션을 보면 돼요" 같은 식으로 방향을 잡아줬다.

물론 이게 항상 맞는 건 아니다. 긴급한 버그가 터졌는데 "먼저 찾아보세요"는 말도 안 된다. 상황에 따라 바로 알려줘야 할 때와 스스로 찾게 해야 할 때를 구분하는 게 멘토링의 어려운 부분이다.

한번은 후배가 3시간 동안 혼자 끙끙대고 있었는데 나한테 안 물어보더라. 나중에 물어봤더니 "자꾸 물어보면 귀찮으실까 봐요"라고. 그 말을 듣고 미안해졌다. 내가 "먼저 찾아봐" 모드로만 대응하니까 질문 자체를 부담스러워하게 만든 거다. 그날 커피를 사주면서 말했다. "30분 이상 막히면 바로 물어보세요. 3시간 쓰는 게 더 비효율적이에요."

## 기대치 조절하기

가장 어려웠던 건 내 기대치를 조절하는 거였다. 한 번 설명했으면 이해했을 거라고 생각하는데 다음에 또 비슷한 실수를 한다. 한 번 리뷰에서 지적한 부분이 다음 PR에서 또 나온다.

처음에는 좀 답답했다. "이거 저번에 얘기했는데?" 라는 말이 목까지 올라온 적이 있다. 근데 돌이켜보면 나도 그랬다. 시니어한테 같은 피드백을 두 번 세 번 받은 적이 있었다. 한 번 듣는다고 바로 체화되는 건 아니다. 비슷한 상황을 여러 번 겪으면서 서서히 몸에 배는 거다.

그래서 마음을 바꿨다. "같은 피드백을 반복하는 것도 멘토링의 일부"라고. 두 번째로 같은 지적을 할 때는 첫 번째와 다른 각도로 설명해보려고 한다. "저번에는 이렇게 말했는데, 다시 정리하면 이런 이유 때문이에요." 설명을 바꾸면 이해도가 달라질 때가 있다.

## 후배가 성장하는 걸 보는 느낌

두 달 정도 지나니까 변화가 보이기 시작했다. PR 크기가 작아졌다. 변수 네이밍이 나아졌다. 질문의 수준이 달라졌다. "이거 어떻게 해요?"에서 "이렇게 하려고 하는데, 이 방법이 맞을까요?"로.

어느 날 후배가 올린 PR을 봤는데, 코멘트 없이 approve를 눌렀다. 진짜 고칠 게 없었다. 깔끔했다. 내가 괜히 뿌듯해했다. 내가 한 건 별로 없는데.

가르치면서 배운다는 말이 진부하게 들렸는데, 직접 겪어보니 정말이었다. 후배 때문에 기초를 다시 공부하게 됐고, 설명하는 능력이 늘었고, 코드 리뷰를 보는 눈이 달라졌다. 무엇보다 "나도 아직 모르는 게 많다"는 걸 인정하게 된 게 가장 큰 성장이었다.

## 페어 프로그래밍의 효과

한번 페어 프로그래밍을 해본 적이 있다. 후배가 복잡한 폼 유효성 검사를 구현해야 했는데, 혼자 하기에는 좀 까다로운 케이스였다. "같이 해볼까요?" 하고 화면 공유를 켰다.

나는 네비게이터 역할을 맡고 후배가 드라이버를 했다. 내가 "여기서 먼저 유효성 규칙을 정의하고..."라고 방향을 잡으면, 후배가 직접 코드를 쳤다. 중간에 후배가 "이 부분은 이렇게 하면 어떨까요?"라고 아이디어를 내기도 했다. 2시간 만에 끝났는데, 혼자 했으면 하루 종일 걸렸을 작업이었다.

이때 느낀 건, 가르치는 게 항상 "설명"의 형태일 필요는 없다는 거다. 같이 코드를 짜면서 내 사고 과정을 보여주는 것도 가르침이다. "여기서 나는 이런 순서로 생각했어요"라는 게 교과서보다 더 효과적인 순간이 있다.

## 나도 아직 배우는 중이라는 것

멘토링을 하면서 가장 위험한 태도는 "내가 다 알고 있다"는 착각이다.

후배한테 뭔가를 설명하다가 내가 틀린 적이 있다. CSS Grid에서 `fr` 단위 계산 방식을 잘못 설명했는데, 후배가 "근데 이렇게 해보니까 결과가 다른데요?"라고 했다. 확인해보니 내가 잘못 알고 있었다. 순간 민망했지만 "아 맞다, 내가 잘못 말했다. 고마워"라고 바로 정정했다.

이 순간이 오히려 관계에 좋은 영향을 준 것 같다. 멘토도 틀릴 수 있다는 걸 보여주면 후배도 편해진다. "이 사람도 모르는 게 있구나, 그럼 나도 모르는 게 있어도 괜찮겠다"라는 안도감. 완벽한 멘토보다 솔직한 멘토가 더 좋은 멘토라고 생각한다.

다음에 또 온보딩 담당을 맡게 되면 좀 더 잘할 수 있을까? 잘 모르겠다. 사람마다 다르니까 이번에 통한 방법이 다음에도 통할지는 미지수다. 다만 한 가지 확실한 건, 도망치지 않을 거라는 것. 처음에 느꼈던 "나는 아직 준비 안 됐다"는 감정은, 실제로 해보기 전까지는 절대 사라지지 않는다.


팀 리드가 어느 날 슬랙에 링크를 하나 공유했다. 마이크로 프론트엔드에 대한 기술 블로그 글이었다. "이거 재밌네. 한번 검토해볼까?" 가벼운 톤이었다. 나는 그 링크를 보자마자 흥분했다. 마이크로 프론트엔드. 이름부터 멋지지 않나. 마이크로서비스의 프론트엔드 버전이라니.

당시 우리 팀 상황은 이랬다. 프론트엔드 개발자 세 명, 모놀리식 Next.js 앱 하나. 앱이 점점 커지면서 빌드 시간이 3분을 넘기기 시작했고, 서로 작업한 코드가 충돌하는 일이 잦아졌다. "이 문제를 마이크로 프론트엔드로 풀 수 있지 않을까?"라는 생각이 들었다.

## 일주일간의 리서치

나는 POC를 맡았다. 일주일 동안 마이크로 프론트엔드에 대해 파봤다. 점심시간에도 관련 글을 읽었고, 퇴근 후에도 유튜브에서 관련 발표 영상을 찾아봤다. 새로운 아키텍처를 탐구하는 건 언제나 재미있다. 특히 이게 팀의 공식적인 업무로 주어진 거라면 더.

Module Federation, Single-SPA, iframe 기반, Web Components 기반. 접근 방식이 여러 개였다. Webpack 5의 Module Federation이 가장 많이 언급됐다. 리모트 앱에서 컴포넌트를 노출하면 호스트 앱에서 런타임에 불러오는 구조. 개념은 이해가 됐다.

간단한 데모를 만들어봤다. host 앱이 있고, remote 앱이 있고, remote 앱의 `Header` 컴포넌트를 host에서 불러오는 구조.

```js
// remote app - webpack.config.js
new ModuleFederationPlugin({
  name: 'remoteApp',
  filename: 'remoteEntry.js',
  exposes: {
    './Header': './src/components/Header',
  },
  shared: ['react', 'react-dom'],
})
```

```js
// host app - webpack.config.js
new ModuleFederationPlugin({
  name: 'hostApp',
  remotes: {
    remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
  },
  shared: ['react', 'react-dom'],
})
```

데모는 30분 만에 돌아갔다. "오 이거 되네?" 하면서 팀에 공유했다. 근데 문제는 데모가 아니라 프로덕션이었다.

## 현실의 벽들

데모에서 프로덕션으로 가는 길에 장애물이 쌓이기 시작했다.

첫 번째, 우리는 Next.js를 쓰고 있었다. Module Federation은 기본적으로 Webpack 설정을 직접 제어해야 한다. Next.js의 Webpack 설정을 커스텀하는 것도 가능은 한데, SSR과 Module Federation을 같이 쓰려면 `@module-federation/nextjs-mf` 같은 서드파티 플러그인이 필요했다. 이 플러그인의 GitHub 이슈를 보는데, 열린 이슈가 백 개가 넘었다. Next.js 버전 올리면 깨지는 케이스, SSR에서 hydration 미스매치 나는 케이스, 개발 모드에서만 동작하는 케이스.

두 번째, 공유 상태 관리. 우리 앱은 Zustand로 전역 상태를 관리하고 있었다. 마이크로 프론트엔드로 쪼개면 이 상태를 어떻게 공유하나? Custom Event로? 공유 스토어를 별도로 만들어서? 어떤 방식이든 기존의 심플한 구조보다 복잡해졌다.

세 번째, 스타일 충돌. 앱 A의 CSS가 앱 B의 DOM에 영향을 주는 문제. Shadow DOM을 쓰면 해결되지만, React와 Shadow DOM은 이벤트 전파 문제가 있다. CSS Modules로 스코핑하는 방법도 있는데, 이미 Tailwind를 쓰고 있어서 클래스명 충돌이 생길 수 있었다.

네 번째, 배포. 각 마이크로 앱이 독립 배포된다는 게 장점이라고 하는데, 독립 배포를 하려면 각 앱마다 CI/CD 파이프라인이 필요하다. 프론트엔드 세 명인 팀에서 여러 개의 배포 파이프라인을 관리하는 게 과연 효율적인가?

## 팀 미팅에서의 논의

POC 결과를 팀에 공유하는 미팅을 했다. 데모를 보여주고, 장단점을 정리해서 발표했다. 시니어가 질문을 하나 했다.

"지금 우리가 겪고 있는 문제가 뭐야?"

빌드 시간이 길다. 코드 충돌이 자주 난다.

"빌드 시간은 Next.js 14에서 Turbopack 쓰면 많이 개선될 것 같은데. 코드 충돌은 폴더 구조를 좀 정리하면 줄어들지 않을까?"

맞는 말이었다. 우리가 겪고 있는 문제를 해결하는 방법이 반드시 마이크로 프론트엔드일 필요는 없었다. 그건 여러 해결책 중 하나였고, 가장 비용이 큰 해결책이었다.

팀 리드가 정리했다. "마이크로 프론트엔드는 여러 팀이 하나의 페이지를 독립적으로 개발/배포해야 할 때 의미가 있다. 우리는 한 팀이고, 한 프로덕트를 만들고 있다. 지금은 아닌 것 같다."

## 대신 한 것들

마이크로 프론트엔드를 도입하는 대신, 기존 모놀리스를 정리하는 데 시간을 썼다.

폴더 구조를 feature 기반으로 재정리했다.

```
src/
  features/
    auth/
      components/
      hooks/
      api/
    dashboard/
      components/
      hooks/
      api/
    settings/
      components/
      hooks/
      api/
  shared/
    components/
    hooks/
    utils/
```

이전에는 `components/`, `hooks/`, `utils/` 같은 기술 기반 폴더 구조였는데, feature 기반으로 바꾸니까 서로의 작업 영역이 명확해졌다. 내가 auth를 작업하는 동안 동료가 dashboard를 건드려도 충돌이 거의 안 났다.

빌드 시간은 Next.js를 업데이트하고 Turbopack을 개발 환경에 적용하면서 체감상 절반으로 줄었다. 프로덕션 빌드도 불필요한 의존성을 정리하고 dynamic import를 적극적으로 쓰면서 개선됐다.

결과적으로, 마이크로 프론트엔드 없이도 원래 겪던 문제가 대부분 해결됐다.

추가로, barrel export(`index.ts`에서 feature별 public API만 내보내는 패턴)를 도입하면서, feature 간 의존성을 명시적으로 관리할 수 있게 됐다. `dashboard/components/SomeChart`를 `auth` 폴더에서 직접 import하는 걸 ESLint 규칙으로 막았다. feature 경계를 코드 레벨에서 강제하니까, 모놀리스인데도 느슨한 결합이 어느 정도 가능했다.

이 과정에서 깨달은 건, 폴더 구조와 import 규칙만 잘 잡아도 코드베이스의 복잡도를 상당히 낮출 수 있다는 거다. 마이크로 프론트엔드가 해결하려는 문제의 일부를 훨씬 적은 비용으로 해결한 셈이었다.

## 마이크로 프론트엔드가 필요한 팀

이후에 커뮤니티에서 마이크로 프론트엔드를 실제로 쓰는 팀의 이야기를 들었다. 대부분 이런 특징이 있었다. 프론트엔드 팀이 여러 개다. 각 팀이 서로 다른 배포 주기를 갖는다. 하나의 페이지에 여러 팀의 코드가 들어간다. 쿠팡 같은 대형 이커머스의 상품 상세 페이지 같은 경우. 상단 영역은 A팀, 리뷰는 B팀, 추천 상품은 C팀.

이런 조직 구조에서는 마이크로 프론트엔드가 말이 된다. 조직적 문제를 기술로 풀어야 하는 상황이다. 하지만 프론트엔드 개발자가 세 명이고 커피 한잔 하면서 "나 이 파일 수정할 건데 괜찮지?" 할 수 있는 팀이라면, 그건 그냥 대화로 풀면 되는 문제다.

## 기술 선택에 대한 교훈

이 경험에서 배운 건, 기술을 도입할 때 "이 기술이 멋진가"가 아니라 "이 기술이 지금 우리 문제를 풀어주는가"를 먼저 물어야 한다는 거다. 뻔한 말처럼 들리겠지만, 실제로 그 순간에는 쉽지 않다. 새로운 기술은 늘 매력적이다. 기술 블로그에 올리면 조회수도 잘 나온다. 이력서에도 한 줄 추가할 수 있다.

팀 리드가 그 링크를 공유했을 때 "한번 검토해볼까?"라고 한 건, 도입하자는 게 아니라 정말 검토만 해보자는 뜻이었다. 검토한 결과 "안 하는 게 낫다"가 나왔고, 그게 올바른 결론이었다. 기술 검토의 결과가 항상 도입일 필요는 없다. "안 한다"도 충분히 가치 있는 결론이다.

가끔 그때 만든 Module Federation 데모 레포를 열어본다. 잘 돌아가는 데모. 근데 프로덕션에는 안 갔다. 그래서 좋았다고 생각한다. 언젠가 팀이 커지고 조직이 분화되면 그때 다시 꺼내볼 수도 있겠지. 그전까지는 서랍 속에 잘 모셔두는 거다.


회사에 다닌지 2년이 넘었고, 최근 개발을 하다가 느낀 점이 하나 있다. 스타트업이라 빠르게 구현해야 했던 환경에서 새로운 구현 방식에 대한 두려움이 생기고, 그에 따라 알지 못했던 방식에 대한 학습도 굉장히 적었다는 것이다.

처음에는 모든 게 새로웠고, 모르는 것에 대한 호기심이 컸다. 하지만 시간이 지나면서 익숙한 방식으로만 문제를 해결하려는 습관이 생겼고, 그 과정에서 '이미 아는 것'에 안주하게 되었다. 새로운 기술이나 패턴을 접할 때도 제품이나 QA 과정에 혹여나 문제가 생길까봐 두려움이 먼저 들었다. 코드리뷰 문화가 있긴 하지만, 그것만으로는 개인적 성장에 충분하지 않았다고 생각했다.

그런데 이게 바로 성장을 멈추게 하는 함정이었다. 익숙함에 안주하면 당장은 편할 수 있지만, 결국 기술의 흐름에서 뒤처지게 된다. 더 중요한 건, 그런 마음가짐이 학습에 대한 열정을 잃게 만든다는 점이다. 어제의 나와 오늘의 나가 똑같다면, 내일도 똑같을 것이다.

성장하는 사람이 되려면, 편안함보다는 호기심을 선택해야 한다. 모르는 것에 대한 두려움보다는 배울 수 있다는 기대감을 가져야 한다. 물론 모든 새로운 것을 무작정 받아들일 필요는 없지만, 최소한 '이해해보고 적용해보려는 마음'은 유지해야 한다.

지금부터라도 그 마음을 되찾아야겠다.

## 학습 속도가 중요한 시대

점점 더 기존 지식보다 "학습 속도"가 중요한 시대가 오고 있다. 특히 개발자에게는 더욱 그렇다고 생각한다.

현업에서 2년이 넘는 시간 동안 많은 문제들을 해결해왔는데, 대부분의 경우 이전 지식을 활용하기보다는 그 문제 상황에 대한 이해와 해결할 수 있는 기술을 새로 학습하는 것이 필요했다.

강동윤 개발자님의 [개발자가 AI 시대에서 필요한 능력](https://kdy1.dev/2025-9-30-developer-in-ai-era)을 보고 많은 부분이 공감되었다.

- 모든 것을 다 알아야한다는 태도는 반드시 버릴 것.
- 큰 프로젝트 여러 개를 동시에 해야하는 경우 국소적 이해로 코딩하는 능력이 필수임.

이 두 가지 문장이 특히 와닿았다.

AI를 통하든, 문서를 읽든, 필요한 부분을 파악하고 그 순간에 맞게 학습하는 능력이 이제 개발자에게 필수적인 역량이 되었다. 모든 것을 미리 알아두는 것보다, 필요할 때 빠르게 이해하고 적용할 수 있는 능력이 더 중요해진 시대다.



입사 첫 달 월급이 들어왔을 때 통장을 열어보고 "어?" 했다. 연봉을 12로 나눈 금액이 아니었다. 세금, 4대 보험, 기타 공제를 빼고 나니까 예상보다 훨씬 적었다. 실수령액이라는 개념을 그때 처음 체감했다. 대학교 때 연봉 계산기를 돌려봤을 때와 달랐다. 계산기는 세전이었고 통장은 세후였다.

개발자 커뮤니티에서 기술 얘기는 하루 종일 한다. 근데 돈 얘기는 잘 안 한다. 연봉이 얼마인지, 주식을 어떻게 관리하는지, 이직할 때 협상을 어떻게 하는지. 이런 주제가 나오면 분위기가 어색해진다.

돈은 일하는 가장 큰 이유 중 하나인데, 그게 왜 말하기 어려운 주제인 걸까.

## 같은 역할, 3배의 차이

이직을 준비하면서 충격적인 사실을 알게 됐다. 같은 "프론트엔드 시니어" 타이틀인데, 회사에 따라 총 보상이 3~4배 차이 난다. 이건 느낌이 아니라 데이터가 있는 이야기다.

테크 업계 보상 구조를 연구하는 한 엔지니어 출신 저자가 이런 개념을 제시한 적이 있다. 기업의 보상 체계가 대략 세 개의 층으로 나뉜다는 거다.

첫 번째 층. 소프트웨어가 핵심이 아닌 회사의 IT 부서, 작은 스타트업의 초기 단계. 개발자를 비용으로 본다. 여기서 시니어 프론트엔드의 연봉이 X라고 하자.

두 번째 층. 기술 기반 중견 회사, 성장기 스타트업, 잘 나가는 국내 IT 기업. 개발자를 성장 동력으로 본다. 여기서 같은 역할의 보상이 1.5X~2X 정도.

세 번째 층. 글로벌 빅테크, 잘 나가는 외국계 기업. 개발자를 핵심 경쟁력으로 본다. 여기서 같은 역할의 보상이 3X~4X.

같은 기술 스택, 같은 경력 연차, 비슷한 업무를 하는데 회사가 어느 층에 속하느냐에 따라 보상이 완전히 달라진다. 이걸 모르면 자기 시장 가치를 심각하게 오판할 수 있다.

커뮤니티에서 "연봉 얼마 받는다"는 글을 볼 때 위축될 필요가 없는 이유도 여기에 있다. 세 번째 층에 있는 사람이 자기 보상을 공유하면 그게 평균처럼 보인다. 근데 그건 세 번째 층의 평균이지 업계의 평균이 아니다. 연봉이 높은 사람이 글을 더 많이 쓰니까 선택 편향이 생긴다.

중요한 건, 이 세 개의 층이 존재한다는 사실을 아는 것이다. 그리고 원한다면 위의 층으로 옮길 수 있다는 것도.

## RSU라는 이름의 함정

IT 업계에서 총 보상(Total Compensation) 이야기를 하면 반드시 나오는 게 RSU(양도제한조건부주식)다. 기본 연봉은 비슷한데 RSU를 많이 붙여서 총 보상을 키우는 구조. 4년에 걸쳐 베스팅되는 조건으로.

RSU에는 함정이 있다.

첫째, RSU는 확정 수입이 아니다. 주가에 연동된다. 입사할 때 주가 10만 원 기준으로 100주를 받았다고 하자. 연 25주씩 베스팅. 1년 후 주가가 5만 원이면? 기대했던 가치의 절반이다. 반대로 20만 원이 되면 2배지만, 어느 쪽이 될지는 아무도 모른다.

둘째, 베스팅 시점에 세금을 낸다. RSU가 베스팅되면 그 시점의 시가로 근로소득세가 부과된다. 주식이 현금이 아닌데 현금처럼 세금을 매기는 거다. 주가 10만 원짜리 25주가 베스팅되면 250만 원이 소득으로 잡히고, 그에 해당하는 세금을 내야 한다. 근데 주식을 안 팔았으니까 세금은 현금으로 내야 한다. 주식을 팔아서 세금을 내면 남는 주식이 줄어든다.

셋째, 4년 베스팅은 곧 4년 잠금이다. 1년 차에 퇴사하면 나머지 3년분은 증발한다. 이게 설계된 금덩이 수갑이다. 회사가 마음에 안 들어도 "RSU가 아까워서" 남게 된다. 커리어 결정을 보상이 아니라 성장 기준으로 해야 하는데, RSU가 그 판단을 왜곡한다.

스톡옵션은 또 다른 이야기다. 스타트업에서 주는 스톡옵션은 특정 가격에 주식을 살 수 있는 "권리"인데, 회사가 상장하거나 인수되지 않으면 행사할 데가 없다. 종이 위의 숫자일 뿐. 물론 잘 되면 대박이다. 근데 스타트업의 대부분은 잘 안 된다. 이건 복권과 비슷한 면이 있다. 스톡옵션의 기대값을 0으로 놓고 다른 조건을 평가하는 게 현실적이다.

## 돈에 대한 심리

돈에 대한 글을 많이 쓰는 한 금융 칼럼니스트의 글 중에 이런 취지의 문장이 있었다. "부자처럼 보이려고 돈을 쓰면, 진짜 부자가 될 확률은 낮아진다." 쓰는 돈이 늘면 모으는 돈이 줄고, 모으는 돈이 줄면 부의 증가 속도가 느려지고, 그러면 더 오래 일해야 하고. 악순환이다.

이걸 개발자 문화에 적용하면 보이는 게 있다. 맥북 프로 최고 사양, 최신 아이폰, 기계식 키보드 3개, 모니터 2대, 스탠딩 데스크. 개발자 사이에서 장비에 돈 쓰는 게 일종의 문화처럼 되어 있다. 물론 장비가 생산성에 영향을 미치는 건 맞다. 근데 솔직히, 키보드를 3개 살 필요는 없었다. 쓰는 건 하나인데. 나머지 두 개는 "개발자니까 키보드 좀 써봐야지"라는 심리로 산 거다.

그 칼럼니스트의 다른 글에서는 이런 개념도 있었다. 부를 쌓는 유일한 방법은 자존심과 수입 사이에 간격을 두는 거라고. 돈을 벌 수 있는 능력과 돈을 쓰고 싶은 욕구 사이의 차이가 저축이고, 저축이 부의 원천이라고. 연봉이 올라도 생활 수준을 같이 올리면 순자산은 제자리다.

이 원리가 개발자한테 특히 위험한 이유가 있다. 이직할 때마다 연봉이 크게 점프하는 업계 특성 때문이다. 3,000에서 4,500으로, 4,500에서 6,000으로. 올라갈 때마다 생활 수준을 맞추면 6,000 받으면서 3,000 받을 때와 같은 여유를 느낀다. 숫자만 커졌을 뿐 구조가 안 바뀐 거다.

## 비상금이 먼저다

재테크 유튜브를 보면 "이 종목에 투자하라", "이 ETF를 사라" 같은 이야기가 많다. 근데 투자보다 먼저 해야 할 게 있다. 비상금.

갑자기 회사가 구조조정을 하면? 건강 문제로 6개월 쉬어야 하면? 월급의 3~6개월치를 비상금으로 갖고 있어야 한다. 이건 투자 수익률 0%짜리 돈이다. 이자도 거의 안 붙는 통장에 그냥 놔두는 돈. 근데 이 돈이 있으면 커리어 결정을 할 때 "당장 돈이 필요하니까"가 아니라 "내 성장에 맞는 선택"을 할 수 있다.

위에서 말한 금융 칼럼니스트가 빚에 대해서도 쓴 적이 있다. 빚의 진짜 비용은 이자가 아니라 유연성의 상실이라고. 50년의 인생 동안 경기 침체, 건강 위기, 커리어 전환 같은 큰 충격이 올 확률은 100%에 가깝다. 빚이 없고 비상금이 있으면 이 충격을 견딜 수 있다. 빚이 있으면 작은 충격에도 무너진다. 500년 넘게 살아남은 일본의 오래된 기업들의 공통점이 뭔지 아는가? 현금을 넉넉하게 쌓아두고 빚을 지지 않는 거라고 한다.

개발자의 비상금은 단순히 생활비의 문제가 아니다. 커리어의 자유도다. 비상금이 6개월치 있으면, 마음에 안 드는 회사에서 "RSU가 아까워서" 버티지 않아도 된다. 면접을 보면서 "연봉 깎여도 이 팀에서 일하고 싶다"는 선택을 할 수 있다. 사이드 프로젝트에 3개월을 투자할 여유도 생긴다. 돈이 있어서 자유로운 게 아니라, 돈 걱정이 없어서 자유로운 거다.

## 투자보다 지출 관리

입사 초기 1년의 재무 상태는 참담했다. 월급이 들어오면 생활비로 나가고, 남는 건 없었다. 적금도 안 들었다. "나중에 해야지" 하다가 1년이 지나갔다.

정신을 차리고 한 첫 번째 일이 지출 추적이었다. 앱으로 카드 사용 내역을 분류해봤다. 한 달 치를 보니까 어디서 돈이 새는지 보였다. 충동 구매가 문제였다. 야근하고 스트레스받으면 쿠팡에서 불필요한 걸 주문했다. 키보드 3개, 사용하지 않은 온라인 강의 2개, 한 번 쓰고 안 쓴 가젯들. 한 달 충동 구매 금액이 월급의 15%에 달했다.

두 번째로 한 건 자동이체 설정이었다. 월급이 들어오면 일정 금액이 자동으로 빠지게. "남으면 저축한다"가 아니라 "저축하고 남은 걸 쓴다"로 구조를 바꿨다. 이것도 뻔한 말이지만 효과가 확실했다. 행동을 바꾸려면 의지가 아니라 구조를 바꿔야 한다는 건 습관의 영역에서도 재무의 영역에서도 똑같이 적용된다.

투자는 조심스럽게 시작했다. 개별 주식은 하지 않는다. 시장을 이길 수 있다는 확신이 없다. S&P 500 ETF를 매달 일정 금액씩 적립식으로 사고 있다. 수익률이 대단한 건 아닌데, 목표가 대박이 아니라 물가상승률을 이기는 거다. 투자에 시간을 많이 쓸 여유가 없으니까, 가장 단순한 방법을 택한 거다. 투자에 쓰는 시간을 코딩 실력을 올리는 데 쓰는 게 장기적으로 더 높은 수익률이라고 생각한다.

퇴직연금도 방치하면 안 된다. DC형(확정기여형)이면 매달 적립금을 어디에 투자할지 직접 선택해야 한다. 처음에는 뭔지도 모르고 원리금보장형(사실상 예금)으로 놔뒀다. 6개월 뒤에야 "이걸 그냥 놔두면 물가상승률도 못 따라간다"는 걸 알았다. 지금은 TDF(Target Date Fund)에 넣고 있다.

## 연봉 협상에 대해

첫 직장의 연봉은 협상이랄 게 없었다. 제시된 금액을 받았다. "이 금액에서 조율이 가능한가요?"라는 한마디를 못 했다. 기회를 놓치면 안 된다는 마음이 컸고, "돈 얘기를 하면 나쁜 인상을 주지 않을까"라는 두려움이 있었다.

두 번째 이직에서는 달랐다. 현재 연봉과 시장 가치를 조사했다. 동일 연차, 동일 기술 스택의 다른 회사 보상 범위를 파악했다. 그리고 면접 과정에서 보상에 대해 먼저 물어봤다. "이 포지션의 보상 범위가 어떻게 되나요?"

돌아온 답에서 기본 연봉, 사이닝 보너스, RSU, 연차 보너스를 분리해서 봤다. 기본 연봉만 보면 비슷해 보이는 두 회사가, 총 보상으로 보면 30% 차이 나는 경우가 있다. RSU를 많이 주는 대신 기본 연봉을 낮추는 회사도 있고, RSU 없이 기본 연봉과 보너스로 가는 회사도 있다.

"돈보다 성장이 중요하다"는 말을 자주 듣는다. 맞는 말이지만 함정이 있다. 성장과 적정 보상은 대립하지 않는다. 좋은 팀에서 좋은 기술을 쓰면서 적정한 보상을 받는 게 가능하다. 그리고 그걸 추구하는 게 당연하다. "성장이 중요하다"가 "돈은 중요하지 않다"가 되면 안 된다. 둘 다 중요하다.

다만 연봉만 보고 이직하면 위험하다. 동기 중 하나가 연봉을 30% 올려서 이직했는데, 3개월 만에 나왔다. 매일 야근, 코드 리뷰 문화 부재, 산더미 기술 부채. 연봉은 올랐지만 번아웃이 왔고, 다시 이직하면서 프로필에 3개월짜리 경력이 남았다. 연봉 30% 인상이 3개월 만에 경력 오점으로 바뀐 거다.

## 돈 얘기를 하자

개발자 커뮤니티에서 돈 얘기를 더 편하게 할 수 있으면 좋겠다. "돈 얘기는 속물적이다"라는 인식이 있는 것 같은데, 돈은 노동의 대가다. 내가 만드는 프로덕트가 회사에 수익을 가져다주고, 회사는 그 수익의 일부를 나에게 지급한다. 이 관계에서 적정한 보상을 받고 있는지 고민하는 건 당연하다.

특히 같은 역할이 회사에 따라 3~4배 차이 나는 업계에서, 자기 시장 가치를 모르는 건 손해다. 세 번째 층의 보상을 받을 실력이 있는데 첫 번째 층에서 "여기도 괜찮은데"라고 안주하고 있을 수 있다. 정보가 없으면 이 사실 자체를 모른다.

돈이 전부는 아니다. 근데 돈이 중요하지 않은 척하는 것도 건강하지 않다. 부자처럼 보이려고 돈을 쓰는 것도, 돈을 무시하는 척하면서 속으로는 불안해하는 것도 둘 다 돈과의 건강하지 못한 관계다.

돈의 진짜 가치는 물건을 사는 능력이 아니라, 시간에 대한 통제권이다. 비상금이 있으면 마음에 안 드는 회사를 떠날 자유가 생긴다. 지출이 적으면 연봉이 낮아도 불안하지 않다. 투자가 꾸준히 쌓이면 언젠가 "일하고 싶어서 일한다"는 선택을 할 수 있게 된다.

월급날이 되면 통장을 확인하고, 자동이체가 잘 됐는지 보고, 투자 수익률을 잠깐 확인한다. 5분이면 끝나는 루틴. 이 5분이 10년 뒤의 자유를 만든다고 믿는다.


작년에 사이드 프로젝트로 MVP를 만들겠다고 했다. 프리랜서 개발자들이 프로젝트를 관리할 수 있는 간단한 대시보드. 기능은 단순했다. 진행 중인 프로젝트 목록, 마감일, 입금 여부 체크. Notion으로 해도 되는 수준이었다.

3주 뒤 내 프로젝트 구조를 보자.

모노레포. Turborepo로 세팅해서 packages 폴더 안에 ui 라이브러리, shared utils, 타입 정의 패키지를 분리했다. 디자인 시스템 패키지에는 Button, Input, Modal, Toast 컴포넌트가 Storybook과 함께 들어있었다. 백엔드는 별도 서비스로 분리할 계획이라 API 게이트웨이 패턴을 준비 중이었다. 테스트 커버리지 목표는 80%.

사용자 수: 0명.

이게 개발자가 MVP를 만들 때 가장 자주 하는 실수의 전형이다. MVP의 M이 Minimum이라는 걸 잊어버린다.

## 과잉 설계의 유혹

왜 이렇게 되는 걸까. 단순하다. 우리에게는 "좋은 코드"에 대한 기준이 있으니까. 회사에서 코드 리뷰를 하고, 기술 블로그를 읽고, 컨퍼런스 발표를 들으면서 내재화한 기준. 관심사 분리, 재사용 가능한 컴포넌트, 확장 가능한 아키텍처, 적절한 테스트 커버리지.

이 기준 자체는 나쁘지 않다. 팀에서 장기간 유지보수할 프로덕션 코드에는 필요하다. 문제는 이 기준을 MVP에도 적용한다는 거다. MVP는 "이 제품이 의미가 있는가?"를 확인하는 실험이다. 실험에 프로덕션 수준의 코드 품질은 필요 없다.

Paul Graham이 쓴 "Do Things That Don't Scale"에서 인상적인 부분이 있다. Airbnb 초기에 창업자들이 뉴욕의 호스트를 한 명씩 직접 방문해서 사진을 찍어줬다고 한다. 확장 가능한 방식이 전혀 아니다. 근데 그게 효과가 있었고, 사용자가 늘어나면서 나중에 자동화했다. 처음부터 "사진 자동 보정 AI 시스템"을 만들었으면 어땠을까. 제품이 출시도 되기 전에 기술에 매몰되어 있었을 거다.

Stripe도 비슷하다. Stripe의 창업자인 Collison 형제가 초기에 한 일은, 잠재 고객한테 직접 찾아가서 결제 시스템을 대신 연동해주는 거였다. API 문서를 보내고 "알아서 연동하세요"가 아니라, 노트북을 들고 가서 그 자리에서 세팅했다. 이걸 "Collison installation"이라고 부른다. 확장 불가능하지만, 초기 사용자의 진짜 니즈를 몸으로 배우는 과정이었다.

## 진짜 MVP는 어떤 모습인가

내가 아는 한 시니어 개발자가 퇴사하고 만든 서비스가 있다. 소규모 쇼핑몰 사장님들이 인스타그램 DM으로 주문을 받을 때 쓰는 자동화 도구. 첫 버전의 구현이 어땠냐면.

프론트엔드: 없었다. 말 그대로 없었다.

사장님이 주문 양식을 구글 폼으로 만들어서 인스타 프로필에 링크를 건다. 주문이 들어오면 구글 시트에 자동으로 쌓인다. 그 시니어가 만든 건, 구글 시트의 데이터를 읽어서 택배사 API에 송장 등록을 해주는 Apps Script 하나였다.

이게 MVP였다. 기술적으로는 초라하다. 근데 이 MVP로 확인한 게 있다. "쇼핑몰 사장님들이 DM 주문 처리에 시간을 엄청 쓰고 있고, 이걸 자동화하면 돈을 낼 용의가 있다"는 사실. 첫 달에 유료 사용자 8명이 붙었다. 월 3만 원씩.

여기서 중요한 건, 사장님들은 그 뒤에 Apps Script가 돌아가는지, 서버리스 함수가 돌아가는지, 마이크로서비스가 돌아가는지 전혀 신경 안 쓴다는 거다. 자기 일이 줄어드는지만 본다.

이 시니어가 프론트엔드를 만들고, 대시보드를 만들고, 제대로 된 서비스로 확장한 건 유료 사용자가 30명을 넘긴 후였다.

## MVP에 필요 없는 것들 목록

구체적으로 적어본다. MVP 단계에서 내가 시간을 썼지만 필요 없었던 것들.

**디자인 시스템.** 버튼 컴포넌트의 variant를 primary, secondary, ghost, outline으로 나누고 사이즈를 sm, md, lg, xl로 만들 필요가 없다. 그냥 하나면 된다. 색깔도 하나면 된다. Tailwind UI나 shadcn/ui에서 필요한 것만 복붙해서 쓰면 된다. 디자인 일관성은 사용자가 100명 넘으면 그때 고민해도 늦지 않다.

**마이크로서비스.** 사용자가 0명인 서비스에 마이크로서비스 아키텍처는 모순이다. 모놀리스로 충분하다. 사실 모놀리스도 과하다. 서버리스 함수 몇 개로 될 수도 있다. 아니면 위에서 본 것처럼 Google Apps Script로 될 수도 있다.

**100% 테스트 커버리지.** 핵심 비즈니스 로직에 대한 최소한의 테스트면 된다. 결제 금액 계산이 맞는지, 데이터가 유실되지 않는지 정도. 나머지는 직접 클릭해보면서 확인하면 된다. 사용자가 적을 때는 버그가 나도 빠르게 고치면 된다.

**인증 시스템 직접 구현.** OAuth 플로우를 직접 만들 필요가 없다. NextAuth든 Clerk든 Auth0든, 기존 서비스를 쓰면 된다. 아니, 초기에는 이메일과 비밀번호로 가입하는 것 자체가 사용자한테 허들이다. 비밀번호 없이 이메일 매직 링크로 가는 게 낫다. 아니면 더 과감하게, MVP 단계에서 인증 자체가 필요한지를 다시 생각해봐야 한다.

**CI/CD 파이프라인.** Vercel에 연결하면 git push만 하면 배포된다. GitHub Actions로 정교한 파이프라인을 구성하는 건 팀이 생긴 후에 해도 된다.

**반응형 디자인.** 타겟 사용자가 모바일 위주인지 데스크톱 위주인지 파악하고, 한쪽만 먼저 만든다. 둘 다 지원하려면 시간이 배로 든다.

First Round Review에서 본 문장이 있다. "No company swag until the business has at least $250K of revenue or 250k users." 매출 25만 달러나 사용자 25만 명이 될 때까지 회사 굿즈를 만들지 말라는 거다. 사업의 느낌이 나는 것들에 시간을 쓰지 말고 본질에 집중하라는 뜻인데, 개발자한테는 이렇게 번역할 수 있다. "유료 사용자가 50명이 될 때까지 아키텍처 리팩토링을 하지 마라."

## "나중에 갈아엎어야 하면 어떡해" 증후군

이 반론이 항상 나온다. "지금 대충 만들면 나중에 기술 부채 때문에 힘들어지지 않냐?" 맞다. 힘들어진다. 근데 그 "나중"이 올 확률이 얼마나 될까.

대부분의 사이드 프로젝트는 유료 사용자를 한 명도 만들지 못하고 죽는다. 정성 들여 짠 클린 코드가 아무도 안 쓰는 레포에서 먼지를 쌓고 있다. 그 코드를 갈아엎을 일이 없다. 애초에 쓰는 사람이 없으니까.

기술 부채가 문제가 되는 건, 서비스가 성장해서 사용자가 늘고 팀원이 들어왔을 때다. 이건 좋은 문제다. 사용자가 늘어서 코드를 리팩토링해야 하는 상황은, 아무도 안 쓰는 깨끗한 코드보다 100배 낫다.

Sam Altman이 "Plans should be measured in decades, execution should be measured in weeks"라고 했다. 장기적 비전은 크게 갖되, 실행은 주 단위로 하라는 거다. MVP는 이 "주 단위 실행"의 결과물이어야 한다. 몇 달이 걸리면 이미 MVP가 아니다.

## 개발 시간 vs 검증 시간

내가 사이드 프로젝트에 투자한 시간을 돌아보면 이렇다.

기술 스택 선정: 3일. 프로젝트 세팅: 2일. 디자인 시스템 구축: 1주. 핵심 기능 개발: 2주. 부가 기능 개발: 2주. 배포 환경 구성: 2일. 랜딩 페이지: 3일.

총 약 6주.

이 6주 동안 잠재 사용자와 대화한 시간: 0시간.

이게 문제다. 6주를 들여서 만든 게 사람들이 원하는 건지 아닌지를, 만들고 나서야 확인하려 한다. 만약 2주 차에 사용자 인터뷰를 했으면? 기능의 절반은 필요 없다는 걸 알았을 수도 있다. 아예 방향을 틀었어야 한다는 걸 알았을 수도 있다.

이상적인 비율은 뒤집어져야 한다. 만드는 시간보다 확인하는 시간이 더 많아야 한다. 1주일에 3일은 만들고, 4일은 사람들한테 보여주고 피드백을 받는다. 물론 현실적으로 재직 중에 이 비율을 맞추긴 어렵다. 근데 최소한 "만드는 시간 100%, 확인하는 시간 0%"에서는 벗어나야 한다.

First Round Review에서 읽은 또 다른 조언이 있다. "You'll know you understand the customer problem enough when you can predict 75% of what a customer tells you." 고객이 말할 내용의 75%를 예측할 수 있으면 문제를 충분히 이해한 거라는 뜻이다. 이 수준에 도달하려면 코드를 짜는 게 아니라 사람을 만나야 한다.

## 실용적인 MVP 접근법

지금 만들고 있는 사이드 프로젝트가 있다면, 이렇게 해보면 어떨까.

기능 목록을 적는다. 다 적는다. 그리고 절반을 지운다. 남은 것에서 또 절반을 지운다. 그래도 제품이 성립하면, 처음 지운 75%는 MVP에 필요 없었던 거다.

기술 스택은 가장 익숙한 걸로 한다. 새로운 기술을 배우면서 MVP를 만드는 건, 두 개의 불확실성을 동시에 안고 가는 거다. "이 기술이 내 프로젝트에 맞을까?"와 "이 제품이 시장에 맞을까?"를 동시에 검증하면 어느 쪽이 실패한 건지 구분할 수 없다.

데드라인을 건다. 2주. 길어도 4주. 그 안에 사람한테 보여줄 수 있는 뭔가가 나와야 한다. 데드라인이 있으면 자연스럽게 스코프가 줄어든다. "이것도 넣고 싶은데 시간이 없으니까 다음에" 가 된다. 이 "다음에"가 대부분 영원히 안 와도 괜찮다.

그리고 가장 중요한 건, "부끄러운 수준"에서 공개하는 거다. LinkedIn의 공동창업자 Reid Hoffman이 "If you are not embarrassed by the first version of your product, you've launched too late"라고 했다. 첫 버전이 부끄럽지 않으면 너무 늦게 출시한 거라는 뜻이다.

내가 완벽주의를 버리게 된 계기가 있다. 어떤 서비스의 초기 버전 스크린샷을 봤는데, CSS가 깨져 있고, 폰트가 기본 폰트이고, 여백이 들쭉날쭉했다. 근데 사용자가 있었다. 돈을 내는 사용자가. 결국 중요한 건 디자인이 예쁜지가 아니라, 문제를 해결하는지다.

MVP는 질문이다. "이걸 원하는 사람이 있나?" 그 질문에 대한 답을 가장 빠르게 얻는 방법이 좋은 MVP다. 코드의 양이 아니라 학습의 양으로 측정해야 한다.


컨퍼런스에 처음 갔을 때 일이다. 발표가 끝나고 네트워킹 시간이라는 게 있었다. 사람들이 삼삼오오 모여서 대화하는데, 나는 구석에서 커피만 마시고 있었다. 핸드폰을 꺼내서 슬랙을 확인하는 척하면서 30분을 버텼다. 그리고 그냥 나왔다.

밖에 나와서 "네트워킹을 해야 하는데 왜 못 하는 걸까" 자괴감이 들었다. 모르는 사람한테 먼저 다가가서 "안녕하세요, 저는 프론트엔드 개발자인데요"라고 말하는 게 물리적으로 불가능했다. 팀 회식에서도 이미 아는 사람 옆에만 앉는 타입이다. MBTI 검사를 할 때마다 I가 90% 넘게 나온다.

그러다 1년쯤 지나서 깨달은 게 있다. 내가 못 하는 건 "네트워킹"이 아니라 "네트워킹이라는 이름이 붙은 그 행위"였다. 명함을 돌리고, 자기소개를 하고, 약한 유대를 넓게 만드는 그 방식. 나한테는 그게 안 맞았을 뿐이다. 관계를 만드는 방법은 그것만 있는 게 아니었다.

## 디스코드 질문 하나에서 시작된 일

어느 날 디스코드 프론트엔드 커뮤니티에서 누군가가 질문을 올렸다. Next.js에서 SSR과 CSR 사이의 하이드레이션 미스매치 에러를 해결하지 못하겠다는 거였다. 에러 메시지를 붙여놨는데, 내가 2주 전에 똑같은 에러를 겪고 해결한 적이 있었다. 원인은 Date 객체가 서버와 클라이언트에서 다른 타임존으로 렌더링되는 거였다.

10분 정도 들여서 답을 적었다. 에러의 원인, 내가 시도했던 것들, 최종 해결 방법, 그리고 비슷한 케이스에 대한 공식 문서 링크까지. 별생각 없이 적은 거였다.

그 사람이 고맙다고 DM을 보내왔다. 거기서 끝났어야 하는데, 우연히 같은 스택을 쓰고 있다는 걸 알게 됐다. Next.js + TypeScript + Tailwind. 가끔 기술적인 질문을 주고받게 됐다. 3개월 정도 그렇게 지냈다. 그러다 6개월쯤 후에 그 사람이 연락을 했다. "우리 회사에서 프론트엔드 시니어를 뽑고 있는데 혹시 관심 있어?" 레퍼럴이었다.

이게 네트워킹이다. 명함을 돌린 게 아니다. 컨퍼런스에서 자기소개를 한 게 아니다. 누군가의 질문에 진심으로 도움이 되는 답을 적었고, 거기서 자연스럽게 관계가 만들어졌고, 6개월 뒤에 기회가 왔다.

## "유용한 사람"이 되는 게 네트워킹이다

돌이켜보면 내가 받은 좋은 기회들은 대부분 "내가 누군가에게 도움이 된 적이 있어서" 생긴 거였다. 이직 레퍼럴, 사이드 프로젝트 초대, 기술 스터디 제안. 전부 내가 먼저 요청한 게 아니라, 관계가 있는 사람이 나를 떠올려서 연락해온 거였다.

이걸 의식적으로 하는 개발자가 있다. 테스팅 라이브러리로 유명한 한 개발자가 대표적이다. 이 사람은 커리어 자체를 "다른 사람이 테스트를 더 잘할 수 있게 돕는 것"으로 만들었다. 오픈소스를 만들고, 블로그를 쓰고, 무료 강의를 제공하고. 이 사람이 "네트워킹"을 한 적은 아마 거의 없을 거다. 근데 개발자 커뮤니티에서 이 사람을 모르는 사람이 없다. 도움을 줬기 때문이다. 도움을 받은 사람이 수만 명이면, 그 중 일부는 자연스럽게 관계가 된다.

물론 이 정도 규모로 할 필요는 없다. 핵심은 원리다. 네트워킹의 본질은 "받는 것"이 아니라 "주는 것"이다. 명함을 돌리면서 "나중에 도움받을 수 있겠지"라고 기대하는 건 순서가 반대다. 먼저 도움이 되는 사람이 되면, 관계는 따라온다.

어떤 블로거가 인간관계에 대해 이런 취지의 말을 한 적이 있다. "누군가에 대해 좋은 생각을 하고 있다면, 그 사람에게 말하라." 칭찬도 도움의 한 형태다. 누군가의 블로그 글이 좋았으면 댓글을 달아라. 누군가의 오픈소스가 유용했으면 깃허브에 스타를 누르고, 가능하면 구체적으로 뭐가 좋았는지 이슈에 적어라. 이 작은 행동들이 쌓이면 존재감이 된다.

## 온라인에서 먼저, 오프라인은 나중에

내향인한테 온라인이 훨씬 편하다. 이유가 몇 가지 있다.

첫째, 생각할 시간이 있다. 오프라인에서 대화하면 즉석에서 반응해야 하는데, 온라인에서는 질문을 보고 5분 동안 생각하고 답을 적을 수 있다. 이 5분이 답의 질을 완전히 바꾼다.

둘째, 자기 페이스대로 할 수 있다. 오프라인 밋업에 가면 2시간 동안 계속 사람들 사이에 있어야 한다. 온라인에서는 에너지가 있을 때 커뮤니티에 들어가서 활동하고, 지치면 그냥 나가면 된다. 아무도 눈치 안 준다.

셋째, 기록이 남는다. 디스코드에서 좋은 답변을 하면 그게 저장된다. 나중에 같은 질문이 나오면 누군가가 내 답변을 인용한다. 그러면 또 사람들이 내 닉네임을 인식하게 된다. 오프라인에서 한 좋은 대화는 두 사람의 기억 속에만 남지만, 온라인에서 한 좋은 답변은 수백 명이 볼 수 있다.

그래서 전략을 "온라인 먼저, 오프라인 나중에"로 바꿨다. 디스코드 커뮤니티에서 활동하면서 사람들과 온라인으로 관계를 만들고, 충분히 편해진 후에 오프라인에서 만난다. 온라인에서 이미 대화를 나눈 사람과 오프라인에서 만나면 전혀 어색하지 않다. 공통 화제가 이미 있고, 서로의 관심사를 이미 아니까.

처음 만나는 사람한테 "안녕하세요, 저는..."을 하는 것과, 온라인에서 3개월 대화한 사람한테 "오프라인에서는 처음이네요"를 하는 것은 완전히 다른 난이도다.

## 학습한 걸 공유하는 것도 관계다

"배운 걸 공유하라"는 조언이 있다. 이걸 다루는 글에서 인상적이었던 건, 공유의 첫 번째 수혜자는 다른 사람이 아니라 "3개월 후의 나 자신"이라는 거다. 블로그를 쓰거나, 커뮤니티에 글을 올리거나, 코드 스니펫을 공유하는 건 일단 자신의 학습을 정리하는 행위다. 거기에 부수적으로 관계가 따라붙는다.

기술 블로그를 시작한 건 네트워킹 목적이 아니었다. 그냥 배운 걸 정리하고 싶었다. 근데 꾸준히 쓰다 보니 댓글이 달리기 시작했다. "저도 같은 문제 겪었는데 도움됐습니다"라는 댓글 하나가 생각보다 큰 동력이 됐다. 댓글에 답을 달고, 그러면서 대화가 시작되고, 가끔 DM으로 이어지기도 했다.

이게 내향인한테 맞는 관계 형성 방식이다. 콘텐츠를 매개로 한 관계. 사람 대 사람이 아니라, 아이디어 대 아이디어로 시작하는 관계. 내 글에 공감한 사람이 말을 걸어오는 거니까, 이미 공통 관심사가 확보되어 있다. 어색하게 화제를 찾을 필요가 없다.

## 깊은 5명 vs 얕은 100명

외향적인 사람들은 행사에 가서 20명과 명함을 교환하고, 20명 모두와 적당한 관계를 유지할 수 있다. 나는 그게 안 된다. 대신 5명과 깊게 아는 사이를 만들 수 있다.

그리고 솔직히, 커리어에서 실질적으로 도움이 된 건 그 5명 쪽이었다.

온라인에서 자주 대화하던 분이 있었다. 같은 기술 스택을 쓰는 분이었는데, 기술 관련 고민을 주고받다가 나중에 오프라인에서 커피를 마셨다. 이미 온라인에서 신뢰가 형성되어 있으니까 만남이 자연스러웠다. 이 분이 나중에 이직할 때 "우리 회사에 자리가 열렸는데 관심 있어?"라고 연락을 줬다. 또 다른 분은 블로그 댓글로 알게 됐다. 내 글에 구체적인 기술 질문을 달았는데, 답을 하다 보니 깊은 기술 토론이 됐다. 그 후로 정기적으로 기술적 고민을 나누는 사이가 됐다.

이런 관계는 "네트워킹 이벤트에 참석해서" 만들 수 있는 게 아니다. 시간을 들여서, 진짜 기술적인 대화를 나누면서, 서로에게 도움이 되면서 만들어지는 거다.

## 회사 안에서의 관계

밖에서만 관계가 있는 게 아니다. 회사 안에서도 다른 팀 사람들과의 관계가 중요하다.

회사 내부 슬랙에 `#frontend` 채널이 있었다. 여러 팀의 프론트엔드 개발자들이 모여 있는 채널인데, 처음에는 눈팅만 했다. 그러다 내가 아는 질문이 올라오면 답을 달기 시작했다. "이 에러는 이런 이유로 나오는 건데, 이렇게 하면 해결됩니다." 짧은 답변. 10분 투자.

이걸 꾸준히 하다 보니 어느 순간 "아 이 닉네임 자주 보는데"라고 인식되기 시작했다. 다른 팀에서 프론트엔드 관련 미팅에 참석해달라는 요청이 왔다. 성능 이슈를 겪고 있었는데, 내가 비슷한 문제를 해결한 경험이 있어서였다. 미팅에서 경험을 공유하고, 그 팀과 관계를 만들었다.

"네트워킹"이라고 부르기엔 너무 자연스러운 과정이었다. 그냥 내가 아는 걸 공유한 거고, 그게 도움이 된 거고, 도움을 받은 사람이 나를 기억한 거다.

## 오프라인에서 살아남는 방법

그래도 오프라인 행사를 완전히 피할 수는 없다. 회사에서 보내거나, 꼭 가야 하는 컨퍼런스가 있으니까. 몇 가지 생존 전략이 있다.

**혼자 가지 않는다.** 아는 동료를 한 명이라도 데리고 간다. 둘이서 발표 내용에 대해 얘기하고 있으면, 옆에 있던 사람이 자연스럽게 끼어든다. "저도 같은 이슈 겪었는데요"라고. 혼자서 모르는 사람한테 다가가는 것보다 1000배 쉽다.

**발표자한테 1:1로 다가간다.** Q&A 시간에 손을 드는 건 어렵지만, 발표 끝나고 개인적으로 다가가서 "발표 잘 들었는데, 한 가지 궁금한 게 있어요"라고 하는 건 훨씬 낫다. 1:1이니까 부담이 적고, 공통 관심사가 이미 있으니까 화제를 찾을 필요도 없다.

**전부 참여하지 않는다.** 8시간짜리 컨퍼런스에서 8시간 동안 사람들 틈에 있는 건 무리다. 듣고 싶은 세션만 듣고, 점심시간에 30분 혼자 산책한다. 그래야 오후를 버틸 수 있다. 내향인의 에너지는 유한하다. 배분이 필요하다.

## 네트워킹이라는 단어를 버려라

결론은 이거다. "네트워킹을 해야 한다"는 생각 자체를 버려라. 대신 "특정한 사람들에게 도움이 되는 사람이 되자"로 바꿔라.

명함 100장을 돌리는 게 네트워킹이 아니다. 디스코드에서 누군가의 에러를 10분 동안 같이 디버깅해주는 게 네트워킹이다. 블로그에 내가 삽질한 경험을 적어서 같은 실수를 할 뻔한 사람의 시간을 아껴주는 게 네트워킹이다. 회사 슬랙에서 다른 팀의 질문에 답을 달아주는 게 네트워킹이다.

내향인의 강점이 여기에 있다. 대화를 많이 하지는 않지만, 한번 대화하면 깊게 듣는다. 넓게 퍼뜨리지는 못하지만, 한 사람에게 집중할 수 있다. 많은 사람에게 이름을 알리지는 못하지만, 소수에게 "그 사람은 진짜 도움이 됐다"는 기억을 남길 수 있다.

그 기억이 6개월 후에 레퍼럴이 되고, 1년 후에 프로젝트 초대가 되고, 2년 후에 커리어를 바꾸는 기회가 된다. 네트워킹 이벤트에서 받은 명함이 아니라, 진심으로 답해준 디스코드 메시지 하나에서.


Next.js 13에서 App Router가 도입되면서 기존 Pages Router와의 선택이 중요한 이슈가 되었다. 두 방식은 완전히 다른 라우팅 패러다임을 제공한다.

이번 글에서는 App Router와 Pages Router의 차이를 명확히 이해하고, 실무에서 어떤 상황에 어떤 것을 선택해야 하는지 알아보려고 한다.

## Pages Router: 전통적인 방식

Next.js의 전통적인 라우팅 방식으로, `pages` 디렉토리 구조가 URL을 결정한다.

```
pages/
  index.js          → /
  about.js          → /about
  blog/
    index.js        → /blog
    [slug].js       → /blog/:slug
  api/
    users.js        → /api/users
```

### 기본 구조

```jsx
// pages/index.js
export default function Home() {
  return <h1>Home</h1>;
}

// pages/about.js
export default function About() {
  return <h1>About</h1>;
}

// pages/blog/[slug].js
export default function BlogPost({ post }) {
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

export async function getStaticProps({ params }) {
  const post = await getPost(params.slug);
  return {
    props: { post },
    revalidate: 60, // ISR
  };
}

export async function getStaticPaths() {
  const posts = await getAllPosts();
  return {
    paths: posts.map(post => ({ params: { slug: post.slug } })),
    fallback: 'blocking',
  };
}
```

## App Router: 새로운 방식

Next.js 13+에서 도입된 방식으로, `app` 디렉토리 구조와 파일 컨벤션을 사용한다.

```
app/
  page.js           → /
  about/
    page.js         → /about
  blog/
    page.js         → /blog
    [slug]/
      page.js        → /blog/:slug
  api/
    users/
      route.js       → /api/users
```

### 기본 구조

```jsx
// app/page.js (Server Component 기본)
export default async function Home() {
  const data = await fetch('https://api.example.com/data');
  return <h1>Home</h1>;
}

// app/about/page.js
export default function About() {
  return <h1>About</h1>;
}

// app/blog/[slug]/page.js
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

// 동적 라우트 생성
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map(post => ({ slug: post.slug }));
}
```

## 핵심 차이점

### 1. 데이터 페칭 방식

**Pages Router**: `getStaticProps`, `getServerSideProps` 사용

```jsx
// Pages Router
export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 60,
  };
}

export default function Page({ data }) {
  return <div>{data}</div>;
}
```

**App Router**: 컴포넌트 내에서 직접 fetch

```jsx
// App Router
export default async function Page() {
  const data = await fetch('https://api.example.com/data', {
    next: { revalidate: 60 },
  });
  
  return <div>{data}</div>;
}
```

### 2. 레이아웃 시스템

**Pages Router**: `_app.js`로 전역 레이아웃

```jsx
// pages/_app.js
export default function MyApp({ Component, pageProps }) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}
```

**App Router**: `layout.js`로 중첩 레이아웃

```jsx
// app/layout.js (루트 레이아웃)
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <Header />
        {children}
        <Footer />
      </body>
    </html>
  );
}

// app/blog/layout.js (블로그 섹션 레이아웃)
export default function BlogLayout({ children }) {
  return (
    <div>
      <BlogNav />
      {children}
    </div>
  );
}
```

### 3. 로딩 및 에러 처리

**Pages Router**: 커스텀 에러 페이지만

```jsx
// pages/_error.js
function Error({ statusCode }) {
  return <p>{statusCode} 에러가 발생했습니다</p>;
}
```

**App Router**: `loading.js`, `error.js` 파일로 자동 처리

```jsx
// app/blog/loading.js
export default function Loading() {
  return <div>로딩 중...</div>;
}

// app/blog/error.js
'use client';

export default function Error({ error, reset }) {
  return (
    <div>
      <h2>에러가 발생했습니다</h2>
      <button onClick={reset}>다시 시도</button>
    </div>
  );
}
```

### 4. 메타데이터 관리

**Pages Router**: `next/head` 또는 커스텀 `_document.js`

```jsx
import Head from 'next/head';

export default function Page() {
  return (
    <>
      <Head>
        <title>Page Title</title>
        <meta name="description" content="..." />
      </Head>
      <div>Content</div>
    </>
  );
}
```

**App Router**: `metadata` 객체 또는 `generateMetadata` 함수

```jsx
// app/blog/[slug]/page.js
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);
  
  return {
    title: post.title,
    description: post.description,
    openGraph: {
      images: [post.image],
    },
  };
}
```

### 5. 서버 컴포넌트 지원

**Pages Router**: 모든 컴포넌트가 클라이언트 컴포넌트

```jsx
// Pages Router: 항상 클라이언트에서 실행
export default function Page() {
  return <div>Content</div>;
}
```

**App Router**: 기본적으로 Server Component, 필요시 `'use client'`

```jsx
// App Router: 기본적으로 Server Component
export default async function Page() {
  const data = await fetchData(); // 서버에서 실행
  return <div>{data}</div>;
}

// Client Component가 필요한 경우
'use client';

export default function InteractiveComponent() {
  const [state, setState] = useState(0);
  return <button onClick={() => setState(state + 1)}>{state}</button>;
}
```

## 실무 선택 가이드

### Pages Router를 선택해야 하는 경우

1. **기존 프로젝트**: 이미 Pages Router로 구축된 프로젝트
2. **안정성 중시**: 검증된 방식으로 빠르게 개발
3. **간단한 프로젝트**: 복잡한 레이아웃이나 중첩 라우팅이 필요 없음
4. **API Routes 중심**: API Routes를 많이 사용하는 경우

```jsx
// Pages Router가 적합한 예시
pages/
  index.js
  about.js
  contact.js
  api/
    contact.js
```

### App Router를 선택해야 하는 경우

1. **새 프로젝트**: 처음부터 시작하는 프로젝트
2. **복잡한 레이아웃**: 중첩 레이아웃이 필요한 경우
3. **성능 최적화**: Server Components로 번들 사이즈 최적화
4. **최신 기능**: Streaming, Suspense 등 최신 기능 필요

```jsx
// App Router가 적합한 예시
app/
  (marketing)/
    page.js
    about/
      page.js
  (dashboard)/
    layout.js
    page.js
    settings/
      page.js
```

## 마이그레이션 전략

### 점진적 마이그레이션

Next.js는 Pages Router와 App Router를 동시에 사용할 수 있다.

```
app/
  page.js          → / (우선순위 높음)
  about/
    page.js        → /about

pages/
  contact.js       → /contact (app에 없으면 사용)
  api/
    users.js       → /api/users
```

### 단계별 마이그레이션

1. **1단계**: 새 페이지는 App Router로 작성
2. **2단계**: 점진적으로 기존 페이지 마이그레이션
3. **3단계**: 완전히 App Router로 전환

## 실무 패턴 비교

### 인증이 필요한 페이지

**Pages Router**:

```jsx
// pages/dashboard.js
export async function getServerSideProps({ req }) {
  const session = await getSession(req);
  
  if (!session) {
    return {
      redirect: {
        destination: '/login',
        permanent: false,
      },
    };
  }
  
  return { props: { session } };
}

export default function Dashboard({ session }) {
  return <div>Dashboard</div>;
}
```

**App Router**:

```jsx
// app/dashboard/page.js
import { redirect } from 'next/navigation';

export default async function Dashboard() {
  const session = await getSession();
  
  if (!session) {
    redirect('/login');
  }
  
  return <div>Dashboard</div>;
}
```

### 동적 라우트

**Pages Router**:

```jsx
// pages/products/[id].js
export async function getStaticPaths() {
  const products = await getProducts();
  return {
    paths: products.map(p => ({ params: { id: p.id } })),
    fallback: 'blocking',
  };
}

export async function getStaticProps({ params }) {
  const product = await getProduct(params.id);
  return { props: { product } };
}
```

**App Router**:

```jsx
// app/products/[id]/page.js
export async function generateStaticParams() {
  const products = await getProducts();
  return products.map(p => ({ id: p.id }));
}

export default async function Product({ params }) {
  const product = await getProduct(params.id);
  return <div>{product.name}</div>;
}
```

## 주의사항

### 1. App Router는 아직 일부 기능이 실험적

- 일부 서드파티 라이브러리가 완전히 지원하지 않을 수 있음
- 문서가 계속 업데이트됨

### 2. Pages Router는 여전히 안정적

- 모든 기능이 검증됨
- 대부분의 라이브러리가 지원

### 3. 혼용 시 주의사항

- 같은 경로에 두 방식 모두 있으면 App Router가 우선
- API Routes는 Pages Router 방식 유지

## 마무리

Pages Router와 App Router는 각각 장단점이 있다. 기존 프로젝트라면 Pages Router를 유지하는 것이 안전하지만, 새 프로젝트라면 App Router의 최신 기능과 성능 이점을 활용하는 것이 좋다.

가장 중요한 것은 팀의 상황과 프로젝트 요구사항에 맞는 선택이다. 복잡한 레이아웃과 성능 최적화가 중요하다면 App Router를, 안정성과 검증된 방식이 중요하다면 Pages Router를 선택하는 것이 합리적이다.




팀에서 Next.js 13이 나왔을 때부터 App Router를 도입할지 논의했다. 근데 그때는 안정성이 불안해서 넘겼고, 14에서도 넘겼다. 15가 나온 시점에서 결국 결정을 내려야 했다. 새 프로젝트를 시작하는데 Pages Router로 갈 건지, App Router로 갈 건지.

2주간 PoC를 했다. 기존 프로젝트의 핵심 페이지 5개를 App Router로 다시 만들어봤다. 그 과정에서 느낀 걸 쓴다.

## 왜 전환을 고민했나

Pages Router가 딱히 문제가 있는 건 아니었다. 잘 돌아가고, 팀원들도 익숙하고, 에코시스템도 안정적이다. 근데 몇 가지 불만은 있었다.

첫째, 레이아웃 공유가 번거롭다. `_app.tsx`에서 전체 레이아웃을 잡고, 페이지별로 다른 레이아웃이 필요하면 `getLayout` 패턴을 써야 한다. 동작은 하는데 공식 API가 아니라 관습적인 패턴이다 보니, 새로 합류한 팀원이 매번 "이건 뭔가요?"라고 물어봤다.

```tsx
// Pages Router에서의 레이아웃 패턴 (관습적)
Page.getLayout = function getLayout(page: ReactElement) {
  return (
    <DashboardLayout>
      <SidebarLayout>{page}</SidebarLayout>
    </DashboardLayout>
  );
};
```

둘째, 데이터 페칭 방식이 페이지에 묶여 있다. `getServerSideProps`나 `getStaticProps`는 페이지 최상단에서만 쓸 수 있다. 컴포넌트가 자기에게 필요한 데이터를 직접 가져오려면 클라이언트 사이드에서 `useEffect`를 써야 한다. 서버에서 가져올 수 있는 데이터인데도.

셋째, Next.js 공식 문서가 이제 App Router 기준으로 쓰여진다. Pages Router 문서가 사라지진 않았지만, 새로운 기능은 App Router에서만 지원되는 경우가 많다. 장기적으로 Pages Router가 유지보수 모드에 들어가는 건 시간문제라는 느낌이 있었다.

## PoC에서 좋았던 것

### 레이아웃이 자연스럽다

App Router의 가장 큰 장점은 파일 시스템 기반 레이아웃이다. `layout.tsx`를 만들면 하위 모든 라우트에 자동 적용된다.

```
app/
├── layout.tsx          // 전체 레이아웃
├── page.tsx            // 홈
├── dashboard/
│   ├── layout.tsx      // 대시보드 레이아웃 (사이드바)
│   ├── page.tsx        // /dashboard
│   ├── analytics/
│   │   └── page.tsx    // /dashboard/analytics
│   └── settings/
│       └── page.tsx    // /dashboard/settings
└── auth/
    ├── layout.tsx      // 인증 레이아웃 (센터 정렬)
    ├── login/
    │   └── page.tsx
    └── register/
        └── page.tsx
```

대시보드 안에서 페이지를 이동해도 사이드바는 리렌더링되지 않는다. 이게 Pages Router에서는 구현하기 까다롭다. `_app.tsx`에서 조건 분기를 하거나, 레이아웃 컴포넌트를 직접 관리해야 한다.

### 서버 컴포넌트

처음에는 "컴포넌트가 서버에서 실행된다고?"라는 개념이 잘 와닿지 않았다. 써보니까 진짜 편한 지점이 있다.

```tsx
// app/dashboard/page.tsx
// 이 컴포넌트는 서버에서 실행된다. useState, useEffect 없음.
async function DashboardPage() {
  const stats = await fetchDashboardStats();
  const recentOrders = await fetchRecentOrders({ limit: 10 });

  return (
    <div>
      <StatsGrid stats={stats} />
      <RecentOrderTable orders={recentOrders} />
    </div>
  );
}
```

`getServerSideProps`에서 데이터를 가져와서 props로 내리는 것과 비교하면, 데이터 페칭 로직이 해당 컴포넌트 바로 옆에 있다. 코드의 응집도가 높아진다. 그리고 컴포넌트를 쪼개면 각 조각이 자신의 데이터를 가져올 수 있다.

```tsx
// 이전: 페이지에서 모든 데이터를 가져와서 props로 전달
// getServerSideProps → page → StatsGrid, RecentOrderTable

// 이후: 각 컴포넌트가 자신의 데이터를 가져옴
async function StatsGrid() {
  const stats = await fetchDashboardStats();
  return (/* ... */);
}

async function RecentOrderTable() {
  const orders = await fetchRecentOrders({ limit: 10 });
  return (/* ... */);
}
```

## PoC에서 힘들었던 것

### "use client" 경계선

서버 컴포넌트에서는 `useState`, `useEffect`, `onClick` 같은 클라이언트 기능을 쓸 수 없다. 써야 하면 파일 상단에 `"use client"`를 붙여야 한다.

문제는, `"use client"`를 붙이면 그 컴포넌트의 하위도 전부 클라이언트 컴포넌트가 된다는 거다 (children으로 받는 경우는 예외). 이 경계를 어디에 두느냐가 설계의 핵심인데, 처음에는 감이 안 잡혔다.

```tsx
// 이렇게 하면 전체가 클라이언트 컴포넌트가 됨
"use client";

export default function ProductPage() {
  const [quantity, setQuantity] = useState(1);

  // 이 안의 모든 것이 클라이언트에서 실행됨
  // 서버에서 가져올 수 있는 데이터도 클라이언트에서 가져오게 됨
  return (
    <div>
      <ProductDetail />  {/* 이것도 클라이언트 */}
      <ProductReviews /> {/* 이것도 클라이언트 */}
      <QuantitySelector value={quantity} onChange={setQuantity} />
    </div>
  );
}
```

올바른 패턴은 클라이언트 로직을 최대한 아래로 밀어내는 거다.

```tsx
// 서버 컴포넌트 (page.tsx)
export default async function ProductPage({ params }: Props) {
  const product = await fetchProduct(params.id);
  const reviews = await fetchReviews(params.id);

  return (
    <div>
      <ProductDetail product={product} />
      <ProductReviews reviews={reviews} />
      <QuantitySelector productId={params.id} /> {/* 이것만 "use client" */}
    </div>
  );
}
```

이 패턴을 팀원들이 자연스럽게 익히기까지 시간이 좀 걸렸다. 특히 "어디까지가 서버고 어디부터가 클라이언트인지"를 머릿속으로 그리는 게 처음에는 어렵다.

### 캐싱의 복잡함

Next.js App Router의 캐싱 전략은 솔직히 복잡하다. Request Memoization, Data Cache, Full Route Cache, Router Cache. 4가지 레이어가 있고, 각각 동작 방식이 다르다.

```typescript
// 이 요청은 캐싱됨 (기본값)
const data = await fetch("https://api.example.com/data");

// 캐싱 안 함
const data = await fetch("https://api.example.com/data", {
  cache: "no-store",
});

// 60초마다 재검증
const data = await fetch("https://api.example.com/data", {
  next: { revalidate: 60 },
});
```

`fetch`에 옵션을 붙여서 캐싱을 제어하는 건 괜찮은데, 문제는 `fetch`를 안 쓰는 경우다. Prisma로 DB를 직접 쿼리하거나, 외부 SDK를 쓸 때는 `unstable_cache`를 써야 한다. 이름에 `unstable`이 붙어 있는 게 마음에 걸린다.

PoC하면서 "왜 데이터가 안 바뀌지?"라고 한참 삽질한 적이 몇 번 있는데, 전부 캐싱 때문이었다. 개발 환경에서는 캐시가 비활성화되어 있어서 잘 되는데 프로덕션 빌드에서 안 되는 경우가 특히 짜증났다.

### 에코시스템 호환성

일부 라이브러리가 서버 컴포넌트를 지원하지 않는다. CSS-in-JS 라이브러리 중 상당수가 클라이언트 런타임에 의존하기 때문에, 서버 컴포넌트에서 쓸 수 없다. styled-components, emotion 등. Tailwind나 CSS Modules는 괜찮다.

상태 관리 라이브러리도 당연히 클라이언트 전용이다. 서버 컴포넌트에서는 상태라는 개념이 없으니까. 이건 제약이라기보다 패러다임의 차이인데, 기존에 전역 상태에 데이터를 넣어두고 쓰던 패턴을 서버 컴포넌트 + 직접 데이터 페칭으로 바꿔야 한다.

## 결국 어떤 판단을 내렸나

PoC 결과를 팀에 공유하고 투표를 했다. App Router로 가기로 했다. 결정적인 이유는 두 가지였다.

하나는 장기적 관점. Next.js의 미래가 App Router에 있다는 건 부정할 수 없다. 지금 Pages Router로 시작하면 1~2년 뒤에 또 전환을 고민해야 한다.

다른 하나는 레이아웃. 우리 프로젝트가 복잡한 중첩 레이아웃을 많이 쓰는 어드민이었다. App Router의 파일 시스템 기반 레이아웃이 이 요구사항에 딱 맞았다.

도입 후 한 달 정도는 팀원들의 생산성이 떨어졌다. 새로운 멘탈 모델에 적응하는 시간이 필요했다. 특히 서버/클라이언트 경계를 잘못 잡아서 에러가 나는 경우가 잦았다. 두 달쯤 지나니까 안정됐고, 세 달쯤 되니까 "이게 더 편한데?"라는 반응이 나왔다.

지금 돌아보면 맞는 선택이었다고 생각한다. 다만 "모든 프로젝트에 App Router를 쓰라"고 말할 수 있느냐고 묻는다면, 그건 아니다. 간단한 마케팅 페이지나 랜딩 페이지라면 Pages Router의 단순함이 오히려 장점이다. 학습 비용을 감수할 만큼 프로젝트가 복잡한지를 먼저 따져봐야 한다.


이 블로그는 Next.js로 만들고 S3에 올린다. Vercel에 올리면 5분이면 끝나는 걸 굳이 S3에 올리는 이유는, 이미 회사에서 쓰는 AWS 인프라가 있어서 거기 얹는 게 관리 포인트가 줄었기 때문이다. 근데 그 "5분이면 끝나는 걸"을 S3에서 하려고 하니까 이틀을 날렸다.

Vercel이 얼마나 많은 걸 자동으로 해주고 있었는지, S3에 직접 배포해봐야 체감된다.

## `output: "export"` 설정했더니 빌드가 터진다

Next.js를 S3에 올리려면 정적 파일로 내보내야 한다. `next.config.js`에 이 한 줄을 추가하면 된다.

```js
// next.config.js
module.exports = {
  output: "export",
};
```

간단해 보인다. `next build`를 실행하면 `out/` 폴더에 HTML, CSS, JS가 생기고, 그걸 S3에 통째로 올리면 된다. 나도 그렇게 생각했다. 그런데 빌드를 돌리자마자 이런 에러가 떴다.

```
Error: API Routes cannot be used with "output: export".
  Route "/api/og" is using API Routes.
```

당연하다. S3는 정적 파일 호스팅이니까 서버 사이드 코드를 실행할 수 없다. API route가 존재하면 빌드 자체가 실패한다. 나는 OG 이미지 생성용으로 `/api/og` 라우트를 하나 두고 있었는데, 이걸 깜빡하고 있었다.

해결법은 두 가지다.

1. API route를 아예 삭제한다
2. API route가 하던 일을 빌드 타임으로 옮긴다

나는 2번을 택했다. OG 이미지 생성을 빌드 타임에 하는 방법은 마지막 섹션에서 다룬다.

중요한 건, `output: "export"`를 켜는 순간 사용할 수 없는 기능이 생각보다 많다는 점이다. API routes 말고도 `middleware.ts`, `rewrites`, `headers` 같은 서버 의존적 기능이 전부 빠진다. 공식 문서에 [지원되지 않는 기능 목록](https://nextjs.org/docs/app/building-your-application/deploying/static-exports#unsupported-features)이 있으니까 `output: "export"` 넣기 전에 한 번 훑어보는 게 좋다.

## trailingSlash를 안 넣으면 S3에서 404가 뜬다

빌드가 성공했다. `out/` 폴더를 S3에 올렸다. 홈페이지는 잘 나온다. 블로그 목록도 나온다. 그런데 블로그 글을 클릭하면 404다.

이건 좀 해맸다. 로컬에서는 멀쩡하거든.

원인은 S3의 파일 탐색 방식에 있다. Next.js가 `trailingSlash` 설정 없이 빌드하면 `/blog/my-post` 경로에 대해 `blog/my-post.html` 파일을 생성한다. 근데 브라우저가 `https://example.com/blog/my-post`를 요청하면, S3는 이걸 `blog/my-post`라는 **폴더**로 해석하고 그 안에서 `index.html`을 찾는다. `blog/my-post.html`이 아니라. 당연히 없으니까 404.

```js
// next.config.js
module.exports = {
  output: "export",
  trailingSlash: true, // 이거 하나로 해결
};
```

`trailingSlash: true`를 넣으면 Next.js가 `/blog/my-post/index.html` 형태로 파일을 생성한다. S3가 `/blog/my-post/` 요청을 받으면 그 폴더 안의 `index.html`을 찾아서 반환한다.

빌드 결과물을 비교해보면 차이가 확실하다.

```
# trailingSlash: false (기본값)
out/blog/my-post.html

# trailingSlash: true
out/blog/my-post/index.html
```

이 한 줄 때문에 한 시간을 썼다. S3 버킷 설정을 만지고, 에러 페이지 설정도 바꿔보고, CloudFront 설정도 건드렸는데 전부 헛짓이었다. `next.config.js`가 문제였다.

## dynamic routes에서 `fallback: false`가 필수다

블로그 같은 사이트에는 dynamic route가 있다. `/blog/[slug]` 형태로 글마다 다른 URL을 만드는 거다. Next.js Pages Router 기준으로 `getStaticPaths`에서 빌드할 경로 목록을 반환해야 한다.

```tsx
// pages/blog/[slug].tsx
export async function getStaticPaths() {
  const posts = getAllPosts();
  return {
    paths: posts.map((post) => ({
      params: { slug: post.slug },
    })),
    fallback: false, // 이게 핵심
  };
}
```

`fallback`에는 `false`, `true`, `"blocking"` 세 가지 옵션이 있는데, `output: "export"`에서는 반드시 `false`여야 한다. `true`나 `"blocking"`을 쓰면 이런 에러가 뜬다.

```
Error: Pages with `fallback` enabled in `getStaticPaths`
can not be exported. See more info here:
https://nextjs.org/docs/messages/ssg-fallback-true-export
```

이유를 생각해보면 당연하다. `fallback: true`는 빌드 시점에 생성하지 않은 페이지를 **런타임에 서버가 생성**하겠다는 뜻이다. S3에 서버가 없으니 불가능하다. `fallback: "blocking"`도 마찬가지로 서버 사이드 렌더링이 필요하다.

App Router를 쓴다면 `generateStaticParams`에서 비슷한 역할을 한다. 그리고 `dynamic` 설정을 명시적으로 잡아줘야 할 수도 있다.

```tsx
// app/blog/[slug]/page.tsx
export const dynamic = "error";
// 빌드 타임에 생성되지 않은 경로는 에러 처리

export async function generateStaticParams() {
  const posts = getAllPosts();
  return posts.map((post) => ({
    slug: post.slug,
  }));
}
```

`dynamic = "error"`는 Pages Router의 `fallback: false`와 같은 의미다. 빌드 타임에 생성된 경로만 허용하고, 나머지는 전부 404로 보낸다.

## next/image가 안 되는 이유

이건 에러 메시지가 친절해서 금방 해결했다.

```
Error: Image Optimization using the default loader is not
compatible with `output: export`.
```

Next.js의 `<Image>` 컴포넌트는 기본적으로 서버에서 이미지를 리사이즈하고 WebP로 변환한다. S3에는 그 서버가 없다. 설정 하나 추가하면 된다.

```js
// next.config.js
module.exports = {
  output: "export",
  trailingSlash: true,
  images: {
    unoptimized: true,
  },
};
```

이러면 `<Image>` 컴포넌트가 최적화 없이 원본 이미지를 그대로 사용한다. "그러면 이미지 최적화를 아예 포기해야 하나?" 하는 생각이 드는데, 몇 가지 대안이 있다.

빌드 타임에 `sharp` 라이브러리로 이미지를 미리 최적화해두거나, CloudFront 앞에 Lambda@Edge를 붙여서 이미지를 변환하거나, 아예 외부 이미지 CDN 서비스를 쓰는 방법이 있다. 이 블로그는 이미지가 많지 않아서 빌드 시에 수동으로 WebP 변환해서 올리고 있다. 완벽한 해결책은 아닌데, 개인 블로그에 Lambda@Edge까지 붙이는 건 과하다고 판단했다.

## CloudFront 캐시 무효화를 까먹으면 생기는 일

배포 파이프라인을 다 만들었다. S3에 파일 올리고, 사이트를 확인하고, 잘 된다. 글을 하나 수정하고 다시 배포했다. S3에 파일이 업데이트된 걸 확인했다. 근데 사이트에서는 안 바뀌어 있다.

캐시다.

CloudFront는 S3 앞에 붙는 CDN이다. 한 번 요청된 파일을 엣지 서버에 캐싱해두고, 같은 요청이 오면 S3까지 가지 않고 캐시된 파일을 반환한다. 그래서 S3의 파일을 바꿔도 CloudFront는 모른다. 명시적으로 캐시를 무효화해줘야 한다.

```bash
# CloudFront 캐시 무효화
aws cloudfront create-invalidation \
  --distribution-id E1234567890 \
  --paths "/*"
```

`"/*"`는 모든 경로의 캐시를 날리겠다는 뜻이다. 특정 파일만 무효화할 수도 있지만, 블로그 배포에서는 어차피 여러 파일이 동시에 바뀌니까 전체 무효화가 편하다. 참고로 CloudFront는 매달 1,000건의 무효화 경로를 무료로 제공하고, `"/*"`는 1건으로 친다.

배포 스크립트에 넣어두면 까먹을 일이 없다.

```bash
#!/bin/bash
# deploy.sh

BUCKET="my-blog-bucket"
DISTRIBUTION_ID="E1234567890"

echo "Building..."
pnpm build

echo "Uploading to S3..."
aws s3 sync out/ s3://$BUCKET --delete

echo "Invalidating CloudFront cache..."
aws cloudfront create-invalidation \
  --distribution-id $DISTRIBUTION_ID \
  --paths "/*"

echo "Done!"
```

나는 이걸 CI/CD에 넣어두고 `main` 브랜치에 푸시하면 자동으로 실행되게 해뒀다. GitHub Actions에서 돌리고 있는데, AWS credentials만 시크릿으로 넣어두면 된다.

이 문제로 하루를 날린 적이 있다. 분명 S3에 새 파일이 올라간 걸 확인했는데, 사이트에서 변경이 안 보이니까 빌드에 문제가 있나 싶어서 `out/` 폴더를 열어보고, 그래도 안 돼서 next.config.js를 의심하고, 한참 삽질하다가 "아 캐시" 하는 순간이 왔다. CloudFront를 쓰고 있다는 사실 자체를 잊고 있었다.

## OG 이미지를 빌드 타임에 생성하기

처음에는 `/api/og` 라우트에서 `@vercel/og`를 써서 OG 이미지를 동적으로 생성하고 있었다. 근데 `output: "export"`를 켜면 API route를 쓸 수 없으니까, 빌드 타임에 미리 만들어야 한다.

`satori`와 `sharp`를 쓰면 된다. `satori`는 JSX를 SVG로 변환하고, `sharp`는 SVG를 PNG로 변환한다. 사실 `@vercel/og`도 내부적으로 `satori`를 쓰고 있어서 결과물이 거의 동일하다.

```bash
pnpm add -D satori sharp @types/sharp
```

빌드 스크립트를 하나 만든다.

```tsx
// scripts/generate-og-images.mts
import satori from "satori";
import sharp from "sharp";
import { readFileSync, mkdirSync, writeFileSync } from "fs";
import { getAllPosts } from "../src/lib/posts";

const font = readFileSync("./public/fonts/PretendardBold.otf");

async function generateOgImage(title: string, slug: string) {
  const svg = await satori(
    {
      type: "div",
      props: {
        style: {
          width: "1200px",
          height: "630px",
          display: "flex",
          flexDirection: "column",
          justifyContent: "center",
          padding: "60px",
          backgroundColor: "#0a0a0a",
          color: "#fafafa",
        },
        children: [
          {
            type: "div",
            props: {
              style: {
                fontSize: "52px",
                fontWeight: 700,
                lineHeight: 1.3,
                wordBreak: "keep-all",
              },
              children: title,
            },
          },
          {
            type: "div",
            props: {
              style: {
                fontSize: "24px",
                color: "#a1a1aa",
                marginTop: "24px",
              },
              children: "tech-donut.com",
            },
          },
        ],
      },
    },
    {
      width: 1200,
      height: 630,
      fonts: [
        {
          name: "Pretendard",
          data: font,
          weight: 700,
          style: "normal",
        },
      ],
    }
  );

  const png = await sharp(Buffer.from(svg)).png().toBuffer();

  const dir = `./public/og`;
  mkdirSync(dir, { recursive: true });
  writeFileSync(`${dir}/${slug}.png`, png);
}

async function main() {
  const posts = getAllPosts();

  for (const post of posts) {
    await generateOgImage(post.title, post.slug);
    console.log(`Generated: ${post.slug}.png`);
  }
}

main();
```

`package.json`에 스크립트를 추가한다.

```json
{
  "scripts": {
    "generate:og": "tsx scripts/generate-og-images.mts",
    "build": "pnpm generate:og && next build"
  }
}
```

그리고 각 페이지의 metadata에서 생성된 이미지를 참조한다.

```tsx
// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = getPostBySlug(params.slug);
  return {
    openGraph: {
      images: [`/og/${params.slug}.png`],
    },
  };
}
```

이렇게 하면 `next build` 전에 OG 이미지가 `public/og/`에 생성되고, 빌드 결과물에 포함된다. API route 없이도 각 포스트마다 커스텀 OG 이미지를 가질 수 있다.

주의할 점 하나. `satori`는 JSX를 HTML처럼 해석하지만, CSS 지원이 완벽하지 않다. `flexbox`는 되지만 `grid`는 안 되고, `position: absolute`는 되지만 `transform`은 일부만 된다. 레이아웃이 복잡하면 결과물이 예상과 다를 수 있어서, 간단하게 만드는 게 낫다.

## 최종 설정

여기까지 겪은 삽질을 전부 반영한 `next.config.js`다.

```js
// next.config.js
module.exports = {
  output: "export",
  trailingSlash: true,
  images: {
    unoptimized: true,
  },
};
```

세 줄이다. 이 세 줄에 도달하는 데 이틀이 걸렸다. 각각의 설정이 왜 필요한지 모르면 하나씩 빼보고 싶은 유혹이 생기는데, 빼면 터진다.

S3 배포가 Vercel 대비 확실히 손이 많이 간다. 근데 한 번 세팅해두면 월 호스팅 비용이 거의 0에 수렴하고, AWS 인프라에 이미 익숙하다면 오히려 관리가 편할 수도 있다. 이 블로그도 한 번 세팅한 뒤로는 글 쓰고 푸시하면 끝이니까. 삽질은 처음 한 번이면 충분하다.



메모 앱을 바꾼 횟수가 7번이다. 2년 동안 7번. 평균 3~4개월에 한 번씩 새 앱으로 갈아탄 셈이다. 매번 마이그레이션할 때마다 이전 앱의 메모를 새 앱으로 옮기는 데 반나절을 썼다. 그 시간에 메모를 50개는 더 쓸 수 있었을 거다.

에버노트 → 노션 → Bear → 옵시디언 → Apple 메모 → 다시 노션 → 다시 옵시디언. 매번 "이번에야말로 완벽한 메모 시스템을 만들겠다"고 하면서 시작했고, 매번 "이 앱은 이게 불편해"라면서 다른 걸로 넘어갔다. 새 앱의 랜딩 페이지는 항상 매력적이었고, 기존 앱은 항상 뭔가 부족해 보였다.

돌이켜보면, 도구를 바꿔도 해결이 안 됐던 건 문제가 도구에 있지 않았기 때문이다.

## 메모 유목민의 역사

에버노트는 입사 전부터 썼다. 대학교 다닐 때 수업 노트용으로 쓰다가 개발을 시작하면서 기술 메모도 여기에 넣었다. 코드 스니펫, 에러 해결법, 블로그에서 본 좋은 글 스크랩. 문제는 메모가 500개를 넘어가면서 시작됐다. 검색이 느리다. 원하는 메모를 찾으려면 키워드를 정확히 기억해야 하는데, 3개월 전에 적은 메모의 키워드를 누가 기억하나. 그리고 에버노트의 에디터가 개발자 친화적이지 않았다. 코드를 넣으면 포매팅이 깨졌다. 인라인 코드조차 제대로 안 됐다.

노션으로 옮긴 건 2024년 초. 주변에서 다들 쓰길래 따라갔다. 트위터에서 "나의 노션 워크스페이스" 같은 글이 유행했고, 예쁘게 정리된 노션 화면 캡처를 보면서 "나도 저렇게 해야지" 했다. 데이터베이스 기능이 좋아서 처음에는 감동했다. 기술 노트를 태그별로 분류하고, 프로젝트별 페이지를 만들고, 칸반 보드로 학습 진도를 관리했다. 셋업하는 데만 주말을 통째로 썼다. 아이콘도 골라 넣고, 커버 이미지도 넣고, 토글과 콜아웃을 활용한 템플릿도 만들었다.

2주 후에 메모를 안 하고 있었다. 이유가 웃긴데, 메모를 하려면 어떤 데이터베이스에 넣어야 하는지 고민이 되는 거다. "이 메모는 TIL 데이터베이스에 넣어야 하나, 프로젝트 노트 데이터베이스에 넣어야 하나, 기술 참고자료 데이터베이스에 넣어야 하나. 아니면 새 데이터베이스를 만들어야 하나." 분류 체계가 너무 세밀해서 메모하는 것 자체에 마찰이 생겼다. 분류하는 데 드는 인지 비용이 메모하는 비용을 초과했다. 메모의 목적은 생각을 빠르게 기록하는 건데, 기록하기 전에 5분을 고민해야 하면 그건 시스템이 잘못된 거다.

Bear는 가볍고 마크다운 지원이 좋아서 좋았는데 윈도우에서 안 돼서 회사 노트북(맥)과 개인 PC(당시 윈도우)를 왔다 갔다 하면서 쓰기 불편했다. 옵시디언은 로컬 기반이라 빠르고 좋았지만, 처음에 너무 많은 플러그인을 깔아서 커스터마이징 지옥에 빠졌다. 메모하는 시간보다 플러그인 설정을 만지는 시간이 더 많았다. "이 플러그인이 좋대" "이 CSS 스니펫을 적용하면 예뻐져" 하면서 결국 메모 앱을 만지는 게 취미가 됐다. 본말전도.

Apple 메모는 극단적으로 심플한 걸 시도해본 거였다. 실제로 마찰은 제로에 가까웠다. 아이폰에서 바로 열어서 적으면 된다. 근데 검색이 빈약하고 마크다운 지원이 없어서 코드 조각을 넣기가 불편했다. 개발자 메모에 코드가 빠지면 가치가 반감된다.

## 깨달음: 시스템이 아니라 규칙이 문제다

7번째로 옵시디언에 정착하면서 깨달은 게 있다. 매번 실패한 이유가 앱의 기능 때문이 아니라 내가 규칙을 안 정한 채로 쓰기 시작해서 그렇다는 거다.

노션에서 실패한 건 노션이 나빠서가 아니라, 분류 체계를 너무 복잡하게 만든 내 탓이었다. 옵시디언에서 실패한 건 옵시디언이 나빠서가 아니라, 플러그인을 20개 설치한 내 탓이었다. Apple 메모에서 불편했던 것도, 코드를 적을 방법을 미리 정하지 않은 내 탓이었다.

도구는 뭐든 상관없다. 노션이든 옵시디언이든 Bear든 Apple 메모든, 중요한 건 "메모를 넣을 때 고민이 없어야 한다"는 거다. 열고, 적고, 닫는다. 이 세 단계에서 2번째 이외의 마찰이 있으면 안 된다.

## 지금 쓰는 시스템

옵시디언으로 돌아왔지만 이번에는 규칙을 먼저 정했다. 앱을 열기 전에 노트에 규칙을 적었다.

**규칙 1: 폴더는 3개만.** `inbox`, `notes`, `archive`. 새 메모는 무조건 inbox에 넣는다. 분류 고민 없이. "이거 어디에 넣지?"라는 생각 자체를 하지 않는다. 일주일에 한 번, 보통 일요일 저녁에 inbox를 정리해서 notes로 옮기거나 archive로 보낸다. 그때 태그를 달고 제목을 정리한다. 적을 때가 아니라 정리할 때 분류한다. 이 순서가 중요하다.

**규칙 2: 플러그인은 5개 이하.** 지금 쓰는 건 Calendar, Dataview, Templater, Quick Add 이 네 개. 다섯 번째 자리는 비워두고 있다. 새 플러그인을 설치하고 싶으면 기존 걸 하나 삭제해야 한다. 이 규칙이 없으면 한 달 안에 플러그인이 20개가 된다. 나는 그런 사람이다.

**규칙 3: 메모 하나의 길이 제한 없음.** 이전에는 "메모는 짧고 원자적이어야 한다"는 Zettelkasten 원칙에 집착했는데, 그러면 메모하기가 부담스럽다. "이 메모가 충분히 원자적인가?"를 고민하느라 메모를 안 하게 된다. 두 줄짜리 메모도, 열 줄짜리 메모도, 몇 페이지짜리 메모도 다 괜찮다. 길이를 신경 쓰지 않으니까 메모의 양이 늘었다. 대충 적어도 된다.

**규칙 4: 하루 끝에 한 개 이상.** 오늘 배운 것, 삽질한 것, 떠오른 아이디어, 읽은 글에서 인상 깊었던 점. 뭐라도 하나 적는다. 없으면 "오늘은 특별한 거 없었음"이라고 적는다. 적는 행위 자체가 중요하다. 빈 날이 하루, 이틀 생기면 습관이 끊기니까.

## 메모가 실제로 도움이 된 순간들

시스템이 자리잡고 3개월 정도 지나니까 메모의 가치가 보이기 시작했다.

한번은 프로덕션에서 이미지 최적화 관련 이슈가 터졌다. 상품 리스트 페이지에서 Largest Contentful Paint가 3초를 넘기고 있었다. 예전에 비슷한 문제를 겪었던 기억이 희미하게 있었는데, 옵시디언을 검색하니까 4개월 전에 적어둔 메모가 나왔다. "next/image에서 layout=fill 쓸 때 부모 컨테이너에 position: relative 없으면 레이아웃 깨짐. sizes 속성 안 넣으면 불필요하게 큰 이미지 로드. priority 속성을 Above the fold 이미지에만 넣기." 과거의 내가 미래의 나를 도와준 거다. 그 메모 덕분에 30분이면 끝날 일을 반나절 삽질할 뻔했다.

코드 리뷰에서도 도움이 된다. 팀원이 올린 PR에서 특정 패턴을 봤을 때, "이 패턴에 대해 뭔가 적어놨었는데" 하고 검색하면 기술 서적에서 발췌한 메모가 나온다. "클린 코드 p.35: 함수는 한 가지 일만 해야 한다. 한 가지 일을 잘 해야 한다. 그 한 가지 일만 해야 한다." 이런 메모가 있으면 근거 있는 리뷰 코멘트를 달 수 있다.

그리고 1on1이나 성과 리뷰 때. 2년간 업무에서 겪은 문제와 해결 과정이 메모에 남아있으니까, "이번 분기에 뭘 했는지" 정리하기가 훨씬 쉬워졌다. 메모가 없으면 한 달 전에 뭘 했는지도 기억이 안 난다. 사람의 기억은 믿을 게 못 된다.

## 종이의 역할

디지털 메모만 쓰는 건 아니다. 회의할 때는 종이 노트를 쓴다.

회의 중에 노트북을 열면 타자 소리가 거슬리기도 하고, 무엇보다 회의하다 말고 슬랙 확인하게 되는 것도 문제다. "잠깐 메모하는 중이에요"라고 하면서 실은 슬랙 DM을 읽고 있는 자신을 발견한 적이 여러 번 있다. 종이에 적으면 이런 유혹이 없다. 펜과 종이밖에 없으니까.

그리고 회의에서 아이디어를 그릴 때 종이가 훨씬 자유롭다. 컴포넌트 구조를 박스로 그리고, 데이터 흐름을 화살표로 표시하고, 옆에 메모를 덧붙이고. 이걸 노션이나 옵시디언에서 하려면 시간이 세 배는 걸린다. 물론 필기가 예쁘진 않다. 나중에 못 읽는 경우도 있다. 내 글씨는 악필에 가깝다.

그래서 규칙을 하나 더 만들었다. 회의 끝나고 5분 안에 종이 노트를 사진 찍어서 옵시디언 inbox에 넣고, 핵심 내용만 3~5줄로 타이핑 정리한다. 5분 안에 하는 이유는 시간이 지나면 자기 필기를 해독 못하기 때문이다. 진짜로 다음 날에 보면 "이 동그라미 안에 적은 건 뭐지?"가 되는 경우가 부지기수다.

## 완벽한 시스템은 없다

지금 시스템도 완벽하지 않다. 일주일에 한 번 inbox를 정리한다고 했는데, 바쁘면 2주, 3주 밀리기도 한다. inbox에 메모가 40개쯤 쌓이면 정리하기 싫어서 또 방치하게 된다. 이러면 inbox가 쓰레기통이 되는데, 그래도 안 적는 것보다는 낫다.

태그 체계도 아직 완벽하지 않다. 처음에 태그를 10개 정도 만들었는데, 6개월 지나니까 어떤 태그에 메모가 80개고 어떤 태그에는 2개다. 재분류를 해야 하는데 귀찮아서 미루고 있다.

그래도 이전보다는 훨씬 낫다. 메모를 해야 한다는 부담이 줄었고, 실제로 과거의 메모가 도움이 되는 경험을 하니까 메모하는 게 습관이 됐다. 도구보다 규칙, 규칙보다 습관이 중요하다는 걸 7번의 실패 끝에 배웠다.

아직도 "이 앱 좋다더라" 하는 글을 보면 마음이 흔들린다. 지난주에도 Craft라는 앱 리뷰를 봤다. 깔끔하고 예뻤다. 손가락이 앱스토어로 향했는데, 참았다. 이번에는 참았다.



그 PR은 상태 관리 구조에 대한 것이었다. 컴포넌트 트리 깊숙한 곳에서 서버 데이터를 어떻게 갱신할 것인가. 나는 전역 상태에 캐싱하는 방식을 밀었고, 같은 팀 시니어는 서버 상태와 클라이언트 상태를 분리하자는 의견이었다.

나는 확신에 차 있었다. 기존 프로젝트에서 비슷한 구조를 써본 경험이 있었고, 그때 잘 동작했다. "이미 검증된 패턴이에요"라는 말을 리뷰 코멘트에 두 번이나 썼다. 시니어가 단점을 지적하면 반론을 달았고, 반론에 재반론이 붙었다. 코멘트가 쌓이면서 PR은 점점 토론장이 됐다.

이틀째 되는 날, 퇴근길 지하철에서 시니어의 코멘트를 다시 읽었다. 감정을 빼고, 내가 반박하려는 의도 없이, 순수하게 텍스트만 읽어봤다. 솔직히, 말이 됐다. 아니, 내 방식보다 더 말이 됐다.

순간 가슴이 쿵 내려앉는 느낌이었다. 이틀 동안 내가 지켜온 게 "더 나은 방식"이 아니라 "내 자존심"이었다는 걸 깨달았다.

## 왜 인정이 이렇게 어려운가

프로그래밍이라는 직업의 특성상, 우리는 논리적이라고 스스로를 믿는다. 감정이 아니라 근거로 판단한다고 생각한다. 코드는 맞거나 틀리거나 둘 중 하나고, 나는 맞는 쪽을 고른다고 믿는다.

그런데 실제로 코드 리뷰에서 벌어지는 일은 그렇지 않다. 코드에 대한 의견이 곧 나의 능력에 대한 평가처럼 느껴진다. "이 방식은 비효율적이에요"라는 코멘트가 "당신의 실력이 부족하네요"로 번역된다. 머리로는 아닌 걸 아는데, 감정은 그렇게 안 움직인다.

특히 주니어 시절에는 이게 심했다. 코드 한 줄 한 줄이 나의 존재 증명 같았다. 내가 작성한 코드가 틀렸다는 건 내가 이 자리에 있을 자격이 부족하다는 뜻 같았다. 그래서 지적을 받으면 방어부터 했다. "이건 이렇게 의도한 거예요." "이 상황에서는 이게 맞아요." 근거를 찾아서 반박하는 게 배우는 것보다 먼저였다.

사실 그때 시니어가 한 번 더 강하게 밀었으면 그냥 "알겠습니다"라고 하고 고쳤을 거다. 하지만 그건 인정이 아니라 복종이다. 내가 틀렸다고 이해한 게 아니라, 힘의 논리에 따른 거다. 겉으로는 같아 보여도 완전히 다른 거다.

## 그래서 뭐라고 했는가

다음 날 아침, 출근하자마자 PR에 코멘트를 달았다.

"다시 생각해봤는데, 제 접근 방식에 문제가 있는 것 같습니다. 서버 상태를 전역에 캐싱하면 동기화 이슈가 생기는 건 맞고, 그 부분을 제가 과소평가했어요. 제안해주신 구조로 가는 게 장기적으로 더 낫겠습니다."

타이핑하는 데 5분이 걸렸다. 문장을 쓰고 지우고를 반복했다. "부분적으로 동의한다"고 쓸까, "절충안을 제안한다"고 쓸까 고민했다. 하지만 그건 또 다른 형태의 방어였다. 틀린 거면 틀렸다고 말하는 게 맞았다.

팀원들의 반응이 의외였다. 시니어는 "솔직하게 말해줘서 고맙다. 사실 나도 이틀 동안 내가 틀린 건 아닌지 계속 고민했다"고 했다. 다른 팀원은 슬랙으로 DM을 보내왔다. "그 코멘트 보고 놀랐다. 솔직히 나도 비슷한 상황에서 끝까지 우긴 적 있는데, 저렇게 인정하기 쉽지 않다."

예상했던 반응은 "그러니까 내 말이 맞잖아"였다. 하지만 아무도 그런 말을 하지 않았다. 오히려 나를 더 신뢰하게 됐다는 뉘앙스였다. 이상하게 들릴 수 있는데, 틀렸다고 인정하는 게 존경을 사는 방법이 될 수 있다는 걸 그때 처음 알았다.

## 회의실에서의 그 순간

비슷한 일이 몇 달 뒤에 또 있었다. 이번에는 코드가 아니라 기술 스택 선택에 대한 회의에서였다.

새 프로젝트의 상태 관리 라이브러리를 정하는 자리였다. 나는 이전 회의에서 특정 라이브러리를 강하게 추천했었다. 사용 경험도 있고, 번들 사이즈도 작고, 러닝커브도 낮다고 했다. 다른 팀원이 대안을 제시했는데, 나는 "그건 오버 엔지니어링이에요"라고 잘랐다.

그리고 일주일 동안 두 라이브러리를 각각 프로토타입으로 만들어보는 시간을 가졌다. 직접 써보니, 내가 추천한 쪽이 현재 프로젝트의 요구사항에 맞지 않았다. 특히 서버 컴포넌트와의 통합 부분에서 상대편이 훨씬 매끄러웠다.

회의 시간. 모두가 자리에 앉아 있었다. 나는 "프로토타입을 만들어보니까, 제가 지난번에 오버 엔지니어링이라고 한 게 사실은 더 적합한 선택이었습니다. 제가 틀렸어요"라고 말했다.

방 안이 잠깐 조용해졌다. 그 2초가 꽤 길게 느껴졌다. 그리고 프로젝트 매니저가 "그러면 그걸로 갈까요?"라고 해서 논의가 빠르게 정리됐다.

회의 후에 깨달은 거다. "틀렸다"고 말하니까 논의가 빨라졌다. 아무도 메뉴얼하게 비교 분석표를 만들 필요가 없었고, 감정적인 논쟁을 할 필요도 없었고, 정치적인 타협을 할 필요도 없었다. 사실을 말했을 뿐인데 모든 게 간결해졌다.

## 틀릴 수 있다는 전제로 시작하기

이후로 의식적으로 연습하는 것들이 있다.

코드 리뷰에서 강한 의견을 낼 때, 마지막에 "제가 놓치고 있는 맥락이 있으면 알려주세요"를 붙인다. 처음에는 형식적인 문장이었는데, 실제로 놓치고 있는 맥락이 있는 경우가 꽤 많았다. 내가 모르는 히스토리, 내가 고려하지 못한 제약 조건, 내가 경험하지 못한 엣지 케이스.

회의에서 내 의견을 말할 때, "확실하지 않은데"를 앞에 붙인다. 확실하지 않은 건 진짜 확실하지 않은 거니까. 이게 약해 보일 수 있다고 걱정했는데, 실제로는 반대였다. 불확실성을 인정하는 사람의 말에 사람들이 더 귀를 기울였다. 항상 확신에 차 있는 사람보다 가끔 "모르겠다"고 말하는 사람이 더 믿음직스러웠다.

동료에게 도움을 요청하는 것도 틀렸다고 말하는 것의 연장선이라고 느낀다. "이거 모르겠어요"가 "이거 틀렸어요"만큼 어렵다. 둘 다 내가 완벽하지 않다는 걸 드러내는 행위니까. 그런데 팀에서 일하면서 완벽한 사람은 한 명도 못 봤다. 완벽한 척하는 사람은 봤다. 그런 사람과 일하는 건 피곤하다.

## 팀 문화와의 관계

개인의 노력만으로 되는 문제는 아니다. "틀렸다"고 말했을 때 "그러니까 네가 부족한 거 아니야?"라고 돌아오는 팀이라면, 아무도 틀렸다고 말하지 않을 거다. 당연하다. 합리적인 자기 방어다.

내가 운이 좋았던 건, 팀이 실수에 관대한 편이었다는 거다. 장애가 나면 원인을 분석하지, 사람을 탓하지 않았다. 코드 리뷰에서 의견이 다르면 토론하지, 직급으로 누르지 않았다. 이런 환경이 전제되어야 "틀렸다고 말하기"가 가능하다.

반대로, 누군가가 먼저 틀렸다고 말하면 그 팀의 분위기가 바뀌기도 한다. 시니어가 "내가 이번에 판단을 잘못한 것 같아"라고 회고에서 말하는 순간, 주니어도 "저도 실은 이 부분에서 실수가 있었어요"라고 말하기 쉬워진다. 솔직함은 전염된다.

예전에 있었던 팀에서는 반대의 경험도 했다. 회고 시간에 누군가 문제를 지적하면 분위기가 싸해졌다. "그때 그렇게 결정한 건 다 이유가 있었어요"라는 방어가 먼저 나왔다. 문제를 인정하면 책임을 져야 하고, 책임을 지면 평가에 불이익이 생길 수 있다는 암묵적인 공포가 있었다. 그 팀에서는 아무도 틀렸다고 말하지 않았고, 결과적으로 같은 실수가 반복됐다. 문제를 인정하지 않으니 개선할 수도 없었던 거다.

두 팀의 차이는 개인의 성향이 아니라 구조의 차이였다. 실수를 인정했을 때 벌을 받는 구조와, 실수를 인정했을 때 배울 수 있는 구조. 같은 사람이라도 어떤 구조에 있느냐에 따라 완전히 다르게 행동한다.

## 틀림의 크기가 다를 때

사소한 틀림은 인정하기 쉽다. 변수명이 어색하다는 지적, CSS 속성 순서를 잘못 쓴 것, 오타. 이런 건 "아 맞네요, 감사합니다" 하고 넘어가면 된다. 자존심이 상할 일이 아니다.

어려운 건 "내가 깊이 생각하고 확신했던 것"이 틀린 경우다. 설계를 잘못 한 거, 기술 선택이 틀린 거, 팀에게 잘못된 방향을 제시한 거. 투자한 시간과 감정이 클수록 인정하기 어렵다. "여기까지 왔는데 틀렸다고 하면 지금까지 한 게 다 무의미해지잖아"라는 생각이 든다. 하지만 방향이 틀린 걸 알면서 계속 가는 게 더 큰 낭비다. 빨리 인정하고 돌아서는 게 결과적으로 시간을 아낀다.

매몰 비용의 오류라는 게 이런 거다. 이미 투자한 것에 대한 집착 때문에 잘못된 방향을 계속 가는 것. 이론으로는 다 아는데, 막상 내 상황이 되면 쉽지 않다.

## 여전히 어렵다

오해하지 말아야 할 게, 나는 이제 틀렸다고 잘 말하는 사람이 된 게 아니다. 여전히 어렵다. 코드 리뷰에서 지적을 받으면 아직도 첫 반응은 방어다. 0.5초 동안 "왜 이걸 지적하지"라는 생각이 스치고, 의식적으로 그걸 누르고 "잠깐, 이 코멘트를 열린 마음으로 읽어보자"로 전환한다.

0.5초의 방어 반응이 사라지진 않았다. 다만 그 뒤의 0.5초가 달라졌을 뿐이다. 자동으로 반박을 타이핑하는 대신, 한 번 더 읽고 생각한다. 이게 전부다. 화려한 성장 서사 같은 건 없다. 그냥 0.5초의 습관을 바꾸려고 매일 애쓰고 있다.

그리고 가끔은, 이틀 동안 고수한 내 의견이 정말 맞는 경우도 있다. 틀렸다고 인정하는 연습은, 무조건 양보하라는 뜻이 아니다. 내가 맞을 수도 있고 틀릴 수도 있다는 가능성을 항상 열어두라는 뜻이다. 확신이 아니라 호기심으로 토론에 임하라는 거다.

누군가에게 "틀렸다"고 말하는 건 한 문장이다. 하지만 그 한 문장에는 자존심을 내려놓는 용기, 상대방의 말을 진심으로 들었다는 증거, 팀의 결과를 나의 체면보다 우선한다는 선언이 담겨 있다. 한 문장치고는 꽤 무겁다.

그래서 연습이 필요하다. 매일, 반복적으로.

최근에 후배 개발자와 1:1을 하다가 이런 이야기를 들었다. "코드 리뷰에서 지적받으면 밤에 잠이 안 와요. 내가 부족한 건가 싶어서." 그 말을 듣고 예전의 내가 떠올랐다. 나도 그랬다고 말해줬다. 그리고 지적을 받는 건 부족해서가 아니라, 팀에서 일하고 있기 때문이라고. 혼자 일하면 아무도 지적하지 않지만, 그게 내 코드가 완벽해서는 아니라고.

틀렸다고 말하는 건 재능이 아니라 기술이다. 기술은 연습으로 는다.


1:1 미팅 시간이 되면 회의실에 들어간다. 리드가 "요즘 어때?"라고 묻는다. "네, 잘 하고 있습니다. 이번 스프린트 티켓 순조롭게 진행 중이에요." 리드가 고개를 끄덕인다. "어려운 거 있어?" "아, 딱히요." 어색한 침묵이 흐른다. 리드가 "그럼 다음 스프린트 티켓 얘기 좀 하자"라고 한다. 30분짜리 미팅이 15분 만에 끝난다.

한동안 내 1:1은 이랬다. 매주 화요일 오후 3시, 30분. 캘린더에 반복 설정되어 있는데 매번 "오늘은 뭘 말하지?"라는 생각으로 시작했다. 특별히 문제가 없으면 할 말이 없다고 느꼈다. 그래서 그냥 업무 진행 상황을 보고하고 나왔다. 그런 미팅이라면 슬랙 메시지로 대체할 수 있다.

## 1:1은 업무 보고 시간이 아니다

변화가 생긴 건 동기 한 명이랑 커피를 마시다가 1:1 얘기가 나왔을 때다. 동기가 말했다. "나는 1:1 때마다 리드한테 커리어 관련 질문을 하나씩 한다." 무슨 질문을 하냐고 물어봤더니 예를 들어 "시니어가 되려면 지금 제가 가장 부족한 부분이 뭐라고 생각하세요?" 같은 거라고.

솔직히 처음에는 그런 질문을 하는 게 부담스럽다고 생각했다. "아직 주니어인데 벌써 시니어 얘기를 꺼내면 이상하지 않나?" 근데 동기 말이, 리드 입장에서는 성장에 관심 있는 팀원이 오히려 반갑다고. 매번 "별일 없습니다"로 끝나는 1:1보다는 뭔가 얘기할 거리가 있는 게 리드 입장에서도 낫다고.

그 뒤로 나는 1:1 전에 메모를 하기 시작했다. 일주일 동안 일하면서 느낀 것, 궁금한 것, 고민되는 것을 노션에 짧게 적어놓고, 미팅 때 그걸 꺼냈다. 처음에는 메모가 한 줄도 없는 주가 많았다. 의식적으로 "이거 1:1 때 얘기하자" 하고 적는 습관이 들기까지 한 달 정도 걸렸다.

## 내가 실제로 했던 질문들

처음에는 어떤 질문을 해야 할지 막막했다. 몇 가지 시행착오 끝에 나한테 효과적이었던 질문 유형을 찾았다.

**피드백 요청.** "최근에 제가 올린 PR 중에 개선할 부분이 있었을까요?" 이걸 처음 물어봤을 때 리드가 잠깐 생각하더니 말했다. "코드 자체는 괜찮은데, PR 설명이 좀 부실할 때가 있어. 리뷰어가 맥락을 파악하려면 PR 설명이 중요한데, 가끔 제목만 있고 본문이 없더라고." 이건 슬랙이나 코드 리뷰에서는 안 나왔을 피드백이었다. 그 뒤로 PR 설명을 꼼꼼하게 쓰게 됐고, 리뷰 속도가 눈에 띄게 빨라졌다.

**의사결정 과정 질문.** "지난번 기술 스택 결정할 때 왜 A를 골랐는지 궁금한데요." 이런 질문을 하면 리드가 당시 고려했던 것들을 설명해준다. 트레이드오프, 팀 상황, 비즈니스 요구사항. 이런 대화에서 배우는 게 많다. 단순히 기술적인 판단이 아니라 여러 조건을 고려해서 결정을 내리는 과정을 간접적으로 경험할 수 있다.

**커리어 방향.** "프론트엔드 쪽에서 더 깊이 가려면 앞으로 뭘 공부하면 좋을까요?" 이건 좀 뻔한 질문 같지만, 실제로 리드마다 답이 다르다. 어떤 분은 성능 최적화를 강조하고, 어떤 분은 시스템 디자인 이해를 중요시한다. 그 사람의 경험에서 우러나오는 답이라 책에서 읽는 것과 다르다.

## 1:1에서 하면 안 되는 것

반대로 피해야 할 패턴도 있었다.

불만만 늘어놓는 것. 한 번은 팀 프로세스에 대한 불만을 1:1에서 쏟아낸 적이 있다. "스프린트 플래닝이 너무 길어요", "이 코드 왜 이렇게 되어 있는지 모르겠어요", "배포 프로세스가 불편해요". 리드가 듣고 나서 물었다. "그럼 어떻게 바꾸면 좋겠어?" 나는 대안을 생각해본 적이 없었다. 그냥 불편하다는 것만 말한 거다.

그 이후로는 불만이 있으면 "문제 + 내가 생각한 대안" 형태로 말하려고 한다. "배포 프로세스가 좀 복잡한데, 이 부분을 스크립트로 자동화하면 어떨까요?" 같은 식으로. 완벽한 대안이 아니어도 된다. 방향성만 있으면 대화가 건설적으로 흘러간다.

다른 팀원 뒷담화. 이건 당연한 건데 의외로 경계가 모호할 때가 있다. "A씨랑 일할 때 커뮤니케이션이 좀 어려워요"라고 말하는 건 괜찮다. 근데 "A씨가 일을 잘 안 해요"는 다른 문제다. 전자는 협업 방식에 대한 고민이고, 후자는 평가다. 리드한테 다른 팀원에 대한 평가를 하는 순간 관계가 복잡해진다.

## 리드도 사람이다

한 가지 더 깨달은 건, 리드도 이 1:1에서 뭔가를 얻고 싶어한다는 거다.

어느 날 1:1에서 리드가 먼저 물어봤다. "솔직히 요즘 팀 분위기 어떤 것 같아?" 처음에는 "좋은데요?"라고 답하려다가, 잠깐 생각하고 솔직하게 말했다. "사실 최근에 배포 이후에 핫픽스가 좀 잦아서 다들 좀 지쳐 보이긴 해요." 리드가 "그렇지, 나도 그게 좀 걱정이었어"라고 했다. 그 다음 주 레트로에서 배포 프로세스 개선이 안건으로 올라왔다.

리드는 팀원들이 뭘 생각하는지 알고 싶은데 직접 물어보면 솔직한 답을 듣기 어렵다는 걸 안다. 1:1은 그나마 솔직하게 얘기할 수 있는 공간이다. 그 신뢰를 깨지 않으면서도 유용한 정보를 주는 것, 그게 팀원으로서 1:1에서 할 수 있는 가장 큰 기여인 것 같다.

## 어려운 얘기를 꺼내는 타이밍

1:1에서 가장 어려운 건 민감한 주제를 꺼내는 거다. 연봉 얘기, 팀 이동 희망, 특정 업무에 대한 불만. 이런 건 평소에 말하기 어렵다.

한번은 특정 프로젝트에서 빠지고 싶다는 얘기를 꺼내야 하는 상황이었다. 레거시 유지보수만 3개월째 하고 있었는데, 새로운 프로젝트에 참여하고 싶었다. 근데 직접적으로 "이 프로젝트 하기 싫어요"라고 말하면 불성실해 보일까 봐 걱정됐다.

고민 끝에 이렇게 말했다. "현재 맡고 있는 유지보수 작업은 안정적으로 운영하고 있는데, 성장 관점에서 새로운 도전이 필요한 시점인 것 같습니다. 새 프로젝트에 부분적으로라도 참여할 수 있을까요?" 리드가 바로 답을 주진 않았지만, 2주 뒤에 새 프로젝트의 일부 기능을 나한테 할당해줬다. 말하지 않았으면 계속 같은 작업만 했을 거다.

타이밍도 중요하다는 걸 배웠다. 팀이 바쁜 시기에 "저 이 작업 안 하고 싶어요"는 타이밍이 안 좋다. 스프린트가 비교적 여유로운 시점, 또는 분기 계획을 세우기 전이 적절하다. 1:1이 정기적으로 있으니까 기다렸다가 적절한 타이밍에 꺼낼 수 있다는 게 장점이다.

## 매주 할 필요는 없다

우리 팀은 주 1회 1:1을 하는데, 솔직히 매주 30분 분량의 대화 거리가 있지는 않다. 어떤 주는 "특별히 할 말 없는데요"가 진짜일 때가 있다. 그럴 때는 무리하게 대화를 끌어내지 않아도 된다. "이번 주는 괜찮아서 15분만 하고 마치겠습니다"라고 하면 리드도 시간을 아낄 수 있어서 좋아한다.

중요한 건 빈도가 아니라 질이다. 2주에 한 번 깊은 대화를 하는 게 매주 형식적으로 만나는 것보다 낫다. 물론 이건 팀 문화에 따라 다르고, 리드와 합의가 필요한 부분이다.

한 가지 팁이 있다면, 1:1 끝나고 나서 짧게 메모를 남기는 거다. "오늘 리드가 해준 말 중에 핵심은 이것"이라고 한 줄만 적어놓는다. 나는 노션에 1:1 로그를 쌓고 있는데, 3개월쯤 지나고 쭉 보면 대화의 흐름이 보인다. "3개월 전에는 이걸 고민했구나, 지금은 해결됐네"라는 식으로. 이게 커리어를 되돌아볼 때도 유용하고, 연봉 인상이나 성과 평가 때 자기 어필 자료로 쓸 수도 있다.

요즘은 1:1이 기다려질 때가 있다. 일주일 동안 일하면서 "이건 1:1 때 물어봐야지"라고 메모해둔 게 있으면 그렇다. 그 메모가 없는 주에는 여전히 좀 부담스럽지만, 최소한 "오늘은 뭘 말하지?"에서 "이번 주는 별일 없었으니 짧게 가자"로 바뀐 것만으로도 꽤 나아졌다고 생각한다.

리드가 바뀌면 또 처음부터다. 전 리드와 잘 맞았던 방식이 새 리드한테는 안 통할 수 있다. 사람마다 1:1에 대한 기대가 다르니까. 새 리드가 오면 "1:1에서 어떤 얘기를 주로 하면 좋을까요?"라고 먼저 물어보는 것도 좋은 시작인 것 같다.


사이드 프로젝트를 여러 개 만들었다. 대부분 깃허브 리포지토리에서 잠자고 있다. "만드는 건 재미있는데 아무도 안 쓰는" 프로젝트의 무덤.

이번에는 다르게 해보기로 했다. 코드를 한 줄도 쓰기 전에, 사람들이 돈을 낼 문제인지부터 확인하는 것.

## 아이디어: 문제에서 시작

기술이 아니라 문제에서 시작했다. 직접 겪은 문제.

프리랜서 프로젝트를 할 때 견적서를 만드는 게 귀찮았다. 매번 구글 시트를 복사해서 수정하고, PDF로 변환하고, 메일로 보내고. 프리랜서 개발자뿐 아니라 디자이너, 마케터도 비슷한 고충이 있을 거라 추측했다.

"프리랜서를 위한 간단한 견적서 생성 도구." 이 한 문장이 아이디어였다.

## 검증: 코드 전에 고객

아이디어가 있으면 바로 코드를 쓰고 싶다. 그 충동을 참았다.

대신 두 가지를 했다.

**1. 대화.** 프리랜서 커뮤니티(디스코드, 카카오톡 오픈채팅)에서 "견적서 어떻게 만드세요?"라고 물어봤다. 10명과 대화했다. 8명이 "구글 시트나 한글 파일로 만든다"고 했다. "더 좋은 방법이 있으면 쓸 의향이 있나요?"에 대부분 "월 5천 원 정도면 쓸 것 같다"고 답했다.

**2. 랜딩 페이지.** 제품이 없는 상태에서 랜딩 페이지만 만들었다. 핵심 기능을 설명하고, "출시 알림 받기" 이메일 수집 폼을 넣었다. 1주일 만에 120명이 이메일을 남겼다.

120명이면 된다. 만들자.

## MVP: 최소한만

개발자의 함정은 "기능을 더 넣고 싶은 욕구"다. 결제 연동도 넣고, 대시보드도 만들고, 다국어 지원도 하고 싶다. 전부 참았다.

MVP에 넣은 기능은 딱 세 가지:
1. 견적서 템플릿 선택
2. 항목·금액 입력
3. PDF 다운로드

로그인도 없었다. 데이터 저장도 없었다. 들어와서 입력하고 PDF로 받고 끝. 기술 스택은 Next.js + Tailwind CSS. 데이터베이스도 필요 없었다. 2주 만에 만들었다.

## 출시와 첫 반응

이메일을 모아뒀던 120명에게 출시 알림을 보냈다. 첫 주 방문자 89명, 실제 사용자(PDF 다운로드) 34명.

피드백이 들어왔다. "저장이 안 돼서 다시 입력해야 하는 게 불편해요", "로고를 넣을 수 있으면 좋겠어요", "보낸 견적서를 관리하고 싶어요".

피드백 중 가장 많이 언급된 것부터 구현했다. 저장 기능(이제 DB가 필요해졌다), 로고 업로드, 견적서 목록.

## 유료 전환

무료로 2개월 운영하면서 사용자를 모으고 피드백을 반영했다. 200명 정도가 꾸준히 쓰고 있을 때 유료화를 시작했다.

가격 전략: 무료 플랜은 월 3건까지, 유료 플랜(월 5,900원)은 무제한 + 로고 + 커스텀 템플릿.

유료 전환 첫 달: 7명.

```
월 수익: 7 × 5,900 = 41,300원
```

4만 원. 서버 비용 빼면 남는 게 거의 없다. 하지만 처음으로 "내가 만든 것에 돈을 내는 사람"이 생겼다는 사실이 의미가 있었다.

## 성장

6개월이 지난 시점에서 유료 구독자가 43명이 됐다. 월 매출 약 25만 원. 아직 커피값 수준이지만, 안정적으로 늘어나고 있다.

가장 효과적이었던 성장 채널은 블로그 SEO였다. "프리랜서 견적서 쓰는 법", "견적서 양식 무료" 같은 키워드로 검색 유입이 들어왔다. 유료 광고는 효과가 없었다. 단가 대비 전환율이 나오지 않았다.

입소문도 있었다. "이거 편하다"고 다른 프리랜서에게 추천하는 사용자가 생기면서 자연 성장이 생겼다.

## 배운 것

**코드보다 문제가 먼저다.** 기술적으로 멋진 제품이 아니라, 문제를 해결하는 제품이 팔린다. MVP의 코드는 부끄러운 수준이었지만, 사용자는 코드를 보지 않는다.

**완벽하지 않아도 출시한다.** 2주짜리 MVP를 출시하는 게, 6개월짜리 완성품을 준비하는 것보다 빠르게 시장을 검증한다.

**개발자의 시간은 비싸다.** 1인 SaaS에서 가장 큰 비용은 서버비가 아니라 개발자인 내 시간이다. 시간당 가치를 환산하면, 어떤 기능을 직접 만들지 말고 외부 서비스를 붙일지 판단이 달라진다.

**수익은 느리게 온다.** 1달 만에 수익을 기대하면 좌절한다. 6개월, 1년을 바라보고 꾸준히 개선하는 인내가 필요하다.

월급 외의 소득이 생긴다는 건 심리적으로 다른 의미가 있다. 금액의 크기가 아니라, "내가 만든 가치에 사람들이 돈을 낸다"는 경험. 이건 회사에서 월급을 받는 것과 질적으로 다른 종류의 성취감이다.



오픈소스에 기여하고 싶다는 생각은 오래전부터 있었다. GitHub 프로필에 초록색 잔디만 사이드 프로젝트로 채우는 것보다, 실제로 사람들이 쓰는 프로젝트에 무언가를 보태고 싶었다. "오픈소스 기여자"라는 타이틀이 개발자로서 멋있어 보이기도 했고.

하지만 실행으로 옮기기까지 1년이 넘게 걸렸다. 이유는 단순했다. 무서웠다.

## 이슈 탭을 열고 닫기를 반복한 3개월

처음에는 매일 쓰는 라이브러리의 GitHub 저장소를 구경하는 것부터 시작했다. 코드를 읽어보고, 이슈 탭을 열어보고, PR을 구경했다. 이슈에 달린 토론을 읽으면서 "나도 저 정도는 할 수 있을 것 같은데"라는 생각과 "저 사람들 대화 수준을 보면 나는 아직 멀었다"라는 생각이 번갈아 들었다.

`good first issue` 라벨이 붙은 이슈를 찾아봤다. 초보자도 할 수 있는 쉬운 이슈라고 들었는데, 막상 열어보면 쉽지 않았다. "문서에서 이 부분의 예제를 추가해주세요" 같은 건 그나마 접근 가능해 보였는데, 이미 다른 사람이 "제가 하겠습니다"라고 코멘트를 달아놓은 경우가 대부분이었다. 인기 있는 프로젝트일수록 경쟁이 심했다.

코드 관련 이슈는 더 어려웠다. "이 함수에서 엣지 케이스 처리가 빠져 있습니다" 같은 이슈를 보면, 일단 그 함수가 어디에 있는지 찾는 것부터 막막했다. 프로젝트 구조를 이해해야 하고, 빌드 환경을 세팅해야 하고, 테스트를 돌려봐야 한다. "good first issue"라는 라벨이 무색하게, 프로젝트에 진입하는 것 자체가 큰 허들이었다.

3개월 동안 이슈 탭을 열고, 읽고, "나중에 해야지" 하고 닫기를 반복했다.

## 버그를 발견하다

전환점은 의외로 일상에서 왔다. 회사 프로젝트에서 날짜 처리 라이브러리를 쓰고 있었는데, 특정 타임존에서 날짜가 하루 밀리는 버그를 발견했다. 처음에는 내 코드의 문제인 줄 알고 한참을 디버깅했다. 그런데 아무리 봐도 내 코드는 맞았고, 라이브러리 쪽의 타임존 변환 로직에서 문제가 발생하고 있었다.

라이브러리 코드를 까봤다. UTC 오프셋을 계산하는 부분에서 서머타임(DST) 전환 시점을 고려하지 않는 케이스가 있었다. 한국에서는 서머타임이 없어서 대부분의 한국 개발자가 겪지 않는 버그였는데, 우리 서비스가 유럽 타임존도 지원해야 해서 발견된 거였다.

이걸 이슈로 올릴까 말까 고민했다. "내가 잘못 읽은 거면 어쩌지?" "이미 알려진 이슈일 수도 있는데, 중복 이슈를 올리면 민폐 아닌가?" 이런 걱정이 한가득이었다.

기존 이슈를 전부 검색해봤다. 비슷한 이슈가 없었다. 그래서 용기를 내서 이슈를 작성했다.

## 이슈 하나 쓰는 데 2시간

이슈를 쓰는 데 2시간이 걸렸다. 진짜 2시간이다.

제목을 뭐라고 할지부터 고민이었다. 영어로 써야 하는데, "bug"라고 하면 너무 단정적인 것 같고, "unexpected behavior"라고 하면 너무 모호한 것 같고. 결국 "Incorrect date conversion when crossing DST boundary" 정도로 정했다.

본문은 더 어려웠다. 재현 단계를 명확하게 적어야 했다. 어떤 입력값으로, 어떤 타임존에서, 어떤 결과가 나왔고, 기대하는 결과는 뭔지. 이걸 영어로, 그것도 전 세계 누가 봐도 이해할 수 있게 써야 했다. 코드 예제를 만들고, 스크린샷을 찍고, 라이브러리 버전과 Node 버전을 적었다.

제출 버튼을 누르기 전에 세 번이나 다시 읽었다. 오탈자는 없는지, 혹시 오해를 살 만한 표현은 없는지, 너무 당연한 걸 물어보는 건 아닌지. 손이 떨렸다고 하면 과장이지만, 심장은 확실히 빨라졌다.

버튼을 눌렀다.

## 메인테이너의 답변

30분 만에 답변이 왔다. 프로젝트의 메인테이너 중 한 명이었다.

"Great catch! This is indeed a bug in our timezone offset calculation. The DST transition edge case was missed. Would you be interested in submitting a fix?"

솔직히 놀랐다. 두 가지 측면에서.

첫째, 답변이 빠르고 친절했다. 무시당하거나, "이미 알고 있습니다" 같은 차가운 답변을 예상했는데, 오히려 칭찬을 해줬다. "Great catch"이라니. 내가 2시간 동안 고민하며 쓴 이슈를 가치 있는 것으로 인정해준 느낌이었다.

둘째, 직접 고쳐보겠냐고 물어봤다. 이건 예상 못했다. 보통 메인테이너가 직접 고치거나, 다른 기여자에게 맡기는 줄 알았다. 나 같은 처음 온 사람에게 기회를 주는 거였다.

"I'd love to try!"라고 답했다. 타이핑하면서 "이게 진짜 되는 건가?"라고 생각했다.

## PR을 만들기까지

프로젝트를 포크하고, 클론하고, 로컬에 빌드 환경을 세팅하는 데만 한 시간이 걸렸다. Contributing 가이드를 읽었다. 코드 스타일 규칙, 커밋 메시지 컨벤션, 테스트 실행 방법. 회사 프로젝트에서는 이미 세팅된 환경에서 일하니까 이런 초기 세팅에 시간을 쏟을 일이 없는데, 새 프로젝트에 처음 뛰어드는 건 이런 과정이 필요했다.

버그를 고치는 것 자체는 생각보다 단순했다. DST 전환 시점을 체크하는 조건문 하나를 추가하는 거였다. 코드 변경은 15줄 정도. 하지만 그 15줄을 쓰기 위해 관련 코드를 200줄 넘게 읽었다. 함수의 맥락을 이해해야 정확한 위치에 정확한 수정을 넣을 수 있으니까.

테스트를 작성하는 게 더 오래 걸렸다. 코드 수정보다 테스트 코드가 세 배는 길었다. 여러 타임존, 여러 날짜에 대해 DST 전환을 검증하는 케이스를 만들었다. 기존 테스트 패턴을 참고해서 스타일을 맞췄다.

PR을 올리기 전에 Contributing 가이드를 한 번 더 읽었다. PR 설명에는 관련 이슈 번호를 링크하고, 변경 사항을 요약하고, 테스트를 어떻게 했는지 적었다. 커밋 메시지도 프로젝트 컨벤션에 맞게 수정했다.

PR 제출.

## 코드 리뷰라는 경험

다음 날 코드 리뷰가 달려 있었다. 메인테이너가 직접 리뷰를 해줬다.

리뷰 코멘트는 네 개였다. 하나는 변수명 제안. "offset"보다 "utcOffset"이 더 명확하다고. 하나는 테스트 케이스 추가 요청. 남반구 타임존도 커버하면 좋겠다고. 하나는 코드 스타일. 프로젝트에서 쓰는 함수 명명 규칙에 맞추라고. 마지막 하나는 칭찬. "The test cases are thorough. Nice work."

회사에서 받는 코드 리뷰와는 분위기가 달랐다. 회사에서는 서로 알고 있는 사이라 맥락이 공유된 상태에서 리뷰가 이루어진다. 오픈소스에서는 처음 보는 사람의 코드를 리뷰하면서도 존중하는 톤을 유지해야 한다. 그리고 이 메인테이너는 그걸 잘 해줬다.

지적할 때도 "이건 틀렸다"가 아니라 "이렇게 하면 더 좋을 것 같은데 어떻게 생각해?"라는 식이었다. 강제가 아니라 제안. 나의 의견도 물어봐 줬다. "이 부분은 이런 이유로 이렇게 했는데요"라고 답하면 "아, 그런 맥락이 있었구나. 그러면 유지하자"라고 수용하기도 했다.

코멘트를 반영하고, 다시 커밋하고, 리뷰가 한 번 더 왔다. "LGTM." 그리고 머지.

GitHub에 "Merged" 라벨이 붙은 순간의 기분은, 처음 코딩을 배우고 "Hello World"를 출력했을 때랑 비슷했다. 뭔가 새로운 세계에 발을 들인 느낌.

## 기여하면서 배운 것들

이 경험에서 배운 게 코드를 고치는 기술보다 훨씬 많았다.

**문서화의 중요성.** 이슈를 쓸 때, 재현 단계를 명확하게 적는 게 얼마나 중요한지 몸으로 느꼈다. 회사에서 버그 리포트를 올릴 때도 이전과 확연히 달라졌다. "안 돼요"가 아니라 "이런 조건에서 이렇게 하면 이런 결과가 나옵니다"로 쓰게 됐다. 이게 상대방의 시간을 엄청나게 절약해준다.

**코드 품질 기준.** 오픈소스 프로젝트의 코드를 읽으면서, 내 코드의 기준이 올라갔다. 변수명 하나, 함수 분리 하나에 대한 감각이 달라졌다. 전 세계 사람이 읽을 코드를 쓴다고 생각하면 자연스럽게 더 신경 쓰게 된다.

**영어 커뮤니케이션.** 기술 영어에 대한 두려움이 많이 줄었다. 완벽한 영어가 아니어도 된다. 명확하기만 하면 된다. 문법이 좀 어색해도 재현 단계가 정확하면 아무도 영어를 지적하지 않았다. 중요한 건 내용이지 표현이 아니었다.

**글로벌 협업의 감각.** 시차가 다른 사람과 비동기로 소통하는 법을 배웠다. 코멘트를 달 때 맥락을 충분히 담아야 한다는 것. 상대방이 내 코멘트를 읽을 때 나는 자고 있을 수 있으니까, 추가 질문 없이 이해할 수 있도록 써야 한다는 것. 이건 리모트 워크에서도 똑같이 적용되는 기술이다.

## 두 번째 기여는 훨씬 쉬웠다

첫 기여 이후 한 달쯤 지나서, 다른 프로젝트에서 비슷한 기회가 왔다. 이번에는 공식 문서에서 오래된 예제 코드를 최신 API에 맞게 업데이트하는 작업이었다.

놀라운 건, 이번에는 무섭지 않았다는 거다. 이슈를 열고, 코멘트를 달고, PR을 보내는 흐름을 이미 한 번 경험했으니까. 문서 수정이라 코드보다 진입 장벽도 낮았다.

첫 번째가 어려운 이유는 기술적 난이도 때문이 아니다. "내가 이 프로젝트에 뭔가를 보태도 되는 사람인가?"라는 심리적 장벽 때문이다. 한 번 넘으면, 두 번째부터는 그 장벽이 확 낮아진다.

## 오픈소스 기여를 망설이는 사람에게

지금 오픈소스 기여를 하고 싶은데 망설이고 있다면, 한 가지만 기억하면 좋겠다. 메인테이너들은 대부분 새로운 기여자를 환영한다. 그들도 과거에 처음 기여했던 시절이 있었고, 누군가의 도움으로 성장했다는 걸 안다. 물론 예외는 있다. 불친절한 메인테이너도 있고, 반응 없이 방치되는 프로젝트도 있다. 하지만 그건 그 프로젝트의 문제지 내 문제가 아니다. 다른 프로젝트를 찾으면 된다.

시작은 거창하지 않아도 된다. 오타 수정, 문서 개선, 에러 메시지 명확화. 이런 것들도 유의미한 기여다. 코드를 한 줄도 안 바꿔도 된다. 좋은 버그 리포트 하나가 프로젝트에 큰 도움이 되기도 한다.

나의 첫 기여는 15줄짜리 버그 수정이었다. 세상을 바꾼 건 아니다. 하지만 그 15줄이 나를 바꿨다. 코드를 쓰는 게 나 혼자만의 일이 아니라, 전 세계 개발자들과 연결된 일이라는 감각. 이건 사이드 프로젝트 열 개를 만들어도 얻기 어려운 거다.


입사 후 처음 6개월은 매일이 성장이었다. Git을 처음 써보고, React 컴포넌트를 처음 만들고, PR을 처음 올리고, 코드 리뷰를 처음 받고. 매주 "이번 주에 이런 걸 새로 알았다"고 말할 수 있었다. 회사 가는 게 재미있었다. 새로운 걸 배우는 속도가 체감될 정도로 빨랐으니까. 월요일이 싫지 않았다. 출근하면 배울 게 있었다.

그러다가 어느 순간 멈춘 것 같은 느낌이 왔다.

## 정체기라는 늪

대략 입사 8개월 차쯤이었다. 매일 하는 일이 비슷해졌다. 컴포넌트 만들고, API 연결하고, 스타일링하고, 코드 리뷰 받고. 스프린트가 시작되면 JIRA 티켓을 가져와서 처리하고, 스프린트가 끝나면 회고하고, 다음 스프린트가 시작된다. 새로 배우는 건 없고 반복만 하는 느낌. 회사에서 시키는 일은 할 수 있는데, 그렇다고 실력이 느는 것 같지는 않았다.

이때가 제일 힘들었던 것 같다. 성장하고 있다는 느낌이 사라지면 일이 그냥 노동이 된다. 아침에 일어나서 "오늘도 같은 일이겠지" 하는 생각. 코드를 치는데 뭔가 기계적인 느낌. 복붙에 가까운 작업이 많아지고, 도전적인 이슈는 시니어한테 가고, 나한테 오는 건 "여기 텍스트 변경해주세요", "이 페이지에 필터 추가해주세요" 같은 것들. 물론 이것도 필요한 일이지만, 성장하고 있다는 실감이 없었다.

주변에 말하기도 애매했다. "일이 힘들어"는 아니었고, "일이 재미없어"도 정확하지 않았다. 그냥 "제자리인 것 같아"라는 감각. 이걸 이해해주는 사람이 많지 않았다. "그래도 월급 받잖아"라는 말이 돌아올 뿐이었다.

TIL을 쓰려고 해도 쓸 게 없는 날이 늘어났다. "오늘 배운 것: 없음." 이런 날이 일주일에 3-4번이었다. 그러면 자연스럽게 "나는 왜 성장을 안 하지?"라는 질문이 따라온다.

## 계단을 발견한 순간

정체기가 한 3개월 정도 지속됐다. 그러다가 팀에서 새 프로젝트가 시작됐다. 기존 레거시 페이지를 Next.js App Router로 마이그레이션하는 작업이었다. Server Component 개념이 처음이었고, 기존 클라이언트 사이드 상태 관리 로직을 서버 쪽으로 옮기는 게 처음에는 감이 안 잡혔다. "서버에서 렌더링하는데 useState를 못 쓴다고? 그러면 인터랙션은 어떻게 하지?"

근데 막상 부딪히니까, 정체기 동안 반복했던 기본기가 발휘됐다. 컴포넌트 설계 패턴이 손에 익어 있었다. 100번 넘게 만들어본 리스트 컴포넌트, 폼 컴포넌트, 모달 컴포넌트. 데이터 페칭 흐름도 감으로 알았다. useEffect 안에서 API 호출하고, 로딩/에러/데이터 상태 관리하는 패턴이 자동으로 나왔다. 에러 핸들링도 여러 번 겪어봤으니까 "이 경우엔 이렇게 처리해야지"가 바로 떠올랐다.

새로운 개념인 Server Component를 흡수하는 속도가 예전보다 훨씬 빨랐다. 기본기가 탄탄하니까, 새 개념이 기존 지식 위에 얹어지는 느낌이었다. 정체기처럼 느껴졌던 그 시간이 사실은 기본기를 다지는 시간이었던 거다.

일주일 만에 서버 컴포넌트 패턴이 익숙해졌고, 2주 만에 다른 팀원한테 설명할 수 있게 됐다. 3주째에는 팀 내 가이드 문서를 썼다. 이때 처음으로 "아, 성장이 계단형이구나" 하는 걸 몸으로 느꼈다. 평평한 구간이 한참 이어지다가, 갑자기 올라가는 순간이 오는 거다.

## 두 번째 정체기

한 번 경험했으니까 다음은 좀 편할 줄 알았는데, 아니었다. 두 번째 정체기는 좀 다른 형태로 왔다.

기술적으로는 꽤 다양한 걸 할 수 있게 됐다. React, Next.js, TypeScript, 상태 관리, CSS-in-JS, 테스팅. 근데 "깊이"가 없다는 느낌이 들었다. 이것저것 할 줄은 아는데, 뭔가 하나를 깊게 파고들었다는 확신이 없었다. 시니어한테 질문을 받으면 "대충은 아는데 정확히는 모르겠어요"라는 대답이 많아졌다.

React의 reconciliation 알고리즘이 정확히 어떻게 돌아가는지. 브라우저 렌더링 파이프라인에서 reflow가 언제 발생하는지. 번들러가 tree shaking을 어떻게 하는지. V8 엔진이 JavaScript를 어떤 단계로 처리하는지. 겉핥기로만 알고 있었다. 면접에서 물어보면 한 문장은 대답하겠는데, "더 자세히 설명해보세요"라고 하면 말문이 막힐 수준.

이 정체기는 더 길었다. 한 4-5개월. 회사 일은 잘 돌아가는데 개인적인 성장감은 제로에 가까웠다. 일은 할 수 있지만 배우는 건 없는 상태. 이게 생각보다 고통스럽다.

## 정체기에 한 것들

첫 번째 정체기 때는 그냥 버텼다. 특별히 한 건 없고, 시간이 지나다 보니 새 프로젝트를 만났다. 운이었다. 두 번째는 운에 맡기지 않고 조금 다르게 접근했다.

일단 깊이가 없다고 느끼는 주제를 하나 골랐다. 브라우저 렌더링. 이걸 제대로 이해하면 프론트엔드 성능 최적화의 근간이 되니까. 출퇴근 시간에 관련 아티클을 읽었다. MDN 문서를 영어로 읽고, 크롬 DevTools 퍼포먼스 탭으로 실제 프로젝트를 프로파일링해봤다. web.dev의 Core Web Vitals 문서를 처음부터 끝까지 읽었다.

체감 성장은 없었다. 한 달 동안. 그냥 "읽었다"는 사실만 남았지, 실력이 는 느낌은 없었다. 정보가 머릿속에 들어오긴 하는데, 그게 실력으로 전환되는 느낌이 아니었다. 솔직히 이때 그만두고 싶었다. "이거 해봤자 뭐가 달라지나" 하는 생각. 퇴근 후에 힘들게 공부하는데 아무런 보상이 없는 느낌.

그런데 어느 날 팀 미팅에서 성능 이슈 논의가 나왔다. 특정 페이지가 느리다는 CS가 들어왔는데, 시니어가 "레이아웃 쉬프트가 문제일 수 있다"고 했을 때 내가 바로 알아들었다. 예전이면 "레이아웃 쉬프트가 뭐였지?" 하고 검색했을 텐데, CLS가 뭔지, 어떤 CSS 속성이 reflow를 유발하는지가 머리에 있었다. 거기서 내가 직접 DevTools 퍼포먼스 탭을 열고, Layout Shift 이벤트를 찾아서, 원인이 이미지 로딩 후 사이즈 변경이라는 걸 밝혔다. `width`와 `height` 속성을 명시하고 `aspect-ratio`를 추가하는 PR을 올렸다.

시니어가 "오 잘 찾았네"라고 했을 때, 그 한 달이 헛되지 않았다는 걸 느꼈다. 또 계단을 하나 올라간 거다.

## 선형을 기대하면 괴롭다

돌이켜보면, 정체기가 괴로운 이유는 성장이 선형일 거라는 기대 때문이었다. 매일 조금씩, 꾸준히, 우상향. 그래프로 그리면 대각선. 유튜브나 블로그에서 "매일 1% 성장하면 1년 후에 37배"라는 말을 많이 하는데, 현실은 그렇지 않았다.

현실은 한참 평평하다가 갑자기 올라가고, 또 평평하다가 갑자기 올라가는 계단이었다. 평평한 구간에 있을 때는 "나만 멈춰 있나?" 싶은데, 사실은 올라갈 준비를 하고 있는 거다. 그 준비라는 게 반복, 독서, 삽질, 실패 같은 눈에 안 보이는 것들이라서, 진행 중인지 멈춘 건지 구분이 안 된다. 다만 그걸 그 순간에 알기는 어렵다. 지나고 나서야 "아, 그때 쌓고 있었구나" 하고 깨닫는다.

지금 세 번째 정체기인 것 같다. 설계와 아키텍처 쪽. 코드 레벨에서는 어느 정도 자신이 생겼는데, 프로젝트 전체를 어떻게 구조화할지에 대해서는 아직 감이 없다. 시니어가 "이 기능은 이 레이어에 두는 게 맞다"고 할 때, 이유를 설명해달라고 하면 답이 "경험상"이다. 그 "경험상"을 쌓는 중인데, 언제 계단이 올라갈지는 모르겠다.

모르겠으니까 그냥 계속 한다. 지금까지 두 번 올라갔으니까, 세 번째도 올 거라는 희망이 있다. 희망이라기보다는, 경험에 기반한 기대라고 하는 게 맞겠다. 이번에도 어느 날 갑자기 "아, 이래서 이렇게 설계하는 거구나" 하는 순간이 올 거라고 믿는다. 근거는 없다. 다만 전에 두 번 그랬으니까.

가끔 주니어 개발자 커뮤니티에서 "요즘 성장하는 느낌이 안 들어요"라는 글을 본다. 댓글에 "이것저것 해보세요", "사이드 프로젝트 하세요" 같은 조언이 달리는데, 그것보다는 "원래 그렇다"고 말해주고 싶다. 정체기는 실력이 멈춘 게 아니라, 다음 계단을 준비하는 시간이다. 체감이 안 되서 괴로운 거지, 실제로는 무언가가 쌓이고 있다. 적어도 내 경험은 그랬다.

코딩만 하면 생기는 일#

시도한 것들#

취미의 기준#