본격 웹-시대의 정보보안 1/2

제목부터 살짝 뻥이라서 어떤 말로 풀어 갈지 고민인데,, 아무튼,

웹사이트는 (대개 "홈페이지!" 그러면 딱 떠올리는 그런) 홈페이지(만은) 아니다.

뭔 소리냐? 결론부터 말하자면,

"웹사이트는 인터넷 프로토콜 기반 네트워크 상에 존재하는 각각 주소와 경로를 따로 가진 페이지들이 유의미하게 묶인 구조체다. (딱 여기까지가 세칭 '홈페이지'의 뜻이고,) 나아가, 기존 시스템들의 통합을 이루기 위해 웹 기술이 서로 다른 각종 장치와 애플리케이션 간의 소통을 위한 인터페이스로 사용됨에 따라, 오늘날 기업 및 기관 전산환경의 절대적 다수는 그 자체로 거대한 웹사이트라 할 수 있다. 그 구조체에 집단 바깥 외부자의 열람을 위한 '홈페이지'가 달려 있든 달려 있지 않든."

아니 그러니까, 그게 뭔 소리냐고,, 먼저 간단히 '업무용 컴퓨터'의 역사를 훑어보자.

1980년대, 'PC'의 시절

IBM의 '메인프레임'만 보더라도 여러 컴퓨터가 한데 묶여 하나의 망을 이루는 거대 시스템도 물론 있었지만, 이 시절 대세는 'PC'였다. 대세란 말이 어째 좀 모호하다 싶은데 간단히 말해 '언론에 가장 자주 등장하는 용어'라고 해 두고, 편의 상 'PC'는 공용 네트워크에 연결되지 않은 그야말로 '개인적인 컴퓨터'라고 치자.

PC 시절, 그러니까 1980년대 풍경을 떠올려 본다. 동네마다 꼭 하나씩은 있던 '컴퓨터학원'의 창에 붙어 있던 글씨는 'MS-DOS', '베이직', 'OA', '코볼', '포트란'이었다. 그리고 기업 현장에서 주로 쓰던 소프트웨어는 "IBM의 킬러 애플리케이션"이라며 꽃시절 누렸던 'dBase'였다. 대개 고립 상태에서 단독 사용하는 독립형 단일 사용자 모델들이다.

"바이러스!"

그러니 이 시절 가장 큰 정보보안 위협은 단독 PC 감염을 노리는 바이러스였다. 따라서 바이러스에 대응하는 안티바이러스, 즉 백신이 대세였다. 이 무렵에 백신을 개발한 사람이 스타가 되기도 했다. 그 스타덤이 도가 지나치는 바람에 아예 신화화(?)됨에 따라 정보보안 패러다임이 기술의 발전상을 따라잡지 못하는 부작용이 발생하기도 했는데, 바야흐로 '본격 웹 시대'를 맞이한 지가 언제 적 일인데 아직까지도 "정보보안!" 그러면 열에 아홉은 "백신!" 그런다,,

"레거시의 등장"

자, 드디어 문제의 용어 '레거시'가 등장한다. '레거시'란? 딱 잘라 "이건 레거시, 그리고 저건 레거시 아님" 식으로 나눌 수는 없지만 대충 '낡은 기술과 방법론' 정도로 이해하면 큰 무리는 없는 용어다. 레거시가 왜 문제냐면.. 기업의 활동이란 말하자면 지적 정보자산을 층층 쌓아 가는 일이다. 그렇게 세월 따라 기업의 데이터베이스는 점점 커지고, 그 누적이 곧 기업의 바탕이요 밥줄이다. 그런데 지금은 거의 쓰지 않는 구식 방법으로 쌓은 데이터가 꽤 많다. 게다가 그때 그 시절 옛날 기술을 통해서만 접근 가능한 정보도 꽤 많다. 이를 어쩌나?

이를테면, 미국 NASA의 우주왕복선은 애초에 "로켓, 한 번 쓰고 버리는 거, 너무 낭비 아냐?" 여론에 대응해 "아니, 이건 갔다가 오니까 또 쓸 수 있는 겁니다!" 논리에 따라 만든 물건이다. 즉, 재사용이 가능하다. 그.런.데. 워낙 복잡복잡한 시스템인데다가 안정성이 최우선인 일이다 보니 새로운 기술을 적용하기 어려워서 한참 시간이 지난 이후에도 일부러 1970년대 기술과 부품으로 계속 땜질하며 쓸 수밖에 없게 된 것. 그래서 우주왕복선은 2011년 은퇴할 때까지 어째 좀 구차하게시리 '레거시'란 말의 상징 노릇을 했다. 그래서 지금도 "레거시!" 그러면 거의 100% 확률로 우주왕복선을 예로 든다.

