테크 블로그 TechBlog

마틴파울러가 이런 얘기를 했습니다.

만약에 여러분이 기존시스템을 빅뱅방식으로 개발하고 오픈한다면,

여러분을 기다리고 있는 것은 빅뱅과 같은 혼란과 어려움만이 기다리고 있다라고 했습니다.

 

AWS Industry Week 발표 중 한동훈 솔루션즈 아키텍트의 이야기 ...

---

안녕하세요. GS SHOP 주문서비스를 담당하고 있는 김헌기입니다. 회사에서는 Darion으로 불리웁니다.

애플리케이션 현대화에 대한, 주문서비스팀의 실무 경험담에 대해 이야기해보겠습니다.

현대화로 해결해야만 했던 기술부채, 현대화 도전에 대한 고민과 경험, 현대화 이후 일하는 방식의 변화에 대해 이야기를 하려고 하는데요.

엄청난 것을 한 것은 아니고요. 비슷한 고민이 있는 사람이면, 클라우드 환경에서, 누구나 한번 시도해 볼 수 있는 이야기입니다. 재밌게 들어 주셨으면 하고요. 주문서비스팀의 경험이, 여러분의 문제 해결에 도움이 되었으면 합니다.

 

1. 기술부채 공감하기

1) 주문서비스팀 미션

애플리케이션 현대화는, 기술부채를 해결하기 위해 시작하였고요. 기술부채에 대해 공감을 하려면, 먼저 주문서비스팀의 미션에 대한 이해가 필요합니다.

 

주문서비스팀은 크게, 영업 매출 증대와 고객 경험 개선의, 2가지 부분에 기여하고 있습니다.

 

영업 매출 증대 사례를 이야기해보면, 특정 기간동안 상품을 많이 팔기 위해, 특집이라는 이벤트를 진행합니다.

올해 5월에, 혜자로운 상상초월이라는, 특집을 진행했는데요. 김혜자 선생님은 다들 잘 아시죠. 도시락이 꽤 많이 팔린 것으로 유명한데, 관련하여 다양한 마케팅 정책들이 반영되었습니다.

이렇게 특집을 진행하기 위해서는, 다양한 영업전략이 있고, 전략에 따른 정책들을, 빠르게 반영해야 하기에, 비지니스 민첩성은 회사의 중요한 역량이고요. 주문서비스팀도 비즈니스 민첩성을 위해 기여하고 있습니다.



다음으로, 고객 경험 개선 사례를 이야기해보면, 회사는 고객 중심의 철학이 있고, 이 철학을 기반으로, 고객경험 개선에 대해 노력을 하는데요.

참고로, GS SHOP은 작년과 올해, 한국 서비스 품질지수, TV홈쇼핑 부문의 서비스 만족도에서, 1위를 하였습니다.

고객경험 개선에 대해, 주문서비스팀과 관련 된 부분으로, 쾌적한 주문속도를 보장하자고 정의하였는데요.

주문서비스팀도 고객 경험 개선을 위한, 서비스 품질 보장에 기여하고 있습니다.

 

성공적으로 미션을 완료하기 위해서는, 비지니스를 민첩하게 연결하거나, 서비스 성능 개선에 기여해야만 한다고 말씀드렸는데요. 이를 실행 할 수 있는 것이, 양질의 코드를 빠르게 배포하여 서비스에 반영하는 것입니다.

참고로 주문서비스팀 멤버들은, 모두 개발자로 구성되어 있고요. 코드를 작성하는 기본 역량을 갖추고 있습니다. 업무에 따라 페어프로그래밍을 하거나, 코드리뷰를 하고 있고요. 회고를 통해 개발문화를 발전 시키고 있습니다.

 

2) 페인 포인트 (Pain Point)

앞서 주문서비스팀 미션에 대해 이야기했는데요.

주문서비스팀 미션에 따라, 양질의 코드를 빠르게 배포하면 되는데, 그렇게 하기 어려운 구조나 환경이, 페인 포인트라고 먼저 말씀드립니다.

구체적인 페인 포인트는 2가지 정도 이야기 할 수 있는데요.

첫번째 페인 포인트는, 고객 상품 방송 주문의 업무도메인이, 하나의 프로젝트에 복잡하게 얽혀 있는 상황인데요. 각 업무도메인의 개발자들이, 코드의 의존성이나 영향도 때문에, 배포순서에 줄을 서야 하는, 비효율적인 부분이 발생하고 있었습니다. 이러한 병목으로 인해, 코드 배포는 더 이상 빨라 질 수 없었는데요.

