[ThisVsThat Project] 프로젝트 소개 및 회고

1. 프로젝트 개요

이거저거(ThisVsThat)는 사용자가 일상 속에서 마주하는 크고 작은 선택의 고민을 해결할 수 있도록 돕는 투표 기반 커뮤니티 플랫폼이다.

‘이거? 저거?’, ‘할까? 말까?’와 같은 선택 상황을 게시글로 작성하면 다른 사용자들은 투표를 통해 의견을 표현하고 채팅을 통해 실시간으로 소통할 수 있다.

🔗 주요 담당 작업 바로 보기

2. 프로젝트 정보

• 유형: 팀 프로젝트

• 기간: 2025.02.05 ~ 2025.03.03 (약 4주)

• 인원: 6명 (모든 팀원이 프론트엔드와 백엔드를 함께 개발)

• 주요 기능

  • 소셜 로그인
  • 게시판 (게시글 · 투표 · 실시간 채팅)
  • 마이페이지 (사용자 정보 관리, 작성글 · 투표 · 채팅방 조회)
  • 관리자 (금지 키워드 · 신고 게시글 · 회원 관리)

• GitHub: 🔗 https://github.com/Kimkaaa/ThisVsThat

3. 기술 스택

• 프론트엔드: HTML, CSS, JavaScript, Thymeleaf

• 백엔드: Java 17, Spring Boot, Spring Security, OAuth2, JWT, JPA

• 데이터베이스: PostgreSQL

• 실시간 통신: WebSocket, Redis

• 인프라 및 배포: AWS (Elastic Beanstalk, RDS, S3), GitHub Actions

• 협업 도구: Notion, Figma, Discord

4. DB 설계

ERD

테이블 정의서

🔗 테이블 정의서 확인하기

5. 주요 화면

메인

전체 게시글을 확인할 수 있으며, 카테고리·정렬·검색 조건에 따라 조회할 수 있다.

무한 스크롤을 지원하며, 게시글 상세 페이지 진입 후 뒤로가기 시 기존 목록과 스크롤 위치가 유지된다.

게시글

게시글 내용, 투표 선택지, 결과를 확인할 수 있으며 투표와 채팅에 참여할 수 있다.

작성자 여부에 따라 노출 기능이 달라지며, 해시태그 조회와 URL 복사도 가능하다.

채팅

채팅 입장 전 프로필 이미지, 채팅 닉네임, 선택지를 설정할 수 있다.

채팅방 입장 시 이전 메시지를 확인할 수 있으며, 실시간 채팅이 가능하다.

참여 인원을 확인할 수 있고, 투표 결과 확인 및 갱신도 가능하다.

로그인 및 회원가입

Google, Kakao, Naver 소셜 로그인을 사용할 수 있으며, 최초 로그인 시 추가 정보를 입력해 회원가입을 진행한다.

기존 가입 소셜과 다른 로그인 시도, 이미 로그인된 상태에서의 페이지 진입에 대한 안내를 제공한다.

6. 담당 역할

백엔드

• OAuth 소셜 로그인 및 JWT 인증
• 이미지 업로드 기능
• AWS 연동(Elastic Beanstalk, RDS, S3)
• GitHub Actions 기반 배포 자동화

프론트엔드

• 로그인/회원가입 관련 화면
• URL 복사, 뒤로가기 기능
• 공통 CSS 정리 및 UI 일관성 개선

프로젝트 기여

• DB 설계 및 API 설계
• 협업 기준 문서 작성 및 공유
• 일정 관리 및 Git 협업 관리

7. 프로젝트 배경과 설계

1) 기획 배경

이전까지 진행했던 프로젝트들은 특정 주제나 대상이 비교적 분명한 편이었다.

이번에는 조금 더 많은 사용자가 가볍게 참여할 수 있는 서비스를 만들어보고 싶었다.

그 과정에서 ‘이거? 저거?’, ‘할까? 말까?’ 같은 선택 상황을 글로 올리고, 다른 사용자가 의견을 표현하는 형태를 구상하게 됐다.

그 방향에서 정한 주제가 투표 기반 커뮤니티였다.

