아키텍처, 프레임워크, 프로그램, 보안 프레임워크, 보안 프로그램

황인균

2016.09.23

가끔씩 “맨땅에 헤딩”한다는 기분이 드는가? 아키텍처, 프레임워크에 대한 개념을 이해할 수 있는 좋은

기회라고 생각하고 그 순간에 집중하라. 이런 생각이 든다면 고민하지 말고 제일 먼저 우선 인터넷을 뒤져라. 세상에는 수많은 사람들이 있고 그

사람들 중에는 이미 비슷한 기분을 느꼈던 사람들이 존재할 확률이 많다. 그들이 다른 사람들을 위해서

자신들의 경험을 이미 정리해 놓은 산출물들이 있을 수 있다( 있다!).

최종 목표는 프로그램이지만 이것을 바로 만들어내라고 하면 “맨땅의 헤딩” 기분이 든다. 이것을 위해서

일반적인 “프레임워크”가 정리되어 있다. 또 해보니 그 프레임워크를 바로 만들어내는 것도 “맨땅의 헤딩”

이어서 어떤 똑똑한 사람들이 또 그 프레임워크를 만들어 내기 위해서 다시 “아키텍처”라는 개념을 만들어

내고, 이것에 대한 이론들도 정리해 놨다.

때로는 이런 프레임워크와 아키텍처에 대한 이론이 아주 유용하다고 best practice 에 대한 가이드로

사용되기도 하고 어떤 경우는 세계 표준으로 정의되기도 했다.

이런 방법과 이론들에 대한 계층 구조를 보면 다음처럼 될 수 있다.

아키텍처 프레임워크 기업 아키텍처 보안 프레임워크(표준, 레퍼런스) 특정 기업의 보안

프레임워크 특정 기업의 보안 프로그램

1.1 아키텍처

아키텍처는 다음과 같은 질문들에 대해서 답을 할 수 있다.

“이 시스템을 구성하는 이유는 무엇인가?”“누가 이것을 어떤 이유로 사용할 것인가?”“이것이 어떻게 사용될 것인가?”“이것이 어떤 환경에서 동작하게 될 것인가?”

“어떤 유형의 보안과 보호가 요구되는가?”“이것이 무엇과 통신할 수 있도록 해야 하는가?”

이런 유형의 질문들은 시스템이 성취해야 하는 주요 목적을 설명하고 시스템을 추상적 수준에서 구성할

수 있도록 도움을 준다. 추상적 아키텍처는 “큰 그림 big picture” 목표를 제공하고 이것은 다음에 오는

디자인 및 개발을 어떤 방향으로 해야 하는지에 대한 지시를 제공한다.

☞ 아키텍처는 개념적인 수준으로 복잡한 항목을 보다 작은 부분들로 나누고 간략화시켜 이해를 돕고

관계자들간의 커뮤니케이션을 쉽게 한다.

☞ 서로 다른 뷰를 통하여 복잡한 엔터티의 구조와 행위를 개념적으로 이해하는데 도움이 되는 도구이다. 다른 뷰가 필요한 이유는 이해당자들마다 보고 싶은 관점이 다르기 때문이다. ☞ 아키텍처를 설명하기 위해서는 우선 시스템을 구성하는 구성 요소들 그리고 구성 요소들 사이의

상호작용 및 상호 의존성 그리고 환경에 대한 관계 등이 정의되어야 한다. 각 뷰는 이런 부분들로

설명하게 된다.

소프트웨어 공학적 용어로 하자면 아키텍처에는 “품질” 목표도 포함되어야 한다. 기능적인 요구사항뿐만

아니라 신뢰성, 사용성, 호환성, 유지보수성, 결함 허용, 확장서, 보안 등, 해당 아키텍처에서 필요한

품질에 대한 요구사항이 정의되어야 한다.

1.2 프레임워크

아키텍처에서 정의한 목표와 구조, 요구사항들이 있더라도, 그러나 바로 구현으로 가는 것은 또한 “맨땅의

