Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

5.7 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack

title

Prettier

📌 한 줄 통찰 (The Karpathy Summary)

Prettier는 개발자가 작성한 소스 코드를 일관된 스타일로 자동 변환해 주는 '의견이 반영된(opinionated)' 코드 포맷터(Formatter)입니다 [1, 2]. 코드의 로직이나 구현 방식에는 관여하지 않고, 줄 바꿈, 공백, 들여쓰기 등 시각적이고 구조적인 뷰에만 초점을 맞추어 코드를 재작성합니다 [2-4]. 이를 통해 팀원 간의 코딩 컨벤션을 통일하여 코드 리뷰 시 불필요한 스타일 논쟁을 없애고, 개발자가 코드의 핵심 로직에 더욱 집중할 수 있도록 돕습니다 [5, 6].

📖 구조화된 지식 (Synthesized Content)

주요 역할 및 특징: 2016년에 등장한 Prettier는 코드가 예쁘게 보이도록 만드는 데 중점을 둔 도구로, 변경이 필요한 부분만 수정하는 것이 아니라 설정된 규칙에 따라 코드 전체의 구조적 뷰를 완전히 새로 작성합니다 [2, 4].
팀 협업 및 생산성 향상: Prettier를 도입하면 개발자가 코드를 작성할 때 스타일에 대한 고민을 덜 수 있고, 저장 시 자동으로 일관된 포맷으로 변환됩니다 [6]. 이는 팀원 간 코드 스타일 차이로 인한 혼란을 최소화하고, 리뷰 과정의 효율성을 크게 증가시킵니다 [6].
설정 및 관리 방법: 일반적으로 프로젝트 루트 경로에 .prettierrc (또는 .prettierrc.json) 파일을 생성하여 규칙을 정의하며, 포맷팅에서 제외할 파일은 .prettierignore에 지정합니다 [5, 7, 8]. 주요 설정 옵션으로는 한 줄의 최대 길이를 정하는 printWidth, 탭 너비를 정하는 tabWidth, 세미콜론 사용 여부를 정하는 semi, 작은따옴표 사용을 결정하는 singleQuote 등이 있습니다 [9, 10].
ESLint와의 통합 및 충돌 방지: 코드 퀄리티를 검사하는 Linter 도구인 ESLint에도 일부 포맷팅 기능이 존재하여, Prettier와 함께 사용할 경우 규칙 충돌이 발생할 수 있습니다 [11]. 이를 해결하기 위해 [[eslint-config-prettier|eslint-config-prettier]] 패키지를 사용하여 Prettier와 겹치는 ESLint의 포맷팅 규칙을 끄는 방법이 가장 강력히 권장됩니다 [11, 12]. 추가로 [[eslint-plugin-prettier|eslint-plugin-prettier]]를 설치하여 Prettier의 포맷팅 오류를 ESLint의 오류로 통합 출력하게 만들 수도 있습니다 [11, 13].
보안 취약점 (공급망 공격) 사례: 2025년 7월, Prettier와 ESLint의 충돌을 방지하는 필수 라이브러리인 eslint-config-prettier 패키지가 공급망 공격(CVE-2025-54313)의 표적이 되었습니다 [14, 15]. 관리자의 탈취된 npm 토큰을 통해 악성 버전이 배포되었으며, 이는 주로 Windows 시스템의 개발자 기기나 CI 호스트에서 원격 코드 실행(RCE)을 시도하도록 설계된 악성 설치 스크립트를 포함하고 있었습니다 [16].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 지식 연결 (Graph)

Related Topics: ESLint, Formatter
Projects/Contexts: eslint-config-prettier, eslint-plugin-prettier, husky, lint-staged
Contradictions/Notes: ESLint와 Prettier를 통합할 때 사용하는 eslint-plugin-prettier에 대해 의견이 갈립니다. 소스 [17]는 해당 플러그인을 사용하면 하나의 설정 파일에서 관리할 수 있고 자동 수정(--fix)이 편리하여 선호한다고 밝히지만, 소스 [18]에서는 에디터에 불필요한 빨간 밑줄이 과도하게 생기고 단독 사용보다 속도가 느려진다는 이유로 공식 문서에서도 권장하지 않는다며 플러그인 사용을 배제하는 방식을 채택합니다.

Last updated: 2026-04-18

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.7 KiB Raw Blame History