Simple Mathematical Model (1)

인공 세포의 구조

입력 X → 연결 강도 W → Cell Body F → 출력 Y

• Cell body에서는 두가지 일이 발생한다.
  1. Summation (Signal 저장)
  2. Threshold 기준으로 output 결정
     1. Summation > 0 → 1
     2. Summation ≤ 0 → 0

Simple Mathematical Model (2)

1. Summation

• Weighted summation of inputs - 입력과 Weight를 곱해서 모두 더한다.

2. Non-linear threshold

• Summation을 하다가 threshold을 넘으면 output을 내게 된다.

  • 보통 threshold를 0으로 설정한다.

  • 그래프에서 S는 Summation이다.

    ⇒ 즉 S가 0을 넘게되면 1을 output으로 내게된다.

• 입력 (X)
• Connection Weignt (W)
  • scale factor
  • connection weight가 높으면 signal이 잘 전달됨.
  • connection weight가 작으면 signal이 잘 전달 안됨.
• Cellbody
  • Summation
  • Activation Function (F)
    • 판단함수 - S값의 결과를 기준으로 출력을 낼지 말지를 결정한다.

Simple Mathematical Model (3)

만들어진 뇌세포들을 모두 연결 하면 뇌가 만들어진다!

• Input X
• Connection Weight W
• 각 노드에서: Summation → Activate

Neural Network 구조

• 뇌세포 존재
• 뇌세포들이 Connection으로 이어져 있음
• 각 연결에 Connection Weight가 존재
• 각세포들의 입력 * Weight Summation → Activate
• 출력

Neural Network가 할 수 있는 것?

Pentinum(Digital Computer)가 할 수 있는 모든 것!

What a Perceptron Can Do?

• Neural Network를 바로 분석하는 것은 복잡하니, 뇌세포 하나에 먼저 집중

• Perceptron

  • Perception: 인지
  • Electron: 전자

• 입력1: X1

• 입력2: X2

• 입력3: 1

  • Bias 라고 함.
  • 입력3은 1로 고정임.
  • Bias는 경계에 큰 자유도를 부여한다.
  • Bias가 사라지면? → Neural Network의 성능이 안좋아진다.
    • 원점을 지나는 경계가 된다.
    • X1W1 + X2W2 = 0
    • 경계가 원점을 지나게 되면 Neural Network의 성능이 비효율적이게 된다.

• W1, W2, W3

  • 상수
  • 경계를 의미한다.

X1과 X2로 이루어진 input space 에서

경계의 위쪽 값은 1을 출력하고, 경계의 아래쪽은 0을 출력하게 된다.

즉, Perceptron은 Linearly Separable Problems를 해결한다!

AND Operation

• Perceptron이 W 값을 결정하니까 AND 연산이 가능함.
• 1: True
• 0: False
• 빨간 점과 파란점을 구분하는 선을 찾아야 함. (이 선은 무한이 많이 존재)

OR Operation

NOT Operation

결론

Neural Network는 Digital Circuit, 즉 CPU까지 만들 수 있음 → 디지털 컴퓨터가 할 수 있는 모든 일은, Neural Network도 그 이상으로 가능하다.

• AND와 OR의 차이는 Connection Weight만 바뀌고 있다는 점이다.

  • Neuron 은 고정 (하드웨어, 껍데기)

  • Connection Weight (프로그램, 기능)만 바꿔주면 연산이 변경된다. ⇒ Neuron의 기능이 바뀐다.

    즉, W를 어떻게 설정하느냐가 가장 중요하다! W를 설정하는 과정을 “학습” 이라고 한다. 자동 설정, 내가 계산하는 것이 아닌, Neural Network이 알아서 계산하는 것이 Neural Network의 장점.

What a Neural Network Can Do?

Neural Network 는 non-linearly separable problems 을 해결할 수 있다.

XOR Operation

• 직선으로는 빨강색, 파란색 구분이 안된다. ⇒ non-linearly separable problem
• 즉, Neuron이 아니라, Neuron Network를 활용해야한다.
• Neuron은 직선문제만 해결 가능.
• 1번 연산: AND Gate
• 2번 연산: OR Gate
• 최종 연산: XOR GATE

Multilayer Perceptron

• Signal은 앞 → 뒤 의 방향으로만 진행해야한다.
• 단, 빨간색 방향은 가능
• 현재 그림은 2Layer Structure 이다.
• 보통 2~3 Layer는 Shallow Nerwork이라고 한다.
• 보통 4 Layer부터 Deep Neural Network이라고 한다.

Multilayer Perceptron의 구조

• Input Layer ↔ Hidden Layer ↔ Output Layer

노드 개수

• Input Layer ↔ Hidden Layer 노드 개수
  • input과 output의 노드 개수를 설정하는 것은 내가 해결하고자 하는 “문제” 이다.
• Hidden Layer 노드 개수
  • 내가 결정하는 것이다.
  • 10, 100, 10000, …
  • 간단할 수록 노드 수가 적어도 되고, 복잡할 수록 노드 수가 많이 필요하다.
    • 이에 대한 기준은 존재하지 않은다.
    • 단, 그렇다면 노드 수가 많을 수록 좋은 것이 아닌가에 대한 질문에는 아니라고 답할 수 있다. → 왜냐하면 노드수가 너무 많아 똑똑한 Neuron Network에 단순한 문제를 주면 너무 과하게 생각해서 오류를 내뱉게 되기 때문이다.

레이어 개수

• Layer 수는 내 마음대로 설정할 수 있다.
• 간단할 수록 Layer 수가 적어도 되고, 복잡할 수록 Layer 수가 많이 필요하다.
• Layer를 많이 까는게 Node를 많이 까는 것보다 낫다.
• 단, 이것도 마찬가지로 무조건 많이 까는게 좋은 건 아니다.
• Q. 내가 어떤 문제를 풀 때 Layer를 몇개를 깔아야하는가? A. 답과 기준 모두 없다.
  • 단, 이론상 2Layer Structure면 Any Continuous function을 만들 수 있다.
  • 3 Layer Structure면 Any function을 만들 수 있다.

Deep Neural Network

• Deep은 상대적인 개념으로 Shallow와 반대되는 개념이다.
• Deep + Shallow = Neural Network = 뇌
• Neural = Neuron의 형용사형, 신경세포(뇌세포)

How They Are Different

AI / ML / Deep Neural Network

AI (인공지능)
├── RuleBasedAI
└── MachineLearning
    ├── SupervisedLearning
    ├── UnsupervisedLearning
    ├── ReinforcementLearning
    └── DeepLearning (머신러닝보다 사용빈도 수 매우 높음)

Big Data / AI

• Big Data
  • 데이터에 치중
  • 데이터를 다루고, 저장하고, 분석하는 것에 집중
• Machine Learning
  • data에서 유용한 패턴을 추출하거나 intelligent program을 어떻게 만들 것이냐에 집중

Some Types Of ML Problems 1 (문제의 종류들)

ML에서 90% 이상이 Classification과 Regression으로 구성되어 있다.

Classification

• Unknown Data → Cat or Dog? ⇒ N지 선다
• 사용 분야 Voice/Face/Fingerprint/Iris/DNA/Signature recognition, Recommendation, Spam filter, Credit card fraud detection

Regression

• Unknown Data → “수치값” 예측, ex. 고양이 몸무게 예측
• 사용 분야 Loan application analysis, Marketing, Stock market prediction

Clustering

• 사용분야 Web-search, Document & information retrieval, Machine translation

Dimension Reduction

Classification

• Classification 문제에서는 Labeled Data가 무조건 필수적으로 주어진다.

• 나의 프로그램에서는 labels의 경계를 찾아야한다.

• 질문이 주어지면, 나의 프로그램에서는 label을 답해야한다.

• Classification의 과정

  데이터 수집 → 학습 → 추론(활용)

  1. Data Collect (labeled data)

     • 아래와 같이 Label 작업을 해주어야 한다.

       (데이터, Label)
       (고양이 사진1, Cat)
       (강아지 사진1, Dog)
       (고양이 사진2, Cat)
       ...

  2. Training (학습 단계)

     • Deep Neural Network를 돌려서 Model을 생성한다.
     • 여기서 Model은 Cat, Dog Pattern을 알고 있다. ⇒ 즉 학습되어 있다.
     • 학습: Data Pattern을 모델이 외우는 것.

  3. Inference (추론 단계)

     • Unknown Data 입력 → model이 label 을 반환 해준다. (Cat or Dog )

Regression

• Classification과 구조가 동일하다.

• 차이점은 label 데이터가 이미지 등이 아닌 값인 것.

    (데이터, Label)
    (고양이1 몸무게, 40kg)
    (강아지1 몸무게, 30kg)
    (고양이2 몸무게, 10kg)
    ...

• Regression 문제에서는 Labeled Data가 무조건 필수적으로 주어진다.

  • (x, y) set (x: vetor, y: real number)

• Regression의 과정

  데이터 수집 → 학습 → 추론(활용)

Clustering

• Unlabeled data 가 주어진다.
• 내 프로그램은 데이터를 그룹화 한다.
• 질문이 주어지면, 질문이 어느 그룹에 속하는지 답변해주어야 한다.

Dimension Reduction

• Unlabeled data 가 주어진다.
• 내 프로그램은 정보의 손실을 줄이면 차원을 축소한다.

Supervised & Unsupervised Learning (ML 기법들)

Supervised Learning

• labeled dataset이 필요한 ML 알고리즘들
• 예시: Classification, Regression

Unsupervised Learning

• labeled dataset이 필요하지 않은 ML 알고리즘들
• 예시: Clustering, Dimension Reduction

https://www.youtube.com/watch?v=0Ssx7jJJADI

정의

분산 이벤트 스트리밍 플랫폼

⇒ 스트리밍을 처리하기 위한 플랫폼

• 고성능

카프카 개념

기본 구조 (구성요소)

1. 카프카 클러스터

• 메시지를 저장하는 저장소
• 데이터가 이동하는데 필요한 핵심 역할을 함
• 하나의 카프카 클러스터는 여러개의 브로커 로 구성이 됨.
  • 브로커
    • 각각의 서버로 보면 됨
    • 메시지를 나누어서 저장함
    • 이중화 처리도 함.
    • 장애가 나면 대체도 하고 그런 역할을 함.

2. 주키퍼 클러스터 (앙상블)

• 카프카 클러스터를 관리함.
• 카프카 클러스터 정보가 기록이 됨.

3. 프로듀서 (Producer)

• 카프카 클러스터에 메시지를 보냄.

4. 컨슈머 (Consumer)

• 메시지를 카프카에서 읽어옴.

토픽과 파티션

토픽

• 메시지를 저장하는 단위 ⇒ 메시지를 구분하는 용도로 사용함.
• 파일 시스템의 폴더와 유사한 개념
• 한 개의 토픽은 한 개 이상의 파티션으로 구성됨.

