Skip to content

Latest commit

 

History

History
276 lines (218 loc) · 25.2 KB

miscellaneous.md

File metadata and controls

276 lines (218 loc) · 25.2 KB

miscellaneous

Node.js

Passport

Passport는 Node.js 기반의 웹 애플리케이션에서 사용자 인증을 간편하게 구현할 수 있도록 도와주는 미들웨어입니다.

  1. 다양한 인증 전략: Passport는 많은 인증 제공업체(Google, Facebook, Twitter, GitHub 등)와의 통합을 지원하며, 다양한 인증 전략을 제공하여 사용자를 인증할 수 있습니다.
  2. 세션 관리: Passport는 세션을 사용하여 사용자의 로그인 상태를 추적합니다. 세션을 설정하고 유지함으로써 사용자의 인증 상태를 유지할 수 있습니다.
  3. 미들웨어 편의성: Passport는 Express와 함께 사용하기 쉽도록 설계되었습니다. Express의 미들웨어로 사용되며, 간단한 설정만으로도 인증을 구현할 수 있습니다.
  4. 사용자 정의 가능: Passport는 확장 가능하며, 사용자 정의 인증 전략을 만들어 기존의 인증 제공업체 외에도 사용자의 자체 인증 시스템을 통합할 수 있습니다.

passport-google-oauth20

passport-google-oauth20은 Passport.js와 함께 사용되는 Google OAuth 2.0 전략을 제공하는 Passport의 확장 모듈입니다. 이 모듈을 사용하면 Express 애플리케이션에서 Google 계정을 통한 사용자 인증을 구현할 수 있습니다.

express-session

express-session은 Express 애플리케이션에서 세션을 구현하기 위한 미들웨어입니다. 클라이언트에 세션 ID를 부여하고, 서버 측에 세션 데이터를 저장하여 세션을 관리합니다.

주로 Passport.js와 함께 사용되며, 사용자 인증 후에 세션을 저장하고 관리할 수 있습니다.

Web

쿠키(Cookie)

쿠키는 웹 서버와 웹 브라우저 간에 상태 정보를 저장하는 작은 데이터 조각입니다. 웹 서버는 클라이언트에게 쿠키를 보내고, 클라이언트는 이를 저장합니다. 그리고 이후에 같은 서버로 다시 요청을 보낼 때마다 해당 쿠키를 함께 전송합니다.

쿠키는 주로 세션 관리, 개인화된 경험 제공, 사용자 추적 및 기타 웹 사이트의 필요한 정보 저장 등 다양한 용도로 사용됩니다. 일반적으로 쿠키에는 다음과 같은 정보가 포함될 수 있습니다:

  • 세션 관리: 세션 ID와 같은 인증 정보를 저장하여 사용자의 로그인 상태를 유지합니다.
  • 사용자 설정: 사용자가 웹 사이트에서 설정한 환경 설정이나 선호도와 같은 정보를 저장합니다.
  • 트래킹: 사용자의 행동을 추적하고 분석하기 위해 사용될 수 있습니다.
  • 장바구니: 온라인 쇼핑 사이트에서 사용자의 장바구니에 담긴 상품 정보를 저장합니다.

브라우저는 쿠키를 일반적으로 디스크에 저장하는데, 이를 통해 사용자가 웹 사이트를 떠나고 나중에 돌아왔을 때에도 이전에 설정된 쿠키가 유지될 수 있습니다. 그러나 브라우저의 정보를 초기화하면 이러한 쿠키 데이터도 함께 삭제됩니다.

세션(session)

세션(session)은 웹 애플리케이션에서 사용자의 상태를 유지하기 위한 메커니즘입니다. HTTP 프로토콜은 기본적으로 stateless(무상태)이므로, 사용자의 상태를 유지하는 데 어려움이 있습니다. 세션은 이러한 문제를 해결하기 위해 도입된 개념입니다.

