하면 된다

패스트캠퍼스 환급 챌린지 48일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Sun, 18 May 2025 11:41:27 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 48일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버의 회원가입 기능 구현을 위한 docker와 Spring Data JPA에 대한 개념 학습을 진행하였다.

카카오톡 인증을 통해 카카오톡으로부터 사용자 정보를 받아오고, 이 정보들을 이용해서 우리의 채팅 서비스에 회원 정보가 있는지 확인하여 (회원 정보가 없다면) 카카오톡에서 받아온 정보로 회원가입을 시키고, (회원 정보가 있다면) 로그인을 완료하도록 구현하는 작업을 진행하기로 했다.

이번 강의에서는 구현에 들어가기 전, 사용할 기능들에 대한 개념 학습을 먼저 진행하였다.

Docker

: 컨테이너 기반의 오픈소스 가상화 플랫폼 (컨테이너: 프로세스를 격리시켜 동작할 수 있도록 표준화된 패키징)

- 컨테이너 내에는 소프트웨어가 작동하는 데 필요한 라이브러리, 시스템 도구, 코드, 런타임 등을 모두 포함하고 있기 때문에, 환경에 구애받지 않고 어플리케이션을 배포 및 확장할 수 있다는 장점이 있다.

- image라고 하는 어플리케이션 실행에 필요한 모든 것들을 포함하는 템플릿을 사용하여 실행된다.

- 기존의 가상화 기술은 OS부터 어플리케이션까지 모든 구성 요소를 가상화했다면, 도커는 호스트 OS는 컨테이너 간 커널을 공유하고, OS 위에서 작동하는 프로세스에 필요한 것들만 가상화한다. => 가볍고 안정적

MySQL

: 대표적인 오픈소스 RDBMS

Spring Data JPA

: 스프링 프레임워크에서 데이터 접근 계층을 간편하게 구현할 수 있도록 도와주는 모듈

- Query Method: 메서드 이름을 기반으로 하여 JPA의 쿼리를 자동으로 생성해주는 기능

노트북을 바꾸기 전에 사용하던 기기에서는 MySQL을 직접 설치하여 사용한 적이 있다.

도중에 충돌이 생겨 지웠다가 다시 설치해야 하는 상황이 생겼는데, 곳곳에 남아있는 설정들 때문에 꽤 고생을 했던 기억이 난다.

이번에는 깔끔하고 편하게 작업을 진행하고 싶어 사용해야 하는 것이 있다면 도커를 사용하고 있는데, 너무 만족스럽다!

로컬에서 사용하는 것만 아니라 배포 작업 등에도 도커를 사용해보고 싶다.

패스트캠퍼스 환급 챌린지 47일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Sat, 17 May 2025 01:06:41 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 47일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버의 OAuth2를 이용한 로그인 기능 고도화 작업을 진행하였다.

OAuth2

: 사용자의 아이디와 비밀번호를 공유하지 않고도 다른 서비스에서 제공하고 있는 정보에 사용자를 대신해서 접근할 수 있는 기능

OAuth2에서 정의하는 4개의 role

1. Resource Owner: 사용자

2. Client: 사용자의 인증을 통해 카카오톡 등의 서비스에 저장되어 있는 정보에 접근하고자 하는 어플리케이션 (현재의 경우, 채팅 서비스)

3. Authorization Server: 사용자의 인증을 받은 클라이언트에게 리소스 서버에 접근할 수 있는 access token을 발급해주는 서버

4. Resource Server: 사용자의 정보를 담고 있는 서버

이번 프로젝트에서는 Authorization Code Grant 방식을 사용하기로 했다.

1. Resource Owner가 클라이언트로 접근을 시도

2. Client는 Authorization 서버로 Resource Owner를 Redirect 시켜 인증을 하도록 함

3. Resource Owner가 Authorization 서버를 통해 로그인 -> Authorization 서버는 Authorization Code 발급해줌

4. Resource Owner가 위에서 발급받은 코드를 클라이언트에 전달 -> Authorization 서버로부터 리소스 서버에 접근할 수 있는 Access Token을 발급받음