파티션

• 메시지를 저장하는 물리적인 파일을 의미.
• append-only 파일 ⇒ 추가만 가능한 파일

⇒ 프로듀서와 컨슈머가 토픽을 기준으로 메시지를 주고 받음

→ 프로듀서가 카프카에 저장할 때, 어떤 토픽에 메시지를 저장해달라고 요청

→ 컨슈머는 어떤 토픽에서 메시지를 읽어옴.

오프셋과 메시지 순서

• 오프셋은 각 메시지 저장 위치를 의미.
• 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가
• 컨슈머는 오프셋 기준으로 메시지를 순서대로 읽음
• 메시지는 삭제되지 않음 (설정에 따라 일정 시간이 지난 뒤 삭제

여러 파티션과 프로듀서

• 프로듀서는 라운드로빈 또는 키로 파티션을 선택해서 메시지를 저장한다. ⇒ 같은 키를 가지면, 같은 파티션에 저장이됨. ↔ 아니면 라운드로빈

여러 파티션과 컨슈머

• 컨슈머는 컨슈머 그룹에 속하게 됨.
• 한 개의 파티션은 컨슈머그룹의 한 개 컨슈머만 연결이 가능하다. ⇒ 즉, 하나의 컨슈머 그룹에 속한 컨슈머들은 한 파티션을 공유할 수 없다. ⇒ 이를 통해 하나의 컨슈머 그룹 기준으로 파티션 메시지는 순서대로 처리가 된다.

성능

• OS 페이지 캐시 사용
• Zero Copy
• 브로커가 컨슈머 추척을 위해 작업을 하지 않음 ⇒ 하는 일이 적음.
• 메시지를 묶어서 보내고, 묶어서 받을 수 있음 (batch) ⇒ 낱개 처리보다 처리량이 증가함.
• 처리량 증대(수평 확장)이 쉬움.
  • 1개의 장비의 용량 한계 ⇒ 브로커 추가, 파티션 추가하면 됨.
  • 컨슈머가 느림 ⇒ 컨슈머 추가하면 됨.

리플리카 - 복제 (고가용성)

• 리플리카: 파티션의 복제수
  • 복제수만큼 파티션의 복제본이 각 브로커에 생김
  • 리더와 팔로워 브로커로 구성 ⇒ 프로듀서와 컨슈머는 리더를 통해서만 메시지 처리함.
• 장애 대응용

Producer

• byte 배열로 변환
• 파티션 결정
• 버터에 배치로 메시지 저장 (성능이 좋은 이유)
• 배치 전송

sender

• sender는 별도 스레드로 동작
• 배치가 찾는지 여부와 관계 없이 브로커에 전송

전송 결과 확인 안함

전송 결과를 확인하기 위해서는

Future 사용

• 단점
  • 블로킹이 발생해서 배치가 1개씩밖에 못쌓임
    • 배치 효과가 떨어져서 처리량 저하
• 처리량이 낮아도 되는 경우에만 사용

Callback 사용

• 처리량 저하 없음

전송 보장과 ACK

• ACK = 0
  • 전송 보장 X
• ACK = 1
• ACK = all (-1)
  • 전송 보장 O

에러 유형

• 전송 과정에서 실패
• 전송 전에 실패

실패 대응

• 재시도 (무한 재시도 X)
  • 브로커 응답이 늦게와서 중복 전송될 가능성이 있음.
  • 순서가 바뀔수도 있음.
• 기록

Consumer

특정 토픽의 파티션에서 레코드를 조회하는 역할을 함.

• 메시지 읽어 옴 → 역직렬화 → 카프카 컨슈머 객체 생성 → 내가 구독할 토픽을 전달
• 토픽 파티션은 그룹 단위로 할당됨.
• 파티션보다 컨슈머가 더 많이 생성되면 노는 컨슈머가 생길 수 있음 ⇒ 컨슈머 개수가 파티션 개수보다 커지면 안됨!!
  • 만약 처리 속도가 느려져서 컨슈머 수를 늘린다면, 파티션의 수도 같이 늘려줘야함.

커밋과 오프셋

컨슈머는 읽다가, 마지막 offset commit함.

다음에는 이 offset부터 읽음

컨슈머는 스레드로 사용하면 안됨!

요즘 PR 올리기 전 커밋 메시지 쓰기랑 코드리뷰 체크리스트 돌리기가 은근 시간을 많이 잡아먹는다. 그래서 “내가 하는 반복 작업을 AI에게 넘기자”라는 목표로 다음을 자동화했다.

• git diff --staged 기반으로 커밋 메시지(제목+본문) 자동 생성
• 브랜치/베이스 기준 diff 기반으로 AI 코드리뷰 생성
• 생성된 코드리뷰를 Notion DB에 자동 저장(검색/축적)

결론부터 말하면, 룰만 잘 잡아두면 “작성/검수” 시간을 꽤 줄여준다. 특히 리뷰 포맷을 강하게 강제하면 결과물이 안정적으로 나온다.

목표

1) 커밋 메시지 자동 생성

• 입력: git diff --staged, git diff --staged --name-status, 현재 브랜치명

• 출력: 바로 붙여넣어 git commit 할 수 있는 커밋 메시지 텍스트

• 브랜치명에서 JIRA 키 추출: ([A-Z][A-Z0-9]+-\d+)

  • 있으면 [JIRA-123]
  • 없으면 [NO-TICKET]

2) 코드리뷰 자동 생성 + Notion 저장

• 입력: git diff base...HEAD 또는 git diff --staged

• 출력: 한국어로 된 리뷰 결과(Blocking/Recommended/Suggestion/TechDebt)

• Notion API로 페이지 생성

  • 마크다운 → Notion 블록 변환(heading, code, list, table 지원)
  • Notion rich_text 2000 UTF-16 유닛 제한 대응
  • children 100개 제한 대응(append patch)

전체 구조

내가 만든 스크립트는 크게 두 개다.

1. 코드리뷰 스크립트

• diff 만들기(경로 포함/제외 지원)
• diff가 없으면 옵션에 따라 파일 내용을 읽어서 정적 리뷰로 대체
• OpenAI Responses API로 리뷰 생성
• Notion DB에 저장

2. 커밋 메시지 생성 스크립트

• staged diff를 읽고
• 브랜치에서 JIRA 키 뽑아서 prefix 결정
• OpenAI로 커밋 메시지 생성
• stdout에 메시지 텍스트만 출력(복붙용)

1) 커밋 메시지 자동 생성: 스테이징 기반

핵심 아이디어

• 커밋 메시지는 staged diff 기준으로 만들어야 “실제로 커밋되는 내용”과 1:1로 맞는다.

• diff만 주는 것보다 --name-status도 같이 주면 요약 품질이 좋아진다.

• 출력 포맷을 강제한다:

  • 제목 1줄 + 빈 줄
  • 고정 섹션: 변경 요약 / 테스트 / 리스크·롤백
  • 불확실하면 (추정) 표시

예시 사용

git add .
python ai_commit_message.py > /tmp/msg.txt
git commit -F /tmp/msg.txt

또는

python ai_commit_message.py | git commit -F -

좋은 점

• 제목 prefix가 자동으로 통일된다. ([JIRA-123] or [NO-TICKET])
• “테스트 했는지”를 본문에 강제해서, 커밋 로그만 봐도 히스토리 품질이 올라간다.

주의할 점

• AI가 “테스트 실행 여부”를 모를 때가 많아서 (추정)을 반드시 붙이게 만든 건 잘한 선택이었다.
• diff가 너무 크면 입력이 폭주하니 MAX_CHARS로 잘라야 한다(스크립트에서 이미 처리).

2) 코드리뷰 자동 생성: diff 기반 + Notion 저장

어떤 입력을 주는가?

• 기본은 git diff origin/develop...HEAD
• 옵션으로 staged만 리뷰할 수도 있다: --staged
• 특정 경로만 리뷰: --path src --path apps/api
• 제외 경로: --exclude node_modules --exclude dist

추가로, diff가 비었을 때:

• --review-files 옵션을 주면 diff 대신 파일 내용을 읽어서 정적 리뷰(구조/보안/테스트/개선점)를 돌린다.

출력 포맷 강제

리뷰는 이 포맷이 핵심이다. 표 형태로, 분류별로, 이슈당 1행. 이걸 강제하면 Notion에 저장해도 읽기 좋고, 나중에 검색도 쉽다.

• 요약 테이블

• 4개 섹션

  • 🚫 Blocking Issues
  • ⚠️ Recommended Changes
  • 💡 Suggestions
  • 📝 Tech Debt

각 섹션에 같은 표 헤더: | 위치 | 문제 설명 | 권장 수정 | 이유 |

이렇게 하면 “좋은 말 잔뜩”이 아니라, 조치 가능한 리뷰가 된다.

3) Notion에 자동 적재: “리뷰를 쌓아두는” 이유

코드리뷰를 그냥 stdout으로 찍어두면 그 순간엔 편한데, 시간 지나면 사라진다.

Notion DB에 쌓아두면 좋은 점:

• 특정 레포/브랜치/포커스(security/performance 등) 기준으로 모아보기 쉽다
• 반복적으로 나오는 리뷰 패턴(테스트 부재, 에러 처리 부족 등)을 통계/회고에 활용 가능
• PR 올리기 전에 “AI 리뷰 링크”를 붙여서 팀 커뮤니케이션에도 쓸 수 있다

구현 디테일 (중요한 제한들)

Notion API는 생각보다 제약이 많다.

• rich_text는 블록당 길이 제한이 있다(UTF-16 유닛 기준)
• children은 한 번에 최대 100개
• 마크다운 표를 그대로 넣기 어렵다 → table block으로 변환

그래서 스크립트에서:

• UTF-16 유닛 기준 split 함수로 텍스트를 잘라 rich_text를 나눔
• 100개 넘으면 append API로 추가
• 마크다운을 heading/code/list/table/paragraph로 변환

이 부분이 “작동은 하는데 깨끗하게 작동하게 만들기”에서 제일 시간을 잡아먹었다.

실제 워크플로우 예시

커밋 메시지

1. 작업 후 git add
2. python ai_commit_message.py 실행
3. 생성된 메시지를 그대로 커밋에 사용

코드리뷰 + Notion 저장

1. PR 올리기 전, 또는 브랜치 정리 타이밍에
2. python ai_review_to_notion.py --base origin/develop --path src --exclude dist -v
3. Notion 페이지 링크가 나오면 끝

내가 느낀 장점 / 한계

장점

• “작성”과 “검수”의 초기 비용이 확 줄어든다
• 리뷰 포맷이 표준화되면서 팀 내 커뮤니케이션 품질이 좋아진다
• Notion에 쌓이면서, 프로젝트의 기술부채/반복 이슈가 눈에 보인다

한계(중요)

