H-9: 마이크로 프론트엔드 — 화면을 여러 팀이 나눠 만들 때

안녕하세요, 홍순구 튜터입니다.

지난 시간 마무리에서 "다음 시간에는 화면을 여러 팀이 나눠 만드는 이야기로 넘어간다" 고 말씀드렸죠. 오늘이 그 시간이고, 동시에 이 과목의 마지막 시간입니다.

지금까지 우리는 인스타그램 클론 하나를 계속 키워왔습니다. 정적인 HTML 이었던 것이 React 컴포넌트가 되고, 라우터와 서버 상태가 붙고, Next.js로 서버까지 넘어갔고, 테스트와 인증이 얹혔고, 오류와 속도를 재는 눈이 생겼고, 번들을 들여다보고, 네 나라 말을 하게 됐는데, 이 모든 과정을 한 저장소에서 한 사람이 해왔다는 게 실무와는 다른 지점이에요.

피드 팀, 검색 팀, 메시지 팀이 따로 있고 각자 배포 주기가 다른데, 검색 팀이 버튼 색 하나 바꾸겠다고 앱 전체를 다시 빌드하고 다시 배포해야 한다면 어떨까요. 게다가 그 배포에 다른 두 팀의 미완성 코드까지 섞여 들어간다면요.

오늘 다룰 것은 그 문제를 푸는 방법이면서, 대부분의 경우 그 방법을 쓰지 말아야 하는 이유이기도 합니다. 오늘은 기술을 배우는 시간이면서, 배운 기술을 안 쓰기로 결정하는 연습을 하는 시간이에요.

 오늘의 여정

 1. 원격 앱이 자기 코드를 내보낸다   remoteEntry.js 라는 이름표
 2. 호스트가 실행 중에 가져온다      디스크에 없는 파일을 import 한다
 3. 원격만 배포해도 호스트는 그대로   해시를 대조해서 확인한다
 4. React 를 두 번 싣지 않는 일      shared 는 최적화가 아니었다
 5. 그 대가를 잰다                   파일 1개 → 24개
 6. 경계를 넘는 약속은 조용히 깨진다  빌드는 초록인데 화면이 없다
 7. 그래서 우리 앱엔 안 넣습니다      쓸지 말지 이전에 쓸 수 있는지

💡 오늘 수업의 핵심 — "나눌 수 있다는 것과 나눠야 한다는 것은 다릅니다"

🎯 학습 목표

• 따로 빌드된 앱의 코드를 실행 중에 가져와 화면에 그리고, 그것이 정말 따로 배포되는지 산출물 해시로 확인합니다.
• 여러 앱이 React 같은 라이브러리를 나눠 쓰는 방식을 이해하고, 그 선언을 뺐을 때 무엇이 무너지는지 직접 봅니다.
• 이 구조가 물리는 비용을 바이트와 파일 수로 재고, 어떤 규모에서 손해인지 나눗셈으로 판단합니다.
• 검색으로 만나는 최신 정보가 실제로 존재하는지 확인하는 방법을 익힙니다.

Step 1: 원격 앱이 자기 코드를 내보낸다

나누고 싶어지는 순간

먼저 무엇을 나눌지 정해봅시다. 우리 앱에서 가장 독립적인 조각 하나를 고르면 좋아요 버튼인데, 좋아요는 눌리면 숫자가 올라가고 색이 바뀌는 게 전부라서 피드가 어떻게 생겼는지, 프로필이 뭘 보여주는지 몰라도 됩니다.

이 버튼을 다른 팀이 소유한 별개의 앱으로 떼어낸다고 해보면, 그 팀은 자기 저장소에서 자기 일정으로 배포하게 됩니다.

떼어낸 쪽을 원격(remote), 그걸 가져다 쓰는 쪽을 호스트(host)라고 부릅니다.

내보낼 것을 고른다

원격 앱부터 만듭니다. 평범한 Vite + React 앱인데 설정에 한 덩어리가 더 붙어요.

