Spring Boot + STOMP로 카카오톡 스타일 채팅방 만들기

📌 Spring Boot + STOMP로 카카오톡 스타일 채팅방 만들기

🚀 STOMP + WebSocket을 활용하여 "카카오톡 같은 채팅방 시스템"을 구현해보겠습니다.
📌 STOMP를 사용하면 여러 사용자가 "채팅방을 생성하고 구독하여 메시지를 주고받을 수 있음!"

 

 

구조

src/main/java/com/example/chat/
├── config/
│   ├── WebSocketConfig.java       # WebSocket + STOMP 설정
├── controller/
│   ├── ChatController.java        # REST API (채팅방 생성/조회)
│   ├── StompChatController.java   # STOMP 메시지 처리
├── model/
│   ├── ChatRoom.java              # 채팅방 객체
│   ├── ChatMessage.java           # 채팅 메시지 객체
├── service/
│   ├── ChatService.java           # 채팅방 관리 로직
└── repository/
    ├── ChatRoomRepository.java    # 채팅방 저장소 (메모리)

 

---

HTTP, WebSocket 

HTTP, WebSocket 둘다 tcp를 사용한다.

WebSocket은 HTTP와 다르게 연결을 유지한다.

 

---

SpringBoot에서 WebSocket으로 구현할 경우

전제

c1, c2, c3, c4는 클라이언트다.

서버는 1대(단일 서버)이다.

 

흐름

1) 구독 요청

서버는 클라이언트가 채팅방 이름에 따라 http로 구독요청을 한다.

서버는 메모리에 클라이언트별로 채팅방이름에 따라 메모리에 저장한다.

 

2) c1이 room1에 메시지를 보냄, c2, c3도 메세지를 받아야함

서버에 있는 브로커는 topic == 채팅방이름에 c1이 보낸 메시지를 발행한다.

room1을 구독하는 c2, c3에게 메시지를 전달한다.

 

 

---

STOMP

STOMP는 웹소켓으로만 springboot에서 코드를 작성하면

일일이 내가 Session, SessionManager를 작성해야한다.

이런 코드 구조를 이미 만들어 놓은 것이 STOMP 프로토콜이다.

 

stomp도 서버 내 client session 정보를 내부 메모리에 저장하기 때문에, 다른 서버와 공유되지 않는다.

따라서 멀티 서버 환경에서는 stomp가 제공하는 Broker로 사용할 수 없다.

 

 

---

멀티환경에서 Broker 역할

멀티 환경에서 그대로 Broker를 사용시 문제점: 

• 멀티환경에서는 로드밸런서에 의해서 랜덤으로 서버가 배정 받기 때문에, client가 어떤 서버로 갈지 모른다.
• 다른 서버에 있는 같은 room1을 구독하는 client에게 메세지를 전달할 수 없다.

 

예시

각 클라이언트 별로 구독중인 채팅방 목록

각 클라이언트는 채팅방을 구독중이다.

클라이언트는 로드밸런서에 의해 어느 서버에 배정될지 모른다.

 

 

 

---

멀티 서버 환경(서버가 다른) 같은 채팅방을 구독하는 client에게 메세지를 전파하려면 어떻게 해야할까?

해결 방법: 외부의 독단적인 메모리를 사용하여, 각 서버로 메세지를 전파하면 된다.

 

 

 

Redis의 Pub/Sub(Publish/Subscribe) 기능은 메시지 브로커와 같은 역할

특정 채널(Channel) == 채팅방이름에 메시지를 발행하면,

해당 채널을 구독(Subscribe)한 모든 클라이언트가 메시지를 수신하는 방식으로 동작함

 

---

Redis Pub/Sub 개념 및 원리

Redis의 Pub/Sub 모델은 메시지 큐(Message Queue)와 달리 메시지를 저장하지 않고 즉시 전달하는 방식.

1.1 동작 원리

• Publisher (발행자): 특정 채널(Channel) 에 메시지를 발행(PUBLISH)하면, 해당 채널을 구독한 모든 클라이언트가 메시지를 수신.
• Subscriber (구독자): 특정 채널을 구독(SUBSCRIBE) 하면, 해당 채널에 발행되는 모든 메시지를 실시간으로 수신.
• Channel (채널): 메시지가 발행되고 전달되는 가상의 통로. == 채팅방 이름

