[CS] 사내에 3000명이 사용할 메신저 프로그램을 만들어보세요

한강섭·2025년 9월 10일

목록 보기

2/3

만약 갑작스럽게 면접에서 3000명이 사용할 메신저 프로그램을 만들어보라고 한다면 어떻게 답변할 것인가?

일단 내 상황을 정리하자면 풀스택 개발자로써 프론트엔드, 백엔드 개발을 모두 진행하였고, 인프라 경험, PM 경험까지 자소서에 녹였기 때문에 이러한 모든 관점에서 생각할 수 있다고 어필해야 할 것 같고 단계별로 키워드를 중심으로 얘기 해보려고 한다.

요구사항 정리

일단 먼저 문제상황을 정리해야 한다. 자신이 정리하지 못하겠으면 면접관과 소통하면서 문제상황, 요구사항을 정리한다.
키 포인트로는 기능 요구사항, 비기능 요구사항을 정리한다.

"먼저 요구사항을 명확히 해야할 것 같습니다. 기능적으로는 1대1 채팅, 그룹 채팅, 파일 전송이 핵심 기능일 것 같고, 비기능적으로는 3000명 동시 접속, 실시간 메시지 전달, 기밀 정보에 대한 보안이 핵심 요구사항이라고 볼 수 있습니다."

아키텍처

정리된 요구사항을 바탕으로 아키텍처를 그려본다. 확장성은 언제나 필요하니 MSA구조로 설계해서 나중에 외부 서비스를 연동할 때 편한 구조로 설계한다.

"전체적인 아키텍처는 클라이언트-서버 구조로 가져가되, 확장성을 고려해서 마이크로서비스 아키텍처로 설계하겠습니다. 주요 서비스로는 사용자 관리, 메시지 처리, 알림 서비스, 파일 업로드로 분리해서 설계할 것 같습니다."

기술 스택

기능적, 비기능적 요구사항에 맞게 특성을 맞춰서 설계한다.

"기술 스택은 프론트엔드는 React로, 실시간 통신을 위해 WebSocket을 활용하겠습니다. 백엔드는 Node.js나 Java Spring 중에 팀 상황에 맞는 걸로 선택하고, 데이터베이스는 사용자 정보 DB는 PostgreSQL, 메시지 데이터처럼 빠른 읽기, 쓰기가 필요한 건 MongoDB를 사용하겠습니다."
"실시간 메시징 부분은 WebSocket 연결 관리가 중요한데, 사용자가 많아질수록 연결을 효율적으로 관리해야 하니깐 Redis나 Kafka 같은 메시지 큐를 활용해서 메시지 브로커 역할을 하게 하겠습니다. 특히 Redis Pub/Sub을 이용하면 실시간 메시지 라우팅이 가능합니다."
"보안 측면에서는 모든 통신에 HTTPS와 WSS(Secure WebSocket)를 적용해서 전송 중 데이터를 암호화하고, 데이터베이스에 저장되는 메시지는 AES-256 암호화를 적용하겠습니다. 또한 JWT 토큰 기반의 인증 시스템을 구축해서 사용자 권한 관리를 하겠습니다."

인프라 관점

선택한 아키텍처를 구현할 수 있도록 Docker와 Kubernates선택하고 모니터링도 추가한다.

"인프라 관점에서 보자면 Docker 컨테이너화를 통해 배포 일관성을 보장하고, Kubernetes를 활용한 오케스트레이션으로 자동 스케일링과 장애 복구를 구현하겠습니다. 모니터링은 Prometheus와 Grafana로 시스템 메트릭을 수집하겠습니다."

PM 관점

개발 방법론 특히 워터폴과 애자일 방식중 하나를 선택하고 이유를 밝힌다.

"마지막으로 PM 관점에서 말씀드리면, 워터폴 방식보다는 애자일 개발 방식을 선택해서 진행할 것 같습니다. 사내 메신저 특성 상 사용자가 명확하고 접근하기 쉽기 때문에 2~4주 스프린트마다 피드백을 통해 수정, 개선할 수 있기 때문입니다. 따라서 MVP로 핵심 기능인 1대1 채팅, 그룹 채팅부터 먼저 출시하고, 사용자 피드백을 받으면서 파일 전송, 알림 기능 등을 기능을 추가해나가겠습니다."

전체 정리

면접관 :
자소서를 읽어보니 프론트, 백, 인프라, PM 경험까지 다재다능 하신데, 그렇다면 사내 3000명의 직원이 사용할 메신저 앱을 만들려면 어떻게 접근하시고, 구현하실 것인지 과정을 쭉 한번 말해주세요.

나 :
먼저 요구사항을 명확히 해야할 것 같습니다. 기능적으로는 1대1 채팅, 그룹 채팅, 파일 전송이 핵심 기능일 것 같고, 비기능적으로는 3000명 동시 접속, 실시간 메시지 전달, 기밀 정보에 대한 보안이 핵심 요구사항이라고 볼 수 있습니다.
전체적인 아키텍처는 클라이언트-서버 구조로 가져가되, 확장성을 고려해서 마이크로서비스 아키텍처로 설계하겠습니다. 주요 서비스로는 사용자 관리, 메시지 처리, 알림 서비스, 파일 업로드로 분리해서 설계할 것 같습니다.
기술 스택은 프론트엔드는 React로, 실시간 통신을 위해 WebSocket을 활용하겠습니다. 백엔드는 Node.js나 Java Spring 중에 팀 상황에 맞는 걸로 선택하고, 데이터베이스는 사용자 정보 DB는 PostgreSQL, 메시지 데이터처럼 빠른 읽기, 쓰기가 필요한 건 MongoDB를 사용하겠습니다.
실시간 메시징 부분은 WebSocket 연결 관리가 중요한데, 사용자가 많아질수록 연결을 효율적으로 관리해야 하니깐 Redis나 Kafka 같은 메시지 큐를 활용해서 메시지 브로커 역할을 하게 하겠습니다. 특히 Redis Pub/Sub을 이용하면 실시간 메시지 라우팅이 가능합니다.
보안 측면에서는 모든 통신에 HTTPS와 WSS(Secure WebSocket)를 적용해서 전송 중 데이터를 암호화하고, 데이터베이스에 저장되는 메시지는 AES-256 암호화를 적용하겠습니다. 또한 JWT 토큰 기반의 인증 시스템을 구축해서 사용자 권한 관리를 하겠습니다.
인프라 관점에서 보자면 Docker 컨테이너화를 통해 배포 일관성을 보장하고, Kubernetes를 활용한 오케스트레이션으로 자동 스케일링과 장애 복구를 구현하겠습니다. 모니터링은 Prometheus와 Grafana로 시스템 메트릭을 수집하겠습니다.
마지막으로 PM 관점에서 말씀드리면, 워터폴 방식보다는 애자일 개발 방식을 선택해서 진행할 것 같습니다. 사내 메신저 특성 상 사용자가 명확하고 접근하기 쉽기 때문에 2~4주 스프린트마다 피드백을 통해 수정, 개선할 수 있기 때문입니다. 따라서 MVP로 핵심 기능인 1대1 채팅, 그룹 채팅부터 먼저 출시하고, 사용자 피드백을 받으면서 파일 전송, 알림 기능 등을 기능을 추가해나가겠습니다.

라고 했어야 했는데 젠장...