9장. 바닷속 우주

Part2. 자의식 정착기

by 케이시르

30. 시험

아빠를 잃은 충격은 쉽게 헤어 나올 수가 없다. 무엇을 의지하고 누구를 위해 살아야 하는지 혼란스러움 가운데 출근을 하고 있다. 멍해있는 나에게 고수는 담담하게 대하며 지금 만들어 놓은 프로그램 자동화 테스트를 만들어보자고 한다. 테스트?? 자동화?? 뭐지?? 혼란도 혼란인데 지금 상황까지 혼란스럽다. "테스트를 어떻게 자동화를 한단 말이지?" 일단 시켰으니 하긴 해야 한다. 몸과 맘도 추스르지도 않았는데 이렇게 바로 시키실 줄은 예상하지 못했다. 나는 자리에 앉아 구글링을 하고 있다.

"지금 상황에 누가 누구를 시험할 수 있단 말인가?"

테스트 자동화에는 크게 4가지 방법이 있다. UnitTest, Coded UI Test, Web Performance Test, Load Test 검색해 보니 뭐가 있긴 있다. 하니씩 살펴보자.


1. UnitTest?? 프로그램 함수 단위를 테스트하는 것이다. f(x)라는 함수에 x 값이 들어올 수 있는 모든 케이스에 대하여 정의하고 결과 값이 맞는지 확인하는 테스트이다.

즉 f(x) = 1 + x라고 가정한다면 x에 0을 넣었을 때 Expected Result가 1이 기 때문에 Assert.Equeals(f(0), 1)라고 코딩을 해준다. 그리고 결과가 1이 나오면 Pass, 아니면 Fail로 처리된다. "테스트가 어려운 게 아니네!?"


"그런데 만약 함수 속의 함수 속의 함수가 있으면 어쩌란 말인가??" 물론 각 함수마다 단위 테스트가 클리어하게 되면 문제는 없다. 하지만 함수 사이사이 실행되는 명령도 있으며 무언가 찝찝하다.

일단 UnitTest OK


2. Coded UI Test는 또 뭐지?? 완성된 프로그램에 테스트 방법을 레코딩 시켜놓고 반복실행 시키는 방법이다. 개념은 쉬어 보일 수 있지만 레코딩 된 상태를 계속 유지시킬 수 있는 노하우가 필요하다.


3. Web Performance Test는 웹 응용 프로그램에서 사용되며 한 번에 액션에 대한 Server와의 응답 속도를 테스트할 수 있다. 그리고 Web Performance Test와 연동되어 Load Test를 한다. Web Server에 Traffic Load를 가상으로 증가시켰을 때 응답 속도를 테스트할 수 있다.


테스트 함수들이 모여 자동화를 이루게 되는데, 모든 로직을 자동화하는 것에는 분명 한계가 있다. 테스트 함수들이 모두 실행되면 코드 커버리지를 알 수 있다. 이는 작성된 코드가 테스트 함수에 의해 실행된 코드 라인 수를 전체 라인 수로 나눈 비율이며 80% 이상이면 훌륭한 테스트 코드를 작성했다고 할 수 있다.

내가 시험에 빠지지 않기 위해서 내가 만든 작품을 시험하고 있다.

지금의 나는 힘들 때 글을 쓰기 시작했다. 내가 힘든 상황을 모두 이야기할 수 없으며 또 들어줄 사람조차도 없다. 가만히 있으면 더 시험에 빠지게 되어 나의 글을 시험하기 시작했다. 한두 사람의 격려의 표현은 기쁨이었고 그것이 위로가 된다.

시험에 빠질 것 같다면 자신이 좋아하는 것을 시험해 보는 것도 도움이 되는 것 같다.


31. 바닷속 우주전쟁

인터넷을 통해 웹이라는 도구를 이용하고 있다. 내가 필요한 정보를 얻기 위해 가장 편리한 수단이다. 인터넷이 되는 단말기라면 어디서든지 이용이 가능하기 때문이다. 이러한 장점에도 불구하고 기술적인 제약이 많다.

원하는 정보를 얻기 위해서는 내가 알 수 없는 위치에 있는 서버에 갔다 와야 한다. 이 비용과 시간은 사용자에게 매우 불편한 것은 사실이다. 그럼에도 목마른 사람이 우물을 파듯이 느리고 답답하지만 이용할 뿐이다.


