철학 사상을 공부한다는 것은 사상 뿐 아니라 그 사상이 나오게 된 배경을 공부하는 것이며, 그 배경에는 개인의 혹은 역사적인 사건이나 그 이전 세대의 사상이 들어 있어서 공부를 하다보면 끊임없이 과거로 과거로 올라가기 마련이다. 역사라는 것을 공부하는 이유가 되이기도 할텐데, 과학기술에도 그런 역사가 있고, 그 역사를 아는 것이 내가 지금 알고 있는 기술에 대한 감각을 더 풍부하게 만든다. 


컴퓨터 분야는 1년이 멀다하고 새로운 기술들이 나온다. 한 5년동안 공부하기를 게을리 했다면, 다시 따라오는데 엄청난 에너지가 소모되는 분야이다. 이걸 따라 잡는 가장 좋은 방법은 멈추었던 지식 이후로 바뀌게 된 IT환경의 변화를 관찰하는 것이다. 변화의 가장 하위 접근은 어떤 H/W가 많이 쓰이게 되었는지를 보면되는데, H/W는 성능을 높이기 위한 기술의 발전이므로, 각 시대별 성능에 대한 표를 만들어가는 것으로 출발하면 될 것이다. 이런 H/W를 충분히 활용하기 위해 언어와 프레임웍이 발전해 왔고, 한 언어가 뜬다고 하여 저런 생각없이 배워야한다면 무지막지한 폭력에 노출되는 것이나 다름이 없다. 


좀 더 생각을 발전시키면, 역사라는 것은 과거를 정리한 것이다. 정리된 역사란 당시의 상황에서 수 많은 시도가 일어나고 그 중 하나가 득세하게 된 인과 관계를 설명하는 방식인데, '현재'는 아직 정리되지 않은 상황이므로 개발자는 성능을 극복하기 위한 그 수 많은 시도 속에 노출되어 있고, 각 시도들을 따라가기란 어려운 것이다. 그런 시도들을 따라간다는 것. 그것은 정리된 과거와 어떤 연결고리가 있는지를 파악하는 것부터 시작하는 것이 빠른 학습방법이며, 어떤 문제를 해결하기 위해 나온 것인지를 아는 것이 가장 경제적인 학습방법이다.


큰 흐름을 파악하는 것은 교양이며, 큰 흐름을 이루고 있는 개별 흐름에 대한 이야기를 이해해서 사용하거나 다른 이들에게 전달 할 수  있는 것이 이른바 전문가적 소양이다.


재미로, 쇼펜하우어의 충족 근거율에 따라 대비시켜보면, 생성, 인식, 존재, 행위 관한 네 가지 근거율에 대하여 다음과 같지 않을까? 생성의 충족 근거율인 인과율에 대해서는 전술한 대로 성능 개선을 위한 하드웨어의 발전에 대하여 어떤 발전에 근거하여 이 소프트웨어적 발전이 이루어졌는지를 파악하는 것이고, 인식의 충족 근거율인 논리법칙에 대해서는 개별 소프트웨어의 발전에 대한 작동원리(스펙 혹은 알고리즘)를 이해하는 것이며, 존재의 충족 근거율인 '시간과 공간'에 대한 순수직관에 대하여는 다루는 기술이 구현되어 나오는 현상에 대한 이해, 혹은 구현 오류에 대한 디버깅을 통해 구현된 기술의 이면에 들어 있는 추상적인 흐름을 파악하는 방법인 것이고 (적절하지 않은 예인것 같긴하다), 마지막으로 행위의 충족근거율인 동기에 대해서는 각 기술이 어떤 배경에 의해 확산되며, 각 개발자들은 어떤 선호도를 가지고 해당 기술을 업무에 적용시키는지에 대한 것이라 할 수 있겠다.


무리한 시도로 대비시켜봤다. 딴지 걸어 딱히 적용되지 않을 수 있는 것은 기술이란, 고도의 지적 발명품에 대해 다루고 있는 것이며, 철학이란 인간의 지적행위와 상관없이도 존재하는 대상(인간을 포함)을 다루는 것에 그 이유가 있겠다.

http://en.wikipedia.org/wiki/Universality_(philosophy)


이 링크는 보편자로 해석되는 철학용어인데, (흔히 보편자 논쟁에서 사용되는 용어) 보편자를 철학적인 주제에서 사용되는 예들을 보다보니 친숙한 단어들이 보인다.

 

논리학이나 형이상학에서 쓰이는 용어들은 컴퓨터 프로그래밍의 설계에 쓰이는 단어와 겹치는 것들이 많다. 단어만 겹치는 것이 아니라 용도도 비슷하다. 그만큼 무형의 세계를 모델링하고 창조하고, 재사용하는 관점에서 보면 프로그래머는 철학자들이다.


