2012.10.26

글로벌 컬럼 | IT운영자가 코딩을 할 수 있어야 하는 이유

Paul Venezia | InfoWorld
우리 모두는 답하기 곤란한 질문을 자주 받곤 한다. "무슨 일 하세요?" 그런 질문에 보통 필자는 "컴퓨터 쪽에서 일해요"라고 답한다. 질문자가 무엇을 떠올리는지 보기 위해서다. 그러면 곧바로 “오, 그러면 웹사이트 만드세요?” 혹은 “아, 그러면 프로그래머시군요?” 아니면 아주 공포스럽게도 “정말요? 제 노트북 좀 고쳐주실 수 있나요? 이거 갑자기 이상하게 안되고… 어쩌고 저쩌고…”라는 대답이 돌아온다.
 
엄밀히 이야기해서 필자는 많은 웹 애플리케이션을 개발해 봤지만 꼭 웹 개발자라고 할 순 없다. 지난 몇년간 수십만 줄의 코드를 작성했지만 스스로를 프로그래머라고 생각하지도 않는다. 프로그래머냐는 질문에 대해 필자는 “어려운 문제에 대한 우아한 솔루션을 개발한다”고 답변한다. 이 답변이야말로 대부분의 사람들이 이해못하는 세부사항에 얽매이지 않으면서도 필자가 매일 하는 일의 가장 정확한 묘사이기 때문이다.
 
사실 프로그래밍 언어 몇 가지를 어느 정도 알더라도 대부분의 IT 전문가들이 그 자체만으로 개발자는 아니다. 필자는 다양한 대규모 IT 개발 프로젝트에 참여해 짧게는 수주, 길게는 수개월씩 일했지만 그게 필자의 업무시간 대부분을 차지하는 것은 아니다. 솔직히 이야기해서 필자는 날마다 코드를 작성하지 않지만 어떤 문제를 처리하기 위한 툴을 개발할 필요가 있으면 바로 착수한다. 그럴 때마다 필자의 뇌가 특정 프로그래밍 언어로 재조직 되는 것 같은 느낌이 들기도 한다. (맞다. 좀 괴상한 기분이 든다)
 
교환의 툴

요점은 운영자들이 선택된 플랫폼의 스크립팅 언어를 어느 정도 알아야 한다는 것이다. 이상적으로는 언어 몇개 정도는 알면 좋다. 윈도우 플랫폼의 VB과 파워셸(PowerShell), *닉스상의 배시(Bash), 펄(Perl) 등이다. 이들은 문제 해결과 앞서 이야기한 우아한 솔루션을 위한 모든 종류의 가능성을 열어 준다. 수십만 줄에 달하는 거대 프로젝트를 담당할 것이 아니라면(물론 그럴수도 있지만) 대부분의 프로그램은 놀랄 정도로 짧다.
 
실제로 필자는 지금까지 사용해 온 네트워크 모니터링 서버를 체크하고 다양한 서비스와 그 서버에서 실행되는 패키지 소프트웨어를 지원하는 펄 스크립트의 양을 나기오스(Nagios)에서 칵티(Cacti)까지 추산해 봤다. 그 결과 1만5,000 줄의 코드가 53개 스크립트에 걸쳐 있는 것으로 나왔다. 평균 283줄의 코드가 스크립트마다 있는 셈이다. 더 검토해 보니 스크립트 3개가 5,000줄을 차지해 평균을 높여 놓았다. 10여개 스크립트는 고작 30~40줄에 불과했다.

이것이 바로 IT 관리자 코딩의 본질이다. 즉, IT 시스템 전반을 지배하는 작고 필수불가결한 툴을 고안하는 것이다.

예를 들어 기업에 FLEXlm 라이선싱을 추적할 방법이 없던 시절에 필자가 사용했던 펄 스크립트를 이야기해 보자. 당시에는 FLEXlm을 위한 서드파티 모니터링 툴 자체가 없었고 상용 라이선스 모니터링 애플리케이션의 성능도 신통치 않았다. 그래서 필자는 109줄에 불과한 펄 스크립트 안에 각각의 lmgrd(license manager daemon) 인스턴스를 쿼리하고 사용중인 라이선스의 수와 얼마나 많은 라이선스를 이용할 수 있는지 체크하는 기능을 넣었다. 라이선스 만료일을 결정하는 폴링 데몬(polling daemon)도 추가했다.

이 스크립트는 공유 메모리 공간에 펄 해시(Perl hash)로 저장된다. 그러면 고작 34줄짜리 컴패니언 스크립트(companion script)는 언제든 다른 어떤 프로세스에 소환돼 현재 사용중인 라이선스와 각 패키지의 라이선스 만료일까지 남은 기간을 산출한다. 이 스크립트는 라이선스의 만료일이 다가오면 이를 경고하고 그 데이터를 도식화하는 칵티에 RRD를 추가하기 위한 나기오스 플러그인에도 사용됐다.
 
