승붕

🚀 [성능 최적화] 수강신청 시스템 부하 테스트: 비관적 락 vs 분산 락안녕하세요! 오늘은 k6를 활용해 수강신청 시스템의 API 성능을 측정하고, 동시성 제어 방식에 따른 성능 변화를 분석한 과정을 특히 강좌 목록 페이징 조회와 동일 강좌에 대한 동시 신청 상황을 집중적으로 테스트해 보았습니다. 1. 테스트 환경 및 시나리오이번 테스트는 실제 사용자가 몰리는 상황을 가정하여 5단계의 Stepping Load Test를 진행했습니다.VUs (Virtual Users): 최대 100명테스트 기간: 약 3분 30초주요 API:GET /api/courses: 강좌 목록 조회 (페이징)POST /api/enrollments: 수강 신청 (동시성 제어 적용) 2. 강좌 목록 조회 테스트 결과먼저, 가장 빈번하..

https://yeopseung.tistory.com/282 무신사 2차 코딩테스트 -2https://yeopseung.tistory.com/281 무신사 2차 코딩테스트 -12월 8일 일요일 오후 3시, 대망의 2차 코딩테스트가 시작되었습니다. 그리고 2월 13일 오후 5시 31분, 다행히 합격 메일을 받을 수 있었습니다.이yeopseung.tistory.com제 코드에 보이는 부분은 Index를 걸었던 부분입니다.why? - 교수별 강의 목록 조회, 학과별 강의 목록 조회가 빈번할 가능성이 매우 높기 떄문에 인덱스를 걸어야한다고 생각했습니다. prompt 는 ? 저의 프롬프트에서는 비관적 락 걸어야할 부분들을 미리 생각하고 넣었는데 수강 신청시 정원 초과 방지를 위한 비관적락을 걸고 싶은데 지금 문제..

https://yeopseung.tistory.com/281 무신사 2차 코딩테스트 -12월 8일 일요일 오후 3시, 대망의 2차 코딩테스트가 시작되었습니다. 그리고 2월 13일 오후 5시 31분, 다행히 합격 메일을 받을 수 있었습니다.이번 무신사 2차 테스트는 'AI 네이티브' 전형이라는 꽤yeopseung.tistory.com 2편에 이어서 여러가지를 한번에 구현하면 질이 떨어지기 떄문에 Global Exception -> Student (JWT Cookie Login Logout) -> Course -> Professor 순서로 구현을 시작했습니다. ① 아키텍처 설계AI 도구를 사용하지만, 코드의 전체적인 구조까지 AI에게 맡길 수는 없었습니다. 프롬프트를 입력하기 전, 패키지 구조와 도메인 ..

2월 8일 일요일 오후 3시, 대망의 2차 코딩테스트가 시작되었습니다. 그리고 2월 13일 오후 5시 31분, 다행히 합격 메일을 받을 수 있었습니다.이번 무신사 2차 테스트는 'AI 네이티브' 전형이라는 꽤 파격적이었습니다. 보통은 금지되는 AI 도구를 마음껏 사용할 수 있었고, 심지어 무신사 측에서 코덱스 사용 권한을 주기도 했습니다. 시험은 깃허브를 통해 문제를 확인하고, 개인 비공개 저장소에 코드를 올리는 방식으로 진행되었습니다. https://github.com/musinsatech/2026-musinsa-rookie GitHub - musinsatech/2026-musinsa-rookie: 2026 무신사 AI Native 개발자 채용 2차 시험 안내2026 무신사 AI Native 개발자..

Rookie AI Native Engineer 1차 코딩테스트 회고: "No AI, Only Human"안녕하세요 최근 무신사 ROOKIE AI Native Engineer 전형에 도전하며 치렀던 1차 코딩테스트 후기를 남겨보려 합니다.이번 테스트는 단순히 '알고리즘을 잘 푸는가'를 넘어, 무신사가 추구하는 '기술의 본질'을 묻는 느낌이 강했습니다"No AI, Only Human"지원 안내 메일에서 가장 인상 깊었던 문구는 이것이었습니다. 이번 테스트는 단순히 '코드를 잘 짜는가'를 넘어, 무신사가 추구하는 본질'을 기술로 어떻게 구현할지를 묻는 느낌이었습니다.AI가 코드를 짜주는 시대라지만, 그 코드가 '맞는지 틀린지' 검증하고, 비즈니스 로직에 맞게 수정하는 것은 결국 사람이 할것이고, 기초 체력이..