// scratch/h9-remote/vite.config.js
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { federation } from '@module-federation/vite'

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'like_app',
      filename: 'remoteEntry.js',
      // 밖으로 내보낼 것만 여기 적는다. 안 적은 파일은 남이 못 가져간다.
      exposes: { './LikeButton': './src/LikeButton.jsx' },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
  ],
  build: { target: 'chrome89' },
})

exposes가 핵심입니다. 이 앱에는 파일이 여러 개 있지만 밖으로 나가는 것은 ./LikeButton 하나뿐이에요. 나머지는 이 앱 안에서만 씁니다.

shared는 지금은 그냥 두고 Step 4에서 정면으로 다룹니다.

내보내는 컴포넌트 자체는 특별할 게 없어요.

// scratch/h9-remote/src/LikeButton.jsx
import { useState } from 'react'

export default function LikeButton({ initialCount }) {
  const [liked, setLiked] = useState(false)
  const count = initialCount + (liked ? 1 : 0)

  return (
    <button aria-pressed={liked} onClick={() => setLiked((v) => !v)}>
      {liked ? '♥' : '♡'} 좋아요 {count.toLocaleString('ko-KR')}개
    </button>
  )
}

B-2에서 만든 좋아요 토글과 거의 같습니다. aria-pressed는 E-7에서 아이콘 버튼에 붙였던 것이고, 자릿점은 지난 시간에 배운 방식 그대로예요.

빌드하면 생기는 것

빌드하면 dist/에 평소 보던 것들과 함께 파일 하나가 더 나옵니다.

 dist/remoteEntry.js    17.13 kB │ gzip: 5.74 kB

이게 이름표입니다. 이 앱이 무엇을 내보내는지, 어떤 라이브러리를 나눠 쓸 생각인지 적혀 있어요. 남의 앱은 이 파일 주소만 알면 됩니다.

💡 한 줄 정리

원격 앱은 exposes에 적은 것만 밖으로 내보내고, 무엇을 내보내는지는 remoteEntry.js라는 이름표에 적힌다.

Step 2: 호스트가 실행 중에 가져온다

디스크에 없는 파일을 import 한다

지금부터는 가져다 쓰는 쪽으로 넘어갑니다.

// scratch/h9-host/vite.config.js
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { federation } from '@module-federation/vite'

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'feed_app',
      // 주소가 코드에 들어간다. 빌드할 때가 아니라 「실행할 때」 이 주소로 받으러 간다.
      remotes: {
        like_app: {
          type: 'module',
          name: 'like_app',
          entry: 'http://localhost:5301/remoteEntry.js',
        },
      },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
  ],
  build: { target: 'chrome89' },
})

remotes에 이름과 주소를 적는데, 여기서 한 번 멈춰서 보실 게 있어요. 주소가 설정에 들어간다는 점이에요. 지금까지 우리가 import 하던 것은 전부 디스크에 있는 파일이었는데, 이번엔 아닙니다.

쓰는 쪽 코드를 보시면 더 분명해집니다.

// scratch/h9-host/src/main.jsx
import { createRoot } from 'react-dom/client'
import { Suspense, lazy } from 'react'

// C-8 에서 쓴 React.lazy 와 같은 문법인데, 가리키는 곳이 우리 파일이 아니다.
// 'like_app/LikeButton' 은 디스크에 없는 이름이다 — 실행 중에 네트워크로 찾아온다.
const LikeButton = lazy(() => import('like_app/LikeButton'))

createRoot(document.getElementById('root')).render(
  <main>
    <h1>피드</h1>
    <Suspense fallback={<p>불러오는 중…</p>}>
      <LikeButton initialCount={1240} />
    </Suspense>
  </main>,
)

lazy와 Suspense는 C-8에서 회원가입 화면을 쪼갤 때 이미 썼는데, 문법이 똑같고 다른 것은 import() 안에 적힌 이름뿐입니다.

