기술 아티클
직접 쓰고 다듬은 기술 글입니다. 학습 일지에서 검증된 내용을 정리해 올립니다.
-
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를 살려 두지만, 애플리케이션까지 저절로 살아나지는 않는다. 전환되는 몇십 초 동안 진행 중이던 트랜잭션은 롤백되고, 풀에 남은 연결은 죽은 채 남으며, 재시도를 잘못 넣으면 같은 거래가 두 번 들어간다.