📌 프로젝트 소개

☕ Coffect: 커피로 소통하는 새로운 방법

Coffect은 공통의 관심사로 사람들을 연결하는 소셜 디스커버리 플랫폼입니다.

나와 비슷한 관심사를 가진 사람을 발견하고, 가벼운 커피챗을 제안하며, 커뮤니티를 통해 관심사를 공유해보세요. Coffect는 온라인에서의 대화가 실제 만남으로 이어지는 즐거운 경험을 제공합니다.

✨ 주요 기능

• 오늘의 추천 카드: 매일 새로운 사람들의 프로필 카드를 추천받고, 넘겨보며 마음에 드는 상대를 찾아보세요.
• 프로필 확인 및 커피챗 제안: 상대방의 프로필에서 관심사를 확인하고, '커피챗 제안하기' 기능을 통해 간편하게 만남을 제안할 수 있습니다.
• 실시간 채팅 및 약속 조율: 상대방이 제안을 수락하면 실시간 채팅방이 열립니다. 채팅방 내에서 캘린더와 약속 잡기를 활용해 약속 시간과 장소를 편리하게 정할 수 있습니다.
• 커뮤니티: 자유롭게 글을 작성하고 댓글을 달며 다른 사용자들과 소통할 수 있는 피드 형식의 커뮤니티 공간입니다.
• 실시간 알림: Firebase Cloud Messaging(FCM)을 통해 새로운 추천, 커피챗 제안, 채팅 메시지 등의 소식을 실시간 알림으로 받아볼 수 있습니다.
• 마이페이지: 내 프로필 정보를 수정하고, 내가 받은 제안과 보낸 제안을 관리하며, 약속 내역을 확인할 수 있습니다.

---

🏗 아키텍처 & 폴더 구조

폴더 구조

src/
├── assets/           # 정적 자원(이미지, 폰트, 스타일)
│   ├── images/
│   ├── styles/
│   └── fonts/
├── components/       # 재사용 UI 컴포넌트
│   ├── shareComponents/      # 다수 페이지에서 공유
│   ├── ProfileComponents/    # Profile 전용
├── pages/            # 라우팅 연결 페이지 단위 컴포넌트
├── hooks/            # 커스텀 훅
├── utils/            # 헬퍼/유틸 함수
├── apis/             # API 호출 로직 (React Query 사용)
├── types/            # 타입 정의
├── enums/            # 열거형 상수
├── App.tsx           # 루트 컴포넌트
└── index.tsx         # 엔트리 포인트

📌 규칙

• 페이지 전용 컴포넌트는 components/{Page명}/에 위치
• 다수 페이지에서 공유되는 경우만 shareComponents/에 저장
• 변수 → 함수 → return 순서 유지
• 함수는 화살표 함수 표현식만 사용

---

🛠️ 기술 스택 및 선정 이유

Coffect 프로젝트는 모던 웹 기술을 적극적으로 활용하여, 빠르고 안정적인 개발 경험과 풍부한 사용자 경험을 제공하는 것을 목표로 합니다.

Core & Build

• React & TypeScript
  • 선정 이유: 컴포넌트 기반 아키텍처를 통해 UI를 독립적이고 재사용 가능한 단위로 개발하기 위해 React를 선택했습니다. 여기에 TypeScript를 적용하여 컴파일 단계에서 타입을 검증함으로써, 코드의 안정성을 높이고 대규모 애플리케이션에서 발생할 수 있는 잠재적 버그를 사전에 방지하고자 했습니다.
• Vite
  • 선정 이유: 기존의 번들러(e.g., Webpack) 대비 월등히 빠른 개발 서버 구동 속도와 HMR(Hot Module Replacement) 성능을 제공하는 Vite를 선택하여 개발 생산성을 극대화하고자 했습니다.

Routing & State Management

• React Router (react-router-dom)
  • 선정 이유: SPA(Single Page Application)에서 사용자 경험을 해치지 않으면서 여러 페이지 간의 이동을 구현하기 위한 표준 라이브러리로 React Router를 선택했습니다.
