천객만래 [千客萬來] (It has an interminable succession of visitors)

[개발/IT] 아키텍쳐, 프레임워크, 플랫폼


- 아키텍처: 소프트웨어의 주요 설계 구조

 


소프트웨어의 주요 특징들을 결정짓는 주요 설계 구조이다.즉, 소프트웨어의 주요 구성 요소 및 구성, 이들간의


주요 인터페이스, 중요 동작 방식 등 소프트웨어의 주요 특징들을 결정짓는 모든 설계 구조를 포함한다.


소프트웨어의 주요 특징을 결정짓고 소프트웨어 개발에 미치는 영향도 매우 커서 소프트웨어 개발에 있어서 가장 중요한


부분이라고 할 수 있다.지원 프로그램, 라이브러리, 언어, 다른 소프트웨어 구성 요소 등과 같이 구체적인 구현을 포함하지 않는다는 점에서


프레임워크나 플랫폼과는 명확히 구분된다.


 


- 프레임워크: 소프트웨어 뼈대 구조


 

프레임워크는 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조이다.지원 프로그램, 라이브러리, 언어,


다른 소프트웨어 구성 요소들을 엮어 주는 소프트웨어 등을 포함하고 있다.따라서, 플랫폼도 프레임워크의 일종이라고 볼 수 있으며,


MS사에서 닷넷 플랫폼을 닷넷 프레임워크라고 지칭하는 것도 틀린 것이 아니다.또한, UI 프로그램 개발을 위한 부분 만을 떼어내서


프레임워크라고 할 수도 있다.UI 프로그램 개발을 위한 부분 만으로는 완전한 소프트웨어 실행 환경이 되지 않으므로 플랫폼은 아니지만


프레임워크이다.이러한 점에서 프레임워크와 플랫폼은 다른 경우가 많다.


 


- 플랫폼: : 소프트웨어 실행 환경


 

가장 일반적이면서도 명료한 의미는 "소프트웨어가 실행되는 환경"이다.개발 언어나 개발 환경을 플랫폼에


포함시키기도 하지만 이는 부수적 개념 혹은  확장된 개념에 불과하고, 핵심은 "소프트웨어가 실행되는 환경"이다.


각 프로그램은 아무 플랫폼에서나 실행되는 것이 아니고 특정 플랫폼에서만 실행된다.

Posted by SB패밀리

http://www.zdnet.co.kr/builder/system/etc/0,39031682,39147115,00.htm

 

 

버그 없는 프로그램은 없다

최진호 (한국 IBM 소프트웨어)   2006/05/04
때는 바야흐로 거미줄력 12년, 버너스 경이 웹과 브라우저를 만들고 웹의 지배 아래 세상이 마우스 클릭질로 시끄럽기 그지없던 시절이었다. 초기의 웹은 그저 집 없는 개인 사용자의 한풀이용으로 홈페이지 제작 기술을 위해 쓰이던 것이었지만 점차 그 허접하던 초기 기술적인 한계를 극복하고 수많은 천재들과 박사들의 컨설팅, 아키텍팅 그리고‘노가다’를 바탕으로 이제는 꽤나 위험할 듯 하고 시스템이 중지되어 버리면 범국가적 위기 상황으로 번질 만한 부분에도 웹이 야금야금 지배하기 시작했다. 바야흐로 전 세계가 거미줄에 대롱대롱 매달려서 살아가고 있는 것이다.

웹은 편하고 단순하고 빠르다. 게다가 돈도 별로 들지 않는다. 이렇게 너도 나도 다 웹 동네에서 살다보니‘가지 많은 나무 바람 잘 날 없다’고 웹 시민들을 끊임없이 괴롭히는 존재가 있었으니 바로 버그라는 놈이었다. 웹 버그는 웹 초기에는 단순히 소스코드 상에서만 숨어있어서 웹 개발자들이 쉽게 끄집어내어 처리하는 것이 가능했으나 점차 웹의 세계가 복잡해지면서 단순히 개발자가 처리할 수 있는 수준을 넘어서게 되었고 이 버그를 해결하는 데 수많은 인력이 투입되기 시작한다. 범기업적, 범국가적, 범세계적으로 문제를 일으킬만한 버그들이 하나 둘 씩 모습을 드러내면서 웹 시민들은 더 이상 이 웹을 좌시할 수 없게 되었으니 이것이 바로 버그 사냥꾼이라는 직업이 태어나게 된 계기가 되었다.

버그 사냥꾼이란?
그렇다면 버그 사냥꾼은 어떤 사람들이며 무슨 일을 하는가? 앞에서도 말을 했지만 웹이 주체할 수 없을 만큼 거대하고 복잡해져 버렸다. 우리가 웹 기반 하에서 서비스를 개발하면 과거에는 해당 서비스를 위해 필요한 다양한 아키텍처적인 요소들을 고려해서 해당 요소들을 거의 모두 개발해야만 했다. 왜냐? 기반이 없었으니까. 즉 보안이나 신뢰성, 성능, 데이터 정합성, 트랜잭션, 확장성 등 거의 모든 부분에서 개발자와 아키텍트들은 그들의 창조성과 능력을 발휘할 수 있었고 그들의 역량에 따라 프로젝트의 실패 유무가 잇따랐다.

사람들은 어떻게 하면 더 예술적이고 효율적으로 시스템을 개발할 수 있을지 고심했고 더 나은 시스템 아키텍처가 있으면 감탄했고 박수를 보냈다. 그러나 시간이 흘러가면서 사람들은 그것이 얼마나 위험천만한 일이고 고비용이 들어가는 일인지를 깨달았고 개발자와 아키텍트가 선별하고 고심해야 했던 아키텍처 요소들을 대신 처리해줄 수 있는 여러 컴포넌트와 미들웨어 제품들을 사용하기 시작했다. 이러한 선택은 웹 시스템 개발에 들어가는 인력과 시간을 줄여주는 듯해 보였고, 점차 순수한 소프트웨어 아키텍트는 손가락을 빨게 됐다. 이제 개발자가 하는 일이라고는 웹 화면의 단순한 인터페이스 노가다이거나 단순 로직에 대한 작업 등을 벗어나지 못했고 이러한 단순 노가다만으로도, 별다른 수고없이 보안이나 성능, 트랜잭션, 확장성 등이 어느 정도 이상 충족되어 가고 있었다. 결국 개발자가 작업한 내용은 전체 시스템에서 보자면 빙산의 일각이었고 눈에 보이는 소스코드 이면에는 그것들에 대한 아키텍처 요건들을 처리해주는 수많은 컴포넌트와 미들웨어 제품들이 얽혀있는 상황이 된 것이다.

문제는 여기에서 발생한다. 웹 시스템에 버그가 발생했을 때 이제는 개발자 한 두 사람이 분석해서 원인을 파악하는 것이 불가능해질 정도로 종합적인 문제 분석 능력이 필요해진 것이다. 때문에 웹 시스템에 버그가 발견되면 해당 사이트에 하드웨어 전문가와 네트워크 전문가, DB전문가, 미들웨어 전문가, 개별 컴포넌트 제품 전문가, 개발자, 운영자 등이 모여서 어디서 문제가 발생한 것인지를 종합적으로 분석해야 하는 상황이 발생하는 경우가 다반사가 되었다. 그래서 이 장애 전문 해결사로서 버그 사냥꾼이라는 직종이 탄생하게 되었다.

버그 사냥꾼 중에서도 특히 미들웨어 전문가의 역할이 매우 중요하게 되었는데, 거의 모든 문제가 발생하는 첫 번째 장소이자 시작 시점으로 거론되는 곳이 바로 이 미들웨어 쪽이기 때문이다. 즉 과거에는 개발로서 해결하던 여러 가지 요소들이 미들웨어 쪽에서 처리되면서 크리티컬한 부분에서의 버그 역시 미들웨어가 처리하게 되었다. 때문에 미들웨어 쪽 버그 사냥꾼의 지식 체계는 넓고 깊다. 왜냐하면 실제로는 하드웨어나 네트워크에 문제가 있어도 일단은 미들웨어에서 문제가 감지되고 소스코드 상에서 버그가 있어도 미들웨어에서 발견할 수 있다. 성능이 문제여도 미들웨어 쪽에서 전체적인 분석을 해야 하는 상황이다 보니 미들웨어 쪽 버그 사냥꾼은 만물박사가 되지 않을 수가 없다. 그들은 때때로 성능이나 개발에 대한 작은 컨설팅까지 해가며 웹 시민들의 안녕을 위해 고군분투하고 있다.

