한국 표준(?) 자바셋(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

1. 기술적 변화를 이끌어가기
안재우(Jaewoo Ahn)
Platform Architecture 팀
SK Planet

2. 변화(Changes)?
‘미안하지만 사람들은 정말 변화를
싫어합니다. 바로 그게 문제죠. 사람들은
자기에게 도움이 되는 변화는 물론이고,
변화는 뭐든 다 반대합니다. 그 이유는 바로
사람들이 변화를 싫어하기 때문이죠.’
- 피플웨어(Peopleware), 톰 디마르코/티모시
리스터

3. 소프트웨어라고 다를리가…
• 꼭 그거 써야 돼? 배우기 귀찮은데.
• 지금 쓰던 기술로도 되는데?
• ‘검증’ 안된 거잖아. 우리 회사에서 쓰는 곳
있어?
• 문제 생기면 니가 책임질래?

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

5. 그래도 변화는 필요하다
• 새로운 기술은 ‘재미’를 이끌어낸다.
• 기술의 변화가 관점의 변화, 할 수 있는 일의
범위를 변화시킬 수 있다.
• 노땅 개발자는 낡은 기술과 함께 늙어가고,
젊은 개발자는 새로운 기술에 열광한다.
• 먼저 매 맞아주는 선구자들이 오픈소스
커뮤니티에 존재한다. (한국 아니면 어때,
글로벌 시대인데…)

6. 신규 개발 시의 고민
• 지난번과 동일한 기술/방법론을 사용할지?
• 뭔가 새로운 기술이나 새로운 방법론을
시도해볼지?
• 프로젝트 멤버들에겐 뭐가 더 재밌을까요?
(물론 재미를 따질 여유 따윈 없으신 분들도
계시겠지요… /애도)

7. 그래서,
• ‘변화’를 주는 것이 더 재밌다고 생각했기
때문에 변화해보기로 합니다.
• ‘원칙적으로는’ or ‘이상적으로는’ 그렇게
하는 것이 ‘맞다’ or ‘좋다’고 생각되는 거면
그렇게 하기로 합니다.

8. Phase 1
‘새로운’ 서비스를
‘새로운’ 기술과
‘새로운’ 방법론으로
만들어보자.

9. Phase 1
‘새로운’ 서비스를
‘새로운’ 기술과
‘새로운’ 방법론으로
만들어보자.
기존 서비스와 무관하도록
쓰고 싶은 기술들을 마음껏 쓸 수 있도록
사람들이 일하는 방식이 달라질 수 있도록

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. Phase 1 : Architecture
• Frontend와 Backend를 명시적으로 분리하고,
각각 독립적인 개발/배포가 가능하게 한다.
• Frontend와 Backend는 REST API를 사용하여
통신하며, Stateless Architecture여야 한다.

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. 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. 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. Phase 1 : Backend
• Goodbye MyBatis & Hello ORM
– Model-Driven 구조
– DDL 자동생성 (Production 제외)
– ERD 그리느라 시간 낭비하지 않음
– 실행 시에는 MySQL, Unit Test 시에는 H2 사용
• ORM 성능 우려?
– 필요하면 Second-Level Cache 적용
– 그걸로도 안되면 Native Query 사용
– 그걸로도 안되면 DB 튜닝

16. Phase 1 : 방법론/프로세스
• Project Charter 작성
– 프로젝트 개요, Scope, 마일스톤
– 커뮤니케이션 위치(Wiki, JIRA, Agile Board, Git)
– 프로젝트 원칙, FAQ
• Scrum 도입
– JIRA Agile 적극 활용
– Sprint 계획/실행/리뷰
• Git
– 처음엔 별다른 Branch 정책 안 둠
– 그냥 일단 Git부터 익숙해지기

17. Phase 1 : 방법론/프로세스
• 프로젝트 원칙
– Sprint 기간 중에는 모든 멤버가 Sprint의 항목에 대해서만 집중한다.
– Sprint 항목은 Sprint 기간 내에 완료되어야 하며, 구현 항목에 대해 배포가
가능한 형태로 시연이 가능해야 한다.
– Dogfooding
– 모든 구성원은 자발적으로 필요하거나 누락된 항목이나 문제점, 더 좋은
아이디어가 있으면 제안하고, 서로 협력한다.
– 개발하는 모든 과정이나 나오는 산출물을 숨기지 않는다. 개방된
마음으로 지적질을 수용한다.
– 팀, 회사 차원의 개발에서 Best Practice를 만든다는 생각으로 임한다.

18. Backend 개발자Frontend 개발자
Phase 1 – 방법론/프로세스
UserStory 검토
Contract/API 설계
Frontend 개발 Backend 개발
Mock/Unit Test Unit Test
API 연동 Load Test
UserStory 종료

19. Phase 1 결과
• 새로운 서비스를 Beta 오픈했고,
• 새로운 기술을 습득하고 검증했으며,
• 새로운 방법론/프로세스에 대해 적응
• Stakeholder들의 긍정적 Feedback
• 무엇보다, 프로젝트 멤버들이
‘성취감’과 ‘재미’를 느꼈다는 점

20. 그럼, 2차 가야죠?

21. Phase 2
‘기존’ 서비스들 + @를
‘더욱 새로운’ 기술과
‘더욱 새로운’ 방법론으로
‘더 많은’ 사람들과
만들어보자.

22. Phase 2
‘기존’ 서비스들 + @를
‘더욱 새로운’ 기술과
‘더욱 새로운’ 방법론으로
‘더 많은’ 사람들과
만들어보자.
마이그레이션, 이행을 고려해야 함
세상은 넓고 새로운 기술은 많다
보다 나은 개선을 위한 실험
피자 두판을 넘어간다면..?

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. 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. Phase 2 : Architecture
• MSA를 선택한 이유
– Frontend – Backend 분리 + 기능 영역의 분리
– API 기반의 Contract 유지를 강제화
– 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리
– Micro-Service 단위로 이해하고 개발하기 쉬움
– Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할
수 있음(Polyglot)

26. Phase 2 : Architecture
• MSA를 선택한 이유
– Frontend – Backend 분리 + 기능 영역의 분리
회사의 Engineer Tech Tree(Frontend/Backend)와 동기화
– API 기반의 Contract 관리를 강제화
API로 뽑아내지 않으면 아무것도 못하니까
– 빌드/배포 용이, 확장 용이, 장애로 인한 영향 격리
Micro-Service 단위로 격리되니까
– Micro-Service 단위로 이해하고 개발하기 쉬움
코드의 양을 줄여서 누구나 쉽게 파악할 수 있도록
– Micro-Service 단위로 다른 프로그래밍 언어/프레임워크를 사용할
수 있음(Polyglot)
실험해보고 싶은 거 맘대로 시도(써보고 아님 말고)
향후 개발자 구하기도 용이할 걸?

27. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?

28. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
어떻게 해결해야 할까?

29. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
어떻게 해결해야 할까?
고갱님, 유료 서비스입니다
미안, 이건 다음 시간에…
(사실 현재진행형이라)
그리고 Google 신에게 물어보세요

30. Phase 2 : Architecture
• 물론, 수많은 단점들이 있다
– Micro-Service를 얼마나/어떻게 나누어서 설계해야 할지?
– Contract (API) 관리를 어떻게 해야 하지?
– 기존에 개발자 혼자서 하면 되던 기능이 여러 명의 개발자(예:
Frontend 개발자, 다른 Micro-Service 개발자)와 협업을 해야 하는
경우들도 생긴다
– 세션은 어떻게 관리해야 하나?
– 서비스 간 의존성/트랜잭션 관리는 어떻게?
– 코드의 중복이 발생
– 배포/운영이 생각보다 머리 아픈데?
무엇보다도,
우리는 이 단점들을 극복해가는 과정을 즐기고,
MSA가 가져주는 장점이 훨씬 더 크다고 믿습니다.
Remind:
‘원칙적으로는’ or ‘이상적으로는’ 그렇게 하는 것이 ‘맞다’
or ‘좋다’고 생각되는 거면 그렇게 하기로 합니다.

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. 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. 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. Phase 2 : 방법론/프로세스
• Pair Programming
– Frontend, Backend, Test별 Pair
• 2개의 Scrum
– 적절한 인원 유지를 위해
• Rules & Conventions
– 팀원 간의 암묵적 지식을 명시적으로 문서화
– 각 Scrum 간 공유
• Sprint Review 시 Code Workshop 실시
– 서로 간의 지식을 공유

35. Phase 2는 현재 진행형
우린 아마 안될거야
분명히 잘 될거예요,
변화가 재밌으니까.

36. Let’s change.
End of Slides