1990년대, '인트라넷'의 시절

'네트워크의 시절'이라고 할지 '인트라넷의 시절'이라 할지 고민했다. 그러다 "네트워크는 지금도 유효한, 너무 큰 개념이지" 싶어서 딱 잘라 그냥, 인트라넷. 이후 등장할 '웹'에 비교해 약간 고풍스러운 어감이라서 더 어울리는 듯싶기도 하다. 아무튼,

"386! 486! 펜티엄!"요란했지만 PC의 레거시化는 예상보다 훨씬 빨리 일어났다. 1990년대 들어 독립형 단일 사용자 모델 소프트웨어들은 모두 다 위기를 맞는다. "세계에서 가장 많이 팔린 소프트웨어"였던 'dBase'의 화끈한 몰락을 보라. 서버-클라이언트 네트워크 시스템의 확산이 주된 요인이었고, 또 다른 결정적 변수로 작용했던 '윈도우즈'의 등장 덕분에 급속도로 추락한 소프트웨어들이 많다. 개별 PC 단독으로 운영하던 정보 체계는 어쩔 수 없이 새로운 환경인 '네트워크', 서버-클라이언트 구조 시스템 안에 우겨 넣을 수밖에 없었다.

"해커!"

모든 데이터와 시스템이 인트라넷으로 한데 묶이니, 이 시절 가장 큰 정보보안 위협은 해커의 침입이었다. 하이텔과 천리안 등 'PC통신'에는 해커 동호회가 아주 활발했고, 해킹은 왠지 좀 멋진 낭만적 단어로 통해 그 행태는 마치 게임 즐기는 듯했다. 해커들은 주로 '인트라넷 침입'을 노렸다. A대 몇 학년 재학생 누구누구가 B대 인트라넷을 뚫었다! B대 몇 학년 누구누구가 A대 인트라넷 해킹하고 복수했다! 중졸 해커 누구누구가 펜타곤을 뚫었다! 뭐, 좋게 말해서 낭만적인 시절이었다.

그러니 이 시절 가장 중요한 정보보안은 '침입방지'였다. 네트워크 방화벽과 IDS (Intrusion Detection System), IPS (Intrusion Prevention Systems) 등 네트워크 보안장치들이 흥하던 시절이다.

"레거시의 본격화"

그렇게 데이터는 인트라넷 시스템 안으로 들어왔다. 언론은 이러한 변화상을 그들 나름대로 해석해서 천지개벽이라도 일어난 것처럼 "요즘 세상이 어떤 세상인데 아직도 그렇게 구태스럽게 살고 있나!" 요란했고, 실상도 대충은 그러했으니 아주 틀린 말은 아니었다. 그래서, 레거시는 본격화되었다. 어째서?

아직까지는 서로 성질이 다른 이종 환경 간의 자원 통합 문제를 그리 크게 고민하지 않았던 것이다. 생산, 영업, 관리, 마케팅, 물류 등 각 사업부서마다 각자의 필요에 따라 시스템을 따로 구축했다. ERP, CRM, SCM 등 부서마다 다른 애플리케이션이 서로 다른 언어로 서로 다른 시스템 상에서 구축되었다. 이 데이터? 일단 그냥 넣어. 저 시스템? 것도 뭐, "싹 다 쑤셔 넣어!" 그리고 그 결과, 파편화되어 막 쌓았던 것들이 이후 가장 큰 문제로 이어지게 된다. 데이터베이스가 완전한 혼돈 상태가 되는 것이다. 데이터 중복과 연계의 어려움이 문제를 일으키고 데이터베이스의 애초 목적인 데이터 즉시 제공 기능은 바랄 수도 없는 지경에 이른다.

(그런데 레거시가 무조건 나쁜 것만은 아니다. 개발자 입장에선 꽤 쏠쏠하기도 하다. 예를 들어, IBM의 메인프레임과 함께 묶이는 코볼 전문가의 높은 연봉을 보면 "요즘 세상에 누가 그런 낡아빠진 코볼 같은 걸 해?" 굳은 믿음이 샥 사라진다,,)

그리고 그 무렵 미국의 정치인 앨 고어(Albert Arnold "Al" Gore, Jr.)가 "정보초고속도로!"를 외치기 시작했다. 그렇다, 웹이다.

