윈도우제품군 3.1~XP까지!

쓰는 일/프로그램 2007.12.14 17:35 Posted by soulfree >동네청년<
시간이 흘러 마이크로소프트의 윈도우가 벌써 20여년의 역사를 가진 운영체제가 되었다. 이 글에서는 윈도우 서버 2003 출시를 계기로 윈도우의 역사적 계보를 살펴보고 각 버전이 역사적으로 어떤 의미가 있고 지구상에 어떤 영향을 끼쳤는지를 살펴본다. 또한 향후 로드맵을 통해 발전 모습과 그것이 지닌 가능성과 한계를 살펴봄으로써 윈도우 세계의 미래를 가늠해 본다. 그리고 마이크로소프트의 야심과 전략을 나름대로 적나라하게 밝혀보려고 한다. 역사를 통해 현재를 본다는 역사학자의 말처럼 이 글을 통해 윈도우의 계보를 살펴보는 것 이상의 감동이 독자에게 전달되었으면 한다.
<!-- 내용 출력 -->신승근 | laborer@dev.co.kr
1992년 숭실대학교 통신 동호회 초대 대표 시삽, 1994년 비주얼 툴 사용자 동호회 초대 회장, 1997년에는 마이크로소프트 디벨로퍼 저널(MDJ) 기술 편집장 등을 역임했다. 핸디소프트 기술연구소 연구원을 거쳐, Microsoft TechED, PDC, Visual Studio Summit, DevDays 초청 강사로도 활동했으며, 현재는 TL 9000 인증을 받은 데브의 CSA 겸 월간 마소의 자문위원이기도 하다. 소프트웨어 개발 방법론과 소프트웨어 아키텍처와 프로젝트 컨설팅을 주로 하고 있으며 소프트웨어 품질 분야에 많은 노력을 쏟아붓고 있다.

90년도 대학생 시절에 윈도우 3.0을 한번 설치해 보겠다고 매장 여직원의 따가운 눈총을 담담히 받아들이면서 매장 한 귀퉁이에 자리잡고 5.25 플로피 디스크에 윈도우 3.0을 복사했던 기억이 가물가물 떠오른다. 지금이야 이런 일을 하면 지식재산권 침해로 무지막지한 벌금에 철창 신세를 져야 하지만 당시에는 복사한 소프트웨어 보유가 일종의 훈장과도 같은 것이었다. 즉 얼마나 많은 소프트웨어를 보유하고 있나, 얼마나 많은 소프트웨어를 사용할 줄 아느냐가 마치 능력의 척도인양 치부되던 시절이었다.
지금이야 소프트웨어 전문 컨설턴트인 필자가 포토샵을 능숙하게 사용하지 못하는 것은 너무 당연하지만 당시에는 모든 소프트웨어를 잘 다루지 못하면 전문가의 반열에 올라설 수 없었다. 당시의 소프트웨어들은 인터페이스가 단순하고 기능이 적어서 제한적인 작업만 가능했으므로 많은 소프트웨어를 익히는 것이 큰 부담이 되지 않기에 가능한 일이었다. 또한 필자는 국산 상업용 소프트웨어 1호격인 아래아한글은 1.x판의 학생용 버전 정품을 구입해서 사용하고 있었지만 친구들은 아래아한글 정품을 구입하는 필자를 이해하지 못하고 아까운 돈을 낭비하거나 어리석은 사람처럼 대했다. 필자는 전산학과를 졸업한 뒤 필자가 만든 소프트웨어를 누군가가 복사한다면, 하지 말라고 떳떳하게 말하기 위해 정품을 사용했다. 그러나 국산은 돈주고 사고 외산은 복사해도 된다는 이율배반적인 논리가 마음 속에 있었던 것은 사실이다.

MS 기술의 출발점, 윈도우의 등장
소프트웨어를 구하기가 쉽지 않아서 외국의 소프트웨어를 경험할 수 있는 보급로 역할을 세운상가가 담당했고, 일부 선각자(?)들은 복제 소프트웨어를 얻을 수 있는 세운상가의 컴퓨터 매장을 하나 정도는 알고 있는 것을 일종의 자부심으로 생각했다. 그 세운상가에서 처음 접한 윈도우 3.0을 매장직원은 이렇게 설명했다. “윈도우 3.0이 발매된 이후로 매킨토시가 죽고 있어요!” 이처럼 ‘매킨토시 킬러’로 불리웠던 마이크로소프트(이하 MS)의 윈도우가 이제 시간이 흘러서 장장 20여년의 역사를 가진 운영체제가 되었다. 이 글에서는 윈도우의 역사적 계보를 살펴보고 각 버전이 역사적으로 어떤 의미가 있고 지구상에 어떤 영향을 끼쳤는지를 살펴본다. 그리고 MS의 야심과 전략을 나름대로 적나라하게 밝혀보려고 한다. 고도의 전략이 숨겨진 것을 알게 된다면 소프트웨어의 개발이 더욱더 어렵게 느껴질 것이다. 이제 모니터 앞에서 밤샘하던 개발자들이 다양한 사고의 세계로 나오지 않는다면 국산 소프트웨어의 미래는 ‘떼돈’과 ‘파벌싸움’으로 얼룩질 것이다. 우리는 역사를 통해 현재를 본다는 역사학자의 말처럼 이 글을 통해 윈도우의 계보를 살펴보는 것 이상의 감동이 독자에게 전달되었으면 한다.
참고로 평상시 필자의 글과는 달리 문헌적 고증을 확실히 하기 위해서 다양한 자료들의 정확한 출처를 공개하겠다. 논문 한 편을 쓰고 나더니 사람이 이렇게 바뀔 수 있냐고 비아냥댈 지인들이 있겠지만, 업그레이드되었음을 만천하에 공개하겠다는 필자의 그윽한 속내(?)를 어찌 이해하리오.

