숏컷 코드

| 항목 | 설명 |
| --- | --- |
| CPU | 계산 담당 |
| Memory | 데이터 임시 저장 |

문법

Markdown 표는 GFM 확장이라 CommonMark 표준에는 포함되지 않는다

Markdown 표 문법은 GitHub Flavored Markdown(GFM)에서 정의한 확장이다. GitHub, GitLab, 대부분의 정적 사이트 빌더, 많은 Markdown 편집기에서 지원되지만, CommonMark 표준 파서 단독으로는 표를 인식하지 못한다. pandoc으로 변환하거나 순수 CommonMark 환경을 대상으로 문서를 작성할 때는 표 지원 여부를 먼저 확인해야 한다. 지원이 불확실하면 bullet 목록 + bold 헤더처럼 표를 흉내 낸 텍스트 구조가 더 안전한 대안이다.

| 기준 | 프로세스 | 스레드 |
| --- | --- | --- |
| 메모리 | 독립적 | 공유 가능 |
| 비용 | 큼 | 상대적으로 작음 |
| 전환 | 무거움 | 더 가벼움 |

표는 비교·요약에 강하고 서술형 설명에는 약하다

표의 강점은 같은 기준(열)으로 여러 항목(행)을 한눈에 비교하게 만드는 것이다. "정의", "비교", "규칙 정리"처럼 열 기준이 분명할 때 가장 효과적이다. 반대로 각 항목마다 설명 길이가 다르거나 항목 간 관계가 복잡한 경우에는 표보다 bullet 목록이나 ### 소제목 방식이 더 읽기 쉽다. 표 셀 안에 긴 문장이나 여러 줄 목록을 넣으면 소스 가독성이 급격히 떨어진다.

<!-- 표에 적합: 비교 기준이 명확 -->
| 항목 | 값 |
| --- | --- |
| 기본 포트 | 8080 |
| 프로토콜 | HTTP/1.1 |

<!-- 표에 부적합: 설명이 길고 항목마다 다름 -->
<!-- → bullet 목록이나 ### 섹션으로 분리 권장 -->

구분선 행의 열 수와 헤더 열 수가 일치해야 안전하다

GFM 파서는 헤더 행과 구분선 행, 데이터 행의 열 수가 일치하지 않아도 렌더링을 시도하지만, 동작이 파서마다 다르고 나머지 셀이 비거나 잘릴 수 있다. 실무에서는 항상 열 수를 맞추는 것이 렌더러 간 안정성을 높이는 기본 습관이다. 편집기의 Markdown 표 정렬 플러그인(예: Prettier, markdownlint)을 활용하면 실수를 줄일 수 있다.

<!-- 안전: 열 수 일치 -->
| A | B | C |
| --- | --- | --- |
| 1 | 2 | 3 |

<!-- 위험: 헤더 3열, 데이터 2열 -->
| A | B | C |
| --- | --- | --- |
| 1 | 2 |

모바일과 좁은 화면에서는 표 셀을 짧게 유지해야 가독성이 보장된다

Markdown 표는 HTML로 변환 후 overflow-x: scroll 없이는 모바일 화면을 벗어나는 경우가 많다. 셀 안에 긴 URL, 긴 코드 조각, 여러 줄 설명을 담으면 좁은 화면에서 읽기 어려워진다. 표는 짧고 간결한 셀 값을 위해 설계된 형식이라는 점을 고려해, 복잡한 내용은 표 밖 code block이나 목록으로 분리하는 것이 좋다.

실무에서는 "표가 되긴 하는데 읽기 너무 어려운" 상태가 흔하다. 이 경우 문제는 문법이 아니라 형식 선택이다. 열 기준이 모호하거나 셀 설명 길이가 길어지기 시작하면 표보다 소제목과 목록이 낫다.

선택 기준

주의할 점

| 단계 | 설명 |
| --- | --- |
| 설치 | 의존성을 설치하고 환경 변수를 확인한 뒤 서버를 실행하고 로그를 보고... |

문법상 가능해도 이런 셀은 표가 아니라 긴 문단을 억지로 칸에 넣은 상태에 가깝습니다. 이때는 표를 버리는 편이 더 읽기 쉽습니다.