VB 절사 부분

2009/10/06 13:20

This is a protected post. Please enter the password to view the article.
이 글은 비밀글입니다. 글을 보시려면 비밀번호를 입력하세요.

1. Option Explicit를 명시한다. 쓰지도 않는 변수들이 생기면 그만큼 메모리 낭비가 생기므로...

2. 배열사용 시 배열 재할당은 최대한 피한다.

3. 배열 사용이 빈번할 시 Dictionary 객체를 이용하여 가독성을 높인다.

4. Stored Procedure를 사용한다. (일반 ASP자체 쿼리보다 최고 30% 성능 향상.)

5. 뷰테이블 사용 시 뷰테이블 자체에서 정렬을 해야 한다. 이미 만들어진 뷰테이블을 이용하여 Asp 코드
에서 정렬하면 속도가 크게 떨어진다. 최고 50%까지 느려지는 것을 목격했음.

6. Query를 사용할 때 꼭 필요한 컬럼만 명시하여 불러오거나 이용해야 한다. SQL은 아주 정직해서 불러
오는 컬럼의 갯수(레코드 수가 동일하다고 가정시)에 비례하여 시간이 걸린다.

7. Recordset 객체 보다는 Command 객체를 이용하는 것이 빠르다. 10%정도의 향상을 볼 수 있었다.

8. Recordset 객체 사용시 CursorLocation를 적절한 것을 사용해야 한다. (1, 서버, 3. 클라이언트) 속도의
차이가 클 수 있다. CursorType도 영향을 미친다. 반드시 테스트 필요. 보통은 CursorLocation은 클라이언
트에 두는 것이 추세다. 테스트때 클라이언트에 커서를 두었을때 서버에 두었을때보다 속도가 최고 3배이상
빨라지는 것을 경험했다.

9. 1000글자가 넘어가는 문장의 경우는 변수에 담아서 한번에 Response.Write 하는 것보다는 한줄한줄 직
접 뿌려주는 것이 빠르다. <%= %>를 이용해 직접 뿌리는 것이 가장 빠르다. 괜히 변수에 잔뜩담아서
Response.write 해보라 -_-;;; 아마 글자수의 제곱에 비례하여 느려질 것이다 -_-;;;

10. 사용한 객체는 반드시 Close, Nothing 해준다. 안해주면 메모리 누수가 일어난다. 웹서버들이 잘 죽는
경우는 반드시 이것을 체크해야 한다.

11. 다중레코드를 이용할 시에는 Do until, Rs.MoveNext 구문보다는 GetRows() 함수를 이용하는 것이 빠르
다.(Stored Procedure와 함께 사용시 최고 40% 성능 향상, 단독으로 사용시 최고 20% 성능 향상.)

12. 사용자 Function을 만들어 쓰는 것이 디버깅 등에 좋다.

13. ADODB 객체 사용보다 OBJECT 객체를 사용하여 컨넥션, 레코드셋을 연다.
2009/09/01 15:55 2009/09/01 15:55
 

Source from:[S.S.R.E.T]ServersTeam.Org [F.N.S.T]Fineacer.Org
url:http://www.Serversteam.org/docs/Microsoft_Win_ASP_Webshell_Security.htm

개요:본문에서는 Microsoft 윈도우 계열의SERVER (IIS5.0、IIS6.0)에서 간단하고 빠르게 ASP 위험성 있는 컨포넌트를 WEB서버 시스템으로부터 멀리하는 것을 설명한다. 본문을 읽는 후 자기가 관리하고 있는 서버를 asp 트로이잔, Webshell 권한상승 및 시스템 보안위협 등으로부터 벗어날 수 있다.

본문:
주의:본문에서 언급된 설정방법 및 설정환경은:Microsoft Windows 2000 Server/Win2003 SERVER | IIS5.0/IIS6.0에 적용함.

1、우선 일반적인ASP트로이잔을 살펴본다, Webshell에서 사용한 ASP 컨포넌트는 아래와 같다. 중국산 webshell인 HY2006를 예를 들어보면,

<object runat="server" id="ws" scope="page" classid="clsid:72C24DD5-D70A-438B-8A42-98424B88AFB8"></object>
<object runat="server" id="ws" scope="page" classid="clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="net" scope="page" classid="clsid:093FF999-1EA0-4079-9525-9614C3504B74"></object>
<object runat="server" id="net" scope="page" classid="clsid:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B"></object>
<object runat="server" id="fso" scope="page" classid="clsid:0D43FE01-F093-11CF-8940-00A0C9054228"></object>
shellStr="Shell"
applicationStr="Application"
if cmdPath="wscriptShell"
set sa=server.createObject(shellStr&"."&applicationStr)
set streamT=server.createObject("adodb.stream")
set domainObject = GetObject("WinNT://.")

이상은 HaiYang webshell의 일부 소스다, webshell에서는 아래 여러 종류의 ASP컨포넌트를 사용하고 있는 것을 알 수 있다.
① WScript.Shell (classid:72C24DD5-D70A-438B-8A42-98424B88AFB8)
② WScript.Shell.1 (classid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B)
③ WScript.Network (classid:093FF999-1EA0-4079-9525-9614C3504B74)
④ WScript.Network.1 (classid:093FF999-1EA0-4079-9525-9614C3504B74)
⑤ FileSystem Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228)
⑥ Adodb.stream (classid:{00000566-0000-0010-8000-00AA006D2EA4})
⑦ Shell.applicaiton....

2: 해결방법:

① 아래 위험성 있는 ASP 컨포넌트를 삭제 혹은 명칭을 변경한다.
WScript.Shell、WScript.Shell.1、Wscript.Network、Wscript.Network.1、adodb.stream、Shell.application
[시작->실행->Regedit]을 실행하여 레지스토리를 수정한다. “Ctrl+F”으로 찾기를 실행한다. 순서대로 위에 Wscript.Shell등 컨포넌트의 명칭 혹은 그와 매칭한 ClassID을 입력한다. 해당 명칭을 삭제하거나 변경한다. (여기서 명칭변경을 권장한다. 만약 일부 웹 페이지의ASP프로그램에서 위에 열거한 컨포넌트를 사용했다면, ASP코드작성시 수정된 컨포넌트의 명칭을 사용하면 모든 것이 정상적 사용을 가능하다. 만약 ASP프로그램에서 이상의 컨포넌트를 사용하지 않는다면 삭제하는 것이 좋다. 삭제 혹은 명칭 변경 후, iisreset으로 IIS재 동작 후 적용한다.)
[주의:Adodb.Stream 컨포넌트는 많은 사이트에서 사용하기 때문에  만약 서버가 Virtual machine 이면 상황에 따라 조치 바람.]

② File System Object (classid:0D43FE01-F093-11CF-8940-00A0C9054228) 보안 문제에 대해 만약 서버에서 FSO를 사용해야 한다면(일부 Virtual Machine에서는 FSO기능을 사용함), FSO보안 해결방법은 “Microsoft Windows 2000 Server FSO 安全隐患解决办法” 문서를 참고하시길 바란다. 사용할 필요 없는 경우 직접 사용중지 하면 된다.

③ 사용중지 혹은 위험성 있는 컨포넌트를 삭제하는 방법:(방법① 및 방법②를 번거롭다고 생각하는 분은 본 방법을 참고함.)

wscript.shell 오브젝트를 해제하는 방법은 아래와 같다. cmd 모드에서[:regsvr32 /u %windir%\system32\WSHom.Ocx]를 실행한다.
FSO 오브젝트를 cmd 에서 아래 내용을 실행하여 해제한다. [regsvr32.exe /u %windir%\system32\scrrun.dll]
stream 오브젝트의 해제는 cmd에서 [regsvr32 /s /u "C:\Program Files\Common Files\System\ado\msado15.dll" ]를 실행한다.
만약 실행취소를 원한다면 위에 명령에 [/U] 옵션만 제거하면 된다. 즉, 관련 ASP컨포넌트를 재실행 가능하다. 예를 들면, regsvr32.exe %windir%\system32\scrrun.dll

④ Webshell 중에 set domainObject = GetObject("WinNT://.")을 사용하여 서버 프로세스, 서비스 및 사용자 정보 등을 획득하는 것에 대한 예방 방법은 아래와 같다. 서비스 중의 Workstation[네트워크 연결 및 통신을 제공함] 즉, Lanmanworkstation서비스를 중지하면 문제해결 된다. 이렇게 처리하면 Webshell 프로세스를 디스플레이 하는 곳에 공백으로 표시된다.

3 위에 방법1、2에 따라 ASP관련 위험한 컨포넌트에 대해 처리 후, Ajiang asp probe으로 테스트하면,"서버CPU상세내역" 및 "서버운영체제"를 찾을 수 없으며 내용은 모두 공백으로 디스플레이 된다. HaiYang을 사용하여 Wscript.Shell를 테스트 하면, cmd commend line에서 Active를 만들 수 없다는 메시지가 디스플레이 된다. ASP 트로이잔이 서버 시스템에 대한 보안 위협을 완화할 수 있다.
본문에서 소개한 내용은 단지 본인이 ASP트로이잔、Webshell에 대한 소견뿐이다. 향후 여러분께 어떻게 간단하게 타인 컴퓨터에 net user 와 같은 명령의 실행을 방지하고, 버퍼 오버플로우를 통해 cmdshell 획득을 방지 및 사용자 추가의 방지, NTFS 설정권한에서 터미널 서비스 등록 등에 대한 간단하고도 효과적인 방어방법을 소개할 예정이다.


