AP 과목 A 35 — 분산 데이터베이스와 데이터 웨어하우스: 분할·복제·CAP·2단계 커밋에서 ETL·OLAP까지
응용정보기술자시험 과목 A 보충편. 수평·수직 분할과 샤딩, 복제와 일관성, 네트워크 분단 시의 CAP, 2단계 커밋, DWH·데이터 마트·ETL/ELT·스타 스키마·OLAP 조작을 풀이 예제와 오리지널 5문항으로 정리합니다.
AP 과목 A 제35편 · 2026년도·실라버스 Ver.7.2 기준의 독립 학습 자료입니다. IPA와 제휴하지 않으며 합격을 보장하지 않습니다. 시리즈 허브 보기
2026년 IPA 응용정보기술자시험(AP) 과목 A, Syllabus Ver.7.2 기준이며 2026-10-22 확인했다. Motitory의 독립 학습 자료로 IPA와 제휴하거나 IPA의 승인·검토를 받지 않았다. Ver.7.2 전 범위나 분산 데이터베이스·데이터 웨어하우스 기술 전체를 빠짐없이 다루지 않으며 합격을 보장하지 않는다. 본문의 예제와 문제는 모두 Motitory가 만든 오리지널이며 IPA 기출이 아니다.
학습 인덱스
- 한눈에 보는 용어
- 분산 데이터베이스와 투과성
- 데이터 분할
- 복제와 일관성
- 네트워크 분단과 CAP
- 분산 질의와 조인
- 2단계 커밋
- 데이터 웨어하우스와 OLTP
- ETL과 ELT
- 팩트와 디멘션
- OLAP 조작
- 퀵 시트와 함정
- 오리지널 진단 5문제
- 셀프 체크와 복습 일정
- 공식 출처
이 글은 고정된 마무리 계획 AP33–38 가운데 AP35(보충편)이며 시리즈의 마지막 글이 아니다. 전체 목록은 시리즈 허브에 있다. 다음 내용은 이미 다뤘으므로 다시 설명하지 않는다.
- 클라우드·가상화·부하 분산·분산 처리 일반: AP10
- 키·함수 종속·정규화: AP13
- SQL·조인의 의미·집계·NULL: AP14
- 단일 DBMS 안의 ACID·격리 수준·WAL·장애 복구: AP15
- 인덱스·성능·접근 제어 등 DB 종합 진단: AP32
여기서는 데이터가 여러 사이트(노드)에 놓일 때 새로 생기는 문제와 분석용 데이터베이스(DWH)만 다룬다.
1. 한눈에 보는 용어
| 한국어 | 日本語(시험 용어) | English | 한 줄 정의 |
|---|---|---|---|
| 분산 데이터베이스 | 分散データベース | distributed database | 여러 사이트에 놓인 데이터를 하나의 DB처럼 쓰게 하는 구성 |
| 수평 분할 | 水平分割 | horizontal partitioning | 행(레코드)을 조건에 따라 나눔. 합집합으로 복원 |
| 수직 분할 | 垂直分割 | vertical partitioning | 열(속성)을 나눔. 각 조각에 기본 키를 남겨 조인으로 복원 |
| 샤딩 | シャーディング | sharding | 수평 분할한 조각(샤드)을 서로 다른 서버에 배치 |
| 복제(레플리케이션) | レプリケーション | replication | 같은 데이터의 사본을 여러 사이트에 유지 |
| 분산 투과성 | 分散透過性(位置透過性など) | distribution transparency | 이용자가 데이터의 위치·분할·복제를 의식하지 않아도 되는 성질 |
| 2단계 커밋 | 2相コミット(2相コミットメント) | two-phase commit (2PC) | 준비·투표 후 전원 커밋 또는 전원 롤백을 정하는 분산 트랜잭션 프로토콜 |
| 스플릿 브레인 | スプリットブレイン | split brain | 분단된 양쪽이 각자 주(primary)로 동작해 데이터가 갈라지는 상태 |
| 강한 일관성 | 強い一貫性 | strong consistency | 커밋된 최신 값을 어느 사본에서 읽어도 얻음 |
| 결과 일관성(최종 일관성) | 結果整合性 | eventual consistency | 새 갱신이 멈추면 사본들이 결국 같은 값으로 수렴 |
| CAP 정리 | CAP定理 | CAP theorem | 네트워크 분단 중에는 일관성과 가용성을 동시에 완전히 만족할 수 없다는 정리 |
| BASE | BASE | basically available, soft state, eventually consistent | ACID와 대비되는 설계 방침(보증이 아님) |
| 데이터 웨어하우스 | データウェアハウス | data warehouse (DWH) | 여러 시스템의 데이터를 통합해 이력과 함께 축적한 분석용 DB |
| 데이터 마트 | データマート | data mart | 특정 부서·목적용으로 좁힌 분석 DB |
| ETL | ETL(抽出・変換・書出し) | extract, transform, load | 추출 → 변환 → 적재 |
| 데이터 클렌징 | データクレンジング | data cleansing | 표기 흔들림·중복·결손·오류를 바로잡음 |
| 팩트 테이블 | ファクトテーブル | fact table | 측정값(매출액 등)과 디멘션 외래 키를 가진 중심 테이블 |
| 디멘션 테이블 | ディメンションテーブル | dimension table | 분석 축(상품·지역·기간)의 속성을 가진 테이블 |
| 스타 스키마 | スタースキーマ | star schema | 팩트 테이블 주위에 디멘션 테이블을 별 모양으로 둔 구조 |
| OLAP | OLAP | online analytical processing | 다차원으로 집계·분석하는 처리 |
| OLTP | OLTP | online transaction processing | 짧은 갱신 트랜잭션을 대량 처리하는 업무 시스템 |
2. 분산 데이터베이스와 투과성
분산 데이터베이스는 네트워크로 연결된 여러 사이트의 데이터를 이용자에게 하나의 데이터베이스처럼 보이게 한다. 이때 요구되는 성질이 투과성(透過性)이며, 시험에서는 다음 종류를 구별한다.
| 투과성 | 日本語 | 이용자가 의식하지 않아도 되는 것 |
|---|---|---|
| 위치 투과성 | 位置透過性 | 데이터가 어느 사이트에 있는지 |
| 이동 투과성 | 移動透過性 | 데이터가 다른 사이트로 옮겨졌는지 |
| 분할 투과성 | 分割透過性 | 테이블이 여러 조각으로 나뉘어 있는지 |
| 복제(중복) 투과성 | 重複透過性(複製透過性) | 같은 데이터의 사본이 여러 곳에 있는지 |
| 장애 투과성 | 障害透過性 | 일부 사이트·회선의 장애 |
| 병행 투과성 | 並行透過性 | 다른 사이트의 트랜잭션과 동시에 실행되는지 |
투과성은 SQL과 응용 프로그램을 바꾸지 않아도 된다는 뜻이지, 성능이나 장애 영향이 사라진다는 뜻이 아니다. 원격 사이트를 읽으면 통신 지연이 생기고, 4–5절처럼 장애와 분단은 일관성·가용성의 선택을 강요한다.
3. 데이터 분할
| 방식 | 나누는 단위 | 복원 방법 | 주의 |
|---|---|---|---|
| 수평 분할(水平分割) | 행. 예: 연도별, 지역별 | 조각들의 합집합(UNION) | 조각들은 서로 다른 행을 가진다. 사본이 아니다 |
| 수직 분할(垂直分割) | 열. 예: 자주 쓰는 열과 드문 열 | 각 조각에 남긴 기본 키로 조인 | 키를 빠뜨리면 원래 행으로 되돌릴 수 없다 |
| 샤딩(シャーディング) | 수평 분할 + 조각마다 별도 서버 | 샤드 키로 담당 서버를 찾음 | 샤드 키 선택이 나쁘면 한 서버에 몰린다(핫스폿) |
- 분할과 복제는 다르다. 수평 분할은 행을 나눠 겹치지 않게 두는 것이고, 복제는 같은 데이터를 겹치게 여러 벌 두는 것이다. 실제 시스템은 둘을 조합하기도 한다(각 샤드를 다시 복제).
- 분할과 샤딩의 관계: 같은 DBMS 안에서 테이블을 파티션으로 나누는 것도 수평 분할이다. 샤딩은 그 조각을 독립된 서버들에 흩어 두는 경우를 가리키는 말로, 샤드를 넘나드는 질의·트랜잭션은 6–7절의 분산 처리가 된다.
풀이 예제 1 — 분할 프루닝과 복제의 저장량
가정: 매출 테이블 12,000,000행, 평균 행 크기 600바이트 고정. 용량은 10진 단위(1 GB = 10^9바이트)이며 인덱스·로그·페이지 관리 영역·압축은 무시한 원시 데이터 크기다.
- 원시 크기: 12,000,000 × 600 = 7,200,000,000바이트 = 7.2 GB.
- 수평 분할: 판매 연도로 5개 파티션, 각 2,400,000행(균등하다고 가정). 질의 조건이 최근 3년이고 파티션 키와 일치하면, 이상적으로는 3개 파티션만 읽는다(파티션 프루닝). 읽는 행 = 3 × 2,400,000 = 7,200,000행.
- 감소율: (12,000,000 − 7,200,000) ÷ 12,000,000 = 4,800,000 ÷ 12,000,000 = 40% 적게 스캔. 읽는 원시 데이터는 7,200,000 × 600 = 4.32 GB. 다만 행 수가 40% 줄어도 응답 시간이 정확히 40% 줄어든다는 보장은 없다(캐시·인덱스·병렬도에 좌우).
- 복제: 전체 사본 3벌(원본 포함 합계 3벌)을 두면 7.2 × 3 = 21.6 GB(오버헤드 전 원시 크기). 수평 분할은 저장량을 늘리지 않지만 복제는 사본 수만큼 늘린다.
- (참고) 수직 분할: 600바이트 = 키 8 + 자주 쓰는 열 92 + 드문 열 500바이트라고 하자. 두 조각 모두 키를 가지므로 조각 행은 100바이트와 508바이트, 합계 608바이트로 키만큼 늘어난다. 자주 쓰는 열만 읽는 질의는 12,000,000 × 100 = 1.2 GB만 읽으면 된다. 두 조각을 키로 조인하면 원래 행이 복원된다.
4. 복제와 일관성
| 방식 | 커밋 응답 시점 | 장점 | 단점 |
|---|---|---|---|
| 동기 복제 | 사본 측 수신(또는 기록) 확인 후 | 커밋 응답에 사용한 내구성 있는 사본에는 확인된 갱신이 있음. 그 사본으로 페일오버하면 그 갱신을 잃지 않음 | 응답 지연 증가. 사본에 닿지 못하면 갱신이 멈추거나 지연 |
| 비동기 복제 | 주(primary)에 기록하면 바로 | 응답이 빠르고 원거리에도 적합 | 복제 지연(래그) 동안 사본 읽기가 오래된 값. 아직 전달되지 않은 갱신은 주가 고장 나 전환할 때 잃을 수 있음 |
- 강한 일관성: 커밋된 최신 값을 어느 사본에서 읽어도 얻는다. 그 대가로 사본 간 조정이 필요해 지연이 늘고, 분단 시 일부 요청을 거부해야 할 수 있다.
- 결과 일관성(結果整合性): 새 갱신이 멈추면 모든 사본이 결국 같은 값으로 수렴한다는 보증이다. 그 사이에는 오래된 값을 읽을 수 있다. “확인된 갱신을 마음대로 잃어도 된다”는 뜻이 아니다. 내구성(확인 전에 몇 곳에 기록하는가)과 동시 갱신 충돌 해결 규칙은 별도로 설계·명시해야 한다.
- 복제는 백업이 아니다. 실수로 지운 행이나 응용 버그로 깨진 데이터도 그대로 사본에 전달된다. 특정 시점으로 되돌리려면 별도의 백업과 로그가 필요하다(복구 원리는 AP15).
- 스플릿 브레인(スプリットブレイン): 주·대기 두 사이트 사이의 회선만 끊겼는데 대기 측이 “주가 죽었다”고 판단해 승격하면, 양쪽이 각자 갱신을 받아 데이터가 갈라진다. 대책은 과반수(쿼럼)로만 주를 정하는 것(3노드면 2노드 이상 쪽만 갱신 허용), 제3의 감시 노드(위트니스), 옛 주를 확실히 차단하는 펜싱이다. 과반수를 얻지 못한 쪽은 갱신을 멈추므로, 일관성을 위해 그쪽의 가용성을 포기하는 선택이다.
5. 네트워크 분단과 CAP
CAP 정리의 정확한 의미: 데이터를 복제한 분산 시스템에서 네트워크 분단(P)이 일어나 있는 동안에는, 다음 둘을 동시에 완전히 만족할 수 없다.
- C(일관성): 모든 읽기가 최신 쓰기 결과를 돌려주거나 오류가 된다.
- A(가용성): 고장 나지 않은 노드에 온 모든 요청이 (오류가 아닌) 응답을 받는다.
분단 중에 양쪽이 계속 응답하면(A 우선) 서로의 갱신을 모르므로 오래되거나 충돌하는 값을 돌려줄 수 있다. 일관성을 지키려면(C 우선) 한쪽(보통 과반수를 얻지 못한 쪽)이 요청을 거부하거나 기다려야 한다.
- “셋 중 아무거나 둘을 고른다”는 흔한 설명은 부정확하다. 실제 네트워크에서 분단은 일어날 수 있는 장애이므로 선택은 분단이 일어났을 때 C와 A 사이에서 생긴다.
- 분단이 없을 때 CAP는 아무것도 강요하지 않는다. 정상 시에는 C와 A를 함께 제공할 수 있다. 다만 정상 시에도 사본 간 조정을 기다리느냐(일관성)와 빨리 응답하느냐(지연)의 상충은 남는데, 이것은 CAP의 주장이 아니라 별개의 설계 문제다.
- BASE(Basically Available, Soft state, Eventually consistent)는 가용성과 결과 일관성을 우선하는 설계 방침을 ACID와 대비해 부르는 말이다. 어떤 성질을 보증하는 규격이 아니며, BASE라고 해서 ACID의 원자성을 제공하는 것도 아니다.
6. 분산 질의와 조인
조인의 의미와 SQL 문법은 AP14와 같다. 분산 환경에서 달라지는 것은 어디서 계산하고 무엇을 보내느냐다. 분산 질의에서는 사이트 간 전송량이 비용을 크게 좌우한다.
- 선택·사영을 먼저: 각 사이트에서 조건(WHERE)과 필요한 열만 남긴 뒤 보낸다.
- 작은 쪽을 보내기: 큰 테이블을 통째로 옮기지 말고 작은 쪽을 큰 쪽 사이트로 보내 조인한다.
- 세미 조인(セミジョイン): 사이트 A가 조인 열의 값만 사이트 B로 보내고, B는 그 값과 일치하는 행만 A로 돌려준다. 그다음 A에서 조인을 마친다. 조인에 참여하지 않는 행을 보내지 않으므로 전송량이 줄어든다. 조인 열 값을 보내는 비용이 줄어드는 행보다 크면 이득이 없다.
- 분할과의 관계: 조건이 파티션 키와 맞으면 관련 없는 사이트를 아예 읽지 않을 수 있다(풀이 예제 1). 샤드 키가 아닌 열로 조인·검색하면 모든 샤드에 질의를 보내야 할 수 있다.
7. 2단계 커밋
여러 사이트를 갱신하는 하나의 트랜잭션이 모두 커밋되거나 모두 롤백되게 하는 프로토콜이 2단계 커밋(2相コミット)이다. 조정자(コーディネータ)와 참가자(参加者)로 구성된다. 단일 DBMS 안의 원자성·로그는 AP15에서 다뤘다.
- 1단계(준비·투표): 조정자가 모든 참가자에게 PREPARE를 보낸다. 각 참가자는 커밋에 필요한 내용을 안정 기억장치의 로그에 기록하고 YES(커밋할 수 있음을 약속) 또는 NO를 투표한다. NO를 낸 참가자는 자기 쪽을 롤백한다.
- 2단계(결정): 전원이 YES면 조정자는 COMMIT 결정을 로그에 기록한 뒤 COMMIT을 보낸다. 하나라도 NO이거나 시간 안에 투표가 오지 않으면 ABORT를 보낸다. 참가자는 결정에 따라 커밋 또는 롤백하고 확인 응답을 돌려준다.
차단(블로킹) 문제: YES를 투표한 참가자는 결정을 받기 전까지 혼자 커밋할 수도(다른 참가자가 NO였을 수 있다), 혼자 롤백할 수도(조정자가 이미 COMMIT을 정하고 다른 참가자가 커밋했을 수 있다) 없다. 이 불확실(in-doubt) 상태에서 조정자가 고장 나면 참가자는 잠금을 쥔 채 결정을 알 때까지 기다린다. 아직 투표하지 않은 참가자는 스스로 롤백할 수 있다. 따라서 2PC는 원자성을 위한 프로토콜이며 가용성을 제공하지 않는다. 차단을 줄이는 3단계 커밋이나 합의 알고리즘은 이 글의 범위 밖이다.
풀이 예제 2 — 2PC의 세 가지 경우
주문 하나가 재고 DB(사이트 X)의 재고 감소와 결제 DB(사이트 Y)의 결제 기록을 함께 갱신한다. 조정자는 주문 서버다.
| 경우 | 1단계 투표 | 조정자 결정 | 결과 |
|---|---|---|---|
| (a) | X: YES, Y: YES | COMMIT을 로그에 기록 후 송신 | X·Y 모두 커밋, 확인 응답 후 종료 |
| (b) | X: YES, Y: NO(한도 초과) | ABORT | Y는 이미 롤백, X도 ABORT를 받아 롤백. 재고는 줄지 않는다 |
| (c) | X: YES, Y: YES(각 참가자는 자기 투표를 보냄) | 조정자가 두 투표를 모두 받았다고 보장되기 전이며, 결정이 어느 참가자에게도 닿기 전에 조정자 고장 | X·Y 모두 불확실 상태. 서로 두 참가자가 YES를 보냈다고 확인해도, 조정자가 제한 시간 안에 둘 다 받아 COMMIT을 기록했는지, 한 투표를 받지 못해 ABORT를 기록했는지 알 수 없다. 조정자가 복구해 로그의 결정을 다시 보낼 때까지 잠금을 쥔 채 차단된다 |
(b)의 핵심은 “하나라도 NO면 전원 롤백”, (c)의 핵심은 “YES 후에는 혼자 결정할 수 없다”이다.
8. 데이터 웨어하우스와 OLTP
| 관점 | OLTP(업무 시스템) | 데이터 웨어하우스(DWH) |
|---|---|---|
| 목적 | 주문·결제 등 업무 처리 | 의사 결정을 위한 분석 |
| 처리 | 짧은 갱신 트랜잭션 다수 | 대량 행을 읽는 집계 질의 |
| 데이터 | 현재 값 중심 | 이력(시계열) 축적 |
| 출처 | 대체로 한 업무 | 여러 시스템을 통합 |
| 설계 | 갱신 이상을 막는 정규화 중심 | 집계하기 쉬운 스타 스키마 등(디멘션은 비정규화하기도 함) |
| 갱신 | 수시로 갱신·삭제 | 주로 정기 적재, 적재한 이력은 덮어쓰지 않음 |
DWH의 특징은 흔히 주제 지향(サブジェクト指向)·통합(統合)·시계열(時系列)·비휘발(不揮発) 네 가지로 요약된다. 그래서 DWH는 OLTP DB를 그대로 복사한 것이 아니다. 여러 출처의 코드·표기를 통합하고 정제(9절)한 뒤 분석용 구조(10절)로 이력과 함께 쌓는다.
데이터 마트(データマート): DWH(또는 출처)에서 특정 부서·목적(예: 영업 분석)에 필요한 데이터만 골라 만든 작은 분석 DB.
9. ETL과 ELT
| 방식 | 순서 | 어디서 변환하나 | 특징 |
|---|---|---|---|
| ETL | 추출 → 변환 → 적재 | 적재 전, 별도의 변환 처리에서 | 정제된 데이터만 DWH에 들어감 |
| ELT | 추출 → 적재 → 변환 | 적재 후, DWH 안에서 | 원시 데이터를 먼저 넣고 DWH의 처리 능력으로 변환. 원시 데이터를 다시 변환할 수 있음 |
데이터 클렌징(データクレンジング): 표기 흔들림(전각/반각, 법인명 표기) 통일, 코드 체계 통일, 중복 레코드 병합(名寄せ), 결손값·범위 밖 값 처리. 규칙에 맞지 않는 행은 버리지 않고 거부 목록에 남겨 원인을 추적하는 것이 일반적이다.
풀이 예제 3 — 일일 적재 건수
가정: 출처 A가 하루 1,200,000행, 출처 B가 하루 800,000행을 보낸다. 합친 입력 중 2%의 행이 클렌징에서 거부되거나 기존 행에 병합되어 새 행으로 적재되지 않는다고 가정한다. 30일 동안 매일 같은 양이라고 가정한다.
- 합친 입력: 1,200,000 + 800,000 = 2,000,000행/일.
- 거부·병합: 2,000,000 × 0.02 = 40,000행.
- 적재: 2,000,000 − 40,000 = 1,960,000행/일.
- 30일: 1,960,000 × 30 = 58,800,000행.
주의: 2%를 출처 B에만 적용하면 2,000,000 − 16,000 = 1,984,000으로 다른 답이 된다. 비율을 무엇에 적용하는지를 문제에서 반드시 확인한다.
10. 팩트와 디멘션
- 팩트 테이블(ファクトテーブル): 분석 대상이 되는 사건의 측정값(매출액, 수량)과 각 디멘션을 가리키는 외래 키를 가진다. 일반적으로 행 수가 가장 많다.
- 디멘션 테이블(ディメンションテーブル): 분석 축의 속성. 예: 상품(상품명·분류), 지역(점포·도시·지방), 기간(일·월·분기·연).
- 스타 스키마(スタースキーマ): 팩트 테이블을 중심으로 디멘션 테이블이 한 단계씩 연결된 구조. 조인이 단순해 집계하기 쉽다. 디멘션을 다시 정규화해 가지를 친 형태를 스노플레이크 스키마(スノーフレークスキーマ)라고 한다.
11. OLAP 조작
데이터를 상품 × 지역 × 월 같은 다차원 큐브로 보고 다음 조작으로 분석한다.
| 조작 | 日本語 | 하는 일 | 예 |
|---|---|---|---|
| 롤업 | ロールアップ | 더 거친 수준으로 집계 | 월별 → 분기별 |
| 드릴다운 | ドリルダウン | 더 상세한 수준으로 내려감 | 분기별 → 월별 → 일별 |
| 슬라이스 | スライス | 한 차원을 하나의 값으로 고정해 단면을 봄 | 지역 = R1인 상품 × 월 표 |
| 다이스 | ダイス | 여러 차원에서 범위를 골라 작은 큐브를 잘라 냄 | 상품 P1–P5 × 지역 R1–R3 × 1–3월 |
| 피벗 | ピボット(回転) | 행·열 축을 바꿔 보는 관점을 바꿈. 집계값 자체는 변하지 않음 | 행=상품/열=월 → 행=월/열=상품 |
풀이 예제 4(선택) — 큐브 셀 수
상품 40 × 지역 10 × 월 12 = 4,800셀이 최대 칸 수다. 실제로 판매가 있는 조합이 1,500개뿐이라면 3,300셀은 비어 있다(희소). 월을 분기(4)로 롤업하면 최대 칸 수는 40 × 10 × 4 = 1,600셀이 된다.
12. 퀵 시트와 함정
- 수평 분할 = 행, 합집합으로 복원. 수직 분할 = 열, 기본 키 조인으로 복원. 샤딩 = 수평 분할 조각을 서버별로.
- 분할 ≠ 복제. 복제 ≠ 백업. 비동기 복제 = 래그 동안 오래된 읽기, 전환 시 미전달 갱신 손실 가능.
- 결과 일관성 = 갱신이 멈추면 수렴. 임의 손실 허용이 아니다.
- CAP = 분단 중 C와 A 중 선택. 분단이 없으면 CAP는 강요하지 않는다. BASE = 방침이지 보증이 아니다.
- 스플릿 브레인 → 쿼럼·위트니스·펜싱.
- 2PC = 준비·투표 → 전원 YES면 커밋, 하나라도 NO면 중단. YES 후 조정자 고장 → 불확실 상태로 차단. 2PC는 가용성을 주지 않는다.
- 분산 조인 = 전송량 최소화, 세미 조인.
- DWH = 주제 지향·통합·시계열·비휘발. OLTP의 단순 복사가 아니다. 데이터 마트 = 목적별 부분.
- ETL = 변환 후 적재, ELT = 적재 후 DWH 안에서 변환. 클렌징 = 통일·중복 병합·결손 처리.
- 롤업 = 거칠게, 드릴다운 = 상세히, 슬라이스 = 한 값 고정, 다이스 = 여러 범위, 피벗 = 축 교환.
13. 오리지널 진단 5문제
아래 문제는 Motitory가 만든 원문(비공식)이며 IPA 기출을 사용하거나 번안하지 않았다.
Q1 — 분할
데이터 분할에 관한 설명으로 옳은 것은?
A. 수평 분할은 같은 행을 여러 노드에 겹쳐 저장하므로 복제의 한 형태이다.
B. 수직 분할에서는 각 조각에 기본 키를 남겨 두어, 키로 조인하면 원래 행을 복원할 수 있다.
C. 샤딩은 테이블을 열 단위로 나누어 서로 다른 서버에 두는 방식이다.
D. 수평 분할한 조각들은 기본 키로 조인해 원래 테이블을 복원한다.
- A: 오답. 수평 분할의 조각은 서로 다른 행을 가진다. 같은 데이터를 겹쳐 두는 것은 복제다.
- B: 정답. 키가 각 조각에 있어야 조인으로 원래 행을 되돌릴 수 있다(풀이 예제 1의 5단계).
- C: 오답. 샤딩은 행 단위(수평) 분할 조각을 서버별로 두는 방식이다.
- D: 오답. 수평 분할 조각은 합집합(UNION)으로 복원한다. 키 조인으로 복원하는 것은 수직 분할이다.
Q2 — 2단계 커밋의 장애
2단계 커밋에서 참가자 P1이 YES를 투표한 뒤, 결정을 받기 전에 조정자가 고장 났다. P1에 관한 설명으로 옳은 것은?
A. P1은 YES를 투표했으므로 혼자 커밋해도 된다.
B. P1은 일정 시간 안에 결정이 오지 않으면 혼자 롤백해도 된다.
C. P1은 불확실 상태이며, 준비 상태와 잠금을 유지한 채 결정을 알 수 있을 때까지 기다려야 한다.
D. 2단계 커밋은 조정자가 고장 나도 모든 참가자가 처리를 계속하도록 보장하므로 가용성에는 영향이 없다.
- A: 오답. 다른 참가자가 NO를 투표해 조정자가 ABORT를 정했을 수 있다.
- B: 오답. 조정자가 이미 COMMIT을 정하고 다른 참가자가 커밋했을 수 있으므로, 시간 초과만으로 혼자 롤백하면 원자성이 깨진다.
- C: 정답. YES 후에는 혼자 결정할 수 없어 차단된다(풀이 예제 2의 (c)).
- D: 오답. 2PC는 원자성을 위한 프로토콜이며 조정자 고장 시 참가자를 차단할 수 있다. 가용성을 제공하지 않는다.
Q3 — 일관성과 CAP
복제된 분산 데이터베이스에 관한 설명으로 옳은 것은?
A. CAP 정리에 따르면 분산 데이터베이스는 언제든지 C, A, P 중 원하는 두 가지를 자유롭게 고를 수 있다.
B. 네트워크 분단으로 사본들이 나뉜 동안에는, 모든 요청에 응답하는 가용성과 항상 최신 값을 돌려주는 일관성을 동시에 완전히 만족할 수 없다.
C. 결과 일관성이란 사본들이 결국 일치하기만 하면 확인된 갱신을 임의로 잃어도 된다는 뜻이다.
D. BASE는 ACID와 같은 원자성을 더 높은 성능으로 보증하는 규격이다.
- A: 오답. 선택은 분단이 일어났을 때 C와 A 사이에서 생긴다. “아무거나 둘”은 부정확하고, 분단이 없으면 CAP는 아무것도 강요하지 않는다.
- B: 정답. CAP 정리의 정확한 진술이다.
- C: 오답. 결과 일관성은 갱신이 멈추면 수렴한다는 보증이며, 임의 손실을 허용하는 정의가 아니다. 내구성과 충돌 해결은 별도로 설계한다.
- D: 오답. BASE는 가용성과 결과 일관성을 우선하는 설계 방침이며 보증이 아니다. ACID의 원자성을 제공한다는 뜻도 아니다.
Q4 — ETL 계산
출처 A가 하루 900,000행, 출처 B가 하루 600,000행을 보낸다. 합친 입력의 4%가 클렌징에서 거부되거나 병합되어 적재되지 않는다고 가정한다. 7일 동안 매일 같은 양이라면 7일간 적재되는 행 수는?
A. 10,500,000행
B. 10,332,000행
C. 10,080,000행
D. 1,440,000행
- A: 오답. (900,000 + 600,000) × 7로, 4% 거부·병합을 빼지 않았다.
- B: 오답. 4%를 출처 B에만 적용했다. 600,000 × 0.04 = 24,000, (1,500,000 − 24,000) × 7 = 10,332,000.
- C: 정답. 1,500,000 × 0.04 = 60,000, 1,500,000 − 60,000 = 1,440,000행/일, × 7 = 10,080,000행.
- D: 오답. 하루 적재량이며 7일 합계가 아니다.
Q5 — DWH와 OLAP
상품 × 지역 × 월의 매출 큐브를 분석한다. 옳은 것은?
A. 월별 합계를 분기별 합계로 바꾸어 보는 것은 드릴다운이다.
B. 지역을 R1 하나로 고정하고 상품 × 월의 표를 보는 것은 슬라이스이다.
C. 보고서의 행과 열을 바꾸면 집계값이 달라지며, 이 조작을 다이스라고 한다.
D. 데이터 웨어하우스는 매일 밤 OLTP DB를 변환 없이 복사한 것이므로 분석에도 같은 정규화 스키마를 그대로 쓴다.
- A: 오답. 더 거친 수준으로 올리는 것은 롤업이다. 드릴다운은 반대 방향이다.
- B: 정답. 한 차원을 하나의 값으로 고정해 단면을 보는 것이 슬라이스다.
- C: 오답. 축을 바꾸는 것은 피벗이며 집계값은 변하지 않는다. 다이스는 여러 차원에서 범위를 골라 작은 큐브를 잘라 내는 조작이다.
- D: 오답. DWH는 여러 출처를 통합·정제해 이력과 함께 쌓으며, 스타 스키마처럼 분석에 맞는 구조를 쓰는 경우가 많다.
정답: B, C, B, C, B
14. 셀프 체크와 복습 일정
- 수평 분할·수직 분할·샤딩·복제를 “무엇을 나누고 어떻게 복원하는가”로 구별할 수 있다.
- 풀이 예제 1의 7.2 GB, 40%, 21.6 GB를 가정과 함께 다시 계산할 수 있다.
- 동기·비동기 복제의 상충과 “복제는 백업이 아니다”를 설명할 수 있다.
- CAP 정리를 “분단 중”이라는 조건을 넣어 정확히 말할 수 있다.
- 2PC의 두 단계와 YES 투표 후 불확실 상태가 차단되는 이유를 말할 수 있다.
- DWH와 OLTP의 차이, 데이터 마트, ETL과 ELT의 차이를 말할 수 있다.
- 풀이 예제 3의 1,960,000행/일과 58,800,000행을 다시 계산할 수 있다.
- 롤업·드릴다운·슬라이스·다이스·피벗을 예와 함께 구별할 수 있다.
권장 복습 주기(발행 일정과 별개): 당일 풀이 예제 1–3을 보지 않고 다시 계산 → 1일 후 Q1–Q5 → 3일 후 퀵 시트만 보고 용어표 빈칸 채우기 → 7일 후 행 수·비율·사본 수를 바꿔 풀이 예제 1과 3을 새로 계산하고 틀린 문항을 재확인.
15. 공식 출처
- IPA 시험 요강·실라버스 개요 — 각 시험 구분의 시험 요강과 실라버스가 공개되는 IPA 페이지. AP 실라버스의 공식 게시 위치를 확인하는 데 썼다. 2026-10-22 확인.
- IPA 응용정보기술자시험 Syllabus Ver.7.2(PDF) — 출제 범위의 근거가 되는 실라버스 본문. 이 글은 대분류 3 / 중분류 9 데이터베이스 / 5. データベース応用의 (1) データベースの応用과 (2) 分散データベース에 대응시켰다. 2026-10-22 확인.
- IPA 실라버스 변경 정보 — 실라버스 개정 이력과 변경점을 확인하는 페이지. 2026-10-22 확인.
- IPA 2026년도 시험 정보 — 2026년도 시험 일정·실시 안내 페이지. 출제 범위가 아니라 시험 실시 정보를 확인하는 용도다. 2026-10-22 확인.
이 글은 AP33–38 마무리 계획의 세 번째 회차다. 다음으로 예정된 주제는 AP36 퍼실리티 매니지먼트이며, 시리즈는 AP38에서 끝난다.