2편에서 검색 인덱스를 정리했다. 이번엔 그 검색 결과를 "어떻게 나눠 주느냐" —페이징 이야기다. 교과서의 OFFSET 방식을 버리고 커서로 간 기록.페이징의 기본형은 다들 이렇게 배운다.이 쿼리의 함정은 OFFSET의 동작 방식에 있다.DB는 10,020행을 읽어서

1편은 캐시였고, 이번엔 검색이다. 인프라 일지 5편의 부하 테스트에서"가장 무거운 API = 검색"이었던 이유와, 그걸 어떻게 인덱스로 풀었는지.검색 기능의 핵심 조건은 이거다. 대소문자 무시 + 부분 일치.동작은 잘 한다. 문제는 실행 계획이다. sequential

인프라 구축 일지는 끝났고, 이번엔 그 위에서 돌아가는 애플리케이션 이야기다.첫 주제는 캐시. Redis를 붙이는 건 쉬운데, "Redis가 아플 때"를 설계하는 게 진짜 일이었다.메인 화면은 조회가 압도적으로 많고, 내용은 자주 안 바뀐다.리스트 첫 페이지, 추천 목

구축 일지 마지막 편이다. 인프라는 다 만들어져 있었다.문제는 "이대로 열어도 되나?"에 답하는 일이었다.기능 개발이 끝나고 오픈 일정이 잡히면, 이상하게 그때부터 불안해진다.개발 환경에선 편했던 것들이 운영에선 구멍이 되기 때문이다.오픈 전 마지막 주에 한 것들을 영

구축이 끝나면 운영이 시작된다. 오픈 이후 매일 아침 반복하는4종 점검 루틴과, 로그를 "읽는 기준"을 정한 이야기다.오픈 직후엔 불안해서 CloudWatch 콘솔을 하루에도 몇 번씩 열었다.그런데 콘솔을 돌아다니는 건 시간도 걸리고, 볼 때마다 보는 범위가 달랐다.어

5편까지는 "만든" 이야기였다. 이번엔 서비스를 오픈하고 나서실제로 들어온 공격과, 그걸 막은 기록이다.서비스를 인터넷에 열면 사람보다 봇이 먼저 온다는 말이 있는데, 진짜였다.오픈 직후부터 ALB 액세스 로그에 이런 요청들이 찍히기 시작했다.우리는 Spring Boo

5편까지는 "만든" 이야기였다. 이번엔 서비스를 오픈하고 나서실제로 들어온 공격과, 그걸 막은 기록이다.서비스를 인터넷에 열면 사람보다 봇이 먼저 온다는 말이 있는데, 진짜였다.오픈 직후부터 ALB 액세스 로그에 이런 요청들이 찍히기 시작했다.우리는 Spring Boo

3·4편에서 비밀값과 배포 인증을 정리했다. 이번엔 트래픽이 몰리면 알아서 늘어나는 구조,그리고 그게 진짜 동작하는지 부하를 걸어 실측한 이야기다.ECS 오토스케일링은 Target Tracking 방식으로 걸었다. terraform으로 몇 줄이면 된다.CPU가 70%를

3편에서 "비밀은 한 군데에만 산다"를 만들었다. 그런데 정리하고 보니아직 한 군데가 남아 있었다. GitHub Secrets에 들어 있는 배포용 AWS 액세스 키.우리 배포는 GitHub Actions가 한다. develop에 push하면 스테이징, main이면 운영

1편은 네트워크, 2편은 컴퓨팅이었다. 이번엔 눈에 안 보이는 것 — 비밀값 이야기다.DB 비밀번호, JWT 키, OAuth 시크릿, 그리고 AWS 액세스 키 자체까지.인프라를 구축하다 보면 비밀값이 계속 늘어난다.DB 비밀번호, JWT 서명 키, 소셜 로그인 클라이언

1편에서 네트워크를 3층으로 나눴다. 이번엔 그 2층(앱 층)에 뭘 올릴지 정하는 이야기다.Spring Boot 앱을 AWS에서 돌리는 방법은 여러 가지다. 후보를 두 개로 좁혔다.EC2: 가상 서버를 직접 빌려서 그 위에 도커/앱을 올린다ECS Fargate: 컨테이

백엔드 개발자가 AWS 인프라를 처음부터 직접 구축한 기록이다.지난 글(Flyway 삽질기)에서 예고했던 구축 일지, 그 첫 번째. 네트워크부터 시작한다.인프라를 구축하면서 가장 먼저 한 일은 서버를 띄우는 게 아니었다. 네트워크 도면 그리기였다.AWS에서 네트워크의

시리즈 예고: 지금 운영 중인 서비스의 백엔드 인프라(AWS ECS Fargate + Terraform)를 직접 구축했다.구축 과정은 따로 연재로 풀 예정이고, 오늘은 정식 오픈 전 준비 기간에 겪은 사건 하나를 먼저 꺼낸다.실사용자가 없던 시기라 피해는 없었지만, 개

3편에서 AWS 환경 세팅을 마쳤다.이제 Qwen-Image-Edit-2511 모델을 실제로 올려보자.생각보다 순탄하지 않았다.작업 폴더를 만들고 모델을 내려받는다.모델 크기가 약 40GB라 시간이 좀 걸린다.resume_download=True 덕분에 중간에 끊겨도

앞서 실 서비스들을 직접 써보면서 Out Painting이 어떤 건지 감을 잡았다.이제 직접 모델을 구축해서 테스트해볼 차례다.회사에서 실제로 사용 중인 GPU 서버에 바로 올리기엔 부담이 있었다.검증되지 않은 모델을 프로덕션 서버에 올리는 건 리스크가 크니까.AWS에

Out Painting이라는 개념을 처음 접했을 때 꽤 흥미로웠다.이미지를 잘라내거나 비율을 바꿔야 할 때 배경을 AI가 자연스럽게 채워준다는 거니까.직접 써보기 전에 개념부터 잡고, 상용 서비스들을 하나씩 테스트해봤다.원본 이미지의 사이즈를 변경해야 할 때, 없는 배

어느 날 팀원 중 한 명이 다음과 같은 말을 했다.choi.openai 님 Threads 포스트 (2025-12-24)4개월 만에 상용 모델을 따라잡는 오픈소스라니, 직접 돌려보고 싶다는 생각이 바로 들었다.그냥 API 쓰는 게 아니라, 모델이 내부적으로 어떻게 돌아가

비슷한 고민을 한 사람들이 이미 많았다.How To Do @Async in Spring - Baeldung — Spring @Async 적용 방법 전반을 잘 정리해놓은 글. SMTP 같은 네트워크 I/O 작업에 적용하는 게 대표적인 사례로 나온다.장시간 비동기 작업,

Virgin Road는 결혼식 당일 하객들이 쓴 편지를 PDF로 만들어 신랑/신부에게 이메일로 보낸다. 스케줄러가 매일 19시에 그날 결혼식인 방을 조회해서 PDF를 생성하고 발송한다.PDF 생성은 처음부터 Java 안에서 구현하려고 했다. Spring Boot 안에서

Virgin Road는 신랑/신부가 방을 만들면 하객들이 편지를 남기는 서비스다. 방을 만들 때 이름, 결혼 날짜, 이메일을 입력한다. 이 이메일이 나중에 PDF 발송 대상이 된다.초기 구현은 단순했다. 방 생성 요청이 오면 바로 DB에 INSERT하고 완료. 그런데