C-10: WebSocket 클라이언트 ② — 실시간을 얹는다

1200번.

지난 시간에 우리가 없앤 요청 수입니다. 3초마다 물어보면 한 시간에 1200번이었는데, 그걸 0으로 만들었고 남이 누른 좋아요는 오히려 2초가 아니라 즉시 우리 화면에 들어오게 됐습니다.

그렇게 열어둔 통로로 지금 다니는 소식은 아직 딱 한 종류예요. 게시물에 생긴 일이요.

안녕하세요, 홍순구입니다. 오늘은 그 통로 위에 나머지를 얹는데, 첫 걸음부터 막혀요. 우리가 지난 시간에 쓴 방식은 구독한 사람 전부에게 가는 방식이거든요.

쪽지는 그러면 안 됩니다.

💡 오늘 수업의 핵심 — "나에게만 오게 하는 것은 우리가 정할 수 없습니다"

오늘 여러분은 이상한 코드를 하나 보게 됩니다.

두 사람이 서로 다른 쪽지를 받는데, 그 쪽지를 받겠다고 서버에 말하는 코드는 두 사람이 글자 하나 안 다릅니다. 복사해서 붙여넣은 것처럼요.

같은 것을 요청했는데 다른 것이 도착합니다. 어떻게 그럴 수 있을까요?

가르는 쪽이 우리가 아니기 때문입니다. 오늘 그 이야기부터 시작합니다.

🎯 학습 목표

• 지금 통로로 쪽지를 보내면 무슨 일이 생기는지 직접 확인하고, 왜 다른 방법이 필요한지 짚습니다.
• 지금까지 듣기만 하던 통로로 우리가 먼저 보내는 방법을 익힙니다.
• /user 접두사가 어떻게 "나에게만"을 만드는지, 그 판단을 누가 하는지 이해합니다.
• 지나간 쪽지는 요청으로, 새로 오는 쪽지는 통로로 받아 한 곳에 모읍니다.
• 통로에는 응답이 없다는 사실이 화면을 어떻게 바꾸는지 만들어봅니다.
• 알림을 붙이고, 끊겨 있던 동안 놓친 것을 메웁니다.
• 실시간이 과한 화면과, 우리 코드로는 못 고치는 문제를 구분합니다.

 오늘의 여정

 1. 쪽지를 지금 통로로 보내면    구독한 사람 전부가 읽는다
 2. 이번엔 우리가 보낸다         publish · /app · 안 붙었으면 던진다
 3. 같은 줄인데 나에게만 온다    /user — 가르는 쪽은 서버
 4. 쪽지가 화면에 쌓인다         지나간 것은 요청으로, 새 것은 통로로
 5. 보낸 것이 갔는지 모른다      통로엔 응답이 없다 → 표를 붙인다
 6. 알림은 같은 길 다른 줄       토스트는 이미 만들어뒀다
 7. 끊긴 동안 온 것은 안 온다    다시 붙는 순간 물어본다
 8. 여기까지가 할 수 있는 것     못 고치는 문제를 아는 것도 실력

Step 1: "쪽지를 지금 통로로 보내면"

있는 것으로 먼저 해봅니다

새로운 걸 배우기 전에, 이미 아는 것으로 해보는 게 순서입니다.

우리에게는 통로가 있어요. 서버가 /topic/posts로 뿌리면 구독한 모두가 받는다는 것을 지난 시간에 두 탭으로 확인했으니까, 쪽지도 같은 방법으로 하면 되지 않을까요? /topic/dm 같은 곳을 하나 더 만들어서, minji 님이 보낸 쪽지를 거기로 뿌리는 겁니다.

한번 그림으로 그려볼게요.

 서버가 /topic/dm 으로 뿌린다

              ┌─ jaehoon  ← 받는다 (받을 사람)
              │
   서버 ──────┼─ minji    ← 받는다 (보낸 사람이니 괜찮다)
              │
              └─ seungwoo ← 받는다 ← ⚠️ 이 사람은 왜?

seungwoo 님은 이 대화와 아무 상관이 없는데도, /topic을 구독하고 있다는 이유만으로 남의 쪽지를 읽게 돼요.

이게 정말 그런지 재봅니다

말로만 하면 믿기 어려우니 실제로 확인했습니다. 두 사람을 같은 서버에 붙여놓고, 한쪽에는 /topic으로 다른 쪽에는 /user/queue로 같은 내용을 보내봤어요.

같은 서버에 두 사람을 붙여두고 소식 하나를 보낼 때, 각자에게 도착한 개수입니다.

윗줄이 지금 우리가 쓰는 방식인데, 뿌리면 전부 받아요. 게시물 좋아요라면 그게 맞습니다. 공개된 정보니까요.

아랫줄이 오늘 만들 방식입니다.

여기서 두 가지 문제가 갈립니다

첫째는 개인정보 문제입니다. 남의 쪽지가 내 브라우저까지 온다는 건, 개발자 도구만 열면 읽을 수 있다는 뜻이에요. 화면에 안 그리는 걸로는 못 막는데, 이미 도착했으니까요.

둘째는 양 문제입니다. 서비스 사용자가 만 명이면, 쪽지 하나가 오갈 때마다 만 명에게 그 쪽지가 배달됩니다. 아무도 안 쓸 데이터를 만 번 보내는 거예요.

두 문제 다 화면에서는 못 고치니까, 애초에 안 보내야 해요.

그럼 어떻게 나눌까요

여기서 잠깐 생각해볼 게 있습니다. 누구에게 보낼지를 누가 정해야 할까요?

클라이언트가 정한다고 해봅시다. "나는 jaehoon 이니까 jaehoon 앞으로 온 것만 주세요"라고 구독하는 거예요.

그럴듯한데, 이러면 아무나 minji라고 적어서 구독할 수 있습니다. 브라우저에서 도는 코드는 사용자가 마음대로 고칠 수 있으니까요.

그러니 정하는 쪽은 서버여야 합니다. 서버는 우리가 누구인지 이미 알고 있어요. 로그인할 때 확인했으니까요.

⚠️ 지난 시간에 만든 통로는 이 확인을 안 거쳤습니다. 로그인 없이도 붙었죠. 오늘 그것부터 고칩니다.

💡 한 줄 정리

/topic은 공개된 소식을 위한 곳입니다. 받을 사람이 정해져 있는 소식은 다른 방법이 필요하고, 그 방법에서 누구에게 갈지를 정하는 쪽은 서버여야 합니다.

Step 2: "이번엔 우리가 보낸다"

지금까지 우리는 듣기만 했습니다

지난 시간 코드를 다시 보면, 통로로 한 일이 하나뿐이었어요. subscribe로 듣는 것.

쪽지를 보내려면 우리도 말을 해야 하는데, 지난 시간에 프레임 종류를 읽어봤던 거 기억하시죠. SEND라는 게 있었습니다. 클라이언트가 서버로 보낼 때 쓰는 프레임이고, 목적지가 /app으로 시작하면 브로커가 아니라 서버의 처리 코드가 받는다고 했습니다.

라이브러리로는 한 줄입니다.

