브랜치 전략 얘기다. 팀에서 실제로 부딪힌 딜레마 하나를 어떻게 풀었는지,Feature Flag를 왜 안 골랐는지, 대신 뭘 골랐는지의 기록.결론부터 말하면 hotfix 브랜치를 stage 서버에 임시로 스왑하는 방식으로 갔다.기획쪽에서 카톡이 왔다."실서버 화면 하나

백엔드 일지 마지막 편이다. 화려한 기능 대신 설정 파일을 꺼냈다.application.yml에 박힌 숫자들은 대부분 "기본값을 왜 바꿨는가"의 기록이기 때문이다.프레임워크의 기본값은 "대부분의 상황에서 무난한" 값이지,"우리 상황에서 최적인" 값이 아니다. 운영하면서

이번 편은 "조회수 +1"이라는, 요구사항 한 줄짜리 기능이다.그런데 이 한 줄이 트랜잭션·비동기·백프레셔를 전부 소환했다. 그 과정을 남긴다.첫 구현은 누구나 떠올리는 그대로였다. 상세 조회 트랜잭션 안에서 UPDATE.동작한다. 그런데 곱씹을수록 이상했다.첫째, 조

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 쓰는 게 아니라, 모델이 내부적으로 어떻게 돌아가