기술적 변화를 이끌어가기

기술적 변화를 이끌어가기

안재우(Jaewoo Ahn)Platform Architecture 팀SK Planet

변화(Changes)?

‘미안하지만사람들은 정말변화를싫어합니다. 바로 그게 문제죠. 사람들은자기에게도움이 되는변화는 물론이고, 변화는뭐든 다 반대합니다. 그 이유는바로사람들이변화를 싫어하기때문이죠.’

- 피플웨어(Peopleware), 톰 디마르코/티모시리스터

소프트웨어라고다를리가…

• 꼭 그거 써야 돼? 배우기귀찮은데.

• 지금 쓰던 기술로도되는데?

• ‘검증’ 안된 거잖아. 우리 회사에서쓰는곳있어?

• 문제 생기면니가 책임질래?

고양이목에 방울달기

또한새로운 체제를도입하는선봉 역할을 맡는것처럼하기 어려우며, 성공을 보장하기 힘들고, 지극히위험한 일도 없다. 새로운 질서를도입하는사람은 필연적으로 구체제 하에서기득권을가졌던 사람들과 모두 적대 관계가 될것이며, 새로운 체제에서 기득권을 얻을 수도있는 사람들은 오직 소극적인태도로 그를옹호할것이기 때문이다.

- 군주론, 마키아벨리

그래도변화는 필요하다

• 새로운기술은 ‘재미’를이끌어낸다.

• 기술의변화가 관점의변화, 할 수 있는 일의범위를변화시킬수 있다.

• 노땅 개발자는낡은 기술과함께 늙어가고,젊은 개발자는새로운기술에 열광한다.

• 먼저 매 맞아주는선구자들이오픈소스커뮤니티에존재한다. (한국 아니면어때,글로벌시대인데…)

신규 개발 시의 고민

• 지난번과동일한 기술/방법론을사용할지?

• 뭔가 새로운기술이나새로운 방법론을시도해볼지?

• 프로젝트멤버들에겐뭐가 더 재밌을까요?(물론 재미를따질 여유 따윈 없으신분들도계시겠지요… /애도)

그래서,

• ‘변화’를주는 것이더 재밌다고생각했기때문에변화해보기로합니다.

• ‘원칙적으로는’ or ‘이상적으로는’ 그렇게하는 것이 ‘맞다’ or ‘좋다’고생각되는거면그렇게하기로 합니다.

Phase 1

‘새로운’ 서비스를

‘새로운’ 기술과

‘새로운’ 방법론으로

만들어보자.

Phase 1

‘새로운’ 서비스를

‘새로운’ 기술과

‘새로운’ 방법론으로

만들어보자.

기존 서비스와 무관하도록

쓰고 싶은 기술들을 마음껏 쓸 수 있도록

사람들이 일하는 방식이 달라질 수 있도록

Backend

FrontendWeb ApplicationWeb Application

Phase 1 : Architecture

Presentation

Controller

Business

Data Access

Database

기존 시스템들의 Architecture

Frontend

Backend

Database

UI

REST API Service

새로운 Architecture


• Frontend와 Backend를 명시적으로분리하고,각각 독립적인개발/배포가가능하게한다.

• Frontend와 Backend는 REST API를 사용하여통신하며, Stateless Architecture여야 한다.

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

Phase 1 : Frontend

Web Application

Presentation

Controller

Business

Data Access

JSP

Sitemesh

JQuery

기존 시스템들의 Frontend

Frontend

HTML

CSS

Angular.js

Bootstrap

Less

Grunt

Bower

Karma

신규 시스템의 FrontendFrontend

MVC Framework

FrontendTask Runner

(Build, Test, Run)

FrontendPackage Manager

FrontendTest Runner

CSSFramework

CSSHelper

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

Phase 1 : Backend

• Goodbye MyBatis & Hello ORM– Model-Driven 구조

– DDL 자동생성 (Production 제외)

– ERD 그리느라 시간 낭비하지 않음

– 실행 시에는 MySQL, Unit Test 시에는 H2 사용

• ORM 성능 우려?– 필요하면 Second-Level Cache 적용

– 그걸로도 안되면 Native Query 사용

– 그걸로도 안되면 DB 튜닝

Phase 1 : 방법론/프로세스

• Project Charter 작성– 프로젝트 개요, Scope, 마일스톤

– 커뮤니케이션 위치(Wiki, JIRA, Agile Board, Git)

– 프로젝트 원칙, FAQ

• Scrum 도입– JIRA Agile 적극 활용

– Sprint 계획/실행/리뷰

• Git– 처음엔 별다른 Branch 정책 안 둠

– 그냥 일단 Git부터익숙해지기


• 프로젝트원칙

– Sprint 기간 중에는 모든 멤버가 Sprint의 항목에 대해서만 집중한다.

– Sprint 항목은 Sprint 기간 내에 완료되어야 하며, 구현 항목에 대해 배포가

가능한 형태로 시연이 가능해야 한다.

– Dogfooding

– 모든 구성원은 자발적으로 필요하거나 누락된 항목이나 문제점, 더 좋은

아이디어가 있으면 제안하고, 서로 협력한다.

