데이터베이스, 데이터웨어하우스, 데이터레이크, 데이터레이크하우스. 비슷해 보이지만 각각 목적과 특성이 다릅니다. 한눈에 비교 구분 데이터베이스 데이터 웨어하우스 데이터 레이크 데이터 레이크하우스 목적 운영/트랜잭션(OLTP) 분석(OLAP) 원시 데이터 저장 분석 + 저장 통합 데이터 형태 구조화 구조화 비구조화/반구조화 모두 지원 스키마 Schema-on-Write Schema-on-Write Schema-on-Read 둘 다 가능 ACID O O X O 쿼리 패턴 단건 읽기/쓰기 대량 집계/분석 배치 처리 대량 집계/분석 실시간성 실시간 준실시간~배치 배치 준실시간~배치 대표 제품 MySQL, PostgreSQL Snowflake, Redshift, BigQuery S3, HDFS Databricks 쉬운 비유 데이터베이스: 매장 POS 시스템. 실시간 거래를 기록합니다. 데이터 웨어하우스: 본사 경영분석실. 정제된 보고서용 데이터를 보관합니다. 데이터 레이크: 창고에 일단 다 쌓아둡니다. 정리는 안 되어 있습니다. 데이터 레이크하우스: 창고에 관리 시스템을 얹었습니다. 저렴하게 저장하고, 체계적으로 관리합니다. 용어 유래 Database: Data + Base(기지) → 데이터를 저장하고 관리하는 기본 시스템 Data Warehouse: Data + Warehouse(창고) → 정리된 물건을 체계적으로 보관 Data Lake: Data + Lake(호수) → 모든 물이 흘러드는 호수 Data Lakehouse: Data + Lake + House (Databricks가 2020년 제안한 신조어) “Data Lake Warehouse"가 아닌 이유? 단순히 둘을 붙여 쓰는 게 아니라, 새로운 패러다임임을 강조하기 위해서입니다. ...

Java package-private 클래스를 Kotlin 테스트 코드에서 접근하려니 생성자 호출이 안 되어 reflection을 써야 했습니다. 왜 이런 문제가 발생할까요? Java와 Kotlin 접근 제어자 비교 Java public: 전체 protected: 상속 + 같은 패키지 (default): 같은 패키지 private: 같은 클래스 Kotlin public: 전체 internal: 같은 모듈 protected: 상속 관계만 private: 같은 클래스 (클래스 멤버) / 같은 파일 (최상위 선언) 핵심 차이 Java Kotlin 캡슐화 단위 패키지 모듈 테스트 접근 같은 패키지 필요 같은 모듈이면 OK package-private 있음 없음 (internal로 대체) protected 상속 + 같은 패키지 상속만 Kotlin의 설계 철학 1. 패키지는 캡슐화 경계가 아니다 // 원래 라이브러리 (example-lib.jar) package com.example.core; class InternalClass { // package-private void sensitiveMethod() { } } // 악의적 사용자 코드 (다른 프로젝트) package com.example.core; // 같은 패키지명 사용 public class Hacker { void access() { new InternalClass(); // package-private인데 접근됨 } } 패키지는 코드 조직화 수단일 뿐, 실제 캡슐화는 컴파일/배포 단위인 모듈에서 이루어져야 합니다. ...

Hugo 블로그에 GitHub Discussions 기반 댓글 시스템 giscus를 적용합니다. 사전 준비 GitHub 공개 저장소 준비 해당 공개 저장소에 Discussions 활성화: Settings → General → Features → Discussions giscus 앱 설치 후 저장소 선택 giscus 설정 https://giscus.app 접속 저장소와 원하는 옵션 선택 생성된 스크립트 코드 복사 Hugo 적용 댓글 파일 생성 <!-- layouts/partials/comment.html --> // 스크립트 코드 설정 파일 수정 # hugo.toml [params] comments = true 정리 giscus는 GitHub Discussions를 댓글로 사용 별도 DB나 서버 불필요 GitHub 로그인으로 댓글 작성