// apps/web-spa/src/realtime/stompClient.ts
// 나에게만 오는 곳. 앞의 /user 는 목적지 이름의 일부가 아니라
// "이 줄에서 나에게 온 것만 달라" 는 표시다. 누구에게 갈지는 서버가 정한다.
export const DM_QUEUE = '/user/queue/dm';

// 우리가 서버로 보내는 곳. /app 으로 시작하는 것은 브로커가 아니라
// 서버의 처리 코드가 받는다 (백엔드의 @MessageMapping).
export const DM_SEND = '/app/dm.send';

부르는 모양은 이렇습니다. 목적지와 보낼 내용, 두 가지만 주면 됩니다.

client.publish({
  destination: '/app/dm.send',
  body: JSON.stringify({ conversationId: 1, content: '안녕하세요' }),
});

publish를 부르면 SEND 프레임이 나갑니다. 백엔드 쪽에서는 /app/dm.send에 붙여둔 처리 코드가 그걸 받아요.

보내는 사람 이름이 안 보이죠

위 코드를 다시 보세요. 방 번호와 내용만 들어 있습니다. 누가 보냈는지가 없어요.

빠뜨린 게 아닙니다. 일부러 안 적은 겁니다.

만약 우리가 적어 보낸다면 어떻게 될까요? 개발자 도구를 열고 senderUsername을 minji로 바꿔서 보내면, 서버는 minji가 보낸 걸로 믿습니다. 남의 이름으로 쪽지를 보낼 수 있게 되는 거라서, 보내는 사람은 서버가 압니다. 우리가 통로를 열 때 이미 말해뒀거든요.

통로를 열 때 이름을 싣습니다

STOMP로 붙을 때 CONNECT 프레임이 나간다고 했죠. 거기에 헤더를 실어 보낼 수 있습니다.

