기술 아티클
직접 쓰고 다듬은 기술 글입니다. 학습 일지에서 검증된 내용을 정리해 올립니다.
-
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 기반 개인 블로그의 첫 글입니다.