K-Buddy

개요

아이템 한줄 설명

방한 외국인의 한국 생활 정보 비대칭을 줄이기 위한 로컬 경험 플랫폼

K-Buddy는 한국을 방문하거나 체류하는 외국인이 겪는 정보 비대칭 문제를 해결하려고 기획된 창업팀 프로젝트다. 단순 관광 정보 제공에서 그치는 게 아니라, 한국 생활 정보, 커뮤니티, 멘토링까지 이어지는 플랫폼 구조를 목표로 삼았다.

초기 기획 단계에서 본 문제는 다음과 같았다.

그래서 K-Buddy는 장소 정보 자체보다도, 커뮤니티와 신뢰 가능한 생활 정보를 연결하는 쪽을 더 중요하게 봤다.

창업팀 초기 멤버로 참여해 다음 업무를 담당했다.

K-Buddy 메인 서버는 Spring Boot 기반으로 구성했다.

서비스가 커뮤니티, 인증, 북마크, 멘토링처럼 비교적 전형적인 비즈니스 도메인을 가지고 있었기 때문에 검증된 웹 백엔드 생태계가 필요했다. Spring Boot는 인증/인가, ORM, API 문서화, 팀 협업 측면에서 모두 안정적이었다.

장소/게시글/사용자 조건 검색이 섞이는 구조였기 때문에, 복잡한 조회가 늘어날 것이 어느 정도 예상됐다. 문자열 기반 JPQL보다 타입 안전성을 확보하고 싶어서 QueryDSL을 선택했다.

Google, Kakao 기반 소셜 로그인을 지원했고, refresh token 저장소로 Redis를 고려했다. 이 구조는 인증 상태를 DB 테이블만으로 처리하기보다, 만료·재발급 흐름을 더 빠르게 처리하기 위해 선택했다.

모바일 앱 팀과 백엔드 팀이 동시에 움직이는 상황에서, 메인 API가 완전히 안정화될 때까지 기다리면 프론트 개발이 멈춰 버린다. 그래서 별도 FastAPI 기반 Mocking Server를 두고,

하는 방향으로 운영했다. 이 결정 덕분에 백엔드 준비 전까지 프론트가 막히는 상황을 많이 줄일 수 있었다.

Oracle Cloud를 중심으로 컨테이너 기반 인프라를 구성했고, 서비스와 데이터 저장소를 분리해 운영했다.

Docker를 도입한 건 단순 배포 편의성과 개발 환경 <-> 운영 환경의 차이를 줄이기 위해서였다.

K-Buddy에서 의외로 중요했던 부분은 문서화였다.

창업팀 프로젝트는 팀원이 바뀌거나 역할이 넓게 섞이는 경우가 많다. 문서가 없으면 개발 속도보다 온보딩 비용이 더 커진다. K-Buddy에서는 이 부분을 초기에 정리해 둔 것이 실제 협업에 크게 도움이 됐다.