수 조 단위 영업실적을 처리하는 시스템이고, 기능은 잘 동작하고 있기에, 개선을 위한 리팩토링 보다는, 안정적인 운영 쪽으로 집중하게 되었습니다.

그래서 15년 전에 작성되기 시작한 코드가, 현재는 만 라인 단위까지 증식되어, 기존 환경에서는 구조를 크게 건들기 어려운 상황까지 이르렀습니다.

 

두번째 페인 포인트는, 이렇게 복잡하게 얽힌 단일 프로젝트가, 하나의 소스로, 여러 개의 채널연계 서비스에 배포되는 환경인데요. 채널연계 서비스는 모바일, 웹, ARS 등의 각각 주문채널에서 들어오는 주문요청을 처리하는 서비스입니다.

초기에는 각각의 주문채널별로, 서비스를 대응하는 정책이 있었고요. 문제가 생겨 장애가 발생하면, 전체 장애로 전파되는 구조였습니다. 당연히 장애 때문에, 개발자들은 배포에 대한 두려움을 가질 수 밖에 없었고요. 그때는 옳은 결정이 있었지만, 지금은 달라져야 한다고 생각하기에, 이러한 문제를 해결하기 위해, 업무 도메인별로 분리되어 독립적으로 운영되어야 한다는, 방향성을 잡아 나가기 시작했습니다.

코드를 빠르게 배포하기 어려웠던 구조나 환경이, 기술부채라고 다시 한번 강조해서 말씀드립니다.

3) 레거시 시스템 (Legacy System)

기술부채에 이어, GS SHOP 주문서비스 레거시 시스템에 대해서도 이야기 해 보려 합니다.

인터넷 환경에서 대고객 주문 요청을 받아, 이커머스 핵심 비즈니스를 처리하는 기간계와 결제서비스인 PG와 같이, 외부 서비스를 활용하는 대외계가 있는, 전통적인 시스템 구조이고요.

   

복잡도가 높은 서비스들이,  연결되어 있는 상황에서, 빠르게 주문을 처리해야 되기에, 항상 긴장을 늦출 수 없고, 잠시라도 쉴 틈이 없는 상황입니다.

마치 빠르게 달리는 기차와 같다고 표현하고 싶은데요.

고객의 주문에 대해, 실시간으로 입금확인을 해야 되는 것이 주업무라, 달리는 기차의 속도를 가장 실감나게 체감하고 있습니다.

약간의 논란의 여지가 될 수도 있는데, 고객의 불만이 발생하면 상담원이 대응을 하거나, 상품정보가 잘못되면 잠시 전시를 중단하거나, 물류에서 문제가 발생하면 출고마감까지 처리하면 되는 것들과, 주문에서 대응하는 속도의 차이가 다르다는 것을, 말씀드리고 싶습니다.

이러한 환경속에서, 주문서비스팀이 애플리케이션 현대화를 하는데 있어, 또 다른 어려운 상황에 직면해 있었다는 것을, 공감해 주셨으면 합니다.

 

5) 접근 전략 (Strategy)

기술부채를 해결하기 위해서는, 현대화에 접근하기 위한 전략 수립이 필요하였는데요.

물밀듯이 들어오는 주문요청 상황에서도, 마치 달리는 기차의 부품을 갈아 끼워야 하며, 심지어는 바퀴도 깔아 끼워야 하는 방법에 대한 고민이 많았습니다. 그리고 이전에 몇번의 시도를 통한 실패의 교훈도 있었고요.

복잡도가 높은 이커머스 비즈니스라는 것을 간과하고, 빅뱅으로 하려 했거나, 기술로만 접근 하려해서, 해결하기 어려운 상황들이 발생이 되었고요. 중간에 포기 할 수 밖에 없었습니다.

기존 것을 고치기 보다는, 새로운 환경에서 새로운 구조로 하는 것이, 가능성이 있다고 판단하였고,

IDC에서 클라우드 환경으로 이전하기로 의사결정은 했지만, 빅뱅으로 전환하기는 어렵다고 판단했습니다.

점진적인 방식으로 하기 위해, 애플리케이션 현대화에 대한 사례 검토와 검증을 하였고, 교체해야 되는 필요한 부품들의 용도를, 잘 파악하여 선별하였습니다. 예를 들어 아마존 EKS나 MSK 오픈서치 오로라DB 등이 있는데요. 클라우드 환경이기에, 직접 만들거나 설치하기 보다는, 서비스 기능을 이해하고 손쉽게 활용하는 것으로 원칙을 세웠습니다.

 