'like_app/LikeButton'이라는 파일은 이 저장소 어디에도 없고 빌드할 때도 없는데, 브라우저가 화면을 그리다가 저 줄에 도착해서야 5301로 받으러 갑니다.

진짜로 그려지는지 확인

두 앱을 각각 빌드하고 원격은 5301, 호스트는 5302로 띄운 뒤 호스트를 열어봤습니다.

 <button aria-pressed="false">♡ 좋아요 1,240개</button>

떴는데, 이 버튼의 코드는 호스트 저장소에 한 줄도 없고 호스트가 아는 것은 주소 하나뿐이에요.

💡 한 줄 정리

호스트는 원격의 코드를 갖지 않고 주소만 갖는다. 그 주소로 가는 시점은 빌드할 때가 아니라 화면을 그리는 중이다.

Step 3: 원격만 배포해도 호스트는 그대로

이게 이 구조를 쓰는 이유 전부입니다

여기까지는 "그래서 뭐가 좋은데?" 싶으실 거예요. 지금부터가 본론입니다.

좋아요 버튼 팀이 하트 모양을 바꾸기로 했다고 해봅시다. 원격 앱의 파일 하나만 고치고 원격만 다시 빌드해요. 호스트는 건드리지 않아서, 다시 빌드하지도 다시 띄우지도 않습니다.

확인할 수 있게 호스트 산출물의 이름을 먼저 적어뒀습니다.

호스트 번들은 파일 이름까지 똑같은데, Vite가 붙이는 해시는 내용이 바뀌면 따라 바뀌죠. 안 바뀌었다는 것은 내용이 한 바이트도 안 달라졌다는 뜻인데, 사용자가 보는 화면은 바뀌었습니다.

이걸 실무 언어로 옮기면, 좋아요 팀은 피드 팀의 배포 일정을 기다리지 않아도 된다는 뜻이에요. 피드 팀에 "저희 배포해야 하는데 언제 나가세요?" 하고 물을 일이 없는 거죠.

앱이 하나일 때는 이게 문제가 아닌데, 팀이 여섯이고 각자 주에 몇 번씩 배포하려 하면 그때부터 문제가 됩니다.

무엇을 산 것인지 정확히

한 가지 정확히 해둘 게 있는데, 우리가 산 것은 배포 독립성이지 개발 독립성이 아니라는 점이에요.

좋아요 팀이 props 이름을 initialCount에서 count로 바꾸면 호스트는 그대로 깨지는데, 그 사실은 배포하는 순간에야 알게 됩니다. 예전 같으면 빌드할 때 알았을 텐데요.

이 맞바꿈이 오늘의 나머지 전부입니다.

💡 한 줄 정리

원격만 다시 배포해도 호스트 산출물은 한 바이트도 안 바뀐다. 이 구조가 파는 것은 이것 하나이고, 나머지는 전부 그 대가다.

Step 4: React를 두 번 싣지 않는 일

미뤄둔 한 줄

Step 1부터 설정에 계속 있었지만 설명을 미뤄둔 줄이 있죠.

// scratch/h9-remote/vite.config.js — 지금까지 미뤄둔 부분
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },

호스트도 React를 쓰고 원격도 React를 쓰는데, 아무 조치도 안 하면 브라우저가 React를 두 벌 받게 돼요. 용량도 문제지만 더 큰 문제가 있는데, React는 훅 상태를 자기 내부에 들고 있어서 두 벌이 돌면 원격의 useState가 엉뚱한 React를 붙잡고 터집니다.

singleton: true는 "이 페이지 안에 React는 하나여야 한다"는 선언인데, 먼저 자리를 잡은 쪽 것을 다 같이 씁니다.

이름이 오해를 부릅니다

shared라는 이름 때문에 이게 최적화 옵션처럼 보이는데, 중복을 없애서 용량을 줄이는 것 같은 느낌이죠.

빼봤습니다.