세션은 일반적으로 서버 측에서 사용자의 상태 정보를 저장하고, 클라이언트에게 세션 ID를 부여합니다. 사용자가 서버에 요청을 보낼 때마다 세션 ID를 함께 전송하여 서버가 해당 사용자를 식별하고 이전 요청에서 저장된 상태 정보를 가져올 수 있습니다.

세션은 보통 다음과 같은 상황에서 사용됩니다:

  • 인증: 사용자 로그인 상태를 유지하고 로그인 정보를 저장합니다.
  • 상태 유지: 사용자의 활동 상태를 추적하고 장바구니, 임시 데이터 등의 정보를 저장합니다.
  • 보안: 중요한 정보를 클라이언트에 저장하는 것보다 서버 측에 저장하여 보안을 강화합니다.

쿠키 vs 세션

이론적으로는 쿠키에 모든 정보를 담고 있다면 세션이 필요 없을 것입니다. 그러나 실제로는 다음과 같은 이유로 세션이 여전히 사용됩니다:

  • 보안: 쿠키는 클라이언트 측에서 관리하므로 보안에 취약할 수 있습니다. 반면에 세션은 서버에서 관리되기 때문에 보안적으로 더 안전합니다. 중요한 정보나 인증 토큰과 같은 민감한 데이터를 쿠키에 저장하는 대신 세션에 저장하여 보안을 강화할 수 있습니다.
  • 용량 제한: 쿠키에는 일반적으로 용량 제한이 있습니다. 브라우저마다 쿠키의 최대 크기가 다르지만, 대부분의 경우 작은 용량으로 제한됩니다. 따라서 많은 양의 데이터를 저장해야 하는 경우 세션을 사용하는 것이 더 효율적입니다.
  • 사용자 경험: 세션을 사용하면 사용자가 로그인한 상태를 유지할 수 있으며, 이를 통해 사용자 경험을 향상시킬 수 있습니다. 사용자가 웹 사이트를 떠나더라도 세션을 유지하여 재방문 시 로그인을 다시 요청하지 않아도 됩니다.

쿠키와 세션은 용도에 맞게 사용되며, 같이 사용할 수도 있습니다. 예를 들어, 쿠키에 세션 ID를 저장하여 필요할 때마다 서버로부터 세션 정보를 가져올 수 있습니다.

OAuth(Open Authorization)

OAuth(Open Authorization)는 웹 및 모바일 애플리케이션을 위한 개방형 표준 인증 프로토콜입니다. OAuth는 보안을 강화하고 사용자의 리소스에 대한 제어를 사용자에게 부여함으로써 개인정보 보호를 강화하는 데 도움이 됩니다. 또한 OAuth를 통해 사용자가 여러 애플리케이션을 사용할 때마다 각 애플리케이션에 사용자 이름과 비밀번호를 제공하지 않고도 로그인할 수 있습니다.

일반적으로 OAuth는 다음과 같은 시나리오에서 사용됩니다:

  • 사용자 인증: 사용자는 애플리케이션에 로그인할 때 OAuth를 사용하여 자신의 신원을 확인합니다.
  • 권한 부여: 사용자는 애플리케이션이 특정 리소스(예: 프로필 정보, 연락처, 이미지 등)에 액세스할 수 있는 권한을 부여합니다.
  • 액세스 토큰 발급: 인증 서버는 사용자의 동의를 받은 후, 애플리케이션에 대한 액세스 토큰을 발급합니다.
  • 액세스 토큰을 사용한 리소스 액세스: 애플리케이션은 발급받은 액세스 토큰을 사용하여 사용자의 리소스에 액세스하고 작업을 수행합니다.

액세스 토큰

액세스 토큰(Access Token)은 사용자의 인증 상태를 나타내는 문자열입니다. 사용자가 성공적으로 인증되면 인증 서버에서 액세스 토큰이 발급됩니다. 이 토큰은 보통 짧은 기간(일반적으로 몇 시간) 동안 유효하며, 애플리케이션이 특정 API를 사용하거나 사용자의 리소스에 대한 작업을 수행하는 데 사용됩니다. 액세스 토큰을 통해 인증된 사용자에게만 특정 리소스에 대한 액세스 권한이 부여됩니다.