• React Query (@tanstack/react-query)
  • 선정 이유: 클라이언트 상태와 서버 상태를 분리하여 관리하고, 서버에서 가져온 데이터의 캐싱, 동기화, 업데이트 로직을 간결하게 처리하기 위해 React Query를 선택했습니다. useEffect와 useState로 복잡하게 관리해야 했던 비동기 로직을 크게 단순화할 수 있습니다.
• Zustand
  • 선정 이유: React Query가 관리하지 않는 전역 클라이언트 상태(e.g., 모달의 열림/닫힘, UI 테마 설정)를 최소한의 보일러플레이트로 관리하기 위해 가볍고 유연한 Zustand를 선택했습니다.

Styling & UI Components

• Tailwind CSS
  • 선정 이유: 'Utility-First' 접근 방식을 통해 미리 정의된 클래스를 조합하여 HTML 내에서 직접 스타일을 적용함으로써, 빠르고 일관된 UI 개발을 위해 Tailwind CSS를 도입했습니다.
• Swiper
  • 선정 이유: 본 프로젝트의 핵심 기능인 프로필 카드 UI처럼, 모바일 환경에 최적화된 터치 슬라이드 및 스와이프 기능을 구현하기 위해 Swiper를 사용했습니다.

Real-time Communication & PWA

• Socket.IO Client
  • 선정 이유: 사용자와 사용자 간의 실시간 채팅 기능을 구현하기 위해, 안정적인 양방향 통신 채널을 제공하는 Socket.IO를 채택했습니다.
• Firebase (FCM)
  • 선정 이유: 새로운 매칭, 채팅 메시지, 커피챗 제안 등 사용자의 즉각적인 반응이 필요한 기능에 실시간 푸시 알림을 구현하기 위해 안정적이고 강력한 Firebase Cloud Messaging을 선택했습니다.
• PWA (vite-plugin-pwa)
  • 선정 이유: 웹 애플리케이션을 네이티브 앱처럼 사용자의 홈 화면에 설치하고, 오프라인 상태에서도 일부 기능을 사용할 수 있도록 Progressive Web App 기술을 적용했습니다.

Development Environment & Code Quality

• ESLint & Prettier
  • 선정 이유: 여러 개발자가 함께 작업하더라도 일관된 코드 스타일을 유지하고, 잠재적인 에러를 사전에 발견하기 위해 ESLint(코드 린터)와 Prettier(코드 포매터)를 도입했습니다. husky와 lint-staged를 연동하여 커밋 시 자동으로 코드 품질을 검사 및 교정함으로써, 저장소의 코드 품질을 높은 수준으로 유지했습니다.
• pnpm
  • 선정 이유: 빠른 의존성 설치 속도와 효율적인 디스크 공간 활용을 위해 pnpm을 패키지 매니저로 선택했습니다.

---

🤝 협업 규칙

1. PR 규칙

