꽥블로그

https://helloworld.kurly.com/blog/vibe-coding-with-claude-code/ 먼저 위 글을 참고했습니다. — LLM과 일할 때, 원하는 답을 얻기 위한 실전 가이드요즘 “바이브 코딩(Vibe Coding)”이라는 말이 자주 등장합니다. AI에게 자연어로 요구사항을 던지고, 코드를 생성하게 한 뒤 흐름에 몸을 맡기는 개발 방식입니다. 하지만 실무에서 바이브 코딩을 써본 사람이라면 이런 경험이 한 번쯤은 있을 것입니다. 분명 규칙을 다 써줬는데 일부가 빠져있다든지..처음엔 잘 지키다가, 대화가 길어지면 갑자기 구조가 바뀐다던지..최신 스택을 쓰자고 했는데 어느 순간 과거 패턴으로 돌아가는 경우입니다. 이건 AI가 충분히 성능을 못내줘서가 아니라,LLM의 구조적 특성을 ..

대규모 데이터 환경에서 쿼리 성능을 최적화하는 핵심 기술 중 하나는 Covered Index(Index-only Query) 를 활용하는 것이다. Covered Index는 쿼리 처리에 필요한 모든 정보가 인덱스 안에 포함되어 있어 Document 본문을 읽을 필요가 없는 경우를 의미한다.즉, Disk I/O 없이 인덱스만으로 결과를 반환할 수 있어 속도와 리소스 효율성이 매우 뛰어나다. 1. Covered Index란 무엇인가?MongoDB에서 쿼리가 Covered Index가 되기 위한 조건은 다음과 같다:필터 조건이 인덱스 필드에 포함되어야 한다. find()의 where 조건 필드가 인덱스에 존재해야함 Projection 필드와 인덱스 필드가 일치해야 한다. 반환해야 하는 필드가 전부 인덱스에 포..

Spring AOP를 활용하면, Controller 파라미터에 특정 값을 자동으로 주입하거나 메서드 실행 전·후에 공통 로직을 삽입하는 흐름을 직접 구현할 수 있습니다.이번 글에서는 @CurrentUserId 라는 커스텀 어노테이션을 만들어, Controller 메서드에서 아래처럼 userId를 직접 받지 않아도 되도록 구성해보겠습니다.@GetMapping("/recommendations")public ResponseEntity> getRecommendations(@CurrentUserId Long userId)이 userId 값은 우리가 만든 AOP @Around 어드바이스가 자동으로 주입하게 됩니다.프로젝트 초기 Spring Initializr에서 기본 Dependencies를 추가한 뒤 프로젝트를 ..

알림 시스템 설계 개요알림 시스템은 이벤트, 선물 중요할 만한 정보를 비동기적으로 제공합니다. 알림 시스템은 단순히 모바일 푸시 알림에 한정되지 않습니다. 단일 이벤트 트리거 기반 멀티 채널 알림 방송 시스템을 목표로 합니다. 1단계 문제 이해 및 설계 범위 확정대상은 푸시 알림, SMS 메시지, 그리고 이메일이 될 수 있습니다. 실시간 시스템임을 감안한다. 지원하는 단말은 iOS 단말, 안드로이드 단말, 그리고 랩톱/데스크톱입니다.기능적 요구사항지원 알림 유형: 푸시, SMS, 이메일비기능적 요구사항성능 특성: 연성 실시간(soft real-time) 시스템, 높은 부하 시 약간의 지연 허용사용자 설정: opt-out 기능(사용자가 알림을 받지 않도록하는 기능) 지원중요한건 확장성을 고려해 천만 건..

상세설계처리율 제한이란?처리율 제한(Rate Limiting)은 사용자가 일정 시간 동안 API를 호출할 수 있는 최대 요청 수를 제한하는것을 의미합니다. 특정 사용자의 과도한 요청으로 인한 서버 과부하 방지를 막아줍니다. 처리율 제한 규칙Lyft 는 처리율 제한에 오픈소스로 사용되고 있습니다. Envoy Proxy와 함께 사용하면 분산 환경에서도 중앙 집중적으로 요청 제한을 관리할 수 있습니다.Lyft는 마이크로서비스 아키텍처에서 이 Ratelimit 서비스를 광범위하게 활용하고 있습니다.공식 깃허브: https://github.com/envoyproxy/ratelimit GitHub - envoyproxy/ratelimit: Go/gRPC service designed to enable generic..

앞선 글에서는 Rate Limiter를 어디 레이어에 배치할 것인지(클라이언트 vs 서버 vs 게이트웨이 vs 인프라) 에 대해 이제 “어디에 둘 것인가”를 결정했다면, 다음 고민은 자연스럽게 이렇게 이어진다. 정확하고 성능 좋은 알고리즘은 무엇인가? Rate Limiter는 단순히 count++로 해결되지 않는다.Time Window, Token Bucket, Leaky Bucket, Sliding Log, Hybrid 방식 등 여러 알고리즘이 존재하며,각 방식은 정확도, 성능, 메모리, 구현 난이도, 분산 처리 가능 여부가 모두 다르다.또한 알고리즘을 선택했다 하더라도, 실제 시스템에서는 아래와 같은 아키텍처적 고민이 필요하다.중앙 저장소를 사용할 것인가? (Redis, DB, in-memory 등)..

들어가기처리율 제한 장치가 뭘까? 클라이언트가 서버에 보낼 수 있는 요청의 빈도(초당/분당 횟수 등)를 제한하는 장치이다. 이게 왜 필요할까? 솔직히 “처리율 제한기(Rate Limiter)” 하나만 잘 넣어도 얻는 게 되게 많아진다. 첫 번째, 시스템 보호용 방패처럼 쓸 수 있다.누가 API를 미친 듯이 때리면(봇, 스팸, DDoS 이런 거) 서버 바로 맛가는경우가 꽤 많다.. 근데 Rate Limiter가 “야, 너무 많이 보낸다? 잠깐 멈춰!” 하고 요청을 잘라주거나 늦춰줘서 전체 시스템이 터지는 걸 막아주게 된다. 실제로 Google Docs API도 “1분에 300번 이상 호출? 그럼 거절!” 이런 식으로 쓰고 있는거 같다. (이건 책에서 소개해줌)두 번째, 서비스 전체가 느려지는 걸 막아준다...