버그 사냥꾼 스파이크
그래서 이번 기사에서는 버그 사냥꾼 스파이크씨를 소개할까 한다. 그는 모 회사에서 판매하고 있는 웹 애플리케이션 서버 제품에 대한 기술지원을 담당하고 있는 경력 5년의 버그 사냥꾼이다. 그가 주로 하는 일은 회사가 판매하고 있는 제품을 구매해서 쓰고 있는 고객들이 개발이나 운영 중에 제품에 문제가 발생했을 때 문제를 해결해주는 것이다. 그러나 웹 애플리케이션 서버라는 것이 위로는 사용자의 요청을 받아서 일차적으로 처리하는 웹 애플리케이션과 맞닿아 있고 아래로는 DB나 네트워크, 하드웨어, Legacy 등의 리소스와 연결되어 있다보니 일단 고객이 뭔가 서비스가 되지 않으면 무조건 스파이크씨를 부른다. 그러면 스파이크씨는 전체 시스템을 모니터링하면서 문제의 원인을 분석하고 고객에게 해결책을 알려주는 것이다. 이런 그에게 최근 웹 시스템에서 발생하는 버그의 유형에 대해 의견을 물어보았다.

버그요? 말도 마세요. 버그 같은 버그, 정말 웹 애플리케이션 서버에 문제가 있어서 생기는 버그면 말도 안하죠. 미들웨어라는 게 눈에 보이지는 않으면서 하는 일은 무진장 많으니까 걸핏하면 저를 호출하는데요, 사실 일어나는 문제 중의 상당수는 개발 쪽이나 DB 그리고 서버에서 생기는 문제예요. 사이징을 제대로 하지 못해서 생기는 경우도 많죠. 그래도 일단 에러 로그는 웹 애플리케이션 서버 쪽에서 나오니까 일단 고객은 저를 부르는 거에요. 그런데 사실 요새에는 개발 쪽에서 생기는 버그도 많질 않아요. 워낙에 개발자들의 능력도 좋아졌지만 개발자들이 웹 개발에서 해볼만한 게 없거든요. 대부분의 중요한 로직들은 웹 애플리케이션이 해결해주니까 단순한 버그는 많지 않은거죠. 다들 버그, 버그 하지만 요새처럼 버그 잡기 어려운 시절이 어디 있겠어요? 버그 잡는 거 쉬운 노릇이 아니거든요. 하드웨어부터 개발까지 IT 지식 전반적인 것들을 다 알아야만 버그를 잡을 수가 있는거죠. 아무나 버그 사냥꾼 하는거 아니거든요.

횡설수설하는 스파이크씨의 인터뷰를 통해서 그가 얼마나 쌓여있는 할 말이 많은지 알 수가 있다. 버그 사냥꾼의 입장에서 과연 최근의 웹 기반 시스템에서 발생하는 버그의 유형은 어떠한 것들이 있는지 살펴보자.

버그의 종류
스파게티 코드와 리소스에 대한 정확한 사용
세상이 많이 변하고 변했지만 아직까지도 이런 허접한 코드를 보면 왕짜증이죠. 개인 홈페이지 만드는 것도 아니고 명색이 대기업 홈페이지라고 해서 들어가 보았더니 JSP 코드에 DB 호출하려고 JNDI 룩업해서 직접 DB랑 쿵작쿵작하는 걸 박아놓고 있더라구요. 정말 한숨부터 나옵니다. 그래도 좀 안다 하는 운영자분들은 미안해하기라도 하지요. 요즘 웹 개발에서 그나마 전체 시스템을 망가뜨릴 수 있는 이슈는 리소스 관리에요. 예를 들어 개발자가 코딩하면서 DB 리소스만 공손하게 사용해준다면 웹 애플리케이션에서 생기는 버그의 반 이상은 방지할수 있을 거예요. 그런데 JSP 코드에 로직과 뷰가 분리되기는커녕 오묘한 조화로 손잡고 있으면 정말 버그 잡기도 힘들 뿐더러 리소스에 대한 반환이 제대로 되는지 파악조차 사실 잘 안 되거든요. 확장성에도 문제가 있고. 아무튼 이런 구석기 시대코드는저질버그를양산하는창고같은역할을하는거죠.

스파이크씨도 과거에는 웹 개발자였다. 특히 그는 php 전문 개발자였는데 초짜시절에 그 역시 php로 무수한 스파게티 코드를 작성한 경험이 있다. 자유로운 php라는 언어의 특성상 개발 속도가 빨랐고 단시일 내에 원하는 사이트를 개발하는 것은 어렵지 않았지만, 초짜시절 그는 지인을 통해 아르바이트로 자그마한 컴퓨터 회사의 홈페이지를 php로 개발하게 되었다. 하루가 지나니 게시판이 생기고 또 하루 지나니 견적 페이지가 만들어졌다. 그렇게 후다닥 만들어진 홈페이지는 고객과 홈페이지 주인의 원망을 듣는 버그 투성이 사이트로 전락해버렸다. 객체지향이고 뭐고 없이 생각나는 대로 만들어진 스파게티 코드는 나중에 다시 고쳐보려 해도 어찌할 수 없을 만큼 복잡해진 말썽꾸러기가 되어버리고 만 것이다. 그러나 이런 사례는 사실 요 근래에는 많이 찾아볼 수 없거나 혹은 이러한 로직과 뷰의 분리가 완전히 되어 있지는 않더라도 중요한 비즈니스 로직 정도는 컴포넌트화 시켜놓는 것이 요 근래의 추세이다. 이것은 그동안 웹 기반 개발자들이 양적으로 뿐만 아니라 질적으로도 많은 향상을 보여왔음을 뜻하는 것이다.

스파게티 코드와 함께 웹 기반 시스템에서 웹 개발자가 실수하는 것들 중의 하나가 리소스에 대한 해제를 제대로 해주지 않아서 전체 시스템에 무리가 가게 만든다는 것이다. 또한 서블릿 사용시 쓰레드 기반 프로그래밍에 익숙하지 않은 개발자가 리소스 변수에 대한 잘못된 사용으로 인해 부하를 일으키는 경우도 종종 있는 일이다. 사실 이러한 현상은 무조건 개발자의 탓으로만 돌릴 것이 아니라 문제가 될 만한 소지가 있는 부분들을 미연에 방지할 수 있도록 별도의 공통 컴포넌트로 끄집어내서 통합관리를 하는 등의 개발 환경을 구축해 놓아야만 해결될 수 있을 것이다.

몇 달 전 스파이크씨가 고객의 요청으로 들어간 사이트에서 있었던 일이다. 평소에는 이상 없이 잘 돌아가던 시스템이 부하가 어느 정도 쌓이면 갑자기 행(hang) 현상이 발생하면서 웹 애플리케이션 서버가 죽어버렸다. 늘 있어왔던 현상이고 이런 경우 대부분 애플리케이션에서 리소스 관리를 제대로 하지 못했기 때문에 발생하는 경우가 다반사였다. 역시나 문제는 애플리케이션 쪽이었다. 각각의 JSP 코드에서 직접 DB 리소스를 가져와서 함부로 썼던 것이다. 즉 그 수많은 JSP 코드에서 직접 DB를 연결하여 필요한 작업을 수행하고서는 때때로 연결을 닫지 않기도 하고 예외처리도 엉성하게 되어 있었다. 더구나 JSP 코드는 로직과 뷰가 전혀 분리되지 않은 상태이다보니 문제를 해결하는것도 어렵기 그지없었다. 천상 스파이크씨는 고객에게 애플리케이션에서 DB 리소스 해제를 제대로 해주지 않은 것이 문제여서 발생한 것임을 보고했고, 되도록이면 DB 제어에 대한 부분은 기업 공통 컴포넌트를 작성하여 그것을 전사적으로 사용할 것을 권했다. 또한 웹 개발자들에게 좀 더 좋은 교육의 기회를 제공하여 웹 프레임워크나 기타 기업 내의 프레임워크 등에 대한 가이드라인을 다시 한 번 제시할 것을 권고했다.

