Welcome! Everything is fine.

🗃️ 데이터 베이스데이터베이스(database) : 사용자나 프로그램에서 사용하기 위해 저장 및 관리하는 데이터 집합개체(entity) : 데이터로 표현하려는 대상속성(attribute) : 개체의 특성과 상태관계(relationship) : 개체 간에 어떤 관련이 있는지 나타냄관계형 데이터베이스관계형 데이터베이스(RDB, Relational Database) : 데이터가 2차원 테이블에 저장되며, 데이터의 구조와 데이터 간 종속성 등을 알 수 있는 데이터베이스릴레이션 : 관계형 데이터베이스에서 데이터의 개념적 모델테이블 : 릴레이션을 실제로 구현한 개체로, 키-값으로 이루어진 2차원 형태행(=튜플, 레코드) : 테이블을 구성하는 데이터들 중 가로로 묶은 데이터셋열(=속성, 필드) : 테이블을 구성하..

⭐ 객체지향 설계가 중요한 이유객체 지향 프로그래밍은 객체를 중심으로 시스템을 구성하는 방식이다. 현실 세계의 사물이나 사건을 하나의 객체로 보고, 이런 객체들 간의 상호작용을 중심으로 프로그래밍한다. 복잡한 시스템일수록 기능을 분리하고, 역할을 명확히 나눈 구조가 필요하다. 객체지향은 이러한 확장성과 유지보수성을 높이기 위한 핵심 설계 방식이다. Spring은 객체지향 설계를 전제로 만들어진 프레임워크로, 특히 IoC와 DI는 객체 간의 관계를 유연하게 구성하고 관리하는 데 중요한 역할을 한다.💡 OOP 특징과 설계 원칙객체 지향의 4가지 핵심 개념추상화( Abstraction )불필요한 세부 사항을 감추고 핵심적인 동작이나 속성만 드러내는 것 List 인터페이스를 사용할 때 내부 구조는 몰라도 ad..

🧐 Spring Batch란? 배치(Batch) 처리란 대량의 데이터를 정해진 시점에 자동으로 일괄 처리하는 방식이다.예시 매일 자정 주문 데이터 통계 저장 매주 고객 대상 이메일 발송DB 마이그레이션, 정산 처리 등특징사람이 직접 요청하지 않아도 자동으로 주기적 실행실시간성보다 정확성과 안정성이 중요실패 시 재처리, 로그 추적이 중요Spring Batch는 대용량 배치 작업을 쉽고 안전하게 처리할 수 있도록 도와주는 Spring 기반 프레임워크다.Job/Step 기반 구성 제공예외, 로그. 재시작, 로깅 등의 기능 제공청크 기반 처리, 병렬 처리 등 내장💡 Spring Batch의 구조Job과 Step아래 그림은 Spring Batch의 전반적인 실행 흐름을 나타낸다.JobLauncher : 배치..

🧠 동기 · 비동기와 블로킹 · 논블로킹동기 vs 비동기동기(Synchronous) : 호출자와 요청자의 결과 확인이 동시에 일어남비동기(Asynchronous) : 호출자와 요청자의 결과 확인이 동시에 일어나지 않아도 됨블로킹 vs 논블로킹블로킹(Blocking) : 호출자가 요청에 대한 결과가 나올 때까지 요청자에게 제어권을 돌려주지 않는 것논블로킹(Non-Blocking) : 호출자가 요청에 대한 결과가 나오지 않더라도 요청자에게 제어권을 돌려줌동시성 vs 병렬성동시성(Concurrency) : 싱글 코어에서 여러 작업을 번갈아 가며 처리하는 방식병렬성(Parallelism) : 멀티 코어가 각 작업을 물리적으로 동시에 처리하는 방식 예를 들어, 아래 코드는 메시지를 수신할 때 동시에 최대 3개의..

