redmine tool – 3rd Iteration

redmine tool – 2nd Iteration 에 이은 세번째. 이틀만에 돌아온 시간입니다.
오늘은 본 프로젝트의 시작에 앞서, 이 프로젝트 진행에 관해서 논했습니다.

  • 해야 하는 다른 프로젝트가 생겼습니다. 그래서, 다르 프로젝트 진행과 본 프로젝트 진행을 어떻게 해야 할지 고민했습니다.
  • 결론은, 일단, 이 redmine tool 프로젝트가 왠만큼 완성될 때까지 지속한다 였습니다.
  • 그래서, 선을 그엇습니다.
  • 3월 세째주, 3월 16일까지 redmine tool 을 어느정도 진행한다로 목표를 삼았습니다.
  • 저희 예측으로는, 그때쯤이면 릴리즈 가능한 모양새가 나올 것 같습니다.
  • 그리고, 그 다음부터는 다른 프로젝트를 진행한다.

일단 여기까지 토론하는데, 시간이 꽤 걸렸습니다. 그래서 오늘은 개발에 시간이 조금 모자랐습니다.
본격, redmine tool 개선에 관해서 논의를 했습니다. 일단, 지난번에 다 채우지 못한 기능을 채우는데 촛점을 맞추기로 했습니다. 오늘은 하지 못하지만, 좋은 제안도 나왔습니다.

  • 새로운 이슈를 생성하는 창 만들기
  • 이슈간 선/후 관계, 부모/자식 관계를 비주얼하게 보여주는 창. 사실 레드마인에서는 복잡한 관계를 형성할 수 있게 해 주지만, 이것을 한눈에 알아볼 수 없기 때문에 쉽게 사용할 수 없는 단점이 있습니다.

일단 위 안은 좋기는 하지만, 만들기 간단하지 않기 때문에, 잠시 접어 두고 아래와 같은 기능 개선에 촛점을 맞추기로 했습니다.

  • webpage 링크
    • 현 이슈 웹페이지
    • 새 이슈 만들기 웹페이지
    • 하위 이슈 만들기 웹페이지
    • 위키 목록 웹페이지
  • 이슈 컨트롤
    • assignee 바꾸기
    • 시작/종료시간 바꾸기
    • 목표버전 바꾸기
    • 추정시간 변경
    • 우선순위 변경
  • 필터
    • 내 이슈 보기
    • 다른 사람 이슈 보기
    • 목표버전별로 보기
  • 이슈목록 5개 해제
  • 시간 추적
    • 타이머 동작/끝
  • 동작 성공 여부 확인
  • 캐시된 내용 다시 불러 오기
  • 마지막 프로젝트/이슈 기억하기
이 중 몇몇은 생각과 달리 API 지원이 없어서 만들 수 없었습니다.
  • 위키 목록 웹페이지
    • 위키의 첫 페이지로 가는 것으로 수정
  • assignee 바꾸기
    • 해당 프로젝트의 등록사용자 목록 불러오기 불가 (1.4 부터 지원)
  • 다른 사람 이슈 보기
    • 해당 프로젝트의 등록사용자 목록 불러오기 불가 (1.4 부터 지원)
그리고 개발 중에 기발한 아이디어도 나왔습니다. 그것은 메뉴바의 타이틀 자체를 이슈 번호로 표시하는 것입니다. 그리고, 이슈 진행 시간도 바로 표시해 주는 것입니다. 아마도 하다보면 계속 좋은 아이디어가 많이 나올 것 같습니다.

이번에는 3시간반 정도 개발할 수 있었습니다.

두번째 보다 훨씬 메뉴가 복잡해 졌습니다. 그래도 기능이 꽤 많이 들어간 듯 합니다.

현재 상태를 볼 수 있을 뿐 아니라, 즉각 변경도 가능합니다.

우선순위도 지정 가능합니다.

목표 버젼도 변경 가능합니다. 위 화면은 약간 버그가 있는 듯 합니다.

시작일과 마감일을 메뉴에서 볼 수 있고, 선택하면, 변경 가능한 창이 나타납니다.

이슈 목록 필터 입니다. 나에게 지정된 이슈와 모든 이슈를 고를 수 있습니다. 여기서 고르면, Issues 목록이 바뀌게 됩니다.

목표 버젼별로도 이슈를 선택할 수 있습니다. 지정된 목표 버젼의 이슈만 선택할 수됩니다.

약간 이제는 우리가 쓸 수도 있겠다는 생각이 들기 시작합니다. 어쩌면 3일투자 (대략 반나절씩) 치고는 꽤 쓸만한 물건인 것 같습니다. 그리고 앞으로 4번 더 한다면 충분히 공개 가능한 버젼이 나올 듯 합니다.
오늘의 애자일 방법론에 대한 회고 입니다.

  • 어느 정도 자리가 잡힌 듯 합니다.
  • git 의 merge 는 역시 어렵습니다. merge 후, 지난 변경이 돌아간 경우가 몇번 있었습니다. 다같이 동시에 비슷한 부분을 작업을 많이 하다보니, 이 부분의 어려움은 어쩔 수 없는 것 같습니다.
다음주를 기대합니다.

redmine tool – 2nd Iteration

redmine tool – 1st Iteration 에 이은 두번째. 일주일 만에 돌아온 시간입니다.
이번 모임에서, 지난주에 이어서 계속 진행하기로 하였습니다. 지난주 5시간의 투자로 우리는

  • Redmine 의 JSON 인터페이스를 통해서, Mac OS X 앱을 만들어서 이용할 수 있다는 사실을 확인하고
  • 메뉴바 애플리케이션(Status Item) 을 만들어서 손쉽게 접근 가능하면 좋겠다는 희망을 가졌고,
  • 간단하게 나마, 기능 구현을 완성하였습니다.
    • 로그인 성공여부 확인하기
    • 프로젝트 목록 가져오기
    • 해당 프로젝트에 속한 이슈 목록 가져오기
    • 해당 이슈 목록의 웹페이지로 이동하기

지난주에 진행한 것은 위와 같습니다. 아직은 우리도 스스로 쓰기엔 부족함이 많습니다. 하지만, 5시간 투자한 것 치고는 꽤 쓸만한 것이 나왔다는 것에 만족하고 있습니다. 오늘 또 5시간을 더 투자하면 어떤 결과가 될지 기대가 되었습니다.
시작에 앞서, 오늘은 무엇을 할까 고민을 하였습니다. 무엇을 더하면 우리가 쓸만한 놈이 될까? 고민을 해 보았습니다. 토론 끝에 두가지 쟁점이 있었습니다. 우리가 지금 해야 할 것은

  • 여러가지 기능을 추가하는 것인가?
  • UI 적인 기둥을 만들어 보는 것인가?

위 두가지 방향성 중, 토의 끝에, 지금 먼저 해 보고 싶은 것은 UI 적인 기둥을 만드는 것이라 생각했습니다. 왜냐면, 기능적인면은 UI 기둥을 만들면, 쉽게 추가가 가능할 것 같다는 생각이 들었기 때문입니다.
그래서, 어떤 사용 시나리오가 좋을까 고민을 하도록 했습니다. 여기서도 두가지 갈래가 나왔습니다.

  • 윈도우를 기반으로 하고, 맨 왼쪽에 프로젝트 목록을 선택하고, 중간에 이슈 목록을 보여주고, 그리고 맨 오른쪽에 해당 이슈의 상세 내용을 보여주는 것입니다.
  • 메뉴바 내의 메뉴에 표기하는 것입니다. 메뉴에서 현재 프로젝트를 선택하고, 현재 이슈를 선택하고 나면, 메뉴 상단에 현재 선택된 이슈의 내용을 간략하게 보여주고, 거기서 바로 이슈의 상태를 변경하는 것입니다.

