잡담

rabbit vs. hare

둘 다 토끼지만 약간 다르다.

crocodile vs. alligator

둘 다 악어지만 약간 다르다.

turtle vs. tortoise

둘 다 거북이지만 약간 다르다.

관리 시스템의 딜레마

관리 시스템이라는 것들은 망관리(NMS: Network Management System)라던지 서버관리(SMS: Server Management System), APM(Application Performance Management)류의 관리 시스템을 말한다.

이 바닥에서 일을 하다 보면 같은 일이라도 어렵게 만드는 무언가가 있다. 일종의 편견 같은 것들인데, 자세히 생각해 보지 않아서 생기는 일들이다.

1. 관리 시스템의 중요도는 그 관리 시스템이 관리하는 대상만큼이나 중요하다.

이건 이렇게 써놓고 보면 그런 것도 같긴 하겠지만 실제로 돈을 쥐고 있는 '갑' 입장에서는 그렇지 않을 수 있다. 예를 들어 무슨무슨 서비스를 위해 서버를 도입하고 네트워크를 설치했다고 하면 비용 절감을 위해 불필요한 것들은 최소한으로 하기 위해 노력할 텐데, 문제는 이 관리 시스템은 이도 저도 아닌 어중간한 위치라는 것이다.

먼저, 근본적으로 관리 시스템은 서비스 시스템이 아니므로 관리시스템의 availability는 낮아도 될 것이란 생각이 있을 수 있다. 일견 맞는 듯 해 보이는 이 말은 큰 모순이 있다. 관리 시스템의 availability는 관리 대상보다 높아야 하기 때문이다. 모든 서비스 시스템이 죽는 순간에도 관리 시스템은 살아서 시스템이 죽어간다는 것을 관리자에게 보고해야 하기 때문이다. 이걸 우습게 보고 관리 시스템을 구축했다간 없느니만 못한 관리 시스템이 될 것이다. 이게 무슨 말인고 하니, 정작 서비스 시스템이 죽었을 때, 그게 왜 죽었는지, 어떻게 죽었는지 알 도리가 없다는 것이고, 이것은 그 관리 시스템의 존재 가치가 없다는 의미다. 고로, 관리 시스템의 availability는 많이 양보해도 최소한 관리 대상 시스템 보다는 더 높아야 한다.

결국 돈이 더 들어간다는 것인데, 그 돈을 들일 '갑'을 설득하는 것은 그리 쉽지 않다. 아무리 좋은 관리 시스템을 들인다고 하더라도 장애확률만을 줄여줄 뿐 근본적으로 막지는 못하는 데다가 기준은 선형적으로 올라가고 비용은 비선형적으로 올라가기 때문이다.

2. black-box vs. clear-box

소프트웨어 개발할 때 모듈을 블랙박스로 놓고 인터페이스를 명확히 하여 불필요한 coupling을 없앰으로 소프트웨어 개선 시에 impact를 최소화하는 것은 귀가 따갑게 들어서 알고 있을 것이다. Clear-box는 블랙박스의 반대 개념으로 생각해본 용어이긴 하지만 결국 관리 시스템이란건 그렇게 만들어놓은 시스템을 관리자에게 투명하게 보여줘야 한다는 개념이다. 그렇게 해야 할 뿐더러 원인 분석 같이 장애나 문제 원인을 엮어서 분석을 해 줘야 할 필요도 있다. 마치 사람이 겉으로 보기엔 멀쩡한데 혈압 재고 피검사 소변검사를 거쳐 병을 알아내고 평소에 습관 등 모든 관련 정보를 종합하여 병을 찾아내고, 그 병을 해결해야 하는 의사 처럼 관리 대상에 발생한 문제에 대한 해결책을 내 놔야 하는 것이다.

여기에서의 딜레마는 블랙박스 형태로 설계된 소프트웨어(혹은 시스템)을 완전히 반대 개념으로 접근해야 한다는 것이고, 결국 그건 돈문제로 귀결이 된다. 겉으로 들어나는 서비스는 전혀 변화가 없는데, 특정 모듈을 변경할 경우 그것을 clear-box 형태로 관리하던 관리 시스템은 폭풍을 맞게 된다. 게다가 이건 구축 시에 들어가는 비용이 아니라 운용중에 발생하는 비용이므로 예산을 맞추기가 쉽지가 않다. 구축시에야 비용이 많이 들어가면 사업을 포기할 수도 있지만, 운용중에는 사업포기가 쉽지 않는 오도 가도 못하는 상황이 벌어지기도 한다.