• AI는 맥락을 모르면 틀릴 수 있다 → 그래서 리뷰 규칙에 불확실하면 ‘추정’ 표시 + 확인 포인트를 넣은 게 핵심
• 큰 diff는 품질이 떨어진다 → diff를 작은 단위로 나누거나, path를 제한해서 돌리는 게 낫다
• 보안/아키텍처처럼 “조직 정책”이 필요한 부분은 → 프롬프트에 팀 룰(예: logging 정책, error code 규칙)을 추가해야 정확해진다

개선 아이디어 (다음 단계)

내가 다음으로 넣고 싶은 것들:

• PR 템플릿 자동 생성: 커밋/리뷰 결과를 합쳐서 PR 본문 초안 만들기
• 리뷰 결과를 lint처럼 fail 조건으로 사용: Blocking N개 이상이면 CI에서 경고
• 리포트 요약 통계: Notion DB에서 “가장 자주 나온 이슈 Top10” 뽑기
• diff chunking: 대형 diff를 파일 단위로 쪼개서 품질 유지

마무리

이 방식의 핵심은 “AI가 다 해준다”가 아니라,

• 입력은 최대한 사실 기반(diff, name-status, 파일 내용)으로
• 출력은 최대한 구조적으로(표/고정 섹션)
• 불확실성은 표기(추정 + 확인 포인트)

이 3가지를 강제하는 거였다.

AI를 잘 쓰면, 개발 속도를 올리는 가장 쉬운 방법 중 하나가 “사람이 하기엔 귀찮은 반복 작업을 넘기는 것”이라고 느꼈다.

InnoDB

InnoDB는 트랜잭션, 외래 키 제약조건, MVCC를 지원하며 행 단위 락을 사용하여 데이터 무결성과 동시정을 보장한다. (MVCC: 다중버전동시성제어)

• MySQL의 기본엔진으로, 주로 데이터 무결성과 트랜잭션이 중요한 시스템에서 사용된다.

MyISAM

MyISAM은 트랜잭션과 외래 키를 지원하지 않고, 테이블 단위 락을 사용하지만, 읽기 작업에 최적화되어 있어 읽기 위주의 작업에 적합하다.

• MySQL 초기버전에서 기본으로 사용된 엔진으로, 주로 성능 위주로 빠른 읽기 작업에 특화되어 있다.

MySQL 옵티마이저(Optimizer)의 역할은 무엇인가요?

MySQL 옵티마이저는 SQL 쿼리를 가장 효율적으로 실행할 수 있는 계획을 수립하는 역할을 한다.

인덱스 사용여부, 테이블 접근 방법, 조인 순서 등을 결정하여 최소 비용으로 쿼리를 실행할 수 있도록 최적의 실행 계획을 생성한다.

MVCC(Multi-Version Concurrency Control)란 무엇이며 어떤 장점이 있나요?

MVCC는 트랜잭션이 데이터를 읽고 쓰는 과정에서 동시성을 유지하기 위해 데이터의 여러 버전을 관리하는 기술이다.

MVCC를 통해 읽기 작업이 쓰기 작업을 차단하지 않아 동시성이 향상되고, 락 경합이 줄어 전체적인 성능이 개선된다.

MySQL에서 인덱스가 쿼리 성능에 어떤 영향을 미치나요?

인덱스는 데이터를 빠르게 찾을 수 있는 구조를 제공하여 Full Table Scan을 방지하고 쿼리 속도를 향상시킨다.

적절한 인덱스 설계는 WHERE 조건, JOIN, ORDER BY, GROUP BY 등의 작업 성은을 개선하지만, 과도한 인덱스는 데이터 변경 작업의 오버헤드를 증가시킬 수 있다.

Graceful Shutdown 이란, 우아한 종료로 애플리케이션이 종료될 때 즉시 종료되는 것이 아니라, 현재 진행하고 있는 작업을 마무리 하고 리소스를 정리한 이후 종료하는 방식을 의마한다.

서버 애플리케이션에서 일반적인 Graceful Shutdown은 SIGTERM 신호를 받았을 때, 새로운 요청은 차단하고 기존에 처리 중이었던 요청들은 모두 완료한 뒤에 프로세스를 종료한다.

만약, 서버 애플리케이션이 요청을 처리하는 중에 즉시 종료된다면, 트랜잭션 비정상 종료, 데이터 손실, 사용자 경험 저하 등의 문제가 발생할 수 있다.

SIGTERM과 SIGKILL의 차이점

SIGTERM과 SIGKILL은 유닉스 및 리눅스 운영체제에서 사용되는 프로세스 종료 시그널이다.

SIGKILL

SIGKILL은 프로세스를 강제로 즉시 종료하게 하는 신호이다.

SIGTERM

SIGTERM은 프로세스가 해당 시그널을 핸들링할 수 있다. 따라서 프로세스가 종료하기 이전에 수행되어야 하는 절차들을 안전하게 수행할 수 있다.

Spring 환경에서 Graceful Shutdown을 하는 방법?

server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=20s // 타임 아웃

스프링에서는 Graceful Shutdown 설정을 지원한다. 단, 기존 처리 중인 요청 중에 데드락이나 무한 루프가 발생하면 프로세스가 종료되지 않을 수 있기 때문에 스프링에서는 이를 예방하기 위해 타임 아웃 설정을 지원한다.

데이터베이스 회복은 장애 발생 시, 데이터를 손실 없이 복구하고 일관된 상태로 복원하는 과정이다.

시스템 충돌, 정전, 하드웨어 오류 등의 상황에서 데이터 무결성과 지속성을 유지하기 위해 필수적이며, 이를 통해 비즈니스 연속성을 보장할 수 있다.

2. Write-Ahead Logging(WAL)이란 무엇이며 어떤 장점이 있나요?

Write-Ahead Logging 이란, 실제 데이터베이스에 적용하기 전에 반드시 로그에 먼저 기록하는 방식이다.

이를 통해 시스템 장애가 발생하더라도 로그를 통해 데이터의 일관성을 유지하고 복구할 수 있으며, 트랜잭션의 원자성과 내구성을 보장할 수 있다.

3. Redo 로그와 Undo 로그의 차이점을 설명해주세요.

Redo 로그

Redo 로그는 이미 커밋된 트랜잭션의 변경 내역을 재실행하여 장애 이후에도 변경된 데이터를 복구하는 로그이다.

Undo 로그

Undo 로그는 트랜잭션이 실패했거나 커밋되지 않았을 때 변경된 데이터를 원상태로 되돌리기 위해 사용된다.

Redo 로그와 Undo 로그의 차이점

Redo : 다시 실행 Undo : 되돌리기

4. 체크포인트(Checkpoint) 기법이 무엇이며 왜 사용하나요?

체크포인트는 주기적으로 데이터베이스의 상태를 저장하는 기법으로, 장애 발생 시, 복구해야할 로그 양을 최소화하여 복구 속도를 높인다.

체크포인트 이후 장애가 발생하면, 마지막 체크포인트에서부터만 로그를 적용하면 되므로 복구 시간이 단축되고 시스템 자원을 효율적으로 사용할 수 있다.

5. 데이터베이스 백업의 종류와 각각의 특징에 대해 설명해주세요.

전체 백업(Full Backup)

전체 백업은 데이터베이스 전체를 백업하여 완전한 복구가 가능하지만, 시간과 공간이 많이 필요하다.

증분 백업(Increment Backup)

증분 백업은 이전 백업 이후 변경된 사항만 백업하여 백업 속도와 효율성을 높이지만, 복구 시 여러 백업 세트가 필요하다.

차등 백업(Differential Backup)

차등 백업은 마지막 전체 백업 이후 변경된 데이터를 모두 백업 한다.

6. 데이터베이스 이중화 구성(Replication)이란 무엇이며, 어떤 이점이 있나요?

데이터베이스 이중화는 주요 데이터베이스 시스템을 복제하여 여러 서버에 데이터를 동기화하여 운영하는 방식이다.

장애 발생 시, 다른 복제 서버가 서비스를 대체하여 가용성을 높이고, 읽기 작업을 분산시켜 성능을 향상시키며, 지리적으로 분산된 환경에서도 데이터 접근 속도를 개선할 수 있다.

실시간으로 데이터 복제가 필요한 시스템에서 장애가 발생할 때, 데이터 일관성을 유지하기 위한 최적의 회복전략은 무엇인가?

실시간 데이터 복제 시스템에서는 동기식 이중화(Synchronous Replication)와 WAL(Write-Ahead Logging)을 결합한 전략이 최적이다.

• 동기식 이중화는 주 서버의 트랜잭션이 모든 복제 서버에 적용된 후에만 완료로 간주하므로 데이터 일관성을 보장한다.
• 자동 장애 조치(Automatic Failover) 메커니즘을 구현하여 주 서버 장애 시 즉시 복제 서버가 역할을 대체하고, 분산 트랜잭션 관리를 통해 모든 노드간의 일관성을 유지해야한다.

위의 전략의 주의점

동기식 복제는 성능 오버해드가 크므로 네트워크 지연이 적은 환경에서 사용해야 한다. 장애 조치 과정에서 잘못된 전환 문제를 방지하기 위한 정족수 메커니즘이 필요하며, 복구 후 데이터 재동기화 과정에서 불일치가 발생할 수 있으므로 충돌 해결 전략을 미리 수립해야한다. 또한 실시간 복제로 인한 시스템 부하를 모니터링하고, 정기적인 복제 상태 검증을 통해 데이터 불일치를 조기에 발견하는 것이 중요하다.

인덱스는 데이터베이스에서 검색 성능을 높이기 위해 사용하는 자료구조이다. 책의 목차처럼 원하는 데이터를 빠르게 찾을 수 있도록 도와준다.

• 사용하는 이유? 데이터를 찾을 때 Full Table Scan을 하면 시간이 오래 걸리는데, 이때 인덱스를 쓰면 특정 값을 빠르게 찾을 수 있어서 성능이 향상된다.

2. B-Tree 인덱스와 Hash 인덱스의 차이점은 무엇인가요?

B-Tree 인덱스

B-Tree 인덱스는 가장 일반적으로 사용되는 인덱스 구조로, 데이터를 정렬된 트리 형태로 저장하고, 검색 시 트리를 따라 내려가면서 값을 찾는 방식이다.

B-Tree 인덱스의 가장 큰 장점은 범위 검색이 가능 하다는 점이다. ex) WHERE age > 30, BETWEEN, LIKE 'abc%' 등의 조건에서 유리하다.

또한 정렬이 되어 있기 때문에 ORDER BY, GROUP BY 와 같은 쿼리에도 효율적으로 사용될 수 있다.

Hash 인덱스

Hash 인덱스는 데이터를 해시 함수를 통해 변환하여 인덱스를 구성한다. "정확히 일치하는 값" 을 매우 빠르게 찾을 수 있는 구조이다.