먼저 빌드 결과부터 봅시다.

뺐더니 작아졌는데, 24 kB 나요. 빌드는 원격도 호스트도 exit 0으로 통과하고 경고도 없습니다.

여기서 멈추면 "아, shared는 오히려 용량을 늘리는 거였네"라고 결론 내리게 됩니다.

그런데 화면이 없습니다

작아진 원격을 띄우고 호스트를 열어봤습니다.

 (빈 화면)

버튼이 안 나오는 정도가 아니라 <h1>피드</h1>까지 통째로 안 나오는데, 이건 호스트가 직접 쓴 글자예요.

이유는 이렇습니다. shared를 빼면 원격은 React를 어디서 얻을지 모르는 상태가 되고, 그래서 lazy가 실패하면서 그 실패가 위로 던져져 React 트리 전체가 죽습니다.

shared를 되돌리니 즉시 정상으로 돌아왔습니다.

⚠️ 두 가지를 함께 기억해두세요.

하나, shared는 최적화가 아니라 원격이 React를 얻는 유일한 통로입니다. 빼면 느려지는 게 아니라 안 돌아가요.

둘, 작아진 것이 좋아진 것이 아닙니다. 84,520 B는 108,749 B보다 작지만 그 작은 쪽은 아무것도 못 그립니다. 번들 크기만 보고 판단하면 정확히 반대로 읽게 돼요. 지난 세 시간 동안 번들을 들여다보며 계속 이야기한 것이 바로 이겁니다. 숫자는 그 자체로 좋고 나쁨을 말해주지 않아요.

 배포되는 것 : 호스트에도 React, 원격에도 React (예비용)
 전송되는 것 : 호스트 React 한 벌만

💡 한 줄 정리

shared는 중복을 줄이는 옵션이 아니라 원격이 라이브러리를 얻는 통로다. 빼면 산출물은 작아지고 앱은 안 돈다.

Step 5: 그 대가를 잰다

같은 화면을 두 방식으로

값을 한번 매겨봅시다. 공정하게 재려면 완전히 같은 화면을 두 방식으로 만들어야 해요.

대조군도 하나 더 만들었는데, 같은 좋아요 버튼, 같은 <h1>피드</h1>, 같은 React 버전인데 페더레이션만 없습니다. 옆 파일에서 그냥 import 해요.

// scratch/h9-plain/src/main.jsx
import { createRoot } from 'react-dom/client'
import LikeButton from './LikeButton.jsx'

createRoot(document.getElementById('root')).render(
  <main>
    <h1>피드</h1>
    <LikeButton initialCount={1240} />
  </main>,
)

브라우저가 실제로 받는 것

용량은 두 가지로 이야기할 수 있는데, 배포되는 바이트와 사용자가 받는 바이트이고 Step 4에서 봤듯이 이 둘이 다릅니다.

사용자에게 중요한 것은 받는 쪽이라 그걸 쟀는데, 브라우저가 내려받기를 끝낸 파일들의 실제 전송량을 전부 더한 값이에요.

24개 중 10개는 원격에서, 14개는 호스트에서 오는데, 그 파일들 이름에는 loadShare__react__, loadRemote__like_app_ 같은 협상하는 코드들이 섞여 있어요.

버튼 하나 그리는 데 파일 24개입니다.

배포되는 바이트로 재면 190,664 B 對 428,411 B로 2.25배이고, 전송으로 재면 2.33배예요. 어느 쪽으로 재도 두 배가 넘습니다.

이 숫자를 어떻게 읽어야 할까요

여기서 조심할 게 있는데, 이 실습 앱은 버튼 하나짜리이고 진짜 앱은 훨씬 큽니다.

양쪽에 똑같은 코드를 조금씩 더해가면서 다시 재봤는데, 대조군과 페더레이션 쪽에 완전히 같은 양을 넣었어요.

