전체 글
이 블로그에 올라온 모든 글입니다.
-
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개를 단계·역할·출처별로 세어 보고, 카
-
AI 코딩 프롬프트 기록 2026-11-02 오전
20261101 저녁부터 20261102 오후 1시까지 Claude Code와 Antigravity에 보낸 프롬프트를 시간순으로 옮긴다. 블로그 아티클 발행, agy CLI 그림 생성 시험, 그림 도구 스킬 반영이 주된 내용이다. 09:23 기술 아티클 4편 발행 · Claude Cod
-
개발 기록 2026-11-02 오전: 기술 아티클 8편 발행, 그림 도구 우선순위 스킬 추가, agy 그림 시험
이번 기록은 20261101 저녁부터 20261102 오후 1시까지의 작업이다. 대부분은 2일 오전에 이뤄졌다. 블로그 기술 아티클 발행, 히어로 그림을 만드는 도구 조사와 스킬 반영, 그리고 그 과정에서 막힌 권한 문제를 다룬다. 기술 아티클 8편 발행 /blogtecharticle
-
Project Factory에 GitHub Actions와 Quality Gate 적용하기
Project Factory는 한 줄 프롬프트로 저장소, 코드, 테스트, 배포까지 만드는 구조다. 지금 설계에서는 검증을 에이전트의 로컬 verify와 Hook이 맡는데, 둘 다 같은 기계 안에서 돌아서 건너뛰거나 설정을 바꾸면 게이트가 사라진다. 이 글은 공장이 만드는 저장소마다 Gi
-
AI Agent의 Tool Calling 보안과 Prompt Injection 방어
AI Agent가 파일을 읽고, 셸을 실행하고, 메일을 보내는 도구를 갖는 순간 프롬프트 인젝션은 "이상한 답변"이 아니라 "실제로 실행된 명령"이 된다. 모델이 읽는 글 어딘가에 숨은 지시 한 줄이 도구 호출로 이어질 수 있기 때문이다. 이 글은 직접·간접 인젝션이 어떻게 들어오는지,
-
Multi-Agent Orchestration에서 병렬 처리와 충돌 방지
AI 에이전트 여러 개를 동시에 돌리면 일은 빨리 끝나지만, 둘이 같은 파일을 고치거나 같은 배포를 두 번 하면 그 시간은 충돌을 푸는 데 다 쓰인다. 이 글은 병렬로 나눌 일을 고르는 기준, 작업자끼리 부딪치지 않게 하는 소유권·격리·단일 작성자 규칙, 그리고 결과를 합치고 검증하는
-
Claude Code와 Codex CLI의 Skill 재사용 아키텍처
Claude Code와 Codex CLI를 같이 쓰면 같은 스킬을 두 곳에 따로 두기 쉽고, 그러면 한쪽만 고쳐져 내용이 갈라진다. 이 글은 한 대의 Mac에서 두 런타임이 스킬을 실제로 어떻게 나눠 쓰는지 폴더 구조부터 확인하고, 원본을 한 곳에 두는 법, 한 런타임이 다른 런타임을
-
AA 관점의 기술 부채 관리와 아키텍처 품질 지표
기술 부채는 "나중에 고치자"는 말로 쌓이고, 숫자가 없으면 끝까지 갚지 못한다. 애플리케이션 아키텍트AA가 할 일은 부채를 없애는 것이 아니라 보이게 만들고, 이자가 큰 것부터 갚을 순서와 예산을 확보하는 것이다. 이 글은 부채를 분류하고 대장에 올리는 법, 우선순위를 정하는 기준,
-
API Gateway와 BFF 도입 기준 및 보안 설계
API Gateway와 BFFBackend for Frontend는 둘 다 클라이언트와 서비스 사이에 서는 계층이라 자주 섞여 쓰이지만, 맡는 일과 막아야 할 위협이 다르다. 역할을 섞으면 게이트웨이가 화면 로직으로 비대해지거나, 반대로 "게이트웨이가 막아 주겠지" 하며 서비스가 인가를
-
모놀리식 시스템을 Modular Monolith로 전환하는 설계 전략
수정 하나에 화면 다섯 개가 깨지는 모놀리식 시스템을 고치는 방법이 꼭 MSA일 필요는 없다. 배포 단위는 하나로 두고 안쪽을 업무 단위 모듈로 나눠 경계를 강제하는 Modular Monolith는 운영 부담을 늘리지 않고 결합도부터 낮춘다. 이 글은 레거시 Spring 모놀리스를 모듈
-
ADR(Architecture Decision Record) 실전 작성법
아키텍처 결정은 몇 달이 지나면 결과만 남고 이유는 사라진다. ADRArchitecture Decision Record은 결정 하나를 한 장에 배경, 대안, 결과와 함께 적어 두는 짧은 문서이고, 이 글은 언제 쓰는지부터 필드 구성, 상태 관리, 저장 위치, 리뷰 절차, 공공 SI 산출
-
2026년 11월 2일 AI 뉴스 정리
2026년 11월 2일 기준으로 최근 보도 중 날짜와 출처를 확인한 10건을 정리했습니다. 각 항목에 보도 날짜를 적었습니다. 정책과 규제 OpenAI, 중간선거 직후 정책 공세 준비: Axios는 11월 1일 OpenAI가 중간선거 직후 AI 안전과 데이터센터 관련 정책 제안을 잇달아
-
AI 코딩 프롬프트 기록 2026-10-31 오후
10월 31일 저녁부터 11월 1일 오전까지 Claude Code에 보낸 프롬프트와 결과를 시간순으로 정리했다. 두 프롬프트 모두 myblog의 /blogtecharticle 커맨드를 썼다. 19:38 기술 아티클 5편 발행 · Claude Code /blogtecharticle 1.
-
개발 기록 2026-10-31 오후: 기술 아티클 11편 발행, 다이어그램 추가, 공개 확인
이번 기록은 10월 31일 저녁부터 11월 1일 오전까지 myblog에서 한 작업이다. /blogtecharticle 커맨드로 기술 아티클 11편을 두 번에 나눠 발행했고, 편마다 다이어그램을 넣은 뒤 이미지 추가 커밋을 남겼다. 발행 흐름 10월 31일 저녁에 5편을 먼저 발행했다.
-
Spring Boot에서 Transactional Event와 비동기 처리의 함정
주문 저장 뒤 알림 발송처럼 "커밋된 다음에 할 일"을 Spring 이벤트로 떼어 내면 코드는 깔끔해지지만, 이벤트가 언제 실행되고 어느 트랜잭션에 묶이는지 모르면 데이터가 조용히 사라진다. 이 글은 @EventListener, @TransactionalEventListener, @As
-
분산 환경에서 멱등 API와 중복 요청 방지 설계
분산 환경에서 같은 요청은 반드시 두 번 이상 들어온다. 클라이언트와 게이트웨이는 응답이 늦으면 다시 보내고, 서버는 이미 처리를 끝냈어도 그 사실을 알릴 방법이 없을 때가 있다. 이 글은 주문·결제처럼 두 번 실행되면 안 되는 API를 멱등 키IdempotencyKey와 유일 제약으로
-
대량 데이터 처리에서 Cursor·Batch·Bulk Insert 비교
수십만~수백만 건을 읽고 쓰는 야간 배치나 데이터 이관은 SQL보다 "몇 번 왕복하고 몇 번 커밋하느냐"가 시간을 정한다. 이 글은 읽는 쪽의 OFFSET 페이징·키셋 페이징·서버 커서와, 쓰는 쪽의 한 건씩 INSERT·JDBC 배치·벌크 로드를 같은 기준왕복, 메모리, 커밋 단위,
-
CUBRID HA 장애 전환 시 애플리케이션 복구 전략
CUBRID HA는 master 노드가 죽으면 slave를 master로 올려 DB를 살려 두지만, 애플리케이션까지 저절로 살아나지는 않는다. 전환되는 몇십 초 동안 진행 중이던 트랜잭션은 롤백되고, 풀에 남은 연결은 죽은 채 남으며, 재시도를 잘못 넣으면 같은 거래가 두 번 들어간다.
-
HikariCP Connection Pool 고갈 원인과 용량 산정
HikariCP 커넥션 풀이 고갈되면 DB는 한가한데 애플리케이션 요청이 30초씩 멈췄다가 한꺼번에 실패한다. 풀 크기를 늘리는 것이 첫 반응이지만, 원인이 커넥션을 오래 잡는 코드라면 늘린 만큼 DB 부하만 커진다. 이 글은 고갈이 어떻게 보이는지, 무엇이 고갈을 만드는지, 지표로 원
-
Spring Boot와 JBoss EAP 배포 시 ClassLoader 충돌 해결
내장 Tomcat에서 잘 돌던 Spring Boot WAR가 JBoss EAP에 올리는 순간 NoSuchMethodError나 ClassCastException으로 멈추는 일은 흔하다. 원인은 대부분 같은 라이브러리가 서버 모듈과 WAR 안에 동시에 있고, JBoss가 생각과 다른 쪽을
-
2026년 11월 1일 주간 레딧 베스트 5선: 개발, 시스템 관리, 푸념, 노동 이야기
이번 주 레딧에서 추천수가 가장 많았던 글을 r/programming, r/sysadmin, r/Vent, r/antiwork 네 곳의 This Week Top 목록에서 모았습니다. 고정 공지는 제외하고, 추천수 기준 상위 5개씩 골랐습니다. 외부 기사는 원문을 열어 확인했고, 사진이나