Extremely Agile

[이어서...]

드링크를 목으로 넘기자 특유의 알싸한 향이 코를 찔렀습니다. 속이 개운해지는 느낌이었습니다. 오전에 회의가 잡혀 있었으니, 어떻게든 빨리 정신을 차려야 했습니다. 한 잔의 커피를 뽑아 들고 회의 시간에 쓸 자료를 점검하기 시작했습니다. 지끈거리던 머리도 서서히 풀려가고 있었고, 글자 한 자 한 자가 천천히 머리속으로 밀려드는 것을 느낄 수 있었습니다.

OLYMPUS 프로젝트는 만만한 프로젝트는 아니었습니다. 처음 해 보는 프로젝트라 그랬고, 많은 수의 장비를 관리해야 하는 프로젝트라 더더욱 그랬습니다. 우리 팀 만으로 감당할 수 있을 것 같아 보이진 않았습니다. 필요하다면 재하청을 주어야 할 일이 생길 것 같아 보였습니다.

프로젝트에 소요되는 기간도 짧았습니다. 길게 잡아 육개월에서 팔개월. 마지막 한 달은 '죽음의 행군'을 해야 할 지도 모르는 일이었습니다. 마감시간이 다가올 수록 늘어가는 버그. 여기저기서 툭 툭 튀어나오는 문제점들. 이슈 추적 시스템에 산더미처럼 쌓여가는 문제점들... 그 모든 것이 불안했습니다. 그리고 그런 불안을 느끼는 것은 나 만이 아니었습니다. 회의는 조용히 진행되었고, 모두들 어떻게 해야 할 지 감을 잡지 못하는 듯 보였습니다.

하지만 그 불안을 조용히 처리해 가는 두 사람이 있었습니다. 박팀장과 남기수, 그 두 사람은 마치 1:1로 팽팽하게 진행되는 투수전 끝에 마무리로 등장한 구세주 같아 보였습니다. 남기수가 말했습니다.

"이미 이 바닥에는 네트워크 관리 시스템(NMS: Network Management System) 개발로 잔뼈가 굵은 사람들이 많습니다. 저도 그런 분들을 좀 만나봤구요. 제가 개발했던 프로토콜은 그런 관리 시스템의 일부였습니다. 이런 관리 시스템이 하는 일은 대개 일정합니다. 중앙에는 네트워크를 관리하는 데 사용될 정책(Policy)이라는 것이 있습니다. 이 정책을 모든 장비에 일관되게 반영해야, 네트워크가 일사불란하게 움직이기 시작하죠. 문제는 네트워크 장비들은 이 정책을 이해 못한다는 점입니다. 정책은 주로 사람이 이해 가능한 언어에 가깝게 만들어지는데, 정작 장비는 그런 언어를 이해하지 못하죠. 장비가 이해하는 언어는 SNMP, TL1, 그도 아니면 CLI를 통해 전송되는 텍스트 스트림으로 이루어집니다. 간단히 말해서, 정책을 장비가 이해하는 언어로 변환해 전송하는 절차가 반드시 개입되어야 한다는 뜻이죠."

그러자 김유식이 물었습니다.

"그렇다면 우리가 만들어야 하는 시스템은 전형적인 3-tier 시스템에 가까와 지지 않을까요?"

"적어도 정책, 그리고 그 정책을 변환할 변환 에이전트, 그리고 장비라는 세 부분을 그 세 계층에 대응시키겠다고 한다면 그렇게 말할 수도 있겠습니다. 하지만, 통상 이야기하는 3-tier 시스템과는 그 각각의 계층이 하는 일이 좀 다르지 않을까 싶네요."

모두들 고개를 끄덕거렸습니다. 그러자 박팀장이 나섰습니다.

"그런데 말이죠, 그런 실질적인 이야기를 하기 전에, 우리 프로젝트 명칭이 갖는 의미를 한 번 곱씹어 볼 필요가 있을 것 같아요. OLYMPUS는 Object layer for management of packet-support systems의 약자에요. 저는 이 단어들 중에서 Object Layer라는 그 두 단어가 굉장히 중요하다고 생각해요. 그런데 저로서는 그게 무슨 뜻인지 잘 모르겠어요. 여러분들 중에 감이 오는 분 계신가요?"

그러자 허동수가 입을 열었습니다.

"제 생각에는예..."

그리고 그는 잠깐 말을 멈추었습니다. 무언가 생각하는 표정이었습니다. 다시 입을 열자, 그의 입에서는 단어들이 속사포탄처럼 튀어나오기 시작했습니다.

