선을 넘는 개발 로그

같은 프롬프트, 왜 매번 돈을 내나 — Prompt Caching 실전 가이드

왜 고정 입력 토큰이 비용 문제가 되는가LLM API 비용은 입력 토큰과 출력 토큰 수의 합으로 결정된다. 출력은 요청마다 달라지지만, 시스템 프롬프트나 RAG 문서처럼 고정된 입력 구간은 매 요청에 그대로 반복해서 전달된다. 요청 수가 늘어날수록 이 반복 구간의 비용이 전체 청구액을 지배하게 된다.예시 1. 계약서 검토 서비스가 2,000 토큰짜리 시스템 프롬프트를 고정으로 쓴다고 가정하자. 하루 1,000번 호출되면 시스템 프롬프트만으로 200만 토큰이 소비된다. Claude Sonnet 기준 입력 단가 $3/1M 토큰을 적용하면 이 구간에서만 하루 $6, 한 달 $180이 나간다. Prompt Caching으로 캐시 히트율 80%를 달성하면, 히트 구간은 입력 비용의 10%만 과금되어 월 $180이..

C4 Model로 소프트웨어 아키텍처 다이어그램 표준화하기

목차개요C4 모델의 네 가지 추상화 레벨Structurizr DSL로 코드 기반 다이어그램 작성다른 다이어그램 접근법과의 비교팀 단위 아키텍처 문서 표준화 전략운영 환경에서의 C4 모델 유지보수맺음말개요문제의 배경: 아키텍처 커뮤니케이션의 단절소프트웨어 팀이 성장할수록 아키텍처 논의는 점점 더 어려워지는 경향이 있습니다. 신규 입사자는 전체 시스템의 윤곽을 파악하려 하고, 시니어 개발자는 특정 서비스의 내부 설계를 논의하며, 아키텍트는 서비스 간 경계와 배포 단위에 집중합니다. 같은 화이트보드를 보면서도 세 사람이 완전히 다른 맥락으로 이야기하는 상황이 반복됩니다. 이 단절의 근본 원인은 각자가 "다른 해상도(resolution)"로 시스템을 바라보기 때문입니다. C4 모델(C4 Model)은 바로 이 ..

Temporal 운영 주의점 — 히스토리 한도·버전 관리·워커 용량

목차운영에서 실제로 터지는 것들히스토리 한도와 페이로드 크기코드 변경과 버전 관리워커 용량과 지표보존 기간·정리·보안맺음말운영에서 실제로 터지는 것들Temporal은 개발 단계에서 잘 도는 것에 비해 운영에서 걸리는 지점이 예상과 다른 편입니다. 워크플로우가 실패해서 문제가 되는 경우보다, 실패하지 않은 채 진행만 멈추거나 히스토리가 한도에 닿아 강제 종료되는 경우가 더 자주 옵니다.이 글은 운영 단계에서 준비해 둬야 할 항목을 다섯 갈래로 정리합니다. 도입 초기에 이 중 어느 것도 준비되어 있지 않으면, 첫 사고가 났을 때 원인을 짚는 데만 며칠이 걸립니다.조용히 멈추는 실패가 가장 위험하다증상겉보기실제 원인워크플로우가 며칠째 실행 중정상처럼 보임결정성 위반으로 태스크가 무한 실패액티비티가 계속 실행 ..

Elasticsearch 인덱스 매핑 설계와 샤드 최적화 전략

목차개요Elasticsearch 인덱스 매핑의 기본 원리정적 매핑 설계 전략샤드 설계와 크기 최적화인덱스 생명주기와 롤오버 전략운영 환경 적용 시 고려사항맺음말개요문제 배경: 검색 성능 병목의 원인Elasticsearch를 처음 도입할 때 많은 팀이 기본 설정으로 빠르게 시작합니다. 단 몇 줄의 설정으로 문서를 색인하고 즉시 검색할 수 있다는 점이 매력적이기 때문입니다. 그러나 데이터 규모가 수억 건을 넘어서고 동시 트래픽이 증가하면서, 초기에는 보이지 않던 문제들이 수면 위로 드러납니다. 검색 응답 시간이 수 초로 치솟거나, 클러스터 상태가 yellow에서 red로 전환되거나, 인덱싱 처리량이 급격히 하락하는 현상이 반복됩니다. 이러한 문제의 상당수는 초기 인덱스 매핑 설계와 샤드 구성의 미흡함에서 비..

Spring Cloud Config Server로 분산 설정 중앙 관리하기

목차개요Spring Cloud Config Server의 핵심 구조Config Server 구축과 클라이언트 연동백엔드 저장소 전략과 선택 기준동적 설정 갱신과 변경 전파운영 환경 적용 시 고려사항맺음말개요문제 배경마이크로서비스 아키텍처가 보편화되면서 수십 개의 서비스가 각자의 설정 파일을 관리하는 구조가 일반적이 되었습니다. 데이터베이스 접속 정보, 외부 API 키, 피처 플래그, 타임아웃 값 같은 환경별 설정이 서비스마다 따로 존재한다면, 운영 환경에서 단 하나의 값만 바꾸려 해도 수십 개의 저장소를 순차적으로 수정하고 재배포해야 합니다. Spring Cloud Config Server는 이 문제를 해결하기 위해 설계된 중앙 집중식 설정 관리 솔루션입니다. 설정 파일을 하나의 저장소에서 버전 관리하고..

