재업로드주소: https://www.slideshare.net/hnki0104/gsshop-103837144

개발 방식의 화를 위한
GS SHOP 고군분투기
GS홈쇼핑 IT개발팀
2018. 7. 2
2018. 7. 4

1) 저 이 부분을 봐주 요.^^
2) 그 다음에 이 부분을 봐주 요.~
본 문서를 재미있게 읽으려면..
주의 !!! 
본 문서에는 은 인 을 맺으려는 다소 유혹적인 구인 내용이 포함되어 있습니다.

평범한 직장인이자 한 집안의 가장입니다.
WORK LIFE
Darion <-> 율이아빠
기술에 관심이 많고 가족의 행복에 관심이 많습니다.
Spoc
Wolverine
D.Y.
Frantz
Jeff
Yul

GS SHOP을 소개합니다.
다양한 고 경험 제공을 위해
IT를 비즈니스에 응용합니다.
* 모든 상품을 소싱하는 
하지는 않음

IT개발팀 업무 영 입니다.
요기...
경영실적이 안정적이네요.^^
저희는 기간계라고
부릅니다.

세상이 디지털로 변하고 있습니다.
Analog Digital
전통적인 산업 경계를 무너뜨리고 신적이고 새로운 시장을 만들어내는
기 들이 생겨난 배경에는 디지털 기술이 있습니다.
Disruptor
SpaceX-항공우주 Airbnb-호텔,여행Uber-대 교통

디지털 화에 맞게 회사도 변하고 있습니다.
판매 데이터 분
고 예측
Monolithic
Microservices
데이터의 화
인프라의 화

세상이 너무나도 빠르게 변하고 있기에
이제는 요청받는대로 모든 것을
전부 다 개발할 수 없습니다.
회사의 화에 맞게 IT도 고민하고 화하고 있습니다.

우리는 과연 가치있는 것들만 개발하고 있는 것인가?
그래서 의문을 가져 봅니다.

잠.깐.만~ 현업을 아시나요?
현업(실제 사용자) 개발자
이 에는 간단해요.
이렇게 바꾸면 되지 않아요.
이게 제가 생각한거 하고는 
다르네요.
if 어야... for 돌려야...
하드코딩 박을 수 밖에...
이거 어려운건데요.
오래 걸리수도 있어요.
납기까지 맞추기 힘들어요.
현업과 개발자의 갈등은 사소한 오 와
소통의 부재에 시작됩니다.

IT의 영향이 미치지 않는 청정지 에 살고 계신 분들도...
그래서 저희는 IT라는 거대한 산을 올라설때  
쉽게 명해드리고 도와드리는 Sherpa 할도  
하고 있습니다.
IT

개발자와 현업에 대해 관점의 차이를 느꼈습니다.
문제 분 기술 접근
파일럿 개발
(운영 전환)
서비스 완성
기능 이
미지의 세계
비지니스 속도 
(빨리빨리)
방 론 아키텍처
점진적 확장
(깔끔하게)
개발자
현업

일하는 방식에 화를 시도하고 있습니다.
요
청
납
기
현업 IT
가치있는 것을 
개발하고 있는가?
이미 정의된 양식에
요청하고
납기일에 맞춰
우선 순위로
개발함.
요청과 납기의 단방향에 커뮤니티 네트워킹에 의해 지속적으로
다양한
커뮤니티 그룹의
팀과 프로젝트가  
생성됨.
텍스트,이미지,동영상부터
움짤,이벤트,설문,
챗팅,라이브영상까지
다양한 콘텐츠 교환

화를 선행하는 TF도 구성하였습니다.

작고 빠르게 개발 할 수 있는 방 을 찾아야만 했습니다.
전통적인 개발환경에 클라우드기반의 다양한 개발환경
적정기술 사용하기
빠른 프로토타이핑 머신러닝 연동 레거시 개발자 협업

화의 속도에 대해 우리의 한계를 극복해 보자.
그래서 가치있는 개발을 할 수 있는 것 일까요?

