온핏(On-Fit) 프로젝트에서 채팅방 읽음 처리 기능을 직접 설계하고 구현했다.

단순히 “안 읽은 메시지 개수만 보여주면 되는 거 아님?”이라고 생각했지만,

막상 구현하려니 아키텍처부터 정해야 할 게 꽤 많았다.

이 글에서는 내가 이 기능을 어떻게 구조화했고,

왜 이런 방식으로 설계했는지,

그리고 실제 구현 코드를 정리해본다.

---

📌 1. 해결해야 했던 문제

온핏의 채팅 기능에서 나는 다음 요구사항을 만족시키고 싶었다:

• 채팅방 리스트에서 unreadCount(안 읽은 메시지 개수)를 표시한다
• 사용자가 채팅방에 들어가는 순간 → 해당 방 메시지를 읽음 처리한다
• 읽음 처리된 내용은 서버(DB) 기준으로 관리해야 한다
• 채팅방을 나갔다 다시 들어오면 뱃지가 사라져야 한다
• 새 메시지가 오면 다시 뱃지가 생겨야 한다

즉, 카카오톡·인스타 DM처럼 자연스러운 UX가 필요했다.

---

🧱 2. 아키텍처 설계

✔ 핵심 데이터 구조: messages.read_by

먼저 Supabase(Postgres)의 messages 테이블에

“누가 이 메시지를 읽었는지” 저장할 구조가 필요했다.

그래서 read_by 배열 컬럼을 하나 추가했다.

alter table messages
add column read_by text[] default '{}';

예시:

read_by = ['user1', 'user2']

이 메시지를 읽은 유저들의 목록을 담는다.

이 구조를 채택한 이유:

• unreadCount 계산이 매우 쉬워짐
• 여러 유저가 참여하는 채팅방에서도 확장성 있음
• 실시간 반응(Realtime)을 붙일 때도 유리함

---

✔ API 분리 전략: “조회”와 “행위”는 나눈다

이 기능을 설계하면서 가장 중요하게 한 결정은 API를 두 개로 분리하는 것이었다.

1) GET /api/chat/rooms

→ 채팅방 리스트 + unreadCount 계산

→ 조회 전용

2) POST /api/chat/read

→ 유저가 방에 들어간 순간 메시지를 읽음 처리

→ 행위(Action) 전용

이렇게 분리한 이유는 간단하다.

• *조회(GET)**는 캐싱해도 되고, SSR에서 불러도 됨
• *행위(POST/PATCH)**는 DB를 수정하는 API라 별도 관리해야 함

둘을 섞어버리면 유지보수도 확장도 애매해진다.

---

📦 3. unreadCount 계산 로직

unread의 조건은 이렇다:

1. sender_id !== user.id (내가 보낸 메시지는 제외)
2. read_by 배열에 내 user.id가 없음

다음 코드로 room별 unreadCount를 만들어냈다.

const unreadCountByRoom: Record<string, number> = {};

(messages ?? []).forEach((m) => {
  const rid = m.room_id as string;
  const senderId = m.sender_id as string | null;
  const readBy = (m.read_by ?? []) as string[];

  if (senderId !== user.id && !readBy.includes(user.id)) {
    unreadCountByRoom[rid] = (unreadCountByRoom[rid] ?? 0) + 1;
  }
});

그리고 최종 응답에 포함:

unreadCount: unreadCountByRoom[rid] ?? 0

이제 프론트에서는 단순히 unreadCount만 받아 쓰면 된다.

---

🛠 4. 읽음 처리 API 만들기

POST /api/chat/read

유저가 방에 진입하자마자 호출되는 API다.

• 해당 방 메시지 중 → 내가 읽지 않은 메시지를 모두 찾아 → read_by에 내 userId 추가
  

export async function POST(req: Request) {
  const supabase = await createSupabaseServerClient();

  const { ok: hasUser, user, response } = await requireUserOr401(supabase);
  if (!hasUser || !user) return response;

  const { roomId } = await req.json();

  const { data: messages } = await supabase
    .from("messages")
    .select("id, read_by, sender_id")
    .eq("room_id", roomId);

  const targets = messages.filter((m) => {
    return m.sender_id !== user.id && !m.read_by.includes(user.id);
  });

  await Promise.all(
    targets.map((m) =>
      supabase.from("messages").update({
        read_by: [...m.read_by, user.id],
      }).eq("id", m.id)
    )
  );

  return ok({ updated: targets.length });
}

Promise.all로 병렬 업데이트하여 성능도 확보했다.

---

📱 5. 프론트에서 읽음 처리 트리거하기

채팅방 카드를 눌렀을 때:

1. /api/chat/read 호출 (읽음 처리)
2. /chat/[roomId]로 이동

const handleChatRoomCard = () => {
  api.post("/api/chat/read", { roomId });
  router.push(`/chat/${roomId}`);
};

이제 사용자가 방에 들어가는 순간 DB에 read_by가 갱신된다.

다시 채팅 리스트로 나오면

GET /api/chat/rooms가 최신 unreadCount=0을 가져오므로

뱃지가 자연스럽게 사라진다.

---

✅ 6. 완성된 UX 흐름

이제 온핏에서는 이렇게 동작한다.

1. 채팅방 목록 → 빨간 뱃지로 unreadCount 표시
2. 방 진입 → 자동으로 read 처리
3. 목록으로 돌아오면 뱃지가 사라짐
4. 새로운 메시지가 오면 다시 뱃지가 생김

메신저 앱처럼 자연스러운 사용 경험이 만들어졌다.

---

🎯 7. 설계 총정리

정리하면 이번 기능은 이런 구조로 설계했다.

• messages.read_by 배열로 읽음 여부 관리
• GET /api/chat/rooms → 조회 전용
• POST /api/chat/read → 상태 변경(행위) 전용
• 프론트에서 방 입장 시 read API 호출
• 목록 화면은 GET API를 다시 호출해서 최신 unreadCount 반영

이 구조는 매우 직관적이고, Next.js Route Handler 패턴과도 잘 맞아떨어진다.

---

📝 마무리

이번에 읽음 처리 기능을 직접 설계하면서 다음을 배웠다.

• API는 “조회(GET)”와 “행위(POST/PATCH)”를 분리하면 유지보수성이 좋아진다
• Supabase 배열 타입(read_by)을 활용하면 챗 시스템 확장성이 넓어진다
• Next.js Route Handler는 RESTful 구조를 만들기 매우 좋다
• 프론트에서는 최소한의 호출만으로 자연스러운 UX를 만들 수 있다