– 개발하는 모든 과정이나 나오는 산출물을 숨기지 않는다. 개방된

마음으로 지적질을 수용한다.

– 팀, 회사 차원의 개발에서 Best Practice를 만든다는 생각으로 임한다.

Backend 개발자Frontend 개발자

Phase 1 – 방법론/프로세스UserStory 검토

Contract/API 설계

Frontend 개발 Backend 개발

Mock/Unit Test Unit Test

API 연동 Load Test

UserStory 종료

Phase 1 결과

• 새로운서비스를 Beta 오픈했고,

• 새로운기술을 습득하고검증했으며,

• 새로운방법론/프로세스에대해 적응

• Stakeholder들의 긍정적 Feedback

• 무엇보다, 프로젝트멤버들이‘성취감’과 ‘재미’를느꼈다는점

그럼, 2차 가야죠?

Phase 2

‘기존’ 서비스들 + @를

‘더욱 새로운’ 기술과

‘더욱 새로운’ 방법론으로

‘더 많은’ 사람들과

만들어보자.

Phase 2

‘기존’ 서비스들 + @를

‘더욱 새로운’ 기술과

‘더욱 새로운’ 방법론으로

‘더 많은’ 사람들과

만들어보자.

마이그레이션, 이행을 고려해야 함

세상은 넓고 새로운 기술은 많다

보다 나은 개선을 위한 실험

피자 두판을 넘어간다면..?


• 기존 : 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


• To Be : Micro-Service Architecture(MSA)

AUI

A Service

BUI

B Service

CUI

C Service

DUI

D Service

A DB

B DB

CDB

DDB

ContentRouter

APIGateway

ContentRouter

ServiceRegistry

EventBroker

ConfigService

DeployService

사용자용 Endpoint

관리자용 Endpoint


• MSA를선택한 이유– Frontend – Backend 분리 + 기능영역의분리

– API 기반의 Contract 유지를강제화

– 빌드/배포용이, 확장용이, 장애로인한영향격리

– Micro-Service 단위로이해하고개발하기쉬움

– Micro-Service 단위로다른프로그래밍언어/프레임워크를사용할수있음(Polyglot)


• MSA를선택한 이유– Frontend – Backend 분리 + 기능영역의분리

회사의 Engineer Tech Tree(Frontend/Backend)와동기화

– API 기반의 Contract 관리를강제화API로뽑아내지않으면아무것도못하니까

– 빌드/배포용이, 확장용이, 장애로인한영향격리Micro-Service 단위로격리되니까

– Micro-Service 단위로이해하고개발하기쉬움코드의양을줄여서누구나쉽게파악할수있도록

– Micro-Service 단위로다른프로그래밍언어/프레임워크를사용할수있음(Polyglot)실험해보고싶은거맘대로시도(써보고아님말고)향후개발자구하기도용이할걸?


• 물론, 수많은 단점들이있다– Micro-Service를 얼마나/어떻게나누어서설계해야할지?

– Contract (API) 관리를어떻게해야하지?

– 기존에개발자혼자서하면되던기능이여러명의개발자(예:Frontend 개발자, 다른 Micro-Service 개발자)와협업을해야하는경우들도생긴다

– 세션은어떻게관리해야하나?

– 서비스간 의존성/트랜잭션관리는어떻게?

– 코드의중복이발생

– 배포/운영이생각보다머리아픈데?









어떻게 해결해야 할까?









어떻게 해결해야 할까?

고갱님, 유료 서비스입니다

미안, 이건 다음시간에…(사실현재진행형이라)

그리고 Google 신에게물어보세요









무엇보다도,우리는 이 단점들을극복해가는과정을 즐기고,MSA가가져주는장점이 훨씬 더 크다고믿습니다.

Remind: ‘원칙적으로는’ or ‘이상적으로는’ 그렇게 하는 것이 ‘맞다’or ‘좋다’고생각되는 거면 그렇게 하기로 합니다.

Phase 2 : Frontend

AUI

BUI

CUI

DUI

ContentRouter

ContentRouter

사용자용 Endpoint

관리자용 Endpoint

Browser에게Single Origin/Endpoint를 보장

UI의 Versioning이나A/B Testing을가능하게하기위한기반

로그/통계의기준

Micro-Service Backend와 짝을이뤄독립적으로개발됨

실제서비스에서는다른 UI들과 Main Page Container에서 조립됨

E2E(End-to-End) TestSelenium을활용한사용자Viewpoint에서의 E2E테스트

Phase 2 : BackendJava 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

또다른NoSql

또는 Cloud

PlanetSpace

File Storage Cloud


• 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 시 코드 리뷰 및 테스트


• Pair Programming

– Frontend, Backend, Test별 Pair

• 2개의 Scrum– 적절한인원유지를위해

• Rules & Conventions

– 팀원간의암묵적지식을명시적으로문서화

– 각 Scrum 간공유

• Sprint Review 시 Code Workshop 실시– 서로간의지식을공유

Phase 2는현재진행형

우린 아마안될거야

분명히 잘될거예요,변화가 재밌으니까.

Let’s change.

End of Slides

기술적 변화를 이끌어가기

Software