도도와 파이썬: 좋은 선택과 나쁜 선택

1. 도도와 파이썬: 좋은 선택과 나쁜 선택 JC CTO 파이콘 2015 jc@spoqa.com

2. 스포카는 뭐하는 회사인가요? 01

3. ‹#› 1. 2011년 5월 창업 2. 태블릿 멤버십 서비스 "도도 포인트" 개발/운영중 3. 서울 / 부산 / 일본에서 운영중 스포카는 뭐하는 회사인가요? 스포카

4. ‹#›

5. ‹#› 스포카는 뭐하는 회사인가요? 스포카

6. ‹#› 스포카는 뭐하는 회사인가요? 스포카

7. ‹#› 1. 5,000개 매장, 500만명의 사용자가 이용중 2. 카페, 레스토랑, 리테일샵, 헤어샵 방방 곡곡에서 사용중 3. 퇴직후 치킨집을 고려하고 계시다면? 1. 02-544-6463으로 전화주시면 친절히 상담드립니다. 2. 저희 부스에 브로셔 받아가세요. 스포카는 뭐하는 회사인가요? 도도 포인트

8. ‹#› 스포카는 왜 파이콘에? Spoqa ❤ Python

9. ‹#› 1. 개발 프로젝트의 거의 대부분이 파이썬으로 개발됨 2. 15명의 개발자가 모두 파이썬을 쓰며,   익숙하게 쓰시는 분이 다수 3. 여러 오픈소스 프로젝트에도 기여하고 있음 •http://github.com/spoqa 스포카는 왜 파이콘에? Spoqa ❤ Python

10. ‹#› 1. 스포카가 도도 포인트를 만들면서 있었던  기술적 의사결정을 공유합니다. 1. 어떤 것은 좋은 선택이었고, 2. 어떤 것은 나쁜 선택이었는데, 3. 이 과정에서 파이썬과 어떻게 함께 생존했는지를  알려드리겠습니다. 스포카는 왜 파이콘에? 오늘 공유할 내용은...

11. 좋은 선택: 도도 포인트를 처음 만들때 02

12. ‹#› 1. 로켓이 될거라 자신한 “스포카” 적립 앱은 매장을 100 개나 가맹했는데 아무도 쓰지 않았음 2. 당연히 쓰이고 있지를 않으니 투자 유치도 요원한 상황 좋은 선택: 도도 포인트를 처음 만들때 2012년 1월 당시 상황

13. ‹#› 1. 이 상황에서 당연히 유료화 또한 꿈도 꿀 수 없었고 2. 자신만만하게 엔젤투자도 받았는데 돈도 다 까먹었고 3. 여러모로 절망적인 상황이었음 좋은 선택: 도도 포인트를 처음 만들때 2012년 1월 당시 상황

14. ‹#› 좋은 선택: 도도 포인트를 처음 만들때 2012년 1월 당시 상황 <당시 잠에 들면 꾸던 꿈>

15. ‹#› 그 상황에서 이런저런 다음 피봇할 거리를 고민하던 중, 공동창업자인 대표가 테크크런치를 보다가, “사람들이 적립한다고 앱을 받지는 않으니 매장에 태 블릿을 깔아놓고 앱 없이도 적립이 되게 하자” 고 제안함 좋은 선택: 도도 포인트를 처음 만들때 2012년 1월 당시 상황

16. ‹#› 지금와서야 말이 되는 것 같지만서도, 당시에는 누가 적립한다고 50만원이 넘는 되는 태블릿을 사;; 같은 생 각이 머리속에 지배적이었음 그런데 대표가 계속 주장을 반복하여 화가 난 나머지 이게 안되는 제품이라는 걸 직접 보여줘야겠다는 생각 이 들었음 좋은 선택: 도도 포인트를 처음 만들때 2012년 1월 당시 상황

17. ‹#› 1. 월급날이 매월 두려워지는 시기였기 때문에,  느긋하게 할 여유 없었음 2. 5일내로 돌아가는걸 보자! 하고 저녁시간에 개발 시작 3. (낮에는 아직 한창 스포카 만들고 있었음;;) 좋은 선택: 도도 포인트를 처음 만들때 1차 프로토타입 제작

18. ‹#›

19. ‹#›