헤딩”을 느끼게 한다. 아키텍처는 개념적으로 구성되어 있다. 그래서 모두 문서로 존재한다. 프레임워크부터는 그 개념들로

구성되어 있는 목표들을 실제로 구현하기 위한 전 단계이다. 아키텍처에서 정한 목표를 달성하기 위한

효율적인 전략을 제공하는 역할을 하는 것이 프레임워크다. 흔히 일반적인 용어로 핵심 성공 전략이라고

CSF( critical success factor) 전략이라고 하는데, 효과적으로 효율적으로 목표를 달성하는데 필요한

방법을 제공하는 것이 프레임워크이다. 프레임워크가 제공하는 구체적인 성공 전략에는 기능적인 요구사항을 달성하기 위한 전략 뿐만 아니라

아키텍처에서 정의한 품질에 대한 요구사항을 달성하기 위한 구체적인 성공 전략도 포함된다. 따라서

프레임워크를 사용하면 고수준의 일관된 품질을 달성할 수 있게 된다. 전략에 대한 절차, 지침을 따라가다

보면 목표로 하는 품질이 달성되는 것이다.

실무를 하다 보면 프레임워크와 아키텍처 사이에는 여러 레벨의 존재가 있을 수 있다. 프레임워크를

만들어 내기 위한 프레임워크, 아키텍처를 만들어 내기 위한 프레임워크 등. 반드시 아키텍처가 있고, 그

다음에 프레임워크 하나가 있는 것은 아니다. 예를 들어 “기획”을 해야 하는데, 기획에 필요한 계획을

세우고, 그 계획을 세우기 위한 상위의 계획이 필요하고. 데이터에도 그 데이터를 설명하는 메타 데이터가

있듯이 프레임워크에도 그 프레임워크를 만들어내는 방법론으로 메타 프레임워크가 있고, 계획을

만들어내는 메타 계획이 있을 수 있다. 실제 작업하면서 필요한대로 하면 된다.물론 아키텍처, 프레임워크는 복잡한 상황을 해결하고자 하는 방법으로서, 이것들 없이 바로 구현으로

들어갈 수도 있다.

1.3 프로그램

이제 그 전략이 제시하는 절차, 지침에 따라서 구체적인 기술( 프로그램 언어, 장비, 솔루션 등)을

사용해서 작업을 한 후 구현된 것이 프로그램이다. 즉 아키텍처, 프레임워크, 프로그램에는 이런 관계가

있다.

큰 그림의 목표 제공 그 목표를 달성하기 위한 핵심 전략들과 절차, 지침 프레임워크를 준수하는

프로그램 구현

분석 단계에서 요구사항과 목표를 정해서 아키텍처가 나오게 되고, 설계,구현 단계를 거쳐서 특정

프레임워크와 최종적인 프로그램이 나오게 된다.

1.4 아키텍처 프레임워크

아키텍처라는 것도 “맨땅에 헤딩”하듯이 아무 기초나 가이드도 없이 하면 힘들다. 그래서 똑똑한

사람들은 아키텍처 자체를 만들어내는 역할을 하는 것도 만들어냈다. 즉 아키텍처에서 제공하는 큰

그림의 목표를 만들어내는 방법론을 제공한다. 이런 방법론은 기존의 존재( 기업, 시스템 등)을 분석하고

이해하는 도구로 사용될 수도 있다. 기업 아키텍처는 기업의 구조를 이해하는데 도움이 되는데, 이런 기업 아키텍처를 만들어낼 수 있는 기본

틀로 사용할 수 있는 프레임워크가 있다. Zachman 프레임워크라는 것이 있는데, 이것은 특정 기업과는

상관없는 일반적인 특성을 갖는다. 특정 기업의 구조를 분석하고 이해하는데 도움이 될 수 있다. 즉 특정

기업의 아키텍처를 만들어내는 프레임워크 역할을 한다. 이런 의미에서 Zachman 프레임워크를

아키텍처 프레임워크라고 부르기도 한다.

