여러분은 애플리케이션의 통합화에대해 어떻게 생각하시나요

기능형 컴퓨터라는 말을 들어봤습니다.
물론 내용은 읽어보지않았습니다.

제가생각했을땐 필요에따라 문서작업할땐 문서작업에 적합한 스팩을 가진 컴퓨터에서 그래픽작업할땐 그래픽 작업에 적합한 스팩을 가진 컴퓨터에서 작업하는것도 나쁘진않다고 생각합니다.

하나의 컴에서 그것들을 모두 돌리기엔 뭐 위험부담이 크잖아요..
(갑자기 다운되면 전부 작업한것이 수포로돌아가니까.)

프레임웤이라는것이 무겁다 생각이드는건 저도 마찬가지입니다.
그러나 작은것 여러개보다 큰것하나라면 차라리 저는 후자쪽이 더나은 구조가 아닐까싶습니다.
적어도 그것이 GUI스럽다고 하는편이 저의 변명이라고 할까요 ^^:
하지만 나름대로 그러는 편이 GUI에선 훨씬 좋지않을까합니다.

물론 꼭 좋은건아닙니다. 그러나 한가지 프로그램이 프레임워크라는 구조로 지원해준다면
진짜 필요하면 내가 그런프레임워크에 맞는 기능들(플러그인)들을 선택해서 받을수있으니
그거야말로 진짜 작은것들의 모임이 아닐까생각합니다.

큰것하나가 작은것들을 감싸고있으니.. 그룹을 이룬다는 형태로요..

만약 다른 그룹의 프레임웍이 그것을 필요로한다면.. 그쪽에도 공유해줄수있는 일이기도 하구요.
(물론 프레임웤마다 그규칙이 다 다르겠지만..)

여튼 이방법이 오픈소스에서 클론들(저는 극악적인 표현으로 사생아라고 했지만..)이
난무하는것을 최소화 하지않을까합니다.

좀더 한곳으로 집중시켜주는 그런계기가 되리라 생각합니다.

이게 반유닉스계열이라고 생각은 하지않습니다. 저는 이것이 vi와 다르지않는구조라고 생각했거든요.

OS도 APP(또는 라이브러리)를 위한 프레임웤이라면..
APP도 Plug-in(모듈)을 위한 프레임웍이 될수있겠군요..
OS -> APP(또는 라이브러리) -> Plug-in(모듈)
이렇게 보는 편도 좋겠죠?

제가 오래전 와우에다 이런글을 썼던게 지금 실감이나기시작했습니다.
오래전 프로그래머는 모듈을 만들고 파워유저는 그것을 조립하며 초보는 그것을 테스트한다.
그렇기때문에 개발이라함은 모든 레벨의 사용자가 다할수있는것이다. 라고..

그런데 새삼 그것이 지금생각하는 제생각으로는 틀린거같지않아서 다시 글을씁니다.
그때.. 잔디인형님께서 딴지를 많이 달아주셨는데..
그덕에 제가 그것을 스스로 비판을 많이해보게되었답니다.

제가 생각하는 개념은 지금에서 이렇게 되어졌습니다.
개발자(한명또는 여러명이)는 하나의 프레임워크를 만들고 파워유저들은 그것을 조립해 자기가원하는기호에맞게
사용한다.
다시말해 개발자는 모듈및 프레임워크를 개발하는쪽이고 파워유저는 그것들을 기호대로 조립및
테스트등을 할수있는 구조를 가지고있다 라는겁니다.

물론 이것은 오직 오픈소스에서만 가능한 구조입니다.
MS쪽이나 기타의 프리속성을 가지지않는 라이센스에서도 가능하긴하겠지만.
그활동이 극히 제한적입니다.

