꾸준하게

캡스톤 디자인 우수상을 받게 되었습니다...! (ㅎㅇ이가 홍보를 야무지게 잘해주심) 티모지지는 정말 2024 겨울부터 기획하여 7월까지 진행한 프로젝트로 프론트 개발까지 하느라 고생이 많았습니다..(챗지피티가 올 해 초만 하더라도 정말 바보같았다..) 에타, 단톡방에 홍보도 하며 나름 유저를 40명까지 채워봤지만 서비스가 상용화 되기에는 한계가 있었네요.... 그래도 캡스톤디자인 프로젝트로 시작해서 기승전결이 좋았기에 우수상까지 받을수도 있었나 싶습니다. 거의 6월까지는 티모지지 서비스만 생각하고 살았던 것 같습니다. 이제 AWS 프리티어도 끝나기도 했고 비즈니스적 한계가 명확하기에 보내줘야 될 때인 것 같습니다. 열심히 기획하고 개발했던 티모지지.... ㅎㅇ, ㅅㅇ 모두 고생했다.. 2026년 1..

나르지지 서비스 : nar.kr 1달 전 디자이너 분과 프론트엔드 분을 모시게 되었습니다. 🙌혼자 상상하고 만든 서비스에 공감하고 합류하는 분들이 있다는게 좋았습니다. 기존에 많은 프로젝트를 해봤지만 이 프로젝트의 특별한 점이라면 '덕업일치'라고 표현 될 것 같습니다. 모두 롤을 좋아하고 특히 LCK보는 것에 관심이 있어서 자연스레 확장해 나갈 수 있는 원동력이 되는 것 같습니다. 개인 프로젝트에서 팀 프로젝트로 확장되면서 느낀점이 확실히 각자의 강점을 발휘할 수 있는 분야를 맡으니 더 효율적이고 견고해지는 것 같습니다. 매 주 점점 발전하는 서비스를 보면서 얼른 사용자가 많이 생겼으면 좋겠다는 상상을 합니다 ㅎㅎ2025년은 아이디어를 그려보는 시간이었다면 2026년은 실제 서비스로 거듭나서 프로 ..

배경 현재 진행중인 나르지지 서비스는 스케줄링으로 적재되는 데이터 이외에는 유저의 데이터가 들어갈 일이 없습니다.하지만 서비스를 확장하면서 몇 명이 조회했는지, 리뷰 등록과 같은 상황이 발생할 수 있습니다.이러한 상황에서는 현재 DB인 SQLite의 한계가 발생할 수 있기에 먼저 테스트 환경에서 측정해보고자 합니다. 내용기본적으로 SQLite도 MySQL과 같이 트랜잭션을 지원하지만 단위에서 차이가 있습니다.SQLite는 단일 파일기반으로 임베디드 형식이라 파일에 락이 걸리게 됩니다. 반면 MySQL은 Row Lock기반이기에 동시성 처리에서 처리량이 높다는 강점이 있습니다. 스레드 개수와 요청 수의 개수를 조절하면서 SQLite와 MySQL을 비교해보겠습니다. 가상 시나리오 : 특정 게시글에 대해 ..

상황 설명 개인 프로젝트인 NAR.GG 서비스 DB는 MySQL로 AWS RDS 설정을 하였습니다. 하지만 RDS 과금이 생각보다 많이 나갔습니다. 총 6만 원 가까이 지출하게 되었습니다..😱 위 상황에서 일단 RDS를 무조건적으로 없애야 됐습니다. (안그래도 용돈 받는 입장에서 6만 원씩 지출되는 건 타격이 크다.) 굳이 MySQL을 고집해야하나??RDS가 아니라면 EC2인스턴스에 Docker로 MySQL을 올리는 게 최선인 방법 같았습니다.그러면 안 그래도 1GB밖에 안 되는 스프링인스턴스에서 더 쪼개서 반반 사용해야 됐습니다.MySQL의 용량을 최대한 최적화하기 위해 튜닝을 해야 하나 생각도 들었습니다. 어떻게 해야 될지 정확히 확신이 안 서 개발자 커뮤니티에 제 상황을 적어서 의견을 구했습니다...

서문이전 DTO 프로젝션 적용 후, 응답 시간이 두 자릿수(ms) 수준으로 개선되어 사용자 경험 측면에서는 불편함이 거의 사라졌습니다.그러나 일정 서비스의 과거 게임 데이터는 불변성이라는 특성을 가지고 있기에, 캐시를 활용하여 더욱 최적화를 할 수 있다고 판단하였습니다.본문서비스 특성 고려하여 캐싱 전략 수립 LCK 일정 서비스 업데이트 주기가 6시간 간격으로 스케줄링을 통해 저장됩니다. 하지만 오늘 경기가 아직 진행중일 경우 절반만 업데이트되는 경우가 있을 수 있습니다. 이럴 경우를 대비해 총 5가지의 캐시로 분류하였습니다. 오늘 경기 일정오늘 경기 상세정보 과거 경기 일정과거 경기 상세정보 기록 페이지 오늘 경기 일정, 상세정보는 과거 데이터들과 다르게 스케줄링이 성공하면 @CacheEvict를 통..

