라떼군 이야기

  믿기 어렵겠지만 몇 년 전만 해도 간단한 정보를 검색하기 위해선 백과사전이 필요했고 적은 분량의 백과사전에서 찾을 수 없을 땐 도서관에 가야 했고 또 작은 도서관에서 찾을 수 없을 땐 좀더 큰 도서관으로 가야 했었다. 과연 지금의 중학교, 고등학교 학생들은 과연 몇 명이나 이래야만 했던 사정을 이해해줄지 모르겠다.

 하지만 이제는 사정이 달라졌다. 인터넷의 등장으로 예전처럼 정보검색에 수많은 시간과 노력을 쏟지 않아도 더 쉽게 더 좋은 자료를 검색할 수 있고 그를 여러 가지 형태의 미디어로 접할 수 있는 시대가 되었다. 예전에 ‘팀 버너스 리(Tim Berners-Lee)’ 가 처음으로 구체적으로 주장했던 하이퍼미디어(Hypermedia)와 그로 이루어진 인터넷으로 인해 우리 생활은 많이 변화했고 또 이제는 없어서는 안될 것으로 멀티미디어 환경으로 진화해 왔다는 사실은 아무도 부인하지 못할 것이다.

 사실 인터넷의 등장만으로도 우리에겐 막대한 영향을 끼쳤다. 하지만 여기서 인터넷의 멀티미디어로서의 역할을 배제한다면 그 영향력을 전부 얘기하지는 못할 것이다. 멀티미디어로서의 인터넷은 위에서 얘기한 것처럼 빠른 정보검색은 물론이고 보다 효율적인 방법으로 정보전달의 기능을 가지고 있다.

 대학교 1학년 때 처음 컴퓨터를 공부할 때 일이다. 네트웍에 대해 공부하고 있었는데 마침 네트웍을 설명하고 있는 동영상을 인터넷에서 발견했다. ‘The dawn of the Net’ 이라는 동영상 이였는데 네트웍 패킷이나 라우터, 라우터 스위치 등등 전체적인 네트웍에 대해서 알기 쉽게 설명한 동영상이었다. 이 동영상은 너무 쉽고 직관적이어서 누구라도 이것을 본 사람이라면 네트웍에 대해 모두 안 것 같은 착각을 하게 만들 정도였다. 하지만 대략적인 네트웍에 대해서 안다고 해서 전문가가 되었다고 말할 수는 없을 것이다. 간단해 보이는 현상 뒤에 숨겨져 있는 지식들을 모두 이해하고 설명할 수 있을 때 비로소 전문가라 부를 수 있을 것이다.

 이런 멀티미디어적인 환경은 대부분에 사람들에게 보다 폭넓은 지식을 요구하는 사회로 변화하게 되었고 이 같은 지식을 강조하게 되었다. 반면에 깊이 있는 지식은 간과하는 사회 분위기를 만들어 가고 있다. 어떤 면에서는 굉장히 비약적인 발전을 이루어 온 것도 사실 이지만 과도기적인 문화를 겪지 못한 한국의 경우에는 이공계, 특히 소프트웨어 발전에 좋은 영향을 끼쳤다고는 볼 수는 없을 것이다.

 소프트웨어 발전에 가장 중요한 역할을 하는 것은 그 나라의 문화라고 생각한다. 지금처럼 한 명의 개발자가 얕은 지식으로 데이터베이스 설계에서부터 개발 관리자의 역할 때에 따라선 컨설턴트의 역할까지 모두 해야만 하는 이러한 우리의 현실은 소프트웨어 발전을 저해하고 있는 것이다. 소프트웨어는 누구나 간단한 교육만으로 진입 가능할 수 있는 일명 청바지산업이 아니라 보다 전문적이고 체계적으로 교육받는 사람만이 가능한 산업이 되어야 할 것이다.

  결과 만을 중시하고 넓고 얕은 지식을 필요로 하기 보다는 과정을 중시하고 한 한곳에 깊은 지식을 가질 때 비로소 진정한 IT 강국으로 발전할 수 있을 것이라 생각한다. 이제 우리는 이런 멀티미디어적인 환경을 보다 잘 활용해 전처럼 중국 발 해킹으로 허술하게 뚫려 개인정보가 유출되거나 마땅히 지켜야 할 기본적인 표준 HTML 문법조차 지키지 못해 다른 브라우저를 사용하는 대다수의 외국고객들을 놓치는 일은 이제는 없어야 하겠다.

 우리도 이제 38세가 되면 38선을 넘는다느니 퇴직해야 한다느니 하는 우리나라의 분위기보다는 나이가 들면 들수록 좀더 깊은 전문성으로 소프트웨어 개발에 힘쓰는 그런 시대가 오기를 바란다. 백발을 휘날리며 소프트웨어 개발에 힘쓴다거나 한국사람 최초로 ‘튜링상(Turing Prize)’을 수상하는 일도 이미 잘 갖추어진 멀티미디어 환경을 잘 활용하고 발전시켰을 때 이런 일도 우리에게는 꿈 같은 일만은 아니라고 생각한다.@

