처음으로 참석하게 된 스프링 캠프 컨퍼런스.2023년, 2024년에 탈락으로 가고 싶어도 가지 못했지만, 2025년에는 운이 좋게 참석했다.주말 오전 삼성역에서 진행하는 컨퍼런스라 일찍이 광역 버스에 탑승했다. 1. 컨퍼런스 진행 방식(1) 세션 진행 방식이번 컨퍼런스는 동 시간에 두 세션을 동시에 진행하는 방식이었다.(사실 이번에 처음 와봐서 잘 모르겠다.) 오후 2시에 진행하는 MSA 와 트랜잭션 개발 가이드, Virtual Thread 세션 모두 듣고 싶었지만,Virtual Thread 세션은 3개월 뒤에 업로드 되는 유튜브 영상으로 대체하기로 했다. 딱 하루만 운영하는 컨퍼런스여서 불가피하게 선택과 집중을 해야 하는 구조가 되었는지 아닌가 싶다. (2) 굿즈이번 컨퍼런스에서는 입장 팔찌와 함께..

1. MCP(Model Context Protocol)??MCP (Model Context Protocol) 는 AI 에이전트와 다양한 시스템에 연결하는 USB-C 포트와 같은 오픈소스 표준 프로토콜이다. (참고로 Antropic(엔트로픽) 에서 처음 도입하였다.) 그렇다면 표준화를 하는 이유는 무엇일까? 표준화란 모두가 똑같이 따라야 하는 규칙이나 방식을 정의하는 행위를 의미한다.통신 규약을 정의함으로써 서로 다른 시스템이라도 같은 표준을 따르면 다른 시스템으로 변경하기 용이하다.즉, 호환성을 향상시킬 수 있다. 또한 이미 정해진 규칙에 따라 작업할 수 있어 시간과 비용을 절약하기 때문에 효율성과 생산성을 증가할 수 있다. MCP 에 대입해서 정리하자면 AI 모델과 도구 사이를 MCP 로 표준화하여다양..

2025년 11월에 예정된 Spring Framework 7.0 릴리즈 노트에 관한 간단한 정리 및 번역 글.https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.0-Release-Notes Upgrading From Spring Framework 6.21. 주요 의존성 및 요구사항 변경최소 요구사항 상향JDK 17을 기본으로 유지하면서 JDK 25 LTS 권장Jakarta EE 11 기준선 도입Kotlin 2.2 및 GraalVM 24 지원구체적인 라이브러리 버전 업데이트:Servlet 6.1 (Tomcat 11.0, Jetty 12.1)JPA 3.2 (Hibernate ORM 7.1)Bean Validation 3.1 ..

ALB 는 OS 7계층 중에 application layer 에서 동작하는 컴포넌트로 URI, 헤더, 쿠키 기반의 라우팅을 지원한다. AWS ALB 는 Target Group 과 연동된 EC2, ECS, lambda 등의 Auto Scaling 에 따라 자동으로 추가/제거되어도 자동으로 로드 밸런싱 적용이 가능하다. 로드 밸런싱 기법로드 밸런싱은 라운드 로빈, 최소 연결, 해시 기반으로 동작한다. 라운드 로빈은 요청을 순서대로 서버에 분배하는 방식이다. 별도의 설정이 없을 경우 가장 기본적으로 동작한다. 간단하지만 서버 성능 차이를 고려하지 않은 방식이므로 가중 라운드 로빈을 통해 서버마다 가중치를 부여해 로드 밸런싱을 하는 방식도 존재한다. 최소 연결 방식은 현재 연결 수가 가장 적은 서버에 분배하는 ..

S3 정적 호스팅으로 임시로 서버 구성을 했지만 이 방법은 AWS 에서 HTTPS 을 지원하지 않는다.HTTPS 을 지원하고 응답속도 개선을 위해 CloudFront + S3 + Route53 을 적용 과정에 관한 이야기이다. CloudFront ? CloudFront 는 AWS 에서 제공하는 CDN(Content Delivery Network) 서비스이다. CloudFront 는 정적 파일을 분산된 엣지 서버에 배치 및 캐싱하여 정적 컨텐츠를 빠르게 전송 가능한 서비스이다. 가장 가까운 엣지 서버에서 제공하기 때문에 응답 속도를 향상시켜 레이턴시(latency) 를 줄일 수 있다. 응답 속도 비교해보자. CloudFront 를 적용했을 때 S3 정적 호스팅을 했을 때보다 9배 가량 응답 시간이 차이가..

기존 MVP 모델에서 실시간 알림을 위해 폴링 기반으로 메시지 알림을 구현했다. 20초 주기로 폴링(polling) 설정하여 알림 메시지 갯수를 전달하는 방식이었고,AWS 프리티어 기반 최소 스펙으로 서버를 구성하고 있어 비용과 부하를 최소화하기 접근 방식이었다. 하지만 알림 기능의 최소한의 실시간성을 보장하지 못하는 피드백이 있어 다른 접근 방법이 필요했다. 최소한의 실시간성을 보장하기 위해 짧은 폴링 주기도 검토했지만,낮은 스펙의 서버 환경에서 부하를 다시 증가하는 문제가 있어 해당 방법은 적합하지 않아 다른 접근 방식이 필요했다. 그래서 대안 중 하나로 SSE(server-sent-event) 를 검토한 과정과 이를 적용하는 과정에 적어보고자 한다. 1. 실시간성을 위한 선택: WebSocket ..