최근 수정 시각 : 2024-04-16 18:19:15

시스템 폴더

1. 개요2. 상세3. 주의사항4. 기타

1. 개요

Microsoft Windows, macOS, 리눅스와 같은 운영체제에서 기능 확장, 제어판, 폰트 등의 기본적 파일 및 하위 시스템 지원 파일 등을 포함하는 커널을 담고 있는 중요한 폴더. 따라서 폴더 전체 혹은 폴더 일부를 수정하면 컴퓨터 전체가 부팅이 안 되거나 OS를 재설치해야 할 수 있다.

2. 상세

운영체제 종류 및 버전, 시스템 비트 수에 따라 그 위치가 달라진다. 다음은 Windows 기준 시스템 폴더의 위치.
Windows 시스템 폴더
MS-DOS(16비트) 기반 \\Windows[1]
9x 커널(16/32비트) 기반 \\Windows\\System[2]
NT 커널(32비트) 기반 \\Windows[3]\\System32[4]
NT 커널(64비트) 기반 \\Windows\\System32[5]
\\Windows\\SysWOW64[6]

Windows Vista 이후부터 윈도우 설치 폴더 아래에 WinSxS(Side-by-Side) 디렉터리가 존재한다. 윈도우 업데이트 등으로 대체된 구버전 파일이 필요한 경우에 대비해서 쌓아두는 공간이다.[7]

3. 주의사항

절대 삭제하면 안 된다. 과거부터 지금까지 컴퓨터를 잘 모르는 수많은 사람들이 컴퓨터에 생긴 문제를 해결하기 위해 질문글을 올렸는데 장난기 많은 사람들이 낚시를 하기 위해서 컴퓨터 에러 질문글에 "Windows 폴더 밑의 system32를 삭제해라."는 답변을 달아주고 있으며[8] 진짜로 지웠다가 컴퓨터를 망가뜨린 사람들도 자주 보인다.[9] 특히 나이 어린 아이들이나 연세가 많은 어르신들이 곧잘 속아넘어가는 경우가 많다. 이 폴더를 함부로 건드리거나 안의 파일들을 삭제할 경우 컴퓨터 작동에 문제가 생길 수 있다.

하지만 다행히도 Windows Vista(2008) 부터 Windows 11(~2022) 까지는 Windows 탐색기 자체를 SYSTEM 계정으로 실행 중이라 하더라도 소유자가 무조건 TrustedInstaller로 설정되어 편집 자체를 막고 있고[10] Windows 8부터는 UAC를 끄더라도 이 폴더에 뭔 짓을 하려 한다면 UAC에서 이를 차단한다.[11] 즉, 쉽게 말하자면 폴더 찾아 들어가서 삭제를 하는 일반적인 방법으로는 절대 삭제가 불가능하다. 굳이 삭제를 하자면 system32에 걸린 권한을 전부 삭제하기 전에, 소유자를 TrustedInstaller에서 사용자 계정으로 변경해버리면 가능하긴 하다.


system32 폴더를 지웠을 때 일어나는 일을 자세히 설명한 영상.

system32 폴더를 지워도 부팅할 때 어느 정도 복구가 가능하지만 더 무서운 건 레지스트리를 지웠을 경우엔 복구조차 어렵다. 그런데 레지스트리 파일이 system32 안에 있다는 것이 함정[12]

결론적으로, 절대 system32 폴더에 손대지 말자!

4. 기타

리눅스유닉스 계열에서는 /boot, /dev, /etc, /usr 등이 전부 시스템 폴더이다. 다행히 이 폴더들은 시스템 특성상 루트 사용자(root)가 아니면 아예 수정조차 못하게 막고 있다. macOS는 여기에 /Library, /System도 시스템 폴더로 잡혀서 계정 비밀번호를 요구한다. *NIX 시스템에서 권한에 관계없이 마구 수정해도 되는 것은 시스템 또는 배포판에 따라 다르지만 /var, /tmp, 그리고 자신의 홈 디렉터리(~/.) 정도가 전부. 물론 sudo로 rm -rf /를 수행했다면 얄짤없다. 물론 rm -rf는 하도 사고가 많이 나서 이런저런 안전 장치가 붙어있다. 게다가 macOS는 10.11 버전에서 루트리스를 추가하면서 아예 삭제하지 못하게 바뀌었다.

MS-DOS에서는 안전 장치가 전혀 없기 때문에 시스템 폴더를 함부로 건드리면 매우 위험하다. 역설적이게도 이러한 점 덕분에 커널을 무조건 뚫고 하드웨어에 직접 접근해야만 하는 상당수의 유틸리티들은 DOS 전용으로만 출시했다.[13][14] 이 경우 말고 하드웨어에 직접적으로 접근할 수 있는 유일한 방법은 바이오스를 통하는 것뿐인데 이마저도 요즘 컴퓨터들은 UEFI로 대체되었으며 UEFI Class 2.2가 롬에다가 기본적으로 탑재된 보드들 부터는 안전 부팅(Secure Boot)이란 것도 기본으로 돌아가기 때문에 사실상 불가능해졌다.[15] 대부분의 컴퓨터 메인보드들의 롬에는 UEFI가 심어져 있을 경우 CSM이라 하는 호환성 지원모듈이 포함되어 있기에 이 모듈이 빠지지 않는 한 하드웨어로 직접 접근 및 제어하는 것 자체가 아주 불가능 하지는 않다. 문제는 UEFI를 개발한 인텔이 사용 용도를 불문하고 CSM을 흔적도 없이 날려버린 UEFI Class 3를 2020년까지 도입 할 것이라 공언했고, 실제로 2019년 부터 출시되는 대부분의 데스크탑과 워크스테이션, 노트북 제품들 부터는 Class 3가 적용되기 시작했다. 이후에는 3+[16]까지 도입하게 될 것으로 예상되는 상황인데 이렇게 되면 진짜로 하드웨어에 직접적으로 접근 제어를 하는 작업을 다른 방법으로 대체하는 수밖에 없어진다.[17] UEFI를 독자적으로 개발하여 규격을 개방한 업체가 인텔이기에 당연히 최고 개발위치인 인텔의 말을 듣는 수밖에 없기 때문이다.


