1. 자동 구성(Auto-Configuration)클래스패스 스캔: Spring Boot는 애플리케이션 실행 시 클래스패스에 있는 라이브러리와 설정 파일을 스캔한다.조건부 설정: 특정 라이브러리가 존재하거나, 특정 빈(bean)이 없는 경우에만 자동으로 설정을 적용한다. 2. 의존성 주입 (Dependency Injection)와 제어의 역전 (IoC)의존성 관리: 스프링 프레임워크의 핵심 개념인 DI와 IoC를 통해 애플리케이션 내의 객체 간의 의존성을 스프링 컨테이너가 관리한다.유연성 및 테스트 용이성: 객체들이 직접 생성되기보다는 컨테이너에 의해 주입되므로, 코드의 결합도를 낮추고, 테스트 및 유지보수가 용이해진다. 3. 스타터 의존성 (Starter Dependencies)편리한 의존성 관리: s..

1. 요청(Request)클라이언트가 HTTP 요청을 보내면, Spring boot의 내장 웹 서버(Tomcat, Jetty 등)가 이를 수신한다. 2. DispatcherServlet을 통한 요청 처리Spring Boot는 DispatcherServlet을 중앙 컨트롤러(Front Controller)로 사용한다.이 DispatcherServlet은 모든 요청을 받아 적절한 핸들러(Controller)로 전달하는 역할을 한다.Spring Boot 실행 시 DispatcherServlet이 자동으로 등록된다.기본적으로 모든 URL패턴(/*) 을 처리하도록 매핑된다. 3. HandlerMapping을 통한 컨트롤러 탐색DispatcherServlet은 요청된 URL과 매칭되는 컨트롤러를 찾기 위해 여러 H..

처음에는 스프링 부트에 대해 아무것도 모르는 상황이라 학원에서 요구하는 버전대로 사용을 해왔지만 이제는 어느정도 익숙해지니 각 버전별로 어떤게 사용이 가능한지 혹은 안되는 것은 무엇인지 알기 위해 버전별로 정리해볼려고 한다. 1.x → 2.x (Spring Boot 2.0) 1. Spring Framework 업그레이드: Spring Framework 5.0 기반으로 변경.  2. Reactive Programming 지원: WebFlux 도입으로 비동기 및 논블로킹 API 지원.  3. Actuator 개선:Actuator 엔드포인트가 /actuator로 기본 경로 변경.새롭게 설계된 Actuator로 세부적인 메트릭스 제공.  4. Configuration Properties 개선:프로퍼티 바인딩 개..

원인은?프로젝트에서 채팅방 목록을 조회할 때 발생하는 순환 참조 문제를 해결하기 위해 코드를 개선하였다. 기존에는 ChatRoom 엔티티를 그대로 반환하거나 참조하는 과정에서 @ManyToOne 또는 @OneToMany와 같은 양방향 관계로 인해 순환 참조가 발생할 수 있었으나, 이로 인해, 직렬화 과정에서 무한 루프에 빠지는 문제가 있었다. 어떻게 해결했나?이를 해결하기 위해 DTO(Data Transfer Object)를 활용하여 필요한 필드만 가져오도록 하였다. ChatDto.ChatRoomDto라는 DTO를 정의하여 채팅방 조회 시 필요한 최소한의 필드(chatRoomId, createdAt)만 반환하도록 하고,ChatRoom 엔티티의 조회 메서드를 변경하여 ChatRoomDto로 변환 후 반환하..

이번 Trello 프로젝트에서 카드 수정 시 동시성 제어를 적용할려고 합니다. 왜 카드 수정 시 동시성 제어를 해야 되느냐?  데이터 일관성 및 무결성 보장동시성 제어는 여러 사용자가 동시에 같은 카드를 수정하는 상황에서 데이터의 일관성을 유지하기 위해 필요합니다. 만약 두 명 이상의 사용자가 동일한 카드에서 다른 정보를 수정할 경우, 각 사용자의 변경 사항이 충돌하게 됩니다. 이를 방치하면 다음과 같은 문제가 발생할 수 있습니다변경 사항 덮어쓰기: 예를 들어, 사용자 A가 카드의 제목을 수정하고, 동시에 사용자 B가 카드의 내용을 수정한다면, 한 사용자의 수정이 다른 사용자의 수정으로 덮어씌워져 일부 변경 사항이 유실될 수 있습니다.일관성 문제: 여러 사용자가 동시에 카드를 업데이트하면서 서로 다른 데..

낙관적 락(Optimistic Locking)란?낙관적 락(Optimistic Locking)은 데이터베이스나 멀티스레드 환경에서 여러 사용자가 동일한 데이터를 수정할 때 발생할 수 있는 충돌을 관리하는 방법 중 하나입니다. 낙관적 락은 충돌이 자주 발생하지 않을 것이라고 가정하고, 충돌을 감지하여 처리하는 방식으로 동작합니다. 이 방식은 보통 비전 번호(Versioning)나 타임스템프를 이용해 구현됩니다. 낙관적 락 작동 원리데이터 조회: 사용자가 데이터를 조회할 때 해당 레코드의 현재 버전 정보를 함께 가져옵니다. 이 버전은 레코드가 수정될 때마다 증가하거나 변경됩니다.데이터 수정: 사용자가 데이터를 수정하려고 할 때, 수정하려는 레코드의 현재 버전과 사용자가 처음 조회할 때 가져온 버전 정보를 비..

KPT 회고KEEP, 다음 프로젝트로 가져갈·  추가 구현에서 경험한 동시성 처리, Redis를 이용한 캐시의 이점, 쿼리와 인덱스를 이용한 최적화, 젠킨스와 도커를 이용한 CICD까지 직접 구현하진 않은 부분일지라도 팀 노션에 작성된 부분을 통해 간접 경험을 하거나 동료의 구현 모습을 보면서 좀더 본인의 기술을 디벨롭 할 수 있는 경험. ·  의견 차이를 커뮤니케이션을 통해 극복하는 자세를 유지하면 좋다. 대부분의 개발이 단체로 이뤄지기 때문에 의견을 수용하고, 배우는 자세를 유지하는것은 매우매우 좋음. ·  동시성 처리에서 분산락, 낙관락, 비관락을 활용한 다양한 동시성 처리 방식을 적용해보았고, 각 방법이 특정 메서드에 얼마나 적합한지 확인하는 과정을 거침. ·  외부 API 호출을 통한 알림 기능..

일단 코드 설명을 하기 앞서 왜 transactional 로그 기록을 남길 때 common 패키지로 분리해서 관리해야 하는지 설명하도록 하겠습니다. 1. 관심사 분리(Separation of Concerns)manager 패키지는 주로 매니저 등록, 수정, 삭제와 같은 비즈니스 로직을 다룹니다. 하지만 로그 관리는 모든 모듈에서 공통적으로 사용될 수 있는 기능이기 때문에 별도의 common 패키지로 분리하여, 비즈니스 로직과 로그 관리 로직을 명확히 구분하는 것이 좋습니다.예를 들어, manager뿐만 아니라 user, product 등 다양한 서비스에서 로그를 사용할 수 있다면, 각 서비스에서 중복된 로그 관리 코드를 작성하지 않고, common 패키지의 공통 로그 관리 기능을 재사용할 수 있습니다.2..

조건은 다음과 같습니다.검색 조건검색 키워드로 일정의 제목을 검색이 가능해야 한다.제목은 부분적으로 일치해도 검색이 가능해야 한다.일정의 생성일 범위로 검색할 수 있어야 한다.일정을 생성일 최신순으로 정렬이 가능해야 한다.담당자의 닉네임으로도 검색이 가능해요.닉네임은 부분적으로 일치해도 검색이 가능해야한다.다음의 내용을 포함해서 검색 결과를 반환해야한다.일정에 대한 모든 정보가 아닌, 제목만 넣도록 해야 한다.해당 일정의 담당자 카운트가 가능해야 한다.해당 일정의 총 댓글 카운트가 가능해야 한다.검색 결과는 페이징 처리. QueryDSL 구현순서 1. Entity 작성 이미 comment와 user간의 연관관계가 이어져 있기에 추가적으로 수정할 필요는 없었다.package org.example.exper..

객체 관계 매핑 프레임워크는 Enterprise Java의 핵심입니다. 이는 객체 지향 방식과 관계형 데이터베이스 모델 간의 불일치를 보완합니다. 또한 개발자가 더 깔끔하고 간결한 지속성 코드와 도메인 로직을 작성할 수 있도록 합니다. -QueryDSL 공식 홈페이지중 baeldung의 QueryDSL 목적https://www.baeldung.com/intro-to-querydsl 즉 QueryDSL은 Java 언어로 작성된 쿼리를 위한 타입 안전 쿼리 생성 라이브러리입니다. SQL, JPA, MongoDB 등 다양한 데이터베이스와의 상호작용을 지원하며, 개발자가 보다 직관적이고 안전하게 데이터베이스 쿼리를 작성할 수 있도록 도와줍니다. 주요 특징타입 안전성 QueryDSL은 쿼리의 문법과 데이터 타입을..