20. ‹#› 1. 제대로 안돌아갈 거라고 생각하고 만들어보니 생각보 다 적립하는 느낌이 괜찮았음 2. 프로토타입을 전사적으로 1차 공유해본 결과 이걸 한 번 실험해보고싶다는 쪽으로 의견이 모아짐 좋은 선택: 도도 포인트를 처음 만들때 엥? 생각보다 경험이 괜찮네?

21. ‹#› 3. 그 자리에서 대표가 1차 프로토타입을 들고 옆 건물 1 층 주커피로 달려감 좋은 선택: 도도 포인트를 처음 만들때 엥? 생각보다 경험이 괜찮네?

22. ‹#›

23. ‹#› 1. 기본적으로는 1차와 별 다를바가 없었음 2. 다만 첫번째 고객의 취향에 완전히 맞추어주었음 •Do things that don’t scale   http://paulgraham.com/ds.html 좋은 선택: 도도 포인트를 처음 만들때 2차 프로토타입 제작

24. ‹#› 1. 그 외 몇가지 사용성 개선 시도를 더함 1. (e.g. 첫번째 프로토타입을 모르는 사용법을 잘 모르 겠다고 판단하여 아예 동영상을 붙임) 2. 여전히 2개 이상의 매장이 사용할 것은 구조적으로 고려 하지 않음 3.2주 정도 소요 좋은 선택: 도도 포인트를 처음 만들때 2차 프로토타입 제작

25. ‹#› 당시에는 5일동안 만들어본 프로토타입을 써보고 내부 의 감에 의해 2차 프로토타입을 만들었지만, 우리는 피 봇을 확정하기 위한 보다 객관적인 기준이 필요했음 좋은 선택: 도도 포인트를 처음 만들때 2차 프로토타입 제작

26. ‹#› 그래서 대표와 나는 약간 보수적으로, 기존 서비스에서 우리가 사용한 양을 제외한 순수 고객 사용량이 3배 이 상이 나오면 주력 서비스를 태블릿 기반 서비스로 전환 하자고 결정함 좋은 선택: 도도 포인트를 처음 만들때 2차 프로토타입 제작

27. ‹#› 1. 2월의 마지막 금요일에 설치하고, 주말을 보낸 후, 월요 일에 확인해보니, 기존 서비스 대비 사용량이 13배 가 나옴 2. 아 그냥 우리가 바보였구나;;; 3. 스포카 앱의 업데이트는 그 날이 마지막이었다고 한다. 좋은 선택: 도도 포인트를 처음 만들때 2차 프로토타입 제작

28. ‹#› 이 프로토타입을 들고 다니면서, 1. 엔젤투자자님께 돈을 더 빌리고 2. 기술 보증 기금을 받고 3. 정부 지원 사업에 선정되어서 4. 다음달 월급을 지급할 수 있었다. 좋은 선택: 도도 포인트를 처음 만들때 부활

29. ‹#› 1. 백오피스를 가볍게 두고 제품 자체에 집중한 것 2. 개발을 할 수 있다면 모두 고객 경험 자체에 올인한다. 좋은 선택: 도도 포인트를 처음 만들때 개발 기조 확립

30. ‹#› 이유: 스포카에서의 경험 1. 스포카 때는 아주 일반적인 개발 과정을 거쳤음 2. 백엔드 운영, 통계, 배포 도구, 앱 자체를 고루고루 개발 3. 장점: 장기적으로 효율이 좋다. 단, 성공했을 때 4. 그리고 망함 좋은 선택: 도도 포인트를 처음 만들때 개발 기조 확립

31. ‹#› 1. 사실상 스타트업의 성공율은 1% 미만, 99% 제품의 보조 도구는 쓸모 없어진다. 2. 그러면 차라리 1%를 올리는데 집중하고 보조 도구의 개발은 나중으로 미루거나 위임한다. 좋은 선택: 도도 포인트를 처음 만들때 개발 기조 확립

32. ‹#› 1. 최대한 보조 도구는 극단적으로 개발 외 자원으로 아웃 소싱할 수 있도록 한다. 1. 계약은 종이로! 2. 분석은 엑셀로! 3. 디플로이는 Heroku 로! 좋은 선택: 도도 포인트를 처음 만들때 개발 기조 확립

