우분투 기본 명령어가 Rust로 바뀐다면, 기존 스크립트는 괜찮을까요?

핵심 요약

• uutils는 GNU coreutils와의 호환성을 목표로 하는 Rust 기반 구현입니다.
• Rust의 메모리 안전성이 명령어의 기능과 결과까지 보장하지는 않습니다.
• 호환성을 지키려면 옵션뿐 아니라 종료 코드, 파일 권한, 심볼릭 링크 처리도 검증해야 합니다.
• 성능은 언어 이름보다 어떤 작업을 어떤 조건에서 실행하는지를 기준으로 비교해야 합니다.

우분투 26.10에서 기본 명령어를 Rust 구현으로 바꾼다면, 매일 쓰는 cp와 ls도 제대로 동작하는지 확인해야 합니다. 사용자가 직접 실행하는 명령부터 서버 배포 스크립트까지 영향을 받을 수 있기 때문입니다. “평소 쓰던 명령이 내일도 똑같이 동작할까요?” 사용자가 궁금한 건 결국 이 부분일 겁니다.

명령어 이름은 같아도, 안쪽 구현은 달라집니다

리눅스에서 파일을 복사할 때는 cp를 씁니다. ls로 목록을 보고, sort로 텍스트를 정렬합니다. 이런 기본 도구를 모아 놓은 것이 coreutils입니다. GNU coreutils는 널리 쓰이는 구현이고, uutils는 GNU 호환을 목표로 이 도구들을 Rust로 구현하는 프로젝트입니다.

‘호환’하려면 명령어 이름만 같아서는 안 됩니다. 기존 스크립트가 넘기는 옵션을 이해해야 하고, 같은 조건에서 실행했을 때 기대한 결과가 나와야 합니다.

사람은 출력이 조금 달라도 뜻을 알아차릴 수 있습니다. 하지만 다른 프로그램은 공백이나 줄바꿈까지 같을 거라고 가정하고 출력을 읽을 수 있습니다. 오래 쓰인 기본 도구일수록 이런 세부 동작에 기대어 돌아가는 프로그램도 쌓여 있습니다.

메모리 안전은 무엇을 해결해 줄까요?

Rust를 선택하는 주요 이유 중 하나는 메모리 안전성입니다. 프로그램이 이미 해제한 메모리를 다시 쓰거나 허용되지 않은 영역에 접근하는 오류를 막는 데 도움이 됩니다.

안전한 Rust 코드는 컴파일할 때와 실행 중에 검사를 거쳐 이런 오류를 막습니다. 다만 안전성 검사를 일부 개발자에게 맡기는 unsafe 코드나 외부 라이브러리와 연결되는 부분은 따로 검토해야 합니다.

메모리를 안전하게 다룬다고 해서 모든 동작이 올바른 것은 아닙니다. 그런 프로그램도 잘못된 파일을 삭제하거나 권한을 엉뚱하게 설정할 수 있습니다. 이처럼 프로그램이 판단이나 동작을 잘못하는 문제를 논리 오류라고 합니다.

Rust를 도입하면 어떤 결함을 줄일 수 있는지 구체적으로 따져봐야 하는 이유입니다. 특정 종류의 결함을 줄일 수 있다는 장점은 분명합니다. 파일 처리 도구가 정확하게 동작하는지는 별도로 검증해야 합니다.

실패할 때의 동작도 같아야 합니다

파일 하나를 정상적으로 복사했다고 해서 cp가 호환된다고 볼 수는 없습니다. 복사할 권한이 없을 때도 확인해야 합니다. 대상 파일이 이미 있거나 저장 공간이 부족할 때 어떻게 동작하는지도 살펴봐야 합니다.

특히 스크립트는 명령어의 종료 코드를 자주 확인합니다. 종료 코드는 실행 결과를 숫자로 알려주는 신호입니다. 일반적으로 0은 성공을 뜻하며, 스크립트는 이 값을 보고 다음 작업을 진행할지 중단할지 정합니다.

파일 일부를 처리한 뒤 실패할 때는 더 살펴볼 것이 있습니다. 어디까지 처리했는지, 마지막에 어떤 종료 코드를 반환했는지가 기존 구현과 다르면 뒤이어 실행하는 작업도 달라질 수 있습니다.

파일 자체의 속성도 확인해야 합니다. cp -p처럼 속성을 보존하려는 명령은 파일 내용뿐 아니라 권한과 시간 정보도 제대로 보존하는지 검증해야 합니다. 다른 경로를 가리키는 심볼릭 링크도 마찬가지입니다. 링크 자체를 다루는지, 링크가 가리키는 파일을 다루는지에 따라 결과가 달라집니다.

그래서 호환성 테스트에는 정상 입력과 잘못된 입력이 모두 필요합니다. 기존 구현의 테스트를 활용하면서, 배포판과 사용자가 실제로 실행하는 스크립트도 함께 확인해야 합니다.

Rust로 만들면 더 빠를까요?

언어만으로 속도를 판단할 수는 없습니다. Rust와 C로 작성한 코드는 모두 효율적인 기계어로 컴파일할 수 있습니다. 실제 속도는 어떤 알고리즘을 쓰고 메모리를 어떻게 다루느냐에 따라 달라집니다. 운영체제 기능을 쓰는 방법도 영향을 줍니다.

예를 들어 큰 파일 하나를 복사할 때는 저장장치 속도의 영향을 크게 받습니다. 작은 파일을 많이 복사할 때는 파일을 열고 속성을 확인하는 데 드는 비용이 두드러질 수 있습니다. 같은 cp를 써도 작업에 따라 속도를 제한하는 요인이 달라집니다.

sort처럼 데이터를 처리하는 명령은 사정이 다릅니다. 입력이 얼마나 큰지, 어떤 방식으로 정렬하는지에 따라 결과가 달라지고 메모리 사용량도 영향을 줍니다. 언어와 지역에 따른 문자 정렬 규칙을 처리하는지도 비교 조건에 넣어야 합니다.

성능을 비교하려면 같은 하드웨어에서 같은 입력과 옵션을 써야 합니다. 결과가 정확한지 먼저 확인하고, 실행 시간과 메모리 사용량을 함께 살펴봐야 합니다. 일부 기능을 빠뜨려서 빨라진 경우와 같은 일을 더 빨리 끝낸 경우는 구분해야 합니다.

우분투의 기본 명령어를 Rust로 바꾸는 선택이 설득력을 얻으려면, 메모리를 더 안전하게 다루면서 기존 동작도 지킨다는 점을 보여줘야 합니다. 저는 오래된 자동화 작업이 그대로 돌아가면서 결함도 줄었는지를 가장 중요한 성공 기준으로 봅니다. 서버에서 이 전환을 시험할 때도 어떤 스크립트부터 실행해 볼지 구체적으로 짚어볼 필요가 있습니다.