지난 글에서 프론트엔드가 3초마다 “새 메시지 있어?”라고 물어보는(polling) 구조를 소개했다. 이제 백엔드가 답할 차례다. “3초마다 요청이 들어온다고? 서버 DB 괜찮아?” 나도 이 부분이 가장 걱정이었다. 앱 사용자가 1,000명만 되어도 단순히 계산하면 초당 수백 건의 조회가 발생한다. 그래서 백엔드 설계의 핵심은 “최대한 빠르고 가볍게 응답하기”였다. 오늘은 Spring Boot와 JPA를 사용해 무거운 소켓 대신 가벼운 조회 API로 채팅을 처리한 경험을 공유한다. 1. … 더 읽기
채팅 기능을 만든다고 하면 다들 관성적으로 WebSocket이나 Socket.io를 떠올린다. 나 역시 그랬다. “채팅 = 소켓”은 공식이니까. 하지만 이번 프로젝트에서는 소켓이 아닌 3초 간격의 API 폴링(Short Polling) 방식을 선택했다. “구식 아니냐”, “서버 부하 괜찮냐”는 걱정이 생길 수 있다. 하지만 MVP(Minimum Viable Product) 단계에서 제한된 시간과 비용을 고려했을 때, 이것만큼 합리적인 선택은 없었다. 오늘은 왜 소켓을 버렸는지, 그리고 플러터에서 어떻게 3초 폴링을 효율적으로 구현했는지 정리해본다. … 더 읽기
지난 글에서 플러터 앱에서 토큰을 발급받아 서버로 던지는 것까지 처리했다. 이제 백엔드(Spring Boot)가 바통을 이어받을 차례다. “그냥 라이브러리 쓰고 매세지 보내면 끝 아닌가?” 라고 생각했지만, 막상 해보니 채팅 알림과 일반 알림을 구분해야 하고, 유저가 알림을 껐는지 체크하는 등 신경 쓸 로직이 꽤 있었다. 오늘은 FCM 초기화부터 실제 전송, 그리고 알림 설정 처리까지의 과정을 정리해본다. 1. Firebase 초기화 … 더 읽기
이번 프로젝트에서 유사 채팅 기능을 구현하면서 푸시 알림(FCM)은 피할 수 없는 산이었다. 보통 개발 블로그들을 보면 프론트와 백엔드가 섞여 있어서 막상 적용하려니 헷갈리는 경우가 많았다. 그래서 이번 구현 과정은 앱(Frontend)과 서버(Backend) 설정으로 나누어 정리해두려 한다. 오늘은 그 첫 번째, 플러터 앱에서의 설정과 토큰 관리 이야기다. 1. 상황 채팅 앱인데 알림이 안 오면 시체다. 단순히 “구글링해서 나온 코드 복붙”으로 끝날 … 더 읽기
이전 글에서 Flutter로 매칭 화면을 그리는 법을 다뤘다. 이번에는 그 화면 뒤에서 실제로 데이터를 굴리는 **백엔드(Spring Boot)**구현 과정을 정리해본다. 모바일 개발자 입장에서 백엔드를 하다 보면 가장 신경 쓰이는 게 “이 데이터를 믿을 수 있는가?”다. 앱은 끄면 날아가지만, DB에 박힌 데이터는 영원하니까. 1. 매칭 리스트 “서울 강남구에서”, “이번 주말 오후에”, “복식 게임을”, “NTRP 3.0 이상만” 찾고 … 더 읽기
지난 글에서 사용자 프로필을 입력받아 유저를 준비시켰다. 이제 이 사람들이 실제로 만나서 테니스를 칠 수 있게 ‘매칭(Match)’ 시스템을 만들어야 한다. Tennis GG 서비스의 핵심 기능이자, 가장 복잡한 비즈니스 로직이 들어가는 부분이다. 내용이 길어서 (1) 모바일 프론트엔드와 (2) 백엔드 편으로 나누어 정리한다. 오늘은 Flutter로 구현한 화면과 상태 관리 이야기다. 주요 포인트 매칭 시스템은 단순히 “글 쓰고 읽기”가 아니다. 이 복잡한 … 더 읽기
지난 글에서 소셜 로그인으로 사용자 인증까지 마쳤다. 하지만 우리 서비스(Tennis GG)에 필요한 건 ‘이메일’ 하나가 아니다. 테니스 실력(NTRP), 구력, 닉네임… 받아야 할 게 몇가지가 있다. 로그인 직후, 사용자를 붙잡아두고 자연스럽게 정보를 입력받는 과정(Onboarding Flow)을 어떻게 구현했는지 정리해본다. 먼저, 완성된 화면부터 보여드리겠습니다. 왜 이 글을 쓰게 되었는지 처음엔 그냥 긴 Form 하나 던져주고 “입력하세요” 할까 했다. 근데 나부터가 … 더 읽기
지난 백엔드 편에 이어, 이번에는 Flutter 앱 클라이언트에서 소셜 로그인을 붙이는 과정을 정리한다. 백엔드에서 아무리 잘 받아줘도, 클라이언트에서 토큰을 못 던져주면 말짱 도루묵이니까. 일단 결과물부터 보여드리면, 화면은 이런식으로 만들었고, 카톡 로그인 성공 시, 데이터 베이스에는 오른쪽과 같이 암호화된 임시 계정이 저장되었다. 왜 이 글을 쓰게 되었는지 소셜 로그인 라이브러리 kakao_flutter_sdk랑 sign_in_with_apple 가져다 쓰면 끝 아닌가? 싶었다. 그런데 막상 해보니 “카카오톡 … 더 읽기
이번에는 소셜[카카오(Kakao)와 애플(Apple)] 로그인을 실제로 구현하면서 겪은 과정들을 정리해본다. 왜 이 글을 쓰게 되었는지 사실 카카오 로그인만 붙이면 참 편했을 거다. 한국에서는 국민 앱이니까. 하지만 Apple App Store 심사 지침(Guideline 4.8)이 발목을 잡았다. 타사 소셜 로그인(구글, 카카오 등)을 쓰려면 반드시 ‘Sign in with Apple’도 같이 넣어야 한다는 조항 때문이다. 결국 울며 겨자 먹기로 두 가지를 다 구현하게 되었는데, … 더 읽기
테니스 매칭 서비스인 ‘Tennis GG’의 백엔드 초기 구성을 잡으면서 고민했던 내용들을 정리해본다. 특히 회원 관리 부분에서 일반 이메일 가입과 소셜 로그인을 어떻게 깔끔하게 합칠지가 주된 고민이었다. 왜 이 글을 쓰게 되었는지 이번 프로젝트에서는 Java 21과 Spring Boot 최신 버전을 도입하면서, 인증 구조를 어떻게 가져갈지 결정해야 했다. 혼자 개발하다 보니 놓치기 쉬운 보안 이슈(JWT 관리 등)도 … 더 읽기