빠르고 강력한 기능의 클라이언트 응용프로그램과 느리고 기능적으로 제약적이지만 편리한 웹 응용프로그램은 과도기를 지나고 있다. 어떤 방향이 지금은 모르겠지만 분명한 것은 웹은 바닷속에서 천천히 우주를 형성하고 있었다.

Windows95로 디지털 시장을 평정했던 MS는 아이폰3G와 웹 시장과 치열한 싸움을 해야 했다. 사용자에게 "공짜"와 "편리함"을 이길 장사는 없다.

Microsoft사는 자신들의 제품을 강제화 하기 위하여 웹에서는 구현 안 되는 기능을 강조하면서 ActiveX라는 응용프로그램의 양산을 유도했다. 그렇게 MS Internet Explorer를 강제화 하려는 과한 액션들은 사용자들에게 불편함과 강한 거부감을 일으키게 된다.
그것을 인식한 Microsoft는 SilverLight라는 웹 전용 강력한 클라이언트 기술을 선보였지만 사용자에게 한 번이라도 추가적인 액션을 강요하는 것이 불편하다는 인식은 여전하다.

이런 시점에 Google에 Chrome은 ActiveX를 과감하게 배제하면서 빠르고 최적화된 웹 환경을 제공하였다. 물론 제한적인 웹서비스를 해야 했지만 부드럽게 작동하는 웹 환경에 환호를 하며 흐름을 웹 시장으로 만들어 가고 있다.
실버라이트 로고는 신비로움을 주는 디자인이라고 생각한다.


32. OOPs I did it again...

테스트 코드를 만들다 보니 불편한 코드들이 많이 발견된다. C언어에서 C++ 이 만들어진 것은 코드의 효율성을 높이기 위하여 객체지향 프로그래밍(Object Oriented Programming)이라는 기법이 나오게 된다. 객체 지향의 의미는 현실세계를 이루는 방식처럼 작은 단위로 객체를 생성하여 속성과 행동을 부여하여 객체 단위로 상호작용 할 수 있도록 만드는 것이다.


게임 프로그래밍을 한다면 비교적 현실적이어서 캐릭터, 아이템, 환경을 객체로 모델링하여 행동과 속성을 적절하게 명명할 수 있다. 하지만 일반 비즈니스 프로그래밍에서는 업무 로직 및 데이터 처리가 중심이기 때문에 적절하게 객체의 행동 속성을 부여하기 어려울 수 있다. 그럼에도 C++ 이후에 나온 언어들은 객체 지향 프로그래밍을 강조하고 있다.


객체 지향 프로그래밍을 가르칠 때 이해를 돕기 위해 현실 세계에 있는 온갖 것들을 가지고 비유를 한다. 하지만 내가 프로그래밍하는 곳에는 그런 것들이 하나도 없다. 그렇기 때문에 현실 세계와 맞지 않은 프로그램에서는 객체 지향 프로그래밍을 하는데 러닝 커브가 되었다. 다시 한번 객체지향 이야기라는 책을 천천히 읽어보고 있다. "객체 지향..." "현실 세계..." "객체 현실..."


세상은 신이 아름답고 조화롭게 만든 것이 현실 세계이다. 모든 객체의 이름을 직접 부여했고 서로 다른 속성과 행동은 서로 상호작용하게 만들었다.

"맞다." 내가 만들고 있는 프로그램의 신은 나다. 신이라면 세상을 아름답게 만들어야 할 의무가 있다고 생각한다. 만약 내가 객체를 만들 때 하나하나 이름과 역할을 만들었다면, 그 객체 간의 교제할 수 있도록 만들었다면, 그리고 권한을 많이 부여한 객체에는 더 많은 책임과 의무를 가지게 했다면 객체지향 프로그래밍을 하고 있는 것이다.

아직까지도 웹 응용프로그램에서는 객체 지향 프로그래밍에 대하여 냉소적인 반응이다. 데이터 처리와 업무 로직에 중점을 두는 설계를 많이 하고 있다.

프로그램의 사이즈는 계속 방대해질 수밖에 없으며 데이터 처리에만 집중하게 되면 비효율적인 코드가 양산되는 형태를 피할 수가 없다.

규모가 커져버린 웹 프로그램들은 유지 관리와 확장성을 위해 MSA(Micro Service Achitecture)라는 개념으로 데이터 처리 함수들을 작은 프로그램으로 분산하는 방식을 선택하게 된다.

