시스템 폴더
1. 개요
Microsoft Windows, macOS, 리눅스와 같은 운영 체제에서 기능 확장, 제어판, 폰트 등의 기본적 파일 및 하위 시스템 지원 파일 등을 포함하는 커널을 담고 있는 중요한 폴더. 따라서 폴더 전체 혹은 폴더 일부를 수정하면 컴퓨터 전체가 부팅이 안 되거나 OS를 재설치해야 할 수 있다.
2. 상세
운영체제 종류 및 버전, 시스템 비트 수에 따라 그 위치가 달라진다. 다음은 Windows 기준 시스템 폴더의 위치.
Windows Vista 이후부터 윈도우 설치 폴더 아래에 WinSxS(Side-by-Side) 디렉터리가 존재한다. 윈도우 업데이트 등으로 대체된 구버전 파일이 필요한 경우에 대비해서 쌓아두는 공간이다.[7]
3. 주의사항
'''절대 삭제하면 안 된다.''' 과거부터 지금까지 컴퓨터를 잘 모르는 수많은 사람들이 컴퓨터에 생긴 문제를 해결하기 위해 질문글을 올렸는데 장난기 많은 사람들이 낚시를 하기 위해서 컴퓨터 에러 질문글에 "Windows 폴더 밑의 system32를 삭제해라."는 답변을 달아주고 있으며[8] 진짜로 지웠다가 컴퓨터를 망가뜨린 사람들도 자주 보인다.[9] 특히 나이 어린 아이들이나 연세가 많은 어르신들이 곧잘 속아넘어가는 경우가 많다. 이 폴더를 함부로 건드리거나 안의 파일들을 삭제할 경우 컴퓨터 작동에 문제가 생길 수 있다.
하지만 다행히도 Windows Vista(2008) 부터 Windows 10(2016, 2019) 까지는 Windows 탐색기 자체를 '''SYSTEM 계정'''으로 실행 중이라 하더라도 소유자가 무조건 TrustedInstaller로 설정되어 편집 자체를 막고 있고[10] Windows 8부터는 UAC를 끄더라도 이 폴더에 뭔 짓을 하려 한다면 UAC에서 이를 차단한다.[11] 즉, 쉽게 말하자면 폴더 찾아 들어가서 삭제를 하는 일반적인 방법으로는 절대 삭제가 불가능하다. 굳이 삭제를 하자면 system32에 걸린 권한을 전부 삭제하거나 소유자에게로 가지고 오면 가능하긴 하다.
system32 폴더를 지웠을 때 일어나는 일을 자세히 설명한 영상.
system32 폴더를 지워도 부팅할 때 어느 정도 복구가 가능하지만 더 무서운 건 레지스트리를 지웠을 경우엔 복구조차 어렵다.
4. 기타
리눅스 등 유닉스 계열에서는 /boot, /dev, /etc, /root, /usr 등이 전부 시스템 폴더이다. 다행히 이 폴더들은 시스템 특성상 루트 사용자(root)가 아니면 아예 수정조차 못하게 막고 있다. macOS는 여기에 /Library, /System도 시스템 폴더로 잡혀서 계정 비밀번호를 요구한다. *NIX 시스템에서 권한에 관계없이 마구 수정해도 되는 것은 시스템 또는 배포판에 따라 다르지만 /var, /tmp, 그리고 자신의 홈 디렉터리(~/.) 정도가 전부. 물론 sudo로 rm -rf /를 수행했다면 얄짤없다. 물론 rm -rf는 하도 사고가 많이 나서 이런저런 안전 장치가 붙어있다. 게다가 macOS는 10.11 버전에서 루트리스를 추가하면서 아예 삭제하지 못하게 바뀌었다.
MS-DOS에서는 안전 장치가 전혀 없기 때문에 시스템 폴더를 함부로 건드리면 매우 위험하다. 아이러니하게도 이러한 점 때문에 커널을 무조건 뚫고 하드웨어에 '''직접''' 접근해야만 하는 유틸리티는 대부분 DOS 전용으로만 나오고 있다.[12][13] 이 경우 말고 하드웨어에 직접적으로 접근할 수 있는 유일한 방법은 바이오스를 통하는 것뿐인데 이마저도 요즘 컴퓨터들은 UEFI로 대체되었으며 안전 부팅(Secure Boot)이란 것도 기본으로 돌아가기 때문에 사실상 불가능해졌다. 대부분의 컴퓨터 메인보드들의 롬에는 UEFI가 심어져 있을 경우 CSM이라 하는 호환성 지원모듈이 포함되어 있기에 이 모듈이 빠지지 않는 한 하드웨어로 직접 접근 및 제어하는 것 자체가 불가능하지는 않을 것이다. 문제는 UEFI를 개발한 인텔이 사용 용도를 불문하고 CSM을 흔적도 없이 날려버린 UEFI Class 3를 2020년까지, 이후에는 3+까지 도입하게 될 것으로 예상되는 상황인데 이렇게 되면 진짜로 하드웨어에 직접적으로 접근 제어를 하는 작업을 다른 방법으로 대체하는 수밖에 없어진다.[14] UEFI를 독자적으로 개발하여 규격을 개방한 업체가 인텔이기에 당연히 최고 개발위치인 인텔의 말을 듣는 수밖에 없기 때문이다.
[1] 3.x까지만 해도 시스템 구조가 단순했기 때문에 Windows 폴더 안에 대부분 저장했다. 이 시절의 잔재로 notepad.exe이나 write.exe와 같은 일부 파일들은 Windows 폴더와 System32 폴더, SysWOW64 폴더에 모두 존재한다.[2] System32도 있지만 일부 드라이버 파일만 보관되며 기타 시스템 운영에 필요한 파일에는 거의 이용되지 않는다.[3] Windows 2000까지는 WINNT였다.[4] System도 남아 있는데 여기에는 16비트 프로그램의 하위 호환에 사용되는 시스템 파일 및 드라이버 파일이 들어 있다. 현재는 16비트 프로그램이 고사했기 때문에 그다지 의미가 없어졌다. 64비트에서는 아예 비어있다.[5] System32는 64비트용 시스템 파일 보관, SysWOW64는 에뮬레이트된 32비트용 시스템 파일을 보관한다. 이렇게 된 이유는 System32라는 폴더 이름이 너무 오랫동안 쓰여서 괜히 바꿨다가 호환성 문제가 생길 수 있기 때문이다. 그렇게 바뀐 사실을 미처 파악하지 못한 프로그래머들 사이에서 혼선을 빚다가 대응이 안 되는 수도 있을 것이고.[6] 64비트 윈도우에서는 일반적인 32비트 프로그램이 System32 경로의 파일에 접근하려 하면 실제로는 SysWOW64에 있는 파일로 접근하게 되어 있다. 만약 32비트 프로그램이 System32(64비트) 폴더에 접근해야 한다면 프로그래밍 시 특정한 선언을 정의해야 한다. 참고로 WOW64는 ''''W'''indows 32-Bit '''o'''n '''W'''indows '''64'''-Bit'에서 나왔는데, '64비트 Windows 위의 32비트 Windows'를 의미한다.[7] Windows XP에도 WinSxS 폴더가 존재하기는 하지만 용도가 다르다.[8] 언어 국적 불문하고 널리 퍼진 세계적인 낚시이다.[9] Windows XP까지는 제한된 계정을 제외한 관리자/파워유저 권한을 부여받은 사용자는 system32의 내용을 아무런 권한 설정없이 수정할 수 있다. 심지어, 운영 체제에서 중요한 폴더들의 소유자는 SYSTEM 계정으로 설정되어 있어 누군가가 악의적인 목적으로 SYSTEM 권한을 탈취해버리기라도 하다가는 그냥 당하고 있는 수 밖에 없었다.[10] 물론 takeown과 icacls 명령어를 이용하여 소유자와 권한을 가져오면 삭제는 된다만 윈도우를 재설치해도 전혀 상관없는 상황이 아닌 이상은 절대로 하지 말자. Windows 7 한정으로는 파일 탐색기를 SYSTEM 권한으로 실행하는 것 또한 마찬가지로 절대로 하면 안 된다. 탐색기를 실행한 상태에서 로그온을 하면 사용자 설정이 영구적으로 망가져버리기 때문이다.[11] Windows 8부터 Windows 10 RS2까지는 UAC를 꺼도 알림창만 띄우지 않을 뿐 실제로는 UAC가 돌아가기는 한다. 레지스트리를 조작하거나 Administrator 계정을 쓰면 UAC를 우회할 수 있지만 이렇게 하면 설정 앱을 제외한 Windows 스토어 앱이 열리지 않는다. 이 방법을 쓰면 Administrator 계정에서도 스토어 앱을 열 수 있지만 Administrator 계정의 관리자 권한을 없애버리기 때문에 UAC가 다시 동작한다. RS3 빌드부터 스토어 앱을 열 수 있게 바뀌었지만 사용자 계정 설정에서 UAC를 완전히 끌 수 없는 것은 동일하다. 참고로 Administrator 계정이 기본적으로 사용되는 Server 계열 운영 체제는 기본적으로 설정 앱을 제외한 UWP 앱이 존재하지 않는다.[12] 과거에는 Windows 9x용도 있었으나 Windows NT 계열에서는 동작하는 일이 차단되어 있기 때문에 사장되었다. 사실 9x용도 커널 특성상 DOS로 우회해서 동작하는 방식이었다. 9x용은 아마도 GUI를 선호하는 사용자들의 편의를 고려해서 출시했을 수도 있다.[13] 이러한 점을 악용해서 탄생 한 것이 바로 CIH 바이러스 였다.[14] 호환성이 중요한 서버 보드 같은 제품들이나 듀얼 바이오스 비슷하게 롬 칩을 두 개 심는 식으로 대응 할 가능성이 있겠지만 서버를 제외한 용도의 메인보드라면 이 방법조차 가망이 없다.