위 두가지를 가지고 토론을 했습니다.
위도우 기반으로 했을 때에는,

  • 그 장점으로,
    • 향후, 복잡한 기능성을 대폭 담을 수 있고,
    • 어짜피 결국에는 이런 방식을 해야 하기 때문에, 처음부터 이렇게 시각하는 것이 좋지 않을까
    • 여러 프로젝트에 흩어진 여러 이슈들 간을 편리하게 이동할 수 있다.
  • 단점으로는,
    • 어짜피 모든 기능은 웹에서 이미 다 제공하고 있는데, 굳이 동일한 기능을 똑같이 반복해서 만들 필요가 있을까?
    • 개발중 복잡한 화면 속에서 또다시 이 창을 찾기란 매우 힘들지도 모른다.
    • 5시간 내에 어느정도 틀을 만들어 낼 수 있을까?
메뉴바를 기반으로 했을 때에는,
  • 그 장점으로는,
    • 지난번 만든 것에서, 조금 만 더 손보면 되기 때문에, 쉽게 만들어 낼 수 있겠다.
    • Mac OS X 의 Space 기능으로 화면 전환을 해도, 늘 메뉴에 붙어 있기 때문에, 항상 쉽게 접근해서 쓸 수 있을 것이다.
    • 작업의 특성상, 하나의 이슈에 고정되어 있기 때문에, 그 경우 오히려 편리하다.
  • 단점으로는,
    • 한번에 하나 이상의 이슈는 다룰 수 없는 한계가 있고,
    • 사용성이 직관적이지 않아 불편하고,
    • 많은 기능을 담기에는 한계가 있을 것이다.

위 쟁점을 토론한 결과, 일단은 메뉴바로 기반으로 해 보자는 결론을 냈습니다. 보다 쉽게 구현할 수 있다는 점이 크게 어필한 것 같습니다
메뉴바 기반의 UX 를 생각하고, 그림을 그려 봤습니다. 화이트 보드 상에서 간략하게, 구현이 됐을 때, 사용하는 상황을 대충 그려 보았습니다.

화이트 보드에 그린 모습

메뉴 상단에 몇줄의 메뉴를 통해서 “현재 선택된 이슈”에 대한 간략한 정보 ( 이슈 번호, 이슈 제목, 이슈 상태, 진척도 ) 등을 표시하고, 상태와 진척도는 오른쪽 서브메뉴를 통해서 즉각적으로 수정할 수 있도록 한다. 그리고, 그 아래에 Add Comment 메뉴를 통해서, 커멘트도 바로 기록할 수 있도록 한다. 그리고, 그 하단에는 프로젝트 선택의 서브메뉴에서 “현재의 프로젝트”를 선택하고, 이슈 선택의 서브 메뉴에서 “현재의 이슈”를 선택하도록 한다.
썩 직관성 있는 사용방법은 아니지만, 일단 만들어 보기로 했습니다.
지난번에서 추가해야 할 주요 작업으로는

  • 추가 프로토콜 지원
    • 프로젝트 내용 업데이트, 프로젝트 상태 목록 등
  • Comment 입력 UI 만들기
  • 메뉴바 현재 이슈 내용 표시하기
생각보다 쉽게 진행되는 듯 했다. 하지만, 중간에 생각치 못한 난관이 있었습니다.
  • 프로젝트 업데이트 프로토콜이 생각되로 잘 진행되지 않았습니다.
    • 이는 Content-Type 을 application/json 으로 보내주지 않았기 때문이었습니다.
  • 내친김에 이미지 업로드 기능도 넣고 싶었습니다.
    • 현재 Redmine 1.3 버젼에서는 API 가 지원되지 않는 듯 했습니다.
그리고, 5시간 후, 결과를 만들어 낼 수 있었습니다.

프로젝트 목록 보여주기. 이중 하나를 선택하면, 현재 선택된 프로젝트가 된다.

 
이슈 선택하기. 현재 선택된 프로젝트내의 이슈목록을 보여준다. 이중 하나의 이슈를 선택하면, "현재 선택된 이슈"가 된다.

현재 선택된 이슈는 항상 메뉴 최상단에 그 정보가 보여진다. 위 화면은 진척도를 보여주고, 서브메뉴를 통해서 진척도를 변경할 수 있다.

또한, 현재 이슈의 상태를 볼 수 있고, 그 상태를 바로 변경할 수 있다.

Add Comment 메뉴를 선택하면, 새로운 창이 뜨고, 이 창에서 새로운 Comment 를 입력할 수 있다.

또 다른 5시간을 투자해서, 꽤 쓸만한 기능이 많아 진 것 같습니다. 하지만, 아직은 스스로 매일 매일 쓰고 싶은 상태까지는 아닌 듯 합니다. 항상 두가지가 교차하는 것 같습니다. 5시간으로 꽤 많은 일을 할 수 있다는 것과, 일주이에 한번으로는 여전히 많이 부족하다는 점입니다. (이번주부터는 일주일에 두번 하기로 하였습니다.)
오늘의 애자일 방법론에 대한 회고입니다.

  • 오늘은 대화가 조금 부족했습니다. 대화가 부족하다 보니, 긴장감도 조금 떨어지고, 병목 현상이 많았습니다. 서로가 각자의 맡은 부분을 하다보니, 마지막에 가서야 현재의 상황을 알 수 있었습니다. 이것은 우리가 원래 원하던 그림이 아니었습니다. 다같이 서로 이야기 하면서 진행하는 것인데, 하다보니 대화가 없어지고 각자 하는 스타일로 돌아가 버렸습니다.
  • 위에서 말한 병목현상. 한 사람이 무엇을 먼저 해 주기를 기다립니다. 그리고, 그 사람이 끝나기를 기다리는데, 시간이 꽤 걸립니다. 그리고, 이번에는 그 다음걸 할려고 하는데, 미쳐 생각치 못한 것들이 또 나옵니다. 즉각적으로 대화를 문제를 풀지 못했기 때문인 듯 합니다.
하지만, 몇 사이클이 지나면, 분명 우리 스스로에게는 꽤 쓸만한 물건이 될 것은 같습니다.

맥 OSX과 터미널

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 김정님께서 OS X 과 터미널에 대한 글을 기고해 주셨습니다.


터미널(Terminal)이란 단어는 일상 생활 속에서도 익숙한 단어다. 하지만 OS X에서는 누구에게나 편하기만 하지않은 미지(?)의 영역이라고 할 수 있다. 복잡해 보이는 터미널 환경에 대해 이야기해보자.
 
우리가 알고 있듯이 터미널이란 단어의 뜻은 주로 “끝에 있는”, “마지막에 있는” 무언가를 의미한다. 그래서 버스 터미널은 버스 종착역을 의미한다. 그렇다면 OS X의 터미널 앱은 어떤 의미가 있는걸까? 그것은 컴퓨터 역사에서 터미널의 역할을 되짚어 보면 알 수 있다.

초창기 대형 컴퓨터들은 엄청난 크기의 몸집을 갖고 있었다. 그리고 커다란 본체 입력을 하기 위해서, 초창기에는 천공카드 입력기를 사용했지만, 점차 타자기처럼 생긴 작은 기계를 연결해서 사용했었다. 실제로 초창기 터미널들은 그림과 같이 타자기와 같은 모습이었다. (그래서 현재 UNIX/Linux에서 터미널을 의미하는 TTY라는 단어도 TeleTYpewriters 에서 나온 것이다)
 

