우선은 표준과 비표준? 만 따져도 이 글은 끝이 안나겠지만,
간단하고 쉽게 일단 접근해 보려한다.
EJB ? Spring ? 개발자는 어떤 것으로 개발할지 고민한다.
WS-*? REST ? json ? 이 역시도 고민스럽다.
그 외에도 이러한 관계 (업계에서 나름 분야의 표준이라는 것과 이에 대한 문제적을 지적하며
나온 것들) 를 가지는 것들을 너무 나도 많다.
이러한 상황에서 개발자들은 무엇으로 개발을 해야할지 고민에 빠질 수 밖에 없다.
흔히 개발자들은 전자 보다는 후자에 더 관심을 가지고 만들는 것에 관심을 가진다.
표준이라는 틀 속에서 자유롭지 못함과 개발의 생성성을 표준이라는 이름하에 떨어트리고 있지않나라는 계속적인 의심속에...
하지만, 프로젝트나 실무 개발에 들어가면 이야기가 틀려진다.
내부 프로젝트에 적용하기 위해서는 이를 사용하기 위한 수차례의 검토와 테스트를 거쳐
OK 되어야만 진행할 수 있는 반면 표준이라는 이름의 것들은 이러한 절차가 너무나도 쉽다.
더욱이 고객을 상대로하는 개발은 이것이 더욱 힘들다.
(그나마 최근엔 오픈소스 프로젝트들이 업계의 인정을 많이 받으며, 좋아진 편이다.)
결국엔, 죽어나는건 개발자다.
표준과 비표준이라는 모든 것에서 최적(!)의 개발 방법과 기법들을 공부하고 익혀야 하기
때문이다. 재밌는 것은 어느 것 한쪽에만 치우쳐 있으면 개발성향을 의심받는다.
두 가지를 다 할 줄 알아야 그나마 "오~ " 한마디 외쳐준다.
나 자신부터도 이러한 생활속에 도퇴되지 않기 위해 발버퉁 쳐야만 했다.
가까운 몇년여를 돌이켜 봤을 때, 이러한 발버둥에서 나름 얻은 지식과 경험으로는 충족함
이 있었지만, 투자한 시간에 비해서는 그다지 만족스러운 결과라고는 생각하기 힘든 듯하다.
한가지 주목해야 할 부분은 ...
현실 개발자들이 좋게만 생각하는 비표준적인 것들은 호응을 하던 개발자들이 일순간
등을 돌리는 순간, 아무리 좋았던 아성(!)도 한순간에 무너질 수 있슴과
그렇게 욕을 먹고 하는 표준적인 요소도 시간의 흐름속에 사라지기 보다는 보안을 거쳐
성장해 가는 가능성이 많다는 것이다.
왜 이런 현상이 일어나는가에 대한 의구심과 고민속에 지난 해 나는 IBM이라는 회사로
옮기게 되었다. 이유는 위의 결과를 찾기 위한 중요한 요소로...
표준을 이끄는 힘은 IT를 이끄는 주요 벤더에 의해서 주도 되기 때문이란 사실 때문이다.
IBM을 옮기기 직전까지 가장 아꼈던 Spring 이란 녀석도 IBM의 정책상 걸림돌이나 도움이
된다고 생각한다면, Interface24 회사를 사버리는 것은 그다지 어려운 일이 아닐 수 있다란
결론에 도달했기 때문이다.
그래서 이러한 생각을 해보게 된다.
현 흐름에 치우쳐 무엇이 좋다더라는 것에.. 이끌려 모든 것을 투자하려 할 때는 ...
몇번이고 되집어 보기를 ... 그리고 좀 더 넓은 시각에서 볼 수 있는 눈부터 가지를 ...
그 눈을 통해 몸소 비교할 수 있는 경험을 쌓기를 ...
그리고 나서 정열을 바칠 수 있는 것에 시간을 할애하기를 ...
...
...
...
하지만, 나는 아직도 양쪽을 저울질하며 시간을 낭비중에 있다.. ㅡㅡ;;
간단하고 쉽게 일단 접근해 보려한다.
EJB ? Spring ? 개발자는 어떤 것으로 개발할지 고민한다.
WS-*? REST ? json ? 이 역시도 고민스럽다.
그 외에도 이러한 관계 (업계에서 나름 분야의 표준이라는 것과 이에 대한 문제적을 지적하며
나온 것들) 를 가지는 것들을 너무 나도 많다.
이러한 상황에서 개발자들은 무엇으로 개발을 해야할지 고민에 빠질 수 밖에 없다.
흔히 개발자들은 전자 보다는 후자에 더 관심을 가지고 만들는 것에 관심을 가진다.
표준이라는 틀 속에서 자유롭지 못함과 개발의 생성성을 표준이라는 이름하에 떨어트리고 있지않나라는 계속적인 의심속에...
하지만, 프로젝트나 실무 개발에 들어가면 이야기가 틀려진다.
내부 프로젝트에 적용하기 위해서는 이를 사용하기 위한 수차례의 검토와 테스트를 거쳐
OK 되어야만 진행할 수 있는 반면 표준이라는 이름의 것들은 이러한 절차가 너무나도 쉽다.
더욱이 고객을 상대로하는 개발은 이것이 더욱 힘들다.
(그나마 최근엔 오픈소스 프로젝트들이 업계의 인정을 많이 받으며, 좋아진 편이다.)
결국엔, 죽어나는건 개발자다.
표준과 비표준이라는 모든 것에서 최적(!)의 개발 방법과 기법들을 공부하고 익혀야 하기
때문이다. 재밌는 것은 어느 것 한쪽에만 치우쳐 있으면 개발성향을 의심받는다.
두 가지를 다 할 줄 알아야 그나마 "오~ " 한마디 외쳐준다.
나 자신부터도 이러한 생활속에 도퇴되지 않기 위해 발버퉁 쳐야만 했다.
가까운 몇년여를 돌이켜 봤을 때, 이러한 발버둥에서 나름 얻은 지식과 경험으로는 충족함
이 있었지만, 투자한 시간에 비해서는 그다지 만족스러운 결과라고는 생각하기 힘든 듯하다.
한가지 주목해야 할 부분은 ...
현실 개발자들이 좋게만 생각하는 비표준적인 것들은 호응을 하던 개발자들이 일순간
등을 돌리는 순간, 아무리 좋았던 아성(!)도 한순간에 무너질 수 있슴과
그렇게 욕을 먹고 하는 표준적인 요소도 시간의 흐름속에 사라지기 보다는 보안을 거쳐
성장해 가는 가능성이 많다는 것이다.
왜 이런 현상이 일어나는가에 대한 의구심과 고민속에 지난 해 나는 IBM이라는 회사로
옮기게 되었다. 이유는 위의 결과를 찾기 위한 중요한 요소로...
표준을 이끄는 힘은 IT를 이끄는 주요 벤더에 의해서 주도 되기 때문이란 사실 때문이다.
IBM을 옮기기 직전까지 가장 아꼈던 Spring 이란 녀석도 IBM의 정책상 걸림돌이나 도움이
된다고 생각한다면, Interface24 회사를 사버리는 것은 그다지 어려운 일이 아닐 수 있다란
결론에 도달했기 때문이다.
그래서 이러한 생각을 해보게 된다.
현 흐름에 치우쳐 무엇이 좋다더라는 것에.. 이끌려 모든 것을 투자하려 할 때는 ...
몇번이고 되집어 보기를 ... 그리고 좀 더 넓은 시각에서 볼 수 있는 눈부터 가지를 ...
그 눈을 통해 몸소 비교할 수 있는 경험을 쌓기를 ...
그리고 나서 정열을 바칠 수 있는 것에 시간을 할애하기를 ...
...
...
...
하지만, 나는 아직도 양쪽을 저울질하며 시간을 낭비중에 있다.. ㅡㅡ;;
