2013.07.17

베테랑 네트워크 관리자의 9가지 특성

Paul Venezia | InfoWorld


베테랑 네트워크 관리자들은 그들만의 특징을 갖고 있다. 여기 설명한 것들은 이러한 특징의 모든 부분을 다루는 것은 아니지만 그들을 이해하고 함께 일하는데 도움이 될 것이다.

1. 그들은 이미 네트워크가 다운된 사실을 알고 있다
무엇보다 관리자들이 원하지 않는 상황이 있다. 전산관리시스템으로부터 자동 경고문자가 휴대폰으로 와서 문제의 원인을 파악하고 있는데 많은 사용자들이 한꺼번에 문자, 이메일, 전화 등을 통해 “어떤 부분이 다운된 것입니까?”라고 묻거나 더 심하게는 “네트워크가 다운됐어요!”라고 하는 메시지를 보내오는 것이다.

문제가 상당히 심각할 경우 네트워크 관리자들은 이미 그 문제를 파악하고 있으며 가능한 신속히 문제를 해결하려고 노력하는 중이다. 이러한 상황에서 이미 알고 있는 사실에 대해서만 전달할 경우 이는 전혀 상황에 도움이 되지 않는다.

2. 관리자들조차 몰랐다면 실제로 다운되지 않았을 가능성이 높다
반대로 “네트워크가 다운됐어요!”라는 메시지를 받을 경우라고 해도 여전히 전산관리시스템으로부터 이러한 사실을 통보 받지 못했을 경우라면, 단순히 사용자가 근거는 알 수 없지만 시스템에 대해 불만을 늘어놓는 경우일 때가 많다. 사용자들은 전산과 관련한 그 어떤 문제가 네트워크 내부에서건 인터넷 상에서건 발생할 경우, 이들은 그냥 '네트워크가 다운되었다'고 생각한다.

이 경우 실제로 웹사이트 자체의 문제로 인한 404 에러일 수도 있고 URL을 잘못 입력한 경우도 있을 수 있으며 사용자의 노트북 설정이 제대로 잡혀 있지 않아서 일 수도 있다. 그리고 사용자는 전산관리자에게 네트워크가 다운되었다고 불만을 제기하는 것이 가장 신속히 도움을 받을 수 있는 방법임을 잘 알고 있다. 하지만 대부분의 경우 노트북을 재부팅하면 문제는 쉽게 해결된다.

3. 문제의 원인을 파악하기 전에 핑테스트를 시도한다
특히 WAN이나 중간에 여러 프로바이더들이 끼어 있는 롱홀 링크 관련해 발생한 문제의 경우 원인을 파악할 때 약간의 시간 동안 문제의 원인에 대한 판단을 유보하는 것이 필요하다. 왜냐하면 이러한 연결들은 경로의 다양성에 의해 영향을 받기 때문이다. 또한 연결 관련 문제는 순식간에 사라질 수도 하다.

따라서 1분전만 해도 안정적이던 광 WAN 링크가 갑자기 30%의 패킷로스를 보일 수도 있고 간단한 절차를 통해 쉽게 고칠 수 있기도 하다. 문제가 발생하더라도 약간 판단을 유보한 후 문제의 원인을 파악하기 위해 노력해야 한다.

4. (믿기 어렵겠지만) 이미 네트워크를 재부팅 했다
문제 해결을 위해 인터페이스의 전원을 내린 후 다시 연결하게 되는 경우가 많다. 사실 이러한 방법이야 말로 문제를 해결하려 할 때 우선 시도해 보는 것이다. 문제의 원인은 자동 복구기능(auto-negotiation), 케이블 문제, 태양의 흑점 등 다양할 수 있겠지만 놀랍게도 인터페이스의 재부팅을 통해 많은 경우에 있어 문제를 해결 할 수 있다. 네트워킹 자체는 과학적인 요소로 이루어져 있지만 문제 해결을 위해서는 다른 접근법이 필요할 때도 있다.