그와 함께 필자는 동일한 데이터에 웹 앱을 덧붙여 개발자들이 빠르게 여러 툴들의 라이선스 상태를 확인하고 누가 그 툴을 이용하는지 정확히 볼 수 있게 해 그들이 필요에 따라 라이선스 해제를 요청할 수 있게 했다. 이 모든 것들을 144줄의 펄과 모두 합쳐 300줄 정도에 불과한 확장 앱, 플러그인으로 구현했다.
 
100줄에 담긴 마음의 평화
이것이 바로 관리자가 필요에 따라 사용할 수 있어야 하는 코딩이다. 이것은 천직도 아니고 핵심 임무도 아니지만 많은 문제에 직면할 때 강력한 무기가 돼 준다. 필자가 하는 모든 일이 펄을 쓰는 것이었다면 진작에 미쳐 버렸을 것이다. 아마 프로그래머들은 어떤 느낌일지 짐작할 것이다. 필자에게 펄, PHP, 심지어 배시 스크립팅까지 업무 환경에서 절대적으로 필요하지만 내 정신적 노력의 주요 관심 대상이 아니라 그저 칼, 톱, 망치 정도의 도구인 것이다.
 
확실히 해두자면 이런 잡부식의 코딩으로 해당 언어의 전문가가 되기는 힘들다. 꼼꼼하고 안전한 코드를 쓰는 것은 중요하지만 고수들은 더 많은 작업을 더 깔끔한 방식으로 구현하는 코드 작성 방법을 금새 발견해 낸다. 그러나 스크립트가 자체적으로 문제가 되지 않고 기능을 충실히 처리하는 한 고수의 수준까지는 필요치 않다.
 
필자는 훌륭한 윈도우나 리눅스 운영자의 기본이 스크립팅에 대한 깊은 이해와 그 솜씨를 어떻게 활용할 지 아는 것에서 시작한다고 굳게 믿고 있다. 만약 당신이 당신에게 주어진 코드 안에 갇혀서 일하며 스스로를 제한시킨다면 많은 문제들을 해결하는데 있어서 더 많은 소프트웨어를 구입하는 것 밖에 생각해낼 수 없을 것이다. 그렇다고 해도 모든 문제가 해결되는 것은 아니다. 결국 문제의 해법을 찾는 과정에서 무엇보다도 필요한 것은 당신 스스로 해결하는 능력이다. editor@idg.co.kr



2012.10.26

글로벌 컬럼 | IT운영자가 코딩을 할 수 있어야 하는 이유

Paul Venezia | InfoWorld
우리 모두는 답하기 곤란한 질문을 자주 받곤 한다. "무슨 일 하세요?" 그런 질문에 보통 필자는 "컴퓨터 쪽에서 일해요"라고 답한다. 질문자가 무엇을 떠올리는지 보기 위해서다. 그러면 곧바로 “오, 그러면 웹사이트 만드세요?” 혹은 “아, 그러면 프로그래머시군요?” 아니면 아주 공포스럽게도 “정말요? 제 노트북 좀 고쳐주실 수 있나요? 이거 갑자기 이상하게 안되고… 어쩌고 저쩌고…”라는 대답이 돌아온다.
 
엄밀히 이야기해서 필자는 많은 웹 애플리케이션을 개발해 봤지만 꼭 웹 개발자라고 할 순 없다. 지난 몇년간 수십만 줄의 코드를 작성했지만 스스로를 프로그래머라고 생각하지도 않는다. 프로그래머냐는 질문에 대해 필자는 “어려운 문제에 대한 우아한 솔루션을 개발한다”고 답변한다. 이 답변이야말로 대부분의 사람들이 이해못하는 세부사항에 얽매이지 않으면서도 필자가 매일 하는 일의 가장 정확한 묘사이기 때문이다.
 
사실 프로그래밍 언어 몇 가지를 어느 정도 알더라도 대부분의 IT 전문가들이 그 자체만으로 개발자는 아니다. 필자는 다양한 대규모 IT 개발 프로젝트에 참여해 짧게는 수주, 길게는 수개월씩 일했지만 그게 필자의 업무시간 대부분을 차지하는 것은 아니다. 솔직히 이야기해서 필자는 날마다 코드를 작성하지 않지만 어떤 문제를 처리하기 위한 툴을 개발할 필요가 있으면 바로 착수한다. 그럴 때마다 필자의 뇌가 특정 프로그래밍 언어로 재조직 되는 것 같은 느낌이 들기도 한다. (맞다. 좀 괴상한 기분이 든다)
 
교환의 툴

