[2025 SUMMER DEV] 별자리를 사랑하는 사람들을 위한 스팟 공유 & 모임 커뮤니티 플랫폼 ‘Starlight’, ST4R팀

프로젝트 소개

ST4R 대표사진

은서: 안녕하세요. Starlight 서비스를 개발한 ST4R팀입니다.

요즘 SNS를 보면 도심을 벗어나 자연 속에서 별을 보려는 사람들이 많아졌다는 걸 알 수 있습니다. 낭만 있는 데이트 코스로도 인기를 끌고 있고, 저희 학교에는 별 관측 동아리도 있을 만큼 별과 관련된 취미생활의 수요가 늘어나고 있습니다. 저도 별 보는 것을 정말 좋아하는데요! 조용한 곳에서 밤하늘을 바라보고 있으면 마음이 편해지더라고요 ㅎㅎ

하지만 막상 별을 보러 가려 하면 숨은 관측 명소를 찾기가 쉽지 않았어요.

또 장비가 없어서 제대로 관측하기 어려운 점이 아쉽더라고요ㅜ
그래서 저희는 이런 고민을 해결해 줄 서비스, Starlight를 기획하게 되었습니다!

Starlight는

  • 함께 별 보러 갈 사람을 찾고 싶은 사람,
  • 관측 꿀팁을 얻고, 관측 장비를 빌리고 싶은 사람,
  • 숨겨진 별 관측 명소를 알고 싶은 사람들을

한 곳에 연결해주는 별자리 관측 동행 플랫폼입니다.

ST4R 기능 소개 사진
주요기능은 다음과 같습니다.

  • 게시판 기능
    사용자들끼리 자유롭게 정보를 공유할 수 있습니다.
    사진이나 지도를 통해 관측 스팟을 소개하거나, 별 관측 팁을 나누는 공간으로 활용됩니다.
    장비 대여에 대한 정보도 이곳에서 확인할 수 있어요!

  • 모임 모집 기능
    별 보러 갈 사람들과 함께할 수 있는 모임을 만들고 참여할 수 있습니다.
    단순한 모임 개설이 아니라, 실시간 채팅 기능을 통해 참여자들끼리
    소통하며 유대감을 쌓고 지속적인 만남으로 이어질 수 있도록 설계했습니다.

추후 기능으로는 유저들이 매일매일 소소한 즐거움을 줄 수 있도록
별자리 운세 보기 기능을 추가할 계획입니다!

Starlight가, 저처럼 별을 좋아하는 사람들에게
작은 설렘과 연결의 기회를 줄 수 있었으면 좋겠습니다. ✨

팀원 소개

ST4R 팀 사진

기술 스택

ST4R 기술 스택 사진1
ST4R 기술 스택 사진2

인터뷰

Q. 프로젝트를 하면서 어떤 문제를 겪었나요?

성준: 저는 프로젝트를 진행하면서 카카오 지도를 여러 페이지에서 사용하는 구조를 구현하였는데요, 직접 테스트를 하던 중 지도가 회색 박스로만 나타나거나 “kakao is not defined”라는 에러가 발생하는 문제를 발견했습니다. 새로고침을 하면 정상적으로 로드되지만, 첫 진입 시에는 지도가 제대로 표시되지 않는 현상이 반복적으로 나타났습니다.

문제를 분석해본 결과, 카카오 맵 스크립트가 완전히 로드되기 전에 지도를 초기화하려다 보니 오류가 발생하고 있던 것이었습니다. 특히 네트워크 속도가 느린 환경에서는 이 현상이 더욱 자주 발생했습니다. 이러한 문제를 해결하기 위해, 카카오 지도 스크립트의 로딩 상태를 전역에서 관리하는 구조를 새롭게 설계하게 되었습니다.

