macOS에서 grep -P가 안 될 때: 오류가 나는 경우와 조용히 비거나 엉뚱한 결과가 나오는 경우

한 줄 요약: macOS 기본 grep은 -P를 거부하므로 -E나 perl로 옮기되, 룩어라운드는 오류로 드러나고 \K와 기본 정규식의 \d+는 오류 없이 비거나 엉뚱한 결과를 내니 바꾼 뒤 기대한 값과 일치하는지 꼭 대조하라.

리눅스 글에서 복사한 grep -oP '\d+' 파일 이 맥에서 grep: invalid option -- P 와 사용법 안내만 남기고 죽는다. 이 글은 대체 방법을 고르는 기준과, 더 위험한 쪽, 곧 오류 없이 결과만 비는 정규식을 다룬다. 확인한 환경은 macOS 26.6.2 arm64의 /usr/bin/grep(BSD grep 2.6.0-FreeBSD)이고, 여기서 GNU grep과 Linux는 시험하지 않았다.

용어 몇 개. -P는 GNU grep이 제공하는 Perl 호환 정규식 옵션이다(GNU grep 매뉴얼의 -P 항목이 그렇게 설명한다). 기본 정규식은 grep에 -E도 -P도 주지 않았을 때의 문법이고, 룩어라운드는 앞이나 뒤의 문맥만 조건으로 걸고 그 문맥은 결과에 넣지 않는 Perl식 문법이다. 종료 코드는 명령이 끝날 때 남기는 숫자로, grep은 0이 “찾았다”, 1이 “못 찾았다”, 2 이상이 “오류”다(직전 값은 $?로 읽는다).

오류가 떠도 파이프에서 묻힌다

오류 메시지가 뜨는 경우도 안전하지는 않다. 내 게임 클론 작업 저장소에는 후보 목록에서 무작위로 하나 고르는 선정 단계가 있었다. 목록에서 굵게 표시한 이름만 grep -oP로 뽑아 shuf -n 1로 넘기는 명령 네 줄이었는데, 로그인 셸에서 grep이 BSD grep으로 잡혔다. 그 저장소의 2026-08-15 커밋 기록에는 이렇게 적혀 있다. 그 네 줄이 전부 grep: invalid option -- P로 실패했고 shuf는 빈 입력을 받아 아무것도 출력하지 않은 채 끝났으며, 후보 수를 세어 보니 0개였다. 같은 입력을 perl로 바꾸자 171개가 나왔다고 기록했다.

기록에는 이 실패가 에러처럼 보이지 않았다고 적혀 있다. 이유는 내 해석이다(커밋 기록에는 이 설명이 없고, 아래 재현은 wc -l로 했다). 파이프 맨 뒤 명령이 “입력이 없다”를 정상으로 받아들이기 때문이다. 같은 모양을 한 줄로 줄여 작은 파일로 재현하면 이렇다(/usr/bin/grep 직접 호출). 이 맥에서 어느 grep이 잡히는지는 command -v grep과 grep --version으로 먼저 본다. 사례의 원인이 PATH 순서였기 때문이다.

printf 'a **Alpha** b\n**Beta**\n' > /tmp/listing-sample.md
/usr/bin/grep -oP '(?<=\*\*)[^*]+(?=\*\*)' /tmp/listing-sample.md | wc -l

wc -l이 0을 찍고, 파이프 앞 grep의 종료 코드는 2다(bash는 PIPESTATUS, zsh는 pipestatus로 확인). 같은 파일에서 perl 한 줄(perl -nle 'print $1 while /\*\*([^*]+)\*\*/g')은 2개를 낸다.

이 맥의 grep이 되는 것과 안 되는 것

