의문 해결 목록

강서진·2024년 2월 26일

Dirty Checking(JPA)

영속성 컨테이너가 관리하는 엔티티의 상태를 감지해, 변경된 부분이 있다면 자동으로 트랜잭션이 끝나는 시점에 데이터베이스에 반영하는 기능

변경의 기준은 엔티티의 최초 조회 상태로, JPA에서는 엔티티를 조회할 때 해당 엔티티의 상태를 그대로 스냅샷을 만든다. 트랜잭션이 끝나는 시점에서 변경사항이 있다면 이를 update 쿼리로 전달한다.

여기서 Dirty는 entity의 변경된 부분을 뜻한다. 변경사항을 자동으로 반영하기 때문에 개발자가 update 쿼리를 따로 작성할 필요가 없어져서 코드의 복잡성이 줄어든다.

Dirty Checking의 조건
1. 영속성 컨텍스트에서 관리되는 엔티티여야 한다.
2. 트랜잭션이 커밋되어야 한다. (커밋되기 전까지는 변경사항을 추적하기만 하고 DB에 반영하지 않는다.)

Dirty Checking으로 생성되는 update 쿼리는 기본적으로 엔티티의 모든 필드를 업데이트한다. 전체 필드를 업데이트하면 쿼리를 재사용할 수 있다는 장점이 있다.
전체 필드가 아니라 변경 필드만 반영되게 하려면 엔티티 최상단에 @DynamicUpdate 애너테이션을 붙인다.

JPA Auditing

DB를 관리하다보면 도메인별로 생성일자, 수정일자, 식별자 등공통된 필드나 칼럼이 존재한다. 도메인마다 공통이기 때문에 개별적으로 이러한 칼럼들을 생성하게 되면 코드가 중복된다. 하여 JPA에서는 시간에 대한 값을 자동으로 넣어주는 Audit 기능을 제공한다.

@CreatedDate (필드)
: Entity가 생성 및 저장될 때의 시간이 자동 저장된다.
@LastModifiedDate (필드)
: 조회한 Entity 값을 변경할 때 시간이 자동 저장된다.
@EntityListeners(AuditingEntityListener.class) (클래스)
: 해당 클래스에 Auditing 기능을 포함한다.
@MappedSuperclass
: JPA 엔티티들이 해당 추상클래스를 상속할 경우 추상 클래스에 속한 @CreatedDate, @LastModifiedDate 등의 필드를 칼럼으로 인식한다.

Cascade

JPA 엔티티는 다른 엔티티의 존재와 연관관계를 맺고 있을 수 있다. 대표적인 예시로 게시글과 댓글의 관계가 있다. 게시글은 댓글이 없어도 존재할 수 있지만, 댓글은 게시글이 없으면 존재할 수 없다.
만약 댓글이 달린 게시글이 삭제된다면 해당 댓글도 삭제되어야 한다. 그렇다고 매번 게시글이 삭제될 때마다 댓글을 삭제하는 로직을 작성하는 것은 번거롭고, 실수로 빼먹을 수도 있다. 이러한 문제점을 해결하기 위해 등장한 것이 JPA Cascade이다. Cascade를 사용하면 밀접한 연관성을 가진 엔티티들을 관리하기가 수월해진다.

PERSIST
: 엔티티를 영속화할 때 연관된 엔티티를 함께 영속화한다.
MERGE
: 엔티티 상태를 병합할 때 연관된 엔티티도 함께 병합한다.
REMOVE
: 엔티티를 제거할 때 연관된 엔티티들도 함께 제거한다.
REFRESH
: 엔티티를 새로고침할 때 연관된 엔티티들도 함께 새로고침한다(=데이터베이스에서 실제 레코드의 값을 즉시 로딩해 덮어씌운다.)
DETACH
: 엔티티를 영속성 컨텍스트에서 분리하여 연관된 엔티티들을 분리한다.
All
: 위의 모든 CascadeType들을 적용한다.

CascadeType.REMOVE 혹은 ALL을 설정해두면 엔티티 삭제 시 연관된 엔티티들이 전부 삭제되거나, 삭제된 데이터가 복구되는 등 데이터의 모순이 발생할 수 있다. 따라서 CascadeType는 엔티티 간 관계가 명확할 때 사용하며, 오용하지 않아야 한다. 또, 부모-자식 관계가 명확하지 않거나 하나의 자식에 여러 부모가 대응되는 경우에는 문제가 될 수 있기 때문에 신중하게 사용해야 한다.

