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

== 상세 ==
운영체제 종류 및 버전, 시스템 비트 수에 따라 그 위치가 달라진다. 다음은 Windows 기준 시스템 폴더의 위치.

||<-2> Windows 시스템 폴더 ||
|| [[MS-DOS]](16비트) 기반 || \\Windows[* 3.x까지만 해도 시스템 구조가 단순했기 때문에 Windows 폴더 안에 대부분 저장했다. 이 시절의 잔재로 [[메모장|notepad.exe]]이나 [[워드패드|write.exe]]와 같은 일부 파일들은 Windows 폴더와 System32 폴더, SysWOW64 폴더에 모두 존재한다.] ||
|| [[Windows 9x|9x 커널]](16/32비트) 기반 || \\Windows\\System[* System32도 있지만 일부 드라이버 파일만 보관되며 기타 시스템 운영에 필요한 파일에는 거의 이용되지 않는다.] ||
|| [[윈도우 커널|NT 커널]](32비트) 기반 || \\Windows[* [[Windows NT 3.x]] 부터 [[Windows 2000]]까지는 WINNT였다.]\\System32[* System도 남아 있는데 여기에는 16비트 프로그램의 하위 호환에 사용되는 시스템 파일 및 드라이버 파일이 들어 있다. 현재는 16비트 프로그램이 고사했기 때문에 그다지 의미가 없어졌다. 64비트에서는 아예 비어있다.] ||
|| NT 커널(64비트) 기반 || \\Windows\\System32[* System32는 64비트용 시스템 파일 보관, SysWOW64는 에뮬레이트된 32비트용 시스템 파일을 보관한다. 이렇게 된 이유는 System32라는 폴더 이름이 너무 오랫동안 쓰여서 괜히 바꿨다가 호환성 문제가 생길 수 있기 때문이다. 그렇게 바뀐 사실을 미처 파악하지 못한 프로그래머들 사이에서 혼선을 빚다가 대응이 안 되는 수도 있을 것이고.][br]\\Windows\\SysWOW64[* 64비트 윈도우에서는 일반적인 32비트 프로그램이 System32 경로의 파일에 접근하려 하면 실제로는 SysWOW64에 있는 파일로 접근하게 되어 있다. 만약 32비트 프로그램이 System32(64비트) 폴더에 접근해야 한다면 프로그래밍 시 특정한 선언을 정의해야 한다. 참고로 WOW64는 ''''W'''indows 32-Bit '''O'''n '''W'''indows '''64'''-Bit'에서 나왔는데, '64비트 Windows 위의 32비트 Windows'를 의미한다.] ||

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

== 주의사항 ==
'''절대 삭제하면 안 된다.''' 과거부터 지금까지 컴퓨터를 잘 모르는 수많은 사람들이 컴퓨터에 생긴 문제를 해결하기 위해 질문글을 올렸는데 장난기 많은 사람들이 낚시를 하기 위해서 컴퓨터 에러 질문글에 "[[여러분 이거 다 거짓말인 거 아시죠|Windows 폴더 밑의 system32를 삭제해라.]]"는 답변을 달아주고 있으며[* 언어 국적 불문하고 널리 퍼진 세계적인 낚시이다.] 진짜로 지웠다가 컴퓨터를 망가뜨린 사람들도 자주 보인다.[* Windows XP까지는 제한된 계정을 제외한 관리자/파워유저 권한을 부여받은 사용자는 system32의 내용을 아무런 권한 설정없이 수정할 수 있다. 심지어, 운영 체제에서 중요한 폴더들의 소유자는 SYSTEM 계정으로 설정되어 있어 누군가가 악의적인 목적으로 SYSTEM 권한을 탈취해버리기라도 하다가는 그냥 당하고 있는 수 밖에 없었다.] 특히 나이 어린 아이들이나 연세가 많은 어르신들이 곧잘 속아넘어가는 경우가 많다. 이 폴더를 함부로 건드리거나 안의 파일들을 삭제할 경우 컴퓨터 작동에 문제가 생길 수 있다.

하지만 다행히도 [[Windows Vista]]([[Windows Server 2008|2008]]) 부터 [[Windows 11]](~[[Windows Server 2022|2022]]) 까지는 Windows 탐색기 자체를 '''[[:파일:LogoSYSTEMUser.png|SYSTEM 계정]]'''으로 실행 중이라 하더라도 소유자가 무조건 TrustedInstaller로 설정되어 편집 자체를 막고 있고[* 물론 takeown과 icacls 명령어를 이용하여 소유자와 권한을 가져오면 삭제는 된다만 윈도우를 재설치해도 전혀 상관없는 상황이 아닌 이상은 절대로 하지 말자. [[Windows 7]]([[Windows Server 2008 R2|2008 R2]]) 한정으로는 파일 탐색기를 SYSTEM 권한으로 실행하는 것 또한 마찬가지로 절대로 하면 안 된다. 탐색기를 실행한 상태에서 로그온을 하면 사용자 설정이 영구적으로 망가져버리기 때문이다.] [[Windows 8]]부터는 [[사용자 계정 컨트롤|UAC]]를 끄더라도 이 폴더에 뭔 짓을 하려 한다면 UAC에서 이를 차단한다.[* [[Windows 8]]부터 [[Windows 10]] RS2까지는 UAC를 꺼도 알림창만 띄우지 않을 뿐 실제로는 UAC가 돌아가기는 한다. 레지스트리를 조작하거나 [[Administrator]] 계정을 쓰면 UAC를 우회할 수 있지만 이렇게 하면 설정 앱을 제외한 Windows 스토어 앱이 열리지 않는다. [[http://blog.naver.com/qutycrow/220707522630|이 방법]]을 쓰면 Administrator 계정에서도 스토어 앱을 열 수 있지만 Administrator 계정의 관리자 권한을 없애버리기 때문에 UAC가 다시 동작한다. RS3 빌드부터 스토어 앱을 열 수 있게 바뀌었지만 사용자 계정 설정에서 UAC를 완전히 끌 수 없는 것은 동일하다. 참고로 Administrator 계정이 기본적으로 사용되는 Server 계열 운영 체제는 기본적으로 설정 앱을 제외한 UWP 앱이 존재하지 않는다.] 즉, 쉽게 말하자면 폴더 찾아 들어가서 삭제를 하는 일반적인 방법으로는 절대 삭제가 불가능하다. 굳이 삭제를 하자면 system32에 걸린 권한을 전부 삭제하기 전에, 소유자를 TrustedInstaller에서 사용자 계정으로 변경해버리면 가능하긴 하다.

[youtube(BBWT2CqEsO0)]
{{{#red '''system32 폴더를 지웠을 때 일어나는 일을 자세히 설명한 영상.'''}}}

system32 폴더를 지워도 부팅할 때 어느 정도 복구가 가능하지만 더 무서운 건 [[레지스트리]]를 지웠을 경우엔 복구조차 어렵다. ~~그런데 레지스트리 파일이 system32 안에 있다는 것이 함정~~[* HKEY_LOCAL_MACINE라는 키는 C:\\Windows\\System32\\'''Config''' 폴더에 레지스트리 파일들이 위치하고 있다.]

{{{#red '''결론적으로, 절대 system32 폴더에 손대지 말자!'''}}}


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

[[MS-DOS]]에서는 안전 장치가 전혀 없기 때문에 시스템 폴더를 함부로 건드리면 매우 위험하다. 역설적이게도 이러한 점 덕분에 커널을 무조건 뚫고 하드웨어에 '''직접''' 접근해야만 하는 상당수의 유틸리티들은 DOS 전용으로만 출시했다.[* 물론, [[Windows 9x]]용도 있었으나 [[Windows NT]] 계열에서는 동작하는 일이 차단되어 있기 때문에 사장되었다. 사실 9x용도 커널 특성상 DOS로 우회해서 동작하는 방식이었다. 9x용은 아마도 GUI를 선호하는 사용자들의 편의를 고려해서 출시했을 수도 있다.][* 이러한 보안상의 취약점을 악용해서 탄생 한 것이 바로 [[CIH 바이러스]] 였다.] 이 경우 말고 하드웨어에 직접적으로 접근할 수 있는 유일한 방법은 [[바이오스]]를 통하는 것뿐인데 이마저도 요즘 컴퓨터들은 [[UEFI]]로 대체되었으며 UEFI Class 2.2가 롬에다가 기본적으로 탑재된 보드들 부터는 [[UEFI#Secure Boot|안전 부팅(Secure Boot)]]이란 것도 기본으로 돌아가기 때문에 사실상 불가능해졌다.[* 다만, 메인보드, 대기업 완제품 PC 제조업체들에 따라서는 기본적인 세팅값이 서로 상이 할 수도 있다.] 대부분의 컴퓨터 메인보드들의 롬에는 [[UEFI]]가 심어져 있을 경우 [[CSM#Compatibility Support Module의 약자]]이라 하는 [[UEFI#CSM|호환성 지원모듈]]이 포함되어 있기에 이 모듈이 빠지지 않는 한 하드웨어로 직접 접근 및 제어하는 것 자체가 아주 불가능 하지는 않다. 문제는 [[UEFI]]를 개발한 [[인텔]]이 사용 용도를 불문하고 CSM을 흔적도 없이 날려버린 UEFI Class 3를 2020년까지 도입 할 것이라 공언했고, 실제로 2019년 부터 출시되는 대부분의 데스크탑과 워크스테이션, 노트북 제품들 부터는 Class 3가 적용되기 시작했다. 이후에는 3+[* UEFI Class 3와 동일하나 Secure Boot가 켜진 상태이며, 서명되지 않은 UEFI 코드를 실행할 수가 없다고 전해지는 버전이다.]까지 도입하게 될 것으로 예상되는 상황인데 이렇게 되면 진짜로 하드웨어에 직접적으로 접근 제어를 하는 작업을 다른 방법으로 대체하는 수밖에 없어진다.[* 안정성 못지않게 호환성도 중요시 여겨야 하는 일부 서버용, 산업용 메인보드 같은 제품들이나 듀얼 바이오스 비슷하게 롬 칩을 두 개 심는 식으로 대응 할 가능성이 있겠지만 상당수의 메인보드들은 따로 개조 할 방법이 없는 이상 가망이 없다.] [[UEFI]]를 독자적으로 개발하여 규격을 개방한 업체가 [[인텔]]이기에 당연히 최고 개발위치인 [[까라면 까|인텔의 말을 듣는 수밖에 없기 때문이다]].

[[분류:운영 체제]]