루트 계정이나 sudo를 이용해서 루트 권한을 획득한 후 rm -rf /를 입력하면 시스템에 존재하는 모든 파일이 증발한다. WSL도 예외는 아니라서 리눅스 시스템이 윈도우와 동반 사망하는 경우도 있다. 이 작업 이후에는 현재 실행중인 프로세스와 런타임 모듈들만 메모리에 남고 컴파일러, 라이브러리, 모든 실행 파일도 같이 증발하기 때문에 재부팅을 하고 나면 복구 불능 상태가 되어버린다. 유일하게 남은 것은 그 명령어를 실행한 셸인데 이 도구와 리눅스 필수 유틸리티에 대한 바이너리 정보만 남아있으면 복구가 가능할까? 개인적인 의견이지만 이론상 복구는 가능하다. 하지만 문제점들을 현실적으로 바라보고 한계점을 알아본다.

1. 셸 그 자체로 프로그래밍이 가능하지만 기계어 코드를 생성해낼 능력이 있는가?
일단 가능은 하다. 왜냐하면 유닉스 시스템은 흔히 텍스트만을 처리하는 시스템으로 착각할 수는 있지만 실제로는 바이트의 나열만을 처리하는 시스템이고 사용자 인터페이스가 대부분 바이트를 텍스트로 인식하도록 되어있을 뿐이다. 즉 바이트 배열을 생성할 수는 있다. 그런데 문제는 셸 또한 텍스트를 다루는 프로그램이기 때문에 헥스 에디터 수준의 바이트 입력을 기대하긴 어렵다.

2. 셸이 모든 기능을 담고있지 않다.
셸은 아주 기본적인 프로그래밍 문법과 유닉스 유틸리티중의 일부를 가지고 있다. 그러나 cd는 있지만 ls는 없고 그 말은 현재 디렉터리의 파일 목록을 읽을 수는 없다. 대부분의 유닉스 유틸리티는 프로세스 외부의 바이너리 폴더에 존재하고 자주 사용하는 명령어 일부만 해시되어 프로세스에 적재하는게 아니라 디스크에서 바로 찾을 수 있도록 기능을 가지고 있을 뿐이라서 먼저 유닉스 필수 유틸리티들을 복구해야 할 것 같다.

3. 복구에 사용되는 프로그램의 바이너리 정보를 어떻게 기록할 수 있을까?
당장 자주 쓰이는 컴파일러의 용량만 수백 킬로바이트고 절대 적은 용량이 아니다. 문자로 저장해도 수십 페이지, 축약해도 매우 길다. 그리고 이 문서의 무결성을 검증하는 것도 어렵다. 한 바이트라도 틀리면 폭주하니까... 다행히 프린터로 인쇄하는 것도 하나의 방법이겠지만 그럴거면 차라리 복구 디스크를 하나 만드는게 낫다.

4. 결정적으로 chmod는 외부에 있다.
그렇게 뻘짓을 해서 어렵게 만들어낸 바이너리 파일을 실행시킬 수 없다. 알다시피 유닉스 시스템은 바이트만을 다루는 시스템이고 해석 방식에 따라 텍스트냐, 실행 파일이냐가 갈리기 때문에 반드시 실행 가능 비트를 설정해줘야 하지만 이 작업을 맡는 chmod 명령어가 셸 내장 명령어가 아니라서 rm -rf /의 폭풍에서 살아남기는 어려울 것 같다.

결론 :
복구는 가능하지만 여러가지 제약 때문에 복구하기도 어렵고 복구가 가능하더라도 사용할 수 있는 상태는 아니게 된다.