Hash인덱스는 동등 조건에서 뛰어난 성능을 보인다. ex) WHERE id = 12345

하지만, 값의 순서를 알 수 없기 때문에 범위 검색이 불가능하다. ex) WHERE id > 1000 Hash 인덱스는 불가능

B-Tree 인덱스 VS. Hash 인덱스

B-Tree 인덱스는 범위 검색, 정렬, 다양한 조건 처리에 유연하여 대부분에 DB에서 기본 인덱스 타입으로 사용된다. 반면, Hash 인덱스는 정확한 값 비교에는 특화되어 있지만, 범위나 정렬 관련 쿼리에는 적합하지 않다.

실제 MySQL(InnoDB)에서는 대부분 B-Tree 인덱스를 기본으로 사용하고 있고, Hash 인덱스는 특정 스토리지 엔진(Memory 엔진 등)에서만 제한적으로 사용된다.

3. 인덱스를 사용할 때의 장점과 단점을 설명해주세요.

인덱스 사용의 장점

1. 조회 성능 향상
2. WHERE, JOIN, ORDER BY, GROUP BY 등의 쿼리 최적화 가능
   • 인덱스는 원하는 조건에 해당하는 레코드만 빠르게 조회할 수 있도록 도와준다.

인덱스 사용의 단점

1. 인덱스를 위한 추가 저장공간 필요
   • 인덱스는 별도의 자료구조(B-Tree 등)를 테이블과 별도로 저장한다.
2. 쓰기 성능 저하 (INSERT, UPDATE, DELETE): 인덱스도 갱신해야하기 때문
3. 너무 많은 인덱스는 오히려 성능 저하를 유발할 수 있음
   • 여러개의 인덱스를 추가했을 때, 쿼리 실행시 어떤 인덱스를 쓸지 판단하는 비용 발생

=> 인덱스는 읽기 성능을 높이지만, 쓰기 성능을 희생하는 구조이다. 따라서 읽기 위주의 시스템(검색 서비스, 리포트 대시보드 등)은 인덱스를 적극적으러 활용하고, 쓰기 위주의 시스템(로그 수집, 트랜잭션 처리 등)은 최소한의 인덱스만 활용한다.

4. 인덱스 스캔 방법에는 어떤 것들이 있나요?

Full Table Scan

인덱스 없이 테이블 전체를 훑는 스캔 방법

Index Scan / Index Range Scan

인덱스를 따라 범위 내 값을 검색

Index Only Scan

필요한 데이터가 모두 인덱스에 있어 테이블 접근 생략

Bitmap Index Scan

대량의 조건에 대한 효울적인 검색

Unique Index Scan

고유한 인덱스에서 정확히 하나읙 값만 찾을 때

5. 복합 인덱스(Composite Index)란 무엇이며, 어떤 경우에 유용한가요?

복합 인덱스란, 두 개 이상의 컬럼을 조합해 만든 인덱스이다.

복합 인덱스가 유용한 경우

• WHERE 조건이 여러 컬럼에 걸쳐 있을 때
• 자주 같이 조회되는 컬럼이 있을 때
• 특정 컬럼 조홥으로 정렬, 그룹화 할 때

6. 인덱스 설계 시 고려해야 할 핵심 요소는 무엇인가요?

• 조회 패턴

• 어떤 쿼리가 자주 실행되는지?

• 선택도(Selectivity)

• 컬럼의 중복이 적을 수록 인덱스 효율이 높아짐 (주민번호 vs. 성별)

• 컬럼 순서

• 복합 인덱스일 경우 자주 사용하는 조건을 앞에 두는 게 좋음

• 쓰기 비용

• 인덱스가 많을 수록 쓰기 성능 저하

• 커버링 인덱스 고려

• 인덱스 만으로 쿼리가 해결되도록 설계하면 성능이 향상

프론트엔드 종류별(웹, 모바일)로 최적화된 백엔드 API를 각각 제공하는 아키텍처 패턴이다.

BFF를 사용하는 이유

• 각 프론트엔드의 요구사항이 다를 때 효율적으로 대응하기 위해서 사용한다.
• 공통 백엔드를 그대로 쓰면 불필요한 데이터까지 받아오거나, 응답 구조가 복잡해질 수 있으므로 이를 해결하기 위해 프론트엔드에 맞는 전용 백엔드를 만드는 것이다.

BFF를 어떻게 구성하는가?

• 웹용 BFF, 모바일용 BFF 와 같이 프론트 별로 별도의 서버 혹은 서비스를 둔다.
• BFF는 클라이언트의 요청을 받아 다른 마이크로 서비스나 백엔드와 통신하고, 필요한 형태로 데이터를 가공해서 프론트에게 전달한다.

일반적인 API 구조

BFF 구조

NextJS로 BFF가 가능한 이유

Next.js는 프론트엔드 프레임워크이면서, 동시에 API Routes 기능을 통해 서버리스(Serverless) 백엔드 API를 만들 수 있음.

• API Routes: Next.js 안에 API 서버처럼 쓸 수 있는 기능
• 서버리스: 요청이 있을 때만 실행되는 백엔드 함수

Next.js에서는 pages/api/.js 또는 app/api//route.ts 경로에 파일을 만들면, 그게 API Endpoint가 되는데,Next.js 앱을 Vercel이나 AWS Lambda 같은 환경에 배포하면, 이 API Route 파일들은 서버를 계속 띄워놓는 게 아니라, 요청이 들어올 때마다 짧게 실행되고 사라지는 백엔드 함수처럼 동작하는데, 이를 서버리스 라고 한다.

BFF의 장점

• 프론트의 요구사항에 딱 맞는 API를 맞춤으로 제공
• 복잡한 백엔드의 로직을 숨기고, 클라이언트는 단순하게 사용할 수 있다.
• 보안, 인증, 응답 포맷 통합 등 중간 계층 역할을 수행할 수 있다.

BFF의 단점

• BFF 서비스가 많아지면, 운영, 관리 복잡도가 증가할 수 있다.
• 코드 중복 가능성이 생긴다. => 프론트엔드마다 별도의 BFF를 두기 때문에 비슷한 로직이 여러 곳에 흩어질 수 있기 때문이다.

출처

카카오페이지 BFF

• Read Uncommitted: 다른 트랜잭션이 커밋하지 않은 결과값을 읽을 수 있는 상태 -> 더티리드 발생 가능
• Read Committed: 다른 트랜잭션이 커밋한 결과만 읽을 수 있는 상태 -> 반복 불가능한 읽기, 팬텀 리드 발생 가능
• Repeatable Read: 동일 트랜잭션 내에서 같은 데이터 조회 시 항상 같은 결과 반환 -> 팬텀 리드 발생 가능
• Serializable: 트랜직션을 직렬화하여 실행하는 가장 엄격한 격리 수준 -> 성능 저하

특정 격리 수준을 선택할 때 고려해야 할 성능과 데이터 일관성 간의 트레이드오프는 무엇인가요?

트랜잭션 격리 수준은 여러 트랜잭션이 동시에 작동할 때 각 트랜잭션이 서로에게 미치는 영향을 조정하는 설정입니다. 동시성과 정합성 사이의 균형을 조정하는 중요한 요소입니다. 격리 수준이 높을 수록 데이터 정합성은 보장되지만 트레이드 오프로 성능 저하가 발생할 수 있습니다.

이러한 격리 수준이 실제 비즈니스 로직에 어떤 영향을 미치는지 설명할 수 있나요?

성능이 중요한 경우는 검색 서비스나 로그 시스템을 예시로 들 수 있는데, 이 경우 Read Committed를 적용해야 한다. 반대로 데이터 일관성이 중요한 경우는 금융 거래와 주문 시스템을 들 수 있는데, 이 경우 Repeatable Read나 Serializable을 격리 수준으로 설정해야 한다.

2. 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)의 차이점과 각각 어떤 상황에서 사용하는 것이 적합한지 설명해주세요.

• 이 두 락 방식의 구현 방법 차이에 대해 설명해주세요.
• 동시성이 높은 환경에서 각 락 방식의 장단점은 무엇인가요?

락(Lock)은 여러 트랜잭션이 동일한 데이터에 동시에 접근할 때 충돌을 방지하기 위한 방법이다.

비관적 락(Pessimistic Lock)

비관적 락은 트랜잭션이 데이터에 접근할 때 즉시 잠금처리를 하여 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 한다. 은행 시스템과 같은 동시 수정 가능성이 높은 환경 사용하는 것이 좋다. 안전하게 데이터를 보호할 수 있지만, 락으로 인하여 성능이 저하되고 교착 상태(Deadlock)이 발생할 수 있다.

비관적 락의 구현 방법

• 데이터베이스 레벨: SELECT ... FOR UPDATE 를 사용하여 행 단위의 락을 설정한다.
• 애플리케이션 레벨: synchronized, ReetrantLock 활용

낙관적 락(Optimistic Lock)

낙관적 락은 데이터 수정 시, 기존 값과 비교하여 변경 가능 여부를 판단한다. 쇼핑몰 상품 조회와 같이 읽기 작업이 많고 충돌 가능성이 낮은 환경에서 사용하는 것이 좋다. 낙관적 락은 동시성 높은 환경에서 성능이 우수하지만, 충돌 발생 시 재시도가 필요하여 응답 속도가 저하될 수 있다.

=> 따라서 비즈니스 로직과 데이터 동시성 요구사항에 따라 적절한 락을 선택해야 한다!

낙관적 락의 구현 방법

• 버전 번호 사용: 데이터 변경 시, 기존 버전과 비교 후 업데이트한다.
• 타임스탬프 사용: 최근 업데이트 시간과 비교하여 데이터 정합성을 유지한다.

3. 분산 트랜잭션의 개념과 구현 방법에 대해 설명해주세요.

• 2단계 커밋(Two-Phase Commit) 프로토콜은 어떻게 작동하나요?
• 분산 트랜잭션에서 발생할 수 있는 문제점은 무엇이며 이를 어떻게 해결할 수 있나요?

4. 교착상태(Deadlock)이 발생하는 원인과 이를 감지하고 해결하는 방법은 무엇인가요?

데드락은 두 개 이상의 트랜잭션이 서로의 락을 기다리면서 무한 대기가 발생하는 현상이다.

해결방법

1. 트랜잭션의 순서 정하기: 특정 순서로 실행하여 충돌을 방지한다.
2. 락 타임아웃 설정하기: 일정 시간이 지나면 롤백하도록 한다.
3. 락 획득 순서 일관성 을 유지하기: 테이블 A -> B 순서로 접근하도록 코드를 설계한다.

5. InnoDB 스토리지 엔진에서 레코드 락(Record Lock), 갭 락(Gap Lock), 넥스트 키 락(Next-Key Lock)의 차이점은 무엇인가요?

Record Lock

특정 행에 대한 락

