[칼럼]개발자들에게 좋은 아키텍처란?

10년 이상을 내다본 설계 or 유연성 높은 간결한 구조

권희웅

최근 필자가 유심히 바라보는 기술 중 하나가 오픈플로(OpenFlow)이다. 관련 스펙 문서를 살피면서 한 가지 흥미로운 것을 발견했다. 오픈플로의 테이블(Table)과 그룹(Group) 구조를 보면 리눅스의 넷필터(Netfilter)와 상당히 유사하다는 것이다.

넷필터는 리눅스에서 일반적으로 네트워크 보안을 위해 가장 많이 사용하는 기능 중 하나이다. 다양한 관련 모듈들의 도움을 받아 수많은 보안 기능을 수행할 수 있으며, 리눅스의 라우팅 기능과도 연계하여 작동이 가능하다. 기능뿐 아니라 유연성과 확장성도 상당히 좋은 구조라 할 수 있다.

그리고 넷필터는 앞서 말했듯이 오픈플로의 구조와도 상당히 흡사한 면을 가진다. 테이블 내의 엔트리에 특정한 패킷이 매칭이 되면 바로 액션을 취하는 일반적인 동작뿐 아니라, 복수의 테이블에서 유기적으로 매칭이 수행되어 복합적인 기능을 이끌어 낼 수 있는 구조적 특징까지 닮아 있다. 즉 장기적으로 다양한 모듈들이 개발되어 어떻게 유기적으로 연계될지 그리고 기존 시스템에 통합이 될 때 어떻게 사용될지 까지 고려하여 설계가 되었다는 점에서 유사하다.

두 기술 모두 스펙과 같이 표면적으로 드러난 것 그리고 후원 기업들이 원하는 배후의 의도를 종합해 보면 지향하는 바는 같다. 하지만 ‘성능’이란 키워드를 놓고 볼 때 두 기술의 설계 방향은 약간 차이가 난다.

넷필터의 경우 구조는 나무랄 데 없지만 소프트웨어적인 측면에서 성능이 그다지 뛰어나지는 않다. 기능을 일반화 하면 할수록 성능을 내기 어려운 건 사실이다. 오픈플로의 최근 스펙 문서들을 보면 초기 설계 단계임에도 성능 이슈들이 상당히 많이 고려 되고 있음을 알 수 있다. 보편적인 기능을 가지면서 고성능을 이끌어 내기 위해서는 단순히 소프트웨어만으로는 역부족일 수도 있기 때문에 제품 관점에서는 하드웨어적인 고려는 필수라고 볼 수 있다.

넷필터가 일반에게 공개된 버전은 보편적인(Commodity) 하드웨어를 사용하는데 초점이 맞추어져 있다고 한다면, 추측하건 데 넷필터를 후원한 벤더들은 아마도 하드웨어적인 구현에 대한 관점을 충분히 반영하였을 것으로 보인다. 다시 말하자면 드러내놓고 있지는 않지만 넷필터는 소프트웨어적인 유연성과 확장성을 유지하는 가운데 하드웨어적으로 성능을 보완하고자 하는 의도가 초기 설계에 반영되었을 것으로 추측할 수 있다.

반면에 오픈플로는 운용 중인 네트워크 장비들에 추가적인 부하 없이 최적의 성능을 이끌어 낼 수 있는 방향으로 설계의 디테일이 잡혀 가고 있다. 즉 전용 장비 차원에서 성능을 확보하고 오픈플로의 소프트웨어적인 특성을 통해 유연성과 확장성을 보장하고자 하는 것이다.

■현실의 벽 앞에 선 개발자…'통찰' 여유 부족

필자가 오픈플로와 넷필터의 구조적 유사성과 설계상의 장점을 발견하고, 동시에 아키텍처 차원의 다른 점이 무엇인지를 생각하는 와중에 문뜩 개발자들의 현실이 마음에 와 닿았다. 실제 제품을 개발하는 이들이 자신의 주관과 비전에 맞게 설계 사상을 밀고 가는 것과 오늘 당장 해야 할 일 간의 부조리 말이다.

좋은 아키텍처는 개발자의 깊은 통찰에서 나온다. 단순히 어떤 기능을 구현하기 위해 코드를 짜는 것과는 다른 이야기다. 스콧 로젠버그의 ‘드리밍 인 코드’란 책의 내용 중 표준 스펙 작성을 위해 최소한 10년 이상을 내다보고 설계해야 한다는 내용이 있다. 아키텍처와 코딩의 차이를 가장 잘 드러내는 말이 아닐까 싶다. 필자가 이 이야기를 하는 이유는 대부분의 개발자들은 장기적 안목에서 설계를 한다기 보다 영업 부서의 긴급한 부탁 또는 고객의 요청에 대응하는데 급급한 경우가 많기 때문이다.

이런 고민은 비단 필자만의 경험은 아닐 것이다. 필자의 경우 몇 년 뒤를 위해 소프트웨어를 개발할 것인가? 아니면 지금 당장의 요구에 맞추어 갈 것인가? 두 질문을 놓고 고민한 끝에 “최대한 간단하게 구조를 만들어 최대한의 효과를 내보자”는 답을 내었다. 간단한 구조를 통해 수정이 용이한 형태로 만들어 가자는 쪽으로 설계에 대한 딜레마를 해결하고자 한 것이다.

사실 아키텍처 관점의 문제는 설계 당시 나타나지 않던 것이 시간이 지나면서 드러나는 경우가 많다. 급하다 보니 장기적인 관점이 빠지는 경우가 많다. 따라서 수정이 용이한 코드를 만들어 놓고 추후 괜찮은 아키텍처의 형태로 점차 진화시켜 가는 것이 어쩌면 더 현실적이지 않을까?

정리해 보자면 설계에 대한 개발자의 딜레마는 좋은 구조를 가져가고 싶지만 현실적으로는 오늘 할 일을 빨리 끝내야 하는 것이다. 조엘 스폴스키가 쓴 ‘조엘온 소프트웨어’란 책에서는 이러한 딜레마에 대해서 “총을 쏘며 진격하기”라 표현하고 있는데 이것이 멋진 설계와 할일(TO-DO) 목록을 눈 앞에 둔 개발자들이 택할 수 있는 현실적 길이 아닐까?

오늘 할 일에 매진하되 사목사총(四目四聰; 사방의 문을 열어놓고 사방의 눈을 밝히고 사방의 귀를 통하게 함)의 지혜를 발휘한다면 어느 날 자랑스럽고 훌륭한 아키텍처 기반의 제품이 개발자 앞에 높여 있을 것이다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.