윈도우 1.0의 시작과 비전
윈도우 1.0을 개인적으로 직접 본 적은 없다. 윈도우 1.0을 설치할 IBM 컴퓨터가 너무 비싸서 주위에서 쉽게 접할 수 없었기 때문이다. 86년도에 애플 컴퓨터를 40만원 정도에 구입했을 때도 구입 여부를 몇 번을 망설여야 했는지 모르는데 IBM 컴퓨터는 300만원이 넘었던 것으로 기억한다. 당시에 집 한 채가 2천만원 정도였으므로 지금으로 치면 3천만원도 넘는 돈이니 일반인이 IBM 컴퓨터를 접하기가 어려웠을 것이다. 국내 유일의 컴퓨터 잡지인 마소에서도 IBM 컴퓨터를 다루는 일은 적었다. 그만큼 국내에서는 사용자층이 한정되었다.
MS는 1983년에 11월 10일 컴덱스 쇼에서 윈도우 1.0에 대한 프로젝트 기획을 발표한다(http://moonji.x-y.net/20c/computer/ gates/life.htm). 그 해 1월에 애플 컴퓨터는 그래픽 기반 인터페이스인 Lisa(스티븐 잡스의 딸 이름)를 1만 달러에 내놓는다(http:// jbshop.co.kr/study/win2000/1history.htm). WIMP(Windo ws, Icons, Mice, Pointers)의 개념을 상용 제품으로 처음 선보이는 순간이었다. 윈도우 1.0은 이 경쟁자를 의식해서 만들어졌는지도 모른다. 2년간의 연구개발 끝에 1985년 11월 윈도우 1.0을 제품화한다. 그러나 애플은 Lisa의 실패를 거름삼아서 장장 5년 동안의 연구개발의 결과인 1984년 1월 24일에 매킨토시를 발표한다. 실제로 일부 책의 저자들은 빌 게이츠가 공공연하게 매킨토시를 모방하도록 강요했다고 한다. 어느 회사나 경쟁사의 좋은 점을 수용해서 고객을 빼앗기지 않으려고 하는 것은 당연한 태도라고 생각하지만, 윈도우의 태동은 단지 경쟁 때문이었을까?

“출시 자체에 의의를 둔다”
당시의 컴퓨터 환경을 기억해 보면 윈도우 1.0은 엄청난 시도였다. 매킨토시는 GUI 처리가 용이한 아키텍처를 기반으로 하고 있었지만, 당시의 IBM PC는 단독 응용 프로그램 수행에도 턱없이 부족한 CPU에 그래픽 어댑터도 매우 초보 수준이었음에도 불구하고 빌 게이츠는 이 일에 도전을 한 것이다.
그럼에도 불구하고 출시된 윈도우 1.0은 상업적으로는 실패를 했다. 소프트웨어가 충분하지 않아서 보급 자체가 어려웠다. 그러나 윈도우 1.0은 시작을 위한 첫 번째 포석일 뿐이다. 전직 MS 관계자의 말을 빌리자면 MS의 모든 제품들이 1.0은 출시하는 데 의의를 두고 있었다고 한다. 아무런 홍보도 마케팅도 거의 하지 않았다. 2.0 버전이 나오면 지원 정책이 수립되고 적어도 3.0 버전 이상이 나와야지만 본격적인 마케팅을 시도할 계획이었다(황윤오, 창문이 열립니다-한글 윈도우 2.1에 거는 기대-, 월간 마이크로소프트웨어 1990년 6월호, pp.194).
윈도우 1.0은 여러 개의 응용 프로그램을 한 화면에서 동시에 실행시키고 볼 수는 있지만, 윈도우의 겹침이 되지 않았다고 한다. 이렇게 윈도우의 겹치기가 허용되지 않아서 각 윈도우의 크기가 윈도우 수에 비례해서 작아지는 타일링 방식(테크니컬 그룹, 마이크로소프트 윈도우 2.0과 시스템 개발 키트 1, 컴퓨터매거진, 1998년 10월호, pp.146)을 채택한 것은 어쩌면 바보같은 결정처럼 보일 것이다. 겹치지 않는 윈도우라니 그것이 진정 윈도우일까? 그러나 당시 컴퓨터 환경에서는 이런 바보같은 아키텍처가 필요했는지도 모른다.
애플은 MS의 직접적인 경쟁자가 아니었을 것이다. 도스 시장에서는 이미 MS-DOS 외에도 경쟁사 제품들이 출시되고 있었다. 디지털 리서치(Digital Research)의 GEM(Graphic Environment Manager)이 84년 9월에 출시되고, 85년 2월에는 IBM이 TOPView를 발표한다. 게다가 85년 7월에 윈도우 3.0이 나오기 전까지 어느 정도 상업적으로 성공을 한 Quarterdeck Office Systems가 DESQview를 발표한다. 빌 게이츠의 MS는 이 분야에서 선구자가 아니다. 어쩌면 제일 늦게 시작한 것인지도 모른다.

‘윈도우’라는 세계의 탄생 알려
마케팅적인 관점에서 본다면 가장 먼저 시작한 것이 성공을 보장하는 것은 아니다. 성공은 적절한 시기에 맞추어서 제품을 출시할 때만 가능하다. 적절한 시기에 제품을 출시하기 위해서는 그 이전에 많은 준비와 실패가 필요하다. 성공을 위한 기본 투자없이는 어느 누구도 적시에 제품을 출시할 수는 없다. 그것을 빌 게이츠는 알고 있었던 것이다.
교묘하게도 윈도우 1.0이 출시되던 해 인텔에서 27만 5000개의 트랜지스터가 내장된 386DX CPU를 출시했다. 멀티태스킹을 위해서는 AT에서 사용되던 80286으로는 한계에 부딪힐 수밖에 없다. 386 CPU의 보급은 윈도우의 행방에 새로운 가능성을 제시해 주고 있다. 윈도우는 아무도 상상을 못한 세계는 아니지만 누구나 도전할 수 있는 세계는 아니었다. 그리고 그 도전하는 행보의 질주 역시 누구나 할 수 있는 일은 아니다. 윈도우 3.1이 나오기까지 10년이라는 투자는 아무나 할 수 있는 일이 절대로 아니다.

윈도우 2.x의 희망
윈도우 1.0의 실패에도 불구하고 윈도우 2.0 버전을 1987년 12월 9일 발표한다. 이전과는 달리 겹칠 수 있는 윈도우 방식을 채택했다. 윈도우 AT PC 이하에서 작동하는 윈도우 2.x와 80386 CPU의 가상 8086 모드를 사용한 윈도우 386 제품이 출시됐다. 당시 판매 가격을 보면 윈도우 2.0 버전의 가격은 99달러(테크니컬 그룹, 마이크로소프트 윈도우 2.0과 시스템 개발 키트1, 컴퓨터매거진, 1998 6월호, pp.152)이고, 윈도우 386 버전은 195달러이다.
국내에 한글화된 최초의 윈도우는 윈도우 2.1 버전이다. 마소 1990년 6월호에 황윤호 씨가 쓴 기고를 보면 한글 윈도우 2.1이 최초로 국내 시장에 소개되었음을 확인할 수 있다. 당시의 윈도우 2.x 버전의 하드웨어 사양을 보면 다음과 같다. 마우스가 옵션이라는 점이 어색하게 느껴진다.

◆ 2개의 플로피 혹은 하나의 하드디스크
◆ MS-DOS 2.0 이상
◆ 512KB 이상의 메모리
◆ 흑백 혹은 컬러 모니터
◆ 마우스(옵션)

윈도우 2.0의 생존 가능성을 높여준 것은 무엇일까? 그것은 엑셀과 페이지메이커와 같은 중요 오피스 제품군과 디자인 제품군이 윈도우용으로 발표되었고, SDK 제공으로 응용 프로그램 보급이 다양한 개발자들의 참여의 길을 터줬기 때문이다.

SDK 제공으로 개발자 지원
애플의 Lisa가 기존의 애플 II의 성공에도 불구하고 실패한 것은 비싼 가격대에 비해서 신뢰성이 떨어졌기 때문이라고 하지만, 가장 큰 문제는 애플 II와 호환되지 않은 프로그램에 있었다. 매킨토시는 이 때의 실패를 거울삼아서 다양한 개발자 그룹과 연대를 하고 지원 프로그램을 발표하게 된다. MS는 윈도우 1.0의 실패에서 이 점을 잘 알고 있었고 그래서 SDK를 제공하게 된 것이다.
소프트웨어 디벨로퍼 킷(SDK)의 구성을 살펴보면 말 그대로 킷이다. 개발을 할 수 있는 기본적인 소스와 컴파일러로 구성되어 있는 것 외에는 없다. 그러나 성공에 있어서 중요한 것은 바로 환경과 포장이다. SDK가 있다는 것은 개발할 수 있는 인터페이스 환경, 즉 애플리케이션 프로그래밍 인터페이스(API)를 제공하고 있다는 것이다. 그런 환경을 제공할 수 있다는 것이 윈도우의 힘이 되고 있다. SDK가 있다는 것은, 뭔지 모르지만 윈도우 환경에서 개발할 수 있을 것이라는 자신감을 갖게 하기 때문이다.
85년도에 출시된 386DX CPU의 출시로 멀티태스킹을 위한 기본적인 환경은 되었으나 고가의 CPU 가격으로 보급이 저조했다. 이는 88년도에 6월에 출시된 저가형 386SX(http://www.howpc.com/ howpc/200001/tech/01.htm)의 보급으로 386급 PC가 폭발적으로 늘어난 점도 간과할 수 없다. 무늬만 386 CPU가 아니냐고 해도 AT PC보다 사용상에서는 훨씬 나은 성능을 보인 것은 사실이다.
또한 MS가 윈도우 386 버전을 만든 것은 마케팅적인 측면에서 고도의 기술을 사용한 윈도우가 모두에게 필요하지는 않다는 것을 제시하는 것 같다. 하지만 결국 고객은 항상 좋은 쪽으로 기울게 되어 있어서 이왕이면 좋은 제품을 선택하게 되므로 결국은 윈도우 386 버전을 선택하게 된다. 이런 마케팅 기법은 한글과컴퓨터에서 아래아한글 레이저 버전을 별도로 출시하면서 고가의 가격을 매겼음에도 불구하고 복사방지 락이 풀리기 전까지 불티나게 팔린 것과 일맥상통할 수 있다.

새로운 도약, 윈도우 3.x
윈도우 3.x 버전은 리얼 모드(real mode), 표준 모드(standard mode), 386 확장 모드(386 enhanced mode)로 실행이 된다. 실행될 때 PC가 640KB 이내의 메모리를 가진 XT나 AT 기종이면 리얼 모드로, 256KB의 확장 메모리를 가진 AT 기종이나 1MB의 확장 메모리를 가진 386 PC에서는 표준 모드로, 1MB 이상의 확장 메모리를 가진 386 PC에서는 386 확장 모드로 실행이 되었다. 이때 가격은 150달러였다고 한다(존유델, 90년대를 향한 MS 윈도우즈 3.0 출현(바이트지 독점 기사), 컴퓨터매거진, 1990년 7월호, pp.241).
이때 3차원의 음영 버튼을 제공해서 밋밋한 윈도우에서 벗어나게 되었다. 그리고 IBM의 MDI(다중 문서 인터페이스) 기술을 적용할 수 있어서 문서 관리 인터페이스가 유연해졌다. 현재 윈도우의 기본 골격은 모두 갖춘 셈이다. 그러나 유닉스와 같은 대다수의 운영체제가 사용했던 선점형(preemptive) 방식을 포기하고 비선점형(non-preemptive)을 사용한 것은 당시의 하드웨어 스펙 사양으로는 선점형 멀티태스킹이 무리라고 판단했기 때문이다. 결국 이것은 두고두고 골칫거리로 남게 되지만, ‘시장을 앞질러가는 기술은 성공할 수 없다’는 MS만이 내릴 수 있는 고객과 시장 중심의 결단이었다.
비선점형 방식은 결국 응용 프로그램이 컴퓨터에 대한 제어권을 가지므로 UAE라고 불리우는 일명 블루 스크린을 보여주게 된다(http://www.helloec.net/network/PreemptiveMultitasking.htm). 빌 게이츠 사장이 데모할 때도 블루 스크린이 발생해서 망신을 당한 방송 중계가 생생하다.

‘시장을 앞지른 기술은 성공할 수 없다’
윈도우 3.0의 실제적인 경쟁자는 DESQview와 Geoworks의 앙상블(Ensemble)이었다. 초기에는 윈도우의 후광에 가려 있다가 윈도우 3.0이 XT를 지원하지 않은 다음부터 각광받기 시작했다(김성대, 앙상블 1.2 리뷰 상, 컴퓨터 매거진, 1992년 2월호, pp.242). 그러나 이들은 시장에 정착하는 데 실패했다. 훨씬 더 빠른 수행 속도를 보였지만 응용 프로그램의 부족과 개발 환경의 미비로 시장에서 점점 사라지게 된다.
초창기에는 윈도우 3.x 버전의 시장 비중이 그리 크지 않았다. 어느 누구도 윈도우가 향후 모든 것을 차지하는 플랫폼이 될 것이라 생각하지 못했다. 오히려 네트워크 기반이 잘되어 있는 OS/2쪽으로 C/S 환경이 기우는 것처럼 보이기도 했다. 일부 C/S 프로젝트나 C/S 관련 책들은 OS/2의 기술과 오픈 아키텍처에 더 점수를 줬다. OS/2는 다중 쓰레드, 32비트 프로그래밍, HPFS(HighPerformance File System), 다양한 그래픽 프로그래밍 인터페이스 등을 제공하고 있었다.
도스 시장에서도 멀티태스킹이 되는 MOS 개념으로 도스 제품들이 나오기 시작했다. 단순한 GUI에 불과한 윈도우 3.0은 MOS보다 느리면서 멀티태스킹도 제대로 되지 않는 제품으로 치부되곤 했다. 그러나 시장은 점점 윈도우쪽으로 기울고 있었다.

시장은 점차 윈도우로 기울고
1992년 4월 6일 발표된 윈도우 3.1은 이전 윈도우 3.0과는 달리 가지는 OLE 기능이나 외곽선 글꼴(TrueType Font), DDE, 개선된 도스 세션, 멀티미디어 제공으로 실제적으로는 3.5 버전의 능력을 가지고 나타났고, 야금야금 팔린 윈도우 3.0은 무려 900만장이나 팔렸다(강민석, 윈도우즈 3.1의 그 달라진 모습, 월간 마이크로소프트웨어, 1992년 6월호, pp.365). 윈도우 3.1도 900만장을 생산해서 팔았다 하니 실로 엄청난 판매량이 아닐 수 없다. 이 때부터 컴퓨터를 구입하면 도스 말고도 윈도우 3.1이 제공되었다. 아무리 OS/2를 무료에 가까운 가격에 제공한들, 사용자들은 이미 컴퓨터에 설치되어 있는 윈도우 3.1을 사용할 수밖에 없었다.
그리고 MS는 이때 윈도우 95에서 넷스케이프에 뒤진 시장을 만회하기 위해서 인터넷 익스플로러를 기본으로 설치해서 파는 정책으로 경쟁자를 따돌렸다.
그동안 도스 프로그램에서는 모든 것을 개발자가 개발하거나 일부 사용 라이브러리를 구입해서 사용해야 했는데, 윈도우는 인터페이스의 모든 것을 제공하고 있으며 주변기기 제어도 단순해지고, 비주얼 베이직과 같은 비주얼 툴의 대거 출현으로 개발자들이 도스 환경에서 윈도우 환경으로 대거 이동해가기 시작했다(편집부, 윈도우 95 사전답사, 컴퓨터매거진, 1995년 12월호, pp.114).
윈도우 NT의 서버 시장 침공
윈도우 3.1과는 달리 32비트 운영체제는 제대로 만들어지고 있었다. OS/2처럼 오픈 아키텍처를 가진 NT는 서버용 운영체제로의 진입을 의미하고 MS가 서버쪽으로 입지를 굳힐 생각이었다. MS는 당시 파일 네트워킹 분야의 부동의 1위인 노벨을 의식해서인지, 윈도우 NT가 절대로 노벨의 네트웨어와 경쟁하는 제품이 아니라고 누누히 강조하던 모습을 기억한다. 윈도우 NT 서버는 파일 네트워크 시장이 아닌, 응용 프로그램 서버쪽으로 유닉스와 경쟁을 할 것이라고 말했다. 역시 상대를 안심시키려는 고도의 삼십육계의 전략 중 하나인 가치부전(假痴不癲)과 반객위주(反客爲主)가 아닐 수 없다.
이것은 SQL 서버 7.0 발표 때에도 똑같이 재현되었다. 1998년 미국 뉴올리언즈에서 열린 TechED 98에서 MS는 현재 시장 점유율 80%인 오라클과는 경쟁하지 않겠다고 했다. 단지 오라클이 포기하고 있는 20%의 시장에서 중소기업용 데이터베이스로서의 SQL 서버 점유율을 높이는 데 집중할 뿐이라고 했다. 이미 윈도우 NT 때 한번 속았던터라 그 말을 믿지 않았다. 아니나 다를까. 오라클이 점유하고 있는 엔터프라이즈 시장을 향해서 SQL 서버는 더 많은 기능을 제공하기 시작했다. 현재 SQL 서버는 OLAP 분야에서 1위를 차지하고 있으며 앞으로 더 많은 분야에서 경쟁사를 압도할 것이다.

노벨, 오라클을 압도한 SQL
1993년 5월 24일 발표된 윈도우 NT 3.1은 파일 시스템 시장을 점점 점유했다(http://jbshop.co.kr/study/win2000/1history.htm, 윈도우의 역사). 개발자들은 OS/2와 같은 32비트 운영체제를 원했고, 파일 네트워킹은 기업의 IT 환경에서는 필수적인 요소였다. 기업은 노벨 아니면 윈도우 NT를 선택해야 했다. 노벨은 파일 서버의 역할이 주이지만, 윈도우 NT는 응용 프로그램 서버도 겸할 수 있으므로 비용절감 차원에서도 노벨은 점점 입지가 약해졌다. 그러나 초창기에는 파일 서버 기능이 약한 NT 서버를 노벨의 파일 서버와 연결하는 일이 많았다.
윈도우 NT 3.5를 출시하면서 서버군은 다시 워크스테이션 버전과 서버 버전(http://webman.lin4u.com/win2000/win2000_intro. html)으로 나누어졌다. 계속해서 제품을 구분하는 것은 시장을 분할한다고 생각할 수도 있지만 오히려 시장을 키우는 전략이 된다. 즉 윈도우 NT 워크스테이션 버전을 사용하면서 필요에 의해서 윈도우 NT 서버 버전을 사용하게 된다. 이런 마케팅 기법은 윈도우 XP에 와서는 좀 심하다 싶을 정도로 과도한 제품군(http://www.winok. co.kr/xpnews/news_view.asp?gotoPage=1&idx=1062)을 만들어낸다. 운영체제 시장에서 경쟁자에게 빈틈을 주지 않겠다는 철저한 마케팅적 계산이 들어가 있다.
NT는 ‘New Technology’의 약자이다. 우리 나라에서도 신기술 마크로 NT를 사용하고 있는 것과 동일한 의미이다. 그러나 아직까지는 신기술의 의미를 윈도우 NT 3.1이나 3.51 버전에서는 찾기 어려웠다. 1996년도에 NT 4.0이 발표됨으로써 NT는 NT다워졌다. 응용 프로그램 서버로서 사용할 수 있는 다양한 기술을 제공하고 있으며 IIS가 번들됨으로써 본격적으로 비즈니스에서 활용되기 시작했다.
윈도우 2000 서버가 발매되기 전까지 한시적으로 시장을 유지하기 위해서 옵션팩을 제공했다. 옵션팩에는 메시지큐나 MTS 등의 서버 제품군이 더 보강돼 있었다. 이때를 기반으로 다양한 기술들이 비즈니스에서 제대로 활용되기 시작했다.

네트워크의 시작 윈도우 95, 98, ME
윈도우 95의 개발 코드네임은 ‘시카고’이다. 시카고라는 코드네임은 사람들에게 기대감을 줬다. 장기간에 걸친 개발 기간이었음에도 사람들은 윈도우 95를 기대, 아니 고대해왔다. 사람들은 윈도우 3.1의 블루 스크린을 그만큼 덜 보기를 원했다. 도스 위의 윈도우가 아닌 진짜 윈도우, 즉 32비트 운영체제가 필요했던 것이다. 개발자들은 이미 메모리의 제한을 받는 윈도우 3.1을 개발 한계를 주는 원흉처럼 생각하고 있었다.
윈도우 95는 부족하지만 나름대로 절충안을 제시하면서 윈도우 3.1의 문제점을 상당 부분 해결하였다. 윈도우 95는 32비트 응용 프로그램도 실행이 가능하며 16비트 응용 프로그램과 호환성을 유지한다. 또한 PnP(Plug and Play) 지원으로 컴퓨터의 하드웨어 추가나 변경에 따른 부담을 최소화하고, 도스없이 윈도우만으로도 설치가 가능하며, 완벽한 보호 모드 제공으로 메모리 활용도가 높았다. 무엇보다도 시작 버튼의 배치나 프로그램 단축키는 컴맹들이 프로그램을 쉽게 이용할 수 있게 해 준다. 또한 이전보다 예뻐진 인터페이스는 사람들의 마음을 사로잡았다.
처음에 시카고라는 코드네임으로 불릴 때는 4MB에서도 실행되는 운영체제를 설계했으나 네트워킹이 되기 위해서는 적어도 8MB의 램이 있어야 실행되도록 변해야 했다. 지금의 XP가 256MB는 되어야 원할하게 사용된다는 점을 되짚어 본다면 윈도우 95는 얼마나 더 많은 노력을 들였는지 알 수가 있다. 지금은 더 방만하게 개발하는 것이 아닌가 하는 의심(?)도 해 본다. 단지 메모리뿐만 아니라 설치 용량도 윈도우 95 베타 1인 경우에는 윈도우 3.1보다 작았다고 한다.

국제화 버전으로 확산 시작
무엇보다도 윈도우 95는 글로벌라이제이션을 위한 가능성을 연 제품이다. 물론 NT에서는 유니코드를 지원하므로 로컬라이제이션이나 글로벌라이제이션에 적합하지만, 다양한 국제화 버전으로 출시가 되고 확산된 것은 윈도우 95가 판매되면서이다. 또한 윈도우 95는 윈도우 3.x 버전에서 탈피해서 수익을 올려주는 실제적인 제품이 되었다. 본격적으로 MS의 세상이 온 것이다.
그러나 초기에는 윈도우 95의 네트워크 방향이 다소 잘못 설정되어 있었다. MS는 MSN을 기반으로 하는 온라인을 생각했다. 그러나 인터넷은 더 빠르게 확산되고 진화했다. 이에 대해 MS는 윈도우가 풍부한 자원을 제어할 수 있는 플랫폼이고 인터넷은 가볍지만 응용력이 약한 플랫폼이라고 선전을 했다. 그러나 시대의 흐름을 MS라고 막을 수 있을까. 결국 전략을 대폭 수정하지 않으면 안 되었다. 수정한 정도가 아니라 브라우저를 기본 플랫폼으로 넣었다.
이쯤에서 지금까지 소개한 윈도우의 버전별 마케팅 전략을 한번 요약해 보자.
◆ 1.x : 우리가 시작했다. 손대지 말라
◆ 2.x : 가능성이 보인다. 사용해 봐라
◆ 3.x : 시장에서 제대로 돈 받고 판다.

이 전략대로라면 윈도우 95는 네트워크용 운영체제로는 1.0 버전에 불과하다. MS는 윈도우 97 버전을 하나 만들고, 윈도우 98로 윈도우 95 아키텍처에 종지부를 찍고 싶어했다. 그러나 결론적으로는 윈도우 98을 거쳐서 결국 윈도우 ME가 발표됨으로써 그 과정을 수정할 수밖에 없었다.
윈도우 98의 후속 제품인 밀레니엄 에디션(Millennium Edition)은 윈도우 98 TE(Third Edition)이란 이름으로 출시될 가능성이 높다고 발표하기도 했지만, 브랜드는 윈도우 ME로 출시가 되었다. 윈도우 ME는 멀티미디어 운영체제를 표방하고 나왔다. 실제 윈도우 ME 발표회때 보여준 것은 디지털 카메라나 멀티미디어 기기와의 연계를 집중적으로 보여주었다.

침체된 시장을 일으켜라, 윈도우 2000
윈도우 NT 4.0의 다음 버전은 윈도우 NT 5.0이지만 코드네임이 카이로와 휘슬러로 불리우다가 윈도우 2000 서버로 발표됐다. 카이로는 초기에는 윈도우 NT 4.0의 코드네임이었다. 휘슬러는 윈도우 XP에서 계속해서 코드네임으로 사용하였다. 휘슬러가 윈도우의 통합을 위해서 개발되던 코드이므로 윈도우 2000 서버 발표로 통합은 물건너간 것처럼 보인다. 향후 MS는 통합을 하지 못할 것이다. 마케팅의 대가인 알 리스의 말처럼 모든 상품은 어느 것도 통합되지 않고 세분된다는 말처럼 통합은 상상 속의 생각이다.
그러나 구조적으로 윈도우 2000은 윈도우 98과 윈도우 NT의 인터페이스 일원화를 시도했으며, NT 커널을 사용한 진정한 32비트 아키텍처를 갖추었고 NTFS와 FAT32를 지원한다. ADS(Active Directory Service)를 선보였고 IPP(Internet Printing Protocol)로 웹 서버에 연결된 프린터로 인쇄가 가능하며 MMC(Microsoft Management Console)라고 부르는 제어판 스냅인을 지원한다.
‘윈도우가 하드웨어 시장을 키웠다’라고 말해도 과언이 아니다. ‘윈텔 진영’이라고 함은 윈도우, 인텔을 말하는 것이 아니던가? 이 두 회사는 서로가 서로를 돕고 있었다. 윈도우 2000은 새로 발표된 인텔의 CPU 라인업의 계보를 잘 반영하고 있었다. 특히 Prestonia라는 HTT(하이퍼 쓰레딩 테크닉)을 가진 제논(Xeon) 서버도 잘 인식하고 실제는 CPU가 2개 밖에 없어도 4개까지는 윈도우 2000 서버에서 인식되므로 자연히 새로운 제논 서버에 대한 수요는 증가하게 된다.
윈도우 2000 발표회 때 필자는 샌프란시스코에서 열리는 VBITs 컨퍼런스에 참가하고 있다가 컨퍼런스에서 나누어주는 브로셔에서 윈도우 2000 발표회가 근처에 있다는 것을 알고 참가를 했다. 거금 50달러의 입장권이 살인적이라고 느끼면서도 역사인 순간에 동참한다는 마음으로 참관했다. 당시 빌 게이츠 회장이 윈도우 2000 서버에 대해서 설명을 하고 있었는데 그는 엄청난 사실을 고백했다. <표 2>는 당시 보았던 프리젠테이션을 떠올려 본 것이다. 저것이 무엇일까 궁금했는데 바로 윈도우 98은 하루에 한 번씩 켜야 하고 윈도우 NT는 7일마다 리부팅이 필요하지만 윈도우 2000 서버는 28일은 문제가 없다고 자랑하는 것이었다.
많은 발전이다. 7일마다 리부팅이 필요한 운영체제에서 무려 4배나 연장된 28일이라니…. 그러나 네트웨어의 경쟁업체인 노벨은 10년 동안 서버를 끄지 않았다는 기록을 자랑스럽게 여긴다는 것과 비교할 때 미약하게 느껴진다. 그럼에도 참석자들은 빌 게이츠 사장의 발표에 열광을 했다.
윈도우 2000 서버는 NT 서버가 가진 많은 단점을 일거에 해소했으며, 그동안 번들 또는 킷 형태로 제공되던 서비스를 제대로 통합하며 32비트 운영체제다운 면모를 보이기 시작했다. 그러나 NT 서버에서 윈도우 2000 서버로의 업그레이드율은 현저하게 낮았다. 고객들은 NT 4.0만으로도 응용 프로그램 서버로 사용하기에 부족함을 느끼지 못했다.
윈도우 2000 서버는 <표 3>과 같이 기존의 윈도우 NT 워크스테이션 대신 프로페셔널 버전을 윈도우 NT 서버 대신 윈도우 2000 서버 버전으로 명명해서 새롭게 내놓았다. 서버 버전은 다시 윈도우 2000 서버, 윈도우 2000 어드밴스 서버, 윈도우 2000 데이터 서버로 나누어진다.
이렇게 많은 버전을 대거 출시하면서 윈도우 2000 어드밴스 서버 이상은 이제 MS가 하이엔드 시장에도 진출할 수 있음을 보여주었다. 기존에는 하이엔드 시장은 메인프레임이나 대형 유닉스 제품들이 선점하고 있던 시장이다. 인텔 기반의 하드웨어로 하이엔드 시장 자체를 공략하기란 쉽지 않음에도 불구하고 인텔의 성장세에 힘입고 로드밸런싱이나 클러스터링을 무기로 이 시장을 공략하기 위한 초석을 마련했다. 실제로 윈도우 2000 서버 발표회 때도 빌 게이츠 사장은 윈도우 2000 어드밴스 서버로 구성된 로드밸런싱과 클러스터링의 데모를 직접 시연했다.

미인계 운영체제 윈도우 XP
처음에 XP가 버전 10 대신 X를 사용한 것이 아닌가 했는데 윈도우 XP는 ‘eXPerience’의 약자라고 한다. 무엇 때문에 XP라고 했을까? 브랜드를 독자적으로 운영해보기 위한 것인가? 그러나 결국 다음 버전은 윈도우 서버 2003으로 하지 않았던가! ME에 이은 상술인가? 그 결과 무엇을 얻었는가?
XP를 굳이 한마디로 평하자면 미인계 운영체제라고 표현하고 싶다. 미인과 결혼하려면 많은 것을 준비해야 한다는 옛어른들의 말씀처럼 윈도우 XP는 고사양의 PC 시스템을 필요로 한다. 사용해 본 결과 최소 펜티엄 4 1GHz 이상의 CPU와 메모리 256MB는 되어야지만 겨우 사용할 정도이다. 물론 XP에도 고부하의 인터페이스를 평범(face down)하게 바꿀 수 있는 옵션이 있어서 저용량(?)에서도 잘 수행될 수 있지만 원숭이 짚신이라고 하지 않던가? 좋은 것을 사용하다보면 바꾸기란 쉬운 것이 아니다.
물론 데스크톱용 운영체제 계열에서는 기능적으로나 구조적으로 윈도우 95 계열에서 벗어난 제품이다. 그러나 많은 사람들이 기대했던 닷넷 프레임의 제품군은 아니었다. 윈도우 XP는 지금까지 6개의 다른 에디션을 가지고 있다. 윈도우 XP 홈, 윈도우 XP 프로페셔널 외에도 윈도우 XP 임베디드, 윈도우 XP 미디어센터, 윈도우 XP 태블릿PC, 윈도우 XP 64비트이다. 각각 용도별로 만들어서 틈새 시장도 허락하지 않겠다는 의미이지만, 뒤집어보면 하나의 제품으로 모든 것을 제공하지 못한다는 현실을 반영한 것이기도 하다.
윈도우 XP가 코드명 휘슬러의 진정한 첫번째 제품으로 인식한다면 NT 기반의 32비트 커널을 탑재해서 기존의 불안정한 16비트 코드로부터 벗어나면서 데스트톱의 기능을 충족시켰다는 데 큰 의미가 있다. 그러나 우리가 상상했던 통합판이 아니라 기술의 머지(Merge)를 통한 기반 기술의 통일이라고 하는 것이 더 맞는 표현이다.

새로운 유토피아 윈도우 서버 2003
휘슬러라는 코드명의 이 제품은 윈도우 ME에 윈도우 NT 기술을 사용한 제품으로 기획이 되었다. 휘슬러는 윈도우 2000 서버의 코드네임이었지만, 윈도우 2000 서버는 통합이 되었다기 보다는 서버로서의 의미를 더 가진다. 뒤이어서 윈도우 XP도 휘슬러라는 코드네임을 사용했다. 역시 서버와 데스크톱의 통합이라기보다는 데스크톱의 기능이 더 화려했다. 휘슬러가 지향하던 통합이라는 용어의 의미는 윈도우 서버 2003에서 가시화된다.
윈도우 서버 2003 버전은 MS의 타겟 에디션 전략이 절정에 이르고 있음을 보여준다. 윈도우 서버 2003 표준판, 윈도우 서버 2003 엔터프라이즈, 윈도우 서버 2003 데이터센터, 윈도우 서버 2003 웹, 윈도우 서버 2003 엔터프라이즈 64비트, 윈도우 서버 2003 데이터센터 64비트에 2003년 3분기쯤 출시되리라 예상되는 윈도우 스몰비즈니스 서버 2003까지 하면 총 7종의 제품이 출시된다. XP가 데스크톱 영역에서 6종의 제품을 출시한 것을 합치면 총 13종의 운영체제가 존재하게 되는 것이다.
닷넷 서버로 전진
윈도우 서버 2003의 개념만큼은 새로운 유토피아를 꿈꾸는 MS의 역작이라고 할 수 있다. 많은 의미를 부여하지 않더라도 첫번째 닷넷 프레임워크 플랫폼베드이다. 그런데 문제는 사용자는 골치아픈 일에서 벗어나고 싶어하는데 새로운 유토피아는 더 복잡한 기술들을 많이 내포하고 있다. 모든 것이 통합되고 발전된다는 것은 점점 개념적으로 단순화되는 것인데 소프트웨어는 시간이 지날수록 점점 더 복잡한 개념으로 얽히고 설켜서 사용하기가 어려워진다. 닷넷 서버라고 하면 거부감이 심할 것 같아서 윈도우 서버 2003이라고 바꾼 것도 사용자들이 새로운 것에 적응하기를 거부하기 때문이 아닐까? 지금까지는 필요에 의해서 새로운 것을 받아들였지만 이제는 그런 시기가 아니다. 전반적인 IT 업계가 성숙기에 접어들었기 때문이다.
새로운 유토피아가 될 윈도우 서버 2003(이전에 닷넷 서버)은 새로운 도전이지만 이 도전이 애플의 스티븐 잡스가 실패한 넥스트스텝의 전철을 밟지 않으리라는 보장을 해 주지는 않는다. 이제 서버들은 중소기업에서 사용할 수 있을만큼 충분히 가격이 내려가 있고 성능도 일정 수준 이상이 된다. 이전과 같은 한계 처리 속도에 버거워서 끙끙거리던 시절이 아니므로 윈도우 서버 2003이 윈텔 진영의 부흥을 다시 가져올지는 사뭇 기대가 된다.

윈도우의 역사에서 우리가 얻을 교훈은?
역사에서 우리는 교훈을 배운다. 그 교훈을 잊지 않는 것은 지식이 아니라 마음이다. 업계의 선두에 있고 그 누구도 달성하지 못한 98% 이상의 업계 석권이라는 업적을 가진 MS는 좀 다른 입장에 있지만, 진리는 항상 반복되는 역사를 보여주었음을 간과해서는 안될 것이다. 지금까지 장황하게 설명한 윈도우의 족보를 한 눈에 볼 수 있도록 정리를 해 보았다. 족보를 만들기 위한 자료 찾기가 쉽지 않았다. 이 족보가 아직도 진행형이라는 점과 앞으로 더많은 제품군이 2년 내에 쏟아질 것을 생각하니 벌써부터 머리가 지끈거린다.

정리 | 이종림 | nowhere@korea.cnet.com

참+고+자+료

윈도우와 ‘쥐‘는 천생연분?
컴퓨터를 사용하는데 마우스가 없다는 것은 상상조차 하기 어려운 일이다. 마우스 없이 넓은 화면을 어떻게 옮겨다닐지 상상만 해도 아득하다. 마우스는 1968년 12월 5일 스탠포드 연구소(SRI) 출신의 더그 엘겔바트(Doug Engelbart, 당시 77세)가 나무로 만든 것이 가장 시초이다(http://www.happycampus.com/ pages/2002/10/21/D1135798.html). 초기 제품은 ‘XY 지표’라고 불리우고 양손으로 사용했다. 실제로 오른손에는 마우스를 왼손에는 5칸짜리 코드 입력기를 이용해서 정보를 입력했다(http://serv.python.or.kr/pykug/_be_e7_bc_ d5_c7_d7_c7_d8). 이후 마우스는 1984년 애플이 매킨토시 컴퓨터의 표준 입력장치로 사용하면서 본격적으로 사용됐다.
마우스라는 애칭은 베트남 전쟁으로 상처를 입은 젊은이들을 달래기 위해서 붙인 애칭이었다는 설과 그 모양이나 크기 색깔이 쥐를 닮아서 마우스라고 불리우게 되었다는 설이 있다. 어째든 쥐를 가지고 논다고 징그럽다고 생각한 사람이 없었다는 것이 신기하다.

2.x 시절의 윈도우의 경쟁자들
마소 1990년 6월호를 들춰보면 윈도우 2.x 버전의 GUI로서의 경쟁자는 OS/2의 프리젠테이션 매니저(Presentation Manager), HP의 뉴 웨이브(New Wave), 왕(Wang)의 클리어 뷰(Clear View), 디지털 리서치의 젬(GEM), 유닉스의 X-윈도우, 넥스트의 넥스트스텝(NeXTStep)이 있다고 볼 수 있다. 그러나 지금은 다들 어디로 간 것일까? 현재 그 맥을 그나마 유지하는 것은 유닉스의 X-윈도우 정도이다. 윈도우보다 먼저 출시가 되어서 시장에 진출했지만 어째서 지금은 사라진 것일까? 답은 간단하다. 대부분은 호환성 부족과 고객이 인지를 하지 못했다는 점 때문이다.

윈도우가 왜 필요한가?
이쯤에서 원초적인 질문을 하나 해 보자. 윈도우는 왜 필요한가? 왜 윈도우가 PC 시장을 장악하고, 나아가서는 서버 시장까지 장악할 것으로 예측되는가? 텍스트 기반은 더 빠른 입출력을 가지지만 왜 고객이 외면하게 되는가?
윈도우는 그래픽 유저 인터페이스(GUI)를 기반으로 하며 WIMP(Windows, Icons, Mice, Pointers) 개념을 포함하고 있다. 모든 윈도우 시스템은 5가지 특징을 가지고 있고, 이것이 표준 인터페이스가 됨으로써 사용자는 개별적인 응용 프로그램의 인터페이스 사용법을 배우지 않아도 된다. 그래서 윈도우는 소프트웨어 환경에서 생산성을 높이는 기반 기술인 것이다. 다음과 같은 개념이 함께 포함된다.

◆ 포인트 & 클릭 : 키보드가 아닌 마우스로 원하는 것을 지정해서 클릭만으로 실행할 수 있다는 것은 프로그램 조작법을 매우 단순하게 한다.
◆ 아이콘 : 룩액필(Look and Feel)이라고 해서 글자보다는 아이콘을 통해서 의미를 알 수 있게 된다. 가위 모양의 아이콘은 잘라내기라는 것을 알듯이 말이다. 다만 아이콘에 사용되는 그림이 지역이나 프로그램마다 달라질 수 있으므로 표준 아이콘을 정의해서 이것을 따라야 한다.
◆ 멀티태스킹 : 여러 프로그램을 동시에 실행하는 기술이다. 작업을 동시에 진행할 수 있으므로 응답성이나 생산성이 높아지는데 이는 모든 응용 프로그램이 CPU를 100% 점유하는 것이 아니기 때문이다. 멀티태스킹은 그 방식에 따라서 선점형과 비선점형으로 나뉜다.
◆ 자료 교환 : 윈도우는 클립보드를 통한 자료 교환부터 DDE, OLE 등의 다양한 것을 통한 자료 교환까지 가능하다. 자료 교환이야말로 응용 프로그램 간에 정보 교환이 될 수 있는 실제적인 기능이다.
◆ 장치 독립적 : 가상 디바이스(VxD : Virtual Device)의 제공으로 프로그램을 개발할 때나 사용할 때 상호호환성이 강화된다. 어떤 프린터를 제어하든지 GDI만 제어하면 되기 때문에 것은 프로그램 개발에서 많은 부분 단순화될 수 있다.


윈도우 NT의 개발비용과 기간은?
톰 R. 하프힐의 기고에 의하면 윈도우 NT는 5년간에 걸쳐서 약 6백만 라인의 코드로 되어 있고 1억 5천만달러가 소요됐다(톰 R. 하프힐, 마이크로소프트사의 운영체제 전략, 컴퓨터매거진 1995년 9월호 pp.132). 개발비용이 지금 돈으로 약 2000억원이 소요된 것이고, 95년도 규모의 경제로 볼 때는 더 큰 비용이 소요된 것이다.

윈도우 코드네임의 정리
MS의 주요 제품군들에 대한 코드네임을 정리해 보았다(톰 R. 하프힐, MS의 운영체제 전략, 컴퓨터매거진 1995년 9월호 pp.133 참조). 각종 문헌을 참고해 보았으나, 발표 시기의 연기로 처음 구상했던 대로 제품이 출시되지 않아서 후에 라인업이 바뀌게 되는 경우를 종종 발견하게 된다. 문헌마다 코드네임이 지칭하는 제품이 달라서 관계를 분석하는 데 시간을 많이 들였지만 정확한 정보 얻기기 쉽지 않았다. 카이로와 휘슬러가 우리를 가장 헷갈리게 하는 코드네임이었다. 이런 현상은 개발이 늦어지거나 기존의 개발되는 코드네임을 통합하면서 발생했다.

◆ 시카고(Chicago) : 윈도우 95 코드네임
◆ 내쉬빌(Nashville) : 1996년에 발표될 소규모 업그레이드판
◆ 멤피스(Memphis) : 엘비스 프레슬리가 심장마비로 사망한 테너시주의 도시. 1998년경에 발표된 데스크톱에서 마지막 주요 릴리즈로 예상했던 윈도우 98의 코드네임
◆ 데이토나(Daytona) : 자동차 경주로 유명한 올랜도 주의 도시. 윈도우 NT 3.5 버전으로 예상했으나 NT 4.0의 코드네임이 됨
◆ 카이로(Cairo) : 이집트의 수도명. 1997년∼1998년에 발표될 윈도우 NT 4.0으로 예측했으나 윈도우 2000 서버의 코드네임이 됨
◆ 루나(Luna) : 데스크톱 OS의 새 버전인 윈도우 XP의 인터페이스 코드네임
◆ 휘슬러(Whistler) : 기존의 윈도우 2000 서버와 윈도우 XP, 그리고 이번에 출시된 윈도우 서버 2003의 코드네임
◆ 넵튠(Neptune) : 취소된 윈도우 2000의 일반 사용자 버전
◆ 롱혼(Longhorn) : 2004년 말에나 출시할 차세대 데스크톱 운영체제의 코드네임
◆ 유콘(Yukon) : SQL 서버 2000 버전의 차세대 제품의 코드네임
◆ 블랙콤(Blackcomb) : 2006년 말에나 선보일 윈도우 서버의 차세대 버전의 코드네임
◆ 하이드라(Hydra) : 윈도우 기반 터미널 서버의 코드네임
◆ 타이타니움(Titanium) : 익스체인지 2000 차기 버전의 코드네임
신고

윈도우즈 파일 시스템의 진화

쓰는 일/프로그램 2007.10.08 16:22 Posted by soulfree >동네청년<
출처 : http://cafe.naver.com/piepie00/179

윈도 2000의 설치과정에서 반드시 거쳐야 하는 부분이 바로 파일 시스템을 결정하고 파티션을 결정하는 과정입니다. 이 과정은 운영체제의 설치에서 밑바탕이 되므로 어떠한 시스템을 선택하느냐에 따라 전체의 성능에도 영향을 미칠 수 있는 중요한 요인이 됩니다. 따라서 윈도 2000의 첫 강좌로 파일 시스템에 대해 다루어보도록 하겠습니다. File System 도스, 윈도95나 윈도 98에서는 파일을 관리하기 위해 'FAT(File Allocation Table)'라는 방법을 사용하고 FAT은 다시 어떤 Entry를 사용하느냐에 따라 크게 FAT16, FAT32로 나뉘게 되고 FAT16의 확장된 개념인 VFAT가 있습니다. 또한 Windows NT의 경우 File system으로 NTFS 4.0을 Windows 2000의 경우 NTFS 5.0을 OS/2의 경우 HPFS를, Linux는 Ext2를 사용합니다. 이렇듯 운영체제에 따라 각각의 지원하는 File System을 가지고 있음에 주목해야 합니다. 지금부터 우리는 여러 가지 파일 시스템 중에서 윈도시리즈에서 사용하는 FAT와 NTFS에 대해 각각의 특징을 살펴보도록 하겠습니다.

FAT

FAT은 오랫동안 사용되었던 파일 시스템이기 때문에 윈도 NT, Win95/98, Macintosh, Linux, Unix 일부 버전 등 대부분의 운영체제가 FAT를 지원하고 있습니다. FAT 파일 시스템은 파일 이름을 8.3 이름 규칙에 따라 제한합니다. 다시 말해 확장자 전의 파일 이름은 8자 이상이 될 수 없으며 확장자는 3자로 제한합니다. FAT 파일 시스템의 파일 이름은 글자나 숫자로 시작해야 하며 공백 문자는 포함할 수 없고 대소문자를 구별하지 않습니다. FAT는 디스크를 일정한 크기의 영역으로 분할할 때, 그 하나하나의 영역의 사용상태(즉, 파일의 크기)와 영역의 논리적인 연결을 기록하기 위한 것입니다. 디스크를 일정한 크기로 분할할 때, 각 영역을 '클러스터'라고 부릅니다. 윈도(95/98)에서 사용되는 하드디스크의 섹터 크기는 대부분의 경우 512B가 사용되기 때문에 클러스터 크기의 현실적은 상한은 32KB로 제한되고 있습니다. 결국 클러스터 크기는 512, 1024, 2048, …., 32768B중의 어느 것을 취하게 됩니다.
FAT의 역사
FAT에 의한 관리방식은 1977년에 등장한 마이크로소프트의 DISK BASIC 시대부터 사용되어오고 있습니다. 그 당시 랜덤 액세스 미디어로는 160KB의 5인치 플로피디스크밖에 없었습니다. 'MS-DOS 1.25'가 등장했을 때는 디스크 베이직과의 파일호환성을 유지하기 위해 파일시스템으로 FAT가 사용되었습니다. 이 MS-DOS에서는 FAT엔트리가 12비트로 확장되어, 최대 128KB까지의 파일시스템을 구축할 수 있게 되었습니다. 'MS-DOS 2.11'이 등장할 때까지 10MB정도의 하드디스크밖에 없고, 또 매우 고가의 디스크였기 때문에 FAT12로도 충분히 여유가 있었습니다. 그러나 'MS-DOS 3.1'이 등장할 때에는 100MB 정도의 하드디스크가 등장하게 되었고, FAT12에 추가된 형태로 FAT16 지원이 추가되었습니다. 그 후 'MS-DOS 4.x'에서는 엔트리를 16비트로 확대하고 최대 2GB까지의 하드디스크를 지원했습니다. 이것이 그대로 윈도 95로 이어진 것입니다.

16비트 FAT의 한계

윈도 95의 등장 이래, 응용프로그램이 사용하는 파일수의 증가와 데이터의 거대화가 급속히 진행되고, 하드디스크의 용량도 점점 증가했습니다. 결국 새로 2GB 이하의 하드디스크를 찾는 것 자체가 어려워지게 됩니다. FAT16을 이용해 대용량 하드디스크를 이용하려면 2GB마다 파티션을 분할해, 최대 4개까지 동시에 액세스할 수 있는 파티션을 만들 수 있습니다. 결국 최대 8GB가 사실상의 한계 용량이 됩니다. 이처럼 하드디스크의 용량이 OS의 관리 가능 범위를 초월하는 비정상적인 상태를 맞게 되자, 사태는 긴급한 해결을 요구하게 됩니다.

FAT16에서 FAT32로

FAT를 32비트화 하려면 단순히 FAT 엔트리를 32비트화하는 것만으로는 안됩니다. FAT 파일 시스템에 관한 데이터 구조의 변경, API의 추가와 확장 및 유틸리티 등의 FAT32 지원이 필요합니다. 또 FAT의 크기가 커지는 데 따라 발생하는 문제도 처리해야 합니다. 오래된 디스크 유틸리티를 사용할 경우, FAT32에서 포맷된 하드디스크를 이용할 수 없게 되므로 주의해야 합니다. FAT16의 디스크 크기는 512KB에서 8KB, 2GB의 디스크에서 32KB가 되고 있습니다. FAT16에서 2GB의 하드를 이용하는 경우, 1KB의 파일을 만들 때 32KB의 용량을 사용하게 됩니다. 한편, FAT32에서는 8GB의 드라이브에서도 4KB 클러스터가 이용되고, 마찬가지로 1B의 파일을 만들 때 4KB 클러스터가 이용됩니다. 이러한 이유로 FAT32를 사용하게 되면 FAT16을 사용할 때보다 일반적인 디스크 용량의 이용효율이 10~20퍼센트 정보 향상된다고 알려지고 있습니다. FAT16의 확장, VFAT VFAT 파일 시스템은 FAT 파일 시스템이 확장된 것으로 Windows 95와 함께 도입되어 많이 알려진 파일 시스템입니다. 이 파일 시스템은 FAT와 호환되며 FAT보다 제한이 적어 파일 이름도 최고 255자까지 만들 수 있고 공백이나 여러 개의 구두점도 포함할 수 있습니다. 대소문자는 지정한 대로 보존되기는 하나 구별하지는 않습니다. VFAT로 긴 파일 이름을 만들 때 파일 시스템은 사실 두 가지 파일 이름을 만듭니다. 하나는 실제 파일 이름이고, Windows 95, Windows 98, Windows NT 4.0 이상 버전에서 나타납니다. 다른 파일 이름은 MS-DOS용 파일 이름으로 긴 파일 이름의 단축형입니다. MS-DOS용 파일 이름은 실제 긴 파일 이름의 공백 문자를 제외한 처음 6글자와 틸드(~) 그리고 숫자로 이루어져 있습니다. 예를 들면 Onlinewithyounet.txt의 MS-DOS용 파일 이름은 ONLINE~1.txt입니다. 이러한 파일 이름을 만드는 방식은 뜻하지 않은 결과를 가져올 수 있습니다. VFAT로 긴 파일 이름을 만들 때 MS-DOS용 이름으로 디렉터리 항목을 하나 사용하고 파일 이름 13자마다 항목을 하나씩 사용합니다. 이론상으로 보면 긴 파일 이름 하나가 최고 21개의 디렉터리 항목을 차지할 수 있습니다. 루트 디렉터리는 512개의 파일을 포함할 수 있지만, 루트 디렉터리에 255자의 가장 긴 파일 이름을 만들면 포함할 수 있는 파일 수가 24개로 줄어듭니다. 따라서 루트 디렉터리에는 가능하면 긴 파일 이름을 사용하지 않는 것이 좋습니다. 다른 디렉터리는 이러한 제한 사항의 영향을 받지 않습니다. 이 글에서 VFAT를 언급하는 것에 대해 의아할 수도 있지만 현재 FAT보다 VFAT가 더 일반적으로 사용되고 있습니다. 그러나 위에 언급한 차이점 외에 VFAT 사용에도 제한 사항이 있습니다. Windows NT에서 분할 영역을 FAT로 포맷하면 VFAT로 포맷됩니다. Windows NT 4.0에서 FAT 분할 영역을 사용하려면 MS-DOS 같은 다른 운영 체제로 분할 영역을 포맷해야 합니다.

FAT32

FAT32 FAT32는 FAT와 VFAT가 확장된 파일 시스템으로, Windows 95 OEM Service Release 2(OSR2)에서 처음 도입되었습니다. FAT32에서는 '대용량 디스크의 지원', '신뢰성 향상', '성능 향상' 등을 꾀하고 있습니다.

▶빈공간 재계산 억제
지금까지의 FAT 시스템에서는 디스크의 빈 공간을 계산하려면 FAT를 모두 읽어 미사용 부분의 계산을 처리했습니다. 그러나 FAT32에서 2GB의 드라이브를 취급하는 경우, 이 데이터를 읽어내게 되면, 약 2MB 정도의 분량을 읽게 됩니다. 이 문제를 해결하기 위해 빈 공간을 보존하기 위한 'FSINFO'라고 불리는 영역이 새로 추가되었습니다. 파일을 읽고 쓸 때마다 이 수치를 갱신해 빈 공간의 용량을 계산할 때에도 고속으로 처리할 수 있게 되었습니다. 그러나 FSINFO와 실제의 빈 공간의 용량의 차이가 없도록 해야 합니다. 특히 윈도 95나 98의 셧다운이 제대로 이루어지지 않으면 FAT와 FSINFO에 장애가 발생합니다. 이를 해결하기 위해 윈도의 비정상 종료시 다음 시작에 스캔디스크가 실행되는 것입니다.

▶파일 저장의 고속화
FSINFO에는 파일의 최종저장 섹터번호까지 저장되도록 되어 있어, 추가로 저장할 경우에도 FAT의 처음부터 최종 저장번호까지 읽지 않고 그대로 추가 저장할 수 있습니다. 이것으로 디스크 액세스의 최소화를 실현하고, 디스크 캐시 메모리를 유효하게 이용할 수 있게 됩니다.

▶신뢰성과 효율성 향상
FAT32에서는 FAT16에 비해 신뢰성 향상도 꾀하고 있습니다. FAT16 시스템에서는 FAT영역을 2개 만들어두고, 보통의 경우에는 제1 FAT를 참조합니다. 만약 제1 FAT가 손상되어 읽을 수 없게 될 때는 몇 번 정도 재시도를 반복하고 그대로 안되면 예비로 있는 제2 FAT에 액세스합니다. FAT32에서는 FAT 영역이 늘어나기 때문에 FAT에 불량이 발생할 확률이 FAT16에 비해 크게 높아졌습니다. 이 문제에 대해서는 장애가 발생한 FAT 부분만을 예비 FAT에서 적극적으로 이용하는 것으로 FAT에 불량이 발생한 경우에도 처리를 계속할 수 있게 되었습니다. 같은 2GB의 하드디스크를 사용하는 경우, FAT16의 경우는 하나의 클러스터가 32KB, FAT32의 경우 하나의 클러스터가 4KB가 됩니다. 만약 1KB의 파일이 있을 때 1클러스터가 소비되므로 28KB의 사용 용량의 차이가 발생합니다. 만약 1KB의 파일이 100개 있을 때, FAT16은 3.2M를 FAT32는 400KB의 용량을 소비하게 되므로 FAT32는 FAT16보다 하드디스크의 사용 효율이 8배나 높아지게 됩니다.

NTFS 4.0

FAT, VFAT, FAT32 파일 시스템을 살펴보았으니 NTFS 파일 시스템에 대해 알아보겠습니다. NTFS는 New Technology File System의 약자로 마이크로소프트에서 결함 허용(fault tolerance) 증가와 보안 향상 등 FAT의 기능을 추가 보완하고 OS/2의 HPFS에서 속도와 유연성을 받아들여 개발(예를 들어 HPFS의 성능향상 기법중의 하나인 B-Tree를 지원)한 것이며 Windows NT에서부터 알려졌고 Windows 2000에서 NTFS 5.0으로 새로운 기능추가와 함께 거듭나게 되었습니다.

▶호환성
어떤 파일 시스템을 사용할지 결정하기 전에 호환성을 알아 보아야 합니다. 여러 운영 체제가 분할 영역을 액세스하는 경우 모든 종류의 운영 체제에서 읽을 수 있는 파일 시스템을 사용해야 합니다. 이는 모든 운영 체제와 호환되는 FAT 파일 시스템을 사용해야 한다는 것을 의미합니다. NTFS의 경우 Windows NT와 Windows 2000에서만 사용할 수 있습니다. 그러나 이러한 제한 사항은 로컬 컴퓨터에만 적용됩니다. 예를 들어, Windows NT와 Windows 98이 같은 컴퓨터에서 실행 중이고 같은 분할 영역을 액세스한다면 FAT로 포맷해야 합니다. 그러나 Windows NT의 단일 운영 체제인 컴퓨터라면 NTFS로 포맷해도 네트워크에서 다른 운영 체제를 실행 중인 컴퓨터가 분할 영역을 액세스할 수 있습니다.

▶볼륨 크기
파일 시스템 선택에 있어서 중요한 것은 분할 영역의 물리적인 크기입니다. FAT는 최고 2GB의 분할 영역 크기를 지원합니다. 분할 영역 크기가 2GB보다 크면 FAT32나 NTFS로 포맷하거나 분할 영역을 작게 나누어야 합니다. 그러나 이 때 NTFS로 포맷할 경우 향상된 기능으로 인해 FAT보다 오버헤드가 디스크 공간을 많이 차지하게 됩니다. NTFS는 사용되는 모든 볼륨에 대하여 대략 5MB를 소모합니다. 분할 영역이 200MB보다 작을 경우 NTFS와 연결된 오버헤드 때문에 디스크 공간이 손실되지 않도록 FAT로 포맷해야 합니다. NTFS 분할 영역의 최대 크기는 16 exabytes입니다.

▶결함 허용
일단 분할 영역의 크기와 호환성 문제가 해결되었으면 파일 시스템 선택이 자유로워집니다. 이제 고려해야 할 사항은 결함 허용인데 Windows NT는 속도와 결함 허용을 증가시키는 몇 가지 다른 디스크 액세스 방법을 소프트웨어를 통해 지원합니다. 이러한 옵션에는 디스크 스트라이핑과 패리티가 있는 디스크 스트라이핑이 있는데, 대부분 이러한 옵션들은 NTFS 파일 시스템에서 사용할 수 있습니다. 그러나 하드웨어 기반의 스트라이프 세트의 경우는 다른 파일 시스템에서도 사용할 수 있습니다. 고급 결함 허용 옵션이 없어도 NTFS는 FAT나 FAT32보다 훨씬 뛰어난 결함 허용 기능이 내장되어 있습니다. 예를 들면 NTFS에서 하드 디스크의 내용을 변경할 때 로그 파일에 변경 사항에 대한 기록을 만들기 때문에 전원 공급이 중단되거나 디스크 오류의 경우에도 Winodws NT는 로그 파일을 사용하여 데이터를 복구할 수 있습니다. 또한 NTFS는 오류 메시지를 표시하지 않고 하드 디스크 오류를 자동으로 복구합니다. 즉, Windows NT에서 NTFS가 분할 영역에 파일 쓰기를 할 경우, 파일을 복사하여 메모리에 저장하고 다시 파일을 읽어들인 후 메모리의 파일 복사본과 비교하여 두 파일이 일치하지 않으면 해당 하드 디스크 섹션을 불량으로 표시하고 다시 사용하지 않습니다. 대신 메모리에 저장된 파일의 복사본을 이용하여 하드 디스크의 다른 장소에 파일을 다시 씁니다. 반면 FAT와 FAT32 파일 시스템에는 이러한 안전 기능이 없습니다. FAT와 FAT32 파일 시스템에서는 2개의 파일 할당 테이블 복사본을 만들어 파일이 손상될 경우를 대비하지만 오류 자동 복구 기능은 없고 대신 디스크 읽기와 같은 유틸리티를 실행해야 합니다.

▶보안
NTFS에는 보안 시스템이 내장되어 있어서 디렉터리와 개별적인 파일에 대한 사용 권한을 허가할 수 있고 파일과 디렉터리를 원격 또는 로컬 침입자로부터 보호할 수 있습니다. 예를 들어, 누군가가 사용이 제한된 파일을 액세스하려고 하면 NTFS의 내장된 보안 시스템이 이 파일을 보호합니다. FAT나 FAT32를 사용하는 경우 공유 사용 권한 기능을 통해 보안을 유지하는데, 비록 네트워크에서는 파일을 보호할 수 있지만 로컬 침입자로부터 파일을 보호할 수는 없습니다. 로컬 PC에 직접 가서 얼마든지 사용 제한된 파일을 액세스할 수 있기 때문입니다. 또한 공유 사용 권한 기능은 자칫 관리하기가 힘들어질 수 있습니다. 각각 고유 디렉터리를 가지는 사용자 수 백명이 한 서버를 사용한다고 가정하면 이들 각각에 대해 공유 사용 권한을 허가해야 하고 이들의 일부가 겹치게 되어 추가적인 문제가 발생할 수 있습니다.

▶파일 압축
NTFS의 또 한 가지 장점은 본래 파일의 압축을 지원한다는 것입니다. MS-DOS 6.22 파일 압축 프로그램을 사용해 본 사용자라면 이미 알고 있겠지만, 파일 압축을 하려면 전체 분할 영역을 압축해야 하고 시간도 오래 걸릴 뿐 아니라 완료된 후에는 PC의 파일 액세스 속도가 눈에 띄게 느려지고, 사소한 디스크 문제가 전체 분할 영역을 못쓰게 만들 수도 있습니다. 한편 FAT32의 경우는 압축 기능을 제공하지 않습니다. NTFS의 압축 기능은 이전 것보다 훨씬 뛰어난데 이 기능으로 파일이나 디렉터리를 선택하여 개별적으로 압축할 수 있습니다. 파일을 개별적으로 압축할 수 있기 때문에 사소한 하드 디스크 문제가 발생해도 압축 구성표에 영향을 미치지 않고 전체 분할 영역을 못쓰게 하는 문제는 발생하지 않습니다. 또한 잘 사용하지 않는 파일만 선택해서 압축함으로써 사용할 때만 이 파일들을 압축 해제할 수도 있습니다.

NTFS 5.0의 신기능

앞에서도 잠시 언급했듯이 윈도우 95 OSR2 버전부터 지원하기 시작한 FAT32 파일시스템을 윈도우NT 4.0에서 지원하지 못했으므로 윈도 95나98과 함께 멀티부팅으로 사용했던 사용자들은 파일 공유를 하지 못하여 어려움을 많이 겪어야 했습니다. 또한 하드디스크의 대용량화를 따르지 못하는 NTFS 4.0의 기능에 불만이 커갈 수밖에 없었습니다. 이에 따라 윈도우 2000부터 제공되는 새로운 파일 시스템 NTFS 5.0은 FAT32 파일 시스템을 지원하며, 이로 인해 2GB의 제약에서 해방되어 부트 파티션을 4GB 이상 사용할 수 있게 되었습니다. 이것은 기존 NTFS 4.0의 특징인 압축과 보안 기능에 여러 가지 기능이 더 추가된 파일 시스템입니다. 이외에도 개별적인 파일의 허가되지 않은 사용을 막기 위해 파일 레벨의 보안(암호화: Encryption)를 지원하며, 재부팅하지 않고 하드디스크 용량을 확장할 수 있습니다. 윈도 NT 4.0에서는 하드디스크를 넓게 쓰기 위해 용량을 확장하면 반드시 재부팅을 해야 했습니다. 단축 아이콘을 만들었는데 단축 아이콘의 대상 프로그램을 다른 곳으로(다른 하드디스크나 서버, 파티션) 이동시켜 버렸을 때 전에는 이동되어진 대상을 찾기 힘들었는데, 윈도우 2000은 분산 링크 트래킹(Distributed Link Tracking)을 지원해 이동된 대상 프로그램을 쉽게 찾을 수 있습니다. 그래서 한번 단축 아이콘을 만들어두면 원래 프로그램을 어디로 옮겨 놓아도 단축 아이콘의 링크는 자동으로 그 이동된 곳으로 링크가 바뀌어 집니다. 유닉스를 포함한 다른 NOS에는 포함되었던 디스크 쿼터 기능(사람마다 사용할 수 있는 용량을 제한 할 수 있는 기능)이 NTFS 5.0에는 포함되어 있습니다. 예를 들어 사용자별로 일정한 용량만 할당해 주고 더 이상은 못쓰게 제한하는 기능이 추가된 것입니다. 또한 하드디스크를 추가하면 일반적으로 하나의 디스크가 한 개의 드라이브 문자를 사용해왔습니다. 그래서 NT가 설치된 시스템에 하드디스크를 추가했을 때 드라이브 명이 바뀌어서 혼란스러워 했던 경험이 있을 것입니다. D:, E:, F: 같은 드라이브 문자에 대한 필요성을 없애기 위해서 NTFS directory에 다른 볼륨을 접목시킬 수 있는 마운트 포인트 기능과 파일이나 문서들의 빠른 검색을 지원하기 위하여 풀 텍스트와 프로퍼티 인덱싱(Full text and property indexing)기능이 추가되었습니다.

파일 시스템 선택
Windows 2000을 단독으로 설치할 경우 운영체제의 기능을 최대한 활용하고 싶을 경우 NTFS를 사용하는 것이 유리하며 다양한 운영체제를 이용하고 특히 리눅스 윈95/98/NT등과 멀티부팅으로 사용하면서 자료의 이동이 많을 경우 FAT16을 사용하는 것이 유리합니다. 하지만 대용량 하드디스크를 사용하면서 역시 윈도 95/98등과 같이 사용하는 경우 FAT32를 사용하는 것이 권장됩니다. 위에서 언급한 내용은 사용자의 시스템에 따라 다양한 방법으로 사용이 가능하고 특히 최근 파티션 설정 유틸리티(예를 들어 파워퀘스트사의 파티션 매직등)의 등장과 Windows 95/98에서 NTFS를 인식할 수 있도록 하는 유틸리티등의 프로그램이 다양하게 나오고 있으므로 차차 파일시스템간의 벽은 그리 높지만은 않다고 할 수 있습니다. 다양한 시도끝에 자신의 시스템에 가장 알맞는 파일 시스템을 설정하는 것이 가장 좋은방법이라 할 수 있습니다.
신고

제목이 우선 그럴듯 합니다 ㅋㅋ 저의 작명센스에 감복하여 주십시오... ㅎㅎ;;

제목 그대로 삼바를 이용해서 리눅스에서 윈도우즈의 스토리지에 읽고 쓸 수 있도록하고,
ftp서비스를 이용해 리눅스 사용자가 자신의 계정에 업로드를 할 때
리눅스 스토리지에 저장되는 것이 아닌, 삼바로 마운트한 윈도우즈 스토리지에 저장하는 시스템을 구축한 것입니다.

리눅스에 그냥 파일을 저장하면 되는데 왜 이러한 시스템을 구축했느냐...
그러한 이유는 다음과 같습니다.

1. 윈도우즈에서 파일을 관리하기 위함입니다.
사람들은 윈도우즈에서 파일을 많이 다룹니다. 따라서 윈도우즈의 파일 형식과 인코딩된 파일이름을 많이 사용하게 됩니다. 그런데 리눅스에서는 한글이나 기타 2바이트 문자들에 대한 인코딩 문제로 심하게는 파일을 인식하지 못하는 문제를 일으키기도 합니다.
 파일을 윈도우즈 스토리지에 저장하므로써, 파일들을 융통성있게 공유할 수 있습니다. 물론 리눅스에서 이러한 일들이 불가능한 것은 아닙니다. 그러나 공동 작업이 많이 이루어지는 윈도우즈 환경에서 편리하고 강력한 네트워크 폴더공유를 이용해, 각자의  ftp공간을 공유할 수 있도록 한다면, 협업 시스템을 위한 공동 작업장 형식의 스토리지 개념이 생성될 수 있습니다. 즉, ftp 공간과 네트워크 공유 공간이 나뉘어진 개념이 아닌 통합된 스토리지 개념이 되므로, 하나로 관리함으로써 더욱 편리해집니다.


2. 서비스 분리
파일을 저장하는 녀석과 파일을 제공하는 녀석은 따로 두고 싶은 마음에서 시도하게 되었습니다. 우리가 보통 대용량 하드디스크를 구입해서 일정 크기로 두 개의 파티션으로 나누고, 하나에는 운영체제를 비롯한 프로그램을 설치하고, 하나에는 일반 문서들이나 음악, 동영상 파일들을 저장하게 됩니다.
그처럼 마치 파티션을 두 개로 나눈듯한 분산 시스템을 구현해보고자 한 것입니다. 또한 웹서비스에서 사용되는 파일업로드와는 구분되게 파일서버 본연의 임무에 충실하게 만들고자 하였습니다. 따라서 대용량 파일 저장에 대한 리눅스서버의 부담을 덜어줄 수 있습니다.

이렇게 구성된 스토리지 서비스를 사용자가 ftp로 접속하게 되면, 다음과 같은 구조의 저장공간을 보게 됩니다.

사용자 루트--+--www
                   |
                   +--ftp

www디렉토리에는 사용자가 http 웹서비스로 보여줄 리소스들(html 파일이나 그림 파일등등)을 저장하는 곳입니다. 그리고 ftp가 바로 윈도우즈 공유폴더와 마운트한 디렉토리입니다.

여기서 사용자 루트를 통채로 마운트해서 www에 저장될 파일들을 윈도우즈 스토리지에 저장하면 안되느냐 의문이 들수 있으실텐데요... 그렇게 하지 않은 이유는 밑에 설명하겠습니다.(미리 말씀 드리자면 리눅스 권한 문제때문)

1.
우선 리눅스가 삼바를 통해 접속 가능하도록 윈도우즈의 계정을 하나 만들어줍니다.
(예를 들면 ftp // 123456 으로 만들었습니다.)
그리고 쓰기가 가능하도록 공유폴더를 하나 추가합니다.
그런데 여기서 폴더를 계정별로 쓰기가능하도록 지정할 수 있습니다.
windows xp의 경우 그런 기능이 숨겨져 있습니다.
폴더옵션을 열어서 보기의 고급설정에 보시면
모든 사용자에게 동일한 폴더 공유 권한을 지정의 체크를 해제하시면
계정별로 권한을 줄 수 있습니다.
ftp 사용자가 공유폴더에 쓰기 가능하도록 지정해줍니다.

2.
그리고 리눅스로 와서 mount 명령으로 윈도우즈 공유 폴더를 마운트 합니다.
우선 윈도우즈 공유폴더를 마운트할 디렉토리를 mkdir 명령으로 만들어 줘야겠죠..

그리고 여기서 ftp에 접속할 사용자의 uid와 gid를 알아두어야 합니다.
uid와 gid는 계정의 id 번호와 사용자가 속한 그룹의 id 번호입니다.
확인은 사용자,그룹 관리 툴을 사용해서 확인하실 수 있으며
/etc/passwd 파일을 열어서 볼 수 있습니다.

uid와 gid 그리고 umask=000을 해주는 이유는
그냥 마운트를 하게 되면 root 계정만 윈도우즈 공유폴더에 삼바를 통해 쓰기가 가능하고,
ftp를 통해 접속하게 되는 사용자는 윈도우즈 공유폴더에 쓰기가 불가능 합니다.
따라서 uid와 gid에 쓰기를 허용하고자 하는 사용자의 정보를 넣어 주는 것입니다.

예를 들어 리눅스의 soulfree(uid:501, gid:501)라는 계정이 ftp에 접속해서 윈도우즈 공유폴더(soulfree_ftp)에 파일 쓰기가 가능하도록 하고자 한다면,

mount -t smbfs -o username=ftp,password=123456,uid=501,gid=501,umask=000 //windows/soulfree_ftp ./ftp

파란색 부분은 윈도우즈에 접속하기 위한 윈도우즈 계정 정보입니다.
핑크색 부분은 마운트한 윈도우즈 공유폴더에 쓰기가 가능한 사용자를 지정해주는 부분입니다.
초록색 부분은 윈도우즈 공유폴더 위치입니다.
회색 부분은 윈도우즈 공유폴더를 리눅스 상에서 마운트시킬 리눅스 폴더입니다.

3.
ftp 서버를 실행합니다..
그리고 이제 ftp 클라이언트로 soulfree라는 계정으로 접속을 하면
마운트 시킨 ftp 디렉토리에 업로드가 가능합니다.
윈도우즈에서 공유폴더에 보면 soulfree 클라이언트가 업로드한 파일이 저장되어 있음을 확인 할 수 있습니다.

※ 그런데 왜 www의 파일들은 이런 방식을 사용하지 않았나?
리눅스 home 디렉토리에는 사용자들 이름으로 사용자 저장공간이 있습니다.
저는 각 사용자의 www 디렉토리에 http 리소스를 저장하도록 하였고, 아파치가 그것을 참조하여, 가상호스트로 작동하도록 하였습니다.
따라서 www내용을 윈도우즈에 저장하기위해서는, 윈도우즈에서 개인별로 www라는 이름의 공유폴더를 만들어 주어야하고, 그렇게 되면 공유폴더가 너무 많아 집니다.
사실 ftp 공유폴더도 개인당 하나씩 공유폴더가 생기는거라 공유폴더가 너무 많아지는 문제가 생깁니다.

그때문에 home 디렉토리 전체를 마운트하는 방법을 시도해봤습니다.
그러나 home 디렉토리 전체를 마운트함에 따라 특정 리눅스 명령어가 home 디렉토리에 쓰기가 제한되는 문제가 발생하더군요.
또한 ftp를 이용해 업로드 도중 접속을 끊었을 경우 I/O 교착상태가 발생해서 시스템이 마비되는 것을 경험했습니다.

그래서 soulfree라는 특정 계정의 공유폴더를 만들고 그것을 사용자 디렉토리에 마운트 하는 방법을 사용했습니다.
이 역시 read는 성공적이었으며, ftp 업로드도 문제없었습니다.
그러나 http 서비스를 이용한 업로드의 경우, 쓰기 권한이 없어 업로드가 되지 않는 문제가 생겼고,
제로보드의 경우, 마운트한 윈도우즈 폴더의 권한을,
chmod 등의 명령을 통한 리눅스 방식으로 설정할 방도를 제가 알지 못해서
사용하지 못하겠다는 결론에 도달했습니다.

그래서 ftp 전용 폴더를 만들게 된 것입니다...

문제점
사실 장점과 제 욕구에만 충실하기 위한 작업이었습니다.
그러나 이러한 작업을 자동화 하는 등의 해결해야할 문제점이 많이 남아 있습니다.

1.사용자 생성시 윈도우즈 공유폴더 추가 문제
쉘 스크립트로 자동화하여 사용할 시 문제입니다.
리눅스 사용자 추가시, 윈도우즈 공유폴더도 사용자 전용으로 자동으로 만들어 주어야합니다.
리눅스에서 윈도우즈에 폴더를 만드는 것 까지는 가능합니다. 그러나 리눅스에서 윈도우즈 폴더를 마운트 포인트로 만드는 것은 불가능합니다.

무슨 이야기인가 하면,
리눅스의 마운트 포인트로는 공유폴더로 지정한 그 위치만 가능하지,
공유폴더의 하위 폴더는 마운트 포인트로 지정할 수 없다는 것입니다.

따라서 윈도우즈 폴더를 자동 생성시키더라도, 공유 폴더 지정을 일일이 손으로 해주어야 합니다.

2. 기존 리눅스 ftp 저장소에 쓰기 문제
IT 공학 공부를 해오고 잠시 일도 해본 경험에서,,
사람들은 개발자들의 요구를 그리 귀기울이지 않습니다.
윈도우즈 공유폴더를 마운트한 ftp디렉토리를 따로 만들어 두었다고해서
반드시 그 디렉토리에 업로드 하지만은 않을 것입니다.
따라서 리눅스 스토리지에 저장한 파일들을 자동으로 ftp 디렉토리에 이동하도록 하는 방법이 있어야 할 것 같습니다.

3. 공유폴더의 숫자...
윈도우즈의 공유폴더는 탐색기에서 모두 나타나게 됩니다. 물론 접근은 안되지만 목록이 보이는 것 조차도 신경쓰이는 일이 아닐 수 없습니다. 이러한 서비스를 사용하는 사람이 얼마나 되는지 등의 정보를 알 수 있기 때문이죠.
그리고 공유폴더가 너무 많아지면 관리하는데 한계가 나타나게 될 것입니다.

너무 두서없이 끄적이고 기술적인 코드는 한줄이 고작이네요^^;;
그러나 나름 이기종간의 분산 파일 스토리지 공간을 이용해, 협업시스템에 적용하고자하는 패러다임을 구현했다고 생각됩니다.
신고