리프레시 토큰

리프레시 토큰(Refresh Token)은 액세스 토큰의 갱신을 위해 사용됩니다. 일반적으로 액세스 토큰은 유효 기간이 짧기 때문에, 유효 기간이 만료되면 새로운 액세스 토큰을 얻기 위해 리프레시 토큰이 사용됩니다. 리프레시 토큰은 일반적으로 긴 유효 기간을 가지며, 리프레시 토큰을 사용하여 액세스 토큰을 갱신하면, 사용자는 로그인 상태를 유지한 채로 애플리케이션을 계속 사용할 수 있습니다. 리프레시 포튼은 보안적인 이유로 사용자의 기기에 저장되어야 합니다.

JWT

**JWT (JSON Web Token)**는 JSON 포맷을 사용하여 정보를 안전하게 표현하고 전송하기 위한 개방형 표준(RFC 7519)입니다. JWT는 주로 인증 및 권한 부여 목적으로 사용되며, 액세스 토큰으로 자주 활용됩니다.

장점

  • 확장성: 상태 비저장이므로 서버 확장이 쉽습니다.
  • 보안: 서명으로 무결성을 보장합니다.
  • 효율성: 페이로드에 필요한 정보를 포함하므로 추가 조회가 필요 없습니다.

단점

  • 크기: JWT는 자체적으로 정보를 포함하므로 크기가 클 수 있습니다.
  • 무효화 어려움: 한 번 발급된 JWT는 만료 전까지 무효화하기 어렵습니다.
  • 보안 위험: 서명이 유출되면 토큰이 위조될 위험이 있습니다.

JWT는 세 부분으로 구성된 문자열입니다. 세 부분을 Base64Url로 인코딩한 뒤, 점(.)으로 연결하여 최종 JWT가 만들어집니다.

Header

JWT의 타입과 서명 알고리즘 정보를 포함합니다.

  • alg: 서명에 사용된 알고리즘 (예: HS256, RS256)
  • typ: 토큰의 타입 (일반적으로 JWT)
{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (페이로드)

사용자 정보 및 클레임(Claims)을 담고 있는 부분입니다. 클레임은 JWT에서 데이터를 표현하는 방식이며, 크게 세 가지로 나뉩니다:

  1. 등록된 클레임 (Registered Claims):
    • 사전에 정의된 표준 클레임.
    • 예: iss (발급자), sub (주제), aud (대상), exp (만료 시간), iat (발급 시간).
  2. 공개 클레임 (Public Claims):
    • 사용자 정의 데이터.
    • 예: 사용자 이름, 이메일 등.
  3. 비공개 클레임 (Private Claims):
    • 발급자와 소비자 간에 정의된 데이터.
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1672531200
}

Signature (서명)

JWT의 무결성을 보장하는 부분입니다. 헤더와 페이로드를 합친 후 비밀 키를 사용하여 서명을 생성합니다.

서명 생성 방식:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

세션 vs JWT

특징 세션 JWT
상태 관리 서버에서 상태 저장 클라이언트가 상태 정보 포함
확장성 서버 부담 증가 서버 부담 적음, 분산 시스템 적합
보안 세션 ID 보호 필요 서명으로 위조 방지, 민감 정보 주의
유효성 관리 서버에서 세션 만료 처리 가능 토큰 만료 전까지 유효
사용 사례 전통적인 웹 애플리케이션 RESTful API, 모바일/분산 환경