이러한 스파게티 코드와 정확치 않은 리소스 사용으로 인한 버그는 많이 발생하기도 하지만 문제의 원인이 분명한 만큼 스파이크씨가 짜증내는 일면 쉽게 해결할 수 있는 범위에 속한다는 측면에서 반가운 현상이기도 하다. 하지만 스파이크씨가 다음으로 언급하는 여러 상황들은 스파이크씨에게도 참으로 버거운 버그들, 고급 버그들이다.

시스템 및 프레임워크에 대한 이해 부족
생각있는 운영자들이 가장 꺼려하는 것 중의 하나가 무엇인지 아세요? 최신 기술입네 하고 무턱대고 개발자들이 인기있는 오픈소스 프레임워크를 도입해서 써버리는 경우에요. 문제는 그 프레임워크가 얼마나 신뢰할만 하냐는 거죠. 그 프레임워크를 썼는데 막상 운영하고 보니 치명적인 문제가 발생하면 대체 누구에게 하소연하겠습니까? 개발자는 그제서야 부랴부랴 오픈소스를 뜯어고치거나 이미 어디론가 회사를 옮겨버린 후란 말이죠. 게다가 무턱대고 프레임워크를 도입해버리면 그 프레임워크를 알고 있는 개발자는 어떻게든 문제를 해결한다하더라도 향후 업그레이드나 확장을 해야 할 시점이 왔을 때 생소한 프레임워크 때문에 개발에 드는 비용보다 프레임워크를 이해하는 데 드는 비용이 더 커져버린다 이겁니다. 저도 지원을 하다보면 이렇게 프레임워크에서 문제가 발생한 경우에는 어떻게 손을 쓸 수가 없어요. 그 프레임워크를 들어내라고 할수도 없고 말이죠. 게다가 프레임워크의 철학을 제대로 이해하지도 못하고 써버리면 문제는 아주 골치아파지는 거죠.

자바 엔터프라이즈 기술 중 EJB는 상당히 성공한 컴포넌트 기반의 기술이다. 수많은 서적에서 EJB를 다루었고 마치 JEE의 수준 높은 개발을 이루려면 EJB를 써야 하는 것처럼 보이기도 한다. EJB는 결국 웹 기반 서비스에서 트랜잭션과 분산처리가 꼭 필요한 요소가 있을 때 그러한 위험을 대신 처리해주기 위해 탄생했다. 물론 비즈니스 로직에 대하여 EJB로 만들어두고 추후 두고두고 쓰겠다고 마음먹겠다면, 그리고 EJB라는 좋은 프레임워크 안에서 개발을 하겠다는데 말릴 사람은 아무도 없을 것이다.

그러나 EJB를 통해서 얻을 수 있는 것이 있다면 반대로 잃는 것이 있게 마련이다. 우선 속도의 문제를 들을 수 있다. RMI Call을 통한 분산 컴포넌트 기술이다보니 아무래도 직접 메쏘드 호출에 드는 비용보다 많을 수밖에 없다. 또한 EJB 기술을 충분하게 숙지하지 않은 개발자일 경우 잘못된 설계와 사용으로 인하여 오히려 사용 안하느니만 못한 결과를 종종 가져올 수 있다. 왜냐하면 EJB는 성숙한 JEE 기반의 설계 지식을 바탕으로 개발되었을 때 그 기능을 십분 발휘할 수 있는 것이지, 비즈니스 로직과 도메인 로직에 대한 분리 개념 없이 접근했다가는 큰코 다칠 기술이기 때문인 것이다. 이런 이유로 가뜩이나 무거운 JEE 환경에서 EJB 호출이 너무나 빈번히 발생하여 전체 시스템에 오버헤드가 일어나는 경우 그 결과는 느려진 서비스와 고비용으로 귀결될 뿐이다.

재차 강조하자면 앞에서도 언급했듯이 웹 기반 시스템에서의 버그가 점점 개별적인 소스코드에서 프레임워크나 전체 시스템단으로 옮겨오는 추세이다. 때문에 전체 시스템과 도입된 프레임워크에 대한 충분한 이해 없이 개발된 시스템은 결국 버그를 양산해낸다. 그 중에서도 프레임워크에 따른 폐해는 정말 심각하다. 문제는 해당 프레임워크가 검증되지 않았다는 것과 프로젝트에 참여하는 개발자 전원이 프레임워크에 대한 이해가 충분하느냐에 있다. 소프트웨어는 단지 바이너리 데이터 덩어리만을 의미하지는 않는다. 소프트웨어에는 고객이 있고 개발 프로세스가 있고 문서가 있으며 유지보수에 따른 절차가 포함된다. 이러한 소프트웨어의 필요충분조건을 무시하고 신뢰성에 대한 검증과 유지보수에 대한 확실한 책임 소지를 분명히 하지 않을 경우 어줍잖은 프레임워크 도입은 오히려 더 큰 버그를 양산하는 요소가 된다.

충분한 테스트 없이 운영
요새 프로젝트를 보면 개발에 걸리는 시간보다는 테스트에 걸리는 시간이 훨씬 많이 소요되고 그 중요성이 증대되고 있는것 같아요. 그만큼 운영 환경에서의 검증작업을 확실하게 한다는 얘긴데요. 그럼에도 불구하고 평상시에는 잘 돌아가던 것들이 운영 때만 되면 꼭 문제가 일어나요. 테스트할 때 제대로 운영 환경에 맞추어 시나리오를 구성하지 못했다는 것이고 운영 환경을 제대로 예측하지 못한 결과이기도 하죠.

지금도 여전히 스파이크씨는 운영 하루 만에 시스템이 정지된 고객의 현장에 출동하느라 여념이 없다. 그만큼 운영과 테스트는 다르다는 것을 입증하는 것이리라. 또한 이것은 단순히 운영과 테스트가 다르기 때문에 일어나는 당연한 현상이라고 넘겨버리기에는 아쉬운 무언가가 있다. 즉, 고객이 테스트의 중요성을 제대로 인식하지 못한 경우에 발생한다는 것이다.

며칠 전 스파이크씨는 고객의 신규 오픈 사이트 통합 테스트 현장에 출동했다. 테스트 중 웹 애플리케이션 서버에서 문제가 발생했을 때를 대비하여 같이 모니터링을 요청한 것이다. 테스트 현장에는 몇 명의 애플리케이션 개발자와 운영자 그리고 부하테스트 전문가들이 모여 있었다. 늦은 밤 시간이었고 개발자들은 하나같이 초췌함 일색이었다. 저녁 9시에 성능 테스트가 시작됐다. 그런데 테스트는 단 30분도 더 진행시킬 수가 없었다.왜냐하면 애플리케이션에서 버그가 발생했기 때문이었다!

스파이크씨는 황당했다. 분명 그 통합 테스트는 성능 테스트였다. 그렇다면 적어도 한번쯤은 애플리케이션에 대한 단위 테스트 정도는 해보았을 것이 아닌가? 스파이크씨가 개발자에게 물어보니 단 한번도 애플리케이션에 대한 통합 테스트를 이전까지 진행해본 적이 없다고 한다. 결국 그 날의 테스트 현장은 파장되었고 개발자는 성능 테스트에서 발생하여 접수된 버그를 해결하기 위해 밤을 샜다.