room1을 구독한 모든 클라이언트가 "Hello, Redis Pub/Sub!" 메시지를 받음.

---

terminal에서 redis로 테스트 하기

# Redis 설치
sudo apt update
sudo apt install redis -y

# Redis 서버 실행
redis-server

# Subscriber (구독자) 실행
redis-cli
> SUBSCRIBE my_channel


# Publisher (발행자) 실행
redis-cli
> PUBLISH my_channel "Hello, Redis Pub/Sub!"

 

 

Spring Boot 기반 Redis Pub/Sub 코드 구현

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-redis'
}

 

@Configuration
@EnableCaching
public class RedisConfig {

    @Value("${spring.redis.host}")
    private String redisHost;

    @Value("${spring.redis.port}")
    private int redisPort;

    @Bean
    public LettuceConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(redisHost, redisPort);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory());
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        return template;
    }

    @Bean
    public RedisMessageListenerContainer redisMessageListenerContainer(
            RedisConnectionFactory connectionFactory, MessageListenerAdapter listenerAdapter) {
        RedisMessageListenerContainer container = new RedisMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.addMessageListener(listenerAdapter, new PatternTopic("my_channel"));
        return container;
    }

    @Bean
    public MessageListenerAdapter listenerAdapter(RedisSubscriber subscriber) {
        return new MessageListenerAdapter(subscriber, "onMessage");
    }
}

 

@Component
public class RedisPublisher {
    private final RedisTemplate<String, Object> redisTemplate;

    public RedisPublisher(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void publish(String channel, String message) {
        redisTemplate.convertAndSend(channel, message);
    }
}

 

 

 

---

 

redis:latest에서 Redisson과 Redis Pub/Sub 사용 가능 여부

 

build.gradle

 

 

 

 

✅ (1) Redisson 설정 (Spring Boot)

 

Redisson을 사용하려면 Redisson 클라이언트 라이브러리, redisson.yaml, Bean 등록이 필요함

 

 

✅ (2) Redis Pub/Sub 설정

Pub/Sub을 사용하려면 RedisTemplate과 MessageListener를 설정

 

 

 

 

 

---

docker compose up -d

 

 

 

 

• Kafka를 KRaft 모드로 실행하면 Zookeeper 없이 작동하지만, 반드시 CLUSTER_ID를 설정해야 함.
• CLUSTER_ID가 없으면 Kafka가 실행되지 않고 Command [/usr/local/bin/dub ensure CLUSTER_ID] FAILED ! 오류 발생.

 

 

docker run --rm confluentinc/cp-kafka:latest kafka-storage random-uuid

-> 랜덤 아이디 생성해줌

 

2025-03-19 16:49:17 ===> User
2025-03-19 16:49:17 uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
2025-03-19 16:49:17 ===> Configuring ...
2025-03-19 16:49:17 Running in KRaft mode...
2025-03-19 16:49:18 ===> Running preflight checks ... 
2025-03-19 16:49:18 ===> Check if /var/lib/kafka/data is writable ...
2025-03-19 16:49:18 ===> Running in KRaft mode, skipping Zookeeper health check...
2025-03-19 16:49:18 ===> Using provided cluster id sPjlIZ5GRP658xZlxkiDzg ...
2025-03-19 16:49:19 Exception in thread "main" java.lang.IllegalArgumentException: requirement failed: controller.listener.names must contain at least one value appearing in the 'listeners' configuration when running the KRaft controller role at scala.Predef$.require(Predef.scala:337) at kafka.server.KafkaConfig.validateControllerListenerExistsForKRaftController$1(KafkaConfig.scala:1290) at kafka.server.KafkaConfig.validateValues(KafkaConfig.scala:1352) at kafka.server.KafkaConfig.<init>(KafkaConfig.scala:1223) at kafka.server.KafkaConfig.<init>(KafkaConfig.scala:545) at kafka.tools.StorageTool$.$anonfun$execute$1(StorageTool.scala:72) at scala.Option.flatMap(Option.scala:283) at kafka.tools.StorageTool$.execute(StorageTool.scala:72) at kafka.tools.StorageTool$.main(StorageTool.scala:53) at kafka.tools.StorageTool.main(StorageTool.scala)

 

services:
    redis:
        image: redis:latest
        container_name: redis
        ports:
            - "6379:6379"
        networks:
            - webtoon

