GNU Parallel보다 50~400배 빠르다고? NUMA 인식 셸 병렬화 도구 Forkrun 등장

셸에서 병렬 처리, 다들 어떻게 하고 계세요?

리눅스에서 반복 작업을 병렬로 돌리고 싶을 때, 많은 분들이 xargs -P나 GNU parallel을 쓰고 계실 거예요. 파일 수천 개를 변환하거나, 로그를 한꺼번에 파싱하거나, API를 동시에 호출하거나 할 때 말이에요. 그런데 이런 도구들이 생각보다 느리다고 느껴본 적 없으세요? 특히 작업 하나하나가 아주 가볍고 빠른 경우, 정작 "작업을 나눠서 실행하는 오버헤드"가 실제 작업 시간보다 더 클 때가 있거든요.

이 문제를 정면으로 파고든 프로젝트가 바로 Forkrun이에요. Bash로 작성된 셸 병렬화 도구인데, GNU Parallel 대비 50배에서 최대 400배까지 빠르다는 벤치마크를 내세우고 있어요. 숫자가 좀 과한 것 아닌가 싶을 수 있는데, 접근 방식 자체가 근본적으로 다르기 때문에 충분히 가능한 수치예요.

어떻게 이렇게 빠를 수 있을까?

Forkrun의 핵심 아이디어는 크게 세 가지예요.

첫 번째는 coproc과 named pipe를 활용한 워커 풀 방식이에요. GNU Parallel은 작업마다 새로운 프로세스를 fork하는 방식이거든요. 이게 뭐냐면, 매번 "새 일꾼을 고용해서 일 하나 시키고 해고하는" 것과 비슷해요. 반면 Forkrun은 미리 워커(일꾼)를 여러 개 띄워놓고, 파이프를 통해 작업을 계속 먹여주는 방식이에요. 마치 공장에 근로자들을 상주시켜놓고 컨베이어 벨트로 부품을 보내는 것과 같죠. 프로세스를 새로 만들고 없애는 오버헤드가 사라지니까, 작업이 가벼울수록 차이가 극적으로 벌어지는 거예요.

두 번째는 이름에도 들어 있는 NUMA 인식(NUMA-aware) 기능이에요. NUMA가 뭐냐면, 요즘 서버용 CPU는 메모리에 접근하는 속도가 균일하지 않아요. CPU 소켓마다 "가까운 메모리"와 "먼 메모리"가 있는데, 가까운 메모리에 접근하면 빠르고 먼 메모리에 접근하면 느려요. 이걸 Non-Uniform Memory Access, 줄여서 NUMA라고 부르거든요. Forkrun은 각 워커 프로세스를 해당 CPU에 가까운 메모리 노드에 바인딩해서 실행해요. 덕분에 멀티소켓 서버에서 불필요한 메모리 접근 지연이 줄어들어요. 코어가 수십, 수백 개인 서버에서 작업을 돌리면 이 차이가 꽤 커지겠죠.

세 번째는 입력 분배 전략이에요. 입력 데이터를 워커들에게 한 줄씩 나눠주는 게 아니라, 적절한 크기의 청크(덩어리)로 묶어서 보내요. 이렇게 하면 파이프 I/O 횟수가 줄어들고, 각 워커가 한 번에 여러 항목을 처리할 수 있어서 효율이 올라가요.

사용법은 얼마나 간단할까?

사실 이런 도구가 아무리 빨라도 쓰기 어려우면 의미가 없잖아요. Forkrun의 기본 사용법은 GNU Parallel이나 xargs와 크게 다르지 않아요. 예를 들어 find . -name '*.log' | forkrun grep 'ERROR' 이런 식으로 파이프라인에 끼워 넣을 수 있어요. -j 옵션으로 병렬 수를 지정하거나, -n 옵션으로 워커당 처리할 항목 수를 조절하는 것도 가능해요. Bash 함수를 직접 워커로 넘길 수 있다는 점도 편리한데, forkrun my_bash_function < input.txt 이렇게 쓰면 돼요.

순수 Bash 스크립트라는 점도 눈여겨볼 만해요. 별도의 컴파일이나 의존성 설치 없이 Bash 4.0 이상이면 바로 쓸 수 있거든요. 서버에 뭔가 새로 설치하기 어려운 환경에서 특히 매력적이에요.

GNU Parallel과의 비교, 그리고 업계 맥락

GNU Parallel은 Ole Tange가 만든 정말 훌륭한 도구예요. 리모트 실행, 재시도, 로깅 등 엔터프라이즈급 기능이 풍부하죠. 다만 그 풍부한 기능이 오버헤드로 이어지는 측면이 있어요. 작업 하나를 실행하는 데 드는 고정 비용이 상대적으로 높거든요. 대규모 파일 처리나 네트워크 요청처럼 작업 자체가 무거우면 이 오버헤드가 무시할 만하지만, echo나 간단한 문자열 처리 같은 마이크로 작업을 수만 번 돌리면 오버헤드가 지배적이 돼요.

Forkrun은 이 틈새를 정확히 파고들었어요. "가볍고 빠른 작업을 대량으로" 돌리는 시나리오에서 압도적인 성능을 보여주는 거예요. 반면 리모트 실행이나 복잡한 작업 의존성 관리 같은 기능은 없으니, 모든 상황에서 GNU Parallel을 대체하는 건 아니에요.

비슷한 영역의 도구로는 rush(Go 기반 병렬 실행기)나 Rust로 만든 parallel 대안들도 있는데, 순수 Bash로 이 정도 성능을 뽑아냈다는 점에서 Forkrun의 접근이 독특해요.

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

데이터 파이프라인이나 배치 작업을 셸 스크립트로 운영하는 팀이라면 눈여겨볼 만해요. 특히 로그 파싱, 이미지 리사이징, 파일 변환 같은 작업을 크론으로 돌리고 있다면, Forkrun으로 교체하는 것만으로 처리 시간이 크게 줄어들 수 있어요. 멀티소켓 서버를 운용하는 환경이라면 NUMA 인식 기능의 효과가 특히 클 거예요.

또 하나 배울 점은, 성능 최적화의 핵심이 "더 빠른 언어"가 아니라 "더 나은 아키텍처"일 수 있다는 거예요. Bash라는 느린 언어로도 프로세스 관리 방식을 바꾸는 것만으로 C로 작성된 도구보다 빠른 결과를 낼 수 있다는 건 꽤 인상적이에요.