O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

기술적 변화를 이끌어가기

24.927 visualizações

Publicada em

한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.

Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git

Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop

Publicada em: Software
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • ACCESS that WEBSITE Over for All Ebooks (Unlimited) ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... DOWNLOAD FULL EPUB Ebook here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m6jJ5M }
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes ,Download or read Ebooks here ... ......................................................................................................................... Download FULL PDF EBOOK here { https://urlzs.com/UABbn }
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • -- DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT -- ......................................................................................................................... ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } ......................................................................................................................... (Unlimited)
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • (Unlimited)....ACCESS WEBSITE Over for All Ebooks ................ accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full EPUB Ebook here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full PDF EBOOK here { https://urlzs.com/UABbn }
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

기술적 변화를 이끌어가기

  1. 1. 기술적 변화를 이끌어가기 안재우(Jaewoo Ahn) Platform Architecture 팀 SK Planet
  2. 2. 변화(Changes)? ‘미안하지만 사람들은 정말 변화를 싫어합니다. 바로 그게 문제죠. 사람들은 자기에게 도움이 되는 변화는 물론이고, 변화는 뭐든 다 반대합니다. 그 이유는 바로 사람들이 변화를 싫어하기 때문이죠.’ - 피플웨어(Peopleware), 톰 디마르코/티모시 리스터
  3. 3. 소프트웨어라고 다를리가… • 꼭 그거 써야 돼? 배우기 귀찮은데. • 지금 쓰던 기술로도 되는데? • ‘검증’ 안된 거잖아. 우리 회사에서 쓰는 곳 있어? • 문제 생기면 니가 책임질래?
  4. 4. 고양이 목에 방울달기 또한 새로운 체제를 도입하는 선봉 역할을 맡는 것처럼 하기 어려우며, 성공을 보장하기 힘들고, 지극히 위험한 일도 없다. 새로운 질서를 도입하는 사람은 필연적으로 구체제 하에서 기득권을 가졌던 사람들과 모두 적대 관계가 될 것이며, 새로운 체제에서 기득권을 얻을 수도 있는 사람들은 오직 소극적인 태도로 그를 옹호할 것이기 때문이다. - 군주론, 마키아벨리
  5. 5. 그래도 변화는 필요하다 • 새로운 기술은 ‘재미’를 이끌어낸다. • 기술의 변화가 관점의 변화, 할 수 있는 일의 범위를 변화시킬 수 있다. • 노땅 개발자는 낡은 기술과 함께 늙어가고, 젊은 개발자는 새로운 기술에 열광한다. • 먼저 매 맞아주는 선구자들이 오픈소스 커뮤니티에 존재한다. (한국 아니면 어때, 글로벌 시대인데…)
  6. 6. 신규 개발 시의 고민 • 지난번과 동일한 기술/방법론을 사용할지? • 뭔가 새로운 기술이나 새로운 방법론을 시도해볼지? • 프로젝트 멤버들에겐 뭐가 더 재밌을까요? (물론 재미를 따질 여유 따윈 없으신 분들도 계시겠지요… /애도)
  7. 7. 그래서, • ‘변화’를 주는 것이 더 재밌다고 생각했기 때문에 변화해보기로 합니다. • ‘원칙적으로는’ or ‘이상적으로는’ 그렇게 하는 것이 ‘맞다’ or ‘좋다’고 생각되는 거면 그렇게 하기로 합니다.
  8. 8. Phase 1 ‘새로운’ 서비스를 ‘새로운’ 기술과 ‘새로운’ 방법론으로 만들어보자.
  9. 9. Phase 1 ‘새로운’ 서비스를 ‘새로운’ 기술과 ‘새로운’ 방법론으로 만들어보자. 기존 서비스와 무관하도록 쓰고 싶은 기술들을 마음껏 쓸 수 있도록 사람들이 일하는 방식이 달라질 수 있도록
  10. 10. Backend FrontendWeb Application Web Application Phase 1 : Architecture Presentation Controller Business Data Access Database 기존 시스템들의 Architecture Frontend Backend Database UI REST API Service 새로운 Architecture
  11. 11. Phase 1 : Architecture • Frontend와 Backend를 명시적으로 분리하고, 각각 독립적인 개발/배포가 가능하게 한다. • Frontend와 Backend는 REST API를 사용하여 통신하며, Stateless Architecture여야 한다.
  12. 12. Phase 1 : Frontend Web Application Presentation Controller Business Data Access JSP Sitemesh JQuery 기존 시스템들의 Frontend Frontend HTML CSS Angular.js Bootstrap Less Grunt Bower Karma 신규 시스템의 Frontend
  13. 13. Phase 1 : Frontend Web Application Presentation Controller Business Data Access JSP Sitemesh JQuery 기존 시스템들의 Frontend Frontend HTML CSS Angular.js Bootstrap Less Grunt Bower Karma 신규 시스템의 Frontend Frontend MVC Framework Frontend Task Runner (Build, Test, Run) Frontend Package Manager Frontend Test Runner CSS Framework CSS Helper
  14. 14. Phase 1 : Backend Java 1.6 Tomcat 6 Spring 3.x + XML Conf. Spring MVC MyBatis Maven 기존 시스템들의 Backend a.k.a. 한국 SI 표준셋(?) 신규 시스템의 Backend Java 1.7 Tomcat 7 Spring 4.x + Java Conf. Spring MVC Spring Data JPA + Hibernate Maven
  15. 15. Phase 1 : Backend • Goodbye MyBatis & Hello ORM – Model-Driven 구조 – DDL 자동생성 (Production 제외) – ERD 그리느라 시간 낭비하지 않음 – 실행 시에는 MySQL, Unit Test 시에는 H2 사용 • ORM 성능 우려? – 필요하면 Second-Level Cache 적용 – 그걸로도 안되면 Native Query 사용 – 그걸로도 안되면 DB 튜닝
  16. 16. Phase 1 : 방법론/프로세스 • Project Charter 작성 – 프로젝트 개요, Scope, 마일스톤 – 커뮤니케이션 위치(Wiki, JIRA, Agile Board, Git) – 프로젝트 원칙, FAQ • Scrum 도입 – JIRA Agile 적극 활용 – Sprint 계획/실행/리뷰 • Git – 처음엔 별다른 Branch 정책 안 둠 – 그냥 일단 Git부터 익숙해지기
  17. 17. Phase 1 : 방법론/프로세스 • 프로젝트 원칙 – Sprint 기간 중에는 모든 멤버가 Sprint의 항목에 대해서만 집중한다. – Sprint 항목은 Sprint 기간 내에 완료되어야 하며, 구현 항목에 대해 배포가 가능한 형태로 시연이 가능해야 한다. – Dogfooding – 모든 구성원은 자발적으로 필요하거나 누락된 항목이나 문제점, 더 좋은 아이디어가 있으면 제안하고, 서로 협력한다. – 개발하는 모든 과정이나 나오는 산출물을 숨기지 않는다. 개방된 마음으로 지적질을 수용한다. – 팀, 회사 차원의 개발에서 Best Practice를 만든다는 생각으로 임한다.
  18. 18. Backend 개발자Frontend 개발자 Phase 1 – 방법론/프로세스 UserStory 검토 Contract/API 설계 Frontend 개발 Backend 개발 Mock/Unit Test Unit Test API 연동 Load Test UserStory 종료
  19. 19. Phase 1 결과 • 새로운 서비스를 Beta 오픈했고, • 새로운 기술을 습득하고 검증했으며, • 새로운 방법론/프로세스에 대해 적응 • Stakeholder들의 긍정적 Feedback • 무엇보다, 프로젝트 멤버들이 ‘성취감’과 ‘재미’를 느꼈다는 점
  20. 20. 그럼, 2차 가야죠?
  21. 21. Phase 2 ‘기존’ 서비스들 + @를 ‘더욱 새로운’ 기술과 ‘더욱 새로운’ 방법론으로 ‘더 많은’ 사람들과 만들어보자.
  22. 22. Phase 2 ‘기존’ 서비스들 + @를 ‘더욱 새로운’ 기술과 ‘더욱 새로운’ 방법론으로 ‘더 많은’ 사람들과 만들어보자. 마이그레이션, 이행을 고려해야 함 세상은 넓고 새로운 기술은 많다 보다 나은 개선을 위한 실험 피자 두판을 넘어간다면..?
  23. 23. Phase 2 : Architecture • 기존 : Monolithic Architecture “사용자용” Web Application “운영자용” Web Application “App용” API Service “Central” Database A.UI A.Biz B.UI B.Biz A.UI A.Biz C.UI C.Biz D.UI D.Biz D.Biz A.Biz A B C D
  24. 24. Phase 2 : Architecture • To Be : Micro-Service Architecture(MSA) A UI A Service B UI B Service C UI C Service D UI D Service A DB B DB C DB D DB Content Router API Gateway Content Router Service Registry Event Broker Config Service Deploy Service 사용자용 Endpoint 관리자용 Endpoint
  25. 25. Phase 2 : Architecture • MSA를 선택한 이유 – Frontend – Backend 분리 + 기능 영역의 분리 – API 기반의 Contract 유지를 강제화 – 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리 – Micro-Service 단위로 이해하고 개발하기 쉬움 – Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할 수 있음(Polyglot)
  26. 26. Phase 2 : Architecture • MSA를 선택한 이유 – Frontend – Backend 분리 + 기능 영역의 분리 회사의 Engineer Tech Tree(Frontend/Backend)와 동기화 – API 기반의 Contract 관리를 강제화 API로 뽑아내지 않으면 아무것도 못하니까 – 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리 Micro-Service 단위로 격리되니까 – Micro-Service 단위로 이해하고 개발하기 쉬움 코드의 양을 줄여서 누구나 쉽게 파악할 수 있도록 – Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할 수 있음(Polyglot) 실험해보고 싶은 거 맘대로 시도(써보고 아님 말고) 향후 개발자 구하기도 용이할 걸?
  27. 27. Phase 2 : Architecture • 물론, 수많은 단점들이 있다 – Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지? – Contract (API) 관리를 어떻게 해야 하지? – 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예: Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는 경우들도 생긴다 – 세션은 어떻게 관리해야 하나? – 서비스 간 의존성/트랜잭션 관리는 어떻게? – 코드의 중복이 발생 – 배포/운영이 생각보다 머리 아픈데?
  28. 28. Phase 2 : Architecture • 물론, 수많은 단점들이 있다 – Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지? – Contract (API) 관리를 어떻게 해야 하지? – 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예: Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는 경우들도 생긴다 – 세션은 어떻게 관리해야 하나? – 서비스 간 의존성/트랜잭션 관리는 어떻게? – 코드의 중복이 발생 – 배포/운영이 생각보다 머리 아픈데? 어떻게 해결해야 할까?
  29. 29. Phase 2 : Architecture • 물론, 수많은 단점들이 있다 – Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지? – Contract (API) 관리를 어떻게 해야 하지? – 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예: Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는 경우들도 생긴다 – 세션은 어떻게 관리해야 하나? – 서비스 간 의존성/트랜잭션 관리는 어떻게? – 코드의 중복이 발생 – 배포/운영이 생각보다 머리 아픈데? 어떻게 해결해야 할까? 고갱님, 유료 서비스입니다 미안, 이건 다음 시간에… (사실 현재진행형이라) 그리고 Google 신에게 물어보세요
  30. 30. Phase 2 : Architecture • 물론, 수많은 단점들이 있다 – Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지? – Contract (API) 관리를 어떻게 해야 하지? – 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예: Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는 경우들도 생긴다 – 세션은 어떻게 관리해야 하나? – 서비스 간 의존성/트랜잭션 관리는 어떻게? – 코드의 중복이 발생 – 배포/운영이 생각보다 머리 아픈데? 무엇보다도, 우리는 이 단점들을 극복해가는 과정을 즐기고, MSA가 가져주는 장점이 훨씬 더 크다고 믿습니다. Remind: ‘원칙적으로는’ or ‘이상적으로는’ 그렇게 하는 것이 ‘맞다’ or ‘좋다’고 생각되는 거면 그렇게 하기로 합니다.
  31. 31. Phase 2 : Frontend A UI B UI C UI D UI Content Router Content Router 사용자용 Endpoint 관리자용 Endpoint Browser에게 Single Origin/Endpoint를 보장 UI의 Versioning이나 A/B Testing을 가능하게 하기 위한 기반 로그/통계의 기준 Micro-Service Backend와 짝을 이뤄 독립적으로 개발됨 실제 서비스에서는 다른 UI들과 Main Page Container에서 조립됨 E2E(End-to-End) Test Selenium을 활용한 사용자 Viewpoint에서의 E2E 테스트
  32. 32. Phase 2 : Backend Java 1.7 Tomcat 7 Spring 4.x + Java Conf. Java 1.8 Embedded Tomcat Spring Boot Node.js Express MySQL Redis Others… Groovy Go ASP.NET 5 Vert.x Others… Polyglot, Multi- Framework 향후 실험(?) 후보 Polyglot, NoSql 또다른NoS ql 또는 Cloud PlanetSpace File Storage Cloud
  33. 33. Phase 2 : 방법론/프로세스 • Scrum 고도화 – Estimation 모델 도입 – JIRA Version을 활용한 Release Note 관리 – JIRA Issue Status와 연동 Open -> Progress -> Resolve(Code Commit/Link) -> Close(master merge 및 배포 완료) • Git Branch 정책 – Master Branch는 Production/Stage 배포 대상 – Dev Branch는 Sprint 중 개발 공유용 – Feature Branch : JIRA Issue 번호 기준 생성 – Feature->Dev, Dev->Master로 Merge 시 코드 리뷰 및 테스트
  34. 34. Phase 2 : 방법론/프로세스 • Pair Programming – Frontend, Backend, Test별 Pair • 2개의 Scrum – 적절한 인원 유지를 위해 • Rules & Conventions – 팀원 간의 암묵적 지식을 명시적으로 문서화 – 각 Scrum 간 공유 • Sprint Review 시 Code Workshop 실시 – 서로 간의 지식을 공유
  35. 35. Phase 2는 현재 진행형 우린 아마 안될거야 분명히 잘 될거예요, 변화가 재밌으니까.
  36. 36. Let’s change. End of Slides

×