저자: 李泊林/LeeBolin
[S.S.R.E.T 服务器安全研究专家小组 CTO] Http://www.serversteam.org
[F.N.S.T 情长计算机网络安全在线 技术顾问] Http://www.fineacer.org
E-mail:leebolin#serversteam.org QQ:24460394 본문관련 질문 사항은 메일 혹은 QQ에 연락하시길 바람
 
 
2009/09/01 11:28 2009/09/01 11:28
DDos 공격 좀비 컴을 확ㅇ니하는 플그램.

2009/07/09 20:01 2009/07/09 20:01
IIS튜닝 - 캐시 조정


www.wssplex.net

ASP파일 캐시

캐싱할 미리 컴파일된 스크립트 파일 수를 메모리에 저장할 파일수를 지정은 기본값으로 500(IIS5-250)개 이다. 이 속성은 사용 가능한 메모리 양과 스크립트 파일 트래픽의 양에 따라 성능을 조정하는 데 사용된다.

메모리에 캐시된 내용은 컴파일 되지 않은 ASP 요청보다 훨씬 빠르게 응답하게 된다. 메타베이스 속성값은 AspScriptFileCacheSize 이다.

물론 이 값을 높게 설정할수록 캐시량은 많아지지만, 캐시된 만큼 메모리를 점유하게 되므로 적용전 메모리 상태를 먼저 확인하는 것이 좋으며, 변경후에 캐시 적중 성능카운터를 이용해 그 효과를 측정해야 한다.




캐시할 스크립트 엔진

파싱된 스크립트를 바이트 코드로 변환하는 작업을 수행한다. IIS5에서는 125개 이며, IIS6에서는 250개가 기본값으로 되어 있다. 만약 웹사이트에서 수천개의 ASP페이지가 존재한다면 이 값을 증가시키는 것 만으로도 성능향상을 꾀할수 있다.



IIS6에서 추가된 디스크에 캐시를 저장하는 옵션으로 디스크에 파일캐시를 저장할경우 지정된 디렉토리에 캐시된 ASP파일이 저장된다. 언제나 그렇듯 ASP 파일내용이 자주 변경되는 웹사이트의 경우 캐시의 효과는 변경되는 비율많큼 적어진다.



위 성능카운터 값은 필자가 운영하는 서버중 한대로 Http 동시접속수 1249개 인 웹서버로 초당 Asp요청수가 초당 50~60건 정도이며, File Cache Hits 93% 인 상태이다. 성능카운터의 File Cache Hits %가 80~90% 선을 지속적으로 유지할 때 만족스러운 상태로 판단할 수 있다.

Adsutil.vbs set 메타베이스경로 "값"
Adsutil.vbs set 메타베이스경로 "값"
Adsutil.vbs set AspScriptEngineCacheMax "값"


IIS 파일 캐시 설정 변경

IIS는 서버에서 사용 가능한 메모리의 50% 까지 사용한다. 그러나 웹전용 서버이면서 IIS에서 점유하는 메모리가 50%에 다다른경우 시스템운영에 적정여유량을 제외한 나머지 값까지 사용할수 있도록 이 값을 변경해 볼 필요가 있다.

MemCacheSize
레지스트리 경로:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters
데이터 형식: REG_DWORD
범위: 0-2,500MB 기본값은 60초마다 동적으로 조정.


캐시된 리소스에 대한 TTL값 조정

IIS는 마지막요청후 30초 이내에 재요청이 없을경우캐시를 파기한다. 서버에 메모리 여유가 있다면 캐시에 오래 남아 있을수 있도록 TTL값을 조정해 볼 필요가 있다.

ObjectCacheTTL
레지스트리 경로:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters
데이터 형식: REG_DWORD
기본값: 30초
범위: 0 - 4,294,967,295 (제한 없음)


2009/06/18 13:41 2009/06/18 13:41

IIS 업로드 용량 제한 컨트롤
제가 알기론 2003에서 200K 용량 제한이 있는것으로 알고 있습니다.
이는 MetaBase.xml에 지정되어 있을것인데요.

C:\WINDOWS\system32\inetsrv\MetaBase.xml
을 보시면 AspMaxRequestEntityAllowed="204800" 으로 되어있습니다.
이 값을 변경시켜주면. 200K 용량제한을 해결하실수 있을것입니다.
이거 하시기전에 IIS 중지를 먼저 해주세요


M$계열 서버 부하 통계 알아보기
성능모니터링을 활용하는 방법
http://mudmania.org/reiot/PerformanceMonitoring

Web Application Stress Tool의 이용
http://support.microsoft.com/default.aspx?scid=kb;KO;231282
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en

mrtg
http://mrtg.co.kr/
http://snmpboy.msft.net/default.aspx

log 분석
http://awstats.sourceforge.net


성능 모니터 중요한 몇가지
Processor - % Process Time ||
프로세서 사용률
이 값이 장시간 동안 80% 이상의 값을 나타내면 프로세서의 사용률이 과다한 것입니다.

Memory - Available Bytes
사용가능한 메모리 양입니다
점차 낮아지거나 장시간 동안 시스템 전체 메모리의 20% 미만인 경우에는 메모리가 부족한것입니다.

Web Service - Current Anonymouse users
동시 사용자의 수

ASP - Reqeust Queued
처리를 위해 대기 중인 ASP 스크립트의 수입니다.
동시 사용자 수가 500 이상인 상황에서 이 값이 5 이상의 값을 나타내면 웹 서버의 처리 능력을 초과한 것입니다.

Web Service - Current ISAPI Extension Requests
웹 서버에서 사용하는 DLL형태의 익스텐션이나 컴포넌트에 대한 호출 횟수입니다
동시 사용자 수가 500 이하인 상황에서 이 값이 5 이상의 값을 나타내면 웹서버의 처린 능력을 초과한 것입니다.


[Win2000] 튜닝을 위한 성능 모니터링
1) 성능 모니터링
웹 서버를 튜닝하기 위해서 주요한 도구중에서 성능 모니터링은 웹 서버 뿐만이 아니라 윈도우 2000 서버의 중요한 성능에 대한 각종 사항을 보여주는 유효한 도구 입니다. 성능 모니터링 도구를 이용하여 웹 서버 및 윈도우 2000 서버의 각종 성능을 모니터링 할 수 있는데 이것들은 프로세서와 메모링등 다양한 종류에 대한 카운터 정보를 모니터링 함으로써 추가 하드웨어 구입에 대한 정보나 현재 문제가 되고 있는 병목현상등을 파악할 수 있는 중요한 지표를 제공합니다.
성능 도구는 해당 컨텐트를 개체, 카운터 및 인스턴스로 그룹화합니다. 개체는 가장 높은 추상화 계층으로, 모니터링할 수 있는 리소스나 서비스와 관련된 카운터의 논리적 컬렉션으로 정의됩니다. 카운터는 성능 개체와 관련된 데이터 항목입니다. 선택된 각 카운터에 대해 성능 도구는 성능 개체에 대해 정의한 성능의 특정 측면을 나타내는 값을 제공합니다. 인스턴스는 가장 낮은 추상화 계층으로, 한 대의 시스템에서 같은 유형의 여러 성능 개체 간을 구분하는 데 사용됩니다.

Windows 2000 핵심 카운터
웹 응용 프로그램에서 성능 병목 현상을 검사하기 전에 운영 체제 수준에서 성능 문제점을 찾아야 합니다. 대개 메모리 부족과 같은 리소스 문제로 인해 시스템에서 다른 성능 문제가 발생할 수 있습니다. 시스템 성능을 이해하고 향상시키기 위해서는 시스템의 모든 부분에 대해 병목 현상이 있는가를 검사해야 합니다.
다음 성능 카운터를 면밀히 검사하여 서버에 프로세서, 메모리, 디스크 또는 네트워크 병목 현상이 있는지 확인하십시오. 웹 서버에서 나타나는 성능 병목 현상을 해결하는 데 도움을 주기 위해 각 카운터에 대한 설명과 함께 측정된 임계값, 권장 사항이 제공됩니다. 모든 검사는 2개의 프로세서와 1GB의 물리적 RAM이 있는 웹 서버에서 수행되었습니다. 성능 카운터는 개체:카운터:인스턴스 형식으로 표시됩니다(해당되는 경우).

Memory: Available Bytes ? 이 카운터는 시스템에서 실행되는 프로세스에 사용할 수 있는 실제 메모리 양을 바이트 단위로 표시합니다. 이 값은 Zeroed, Free 및 Stand-by 메모리 목록에 공간을 추가하여 계산합니다. Free 메모리는 사용할 수 있는 메모리이며, Zeroed 메모리는 나중에 프로세스가 이전 프로세스에서 사용한 데이터를 보지 못하게 하기 위해 0으로 채워진 메모리 페이지를 나타내며, Stand-by 메모리는 디스크로 보내지는 프로세스 작업 집합에서 제거되었지만 회수할 수 있는 메모리입니다. 이 카운터는 마지막으로 검색된 값만 표시합니다.