프레임워크에대해 저는 긍정적입니다.
프레임워크가아닌것에대해 저는 그런것을 스텐다드 얼론방식이라 이름짓고싶습니다.
프레임워크라는것의 일례로 XINETd같은게 있을수있으니까요.
마치 하나의 넓적한 레고블럭에 여러개의 작은 블럭들로 집을 짓거나 할수있으니까요.
프레임워크라는것은 그런 넓고 큰 레고블럭과 같다고 생각합니다.

물론 (제가말하는)스텐드얼론방식도 나쁜건아니라고 생각합니다.
왜냐면 이것은 규모나 사용에있어서 상당히 간소화할수있으니까요.
하지만 버전업을 함에따라 그한계성을 많이들어냅니다.
그때문에 비슷한 새로운 것들이 자꾸 파생되는거죠..

그런이유들때문에 안시씨가 아닌 프레임워크를 포함하는 닷넷이나 자바가 등장하는지 그것도 알게될껍니다.
분명히 프레임워크형태는 무식하게 큽니다. 그래서 그다지 좋은게 없다고 생각하실지모릅니다.
그러나 프레임워크는 무식하게 큰만큼 많은것을 지원해주게되어잇습니다.

일일히 사람손갈거 한두번이면 마무리지어지겠죠.. 그런게 프레임워크의 특징이 아닐까 생각합니다.
비슷한것을 여기서 만들고 저기서만들고 그렇기때문에 서로 달라서 함께할수없다라는것은
정말 소모적 이라 생각합니다.

하나의 프레임워크가 공개가된다면.. 그것을 기반으로하는 모든프로그램들이 성장해갈수있습니다.
스타크래프트의 캐리어가 공격유닛중에서 가장 좋은점도.. 적과 대치했을때 공방을 대부분 인터셉터가
해줍니다. 물론 맘먹고 1.4해버리면 죽겠지만.. 제가 유일하게 좋아하는 유닛이 캐리어이거든요..
그냥 왠지 마음에 듭니다.

표준화라는것은 프레임워크를 만들고 그것을 통째로 공개해버리면 그것을 기반으로 모든사람들이 달라들므로
자연적으로 표준화가 생긴다고 생각합니다. 꽃밭에 꿀을찾으려오는자들이 오는건 당연하죠..
그 꽃밭이 크면 클수록 찾아드는자들이 더많아질것입니다. 물론 그꽃의 번식은 엄청날테구요..

표준화가 필요할때입니다. 표준화를 말만외치고 그냥 일부러 없는거에 만들필요는 없다고 봅니다.
단지 잘나가는것을 모델로 지속적으로 연구하면서 개선해간다면 그것이 표준이고 그것이 대중성을 이끄는
방법이 아닐까생각합니다.

저는 리눅스와 유닉스가 아직도 햇갈립니다. 왜 같으면서 같지않다고 하는건지 그것을 모르겠고.
응용프로그램들역시 클론일지라도 결국뿌리가 같으면서도 절때로 다르다고 하는지 이유를 모르겠습니다.
그럼 어디가 그들을 하나로 이어주는건가요, 그것을 뭐라고 불러야하며, 우리가 그것을 쉽게 찾을수있을련지요.
또 쉽게 접할수있는지요

대중성이란것을 제가 오래전부터 개짓듯 지져왔습니다.
프로그램의 표준 설령 백신일지라도.. 응용프로그램보다는 모듈 보드
(이거도 제가 나름대로 이름지은건데 메인보드의 확장슬롯에 그래픽카드등을 꼿을수있는데 그그래픽카드에도
각부품별로 또 업그레이드가 가능하게하는..방법 중에서 그래픽카드의 역할자. 일종의 메인보드와
각부품의 인터페이스역할을 해주는 보드..)
만 잘만들어놓으면 그안에서 또 죽을 쑤던 떡을 만들던 가능하죠..

그림은 제가 좀 안되는실력이지만 이것에대해 이해를 돕고자.. 써봤습니다.