구체적으로는, 첫 번째로 지도를 사용하는 컴포넌트에서만 스크립트를 로드하고, 이후의 컴포넌트들은 이 스크립트가 완전히 로드될 때까지 기다렸다가 지도를 초기화하도록 구성하였습니다. 이 과정에서는 promise 패턴을 활용해 중복 로딩을 방지하고, 비동기 로딩 타이밍을 안정적으로 제어할 수 있도록 하였습니다.

이 경험을 통해 외부 라이브러리를 사용할 때 단순히 불러오는 것을 넘어서, 로딩 타이밍과 전역 상태를 어떻게 관리할 것인지에 대한 설계가 매우 중요하다는 것을 배웠습니다. 특히 사용자 환경이 모두 동일하지 않다는 점에서, 다양한 상황에서도 안정적으로 작동할 수 있는 초기화 구조를 고민하고 직접 구현해볼 수 있었던 값진 경험이었습니다.


Q. 프로젝트를 하기 전 후 달라진 점이 있다면?

수랑: 프로젝트를 진행하면서 가장 크게 배운 점은 뭐든지 괜히 복잡하게 만들지 말자는 것이었습니다. 이전에는 새로운 기술을 배우는 게 재미있어서 ‘나중에 필요할 수도 있지 않을까?’라는 생각으로 미리미리 기능을 만들어두는 습관이 있었습니다.

예를 들어서 이번에 채팅 기능을 만들 때도 처음에는 성능이 중요하다고 생각해서 Redis에 임시로 데이터를 저장하고 10분마다 MySQL에 저장하는 방식을 생각했었습니다. 그런데 생각해보니까 이게 저희 프로젝트를 괜히 복잡하게만 만드는 것이였습니다.

저희 프로젝트는 아직 개발 단계였고 MVP 만드는 것이 목표였는데, 당장은 저희 학교 사람들을 대상으로 하고, 수강신청처럼 한 번에 사람들이 몰릴 일도 없는 작은 프로젝트였습니다. 그래서 굳이 Redis까지 써가면서 복잡하게 만들 이유가 없었습니다.

이런 경험을 하면서 YAGNI(You Ain’t Gonna Need It) 원칙의 중요성을 느끼게 되었습니다. 미래를 너무 걱정하지 말고 지금 당장 필요한 것만 집중해서 만드는 게 훨씬 좋다는 걸 깨달았고, 이제는 개발할 때마다 ‘이 기능이 정말 지금 필요한가?’, ‘더 간단하면서도 효과적인 방법은 없을까?’라는 질문을 스스로에게 던지는 습관이 생겼습니다.


Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

은서: 개발하다 보면 분명 막히는 순간들이 생기는데요, 그럴 땐 꼭 팀원들과 함께 이야기하면서 해결해 나가는 것을 추천해요! 저는 이번 프로젝트를 하면서 팀원들에게 많은 도움을 받았는데, 그 과정에서 스스로 깨달은 것들이 정말 값졌던 것 같아요. 혼자 고민할 때보다 함께 이야기 나누는 게 훨씬 빠르고, 그만큼 팀 전체가 함께 성장할 수 있는 기회가 되더라고요.

그리고 혹시 개발이 처음이라면, 두려워하지 말고 마음껏 도전해보셨으면 해요! 저도 이번 에코노 프로젝트가 프론트엔드 개발자로서의 첫 도전이었어요. 리액트를 공부하면서 동시에 개발을 진행하다 보니 속도도 느리고, 실력이 부족하다는 생각에 스스로 비교하게 되기도 했어요. 하지만 생각해보면, 모두에게 처음은 있었을 거예요. 무조건 잘해야 한다는 부담보다는, 즐거운 마음으로 시작해보세요. 처음엔 어려워 보여도, 결국 어떻게든 만들어지더라고요 ㅎㅎ

그러니 자신을 믿고 한 번 부딪혀 보는 건 어떨까요?


Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

