커피명인이라는 분들의 얘기를 들어보면 전혀 과학적이지 않거나 각종 미사여구로 커피에 대해 지나치게 포장하는 경우가 있습니다. 사실 과학적으로 분석하고 수치화하는 사람의 입장에서 이런 근거 없는 얘기를 남발하는 커피 전문가는 신뢰 하기 힘듭니다.

예전에 제가 아는 분은 스파르타식 커피 아카데미를 운영하는 모 커피 전문가를 사기꾼이라 비판했고, 특히 드립할때 거품이 올라오는걸 보고 몸에 나쁜 “탄소”가 배출되는 과정이라고 얘기하는 경우가 있는데 이를 전혀 근거 없는 얘기라며 신랄하게 비판하기도 했습니다.

이번 커피명가 안명규 대표의 강의도 사실 조금 걱정이 앞섰습니다. 혹시 근거 없는 미사여구만 남발하진 않을까. 바쁜 월요일, 업무가 채 끝나기도 전에 이른 저녁 모임에 참석하기란 결코 쉬운 일이 아니었습니다. 하지만 맛있는 커피에 대한 궁금증을 참기란 더욱 힘들었습니다.

그렇게 강연에 참석하게 됐습니다.

생각보다 강의 공간이 너무 비좁고 협소해서 당황했습니다. 마침 한 여름에 자전거를 타고 갔던 터라 행여나 실례 되지 않을까 조심스러웠습니다.

참석한 사람은 열 명 남짓.

좀 더 많은 분들에게 기회가 가지 못해 아쉽지만 덕분에 훨씬 더 밀도 있게 강의를 들을 수 있었습니다.

인상 깊었던 부분은 원산지에 대한 강조입니다.

좋은 커피를 위해 산지를 직접 찾아다니고 농장과 계약해 좋은 생두를 직접 공급받는다는 얘기는 매우 인상적이었습니다.

커피자루라고 하나요.

오른쪽 저 마대에는 상단에 큼지막하게 “커피명가”라는 한글이 적혀 있습니다. 농장에 직접 생두를 발주하고 저 자루를 이용해 실어온다는 얘기입니다.

또한 그 동안의 커피 운송은 단순히 컨테이너 박스 안에서 한 달간 고온다습한 환경에 노출되어 변질되는 경우가 많았는데 최초로 냉장 운송을 도입해 생두 품질을 유지했다는 얘기를 들려주셨습니다.

그만큼 원산지와 커피 생두의 품질에 대해 강조하셨습니다. 물론 좋은 커피란 생두 뿐만 아니라 배전, 추출이 모두 함께 어우러져야 하지만 특히 생두가 가장 중요하고 심지어 좋은 생두가 90% 이상을 차지한다는 마지막 슬라이드가 인상적이었습니다.

중간중간 시음용으로 몇 잔씩 건네주셨지만 이 날의 백미는 뭐니뭐니해도 최고의 커피를 맛보게 해주겠다며 직접 내려주시는 커피였습니다.

융드립으로 최고 품질의 원두를 내려서 맛보게 해주셨는데 지금까지 경험하지 못했던 매우 풍부한 맛이었습니다.

말로 표현하기 힘든 천상의 맛.

이런 얘기만으로 매듭지으면 저 또한 앞서 얘기한 신뢰하기 힘든 사람이 되는 셈이니 이를 좀 더 구체적이고 정량화해서 표현하자면.

시큼하면서도 씁쓸한, 텁텁하면서도 깔끔한, 그리고 달콤한. 마치 오미자차를 연상케 하는 온갖 풍부한 맛과 향미가 입안을 감돌았습니다.

그러고 보면 비싼 커피는 항상 이렇게 풍부한 맛이 났습니다. 조금 더 비싼 예멘 마타리가 그랬고 그 보다 조금 더 비싼 블루 마운틴이 그랬습니다. 이번 안명규 대표의 커피는 예전에 먹었던 블루 마운틴 보다도 훨씬 더 깊고 풍부한 맛이 느껴졌습니다.

앞서 얘기한 걱정을 떨쳐내고 두 시간 동안 얘길 들어보길 잘한 순간이었습니다. 역시 커피명인의 커피는 무척 맛있었습니다. 아마도 맛있는 커피의 여운은 오래도록 기억에 남을 것 같습니다.

매우 유익한 시간이었습니다. 좋은 말씀해주신 안명규 대표님께 감사 드리며 이 자리를 빌어 좋은 자리를 마련해준 닐모리동동 관계자 분들께도 깊은 감사 말씀 드립니다.

소프트웨어를 개발하는데 있어 가장 잦은 그리고 가장 난처한 질문이 “언제 끝나요?”라는 질문이다.

한 마디로 대답하자면 “알 수 없다”.

