티스토리 툴바


크리에이티브 커먼즈 라이선스
Creative Commons License





저는 작년 말에
Boardman이라는 앱을 앱스토어에 올렸습니다. 이 앱은 화이트보드 사진을 찍어주는 앱입니다. 그냥 사진을 찍는 거면 카메라 앱이 있는데 왜 만드나 하실 겁니다. 바로 아래 그림과 같은 효과를 내주는 앱이지요.



이 앱을 만들게 된 동기는 이렇습니다. 보통 그림을 그려서 설명하고 설계하는 software engineer는 화이트보드를 끼고 살지요, 저 역시 그랬습니다. 그런데 문제는 이것이 기록으로 남아서 정리가 되질 않기 때문이었습니다.  당시 제가 일하던 직장에 전자칠판이 몇개 있긴 했지만 이것이 늘 제가 쓸 수는 없는 상황이었거든요.

그러다가 camera calibration으로 유명한 Zhengyu Zhang의 논문을 발견했습니다. 한번 짜보자 싶어서 가볍게 python script상에서 open computer vision library를 이용해서 한번 간단하게 작성을 해봤습니다.결과가 슬슬 나오자 가끔씩 디카로 찍어서 변환을 하곤 했죠. 이 때 까지는 오로지 Python script였습니다. 이 때쯤 솔직히 핸드폰에 넣어볼까 말까 하는 생각을 했지요.


그러던 중, 최초의 아이폰 발표를 온라인으로 보고 '이거다'했습니다. 잡스옹의 손에 있는 저 작은 물건이 뭔가 대단한 일을 만들것이다라는 생각을 했습니다. 아니나 다를까 드디어 애플말고 개인이 앱을 올릴 수 있는 앱스토어가 만들어졌습니다. 하지만 한국에서 아이폰을 쓸수가 없어서 손을 빨다가 드디어 맥을 사서 공부를 시작했습니다. 그러나 이때까지도 시뮬레이터만 눌러보는 상황이었습니다.


드디어 아이폰이 출시 되자 바로 구매해서 실제 장비에 올라가던 프로그램을 보니 기뻤습니다. 이제 모든 준비는 끝이 났습니다. 그러나 바쁜 회사 일정에 쫓기다보니 생각보다 진도가 안나갔습니다. 조바심만 늘어갔었지요. 그러다 Rework의 ‘가르침'인 ‘초기에는 세부사항을 잊어라'라는 말을 가슴에 품고 온갖 쓸데 없는 기능을 최대한 없앴습니다.

처음 아이콘을 디자인하기 위해  손놨던 타블릿도 꺼내고, Drawing tool도 오래간만에 써봤습니다. 이러한 과정들 하나하나가 매우 즐겁고 보람된 과정이었지요. 마케팅 전략도 세워보고 실제 물건이 팔리는 것을 보고 소름도 돋아봤습니다. 

자, 역사(?)는 이만큼 이야기 하고 실제 제가 이 제품을 만들고 팔아보고 나서 느낀 것들을 한번 이야기 해보고자 합니다. 이제는 어느정도 이 제품의 갈 길을 결정을 할 때가 되었다는 생각에서 적어보도록 하겠습니다.


어떤 일이 있었는가? 

처음 이 작업을 하기 위해 기술적으로는 앱 개발이 어려웠습니다.  그러나 진짜 문제는 다른 일들이었지요. 실제 팔만한 제품을 만들다 보니 design, marketing등 혼자 감당하기 어려운 요소들이 나타나기 시작했습니다.

Design은 User eXperience를 포함하는 과정의 디자인을 해야 했는데 이것을 혼자 감당하다보니 어려움이 있었습니다. Paper prototyping등도 해보았지만 이것을 구현할만한 실력도 아직 안된 것을 발견했습니다.

Marketing의 경우 SNS와 지인들을 통해 진행했는데 그리 좋은 성적을 보여주지 않았습니다. 실제 처음 가격은 1.99$였다가  진행하다가 판매율량 저조해서 잠시 무료로 풀었는데 매우 판매량이 늘었습니다. 그래서 다시 0.99$로 가니 판매량은 떨어졌고 지금은 iAD를 붙였습니다. 하지만 한개의 앱에 광고를 붙인다고, 특히 iAD, 그렇게 많은 수익을 주지 못했습니다.

