Small Asteroid Blog

Kubernetes를 운영하다 보면 dev / cbt / prod처럼 환경이 여러 개로 나뉘고, 리소스 형태는 같은데 값만 다른 상황이 흔하다.예를 들면 Deployment/Service/Ingress는 동일한 구조를 유지하면서도 환경마다 image tag, replicas, resources, Ingress host, annotation 같은 값은 달라진다.이때 선택지는 보통 두 가지다.환경별로 YAML을 복사해서(dev.yaml, prod.yaml...) 각각 관리한다.공통은 하나로 두고, 환경별 차이만 관리한다. (Kustomize 방식)이 글에서는 두 번째 방식인 Kustomize를 왜 쓰는지, 특히 base는 동일하고 환경별로 다른 내용만 있을 때 어떤 이득이 있는지 정리한다. 문제: 환경별 Y..

작성 배경: Config 업데이트 기능 구현 시 동적 쿼리 필요성으로 인해 R2dbcEntityTemplate 도입핵심 문제: Request에 값이 없는 필드는 업데이트하지 않고, 있는 필드만 선택적으로 업데이트 개요Spring Data R2DBC는 리액티브 데이터베이스 접근을 위한 두 가지 주요 패턴을 제공합니다:Repository 인터페이스 - 선언적 쿼리 방식R2dbcEntityTemplate - 프로그래밍 방식의 동적 쿼리 Repository (@Query) 방식특징선언적(Declarative) 방식인터페이스에 @Query 어노테이션으로 SQL 작성컴파일 타임에 쿼리가 고정됨Spring Data의 표준 패턴코드 예시public interface ConfigRepository extends R2db..

동생과 이야기하다가 이런 불만을 들었다."문서 찾는 게 너무 오래 걸려. 사람마다 케이스가 다르고, 했던 내용인거 같은데 관련 파일을 찾으려고 여러 파일을 일일이 열어봐야 해서 시간이 너무 오래 걸려" 사내 공유 폴더에 문서는 잘 정리되어 있는데, 파일명과 안에 내용들을 다 찾아봐야해서 시간이 많이 든다고 했다. 요구사항 정리파일 내용으로 검색 - HWP, PDF, DOCX 파일 내용까지 검색쉬운 사용 - 브라우저만 열 줄 알면 됨보안 - 문서는 절대 외부로 나가면 안 됨제약사항별도 서버 구축 불가외부 클라우드/API 사용 불가PC마다 프로그램 설치 강요 불가 어떻게 만들었나요구사항과 제약사항을 놓고 고민했다. 서버는 못 세우고, 클라우드도 못 쓰고, 프로그램 설치도 강요할 수 없다면... 남은 건 뭘까..

Google에서 Antigravity가 나왔다고 해서 사용해봤다. 나는 주로 Gemini, Codex, Claude CLI로 사용하는데, Antigravity와 CLI로 사용하는 거는 무슨 차이가 있을까? Antigravity vs CLI, 뭐가 다를까?간단히 말하면Antigravity = AI가 주도하는 IDE(에이전트 작업실)Gemini CLI = 터미널 안에서 쓰는 AI 코딩 에이전트같은 코딩하는 AI지만, 어디에 붙어 있고(IDE vs 터미널), 누가 주도권을 가지느냐(에이전트 vs 개발자) 가 제일 큰 차이라고 한다. 실제 사용해본 느낌Antigravity 내가 원하는 작업에 대한 내용을 설계해서 md로 만든 후 "만들어줘"라고 했을 때, 전체적인 프로젝트 설계와 구현을 잘하는 것 같다.특히 ..

캐시를 쓰려고 하면 Memcached,Redis 두 개가 있다.둘 다 “인메모리 캐시”지만, 성격이 다르다.실무 기준으로 어떤 걸 언제 쓰면 좋은지만 간단히 정리해보겠다. 1. 한 줄 요약Memcached 단순 key-value 캐시. 가볍고 빠르다. 그냥 “DB 앞에 두는 캐시”만 필요할 때.Redis인메모리 데이터 스토어. 자료구조, 기능이 매우 많다.캐시 + 세션 + 토큰 + 랭킹 + 큐 + 락 등 “상태”를 다루고 싶을 때. 2. 공통점메모리에 데이터를 올림key → value 로 읽기DB 앞단에 두고 읽기 부하 줄이는 용도예를 들어, 상품 상세 조회의 이 패턴까지는 Redis, Memcached 모두 동일하게 가능하다.1) 캐시에서 product:{id} 조회2) 있으면 바로 반환3) 없으면 D..

들어가며프론트엔드 개발을 시작한 지 얼마 되지 않은 개발자라면 누구나 한 번쯤은 고민하게 되는 문제가 있습니다. "컴포넌트를 어디까지 나눠야 할까?"저 역시 기존 보일러플레이트를 활용한 개발에서 점점 커져가는 컴포넌트와 늘어나는 중복 코드를 보며 같은 고민에 빠졌습니다. 그리고 최근 팀 내 동료 개발자들과 나눈 논의를 통해 중요한 인사이트를 얻을 수 있었습니다. 거대해져 가는 컴포넌트현재 상황남이 만든 보일러플레이트에서 복사-붙여넣기로 시작한 개발나름대로 컴포넌트화를 시도했지만 중복 코드가 계속 증가하나의 컴포넌트에 모든 기능을 담으려다 보니 관리가 점점 어려워짐실제 예시를 들면, 프로젝트를 진행하면서 다양한 화면에서 검색 기능이 필요했습니다. 각 화면마다 조금씩 다른 검색 조건들이었습니다.A 화면: 검..