푸른영혼의 별 | Tech Blog

---

Posts (총 1371편 · 118 / 138 페이지)

• 2026-06-10

  백엔드 개발자가 알아야 할 *로컬 캐시 vs 리모트 캐시* — 언제 무엇을 *왜*

  느린 시스템 의 80% 가 적절한 캐시 로 극적 개선 된다. 그만큼 캐시가 중요 하다. 그런데 어떤 캐시를 *어디에 두는가* — 그 결정이 나중에 더 큰 *복잡도 가 된다. 한 잘못된 캐시 결정이 수개월의 *디버깅 비용 을 만들 수 있다. 이 글은 그 결정을 위한 정리다.

  #cache #local-cache #remote-cache #redis #caffeine #ehcache #performance #throughput #latency
• 2026-06-10

  백엔드 개발자가 알아야 할 *가비지 컬렉터와 메모리 사용* — JVM 중심으로

  백엔드가 *느려진다 의 체감 30% 는 GC pause 다. 단 원인을 잘못 짚으면 *반대 방향 으로 튜닝* 한다. 큰 heap 이 항상 좋은 게 아니고, GC 가 *항상 나쁜 것 도 아니다. 원리 + 측정 + 결정 — 이 세 가지가 GC 와의 *건강한 관계.

  #gc #garbage-collection #jvm #memory #heap #g1 #zgc #performance #java
• 2026-06-10

  Discord 가 *Go 로 만든 Read States 서비스를 *Rust 로 다시 쓴* 이유와 *실측 효과* — *GC pause 의 조용한 살인자*, *p99 의 *수 ms → < 1 ms*, *메모리 *5 배 감소* 의 *정공적 분해*

  Discord 가 *2020 년 자기들의 Read States 서비스 — 초당 수십만 메시지 의 *읽음 상태 추적 — 를 Go 에서 Rust 로 재작성 한 사례. *한 서비스 의 *언어 교체 가 수년 후 Rust 의 시스템 프로그래밍 지위 를 *대중 화 시킨 상징적 사건 이 됐다. 표면 상의 이유 는 “Go GC pause 가 p99 를 망친다” 였지만 — 진짜 이유는 *deterministic *메모리 모델 의 차이. 그 차이 가 실측 으로 *얼마나 큰지 가 압도적 으로 인상적.

  #discord #rust #golang #gc #garbage-collection #latency #p99 #ownership #borrow-checker #tokio #async #memory #rewrite #case-study #performance #system-language
• 2026-06-10

  캐시 적중률 (Cache Hit Ratio) — *90%면 충분한가*? *Working Set · 정책 (LRU/LFU/ARC) · Stampede · 분산 캐시* 의 *진짜 *체계화*

  “우리 캐시 적중률이 95% 인데 왜 여전히 느려요?” — 실무에서 가장 자주 묻는 캐시 관련 질문. 답은 *95% 가 사실 *낮은 숫자 일 수 있다는 것. *Working set 의 크기, *cache 의 *층층 구조, miss 의 *비용 비대칭, stampede 의 *조용한 살인자** — 이 *4 가지 의 진짜 이해 가 없으면 적중률 의 숫자 자체 가 *오해를 부른다.

  #cache #hit-ratio #miss-rate #working-set #lru #lfu #arc #caffeine #redis #cache-aside #write-through #write-back #stampede #thundering-herd #consistency-hashing #memory-hierarchy
• 2026-06-10

  수직 확장 vs 수평 확장 — CPU · Memory · HDD · SSD 각 자원에서 본 *처리량 / 응답시간* 의 개선 지점

  시스템이 느려진다. 서버를 *키울지 / 서버를 *늘릴지** 가 첫 결정이다. 단순해 보이지만 — *어떤 자원 이 병목인지에 따라 답이 다르다. 같은 느림 도 CPU 가 부족한 느림 과 메모리 가 부족한 느림 은 해결 방향이 정반대.

  #scaling #vertical-scaling #horizontal-scaling #throughput #latency #cpu #memory #ssd #hdd