맨 오른쪽 칸을 보시면, 세금이 안 움직입니다. 앱을 세 배 가까이 키우는 동안 237,6xx B에서 오르내리는데, 가장 큰 값과 가장 작은 값의 차이가 145 B밖에 안 되는데도 배수는 2.25에서 1.43까지 내려갑니다.

 세금(절대값)  237,747 → 237,620      거의 안 움직인다
 배수          2.25배  →   1.43배      계속 내려간다
 달라진 것     앱 크기 = 나누는 값

페더레이션이 물리는 비용은 앱 크기와 무관한 고정비인데, 협상 코드와 런타임은 앱이 크든 작든 똑같이 들어가서 앱이 작으면 세금이 앱보다 커 보이고 앱이 크면 묻힙니다.

⚠️ 그래서 "몇 배"라는 말은 그 자체로는 아무 정보가 없습니다. 무엇으로 나눴는지를 함께 말해야 해요.

커리큘럼에는 "소규모는 단일 앱이 더 빠르다"고 적혀 있는데, 이제는 그게 왜인지 아시겠죠. 의견이 아니라 나눗셈이라서, 고정비를 작은 수로 나누면 크고 큰 수로 나누면 작아요.

이 비용은 바이트로만 오지 않는데, 파일 1개가 24개가 됐죠. 요청이 늘고, 받아올 출처가 둘로 늘고, 그중 하나는 우리가 관리하지 않는 서버인데, H-3와 H-4에서 잰 지표들이 전부 여기에 영향을 받아요.

💡 한 줄 정리

세금은 앱 크기와 거의 무관한 고정비라서, "몇 배"는 분모를 밝히지 않으면 아무 말도 안 한 것과 같다.

Step 6: 경계를 넘는 약속은 조용히 깨진다

빌드 로그에 계속 있던 것

지금까지 빌드할 때마다 로그에 이런 게 찍히고 있었습니다.

 Unable to compile federated types, Error: Command failed: ... tsc --showConfig
 error TS5058: The specified path does not exist: .../tsconfig.json

원격이 내보내는 것의 타입을 공유하는 단계가 실패하고 있었는데, 호스트가 LikeButton이 어떤 props를 받는지 타입으로 알 방법이 사라진 거예요.

그래도 vite build는 exit 0이고, remoteEntry.js도 정상으로 나오고 화면도 잘 뜹니다.

우리는 이 모양을 여러 번 봤는데, 보안 헤더를 켰더니 빌드는 통과하는데 스크립트가 하나도 안 실렸던 것, 언어를 주소로 옮겼더니 빌드는 통과하는데 앱이 통째로 죽었던 것, 번역 칸을 빠뜨렸는데 빌드가 조용했던 것까지 오늘이 네 번째입니다.

이번 것이 특히 고약한 이유는 없어진 게 남의 팀과의 약속이라서인데, 앱이 하나일 때는 props 이름을 바꾸면 타입 검사가 즉시 잡아주지만 경계를 넘으면 그 안전망이 조용히 사라져요.

원격이 안 뜨면 어떻게 될까요

하나 더 봅시다. 원격 서버를 그냥 꺼버리고 호스트를 열었습니다.

 (빈 화면)

Step 4에서 본 것과 똑같이 <h1>피드</h1>까지 안 나와요.

이건 생각해볼 만한 그림인데, 좋아요 버튼 하나를 못 가져왔을 뿐인데 피드 전체가 사라져서 남의 팀 서버가 우리 화면의 생사를 쥐고 있는 상태가 됩니다.

우리는 이미 막는 법을 압니다

다행히 이건 우리가 배운 걸로 막을 수 있는데, H-1에서 오류 경계를 앱에 이었고 H-2에서 그 경계가 무엇을 잡고 무엇을 못 잡는지까지 갈라봤죠.

원격을 불러오는 곳을 경계로 감싸면, 원격이 죽어도 그 칸만 비고 나머지 화면은 삽니다. 오류 보고도 그리로 올라가고요.