🔹 배치 처리(Batch Processing)란? 배치 처리는 대량의 데이터를 정해진 시간에 일괄적으로 처리하는 방식입니다. 🔧 일반적인 특징 항목설명💾 처리 방식실시간 처리(X), 일괄 처리(O)🕒 실행 시점주로 정해진 시간에 스케줄러를 통해 실행📁 사용 목적대량 데이터 처리, 통계 집계, 리포트 생성, 마이그레이션 등💥 실패 처리중간 실패 시 재시도 가능하게 설계 🧱 Spring Batch란? Spring Batch는 Spring 생태계에서 배치 처리를 손쉽고 안정적으로 구성할 수 있도록 지원하는 오픈소스 프레임워크입니다.대용량 데이터 처리, 트랜잭션 관리, 로깅, 체크포인트, 실패 복구 등 배치의 복잡한 요소들을 쉽게 관리할 수 있게 도와줍니다. Spring Batch는 3단계 처리 ..

Apache Kafka 완벽 정리: 실시간 데이터의 핵심 플랫폼과 비용 요즘 IT 서비스나 플랫폼을 운영하다 보면 “실시간 데이터 처리”라는 말을 많이 듣습니다.사용자가 남긴 로그, 쇼핑몰의 주문 이벤트, 금융 거래 기록처럼 빠르게 쌓이는 데이터를 안정적으로 수집하고 가공해서 다른 서비스에 전달하려면 무엇이 필요할까요? 바로 그 핵심에 있는 기술이 Apache Kafka입니다. Kafka란 무엇인가? Kafka는 분산 스트리밍 플랫폼입니다. 쉽게 말해, 데이터를 실시간으로 안전하게 모으고, 저장하고, 필요한 곳으로 흘려보내는 역할을 합니다. 단순한 메시지 큐(Message Queue) 시스템을 넘어서, 데이터 파이프라인의 허브이자 이벤트 로그 저장소 역할까지 해내죠. Kafka의 기본 개념 메시지(M..

📡 1.1 네트워크 구성도데이터 센터 네트워크는 안정적이고 빠른 대용량 서비스 제공을 목표로 구성다양한 이중화 기술을 사용하여 고가용성 보장많은 서버와 서비스가 한 네트워크에 연결되므로, 높은 통신량 수용 필요기존 구성: 3계층 네트워크 구조Core → Aggregation → Access트래픽 증가, 복잡성 증가 문제 발생최근 구성: Spine-Leaf 구조 (2계층 네트워크)Scale-Out 기반 애플리케이션에 적합서버 간 통신이 많은 환경에서 대역폭 균형을 맞추기 위해 등장Leaf 스위치: 서버와 직접 연결Spine 스위치: Leaf 스위치 간 고속 통신 담당🛰️ 1.2 프로토콜프로토콜(Protocol): 통신 시 정해진 규칙(규약)→ 물리적 & 논리적 측면 모두 포함🔹 프로토콜 구분구분설명물..

1. 로드 밸런싱이란?하나의 서버로는 모든 트래픽을 감당하기 어려워 여러 서버에 트래픽을 분산하여주는 방법이다.서비스의 규모가 커지고 이용자 수가 증가하면 원활한 서비스 동작이 불가능하여 아래의 대처 방법들을 사용해야 한다.기존의 서버 성능을 확장하는 Scale-up 방식기존의 서버와 동일하거나 낮은 성능의 서버를 증설하는 Scale-out 방식→ 여기서 Scale-out방식을 사용한다면 로드 밸런싱 기술이 반드시 필요하다.L4로드 밸런싱과 L7로드 밸런싱이 대표적이다.2. 로드 밸런싱 기법로드 밸런싱 기법은 서버의 능력을 고려하여 분배하여야 하기 때문에 서버의 상황에 맞춰서 적절한 방법을 사용해야 한다.2.1. 라운드로빈 방식(Round Robin Method)서버에 들어온 요청을 순서대로 돌아가며 배..

안녕하세요! 이번 글에서는 JPA를 사용하다가 직접 쿼리를 작성해 성능을 개선한 경험을 공유하려 합니다.보통 JPA는 객체 지향적으로 DB를 다루기에 개발 편의성과 유지보수 측면에서 뛰어나지만, 때로는 성능 최적화가 필요한 상황에서 직접 쿼리를 작성하는 것이 더 유리할 수 있습니다. 1. 문제 상황: JPA 성능 이슈프로젝트에서 장바구니 기능을 구현하며 JPA의 기본 메서드를 통해 데이터를 조회하고 수정했습니다.하지만 대량의 데이터를 처리하거나 복잡한 조건을 다룰 때 다음과 같은 문제가 발생했습니다.N+1 문제로 인한 쿼리 과다 발생데이터 수정 시 여러 번 DB를 호출하여 응답 지연복잡한 조건 조회 시 쿼리가 비효율적장바구니 기능을 개발하면서 API 응답 속도를 측정해보니, TTFB(Time To Fir..