통합 테스트는 운영 테스트와 성능 테스트로 분류할 수 있고 이러한 통합 테스트 이전에 각각의 애플리케이션들에 대한 충분한 단위 테스트와 애플리케이션 별 통합 테스트가 선행되어야만 한다. 그런데 이러한 순차적인 과정을 무시하고 오픈이 얼마 남지도 않은 시점에서 개별 애플리케이션들에 대한 기본적인 버그조차 해결되지 않은 상황에서 성능 테스트한답시고 밤을 새워가며 애플리케이션 성능이 나오지 않음을 탓하는 경우를 스파이크씨는 가끔 목격하곤 한다. 테스트는 아무리 강조해도 지나치지 않으며 테스트 기간 산정은 시스템의 신뢰성을 가름하는 가장 중요한 잣대가 될 수도 있다.

제품에 문제가 있는 경우
버그 중에 저 같은 버그 사냥꾼들이 가장 무서워하는 것이 제품 버그죠. 새 버전의 웹 애플리케이션 서버가 출시되면 일단 처음에 겁부터 나요. 이번엔 어떤 버그가 있을까? 하구요. 제가 담당하고 있는 제품이 그래도 이 바닥에서는 유명하고 검증받은 제품인데도 가끔씩 황당한 버그를 발견하곤 하거든요. 세상에 버그없는 소프트웨어가 어디 있겠어요? 하지만 특히 웹 애플리케이션 서버 버그는 찾기도 어렵고 치명적인 경우가 많아서 신경이 많이 쓰이죠. 보통 문제가 발생한 사이트에 나가면 문제의 원인이 어디에 있는지 추적해 들어가는데, 전체 IT 인프라부터 개별 애플리케이션까지 다 추적해보거든요. 그런데 결국 추적의 방향이 웹 애플리케이션 서버 자체의 결함으로 결론지어지면 고객에게 할 말이 곤궁해져요. 금방 고칠 수 있는 거면 고치지만 제가 개발한 것도 아니다보니 시간이 길어질 수밖에 없어요. 아무튼 이런 경우 입이 바짝 바짝 마릅니다.

보통 고객에게 제품을 판매하기 전에 정말 이 제품이 제 성능을 발휘하는 지를 보여주기 위해 때때로 벤치마크 테스트를 고객이 보는 앞에서 시연하는 경우가 있다. 스파이크씨는 몇 달 전 고객에게 웹 애플리케이션 서버의 성능을 보여주기 위해 벤치마크 테스트에 참여했다. 테스트는 클러스터링된 환경에서 여러가지 패일오버(Failover)와 세션 클러스터링 그리고 고객의 샘플 애플리케이션에 대한 성능 테스트였다. 웹 애플리케이션 서버에서 클러스터링 기능은 가장 기본이 되는 기능이기 때문에 비록 새 버전의 제품이기는 하지만 결국 같은 제품 라인이므로 스파이크씨는 큰 무리없이 테스트가 진행되리라 생각했다.

그러나 이후 엄청 황당한 경험을 해야 했다. 클러스터링으로 묶여있는 서버군 중 하나의 서버를 임의로 중지시키고 다시 가동시켰더니 나머지 다른 하나의 서버가 죽어버리는 현상이 발생한 것이다. 아마도 세션 정보를 서로 공유하다가 무언가가 꼬여버린 것 같은데 전날 테스트할 때에는 아무런 문제가 없다가 특정 상황에서 그것도 하필 고객이 바로 옆에 있는 그 상황, 너무나 중요한 그 상황에서 제품은‘엿 먹으라는 듯’버그를 발생시키고 만 것이다. 스파이크 씨를 비롯한 회사의 모든 사람들의 얼굴은 흙빛이 되었고 그 날 테스트는 그것으로 끝이 났다. 그 이후로 스파이크씨는 밤새도록 제품 개발자와 문제를 재현하여 해결하는데 많은 시간을 들였고 결국 단순히 하나의 클래스를 교체함으로써 더 이상 해당 버그는 발생하지 않았다.

앞서 언급한 것처럼 웹 시스템 개발자가 담당하는 역할 상 리소스에 대한 제대로 된 사용만 철저히 한다면 전체 시스템에 걸쳐 영향을 미칠 수 있을만한 여지가 적은 반면에 미들웨어에서 상대적으로 처리해주는 기능이 많아지다 보니 만약에 이러한 미들웨어가 부실한 신뢰성을 가진다면 그 파급 효과는 상당한 것이다. 때문에 미들웨어를 선택할 때에는 신뢰할만한지 지원은 얼마나 철저한지를 제대로 점검해보지 않으면 두고두고 전체 IT 인프라를 좀먹을 수 있는‘악의 근원’이 될 소지가 있다.

나무를 보지 말고 숲을 보자
가장 황당한 버그는, 사실 이건 버그도 아닌데요. 사람들은 문제가 발생하면 아무래도 시야가 좁아지죠. 개발자는 소스에 이상이 없는지만 살피게 되고 운영자는 운영 환경만 살펴보게 되죠. 그런데 문제는 정말 엉뚱하게도 너무나 당연하게 생각했던 부분에서 해결되는 경우가 많아요. 이를테면 네트워크 선이 뽑아져 있었다든지, DB 서버가 잠시 죽어있었다든지 우리가 평소에 당연히 되리라고 믿어 의심치 않는 요소들이 문제여서문제 상황이 지체되는 경우가 심심치 않게 일어나죠. 그래서 가끔 지원나갔다가 랜선 뽑아져 있던거 연결해주거나 시스템만 한 번 껐다 켜주고 돌아오는 경우가 의외로 많지요. 이런 상황이 있으니 저처럼 미들웨어 쪽 기술 지원하는 사람이 만능박사가 될 수밖에 없는 거죠. 일도 많지만 그만큼 전체 시스템을 보게 되는 힘을 기를 수 있어서 즐겁습니다.

어느 중요한 고객으로부터 스파이크씨에게 연락이 왔다. 엄청나게 성능 좋은 서버를 도입해서 프로젝트를 진행하고 오픈이 얼마 남지 않았는데 성능이 제대로 나오질 않아서 난리가 났다고 한다. 허접한 오픈소스 제품으로 돌릴 때만도 못한 성능이 나오니 이것은 분명 스파이크씨가 담당한 제품의 문제이고 이것을 해결하지 못하면 앞으로 장사 못할 줄 알아라고 말한다. 다급한 스파이크씨 곧장 고객에게 달려간다.

실제로 문제 상황을 보니 같은 웹 애플리케이션을 실행하는데 유독 스파이크씨가 담당한 제품에서만 느린 것을 확인했다. 스파이크씨는 당연히 제품만의 문제로 규정하고 제품의 버그를 찾기 시작했다. 애플리케이션의 알고리즘을 바꿔보기도 하고 버그 리스트를 찾아보기도 했으며 다른 서버 환경에서의 차이점도 분석해보았다. 그러기를 며칠, 결론은 제품의 문제인 것 같기는 하지만 다른 서버에서는 전혀 발생하지 않는 문제라는 것이다. 결국 문제는 고객이 최신 기종이랍시고 들여온 서버에 문제가 있음을 검증하는 단계에 이르렀고 스파이크씨가 며칠 동안을 애써가며 웹 애플리케이션 서버안의 문제를 파헤쳤던 수고는 공염불이 돼버렸다. 즉, 애초에 스파이크씨가 문제의 원인을 좀 더 다각도로 바라보았다면 일찍 서버에 문제가 있었음을 간파할 수있었을 것이며 상황은 훨씬 빨리 종결될 수 있었을 것임에도 불구하고 고정관념에 사로잡혀 하나의 포인트만을 바라보다 보면 숲을 보지 못하는 결과가 생길 수 있음을, 즉 문제는 의외로 다양한 곳에서 복합적으로 일어날 수 있음을 간과한 결과라고 할 수 있겠다.