• 2026-06-10

  백엔드 개발자가 알아야 할 *DB 커넥션 대기시간* — Spring Boot + HikariCP 의 *5 가지 *시간 설정* 을 *전부 *합쳐서* 보는 시야*

  동료가 p99 응답시간 알람 을 받고 와서 말했다.

  “DB 가 *느려. connection pool 늘려야 해.”*

  그 말이 틀린 건 아니다. 다만 정답도 아니다. DB 가 *느린지, pool 이 *작은지, pool 의 *시간 설정 이 서로 충돌하는지** 는 *완전히 다른 5 가지 진단. 각각의 *처방 도 완전히 다르다.

  #hikaricp #spring-boot #connection-pool #jdbc #connection-timeout #idle-timeout #max-lifetime #validation-timeout #leakdetection #database #postgresql #mysql
• 2026-06-10

  서버 성능 개선 *기초* — *DB 80% / 외부 API 15% / 서버 코드 5% 법칙* 으로 본 *측정 → 진단 → 처방* 의 일관 사이클

  서버 성능 의 체감 적 정공 은 세 줄 룰 로 압축 된다 — “측정 없이 최적화 하지 말 것, *DB 부터 의심 할 것, 코드 최적화 는 *마지막“. 실무 에서 *느린 endpoint 의 *80% 는 DB, 15% 는 외부 API 호출, 나머지 5% 만 서버 코드 자체. 우리 시간 의 80% 가 *DB 절 에 가야 한다 — 그러나 실제로는 코드 가독성 개선 같은 5% 쪽에서 시간 을 쓴다. 비대칭 이 *서버 성능 개선 의 *가장 큰 함정.

  #performance #latency #throughput #db #jpa #n-plus-one #indexing #connection-pool #caching #circuit-breaker #resilience4j #async #batch #gc #observability #apm #spring-boot
• 2026-06-10

  *백엔드 개발자가 *진짜 *신경 써야 하는 *처리량 (TPS)* — *100 → 1K → 10K → 100K* 의 *단계별 병목 / 실전 사례 6 건 / 도구 (k6 + JMeter + Pinpoint + Grafana) 사용법* 의 *postmortem 압축***

  이 글은 “우리 시스템 TPS 가 *얼마야?” 라는 질문에 백엔드 개발자가 *정확히 답할 수 있게 하는 현장 가이드 다. TPS 정의 → 단계별 병목 → 실전 사례 6 건 → 측정/부하 테스트 도구 사용법 → 함정과 학습 압축 의 5 layer 로 정리.

  #tps #rps #throughput #performance #k6 #jmeter #pinpoint #prometheus #grafana #jvm-tuning #hpa #db-connection-pool #redis #kafka #hexagonal #postmortem
• 2026-06-10

  백엔드 개발자가 봐야 할 처리량과 응답시간 — 네트워크 · 디스크 · 메모리 · 디바이스 · CPU 다시 보기

  백엔드 시스템 이 느리다 는 말을 자주 듣는다. 어디가 느린지 는 덜 자주 보인다. 사용자가 보는 3초의 지연 은 5 개의 다른 *층 에서* 1 초씩 모인 것일 수 있다. 각 층의 속도 수준 을 몸에 익혀 두면 — 처음 보는 시스템도 *대략 어디가 병목인지 짚을 수 있다.

  #throughput #latency #network #disk #memory #cpu #hardware #performance-engineering
• 2026-06-10

  백엔드 개발자가 알아야 할 *응답 시간의 진실* — *평균이 거짓말하는 이유* 와 *모니터링 시스템이 잡지 못하는 것*

  동료가 대시보드 를 보여줬다 :

  “평균 응답시간 100ms 다. *잘 돌고 있어.”*

  같은 시간 고객 게시판 에 “결제가 *10 초씩 멈춰요”* 가 3 건 올라와 있었다.

  둘 다 *옳다. 그리고 *둘 다 *틀렸다**.

  #latency #percentile #p99 #slo #sli #error-budget #prometheus #grafana #tempo #loki #distributed-tracing #monitoring