대형 컴퓨터를 만드는 업체들이 차츰 UNIX 기반 운영체제를 사용하도록 진화해 가면서, 시분할 접속 방식으로 여러 사람이 동시에 접속해서 사용할 수 있게 됐다. 지금도 남아있는 RS-232 같은 시리얼 방식도 터미널에 연결 방식으로 도입되었고, DEC에서는 최초로 ANSI 규격을 준수하는 그림과 같은 VT100 현대적인(?) 터미널이 만들었다. 워낙 컴퓨터 제조사의 터미널 마다 화면에 글씨를 표시하는 방식이 다르기 때문에 ANSI 표준을 정했었다. 그리고 이 당시 대부분의 터미널의 글자색이 녹색이었고 ASCII 문자만 표시할 수 있었기 때문에, 지금까지도 터미널 앱에서 검은색 배경에 녹색 글씨로 쓰는 사람이 많다.

90년대 모뎀으로 접속하는 PC통신을 해본 사람들이라면 이미 터미널 화면에 익숙하다고 할 수 있다. 왜냐하면 당시의 국내 PC 통신 서비스들이 모두 터미널 기반의 접속 서비스였기 때문이다. 하늘소 팀에서 만든 “이야기”가 가장 인기 있던 터미널 에뮬레이션 앱이었다.
시간이 흘러서 개인용 컴퓨터가 발전하면서 대형 컴퓨터에 접속하기 위한 전용 터미널들은 의미가 없어졌다. 대신 PC에서 터미널을 에뮬레이션해서 다른 컴퓨터에 접속하도록 화면과 통신 프로토콜만 맞춰주면 되는 시대가 됐다. 맥 OS9까지는 zterm같은 에뮬레이터 앱은 있었지만 공식적인 터미널 앱은 없었다. 그렇지만 OS X부터 유틸리티 디렉터리에 터미널 앱과 함께 콘솔 앱까지 제공한다. 참고로 콘솔은 터미널과 비슷한 듯하지만 쓰임새는 사뭇 다르다. 터미널은 일반 사용자가 대형 컴퓨터에 입-출력을 하기 위한 것이라면, 콘솔은 대형 컴퓨터를 운영하는 운용자가 시스템을 관리하기 위해 로그을 확인하는 용도인 것이다. (물론 운용 명령어를 알고 있다면 터미널로 접근해서 마치 콘솔처럼 활용할 수 있다)

OS X는 FreeBSD가 기본적으로 포함되어 있고, 오픈그룹의 인증까지 받은 UNIX 머신이다. UNIX 명령을 사용하기 위해서는 당연히 가상의 터미널이 필요하게 되었고, 터미널에서 사용하는 수많은 UNIX 명령어들도 기본적으로 제공하고 있다. 사실 OS X의 수많은 기능들은 UNIX 명령으로 만들어져 있고, 명령의 결과를 GUI로 보여주기 위해 Aqua 윈도우 시스템을 활용하고 있다. 예를 들어 환경 설정 – Preferences 앱을 실행하면 시스템 혹은 홈폴더 아래 있는 /Library/Preferences/ 디렉터리에서 plist 파일들을 열어 화면으로 보여주고, 설정을 변경하면 이 파일들을 수정해서 저장한다. 그리고 이 파일들에는 환경 설정에서 보여주지 않는 숨겨진 기능까지 저장되어 있다.
OSX을 포함해서 모든 운영체제는 시스템 내부를 관리하고 프로그램을 실행하는 커널과 그 커널을 보호하기 위해 둘러싸고 커널의 기능 중에서 한정된 기능만을 사용하도록 하는 쉘이 있다. 여러 가지 쉘 중에서도 UNIX기반 쉘은 터미널에서 쓸 수 있도록 텍스트 기반의 쉘로 발전했고, GUI 기반의 매킨토시와 윈도 시스템은 탐색기나 파인더가 부분적으로 쉘 역할을 한다. OS X은 NeXTSTEP과 Mac OS의 화려한 GUI와 UNIX의 강력한 터미널 기능이 멋지게 결합된 형태라고 할 수 있다. 따라서 터미널 앱을 실행하고 OS X에 접근하기 위해서는 UNIX 쉘과 명령어들에 익숙해져야 한다. 결국 OSX의 터미널 앱은 UNIX 쉘을 사용하기 위한 접속 도구일 뿐인 것이다.
다음에는 OS X의 터미널에서 사용하는 여러 가지 쉘 환경과 유용한 명령어들을 살펴보도록 하겠다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

사용자 인증과 친구 찾기

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 박세현님께서 아이폰에서의 개인 정보 문제에 대한 글을 기고해 주셨습니다.

