'전체 글'에 해당되는 글 1246건

구글 크롬을 한창 사용 중인데, IE의 고유 기능을 사용할 때 별 수 없이 IE를 꺼내게 된다.

하지만, 점점 Task bar에 달린 응용 프로그램의 종류가 많아져서

이제는 더 이상 추가하기도 그렇고, 자꾸 IE와 Chrome을 혼재해서 쓰니까,

사용면에 있어 점점 활용도가 엇갈리며 떨어져 갔다.

이에 단행!. IE를 Task Bar에서 없애고, 대신 Chrome을 사용하는 방법을 모색 중에,

Google Chrome 4.0 이상에서는 IE 플러그인을 제공한다는 사실을 알게 되었다.

그러나, 다른 한국어 사이트들에서 제공하는 내용은 대부분,

과거 3.0 시절의 패치 방법이나, 좀 Hack 스럽게 하거나,

아니면 별도의 다른 프로그램의 힘을 빌어 처리하는 방법이였다.

공식인지는 모르겠지만, 일단 크롬 플러그인들을 제공하는 사이트에서 제공하는 방법으로

아래의 링크에서 플러그인을 다운로드 받아 설치하면 된다.

http://www.chromeextensions.org/utilities/ie-tab/

사용방법은 원하는 URL로 이동한 후에, URL 바 옆쪽에 있는 IE 아이콘을 누르기만 하면 된다.

많다고 하면 많고, 조금이라고 생각하면 조금이겠지만,

최소한 나름대로 다양한 사이트를 경험해왔다고 생각은 한다.

다양한 사이트를 다니면서 이런 저런 것들을 만들고 구성하면서 드는 최후의 생각은 바로 이것이였다.

“ 고객은 적이다!!!! “

하지만, 일을 하면서 돈을 주는 건 애석하게도 고객이기 때문에, 언제나 프로그래머들은 “적과의 동침"(?)을 계속 해올 수 밖에 없었다.

이 때, PM혹은 PL 또는 프로그래머들은 일정과 요구사항에 맞추어 고객을 무시하고 진행할 수 있다. 제시간에 프로젝트를 종료하고, 모든 프로그래머들은 행복하고, 편한 사이트라고 평할 수 있는 그런 진행말이다. 그러나, 우리나라에서 그런 짓을 하다가는 십중 팔구 프로젝트 실패나 고객의 불신 포인트 쌓기에 심하면 차기 프로젝트에 있어서 지명 제외 사태까지 벌어진다. 더욱이 고객이 네트워크 까지 넓다면 다른 사이트 들어가기는 물 건너 간셈.

그렇다면 고육지책이지만, 프로그래머를 쥐어 짜면? 무리한 요구사항들이든 뭐든 받아들이고 진행하면? 물론 프로젝트 검수 완료 될 때( 대개 프로젝트의 사이즈에 따라 다르겠지만, 1~2 주일, 혹은 한달, 심하면 1년? 지연이 되는 것은 어쩔 수 없을 듯… ) 고객의 극찬과 맛난 음식이 기다리겠지만, 그 전에 프로그래머들의 건강은 피폐해지고, 직업병에 대한 심각한 우울의 나락을 왔다 갔다 하고 자신의 신세한탄의 홍수에 오락가락 할 것은 뻔하다. 그리고 이직하고 이직하고…

이게 현실이다!!!! 라고 말하기에는 무언가 이상하다고 생각된다.

사실 고객이라고 해봐야, 그들도 결국 다른 이들을 고객으로 삼고있는 또 다른 형태의 서비스 제공자일 뿐이다. 그들도 이 소프트웨어 바닥의 괴로움 정도는 어느정도 알고 있다고 생각한다. (최소한 초창기 시절 보다는.. ). 이심 전심이지 않을까? 그들도 최소한 서로 Win-Win 하는 방법을 찾고 싶어하고, 그렇게 움직이고 싶어한다. 하지만, 결국 일을 시작하면, 자선사업이 아닌 이상, 결국은 비용과 일정 때문에, 결국 프로그래머들을 쪼고 또 쪼게 되는 악순환을  반복하게 된다.

자… 그럼 무엇이 문제일까?

이 부분에 대한 해답까지는 아니지만, 나름 대로 실타래 끝자락을 바로 이 애자일에서 찾을 수 있었다.

맨 처음 접했던 애자일은 사실 신뢰성 0 였다. 도리어 여타 다른 방법론과 같이 취급되었다. 그전에 직접 체험 보다는 간접 체험한 사람들의 결과 내용들을 보기만 했는데, 이게 과연 방법론 맞아? 라는 의구심만 들게 만들었고, 가장 위험한 방법론이구나, 라는 생각이 들었다. 그리고 몇 년이 흘러, 우연히 찾은 김창준씨의 블로그를 보면서 새롭게 바라보았고, 관련 서적을 이것 저것을 보고 난 뒤, 나의 오해는 거의 다 푼 것 같았다.

자,다시! 그렇다면 문제는 무엇일까?

최소한 내가 바라보는 문제는 바로 고객과 프로그래머 사이를 효율적으로 조율할 무언가의 부재였다. 이 이야기하면, “PM이나 PL이 바로 그런 역할을 하는 거야!” 라고 정중히 충고하시는 분들이 있을 것이다. 그러나 그건 다르다. PM이나 PL은 고객과 프로그래머를 조율하는 것이 아니라, 일정 관리나, 기술 관리 등을 수행하는 또 다른 조직일 뿐이다. 혹은 설계 부분을 담당하거나, 요구사항을 정리도 하겠지만, 결국 프로그래머 관리하는 관리 조직일 뿐인 것이다. 그렇다면 그 무언가는 무엇인가?