instance

type

property

relation

concrete

inhere

ontology

class


저 위키피디어에서 보편자를 설명하기 위해 쓰인단어만하더래도 데이터 모델링하는데 사용되는 용어들이 그대로 사용되며, 심지어는 의미도 비슷하다.

Metaphysics와 Physics를 한국어로 바꾸면, 각각 형이상학과 물리학이 된다. 한국어의 차이만큼 영어를 모국어로 하는 사람들도 차이가 날까? 일단 차이가 나든 말든, 단어의 형태에 있어서는 영어로 된 단어가 뭔가 더 근사하지 않나 싶다. 형이상학과 물리학은 전혀 다른 학문으로 보이지만, Metaphysics와 Physics는 어딘가 모르게 Physics를 기준으로 하고 그에 대한 meta-적인 관계를 의미하지 않나 싶다.

테일러 급수(Taylor Series)가 18세기 Taylor에 의해 고안된 방식인 줄 알았는데, 먼저 발견한 사람은 스코틀랜드 James Gregory라는 17세기의 천재적인 학자였다. 테일러 급수는 sin, cos, exp 등의 초월함수의 정확한 값을 최대한 근사하게 찾아낼 수 있는 방법인데 (무식하게 그래프를 선으로 그은 다음 자로 측정하는 것이 아닌), 이런 접근이 가능해지자, 그 유명한 오일러의 공식이라 알려져 있는




이라는 식이 유도된다. 


테일러 급수는 함수를 X에 대한 고차 방정식으로 표현가능하다고 할 때, 고차 방정식은 X=0일때 상수항만 남게 되고, 함수를 미분할 때마다 모든 차수는 1씩 내려오는데 이 때, 상수항은 사라지며, 일차항이 상수로 내려오는 성질을 이용하며, X가 무한대로 갈때 고차항들이 0으로 수렴하는 상황을 가정하면, 모든 항의 계수를 구할 수 있다는 원리이다.


가만히 들여다 보고만 있어도 기분좋아지는 수식.... 머리 좀 식히는데 사용하자.


서비스에 접근이 안돼서 게임을 할 수 없다고한다. DNS 문제인지, 내 서버의 정합성 문제인지 아... 귀찮다.

완성이 다 되지 않아도 출시를 위주로 행동하라.

물론 미완성 작품을 내라는 것이 아니라, 부족해 보이더라도 좀 더 추가 하거나 바꾸자는 말을 하지 말라는 얘기지.


지금은 마윈이나 손정의의 입을 통해서 나오고, 자기개발서 같은 글에서 저 주제가 나온다.


수년전 스타트업 초기 멤버로 활동할때도 강조되었던 말이고, 그 이전에도 들었던 말이다.

언젠가는 진리(?)의 금문자가 될 것이다.

행동하고 사고하는 과정에 일정한 패턴이 생겨 그것을 추상화할 수 있다. 여러 행동의 객체를 제거하면 비슷한 것들의 추상화 단계를 통합하여 그룹지을 수 있을 것이며, 논리적 추론에서도 사고의 각 질료들을 배제한 논리전개의 추상화된 구조만을 건질 수 있다면 또한 여러 추론을 그룹지을 수 있다.


이런 추상화단계를 통한 그룹짓기는 궁극적으로 재사용을 하기 위함이다. 재사용은 그 자체만으로도 똑같은 일을 할 수도 있지만, 더 큰 단계의 부분으로 참여시킬 수 있는 일종의 정지(prune)작업인 것이다.


여기까지는 흔히 생각할 수 있는 추상화의 정리라 볼 수 있으나, 중요한 사실은 추상화된 행동이나 사고 그 자체는 실상 존재하지 않는 것이다. 구체적인 무언가로의 적용이 있기 전까지는 그 추상단계란 보이지 않는 것 혹은 존재하지 않는 것이다. 혹은 추상단계가 실상이며 구체적인 것은 허상이라고 말할 수 있을지도 모르겠다만, 난 연역적인 세상을 생각하는 것이 아니며, 미지의 세상에 태어나 알아가는 존재이므로 이런 입장은 취하고 싶지 않다. 추상의 단계는 구상의 존재를 인식하기 위한 하나의 장치에 불과하다. 아니 구상의 단계 조차 다른 어떤 것들의 추상이라고 말한다면 할 말은 없지만, 오감으로 인식이 되는 단위로서의 개별 존재들을 말하는 것에 집중한다.


데이터 모델링 및 핸들링을 하는데 궁극적으로는 DB를 통한 파일로 존재한다. 즉, 이름, 나이, 캐릭터, 썸네일주소, 보유한 코인수 이런 구체적인 것들(이 정도선은 인식 가능한 상태이므로 내 논의 안에 들어 있는 구상체이다)이 실제 존재하는 곳은 DB가 관리하는 파일 속 어디인가라는 뜻이다.