Gap Lock

특정 범위에 대한 락 (팬텀 리드를 방지한다.)

Next-Key Lock

Record Lock + Gap Lock

6. MySQL에서 사용하는 다양한 락의 종류(글로벌 락, 테이블 락, 네임드 락, 메타데이터 락 등)에 대해 설명해주세요.

글로벌 락 (Global Lock)

전체 데이터베이스 락

테이블 락 (Table Lock)

특정 테이블 단위 락

네임드 락 (Named Lock)

애플리케이션에서 정의하는 사용자 지정 락

메타데이터 락 (Metadata Lock)

스키마 변경 시 발생하는 락

7. 트랜잭션 격리 수준을 애플리케이션 코드 레벨에서 어떻게 제어하나요?

• Spring Framework에서 @Transactional 어노테이션 사용 시 격리 수준 설정 방법과 주의점은 무엇인가요?
• 애플리케이션 레벨에서 트랜잭션 격리 수준을 잘못 설정했을 때 발생할 수 있는 문제는 무엇인가요?

트랜잭션 격리 수준은 동시에 실행되는 트랜잭션 간의 영향을 미치는 수준을 설정함에 있어 트랜잭션 간의 데이터 정합성을 유지, 최적화하기 위한 중요한 설정이다. 애플리케이션 코드 레벨에서 격리 수준을 제어하는 방법은 데이터베이스 설정, SQL 직접 설정, 프레임 워크 설정 등이 있다.

특히 Spring Framework에서 @Transaction 어노테이션을 사용하여 트랜잭션 격리를 실행할 수 있는데, 주의할 점은 @Transaction 어노테이션을 사용하더라도 데이터베이스 자체 설정이 우선 적용될 수 있으며, 프록시 기반 트랜잭션으로 private 메서드에서는 동작하지 않는 다는 점이다. 즉, @Transaction 어노테이션이 적용된 메서드는 Spring 컨테이너에서 관리되는 빈에서 호출 되어야 한다.

전체적으로 트랜잭션 격리 수준을 잘못 설정하게 되면,

• 격리 수준이 너무 높아 성능 저하가 발생하거나,
• 격리 수준이 너무 낮아 데이터 정합성 문제가 발생하거나,
• 불필요한 트랜잭션을 유지하여 성능이 저하되거나,
• 트랜잭션 전파 속성을 잘못 설정하여 예상과 다른 결과를 얻을 수 있다.

8. MSA(Microservice Architecture) 환경에서 트랜잭션 관리 방법과 패턴에 대해 설명해주세요.

• SAGA 패턴이란 무엇이며 어떻게 구현하나요?
• 보상 트랜잭션(Compensating Transaction)이란 무엇이며 어떻게 동작하나요?

MSA에서는 주로 SAGA 패턴 또는 2PC 패턴을 사용하여 트랜잭션을 관리한다.

SAGA 패턴

트랜잭션을 여러 개의 로컬 트랜잭션으로 나누어 실행하고, 실패 시 보상 트랜잭션을 실행하는 방식이다. 동기 방식이 아니라 비동기 이벤트 기반으로 트랜잭션을 처리하여 MSA환경에서 트랜잭션 일관성을 유지한다.

SAGA 패턴의 동작 방식

1. 각 서비스가 독립적으로 로컬 트랜잭션을 실행
2. 한 서비스에서 트랜잭션이 실패하면 이전 서비스에서 보상 트랜잭션을 수행하여 데이터 일관성을 유지한다.

SAGA 패턴의 종류

둘의 차이는 트랜잭션을 어디서 처리하냐에 있다.

• 오케스트레이션 기반 SAGA
  • 중앙 컨트롤러가 전체 트랜잭션의 흐름을 관리 => 흐름 추적이 쉽지만, 중앙 컨트롤러가 병목이 될 가능성이 있음
  • 한 서비스가 트랜잭션을 실행하고, 완료되면 다음 서비스가 실행됨 (트랜잭션 실행순서는 정해져 있지만, 서비스는 독립적으로 실행됨)
  • 예) 주문 처리 시스템: 주문 -> 결제 -> 배송 순차 관리, 트랜잭션의 흐름이 명확한 시스템에서 유리 (ex. 금융 거래, 예약 시스템)
• 코레오그래피 SAGA
  • 각 마이크로 서비스가 이벤트를 주고 받으며 독립적으로 트랜잭션을 처리
  • 별도의 중앙 컨트롤러 없이, 이벤트 브로커(Kafka 등)을 통해 서비스 간 통신
  • 예) 결제 서비스 성공 -> "결제 완료" 이벤트 발생 -> 주문 서비스가 이를 받아 상태 업데이트, 전자상거래, 마이크로서비스 기반 플랫폼에 유리

SAGA 패턴의 장점

• 서비스 간 느슨한 결합 구조 유지 가능
• 장애 발생 시 부분 롤백이 가능해 시스템 안정성이 높음
• 확장성이 뛰어나고, 비동기 이벤트 기반으로 높은 성능 유지 가능

SAGA 패턴의 단점

• 일관성 보장이 어려움
• 설계 복잡성 증가

2PC(Two-Phase Commit 패턴)

트랜잭션을 2단계 (준비 단계 -> 커밋 단계)로 나누어 실행하는 방식으로 분산 트랜잭션을 동기적으로 관리할 수 있다.

2PC 패턴의 장점

• 데이터 일관성을 강하게 유지할 수 있음

2PC 패턴의 단점

• 동기 방식으로 성능이 떨어져 MSA 환경에서는 권장되지 않는다.

보상 트랜잭션

트랜잭션 도중 일부 작업이 실패했을 때, 이전에 완료된 작업을 롤백하여 데이터 일관성을 유지하려는 트랜잭션 패턴이다.

보상 트랜잭션은 MSA 환경에서 분산 트랜잭션을 관리하는 대표적인 방식이며, SAGA 패턴 에서 자주 사용된다.

기존 RDBMS의 ACID 기반 트랜잭션에서는 하나의 트랜잭션이 실패하면 Rollback() 호출하여 모든 작업을 원래 상태로 되돌릴 수 있었지만, MSA 환경에서는 각 서비스가 독립적인 데이터베이스를 사용하므로, 단일 트랜잭션으로 모든 서비스를 한꺼번에 롤백할 수 없다. 그렇기 때문에 보상 트랜잭션을 실행하여, 실패한 서비스 이전의 작업들을 취소하는 방식으로 트랜잭션을 관리한다.

보상 트랜잭션 예시

1. 주문 - 주문 서비스
2. 결제 승인 실패 - 결제 서비스
3. 주문 취소 (보상 트랜잭션) - 주문 서비스

9. 데이터베이스 성능 최적화 관점에서 트랜잭션을 어떻게 설계하고 관리해야 하나요?

트랜잭션의 범위를 최소화하여 실행 시간을 줄이고, 인덱스를 활용하여 성능을 최적화해야합니다. 트랜잭션이 불필요하게 길어지는 것을 방지하기 위해 배치 처리를 활용하고, 커밋 빈도를 적절히 조정해야합니다. 읽기 전용 트랜잭션(READ ONLY)을 적용하면 불필요한 락을 방지할 수 있으며, 데이터 일관성을 유지하면서도 성능을 높일 수 있습니다. 또한 트랜잭션 수준을 비즈니스 요구사항에 맞게 설정하여 성능과 데이터 정합성 간의 균형을 유지해야합니다.

• 여기서 배치처리란, 대량의 데이처를 한 번에 처리하여 트랜잭션을 효율적으로 관리하는 기법으로 트랜잭션이 불필요하게 길어지는 것을 방지하고 성능을 최적화하는데 사용된다.

장기 실행 트랜잭션(Long-running Transaction)의 문제점과 이를 해결하기 위한 방법은 무엇인가요?

장기 실행 트랙잭션은 데이터 락을 장기간 유지하여 동시성을 저하시킬 수 있으며, 데드락 발생 가능성을 높입니다. 트랜잭션이 길어질 수록 로그 크기가 증가하여 I/O 부하가 발생하고, 시스템 성능이 저하될 수 있습니다. 해결방법으로는 트랜잭션을 작은 단위로 분리하여 비동기적으로 처리하거나 읽기 작업을 캐싱하여 DB 부하를 줄이는 방법도 효과적입니다.

트랜잭션 로그(Transaction Log)의 역할과 관리 방법은 무엇인가요?

트랜잭션 로그는 데이터 변경 사항을 기록하여 장애 발생 시 복구할 수 있도록 지원하는 역할을 합니다. 로그는 Write-Ahead Logging (WAL) 방식으로 동작하며, 변경 내용을 먼저 로그에 기록한 후 실제 데이터를 반영하는 방식으로 데이터 무결성을 보장합니다.

트랜잭션 로그가 과도하게 쌓이면 성능 저하를 유발할 수 있으므로 Checkpoint를 설정하여 불필요한 로그를 정리하고 주기적으로 백업해야합니다. Redo Log 와 Undo Log 를 활용하여 장애 발생 시 트랜잭션을 복구하고, 데이터 정합성을 유지하는 것이 중요합니다. 로그 파일을 별도의 디스크에 저장하는 것도 성능 향상에 도움이 됩니다.

• Redo Log : 트랜잭션이 성공적으로 커밋된 이후에도 장애가 발생하면 다시 데이터를 복구하기 위한 로그
• Undo Log : 트랜잭션이 롤백될 때 이전상태로 데이터를 되돌리기 위한 로그

10. 읽기 전용 트랜잭션(Read-only Transaction)의 최적화 방법은 무엇인가요?

읽기 전용 트랜잭션은 데이터를 변경하지 않고 SELECT 작업만 수행하는 트랜잭션으로, 데이터 정합성을 유지하면서도 성능을 최적화할 수 있도록 설계됩니다.

• 트랜잭션 격리수준 최적화: 읽기 전용 트랜잭션에서는 높은 격리 수준이 필요지 않으므로 Read Committed 또는 Repeatable Read로 설정하여 성능을 향상시킬 수 있음.
• 인덱스 최적화: where절에 자주 사용되는 털럼에 인덱스를 적용하여 검색 속도를 개선할 수 있음.
• 캐싱 적용: 자주 조회하는 데이터에 캐싱을 적용하여 DB 부하를 줄여 성능을 개선할 수 있음.

11. 트랜잭션 관련 디자인 패턴(Unit of Work, Repository 등)에 대해 설명하고 실제 코드에서 어떻게 구현하는지 설명해주세요.

Unit of Work

Unit of Work 패턴은 여러 개의 데이터 변경 작업을 하나의 트랜잭션으로 묶어 관리하는 패턴으로, 이를 통해 중복된 트랜잭션 처리를 방지하고, 커밋(Commit)과 롤백(Rollback)을 일괄적으로 처리할 수 있다.

