짚어봄

음력 생일, 올해 양력으로 며칠일까 — 공식 조회 경로와 평달·윤달 차이

짚어봄 — Tue, 27 Oct 2026 10:35:26 +0900

가족이나 내 생일이 음력이면 해마다 양력 날짜가 바뀌어서 달력에 미리 표시해 두기가 번거롭습니다. 인터넷에 변환기가 많지만, 기준이 되는 곳은 한국천문연구원입니다. 이 글에서는 천문연구원의 공개 페이지에서 음력 생일의 양력 날짜를 찾는 경로를 정리하고, 같은 날짜를 맥의 달력 계산으로 따로 구해 결과가 맞는지 대조했습니다.

확인일 2026-10-21. 예시는 가상의 생일(음력 6월 15일)이며, 실제 생일을 넣어도 같은 순서로 찾을 수 있습니다.

공식 조회 경로: 여러 해를 한 번에

한국천문연구원 천문우주정보 사이트(astro.kasi.re.kr)의 음양력변환계산 페이지에는 탭이 네 개 있습니다. 음력 생일에는 두 가지가 쓸모 있습니다.

특정 음력일 찾기: 양력 년도 범위(예: 2026~2035)와 음력 월·일을 넣으면 해마다의 양력 날짜와 요일을 목록으로 보여 줍니다. 몇 년 치를 한 번에 달력에 옮길 때 편합니다.
음력을 양력으로: 한 해만 볼 때 씁니다. 평달, 윤달 말고도 '평달인지 윤달인지 알지 못함'을 고를 수 있습니다.

입력할 수 있는 범위는 -59년부터 2050년까지로 안내돼 있습니다. 로그인 없이 쓸 수 있습니다. 페이지 코드를 보면, '음력을 양력으로' 탭은 그해에 같은 달 윤달이 있을 때 고르지 않은 쪽(평달 또는 윤달) 결과도 '[부가정보]'로 함께 보여 주도록 되어 있습니다. '특정 음력일 찾기'에서 해당하는 날이 없으면 '해당하는 데이터가 없습니다'라는 안내가 뜹니다.

음력 생일의 해마다 양력 날짜를 찾는 경로(메뉴 이름을 옮겨 직접 그린 그림)

평달과 윤달, 무엇이 다른가

음력은 몇 해에 한 번 같은 달이 두 번 들어가는데, 두 번째 달을 윤달이라고 합니다. 그래서 윤달이 있는 해에는 같은 '음력 6월 15일'이 두 번 있습니다. 2025년에는 윤6월이 있어서 평달 6월 15일은 양력 7월 9일, 윤달 6월 15일은 양력 8월 8일로 한 달 가까이 차이가 났습니다. 생일을 입력할 때 평달·윤달을 잘못 고르면 엉뚱한 날짜가 나오는 이유입니다.

같은 음력 6월 15일의 해마다 양력 날짜(움직이는 그림, 약 9초)

앞으로 윤달이 드는 해는 아래와 같습니다. 맥의 달력 계산으로 뽑았고, 2028년과 2033년은 천문연구원 조회 결과와도 같았습니다.

해	윤달	양력 기간
2028년	윤5월	6월 23일 ~ 7월 21일
2031년	윤3월	4월 22일 ~ 5월 20일
2033~2034년	윤11월	2033년 12월 22일 ~ 2034년 1월 19일

직접 대조한 결과: 10년 치 모두 일치

천문연구원의 '특정 음력일 찾기'로 음력 6월 15일(평달)을 2026~2035년 범위에서 조회했고, 같은 날짜를 맥에 들어 있는 한국 음력 달력 계산으로 따로 구했습니다. 아래 10개 날짜가 모두 같았습니다. 같은 기간을 윤달로 조회하면 결과가 없었는데, 이 기간에는 윤6월이 들지 않기 때문입니다.