이렇게 숲을 보지 못해서 쉽게 해결할 수도 있는 문제가 오래동안 여러 사람의 밤잠을 설치게 하는 경우는 스파이크씨에게 비일비재하다. 밤늦게 전화가 온다. 급하게 어느 사이트에서 장애가 발생했는데 웹 애플리케이션 서버 쪽 문제인 것 같다. 그러니 빨리 와 달라. 그래서 찾아간 고객의 사이트에서 스파이크씨가 한 일이라고는 고작 랜 선 꽂아주고 라우터 한 번 껐다 켜준 일 밖에 없을 때 고객과 스파이크씨는 서로 얼마나 X씹은 얼굴일지 상상해보라. 그러니 문제가 발생했을 때에는 일단은 먼저 숲을 바라봐야 한다. 숲을 바라본 다음에 우리가 가진, 문제의 원인일 것이라고 생각하는 고정관념을 배제한 상태에서 문제의 원인을 추적해 들어가는 것. 그것이 웹 기반 시스템에서 문제를 접하는, 스파이크씨가 권하는 방법론이다.

웹 기반 시스템 버그 해결 프로세스
앞서 버그 사냥꾼 스파이크씨의 경험을 토대로 웹 기반 하의 시스템에서 어떠한 버그들이 있는지 사례별로 살펴보았다. 스파이크씨의 말처럼 웹 기반에서의 시스템이 일으키는 버그는 여타 다른 아키텍처에 비하여 상당히 복합적이고 다층적인 관점에서 문제 해결 능력을 필요로 한다는 것을 여실히 느낄 수 있을 것으로 생각한다.

<그림 1> 웹 기반 시스템 버그 해결 프로세스

여기서 짚고 넘어가야 할 것은 어느 문제 상황에서나 스파이크씨처럼 다양한 문제 해결 경험을 가진 이가 여러분 곁에 있을수는 없다는 것이다. 버그는 사람을 가리지 않고, 오히려 상황이 다급하고 주위에 전문가가 없을 때 더 잘 나타난다. 그게 버그의 습성이다. 따라서 필자는 스파이크씨에게 과연 웹 기반 시스템에서 버그를 해결하기 위한 방법론은 없겠는가 물어보았다. 스파이크씨는 비록 웹 기반 시스템이 복합적인 성격을 가지고 다양한 지식과 경험을 가진 이의 분석을 필요로 하는 것은 맞지만 그럼에도 불구하고 어느 정도의 수준을 가진 개발자 내지 운영자가 문제를 해결하는 데 있어 쉽게 접근해 볼 만한 방법론을 제시했다.

어디서 시작할까?
문제가 발생하고 버그가 예상되었을 때 디버깅을 하기 이전에 먼저 전체 웹 시스템이 어떻게 운영되는지를 점검해볼 필요가 있다. 만약 시스템 아키텍처에 대한 간략한 구성도가 있다면 그것을 보면서 점검해보면 좋을 것이다. 과연 아키텍처 각각의 구성원들이 서로 어떻게 연결되어 있는지를 살펴보자. 웹을 구성하고 있는 아키텍처 상에는 생각보다 상당히 많은 구성원들과 리소스 그리고 메시지 프로토콜로 이루어져 있는 것을 알아챌 수 있으며 이와 관련하여 당신이 운영자가 아니라면 운영자와 대화를 통해 각 구성상의 취약점은 없었는지 그리고 최근에 벌어졌던 다른 문제 상황과 변경된 사항들을 먼저 수집해 나가야 한다.

던져야 할 질문들
넓고 넓은 시스템 아키텍처 중에서 가장 먼저 살펴봐야 할 그 곳은 어디일까? 그 곳을 찾는 것이 문제 분석의 첫걸음이다. 이 결정을 위해 몇 가지 간단한 질문을 스스로에게 던져보아야 한다. 첫 번째로 이 문제의 증상은 무엇인가? 만약 에러 메시지가 클라이언트 브라우저에서 발생한 것이라면 아무래도 클라이언트와 맞물려 있는 여러 구성요소들을 의심해 볼 만할 것이다. 아니면 특정 프로세스가 죽거나 행 현상이 발생했다면 이것 역시 가장 먼저 살펴 볼 그 곳을 결정하는 데 중요한 단서가 된다. 물론 해당 프로세스가 죽거나 행 현상이 발생했다면 다음 절차는 해당 프로세스에 대한 행동을 기록하고 있던 로그 파일을 보는 행위가 될 것이 명백하다.

두 번째로 가져야 할 질문은‘언제 해당 증상이 발생하는가?’이다. 발생하는 시간과 발생하는 주기 등이 문제의 본질에 대해 이해하는 데 매우 중요한 단서가 된다. 예를 들어 사용자가‘계정 정보’페이지를 클릭할 때면 무조건 에러 메시지가 출력된다면 너무나 당연하게도‘계정 정보’와 관련된 소스코드를 먼저 볼것이다. 반면에 사용자 트래픽이 매우 높을 때에만 발생하는 현상이라면 무언가 시스템 리소스와 관련이 있는 문제라는 것을 직감할 수 있을 것이다. 반면에 아무런 시기적인 유사성이 없는 상황에서 발생하는 문제라면 이 문제에 제3의 구성원의 개입이 있을 수 있거나 좀 더 시간과 상황에 따른 유사성을 발견해내야할 것이다. 하지만 이렇게 간헐적으로 발생하는 문제가 가장 해결하기 어려운 문제임은 확실하므로 단단히 긴장해야 한다.

세 번째로 가져야 할 질문은‘최근에 시스템 변경사항은 무엇이었는가?’이다. 최근에 애플리케이션 혹은 시스템에 변경 사항은 없었는가? 무언가가 변경이 되었다면 그것이 원인이 되어 발생한 문제 혹은 버그임을 우선 의심할 수 있을 것이다.

버그를 고립시키기
쥐를 잡아본 적이 있는가? 쥐를 잡으려면 일단 쥐가 어디에 숨어있는지를 알아야 하고 위치를 알았다면 적절한 도구로 쥐를 야금야금 몰아가야 한다. 자 이제 어디에 버그가 숨어있는지를 눈치 챘다면 적절한 도구로 버그 사냥에 들어간다.

디버깅 툴
웹 기반 시스템에서 발생한 버그라는 것이 대부분 런타임 환경에서 발생하는 경우가 많기 때문에 디버깅하기가 상당히 까다롭기는 해도 요즘 출시되고 있는 각종 개발 툴에서는 런타임에서의 디버깅 환경이 꽤 유용할 만큼의 환경을 제공해준다. 그럼에도 불구하고 디버깅 툴에는 어느 정도 한계가 있다. 그 첫 번째가 운영환경에서의 버그일 경우 디버깅 툴로서는 잡아내는 게 여의치 않다는 것이다. 이를테면 사용자 접속이 얼마 이상일 때 발생하는 버그일 경우 주로 객체와 메시지 자체에 대한 정보만을 바라볼 수 있는 디버깅 툴만으로는 현상 파악에 무리가 있는 것이다. 따라서 자세한 정보를 위해서라면 한 손에는 디버깅 툴을 그리고 다른 손에는 또 다른 유용한 툴을 지니고 있어야 한다.

로그 파일
거의 대부분의 프레임워크와 미들웨어 및 리소스 관리 툴에서는 로그 파일을 남긴다. 때때로 특정 제품의 경우 성능 등의 이유로 최소한의 로그만을 남기는 경우가 있는데 대부분 로깅 수준을 조절하여 더 세밀한 정보를 볼 수가 있다. 로그 파일에는 단순히 각각의 서버가 제공하여 주는 것들 이외에도 JVM이나 네트워크스위치 등이 제공해줄 수 있는 파일(쓰레드 덤프와 힙 덤프 등)들도 있다. 이 뿐만 아니라 문제가 발생하고 있는 부분에 대한 자세한 추적을 위한 로그를 별도로 추가함으로써 문제의 원인을 좀 더 막다른 골목으로 좁혀볼 수 있을 것이다. 따라서 전체 시스템 아키텍처 구성도를 바탕으로 해서 하나라도 빠짐없이 로그파일을 챙기는 것이 문제 원인을 해결할 수 있는 지름길이다.