5. 네트워크에 문제가 발생하면 머릿 속에서 그 원인을 추적한다
네트워크 관리자가 문제를 해결하는 과정에서 라우팅 테이블을 그냥 쳐다보고 있다고 해서 문제 해결의 압박감에 눌려있거나 혹은 원인을 몰라 전전긍긍하는 것으로 해석해선 안된다. 그는 머릿속에서 라우팅과 스위칭 경로를 따라 문제의 원인이 될 수 있는 여러가지 시나리오를 떠올리며 문제의 원인을 고민한다.

네트워크 비전문가들은 네트워크 관리자의 문제 해결 방식에 대해 전적으로 이해하지 못하지만, 그러한 동안에도 네트워크 관리자들은 머릿속에 가상의 미로를 떠올려 문제를 해결하기 위해 노력한다. 그 미로의 어느 지점에 다다르게 되면 있어서는 안되는 막다른 골목(a dead end)이 있을지도 모르기 때문이다. 네트워크 관리자들은 바로 이 지점을 찾고자 하는 것이며, 그 이후 경로를 다시 연결함으로서 순탄하게 문제를 해결 할 수 있다.

6. 서브넷 마스크나 CIDR를 계산하는 것이 숨쉬는 것 만큼이나 쉽다
대부분의 사람들은 공통 C클래스 넷마스크(the common Class C netmask)를 제외하고는 서브넷이나 사이더(CIDR)에 대해 이해하지 못하는 것 같다. 하지만 네트워크 관리자들에게 있어 이것은 숨쉬는 것 만큼이나 본질적이고 자연스러운 것이다.

이는 단순히 /28은 255.255.255.240의 넷마스크이거나, 16개의 주소로 구성되어 있다는 사실 등에 대해서만 알고 있는 것은 아니다. 라우팅 테이블 사이즈, ACL 어플리케이션, 그리고 다른 내부적 네트워킹 테스크를 줄이기 위해 작은 서브셋의 큰 숫자들을 짧게 정리하는 능력을 의미한다. ACL 하에서 인접한 네트워크들을 작은 청크로 나누는 과정에서 동일한 룰이 적용되지 않기 때문에 불안감을 느낀다. /19는 여러 개의 /24보다 훨씬 좋은 생각이다. 이는 와일드마스크(wildmasks)에도 동일하게 적용된다.

7. 버그를 용납하지 않는다
때때로 일반적인 문제해결 방법이나 새로운 네트워크를 구축하는 과정에서 설명할 수 없는 장애요소에 직면할 때가 있다. 설정(configurations)을 면밀히 검토하고, 연결, 라우트, 포워딩 테이블, 실행중인 디버그를 개략적으로 구상하면 문제를 해결하기가 그 어느 때 보다 쉬워진다. 이러한 부분은 소프트웨어 버그로 인해 존재할 수 밖에 없는 네트워킹의 지독한 부분이기도 하다.

네트워크 관리자들은 스위칭 및 라우팅 소프트웨어 버그를 개인적인 공격으로 간주하여, 버그가 발생할 경우 벤더를 심하게 비난하게 된다. 왜냐하면 버그로 인해 문제가 발생했다는 확신이 들기 전까지는, 모든 것이 이치에 맞지 않다고 느껴지기 때문이다. 그간 쌓아온 수년간의 경험과 지식을 의심케 하고, 로직의 존재가치를 상실케 하며, 스트레스를 받기도 한다. 마치 잠시동안 다른 사람으로 변해있는 것과 같은 느낌이 들기도 한다. 그동안 알고 있던 지식이 전혀 적용이 안되는 상황이 발생하는 것이다.

8 . 눈감고도 라이브 패킷 스트림을 읽고 복잡한 필터를 작성할 수 있다
네트워킹과 컴퓨팅을 TV와 영화에서 다룰 때 실제와 비슷한 것을 찾아보기는 어렵다. 그 중 한가지로 끊임없이 문자열이 흘러 내려가는 모니터 화면을 예로 들 수 있다. 시스템 관리자들에게 있어 이는 보통 로그파일과 관련된 내용에 해당한다.

