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 기본 개념 정리
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) 메시지 흐름 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 설정 파일 로딩
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 애플리케이션 웜업
Spring Boot 배포 직후 첫 요청이 느린 이유를 JVM 동작 원리부터 설명합니다. 컴파일러와 인터프리터 컴파일러 언어 (C/C++) 전체 코드를 한번에 기계어로 변환 실행 속도 빠름 플랫폼 종속적 인터프리터 언어 (Python) 코드를 한 줄씩 해석하며 실행 실행 속도 느림 플랫폼 독립적 자바 동작 방식 자바 1990년대 설계 철학 이식성: Write Once, Run Anywhere 안전성: 메모리 보호, 타입 검증 개발 생산성: 자동 메모리 관리 HelloWorld.java (소스코드) → javac (컴파일) → HelloWorld.class (바이트코드) → java (JVM) → 실행 단점 바이트코드 인터프리터 실행으로 성능이 느렸습니다. ...
LLM 개념 정리
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) 원본 정보 ...
AI 개념 정리
1. AI 영역 구분 1번: AI 모델 개발 직접 머신러닝으로 모델 학습 추천, 예측 등 자체 모델 제작 시간/비용 많이 들고, 전문 인력 필요 2번: AI 기능 통합 외부 LLM API 활용 (GPT, Claude) 서비스에 챗봇, 요약, 검색 등 추가 빠르고, 기존 개발자가 가능 3번: AI 도구 사용 Claude Code, Copilot으로 개발 효율화 AI는 보조 도구 2. 데이터 마이닝 ↔ AI 관계 데이터 마이닝 AI (패턴/인사이트 발견) (지능적 판단·행동) ╲ ╱ ╲ ╱ ╲ ╱ ╲ ╱ 머신러닝 설명 데이터 마이닝: “왜 이런 일이 일어나는가?” (패턴 발견) AI: “이 상황에서 뭘 해야 하는가?” (문제 해결) 머신러닝: AI의 한 분야이자, 데이터 마이닝에서 활용되는 핵심 도구 예시 데이터 마이닝: 고객 데이터 분석 → “금요일 저녁 맥주+치킨 많이 팔림” 발견 AI: 고객 접속 시 → “이 사람에게 맥주 추천” 자동 판단 3. AI의 기술 체계 AI의 목적 지능적 판단·계획·행동으로 문제 해결 예측은 그 중 한 수단일 뿐 AI (지능적으로 판단·계획·행동하여 문제 해결) ├─ 규칙 기반 AI (if-then 로직) ├─ 탐색/최적화 알고리즘 └─ 머신러닝 ← 요즘 AI의 핵심 (특히 딥러닝) ├─ 전통 머신러닝 (SVM, 랜덤포레스트 등) └─ 딥러닝 ├─ CNN (이미지 인식) ├─ RNN (시계열 처리) └─ Transformer (2017~) ├─ BERT (양방향 이해) └─ LLM (대규모 언어모델) ← 요즘 가장 주목받는 분야 └─ GPT, Claude, Gemini 4. 머신러닝의 학습 방식 머신러닝 (데이터로 모델 학습) ├─ 지도 학습 (정답 있는 데이터로 학습) ├─ 비지도 학습 (정답 없이 패턴 찾기) └─ 강화 학습 (시행착오로 학습) 5. 핵심 프로세스 학습 데이터 → [학습/Training] → 모델 입력 데이터 → [추론/Inference] → 결과 6. 시대별 “AI"의 의미 1980년대: AI = 규칙 기반 한계에 부딪힘 (AI의 겨울) 2000년대: AI = 머신러닝 데이터 → 특징 → 학습 → 모델 → 추론 딥러닝 이론 존재, 컴퓨팅 파워 부족 2010년대: AI = 딥러닝 GPU 발달 2012 ImageNet: CNN으로 이미지 인식 돌파 2017 Transformer 등장 2020년대: AI ≈ LLM (대중 인식) ChatGPT, Claude 등의 폭발적 성장 7. 핵심 용어 정리 AI (인공지능) 지능적으로 판단·계획·행동하여 문제 해결 요즘은 사실상 머신러닝 의미로 많이 씀 머신러닝 (기계학습) 데이터로 기계를 학습시킴 AI 구현에 성공한 방법 데이터 마이닝과 AI가 공유하는 핵심 도구 딥러닝 신경망을 깊게 쌓은 것 특징을 자동으로 학습 (사람이 특징 정의 불필요) GPU 발달로 2010년대 실용화 Transformer 2017년 등장한 딥러닝 아키텍처 병렬 처리가 가능해서 대규모 학습에 유리 LLM (Large Language Model) Transformer 기반 대규모 언어 모델 ChatGPT, Claude 등 AI 중 일부지만 최근 2-3년 폭발적 유행 데이터 마이닝 데이터에서 패턴/인사이트 찾기 머신러닝을 도구로 활용
MySQL vs Oracle: 커서(Cursor) 동작 방식 비교
TL;DR MySQL과 Oracle은 서버 커서 구현 방식이 근본적으로 다름 MySQL: 임시 테이블 생성하여 전체 결과 저장 Oracle: PGA 메모리에서 커서 상태만 유지하고 필요한 만큼 페치 “클라이언트 사이드 커서"는 MySQL에서 공식 용어가 아님 MySQL: 클라이언트 버퍼링, 스트리밍, 서버 커서 3가지 방식 제공 1. 커서란 무엇인가 데이터베이스 커서는 쿼리 결과를 순차적으로 처리하기 위한 메커니즘입니다. 대용량 결과를 한 번에 메모리로 로드하지 않고, 필요한 만큼만 가져와서 처리할 수 있게 해줍니다. 데이터베이스에서는 결과를 처리하는 위치에 따라 서버 커서와 클라이언트 커서으로 구분할 수 있습니다. ...
바이브 코딩을 넘어서 - 기획 영역에서의 AI 활용
코딩 영역에서 시작된 자연어 기반 AI 협업이 기획 영역에도 적용되고 있습니다. 바이브 코딩이 자연어로 코드를 작성하는 방식이라면, 기획에서는 자연어로 사용자 스토리, 제품 요구사항, 기능 명세서를 생성하는 방식입니다. AI가 효과적인 기획 작업 1. 사용자 스토리 작성 표준 형식의 사용자 스토리를 빠르게 생성할 수 있습니다. "로그인 기능에 대한 사용자 스토리를 작성해줘. 이메일/비밀번호 방식과 소셜 로그인 지원" 2. 제품 요구사항 문서(PRD) 초안 제품 아이디어를 구조화된 문서로 변환하는 데 유용합니다. "온라인 서점 장바구니 기능 PRD 작성. 목표, 기능 요구사항, 제외 범위 포함" 3. 기능 명세서 작성 복잡한 기능을 단계별로 분해하고 명세화하는 작업에서 효율적입니다. ...