해	음력 6월 15일(평달) → 양력	맥 계산과 대조
2026년	7월 28일 (화)	같음
2027년	7월 18일 (일)	같음
2028년	8월 5일 (토)	같음
2029년	7월 26일 (목)	같음
2030년	7월 15일 (월)	같음
2031년	8월 2일 (토)	같음
2032년	7월 21일 (수)	같음
2033년	7월 11일 (월)	같음
2034년	7월 30일 (일)	같음
2035년	7월 19일 (목)	같음

다른 변환기를 쓸 때 주의할 점

음력에는 한국 기준과 중국 기준이 있고, 두 계산이 드물게 하루씩 어긋납니다. 맥의 달력 계산으로 1950~2050년을 비교해 보니 두 음력이 다른 날이 1,378일 있었고, 2027년 설날이 대표적입니다. 한국 기준은 2월 7일, 중국 기준은 2월 6일입니다. 천문연구원은 '음양력변환계산'과 '월별음양력' 두 페이지 모두 2027년 2월 7일을 음력 1월 1일로, 2월 6일을 음력 2026년 12월 30일로 보여 줬습니다. 변환 결과가 하루 다르게 나오면 그 도구가 어느 기준으로 계산하는지 의심해 보고, 천문연구원 결과로 확인하세요.

한국 음력과 중국 음력이 하루 다른 예(직접 계산·조회한 값으로 그린 표)

출처

한국천문연구원 천문우주정보, 음양력변환계산 (조회일 2026-10-21)
한국천문연구원 천문우주정보, 월별음양력 (2027년 2월 조회, 확인일 2026-10-21)
직접 확인: macOS 27.0.1 Foundation 달력 계산(한국 음력 dangi, 중국 음력 chinese) (2026-10-21)

맥 PDF 용량 줄이기 — '파일 크기 줄이기'는 사진 PDF와 글자 PDF에서 결과가 같을까

짚어봄 — Mon, 26 Oct 2026 16:14:45 +0900

메일에 PDF를 첨부하려는데 용량이 너무 크다고 거절당하면, 맥에서는 따로 프로그램을 깔지 않고 기본 앱 '미리보기'의 파일 크기 줄이기로 줄일 수 있습니다. 그런데 이 기능이 정확히 무엇을 줄이는지는 잘 알려져 있지 않습니다. 그래서 이 맥에 들어 있는 필터 파일의 설정값을 직접 열어 보고, 사진 PDF와 스캔한 것 같은 PDF를 직접 만들어 같은 필터를 적용해 크기와 화질을 비교했습니다.

확인 환경: Mac mini, macOS 27.0.1(빌드 26A434). 확인일 2026-10-21.

미리보기에서 줄이는 방법

PDF를 미리보기로 엽니다.
메뉴에서 파일 > 내보내기를 고릅니다.
Quartz 필터 팝업 메뉴에서 파일 크기 줄이기를 고르고 저장합니다.

Apple 안내에도 "압축하면 PDF 품질이 원본보다 저하될 수 있습니다"라고 적혀 있습니다. 원본은 지우지 말고 새 이름으로 저장하는 편이 안전합니다. 같은 Quartz 필터는 맥의 'ColorSync 유틸리티'에서도 PDF를 열고 창 아래 필터 팝업 메뉴에서 골라 '적용'을 눌러 쓸 수 있습니다.

이 기능이 실제로 하는 일: 사진만 줄인다

Quartz 필터는 맥 안의 필터 파일로 들어 있습니다. 이 맥의 /System/Library/Filters 폴더에서 영문 이름이 'Reduce File Size'인 필터 파일을 열어 보니, 설정은 모두 사진(이미지)에 관한 것이었습니다.

이 맥의 '파일 크기 줄이기' 필터 설정값(실제 파일을 옮겨 그림)

사진을 JPEG로 다시 압축하고, 품질은 0.7(70%)입니다.
종이 1인치에 144픽셀이 넘는 사진은 144픽셀로 줄입니다.
사진의 긴 변이 2400픽셀을 넘으면 2400픽셀로 맞춥니다.

그래서 글자만 있는 PDF에는 이 필터가 줄일 대상이 없습니다. 이번에 만든 글자 PDF(9쪽, 83KB)에는 이미지가 하나도 없었습니다. 이런 파일은 원래 작기 때문에 그대로 보내는 편이 낫습니다.

