1. 문서 한 장의 구조

문서마다 모양이 다르면 위키를 훑을 수 없습니다. 어느 문서를 열어도 같은 자리에 같은 정보가 있어야 합니다. 이 절에서 그 틀을 정합니다.

1.1 네 부분

모든 위키 문서는 네 부분으로 이뤄집니다.

---
title: 경쟁사 A
type: entity
updated: 2026-08-16
sources: [raw/2026-08-14-competitor-a-pricing.pdf]
---

# 경쟁사 A

한 줄 요약: 국내 온라인 강의 서비스. 14일 무료 체험과 팀 결제 중심.

## 기본 정보
2019년 설립, 누적 수강생 40만 명. (raw/2026-08-14-competitor-a-pricing.pdf)

## 요금 구조
개인 월 19,000원, 팀 플랜은 5계정부터. (raw/2026-08-14-competitor-a-pricing.pdf)

[추론] 팀 최소 인원을 5명으로 잡은 것은 소규모 스터디 모임보다
기업 교육 담당자를 노린 설계로 보입니다.

## 관련 문서
- [[free-trial]] 무료 체험 정책
- [[pricing-comparison]] 경쟁사 비교

프론트매터는 기계가 읽는 부분입니다. Obsidian이 문서 속성으로 인식하고, 10장의 Dataview가 이걸로 표를 만들고, 8장의 린트가 updated 날짜로 낡은 문서를 골라냅니다.

한 줄 요약은 색인에 그대로 들어갑니다. 이 한 줄을 잘 쓰면 색인이 쓸모 있어지고, 대충 쓰면 색인이 파일 목록과 다를 바 없어집니다.

본문은 소제목으로 나뉩니다. 문서가 길어졌을 때 소제목 단위로 쪼개게 되므로, 소제목은 처음부터 독립적인 덩어리로 잡습니다.

관련 문서는 링크 목록입니다. 본문 안에도 링크를 걸지만, 아래에 모아 두면 이 문서가 위키의 어디에 걸려 있는지 한눈에 보입니다.

1.2 한 줄 요약 쓰는 법

한 줄 요약은 문서의 제목을 다시 쓰는 자리가 아닙니다. 이 문서를 열어야 할지 말지를 판단할 수 있게 해 주는 줄입니다.

나쁜 예: 경쟁사 A에 대한 정보를 정리한 문서입니다.

이건 아무것도 알려주지 않습니다. 제목만 봐도 아는 내용입니다.

좋은 예: 국내 온라인 강의 서비스. 14일 무료 체험과 팀 결제 중심. 2026년 8월 팀 최소 인원을 5명에서 3명으로 낮춤.

이건 이 문서를 열지 말지 판단할 수 있게 합니다. 무료 체험을 조사 중이라면 열고, 다른 걸 찾는 중이라면 넘어갑니다.

규칙 문서에 한 줄 넣어 둡니다.

한 줄 요약에는 그 대상을 다른 것과 구별하는 특징을 적습니다.
"~에 대한 정리"처럼 제목을 반복하는 문장은 쓰지 않습니다.

1.3 출처 다는 자리

출처는 문장 끝에 답니다. 문단 끝도 아니고 문서 끝도 아닙니다.

같은 출처가 연달아 나오면 문단마다 한 번씩만 달아도 됩니다. 다만 출처가 바뀌는 지점에는 반드시 표시가 있어야 합니다.

## 요금 구조

개인 월 19,000원, 팀 플랜은 5계정부터입니다.
연간 결제 시 20% 할인이 적용됩니다. (raw/2026-08-14-competitor-a-pricing.pdf)

팀 플랜 최소 인원은 2026년 8월에 5명에서 3명으로 바뀌었습니다.
(raw/2026-08-20-competitor-a-blog.md, 2026-08-20 발행)

두 문단의 출처가 다르므로 각각에 붙었습니다. 나중에 "5명에서 3명으로 바뀌었다"는 문장이 의심스러우면 그 자리에서 어느 자료를 열어야 하는지 알 수 있습니다.

1.4 표시 세 가지

문장의 성격을 나누는 표시를 정해 둡니다. 5장에서 하나씩 나왔던 것들을 모으면 이렇습니다.

> 확인 필요: 로 시작하는 인용 줄은 성격이 조금 다릅니다. 문장의 종류가 아니라 처리해야 할 일을 표시합니다.

> 확인 필요: 팀 최소 인원이 자료마다 다릅니다.
> raw/2026-08-14-pricing.pdf 는 5명, raw/2026-08-20-blog.md 는 3명.
> 후자가 최근이지만 공식 페이지 확인이 필요합니다.

Obsidian에서는 이 인용 표시가 회색 상자로 보여서 본문과 잘 구별됩니다. 문서를 훑을 때 눈에 바로 걸립니다.

1.5 문서 길이

한 문서가 화면 세 쪽을 넘으면 나눌지 검토합니다. 이 기준은 두 가지 이유에서 나왔습니다.

사람이 훑을 수 있는 한계입니다. 세 쪽이 넘으면 위에 뭐가 있었는지 잊습니다.

AI가 정확하게 고칠 수 있는 한계이기도 합니다. 문서가 길수록 갱신할 때 엉뚱한 자리를 고치거나 중복된 문장을 더하는 일이 늘어납니다.

다만 기계적으로 나누지는 않습니다. 나누는 기준은 다음 절들에서 다룹니다.

1.6 기존 문서를 새 틀에 맞추기

지금까지 만든 문서들이 이 틀과 다를 수 있습니다. 한 번에 맞춥니다.

wiki/ 안의 모든 문서를 아래 틀에 맞게 고쳐줘.

1. 프론트매터: title, type, updated, sources 네 개.
   sources는 그 문서가 참조한 raw/ 파일 목록.
2. 제목 바로 아래에 '한 줄 요약:' 줄.
   그 대상을 다른 것과 구별하는 특징을 적을 것.
3. 맨 아래에 '## 관련 문서' 절과 [[링크]] 목록.

내용은 바꾸지 말고 틀만 맞춰줘.
고치기 전에 몇 개 문서가 바뀌는지 먼저 알려줘.

마지막 줄이 안전장치입니다. 문서 스무 장을 한꺼번에 고치는 작업이니 규모를 먼저 확인합니다. 10장에서 Git을 붙이면 이런 대규모 정리를 훨씬 마음 놓고 할 수 있습니다.

다음 절에서 문서를 잇는 링크를 다룹니다.