모니터링 툴
요즘 출시되고 있는 DB 서버나 웹 애플리케이션 서버, 웹 서버,메시징 엔진 제품 등은 더 편리한 관리 환경을 위해 비주얼한 형태의 모니터링 툴을 제공하여 자원의 상태 등을 파악하고 런타임 환경이 제대로 운영 중인지 파악하는 데 많은 도움을 주고 있다. 또한 이러한 적절한 툴이 없다 할지라도 간단한 스크립트를 이용하여 서버 상황을 이해하는 데 기본이 되는 여러 가지 정보를 추출하는 것이 가능하다. 이를테면 네트워크 연결 수나 DB 연결수 그리고 CPU와 메모리 활용 상태 등은 간단한 스크립트로도 추출하는 것이 가능하다. 이러한 툴을 쓰는데 인색하지 말라.

숙련된 버그 사냥꾼이 필요하다
이제까지 버그 사냥꾼 스파이크씨의 경험을 토대로 웹 환경에서의 버그의 유형과 이러한 버그를 잡아내는 대략적인 방법론에 대한 이야기를 들어보았다. 우리는 흔히 버그 없는 소프트웨어는 없다고 하고 단 백 줄도 안되는 소스코드에서도 얼마든지 버그는 존재한다고 한다. 그만큼 개발자에게 있어 버그는 여름철의 모기처럼 평생을 따라다니는 숙명과도 같은 존재다. 그럼에도 불구하고 웹 기반 시스템은 날이 갈수록 그 복잡도를 더해가서 하나의 웹 사이트 안에 포함되어 있는 프레임워크나 미들웨어 제품 그리고 각종 부가적인 서버들의 종류가 점점 더 다양해져가고 있다.

이는 곧 웹 기반 시스템이 점점 더 단순한 개발자로서의 능력보다는 전체 시스템에 대한 안목과 다양한 경험을 아우르는 능력을 가진 인력을 더 필요로 함을 반증하는 것이기도 하다는 생각이다. 때문에 이렇게 복잡해져가는 시스템에 대한 문제 해결 능력을 기르는 것은 개발 본연의 경험과 함께 매우 중요한 능력이라 생각하며 본 기사를 통해 더 깊은 웹 기반 시스템 문제 분석가의 길에 매력을 느끼는 독자들이 많아지면 바랄 것이 없겠다.

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
Posted by SB패밀리

플랫폼(Platform)과 프레임워크(Framework), 아키텍처(Architecture) 개념비교

 

참조 출처: 네이버 지식in

 소프트웨어 분야에서 프레임워크와 라이브러리, 플랫폼, 아키텍쳐를 비교해 보면, 다음과 같다.

 프레임워크: 소프트웨어의 뼈대 구조

 

프레임워크란 특정형태의 소프트웨어 문제를 해결하기 위한 상호 협력하는 클래스들과 인터페이스들의 집합. 즉 소프트웨어 콤포넌트들의 집합을 의미한다. 이는 여러클래스와 컴포넌트로 구성되고 좀더 높은 수준에서 패턴들을 조직화하며 다양한 애플리케이션에서 이용 가능한 범용성(generic)을 가진다.

 프레임워크는 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조이다. 지원 프로그램, 라이브러리, 언어, 다른 소프트웨어 구성 요소들을 엮어 주는 소프트웨어 등을 포함하고 있다. 따라서, 플랫폼도 프레임워크의 일종이라고 볼 수 있으며, MS사에서 닷넷 플랫폼을 닷넷 프레임워크라고 지칭하는 것도 틀린 것이 아니다.

 또한, UI 프로그램 개발을 위한 부분 만을 떼어내서 프레임워크라고 할 수도 있다. UI 프로그램 개발을 위한 부분 만으로는 완전한 소프트웨어 실행 환경이 되지 않으므로 플랫폼은 아니지만 프레임워크이다. 이러한 점에서 프레임워크와 플랫폼은 다른 경우가 많다.


프레임워크에 대한 내용의 이해를 돕기위해 라이브러리와 비교를 해보자. 라이브러리는 애플리케이션에서 호출할수 있는 함수와 루틴으로 구성되며, 필요한 클래스를 개발자가 불러오는 방식을 지닌다.

 프레임워크와 라이브러리의 관계는 구성적인 측면에서 라이브러리는 함수와 루틴들로 볼 수 있고, 프레임워크는 콤포넌트들로 볼 수 있다. 실제 사용하는 측면에서 라이브러리는 내부에서 불러서 사용하고, 프레임워크는 내부에서 호출이아니라, 자체가 그대로 동작하거나,상속을 받아 재구성하여 동작한다. 이러한 콤포넌트들은 라이브러리를 불러서 사용할 수 있다.


프레임워크(Framework)
  - 잘 정의된 문제도메인 안에서 성공적으로 어플리케이션을 작성하기 위해 필요한 가치 있는 지식을 내포함
  - 비교적 규모가 크고, 복잡하며, 다루기 어려움
  - 어플리케이션 프로그래머는 프레임워크의 인터페이스를 구현하거나 프레임워크 클래스를 상속하여 사용함
  - 프레임워크는 적절한 시기에 어플리케이션을 호출함(흐름에 대한 제어를 프레임워크가 수행)

라이브러리(Library)
  - 어플리케이션 프로그래머가 적절하다고 생각할 때 호출하여 사용함
    (
흐름에 대한 제어는 어플리케이션 코드에서 수행)
  - 라이브러리는 어플리케이션 프로그래머에게 코드작성규칙을 강요하지 않음 
  - 어플리케이션 프로그래머는 코드 작성시 에러 핸들링 정책에 신중을 기해야 함
 

플랫폼: 소프트웨어 실행 환경

 

가장 일반적이면서도 명료한 의미는 "소프트웨어가 실행되는 환경"이다. 개발 언어나 개발 환경을 플랫폼에 포함시키기도 하지만 이는 부수적 개념 혹은  확장된 개념에 불과하고, 핵심은 "소프트웨어가 실행되는 환경"이다.

 각 프로그램은 아무 플랫폼에서나 실행되는 것이 아니고 특정 플랫폼에서만 실행된다. 일반적으로, O/S는 모두 플랫폼이다. Windows는 윈도우즈 프로그램만을 실행시킬 수 있는 플랫폼이고, 리눅스는 리눅스 프로그램만을 실행시킬 수 있는 플랫폼이다.

자바 런타임 환경도 플랫폼이다. 자바 프로그램은 O/S에 대한 종속성은 거의 없고 자바 런타임 환경없이는 실행되지 않으므로 자바 런타임 환경을 주요 플랫폼으로서 필요로 한다. 마찬가지로 닷넷 프로그램도 닷넷 런타임 환경없이는 실행되지 않으므로 닷넷 런타임 환경이 플랫폼이 된다.


아키텍처: 소프트웨어의 주요 설계 구조

 

소프트웨어의 주요 특징들을 결정짓는 주요 설계 구조이다. 즉, 소프트웨어의 주요 구성 요소 및 구성, 이들간의 주요 인터페이스, 중요 동작 방식 등 소프트웨어의 주요 특징들을 결정짓는 모든 설계 구조를 포함한다.

 소프트웨어의 주요 특징을 결정짓고 소프트웨어 개발에 미치는 영향도 매우 커서 소프트웨어 개발에 있어서 가장 중요한 부분이라고 할 수 있다. 지원 프로그램, 라이브러리, 언어, 다른 소프트웨어 구성 요소 등과 같이 구체적인 구현을 포함하지 않는다는 점에서 프레임워크나 플랫폼과는 명확히 구분된다.

 

정리하자면, 이렇게 된다.

 

아키텍쳐 = 소프트웨어 설계 구조

프레임워크 = 소프트웨어 개발 구조  <-- 라이브러리 참조

플랫폼 = 소프트웨어 실행 환경 

Posted by SB패밀리