수랑: 프로젝트를 진행하면서 가장 큰 어려움은 프로젝트 초기 설정 단계였습니다. Spring 프로젝트의 build.gradle에서 의존성 버전을 설정할 때 최신 버전이 좋을 것이라고 생각하여 모든 의존성을 최신으로 설정했는데, 이것이 문제의 시작이었습니다. 빌드는 계속 실패하였고, 최신 버전이다 보니 문서화도 충분하지 않았으며, 몇몇 메서드들은 deprecated로 표시되어 있었습니다. 심지어 최신 버전임에도 불구하고 보안 취약점이 있다고 경고가 나오는 라이브러리도 있었습니다. 처음에는 간단할 것 같았지만 막상 해보니 가장 골치 아픈 부분이 바로 이 부분이었습니다. 이 문제를 GPT나 Gemini에게 물어보고 구글링을 통해 정보를 수집하면서 버전을 다양하게 변경해가며 gradle clean build를 계속 해보니 어찌저찌 해결이 되었습니다. 이를 통해 무작정 라이브러리를 최신 버전을 사용하는 것보다는 많은 개발자들이 사용하고 있는 검증된 버전이나 그보다 약간 최신인 안정적인 버전을 선택하는 것이 개발 하는데에 수월하다는 교훈을 얻었습니다.


Q. 프로젝트의 기술적인 도전 과제나 혁신적인 부분은 무엇이었나요?

은서: 저희 프로젝트에서 가장 기술적으로 도전이 되었던 부분은 WebSocket을 활용한 실시간 채팅 기능 구현이었습니다. WebSocket + STOMP 프로토콜을 사용하여, 클라이언트와 서버 간의 실시간 양방향 통신이 가능한 구조를 구현했습니다.

처음에는 WebSocket의 동작 원리나 구조를 이해하는 것부터 시작하였습니다. 그 후 React 환경에서 소켓 연결을 안정적으로 유지하고, 메시지를 실시간으로 처리하는 로직을 구현하는 데 많은 시간을 들였습니다.

로직을 간단하게 설명해보면 사용자가 특정 모임에 참가하면, 해당 모임 ID를 기반으로 채널을 구독하게 됩니다. 이후 해당 채널에 접속한 사용자들은 실시간으로 메시지를 주고받을 수 있게 됩니다.

이때 서버로부터 두 가지 type의 메시지를 받게 되는데요

- general 타입: 사용자가 보낸 메세지로 분류하고 메세지를 채팅 화면에 띄어 줍니다.
- updateReadTime 타입: 특정 사용자의 최근 읽은 시간을 갱신해 줍니다. 여기서 갱신된 읽은 시간과 각 메시지의 발송 시간을 비교하여, 해당 메시지를 몇 명의 사람들이 채팅을 읽었는지 계산할 수 있게 됩니다. 즉, 실시간 읽음 여부를 구현하기 위한 기반 데이터로 활용됩니다.

읽은 시간을 갱신하는 조건은

  1. 사용자가 처음 채팅방에 들어갈 때
  2. 사용자가 general 타입의 메세지를 받았을 때

이 두 경우를 “해당 사용자가 채팅을 읽었다”고 간주하고, 서버에 읽음 요청을 보내 사용자의 최근 읽음 시간을 갱신하도록 구현했습니다.

또 채팅 내역을 무한 스크롤로 불러오는 것도 도전 과제 중 하나였습니다. 채팅은 위로 스크롤 하여 과거 메세지를 보기 때문에 역순으로 구현해야 했습니다. React Query의 useInfiniteQuery 훅을 사용하여 메시지를 페이지 단위로 불러왔고, 이를 역순으로 정렬하여 구현하였습니다.

특히 React에서는 WebSocket 연결을 컴포넌트 생명주기에 맞춰 관리해야 했기 때문에 처음부터 전체 흐름을 설계하는 데 어려움을 느꼈습니다. 중간중간 에러가 날 때마다 원인을 찾아가면서 문제를 해결해 나갔고 이 과정에서 많은 시행착오를 거친 것 같습니다.