Available Bytes 값이 낮으면(4MB 이하) 시스템의 전체적인 메모리가 부족하거나 프로그램이 메모리를 릴리스하지 않는 경우일 수 있습니다. 4MB의 임계값에 도달하면 시스템의 가상 메모리가 부족함을 나타내는 이벤트 26이 시스템 이벤트 로그에 기록됩니다. 메모리가 낮으면 이벤트가 기록될 뿐 아니라 영향받는 시스템의 성능도 저하됩니다.

메모리 관련 성능 문제를 피하려면 웹 사이트가 최대로 사용될 때를 대비하여 적어도 10%의 메모리를 보유해야 합니다.

Memory: Cache Bytes - 이 카운터는 파일 시스템 캐시의 크기를 보여 줍니다. 이 크기는 설치된 실제 메모리 크기에 따라 최대 900MB까지 사용 가능한 실제 메모리의 50%를 사용하도록 설정됩니다. IIS는 메모리가 부족할 때 자동으로 캐시의 데이터를 지우므로 이 카운터는 중요합니다. 이 카운터를 아래에서 설명하는 Private Bytes와 함께 사용하면 메모리 누수가 있는 응용 프로그램을 격리할 수 있습니다.

Memory: Page Faults/Sec - 이 카운터는 초당 폴트된 평균 페이지 수를 측정합니다. 이 카운터는 하드 폴트(디스크 액세스를 필요로 하는 폴트)와 소프트 폴트(실제 메모리에서 폴트된 페이지가 있는 위치)를 모두 포함합니다. 대부분의 프로세서가 큰 영향 없이 많은 수의 소프트 페이지 폴트를 처리할 수 있습니다. 그러나 디스크 액세스를 필요로 하는 하드 폴트는 심각한 성능 문제를 유발할 수 있습니다. 이 카운터의 값이 낮으면 서버는 빠르게 요청에 응답합니다. 이 값이 높으면 나머지 시스템을 위해 충분한 메모리를 남겨 두지 않고 파일 시스템 캐시에 너무 많은 메모리가 할당될 수 있습니다. 페이지 폴트/초 값이 너무 높으면 서버의 실제 메모리 양을 늘려야 합니다.

Process: Private Bytes: (Inetinfo, Dllhost) - 이 카운터는 Inetinfo가 할당했으며 다른 프로세스와 공유할 수 없는 현재의 메모리 양을 측정합니다. 이 카운터는 이러한 프로세스가 긴 기간 동안 메모리를 릴리스하지 않고 시스템에 더 많은 메모리를 할당하고 있다는 사실을 알았을 때 웹 응용 프로그램의 메모리 누수를 격리시키는 데 도움이 됩니다. 응용 프로그램의 격리 수준이 낮게 설정되면 Private Bytes 카운터에서 Inetinfo 프로세스를 모니터링하십시오. 격리 수준이 보통이거나 높게 설정되면 해당 DLLHost 프로세스를 모니터링하십시오.

System: Processor Queue Length - 이 카운터는 프로세스 대기열에서 실행을 기다리는 스레드의 수를 나타냅니다. 프로세스가 여러 개 있는 컴퓨터에서도 프로세스 시간을 기다리는 준비 대기열은 하나만 있습니다. 이 카운터는 실행 중인 스레드가 아니라 준비 스레드만 계산합니다. 프로세서당 스레드가 2개가 넘는 프로세서 대기열 길이는 서버가 느리게 작동하거나 응답하지 않는 프로세서 정체 상태를 나타낼 수 있습니다. 여러 프로그램 프로세스가 프로세서 시간을 위해 경쟁하는 경우 더 빠른 프로세서를 설치하여 처리량을 향상시킬 수 있습니다. 멀티스레드 프로세스를 실행하는 경우에는 프로세서를 추가하는 것이 도움이 될 수 있지만 이러한 경우에 얻을 수 있는 이점은 제한되어 있습니다.

참고 긴 스레드 대기 상황에서는 한 대의 유휴 시스템에 두 개 이상의 프로세스 대기열이 있을 수 있습니다.

Processor: % Processor Time - 이 카운터는 프로세서가 비유휴 스레드를 실행하는 데 사용하는 시간(%)을 표시합니다. 이 카운터는 프로세서 활동에 대한 기본 지표로, 서버 작동 중단이나 무응답 상태와 같은 문제를 해결하는 데 사용할 수 있습니다. 이 성능 카운터를 분석할 때는 컴퓨터의 역할을 이해해야 합니다. 예를 들어, CAD 응용 프로그램에 주로 사용되는 컴퓨터를 모니터링하는 경우 CAD 응용 프로그램은 실행 중에 100%의 프로세스 시간을 쉽게 사용할 수 있습니다. 많은 클라이언트 요청을 처리하는 서버에서 이 값이 100%에 가깝다면 사용 가능한 프로세서 시간을 기다리기 위해 프로세스가 대기 중이므로 병목 상태일 것입니다. 따라서 서버에서 100%에 가까운 프로세서 사용률을 유지하는 일은 불가능하며, 프로세서를 추가하거나 작업 로드를 수정해야 합니다. 웹 서버에서 허용되는 프로세서 사용률 임계값은 70%입니다.

Network Interface: Bytes Total/Sec - 이 카운터는 네트워크 인터페이스에서 바이트를 보내고 받는 속도를 측정합니다. 네트워크 연결에서 병목 현상이 발생하는지 확인하려면 Network Interface: Bytes Total/sec 카운터 값과 네트워크 어댑터 카드의 총 대역폭을 비교해 보십시오. 급격히 증가하는 트래픽에 대비하려면 용량의 50% 이하만 사용해야 합니다. 이 값이 연결 용량에 거의 근접하고 프로세서와 메모리 사용량에 문제가 없으면 연결에 문제가 있는 것입니다.

Physical Disk: % Disk Time - 이 카운터는 선택한 디스크 드라이브가 읽기 및 쓰기 요청을 처리하는 시간을 측정합니다. 이 카운터 값이 높으면(90% 초과) Physical Disk: Current Disk Queue Length 카운터를 검사하여 디스크 액세스를 기다리는 시스템 요청 수를 확인해야 합니다. 대기 I/O 요청 수는 실제 디스크를 구성하는 스핀들 수의 1.5-2배 수준으로 유지되어야 합니다. 스핀들 정보에 대해서는 서버 제조업체에 문의하십시오. 일반적으로 대부분의 디스크에는 스핀들이 하나만 있지만 RAID 장치에는 더 많은 스핀들이 있습니다. 하드웨어 RAID 장치는 시스템 모니터에 하나의 실제 디스크로 나타나지만 소프트웨어를 통해 만들어진 RAID 장치는 여러 드라이브로 나타납니다. 각 실제 드라이브(RAID가 아닌)의 Physical Disk 카운터를 모니터링하거나 _Total 인스턴스를 사용하여 모든 컴퓨터 장치의 데이터를 모니터링할 수 있습니다.

Physical Disk: Current Disk Queue Length 및 Physical Disk: % Disk Time 카운터 값을 사용하여 디스크 하위 시스템의 병목 현상을 찾아 내십시오.이들 값이 모두 높으면 디스크 드라이브를 업그레이드하거나 자주 액세스하는 파일을 다른 디스크나 서버로 옮기는 것을 고려할 수 있습니다.

참고 RAID 장치를 사용하는 경우 % Disk Time이 100%보다 더 큰 값을 나타낼 수 있습니다. 이 경우 Physical Disk: Average Disk Queue Length 카운터를 사용하여 평균적으로 디스크 액세스를 기다리는 시스템 요청의 수를 확인하는 방법을 고려해야 합니다.

웹 응용 프로그램 성능 카운터
Microsoft는 관리자들이 웹 응용 프로그램의 문제점을 규명하는 데 도움을 주기 위해 성능 도구에 몇 가지 개체를 제공하고 있습니다. 아래의 웹 응용 프로그램 성능 카운터를 사용하여 응용 프로그램에 성능 병목 현상이 있는지 확인하십시오. 응용 프로그램의 성능 문제점을 빠르게 확인하고 해결하는 데 도움을 주기 위해 각 성능 카운터에 대한 설명과 임계값 및 권장 사항이 제공됩니다. 모든 임계값과 권장 사항은 프로세서가 두 개 있고 RAM이 1GB인 웹 서버에서 측정한 결과에 따른 것입니다. 성능 카운터는 개체:카운터:인스턴스 형식으로 표시됩니다(해당되는 경우).

Active Server Pages:Requests Executing - 이 카운터는 현재 실행 중인 요청의 수를 계산합니다. 이 카운터는 응용 프로그램이 한 번에 하나의 요청을 효율적으로 실행하는지 여부를 나타냅니다. 요청이 하나씩 실행되면 알려지지 않은 원인으로 인해 요청이 serialization됩니다. 일반적으로 인터넷 서비스 관리자를 통해 ASP 디버깅을 설정하면 serialization이 발생합니다.

