기술 아티클
직접 쓰고 다듬은 기술 글입니다. 학습 일지에서 검증된 내용을 정리해 올립니다.
-
데이터 정합성 검증 자동화와 Data Contract 설계
데이터 사고는 대부분 조용히 일어난다. 원천 팀이 컬럼 하나를 바꾸거나 배치가 절반만 적재돼도 파이프라인은 성공으로 끝나고, 며칠 뒤 보고서 숫자가 틀린 것을 누군가 발견한다. 이 글은 생산자와 소비자 사이의 약속을 Data Contract로 문서화하고, 그 약속을 CI와 파이프라인에서
-
Data Lakehouse 아키텍처와 Apache Iceberg
데이터 레이크는 싸고 크지만 파일 묶음이라 트랜잭션도 스키마 관리도 없고, 웨어하우스는 정확하지만 비싸고 한 엔진에 묶인다. 레이크하우스는 객체 스토리지의 Parquet 파일 위에 테이블 메타데이터 계층을 얹어 두 장점을 합치는 구조다. 이 글은 그 계층을 대표하는 Apache Iceb
-
Vector Database의 HNSW 인덱스 동작 원리
벡터 검색의 지연 시간과 정확도는 대부분 인덱스 하나로 정해지고, 지금 가장 널리 쓰이는 인덱스가 HNSWHierarchical Navigable Small World다. 이 글은 Malkov와 Yashunin의 논문2016년 arXiv 공개, 2018년 IEEE TPAMI 게재이 정리
-
PostgreSQL Partitioning과 대용량 테이블 관리
수억 건짜리 테이블은 조회보다 관리에서 먼저 무너진다. 오래된 데이터를 지우는 DELETE가 몇 시간씩 돌고, VACUUM이 끝나지 않고, 인덱스 하나 만들 때마다 서비스 점검 공지를 낸다. 이 글은 PostgreSQL 선언적 파티셔닝으로 이 문제를 푸는 방법을 정리한다. 방식 고르기,
-
OLTP와 OLAP 아키텍처 분리 및 데이터 동기화
운영 DB 하나로 업무 처리와 통계를 함께 하면, 월말 집계 쿼리 한 번에 민원 접수 화면이 느려지는 일이 생긴다. 두 일은 데이터를 읽는 방식이 정반대라서 저장소를 나누는 것이 맞다. 다만 나누는 순간 "두 곳의 숫자가 같은가"라는 새 문제가 생긴다. 이 글은 OLTP와 OLAP를 왜
-
CDC와 Debezium으로 DB 변경 이벤트 수집하기
검색 색인, 분석 DB, 캐시가 원본 DB를 따라가려면 무엇이 바뀌었는지 빠짐없이 알아야 한다. 코드에 이벤트 발행을 끼워 넣으면 빠뜨리는 경로가 생기고, 테이블을 주기적으로 다시 읽으면 삭제를 놓친다. 이 글은 PostgreSQL WAL·MySQL binlog를 읽어 Kafka로 보내
-
LLM 서비스의 비결정성과 재현 가능한 테스트 설계
같은 입력에 다른 답을 내는 LLM은 "어제 통과한 테스트가 오늘 실패하는" 문제를 기본으로 안고 있고, 그대로 두면 팀은 빨간 CI를 무시하는 법부터 배운다. 이 글은 비결정성이 어디서 오는지 나누고, 녹화 재생·스키마 계약·불변식·N회 샘플링의 네 층으로 테스트를 짜서 실패를 다시
-
AI Agent의 비용 최적화: Model Routing과 Token Budget
AI Agent의 비용은 호출 한 번의 단가보다 루프가 몇 바퀴 도는지, 바퀴마다 무엇을 다시 보내는지에서 결정된다. 이 글은 Agent 비용이 생기는 지점을 작업 단위로 재는 법, 쉬운 일을 작은 모델에 보내는 Model Routing, 작업마다 한도를 거는 Token Budget,
-
LLM Semantic Cache 설계와 캐시 오염 방지
Semantic Cache는 "뜻이 같은 질문"에 지난 답을 돌려줘서 LLM 호출 비용과 지연을 줄인다. 대신 틀린 답, 다른 사용자의 개인정보, 프롬프트 인젝션에 오염된 답까지 그대로 재사용될 수 있다. 이 글은 Exactmatch 캐시와의 차이, 캐시 키 구성, 유사도 임계값을 정하
-
Agentic RAG와 일반 RAG의 아키텍처 차이
일반 RAG는 질문을 한 번 검색하고 찾은 문서를 붙여 바로 답한다. 질문이 여러 단계를 거치거나 답이 여러 저장소에 흩어져 있으면 이 한 번의 검색이 빗나가고, 모델은 빈약한 근거로 그럴듯한 답을 만든다. 이 글은 검색 자체를 판단의 대상으로 만드는 Agentic RAG가 일반 RAG
-
LLM Inference 최적화: KV Cache·Quantization·Batching
LLM 서빙 비용과 응답 속도는 모델 크기보다 GPU 메모리를 어떻게 나눠 쓰는지에 더 크게 좌우된다. 이 글은 추론이 prefill과 decode 두 단계로 나뉘는 이유에서 시작해, KV Cache 메모리 계산, PagedAttention과 Prefix Caching, Quantiza
-
RAG 검색 품질 개선: Hybrid Search와 Reranking
RAG 답변이 틀리는 원인의 상당수는 모델이 아니라 검색에 있다. 찾아야 할 문서를 상위 몇 개 안에 넣지 못하면 어떤 모델도 맞는 답을 쓸 수 없다. 이 글은 키워드 검색BM25과 벡터 검색을 함께 돌리는 Hybrid Search, 두 결과를 합치는 RRF, 후보를 다시 줄 세우는 C
-
Kubernetes Pod Lifecycle과 Graceful Shutdown 설계
롤링 배포를 할 때마다 502 응답이 몇 건씩 찍힌다면 원인은 대개 애플리케이션 코드가 아니라 종료 순서다. Kubernetes는 Pod를 지울 때 트래픽 차단과 종료 신호를 동시에 진행하므로, 둘의 순서를 맞추는 일은 설계하는 쪽의 몫이다. 이 글은 Pod 생애 주기와 프로브의 역할을
-
Blue-Green·Canary·Rolling 배포 전략 비교
무중단 배포 방식은 세 가지가 가장 흔하다. BlueGreen은 환경을 통째로 바꾸고, Canary는 트래픽 일부로 먼저 시험하고, Rolling은 인스턴스를 하나씩 교체한다. 셋은 서버 비용, 롤백 속도, 장애가 닿는 범위가 서로 다르고, 공통으로 "구버전과 새 버전이 잠시 함께 돈다
-
SRE Error Budget으로 배포 속도와 안정성 관리하기
"배포를 더 자주 하자"는 개발팀과 "장애가 나니 덜 바꾸자"는 운영팀의 다툼은 기준이 없으면 목소리 큰 쪽이 이긴다. Error Budget에러 버짓은 SLO가 허락하는 실패의 양을 숫자로 정해 두고, 그 숫자가 남아 있으면 배포하고 바닥나면 안정성 작업으로 돌아가게 만드는 장치다.
-
Chaos Engineering으로 장애 복원력 검증하기
타임아웃, 재시도, Circuit Breaker, 이중화를 설계해 두어도 실제 장애가 났을 때 그대로 동작하는지는 장애가 나기 전까지 모른다. Chaos Engineering은 통제된 조건에서 일부러 장애를 주입해 그 설계가 정말 버티는지 확인하는 실험 방법이다. 이 글은 실험 원칙,
-
GitOps와 Argo CD 기반 선언적 배포 아키텍처
운영 클러스터에 무엇이 떠 있어야 하는지를 Git 저장소 하나에 적어 두고, 클러스터 안의 에이전트가 그 상태를 계속 맞추게 하는 방식이 GitOps다. 이 글은 OpenGitOps 4원칙에서 출발해 저장소 분리, Argo CD의 Application·AppProject 설정, 동기화
-
OpenTelemetry Trace Context 전파와 분산 추적
분산 추적은 서비스마다 span을 남기는 것만으로 완성되지 않는다. 요청이 HTTP, Kafka, 스레드 풀을 건널 때마다 같은 traceid가 넘어가야 하고, 한 곳에서 빠지면 trace가 둘로 끊긴다. 이 글은 W3C Trace Context 형식, Propagator와 Baggag
-
Lamport Clock과 Vector Clock으로 분산 이벤트 순서 이해하기
서버가 여러 대면 "어느 일이 먼저 일어났는가"를 벽시계로 정할 수 없다. 서버마다 시계가 조금씩 다르고, 맞추는 도중에 뒤로 가기도 하기 때문이다. 이 글은 시계 대신 인과 관계로 순서를 매기는 Lamport Clock과 Vector Clock의 규칙을 같은 예시 하나로 계산해 보고,
-
Event Sourcing과 CQRS를 도입해야 하는 시점
Event Sourcing과 CQRS는 함께 소개되는 일이 많아 한 묶음처럼 들리지만, 둘은 서로 다른 문제를 푸는 별개의 선택이고 들어가는 비용도 다르다. 이 글은 두 패턴을 나눠서 설명하고, 도입해야 할 신호와 하지 말아야 할 신호, 도입하면 따라오는 비용, 감사 로그부터 시작하는
-
Exactly-Once Processing은 정말 가능한가: 전달 보장과 처리 보장의 차이
메시지 브로커와 스트림 처리 엔진은 "exactlyonce"를 지원한다고 말하지만, 네트워크 너머로 메시지를 정확히 한 번만 전달하는 방법은 없다. 실무에서 말하는 exactlyonce는 전달을 최소 한 번 하되 결과가 한 번만 반영되게 만드는 것이고, 그 보장은 특정 시스템의 경계 안
-
분산 락 구현 전략: Redis·DB·ZooKeeper 비교
서버가 두 대 이상이 되면 synchronized나 프로세스 안의 뮤텍스로는 "한 번에 하나만" 실행되는 것을 보장할 수 없다. 이 글은 분산 락을 Redis, 관계형 DB, ZooKeeper·etcd로 구현하는 방법을 비교하고, 락이 만료된 뒤에도 데이터를 지키는 펜싱 토큰까지 포함해
-
Saga Pattern과 보상 트랜잭션 실전 설계
주문·결제·재고가 서로 다른 서비스와 DB로 나뉘면 한 번의 커밋으로 전부를 묶을 수 없고, 중간 단계가 실패했을 때 앞 단계를 되돌릴 방법을 따로 만들어야 한다. 이 글은 로컬 트랜잭션을 차례로 실행하고 실패하면 보상 트랜잭션으로 취소하는 Saga 패턴을, 단계 순서·상태 테이블·멱등
-
CAP Theorem과 PACELC로 분산 시스템 설계 결정하기
복제된 데이터를 쓰는 시스템은 언젠가 노드 사이 통신이 끊기고, 그 순간 "그래도 응답할 것인가, 틀릴 수 있으니 거절할 것인가"를 고르게 된다. CAP은 이 선택이 피할 수 없다는 것을, PACELC는 장애가 없는 평상시에도 지연과 일관성 사이의 선택이 계속된다는 것을 알려 준다. 이
-
Microsoft Copilot 프롬프트 갤러리 분석: 프롬프트 129개와 다단계 시나리오 12개
Microsoft 도입 지원 사이트의 Copilot 프롬프트 갤러리https://adoption.microsoft.com/kokr/copilot/promptgallery/는 Microsoft 365 Copilot에서 바로 실행해 볼 수 있는 업무 프롬프트를 직무·제품·작업으로 걸러 보여
-
Gemini 프롬프트 작성 가이드 101 분석: 4요소와 연속 프롬프트, 직무별 예시 173개
Google Workspace의 프롬프트 작성 가이드 101https://workspace.google.com/intl/ko/resources/ai/writingeffectiveprompts/은 Gmail, Docs, Sheets 안에서 Gemini를 쓰는 방법을 직무별 예시로 보여 주
-
ChatGPT for any role 프롬프트 가이드 분석: 직무 공통 업무 프롬프트 20개와 3문장 구조
OpenAI Academy의 ChatGPT for any rolehttps://academy.openai.com/ko/public/clubs/workusersynjqu/resources/chatgptforanyrole은 직무와 상관없이 회사에서 바로 쓰는 ChatGPT 프롬프트 20개를
-
Claude Code 프롬프트 라이브러리 분석과 리뷰: 52개 카드에서 찾은 6가지 작성 패턴
Claude Code 공식 문서에 복사해서 바로 쓰는 프롬프트 모음인 프롬프트 라이브러리https://code.claude.com/docs/ko/promptlibrary가 있다. 이 글은 2026년 11월 2일 기준 한국어 페이지에 실린 카드 52개를 단계·역할·출처별로 세어 보고, 카
-
Project Factory에 GitHub Actions와 Quality Gate 적용하기
Project Factory는 한 줄 프롬프트로 저장소, 코드, 테스트, 배포까지 만드는 구조다. 지금 설계에서는 검증을 에이전트의 로컬 verify와 Hook이 맡는데, 둘 다 같은 기계 안에서 돌아서 건너뛰거나 설정을 바꾸면 게이트가 사라진다. 이 글은 공장이 만드는 저장소마다 Gi
-
AI Agent의 Tool Calling 보안과 Prompt Injection 방어
AI Agent가 파일을 읽고, 셸을 실행하고, 메일을 보내는 도구를 갖는 순간 프롬프트 인젝션은 "이상한 답변"이 아니라 "실제로 실행된 명령"이 된다. 모델이 읽는 글 어딘가에 숨은 지시 한 줄이 도구 호출로 이어질 수 있기 때문이다. 이 글은 직접·간접 인젝션이 어떻게 들어오는지,