2000년대, '웹-비즈'의 시절

다들 참 열심히 살았다. "모두 억척스럽게도 살아왔지. 솜처럼 지친 모습들. 하지만 저 파도는 저리 드높으니, 아무래도 친구, 푸른 돛을 올려야 할까 봐." 어째서일까? 언젠가부터 뭔가를 '열심히 한다'는 말은 어째 좀 부정적인 어감으로 쓰이는 듯싶다. 반대말로 '잘한다'가 쓰이고. 그래서, 차두리 은퇴사가 참 슬펐고. 아무튼, 열심히 살았던 덕분에 얼마든지 작을 수 있었던 문제가 너무 커져버렸다.

메이저 기업들이 업무용 전산 시스템을 업그레이드하기 시작하던 무렵, 파편화된 시스템과 애플리케이션들의 통합 필요가 부각되기 시작했다. 도입하려는 새로운 시스템과 기존 시스템 그리고 데이터의 연계가 가장 큰 화두로 떠오르게 된 것. 이 무렵 현장에서 내뱉는 불평을 딱 한 마디로 정리하면,

"아, 레거시,,, T_T "

어떻게든 이어 불여야 하는데 붙일 방법이 없는 거라. 발 빠른 장사꾼들이 새 시스템과 헌 시스템을 연결하는 어댑터를 팔긴 했지만 근본적인 문제 해결 방법은 아니었다.

여러 방법론이 있었다. 우선, 기계 하나와 기계 하나를 1:1 매칭하는 '원투원매핑 (One-to-One Mapping)', 하지만 시스템의 수에 따라 곱셈으로 막 늘어나는 복잡도를 도저히 감당할 수 없었다. 시스템 사이 연결 계류를 위한 '브로커 컴포넌트' 삽입, 주객이 전도되어 고작 연결 위해 삽입하는 컴포넌트 때문에 전체 시스템의 사양이 결정되는 주객전도 현상 발생 등, 수많은 시행착오가 있었다. 그렇다고 해서 아주 무의미한 역사는 아니다. 어떤 분야 기술이든 그런 시행착오를 통해, 발전한다.

목적은 '기업용 애플리케이션 통합 (EAI, Enterprise Application Integration)' 식으로 이미 구체적으로 명백했고, 이를 위해 결국 하려고 하는 '일'을 중심으로 제대로 정의된 인터페이스를 가진 재사용 가능 컴포넌트들로 전체 시스템을 구축하자는 '서비스 중심 설계 (SOA: Service Oriented Architecture)' 등의 개발철학이 유행하기도 했다. 하지만 그게 말처럼 그리 간단한 일은 아닌 것이,

'복잡성 (Complexity)' : 정말 다양한 부서에서 다양한 사람들이 다양한 프로세스로 일하고 있으니 각각의 요구부터 천차만별이고, '경직성 (Inflexibility)' : "아니 지금도 대충 돌아가긴 하는데 뭘 굳이 바꿔?" 불만과, '취약성 (Brittleness)' : 위 복잡성과 경직성에 따른 문제 발생 가능성은 늘 "안정성이 최우선인데!"란 말과 이어진다. 보수반동 구태악습 불평불만처럼 들리지만 실제 현장에 가서 보면 꼭 필요한 의문들이기도 하다.

이걸 도대체 어떻게 극복할 것인가!

위 모든 복잡한 문제들을 어렴풋하게나마 모두 해결할 수 있을 듯싶은 가능성이 바로, 웹이었다. 웹 기술, 그리고 '느슨한 결합 (loose coupling)'이라는 아주 막강한 무기를 내세운 'OOP (객체지향 프로그래밍, Object Oriented Programming)'가 시대적 요청에 따른 대세를 자처하고 나섰다.

'느슨한 결합'이란, 간단히 말해 뭐든 위 '원투원매핑 (One-to-One Mapping)'처럼 딱딱하게 엮지 말자는 것이다. 요소와 요소의 이질성을 굳이 부셔서 동질성을 갖추려 들지 말고, 서로 소통이 가능한 '인터페이스'를 통해 딱 필요한 만큼만 느슨하게 붙이자는 발상이다. 그럼 어떤 매개체를 인터페이스로 삼을까? 물론 '웹'이다.

그래서, '웹-비즈' 시절이 된 것이다. 이 흐름이 2010년대로 넘어가면서 클라이언트의 수와 종류가 대폭 확장되면서 본격화된다.

"웹 애플리케이션 보안"

