숏컷 코드

| Left  | Center | Right |
| :---- | :----: | ----: |
| 이름  |   a    |     1 |
| 경로  |   b    |    12 |
| 특수  |  A \| B |   100 |

문법

정렬은 구분선의 콜론 위치로 결정하며 시각적 정렬과 별개로 동작한다

GFM 표에서 열 정렬은 헤더와 데이터 행 사이 구분선 행의 콜론 위치로 제어한다. :---는 왼쪽 정렬, :---:는 가운데 정렬, ---:는 오른쪽 정렬이다. 콜론 없이 ---만 쓰면 렌더러 기본값(보통 왼쪽)이 적용된다. 중요한 점은 소스에서 파이프 문자로 맞춘 시각적 정렬은 렌더링 결과와 무관하다는 것이다. 소스 정렬이 예쁘더라도 구분선에 콜론이 없으면 가운데 정렬이 되지 않는다.

| 항목 | 수량 | 가격 |
| :--- | :---: | ---: |
| CPU  |   2   |  300 |
| RAM  |   4   |   80 |

셀 안의 pipe 문자는 반드시 escape해야 열 구분자와 충돌하지 않는다

표의 열은 | 문자로 구분되기 때문에 셀 내용에 |를 그대로 쓰면 파서가 새 열의 시작으로 해석한다. \| 처럼 backslash를 앞에 붙여 escape하면 파이프 문자가 열 구분자가 아닌 리터럴로 처리된다. 논리 연산자(||), 쉘 파이프, 정규식 교체 기호 등이 자주 등장하는 기술 문서에서 특히 중요하다. 대안으로 셀 안에 <code>&#124;</code> HTML 엔티티를 쓰는 방법도 있지만, 소스 가독성은 \| 가 더 낫다.

| 연산 | 예시 |
| :--- | :--- |
| OR 연산자 | A \| B |
| 파이프 명령 | `ls \| grep txt` |

셀 안에 인라인 Markdown 문법은 대부분 동작하지만 복잡한 구조는 피해야 한다

GFM 표 셀 안에서는 굵게(**), 기울임(*), 인라인 코드(`), 링크([텍스트](url)) 같은 인라인 Markdown이 동작한다. 그러나 코드 블록, 여러 줄 텍스트, 목록 같은 블록 레벨 요소는 표 셀 안에서 사용할 수 없다. 억지로 넣으면 파서가 표 구조를 벗어났다고 판단해 나머지 문서 렌더링이 틀어질 수 있다. 복잡한 내용은 표 밖에서 설명하고 표 셀에는 짧은 참조만 남기는 것이 안전하다.

| 항목 | 설명 |
| :--- | :--- |
| 명령어 | `npm run build` |
| 문서 | [설치 가이드](./install.md) |
| 상태 | 완료 |

소스의 파이프 정렬은 가독성을 위한 선택이지 필수 사항이 아니다

많은 Markdown 가이드가 소스에서 파이프를 열에 맞춰 정렬하는 패턴을 보여 주지만, 이것은 렌더링에 영향을 주지 않는 순수한 소스 가독성 선호다. 파이프를 정렬하면 보기 좋지만, 셀 내용 길이가 자주 바뀌는 문서에서는 매번 정렬을 유지하는 편집 비용이 크다. Prettier, markdownlint 같은 자동화 도구를 쓰면 정렬 일관성을 유지하면서 편집 부담을 줄일 수 있다.

또한 표 카드와 자주 섞이는 오해는 "표 안에서도 모든 Markdown이 되겠지"라는 기대다. 인라인 수준까지만 안전하다고 보고, 줄바꿈·목록·코드 블록이 필요해지는 순간 표를 벗어나는 편이 낫다.

선택 기준

주의할 점

| 항목 | 명령 |
| --- | --- |
| 설치 | ```bash\nnpm install\n``` |

이런 식의 블록 코드는 표 셀 안에서 안정적으로 다루기 어렵습니다. 셀에는 짧은 인라인 코드만 두고, 긴 예시는 표 밖으로 빼는 편이 안전합니다.