5. 이후, 클라이언트는 필요 시 Access Token을 통해 리소스 서버로부터 리소스 오너(사용자)의 정보를 가져옴

스프링 시큐리티에서는 OAuth2 Client 라는 추가적인 모듈을 제공하고 있다.

이를 추가하면, 기본적으로 사용되던 form login 방식의 인증 흐름에 차이점이 생긴다.

UsernamePasswordAuthenticationFilter/Token, UserDetailsService, UserDetails가 사용되지 않고,

OAuth2 로그인을 위해 구현된 OAuth2LoginAuthenticationFilter, OAuth2AuthenticationProvider, OAuth2UserService, OAuth2User 인터페이스를 사용하여 인증이 진행된 후 Authentication 객체를 반환한다.

implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'

build.gradle 파일에 의존성을 추가해주었다.

카카오톡과 연동하기 위해, kakao developers에서 우리의 서비스를 등록해주었다.

security:
  oauth2:
    client:
      registration:
        kakao:
          client-id: 앱 키 > REST API 키
          client-secret: 카카오 로그인 > 보안 > Client Secret
          scope:
            - profile_nickname
          redirect-uri: "http://localhost:8080/login/oauth2/code/kakao"
          client-name: kakao
          authorization-grant-type: authorization_code
          client-authentication-method: client_secret_post
      provider:
        kakao:
          authorization-uri: https://kauth.kakao.com/oauth/authorize
          token-uri: https://kauth.kakao.com/oauth/token
          user-info-uri: https://kapi.kakao.com/v2/user/me
          user-name-attribute: id

이후, application.yml 파일에 OAuth2 클라이언트를 사용하기 위한 설정값들을 추가해 주었다.

어플리케이션을 실행하면 위와 같이 카카오톡 로그인 화면이 뜨고, 로그인을 하면 개인정보 이용 동의창이 뜨는 것을 확인할 수 있다.

스프링에서 oauth 설정이 이렇게 간단한지 처음 알았다..!

카카오 이외의 다른 서비스로 OAuth 기능 구현도 해보고 싶은 생각이 든다.

패스트캠퍼스 환급 챌린지 46일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Fri, 16 May 2025 23:37:25 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 46일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버의 로그인 기능 적용 작업을 진행하였다.

지난 시간에는 주소만 입력한다면 누구나 접속할 수 있는 채팅 기능을 만들었다면, 이번에는 채팅 기능에 Spring Security를 이용한 로그인 기능을 적용시켜 로그인한 사용자만 채팅창에 접근할 수 있도록 구현하였다.

Spring Security란 인증 및 인가를 위한 스프링의 하위 프레임워크이다.

서블릿(Servlet)은 클라이언트의 http 요청을 처리하고 동적으로 응답을 생성하는 자바 기반의 웹 프로그래밍 기술로, 웹 서버 상에서 동작하는 자바 클래스이다.

스프링부트에서는 기본적으로 Tomcat이라는 내장 웹 서버를 사용하며, 이는 서블릿 컨테이너 역할을 하여 우리가 작성한 웹 애플리케이션 코드를 실행하고 HTTP 요청을 처리한다.

서버로 들어온 HTTP 요청은 여러 개의 서블릿 필터를 거쳐서 서블릿에 도달하게 된다.

이러한 필터 계층 구조 중 하나로 스프링 시큐리티의 FilterChainProxy가 삽입되어 동작한다.

FilterChainProxy는 하나의 필터로 보이지만, 내부적으로 여러 개의 SecurityFilterChain을 관리한다. 개발자는 이 체인을 커스터마이징하여 인증, 인가, 세션 관리 등 보안 기능을 확장할 수 있다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-websocket'
    implementation 'org.springframework.boot:spring-boot-starter-security'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.security:spring-security-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

build.gradle 파일에 spring security 관련 의존성을 추가해 주었다.

어플리케이션을 실행시키고 localhost:8080으로 접속하니, index.html 화면이 바로 뜨는 것이 아니라 /login 경로의 로그인 화면으로 접속되는 것을 확인할 수 있다. 스프링 부트의 장점 중 하나인 auto configuration 덕분에 프로젝트의 classpath에 스프링 시큐리티가 있는 것을 확인하여 자동으로 기본 form login 기능이 적용된 것이다.

