# [[프론트엔드 및 Node.js 개발 워크플로우|프론트엔드 및 Node.js 개발 워크플로우]]

## 📌 Brief Summary
프론트엔드 및 Node.js 개발 워크플로우는 소스 코드의 품질, 일관성, 그리고 보안을 자동화된 방식으로 유지하기 위해 일련의 도구들을 파이프라인에 결합하는 과정입니다. 주축이 되는 도구로는 코드 에러를 정적으로 분석하는 ESLint와 코드 스타일을 자동으로 정렬해주는 Prettier가 있으며, 이를 Git 훅(Git Hooks) 관리 도구인 Husky와 변경된 파일만 검사하는 lint-staged를 통해 커밋 전에 강제합니다. 최근에는 이러한 파이프라인과 IDE에 AI 기반의 정적 애플리케이션 보안 테스트(SAST)를 결합하여 취약점을 조기에 탐지하고 자동 수정하는 체계가 필수적으로 자리 잡고 있습니다.

## 📖 Core Content
*   **코드 품질 및 스타일 자동화 도구 (ESLint & Prettier)**
    자바스크립트 및 타입스크립트 기반의 프론트엔드와 Node.js 환경에서는 코드 품질과 스타일을 일관되게 유지하기 위해 ESLint와 Prettier를 핵심 도구로 사용합니다 [1, 2]. ESLint는 문법적 오류와 잠재적 버그, 안티 패턴을 찾아내고 규칙을 강제하는 린터(Linter)이며, Prettier는 줄 바꿈, 공백, 들여쓰기 등의 코드 스타일을 일관되게 변환해주는 포매터(Formatter)입니다 [1, 3, 4]. 이 두 도구를 함께 사용할 때 포맷팅 역할이 겹쳐 충돌이 발생할 수 있는데, 이를 방지하기 위해 `eslint-config-prettier` 패키지를 사용하여 Prettier와 충돌하는 ESLint 규칙을 비활성화하는 방식이 표준으로 권장됩니다 [5-7].
    
*   **Git 훅을 통한 검증 자동화 (Husky & lint-staged)**
    개발자가 컨벤션에 맞지 않는 코드를 저장소에 커밋하는 것을 방지하기 위해 Git 훅(Git Hooks)을 자동화하는 Husky와 lint-staged가 폭넓게 사용됩니다 [8, 9]. Husky는 `pre-commit`이나 `pre-push` 등의 훅을 쉽게 공유하고 설정하게 해주며, lint-staged는 전체 코드베이스가 아닌 커밋 대기 중인 '스테이징된(staged) 파일'에 대해서만 검사와 포맷팅을 실행하도록 오케스트레이션하여 실행 속도를 획기적으로 높입니다 [9-11]. 이 설정은 `package.json`의 `prepare` 스크립트와 연동되어 팀원 누구나 의존성을 설치할 때 동일한 검증 파이프라인을 구축하게 해줍니다 [12, 13].

*   **모노레포 환경에서의 워크플로우 구성**
    React, Next.js 등 다양한 애플리케이션과 공유 라이브러리를 단일 저장소에서 관리하는 Turborepo 같은 모노레포(Monorepo) 환경에서는 린팅 설정의 파편화와 중복을 막기 위해 중앙집중식 관리를 수행합니다 [14, 15]. 중앙 패키지(예: `@repo/eslint-config`)에 Base, Next.js, 라이브러리 용의 사전 설정(preset)을 정의해두고, 각 개별 패키지에서는 이를 상속하여 사용합니다 [16-18]. 이후 프로젝트 루트 디렉토리에서 lint-staged를 실행할 때, 오케스트레이션 설정을 통해 변경된 파일이 어느 패키지에 속하는지 파악하고 각 패키지의 린팅 규칙을 독립적으로 적용함으로써 유지보수성을 극대화합니다 [18-20].

*   **정적 애플리케이션 보안 테스트(SAST) 및 AI의 결합**
    코드 품질 검증과 함께 Snyk Code, SonarQube, Checkmarx와 같은 SAST 도구들이 IDE 및 CI/CD 파이프라인에 통합되어 실시간으로 보안 취약점을 점검합니다 [21-23]. 기존의 단순 패턴 매칭을 넘어, 최근 워크플로우에는 LLM과 기계학습(ML)을 기반으로 한 AI 에이전트가 도입되어 파일 간의 데이터 흐름(Interfile analysis)이나 XSS, SQL 인젝션, 하드코딩된 비밀번호 등 복잡한 문맥의 취약점을 탐지합니다 [24-26]. 나아가 발견된 오류에 대해 단순 경고를 넘어 AI 기반의 자동 수정(Auto-fix) 코드를 제안하여 개발자가 즉각적으로 코드를 리팩토링하고 병합할 수 있도록 돕습니다 [27-29].

*   **개발 워크플로우 내 공급망 보안 위협**
    개발 워크플로우를 구성하는 도구 자체의 보안 검증 또한 중요합니다. 실제로 워크플로우 구축 시 가장 흔하게 사용되는 `eslint-config-prettier` 패키지가 2025년에 공급망 공격(CVE-2025-54313)의 타겟이 된 사례가 있습니다 [30-32]. 관리자의 토큰 탈취를 통해 배포된 악성 버전은 `npm install` 실행 시 윈도우(Windows) 개발자 머신에 원격 코드 실행(RCE)을 가능하게 하는 악성 DLL을 드롭하도록 조작되어 있어, 코드 검증 도구와 서드파티 패키지 사용에 대한 지속적인 보안 및 의존성 관리가 필수적임을 시사합니다 [31-33].

## 🔗 Knowledge Connections
- **Related Topics:** [[ESLint|ESLint]], [[Prettier|Prettier]], [[Husky|Husky]], [[lint-staged|lint-staged]], [[정적 애플리케이션 보안 테스트 (SAST)|정적 애플리케이션 보안 테스트 (SAST)]], [[공급망 공격 (Supply Chain Attack)|공급망 공격 (Supply Chain Attack)]]
- **Projects/Contexts:** [[React 및 Next.js 개발 환경|React 및 Next.js 개발 환경]], [[Turborepo 기반 모노레포 워크플로우|Turborepo 기반 모노레포 워크플로우]]
- **Contradictions/Notes:** ESLint와 Prettier를 결합할 때, `eslint-plugin-prettier`를 사용하여 Prettier를 ESLint 규칙의 일부로 실행하는 방식이 존재하지만, Prettier 공식 문서 및 실무 환경에서는 성능 저하 문제와 에디터 내 과도한 경고(빨간 밑줄) 발생 등의 피로도 문제로 인해 `eslint-config-prettier`를 활용해 역할(규칙 검사는 ESLint, 포맷팅은 Prettier)을 명확히 분리하는 것을 가장 권장합니다 [5, 34, 35].

---
*Last updated: 2026-04-18*