세션을 사용하는 것이 적합한 경우

  1. 상태를 서버에서 관리해야 하는 경우:
    • 서버에서 세션을 관리하고, 유효성을 제어하기 쉬운 구조가 필요할 때.
    • 예: 전통적인 웹 애플리케이션, 서버에서 사용자 상태를 자주 업데이트하거나 확인해야 하는 경우.
  2. 보안이 중요한 경우:
    • 세션은 서버에서 상태를 관리하므로, 민감한 정보를 클라이언트에 노출하지 않습니다.
    • 예: 민감한 금융 서비스나 내부 애플리케이션.
  3. 사용자 수가 적거나 서버 확장이 필요하지 않은 경우:
    • 서버가 충분한 리소스를 가지고 있고, 세션 저장소 관리가 간단한 경우.

JWT를 사용하는 것이 적합한 경우

  1. 확장성과 분산 시스템이 중요한 경우:
    • JWT는 클라이언트에 상태를 저장하므로, 서버 간 상태 동기화가 필요하지 않습니다.
    • 예: 마이크로서비스 아키텍처, 서버리스 환경, 글로벌 사용자 기반.
  2. RESTful API 또는 모바일 환경:
    • 클라이언트가 API를 호출할 때마다 상태를 서버에 저장하지 않고도 인증을 유지할 수 있습니다.
    • 예: 모바일 앱, SPA(Single Page Application).
  3. 서버 부담을 줄이고 싶을 때:
    • 세션 저장소를 유지하지 않아도 되므로 서버 리소스가 절약됩니다.
  4. 토큰 기반 인증이 필요한 경우:
    • JWT는 자체적으로 인증 정보를 포함하므로, 외부 인증 시스템과 통합하기 쉽습니다.

Log

Level

로그 레벨은 소프트웨어 개발 및 운영에서 로그 메시지의 중요도를 분류하기 위해 표준화된 방식으로 사용됩니다.

  1. TRACE: 가장 세부적인 로그로, 프로그램의 실행 흐름을 상세히 기록합니다. 매우 세부적인 디버깅이 필요할 때 사용합니다.
  2. DEBUG: 디버깅 목적으로 사용되며, 개발 중에 주로 활성화합니다. 개발 중에 시스템의 동작을 확인할 때 사용합니다.
  3. INFO: 시스템의 정상적인 동작과 관련된 주요 이벤트를 기록합니다. 시스템 상태를 모니터링할 때 사용합니다.
  4. WARN: 문제를 일으킬 가능성이 있는 상황을 나타냅니다. 비정상적이지만 치명적이지 않은 문제를 기록할 때 사용합니다.
  5. ERROR: 심각한 문제를 나타내며, 예외 상황을 기록합니다. 복구가 필요한 치명적인 문제를 기록할 때 사용합니다.
  6. FATAL : 치명적인 오류를 기록하며, 프로그램이 종료될 수 있는 상황을 나타냅니다.

Frontend

프론트엔드는 웹 애플리케이션 또는 웹사이트의 사용자 인터페이스(UI)와 사용자 경험(UX)을 구축하는 영역을 말합니다. 이는 사용자가 직접 상호 작용하는 부분으로, 웹 페이지의 레이아웃, 디자인, 콘텐츠 표시 등을 담당합니다. 프론트엔드 개발자는 HTML, CSS, JavaScript 등을 사용하여 웹 페이지를 만들고, 이를 통해 사용자가 웹 애플리케이션과 상호 작용할 수 있도록 합니다.

최근에는 프론트엔드 개발에서도 다양한 프레임워크와 라이브러리가 등장하면서, 보다 효율적이고 강력한 웹 애플리케이션을 구축할 수 있게 되었습니다. 대표적으로 React, Angular, Vue.js 등이 있으며, 이들을 사용하면 웹 애플리케이션의 개발과 유지 보수가 더욱 용이해집니다.

Backend

백엔드는 웹 애플리케이션 또는 웹사이트의 뒷단을 담당하는 영역을 의미합니다. 사용자가 웹 페이지에서 요청하는 작업을 처리하고, 데이터베이스와 상호 작용하여 필요한 정보를 제공합니다. 이러한 작업들은 사용자에게는 보이지 않지만, 웹 애플리케이션의 핵심적인 기능과 데이터 처리를 담당합니다.

