유지 관리가 용이함
미래의 개발자가 쉽게 이해하고 수정하며 확장할 수 있는 소프트웨어를 구축하세요.
명확한 프로젝트 구조 및 모듈형 아키텍처
우리는 폴더 구조가 미래의 개발자가 가장 먼저 판단할 요소가 되도록 합니다. 의견이 명확하고 일관된 폴더 구조가 사용됩니다 (예: src/components, src/services, src/hooks, src/features).
읽기 쉽고 예측 가능한 코드 표준
우리는 컴파일러뿐만 아니라 인간을 위해 코드를 작성합니다. 모든 프로젝트에서 일관된 명명 규칙과 패턴을 따릅니다. ESLint와 Prettier는 Husky와 같은 pre-commit 훅을 통해 포맷팅을 강제하도록 설정되어 있어, 시작부터 코드 품질을 보장합니다. 우리는 유지 관리가 더 용이하도록 JavaScript 대신 TypeScript와 같은 타입 언어를 우선시합니다. 우리는 항상 코드를 읽기 쉽고 관리하기 쉬우며, 집중적이고 작게 유지합니다.
공유 디자인 시스템 / 컴포넌트 라이브러리
재사용 가능한 코드 컴포넌트에 디자인 결정을 인코딩하여 디자인 혼란을 피합니다. ShadCN, Tailwind UI 또는 Material UI와 같은 확립된 컴포넌트 시스템을 사용하여 프로젝트 전반에 걸쳐 일관성을 보장합니다. 이 접근 방식은 절대적으로 필요하지 않은 한 일회성 UI 코드를 작성하는 것을 피하여 시간을 절약하고 디자인 일관성을 보장합니다.
캡슐화된 비즈니스 로직
우리는 비즈니스 로직이 UI 레이어에 포함되지 않도록 보장합니다. 서비스 레이어, 커스텀 훅 또는 컨트롤러 모듈을 사용하여 비즈니스 로직을 적절히 분리하고 조직합니다. API 상호작용을 위해 SWR, React Query 또는 캐싱 및 오류 상태를 효율적으로 처리하는 커스텀 래퍼를 사용하여 현대적인 데이터 페칭 패턴을 구현합니다. 모든 API 호출은 services/api/user.ts와 같은 전용 서비스 폴더로 추상화되어 코드베이스를 더 유지 관리 가능하고 테스트 가능하게 만듭니다.
문서화: 가볍지만 유용하게 유지하기
우리는 소설을 쓰지 않습니다—다음 개발자가 빠르게 온보딩할 수 있을 만큼만 작성합니다. README.md는 항상 설정, 환경 변수, 배포 지침을 포함하여 작성됩니다. 복잡한 로직에 대해서는 짧은 주석이 추가됩니다(주석을 과도하게 달지 않습니다). 공개 메서드에는 TSDoc / JSDoc이 사용됩니다. 테스트 실행 방법 / 규칙에 대한 CONTRIBUTING.md가 추가됩니다.
테스트 커버리지 (중요 경로만)
우리는 100% 커버리지가 필요하지 않지만, 실패가 비용이 많이 드는 곳에서는 완전한 커버리지가 필요합니다. 비즈니스에 중요한 기능에 대해 단위 테스트가 우선시됩니다. API 엔드포인트나 워크플로우에 대해서는 통합 테스트가 사용됩니다. 사용하기 쉬운 도구가 선택됩니다: Jest + Testing Library (React), e2e를 위한 Playwright. 그래서 우리는 커버리지와 시장 출시 시간 간의 균형을 유지할 수 있습니다.
CI/CD + 코드 품질 자동화
모든 커밋은 안전성 검사를 트리거합니다. Type 체크(예: tsc --noEmit), Lint/포맷 체크, 단위 테스트, 스테이징으로 자동 배포를 수행하는 간단한 CI/CD 파이프라인이 설정됩니다. 일반 도구가 사용됩니다: GitHub Actions, Docker Compose.
코드에서 설정 분리하기
우리는 하드코딩을 피합니다 = 장기적인 고통. 모든 비밀/설정은 .env 또는 원격 설정(예: AWS SSM, Vercel envs)에 저장됩니다. 환경 기반 설정이 사용됩니다 (process.env.NODE_ENV). .env.*, API 키, 자격 증명 등을 커밋하는 것은 피합니다. 그리고 이들은 잘 문서화되어 있습니다.