sowon02 님의 블로그

호스팅이란? 호스팅(Hosting)은 웹사이트나 서비스를 인터넷에 실제로 공개하기 위해 서버 공간을 빌리는 것을 의미한다.개발자가 만든 웹사이트, API, 앱 백엔드 등은 로컬 컴퓨터에서는 잘 작동하더라도,전 세계 사용자들이 접속하려면 인터넷에 연결된 서버가 반드시 필요하다. 이 서버 공간을 제공해주는 서비스가 바로 호스팅(Hosting)이다. 등장 배경초기의 웹 서비스는 단순했다.정적 HTML 파일 몇 개만 있으면 되었고, 개인 PC나 간단한 서버에서도 충분히 제공할 수 있었다.하지만 웹이 발전하면서 다음과 같은 요구가 생겼다.서비스를 24시간 운영해야 함많은 사용자가 동시에 접속할 수 있어야 함갑작스러운 트래픽 증가도 감당할 수 있어야 함보안 패치, 백업, 장애 복구가 필요해짐이처럼 웹 서비스가로그..

13일차까지 WebSocket, FullCalendar, 실시간 동기화까지 꾸준히 올렸는데그 이후로 블로그에는 업데이트를 못 올리고 있었다.그동안 개발은 계속 진행 됐고, 20일차 까지는 자동 스케줄링 엔진의 기본 구조, 그리디 배치, 점수 모델, 시간 슬롯 분할 / 연속 배치, 진행률 브로드캐스트까지는 전부 완성했다. ( + AWS EC2 배포까지 함 : http://54.206.65.33:8080 ) 21일차 기준으로는 : 캘린더 자동 업데이트 연동 완료ScheduleGenerateResponse → FullCalendar 형식 반환프런트에서 생성된 스케줄이 바로 UI에 반영됨점수 시각화는 일부만 완료백엔드: schedule.setScore() 까지 구현프런트: 점수 표시 UI 아직 없음즉, 엔진..

오늘은 프로젝트에서 구현해둔WebSocket/STOMP 기능을 테스트하는 과정에서 여러 가지 예상치 못한 오류들이 발생하여,해당 문제들을 문제 상황 → 원인 분석 → 해결 과정 순서로 정리하였습니다. 이번 오류는 단순한 코드 문제가 아니라, 보안 설정, CORS, SockJS 정책, Handshake 옵션들이 서로 충돌하면서 발생한 케이스였고, 특히 Spring Boot 3.x 환경에서 자주 발생할 수 있는 유형이었습니다.아래는 실제로 테스트 중 발생했던 에러들입니다.WebSocket connection to 'ws://:8080/ws/websocket' failedPOST /ws/... xhr_streaming?... 500 (Internal Server Error)GET /ws/iframe.html ..

오늘은 FullCalendar.js를 기반으로일정을 드래그해서 수정할 수 있도록 UX를 개선했다.기존에는 일정 수정 시 폼에 직접 입력해야 했지만,이제는 드래그 & 리사이즈로 직관적으로 일정/시간을 변경할 수 있다.수정 이유 사용자 UX 개선직접 폼에 날짜·시간을 입력하는 건 번거롭고 느렸다.드래그로 바로 옮기거나 리사이즈로 시간을 늘릴 수 있다면훨씬 빠르고 직관적인 사용자 경험을 제공할 수 있다.실시간 협업 환경 개선여러 사용자가 같은 캘린더를 볼 때,한 사용자의 변경이 즉시 다른 사용자에게 반영되어야 한다.WebSocket(STOMP)을 활용해 실시간으로 동기화시켰다.비즈니스 가치일정 관리 효율 향상 → 팀 협업 생산성 향상 → 사용자 만족도 향상전체 흐름[ 사용자 드래그 ] ↓ [ 프론트엔드..

AutoSchedule 프로젝트는 실시간 협업 기능이 핵심이다.캘린더 수정이나 작업 생성, 충돌 알림 등 모든 상호작용이 다른 사용자 화면에 즉시 반영되어야 한다.그런데 기존에는 WebSocket이 실제로 잘 작동하는지 확인할 방법이 없다는 문제가 있었다. JWT 인증 실패Rate Limit 초과Origin 검증 실패토큰 만료네트워크 끊김서버 재시작 중 연결 해제이런 문제들이 발생해도 브라우저 콘솔에 로그만 찍힐 뿐,실제로 클라이언트가 정상적으로 구독·수신을 하고 있는지 눈으로 확인하기 어려운 구조였다. 코드를 보면 실제로 아래와 같은 위험 요소가 있었다 : 구독 실패 시 조용히 실패메시지가 전송/수신됐는지 확인 불가여러 토픽 구독 시 중복 메시지 위험예외 상황에 대한 대응 부족이런 문제들을 해결하기 ..

오늘은 동시에 같은 슬롯을 두번 건드리는 일을 막기 위해 TTL 기반 슬롯 락 인프라를 구현했다.락 획득 / 연장 / 해제 / 로직과 만료 청소 스케줄러를 붙였고,Mockito 기반으로 서비스 로직을 단위 테스트해보았다. TTL 기반 락을 선택한 이유TTL(Time-To-Live)이란 ?락이 자동으로 해제되는 시각을 함께 저장해 두고, 그 시간이 지나면 다른 주체가 락을 가져갈 수 있게 하는 방식이다.예를 들어 tryLock("slot-1", userId, Duration.ofSeconds(30))은 30초 후 자동 만료되어 타 사용자가 재획득 가능하다는 뜻. 다른 방식들과 비교1) DB 플래그 방식(수동 해제)단순히 locked = true / false 만 관리하는 방식이다. UPDATE slot S..

프로젝트를 진행하면서 DB 스키마 버전을 관리하기 위해 Flyway를 사용하고 있습니다.이번에는 단순한 실수로 인해 애플리케이션이 기동되지 않는 오류를 경험했습니다.Flyway란Flyway는 DB 마이그레이션 도구로,V1__init.sql, V2__add_table.sql처럼 버전을 붙인 SQL 파일을 순서대로 실행하여 데이터베이스 스키마를 관리합니다. 한 번 실행된 마이그레이션 파일은 그 내용의 해시(체크섬) 을 DB 내부의 flyway_schema_history 테이블에 저장해둡니다.이후 애플리케이션을 다시 실행할 때 파일 내용이 이전과 달라지면 (주석, 띄어쓰기, 줄바꿈까지 포함)체크섬 불일치(Migration checksum mismatch) 로 간주하고 실행을 중단합니다.증상이미 배포되어 적용된..

어제는 WebSocket/STOMP 기반의 실시간 협업 인프라를 구축했다.오늘은 그 연장선으로, AI 스케줄 최적화 결과를 실시간으로 브로드캐스트하는 기능을 구현했다.기존 구조에서는 진행률만 실시간으로 전송되고, 최종 스케줄 결과는 프론트가 별도로 REST API를 호출해야 했다.이 방식의 문제는 다음과 같았다.AI 최적화 완료 시점을 프론트가 알 수 없음API 응답 타이밍 차이로 화면이 늦게 갱신됨다른 도메인(Task, Calendar, Notification)과의 실시간 흐름이 불일치결국 “진행률은 실시간인데 결과는 수동 갱신”이라는 어색한 구조가 됐다. 그래서 오늘은 최종 스케줄까지 자동으로 push하는 브로드캐스터 로직을 추가했다.1. 기존 구조기존 ScheduleOptimizationServic..

프로젝트를 진행하면서 WebSocket을 추가하고, 실시간 협업 기능을 위해 보안 로직(STOMP 인증, Origin 검증 등)을 강화하였습니다. 이때 Spring Messaging 기능을 사용하기 위해 spring-boot-starter-websocket 의존성을 추가하였습니다.그런데 프로젝트에서 계속해서 SimpMessagingTemplate 클래스를 인식하지 못하는 문제가 발생했습니다.의존성은 분명히 추가되어 있었고, Gradle refresh, IDE 재시작 등 모든 기본적인 조치를 취했음에도 에러가 사라지지 않았습니다.증상 import org.springframework.messaging.SimpMessagingTemplate; 에서“cannot be resolved” 에러 발생SimpMessa..

어제는 실시간 일정 편집, 자동 스케줄 배포, 협업 알림을 위해 WebSocket을 구현했다.오늘은 이 WebSocket 통신의 보안성과 안정성을 높이기 위해, 세 가지 단계의 보안 인터셉터를 추가했다.핸드셰이크 → 인증 → 트래픽 제어까지, STOMP 전 구간을 검증하는 구조다.1. StrictHandshakeInterceptor – Origin / TLS 검사WebSocket 연결 직전에 실행되는 핸드셰이크 인터셉터로, 다음 두 가지를 검사한다.허용 Origin 확인: 외부 도메인의 비정상 요청 차단TLS 강제 여부 검사: 배포 환경에서는 wss:// 만 허용이 값들은 모두 application.properties 의 app.websocket.allowed-origins, app.websocket.r..