여기서 중요한 것은 기술이 아니라 순서인데, 앱이 하나일 때 오류 경계는 있으면 좋은 것이었어요. 화면을 남의 서버에서 가져오기 시작하는 순간 그것은 없으면 안 되는 것이 되는 셈인데, 같은 도구인데 지위가 달라졌죠.

이 아키텍처를 고르면 이런 것들이 줄줄이 따라오는데, 계약을 검사하는 장치, 원격이 죽었을 때의 대비, 버전이 어긋났을 때의 처리까지 전부 앱이 하나였으면 공짜로 얻던 것들이에요.

💡 한 줄 정리

앱을 나누면 타입 검사와 빌드가 주던 안전망이 경계에서 끊긴다. 그 안전망을 대신할 것을 직접 만들어야 한다.

Step 7: 그래서 우리 앱엔 안 넣습니다

쓸지 말지 이전에

지금까지 재본 걸로 우리 앱에 넣을지 판단해봅시다.

판단하기 전에 확인할 게 있었는데요, 우리 풀스택 앱은 Next.js 16이라서 여기에 페더레이션을 붙이려고 하면 이렇게 됩니다.

 npm error code ERESOLVE
 npm error Found: next@16.3.1
 npm error Could not resolve dependency:
 npm error peerOptional next@"^12 || ^13 || ^14 || ^15" from @module-federation/nextjs-mf@8.8.73

설치가 안 되는데, Next 전용 플러그인이 아직 15까지만 받고, 게다가 그 플러그인은 webpack을 전제로 하는데 Next 16은 다른 번들러가 기본이기 때문이에요.

쓸지 말지를 고민하기 전에 쓸 수 있는지에서 막힌 겁니다.

이런 일은 프론트엔드에서 드물지 않은데, 프레임워크가 메이저를 올리면 주변 도구들이 따라오는 데 시간이 걸리기 때문이에요. 새 아키텍처를 검토할 때 우리 스택에서 실제로 설치가 되는지부터 확인하는 게 순서인 이유가 여기 있는데, 블로그 글은 대개 그 이야기를 안 합니다.

판단표

우리 앱 기준으로 정리하면 이렇습니다.

넷 다 아니라서 안 넣습니다.

오늘 우리가 지은 원격과 호스트는 실습 폴더에 그대로 두고, 인스타그램 앱 본체는 한 줄도 바꾸지 않았습니다. 짓고, 재고, 안 넣기로 한 거예요.

이게 오늘 가장 중요한 부분인데, 배운 걸 안 쓰기로 결정하는 것도 결정이고, 재보고 내린 결정과 안 재보고 내린 결정은 다릅니다. 우리는 재봤어요.

이 분야가 지금 어디쯤 있나

마지막으로 동향을 짧게 짚어보려는데, 이 이야기를 하는 방식 자체가 오늘의 마지막 교훈이에요.

이 주제를 검색하면 "Module Federation 3.0"을 다루는 글이 여럿 나오는데, 2026년 마이크로 프론트엔드는 3.0 위에 서 있다는 식으로요.

확인해봤습니다.

3.0은 존재하지 않습니다. 존재하지 않는 버전에 대한 사용법과 마이그레이션 안내가 검색 결과 상단에 있는 거예요.

반면 함께 언급되는 Native Federation 쪽은 실재하는데, 브라우저 표준인 import maps를 써서 번들러 없이 모듈을 나눠 쓰자는 접근이고, 도구도 활발히 관리되고 있어요. 아직 널리 쓰이는 방식은 아니지만, 오늘 우리가 본 문제들(공유 의존성, 계약, 원격 장애)은 그쪽에서도 그대로 남아서 짐을 옮기는 것이지 없애는 게 아니에요.

⚠️ 그러니 버전 이야기를 만나면 검색 결과가 아니라 패키지 저장소를 보세요. 저장소는 실제로 배포된 것만 들고 있습니다. 블로그는 아무거나 쓸 수 있는데, 이 습관 하나가 여러분을 없는 기능을 찾아 헤매는 하루에서 구해줍니다.

