태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

척척박사 윤박사가 들려주는 AI | 네 번째, 알파고의 도전과 시사점

 

 

 

필자는 앞에서 인공지능의 개요와 함께 왓슨(Watson)에 대해 이야기 했다. 이번에는 왓슨과 함께 세기의 대결을 펼친 구글의 알파고(AlphaGo)를 이야기 하고자 한다. 만약 우리가 인공지능 시스템을 개발한다고 하면, 퀴즈쇼와 게임 중에서 세계인이 관심을 가질 수 있는 공통의 분모를 찾고 흥미를 유발할 만큼의 이벤트가 필요할 것이다. 그렇기에 다음 인공지능 이벤트는 아마도 그랑프리나 렐리와 같은 자동차 경주에서 무인 자동차 대결이 아닐까?

 

 

- 구글의 딥러닝 도전과 이슈 만들기
  2016년 3월, 우리는 잊지 못할 세기의 대결을 보았다. 구글의 딥러닝 기반의 알파고와 이세돌 9단의 대국, 인간과 컴퓨터와의 3번째 큰 대결이었다. 첫 번째 대결은 IBM이 만든 체스 전용 컴퓨터 “딥 소트(Deep Thought)와 세계 체스 챔피언들과의 대결이다. 이 대결은 대부분 인간과 컴퓨터의 무승부로 마무리되었다. 두 번째 대결은 퀴즈쇼이다. IBM은 제퍼디 퀴즈쇼에서 왓슨을 소개하고, 퀴즈쇼 역대 우승자들을 상대로 일찌감치 승기를 잡은 대결이었다. 세계적인 관심을 이끌기에는 너무나 싱거운 사람의 패배였다. 세 번째 대결이 바로 우리가 잘 알고 있는 알파고와 이세돌 9단의 바둑이다. 구글은 이전에 IBM이 체스나 퀴즈쇼와 같은 챔피언쉽 대결로 개발한 딥러닝 성능이 우수하다는 것을 알리는 아주 큰 이벤트가 필요했다. 그래서 구글은 많은 게임들을 가지고 고민하였고, 이중에서 바둑을 가장 좋은 이벤트로 선택하였다. 특히 바둑은 우주의 원자수보다 많은 경우의 수를 가지고 있고 완벽한 탐색이 불가능하다는 이유와 함께 세계적인 챔피언스리그를 체계적으로 운영하는 게임 중의 하나였다.

 

 

 

 

바둑은 많은 경우의 수를 계산하는 NP(Non-deterministic, Polynomial time) complete와 유사한 문제에 대한 많은 수의 정답에서 최적의 정답을 찾는데 많은 시간이 소요되는 계산 복잡도(Computational Complexity)의 이슈를 가지고 있다. 그렇기 때문에 구글이 개발한 알파고는 왓슨이나 Deep Fritz보다 더 우수한 알고리즘이라 할 수 있다. 알파고와 이세돌 9단의 대국은 인공지능의 부활을 알리는 매우 훌륭한 이벤트였다.

 

 

- 알파고의 알고리즘은 어떻게 움직이나?
알파고는 경우의 수를 빠르게 탐색하는 인공지능 시스템이다. 알파고의 동작 원리는 게임을 좋아하는 사람들이라면 가장 쉽게 할 수 있는 동작의 원리를 가지고 있다. 게임은 승리를 위한 경우의 수를 가지고 있고, 이것들의 대표적인 것은 미로 찾기, 길 찾기, 이동장애물 피하기 등과 같은 것이다. 이러한 경우의 수를 찾는 동작 원리를 표현할 때, 보통 트리(Tree) 탐색이라는 방법을 적용한다. 대표적인 알고리즘은 몬테카를로 트리탐색(MCTS: Monte Carlo Tree Search) 알고리즘이다. 바둑은 다른 게임에 비해 경우의 수가 많은 10,360개가 존재한다. 바둑의 규칙을 고려하면 평균 250개로, 우주 원자의 개수 1,080개보다 많은 경우의 수를 가지고 있다. 아래 그림은 알파고에서 사용한 몬테카를로 트리 검색 방법이다. 이 방법을 이용하여 알파고는 현존하는 바둑 기보의 모든 경로를 학습하였다. 몬테카를로 트리 탐색은 선택(Selection), 확장(Expansion), 시뮬레이션(Simulation), 역전파(Backpropagation)로 구성된다. 최초 바둑돌을 두는 시점을 최상단 루트(Root)라고 했을 때, 상대방이 두는 바둑 돌을 다음 시점으로 하여 그 다음 점에서 승률이 높은 경로를 추적하면서 경우의 수를 줄여 나가는 방법이다. 이것은 대부분의 게임에서 적용되고 있다.

 

 

* 참조 : mastering the Game of Go with Deep Neural Networks and Tree Search, google Deepmind

 

 

 

알파고는 바둑에서 모든 경우의 수를 학습하기 위해 넓이 탐색을 이용하여 다음 수를 찾는 기보의 패턴을 반복적으로 학습시켰다. 그리고 각 단계별 시뮬레이션 예측 결과를 트리 상태 정보에 업데이트 하였다. 하지만 기계학습을 이용한 경로 추적의 단점은 경우의 수가 없는 입력이 반영되었을 때이다. 이 경우에는 최적의 경로를 찾기 위해 이전의 경로 값들이나 새로운 경로를 재구성하는 문제를 가지고 있다. 그래서 이세돌 9단이 전혀 생각하지 못한 곳에 바둑돌을 놓았을 때, 알파고는 사람이라면 생각할 수 있는 “왜 그곳에 돌을 두었을까” 하는 고민보다는 기보에서 최적의 경로만을 찾아 바둑 돌을 두는 실수 아닌 실수를 하게 되었다. 그래서 알파고 팀은 학습한 기보에만 최적화되는 것을 예방하기 위해 자기 학습을 위하여 강화학습을 함께 적용하였다. 그럼으로써 승률을 높이는 최적의 경로를 탐색할 수 있는 구조로 개선하였다. 아래의 그림은 알파고의 패턴 학습에 강화학습 모델을 적용한 신경망 학습 구조이다.

 

 

* 참조 : mastering the Game of Go with Deep Neural Networks and Tree Search, google Deepmind

 

 

그림을 보면, 알파고는 정책 네트워크(Policy network)라는 예측 네트워크를 두고 기계 학습을 하였다. 정책 네트워크는 CNN(Convolutional Neural Network) 이라는 딥러닝 구조를 가지고 있다. 학습을 위해 방대한 양의 기보 데이터를 KGS라는 사이트에서 확보하였다. 알파고는 총 3천만 개 정도의 상태값을 가지고 정책 네트워크를 훈련시켰다. 그리고 몬테카를로 트리 검색을 이용하기 위해 Rollout Policy라는 네트워크를 준비하여 네트워크를 강화시켰다. 그리고 강화학습(RL: Reinforcement Learning)을 이용한 자가 학습으로 네트워크 성능을 향상시켰다. 또한 알파고는 몬테카를로 트리 탐색을 적용한 상태값을 Value Network의 학습 데이터로 이용하여 학습 완성도를 높임으로써, 이세돌 9단과의 대결에서 승리할 수 있었다.

 

 

- 알파고는 왜 왓슨보다 활용을 못할까?