DB라는 제품은 많다. 내가 만든 데이터 모델 (이름, 나이...)을 어떤 DB에 저장할지 선택하기 전까지는 DB는 일종의 추상층이 된다. 그러나 MySQL이라는 제품을 사용하겠다고 결정하는 순간 MySQL이 접근하는 방식으로 행동과 사고방식이 결정된다.


MySQL은 다른 DB제품들과 비슷한 방식으로 동작하지 완전 다른 방식으로 동작하는 것이 아니다. 이때 유혹이 생긴다. 행동을 추상화하여 어떤 DB를 사용해도 내 데이터 모델을 핸들링하게 만들것인가, 아니면 MySQL에서만 사용가능하도록 추상단계를 제거할 것인가. 이 유혹은 "허세"로 다가오기도 하고, "관리상 편의"로 다가오기도 하며, "개발 속도"라는 이름으로 다가오기도 한다. 그 중간단계 어디쯤에서인가 대개 멈추게 되고 그것은 추상화라는 괴물과 싸운 흔적들로 읽혀질 수 있다. 아! 수많은 SQL문의 산재함이여~! 내 너의 모듈화와 관련된 고민을 듣노라!



내용을 전달해야 할 때, 표를 써서 가로/세로 격자안에 내용을 집어 넣는 경우가 있다. 이것이 습관이 된 것인지 문장이 아닌 모든 것을 다 표를 만들어 전달하는 것이다.


예를 들어, 스팸필터 보고서를 매일 메일로 받는다고 생각해보자.


 차단시각

제목 

 사유

 재전송

 2014-12-31 14:20:21

 (광고) 당신의 어쩌고 저쩌고...

 (광고)

 전송

 2014-12-31 17:21:19

 세계 최고의 명품

 비아그라

 전송



나열형으로 바꾸면,


  • 차단시각: 2014-12-31 14:20:21
  • 제목: (광고) 당신의 어쩌고 저쩌고...
  • 사유: (광고)
  • 재전송

  • 차단시각: 2014-12-31 17:21:19
  • 제목: 세계 최고의 명품
  • 사유: 비아그라
  • 재전송

이렇게 된다. 이런 내용을 최초 생각할 때 표를 먼저 떠올리는 것이 자연스러운가 아니면 나열형으로 떠올리는 것이 자연스러운가? 메일로 전송되는 것이라 한정했지만, 웹페이지로 보는 경우도 크게 다르지 않다. 보고서의 전달 효율성과 익숙함을 비교하는 미묘한 문제인데. 익숙한 것이 항상 효율적이지 않을 수 있기 때문이다.


수작업으로 보고하는 경우는 표를 통해 표현하는 것이 칸의 간격을 조절하거나 내용을 간이 편집을 하여 잘 꾸며낼 수 있다. 하지만, 그것이 자동보고서인 경우 최적의 디자인을 만들어 내지 못할 수도 있다. 위와 같이 제목에 해당하는 부분은 디자인을 망치는 주 요소가 된다.


표가 익숙해서 표를 통한 보고서가 쉬울 것 같지만, 난 이런 디자인을 요구할 때마다 항상 표 보다 다른 방식이 있지 않을까를 고민한다.

아무 느낌 없는 느낌

Docker가 가져 올 또 다른 가상화의 환경변화는 배포의 의존성 해결에 기원이 있다.


배포의 의존성은 늘 성능문제와 씨름하는 주제였는데, 과거에는 static link와 dynamic link에도 있어왔고, 각종 OS의 패키지 매니저에 존재해 왔고, 애플의 Contents 를 정의하는 디렉토리 구조에 존재해 왔었다(애플은 그저 디렉토리단위로 이동시키면 설치가 가능한 모델이 있다). 이젠 그 의존성 문제에 있어 프로그램 단위를 넘어서 환경 전체를 하나의 배포 단위로 할 수 있는 컴퓨팅 환경이 도래한 것이며, 앞으로 이런 모델은 계속 튀어 나올 것이다.


"내 컴퓨터에서는 잘 돌아요"라고 외치는 것은 의존성문제와 연결되어 있는 전형적인 개발자의 외침이다. 그 "내 컴퓨터"를 최종 사용자에게까지 전달하면 되는 것 아닌가라는 식의 접근을 감히 해보는 것이 이런 기술들이 사용되는 지극한 예이다.

에볼라가 과거 치사율이 높아서 숙주를 다 죽이기 때문에 확산이 되지 않은 예로 언급되었었는데, 치사율이 낮아지니 확산이 되기 시작하는구나.

+ Recent posts