3. Stability, Robustness, Integrity, Efficiency...

이 모든 것들이 관리시스템에는 필수 사항이다. 하나 하나가 제대로 하려면 애시당초 설계부터 개념적으로 완성이 되어야 하는 것들이다. Stability: 관리 대상 보다는 더 stable해야 한다. 앞서 설명한대로... Robustness: 모든 상황을 예측하긴 불가능하므로 어떠한 상황이라고 하더라도 대략 패낵상태로 가면 안되고 항상 'under-control'이어야 한다. Integrity: 오탐은 상황을 악화시킬 뿐이며 차라리 탐지가 불가능하다고 알려지느니만 못하다. Efficiency: 어떠한 상황이 오더라도 대상 시스템은 서비스가 최우선이므로 대상 시스템에 부하를 주지 않도록 설계되어야 한다.

어느 하나도 쉽게 넘길 수 없는 요구사항들이다. 모두 가능할 수 있지만 역시 비용문제가 곁들여지면 타협점을 찾아야 한다. 모두 만족시키는 타협점은 찾기 힘들다.

4. 잘해야 본전

만약 시스템에 별 문제가 발생하지 않았다면 본전치기, 시스템에 문제가 발생하면 손해다. 모든 관리 시스템은 잘 해야 본전인 일을 할 뿐이다. 하지만 너무 잘해도 문제가 될 수 있다. 가장 시간 관리를 잘 하는 사람은 한 번도 비행기를 놓치지 않은 사람이 아니란 것이다. 이 사람은 비행기를 놓치지 않기 위해 많은 시간을 비행기 앞에서 기다렸을 뿐이다. 만약 관리 시스템이 너무도 관리가 완벽하여 시스템에 사소한 문제도 발생하지 않았다면 그 시스템은 과잉투자되었다고 판단될 수 있고, 다음 투자 시기에 제대로 된 투자비를 받지 못할 수도 있다.

정작 가장 밸런싱이 잘 된 관리 시스템은 크지 않은 범위 내에서 장애가 발생하고 쉽게 해결하여 관리 시스템의 존재를 인식시켜줌과 동시에 대형장애는 발생을 하지 않아 관리시스템을 갈아치울 마음이 들지 않도록 하는 것이다. 이 밸런싱은 예술 분야에 속한다.

결론

늘 돈이 부족할 수 밖에 없고, 돈이 충분하다고 해도 완전해지지 않는 시스템이 바로 관리 시스템이다. 그렇다고 해서 암울한 것만도 아닌건 이게 필요하다는 것은 대략적으로 인식이 돼 있다는 사실이다. 희망적인 것은 관리 시스템이라는 것이 구조적으로 복잡하지 않다는 것이다. 이 사실은 위 요구사항들을 어느 정도 만족시켜줄 가능성을 높여준다.


...
..
.

더 암울한 분야는 보안 분야다.

예언 적중 - 자동차 홀짝제와 듀얼 번호판

본인이 2006년도에 예언을 해 놓은 자동차 요일제와 관련 포스팅(자동차 요일제)을 보시라!

정확히 토씨하나 틀리지 않고 그대로 적용되지 않는가? 오일쇼크에 준하는 사태가 벌어졌고, 그로 인해 홀짝제 시행한다는 내용까지... 그리고 한 걸음 더 나아가서 차 두 대 사용하는 것과 거기서 한걸음 더 나아가서 듀얼 번호판까지 이야기가 나왔다.

아직 듀얼 번호판은 아니지만 그러한 기운이 감도는 기사가 나왔다.

이제 남은건 듀얼 번호판이다.


...
..
.


어쨌거나 자동차 홀짝제는 언발에 오줌누기라는 것이고 그걸 어떻게 포장을 했던지 간에 기한 없이 시행하는 것은 문제가 크다. 조만간 자동차를 사용하는 사람들은 자신이 사용하는 자동차의 가치가 반으로 줄어들었다는 것을 알아챌 것이기 때문이다. 듀얼번호판이 충분히 가능한 시나리오라는 것은 비로 이러한 이유이다. 차의 가치를 온전히 끌어내기 위해서는 듀얼번호판은 필수, 여기서 승자는 자동차 등록세를 걷어가는 정부, 패자는 졸지에 세금만 두배로 내는 자동차 소유주, 두 대 팔릴거 한대 파는 자동차 회사, 그리고 쓸데없는 일이 늘어난 공무원들이겠다.