username에는 'user'를, password에는 프로젝트 콘솔에 출력되는 Using generated security password 값을 복사하여 붙여넣고 sign in 버튼을 누르면 로그인이 되어 기존의 채팅창으로 넘어가게 된다.

프로젝트를 진행하면서 스프링 시큐리티를 사용해 본 경험이 있다.

매번 느끼지만 스프링에서 제공하는 하위 프레임워크를 잘 활용하면 개발 생산성에 정말 큰 도움이 되는 것 같다.

패스트캠퍼스 환급 챌린지 45일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Thu, 15 May 2025 10:39:11 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

실습 화면

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 45일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버의 STOMP을 사용한 간단한 채팅 서비스 구현 작업을 진행하였다.

@Configuration
@EnableWebSocketMessageBroker // STOMP 기능 활성화
public class StompConfiguration implements WebSocketMessageBrokerConfigurer {

    // 클라이언트가 서버에 연결할 수 있도록 엔드포인트 지정
    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/stomp/chats");
    }

    // 메세지 브로커로서의 역할을 하기 위해서 클라이언트에서 메세지를 발행하고, 클라이언트는 브로커로부터 전달되는 메세지를 받기 위해 구독을 해야 한다.
    // 그 경로들을 지정해주는 기능
    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // 메세지 발행 경로 (클라이언트 -> 서버로 메세지 보낼 때 사용할 prefix)
        registry.setApplicationDestinationPrefixes("/pub");

        // 메세지 구독 신청 경로 (서버 -> 클라이언트로 메세지 보낼 때 사용할 prefix)
        registry.enableSimpleBroker("/sub");
    }

}

STOMP 사용을 위한 설정 파일을 생성하였다.

WebSocketMessageBrokerConfigurer 인터페이스를 구현하여 스톰프 기능을 설정할 수 있다.

registerStompEndpoits(), configureMessageBroker()를 오버라이드하여 구현하였다.

@Slf4j
@Controller
public class StompChatController {

    @MessageMapping("/chats") // 어떤 경로로 발행된 메세지를 라우팅할 것인지 지정 (설정 파일에서 설정한 prefix(/pub)는 생략)
    @SendTo("/sub/chats") // 해당 경로를 구독하고 있는 모든 클라이언트에 메세지 전달
    public String handleMessage(@Payload String message) {
        log.info("{} Received", message);

        return message;
    }

}

이후, 메세지 요청을 받는 컨트롤러를 생성했다.

@MessageMapping 어노테이션을 통해 /pub/chats 경로로 발행된 메세지를 받아와 처리하고, 구독 중인 클라이언트들에게 메세지를 전달한다.

어플리케이션을 실행하여 메세지를 보내면, 위 컨트롤러에서 작성한 포맷대로 log가 출력되는 것을 확인할 수 있다.

map 등의 자료구조에 직접 세션을 저장하고, 반복문을 수행하면서 메세지를 전송해야 했던 웹소켓과 달리 stomp는 경로 지정과 컨트롤러 구현만으로 메세지 전달이 가능해서 훨씬 빠르고 편리하게 개발을 할 수 있었다.

패스트캠퍼스 환급 챌린지 44일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Wed, 14 May 2025 01:26:40 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

프로젝트 생성 화면

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 44일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버의 프로젝트 생성, 웹소켓을 사용한 간단한 채팅 서비스 구현 작업을 진행하였다.

part4 강의에서는 채팅 상담 기능을 제공하는 백엔드 서비스를 만들 계획이다.

서버에 연결된 복수의 사용자들이 서로 메세지를 주고 받을 수 있는 간단한 채팅 기능을 WebSocket과 STOMP를 이용하여 각각 구현해보는 작업을 진행하기로 하였다. 먼저, 이번 강의에서는 웹소켓을 이용하여 개발을 진행하였다.

@Slf4j
@Component
public class WebSocketChatHandler extends TextWebSocketHandler {

	final Map<String, WebSocketSession> webSocketSessionMap = new ConcurrentHashMap<>();