문제 상황일정 서비스 로직은 단순한 조회 기능인데, 사용자가 체감할 정도의 응답 지연(약 750ms)이 발생하고 있었습니다. 접근스프링단 코드는 크게 이상이 없어 DEBUG 레벨 로그로 설정해보았습니다.API 조회 콜 1개당 수많은 쿼리문이 발생하였습니다. 바로 N+1문제였습니다. 원인ONE TO ONE 양방향 매핑 N+1 문제연관관계 주인 - game_player_stat반대 - game_participant GameParticipant 조인 시 GamePlayerStat도 EAGER 방식으로 가져오게 되어 문제 발생 자식 쪽에서는 부모 존재여부를 모르기 때문에 체크하게 되어 LAZY방식 작동안하게 됨해결책@OneToOne(optional = false) (DTO 프로젝션과 비교분석함)JOIN FE..

들어가며나르지지 서비스는 Riot에서 제공하는 대회 데이터 기반으로 분석 서비스를 제공하는 것을 목표로 합니다. 위와 같이 서버 단에서 데이터 수집 및 정제 후 DB에 저장하여 가공한 서비스를 제공하는 것이 목표입니다. 이를 위해 주기적으로 업데이트되는 Google Drive 파일을 우리 서비스에서도 똑같이 업데이트해야됩니다. 진행 사항 스케줄링 Google Drive 파일이 6시간 간격으로 업데이트 됩니다.@Scheduled(cron = "0 30 4,10,16,22 * * ?", zone = "Asia/Seoul") 이에 맞춰 저희 서비스에서도 6시간 간격으로 스케줄링을 설정하였습니다. Data Ingestion DataIngestionFacade배치처리에 있어서 가장 중심이 되는 Class입니..

들어가며- 롤 e-스포츠 데이터를 다루는 개인 프로젝트 ‘NAR’에서 “챔피언 조합 통계(Combination)” API를 만들었습니다.- 첫 구현은 메모리 중심 설계로 하였습니다. DB에서 GameParticipant 전부를 읽어 와 자바 컬렉션으로 그룹핑, 집계, 정렬, 페이징까지 처리하는 방식입니다. 문제상황서비스 운영 중, java.lang.OutOfMemoryError: Java heap space 에러가 터짐. 로그를 확인해보니 챔피언 조합 통계 API가 반복적으로 호출됨. 운영 환경 인스턴스: AWS EC2 t3.micro (vCPU: 2, Memory: 1GB)JVM 옵션 : -Xmx512m 성능 테스트 (기존 코드)정확한 진단을 위해 VisualVM 모니터링 툴을 이용하여로컬에서 운영..

1차 리팩토링: 구조 개선 + 비동기 전환(1차 리팩토링 글 : https://changha-dev.tistory.com/188 )처음 진행한 리팩토링에서는 다음과 같은 개선을 통해 구조적 안정성과 기본적인 성능 향상을 도모했습니다:외부 API URL 하드코딩 문제 → HttpInterface와 RestClient 기반으로 추상화하여 가독성과 유지보수성 향상전적 조회 10건을 순차적으로 호출하던 방식 → CompletableFuture와 ThreadPool을 활용한 비동기 처리 방식으로 전환이 과정을 통해 기존 평균 2~3초 걸리던 요청을 1초 미만으로 단축하는 데 성공했습니다. 그러나... 성능은 아직 충분하지 않았다비동기 구조로 전환한 이후, 내부 처리 시간 자체는 약 500ms 수준으로 빨라졌지만실..

작년 12월부터 지금까지, 내 머릿속 절반은 TIMO.GG로 가득 차 있었다고 해도 과언이 아닌 것 같다..작년 디자이너분이 만들어주신 귀엽고 정감 가는 로고와 캐릭터 덕분에, 이 프로젝트에 더 큰 애정을 갖게 된 것 같다. 대학 생활 중 정말 다양한 프로젝트를 해봤지만, 실제 서비스로 운영까지 간 적은 없었다. (대부분 비즈니스 모델의 한계 때문이었다)그래서 이번에는 ‘우리가 좋아하고 직접 써볼 수 있는 서비스’를 만들고, 끝까지 운영까지 해보자는 목표를 세웠다. 이 프로젝트를 진행하며 가장 집중한 부분은 무엇이었을까?사용자 중심적 사고 회원가입 플로우 단순화기본 닉네임 자동생성티모대위-a12b42(랜덤UUID 활용)오직 OAuth 로그인 통한 비밀번호 미사용→ 유저가 빠르게 서비스를 경험하는 것이..