고객지원을 하기 위해 wordpress에 blog를 열었습니다. ( http://ideabywindow.wordpress.com/ ) 마치 분위기는 어디 영어권에서 좀 컨설팅좀 하시는 분(?)처럼 사기를 치는 분위기였지만 뭐 빈 깡통인건 조금만 보면 티가 나죠. 하지만 의외로 어떤 일을 하기 위해 거대한 호스팅을 하거나 도메인을 살 필요가 없다는 것을 확실하게 느꼈습니다.

하지만 이 앱이 보여준 가장 큰 소득은 저에게 iOS개발 능력이 있다는 증거(?)가 되었습니다. 실제 이직에도 도움이 되었지요. 그런면에서는 매우 좋은 제품이 된 것 같기도 합니다. 


어떻게 느끼는가?

무려 거의 4년에 걸쳐서 좌충우돌을 했지만 정작 가장 큰 변화는 마지막 3~4개월 내에 일어났습니다. 그 당시 다니던 회사가 어려워짐으로 무언가 내가 이 상황을 타개할 것이 필요하다고 느꼈습니다. 무언가 절박함이 생기니 밤에 늦게 까지 무언가 하게 되더군요. 그 때 저 역시 ‘긴급성 중독'환자라고 느꼈습니다.

도와줄 사람을 반드시 찾자’라는 것을 이 때 깨달았습니다. 비록 1인 기업처럼 시작을 하더라도 기본적으로 일을 따오는게 아니라 상품을 만들어 내놓으려면 1사람으로는 절대 안되었습니다. 최소한 Designer, Marketer가 한명씩은 필요합니다. Marketer가 필요한 가장 큰 이유는 Engineer나 Designer가 못 보는 부분을 보는데 제일 뛰어나고요 최소 세 사람의 관점이 모이려면 그만큼 균형이 맞을 수 밖에 없겠더라고요.

그래도 가보니 알겠더라고요, 이 모든 일을. 제가 뭔가 하나라도 올려보지 않았다면 앱스토어의 판매 전략세우기, iAD설정 때문에 애플과 메일로 싸우기, 어설프지만 고객 응대용 웹페이지 만들기, SNS로 홍보하기등 하나도 못해보고 그냥 ‘썰'만 풀었겠지요.

그리고 이 제품은 이른바 ‘Computational photography’의 가능성을 보여준 앱이었습니다. 단순한 이미지 처리가 아니라  매우 복잡한 수준의 첨단 Computer vision 알고리즘을 통해 향상된 영상을 보여주는 것으로서, computer vision 연구자들이 자신의 연구를 어떻게 세상에 보여줘야 하는 지를 알아보는 좋은 시도가 되었다 생각합니다. 


어떤 교훈을 얻었는가?

장기적으로 2년 내내 update한다 생각하고 1달 단위로 꾸준히 upgrade를 하는 것이 더 도움이 된다는 사실을 알았습니다. 한 술에 배부를 수도 없고 실제 꾸준한 사용자들의 경험 축적이 시행착오를 줄여줄 수 있기 때문이지요.

절대 큰 돈 벌기 위해 앱을 만드는 일은 무리였습니다. 많은 기능들을 개발한다는 것은 그만큼 많은 비용을 얻는 다는 것이지요. 1인 기업을  운영하는 입장에서는 거의 불가능한 일입니다. 그러나 저는 이미 조바심이 매우 심해져서 망상에 빠지기까지 했습니다. 이젠 빠져나왔어요. ^^

최근에 AARRR과 같은 matric을 통해서 실제 수정사항이 어떻게 매출이나 사용자 증가에 영향을 미치는지 테스트를 하는 법을 배웠습니다. 이걸 미리 알았다면 한번 시도해보는건데 하는 생각을 합니다.


미래에 해볼 것은?

몇 가지 생각해보면 다음과 같습니다. 

  • 동료 확보: 혼자는 너무 힘들어요....
  • Storyboard를 통해 다양한 UI를 만들어 보기
  • Algorithm향상 시키기
  • 추천 들어왔던 여러 기능들 미리 Prototype만들어 테스트 해보기
  • AARRR등의 분석을 통해 실제 매출로 이어지는 요소는 무엇인지  실험해보고 이를 꾸준히 이어가기


약 3개월 후에는 무슨 일이 일어날까?

5가지 해볼 일들 중에 단 1개만 시도해서 결론을 봤으면 합니다. 이건 3개월 후에 적어야겠죠? ^^


저작자 표시

Posted by 유진호
크리에이티브 커먼즈 라이선스
Creative Commons License

우리는 늘 고객이 우리의 개발에 참여해야 한다라고 말합니다. 그러나 실제 우리는 어떻게 그들을 참여 시키고 있습니까?  단순히 매주 한번씩 고객과 만나는 것인가요? 아니면 제품 출시 직전에 테스트를 통해 고객과 만나나요?

최근 The lean startup으로 유명한 Eric Rise는  Nordstrom이란 Team이 벌인 Flash build라는 개발 방식에 대해 글을 올렸습니다.  이들의 실험은 지금 무언가 마땅한 제품을 기획을 해내지 못하고 있는 회사나 조직이 반드시 해보기를 권하는 일입니다.

먼저 이들의 프로젝트는 ‘1주일간 선글라스 가게에서 사용할 앱 만들기'입니다. 이게 어떻게 가능할까요?  한번 생각해보세요, 여러분이라면 어떻게 할지.



이들의 방법은 이랬습니다. '우리 모두 선글라스 가게로 가자’. 개발팀, UX Designer등 모든 팀원들이 다들 선글라스 가게로 갔습니다. 그리고 한쪽 구석에 책상가져오고 Macintosh를 설치했습니다. 그리고 선글라스 가게에 오는 손님들에게 물어봤습니다. 그러면서 Prototype을 만들어갔습니다. 실제 구동하는 소프트웨어도 만들고 Paper prototype도 고객에게 보여주면서 수정해갔습니다.
 

결과는 아주 놀라웠습니다. 이들이 만들어낸 App자체보다는 이렇게 하면서 새롭게 알아난 것들이 아주 놀라웠습니다.

- 편광 선글라스 때문에 Portrait에서 Landscape로 바꿨다.
: 원래 이 프로그램은 Portrait방식으로 개발되었었습니다. 손거울처럼 iPad를 쓰게 하자는 거였기 때문입니다. 하지만 선글라스 중에 편광 선글라스가 있습니다. 이것들은 가로 방향으로 아주 촘촘한 보이지 않는 선들을 코팅해서 그려놓은 것들인데 iPad의 액정 방식 때문인지 Portrait로 두면 아예 화면이 안보이는 것입니다. Nordstorm은 이 사실을 약 3일째 될 때 알았습니다. 급하게 수정이 들어갔습니다. 이건 직접 고객이 선글라스 끼고 보지 않았다면 AppStore에서 다운로드가 시작 되고서야 알았겠지요.

-단순 비교에서 시작했지만 줌기능을 넣어 두 장의 영상을 서로 비교할 수 있게 해줬다.
 
: 이런 UX의 변화는 보통은 바로 얻기 힘듭니다. 고객이 참여해야만 얻을 수 있는 것입니다. 첨에는 단순히 비교만으로도 충분해 보였지만 서서히 사용자가 참여하면서 하나하나 필요한 것이 보이는 법이지요.

- 1주일의 Time Boxing
: 생각해 보세요, 만약에 전체 프로젝트를 이렇게 한다고 하면 매우 많은 에너지를 써야 해서 지칠것입니다. 하지만 1주일만 이렇게 한다면 집중할 수 있습니다.

자세한 기사는 여기를 참고해보세요. 여기서 제가 얻은 교훈은 이렇습니다.
 

- 지금 고객이 있는 곳에 개발팀을 모두 데리고 가서 관찰하자.
 
- 그 자리에서 고객에게 보여줄 수 있는 것이 있다면 보여주고 물어보자.
- 짧게, 그러나 자주해야 한다.
정말 우리가 지금 이 순간 무엇을 해야 할지 모르는 팀이라면 이렇게 해보시기 바랍니다. 고객을 관찰하고 그들에게 질문하다 보면 많은 것을 얻을 수 있을 것입니다. 다음주 저희의 할 일을 알게 되었네요.
Eric Ries는 아래와 같이 흥미로운 것들을 찾아냈습니다.
  • 1주일 단위 반복. 막판에 가서는 이 팀은 1주일 끝에서 끝마다 완전히 새로운 제품을 만들어 냈다. 

  • 달려가면서 스스로를 되돌아 보기를 계속했다. 

  • 간단하고 빠르고 실험적이다. 보통 iOS개발하면서 Rapid development 방식의 기술이 적용되기 힘들다. 그러나 이 팀은 2대의 iPad를 이용해서도 이를 극복했다. App이 개발되는 동안 Sales team은 하나의 iPad를 썼고 다른 팀은 다른 것을 썼다. 매번 개발이 끝날 때마다 Sales team은 이를 바꿔치기 했다. Paper prototype을 할 때도 똑같이. 
     
p.s: 좋은 정보를 물어주신 스승님 감사합니다. ^^ 후훗~  
저작자 표시
Posted by 유진호
크리에이티브 커먼즈 라이선스
Creative Commons License

Joseph Yoder 소개



우리나라에서는 정말 만나기 힘든 ‘Architect’이신 Joseph Yoder가 한국에 다른 일정으로 오셨습니다. 이분의 주무기는 Refactoring과 Adaptive Object Model, Design Pattern입니다.
http://www.joeyoder.com/ 에 자세한 이야기가 나와 있습니다만  다양한 형태의 PLoP  Conference를 주관하시고 있고 소프트웨어 아키텍쳐, 설계, 구현과 같은 다양한 소프트웨어 개발에 대한 훈련, 멘토링과 컨설팅을 하고 계십니다.


The Big ball of mud

특별히 이번에 진행된  Conference에서는 TDD와 Refactoring에 대한 이야기를 했습니다. 왜 소프트웨어는 가면 갈수록 점점 엉터리 코드로 엉망이 되어 가는걸까요? The big ball of mud pattern이란 이런 현상을 설명하는 좋은 예입니다. 동의어로 스파게티 코드가 있지요. 그런데 Joseph은 이러한 것이 반드시 나쁜 것이냐 라는 질문을 합니다. 이것은  “Worse is better” 라는 Gabriel이 1991년에 낸 생각과 유사합니다.  이 뜻은  “일찍 출시해서 시장이 최종 제품을 설계하는데 도움을 주게 하라"는 뜻인데 실제 오픈소스가 이런 방식으로 발전해왔지요.  

즉 완벽한 소프트웨어를 만들기 위해 우리 모두 노력을 하지만 소프트웨어의 변화는 결국 진흙덩어리를 만들게 됩니다. 이것이 완벽히 없어야만 좋은 소프트웨어가 되는 것은 아니지만 이것을 계속 두게 되면 ‘기술의 빚'을 지게 되는 것이지요. 이것을 해결하는 방법으로 꾸준한 Refactoring, TDD등의 방법을 제안하고 있습니다.

그리고 이러한 소프트웨어의 변화는 계층에 따라 변하는 속도가 다르게 됩니다.  아래 순서대로 위쪽에 있는 것일 수록 늦게 변하고 아래로 갈수록 빠르게 변할 수 있다고 Footer와 Joseph은 주장을 합니다.
  • The platform
  • Infrastructure
  • Data schema
  • Standard frameworks and components
  • Abstract classes and interfaces
  • Classes
  • Code Faster
  • Data


Mud로 대표되는 소프트웨어의 문제점들에 대해 Joseph은 다음과 같은 주장을 합니다.
  • 우리는 코드를 개량하고 복구하거나 개조해서 진흙덩어리들을 치워버릴 수 있다. (We can gentrify, rehabilitate, or make-over code helping clean up the mud.)

  • 어떠한 패턴이나 프레임워크, 부분모듈, 그리고 객체가 오히려 진흙덩어리를 만들어 냈 다.  애자일 개발방식은 이를 해결하는데 도움을 주었다.  (Even some patterns, framework,  components, and objects works, helped with mud. Agile has helped some.)


Refactoring & TDD

이날  Joseph 굉장히 Refactoring에 대해 많은 시간을 가지고  소개했습니다. Refactoring의 정의, 종류, 위험도에 따른 분류까지 했습니다. 무엇보다 매일 그리고 점진적으로 Refactoring을 해나가야 한다라는 주장을 했습니다. 그리고 본인은 따로 Refactoring시간을 두지 않고 자연스럽게 하다보면 Refactoring을 하고 있더라라는 이야기를 했습니다.


그리고 이러한 Refactoring을 위해 Test를 꼭 하라면서 Testing이 Agile이 있기 전부터 Refactoring의 핵심원리라 할 만큼 강조했습니다. 저 역시 이 부분에 대해서는 정말 공감합니다. 그리고 TDD와 Refactoring이 서로 겹치는 부분이 있다 했습니다. 무엇보다 Test case를 먼저 안 썼다고 비난하지 말라 하시며 오히려 실제 구현 작성 하고나서  Test code를 작성하고 이것이 실패하면 구현을 수정하는 방식으로 일해도 된다했습니다. 저는 이 부분이 TDD관련되서 과거에 많이 논쟁이 되었던 것을 기억해보면 진짜 전문가는 ‘가지는 쳐내고 맥을 제대로 집는다'는 느낌을 가지게 되었습니다.



Refactoring & Design pattern

그럼 이러한 Refactoring을 할 때 구조를 바꿔야 하는 일도 있을 것입니다. Joseph 이때 Design pattern을 살펴보라고 했습니다.  Design pattern이란 것이 실제 소프트웨어를 설계하면서 나온 일종의 공식이고 다른 사람들의 경험이 녹아 있기 때문이지요. 즉 Refactoring이 다소 복잡한 구조라면 이를 풀어나가는 방법을 생각하기 위해 Pattern catalogue같은 목록을 보면서 어찌 풀지 고민해 보라는 주장이었습니다. 물론 지나친 Pattern광신은 경계했고요. 그 후 PLoP에서 어떻게 패턴이 만들어지는지에 대해 소개해주었습니다. (Writer’s workshop같은 것들 )



Adaptive Object Model


추가적으로 AOP(
http://adaptiveobjectmodel.com/ )에 대한 설명도 해주셨습니다. 이것도 Joseph 작품이거든요. 간단히 설명하자면 속성과 관계(Attribute and Relationship)에 대한 것들 / 그리고 행동(Behavior)을 객체로 분리해서 구현 하자는것입니다. 이렇게 해서 최대한 유연한 유로운 객체구조를 만들자라는것이 목적입니다.

이러한 설계가 나온 이유는 실제 현장에서 자주 구조를 재 설계해야 하는 일이 벌어지는 거죠. 예컨데 보험회사의 시스템의 경우 상품에 대한 구조가 바뀌는 것에 따라 이를 처리해주는 소프트웨어도 변해야 하는데 이를 단순히 상속기반의 설계로는 감당할 수 없습니다.  실제 Joseph이 이러한 설계를 생각해 낸 것도 금융 쪽 소프트웨어에 대한 설계를 하다 나온 것이라 했던것으로 기억합니다. (그렇게 들은 것 같은데 녹취록을 다시 들어보니 그런 말이 없어요.. T_T...) 자세한 구현은 http://www.codeproject.com/KB/architecture/AOMTypeObject.aspx 같은 것을 보시면 좋을 것입니다.

특히 이 분이 이 패턴을 설명하면서 ‘Over engineering’을 이야기 했는데, 이 패턴을 반드시 적용해야 하는 곳인지 잘 생각해서 하라는 의미였습니다. 유연한만큼 품이 많이 드는 패턴이기 때문입니다. ‘균형'을 잡으라는 뜻이죠.
 


재미있던 Q&A 시간


앞선 강의도 1시간을 좀 넘겼는데 이후 질문/답변은 무려 3시간을 지속했습니다. 배고프고 힘들어서 매실에이드와 녹차만 들이켰습니다... 많은 질문 답변 중에 몇개 골라서 적당히 요약해서 적어봅니다.

저는 개발할 때 Refactoring할 시간이 없었는데...
: 지금 빚(Technical depth)을 갚을 것인지 나중에 갚을 것인지 문제입니다. 이것은 매일매일 되어야 하는 것입니다. 작은 것부터 해보시길 권합니다.

어떤 분들은 자신의 코드에 자신의 자아를 투영해서 심지어는 쓰레기임에도 남이 치우는 것을 싫어합니다. 이런 분들을 어떻게 다루거나 피해야 합니까?
: 다른 분의 코드라도 코드를 정리해줘서 깨끗하게 유지하는 것은 좋은 일입니다. XP에서는 남의 코드, 내 코드의 구분하지 말라고 가르치지요. 혼자 할 때야 혼자의 코드이지만 팀을 이뤄서 일한다는 것은 내가 작성했어도 팀의 코드라는 뜻입니다. 함께 극복해야죠. 페어프로그래밍 방식을 도입해 보십시오. 각 부분(핵심, GUI등)팀들이 서로 돌아가면서 코드를 보게 하세요.

이런 상황에서 팀 리더가 아니라면 어떻게 해야 할까요?
: 나쁜 방법은 코드리뷰를 할 때 , ‘이게 문제네요, 이게 뭐에요~’라면서 서로 놀리는 것입니다. 의외로 많이 이렇게 합니다. 이 문제에 대해 상대방을 배려하면서 ‘내가 이 부분이 이해가 안되는데 도와 줄 수 있어요?’라고 질문할 수 있어야 합니다. ( 저는 비폭력대화나 코칭을 배워보시길 추천합니다. )

타인의 코드를 Refactoring할 때 어떻게 진행하시나요?
: 타인의 코드를 한번에 이해하기는 힘듭니다. 이럴 때 기존에 있는 큰 코드를 몇 개의 Procedure로 분해하고 이 Procedure의 의미를 물어보고 이름을 짓는 과정에서 자연스럽게 이해하게 됩니다. 마법은 없지요. 심지어는 디버거로 중단점 찍어가면서 확인도 합니다.

얼마나 Refactoring할 때 Comment를 남기나요? 어떤 사람들은 Comment없이 코드만으로 이해할 수 있게 짜라는 조언을 하는데요.
: Kent Beck은 Comment가 길면 무언가 추상화 할 수 있는 잠재성이 있다고 했습니다.  어떤 사람은 Refactoring을 할 때 코드의 전체 구조를 먼저 Comment로 적고 실제 함수 이름은 그 Comment에서 띄어쓰기를 뺀 이름을 쓰기도 합니다. 어떻게 이름 짓는가가 어떻게 구현하느냐보다 중요하다고 Kent Beck은 이야기 했지요. Comment로 적어 놓는 다는 것은 어찌보면 이후에 제거해야 할 것들에 대해 표시를 하는 것과 같은 의미일 것입니다.
( 그러나 저는 Comment는 코드의 ‘의도'를 적어야 한다는 Code Complete의 저자인 Steve McConnell의 의견에 더 동의합니다.)


얼마나 하면 당신 같은 전문가가 될 수 있을 까요?
: 매일 매일 노력해야 합니다. 작은 것이라도 개발환경을 개선하고 소프트웨어를 더 낫게 만들어야지요. 마법의 연차수는 없습니다. ^^ 스크럼 마스터 인증서가 실제 그 사람이 좋은 스크럼 마스터라는 것을 보증하지 않은데 검증없이 고용하는 회사들이 있죠. 실제 그 사람이 했던 결과물들, 코드를 봐야 합니다. Google이 이런 부분에 대해서는 잘 하고 있지요.


당신에게 지난 몇 년 동안 가장 도전적이었던 일은 어떤 것이었습니까?
:  저에게 제일 힘든 문제는 소프트웨어 자체보다 사람들과 관계를 맺는 일이었습니다.  좋은 팀을 만드세요.  


Slide : [Link]

Voice record: [Keynote], [Q&A]

 
저작자 표시

Posted by 유진호