macOS는 grep을 BSD grep으로 제공한다. 공개된 맥 사례도 같다. Bridge for Git 훅이 grep: invalid option -- P를 낸 지식베이스 글(Broadcom)은 기본 grep이 Perl 정규식을 지원하는 것이어야 한다며 ggrep을 든다. 일본어 개발자 글(Zenn)은 brew install grep 뒤 ggrep -P를 쓰라 하고, 유닉스 커뮤니티 질문은 우분투에서 온 grep -P -v '^(.)\1*$'가 맥에서 사용법 안내만 낸 경우다. 이 글은 Homebrew 없이도 맥에 기본으로 있는 도구(/usr/bin의 grep·sed·perl)만으로 푸는 길을 본다. ggrep은 이 맥에 없어 시험하지 않았다.

같은 입력으로 /usr/bin/grep에 던져 본 결과다. 입력과 출력은 trial-output 파일 그대로다.

패턴(옵션)	입력	종료 코드	출력
-oP '\d+'	order 123 ok	2	grep: invalid option -- P
-oE '\d+'	order 123 ok	0	123
-oE '\w+'	ab_1 cd	0	ab_1, cd
-oE '\bcat\b'	cat concat	0	cat
-oE 'a.*?b' (비탐욕)	aXbYb	0	aXb
-E '(?i)abc'	ABC	0	ABC
-oE 'a(?=b)' (룩어헤드)	ab	2	grep: repetition-operator operand invalid
-oE '(?<=key=)\w+' (룩비하인드)	key=val	2	위와 같은 오류
-oE 'key=\K\w+'	key=val	1	(없음)
-o '\d+' (옵션 없이, 기본 정규식)	order 123 ok	1	(없음)

해석을 하나 붙인다. -E에서 \d·\w·\b·비탐욕 반복·(?i)가 도는 것은 맥의 정규식 매뉴얼 re_format이 말하는 enhanced(REG_ENHANCED 플래그를 켠 확장) 기능과 일치한다(\d는 [[:digit:]]와 같고, 반복 연산자 뒤 ?는 최소 매칭이며, (?i)는 대소문자 무시). 다만 grep이 그 플래그를 쓴다고 적은 문서는 보지 못했다. 이 글은 관측된 동작이 그렇다는 데까지만 말한다.

오류 없이 비거나 틀리는 두 가지

맥에서 grep -P는 소리라도 나지만, \K와 \d+는 아무 소리 없이 빈 결과를 낸다. 표의 마지막 두 줄이 이 글의 핵심이고, 표의 입력에서는 둘 다 종료 코드 1이라 grep의 “못 찾았다”와 구별되지 않는다.

기본 정규식의 \d+. -E나 -P 없이 쓰면 +는 그냥 글자 +다. re_format은 enhanced 모드의 기본 정규식에서 +·?·|는 일반 문자로 남고 \+·\?·\|가 특수 의미를 갖는다고 적는다. 그래서 \d+는 “숫자 하나 뒤에 더하기 기호”를 찾는다. order 123 ok에서는 없으니 1이 나오고, 우연히 n=12+3을 넣으면 2+가 튀어나온다. 숫자 덩어리를 뽑으려면 \d\+나 -E '\d+'로 쓴다.

\K. PCRE에서 \K는 “여기까지 맞은 것은 결과에서 버린다”는 뜻이라 key=\K\w+가 값만 뽑는다. BSD grep에서는 오류도 없이 빈 결과가 나온다. key=Kval을 넣어 보면 key=\K\w+와 key=K\w+가 둘 다 key=Kval을 그대로 돌려준다. 이 두 출력이 같다는 것은 \K가 대문자 K라는 글자로 읽힌다고 보면 맞는다.