네트워킹 분야에서는, 보통 패킷 덤프가 이에 해당한다. 하는 일에 따라 라이브 서킷에서의 패킷 캡쳐를 손쉽게 불러낼 수도 있고 패킷이 실시간으로 흘러가는 모습을 지켜볼 수도 있다. 단순히 모니터상에 흘러가는 텍스트가 아니다. 명백한 징후를 찾는 것이고, 네트워크 관리자가 원하는 정보를 찾아낼 때까지 필터를 통해 계속 걸러낸다.

이러한 경우에 있어서 속도가 매우 중요한데 그래서 관리자들은 BPF 필터링 문법에 정통한 경우가 많다. 또한 정상적인 상태로 보이지 않는 IP헤더와 같은 친숙하지 않은 것들에 대해서도 인식하고 있는 경우가 많으며 대부분의 사람들에게 알파벳 조합 이상의 의미를 가지지 않아 보이는 것과 같은 친숙하지 않는 내용에 대해서도 숙지하고 있다. 스타트랙에서는 클링족의 언어를 하는 사람들도 나오는데, 네트워크 관리자의 IP에 대한 지식은 거의 남들에게는 이와 비슷하게 보일 것이다.

9. 항상 리스크를 대비한다
네트워크 관리자들은 원격 기기를 통해 일하게 되는 경우가 많다. 서버가 네트워크를 통해 접속되지 않으면 콘솔을 사용하게 되는 서버관리자와는 다르게 네트워크 관리자들에게는 그러한 여유있는 상황이 아니다. 다시 말해 네트워크 관리자가 특정 기기에 변화를 줄 때 이는 연결이 끊어지게 되는 상황으로 나타난다.

기본적으로, 문제가 악화되기 전이라도 소소한 실수는 항상 있게 마련이며 혹은 이전에는 나타나지 않았던 심각한 문제로 비화된다. 리모트 스위치에 변화를 주는 것이나 35번 포트 대신 34번 포트로 전환하게 되면 네트워크 관리자들이 알지 못하는 사이에 연결이 끊어질 수도 있다. 이러한 상황에서 어떠한 네트워크가 오프라인 상태인지에 대해 궁금증을 갖게 되고 심지어 수리를 위해 이동을 하게 되는 경우가 발생할 수도 있다.

물론 한밤중에 이러한 일이 일어나는 일은 잘 없어야 하겠지만 문제는 그렇게 되는 경우도 많다는 것이다. 사소한 문제로도 연결이 끊어질 수도 있기 때문에 리모트 기기에 변화를 주어야 할때도 생기는 것이다. 특히 원격지로부터 인터넷 프로바이더를 변경하거나 방화벽과의 지속적인 연결이 없기 때문에 스크립트로 방화벽을 재설정하는 것이 이에 해당한다. 네트워크 관리자들은 이러한 상황을 감내하면서도 오늘을 살아간다.

이번 글을 통해 극도로 논리적이어야 하며, 그럼에도 업무상의 여러 리스크를 동반하는 삶을 사는 네트워크 관리자들의 일상과 고충에 대해 환기할 기회를 통해 이들이 어떻게 일하며 무슨 생각을 하며 사는지에 대해 공유할 수 있는 기회가 되었으면 한다.

글 하나로, 수없이 반복되는 네트워크의 다운상태에 대한 불만이 줄어들 것이라고는 생각하지 않으나, 이번 기회를 변화의 시작점으로 삼을 수도 있다. 사실, 이 글을 읽으면서 만약 여러분이 네트워크 관리자가 아니라면, 주변에 있는 네트워크 관리자를 찾아 커피를 한잔 대접하라. 좋은 기회가 될 것이다. editor@idg.co.kr