	// 웹소켓 클라이언트가 서버로 연결을 한 이후에 실행되는 로직
    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        log.info("{} connected", session.getId());
        this.webSocketSessionMap.put(session.getId(), session);
    }

	// 웹소켓 클라이언트에서 메세지가 왔을 때 처리하는 로직
    @Override
    public void handleMessage(WebSocketSession session, WebSocketMessage<?> message) throws Exception {
        log.info("{} sent {}", session.getId(), message.getPayload());

        this.webSocketSessionMap.values().forEach(
                webSocketSession -> {
                    try {
                        webSocketSession.sendMessage(message);
                    } catch (IOException e) {
                        throw new RuntimeException(e);
                    }
                }
        );
    }

	// 서버에 접속해 있던 웹소켓 클라이언트가 연결을 끊었을 때 처리하는 로직
    @Override
    public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception {
        log.info("{} disconnected", session.getId());
        this.webSocketSessionMap.remove(session.getId());
    }

}

TextWebSocketHandler를 상속받고, 세 개의 메서드를 오버라이드하여 웹소켓 핸들러를 구현했다.

세션을 map 형태로 저장해둔 후, 연결된 모든 사용자에게 메세지를 전송하는 형식이다.

@RequiredArgsConstructor
@EnableWebSocket
@Configuration
public class WebSocketConfiguration implements WebSocketConfigurer {

    final WebSocketChatHandler webSocketChatHandler;

    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(webSocketChatHandler, "/ws/chats");
    }

}

Spring에 웹소켓 서버 설정을 하기 위해 WebSocketConfigurer 인터페이스를 구현한 설정 파일을 생성하였다.

웹소켓 요청이 "/ws/chats" 경로로 들어오면 WebSocketHandler가 처리하도록 등록했다.

다른 브라우저에서 localhost에 접속한 후, 각각 connect하고 메세지를 send하면 두 개의 창에서 실시간으로 전송된 메세지가 출력되는 것을 확인할 수 있다!

웹소켓만 가지고 정말 간단한 채팅 기능을 구현해 보았다.

너무 신기하다! 다음 강의에서 STOMP로 구현할 때는 어떤 차이가 있을지 궁금하다.

패스트캠퍼스 환급 챌린지 43일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Tue, 13 May 2025 15:52:00 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 43일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버 개발 강의의 웹소켓 이론에 대한 학습을 진행하였다.

Spring Framework의 WebSocket 지원

1. Web Socket API

: 웹소켓 메세지를 다룰 수 있는 api 제공

- WebSocketHandler: 이진 데이터 또는 텍스트 데이터를 다루기 위한 바이너르 웹소켓 핸들러 또는 텍스트 웹소켓 핸들러를 상속받아 구현하는 것만으로 간단한 웹소켓 서버를 만들 수 있다.

- WebSocket Handshake: 웹소켓의 http 핸드쉐이크를 커스터마이징할 수 있는 핸드쉐이크 인터셉터를 제공. 핸드쉐이크 인터페이스의 beforeHandshake, afterHandshake 메소드를 제공하는데, 이를 구현함으로써 핸드쉐이크 과정 중에 일어나는 인증, 서브 프로토콜 협상 등의 부가적인 작업들을 제어할 수 있다.

- 웹소켓 서버 설정을 자바코드로 제어할 수 있는 기능을 제공한다. 이를 통해 웹소켓의 메세지 버퍼 사이즈, 타임아웃과 같은 설정을 제어할 수 있다.

2. SockJS Fallback

: 웹소켓이 정상적으로 작동하지 않는 환경을 위한 SockJS 프로토콜 지원

- 브라우저상의 SockJS 클라이언트가 웹소켓, 스트리밍, 롱폴링 등의 통신 방법 중에서 적절한 방식을 선택하기 위해서는, 서버로 요청을 보내서 세션/쿠키의 사용 여부 등 여러가지 기본적인 정보들을 받아야 한다. 또한, 프록시에서 연결이 끊기는 것을 방지하기 위해서 서버에서는 프록시로 heartbeat 요청을 지속적으로 보내줘야 한다. 이렇게 SockJS가 작동하기 위한 서버 사이드의 역할들에 대한 지원을 해주는 기능을 한다.

3. STOMP

