백엔드 부트캠프

1️⃣ 비밀번호 Valid 수정1. 배경 (Situation)레벨 1 에서 Validation 을 수정했습니다. 비밀번호에 대한 검증인데, 회원가입 시에는 적용되고 있지 않았습니다. 새로운 비밀번호 수정 시에만 Valid 를 적용해주고 있었습니다.2. 문제점 또는 도전 (Task)회원가입 시에는 비밀번호에 대한 유효성 검증이 적용되지 않았고, 새로운 비밀번호 수정 시에만 유효성 검증이 적용되는 문제점이 존재합니다.이로 인해, 회원가입 시에는 비밀번호 제약이 적용되지 않아 보안상 문제가 발생할 수 있다. 따라서, 비밀번호 검증 로직을 회원가입에도 적용해야 합니다.3. 해결을 위한 행동 (Action)1) Entity DB 제약 추가보통 자세한 제약은 DTO 딴에서 막는 것이 낫습니다. 비밀번호 같은 민감..

1️⃣ FetchType : Eager 와 LazyN+1 문제에 대해서 생각을 할려면,먼저 Eager 와 Lazy 의 개념에 대해서 알아야한다."연관된 엔티티를 언제 가져올지를 결정하는 방식, Fetch Type 에는 두 가지가 있다."연관된 엔티티를 전부다 조회할 건지? 필요한 것만 나중에 조회할 것인지? 이렇게 두 종류가 있다고 생각하면 된다.1. Eager- Eager 라는 것은 엔티티를 조회할 때 즉시 연관 객체도 함께 로딩 된다- 초기 로딩이 느릴 수 있다. (불필요한 데이터까지 가져옴)- 진짜 항상 같이 쓰는 관계에서 사용해야 한다.- 코드 예시는 아래에서 비교할 때 보여주겠다.2. Lazy- 연관 객체는 실제로 사용할 때 로딩된다. 해당 연관 객체를 get 등을 할 때 로딩되는 것이다.- 처..

1. Persistence Context 가 뭐야 ?자바의 엔티티(Entity)를 관리(보관)하는 JPA의 메모리 공간 이다.자바 애플리케이션과 데이터베이스 사이에서, 객체(Entity)를 저장하고 조회하는 역할을 수행하는 JPA의 저장 관리 계층이다.영속성 컨텍스트라는 메모리 공간을 통해, 엔티티의 상태를 관리하고 DB와의 변경사항을 동기화한다.그림으로 표현하면 아래와 같다.자바 애플리케이션과 DB 사이의 중간 저장소 역할인 것이다.여기서, 하나 의문이 들 것이다.“DB가 데이터를 저장하는 곳 저장소인데, 왜 자바 애플리케이션과 DB 사이에 JPA나 Persistence Context 같은 저장소가 또 필요해?” 답은 아래와 같다.> 자바는 객체지향 프로그래밍 언어지만, 데이터베이스는 관계형 시스템이다..

1. 오버헤드란 ?계속해서 강의를 듣고, 문제를 해결해나가는 과정에서 자주 들리는 말이 있다.바로 " 오버헤드 Overhead " 이다.간단하게 설명하자면, 기본 기능을 수행하는 데 필요한 부가적인 자원 소모를 뜻한다.우리가 직접적인 일하는 것 외에 추가로 드는 시간, 메모리, 네트워크, 연상 등의 비용을 의미한다고 한다.오버헤드는 시스템 성능, 확장성, 응답 속도 등에 직접적인 영향을 미치기 때문에 개발자에게 매우 중요한 개념이라고 할 수 있다. 2. 오버헤드 종류백엔드에서 발생할 수 있는 주요 오버헤드는 아래와 같다.1. 네트워크 오버헤드API 요청/응답, REST 통신2. 데이터베이스 오버헤드쿼리 비효율, 인덱스 미사용3. 서버 처리 오버헤드비동기 처리 실패, 과도한 로직4. 스레드/동시성 오버헤드..

✅ 캡슐화캡슐화 " Client 객체가 구체적인 것을 의존하지 못하도록 숨기고 추상적인 것만 의존하도록 하는 모든 과정 "Client 객체란? 협력에서 요청을 보내는 객체이다.1 ) 구체적인 것 : 변경될 가능성이 높은 것 | How 가 대표적인 구체적인 것 (인스턴스) > 낮은 것-> 낮은 수준의 것을 것을 의존했을 때 생기는 문제 > 구체적인것에 의존하면 할 수록 우리는 결합도가 높다고 함. -> 결합도가 높은 것은 변경될 가능성이 높다는 것이며 의존성이 높아진다는 것. 그래서 변경의 전파가 클 것임.2) 추상적인 것 : 변경될 가능성이 낮은 것 | 메서드 이름, 파라미터, 반환값등 What에 대한 것이 대표적인 추상적인 것 > 높은 것 ✅ 캡슐화 하는 방법1. 자주 변경되는 것과 그렇지 않은 것을 ..

