미카 프로젝트

Mobile 쪽에 몸담고 있으면서 , file system에서 부터 UI 까지 모든 과정에 참여하여 아이디어를 내고 개발하고 결과를 보고 아키텍쳐를 수정하여 다시 설계하고 하는 작업들이 즐거웠던 시절이 있었다.

하지만, 이런 점진적인 발전과 시행착오들은 점점 부담과 위기로 다가오기 시작한 것 같다.

Hand Phone S/W의 시장에 존재하던 Normal phone 과 smart phone의 경계가 무너지면서 기존에 Normal Phone S/W들이 Open OS와의 경쟁을 시작하게 되었기 때문이다.

최근 내가 지금 관심을 가지고 지켜보고 있는 기존 Embeded S/W의 경쟁력에 관한 부분이다.
우선 첫번째가 "Embeded S/W가 Open OS 들과 경쟁하기 위해 어느정도 개선되어야 하는가" 하는 부분이고,
두번째는 "Embeded S/W가 Open OS들만큼의 기능을 갖추는 것이 과연 메리트가 있는가" 하는 부분이다.
세번째는 "시장의 Needs는 이미 Open OS의 기능을 요구 하기 때문에 최대한 빠르게 Open OS 로 전환하는 것이 옳은가" 하는 것이다.

Open OS( Window Mobile이나 Linux , Symbian 등)의 포팅이나 개발 업무 보다는 기존에 꾸준히 Embeded S/W만 해왔기 때문에 Embeded S/W 쪽으로 훨씬 애착을 가지고 있는 편이다. 그럼에도 불구하고 Embeded S/W 냐 Open OS냐를 두고 고민하는 것은 10년 20년이 지나면 Open OS로 달려가고 있을것으로 예상 하기 때문이다.

여기에도 한가지 변수가 있는데 기존의 Window mobile, embeded linux, OSX, Symbian 등과 어깨를 나란히 할 수 있는 Open OS를 만들어 내고 배포할 수 있는가 하는 것이다.

개인적인 입장에서는 내가 지금 하고 있는 프로젝트가 이런 Open OS 개발의 가능성을 열고, 기업입장에서도 투자가치가 충분한 부분이라 인식되었으면 하는 바램이다.!!

글을 읽는 도중 다음과 같은 문구를 보게 되었습니다.
Framework 없이 어플리케이션을 만드는 것은 프로그래머의 역량과 컨디션에 따라 어플리케이션의 구조가 만들어지게 된다. 라고 적혀있었는데 생각해보면 맞는 예기인것 같습니다.

Framework이라는 것이 사실상 생산성을 높이고 제공하고자 하는 기능을 구조화 하여, 개발자들에게 기능 사용구현에 대한 Guide 역할하고, 기능 동작을 보장 해주는 것이라 볼수 있습니다.

때문에 Framework없이 S/W를 개발한다면 사실상 개발자의 역량에 맡길수 밖에 없게 됩니다.

이전에 이와 같은 기능을 구현해 봤는가, 아닌가에 따라 S/W의 질이 달라지게 되겠죠.

Framework이란 무엇인가? 

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

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

라이브러리와 프레임워크의 차이!
라이브러리는 개별적인 기능들을 집단형태로 묶음을 의미합니다.
때문에 라이브러리를 이용해 문제를 해결하고자 할때는 메소드의 기능을 정확히 이해하고 사용해야 합니다..

프레임워크는 원하는 기능을 제공하는 모듈의 인스턴스와 이에 수반되는 여러가지 장치 들의 상호작용까지의 묶어서 정의 하게 됩니다. 

때문에 프레임워크에서 제공되는 기능을 사용하게 되면 이와 수반된 이미 검증된 작업의 플로우까지 함께 사용하게 되는 것입니다..

이렇게 함으로 해서 어플리케이션의 코드를 줄일 수 있고, 안정성을 높이며 개발 속도를  빠르게 할 수 있습니다.

좋은 프레임워크
좋은 프레임워크를 사용하면 소프트웨어 개발 비용이 줄어들지만, 아이러니하게 좋은 프레임워크를 개발하기 위한 비용이 많이 들게 됩니다.

좋은 framework을 만들기 위해 설계에 들어가는 시간, 퍼포먼스 향상을 위해 투자하는 시간, 그리고 안정성 확보를 위해 테스트에 들어가는 시간 이 모든 것들이 비용이 되기 때문에 많이 들 수 밖에 없습니다.

Framework 설계에 들어가는 원칙들.

의존관계 역전 원칙( The Dependency Inversion principle)
인터페이스 분리 원칙(The Interface Segregation Principle)
리스코프 치환 원칙(The Liskov Substraction Principle)
단일 책임 원칙(The Single Responsiblity Principle)
개방 폐쇄 원칙(The Open-closed Principle)

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

Let's enjoy the bloging!!!!

Wow... :)