많은 iOS용 SNS/메시지 앱 들이 최초 가입 과정을 전화번호 인증으로 대신한다. 또, 인증된 사용자의 친구를 자동으로 찾아주기 위해, 주소록 데이터를 서버에 올려 사용한다. 이 두 기능으로 사용자에게 빠르고 편하게 서비스를 제공할 수 있게 된다.
그러나 두 가지 기능 모두 애플로 부터 “사용 금지” 처분을 받게 될 것으로 보인다.
주소록 데이터 사용 
주소록 데이터 사용 건부터 먼저 살펴보자. 주소록 데이터를 가져다가 친구맺기에 쓰는 경우는 이전부터 허다하게 많았는데, 최근 이 문제가 붉어진 이유는 바로 Path 때문이었다. 미려한 UI, 사진 필터링 등으로 많은 인기를 얻은 이 앱이 사용자 동의 없이 주소록 데이터를 서버로 올리고 있다는 사실이 블로거 Arun Thampi에 의해 알려졌기 때문이다.
Path의 CEO, Dave Morin이 블로그에 사과 글을 재빠르게 올리고, 수정한 버전을 앱스토어에 등록했지만 이 사건의 여파는 쉽게 가라앉지 않았다. 눈치 빠른 개발사들은 사건의 심각성을 파악하고, 신의 앱이 주소록 정보 사용 시 사용자의 동의를 구하도록 변경하거나, “친구 찾기”와 같은 문구를 “연락처 업로드하기”로 변경하고 있다.
미 의회의 Henry Waxman과 G.K. Butterfield 의원도 이 사건을 가볍게 보지 않고, 애플에 해명을 요구하였다. (서신을 통해 전달한 8가지 정도의 관련 질문의 답을 2월 29일까지 요구하고 있다.)
일단 애플은 대변인 Tom Neumayr를 통해, 이에 대한 해결책을 제시하긴 했다. 주소록 정보에 접근할 때, 사용자의 허가를 구하는 방식인데, 이는 애플리케이션이 사용자의 위치 정보를 사용하고자 할 때, 알림 팝업을 통해 동의를 구했던 것과 유사할 것이다.
캘리포니아 주 법무부의 최근 발표는 여기서 한단계 더 나아갔다. 모바일 앱 시장을 제공하는 여섯개 업체(애플과 구글, 아마존, HP, MS, RIM)가 모두 동의했다는 새 표준에 따르면, 앱 스토어에서 다운받는 앱의 개인 정보 정책을 미리 확인 할 수 있게 된다. 또한, 이 사항을 위반하는 앱을 쉽게 신고할 수도 있어야 한다. 이를 위반하는
개발사는 캘리포니아 주법을 위반하는 상황에 처할 수도 있다 하니, 많은 앱의 개인 정보 활용 정책을 분명히 파악하기가 쉬워질 것으로 보인다.
Path로 시작된 이 문제는 사실, 국내 개발사 입장에서는 큰 이슈가 아닐지도 모르겠다. 이미 대부분의 SNS/메시징 애플리케이션은 이미 첫 구동시(혹은 가입시)에 개인 정보 활용 동의를 해야만 서비스를 이용할 수 있으니 말이다. 혹, 지금껏 그리 하지 않았더라도 이제 동의 절차를 추가하고 (개발사가 안하더라도 새 버전의 iOS에서 알아서 처리가 될 터이고) 언젠가 앱 스토어의 개인 정보 정책을 채워넣기만 하면, 주소록 데이터의 사용 자체가 막힌 것은 아니니까.
전화번호 인증
사실 당면한 더 큰 문제는 아마 전화번호 인증 “금지”일 것이다. 번거로운 가입 절차를 사용하는 ID/Password 시스템 대신, 전화번호 인증을 통해 사용자를 “가입과 동시에 구분”하는 방식은 대다수의 SNS/메신저 애플리케이션이 사용하는 인증 방식이다. 국내 메신저 서비스인 카카오톡 뿐만 아니라 WhatsApp도 사용하고 있고, 심지어 페이스북의 메신저 앱도 이 방식을 사용한다.
애플이 공식적으로 “SMS 인증을 금지”한다고 한 적은 없는 것으로 알고 있지만, 이로 인해 카카오톡이 업데이트가 지연되고 있다는 뉴스가 간헐적으로 들려왔었다. 국민 메신저 앱인 카카오톡의 업데이트를 지연시키고, 인증 방식을 변경하라는 요구가 국내 언론에 곱게 비춰지지는 않는 것 같다.
“애플 관계자”에게 문의해본 결과, 뉴스에 나온 대로 SMS를 통한 사용자 인증을 금지시킬 계획인 것으로 보였다. 일단 추측할 수 있는 이유는, 주소록 사건과 마찬가지로 “개인 정보 보호”를 위함이라고 해석할 수 있을 것이다. 애플이 사용자 개인의 정보나 디바이스에 해당하는 정보의 사용을 막은 것은 이번이 처음이 아니다. 작년 하반기 경, iOS 5가 출시되면서 UDID(디바이스 식별정보)를 사용해 디바이스나 사용자를 인증(혹은 식별)하는 방식을 금지시킨 전례가 있었다. 그 전까지, 이 정보를 통해 디바이스를 구분하던 업체들은 UUID라는 고유 키를 사용하거나, 인증을 위한 다른 방법을 새로 고안할 수밖에 없었다. 이 때에도 애플은 개인 정보 보호라는 명목으로 UDID사용을 막았다.
SMS 인증이 가진 다른 문제는 휴대전화 분실이나, 전화번호 변경 등을 생각해 볼 수 있을 것이다. 사용자를 식별하는 정보가 분실되거나, 변경되는 경우 해당 사용자의 기존 데이터가 다른 사람에게 유출되거나, 기존 사용자가 복원할 방법을 찾기가 어려워진다는 문제가 있다. iPad와 iPod Touch를 판매하는 애플 입장에서는, 이 두 기기만 쓰는 사용자에게는 서비스가 제한될 수 있다는 점이 마음에 안들었을 수 있다. 그러나, 이런 이유로 SMS 인증을 막은 것 같지는 않다. 정확한 이유는 모르겠지만 일단 가장 겉으로 보이는 가장 큰 이유는 개인정보 보호일 것이다.
해결책 
애플이 그렇게 하겠다니 뭐 어쩌겠는가? 일단 급한대로 해결책을 마련해야 하지 않겠는가? 결국은 애플이 제시하는 방향으로 갈 수 밖에 없을 것이다.
주소록 문제는 간단하다. 사용자에게 주소록 정보 사용에 대해 알려주고, 동의를 구하면 될 것이다.
그럼 SMS인증은 어찌하나?

어쩔 수 없이, ID/Password 방식으로 가야할 것이다. Facebook이나 Twitter 계정에 빌붙는 방법도 있겠다. 어쨌든 SMS를 통한 사용자 인증은 더 이상 허용되지 않을 것으로 보인다.
주소록 데이터와 SMS 인증, 두 개의 별개의 문제가 한 곳에서 만나는 지점은 바로 ‘친구 찾기’ 기능이다. (사실, 이 기능 때문에 이 글을 주절주절 쓰게 되었다.) 주소록 데이터에 등록되어있는 친구들의 연락처(주로 전화번호)로 친구맺기 서비스를 제공하려면 사용자의 전화번호를 받아야만 한다. (그리고 그 번호가 해당 사용자의 번호인지 인증해야만 한다.) 다행이도, 사용자 인증을 위한 SMS의 사용은 금하지만, 사용자가 친구 찾기를 위해 자신의 번호를 등록하는 것은 허용할 것으로 보인다.
절차가 좀 번거로워지긴 하지만, id/password (혹은 다른 방식의) 사용자 인증 후, “친구 찾기”를 위한 주소록 데이터 사용 동의, 개인 전화번호 등록 등의 과정을 거친다면, 기존의 자동 친구 맺기 기능은 사용자의 명시적인 동의 하에 계속 서비스할 수 있을 것이다.
애플의 속셈?
개인 정보를 보호하고픈 애플의 의도는 이해가 간다. 그런데 SMS 인증을 막는 것이 정말 그 때문일까?
나는 다음 두 가지 정도의 숨은 의도가 있지 않나 추측해본다.
1. 전화 번호의 기능 축소
전화 번호는 통신기기에만 부여되는 식별 번호이다. 한 개인이 여러 개의 번호를 갖기도 힘들고(돈이 많이 들고), 맥과 iPad, iPod Touch와 같이 전화번호와 사실 별 상관 없는 기기들도 많이 존재한다.
그리고 무엇보다도 전화번호는 애플이 통제하기 쉬운 시스템이 아니다. 여전히 통신사에 속한 영역인 것이다.
애플 입장에서는 애플 기기에서 돌아가는 서비스에서 사용자 간의 네트웍을 구축하는 식별 정보로 전화번호를 쓰기보단, 이메일을 쓰는 것이 더 편하다. FaceTime 앱이나 OS X용 Messages 베타를 사용해보면 이 말이 무슨 의미인지 알 수 있을 것이다. 이메일을 쓰면, 아이폰 간 커뮤니케이션 뿐만 아니라, (전화번호와 상관 없는) 각종 기기 간의 통신이 훨씬 수월해진다.
2. 애플이 제공하는 인증 시스템
첫 번째 추측에 더해, 애플은 아예 애플의 계정(.Mac, MobileMe, iTunes, iCloud 계정으로 뒤죽박죽이 되어버렸으나 iCloud로 통합하고 싶어보이는) 시스템으로 모든 사용자의 인증과 식별을 전부 통합하길 원할지도 모른다.
Game Center와 같이 애플이 제공하는 API를 통해 사용자를 인증하는 시스템을 도입해 준다면 어떻게 될까?
애플리케이션을 처음 구동할 때, 인증 서비스를 사용할 지 묻고, 애플 계정을 입력하면 애플리케이션에는 특정 키를 내려주는 식으로 처리할 수 있을 것이다. 아니면 Game Center가 그냥 더 확장되어 일반 애플리케이션에서도 커뮤니케이션과 인증 용도로 사용할 수 있게 되거나…
물론 이 시스템은 iOS와 OS X을 사용하는 환경에서만 동작하겠지만, 이는 현재 Game Center도 마찬가지다. 그럼에도 불구하고, 모바일 시장의 메이저 플레이어인 애플이기에, 많은 게임 개발사들은 Game Center를 지원한다. (물론, 타 플랫폼과의 호환을 위해 별도의 랭킹 시스템을 함께 도입하는 경우도 많다.)
이런 기능이 도입되면, 멀티 플랫폼 개발자 입장에서는 id/password 시스템과 병행해야하는 부담감이 적지 않을 것이다. 그러나, 그것은 개발사의 문제이지, 애플의 문제가 아니다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