    postgres:
        image: postgres:latest
        container_name: postgres
        ports:
            - "5432:5432"
        environment:
            POSTGRES_DB: 디비
            POSTGRES_USER: 유저
            POSTGRES_PASSWORD: 비번
        volumes:
            - postgres_data:/var/lib/postgresql/data  # 데이터 유지
        networks:
            - webtoon

    kafka:
        image: confluentinc/cp-kafka:latest
        container_name: kafka
        ports:
            - "9092:9092"
        environment:
            KAFKA_NODE_ID: 1
            KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093,PLAINTEXT_INTERNAL://:9094  # CONTROLLER 리스너 추가
            KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092,PLAINTEXT_INTERNAL://kafka:9092 #브로커용 리스너
            KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
            KAFKA_PROCESS_ROLES: controller,broker #Kafka를 브로커와 컨트롤러 역할을 동시에 수행하도록 설정
            KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093 #컨트롤러 선출을 위한 설정
            KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER #리스너
            KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_INTERNAL:PLAINTEXT #보안 프로토콜 매핑
            KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT_INTERNAL  # 내부 브로커 통신용 설정 변경 # PLAINTEXT 브로커 간 통신 방식 지정
            CLUSTER_ID: sPjlIZ5GRP658xZlxkiDzg  # 생성한 CLUSTER_ID 추가
        volumes:
            - kafka_data:/var/lib/kafka/data #Kafka 데이터를 유지하기 위해 볼륨 추가
        networks:
            - webtoon
volumes:
    postgres_data:
    kafka_data:

networks:
    webtoon:
        external: true  # 이미 생성된 네트워크를 사용
        name: webtoon
        driver: bridge

 

🔍 PLAINTEXT란?

Kafka에서 PLAINTEXT는 암호화되지 않은 일반 텍스트 통신 프로토콜을 의미합니다.

Kafka는 여러 가지 보안 프로토콜을 지원하는데, PLAINTEXT는 TLS(SSL) 없이 암호화되지 않은 데이터를 전송하는 가장 기본적인 방식입니다.

 

 

📌 Kafka의 listener 프로토콜 옵션

프로토콜	설명	데이터 암호화	인증 기능	일반적인 사용 환경
PLAINTEXT	암호화되지 않은 일반 TCP 통신 (기본값)	❌ 없음	❌ 없음	내부 네트워크 (개발 환경)
SSL	TLS(SSL) 암호화가 적용된 통신	✅ TLS 암호화	❌ 없음	보안이 필요한 환경
SASL_PLAINTEXT	PLAINTEXT + 사용자 인증 (SASL) 추가	❌ 없음	✅ ID/PW 인증 가능	보안이 필요한 환경
SASL_SSL	SSL + 사용자 인증 (SASL) 추가	✅ TLS 암호화	✅ ID/PW 인증 가능	최상의 보안 필요

 

KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093,PLAINTEXT_INTERNAL://:9094 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_INTERNAL:PLAINTEXT

 

• PLAINTEXT://:9092 → 클라이언트(예: Spring Boot 애플리케이션)가 Kafka 브로커에 접속하는 기본 리스너.
• CONTROLLER://:9093 → Kafka 컨트롤러(브로커 간 리더 선출 등)를 위한 리스너.
• PLAINTEXT_INTERNAL://:9094 → 내부 브로커 간 통신을 위한 리스너.

 

 

🔒 PLAINTEXT 대신 SSL을 사용해야 할 때

✅ PLAINTEXT는 보안이 없기 때문에, 프로덕션 환경에서는 SSL을 사용하는 것이 권장됩니다.
Kafka 브로커가 외부 인터넷에 연결되는 경우, SSL 또는 SASL_SSL을 사용해야 합니다.

KAFKA_LISTENERS: SSL://:9092,CONTROLLER://:9093 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:SSL,SSL:SSL

 

 

 

 

 

 

---

테이블 설계

 

---

🚀 엔티티 매핑: 연관관계 매핑

테이블, 외래키 매핑 vs 객체지향, 참조

• 일반적인 채팅 서비스라면 @ManyToOne이 더 객체지향적으로 적합
• 대규모 채팅 서비스라면 UUID 저장 방식이 JOIN 부담을 줄여서 성능이 더 좋음
• 중간 타협안: UUID를 저장하되, 캐싱(Redis)과 조합해서 성능 보완 가능 🚀

 