H/W
OS
WAS
Framework
Business Logic
Cloud
WAS
Framework
Cloud
Logic
SaaS
API
Logic
Framework
개발자 참여에 대한 화도 필요합니다.
전사 통합 시스템 아키텍처의 범위내에
기존에 개발된 비지니스 영 에 추가하거나 수정
* 개발자의 택 영 이 제한적임.
개발자가 택할 수 있는 영
Monolithic Type
Microservice 
Type1
Microservice 
Type2
Microservice 
Type3
Integration API 호출 (제한적) 개발자가 API와 API를 연결
Type1 : 개발 어에 적합한 WAS를 택하여 개발 함.
Type2 : 플랫폼 서비스에 택한 개발 어로 개발하여 배포 함.
Type3 : 목 에 맞는 SaaS 택하여 API로 연동 함.
* 개발자의 택 영 이 어짐.
* 작은서비스 단위로 개발
* API와 API의 성능을 고려하여 연결해야 함.
제한적이고 수동적인 환경에 극적이고 자발 인 참여로

앗~ 우리가 잠시 잊은 세상이 있습니다.
레거시(Legacy)
기술 스펙이 절대 바뀌지 않아 고민하고
보안때문에 불편한게 많아 절망하고
클라우드 연 은 상상도 못하는 난공불락의 성

그 거대한 성벽에 구멍을 뚫어보았습니다.
이제 레거시(Legacy)에 는
상상하지 못했던 일들이 일어납니다.

Kong은 오픈소스 API Gateway 입니다.
Basic Key
OAuth2 JWT
HTTP File
Rate 
Limiting
Request 
Limit 
Size
라우팅(Routing)
- Request Host Header(*)
- Request Path
- Request Http Method
레거시에 관리하는 API들을 서비스로 노출하는 용도로 사용합니다.
이에 라우팅과 인증과 로깅과 서비스 제한 기능이 필요하였습니다.

https://gist.github.com/StevenACoffman/acf1133da6c5ff5226c0f6eb8fbd8132
다양한 Microservice Proxy Gateway가 있습니다.
MicroService Proxy Gateway Solutions (Github Star Trend)
는 기능이 제일 고 은 심장 뛰게 개발 할 수 있지만 으로 작고 가볍게 시작할 수 있었습니다.
Linkerd ZUUL KONG

저에게 API Gateway 란?
이놈 하나를 tank siege mode로 제일 앞에 박아두면
서비스에 어떠한 화(?)가 있 지 간에
클라이언트에 받는 모든 요청을 영향없이
유연하게 대응할 수(?) 있다.
-Darion-

예 에는 생각조차 하지 않은 고민이 있었습니다.
클라우드에 레거시 데이터를 활용할 수는 없을까?
그러면 더 빨리 개발 할 수 있을 텐데...
클라우드+레거시

이제는 레거시 API를 클라우드 서비스로 재사용 할 수 있습니다.
API 
Gateway
Legacy
Legacy
HTTPS/TLS
* 이 를 돕기 위해 간단한 구조로 작성하였습니다.
New Cloud Service with Legacy Data
클라우드+레거시

저희의 레거시에 대한 궁극적인 고민은 바로 이것입니다.
이봐 ~
우리의 레거시는 점점 더 복잡해지고 비대해지고 있어.

고민을 해 하기 위해 Satellite 프로젝트를 띄웠습니다.
레거시(Legacy)
Cloud API 
인공위성
Cloud API
인공위성
Cloud API
인공위성
Cloud API
인공위성
Cloud API 
인공위성
Cloud API 
인공위성
(인공위성?) (아마 행성일듯)

Satellite는 레가시 서비스를 클라우드에 개발할 수 있습니다.
API 
Gateway
Legacy
HTTPS/TLS
Amazon 
RDS
RIA Client
RIA Server
신규 RIA
API 호출
이전 RIA
API 호출
RIA Server
Proxy
API Service
API Service에
외부의 Open API를 호출
레가시에 의 클라우드 연 은 개발의 새로운 화를 가져오고
외부의 Open API를 사용할 수 있기에 빠르게 개발 할 수 있습니다.

