티스토리 뷰
요즘들어서는 웹 2.0 혹은 그와 비슷한 류의 기술적(?) 진보에 대해 생각이 많이 들어갑니다. '상술'이라 단정하기 전에, 그 뒤에 관련된 개념을 다음과 같이 정리하면, 아마 인류의 학문적 진보 성향과 그다지 멀지 않음을 알 수 있을 것 같습니다.
근 10년간, 디자인 패턴들이 그래왔고, 테스트 주도 개발 프레임웍이 그래왔고, 웹 2.0, REST, 자바스크립트(Ajax) 프레임웍들, 오픈소스 개발 방법론이 그래왔습니다.
지금 당신이 하고 있는 일을 누군가에게 설명하기 위해서, 또 당신과 비슷한 일을 하는 사람과 대화를 하기 위해서, 취업을 위해서, 열심히 일했지만 성과에 대한 평가가 없는 것을 자위하기 위해서 등등 수많은 행위속에는 바로, 이름을 붙이고 공감하는 작업이 계속 이루어져 왔습니다.
20세기 초반 격변을 일으켰던 철학의 수많은 사조도 그렇고 (제가 이런말을 하니 우습군요), 마케팅 방법들도 그렇고, 금융에 대한 갖가지 방식들도 그렇습니다. 누군가는 그것을 설명해야하고, 그것이 주류와 어떻게 다른지를 커뮤니케이션하기 위해 이름을 붙입니다. 이때, 가치가 만들어지고, 그 가치는 그 이름을 타고 떠 다닙니다.
늘 하던 것을 남이 이름을 붙여 포장하다고 폄하하는 것은 그 안에 만들어진 가치를 보지 못하는 일입니다. 한 단어로 설명될 때, 수많은 헛수고로 끝날 일들이 가치로 보관이 되고, 계속 발전하게 되는 것입니다.
제가 말하고 싶은 것은 내가 하는 일에 쿨엔지니어 프레임웍과 같은 새로운 이름을 붙이라는 것이 아닙니다. 세상에 그 가치를 알만한 사람은 당신밖에는 혹은 그 팀원밖에는 없습니다. (물론 전사적으로 몇 백명 되면 말은 달라지겠지요) 오히려 누군가는 비슷한 일을 했을 것이고, 그것을 자신의 경험에 비추어 차이를 알고, 익히라는 것입니다.
왜 디자인 패턴이 생산성을 높힌다고 생각하십니까? 공부하느라 생산성이 높아지지 않을 수 있습니다. 하지만, 정형화된 이름을 가진 설계가 있을 때, 시장에는 그런 경험을 가진 X맨을 구할 수 있게 되는 것입니다.
왜 오픈 소스 프로젝트에 참여한 경험이 중요합니까? 그것은 오픈소스 프로젝트가 가지는 어느정도 정형화된 개발 방식을 사내 프로젝트의 방법을 도입할 경우 어딘가에 있을지 모르는 X맨과 경험을 일치시키는 작업으로서 중요한 것입니다.
왜 테스트 주도 프로그램을 도입하는 것이 중요합니까? 어떤 언어든 비슷한 형태의 테스트 프레임웍이 있습니다. 이런 방식을 도입할 경우 어딘가에 있을 비슷한 방식의 X 맨과 쉽게 얘기할 수 있게 됩니다.
조직은 X맨을 영입하면 되는 것이죠.
지금은 도입의 장벽이 무서워 피하기 보다는 조직과 개인의 체질 개선을 생각하여 가치 있는 이름의 동향을 살피고 습득하는 것이 중요한 시점입니다.
늘 하던일에 이름을 붙이는 순간 다른 것과 구별되며, 가치를 운반할 수 있는 운반자(캐리어)가 됩니다제가 주목하고 싶은 것은 판단하지 못하던 것에 대한 가치를 메기는 작업을 누군가가 한다는 것입니다. 그런 가치가 서로 공유되기 전에 누구는 상술이라는 이름으로 폄하하거나, 누구는 나도 그렇게 개발해왔다라고 말하면서 깊이 들여다 보지 않는 우를 범하게 됩니다.
근 10년간, 디자인 패턴들이 그래왔고, 테스트 주도 개발 프레임웍이 그래왔고, 웹 2.0, REST, 자바스크립트(Ajax) 프레임웍들, 오픈소스 개발 방법론이 그래왔습니다.
지금 당신이 하고 있는 일을 누군가에게 설명하기 위해서, 또 당신과 비슷한 일을 하는 사람과 대화를 하기 위해서, 취업을 위해서, 열심히 일했지만 성과에 대한 평가가 없는 것을 자위하기 위해서 등등 수많은 행위속에는 바로, 이름을 붙이고 공감하는 작업이 계속 이루어져 왔습니다.
20세기 초반 격변을 일으켰던 철학의 수많은 사조도 그렇고 (제가 이런말을 하니 우습군요), 마케팅 방법들도 그렇고, 금융에 대한 갖가지 방식들도 그렇습니다. 누군가는 그것을 설명해야하고, 그것이 주류와 어떻게 다른지를 커뮤니케이션하기 위해 이름을 붙입니다. 이때, 가치가 만들어지고, 그 가치는 그 이름을 타고 떠 다닙니다.
늘 하던 것을 남이 이름을 붙여 포장하다고 폄하하는 것은 그 안에 만들어진 가치를 보지 못하는 일입니다. 한 단어로 설명될 때, 수많은 헛수고로 끝날 일들이 가치로 보관이 되고, 계속 발전하게 되는 것입니다.
제가 말하고 싶은 것은 내가 하는 일에 쿨엔지니어 프레임웍과 같은 새로운 이름을 붙이라는 것이 아닙니다. 세상에 그 가치를 알만한 사람은 당신밖에는 혹은 그 팀원밖에는 없습니다. (물론 전사적으로 몇 백명 되면 말은 달라지겠지요) 오히려 누군가는 비슷한 일을 했을 것이고, 그것을 자신의 경험에 비추어 차이를 알고, 익히라는 것입니다.
왜 디자인 패턴이 생산성을 높힌다고 생각하십니까? 공부하느라 생산성이 높아지지 않을 수 있습니다. 하지만, 정형화된 이름을 가진 설계가 있을 때, 시장에는 그런 경험을 가진 X맨을 구할 수 있게 되는 것입니다.
왜 오픈 소스 프로젝트에 참여한 경험이 중요합니까? 그것은 오픈소스 프로젝트가 가지는 어느정도 정형화된 개발 방식을 사내 프로젝트의 방법을 도입할 경우 어딘가에 있을지 모르는 X맨과 경험을 일치시키는 작업으로서 중요한 것입니다.
왜 테스트 주도 프로그램을 도입하는 것이 중요합니까? 어떤 언어든 비슷한 형태의 테스트 프레임웍이 있습니다. 이런 방식을 도입할 경우 어딘가에 있을 비슷한 방식의 X 맨과 쉽게 얘기할 수 있게 됩니다.
조직은 X맨을 영입하면 되는 것이죠.
지금은 도입의 장벽이 무서워 피하기 보다는 조직과 개인의 체질 개선을 생각하여 가치 있는 이름의 동향을 살피고 습득하는 것이 중요한 시점입니다.
반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- Tattertools plugin
- 수선화
- VIM
- writely
- 벤자민
- 킹벤자민
- 덴드롱
- Linux
- ssh
- perl
- BlogAPI
- 클레로덴드럼
- MySQL
- macosx
- SSO
- url
- nodejs
- Subversion
- 대화
- SVN
- TCP/IP
- 식물
- JavaScript
- 디버깅
- 커피
- 퀴즈
- tattertools
- 오픈소스
- OpenID
- 구근
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
글 보관함