요구사항은 언제나 변화무쌍하고 정확하게 동작할 것 같았던 프로그램은 실제로 돌려보면 오류 투성이다. 막바지에는 보이지 않던 각종 버그가 눈에 띈다. 이 버그를 수정하는데 얼마나 더 걸릴지는 또 알 수 없는 일이다.

정확하게 예측하고 시간을 엄수하며 한 번에 깔끔하게 종료되는 프로젝트란 있을 수 없다.

서울 – 부산

우리가 서울에서 부산까지 고속도로로 차를 몰고 가본다고 가정해보자. 5시간 안에 도착할 수 있을확률은 얼마나 될까. 서울과 부산간 거리는 400km 남짓하니 평균속도 80km/h 정도면 충분히 도달할 수 있다. 맑은 날 고속도로에 아무 문제가 없다면 5시간 안에 도착할 확률은 99% 이상이 될 것이다.

하지만 비가 오거나 안개가 심하게 낄 확률은?
차가 막혀서 시간을 허비할 확률은?
갑자기 차가 고장 나거나 교통사고가 날 확률은?

이 같은 각종 외부 요인이 발생하면 5시간 안에 도착할 확률은 훨씬 더 낮아질 것이고 우리는 이를 불확실성이라 부른다.

불확실성

개발 업무는 이 같은 불확실성이 매우 높다. 외부 요인이 고속도로의 그 것과는 비교조차 되지 않을 정도로 높다. 불확실성은 “판단이나 의사결정에 필요한 적절한 정보의 부족“이라고도 할 수 있는데 프로젝트 일정을 보다 정확하게 예측하려면 이 같은 불확실성을 면밀히 파악하고 확실한 정보로 개선할 수 있어야 한다.

Rapid Development

그래서 수많은 프로젝트 일정 관리 기법이 책, 논문 형태로 소개되었고 그 중 내가 본 가장 감명깊은 책은 스티브 맥코넬의 Rapid Development다. 번역서 제목은 “프로젝트 쾌속 개발 전략”으로 기억한다.

책 기저에 흐르는 핵심 문장은 아래와 같다.

위험 요소를 빠르게 제거하라

일정 산정이 어려울 경우 과감하게 그 기능을 포기하면서 위험 요소를 최소화 하라는 얘기다.

멀리 볼 것 없이 윈도우만 봐도 그렇다.

원래 윈도우 비스타에는 WinFS(Windows Future Storage)라는 관계형 데이타베이스 기반의 파일 시스템이 도입될 예정이었으나 출시를 1년이나 남긴 시점에서 이 기능은 과감히 제외됐다. 핵심기능이라며 마켓팅을 진행했음에도 무리하게 개발을 진행해 문제가 생기는 것 보다 위험 요소를 빠르게 제거하는 쪽을 택한 것이다.

다시 불확실성

그렇다면 불확실성을 판단하려면 어떤 일이 필요할까.

  1. 프로토타입
  2. 테스트
  3. 코드 리뷰
  4. 실제 환경 테스트

앞서 서울 – 부산을 5시간 안에 도착할 수 있을지 판단하는 가장 확실한 방법은 미리 직접 가보는 것이다. 소프트웨어 개발 또한 마찬가지다. 프로토타입을 통해 미리 진행해보는 것이 가장 좋은 접근 방법이며 다행히 소프트웨어 개발은 고속도로를 달리는 것보다 훨씬 더 빠르고 유연하게 대처할 수 있다. 이 같은 장점을 살려 가능한 많은 프로토타입을 진행해보고 조금이라도 의심스러운 부분은 제거해 나간다.

사실 테스트는 매우 어렵다. 특히 4번 처럼 실제 환경과 가까운 테스트는 더욱 어렵다. 아무리 좋은 테스트라도 실제 환경에선 또 다른 결과를 낼 수 있다. 테스트를 갖추는데 개발하는 것보다 훨씬 더 오랜 시간이 걸릴지도 모른다.

하지만 테스트는 무엇보다 중요하다. TDD(Test-driven Development)에서는 아예 테스트부터 만들기를 권장한다. 프로토타입과 마찬가지로 가급적 많은 테스트를 만들어보고 외부 요인의 위험 요소를 파악하는데 집중한다.

코드 리뷰는 코드 품질을 높이는데 필수적이다. 코드 리뷰 할 시간이 있으면 일정내 마감하라는 압박이 있겠지만 코드에 좋은 냄새가 나지 않으면 좋은 품질의 소프트웨어가 나올 수 없다. 좋은 코드는 유지보수를 쉽게 하고 앞으로 생산성을 더욱 높인다. 아무리 바쁘더라도 배포(Deployment) 이전에는 반드시 코드 리뷰를 진행해 미래의 불확실성을 제거해야 한다.

또 다시 불확실성

이렇게 해도 불확실성은 여전히 존재하고 일정은 어긋나기 일쑤다.