33. ‹#› 1. 처음에는 계약 자체도 많은 수정과 개선이 필요하다. 2. 어떤 비즈니스 모델이 매장과 우리 회사 입장에서 모두 만족스러울 수 있는지 끊임없이 테스트해야 함 3. 개발팀의 의존성 없이 빠르게 계약을 실험해볼 수 있도 록 계약은 당분간 종이로 진행 좋은 선택: 도도 포인트를 처음 만들때 계약은 종이로!

34. ‹#› 1. SQL을 쓸 줄 아는 사람보다 엑셀 쓸 줄 아는 사람이 더 많았음 2. 매장 사용 현황을 깊게 분석해보기 위한 과정에서 개발 의존성을 최소화하고자 했음 3. 그래서 현재 사용 DB를 구글 스프레드시트로 내보내 는 스크립트를 만들고, 모두가 분석할 수 있게 함 좋은 선택: 도도 포인트를 처음 만들때 분석은 엑셀로!

35. ‹#› 4. 이런 방식은 한 시트당 데이터가 40,000 셀이 넘어가 면 더 이상 쓸 수가 없게 되었지만, 5. 다행히 그 때는 다른 분석 도구를 제공해줄 수 있는 여 유가 생겨 큰 문제 없이 넘어감 좋은 선택: 도도 포인트를 처음 만들때 분석은 엑셀로!

36. ‹#› 1. 도도 포인트를 처음 만들 때 마침 Heroku 에서 Cedar 스택을 통해 Python 을 지원하기 시작했음 2. 디플로이 시스템을 만들고 유지보수하는 것도 부담이 있었기 때문에 아예 Heroku 를 써서 운영  (당시에는 어이없어하는 사람들이 많았음) 좋은 선택: 도도 포인트를 처음 만들때 디플로이는 Heroku 로!

37. ‹#› 1. 다만 버지니아에서 날라오는데 레이턴시 이슈가 있었 기 때문에 디플로이 시스템을 개발하여 AWS 도쿄로 옮김 2. 2012년에 여름에만 AWS 버지니아 리전이 2주 간격 으로 태풍/번개를 2번 맞아서 당황스러웠던 기억이... 좋은 선택: 도도 포인트를 처음 만들때 디플로이는 Heroku 로!

38. ‹#› 1. 첫 프로토타입까지, 5일 2. 2차 프로토타입까지, 2주 3. 첫 런칭까지 1개월 좋은 선택: 도도 포인트를 처음 만들때 빠르고, 점진적으로,

39. ‹#› 1. 그로부터 7개월간 3명+1명(인턴) 의 개발팀이 지속적 으로 제품을 개선해나갔고, 2. 제품을 사용하는 매장이 200개까지 늘어났으며, 3. 1차 투자를 유치하며 더 멀리 바라볼 수 있게 되었다. 좋은 선택: 도도 포인트를 처음 만들때 빠르고, 점진적으로,

40. 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 03

41. ‹#› 1. 매장이 1,000개 가까이 늘어나니까 서비스에 대한 요 구사항이 늘어남 2. 기존 서비스는 이미 너무 커져서 새로운 기능을 추가하 기 점점 고통스러워지고 있었음 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 2013년 겨울 당시의 상황

42. ‹#› 1. 그래서 여러가지 작은 서비스들이 서로 API를 통해 통 신하며 발전할 수 있는 구조를 가져가기로 결심 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 2013년 겨울 당시의 상황

43. ‹#› 1. 그런데 문제는 당시에 여러가지 욕심이 많았음 2. 다른 회사에서의 제휴 문의도 많았고 3. 우리도 하고 싶은게 정말 많았음 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 2013년 겨울 당시의 상황

44. ‹#› 1. 그래서 우리는 API를 우리 뿐만 아니라 처음부터 외부 인들도 사용할 수 있게 만들자고 결심했고 (실수1) 2. 개발자 사이트, 개발자 등록, Rate Limit, 관리도구 등 등을 초기 구현 범위에 포함시켰음 (실수2) 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 API에 대한 삽질 시작