무결성 제약조건
무결성이란 데이터에 결함이 없는 상태로, 데이터를 정확하고 일관되게 유지하는 것을 의미한다. 무결성 제약조건이란 데이터베이스의 정확성, 일관성을 보장하기 위해 저장, 삭제, 수정 등을 제약하기 위한 조건이다.

개체 무결성: 기본키는 NULL이거나 중복될 수 없다.

참조 무결성: 외래키값은 NULL이거나 참조하는 릴레이션의 기본키 값과 동일해야 한다. (=각 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다.)

도메인 무결성: 속성들의 값은 정의된 도메인에 속한 값이어야 한다.

고유 무결성: 특정 속성에 대해 고유한 값을 가지도록 조건이 주어질 경우, 중복될 수 없다.

NULL 무결성: NULL 값이 올 수 없도록 제한한 경우 NULL값을 받을 수 없다.

키 무결성: 각 릴레이션은 최소 1개 이상의 키를 가져야 한다.

HTTP와 HTTPS

HTTP 프로토콜
: HTTP(Hypertext Transfer Protocol).
클라이언트와 서버 간 통신을 위한 통신 규약. 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하면 웹 서버는 HTTP 응답으로 응답하며, 데이터는 일반 텍스트로 교환된다.
HTTP는 암호회되지 않은 데이터를 전송하기 때문에, 중간에 제3자가 가로챌 수 있는 위험에 노출되어 있다.
HTTPS 프로토콜
: (Hypertext Transfer Protocol Secure)는 더 안전한 버전의 HTTP로, 브라우저와 서버가 데이터를 전송하기 전에 SSL 및 TLS 기술을 사용해 안전하고 암호화된 연결을 설정한다.
HTTPS 웹사이트는 독립된 인증기관에서 SSL/TLS 인증서를 획득하고, 데이터를 교환하기 전에 브라우저와 인증서를 공유한다.

브라우저가 서버의 인증서를 요청하면 서버는 퍼블릭 키가 포함된 SSL 인증서를 회신으로 전송한다.
인증이 되면, 브라우저는 퍼블릭 키를 사용해 비밀 세션 키가 포함된 메시지를 암호화해 보내고, 서버는 개인키를 사용해 메시지를 해독하고 세션 키를 브라우저에 제공한다.
이 다음부터 브라우저와 웹은 동일한 세션 키를 사용해 메시지를 안전하게 교환한다.

SQL Injection

SQL 인젝션은 악의적인 사용자가 보안 상의 취약적음 이용하여 임의의 SQL문을 주입하여 DB가 비정상적인 동작을 하도록 조작하는 행위이다. SQL Injection은 OWASP(Open Worldwide Application Security Project)가 선정한 인터넷 보안 위험 탑 10에 들어가기도 한다.
대응 방안으로는 입력 값에 대한 검증 로직을 추가하거나, PreparedStatement 구문을 사용하거나, Error Message 노출을 금지하거나 웹 방화벽을 사용할 수 있다.

Server Side Rendering

(A.K.A. Multi Page Rendering)
서버사이드 렌더링은 다른 화면으로 이동할 때마다 서버에 리소스를 새로 요청해 전달받은 내용을 클라이언트가 화면에 표시한다.

SPA(Single Page Application)

(A.K.A. Client Side Rendering)
하나의 페이지를 사용하는 애플리케이션으로, 서버에서 새로운 페이지를 가져오는 것이 아니라 하나의 페이지에서 내용을 동적으로 변경하는 사용자 웹앱을 말한다.
기존에는 웹사이트 하나에 전달되는 용량이 적었으나, 웹사이트가 발전하면서 포함된 데이터의 양이 많아져 부담이 되자 SPA가 등장하게 되었다.
SPA를 사용하면, 매번 새로운 페이지를 로딩하면서 html에 포함된 헤더, 네비게이션, 푸터 등의 중복된 요소들을 계속 새로 전달할 필요가 없어진다.
SPA 구현 방식은 대표적으로 Ajax를 통한 비동기 컨텐츠 로드가 있다. 또, React를 사용해 컴포넌트 조각들로 이루어진 페이지일 경우 SPA가 적합하다.

장점