When you develop an Android application on Emulator, you probable encounter a tiny problem. The default screen size of Emulator is generally too large to work on small laptop. For instance, 13″ macbook only supports screen size 1280*800. And you want to develop an application looks perfect on Motorola Droid, which supports 480×854. It exceeds your laptop’s real estate.
In this case, you may want to resize (or scale down) the Emulator’s screen. Here’s the solution what you’re looking for.
In face, Android AVD Manager’s shipped with the feature built-in. Let’s check one by one.
I prepared one AVD which supports WSVGA1024. Really big. Mostly suitable for tables, but not phones. Anyway..
Your emulator on your display will have the exactly same size you just set at step 5. In above case, the emulator’s screen will cover 7″ in your display.
OK.. Enjoy programming!
오픈 소스 제품을 쓸 때마다 항시 헷갈리는 라이선스 정책.. 혼자 개발할 때면 큰 상관이 없지만, 회사 프로젝트라던가, 다른 사람과 함께 개발할 것이라면 라이선스를 잘 따져봐야 한다.
회사에서 1회성 교육을 받긴 했지만, 몇 달 지나니 영 생각이 나지 않는다. 이것이 저것 같고, 저것이 이것 같고.. ㅎㅎ 그래서 한 번 구글링을 해보니 역시나 KLDP 에서 비교적 자세하고 쉽게 정리해두었다. (그것도 아주 오래 전에) 필요할 때마다 참고하도록 하자.
오픈소스 소프트웨어 라이센스 가이드
한 가지.. 오픈 소스계의 또 하나의 큰 틀인 Eclipse 재단의 CPL (Common Public License) 이 누락된 점은 조금 아쉽다.
나는 작년에 마음에 맞는 사람 몇 명과 제법 참신하고 효과적인 스터디를 만들어 운영해보았다. 그 경험은 값진 기억이 되었고, 추후 여건이 다시 갖추어지면 유사한 형태로 재도전해보고 싶다. 여기 그 방식에 대해 간략히 소개해볼 터이니, 관심 있는 사람은 직접 주변인들과 시도해보길 권해본다.
내가 만들었던 스터디는 조금 특이했다.
가장 큰 특징은 참여자들이 준비해올 것이 없었다는 점. 스터디 자료로는 Google Tech Talk, iTunes U(niversity) & Video Podcast, 인터넷 상의 각종 기술 세미나, 최신 툴 데모 동영상, 유명인 인터뷰 동영상 등이었다. 세어보진 않았지만, 대략 백여개 정도의 흥미로운 자료들을 모을 수 있었다.
1시간 정도 동영상을 함께 보고, 30분 정도 토론을 한다. 부족한 정보는 그때그때 인터넷에서 검색해볼 수 있고, 더 깊은 지식을 원하거나 직접 해보고 싶은 것들은 action item 으로 빼서 스터디 외 시간에 진행하기도 한다. 흥미로는 결과는 종종 스터디 참여자 이외의 사람들과도 공유했고, 또 과제 진행에 도움이 되는 일을 진행하기도 했다.
또한, 서로의 task plan 을 리뷰하면서 planning 기술을 늘려가기도 하고, 코드 리뷰로부터 나온 유용한 패턴들을 공유하는 자리로 활용한다.
별다른 준비 없이 참여만 하면 지식과 지혜를 얻어갈 수 있는 모임이었고, 이런 특성이 스터디를 오랫동안 유지하는데 큰 도움이 되었다고 믿는다.
여기에.. 매달말 회고(retrospective)를 진행했다. 회고에서는 지난 한 달동안 공부한 내용 되집어보고, 다음 한달간 공부할 커리큘럼을 짠다. 스터디 진행 방식에 있어 개선이 필요하다고 생각되는 것들을 논의해서 적용해본다. 주기적으로 동기를 부여하고, 부족한 부분을 지속적으로 보강하여 모임의 생명력을 유지해나가고 발전시키는 수단으로 효과가 높다.
이 모임은 매일 아침 7:30 에 모여 9시까지, 약 4달간 유지되었고, 일부 열성 멤버는 토요일에 모여 별도의 스터디(iPhone application programming)를 진행하기도 했다. 그러다 내가 다른 목표가 생겨 탈퇴하면서, 아쉽게도 현재는 운영되지 않는 상태다.
운영하면서 어려웠던 점들도 정리해보았다.
- 참여자들이 대부분 서로 다른 서브팀 맴버였고, 같은 서브팀 내에서도 개개인이 독립적으로 일하는 문화 때문에 시너지를 일으키는데 한계를 많이 느꼈다.
- 멤버들이 업무상 건물간 이동이 잦아, 일부 맴버들은 왔다갔다하는 불편을 겪기도 했다.
- 정식 업무가 아니라, 이른 아침 시간을 선택.. 참여 희망이 있어도 나오지 못하는 사람들도 종종 있었다. 멀리 사는 사람, 아침잠 많은 사람 등. 소수 인원으로 운영하다보니 두 명만 빠져면 스터디 진행에 큰 영향을 미쳤다. (내가 빠진이 운영 중단에 큰 영향을 미친 이유다.)
- 팀이 점점 (반 강제적으로) 늦게 퇴근하는 문화로 바뀌면서 아침 스터디에 대한 부담이 점차 가중되었습니다.
내가 이 스터디를 주창한데는 주변 개발자들이 세상 돌아가는 정보를 너무 모른다는 느낌을 평소 많이 받았다는 이유가 크게 작용했지만, 진행을 하면서 나 역시도 다른 멤버들로부터 많은 정보를 얻고 미처 생각하지 못했던 깨우침을 얻게된 값진 경험이었다.
지난달 iPad 발표와 함께 iPhone OS 3.2 가 공개되었다. 이름은 iPhone OS 이지만 정작 iPhone 용으론 제공되지 않고 있어 의미가 퇴색될 수도 있지만, 애플이 iPhone/iPod touch 와 iPad 의 OS 브랜치를 완전히 나눌 가능성은 높지 않아 보인다. iPhone OS 라는 이름을 버리지 않았고, 또 버전도 그대로 계승하고 있기 때문이다.
그렇다면 iPhone OS 3.2 의 상당수 기능들이 4세대 iPhone 으로 녹아들어가는 것이 자연스럽다. 아마도 iPhone OS 4.0 이 될 새 OS 에는 어떤 기능을 기대해볼 수 있을까? 잠시 시간을 내어 정리해보았다.
내가 등록된 iPhone 개발자가 아닌지라 SDK 를 받아볼 수 없다. 따라서 여기서 얻은 정보들은 모두 인터넷에서 구하였다. 주 흐름은 Concentric Sky 사이트의 iPad: What’s new in iPhone OS 3.2 [1] 를 따랐고, 추가 정보들을 이어서 나열하였다.
보통 컨텍스트 메뉴라 부르는 기능으로, 마우스 오른쪽 버튼을 눌렀을 때 클릭한 UI 컴포넌트과 밀접하게 관련된 메뉴만 보여주는 것이다. iPhone 에서는 작은 화면때문에 이 기능을 제한하고 있었지만, iPad 는 화면이 넓어 다시 부활시켰다. 사용자가 관심을 보일때, 즉 필요할 때만 나타났다 사라지므로 전체 화면을 깨끗하게 유지할 수 있다. Popover 영역 밖을 클릭하면 사라진다. Popover 는 단순 메뉴뿐 아니라 (다음에 설명할) split view 도 포함할 수 있다.
iPad 의 넓은 화면에 따른 특성이므로 4세대 아이폰에서 활용될 확률은 높지 않다.
iPhone 적용 가능성: low
뷰를 분할해 보여주는 전통적인 방식이다. 예를 들어, email 클라이언트에서 좌측 화면에서는 메일 제목 리스트가 나오고, 우측 화면에서는 메일 내용을 보여주는 식이다. 일정 수준 이상 화면이 넓지 않으면 화면 분할은 오히려 역효과가 난다. Popover 와 같이 iPad 가 화면이 넓어지면서 다시 도입된 기능이라 볼 수 있다.
Popover 와 split view 는 모두 기존 대화면 UI 시스템에서 널리 쓰이던 방식이다. 하지만 애플은 여기서 끝내지 않았다. 애플은 popover 가 split view 를 포함할 수 있도록 했는데, 꾀 참신한 발상이라 볼 수 있다. 아래는 iPad의 기본 메일 클라이언트이다. 가로로 눞히면 좌측의 이미지처럼 split view 형태로 표현되고, 세로로 세우면 split view 가 사라지면서 대신 버튼을 클릭하면 동일한 view 가 popover 로 나타난다. 멋지지 않은가? 약간이나마 iPhone 개발을 해본 감으로는 이 과정에서 개발자가 해줄 것은 없어 보인다. Cocoa Touch 에서 제공하는 controller 가 자동으로 처리해줄 것이다.
또한 아래와 같은 구성도 가능하다.
여기까지는 iPhone 에서는 기대하기 힘든 특성들이다.
지금까지 iPhone 사용자가 사용할 수 있는 키 입력 방식은 모두 애플에서 기본 제공한 조합들 뿐이었다. 일본 사용자들을 위한 Emoji (아래 그림 참조)가 유일한 예외였다.
애플은 이제 이를 더욱 진보시켜 일반에 공개했다. 어플 개발자들은 자신만의 키보드를 만들어 제공할 수 있다. 예를 들어 삼성 핸드폰 사용자들이 좋아하는 천지인 입력기도 쉽게 구현해 넣을 수 있게 되었다 (라이선스 이슈가 있겠지만). 나아가 꼭 키보드 모델에 국한될 필요도 없다. Speech-to-text 나 제스처 기반 입력 인터페이스도 추가할 수 있다. 고유의 필기인식 입력기도 가능하다. Handwriting 키보드의 프로토타입이 3.2 에 포함되어 있다고 하니, 2개월 이내에 충분히 만족스러운 품질에 도달하면 처음부터 내장되어 나올 것이다.
이 기능은 iPhone 에서도 충분히 유용하기 때문에 충분히 기대해볼만 하다.
iPhone 적용 가능성: high
지금까지 제스처 인식은 iPhone 어플 개발자들의 불편사항중 하나였다. 멀티터치를 제공하지만 가장 낮은 수준의 이벤트만을 올려주어서 pinch, long press, drag 등 기본적인 동자도 어플 개발자가 직접 인식 코드를 작성해야만 했다. iPhone OS 가 3.2 로 업그레이드 되면서 애플은 이런 기본 이벤트들을 래핑해서 제공해주기로 결정하였다. Custom input view 와 함께 iPhone OS 기반 제품의 입력 방식을 한 단계 진보시킬 수 있는 특성이다.
4 세대 iPhone 에서 기대할 만한 기능이다.
연결된 케이블을 통해 화면을 외부 디스플레이로 출력할 수 있다. 지원 모드는 케이블에 따라 1024×768, 480p, 576p, 480i, 576i 이다.유사 기능이 전부터 private API 로 노출되었으나, 이제 공식적으로 제공되는 듯 싶다.
디바이스의 메인 윈도우와 독립적인 화면 출력이 가능하므로 활용 폭은 더 크나. 예를 들어 iPad나 iPhone 으로 프로젠테이션도 가능하다. 단, 케이블을 연결해야하는 문제가 있으니 회의실에서 iPad 로 연결해 사용하는 시나리오만이 가장 그럴듯하다. 대화면 게임, 영화 감상 등 훨씬 현실적인 활용 예도 많다.
이 역시 다음 세대 iPhone 에서 기대해본다.
고수준의 텍스트 프로세싱 라이브러리로, iWork 와 같은 고급 사무용 문서 제작 어플리케이션 제작을 가능케 한다. 커스텀 폰트 지원, 텍스트 레이아웃을 지원하며, iPhone 의 cut, copy & paste 위젯까지도 변경할 수 있다. 이 기능을 활용하면 선택된 텍스트를 굵게 변경한다던지, 곧바로 Twitter 나 Facebook 에 공유하는 메뉴를 띄울 수도 있다. 사용자가 입력한 글에 대한 스펠링 체커도 제공된다.
스펠 체킹과 Cut, Copy & Paste 위젯 변경 기능은 iPhone 에서도 충분히 유용할 것으로 보인다.
iPhone 적용 가능성: medium-high
iPad 에서는 어플리케이션들에게 공용 문서 폴더를 제공한다. 이 폴더는 USB 로 Mac/PC 에 연결했을 때 Mac/PC 에서도 바로 볼 수 있다. 즉 USB 드라이브 기능을 겸한다. 이 폴더를 이용해 어플리케이션이 데이터 싱크도 할 수 있고, 자신이 처리하는 파일 타입을 등록해두면, 사용자가 해당 파일을 선택했을 때 그 어플리케이션이 자동으로 실행되도록 만들 수도 있다. 또한 브라우저를 통해 파일 업로드/다운로드도 가능할 듯 싶다.
iPhone 에서도 제공한다면 많은 사람들로부터 환영을 받을 기능이다.
PDF 생성 기능은 다이어트 트래킹, 헬스 어플리케이션 등 현황과 추이를 리포트 형태로 뽑아낼 때 유용하다. 작성한 문서나 웹 컨텐츠 역시 PDF 로 저장하기 좋은 대상들이다.
유용한 기능이긴 하지만, iPhone 처럼 작은 화면에서는 유용성이 많이 떨어질 듯 싶다.
iPhone 적용 가능성: medium
iPad 가 iSight 카메라 없이 소개되었긴 하지만 이 기능을 완전히 배제하진 않은 것으로 보인다. 프레임을 분해해보면 MacBook 용 iSight 카메라가 들어갈 수 있는 공간이 마련되어 있다고 하고, 또 iPhone OS 3.2 에서도 이 기능을 노출하고 있다는 것이 그 반증이다. 만약 카메라가 포함된 iPad 가 등장한다면 비디오 컨퍼런싱에 유용할 수 있다.
반대 의견도 있다. 실제 iPad 에 카메라가 부착되어 있다고 가정하고 사용하는 모습을 시뮬레이션해보면, 사진을 찍건, 컨퍼런싱을 하건 대부분의 경우는 다 어색하다는 것이다. 그래서 일부러 제거한 것이라면 또 다른 가능성을 생각해볼 수 있다. 바로 4세대 iPhone 에 어떤 형태로건 이 기능이 추가될 수 있다는 것이다. 예전에 스크린 패널 뒷면에 카메라를 내장하는 특허도 공개된 적 있지만, 상품화 수준까지 쉽게 구현되리란 상상은 잘 되지 않는다. 가능성이 높진 않아 보인다.
iPad 로부터 네트워크 프로터로 직접 출력이 가능하다. iWork 은 오피스 어플리케이션들을 십분 활용하기 위한 필수 기능중 하나로 판단된다. 봉주즈 기술을 활용하거나 혹은 직접 네트워크 프린터 세팅을 해주면 모바일 기기에서 바로바로 출력이 된다. 편리한 능력이라 할 수 있다.
상대적으로 iPhone 에서의 유용성은 많이 떨어지지만, 외부에서 받은 PDF 나 공용 폴더의 문서, 또는 메일아나 웹 컨텐츠를 즉각 출력할 수 있다는 것만으로도 가치가 있다. 일부러 제한할 필요는 없어보인다.
잡스는 다음 iPhone 은 A+ 업데이트가 될 것이라 이야기했다 한다. 하드웨어적인 개선도 있을 수 있고, 소프트웨어적 개선 수준도 지금까지 노출된 것들보다 훨씬 뛰어날 수도 있다. 지금까지의 패턴을 보면, 3~4월 즈음에 iPhone OS/SDK 4.0 이 beta 로 공개될 것이다. 그 때가 되면 소프트웨어적인 개선은 대부분 공개될 것이고, 나머지는 하드웨어만 남는다. 그리고 6~7월이면 모든 것이 드러날 것이다. 그 전까지는 Android, webOS, Symbian, bada 등 경쟁 제품들의 깜짝쇼가 있을 지 기대해보자.
‘쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.
‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.
정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.
시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.
혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.
이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.
고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.
이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.
직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.
또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.
이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.
결론?
조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]
[updated]
사례를 몇 가지 추가해보기로 하였다.
작년에 iPhone Application Programming 이라는 제목의 강의를 iTunes U 를 통해 공개해 화제가 되었던 미 Stanford 대학에서 새로운 업그레이드 버전의 강의[1]를 다시 시작했다. 물론 이번에도 iTunes U 를 통해 강의 동영상[2]을 볼 수 있다.
iPhone Application Development. 시작 부분은 작년 강의와 비슷하지만, 후반부로 가면서 최신 iPhone OS 3.1 을 포함하여 작년에 다루지 않았던 내용들을 제법 커버하고 있다. 또한 타 언어 청강자들을 위한 배려로 자막을 포함시켰다. 대략적인 강의 계획[3]은 아래 정도..
This is our preliminary syllabus. Details may change as we go along. 1/5 – Intro to Mac OS X, Cocoa Touch, Objective-C and Tools 1/7 – Using Objective-C, Foundation objects 1/12 – Custom classes, memory management, properties 1/14 – MVC, Interface Builder, Controls & target-action 1/19 – Views, Animation, Open GL 1/21 – View Controllers 1/26 – Navigation Controllers, Tab Bar Controllers, Searching 1/28 – Table Views 2/2 – Dealing with Data: User defaults/Settings, CoreData, JSON & XML, Push 2/4 – Threading, Notifications, KVC 2/9 – Text, Responders, Modal Views 2/11 – Address Book 2/16 – WebViews, MapKit 2/18 – Multitouch, Gestures 2/23 – Device APIs: Location, Accelerometer, Compass, Battery life 2/25 – Audio playback, Video playback, Image/Video Picker, iPod Media Access 3/2 – Bonjour, streams, networking, GameKit 3/4 – Unit testing, Objective-C fun, localization 3/9 – TBD 3/11 – TBD
This is our preliminary syllabus. Details may change as we go along.
1/5 – Intro to Mac OS X, Cocoa Touch, Objective-C and Tools 1/7 – Using Objective-C, Foundation objects
1/12 – Custom classes, memory management, properties 1/14 – MVC, Interface Builder, Controls & target-action
1/19 – Views, Animation, Open GL 1/21 – View Controllers
1/26 – Navigation Controllers, Tab Bar Controllers, Searching 1/28 – Table Views
2/2 – Dealing with Data: User defaults/Settings, CoreData, JSON & XML, Push 2/4 – Threading, Notifications, KVC
2/9 – Text, Responders, Modal Views 2/11 – Address Book
2/16 – WebViews, MapKit 2/18 – Multitouch, Gestures
2/23 – Device APIs: Location, Accelerometer, Compass, Battery life 2/25 – Audio playback, Video playback, Image/Video Picker, iPod Media Access
3/2 – Bonjour, streams, networking, GameKit 3/4 – Unit testing, Objective-C fun, localization
3/9 – TBD 3/11 – TBD
빠르면 이달 말, 늦어도 강의가 끝날 즈음엔 iPhone OS 4.0 API SDK 가 공개될 것이다. 이 강의를 통해 3.x 까지 기본 개념들을 익혀둔 후 4.0으로 넘어가는 것도 괜찮을 듯 싶다.
작년 강의 때는 진도에 맞춰 숙제도 해보면서 많은 것을 배웠다. 회사에서 비슷한 과제를 진행하는데.. 우리의 것보다 너무도 우월하여 다른 팀원들도 시간내서 꼭 봐주길 촉구했으나 관심도 보이지 않던 씁씁한 기억이.. -_-
p.s. Stanford 강의만큼 녹화/편집이 깔끔하진 못하지만, 독일의 RWTH Aachen 대학에서도 iPhone Application Programming 강의를 진행중이다[4].
우리는 창의력과 혁신을 강조하는 시대에 살고 있다. 소프트웨어 개발도 당연히 그 중심에 서 있다. 하지만 우리의 소프트웨어 개발 문화는 창의력을 심히 제한하는 방식으로 굳어져 있다.
일반적으로 우수한 편에 속하는 지적 능력을 가지고 있고, 새로운 것을 만들어내는 것을 즐기는 소프트웨어 개발자들. 그들은 회사에서 어떤 대우를 받고 있나. 조직이 조금만 커져도 기획은 별도의 부서에서 진행하고, 소프트웨어 개발은 몇몇 관리자들이 이끌게 된다. 소프트웨어 개발자들은 창의력을 발휘하기 보다는 시키는 일만 열심히 해야 하는 위치에 놓이게 된다. 코드를 찍어내고 타의에의해 변경된 요구사항들 때문에 수정/테스트를 반복하는 나날을 보내며 발언권은 점점 작아진다.
기술 개발을 중시하는 몇몇 소수 기업을 제외하고는 대부분(대기업)의 윗사람들은 아직까지 소프트웨어 개발자들을 단순 노동자 취급하고 있다. 이를 빗대어 나는 ‘소프트웨어 제조업’ 에 종사하고 있다고 얘기하곤 한다.
반면, 개발자들의 능력을 믿고 그들에게 스스로 혁신을 일으킬 수 있도록 지원해주는 대표적인 기업들로 Google, Apple, Rally Software 등을 들 수 있다.
Google 은 20% 제도로 유명하다[1]. 자신에게 주어진 시간 중 20% 정도를 주업무가 아닌 다른 일에 할애하도록 권장하는 제도로, 다양한 형태로 응용 가능하다. 매일매일 20%의 시간을 다른 일에 투자하는 것은 대부분의 경우는 현실적이지 않다. 프로젝트 마감이 코앞인데 다른 일에 정신 팔기도 힘들고, 하루 1~2시간씩 해서는 진도도 나가지 않기 때문이다. 대신 그들은 1주일에 하루, 1달에 1주, 혹은 6개월에 1달, workaholic 이라면 주말을 이용 등등.. 자유롭게 변형해서 일한다. 과제가 바쁠때는 열심히 그 일에 매달렸다가 한가할 타임에 그동안 못 쓴 20%를 쓰는 식이다.
20%의 시간에는 어떤 일을 할까? 이것도 아주 자유롭다. 전혀 새로운 과제를 수행할 수도 있고, 관심있는 다른 팀 과제를 지원할 수도 있고, 자신의 주 과제를 진행하면서 불편했던 부분을 자동화하거나 유용한 유틸리티를 만들거나, 최적화/리펙토링을 할 수도 있고, gmail/chrome browser 등에 유용한 플러그인을 만들어넣을 수도 있다. 공부를 할 수도 있다.
이렇게 해서 나온 결과들은 팀의 개발 생산성을 향상시키고, 제품의 품질을 좋게하고, 새로운 것을 배우게 만들고, 운이 좋으면 구글의 미래를 이끌어갈 제품으로 거듭날 수도 있다. Gmail, Google News, Google Talk, Orkut, Google Sky [2], Go programming language [3] 등은 모두 20% 시간에 시작된 프로젝트들이다.
Apple 의 경우 1년에 1달 가량 자신이 원하는 일을 할 수 있게 해준다지만.. 자세한 내용은 잘 알려지지 않았다[4].
마지막으로 Rally 의 경우 8주의 개발 사이클 중 마지막 1주는 회사의 미션과 관련된 일이라면 어떤 것이든 할 수 있는 권한이 주어진다[5]. 기간이 일정하게 주어져 있기 때문에 융통성이 조금 부족하지 않을까 우려되긴 하지만 한 숨을 돌리며 자신들의 과거를 뒤돌아볼 수 있다는 점만으로도 확실한 장점이 될 것이다.
다시 암울한 우리의 이야기로 돌아와보자.
나는 현 회사의 윗사람으로부터 ‘관지자가 할 일은 개발자가 놀지 않게 하는 것’ 이란 얘기를 들었다. 여기서 논다는 것은 ‘주업무와 직접적으로 관련 없는 모든 일’을 지칭한다. 내게는 ‘공장 가동을 멈추지 말 것’ 정도로 들렸다. 공식적인 주업무 외에는 회사에 기여하지 못하는 것으로 여겨기기 때문에 일거리를 만들어서라도 주지 않으면 능력 없는 관리자가 되는 것이다.
개발자 입장에서도 마찬가지다. 좋은 아이디어가 있더라도 side job 은 업적으로 인정받기 어렵다. 놀고 있는 것으로 받아들여지므로 드러내놓고 할 수도 없다. 결국 몰래 하거나 개인 시간을 희생해서 짬짬이 하게 되고, 인정받지 못하기 때문에 의욕이 생길리 만무하다.
고급 인력인 개발자들의 좋은 두뇌를 활용하지 못하고, 반대로 창의성을 저하시키는 이런 문화는 하루 빨리 고쳐져야 한다. 말로만 소프트웨어가 중요하다고 하지 말고, 소프트웨어 개발의 특성과 개발자들을 이해하려는 노력이 절실하다.
두서 없지만 이 글은 이쯤에서 마무리하기로 하고, 유사 주제로 작성하고 있는 글이 있으니 그 쪽에서 정리를 시도해보기로 하겠다. ^^
한 4년쯤 전에 정리를 시작했던 주제로, 지인 몇 명과 논문으로 써볼까 기고를 할까 고민하다 제 때 빛을 보지 못했다. 실례를 찾아 보강하는 것이 가장 큰 숙제였는데, 불행히도 그 후 테스트 관련 업무를 접할 기회가 없었어서 기고까지는 하지 못했다.
In other to make software testable, designer should follow some rules. If you are interested in software design, some of them must be familiar to you. That’s because they are rules for improving software ‘design‘ in testability perspective. Lets look into the rules one by one.
Software which satisfies these rules can be called testable. However, it is very hard to measure quantitatively how well the rules are reflected. I’ll remain this issue for other dedicated articles.
(in Korean)
테스트 가능한 소프트웨어를 만들기 위해서는, 설계자는 몇 가지 규칙을 따라야 한다. 소프트웨어 설계에 관심있는 사람이라면, 친숙한 이름의 규칙들을 찾을 수 있을 것이다. 이유인 즉, 이 규칙들은 테스트의 관점에서 소프트웨어의 ‘설계‘를 향상시키기 위한 지침이기 때문이다. 그럼 그 규칙들을 하나씩 살펴보도록 하자.
이상의 규칙들이 충족된 소프트웨어라면 ‘테스트할 수 있다’고 얘기할 수 있을 것이다. 단, 이런 규칙들이 얼마나 잘 반영되었는지를 정량적으로 측정하는데는 분명한 한계가 있다. 측정 이슈는 주제의 범위를 벗어나므로 본 글에서는 더 자세히 다루지 않을 것이다.
(Read the full article)
Spring Framework 관련 한글책[1]을 보다가 Dependency Injection(DI) 의 번역에 대한 역자주에서 생각해볼만한 것이 있어 보충 설명 겸, 잠시 끄적여본다. DI 의 개념이 아직 모호한 사람이라면 이 글을 먼저 읽어본 후 참조한 wikipedia[2] 의 글을 보면 전체적인 윤곽을 잡는데 도움이 될 것이다.
역자주: 종속객체 주입, 즉 DI(dependency injection)는 스프링에서 가장 기본이 되면서도 매우 중요한 의미를 갖는다. 기존에 가장 많이 쓰이던 번역은 ‘의존성 주입’이었다. 그러나 역자가 보기에 이 번역은 ‘없는 의존성을 만들어 주입한다’는 오해를 일으키고, 이 때문에 DI의 이해가 어려웠다고 생각한다. DI 는 없는 의존성을 주입하는 것이 아니라 의존성은 이미 존재하되, 실제 객체가 필요로 하는 종속객체를 주입하는 것을 의미한다. 따라서 ‘의존성 주입’보다 뜻이 명확하도록 ‘종속객체 주입’이라고 번역했다. .. (후략)
일단.. 이 역자가 잘 봤다고 말하고 싶다. DI 에서 dependency 를 의존성으로 번역한 것은 확실히 잘못된 것이다. UML, OOAD 등 지금까지 IT 기술 관련 대부분의 상황에서는 모듈간 관계를 명시하기 위해 dependency 라는 용어를 사용해왔기 때문에 여기서도 습관적으로 의존성이라는 단어를 선택했으리라 생각한다. 하지만 단어는 문맥에 따라 여러 가지 의미를 가지고 있음을 잊어서는 안된다.
DI 을 직역하더라도 의존성 주입은 아니다. 오히려 위 역자가 사용한 종속객체 주입이 더욱 적절하다. 약간 아쉬운게 있다면 DI 는 object 세상에 국한되지 않기 때문에 ‘객체’ 라는 말은 여전히 논란의 소지가 있다는 점 정도. 범위를 제한하지 않으려면 module 정도의 추상적인 용어를 사용할 수 있겠지만, object 라는 용어도 꼭 OOP 에서 말하는 object 로 제한되는 것은 아니니 상관 없을 듯 하다.
그럼 다시.. 왜 직역을 했는데도 종속성은 틀린 것일까? 이는 DI 패턴의 구조[2]를 살펴보면 쉽게 이해가 된다. DI 패턴은 세 개의 요소로 구성된다. 적절한 한글 대용어를 찾기 어려워 대강 번역해보면 이렇다.
이 패턴은 최소 3개의 구성 요소로 이루어진다: dependent와 그의 dependencies, 그리고 injector (혹은 provider, container). Dependent 는 컴퓨터 프로그램에서 작업(task)을 수행해야할 소비자(consumer)이다. 작업 완료를 위해선 특정 부작업들(sub-tasks)을 수행하는 다양한 서비스(dependencies)들을 활용해야 한다. 마지막으로 Injector 는 dependent 와 그에 필요한 dependency 들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.
위 설명에서와 같이 DI 의 dependency 는 객체간의 관계 속성을 의미하는 것이 아니라 서비스를 제공해주는 ‘실체’를 가리킨다. 그 실체를 (의미 그대로) dependent 에서 주입시켜주는 것이다. 위 역자의 용어에 맞추어보면 대략 이렇게 되지 않을까 싶다.
이 용어들을 적용해 다시 번역해보면 아래처럼 되겠다. 깔끔하려나.. ^^
이 패턴은 최소 3개의 구성 요소로 이루어진다: 의존 객체(dependent)와 그의 종속 객체들(dependencies), 그리고 주입자(injector, provider, or container). 의존 객체는 컴퓨터 프로그램에서 작업을 수행해야할 소비자이다. 작업 완료를 위해선 특정 부작업들을 수행하는 다양한 서비스(종속객체)들을 활용해야 한다. 마지막으로 주입자는 의존객체와 그에 필요한 종속객체들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.
아이폰의 열풍이 계속되면서 또 다른 아이폰 프로그래밍 공개 강의[1]가 개설되었다.
이미 Stanford 의 강의[2]를 (아주 감명깊게) 들은 바 있어서 신섬함은 좀 부족하지만, 시간차가 있는만큼 새로운 정보도 얻을 수 있을 것 같아 이번 강의도 쭉 지켜보려 한다.
두 강의 모두 iTunes U [3] 를 통해 서비스되고 있다. iTunes U 에는 여러 대학들이 참여하여 품질 높은 강의/교육 컨텐츠들을 쏟아붇고 있으니 꼭 한 번 둘러보길 권한다. iPhone/iPod touch 없이도 PC 에서 iTunes 소프트웨어만 설치하면 모든 자료를 무료로 이용할 수 있다.