요점은 운영자들이 선택된 플랫폼의 스크립팅 언어를 어느 정도 알아야 한다는 것이다. 이상적으로는 언어 몇개 정도는 알면 좋다. 윈도우 플랫폼의 VB과 파워셸(PowerShell), *닉스상의 배시(Bash), 펄(Perl) 등이다. 이들은 문제 해결과 앞서 이야기한 우아한 솔루션을 위한 모든 종류의 가능성을 열어 준다. 수십만 줄에 달하는 거대 프로젝트를 담당할 것이 아니라면(물론 그럴수도 있지만) 대부분의 프로그램은 놀랄 정도로 짧다.
 
실제로 필자는 지금까지 사용해 온 네트워크 모니터링 서버를 체크하고 다양한 서비스와 그 서버에서 실행되는 패키지 소프트웨어를 지원하는 펄 스크립트의 양을 나기오스(Nagios)에서 칵티(Cacti)까지 추산해 봤다. 그 결과 1만5,000 줄의 코드가 53개 스크립트에 걸쳐 있는 것으로 나왔다. 평균 283줄의 코드가 스크립트마다 있는 셈이다. 더 검토해 보니 스크립트 3개가 5,000줄을 차지해 평균을 높여 놓았다. 10여개 스크립트는 고작 30~40줄에 불과했다.

이것이 바로 IT 관리자 코딩의 본질이다. 즉, IT 시스템 전반을 지배하는 작고 필수불가결한 툴을 고안하는 것이다.

예를 들어 기업에 FLEXlm 라이선싱을 추적할 방법이 없던 시절에 필자가 사용했던 펄 스크립트를 이야기해 보자. 당시에는 FLEXlm을 위한 서드파티 모니터링 툴 자체가 없었고 상용 라이선스 모니터링 애플리케이션의 성능도 신통치 않았다. 그래서 필자는 109줄에 불과한 펄 스크립트 안에 각각의 lmgrd(license manager daemon) 인스턴스를 쿼리하고 사용중인 라이선스의 수와 얼마나 많은 라이선스를 이용할 수 있는지 체크하는 기능을 넣었다. 라이선스 만료일을 결정하는 폴링 데몬(polling daemon)도 추가했다.

이 스크립트는 공유 메모리 공간에 펄 해시(Perl hash)로 저장된다. 그러면 고작 34줄짜리 컴패니언 스크립트(companion script)는 언제든 다른 어떤 프로세스에 소환돼 현재 사용중인 라이선스와 각 패키지의 라이선스 만료일까지 남은 기간을 산출한다. 이 스크립트는 라이선스의 만료일이 다가오면 이를 경고하고 그 데이터를 도식화하는 칵티에 RRD를 추가하기 위한 나기오스 플러그인에도 사용됐다.
 
그와 함께 필자는 동일한 데이터에 웹 앱을 덧붙여 개발자들이 빠르게 여러 툴들의 라이선스 상태를 확인하고 누가 그 툴을 이용하는지 정확히 볼 수 있게 해 그들이 필요에 따라 라이선스 해제를 요청할 수 있게 했다. 이 모든 것들을 144줄의 펄과 모두 합쳐 300줄 정도에 불과한 확장 앱, 플러그인으로 구현했다.
 
100줄에 담긴 마음의 평화
이것이 바로 관리자가 필요에 따라 사용할 수 있어야 하는 코딩이다. 이것은 천직도 아니고 핵심 임무도 아니지만 많은 문제에 직면할 때 강력한 무기가 돼 준다. 필자가 하는 모든 일이 펄을 쓰는 것이었다면 진작에 미쳐 버렸을 것이다. 아마 프로그래머들은 어떤 느낌일지 짐작할 것이다. 필자에게 펄, PHP, 심지어 배시 스크립팅까지 업무 환경에서 절대적으로 필요하지만 내 정신적 노력의 주요 관심 대상이 아니라 그저 칼, 톱, 망치 정도의 도구인 것이다.
 
확실히 해두자면 이런 잡부식의 코딩으로 해당 언어의 전문가가 되기는 힘들다. 꼼꼼하고 안전한 코드를 쓰는 것은 중요하지만 고수들은 더 많은 작업을 더 깔끔한 방식으로 구현하는 코드 작성 방법을 금새 발견해 낸다. 그러나 스크립트가 자체적으로 문제가 되지 않고 기능을 충실히 처리하는 한 고수의 수준까지는 필요치 않다.
 
필자는 훌륭한 윈도우나 리눅스 운영자의 기본이 스크립팅에 대한 깊은 이해와 그 솜씨를 어떻게 활용할 지 아는 것에서 시작한다고 굳게 믿고 있다. 만약 당신이 당신에게 주어진 코드 안에 갇혀서 일하며 스스로를 제한시킨다면 많은 문제들을 해결하는데 있어서 더 많은 소프트웨어를 구입하는 것 밖에 생각해낼 수 없을 것이다. 그렇다고 해도 모든 문제가 해결되는 것은 아니다. 결국 문제의 해법을 찾는 과정에서 무엇보다도 필요한 것은 당신 스스로 해결하는 능력이다. editor@idg.co.kr

X