프레임워크를 만들었음에도 불구하고 초기 프레임워크 ㅐ념이 나올 때의 글만 보다가 요즘 다시 보니 새로운 느낌까지 들고 너무 책을 등한시 했다는 생각이 든다.
출퇴근시간이 1시간이상 소요되는 되다가 저녁먹고 나서는 건강을 위해서 운동을 해야하고
요즘 경제서적보랴 ... 한동안 등한시 해왔던 개발이론 분야....
다시 책을 집어 들고 인터넷에서 여러 개발자분들의 노고를 감사히 읽으면서 이해를 해야겠다.

프레임워크 생산성의 향상

•프로그램에서의 생산성 향상 방안 : 코드의 재사용
•Function, Procedure 개념 지원 언어의 출현, 이후 객체지향 언어가 출현
•컴포넌트 사용 : 재사용을 높이고 검증된 코드를 사용하게됨 --> SW 품질이 높아지고 개발비용/유지비용이 낮아짐
•컴포넌트 재활용과 디자인 재활용
•객체지향 프로그램에서는..
•클래스 : 기능을 모듈화 & 추상화 지원
•추상클래스 : 객체간 프로토콜 일치 가능
•동적바인딩 : 프로시저 호출 지연 바인딩(Late-binding)
•클래스 상속 : 서브클래스에서 기능을 추가/보완
•다형성 : 객체의 기능을 교체
•랄프존슨이 말한 프레임워크
•추상클래스들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용 가능한 디자인
•예제) 윈도우 애플리케이션용 프레임워크
•화면의 로직처리
•윈도우 그리는 컴포넌트
•통신 컴포넌트
•내부 정보 처리하는 도큐먼트 컴포넌트
•등등등..

Framework이란 무엇인가? 

 Ralph Johnson 이라는 사람은 추상클레스( abstract class) 들의 집합과 상호 협조하는 클래스들의 인스턴스 동작 방법으로 이루어진 재사용 가능한 디자인이라 정의.

프로젝트에 어울리는 잘 만들어진 프레임워크를 이용한 어플리케이션은 비록 거대해지더라도 프레임워크의 의도에 맞게 어플리케이션의 설계가 이루어짐. 때문에 어플리케이션에 의해 System의 안정성을 해치거나, 터무니없이 낮은 퍼포먼스를 내는 일은 거의 없을 것 임.

라이브러리와 프레임워크의 차이!
라이브러리는 개별적인 기능들을 집단형태로 묶음을 의미.
때문에 라이브러리를 이용해 문제를 해결하고자 할때는 메소드의 기능을 정확히 이해하고 사용해야 함.
프레임워크는 원하는 기능을 제공하는 모듈의 인스턴스와 이에 수반되는 여러가지 장치 들의 상호작용까지의 묶어서 정의 하게 됨.때문에 프레임워크에서 제공되는 기능을 사용하게 되면 이와 수반된 이미 검증된 작업의 플로우까지 함께 사용하게 되는 것입니다.
이렇게 함으로 해서 어플리케이션의 코드를 줄일 수 있고, 안정성을 높이며 개발 속도를  빠르게 할 수 있습니다.


라이브러리 대신 프레임워크 사용하는 이유

•라이브러리
•정의 : 해결하고자 하는 도메인 문제와 상관없이 재사용할 컴포넌트의 집합
•사용시 : 제공하는 메소드의 기능을 정확히 알고 있어야 함 (목적, 인자, 결과값)
•프레임워크
•정의 : 해결하고자 하는 도메인 문제에 특화된 인스턴스들이 함께 동작되는 컴포넌트 집합과 디자인
•사용시 : 필요한 지점에서 적절히 삽입하고 쉬운 사용, 세부적인 부분은 몰라도 됨
•프레임워크 = 반제품(Semi-Complete Application) : 적은 비용으로 App 만들기 위해 절반정도는 구현되어 있는 수준

•예제 : 신뢰성 있는 메시징, 트랜젝션 개발시
•라이브러리 : 각 라이브러리별 메소드를 알고, 개발해야 됨
•프레임워크 : WCF 쓰면 내부의 세부사항은 몰라도 기능 흐름만 파악하면 되며, 코드가 주어듬


좋은 프레임워크와 효과적인 사용법

•일반적인 프레임워크 사용방법
•1) 클래스의 서브클래스 생성
•2) 생성된 객체의 내부환경을 설정
•3) 프레임워크가 제시하는 표준 방법으로 App에 적용
•좋은 프레임워크의 요소
•효율성(Effectiveness) : 개발자에게 효율적이여야, 개발 속도를 빠르게 해야, 개발비용을 줄여야 함
•확장성(Extensibility) : 특정 도메인의 App 개발시 개발항목을 포괄하는 확장성을 가져야 함 (App이 삼각형 윈도우를 지원해야 한다는 식의 무리한 확장성은 포함 안해도 됨)
•적용규모(Coverage) : 구현사항을 어느 범위까지 적용할지?
•평이성(Simplicity)와 이해도(Understandability) : 교육이 쉬워야, 너무 복잡하거나 추상적이면 안됨
•통합성(Framework Intergration) : 다른 프레임워크나 라이브러리와 상호소통이 잘되면 좋다
•품질(Qualities) : 능률성,적용성,표준성.. 필수항목은 아닌듯
•안정성(Stability) : 개발코드에 정확한 계산과 결과물 도출


프레임워크 도입시 고려할 점

•필요이상으로 복잡해지고 코드나 객체가 커지면 안됨
•랄프존슨 : "원할하게 일할 수 있을 만큼 이 프레임워크가 쉽게 느껴지는가?"
•프레임워크 도입시 더 비효율적이 될거 같으면 때려치워라! (개발비용, 교육, 문서화 작업 등...)


프레임워크 만들기

•추상 개념을 먼저 생각하기는 어렵다.. 먼저 구현해 보자
•먼저 구현 -> 문제 해결 방법을 작은 집합으로 나눔 -> 구현체 중 컨텍스트를 인자화해 변경할 수 있도록 수정
•도메인 전문가가 만들때 : Up-Front 디자인 방식
•코딩 전문가가 만들때
•반복적인 구현을 통해 코드를 개선해 나감
•반복 개발시 Hot Spots과 Frozen Spots를 잘 구분해서 다음번 개발시 잘 구성하자
•App이 다 만들어지면 이전 프레임워크와 비교하여 재사용성 부분을 반영
•구현클래스에서 추상클래스 유추하기
•구현클래스에서 일반적인 부분들을 뽑아서 추상클래스 만들기
•1) 공통 기능의 구현클래스 준비
•2) 구현 클래스의 공통 기능을 하나의 메소드로 옮긴다.
•3) 옮겨진 구현 클래스의 멤버로 있는 메소드의 이름을 동일하게
•4) 이름을 변경한 메소드의 인자, 리턴값을 동일하게 일반화
•5) 해당 메소드를 분리하거나 병합할 필요시 리팩토링
•6) 같은 메소드명이지만 다른 구현이라면 추상클래스에서 메소드명을 반영
•7) 구현 클래스의 메소드 내용이 같다면 수퍼클래스로 구현을 옮김
•상향식 설계
•하향식 : 구현 클래스 먼저 만들고 이를 바탕으로 추상클래스 만듬
•상향식보다 쉽다.
•R = I + J = AX + AY = A(X + Y) --> 여기서 A는 공통부분

필요한 설계 원칙
 
•의존 관계 역전 원칙(The Dependency Inversion Principle)
•인터페이스 분리 원칙(The Interface Segregation Principle)
•리스코프 치환 원칙(The Liskov Substitution Principle)
•단일 책임 원칙(The Single Responsibility Principle)
•개방 폐쇄 원칙(The Open-Closed Principle)


프레임워크 개발의 9 단계

•http://st-www.cs.illinois.edu/users/droberts/evolve.html
•시간축에 따라 동시에 진행할 수도 있다.
•1) Three Example : 세가지 애플리케이션 패턴
•2) White-box Framwork : 화이트박스 패턴
•3) Component Library : 컴포넌트 라이브러리 패턴
•4) Hot Spots : 핫 스팟 패턴
•5) Pluggable Object : 플러그러블 오브젝트 패턴
•6) Fine-grained Object : 파인-그레인드 객체 패턴
•7) Black-box Framework : 블랙박스 패턴
•8) Visual Builder : 비주얼 빌더 패턴
•9) Language Tools : 언어도구 패턴

