Ruby로 만든 유닉스 셸 'Rubish': 셸 스크립트의 한계를 넘어

셸 스크립트, 다들 한 번씩은 욕해봤죠

터미널에서 매일 쓰는 bash나 zsh, 정말 강력한 도구지만 가끔 한숨이 나올 때가 있어요. 문자열에 공백 하나 잘못 들어가면 전혀 다르게 해석되고, 변수에 따옴표 안 씌우면 갑자기 에러가 나고, if문 안에 대괄호를 두 개 써야 하는지 한 개 써야 하는지 매번 헷갈리고요. 간단한 작업은 빛처럼 빠르게 처리할 수 있는데, 조금만 복잡해지면 "아 그냥 파이썬으로 다시 짤까"라는 생각이 자연스럽게 들죠.

이런 답답함에서 출발한 프로젝트가 'Rubish'예요. 일본의 유명한 루비스트 amatsuda(아마츠다 아키라)가 만든 프로젝트인데, 이름 그대로 "Ruby + ish(셸)"의 합성이에요. 순수 Ruby로 작성된 유닉스 셸이고, 셸 명령어를 입력하면 그게 사실 Ruby 코드로 평가되는 구조예요.

어떻게 동작하나, 들여다보면

Rubish의 핵심 아이디어는 단순해요. 우리가 터미널에 ls -la 같은 걸 치면, 보통은 셸이 그걸 외부 명령어로 인식해서 /bin/ls를 실행하잖아요. 그런데 Rubish에서는 이게 사실 Ruby의 메서드 호출로 변환돼요. 그러니까 ls("-la") 같은 식으로 처리되는 거죠. 명령어와 그 인자들이 모두 Ruby 객체로 다뤄지기 때문에, 셸의 한계 안에서 끙끙대지 않고 Ruby의 풍부한 기능을 그대로 쓸 수 있어요.

예를 들어 셸 스크립트에서 "이 디렉터리에 있는 .log 파일 중에서 100MB 이상인 것만 골라서 압축하고, 압축 결과의 크기가 50MB 미만이면 원본 삭제" 같은 작업을 하려면 awk, find, xargs, 조건문이 뒤엉킨 마법 같은 한 줄이 나오기 일쑤죠. Rubish에서는 이걸 Ruby 코드로 자연스럽게 풀어 쓸 수 있어요. Ruby의 Enumerable 메서드들(map, select, reject 같은 것들)을 그대로 활용할 수 있다는 게 가장 큰 장점이에요.

또 한 가지 흥미로운 점은 파이프(|) 처리예요. 일반 셸에서 파이프는 텍스트 스트림을 다음 명령으로 넘기는데, Rubish에서는 Ruby 객체를 그대로 넘길 수 있어요. 텍스트를 다시 파싱할 필요 없이 구조화된 데이터를 다음 단계로 전달하는 거죠. 이게 뭐가 좋냐면, JSON이나 해시 데이터를 다룰 때 jq 같은 별도 도구 없이도 그냥 Ruby 코드로 처리할 수 있다는 뜻이에요.

비슷한 시도들과의 비교

사실 "프로그래밍 언어 기반의 셸"이라는 아이디어는 Rubish가 처음은 아니에요. 가장 유명한 건 마이크로소프트의 PowerShell이죠. 윈도우에서 기본으로 제공되는 셸인데, 텍스트가 아니라 .NET 객체를 파이프로 전달한다는 점에서 혁신적이었어요. 비슷하게 'xonsh'는 Python 기반의 셸이고, 'Elvish'와 'Nushell'은 아예 새로운 언어를 만들어서 구조화된 데이터를 다루는 데 집중했어요. 특히 Nushell은 최근 몇 년간 많이 떠오르고 있는데, 모든 명령어 결과를 테이블 형태로 다룬다는 점이 독특해요.

Rubish의 위치는 이 흐름의 일부예요. 기존 유닉스 셸의 텍스트 중심 처리 방식에서 벗어나, 호스트 언어(Ruby)의 객체 모델을 그대로 셸 환경에 가져온다는 점에서요. 차이라면 PowerShell이나 Nushell처럼 "새로운 셸 패러다임"을 표방하기보다, Ruby 생태계의 사용자들에게 친숙한 도구를 제공하는 데 더 집중하는 느낌이에요.

그리고 Ruby의 특성상, 메타프로그래밍(코드가 코드를 다루는 기법)이 자유롭다는 점도 큰 장점이에요. 자기만의 셸 명령어를 Ruby 메서드로 정의해서 바로 쓸 수 있거든요. "이 명령은 매번 옵션 5개를 똑같이 붙여" 같은 반복을 함수로 묶어버리면 끝이에요. bash에서도 alias나 function으로 비슷하게 할 수 있지만, Ruby의 표현력에 비할 바는 아니에요.

실무에서 쓸 만한가

솔직히 당장 메인 셸로 갈아타라고 권하긴 어려워요. zsh + oh-my-zsh 조합에 익숙한 사람이 새 셸로 옮기는 비용이 만만치 않고, Rubish는 아직 실험적인 프로젝트라 일상적인 안정성이 검증된 단계는 아니거든요. 게다가 Ruby가 시작될 때마다 인터프리터가 로드되니까, 가벼운 bash보다는 셸 시작 속도가 느릴 수밖에 없어요.

그럼에도 한번 들여다볼 가치는 충분해요. Ruby 개발자라면 자신의 일상 작업 자동화 도구로 쓰기 좋고, 셸 스크립트의 한계를 답답해하던 사람이라면 "아, 이런 방향도 있구나"라는 영감을 얻을 수 있어요. 그리고 이런 프로젝트 코드를 직접 읽어보는 것 자체가 좋은 공부예요. "셸이 어떻게 동작하는지", "읽기-평가-출력 루프(REPL)는 어떻게 만드는지", "프로세스를 어떻게 생성하고 파이프를 연결하는지" 같은 시스템 프로그래밍의 기초가 자연스럽게 보이거든요.

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

한국에서 Ruby는 한때 Rails 붐과 함께 인기였지만 지금은 사용층이 좁아진 게 사실이에요. 그래도 우아한형제들, 카카오 일부 팀, 그리고 여러 스타트업에서 여전히 Ruby/Rails를 쓰고 있고, Ruby 자체의 표현력은 여전히 매력적이에요. 만약 자동화 스크립트를 짜다가 bash로 한계를 느꼈다면, 굳이 Rubish가 아니더라도 Ruby 스크립트(.rb 파일)로 바꿔보는 것만으로도 삶의 질이 올라갈 수 있어요. system, IO.popen, Open3 같은 표준 라이브러리만으로도 셸의 거의 모든 기능을 우아하게 다룰 수 있거든요.

Python 진영의 'invoke', 'fabric', 'plumbum' 같은 라이브러리도 비슷한 역할을 해요. 핵심은 "셸 스크립트의 한계에 부딪혔을 때, 다른 언어로 넘어가는 임계점을 잘 잡는 것"이에요. 50줄 넘어가는 bash 스크립트라면 그냥 다른 언어로 넘어가는 게 정신 건강에 좋다는 게 많은 개발자들의 경험칙이고요.

마무리

도구는 결국 사람이 만들어요. amatsuda 같은 개발자가 "내가 쓰던 셸이 답답해서 새로 만들었어"라고 이야기하는 모습은, 우리가 잊고 살기 쉬운 진실 하나를 일깨워줘요. "불편하면 직접 만들 수 있다"는 것이요. 여러분이 매일 쓰는 도구 중에서, 한 번쯤 직접 만들어보고 싶은 게 있나요?