2013.07.17

베테랑 네트워크 관리자의 9가지 특성

Paul Venezia | InfoWorld


베테랑 네트워크 관리자들은 그들만의 특징을 갖고 있다. 여기 설명한 것들은 이러한 특징의 모든 부분을 다루는 것은 아니지만 그들을 이해하고 함께 일하는데 도움이 될 것이다.

1. 그들은 이미 네트워크가 다운된 사실을 알고 있다
무엇보다 관리자들이 원하지 않는 상황이 있다. 전산관리시스템으로부터 자동 경고문자가 휴대폰으로 와서 문제의 원인을 파악하고 있는데 많은 사용자들이 한꺼번에 문자, 이메일, 전화 등을 통해 “어떤 부분이 다운된 것입니까?”라고 묻거나 더 심하게는 “네트워크가 다운됐어요!”라고 하는 메시지를 보내오는 것이다.

문제가 상당히 심각할 경우 네트워크 관리자들은 이미 그 문제를 파악하고 있으며 가능한 신속히 문제를 해결하려고 노력하는 중이다. 이러한 상황에서 이미 알고 있는 사실에 대해서만 전달할 경우 이는 전혀 상황에 도움이 되지 않는다.

2. 관리자들조차 몰랐다면 실제로 다운되지 않았을 가능성이 높다
반대로 “네트워크가 다운됐어요!”라는 메시지를 받을 경우라고 해도 여전히 전산관리시스템으로부터 이러한 사실을 통보 받지 못했을 경우라면, 단순히 사용자가 근거는 알 수 없지만 시스템에 대해 불만을 늘어놓는 경우일 때가 많다. 사용자들은 전산과 관련한 그 어떤 문제가 네트워크 내부에서건 인터넷 상에서건 발생할 경우, 이들은 그냥 '네트워크가 다운되었다'고 생각한다.

이 경우 실제로 웹사이트 자체의 문제로 인한 404 에러일 수도 있고 URL을 잘못 입력한 경우도 있을 수 있으며 사용자의 노트북 설정이 제대로 잡혀 있지 않아서 일 수도 있다. 그리고 사용자는 전산관리자에게 네트워크가 다운되었다고 불만을 제기하는 것이 가장 신속히 도움을 받을 수 있는 방법임을 잘 알고 있다. 하지만 대부분의 경우 노트북을 재부팅하면 문제는 쉽게 해결된다.

3. 문제의 원인을 파악하기 전에 핑테스트를 시도한다
특히 WAN이나 중간에 여러 프로바이더들이 끼어 있는 롱홀 링크 관련해 발생한 문제의 경우 원인을 파악할 때 약간의 시간 동안 문제의 원인에 대한 판단을 유보하는 것이 필요하다. 왜냐하면 이러한 연결들은 경로의 다양성에 의해 영향을 받기 때문이다. 또한 연결 관련 문제는 순식간에 사라질 수도 하다.

따라서 1분전만 해도 안정적이던 광 WAN 링크가 갑자기 30%의 패킷로스를 보일 수도 있고 간단한 절차를 통해 쉽게 고칠 수 있기도 하다. 문제가 발생하더라도 약간 판단을 유보한 후 문제의 원인을 파악하기 위해 노력해야 한다.

4. (믿기 어렵겠지만) 이미 네트워크를 재부팅 했다
문제 해결을 위해 인터페이스의 전원을 내린 후 다시 연결하게 되는 경우가 많다. 사실 이러한 방법이야 말로 문제를 해결하려 할 때 우선 시도해 보는 것이다. 문제의 원인은 자동 복구기능(auto-negotiation), 케이블 문제, 태양의 흑점 등 다양할 수 있겠지만 놀랍게도 인터페이스의 재부팅을 통해 많은 경우에 있어 문제를 해결 할 수 있다. 네트워킹 자체는 과학적인 요소로 이루어져 있지만 문제 해결을 위해서는 다른 접근법이 필요할 때도 있다.