💡 한 줄 정리

새 아키텍처는 쓸지 말지 이전에 우리 스택에서 되는지부터 확인하고, 버전은 검색 결과가 아니라 패키지 저장소에 물어본다.

마무리

오늘 한 일을 정리하면 이렇습니다.

 1. 원격 앱이 내보낼 것을 골랐다        exposes 하나 · remoteEntry.js 17.13 kB
 2. 호스트가 실행 중에 가져왔다         디스크에 없는 이름을 import 한다
 3. 원격만 배포해도 호스트가 그대로     번들 해시 index-Jyffi1Md.js 불변
 4. shared 를 빼봤다                    산출물은 작아지고 화면은 전멸
 5. 세금을 쟀다                          JS 1개 59,882 B → 24개 139,426 B
 6. 경계에서 안전망이 끊기는 걸 봤다     타입 공유 실패인데 빌드는 exit 0
 7. 안 넣기로 했다                       그리고 3.0 은 존재하지 않았다

오늘은 이 과목에서 처음으로 결론이 "안 한다"인 시간이었는데, 안 하기로 하는 데 한 시간을 다 썼죠. 재보지 않고 안 하는 것과 재보고 안 하는 것은 완전히 다른 결정이니까요.

60개 모듈을 돌아봅니다

이걸로 이 과목이 끝납니다.

처음에 여러분은 순수 HTML, CSS, JavaScript만 아는 상태로 오셨는데, 그때 만든 인스타그램 클론은 document.createElement로 카드를 그리는 정적인 화면이었습니다.

지금 그 프로젝트는 이렇습니다. 타입이 붙어 있고, 컴포넌트로 나뉘어 있고, 주소마다 화면이 갈리고, 서버 상태를 캐시하고, 실시간으로 메시지가 오고, 서버에서 미리 그려져서 오고, 로그인이 진짜로 되고, 남의 스크립트를 막고, 테스트가 천 건 넘게 지키고 있고, 오류와 속도가 측정되고, 네 나라 말을 합니다.

정말 남기고 싶은 것은 그 목록이 아니에요.

이 과목 내내 반복된 게 하나 있습니다. 재보기 전에는 모른다는 것요. 통설이 틀린 적이 여러 번 있었고, 제가 쓴 설명이 실행해보니 거짓이었던 적도 여러 번 있었는데, 빌드가 통과했는데 앱이 죽어 있던 적은 오늘까지 네 번이고, 커리큘럼에 적힌 내용이 실제와 달랐던 적도 있었죠. 오늘은 아예 존재하지 않는 버전이 검색 결과 상단에 있었습니다.

그때마다 답을 준 것은 실행이었습니다. 재보고, 조건을 바꿔서 다시 재보고, 안 바뀌면 재는 방법을 의심하고요.

프레임워크는 계속 바뀌고 오늘 배운 버전들도 몇 달 뒤면 낡는데, 어떻게 확인할지 아는 것은 안 낡습니다. 여러분이 가져가실 게 그거였으면 좋겠습니다.

수고하셨습니다.

과제

[구현] 원격이 죽어도 화면이 살아남게 만드세요

Step 6에서 원격 서버를 끄면 호스트 화면이 통째로 사라지는 걸 봤습니다.

• LikeButton을 불러오는 곳을 오류 경계로 감싸고, 원격을 끈 상태로 다시 열어보세요.
• <h1>피드</h1>과 나머지 화면이 남아 있나요? 좋아요 칸에는 무엇이 보이나요?
• 경계가 없을 때와 있을 때, 사용자가 겪는 일이 어떻게 다른지 한 문단으로 적어보세요.

[구현] 원격이 약속을 어기게 만들어보세요

좋아요 팀이 props 이름을 바꿨다고 해봅시다.