직접 만든 PDF로 비교한 결과

사진 PDF는 직접 만든 4000×3000픽셀 사진 4장을 가로 A4 4쪽에 넣었고, 스캔 같은 PDF는 글자 문서를 300dpi 이미지로 만들어 A4 3쪽에 넣었습니다. 여기에 위 필터 파일을 맥 기본 PDF 기능(PDFKit)으로 적용했습니다. 미리보기 앱 화면에서 직접 누른 결과가 아니라는 점은 감안해 주세요.

사진 PDF와 스캔 같은 PDF의 줄어든 크기(실험 값으로 그림)

시험 파일	원본	줄인 뒤	사진 크기 변화
사진 PDF(4쪽)	12.1MB	1.75MB(−86%)	4000×3000 → 1586×1189
스캔 같은 PDF(3쪽)	1.94MB	1.27MB(−34%)	2481×3507 → 1190×1682
글자 PDF(9쪽)	83KB	줄일 이미지 없음

줄어든 사진 크기는 필터 설정과 정확히 맞았습니다. 스캔본은 A4 폭 8.27인치 × 144 ≈ 1190픽셀, 사진은 종이에서 차지한 폭 약 11인치 × 144 ≈ 1586픽셀입니다. 즉 이 필터는 '파일을 몇 % 줄이기'가 아니라 종이에 찍힐 크기 기준으로 사진을 144dpi까지 낮추는 방식입니다. 사진 PDF가 훨씬 많이 줄어든 이유는 원본 사진이 종이 크기에 비해 훨씬 촘촘했기 때문입니다(약 363dpi → 144dpi). 반대로 원래 144dpi보다 거친 사진이라면 줄어드는 폭이 작을 것입니다(설정값으로 본 추론, 이번엔 시험하지 않음).

한 번 더 줄이면 더 작아질까?

이미 줄인 파일에 같은 필터를 한 번 더 적용해 봤습니다. 스캔 같은 PDF는 1.27MB 그대로였고, 사진 PDF는 오히려 12.3MB로 커졌습니다. 다시 저장하면서 사진이 JPEG가 아니라 무손실 방식으로 저장됐기 때문입니다. 줄이기는 원본에서 한 번만 하는 편이 안전합니다.

스캔 문서는 글자가 읽히는지 꼭 확인

스캔한 문서는 글자도 이미지라서 함께 흐려집니다. 같은 부분을 4배로 확대해 비교해 보면, 줄인 파일은 글자 테두리가 조금 뭉개지지만 이 정도 크기의 글자는 읽는 데 문제가 없었습니다. 작은 글씨나 도장, 서명이 들어간 스캔본이라면 줄인 파일을 열어 실제로 읽히는지 먼저 확인하세요.

원본과 줄인 파일의 글자 확대 비교(움직이는 그림, 약 9초)

출처

Apple 사용 설명서, Mac용 미리보기에서 PDF 크기 줄이기 (확인일 2026-10-21)
Apple 사용 설명서, Mac용 ColorSync 유틸리티에서 Quartz 필터로 PDF 파일 수정하기 (확인일 2026-10-21)
직접 확인: macOS 27.0.1의 /System/Library/Filters/Reduce File Size.qfilter 설정값과 시험 PDF 비교 (2026-10-21)

맥에서 Home·End 키가 이상할 때 — 윈도우 키 대응표와 Home이 커서를 안 옮기는 이유

짚어봄 — Fri, 23 Oct 2026 10:53:54 +0900

윈도우에서 맥으로 옮긴 뒤 글을 쓰다가 Home 키를 눌렀는데 커서가 줄 맨 앞으로 가지 않고 화면만 위로 휙 올라가서 당황한 적 있으신가요? 고장이 아니라 맥은 Home·End 키가 원래 하는 일이 윈도우와 다르기 때문입니다. 이 글에서는 윈도우 키에 해당하는 맥 단축키를 표로 정리하고, 이 맥의 기본 키 설정 파일을 직접 열어 Home 키가 실제로 무엇으로 정해져 있는지 확인했습니다.