완벽한 예측이란 이상일 뿐이며 어떠한 예측도 잠재 위험 요소를 모두 찾아낼 수 없다. 여기에는 변화무쌍한 요구사항도 한 몫 거든다. 요구사항이 바뀌면 위험요소는 또 다시 늘어난다.

자, 그렇다면 이런 악순환을 해결할 명쾌한 방법은 없는 것일까.

아무것도 안 하는 것이다. 아무것도 안 하면 아무 문제도 생기지 않는다.

하지만, 독일의 문호 William Shedd 는 이런 명언을 남겼다.

A ship is safe in harbor, but that’s not what ships are for.

배는 항구에 있을때 가장 안전하다. 그러나 그것이 배의 존재 이유는 아니다.

우리 집 바로 앞엔 하귀-애월 해안도로가 있다.

얼마나 멋진지 모른다. 세계 어딜 내놔도 뒤지지 않을 아름다운 곳이다. 평소 이 곳을 자전거로 다니면서 언젠가 이 아름다운 곳을 영상으로 꼭 남겨야지 하고 생각했는데 좀 처럼 기회가 나질 않았다. 스포츠 캠이 있는 것도 아니고.

해외 싸이클링 포럼을 보니 아이폰을 네임택에 넣어서 찍는 사람도 있고 해서 나도 따라 해 봤다. 결론 부터 말하면 실패다. 화각이 너무 좁고 포커스가 맞지 않을뿐더러 자전거의 진동 때문에 어지러울 정도의 영상이 나왔기 때문이다. 아래처럼. 별로 보길 권하진 않는다.

그 다음 시도한 것은 거울에 비친 모습이라도 찍어보자고 해서 반사경이 나올때마다 열심히 핸드폰을 들이댔다. 이 조차도 실패다. 마찬가지로 화각이 좁고 포커스가 맞지 않아 제대로 내 모습이 보인게 몇 안되기 때문이다. 아래 반사경에 내 모습이 비친게 몇 되는지 찾아보면 정말 비참할 정도다. 힘들게 찍었는데.

그나마 직접 핸드폰을 들고 찍은 모습과 중간에 쉼터에서 천천히 찍은 모습등을 편집하니 제법 쓸만한 영상은 만들어졌지만. 해안도로와 자전거의 멋진 모습을 표현하겠다는 본연의 역할에는 훨씬 못 미친다. 아무래도 GoPro와 같은 전문 스포츠 캠이 있어야 할 듯하다.

그렇게 지름신은 우리 곁으로 다가온다.

DW에는 기술에 대한 매우 디테일한 튜토리얼이나 기술문서가 올라오지만 이렇게 기술에서 다소 한 발짝 떨어진 설계에 관한 좋은 문서도 올라온다.

Evolutionary architecture and emergent design 시리즈는 전체 15편까지 찾을 수 있고 아쉽게도 전체가 한글 번역본이 나와 있는 것은 아니지만 중간 중간 번역본을 볼 수 있으며 소프트웨어 아키텍처를 설계하는데 있어 매우 유용한 고급 정보를 얻을 수 있다.

단순히 말로 하는 설계 뿐만 아니라 중간 중간 구현사례(Java 코드로)까지 제시하며 실무에 도움이 되는 내용이 많다. 특히 TDD 패턴을 직접 코드로 구현한 부분은 반드시 읽어볼 필요가 있다.

이번 아티클에는 “미지의 창발적 설계”라는 주제로 모르는 것을 설계하는 능력, 설계의 범위, 선행 설계를 얼마나 수행해야 할 것인가에 대해 자세히 알아본다.

2009년 부터 시작한 이 시리즈는 앞으로도 계속 진행될 예정이라고 한다.

* 이 글은 IBM developerWorks 후원으로 작성한 글입니다.

모피아(Morphia)는 자바로 MongoDB를 이용하는데 있어 선택이 아닌 필수다. MongoDB의 JSON을 자바 오브젝트(POJO)로 맵핑 하려면 꽤나 번거로운 파싱, 맵핑 작업이 필요한데 모피아는 이를 자동으로 처리해 준다. 우리도 MongoDB를 실서비스에 녹여내는데 있어 모피아에 많은 도움을 받았다.

그 구조 또한 매우 단순하여 복잡한 프레임워크를 학습하느라 지친 개발자들에게 새로운 대안으로 떠오르고 있다. 이번 DW 아티클에서는 도메인 모델을 정의하고 이를 모피아와 MongoDB로 얼마나 쉽게 구현할 수 있는지에 대해 알아본다.

* 이 글은 IBM developerWorks 후원으로 작성한 글입니다.

소개

Working Smart: Getting Better at Work and Life

likejazz@daum.net

검색

메뉴

소개
글 목록 보기
KML/KMZ + Daum 지도
Mac OS X 유틸리티 및 설정
TechNotes

Facebook Activity

피드

  25,940 readers

라이센스

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.0 Korea License.

 

« 최근 글오래된 글 »