Files

T

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

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

5.0 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

Parse dont validate

📌 한 줄 통찰 (The Karpathy Summary)

'Parse, don't validate(검증하지 말고 파싱하라)'는 프로그램의 경계에서 타입이 없거나 느슨한 데이터를 잘 정의된 타입의 데이터로 변환하는 소프트웨어 설계 철학입니다[1]. 코드 전반에 걸쳐 데이터의 유효성을 반복적으로 검사하는 대신, 시스템 진입점에서 단 한 번 파싱하여 안전한 타입으로 만듭니다[1]. 이를 통해 유효성 검사 로직의 파편화를 막고 타입 검사기의 정적 분석 능력을 극대화하여 코드의 예측 가능성과 안정성을 높입니다[2, 3].

📖 구조화된 지식 (Synthesized Content)

기본 원칙 및 파싱 흐름: Alexis King의 동명 아티클을 통해 널리 알려진 이 개념은 시스템의 경계(입구 및 출구)에서 입력 데이터를 한 번 파싱하는 것을 핵심으로 합니다[1, 2]. 이 파싱 단계에서 데이터의 유효성 검사와 변환이 동시에 이루어지며, 이후의 애플리케이션 흐름에서는 완전히 타입이 지정되고 검증된 데이터만을 사용하게 됩니다[1].
수비적 프로그래밍(Defensive Programming)의 정점: 단순히 데이터의 유효성 여부만 확인(Validate)하고 끝내는 것이 아니라, 데이터를 더 구체적이고 신뢰할 수 있는 타입의 객체로 변환(Parse)하여 시스템 내부로 전달합니다[3]. 이는 의도하지 않은 불확실한 데이터의 유입을 원천적으로 차단하는 견고한 아키텍처적 방어막 역할을 합니다[3].
제어 흐름(Control flow)과 개발자 경험 향상: 유효성 검사 로직을 시스템 경계에만 배치함으로써, 비즈니스 로직 곳곳에 검증 코드가 어지럽게 흩어지는 것을 방지할 수 있습니다[2]. 결과적으로 타입 시스템의 정적 분석에 무거운 작업을 위임하여 개발자의 신뢰를 높이고, 관리해야 할 코드의 양(Code volume)과 복잡도를 줄이는 데 크게 기여합니다[2, 4].
구현 방법 및 생태계 도구: 이 철학을 실현하기 위해 Zod와 같은 런타임 유효성 검사/파싱 라이브러리가 자주 활용됩니다[3, 5]. 구체적으로는 Zod 등을 통해 알 수 없는(Unknown) 데이터를 잘 알려진 타입으로 변환하며, 런타임 데이터에 Branded Types를 부여하여 시스템 내부로 전달하는 것이 이 철학을 완벽히 실현하는 구체적 방법론입니다[3, 5].

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

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

🔗 지식 연결 (Graph)

Related Topics: Branded Types, Zod, Defensive Programming, Static Analysis, Structural Typing
Projects/Contexts: API Boundary Handling, State Management
Contradictions/Notes: 소스 내에서 이 철학에 대한 상반된 주장이나 모순은 발견되지 않습니다. 오히려 상태 관리(State management) 문제나 복잡성 증가를 완화하는 TypeScript의 핵심 모범 사례 중 하나로 강력히 권장됩니다[1, 6].

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.0 KiB Raw Blame History