5. 네트워크에 문제가 발생하면 머릿 속에서 그 원인을 추적한다
네트워크 관리자가 문제를 해결하는 과정에서 라우팅 테이블을 그냥 쳐다보고 있다고 해서 문제 해결의 압박감에 눌려있거나 혹은 원인을 몰라 전전긍긍하는 것으로 해석해선 안된다. 그는 머릿속에서 라우팅과 스위칭 경로를 따라 문제의 원인이 될 수 있는 여러가지 시나리오를 떠올리며 문제의 원인을 고민한다.

네트워크 비전문가들은 네트워크 관리자의 문제 해결 방식에 대해 전적으로 이해하지 못하지만, 그러한 동안에도 네트워크 관리자들은 머릿속에 가상의 미로를 떠올려 문제를 해결하기 위해 노력한다. 그 미로의 어느 지점에 다다르게 되면 있어서는 안되는 막다른 골목(a dead end)이 있을지도 모르기 때문이다. 네트워크 관리자들은 바로 이 지점을 찾고자 하는 것이며, 그 이후 경로를 다시 연결함으로서 순탄하게 문제를 해결 할 수 있다.

6. 서브넷 마스크나 CIDR를 계산하는 것이 숨쉬는 것 만큼이나 쉽다
대부분의 사람들은 공통 C클래스 넷마스크(the common Class C netmask)를 제외하고는 서브넷이나 사이더(CIDR)에 대해 이해하지 못하는 것 같다. 하지만 네트워크 관리자들에게 있어 이것은 숨쉬는 것 만큼이나 본질적이고 자연스러운 것이다.

이는 단순히 /28은 255.255.255.240의 넷마스크이거나, 16개의 주소로 구성되어 있다는 사실 등에 대해서만 알고 있는 것은 아니다. 라우팅 테이블 사이즈, ACL 어플리케이션, 그리고 다른 내부적 네트워킹 테스크를 줄이기 위해 작은 서브셋의 큰 숫자들을 짧게 정리하는 능력을 의미한다. ACL 하에서 인접한 네트워크들을 작은 청크로 나누는 과정에서 동일한 룰이 적용되지 않기 때문에 불안감을 느낀다. /19는 여러 개의 /24보다 훨씬 좋은 생각이다. 이는 와일드마스크(wildmasks)에도 동일하게 적용된다.

7. 버그를 용납하지 않는다
때때로 일반적인 문제해결 방법이나 새로운 네트워크를 구축하는 과정에서 설명할 수 없는 장애요소에 직면할 때가 있다. 설정(configurations)을 면밀히 검토하고, 연결, 라우트, 포워딩 테이블, 실행중인 디버그를 개략적으로 구상하면 문제를 해결하기가 그 어느 때 보다 쉬워진다. 이러한 부분은 소프트웨어 버그로 인해 존재할 수 밖에 없는 네트워킹의 지독한 부분이기도 하다.

네트워크 관리자들은 스위칭 및 라우팅 소프트웨어 버그를 개인적인 공격으로 간주하여, 버그가 발생할 경우 벤더를 심하게 비난하게 된다. 왜냐하면 버그로 인해 문제가 발생했다는 확신이 들기 전까지는, 모든 것이 이치에 맞지 않다고 느껴지기 때문이다. 그간 쌓아온 수년간의 경험과 지식을 의심케 하고, 로직의 존재가치를 상실케 하며, 스트레스를 받기도 한다. 마치 잠시동안 다른 사람으로 변해있는 것과 같은 느낌이 들기도 한다. 그동안 알고 있던 지식이 전혀 적용이 안되는 상황이 발생하는 것이다.

8 . 눈감고도 라이브 패킷 스트림을 읽고 복잡한 필터를 작성할 수 있다
네트워킹과 컴퓨팅을 TV와 영화에서 다룰 때 실제와 비슷한 것을 찾아보기는 어렵다. 그 중 한가지로 끊임없이 문자열이 흘러 내려가는 모니터 화면을 예로 들 수 있다. 시스템 관리자들에게 있어 이는 보통 로그파일과 관련된 내용에 해당한다.