이번 주 스터디 주제는 인증/인가다!최종 프로젝트에서 다른 팀원이 구현한 코드를 분석해보며 인증/인가에 대한 공부도 함께 진행해보려한다.Spring Security + JWT를 사용하는 방식은 이전에 강의를 듣고 포스팅 한 적이 있지만,프로젝트를 진행하면서 인증/인가 부분은 맡은 적이 없어서 기본에 충실한 내용들로 구성해 정리해보려 한다. 👤인증/인가가 필요했던 이유우선 인증(Authentication)과 인가(Authorization)에 대해 짚고 가자.인증(Authentication) : 사용자가 서비스에 가입되어 있는지 확인하는 과정(= 로그인)인가(Authorization) : 인증된 사용자에 대해 권한을 확인하는 과정인증/인가가 없다면 식당 예약, 이벤트 참여, 결제와 같은 주요 기능에 누..

최종 프로젝트가 끝난지 벌써 2주가 됐다...!최종 프로젝트에서 나는 예약 및 이벤트 동시성 제어를 구현했지만 아쉬운 점이 많았다. 좀 더 다양한 동시성 제어 방법에 대해 공부하지 않은 점DB 락 구현이 잘못된 점내가 구현한 부분은 말로 설명하는 연습이 부족한 점따라서 팀원들과 매주 모여 자신이 공부한 내용을 발표하고 의견을 나눠보기로 했다.주제는 최종 프로젝트의 핵심적인 내용 위주로 진행될 예정이다.첫 번째 주제는 "동시성 제어"이다.내가 맡은 부분이긴하지만 어렵고 헷갈리는 부분이 많아 쉽지 않은 주제인 것 같다.🧐동시성(Cocurrency) 제어란? 둘 이상의 실행 흐름(스레드 또는 트랜잭션)이 동시에 동일한 자원에 접근할 때 발생할 수 있는 데이터 충돌이나 정합성 오류를 방지하기 위한 제어 기법...

기존 코드의 문제점기존 이벤트 API는 오픈 알림이 구현되지 않았고,단순 DB 기반 스케줄러로 1분마다 오픈 시간을 체크해 상태를 변경하는 구조였다. 하지만 지금과 같은 구조는 다음과 같은 단점이 있다.데이터베이스 부하 증가스케줄러는 매 분마다 WHERE open_at 모든 이벤트를 조회해야 한다. 기존 코드는 매 분마다 위와 같은 조건으로 풀스캔하고 있다. 인덱스를 적용하더라도 유저 수와 이벤트 수가 많아질수록 쿼리 부하가 커지고, 인덱싱만으로는 처리 한계가 생긴다. 이벤트 오픈 비동기 전파 필요성만약 알림 도메인과 직접적인 연결을 한다면?두 서비스가 서로의 생명주기와 내부 구조에 영향을 받을 수 있다.직접적인 연결은 유지보수를 어렵게 하고, 장애 전파 가능성을 높인다.MQ를 사용하면 이벤트 서비스는..

문제점이벤트 정원이 10명인데도 200명 신청 시 9명까지만 들어가는 문제가 발생했다.또한 로그에서 “이벤트 정원이 초과되었습니다.”라는 메세지가 떴다.Redis에는 이미 200명이 저장된 상태DB는 한 명이 누락된 상태DB에 존재하지 않는 ID로 다시 신청 → EVENT_ALREADY_JOINED 예외 발생원인Redis와 DB의 정합성이 깨졌는데, 검증 기준은 Redis에만 의존하고 있기 때문이다. Redis는 ID를 이미 참여한 유저로 보고 있지만, 실제 DB에는 들어가지 않았다.하지만 ZSet에 있는 것만 보고 판단하여 중복 신청으로 막아버린 것이다.Zset에는 실패한 유저도 들어있기 때문에 100% 신뢰할 수 없다.왜 지금까지 이런 문제가 한 번도 없었는지는 잘 모르겠다..😓해결 방법valida..