xargs에 질린 개발자가 직접 만든 대안 — 우리는 왜 xargs와 계속 싸울까

xargs, 다들 한 번쯤 싸워보셨죠

한 개발자가 “xargs가 지긋지긋해서” 직접 bash용 열거(enumerate) 도구를 만들었다는 글을 올렸어요. 도구 자체보다도, 이 글이 건드린 공감 포인트가 커요. xargs가 뭐냐면, 앞 명령의 출력으로 나온 목록을 받아서 다음 명령의 인자로 넘겨주는 유닉스 도구예요. 예를 들어 find . -name '*.log' | xargs rm 하면 찾아낸 로그 파일들을 한꺼번에 지워주죠. 쉘에서 “여러 대상에 같은 작업을 반복”할 때의 표준 도구인데, 문제는 이 도구가 수십 년째 온갖 함정으로 악명이 높다는 거예요. 오죽하면 참다못해 대체 도구를 직접 만드는 사람이 나왔겠어요.

xargs의 유서 깊은 함정들

첫 번째 함정은 공백이에요. xargs는 기본적으로 공백과 줄바꿈을 구분자로 쓰는데, 파일명에 공백이 들어 있으면(예: my report.pdf) 이걸 두 개의 인자로 쪼개버려요. 그래서 널 문자를 구분자로 쓰는 find -print0 | xargs -0 조합을 따로 외워야 하죠. 두 번째는 자리표시자예요. 인자를 명령 중간에 끼워 넣으려면 xargs -I {} 문법을 써야 하는데, 이 옵션을 켜는 순간 한 번에 하나씩만 처리하는 모드로 바뀌는 등 동작이 미묘하게 달라져요. 세 번째는 빈 입력 문제예요. 입력이 하나도 없어도 GNU 버전 xargs는 명령을 한 번 실행해버려서 -r 옵션을 붙여야 하는데, 맥에 들어 있는 BSD 버전은 또 동작이 달라요. 리눅스에서 잘 되던 스크립트가 맥에서 깨지는 단골 원인이죠. 이걸 피하려고 while read 루프로 갈아타면, 이번엔 read -r을 빼먹거나 IFS 설정을 놓쳐서 또 다른 함정에 빠지고요. 그러니까 “목록을 돌면서 명령 실행하기”라는 지극히 평범한 작업이 쉘에서는 지뢰밭인 거예요. 글쓴이가 만든 도구는 이 열거 과정을 좀 더 예측 가능하게 만들어보자는 시도고요.

대안은 이미 여럿 있어요

사실 이 불만은 오래된 만큼 대안도 많아요. GNU parallel은 xargs의 상위 호환 같은 도구로, 병렬 실행과 자리표시자 문법이 훨씬 유연해요. find를 대체하는 러스트 기반 도구 fd는 -x 옵션으로 검색 결과에 바로 명령을 실행할 수 있어서 아예 xargs가 필요 없고요. zsh를 쓴다면 **/*.log 같은 글롭 확장으로 파이프 없이 해결되는 경우도 많아요. 조금 더 근본적인 흐름도 있는데요. 이 모든 문제의 뿌리는 유닉스 파이프라인이 ‘구조 없는 텍스트’를 주고받는다는 데 있어요. 텍스트에는 “여기까지가 하나의 항목”이라는 정보가 없으니까, 공백이니 널 문자니 하는 약속이 계속 필요한 거예요. 그래서 파이프로 구조화된 데이터(테이블)를 넘기는 nushell 같은 새로운 쉘이나, JSON을 다루는 jq 같은 도구가 주목받는 거고요.

한국 개발자에게 주는 시사점

당장 실무에 가져갈 팁을 정리하면 이래요. 파일명을 다루는 파이프라인에는 반사적으로 find -print0 | xargs -0 조합을 쓰는 습관을 들이세요. 스크립트를 짤 때 shellcheck를 돌리는 것만으로도 이런 함정의 상당수를 미리 잡을 수 있어요. 병렬 처리가 필요하면 xargs의 -P 옵션이나 GNU parallel을 검토해보시고요. 맥과 리눅스를 오가는 환경이라면 BSD 도구와 GNU 도구의 동작 차이를 의심 목록 첫 줄에 두세요. 마지막으로, 쉘 스크립트가 화면 반 이상으로 길어지고 조건 분기가 늘어나고 있다면, 그건 파이썬 같은 제대로 된 언어로 넘어가라는 신호일 수 있다는 것도요. 쉘은 접착제로 쓸 때 가장 빛나거든요.

마무리

정리하면, xargs와의 싸움은 여러분의 실력 문제가 아니라 텍스트 기반 파이프라인이라는 설계의 태생적 한계라는 이야기예요. 여러분은 “목록 돌면서 명령 실행”을 어떻게 처리하세요? xargs파, while read파, parallel파, 아니면 그냥 파이썬으로 짜버리는 파인가요?