// apps/web-spa/src/realtime/RealtimeBridge.tsx
client.configure({
  // 출입증을 서버에 내미는 자리. 진짜 서버는 여기서 JWT 를 검사한다.
  // 로그인 전에는 아무것도 안 싣는다 — 그래도 /topic 은 받는다.
  connectHeaders: username === null ? {} : { login: username },

서버는 이 이름을 그 연결에 기억해둡니다. 이후 그 연결로 들어오는 모든 SEND는 그 사람이 보낸 것으로 처리돼요.

⚠️ 연습용 서버라 이름만 받지만, 실제 서버는 여기서 토큰을 검사합니다. 백엔드 쪽에서 CONNECT 프레임을 가로채 토큰을 확인하고, 통과한 사람만 연결을 허락해요.

그런데 로그인은 통로가 열린 뒤에 합니다

여기서 순서 문제가 하나 생깁니다.

앱을 켜면 통로부터 열립니다. 그때는 아직 로그인 전이라 실을 이름이 없어요. 그러다 사용자가 로그인 버튼을 누르면 이름이 생기지만, 이미 열린 통로에는 이름이 안 실려 있습니다. 서버는 우리를 여전히 손님으로 알고 있어서, 사람이 바뀌면 통로를 다시 엽니다.

// apps/web-spa/src/realtime/RealtimeBridge.tsx
// 누구로 들어와 있는지가 바뀌면 통로도 다시 열어야 한다.
// 서버는 CONNECT 때 받은 이름으로 "누구에게 보낼지" 를 가르기 때문이다.
const username = useSessionStore((state) => state.username);

이 값을 effect의 의존성에 넣으면 됩니다. 이름이 바뀌는 순간 정리 함수가 돌아 통로를 닫고, 새 이름으로 다시 열어요. B-4에서 배운 effect의 정리와 재실행이 여기서 그대로 쓰입니다.

그 이름은 어디에 담나요

여기서 우리가 이미 세워둔 규칙을 씁니다. 상태를 어디에 담을지 정하는 세 갈래 규칙이요.

로그인한 사람이 누구인지는 서버가 주인인 값일까요? 아닙니다. 서버는 토큰이 유효한지만 알지, 이 브라우저가 누구로 들어와 있는지는 이쪽 사정이에요.

주소에 담을까요? 그것도 아닙니다. 주소를 복사해서 친구에게 보냈는데 친구가 나로 보이면 큰일이니까요.

머리말도 알아야 하고 통로도 알아야 하고 쪽지 화면도 알아야 하니까, store입니다.

// apps/web-spa/src/stores/useSessionStore.ts
interface SessionState {
  username: string | null;

  signIn: (username: string) => void;
  signOut: () => void;
}

export const useSessionStore = create<SessionState>()((set) => ({
  username: null,

  signIn: (username) => set({ username }),
  signOut: () => set({ username: null }),
}));

C-4에서 만든 확인 상자 store와 똑같이 생겼죠. 규칙이 같으면 결과도 같습니다.

안 붙어 있을 때 보내면 어떻게 될까요

궁금해서 해봤습니다. 통로를 열지 않은 채로 publish를 불러본 거예요.

여러분은 어떻게 될 거라고 예상하세요? 조용히 사라질까요, 아니면 나중에 붙었을 때 보내줄까요?

둘 다 아닙니다. 던집니다.

TypeError: There is no underlying STOMP connection

라이브러리가 보내기 전에 연결을 확인하고, 없으면 예외를 던져요. 큐에 쌓아뒀다 나중에 보내주지 않습니다.

이건 사실 친절한 설계인데, 조용히 사라지는 게 제일 나쁘거든요. 사용자는 보낸 줄 아는데 아무 데도 안 간 상태가 되니까요.

대신 우리가 할 일이 생기는데, 끊겨 있으면 보내기 버튼을 잠가야 해요. 안 그러면 앱이 터집니다.

⚠️ subscribe도 똑같이 검사합니다. 붙기 전에는 구독도 못 해요. 다음 Step에서 이 때문에 한 번 막힙니다.

💡 한 줄 정리

publish로 /app에 보내면 서버의 처리 코드가 받습니다. 보내는 사람은 우리가 적는 게 아니라 서버가 연결에 기억해둔 이름으로 판단하고, 연결이 없으면 보내기는 조용히 사라지지 않고 던집니다.

Step 3: "같은 줄을 구독했는데 나에게만 온다"

목적지 앞에 /user를 붙입니다

지금부터가 오늘의 핵심인데, 쪽지를 받으려면 이렇게 구독합니다.

// apps/web-spa/src/realtime/stompClient.ts
export const DM_QUEUE = '/user/queue/dm';

/user/queue/dm. 앞에 /user가 붙었죠.

여기서 반드시 짚고 갈 것이 있습니다. /user는 목적지 이름의 일부가 아닙니다.

/topic/posts는 실제로 그런 이름의 게시판이 서버에 있는 것이었지만, /user/queue/dm은 그런 이름의 게시판이 있는 게 아닙니다. 서버에게 보내는 표시예요. "이 줄로 오는 것 중에서 나에게 온 것만 주세요"라는 뜻입니다.

그래서 이상한 일이 생깁니다

jaehoon 님의 브라우저에서 구독하는 코드를 봅시다.

client.subscribe('/user/queue/dm', handler);

이번엔 minji 님의 브라우저입니다.

client.subscribe('/user/queue/dm', handler);

같습니다. 글자 하나 안 다릅니다.

두 사람이 서버에 보내는 SUBSCRIBE 프레임의 목적지도 똑같은데, 도착하는 쪽지는 다릅니다.

 보내는 코드는 같고, 받는 것은 다르다

 jaehoon 의 브라우저 ──SUBSCRIBE /user/queue/dm──┐
                                                 │
                                              [ 서버 ]  ← 여기서만 갈린다
                                                 │        (연결마다 누구인지 안다)
 minji 의 브라우저   ──SUBSCRIBE /user/queue/dm──┘

서버는 각 연결이 누구인지 알고 있습니다. Step 2에서 CONNECT에 이름을 실어 보냈으니까, 같은 문자열을 받고도 사람마다 다른 곳에 묶어둘 수 있습니다.

백엔드 쪽에서 이 변환을 해주는 부품이 따로 있어요. 서버 코드는 그냥 "minji에게 /queue/dm으로 보내"라고 말하고, 그 부품이 minji의 연결을 찾아 배달합니다.

화면을 만들어봅니다

쪽지 화면을 새로 만듭니다. 주소는 /dm/:conversationId예요. 게시물 상세와 똑같이 생겼어요. 방이 몇 개든 표는 한 줄이면 됩니다.

// apps/web-spa/src/routes/routes.ts
// 대화방도 같은 모양이다. 방이 몇 개든 이 표는 한 줄이다.
{ path: 'dm/:conversationId', Component: DmPage },

여기서는 화면이 통로를 직접 듣습니다.

// apps/web-spa/src/routes/DmPage.tsx
// 붙기 전에는 구독도 못 한다. 지난 시간에 담아둔 연결 상태가 여기서 쓰인다.
const status = useConnectionStore((state) => state.status);

useEffect(() => {
  if (status !== 'connected') return;

  // 이 줄은 누가 들어와 있든 글자 하나 안 다르다.
  // 그런데 도착하는 것은 사람마다 다르다 — 가르는 쪽이 서버이기 때문이다.
  const subscription = client.subscribe(DM_QUEUE, (message) => {
    const received = parseDirectMessage(message.body);
    if (received === null || received.conversationId !== roomId) return;

    setMessages((current) => appendMessage(current, received));
  });

  // 화면을 떠나면 구독을 거둔다. 연결은 그대로 두고 이 줄만 끊는 것이다.
  return () => subscription.unsubscribe();
}, [client, roomId, status]);

세 가지가 눈에 띄죠.

첫째, 연결 상태를 먼저 봅니다. Step 2 마지막에 예고한 그 문제예요. 붙기 전에는 구독도 못 하니까, 지난 시간에 store에 담아둔 상태가 connected가 될 때까지 기다립니다. 담아둘 때는 표시등 하나 켜려고 만든 값이었는데, 오늘 다른 데서 쓰이네요.

둘째, 정리 함수에서 구독을 거둡니다. subscribe가 돌려주는 것에 unsubscribe가 붙어 있어요. 이걸 부르면 그 줄만 끊깁니다. 연결은 그대로 열려 있어요.

셋째, 방 번호가 다르면 버립니다. 통로는 내 앞으로 온 쪽지를 전부 보내주는데, 지금 보고 있는 방의 것만 그려야 하니까요.

보낸 것을 화면이 어떻게 아나요

여기서 재미있는 게 하나 있습니다. 우리가 보낸 쪽지는 어떻게 우리 화면에 뜰까요?

먼저 그려놓을 수도 있겠지만, 서버가 보낸 사람에게도 되돌려 보내서 받는 코드 하나로 양쪽이 다 처리돼요.

 minji 가 보낸 쪽지가 가는 길

 minji ──SEND /app/dm.send──→ 서버 ──┬──→ jaehoon 의 /user/queue/dm
                                      │
                                      └──→ minji 의 /user/queue/dm  (되돌려 보냄)

받는 사람에게 한 번, 보낸 사람에게 한 번. 화면 쪽에서는 구분할 필요가 없습니다. 어느 쪽이든 "쪽지가 하나 도착했다"로 처리하면 되니까요.

⚠️ 이건 그냥 편의가 아닙니다. Step 5에서 이게 왜 중요한지 다시 만납니다.

같은 것이 두 번 오면

통로는 "한 번만 보낸다"를 약속하지 않습니다. 재연결이 얽히거나 서버가 다시 보내면 같은 쪽지가 두 번 올 수 있어서, 얹기 전에 번호를 확인합니다.

// apps/web-spa/src/lib/dmEvents.ts
// 받아둔 쪽지 목록에 새 것을 얹는다.
//
// ⚠️ 같은 것이 두 번 올 수 있다. 통로는 "한 번만 간다" 를 약속하지 않는다.
// 번호가 같은 것이 이미 있으면 그대로 둔다.
export function appendMessage(
  messages: DirectMessage[] | undefined,
  incoming: DirectMessage,
): DirectMessage[] {
  const current = messages ?? [];
  if (current.some((it) => it.messageId === incoming.messageId)) return current;

  return [...current, incoming];
}

같은 것이 이미 있으면 그대로 둡니다. 새 배열을 안 만들어요. 이러면 화면도 다시 안 그려집니다.

두 탭으로 확인합니다

여기서부터는 직접 해볼 차례입니다.

• 연습용 서버와 앱을 띄우고 탭을 두 개 엽니다.
• 머리말에서 한쪽은 jaehoon, 다른 쪽은 minji를 골라 로그인합니다.
• 두 탭 다 /dm/1로 들어갑니다.
• minji 쪽에서 쪽지를 하나 보냅니다.

jaehoon 쪽 화면에 그 쪽지가 뜹니다. 새로고침은 안 했어요.

서버 쪽 기록을 보면 사람마다 구독이 따로 잡혀 있는 것도 보입니다. 같은 문자열을 받았는데 서버 안에서는 두 개의 다른 줄로 갈라져 있는 거예요.

💡 한 줄 정리

/user는 목적지 이름이 아니라 "나에게 온 것만"이라는 표시입니다. 두 사람의 구독 코드는 같고, 가르는 판단은 연결마다 누구인지 아는 서버가 합니다.

Step 4: "쪽지가 화면에 쌓인다"

새로 들어가면 텅 비어 있습니다

Step 3을 만들고 나서 쪽지 화면을 새로고침해보세요.

아무것도 없습니다.

조금 전까지 주고받은 쪽지가 전부 사라졌어요. 서버는 그것들을 잘 들고 있는데도요.

당연합니다. 우리 화면은 통로로 오는 것만 받거든요. 통로가 열리기 전에 오간 것은 통로로 안 옵니다.

숫자로 보면 이렇습니다.

요청이 0번이라는 게 핵심입니다. 물어본 적이 없으니 모르는 게 당연해요.

지나간 것은 요청으로 받습니다

여기서 두 갈래로 나눕니다.

 쪽지가 화면에 오는 두 가지 길

 지나간 것  ──→ GET /api/conversations/1/messages  (요청 · 들어갈 때 한 번)
 새로 온 것 ──→ /user/queue/dm                     (통로 · 계속)

읽어오는 코드는 C-6에서 만든 것과 똑같이 생겼습니다.

// apps/web-spa/src/api/dm.ts
// 통로가 열리기 전에 오간 것은 통로로 안 온다. 그건 요청으로 받아야 한다.
export async function fetchMessages(conversationId: number): Promise<DirectMessage[]> {
  const response = await api.get<DirectMessage[]>(`/conversations/${conversationId}/messages`);

  return response.data;
}

// apps/web-spa/src/queries/dm.ts
// 키와 부를 함수를 한 덩어리로 묶는다. 통로도 화면도 이 하나를 가져다 쓴다 —
// 키가 어긋날 자리가 없어진다 (C-6 의 postQuery 와 같은 모양).
export function messagesQuery(conversationId: number) {
  return queryOptions({
    queryKey: dmKey(conversationId),
    queryFn: () => fetchMessages(conversationId),
  });
}

그럼 통로로 온 것은 어디에 둘까요

여기가 오늘의 갈림길입니다.

지금 화면은 통로로 온 것을 useState에 쌓고 있는데, 요청으로 받아온 것은 캐시에 있어서 같은 대화의 쪽지가 두 곳에 나뉘어 있는 거예요.

C-7에서 우리가 뭐라고 했죠? 진실이 둘이면 하나는 거짓말입니다.

그때는 좋아요 개수였어요. 화면이 자기 셈으로 세고 서버도 따로 세다가 갈라졌죠. 지금은 쪽지 목록이고, 갈라지는 방식은 똑같습니다.

그러니 한 곳으로 모읍니다. 통로가 온 것을 캐시에 얹어요. 지난 시간에 좋아요 소식을 얹었던 그 방식 그대로입니다.

// apps/web-spa/src/realtime/RealtimeBridge.tsx
// 쪽지도 같은 자리에서 듣는다. 화면이 아니라 앱이 듣는 이유는
// 쪽지 화면을 떠나 있는 동안에도 받아둬야 하기 때문이다.
client.subscribe(DM_QUEUE, (message) => {
  const received = parseDirectMessage(message.body);
  if (received === null) return;

  // 얹는 방식은 좋아요와 똑같다. 진실을 캐시 한 곳에 모아뒀으니
  // 화면은 이 줄이 있는 줄도 모르고 다시 그려진다.
  queryClient.setQueryData<DirectMessage[]>(dmKey(received.conversationId), (current) =>
    appendMessage(current, received),
  );
});

구독이 화면에서 앱으로 올라갔습니다

방금 코드가 어디에 있는지 보세요. DmPage가 아니라 통로를 여는 곳입니다.

Step 3의 🙋 질문에서 예고한 것이 이겁니다. 기준은 하나예요.

그 소식이 그 화면을 떠나 있는 동안에도 필요한가?

쪽지는 필요합니다. 홈을 보고 있는 동안 쪽지가 와도 받아둬야 해요. 나중에 쪽지 화면에 들어갔을 때 거기 있어야 하니까, 앱이 듣습니다. 화면은 캐시만 그려요.

// apps/web-spa/src/routes/DmPage.tsx
// 통로가 열리기 전에 오간 것은 여기로 받는다.
// 통로는 이 캐시에 얹기만 하니, 화면은 어느 쪽으로 온 것인지 몰라도 된다.
//
// ⚠️ 들어오자마자 묻지 않는다. 남의 쪽지를 아무나 못 보게 서버가 막고 있어서,
// 로그인 전에 물어보면 거절만 받고 그 실패가 캐시에 남는다.
const { data: messages, isPending: loadingHistory } = useQuery({
  ...messagesQuery(roomId),
  enabled: username !== null,
});

화면에서 subscribe가 사라졌습니다. useState도요. 남은 것은 캐시를 읽는 한 줄뿐이에요.

enabled는 처음 보는 옵션이죠. "이 조건이 맞을 때만 물어봐라"는 뜻입니다. 로그인 전에는 서버가 거절할 게 뻔하니 아예 안 묻는 겁니다.

확인해봅니다

두 탭을 다시 띄우고 이렇게 해보세요.

• 두 탭 다 로그인하고 /dm/1로 들어갑니다. 지나간 쪽지 2개가 먼저 뜹니다.
• jaehoon 쪽에서 홈으로 이동합니다. 쪽지 화면을 떠난 거예요.
• minji 쪽에서 쪽지를 하나 보냅니다.
• jaehoon 쪽에서 다시 쪽지 화면으로 들어갑니다.

그 쪽지가 있습니다. 떠나 있는 동안 앱이 받아뒀거든요. 한 가지 더 눈여겨보면, 새 쪽지가 왔다고 서버에 다시 물어보지 않았습니다. 요청은 처음 들어갈 때 한 번뿐이에요. 나머지는 전부 통로가 채웠습니다.

💡 한 줄 정리

지나간 것은 요청으로, 새로 오는 것은 통로로 받되 담는 곳은 하나이고, 화면을 떠나 있는 동안에도 필요한 소식이라면 화면이 아니라 앱이 들어야 합니다.

Step 5: "보낸 것이 갔는지 우리는 모른다"

지난 시간 과제의 답이 여기서 쓰입니다

지난 시간 생각해볼 주제에 이런 게 있었죠. "통로가 열려 있는데 좋아요는 왜 아직도 요청으로 보내나요?"

답은 응답이었습니다. 요청에는 짝이 있어서 성공인지 실패인지 알 수 있는데, 통로의 SEND에는 짝이 없다는 것.

오늘 그 말이 실제로 무슨 뜻인지 봅니다. 우리는 방금 쪽지를 통로로 보냈어요. 그러니 갔는지 모릅니다.

 좋아요를 누를 때 (요청)          쪽지를 보낼 때 (통로)

 POST /posts/1/like               SEND /app/dm.send
        │                                │
        ▼                                ▼
   200 · 500 · 403                   (아무것도 없음)
        │
        └─→ 실패면 되돌린다          └─→ 되돌릴 근거가 없다

C-7에서 만든 되돌리기가 전부 응답 위에 서 있었습니다. 서버가 403을 줬으니까 화면을 되돌린 거예요. 통로에는 그 403이 안 옵니다.

그런데 우리에겐 이미 단서가 하나 있습니다

Step 3에서 지나간 것 기억나세요? 서버가 보낸 사람에게도 되돌려 보낸다고 했죠.

그게 곧 확인입니다. 되돌아왔다는 건 서버까지 갔고, 서버가 저장했다는 뜻이니까요.

문제는 하나뿐이에요. 돌아온 것이 내가 보낸 그것인지 어떻게 알까요? 같은 시간에 여러 개를 보냈을 수도 있고 상대가 똑같은 글자를 보냈을 수도 있어서, 보낼 때 표를 하나 붙입니다.

// apps/web-spa/src/routes/DmPage.tsx
function send() {
  const content = draft.trim();
  if (content === '') return;

  // 통로에는 응답이 없다. 그래서 우리가 표를 붙여 보내고,
  // 서버가 그 표를 그대로 실어 돌려주는 것을 "갔다" 의 증거로 삼는다.
  const clientId = crypto.randomUUID();

  client.publish({
    destination: DM_SEND,
    body: JSON.stringify({ conversationId: roomId, content, clientId }),
  });

  setOutgoing((current) => [...current, { clientId, content, failedReason: null }]);
  setDraft('');
}

crypto.randomUUID()는 브라우저가 만들어주는 겹치지 않는 문자열입니다. 서버는 이걸 해석하지 않고 그대로 실어 돌려줘요.

확인 전에는 어디에 담을까요

여기서 또 한 번 담는 곳을 정해야 합니다.

방금 보낸 쪽지는 서버가 아직 모르는 것이고 저장됐는지도 몰라서, 서버 상태가 아닙니다.

C-4의 규칙을 그대로 적용하면 답이 나옵니다. 서버가 주인이 아니고, 주소에 담을 것도 아니고, 이 화면만 알면 되는 값. 화면의 useState입니다.

// apps/web-spa/src/types/dm.ts
// 아직 서버가 받았는지 모르는, 우리 화면에만 있는 쪽지.
// 서버가 모르는 것은 서버 상태가 아니다 — 그래서 캐시가 아니라 화면이 들고 있는다.
export interface PendingMessage {
  clientId: string;
  content: string;
  failedReason: string | null;
}

확인이 오면 목록에서 빠집니다

이제 화면에는 두 종류가 있습니다. 서버가 확인해준 것과 아직 기다리는 것인데, 이 둘을 손으로 옮겨 담지 않습니다. 계산으로 가릅니다.

// apps/web-spa/src/routes/DmPage.tsx
  // 서버가 우리 표를 그대로 실어 돌려준 것들. 이것들은 확인이 끝났다.
  const confirmed = new Set(messages?.map((it) => it.clientId).filter((it) => it !== undefined));
  const stillOutgoing = outgoing.filter((it) => !confirmed.has(it.clientId));

캐시에 들어온 쪽지 중에 표가 붙은 것들을 모으고, 기다리던 것 중에 그 표가 있는 것은 뺍니다.

이게 왜 나을까요? 옮겨 담는 코드를 쓰면 "언제 옮길지"를 정해야 하고, 그건 effect가 됩니다. 계산으로 하면 그럴 일이 없어요. B-4에서 "effect로 안 해도 되는 것"을 골라내던 그 기준입니다.

화면에는 이렇게 나옵니다.

 보내기를 누른 직후

 minji     한강 사진 그거 어디서 찍은 거예요?
                        반포대교 남단이요! 해 지기 30분 전이 제일 좋아요
                                          노을 시간 맞춰 가볼게요  보내는 중…

 서버가 되돌려준 뒤

 minji     한강 사진 그거 어디서 찍은 거예요?
                        반포대교 남단이요! 해 지기 30분 전이 제일 좋아요
                                                    노을 시간 맞춰 가볼게요

메신저 앱에서 보낸 메시지 옆에 시계가 떴다가 체크로 바뀌는 것, 그게 정확히 이겁니다.

그럼 실패는 어떻게 알까요

통로에 응답이 없다면 실패도 안 오는 걸까요?

여기서 백엔드가 규약을 하나 더 만들어둡니다. 실패 전용 줄이에요.

// apps/web-spa/src/realtime/stompClient.ts
// 보내기가 거절당했을 때 답이 오는 곳. 정상 쪽지와 다른 줄이다.
export const ERRORS_QUEUE = '/user/queue/errors';

정상 쪽지는 /user/queue/dm으로, 거절은 /user/queue/errors로 옵니다. 같은 사람에게 오는 것이니 둘 다 /user로 시작하는데, 그래서 클라이언트는 두 줄을 다 구독해야 합니다. 하나만 구독하면 절반은 영영 못 듣습니다.

// apps/web-spa/src/routes/DmPage.tsx
// 보내기가 거절당하면 그 답은 정상 쪽지와 다른 줄로 온다.
//
// 쪽지는 앱이 듣고 이건 화면이 듣는다. 기준은 "그 소식이 화면을 떠나 있는 동안에도
// 필요한가" 다. 쪽지는 필요하고, 내가 이 화면에서 보낸 것의 실패는 여기서만 쓸모가 있다.
useEffect(() => {
  if (status !== 'connected') return;

  const subscription = client.subscribe(ERRORS_QUEUE, (message) => {
    const error = parseStompError(message.body);
    if (error === null || error.clientId === null) return;

    setOutgoing((current) =>
      current.map((it) =>
        it.clientId === error.clientId ? { ...it, failedReason: error.message } : it,
      ),
    );
  });

  return () => subscription.unsubscribe();
}, [client, status]);

주석에 적힌 판단을 눈여겨보세요. 쪽지는 앱이 듣는데 실패는 화면이 듣습니다. 어긋나 보이지만 기준은 같아요. 떠나 있는 동안에도 필요한가. 내가 이 화면에서 방금 보낸 것의 실패는 여기서만 쓸모가 있습니다.

거절이 오면 그 쪽지 옆이 "보내는 중…"에서 "안 갔어요 — 참여하지 않은 대화방입니다"로 바뀝니다. 서버가 준 사유를 그대로 보여주는 거예요.

끊겨 있으면 아예 못 누르게 합니다

Step 2에서 확인한 것 기억나시죠. 안 붙어 있을 때 publish를 부르면 던집니다.

그러니 버튼을 잠급니다.

        <Button type="submit" size="sm" disabled={status !== 'connected'}>
          보내기
        </Button>

지난 시간에 담아둔 연결 상태가 오늘 세 번째로 쓰였습니다. 표시등에 한 번, 구독 시점에 한 번, 이제 버튼 잠금에 한 번이요.

💡 한 줄 정리

통로에는 응답이 없으니 확인을 우리가 만듭니다. 보낼 때 표를 붙이고, 서버가 그 표를 실어 돌려주면 확정하고, 거절은 따로 마련된 줄로 받습니다.

Step 6: "알림은 같은 길로 온다"

세 번째 줄을 하나 더 엽니다

쪽지를 만들고 나면 알림은 쉽습니다. 이미 다 배웠거든요.

내 게시물에 누가 좋아요를 누르거나 댓글을 달면, 그 소식은 나에게만 와야 합니다. 남들에게 뿌릴 이유가 없어요. 그러니 /user를 씁니다.

// apps/web-spa/src/realtime/stompClient.ts
// 나에게 온 알림이 오는 곳.
export const NOTIFICATIONS_QUEUE = '/user/queue/notifications';

이제 우리가 듣는 줄이 넷입니다.

같은 통로 하나 위에 네 줄이 다닙니다. 연결은 여전히 앱에 하나예요.

모르는 종류는 버립니다

알림에는 종류가 있습니다. 좋아요, 댓글, 팔로우처럼요. 서비스가 커지면 종류가 늘어나요.

여기서 미래를 한 번 생각해봅시다. 서버가 나중에 MENTION이라는 새 종류를 보내기 시작하면, 우리 화면은 어떻게 될까요?

우리가 아무 확인도 안 하면 모르는 종류가 그대로 흘러들어옵니다. 화면에 이상한 게 뜨거나 운이 나쁘면 터지기 때문에, 아는 종류만 통과시킵니다.

// apps/web-spa/src/lib/notificationEvents.ts
const KINDS = ['LIKE', 'COMMENT', 'FOLLOW'] as const;

function isKind(value: unknown): value is AppNotification['type'] {
  return typeof value === 'string' && (KINDS as readonly string[]).includes(value);
}

value is AppNotification['type']이 보이시죠. A-2에서 배운 사용자 정의 타입 가드입니다. 서버가 준 것은 unknown이고, 이 함수를 통과해야 우리 타입이 됩니다.

이러면 서버가 새 종류를 늘려도 옛 화면은 그냥 그것을 지나칩니다. 안 터져요.

띄우는 것은 이미 만들어뒀습니다

알림을 화면에 어떻게 보여줄까요?

잠깐 떴다 사라지는 한 줄이면 충분합니다. 그런데 그거, 우리 앱에 이미 있어요. B-4에서 만든 토스트요.

// apps/web-spa/src/components/NotificationToaster.tsx
// 토스트는 이미 만들어둔 것을 그대로 쓴다. "방금 일어난 일" 을 알리는
// 자리라서 role="status" 가 붙어 있는데, 알림이 바로 그것이다.
return <Toast message={current.message} />;

지난 시간에 연결 표시를 만들 때는 role="status"를 일부러 안 붙였습니다. 늘 떠 있는 표시는 "방금 일어난 일"이 아니니까요.

알림은 정확히 그 반대라서, 방금 일어난 일이고 이번엔 맞습니다.

통로와 토스트를 어떻게 잇나요

통로는 앱에 있고, 토스트를 그리는 것은 컴포넌트입니다. 둘을 이을 것이 필요해요.

이것도 이미 해본 적이 있습니다. C-4의 확인 대화상자를 떠올려보세요. 어디서든 열 수 있어야 해서 store에 담고, 앱에 컴포넌트를 하나 그려뒀죠.

// apps/web-spa/src/stores/useNotificationStore.ts
export const useNotificationStore = create<NotificationState>()((set) => ({
  current: null,

  // 겹치면 나중 것이 이긴다. 알림 상자는 한 번에 하나만 띄운다.
  show: (notification) => set({ current: notification }),

  dismiss: () => set({ current: null }),
  reset: () => set({ current: null }),
}));

통로가 show를 부르고, 컴포넌트가 그립니다.

// apps/web-spa/src/realtime/RealtimeBridge.tsx
// 알림도 나에게만 오는 소식이다. 쪽지와 같은 길, 다른 줄.
client.subscribe(NOTIFICATIONS_QUEUE, (message) => {
  const notification = parseNotification(message.body);
  if (notification === null) return;

  useNotificationStore.getState().show(notification);
});

그리고 앱에 한 번만 그려둡니다.

// apps/web-spa/src/AppProviders.tsx
{/* 확인 상자는 감쌀 것이 없다. 앱에 한 번 그려두기만 하면 된다. */}
<ConfirmDialog />
{/* 알림 상자도 같은 자리다. 어느 화면에 있든 떠야 한다. */}
<NotificationToaster />

두 줄이 나란히 있는 게 보이시죠. 성격이 같으면 두는 곳도 같습니다.

띄웠으면 치웁니다

알림이 계속 떠 있으면 화면을 가립니다. 시간이 지나면 사라져야 해요.

// apps/web-spa/src/components/NotificationToaster.tsx
// 띄웠으면 치우는 것까지가 한 일이다 (B-4 에서 세운 규칙).
useEffect(() => {
  if (current === null) return;

  const timerId = setTimeout(dismiss, DURATION);

  return () => clearTimeout(timerId);
}, [current, dismiss]);

정리 함수에서 타이머를 지우는 것도 B-4 그대로입니다. 안 지우면 알림이 연달아 올 때 앞 타이머가 뒤 알림을 일찍 치워버려요.

확인해봅니다

• 탭 두 개를 띄우고 각각 다른 사람으로 로그인합니다.
• minji 쪽에서 jaehoon 님의 게시물에 좋아요를 누릅니다.
• jaehoon 쪽 화면 아래에 알림이 뜹니다.

그리고 한 가지 더 보세요. minji 쪽에는 알림이 안 뜹니다. 자기가 한 일이니까요. 서버가 애초에 안 보냅니다.

같은 좋아요 한 번인데 두 갈래로 갈립니다. 좋아요 개수는 /topic으로 모두에게 가고, 알림은 /user로 게시물 주인에게만 갑니다.

💡 한 줄 정리

알림은 쪽지와 같은 길, 다른 줄로 옵니다. 모르는 종류는 버려서 서버가 늘려도 안 깨지게 하고, 띄우는 것은 이미 만들어둔 토스트와 store 패턴을 그대로 씁니다.

Step 7: "끊긴 동안 온 것은 안 온다"

지난 시간에 남겨둔 구멍입니다

지난 시간 마지막에 이런 이야기를 했죠. 끊겼다 다시 붙는 것까지는 만들었는데, 끊겨 있는 동안 일어난 일은 어떻게 되느냐고요.

오늘 그걸 확인합니다. 직접 해보세요.

• 앱을 띄우고 첫 게시물의 좋아요 개수를 봅니다. 1240이라고 해봅시다.
• 연습용 서버를 끕니다. 연결 표시가 빨갛게 바뀝니다.
• 그 사이에 서버 쪽 값이 1300으로 올라갔다고 해봅시다. 남들이 누른 거예요.
• 서버를 다시 켭니다. 표시가 초록으로 돌아옵니다.

화면은 몇일까요?

1240입니다.

다시 붙었는데도 틀린 값이에요. 통로가 끊겨 있던 동안 서버가 보낸 소식은 어디에도 안 남습니다. 다시 붙는다고 그때 것을 다시 보내주지 않아요.

 시간 →

 붙어 있음   ●─────────●                    ●────────
                        ↑                  ↑
                       끊김               다시 붙음

 그 사이 서버에서 일어난 일:  1240 → 1300
 우리가 받은 소식:            없음
 다시 붙은 뒤 화면:           1240   ← 틀렸다

통로는 편지함이 아닙니다

여기서 통로의 성질을 하나 확실히 해둡시다.

우체통이라면 집을 비운 동안 온 편지가 쌓여 있습니다. 돌아와서 열어보면 되죠.

통로는 그렇지 않습니다. 전화에 가깝습니다. 전화를 안 받으면 그 말은 그냥 사라져요. 상대가 다시 걸어주지 않는 한요.

그러니 다시 붙었을 때 우리가 해야 할 일이 있습니다. 그동안 뭐가 바뀌었는지 물어보는 것이에요.

다시 붙는 순간 물어봅니다

고치는 코드는 짧습니다.

// apps/web-spa/src/realtime/RealtimeBridge.tsx
onConnect: () => {
  setStatus('connected');

  // ★ 끊겨 있던 동안 일어난 일은 통로로 안 온다. 지나간 건 지나간 것이다.
  // 그래서 다시 붙은 순간 받아둔 것을 전부 낡은 것으로 표시해 다시 물어본다.
  //
  // 처음 붙을 때는 안 한다 — 화면이 방금 받아온 것을 또 받을 이유가 없다.
  // 실시간을 붙였다고 물어보는 방식을 버릴 수 없는 이유가 여기 있다.
  if (connectedBefore.current) {
    void queryClient.invalidateQueries();
  }
  connectedBefore.current = true;

invalidateQueries를 인자 없이 부르면 받아둔 것 전부가 낡은 것으로 표시됩니다. 지금 화면이 보고 있는 것부터 다시 물어봐요.

C-7에서 좋아요를 누른 뒤에 불렀던 그 함수입니다. 그때는 특정 키만 지정했는데 오늘은 전부예요. 무엇이 낡았는지 우리가 알 수 없기 때문입니다. 끊겨 있는 동안 무슨 일이 있었는지 모르니까요.

처음 붙을 때와 다시 붙을 때는 다릅니다

connectedBefore라는 것이 보이시죠. 왜 필요할까요?

onConnect는 붙을 때마다 불리고 앱을 처음 켤 때도 불리는데, 그때 무효화하면 어떻게 될까요?

화면이 방금 서버에서 받아온 것을 곧바로 또 받으면 첫 화면에서 요청이 두 배가 되므로, 갈랐습니다. 확인해보면 이렇게 나옵니다.

useRef를 쓴 이유도 짚고 갈게요. 이 값은 화면에 안 나옵니다. 바뀌어도 다시 그릴 이유가 없어요. A-5에서 배운 그 기준입니다. 화면에 나오는 값이면 useState, 기억만 하면 되면 useRef.

그래서 실시간은 물어보기를 못 버립니다

여기가 오늘의 균형점입니다.

지난 시간에 우리는 폴링을 걷어내 요청 1200번을 0번으로 만들었는데, 오늘 다시 물어보고 있어요.

모순처럼 보이지만 아닙니다. 재는 방법이 다릅니다.

평소에는 0번입니다. 끊길 때만 한 번이에요. 폴링을 되살린 게 아니라, 통로가 못 하는 일에만 요청을 쓰는 겁니다.

⚠️ 그러니 실시간을 붙였다고 REST API를 걷어내면 안 됩니다. 통로는 요청 위에 얹는 것이지 대체하는 게 아니에요.

💡 한 줄 정리

통로는 편지함이 아니라 전화입니다. 끊겨 있는 동안 온 것은 사라지므로, 다시 붙는 순간 물어봐서 메웁니다. 처음 붙을 때와는 해야 할 일이 다릅니다.

Step 8: "여기까지가 우리가 할 수 있는 것"

먼저 오늘 얻은 것을 세어봅니다

두 시간에 걸쳐 통로를 열고 그 위에 기능을 얹었습니다. 화면에 뭐가 생겼는지 정리하면 이렇습니다.

한 앱 안에 두 방식이 섞여 있는데, 그게 정상이에요.

그런데 실시간이 늘 좋은 건 아닙니다

지난 시간 첫 Step에서 미뤄둔 이야기를 이제 합니다. 언제 이게 과한가.

통로를 열면 치르는 값이 있습니다. 하나씩 보면 작은데 모으면 꽤 됩니다.

먼저 내려받는 양입니다. 라이브러리를 들이면서 첫 화면에 25 KB가 늘었어요. 지난 시간에 그걸 정직하게 짚었죠. 코드를 쪼개서 없앴던 500 KB 경고가 되돌아왔습니다.

그리고 서버가 붙들고 있는 것입니다. 요청은 왔다 가면 끝인데 연결은 앱을 켜두는 내내 남아요. 사용자 만 명이면 연결 만 개가 계속 열려 있습니다.

마지막으로 우리가 다뤄야 할 것이 늘어납니다. 끊김, 재연결, 놓친 것 메우기, 보낸 것 확인하기. 오늘 만든 것의 절반이 여기에 쓰였어요.

그러니 이렇게 물어보면 됩니다.

 이 화면, 몇 초 늦어도 괜찮은가?

 괜찮다  ──→ 다시 물어보기로 충분하다  (한 줄이면 되고 끊김을 안 다뤄도 된다)
 아니다  ──→ 통로가 필요하다

 늦으면 "틀린 값" 이 되는가?

 그렇다  ──→ 통로가 필요하다  (채팅 · 경매 · 실시간 협업)
 아니다  ──→ 다시 물어보기로 충분하다  (배포 상태 · 대시보드 · 알림 목록)

배포 상태를 보여주는 화면이라면 5초 늦어도 아무 문제 없습니다. 오히려 폴링이 나아요. 코드가 짧고, 서버가 재시작돼도 알아서 붙거든요.

⚠️ 도구를 배웠다고 쓸 곳을 찾지 마세요. 재보고 필요할 때 쓰는 것이 순서입니다. C-8에서 성능을 다룰 때 세운 그 순서와 같아요.

우리 코드로는 못 고치는 것들

이제 오늘의 마지막 이야기입니다. 실시간에는 화면에서 아무리 잘 짜도 안 풀리는 문제가 있습니다.

하나 — 순서를 보장하지 않습니다. 한 연결 안에서는 보낸 순서대로 도착하지만, 서로 다른 줄로 온 것 사이의 순서는 아무도 약속하지 않아요. 쪽지가 /user/queue/dm으로 오고 알림이 /user/queue/notifications로 올 때, 어느 쪽이 먼저 도착할지는 그때그때 다릅니다.

둘 — 같은 것이 두 번 올 수 있습니다. 그래서 오늘 번호를 확인하고 얹었죠. 이건 우리가 막을 수 있는 쪽입니다.

셋 — 서버가 여러 대면 소식이 경계를 못 넘습니다. 지난 시간 생각해볼 주제에서 다뤘던 그 문제예요. 사용자 A는 1번 서버에, B는 2번 서버에 붙어 있으면, 1번 서버가 "모두에게 뿌려"라고 해도 그 모두는 1번 서버에 붙은 사람들뿐입니다.

셋 중에서 우리가 고칠 수 있는 것은 둘뿐입니다. 하나와 셋은 화면 코드로 안 됩니다.

그런데 여기서 중요한 게 있어요. 못 고친다는 걸 아는 것이 실력입니다.

"가끔 소식이 안 와요"라는 제보를 받았다고 해봅시다. 우리 코드만 들여다보면 아무리 봐도 답이 안 나옵니다. 구독도 잘 하고 있고, 얹는 코드도 맞아요.

그때 "서버가 몇 대죠?"라고 물어볼 수 있으면, 그 하루가 절약됩니다.

💡 한 줄 정리

통로는 요청을 대체하지 않고 얹힙니다. 몇 초 늦어도 되는 화면에는 과하고, 늦으면 틀린 값이 되는 화면에는 필요합니다. 그리고 실시간 문제의 일부는 화면 코드로 못 고칩니다.

마무리

두 시간에 걸친 실시간 이야기가 끝났습니다.

지난 시간에는 통로를 열었고, 오늘은 그 위에 기능을 얹었는데, 오늘 배운 것 중에 진짜 오래 남을 것은 기능이 아닙니다.

오늘 배운 핵심 세 가지

💡 하나 — 같은 코드가 다른 결과를 낼 수 있습니다. 두 사람이 구독하는 문자열은 글자 하나 안 달랐는데 도착하는 것은 달랐어요. 클라이언트 코드만 보고 있으면 영영 이해 못 하는 동작입니다. 판단하는 쪽이 어디인지를 알아야 보입니다.

💡 둘 — 통로에는 응답이 없습니다. 보내고 끝이에요. 그래서 확인이 필요하면 우리가 만들어야 하고, 만들다 보면 요청·응답을 다시 짓게 됩니다. 그럴 바에는 요청을 쓰는 게 낫다는 판단도 함께 배웠어요.

💡 셋 — 실시간은 물어보기를 대체하지 않습니다. 통로가 끊긴 동안은 아무것도 못 받고, 지나간 것도 못 받습니다. 그래서 지나간 것은 요청으로, 놓친 것은 다시 붙을 때 요청으로 메웠어요. 얹는 것이지 갈아치우는 게 아닙니다.

오늘 닫은 것

다음 시간 예고

여기까지가 Category C입니다. 되짚어보면 꽤 왔어요.

주소로 화면을 나누고, 주소가 데이터를 데려오게 하고, 값을 나르는 문제를 풀고, 서버에서 가져오고 쓰고, 빠르게 만들고, 실시간을 얹었습니다. 우리 인스타그램은 이제 브라우저에서 도는 완성된 앱이 됐는데, 처음부터 있던 성질이 하나 있습니다. 모든 것이 브라우저에서 일어난다는 것.

주소창에 /p/1을 치면 브라우저가 먼저 빈 화면을 받고, 그다음 우리 코드를 내려받고, 그다음에야 서버에 게시물을 물어봅니다. 그 사이에 사용자는 빈 화면을 봐요.

그리고 검색 엔진이 우리 페이지를 읽으러 오면 어떻게 될까요? 빈 화면을 봅니다. 자바스크립트를 안 돌리는 방문자에게 우리 인스타그램은 그냥 흰 종이예요.

다음 시간부터 Category D입니다. 화면을 서버에서 먼저 그려서 보내는 방식을 배웁니다. 지금까지 만든 것을 버리는 게 아니라, 어디까지가 브라우저의 일이고 어디부터가 서버의 일인지 다시 나누는 시간이에요.

Next.js로 갑니다. 폴더 이름이 곧 주소가 되는 방식부터 시작할게요.

과제

[구현] 안 읽은 쪽지 개수를 머리말에

지금은 쪽지 화면에 들어가야만 새 쪽지가 왔는지 압니다. 머리말에서 알 수 있게 만들어보세요.

• 통로로 쪽지가 오면 개수를 하나 올립니다.
• 쪽지 화면에 들어가면 그 개수를 0으로 되돌립니다.
• 머리말 "쪽지" 옆에 개수를 보여줍니다. 0이면 안 보이게요.
• 내가 보낸 쪽지도 되돌아온다는 것을 잊지 마세요. 그것까지 세면 내가 보낼 때마다 개수가 올라갑니다.
• 이 개수를 어디에 담을지 세 갈래 규칙으로 먼저 정하고, 왜 그렇게 정했는지 한 문장으로 적어주세요.

[구현] 돌아온 사람에게는 즉시 붙는다

지난 시간 생각해볼 주제 3의 답을 실제로 만들어봅니다.

• 브라우저는 탭이 다시 앞으로 왔는지를 알려줍니다. 그 신호를 받으면 기다리던 것을 취소하고 즉시 한 번 시도하세요.
• 대기 시간도 처음 값으로 되돌립니다.
• ⚠️ 이미 붙어 있을 때는 아무것도 하면 안 됩니다. 멀쩡한 연결을 끊었다 붙이면 손해만 봐요.
• 만들고 나서, 탭을 오래 숨겨뒀다가 돌아왔을 때 화면 값이 맞는지 확인해보세요. Step 7에서 만든 것과 어떻게 맞물리는지 함께 적어주세요.

[탐구] 네 줄을 눈으로 보기

우리는 지금 한 연결 위에서 네 줄을 듣고 있습니다. 실제로 그런지 확인해보세요.

• 개발자 도구의 네트워크 탭에서 ws로 걸러 연결 하나를 찾습니다.
• 오간 프레임 중 SUBSCRIBE를 전부 찾아 목적지를 적어보세요.
• 로그인 전과 후에 각각 확인해서, 무엇이 달라지는지 적어보세요.
• 연결이 몇 개인지도 세어보세요. 네 줄을 듣는데 연결은 몇 개인가요?

[탐구] 표를 떼면 무슨 일이 생기나

Step 5에서 붙인 clientId를 일부러 빼보세요.

• 보낼 때 clientId를 안 실어 보냅니다.
• 쪽지를 하나 보내고 화면을 지켜보세요.
• "보내는 중…"이 어떻게 되는지 적어보세요.
• 왜 그렇게 되는지 설명해보세요. 화면이 무엇을 근거로 확정 판정을 하고 있었나요?
• ⚠️ 확인이 끝나면 되돌리세요.

생각해볼 주제

1. 오늘 만든 쪽지에 아직 없는 것

우리 쪽지 화면에는 실무 메신저에 있는 것들이 여럿 빠져 있습니다.

그중에 읽음 표시를 생각해봅시다. 상대가 내 쪽지를 읽었는지 알려주는 기능이요.

이걸 만들려면 무엇이 필요할까요? 어떤 시점에 무엇을 누구에게 보내야 하는지 그려보세요. 그리고 그 과정에서 오늘 배운 것 중 무엇을 다시 쓰게 되는지 짚어보세요.

2. 통로가 하나인 것이 늘 좋을까

우리는 연결을 앱에 하나만 열었습니다. 화면마다 열면 서버 쪽 연결이 화면 수만큼 늘어나니까요.

그런데 그 하나가 모든 것을 나릅니다. 좋아요도, 쪽지도, 알림도요.

여기에 어떤 위험이 있을까요? 그리고 우리 앱이 커져서 실시간으로 다루는 것이 스무 가지가 되면 이 구조가 어떻게 변할지 생각해보세요. 힌트를 드리면, 지금은 붙을 때 모든 줄을 한꺼번에 구독하고 있습니다.

3. 화면에 안 뜨는 실패

Step 5에서 우리는 보내기 실패를 화면에 표시했는데, 그건 서버가 거절해서 답을 준 경우예요.

답조차 안 오는 경우를 생각해봅시다. 보내는 순간 연결이 끊겨서 프레임이 중간에 사라졌다면요? 서버는 그 쪽지를 받은 적이 없으니 거절 답도 안 보냅니다.

우리 화면은 어떻게 될까요? 그리고 이 상황을 사용자에게 어떻게 알려야 할까요? 시간이라는 단서를 쓸 수 있을지 생각해보세요.