2. 현대화를 위한 도전

1) GS SHOP 빌더들의 이야기

다음으로 현대화를 위한 도전에 대해서 말씀 드리려고 하는데요.

이 시점에서 말씀드리고 싶은 것이, 현대화를 위한 도전은, 기술에만 국한되지 않았다는 것입니다.

앞서 몇번의 실패 교훈으로, 전통적인 방식과는 다르게, 개발 문화를 바꾸면서 접근하는 것이 필요하다고 생각했고요.

그라운드 룰로, 작은 부분부터 실행하는 것을 강조하였습니다. 대부분 완벽하게 한방에 하려다가, 의사결정 장애에 빠지는 경우를 많이 보았고요. 한번에 완벽하게 하지 말고, 버전 0.1부터 시작하여 작게 지속적으로 연결되게끔 하였습니다.

 

멤버분들에게, 항상 방향성을 제시할 때 먼저 이야기하는 것이, 우리의 눈높이는 높습니다. 우리는 할 수 있습니다. 우리는 한 팀입니다. 라고 이야기 하는데요. 혼자하기 보다는 함께하고, 서로 밀어주고 끌어주는, 개발문화를 만들어 나갔습니다.

 

아마존에서 빌더란 개념이 있어서 소개해드리면, 빌더란 혁신을 좋아하며, 다양한 고객 경험을 살펴보고, 이를 재혁신하는 방법을 모색하는 사람으로 정의하였는데요.

현대화에 도전하기 위해, 문제 해결을 추구한 방향과, 경험한 결과의 내용이, 빌더와 부합되었기 때문에, 이번 발표의 제목으로 반영되지 않았을까 생각해봅니다.

 

2) 달리는 기차의 바퀴를 갈아끼우는 고민

주문서비스의 레거시시스템이, 멈출 수 없는 달리는 기차와 같다고 말씀을 드렸는데요. 이 기차의 바퀴를 갈아 끼우기 위해서는, 업무도메인 간의 의존성을 해결해야 되는 고민거리가 있었습니다.

주문 기준으로 업무도메인 간의 관계에 대한 이해가 필요한데요.

하나의 주문이 생성되기 위해서는, 고객 상품 방송의 정보가 필요하고, 주문 스냅샷이 만들어지면, 물류에 출하지시 명령을 내리고, 협력사 정산까지 이어집니다.

순서상으로는 정보를 제공하는 고객 상품 방송과 같은, 메타데이터성 업무도메인이, 먼저 분리되는 것이 맞다고 생각하고요. 다음으로 스냅샷을 만드는 주문이 분리되어야 하는데, 내부적인 이슈로 주문이 먼저 분리되어야 하는 상황이 발생하였습니다.

업무도메인간 기존 연결을 유지하면서, 주문만 분리하는 방법에 대해 고민 할 수 밖에 없었는데요. 이에 대한 해법으로 스트랭글러 패턴에서 영감을 얻었습니다.

 

주문 생성 시, 고객 상품 방송에 대한 정보를, Java API로 호출하는 것과 동일하게 하기 위해, 리모트/사이트카 라는 레이어를 만들었고요. RESTful API로 전환하면서, Java API를 호출하는 것과 동일하게 하여, 변경에 대한 영향을 최소화하였습니다.

문제가 아예 없었던 것은 아닙니다. 트랜잭션을 분리하니, 다양한 이슈들이 나오기 시작했고요. 데드락이 발생하거나 커밋 전 데이터 참조 에러, 롤백 시 보상처리 등의 이슈가 발생하여, 이를 해결하는데 집중하여야만 했습니다.

 

3) 달리는 기차의 바퀴를 갈아 끼우기 I

달리는 기차의 바퀴를 갈아 끼우는, 첫번째 실무 경험담입니다. 고객의 주문을 받는 각각의 주문 채널들이, 기존 ESB 레거시 환경에서, 새로운 API Gateway 클라우드 환경으로, 전환 한 이야기고요.

바퀴를 갈아 끼울 수 있는 환경이 만들어 진 것을 좀더 구체적으로 말씀드리면, IDC에서 클라우드로 환경을 이주했고요. 클라우드 환경에 주문 로직만 분리하여, 서비스 할 수 있는 준비가 되었습니다. 다양한 주문채널의 유관부서와 소통하여, 순차적으로 전환하는 것에 합의하였고요.

