성장하는 스타트업의 프로세스 개척기
- 2. Who am I? • 김형준 • 처음 5년은 공공 SI • 그 다음 5년은 삼성전자 ITO • 최근 10년간은 Hadoop/BigData • 현재는 잡플래닛 • Apache Tajo PMC
- 3. Startup • business that is typically technology oriented and has high growth potential. • organization formed to search for a repeatable and scalable business model. • A startup is a company designed to grow fast. … The only essential thing is growth.
- 4. 필요한 건 뭐?
- 5. 처음 시작할 때에는 개발은 많아야 3 ~ 4명 모두가 서비스 기획자 디자인은 있으면 좋고 없으면 인맥 동원 마일스톤 따위는 없음
- 6. 서비스가 성공하면 더 많은 개발자 세분화된 조직 구성 (Mobile, Front-End, Back-End, 기획, QA, 디자인, …)
- 7. 이 시기에는 • 새로 만들어진 각 역할 조직은 의욕이 너무 넘침 • 조직/개인의 R&R이 불분명함 • 새로 합류한 인력들의 다양한 경험과 백그라운드 • 잘 만들어진 도구도 별로 없음 • 증가하는 고객 및 트래픽 대응, Business Model 구축하는 것도 버거움
- 8. 그래도 경영진은 시작 단계에서의 스피드가 학습되어 있음
- 9. 검색어 개인화 해주세요. (기획팀) 인도네시아에서는 메뉴가 너무 길어요. (인도네시아 스탭) 이거 말고 광고로 바꿔주세요. (영업팀) 이 채용 건이 최상단에 나오는데 검색 래킹의 품질은 좋은가요? 지표 좀 볼 수 있나요? (경영진) 로고가 이상해요. 교체해 주세요. (사용자/고객) 이미지 깨져요. (운영팀)
- 10. 모든 요구사항은 개발팀으로 검색어 개인화 해주세요. (기획팀) 인도네시아에서는 메뉴가 너무 길어요. (인도네시아 스탭) 이거 말고 광고로 바꿔주세요. (영업팀) 이 채용 건이 최상단에 나오는데 검색 래킹의 품질은 좋은가요? 지표 좀 볼 수 있나요? (경영진)로고가 이상해요. 교체해 주세요. (사용자/고객) 이미지 깨져요. (운영팀)
- 11. 이런 혼돈 속에서도 단순히 스피드만 빠른 것이 아니라 안정적이면서 많은 업무(Throughput)도 수행할 수 있는 프로세스/도구 필요
- 12. 필요한 것은 프로세스
- 13. 잡플래닛은? • 2014년 서비스 오픈 • 약 OO 만개의 기업 리뷰, 연봉 인터뷰 정보 제공 • 빠르게 성장하고 있는 중 • 한국, 인도네시아, 대만 서비스 중, 다수 국가 확장 진행중 (한국, 인도네시아 점유율 1위)
- 14. 입사해보니 • 최고 연장자 • Senior Engineer 역할이니 뭔가는 해야지 라는 생각 • 최근 2 ~ 3 개월내에 회사원이 2배 성장 (그 이후로 6개월 동안 2배 더 성장) • 역할별 조직 구성 중 • 정형화된 프로세스는 없음
- 15. 프로세스 다듬기 • 기존에도 이미 프로세스가 존재 • 새로 만드는 것이 아님 • 하지만, 밖으로 나와 있지 않음 • 조직 또는 구성원의 R&R에 대해 명문화되지 않음
- 16. 프로세스 다듬기 • 우군 확보 • 나 혼자만 외치면 안됨 • 현재 상황 및 수준 파악 • 프로세스 전문가 없음 • Agile 프로세스 경험자 없음 • 도구는 기본적으로 사용중 • Issue Tracker, Source Repository, Slack등 • 개발 조직만 사용 • 목표 수립 • 일단 프로세스 만들기, • 실현 가능한 목표 수립
- 17. 고민!!! • 최종 목표는 빠르게 기능을 추가/수정해서 • 버그 없이 안정적으로 배포 및 운영 • 그러면 Agile 기반 프로세스가 맞지 않나? • Agile에서는 단순한 원칙만 제시
- 18. Agile
- 19. Agile • 세부적으로 들어가면 생각해야 할 것들이 많음 • 계획 수립(우선순위) • 이슈 관리 • 코드 Merge • 스테이징 배포 • 테스트 • 운영 배포 • 타 국가 적용(번역 등)
- 20. 계획한 프로세스 우선순위 Icebox 기획 개발 QA 마케팅 Iteration Plan 개발 개발 개발 Test (Pass) Test (Pass) Test (Fail) Backlog Release Iteration은 Weekly 배포는 Daily
- 21. 계획한 프로세스(개발) 기능 개발/수정 테스트 케이스 개발 테스트 실행 Pull Request (githib.com) CI 서버 테스트 수행 테스트 결과 PR에 반영 Code Review Review 반영 Review 완료 Merge into Staging branch Staging 배포 통합 테스트 진행 Bug 등록 테스트 케이스 반영 테스트 통과 Merge into Master 배포 테스트 통과
- 22. 1차 적용된 프로세스 Icebox 기획 개발 QA 마케팅 Iteration Plan 개발 개발 개발 Test (Pass) Test (Pass) Test (Fail) Backlog Release Iteration은 ? 배포는 주 2회
- 23. 적용 시 장애물 • Product Owner 다시 말하면 서비스를 잘 이해하고 있으며, 개발 및 다른 조직과 협업을 할 수 있어야 하며 경영진 수준의 권한도 가져야 함
- 24. 적용 시 장애물 • Iteration 계획 수립 • 이유는 다수의 즉흥적인 업무 • 빠른 성장에서 나타날 수 밖에 없음 • 우선순위 제어가 되어야 하지만 그렇게 안됨 • CXO 레벨에서 어느 정도 Iteration 계획 참여 필요 -> Iteration 계획 수립은 하지 않음 • Backlog 만 관리, 모든 업무는 Backlog에 등록
- 25. 적용 시 장애물 • Daily 배포가 쉽지 않음 • 코드 병합, 테스트, QA에 많은 시간 투입 • 일일 변경 사항에 대해 코드 병합 후에도 주요 기능에 대해서는 테스트 수행 필요(Side effect 확인) • 이유는 자동화된 테스트 케이스 부족 • 테스트 케이스를 새로 다 만들어 넣어야 하는가? • 주 2회 배포만 진행 • 기본은 주 2회, 필요시 3 ~ 4회도 가능 • 휴일전 배포 금지
- 26. 1차 적용된 프로세스(개발)
- 27. 그래도 성과는 있었다. • 신규 Setup 된 조직의 R&R 정리 • 프로세스 기반 업무 진행 • 기획 -> 리뷰 -> 디자인 -> FE -> BE -> QA -> 배포 • 개발 팀에서는 코드 리뷰 문화가 만들어짐 • 테스트 및 품질에 대한 마인드 • PivotalTracker 기반으로 업무 진행
- 28. 2차 시도(1) • Product Owner 가 없는 상황을 반영 • Product Ownership:큰 단위 업무별 기획 Owner 선정 • Backlog 관리: 개발팀 리더가 전체 관리 • Backlog 우선순위: Iteration 미팅에서 진행 • 스토리 Use-Case 상세화: 기획자, 개발자가 진행 • Product 확인: 기획, QA 팀에서 진행
- 29. 2차 시도(2) • 단위 기능에 대한 테스트 케이스는 구현하지 않음 • 대신 자동화된 테스트 진행 • 모든 PR에 대해 테스트 수행하지 않음
- 30. 테스트 자동화 • 테스트 자동화 프레임워크 자체 구축 • 서버 기능은 모든 HTTP 호출 실행 및 Assert • 웹 기능은 Selenium 이용 • 모바일은 Appium 이용 • CI 에서 자동 실행 • 운영 배포 직전 스테이징 테스트 • 운영 배포 직후 운영 테스트 • 테스트 관리 시스템 • Testlink 사용 • 테스트 Case
- 31. 현재는
- 32. 사용하는 도구 • Ruby on Rails • Scaffold, ORM, Rails Framework 등을 통해 기만한 개발 가능 • PivotalTracker • 스토리 관리 • Github • Source Code Repository, Code Review • Slack • 커뮤니케이션 도구 • Newrelic • 시스템 모니터링 • OneSky • 번역 프로세스 관리 • TestLink • 테스트 케이스 관리 시스템
- 33. Ruby on Rails • 작고 빠른 기능 개발에 최적화 • Ruby/Rails 내에 웹/API 개발에 필요한 대부분 컴포넌트 제공 • 강력한 ORM • 개발자가 SQL을 사용하지 않아도 되는 수준으로 제공 • MVC Framework • View 템플릿 • MVC/ORM/Template 등에 기반한 코드 자동 생성(Scaffold) • 데이터 모델 변경 History tracking(DB Migration)
- 34. Ruby on Rails • Asset Compile • CSS, Javascript 등 • 테스트 도구 제공 • 강력한 REPL(Read–Eval–Print Loop) 도구 제공 • Rails console 만으로도 SQL 기능 수행 가능 • 배우기 쉬움 • ORM, MVC 등에 개념이 있는 개발자라면 1주일 정도면 개발 가능 • 단점은 • Weak Type 언어가 가지는 단점을 그대로 가지고 있음
- 35. Ruby on Rails로 개발 • 데이터 모델링 • Scaffold를 이용하여 다음 항목 생성 • 테이블 생성 Migration • Model, Controller, View 생성 • 목록, 입력, 수정, 상세조회, 삭제 기능 화면 기본 생성 • 테스트 케이스 기본 구성 • Model 등에 비즈니스 로직 추가 • 사용자 화면 Layout 변경 또는 추가 • 관리자 화면은 자동 생성된 기능 이용 • 배포 후 모델 수정 사항 발생 시 Migrate 코드 생성 • Add column 등 • 모델에는 자동 반영
- 36. PivotalTracker • Tracker is a simple, story-based project planning tool that allows teams to collaborate and react instantly to real-world changes. • It's based on agile software development methods …
- 37. PivotalTracker
- 38. Slack • 다양한 도구들과 Integration • Github에 Pull Request 요청 • Code review conversation • 스테이징, 운영 배포 스크립트 수행 시 Release note 공유 • CI Server의 Test 결과
- 39. Newrelic • 시스템 모니터링 도구 • 트렌젝션(SQL 등) 모니터링 • 배포 후 에러 모니터링
- 40. Newrelic
- 41. Newrelic
- 43. TestLink
- 44. Discussion • 단위 테스트의 부족은 어떻게 해결할 것인가? • 비즈니스 로직에 대한 테스트는 단위 테스트 추가 필요 • 화면의 Script 등에 대한 테스트는 기존 도구 활용 • 현재는 하나의 시스템으로 구성 • 모든 코드/조직이 시스템에 의존 관계 • 일부 코드 수정 시 여러 기능에 영향 • 서로 다른 요구수준이 같은 단위로 배포 • 보안, 품질 수준 등 • 의존 관계가 약한 여러 작은 단위가 움직이면? • Micro Service Architecture?
- 45. Discussion • 적당한 크기의 서비스/시스템으로 나눌 경우 • 일반적인 Agile 스러운 팀 구성을 해야 하는가? • 해당 서비스에 대한 PO • 기획, 프론트앤드, 백앤드, 개발, QA 등 • 이런 조직 구성인 경우 분할된 역할이 필요한가? • 기획자가 필요한가? • 프론트앤드/백앤드 개발 구분이 필요한가? • 개발자가 최종 QA를 수행할 수 있을까?
- 46. 또 다른 룰 • 견고한 서비스를 유지하기 위해서는 룰이 필요 • 가능한 단순한 구조로 시스템을 구성 • 하나의 소스 트리로 여러 국가 서비스가 가능해야 함 • 개발자는 운영 서버, 운영 DB에 접근하지 못함 • 보안이 가장 우선 • 클라우드 서비스를 적극적으로 활용 • 에러를 숨기지 말고 적극 노출, 노출된 에러는 즉시 수정 • 한 개발자가 하나의 기능만 개발하지 않음(즉, 전담 기능 개발은 없음) • 배포는 근무 시간 중