확인 환경: Mac mini, macOS 27.0.1(빌드 26A434). 확인일 2026-10-21.

한눈에 보는 대응표

윈도우 키와 맥 단축키 대응표(Apple·Microsoft 문서와 이 맥의 설정을 대조해 정리)

줄 맨 앞·맨 끝: 윈도우 Home·End → 맥 command + ← / →
문서 맨 앞·맨 끝: 윈도우 Ctrl+Home·Ctrl+End → 맥 command + ↑ / ↓
단어 단위 이동: 윈도우 Ctrl+← / → → 맥 option + ← / →
오른쪽 글자 지우기: 윈도우 Delete → 맥 fn + delete(맥의 delete 키는 윈도우 Backspace처럼 왼쪽 글자를 지웁니다)

맥의 Home은 '스크롤'만 합니다

Apple 단축키 문서는 fn+←(Home)를 "문서의 시작 위치로 스크롤", command+↑를 "삽입 지점을 문서의 시작 위치로 이동"이라고 구분해서 적습니다. 삽입 지점은 커서를 말합니다. 즉 맥의 Home은 보이는 화면만 문서 맨 위로 옮기고 커서는 제자리에 둡니다. 줄 맨 앞으로 커서를 옮기고 싶다면 Home 대신 command+←를 누르는 습관을 들이는 것이 가장 확실합니다.

Home(fn+←)과 command+←, command+↑의 차이(설명용 움직이는 그림, 약 9초)

이 맥의 기본 키 설정 파일로 확인한 결과

맥의 글자 입력칸이 어떤 키에 무엇을 할지는 시스템 안의 기본 키 설정 파일(StandardKeyBinding.dict)에 적혀 있습니다. 이 맥에서 그 파일을 읽어 사람이 읽기 쉬운 이름으로 바꿔 보니 다음과 같았습니다. 사용자가 따로 만든 키 설정 파일은 없는 기본 상태입니다.

이 맥의 기본 키 설정 파일에 적힌 실제 값(일부 줄을 옮겨 그림)

키	설정 파일 값	뜻
Home	scrollToBeginningOfDocument	문서 맨 위로 스크롤
command + ←	moveToLeftEndOfLine	커서를 줄 맨 앞으로
command + ↑	moveToBeginningOfDocument	커서를 문서 맨 앞으로
shift + Home	moveToBeginningOfDocumentAndModifySelection	문서 맨 앞까지 선택
command + delete	deleteToBeginningOfLine	줄 맨 앞까지 지우기

눈여겨볼 점이 두 가지 있습니다. 첫째, shift+Home은 윈도우에서 '줄 맨 앞까지 선택'이지만 맥 설정에서는 '문서 맨 앞까지 선택'입니다. 둘째, command+delete는 Apple 단축키 문서에는 Finder에서 '휴지통으로 이동'으로만 나오지만, 설정 파일에는 글자 입력칸에서 '줄 맨 앞까지 지우기'로 정해져 있습니다.

헷갈리기 쉬운 작은 차이

범위 선택: 윈도우에서 shift+Home·shift+End로 하던 줄 단위 선택은 맥에서 shift + command + ← / →입니다. 문서 맨 앞·끝까지 선택은 shift + command + ↑ / ↓, 단어 단위 선택은 shift + option + ← / →입니다. 세 가지 모두 이 맥의 설정 파일에서 '선택하며 이동(AndModifySelection)'으로 적혀 있는 것을 확인했습니다.
지우기: option+delete는 왼쪽 단어를, command+delete는 줄 맨 앞까지 지웁니다.
단어 이동 위치: Microsoft 문서에서 Ctrl+→는 "다음 단어의 시작 부분"으로, Apple 문서에서 option+→는 "다음 단어의 끝"으로 커서를 옮깁니다.
앱마다 다를 수 있음: 이번 확인은 맥 기본 설정 파일 기준입니다. 자체 단축키를 쓰는 앱에서는 동작이 다를 수 있습니다.

