이인석 | 아이캔매니지먼트 과장
따르릉. 어느날 사무실로 전화를 한 고객이 다짜고짜 묻는다.
고객 : 동시 접속자가 3만 명인데 어느 정도 사양의 서버가 필요합니까.
나 : 제일 좋은 서버 쓰세요(이때 나의 표정은 -.-;)
왜 못마땅한 표정(-.-;)을 지었을까. 컴팩, IBM, 델 등 그 어떤 서버에 대한 설명에도 동시 접속자가 3만 명을 지원한다는 수치는 기록하고 있지 않기 때문이다. 때문에 서버 사양을 결정하는 데는 고객의 환경이 가장 중요하며, 고객 역시 무조건 답만 알아내려고 할 것이 아니라 사전에 환경에 대한 파악부터 해야 한다.
IT에 종사하는 이들이나 IT를 조금 안다는 이들은 숫자 놀이를 좋아한다. 모든 데이터는 수치로 나타낼 수 있어야 하고, 그것을 바탕으로 다른 것과 비교할 수 있기 때문일 것이다. 그러나 아쉽게도 용량 계획은, 더군다나 초기 용량 계획에 대한 숫자는 존재할 수 없을 것이다. 없는 것은 아니지만 없다고 생각하는 것이 정답이다.
www.tpc.org라는 사이트가 있다. 여기서는 여러 가지 설정을 하고 그에 맞는 성능 테스트를 해서 그 결과를 볼 수 있다. 여기서 보면 애플리케이션 서버, 웹 서비스, 온라인 트랜잭션 프로세싱 등의 항목이 나온다. 그렇다면 여기에 기록된 수치가 앞으로 자기가 운영할 IIS와 MS SQL 서버에 그대로 적용될 수 있을까? 절대 아니다. 해당 사이트가 테스트한 환경과 내가 테스트할 환경은 절대적으로 틀리기 때문이다. 비슷한 환경에서 테스트했다고 생각할 수 있을지 모르지만, 정확하고 투명한 데이터도 아니고 신뢰할 만한 사항도 아니다. 결론은 '사전 용량 계획에 대한 답은 없다'라는 것이다. 답이 없다기 보다는 그걸 만들어내는 공식이 없다는 것이다.
그럼 방법이 없는가. 결론부터 이야기기를 한다면 서버용량에 대한 수치를 그려내기 위해서는 크기를 설정하고, 용량이라는 것을 계획한 후 운영을 하면서 정확한 데이터를 얻어야 한다.
용량 계획과 SLA
용량 계획은 사전 용량 계획과 사후 용량 계획 두 부분으로 나눌 수 있다. 이들에 대해 언급하기 전에 SLA(Service Level Agreement)라는 것에 대해 먼저 짚고 넘어가자. SLA를 한국말로 그대로 해석하면 '서비스 수준 동의'쯤 될 것이다. 이에 대한 정의는 다음과 같다.
SLA는 네트워크 서비스 공급업체와 고객간에 체결하는 계약으로, 대개 어떤 서비스가 제공될 것인지를 측정이 가능한 조건으로 명시한 것이다. 많은 수의 인터넷 서비스 업체들이 SLA와 같은 형태의 계약을 고객들에게 제공한다. 최근에는 대기업의 IT 관련 부서가 자신의 고객, 즉 사내 각 부서에서 근무하는 사용자에 대한 서비스를 측정하고, 근거를 제시하며, 외부 네트워크 제공업체와 비교하는 것이 가능하도록 SLA를 작성해 활용하는 방안을 채택하고 있다.
다음은 SLA에 포함돼야 할 척도 중의 일부다.
☞ 동시에 서비스할 수 있는 사용자의 수
☞ 실제 성능을 주기적으로 비교할 수 있는 명확한 성능 기준
☞ 사용자들이 영향을 받을 수 있는 네트워크의 변경작업 등을 사전에 고지하기 위한 일정
☞ 다양한 종류의 문제에 대한 고객상담실의 응답시간
☞ 다이얼 업 접속 가능성
☞ 제공될 사용량 통계
최근에는 SLA 경험자를 찾는 구인광고도 간간히 등장할만큼 SLA에 대한 중요성이 높아졌다.
SLA는 공급업체와 고객 간의 서비스 레벨에 대한 동의서이므로, 서로의 동의한 사항을 위반하면 그에 대한 벌금을 물게 되는 것이다. 고객의 서비스 항목을 잘 파악을 하고 그에 대해 공급업체는 '서버 가동시간을 99% 이상으로 하겠다'라거나, 고객은 '99.5%로 해달라' 등의 세부 항목을 설정하게 되는 것이다.
이런 항목 중에 빠지지 않고 들어가는 것이 용량 계획이다. 여기에는 사전 용량 계획에 대한 부분도 포함돼 있다.
일례로 CPU 사용률이 80% 이상을 넘을 경우(단, 하드웨어나 애플리케이션에서 이상이 없으면) 시스템을 업그레이드를 할 것이며, 업그레이드를 할 때는 어떤 크기로 할 것인지에 대해서 계약하기도 한다. 즉, 용량 계획이나 성능에 대한 부분과 그 이외의 여러가지 모니터링 부분 등이 결합돼 SLA가 맺어진다.
IIS 사전 용량 계획하기 : CPU와 메모리
일반적으로 사전 용량 계획은 모든 환경(시스템, 애플리케이션, 네트워크 등)을 제품 기준으로 맞추고 스트레스 툴(Stress Tool)로 테스트해서 결과를 얻어낸다.
하지만 개인적으로 필자가 생각하고 있는 사전 용량 계획은 웹 애플리케이션 개발이 완료되고, 데이터베이스의 디자인도 끝내고, DB도 생성을 한 이후에 이 애플리케이션을 운영할 적당한 시스템이 어느 정도의 사양을 갖춰야 하는 가에 대한 값이다. 안타깝게도 이 부분에 대해 제시된 데이터는 없다. 하지만 좌절할 필요는 없다. 만들 수는 있기 때문이다.
일반적으로 시스템 크기를 선정할 때 CPU, 메모리, HDD(엄밀하게 얘기를 하면 디스크의 I/O), 네트워크의 네가지 구성 요소를 고려하는데, 이들의 한계치는 설정할 수가 있다. 만일 초보 시스템 관리자라면 아마 앞서 말한 TPC 사이트에 의존할지도 모르겠다.
그러나 이 글에서는 성능 모니터를 설정해서 어느 정도의 해답을 제시하려 한다. 그러나 여기서 제시하는 사항도 어디까지나 참고사항일 뿐이며, 그 수치가 아무리 신뢰할만한 데이터라고 해도 사전 용량 계획으로 잡아 둔 크기의 3배 이상으로 용량 계획을 할 것을 권장한다. 이유는 서버가 본격적으로 운영되기 시작하면서 예측하지 못한 부분에서의 서버 자원을 사용할 수가 있기 때문이다.
IIS를 설치하건 MS SQL을 설치하건 마이크로소프트가 주장하는 가장 첫 번째 요소는 HCL(Hardware Compatibility List)을 사용하라는 것이다. 핵심은 간단하다. 마이크로소프트에서 제공하는 드라이버가 있느냐 없느냐 하는 것이다. 마이크로소프트에서 제공하는 드라이버가 없다면 시스템 장애가 발생할 것이고, 마이크로소프트는 그에 대한 책임이 없다는 것이다. HCL에 있는데도 블루 스크린이 발생을 한다면? 이것은 장치가 고장이 났거나 드라이버의 문제가 있으므로 업데이트를 해야 한다. 기본적인 사항이므로 점검을 해보고 넘어가는 것이 좋다.
HCL 목록은 www.microsoft.com/whdc/hcl/default.mspx이다.
그럼 CPU는 어느 정도의 크기로 잡아야 할까. 정확한 수치를 제시할 수는 없지만 여유있게 투자하고 가능하면 캐시가 큰 것으로 할 것을 권장한다.
다행히 수치를 주는 사이트(http://servers.digitaldaze.com/compare/spec.html)가 있기에 소개한다. 그러나 너무 믿지는 말기 바란다.
메모리는 윈도우 2000 서버에서나 IIS 그리고 MS SQL에서도 가장 접근하기 어려운 부분이다. 병목 현상도 메모리에서 가장 빈번하게 발생한다. 이번 강좌에서 테스트하려는 서버의 IIS가 사용하는 메모리량은 30MB 정도다. 윈도우 2000에서 사용하는 메모리를 빼니 400MB 정도가 사용 가능한 메모리의 양이다. 메모리에 대한 수치도 사전에 제시한다는 것이 어렵다.
CPU나 메모리 크기를 적게 산정했다면 큰 문제가 되지 않을 수 있다. CPU가 2웨이, 4웨이를 지원한다면(물론 싱글만을 지원하는 보드를 구매할까 걱정이긴 하지만), CPU를 추가 장착하고 장치 관리자를 연다(화면 1).
(화면 1) ACPI 등록정보로 드라이버 업데이트하기
ACPI의 등록정보를 열어서 드라이버 업데이트를 연다. 특정한 드라이버를 선택할 수 있도록 이 장치에 적절한 드라이버 목록 표시를 선택하고 ACPI 다중 프로세스 PC를 선택한다(화면 2). 경고 메시지가 뜨면 예를 클릭하고 설치 완료를 하면 된다. 시스템 변경 관계로 재부팅을 하라는 메시지가 뜬다. 재부팅을 하면 원하는 숫자 만큼의 CPU가 있는 것을 여러 경로를 통해서 알 수가 있다.
(화면 2) ACPI 다중 프로세서 PC 선택하기
그럼 메모리가 부족하면? 마찬가지다. 원하는 만큼의 메모리만을 추가하면 된다. 그러나 디스크를 다시 재구성해야 할 상황이라면 문제가 있다. 심한 경우 시스템을 재설치해야 하는 경우가 생길 수도 있고 데이터를 이리저리 옮겨야 할 수도 있다. 쉽지 않은 부분인 만큼 계획을 잘 세워야 할 것이다.
IIS 사전 용량 계획하기 : 디스크 I/O와 네트워크
디스크 크기를 산정할 때는 시스템 파티션, 페이징 파티션, 데이터 파티션 그리고 백업과 로그를 생각해 볼 수가 있다. 조금 더 욕심을 내서 많은 애플리케이션들이 올라간다면 그것에 대한 디스크를 따로 가져가는 것도 고려해야 한다. 여러 다른 상황이 있겠지만 우선은 이 정도만을 고려하자.
윈도우 2000을 설치하고, IIS를 설정했다면 1GB가 조금 넘는 용량이 시스템 파티션에 사용되고 있을 것이다. 여유 있게 3배로 하라고 했으니 적어도 3GB 이상(권장 사항은 5GB 이상)이다.
참고로 디스크 전체 크기의 85%가 사용되고 있다면 그 디스크는 사용을 하지 않는 것이 좋다.
왜 15%나 남았는데 쓰지 말라고 하는 것일까. 그것은 바로 디스크의 검색 속도 때문이다. 디스크는 헤드가 왔다갔다 하면서 데이터를 읽거나 쓰거나 하는데, 85% 이상이 되면 검색 속도가 느려진다. 빨리 빨리 데이터가 메모리로 올라가서 CPU와 통신을 해야 하는데 검색 속도가 느려지면 메모리와 CPU는 대기 상태가 된다.
PAGEFILE.SYS가 위치할 페이징 파티션은 시스템 파티션과 마찬가지로 5GB로 잡는다. 아무리 물리적인 RAM의 양이 많다고 해도 실질적으로 가상 메모리인 페이징 파일은 4GB 이상을 사용하지 못한다. 물리적으로 메모리의 1.5배가 적당하다고 해서 그 숫자대로 한다면 큰 손해는 없지만 참고로 알아 두자.
데이터 파티션은 이미 개발이 완료됐기에 어느 정도의 데이터 양이 필요한지 계산이 끝났을 것이다. 거기에 맞게 계산을 해서 데이터 파티션을 잡으면 된다.
백업은 여러 용도로 사용될 수 있을 것이다. 데이터를 백업받을 수도 있고 윈도우 2000의 시스템 백업을 받은 다음 용량을 계산하면 쉽지만, 로그는 유동적이라 계산하기가 어렵다. 로그는 여러모로 필요한 사항이기 때문에 저장하는 것이 좋다. 그러나 디스크가 모자란다면 로그의 보관주기를 짧게 가져갈 것을 권장한다.
여기까지가 논리적인 파티션에 대한 설명이다. 이런 논리적인 볼륨들이 36GB SCSI 디스크 두개로 구성될 수도 있다.
그러나 현재 많은 브랜드의 서버 제품이 RAID를 많이 사용하는 추세다. RAID는 레벨로 따지며 0, 1, 5가 주로 사용되고 있으며, 0, 1, 5의 단점을 서로 보완하기 위해 01과 10이라는 레벨이 개발됐다. 레벨 01과 10의 차이는 스트라이프가 먼저 되는가. 미러가 먼저 되는가의 차이다(http://www.raid.co.kr/sub/study/RAID를 참고하자).
RAID 레벨을 이해하는 것도 중요하지만 운영할 IIS 서버에 맞게 레벨을 선택하는 것이 좋다.
윈도우 2000에서 소프트웨어적으로 RAID를 구현할 수 있지만 권장 사항이 아니다. RAID를 구성하려면 하드웨어적으로 하기를 바란다.
어느날 고객으로부터 연락을 받았다. 웹 페이지의 이미지 로딩이 한번에 펼쳐지는 것이 아니라 순차적으로 위에서부터 아래로 이미지가 하나씩 뜬다고 한다. 사이트에 들어가 봤더니 정말 사진이 한장씩 펼쳐진다. 이미지를 관리하는 서버가 따로 있고 모든 이미지는 이 서버에서 로딩되고 있는 상황이었다. 결론을 먼저 이야기하면 처음부터 디스크 사이징을 잘하고 RADI 레벨을 잘 선택했다면 이런 현상은 없을 것이다. 결국 이 사이트는 RAID 레벨 10을 도입했다. 변경 후 웹페이지는 정상적으로 작동했다.
디스크 용량 계획을 할 때는 크기도 중요하지만 그 데이터가 어떤 용도로 사용될 것인가를 고려하는 것도 중요하다.
최근 기업들은 100Mbps 전용 네트워크를 많이 선택한다. 우선은 이 정도면 충분하다. 때로는 10Mbps도 충분하다. 네트워크 회선 증설은 CPU나 메모리를 증설하는 것보다 쉽기 때문에 큰 걱정은 하지 않아도 된다. 100Mbps 전용이 양에 안차면 기가비트 이더넷을 사용하면 되지만 기가비트로 바로 가기 보다는 차라리 팀(team) 기능을 사용해서 100Mbps 네트워크 두 개를 묶어서 200Mbps를 사용하거나, 한쪽의 LAN 카드가 문제가 있으면 예비용으로 사용할 수 있게 스탠바이로 준비해 두는 것도 좋다. 다만 서버가 제공하는 한도가 초과되면 서버를 증설하면서 로드 밸런싱을 염두해둬야 할 것이다.
지금까지 IIS에 대한 사전 용량 계획을 주제로 이야기했지만 많은 부분을 성능에 대해 언급한 것 같다. 용량 계획과 성능 분석은 실과 바늘의 관계다. 용량 계획을 하기 위해서는 데이터를 추출해야 하고, 그것을 가능하게 하는 것이 성능 분석이기 때문이다. 그렇기 때문에 앞으로도 성능에 대한 부분이 많이 언급될 것이고, 서버 설정 후 테스트 과정에서도 성능 분석에 대해 자세하게 언급할 것이다.
MS SQL의 사전 용량 계획 : CPU와 메모리
MS SQL 뿐만이 아니고 다른 제품의 SQL도 모든 용량 계획은 트랙잭션 처리량에 의존한다. MS SQL 역시 3배 이상의 여유를 갖고 사이징을 잡으라고 권하고 싶다. 마이크로소프트가 40개 이상의 물리적인 디스크를 물리고 초당 1000 트랜잭션을 처리했다는 벤치마크 결과도 있다.
SQL 서버의 CPU 용량을 계획할 때는 IIS에서 알려준 http://servers.digitaldaze.com/compare/spec.html을 권장하고 싶다. 여러 가지 벤치마크에 대한 사항이 있어 도움이 될 것이다. 여기서 중요하게 살펴봐야 할 부분은 정수 처리 성능이다. 정확한 계산이 어렵다면 역시 캐시가 큰 CPU를 선택하고 싱글로 먼저 테스트를 해보는 것이 좋다. 싱글에 부하가 걸린다면 듀얼로 업그레이드를 하면 부족한 부분은 없을 것이다. 물론 선택된 제품의 사양 중 가장 빠른 CPU와 가장 큰 캐시를 선택하는 조건이다.
마이크로소프트 SQL은 생각보다 CPU를 많이 사용한다. 다른 애플리케이션에서는 CPU를 늘려도 큰 차이는 없지만 MS SQL은 CPU 하나만을 추가해도 3배의 용량을 차지한다고 봐도 과장은 아니다. CPU는 많은 연결을 관리하고, 데이터 캐시를 효과적으로 관리하고, 쿼리를 최적화해서 실행하고, 제약조건을 검사하고, 저장 프로시저를 실행시키고 테이블과 인덱스를 잠그는 등 프로세싱 주기를 많이 사용한다. MS SQL 서버의 CPU는 가장 빠른, 가장 큰 캐시를 가진 것을 추천한다.
MS SQL의 메모리 운영 방식의 기본값은 동적이다. 이 말은 MS SQL은 자신이 사용할 메모리의 양을 운영체제와 애플리케이션의 메모리 사용량에 따라서 자동으로 설정하게 된다. MS SQL의 관점에 본다면 RAM에서 불러오는 작업이 가상 메모리에서 불러오는 것보다 수천 배가 빠르다. RAM의 양이 적으면 메모리 공간이 부족하므로 X86 기반의 멀티 프로세스는 FIFO 알고리즘이 적용돼 먼저 들어온 주소의 페이지가 하드디스크의 가상 메모리로 페이지 된다는 것이다.
나간 데이터를 다시 메모리로 불러 들여할 상황이면 그 대기 시간 때문에 병목이 생긴다. 만일 충분한 메모리를 가지고 있다면? 가상 메모리로 갈 일이 없다. 다시 말하면 충분한 메모리의 양은 SQL 서버의 성능을 좌지우지 한다는 것이다. 메모리 역시 일정한 수치값이 없으며, 이것을 얻을려고 하는 것도 무의미하다. 중소 기업이라면 2GB부터 시작할 것을 권장한다.
메모리의 성능은 조정할 수가 있는데, 이 부분은 테스트 후 성능 분석에서 언급하도록 하겠다. 노파심에서 하는 이야기지만 보드에 메모리 뱅크가 몇 개가 있는지 반드시 확인하고, 해당 서버의 최대 메모리 사양과 그에 맞는 MS SQL 제품을 선택하는 것을 잊지말자.
참고로 자신이 개발한 DB가 쿼리 중심이냐 트랙잭션 중심이냐에 따라 메모리의 사용 용도가 달라진다. 쿼리는 컴파일이 되고 캐시(메모리)에 머무르기 때문에 큰 메모리를 갖고 있는 것이 유리하다. 반대로 트랙잭션 중심은 캐시(메모리) 히트율이 떨어지기 때문에 적은 메모리가 유리할 수 있다. 트랜잭션 중심의 성능 향상은 디스크 I/O를 향상시키는 것이 더 좋을 것이다.
MS SQL의 사전 용량 계획 : 디스크 I/O와 네트워크
디스크 I/O는 IIS에서도 언급했지만 용량만을 보고 결정할 사항이 아니다. 더군다나 MS SQL이면 I/O의 속도와 폴트 톨러런스(fault tolerance)를 고려해야 한다. 일반적으로 IIS는 결함 제어를 위해 로드밸런싱을 사용한다. MS SQL은 클러스터를 사용한다. 차이는 데이터의 사용 목적 때문이다.
MS SQL이 한 개의 디스크 드라이브에서 운영할 수 없다는 것은 아니다. 그러나 한 개 보다는 두 개가 좋고, 두 개 보다는 세 개가 좋다는 것이다. 데이터 용량 계산은 기본적으로 독자에게 맡기겠다.
디스크의 개수도 중요하지만 SCSI의 채널도 중요하다. 한 채널에 물리는 드라이브 개수는 5개 이상을 넘기지 않을 것을 권장한다. 물론 한 채널에 물릴 수 있는 드라이브 수는 그 이상이지만, 가장 속도가 느린 자원인 디스크이지만 디스크 용량을 써가면서 낼 수 있는 권장값이다. 아예 큰맘 먹고 한 디스크에 한 파티션씩 할당할 것을 권장한다.
그럼 몇 개의 디스크가 필요할까. 시스템 파티션에는 윈도우 2000을 설치한다. 페이지 파티션은 가상 메모리인 페이징 파일만을 가지고 있다. MS SQL의 시스템 파일과 시스템 DB가 있을 것이다. 그러나 여기서 TEMP DB는 제외를 한다. TEMP DB는 입출력이 많은 DB 이므로 아예 따로 디스크를 하나 할당할 것을 권장한다. 이것도 한 개의 디스크로 가자. 그리고 사용자 DB를 하나의 디스크로 가져간다.
백업을 테이프로 받는다면 상관 없겠지만 디스크로 받겠다면 이것 역시 하나의 디스크로 가져가야 한다. 기본적으로 많이 쓰면 6개다. 결함 허용이 없는 디스크 구성이기 때문에 RAID 레벨을 독자 여러분의 상황에 맞게 구성하면 무척이나 많은 디스크를 가지게 될 것이다. 그래도 성능이 제대로 발휘만 된다면 성공적인 용량 계획이 될 것이다.
네트워크는 사용량이 적을 것이다. 많은 양의 네트워크 트래픽을 보내고 받는 것을 IIS가 처리하기 때문이다. 일반적으로 SQL은 애플리케이션의 뒤에 배치된다. 심지어는 3티어에 배치되는 경우도 있다. 이런 구조덕에 관련된 데이터만을 전송해주면 될 것이고 이것은 IIS까지만 또는 애플리케이션 서버까지만 전송하면 되기 때문에 그렇게 많은 양의 트래픽이 사용되지는 않을 것이다.
다음 시간에는 용량 계획을 위한 테스트에 대해 살펴볼 것이다. 테스트를 위해서는 준비 설정을 해야 할 것이고 WAS(Web Application Stress)라는 툴을 돌려서 모의 실험을 할 것이다. 이 모의 실험을 하고 있는 동안 IIS와 MS SQL에서 성능 분석을 설정해서 로그를 남기고 있을 것이고, MS SQL에서는 쿼리 분석을 위해서 프로파일러(PROFILER)도 실행시켜 놓을 것이다. 이런 자료를 토대로 서버의 사양을 파악하고 적정 기준치 설정을 할 것이며, 이 기준치를 갖고 사후 용량 계획도 잡아볼 것이다.
=================================================================
효율적인 서버 관리를 위한 관리자의 행동지침 4가지
관리해야 하는 서버 수가 많아지면 그것을 혼자서 관리한다는 것은 불가능하다. 마이크로소프트가 제시하는 모든 제품을 구매하지 않는 이상은, 혼자라기 보다는 소수의 인원이 관리를 한다는 것이 맞을 것이다. 소수가 됐던 다수가 됐던 여러명이 팀을 이뤄 서버를 관리하다 보면 혼선을 빚을 때가 많다. 동일한 작업이 같은 시간에 서로 다른 사람에 의해 이뤄지다보면, 나중에 문제가 생겼을 때 서로 책임을 떠넘기게 된다. 아니면 아예 작업 기록이 없어서 해당 작업이 누구에 의해 이뤄졌는지를 아예 모를 때도 있다. 이 같은 문제를 해결하기 위해서는 사전에 어떤 작업이 필요한지 필자의 경험을 통해 살펴보자
하나, 모든 정보에 대한 설명은 필수
(화면) 계정별로 상세하게 설명이 기록돼 있는 화면
(화면)은 윈도우 서버 2000 뿐만 아니라 윈도우 NT 4.0에서도 유사하게 볼 수 있는 환경이다. 문제는 규모가 큰 시스템을 관리하든 작은 규모의 시스템을 관리하든 관리자다들이 (화면)의 오른쪽에 있는 계정별 설명을 잘 기록하지 않는다는 것이다. 초창기에 업무를 그렇게 처리했다면 계속해서 그럴 것이다. 사실 필자도 처음에는 그랬다. 그럼 그렇게 관리자들이 귀찮아 하는 사항을 굳이 마이크로소프트가 계속해서 사용하게 하는 이유는 무엇일까. 그것은 바로 필요해서이다. 이는 단지 윈도우 서버에만 해당되는 내용이 아니라 다른 운영체제를 비롯해 네트워크 장비, 더 나아가서는 일반 업무에서도 상당히 필요한 부분이다.
혼자서 관리하는 서버라면 굳이 이런 설명이 필요없을 지도 모른다.
하지만 이런 경우를 한번 생각해보자. 여러대의 윈도우 서버 시스템이 있는 회사에서 익스체인지 서버를 담당하던 직원이 그만두게 됐다. 그것도 급작스럽게 그만두게 돼 업무 인수인계가 제대로 되지 못했다. 이런 상황에서 전임자가 계정별 상세 설명을 서버에 기록하지 않았다면 후임자는 계정 파악에만 많은 노력을 들여야 할 것이다. 그러나 설명에 해당 계정의 사용목적이나 관련 정보를 일목 요연하게 적어 놨다면 후임자는 업무에 대해 보다 쉽게 파악할 수가 있다. 자기가 할 업무가 아니니까 신경 안쓴다고? 그러지 말자. 나도 똑같은 경우를 당할 수 있다.
둘, '삽질'이냐 '내공'이냐는 나의 몫
보통 이 바닥에서는 '삽질' 또는 '내공' 등의 단어를 종종 사용한다. 그런데 내공은 저절로 쌓이는 것이 아니다. 영화를 보면 주인공의 부모가 원수의 손에 죽임을 당하고, 주인공은 가까스로 살아나서 힘든 생활과 무술을 열심히 연마한다. 이후 사부님으로부터‘이제 하산하여도 좋다'라는 말을 듣고 밀짚모자를 눌러 쓰고 고향으로 돌아간다. 그리고 바람이 부는 날에 원수를 찾아가서 복수를 한다.
여기서 가장 주목할만한 대목은 바로 '이제 하산하여도 좋다'이다. 난 언제쯤 하산해도 될까. 눈만 뜨고 일어나면 새로운 기술이 쏟아진다. 내가 기술을 배우는 속도보다 새로운 기술의 등장 속도가 더 빠르니 한숨은 절로 나온다. 하지만 뜻이 있는 곳에 길은 아주 많다. 단, 본인이 게을러지지만 않는다면.
셋, 정정당당해지자.
또 한가지 얘기를 하고 싶은 것은 정정당당 하자는 것이다. 잘못은 누구나 할 수가 있다. 그러나 그 잘못을 숨기려고 하는 것이 잘못된 것이다. 예전에 모 사이트에서 ASP의 잘못된 루프로 메모리 누수가 발생해서 웹서버가 죽어나갔다. 루프를 잡아 놓고 전화를 했더니 담당자는 코드를 고친적이 없다고 잡아뗀다. 증거를 들이미니 그때서야 잘못했다고 한다. 또 다른 사례다. 프로그램이 구동이 안돼서 들어가 봤더니 해당 프로그램이 삭제돼 있었다. 누가 그랬을까 하고 찾아 봤더니 개발자였다. 왜 지웠냐고 했더니 그런적이 없다고 펄쩍 뛴다. 로그를 보여줬음에도 불구하고 자기가 아니라고 끝까지 우긴다.
이렇게 뭘 만져 놓고 잘못 수정을 했음에도 불구하고 모른다고 발뺌하는 나몰라라 형은 다른 사람을 더 많이 고생시키게 된다. 작업을 하면서 크고 작은 실수는 누구나 하게 마련이다. 그러나 그것을 덮을려고 하지 말고 빨리 실토하고 해결책을 찾는 것이 좋다.
넷, 문서화
문서화 작업은 정말 아무것도 아닌 것 같지만 귀찮고 힘든 작업이다. 그러나 이 문서가 얼마나 업무에 도움이 되는지는 만들어 놓고 보면 안다. 시스템을 운영하다 보면 계정, 보안과 관련된 사항뿐만이 아니라 IIS, MS SQL, 익스체인지 등에 대해 자기만의 구축 방법과 마이크로소프트에서 제시한 값이 있을 것이다. 이런 것들에 대해 될 수 있으면 전 부분에 대해 문서화를 해 놓고 그 값에 맞추는 방식을 채택하자. 그럴 경우 다른 사람과의 공동 작업에서도 이미 정책이 결정된 사항이기 때문에 혼선이 일어날 일이 없다. 예를 FTP 설정 사항에 대해 다음과 같이 정리할 수 있을 것이다.
추천 설정 사항 : 익명의 FTP 로그온 허용하지 않음
현재 설정 사항 : 익명의 FTP 로그온 허용
단적인 예를 들긴 했지만 서버에는 설정할 사항들이 무수히 많다. 레지스트리, 폴더의 ACL 권한 등은 추천 설정 사항으로 아주 모범적인 사항을 만들어 놓고, 어디에서나 그 환경에 맞게 설정만 하면 된다. 추천 설정 사항에 대한 정보는 마이크로소프트나 정보보호진흥원 등의 보안 관련 사이트를 뒤지면 된다.
출처 : on the NET