45. ‹#› 1. 지금 당장 쓸 실제 외부 개발자가 없었기 때문에, 외부 개 발자가 쓸 상황을 상상하며 설계해야 했음 2. 지금 필요한 내부 개발과는 동떨어진 고민이 자잘하게 많이 섞여있었기 때문에, 1. 확신이 서지 않아 결정이 빨리 내려지지 않음 2. 내부에서는 필요한 API를 제때 공급받지 못함 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 이 과정에서 다양한 문제를 겪게 되는데

46. ‹#› 결국 당시 만든 API는 내부에서 쓰기도, 외부에서 쓰기 도 어려운 물건이 됨 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 실패

47. ‹#› 해당 프로젝트의 실패 이후, 실제로 외부 서비스와 연 동이 필요한 상황에서 계획적이지 않게 급하게 추가한 API가 가장 많이 활용되는 것을 보게 됨 나쁜 선택: 이제 성장할 시기라고 느꼈을 때 실패

48. 교훈 04

49. ‹#› 1. 우리는 종종 "그 때 제대로 해놨으면 지금 이 고생 안 하는데..." 라고 후회 2. 하지만 그건 이미 그 코드를 계속 만질 수 있는 미래 시 점에서의 평가일 뿐 3. 스타트업이었고, 필요한 것에 집중했다면,  사실은 그 선택이 맞는 선택이다. 교훈 지금 필요한 것에 집중하자

50. ‹#› 1. 하지만 이 발표가 단지 똥코드를 계속 방치하는 회사 들의 변명거리가 되지 않았으면 한다. 2. 가치를 만들어야 하는 시기와 성장을 만들어야 하는 시기는 다르다. 3. 태세 전환을 하지 못하고 과거의 영광에 빠지면 성장 스테이지에서도 제대로된 것을 만들지 못함 교훈 지금 필요한 것에 집중하자

51. 서울 본사 서울특별시 강남구 테헤란로 420 하이리빙 빌딩 9층 TEL 02-544-6463 FAX 02-544-6460 부산 지사 부산광역시 부산진구 부전동 426-7 신동아오피스텔 1007호 TEL 02-544-6463 FAX 02-544-6460 주식회사 스포카 나쁜 결정 늦은 결정

52. 서울 본사 서울특별시 강남구 테헤란로 420 하이리빙 빌딩 9층 TEL 02-544-6463 FAX 02-544-6460 부산 지사 부산광역시 부산진구 부전동 426-7 신동아오피스텔 1007호 TEL 02-544-6463 FAX 02-544-6460 주식회사 스포카 좋은 결정 나쁜 결정

53. 대격변: 파이썬은 스타트업에게 좋은가? 05

54. ‹#› 1. 기본적으로 익숙한 언어로 창업하시기 바랍니다. 2. 당시에 흔치는 않았지만, 저희 팀에서 파이썬을 채택 한 이유는 기본적으로 익숙했기 때문입니다. 3. 파이썬이 익숙치 않다면 이후의 조언이 의사결정에 반 영되지 않았으면 합니다. 대격변: 파이썬은 스타트업에게 좋은가? 경고

55. ‹#› 대격변: 파이썬은 스타트업에게 좋은가? Duct Tape 부터 엄격함까지

56. ‹#› 1. 파이썬은 기본적으로 쉽고 빠르게 원하는 것을 만들 수 있는 프로그래밍 언어 2. 하지만 그런 프로그래밍 언어는 이미 많음 3. 파이썬은 동시에 엄격한 코드를 짤 수 있는 프로그래 밍 언어이기도 하다는 점이 조금 다름 대격변: 파이썬은 스타트업에게 좋은가? Duct Tape 부터 엄격함까지

57. ‹#› 1. 스타트업은 단지 “작은”회사를 뜻하지 않음 2. 스타트업의 가장 중요한 키워드는 “고속성장” • Startup = Growth   http://paulgraham.com/growth.html 3. 코드가 처하는 상황 또한 빠르게 바뀐다는 의미 대격변: 파이썬은 스타트업에게 좋은가? Duct Tape 부터 엄격함까지

58. 서울 본사 서울특별시 강남구 테헤란로 420 하이리빙 빌딩 9층 TEL 02-544-6463 FAX 02-544-6460 부산 지사 부산광역시 부산진구 부전동 426-7 신동아오피스텔 1007호 TEL 02-544-6463 FAX 02-544-6460 주식회사 스포카 가치 성장