예를 들어, JPA의 EntityManager를 사용하면 여러 엔티티 변경 사항을 한 번에 관리할 수 있다.

Repository

Repository 패턴은 데이터베이스 접근 로직을 추상화해서 트랜잭션을 일관되게 관리하는 방식이다. 이를 활용하면, DAO(Data Access Object)와 비슷하게 특정 엔티티에 대한 데이터를 조회, 저장, 삭제하는 메서드를 한 곳에서 관리할 수 있다.

트랜잭션 전파(Propagation) 속성이란 무엇이며 어떻게 활용하나요?

트랜잭션 전파(Propagation) 속성은 현재 실행 중인 트랜잭션을 어떻게 처리할지 결정하는 설정이다. 쉽게 말하면, 하나의 트랜잭션이 실행될 때 이미 진행 중인 트랜잭션이 있다면 이를 유지할지, 새로운 트랜잭션을 만들지, 아니면 기존 트랜잭션을 무시할지를 결정하는 방식이다.

Spring에서는 @Transactional(propagation = Propagation.XXX) 형태로 설정할 수 있는데, 가장 많이 사용하는 속성들은 다음과 같다.

• REQUIRED (기본값): 기존 트랜잭션이 있으면 참여하고, 없으면 새로 생성
• REQUIRES_NEW: 항상 새로운 트랜잭션을 생성 (기존 트랜잭션이 있어도 무시)
• SUPPORTS: 트랜잭션이 있으면 참여하지만, 없어도 실행
• MANDATORY: 반드시 기존 트랜잭션이 있어야 실행 (없으면 예외 발생)
• NEVER: 트랜잭션이 있으면 예외 발생, 트랜잭션 없이 실행
• NESTED: 기존 트랜잭션 내에서 별도의 중첩 트랜잭션 실행

중첩 트랜잭션(Nested Transaction)이란 무엇이며 언제 사용하는 것이 적합한가요?

중첩 트랜잭션(Nested Transaction)이란, 하나의 트랜잭션 내부에서 또 다른 트랜잭션을 실행하는 방식을 의미한다. 즉, 부모 트랜잭션이 진행 중인 상태에서 하위 트랜잭션(자식 트랜잭션)이 수행되는 구조이며, 하위 트랜잭션에서 문제가 발생하면 부분 롤백(Partial Rollback)이 가능한 것이 특징이다.

중첩 트랜잭션을 사용하는 것이 적합한 상황

• 부분 롤백이 필요한 경우: 예를 들어, 사용자 주문 처리 과정에서 배송 정보 저장은 취소해야 하지만, 결제 내역은 유지해야 하는 경우.
• 한 개의 트랜잭션 내에서 논리적으로 구분된 여러 작업을 실행해야 할 때: 예를 들어, 대량의 데이터를 삽입하는 동안 특정 레코드에서 오류가 발생하더라도, 전체 트랜잭션을 롤백하지 않고 일부 데이터만 롤백 가능.
• 서브 트랜잭션이 독립적인 실행 단위로 관리될 필요가 있을 때: 특정 모듈(예: 로그 기록)이 트랜잭션이 롤백되더라도 로그는 남아 있어야 할 경우.

데이터 정합성

데이터 정합성(Data Integrity)이란 데이터의 정확성, 일관성, 신뢰성을 유지하는 개념을 의미. 즉, 데이터가 손상되지 않고, 올바른 상태를 유지하며, 서로 다른 시스템 간에서도 일관된 상태를 유지하는 것.

트랜잭션이란, 데이터베이스에서 하나의 논리적인 작업 단위를 의미합니다. 일련의 작업이 모두 성공하거나, 하나라도 실패하면 전체가 롤백되는 원자성을 보장하는 개념입니다.

트랜잭션은 데이터의 일관성과 무결성을 유지하는데 중요한 역할을 합니다. 예를 들어, 은행 계좌 이체 시, 송금 계좌에서 돈이 출금되고 수신 계좌에 입금되는 과정이 하나의 트랜잭션으로 처리되지 않으면, 일부만 반영되어 데이터 불일치가 발생할 수 있습니다.

ACID

ACID는 트랜잭션이 안전하게 수행되기 위한 4가지 핵심 속성을 의미합니다.

• 원자성(Atomicity): 트랜잭션 내 작업이 하나의 단위로 수행되며 하나라도 실패하면 전체가 롤백된다.
• 일관성(Consistency): 트랜잭션 실행 전 후에 데이터가 항상 일관된, 무결한 상태가 유지되어야 한다. (예를 들면, 100만원 송금하면 100만원이 입금되어 전체적으로 총량이 변화가 없어야 한다.)
• 격리성(Isolation): 동시에 실행되는 트랜잭션들이 서로 영향을 주지 않도록 보장해야한다.
• 지속성(Durability): 트랜잭션이 성공적으로 완료되면, 시스템에 장애가 발생하더라도 결과가 유지되어야 한다.

트랜잭션의 기본 연산인 커밋(Commit)과 롤백(Rollback)에 대해 설명해주세요

Commit

트랜잭션이 성공적으로 완료되었음을 데이터베이스에 확정하는 연산. commit 이후에는 변경사항이 영구적으로 반영됩니다.

Rollback

트랜잭션 수행 중 오류가 발생하거나 문제가 생겼을 때, 이전 상태로 되돌리는 연산입니다.

세이브포인트(Savepoint)란 무엇이며 어떤 상황에서 사용하나요?

세이프 포인트는 트랜잭션 내에서 특정 시점에 저장점을 설정하여, 필요 시 해당 점까지 롤백할 수 있도록 하는 기능입니다.

ex) 여러개의 계좌로 송금하는 트랜잭션을 수행할 때, 일부 계좌의 송금이 실패했을 때 전체 송금을 롤백하는 것이 아니라 실패한 부분만 롤백하고 나머지는 유지할 수 있도록 세이브 포인트를 설정할 수 있습니다.

트랜잭션 격리 수준이란 무엇인가요?

트랜잭션 격리 수준은 여러 트랜잭션이 동시에 실행될 때, 각 트랜지션이 서로에게 미치는 영향을 조정하는 설정입니다. SQL에서는 4가지 격리 수준을 정의하고 있으며, 낮은 수준일수록 성능이 향상되지만, 데이터 일관성 문제가 발생할 수 있습니다.

• Read Uncommitted: 다른 트랜잭션의 미확정 데이터를 읽을 수 있음. => 더티 리드 발생 가능
• Read Committed: 다른 트랜잭션이 커밋한 데이터만 읽을 수 있음. => 더티 리드 방지
• Repeatable Read: 하나의 트랜잭션이 수행되는 동안 동일한 데이터를 여러 번 조회하면 항상 같은 결과가 보장됨. => 반복 불가능한 읽기 방지
• Serializable: 가장 엄격한 격리 수준으로 트랜잭션이 순차적으로 수행되는 것처럼 보장됨. => 팬텀 리드 방지, 성능 저하 가능성 존재.

더티 리드(Dirty Read)란 무엇인지 설명하고 예시를 들어주세요.

더티 리드는 하나의 트랜잭션에서 아직 커밋되지 않은 다른 트랜잭션의 데이터를 읽는 현상이다.

이후에 해당 트랜잭션이 롤백되면 읽은 데이터는 유효하지 않은 값이 될 수 있다.

예를들면,

1. A 트랜잭션이 계좌 잔액을 100만원에서 50만원으로 변경했지만 아직 커밋하지 않은 상황에서
2. B 트랜잭션이 계좌 잔액을 조회했을 떄 50만원으로 조회를 하고,
3. 이후 A 트랜잭션이 롤백되면 잔액은 다시 100만원이 되지만, B는 잘못된 정보를 사용했을 수 있음.

=> 해결방법: Read Committed 이상의 격리 수준을 적용하여 커밋된 데이터만 읽도록 설정한다.

반복 불가능한 읽기(Non-repeatable Read)란 무엇인가요?

반복 불가능한 읽기는 하나의 트랜잭션에서 같은 데이터를 여러 번 읽을 때, 중간에 다른 트랜잭션이 값을 변경하여 서로 다른 결과가 나오는 문제이다. => 기존 데이터의 값이 변경되거나 삭제되어 다른 조회 결과가 나오는 것(DELETE, UPDATE)

예를 들면,

1. A 트랜잭션이 고객의 계좌 잔액을 조회했을 때 100만원이었는데
2. B 트랜잭션이 같은 계좌의 잔액을 50만원으로 변경하고 커밋했다면,
3. A 트랜잭션이 다시 같은 계좌를 조회했을 때 50만원으로 바뀌어 조회되게 된다.

=> 해결방법: Repeatable Read 이상의 격리 수준을 적용하여 동일 트랜잭션 내에서는 데이터가 변경되지 않도록 보장한다.

팬텀 리드(Phantom Read)란 무엇인가요?

팬텀리드는 한 트랜잭션이 특정 조건으로 데이터를 조회한 후, 다른 트랜잭션이 새로운 데이터를 추가하거나 삭제하여 같은 조회 시 결과가 달라지는 현상이다. => 기존 데이터의 값이 추가되거나 삭제되어 조회 결과 행 개수가 달라지는 것 (DELETE, INSERT)

=> 해결 방법: Serializable 수준의 격리 수준을 적용한다.

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 다양한 운영체제에서 동작하며, MySQL 서버는 MySQL 엔진과 스토리지 엔진으로 구성되어 있다.

MySQL 서버 = MySQL 엔진 + 스토리지 엔진

• MySQL 엔진은 클라이언트로부터 오는 SQL 요청 처리를 담당한다.
• 스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 조회하는 부분을 담당한다.

MySQL 엔진

• SQL 인터페이스: DDL, DML, ..
• SQL 파서: SQL 문법 오류 탐지
• 쿼리 옵티마이저: 실행 계획을 최적화하여 효율적인 데이터 검색을 수행한다.
• 캐시와 버퍼 기능 제공: 자주 사용되는 데이터를 메모리에 저장하여 쿼리 성능을 향상시킨다.

InnoDB

MySQL이 제공하는 스토리지 엔진이 다양하지만 그 중 유일하게 레코드 기반의 락(Lock)을 제공하며, 이를 통해 높은 동시성 처리가 가능한 특징이 있어 주로 쓰이는 스토리지 엔진이다.

InnoDB의 구조

• 메모리 영역: InnoDB 버퍼 풀을 활용하여 데이터 및 인덱스를 캐싱하여 성능을 향상시킨다.
• 디스크 영역: 데이터 파일 및 로그 파일이 저장되며, 데이터 변경 사항을 지속적으로 기록한다.

InnoDB의 특징

