전체 글
이 블로그에 올라온 모든 글입니다.
-
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일을 주 단위로 나눠 해야 할 일과 그 주에 반드시 남겨야 할
-
AI 코딩 프롬프트 기록 2026-10-29 오후
13:04 vox 스타일 한양 영상 · Claude Code /topicvideoyoutube 당신이 16세기 한양에 떨어진다면 벌어지는 일 주제로 영상을 만드는데 스킬을 좀더 업그레이드 해서 만들어주는데 아래 추가 내용을 첨부 했는데 참고해서 만들어 줄래. Key Summary 원인:
-
개발 기록 2026-10-29 오후: 영상 스킬 maker·checker 분리, 제작 속도 최적화, three.js 템플릿
오후 내내 topicvideoyoutube 스킬을 손봤다. 핵심은 세 가지다. 영상을 vox 스타일로 바꿨고, 제작과 검수를 두 에이전트로 나눴고, 느려진 제작 속도를 측정해서 줄였다. 그 사이에 영상 4편을 「아키의 공백」 채널에 올렸다. 중간에 Open Notebook을 설치했다가
-
AI 코딩 프롬프트 기록 2026-10-29 오전
프롬프트 19:51 피라미드 영상 기획과 제작 · Claude Code 이집트 피라미드 역사 에 대한 영상을 만들고 싶은데 길이에 제한은 없어. 아래 워크플로우 순서대로 진행 해줘. 1. 이미지는 codex cli를 통해서 만들어줘. 2. 자막에 쓰일 대본을 써줘. 3. 대본을 기반으로
-
개발 기록 2026-10-29 오전: 주제만 넣으면 유튜브까지 올리는 영상 스킬, 썸네일 스킬, 무료 TTS 전환
어제 저녁부터 오늘 오전까지 역사 교양 영상을 만드는 흐름을 처음부터 한 번 손으로 돌렸다. 그 과정을 스킬로 묶었고, 스킬로 영상 여러 편을 연달아 올렸다. 썸네일 만들기도 스킬로 분리했다. 중간에 ElevenLabs 크레딧이 떨어져서 음성 엔진을 무료 edgetts로 바꿨다. 영상을
-
2026년 10월 29일 AI 뉴스 정리
2026년 10월 27일과 28일에 보도된 AI 소식 12건을 정리했습니다. 최근 24시간 안팎에서 원문을 확인할 수 있는 항목만 담았고, 날짜가 불분명하거나 원문 확인이 어려운 소식은 뺐습니다. 정책과 규제 트럼프, "인공지능AI" 용어 금지 방침 밝혀: 트럼프 대통령이 10월 27일
-
AI 코딩 프롬프트 기록 2026-10-28 오후
프롬프트 17:47 다른 도구 프롬프트도 모으는지 확인 · Claude Code 클로드코드 세션에 있는 프롬프트만 만들어서 올리니 아님 codex, agy 세션에서 작성한 프롬프트도 정리해서 올리니? 지금은 Claude Code 세션만 정리한다는 답을 받았다. Codex 기록은 JSON
-
개발 기록 2026-10-28 오후: 헤더 검색창, Codex·Antigravity 프롬프트 수집, 커밋 정리
이번 기간에는 블로그 초안 자동 정리 스크립트가 Claude Code뿐 아니라 Codex와 Antigravityagy 프롬프트도 모으게 했다. 블로그 헤더에는 검색창을 붙여 배포했고, 그동안 쌓인 작업을 커밋으로 정리했다. 프롬프트 수집 대상을 Codex까지 넓히기 이 블로그의 "AI