• PR 대상 branch:
  • feature/* → develop
  • chore/* → develop
• PR 단위: 기능 단위 (UI 파편 단위 금지)
• PR 템플릿 사용:

## 📌 PR 제목

- A 기능 추가
- B 기능 삭제
- C 기능 수정

## 🧩 변경 사항

- 주요 변경 사항 나열

## ✅ 체크리스트

[ ] 코드 스타일 준수
[ ] 테스트 실행
[ ] 주석 작성

## 💬 기타 참고사항

- 관련 문서, 링크

2. Merge 규칙

• 팀장만 develop, main 머지
• 팀원은 develop으로만 PR

3. Commit 규칙

타입(스코프): 제목

타입 예시: feat, fix, chore, docs, refactor, test

4. Branch 규칙

브랜치명	설명
main	운영 배포용
develop	다음 배포 준비용
feature/*	기능 개발용
release/*	배포 준비
hotfix/*	긴급 수정

예시:

feature/login
feature/login-42
release-1.0
hotfix-1.2.1

5. Issue 규칙

• Bug report 템플릿: 버그 발생 시 재현 방법, 스크린샷, 환경 정보 작성
• Feature request 템플릿: 기능 제안 사유, 구현 아이디어 작성

6. 코딩 컨벤션

• 변수 → 함수 → return 순
• 함수는 화살표 함수 표현식만 사용
• export/default는 파일 하단
• 주석 필수: 파일 상단, 함수 앞, 복잡 로직, JSX 내부 필요 시
• fetch 대신 useQuery/useMutation 사용

7. 기타

• pnpm 사용 (npm, yarn 금지)
• 정기회의: 주 2회 (3~4일 간격)
• 기능 지연 시 Discord 화면 공유 필수

---

📦 설치 패키지 및 사용 목적

패키지명	설치 명령어	사용 목적
swiper	pnpm add swiper	카드형 슬라이드 UI 구현. (프로필 카드 플립, 배너 슬라이드 등)
react-date-picker	npm install react-date-picker	날짜 선택 UI 구현. (react-day-picker 대체)
@tailwindcss/line-clamp	pnpm install -D @tailwindcss/line-clamp	긴 텍스트를 일정 줄 수에서 말줄임(...) 처리.
zustand	pnpm add zustand	전역 상태 관리.
husky	npm install husky --save-dev	Git hook 자동화 (커밋 전 lint 검사 등).
lint-staged	npm install --save-dev lint-staged	Git staged 파일에만 lint/포맷 적용.
vite-tsconfig-paths	npm install --save-dev vite-tsconfig-paths	Vite에서 tsconfig.json 경로 별칭 인식.
axios	pnpm i axios	HTTP 요청 처리를 위한 라이브러리.
locomotive-scroll	pnpm add locomotive-scroll	부드러운 스크롤, 스크롤 감지 이벤트 구현.
socket.io-client	pnpm add socket.io-client	실시간 양방향 통신 (채팅, 알림 등).
firebase	pnpm add firebase	FCM 푸시 알림, Firebase 서비스 연동.
vite-plugin-pwa	pnpm add -D vite-plugin-pwa	Vite 기반 PWA(Service Worker, 캐싱, 오프라인 지원).
workbox-precaching	pnpm add workbox-precaching	PWA 서비스 워커에서 정적 리소스 사전 캐싱.
@tanstack/react-query	pnpm add @tanstack/react-query	useQuery, useMutation 훅 사용을 위한 서버 상태 관리 라이브러리. API 호출 결과 캐싱·비동기 데이터 fetching 최적화.

---

개발 중 겪은 어려움과 해결 과정

배포 환경에서의 소켓 통신 실패

• 문제 상황
  • 서비스를 Vercel 환경에 배포한 뒤, 프론트엔드에서 소켓 통신을 시도했을 때 연결이 되지 않는 문제가 발생했습니다. HTTPS 기반 배포 환경에서 소켓 연결이 시도되었지만, 기본적으로 설정된 서버 주소가 맞지 않아 요청이 잘못된 엔드포인트로 향했고, 그 결과 연결이 실패했습니다. 특히 WebSocket은 HTTP와 달리 프로토콜(wss://)과 도메인 설정이 정확해야 하므로, 잘못된 경로로 요청하면 연결이 바로 끊어지는 문제가 있었습니다.
• 해결 과정
  • 처음에는 .env를 수정하여 프론트엔드에서 올바른 API 주소를 참조하도록 하는 방법을 고려했으나, 프론트와 백엔드 간 도메인 불일치 문제로 근본적인 해결이 되지 않았습니다.
  • 이에 백엔드 서버의 nginx 설정을 수정하여, 실제 서비스 도메인과 배포 환경(Vercel)에서 사용하는 주소를 일치시키는 방식으로 접근했습니다. server_name과 프록시 설정을 변경해 소켓 통신 요청이 올바른 백엔드 서버로 라우팅되도록 했습니다.
• 결과
  • nginx 설정 변경 후, Vercel 배포 환경에서도 소켓 연결이 정상적으로 이루어졌습니다. 이제 프론트엔드가 어떤 환경에서 배포되더라도, 해당 도메인을 통해 안정적으로 소켓 통신을 할 수 있게 되었으며, 실시간 채팅 및 데이터 동기화 기능이 정상 동작하게 되었습니다.

공유 컴포넌트의 상태 불일치 문제 해결: API 응답 데이터 분석을 통한 원인 규명

• 문제 상황
  • 프로젝트 내 여러 페이지(커뮤니티 피드, 마이페이지 등)에서 재사용되는 공유 컴포넌트인 FeedItem.tsx 가 있었습니다. 대부분의 페이지에서는 '좋아요'와 '북마크' 버튼이 정상적으로 동작했지만, 특정 페이지에서만 버튼을 클릭해도 UI(좋아요 색상과 카운트 / 북마크 색상)가 변경되지 않는 상태 불일치 문제가 발생했습니다. 동일한 컴포넌트가 다른 페이지에서는 정상 동작했기 때문에, 문제의 원인을 파악하기 어려운 초기 상황이었습니다.
• 해결 과정
  • 이 문제를 해결하기 위해, 프론트엔드 로직의 문제인지 백엔드 API의 문제인지를 명확히 식별하는 것을 최우선 목표로 삼고 체계적인 디버깅을 진행했습니다.
  1. 가설 수립: '컴포넌트의 로직은 동일하므로, 각 페이지에 전달되는 데이터나 API 응답의 차이가 원인일 것이다'라는 가설을 세웠습니다.
  2. 정상 동작 기준점 확인: 먼저, 기능이 정상 동작하는 페이지에서 브라우저 개발자 도구의 '네트워크' 탭을 열었습니다. '좋아요' 버튼 클릭 전후의 API 응답(Response) 데이터를 캡처하여, 성공 시 서버가 어떤 형식과 데이터로 응답하는지에 대한 명확한 기준점을 확보했습니다.
  3. 문제 지점 비교 분석: 다음으로, 문제가 발생하는 페이지에서 동일한 작업을 반복했습니다. 버튼 클릭 후 서버로부터 받은 API 응답을 정상 동작 기준점과 비교 분석한 결과, 문제가 되는 페이지의 API 응답에는 업데이트된 '좋아요' 상태나 '카운트' 정보가 누락되어 있거나, 다른 형식으로 전달되고 있음을 발견했습니다.
  4. 원인 규명 및 협업: 프론트엔드 컴포넌트는 정상이었으나, 특정 API 엔드포인트에서 비정상적인 데이터를 응답하고 있음이 명확해졌습니다. 이처럼 데이터에 기반한 구체적인 근거(정상/비정상 응답 데이터 비교 자료)를 준비하여 백엔드 팀에 전달했고, 덕분에 백엔드 팀은 문제의 원인을 신속하게 파악하고 해당 API를 수정할 수 있었습니다.
• 결과
  • 백엔드 API 수정 후, 모든 페이지에서 '좋아요' 및 '북마크' 기능이 일관되게 동작하는 것을 확인했습니다. 이 경험을 통해 복잡한 문제 상황에서 섣불리 코드를 수정하기보다, 체계적인 데이터 분석을 통해 문제의 원인을 정확히 분리해내는 디버깅 프로세스의 중요성을 다시 한번 깨달았습니다. 또한, 팀 간의 협업에 있어 명확한 근거 자료가 얼마나 효율적인 소통과 빠른 문제 해결을 이끌어내는지 배울 수 있었습니다.

추천 카드 기능 안정성 및 UI/UX 개선

• 문제 상황
  1. 무한 카드 버그: 하루에 제공되는 3장의 추천 카드를 모두 소진했을 때, 기능이 종료되지 않고 마지막 카드가 계속해서 보이는 '무한 루프' 현상이 발생했습니다. 이는 사용자에게 기능이 끝났다는 명확한 피드백을 주지 못하는 심각한 버그였습니다.
  2. 카드 전환 시 UI 깨짐: 사용자가 카드를 빠르게 넘길 때(Swipe), 다음 카드의 데이터가 미처 로드되지 않아 이전 카드의 정보가 잠시 노출되거나, 비어있는 카드가 보이는 등 시각적으로 매끄럽지 못한 사용자 경험을 제공했습니다.
• 해결 과정
  1. 명확한 API 계약 수립 및 종료 상태 처리
     • 원인 분석: 초기 API는 추천 카드가 모두 소진되었을 때, 마지막 카드 데이터를 계속 반환하고 있었습니다. 프론트엔드에서는 이를 에러 상황으로 인지할 수 없었습니다.
     • 해결: 백엔드 팀과의 협의를 통해, 더 이상 추천할 카드가 없을 경우 null을 반환하도록 API 명세를 재정의했습니다. 프론트엔드에서는 getCurrentRecommendedCard API의 응답이 null일 경우, '오늘의 추천이 모두 종료되었습니다'와 같은 완료 화면을 렌더링하도록 로직을 수정하여 '무한 루프' 버그를 근본적으로 해결했습니다.
  2. setQueryData를 활용한 낙관적 업데이트(Optimistic Update) 적용:
     • 원인 분석: 카드 전환 UI 깨짐 현상은 카드 스킵 initOrSkipCard API 호출 후, 다음 카드 정보를 가져오는 getCurrentRecommendedCard API가 호출되기까지의 네트워크 지연 시간 때문에 발생했습니다.
     • 해결: 이 문제를 해결하기 위해 React Query의 setQueryData 기능을 활용했습니다. initOrSkipCard Mutation이 성공하는 즉시, 네트워크 요청을 기다리지 않고 다음 카드의 데이터를 미리 받아와 setQueryData로 캐시를 수동으로 업데이트했습니다. 이 '낙관적 업데이트' 방식을 통해, UI는 다음 카드를 렌더링할 시점에 이미 캐시에 준비된 데이터를 사용하게 되어 네트워크 지연으로 인한 시각적 깨짐 현상을 완벽하게 제거하고 매우 부드러운 카드 전환 경험을 구현할 수 있었습니다.
• 결과
  • 백엔드와의 긴밀한 협업과 React Query의 고급 기능 활용을 통해, 추천 카드 기능의 안정성을 확보하고 사용자 경험을 크게 향상시킬 수 있었습니다. 이 과정에서 명확한 API 계약의 중요성과, 네트워크 지연을 고려한 프론트엔드 상태 관리 기법이 얼마나 중요한지 배울 수 있었습니다.

데이터 전달 구조 개선을 통한 API 호출 최적화

• 문제 상황
  • 채팅방 페이지에 진입한 후, 내부의 특정 기능(e.g., 일정 등록)을 사용하기 위해 coffectId라는 값이 필요했습니다. 하지만 채팅방 목록 페이지에서 채팅방 페이지로 이동할 때 이 coffectId 값을 전달하지 않아, 채팅방 페이지는 coffectId를 얻기 위해 불필요한 API를 추가로 호출해야만 했습니다. 이는 페이지 로딩 속도를 저하시키고 서버에 부담을 주는 비효율적인 'API 워터폴(Waterfall)' 현상을 야기했습니다.
• 해결 과정
  1. 원인 분석: 문제의 근본 원인은 페이지 간 이동(Routing) 시 필요한 데이터가 충분히 전달되지 않는다는 점이었습니다.
  2. 구조 개선: 이 문제를 해결하기 위해 데이터 전달 구조를 개선했습니다. 채팅방 목록에서 coffectId를 이미 알고 있으므로, 특정 채팅방으로 이동할 때 URL 파라미터 (/chat/:coffectId) 또는 React Router의 state를 통해 coffectId를 직접 전달하도록 로직을 수정했습니다.
  3. API 호출 제거: 채팅방 페이지는 이제 진입 시점부터 coffectId를 직접 전달받게 되어, 더 이상 coffectId를 얻기 위한 별도의 API를 호출할 필요가 없어졌습니다.
• 결과:
  • 불필요한 API 호출 로직을 제거함으로써 채팅방의 로딩 속도를 눈에 띄게 개선하고 서버의 부담을 줄였습니다. 이 경험을 통해 SPA(Single Page Application) 환경에서 효율적인 페이지 전환을 위해서는 컴포넌트나 페이지 간에 필요한 데이터를 명확하게 전달하는 라우팅 설계의 중요성을 배울 수 있었습니다.

비트마스크(Bitmask) 데이터의 클라이언트 단 처리 및 시각화

• 문제 상황
  • '공강 시간 조회' 기능은 두 사용자가 공통으로 비어있는 시간을 보여주는 기능입니다. 백엔드에서는 데이터 효율성을 위해 각 사용자의 전체 시간표를 '100101...'과 같은 형태의 긴 비트열(Bitmask) 데이터로 전달했습니다. 프론트엔드에서는 이 비트마스크 데이터를 받아, 두 사용자의 공통 시간을 계산하고, 이를 '월 10:00, 수 14:00'처럼 사용자가 쉽게 이해할 수 있는 형태로 변환해야 하는 과제가 있었습니다.
• 해결 과정
  1. 공통 시간 계산: 두 사용자의 비트마스크 문자열을 입력받아, 각 자리에 대해 비트 AND 연산(&)을 수행하는 로직을 구현했습니다. 이를 통해 두 사용자 모두 '1'(공강)인 시간대만 '1'로 남는 새로운 비트마스크(공통 공강 시간)를 생성했습니다.
  2. 데이터 변환 및 시각화: 생성된 공통 공강 시간 비트마스크를 순회하며 '1'이 위치한 인덱스를 찾았습니다. 각 인덱스는 '월요일 9시', '월요일 10시' 등 미리 정의된 시간표의 특정 시간대와 매핑되도록 설계했습니다. 이 매핑 정보를 바탕으로, 최종적으로 사용자가 알아보기 쉬운 문자열 형태로 변환하여 화면에 표시했습니다.
• 결과:
  • 백엔드로부터 받은 압축된 비트마스크 데이터를 프론트엔드에서 성공적으로 파싱하고 가공하여, 복잡한 시간표 정보를 사용자 친화적인 UI로 제공할 수 있었습니다. 이 과정에서 서버 데이터 형식에 맞춰 클라이언트에서 비즈니스 로직을 효과적으로 처리하는 능력과, 데이터를 사용자 관점에서 유의미한 정보로 시각화하는 능력을 기를 수 있었습니다.

컴포넌트 데이터 흐름 리팩토링: 잘못된 Hook 사용으로 인한 데이터 불일치 해결

• 문제 상황
  • 게시글 상세 페이지 (PostDetailPage.tsx)에 있는 댓글 입력 컴포넌트(CommentInput.tsx)에서 댓글을 작성하려는 현재 로그인된 사용자의 프로필 이미지가 아닌 게시글 작성자의 프로필 이미지가 표시되는 버그가 발생했습니다. 이는 사용자에게 마치 다른 사람의 신분으로 댓글을 다는 듯한 혼란을 주는 심각한 UI 오류였습니다.
• 해결 과정
  1. 원인 분석: 코드 리뷰 결과, 문제의 원인은 CommentInput 컴포넌트 내에서 usePostDetail이라는 훅을 직접 호출하여 사용하고 있었기 때문이었습니다. 이 훅은 이름 그대로 '게시글 상세 정보'를 가져오는 역할을 하므로, 해당 훅이 반환하는 프로필 이미지는 당연히 '게시글 작성자'의 것이었습니다. 이는 컴포넌트가 자신의 역할 범위를 넘어서는 데이터를 직접 호출하여 사용한 설계상의 오류였습니다.
  2. 데이터 흐름 재설계: CommentInput 컴포넌트는 댓글 입력에만 집중해야 하며, 현재 로그인한 사용자의 정보는 상위 컴포넌트로부터 전달받는 것이 올바른 데이터 흐름이라고 판단했습니다. 이에 따라 CommentInput 컴포넌트 내부의 usePostDetail 훅 호출 로직을 과감히 제거했습니다.
  3. Props 기반으로 리팩토링: CommentInput 컴포넌트가 currentUserProfileImage라는 이름의 Prop을 받아서 프로필 이미지로 사용하도록 수정했습니다. 이를 통해 CommentInput은 데이터의 출처를 신경 쓸 필요 없이, 전달받은 데이터를 화면에 그리는 역할에만 충실한 재사용성 높은 컴포넌트가 되었습니다.
  4. 상위 컴포넌트의 책임 부여: 상위 컴포넌트인 PostDetailPage.tsx가 현재 로그인된 사용자의 프로필 정보(e.g., profile.ts의 getProfile API를 사용하는 훅을 통해)를 가져와서, CommentInput에 currentUserProfileImage Prop으로 정확한 데이터를 전달하도록 수정했습니다.
• 결과:
  • 버그를 해결하여 댓글 입력창에 정확한 사용자의 프로필 이미지가 표시되도록 수정했습니다. 더 나아가, 컴포넌트의 책임을 명확히 분리하고 부모-자식 간의 데이터 흐름을 Props를 통해 단방향으로 흐르도록 리팩토링함으로써, 더 예측 가능하고 유지보수하기 쉬운 코드 구조를 만들 수 있었습니다. 이 경험은 각 컴포넌트의 역할을 명확히 정의하고 올바른 데이터 흐름을 설계하는 것의 중요성을 깨닫게 해주었습니다.

---

🤖 프로젝트의 AI 활용 사례

AI 코드 리뷰어 (CodeRabbit)

CodeRabbit 도입기

프로젝트 초기에 팀원 3명의 Pull Request(PR) 리뷰를 팀장 한 명이 맡다보니 수정된 코드의 내용이 많아 PR merge가 지연되곤 했습니다. 이를 해결하기 위해 팀원들이 리뷰에 참여했지만 각기 다른 리뷰 기준으로 인해 코드의 일관성을 유지하기 어렵다는 한계에 부딪혔습니다.

이러한 문제들을 극복하기 위해, 저희는 AI 코드 리뷰어 CodeRabbit을 도입했습니다.

CodeRabbit 도입으로 얻게 된 이점

1. 일관성 있는 코드 품질 관리 및 표준화

   • CodeRabbit은 사전에 정의된 규칙에 따라 모든 PR을 동일한 기준으로 검토하여, 사람마다 다를 수 있는 주관적인 판단을 배제하고 프로젝트 전체의 코딩 스타일을 일관되게 유지할 수 있었습니다.
   • 놓치기 쉬운 잠재적 버그, 안티 패턴, 비효율적인 코드 등을 초기에 발견하여 코드의 안정성과 품질을 크게 향상시켰습니다.

2. 핵심 로직에 집중하는 리뷰 문화 정착

   • 스타일 가이드, 네이밍 규칙, 미사용 변수 등과 같은 부분은 CodeRabbit이 전담하게 되었습니다.
   • 그 결과 팀원들은 이제 코드의 핵심 로직, 아키텍처, 사용자 경험(UX) 등 더 중요하고 창의적인 부분에 집중하여 작업을 진행할 수 있었습니다.

3. 객관적인 피드백을 통한 학습 문화 조성

   • CodeRabbit이 제안하는 개선 사항과 그 이유를 살펴보며, 팀원 모두가 더 나은 코드 작성법을 자연스럽게 익히고 함께 성장하는 계기가 되었습니다.

4. 리뷰 병목 현상 해결 및 개발 속도 향상

   • PR 생성 즉시 리뷰가 자동으로 진행되므로, 리뷰를 기다리는 대기 시간이 크게 줄었습니다.
   • 팀원들은 CodeRabbit의 검토 결과를 바탕으로 빠르게 판단을 내릴 수 있어, 전체적인 개발 사이클이 눈에 띄게 빨라졌습니다.