	@ManyToOne(객체 관계 매핑)	UUID 직접 저장, 테이블 외래키 매핑
채팅방 참조 방식	@ManyToOne private ChatRoomEntity chatRoomId;	@Column(nullable = false) private UUID chatRoomId;
사용자 참조 방식	@ManyToOne private UserEntity userId;	@Column(nullable = false) private UUID userId;
JOIN 여부	JOIN 필요 (객체 관계 매핑)	JOIN 불필요 (UUID 직접 저장)
JPA 관계 활용성	✅ 객체 탐색 가능 (JPA 연관관계)	❌ 객체 탐색 불가능 (ID만 저장)
유연성	🚀 JPA와 객체지향적으로 사용 가능	⚡ 성능 최적화에 유리 (JOIN 최소화 가능)

 

---

❓왜 테이블 매핑에서 조인이 필요 없다고 하는가?

FK 값을 단순히 저장하는 방식이기 때문에 JPA가 내부적으로 자동 조인을 수행하지 않습니다.

ChatParticipantEntity를 조회한 후 채팅방이나 유저 정보를 추가로 가져오려면 수동으로 JOIN이 필요함.

 

@Column(nullable = false)
private UUID chatRoomId;  // ✅ 채팅방 ID (FK)

@Column(nullable = false)
private UUID userId;  // ✅ 참여자 ID (FK)

• chatRoomId와 userId가 UUID 값으로 저장되어 있음.
• JPA에서 객체 참조를 하지 않기 때문에 쿼리 실행 시 자동 조인 발생 안 함.
• findAll()을 호출하면 p_chat_participants 테이블에서 chatRoomId, userId 값을 가져올 뿐, 연관된 테이블을 조회하지 않음.
• 실제 채팅방 또는 유저 정보를 가져오려면 추가적인 쿼리를 직접 수행해야 함.

호출 결과

SELECT * FROM p_chat_participants;

 

chatroom 정보, user 정보를 사용하려면 jpa로 각각 조회해야함

List<ChatParticipantEntity> participants = chatParticipantRepository.findAll();
for (ChatParticipantEntity participant : participants) {
    UUID chatRoomId = participant.getChatRoomId();
    UUID userId = participant.getUserId();

    ChatRoomEntity chatRoom = chatRoomRepository.findById(chatRoomId).orElse(null);
    UserEntity user = userRepository.findById(userId).orElse(null);
}

• chatRoomRepository.findById(chatRoomId)와 userRepository.findById(userId)를 별도로 수행해야 함.
• 즉, JPA가 자동 조인을 하지 않기 때문에 쿼리가 분리됨.

 

객체 관계 매핑 스타일

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "chat_room_id", nullable = false)
private ChatRoomEntity chatRoom;

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id", nullable = false)
private UserEntity user;

객체 참조를 사용하면 JPA가 자동으로 조인을 수행합니다.

 

호출 결과

SELECT cp.*, cr.*, u.*
FROM p_chat_participants cp
JOIN p_chat_rooms cr ON cp.chat_room_id = cr.chat_room_id
JOIN p_users u ON cp.user_id = u.user_id;

• JPA가 ChatRoomEntity와 UserEntity를 객체로 참조함.
• findAll()을 호출하면, 기본적으로 JOIN 없이 chat_participants 테이블만 조회함.
• 이후 getChatRoom()이나 getUser()를 호출하면 **지연 로딩(Lazy Loading)**으로 쿼리가 실행됨.
• fetch = FetchType.EAGER를 사용하면 자동 조인 발생.

---

 

ChatParticipantEntity -> 객체지향 매핑: chatRoomId, userId

