서버 제어 시스템에 대한 썰

내 첫 IDE는 MS-DOS용 터보-C 2.0이다.

vi 정도는 아니었어도, 윈도우 기반 요즘 IDE와는 비교도 안될만큼 불편했다.

그런 환경에서 Visual Studio 5.0을 썼을때의 환경은 말그대로, 환호가 절로 나왔으며, MFC의 App Wizard는 신이 내린 하사품 같았다.

그렇다보니 GUI환경에 대한 동경은 갈수록 커져만갔을 뿐... 글씨만 줄창 보게되는 CUI (Console User Interface)에 대한 내 이미지는 "직관적이지 않고 어렵다" 였다.

알바 경험, 외주 경험을 다 제끼고 나면 나는 온라인 게임만으로 일해왔다.

내가 상업적인 프로젝트에 외주가 아닌, 직원으로 일한 것은 싸이미디어사의 믹스마스터였다.

당시 서버는 리눅스 서버였는데, 클라이언트 프로그래머였던 나로썬 점검시 심심하다고 나를 부르는 SE형 옆에서 서버 20대가량을 제어하는 터미널 창만 봐도 눈이 휘둥그레 졌었다.

여러개 떠 있는 세션에 같은 명령을 보내는 스크립트로 패치하시곤 했는데, 내 입장에서는 굉장히 신기한 작업이었다.

물론, 그저 신기했을 뿐 딱히 멋져보이진 않았다.

그러던 내가... 그 일로 얼마 지나지 않아 어쩌다보니 서버프로그래머가 됐다.

서버 프로그래머가 되고 서비스를 하다보니... 하... 먼놈의 관리해야 될 머신이 이렇게 많은겨....-_-

관리할 머신의 수는 팀마다 달랐고, 국가마다 달랐지만 최소 10대 가량은 관리해왔다고 볼 수 있다.

내 로컬에서 개발 머신까지의 적용은 그나마 괜찮다.

문제는 대부분 Local -> Develop -> QA -> Live 이런식으로 deploy 되는 과정에서, 실수가 유발됐다.

사실 점검은 국가마다 다르지만, 대게 새벽시간에 이루어지곤 한다.

유저가 가장 적은 시간대를 선택하다보니 그렇게 되기도 하고, 해당 국가의 시간에 맞추다보니 그렇게 되기도 하고.

그런 시간에 정신이 말짱해, 모든 프로세스를 실수 안하는 사람이 있나?

만약 있다해도 적어도 난 아니다.

작업은 가능한한 자동화 되어있어야했고, 그를 위한 서버 제어 시스템은 필수 였다.

내가 본 첫 서버 제어 시스템은 네X위즈사의 피X 서버 제어 시스템이었는데, 실질적으로 내가 사용한 것은 아니라 대략의 기능들과 어떠한 느낌인지만 알 수 있었다.

해당 서버 제어 시스템으로 관리되던 것은, 내가 클베때부터 합류했던 프로젝트인 네오액X의 포키포X인데, 

당시만해도 서버 프로그래머가 된지 얼마 되지 않았고, 업무량 자체가 절대적으로 많아 생각의 폭도 좁았지만, 그런 고민을 할 여유가 많지 않았다.

헌데 그렇게 바쁠 수록 실수는 나오기 마련.

패치할 서버를 FTP에 올려놓고, 패치 메일을 빼먹는 다거나, 업로드한 파일 경로를 잘못 메일에 기록한다거나...

특히 긴급 패치에 새로 나온 바이너리를 안올리고, 테스트하던 바이너리를 올린다거나 하는 등의 다급할때의 실수는 대부분 수작업으로 인한 파생 효과였다.

그래서 필요했던 것은 두가지였다.

1. 빌드 -> 배포까지의 자동화.

2. 배포 -> 실제 패치까지의 자동화

이렇게 되고나니 한결 편하게 패치를 진행할 수 있다.

서버가 몇대건 간에 말이다.

여기서 추가적으로 필요한 작업이 있다.

바로 서버 모니터링. 서버 제어 시스템의 핵심중 하나다.

서버가 죽었는지, 제대로 떴는지 등의 상태 체크를 모니터링 업체에만 맡길 순 없다. (실제로 모니터링 업체에 맡기는 경우도 드물고)

이런 기능을 개발하면서부터, 개발자의 시간을 아끼기 위해, 또 실수를 줄이기 위해 선 시간 투자에 대한 눈을 조금 떴다고 할까?

효율성이 떨어진 자동화나, 코드 생성기 작업도 없었던 것은 아니지만, 많은 작업들이 결과적으로 시간을 아꼈다.

애초에 덜렁대고 급한 성격인 나로썬, 급할 수록 돌아가지 못하다보니 잔실수를 자꾸 하게 됐었는데, 이를 자동화로써 해결하면서 큰 이득을 보게 됐다.

사실 과거에는 이런 솔루션 파는 회사 없나라는 고민을 좀 했었다. 범용 서버 제어 시스템...충분히 있을법하지 않은가?

요즘 보면 모바일 서버가 웹 기반으로 돌아섰고, AWS 등의 클라우드 기반 서버를 쓰다보니 자동화가 강제되는 면까지 있어, 이를 해낸 여러 사례가 들려오고 있다.

특히 cookbook같은 개념도 머릿속으로 그려봤던 개념이, 실제로 많이 실용화 된 것을 보자니 내가 해온 것보다 적은 공수로 실시간 서버 추가/제거를 해내는 모습을 보면 부럽기도 하면서, 뿌듯한 면도 있다. 당연히 앞으로 배울점도 많고.

다른 자동화에 대한 의지를 가진 분들의 생각은 다는 모르겠다만, 적어도 내 기본 전제는 "내가 편할려고", "똑같은 작업 여러번 하기 싫어서"다.

또 내가 당장 사무실에 없다해도, 혹은 누가 해도 되는 일로 만들기 위해서이기도 하고.

자동화도 하다보니 좀 늘더라. 특히 스크립트 언어를 적극 사용하니 좀 더 수월하기도 하고.

서비스 질이 갈수록 좋아지고 있다. 클라우드 서비스를 기반으로한 무인 원격 서버 증감도 이뤄지고 있더라.

요즘 트렌드를 보자면, 서버 제어 시스템을 앞으로 직접 구축하거나 보완하는 일은 많진 않을거라 예상은 되지만.... 서버 프로그래머로써 3번째 회사에서, 3번의 서버 제어 시스템을 담당 해본 입장에서, 이런 시스템을 구축하면 할 수록 업무 시간을 벌 수 있다.

node.js 등의 리눅스 기반 웹서버로써 구동하고자 하는 많은 회사들도 그렇게 하고 있다는 얘기도 들려오고 있고. 내가 한 많은 작업들이 AWS등에선 기본 지원하는 기능이기도하다.

조금 허탈하기도 하지만, 뭐 기술이란게 다 그런거 아닐까? 여하튼 좋은 모양새로 업계가 발전하고 있는것은 아주 맘에 든다. 

몇몇 분들을 보면 아쉬운 것이... 어째서 코드의 중복은 싫어하면서, 작업의 반복은 수긍하고 익숙해짐으로써 해소하려하는 걸까? 작업의 반복도 충분히 간소화하고 제거할 수 있다. 

개선할 수 있는 많은 것을 개선하고, 낭비되는 시간을 줄여야 진짜 즐거운 작업을 할 시간을 벌 수 있다. 우린 엔지니어다. 기술로 커버할 수 있는 것이 아주 많다. 조금씩만 더 효율적으로 일하도록 노력해보자.