반대로 룩어라운드((?=·(?<=)는 repetition-operator operand invalid 오류를 낸다. 소리가 나니 침묵하는 두 가지보다는 낫지만, 앞 절처럼 파이프 안에서는 이 오류도 똑같이 묻힌다.

어떤 도구로 옮길까

같은 목적, 곧 key= 뒤의 값만 뽑는 일을 이 맥에 기본으로 있는 도구로 해 본 결과다(아래 grep은 시스템 /usr/bin/grep 기준이다). 입력은 모두 key=val이고 전부 val을 냈다.

grep -oE 'key=[a-z]+' | cut -d= -f2         # 값 앞의 key= 를 cut이 잘라낸다
sed -nE 's/.*key=([a-z]+).*/\1/p'           # 괄호로 묶은 부분만 출력
perl -ne 'print "$1\n" if /key=(\w+)/'      # 가장 PCRE에 가깝다
perl -ne 'print "$&\n" if /(?<=key=)\w+/'   # $&는 방금 맞은 부분 전체. 룩비하인드·\K 도 그대로 된다

고르는 기준은 이렇다. 룩어라운드나 \K가 정말 필요하면 perl이 정규식을 거의 그대로 옮긴다. 그 정도가 아니면 -E와 [[:digit:]]·[0-9] 같은 단순한 식으로 고쳐 쓰는 편이 이식성이 좋다(이 부분은 시험이 아니라 POSIX 일반 지식에 기댄 판단이다). \d는 이 맥에서 동작한다는 것만 확인했고, re_format도 enhanced 기능이 POSIX 표준과 어긋날 수 있어 이식성이 필요한 곳에서는 조심해 쓰라고 경고하므로 리눅스에도 쓸 스크립트에는 넣지 않는다. -P를 그대로 두려는 목적이라면 GNU grep을 따로 설치하는 길이 있으나 이 글에서는 확인하지 않았다.

종료 코드는 도구마다 다르다. sed -n은 못 찾아도 0이다. perl -ne도 못 찾았을 때 0이다. grep처럼 “못 찾으면 1”을 기대한 스크립트에 그대로 끼우면 판단이 달라진다. 못 찾음을 실패로 치려면 perl -ne '$m=1,print "$1\n" if /key=(\w+)/; END{exit($m?0:1)}'처럼 종료 코드를 직접 정한다(못 찾았을 때 1이 나오는 것을 확인했다).

바꾼 뒤에 반드시 세는 것

오류가 눈에 보이는 경우는 고치고 끝난다. 위험한 건 바꾼 식이 문법상 통과해 빈 결과를 내는 경우라서, 바꾼 줄마다 이렇게 확인한다. \d+가 2+를, \K가 key=Kval을 낸 것처럼 비어 있지 않아도 틀릴 수 있으니 개수만이 아니라 기대한 값과도 대조한다.

1. 결과가 있는 입력 하나와 없는 입력 하나로 각각 돌려 출력과 $?를 보고, 출력이 기대한 값과 정확히 같은지 본다.
2. 파이프 뒤에 있으면 앞 명령 단독으로도 돌려 개수를 센다(| wc -l). 앞의 사례 기록에서는 후보 수를 먼저 확인하라는 절차가 사고 뒤에 추가됐다.
3. grep ... || true로 감쌌다면(bash set -e 기준으로 시험했다) 그 안의 오류도 같이 삼킨다. v=$(echo abc | /usr/bin/grep -oP "\d+" || true)는 usage 메시지를 stderr에 찍고도 v=[]로 정상 종료(종료 코드 0)했다. set -e와 만나는 문제는 별도 글에서 다뤘다.

시험하지 않은 것: GNU grep 3.x의 -P 동작, ggrep, Linux, 다른 macOS 버전의 grep. 이전 macOS의 grep이 같은 표를 낸다고 일반화하지 않는다.

세 줄 요약

• 이 맥의 /usr/bin/grep은 -P를 오류(종료 코드 2)로 거부하고, -E에서는 \d·\w·비탐욕 반복·(?i)가 동작한다.
• 룩어라운드는 오류로 드러나지만 \K와 옵션 없는 \d+는 오류 없이 빈 결과(종료 코드 1)나 엉뚱한 결과를 내서 파이프 뒤에서 조용히 0개가 되거나 틀린 값이 된다.
• perl이나 sed -E로 옮긴 뒤에는 결과 있는 입력과 없는 입력을 모두 돌리고 값과 개수와 종료 코드를 기대와 대조한다.