“과거는 잊어라” 소프트웨어 개발의 본질을 바꾸는 21가지 기술
아주 오래 전에 개발자들은 빠르고 가벼운 어셈블리 언어로 개발했다. 코드를 입력하기 위해 기계 전면의 스위치를 조작해 줄 사람을 고용할 수 있을 정도로 예산이 많은 적도 있었고, 상황이 좋지 않을 때는 개발자가 직접 그 일을 했다. 복잡할 것이 전혀 없었다. 당시의 소프트웨어는 메모리에서 데이터를 읽어 들여 약간의 연산을 한 뒤 결과물을 내놓는 것이 전부였다.
오늘날의 개발자는 전 세계 출신의 다양한 언어를 구사하는, 무엇보다 제각기 다른 버전의 컴파일러를 사용하는 팀원들과 함께 일해야만 한다. 게다가 어떤 코드는 새로 개발된 것이고, 어떤 코드는 소스 코드가 제공되지 않는, 10년도 넘은 라이브러리를 활용한 것일 수도 있다. 오늘날 개발자가 되기 위해서는 협동심과 인내력부터 키워야 한다.
불과 5년 전과 비교하더라도 컴퓨터에 작업을 지시하는 것에는 대단한 차이가 있다. 지난 10년 동안 영화 ‘올드보이’의 오대수처럼 어딘가에 납치됐다 풀려난 개발자가 있다면, 오늘날의 컴퓨팅 세계에서 아무것도 할 수 없을지도 모른다. 모든 것이 그 어느 때보다 빠르게 변하고 있다.
프로그래밍의 본성을 바꾸어 놓는 21가지 기술을 살펴본다. 이 기술들로 인해 개발자의 협업 방식, 고객 지원 방식, 코딩 방식이 바뀌고 있다. 개발자라면 정신을 바짝 차리기 바란다.
지속적인 통합(Continuous Integration)
과거에는 리포지토리(Repository)에 코드를 커밋하고 나면 보통 커피를 마시며 한숨 돌리거나 점심을 먹을 여유가 있었다. 하지만 더 이상은 아니다. 오늘날의 리포지토리는 지속적인 빌드 시스템과 밀접하게 연결되어 있기 때문이다. 지속적인 빌드 시스템은 코드를 다시 컴파일하고, 아키텍처를 검사하고, 코드에 수백 가지 테스트를 수행해 오류의 가능성을 표시해 준다. 이 때문에 개발자는 지속적인 빌드 시스템이 보내는 작업 수정 요청 메일과 문자 메시지 때문에 책상에서 한치도 벗어나기 어렵다. 지속적인 빌드 시스템은 개발자에게 늘 새로운 일거리를 던져 준다.
더 똑똑한 언어
초창기의 컴퓨터 언어는 컴퓨터를 사용해 어떤 일을 쉽게 하기 위한 목적으로 고안됐다. 최신 언어의 초점은 정상적인 작업 이외의 다른 일은 하기 어렵거나 거의 불가능하도록 하는 데 있다. 프로그래밍 커뮤니티는 오랜 시간에 걸쳐 사람들이 어떻게 실수를 해서 프로그램을 망치는지를 학습했다. 그렇게 해서 나쁜 습관 목록을 작성했고, 이제 몇몇 언어 설계자들은 아예 가드레일을 치고 구속복을 입혀가며 프로그래머들이 널 포인터 역참조 또는 경합 조건과 같은 과거 세대의 실수를 반복하지 않도록 하기 위해 애쓰고 있다.
예를 들어 러스트(Rust)에는 변하지 않는 변수 클래스가 있다. 변할 수 없는 변수라니 이상하게 들리겠지만, 경합 조건을 차단하고 코드 실행 속도를 더 빠르게 하기 위한 유일한 방법이다. 이와 같은 수백 가지의 혁신 덕분에 프로그래머들은 더 좋은 코드를 작성할 수 있다.
물론 이러한 제약은 완벽하지 않으며, 나쁜 습관을 반사적으로 피해가는 유능한 프로그래머에게는 오히려 성가신 요소가 되기도 한다. 그러나 많은 프로그래머들이 새로운 언어들의 엄격한 규율과 부가적인 구조를 반갑게 받아들이는 중이다.
더 좋은 데이터베이스
최초의 데이터베이스는 기적이었다. 데이터베이스가 정보를 큰 테이블에 집어넣는 표준 방법을 제공한 덕분에 전 세계 프로그래머들은 오래 전부터 시달리던 힘든 작업에서 벗어날 수 있었다. 오늘날의 데이터베이스는 그 외에도 소셜 네트워크 유지 관리, 위치 추적, 이미지 저장 등의 많은 부하를 짊어진다. 이러한 모든 작업을 하면서 서로 다른 대륙에 위치하기도 하는 시스템 클러스터 전반으로 부하를 분산시킨다.
관심이 폭증하면서 프로그래머들은 다양한 틈새 수요를 충족하는 수십 가지 데이터베이스를 만들었다. 초고속으로 대답이 필요하며, 데이터에 미세한 비일관성이 발생하는 정도는 신경 쓰지 않는다면? 트랜잭션을 사용하지 않는 메모리 내 데이터베이스를 사용하면 된다. 절대적으로 귀중한 데이터라서 손실되는 일이 없어야 한다면? 서로 다른 시간대 또는 서로 다른 반구에 위치한 데이터센터로 정보를 자동으로 복제하는 데이터베이스를 사용하면 된다. 수십 가지 옵션이 있고, 한 가지 제품에서도 구성 파일을 조금 손보는 방법으로 다양한 요구 사항에 대처할 수 있다.
프레임워크(Framework)
근래에는 다른 사람의 작업물을 활용하지 않고 온전히 자신의 힘으로만 프로그램 전체를 개발하는 경우는 드물다. 대신 적당한 프레임워크(Framework)를 선택한 다음 API를 조사하고, 원하는 기능에 부합하지만, 서로 호환되지 않는 일부 API를 연결하기 위한 접합 코드를 개발하는 방식을 선호한다. 이제 누구도 HTML이나 CSS로 웹 페이지를 개발하지 않는다. Ext JS나 ExpressJS 혹은 기반이 되는 코드 컬렉션을 이용한다.
물론, 모든 것을 처음부터 만드는 개척자가 될 수도 있지만, 이는 자살 행위나 다름없다. 다른 사람들이 이미 완성해 놓은 것을 모두 다 처음부터 만들 수는 없는 노릇이다. 개발자는 ‘장인’이 아닌, ‘프레임워크를 조작하는 사람’임을 명심해야 한다. 만약 직접 코드를 개발할 생각을 하고 있다면 당장 멈추고 이미 개발된 프레임워크를 찾아보길 바란다.
라이브러리(Library)
루틴(Routine)의 집합소인 라이브러리는 프레임워크의 사촌 격으로, 거의 모든 곳에서 사용되고 있어 이제 라이브러리 없이는 개발이 어려울 정도다. 과연 jQuery 없이 브라우저를 위한 코드 개발이 가능할까? GetElementByID라는 함수가 있다는 것을 기억하는 사람이 있기나 할까? 물론, ‘No’다. 오늘날에는 jQuery 같은 라이브러리가 소프트웨어 스택 전체를 지배하고 있다.
사람들은 자신이 좋아하는 언어에 대해서는 잘 이야기하면서도 어떻게 개발하는지는 좀처럼 이야기하지 않는다. 따라서 개발자를 고용할 때는 라이브러리 지식에 관해 물어볼 필요가 있다. 자바스크립트 개발자라면 jQuery, 아니면 Dojo 쪽인지, 게임 개발자라면 C++보다는 Allegro나 Unity, Corona 등에 대해 알고 있는지를 물어야 한다. 라이브러리에 대한 지식은 언어를 잘 아는 것만큼 중요하다.
Node.js와 자바스크립트
과거의 웹 서버는 정적인 HTML을 서비스하는 역할을 했는데, 그 이후 데이터베이스와 상호작용할 수 있는 동적인 웹 서버를 만드는 방법이 고안됐다. 모든 개발팀에서는 데이터베이스를 프로그래밍할 수 있는 SQL 전문가와 서버 코드를 개발할 수 있는 PHP 혹은 자바 개발자, HTML 템플릿을 디자인할 수 있는 디자이너를 한 명씩 고용했다. 클라이언트 쪽에서 실행되는 AJAX와 자바스크립트가 유행하자 이런 언어를 다룰 줄 아는 개발자가 추가됐다.
지금은 모든 것이 자바스크립트로 되어 있다. 브라우저는 물론이고, 서버(Node.js)와 데이터베이스(MongoDB, CouchDB) 계층도 마찬가지다. 클라이언트 쪽에서 HTML을 생성해 주는 jQueryMobile이나 EXT JS 같은 프레임워크에서는 종종 HTML까지도 자바스크립트코드로 되어 있다.
트랜스파일러(Transpiler)
프로그래머도 인간인지라 선호하는 언어도 저마다 다르다. 누구는 A라는 언어를 선호하고, 누구는 A를 기피하고 B나 C 또는 D를 선호한다. 사용할 언어를 결정하는 데 걸리는 시간이 작업 시간보다 많을 지경이다. 많은 현대 프로그래밍 언어의 장점은 자동으로 다른 프로그램 언어로 재작성하는 기능이다.
“트랜스파일러” 또는 “크로스 컴파일러”는 특정 언어로 작성된 프로그램의 기본 구조를 뽑아내서 다른 언어에서 실행되도록 변환한다. 완벽하지 못한 경우도 있고 프로그래머의 기발한 트릭이나 이디엄을 제대로 포착하지 못하는 경우도 있지만 최적화할 수 있는 부분을 인식하는 기능 덕분에 가끔은 원본보다 오히려 더 나은 결과물을 내줄 때도 있다.
트랜스파일러의 가장 큰 목표 언어 중 하나는 모든 브라우저의 국제 공통어 자바스크립트다. C++에서 파이썬까지 어느 언어든 변환기에 집어넣으면 모든 웹페이지에서 이미지 및 텍스트와 함께 나란히 실행되는 자바스크립트로 바꿔준다. 커피스크립트(CoffeeScript)와 타입스크립트(TypeScript)가 있으니 자바스크립트 프로그래머도 개선된 자바스크립트를 일반 자바스크립트로 변환할 수 있다.
코드 검토와 스타일 규칙
과거에는 N명의 프로그래머들이 제작한 대규모 프로그램 코드에는 최소 N개의 뚜렷한 스타일이 존재했고, 정신분열적인 프로그래머들로 인해 그보다 더 많은 스타일이 혼재하는 경우도 흔했다. 지금은 각 프로그래머 팀들은 이디엄과 설계 패턴의 일관성을 지켜 코드를 더 알아보기 쉽도록 하기 위해 균일한 스타일을 강제하는 메커니즘을 개발하고 있어 이러한 스타일의 차이도 차츰 옛날 일이 되고 있다.
그러나 균일한 스타일에 순응해야 하는 것이 달갑지 않은 프로그래머도 있다. 재능이 남달리 뛰어난 프로그래머 또는 자기 주장이 강한 프로그래머는 자신의 기량이 억눌린다고 느끼는 경우가 많다. 코드 검토는 때때로 노골적인 대립으로 이어져 팀원들 간 감정적인 상처와 팀 분열로 이어지기도 한다. 최악의 경우 방향성을 상실하여 죽도 밥도 아닌 결과물을 내놓게 된다.
이와 같은 모든 문제점에도 불구하고 관리자들은 이러한 아이디어를 계속해서 도입하고 있다. 프로그래머의 좋지 않은 습관을 차단하고 불완전한 코드를 걸러내는 유일한 방법이기 때문이다. 소수 천재의 창의성을 좌절시키는 결과를 초래하기도 하지만 그 정도는 감수해야 한다.
전처리기와 린팅(Preprocessors and linting)
과거에는 컴파일러가 사용되지 않는 변수를 발견하기라도 하면 재수가 좋다고 느끼곤 했다. 지금은 논리 또는 스타일에서 오류를 잡아내는 코드 전처리 툴이 넘쳐난다. 변수를 선언하지 않았다면? 더 나쁜 경우로, 공백과 탭의 조합을 잘못 사용했다면?
에어비엔비(Airbnb) 소속 팀은 자바스크립트 코드를 위한 스타일 가이드를 공표하면서 인터넷에서 유명세를 탔다. 이 가이드는 유능한 프로그래머는 더하기 기호의 양쪽 모두에 공백을 넣으며, 그 외의 모든 형태는 나쁘다고까지 명시했다. 이처럼 가혹할 만큼의 균일성이 좋은 것일까? 어쩌면 이 규칙을 만든 이들은 사람들이 난감해 하는 모습을 보며 만족스러운 미소를 짓고 있을지도 모른다. 그러나 최소한 이들은 개발자가 자신의 어리석은 실수를 세상에 내보이기 전에 잡아낼 수 있는 도구를 제공한다.
가상머신
오늘날의 코드 대부분은 실리콘 칩이 이해할 수 있게 변환해 주는 가상머신 위에서 실행된다. 자바 가상머신, C#/.Net 가상머신, 그리고 지금은 자바스크립트 엔진이 코드의 주요 대상이다.
가상 머신의 인기는 소프트웨어 스택 전체를 흡수할 만큼 높아졌다. 과거에는 새로운 언어를 만들 때 전처리기에서부터 레지스터 할당기까지 스택 전체를 개발해야 했다. 하지만 오늘날에는 새로운 언어가 기존의 가상머신 위에 위치한다. Clojoure, Scala, Jython, JRuby 등은 오라클의 일부가 된 썬의 위대한 업적에 편승한 언어들이다.
브라우저 세계에서도 비슷한 현상이 나타나고 있다. 물론 자신만의 브라우저와 언어를 개발할 수도 있지만, 자바스크립트로 크로스컴파일할 수 있게 만들 수도 있다. 이는 CoffeeScript 같은 도구에 사용된 방법이기도 하다. 구글은 자바를 자바스크립트로 변환해 주는 GWT(Google Web Toolkit)를 내놓기도 했다.
API
과거 개발자들은 주로 데이터 구조에 대해 고민했다. 모든 정보를 바이트 블록으로 묶고, 바이트를 하나하나 센 다음 어떤 값이 특정 포인터를 기준으로 정확한 거리에 위치하는지를 확인해야 했다. 다행히 지금은 컴파일러가 이와 같은 작업 대부분을 대신해 준다.
오늘날에는 이보다 훨씬 더 정확한 인터페이스인 API로 작업할 수 있다. API는 보통 완전히 다른 디바이스에서 서비스되며, 다른 업체에서 제공하는 서비스를 매 호출 시마다 요금을 지불하고 이용할 수도 있다. 주소와 우편번호를 위도와 경도로 바꾸고 싶을 경우, 비용을 지불한 뒤 원하는 결과를 얻을 수 있는 API를 사용하면 된다.
일반적으로 데이터는 그리 치밀한 구조화가 필요 없다. 바이트의 수를 세는 예전 방식은 JSON이나 XML처럼 파싱이 가능한 데이터 구조로 대체된 지 오래다. 그저 구분 점을 올바른 위치에 찍었는지만 확실히 하면 되며, 이를 처리해 주는 라이브러리도 있다.
새로운 사용자 인터페이스
‘사용자 인터페이스(User Interface)’라는 용어는 한때 명령줄, 또는 클릭 가능한 그림 및 아이콘으로 구성된 GUI, 둘 중 하나를 결정하는 의미로 사용됐다. 지금은 텔레비전도 웹사이트를 열고 모든 전화기에 시리나 코타나 같은 개인 비서가 있는 “스마트”한 시대다. 곧 모든 부엌과 거실에는 누군가 불러 주기를 상시 기다리는 마이크가 존재하게 된다. 텔레파시가 구현될 날이 머지않은 듯이 느껴진다.
다양한 구조와 메타포를 사용하는 새로운 라이브러리와 툴을 익혀야 하는 프로그래머들에게 이런 현상은 모두 과제다. 새로운 영역은 곧 프로그래머가 차용하거나 기반으로 삼을 정립된 방식이 거의 없다는 것을 의미한다. 모든 것을 처음부터 새로 만들어야 한다. 다만 이 새로운 길에서는 프로그래머가 해야 할 작업이 간소화될 수 있다. 사용자가 단순히 온도를 알고 싶어 한다면, 굳이 온전한 앱이나 멋진 사용자 인터페이스를 만들 이유가 없기 때문이다. 그냥 음성으로 숫자를 말해주면 끝이다. 작은 앱 하나를 만들기 위해 몇 기가바이트나 되는 용량의 애플 엑스코드(Xcode)를 오후 내내 다운로드했던 경험이 있는 사람에게 이 단순함은 생소하기까지 하다.
브라우저
과거에는 데스크톱, 서버, 혹은 디바이스에 따라 각각 다른 소프트웨어를 개발했다. 이런 소프트웨어는 사용자와 상호작용하는 나름의 방식을 가지고 있었다. 하지만 지금은 모든 것이 브라우저를 경유한다. 예를 들어, 음악을 저장하기 위한 로컬 파일 서버를 구축할 때 URL로 접속해 웹 사이트에서 작업할 수도 있다. 애플의 데스크톱 위젯 역시 자바스크립트와 HTML로 개발하기 시작한 지 오래며, 많은 크로스 플랫폼 모바일 앱이 아파치 코르도바(Apache Cordova)를 통해 HTML이나 자바스크립트로 개발되고 있다.
물론 기존의 방식을 고집하는 분야도 있다. 예를 들어, 게임 분야에서는 브라우저를 거의 사용하지 않는다. 하지만 스크린 캔버스 객체를 다룰 줄 아는 자바스크립트 개발자가 늘면서 이 분야 역시 변하고 있다. 일례로 앵그리 버드(Angry Birds)는 브라우저에서도 실행할 수 있다.
도커와 컨테이너
과거에는 서버를 구축하는 작업이 쉽지 않았다. 먼저 작업을 완료한 개발자는 소프트웨어를 설치할 서버 팀에 메모를 보낸다. 그러면 서버 팀은 정확한 라이브러리를 받는 경우도 있고 그렇지 않은 경우도 있었지만, 어쨌든 결국에는 서버가 동작하게 했다.
오늘날에는 도커(Docker) 같은 애플리케이션 컨테이너를 이용해 올바른 라이브러리가 모두 포함된 컨테이너를 손쉽게 전달할 수 있다. 테스트 기기에서 잘 동작하는 컨테이너라면 실제 서버에서도 거의 잘 동작한다. 또 모든 것이 묶음으로 제공되기 때문에 데스크톱과 서버 사이의 비호환성 문제도 거의 없다.
데브옵스 도구
과거의 개발자는 소프트웨어를 서버에 일일이 설치했다. 하지만 지금은 수십, 수백, 많게는 수천 대의 서버를 한 번에 대여하는 시대다. 이들 서버는 대부분 요청과 동시에 새로 생성되어야 하고, 최신 소프트웨어도 설치되어 있어야 하므로 사실상 수작업으로는 불가능한 일이다.
셰프(Chef), 퍼핏(Puppet) 같은 서버 관리 툴을 통해 ‘데브옵스(devops)’로 입문하면 된다. 새로운 소프트웨어를 클라우드에 올리기만 하면 이들 툴은 모든 기기에서 같은 코드를 실행하며, 과거에 한 대의 기기에서 수작업으로 했던 일을 자동화해 준다.
구글 앱 엔진(Google App Engine) 같은 서비스는 이런 자동화 과정을 내부적으로 처리하고 있다. 개발자는 자신이 개발한 앱을 던져주기만 하면 된다. 그러면 자동으로 프로비저닝이 일어난다. 내부적으로 어떤 일이 일어나는지 알 필요도 없다. 그저 사용한 CPU 시간만큼 요금만 납부하면 된다.
IaaS
서버의 경우, 클라우드 계층으로 흡수됐다. 이제 새로운 프로젝트를 위한 서버를 구축해 달라고 요청하는 개발자는 거의 없다. 대신 IaaS 사이트에 로그인한 다음 버튼만 누르면 운용할 수 있는 서버를 얻을 수 있다. 과거와 비교하면 훨씬 간단하다.
PaaS
과연 지금도 웹 사이트를 직접 구축하는 사람이 있을까? 아마도 다른 웹 사이트에 계정을 만든 다음 커스터마이징하는 방법을 택할 것이다. 웹 서식에 몇 개의 필드를 채우기만 하면 나머지는 웹 사이트가 다 알아서 해주기 때문이다. 이는 유튜브에 고양이 비디오를 올리거나 이베이에서 페즈(Pez) 디스펜서를 입찰하는 것과 다르지 않다.
물론 여기에는 약간의 과장이 섞여 있다. 현존하는 대다수의 PaaS가 웹 서식에 적절한 값을 채우는 데 개발자의 지식이 필요하다. 일례로, 마이크로소프트 애저의 경우 웹 사이트의 응답 방식을 정의하려면 몇 가지 자바스크립트 함수를 작성해야 한다. 그러면 애저가 이들 함수를 적절한 라이브러리로 랩핑해 Node.js에서 실행시키는 식이다.
플러그인을 판매하는 마켓플레이스
고품질의 그래픽 게임을 개발하기 위해 그래픽 디자이너 또는 개발자를 추가로 고용하거나, 유니티 어셋 스토어(Unity Asset Store) 같은 스토어에서 필요한 플러그인을 모조리 구입할 수도 있다. 유니티 어셋 스토어의 상품 가운데 "모든 규모의 하수구 장면 개발이 가능한 모듈 형태의" 지하 감옥 하수구 타일 키트는 45달러에 판매되고 있기도 하다. 이처럼 저렴한 가격에 그래픽을 구현할 수 있는 상황에서, 개발자나 그래픽 디자이너를 고용하려고 할지 잘 모르겠다.
그 외에도 플러그인이나 확장 모듈, 라이브러리, 다른 부가적인 것들을 판매하는 스토어가 점점 더 많이 생겨나고 있다. 라이브러리나 프레임워크와 마찬가지로 이런 것들도 적절히 잘 구입하면 그만큼 개발 시간과 인력, 비용을 줄일 수 있다.
소셜 미디어 포탈
인터넷 초기에는 웹 사이트를 만든 다음 타인의 방문을 무작정 기다려야만 했으며, 방문자는 해당 웹 사이트의 URL을 기억해야만 했다. 오늘날에는 점점 더 많은 웹이 페이스북이나 세일즈포스 같은 대형 사이트로 흡수되고 있다. 직접 웹 사이트를 구축한다면, 전 세계의 인구가 페이스북이나 세일즈포스를 클릭하는 것을 구경만 해야 할 것이다.
해결책은 당연히 페이스북이나 세일즈포스 앱을 만드는 것이다. 이들 서비스는 어느 정도 플랫폼을 통합할 수 있도록 해줄 것이다. 하지만 플랫폼에 종속될 경우, 언제든지 버림 받을 수 있다는 점을 고려해야 한다. 대형 포털 사이트의 노예가 되거나, 구경만 하거나 둘 가운데 하나를 선택할 수 있는 갈림길에 서 있다.
깃허브와 소셜 코드 공유
오픈소스 시대의 연 것은 코드 공유 사이트라 해도 과언이 아니다. 소스포지 같은 서비스가 있기 전에는 소프트웨어 개발은 ‘혼자’만의 작업일 뿐이었다. 타인의 코드를 보기 위해서는 그들이 기꺼이 코드를 전송해 주기를 마냥 기다려야만 했다.
오늘날, 코드 공유는 일종의 ‘소셜 네트워크’다. 소스포지나 깃허브 같은 사이트는 누구나 모든 코드를 보거나 수정할 수 있게 했다. 더불어 코드를 관리하고, 공유하고, 의논하는 과정이 한 곳에서 이루어질 수 있도록 통합했다. 덕분에 개발자는 하나의 인터페이스를 통해 코드를 보고, 수정을 제안할 수 있다. 불과 일주일 만에 수천, 수만 번 다운로드를 기록하는 프로젝트도 어렵지 않게 찾아볼 수 있다. 하지만 과거에는 절대 불가능한 일이었다.
이제 코드 공유 모델은 소유권이 있는 프로젝트에서도 따르고 있을 정도로 당연한 것이 되었다. 깃허브나 비트버킷(BitBucket) 같은 사이트는 제한된 그룹의 사람들에게만 공유 기능을 제한하는 비공개 코드 저장소를 유료로 제공함으로써 서비스를 유지하고 있다.
성능 모니터링
처음에는 코드의 성능을 추적하기가 수월했다. 코드가 시작될 때의 시간을 출력한 다음 끝날 때 시간을 출력하면 됐다. 좀 더 성실한 개발자는 여기에 시간차를 계산하는 식을 추가하기도 했다.
하지만 이 방법은 더는 쓸 수 없게 됐다. 여러 기기에 걸쳐 많은 문제가 나타나기 때문이다. 과거와 같은 방식의 분석을 적용하더라도, 비정상적인 통신이나 데이터베이스의 지연에 의한 진짜 병목 지점은 찾을 수 없다. 오늘날의 모니터링 도구는 모듈별 성능뿐 아니라 네트워크로 연결된 소프트웨어를 위해 네트워크 호출도 추적한다. 이렇게 해야만 무엇이 정상이고 무엇이 비정상인지 제대로 파악할 수 있다.
원문보기:
http://www.itworld.co.kr/news/105902#csidx8b13929fe904043ac23852adb7b0f7c 