그건 바로 중간 결과물이다.

다시 오해를 벗기 위해 또 다시 이야기를 하겠다. 내가 말하는 중간 결과물은 단순한 문서나 제작중인 코드를 의미하는 것이 아니다. 게다가 솔직히 문서 같은 것은 중간에 고객에게 보여주기 위해서 만들기 보다는 중간에 품질 관리에서 도장을 받기 위한 숙제 같은 것일 뿐, 중간 결과물이 아니다!!!

내가 말하고 싶은 것은 바로 프로토타입 처럼 고객에게 보여줄 수 있는 그런 중간 결과물이다.

터무니 없다고 생각되는가? 그럴 수 있다. 도리어 성급하게 결과물을 보여주면 그간 모아온 요구사항과 완전 역전되는 진행을 낳을 수도 있다. 그러면 기존에 설계된 사항과 완벽히 위반되어 처음 부터 다시하는것 아닌가? 라는 것이다. 맞다. 정말 맞다.

그런데 다시 생각해보자. 왜? 요구사항과 설계가 역전되어 새로 다시 모으고 만들어야 될까?

부끄러워 숨기고 싶겠지만, 바로 그 놈의 요구사항은 고객의 의도와는 전혀 다르게 수집하고,

고객이 원하는 모습과는 전혀 다른 모습으로 설계하고 있었던 것 아닌가?

여기에 유명한 그림이 있다. (http://onestone.tistory.com/entry/user-requirements)

왜 요구사항의 환상이라고 했을까? 환상? 아니다.

고객의 의도와 개발자의 한계 상의 조율이 전혀 안된 것 뿐이라는 것이다.

일단, 고객에게 가장 중요한 것이 무엇인지 물어봐서, 최대 2주 내로 구현 가능한 모델을 만드는 것이다. 그리고 시연하고 보여준다. 다시 이야기한다. 다시 여기서 살을 붙이고 뼈를 잇는다. 여기서 중요한 것은 무조건 고객에게 모든 것을 다 주는 것은 아니다. 고객도 희생이 필요하다. 당신들이 원하는 것은 이정도 크기의 프로젝트다! 그러면 모든 것을 들어주는데는 10년이 걸리고 10억이 필요하다! 그렇게 하고 싶지 않으면 어떻게 할까? 이제 고객의 욕심을 줄이는 시점이 오는 것이다. 이건 있으면 좋겠지만, 꼭 필요한 것이 아니면 없앨 수 있는 계기를 만들어주는 작업을 하는 것이다. 비용과 기간을 고객의 요구사항과 저울질을 하는 것이다. 그리고 여과 없이 보여준다.

이게 바로 핵심이지 않을까 싶다.

이를 위해서는 라이트한 조직으로 기존과는 전혀 다른 진행, 관리 방식이 요구된다.

이 부분에서 애자일에서는 다양한 방법들을 마치 방법론 처럼 보여줄 뿐이다.

우리나라의 소프트웨어 개발 환경에서는(애석하게도 외국의 다양한 사이트에서는 이미 많은 성공 사례들이 발표되고 있고, 큰 개발 조직 같은 경우에서도 시도하고 있으며 이미 발전 단계에 이르렀다) 마치 환상 같아 보이기만 하지만, 이런 환경을 구성하여 진행하는 곳에 꼭 참여해보고 싶다.

당분간은 이런 환경 접하기는 어려워 보이고, 스스로 만들 용기나, 힘도 부족하니 당분간은 책을 통해서 생각이나 정리하면서 지식 DDR나 하면서 공상이나 해야 겠다.

.NET 2.0 시절 부터 웹 프로그램을 시작하는 바람에,

ASP.NET 2.0에서 제공하는 MVC 분리 작업에 놀라면서 다양한 방법으로 사용했다.

사실 이 부분에 있어 대부분의 View와 연결하는 작업이 숨겨져서 구현된 부분이 많아

그 내용을 조사하는데 많은 시간을 할애한것도 사실이지만,

최소한 전체적으로 바라 볼때, 상당히 매력적인 것은 사실이였다.

그러다가, 요즘 Java  쪽으로 넘어와서 보는데,

왠걸… 이거 구석기 시대의 웹프로그래밍이 아닌가…

일단 servlet. 이건 Http 처리를 위한 최하단 프로그래밍이였고,

JSP는 옛날 유행했던 HTML 코드와 프로그램 코드가 엉겨서 어쩔 줄 모르게 만드는
(이 부분이 내가 과거 웹프로그래밍을 기피하게 된 원인 1순위) 형태였다.

이미 시작한 것 끝까지 가자는 마음에 하나씩 구현하다가,

우연히 JSP Tag 라는 것을 들었다. 그러다가… 아하.. 라는 생각을.

바로 이 JSP Tag라는 것이 지금까지 내가 해왔던 ASP.NET 2.0의 형태였다.

단지 틀린 것은 ASP.NET 2.0에서는 대부분 MS에서 구현하여 숨긴 내용을

여과없이 보여주면서, 원하는대로 만들라고 하는 것 뿐이였다.

아직은 JSP tag 손대기는 시간상이나, 지식상으로 딸리기 때문에, 일단 당분간은
JSP 구현을 계속 할 예정이다. ( 의외로 많이 익숙해져 버렸다. )

게다가 바로 이 Servlet은 AJAX.NET을 위한 데이터 I/F 구현에 있어서는

최강의 모습을 보여주니 더욱더 매력적이지 않을 수 없다.

나중에 시간이 되면 JSP tag 쪽 공부도 할 예정이다.