백엔드 개발은 다양한 프로그래밍 언어와 프레임워크를 사용하여 이루어집니다. 주로 사용되는 언어로는 Python, Java, Ruby, PHP, JavaScript(Node.js) 등이 있으며, 이들 언어를 기반으로 하는 다양한 프레임워크와 라이브러리가 개발되어 백엔드 개발을 보다 효율적으로 할 수 있게 됐습니다.

백엔드 개발자는 클라이언트의 요청을 받아들이고, 그에 맞게 서버 측에서 데이터 처리, 비즈니스 로직 실행, 데이터베이스 조회 및 업데이트 등을 수행합니다. 또한 보안, 성능 최적화, 사용자 인증 및 권한 부여와 같은 측면도 백엔드 개발자가 고려해야 할 중요한 요소입니다.

SSH

SSH(Secure Shell)는 네트워크 상에서 두 컴퓨터 간에 안전하게 통신할 수 있도록 해주는 보안 프로토콜입니다. 주로 원격 서버에 접속하여 명령을 실행하거나 파일을 전송할 때 사용되며, 암호화를 통해 데이터를 안전하게 보호합니다. SSH는 서버 관리와 유지보수에 중요한 역할을 하며, 서버에 대한 원격 접속을 가능하게 해줍니다.

  • 원격 로그인: 로컬 컴퓨터에서 원격 서버로 안전하게 접속해 명령어를 실행할 수 있습니다. 예를 들어, 웹 서버나 데이터베이스 서버의 설정을 수정할 때 사용됩니다.
  • 파일 전송: SSH를 사용해 파일을 안전하게 전송할 수 있습니다. 이때 많이 사용되는 도구로는 scp (secure copy)나 rsync가 있습니다.
  • 포트 포워딩: SSH를 통해 특정 포트를 터널링하여 외부 네트워크와의 안전한 통신을 할 수 있습니다. 이를 SSH 터널링이라고 부르며, 보안이 필요한 상황에서 많이 사용됩니다.
  • 암호화된 통신: SSH는 암호화를 사용해 데이터가 중간에 도청당하거나 변조되지 않도록 보호합니다. 대칭 키와 비대칭 키 암호화를 결합하여 통신을 안전하게 유지합니다.
  • 키 기반 인증: SSH는 암호 대신 공개 키 기반의 인증 방식을 제공합니다. 이는 비밀번호보다 보안성이 높으며, 공개 키와 개인 키 쌍을 사용해 사용자를 인증합니다.

UUID

**UUID (Universally Unique Identifier)**는 전 세계에서 고유한 값을 생성하기 위한 표준 형식입니다. UUID는 주로 데이터베이스, 분산 시스템, 네트워크, 파일 시스템 등에서 고유한 식별자가 필요할 때 사용됩니다. UUID는 128비트 크기를 가지며, 이를 16진수로 표현한 32개의 문자로 구성됩니다.

  1. 고유성 (Uniqueness): UUID는 매우 높은 확률로 고유한 값을 생성합니다. 이를 통해 다른 시스템 간에 충돌 없이 고유한 식별자를 생성할 수 있습니다.
  2. 전 세계적으로 고유: UUID는 시간, 머신 정보, 랜덤 값 등을 기반으로 생성되기 때문에, 서로 다른 시스템에서 생성된 UUID도 충돌하지 않습니다.
  3. 표준화: UUID는 RFC 4122에 의해 정의된 표준 형식으로, 다양한 언어나 시스템에서 동일한 방식으로 생성됩니다.

UUID는 일반적으로 32개의 16진수 숫자와 4개의 하이픈으로 구분된 5개의 부분으로 이루어져 있습니다:

123e4567-e89b-12d3-a456-426614174000