일이 잘못되어 가는 과정

예전에 순진했던 그 옛날 시절에는 정말로 사필귀정이라는 말을 믿었더랬다. 차차 세월이 흘러 지금에 이르러서는 그 말을 믿지 못하게 되었다. 뭐, 별다른건 아니고 그놈의 '정(正)' 에서 올바르다는 의미가 뭔지가 참 애매하다는 것이다. 애초에 인간으로써는 옳고 그름을 판단할 능력이 없기 때문이다. 인간은 단지 말의 앞뒤가 맞다/맞지 않다 정도만 판별할 수 없다는 것을 깨달은 후에는 이러한 옳다는 것에 대해 너무 믿음을 깊게 갖지 않는 편이 타당하다고 생각하고 있다.

큰 사업은, 사실 일개 인간의 힘으로는 어디로 갈지 예측하기가 무지 어렵다. 이번에 진행중인 사업도 큰 사업이다. 사업 자체에 거대 음모나 비리가 있다는 느낌은 들지 않고 추진 중인 진행자들도 각각을 놓고 봤을때는 그다지 큰 문제점을 찾을 수 없다. 즉, 각각의 단위 주체들은 각 주체들 나름대로 자신의 지식과 경험을 토대로 합리적인 판단을 한다고 보여진다. 그런데, 나오는 결과로만 보았을 때는 최선의 결과와는 거리가 한참 멀다.

일단 발주처를 보자면, 틀림없이 그들은 돈이 있다. (민자 사업이라고 하더라도 10년간 할부금을 대줄 돈은 있는 거다) 그리고 요구사항이 있다. 하지만 가장 큰 문제라고 할 수 있는 것이... 그들은 지식과 경험이 별로 없다. 사실 이건 당연할 수 있다. 그들은 자기들이 지식이 없으니 돈으로 사려고하는게 아닌가? 당연하긴 하지만 크나큰 문제의 시작이 바로 여기에 있다. 일단 자기네들의 요구사항을 명확히 기술할 수가 없는게 모든 스토리의 시작이다.

앞서 이야기 했듯이 발주처의 지식이 얕으므로 이 기본설계를 용역을 통해 완료했다. 당연한 일이긴 하다. 용역업체는 발주처의 요구사항을 가지고 기본설계를 마련했지만 어디까지나 회사는 이익을 추구하는 집단. 업체의 욕심이 잔뜩 들어간 기본설계가 나왔다.

발주처는 지식이 없다뿐이지 업체의 욕심이 들어갔다는 사실을 모를리 없다. 다만 어느 부분인지를 모를 뿐이다. 결론은 늘 그렇듯 당연하게 제안요청서(RFP)를 더욱더 모호하게 적는 방법을 택한 후 모든 것을 제안서를 평가할 때 결정한다고 하는 것이다.

이 정도로 큰 사업은 당연히 공정한 경쟁을 해야 한다. 따라서 공고에서부터 시작해서 벤치마크, 제안서 평가가 공정하게 이루어져야 한다. 이 룰에 따라 벤치마크는 (거의)기계적으로 돌리고 제안서 평가는 이익을 대변하지 않는 사람들이 많은 풀에서 평가자를 랜덤하게 뽑아서 하게 된다. 결론적으로 말하면 이 사업을 잘 모르는 (쉽게 말해 이 사업에 대한 이해도가 높지 않고 사업에 대한 절실성이 떨어지는) 사람들이 단지 자신의 기준 (여기서는 대부분 교수...급들)에 의해 평가가 될 것이 뻔하다. 이것도 '공정한' 평가를 해야 하는 입장에서는 무지무지 당연하지만 앞서 틀어지기 시작한 비틀림 -- 요구사항의 불명확성 -- 때문에 모든 결과는 알 수 없게 돼 버린다.

다음으로 확실히 대못을 박아버린 계기는 바로 민자사업이기 때문에 관례상 해온 제안 형식 때문이다. VE(Value Engineering)이라는 제안형식인데, 이 형식은 이론적으로는 그럴듯 하다. 기본설계를 바탕으로 보다 더 나은 제안을 할 수 있으면 하되, 그 효과는 정량적으로 분석하는 것을 골자로 한다. 말이 쉽지 실제 VE 제안서란 놈을 본 사람은 그 제안서란 것이 녹녹치 않음을 알 수 있다. 일단 기본설계가 완벽해서 그냥 그 설계대로 진행을 하는데 아무런 이상이 없음을 전제로 해야 하는데, 앞서 이야기한 대로 기본설계는 단지 희망사항일 뿐인 IT업계에서는 제안서 제작 자체를 막막하게 하는 것 외에는 효과가 없었다.