이 모든 과정을 통해 단순한 API 호출을 넘어, 실시간성과 상태 관리의 복잡함을 직접 경험하고 해결해 본 것이 어려웠지만 저에게는 큰 도전이자 성장이었습니다.
또한 이 기능 덕분에 사용자들이 모임 안에서 자유롭게 소통할 수 있어 플랫폼의 완성도와 사용자 경험을 높이는 데 크게 기여했다고 생각합니다.


Q. 개발자로서의 역량 향상을 위해 어떤 노력을 기울였으며, 이 프로젝트를 통해 어떤 기술적 성장을 이루었나요?

성준: 프로젝트를 하면서 가장 크게 느낀 점은 단순한 기능 구현보다 구조화와 유지보수가 훨씬 중요하다는 것이었습니다. 초반에는 게시글 컴포넌트 하나에 인증 확인, API 호출, 좋아요 처리, 댓글 관리, 이미지 뷰어 등 다양한 기능을 모두 넣다 보니 컴포넌트가 수백 줄이 넘어가는 거대한 구조가 되어버렸습니다. 당시에는 빠르게 기능을 구현하는 데에만 집중했기 때문에, 코드가 점점 복잡해지는 것을 실감하지 못했는데요, 어느 순간부터 작은 수정에도 다른 기능에 영향을 주는 일이 반복되면서 비효율을 크게 체감하게 되었습니다.

이러한 문제를 해결하기 위해 리팩터링을 시작했고, 기능 단위로 커스텀 훅을 분리하는 방식으로 구조 개선을 시도했습니다. 예를 들어, 인증 관련 로직은 useBoardDetailAuth, 댓글 처리 로직은 useBoardDetailComments로 분리하여 역할을 명확히 나누고, 코드의 응집도를 높이는 동시에 결합도를 낮추는 구조를 만들어나갔습니다. 이를 통해 코드의 가독성과 테스트 용이성은 물론, 유지보수성도 큰 폭으로 향상되었습니다.

또한 사용자 경험(UX) 측면에서도 많은 고민을 하게 되었는데요, 대표적으로는 낙관적 업데이트(Optimistic UI)를 도입하여 좋아요 버튼 클릭 시 서버 응답을 기다리지 않고 UI를 먼저 반영하게 하였습니다. 이후 서버 요청이 실패할 경우에는 다시 원래 상태로 복원하는 방식으로 안정성을 유지하였고요.

추가로, 스마트 캐싱을 적용하여 한 번 조회한 게시글은 일정 시간 동안 캐시에 저장되도록 하여, 뒤로 가기 후 재진입 시에도 로딩 없이 빠르게 화면을 구성할 수 있도록 개선하였습니다. 에러 처리에 있어서도 단순히 “에러가 발생했습니다”라는 문구 대신, 네트워크 오류, 권한 문제, 삭제된 게시글, 토큰 만료 등 구체적인 상황에 맞는 안내 문구와 해결 방법을 함께 제시함으로써 사용자 혼란을 최소화하려 노력했습니다.

이러한 일련의 과정을 거치며, 단순히 ‘동작하는 기능’을 만드는 것에서 한 발 더 나아가, 사용성과 유지보수성까지 고려한 설계와 구현이 얼마나 중요한지를 체감할 수 있었고, 실제 사용자 입장에서 시스템을 바라보며 기술과 사용자 경험 사이의 균형을 고민하는 개발자로서 한 단계 성장할 수 있었던 시간이었다고 생각합니다.



복잡한 기능을 단순히 구현하는 데서 나아가, 구조화와 유지보수성 향상을 목표로 리팩터링과 UX 개선에 힘쓴 ST4R 팀의 이야기를 전해드렸습니다. 이 경험을 바탕으로 더 많은 사람에게 즐거운 별 관측 경험을 제공할 ST4R 팀의 Starlight 여정을 기대하겠습니다!🌌