혼동하기 쉬운 블록킹/논블록킹과 동기/비동기 개념을 정리합니다. 개념 정의 블록킹 vs 논블록킹 구분 기준: 제어권을 바로 돌려주는가? 블록킹: 작업 완료까지 제어권을 돌려주지 않음 논블록킹: 작업 요청 후 바로 제어권 반환 카페 주문 비유: 블록킹: 카운터에서 서서 기다림 (다른 일 못함) 논블록킹: 진동벨 받고 자리로 (다른 일 가능) 동기 vs 비동기 구분 기준: 결과를 누가 확인하는가? 동기: 요청한 쪽이 결과를 직접 확인 비동기: 결과가 준비되면 콜백으로 알려줌 카페 주문 비유: 동기: 내가 직접 “제 커피 됐나요?” 확인 비동기: 직원이 “OO번 고객님~” 불러줌 핵심 구분 구분 질문 블록킹 논블록킹 제어권 기다리는 동안 다른 일 할 수 있어? 못함 (멈춤) 가능 (안 멈춤) 구분 질문 동기 비동기 결과 확인 결과를 내가 확인해? 알려줘? 내가 확인 알려줌 C 디바이스 I/O 예제 블록킹 I/O int fd = open("/dev/device", O_RDONLY); char buf[1024]; // 데이터 올 때까지 멈춤 int result = read(fd, buf, 1024); // 여기 도달 = buf 채워짐 보장 printf("읽음: %s", buf); 동작: ...

Apache Kafka의 핵심 개념과 동작 원리를 정리합니다. 아키텍처 Kafka Cluster (여러 Broker의 집합) │ └─ Broker (카프카 서버, 여러 대 가능) │ └─ Topic (메시지 종류) │ ├─ Partition 0 ──┐ ├─ Partition 1 ──┼── Consumer Group A ─┬─ Consumer 1 └─ Partition 2 ──┘ ├─ Consumer 2 │ └─ Consumer 3 │ └──────────── Consumer Group B ─── Consumer 1 구성 요소 Broker: Kafka 서버 (여러 대로 클러스터 구성) Topic: 메시지 종류별 논리적 그룹 Partition: 토픽 내 병렬 처리 단위 Consumer Group: 동일 group.id로 묶인 컨슈머들 설계 시 고려사항 파티션 수 = 최대 병렬 처리 수 파티션 수 ≥ 컨슈머 수 (컨슈머가 더 많으면 일부는 idle) 용어 정리 ← 여기 동작 일반 메시지 큐 Kafka 메시지 보내기 Publish Produce 보내는 주체 Publisher Producer 토픽 구독 Subscribe Subscribe (동일) 메시지 받기 Push (서버가 보냄) Poll (주기적으로 가져감) 받는 주체 Subscriber Consumer 메시지 흐름 Producer ──produce──▶ Kafka Broker ◀──poll── Consumer │ ▼ consume 처리 로직 동작 방식 Producer가 메시지 전송 Broker가 파티션에 메시지 저장 Consumer가 주기적으로 폴링 새 메시지 있으면 가져와서 처리 메시지 관리 Offset 관리 Offset: 파티션 내 메시지 위치 (0부터 시작) Committed Offset: 처리 완료한 마지막 위치 Latest Offset: 파티션의 마지막 메시지 위치 Consumer Lag: Latest - Committed (처리 지연 정도) Commit 전략 // 자동 커밋 (기본값) enable.auto.commit=true auto.commit.interval.ms=5000 // 수동 커밋 consumer.commitSync(); consumer.commitAsync(); 메시지 전달 보장 1. At-most-once 처리 전 commit 장점: 중복 없음 단점: 메시지 유실 가능 2. At-least-once (기본값) 처리 후 commit 장점: 메시지 유실 없음 단점: 중복 처리 가능 중요: 애플리케이션 레벨에서 멱등성 보장 필요 3. Exactly-once 트랜잭션 사용 장점: 중복도 유실도 없음 단점: 성능 오버헤드 메시지 보관 일반 메시지 큐와 달리 Kafka는 consume 후에도 메시지 보관: ...