이렇게 모호한 요구사항, 부실하고 욕심이 들어간 기본설계, 헷갈리는 제안 양식, 뭘 평가할지 모를 평가위원들....

그런데 이런 것들을 싸악 제거하고 그 동안 제안서 쓰려고 익혀뒀던 발주처의 상황을 고려해 보면 같은 예산이면 무지무지 좋은 환경을 구축해 줄 수 있다. 다만... 그러려면 그저 해당 RFP의 요구사항 몇 개를 살짝 무시하고 RFP에는 없는 다른 기능을 가진 서비스를 제공해 줘야만 한다...

나의 선택은 당근 이러한 망상을 제거하고 어디까지나 채점하기 귀찮아할 평가위원들을 위해 깔끔하게 정리된 제안서에 RFP요구사항에 나온 것만을 만족시키는 맘에 안드는 시스템을 소개하는 것이다.

뭐, 생각같아서야 발주처에 대략 말 통하는 사람 붙잡고 너네들 요구사항은 이러한 것보담은 요로코롬 만드는게 더 좋을 듯 한데 어떻겠냐고 하소연을 하고 싶긴 하지만... 그럴 수 있는 상황도 아니어서 더 답답하다.

어쨌거나 결론적으로 개개인이 잘 못하는 것 같지 않는데 일은 잘못되어 갈 수 있다는 사실이 암담할 뿐...

거대사업의 표류

회사 다니다 보면 이런 저런 일을 하게 된다. 그 중에는 걍 자체적으로 만들어 파는 물건도 있겠지만 경우에 따라서는 거대 프로젝트에 직 간접적으로 연관이 되는 경우가 많다.

이번에 내가 연관된 케이스는 IT/통신업계 치고는 초 거대 프로젝트인 국방정보통신망 민자 사업이 되겠다. 작년 거의 한 해를 이걸로 보냈다고 해도 과언이 아니다. (사실은 약 반 년정도 되지만, 나머지 반년 정도는 한 일이 없기 때문에...)

뭐, 그건 그렇다 치더라도 이런 거대 사업들의 시작은 한 두 사람이겠지만 끝은 무지막지한 사람과 돌발변수로 그 누구도 예측하지 못한다.

이번 사업에 앙숙관계에 있는 KT-데이콤이 컨소시엄을 구성을 한 것이라던지, KT의 무력행사라던지... 게다가 이번엔 4 개 컨소시엄이 몽땅 다 BMT 통과에 실패하는 사태가 벌어졌다.

제안서 작업 중 그래픽 편집작업과 인쇄작업만 억단위의 돈이 들어간건데 이번 사태로 인해 작업했던 제안서 자체가 고스란히 (봉인도 뜯지 않고) 도로 돌아오게 될 듯 하다.

중간 과정 다 생략하고 느낀 점을 한 마디로 정리하면, 똑똑하고 사심없는 사람이 책임과 권한만 제대로 가지고 추진하지 못한다면 프로젝트는 거의 반드시 실패할 수 밖에 없다는 것이다.

어쨌든 이제 돌이킬 수 있는 상태는 지났고, 국방부가 '원점에서 재검토' 인지 아니면 'BMT만 다시'인지를 결정해야 할 때이다. 어떤 선택을 한다고 하더라도 그에 따른 역풍은 반드시 맞고야 말기 때문에 눈치는 무시하고 그야말로 '올바른' 선택을 해야 할 때이다.

작업 후유증

28일 제안서 제출 이후 장장 5일간이나 몸살을 앓았다.

아직도 온 몸이 쑤시고 아프다.

머리털나고 이렇게 오랫동안 몸살을 앓기는 처음. 비슷한 정도로 아픈건 대학교 기숙사에서 였지만, 그건 이틀 정도 앓고 나서는 괜찮아졌는데, 이건 그 수준의 고열을 동반한 전신 통증이 5일간이나 지속이 됐다.

고로, 가족들 챙기겠단 희망은 물거품이 되고...

그나마도 아직 몸이 회복이 덜되어서 여기 저기 쿡 쿡 쑤시고 있다.

담부턴 이렇게 일 하지 말아야지...