자세한 내용과 코드 serialization의 예를 보려면 다음을 참조하십시오.

InProc 구성 요소(DLL)를 사용할 경우의 차단

Active Server Pages:Requests Queued - 이 카운터는 대기열에서 서비스를 기다리는 요청의 수를 측정합니다. 이상적인 값은 0입니다. 이 값이 계속 증가하면 ASP는 스레드를 차단하며, 대기열의 다른 요청을 처리할 수 있도록 스레드가 릴리스되지 않습니다. 스트레스 상황에서 Requests Queued 값이 상당히 증가하면 프로세서 사용률은 비교적 낮은상태를 유지하고 이것은 스크립트가 처리할 수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다는 표시입니다. 이 경우 COM 개체는 병목 현상을 발생시킵니다. 이 경우 IIS가 만드는 프로세서당 최대 작업자 스레드 수를 지정하는 ASPProcessorThreadMax 메타베이스 항목을 늘려야 합니다.

ASPProcessorThreadMax 메타베이스 항목에 대한 자세한 내용은 다음을 참조하십시오.

ASPProcessorThreadMax를 조정하는 방법

Active Server Pages: Sessions Total - 이 카운터는 서비스가 시작된 후의 전체 세션 수를 측정합니다. 특정 테스트 스크립트에 대해 만들어진 전체 세션을 모니터링하는 경우 보다 정확한 측정을 위해 테스트 실행 전에 웹 서비스를 중지했다가 다시 시작하는 것이 좋습니다. 스크립트가 실행 중인 경우 Sessions Total 값은 원하는 수준에 도달할 때까지 서서히 증가합니다. Sessions Total이 원하는 수준에 도달하지 않으면 웹 서비스를 중지했다가 다시 시작한 다음 다른 테스트를 실행할 수 있습니다.

Web Service: CGI Requests/sec 및 ISAPI Extension Requests/Sec - 이 카운터는 서버가 CGI 및 ISAPI 응용 프로그램 요청을 처리하는 속도를 측정합니다. 로드가 증가하는 동안 이 값들이 감소하면 응용 프로그램 개발자들에게 코드를 확인하도록 지시할 수 있습니다.

Web Service: Get Requests/Sec 및 Post Requests/Sec - 이 카운터는 서버에 두 가지 유형의 HTTP 요청이 수행되는 속도를 나타냅니다. POST 요청은 일반적으로 폼에 사용되며 ISAPI(ASP 포함) 또는 CGI로 전송됩니다. GET 요청은 POST 요청을 제외한 거의 모든 브라우저의 요청을 나타내고 정적 파일, ASP 및 기타 ISAPI 요청, CGI 요청 등을 포함합니다. 이러한 카운터는 사이트의 일반 로드 특성을 이해하는 데 많은 도움이 됩니다.





[Win2000] IIS 튜닝 하는 방법 자료에 대해서
웹컨텐트에 대한 보안과 함께 액세스가 빈번한 대용량 사이트라면 기본설정으로는 무리가 따르게 되므로 적절한 튜닝이 더욱 필요하다. 이런 튜닝 기술은 단순한 직감으로 수행될 수 없으므로 원리와 효과를 예측할 수 있도록 지식을 쌓는 것이 중요하다. 하지만 사용하는 시스템 환경에 따라 경우가 천차만별이므로 절대적인 기준을 제시하기는 어렵다. 그러므로 웹서버 트래픽 분석 및 적절한 벤치마킹을 통해 전문가들이 가이드라인을 제시하는 것이 일반적이다. (이 튜닝 포인트 가이드는 IIS 4.0을 기준으로 함). 다시 강조하지만 이러한 가이드조차 절대적인 것이 없으므로 웹관리자 스스로 서버 벤치마크 도구와 트래픽 분석을 통해 본인의 사이트에 맞는 기준을 설립하는 것이 중요하다.

1. 전체적인 튜닝 포인트
NT 서버는 그 사용도에 따라 서버를 최적화할 수 있도록 '사용 메모리 최소화', '균형 유지', '파일 공유 처리량 최대화', '네트워크 응용 프로그램 처리량 최대화' 등 4개의 서버 옵션을 제공한다.
NT 도움말을 보면 네트워크에 연결에 할당된 메모리와 사용자 컴퓨터에서 실행중인 응용 프로그램에 할당된 메모리 사이의 관계를 바로 이 옵션을 통해 조정할 수 있다고 돼 있다. 그러나 독자들의 관심사는 웹서버인 IIS 4.0일 것이므로 서버 최적화 옵션을 '네트워크 응용 프로그램 처리량 최대화'로 설정해 IIS 서버가 보다 많은 메모리를 사용하도록 하면 성능을 높일 수 있다.

IIS 서버는 파일 서버에 비해 페이지 오류(page fault)가 더 많이 발생하므로 파일 캐시 기능을 강화하기 위해 서버 옵션을 위와 같이 설정해야 한다고 되어 있다. 페이지 오류란 가상 메모리와 관련된 기술용어로 응용 프로그램에서 사용하는 가상 메모리 중 물리적인 메모리에 적재돼 있지 않은 곳을 프로그램에서 읽으려고 할 때 발생하는 시스템 이벤트다. 일단 페이지 오류가 발생하면 운영체제는 응용 프로그램에서 하던 일을 전부 멈추고 이 문제를
해결하기 위해 디스크로 스왑핑돼 있던 가상 메모리 영역 중 프로그램에서 요구한 부분을 물리적인 메모리로 읽어 오는 작업을 하게 된다. 그런데 문제는 디스크 읽기/쓰기 작업이 메모리 읽기/쓰기 작업에 비해 엄청나게 시간이 오래 걸린다는 점이다. 따라서 페이지 오류가 많이 발생하는 응용 프로그램에서 사용하는 가상공간은 가능한 물리적인 메모리 안에 두는 것이 성능을 극대화시킬 수 있는 것이다. 이것 서버 최적화 옵션을 선택하는 원인과 예
상할 수 있는 효과이다.

초창기 웹서버인 NCSA부터 시작해 거의 모든 웹서버는 '로깅(logging)' 기능을 가지고 있다. 로그에는 웹컨텐트 사용자에 대한 각종 정보가 담겨져 있어 문제점을 파악하고 사용자의 취향에 대한 판단을 할 수 있는 중요한 근거가 된다. 그러나 수백명이 웹서버를 이용하고 있는 상황에서 웹서버는 사용자가 원하는 파일을 개별적으로 가져다주기도 힘겨운데, 요구한 각 파일마다 로그기록을 남기도록 한다면 웹서버가 스트라이크(?)를 일으키는 상황이 종종 발생하게 된다. 이에 대해 튜닝 가이드는 사용자 경향을 어느 정도 파악한 사이트라든지, 성능이 무척 중요한 사이트라면 IIS 로깅 기능을 끄도록 권하고 있다. 로그를 반드시 봐야 한다면 일부 파일에 대한 로깅만 수행하는 '부분로깅'을 동작시키던지, 아니면 로그를 기록하는 디스크에 대한 부담을 줄이기 위해 스트라이프 파티션에 로그 파일을 두면 서버 성능 저하를 피할 수 있다.

2. 네트워크 튜닝 포인트
웹서버의 기반 프로토콜인 HTTP, FTP는 TCP/IP 위에서 동작하기 때문에 TCP/IP 설정 방법에 따라 성능차가 크게 나게 된다. 일반적인 응용 프로그램 서버로 NT 서버를 사용할 때에는 굳이 TCP/IP 설정을 바꿀 필요가 없지만, 사이트 규모가 큰 경우에는 보다 효율적인 운영을 위해 손질할 필요가 있다.
여기서는 NIC 파라미터와 TCP 파라미터에 대한 튜닝에 대한 포인트를 설명하기로 하고, 참고로 HTTP도 1.1 스펙을 보면 성능 향상을 위해 몇 가지 추가된 기능이 들어 있다. 이 기능은 클라이언트와 서버 모두에서 HTTP 1.1 스펙을 지원해야 하기 때문에 한계가 있지만 TCP/IP 상위 프로토콜에서도 튜닝할 부분이 있다는 점만은 알아두는 것이 좋다(보다 자세한 내용은 옵션팩 온라인 도큐먼트 중 IIS 서버 관리, 성능 튜닝 부분을 참조).
TCP/IP 프로토콜에서는 슬라이드 윈도우 기법을 사용해 흐름 제어(flow control)를 수행한다. 흐름 제어란 물리적인 네트워크에 통신 패킷들이 어느 한 곳에서 막히지 않고 원활히 지나다닐 수 있도록 제어하는 기법을 말한다. 여러 가지 흐름제어 방법 중 TCP/IP는 특정 윈도우 크기만큼 데이터 패킷들을 보내고 ACK를 받는 방식으로 흐름을 제어한다. 따라서 빠른 네트워크를 사용할 때는 윈도우 버퍼 크기를 크게 잡으면 잡을수록 보다 많은 데이터를
한꺼번에 전송할 수 있으므로 성능이 높아진다. 하지만 느린 네트워크에서는 오히려 문제가 발생할 소지가 있으므로 이 방법이 항상 좋은 것은 아니다. 이 값은 레지스트리 편집기인 regedt32.exe를 사용해 HKEY_LOCAL_MACHINE\CurrentControlSet\TCPIP 파라미터를 찾아보면 알 수 있는데, TcpWindowSize이다. 튜닝 가이드에 의하면 약 0x4470 정도로 값을 설
정하면 된다.
또다른 TCP/IP 파라미터로 'MaxUserPort'라는 것이 있다. 이 파라미터는 웹클라이언트에서 웹서버에 접속할 때 사용하는 사용자 포트의 최대 개수를 지정하는 키값을 의미하기 때문에 많은 사용자들이 서비스를 받고자 할 때 사용자 포트의 부족으로 패킷이 드롭(drop)돼 재전송되는 현상을 줄이고자 크게 잡는다. 튜닝 가이드에 의하면 0xfffe 정도로 설정하라고 되어있다.