Spring Boot의 설정 파일 로딩 메커니즘과 외부 라이브러리 사용 시 발생하는 문제를 다룹니다. ConfigData API (Spring Boot 2.4+) Spring Boot 2.4 부터 설정 로딩 방식이 ConfigData API로 변경되었습니다. 주요 변경사항 Spring Cloud Bootstrap Context 대체 (bootstrap.yml → application.yml) 단일 ApplicationContext 사용 spring.config.import 도입 설정 파일 로딩 기본 동작 검색 위치 Spring Boot는 다음 위치에서 설정 파일을 검색합니다 (낮은 → 높은 우선순위): 1. classpath:/application.yml 2. classpath:/config/application.yml 3. file:./application.yml 4. file:./config/application.yml 5. file:./config/*/application.yml 로딩 규칙 다른 경로: 모두 로드 후 병합 같은 classpath 경로: 첫 번째만 사용 Oracle Java 문서: 여러 모듈이 동일한 클래스 로더에 정의되고, 둘 이상의 모듈이 주어진 이름의 리소스를 포함하는 경우, 모듈이 검색되는 순서는 명시되지 않으며 매우 예측할 수 없을 수 있습니다. 우선순위 나중에 로드된 것이 우선: ...

Spring Boot 배포 직후 첫 요청이 느린 이유를 JVM 동작 원리부터 설명합니다. 컴파일러와 인터프리터 컴파일러 언어 (C/C++) 전체 코드를 한번에 기계어로 변환 실행 속도 빠름 플랫폼 종속적 인터프리터 언어 (Python) 코드를 한 줄씩 해석하며 실행 실행 속도 느림 플랫폼 독립적 자바 동작 방식 자바 1990년대 설계 철학 이식성: Write Once, Run Anywhere 안전성: 메모리 보호, 타입 검증 개발 생산성: 자동 메모리 관리 HelloWorld.java (소스코드) → javac (컴파일) → HelloWorld.class (바이트코드) → java (JVM) → 실행 단점 바이트코드 인터프리터 실행으로 성능이 느렸습니다. ...

1. LLM이란 무엇인가? 정의 Large Language Model = 대규모 언어 모델 엄청난 양의 텍스트로 학습한 파라미터가 수백억~조 개인 언어를 이해하고 생성하는 AI 모델 본질 “다음 단어 예측"을 극한까지 잘하는 모델 입력: "오늘 날씨가 정말" LLM: "좋네요" (가장 자연스러운 다음 단어 선택) → 이 단순한 원리로 대화, 요약, 번역, 코딩까지 가능 2. LLM = 딥러닝의 한 종류 AI 기술 계층도 AI └─ 머신러닝 ├─ 전통 머신러닝 └─ 딥러닝 └─ Transformer └─ LLM ← 여기 LLM의 위치 AI의 일부 딥러닝의 일부 Transformer 기반 현재 가장 주목받는 분야 Multimodal 확장 최근 트렌드: ...

1. 머신러닝 전체 프로세스 단계 전통 머신러닝 딥러닝 1. 원본 데이터 텍스트, 이미지, 표 등 텍스트, 이미지, 표 등 2. 분할 텍스트→토큰, 이미지→픽셀, 음성→프레임 텍스트→토큰, 이미지→픽셀, 음성→프레임 3. 벡터화 숫자로 변환 (ID, RGB, 정규화) 숫자로 변환 (ID, RGB, 정규화) 4. Feature 추출 사람이 설계 (고정)- 긍정단어 개수- 부정단어 개수- 느낌표 개수 - 5. 학습 초기화 랜덤 Parameter 랜덤 Parameter 6. 순전파 Feature × Parameter = 예측 벡터화된 입력 × Parameter→ Layer별 Feature 자동 생성→ 예측 7. 손실 계산 정답과 비교 정답과 비교 8. 역전파 Parameter 조정 Parameter 조정→ Feature 표현도 변화 9. 반복 68 반복 (수백만수억 회) 68 반복 (수백만수억 회) 10. 학습된 모델 고정 Feature + 학습된 Parameter 학습된 Parameter(Feature 표현 내장) 11. 추론: 전처리 분할 + 벡터화 분할 + 벡터화 12. 추론: Feature 같은 방식으로 Feature 추출 학습된 모델로 자동 생성 13. 추론: 예측 학습된 Parameter로 계산 학습된 Parameter로 계산 14. 예측 결과 출력 출력 2. 핵심 용어 완전 정리 데이터 (Data) 원본 정보 ...