왜 마크다운으로 업무 문서를 쓰는가
노션, Confluence, Google Docs 등 훌륭한 협업 도구가 많은데 굳이 마크다운을 쓰는 이유가 있습니다.
- 플랫폼 독립적: 어떤 서비스가 망하거나 요금 정책이 바뀌어도 내 문서는 그대로입니다.
- Git으로 버전 관리: 누가 언제 무엇을 바꿨는지 기록이 남습니다.
- 빠른 작성 속도: 마우스 없이 키보드만으로 서식을 적용할 수 있습니다.
- 검색 용이: 일반 텍스트 파일이라
grep, 파인더, VS Code 전체 검색이 잘 됩니다.
회의록 템플릿
회의록은 일관된 형식이 있어야 나중에 찾아보기 쉽습니다. 다음 템플릿을 팀 내 표준으로 쓰세요.
# 회의록 - [프로젝트명] 주간 동기화
**일시**: 2026-04-29 (화) 14:00 ~ 15:00
**장소**: 회의실 A / 온라인 (Google Meet)
**참석**: 홍길동, 김철수, 이영희
**작성**: 홍길동
---
## 안건
1. 지난 주 작업 리뷰
2. 이번 주 목표 설정
3. 블로커 공유
---
## 논의 내용
### 1. 지난 주 작업 리뷰
- 홍길동: 로그인 API 완성, 테스트 코드 작성 중
- 김철수: 디자인 시스템 1차 완료, 피그마 공유함
- 이영희: 기획서 v2 작성 완료, 검토 요청
### 2. 이번 주 목표
- [ ] 로그인/회원가입 프론트엔드 연동 (홍길동, ~5/2)
- [ ] 대시보드 컴포넌트 개발 시작 (김철수, ~5/3)
- [ ] 사용자 인터뷰 3건 진행 (이영희, ~5/2)
### 3. 블로커
- 결제 API 연동이 외부 업체 승인 대기 중 → 이영희가 다음 주까지 팔로우업
---
## 결정 사항
- 배포 주기: 격주 금요일로 고정
- 코드 리뷰는 PR 올린 후 24시간 내 완료
## 다음 회의
**2026-05-06 (화) 14:00**
결정 사항과 논의를 분리하기
나중에 회의록을 다시 볼 때 가장 궁금한 것은 "그래서 뭘 정했지?"입니다. 길게 오간 논의 내용과 최종 결정 사항을 위 템플릿처럼 별도 섹션으로 분리해두면 핵심을 빠르게 파악할 수 있습니다.
액션 아이템은 체크리스트와 표로
회의의 결과물은 결국 "누가, 무엇을, 언제까지"입니다. 이것을 체크리스트(- [ ])로 적으면 다음 회의에서 진행 상황을 그대로 체크하며 확인할 수 있습니다. 담당자와 기한을 함께 적는 것이 핵심입니다.
액션 아이템이 많은 회의라면 체크리스트와 함께 표로 정리하면 담당·기한·상태를 한눈에 볼 수 있습니다.
| 항목 | 담당 | 기한 | 상태 |
|------|------|------|------|
| 디자인 시안 공유 | 김OO | 6/3 | 진행 중 |
| API 명세 작성 | 이OO | 6/5 | 대기 |
다음 회의에서 이 표의 '상태'만 갱신하면 지난 회의 이후 무엇이 진행됐는지 그대로 추적됩니다.
결정 로그(Decision Log) 남기기
회의가 쌓이면 "그 결정을 언제, 왜 했더라?"가 헷갈립니다. 결정 사항 옆에 날짜와 근거(왜 그렇게 정했는지)를 한 줄 덧붙여두면 나중에 같은 논의를 반복하지 않게 됩니다. 결정의 배경까지 남기는 것이 단순 기록과의 차이입니다.
주간 보고서 템플릿
주간 보고서는 상사나 이해관계자에게 진행 상황을 공유하는 문서입니다. 핵심만 간결하게 담으세요.
# 주간 보고서 - 2026년 18주차 (4/28 ~ 5/2)
**작성자**: 홍길동
**팀**: 프론트엔드
---
## 이번 주 완료
- [x] 로그인 API 연동 및 에러 처리
- [x] 사용자 프로필 페이지 레이아웃
- [x] 크로스브라우저 테스트 (Chrome, Safari, Firefox)
## 다음 주 계획
- [ ] 대시보드 차트 컴포넌트 개발
- [ ] 성능 최적화 (Lighthouse 점수 90+ 목표)
- [ ] 접근성 검토 (WCAG 2.1 기준)
## 이슈 / 블로커
| 이슈 | 심각도 | 조치 |
|------|--------|------|
| Safari iOS 사파리에서 날짜 picker 오류 | 중 | 대안 라이브러리 검토 중 |
| 백엔드 API 응답 속도 느림 | 저 | 백엔드 팀에 이슈 제기 완료 |
## 메트릭
- 완료 태스크: 8 / 10
- PR 머지: 5건
- 코드 리뷰: 7건
프로젝트 기획서 구조
새 프로젝트를 시작할 때 빠르게 초안을 잡을 수 있는 구조입니다.
# [프로젝트명] 기획서
**버전**: 1.0
**작성일**: 2026-04-29
**상태**: 초안 / 검토 중 / 확정
---
## 배경 및 목적
(왜 이 프로젝트가 필요한가)
## 목표
- 정량 목표: ...
- 정성 목표: ...
## 범위 (Scope)
### In Scope (포함)
- ...
### Out of Scope (제외)
- ...
## 이해관계자
| 역할 | 담당자 | 책임 |
|------|--------|------|
| PM | 이영희 | 전체 조율 |
| 개발 | 홍길동 | 프론트엔드 |
| 디자인 | 김철수 | UI/UX |
## 일정
| 마일스톤 | 목표일 | 상태 |
|----------|--------|------|
| 기획 확정 | 5/10 | 진행 중 |
| 개발 완료 | 6/15 | 예정 |
| 출시 | 6/30 | 예정 |
## 리스크
| 리스크 | 확률 | 영향 | 대응 방안 |
|--------|------|------|-----------|
| 일정 지연 | 중 | 고 | 버퍼 2주 확보 |
공부 노트
강의 노트를 마크다운으로 정리하면 세 가지 장점이 있습니다. 첫째, 제목과 목록으로 내용의 구조가 한눈에 보입니다. 둘째, 텍스트 기반이라 검색이 쉽습니다. 셋째, 어떤 기기에서도 열리고 PDF로 변환해 출력하거나 공유하기도 편합니다.
# 자료구조 - 3주차: 스택과 큐
## 핵심 개념
- **스택(Stack)**: LIFO (Last In First Out)
- **큐(Queue)**: FIFO (First In First Out)
## 상세 정리
### 스택의 주요 연산
- push: 데이터 추가
- pop: 데이터 제거
## 외울 것 (시험 대비)
- [ ] 스택/큐 시간복잡도
- [ ] 활용 사례 3가지
## 질문 / 헷갈리는 점
- 큐와 덱(deque)의 차이?
공부 노트에 특히 유용한 문법
- 제목 계층: 과목 → 주차 → 개념 순으로
#,##,###를 쓰면 구조가 명확해집니다. - 체크리스트: 외울 항목, 과제 목록을
- [ ]로 관리하면 진도 체크가 됩니다. - 표: 비교가 필요한 개념(예: 정렬 알고리즘별 복잡도)은 표로 정리하면 한눈에 들어옵니다.
- 인용구: 교수님이 강조한 내용이나 핵심 정의를
>로 강조해 둡니다. - 코드 블록: 프로그래밍 과목이라면 예제 코드를 문법 강조와 함께 보관합니다.
복습과 시험 기간 활용
- "질문" 섹션 만들기: 헷갈리는 점을 따로 적어두고 해결하면 지웁니다.
- 나만의 요약: 강의 내용을 그대로 옮기지 말고 내 말로 다시 정리하면 기억에 오래 남습니다.
- 과목별 파일 분리: 한 파일에 다 넣지 말고 과목·주차별로 나누면 찾기 쉽습니다.
평소 마크다운으로 정리해두면 시험 직전에 "외울 것" 체크리스트와 표만 빠르게 훑어볼 수 있습니다. 필요하면 PDF로 내보내 인쇄하거나 태블릿에서 보세요.
파일 관리 체계
문서가 쌓이면 찾기 어려워집니다. 처음부터 폴더 구조를 잡아두세요.
docs/
├── meetings/
│ ├── 2026-04/
│ │ ├── 2026-04-01-킥오프.md
│ │ └── 2026-04-15-주간동기화.md
│ └── 2026-05/
├── specs/
│ ├── 기능명세서-v1.md
│ └── API-설계.md
├── reports/
│ ├── 2026-04-weekly.md
│ └── 2026-05-weekly.md
└── decisions/
└── 2026-04-29-기술스택-결정.md
특히 결정 기록(decision log)은 자주 간과되는데 나중에 "왜 이걸 이렇게 했지?"라는 질문에 답하는 데 매우 유용합니다.
마크다운 업무 문서의 한계와 보완
모든 것이 장점만 있지는 않습니다.
- 실시간 협업 어려움: Google Docs처럼 여러 명이 동시에 편집하기 어렵습니다. → Git 브랜치 전략으로 보완하거나 협업 시에는 HackMD, Notion을 병행하세요.
- 이미지 관리: 이미지 파일을 별도로 관리해야 합니다. → 저장소 내
assets/폴더를 만들어 같이 커밋하세요. - 기술 진입 장벽: 마크다운에 익숙하지 않은 팀원은 거부감을 느낄 수 있습니다. → 처음엔 이지 마크다운 같은 WYSIWYG 에디터로 시작하면 진입 장벽이 낮아집니다.
마크다운은 완벽한 도구가 아니지만 가볍고 이식성 높은 문서 형식으로서 장기적으로 가장 안정적입니다. 중요한 문서일수록 특정 플랫폼에 종속되지 않는 형식으로 보관하는 것이 현명합니다.
완성한 문서를 워드나 PDF로 제출할 계획이라면 마크다운을 워드·PDF로 내보낼 때 깨지는 것들을 먼저 확인하세요. 표와 접기에서 사고가 가장 많이 납니다.