복잡한 건강검진 결과를 이해하기 쉽게 해설하고, 개인 상태에 맞춘 건강 관리 방향을 제안하는 헬스케어 서비스
 |
 |
 |
 |
| 임지성 👑 | 김어진 | 박원 | 지민재 |
| 역할 | 종류 | 선정 근거 |
|---|---|---|
| Build Tool |  |
ESBuild 기반의 빠른 번들링과 HMR로 개발 생산성 향상 |
| Library |  |
컴포넌트 기반 아키텍처로 UI 구축을 간소화하고 효율적인 상태 관리 |
| Programming Language |  |
정적 타입 검사로 런타임 오류를 사전에 방지하고 코드 안정성 확보 |
| Styling |  |
제로 런타임 유틸리티 기반 스타일링으로 빠르고 일관된 UI 구현 |
| Data Fetching |  |
서버 상태와 캐싱을 선언적으로 관리 |
| Development Tools |  |
독립 환경에서 UI 컴포넌트를 개발·테스트하고 디자이너와 협업 강화 |
 |
OpenAPI 기반 API 함수와 타입 자동 생성으로 개발 생산성 및 타입 안정성 확보 | |
| Code Quality |  |
Linting과 Formatting을 단일 도구로 통합하여 빠른 속도와 간편한 설정 |
 |
Git hooks를 통한 커밋 전 코드 품질 자동 검사 | |
| Package Manager |  |
심볼릭 링크 기반 글로벌 저장소로 디스크 절약 및 빠른 설치 속도 |
| Deployment |  |
Git 연동을 통한 자동 배포와 간편한 CI/CD 설정 |
| Version Control |   |
분산 버전 관리와 PR 기반 협업으로 코드 품질 및 팀 생산성 향상 |
Feature-Sliced Design(FSD)는 함께 수정되는 코드들을 하나의 단위로 관리할 수 있도록 도와주어 구조 파악과 유지보수를 수월하게 해줍니다.
프로젝트 규모가 커질수록 폴더 구조와 파일 위치에 대한 기준을 명확히 하고자 FSD를 도입하게 되었어요.
자세한 FSD 구조와 설계 기준은 해당 PR에서 확인할 수 있어요!
src/
├── app/ # 앱 초기화, 전역 설정
│ ├── providers/ # Context Providers
│ ├── routes/ # 라우팅 설정
│ └── styles/ # 전역 스타일
├── pages/ # 페이지 컴포넌트
│ └── [page-name]/
│ ├── ui/ # 페이지 UI
│ ├── api/ # 페이지 전용 API (queries, mutations)
│ ├── model/ # 상태 관리, 비즈니스 로직
│ └── lib/ # 페이지 전용 유틸
├── widgets/ # 독립적인 UI 블록
│ └── [widget-name]/
│ └── ui/
└── shared/ # 공통 모듈
├── ui/ # 공통 UI 컴포넌트
├── apis/ # API 클라이언트, 자동 생성 코드
├── libs/ # 공통 유틸리티
├── styles/ # 공통 스타일, 디자인 토큰
├── configs/ # 설정 파일
└── assets/ # 정적 리소스 (svg, img)
3 브랜치 전략 (`main`, `develop`, `feat`)
main: 오직 배포를 위한 브랜치develop: 팀원끼리 작업한 내용(feature)을 합치는 곳feat: 각 작업에 따라 새로 파고 사용할 브랜치 (하나의 feat 브랜치는 하나의 Issue와 연결)
Prefix
| 머릿말 | 설명 |
|---|---|
init |
패키지 설치, 개발 설정 |
feat |
새로운 기능 추가 / 퍼블리싱 |
fix |
버그 수정 |
style |
CSS 등 사용자 UI 디자인 변경 |
api |
api 연결 로직 작성 |
refactor |
프로덕션 코드 리팩토링, QA 반영 |
chore |
빌드 테스트 업데이트, 패키지 매니저 설정 (프로덕션 코드 변경 X) |
deploy |
배포 작업 |
test |
테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X) |
rename |
파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
remove |
파일을 삭제하는 작업만 수행한 경우 |
docs |
문서 수정 |
브랜치 네이밍
prefix/#이슈번호/설명
- 여러 단어는
-으로 연결 - 예시:
setting/#1/router-setting,feat/#5/login,fix/#6/register-form-bug-fix
커밋 컨벤션
prefix: 커밋 메시지
- 예시:
feat: login form 구현,refactor: image upload 로직 커스텀훅으로 분리
브랜치 병합 규칙
- 메인 브랜치(main, develop)에서 직접적인 커밋은 하지 않는다.
- 작업 브랜치(feat)에서만 커밋하고, 병합은 PR(Pull Request)을 통해서만 진행한다.
- 작업 전에는 항상
git pull origin develop으로 feature 브랜치를 최신화한다. - 팀원들의 리뷰 후 2명 이상의 approve를 받아야 merge할 수 있다.
네이밍
| 대상 | 규칙 | 예시 |
|---|---|---|
| 컴포넌트 / class | PascalCase |
UserProfile, HealthReport |
| 폴더명, 파일명 | kebab-case (복수형) |
apis/, components/ |
| 변수, 함수, 파라미터 | camelCase |
userName, getUserData |
| 상수 | UPPER_SNAKE_CASE |
API_BASE_URL |
변수
var사용 금지.const기본, 필요시let사용- 전역 변수 최대한 지양
- 구조 분해 할당 적극 활용:
const { name, age } = user; - 문자열 조합 시 템플릿 리터럴 사용:
`Hello, ${name}`
함수
- 화살표 함수 기본 사용
- 이벤트 핸들러:
handle + 이벤트(예:handleBtnClick) - props 전달 시:
on + 이벤트(예:onClick={handleBtnClick}) - boolean 변수:
is/can/should/has + 상태(예:isLogined,canSubmit) - API 함수:
HTTP 메서드 + 명사(예:getUserList,postUserLike) - 배열 처리: 스프레드 연산자, 함수형 메서드(
map,filter등) 사용
TypeScript
- object:
interface, 단일 변수:type - 컴포넌트 props 타입:
역할 + Props(예:HeaderProps) - API response/request 타입:
OOOResponse,OOORequest
interface HeaderProps {
title: string;
description: string;
}
const Header = ({ title, description }: HeaderProps) => {
// ...
}기타
- 변수/함수명 20자 미만, 필요시 주석 추가
- 의미없는
<div>지양, 최상단은 fragment(<>) 사용 - children 불필요 시 self-closing:
<Component /> - named export 기본 사용
- 업무 관련 연락은 확인 즉시 응답해요.
- 의사 표현은 명확하게, 전달 방식은 부드럽게 표현해요.
- 진행 상황은 수시로 공유해요.
- 아이디어와 개선 의견을 자유롭게 제안해요.
- 마감 기한과 약속 시간을 준수해요.
- 일정 준수가 어려울 경우 사전에 공유해요.
- 어려운 상황은 함께 고민하고 해결해요.
- 긍정적인 팀 분위기를 유지해요.
- 개발할 때는 적절한 긴장감을 유지해요.
- 브랜치 룰셋과 PR 템플릿을 준수해요.
- PR 단위는 작게, 설명은 자세히, 리뷰는 꼼꼼히 진행해요.
- PR 작성 시 관련 컨텍스트(고민한 지점, 해결 과정 등)를 충분히 제공해요.
- 수정 요청 시 근거와 개선 방향을 함께 제시해요.