[참고문헌]
http://www.wikipedia.org/

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 라떼군

 오늘 소공동 롯데 호텔에서 열리는 '성공적인 SOA 도입을 위한 IBM 제언 세미나' 에 다녀왔다. (SOA: Service-oriented architecture) 세미나에 참석하게 된 가장 큰 이유는 세미나 아젠다(Agenda) 중에 '웹 서비스 및 XML의 한계와 이의 극복 방안' 이라는 주제가 있어서 기대하며 다녀오게 되었다. 기대가 너무 컸던 탓일까? 발제자들은 많은 것을 알고 있으면서도 잘 알려주려 하지 않는 것 같아 보였고 모든 XML(Extensible Markup Language)과 관련된 문제점들을 자신들의 제품에서만 해답을 찾으려고만 하는 것 같다 좀더 기술적인 내용을 기대하고 참석했던 나로써는 좀 아쉬운 세미나가 된 것 같다.

 나는 항상 세미나를 하고 거기서 전달이 가능한 내용들은 발제자가 알고 있는 지식의 25% 정도 밖에 되지 않는다고 개인적으로 생각하고 있다. 발제자의 능력이 100%이라고 한다면 여러 사람의 수준을 맞추는데 50%의 전달능력을 상실되고 자신의 지식을 또 알맞게 포장하는데 또 50%의 전달능력이 상실된다고 생각한다. 그만큼 수준이 다른 여러 사람들을 대상으로 발표하고 그것을 이해시키기가 그만큼 어렵다는 말이다. 그래서 나는 누가 세미나를 들을 때 발제자의 실력이 내가 느끼는 것보다 4배정도 잘하는 사람이라고 미리 생각하고 세미나를 듣는다. 그런데 오늘 첫 번째 세션을 발표하시고 미국 IBM에서 근무하시고 계신다는 '손성익' 이란 분은 세미나를 통해 느껴지는 그분의 내공도 대단했지만 실제 그분이 오랜 기간 대기업에서 소프트웨어 산업에 몸담고 있으면서 겪었던 경험들을 생각할 때 더 대단한 분 일거라는 생각이 들었다.

 대기업 개발자들과 만나 볼일은 별로 없지만 가끔 만날 때마다 공통적으로 느끼는 점이 있었다. 오늘도 마찬가지로 그런 느낌을 느낄 수 있었는데 그것은 대기업 개발자와 중소기업 그리고 소기업 개발자와는 확실히 차이가 난다는 것이다. 그 차이는 간단히 말해서 100억짜리 프로젝트를 해본 개발자와 1억짜리 개발을 해본 개발자와 1,000만 원짜리 개발을 해본 개발자로 달리 말할 수 있겠다. 사실 100억짜리 프로젝트라고 해서 뭐가 그렇게 다르겠는가? 그렇게 비싼 프로젝트라도 황금으로 만든 키보드와 마우스로 작업하거나 매일 저녁 야식을 위해 스테이크를 구워먹거나 하지는 않을 것이다. 그냥 똑 같은 프로젝트일 뿐인데 어떤 프로젝트는 여러 회사들의 이해관계가 얽혀(혹은 국가 일지도 모르겠다) 가격이 올라가고 또 그러기에 좀더 중요한 프로젝트라 불려지는 것뿐이다.

 그래도 나는 개발자라면 한번쯤은 큰 규모의 프로젝트를 해볼 필요가 있다고 생각한다. 그런 큰 규모의 프로젝트를 해봄으로써 작은 프로젝트에서는 결코 경험할 수 없는 새로운 문제점들을 경험할 수 있게 될 것이라고 확신한다. 그런 문제점들을 해결해 나감으로써 다른 프로젝트를 바라보는 보다 넓은 시각을 갖게 해줄 것이라고 생각한다.

 사실 소프트웨어 공학에서 나오는 대부분의 것들이 소규모 프로젝트를 대상으로 하고 있는 것은 없지 않은가? 심지어 오늘 세미나의 주제인 SOA도 그렇지 않은가? “SOA는 기업의 소프트웨어 인프라를 구축하는 방법으로 서로 다른 운영체제와 프로그램에 상관없이 애플리케이션간에 데이터와 프로세스를 교환할 수 있는 아키텍처를 말한다.“라고 IBM사이트에서도 말하고 있듯이 그 내용부터 소규모 프로젝트는 벌써 배제되고 있음을 알 수 있다. SOA 탄생의 궁극 목적도 새로 개발하거나 유지보수에 따르는 비용이 큰 대형 레거시 시스템(Legacy System)들을 어떻게 최소 수정으로 신규 시스템에 통합할 것인가로부터 생각이 출발한 것이 아닐까?

 요즘 내가 일하는 부서에서는 소스통합에 대한 이슈가 제기되고 있다. UI와 플래폼(Platform)과 개발언어는 다르지만 기능이 비슷한 두 프로젝트의 소스를 하나로 합쳐 추후 지금보다 낮은 비용으로 개발하고자 하는 것이 그 목적이다. 하지만 물론 가능은 하지만 그 작업으로 인해 앞으로 나타날 험난한 프로젝트의 문제점들과 시행착오들이 나에게는 그저 깜깜하게 보일 뿐이다.

 SOA도 좋고 웹 서비스도 좋고 IBM에서 말하는 하드웨어로 구현된 엄청 빠른 XML파서인 DataPower도 좋지만 그것들의 장점을 살릴 수 없는 중소형 프로젝트들과 만약 장점을 살릴 수 있는 길이 있다고 하더라도 그것들을 관리자에게 제대로 이해시키지 못하는 나 같은 개발자에게는 그저 공허한 울림이 될 수 밖에 없다. 보다 풍부한 경험이 있었더라면 더 좋은 방향을 제시할 수도 있을 거라 생각을 하면서 나에게 있어서 여러 가지 상황의 경험과 그에 맞는 기술적 조합이 부족함을 절실히 느낀다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 라떼군

 소프트웨어 개발자(software developer)로써 일을 하다 보면 기획자와 많은 시간을 보내게 된다. 여기서 기획자란 말은 소프트웨어의 요구사항을 만들어내는 사람이라고 봐도 좋겠다. 혹은 드물겠지만 기획자라고 부를 만한 사람이 없다면 소프트웨어를 사용하는 사용자를 떠올리기 바란다.

 요구사항을 만들어내는 사람들은 개발자를 곤혹스럽게 하곤 한다. 그것은 근본적으로 개발자가 하고 싶지 않은 일을 시키기 때문이라고 생각한다. 개발자는 성능을 중시하고 코드가 얼마나 간결한지를 중시하곤 하는데 복잡한 요구사항들은 이런 코드를 지저분하고 복잡하고 느린 모습으로 바꾸곤 하기 때문이다. 하지만 자신의 소프트웨어가 살아 있는 한, 자신의 소프트웨어를 사용해주는 사용자가 있는 한, 요구사항이 있는 한 이러한 일은 끊이지 않을 것이다.

 같은 요구사항이라도 기획자에 손을 어떻게 거치느냐에 따라 어렵고 시간이 오래 걸리는 것이 있는 반면 간단하면서 빨리 끝낼 수 있는 일도 있었던 것을 많이 보아왔다. '실력 있는 개발자라면 오래 걸리는 개발도 쉽게 끝낼 수 있을 않느냐?' 라고 반문하실 지도 모르겠다. 하지만 이건 실력하고는 별개의 문제라고 생각한다. 나의 경험을 비춰 봤을 때 똑같은 기능이라도 어떤 기획서는 작업하기 쉬웠던 반면에 어떤 기획서는 작업하기 힘들었던 적이 분명히 있었기 때문이다. 이것은 기능의 많고 적음을 얘기하는 것은 결코 아니다.

 어려운 기획서의 가장 큰 부분은 기존에 이미 요구돼있던 기능의 기본적인 틀의 변경이 여러 번 번복되어서 가해지는 부분이다. 한번 이렇게 바꿔보고 또 아니다 싶으면 다르게 바꿔보는 식이다.

 이것이 어려운 이유는 간단해 보이는 요구사항일지라도 소프트웨어 설계 전체에 대한 수정이 가해져야만 적용될 수 있는 부분이 있기 때문이다. 웹 어플리케이션을 예로 들면 대부분 데이터베이스와 밀접한 관계를 가지고 그것의 설계에 기초 하는 것들이 많기 때문에 데이터베이스의 설계가 심하게 변경 되어야만 했을 때 데이터베이스 레이어(Database layer)부터 프레젠테이션 레이어(Presentation layer)까지 수 많은 부분들이 변경되어야만 한다. 기획자는 기존 요구사항에 대한 수정 또는 요구사항 번복에 대해 충분히 신중해야 할 것이다. 사실 이것이 내가 실제로 일을 하면서 기획자들에게 가장 불만을 갖고 있는 부분 이기도 하다.

 사실 기획자들이 이런 변경에 대한 요구를 끊임없이 해오는 이유는 고객의 요구사항을 제대로 파악하지 못해서 생긴 일이 대부분 이라고 생각한다. 일반 고객들이 바로 요구사항을 만들어내는 상황의 소프트웨어라면 이런 잦은 요구사항 수정에 책임은 요구사항을 제대로 파악하지 못한 개발자에게 있다 것이다. 또 기획자에 의도를 제대로 파악하지 못해 엉뚱한 것을 만들어 내고 있었다면 이것 역시 개발자 책임일 것이다. 그냥 한번 만들어보고 그게 아니면 또 바꾸는 식의 해결방법은 곤란하다. 하지만 이런 문제를 해결할 수 있는 방법은 얼마든지 있다.

 프로토타입(Prototype)을 이용해 해결할 수 있다. 프로토타입이란 어떤 구조물이나 장비에 대하여, 형상이나 설계, 적합성 또는 성능 등을 평가하기 위해 만든 실물 크기의 모형을 말한다.(http://terms.co.kr) 즉, 기획자가(고객이) 무엇을 원하는지 제대로 모를 때 프로토타입을 빠르게 만들어서 보여주고 ‘이게 맞습니까?’ ,’이 정도면 되겠습니까?’ 이렇게 물어볼 수 있는 것이다. 요구사항이 명확히 파악된다면 그걸 기반으로 더 잘된 설계를 이끌어 낼 수 있을 것이다.

 또는 그 소프트웨어를 가지고 일하는 사람들과 같이 지내 봄으로써도 해결할 수 있다. 요구사항을 제대로 파악하지 못하는 이유 중에 하나가 자신의 소프트웨어를 자신이 실제로 써보지 않아서 어떤 것이 어떻게 불편한지 제대로 알지 못해서 일 것이라고 나는 확신한다. 웹 메일 서비스라면 자신이 직접 웹 메일을 써봐야 어떤 점이 업무를 불편하게 하는지 알 수 있을 것이고 게임을 만든다면 직접 그 게임을 해봐야 어떤 점이 재미없는지도 알지 않겠는가?

 나는 개발자들이 개발에만 열중할 것이 아니라 고객(또는 요구사항을 만들어내는 기획자)과 소통하는데 더 노력을 기울일 것을 권하고 싶다. 이것이 바로 자신의 소프트웨어를 성공 시킬 수 있는 진정한 one way 인 것이다. 코드가 깔끔한 소프트웨어라고 성공하는가? 자신의 소프트웨어가 사용하기 불편한 대신 코드가 깔끔하다고 광고할 생각인가? 심지어는 버그가 많은 소프트웨어가 다른 경쟁 업체들을 제치고 성공하기까지 하는 이유는 바로 요구사항을 다른 경쟁 업체들 보다 제대로 파악했기 때문이 아닐까?@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 라떼군

 프로그래밍 작업은 고통스럽다. 사실 프로그래밍하는 작업이 고통스러운 건 아니다. 그건 즐거운 일이며 나에게 있어 생각만으로도 아드레난린(Adrenaline)을 분비시켜 힘을 나게 한다. 하지만 그것이 일과 연관 되어있을 때는 마냥 즐거운 일일 수만은 없다. 프로그래머는 일할 때는 초현실적인 UI(User Interface: 사용자 인터페이스)를 만들어내는 기획자도 설득해야만 하고 자꾸 모호한 말만 하는 애매한 디자이너도 상대해야 하기 때문이다. 하지만 프로그래밍을 하는 사람으로써 마냥 고통스럽게 있을 수만은 없다. 고통의 연속이라면 더 이상 생산성을 떨어뜨릴 뿐만 아니라 회사의 월급도둑 역할만 하는 일은 그만두고 다른 직업을 찾아보는 것이 본인에게도 좋을 것이다. 그럼 항상 즐거울 수만 없는 이런 일들을 어떻게 즐기며 일할 수 있을 것인가?

 먼저 '잘 쉬어야 한다.' 일하는 모든 사람들에게 적용되는 말이다. 잘 일하기 위해서는 잘 쉬어야 한다. 하지만 이 말을 오해하는 사람들이 있다. 쉬라는 말이 집에 누워서 아무것도 하지 않은 채로 시체놀이 만으로 주말을 보내라는 그런 말은 아니다. 쉬는 것은 일 외에 다른 곳에 관심을 돌리는 것을 쉬는 것이라고 말할 수 있다. 예를 들면, 회사에서 가상 파일시스템을 개발하는 사람이 남는 시간을 통해 웹 메일 클라이언트를 만들어 오픈 소스 커뮤니티에 올리는 일을 했다라고 한다면 그 사람은 쉬었다 라고 말할 수 있다. 또는, 남는 시간을 통해 새로운 언어(Python, Perl, Lisp …) 공부하는 것도 마찬가지다. 잠시 짜증나는 업무에서 벗어나 생각을 리프레시(refresh) 함으로써 일을 더 즐겁고 잘할 수 있는 것들이 여기에 포함될 것이다.

 '원인을 분석해야 한다.' 일이 힘들어 졌을 때는 왜 일이 힘들어 졌는지 어떤 일 때문에 즐겁지 않은지 원인을 분석해야 할 필요가 있다. 노트에 하나씩 적어보자. 예를 들면 이런 것들이 있을 수 있다. '기획자가 보내온 기획서가 너무 엉망이다.', '요구사항이 너무 수시로 바뀐다.', 또는 '상사가 나를 싫어한다.' 등등.. 하나씩 적어보자. 만약 하나도 적을 것이 없거나 납득할만한 내용을 적을 수 없는데 일이 힘들어졌다면 그건 자신에게 문제가 있는 것이다. 모두 적었다면 하나씩 해결하려고 노력해볼 필요가 있다. 기획서가 너무 엉망이라면 왜 엉망인 기획서인지 기획자에게 알려주고 다음부터 보완하도록 얘기해볼 수 있을 것이다. 요구사항이 너무 수시로 바뀐다면 경험적으로 바뀌는 요구사항에 맞게 어느 정도 유연한 설계를 할 필요가 있을 것이고, 상사가 나를 싫어한다면 그 원인을 알고자 상사와 대화해야 할 것이다.

 '커피를 마셔라.' 여기서 커피는 자판기 커피나 커피 믹스는 제외한 것이다. 1994년 일본 교린 대학의 연구결과에 따르면 커피 향은 뇌의 혈액량을 증가시키고 뇌파를 변화시켜서 집중력과 쾌감 기능을 높여 준다고 밝혀졌다. 자판기 커피나 커피믹스는 향이 적고 그다지 좋지 않으므로 에스프레소(Espresso)를 마실 것을 권하고 싶다. 난 카페라떼(Latte), 카푸치노(Cappuccino)를 좋아한다. 예전에 홍대 앞에서 근무할 당시 매일 한잔씩 마시던 카페라떼 향은 아직도 잊을 수 없다. 그때 회사가 참 힘들었었는데 생각해보면 그때 힘들었던 일들을 커피 덕에 조금이라도 덜 힘들게 일할 수 있지 않았나 싶다. 커피 한 모금처럼 본인에게 더 맞는 리프레시 수단이 있다면 그것을 찾을 것을 권하고 싶다.

 하나씩 고통의 원인을 제거해 보면 프로그래머로써 일하는 것은 고통스러운 일이 결코 아닐 것이다. 고통은 대게 나 자신에게서 시작되고 있고 그게 해결되지 않은 채로 지속되고 있을 땐 결국엔 지쳐 쓰러지게 된다. 그때는 어떤 원인 때문에 내가 힘들어 하는지도 모르고 아무리 쉬어도 회복될 수 없는 상태가 되고 말 것이다. 프로그래밍 작업만 분석적으로 할 것이 아니라 자신의 생활도 디버깅 하듯이 혹은 '커피' 같은 툴의 도움을 받아 고통의 원인을 하나씩 찾아서 해결해 보는 것은 어떨까? @

이미지: Stress Qoutes, http://1927cafe.wordpress.com/2007/09/26/stress-qoutes/

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 라떼군

 나는 이른바 코딩 해서 먹고 살고 있는 프로그래머라 불리는 사람 중 한 명이다. 하루 종일 코딩 하기 위해 애쓰는 그런 사람 중 한 명이란 말이다. 그런데 요즘 들어 문득 오픈 소스 커뮤니티를 돌아다니다 나보다 뛰어난 수많은(개인적으로 우리나라 프로그래머 중에 80%이상은 나보다 뛰어날 거라 생각한다) 프로그래머를 만나면서 나의 작은 존재감에 다시 한번 생각하게 되었고 그럼 과연 내 프로그래밍 철학은 무엇인지 생각해 보게 되었다.

 프로그래밍 철학이란 다시 말해서 내가 프로그래밍을 하면서 추구하는 궁극적인 목표라고도 말할 수 있을 것이다. 그렇게 말할 수 있는 이유는 철학이 행동을 만들고 그 행동은 그 사람의 삶의 목표와 맞다 아 있다고 생각하기 때문이다. 그럼 내가 프로그래머 직업을 가지면서 궁극인 목표로 삶고 있는 것이 무엇일까? 한참을 생각해 봤지만 부끄럽게도 목표라고 내세울만한 건 없었다. 지금 하는 프로젝트 대박 내는 것? 아니면 열심히 해서 회사 잘 키워보는 것? 물론 이것들도 중요하지만 아무래도 이런 것들은 철학, 목표라고 하기에는 너무 근시안적인 것뿐이다.

 난 웹(web) 프로그래머라 불리는 사람이다. 닷넷(.net)을 이용해 개발하고 있고 주로 사용하는 언어는 C#이다. 그렇다고 아직 C#전문가라 불릴만할 정도로 그 부분에 대해 권위가 있는 수준은 아니다. 또 어느 한 플랫폼에 집중돼서 전문가라 불리는 것도 원하지 않는다. 플랫폼에 집중된 노력을 쏟는 것은 멀리 볼 때 발전가능성을 더디게 한다고 생각해서이다. 하지만 웹 프로그래머들은 상대적으로 그런 부분이 취약하다. 자신의 플랫폼 이외의 플랫폼에는 관심이 덜하거나 관심이 전혀 없는 실정이다. 주위에 php하는 프로그래머와 닷넷 프로그래머와 대화해 보라. 쉽게 알 수 있을 것이다. 과연 웹 프로그래머로써의 나의 철학은 뭘까?

 난 웹 사이트와 윈도우 어플리케이션을 비교해서 말하는 것이 싫다. 그것보다 어플리케이션 이라는 말이 윈도우 프로그램을 대표하는 단어가 됐다는 게 싫은 것이다. 웹은 어플리케이션이 아니고 윈도우 UI를 가진 프로그램만이 어플리케이션이란 말인가? 익숙해져서 인지 주위에 그렇게 말하는 사람들을 많이 볼 수 있다. 실제로 그런 말을 들을 때마다 웹 어플리케이션, 윈도우 어플리케이션 이렇게 말해야 맞는다고 정정해 주고 싶은 심정이다. 내부를 들여다 보면 더 다르지 않다는 것을 볼 수 있다. 단지 웹은 웹API를 이용할 뿐이고 웹 브라우저를 이용할 뿐인데 말이다.

 다시 처음으로 돌아가면 프로그래밍 철학이란 결국 플랫폼이나 개발언어에 국한되지 않은 목표가 되어야 하고 근시안적인 목표가 아닌 인생전체를 걸고 추구해야 할 목표였으면 하는 것이다. 올림픽에서 매달을 딴 선수가 자신의 목표한 것을 이뤘기 때문에 기쁨과 감격의 눈물을 흘리듯이 내가 세운 프로그래밍 철학을 내가 이뤘을 때 감격할 수 있는 그럼 목표를 세웠으면 하는 것이 나의 바램인 것이다. 이 글을 쓰면서 한 문장으로 정리된 목표는 아직 말할 수 없지만 어떤 방향인지는 대충 정리가 된 느낌이다. 그걸 이루기 위해 계속 긴장을 늦추지 않고 노력해야 할 것이다. 또, 그럼 목표를 이룰 수 있는 지금 나의 상황들 모두가 감사할 뿐이다.@

[사진] 어거스타 에이다 킹, 러브레이스 백작부인(Augusta Ada King, Countess of Lovelace) : 최초의 프로그래머

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 라떼군