No Office for iOS

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 이인배님께서 아이패드와 Microsoft Office에 관해서 글을 기고해 주셨습니다.
<기고자주> 이 글은 개인 블로그에 올렸었던 내용을 각색하여 기고한 것임을 밝힙니다.

Patrick Rhone 의 블로그 포스트 Microsoft’s Biggest Miss 는 ‘왜 마이크로소프트가 애플의 iOS 시장을 피해 갔을까’ 라는 내용을 다룬 영문 기사이다. <편집자주>한글 번역된 내용은 알비레오 사이트에서 볼 수 있습니다.</편집자주> 마이크로소프트는 분명 소프트웨어를 하는 회사이고, iOS 의 파급 정도를 (예측하지는 못했어도) 후천적 수요와 시장성 때문에 한 번이라도 고려해 보지는 않았을까 하는 내용이다. 핵심이 되는 문단은 다음과 같다:

“Microsoft’s DNA is software. They are primarily a software company. The very name of the company is a mashup of microchip and software. And of all of the software they produce, one is more important than all the rest and a huge revenue source that the very livelihood of the company has come to depend on.”
“Are you thinking Windows? Wrong.”
“마이크로소프트의 핵심은 소프트웨어이다. 마이크로소프트는 우선적으로 소프트웨어 회사이고 말이다. 회사 이름 조차 (마이크로칩의 마이크로와) 소프트웨어의 소프트가 들어가 있다. 그리고 그들이 만드는 모든 소프트웨어들 중 제일 중요하며 수익성이 큰 놈 하나가 있고, 회사가 그래서 그 소프트웨어 하나에 매우 크게 의존하게 된 것이 있다.”
“윈도우즈 라고 생각하는가? 틀렸다.”

일단, 저자의 주장하는 바가 진실인지를 확인하는 차원에서, 또 단순히, ‘자존심 또는 사업방침 때문에 어떠한 이유에서든 개발하지 않겠다’ 라고 마음 먹은 것이 아니라는 것을 전제로, 정말로 그런 가치가 없다고 생각을 할 만한가? 라는 궁금증이 생겨서, 한 번 머리를 굴려 보기로 했다. 과연 마이크로소프트가 뭘 해서 제일 수입을 벌고 재미를 보는지 부터 알아 보는게 좋다고 생각이 들었다. 그리하여, 마이크로소프트의 공식 발표 자료 (www.microsoft.com/investor) 를 토대로 직접 표를 만들어 보았다. (나라별 회사별 회계연도의 책정 기준은 틀리므로, 순수하게 2011년 전체를 4등분한 1~4분기를 기준으로 열거해 보았다.)
Microsoft’s Revenue in 2011, in $ Billions

2011 Q1 2011 Q2 2011 Q3 2011 Q4
Microsoft Business Division 5.25 5.77 5.62 6.28
Server & Tools business 4.1 4.64 4.25 4.77
Windows and Windows Live Division 4.45 4.74 4.87 4.74
Online Services Division 0.65 0.662 0.625 0.784
Entertainment & Devices Division 1.94 1.47 1.96 4.24
Total 16.43 17.37 17.37 20.89

눈대중으로 보면, 작년 전체 수입이 $71B, 오피스 계열의 대(對) 비즈니스 사업의 그것이 $23B 정도로, 약 삼분의 일을 차지하여 제일 큰 비중을 차지하고 있다고 볼 수 있다. 이 조사를 하기 전까지 오피스가 윈도우즈보다 사업성이 더 클 줄은 몰랐는데, 놀라운 일이다. 언뜻 생각하면 윈도우는 문틈에 발 들여 놓기 격인 것이고, 그 위에 얹는 소프트웨어로 더 돈을 많이 버는 것이니 재미있다.
자 이제 만일 마이크로소프트가 iOS 용 오피스 앱들을 만들어서 출시했다고 가정하면, 대략 이만큼의 수익을 올릴 수 있지 않았을까 생각해 본다. (이번에는 Horace Dediu 의 이 자료를 참고했다.) 역대 아이폰 누적판매 대수가 약 1.8억 대, 아이팟 터치가 7500만 대, 아이패드가 5500만 대 라고 한다. 실제 iOS 디바이스 사용자 수는, 아이폰 사용자 수와 아이패드 사용자 수의 합집합 X 천만 명, (중복 사용자를 배제해야 하므로) 이라고 쳐야 할 것 같다. 그리고 실제 iOS 를 쓰는 사람이 누적 iOS 디바이스 판매대수의 1/10 이라고 치면, 아무리 잡아도 전세계적으로 대충 수천만 명일 것이다. 그 중 극히 일부만 오피스 앱을 구매한다고 치고, 1/10 을 잡아도 수백만 명이라면, 더 나아가 아주 소극적인 백만 명 이라고 치자. (Patrick Rhone 역시 자기 블로그에서 “I would guess in the millions” 라고 했다.) 그래서 그 사람들이 한 번씩 구매를 한다면, 앱 하나 당 (애플의 Keynote, Numbers, Pages 와 비슷하게 잡고) 10 달러 씩이라고 쳤을 때, 앱 당 수입이 $10M 정도 밖에는 되지 않을 수도 있겠다.
물론 ‘앱 몇 개를 팔아서 얼마를 벌 것이고, 그게 꼭 얼마 이상이 되어야 가치가 있는 사업이다’ 외에도, 앱 개발의 당위성은 있을 것이다. 기존 오피스 사용 회사들이 “우리도 우리 직원들에게 아이패드로 회사 문서를 보게 해 주세요” 라고 강력하게 요구를 하거나 등. 또한, “나는 회사에서는 윈도우즈를 써야 한다고 해도 죽어도 개인적으로는 맥을 쓴다” 라거나, “블랙베리/안드로이드폰을 써야 한다고 해도 굳이 돈을 내고 아이폰을 쓰겠다” 라는 사람들도, Pages 혹은 Numbers 가 너무 안 맞아서 워드/엑셀을 쓰고 싶어 하는 사람도 꽤나 있을 법 하다 (본인도 그런 부류이다). 이런 저런 입장에서 보면, “맥용 오피스는 있으면서 왜 iOS 용 오피스는 없는 거지?” 라는 의문점은 섭섭함을 불러 일으킬 수 밖에 없다.
다시 원론점으로 돌아 와서, Minimal Mac 의 저자 Patrick Rose 가 지적한 내용이 진리일 수 있다. 마이크로소프트라는 조직은, ‘우리의 방식 말고는 아무도 진짜 업무용 어플리케이션을 만들 수 없다’ 라는 아집과 착각을 지니어 여기까지 왔기 때문에, 이 기회를 놓쳤을 것이다 라는. 업계의 아는 사람은 알듯이, 그리고 잡스전기를 읽은 사람도 알듯이, 빌게이츠의 초기 사상은 Windows everywhere 였다. 운영체제 하나를 만들어 놓고, 이를 어느 제조사의 컴퓨터이든 탑재하는 것이 중요하다고 생각했었다.  이러한 방향성은 지금 현재 정책과는 조금 상반된 것으로 보이고, 사용자들에게는 결국 불편하거나 아쉬움만 남기는 부분이 아닐 수 없다. Patrick Rhone 의 아내가 그에게 했던 문구를 그대로 인용하자면:

