솔직히 말해봅시다. 여러분이 운영 중인 그 수많은 Bash 스크립트들, 정말 안녕하신가요? 15년 동안 인프라 바닥을 구르며 제가 뼈저리게 느낀 진리가 하나 있습니다. "시스템은 거짓말을 하지 않지만, 텍스트 파싱은 언제나 배신한다"는 것입니다. 우리는 고가용성(High Availability) 99.999%를 외치면서도, 정작 그 시스템을 지탱하는 스크립트는 1970년대에 만들어진 텍스트 처리 방식에 의존하고 있습니다. 공백 하나 때문에 프로덕션 데이터가 날아가거나, 로그 포맷이 조금 바뀌었다고 awk와 sed로 떡칠된 스크립트가 오작동해 새벽 3시에 PagerDuty가 울리는 경험, 다들 한 번쯤 있으실 겁니다. 저는 이제 그 지긋지긋한 '레거시의 낭만'을 버리고, 퇴근과 건강을 지켜줄 실질적인 도구에 대해 이야기하려 합니다. 바로 Nushell입니다.
우리가 매일 마주하는 Bash나 Zsh 같은 쉘 환경을 냉정하게 바라봅시다. 이 친구들은 훌륭합니다. 어디에나 있고(Ubiquitous), 한 번 배워두면 리눅스 서버 어디서든 생존할 수 있습니다. 하지만 '언어'로서의 가치를 따져보면 이야기가 다릅니다. Bash는 복잡한 로직을 처리하거나 대규모 운영 자동화를 위해 설계된 것이 아닙니다. 간단한 반복문 하나를 작성하려 해도 문법은 기괴하기 짝이 없습니다. 백틱(backtick)과 달러 사인이 난무하는 코드를 보며 우리는 "이게 진짜 최선인가?"라고 묻지 않습니다. 그저 익숙함이라는 관성에 젖어 있을 뿐입니다. Fish 쉘이 "90년대를 위한 쉘"이라며 더 나은 사용성을 들고나왔고, PowerShell이 .NET 객체를 파이프라인에 태우는 혁신을 보여주었지만, 여전히 리눅스 서버의 대세는 텍스트 스트림 기반의 고전적 쉘입니다.
여기서 짚고 넘어가야 할 것이 바로 'POSIX 호환성'이라는 신성불가침의 영역입니다. 많은 엔지니어가 새로운 쉘 도입을 주저하며 "하지만 POSIX 표준이 아니잖아요"라고 반문합니다. 그런데 냉정하게 물어봅시다. POSIX의 무엇이 그렇게 위대합니까? 쉘 스크립트의 예약어인 case를 닫기 위해 esac을 쓰고, if를 닫기 위해 fi를 쓰는 문법이 정말 2024년에도 유효한 설계 철학일까요? 이건 마치 우리가 아직도 8비트 머신을 다루며 바이트 단위 최적화를 해야 한다는 강박과 같습니다. 유닉스 명령어들의 플래그(Flag) 파편화도 심각합니다. 제 맥북에서 ls 명령어의 플래그는 무려 45개나 됩니다. 우리는 데이터를 파이프라인으로 넘겨서 처리하는 게 아니라, 각 명령어의 출력 형식을 맞추기 위해 수십 개의 옵션을 외우는 '옵션 암기 과목'을 공부하고 있는 셈입니다.
이 지점에서 Nushell이 제안하는 '구조화된 데이터(Structured Data)'의 개념이 우리의 구원이 됩니다. 기존 유닉스 파이프라인은 텍스트(Text)가 흐릅니다. 앞단의 명령어가 뱉은 텍스트를 뒷단의 명령어가 받아 정규표현식으로 찢고 발라내야 의미가 생깁니다. 이는 극도로 불안정합니다. 반면 Nushell은 파이프라인을 통해 '객체' 혹은 '테이블' 형태의 구조화된 데이터가 흐릅니다. 예를 들어, 특정 크기 이상의 파일을 찾고 싶을 때 우리는 더 이상 ls -l의 몇 번째 컬럼이 파일 사이즈인지 세어볼 필요가 없습니다. ls | where size > 10kb라고 입력하면 끝입니다. ls는 데이터를 구조화해서 넘기고, where는 그 데이터의 속성을 이해하고 필터링합니다.
이러한 구조적 접근은 단순히 타이핑을 줄여주는 차원이 아닙니다. 시스템 운영의 안정성을 획기적으로 높여줍니다. ps 명령어로 CPU 점유율이 높은 프로세스를 찾을 때도 ps | where cpu > 40처럼 직관적인 로직이 가능합니다. 심지어 CSV 파일을 열 때도 open fields.csv | where area > 5와 같이 동일한 문법을 사용합니다. 데이터의 소스가 프로세스 목록이든, 파일 시스템이든, 정형 데이터 파일이든 상관없이 일관된 방식으로 처리할 수 있다는 것은 엔지니어에게 엄청난 축복입니다. 파싱 에러로 인한 스크립트 중단을 걱정할 필요가 없다는 뜻이니까요.
물론 현업에서 당장 모든 서버의 기본 쉘을 Nushell로 바꾸는 것은 불가능에 가깝습니다. 레거시는 생각보다 끈질기고, 우리는 여전히 #!/bin/bash로 시작하는 스크립트를 유지보수해야 할 것입니다. 하지만 로컬 환경에서 데이터를 분석하거나, 복잡한 트러블슈팅을 위해 로그를 뒤져야 할 때, 혹은 CI/CD 파이프라인의 일부 로직을 작성할 때 Nushell은 강력한 무기가 됩니다. 범인을 찾기 위해(Blaming) 로그 텍스트를 눈빠지게 쳐다보는 대신, 로그를 구조화된 데이터로 변환해 쿼리를 날리는 방식은 문제 해결 시간(MTTR)을 단축해 줍니다.
결국 도구는 우리의 시간을 벌어주어야 합니다. 익숙함이라는 핑계로 비효율을 방치하는 것은 엔지니어의 직무 유기이자, 자신의 워라밸에 대한 배신입니다. 40년 된 망치만 고집하지 마십시오. POSIX라는 낡은 경전에 얽매여 더 나은 방법을 외면하지 마십시오. 시스템이 복잡해질수록 우리는 더 명확하고 안전한 도구가 필요합니다. 오늘 당장 터미널을 열고 Nushell을 설치해 보십시오. 그리고 텍스트 덩어리와 씨름하던 시간을 줄여, 제발 정시에 퇴근하시길 바랍니다. 우리 인생의 가용성은 우리가 지켜야 하니까요.
