▣ S/W tip - 해당되는 글 35건
출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&keywords=%C0%D0%C0%BB%B0%C5%B8%AE&page=2&wr_id=37493
대체(바꿈)’라는 말은 지금 사용하고 있는 무언가를 다른 것으로 대신한다는 의미이다. 예를 들어 자동차를 가지고 출퇴근을 하다가 건강과 환경을 위해 자전거로 출퇴근을 한다면 자동차를 대체하는 교통수단이 자전거가 된다. 집에서 사무실까지 이동하는 것을 지원한다는 본질적인 목적에 대한 수단이 자동차에서 자전거로 바뀌는 것이다. 프로젝트로 인해 서울에서 대전으로 출퇴근을 해야 한다면 자전거로 이동은 가능하겠지만 10시간 이상(시속 15km 기준인 경우) 소요되는 경로를 매일 출퇴근할 수는 없는 노릇이다. 건강과 환경이라는 취지는 좋지만 무모한 일이 될 수 있다. 오히려 대전역까지 자동차나 열차로 이동을 하고 대전역에서 자전거를 이용해서 사무실로 출퇴근하는 것이 효율적일 것이다.
자동차가 자전거를 대체한다고 해서 시속 80km의 성능과 안락한 의자, 최적의 음향 시스템을 지원할 수 있다는 것은 아니다. 같은 자동차라는 표현에도 최대시속 300km 이상의 수퍼카와 다른 차들과는 분명한 차이가 있다. 대체를 결정하는 기준이 의도한 목적을 달성하느냐 여부가 아니라 가지고 있는 것이 무엇이고 무엇을 하고 싶은지가 되어야 한다. 원하는 목적지에 빠르게 도달하는 것이 하고 싶은 것이라 할지라도 가지고 있는 것(도로교통법, 예산)에 제약이 있다면 수퍼카를 선택하는 것이 최적의 선택은 아니라는 것이다.
.jpg)
<그림 1> Rocket Bike - 출처 : popsci.com
하지만 유행에 민감한 한국적인 정서는 기술 분야에서도 예외는 아니다. 가지고 있는 것에 대한 명확한 인식이 없이 유행을 따라가거나 상급부서의 지침을 무작정 따라가곤 한다. 그래서 자전거가 필요한 공간에 수퍼카를 배치하기도 하고 자동차가 필요한 시점에 자전거를 가져다놓고 개발팀에 무리수를 요구하기도 한다. 안 되는 걸 알면서도 개발팀에서는 무리수를 두고 개발을 완료한다. 그럼 ‘세상에 이런 일이‘에 나올만한 제품이 나오기도 한다. 퍼포먼스나 데모를 위해 만들어진 것이라면 모르겠지만 그렇지 않다면 프로젝트를 마무리하고 유지하기 위한 비용이 더 들어갈 수도 있고 결국에는 제품을 버려야 하는 시점이 올 수도 있다(물론 실용적인 제품이 될 수도 있다. 전동 자전거나 가솔린 엔진을 달고 있는 자전거도 그런 아이디어에서 나온 것이다. 하지만 아직은 가격대가 만만치 않다). 예측할 수 없는 미래에 대응하기 위해서는 새로운 것에 과감히 도전하는 혁신적이고 창의적인 정신이 필요하지 않느냐는 반론이 있을 수 있다.
도전’과 ‘무리수’는 묘하게 수준을 조절하기 힘들기 때문이다. 명확한 정의는 아니지만 유사한 내용의 컬럼을 인용하면 ‘도전’은 약간 힘들어지긴 하지만 어느 정도 성공을 보장할 수 있고 이로 인한 성취감을 가질 수 있어야 한다고 한다. 도전의 수위는 관련된 팀의 능력이나 주변 맥락을 보면서 결정해야 한다는 것이다. 인기 있는 TV 프로그램인 ‘무한도전’의 아이템을 보면 도전의 수위를 어떻게 조절하느냐에 따라 이슈가 되기도 하고 재미없는 프로그램이 되기도 한다.
HTML5와 관련된 이슈도 마찬가지로 접근할 수 있다. 웹과 관련된 기업의 HTML5에 대한 접근은 현 시점에서 볼 때는 무리수인 것처럼 보이지만 장기적인 관점에서 바라볼 때 손익을 하나하나 챙기고 있을 것이다. 현실세계에서 가지고 있는 것이 무엇이고 무엇을 하고 싶은지 다시 한 번 생각해보고 있을 것이다.
다시 찾아온 네트워크 컴퓨터
네트워크 컴퓨터는 특정 목적을 가지고 만들어졌다. 기존 개인용 컴퓨터에 불필요한 장치를 없애고 서버에 올라와 있는 애플리케이션을 실행시킬 수 있는 기능과 통신 기능을 강화했다. 불필요한 요소를 제거했기 때문에 장비의 가격을 내릴 수 있었고 특히 기업 입장에서는 정보의 보안이나 관리 비용 등의 측면에서 획기적인 개념이었다. 하지만 이런 개념이 처음 나왔을 때가 1995년이었고 당시 네트워크 환경은 아직 모뎀을 주로 사용하던 시절이었기 때문에 머릿속에 있는 아이디어를 그대로 실현하기에는 어려운 환경이었다. 같은 시기 출시된 윈도우 95는 운영체제 부분에서 엄청난 점유율을 차지하며 향후 독점적인 지위의 기반을 만들게 되는 시기였다. PC 제조업체 입장에서 윈도우와 연합으로 지속적인 PC 업그레이드 수요를 확보할 수 있게 됐지만 네트워크 컴퓨터는 저렴한 비용에 관리적인 측면에서도 이슈를 만들지 못하게 돼 부정적인 입장을 취했을 수도 있다.
네트워크 컴퓨터는 환경적인 요인과 범용적인 확장 실패로 더 이상 진행되지 못했지만 인터넷 접속기기라는 이름으로 다양한 기기들이 2000년대 다시 등장하기 시작했다. PC 보급의 확대와 인터넷 이용자 수의 지속적인 증가는 이러한 예측을 긍정적으로 바라보게 했다. 넷플라이언스의 아이오프너(i-opener)와 같은 제품은 원가의 3분의 1 수준의 가격으로 단말기를 판매하였고 주요 업체에서 앞 다투어 신제품을 선보였다. 하지만 1년이 채 못 돼 넷플라이언스는 해당 사업을 철수했으며 다른 기업들도 급격한 적신호가 켜지면서 관련 사업을 정리했다. 이런 배경에는 여러 가지가 있지만 우선 도입기의 시장에 너무 많은 업체가 참여하면서 경쟁이 과열됐고 특정 ISP와 연계해서 저렴하게 제공하던 시스템이 단순한 해킹시도로 다른 ISP와 호환할 수 있다는 것이 알려지면서 월단위 과금이라는 서비스 기반이 무너지기도 했다.
.jpg)
<그림 2> i-opener
다른 환경적인 요인도 있었지만 네트워크 컴퓨터가 혁신적인 시도에도 불구하고 성공을 거두지 못했던 것은 가지고 있는 것 중 무엇인가가 부족했던 것이다. 이와 반대로 2000년대 초반 소개된 X-인터넷과 RIA가 지금까지 착실히 성장해 온 배경에는 서버/클라이언트 시스템과 인터넷만으로는 부족했던 무언가를 하나로 적절하게 제공해주겠다는 것이 명확했기 때문이다. 현재 시점에서 사용 가능한 자원을 적절하게 활용할 수 있었고 도전 가능한 명제에 접근했던 것이 사용자의 요구사항을 뒷받침해 줄 수 있었다. 처음부터 경쟁 우위에 올라서기 위해 3D와 같은 기능을 내세웠다면 구현은 가능했겠지만 범용적인 사용자 확보에 실패하고 기억 속에서 사라졌을 것이다. 어도비나 마이크로소프트가 PC 시장에서 그래픽 카드의 성능이 어느 정도 확보됐다고 파악된 시점에 해당 제조업체와 공동의 마케팅을 펼치는 것은 그동안 여러 차례 실패를 교훈삼아 만들어낸 결과라고 할 수 있다.
공식적인 판매 일정을 발표한 구글의 크롬북은 이전의 네트워크 컴퓨터나 인터넷 접속기와 비슷한 개념인 것 같지만 아이패드와 같은 스마트패드가 익숙한 세대를 위한 디바이스로 안착할 수 있을지 많은 기대를 모으고 있다. 안정적인 제조업체의 지원과 기업용 시장에서 기존 솔루션들을 크롬 기반으로 제공할 수 있는 목록을 확보하고 있음을 발표해 크롬북을 가지고 무엇을 할 수 있는지 명확하게 보여주고 있다.
Write once, run everywhere
‘Write once, run everywhere’라는 표현은 자바의 크로스 플랫폼 지원을 가장 잘 표현하는 문구로 알려져 있다. 물론 자바 자체의 아이디어보다는 그 이전에 만들어진 아이디어를 인용한 것이다. RIA 플랫폼 중에서도 이런 개념을 일찍이 사용한 오픈소스 플랫폼이 있었는데 바로 오픈라즐로(OpenLaszlo)가 그 주인공이다. 2000년대 중반부터 하나의 애플리케이션이 웹브라우저뿐 아니라 주요 운영체제에서 동작하고 데스크톱 클라이언트 단독으로 실행하거나 모바일 디바이스까지 지원할 수 있는 개념을 만들어놓고 있었다. 국내에서도 오픈라즐로 기반으로 쇼핑몰이 만들어졌고 커뮤니티가 어느 정도 활성화될 듯 보였으나 오픈소스 자체에 대한 신뢰가 부족했고 타 플랫폼에 비해 빠른 대응을 하지 못해 국내에서는 더 이상 레퍼런스나 자료를 찾기 힘들게 됐다. 하지만 2007년 4.0 버전을 발표하면서 하나의 애플리케이션을 플래시와 DHTML로 컴파일할 수 있는 구조를 만들었다.
.png)
<그림 3> 오픈라즐로
얼마 전 애플에서 플래시에 대한 이슈를 제기했을 때 Gliffy라고 하는 웹 기반 다이어그램 도구를 서비스하는 회사에서는 플래시를 지원하지 않더라도 오픈라즐로 기반으로 애플리케이션이 구성되어있어 언제든지 어떤 디바이스든 서비스를 할 수 있다는 글을 블로그에 남기기도 했다(하지만 아직까지 별도의 아이패드용 앱이나 사이트를 제공하지는 않는다).
오픈라즐로가 이렇게 멋진 개념에도 불구하고 성공을 하지 못했던 이유는 워크플로우를 사로잡지 못했다는 것이 가장 큰 벽이었다. 기획 → 디자인 → 개발 → 테스트로 이어지는 가장 대중적인 개발 프로세스에서 모두가 만족할 수 있는 도구를 제시하지 못한다면 쉽게 받아들여지지 않는다. HTML5가 등장하면서 몇몇 업체에서 기존 콘텐츠를 HTML5로 변환하는 기술이 등장했다. 이런 기술은 초기에 흥미를 유발할 수 있겠지만 임시적인 방편일 뿐 그 자체가 프로세스가 될 수는 없기 때문에 크게 주목받지 못하고 있다. 변환 기술보다는 하나의 코드로 관리할 수 있는 오픈라즐로의 접근 방식을 택한 기업들은 비교적 안정적인 코어(최근 방송을 타고 있는 운동 가이드 프로그램에서 몸의 중심을 잡는 속 근육을 나타내는 말이다. 플랫폼에서도 마찬가지로 중심을 잡아 줄 수 있는 무언가가 필요하다)를 가지고 있기 때문에 장기적으로 유연한 정책을 택할 수 있으며 환경의 변화에 쉽게 적응할 수 있다.
어도비 역시 오픈 스크린 프로젝트를 기반으로 everywhere와 비슷한 anywhere라는 이슈를 내세우고 있다. 작년 5월 어도비 사이트에는 공동창립자이며 이사회 회장인 척 게쉬케(Chuck Geschke)와 존 워녹(John Warnock)의 글을 보면 ‘모바일 디바이스의 수가 컴퓨터의 수를 앞지르게 될 것이며 모든 사용자가 퍼블리셔가 될 수 있고 콘텐츠를 언제 어디에서나 액세스할 수 있는 등 웹이 지향해야 하는 미래’라고 표현하면서 개방적인 시장 안에서 웹상에서 제공하는 선택의 자유를 누릴 수 있게 해야 한다고 주장하고 있다. 최근 공개된 CS5.5 버전에서는 모바일 개발 지원 대상을 확대하고 다양한 시나리오에 따른 효율적인 워크플로우를 제공하고 있어 이러한 주장을 뒷받침하고 있다.
하지만 anywhere에서의 경험이 모두 동일한 것은 아니다. 현재 제공되고 있는 플래시 플레이어 10.3이 동작하려면 안드로이드 2.2 버전을 지원해야 하며 특정 기준에 적합한 디바이스를 필요로 한다. 어도비에서는 내부적으로 DCTS(Adobe Device Certification Test Suit)를 거치도록 제안하고 있다. 그럼에도 플래시 플레이어와 같은 하나의 인터페이스를 유지할 수 있다는 것은 최대 강점이 될 수 있다. 물론 잦은 버그나 보안 이슈로 인해 플래시 플레이어의 코드를 개방하라는 압력을 받고 있지만 단편화를 막기 위해서라도 플레이어만큼은 놓지 않을 것이다.
.jpg)
<그림 4> Pidion 산업용 단말기
엔터프라이즈에서 HTML5
기업 내부 사용자들이 활용하는 디바이스가 다양해지면서 예전처럼 통제하기가 어려워졌다. 단체로 디바이스를 구매하고 개발 시 해당 디바이스가 표준이 될 수 있었던 시절에는 요구사항에 대한 수용이 어느 정도 가능했다. 하지만 최근의 상황은 1년에도 몇 차례 새로운 디바이스가 선보이면서 예전처럼 최적화된 요구사항에 대한 수용은 불가능해졌다.
얼마 전 SAP에서 진행된 기술 컨퍼런스에서 ‘대기업들은 2년 뒤면 비즈니스 소프트웨어를 여러 단말기 환경에서 제공하기 위해 대부분 HTML5를 사용할 것’이라는 발언이 나왔다. 그리고 구글 크롬북 프로젝트에 SAP을 비롯한 비즈니스 벤더들이 깊이 관여하고 있어 이러한 발언을 뒷받침해주고 있다. 이런 이야기가 언론에 노출되면 많은 이들이 기업용 시장도 HTML5로 가야겠다 싶어 모든 걸 버리고 HTML5에 올인할 수도 있다.
이미 웹기반으로 그룹웨어를 서비스하는 몇몇 업체들은 모바일 기반 서비스를 제공하고 있다. 간단한 인증만으로 이메일, 일정관리, 결재 등의 항목을 통합 관리할 수 있도록 서비스를 제공하고 있다. 첨부된 파일을 직접 열어볼 수 없는 경우에는 이미지로 변환해서 보여주거나 팩스나 인터넷 전화를 연동할 수 있는 기능을 제공한다. 하지만 동일한 서비스를 받고 있다고 할지라도 모바일 디바이스의 종류에 따라 제공되는 서비스가 달라질 수 있다. 예를 들어 ‘실시간 알림 서비스는 갤럭시 S에서만 지원됩니다’와 같은 안내문이 제공된다면 분명히 디바이스에 따라 사용자 경험이 달라질 수 있다는 것이다. 모바일 디바이스에서 결재를 진행할 수 있다는 것은 동일하지만 새로 받은 메시지를 즉시 확인할 수 있는지의 여부는 업무 성격에 따라 무척 중요한 목적이 될 수 있다.
무엇을 하고 싶은지에 대한 질문을 던져보면 기업 내에서 HTML5를 어떻게 수용해야 할지 다시 한 번 고민해보게 된다. 바코드 리더기를 생각해보자. 최근 유행처럼 사용하는 QR 코드는 대부분의 스마트폰 카메라로 인식할 수 있다. QR 코드만이 아니라 바코드 역시 내용을 인식하고 특정 상품 정보를 바로 보여주기도 한다. 그럼 기존 바코드 리더기를 스마트폰이 대체할 수 있을까? 대체는 할 수 있겠지만 하고 싶은 것은 아닐 것이다. 길을 지나가다가 영화포스터를 보고 포스터에 있는 QR 코드를 인식해서 정보를 보는 것은 가능한 일이지만 마트에서 물건을 계산하기 위해 스마프폰의 카메라를 동작시키고 코드를 인식시켜 데이터를 단말기에 연동시키는 것은 결코 추천할만한 일은 아니다.
기업 내 시스템의 복잡성도 새로운 기술의 도입을 어렵게 하는 측면이 있다. 브라우저에서 HTML5 기술을 적용하기 위해서는 IE9 이상의 브라우저가 설치되어야 하고 이를 위해서는 윈도우 비스타 이상의 운영체제로 업그레이드가 되어야 한다. 하지만 기존에 사용하던 장비(더 이상 생산되지 않으며 당장 다른 것으로 대체할 수 없는)에서 지원하는 운영체제가 XP까지라면 어떻게 해야 할까? IE외의 다른 브라우저를 선택할 수 있겠지만 그 또한 다른 시스템의 제약 때문에 어려울 수 있다. 일반 사용자는 몰라서 새로운 기술을 받아들이지 못한다면 기업 사용자는 여러 가지 제약으로 새로운 기술을 만나지 못할 수 있다는 것이다.
그럼에도 미래의 환경에서는 HTML5를 좀 더 자연스럽게 받아들일 수 있을 것이다. 이를 위해 많은 기업들이 기존의 기술과 어떻게 적용하고 융합시킬지 고민하고 있다. 당장은 하나로 합치기 어려우니 선택하는 것이 하이브리드라는 전략이다.
하이브리드가 최선의 선택일까?
하이브리드는 잡종이나 혼합물을 의미하는 단어이다. 비슷한 단어로 퓨전이란 단어도 많이 사용이 된다. 서로 같은 의미인 것 같지만 차이가 있다. 하이브리드는 특정한 목표를 달성하기 위해 두 개 이상의 요소가 함께 공존하는 것이다. 최근 출시되는 자동차 중에서 많이 들을 수 있는 것이 하이브리드이다. 아예 ○○ 하이브리드와 같은 식으로 제품이 출시되기도 한다. 주행 상태에 따라 가솔린 기관과 전동 기관이 적절하게 작동하는 것이다. 하이브리드 자동차는 탁월한 연비와 배출가스 감소, 가속성, 승차감 등의 장점을 가지고 있으며 여러 업체들의 선의의 경쟁으로 하이브리드가 가지는 단점을 지속적으로 보완하고 있다. 퓨전은 서로 다른 물체가 녹아 처음과 전혀 다른 특성을 보이는 것이다. 이전과 전혀 새로운 기능이 생기는 것이다. 융합 기술이라고 이야기하는 것들과 퓨전 음악에 사용되는 악기나 음악 자체를 이야기할 수 있다.
.png)
<그림 5> 하이브리드 자동차 작동원리 - http://k5.kia.co.kr
모바일 애플리케이션 개발에서 하이브리드를 이야기하는 것은 기존의 콘텐츠 개발 기술을 그대로 활용하면서 디바이스의 기능을 활용하려는 특정한 목표를 달성하기 위해 두 가지 기술을 적절하게 조합시키려 하기 때문이다. 하이브리드 애플리케이션 개발을 지원하기 위한 API를 공통으로 사용할 수 있으며 개발자는 콘텐츠와 비즈니스 영역에 좀 더 집중할 수 있게 된다.
투비소프트의 엑스플랫폼도 하이브리드형 통합 개발 플랫폼을 표방하고 있다. 데스크톱, Ajax, 모바일 애플리케이션 개발을 하나의 플랫폼에서 구현하고 적절하게 배치할 수 있는 구조를 제시하고 있다. 하나의 프로젝트 내에서도 필요한 업무 요구사항에 따라 적합한 기능을 제안할 수 있다. 웹의 미래는 HTML5인데 HTML5만 가지고 구현하면 안될까? 물론 가능하다. 하이브리드 차량 역시 하이브리드 따위는 버리고 전기만으로 움직이는 자동차를 만들면 된다. 전기 자동차는 아직까지 배터리를 최적화하는 이슈가 남아있다. 조만간 다가올 미래의 선택은 전기 자동차가 될 수 있지만 현재 가지고 있는 것을 기준으로 보았을 때 효율적인 선택은 하이브리드라는 것이다. 개발 플랫폼에 있어서 하이브리드도 마찬가지이다. Ajax나 HTML5 기술을 기반으로 구현할 수 없는 것이 아니라 그에 따른 비용, 성능, 최적화, 외부 기기와의 연동 등과 같은 다양한 이슈가 있을 수 있다는 것이다. 다시 한 번 강조하지만 가지고 있는 것이 무엇인지, 하고 싶은 것이 무엇인지 생각해보아야 한다.
여러 가지 논란 속에서도 빛을 내고 있는 TV 프로그램 중에 ‘나는 가수다’라는 서바이벌 프로그램이 있다. 흥미롭게도 시청자의 관심은 서바이벌 자체보다도 ‘같은 노래가 저렇게 다가올 수 있구나’라는 놀라움이다. 같은 코드를 가지는 노래지만 편곡 과정과 어떤 가수를 만나는지에 따라 전혀 다른 노래로 다가오기도 한다. 그럴 때면 이 노래는 이 사람이 불렀어야 하는데 하는 아쉬움을 이야기하기도 한다. 하지만 ‘적합한’이라는 말은 기술이 사용되는 시점의 여러 가지 맥락에 영향을 받는다는 것을 잊지 말아야 한다. 오래 전에 촬영된 뮤직비디오를 지금 보면 우습게 보이겠지만 그 당시에는 얼마나 그 모습에 열광했었는지 기억해보자. 지금 우리 팀이 가지고 있는 것과 하고 싶은 것을 다시 한 번 생각해보자.
출처 : http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=104&docId=66572761&qb=7ZSE66Gc6re4656Y67CNIOyYiOyZuOq3nOy5mQ==&enc=utf8§ion=kin&rank=1&search_sort=0&spq=0&pid=gmlZywoi5UsssZ9wfxNsss--194387&sid=ThgEAAPvF04AAA09Ddk
객체 지향 프로그래밍(Object-Oriented Programming)은 컴퓨터 프로그래밍의 패러다임의 하나이다. 객체 지향 프로그래밍은, 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 또한 프로그래밍을 더 배우기 쉽게 하고 소프트웨어 개발과 보수를 간편하게 하며, 보다 직관적인 코드 분석을 가능하게 하는 장점을 갖고 있다. 그러나 지나친 프로그램의 객체화 경향은 실제 세계의 모습을 그대로 반영하지 못한다는 비판을 받기도 한다.
객체지향 프로그래밍의 기본 구성 요소
- 클래스(Class) - 같은 종류(또는 문제 해결을 위한)의 집단에 속하는 속성(attribute)과 행위(behavior)를 정의한 것으로 객체지향 프로그램의 기본적인 사용자 정의 데이터형(user define data type)이라고 할 수 있다. 클래스는 프로그래머가 아니지만 해결해야 할 문제가 속하는 영역에 종사하는 사람이라면 사용할 수 있고, 다른 클래스 또는 외부 요소와 독립적으로 디자인되어야 한다.
- 객체(Object) - 클래스의 인스턴스(실제로 메모리상에 할당된 것)이다. 객체는 자신 고유의 데이터(attribute)를 가지며 클래스에서 정의한 행위(behavior)를 수행할 수 있다. 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용한다.
- 메서드 (Method), 메시지 (Message) - 클래스 로부터 생성된 객체를 사용하는 방법으로서 객체에 명령을 내리는 메시지라 할 수 있다. 메서드는 한 객체의 서브루틴(subroutine) 형태로 객체의 속성을 조작하는데 사용 된다. 또 객체 간의 통신은 메시지를 통해 이루어진다.
객체지향 프로그래밍의 특징
- 캡슐화 (Encapsulation) - 하나의 문제를 해결하기 위한 데이터와 메서드를 하나의 단위로 묶는다는 것으로서, 클래스의 내부 정의에 대해 외부에서 볼 수 없도록 하는 것이 특징이다. 클래스에 정의된 메서드(Interface)만 볼 (사용할) 수 있으며, 내부의 속성과 구현은 볼 수 없게 디자인한다. 캡슐화는 객체를 외부의 부정적인 방법(또는 잘못된 방법)으로 사용하는 것을 방지하며, 사용자가 클래스의 내부에 대해 알지 못하는 상황에서도 외부에 공개된 메서드(Interface)를 통해 객체사용을 가능하게 해준다.
- 추상화 (Abstraction) - 모델(Object)의 자세한 성질을 무시하고(숨기고) 그들의 일반적인 성질을 나타낸다는 것으로서, 일반적으로 클래스는 클래스로 표현할 서브클래스(또는 객체)의 공통적인 성질과 행위를 일반화하여 디자인 되게 되며 그로부터 생성된 객체는 자신의 고유의 성질을 가지게 된다.
- 다형성 (Polymorphism) - 다형성이란 같은 메시지에 대해 클래스에 따라 다른 행위를 하게 되는 특징이다. 일반적으로 같은 이름을 가지는 메서드에 대해 인자(Argument)의 개수와 데이터형(Data Type)에 따라 수행되는 행위가 달라짐을 의미한다. 다형성을 통해서 사용자는 약속된 인터페이스를 따르는 서로 다른 객체를 같은 방식으로 사용 할 수 있게 된다.
객체지향 프로그래밍을 통해 얻을 수 있는 장점
소프트웨어 공학의 관점에서 볼 때 S/W의 질을 향상시키기 위해 Strong Cohesion 와 Weak Coupling을 지향해야 하는데, OOP의 경우 클래스에 하나의 문제 해결을 위한 데이터를 모아 놓은 데이터형을 사용함으로서 Cohesion을 강화시키고, 클래스간에 독립적으로 디자인함으로서 Coupling을 약하게 만들 수 있다.
대표적인 객체 지향 언어
구조적 프로그래밍(영어: structured programming)은 구조화 프로그래밍으로도 불리며 프로그래밍 패러다임의 일종인 절차적 프로그래밍의 하위 개념으로 볼 수 있다. GOTO문을 없애거나 GOTO문에 대한 의존성을 줄여주는 것으로 가장 유명하다.
역사적으로 구조적 프로그램을 작성하기 위하여 몇가지 다른 구조화 기법과 방법론이 개발되어왔다. 가장 일반적인 3가지는 다음과 같다.
- 잭슨의 구조적 프로그래밍 : 자료구조를 프로그램 구조에 맞추는 것에 중점을 두었다.
- 데이크스트라의 구조적 프로그래밍 : 프로그램의 논리 구조는 제한된 몇 가지 방법만을 이용하여 비슷한 서브 프로그램들로 구성된다. 프로그램에 있는 각각의 구조와 그 사이의 관계를 이해하면 프로그램 전체를 이해해야 하는 수고를 덜 수 있어, SoC에 유리하다.
- 데이크스트라의 관점에서 파생된 관점 : 하위 프로그램의 시작점은 한 군데이지만 끝점은 여러 개일 수 있다.
대부분의 사람들이 구조적 프로그래밍이라고 할 때 첫번째 것을 제외한 둘 중에 하나를 말하는 것이며, 이것이 여기서 말하고자 하는 것이다.
저수준 구조
저수준의 관점에서 구조적 프로그램은 간단하고, 계층적인 프로그램 제어 구조로 구성된다. 이 제어 구조들은 하나의 구문으로 간주되며, 동시에 더 간단한 구문들을 결합시키는 방법이다. 더 간단한 구문들은 또 다른 제어 구조일 수도 있고, 할당문이나 프로시저 호출과 같은 기본 구문일 수도 있다. 에츠허르 데이크스트라가 확인한 3가지 형태의 구조는 순차, 선택, 반복이다.
- 순차(concatenation)는 구문 순서에 따라서 순서대로 수행된다는 것이다.
- 선택(selection)은 프로그램의 상태에 따라서 여러 구문들 중에서 하나를 수행하는 것이다. 주로
if..then..else..endif,switch,case와 같은 키워드로 표현한다.
- 반복(repetition)은 프로그램이 특정 상태에 도달할 때까지 구문을 반복하여 수행하거나, 집합체의 각각의 원소들에 대해 어떤 구문을 반복 수행하는 것이다. 보통
while,repeat,for,do..until같은 키워드로 표현한다. 종종 반복 영역의 시작점을 하나로 하는 것이 추천되며, (원조 구조적 프로그래밍에서는 종료점도 하나로 해야한다고 추천하고,) 몇 가지 언어에서는 이것을 꼭 지켜야 하도록 하고 있다.
데이크스트라의 초창기 가드 명령어 언어같은 어떤 언어에서는 구조를 완전히 둘러싸는 if..fi와 같은 구문으로 구조의 단일성을 강조한다. C 같은 다른 언어들은 구조의 단일성을 강조하지 않는데, 잘못 이해하거나 잘못 수정할 수 있는 위험이 커지는 것은 아니다.
고수준 구조
코드 작성자는 큰 조각의 코드를 이해하기 쉬운 크기의 작은 하부 프로그램(함수, 프로시저, 메서드, 블록, 등)으로 나누어야 한다. 일반적으로 프로그램은 전역 변수는 거의 사용하지 않아야 하고 대신에 하부 프로그램은 지역 변수를 사용하거나, 값이나 참조에 의한 인자를 받아야 한다. 이런 기법은 전체 프로그램을 한번에 이해하지 않고, 분리된 작은 코드 조각을 쉽게 이해하는데 도움을 준다.
설계
구조적 프로그래밍은 항상 그런 것은 아니지만 하향식 설계와 관련이 있다. 하향식 설계를 할 때, 설계자는 큰 규모의 프로그램을 더 작은 공정으로 나누어 구현하고, 각각 검사한 다음에 전체 프로그램으로 합친다.
구조적 프로그래밍 언어
모든 절차적 프로그래밍 언어에서 구조적 프로그래밍을 할 수 있다. 1970년쯤부터 구조적 프로그래밍이 인기있는 기법이 되었기 때문에, 대부분의 새로 나온 절차적 프로그래밍 언어들이 구조적 프로그래밍을 고취시키기 위한 특징을 추가하였고 구조화되지 않은 프로그래밍을 쉽게 하기 위한 특징들은 남겨둔 것들도 있었다. 잘 알려진 구조적 프로그래밍 언어에는 파스칼(Pascal)과 에이다(Ada)가 있다.
역사
이론적 기반
구조적 프로그램 정리는 구조적 프로그래밍의 이론적 기반이 되었다. 정리에 따르면, 프로그램을 결합하는 3가지 방법인 순차, 분기, 반복만으로 충분히 계산가능 함수를 표현할 수 있다. 이런 점은 구조적 프로그래밍 운동에서 나온 것은 아니지만, 이런 구조들은 중앙 처리 장치의 명령 주기뿐만 아니라 튜링 기계의 동작을 설명하는데 충분하다. 따라서 이런 의미에서 프로세서는 항상 "구조적 프로그램"을 실행한다. 구조적 프로그램이 아닌 기억 장치의 다른 부분에서 읽는 명령을 수행해도 그러하다. 1966년 뵘(Böhm)과 야코피니(Jacopini)의 글을 데이크스트라가 인용하였기 때문에 구조적 프로그래밍의 최초의 이론적 기반이라고 하기도 한다. 구조적 프로그램 정리에 구조적 프로그램을 어떻게 작성하고 분석하는지에 대해서는 나와있지 않다. 이 내용들은 1960년대 후반과 1970년대 초반에 개발되었는데 주로 데이크스트라, 플로이드, 호, 그리즈가 많은 공헌을 했다.
논쟁
구조적 프로그래밍의 선구적 실천가(얼리어답터)인 플로저는 구조적 프로그램 정리에 대한 그의 반응을 이렇게 설명했다.:
- 우리는 이 흥미로운 소식을 어셈블리 프로그래머들에게 알려주면서 마음을 돌려보려 하였지만, 이 덜된 어셈블리 프로그래머들은 비비꼬인 로직의 비트들을 만들어내면서 계속해서 '이런건 구조화가 안될껄?'이라고 말하고 있다. 뵘과 야코피니의 증명을 보여주어도, 우리가 구조적 코드를 성공적으로 계속해서 만들어서 보여주어도, 그들은 구조화된 프로그래밍 적응 준비를 하루도 앞당기지 않았다.
1967년, CACM에 데이크스트라의 "GOTO문의 해로움"(Go to statement considered harmful)라는 서한이 실렸다. 이 글에서 그는 뵘과 야코피니의 증명을 인용하면서, 고급언어에서 GOTO 명령을 제거하는 것이 코드의 질을 높일 수 있다고 했다. 이 글은 주로 구조적 프로그래밍 논쟁의 시작점으로 인용된다.
비록 플로저가 언급했듯이 다수의 프로그래머들이 이 정리에 익숙하지 않다고 해도, 이런 프로그래머들을 양성할 가치가 충분히 있을 정도로 지난 몇년간 소프트웨어 개발은 간결성, 품질, 개발 시간의 측면에서 향상되었다. 데이크스트라는 구조의 종류를 제한하는 것이 프로그래머가 생각하는데 집중하는 것을 돕고, 관리 가능한 절차로 분석하여 프로그램의 유효성을 더 간단히 보장할 수 있다고 했다. 그는 1969년구조적 프로그래밍에 대한 글에서 이렇게 썼다.:
- 우리는 정확한 프로그램을 작성하는 프로그래머의 직분을 수행해야 할 뿐만 아니라, 그것의 정확성을 납득가능한 방법으로 증명하는 역할도 수행해야 한다. 위에서 한 언급은 프로그래머가 작성하는 모든 것은 유효하게 구조화되어야 한다는 것에 뜻 깊은 영향을 끼친다.
- …프로그램의 정확성 뿐만 아니라 프로그램의 적응성과 관리성까지 내가 신경쓰고 있다는 것이 더욱 명백해진다… 1
카누스는 프로그램이 입증가능성을 염두에 두고 작성되어야 한다는 원리는 받아들였으나 GOTO문을 없애는 것은 받아들이지 않았고 지금도 받아들이지 않는다. 1974년, 그의 논문, "GOTO문이 포함된 구조적 프로그래밍"에서 직접적인 분기를 하여 입증가능성을 희생시키지 않으면서도 더 간결하고 효율적인 코드를 작성할 수 있는 몇 가지 예제를 보였다. 카누스는 좀 더 완화된 구조 제한을 제안했다. 그것은 프로그램의 순서도를 그린다면 왼쪽에는 아래쪽으로 가는 가지(branches)만, 오른쪽에는 위쪽으로 가는 가지만 그려야하며 그 가지들이 서로 교차하지 않아야 한다는 것이다. 컴파일러와 그래프이론에 정통해 있는 많은 사람들이 축소 가능한 흐름도(reducible flow graphs)만을 허용해야한다고 이 생각을 옹호했다.
구조적 프로그램 이론가들은 1970년대 IBM의 연구원 밀즈가 구조적 프로그래밍 이론에 대한 그의 해석을 뉴욕타임즈의 인덱싱 시스템 개발자들에게 적용한 일이 있은 후에 대부분이 합의를 봤다. 이 계획은 공학적으로 크게 성공하였다. 데이크스트라가 밀즈의 해석이 출판된 것들과 다르다며 비판하였지만, 다른 회사의 관리자들까지도 구조적 프로그래밍의 채택을 지원하기 위하여 밀즈의 해석을 인용했다.
1987년이 되어서도 여전히 전산학 간행물에서 구조적 프로그래밍에 대해 의문점이 제기되었다. 프랭크 루빈은 그 해에 "GOTO문의 해로움의 해로움"('Go to statement considered harmful' considered harmful)이라는 글을 썼다. 루빈은 물론이거니와 양보하라고 한 다른 필자들까지도 날카롭게 비판한 데이크스트라의 응답과 함께 수많은 반대 의견이 뒤따랐다.
결과
20세기의 막바지에 이르자, 대부분의 컴퓨터 과학자들은 구조적 프로그래밍의 개념을 배우고 적용하는 것은 유용하다고 확신했다. 포트란, 코볼, 베이직과 같이 프로그래밍 구조가 원래 취약한 고급 프로그래밍 언어들은 이제 그런 구조를 가지고 있다. GOTO문 제멋대로 사용하는 것을 받아들이는 프로그래밍 교육자들은 찾기가 힘들어졌다.
프로그래머가 경험을 쌓을수록 엄격한 의미의 구조적 프로그래밍을 침해하는 어떤 부분이 있는지를 이해하기가 쉽다는 것을 알았고, 널리 퍼진 몇몇 프로그래밍 언어들은 직접적인 분기문을 제한하고 있으며 예외처리를 이런 상황에서 사용할 수 있게 하고 있다. 주요한 산업용 언어들은 자바와 같은 언어들을 제외하고는 프로시저 내에서의 직접 분기를 위하여 GOTO문을 여전히 유지하고 있다. 데이크스트라가 구조적 프로그래밍을 표준 교육과정에 편입시키는데는 성공했지만 엄격한 조건을 고수하는데는 성공하지 못하였다.
엄격한 조건을 만족시키지 못하는 상황
예외 처리
대부분의 경우에 하위프로그램에 여러 개의 시작점이 있는 것은 아니지만, 여러 개의 종료점을 가지는 경우는 있다. 주로 하위프로그램이 더이상 할 일이 없거나 더이상 계속하지 못하는 상황이 된 경우이다.
다음은 파일에서 자료를 읽어서 처리하는 간단한 프로시저의 전형적인 예이다:
open file;while (reading not finished) { read some data; if (error) { stop the subprogram and inform rest of the program about the error; }}process read data;finish the subprogram;
5번째 줄에서 멈추고 알리는 것은 예외를 발생시키거나, 제 2의 리턴을 하거나, 레이블한 루프로 빠져나가거나, 심지어는 goto를 써도 할 수 있다. 프로시저가 2개의 종료점을 갖기 때문에 데이크스트라의 구조적 프로그래밍의 규칙에 어긋난다. 종료점을 하나로 하는 규칙을 지키려고 하면 복잡해진다. 에러 상황이 더 있다면, 청소 규칙이 서로 달라서, 오히려 goto문을 사용한 비구조적인 것보다 훨씬 읽거나 이해하기 어렵게 될 것이다. 반면에 그런 규칙을 따르지 않는 구조적 프로그래밍은 코드를 아주 깔끔하고 읽기 쉽게 할 것이다.
대부분의 언어는 구조적 프로그래밍에서의 여러 종료점을 지원한다. C (프로그래밍 언어)는 continue, break, return과 같이 여러가지 경로로 구조에서 빠져나가는 것을 허용하고, 더 새로운 언어들은 레이블한 루프(전자와 비슷하지만 제일 안쪽 루프 뿐만 아니라 그 이상도 빠져나갈 수 있게 해 준다)와 예외처리를 지원한다.
상태 기계
특히 구문분석기와 통신 규약 같은 프로그램들은 상태들이 있어서 기본 구조들로 줄이기가 쉽지 않다. 각각의 상태 변화를 분리하여 하위프로그램을 만들고 변수를 이용하여 활동중인 상태를 나타내면 가능하긴 하다. 하지만, 카누스를 포함한 일부 프로그래머들은 상태의 변화를 새로운 상태로 직접 분기하는 것을 더 좋아한다.
현대적 가치
구조적 프로그래밍에 대한 논의는 많은 새로운 언어를 낳았으며, 기존의 언어에 구조적인 면이 추가되는 등 언어의 발전에 도움이 되었다. 그리고 이후에 나온 프로그래밍 패러다임들에도 영향을 끼쳤다.
구조적 프로그래밍은 프로그래머의 습관을 바꾸었다. 프로그램의 정확성을 증명하는 문제를 떠나서 데이크스트라가 그의 논문에서 말한 대로 시간에 따라 변하는 동적인 과정을 시각화하는 것은 인간에게 매우 어려운 일이다. 꼭 GOTO문만의 문제가 아니라 구조화된 흐름 제어문을 사용한다고 할 지라도 너무 복잡하게 중첩되어 있거나 스코프의 길이가 너무 긴 코드를 작성한다거나 너무 긴 길이의 하위프로그램을 작성하는 일을 가급적 피하게 경향이 생겼다. 그리고 이런 습관은 다른 사람이 작성한 프로그래밍 코드를 쉽게 이해하는데 도움을 준다.
데이크스트라가 쓴 "GOTO문의 해로움"이라는 논문은 이후 "...의 해로움"이라는 유행을 낳기도 하였다. 이는 전산학에서 과도하게 사용되는 어떤 것에 대한 것을 비판하는 데 많이 사용되었다.
헤엑헤엑.... 끝입니다.
수고하세요 ㅇㅂㅇ