3. 멀티 CPU 튜닝 포인트
여러 개의 CPU가 있는 시스템은 보다 빠르게 처리하도록 작업을 여러 CPU에 배분시킨다. 이렇게 배분된 작업은 쓰레드란 단위로 각 프로세서에서 실행된다. 쓰레드란 프로세서보다 가벼운 실행 단위로 순차적으로 실행되는 쓰레드(thread)를 의미한다. 요즘 출시되는 대부분의 서버는 다중쓰레드 구조를 가지고 있어, 동시에 여러 작업을 서버 내에서 처리하도록 되어 있다. IIS 4.0도 다중쓰레드를 사용해 웹클라이언트에서 요청한 작업을 여러 CPU에 분산시켜 처리 성능을 높인다. 그런데 만약 웹클라이언트에서 특정 파일을 요구하
고 난 후 IIS 서버가 그 작업용으로 쓰레드를 할당하려고 하는데 사용할 수 있는 쓰레드가 없는 경우가 발생한다면? 요구 자체를 지연(block)시킬 수밖에 없고, 사용 가능한 쓰레드가 생길 때까지 멈추게 된다. 결국 사용할 수 있는 쓰레드수의 부족으로 웹서버 성능이 저하될 수 있다는 얘기다.
현재 얼마나 많은 쓰레드가 실행중인가를 확인하려면 윈도우 NT 성능 모니터를 실행시킨 후 'System' 개체에서 'Processor Queue Length' 카운터를 차트에 추가하면 현재 시스템의 프로세서 큐 길이를 지켜볼 수 있다. 이 값은 현재 실행중인 쓰레드를 표시하지 않기 때문에 보통 상황에서는 1의 값을 가진다. 이 값은 프로세서가 N개일 때, N에서 3×N 정도로 설정하면 좋다. 이 값이 의미하는 바나 적절한 값을 잘 모르겠으면 건드리지 말고 디폴트로 놓도록 하되, IIS에서 사용하는 쓰레드수를 늘려주고 컨텍스트 스위치 횟수를 줄
이는 방향으로 튜닝해야 한다. 예를 들면, IIS 로드가 일정한 정적 환경에서는 MaxPoolThreads는 1로, PoolThreadLimit를 N으로 설정하도록 권장하고 있다. 이렇게 구성하면 프로세서 당 1개씩 쓰레드를 배치시켜 컨텍스트 스위치 횟수를 줄이는 동시에 IIS에서 사용할 수 있는 쓰레드의 개수를 늘려주므로 좀더 나은 성능을 얻을 수 있다.

4. 정적 환경에서의 튜닝 포인트
IIS 4.0에서는 객체 캐시 기능을 제공해 객체에 대한 사용이 끝나도 일정한 시간 동안 메모리에 가지고 있다가 다시 사용할 때 디스크에서 읽어올 필요 없이 곧바로 캐시 안에 있는 객체를 사용한다. 객체가 캐시 내에서 유지되는 시간을 TTL(Time To Live)라고 하며, 디폴트 값은 30초로 되어 있다. 만약 웹사이트 내용이 메모리에 적재될 정도이고 자주 바뀌는 것이 아니라면, 아에 TTL을 0xffffffff로 설정해 객체가 항상 캐시 안에 있도록 할 수도 있지
만, 대다수의 경우에는 메모리 안에 웹컨텐트가 모두 적재되지 않기 때문에 TTL값을 적절히 조절해야 할 필요가 있다.
아주 자주 사용되는 파일이 있다면, 이 TTL값을 크게 설정해 성능 향상을 꾀할 수도 있다. 반면 자주 요청되는 파일들이 많은 경우에는 TTL값을 크게 해도 성능 증대를 기대할 수 없고, TLL 값을 낮춰 캐시 안에 있는 객체수를 줄임으로써 시스템 자원이 고갈되는 것을 막을 수 있다. 캐시 안에 유지되는 파일수는 다음에 설명될 OpenFileInCache값을 조절하면 조정이 가능하다.
TTL 값은 레지스트리키인
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters안에 있는 ObjectCacheTTL값으로 설정된다.

IIS는 또한 캐쉬 안에 유지되는 파일 핸들의 수를 지정할 수 있도록 OpenFileInCache라는 레지스트리값을 제공한다. 이 값은 한번 열려진 파일에 대한 핸들을 몇 개나 저장하겠느냐를 의미하는 것으로 IIS 캐시용으로 할당할 수 있는 메모리양과 캐시 내에 저장하길 원하는 파일 핸들의 수에 따라 달라진다. 일반적으로 큰 웹사이트에서는 보다 많은 파일핸들을 캐싱시켜 성능을 높일 수 있으며, 일정한 파일만을 가진 웹사이트의 경우에는 그 파일
수보다 큰 값으로 OpenFileInCache값을 설정해 모든 파일들을 디스크 입출력 없이 메모리에서 파일을 읽어옴으로써 성능을 극대화할 수도 있다. 이 값을 적절히 선택하기 위해서는 NT성능 모니터를 사용해 'Internet Information Server Gobal' 개체 중 'Cached File Handles' 카운트값을 모니터링함으로써, 메모리 낭비없이 어느 정도면 많이 사용하는 파일 핸들을 캐시 내에 저장할 수 있을지를 예상할 수 있을 것이다.

5. 액티브 서버 페이지 튜닝 포인트
IIS 4.0은 MTS 2.0과 통합돼 각종 ASP 스크립트나 COM 컴포넌트들에 대해 트랜잭션 성격을 부과할 수 있게 됐다. IIS는 MTS의 실행을 위해 CPU당 일정한 수의 쓰레드를 할당해 놓는다. 이 값은 레지스트리 키 중 HKEY_LOCAL_MACHINE\System\CurrentControlSet\ServicesW3SVC\ASP\Parameters안에 있는 ProcessorThreadMax값으로 설정할 수 있다. 잘 만들어진 ASP의 경우라면 이 값이 적을수록 경쟁 감소 효과가 일어나므로 이 값을 줄여보고 성능을 모니터링한 뒤, 만약 성능이 떨어지면 원상태로 복귀하는 방식으로 튜닝하면 된다.
ProcessorThreadMax와 연계된 튜닝 포인트로 AspScriptEngineCacheMax라는 값이 있다. 이 값은 대개 ProcessorThreadMax값에 시스템에서 제공하는 프로세서의 수를 곱한 값으로 설정한다. 이렇게 설정함으로써 각 ASP 쓰레드가 좀더 효과적으로 ASP 페이지들을 처리하도록 스크립트 엔진들을 하나씩 캐시하게 된다.
또한 ASP 응용 프로그램들에서 클라이언트로 출력되는 모든 내용을 버퍼링한 후 마지막에 한꺼번에 출력시킴으로써 성능을 높일 수도 있다. 이 기능은 MS 관리 콘솔에서 인터넷 인포메이션 서버 스냅인(snap-in)을 선택하고, 특성을 선택한 후 'Home/Virtual Directory' 특성 페이지를 열고, 'Configuration' 버튼을 누르고, 'App Options'에서 'Enable Buffering'을 클릭하면 된다.
ASP 안에서 세션을 유지하기 위해 '세션객체(session object)'를 사용하는데, 이 객체를 계속해서 유지하려면 시스템 자원을 점유하게 된다. 만약 1000명의 사용자가 동시에 연결된다면, 각 사용자당 세션 상태를 유지시키기 위해 굉장히 많은 양의 시스템 자원을 점유해야 한다. 세션을 유지하는 한 시스템 자원을 점유해야 하므로 세션 타임 아웃값을 적절히 설정한다면, 서버 자원 사용을 최적화할 수 있을 뿐만 아니라 성능 또한 증대시킬 수 있다.
웹 응용프로그램은 또한 In-process와 Out-of-process를 지원하는데 성능면에서는 In-process를 사용하는 것이 바람직하다. Out-of-process는 주로 개발 기간에 웹 응용프로그램에 Bug가 내제 되어 있는 시점에 전체 IIS 서버에 영향을 안 끼치기 위한 방법으로 사용된다.