프레임워크 개발은 여러 도메인에 대하여 여러가지 문제를해결할 수 있도록 만들어지기 때문에 특정 도메인의 간단한 문제를 해결하기 위하여 기능과 구현이 복잡해지고 코드의 크기나 객체의 크기가 커질 수도 있음.

Posted by SB패밀리


프레임워크의 정의
•더글라스 슈미츠 (POSA2 저자) : 프레임워크는 도메인 기반의 지식으로 구성된 객체 구조와 기능을 가지고 있는 "반쯤 완성된 애플리케이션"이다.
•랄프존슨 : 추상클래스들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용 가능한 디자인


프레임워크 개발을 위해 고려할 5가지 기본 속성
•1) 조직 : 조직을 먼저 구성하지 마라. 비지니스 파악 --> 관련된 프로세스 정제 --> 프로세스에 맞게 IT 조직 구성
•2) 계획 : 땅콩버터 (특징을 중심으로 골고루 구현하는 Bottom-UP 방식. 기능중심의 팀이 필요), 마천루(시나리오 중심으로 구현, 특정모듈에만 집중적인 개발이 됨)
•3) 아키텍처 : 아키텍처 타입, API, 실행, 의존성을 고려해 Layering을 구축. 의존성 분석을 위해 xDepend 같은 툴을 사용
•4) 설계 : 메인 시나리오에 부합되는 코드 샘플 만들기 -> 객체 모델 정의. 디자인 스튜디오 등의 툴을 사용하여 설계
•5) 개발 : 80/20룰을 적용해 효율성 고려
•6) 그밖에 : 산출물 가독성, 문서화, 네이밍룰, 프레임워크 매뉴얼


프레임워크 이해를 위한 패턴언어
•1) 프레임워크 선택하기 : 화이트박스(hot spots의 수정 위해 상속과 동적바인딩을 사용)/블랙박스(hot spots의 수정 위해 인터페이스를 사용)/그레이박스 프레임워크
•2) 프레임워크를 이용한 프로젝트 레퍼런스 만들기 : 적당한 예제단위로 레퍼런스를 구축한다면 효율성이 높음
•3) 프레임워크 발전시키기 : 도메인 적용되고 나타나는 문제를 해결하여 다시 프레임워크에 반영해야
•4) 프레임워크 학습
•5) 사용 경험의 보전 방법 : 프레임워크 사용경험을 문서화시키고, 실전코드들을 레퍼런스나 케이스로 정리할것
•6) 애플리케이션 도메인의 이해 : 프레임워크가 App에서 구현할 문제를 해결할 수 있는 범위 파악하는 것이 중요
•7) 프레임워크 아키텍처의 이해 : 프레임워크는 App에 직접적 영향 미침, 구조 파악하면 정확한 프레임워크 사용 가능
•8) 프레임워크 내부 디자인의 이해 : 프레임워크가 복잡하다고 느끼는 것은 내부 디자인이 복잡해서임.
•9) 프레임워크 코드의 이해 : 프레임워크 개발자의 코드는 후배들의 본보기가 되므로 잘 짜라


프레임워크 엔지니어링
•고려할 6가지 사항
•조직 (가장 강력한 설계 툴) : 콘웨이의 법칙 : 팀 구조가 소프트웨어 구조에 영향 미침
•계획 (프레임워크를 올바르게 구축하기 위한 계획) : 마일스톤 = 땅콩버터 + 마천루 (인프라 구축 초기에는 땅콩버터, 인프라 구축된 후 땅콩버터 유지하되 점진적으로 마천루 혼합)
•아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들) : IoC 사용하여 의존성 제거할것, xDepend 도구 사용
•설계 (품질을 보장하기 위해 고려할 사항들) : 메인시나리오 작성 ==> 시나리오에 부합되는 코드샘플 작성 ==> 개발자들에게 피드백하여 정제 ==> 객체 모델 정의 (프레임워크 디자인 스튜디오 도구 사용), 동일성을 위해 FxCop, StyleCop 도구 사용
•개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들) : Feature별 Quality Gate 구성할것.
•그 외에 고려해야 되는 것들 (가독성, 문서화) : 문서 제공할것
•좋은 프레임워크란..
•쉽게 배워야
•문서 없이도 쉽게 사용해야
•실수하지 않도록 직관적이여야 (실패하기 힘들도록..)
•프레임워크 사용하면 코드가 읽기 쉬워야 (유지보수성도 좋아짐)
•확장이 쉬워야
•사용자를 고려해야..


프레임워크 구축과 발전 - 랄프존슨의 9가지 패턴
•1) 세가지 애플리케이션 패턴 : 3개 이상의 App을 만들어서 재사용 모듈 파악
•2) 화이트박스 패턴 : 인터페이스를 사용하여 상속하라. 없으면 구현클래스에서 유추하여 만들어라. 상속을 이용하여 프레임워크의 기능 확장 구현을 반복한다.
•3) 컴포넌트 라이브러리 패턴 : 재사용하지 않는 클래스는 프레임워크에 넣지않고, 애플리케이션의 구현클래스에 위치
•4) 핫 스팟 패턴 : 화이트박스 패턴으로 계속 추가하고, 컴포넌트 라이브러리 패턴으로 계속 제거 --> 기존 클래스와 추가될 클래스의 관계를 정의하면서 확장하여 중복을 막자
•5) 플러그러블 오브젝트 패턴 : 객체 생성시 다양성 구분에 필요한 인자 사용 --> 객체가 인자에 따라 행동하게 개발
•6) 파인-그레인드 패턴 : 간단한 API가 복잡한 API보다 사용하기 쉽다 --> Small Objects Pattern
•7) 블랙박스 패턴 : 애플리케이션은 요구변경에 유연해야 함 --> 클래스의 확장에는 열려있고, 수정에는 닫혀 있어야 함. --> 상속보다는 구성을 사용
•8) 비주얼 빌더 패턴과 언어 도구 패턴 : 프레임워크 정리한 문서, 프레임워크 사용을 도와주는 툴 등을 제공할것

 

 

애플리케이션과 프레임워크 동시 개발
•1) Framelets for Multiple Use : 심플할 수 있고, 3번이상 재사용될꺼면 프레임워크를 개발해라
•2) Budget Factor 2.5 : 프레임워크는 애플리케이션보다 비싸다. F개발 = 2.5 * A개발
•3) Two Pilot Applications : 매우 보편적인 요구사항을 가진 애플리케이션 2개를 먼저 만든 후 프레임워크 개발
•4) Small Functions : 기능은 많고 작고 단순하게 구현하라. 이해하기 좋고 많은 요구사항에 적합하다
•5) User Involvement : 사용자에게 같이 참여시켜서 확신을 줘라. 교육/툴/테스트/튜토리얼 제공하라
•6) Tests Based on Pilot Applications : 회귀테스트 - Pilot Applications에서 핵심 컴포넌트 추출 --> 보편적 시나리오 추출 --> 테스트
•7) Double Change Request : 기능추가 요구가 있을때 적어도 2팀 이상 원할때 추가하라.


프레임워크 리팩토링
•리팩토링 검증방법 : 회귀테스트
•테스트 케이스 작성 과정 : 테스트 대상 클래스 선정 --> 테스트 대상 메소드 선정 --> 테스트 시나리오 선정 준비
•테스트 시나리오 작업 : 테스트 클래스 역할 파악. 메소드 역할 파악. 메소드 파라메터 분석. 메소드 내 분기문 분석. 메소드 리턴값 분석....
•테스트 작성 : 테스트 의도 명확히 드러내기. 예외테스트도 수행.
•테스트 코드 리팩토링 : 반복적으로 사용되는 코드는 별도의 추상 클래스나 상위 클래스로 추출하여 코드 중복 제거

출처: http://kimstar.pe.kr/blog/190 <-- 여기 가시면 더 잘 정리되어 있습니다.

Posted by SB패밀리