package com.webtoonmaker.api.chat.entity;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.EntityListeners;
import jakarta.persistence.Id;
import jakarta.persistence.JoinColumn;
import jakarta.persistence.ManyToOne;
import jakarta.persistence.Table;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import java.util.UUID;

@Entity
@Table(name = "p_chat_participants")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@EntityListeners(AuditingEntityListener.class)
@Getter
public class ChatParticipantEntity extends BaseEntity {

    @Id
    @Column(name = "chat_participant_id", columnDefinition = "UUID", nullable = false, unique = true)
    private UUID chatParticipantId;

    @ManyToOne
    @JoinColumn(name = "chatroom_id", nullable = false)
    private ChatRoomEntity chatRoomId;

    @ManyToOne
    @JoinColumn(name = "user_id", nullable = false)
    private UserEntity userId;
}

✅ 장점

• chatRoom.getParticipants() 객체 탐색 가능
• user.getChatRooms() JPA 연관관계를 통해 쉽게 접근 가능
• JPA 관계 설정으로 코드가 더 객체지향적으로 유지됨

❌ 단점

• JOIN 쿼리 필수 → 대규모 서비스에서는 성능 부담이 될 수 있음
• 캐싱이 없으면 느려질 가능성 존재

 

 

 

 

ChatParticipantEntity -> 테이블, 외래키 매핑: chatRoomId, userId

@Entity
@Table(name = "p_chat_participants")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@EntityListeners(AuditingEntityListener.class)
@Getter
public class ChatParticipantEntity extends BaseEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private UUID chatRoomId;  // ✅ 채팅방 ID (FK)

    @Column(nullable = false)
    private UUID userId;  // ✅ 참여자 ID (FK)

    @Builder
    private ChatParticipantEntity(UUID chatRoomId, UUID userId) {
        this.chatRoomId = chatRoomId;
        this.userId = userId;
    }

    public static ChatParticipantEntity join(UUID chatRoomId, UUID userId) {
        return ChatParticipantEntity.builder()
            .chatRoomId(chatRoomId)
            .userId(userId)
            .build();
    }
}

 

✅ 장점

• JOIN이 필요 없음 → 성능이 뛰어남
• 쿼리 단순화 → SELECT * FROM p_chat_participants WHERE chatRoomId = ?
• JPA가 아닌 네이티브 쿼리 (QueryDSL, MyBatis) 사용이 더 편리함

❌ 단점

• chatRoom.getParticipants() 이런 식으로 객체 탐색 불가능
• user.getChatRooms() 같은 연관관계 활용 불가능 → 별도 쿼리 필요
• 데이터 무결성 체크가 필요함 → UUID가 DB에 존재하는지 확인해야 함

 

---

🔥 결론: 어떤 방식이 좋을까?

✅ JPA 연관관계 (@ManyToOne) 추천하는 경우

• 객체 탐색이 중요한 경우 (JPA를 적극적으로 활용)
• 서비스 로직이 복잡하고 관계형 데이터 조작이 많을 때
• 채팅방과 유저 간 관계를 객체 지향적으로 관리하고 싶을 때

✅ UUID 직접 저장 방식 추천하는 경우

• 대규모 채팅 서비스 (대량의 데이터가 저장되는 경우)
• 성능이 중요하고 JOIN을 최소화하고 싶을 때
• NoSQL 같은 분산 환경을 고려하는 경우

 

 

채팅메세지에서 채팅방id를 테이블조인? 객체지향?

chatRoomId를 객체 참조로 할지 (ChatRoomEntity) 문자열로 유지할지 결정

• 객체 참조 (@ManyToOne):
  • ChatRoomEntity 객체를 직접 참조할 경우, 객체지향적으로 연관관계를 명확히 표현할 수 있음.
  • 하지만 채팅방 ID만 필요한 경우, 불필요한 JOIN이 발생할 수 있어 성능이 떨어질 수도 있음.
• 현재처럼 String 유지:
  • 단순히 ID 값만 저장하고, chatRoomId를 기반으로 별도로 조회하면, JOIN이 필요 없어 성능상 유리.
  • 메시지 수가 많을 경우, ChatRoomEntity를 직접 참조하는 것보다 단순 ID로 관리하는 것이 더 효율적.