오늘은 특별히 쓰고 싶은 내용이 없어서, 과거 얘기를 해볼까 합니다. 제가 다니는 회사가 군 사업을 주력으로 하고있기 때문에, 폐쇄망에서 일하는 경우가 매우 많습니다. 초급 엔지니어 시절에도, 사업 수행을 지원하는 수행원 시절에도, TA와 PL로서 사업을 직접 수행하는 현재에도, 저는 늘 폐쇄망에서 고군분투하고 있습니다. 인터넷과 전화통화가 안되는 환경이란.. 어쩌면 엔지니어들에게는 무덤이 아닌가 하는 생각이 듭니다.
모든 시절에 고충은 있었지만, TA 역할을 수행하는 현재 폐쇄망에서의 사업 수행이 더욱 어렵게만 느껴집니다. 외부 환경에서 rpm, yum 등의 명령어를 통해 패키지를 받을 땐 인터넷의 소중함을 모르고 있었는데, 막상 직접 패키지를 손수 밀어넣고, 의존성을 하나 하나 체크하다 보니 인터넷이란 정말 소중한 것이구나 새삼 깨닫습니다.
Tip : 군 인트라넷 내부에 오픈소스, 서버 패키지, 개발 도구 및 라이브러리 등을 다운받을 수 있는 허브를 개발하고 그 형상을 체계적으로 관리한다면 사업할 때 정말 좋을 것 같다는 개인적인 생각입니다. 아마 군 입대하는 컴공 학생 분들에게도 도움이 되지 않을까요? 생각만해도 좋네요..
1. 분리발주 SW와 만남
RFP 상에서 분리발주 대상 SW는 사전에 식별했었고, 때가 되면 지원해달라는 요청이 오겠지~ 라는 마음으로 계획을 이행하다보니 문득 SW 설치에 요구되는 환경이 폐쇄망에서 마련되기 어려울 수 있을텐데 하는 생각이 들게 되었습니다. 그때는 사업 초반이었고 대상 SW가 그리 중요한 품목은 아니라 판단 되었기에 발주자도, PM도 그것을 리스크로 관리하지는 않고 있었죠.
저는 당시 인프라를 관리하는 입장으로서 이 부분이 매우 염려되기 시작했습니다. 엔지니어 생활도 꽤 오래했고, 실무적으로 접근했을때, SW의 설치 호환성 이슈는 너무나 흔하게 경험한 것 중 하나였기 때문입니다. ‘혹시 분리발주 대상 SW 엔지니어분 연락처 좀 알 수 있을까요?’ 제가 PM과 고객에게 요청한 내용이었습니다. 사전에 필요한 것은 없냐, 환경은 어떻게 준비해주어야 하냐에 대한 문의를 하고 싶었죠. 대답은 역시 작업 일정이 한참 뒤에나 잡혀있으니, 그 전에 알려주겠다는 것이었고, 염려하는 마음은 있었지만, 모두의 결정에 따르기로 했습니다.
그러다 본 작업 이틀 전에 한 장의 문서를 건네 받았습니다. 40개 가량의 패키지 목록이었죠. “백업 SW 엔지니어 분이 서버에 설치하기 위해 필요한 패키지라고 정리해서 보내주신겁니다.” 저의 염려가 현실이 되는 순간이었습니다. “이틀 뒤 오전까지 대상 서버에 설치해주실 수 있죠?”
2. 분리발주 SW 엔지니어의 등장
사내 Ubuntu, Redhat 서버에서 패키지를 열심히 인스톨하고, 긁어모아 CD 형태로 구워 반입했고, 대상 서버에 패키지를 밀어 넣는데, 생각보다 잘 안되는 것도 많은 상황이었습니다. 받은 필요 패키지 목록에 의존성과 OS 버전은 고려하지 않은 철지난 패키지 버전이 수두룩했고, OS 별 구분도 매우 불분명했죠. 저는 처음으로 생전 본 적 없는 엔지니어를 원망하게 됩니다. 같이 지원하는 입장에 이런 문서란 썩 달갑지 못했죠. 그래도 최대한 되는대로 밀어넣고, 정 설치가 안되는 패키지는 체크하여 분리해두었습니다.
한참 방화벽 정책을 검토하던 다음날 시각, 분리발주 엔지니어가 등장했습니다. 저는 자초지종 설치가 된 패키지와 그렇지 못한 패키지에 대해 안내했고, 엔지니어는 본격적인 설치 작업에 들어갔습니다. 역시 결과는 대실패였습니다. 대상 서버 중 한 군데도 설치가 진행되지 못했고, 엔지니어는 원인을 찾아 골똘히 로그를 분석하기 시작했습니다. 다행히 안드로이드 폰을 소지하셔서 인터넷 검색과 전화 찬스를 사용하실 수 있었지만, 끝내 설치가 불가능한 근본적인 원인까지 식별하지는 못했습니다.
Tip : 군에서는 MDM 설치 후 핸드폰 반입이 가능합니다. 하지만 이는 안드로이드 한정이고, 애플OS는 MDM 삭제가 자유로워 반입할 수 없도록 되어있는 부대가 대부분입니다.
우리는 그 원인을 일부 필수 패키지의 설치 부재로 생각하고, 보완하여 준비하기로 협의했습니다. 해당 패키지의 설치가 가능하도록 준비하는 것으로 다음 약속을 기약했죠. 그리고 다음, 또 그 다음, 다음이 되기까지 필요한 패키지는 전부 반입해서 설치하고, 준비했지만 정작 SW 설치는 수행되지 못했습니다. 그리고 그 원인은 여전히 파악이 불가능했습니다.
문득 궁금해서 물었습니다. “다른 군에서는 이런 경우 어떻게 진행하셨었나요?” 예상은 했지만, 저를 초연하게하는 대답이 돌아왔습니다. “제가 폐쇄망은 처음이라..”
3. 유도리 등장
단일 지원 예정이었던 엔지니어가 5일을 연속 내리 출입하자, 발주자 측에서 더이상 안되겠다고 판단했는지 외부에 노출된 메일서버에서 패키지를 다운받아, 내부 서버에 미러서버 형태로 제공하게 해주겠다는 제안을 건내왔습니다. 물론 패키지는 모두 무결성 검사를 마쳐야하지만, 희망이 보이지 않던 저희로서 매우 감사한 제안이었죠.
저는 그 엔지니어가 그렇게 밝고, 수다스러운 분인줄 몰랐습니다. 서버 리포지토리에 다운받은 것들을 대상 서버에 전부 밀어넣고 SW 설치를 진행하자 거짓말처럼 설치가 완료되기 시작했습니다. 심지어 본 설치는 30분도 채 걸리지 않더군요. “저희 SW는 이런~이런~ 기능이 있구요~ 장애시에~” 얼마나 후련할까요? 알죠 저희도, 그 당시의 쾌감과 성취감은 이루 말할 수 없다는 것을요. 잠깐이지만 저도 덩달아 흐믓했습니다. 왜 잠깐이냐 하면요, 바로 아직 설치되지 않은 다음 분리발주 SW가 남아있었기 때문이죠.
아무튼 필요할 때 발휘되는 무적의 유도리로 인해 당시 상황은 그렇게 일단락 되었습니다. 쉽지 않은 결정이셨을텐데 리스크를 감수하고, 편의를 봐주신 발주자께 다시 한번 감사한 마음이 드는 지금입니다.
4. 끝으로
이후 다른 분리발주 SW도 설치 과정에서 정말 이상하리만치 문제가 많았습니다. 윈도우 기반 설치 제품이라 리눅스처럼 패키지 의존성에 영향받지 않음에도 불구하고 말이죠. 그 엔지니어분도 수차례 방문하시더니, 결국 연구 소장님까지 대동하여 문제 해결을 도와주신 기억이 납니다. 그분도 같은 말씀을 하셨어요. “제가 이런 환경은 진짜 처음이라서..”
시간이 지나 테스트를 완수하고, 기술이전을 준비하며 사업은 아무쪼록 잘 마무리 되었습니다. 해당 사업은 폐쇄망에서 분리발주를 수행하는 것은 정말 철저한 준비가 요구되는 것이구나 라는 것을 깨닫는 계기가 되어주었고, 감사하게도 저의 Lesson Learned에 기록되어, 양분이 되어주었죠. 시간이 꽤 지난 지금이지만 아직까지도 RFP 상에서 폐쇄망 + 분리발주 조합을 보면 흠칫 흠칫 놀라곤 합니다.
만약 다시 대응할 기회가 주어진다면, 그때와는 다를까요?