UUID의 사용 사례:

  1. 데이터베이스의 기본 키: UUID는 고유한 식별자가 필요할 때, 특히 분산 시스템에서 유용합니다.
  2. 세션 식별자: 웹 애플리케이션에서 사용자 세션을 추적할 때 UUID를 사용하여 고유한 세션 ID를 생성합니다.
  3. 파일 식별자: 파일 시스템에서 파일 이름을 고유하게 생성하거나, 분산 파일 시스템에서 파일을 식별하는 데 사용됩니다.
  4. API 키 및 토큰: 인증 및 권한 부여 시스템에서 고유한 API 키나 인증 토큰을 생성할 때 UUID를 사용합니다.

환경 변수

환경 변수는 운영 체제에서 실행 중인 프로세스가 사용할 수 있는 동적인 값입니다. 시스템 설정, 애플리케이션 구성, 또는 실행 환경에 대한 정보를 저장하는 데 사용됩니다.

환경 변수는 키-값(Key-Value) 쌍으로 구성되며, 운영 체제에서 전역적으로 접근하거나 특정 프로세스에서만 사용할 수 있습니다.

  1. 전역 접근 가능: 환경 변수는 시스템 전역적으로 설정되며, 해당 값을 모든 프로세스에서 사용할 수 있습니다.
  2. 키-값 쌍: 각 환경 변수는 고유한 이름(키)과 값으로 구성됩니다.
  3. 동적 변경 가능: 시스템 실행 중에도 값을 변경하거나 추가할 수 있습니다.
  4. 보안: 민감한 정보를 코드 대신 환경 변수에 저장하여 보안을 강화할 수 있습니다.

환경 변수의 주요 용도

  1. 시스템 구성:
    • 운영 체제에서 사용하는 기본 디렉토리, 실행 경로, 언어 설정 등을 정의.
    • 예: PATH, HOME, TEMP.
  2. 애플리케이션 설정:
    • 데이터베이스 URL, API 키, 포트 번호와 같은 설정 정보를 저장.
    • 예: DB_URL, API_KEY, PORT.
  3. 환경 분리:
    • 개발, 테스트, 프로덕션 환경에서 다른 설정 값을 사용할 수 있도록 지원.
    • 예: ENV=development 또는 ENV=production.
  4. 비밀 정보 관리:
    • 비밀번호, 토큰, 인증 키와 같은 민감한 정보를 코드에서 분리.

서버 렌더링

**서버 렌더링(Server-Side Rendering, SSR)**은 웹 애플리케이션에서 HTML 콘텐츠를 서버에서 생성하여 클라이언트(브라우저)로 전송하는 방식을 말합니다. 서버가 요청을 받으면 필요한 데이터를 기반으로 HTML 페이지를 완성하고, 브라우저는 이를 받아 사용자에게 표시합니다.

서버 렌더링은 SEO 최적화와 빠른 초기 로드가 중요한 프로젝트에 적합하며, 클라이언트 렌더링과 함께 사용해 하이브리드 구조를 구현할 수도 있습니다.

  1. SEO(검색 엔진 최적화)
    • 검색 엔진은 서버에서 생성된 HTML 콘텐츠를 쉽게 크롤링할 수 있습니다.
    • 클라이언트 렌더링보다 SEO에 유리합니다.
  2. 빠른 초기 로드
    • 브라우저가 완성된 HTML을 받아 즉시 렌더링할 수 있으므로 초기 로드 시간이 빠릅니다.
  3. 간단한 구현
    • JavaScript 프레임워크를 사용하지 않고도 서버에서 HTML을 생성할 수 있어 구현이 간단합니다.
  4. 일관된 데이터 처리
    • 서버에서 모든 데이터를 처리하므로 보안이 강화되고, 클라이언트에서의 데이터 누락 가능성이 줄어듭니다.

과정

  1. 클라이언트 요청
    • 사용자가 브라우저에서 URL에 접근하거나 특정 요청을 보냅니다.
  2. 서버 처리
    • 서버는 요청을 받아 필요한 데이터를 데이터베이스나 외부 API에서 가져옵니다.
    • 데이터를 템플릿 엔진(예: Thymeleaf, JSP, Handlebars)을 사용해 HTML 페이지에 삽입합니다.
  3. 완성된 HTML 반환
    • 서버는 완성된 HTML을 클라이언트로 전송합니다.
  4. 클라이언트 표시
    • 브라우저는 받은 HTML을 렌더링하여 사용자에게 페이지를 보여줍니다.

