리팩토링, 다르게 생각하기. Part 4

비즈니스의 속도가 민첩하게 변화되면서 가장 크게 변화된 것은 팀의 구조와 개발팀, 기획팀의 거버넌스 체계입니다. 다음의 그림을 보죠.

고객과 내부의 작업자를 연결한 비즈니스의 구성에 있어서 고속으로 기획 및 개발이 이루어지려면 어떻게 해야 할까요? 기존의 피라미드 구조의 권한을 가진 거버넌스 구조로 이런 기민한 비즈니스 민첩성을 가질 수 있을까요?

매우 당연하게 비즈니스의 통제와 관련된 직원에 대해서 엄청난 권한 이향이 발생되게 됩니다. 소비자의 요구사항이 거의 직접 내부 작업자들에게 연결됩니다.

기존의 프로세스와 시스템 중심의 구조에서 의사결정 중심의 구조로 이동하게 되며, 이 구조는 DevOps의 구조의 형태로 진행되게 됩니다. 보통, DevOps구조를 명확하게 가지고 있는 곳이라면, 팀의 체계가 세분화되고, 배포 권한들이나 신규 기획 및 구현과 관련된 ‘권한’등이 대부분 팀원들이나 조직원들에게 이동되게 됩니다.

당연하게 배포 자동화 프로세스나 QC/QA 등의 체계 등이 매우 세분화되고 유연한 형태로 변화된 구조만이 이러한 DevOps구조에 적합합니다.

제가 속한 와탭의 경우에도 거의 가상화 된 조직으로 구성되어져 움직이는 매우 기민한 DevOps조직입니다.

분명한 것은 ‘고객’부터 기업 조직 내의 다양한 ‘점’들이 모두 이어지게 됩니다.

디지털 마케팅과 기업의 서비스는 하나다

라고 정의할 수 있습니다.

디지털 마케팅, 비즈니스의 속도에 대해서 소프트웨어 공학에서의 해결책들은 대부분 계획과 설계에 집중화되어 있습니다. 실제, 구현되고 동작되는 서비스들의 모든 액션이나 로그들을 추적할 수 없기 때문에 ‘모델’을 세우고 그 모델을 중심으로 프로세스와 품질을 추상적으로 관리하려 했습니다.

그 대표적인 3가지의 프로세스 평가 모형들은 다음과 같습니다.

하지만, 이 방법들은 기민하게 가동되는 1주일 간격으로 배포가 동작하는 디지털 비즈니스의 환경에는 적합하지 않습니다. 다른 방법을 찾아야 합니다.

더군다나, 대표적인 경험 중심의 학문도 변화하고 있습니다.

그 대표적인 학문은 바로 ‘의학’입니다. 기존의 임상의학의 경우에는 아픈 환자에 대한 모델과 의료행위에 대한 기존에 증명된 모델들을 통해서 과학적인 방법으로 접근하는 방법으로 의료행위가 동작하였습니다. 의사 또한 직접 증상을 관찰하고 자신의 가설을 통하여 환자를 치료했죠.

하지만, 시대가 변했습니다. 환자들은 connected health기술들을 통해서 데이터들을 방대하게 수집하고, 의사들 역시 새로운 논문이나 신약, 치료법들에 대해서 데이터 분석과 경험적인 서포트를 받기 위해서 방대한 데이터 분석의 도움을 받아서 진료를 하기 시작했습니다.

의학 역시, 기존에 다루지 않았던 데이터들에 대해서 집중하기 시작했습니다.

이제, 소프트웨어 개발도 이러한 관점으로 변화되어야 하지 않을까요?

기존의 리팩터링들이 체크리스트와 프로세스, 기법 등을 통하여 유용한 결과를 얻어내는 모델의 형태를 취하는 추상적인 단계로 실증적이지 못했고, 매우 많은 시간들이 필요했습니다.

특히, 리팩터링의 관점들은 다음의 단계들을 진행했지만, 그 작업은 매우 방대하며, 실제 개발기간보다 더 더 필요한 것이 사실입니다.

중복된 코드 Duplicated Code
긴 메서드 Long Method
거대한 클래스 Large Class
게으른 클래스 Lazy Class
추측성 일반화 Speculative Generality
임시 필드 Temporary Field
메시지 체인 Message Chains
미들 맨 Middle Man
부적절한 친밀 Inappropriate Intimacy
다른 인터페이스를 가진 대체 클래스 Alternative Classes with Different Interface
불완전한 라이브러리 클래스 Incomplete Library Class
데이터 클래스 Data Class
거부된 유산 Refused Bequest
주석 Comments

하지만, 관점을 이런 행위와 모델의 접근법이 아니라, 실제 구현되고 동작중인 서비스에서 문제를 찾는 방법으로 접근법을 바꾸고 의료행위에서 자신의 경험에만 의존하는 것이 아니라, 의료영상기기인 MRI를 사용하듯이 방법을 바꾸어야 합니다.

다음의 프로파일들을 자동으로 추출한다면 위에서 언급된 리팩터링 작업의 상당 부분들이 실증적으로 처리할 수 있습니다.

특정 시점의 Transaction End-List
특정 시점의 SQL Query List
특정 시점의 Nested Web-Transaction End-List
특정 시점의 User, Transaction, Resource List
특정 시점의 Remote HTTP Call List
특정 시점의 Method List

물론, 모든 소스를 검토하고 다시 리뷰하는 시간을 거치면서 작업하면 좋겠지만, 작업 시간의 효율은 매우 떨어집니다.

그래서, SW 구조에 맞추어서 사용자들이 실제 서비스를 사용하는 행위와 해당 행위의 웹 트랜잭션을 기반으로 해당 서비스의 실제 상태(CPU, 메모리, 네트워크)등의 트랜잭션을 추적 관리하고, 이를 기반으로 통계적인 접근법을 사용하는 방법으로 문제가 큰 부분부터 잡아들어가는 방법을 사용하도록 유도하겠습니다.

이 방식은 다음의 그림으로 표현할 수 있습니다.

물론, 이러한 데이터들을 추출하고, 정제하고, 통계적으로 빠르게 접근할 수 있는 방법을 제공한다면, 리팩터링은 전체 소스를 뒤져가면서 논리적인 상황들을 연상하는 방법만으로 접근하는 것이 아니라는 것을 보여줍니다.

이제, 기존 리팩터링의 방법을 넘어서서 메서드 프로파일링을 기반으로 웹 트랜잭션을 세밀하게 검토하고 관리할 수 있습니다.