모든 데이터는 애플리케이션을 통해서 이동한다. 그리고 현재 애플리케이션의 주요 환경은 웹이다. 통신기술뿐 아니라 시스템 환경에서부터 사용자 인터페이스에 이르기까지, 모든 IT 기술이 웹으로 통합되고 있다. 앞으로는 모든 애플리케이션이 웹 환경에서 개발되고 운용될 것이다. 이는 시대적 필요에 따른 것이기도 하다. 비즈니스 자체가 웹을 통해 일어나므로 닫아 두고 싶어도 닫을 수가 없게 된 것이다.

(웹 애플리케이션 보안에 대해선 이어지는 '본격 웹-시대의 정보보안' 2편에서 다시..)

2010년대, '웹-비즈'의 확장

돌고 돌아 여기까지 왔다. 처음으로 다시 돌아가서,

"웹사이트는 인터넷 프로토콜 기반 네트워크 상에 존재하는 각각 주소와 경로를 따로 가진 페이지들이 유의미하게 묶인 구조체다."

그렇다. 그러하기 때문에,

"나아가, 웹 기술이 기존 시스템의 통합을 이루기 위해서 서로 다른 각종 장치와 애플리케이션 간의 소통을 위한 인터페이스로 사용됨에 따라, 오늘날 기업 및 기관 전산환경의 절대적 다수는 그 자체로 거대한 웹사이트라 할 수 있다. 그 구조체에 집단 바깥 외부자의 열람을 위한 '홈페이지'가 달려 있든 달려 있지 않든."

결국 이런 구조체를 이루게 된 것이다. 이것이 오늘날 거의 모든 기업의 전산환경이다. 그러니까 웹사이트란 단지 '홈페이지'가 아닌 것이다.

근데 실은 위와 같은 그림은 그리기 나름이다. 얼마든지 다른 그림으로 바꿀 수 있다. 일반적으로 그렇게 그리듯 '웹-티어 (Web-Tier) / 비즈-티어 (Biz-Tier) / 데이터베이스' 구조로 풀 수도 있다. 이는 웹 서버와 웹 애플리케이션 서버를 한데 묶어 '웹-티어'로 분류하는, '컨테이너' 성격 중심의 기술적 구분인데, 요즘은 웹 자체의 위상이 점점 더 커짐에 따라 (그리고 비즈-티어의 대표를 자처하던 EJB의 사실상 실패에 따라) WAS와 비즈니스 컨테이너의 역할이 뒤섞이고 있고, 앞으로는 모든(!) 애플리케이션이 통째로 웹 환경에서 개발되고 운용되리라는 전망에 따라서, '웹서버 - WAS - 데이터베이스'로 풀어 썼다.

그러니 위 그림은 좀 더 긴 말이 필요하다. 하지만 오늘은 일단 여기까지. 이어서,

"본격 웹-비즈 시대, 기업-보안은 도대체 무엇이고 무엇이어야 하는가?"

2편에서 보다 구체적으로 알아보자. 위 그림은 요소와 요소 사이에 오가는 요청과 응답 등 데이터의 흐름에 따라 좀 더 복잡해질 것이다. 클라이언트와 애플릿의 진화, 그리고 WAS의 확장과 서블릿의 진화 및 비즈-티어의 대체 등의 내용이 추가될 것이다.

현황이 그러하니, "JAVA는 어떻게 세계를 정복했나?" 이야기가 될 듯싶기도 하다.

P.S. / 안타깝게도 저는 기술자가 아닙니다. 어쨌든 예술학교를 졸업했으니 기술자가 아니라 예술자라고 해야 그나마 좀 더 어울리겠죠. (이거 올릴 때도 글보다 그림과 표 그릴 때가 마음 편합니다.) 그러니 위 내용은 순전히 제 상식 수준의 이해에 따른 정리입니다. 기술적으로 볼 때 무리가 있을 수 있다는 뜻입니다. 다른 매체를 통하는 컨텐츠는 내부 기술자 자문 과정을 거치지만, 이곳 허핑턴포스트는 제 임의로 그냥 막 올려서 그렇습니다. 막 써서 올리고 나서 "아니, 이건 사실이 아닌데?" 지적을 받곤 합니다,, 혹시 제가 잘못 알고 있거나 아예 모르고 있는 부분을 발견하신다면 댓글 남겨 주시든지 ghpak@pentasecurity.com 주소로 연락 주시면 감사히 받고, 앞으로 계속 생각 고쳐 가겠습니다. 인생은 고집 막 부리며 살기엔 너무 기니까요.