[디지털 뱃지] 일일 스터디 Day 06

[디지털 뱃지] 일일 스터디 Day 06

General(Security) & Developer(Data Architecture) 핵심 돌파

1. 오늘의 핵심 이론 설명

General Engineering - Network/Security

대칭키(Symmetric) vs 공개키(Asymmetric) 암호화 구조 메커니즘

클라우드 인프라 통신망(SSL/TLS) 및 가상 데이터 스토리지 암호화를 보호하기 위한 필수 정보보안 기초입니다.

• 대칭키 암호화 (예: AES, DES): 암호화와 복호화에 동일한 단일 키를 사용하는 방식입니다. 알고리즘 구조가 비교적 단순하여 연산 속도가 매우 빠르기 때문에 대대적인 가상 디스크 볼륨이나 대용량 데이터를 암호화할 때 대단히 유리합니다. 그러나 송수신자 간에 키를 안전하게 전달하기 어렵다는 키 교환(Key Exchange) 문제가 존재합니다.
• 공개키 암호화 (예: RSA, ECC): 암호화에 쓰이는 공개키(Public Key)와 복호화에 쓰이는 개인키(Private Key)가 서로 쌍으로 존재하는 비대칭 구조입니다. 공개키는 누구나 알 수 있게 공개하고 개인키는 본인만 소유하므로 키 배송 문제를 근본적으로 해결합니다. 다만 복잡한 수학적 연산이 필요하여 대칭키에 비해 속도가 현저히 느립니다.
• 하이브리드 암호화 (SSL/TLS의 본질): 실제 데이터 통신 시에는 연산 속도가 빠른 대칭키(세션키)로 데이터를 암호화하고, 이 대칭키를 안전하게 공유하기 위해 공개키 방식으로 대칭키를 암호화하여 전송하는 융합 메커니즘을 사용합니다.

Developer Engineering - Data Architecture

CDC(Change Data Capture)의 개념과 데이터 파이프라인 가용성

MSA 분산 DB 환경이나 이종 인프라(On-Premise to Cloud) 마이그레이션 시, 실시간 데이터 동기화를 유지하기 위한 핵심 아키텍처 패턴입니다.

• CDC(변경 데이터 캡처)의 정의: 데이터베이스 원천 테이블에서 발생하는 삽입(Insert), 수정(Update), 삭제(Delete) 등 모든 변경 이벤트를 실시간으로 감지하여 타겟 스토리지나 분석 프레임워크로 즉각 전송 및 동기화하는 기술입니다.
• 로그 기반 CDC (Log-based CDC): 소스 DB의 애플리케이션 레이어에 부하를 주며 쿼리를 때리는 방식(Query-based)과 달리, 데이터베이스가 데이터 무결성을 위해 남기는 내부 트랜잭션 로그(예: MySQL의 Binlog, Oracle의 Redo log)를 하부에서 직접 파싱하여 변경 사항을 추출합니다. 원천 데이터베이스 운영 성능에 미치는 오버헤드가 거의 없다는 강력한 장점이 있습니다.
• 활용 스펙트럼: 데이터 웨어하우스(DW) 및 데이터 레이크로의 실시간 파이프라인 구성뿐만 아니라, 무중단으로 데이터를 다른 클라우드 환경이나 이종 인프라 가상머신으로 복제 및 이관할 때 정합성을 유지하는 기반 아키텍처로 사용됩니다.

---

2. 디지털 뱃지 레벨 1~2 예상 문제집

Q1. 암호화 알고리즘 메커니즘과 그 특징에 대한 설명 중 가장 거리가 먼 것은?

1) 대칭키 암호화 방식은 암호화와 복호화에 동일한 키를 사용하며 AES가 대표적인 알고리즘이다.
2) 공개키 암호화 방식은 대칭키 암호화 방식에 비해 대용량 데이터를 암호화할 때 연산 속도가 빠르다.
3) 공개키 방식에서 데이터를 비밀리에 전송하고자 할 때는 수신자의 '공개키'로 데이터를 암호화하여 송신한다.
4) 하이브리드 암호화 방식은 공개키 방식으로 대칭키(세션키)를 안전하게 교환하고, 실제 데이터는 그 대칭키로 암호화한다.

정답 및 해설 보기

정답: 2)
해설: 공개키(비대칭키) 암호화 알고리즘은 소수 격자나 타원 곡선 등 고도의 수학적 연산을 필요로 하므로, 알고리즘 구조가 비교적 직관적인 대칭키 암호화 방식에 비해 처리 속도가 훨씬 느립니다. 대용량 볼륨 암호화에는 부적합합니다.

Q2. 데이터 파이프라인 설계에서 사용되는 '로그 기반 CDC(Log-based Change Data Capture)' 기술의 특징으로 가장 올바른 것은?

1) 특정 주기로 타겟 테이블을 전체 스캔(Full Scan)하여 변경 사항을 대조하므로 네트워크 대역폭 소비가 크다.
2) 원천 데이터베이스 애플리케이션 레벨에서 주기적으로 SELECT 쿼리를 요청하여 데이터를 추출한다.
3) 데이터베이스가 생성하는 로우 레벨의 트랜잭션 로그를 직접 읽어 변경 사항을 추출하므로 소스 DB 가동 성능에 미치는 영향이 최소화된다.
4) 오직 데이터 웨어하우스 적재 용도로만 사용이 한정되며 실시간 네트워크 스트리밍에는 적용할 수 없다.

정답 및 해설 보기

정답: 3)
해설: 로그 기반 CDC는 DBMS 자체의 스토리지 엔진이 내부 무결성을 위해 기록하는 시스템 트랜잭션 로그(Binlog, WAL 등)를 백그라운드에서 직접 가로채어 파싱하는 구조이므로, 원천 가동 중인 서비스 쿼리 연산 장치에 오버헤드를 거의 주지 않고 실시간에 준하는 스트리밍 복제를 가능하게 합니다.

---

💡 신기술 추가 지식 : 이벤트 브로커와 분산 로그 복제 생태계 (Debezium & Kafka)

최근 엔지니어링 아키텍처에서는 실시간 CDC 파이프라인의 표준 프레임워크로 오픈소스 기반의 Debezium과 분산 분할 메시지 플랫폼인 Apache Kafka를 결합한 아키텍처가 독점적인 위치를 차지하고 있습니다. Debezium 커넥터가 DB의 하부 엔진 로그 파일 파티션을 리드하여 소스 테이블의 행(Row) 변화를 즉각 '이벤트' 데이터로 캡처하면, Kafka 오케스트레이터가 이 이벤트를 고속으로 유실 없이 브로커 노드 전체에 복제하고 유통합니다. 이 결합 기술은 데이터베이스 마이그레이션 백엔드뿐만 아니라, 클라우드 네이티브 MSA 환경에서 서로 다른 서비스 간 데이터의 '최종적 일관성(Eventual Consistency)'을 지탱하는 중추 인프라 메커니즘으로 유기적으로 진화하고 있습니다.