CS
1.Rate Limiting — 토큰 버킷, Guava, 그리고 Redis를 안 쓴 이유
앞에서 세마포어로 동시 접근 수를 4개로 제한했다. 그런데 이것만으로는 부족했다.세마포어는 "동시에 몇 개까지 허용할 것인가"를 제어하지, "얼마나 빠르게 호출할 것인가"는 제어하지 않는다. 예를 들어 permit 4개가 전부 비어있는 상태에서 요청 4개가 동시에 들어
2.트랜잭션 & DB — 30초짜리 트랜잭션을 쪼갤 수밖에 없었던 이유
추리게임의 시나리오 생성 흐름은 이렇다. 풀스토리를 만들고, 용의자별 알리바이를 생성하고, 증거를 배치하고, 용의자 정보를 저장한다. 이 과정에서 LLM을 여러 번 호출하고, 각 결과를 DB에 저장한다.처음에는 이 전체를 하나의 트랜잭션으로 묶었다. "전부 성공하거나
3.세마포어 & 동시성 제어 — AQS, CAS, 그리고 왜 세마포어인가
프리티어 LLM API를 쓰고 있었다. 당연히 동시 호출 수에 제한이 있었고, 백엔드 스레드도 4개로 제한된 환경이었다. 동시에 4개 이상의 요청이 LLM API를 때리지 못하게 제어할 수단이 필요했다.처음부터 세마포어를 쓰려고 했던 건 아니다. synchronized
4.외부 API 연동 패턴 — 타임아웃, 재시도, 서킷 브레이커
이 프로젝트에서 LLM은 외부 API다. 내가 제어할 수 없는 영역이다. 언제 응답이 올지, 얼마나 걸릴지, 실패할지 성공할지 모두 내 손 밖이다.세마포어와 Rate Limiter로 RPM 초과를 막고, 트랜잭션을 쪼개서 커넥션 점유 시간을 줄였다. 그런데 그것만으로는
5.스레드 & 부하 테스트 — 스레드 4개의 한계와 k6 검증
이 프로젝트는 스레드가 4개로 제한된 환경에서 돌아간다. 이 제약이 프로젝트 전체의 설계에 영향을 줬다. 세마포어 permit을 4로 잡은 것도, 트랜잭션을 쪼갠 것도, Rate Limiter를 건 것도 결국 이 4개라는 제약에서 출발한 거다.그런데 "스레드 4개"라는