성공적인 NT 웹서버 관리를 위해
NT 서버의 성능 및 보안체계 튜닝 작업은 가상 시뮬레인션인 벤치마킹과 실제 데이터인 로그 데이터, 성능 데이터를 기반으로 하고 있으므로 실제 튜닝 작업에 들어가기 전에 관련 도구 및 데이터 분석 능력도 함께 키워야 제한된 능력만을 가진 서버 관리자에서 벗어나 고급 관리자로 탈바꿈할 수 있을 것이다.
저작권 (주)마이크로소프트
http://www.microsoft.com/korea/support/kb/K000987.htm


추가적인 자료입니다
1.IIS 4.0 Tuning Parameters for High-Volume Sites (March 9, 1998)
http://msdn.microsoft.com/workshop/server/feature/tune.asp

2.Server Performance and Scalability Killers(February 22, 1999)
http://msdn.microsoft.com/workshop/server/iis/tencom.asp




[Win2000] Windows 2000 과 IIS 관리자들을 위한 점검사항 리스트

1.OS System 측면
International English 버전으로 설치
Windows OS 의 HotFix(Patch 또는 Update)가 1주일에 거의 1번 꼴로 발생한다.
그러나, 대부분이 영어버전용이고 다국어 버전에서는 어떻다는 말이 없다. 특수한 경우에는 다국어 버전의 파일을 별도로 제공하고는 있지만 나머지는 다국어 버전에서 그냥 사용해도되는지 알 수 없다. 사용하다 문제가 발생하면 누구의 책임이겠는가? 모든 것이 관리자의 책임이다.
따라서, 이런 고민을 하지 않으려면 영어버전(국내에서 판매되는 International English)버전을 사용하기 바란다.

버전관리
Boot Script 를 활용하여 서비스팩과 핫픽스을 업데이트

계정 관리
- 계정별 권한관리.
Perms.exe : 사용자별 파일/디렉토리 액세스권한을 확인할 수 있다.

계정암호 관리
- 최소길이 7자 추천(최대 127자)
- 특정 단어사용하지 말것(사전에 나오는 문자사용불가)
- 영문자(대소문자 혼용)+숫자+기호(!$%& 등의 특수 문자)
- 원격 암호변경 불가능하도록 설정 : 해커가 관리자의 암호를 마음대로 수정하는 것을 방지한다.
- 암호사용기간 및 암호기록 횟수 지정 : 일반적으로 사용자들은 한 번 정한 암호를 바꾸지 않는다. 이 것을 방지한다.

Storage 관리
- NTFS 파티션 : 적어도 Web 관련된 부분만큼은 NTFS 로 지정되어 있어야 한다.

로그관리 - 이벤트 표시기를 통한 보안/시스템/응용프로그램 로그를 항상 주시하여 언제 발생할지 모르는 사고와 사태에 대비하여야 한다. 노란색으로 표시되는 경고메시지는 잠재된 에러를 뜻하므로 경계를 게을리하면 안된다.

로그온감사 : 사용자 로그온 기록을 남기자
- ID 사용을 감시할 수 있으므로 불법 ID 확인이 가능하다.

보안관리 : Microsoft 보안 알림서비스 메일링리스트 가입
- 제목, 내용없이 메일을 보내면 가입을 확인하는 메일이 오는데, 이 메일에 회신하면 가입축하메일이 온다.



2.네트워크 측면
Ping 받지않기(ICMP 패킷 차단하기)
Windows 2000 의 경우, IPSec 을 사용하여 ICMP 패킷을 차단할 수 있다.

Web 서비스 전용기기로 설치하기
웹 서버를 파일서버등과 분리하는 것은 보안적 측면이나 속도를 고려해서 추천할 만한 방법일 것이다.

네트워크에서 분리하기
웹 서비스 기기는 다른 업무용 기기와 분리되는 것이 좋으나, 하나의 기기로 여러 개의 작업을 하는 경우라면 서버측에 랜카드를 두개 설정하고 IP 주소를 분리하는 방법도 고려해 볼만하다.

Qos 를 이용한 대역폭관리

방화벽이용
방화벽을 이용할 경우, Windows 의 서비스들은 각각의 port 를 사용한다.
\\…\system32\drivers\etc\service.txt 를 참조한다.


3.DNS 측면
외부에서 nslookup 으로 DNS 정보를 볼 수 없게 설정한다.
DNS서버의 웹사이트의 등록정보에 보면 “영역 전송” 탭에서 체크박스를 체크해주고 아래에 영역을 전송할 서버를 입력하여 주면 됩니다.
이 것을 "아무서버로" 라 설정하면 말 그대로 영영정보를 요청하는 모든 곳에 영역을 전송하게 됩니다. 즉, 이를 막는 방법을 사용하려면 특정서버(연결된 ISP 의 DNS 서버 권장)로의 연결만을 허락하는 것이 좋습니다.


4.IIS 측면
버전관리
- HFCheck : HotFix 적용확인 도구

보안관리
- IISCONFIG :
- IISLock : IIS 5.0 설정을 쉽게 해준다.
- What If : IIS 보안 확인도구(시나리오를 이용한 보안성 확인)
- 보안체크리스트(원문)

응용프로그램보안
- IIS 응용프로그램레벨의 보안방화벽 Secure IIS 추천

IIS 무응답상태 : ASP Queue 관리
- set objVar = nothing
- IIS 서비스가 무응답으로 빠지는 문제는 대부분 ASP에서 Object 변수를 Nothing 처리를 하지 않았기 때문입니다.
- 퍼포먼스관리자의 ASP Requested Queue 의 수가 0 이어야 한다. ASP 가 하나씩 실행될 때마다 1 씩 증가하며, 종료되면 1 씩 감소한다. 따라서 정상적인 ASP 코드의 경우에는 늘어난 만큼 감소하여 나중에는 0이 되어야한다.

webroot 보안 십계명

unicode 문제
- 디렉토리/파일의 이름에 유니코드등 2 바이트문자를 사용하지 않는다.(영문만 사용한다)
- 가급적 실행권한을 주지 않는다.
- 필요한 경우가 아니라면, IIS 설치시 기본적으로 설치되는 IISAdmin, IISSample 등의 디렉토리를 지운다.

웹용량 분석
- MS Web Capacity Analysis Tool

웹캐쉬제어

ASP 성능향상
- Tip 1
- Tip 2


5.사이트관리측면
- 관리자와 서버간 통신은 VPN / SSL 등으로 보호하자.
- Terminal Service 보안


6. 참고 list 및 문헌
윈도우 NT서버 및 IIS 보안 관리
- http://www.ntfaq.co.kr
- http://www.ntsecurity.com
- http://www.ntsecurity.net
- http://www.microsoft.com/security
- http://www.microsoft.com/technet/security
- 공짜로 경험하는 강력한 네트워크관리



[Win2000] IIS 5.0 실행에 필요한 최소 NTFS 권한
이 문서에서는 IIS 5.0 웹 사이트에 필요한 최소 NTFS 액세스 권한에 대해 설명합니다. IIS를 설치할 때 이미 기본 웹 사이트와 기본 FTP 사이트에 대해 적절한 NTFS 액세스 권한을 갖고 있어야 합니다. 올바른 NTFS 권한이 필요한 폴더가 많이 있습니다. 이러한 폴더 중 하나의 설정이 틀리면 다음 중 하나 이상의 오류가 발생할 수 있습니다.

웹 브라우저의 오류:

You are not authorized to view this page
You do not have permission to view this directory or page using the credentials you supplied.

HTTP 401.3 - Access denied by ACL on resource
Internet Information Services

-또는-

웹 브라우저의 오류:

Server Application Error
The server has encountered an error while loading an application during the processing of your request. Please refer to the event log for more detailed information. Please contact the server administrator for assistance.

시스템 로그의 오류 설명:

Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 36
Date: 3/5/2001
Time: 9:59:40 AM
User: N/A
Computer: MACHINE-NAME
Description:
The server failed to load application '/LM/W3SVC/5/Root'. The error was 'General access denied error'.
For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10001
Date: 3/5/2001
Time: 9:59:40 AM
User: NT AUTHORITY\SYSTEM
Computer: MACHINE-NAME
Description:
Unable to start a DCOM Server: {99169CB1-A707-11D0-989D-00C04FD919C1} as ./IWAM_MACHINE-NAME. The error: "Access is denied. " Happened while starting this command: C:\WINNT\System32\dllhost.exe /Processid:{3D14228D-FBE1-11D0-995D-00C04FD919C1}

-또는-

웹 브라우저의 오류:

Error: Access is Denied.

시스템 로그의 오류 설명:

Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 30
Date: 3/5/2001
Time: 10:01:13 AM
User: N/A
Computer: MACHINE-NAME
Description:
The server was unable to read the file C:\WINNT\help\iisHelp\common\401-3.htm. The file does not exist. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.

원인
NTFS 권한이 기본 설정에서 변경되어 IIS 5.0 실행 권한으로는 충분하지 않습니다.