기존에 주문채널의 요청을 받아주는, ESB에서 새로운 API Gateway로, 기존 인터페이스 방식을 변경하여 전환하는 것이라, 주문채널 쪽 변경사항은, 필수적으로 발생하게 되었고요. 전환 시에는 장애 없이 주문을, 무중단으로 계속 받아야 하기 때문에, 주문채널의 유관부서에서는 부담감이 있었고요. 주문서비스를 제공하는 입장에서, 이를 최소화 하려고 고민했습니다.

각 유관부서에 기존에 잘 돌아가는 서비스를, 보다 나은 미래를 위해서, 구조 변경을 해야 된다고, 설득하는 것이 필요했습니다.

주문 업무가 변경되는 것이 아니기에, 로직 및 성능에 대해 검증을 하는 것이 최우선이라 생각하였고요. 좀더 안전하게 하고, 자신감을 키우면서 하기 위해, 개발환경에서 먼저 EBS에서 API Gateway로, 인터페이스별로 라우팅 정책을 조정하여, 주문채널에서는 변경사항이 없게 하였고요. 개발환경에서의 검증 성공의 결과로, 신뢰성을 확보하게 되었습니다.

나름 잘 준비했다고 자신했는데, 그래도 장애는 있었다고 말씀드리고 싶었고요. 장애가 나면 개인적으로 심장이 말랑말랑해 지는 느낌이 들더라구요.

장애가 발생하더라도, 실수를 두 번 다시 하지 않게 함께 검토하고, 또 다시 실행할 수 있게 하는 스폰서십 있었기에, 가능했다고 생각하고 있습니다.

 

4) 달리는 기차의 바퀴를 갈아 끼우기 II

다음은 달리는 기차의 바퀴를 갈아 끼우는 두번째 실무경험담입니다.

주문과 물류 업무 도메인이, 주문 상태를, DB 테이블 기반에서 실시간 이벤트 기반으로 공유하는 것으로, 전환하는 이야기입니다.

배경 설명을 위해 주문/물류 프로세스를 잠깐 말씀드리면, 주요 주문상태는 주문접수, 입금확인, 출하지시, 출고완료, 배송완료가 있는데요.

주문접수, 입금확인은, 주문에서 관리하여, 고객에게 주문 시 입금을 받는 역할을 하고요.

출하지시, 출고완료, 배송완료는, 물류에서 관리하여, 고객에게 상품을 배송하는 역할을 합니다

주문과 물류는 DB테이블을 함께 사용하고, 각각 배치 처리로 주문상태를 함께 업데이트하여, 서로 강한 의존성을 가지고 있는데요. 향후 주문서비스 품질을 보장하기 위해서,는 주문DB 분리가 필수인데, 물류와의 강한 의존성이 있기 때문에, 이 부분을 제거하지 않으면, 향후 주문DB 분리에 커다란 걸림돌이 되는 상황이라, 꼭 해야만 되는 것이었습니다.

물류서비스팀과 함께 설계 협의를 하여, 아마존 MSK를 활용하여, 실시간으로 주문상태를 전달받기로 하고, 주문 상태에 대한 DB 업데이트는, 주문서비스팀에서 처리하는 것으로 합의하였습니다.

기존에 배치 처리와 새롭게 연결한 실시간 이벤트 처리를, 병행하여 운영하기로 하였고요. 이를 검증하기 위해, 별도의 검증용 테이블을 만들어 검증 후 전환에 대해서는, 함께 의사결정하기로 하였습니다.

이 또한 문제가 없었던 것은 아닙니다. 실시간 이벤트 처리로 구조변경에 따른, 주문상태의 순서보장 이슈가 발생하였고요. 정공법으로 하나 하나씩 잡아 나갈 수 밖에 없었습니다.

 

5) 비즈니스 재사용하기에 집중

애플리케이션 현대화를 진행하면서, 개발 프로세스에서는, 비즈니스 재사용 부분을 집중하고, 이를 개선하기 위해 노력하였습니다.

기존에는 코드에 대한 신뢰성이 떨어져, 똑같은 패턴에 대해서 복붙하여 개발하는 것이 성행하였는데요. 유지보수 비용이 많이 들고 관리도 어려워서, 코드를 재사용 해야 된다는 목소리가 높아졌습니다.

주문이 새로운 환경으로 분리되니, 주문 로직에만 집중 할 수 있게 되어 좋았고요. 기존보다 설계에 대해 빠른 의사결정을 할 수 있었습니다.

 