그림이 허접합니다. 파워포인트로 그려넣었습니다.
중요한것은 그림의 각블럭들은 그크기들이 일정하지않지만. 하나의 모듈안의 크기들은 동일한 사이즈 규격을 가진다는것을 강조하고싶군요.. 규격은 같되 색깔만틀리다. 라는거만..

아참 글의 요점은 이겁니다. 그냥 프레임워크형태로 개발하면 좋은점이 많으니 프레임워크쪽으로 개발을 지향하자라는쪽이 더 정확한표현이 아닐까라는생각을 해봅니다.

아참.. 그리고 그렇게 하다보면.. 사생아들이 더이상 생겨나지않겠죠?
사생아가 없어지려면 함께살아가는방법을 알려주면 좋겠다는 생각이 듭니다.
그때는 필요에서 사생아가 만들어졌지만. 표준화를 통해 그럴필요가 없음을
느낄수있을테니까요.

제가 나름대로 글과 그림을 정리해가는것은
그곳까지가는데 가장 빠른 설명을 위해서라고 보시면됩니다.
물론 새로운 개념이라고는 생각하지않습니다.

그러나 선생들중 정말 잘가르치는사람은 뭔가 연관시켜서 설명하지않던가요?
다시말해 서울에서 제주도까지가는방법은 많은데
돌아가던지 바로가던지 도착하면된다라는거겠죠?
그런데 절차적인 방법은 꼭 어디어디를 거쳐야지만 제주도에 간다라고 가르키죠
대부분이 그렇잖아요. 그런데 바로가는방법도 얼마든지있거든요..
설령제주도라고 하지않더라고 울나라에서 가장 사람이 많이사는 섬이라고해도알죠.
또는 울나라에서 가장큰섬이라고해도되고..

뭐 교육학에대해 관심은 없지만요.. 하지만 제가 이렇게 하는것은
좀민망하지만 필요하다면 제말에대해 정리를 해주는쪽이좋겠다는 생각이듭니다.
뭐 제가 좀 무식할정도로 아는척을 해대는건 인정하지만 동기나 과정에서
그것이 잘못되었다고 생각은 안듭니다.

물론 결과적으로 잘못된 결과를 주는건 너무나도 당연하겠지만요
그럴땐 그냥 올바른답을 써주심될듯.. 또는 참고할만한 사이트라든지..
그게 제가봤을땐 가장 정답이될꺼같다는 생각이드네용..
단지 전망없는 딴지라면.. 그다지 기분좋을글은 아닐까생각도듭니다.

그리고 하나를 알기위해 수백가지를 이해해야하는것은 소질이 없습니다.
모든지식은 탑쌓기를 하지않아도 최고점에 도달할수있다고 생각하거든요.

이클립스나 vi같은건 애플리케이션단위의 프레임워크같습니다.
뭐 저는 쉘이라 할지라도 그게 프레임워크가 없다고 생각하지않습니다.
CUI쉘이나 GUI쉘이나 그기반에서 돌려는 프로그램들은 죄다 그기반의 파일들을 필요로하니까요
CUI에서 파이프나 리다이렉션을 지원하는것은 쉘이 설계가 잘되진거겠죠..(저역시 그렇게 생각합니다.)

흔히들 라이브러리라고 불리우는거를 말하는데
저는 라이브러리나 프레임워크나 크게 다를게없다고생각합니다.
어차피 이클립스같은것은 그안에서 부수적인 프로그램을 구동시킬수있습니다.
(이클립스안에서 테트리스같은거나 또는 C언어 환경 또는 자바 환경을 만들수있는거처럼)

그에반해 쉘단위 프레임워크는 대부분 라이브러리라고 불리우는것들이 아닐까합니다.
그리고 그안의 모듈이라는것은 대부분 우리가 아는 실행 프로그램들을 말하는거겠죠?

