#아키텍처
-
Agentic RAG와 일반 RAG의 아키텍처 차이
일반 RAG는 질문을 한 번 검색하고 찾은 문서를 붙여 바로 답한다. 질문이 여러 단계를 거치거나 답이 여러 저장소에 흩어져 있으면 이 한 번의 검색이 빗나가고, 모델은 빈약한 근거로 그럴듯한 답을 만든다. 이 글은 검색 자체를 판단의 대상으로 만드는 Agentic RAG가 일반 RAG
-
Lamport Clock과 Vector Clock으로 분산 이벤트 순서 이해하기
서버가 여러 대면 "어느 일이 먼저 일어났는가"를 벽시계로 정할 수 없다. 서버마다 시계가 조금씩 다르고, 맞추는 도중에 뒤로 가기도 하기 때문이다. 이 글은 시계 대신 인과 관계로 순서를 매기는 Lamport Clock과 Vector Clock의 규칙을 같은 예시 하나로 계산해 보고,
-
Event Sourcing과 CQRS를 도입해야 하는 시점
Event Sourcing과 CQRS는 함께 소개되는 일이 많아 한 묶음처럼 들리지만, 둘은 서로 다른 문제를 푸는 별개의 선택이고 들어가는 비용도 다르다. 이 글은 두 패턴을 나눠서 설명하고, 도입해야 할 신호와 하지 말아야 할 신호, 도입하면 따라오는 비용, 감사 로그부터 시작하는
-
Saga Pattern과 보상 트랜잭션 실전 설계
주문·결제·재고가 서로 다른 서비스와 DB로 나뉘면 한 번의 커밋으로 전부를 묶을 수 없고, 중간 단계가 실패했을 때 앞 단계를 되돌릴 방법을 따로 만들어야 한다. 이 글은 로컬 트랜잭션을 차례로 실행하고 실패하면 보상 트랜잭션으로 취소하는 Saga 패턴을, 단계 순서·상태 테이블·멱등
-
CAP Theorem과 PACELC로 분산 시스템 설계 결정하기
복제된 데이터를 쓰는 시스템은 언젠가 노드 사이 통신이 끊기고, 그 순간 "그래도 응답할 것인가, 틀릴 수 있으니 거절할 것인가"를 고르게 된다. CAP은 이 선택이 피할 수 없다는 것을, PACELC는 장애가 없는 평상시에도 지연과 일관성 사이의 선택이 계속된다는 것을 알려 준다. 이
-
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와 유일 제약으로
-
CUBRID HA 장애 전환 시 애플리케이션 복구 전략
CUBRID HA는 master 노드가 죽으면 slave를 master로 올려 DB를 살려 두지만, 애플리케이션까지 저절로 살아나지는 않는다. 전환되는 몇십 초 동안 진행 중이던 트랜잭션은 롤백되고, 풀에 남은 연결은 죽은 채 남으며, 재시도를 잘못 넣으면 같은 거래가 두 번 들어간다.
-
서비스 장애 시 Graceful Degradation과 Circuit Breaker 설계
외부 API 하나가 느려지면 그 API를 기다리는 스레드와 커넥션이 쌓이고, 결국 그 API와 상관없는 화면까지 멈춘다. Graceful Degradation은 "무엇을 포기하고 무엇을 지킬지"를 기능마다 미리 정하는 일이고, Circuit Breaker는 그 결정을 장애 순간에 자동으
-
감리 대응을 위한 아키텍처 증적 자동 수집 시스템 설계
공공 SI의 감리는 "설계한 대로 만들었는가"를 문서와 결과물로 확인한다. 그런데 증적을 감리 직전에 사람이 모으면 날짜가 맞지 않거나, 화면 캡처가 지금 코드와 다르거나, 누가 언제 만든 파일인지 설명하지 못하는 일이 생긴다. 이 글은 빌드·검사·배포 과정에서 증적이 저절로 쌓이고,
-
TLS 종료 지점과 Reverse Proxy 신뢰 경계 설계
TLS를 어디서 끝내느냐는 인증서 위치만 정하는 일이 아니다. 그 지점이 곧 "여기부터는 평문을 본다"와 "여기부터는 앞 구간이 알려 준 클라이언트 IP와 프로토콜을 믿는다"는 신뢰 경계가 되고, 경계를 잘못 그으면 위조한 XForwardedFor 한 줄로 관리자 IP 제한이 풀린다.
-
Zero Trust 관점의 관리자 시스템 접근 통제 설계
관리자 시스템은 계정 하나만 뚫려도 전체 데이터와 설정이 넘어가는 곳이라, "VPN 안에 들어왔으니 믿는다"는 경계 모델이 가장 위험하게 작동하는 자리다. 이 글은 Zero Trust 원칙으로 관리자 접근을 신원, 단말, 정책 판정, 권한, 세션, 감사 여섯 겹으로 나눠 설계하고, 각
-
Outbox·Inbox 패턴으로 연계 데이터 정합성 확보하기
업무 데이터를 DB에 저장하고 다른 시스템에 메시지를 보내는 일을 따로 하면, 둘 중 하나만 성공하는 순간이 반드시 생긴다. 이 틈 때문에 "신청은 접수됐는데 연계 기관에는 안 갔다", "취소했는데 상대 시스템에는 승인으로 남았다" 같은 정합성 사고가 난다. 이 글은 보내는 쪽의 Out
-
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 + JBoss + Apache 이중화 아키텍처 설계
공공·금융 SI에서는 Spring Boot 애플리케이션을 내장 Tomcat이 아니라 JBoss EAP 같은 WAS에 WAR로 올리고, 앞에 Apache를 두는 구성이 여전히 많다. 서버를 두 벌 놓는 것만으로는 이중화가 되지 않는다. 버전 조합, 세션 처리, 헬스 체크, 배포 순서가 맞
-
공공 SI 비기능 요구사항 정의와 검증 기준 설계
공공 SI의 검수 분쟁은 대부분 비기능 요구사항에서 생긴다. 제안요청서에 "안정적인 성능", "충분한 보안"처럼 적힌 문장은 사업이 끝날 때 누가 어떻게 확인할지 정해져 있지 않기 때문이다. 이 글은 제안요청서의 모호한 비기능 요구사항을 측정 가능한 문장으로 바꾸고, 요구사항마다 검증
-
아키텍처 설계서와 프로젝트 관리 산출물은 어떻게 구분할까?
SI 프로젝트에서는 문서가 수십 종 나오고, 그중 상당수가 같은 내용을 서로 다른 곳에 적는다. 아키텍처 설계서에 일정이 들어가고 사업수행계획서에 기술 구조가 들어가면, 한쪽만 고쳐지는 순간 두 문서가 서로 다른 말을 한다. 이 글은 두 문서 묶음을 가르는 기준, 둘 사이에 걸치는 경계
-
AA가 프로젝트 착수 후 30일 동안 해야 할 일과 필수 산출물
애플리케이션 아키텍트AA의 첫 30일은 개발 기간 전체의 비용을 정한다. 이때 정한 구조, 표준, 기술 선택은 개발자 수십 명이 몇 달 동안 따라야 하는 기준이 되고, 늦게 바꿀수록 고치는 값이 커진다. 이 글은 착수 후 30일을 주 단위로 나눠 해야 할 일과 그 주에 반드시 남겨야 할