일상적인 선택은 누구나 쉽게 참여할 수 있고 진입장벽이 낮다는 점에서 다양한 사용자가 반응할 수 있는 주제라고 생각했다.

2) 서비스 설계

서비스를 설계할 때 가장 중요하게 본 것은 사용자가 빠르고 부담 없이 참여할 수 있는 구조였다.

투표 선택지를 2개로 둔 것도 같은 이유였다.

여러 선택지를 두는 것보다 직관적이고, 게시글을 확인한 뒤 바로 반응하기에 적절하다고 판단했다.

다만 단순히 선택만 하고 끝나지 않도록, 투표로 의견을 표현하고 필요하면 채팅으로 대화를 이어갈 수 있도록 했다.

또 웹으로 구현했지만, 모바일 사용을 고려해 일부 영역에서는 가로 스크롤이나 무한 스크롤 방식을 적용했다.

8. 주요 담당 작업

1) 협업 방식

기획과 디자인은 초기에 오프라인으로 함께 정리했고, 실제 개발 단계부터는 온라인 중심으로 작업을 진행했다.

초반에는 자주 모여 방향을 빠르게 정리하려고 했고, 개발 단계에서는 노션, 디스코드를 사용해 내용을 공유했다.

다만 작업 시간대가 다르다 보니 실시간으로 모든 내용을 논의하기가 어려웠다.

그래서 컨벤션, DB 설계, API 명세, 깃 운영 방식, 프로젝트 세팅 방법 등을 문서로 정리해 협업 기준으로 삼았다.

하지만 실제 작업에서는 문서만으로 충분하지 않은 부분도 있었고, 이를 보완하기 위해 코드 리뷰와 QA 시간을 두고 구현 방향과 결과를 함께 점검했다.

그 과정에서 우선순위를 다시 정리하고, 일부 기능은 범위와 일정에 맞게 조정했다.

2) 프로젝트 세팅과 환경 구성

프로젝트 초반에는 로컬 실행 환경과 공통 인프라를 먼저 구성했다.

AWS RDS, S3, Elastic Beanstalk를 연결한 뒤, 이미지 업로드 기능이 여러 곳에서 쓰일 것을 고려해 공통 유틸과 테스트 화면을 구현했다.

이후 프로젝트를 배포해 확인했고, 이를 기준으로 각자 작업을 시작했다.

또 맥과 윈도우 사용자가 함께 작업하는 환경을 고려해, 줄 바꿈 처리와 같은 깃 설정도 정리했다.

3) 깃 협업과 배포 흐름 정리

GitHub Organization을 생성하고, 팀원 권한과 브랜치 전략을 정리했다.

기능 개발은 dev 브랜치에서 분기한 기능 브랜치에서 진행하고, 작업이 끝나면 dev 브랜치로 PR을 올리는 방식으로 운영했다.

배포는 main 브랜치 병합 시 GitHub Actions가 실행되도록 설정했다.

배포가 연결되는 main 브랜치에는 브랜치 보호 규칙을 적용해 직접 푸시와 강제 푸시를 제한했다.

애플리케이션을 빌드한 뒤 결과물을 S3에 업로드하고, Elastic Beanstalk 환경에 새 버전을 반영했다.

배포 후에는 헬스 체크를 통해 정상 응답 여부를 확인하도록 했다.

자세한 배포 과정은 아래 글에서 확인할 수 있다.

🔗 GitHub Actions와 AWS 기반 배포 자동화

9. 트러블슈팅

1) JWT 저장 방식 개선

로그인 구현에서는 JWT를 어디에 저장하고, 어떤 방식으로 다음 요청에 전달할지에 대한 고민이 있었다.

처음에는 URL 파라미터나 HTTP 헤더를 통해 토큰을 전달하는 방식을 검토했다.

하지만 토큰이 외부에 노출되지 않아야 하고, OAuth 로그인 이후 흐름을 서버에서 제어할 수 있어야 하며, 기존 회원·신규 회원·차단 사용자 처리와 로그인 전 페이지 복귀까지 함께 다룰 필요가 있었다.

이를 위해 JWT를 HTTP-Only 쿠키에 저장하는 방식으로 변경했다.