이쯤해서 또다시 레이어의 구분을 지으라고한다면
하드웨어에서 커널까지는 독립적인 구조를 가지고 그위의 쉘은 라이브러리(프레임워크)와 같은
레이어에있다고 생각합니다.
그리고 그위엔 응용프로그램레이어가있고 그것역시 프레임워크를 속성으로 할수있고..
아니면 상위의 라이브러리를 의존할수있게 할수있습니다.
(다시말해 순수하게 자신이 만든 파일들로만 구동이가능하거나 또는 기존의 공용되는 파일(*.dll)을
의존해야하거나..

라이브러리나 jre(자바런타임엔진, 맞나?) 닷넷프레임워크 등을 프레임워크라 불러도
크게 다를게 없다고 생각합니다. 그래서 쉘단위 레이어에 속한다고생각합니다.
물론 응용프로그램은 이런라이브러리를 선택적으로 사용할수있는 권한이있습니다.
반드시 프로그램이라고해서 이런 프레임워크를 의존해야할필요는 없겠죠.
프레임워크를 꼭 의존하지않아도 플밍실행은 커널에의존되어 실행이가능하겠죠.

전체적인 면에서 제가 일방적인 저의 생각을 말씀드렸습니다.
그런데 실질적으로 프레임워크니 라이브러리니 하는것은 정확하게 그의미를 구분짓기가 모호합니다.
왜냐면 지금까지 우리가 봐온것들은 거의 장르에대한 구분이 없었기때문입니다.
(물론 예전에 나온것들은 그개념이 확실했지만)
그것은 기능의 발전으로인해 모호성을 많이 준것도 사실입니다.
(이클립스는 원래 개발도구를 목적으로 썼는데 그안에서 게임이나 문서작성을 한다면 그장르가 모호해짐
처음 목적을 그대로 두고 개발도구라고 장르를 결정했는데 정작 개발도구쪽으로는 개발되지않고
계속 게임쪽으로만 개발되버리면.. 이클립스는 게임이라고 하기도 그렇기때문..)

프레임워크나 라이브러리는 같은의미가 아닐까요?
단지 좀 그크기를 따진다면 프레임워크가 좀더 큰개념을 지닌거같다는생각이듭니다.
그리고 프레임워크란 라이브러리 세트를 말하는것이고 그라이브러리세트를 이용해 만들어진것들이
프레임워크에 의존하고있는 모듈이되겠죠.
그리고 이런프레임워크는 응용프로그램용 프레임워크나 쉘의 프레임워크등이 있겠죠.
또는 모듈의 프레임워크라든지..

그렇게 따졌을때 모듈과 응용프로그램의 개념이라는것도 어쩌면 좀모호하겠군요
쉘의 입장에서 따졌을때 그이하에서 도는 대부분의 플그램들은 모듈이 될텐데요..
왜냐면.. A라는 쉘에서는 돌아가는데 B라는 쉘에서는 안돌아가면 그것은 쉘에 의존하고있다는뜻이니까요.
즉 그런것은 응용프로그램에서 모듈(플러그인같은.)과 다를게 없으니까요.

이게 좀더 정리된 정보가있었음 좋겠습니다. 왜 라이브러리라고 하고 프레임워크라고하고..
제글 보신분들중 몇분은 제글이 이해를 못할수도있습니다.
(물론 저역시 제가 아닌 남이 쓴글이라면 쉽게 이해하지못할지 모릅니다. 뭔내용인지 정리가안되는
우후죽순같은 글이라.. @_@)

그러나 좀이해하신분들중에 제글의 의도를 아시는분들이라면
죄송하지만 그것에대한 정확한 개념을 아래다 올려주셨음 좋겠습니다. 다른뜻이 있어서그런건아니고.
제가 틀렸다면 그것의 정정할필요성을 느끼기때문입니다.^^

(때로는 물리적인 공부보다는 그런 이론적인 부분이 필요할지모릅니다.
물리적인 공부는 아무리해봐야 머리에 개념이 서지않는다면 첨부터 다시시작해야할지도 모르르거든요.
그렇게 생각하기때문에 지속적으로 개념적인 글과 개념적인 질문을 하는건지도.. ^^;)

서울에서 부산까지 비행기로 또는 기차, 배로 차로 여러가지 수단을 쓸수있습니다.
결국 어떻게가던 갈수있죠. 반드시 대전을 거쳐야 가는것도아니고 그렇다고 강원도를 거쳐갈필요는 없습니다.
그냥 어떻게 가던간에 갈수있죠.
마찬가지로 전산에서 선수학습이라는게 반드시 필요하지않아도 지식을 충분히 전달할수있을꺼라생각합니다.
전혀 새로운개념들도 아니고 그런개념들이라는게 죄다 거기서 거기일테니까요..

redbaron
님의 말씀이 일리가 있군요..
첨엔 그런 개념자체가 없었기때문에 지금와서 그렇게 비스무리한 단어들이
나오는건 무리도 아니겠습니다.
그렇다면 앞으로도 얼마나더 새로운단어들이 우리의 머리를 압박할수도..

그리고 의도와 지식의 차이역시 이해합니다.
그러나 그게 차이가있다면 차이를 둬서라도 우선은 의도를 먼저 알려주는쪽이 좋지않을까라는
생각을 해봅니다. 천천히 그것에대한 "지식"을 알아가더라도말입니다.

그리고 "지식"과 "의도"의 차이를 둔다면 분명히 의도는 쉽고 빨라야하며
누구나 알야야한다는 의무도 있지않을까생각합니다.

컴퓨터에서 네트워크레이어의 하위단계를 알지않고도 상위단계만으로 충분히 네트워크의
구조를 설명할수있습니다. 그런게 좀부족하지않을까생각해봅니다.

네트웍플밍을 하려는데 꼭 네트웍의 하위레이어를 공부할필요도없을꺼며.
그렇다고 하드웨어구조나 통신의 회선 연결등의 구체적인 수준까지 알필요는 더더욱 없겠지요
단지 사용자는 필요한수준의 정보만 긁어다 자기것으로 만들면되는거같아요.

여튼 이런부분은 같은 의견입니다.

그러나 중요한것은 처음부터 깊게 파는 지식은 오래가지못하지않나싶습니다.
목욕할때도 그 단계가있어 처음엔 그냥 가볍게 발만 적시고 점차 온몸을 적시는게 당연하죠.
바로 온몸을 담구면 몸에 무리가 생길수있습니다.
어떤식으로가던 가면되는것은 아주 기초적인 방법이고 위에 많은분들이 설명한 그것은
그것에대한 구체적인 방법론들을 말하는거겠죠.

그래도 프레임워크와 라이브러리등의 개념은 같은 이유에서 출발한건 맞겠죠?
물론 기능도 비슷하고 지금도 그러니까. 아무리 C언어같은걸로 Hello World!!라는 플그램을
짜더라도 그것은 프레임워크(또는 라이브러리)를 의존하고있기때문에 컴파일되고 결과물이
보이는거겠죠?

만약 프레임워크를 기반으로 하지않는다면 유닉스에서 컴파일된 파일을 윈도우에서 돌려도
돌아가야정상이겠죠?
물론 소스야 약간의 레이어(포팅레이어같은..)를 꼿아두면 거의 80%이상은 완벽해질수있겠지만
그이상은 무리겠죠?

뭐 제글에대한 결론은 프레임워크라고 별도로 이름불리워진것은 다른뜻으로 보면
일종의 라이브러리개념밖에 되지않을듯하다는겁니다.
다시말해 이클립스가 느려터지고 그래서 효율성이 떨어지는거나 CUI에서 명령스크립스
쓰는거나 결과론적으로 봤을때는 효율은 거기서 거기다라는겁니다.

어차피 프레임워크라는건 CUI에도 GUI에도 자바 프로그램에도 닷넷플그램에도..
어디든지간에 필요로한거니까요..
결론은 프레임워크 없이 플그램실행은 절때로 불가능하다는겁니다.