Skip to content
Jiho Jeong edited this page Dec 3, 2024 · 19 revisions

기술적인 경험

마이페이지에서의 경험

391472679-b9586287-5df2-46f8-8816-5e92c1da4709

저희 프로젝트는 베팅으로 얻은 코인으로 Three.js를 활용하여 사용자가 오리를 구매할 수 있는 기능을 구현하였습니다. 개발 과정에서 우리가 직면했던 주요 문제는 3D 모델링 파일(.glb)과 환경 맵핑 파일(.hdr)을 서버에 배포하는 과정이었습니다.

이 문제의 구체적인 원인은 Vite가 기본적으로 이러한 3D 에셋 파일들을 처리하는 방식에 있었습니다. 우리는 Vite의 설정을 수정하여 이 문제를 해결할 수 있었습니다. 문제 해결 과정과 상세한 설정 방법은 아래 링크에서 확인하실 수 있습니다


로그인페이지와 투표 생성 페이지에서의 경험

391462264-47ad7487-cf49-4661-bf2f-252083bf2788

[FE] 반복적으로 요청하는 인증 요청의 횟수 줄이기

프로젝트의 모든 페이지에서 사용자 인증이 필요했기 때문에, 페이지 전환마다 서버로 동일한 인증 요청이 반복적으로 발생하는 성능 문제가 있었습니다. 이를 해결하기 위해 Tanstack Query의 명령적 캐싱 전략을 도입했습니다. 사용자의 상태가 변경되지 않은 경우에는 캐시된 데이터를 재사용하고, 상태 변경이 필요한 경우에만 캐시를 무효화하고 새로운 데이터를 요청하는 방식으로 불필요한 네트워크 요청을 최소화할 수 있었습니다.

[FE] 사용자 피드백을 반영한 타이머 설정 개선

초기 타이머 설정이 1분씩 올릴 수 있게 되어 있었는데, 사용자 편의성이 낮다는 피드백을 받았습니다. 이러한 피드백을 반영하여 보다 직관적이고 효율적인 방식으로 개선하였습니다.

setTimeoutsetInterval을 활용해 버튼을 꾹 누르고 있을 경우에 타이머 값이 자동으로 빠르게 증가하거나 감소하도록 구현하였습니다. 이를 통해 단순히 버튼을 여러 번 클릭해야 했던 불편함을 제거하고 연속적인 동작으로 자연스러운 사용자 경험을 제공합니다.

베팅 생성 페이지는 사용자가 직접 제목, 케이스1, 케이스2, 타이머, 최소 금액을 설정할 수 있도록 구성되었습니다.
다양한 입력 폼이 존재하기 때문에 상태 관리와 렌더링 최적화를 통해 입력 과정에서의 성능 저하를 최소화하였습니다.
또한, 유효성 검증을 적용하여 유효한 입력 값만 제출될 수 있도록 구현함으로써 잘못된 데이터가 서버로 전달되지 않도록 방지했습니다.
이러한 설계를 통해 FE와 BE 간 안전하고 신뢰성 있는 데이터 통신을 보장합니다.


소켓을 활용하여 투표 창을 만들며 겪은 경험

391462948-cd66e73b-4fbe-47b8-9a02-e331bd0d6166

[FE] 잘못된 소켓 연결 관리로 인한 서버 다운

CSR(Client-Side Rendering) 방식의 프로젝트에서 소켓 연결을 useEffect로 관리했지만, 클린업 함수에서 소켓 연결이 제대로 종료되지 않아 불필요한 연결이 계속 유지되는 문제가 발생했습니다. 이로 인해 컴포넌트 언마운트나 의존성 배열 변경 시 기존 소켓 연결이 누적되어 메모리 누수와 서버 리소스 낭비로 이어졌습니다. 문제를 해결하기 위해 useEffect의 클린업 함수 작동 원리, 비동기 작업 처리 시 클린업 구현 방법, 상태 초기화를 확실히 보장하는 방법을 학습하고 적용하여 소켓 연결 관리 문제를 해결했습니다.

[BE] 레디스 메모리 설정 최적화

스크린샷 2024-12-03 오후 4 21 07

이전까지 Redis의 maxmemory와 maxmemory-policy 설정을 따로 해두지 않았습니다. 그러다 보니, 위의 비정상 소켓 이벤트에 대처할 수 없었고, Redis 메모리 관리 실패로 인해 OOM 문제가 발생했습니다.

해당 에러를 겪으며, Redis의 메모리 최적화 방법을 고민했습니다. max-memory, max-memory-policy 설정하고, ziplist를 활용해 연속된 메모리 구조로 데이터 저장 효율을 높였습니다.

[BE] 실시간 베팅 처리를 하며 겪은 경험

화면 기록 2024-12-02 오후 4 38 34

실시간 베팅 처리에서 Redis와 HINCRBY 명령어를 활용해 동시성 문제를 해결했습니다. Redis의 단일 스레드 기반 특성과 HINCRBY의 원자성을 활용해 데이터 업데이트 과정에서 발생할 수 있는 불일치를 방지했습니다. 이를 검증하기 위해 100만 번의 동시 요청을 처리하는 테스트를 진행하며 안정성을 확인했습니다.

[BE] 다양한 캐시 전략 적용

시스템 성능 최적화와 데이터 일관성 유지의 균형을 위해 다양한 캐시 전략을 설계하고 구현했습니다.

베팅 데이터 저장에는 Write Through를 적용해 데이터 정합성을 유지했으며, 실시간 베팅 정보 관리에는 Write Back을 활용해 쓰기 부하를 줄이면서 실시간성을 보장했습니다.


결과 정산 페이지에서 겪은 경험

결과 페이지

[BE] 베팅 종료 API 최적화

베팅이 종료될 때, 호출하는 API의 응답 시간이 너무 오래(약 1400ms) 걸린다는 문제가 있었습니다.

메시지 큐와 Redis의 Set을 사용하여 해당 API에 대한 최적화를 진행하였습니다.

결과적으로 API 응답 시간을 300ms대로 개선하였습니다.

베팅 종료 API 개선하기

🏠 𝐇𝐨𝐦𝐞

🙌 𝐈𝐧𝐭𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧

📄 𝐏𝐫𝐨𝐣𝐞𝐜𝐭 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧

🤝 𝐓𝐞𝐚𝐦 𝐑𝐮𝐥𝐞𝐬

🎁 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐒𝐡𝐚𝐫𝐢𝐧𝐠

프로젝트 초기 세팅

메인 페이지

로그인/회원가입/게스트 로그인

베팅페이지

BE

FE

🔫 𝐓𝐫𝐨𝐮𝐛𝐥𝐞𝐬𝐡𝐨𝐨𝐭𝐢𝐧𝐠

📎 𝐑𝐞𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐋𝐢𝐧𝐤𝐬

Clone this wiki locally