: STOMP 브로커 기능을 제공

- 웹소켓을 직접 사용하는 것보다 더 풍부한 기능을 제공한다. (메세지 포맷 정의 / 파싱 로직 구현 불필요, 하나의 웹소켓 핸들러에서 처리하던 것을 다수의 컨트롤러에서 처리 가능(@MessageMapping), Spring Security 이용 가능 등)

- @Configuration, @EnableWebSocketMessageBroker 어노테이션을 선언하고, WebSocketMessageBrokerConfigurer 인터페이스를 구현하면 된다.

저번 강의에서 웹소켓에 대한 개념만 학습했을 때는 너무 복잡해 보여서 이걸 어떻게 구현할 수 있을지 상상이 되지 않았는데, 스프링상에서 제공하는 웹소켓 관련 기능이 굉장히 많은 것을 알게 되어 다행이다~

패스트캠퍼스 환급 챌린지 42일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Mon, 12 May 2025 23:01:06 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 42일차!
오늘은 Websocket을 활용한 실시간 메시징 도메인 서버 개발 강의의 웹소켓 이론에 대한 학습을 진행하였다.

(새롭게 시작할 토이 프로젝트에서 웹소켓을 사용하게 될 것 같아서 갑작스럽게 수강하는 강의를 바꾸게 되었다.

기존에 수강 중이던 redis 강의는 추후에 꼭 완강하도록 해야겠다,, )

웹소켓

: TCP 기반의 연결을 통해 실시간 양방향 통신을 가능하게 해주는 통신 프로토콜

하나의 커넥션을 이용하여 실시간으로 효율적인 양방향 통신이 가능하다는 장점이 있다. (전이중 통신)

하지만 비교적 최신 기술이기 때문에 브라우저의 호환성이 떨어지고, stateful한 특징에 맞춰 연결의 상태에 따른 여러가지 상황들을 구현시 신경써야 하는 단점이 있다.

웹소켓은 실시간성이 중요한 채팅, 인터넷 게임, 주식거래 사이트, 협업 툴 등의 서비스에 주로 사용된다.

웹소켓과 http의 비교

- http는 서버로부터 데이터를 받기 위해서 반드시 클라이언트의 요청이 있어야 한다.

한 번의 요청과 응답을 주고 받기 위해서는 3-way handshake 과정을 거쳐야 하기 때문에, 이로 인한 오버헤드가 발생할 수 있다.

- 서버와 연결을 맺기 위한 최초의 handshake 과정 이후에는 클라이언트와 서버가 각자 원하는 시점에 원하는 데이터를 보낼 수 있다. 그렇기에, handshake로 인한 불필요한 오버헤드가 발생하지 않는다.

웹소켓 이전의 실시간 통신 방식

- Polling

: 서버로부터 원하는 데이터를 얻어오기 위해 일정한 간격으로 서버에 계속 요청을 보내는 방법

서버에 변경사항이 없는 경우에도 계속해서 요청을 보내는 상황이 발생할 수 있기 때문에 불필요한 트래픽 낭비가 많이 생긴다.

- Long Polling

: 한번의 요청을 보내고 서버에서 보내줄 데이터가 없다면, 그 데이터를 보낼 수 있는 상황이 될 때까지 연결을 끊지 않고 유지하는 방식

해당 요청에 대해 응답을 받으면, 클라이언트에서는 해당 데이터를 처리한 후에 바로 다시 서버로 요청을 보내서 다음 데이터를 대기한다.

폴링 방식보다는 불필요한 트래픽이 줄어들지만, 많은 요청을 보내야 하는 문제는 해결되지 않는다.

- 스트리밍

: 클라이언트에서 서버로 요청을 보내고 나면, 이에 대한 연결을 끊지 않은 상태로 서버에서 데이터를 보낼 수 있을 때마다 몇 번이고 응답을 내려주는 방식

빈번한 요청이라는 문제는 해결할 수 있지만, 클라이언트에서 서버로 데이터를 전송할 수 없다는 문제가 있다.

웹소켓은 하나의 연결을 이용해서 양방향 통신이 가능하기에 위의 문제들을 해결할 수 있다.

웹소켓 핸드쉐이크