아키텍처 프레임워크

실제 기업의 아키텍처가 구성될 수 있는 구조 제공

Zachman 프레임워크

1.5 보안 프레임워크, 보안 프로그램

ISO/IEC 27000 시리즈를 우리는 보안 프레임워크라고 흔히 말한다. 보안 프레임워크는 설계된 보안

아키텍처의 목표를 구현하기 위한 방법을 제공하는 역할로서 아키텍처에서 제공하는 큰 그림의 목표를 좀

더 구체적인 구성 요소와 구현할 수 있는 방법에 대해서 설명한다. ISO/IEC 27000 시리즈에는 기업의 보안에 대한 일반적인 요구사항(목표)를 지정하고 그것을 구현할 수

있는 지침도 제공하고 있다. 즉 기업의 정보 시스템 보안이라는 목표를 달성하기 위해서 필요한 핵심

전략들이 있고 각 핵심 전략을 어떻게 구현할 수 있는지에 대한 지침, 방법론들을 제공하는 보안

프레임워크이다. 이 보안 프레임워크에서 제공하는 요구사항들과 구현 지침, 위험관리 지침, 모니터링

방법들을 이용해서 각 기업에서는 필요한 보안 프로그램을 만들어 낼 수 있다.

때로는 ISO/IEC 27000 시리즈 같은 일반 표준 프레임워크를 특정 기업에 맞도록 커스터마이징해서 해당

기업만의 프레임워크로 구성하는 하는 경우도 있다. 이것은 선택이다. 좀 더 기업에 맞는 프레임워크를

갖는 것은 보안 목표를 달성하는데 효과적일 수 있다. 좀 더 구체적인 정책, 절차, 지침, 표준을 제공할 수

있기때문이다. 그러나 비용, 시간, 관리 어려움등의 문제가 있을 수 있다. 해서 바로 ISO/IEC 27000 을 해당 기업 보안

프로그램의 프레임워크로 사용할 수도 있다. 어플리케이션 제작에 있어서 해당 기업만의 개발

프레임워크없이 바로 .NET 이나 Java 만을 바로 이용해서 프로그램을 개발할 수도 있는 것과

마찬가지이다. 기업의 개발 프레임워크를 만드는 것은 in-house 로 개발하든 상용 제품을 사용하든

비용이 들고 그리고 관리도 해야 한다. .NET 이나 Java 를 ISO/IEC 27000 같은 일반 표준 보안

프레임워크로 보면 될 것 같다.

1.6 아키텍처? 왜?

기술분야의 사람들이 아키텍처의 상위 수준의 다소 이론적 개념을 심각하게 받아들이지 않는 것은

보편적인 듯 하다. 이는 이들이 이러한 개념을 과장되고 비실용적으로 보고, 이런 개념을 일상 생활에서

수행하는 활동들과 그다지 연관도 없고 소용도 없는 것처럼 보기 때문일 것이다. 서버를 설정하는 방법이

중요하고, 현재 발등에 떨어진 불을 끄는 지식을 아는 것도 중요하지만 경영의 입장에서는 처음부터

서버를 제대로 설치하는 것이 더 중요하다. 그리고 서버가 그곳에 왜 있는지 등 주변과 문맥에 맞는

설명이 있어야 한다. 시스템, 보안을 상위 수준의 이론적 관점에서부터 실용적 경험 수준까지 구현되도록

보장해야 한다.

만약 아무도 시스템이 존재해야 하는 이유, 목적에 대해서 고민하지 않는다면? 아무도 시스템 아키텍처를

수행하는 방법에 집중하지 않는다면? 돈은 돈대로 들어가고 효과는 없는 듯하고. 시스템이 복잡해지면

머릿속은 뒤죽박죽이 되고. 지금 전체 시스템에 대해서 추상적인 단계에서부터 아래 단계에까지 구체화되는 그림이 머릿속에

그려지지 않는다면 머릿속에 왜 그림이 그려지지 않을까 문제 의식을 가져볼 필요가 있다.