출처

Apple 사용 설명서, Mac 키보드상의 Windows 키 (확인일 2026-10-21)
Apple 지원, Mac 키보드 단축키 (게시일 2026-09-21, 확인일 2026-10-21)
Microsoft 지원, Windows에서 바로 가기 키 (확인일 2026-10-21)
직접 확인: macOS 27.0.1의 /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict (2026-10-21)

윈도우에서 만든 zip, 맥에서 한글 파일명이 깨질 때 — 맥 기본 도구로 직접 풀어 본 결과

짚어봄 — Thu, 22 Oct 2026 10:05:56 +0900

윈도우 PC에서 압축한 zip 파일을 맥에서 풀었더니 한글 파일 이름이 이상한 기호로 바뀌거나, 아예 풀리지 않고 오류가 나는 경우가 있습니다. 검색해 보면 "터미널에서 unzip -O cp949를 쓰라"는 답이 많은데, 지금 맥에 기본으로 들어 있는 unzip에는 이 옵션이 없습니다. 그래서 윈도우 방식으로 이름을 적은 zip을 직접 만들어, 맥에 기본으로 들어 있는 도구로 하나씩 풀어 봤습니다.

확인 환경: Mac mini, macOS 27.0.1(빌드 26A434), 시스템 언어 한국어. 확인일 2026-10-21.

왜 깨지나요: 파일 이름을 적는 방식이 달라서

zip 파일 안에는 파일 이름이 글자 코드로 적혀 있습니다. Python 공식 문서에 따르면 zip 표준에서는 헤더의 표시(플래그)로 이름이 UTF-8인지를 알리고, 표시가 없으면 기본 코드(IBM 코드 페이지)로 봅니다. 그런데 주로 윈도우에서 쓰인 옛 방식의 프로그램은 그 컴퓨터의 지역 코드로 이름을 적는다고 같은 문서가 설명합니다. 아래 시험에서는 이런 이름을 맥 터미널 도구 일부가 "Illegal byte sequence" 오류와 함께 풀지 못했습니다.

시험용 zip은 이 방식 그대로 만들었습니다. 파일 두 개(보고서_최종.txt, 폴더 안의 사진/여름 휴가.txt)의 이름을 CP949로 적고 UTF-8 표시는 끈 상태입니다.

같은 zip을 도구마다 풀었을 때 결과(시험용 zip의 실제 바이트로 그림)

맥 기본 도구로 하나씩 풀어 본 결과

푼 방법	결과
아카이브 유틸리티(Finder에서 zip을 더블클릭하면 열리는 기본 앱)	정상. 한글 이름 그대로 풀림
터미널 `ditto -x -k 파일.zip 폴더`	정상
터미널 `unzip 파일.zip`	실패. "cannot create ??????_????.txt / Illegal byte sequence"
터미널 `unzip -O cp949 파일.zip`	옵션이 없어 버전 안내 문구만 나오고 파일은 풀리지 않음
터미널 `tar -xf 파일.zip`	실패. 이름이 \272\270… 같은 숫자로 표시되며 "Illegal byte sequence"
터미널 `tar -xf 파일.zip --options hdrcharset=CP949`	정상

아카이브 유틸리티는 이 맥에서 zip 파일의 기본 앱으로 지정된 앱을 직접 열어 시험했습니다. 정리하면 기본 도구 중 한글이 제대로 풀린 것은 아카이브 유틸리티, ditto, 옵션을 준 tar 세 가지입니다.

실패한 unzip과 성공한 tar의 실제 터미널 출력(옮겨 그림)

상황별로 이렇게 하세요