[1] 3.x까지만 해도 시스템 구조가 단순했기 때문에 Windows 폴더 안에 대부분 저장했다. 이 시절의 잔재로 notepad.exe이나 write.exe와 같은 일부 파일들은 Windows 폴더와 System32 폴더, SysWOW64 폴더에 모두 존재한다.[2] System32도 있지만 일부 드라이버 파일만 보관되며 기타 시스템 운영에 필요한 파일에는 거의 이용되지 않는다.[3] Windows NT 3.x 부터 Windows 2000까지는 WINNT였다.[4] System도 남아 있는데 여기에는 16비트 프로그램의 하위 호환에 사용되는 시스템 파일 및 드라이버 파일이 들어 있다. 현재는 16비트 프로그램이 고사했기 때문에 그다지 의미가 없어졌다. 64비트에서는 아예 비어있다.[5] System32는 64비트용 시스템 파일 보관, SysWOW64는 에뮬레이트된 32비트용 시스템 파일을 보관한다. 이렇게 된 이유는 System32라는 폴더 이름이 너무 오랫동안 쓰여서 괜히 바꿨다가 호환성 문제가 생길 수 있기 때문이다. 그렇게 바뀐 사실을 미처 파악하지 못한 프로그래머들 사이에서 혼선을 빚다가 대응이 안 되는 수도 있을 것이고.[6] 64비트 윈도우에서는 일반적인 32비트 프로그램이 System32 경로의 파일에 접근하려 하면 실제로는 SysWOW64에 있는 파일로 접근하게 되어 있다. 만약 32비트 프로그램이 System32(64비트) 폴더에 접근해야 한다면 프로그래밍 시 특정한 선언을 정의해야 한다. 참고로 WOW64는 'Windows 32-Bit On Windows 64-Bit'에서 나왔는데, '64비트 Windows 위의 32비트 Windows'를 의미한다.[7] Windows XP에도 WinSxS 폴더가 존재하기는 하지만 용도가 다르다.[8] 언어 국적 불문하고 널리 퍼진 세계적인 낚시이다.[9] Windows XP까지는 제한된 계정을 제외한 관리자/파워유저 권한을 부여받은 사용자는 system32의 내용을 아무런 권한 설정없이 수정할 수 있다. 심지어, 운영 체제에서 중요한 폴더들의 소유자는 SYSTEM 계정으로 설정되어 있어 누군가가 악의적인 목적으로 SYSTEM 권한을 탈취해버리기라도 하다가는 그냥 당하고 있는 수 밖에 없었다.[10] 물론 takeown과 icacls 명령어를 이용하여 소유자와 권한을 가져오면 삭제는 된다만 윈도우를 재설치해도 전혀 상관없는 상황이 아닌 이상은 절대로 하지 말자. Windows 7(2008 R2) 한정으로는 파일 탐색기를 SYSTEM 권한으로 실행하는 것 또한 마찬가지로 절대로 하면 안 된다. 탐색기를 실행한 상태에서 로그온을 하면 사용자 설정이 영구적으로 망가져버리기 때문이다.[11] Windows 8부터 Windows 10 RS2까지는 UAC를 꺼도 알림창만 띄우지 않을 뿐 실제로는 UAC가 돌아가기는 한다. 레지스트리를 조작하거나 Administrator 계정을 쓰면 UAC를 우회할 수 있지만 이렇게 하면 설정 앱을 제외한 Windows 스토어 앱이 열리지 않는다. 이 방법을 쓰면 Administrator 계정에서도 스토어 앱을 열 수 있지만 Administrator 계정의 관리자 권한을 없애버리기 때문에 UAC가 다시 동작한다. RS3 빌드부터 스토어 앱을 열 수 있게 바뀌었지만 사용자 계정 설정에서 UAC를 완전히 끌 수 없는 것은 동일하다. 참고로 Administrator 계정이 기본적으로 사용되는 Server 계열 운영 체제는 기본적으로 설정 앱을 제외한 UWP 앱이 존재하지 않는다.[12] HKEY_LOCAL_MACINE라는 키는 C:\\Windows\\System32\\Config 폴더에 레지스트리 파일들이 위치하고 있다.[13] 물론, Windows 9x용도 있었으나 Windows NT 계열에서는 동작하는 일이 차단되어 있기 때문에 사장되었다. 사실 9x용도 커널 특성상 DOS로 우회해서 동작하는 방식이었다. 9x용은 아마도 GUI를 선호하는 사용자들의 편의를 고려해서 출시했을 수도 있다.[14] 이러한 보안상의 취약점을 악용해서 탄생 한 것이 바로 CIH 바이러스 였다.[15] 다만, 메인보드, 대기업 완제품 PC 제조업체들에 따라서는 기본적인 세팅값이 서로 상이 할 수도 있다.[16] UEFI Class 3와 동일하나 Secure Boot가 켜진 상태이며, 서명되지 않은 UEFI 코드를 실행할 수가 없다고 전해지는 버전이다.[17] 안정성 못지않게 호환성도 중요시 여겨야 하는 일부 서버용, 산업용 메인보드 같은 제품들이나 듀얼 바이오스 비슷하게 롬 칩을 두 개 심는 식으로 대응 할 가능성이 있겠지만 상당수의 메인보드들은 따로 개조 할 방법이 없는 이상 가망이 없다.

분류