목차개요Spring Data JDBC의 핵심 철학핵심 구성 요소와 동작 원리실제 프로젝트 적용: 도메인 모델 구현성능 특성과 JPA 비교 분석운영 환경에서의 고려사항맺음말개요문제 배경: 영속성 계층의 복잡성Spring 기반 애플리케이션에서 데이터 접근 계층을 설계할 때 가장 먼저 떠오르는 선택지는 JPA, 그 중에서도 Hibernate입니다. JPA는 객체-관계 매핑(ORM)의 사실상 표준으로 자리잡았고, 복잡한 도메인 모델을 데이터베이스에 투명하게 매핑해 주는 강력한 도구입니다. 그러나 실제로 프로젝트에서 JPA를 어느 정도 사용하다 보면 예상치 못한 복잡성에 직면하게 됩니다. 영속성 컨텍스트의 상태 변화, 지연 로딩으로 인한 LazyInitializationException, N+1 쿼리 문제, 연쇄..

목차비교가 성립하는 지점과 아닌 지점전달 모델의 차이순서·재시도·상태를 다루는 방식같은 요구를 각각 어떻게 푸는가함께 쓰는 구성맺음말비교가 성립하는 지점과 아닌 지점"비동기 처리는 Kafka로 하면 되는데 Temporal이 왜 필요한가"라는 질문을 자주 만납니다. 두 도구 모두 요청을 받아 나중에 처리하고, 실패하면 다시 시도하게 해 주기 때문입니다.먼저 정리하면, Kafka는 이벤트를 저장하고 나눠 주는 로그이고, Temporal은 한 건의 처리 흐름을 끝까지 책임지는 오케스트레이터입니다. 겹치는 부분은 "비동기로 넘긴다"는 표면적인 모양뿐이고, 그 아래 책임 범위는 다릅니다.각자가 해결하는 문제문제KafkaTemporal발생한 사실을 여러 소비자에게 나눠 주기잘함하지 않음대량 이벤트를 높은 처리량으로..

목차개요Hibernate 캐시 계층 구조 이해2차 캐시 설정과 구현Query Cache 적용 방법성능 특성과 대안 비교운영 환경 적용 시 고려사항맺음말개요문제 배경: JPA 반복 조회의 성능 병목JPA와 Hibernate를 사용하는 프로젝트에서 가장 빈번하게 마주치는 성능 병목 중 하나는, 변경 빈도가 낮은 데이터를 트랜잭션마다 반복해서 데이터베이스에서 가져오는 패턴입니다. Hibernate 2차 캐시(Second Level Cache)와 Query Cache는 이 문제를 JPA 레이어에서 직접 해결하는 메커니즘으로, 애플리케이션 코드를 거의 수정하지 않고도 반복 조회 성능을 수 배에서 수십 배까지 끌어올릴 수 있습니다. 이 글에서는 두 캐시의 동작 원리, 설정 방법, 그리고 운영 환경에서 안전하게 적용..

목차두 도구가 서 있는 자리실행 모델 비교실패와 재시작을 다루는 방식처리량과 건당 비용선택 기준과 함께 쓰는 구성맺음말두 도구가 서 있는 자리"야간에 도는 정산 처리를 Spring Batch로 짤까 Temporal로 짤까"는 자주 나오는 질문입니다. 둘 다 여러 단계를 순서대로 실행하고, 실패하면 다시 돌릴 수 있게 해 주기 때문입니다.그런데 두 도구의 출발점은 다릅니다. Spring Batch는 "많은 데이터를 한 번에 처리하는" 문제를, Temporal은 "한 건의 처리를 오래 이어 가는" 문제를 풉니다. 이 차이를 기준으로 삼으면 대부분의 선택이 정리됩니다.배치 프레임워크 쪽 구조는 앞서 Tasklet부터 파티셔닝까지 한 편으로 정리한 적이 있으니, 배치 쪽 용어가 낯설다면 그 글을 먼저 보시는 편..

목차개요RLS 동작 원리와 핵심 구조RLS 정책 설계와 구현멀티테넌트 격리 패턴 심화성능 특성과 대안 기술 비교운영 환경 적용 시 고려사항맺음말개요문제 배경: 하나의 데이터베이스, 여러 고객멀티테넌트 SaaS 아키텍처에서 가장 까다로운 문제 중 하나는 단일 데이터베이스 내에서 고객(테넌트)별 데이터를 완전히 격리하는 일입니다. PostgreSQL의 Row-Level Security(RLS)는 이 문제를 데이터베이스 엔진 수준에서 해결하는 메커니즘으로, 애플리케이션 코드가 WHERE 절을 빠뜨리거나 잘못 작성하더라도 데이터 유출이 발생하지 않도록 강제합니다. 이 글에서는 RLS의 내부 동작 원리부터 운영 환경에서의 실제 적용 패턴까지, 중급 이상의 백엔드 개발자가 현업 프로젝트에 바로 적용할 수 있는 수준..