: 최초의 요청은 http 프로토콜을 이용하여 이루어진다. get 메서드를 이용해 웹소켓 프로토콜로의 업그레이드 요청을 보냄.

서버에서는 이에 대한 응답으로 200(일반적인 성공에 대한 응답)이 아닌, 100을 내려준다.

위 과정 이후부터는 웹소켓 프로토콜을 이용하여 서버와 연결을 맺고 데이터를 주고 받을 수 있게 된다.

웹소켓 프로토콜에서 사용하는 가장 작은 데이터 단위인 'Frame' 형식을 사용한다.

웹소켓 프로토콜상의 데이터 전송은 일련의 프레임을 사용한다.

프레임은 비트 단위로 세부적인 구조를 가지고 있으며, 크기 헤더와 페이로드로 구분된다.

0번 비트	FIN	메시지의 마지막 프레임 여부 (1이면 마지막)
1~3번 비트	RSV1~RSV3	웹소켓 확장용 필드. 특별한 확장 없으면 기본값은 0
4~7번 비트	Opcode	전송 데이터의 종류 (예: 텍스트, 바이너리 등)
8번 비트	Mask	마스킹 여부. 클라이언트 → 서버 전송 시 항상 1
9~15번 비트	Payload Length	페이로드 데이터 길이 표현

- 0 ~ 125: 최초의 7비트를 이용해 직접 길이 표현

- 126: 최초의 7비트를 126으로 고정, 그 이후에 2 바이트를 사용하여 16비트 unsigned int로 길이 표현

- 127: 최초의 7비트를 127으로 고정, 그 이후에 8바이트를 사용하여 64비트 unsigned int로 길이 표현

이후, mask 비트가 1일 경우에는 길이 필드 뒤에 4바이트 마스킹 키가 추가되고, 그 뒤에 실제 페이로드 데이터가 전송된다.

웹소켓 프로토콜은 어플리케이션 레벨의 프로토콜이 아니기 때문에 주고받는 메세지 성격에 대한 충분한 정보가 없기 때문에 프레임워크나 컨테이너가 메세지를 어떻게 처리해야 할지 알 수가 없다. 그렇기 때문에 웹소켓 프로토콜을 위해 작동하는 서브 프로토콜 중 하나인 stomp를 사용한다.

stomp는 클라이언트와 서버가 전송할 메세지의 유형, 형식, 내용 등을 정의한다.

전에 웹소켓을 이용한 프로젝트를 진행하려다가 사전 지식의 벽에 가로막혀 도전하지 못했던 기억이 난다.

아직 정확히 이해가 되지 않는 부분도 있지만, 네트워크 공부를 병행하면서 진행하면 될 것 같다!

http 이외의 프로토콜을 사용하는 것은 처음이라 기대된다.

패스트캠퍼스 환급 챌린지 41일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Sun, 11 May 2025 23:07:06 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 41일차!
오늘은 동영상 컨텐츠 서비스 개발 강의의 프로젝트 구조 및 필요한 기술과 의존성에 대한 학습을 진행하였다.

도메인 로직을 중심에 두고, 외부 의존성을 입출력 포트와 어댑터로 분리하는 헥사고날 아키텍처로 설계하였다.

외부 요청(API 등)이 어댑터(컨트롤러)를 통해 들어오고, 이 어댑터는 애플리케이션 계층의 유즈케이스를 실행한다. 유즈케이스는 도메인 모델과 협력하며 필요한 작업을 처리하고, 데이터 저장이나 외부 API 호출이 필요한 경우에는 아웃포트 인터페이스를 통해 퍼시스턴스 어댑터(JPA, Redis, Kafka 등)를 호출한다.

프로세스 흐름

Redis에 먼저 요청을 보내어 데이터가 있으면 바로 반환하고, 캐시에 저장된 데이터가 없는 경우에는 RDBMS에서 조회하여 Redis에 저장을 시킨 후에 반환이 되도록 한다.

cache hit / miss에 대한 처리는 Spring에서 제공하는 Spring Cache를 이용하면 편리하게 구현할 수 있다.

이번 강의에서는 수동으로 캐시 처리를 구현하는 것과 스프링을 이용하는 것 두 가지 방법을 모두 사용할 예정이다.