• 클러스터형 인덱스: Primary Key 순서대로 디스크에 저장되며 그렇기 때문에 Range scan이 굉장히 빠르다.
• MVCC(Multi-Version Concurrency Control): 다중 트랜잭션 동시 수행 시, 일관성을 유지하기 위해 여러 버전의 데이터를 관리한다.
• 자동 데드락 감지: 트랜잭션 충돌이 발생하면 자동으로 데트락을 탐지하고 해결한다.
• 자동 장애 복구: 트랜잭션 로그를 기반으로 장애 발생 시, 자동으로 복구한다.

면접 답변

MySQL이 무엇인가요?

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템(RDBMS)으로, 데이터의 저장 및 관리, 검색을 수행하는 데이터베이스 시스템입니다. MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구성됩니다.

MySQL 엔진: 클라이언트로부터 SQL 요청을 받아 처리하며, SQL 문법을 분석하고 최적의 실행 계획을 수립하여 데이터 검색을 수행합니다. 스토리지 엔진: 데이터를 디스크에 저장하고 관리하는 역할을 하며, 대표적으로 InnoDB와 MyISAM을 지원합니다. MySQL은 쿼리 최적화, 캐싱, 트랜잭션 처리 등의 기능을 제공하며, 대규모 시스템에서도 높은 성능을 유지할 수 있도록 설계되었습니다.

InnoDB가 무엇인가요?

InnoDB는 MySQL에서 기본적으로 사용되는 스토리지 엔진으로, 트랜잭션을 지원하며 높은 동시성을 제공하는 특징이 있습니다.

InnoDB의 주요 특징은 다음과 같습니다.

클러스터형 인덱스(Clustered Index): Primary Key 순서대로 데이터를 저장하며, 이를 통해 범위 검색(Range Scan) 속도가 빠릅니다. MVCC(Multi-Version Concurrency Control): 여러 트랜잭션이 동시에 수행될 때 데이터의 일관성을 유지하도록 여러 버전의 데이터를 관리합니다. 자동 데드락 감지: 트랜잭션 충돌이 발생할 경우 자동으로 데드락을 탐지하고 해결합니다. 자동 장애 복구: 트랜잭션 로그를 기반으로 장애 발생 시 자동으로 복구할 수 있습니다. 이러한 특징 덕분에 InnoDB는 안전한 데이터 저장 및 고성능 트랜잭션 처리가 필요한 시스템에서 널리 사용됩니다.

무결성이란, 데이터베이스에서 데이터의 정확성, 일관성을 유지하는 것을 의미한다. 즉, 데이터에 결함이 없는 상태를 나타낸다.

무결성 제약조건

무결성 제약조건은, 데이터베이스의 정확성과 일관성을 보장하기 위해 설정되는 조건으로, 데이터의 저장, 삭제, 수정 등을 제한하거나 조절하는 역할을 한다.

• 도메인 무결성
• 개체 무결성
• 참조 무결성

도메인 무결성

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

ex) 나이 속성에 음수가 들어가거나, 성별이라는 속성에 남, 여를 제외한 데이터는 들어갈 수 없다.

개체 무결성

각 릴레이션의 기본키를 구성하는 속성은 NULL값이나 중복된 값을 가질 수 없다.

=> 기본키는 항상 유일하고 비어 있을 수 없는 값이다.

ex) 학번

참조 무결성

외래키 값은 NULL이거나 참조하는 릴레이션의 기본키 값과 동일해야 한다.

=> 각 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다.

데이터데이스에서 각 행을 구분하는 유일한 식별자이다.

• 일반적으로 키는 테이블에서 하나 이상의 열(속성)로 구성된다.
• 키는 데이터 정합성 유지, 검색, 수정, 삭제 등의 작업을 할 때 중요한 역할을 한다.

데이터 정합성

데이터가 올바르게 유지되고 일관성 있게 유지되는 것을 의미한다. 데이터베이스 내의 모든 데이터가 정확하고 일관되게 유지되도록 하는 것을 목표로 한다.

데이터베이스 키 종류

1. 기본키

테이블에서 각 행을 유일하게 식별할 수 있는 키

• NULL 허용 X

2. 후보키

기본 키가 될 수 있는 후보로 선정된 속성 또는 속성의 집합

• NULL 허용 X

3. 대리키

기본 키로 사용되징 않는 후보키의 집합을 의미한다.

• NULL 허용 O

4. 슈퍼키

행을 유일하게 식별할 수 있는 모든 필드의 조합을 의미한다.

• 주키와 후보키, 대체 키들의 조합이 슈퍼키가 된다.
• NULL 허용 O

5. 외래키

다른 테이블의 기본키로 사용되는 키로 두 개 이상의 테이블을 연결하는 데 사용된다.

관계형 데이터베이스에서 데이터를 표로 저장하는 기본 단위이다. 릴레이션은 튜플과 속성으로 구성된다.

=> 즉, 릴레이션은 DB 테이블이다.

릴레이션의 특징

• 하나의 릴레이션에 포함된 튜플들은 모두 상이하다.
• 한 릴레이션에 포함된 튜플 사이에는 순서가 없다. (하지만 SQL의 ORDER BY로 특정 속성을 기준으로 정렬할 수 있다.)

릴레이션 스키마와 릴레이션 인스턴스에 대해서 설명해주세요.

릴레이션 스키마

릴레이션 스키마는 릴레이션에서 데이터를 저장하는 구조를 정의하는 설게도이다.

테이블의 이름, 속성 목록, 속성의 데이터 타입, 기본 키 및 제약 조건 등을 포함한다.

릴레이션 인스턴스

릴레이션 인스턴스는 릴레이션에 실제로 저장된 데이터의 집합을 의미한다.

릴레이션의 차수와 카니날리티에 대해 설명해주세요.

릴레이션의 차수

한 릴레이션 안에 있는 에트리뷰트(속성)의 수를 차수라고 한다.

• 0 < 차수
• ex) 고객번호, 이름, 전화번호, 집주소

카디날리티

릴레이션의 튜플의 개수이다.

• 0 <= 카디날리티
• 카디날리티는 시간이 지남에 따라 값이 게속 변한다.

데이터를 테이블 형태로 저장하고 테이블 간의 관계를 명확히 정의하는 데이터베이스를 생성, 수정, 관리 및 검색하는 소프트웨어 시스템이다.

RDBMS의 특징

• RDBMS는 SQL을 사용하여 데이터를 조작하고 검색한다.
• RDB는 행과 열로 이루어져 있다.
  • 열(속성): 특정 데이터 유형 의미
  • 행(튜플): 레코드 의미
• ACID 특성을 기반으로 병행 제어와 트랜잭션 제어를 제공하여 다중 사용자 접속 상황에서 데이터 충돌을 방지하고, 데이터의 무결성과 일관성을 보장
  • 원자성: 트랜잭션은 완전히 수행되거나 전혀 수행되지 않아야 함
  • 일관성: 트랜잭션 전 후의 데이터베이스의 일관성
  • 격리성: 여러 트랜잭션 동시 실행 시, 다른 트랜잭션과 격리되어 진행
  • 지속성: 트랜잭션 성공 이후 결과가 영구적으로 저장

트랜잭션

트랜잭션은 데이터베이스에서 수행되는 단일 논리적 작업 단위이다.

하나 이상의 데이터베이스 작업이 모두 성공하거나 실패할때까지 모두 적용되거나 모두 롤백되어야 하는 작업 그룹을 의미한다.

트랜잭션은 데이터의 무결성과 일관성을 유지하기 위해 사용된다.

면접 답변

RDBMS는 데이터를 관계형 데이터베이스인 RDB를 관리하는 소프트웨서 시스템으로, 데이터를 테이블 구조로 저장하고, 테이블의 관계를 명확히 정의하여 데이터를 효율적으로 생성, 수정, 검색하는 소프트웨어 시스템입니다.

RDBMS는 보통 SQL을 통해 RDB를 조작합니다.

또한 RDBMS는 ACID원칙을 기반으로 병행제어와 트랜잭션을 제공하여 다중 사용자 접속 환경에서 데이터 충돌을 방지합니다.

RDBMS의 트랜잭션은 데이터베이스에서 하나 이상의 SQL 연산을 묶어 하나의 논리적 작업 단위로 실행하는 개념입니다. 예를 들어, 은행 계좌 이체시, 출금과 입금이 하나의 트랜잭션으로 실행되어야 하며, 만약 하나라도 실패하면 전체 작업이 롤백되어 데이터 정합성이 지켜져야 합니다.

이러한 특징 덕분에 RDBMS는 기업의 대규모 데이터 관리, 금융 시스템, 전자 상거래 등에서 널리 사용됩니다.

데이터 독립성은 데이터베이스 시스템의 중요한 특성으로, 하위 스키마의 변경이 상위 스키마에 영향을 미치지 않도록 보장하는 원칙이다.

• 데이터베이스의 유연성과 유지보수 용이성을 높여, 변경 사항이 다른 영역에 미치는 영향을 최소화 한다.
• 파일 시스템은 데이터 구조 변경 시 모든 응용 프로그램을 수정해야하는 종속성 문제가 발생했지만, 데이터베이스에서는 독립성을 통해 이러한 종속성 문제를 해결한다.

논리적 데이터 독립성 (응용 인터페이스 독립성 유지)

논리적 데이터 독립성이란, 개념 스키마(데이터베이스의 논리적 구조)가 변경되더라도, 외부 스키마(사용자 관점에서 보는 데이터 구조)에 영향을 주지 않는 것을 의미합니다.

• 예를 들어, 새로운 속성을 추가하더라도 기존 응용 프로그램이 영향을 받지 않도록 보장합니다.

물리적 데이터 독립성 (저장 인터페이스 독립성 유지)

• 내부 스키마가 변경되어도 개념 스키마는 영향을 받지 않는다.

  물리적 데이터 독립성이란, 내부 스키마(데이터의 물리적 저장 방식)가 변경되더라도 개념 스키마(논리적 데이터 구조)에 영향을 미치지 않는 것을 의미한다.

• 예를 들어, 성능 최적화를 위해 저장소를 SSD로 변경하더라도 데이터베이스의 논리적 구조는 그대로 유지됩니다.

면접 답변

데이터 독립성은 데이터베이스 시스템의 중요한 특성으로, 하위 스키마의 변경이 상위 스키마에 영향을 미치지 않도록 보장하는 것입니다.

이를 통해 데이터베이스의 유지보수성과 확장성을 높이고, 기존의 파일 시스템에서 발생하던 데이터 종속성 문제를 해결할 수 있습니다.

데이터 독립성은 논리적 데이터 독립성과 물리적 데이터 독립성으로 나뉩니다.

논리 데이터 독립성은 개념 스키마의 변경이 외부 스키마에 영향을 주지 않게 합니다. 예를 들어, 테이블에 새로운 속성이 추가되더라도 기존 응용 프로그램이 정상적으로 작동할 수 있도록 보장합니다.