기존의 레이어드 아키텍처가 나쁜 편은 아니었는데요. 새로 참여하는 개발자에게는, 항상 별도의 비표준적인 교육을 해야만 했었고, 심지어는 구두로 내려오는 것들이 전해지고 있어, 이 부분에 대한 개선이 필요했습니다.

Java Spring 개발자면, 누구나 애플리케이션 레이어의 역할을 인지하고, 재사용 할 수 있게 표준화를 진행하였습니다.

 

데이터 구조나 행위에 대한 재사용도 중요하게 생각하여, 재사용 가능한 컴포넌트나 엔티티를 확대하였는데요.

클라이언트의 영향도를 최소화 하기 위해, 애플리케이션 레이어별로 DTO를 두고, 각각의 역할을 정의하여 재사용을 확대하였습니다.

우선은 클라이언트 변경사항의 최소화에 중점을 두고, 그동안 습득한 비즈니스 노하우를 가지고 요청과 응답에 대한 데이터구조인 DTO를 정의하였고요. 비즈니스 레이어에서는, 상태변경과 조회 그리고 정보 성격의 DTO로 구분하였습니다. 인프라스트럭처 레이어에서는, DB에 대한 상태변경과 조회 그리고 API나 이벤트에 대한 DTO로 구분하여, 하나 잘 만들어 놓으면 다른 개발자들이 쉽게 가져다 활용하는, 선순환 구조로 개선하였습니다.

클라이언트와 약속 된 행위는 명확히 정의하고, 뒷단에서는 내부적으로 언제든지 리팩토링 할 수 있는 설계 구조를 추구하였는데요. 처음 만들 때는 손이 좀 가지만, 활용하는 개발자들이 많아 질수록, 코드품질은 계속 높아지게 되더라구요.

 

데이터 구조나 행위에 대한 재사용도 중요하게 생각하여, 재사용 가능한 컴포넌트나 엔티티를 확대하였는데요.

클라이언트의 영향도를 최소화 하기 위해, 애플리케이션 레이어별로 DTO를 두고, 각각의 역할을 정의하여 재사용을 확대하였습니다.

우선은 클라이언트 변경사항의 최소화에 중점을 두고, 그동안 습득한 비즈니스 노하우를 가지고 요청과 응답에 대한 데이터구조인 DTO를 정의하였고요. 비즈니스 레이어에서는, 상태변경과 조회 그리고 정보 성격의 DTO로 구분하였습니다. 인프라스트럭처 레이어에서는, DB에 대한 상태변경과 조회 그리고 API나 이벤트에 대한 DTO로 구분하여, 하나 잘 만들어 놓으면 다른 개발자들이 쉽게 가져다 활용하는, 선순환 구조로 개선하였습니다.

클라이언트와 약속 된 행위는 명확히 정의하고, 뒷단에서는 내부적으로 언제든지 리팩토링 할 수 있는 설계 구조를 추구하였는데요. 처음 만들 때는 손이 좀 가지만, 활용하는 개발자들이 많아 질수록, 코드품질은 계속 높아지게 되더라구요.

 

6) 도전 과정 및 최종 목표

지금까지 말씀드린 도전의 과정을 정리해 보면

마일스톤1에서는, 인프라의 현대화를 진행하여 IDC에서 클라우드로 인프라 구조나 환경을 변경하였고요. 새로운 CI/CD 파이프라인을 구성하고, 애플리케이션 로그 통합으로 보다 효율적인 업무를 수행하였고, API Gateway를 활용하여 클라이언트 영향도를 최소화 하면서, 내부적으로 인프라 구조를 조정하면서, 리팩토링이 가능하게 구성하였습니다.

마일스톤2에서는 애플리케이션의 현대화를 진행해서, 애플리케이션 아키텍처의 세대교체를 하는 것이 핵심이었고요. 비지니스 재사용을 위한, 도메인 주도 설계 컴포넌트 도입 및 확산과, 테스트 기반으로 애플리케이션 변경에 대한 영향도를 감지하게 하였습니다.

 

마지막으로 내년에 진행 예정인 마일스톤3에서는, 서비스 품질 보장을 위한 마지막 과정으로, DB의 현대화를 진행하려 하고요. 주문 DB를 분리하여 독립 운영하는 것을 핵심 태스크로 잡고, 오라클에서 아마존 오로라 PostgreSQL로 이관 예정입니다.