Micro Service를 하면서 올바른 객체 지향 프로그래밍을 활용할 수 있는지 의문이 든다.
객체는 서로 상호작용 할 수 있도록 설계되어야 하는데 Micro Service 내에서만 상호 작용하는 객체는 큰 의미를 가지지 않는다.

객체 지향 프로그래밍을 마스터한 개발자가 MSA를 하겠다고 말한다면 그럴 수 있다고 생각하겠지만 필드에서 객체지향 프로그래밍을 능숙하게 하는 웹 프로그래머를 본 적이 거의 없다. 그럼에도 MSA를 주장하는 하는 개발자들은 한 번쯤 자신의 코딩 실력에 대하여 고민해 볼 필요가 있다.




퀘스트 보상으로 소프트 스킬 4개, 하드스킬 6개를 획득하셨습니다.

[INVENTROY]

(소프트 스킬)

극복
시험
책임
의무


(하드스킬)

테스트자동화
ActiveX
SilverLight
OOP
Web1.0
Web2.0


THE
LOVEBIT
CODE

사랑과 돈, 그리고
영원의 비밀

[쿠키]
응용 프로그램과 웹의 차이를 알아보자
응용 프로그램은 실행되고 있는 PC 운영체제의 관리를 받으며 실행된다. 관리를 받아야 한다는 의미는 프로그램이 같은 PC에 소유되어 있어야 한다는 의미도 된다. 우리가 이용하고 있는 모든 웹 사이트들이 자신의 단말기에 가지고 있어야 한다면 매우 끔찍한 일이다.

웹 응용프로그램은 우리는 알 수 없는 공간에 기업이 관리하는 운영체제에서 관리되고 실행되는 컴퓨터를 서버라고 부른다. 개인은 Web Browser(Internet Explorer, Chrome, Firefox, Safari)와 같은 응용 프로그램을 통해서 접근이 가능하다. Browser에 입력하는 URL은 서버의 주소와 명령을 담고 있다. URL을 통해 서버에서 필요한 연산을 모두 처리한 후에 Html이라는 Web Browser가 해독할 수 있는 언어로 전달을 해주어 웹에서 보는 화면으로 랜더링 하는 방식이다. 개인은 Web Browser가 있는 곳에 Url만 알고 있으면 어디서든 프로그램을 쉽게 이용할 수 있다.

이 설명을 들으면 당연히 웹 응용프로그램이 압승이다. 하지만 서버에서 실행된다는 의미는 고유 단말기의 기능을 완전하게 사용할 수 없다는 의미도 된다. 프린터/팩스 기기를 다이렉트로 실행시키거나 로컬 파일시스템에 접근하는 것에 제약이 따를 수밖에 없다. 이 문제를 해결하기 위해 우리가 의도하지 않은 응용프로그램들의 설치를 유도하는 것을 알 수 있다.

스마트폰의 유명한 앱들도 마찬가지이다.
하이브리드 앱이라고 부르며 Web Browser를 대신한 껍데기가 앱이고 알맹이는 웹으로 작동하는 것이 대부분이다. 앱에서는 단말기를 직접 접근해야 하는 기능을 담당하고 비즈니스를 담당하는 기능은 서버에서 실행하여 응용프로그램과 웹은 서로 상호작용을 해야 완전한 솔루션이 될 수 있다.


Web1.0
웹은 인터넷 보급과 함께 활성화되었고 이때를 Web1.0의 시기이다.
초기에는 홈페이지라고 부르며 서버에서 제공되는 정보를 단방향으로만 받는 형태이고 간단한 검색이나 게시판 같이 텍스트를 주고받는 형태가 전부였기 때문에 웹과 응용프로그램의 역할이 명확하게 구분되었던 시기이다.

Web2.0
인터넷의 속도와 서버 성능의 발전으로 지금은 웹은 Web2.0의 시대이다. 서버에서 텍스트, 이미지, 동영상까지도 주고받을 수 있는 인터넷 속도가 되었기 때문이다. 이에 따라서 웹의 기술력은 빠르게 발전하게 되어 개인의 주도적인 참여를 유도할 수 있게 되었으며 상당 부분에 응용프로그램이 웹 응용 프로그램은 전환되어가고 있다.
이전 12화8장. 혼돈의 바다