'기술자료'에 해당되는 글 351건

전문적으로 개발하는 것은 아니고, 어디까지나 취미로 시작했던 작업이다.

기존에 Azuare로 구현했던 내용을 이번에는 Google Apps Engine으로 개발한 것이다.

아마도 단순 접근성으로 따지면 단연 Google Apps Engine인 것 같다.

제일 먼저 높은 점수로 줄 수 있는 부분은 대부분의 비용이 Free 라는 사실이다.

이거 때문에, Azure에서 이 Google Apps Engine을 선택한 주요한 원인이니까,

상당한 매리트였다.

그리고 Java 지원. 사실 지금 그나마 다룰 줄 언어는 C/C++, C#, Java 뿐이니, Python이라든가, Peal 이렇게 나왔으면 아마도 GG였을 것 같다. Google Apps Engine 초창기는 Python 이라고 했는데, 그 당시의 생각만 했다면 접근 불가였을 것이다. 그런 시스템이 지금은 Java를 훌륭하게 지원한다.

다음은 시작하기 가뿐한 Start up Tutorial 이다. 이것 따라하기만 하면 금방 개념이라든가

처리하는 방법을 배울 수 있었다. 훌륭한 내용이지 않을까 싶다.

그러나, 이런 훌륭한 접근성에 비해 마음에 안드는 부분이 있기는 했다.

제일 먼저 Back 단에서 처리하는 작업을 하기 위한 일종의 Service 개념이 없었다.

지금까지 찾아서 확인한 것 까지 본다면, JSP 페이지와 같은 I/F를 통해 Request/Response 기반의

작업 뿐인 것 같다. 물론 cron 이나, queue와 같은 것들을 활용하여,

각 Request를 마치 Service 처럼 구성하면 될지는 모르겠지만…

처음에 아무 생각없이 Azure에서 구현한 방식대로 구현한 뒤, 내 PC에서 돌릴 때는 문제가 없었다가,

이번에 처음으로 Google Apps Engine에 올려보니, 역시 Request Time out 이 발생하였다.

아마도 Request가 들어오게 되면 처리하는 내용이 많다보니, Response까지 나오는 시간이

의외로 많이 걸리게 되었는데, 바로 걸려 버리는 문제가 발생했다.

일단, 소정의 목적만 달성하고, 현재는 재설계 계획 중이다.

Response가 빠르게 할 수 있도록 Job을 Page 단위로 분해하여 재조립을 해야 할 필요가 느껴졌다.

여튼 현재로는 Back 단에서 서비스 처럼 동작하는 부분이 없다는 약점만은 어떻게든 보완할 필요가 있다.
( 최소한 Azure에는 Worker 라는 개념이 있고, Amazone 에서는 Enterprise 서비스를 활용하면 그 안에서 처리할 방법이 있는 것 같다. )

Java로 웹 서비스 같은 것을 개발할 계획이라면, 한번 활용해 보는 것도 나쁘지 않을 것 같다!!

http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/

/etc/network/interfaces라는 파일을 vi 에디터 등을 통해 연다.

그리고 해당하는 ethernet 카드 dev 명에 해당하는 부분에 적당하게 내용을 채운다.

iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
gateway 192.168.1.254

만일 DHCP로 변경하려면 아래와 같이 원래대로 변경하면 된다.

auto eth0
iface eth0 inet dhcp

그리고 난뒤, network 서비스를 재시작 하거나, ifdown eth0, ifup eth0 같은 네트워크 카드 일시적으로 내렸다 올리는 명령어를 통해 처리해도 된다.

구글 크롬을 한창 사용 중인데, 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 쪽 공부도 할 예정이다.

NAS의 H/W 교체가 있어서, 전체적으로 교체를 시도했다.

(솔직히 NAS 사용에 베어본 PC라는 것도 이상했고, 더욱이 쿼드코어는 오버였다. )

예전 기종을 찾아내 교환을 했고, 전체적으로 큰 사이즈의 데스크탑인지라,

많은 수(?)의 HDD를 연결할 수 있는 메리트도 있었다.

그런데, 설치하고 얼마 되지 않아, DoS(Denial of Service )현상이 발생했다.

처음에는 그냥 리셋하는 정도로 해결했는데, 파일 서버의 역할로써,

복사 중에 다운되는 현상은 조금 참기 힘들었다.

결정적으로 출근 후, 파일 서버 접근을 시도하려는 순간 갑자기 이런 문제가 터지자

당황할 수 밖에 없었다.

퇴근 후, 이 문제를 차근 차근 되집어 본 결과, Console에 다음과 같은 메시지를 보게 되었다.

msk0: watchdog timeout ….

이 문제를 Google에 입력했고 ( http://www.google.com/search?rlz=1C1CHMB_koKR354KR354&sourceid=chrome&ie=UTF-8&q=msk0+watchdog+timeout ) 검색 결과 여러가지 항목들을 찾을 수 있었다.

그 중 FreeNAS 관련 포럼에 내 문제와 Just It 하는 것을 볼 수 있었고, 간단하게 해결할 수 있는 방법이였다.

(http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/195790.html)

이 문제는 아마도 Gigabit의 Big size 패킷 처리에서 발생하는 문제로 생각된다. 근래 나온 칩셋들은 문제가 없지만, 예전 Giga-bit 제품들이 이런 경향이 컸다. FreeNAS 6.4에서 이미 패치되서 해결 되었다고 하나, 이 문제는 7.1 에서도 예전 Giga-bit 네트워크 칩셋 일부에서 동일한 문제가 발생한다.

이 경우 Big-Size 패킷 처리를 커널 옵션 상에서 끄면 된다.

/boot/loader.conf 파일을 열고 아래의 내용을 추가한다.

hw.pci.enable_msi=0
hw.pci.enable_msix=0

uname -a:

( 위의 내용을 /boot/loader.conf 에 추가하려면, Web GUI를 열고 메뉴에 있는 Advanced –> File Editor 에서 처리하면 된다. )

편집한 뒤, 저장 하고, 리붓 해주면 된다.

현재 파일 송/수신 하면서 1시간 정도의 시간을 보낸 지금도 아무런 문제없이 동작하는 것을 보면, 위의 문제였으리라 짐작된다.

계속 상황을 지켜보면서 현재 NAS를 체크하도록 할 예정이다.

그렇다. 설정 화면에서 Ctrl + Tab을 창 전환으로 바꾸면 간단하게 끝나는 일이였다.

지금까지, 왜 무식하게 쓰고만 있었을까 ??

http://jhoony.tistory.com/16