주요 기술

Spring + Redis (SpringDataRedis를 구현하여 사용)

- RedisTempate

: Redis Operation에 대응되는 method 제공

- RedisRepository

: Spring Data에서 제공하는 interface로 접근

- @RedisHash

: Spring Data에서 사용하는 Redis에 hash로 저장될 데이터 (JPA의 Entity와 비슷한 개념)

필요한 의존성

- web

- jpa

- redis

- mongodb

- mysql

- (test) test

- (test) h2

- (test) mongodb

- (test) redis

그동안 항상 급하게 시작해서 그런지(ㅎㅎ;;) 프로젝트를 시작하기 전에 이렇게 자세하게 기술과 의존성에 대해 알아보는 건 처음이다.

간단하게나마 배경지식을 깔고 시작하는 것이 좋은 것 같다.

패스트캠퍼스 환급 챌린지 40일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Sat, 10 May 2025 23:17:49 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 40일차!
오늘은 동영상 컨텐츠 서비스 개발 강의의 커리큘럼 설명 및 개발 요구 사항 분석에 대한 학습을 진행하였다.

동영상 컨텐츠 서비스 구성

컨텐츠 서비스 (웹툰, 웹소설, 음악, 비디오 서비스 등)

ㄴ 동영상 컨텐츠 서비스

ㄴ 동영상 정보 (제목, 설명, 업로드 일자, url, 썸네일, 영상 길이 등)

ㄴ 사용자 액션 (구독(채널 단위), 좋아요(비디오 단위), 댓글(비디오 단위))

ㄴ 동영상 전송 (CDN)

컨텐츠 서비스와 커뮤니티 서비스의 비교

	컨텐츠 생성	컨텐츠 조회	목록 기준	시간이 지난 컨텐츠 조회
컨텐츠 서비스	적음	생성되는 컨텐츠 대비 많음	연관성, 랜덤	장기간 지속됨
커뮤니티 서비스	많음	생성되는 컨텐츠 대비 적음	시간순	조회가 집중되는 시기가 짧음

Redis와 RDBMS의 비교

	데이터 저장소	데이터 저장 방식	장점	단점
Redis	Memory	Key-Value	빠른 조회 속도, 다양한 데이터 구조	비싼 메모리 가격, 휘발성
RDBMS	Disk	SQL	무결성, 복잡한 관계 처리	고정된 스키마, 확장의 어려움

Redis는 메모리에 저장되기 때문에 조회 속도가 빠르지만 비용이 많이 지불된다.

Key-Value 타입으로 저장되는데, value의 타입이 기본적인 타입 외에도 Hash, List, Set 등 다양하게 제공된다.

하지만 데이터 간의 연관관계를 맺는 것에는 어려움이 있다.

Redis와 RDBMS의 장점을 활용하여 RDBMS에서 조회에 시간이 많이 소요되는 데이터를 Redis가 중간에 가지고 있다가 빠르게 반환해주는 캐시 방식으로 사용할 수 있다.

Chche (캐시)

- 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 저장소

캐시를 사용하면 또 다른 인프라가 추가되는 것이기 때문에 인프라에 대한 관리 비용이 추가되게 된다.

또한 캐시가 셧다운된 경우 복구 비용과 대체 시스템 구축, 셧다운 시에 DB로 몰리는 요청을 감당하게 되는 등 비용적인 문제가 커지게 된다.

이러한 비용을 감수하면서도 캐시 사용을 고려해야 하는 상황은 다음과 같다.

- 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래 걸리는 경우

- 반복적으로 동일한 결과를 돌려주는 경우

생성은 적지만 조회는 많고, 변경이 잘 일어나지 않고, 내부적인 계산을 반복할 필요가 없는 컨텐츠 서비스의 특성상 캐시를 사용하면 이득을 볼 수 있게 된다.

전의 커뮤니티 서비스 강의 수강을 모두 끝내고, 이번에는 동영상 컨텐츠 서비스 강의 수강을 시작하게 되었다.

늘 RDBMS만 사용해보고 Redis 같은 NoSQL은 처음 사용해보는 거여서 굉장히 기대가 된다!