요청이 들어오면 서버가 쿠키에서 JWT를 꺼내 인증을 처리하고, 로그인이나 회원가입이 끝난 뒤에는 세션에 저장해 둔 이전 요청 URL을 기준으로 다시 이동하도록 했다.

2) 닉네임 중복 검사 요청 최적화

회원가입에서는 닉네임 중복 검사를 입력 단계에서 바로 안내하려고 했지만, 단순하게 구현하면 입력할 때마다 서버 요청이 반복되는 문제가 있었다.

특히 닉네임은 한 글자씩 바뀌는 입력값이라 호출 빈도가 높아지기 쉬웠고, 같은 값을 다시 입력하는 경우에도 동일한 요청이 반복될 수 있었다.

이 부분은 디바운싱을 적용해 입력이 잠시 멈춘 시점에만 검사하도록 하고, 이미 확인한 값은 캐시에 저장해 재사용하도록 처리했다.

다만 캐시만 기준으로 삼으면 실제 서버 상태와 어긋날 수 있기 때문에, 최종 제출 시에는 다시 서버 기준으로 확인하도록 했다.

3) 모바일 브라우저 100vh 레이아웃 문제 대응

모바일에서는 주소창이나 하단 UI 때문에 100vh가 실제 보이는 영역과 다르게 계산되는 경우가 있었고, 그 결과 하단 버튼이 밀리거나 일부 영역이 잘려 보이는 현상이 발생했다.

이 부분은 모든 페이지에 일괄 적용하기보다, 로그인과 회원가입처럼 원스크린 구성이 중요한 화면에 한정해 보완했다.

최신 브라우저에서는 100svh를 우선 사용하고 지원이 불완전한 환경에서는 CSS 변수로 높이를 보정했으며, 높이 값은 min-height 기준으로 정리했다.

10. 아쉬운 점과 개선 방향

1) API 구현이 RESTful하지 못한 점

일부 기능에서는 상태를 변경하는 요청에 GET 메서드가 사용되었고, 엔드포인트 표현도 일관되지 않은 부분이 있었다.

이후에는 기능 성격에 맞는 HTTP 메서드를 적용하고, 경로 구조도 자원 기준에 맞춰 개선할 필요가 있다.

2) 인증 처리가 일관되지 않았던 점

JWT 인증은 필터를 중심으로 처리했지만, 일부 컨트롤러에서는 쿠키를 직접 읽어 토큰을 다시 해석했다.

로그인 후 복귀 처리에도 세션 저장 방식과 URL 파라미터 방식이 함께 사용되었다.

보완한다면 인증 정보 조회와 로그인 후 복귀 처리 방식을 더 일관되게 가져갈 필요가 있다.

3) 파일 업로드 검증이 충분하지 않았던 점

이미지 업로드는 S3 연동 공통 서비스로 분리해 재사용할 수 있도록 구성했다.

다만 파일 크기 제한, MIME 타입, 확장자 검증 같은 서버 단 기준은 더 구체적으로 정리할 여지가 있었다.

공통 기능으로 관리한 만큼 검증 정책을 더 명확하게 했으면 좋았겠다는 아쉬움이 남았다.

마무리

개발 단계부터 온라인 중심으로 작업을 진행하다 보니, 작업 시간대 차이로 실시간 조율이 쉽지 않은 경우가 있었다.

그만큼 초반에 컨벤션과 문서를 정리해 공유하며 협업 기준을 맞추려고 했다.

다만 실제 구현 단계에서는 파일명이나 코드 스타일이 달라지는 경우가 있었고, API 역시 설계와 구현이 일치하지 않는 문제가 생겼다.

예를 들어 하나의 흐름으로 연결되어야 할 기능이 서로 다른 엔드포인트 기준으로 구현되면서, 같은 성격의 기능인데도 경로가 달라 오류가 나는 경우가 있었다.

중간 확인과 QA는 이런 부분을 다시 점검하고 작업 방향을 정리하는 데 중요한 역할을 했다.

DB 설계 역시 처음 정한 구조를 그대로 유지하기보다, 해시태그 테이블은 논의 끝에 제외하고 신고 테이블은 다시 추가하는 식으로 조정했다.

결과적으로 협업에서는 작업 과정을 함께 확인하고 조율하는 일이 중요하다는 점을 체감할 수 있었다.