앞에서 살펴본 것과 같이, 알파고는 바둑에서 최적의 경로를 찾기 위해 인공지능을 적용한 사례이다. 그리고, 바둑이라는 게임을 위해 1,202개의 CPU와 176개의 GPU 자원을 사용한 시스템이다. 만약, 알파고를 사람들 개개인의 행동을 학습하기 위해 사용한다면 구글의 모든 컴퓨팅 자원을 동원해도 어려울 것이다. 이것은 알파고뿐만 아니라 차세대 인공지능 시스템의 한계이기도 하다. 그리고 알파고를 적용할 수 있는 산업 분야도 극히 제한적이다. 예를 들면, 게임, 자율주행, 스케줄링 및 계획, 고객 추천 서비스 등과 같은 분야가 대표적일 것이다. 이에 비해 왓슨은 자연어를 기반으로 만들었기 때문에 사람과 밀접한 업무 또는 서비스를 빠르게 구성할 수 있다. 그래서 왓슨은 자동응답 서비스, 개인화 서비스, 고객 추천 서비스 등과 같이 다양한 분야에서 직접적으로 적용되거나 도입을 준비하는 대표적인 인공지능 시스템이 된 것이다. 이처럼 왓슨이나 알파고와 같은 인공지능 시스템이 아직까지 만능은 아니다. 하지만 사람의 일자리를 뺏는 구조로 기업이 인공지능 기술을 도입하고 있는 것은 사실이다. 그렇기 때문에 인공지능 서비스를 기획하고 도입하는 기업들은 사람의 일자리를 뺏는 시스템이 아닌 보조해 주는 시스템으로 인공지능을 고민하고 서비스를 개발하는 것이 필요하다.

 

다음에는 인공지능 시스템을 구축하기 위한 인프라와 플랫폼에 대한 이야기 하고자 한다. 인공지능 시스템을 어떻게 도입할까? 어떤 서비스를 개발할까? 도 중요하지만 기본적으로 어떻게 구성하는가가 현재 시점에서는 무엇보다 중요할 것이다.

 

 

 

 

 

 

 


 

저작자 표시
신고

UX 이야기 | 예상한다, 2017년 디자인 툴


나도 모르는 사이에, 달라지고 있는 디자인들.


고작, 몇개월이 지났을 뿐인데 지금 다시 보면 구식도 이런 구식이 없는 것이 디자인이지요. 

2017년 이러한 디자인이 돋보이고 있습니다.



역사적으로 디자이너보다 개발자를 위한 툴들이 많이 있습니다.

그 이유 중 하나는, 


개발자 스스로가 개발을 위한 툴을 만들수 있지만 디자이너들은 소수만 할 수 있기 때문입니다. 



디자인 세계가 중요해지고 있다. 

Design space is getting serious


2016년에는 모든 디자인 툴 세계가 세련되게 개선되는 징후가 나타나기 시작했습니다. 

Invision이 Macaw, SilverFlow, Easee, Muzli등을 인수했고, Marvel은 Pop을 인수했으며,

 Google은 Pixate를 인수하고 갤러리 및 스테이지의 새로운 도구 세트를 발표했습니다. 

Figma는 Adobe가 따라 잡으려고 노력하는 동안 흥미로운 작업들을 하고 있습니다.


저는 2017년이 디자이너에게 있어 정말 아름다운 해가 될 거라고 기대하고 있습니다. 



성공적인 디자인 접근 

The winning approach to design


디자인과 코드가 통합되어 디자이너가 모든 것을 만들어 제공할 수 있다는 희망이 생겨났습니다.

아직까지는 그러한 위치에 도달하지 않았지만 여러 다양한 프로토타이핑 툴들의 급부상이

앞으로 그렇게 될고라고 증명하고 있습니다.  


그러한 이유는 현재 명확해졌는데, 프로젝트 작업물이 모든 화면과 모든 디바이스에 걸쳐

정상적으로 작동하게 만드는 것은 쉽지 않습니다.


적어도, 디자이너들은 뭔가 잘못되었을 때 책임을 떠 넘길려하지 않을겁니다. ^-^


 

더 나은 워크플로우

A better workflow


2016년 훨씬 이전부터 시작된거이지만, 

이제는 하나의 툴이 다양한 문제를 해결할 수 없다는 게 명백해졌습니다.

오히려, 서로 연동되는 세트로서의 툴이 필요한데 스케치앱이 서로 각기 다른 장단점을 연동하고,

문제를 해결해주는 가장 대표적인 툴로써 팀웍, 고객 피드백, 디자인 산출물, 향후 개선안이

함께 이루어지는 하나의 워크플로우로 모든 것을 구성하게 만듭니다. 

모든 중요한 개발의 핵심인 버전컨트롤은 개발자들이 Github과 유사한 것으로 해결했지만 

디자이너팀을 팀 작업임에도 불구하고 많은 '땜빵' 작업을 필요로 했습니다.

당연히 디자인 툴은 전부터 이를 해결하고자 시도하고 있고 

일부는 이미 제작 중에 있습니다.



실제 데이터로 디자인하기

Design with real data


2016년에 시작된 또 다른 기대 실제 데이터를 적용한 디자인입니다.

실개발이 시작되기 전에 더 나은 의사결정을 내리고 핵심 사례를 찾는 데 도움이 되는 많은 의미가 담겨있지요.

실제 데이터로 디자인하면서 가장 놀랍게 보이는 건 

한 블로그 게시물이 전체 패러다임의 전환을 만든 것처럼 보인다는 것입니다.

이것은 , 더 많은 사람들이 더 좋고 멋있는 글을 작성하게 하는 바탕이 될 것 입니다. 



콘텐츠가 왕이다.

Content is the king


다양한 디바이스 및 화면 크기를 위한 디자인하기 위해선 많은 제약점들이 있습니다.

요지는 콘텐츠가 킹왕짱이다! 

인데, 그 뜻은 워딩(글내용), 사진, 일러스트레이션 그리고 타이포그래피에 포커스를 해야한다는 뜻이며

그렇게 함으로써 우리가 만드는 콘텐츠는 일관되어야 하고 웹페이지, 앱, 블로그 및 소셜미디어에서 생존할 수 있다는 것입니다.



2017년 희망하는 것들 

what's missing or a wish list for 2017


초기의 스케치앱은 포토샵에서의 UI작업하는 것 보다 나은 방법으로 작업하기 위해 만들어졌습니다.

피그마는 스케치앱보다 더 나은 제품이 되기 위해 UI디자인을 툴 시장에 나왔고

새로운 아이디어는 다른경쟁 툴이 시장되는 걸로 아이디어의 가치를 증명하고 있습니다.

어찌되었던 그것은 진화라고 볼 수 있을 겁니다.

무슨일이 일어나고 있는지 쉽게 알 수는 있지만 

정말 어떤 일이 일어날지는 지켜봐야 할 거 같습니다.



우리가 사용하는 툴들은 그닥 똑똑하지 못하다

Our tools aren't SMART

앞으로 저는 더욱 많은 툴들이 등장해서 디자인 프로세스를 개선해주기를 바랍니다. 

우리가 앞으로 뭘 해야하는 지로 끝나는게 아닌 앞으로 어떻게 더 개선 할 수 있는 지 알려줘야 한다고 봅니다.

아니면,

더 나은 선택권(접근성, 가독성, 기본 디자인 이론 등)을 제공해 주어야 할 것입니다.

자동 맞춤법이나 시각적 커닝과 같을 디자인결정에도 적용되며

동일한 경우에도 항상 더 똑똑한/ 유리한 쪽으로 도움을 줄 것입니다. 


 

인공지능과 머신러닝

AI and machine learning


디자인은 시스템이지만 사람은 모든 경우의 수를 기계처럼 한 눈에 보지 못합니다.


경험많은 디자이너가 신입 디자이너보다 더 빨리 문제 해결하는 방법을 찾을 수 있는 이유는 당연한 얘기지만, 

바로 '경험'이 많기 때문입니다.

