어쩌다 보니 이번 달은 자바스크립트 강좌만 소개하는데 이번에도 역시 자바스크립트 이야기다.
그 중에서도 지난 번과 같이 jQuery에 대한 얘기다.
특히 요즘 가장 주목받고 있는 모바일 분야인데 최근 jQuery에서 선보인 jQuery Mobile을 이용한 튜토리얼을 소개한다.
jQuery Mobile을 이용하면 손쉽게 Web app을 만들 수 있으며 게다가 Native app과 비슷한 심도를 구현할 수 있다. 아이폰 뿐만 아니라 안드로이드 심지어 삼성의 바다까지 다양한 플랫폼을 지원해 플랫폼에 개의치 않고 심도 깊은 Web app을 만들 수 있다.
jQuery Mobile을 이용해 모바일 Web app 개발에 직접 도전해보시길. jQuery의 성능과 기능에 매우 만족해 할 것이다.
* 이 글은 IBM developerWorks 후원으로 작성한 글입니다.
John Resig의 jQuery는 이제 하나의 단순한 자바스크립트 라이브러리 수준을 넘어 사실상 표준(de facto) 자바스크립트 라이브러리의 위치에 올라섰다.
코어(Core)뿐만 아니라 jQuery UI를 별도로 제공하고 또한 다양한 플러그인을 직접 삽입할 수 있도록 지원하는데, 이를 이용하면 UI에 미숙한 시스템 개발자들이 손 쉽게 미려한 룩앤필을 구현할 수 있다.
뿐만 아니라 GUI 디자인에 걸리는 시간을 최소화하면서 다양한 템플릿을 적용할 수 있고 궁극적으로 전체 웹 개발 속도를 높일 수 있다.
몇 가지 간단한 셋팅과 복잡한 CSS 설정 없이도 위와 같은 룩앤필을 지닌 다양한 테마를 손쉽게 구성할 수 있는데 아래 DW 아티클에서 어떻게 적용할 수 있는지에 대해 자세히 알아본다.
정말 쉽게 적용할 수 있다.
무슨 얘긴가 한참을 살펴봤다.
PHP가 데이터를 불러오는데 Javascript에 무슨 데이터 레이어를 또 따로 둔다는 것인지. 한참을 보다보니 JSON으로 결과값을 받아온다. 모든 결과값을 JSON으로 받게끔 되어 있다.
흡사 MongoDB에서 JSON을 꺼내오듯, FriendFeed에서 MySQL을 JSON 전용 DB로 활용하듯 PHP에서 결과를 json_encode하고 Javascript로 만든 레이어가 이를 호출하는 방식이다.
결과가 재밌다. 아이디어도 좋다. 이런 건 당장 서비스에 실제로 적용해 봄직하다.
* 이 글은 IBM developerWorks 후원으로 작성한 글입니다.
커피명인이라는 분들의 얘기를 들어보면 전혀 과학적이지 않거나 각종 미사여구로 커피에 대해 지나치게 포장하는 경우가 있습니다. 사실 과학적으로 분석하고 수치화하는 사람의 입장에서 이런 근거 없는 얘기를 남발하는 커피 전문가는 신뢰 하기 힘듭니다.
예전에 제가 아는 분은 스파르타식 커피 아카데미를 운영하는 모 커피 전문가를 사기꾼이라 비판했고, 특히 드립할때 거품이 올라오는걸 보고 몸에 나쁜 “탄소”가 배출되는 과정이라고 얘기하는 경우가 있는데 이를 전혀 근거 없는 얘기라며 신랄하게 비판하기도 했습니다.
이번 커피명가 안명규 대표의 강의도 사실 조금 걱정이 앞섰습니다. 혹시 근거 없는 미사여구만 남발하진 않을까. 바쁜 월요일, 업무가 채 끝나기도 전에 이른 저녁 모임에 참석하기란 결코 쉬운 일이 아니었습니다. 하지만 맛있는 커피에 대한 궁금증을 참기란 더욱 힘들었습니다.
그렇게 강연에 참석하게 됐습니다.
생각보다 강의 공간이 너무 비좁고 협소해서 당황했습니다. 마침 한 여름에 자전거를 타고 갔던 터라 행여나 실례 되지 않을까 조심스러웠습니다.
참석한 사람은 열 명 남짓.
좀 더 많은 분들에게 기회가 가지 못해 아쉽지만 덕분에 훨씬 더 밀도 있게 강의를 들을 수 있었습니다.
인상 깊었던 부분은 원산지에 대한 강조입니다.
좋은 커피를 위해 산지를 직접 찾아다니고 농장과 계약해 좋은 생두를 직접 공급받는다는 얘기는 매우 인상적이었습니다.
커피자루라고 하나요.
오른쪽 저 마대에는 상단에 큼지막하게 “커피명가”라는 한글이 적혀 있습니다. 농장에 직접 생두를 발주하고 저 자루를 이용해 실어온다는 얘기입니다.
또한 그 동안의 커피 운송은 단순히 컨테이너 박스 안에서 한 달간 고온다습한 환경에 노출되어 변질되는 경우가 많았는데 최초로 냉장 운송을 도입해 생두 품질을 유지했다는 얘기를 들려주셨습니다.
그만큼 원산지와 커피 생두의 품질에 대해 강조하셨습니다. 물론 좋은 커피란 생두 뿐만 아니라 배전, 추출이 모두 함께 어우러져야 하지만 특히 생두가 가장 중요하고 심지어 좋은 생두가 90% 이상을 차지한다는 마지막 슬라이드가 인상적이었습니다.
중간중간 시음용으로 몇 잔씩 건네주셨지만 이 날의 백미는 뭐니뭐니해도 최고의 커피를 맛보게 해주겠다며 직접 내려주시는 커피였습니다.
융드립으로 최고 품질의 원두를 내려서 맛보게 해주셨는데 지금까지 경험하지 못했던 매우 풍부한 맛이었습니다.
말로 표현하기 힘든 천상의 맛.
이런 얘기만으로 매듭지으면 저 또한 앞서 얘기한 신뢰하기 힘든 사람이 되는 셈이니 이를 좀 더 구체적이고 정량화해서 표현하자면.
시큼하면서도 씁쓸한, 텁텁하면서도 깔끔한, 그리고 달콤한. 마치 오미자차를 연상케 하는 온갖 풍부한 맛과 향미가 입안을 감돌았습니다.
그러고 보면 비싼 커피는 항상 이렇게 풍부한 맛이 났습니다. 조금 더 비싼 예멘 마타리가 그랬고 그 보다 조금 더 비싼 블루 마운틴이 그랬습니다. 이번 안명규 대표의 커피는 예전에 먹었던 블루 마운틴 보다도 훨씬 더 깊고 풍부한 맛이 느껴졌습니다.
앞서 얘기한 걱정을 떨쳐내고 두 시간 동안 얘길 들어보길 잘한 순간이었습니다. 역시 커피명인의 커피는 무척 맛있었습니다. 아마도 맛있는 커피의 여운은 오래도록 기억에 남을 것 같습니다.
매우 유익한 시간이었습니다. 좋은 말씀해주신 안명규 대표님께 감사 드리며 이 자리를 빌어 좋은 자리를 마련해준 닐모리동동 관계자 분들께도 깊은 감사 말씀 드립니다.
소프트웨어를 개발하는데 있어 가장 잦은 그리고 가장 난처한 질문이 “언제 끝나요?”라는 질문이다.
한 마디로 대답하자면 “알 수 없다”.
요구사항은 언제나 변화무쌍하고 정확하게 동작할 것 같았던 프로그램은 실제로 돌려보면 오류 투성이다. 막바지에는 보이지 않던 각종 버그가 눈에 띈다. 이 버그를 수정하는데 얼마나 더 걸릴지는 또 알 수 없는 일이다.
정확하게 예측하고 시간을 엄수하며 한 번에 깔끔하게 종료되는 프로젝트란 있을 수 없다.
우리가 서울에서 부산까지 고속도로로 차를 몰고 가본다고 가정해보자. 5시간 안에 도착할 수 있을확률은 얼마나 될까. 서울과 부산간 거리는 400km 남짓하니 평균속도 80km/h 정도면 충분히 도달할 수 있다. 맑은 날 고속도로에 아무 문제가 없다면 5시간 안에 도착할 확률은 99% 이상이 될 것이다.
하지만 비가 오거나 안개가 심하게 낄 확률은?
차가 막혀서 시간을 허비할 확률은?
갑자기 차가 고장 나거나 교통사고가 날 확률은?
이 같은 각종 외부 요인이 발생하면 5시간 안에 도착할 확률은 훨씬 더 낮아질 것이고 우리는 이를 불확실성이라 부른다.
개발 업무는 이 같은 불확실성이 매우 높다. 외부 요인이 고속도로의 그 것과는 비교조차 되지 않을 정도로 높다. 불확실성은 “판단이나 의사결정에 필요한 적절한 정보의 부족“이라고도 할 수 있는데 프로젝트 일정을 보다 정확하게 예측하려면 이 같은 불확실성을 면밀히 파악하고 확실한 정보로 개선할 수 있어야 한다.
그래서 수많은 프로젝트 일정 관리 기법이 책, 논문 형태로 소개되었고 그 중 내가 본 가장 감명깊은 책은 스티브 맥코넬의 Rapid Development다. 번역서 제목은 “프로젝트 쾌속 개발 전략”으로 기억한다.
책 기저에 흐르는 핵심 문장은 아래와 같다.
“위험 요소를 빠르게 제거하라”
일정 산정이 어려울 경우 과감하게 그 기능을 포기하면서 위험 요소를 최소화 하라는 얘기다.
멀리 볼 것 없이 윈도우만 봐도 그렇다.
원래 윈도우 비스타에는 WinFS(Windows Future Storage)라는 관계형 데이타베이스 기반의 파일 시스템이 도입될 예정이었으나 출시를 1년이나 남긴 시점에서 이 기능은 과감히 제외됐다. 핵심기능이라며 마켓팅을 진행했음에도 무리하게 개발을 진행해 문제가 생기는 것 보다 위험 요소를 빠르게 제거하는 쪽을 택한 것이다.
그렇다면 불확실성을 판단하려면 어떤 일이 필요할까.
앞서 서울 – 부산을 5시간 안에 도착할 수 있을지 판단하는 가장 확실한 방법은 미리 직접 가보는 것이다. 소프트웨어 개발 또한 마찬가지다. 프로토타입을 통해 미리 진행해보는 것이 가장 좋은 접근 방법이며 다행히 소프트웨어 개발은 고속도로를 달리는 것보다 훨씬 더 빠르고 유연하게 대처할 수 있다. 이 같은 장점을 살려 가능한 많은 프로토타입을 진행해보고 조금이라도 의심스러운 부분은 제거해 나간다.
사실 테스트는 매우 어렵다. 특히 4번 처럼 실제 환경과 가까운 테스트는 더욱 어렵다. 아무리 좋은 테스트라도 실제 환경에선 또 다른 결과를 낼 수 있다. 테스트를 갖추는데 개발하는 것보다 훨씬 더 오랜 시간이 걸릴지도 모른다.
하지만 테스트는 무엇보다 중요하다. TDD(Test-driven Development)에서는 아예 테스트부터 만들기를 권장한다. 프로토타입과 마찬가지로 가급적 많은 테스트를 만들어보고 외부 요인의 위험 요소를 파악하는데 집중한다.
코드 리뷰는 코드 품질을 높이는데 필수적이다. 코드 리뷰 할 시간이 있으면 일정내 마감하라는 압박이 있겠지만 코드에 좋은 냄새가 나지 않으면 좋은 품질의 소프트웨어가 나올 수 없다. 좋은 코드는 유지보수를 쉽게 하고 앞으로 생산성을 더욱 높인다. 아무리 바쁘더라도 배포(Deployment) 이전에는 반드시 코드 리뷰를 진행해 미래의 불확실성을 제거해야 한다.
이렇게 해도 불확실성은 여전히 존재하고 일정은 어긋나기 일쑤다.
완벽한 예측이란 이상일 뿐이며 어떠한 예측도 잠재 위험 요소를 모두 찾아낼 수 없다. 여기에는 변화무쌍한 요구사항도 한 몫 거든다. 요구사항이 바뀌면 위험요소는 또 다시 늘어난다.
자, 그렇다면 이런 악순환을 해결할 명쾌한 방법은 없는 것일까.
아무것도 안 하는 것이다. 아무것도 안 하면 아무 문제도 생기지 않는다.
하지만, 독일의 문호 William Shedd 는 이런 명언을 남겼다.
A ship is safe in harbor, but that’s not what ships are for.
배는 항구에 있을때 가장 안전하다. 그러나 그것이 배의 존재 이유는 아니다.
