2달간의 몰입, 업비트 클론 프로젝트 'Heartbit' 제작기
IT 교육 플랫폼 구름(goorm)에서 진행한 2달간의 프로젝트가 지난 2월 말 대단원의 막을 내렸습니다. 학교를 다니며 내세울 만한 프로젝트가 없었던 저에게 이번 경험은 단순한 개발 그 이상이었는데요. 그 기록을 짧게 정리해 보고자 합니다.
도메인 선정: "가짜를 만들더라도, 완벽하게 만들자"
프로젝트 기획 단계에서 이커머스, 엔터테인먼트 등 수많은 선택지가 있었습니다. 하지만 우리 팀의 목표는 명확했습니다. "가짜를 만들더라도, 진짜처럼 동작하는 완벽한 서비스를 만들자."
이런 관점에서 보았을 때, 기술적 난이도가 높고 실시간 처리가 필수적인 거래소 도메인은 거부할 수 없는 매력적인 선택지였습니다. 그렇게 우리는 국내 최대 암호화폐 거래소인 Upbit를 모티브로 한 서비스, Heartbit을 기획하게 되었습니다. (이름처럼 시세 변동에 요동치는 사용자의 심장 박동을 담았습니다.)
도메인을 선정하자마자 바로 떠올랐던 부분이 백엔드로서 내가 이 프로젝트에서 어떤 역할을 맡을까였습니다.
나의 역할: 실시간 데이터 처리의 핵심을 맡다
저는 이번 프로젝트에서 '실시간 데이터 처리' 파트를 담당했습니다. 서비스의 핵심 흐름은 다음과 같습니다.
사용자 주문 → 체결 엔진(Matching Engine) → 결과 가공 → 실시간 클라이언트 전송
그중 저는 체결 엔진에서 쏟아지는 결과 데이터를 가공하여 수많은 사용자에게 지연 없이 전달하는 역할을 맡았습니다. 평소 대규모 트래픽 처리와 실시간 데이터 전송에 대한 갈증이 있었기에, 배울 것이 많을 것이라 확신하며 선택했습니다.
고민의 시작: "모든 곳에 실시간 데이터가 있다"
ERD 설계와 MVP 기획을 진행하며 깨달은 점은, 거래소 도메인에서 실시간 데이터가 쓰이지 않는 곳은 단 한 군데도 없다는 사실이었습니다.
- 사용자 간 체결에 의해 실시간으로 변하는 현재가
- 현재가에 연동되어 매초 바뀌는 전일 대비 변동액/변동률
- 체결 결과에 따라 실시간으로 반영되어야 하는 개인 자산 현황
이 모든 변화를 매번 DB I/O로 처리한다면 시스템에 엄청난 부하가 올 것이 자명했습니다. "어떻게 하면 DB 부하를 줄이면서 사용자에게 즉각적인 정보를 전달할 수 있을까?"라는 고민이 시작되었습니다.
기술적 해결책: WebSocket과 Redis의 도입
고민 끝에 저는 두 가지 핵심 기술을 도입하여 문제를 해결했습니다.
- WebSocket: HTTP의 단방향 통신 한계를 극복하고, 서버가 클라이언트에게 즉각적으로 데이터를 밀어줄 수 있는(Server Push) 환경을 구축했습니다.
- Redis: 빈번하게 발생하는 실시간 데이터를 인메모리 DB인 Redis에 캐싱하여 조회 성능을 극대화하고, 필요한 시점에만 RDB에 기록하는 방식으로 DB 부하를 획기적으로 줄였습니다.
처음 시작할 때는 도메인 지식의 깊이와 기술적 난이도 때문에 걱정이 앞섰던 것도 사실입니다. 하지만 2달이 지난 지금, 그때의 힘듦이 저를 한 단계 더 성장시켰음을 느낍니다.
막막했던 실시간 데이터 처리를 직접 설계하고 구현하며 얻은 인사이트는 그 무엇과도 바꿀 수 없는 소중한 자산이 되었습니다. 이어지는 포스팅에서는 구체적으로 WebSocket과 Redis를 어떻게 설정하고 활용했는지 기술적인 내용을 깊이 있게 다뤄보겠습니다.