Satellite는 기존 레거시에 많은 화를 가져왔습니다.
점점 복잡해지는 레거시에 클라우드를 활용하여  
API로 분리해서 개발하여 덜 복잡한 코드를 갖게 되었습니다.
레거시에 고민하고 어려워하는 허들인 신기술 적용,
외부 API 서비스 활용을 뛰어넘을 수 있습니다.
콩펀치 쓰리강냉이

그렇다고 레가시의 구 개 은 아닙니다.
Monolithic
Microservices
Innovation Deep Dive(?)
MSA로의 구 개 은 아닙니다.
(구 개 전문 파트도 따로 있습니다.)
교육은 샌프란시스코에

개발자의 정과 비지니스의 가치도 구분해야 했습니다.
더 빨리 개발 할 수 방 이 있을까요?
개발자의 정 vs 비지니스의 가치

텍스트를 분 하여 자동으로 답변해보자.
사례공유1) 댓글요정 프로젝트(파일럿)

머신러닝 광풍에 영향받아 기술 습득을 저 접근하였습니다.
Word2Vec
각종
머신러닝
서적
3개월 소요(?) 2주 소요
댓글요정 프로젝트
정확도가 많이 떨어지는 것
같아요. 
정확도는 제 아질까요?
기능을 확인해보니 사람이
말로하는 것보다 불편다는
것을 확인했고 시나리오 설
계가 더 요하다는 것을
알았다.
IBM Watson 
Conversation
Business
Logic
Model
아~ 파도파도 끝이 없네.
전 처리의 끝은 어디인가?
의도를 예측하고 추 하는
보다 정밀한 API 서비스들
이 필요하다.
텍스트 분
API
챗팅서비스
챗팅서비스
기본원리 및 개 학습 후 기술 습득 SaaS 활용으로 빠른 과 제공
스피커? 셋탑?
비교평가 (X)

이미지를 인식하여 자동으로 분
사례공유2) 오란-씨 프로젝트
업무 자동화
OCR은 이미지의 내용을 파악하는 기술.
사람이 일일이 눈으로 확인하고 엑셀파일에 옮겨적는 것을  
자동화하여 업무 효율을 개 해보자.
OCR ORAN-C

고 경험 확인을 저 접근하였습니다.
2주 소요
과를 보고 사용할지 빠르
게 판단할수 있다.
Business 
Logic
빠르게 기능을 구현하여
과를 빠르게 보여줄수 있
다.
2주간 으로 과 확인
Cloud
Vision API
새로운 기능 추가
새로운 툴 개발
개 과 원리 확인 및 기술 개
업무 자동화 확대
SaaS 활용으로 빠른 과 제공 새로운 기능,툴 개발의 선순환 구조 전환
비교평가(O)

정리하면...
주요 포인트는 세상은 변하고 회사도 변하고 IT에 개발하는 방식도  
변하고 있는 것입니다.
(1) 요청받고 납기일에 맞추는 정해진 방식에 헤쳐모여식 사내커뮤니티
그룹에 함께 가치를 빠르게 확인하는 방식으로 화하고 있습니다.
(2) 개발 빠르게하기에는 우리의 레거시는 아주 복잡하고 너무 뚱뚱해요. 
그래서 다이어트를 위해 API Gateway로 구멍을 뚫고 클라우드에  
인공위성 서비스를 띄워 개발하며 화하고 있습니다.
(3) 개발은 청난 기술을 습득해서 빠르게 코딩하는 것이 요한 것이라 
생각했었는데 실제 이런것들을 해보니 과물을 빠르게 보여주고 판단
할 수 있게 하는 것이 더 요하다는 것을 알고 화하고 있습니다.
이것이 개발방식의 화를 위한 GS SHOP 고군분투기 입니다.

신은 신하고 싶으신 분들이 오셔서 해야합니다.
바로 이곳입니다.^^

재업로드주소: https://www.slideshare.net/hnki0104/gsshop-103837144

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 재업로드주소: https://www.slideshare.net/hnki0104/gsshop-103837144

Similar to 재업로드주소: https://www.slideshare.net/hnki0104/gsshop-103837144 (20)

More from Darion Kim

More from Darion Kim (14)

재업로드주소: https://www.slideshare.net/hnki0104/gsshop-103837144