기술 아티클
직접 쓰고 다듬은 기술 글입니다. 학습 일지에서 검증된 내용을 정리해 올립니다.
-
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가 파일을 읽고, 셸을 실행하고, 메일을 보내는 도구를 갖는 순간 프롬프트 인젝션은 "이상한 답변"이 아니라 "실제로 실행된 명령"이 된다. 모델이 읽는 글 어딘가에 숨은 지시 한 줄이 도구 호출로 이어질 수 있기 때문이다. 이 글은 직접·간접 인젝션이 어떻게 들어오는지,
-
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 산출
-
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가 생각과 다른 쪽을
-
서비스 장애 시 Graceful Degradation과 Circuit Breaker 설계
외부 API 하나가 느려지면 그 API를 기다리는 스레드와 커넥션이 쌓이고, 결국 그 API와 상관없는 화면까지 멈춘다. Graceful Degradation은 "무엇을 포기하고 무엇을 지킬지"를 기능마다 미리 정하는 일이고, Circuit Breaker는 그 결정을 장애 순간에 자동으
-
DB 인덱스가 있는데도 Full Scan이 발생하는 이유
인덱스를 만들었는데도 쿼리가 테이블 전체를 읽는 일은 흔하다. 원인은 대부분 세 가지 중 하나다. 조건이 인덱스를 쓸 수 없는 모양이거나, 옵티마이저가 계산해 보니 전체를 읽는 편이 싸거나, 옵티마이저가 잘못된 정보로 계산했거나. 이 글은 실행계획으로 원인을 찾는 순서와, 원인마다 SQ
-
부하 테스트에서 Coordinated Omission이 만드는 착시
부하 테스트 보고서의 P99가 1ms인데 운영에서는 수 초짜리 응답이 나온다면, 측정 도구가 느린 순간을 통째로 빼먹었을 가능성이 크다. 응답을 기다리는 동안 다음 요청을 보내지 않는 부하 도구는 서버가 멈춘 구간을 표본 한 건으로 줄여 기록하기 때문이다. 이 글은 이 현상Coordin
-
Prometheus·Grafana·Micrometer로 SLO 모니터링 구축
SLO는 "얼마나 자주 실패해도 되는가"를 숫자로 정해 두는 약속이고, 에러 버짓은 그 약속에서 아직 쓸 수 있는 실패의 양이다. 숫자를 정해도 대시보드와 경보가 그 숫자를 계산하지 않으면 SLO는 문서에만 남는다. 이 글은 Spring Boot 애플리케이션에서 Micrometer로 요
-
Apache mod_jk와 JBoss AJP 연결 구조 및 장애 분석
Apache 앞단에 mod_jk를 두고 JBoss와 AJP로 붙인 구성은 공공·금융 SI에서 아직 흔하다. 이 구성의 장애는 대부분 애플리케이션이 아니라 연결에서 난다. mod_jk의 연결 풀, WAS의 스레드 수, 방화벽의 유휴 시간이 서로 맞지 않으면 503, 간헐적 지연, 세션 끊
-
감리 대응을 위한 아키텍처 증적 자동 수집 시스템 설계
공공 SI의 감리는 "설계한 대로 만들었는가"를 문서와 결과물로 확인한다. 그런데 증적을 감리 직전에 사람이 모으면 날짜가 맞지 않거나, 화면 캡처가 지금 코드와 다르거나, 누가 언제 만든 파일인지 설명하지 못하는 일이 생긴다. 이 글은 빌드·검사·배포 과정에서 증적이 저절로 쌓이고,
-
TLS 종료 지점과 Reverse Proxy 신뢰 경계 설계
TLS를 어디서 끝내느냐는 인증서 위치만 정하는 일이 아니다. 그 지점이 곧 "여기부터는 평문을 본다"와 "여기부터는 앞 구간이 알려 준 클라이언트 IP와 프로토콜을 믿는다"는 신뢰 경계가 되고, 경계를 잘못 그으면 위조한 XForwardedFor 한 줄로 관리자 IP 제한이 풀린다.
-
공공 SI 환경의 CI/CD 배포·백업·롤백 자동화
공공 SI의 운영 배포는 망분리, 변경 승인, 정해진 작업 시간 안에서 이뤄진다. 이 조건에서 사람이 WAR를 복사하고 로그를 눈으로 보는 배포는 실수 한 번에 서비스가 멈추고, 무엇이 언제 바뀌었는지도 남지 않는다. 이 글은 빌드부터 반입, 승인, 백업, 노드별 배포, 헬스체크, 자동
-
Zero Trust 관점의 관리자 시스템 접근 통제 설계
관리자 시스템은 계정 하나만 뚫려도 전체 데이터와 설정이 넘어가는 곳이라, "VPN 안에 들어왔으니 믿는다"는 경계 모델이 가장 위험하게 작동하는 자리다. 이 글은 Zero Trust 원칙으로 관리자 접근을 신원, 단말, 정책 판정, 권한, 세션, 감사 여섯 겹으로 나눠 설계하고, 각
-
Spring Security에서 IDOR·BOLA 취약점 방어하기
IDOR·BOLA는 로그인한 사용자가 주소의 번호 하나만 바꿔 남의 주문, 남의 신청서, 남의 계좌를 읽거나 고치는 취약점이다. 인증과 역할 검사를 모두 통과한 요청에서 생기기 때문에 Spring Security 설정만으로는 막히지 않고, 객체를 꺼내는 코드마다 "이 사용자의 것인가"를
-
AI Agent의 Context Engineering과 메모리 계층 설계
같은 모델을 써도 어떤 에이전트는 일을 끝내고 어떤 에이전트는 엉뚱한 파일을 고친다. 차이는 대개 모델이 아니라 "이번 호출에 무엇을 넣었는가"에서 난다. 이 글은 컨텍스트 창을 작업대로 보고 지침·절차·장기 기억·외부 지식을 계층으로 나눠 필요할 때만 불러오는 설계, 그리고 실제로 쓰
-
JVM Thread Dump와 Heap Dump로 장애 원인 분석하기
Java 서비스가 멈추거나 느려졌을 때 가장 흔한 대응은 재시작이고, 재시작하는 순간 원인의 증거도 함께 사라진다. Thread Dump는 그 순간 모든 스레드가 무엇을 기다리는지, Heap Dump는 메모리를 무엇이 붙잡고 있는지를 보여 주는 유일한 기록이다. 이 글은 증상별로 어떤
-
망분리 환경의 Maven·npm 의존성 공급망 보안
망분리 환경은 외부 공격이 막혀 있다고 믿기 쉽지만, 개발에 필요한 라이브러리는 결국 인터넷에서 받아 안으로 들인다. 반입 과정에 검사와 기록이 없으면 악성 패키지와 알려진 취약점도 라이브러리와 함께 내부망에 들어오고, 사고가 났을 때 어디에 퍼졌는지조차 답하지 못한다. 이 글은 Mav
-
Outbox·Inbox 패턴으로 연계 데이터 정합성 확보하기
업무 데이터를 DB에 저장하고 다른 시스템에 메시지를 보내는 일을 따로 하면, 둘 중 하나만 성공하는 순간이 반드시 생긴다. 이 틈 때문에 "신청은 접수됐는데 연계 기관에는 안 갔다", "취소했는데 상대 시스템에는 승인으로 남았다" 같은 정합성 사고가 난다. 이 글은 보내는 쪽의 Out
-
AI Agent Eval 파이프라인과 회귀 테스트 자동화
AI 에이전트는 프롬프트 한 줄, 모델 버전, 도구 설명 하나만 바꿔도 전혀 다른 곳이 깨진다. 같은 입력에도 결과가 매번 조금씩 달라서, 사람이 몇 번 써 보고 "괜찮네"로 끝내면 회귀를 놓친다. 이 글은 평가 세트 만들기부터 채점기, 반복 실행, 기준선 비교, CI 게이트, 운영 로
-
Rust와 Java의 메모리 관리 및 실행 성능 비교
Rust와 Java는 둘 다 "메모리 안전"을 말하지만 방법이 정반대다. Java는 실행 중에 가비지 컬렉터가 안 쓰는 객체를 찾아 치우고, Rust는 컴파일할 때 소유권 규칙으로 언제 메모리를 해제할지 정해 둔다. 이 차이가 메모리 사용량, 지연의 예측 가능성, 시작 시간, 개발 속도
-
eBPF를 활용한 Java 애플리케이션 성능 관측
APM과 JFR은 JVM 안에서 일어나는 일을 잘 보여 주지만, 스레드가 왜 CPU를 받지 못하는지, 어떤 시스템 호출에서 오래 기다리는지, 패킷이 재전송되는지는 JVM 밖, 커널에서 일어난다. eBPF는 애플리케이션을 바꾸거나 재시작하지 않고 커널 안에 작은 관측 프로그램을 붙여 이런
-
Linux Process와 Thread의 Kernel 관점 분석
교과서는 프로세스와 스레드를 다른 개념으로 설명하지만, Linux 커널 안에서는 둘 다 같은 구조체 하나task_struct로 표현되는 "태스크"다. 차이는 무엇을 공유하느냐뿐이다. 이 차이를 알면 top에 보이는 숫자, Java 스레드 수와 메모리, 컨텍스트 스위칭 비용, OOM 동작
-
JVM G1 GC와 ZGC의 동작 원리 및 선택 기준
Java 서비스의 P99 지연을 따라가다 보면 결국 GC 멈춤StopTheWorld을 만난다. G1은 JDK 9부터 기본 GC로 대부분의 서비스에 맞게 처리량과 멈춤 시간의 균형을 잡고, ZGC는 힙 크기와 상관없이 멈춤을 1ms 안팎으로 묶는 대신 CPU와 메모리 여유를 더 쓴다. 이
-
공공 웹서비스 파일 다운로드 권한 검증 설계
공공 웹서비스의 파일 다운로드는 가장 단순해 보이는 기능이면서 개인정보 유출 사고가 가장 자주 나는 기능이다. 목록 화면에서는 권한을 확인했는데 다운로드 주소는 파일 번호만 바꾸면 남의 첨부가 내려받아지거나, 경로 문자열을 그대로 받아 서버의 다른 파일까지 읽히는 식이다. 이 글은 다운
-
CUBRID X_LOCK과 장기 트랜잭션 병목 해결
CUBRID를 쓰는 공공 시스템에서 "특정 시간만 되면 화면이 멈춘다"는 장애의 상당수는 오래 열려 있는 트랜잭션이 잡은 배타 락X_LOCK 때문이다. 쿼리는 빠른데 락을 기다리느라 요청이 쌓이고, 결국 커넥션 풀까지 바닥난다. 이 글은 흔한 패턴으로 재구성한 장애 사례를 따라 X_LO
-
P95와 P99가 평균 응답 시간보다 중요한 이유
"평균 응답 시간 0.3초"라는 보고서는 사용자 100명 중 5명이 4초를 기다렸다는 사실을 숨길 수 있다. 응답 시간 분포는 오른쪽으로 긴 꼬리를 갖고, 장애와 민원은 그 꼬리에서 나온다. 이 글은 평균이 왜 사용자 경험을 대변하지 못하는지, P95·P99를 어떻게 재고 합치고 목표로
-
10 TPS에서 250 TPS까지: 성능 개선 사례 분석
처리량이 10 TPS에서 막힌 시스템을 250 TPS까지 올리는 과정은 대개 하나의 묘수가 아니라 다섯 개쯤의 평범한 병목을 차례로 걷어내는 일이다. 이 글은 공공 SI에서 흔히 만나는 병목들로 재구성한 대표 사례를 따라가며, 어떤 지표로 병목을 찾고 무엇을 바꿨을 때 처리량이 얼마나
-
Spring Security JWT 인증과 인가 아키텍처
JWT 인증은 예제 코드만 보면 필터 하나로 끝나 보이지만, 운영에서 문제가 되는 것은 서명 방식, 토큰 수명, 재발급과 폐기, 브라우저 저장 위치, 권한 매핑 같은 설계 결정이다. 직접 만든 JWT 필터는 검증 누락이 생기기 쉽고, 토큰을 한 번 발급하면 되돌릴 수 없다는 점을 놓치기
-
Redis Look-aside Cache 설계와 Cache Stampede 대응
LookasideCacheaside 캐시는 구현이 쉬워서 가장 많이 쓰이지만, 인기 있는 키 하나가 만료되는 순간 수백 개의 요청이 동시에 DB로 몰리는 Cache Stampede를 만든다. 평소에는 DB 부하를 크게 덜어 주던 캐시가 만료 한 번에 DB를 쓰러뜨리는 것이다. 이 글은
-
MyBatis와 JPA 성능 및 유지보수 관점 비교
국내 SI에서 MyBatis와 JPA는 "어느 쪽이 더 빠른가"로 자주 논쟁이 되지만, 실제 성능 차이는 도구보다 쓰는 방법에서 나온다. JPA는 잘못 쓰면 쿼리가 폭증하고, MyBatis는 잘 쓰면 빠르지만 스키마가 바뀔 때마다 고칠 곳이 늘어난다. 이 글은 두 기술을 성능과 유지보수
-
Spring Boot에서 트랜잭션 경계를 잘못 설계하면 발생하는 문제
@Transactional은 붙이기는 쉽지만 경계를 잘못 잡으면 운영에서 가장 찾기 어려운 장애를 만든다. 경계가 너무 넓으면 커넥션 풀이 마르고 락이 길어지고, 너무 좁거나 아예 없으면 절반만 저장된 데이터가 남는다. 이 글은 Spring Boot에서 트랜잭션 경계를 잘못 설계했을 때
-
한 줄 프롬프트로 프로젝트를 생성하는 Project Factory 설계
"프리랜서 실수령액 계산기 만들어줘" 한 줄로 저장소, 코드, 테스트, 배포까지 끝나는 흐름을 Project Factory라고 부르자. 에이전트에게 그냥 시키면 매번 다른 구조, 빠진 테스트, 확인 안 된 배포가 나온다. 공장처럼 같은 품질로 찍어 내려면 해석, 명세, 템플릿, 구현 루
-
MCP와 Skill, Hook의 차이 및 적용 기준
Claude Code를 오래 쓰다 보면 같은 요구를 MCP 서버로 풀지, Skill로 풀지, Hook으로 풀지 고민하게 된다. 셋은 모두 Claude Code를 확장하지만 누가 실행을 결정하는지, 무엇을 더해 주는지, 컨텍스트를 얼마나 쓰는지가 다르다. 이 글은 세 가지의 차이를 실제
-
Spring Boot + JBoss + Apache 이중화 아키텍처 설계
공공·금융 SI에서는 Spring Boot 애플리케이션을 내장 Tomcat이 아니라 JBoss EAP 같은 WAS에 WAR로 올리고, 앞에 Apache를 두는 구성이 여전히 많다. 서버를 두 벌 놓는 것만으로는 이중화가 되지 않는다. 버전 조합, 세션 처리, 헬스 체크, 배포 순서가 맞
-
공공 SI 비기능 요구사항 정의와 검증 기준 설계
공공 SI의 검수 분쟁은 대부분 비기능 요구사항에서 생긴다. 제안요청서에 "안정적인 성능", "충분한 보안"처럼 적힌 문장은 사업이 끝날 때 누가 어떻게 확인할지 정해져 있지 않기 때문이다. 이 글은 제안요청서의 모호한 비기능 요구사항을 측정 가능한 문장으로 바꾸고, 요구사항마다 검증
-
Maker–Checker Loop로 AI Agent 결과물 검증하기
AI 에이전트에게 자기 결과물을 검토하라고 하면 거의 항상 "문제없다"고 답한다. 만든 과정을 기억하는 쪽은 결과를 그 의도대로 읽기 때문이다. 이 글은 만드는 에이전트maker와 검사하는 에이전트checker를 나누고 그 사이를 루프로 묶는 Maker–Checker 구조를, 실제로 운
-
아키텍처 설계서와 프로젝트 관리 산출물은 어떻게 구분할까?
SI 프로젝트에서는 문서가 수십 종 나오고, 그중 상당수가 같은 내용을 서로 다른 곳에 적는다. 아키텍처 설계서에 일정이 들어가고 사업수행계획서에 기술 구조가 들어가면, 한쪽만 고쳐지는 순간 두 문서가 서로 다른 말을 한다. 이 글은 두 문서 묶음을 가르는 기준, 둘 사이에 걸치는 경계
-
Claude Code Skill 설계부터 자동 실행까지 실전 가이드
같은 지시를 세 번째 타이핑하고 있다면 Skill로 만들 때다. 이 글은 실제로 운영 중인 스킬 두 가지, 주제 하나로 교육 영상을 만들어 유튜브에 올리는 topicvideoyoutube와 매일 두 번 블로그 초안을 써 주는 자동 정리 작업을 예로 들어 Skill을 설계하고, 검수를 붙
-
AA가 프로젝트 착수 후 30일 동안 해야 할 일과 필수 산출물
애플리케이션 아키텍트AA의 첫 30일은 개발 기간 전체의 비용을 정한다. 이때 정한 구조, 표준, 기술 선택은 개발자 수십 명이 몇 달 동안 따라야 하는 기준이 되고, 늦게 바꿀수록 고치는 값이 커진다. 이 글은 착수 후 30일을 주 단위로 나눠 해야 할 일과 그 주에 반드시 남겨야 할
-
첫 글: 블로그를 열었습니다
SvelteKit + SQLite/Turso 기반 개인 블로그의 첫 글입니다.