해결 방법
참고: 본 문서에서 설명하는 단계를 수행하면 IIS 5.0 컴퓨터에서 관리자만 소프트웨어를 설치하거나 실행할 수 있도록 권한이 제한됩니다. 이 문서에서 지정한대로 권한을 재설정한 후에는 인터넷 서비스 관리자를 통해 각 웹 사이트에 대해 Server Extensions 확인 작업을 수행해야 합니다. FrontPage 클라이언트가 HTTP 프로토콜을 사용하여 연결될 수 있으려면 이 단계가 필요합니다.

Windows 탐색기를 사용하여 다음과 같이 하십시오.

전체 하드 드라이브를 다음과 같이 설정합니다.


SYSTEM - 모든 권한
ADMINISTRATORS - 모든 권한


이렇게 설정하려면 고급을 누르고 모든 자식 개체의 사용 권한 재설정 및 상속 가능한 사용 권한 전파 허용을 선택합니다.

참고: Pagefile.sys 파일에 사용 권한을 적용하려고 하면 오류 메시지가 나타납니다. 이 오류 메시지와 유사한 모든 오류 메시지에 대해 계속을 누르십시오.


Program Files\Common Files의 경우 Everyone을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Inetpub\Wwwroot의 경우 IUSR_MACHINE을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Winnt\System32 폴더에서 Inetsrv 폴더와 Certsrv 폴더를 제외하고 모든 폴더를 선택합니다.

이러한 폴더의 등록 정보 시트를 열고 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음을 선택 취소합니다. 나타나는 대화 상자에서 복사를 누릅니다. 확인을 눌러 등록 정보 시트를 종료합니다.


Winnt 폴더에서 Downloaded Program Files, Help, IIS Temporary Compressed Files, Offline Web Pages, System32, Tasks, Temp 및 Web 폴더를 제외하고 모든 폴더를 선택합니다.

이러한 폴더의 등록 정보 시트를 열고 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음을 선택 취소합니다. 나타나는 대화 상자에서 복사를 누릅니다. 확인을 눌러 등록 정보 시트를 종료합니다.


Winnt의 경우 Everyone을 추가하고 읽기 및 실행, 폴더 내용 보기 및 읽기를 선택합니다.

참고: 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음 확인란을 선택 취소하지 마십시오.


Winnt\Temp(ASP 페이지에서 Access 데이터베이스를 볼 수 있게 해줌)의 경우 Everyone 그룹(이 그룹은 Winnt 폴더에서 상속하여 이미 존재해야 함)을 선택하고 수정을 선택합니다.


추가 정보
각 시스템 관리자의 필요에 맞게 사용 권한을 특수화할 수도 있지만 IUSR_MACHINE 계정 대신 Everyone 그룹을 사용하는 것이 좋습니다.

Everyone 그룹은 사용자 그룹, IUSR_MACHINE 계정 및 IWAM_MACHINE 계정을 포함합니다.

IIS 5.0에서는 웹 페이지를 실행하는 데 별도의 두 가지 계정을 사용합니다. 익명 인증을 사용할 경우 IIS는 IUSR_MACHINE 계정을 사용하여 해당 페이지를 봅니다. 그러나, Dllhost.exe라는 별도의 프로세스를 시작할 때는 IWAM_MACHINE을 사용합니다. 모든 ASP(Active Server Page), 구성 요소 개체 모델(COM) 구성 요소 또는 기타 ISAPI 확장(ASP는 ISAPI 확장으로 간주됨)이 Dllhost.exe 프로세스 내부에서 실행됩니다. 이것은 주로 안정성을 위한 것입니다. ASP 페이지에서 호출된 사용자 지정 COM 구성 요소가 동작하지 않아도 즉, 액세스 위반으로 인해 프로세스가 중단되어도 Inetinfo.exe가 영향을 받지 않아 웹 서비스가 계속 실행됩니다.

IIS 4.0의 두 가지 보호 수준은 아래와 같습니다.

기본설정: IIS 4.0이 프로세스 내 즉, SYSTEM 계정에 의해 시작되는 Inetinfo.exe 프로세스 내부에서 모든 응용 프로그램을 시작합니다. 웹 페이지가 나타나면 해당 페이지를 서비스하는 특정 스레드가 IUSR_MACHINE 계정의 컨텍스트에서 실행됩니다. HTM, ASP 및 그 밖의 다른 ISAPI 확장이 Inetinfo.exe 내부에서 실행됩니다.


구분 메모리 공간에서 실행(격리된 프로세스): 이를 out-of-process라고도 합니다. IWAM_MACHINE 계정을 사용하여 ASP와 그 밖의 다른 ISAPI 확장을 실행하는 별도의 Mtx.exe 프로세스를 만듭니다.


IIS 5.0의 세 가지 보호 수준은 아래와 같습니다.

낮음(IIS 프로세스): 이 설정은 IIS 4.0의 기본 설정과 유사합니다. 모든 웹 페이지가 HTM인지 아니면 ASP인지에 관계 없이 Inetinfo.exe 프로세스 내부에서 실행됩니다.


보통(풀링됨): 이것이 기본값입니다. IIS 4.0에서처럼 이 설정은 모든 ASP 및 COM 구성 요소가 실행되는 Dllhost.exe라는 별도의 프로세스를 시작합니다. 이 프로세스는 IIS 4.0에서처럼 IWAM_MACHINE 계정에 의해 시작됩니다. 또한, 이 설정은 IIS에서 실행하는 모든 웹 사이트가 ASP 페이지를 실행하는 데 이 단일 Dllhost.exe를 공유하므로 풀링됨이라고도 합니다. Windows 2000에서는 Mtx.exe가 Dllhost.exe로 대체됩니다.


높음(격리됨): 이 설정은 각 웹 사이트나 응용 프로그램에 대해 전용 Dllhost.exe 프로세스를 시작합니다. 5개의 웹 사이트가 있고 각각 높은 수준의 보호로 설정되어 있으면 총 6개의 Dllhost.exe 프로세스 즉, 5개의 Dllhost.exe 프로세스 외에 시스템 응용 프로그램 아래에서 COM+가 시작하는 추가 Dllhost.exe 프로세스 하나가 더 시작됩니다.


참조
Windows 2000의 기본 NTFS 권한을 복원하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com/support/kb/articles/Q266/1/18.ASP

Q266118 How to Restore the Default NTFS Permissions for Windows 2000

추가 검색어: iis 5 NTFS permission


[Win2000] IIS 웹 인증을 구성하는 방법
http://support.microsoft.com/kb/308160/ko


IIS에서 ASP에러 보이게 하기
웹사이트 등록정보를 보시면 사용자 정의 오류 탭이 있습니다 ..
그중에서 500-100을 편집누르시고 url로 고치신다음 url로는 /iishelp/common/500-100.asp
를 써주시고 ...다음 그 웹사이트에서 가상 디렉토리명을 iishelp로 잡으시면 됩니다.
가상 디렉토리를 만드실때 존재하는 디렉토리는 os가 설치된 드라이브의 winnt\help\iishelp 가 됩니다.
그러시면 원하시는 asp 오류메세지를 보실수 있습니다.


IIS 사용자 정의 HTTP 헤더
사용자 정의 헤더 이름 P3P
값 CP='CAO PSA CONi OTR OUR DEM ONL'
쿠키 설정하는 부분을 자동적으로 처리


[IIS] SMTP Error 0x8009000f - Object already exists
* Support.Microsoft.com
http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;q294274

* iisFAQ
http://www.iisfaq.com/default.aspx?View=R288&P=154

* Google.co.kr
http://www.google.co.kr/search?hl=ko&ie=UTF-8&oe=UTF-8&newwindow=1&q=0x8009000F&lr=

* Solve this Problem
1. Read MSKB
2. ReInstall SMTP
3. Had the same problem trying to install IIS. MS's solution did not work

### so deleted files in MachineKeys folder & was successful. ###

Windows 와 .NET 관련 IIS 세팅

UNable to create web project
One suggestion is to add the .tmp extension to the MIMEMap entries in IIS (open
IIS MMC Snapin, right click on local computer node, select Properties, MIMEMap,
and add the .tmp extension. Restart IIS so that this global change is taken
[important]).

Add this MIME type to your vdir, found this elsewhere on the boards:

Extension: .tmp
MIME type: application/x-temporary

That should allow you to open Web Projects using the File Share option, yes,
it IS ridiculous.


동시 접속자수가 많을 때, IIS의 급격한 성능 저하 또는 서버 장애 현상
http://support.microsoft.com/default.aspx?scid=kb;ko;601401

2009/06/18 13:37 2009/06/18 13:37
날이 갈수록 웹 관련 기술은 발전하고 있지만, 이러한 기술의 발전에 비례하여, 웹 관련 사용자들의 새로운 불편함이 나타나고 있다. 최근 이에 대한 조사를 통하여 나타난 웹 사용자들이 현재 웹에 대하여 가장 불편함을 느끼는 10가지 요소를 다음과 같이 제시하고자 한다.

첫째, 의심스러운 프라이버시 관련 정책
69퍼센트의 사용자들이 긍정적으로 답변하고 있는데, 특히 비즈니스 관련 사이트, 이 중에서도 건강이나 재무관련 서비스 사이트에서 사용자들로부터 민감한 정보들을 수집하고자 하는 성향에서 나타나고 있는 것으로 알려지고 있다. 이러한 첫 번째 내용은 최근 기사의 내용[GTB2007100662]과도 부합하는 요소이다.

