꾸준하게

[Riot API] 비동기 전적조회 리팩토링으로 응답속도 개선하기 (2차)

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

TIMO.GG를 만들면서

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

🚨상황 발단 사이드 프로젝트로 진행 중인 Tim.gg 서비스가 있다. 기능 중에 라이엇 외부 API를 활용하는 부분이 있다. 이 기능의 목적은 최근 10개의 매치 정보를 가져와서 승/패 횟수를 파악하는 것이다. 팀원의 기존코드로 작성했을 때 HttpClient로 작성되었었다. 작동하는데에는 문제가 없었지만 무언가 읽기 힘들다는 느낌이 들었었다.보면 알겠지만 URL을 일일이 메서드 안에 정의해줘야 한다. 매번 반복되는 HttpRequest, HttpResponse도 코드의 양을 늘이는 주범이다. 코드의 또 하나 문제인 부분이 여기서 List으로 매치정보를 가져오고 있다. 그 후 일일이 동기 방식으로 MatchSummaryDTO에 저장하고 있다.10개의 정보를 하나씩 해결하니까 웹사이트에서 은근히 처..