✅ Keep이번 프로젝트에서 진행한 과정 중 다음 프로젝트에서도 유지했으면 하는 부분1. 일관된 예외 처리2. Pull request 요청할 경우 PULL 한 후 PUSH3. 문서화 습관4. 함수 네이밍 컨벤션 지키기5. 커밋 메시지 컨벤션 지키기✅ Problem1) 좋아요의 동시성 문제문제 원인동시에 여러 사용자가 같은 댓글에 좋아요를 누르거나 취소할 경우,Race Condition(동시성 문제)로 인해 DB의 likeCount 값이 실제 좋아요 수와 일치하지 않을 가능성을 발견했다.문제 분석likeCount는 단순 숫자 필드로, 동시 요청 시 DB에 저장되는 값이 충돌 없이 덮어쓰여지는 문제가 있었다.트랜잭션을 사용하더라도 조회 → 증가 → 저장 사이에 다른 요청이 개입하면 값이 꼬일 수 있었다.문제..

@Builder는 Lombok에서 제공하는 어노테이션으로, 객체 생성 시 생성자 또는 메서드에 직접 값을 하나씩 넣지 않고, 가독성 좋고 유연한 방식으로 객체를 생성할 수 있도록 도와준다. 특히 파라미터가 많은 객체를 생성할 때 매우 유용하다.✅ 기본 개념@Builderpublic class User { private String name; private int age; private String email;}위와 같이 @Builder를 붙이면, 다음과 같은 방식으로 객체를 만들 수 있다User user = User.builder() .name("AA") .age(27) .email("aa@example.co..

JWT (JSON Web Token)✅ JWT란?JWT는 로그인한 사용자 정보를 토큰 형태로 안전하게 주고받기 위해 사용하는 인증 수단JWT는 서버가 세션 없이도 사용자의 인증 상태를 유지할 수 있게 도와준다. ✅ JWT 구조JWT는 다음과 같이 3가지 부분으로 나뉜다.xxxxx.yyyyy.zzzzz부분이름설명xxxxxHeader알고리즘 및 타입 정보 (ex. HS256, JWT)yyyyyPayload사용자 정보: userId, 이름, 권한 등zzzzzSignature서명. 위 내용이 변조되지 않았는지 검증1. Header{ "alg": "HS256", "typ": "JWT"}- 어떤 알고리즘을 서명했는지- 타입음 JWT 을 명시2. Payload{ "sub": "1234567890", "name..

✅ 깨끗한 코드1. 재 디자인의 무한 루프기존 코드가 너무 복잡하거나 생산성이 낮아서 → "이건 안 되겠다, 새로 짜자!" 해서 새로운 팀(tiger team)이 생김그 팀이 기존 걸 따라가면서 새 기능도 추가하는 걸 목표로 개발함근데 시간이 지나면서 그 Tiger 팀의 원래 멤버들이 빠지고 새 사람들로 바뀜새 멤버들이 기존 tiger team 코드(이제 새 코드죠)를 보면서 → "이거 별로네… 다시 만드는 게 낫겠는데요?"이게 계속 반복되는 무한루프가 생기게 된다. 실제로 많은 프로젝트에서 반복된다. 그래서 리팩토링이나 점진적인 개선이오히려 현실적인 접근일 때가 많다.2. 태고의 난제더러운 코드는 생산성을 저하시킨다. 그와 동시에 개발자들은 기한을 맞추기 위해 더러운 코드를 짠다. 하지만, 더러운 코드..

✅ Race Condition이란?여러 사용자가 동시에 같은 데이터를 수정하려 할 때,처리 순서에 따라 데이터가 덮어씌워져 예상과 다른 결과가 생기는 현상.예시:현재 좋아요 수: 5유저 A와 B가 동시에 클릭 → 둘 다 5 읽고 6 저장결과: 실제론 2번 눌렀지만 +1만 반영됨✅ 왜 발생하는가?@Transactionalpublic void likePost(Long postId) { Post post = postRepository.findById(postId).orElseThrow(); post.setLikeCount(post.getLikeCount() + 1);}post.getLikeCount()로 읽은 시점이 같으면,동일한 값으로 계산 → 마지막 저장 값만 반영됨✅ 동시성 문제가 발생하기 쉬..