먼저 더블클릭: 이번 시험(기본 앱인 아카이브 유틸리티로 직접 열어 봄)에서는 한국어로 설정된 맥에서 아카이브 유틸리티가 한글 이름을 제대로 풀었습니다. 이걸로 되면 따로 할 일이 없습니다.
터미널에서 풀어야 한다면: unzip 대신 아래 둘 중 하나를 쓰세요. 둘 다 맥에 기본으로 들어 있는 명령입니다.
```
tar -xf 파일.zip --options hdrcharset=CP949
```
```
ditto -x -k 파일.zip 풀폴더
```
Python 3.11 이상을 따로 설치해 쓰고 있다면: python3 -m zipfile --metadata-encoding cp949 -e 파일.zip 풀폴더로도 풀립니다(-l로 바꾸면 이름만 봄). 다만 맥에 기본으로 들어 있는 /usr/bin/python3는 이 맥에서 3.9.6이라 "unrecognized arguments: --metadata-encoding" 오류가 납니다.

참고로 hdrcharset는 맥의 tar(bsdtar 3.5.3)가 쓰는 libarchive 3.7.4의 설명서(man 3 archive_read_set_options)에 zip 형식 옵션으로 나오며, 파일 이름을 바꿀 때 쓸 문자 집합을 정합니다. Python의 --metadata-encoding은 Python 3.11에서 추가된 옵션입니다. 시험에는 따로 설치한 Python 3.14.8을 썼습니다.

unzip 실패에서 tar 옵션 성공까지 과정(움직이는 그림, 약 8초)

확인하지 못한 것

시스템 언어가 영어인 맥에서도 아카이브 유틸리티·ditto가 한글을 제대로 푸는지는 이 맥의 설정을 바꿔야 해서 시험하지 않았습니다.
시험용 zip은 직접 만든 것입니다. 윈도우의 특정 압축 프로그램이 만든 파일과 세부 구조가 다를 수 있습니다.

출처

Apple 사용 설명서, Zip and unzip files and folders on Mac (더블클릭으로 압축 해제, 확인일 2026-10-21)
Python 공식 문서, zipfile — Work with ZIP archives (metadata_encoding, 3.11 추가, 확인일 2026-10-21)
맥 내장 설명서 man 3 archive_read_set_options(Format zip의 hdrcharset), 직접 재현 결과(2026-10-21)

맥 화면 녹화할 때 소리까지 같이 녹음하는 법 (macOS 27 '시스템 오디오 포함')

짚어봄 — Thu, 22 Oct 2026 08:40:18 +0900

맥에서 화면을 녹화했는데 영상에 소리가 하나도 안 들어가 있어서 당황한 적 있으신가요? 예전에는 맥 기본 기능만으로 컴퓨터에서 나는 소리(시스템 오디오)를 녹음할 수 없어서, 가상 오디오 장치 같은 별도 프로그램을 깔라는 안내가 많았습니다. macOS 27부터는 기본 스크린샷 도구에 '시스템 오디오 포함' 옵션이 생겼습니다. 이 글에서는 그 옵션을 켜는 위치와, 실제로 소리가 들어가는지 이 맥에서 직접 확인한 결과를 정리했습니다.

확인 환경: Mac mini, macOS 27.0.1(빌드 26A434). 확인일 2026-10-21.

먼저 내 맥 버전부터 확인하기

이 옵션은 Apple 지원 문서에 "macOS 27 Golden Gate 및 이후 버전"에서 쓸 수 있다고 적혀 있습니다. 버전은 화면 왼쪽 위 Apple 메뉴 → 이 Mac에 관하여에서 볼 수 있습니다. 터미널을 쓰신다면 sw_vers를 입력해도 됩니다.

macOS 27 이상: 아래 방법 1·2를 그대로 쓰면 됩니다.
그보다 낮은 버전: Apple 문서는 이 옵션을 macOS 27 이상 기준으로 안내합니다. 낮은 버전이면 옵션 메뉴에 '시스템 오디오 포함'이 있는지 먼저 확인해 보세요.

방법 1. 스크린샷 도구에서 '시스템 오디오 포함' 켜기