패스트캠퍼스 환급 챌린지 39일차 : 9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online 강의 후기

ssoonearth — Fri, 9 May 2025 10:20:59 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://abit.ly/lisbva

패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 39일차!
오늘은 커뮤니티 피드 서비스의 알림 기능 구현 작업을 진행하였다.

@Repository
@RequiredArgsConstructor
public class FcmMessageRepositoryImpl implements MessageRepository {

    private final JpaFcmTokenRepository jpaFcmTokenRepository;

    private static final String LIKE_MESSAGE_TEMPLATE = "%s님이 %s님의 글에 좋아요를 눌렀습니다.";
    private static final String MESSAGE_KEY = "message";

    @Override
    public void sendLikeMessage(User sender, User targerUser) {
        Optional<FcmTokenEntity> tokenEntity = jpaFcmTokenRepository.findById(targerUser.getId());
        if (tokenEntity.isEmpty()) {
            return;
        }

        FcmTokenEntity token = tokenEntity.get();
        Message message = Message.builder()
                .putData(MESSAGE_KEY, LIKE_MESSAGE_TEMPLATE.formatted(sender.getName(), targerUser.getName()))
                .setToken(token.getFcmToken())
                .build();
        FirebaseMessaging.getInstance().sendAsync(message);
    }

}

저장되어 있는 토큰 정보를 타켓 유저에 맞게 불러와주고, 그 값이 없다면 그냥 발송하지 않게 된다.

유저가 푸시 토큰을 받을 토큰이 저장되어있다면 파이어베이스에서 제공하는 메세지를 만들어서 비동기로 전달해준다.

@Override
@Transactional
public UserAuth loginUser(String email, String password, String fcmToken) {
    UserAuthEntity userAuthEntity = jpaUserAuthRepository.findById(email).orElseThrow();
    UserAuth userAuth = userAuthEntity.toUserAuth();

    if (!userAuth.matchPassword(password)) {
        throw new IllegalArgumentException("옳지 않은 비밀번호입니다.");
    }

    userAuthEntity.updateLastLoginAt();
    jpaFcmTokenRepository.save(new FcmTokenEntity(userAuth.getUserId(), fcmToken));
    return userAuth;
}

이전에 구현했던 로그인 로직에 fcmToken을 파라미터로 추가하고, jpaFcmTokenRepository를 통해 저장하여 로그인할 때 토큰값도 같이 저장되게 하였다.

@Override
@Transactional
public void like(Post post, User user) {
    LikeEntity likeEntity = new LikeEntity(post, user);
    entityManager.persist(likeEntity);
    jpaLikeRepository.save(likeEntity);
    jpaPostRepository.updateLikeCount(post.getId(), 1);
    messageRepository.sendLikeMessage(user, post.getAuthor());
}

기존의 like 로직에 messageRepository를 추가하여, 좋아요를 누를 때 저장되어 있는 토큰 기반으로 메세지가 전달되게 하였다.

어플리케이션을 실행시켜 user1과 user2 계정으로 로그인하여 fcmToken값을 저장시킨 후, postman에서 like 요청을 보내면 크롬에서 알림이 뜨는 것과 개발자 도구에서도 메세지 정보가 뜨는 것을 확인할 수 있다.

이렇게 커뮤니티 피드 서비스 강의가 모두 마무리되었다.

40일에 가까운 시간 동안 매일 해오던 것이 끝나서인지 뭔가 아쉽다ㅠㅠ

이번 part1, part2 강의를 들으며 객체지향적인 설계부터 jwt, 쿼리 튜닝, firebase 활용 등 많은 것을 배울 수 있었다.

특히, 내가 어려워했던 테스트 코드 기반의 클린 아키텍처의 중요성과 본질 및 활용법 등에 대해 정말 많이 배운 것 같아 기쁘고 뿌듯하다.

백엔드 개발자로서 갖추어야 할 기본적이지만 그만큼 중요한 것들에 대한 내용이 알차게 담겨있어서 매우 만족스럽게 수강할 수 있었다!

좋은 강의 만들어주신 강사님께도 감사한 마음을 전합니다.. ‍♀️