둘째, 난해한 온라인 형식
새로운 사이트에 등록하거나, 웹 상에 정보를 제공하고자 할 때, 사용자들은 익숙하지 못한 인터페이스나 너무 많은 정보를 한꺼번에 요청하는 방식에 대하여 65퍼센트의 사용자들이 거부감을 느끼고 있는 것으로 조사되었다. 웹사이트 개발자들은 이러한 사용자들의 거부감을 최소화시키기 위하여 중요한 정보와 그렇지 않은 정보를 하이라이트시키는 방식을 통하여 차별화시킬 필요가 있다.

세 번째, 웹의 지나친 상업화
웹 사이트에 들어가보면, 사용자의 정상적인 웹 내비게이션을 방해하는 흐름들이 지나치게 많이 관찰된다. 예를 들자면, 팝업창, 시끄러운 플래시 광고파일, 배너광고, 사용자의 특정 행동 없이도 자동으로 작동되는 비디오 광고들, 대개 푸쉬 광고의 형태로 사용자에게 제공되고 있는 이러한 파일들은 상업화된 주요 요소로서 사용자들 중 62퍼센트가 거부감을 느낀다고 조사되었다. 야후나 마이스페이스 같은 유명사이트도 마찬가지로, 이럴 경우 수익모델의 확보를 위한 상업화 노력도 좋지만, 구글과 같은 단순한 인터페이스가 사용자들에게 더 크게 어필할 수 있다는 사실에 주목할 필요가 있다.

네 번째, 표준화에 대한 필요성
현재 사용자들이 주로 사용하고 있는 웹브라우저인 인터넷 익스플로러의 경우, 웹 페이지를 제작하기 위하여 사용되는 핵심 포맷에 대한 지원이 부족하다는 것이 가장 큰 단점 중의 하나이다. 많은 웹디자이너들은 표준화에 부합하지 못하는 페이지를 제작하고 있고 단지 이러한 IE에만 익숙한 사이트를 만들고 있는 것이다. 새로운 웹 2.0 스타일의 사이트가 많아질수록 이러한 흐름에 역행하는 새로운 시도가 필요할 것이고, Firefox.com의 성공에 주목할 필요가 있는 것이다.

다섯 번째, 지나친 커뮤니티와 상호작용들
약 58퍼센트의 사용자들이 웹 2.0으로 진화되고 있는 현 웹 플랫폼에 대하여, 지나친 다른 사람들과의 상호작용, 자신이 업로드한 콘텐츠 하나하나에 대한 사용자들의 댓글들이 오히려 부담스럽다고 응답하고 있다.

여섯 번째, 이벤트 티켓 구입하기
약 54퍼센트의 사용자들이 불편함을 나타내고 있는데, Ticketmaster와 같은 사이트에서 사용자의 편의성을 어떻게 증진시키고 있는지 주목할 필요가 있다. 사용자들은 티켓 구입사이트에서의 잦은 매진, 표가 연기되는 상황, 금융사이트와의 복잡한 링크로 인하여 불편함을 호소하고 있다.

일곱 번째, 웹 2.0이 과연 무슨 도움이 되고 있는가?
웹 2.0 기술이 사용자들에게 새로운 체험과 경험을 제공하여 웹에서의 상호작용을 증진시키고 있는 부분에 대하여는 모두 공감하지만, 이러한 경험이 궁극적으로 사용자 가치향상에 무슨 도움이 되고 있는지 사용자들은 의구심을 품고 있다. 커뮤니티 지향적인 웹사이트에 대하여 사용자들이 매력을 갖게 하기 위해서는 사용자들을 유인하기 위한 동기들이 무엇이 되어야 할지에 대한 고찰이 필요하다.

여덟 번째, 전자책에 대한 비용
웹 상에서 구매할 수 있는 전자책은 출판비용이나 유통비용이 거의 들지 않는데도 불구하고, 사용자들이 실제 지불하는 비용은 기존의 오프라인 책에 비하여 크게 차이가 나지 않는 부분에 대하여 사용자들이 의구심을 품고 있다.

아홉 번째, 실망스러운 웹 비디오
UCC 동영상의 활성화로 인하여 다양한 동영상 콘텐츠가 웹 상에 나타나고 있는데, 사용자 제작의 개념은 훌륭하나, 과연 효율적인 동영상이 얼마나 되느냐에 사용자들이 그저 그런 동영상 콘텐츠에 대하여 흥미를 잃어가고 있다.

열 번째, 지루한 가상세계
세컨드 라이프와 같은 가상세계가 나타나고 있지만, 이러한 사이트를 이용하지 않는 비사용자들의 반응은 자신들이 생각하고 있는 가상세계에 대한 반응과 이러한 사이트에서 알 수 있는 가상세계에 대한 반응과 일치하지 않고 있다는 데에 대하여 의구심을 제시하고 있는 것에 주목할 필요가 있다.

위에서 나타난 10가지 불편 요소를 살펴보자면, 신기술 자체가 중요한 것이 아니라, 사용자의 요구에 기반한 사용자들의 가치를 정확히 꿰뚫을 수 있는 것이 무엇인지 접근하는 것이 가장 필요한 것으로 파악할 수 있다. 바야흐로 푸쉬 기반의 기술전략이 아니라 풀 기반의 기술전략을 어떻게 추진할 것인가? 그리고 그 중심에 사용자, 다시 그 중심에 가치란 부분이 어떻게 연결될 것인지가 필요한 것이다.

우리도 사용자 관점에서 조금 더 접근을 해야 할 듯 하다. 우리 업무에 있어 가장 중요한 것을 놓치고 있지는 않나 다시 한번 생각을 해볼 때가 아닌가 생각 된다.

KISTI 에 나온 이야기였습니다~~
2008/11/21 15:31 2008/11/21 15:31
개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다.

솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다.

K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다.

“회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?”

필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다.

개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇기 때문에 개발을 할 수 있는 것이다.

개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다.

어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다.

반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.”

혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다.

그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다.

개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다.

패배하지 않기 위해 이것만은 기억하자

사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다.

1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다.
자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다.

하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다.

2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다.
자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다.

3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다.
이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다.

그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면?

사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다.

한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다.

전문가를 필요로 하지 않는 사회, 자기계발이 살길
궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다.

성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다.

개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다.

그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다.

이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다.

출처 : http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39166851,00.htm


본인도 개발자로써 이글을 읽으며, 조금은 씁슬 하지만 현실이 이렇다는건 공감을 하는바 몸에 베이도록 노력을 해야 겠다..^^;;
2008/11/21 15:30 2008/11/21 15:30

<html>
<head>
<style type="text/css">
<!--
#sponsorAdDiv {position:absolute; height:1; width:1; top:0; left:0;}
-->
</style>
<SCRIPT LANGUAGE="JavaScript1.2">

adTime=180;  // 보여줄 초 입력
chanceAd=1; // ad will be shown 1 in X times (put 1 for everytime)

var ns=(document.layers);
var ie=(document.all);
var w3=(document.getElementById && !ie);
adCount=0;
function initAd(){
       if(!ns && !ie && !w3) return;
       if(ie)                adDiv=eval('document.all.sponsorAdDiv.style');
       else if(ns)        adDiv=eval('document.layers["sponsorAdDiv"]');
       else if(w3)        adDiv=eval('document.getElementById("sponsorAdDiv").style');
       randAd=Math.ceil(Math.random()*chanceAd);
       if (ie||w3)
       adDiv.visibility="visible";
       else
       adDiv.visibility ="show";
       if(randAd==1) showAd();
}
function showAd(){
if(adCount<adTime*10){adCount+=1;
       if (ie){documentWidth  =document.body.offsetWidth/2+document.body.scrollLeft-20;
       documentHeight =document.body.offsetHeight/2+document.body.scrollTop-20;}
       else if (ns){documentWidth=window.innerWidth/2+window.pageXOffset-20;
       documentHeight=window.innerHeight/2+window.pageYOffset-20;}
       else if (w3){documentWidth=self.innerWidth/2+window.pageXOffset-20;
       documentHeight=self.innerHeight/2+window.pageYOffset-20;}
       adDiv.left=documentWidth-200;adDiv.top =documentHeight-200;
       setTimeout("showAd()",100);}else closeAd();
}
function closeAd(){
if (ie||w3)
adDiv.display="none";
else
adDiv.visibility ="hide";
}
onload=initAd;
//End-->
</script>

</head>

<body>


<div id="sponsorAdDiv" style="visibility:hidden">

       <table border="0" cellpadding="0" cellspacing="1" width="300" bgcolor="gray">
   <tr>
       <td width="288" height="145" valign="top" bgcolor="white"><p>태그인넷입니다<br>
           www.tagin.net<br>이 레이어는 3초뒤 사라집니다</td>
   </tr>
</table>
</div>

</body>

</html>


2007/06/21 15:51 2007/06/21 15:51
Tags:

This is a protected post. Please enter the password to view the article.
이 글은 비밀글입니다. 글을 보시려면 비밀번호를 입력하세요.