(기존 프로젝트 설명) 기존에는 Open API를 활용해 동화 콘텐츠를 생성했습니다. 다만 기능 구현 위주였기 때문에 별도의 결제 시스템은 두지 않았는데,이번에는 동화 콘텐츠 생성을 위한 결제 시스템을 구축해보고자 합니다. 크레딧 기반으로 구성되며, 기본 크레딧을 제공하고 콘텐츠 생성 결과에 만족하면 추가 결제를 유도해 크레딧을 구매하는 방식으로 구현해보겠습니다. 1. 기본 구현 프로필을 활용하고 있기 때문에 프로필에 크레딧을 위한 필드를 추가하고, 책을 생성하는 BookService에서 크레딧이 충분하면 기존 로직대로 생성하고, 그렇지 않으면 예외 처리하는 로직을 추가로 구현하겠습니다. 또한 credit들의 잔액을 조회하고 충전을 위한 Credit을 위한 엔티티를 따로 생성을 해두겠습니다. 일단 ..
클로드 코드를 사용하면서 곳곳에서 모은 팁들을 한 곳에 모았습니다. 계속 배우는 내용이 생기면 업데이트할 예정입니다. 01. 초반 프로젝트 설정Tip 1. 실행 디렉토리를 좁게 잡아라Claude Code는 현재 디렉토리를 기준으로 파일을 탐색합니다. 필요한 최소 범위의 디렉토리에서 실행해야 불필요한 파일을 컨텍스트로 낭비하지 않습니다. Tip 2. /init으로 CLAUDE.md를 자동 생성하라/init 명령어를 치면 Claude가 프로젝트 구조를 직접 분석해서 CLAUDE.md를 만들어줍니다. 처음부터 손으로 작성하지 않아도 됩니다. Tip 3. CLAUDE.md는 직접 편집하지 말고 Claude에게 맡겨라작업 중 새로운 패턴이 생겼다면 Claude에게 이렇게 말하세요."방금 정한 패턴을 CLAUDE..
1. 문제 상황AI 배경음 생성 작업은 이미지 업로드 이후 감정 분석과 음악 생성을 거쳐 결과가 만들어지는 구조입니다. 초기에는 클라이언트가 주기적으로 서버에 요청을 보내 작업 상태를 확인하는 폴링 방식으로 구현되어 있었습니다.처리 시간이 짧을 때는 폴링만으로도 큰 문제가 없었습니다. 하지만 감정 분석 모델이 추가되고 AI 서버가 전환되면서 전체 추론 시간이 길어지자, 기존 방식의 한계가 드러나기 시작했습니다.2. 어디가 문제일까폴링 방식은 클라이언트가 스스로 "지금 완료됐나요?"를 반복해서 물어보는 구조입니다. 그런데 추론 시간이 길어지면서, 사용자가 메인 페이지에서 대기하는 동안 완료 이벤트를 실시간으로 전달받지 못하는 구조적 한계가 있다는 걸 확인했습니다. 폴링 간격을 짧게 줄이면 서버 부하가 늘어..
1. 먼저 프로젝트 설명부터 먼저 프로젝트의 메인 기능에 대해 간단히 설명드리겠습니다.프로젝트에서는 사용자가 이미지 3장을 업로드하면, 이미지에서 감정을 추출한 뒤 감정에 어울리는 AI 배경음을 3개 생성합니다. 이후 생성된 이미지와 배경음을 기반으로 인터랙션 형태의 전시회를 즐길 수 있도록 구성하였습니다. 다만 AI 배경음 생성에는 1개당 약 30초, 총 3개 생성 시 약 90초 정도의 시간이 소요되었습니다. 만약 이를 동기 방식으로 처리할 경우, 전시회 조회 및 사용자 인터랙션과 같은 다른 API 요청까지 지연될 가능성이 있다고 판단했습니다. 이에 따라 AI 추론 작업은 Celery 기반 비동기 구조로 분리하여 설계했습니다. 2. 어디가 문제일까?비동기 구조로 AI 추론 작업을 분리하면서 API 블..
1. 서론서비스에서 자주 조회되는 인기글 API의 응답 속도를 개선하고자, Spring Boot에서 제공하는 @Cacheable 어노테이션을 활용해 캐시를 빠르게 붙였습니다. 간단하게 붙이고 성능도 챙기자는 의도였고, 처음에는 실제로 응답 속도도 빨라지고, 서버 부담도 줄어드는 듯 보였습니다. 하지만 운영을 지속하면서 이상한 지점을 발견했습니다. JVM Heap 사용량이 점점 누적되는데도, Full GC 이후에도 메모리 사용량이 줄지 않는 현상이 반복되었고, 같은 시점에 TPS가 급격히 하락하고 응답 지연이 늘어나는 문제도 함께 나타났습니다. 처음에는 일시적인 부하인가 싶었지만, Scouter로 수치를 확인하고 나니 이건 단순한 GC 문제만은 아니구나를 생각했습니다. 관련해서 어떤 점 때문에 메모리..
1. 서론인기글 API의 성능 문제를 해결하기 위해, 먼저 쿼리 구조를 개선하고 적절한 인덱스를 적용하여 DB 부하를 줄이고 응답 속도를 개선했습니다. 하지만, 사용자 접근 빈도가 높은 인기글 페이지의 특성상, 여전히 반복적인 조회에 의한 DB 접근 비용이 부담으로 남아있었습니다.이번 글에서는 이를 해결하기 위해 적용한 캐싱 전략에 대해 다뤄보겠습니다. 캐싱이란 무엇인지, 왜 Redis를 선택했는지, 그리고 실제 적용 방식을 함께 살펴보겠습니다. 2. 데이터베이스는 왜 느릴까 우선 데이터 베이스의 종류를 간단히 살펴보면, [RDB 특정] - 안정성HDD 혹은 SSD같은 보조기억 장치에 데이터를 저장행과 열 구조의 정형 데이터 저장(엑셀처럼 생각하면 쉬움)SQL 언어로 데이터 조회 및 관리테이블 간 관계를..
