가챠 게임의 핵심은 "뽑기 버튼을 눌렀을 때 어떤 등급의 카드가 나오는가"를 결정하는 확률 엔진입니다. 단순히 Math.random()만으로는 해결되지 않는 설계 과제가 있었습니다:9개 등급(E~U)에 각각 다른 확률을 부여해야 한다확률 조정이 코드 수정 없이 데이터 변경만으로 가능해야 한다등급 결정 → 해당 등급에서 카드 선택의 2단계 로직이 필요하다풀에 해당 등급 카드가 없을 때 Fallback 처리가 필요하다1000분율 누적 확률 테이블퍼센트(%) 대신 1000분율을 선택했습니다. 이유는 소수점 없이 정수만으로 0.1% 단위의 정밀한 확률을 표현할 수 있기 때문입니다.private record RarityEntry(int ceiling, String rarity, int cpMin, int cpMa..

한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다. LLM이 답을 줬는데, 이 답이 왜 틀렸는지 설명할 수 있을까? 요즘 AI 기능을 붙이는 일은 예전보다 훨씬 쉬워졌습니다. API를 연결하고 문서를 검색해 답변에 넣으면 데모 화면은 금방 나옵니다. 몇 가지 질문을 던져 보고 그럴듯한 답이 돌아오면 일단 안심하게 됩니다. 그런데 운영에 들어가는 순간 질문이 달라집니다. 답변이 틀렸을 때 검색 결과가 문제인지, 프롬프트가 문제인지, 모델이 맥락을 놓친 건지 어디서부터 봐야 할까요? 백엔드 개발에서는 장애가 나면 로그와 지표를 따라 원인을 좁혀 갑니다. AI 기능 앞에서는 그 익숙한 감각이 자주 막힙니다. 요청은 성공했고 응답도 왔는데 내용만 틀릴 수 있기 때문입니다. 게다가 에이전트가 외..

가챠로 카드를 뽑는 것만으로는 유저가 카드에 애착을 가지기 어렵습니다. 뽑기 → 수집으로 끝나면 금방 지루해지죠. "이 카드를 키우고 싶다"는 동기 부여가 필요했고, 그래서 카드 강화(Enhance) 시스템을 도입했습니다. 설계할 때 가장 고민했던 포인트는 두 가지입니다:확률 설계: 무조건 성공이면 긴장감이 없고, 확률이 너무 낮으면 유저가 이탈한다.경제 밸런스: 골드 소모량이 레벨에 비례해야 하지만, 초반 유저가 부담 없이 시도할 수 있어야 한다. 강화 시스템의 핵심은 딱 두 줄의 공식입니다:// 강화 비용: 현재 레벨 × 100 골드int cost = card.getLevel() * 100;// 성공 확률: 레벨이 오를수록 10%씩 감소, 최소 10% 보장double successRate = Mat..

가챠(뽑기) 게임에서 가장 중요한 경험은 "카드를 획득하고 수집품을 감상하는 순간"입니다. 초기 프론트엔드 UI는 카드의 기본 정보만 단순히 텍스트로 나열하는 밋밋한 구조였습니다. 특히, 레이드 시스템과 피로도(스태미나/소진) 시스템이 추가되면서 카드의 상태를 직관적으로 유저에게 전달할 필요가 생겼습니다. React 컴포넌트(CardDetail, CardFaces, ActionSheet)를 재설계하여 정보의 밀도와 시각적 피드백을 강화했습니다.1. 카드 피로도(소진) 상태 시각화카드가 레이드에 참여하여 피로도가 소진되었을 때, 텍스트("소진됨")로만 표시하는 대신 흑백 처리나 게이지바를 도입했습니다.// CardFaces.jsx 내의 렌더링 로직 일부const isExhausted = card.isEx..

초기 기획 변경으로 인해 User 엔티티의 email, Card 엔티티의 isFavorite 등 더 이상 사용하지 않는 더미 컬럼들이 방치되어 있었습니다. 기술 부채(레거시)를 청산하기 위해 엔티티에서 해당 필드들을 삭제하고, schema.sql에서도 제거한 뒤 Render에 배포를 진행했습니다. 하지만 배포 후 서버가 500 에러를 뱉으며 뜨지 않는 크리티컬 이슈가 발생했습니다.로그(Log)를 확인해 본 결과, Spring Boot 구동 중 Context Load 단계에서 아래와 같은 예외가 쏟아졌습니다.Caused by: org.springframework.data.repository.query.QueryCreationException: Could not create query for public a..

가챠 게임에서 가장 중요한 지표 중 하나는 리텐션(재방문율)입니다. 유저들이 매일 접속할 명분을 제공하기 위해 두 가지 시스템을 기획했습니다.무료 뽑기 쿨타임: 스태미나가 다 떨어져도 일정 시간마다 주어지는 무료 기회오늘의 의뢰(Daily Bounty): 매일 새롭게 주어지는 미션 (예: '동물 테마 사진 3장 뽑기')이러한 시간 의존적(Time-dependent) 상태들을 데이터베이스에 어떻게 저장하고, 서버와 클라이언트 간의 시차 문제를 어떻게 해결할지가 중요한 아키텍처 과제였습니다.1. 무료 뽑기 (쿨타임 기반 충전 로직)스태미나가 소진된 상태(isExhausted)를 단순히 boolean으로 관리하지 않고, 만료 일시(exhaustedUntil) 필드를 사용했습니다.// User.javapriva..

초기 오늘가챠 시스템의 뽑기(Gacha) 로직은 단일 엔드포인트와 단일 비즈니스 로직으로 구현되어 있었습니다. 모든 카드를 동일한 확률로 뽑고, 고정된 재화(Stamina)를 소모하는 형태였습니다. 하지만 서비스가 고도화되면서 다음과 같은 기획 요구사항이 추가되었습니다:일반 배너 (Normal): 전체 풀에서 뽑기소셜 배너 (Social): 친구가 올린 사진 위주의 뽑기테마 배너 (Theme): 동물, 풍경, 음식 등 특정 테마 카드만 등장하는 한정 배너이 요구사항을 기존 CardService에 if-else나 switch 문으로 전부 쑤셔넣으면 코드가 매우 비대해지고, 새로운 배너가 추가될 때마다 핵심 도메인 로직을 수정해야 하는 문제(OCP 위배)가 예상되었습니다. 이러한 문제를 해결하기 위해 객체..