• 원격의 LikeButton이 initialCount 대신 count를 받도록 고치고 원격만 다시 빌드하세요.
• 호스트는 건드리지 마세요. 화면에 무엇이 나오나요?
• 호스트에서 타입 검사와 빌드를 돌려보세요. 이 변경을 잡아주나요?
• 앱이 하나였다면 이 실수가 언제 잡혔을지 비교해서 적어보세요.

[탐구] 그 세금을 우리 인스타 앱에 매겨보세요

Step 5의 표는 실습용 앱으로 잰 것입니다. 우리가 진짜로 만든 앱에 매기면 얼마일까요.

• 우리 인스타 클론을 빌드해서 지금 번들이 몇 바이트인지 확인하세요. 번들을 들여다보는 방법은 지난 시간들에 다뤘습니다.
• 그 크기를 분모로 놓고, Step 5에서 잰 고정비를 나눠보세요. 몇 퍼센트인가요?
• 우리 앱을 몇 조각으로 나눈다고 하면 그 세금은 조각 수만큼 늘어날까요, 아니면 한 번만 낼까요? 왜 그렇게 생각하는지 근거를 적어보세요.
• 우리는 번들에 상한을 걸어둔 적이 있습니다. 이 세금을 더하면 그 상한을 넘나요?

[탐구] 검색 결과를 저장소로 검증해보세요

Step 7에서 존재하지 않는 버전이 검색 상단에 있는 걸 봤습니다.

• 여러분이 요즘 관심 있는 라이브러리를 하나 골라 "새 메이저 버전"을 검색해보세요.
• 패키지 저장소에서 실제 배포 이력과 최신 버전도 확인하세요.
• 둘이 일치하나요? 어긋난다면 어긋난 글이 무엇을 근거로 그렇게 썼는지 살펴보세요.
• 앞으로 버전을 확인할 때 여러분이 쓸 순서를 세 줄로 적어보세요.

생각해볼 주제

1. 조직도가 아키텍처를 정할 때

오늘 배운 구조는 기술 문제를 푸는 도구처럼 보이지만, 실제로 푸는 것은 사람 문제에 가깝습니다. 팀이 서로 기다리지 않게 하는 것이니까요.

그런데 반대 방향도 자주 일어납니다. 팀을 여섯 개로 나눴으니 화면도 여섯 조각으로 나눠야 한다고 생각하는 경우요.

조직 구조에 맞춰 아키텍처를 정하는 것은 어디까지 합리적이고 어디부터 문제일까요. 팀이 합쳐지거나 갈라질 때 화면 구조도 따라가야 할까요?

2. 안 아픈데 약을 먹게 되는 이유

오늘 우리는 재보고 안 쓰기로 했습니다. 그런데 실무에서는 재보지 않고 도입하는 일이 훨씬 흔해요.

큰 회사가 쓴다는 이유로, 컨퍼런스에서 봤다는 이유로, 이력서에 쓰고 싶다는 이유로 도입되는 기술이 있습니다. 그리고 도입된 뒤에는 되돌리기가 훨씬 어렵죠.

여러분이 팀에서 "이거 도입합시다"라는 제안을 받았을 때, 무엇을 물어보면 이 판단을 도울 수 있을까요. 그리고 반대로 여러분이 제안하는 쪽이라면 무엇을 미리 준비해 가시겠어요?

3. 없는 것에 대한 설명서가 존재할 때

오늘 확인한 것 중 가장 이상한 건 존재하지 않는 버전의 사용법이 검색 결과 상단에 여러 개 있었다는 겁니다.

그럴듯한 글은 이제 아주 싸게 만들어집니다. 그리고 검색은 그럴듯함과 사실을 잘 구별하지 못해요.

이런 환경에서 여러분은 무엇을 1차 자료로 삼으시겠어요? 그리고 팀 안에서 누군가 없는 기능을 근거로 설계를 제안했을 때, 그 사람을 무안하게 하지 않으면서 사실을 확인하려면 어떻게 말하는 게 좋을까요?