shift + command + 5를 동시에 눌러 스크린샷 도구 막대를 엽니다.
도구 막대에서 전체 화면 기록 또는 선택 부분 기록을 고릅니다.
옵션을 눌러 시스템 오디오 포함을 선택합니다. 내 목소리도 같이 넣고 싶으면 같은 메뉴의 마이크에서 마이크를 고릅니다.
기록을 눌러 시작합니다. 시작 전에 취소하려면 esc 키를 누릅니다.
끝낼 때는 메뉴 막대의 중단 버튼을 누르거나 command + control + esc를 누릅니다. 파일은 기본으로 데스크톱에 저장됩니다(저장 위치는 같은 옵션 메뉴의 '다음으로 저장'에서 바꿉니다).

시스템 소리까지 녹화하는 4단계(Apple 지원 문서 내용 정리)

참고로 Apple 사용 설명서의 '스크린샷 또는 화면 기록 찍기' 페이지(확인일 기준)에는 옵션 목록에 마이크만 있고 '시스템 오디오 포함'이 빠져 있습니다. 옵션 이름은 지원 문서(102618)를 기준으로 적었습니다. 메뉴에서 이 이름이 보이지 않으면 버전을 먼저 확인해 보세요.

방법 2. 터미널 한 줄로 녹화하기 (확인한 결과)

같은 기능이 맥 기본 명령어 screencapture에도 있습니다. 이 맥에서 screencapture -h를 실행하면 -A 옵션이 화면 녹화 중 시스템 오디오를 녹음하는 옵션으로 나옵니다. 예를 들어 아래처럼 쓰면 화면 전체를 10초 동안 소리와 함께 녹화해 데스크톱에 저장합니다.

screencapture -v -A -V10 ~/Desktop/rec.mov

이 맥의 screencapture 도움말 중 소리 관련 줄(실제 출력을 옮겨 그림)

실제로 소리가 들어가는지 짧게 녹화해 비교했습니다. 녹화하는 동안 맥 기본 알림음(Glass, Ping)을 재생하고, 만들어진 파일 안에 어떤 트랙이 있는지와 소리 크기를 확인했습니다.

옵션을 켠 파일과 안 켠 파일의 소리 비교(실제 녹화 파일로 그림)

녹화 명령	파일 안의 트랙	알림음 녹음
`screencapture -v -V3` (옵션 없음)	영상만	안 됨(소리 트랙 없음)
`screencapture -v -A -V4`	영상 + 소리 1개	됨(재생한 두 소리 모두)
`screencapture -v -A -g -V3` (마이크도 같이)	영상 + 소리 1개	됨

-A로 녹화한 파일과 옵션 없이 녹화한 파일의 트랙 확인 과정(움직이는 그림, 약 9초)

정리하면, 옵션을 켜지 않으면 소리 트랙 자체가 만들어지지 않고, -A를 켜면 맥에서 나는 소리가 녹음됩니다. 마이크(-g)를 같이 켜도 소리 트랙은 하나로 저장됐습니다. 다만 확인한 맥에는 실제 마이크가 없어서, 목소리가 시스템 소리와 한 트랙에 섞여 들어가는지까지는 확인하지 못했습니다.

소리가 안 들어갈 때 확인할 것

버전: Apple 문서 기준으로 '시스템 오디오 포함'은 macOS 27 이상에서 쓸 수 있습니다.
옵션이 실제로 켜졌는지: 기록 버튼을 누르기 전에 옵션 메뉴에서 '시스템 오디오 포함'이 선택돼 있는지 한 번 더 확인하세요.
출력 장치: 위 시험은 소리가 원격 접속 프로그램의 가상 출력 장치로 나가는 상태에서 했는데도 녹음됐습니다.
QuickTime Player: Apple 문서는 '시스템 오디오 포함'을 스크린샷 도구(shift + command + 5)의 옵션으로 설명합니다. 시스템 소리가 필요하면 방법 1로 녹화하세요.

출처

Apple 지원, Mac에서 화면을 기록하는 방법 (게시일 2026-09-22, 확인일 2026-10-21)
Apple 사용 설명서, Mac에서 스크린샷 또는 화면 기록 찍기 (확인일 2026-10-21)
직접 확인: macOS 27.0.1의 screencapture -h 출력과 녹화 파일 비교 (2026-10-21)