네트워킹 분야에서는, 보통 패킷 덤프가 이에 해당한다. 하는 일에 따라 라이브 서킷에서의 패킷 캡쳐를 손쉽게 불러낼 수도 있고 패킷이 실시간으로 흘러가는 모습을 지켜볼 수도 있다. 단순히 모니터상에 흘러가는 텍스트가 아니다. 명백한 징후를 찾는 것이고, 네트워크 관리자가 원하는 정보를 찾아낼 때까지 필터를 통해 계속 걸러낸다.

이러한 경우에 있어서 속도가 매우 중요한데 그래서 관리자들은 BPF 필터링 문법에 정통한 경우가 많다. 또한 정상적인 상태로 보이지 않는 IP헤더와 같은 친숙하지 않은 것들에 대해서도 인식하고 있는 경우가 많으며 대부분의 사람들에게 알파벳 조합 이상의 의미를 가지지 않아 보이는 것과 같은 친숙하지 않는 내용에 대해서도 숙지하고 있다. 스타트랙에서는 클링족의 언어를 하는 사람들도 나오는데, 네트워크 관리자의 IP에 대한 지식은 거의 남들에게는 이와 비슷하게 보일 것이다.

9. 항상 리스크를 대비한다
네트워크 관리자들은 원격 기기를 통해 일하게 되는 경우가 많다. 서버가 네트워크를 통해 접속되지 않으면 콘솔을 사용하게 되는 서버관리자와는 다르게 네트워크 관리자들에게는 그러한 여유있는 상황이 아니다. 다시 말해 네트워크 관리자가 특정 기기에 변화를 줄 때 이는 연결이 끊어지게 되는 상황으로 나타난다.

기본적으로, 문제가 악화되기 전이라도 소소한 실수는 항상 있게 마련이며 혹은 이전에는 나타나지 않았던 심각한 문제로 비화된다. 리모트 스위치에 변화를 주는 것이나 35번 포트 대신 34번 포트로 전환하게 되면 네트워크 관리자들이 알지 못하는 사이에 연결이 끊어질 수도 있다. 이러한 상황에서 어떠한 네트워크가 오프라인 상태인지에 대해 궁금증을 갖게 되고 심지어 수리를 위해 이동을 하게 되는 경우가 발생할 수도 있다.

물론 한밤중에 이러한 일이 일어나는 일은 잘 없어야 하겠지만 문제는 그렇게 되는 경우도 많다는 것이다. 사소한 문제로도 연결이 끊어질 수도 있기 때문에 리모트 기기에 변화를 주어야 할때도 생기는 것이다. 특히 원격지로부터 인터넷 프로바이더를 변경하거나 방화벽과의 지속적인 연결이 없기 때문에 스크립트로 방화벽을 재설정하는 것이 이에 해당한다. 네트워크 관리자들은 이러한 상황을 감내하면서도 오늘을 살아간다.

이번 글을 통해 극도로 논리적이어야 하며, 그럼에도 업무상의 여러 리스크를 동반하는 삶을 사는 네트워크 관리자들의 일상과 고충에 대해 환기할 기회를 통해 이들이 어떻게 일하며 무슨 생각을 하며 사는지에 대해 공유할 수 있는 기회가 되었으면 한다.

글 하나로, 수없이 반복되는 네트워크의 다운상태에 대한 불만이 줄어들 것이라고는 생각하지 않으나, 이번 기회를 변화의 시작점으로 삼을 수도 있다. 사실, 이 글을 읽으면서 만약 여러분이 네트워크 관리자가 아니라면, 주변에 있는 네트워크 관리자를 찾아 커피를 한잔 대접하라. 좋은 기회가 될 것이다. editor@idg.co.kr


X