주문서비스는 다른 서비스와 복잡하게 얽힌 의존성이나 영향도를 제거하기 위해 앞서, 인프라 독립 분리 및 애플리케이션 독립 분리에, DB 독립분리까지 해야지, 서비스 품질을 보장할 수 있다고 판단하고, 앞으로 나아가는 방향성으로 잡고 있습니다.

 

위의 3가지 마일스톤이 완료되면, 애플리케이션 현대화에 대한 최종목표에 도달하게 되고요. 주문서비스팀 미션인 영업매출 증대와 고객 경험 개선에 기여하게 될 것입니다.

 

3. 일하는 방식의 변화

애플리케이션 현대화를 진행하고 되돌아보니, 일하는 방식의 변화도 있어서 한번 말씀드려보겠습니다.

첫번째는 CI/CD 파이프라인 업무의 변화가 있었습니다.

기존에도 무중단 배포가 가능했지만, 커스텀 배포도구로 반반 씩 배포하는 방식으로 진행하였는데요. 서버의 반을 배포하다가 문제가 발생하면, 문제가 해결 될 때까지 나머지 서버의 반으로 리소스를 운영하는데 어려움이 있었습니다. 보통 환경 설정 변경으로 인한 오류로, 서버가 기동이 되지 않는 문제가 있었습니다.

아마존 EKS를 도입하면서, 컨테이너 이미지 기반의 롤링 업그레이드로 배포방식을 전환하였고, 배포 시 문제가 발생하면, 배포가 되지 않거나 이전 이미지로 바로 롤백 할 수 있어서, 업무의 효율성을 얻게 되었습니다. 그래서 기존에는 수시배포가 가능함에도, 매주 목요일에 모아서 정기배포를 진행하였는데요. 지금은 배포에 대한 두려움이 사라져, 수시배포도 별도로 진행하고 있고요. 배포의 자유로움도 만끽하고 있습니다.

두번째는 주문서비스 모니터링 및 알람 방식의 업무 변화가 있었습니다.

기존에는 장애가 나면, BMS라는 비즈니스 모니터링 시스템에서 SMS 문자를 발송하고, 개발자가 문자를 보고 서버에 직접 접속하여 서버마다 로그를 확인하였는데요.

아마존 오픈서치를 도입하면서, 개발자는 더 이상 서버에 직접 접속하지 않고, 웹 콘솔에서 통합로그를 확인하였고요. 팀즈 알람을 통해, 해당 시간의 로그를 링크로 받아, 빠르게 확인 할 수 있어, 장애 분석 및 대응 시간을 단축시켰습니다.

제가 좋아하는 말이고, 방향성으로 멤버분들에게 지속적으로 공유하는 말로, 우리가 일을 하는 현실적인 목적은 퇴근 시간을 준수하여, 개인의 행복도 찾아가자 인데, 일하는 방식의 변화로 인해, 계획 된 퇴근 시간을 준수 할 수 있게 되었다고 생각합니다.

 

어떻게~ 재밌게 들으셨나요. 이제 마지막으로, 주문서비스팀의 메세지를 전달하고, 마무리 지으려 합니다.

클라우드에서는 손쉽게 기술을 사용할 수 있습니다. 보여줄 수 있는 가치에 집중하는 것이, 새로운 기회를 만드는 것입니다. 라고 함께 일하는 주문서비스팀 멤버들의 메세지를 여러분께 전달 해 드립니다. 멤버분들의 일하는 모습도 담아봤습니다.

 

각자의 환경에서 누구나 할 수 있는 일이라 생각하고요. 기술부채를 갚기 위해서 클라우드를 용도에 맞게 활용하였고, 저희가 할 수 있는 범위에서 가치 있는 것들을 찾아, 작게 작게 개선한 것 뿐입니다. 기술에만 매몰되기 보다는, 가치 있는 것에 집중하여, 새로운 기회를 많이 만들어 내는 것이 중요하다고 생각하는데요. 그 새로운 기회를 통해, 개인의 역량이 강화되고 조직의 역량으로 이어져서, 보다 가까운 미래를 현실적으로 준비 할 수 있는, 원동력이 된다고 생각합니다.

 

한번 더 강조하면, 클라우드 환경에서는 누구나 빌더가 되어 일상생활의 불편한 점을 개선 할 수 있습니다.

 

감사합니다. ^^

---

김헌기 Darion | 디지털서비스본부 > 홈쇼핑서비스부문 > 주문서비스팀

Backend Office 주문 / 결제 / 마케팅프로모션 / 연계 / 혁신과제 서비스를 담당하고 있습니다.

동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.

---