물리 데이터 독립성은 내부 스키마의 변경이 개념 스키마에 영향을 미치지 않도록 보장합니다. 예를 들어, 성능 최적화를 위해 하드디스크에서 SSD로 변경하거나, 데이터 저장 구조를 변경하더라도 개념 스키마는 그대로 유지됩니다.

데이터베이스 스키마는 관계형 데이터베이스에서 데이터의 구조를 정의하는 설게도를 의미한다. 이는 테이블, 필드, 데이터 유형, 관계 및 제약조건 등을 포함하여 데이터를 어떻게 정리하고 관리할지에 대한 규칙을 설정한다.

(스키마의 목적은 명확히 데이터 구조를 정의하는 것!!)

스키마에 포함되는 것들

• 개체의 특성을 나타내는 속성
• 속성들의 집합으로 이루어진 개체
• 개체 사이에 존재하는 관계에 대한 정의
• 속성, 개체, 관계들이 유지해야할 제약조건들

3단계 데이터베이스 구조

데이터베이스를 쉽게 이해하고 이용할 수 있도록 하나의 데이터베이스를 관점에 따라 세 단계로 나눈 것이다.

1. 외부 단계
2. 개념 단계
3. 내부 단계

1. 외부 단계 - 개별 사용자 관점

데이터 베이스 하나에 외부 스키마 여러 개가 존재할 수 있다.

외부 스키마 = 서브 스키마

• 외부 단계는 사용자와 응용 프로그램에 맞게 필요한 데이터베이스 구조를 정의하며, 각 사용자는 자신이 필요한 데이터만을 볼 수 있다.
• 각 사용자가 생각하는 데이터베이스의 모습으로, 논리적 구조로 사용자마다 다른 모습이다.

2. 개념 단계 = 조직 전체의 관점/논리적 구조와 유사

개념 단계에서는 데이터베이스 전체의 논리적 구조를 정의하며, 하나의 데이터베이스에는 개념 스키마가 하나만 존재한다.

개념 스키마 = 스키마

• 개념 단계에서 데이터베이스 전체의 논리적 구조를 정의한 것
• 조직 전체의 관점에서 생각하는 데이터베이스 모습
• 전체 데이터베이스에서 어떤 데이터가 저장되는지, 데이터들 간에는 어떤 관계가 존재하고
• 어떤 제약조건*이 존재하는지에 대한 정의뿐만 아니라, 데이터에 대한 보안 정책이나 접근 권한에 대한 정의도 포함 => (데이터를 효과적으로 관리하기 위한 다양한 기능 개념)

3. 내부 단계 - 물리적인 저장 장치의 관점 / 실질적인 내용

데이터 베이스 하나에 내부 스키마가 하나만 존재

내부 스키마 = 저장 스키마

• 전체 데이터베이스가 저장 장치에 실제로 저장되는 방법을 정의한 것
• 레코드 구조, 필드 크기, 레코드 접근 경로 등 물리적인 저장 구조를 정의

3단계 데이터베이스 구조 분류

3단계 데이터베이스 구조의 사상 또는 매핑

데이터베이스를 3단계 구조로 나누고, 단계별로 스키마를 유지하며 스키마 사이의 대응관계를 정의하는 것이 목적이다.

1. 외부/개념 사상 - 응용 인터페이스

• 외부 스키마 - 개념 스키마의 대응 관계
• 외부/개념 사상은 응용 프로그램과 데이터베이스 시스템 간의 인터페이스 역할을 하며, 사용자가 필요로 하는 데이터를 개념 스키마의 구조에 맞춰 제공하는 기능을 한다.

2. 개념/내부 사상 - 저장 인터페이스

개념 스키마 - 내부 스키마의 대응 관계

데이터 독립성

• 데이터 독립성은 데이터베이스 시스템의 중요한 특성으로, 하위 스키마의 변경이 상위 스키마에 영향을 미치지 않도록 보장하는 원칙이다.
• 데이터베이스의 유연성과 유지보수 용이성을 높여준다.
• 파일 시스템의 종속성 문제를 해결한다.

논리적 데이터 독립성 (응용 인터페이스 독립성 유지)

• 개념 스키마가 변경되어도 외부 스키마가 영향을 받지 않는다.
• 개념 스키마가 변경되면 관련된 외부/개념 사상만 정확히 수정해주면 된다.

물리적 데이터 독립성 (저장 인터페이스 독립성 유지)

• 내부 스키마가 변경되어도 개념 스키마는 영향을 받지 않는다.
• 내부 스키마가 변경되면 관련된 개념/내부 사상만 정확히 수정해주면 된다.

데이터베이스 종류

데이터 사전 - 시스템 카탈로그

데이터베이스에 저장되는 데이터에 관한 정보, 데이터를 설명, 관리하기 위한 시스템 데이터베이스

메타 데이터

데이터에 대한 데이터

스키마, 사상 정보, 다양한 제약 조건 등을 저장

데이터 디렉토리

데이터 사전에 있는 데이터에 실제로 접근하는데 필요한 위치 정보를 저장하는 시스템 데이터베이스

사용자 데이터베이스

사용자가 실제로 이용하는 데이터가 저장되어 있는 일반 데이터베이스

면접 답변

스키마(Schema)는 데이터베이스의 구조를 정의하는 설계도로, 데이터베이스 내에서 데이터를 어떻게 저장하고 관리할지를 규명하는 역할을 합니다. 관계형 데이터베이스에서는 테이블, 필드, 데이터 형식, 관계 및 제약 조건 등을 포함하여 데이터를 논리적으로 구조화합니다. 이를 통해 데이터 간의 관계를 명확히 하고, 데이터 무결성 및 일관성을 유지할 수 있습니다.

3단계 데이터베이스 구조는 데이터베이스를 보다 효율적으로 이해하고 관리하기 위한 분류로, 크게 외부 단계, 개념 단계, 내부 단계로 나눕니다.

외부 단계는 사용자나 응용 프로그램이 필요로 하는 데이터베이스의 구조를 정의하며, 외부 스키마는 사용자가 보는 데이터베이스의 모습을 제공합니다. 각 사용자는 자신이 필요한 데이터만을 볼 수 있습니다.

개념 단계는 데이터베이스 전체의 논리적 구조를 정의하며, 하나의 데이터베이스에는 개념 스키마가 하나만 존재합니다. 이 단계에서는 데이터 간의 관계와 제약 조건을 정의하고, 데이터베이스 관리자가 보안 정책 및 접근 권한도 설정합니다.

내부 단계는 데이터가 물리적으로 저장되는 방식에 대한 정의입니다. 내부 스키마는 레코드 구조, 필드 크기, 데이터 접근 경로 등 저장 장치에서 데이터가 실제로 어떻게 관리되는지에 대한 세부 정보를 다룹니다.

면접 답변

DBMS는 데이터를 효율적으로 저장하고 관리할 수 있도록 지원하는 소프트웨어 시스템입니다. 특히 RDBMS는 RDB를 관리하는 시스템으로, 데이터를 테이블 형태로 저장하며, 테이블간의 관계를 명확하게 정의하여 일관성 있는 데이터 관리를 지원합니다. DBMS는 ACID 원칙을 기반으로 트랜잭션과 병행제어 기능을 제공합니다. 이를 통해 데이터의 무결성, 일관성을 보장하며 동시 접근 시에도 데이터 충돌을 방지할 수 있습니다. 따라서 대규모 데이터 관리에 유리합니다.

데이터베이스는 구조화된 데이터의 조직화된 모음.

데이터베이스의 특징

• 데이터베이스는 일반적으로 DBMS에 의해 제어되며, 관계형 데이터베이스에서는 RDBMS가 사용된다.
  • DBMS의 예시: MySQL, Oracle, ...
• 일반적인 유형의 데이터베이스는 데이터 처리 및 데이터 쿼리를 효율적으로 수행하기 위해 테이블의 형태로 데이터를 저장한다.
• 대부분의 데이터 베이스는 데이터 조작에 SQL(Structured Query Language)을 사용한다.

SQL(Structured Query Language)

SQL은 데이터를 쿼리, 조작 및 정의하고 제어를 제공하기 위해 거의 모든 관계형 데이터베이스에서 사용하는 프로그래밍 언어이다.

데이터베이스의 종류

계층형 데이터베이스

폴더와 파일 등의 계층 구조로 데이터를 저장하는 방식

• 데이터의 관계를 트리 구조로 정의, 부모-자식 형태 => 1:N 만 가능
• 종류: IBM의 IMS, Windows Registry, ...
• 장점
  • 데이터 접근 속도 빠름
  • 데이터 사용량 예측이 쉬움
• 단점
  • 상하 종속적인 관계로 초기 세팅 후 변경이 어렵고, 복잡한 쿼리가 힘들다.

관계형 데이터베이스

행과 열을 가지는 테이블 형식으로 데이터를 저장하는 데이터베이스

• SQL을 이용하여 관리 및 접근
• 종류: Oracle, DB2, SQL Server, Mysql, ...
• 장점:
  • 높은 범용성과 성능
  • 데이터 무결성 보장
  • 명확한 스키마와 테이블간의 관계 정의
  • 검색 속도가 빠름
  • 데이터 중복을 줄임
• 단점:
  • 수직 확장을 통해 성능을 향상시키며, 수평확장은 샤딩등의 추가적인 기술이 필요하다.

NoSQL

NoSQL은 저장 방식이 유연하며, 문서형, 키-값, 열 지향, 그래프 등의 여러 유형이 있다.

• 스키마가 없고, 관계도 없다.
• 정확한 데이터 요구 사항을 알 수 없거나 관계를 맺는 데이터가 자주 변경될 때 사용된다.

RDB와 NoSQL의 차이점

• NoSQL은 비정형 데이터(메시지 텍스트, 음성, 이미지 등)을 다룰 수 있다.
• NoSQL은 수평 확장이 가능하며 분산형 컴퓨팅(클라우드 환경)에 적합하다.
• 예시: MongoDB, Redis, ...
• 장점:
  • 스키마가 없어 데이터 추가가 유연하다.
  • 속도가 빠르다.
• 단점:
  • 데이터 중복이 생길 수 있다.

면접 답변

데이터 베이스는 구조화된 데이터를 저장하고 관리하는 시스템입니다. 일반적으로 데이터베이스는 DBMS에 의해 제어되며, 관계형 데이터베이스에서는 RDBMS가 주로 사용됩니다. 관계형 데이터베이스는 테이블 형태로 데이터를 저장하고 SQL을 통해 데이터를 조작합니다. 반면 NoSQL은 Key-Value, 문서, 그래프 등의 다양한 형태로 데이터가 저장되어 스키마 없이 유연한 확장이 가능합니다. RDB는 데이터 무결성과 정규화를 보장하는 반면, NoSQL은 수평확장에 용이하고 대량의 비정형 데이터를 처리하는데 적합합니다.

(*정규화: 데이터를 논리적으로 분리하여 중복을 줄이고, 데이터 무결성을 유지하는 과정