풀소유

이 글의 기준은 Codex App / Codex Desktop이다. 터미널에서 codex를 직접 실행하는 Codex CLI 기준이 아니다.Codex Desktop은 프로젝트 폴더를 열고, 여러 thread와 worktree를 병렬로 굴리는 데스크톱 작업 공간이다. 그래서 도구를 붙일 때도 CLI 기준으로 생각하면 헷갈린다.내가 만들려는 구조는 이렇다.Codex Desktop→ 여러 thread/worktree로 작업한다.Codesight→ 프로젝트 구조를 미리 스캔해서 AI가 읽을 지도를 만든다.agentmemory→ thread와 세션 사이의 작업 기억을 이어준다.OmO / LazyCodex→ Codex lifecycle에 보조 hook/plugin을 붙인다. 왜 이 셋을 붙이는가Codex Deskto..

Spring의 @Configuration 클래스 안에서 @Bean 메서드를 직접 호출하면, 일반 Java 메서드 호출처럼 보이지만 실제로는 다르게 동작할 수 있다. 핵심은 @Configuration(proxyBeanMethods = true)와 Spring proxy다.문제 코드@Beanpublic Job reportJob() { return new JobBuilder("reportJob", jobRepository) .start(reportStep(null)) .build();}@Bean@JobScopepublic Step reportStep( @Value("#{jobParameters['reportDate']}") String reportDat..

Redis SentinelRedis Sentinel은 Redis master 장애를 감지하고 replica를 새 master로 승격시키는 HA 구조다. Redis Cluster처럼 데이터를 여러 노드에 분산 저장하는 구조가 아니다.구분Redis SentinelRedis Cluster목적master 장애 대응sharding + HA데이터 분산없음있음주요 기능failoverhash slot 분산적합한 상황단일 Redis의 HARedis 용량·처리량 분산Redis cache-aside 구조에서는 Redis가 정상일 때 반복 검색어를 캐시로 흡수한다. 하지만 Redis가 죽으면 cache layer가 사라지고 DB fallback이 증가한다. 따라서 이번 실험의 대상은 Redis Cluster가 아니라 Redi..

이전 글에서는 자동완성 검색 API에 Redis Cache를 붙이고 실제 입력 패턴으로 부하 테스트를 진행했다.자동완성 API의 1차 방어선은 Redis가 아니라 debounce였다. debounce를 적용하자 API 요청 수와 DB query count가 크게 줄었다.하지만 Redis 장애 테스트에서는 다른 문제가 드러났다. Redis가 운영 중 내려가자 API 실패율은 0%였지만, p95와 p99가 크게 튀었다.DB 검색 쿼리 평균 실행 시간은 12.05ms 수준이었다. 즉 전체 지연의 핵심은 DB 자체가 아니었다. 문제는 Redis 장애 시 매 요청마다 Redis get/set 실패를 기다리는 구조였다. 그래서 이번 글에서는 Redis timeout을 줄이고, CircuitBreaker를 적용했다...

1편에서는 PostgreSQL 검색 쿼리의 실행 계획을 확인했다.이번에는 실제 자동완성 API에 부하를 걸어봤다. 단순히 “Redis를 붙이면 빨라지는가?”를 확인하려는 실험은 아니다.자동완성 API에서 더 중요한 질문은 따로 있다.사용자가 검색창에 입력할 때 서버에는 어떤 요청이 발생하는가?Redis Cache는 DB 부하를 얼마나 줄이는가?Redis가 운영 중 내려가면 병목은 어디로 이동하는가?결론부터 말하면, 자동완성 검색 API의 1차 방어선은 Redis가 아니라 debounce였다.Redis는 반복 요청을 흡수한다. 하지만 잘못된 입력 패턴 자체를 줄이지는 못한다.자동완성 API의 요청 경로는 조회 중심으로 설계했다.Redis→ local stock_master→ response자동완성 API는..

현재 Repository 쿼리는 대략 다음 구조다.where s.is_active = true and ( s.search_symbol = :symbol or s.search_symbol like concat(:symbol, '%') or s.search_name_ko like concat('%', :nameKo, '%') or s.search_name_en like concat('%', :nameEn, '%') )order by case when s.search_symbol = :symbol then 0 when s.search_symbol like concat(:symbol, '%') then 1 when s.search_name_ko like concat('..

PWM 서비스를 만들면서 종목 검색 API를 구현했다. 처음에는 단순 조회 API라고 생각했다. 하지만 자동완성 UI를 붙이는 순간 검색 API의 성격이 달라진다. 사용자는 검색창에 한 번 입력하지만, 서버는 여러 번 요청을 받는다.삼삼성삼성전삼성전자입력이 바뀔 때마다 API를 호출하면 검색 한 번이 여러 요청으로 증폭된다.종목 조회, 포트폴리오 편입, 관심 종목, 차트 조회, 지수 비교가 모두 검색에서 시작된다.즉 종목 검색 API는 단순 부가 기능이 아니라 트래픽이 몰릴 수 있는 지점이다.현재 구조현재 검색은 PostgreSQL의 local master DB를 먼저 조회한다.결과가 충분하면 바로 반환하고, 결과가 없으면 외부 Provider를 호출하는 구조를 고려하고 있다.Local DB 검색→ 결과..

시장의 유동성을 판단하는 기준점이 이동하고 있다. 과거의 질서에서 유동성은 연준(Fed)이라는 단일 공급원이 금리라는 가격 조절 장치를 통해 전 세계에 흘려보내는 공공재에 가까웠다. 그러나 탈세계화라는 거대한 흐름 속에서 이 공급 체계 자체가 전략적 자산으로 변화하고 있다. 1. 붕괴되는 구질서: 달러 패권 유지를 위한 인위적 환경과거 15년은 금리가 곧 유동성을 결정하는 시대였다. 이 구질서는 미국이 달러 패권을 공고히 하고 세계화의 이득을 극대화하기 위해 설계한 '유동성 무한 공급' 체계였다. 연준은 QE와 달러 스왑라인(Swap Lines)을 동원해 글로벌 소방수를 자처했으나, 이는 본질적으로 달러 시스템의 붕괴를 막아 자국의 지배력을 유지하기 위한 선택이었다. 시장 참여자들은 미국이 자국 이익을 ..

투자자산운용사 공부를 하면서 가장 이해하기 힘들었던 건 IS-LM 곡선이었다. 특히 “실질 국민소득(Y)이 증가하면 이자율(R)이 증가한다"는 LM 곡선의 원리는 내 직관에 맞지 않는 것 같았다. 소득이 늘면 시중에 돈이 많아졌으니 돈의 가치가 내려가야 하는 것 아닌가? LM 곡선을 이해하려고 제미나이와 씨름하다 보니, 경제학에서 말하는 '소득'이 일반적인 의미의 수입이 아니라는 걸 깨달았다.1. 변수 Y의 재정의: 소득은 수입이 아니다. 우리가 일상에서 쓰는 '소득'은 내 지갑에 들어오는 현금을 떠올리게 한다. 하지만 경제학에서 Y를 소득(Income)이라 부르는 건 국가 전체가 만든 가치가 결국 국민 개개인에게 분배되기 때문일 뿐이다. 공부할 때는 이를 '물리적인 생산량'이나 '거래 규모(Volume..

유튜브를 보다 보면 심심치 않게 마주치는 영상이 있다.5년 뒤면 네 돈은 휴지 조각 된다, 초인플레이션의 서막, 당장 이 자산으로 도망쳐라 같은 빨간 글씨와 자극적인 배경음악.사실 이런 영상들을 본다고 해서 심장이 덜컥 내려앉지는 않는다.다만, 이런 공포가 대중에게 소비되는 방식과 그 이면에 숨겨진 논리적 빈틈이 흥미로울 뿐이다.정말로 내 돈의 가치가 조금씩 떨어지는 게 세상에서 가장 무서운 일일까?경제의 구조를 뜯어보면, 진짜 비극은 돈이 귀중품이 되었을 때 시작된다는 것을 알 수 있다.돈의 어원: 돌고 돌아야 생명이 유지된다우리는 흔히 화폐를 돈이라고 부른다.이 말의 어원을 찾아가 보면 흥미로운 지점이 있다.돈은 "돌고 돈다"는 말에서 유래했다는 설이 지배적이다.즉, 돈의 본질은 소유나 축적이 아니라..