서버 렌더링(Server-Side Rendering, SSR)은 전통적으로 백엔드의 영역에 속하지만, 프론트엔드와 밀접하게 관련된 작업입니다. SSR이 브라우저에서 렌더링될 HTML을 생성하고, 사용자가 보는 UI를 결정하기 때문입니다. 어떤 기술 스택을 사용하는지에 따라 프론트엔드와 백엔드 중 누가 더 많은 책임을 가지는지가 달라집니다.

  • 전통적인 서버 렌더링(Java + Thymeleaf, Django 등): 백엔드 주도.
  • 현대적인 SSR(Next.js, Nuxt.js 등): 프론트엔드 개발자가 주도.

더티 쓰기

**더티 쓰기(Dirty Write)**는 데이터베이스나 객체 관계 매핑(ORM)에서 변경된 데이터가 저장되었을 때, 실제로 변경된 내용만 반영하는 것이 아니라 불필요한 데이터까지 저장되는 현상을 의미합니다. 즉, 객체의 상태가 변경되면 그 객체가 연결된 데이터베이스 테이블의 모든 필드가 업데이트되는 방식입니다. 더티 쓰기는 ORM의 편리함을 제공하지만, 성능에 영향을 미칠 수 있습니다.

  1. 객체의 상태 변경 추적:
    • ORM은 객체를 데이터베이스 테이블과 매핑하여 객체의 상태를 추적합니다. 객체의 상태가 변경되면, ORM은 해당 객체를 "더티(Dirty)" 상태로 표시하고, 이를 저장할 때 모든 변경된 필드를 데이터베이스에 반영합니다.
  2. 불필요한 업데이트:
    • 객체의 일부 필드만 변경되었더라도, ORM은 객체 전체를 저장하려고 할 수 있습니다. 예를 들어, 객체의 일부 필드만 수정되었는데, ORM은 해당 객체의 모든 필드를 업데이트하려고 할 수 있습니다.
  3. 자동으로 처리되는 경우:
    • JPA와 같은 ORM에서는 객체의 상태가 변경되면 이를 자동으로 추적하고, save(), flush() 등을 호출하면 변경된 내용을 자동으로 데이터베이스에 반영합니다. 이때 객체의 상태가 "더티"로 표시되며, 해당 객체의 모든 변경 사항이 데이터베이스에 반영됩니다.

예를 들어, User 객체가 있고 이 객체의 name과 email 필드가 있습니다. 만약 name만 수정되었다면, email은 변경되지 않았지만 ORM은 객체를 저장할 때 name과 email 모두를 업데이트하려고 할 수 있습니다. 이렇게 되면 email 필드는 실제로 변경되지 않았음에도 불구하고 불필요하게 데이터베이스에 저장됩니다. 이 현상이 바로 더티 쓰기입니다.

더티 쓰기의 장점:

  • 간편함: ORM이 객체의 상태를 자동으로 추적하고, 변경된 내용을 데이터베이스에 반영하므로 개발자가 일일이 SQL을 작성할 필요가 없습니다.
  • 자동화: 객체의 상태가 변경되면 ORM이 이를 자동으로 반영하므로 개발자가 수동으로 업데이트 쿼리를 작성할 필요가 없습니다.

더티 쓰기의 단점:

  • 불필요한 업데이트: 객체의 일부 필드만 변경되었는데, 전체 객체가 업데이트되므로 불필요한 데이터베이스 쓰기 작업이 발생할 수 있습니다. 이는 성능 저하를 초래할 수 있습니다.
  • 성능 문제: 객체가 매우 크거나, 많은 필드를 가지고 있는 경우, 불필요한 필드까지 업데이트되면 성능에 부정적인 영향을 미칠 수 있습니다.