59. ‹#› 1. 처음에는 사람도 적고 경험도 적고 시간도 없으니, 2. 도도 포인트에도 수 많은 똥코드가 산재해있었음 3. 있는 돈과 시간 하에서 우선 “가치”를 만드는데 집중 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

61. ‹#› 2012년 도도 포인트 코드 상태 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

62. ‹#› 2012년에 예상한 2014년 도도 포인트 코드 상태 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

63. ‹#› 2014년 초 도도 포인트 코드 상태 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

64. ‹#› 1. 어느정도 제품이 충분히 시장의 니즈를 충족하게 되면 이를 더 많은 사람들이 쓸 수 있도록 해야... 2. 그렇게 하기 위해 제품의 안정성, 지속 가능성을 확보 해야 함 대격변: 파이썬은 스타트업에게 좋은가? 성장 모델로 전환을 위해

66. 똥코드를 개선하는 방법 #1

67. ‹#› 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #1: 빠따

68. ‹#› 1. Pull Request를 통해 변경사항에 대해 리뷰를 받고, 리뷰어가 각종 문법 오류와 설계를 지적하는 것 2. 고차원의 코드 퀄리티에 대한 논의가 가능한 것은 장 점이나, 3. 여러가지 단점과 한계가 있음 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #1: 빠따

69. ‹#› 1. 리뷰를 해주는 사람에 따라 리뷰 퀄리티도 차이가 남 2. 리뷰를 보는 사람도, 듣는 사람도 감정이 상하는 경우 가 왕왕 있음 • 넌 왜 이렇게밖에 못짜냐 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #1: 빠따

70. ‹#› 1. 그래서 잡플래닛 평점이 내려감 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #1: 빠따

71. 똥코드를 개선하는 방법 #2: 시어머니 봇

72. ‹#› 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #2: 시어머니 봇

73. ‹#› 1. 코드 리뷰의 상당 부분을 자동화 • 봇은 잔인하게 엄격함 • 봇한테 화가 날 수는 있어도 미워하진 않더라 2. CI에 붙어있음 / 테스트와 동급으로 취급 3. 인간이 하는 코드 리뷰 시간을 상당히 아낌 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #2: 시어머니 봇

74. ‹#› 처음부터 다 고치려면 시간이 너무 오래 걸리므로, 첫 스크립트는 이렇게 통과 가능해보이는 것들만 먼저 검 사하도록 함 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #2: 시어머니 봇 $ pep8 --statistics --count --show-source -- ignore=E123,E126,E127,E201,E202,E225,E226,E231,E241,E30 2,E501,E711,E712,W391,W601 dodo

75. ‹#› 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #2: 시어머니 봇

76. ‹#› 1. flake8: pep8 + pyflakes 2. eslint 3. 마이그레이션 스크립트 검사 4. import 순서 검사 https://github.com/spoqa/import-order 대격변: 파이썬은 스타트업에게 좋은가? 똥코드를 개선하는 방법 #2: 시어머니 봇은 지금

77. ‹#› 1. 성숙한 모노리스 + 몇개의 마이크로서비스 2. 성숙한 모노리스 (도도 포인트 + 도도 인사이트) 1. 무중단 운영 2. 하루 10번 이상의 디플로이 3. 준수한 코드 퀄리티 유지중 4. 모노리스의 크기를 조금씩 줄이는 중 3. 신규 마이크로 서비스 일부는 여전히 똥코드 대격변: 파이썬은 스타트업에게 좋은가? 요즘 도도 포인트

79. ‹#› 2015년 도도 포인트 코드 지향점 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

80. ‹#› 잘못되면... 대격변: 파이썬은 스타트업에게 좋은가? 도도 포인트 코드의 역사

81. ‹#›

82. 감사합니다.

83. Q&A

84. https://github.com/spoqa/spoqa- pycon-2015-codegolf

도도와 파이썬: 좋은 선택과 나쁜 선택

도도와 파이썬: 좋은 선택과 나쁜 선택

Recommended

More Related Content

What's hot

What's hot(20)

Similar to 도도와 파이썬: 좋은 선택과 나쁜 선택

Similar to 도도와 파이썬: 좋은 선택과 나쁜 선택(20)

Recently uploaded

Recently uploaded(6)

도도와 파이썬: 좋은 선택과 나쁜 선택