물론, 이러한 방법은 그냥 되는 것이 아닙니다. WebService Performance Framework라는 도구의 도움을 받아야 합니다. 이 Framework는 메서드 레벨의 추적이 가능할때 부여할 수 있습니다. 기존에 만들어졌던 APM제품들은 이런 접근이 불가능합니다. ( 국내외 모든 APM 제품 기준 )

또, 자랑합니다. 필자는 25년을 소프트웨어 공학을 해왔습니다만, 이렇게 손쉽고 빠르고, 정확하게 메소드 레벨을 추적하는 기술을 본적이 없습니다. 그렇습니다. 와탭의 APM( http://www.whatap.io )은 가능합니다. 그것도, 고가의 설치형 APM이 아니라, 필요시에 필요한 만큼만 서비스받아서 문제를 해결할 수 있습니다.

(월 몇만원의 서비스로 리팩토링 전문가를 고용해보십시요. )

빠르게 변화해야 하는 비즈니스의 속도, 기존 리팩토링으로는 해결할 수 없습니다. 와탭은 기존의 정적 분석과 동적 분석을 뛰어넘어, 숨겨진 메서드의 문제들을 통계적으로 추적 관찰할 수 있습니다.

hidden method troubble 처리 기법은 와탭의 Active Stack 기술(특허 : 10-2016-0078864)은 비즈니스의 속도가 필요한 모든 IT기업에게 정말 매력적인 방법을 제공합니다.

리팩토링, 다르게 생각하기. Part 3

IT서비스는 비즈니스의 요구조건에 맞추어서 개발되고 구현되는 것입니다. 기존의 소프트웨어 공학이 현재의 관점에서 잘 맞지 않게 된 이유 중의 하나는 ‘비즈니스의 속도’와 깊은 연관성을 가지고 있습니다.

분명한 것은 기존의 Classic Business와 현재의 Digitacl Business의 환경은 정말 다릅니다. 그 이유를 다음의 그림으로 설명하겠습니다.

기존의 Classic Business에서 어떤 상품이나 서비스들은 직접 고객과 연결되지 않았습니다. 그리고, 해당 비즈니스를 위해서 어떤 광고를 하거나 어떤 마케팅 행위를 했는지에 대해서 추정할 수밖에 없었다는 것은 이미 널리 알려진 사실입니다.

또한, 새로운 비즈니스가 기획되는 기간은 통계적으로 대략 6~9개월 정도 소요되며, 해당 기간 동안 데이터를 수집하고, 분석하고, 기획과 구현 실행을 하는 기간들이 포함된 내용입니다.

실질적으로 고객을 이해하는 것은 정량적인 데이터들이라기보다는 정성적인 판단이나 유추한 해당 비즈니스의 모델 구조와 모형에 대한 이해로 풀이하는 정도였습니다.

하지만, 이러한 Classic Business는 Digital Business로 넘어오게 되면서 급변하게 됩니다. 그 가장 큰 이유는 웹의 시작이었고, 모바일로 진화되면서 이 구조는 이제 견고해졌습니다. 이제 모든 고객들과 기업들은 connected 되었습니다.

고객이 어떤 광고에 반응하고, 어떤 동작으로 서비스를 사용하며, 어떻게 지불하고 어떤 반응을 보이는지 ‘데이터’를 중심으로 확인할 수 있게 된 것이죠.

더군다나, 이런 환경에서 새로운 비즈니스가 동작하는 시간이 최대 1주로 짧아진 상황에서도 기민하게 새로운 서비스의 구현이 가능해졌습니다.

451 Research의 조사에 따르면, 기존의 Business에 비해서 출시 기간이 4000% 개선되고, 모든 것이 데이터가 되었기 때문에 분석 능력은 400배, 전체적인 소요비용인 TCO는 50%가 절감되고, 관리 오버헤드도 50% 감소.

특히나 IT서비스의 개발자 대응능력이 24시간 이내에 개념을 수립해서 배포가 가능한 환경으로 돌입했습니다.

Digital Business에서 ‘비즈니스의 속도’는 기존의 IT서비스를 만들던 방식의 소프트웨어 공학으로는 설명할 수 없게 되었습니다. 물론, 아직도 기존의 6~9개월 이상 소요되는 대규모 프로젝트라면 의미 있겠지만 말입니다.

분명한 것은 ‘비즈니스의 속도’에 의해서 ‘소프트웨어 공학’은 다시 생각되게 되었습니다.

디지털 비즈니스를 기획하고 있다면, 기존의 소프트웨어 공학은 완전 다시 생각해야 합니다.

리팩토링, 다르게 생각하기. Part 2

실전 환경에서 소프트웨어 공학은 무용지물인 경우가 많다. 왜냐하면, 급박한 IT 비즈니스 속도에 맞추어서 빠르게 개발되고, MSA구조에 맞추어서 클라우드 위에 서비스가 올라가면서, 매우 작고 기민한 형태로 개발이 이루어지기 때문에, 기존의 장기간 고민하면서 큰 서비스를 디자인하는 방식의 접근법은 사용할 수 없다.

기존 IT서비스들이 8~9개월에 1개의 큰 서비스를 론칭하는 형태에서는 기존의 소프트웨어 공학적인 접근법이 매우 유용한 것은 분명 사실이다. 요구사항을 잘 수집하고, 또 잘 정제하고, 이슈 트리를 만들고, 소프트웨어 아키텍처를 구성하면서 팀의 역량을 키워가면서 개발 성숙도와 팀의 성숙도를 향상하면 분명, 소프트웨어 개발의 품질은 향상된다.

하지만, 실제 주변 환경을 돌아보면, 2~3주 내에 하나의 서비스를 론칭해야 하고, 신규 기능이 계속 추가되는 환경에서 기존 방법론들은 대부분 추상적인 ‘가르침’만을 이야기할 뿐이다.

현시점에서 필요한 것은 ‘추상적인 공학’이 아니라, 지금 당장 작업하고 있는 팀의 구조와 개발 목표, 고객의 피드백과 서비스들이 빠르게 개발되고 관리되는 관점이 필요한 것이다.

물론, Node나 Python, PHP( 라라벨이나 코드 이그나이터 등)를 이용하여 빠르게 서비스를 DB서비스에 맞추어서 개발을 할 수 있다. 다만, 이렇게 만들어진 서비스가 갑자기 증가되면서 실제 서비스되면서 요구사항이 폭주하고 서비스가 복잡하게 변화하면서 문제는 발생한다.

서비스가 복잡해지면, 문제도 같이 늘어난다. 장애도 같이 증가하게 된다. 매우 당연하게 고객들은 세션이 끊어지는 현상을 경험하게 되고, 사용이 불편해지고, 그런 상황에서 경쟁자가 출현하거나, 새로운 데이터 마케팅 방법을 적용하려고 할 때에 매우 곤란한 상황을 만나게 된다.

리팩터링 할 여유도 없고, 새로운 버전과 새로운 기능에 몰두해야 한다. 이런 경우에 개발 총괄을 어떤 생각을 해야 하는 것일까? 현재까지의 정답은 기존에 만들어진 서비스로 최대한 버틸 때까지 버티면서 새로운 서비스를 만들어서 이를 대체하는 것이 최선이라고 이야기할 수 있다.

차선책은 그 부분을 어떻게든 레이어 구분을 해서 부분 부분 리팩터링을 하면서 서비스를 고도화하는 방법으로 진행하게 된다. 분명한 것은 이런 과정들이 매우 고통스러운 튜닝 작업의 연속이 되게 된다는 점이다.

아이러니하지만, 경험이 풍부한 자바 개발자가 있다면, 이런 상황들을 나름 서핑하듯이 넘어갈 수 있다. 하지만 그렇지 않다면, 이 작업들은 매우 고통스럽고, 작업 진행이 효과적으로 진행되지 않는다면, 서비스가 중단되거나 고객들이 만족하지 못하고, 신뢰가 떨어지면서 고객은 이탈할 것이고, 서비스는 문을 닫는 상황으로 진행이 된다.

대부분 스타트업들이나 IT기업들은 초기의 1차 작업은 빠르게 개발하는 환경에서 기민한 개발자가 가장 효과적으로 사용하는 툴을 사용하여 서비스를 빠르게 비즈니스 환경에 맞도록 론칭하고, 이를 기반으로 본격적인 서비스를 다시 구상하는 것이 대부분의 패턴이라고 할 수 있다.

보통, 투자를 많이 받거나, 어느 정도 고객이 확보되는 순간에 경험이 풍부한 CTO레벨을 영입해서 이를 해결하려 한다. 매우 당연하게 경험이 풍부한 CTO는 기술 스택의 부족함과 리팩터링 이슈에 대해서 질문을 개시하고, 이를 갈아 없기 위한 논의를 시작하는 것은 매우 당연하다.

하지만, 비즈니스의 특성상 중단될 수 없고, 순차적으로 넘어가는 방법에 대해서 내부 협의가 잘되지 않는 경우에는 영입된 CTO가 이탈하거나, 개발팀이 제대로 꾸려지지 않아서, 서비스가 안착되기 어려운 경우도 빈번하게 발생된다.

분명한 것은 경험이 풍부한 CTO라면, 백엔드 서비스들에 대해서 기민하게 컨트롤하기를 원하고, 100만, 1000만 사용자들을 컨트롤할 수 있는 자바 백엔드 서비스를 매우 당연하게 구상할 것이다. 더 글로벌 서비스라면 데이터 스토리지와 관련된 레이어까지 다시 구상할 것이다.

그리고, 자바 튜닝과 관련된 인프라와 리팩터링, 코드리뷰와 개발 문화를 위해서 고민하고 이를 반영하려고 할 것이다.

이번에는 그중에 자바 튜닝과 관련된 내용만 일부 나열하자.

자바 튜닝과 관련해서는 한두 페이지로 설명을 전부 할 수 없다. 다만, 여기서는 향후 구체적으로 설명하기 위한 ‘다이내믹 리팩터링’에 대한 사전적인 설명을 하는 정도로 기본 정리만 하겠다. 관련 내용들은 별도로 기술할 생각은 있으나, 요즘 관련된 문서들이 인터넷에 너무 많아서, 간단하게만 정리하겠다.

자바와 소프트웨어 공학적인 측면은 매우 일맥상통하는 부분이 많다. 정적인 분석이나 동적인 환경에서의 분석 및 프로파일링을 통해서 실제 CPU와 메모리, 네트워크 등의 리소스에 대한 세밀한 제어까지 가능하기 때문에 대규모적인 서비스에서 성능을 컨트롤하기 원한다면, 분명. 자바로 코딩되는 것이 매우 유용하다.

주변에서는 Node.js나 PHP로 1차 구현된 이후에, 본격적인 서비스를 위해서 JAVA로 재 코딩되는 경우를 많이 본다. 특히, ‘성능’이 이슈가 되거나 기민하게 가동되며, 서버 리소스 비용을 최소화하기 위해서 클라우드와 결합된 환경에서 극단적으로 튜닝하는 경우에는 자바로 코딩하는 것이 분명 효과적이다. (다만, 그만큼 복잡하고, 그만큼 경험이 풍부한 개발자가 없다면 이 선택은 어려울 수 있다. )

하지만, 리팩터링과 성능 프로파일링을 기반으로 엔터프라이즈 환경에서 유연하게 확장과 세밀한 컨드롤등이 가능한 것이 자바인 것은 굳이 더 설명이 필요 없다고 생각한다. 특히나, 리팩터링이 원활하고 원하는 프레임웍들을 손쉽게 선택할 수 있는 환경임에는 분명하다. ( 그만큼 아는 사람이 잘 쓴다. )

자바로 구현된 서비스를 중심으로 리팩터링의 이슈를 해결하기 위해서 중요한 관점들을 몇 가지 정리한다면 다음의 관점들에 대해서 관심을 가져야 한다고 정리해보자.

첫 번째. garbage collection에 대한 이해

분명한 것은 메모리에 생성되는 변수와 객체에 대한 할당과 해제에 대해서 가장 민감하게 생각되어야 한다. 자바 코딩의 기본 중의 하나인 System.gc()를 명시적으로 호출하는 경우는 논외로 하자. 아주 특이한 경우가 아니라면 직접 호출하지 않을 테니.

다만, gc와 관련된 모니터링을 위한 툴과 방법은 다음과 같다.

* jvmstat : 무료, jdk 1.4.2 이상,

* visualgc : 무료

* jps : jvm 프로세스 뷰

* jstat : jvm 통계수치 뷰

* jstatd : 원격으로 jstat을 사용하기 위한 데몬

두 번째. 프로파일링과  APM의 활용

자바로 구현된 상태에서 소스 레벨 분석용을 위하여 정적 분석을 위해서 DevPartner for Java, Jprobe, TPTP(Eclipse 기반)등을 사용할 수 있으며, 웹서비스가 실제 구현되고 동작되는 상황에서 동적 분석을 위해서 APM(Application Performance Management)을 기반으로 프로파일링 하는 방법이 있다.

정적 분석의 경우에는 대부분 String의 상태, Collection과 Map에 대한 자료구조에 대한 상황들을 관찰하고 분석한다. 특히, 대용량 데이터를 사용할 경우에는 적절한 프로파일링을 통해서 선택하는 것이 좋다.

특히, 자바의 경우에는 Collection의 다양한 클래스들이 존재한다. 사실상, 이 자료구조의 선택을 어떻게 하느냐에 따라서 전체적인 서비스의 성능과 장애의 근본 원인이 되는 경우가 대부분이다. 특히, 자료구조의 경우 동기화가 되고 안되고의 차이도 크니 이 부분을 기민하게 상요해야 한다.

세 번째. 그 이외의 것들

작게는 Loop의 성능에 대해서도 이야기를 하나. 사실상 그다지 차이가 없다. if나 switch나 큰 문제가 되지 않는다.  이외에도 static이나 syncronized 등을 참고하겠지만, 대부분의 ‘성능장애’는 이런 부분에서 발생하지 않는다.

큰 문제는 보통 IO병목이거나 Logging과 관련된 이슈, DB 연동을 위한 connection관리 등에서 발생한다. Connection, Statement, ResultSet 등의 관리가 핵심이다.

생각보다, XML 관련 이슈는 대규모 서비스이거나 사용자가 급증했을 때에 전체 서비스의 성능장애를 발생시키는 주된 요인이 된다. SAX의 경우 추적이 어렵고, DOM의 경우에는 메모리 사용량이 많아서 대부분의 APM들에서 추적이 불가능한 경우도 많다. ( 유일하게, 와탭 APM만 해당 이슈의 추적이 가능하다. )

그 밖에도 웹서버 관련 이슈도 많이 존재하고, DB connection Pool, session timeout 등을 주목하게 된다. JVM의 메모리 설정을 잘못해서 생기는 문제도 은근 많이 발생한다.

이러한 리팩터링의 관점들을 APM들은 매우 손쉽게 프로파일링하고 필요한 포인트들에 대해서 명쾌하게 접근할 수 있도록 매우 큰 도움을 준다. APM의 장점은 크게 다음의 두 가지로 정리할 수 있다.

하나는 Slow Query를 매우 손쉽게 찾아준다는 점이고. 다른 하나는 웹서비스 트랜잭션에 대한 프로파일링을 통해서 성능상의 이슈나 잘못된 설정등을 빠르게 찾게 해준다. 이처럼, 대부분의 WebService의 문제의 70% 정도는 Slow Query의 문제이고, 25%정도의 WAS내부의 성능문제들을 찾게 해준다.

다만, 소스코드 상에서 특정 클래스나 특정 펑션의 성능적인 이슈가 발생되어 비정상적인 성능장애가 발생한 경우에는 추적이 매우 어렵다. 기존의 APM들은 다이나믹 프로파일링이라는 기법으로 개발자의 추측과 소스코드상의 분석등을 통해서 문제가 예측되는 상황들을 하나씩 검토해 보는 방법을 사용한다.

또는, 인젝션하는 방법으로 서비스에 직접 걸어서 추출하는 방법도 있기는 하나, 이는 실 서비스에서 인젝션된 에이전트의 부하와 구분할 방법이 명확하지 않기 때문에 실서비스 보다는 개발환경에서 사용하는 경우가 많다. 대부분의 APM들은 이런 5%의 특이상황들에 대해서는 튜닝을 포기한다. 그리고, 향후 고도화작업이거나 솔루션 대체를 할 경우에 이를 해결하려고 한다.

대부분의 상용APM들이나 Scouter와 같은 오픈소스 형태의 APM으로도 대부분의 95%의 문제는 해결이 가능하다. ( 다만, Scouter의 경우에는 1~5대 정도의 서버에 적합하지, 100대이상의 대규모 서비스에 적용한다는 것은 사실상 실패를 할수 밖에 없다. )

문제가 발생한 소스 코드의 위치까지 찾는 기능을 제공하는 APM은 기존 APM제품중에는 없다.

여기서 와탭을 잠시 자랑하겠다. ~.~ ( 저.. 와탭의 CBO랍니다. ~.~ )~~~

이런 문제를 해결하는 APM이 있다. 와탭의 APM( http://www.whatap.io )은 이렇게 숨어있는 특정 소스라인의 문제들을 추적하여 리팩토링이 가능한 쉬운 방법을 제공한다. 와탭의 특허인 Active Stack이라는 기법( 10-2016-0078864 )으로 마치, MRI촬영을 하듯이 실제 동작중인 웹서비스에 설치하여 ( 재기동 없이 ) 스냅샷을 찍어서, 프로파일링하는 기법으로 문제가 되는 부분들을 손쉽게 찾아서 리팩토링을 빠르게 처리한다.

( 실제 사례 : 2년동안 못 찾은 모바일 뱅킹의 장애원인을 진단하다. )

앞에서 설명한 복잡한 정적인 코드 리뷰나 분서기법들을 사용하지 않고서도, 현재 동작중인 웹서비스의 리팩토링을 실시간으로 처리한다. 마치, Dynamic Refactoring이라고 불러야 적당할 듯하다.

리팩토링, 다르게 생각하기. Part I

10년 넘도록 동작하던 레거시에 가까운 코드로 동작하던 A기업의 고객 시스템에서 지속적으로 성능 문제가 발생하고 있다면 해당 서비스의 담당자는 머리를 잡고 고민할 것이다.

여러 가지 고민을 하겠지만, 대부분의 결론은 ‘서버’의 용량을 증설하는 Scale Up이나 Scale Out으로 결론이 난다. 소스나 내부에 대해서 어떻게 할 수 없을 경우가 대부분이기 때문이다.

분명한것은, 어떤 방법으로 증설하던 ‘비용’이 추가적으로 발생할 것이며, 이 ‘비용’에 대해서 부연설명을 하거나 해명을 할 준비를 하게 된다.

임원회의 때에 땀을 흘리며 브리핑을 할 것인지, 수월하게 할것인지에 대해서 고민하게 된다.

이런 문제는 어느 회사, 어떤 조직, 어떤 관리장의 입장에서도 비슷하게 발생한다.

지속적으로 성능 문제가 발생한다는 것은 어떤 것일까? 대표적인 케이스들만 서술한다면 사용자가 로그인하기 힘들다던가, 반응이 느려서 고객센터에게 전화가 많이 오거나, 홈페이지에 댓글이 연달아 달리는 경우일 것이다.

문제는 이 문제가 과거에는 잘 동작하던 시스템이었는데, 모바일 시대로 바뀌면서 발생하는 경우이다.

과거에는 해당 서비스들이 기업 내부의 직원들이 주로 다루었기 때문에 아주 큰 문제를 일으키지는 않았다.

하지만, 사용자들이 증가하고 모바일로 유사 서비스들이 제공되는 시대로 돌입하면서, 기존에 유야무야 존재하던 버그나 성능장애에 대한 이슈들은 이제 실제 고객의 클레임이나 고객의 불평불만을 접수하는 CS 부서의 주된 요청사항의 하나가 되었다.

매번 고객담당부서의 아우성을 IT 인프라 운영부서나 개발 총괄이 들을 수밖에 없는 시대가 된 것이다.

물론, 이런 문제를 해결하기 위해서 소프트웨어를 연구하는 많은 사람들은 그 해결책을 찾기 위해서 많은 연구를 하고, 대응책을 마련했다. 그 대표적인 것은 바로 ‘프로세스 평가 모형’을 만들어서 만들어지거나 만들어진 소프트웨어, IT서비스의 문제를 해결하려고 한 것이다.

대표적인 것 3가지를 살펴보나.

하나. ISO 9000 ( ISO 9000-3)

품질경영원칙을 미리 정립하고 시스템 기준으로 구축한다면 소프트웨어 품질이 좋아져서 IT서비스가 매우 효과적으로 운영될 것이라는 생각으로 만들어진 품질 기준이다.

프로세스의 관점으로 고객만족을 지속적으로 개선하자는 것이며, 경영자의 책임이나 소프트웨어 개발에 투여되는 자원들에 대한 관리, 구현체에 대한 측정 분석 및 개선책을 통해서 SW 개발과 공급, 설치와 유지보수를 위한 지침서들을 통해서 이런 성능 장애와 품질문제를 해결하고자 한 것이다.

둘. CMM(Capability Maturity Model)

SW 개발 조직의 실제 수행평가를 통해서 품질을 잡고자 하는 시도였다. 미 국방성(SEI Software Engineering Institute)에서 추진한 방법으로, 신뢰성 있고 사용하기 편리한 소프트웨어는 ‘성숙된 조직’에서 얻어 낼 수 있다는 가설 위에서 출발했다.

그러므로, 보다 ‘성숙된 개발 조직’을 갖추기 위한 체크 방법과 구현 방법들이 주로 고민되었다.

셋. SPICE(Software Process Inprovement and Capability dEtermination)

CMM의 성숙도 모형과 ISO/IEC12207의 SW생명주기 모형을 결합하여 프로세스의 능력 결정과 프로세스 개선을 위한 방법으로 품질을 높이고, 성능을 잡는 방법을 고안한 것이다.

이런 소프트웨어 공학들이 실제 소프트웨어를 개발하고 Lean 하고 기민하게 움직이는 현재의 소프트웨어 개발 방법과 비교한다면 너무도 추상적인 개념과 측정할 수 없는 개발자나 개발 조직 등의 품질을 잡으려고 한 시도였다고 솔직하게 이야기하자.

과거, IT 비즈니스의 신규 기능이나 신규 서비스의 개발이 9개월 이상 소요되던 시대에는 이러한 방법을 통해서 반복적인 설계와 미리 예측된 상황들에 대해서 고민하면서 이 문제를 개발 전과 개발 중에 해결하려고 애를 쓴 것이기 때문에 나름 의미가 있었다.

하지만, 현재의 IT서비스를 돌아보자. 빠르면 1주, 늦어도 2~3주에 한 개의 IT서비스가 새로 만들어지며, 기획부서는 데이터를 직접 분석하여 새로운 서비스를 만들어낼 준비를 한다. 개발자들은 빠르게 이렇게 만들어지는 서비스들을 대응해야 하는 고속 개발의 시대로 접어들었다.

더군다나, 사용자들의 행동 패턴을 예측할 수 없는 모바일 기기들에 대해서 대응하는 IT서비스를 구현하기 위해서 수십만, 수백만의 사용자들을 고려해야 하는 MSA의 시대이다.

이제는 소프트웨어들은 어느 정도의 품질과 어느 정도의 성능을 위한 공학적인 도움은 받았으나, 그동안 공학의 ‘모델’에서 애써 외면하던 5%의 영역이 실제 IT서비스에서 문제를 일으키기 시작한 것을 다들 몸으로 느끼고 있다.

대표적인 것이 특정 시간, 특정 일자만 되면 CPU가 급등하거나 네트워크가 급등하는 등의 반복적인 상황이 발생하고 있다는 것이다. 이런 상황들은 ‘모형’에서는 대부분 오차로 인지하는 영역들이며, 특이한 영역으로 구분되었기 때문에 ‘공학’은 고민하지 않았다.

관리적으로는 경위서나 사유서로 대체하고… 1년에 며칠만 고생하면 되었기 때문이다. 하지만, 모바일 시대에서 이런 방식으로는 경쟁회사와 경쟁업체에게 자사의 서비스에 대한 신뢰도를 급락하게 하는 주요한 사유가 된다.

사용자들은 ‘어떤 날’ ‘어떤 시간’에 성능장애를 겪고 있다면, 기존의 ‘소프트웨어 공학’만으로는 해결이 안 된다는 것을 이제 깨달아야 한다. 사용자들에게는 WebService Application Performance Framework의 접근법이 필요하고, 해당 장애나 문제를 일으키는 ‘한 줄의 코드’에 집중해야 한다.

기존의 공학은 이 ‘한 줄의 코드’를 유추와 분석, 가설과 모형으로 찾아냈지만, 현재의 IT기술은 소프트웨어 개발자들에게 관련 스냅샷과 프로파일링 기법으로 빠르게 1줄의 코드를 빠르게 찾아낼 수 있는 시대로 돌입했다.

다음의 사례를 참조하시기를… ‘2년 동안 못 찾은 모바일 뱅킹의 장애 원인을 진단하다.

IT서비스 개발자, 운영자들이라면 공감하는 문제들…

IT서비스를 개발/운영하고 있는 고객의 경우 다음의 내용에서 한가지의 문제라도 해당되신다면… 와탭 APM의 도움이 필요한것입니다.

1. 정기적으로 CPU가 급증하여 그 날만 되면 불안해지는 경우…
정기적으로 CPU의 사용량이 급증하는 현상이 생기는 경우는 분명 성능상의 장애 문제인 경우가 많습니다.  와탭APM은 소스레벨의 성능상의 문제를 추적하여 이 문제를 해소시킬 수 있습니다.

2. 몇가지 신규기능이 추가되었는데 서버는 두배?
신규 기능을 추가한 새로운 솔루션의 서버 용량이 갑자기 급증한 경우에도 분명합니다. 추가된 기능이 몇가지 안되는데에도 서버 사용량이 증가한다면, 분명. 소스코드상에 성능문제가 있다고 추정됩니다.

3. 오픈소스와 기술스택이 복잡해지는 경우!
오픈소스와 기술스택이 복잡해서 장애나 문제의 유추와 해결이 복잡한 경우에도 매우 유용합니다. 당연하게 알고 계시겠지만, 오픈소스도 버그를 가지고 있고, 사용하기 위한 규칙이 나름 존재합니다. 이 문제가 중첩되면서 발생되는 문제들의 복잡함을 와탭은 간소화 시켜서 문제를 해소합니다.

4. SSA에서 MSA구조로 변화를 준비하는 경우!
SSA(Single Service Architecture)에서 MSA(Micro Service Architecture)로 변화를 시도하는 과정의 경우에도 특히 필요합니다. Oracle이나 MSSql과 같은 DB에서 MySQL로 분화되는 구조의 경우에도 비슷합니다. Application의 상황이 복잡해지면서 문제를 찾기 어려워집니다. 고객에게는 와탭 APM이 필요합니다.

5. DB병목 지점에 대해서 실시간 검토가 필요한 경우!
DB병목지점에 대해서 자세하게 알고 싶은 경우에도 와탭APM이 유용합니다. 물론, DB병목지점은 타사의 APM이나 DB모니터링 툴로도 이 문제는 해결이 가능합니다. 하지만, DB병목지점과 Application과의 문제, 소스레벨의 문제를 추적하려면 현시점에서는 와탭 APM밖에는 해결책이 없습니다.

6. 특정 소스코드 레벨의 메모리 누수를 파악하고 싶은 경우!
메모리 누수에 대한 구체적인 상황을 알고 싶은 경우에도 유용합니다. 타사의 APM으로도 추적은 가능합니다만, 소스레벨의 추적은 불가능합니다. 와탭 APM만이 구체적으로 추적할 수 있습니다.

7. IDC의 상황이 실제 정확한지? 잘 적용하고 있는지?
IDC를 사용하고 있는 경우에도 유용합니다. 네트웍 문제와 IDC 서버와의 상관관계의 추적을 효과적으로 수행합니다.

8. 클라우드가 정확한 서버 용량을 지키고 있는지 걱정되는 경우!
클라우드를 사용하여 서비스하는 경우에는 선택이 아닌 필수라고 권해드립니다. 와탭APM은 클라우드 지향이며, 클라우드에서 손쉽게 배포 관리 및 클라우드의 사용량의 불완전함을 해소시킬 수 있습니다.

9. 서버가 급증하고, 이전하면서 실수하지 않는지 불안하면!
새로운 서버로 이전하여 사용하는데 JVM이나 Tomcat, 서버 설정등의 장애가 걱정되는 경우에도 와탭APM은 매우 유용합니다. 한번에 한화면으로 한곳에서 관리할 수 있습니다.

10. 아! 인력부족!!! 성능문제!!
성능개선을 해야 하나 인력이 부족하여 여유가 안나는 경우. 와탭APM은 관리자, DBA, 시스템 오퍼레이터, 개발자들간의 커뮤니케이션을 보다 효과적으로 수행할 수 있게 해줍니다.

11. 한두대 서버관리는 Scouter.. 100대? 1000대는?
오픈소스로도 몇대의 서버 관리는 충분하게 가능합니다. 하지만, Scouter는 대용량의 서버나 클라우드 지향으로 디자인된 녀석이 아닙니다. 이 부분을 명쾌하게 지적하는 이유는 Scouter 메인 커미터가 와탭에 있기 때문이죠.

혹시라도, Scouter로 100대, 1000대의 서버의 성능관리를 하겠다면 도시락 싸들고 다니면서 말려야 합니다. 돈과 시간, 열정을 소비할 뿐입니다.

마지막으로

12. 다른 APM이 있으나 ‘성능’장애 문제가 있는 경우
타사의 APM을 사용하고 있으나, 정기적으로 성능 장애 문제를 해결하지 못하는 경우에 와탭의 APM이 필요합니다.

이경우 대부분의 문제는 소스레벨 특정라인의 성능 문제입니다. 와탭의 특허인 Active Stack( 출원번호 : 10-2-16-0078864 )은 Hidden Method Trouble 분석 기능으로 문제가 발생된 소스코드 레벨의 문제들을 찾아서 문제를 해소합니다. ( 고객사례 : ‘2년동안 못 찾은 모바일 뱅킹의 문제를 해소하다’ 를 참조 )

와탭은 웹서비스의 문제들을 해결하고 고객의 서비스를 성공적으로 운용할 수 있는 서비스를 SaaS형태로 사용한 만큼 비용을 지불하는 형태로 제공하고 있습니다. 와탭에게 문의 하십시오. ( http://www.whatap.io )

 

매월, 매주 주기적으로 서비스가 느려지고, 고객이 아우성친다면… 와탭을 찾으세요.

디지털비즈니스는 이제 모바일과 웹을 통해서 고객과 직접 연결되어 있습니다. 이제, 사용자들은 자신들의 요금이나 서비스를 직접 자신의 모바일 디바이스를 통해서 정보를 조회하고 필요한 정보나 기능들을 추가하고 있습니다.

기존에 전통적인 IT비즈니스의 상황은 이렇게 대량의 사용자들이 동시 접근하여 사용하는 것을 고려하여 디자인되거나 설계되지 않았습니다.

서버의 용량을 증설하고, 네트웍을 증설한다고 하더라도, 서비스가 월 초와 월말에 엄청나게 느려지거나 대응이 답답해지는 것을 알기 위해서 매일매일 고민합니다.

물론, 개발자들은 리팩토링을 이야기하고 방대한 소프트웨어를 다시 설계해야 그것이 가능하다고 하겠지요. 이 이야기는 물론 맞는 말입니다. 완전하게 다시 만든다면 깔끔해질 것입니다.

하지만, 현재의 디지털비즈니스는 현재 서비스중인 내용을 중단하거나 기다릴 수 없습니다. 필요하다면 서버의 CPU나 메모리도 두배 세배 증설해서라도 고객의 서비스를 만족시키기 위해서 움직이니까요.

그렇지만, 지금 이시간에도 주기적으로 서비스는 느려지는 현상이 있습니다.

그래서, APM업체들이 모니터링과 다이나믹 프로파일링 기법으로 느려지는 Query나 WAS의 문제들을 찾아서 서비스를 원활하게 해주는 방법들을 제공합니다. 분명, 고객여러분들 대부분도 필요한 모니터링이나 APM제품을 사용하고 계실것이니까요.

그렇지만.. 여전히 풀리지 않는 숙제나 문제들에 대해서 내부적으로 고민하고 계실 것이며, 주기적으로 임원회의에 불려나가서 해명을 하시고, 고도화에 대한 계획을 잡고 계실 것입니다.

만일 고객이 그런 상황이시라면… 와탭을 찾아주세요.

고객의 현재 상황은 분명하게 기존의 APM으로 찾을 수 있는 쉬운 문제들은 대부분 찾았고, 타사의 APM들은 ‘불분명’한 이유로 더 이상 문제를 찾지 못한다고 하실 것입니다.

이제 와탭의 APM에 대한 소문을 들으실 것입니다.

어떤 APM이 몇개월을 추적했으나 찾지 못한 것을 4시간 만에 찾았다거나, 10년동안 레거시에서 성능을 괴롭히던 소스 코드상의 문제를 찾았다는 것에 대해서요.

보다 자세한 이야기를 듣고 싶다면. 와탭에 문의 하십시오.

답답한 IT서비스의 장애와 성능상의 결함들을 매우 빠르게 찾아드립니다.

신규 시스템이나 신규 서비스는 왜? 과도한 증설을 요구하는 것일까? 해결책이 없을까?

실제 3천명이 넘는 중견기업의 CIO생활을 할때에도 이 점은 정말 의문스러웠다. 소프트웨어 공학을 알고, 20년동안 소프트웨어 개발을 했지만, 대규모 인원이 투입되어 이루어지는 소프트웨어 개발의 전체를 한두 사람이 전체를 안다는 것은 매우 힘든 일이다.

특히나, 기존 레거시 서비스의 서버 리소스의 용량이 기능 몇개 추가되고 기능 몇개가 변경되었음에도 불구하고, 서버가 2배이상으로 증설되어야 한다는 보고를 받는 다면 이 부분에 대해서 CIO나 IT운영실장의 입장에서는 매우 난감하다.

( 그리고, 신규 시스템이 도입된지 얼마 안되어서 고도화나 업그레이드에 대한 이야기가 오고가고 있다면.. 시스템의 성능을 의심해야 한다.)

지난 20년간의 의문이 와탭의 CBO를 하면서 풀리고 있다.

엄청난 설계와 계획이 투입되어진다고 하더라도, 인간의 실수이거나 복잡도에 의한 ‘성능상의 문제’는 사실상 추적하기 어렵다. 그래서, 소프트웨어 설계와 아키텍처링을 집중하고 리팩토링을 해야하는 것에 대해서 매우 ‘기민하게 움직여야 한다’고 역설해왔다.

하지만…

이 기존 20년 경력의 개발 경험을 송두리채 바꾸는 경험을 하고 있다.

단지 몇줄의 코드가 중첩된 웹트랜잭션에 의해서 전체 서비스에 악영향을 주고, 실제 서비스 용량을 과도하게 증설시키는 이유였으며, 이 ‘성능성의 결함’을 손쉽게 찾을 수 있다는 것을 실제 눈으로 확인했다는 점은 정말 흥미롭고 떨리는 경험이다.

와탭의 APM은 Active Stack이라는 프로파일링 기법을 고도로 자동화 하였고, 소스 코드상에서의 성능상의 문제를 ‘직관적’으로 찾아낼 수 있는 매우 놀라운 기능을 가졌다는 것이다.

이 기능과 서비스를 주변의 개발자나 CIO들에게 보다 쉽게 설명하기 위해서 고민하고 있는 현 시점이 매우 즐겁다.

엄청난 소스 분석과 리팩토링 계획과 일정을 잡기 어려울 정도로 고속으로 움직이는 디지털 비즈니스의 세계에서 이 기술은 분명 시장에서 ‘인정’받을 것이다.

그 ‘일’을 위해서 오늘도 와탭의 엔지니어들은 달려가고 있습니다.

새로운 서비스를 도입했는데 서버 용량이 과도하게 증설되고 있거나, 정기적으로 서비스의 속도가 느려지면서 고객 응대가 증가하고 있다면… 와탭에게 노크하십시오.

원하는 접근방법과 처리방법에 대한 솔루션을 제공합니다.

[세미나 프로시딩]와탭랩스·트레저데이터, `데이터 기반 성공` 세미나 발표자료

먼저, 와탭랩스와 트레저데이터가 기획한 ‘데이터 기반의 성공, 서비스 기획과 운영’ 세미나에 참석해주신 분들께 감사 인사전합니다.

소중한 시간을 투자해 자리를 빛내주신 여러분께서도 데이터와 성능관리에 있어 많은 정보를 얻어가시는 시간들이 되었길 바랍니다.

와탭랩스와 트레저데이터는 금번 세미나에 참석하신 분들께 보다 더 많은 정보 공유의 차원으로 발표자료를 공유합니다. 이를 통해 더 많은 정보와 인사이트를 얻어가시는 계기가 되시길 바랍니다. 자세한 내용은 본문 최하단을 참고해주십시오.

단, 발표자료 중 특정 기업의 데이터 등 민감한 내용은 자료에서 삭제되었을 수 있으니 이 점 널리 양해부탁드립니다.

다시 한번 금번 세미나에 참석해주신 분들께 감사인사 전하며, 더 좋은 컨텐츠와 내용의 세미나로 다시 찾아뵙도록 하겠습니다. 다음 세미나에서도 많은 성원 부탁드립니다.

감사합니다.

 

———————————————————————————————

[WhaTap] 장기간 원인모를 장애와 싸워온 모바일뱅킹의 장애원인을 진단하

[WhaTap] 쉽게 이해할수 있는 성능 모니터링

[WhaTap] 국내 온라인 쇼핑몰의 중국 광군제 프로모션 성공을 이끈 성능 진단과 처방

[TreasureData] 발표자료

———————————————————————————————

 

OKKY 설문조사 이벤트 당첨자 발표

2월 중 OKKY 회원님들을 대상으로 진행된 설문조사 이벤트의 당첨자를 공지합니다.

ctrl+F를 누른 후 핸드폰 뒷번호를 검색해보세요!

기프티콘에 당첨되신 분들께는 문자메세지로 기프티콘이 발송될 예정이며, 1등 키보드에 당첨되신 분께는 경품 수령 안내를 위해 개별 연락 예정입니다.

이벤트에 참여해주셔서 감사합니다.

 

1등:  다이아텍 필코 마제스터치 컨버터블2 갈축(1명)

이*희(010-****-5224)

2등: 스타벅스 아메리카노 기프티콘(20명)

고*남 010-****-3683
박*성 010-****-1051
양*열 010-****-4298
정*호 010-****-9327
배*욱 010-****-7007
황*현 010-****-5468
윤*선 010-****-7810
조*호 010-****-4015
박*찬 010-****-0880
김*세 010-****-0053
김*기 010-****-3908
장*철 010-****-4452
이*신 010-****-0743
유*근 010-****-2123
정*록 010-****-6690
이*기 010-****-2742
최*수 010-****-8751
임*영 010-****-2613
김*정 010-****-3555
김*식 010-****-6678

 

3등: 스타벅스 더블샷 기프티콘(100명)

김*영 010-****-6993
박*연 010-****-7635
박*훈 010-****-2997
백*욱 010-****-3386
정*담 010-****-6380
김*화 010-****-3877
이*빈 010-****-7042
이*배 010-****-2983
석*준 010-****-3261
이*락 010-****-8327
박*성 010-****-9377
문*함 010-****-7668
김*욱 010-****-5552
이*기 010-****-1071
박*형 010-****-2778
이*빈 010-****-0956
박*하 010-****-7211
이*근 010-****-4854
이*현 010-****-3316
유*훈 010-****-9172
박*하 010-****-1811
김*현 010-****-5246
김*욱 010-****-3026
황*관 010-****-5867
최*원 010-****-7573
정*현 010-****-8537
한*기 010-****-8340
정*호 010-****-1321
허*희 010-****-1451
박*성 010-****-8377
송*단 010-****-4615
조*희 010-****-3815
이*우 010-****-9323
김*강 010-****-6950
이*호 010-****-1845
류*민 010-****-3576
문*필 010-****-4533
김*동 010-****-3300
김*호 010-****-8329
박*태 010-****-0484
전*민 010-****-4473
김*대 010-****-8457
이*준 010-****-5477
서*관 010-****-3310
김*진 010-****-4749
김*람 010-****-7855
이*희 010-****-5966
김*규 010-****-9710
이*진 010-****-4686
김*중 010-****-8065
정*용 010-****-8369
전*준 010-****-0299
심*한 010-****-2876
최*용 010-****-8186
조*호 010-****-6986
반*덕 010-****-3626
최*호 010-****-2297
유*원 010-****-9559
박*형 010-****-1937
이*원 010-****-0742
김*준 010-****-3026
박*덕 010-****-6786
김*진 010-****-5273
김*범 010-****-3546
문*현 010-****-7783
김*운 010-****-7613
곽*근 010-****-5028
조*덕 010-****-6741
성*영 010-****-9632
김*은 010-****-1744
박*명 010-****-0989
유*원 010-****-5911
함*호 010-****-8932
최*식 010-****-1316
남*진 010-****-8283
박*철 010-****-1641
윤*국 010-****-1032
김*석 010-****-6628
조*인 010-****-4311
이*규 010-****-5071
김*우 010-****-7993
김*호 010-****-0739
이*희 010-****-0462
이* 010-****-8587
김*태 010-****-7191
안*민 010-****-1004
김*욱 010-****-7682
정*필 010-****-7771
김*원 010-****-0725
이*민 010-****-1128
신*진 010-****-3047
김*호 010-****-8310
박*환 010-****-6209
우*식 010-****-3691
김*영 010-****-2030
정*호 010-****-7552
배*규 010-****-0956
이*진 010-****-9130
서*호 010-****-6016
이*형 010-****-7606

[보도자료] 와탭랩스-트레저데이터, 세미나 개최

와탭랩스-트레저데이터,세미나 개최…
데이터 기반 비즈니스·서비스 운영

국내 클라우드 SaaS형 APM 전문업체 와탭랩스(대표 이동인)와 미 실리콘밸리 빅데이터 전문업체 트레저데이터가 데이터를 이용해 기업의 비즈니스 및 서비스 운영 해법을 논의하는 자리를 마련한다고 밝혔다.

와탭랩스와 트레저데이터 한국지사가 함께하는 ‘데이터 기반의 성공, 서비스 기획과 운영’ 연합 세미나를 통해서다.

데이터로 비즈니스 사전예측 및 기획과 운영, 성능관리에 관심이 많은 기업 담당자와 일반인을 대상으로 열리는 이번 세미나는 오는 3월 9일 (목) 14시부터 서울 강남구 역삼동에 위치한 디캠프에서 개최된다.

전반적인 세미나의 흐름은 데이터 기반 성능관리 및 서비스 기획을 성공적으로 달성한 기업 우수사례 위주로 정보 공유 및 자유로운 소통, 무료 상담컨설팅 등으로 구성된다.

세미나 1부는 고영혁 트레저데이터 데이터사이언티스트의 ‘O2O 리테일커머스 비즈니스의 개인화 서비스 성공사례’를 시작으로 신현묵 와탭랩스 비즈니스 총책임자의 ‘국내 온라인 쇼핑몰의 중국 광군제 프로모션 성공을 이끈 성능진단과 처방’, 고영혁 데이터사이언티스트의 ‘회원기반 비즈니스 이탈자 예측과 이탈율 최소화 서비스 성공사례’, 신현묵 비즈니스 총책임자의 ‘장기간 원인모를 장애와 싸워온 모바일뱅킹의 장애원인을 진단하다’의 순으로 진행된다.

2부는 손영수 와탭랩스 최고 제품책임자의 ‘누구나 알기쉬운 성능관리이야기&모니터링 트랜드’를 시작으로, 고영혁 데이터사이언티스트의 ‘데이터기반 비즈니스를 위한 토탈 데이터솔루션’과 ‘데이터 기반 서비스 기획과 운영을 내재화하기 위해 극복해야할 이슈와 노하우’란 주제로 토론 및 질의응답 시간을 가질 예정이다. 이후에는 희망자를 대상으로 무료 현장상담 컨설팅을 가진다.

세미나 참석은 소정의 참가비와 함께 온오프믹스에서 신청할 수 있으며, 사은품 및 경품이 증정될 예정이다.

와탭랩스 이동인 대표는 “클라우드 기반인 두 업체의 솔루션은 성격은 달라도 기업 입장에서는 함께 사용하면 각기 다른 영역에서 시너지를 발휘할 수 있는 서비스기 때문에 이번 연합 세미나를 기획하게 되었다”면서 “이번 세미나를 통해 최근 GS인증 획득 등 기술력을 인정받고 있는 와탭랩스의 보다 새로운 면모를 보여줄 계획”이라고 말했다.

한편, 이번 행사는 은행권청년창업재단인 디캠프의 장소 후원을 통해 이루어진다.

기사링크 바로가기 >>