그 경험의 가장 중요한 부분은 가능한 모든 조합(combinations)방법을 처리하는 것에 있고

그것은 컴퓨터가 해줄 수 있는 부분이라고 생각합니다. 




디자인에 아토믹 디자인 방법론을 적용하기 

Bringing atomic design principles to design practice



코드 요소 속에는 컨텍스트(context)와 상태(states)가 있습니다.


Atomic design principles(원자 디자인 원칙)

http://atomicdesign.bradfrost.com/chapter-2/



e디자인 툴의 시장흐름을 어떻게 보던지 한 가지 활실한 건 앞으로 더욱 많은 툴들이 나올 것입니다.

인터랙티브 디자인은 계속 진화하고 있으며 웹과 앱을 사용하는 새로운 방법은 결국 새로운 도전을 줄 것입니다. 


하루하루 다른 디자인이 나오고 있는 지금,


" 디자인 업계에서 우리는 재미난 시기에 살고 있는 것 같습니다. "



출처 : https://medium.com/froont/the-state-of-design-tools-in-2017-5fc15fccd6dd?ref=webdesignernews.com#.wdas1hnsw

 

 

 

 



저작자 표시
신고

UX이야기 | 정말 별로인 아이디어

 

 

`좀 잔인하다고 할지 모르겠지만, 저는 스타업들이(서비스 오픈 이전 포함) 초기 단계에 있는 아이디어를 발견하는 성공 감별사 일을 합니다.

그들이 바보라고 무시하고 나서 나중에 보면 저는 그들이 못 믿을 정도로 대박 나는 걸 봅니다.

이런 말도 안 되는 일이 저에게 적어도 4번은 일어난 거 같습니다.

매번 그들의 아이디어가 '구리다'라고 말을 안 할 거라고 스스로에게 약속하지만 이런 일은 매번 일어났습니다.

여기서 얻은 교훈이 오만함에 대한 경고인지는 모르겠지만 저는 여러분께 공유할 두 개의 이야기가 있습니다.

 

 

2009 년 말, 저는 누군가로부터 새로운 프로젝트에 대해 어떻게 생각하는지 만나서 자문받아 보고 싶다는 이메일을 받았습니다.

그 당시 저는 디자이너였고 그는 저에게 몇 가지 조언을 듣기를 원하고 있었습니다.

그래서 저희는 샌프란시스코의 전형적인 스타트업 미팅 장소인 더 크리머리에서 만나기로 했습니다.

 

"저는 카탈로그 모바일 앱을 만들고 싶어요. 앱은 패션 카탈로그 같은 건데 사용자들이 카탈로그 아이템을 직접 공유하고 정리할 수 있어요."

라고 하면서 주머니에서 아이폰을 꺼내더니 최소 기능만 구현된 프로토타입을 보여주었습니다.

UI는 평범한데 뭔가 어설펐습니다.

옆으로 스와이프 하는 내비게이션은 몇 번의 시도를 해야만 구동되었는데 그는 끊임없이 여성 의류가 계속해서 보이는걸 보여줬습니다.

 

저는 "좋네요.."라고 말은 했지만 제 머릿속엔 이미 그의 아이디어를 별로라고 생각했습니다.

생각해 보세요. 지구에서 어떻게 실리콘 밸리의 20대의 청년이 중년 여성을 타깃으로 서비스를 하려고 할까?

그리고 중년 여성들이 과연 이 서비스를 원하기는 할까요? 아니 중년 여성들이 아이폰은 가지고 있을까요?

제 기억엔 이런 질문들을 물어본 걸로 아는데 그가 뭐라고 답했는지 기억 조차 나지 않습니다.

 

저는 '이건 정말 아니다.(What a stupid idea)'라고 생각했습니다.

그리고 우리는 커피를 다 마시고 나서 그는 내가 무관심하다고 느꼈던 거 같습니다.

그렇게 우리는 헤어지면서 그가 저에게 이렇게 물어봤습니다.

"그런데 저희가 만든 앱 이름은 어떻게 생각하세요? 저희는 이걸 핀터레스트라고 부르고 있어요."

 

Pinterest  9개월 만에 회원수 1,700만을 달성한 초대박 소셜 서비스

 

 

 

2012년 저는 뉴욕의 평범한 레스토랑에서 누군가를 만나 저녁을 하고 있습니다.

저희는 저녁을 먹기 시작할 때 그 사람은 저에게 모바일폰을 보여 주면서

 "저는 인스타그램처럼 동영상을 쉽게 공유하는 모바일 앱을 만들고 있습니다."라고 말했습니다.

 

프로토타입임에 불구하고 디자인 완성도도 높고 개발도 잘되어 보였습니다.

그러나 저는 수많은 사진, 동영상 앱을 이미 사용해봤습니다.

모바일 동영상 시장(앱)은 이전에 많이 망한 서비스가 넘쳐났기에 저는 그에게 전혀 승산이 없을 거라 생각했습니다.

과연 이 사람이 다른 모바일 동영상이 수없이 시도했지만 이루지 못한 장애들을 어떻게 극복할 수 있을지 생각했습니다.

그 앱은 엄청나게 대박인 기능이 하나 있었는데 화면에 손가락을 화면에 터치하는 것으로 동영상 녹화가 되는 것이었습니다.

그렇게 해서 짧은 동영상을 많이 찍을 수 있고 그렇게 찍은 동영상을 서로 연결하여 스토리로 만들 수 있는 것이었습니다.

 

그러나 앱은 앱 내 피드(feed)가 있는 독자(self-contained) 앱이었고 바이럴을 하는 요소가 없었습니다.

저는 이 앱이 성공할 요소를 가지고 있다고 생각하지 않았습니다.

 

저는 '이건 정말 아니다.(What a stupid idea)'라고 생각했습니다.

그와중에 저는 앱 로고만은 유독 맘에 들어했는데 그 로고는 녹색 배경에 "바인(Vine)"의 앞 문자를 딴 V로 되어있었습니다.

 

 Vine  론칭 1년 후 iOS 버전 한정 가입자만 1300만명을 돌파한 초대박 동영상 기반 소셜 서비스

 

 

 

다시 핀터레스트 창업자 벤 실버맨과 바인 창업자 돔 호프맨과 미팅을 돌이켜 생각해보면 그들에 대한 제 반응은 참으로 부끄럽기 짝이 없습니다.

그 두 사람은 모두 유별나게 열정적이고 활력이 넘친다는 걸 여러분이 그들을 만나면 바로 알 수 있을 겁니다.

 

두 사람은 미래를 보았고 미래를 만들었습니다.

They saw the future and they built it.

 

그러나 어떤 이유이던 그들의 초기 제품에 대한 제 첫 반응은 긍정적인 면을 보지 않고

제일 먼저 어떤 문제점들이 있는지 발견하고 아이디어를 무시했다는 것입니다.

미래는 현재라는 이름의 렌즈를 통해 알 수 없습니다.

무의식적으로 시시하거나 쓸모없게 보이는 첫 번째 버전의 제품을 무시하는 것은 매우 쉽습니다.

아니면 정말 별로인 아이디어이거나 말이죠.

 

[출처: https://dcurt.is/what-a-stupid-idea]

 

 


------------------------------------------


3년 전에 읽은 글인데 못 보신 분들이 많아 문장을 다듬어 다시 공유하기로 생각했습니다.

예전이나 지금이나 우리는 정말 별로인 아이디어가 가득 찬 세상에 살고 있습니다.

뭔가 주류에 탑승해야 잘 될 거 같고 그래서 항상 뒤따르기만 하고..


알파고 이후 한국형 알파고를 만든다고 하고,
포케몬고 이후 한국형 포케몬고 만든다고 하고,
AR, VR, IoT, 드론, O2O, 전기차, 자율주행 기술 등 현재 신문에 자주 언급되는 제품/서비스만 투자 가치가 있다고 본다던가.

국가에서 스타트업을 육성한다고 하는데 실상은 단지 연륜이 많다는 이유만으로 멘토라는 탈을 쓴 비전문가의 심사를 통과해야만 된다던가.

비전문가가 전문가의 아이디어를 평가하고 사업을 만드는 현실.

여러분들은 아이디어는 있습니까? 아이디어를 다른 사람에게 설득시킬 수 있습니까?
저는 그렇게 하지 못할 수도 있다고 생각합니다.
그렇다고 좌절할 필요도 없다고 생각합니다.

소신은 가지고 준비하되 시야를 넓혀 좋은 결과 맺기를 바랍니다.

 

 

 

By. 이상용

 

 

 


저작자 표시
신고
  • 3월에는 2017.03.30 10:04 신고 ADDR 수정/삭제 답글

    신설코너네요~ 전에 읽었던 내용인데, 다시 봐도 많은 걸 느끼게 하네요!! 재밌게 읽었고 앞으로도 칼럼? 기고? 기대하겠습니다!!

척척박사 윤박사가 들려주는 AI | 세 번째, 왓슨의 도전과 시사점

 

 

IBM은 1997년 체스 게임을 통해 인공지능의 미래를 소개하였다. 그 이후, IBM 연구팀의 폴 혼과 찰스 리켈은 새로운 도전을 찾던 중 제퍼디 게임에 주목하였고, 5년간의 개발 기간을 거쳐 사람의 말을 해석하고 답을 주는 왓슨을 개발하였다.

 

 

우리는 왓슨이 사람의 질문을 어떻게 해석하고, 그 질문에 대한 답을 줄 수 있을까? 라는 의문을 가질 것이다. 컴퓨팅 지식을 가지고 있다면, 그 답을 쉽게 풀 수 있다. 그리고 언어를 처리하는 기술도 인공지능의 한 영역이라고 전문가들은 답해 줄 것이다. 인공지능 영역에서 이것을 자연어 처리(NLP : Natural Language Processing)라 한다. 사람의 언어인 자연어는 문법이라는 체계적인 규칙을 가지고 있다. 자연어 처리는 언어의 규칙에 맞게 문장을 해석하고 처리하는 방법(알고리즘 : Algorithm)이 중요하다. 이는 사람의 언어가 국가나 지역에 따라 문법이 다르기 때문에 자연어를 처리하는 방법 또한 조금씩 차이가 있기 때문이다. 대표적인 예가 언어 간의 번역의 차이이다. 자동으로 언어를 번역하기 위해서는 언어가 가지고 있는 고유 패턴과 의미를 이해하는 방법 또한 중요하다. 그래서 현재 왓슨은 사람의 언어를 정확하게 번역하고 이해하기 위해 언어의 관계성을 학습하고 해석하는데 집중하고 있다.

 

 

 

- 왓슨의 처리 동작은
일반적으로 자연어를 처리하기 위해서는 언어의 규칙 즉, 문법에 맞도록 단어를 분리하고 정의한다. 이를 형태소 분석(Stemming)이라 하며, 형태소 분석 엔진이 잘 갖춰지기 위해서는 단어 사전의 역할 또한 중요하다. 형태소 분석이 완료되면, 단어가 가진 의미 가중치를 계산한다. 이 가중치는 단어 간의 연관이나 의미의 연결성을 결정하는데 필요한 값이다. 특히 수집된 문서들에서 형태소를 분석하고, 문서와 단어 간의 관계, 중요한 키워드를 판단하기 위한 단어의 특징을 의미 검색을 위한 구조로 변환한다. 그리고 사람의 질문에 대한 답을 찾아 화면에 출력한다. 이를 단계적으로 표현하면 아래의 그림 2와 같다. Watson은 수집된 문서에서 각 문장의 단어를 형태소 분석으로 추출하고, 이들 간의 관계와 가중치를 계산한다. 각 문장의 단어는 키워드 매칭 과정을 통해 단어의 유효성을 판단한다. 즉, 단어의 매칭을 통해 중심어가 될 수 있는 단어(주어 또는 명사)를 선정한다. 예를 들면 그림 3과 같이 두 개의 문장이 있고, 각각의 단어 관계와 키워드 매핑을 통해 질문에서 발견할 수 있는 단어인 “Gray”를 정답으로 하며, 이러한 과정을 컴퓨터가 반복해서 수행하고 학습하여 빠르고 정확한 답을 찾도록 한다. 이렇게 학습된 데이터의 정답셋을 검색엔진에 넣고, 사용자 또는 질문자가 넣은 질의어를 형태소 분석한다. 그리고 정답셋의 검색엔진을 통해 관계가 높은 답을 찾아 제공한다. 정답의 정확도를 높이기 위해 기계학습의 정답셋을 보정한 후, 다시 기계학습을 시키는 작업이 필요하다. 이 과정에서 사람의 손으로 보정하는 큐레이션(Digital Curation)이 필요하다. 정답셋의 예는 그림 4와 같다.

 

 

- 왓슨으로 무엇을

Watson의 데이터는 2억 페이지 이상의 정형, 비정형 페이지를 수집하여 정답셋을 구성하였다. 그리고 IBM 블루믹스 플랫폼에서 새로운 비즈니스 아이디어를 시범 운영 · 시험 · 배치하고 있다. 국내에서도 롯데그룹, SK 하이닉스, 대한항공 등에서 Watson을 도입한 지식서비스 구성을 계획하고 있다. 하지만 한글 사전의 정확도에 적용하기 위해서는 어느 정도의 시간이 소요될 것으로 예상한다. 현재 Watson은 금융, 방송, 의학, 쇼핑, 스마트 홈스피커 등과 같은 분야에서 다양하게 적용되고 있고, 자동 응답 메신저나 비서 서비스 등과 같은 산업 분야에서도 적용할 예정이다.

 

- 왓슨의 미래 모습은
Watson은 사람의 언어를 해석하고 필요한 지식 정보를 제공하는 시스템이다. 사람의 언어와 관련이 있는 행동과 습성을 컴퓨터에게 학습시키고, 지식을 전달하는 지능정보 서비스이다. 예를 들면, 학교에서 학생들의 수업을 보조하는 보조교사, 장애우들의 학습을 보완하고 지원하는 지식 단말 서비스, 차량의 주행과 운전 중의 사고를 예측하는 서비스 등은 좋은 예라 할 수 있다. 이렇듯 인공지능 시스템을 사람의 일자를 대신하는 것이 아닌, 보조적인 역할을 수행하는 방향으로 가다듬어 진화시킨다면, 인공지능의 보다 밝은 미래를 기대해 볼 수 있을 것이다.

 

왓슨에 이어 다음 시간에는 우리 사회를 압도한 인공지능의 화두, 알파고에 대해 이야기해 보고자 한다.

 

 

 

 

 

 

 

저작자 표시
신고
  • 3월에는 2017.03.30 10:05 신고 ADDR 수정/삭제 답글

    약간은 어렵지만, 인공지능의 큰 흐름과 역사를 볼 수 있어서 즐겨 봅니다~~

척척박사 윤박사가 들려주는 AI | 두 번째, 인공지능의 역사와 비하인드 스토리

 

 

인공지능이라는 개념을 최초로 만들어낸 마빈 리 민스키(Marvin Lee Minsky) 교수는 “인간의 뇌는 다양한 능력을 기반으로 하는 상호작용 요소들의 결합체“를 주장하면서 그의 제자들에게도 그 기능을 강조하였다. 그와 함께 인공지능의 발판을 만든 존 매카시(John McCarthy)는 1956년 다트머스 학회에서 처음으로 ”인공지능(Artificial Intelligence)“이라는 용어를 창안했고, LISP 라는 프로그래밍 언어를 설계하고 구현하였다. 두 거장을 중심으로 MIT에서 인공지능 프로젝트가 시작되었고, 대표적인 제자로는 구글의 레이 커즈와일(Ray Kurzweil)이 있다. 그는 인간의 두뇌와 자연스럽게 하나가 될 것이라는 사이보그 이론을 주장하였다. 관심 있는 연구 분야로 나노로봇, DNA 컴퓨팅, 양자 컴퓨팅, 뇌공학 등의 인공지능 기술을 함께 연구하였다. 그는 인공지능이 인간의 진화와 마찬가지로 복잡한 패턴과 창의적이고 더 고등한 감정들을 표현하는 능력을 강조하였다. 재미있는 사실은 이들은 심리학과 철학 같은 인문학에도 높은 관심을 가지고 있었다.

 

 

 

하지만 이들의 활동에도 인공지능은 1970년대와 1990년대 두 번의 침체기가 있었다. 초기에는 컴퓨팅 기술의 발전으로 극복하였고, 두 번째는 게임 산업과 유비쿼터스 컴퓨팅을 통해 부활하였다. 첫 번째 침체기라 불리우는 1970년대에는 인공지능이 가진 진보적 성향에 대한 대중의 반감과 두려움이 있었다. 특히 “2001년 스페이스 오딧세이”라는 영화에서 보여준 인공지능 시스템은 대중에게 인공지능의 두려움을 보여주기 충분하였다. 인공지능 연구자들은 HAL 9000과 같은 역할의 인공지능 시스템을 만들려는 의지를 가지고 있었다. 하지만 민스키 교수는 오히려 역으로 “왜 우리는 2001년 HAL을 얻지 못했나?” 라는 질문으로 던짐으로써 인공지능이 가진 진보의 방향을 경계하도록 주문하였다. 이는 인공지능 시스템의 방향이 인간윤리를 넘어선 잘못된 방향성을 경계하고, 윤리와 목적성을 명확하게 하는 계기가 되었다.

 

[이미지 출처: laughingsquid.com, reddit.com]

 

 

그리고, 1990년대는 미국에서 인공지능 연구지원이 삭감되면서 많은 인공지능 연구자들이 기계학습(머신러닝), 로봇공학, 컴퓨터 비전 등 구체적인 하위 영역으로 이동하면서 제한적인 연구에 집중하였다. 이 과정에서 인공지능은 침체기를 보이는 듯 했지만 우리의 일상생활에 알게 모르게 조금씩 다가왔고 편리한 기능을 제공하고 있었다. 예를 들면, 세탁기의 퍼지 기능, 냉장고의 스마트 점검, 자동차의 자동 주차나 주행, 카메라의 손떨림 방지 기능, 다촛점 인식, 헬스케어, 스마트 서비스 등과 같은 자동화된 생활형 서비스가 대표적이다.

 

 

 

[이미지 출처: MOTORGRAPH, 녹십자 헬스케어 '워커+디', 미스핏 '샤인'과 조본의 '조본업'(이미지 좌측 상단부터 시계방향 순)] 

 

 

이처럼 두 번의 침체기를 통해 인공지능은 작은 기술과 기능으로 개발되었으며, 현재는 이것들을 연결하고 통합하는 과정을 진행하고 있다. 그러면서 인공지능의 진보적 성향을 점검하고 다듬는 도덕적 역할도 함께 진행하고 있다. 꿈이 현실로 이루어지기 위해 인공지능 연구자들은 각자의 분야에서 기술을 연구하고 이론과 현실의 간격을 조금씩 메우고 있다. 또한 공상과학이라는 테마를 중심으로 미래로의 발전을 지속적으로 이어가고 있다. 필자는 재미있는 인공지능을 이해하고 싶다면, 2001년 스페이스 오딧세이와 함께 메트릭스와 마이너리 리포트라는 영화를 먼저 권하고 싶다. 로봇이 나오고 우주를 돌아다니는 인공지능 기술도 재미있지만, 인공지능이 가진 진보적 경계에 대해서 많은 부분을 함께 고민하고 이해할 수 있는 영화이기 때문이다.

 

다음 시간에는 왓슨의 도전과 시사점이라는 주제로 인공지능이 가진 인간의 언어 처리 방법과 인공지능 플랫폼 설계에 대해 다루고자 한다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

저작자 표시
신고
  • 2월에는 2017.02.22 09:48 신고 ADDR 수정/삭제 답글

    지속해서 인공지능에 대한 여러 이야기 담아주세요~~

척척박사 윤박사가 들려주는 AI | 첫 번째, 인공지능의 현재와 미래

 


최근에 IBM의 왓슨(Waston)과 Google의 알파고(AlphaGO)가 등장하면서 서비스 기술과 산업 활용의 측면에서 인공지능에 대한 관심이 급격히 증가하고 있다. 또한 4차 산업 혁명에서 자동화와의 연결성이 강조되면서 산업 환경의 변화를 주도적으로 수행하는 기술 분야로 인공지능의 역할이 강조되고 있다. 이러한 인공지능 기술은 다양한 분야에서 자동화를 주도하고 있다. 특히 기계는 단순한 움직임에서 벗어나 사람과 같은 지능, 생각, 행동을 수행하는 기계학습 분야를 중심으로 발전하고 있다. 기계학습은 문제를 해결하기 위해 정해진 일련의 절차인 알고리즘(Algorithm)으로 인간과 유사하게 컴퓨터 프로그램으로 구현된 딥러닝(Deep Learning)을 중심으로 확대되고 있다.

 

 

인공지능은 몇 년 전까지만 해도 게임 및 시뮬레이션과 같은 산업분야에서 사람이나 동물 등을 모방하는 동작 처리와 전자상거래에서 서비스 또는 물품 추천을 중심으로 발전하였다. 하지만 게임분야에서 대용량의 3차원 데이터와 영상 처리가 증가하면서 사람 또는 동물의 동작을 모방하여 처리하는데 한계에 이르렀다. 특히, 바둑과 같은 최적의 경로 추적 게임에서 이용자의 다양한 행위에 대한 경우의 수를 실시간으로 학습하고 처리하는 기계학습의 빠른 연산이 필요하였다. 그리고 서비스 추천에서도 다량의 데이터가 수집되고, 사용자의 다변화된 상품 구매 패턴을 학습시키기 위한 대용량 데이터 처리가 문제로 등장하였다. 이러한 상황에서 인공지능은 또 한 번의 침체기를 가지는 듯 했지만, 자연스러운 학습과 최적의 경로를 결정하는 알파고가 등장하면서 딥러닝이 기계학습의 새로운 디딤돌로 등장하게 되었다. 또한 대용량의 데이터 분석 한계성과 반복적인 처리가 많은 사람이나 동물의 동작의 처리에서도 빠른 인지와 자연스러움을 시도하는 수준으로 적용이 가능하게 되었다. 이렇듯 인공지능이 다양한 산업 분야로 적용될 수 있는 환경은 대용량 데이터를 실시간으로 처리하는 빅데이터 기술과 인프라의 자율성이 높은 클라우드 기술이 함께 적용되었기 때문이다.

 

이제 인공지능의 다음 목표는 다양한 산업분야로 확대해 고성능의 분석 기능을 가지고 자기 복제(Self-Organization)가 가능한 전문가 수준의 지능 서비스로 발전시키는 것이다. 또한 자연계에 대한 복잡도를 학습하는 알고리즘과 신경계 알고리즘이 결합되어 자기 복제와 다차원 연산이 강화된 인공지능 학습 모델로 재구성함으로써 산업분야별 최적의 인공지능 모델로 발전하는 것을 목표로 해야 한다. 그리고 여기에는 미래에 인간의 생활을 보조하는 수준에서의 올바른 역할과 제어 기능이 반드시 포함되어야 할 것이다. 인간을 능가하는 지능을 지닌 인공지능이 존재하는 시대가 빠르게 다가오겠지만 인간이 지닌 사랑, 우정, 연민, 공감과 같은 감정의 특이점을 학습시키는 미래 사회의 도덕률 관점에서는 조심스러운 접근과 반영이 필요하다.

 

이후에는 인공지능이 태어나고 성장하면서 다루어진 비하인드 스토리를 시작으로, 산업분야별 인공지능이 적용된 사례와 함께 인공지능의 중심 기술과 발전 방향을 다루고자 한다.

 

 

 

 

 

 

저작자 표시
신고
  • orion 2017.01.25 10:02 신고 ADDR 수정/삭제 답글

    척척박사님의 활약이 기대됩니다!^^

  • 새초롬하게 2017.01.26 10:58 신고 ADDR 수정/삭제 답글

    윤부장님!! 지적인 카리스마 최고~ 세미나 하실 때 꼭 챙겨듣습니다~~

박재호의 IT 이야기| 소프트웨어 개발과 창의력 vol.1 창의력의 본질

 

 

 

 

 

소프트웨어 개발에 창의력이 필요하다는 가정은 거부하기 어려울 것이다. 한번 설계가 끝나고 대량 생산에 들어가는 하드웨어와는 달리 소프트웨어는 요구 사항이 계속해서 변경되는 경향이 있으며 이를 충족하기 위해 사고의 전환이 필요하다. 따라서 소프트웨어 개발을 창의력과 연결시키려는 시도는 자연스럽다. 하지만, 창의력이 무엇인지에 대해 충분히 고민하지 않은 상태에서 무조건적인 자유와 신기술을 소프트웨어 개발의 핵심으로 놓기에는 미심쩍은 구석이 있다. 오늘은 소프트웨어와 연결된 창의력의 본질에 대해 탐험해보자.

 

위키피디아에 따르면 창의력은 독창적이고 가치가 있는 뭔가를 만들어내는 작업과 관련이 있으며, 다음과 같은 특성을 보인다.

 

“문제, 결함, 지식 사이의 간극, 빠진 구성 요소, 부조화 등에 촉각을 곤두 세우며, 어려움을 파악하고, 해법을 찾고, 생각하고, 결함에 대해 가설을 세우고 이런 가설을 다시 실험하고 가능한 경우 변경하고 다시 테스트하는 과정을 거쳐 최종적으로 결과를 알리는 과정이다.”

 

백지에서 출발해 전혀 없는 새로운 물건/사상/개념을 만들어 낸다는 일반적인 상식과 달리 창의력의 특성은 흔히 과학에서 사용하는 ‘가설, 실험, 검증’ 또는 ‘문제 풀이’와 유사하다. 소프트웨어 개발의 목표 중 하나가 바로 고객의 문제 해결이라는 사실을 떠올려보면 연결고리를 찾아낼 수 있다. 따라서, 문제 풀이를 쉽게 만들어주는 여러 가지 프로세스와 도구는 가설, 실험, 검증, 문제 풀이를 위한 수단이며 이를 체계적으로 다룰 수 있는 사람만이 창의력을 발휘할 수 있게 된다. 하지만 창의력을 발휘하기 위해 이렇게 체계적으로 접근해야 한다면 자유를 제한하므로 새로운 뭔가를 추구하는 창의력의 본질이 훼손될지 모른다는 걱정이 들기 시작할 것이다. 설상가상으로 다음과 같은 더 큰 문제가 하나 존재한다.

 

1. 창의력은 기존에 없는 새로운 뭔가를 만들어야 한다.
2. 새로움을 추구하기 위해서는 기존에 존재하는 사항에 대해 잘 알고 있어야 한다.

 

 

1번과 2번의 충돌 또는 모순은 창의력을 발휘하려면 완전한 무에서 시작하는 대신에 어느 정도 기반을 다진 결여의 무에서 시작해야 한다는 사실을 암시한다. 이는 독창성을 강조하는 창의력에 대한 본질을 다시 한번 고민하게 만든다.

 

그렇다면 이런 모순을 어떻게 해소해야 할까? 자니 그로엔이 1990년에 발표한 논문인 ‘호기심이라는 규율’에 제시한 설명을 소개한다.

 

“과학은 단순한 호기심과 창의력이 아니다. 호기심과 창의력을 통제한 형태가 과학이다. … 과학적인 진보를 끌어내는 원동력은 호기심과 규율이라는 기묘한 단짝이다. 끊임없이 ‘왜?’와 ‘어떻게?’를 묻는 호기심과, 과학을 현실로 묶어주는 체계 말이다.”

 

소프트웨어 부문에서도 마찬가지일 것이다. 무조건적인 방법론과 엄격한 관리 체계가 해답은 아니지만 창의력을 빙자한 무질서 역시 해답은 아니다. 소프트웨어 공학도라면 누구나 과학적인 사고 방식으로 고객의 어려움을 해결하기 위한 문제 풀이에 집중해야 마땅하며, 이런 과정에서 사물에 대한 크나큰 호기심과 과거 경험을 토대로 정립된 규율이라는 단짝을 함께 포용해야 한다.

 

하지만 주의 사항이 하나 있다. 여기서 말하는 규율은 상명하복을 무조건적으로 따르는 중앙집중적인 통제가 아니라 개발자들의 자발적인 관리 체계에 가깝다는 사실을 짚고 넘어가겠다. 특히 두뇌 활동을 기반으로 움직이는 조직에서는 자율과 규율이 조화를 이뤄야 제대로 된 ‘창의력’이 발현될 것이다.

 

창의력이 그렇게 쉬운 단어가 아님을 인식했는가? 다음에는 조금 더 구체화해 소프트웨어 설계 과정에서 발현되는 창의력에 대해 살펴보기로 하겠다.

 

 

 

 

 

저작자 표시
신고
  • 지나가다 2016.02.24 13:15 신고 ADDR 수정/삭제 답글

    박상무님의 문필력은 정말 대단하세요~!! 엑셈에서 박상무님의 글 자주 봤으면 좋겠습니다.

  • 나우리너 2016.03.04 13:17 신고 ADDR 수정/삭제 답글

    많은 생각을 하게 합니다.내용 너무 좋습니다.

  • 와룡선생님 2017.02.22 12:30 신고 ADDR 수정/삭제 답글

    창의력을 갈구하는 제게 큰 교훈이 되어 감사의 말씀 올립니다.
    글을 다 읽고 느낀점이라곤 무엇보다도 이러한 글들을 많이 읽고 싶다는 욕구가 강해 졌다는점 입니다.
    앞으로 많은 기고 간절히 부탁드립니다.

[기술기고/인터맥스] 트랜잭션 관리 " Comprehensive visibility of transaction! "

 


# 트랜잭션 관리란?

프로파일링과 call tree에 이어 이번에는 트랜잭션 관리에 대해서 알아 보고자 한다. 트랜잭션 이란 하나의 완결된 요청 처리로서 사용자의 처리요청이 여러 구성요소 및 절차를 거쳐 완료 되는 것이다. 절차 및 구성요소에 대해서 모두 처리 되거나 모두 안되거나 두 가지 경우 밖에는 없다.

일반적으로 시장에 나와 있는 APM툴은 트랜잭션 관리와 관련해서 세가지 정도로 구분 해 볼 수 있다. 트랜잭션에 대해서 WAS쪽에서의 처리만을 관리 하는 툴, 데이터 베이스 처리 상황을 보여 주는 툴, 그리고 WAS와 DB를 동시에 관리하지만 트랜잭션을 보는 시야(visibility)가 단절된 상태로 보여주는 툴들로 구분 할 수 있을 것 같다.

트랜잭션이란 관점에서 보면 WAS와 데이터베이스를 모두 거치는 한 개 단위이므로 APM툴은 트랜잭션이 흘러 가는 구간을 전부 관리 할 수 있어야 한다. 좀 더 구체적으로 보면 HTTP Request, servlet processing, database call 이 주요 트랜잭션 구성 단계로 만일 이런 요소들이 개별 모니터링 된다면 문제 분석 시에 추가적인 노력이 더 필요하게 될 수 밖에 없다.

연구 자료에 의하면 성능문제 해결을 위해서 소요되는 시간의 약80%가 문제지점을 파악하는 데 사용된다고 한다. 그렇다면 툴은 이 시간을 줄일 수 있도록 관련 정보를 즉시 제공 할 수 있어야 한다.



 


<Flow of Transaction>



# 트랜잭션 관리를 위해서는 어떤 정보가 필요할까?

일반적인 경우 was에서 실행 되는 servlet에서는 1개 이상의 database call이 있다. 즉 사용자 요청에 의해서 실행 되는 servlet과 여기에서 요청 하는 database call이 하나의 트랜잭션으로 보여 지는 것이 기본적으로 필요하다.
사용자 요청(트랜잭션이름) + 실행중인 class method + 데이터 베이스 요청(sql실행) + target database + database의 sql 실행 상태, 이런 정보가 항상 동시에 보여 질 수 있어야 detection, alerting, correction의 관리 작업을 원활하게 할 수 있지 않을까 한다.

이런 정보를 바탕으로 관리요소가 was에 있을 경우 was에서 수집된 프로파일데이타,call tree를 활용한 분석으로 진행 되고 데이터베이스에 있을 경우 수집된 세션, sql, 각종 통계정보를 바탕으로 sql 튜닝 등을 진행 해야 한다.

수집되는 정보들은 기본적으로
트랜잭션이름, class method, sql , target database, 데이터베이스 처리 상태가 항상 동시에 보이고,
프로파일링 정보, call tree등이 항상 수집되고,
데이터베이스의 세션, 통계정보, sql 등이 항상 수집 되어야 한다.

이를 바탕으로 was-> 트랜잭션 -> call tree -> java source 로 트랜잭션 분석이 진행 되거나, db-> 세션 -> sql 처럼 데이터베이스 분석을 진행 할 수 있다.

이상 위에서 언급된 내용을 요약하자면, APM툴이 반드시 제공해야 하는 기능은 바로
Comprehensive visibility of transaction!


# InterMax 의 트랜잭션 관리

이제 이를 구체적으로 구현한 InterMax의 화면을 통해서 실제 사용 예를 간단히 보자.
TOP DOWN방식 접근법을 적용한 InterMax에서 상위의 tier들을 함께 보여주는 화면이 아래에 있다. 여기서는 web server, was, database의 개별 요소들의 전체적인 상태를 한 눈에 볼 수 있게 배치 되어 있다.
 

 



예를 들어 실행 되는 트랜잭션이 갑자기 증가하면서 대기 상황이 WAS쪽에서 보일 때 DB쪽에서 LOCK이 발생한 것이 보인다면 원인이 DB쪽임을 즉시 파악 할 수 있을 것이고 DB쪽에서 LOCK을 해소 하면 장애상황도 따라서 해결 될 것이다.

아래는 LOCK으로 인한 트랜잭션 증가 현상을 캡쳐한 화면으로 TREE구조로 LOCK상황을 볼 수 있어 즉시 LOCK HOLDER에 대한 정보를 파악 할 수 있다.

 



 화면 아래에 있는 것이 현재 실행 중인 트랜잭션의 목록이다. 여기서 특징적으로 보이는 점은 바로 트랜잭션, CLASS METHOD, DB INSTANCE, DB SID, SQL TEXT, DB SESSION WAIT 정보가 동시에 표현 된다는 점이다.
이 화면 만으로도 문제 상황에서 WAS쪽인지 DB쪽인지 해당 원인을 기본적으로 파악 할 수 있어 문제 구간을 찾기 위해 관련 담당자들이 모이는 등의 시간을 상당히 줄일 수 있다.

TOP LEVEL 모니터링에서 WAS와 데이터베이스가 동시에 모니터링 되고 트랜잭션은 WAS에서 실행 상태와 데이터베이스에서 SQL 실행 상태가 연결되어 하나의 뷰로 모니터링 된다면 트랜잭션관리라는 목표를 쉽게 달성 할 수 있을 것이다.


 




기고:   박 락 빈  (주) 엑셈 부사장
저작자 표시
신고

[기술기고/인터맥스] 애플리케이션 성능관리의 절대 기준 – 사용자 응답 시간

 



초당 처리 건수(TPS), 일 방문자수 그리고 테스트 툴을 통한 트랜잭션 응답시간등 일반적으로 IT부서에서 사용하는 성능지표들은 실제 애플리케이션 사용자에게는 의미가 없다. 사용자들에게는 자신들이 직접 경험하는 애플리케이션의 빠름/느림이 의미 있을 뿐이다.

물론 사용자들이 받아들일만한 응답시간이 무엇인지에 대해서는 객관적인 기준을 정하기가 쉽지 않지만 성능관리 측면에서는 최소한 사용자 응답시간을 수집/관리 해야 하고 APM툴에서 반드시 제공해야 하는 기능이어야만 한다. 사용자가 불만을 표시하기 전에 대응 할 수 있도록 APM툴에서 도와 줄 수 있어야 한다.

웹 페이지에서 정보를 판단하고 데이터 입력 등 에 사용자가 들이는 시간을 수집 하는 것도 필요하지만 이 부분은 객관적인 방법으로 데이터 수집이 상당히 복잡하고 어려우므로 현실적으로 수집 가능하고 애플리케이션 운영관리자에게 중요한 사용자 응답시간에 대해서만 언급하고자 한다.
 

일반적으로 사용 되는 응답시간 수집 방법

포트 미러링( sniffer ) – 애플리케이션에 부하를 주지 않고도 대부분의 트랜잭션에 대해 응답시간을 측정 할 수 있지만, 실제 클라이언트의 로딩시간( 즉 실제 사용자가 체험하는 응답시간)을 측정 할 수 없고, 포로토콜이 암호화 된 경우 측정이 쉽지 않다. 또한 복잡하게 frameset으로 구성된 경우, ActiveX 같은 경우 측정에 어려움이 있다.

Agent 방식 – 클라이언트 PC에 설치 되어 수집 하므로 PC의 상태 즉 CPU, 메모리, 디스크 등의 성능도 수집 가능 하고 무엇 보다 실제 사용자의 응답시간을 수집 할 수 있다. 단점은 Agent설치및 관리가 쉽지 않고, 모든 PC에 설치 할 수 없고 또한 ActiveX 같은 경우 수집이 어렵다.

로드 테스트 툴 – 동시 실행 등의 테스팅에는 좋으나, 스크립트 생성 및 관리에 전문적인 능력필요 하고 dynamic web content에 대한 처리가 어렵고, 무엇보다 실제 사용자의 응답시간이 아니다.

툴(GUI Robot Tool) – 사전에 정해진 임의의 트랜잭션들을 특정 시간 마다 자동으로 실행 해서 트랜잭션 응답시간을 측정한다. 실제 사용자의 응답시간을 측정 할 수 있다는 장점이 있는 반면 모든 트랜잭션에 대해서 수집 불가하고 샘플링 이므로 다양한 상황 대응이 안 되는 단점이 있다.  또한 외부 망에 있는 사용자의 응답시간 측정에 한계가 있어 시스템 접근 암호가 같이 배포 되어야 하므로 배포와 유지 관리에 비용이 발생한다. 
 

사이트에서 사용자 응답시간을 모니터링 하지 않는 이유

대부분의 사이트에서 실제 사용자 응답시간의 중요성을 알고 있지만, 실제 구축해서 사용하는 경우가 많지 않은 것은 주로 아래와 같은 이유들 때문이다.

- 위에 언급한 어떠한 경우 던지 구축에 시간이 많이 들고 또한 전문가의 도움이 필요하며 유지 관리 또한 복잡하고 어려움이 많다
- 대부분의 응답시간 측정 툴들이 point solution으로 공급 되므로 실제 문제 분석을 위한 다른 툴과의 연계가 쉽지  않고 추가적인 구축 작업이 필요하다.
- 수집되는 데이터가 가능한 모든 경우의 (상시)응답시간이 아닌 부분적이거나 또는 경우에 따라서는 실제 응답시간과 차이가 있을 수 있다.


InterMax의 사용자 응답시간 측정

InterMax에서는 위에 언급한 방식의 단점들을 극복하여 특허 등록된 새로운 방식으로 접근 하였다. 이를 통해 클라이언트에 설치 관리의 부하가 없으면서 화면 rendering시간이 포함된 실제 사용자 응답시간을 수집 하고 있으며 또한 ActiveX에 대해서도 수집할 수 있는 방법을 제공 하고 있다.

사용자 응답시간을 수집하기 위해 추가적인 설치가 없이 한 번의 InterMax 설치로 제공되는 기능이므로 APM관리자가 추가적으로 관리해야 하는 부담이 없다.

InterMax에서 수집하는 응답시간은 아래와 같은 구간별 구조를 가진다. 

 


**참고로 TP에 해당 하는 Tuxedo 모니터링의 경우는 다음 버전에서 제공될 예정 이다.


이를 통해서 InterMax에서는 실제 Client의 IP와 함께 트랜잭션별 실제 사용자 응답시간을 수집하여 APM관리자가 이를 통해 응답시간 저하와 관련된 대응을 할 수 있게 하였다. 이 데이터는 당연히 InterMax에서 수집되는 다른 성능 분석 데이터 즉 트랜잭션, SQL, Call Tree등 과 자연스럽게 연계 되므로 Point Solution의 경우처럼 복잡한 구축과 분석과정이 없어 가볍고 빠르게 APM관리자가 대응 할 수 있게 된다.

아래는 InterMax에서 기본 제공하는 Client Response Time화면으로 이를 통해, Client IP, 트랜잭션명, 응답시간, WAS 처리 시간, DB 처리 시간 등을 한 눈에 파악 할 수 있다.


 








기고:   박 락 빈
  (주) 엑셈 부사장  

저작자 표시
신고

[기술기고/인터맥스] 통합된 알람 관리

 


통합 알람 (alarm)

 APM툴에서 제공되는 핵심적인 기능중의 하나는 실시간으로 발생하는 각종 알람에 대한 설정 기능이 될 것이다. 문제가 되거나 알고 있어야 되는 EVENT에 대한 정의를 등록 하고 발생된 알람이 관련 담당자에게 즉시 통보 되는 시스템은 모든 사이트에서 필수적으로 요구 되는 기능인데, 현실적인 문제는 각각의 툴에서 독자적인 알람을 관리하고 단지 알람의 발생 사실만을 통보하는 방식으로 구축 되어 있다는 점이다.

 일반적으로 관리자가 데이터베이스 또는 WAS등의 각각의 시스템에서 알람 설정을 하고, 알람이 발생하면 사이트의 SMS툴로 전송되어 담당자들에게 통보 되는 방식을 주로 사용 한다. 이 방식의 단점은 WAS담당자 또는 DB담당자에게 알람의 원인을 규명하기 위해서 필요한 모든 정보를 가지고 있지 않은 경우가 있다는 점이다.
 

 




 예를 들어서 WAS담당자에게 Connection Pool이 부족하다는 알람이 오는 경우 원인을 분석하기 위해서는 데이터 베이스 쪽 정보도 같이 있어야 완전한 분석이 가능해 진다. Was쪽 connection pool부족이 db에서 발생된 문제 때문인지를 파악 해야 하기 때문이다. 즉 DB의 active session의 수 와 lock 대기중인 세션의 수 등에 대한 정보가 필요하다. DB에서 계속해서 세션이 묶여 있는 경우( 일을 하거나 대기 중이거나 어떤 경우라도 ) 해당 세션은 다른 트랜잭션에서 사용 할 수 없게 되고 따라서 Connection Pool부족 문제를 발생 하게 된다.

따라서 WAS 쪽 Connection pool의 수를 참조 해서 DB쪽 Active session에 대한 알람 설정이 필요하고 lock 대기에 대한 알람 설정도 마찬가지다.

또 다른 예로는 트랜잭션 elapse time에 대한 알람 설정은 sql elapse time에 대한 모니터링 기준으로 작용 하게 된다.

인터맥스의 통합 알람 구현

WAS또는 DB담당자 상호간의 원활한 협업과 투명한 정보공유를 위해서는 동일한 하나의 작업환경 하에서 동일한 방식 또는 뷰를 사용하면서 협업을 위한 분석 데이터가 충분하게 제공 되는 툴이 필수가 된다. 이는 제대로 된 APM툴이 제공해야 할 환경이 된다. WAS따로 DB따로 되어 있다면 협업을 하기 위한 정보의 투명한 제공에 추가적인 노력과 시간이 필요하게 된다. 애플리케이션이 WAS와 DB를 포괄 하는 것처럼 이를 모니터링 하는 APM툴은 당연히 WAS와 DB에 대한 모니터링 관리 기능을 함께 제공 해야 한다.

InterMax는 기존의 was 모니터링 툴보다 향상된 기능을 제공한다. 국산 툴 중에서 최초로 was와 db에 대한 실시간 모니터링 및 사후 분석기능을 통합하여 제공 한다. 따라서 알람 관리도 was와 DB에 대해서 통합적으로 제공 된다.
 
InterMax에서 제공 되는 통합 알람 기능 중 중요한 기능은 아래와 같다.
- WAS, OS, 데이터베이스(오라클,DB2)에 대한 충분한 알람 설정 기능
- 달력기능 제공
- 알람의 복사 기능

제공 되는 기능은 아래의 화면을 통해서 볼 수 있다.

 


 위 화면에서는 WAS와 DB 에 대한 알람 설정 화면으로, WAS 그룹에 대한 알람 설정과 이를 상속받아서 개별 WAS별로 알람을 설정 할 수 있다.  DB 도 마찬가리고 그룹으로 알람을 설정하고, 개별 DB 에 대한 알람은 그룹설정에서 상속받아 별도로 설정할 수 있다. 
 

 


 위 화면은 달력기능으로 알람 설정을 위한 특정 일자와 시간대를 지정해서 SCHEDULE을 등록 하는 기능으로 WORKING/NON-WORKING으로 구분해서 시스템작업등이 있을 경우 불필요하게 알람이 발생 하는 것을 막을 수도 있다. 


 



기고:   박 락 빈  (주) 엑셈 부사장



저작자 표시
신고


티스토리 툴바