"보통 Hybernate 같은 시스템을 보믄, 데이터베이스라는 굉장히 평면적인 구조를 객체로 대응시키는 기능을 제공하거든예. 그런걸 ORM이라고들 하지 않습니꺼. 실질적으로 보믄, 2차원 테이블 위에다 객체라는 뷰를 제공하는 것이거든예. 그걸 굳이 부른다면 레이어, 그러니까 계층이라고 부를 수 있지 않겠습니꺼? 같은 이치로, 네트워크 장비를 데이터베이스 테이블같이 본다면, 그 위에다가 객체라는 계층을 살짜기 얹을 수도 있지 않겠나, 이런 생각이 들거든예. 장비를 꼭 객체마냥 취급할 수 있는 레이어를 만들 수도 있지 않겠나, 이 말입니더. 잘은 모르겠지만예, 쪼끔 더 생각해보믄, 그 단어에 맞는 시스템을 만들 수도 있을 것 같고예."

그의 말이 정확히 무슨 말인지 알기는 힘들었지만, 그 골자만큼은 모두들 이해하는 눈치였습니다. 장비 위에 객체 계층을 얹는다. 그럼 프로그래밍은 그 객체 계층 위에서 진행될 것이고... 나름대로 매력적인 아이디어였습니다.

"그런데, 문제가 있습니다."

김유식이 손을 들더니 말했습니다.

"데이터베이스는 업체들 마다 조금씩 다른 문법을 제공하는 경우도 있지만, 본질적으로는 굉장히 유사하거든요. SQL을 통해 사용한다는 점도 그렇고, JDBC나 ODBC같은 표준적인 접근 방법을 제공한다는 점에 있어서도 그렇습니다. 과연 네트워크 장비도 그럴까요? 이 문제 때문에 며칠간 웹을 좀 뒤져 봤는데요. 네트워크 장비를 관리하는 데 사용되는 프로토콜은 SNMP, CLI, TL1 등 비교적 일정한 편입니다만, 그 장비로 가져오거나 설정해야 하는 정보에 이르면, 업체마다 천차 만별입니다. CLI를 통해 장비를 제어해야 하는 경우에는 각 회사들 마다 장비 설정 문법이 다 다르고 설정 결과로 출력되는 결과도 다 다른 형식이라는 것이 문제가 되구요. SNMP인 경우에도 사정은 크게 다르지 않습니다. SNMP는 가장 널리 사용되는 프로토콜인데도, 정작 장비마다 다른 정보 모델을 채용하고 있다는 것이 문제가 되죠."

그러자 모두들 다시 조용해졌습니다. 왜였을까요? 아마 이 일의 규모가 대체 얼마나 되는 것인지, 좀처럼 감을 잡을 수 없다는 것이 가장 큰 문제가 아니었을지. 그 때, 박팀장이 책상 앞으로 바짝 다가 앉으며 말했습니다.

"그럼, 우리에게 이 프로젝트를 던져준 당사자들을 만나봅시다."

"당사자요?" 남기수가 무심한 눈빛으로 물었습니다.

"네. 당사자. 요즘 유행대로 하자면 사용자라고 해야 하나요? 이 프로젝트를 우리에게 준 사람들, 그리고 이 프로젝트의 결과물을 사용할 사람들, 그리고 이 프로젝트를 우리 팀에 던진 결정권자들, 모두를 한 번 만나봅시다. 그러면 뭔가 영감이 떠오르겠죠. 뭔가 막힐 때 구글신에게 신탁을 구하는 것 처럼요."

적절한 비유는 아니었습니다만, 모두들 웃으며 기꺼이 동의했습니다. 우리는 모두 장님이고 프로젝트는 코끼리 같았는데, 코끼리를 만져볼 방법이 없으니 코끼리가 어떻게 생겨먹어야 하는지 이야기라도 들어야 했습니다.

회의를 마치고 박팀장은 여기저기 전화를 걸어 약속을 잡았습니다. 우선 프로젝트를 따 온 윗선 이야기를 들어보기로 했고, 프로젝트를 준 업체 실무자를 초청해 이틀간 집중적으로 회의를 진행하기로 했습니다. 최종적으로 만들어질 제품을 사용할 사람들을 만나는 것은, 업체 실무자와의 미팅 이후로 미루었습니다. 어차피 그 실무자를 통해야 했으니까요. 우선은 프로젝트의 성격을 정확히 파악하는 것이 중요했습니다.

코드는 한 줄도 짜지 않았는데, 모두들 코끼리를 등에 업고 걸어가는 사람 마냥 표정이 밝지 않았습니다. 벌써 마음 한 켠에 아직 만나보지도 못한 버그가 날아다니는 환영을 보고 있는 듯한 기분이었습니다.

[다음에 계속...]