“You see, she said, missing all of the opportunities was just the start of a much deeper problem. Microsoft for many years had convinced the world that, in order to get “real work” done, you needed Office.”
“이건 깊이 생각해 보면 더 본질적인 문제가 있는 것이다. 마이크로소프트는 수 년간 이 세상에게 “진짜 진지한 일, 즉 업무 관련 일을 하려면, 오피스 없이는 안 된다” 라는 인식을 심어 주었었다.”
“Then, she explained, the iPhone came. There was no Office. People got things done. Then the iPad came. There was no Office. People got things done. Android came. People got things done. All of those things that they, just a couple of years ago, were convinced they needed Office to do. They got them done without it. And thus, the truth was revealed.”
“그러던 어느 날, 아이폰이 도래했고, 오피스 없이도 사람들은 일을 할 수 있었다. 아이패드가 출현한 후에도 마찬가지였고, 안드로이드가 등장한 후에도 마찬가지였다. 불과 몇 년 사이에, 이러한 인식은 뒤집어 질 수 밖에 없었고, 결국 (마이크로소프트에게는 불편한) 진실이 들어난 것이다.”
“Microsoft’s biggest miss was allowing the world to finally see the truth behind the big lie — they were not needed to get real work done. Or anything done, really.”
“And that will be what ultimately kills them.”

진짜로 마이크로소프트가 이 점 때문에 몰락할 것인지는 관심을 갖고 지켜 볼 일이다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

왜 애플은 중국 노동문제로부터 벗어날 수 없는가?

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 그 첫 컬럼으로 정일기님께서 애플과 중국 노동문제에 관해서 글을 기고해 주셨습니다.

 지난달 20일 중국내 Foxconn 공장에서 일어난 폭발사고를 조명하며 뉴욕타임즈에서 중국내 애플 제품 조립업체인 Foxconn에서의 노동자들에 대한 처우를 다루었다. 이와 함께 여러 언론에서 애플의 공급업체인 Foxconn의 노동자들의 위험한 작업환경에서의 노동과 과도한 작업량으로 인한 노동자들의 처우가 세상에 알려지면서 애플은 세상으로부터 엄청난 질타를 받기 시작했다. 미국 내 노동자 환경을 위한 두 단체(Change.org, Sumofus.org)에서 사람들에게 서명을 받아 비윤리적인 공급업체들에게 애플이 처우개선을 위해 노력을 해야 한다고 촉구하면서 청원서를 제출했고, 이에 애플은 외부기관인 공정노동협회(FLA)에게 이와 관련된 감사를 요청했으며, FLA는 Shenzhen과 Chengdu 공장들을 포함한 Foxconn 공장들에 대한 조사를 착수했다.

 세계에서 가장 혁신적이고 성공적인 애플사의 밝은면 이면에 이러한 어두운면이 존재한다는 사실은 전 세계적인 이슈가 되면서 사람들의 많은 토론으로 이루어 졌다. 이러한 내용이 애플의 공급업체의 문제이지 애플이 직접 부당 노동행위를 하고 유독성 폐기물을 직접 버린것이 아니지 않느냐고 이야기 하는 사람들도 있으나 왜 언론 및 노동협회에서 애플에게 처우 개선을 요구하는지에 대해서는 3가지 측면에서 바라볼 수 있다.

1. 과거 나이키 사례와 같이 발주업체를 압박하여 영향력을 행사

  2000년대 초 멕시코에 있는 나이키 하도급공장에서 열악한 노동조건에 항의하던 직원들을 대량 해고하고 아동노동 등 인권유린 혐의도 받으면서 미국 내에서 나이키 불매운동이 거세게 일어났던 사태를 기억하시는 분도 있을 것이다. 멋지게 포장되어진 스포츠 스타와 용품들을 마케팅의 주 전략으로 삼았던 나이키의 이면에 과도한 노동환경과 고사리 같은 손으로 축구공을 꿰매야했던 아동노동의 존재는 지금 애플의 이슈와 같이 거센 여론을 형성하였고, 나이키뿐만 아니라 아이다스 등 생산업체에게 가장 영향력이 큰 발주업체들을 압박하면서 노동자 처우개선을 위한 토론과 함께 협회 제정 및 공급업체의 요구기준 등을 정하게 되는 교두보가 되었다.

  전 세계적으로 글로벌 기업과 경영이 확산되면서 기업들이 원하는 생산성과 속도에 모든 초점이 맞추어 지다보니, 노동력이 싼 저임금 국가로 생산시설들이 거의 대부분 이전되어 있는 상황에서 각 국가의 노동기준 및 환경보호 관련 법률 등이 서로 상이하다. 이런 다른 실정들 속에서 생기는 비윤리적인 문제들을 해결하기 위해서 타국 내 법률적 기준이 우리의 실정과 맞지 않다고 비판을 가하고 변화를 촉구하는 것은 현실적으로 매우 어려운 문제이므로, 생산업체에게 가장 큰 영향력을 끼칠 수 있는 발주업체들에게 처우개선을 위해서 노력하라는 압박을 가하는 것은 매우 효과적인 방법으로 알려져 있으며, 이에 애플이 발 빠르게 행동하는 것도 같은 맥락으로 이해할 수 있다.

2. 미국 내 대선과 맞물린 경제부흥 주장

 스티브 잡스가 살아생전 백악관에서 오바마 대통령과 IT기업의 대표들과 가진 만찬에서 애플제품의 생산시설을 미국 내로 이전하여 일자리 창출에 기여할 수 있는지에 대해 오바마 대통령과 나눴던 대화에서 그러한 일은 일어나지 않을 것이라고 못 박은 적이 있다. 이는 애플의 완벽한 품질 요구에 대응할 수 있으려면 높은 숙련도와 생산성 및 빠른 속도와 간결함이 필요한데 이를 미국 내에 구축하기 위해서는 시간과 비용 등 제약요인이 너무 많다는 뜻으로 해석할 수 있다.

 이 같은 잡스와 애플의 입장에 대해 미국 근로자들과 지역사회는 거세게 반발하고 있다. 애플이 자국 내 고용에 인색한 이유는 생산성이나 숙련도 차이가 아니라 단지 비용 절감만을 고려한 결정이라는 것이다. 이는 애플이 비용 절감을 위해 생산시설을 해외에 둠으로써 낮은 노동비용과 세금혜택, 위치 등의 3가지 요인에서 비용 절감의 효과를 거두어 전 세계적 경기침체에도 불구하고 천문학적인 이익을 거두어들인다는 것을 증거로 대며 애플을 비판하고 있다.

 더욱이 2012년 미국 대선에 따라 정치적 이슈를 부각시켜 여론의 공감을 얻기 위해 자국 내 부의 양극화와 국가의 경제불안을 타파하기 위해서 많은 이익을 내는 애플이 오블리스 노블리제를 실천하지 않는다는 점을 부각시키고 있다. 중국서 고조되는 노동력 착취 여론과 중국정부의 근로자 임금 인상과 근무환경 개선의 요구와 같은 해외생산 이점이 줄어들고, 24일 국정연설에서 오바마 대통령이 이야기한 것과 같이 자국 내 투자를 늘리고 고용을 창출하는 기업에게 적절한 보상을 하고, 해외 생산으로 인한 세제 혜택을 보는 기업들을 반대한다는 주장이 정치권에 더욱 힘을 실어주면서 언론에서도 중국에서의 애플제품 생산공정에 대한 노동문제에 대해서 집중적인 보도를 이끌어 이의 해결책으로 자국 내에 숙련된 노동력을 이용함과 동시에 국가 경제를 이끌어야 한다는 의도로 또한 해석할 수도 있을 것이다.

