이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
채팅 기능 개발에서 처음 구현한 것은 실시간 메시지 전송이었습니다. WebSocket 연결을 유지하면서 클라이언트가 메시지를 보내면 서버가 같은 방의 모든 연결에 즉시 브로드캐스트하는 구조를 만들었습니다.
읽음 처리도 사용자 경험에 중요한 기능이었습니다. 상대방이 메시지를 읽은 시점을 표시하려면 클라이언트가 메시지를 화면에 표시하는 시점을 서버에 알리는 구조가 필요했고, 배치 처리로 불필요한 DB 쓰기를 줄이는 방식을 적용했습니다.
메시지 히스토리 조회에서는 커서 기반 페이징을 사용했습니다. 일반 오프셋 페이징은 데이터가 많을수록 성능이 떨어지는데, 마지막 메시지 ID를 기준으로 이전 데이터를 가져오는 방식으로 대화 이력이 많아도 일정한 응답 속도를 유지했습니다.
채팅 기능을 처음 구현했을 때 단일 서버에서는 잘 작동했는데, 서버를 여러 대로 늘렸을 때 문제가 생겼습니다. 각 서버가 자체적으로 연결을 관리하다 보니, 서버 A에 연결된 사용자가 서버 B에 연결된 사용자에게 보낸 메시지가 전달되지 않았습니다. 서버 간에 메시지를 공유하는 메시지 브로커를 중간에 두는 방식으로 해결했는데, 모든 서버가 같은 채널을 구독하면 어느 서버로 들어온 메시지든 전체에 전파됩니다. 이 구조로 전환하면서 단일 서버 시절에는 고려하지 않아도 됐던 연결 상태 관리가 복잡해졌습니다. 특정 사용자가 온라인인지 확인하려면 단일 서버의 메모리를 보면 됐는데, 다중 서버 환경에서는 공유 저장소에서 온라인 상태를 조회해야 했습니다. 채팅 시스템은 단일 서버에서 작동하는 것과 여러 서버로 확장하는 것이 구조적으로 다른 문제라는 것을 이 경험에서 배웠습니다.
채팅 기능에 파일 전송을 추가하면서 텍스트 메시지와 다른 처리가 필요하다는 것을 배웠습니다. 처음에는 파일을 WebSocket으로 직접 전송하려 했는데, 파일 크기가 크면 연결이 끊기거나 다른 메시지 전달에 영향을 주는 문제가 생겼습니다. 파일은 별도의 업로드 경로로 먼저 저장하고, 채팅 채널에는 파일 URL만 전달하는 방식으로 분리했습니다. 이렇게 하니 파일 업로드가 느려도 채팅 응답성에 영향을 주지 않았고, 파일 저장과 메시지 전달을 독립적으로 관리할 수 있었습니다. 한 가지 한계는 파일 업로드 중에 연결이 끊기면 업로드가 중단되는 문제였는데, 재개 가능한 업로드 방식을 구현하지 못해 용량이 큰 파일은 다시 처음부터 올려야 했습니다. 채팅에서 파일 전송은 텍스트와 다른 전송 패턴이 필요하다는 것을, 처음부터 분리해서 설계했다면 나중에 고치는 비용을 줄일 수 있었다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부동산플래닛 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.