3. 애플이 추구하는 브랜드 이미지 관리

 국내에 아이폰이 출시될 당시에 애플의 간섭은 진저리가 날 정도로 꼼꼼했다고 뉴스가 났었다. 그만큼 애플이 브랜드 이미지에 많은 노력을 쏟아 부으며, 소비자에게 어떻게 인식되어지는 바에 매우 적극적으로 행동하고 있는것으로 정평이 나있다. 물론 브랜드 이미지를 신경쓰지 않는 기업은 없겠지만 그동안 애플 소비자에게 어필한 Awesome하고 Cool한 브랜드 이미지에 악덕기업이란 오명을 쓰지 않기 위해서 특히 더 발빠르게 행보하고 있다고 볼 수 있다. 그동안 애플이 광고해 온 기술을 선도하고, 환경을 생각하는 윤리적이고 사회적인 기업의 브랜드 이미지를 신경쓰는 애플이 타겟이 된만큼 발빠르게 움직일 거라는 노동협회들의 기대도 반영한다고 생각할 수 있을 것이다.

 모든 기업은 사회의 일부분으로 존재하기 때문에 사회적인 힘, 규제적인 힘, 정치적인 힘에 영향을 받는다. 이 같은 것들에 주의를 기울이고 그것들이 기업에 어떤 영향을 미치는지 항상 살펴보는 것을 간과한다면, 나중에 커다란 화를 자초할 수 있다. 물론 앞서 이야기한 3가지 측면이 필자의 개인적의 의견일 뿐이고, 그 외 우리가 알 수 없는 여타 다른 복잡한 이해관계 또한 존재하겠지만, 현재 세계적으로 어떤 기업이 되어야 하는가에 관한 논의에서 패러다임의 중심은 항상 윤리적이고 사회적인 기업이다. 물론 이를 위해서는 혁신적이고, 이익이 많은 성공적인 기업이 밑받침되어야 하겠지만 경쟁에 이겨 성공함으로써 위대함을 얻을지언정 인간에 대한 기본적인 예의가 결여된다면 존경심이 잘 어우러지는 기업은 될 수 없다. 즉 제품이나 서비스, 고용뿐만 아니라 다른 기업의 역할 모델로서 세상에 긍정적인 영향을 미치는 기업이 되기 위해서는 애플이 한걸음 더 나아가 지금의 큰 문제들을 어떻게 Awesome하게 풀어나갈지 앞으로의 행보가 기대된다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

redmine tool – 1st Iteration

드디어, 내부 프로젝트의 첫삽을 떴습니다.
지난번 모임에서 몇가지를 확인하였습니다.

  • 내부 프로젝트의 가이드 라인
    • Mac OS X 용 응용 프로그램일 것.
    • Mac OS X 용 응용 프로그램 이상의 개발이 필요하지 않을 것.
    • 우리 스스로가 가장 많이 사용할 것.
  • 개발할 아이템
    • redmine 관련 도구!

이번 모임에서는 5시간에 걸쳐서, 기획/개발를 동시에 진행해 보았습니다. 그리고, redmine 도구, 과연 어떤게 필요할까 하는 의견부터 모아보았습니다.

  • Gantt 차트 도구 : 현재 redmine 에서는 Gantt 차트로 이슈를 보여주는 기능이 있는데, 이 그래프가 단지 시각적으로 보이기만 하고, 실제 마우스로 이동한다던지, 시작일과 종료일을 바로 바꾼다던지 하는 다이나믹한 사용은 불가하다. 이것을 Native App 을 통해서 해결하고 싶다.
    • 일단, Gantt 차트에 추가 기능을 제공하기 이전에, 기본적인 Gantt 차트 그리기 기능부터 만들어야 하나, 이에 대한 노력이 많은 큼. 추가적인 기능 제공을 하기 위해서, 웹에서 이미 제공하는 기능을 다시 만들어야 한다는 부담도 경제성을 생각해 봐야 할듯 함.
  • Time Tracking 기능 : 현재 이슈에 대한 소요 시간을 웹 페이지에서 스스로 기록하도록 되어 있으나, 이를 Mac OS X 응용 프로그램 차원에서 쉽게 해 줄 수 있을까?
    • 일단 기본적인 기능을 먼저 구현한다면, 그 다음에 쉽게 추가할 수 있을 듯하다.
  • Redmine 이슈 목록 보기 : 자동 로그인 하여, 프로젝트 목록과 이슈 목록을 볼 수 있게 하자.
    • 오늘의 주제로 선정

일단, 위와 같이 하여, 이슈 목록을 메뉴바 애플리케이션으로 저장하여, 현재 이슈의 목록과 프로젝트의 목록을 보여주도록 하는 아주 간단한 기본적인 기능을 만들어 보기로 하였습니다. 일단은 시작하는 차원에서 redmine 과의 연동을 테스트 해 보는 차원도 있기 때문에, 많은 욕심을 내지 않았습니다.
화이트 보드에서 전체적인 그림을 그려 보았습니다.

  • 최초 시작시, API 키 값과, redmine URL 입력창 보여주기. Login 버튼을 누르면, 해당 값이 유효한지 확인하고, 확인이 되면, 넘어가고, 확인이 안되면 실패를 알려준다.
  • 로그인 후에는 화면 상단의 메뉴바의 메뉴를 클릭하면, 현재 이슈의 목록을 메뉴 항목으로 보여준다. 그리고, 해당 메뉴를 선택하면, 웹 페이지를 통해서 해당 이슈 페이지로 이동한다.
  • 이슈 목록 하단에는 Projects 라는 메뉴를 두고, 그 서브메뉴에는 프로젝트 목록을 표시해 준다. 그리고, 그 목록에서 하나의 프로젝트를 선택해 주면, 다시 본 메뉴의 이슈 목록은 해당 프로젝트내의 이슈 목록으로 그 리스트를 제한한다.

썩 좋은 UI 구성도, work flow 도 아니지만, 일단 가장 간단하게 만들어 볼 수 있다는 차원에서 이 정도로 안을 만들었습니다.. 그리고, 만들어야 할 구성 요소와 각자의 역할을 찾아 보았습니다.

  • 프로토콜 분석 : JSON 프로토콜이 제공하는 범위 파악. 각 기능 구현을 위해서 어떤 프로토콜을 사용해야 하는지 파악. 이 역할을 한 사람이 담당하니 매우 시간이 절약 되었습니다.
  • 서버 통신 및 JSON Parse 기능 구현 : HTTP 통신 및 JSON 분석은 워낙 많이 사용되는 기법이라 시간이 많이 걸리지 않았습니다. 재사용 하여 한두시간 내에 구현이 되었습니다.
  • Menu 항목에 대한 다이나믹한 구성 : 서버에서 받아온 이슈 목록과 프로젝트 목록을 메뉴 아이템으로 만드는 모듈. 생각치 못한 버그로 인해서 의외의 모듈에서 시간이 꽤 걸렸습니다.
  • Login 창 및 로직 : 로그인 데이타를 받고, 처리하고, 넘어가는 부분. 어렵지 않게 진행 가능했습니다.
총 5시간의 작업결과 해당 기능을 만들어 낼 수 있었습니다.
Login 창의 동작 모습

메뉴바를 통해서 이슈 목록과 프로젝트 목록을 보여줌

소감

  • 아직은 너무 간단한 기능을 제공하기 때문에, 유용함을 갖췄다고 하기엔 부족함이 많다는 것을 잘 알고 있습니다.
  • 하지만, 5시간을 투자하여, 우리가 생각했던 것을 실제로 동작하는 소프트웨어로 만들어 냈다는 점은 아주 큰 기쁨을 주었습니다.

애자일 개발 방법론에 대해서

  • 우리는 나름 애자일 개발방법으로 해 보았다고 했으나, 이것이 애자일인지 아닌지는 모르겠습니다. 하지만, 우리가 지금껏 해 오던 방식과는 분명 달랐습니다.
  • 기획안을 먼저 골똘히 준비하고, 그에 맞춘 개발을 진행하는 것이 아니라, 개발자끼리(혹 기획자가 있다면 함께 해도 좋지만, 기획자가 없는 관계로)모여서 우리 스스로가 옳다는 기획안을 만들어서, 금방 구현을 해서, 그 유용함을 확인해 보았는 것은 의미있는 과정이었습니다.
  • 또한 개발자 5명과 테스터 1명이 서로 같은 자리에서 얼굴을 맞대고 작업하는 것은 또다른 새로움이었습니다. 지속적으로 대화를 하면서 개발을 진행하였고, 그래서 어쩌면 지속적인 긴잠감을 주는 것 같기도 하였습니다. 대부분의 의견이 5시간동안 집중을 하게끔 한다고 하였습니다. 육체적 피로감은 높았지만, 그 집중력에 대한 성취감도 높았습니다.
  • 생산성은 아주 높았습니다. 모두가 따로 떨어져 했을 때보다, 두세배 더 빠르게 작업하지 않았나 하는 생각입니다.
  • 짧은 시간에 모두가 각자의 역할을 찾는 것이 생각보다는 어렵지 않았습니다. 그래서 혼란스럽지 않게 잘 진행이 되었습니다.
이번주에는 여러가지 일정의 문제로 반나절까지만 해 보기로 하였습니다. 하지만, 일주일에 반나절의 일정으로는 이 프로젝트에 대한 진도가 생각보다 더딜 것 같아서, 일주일에 두번으로 늘여볼까 합니다. 일주일에 두번씩 매번 이정도의 진도로 진행해 나간다면, 앞으로 한달, 석달이 지난 다음에는 꽤 쓸만한 소프트웨어가 되어 있지 않을까 하는 기대감이 듭니다.

 
 

민트기술 2012년 새로운 자체 프로젝트

민트기술을 외주 프로젝트를 통해서 주매출을 얻습니다. 작년 한해 5개 정도의 자체 프로젝트를 했었지만, 그것이 매출로 이어진 것은 없습니다. 매출로 이어지지는 않지만, 그래도 꾸준히 내부 프로젝트를 해야 하는 이유가 있습니다. 우리는 우리의 개발 기술력이 타인의 아이디어, 제품을 빛내주는데에도 잘 사용되기를 바라지만, 우리 스스로의 아이디어와 생각에도 사용되기를 바라기 때문입니다.
우리는 작년 한해동안 해온 내부 프로젝트가 성공적이었다고 단언할 수는 없습니다. 대신 많은 반성을 하였습니다.  2012 신년 계획 에서 그에 관한 생각을 정리한 적이 있습니다. 이에 대한 반성을 바탕으로, 새로운 방향을 잡아 보기도 하였습니다.
그래서, 내부 프로젝트에 대한 몇가지 가이드라인을 잡아 보았습니다.

  1. 첫째, 맥 애플리케이션 입니다. iOS 용 앱도 아닌, 안드로이드용 앱도 아닌, 오로직 맥 애플리케이션을 최종 결과물로 하기로 하였습니다.
  2. 둘째, 단독 소프트웨어 입니다. 맥 애플리케이션 하나로 완전해야 합니다. 다시 말해, 우리가 개발할 영역으로는 맥 애플리케이션으로 한정하였습니다. 서버사이드 개발이 필요하거나, 웹 개발이 필요하거나 하지 않고, 맥 애플리케이션 개발만 하기로 하였습니다.
  3. i use it. 내가 사용하는 소프트웨어를 만들기로 하였습니다. 민트기술 개발 팀원이 스스로 쓸 수 있는, 아니 스스로 쓰고 싶은,스스로에게 꼭 필요한 소프트웨어를 만들기로 했습니다. 그 누구 타인이 필요한 소프트웨어 보다는, 우리가 필요한 소프트웨어를 만드는 것이 더 가치 있을 수 있고, 더 정확할 가능성이 높기 때문입니다.
그래서, 이 가이드라인에 따라서, 몇가지 안을 세워 보았습니다.
  • WYSIWYG 위키 편집 툴. 민트기술 개발팀은 위키를 이용하여, 개발 문서화를 하고 있습니다. 문서화를 잘 하기 위해서는 textile 같은 문법을 익혀야 합니다. 익힌다 하더라도, 복잡한 표가 들어간 문서는 편집하는 것이 보통일이 아닙니다. 좋은 도구가 있었으면 하는 생각을 했습니다.
  • redmine 도구. 민트기술 개발팀은 이슈 관리 도구로, redmine 도구를 사용합니다. 개발 과정 중간에 항상 참조하고, 기록하기 위해서 웹 페이지를 띄워놓아야 합니다. 그리고, 업무 흐름을 파악하는 것도 쉽지 않습니다. 하나의 이슈를 포커스 하는 것도 쉽지 않습니다. 딱히 떠오르는 아이디어는 없지만, redmine 을 쉽게 쓸 수 있도록 도와주는 맥 애플리케이션이 있었으면 좋겠다는 생각이 듭니다.
  • google addressbook sync. 아이클라우드 주소록과 구글 주소록을 서로 비교하여, 싱크를 잘 할 수 있었으면 좋겠습니다. 현재 나와있는 도구는 우리를 만족시켜줄 수 없습니다.
  • flickr_fs. fuse 를 이용하여, flickr 사이트를 파일 시스템으로 마운트하여, 파일을 업로드 다운로드 할 수 있었으면 좋겠습니다. 현재 나와 있는 버젼을 좀더 개선하고 싶습니다.
  • git flow tool. 민트기술에서는 git flow 를 사용하고 있습니다. 이와 관련한 branch visualization 이 있었으면 좋겠다는 생각을 하였습니다.

위 안을 다수결로 하여, redmine 도구 관련한 애플리케이션을 개발하는 것으로 결의하였습니다.
개발 방법론으로 Agile 개발 방법론을 시도해 보기로 하였습니다. 아직 어떻게 하는 것인지 정확한 아이디어는 없지만, 일단 우리 방식으로 적용을 해 볼까 합니다.

  • 일주일에 반나절 정도의 시간을 할애한다.
  • 해당 시간에 개발팀이 전원 모여서 작업을 한다.
  • 모인 자리에서 개발 기획과 개발 진행, 검증을 진행한다.
  • 각자의 정해진 역할을 미리 정하지 않고, 모인 자리에서 그때 그때 결정하여 진행한다.
  • 지속적인 대화를 통해서 의견 교환을 하고, 그와 동시에 구현을 하고, 그 구현 결과를 통해 의견을 나누면 개선해 나간다.

위와 같은 방법론이 과연 잘 진행된지에 대한 의문은 있지만, 일단 진행해 보기로 하였습니다. 잘 안되면, 계속적으로 문제점을 파악하고 개선해 나가야 겠죠?
이쯤되면, 다시 한번 의문이 들 수 있읍니다. 과연 redmine 도구를 왜 만들어야 하는 것일까? 이것이 새로운 수익을 창출할 수 있을까? 일단은 단기적으로 그것보다 목표는 소박합니다. 우리의 목표는 먼저 “아주 작은 그룹의 사용자”에게 “아주 특수한 목적으로 사용되는” 애플리케이션을 통해서 “가치”를 제공하는 것을 만들고 싶기 때문입니다. 만일 이 작은 그룹/목적 내에서 “가치”를 만들어 내기만 한다면, 그 다음에는 더 많은 사람, 더 많은 목적을 위해서도 만들 수 있다고 생각합니다. 그리고, 사람들에게 “가치”를 제공해 줄 수 있다면, 수익, 매출 이런 것은 걱정할 것이 아닌것 같습니다.
아주 처음은 작고 소박한 목표를 향해 출발합니다. 잘 진행되는 과정을 반복한다면 머지 않아 큰 결실을 이룰 수 있을 것으로 기대합니다.