열린 공간, 누가바닷컴

글리치는 어떤 것일까요. 어감상 글리치는 어딘가 긁힌 듯한 느낌을 주곤 합니다. 그리고 셀버그도 알아볼 것입니다.

언뜻보면 두가지가 그래픽이 깨지는 비슷한 유형처럼 보입니다. 물론 게임에서는 그렇게 분류를 하는 경우도 있긴합니다.

(윗분들은 셀버그나 글리치나.. 그냥 깨지는걸로 보이니까요) 셀 버그는 공식적인 용어는 아닙니다. 뭐 여러가지의 업계

용어가 있겠지만 이게 다 다를 수도 있어요. 툴마다 게임엔진마다 게임마다 그리고 성향에 따라 방식에 따라서 말이지요

뭐라고 표현하기가 모호해서 그래픽 오류라고 하기에도 좀 그래서, 비교적 알기 쉽게 풀어서 하나의 그래픽 인터페이스가 

오동작을 일으킨다고 생각하시면 편하실 겁니다.

http://noogabar.com/357

이미 천재모노님께서 쓰신 글리치와 버그의 글은 있으니 참조 하시고 오신다면, 이해가 더 쉬우실 겁니다. 물론 제가 잘못

알고있는 사실도 있을 수 있으니, 지적도 주시면 감사하겠습니다.

1. 글리치

글리치를 정의를 하자면, 많은 설명까지 해야 할 수 있습니다. 글리치는 주로 하드웨어적인 문제가 대부분인 경우가  

많습니다. 원인에 대해서는 아래에서 살펴보기로 하고, 글리치는 하드웨어의 오동작에 의해 생기는 잔상 / 오동작 / 그래픽적인 문제 / 전송 오류 / 노이즈

등을 포함 한다고 할 수 있습니다.

글리치가 왜 일어나는건가?

글리치의 예를 들기 위해 몇가지 예를 들어보겠습니다.

-모바일

> 모바일 글리치는 주로 주파수가 일정치 않거나, 전력 부족 현상, 메모리 누수가 대표적인 예입니다.

피쳐폰 보다도, 스마트 폰에서 매우 많이 나타나곤 합니다. 스마트폰의 경우 피쳐폰 보다도 여러가지 기기가 내장 되어있습니다.

예를 들면 배터리를 중심으로 액정 / 터치 패널 혹은 칩셋 / 스피커 / GPU / 카메라 기기 / 통신 칩 / 메인 보드버튼(쿼티자판이 있을

경우- 예 = 블랙베리) 외에도 수많은 부품이 들어 갑니다. 이 중에서 단연 충돌이 많이 나서 터치가 안되는 문제를 발생시키는

부분은 메모리나 / SD카드 인식속도나 포멧 문제 / 블루투스의 채널이 00000(NULL) 이라던가/내가 충전한 배터리는 분명히

15%가 남았는데 계속 꺼지거나 화면이 줄어들었다가 커진다던가 배터리를 연결해 달라던가 하는문제들이 휴대폰에 오류를 일으키는

부분이 있습니다. 이러한 것은 비단 소프트 웨어적인 문제만이 아니라 기기간의 호환성충돌로 나타나는 경우가 있습니다.

전력부분이 무슨 상관이냐 할 수 있지만. 요사이에 대부분의 글리치의 원인은 호환성 보다도최근 추세가 전력소모량과 열이 

화두가 됨에 따라서 많은 민감함이 있곤 합니다.

모바일 기기는 글리치를 보기가 어려운 이유는, PC와는 다르게 조립이 이미 되어 나오기 때문에, 어느정도는 호환이 된 상태의

패키지 모델을 준비하지 않으면 출시가 될 수도 없기 때문입니다. 그래픽적이나 주파수 적인 글리치를  경험하는 경우는대걔

커스텀 롬으로 자기가 직쩝 할 경우에 나타납니다. 이유는 1000짜리 크기의 G라는폰이 있는데. 운영체제는 900짜리 A라는 폰에

맞추게 되면 버튼이나 이런 애들이 터치랑 따로 놀거나 겹쳐지는 증상이 나타납니다. 하지만 터치는 정확히 먹히고 있지요. 이유는

해상도 문제와 터치 패널의 위치가 다름에 있는 기기문제가 될 수 있지요. 애시당초 커스텀롬 자체는 이런 규격을 맞추어 주지 않습니다.

<유니티엔진과 퀄퀌칩과의 삼각관계.jpg- 게임은 멀쩡합니다. 스샷만 이렇지..>

-PC / 콘솔

> PC에서의 글리치는 콘솔과 매우 닮아 있습니다. 콘솔이 주로 PC의 형태처럼 진화를 해서 그렇긴 합니다. 주로 나타나는 글리치는

바로 GPU 성능이 받혀주는데도 제대로 표시도 못하거나 튀는 현상이 있다던지, 아니면 그래픽을 표현하는 지점 및 코드는 정확한데

그래픽카드에서 표시를 할 수가 없어 게비스콘 아저씨처럼 허얘진다던지, 아니면 각기춤을 추듯이 사람들이 움직인다던지 하는 문제가

생깁니다.  또 색이 번져버린다던가 아니면 아예 레이져를 쏘기도 합니다. 주파수가 너무 많이 나오면 찌익~ 하는 고주파음도 나죠.

하드웨어 리소스가 적어도 글리치는 일어납니다. 분명 게임에서는 핑이 정상인데 P2P를 켜놓거나, 바이러스 검사 중에 게임이 중간에

뚝뚝뚝 끊기는데 이게 대충 프레임이 50 > 10  요런식으로 사실은 주기적으로 떨어집니다. 이건 정상입니다. 리소스를 너무 많이 쓰거나

하는거니까요.

하지만!! FPS(프레임 퍼 세컨드= 초당 장면 깜빡임 지수)가 50 >120 >10 > 50 >120 >10 이런 식으로 끊긴다면 하드웨어 충돌을 의심 해보셔야

할 수 도 있습니다. 그래픽 카드가 과부화 혹은기기와 충돌하는 게임이거나 파워서플라이의 전력 부족도 원인이 됩니다.

정격 600W 를 써야 하는 PC가 정격 500W 파워를 달고 게임을 하게되면 그래픽 카드 및 하드웨어는 제 성능을 발휘하지 못합니다.

사람도 밥을 100주고 일 시켜야 하는데 50주면 얘가 이를 했다가 안했다가 하듯이 리소스가 부족하면 그래픽 카드나 기타 기기들도

힘을 50 밖에는 못 내는거지요 문제는 이 50의 경계가 정해진게 아니라 들쭉 날쭉하다는 겁니다. 이게 글리치의 원인이 됩니다.

즉 게임상에는 정상적인 표기 및 입력이 되고 있는데.. 정작 PC에서는 그래픽카드가 처리를 못해서 이미 플레이어가 손을 쓸 수

없게 되어버리는 경우이지요.

한때 게시판을 뜨겁게 달구던 파워가 있었습니다. 터지는 파워 "뻥궁" 이라고 하는 별명이 있는 "천궁" 파워를 예를 들어보면(회사 없어짐)

제 친구도 희생양이긴 하지만.. 이 파워가 정격은 600W인데 실제 내는 양은 저항이랑 캐피시터 포함해서 견디는게 472W 정도 밖에 안되는데,

이러한 전력을 과도하게 600W 를 뽑아내려니 뽑아지지도 않고, 급기야 최고의 불량 제품은 폭발도 하는 불의의 사태도 난적이 있었지요.

 사양이 일반적인 PC방 사양으로 돌아가는 게임이 있다고 가정을 해봅시다. 뭐 AOS 장르의 L 게임이라고 쳐봅시다.

그럼 일반적으로는 GTS 250 이면 돌아가고도 남을 수 있습니다. 물론 사양을 협의해야 할 수도 있지만. 일반적으로는 돌아갑니다.

그러나 친구는 GTX560을 쓰고 있었고. CPU도 I7 1세대였습니다. 근데 그게임이 랙이 엄청 걸립니다. 움직이면 모션이 생길정도로요

보니까 120 프레임으로 비 주기적으로 튀고 있었죠. 5분을 못 버티는 겁니다. 친구의 원인은 하나였죠. 그래픽카드가 문젠가 보다.

그래피카드를 바꾸러 갔죠. 네? 그대로 안됩니다. 메인보드 고치러 갔습니다. 네? 역시 안됩니다. 램도 바꿨어요. 넵 안됩니다.

하드디스크 스왑인가 해서 다 끄고 SSD 달았는데도? 넵. 5분뒤 120프레임이 나왔습니다. SSD 달고도 랙걸리는 이 상황은 과연.

제가 가서 파워가 뭔지를 보고 기겁을 했습니다. 천궁이였죠 천궁 600W 였던 겄이였죠. 그냥.. 이거다 싶더군요. 모든 원인은 이 천궁의

글리치 덕분에 나는 것이죠. 물론 설계는 그렇게 하지 않았겠지만.. 실체는 그렇치 않습니다. 애시당초 PCB가 문제가 있긴 합니다.

자세한게 궁금하심 천궁 쳐도 분해기가 나오니 보심 됩니다.

어쨌든 원인은 정격과 다른 파워의 비정상적인 전력 공급이 원인입니다.

이런게 뭔 글리치랑 상관이 있느냐! 라고 하신다면 실험을 하셔도 됩니다. 최신사양에 400W를 달고 해 보시면 절로 마우스를 모니터에 던지실

준비가 되신겁니다. 최악의 상황이라면 VGA가 주파수를 제대로 못 내서 주파수를 탁탁 튀면서 모니터가 꺼지는 진 관경도 목격 하실수 있습니다.

모니터들은 주파수가 초과하면 안 켜집니다. (이런 주파수 따위 못켜!! 하면서 말이지요). 제친구 모니터가 자주 꺼집니다..

말로는 이정도 하고 그림을 몇개 넣어보겠습니다. 그래야 이해가 되실랑 말랑 하실거 같으니 말이지요. 글리치 여러분도 할 수 있습니다!

(절대 하지마세요!!)

 <검색창에 "뻥궁"을 쳐보세요~>

요약

귀찮은 분은 여길 읽어주세요

- 글리치는 주로 하드웨어의 주파수나 전력소모에 따른 성능의 불안전성 하드웨어간의 충돌로 나타나는 느려짐 / 오동작 / 데이터 깨짐등을 나타냅니다.

- 분명히 게임을 돌리는 충분한 사양인데도 소프트웨어적으로 위치도 정확하고 처리도 정확한데 그래픽이 깨지거나 느려짐 표현을 못 할 수 있습니다.

- 사양이 충분하지 않은데 하려고 든다면 그건 글리치라고 보긴 힘들고.. 그냥 사양 문제입니다.

- HW 적인 문제가 주인 글리치가 아닌 SW 적인 문제를 지칭하는 버그는 수정시간이 HW적인 문제보다는 적은 경우가 많습니다. 

  즉, 의도가 되었느냐 의도 하지 못하는 HW나 외부의 오류로 오는 문제냐에 따라서도 달라진다고 보시면 되겠습니다. 

2. 그래픽 버그

버그중 그래픽 버그는 일반적으로는 마이너한 개념 입니다.

그러나 이 버그는 그리 주요하지 않다고 생각하지만.

사용자간의 인식의 차이가 매우 심합니다. 그래픽 버그가 A급 버그라고 보는 사람도 있지만,

굉장히 알아보기 힘들정도의 그래픽 문제가 발생해도 돌아가서 내가 게임을 할 수 있으면 된다는

대단한 인내심의 소유자도 존재합니다. 요런 유형은 나중에 살펴보기로 하

 그렇다면, 그래픽 버그는 어떨때 일어나는가? 이런건 다 의도가 된 버그에 속합니다.

즉, 휴먼에러에 가깝다고 볼 수 있습니다.

 휴먼에러는 주로 사람의 아래와 같은 문제로 나타납니다. 대부분은 스트레스로 표현을 하는데요

이러한 실수를 하는 요인은 많습니다. 그 중 몇가지는

 - 적용 할 시간이 모자람

 - 육체적 피로에 의한 잊어버림

 - 인식과 행동의 차이가 발생

 - 아예 요구사항을 잘못 알고 있거나 적용될 기기에대한 정보를 아예 모름.

 - 처음에는 적용하였지만, 이 후 수정된 사항을 모름.

 - 적용된 사항을 확인하여야 하나, 그냥 넘어감.

이런 사례를 보면 주로 시간적 스트레스, 돌발 대처능력 부족의 스트레스, 안일함, 미숙함에서

주로 오게 됩니다.

 그래픽 버그의 사례는 다음과 같습니다.

 - 도트 버그

 - 셀 버그

 - 폴리곤 깨짐 버그

 - 텍스쳐 깨짐 버그

 - 접합부 버그

 - 파일 없어서 ? 로 나옴

 - 위장약을 부은듯한 백옥같은 그래픽

(일부 환경에 의해서 글리치급에 들어갈 수 도 있는 버그지만 대부분은 그래픽 오류입니다.)

 그 외 눈으로 확인 가능한 그래픽이 일정한 노이즈 증상이 아닌 단순하게 돌아오는경우는 일반적으로 포함됩니다.

그럼 이런 그래픽버그를 어떻게 일일히 발견하나요!!! 라면서 화내 실 수도 있습니다.

사실 증상 자체는 글리치가 명확합니다. 아예 동작하기 힘들정도의 심각한 수준이 대부분이기 때문이죠.

이런 단순 그래픽 버그의 경우 몇 가지 해결의 제안사항이 있을 수 있습니다.

-영업 / 기획 부서 혹은 프로젝트 매니져와 이슈 합의 (시간적이거나 프로젝트성 일 경우)

-개발 부서와의 합의 (3D 기술이거나 좌표 오류일 경우 수정을 요청함)

잠깐 여기서!

>협의가 잘 안 됩니다. 왜냐면 사실 마이너한 버그이기 때문이죠. 이러한 그래픽버그가 문제가 많음을

보여주지 않고, 단순하게 이거 깨지는데요? 라고하면 바로 협의가 되지 않겠죠.

 그렇다면!? 버그도 주요도를 매겨야 하는겁니다.

 뭐가 있을까요? 아래와 같이 생각을 해보면 되지 않나 싶습니다. 장르에 따라다르지만

1. 장르를 생각해봅시다.

투사체가 발생하는 것은 슈팅 / 액션 / RPG / RTS 뭐 엄청 많군요.. 이들에서 그래픽 버그가.

중요할 수도 있습니다. 예를 들어보죠

-RPG에서의 보스 레이드 / 공성전 / PVP에서의 셀버그 그래픽 버그를 유저가 이용함 혹은 불편을 겪음.

-슈팅에서의 적 비행체가 쏘는 탄환의 그래픽이 실제와 다르게 크다던가 반대로 너무 작고 위치도 달라 도저히 피할 수 없다.

-기획팀과 개발팀의 음모였다.(이건 농담입니다. 돌던지지 마세요..) = 기획의도가 있을 수 있습니다. 예를들면 실제 칼은 작은데

캐쉬칼이라서 조금 길게 매겼다던가. 반대로 소검인데 길게 보이는 캐쉬템이다던가.. 아니면 그냥 위에서 하라고 했던가.. 뭐 거런거죠.

 그러나. 낚시 게임이나 카드게임 고정형 퍼즐게임 등과 같은 장르는 그 다지 리스크가 크지 않는 경우가 많습니다.

(만약 카드게임인데 여성 캐릭터 카드의 이미지가 내 의도아 다른건 그래픽 버그가 아닙니다.)

  <그러니까 낚시대 빼고 신경을 안쓴다니까..거북이가 튀어나오던지 말던지..>

2. 시간을 따져봅시다.

과연 이 그래픽 버그를 수정하기 위해서 얼마나 시간이 걸릴까? 생각을 한번 해보시기 바랍니다.

예를 하나 들어서 도트를 보죠. 요즘 2D가 없긴 하지만 아이템은 여전히 도트를 쓰곤합니다.

3D가 조립이라면 도트는 미친듯히 점으로 이루는 예술일지도 모릅니다. (개인적으로 말이죠)

이거 문제 나와서 갈아엎으면 수정하는데 꽤 걸립니다.

그럼 어떻게 할건가.

<이건 납기에 문제가 없는게 아닐건데요? - 수정됐습니다 이거. 잘 하고 있어요 동물특공대.>

-납기에 문제없으니 협의한다.

-유저가 발견해도 문제가 없다.

-시간대비 리스크가 크지 않다.

아마 대걔 이렇게 갈겁니다.

3. 자원을 따져보고 심각하다고 할지 아니면 차차 고칠지에 대한 보고를 하는 편이 서로에게 좋을 수도 있습니다.

 과연 이걸 잡아내더라도 어떻게 보고할건가? 문제가 생깁니다. 역시 자원을 따져봐야 합니다. 디자이너가 3명이

풀로 일을 하고 있는데 도트를 던져준다. 이건 화냅니다. 즉 캐릭터 손과 발이 빅장을 읃어맞아서 떨어진게 아닌이상

그리 큰 문제가 아닐거라고 생각을 할겁니다. 요런애들은 모아주세요.

큰 업데이트말고 뭔가 널널한 시즌에 몰아서 처리할 수있도록 남겨 놓으면 나중에 일거리없다고 핍밥받는 경우가

(다 바빠서 그런거 없겠지만.) 이런거 있더라구요 하고 주도록 합시다. 가끔 어쩌다가 운이 떨어질 만큼의 확률로

널널할 때가 있는데 일이 없다고 투덜댈때 주면 아마 이거 하면서 시간을 보낼겁니다. 물론 윗분들 입장에서는

엄~청 안 좋지만, 크게 생각해 본다면 결국 버그 수정의 측면은 똑같기 때문에 뭐라도 하게 하는것도 하나의 관리

측면이라고 볼 수 있겠지요.

반대로 유저에게 주기도 합니다. 대부분 유저들한테 버그잡으라고 던져주면, 그래픽 버그나 스트링 버그가 대부분이기 때문이죠.

개중엔 강력한거도 나오긴 합니다.. 이건 유저한테 나왔다면 긴장해야 할 지도 모르는게 가끔은 나오기도 합니다.

그러나 이 열심히 쓴거는 결국.이론에 다나오는겁니다. 결국 이슈관리툴에 어떻게 올릴건가 고민하게 되는 내용일 뿐이라는 겁니다.

정말로 리스크한게 아닌이상 그래픽 버그는 대부분이 약소합니다. 하지만 이러한 조그마한 노력이 어떻게 고쳐지냐는 위에처럼

내부에서만큼은 생각을 해봐야 할 문제는 된다는 겁니다.

글리치의 해결방안도 위와 동일 합니다. 하지만, 이는 많은 부서와 리소스와 시간이 얽혀있어 보고도 대부분 껄끄럽습니다.

거의 대부분은 심각한 버그가 많아서 A급 버그가 되기도 합니다. 정말 심하면 그래픽카드 태워먹는 버그도 있을 수 있지요.

역시나. 귀찮으실테니 아래만 봐 주시기 바랍니다

- 그래픽버그는 주로 소프트웨어 제작 도중에 나오는 대부분의 휴먼에러나 요구사항 분석이나 이해 문제로 일어날 수 있습니다.

- 주로 외향적으로 보이며, 일정하게 나오지 않거나 사라지기도 합니다. 파일을 빼먹거나 아예 적용이 안되지 않는다면 대부분은

버그 발생면적이 작습니다.

- 유저들도 특별한 사항이 아니라면 크게 개의치 않는 경우가 많습니다. 일부 유저는 목과 다리가 떨어져도 재밌어 하기도 합니다.(흠..)

- 글리치보다 빠르게 고쳐지는 경우가 많으므로 이는 협의 하거나 모아서 해결하기도 합니다.

마지막으로 글리치이던 그래픽 버그이던, 둘다 문제점인건 마찬가지입니다. 문제점이 발견된다면,

이를 어떻게 하는가가 더 중요하다고 생각을 하면서 마칩니다.

오늘 설명할 내용은 간단하고 (작성이) 빠른

안드로이드 UI 터치 입력에 대한 자동화 테스트를 만드는 것이다.

본 자동화는 간단한 시나리오의 Repetition Test에 적합하다.

Repetition Test를 통해 Load/Stress Test나 Memory Leak Checking을 할 수도 있다.

중요한 것은 getevent 명령어의 출력값들에서

군더더기 없는 터치 이벤트를 걸러내는 것과 각 터치 이벤트 간에 Delay를 주는 것이다.

몇 번 해보면 어렵진 않으나 제대로 하려면 공부가 필요하다.

ADB.7z

GetEvent.bat

[Modeling]SendEvent.xlsx

1. 첫번째 할 일은 ADB 파일을 여러분의 로컬 경로에 저장하는 일이다.

  첨부파일 ADB.7z를 다운로드하길 바란다.

  필자는 C:\ADB 안에 파일들을 복사했다

  7zip으로 압축된 파일 안에는 아래와 같은 세 개의 파일이 담겨져 있다.

2. 여러분의 안드로이드 디바이스에 접속한다.

  필자는 Private Network을 구축하여 IPv4 Address를 이용하여 디바이스에 접속했다.

3. GetEvent.bat를 실행한다.

  배치파일의 내용은 별 것 없다.

  여러분이 UI 상의 뭔가를 터치할 때마다 일어나는 이벤트를 텍스트 문서에 옮겨담는 일을 한다.

  나는 환경변수를 건드리기 싫어하기 때문에

  배치파일에서 ADB가 있는 경로로 이동하는 명령어를 넣어두었다.

  getevent 명령어는 터치할 때마다 일어나는 이벤트들을 보여주는 명령어이고,

  '> GetEvent.txt'를 하면 출력값들을 모조리 텍스트 문서에 저장하게 된다.

  필자는 안드로이드 UI 상에서 [Home] 버튼을 한번 눌렀다.

  GetEvent를 켜두고 너무 많은 터치 이벤트를 하게 되면 나중에 뭐가 뭔지 구분해내기 어렵다.

  이를 위한 getevent 옵션들이 몇 가지 있지만 썩 유용하진 않다.

  정말 긴 시나리오에 대해서 자동화를 할 생각이라면

  그냥 자동화 프레임워크를 만들거나 이미 있는 걸 갖다 쓰거나 하길 바란다.

4. GetEvent.txt를 연다.

  아마 아래와 같은게 적혀 있을 것이다.

  주의할 점은 여기에 있는 값들은 Hex값이다. 자동화에 쓰려면 10진수로 변환이 필요하다.

  일단은 Ctrl+A, Ctrl+C를 해둔다.

5. SendEvent.xlsx를 연다.

  아래 빨간색 테두리 안에 아까 복사한 내용을 붙여넣는데,

  텍스트 마법사를 이용하여 공백을 탭으로 구분해주면 4개의 열 - A, B, C, D에 딱 맞게 들어간다.

  그리고 E열에는 자동으로 hex값이 10진수값으로 변환되어 명령문 형태로 변환되어 나타난다.

  실제 자동화에 필요한 값은 바로 이 E열이다

  쭈욱~ 복사하자. 이 예제에서는 E2 ~ E7 값을 복사하면 된다.

  (이때! 텍스트 마법사를 이용할 때 열들의 속성은 '텍스트'로 바꿔라. 안그러면 엑셀이 hex값을 제대로 처리하지 못한다.)

6. 배치파일 작성을 위해 Notepad를 연다.

  필자는 두개의 배치파일을 만들 것이다.

  첫번째는 위에서 복사한 값을 이용하여 '[Home] 버튼을 누르는 동작'에 대한 배치파일이고,

  두번째는 '여러가지 터치 이벤트에 대한 배치 파일들을 호출하는 자동화 테스트'에 대한 배치파일이다.

  첫번째 배치파일부터 작성해보자.

  마지막에 ping 127.0.0.1 -n 3 > nul 를 넣은 것은 터치 이벤트 간에 delay를 주기 위함이다.

  적정 수준의 delay를 설정하기 바라며, 배치파일들을 호출하는 자동화 테스트 배치파일에서 delay를 제어해도 무방하다.

  나는 이것을 [State]_Home_Screen.BAT라고 이름지었다.

  두번째 배치파일을 작성해보자.

  필자는 Auto_Test.BAT이라고 이름지었다.

  set /p Cpy=Repeat Count? 는 이 테스트를 몇 번 반복을 할 지를 정하는 것이다.

  사용자가 숫자를 입력하면 Cpy라는 변수에 값을 저장하고

  그 횟수만큼 루프문을 돌게 된다.

  echo [State]Home_Screen 는 현재 자동화 테스트의 위치를 나타내주기 위함이고

  call [State]Home_Screen.BAT은 다른 배치파일을 호출하기 위함이다.

  이때, call이 없으면 다른 배치파일을 실행하고 그냥 종료해버린다.

  필자는 위에서 직접 사례를 든 [State]Home_Screen.BAT 이외에

  두 가지 배치파일을 더 만들었다.

  UI 상에서 각 화면들을 State로 정의하고

  버튼이나 아이콘을 터치하는 동작을 Event로 정의하여

  각 배치파일들을 잘 구분하여 만들면

  단순한 Model-Based Testing도 가능하다.

  단, Oracle Problem은 해결하지 못한다.

  하지만 정말 MBT를 하고 싶다면 자동화 테스트 프레임워크를 사용하는 것이 정신 건강에 좋다.

7. 자동화를 돌려보자.

  필자는 Command 창에서 3을 입력했다.

  결과는 다음과 같았다.

  [Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 > 2-3초 지연 > [Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 > 2-3초 지연 > [Home] 버튼 클릭 > 앱 실행 > [Back] 버튼 클릭 >

한번 해보자.

당신의 조직에서 사용하는 테스트 케이스가

IEEE 829나 ISTQB에 나오는 형식을 취한다면,

테스트 케이스는 그 목적이나 의도에 맞게 그 표현도 명확하게 작성되어야 한다.

예를 들어, 어떤 애플리케이션을 테스트할 때 테스트 케이스가 다음과 같다면,

테스트 케이스 1

 1. 애플리케이션 UI 상단 메뉴바에서 메뉴 A를 클릭한다.

 2. 후략

테스트 케이스 2

 1. 애플리케이션 UI 상단 메뉴바에서 메뉴 B를 클릭한다.

 2. 후략

테스터 A는 테스트 케이스 1을 수행하기 위해

애플리케이션을 최초 실행한 다음,

테스트 도중 종료/재실행하는 절차 없이

테스트 케이스 2를 이어서 수행할 수도 있고,

테스터 B는 각 테스트 케이스마다

애플리케이션을 종료/재실행하는 절차를 이어서 할 수도 있다.

실제 테스트 케이스 작성자의 의도는

매 테스트 케이스 수행 전 애플리케이션을 종료/재실행하는 것이라면

테스터가 당연히 그렇게 하겠지, 하고 판단하지 말고

명확히 명시해주는 게 좋다.

위에 예를 든 것은 설명을 용이하게 하기 위해 아주 쉬운 예를 들어본 것이다.

지금 즉시 당신이 작성한 테스트 케이스를 검토해보자.

모든 테스터가 당신의 의도대로 생각하는가?

아니면, 오해의 소지가 많은가?

개발자들이 유닛테스트를 싫어하는 이유라고 제목은 달았지만, 정확한 질문은 'What bothers you about Unit Testing?' - '유닛테스팅시 어떤점이 가장 당신을 괴롭히나요??' 라는 질문입니다. 

LinkedIn에서 'What bothers you about Unit Testing?'이란 질문으로 투표를 했었습니다. 참가인원은 적어서(66명) 그다지 큰 의미를 부여하지 못하지만 나름 실무에서 활동하고 있는 개발자가 많은 LinkedIn이기에 나름 생생한 정보라 생각되서 포스팅해봅니다. 

유닛테스트 시 가장 어려운점 5가지

제일 큰 이유는 "Can't keep up with the evolution of code" , 직역하자면 '코드의 진화를 유지할 수가 없어서'입니다. 즉, 코드는 계속해서 변경하고 발전하는데 유닛테스팅을 그 코드에 맞춰서 따라가기가 힘들다는게 그 첫 번째 이유죠. 

두 번째 이유는 개발하다보면 저 역시 자주 겪는 일입니다. 어떤 유닛(메소드, 함수)을 테스팅하기 위해서는 어떤 유닛테스트가 필요로 하는 사전 조건 및 데이터가 있습니다. 유닛테스트는 그 실행순서에 구애받지 않고 그 유닛 테스팅 자체만으로 구동이 되야되기 때문에(이것이 원칙이긴 합니다), 구동에 필요한 사전 데이터를 설정하기가 상당히 곤란할 때가 많습니다. 예를 들어 다른 유닛이 실행된 후에 생성된 데이터를 가지고 테스팅을 해야하는데 데이터가 많고, 크고, 다양할 경우 정말 울고싶을 정도죠.

세 번째 이유는 교육적인 이유입니다. 좀 더 많은 좋은 예제가 필요하다는 답변이 의외로 많았습니다.  

네 번째 이유는 False Positive를 살펴보는 일입니다. False Positive란 유닛테스트는 실패한걸로 나오지만 실제고 기능이 동작하는 경우입니다. 이 경우 작성한 유닛테스트와 실제 코드를 일일이 살펴보면서 무엇이 잘못되었는지를 찾아야하기 때문에 힘듭니다.

다섯번째 이유는 하나의 유닛, 즉 한 메소드나 함수를 고치면 다른 곳에서 문제가 생기기 때문입니다.

아래는 응답한 사람의 나이, 성별, 직급입니다. 외국도 개발자는 남자가 많군요.(웃음)

안녕하세요. 곰돌군입니다.

글을 뭔가 완벽하게 쓰려고 하다보니 산으로 가는게 너무 많고, 성격상 주제를 빼먹고 뜬금없이

이야기를 하는게 너무 많다보니.. 포스팅이 산으로 가는거 같아서, 차근차근 올려보려고 합니다.

사실 지금은 QC를 하고 있으니 SQA에서는 조금 멀어진듯 하지만. 이젠 좀 차근차근 하려고 합니다.

오늘 포스팅 되는 글은 일반적인 게임에서 나타나는 오류에 대한 표와 예시를 정리해서 올려보고자 합니다. 아주 일반적인 분류이니.. 참조만 하시기 바랍니다.

<표1> 서버 / 클라이언트 이슈 분류

 <표2> 기획 / 유저 관련 오류 (서버 / 클라이언트와 중복 항목 있으나 다른 문제임)

이 표에서 빠진 사항은 시스템 내부에 컨텐츠적 오류. 개발 오류는 해당되지 않습니다.

자 이제 여기서 몇 개만 실질적인 예시로 한번 알아보도록 합시다.

일단 게임성문제는 복합적인 문제로.. 기획 개발 품질 서비스(운영) 영업 다 필요한 사항이니 빼도록 하고요..

다음시간엔 글리치 오류 / 사용성 문제 / 게임 리소스 오류 / 정도를 살펴보도록 하겠습니다.

제로베이스 사고는 고정관념을 버리고 관점을 바꾸어 다른 각도에서 문제를 바라보는 기법을 뜻합니다.

테스트를 할 때 기존 고정관념의 틀에서 검증 대상을 바라보는 것은 아주 위험합니다. 놓치는 것이 많아지거든요.

실제로 자신이 지난 테스트를 통해 얻은 경험이나 축적된 지식 등을 버리고 완전한 제로 베이스에서 다른 아이디어를 떠올려본다는 것은 쉽지 않은 일입니다. 특히, 특정 시나리오에서 결함을 발견해 본 경험은 그로 하여금 그 시나리오에 편향된 테스트 아이디어만 떠올리게 할 위험이 있습니다.

예를 들어, PC가 최대 절전 모드 상태에 진입했다가 빠져나온 후에 PC와 연결된 디바이스와의 통신에 발생한 문제점을 경험해본 테스터라면 테스트하는 동안 그리고 다음 테스트에서도 'PC 최대 절전 모드 전과 후'라는 조건을 염두에 두고 있을 것입니다. 하지만 PC와 디바이스 간의 통신에 영향을 주는 요소는 이것 뿐일까, 하고 생각해보십시오. 디바이스 단에서 연결이 끊긴 경우, PC 단에서 연결이 끊긴 경우, 디바이스가 재부팅되는 경우, PC가 재부팅되는 경우 등등 다양한 요소들이 떠오를 것입니다.

실제로 유저들이 하루동안 PC를 사용하는 패턴을 보게 되면, (1) 퇴근 후 PC 전원을 껐다가 장시간 방치 후 아침 출근 후 PC 전원을 켜고 난 다음 디바이스와의 통신, (2) 회사에 있는 동안 미팅, 점심 식사 등으로 PC가 화면보호기나 각종 절전모드로 진입한 후 자리로 다시 돌아와 PC를 다시 Wake-up 시켰을 때 디바이스와의 통신 (3) 블루스크린 발생 및 윈도우 업데이트 등으로 인해 PC를 재부팅한 후 디바이스와의 통신 등등 여러가지 상황이 있을 수 있습니다.

여기서 예를 든 것은 제로베이스 사고의 다양한 세부 방법 중 일부에 해당합니다. '제로베이스 사고'에 대해 단편적인 지식만 가지고 계신 분이라면 구글링 한번 해보십시오. 아마, 당신의 테스트 아이디어는 이전보다 훨씬 더 좋아지리라 믿습니다.

<출처 : http://endeavor-online.com/changing-life-with-zero-based-thinking>

다음 시간에는 '프레임워크 사고'에 대해 알아봅시다.

Debugging for Testers

Alan Page

최근 개인적으로 내게 경각심을 불러일으키는 말들을 자주 들을 수 있었다. 내가 들은 이런 말들의 요지는 한 마디로 ‘디버깅은 코더들을 위한 것이고, 테스터들은 단순히 이슈를 찾는 것 뿐’ 이라는 것이다. 이렇게 말하는 이유를 이해할 수 있다(아니면 적어도 최소한 이해한다고 생각한다). 나는 모든 테스터가 코더일 필요는 없다는 말에도 동의한다. 또한 모든 테스터들이 디버깅 마스터가 될 필요도 없다. 하지만 그 어떤 테스터도 디버깅을 두려워해서 이를 멀리해서는 안된다고 생각한다.

저번 시간에 이어 FUN QA는 그럼 어떤것인가에 대한 고민을 해 보도록 합시다.

1.FUN QA 그건 마치 게임에선 수표 일지도 모른다.

1. FUN QA는 일종의 수표 같은 존재입니다.  하지만 만능에 백지수표까지는 아닙니다.

게임에 있어서의 재미는 흥행을 이야기 하기도 합니다.

게임도 역시 미디어기에 많은 사람이 할 수록 유리합니다.

물론 소수 정예를 이루는 매니악한 게임도 있습니다.

인기 = 이윤!  아니지요.. 사실 인기만으로 이윤으로 이어지지는 않기도 합니다. 

재미를 측정하는 일은 상대적인 일입니다.

즉 FUN QA는 이 게임이  

게임의 기획요소 및 요구사항에 적합한지 

가상의 공간 혹은 세계관이 현실과 조화를 이룰 수 있는지 

현실상에서는 시장 조사를 바탕으로 재미가 있을지 분석을 하고 

주변에 있는 정보나 기법을 모아서 위험성을 예측 한다. 

즉 기획적 능력과 품질적인 능력을 동시에 지녀야 한다는 이야기가 되겠죠.

2. 낚시게임으로 예를 들어보자.

카드나 고스톱을 예를 들면 어떤 부서가 화 내실거 같으니 낚시게임으로 예를 들어 보겠습니다.

낚시게임의 재미 요소는 무엇일까요?

1. 여러사람에서의 경쟁 속에서 내가 더 크고 희귀한 물고기를 잡았다.

2. 어려운 시도 끝에 거대한 물고기를 낚았다.

3. 희귀한 장비를 돈을 모으거나 뽑기를 해서 샀다.

                            ...

뭐 꼽으라면 엄청나게 나옵니다. 이걸 측정 할 수 있을까요? 결국엔 못합니다. 너무 구체적이지 않습니다. 재미를 찾아 나서기 위해서 

기획서를 요구하곤 합니다. 게임에 대한 기획 및 요구사항 / 제반 사항 등을 회의나 기획서를 통해서 알아보곤 합니다.

기획 했던 사항이 잘 적용이 되었는지 볼 수 있습니다. 만약에 낚시게임에서A섬에 대한 업데이트에 대한 기획이 있었다고 쳐보도록 하겠습니다.

(한 5분 정도 기획된 겁니다..)

 

어쩌구 낚시 게임(가칭)

구현 된 사항 : 50랩까지 있음 / 낚시대는 평균 중급 고급 낚시대가 존재함/ 물고기 어종별로 다른 미끼를 먹음/ 프리미엄 물고기가 있음

고급 미끼가 구현되어 있음 / 이벤트 어종이 있음/ 어류를 모으는 도감이 있음 (이벤트 한정 도감 / 일반적인 도감)/10회 이상 물고기

텐션 유지 실패시 도망감. / 릴 조정이 아니라 HIT 방식이다./ 재도전 할 수 있음

 

A 섬 기획안

 

물고기 종류 : 25LV 부터 입장 가능/ 거북이는 이벤트 어종이다.

 

어종:오징어 / 꼴뚜기 / 대구 / 명태 / 거북이 / 연어알 / 물새알 / 인어

 

먹이: 비실비실한 지렁이 / 싱싱한 지렁이 / 멍한 새우 / 싱싱한 새우 / 금삐까 미끼 / 프리미엄 김중배의 다이아몬드 미끼

난이도 

오징어 / 꼴뚜기 / 대구 : 일반어종 : HP 300  27 lv 평균 5lv 낚시대로 약 30hit 및 

텐션 유지로 잡을 수 있음 (다이아몬드 미끼 제외 전 미끼) 도감에 들어감. 시간제한 : 40초 도감보상 : 적음

 

대구 / 명태 : 일반어종 :HP 500  27 lv 중급 5lv 낚시대로 약 36hit 및 

텐션유지로 잡을 수 있음(싱싱한 지렁이 / 멍한 새우만 나옴) 도감에 들어감 시간제한 : 40초 도감보상 : 보통

 

거북이 : 특수어종 HP 660   30lv 중급 5lv 낚시대로 약 42hit 및

텐션유지로 잡을 수 있음 (이벤트 기간엔 멍한새우 이후 금삐까 미끼 및 김중배 다이아몬드 미끼) 한정기간 시간제한 : 40초 도감보상 : 높음(한정적)

 

연어알 / 물새알 : 특수 어종 : HP 600  27lv 중급  5lv 낚시대로 약 40hit 및

텐션유지로 잡을 수 있음. 도감에 들어감 (금삐까 미끼만 나옴) 시간제한 : 40초 도감보상 : 높음

 

인어 : 초 레어어종 : HP 1200 27lv 고급 5lv 낚시대로 약 60hit 및 

텐션유지로 잡을 수 있음. 도감에 들어감 시간제한 : 45초 도감보상 : 아주 높음

 

자 이렇게 내놓고 구현을 해 왔습니다. 거북이가 피가 제대로 구현이 안 되었네요. 거북이의 지느러미가 그림에서 삐져나왔습니다!  

를 FUN QA가 잡을 필요는 없죠.. 사실은.. 

 

뭐 국내 게임회사분들은 힘들게 다 하고 있을 수도 있습니다.. 몇 가지 재미요소를 살펴보자면..

 

물고기 마다 난이도가 틀려서, 도전을 할 수 있다.

도감이 있어서 어종들을 모을 수 있다. 보상이 난이도에 따라서 틀리다.

일반적인 낚시와 비슷한 HP 게이지이지만 HIT라는 점으로 텐션 조절을 단순화 시켰다.

수시로 이벤트를 하여 유저에게 보상을 준다.

 

여기서 FUN QA는 보상에 관련된 사항도 고민해야 하지만..그보다 유저가 떨어져 나갈 요소가 몇가지 보입니다.

이런걸 지적해 보고 집중 테스트를 하면 될 듯합니다.

 

A. 난이도에 대한 궁리를 해봅시다. 

일반적으로 10번의 실수를 안하고 45초 동안 60번을 하려면 플래쉬를 불러야 할거 같군요..

시간이 거진 비슷합니다. 대충 봐도 1초에 1번씩은 두들겨야 겨우 잡네요..

이러한 것을 시트프로그램이나 뭐.. 그냥 메모장에 적어서라도 통계를 내어봅시다..

0.78CP 정도 겠죠..  거진 카메라 셔터 속도입니다. 찰칵!?

도전이 불가능 한 거라면 사람들이 재미가 없어 할 수 있습니다.

그리고 25LV 부터 올 수 있지만.. 실상 27LV 낚시대를 요구하는군요.. 이건 뭐 택도 없습니다.

25LV 유저는 오지 말라는 이야기가 될 수 있겠군요.. 25LV 을 27로 바꾸던가 하는게 

좋다는 생각이 듭니다. 

"도망가는 시간 과 LV 제한 "이라는 재미 반감요소를 찾았으니.. 

기획팀에 올려봅시다.. 물론 이는 구체적 통계가 있어야 합니다.

사실 기획팀은 재미 요소를 찾아냅니다. 

재미 반감요소에 대한 재심의 시간이 있는 전문적인 팀은 극히 드뭅니다.

심리학자를 준비해 놓은 회사는 몇 없기 때문이죠... 

국내에는 아직까지 제가 아는 회사중에는 못 본거 같습니다.

B. 반짝 이벤트에 대한 항목은 아래에도 설명하지만 사실 테스트가 어렵습니다.

위에서 거북이는 사실 재미 요소에 있다고도 아니라고도 할 수 있습니다.  왜냐하면.. 

거북이를 잡아도 보상은 높지만 연어알 / 물새알에 비하면 메리트가 적다고 할 수 도 있습니다. 

난이도는  비슷한데.. 주는건 같다? 그럼 목적이 도감 보상인 사람에게는 반감이 오게 되겠죠.

3.제약요소가 있지는 않을까?

재미란 요소는 상대적인 요소입니다 QA만으로는 잡을 수 없습니다.

재미를 반감시킬 수 있는 요소 중 테스트 불가한 것은 과감하게 측정 불가능 함을 주장 하여야 합니다.

 FUN QA가 테스트 불가능한 항목

A. 각각 캐릭터간의 상성 관계 및 통계는 내어 볼 수 있지만, 그 밸런싱을 조절하는건 불가하다.

통계분석은 QA가 한다기보다는 기획적 요구 사항 문제 일 수 있다. 

B. 캐쉬에 의해서 조절되는 항목 및 반짝 이벤트에 대한 재미를 사전에 측정하는 것

C. 서버 문제 가 일어나거나 높은 사양 운영적인 요소에 의한 재미 반감 요소도 측정이 불가함.

D. 적절한 업데이트 시기를 놓치거나 폐기가 된 프로젝트에 대한 재미 검토를 하는건 시간 낭비 일 수 있습니다.

보상이 가장 문제다!  하지만 결국 FUN QA가 측정이 가능한 부분은 아니라고 봅니다.

이러한 보상이 게임 내에선 사소할 수도 클 수도 있습니다. 남들과 경쟁을 하는 게임은 주 목적이 

과시나 자신이 높은 등급에 있다는 것을 보여주어야 하기 때문입니다. 

시각적이나 자신의 게임플레이에 스탯에 영향을 미치는 그런게 없다면  사람의 감성적인면에서의 보상을 유도할 수 있습니다.

하지만 이건 측정이 불가능 합니다.  하지만 한가지는 확실합니다. 사람들은 희소성이 있거나

자신이 관계를 가져야 하는정도는 되어야 한다는 것이지요. 중점적으로 테스트를 하도록 합시다.

데이빗(David McFadzean)과 나는 “Better Software” 9/10월호에 “소프트웨어 개발 게임(The Software Development Game)”이라는 글을 발표했다. 우리는 이 글을 통해 어떻게 소프트웨어 개발 과정에 게임과 유사한 기법을 적용하는 지에 대해 설명했다. 이 일이 있고난 후, 소프트웨어 테스팅에 관련해서도 게임과 유사한 기법을 적용할 수 있는지에 대해 글을 써달라는 요청을 여러번 받게 되었다. 이 글을 통해 그 방법을 자세하게 알아보기로 하겠다.

자, 내가 생각하는 바는 이렇다.

어떻게 소프트웨어 테스팅이 게임과 같을 수 있을까? 소프트웨어 개발 자체를 게임과 같다고 간주하거나, 혹은 서로 다른 사람들이 서로 다른 동기와 목표를 가지고 협동하거나 경쟁하는 상황이라고 생각한다면, 소프트웨어 테스팅은 확장된 소프트웨어 개발 게임(SDG; Software Development Game)이라는 범주 안에 속하며 따라서 게임과 같다고 생각할 수 있을 것이다. SDG가 정책과 사례, 그리고 프로세스와 툴, 기술적인 면을 이상적으로 혼합하는 방법에 초점을 두고 있다면, 소프트웨어 테스팅은 게임이라는 큰 전제 하에서 크게 두 가지의 형태가 앞서거니 뒤서거니 하는 형태를 띄게 된다. 이 두 가지 서로 다른 게임 스타일은 바로 스크립트 테스팅과 탐색적 테스팅이다.

스크립트 테스팅 게임에서는 테스트 계획과 테스트 케이스 관리 시스템이 가장 많은 영향을 미친다. 우리는 이러한 관리 시스템을 통해 테스트 스크립트를 반복하고 그 결과를 패스 혹은 패일로 처리함으로써 보상을 받게된다. 또한 우리는 테스트 케이스 관리 시스템에 저장되어 있는 테스트의 커버리지를 통해 정량화될 수 있다. 테스트 케이스 관리 시스템에 미리 설정되어 있는 테스트 커버리지에 얼마나 가깝게 테스트를 수행했느냐는 모든 사람들에게 중요한 문제 중의 하나다. 이는 늘상 반복되는 일임과 동시에, 환경의 제약을 많이 받는 일중의 하나다. 테스트 케이스 관리 시스템 상에서 높은 커버리지를 달성해야 한다는 목표와 어긋나는 일들은 종종 무시되거나 아예 시도조차 되지 못하기도 한다. 이런 경우, 시스템 상의 수치가 가장 중요한 목표가 되어버리고 아무리 더 나은 테스팅이라고 하더라도 이 목표에 어긋나는 것이라면 무시당하기 일쑤가 되어버린다. “당신같은 테스터들은 얼마나 많이 시스템에 있는 테스트 케이스를 수행했는지, 그리고 그 결과에 따라 패스나 패일을 표시했는지에 따라 보상을 받게될 것이다. 그러니 이런 일을 다 한 다음에도 시간이 남으면, 그때에나 다음에 뭘할까 생각해봐라.”

탐색적 테스팅 게임에서는 테스터가 어느 정도 자기 일에 대한 결정 권한을 가진다. 사실 가장 최근의 정의는 오히려 이 부분을 강조하고 있다. “개인의 자유와 책임을 강조하는 소프트웨어 테스팅 스타일. 프로젝트 전체를 통해 테스트와 관련된 학습, 테스트 디자인, 테스트 실행 그리고 테스트 결과 분석을 상호 보완적으로 수행함으로써 작업의 품질을 지속적으로 향상시킬 수 있게 한다”라고 정의하고 있는 것이다.

탐색적 테스팅을 수행하는 게임 플레이어는 그들이 수행한 작업의 품질과 접근법, 그리고 그들이 제공하는 정보의 품질에 따라 보상을 받는다. 탐색적 테스팅은 스크립트 테스팅에 비해 유연하고 상대적이며, 질적인 정보를 중시하는 경향으로 인해 숫자[1]를 중요하게 보는 생각들은 때때로 폄하되고는 한다. 만약 테스터가 업무를 수행하는 도중에, 어떤 합리적인 이유로 일의 방향을 바꾸고 이것이 합당한 조치였다는 것을 논리적으로 입증할 수 있다면, 이러한 변경에 대해 충분한 보상을 받을 수 있을 것이다. 이러한 변경이 제품 자체에도 도움이 되고 자신이 보유한 테스트 기법을 향상시키는 데에도 도움이 되기 때문이다. 커버리지는 테스팅에서 무엇보다 중요한 요소 중의 하나이다. 테스터는 탐색적 테스팅을 사용함으로써 기존의 리그레션 테스트를 얼마나 많이 반복적으로 수행했느냐를 통해 커버리지를 측정하는 방법을 벗어나, 커버리지를 확보하는 다양한 기법을 사용해 볼 기회를 가지게 되며 때로는 중요한 기법들을 새로 발견할 수도 있다.

탐색적 테스팅을 생각할 때마다, 룰을 변경하는 것이 의미있는 턴으로 간주되는 게임인 노믹(Nomic)[2]을 떠올리곤 한다. 노믹처럼 여러 명이 무언가를 변경하는 대신 테스터들은 그들 스스로 그들의 코스를 자유롭게 변경시킬 수 있다. 이를 통해 탁월한 업무 성과를 창출함으로써, 팀 전체의 성과와 기법을 향상시키는데도 도움을 주어야 한다. “테스터들은 훌륭한 테스팅과 중요한 문제를 찾아내고 보고하는 스킬과 능력으로 보상을 받는다. 우리는 테스터들이 정보를 얻기 위해 한 번의 테스트를 수행하던, 혹은 수 천번의 테스트를 수행하든 상관하지 않는다. 당신들이 제공하는 정보로 인해 제품의 품질과 가치가 얼마나 향상될 수 있느냐가 의미있는 것이다”. 탐색적 테스터들은 팀 전체가 제품을 통해 어떤 가치를 창조할 수 있도록 그들이 처한 상황을 개선하고 필요한 정보를 제공해 주어야 한다. 또한 대부분의 경우 동료들로부터 지지와 존경을 얻어내는 것도 필수적이다.

자 이제 게임 플레이를 생각해보자. 스크립트 테스팅과 탐색적 테스팅은 모두 어느 정도 반복적인 작업을 포함하고 있다. ‘게이미피케이션’이라는 개념을 활용해 이러한 행위를 연구함으로써, 어떻게 게임이라는 컨셉을 적용해 우리가 수행하는 작업을 더 발전시킬 수 있는지에 대해 답을 얻을 수 있다. 우리가 연구해 볼 대상 중의 하나는 바로 비디오 게임이다. 우리가 MMORPG 게임을 플레이하고 있다고 가정해보자. 어떤 플레이어들은 개인의 퀘스트 혹은 파티가 공유하는 퀘스트와 상관없이 반복적인 작업을 수행하는 것을 좋아할 것이다. 그들의 캐릭터에 맞는 새로운 의상이나 액세서리를 얻기 위해 단순하고 반복적인 사냥을 좋아하는 플레이어들도 있다.

또 어떤 플레이어들은 퀘스트를 달성하는 것에 집중한다. 그들은 개인에게 주어진 미션을 달성해 포인트를 획득하는 것과, 특정 퀘스트를 완료해 보상을 얻고 이 과정에서 동료들과 협동하는 것을 배워 좀 더 많은 것을 달성하려고 한다. 어떤 플레이어 유형은 반복되는 개별 업무를 통해 보상을 받으려하고, 또 다른 사람들은 성과를 만들어내거나 혹은 스스로나 다른 사람들의 가치를 탐구하는 것에서 보상을 받으려 한다. 이 두 가지 타입이 혼재되면, 거의 모든 플레이어들이 그렇듯이 캐릭터의 외양을 변경하는 서브미션을 수행하면서 동시에 더 어려운 퀘스트를 수행하거나 다른 업적 달성을 위해 장비를 강화하고 골드를 모으는 것이다. 상대적으로 덜 도전적인 사람들과 캐릭터의 외양에 집착하는 사람들 모두 이러한 퀘스트에 참여할 수 있게 되는 것이다.

만약 당신이 이런 게임을 하면서 협력 플레이를 하려고 한다면, 당신과 다른 시각을 가지고 있는 사람들도 많다는 사실을 알게 될 것이다. 만약 팀 구성원이 팀 전체의 업무에 도움을 주는 것보다 그가 가진 캐릭터의 능력치를 올리는 것에만 관심을 보인다면 이는 실망스러운 일이 아닐 수 없다. 예를 들어, 만약 당신이 레이드에 참가하고 있을 때, 한 명 혹은 그 이상의 레이드 구성원들이 자신의 체력을 채우거나 떨어진 금화를 줍기 위해 계속 멈춘다면, 레이드의 속도가 느려질 뿐만 아니라 어떤 경우는 다시 레이드를 구성해야 하는 일도 생길 것이다. 게임에서 눈에 보이는 가치와 보상 구조가 조화롭지 않게 설계되었기 때문에 함께 레이드를 진행하기가 힘든 것이다. 개인적인 스탯과 장비에 집착하는 사람들이 있는 반면, 자신이 보유한 캐릭터의 속성과는 관계없이 동료들과 레이드 전체의 목적을 우선시 하는 사람들도 있는 것이다.

소프트웨어 테스팅 게임에서, 엄격하고 제한적이며 스크립트 기반의 게임을 하는 테스터들에게 보상을 주는 시스템에서라면 탐색적 테스팅 게임을 수행하기 힘들 것이다. 정반대로, 테스트 케이스 관리 시스템에서 요구하는 커버리지를 얼마나 달성했느냐로 보상을 받는데 익숙한 테스터들에게, 그들이 제공한 정보와 테스팅 스킬의 품질로 보상을 받게 한다면 거의 어떤 보상도 받지 못할 것이다. 테스팅에 대한 전통적인 개념과 일반적인 사례들은 테스팅을 단순히 테스트 케이스 관리 시스템이 중심이 되는 게임의 한 종류로 보는 경향이 있다. 이런 부류의 사람들이 깨닫지 못한 것은 테스팅이라는 게임을 플레이 하는 데에는 단 한 가지가 아닌 여러가지 다양한 방법이 존재한다는 것이다. 나는 게이밍이라는 렌즈를 통해 다른 방법들을 좀 더 자세하게 살펴보았으면 하는 바램이 있다.

테스터와 테스트 매니저들은 스크립트 테스팅과 테스트 케이스 관리 도구 외에도 더 많은 것들이 세상에 존재한다는 것을 알 필요가 있다. 스크립트 테스팅과 테스트 케이스 관리 도구는 모바일과 웹을 비롯한 새로운 분야가 성장하면서 야기된 새로운 기술과 방법론 앞에서 다시 전면에 나서려고 노력하는 고전적인 게임(최소한 1970년대부터 이어져온)의 일부일 뿐이다. 현대적인 테스터들은 우리를 둘러싼 세상에 걸맞는 게임을 플레이하려고 노력한다. 팀원들이 시대에 걸맞는 게임을 플레이하고 있는지, 아니면 지금까지 가장 익숙했던 게임을 플레이 하고 있는지를 관찰하고 그에 따른 보상을 주고 있는가? 비디오 게임의 주인공이 스탯을 높이고 액세서리를 모으는 것처럼, 당신은 다른 팀원들의 목표를 방해하면서까지 이에 집착하고 있는 것은 아닌가? 아니면 적합한 측정과 보상을 통해 전체 소프트웨어 개발 팀이 더 나은 제품을 만들 수 있도록 도와주고 있는가?

추후에 게이미피케이션과 게임 이론, 그리고 게임이라는 관점을 더 깊이 분석해서 소프트웨어 테스팅을 탐색할 것이다. 지켜봐주시길 바란다.

게임과 확률의 관계는 꽤 밀접하다. 과거 PC게임이 없던 시절에도 사람들은 RPG를 즐겼다. D&D라고도 불리는 이 게임은 사람들이 테이블에 둘러앉아 판타지 소설에 나오는 직업들(전사, 마법사, 성직자등등)을 각자 맡아 진행자가 들려주는 이야기의 모험을 즐기는 게임이다.

Welcome to the D&D World!

이 게임을 진행시키는 가장 중요한 요소는 주사위이다. (D&D에서 사용되는 주사위는 6면체 말고도 8면체부터 21면체까지 다양하다.)

나누고 나누고 나눠 봅시다.

주사위를 굴려 나온 숫자에 따라 전투가 진행되고 이야기의 흐름에 적절한 방해도 받고 하는 것이다. (적절한 방해와 장애물은 이야기에 몰입하는데 매우 중요하다.)

이러한 주사위 확률 룰은 그 뒤 D&D가 PC의 RPG게임으로 변하면서도 계속 유지되어 오고 있는 중요한 요소이다.

확률은 매우 중요한 게임 요소이다. 그리고 게임 외적으로도 중요한 요소이기도 하다.

그렇다면 이러한 확률은 어떻게 테스트를 할까?

테스터에게 이런 과제가 주어졌다.

“고블린 사냥을 성공 했을 시 ‘고블린의 귀’ 아이템이 1/10 확률로 받게 되어 있다. 고블린의 귀가 1/10 확률로 받을 수 있는지 확인해 달라.”

테스터는 고블린을 10번 사냥했고 ‘고블린의 귀’ 아이템은 안타깝게도(?) 3개가 나왔다.

그렇다면 테스트 결과는 실패한 것일까?

테스터는 생각한다.

아니다. 확률에 대한 코드는 정상적으로 동작했고. 그 결과. ‘고블린의 귀’ 아이템은 나오거나. 나오지 않는 결과가 나온 것이다.

확률 코드에 대해 좀 더 구체적인 결과를 얻고 싶다면 1/10 과 1/100 확률이 나오는 테스트를 할 것이 아니라 1/10, 10/10 에 대한 확률을 테스트 하는 것이 좋을 것이다.

위와 같은 테스트 통해 테스터는 다음과 같은 결과를 얻을 수 있다.

1/10 – 1,2번의 당첨

10/10 – 10번의 당첨

경계값을 좀 더 고려하고 싶다면 9/10을 추가 할수도 있다. 받을 때보다 못 받는 경우가 더 적어야 정상이다.

그리고 테스터는 확률 코드가 정상임을 확인 할 수 있다.

아마도 확률의 이런 부분에 대해 “아니 그럼 이 희귀템이 정말 서버 통틀어 하나 정도면 나와야 하는데 확률을 못 믿으면 어떻 하나요?” 라고 생각 할 수도 있다.

어… 그건.. 그러니까..

정말 서버 통틀어 하나만 나와야 하는 희귀 아이템이고 제약에 대한 부분이 필요하다면 확률 외에 해당 아이템이 한번 이라도 나오면 그 뒤로는 나오지 않는 조건이 코드에 추가되어야 한다.

나는 실제로 그런 상황을 본 적이 있다. 이벤트로 확률에 의해 당첨되는 아이템이 확률에만 의존하여 기획자의 의도와 다르게 생각했던 수량보다 더 나간 것이다. 아마도 수량의 제약까지 있었으면 문제는 발생하지 않았을 것이다.

한번 확률만 있어도 되는 경우와 확률과 제약이 같이 있어야 하는 경우를 나눠 보았다.

확률만 있어도 되는 경우

전투 시의 확률 (공격율,방어율,회피율)

파티 플레이 시 루팅 확률

루팅되는 아이템이 밸런스상 기획자의 제약 안에 있지 않아도 되는 경우

확률과 제약이 같이 있어야 하는 경우

이벤트 시 당첨되는 상품 수량이 제한되어 있을 경우

루팅되는 아이템이 밸런스 상 기획자의 제약 안에 있어야 하는 경우

P.S 디아블로 같은 게임은 유니크템이 떨어지는데 제한이 있지 않다. (디아2 말기 그 귀한 조던링이 뭉치로 돌아다녔다.) 결국 제한을 거느냐 마느냐도 해당 게임의 게임성에 따라서 기획자가 정할 일이다. 가정으로 서버 하나에서 모든 유저들이 최고의 무기를 가지기 위해 서로 싸우는 게임이 있고 그 무기가 조던링같이 루팅이 된다면 모든 유저들에게 해당 게임을 하는 목표가 사라지기 때문에 안 될 것이다.

이 글은 정적분석 툴인 C++ Test, JTest 등의 개발사인 Parasoft의 블로그 글을 간략하게 번역한 글입니다. 

또한 제 블로그에도 게재되었습니다. 

소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기

(Static Analysis Optimization Tip: Scrub Your Rule Set)

여러분의 개발팀이 어디서부터 어떻게 "진짜 문제"를 붙잡고 씨름해야 할 지 모를만큼 많은 정적분석 규칙 위반의 숫자에 압도된적이 있나요? 

여러분의 정적 분석 최적화의 첫걸음은 너무 많은 것이 어수선하기 채워져있는 규칙을 깔끔하게 정리하는 것입니다. 너무 많은 규칙들은 진짜 관심을 가져야할 이슈에 집중하기 어렵게 만들지요. 두번째는 여러분의 시야를 넓여서 조직에 가치를 증대시키는 길로 여러분의 진취성을 발휘하는 것입니다. 

여러분의 정적 분석 구현을 다시 한 번 환기시키는 길을 찾아보고자 합니다. 정적분석 규칙을 다듬는 2가지 방법을 보시죠. 

당장 강행하지 않을 정적분석 규칙은 비활성화시켜라. 

(Disable static analysis rules you're not committed to enforcing right now)

많은 규칙을 체크하는 것은 정적분석으로 얻을 수 있는 최고의 ROI를 달성하는 열쇠가 아닙니다. 사실, 많은 사례에서는 그 반대의 경우가 정답입니다. 정적분석은 실제로 여러분이 적지만 의미있는 규칙에 포커스를 맞출때 더 좋은 결과를 얻을 수 있습니다. 

여러분이 정적분석을 수행하는 것은 경험이 적은 개발자 어깨 너머에 경험있는 개발자가 서있고 경험이 적은 개발자에게 코딩할때 팁을 알려주는 것과 같습니다. 만약 경험있는 개발자가 소스코드 한 줄 한 줄마다 하찮은 이슈로 끊임없이 잔소리 타령을 한다고 가정합시다. 새내기 개발자는 곧 그에게 압도되고, 좋은 조언이건 나쁜 조언이건 간에 모든 조언을 무시하기 시작할것입니다. 그러나, 경험있는 개발자가 심각한 문제를 일으킬수 있는 한 두개의 이슈에 초점을 맞춘다면, 새내기 개발자는 그가 준 조언을 더 기억하고 더 좋은 코드를 작성하기 시작할것이며, 실제로 이런 종류의 피드백에 감사하게 될것입니다. 

이는 정적분석에서도 동일합니다. 만약 여러분이 정적분석 규칙을 관리 가능하고 의미있게 유지한다면, 개발자에게 많은 것을 가르칠 수 있고, 개발자들이 프로세스에 대해서 덜 분노하게 만들 수 있습니다. 모두가 따르는 적은 수의 규칙이 좋을까요? 아니면 모두가 따르지않는 모든 규칙을 유지하는게 좋을까요? 여러분이 개발자에게 규칙 위반이 보고되자마자 문제를 해결할 것 같지 않으면, 심각하게 해당 규칙을 비활성화 시키는 것을 고려해보십시오. 

너무 많은 위반을 야기시키는 규칙을 비활성화시켜라.

(Disable static analysis rules causing too many violations)

어떤 특정 정적분석 규칙이 되풀이되서 위반된다면, 지금이 여러분이 이 규칙을 계속해서 체크할것인지 말지를 재평가해야할 좋은 기회입니다. 과도하게 많은 수의 규칙 위반은 개발자가 규칙이 요구는 방식으로 코딩하고 있지 않음을 알려주는 것입니다. 개발자들의 코딩 습관을 개선시키고자 설득하는 것은 개발자들의 만만찮은 저항에 직면할 수 있습니다. 

여러분들은 이 이슈를 계속 밀고 나가는 것이 과연 가치가 있는지 없는지 어떻게 결정하시나요? 첫번째, 왜 여러분이 우선 이 문제를 체크하기 시작했는지에 대해서 기억해보십시오. 당신이 실전에서 경험했던 이슈를 검출하는데 좋은 방법이기 때문에 선택했나요?  각종 인증 준수를 위한 노력의 일부?(역자 주 : FDA, MISRA-C 혹은 DO-178B/C와 같은 소프트웨어 규격 준수를 위한 노력을 말한다. ) 아니면 그냥 벤더에서 제공해준 기본값이기 때문에? 벤더들은 전형적으로 각각의 규칙에 대해서 설명을 함께 제공합니다. 이 규칙이 진정으로 여러분의 프로젝트의 목표에 합당한지 결정하는데 도움이 되려면 규칙에 대한 설명을 읽는 것이 도움이 됩니다. 

다음으로, 원하는 결과를 달성하기 위해 다른 방법이 있는지 봅니다. 만약 보다 구체적인 대체가능한 규칙이 있나요? 이슈가 너무 자주 발생하지 않게 규칙 파라미터를 수정할 수 있는 방법이 있나요? 

만약 당신이 이 규칙이 주는 이득과 다른 방법을 재검토후에도 이 규칙을 적용하고 싶다면, 이 규칙을 따를 때 어떤 일이 필연적으로 수반될지 개발팀으로부터 피드백을 얻으세요. 이 피드백을 사용하여 개발자들에게 이 규칙을 따를것을 요구할만한지 결정할 수 있습니다. 만약 이 규칙을 적용해서 얻는 이득인 적고 할 일만 많아진다면, 과감하게 이 규칙을 비활성화하세요. 

------ 

Image Credit: Clearly Ambiguous

<서로 끌어주고 올려주는 워페이스의 '협동 오르기' 액션. 개발사와 퍼블리셔의 관계여야 하지 않을까요?>

온라인 게임회사에서 QA로 재직하면서 적지않은 세월이 지났습니다. 그동안 게임 개발을 전문으로 하는 개발사에도, 개발된 게임을 고객에게 서비스하는 퍼블리셔에도 동일하게 “QA”라는 포지션으로 몸담으면서 실무자로서 겪게 되는 여러 가지 입장차이를 직접 경험할 수 있었습니다. 서로가 서로에게 가지고 있는 기대와, 그 기대와 다른 현실 사이에서 겪게되는 미묘한 갈등을 지금도 절실하게 느끼고 있습니다. 테스트 혹은 QA와 관련해 개발사와 퍼블리셔가 가지고 있는 서로의 역할에 대해 개인적인 의견을 밝혀봅니다.

과연 개발사와 퍼블리셔의 관계는?

요즘은 개발사 – 퍼블리셔의 협업이 게임업계의 가장 주된 비즈니스 모델이 되었지만 온라인 게임 시장의 초기에는 개발사가 직접 고객들에게 서비스를 제공하는 형태가 주류였습니다. 하지만 게임 시장이 커지고 고도화됨에 따라, 게임을 서비스하기 위한 하드웨어 및 소프트웨어 지원, 고객의 피드백에 적절하게 대응하기 위한 CS(Customer Service), 사업과 마케팅 등 직접적인 게임 개발 외에도 고객 및 서비스와 관련된 부분의 중요성이 점점 커져가기 시작했고, 이로 인해 퍼블리셔들의 위상도 점점 부각되기 시작했습니다. 현재 국내의 온라인 게임 수위 업체 거의 모두가 게임 퍼블리셔로서의 사업 영역이 전체 사업의 절반 이상을 차지한다고 해도 과언이 아닐 것입니다. 흡사 퍼블리셔가 마트나 백화점 같은 유통 및 서비스 영역을 차지하고, 개발사는 마트에 물건을 제공하는 제조사의 입장과 비슷해 보입니다. 이러한 관계는 쉽게 소위 말하는 ‘갑’과 ‘을’의 관계로 변질되기 십상입니다.

퍼블리셔는 개발사의 최종 고객인가?

최근에는 퍼블리셔가 막강한 자본력을 앞세워 실력있는 중소 규모의 개발사를 인수하는 경우가 빈번합니다. 중국 자본이 국내의 전도유망한 개발사를 인수해가는 경우도 더러 발생하고 있죠. 이런 경우가 아니더라도, 상대적으로 덩치가 큰 퍼블리셔에 비해 영세한 규모일 수 밖에 없는 개발사는 어느 정도 퍼블리셔의 요구와 주장에 끌려갈 수 밖에 없는 것이 현실입니다. 또한 퍼블리셔는 직접 고객과의 접점에서 게임을 서비스함으로써, 대중이 원하는 것을 개발사에 비해 좀 더 구체적으로 파악할 수 있고, 이를 개발 방향에 반영할 수 있도록 요구하는 역할을 수행하고 있습니다. 이런 관계로 인해 자연스럽게 퍼블리셔에게 큰 소리칠 수 있는 개발사는 찾아보기가 힘든 것이 현실입니다. 어떤 경우에는 마치 퍼블리셔가 개발사의 최종 고객이 된것처럼 보이기도 합니다.

예를 들어, 이런 경우를 가정해보죠. OBT와 같이 중요한 마일스톤을 앞두고, 여느때와 같이 중요한 여러가지 문제들이 산적해 있습니다. 개발사는 개발사 나름대로 중요한 오류를 수정하고 퍼블리셔의 요구사항을 최대한 반영하기 위해 몇 주째 크런치에 돌입합니다. 퍼블리셔 역시 자체적으로 대규모 테스트를 수행하고 여기서 발견된 문제점을 개발사로 전달해 수정을 요구합니다. 개발사는 개별 기능의 수정 뿐만 아니라 퍼블리셔들이 전달해준 문제 역시 같이 수정을 진행하게 됩니다.

이 과정에 어떤 문제가 있는 것일까요? 아닙니다. 개발사의 입장에서 수행하기 힘든 대규모 테스트를 퍼블리셔가 수행하고, 그 피드백을 개발사로 전달하는 것은 당연합니다. 실제 사용자가 가지고 있는 다양한 H/W 및 S/W 환경에서의 상호운용성이나 호환성 이슈 등은 개발사에서 커버하기에는 어려움이 있습니다. 또한 수백 수천명의 고객이 한꺼번에 몰릴 때의 서버 이슈 등과 같은 문제도 개발사에서는 쉽게 접할 수 있는 환경이 아닙니다. 물론 이런 환경을 시뮬레이션해 주는 툴들이 있기는 하지만, 구매 비용과 유지보수에 드는 비용이 만만치 않아 중소규모의 개발사에서는 쉽게 투자하기가 힘든 것이 사실입니다. 이런 경우에는 오히려 여러 게임을 서비스하면서 다양한 사용자 환경에 대한 인사이트를 가지고 있는 퍼블리셔가 관련한 테스트 랩을 꾸미고, 서비스하는 모든 게임을 이 랩에서 테스트하도록 하는 것이 훨씬 경제적이고 효율적입니다. 또한 다양한 장르와 규모의 게임이 이미 이 테스트를 거쳐서 누적된 데이터를 가지고 있다면, 새롭게 서비스할 게임 역시 동일한 테스트를 거치면서 비교할 수 있는 데이터를 가지게 되는 것입니다. 이 또한 서비스를 앞둔 게임에 있어 빠질 수 없는 중요한 부분이 될 것입니다.

요는 개발사와 퍼블리셔 모두 서로가 잘할 수 있는 부분에 집중하자는 것입니다. 개별 기능의 수정과 신규 기능 추가에 눈코뜰새 없는 개발사가 한계가 있을 수 밖에 없는 사용자 환경 테스트를 직접 수행하고 거기서 나온 이슈까지 수정해야 한다면, 자연스레 기본적인 기능 개발에 대한 리소스 투입이 상대적으로 적어질 수 밖에 없고, 이는 안정적인 게임 클라이언트 제공이라는 개발사의 1차적인 목적에 위배될수 밖에 없습니다. 그렇다고 이런 대규모 사용자 환경과 관련된 부분이 모두 온전히 퍼블리셔의 몫일수는 없습니다. 당연히 사전부터 이 부분을 염두에 두고 개발 초기 단계부터 제품이 설계되어야 하며, 마지막 크런치 단계에서도 이 부분에 대한 리소스 할당이 충분히 고려되어야 합니다. 퍼블리셔 역시 문제를 해결하기 위한 동반자의 입장에서 이 부분에 대한 수정이 원활하게 이루어지도록 최대한의 정보를 제공하고 지원을 아끼지 말아야 합니다. 다양한 사용자 환경에서 발생한 문제를 수정하는데 필요한 정보를 제공할 수 있는 곳은 오직 퍼블리셔 뿐이기 때문입니다. 이 모든 것들이 서로가 잘 하는 부분에서 잘하는 부분을 수행함으로써 좀 더 품질 좋은 게임을 만들어 서비스하려는 동반자라는 입장을 기반으로 해야합니다.

퍼블리셔는 개발사의 최종 고객이 아닙니다. 개발사가 퍼블리셔에게 ‘제로 디펙트’의 제품을 납품해야 한다는 강박관념에 비효율적인 테스트에 리소스를 빼앗겨서도 안되고, 퍼블리셔 역시 CBT나 OBT의 원래 목적이 “결함없는 제품의 공개”가 아니라 “대규모 사용자 환경 테스트를 통해 실제 환경에서 일어날 수 있는 이슈를 미리 해결한다”라는 것임을 명심해야 합니다. CBT나 OBT와 같은 사전 공개 테스트에서 문제가 일어나는 것이 비난받을 일은 아닙니다. 오히려 가장 문제가 되는 것은 어설프게 공개 테스트를 진행해서 존재하는 주요 결함을 서로 발견하지 못하고 실제 서비스에 돌입하게 되는 것입니다. 충분한 공개 테스트 과정을 거쳐서 가급적 많은 결함을 발견해 내고, 주어진 시간안에 해결할 수 있는 결함의 우선순위를 합리적으로 결정해 이 부분을 해결해 나가는 것이 개발사와 퍼블리셔가 해야할 공동의 업무입니다.

PvP가 아닌 PvE!!

가끔은 서로가 기대에 못미친다고 불만을 가질수도 있고, 너무 강압적이라거나 적극적이지 않다고 생각할 수도 있습니다. 하지만 좀 더 나은 품질의 게임을 서비스하려는 동일한 목적을 가지고 서로가 잘 할수 있는 부분에서 최선을 다하고 있다고 믿어준다면, 그렇지 않을때보다 분명 더 좋은 결과를 맞이할 수 있으리라 생각합니다. 개발사와 퍼블리셔는 서로가 경쟁상대인 PvP가 아니라, '성공적인 게임 서비스'라는 동일한 퀘스트를 수행해 가는 같은 클랜원, 공대원입니다.

오늘 이 주말도 '최상의 게임 서비스'라는 미션 수행을 위해 불철주야 고생하고 있는 전국의 개발사 및 퍼블리셔의 QA/테스터 분들에게, 힘내시라는 위로의 말씀을 전하며…

Happy Testing!!!

필자는 가끔 소스포지의 프로젝트들을 돌아보곤한다. 대개는 설익은 아이디어의 집합소이기도 하지만 가끔 대단히 특이한 아이디어들을 만나게 되는데, 오늘 소개할 프로젝트도 그러한 종류중 하나라고 생각한다. 테스터에게는 자웅동체와 같은 하~이브리드 샘이솟아 리오레이비와 같은 특성이 요구된다고 할 수 있는데, 그 중하나는 사용자의 감정이입이고, 둘째는 개발자로서의 논리적 특성이다. 이러한 논리적 특성을 계발하는 방법은 여러 가지가 있을텐데 그중 하나는 스스로 논리를 개발하고 논리를 다듬는 과정에서 잘못될 가능성을 이해하고, 전체적인 시각Bird view를 가지는 것이다. 이러한 논리를 생각하는 과정에서 이 소프트웨어의 탄생 철학과 그 쓰임을 익히는 것이 도움이 될 것이라 믿는다.

지금부터 소개할 프로그램은 다음에서 얻을 수 있다.

http://drakon-editor.sourceforge.net/

====================================================================================================================

DRAKON: The Human Revolution in Understanding Programs

October 2011
Stepan Mitkin
stipan.mitkin@gmail.com

번역: TB

그래픽 언어

DRAKON은 알고리즘을 설명하는 그래픽 언어이다. 이것은 프로그램에 대해서 사람들간에 쉽고 빠른 이해를 가능하게 해준다. DRAKON의 슬로건은 “한번 보고 아이디어를 얻자” 이다.

우주항공 분야에서 유래

DRAKON은 부란 우주항공기를 제어하는 AI를 프로그래밍하는 러시아 우주항공 프로그램 내부에서 개발되었다. 부란의 개발자들은 거대한 시스템을 만드는데 있어 가장 큰 문제는 사람에 관한 요인으로 사람들간의 의사소통에 있음을 곧 깨달았다. 알고리즘을 설명하는 일은 그것을 디자인하고 구현하는 것보다 더 어려운 일이다. 모스코바에 있는 Keldysh Institute for Applied Mathematics에 이 문제를 처리하라는 임무가 주어졌다. 그들의 결론은 DRAKON 언어였다.

이해력이 소프트웨어 프로세스에 핵심이다

프로그램과 문서를 명확하고 쉽게 읽는 것은 좋은 소프트웨어 프로세스의 핵심이다.

• 프로그램이 이해하기 쉬우면 그 안에 있는 에러는 프로그램을 실행하기 전에 보이게 된다. 초기에 에러를 찾아내는 가치를 과소평가해서는 안 된다. 첫째로, 디버딩과 테스팅에 많은 시간을 사용할 필요가 없다. 둘째로, 에러가 디자인 결함으로 밝혀지면 그 결함은 프로젝트가 시작되고 즉시 발견되고 수정이 될 가능성이 높아진다. 결과적으로 더 좋은 소프트웨어가 더 짧은 시간 안에 출시된다.
• 큰 소프트웨어 프로젝트는 사람에 의해 항상 크기가 커지는 정보의 구름일 뿐이다. 각 개인들의 (프로젝트에 대한) 기여는 기존 환경에 들어맞아야 한다. 이것이 왜 클라우드에 추가되는 것보다 기존 클라우드에서 읽을 거리가 많은지에 대한 이유이다. 새로운 요구사항이 과거 요구사항과 어울려 진행되어야 한다. 새로운 코드는 기존에 있던 코드와 잘 어울려서 동작해야 한다. 다른 것들이 완료되었는지 이해하는 것은 큰 프로젝트의 업무에서 필수적이다. 이것이 왜 그 프로젝트가 이해하기 쉬우면 사람들이 협업하기에 더욱 효율적인지에 대한 이유가 된다.

명확함은 성공을 의미하지만 반면에 불명확함은 실패를 의미한다.

이해하기는 더 쉽게 이루어질 수 있어야 한다

이해하기 에서의 문제는 무엇일까?

1. 프로그램은 점점 더 복잡해진다.
2. 그들은 이해하기에 점점 더 어려워진다.
3. 이해하는 것은 일이다.
4. 이해의 생산성은 참을 수 없을 만큼 낮다.

결론: 이해하기는 더 쉬워져야 한다

어떻게 하면 이해력을 개선할 수 있을까?

알고리즘을 쉽게 만드는 DRAKON의 혁신적인 방법은 수학적인 엄격성과 인체공학을 조합한 것이다.
한편, DRAKON은 수학적으로 엄격하다. 즉,

1. 이것은 정확하고 명확하다.
2. DRAKON이 어떤 알고리즘도 표현할 수 있다는 점이 증명되어 왔다.

반면에, 수학만 가지고는 충분치 않다. 이것은 왜 DRAKON이 사용성과 인체공학에 집중하는지에 대한 이유이다.

인체공학이 무엇일까? 인체공학은 꼼꼼하게 하고, 지루한 작업을 쉽고 편하게 해주는 예술이다. 이것은 사람이 사용하기에 편하게 해주는 어떤 것이다. DRAKON이 인체공학에 접근하는 방법은 다음과 같다.

1. DRAKON은 간단하다.
2. DRAKON은 그래픽 언어이다.
3. DRAKON은 가장 최적화된 그래픽 기호이다.

왜 그래픽이어야 하나?

텍스트는 현재 알고리즘을 담아내는capturing 주요한 방법이다. 요구사항과 코드 모두 텍스트 형태로 되어 있다면, 모든 사람들은 자연스럽게 어쩔 수 없이 텍스트의 지배를 받는다. 다이어그램은 가끔 일관성 없게 사용된다. 다음의 상황이 진짜 문제라고 할 수 있다.

1. 사람의 시각과 뇌는 받아들이는 정보의 대부분이 시각적인 정보일 때 가장 최적화되어 있다. 우리 모두는 읽기로는 잘 이해되지 않지만, 그림으로 보면 이해가 쉬울 때가 있다. 생산성을 위해 우리는 우리의 몸과 마음을 그것이 잘 작동되는 방식으로 사용해야 한다.
2. 이미지는 텍스트보다 정보를 더 간략하게 표현할 수 있다. 특히 이것은 높은 수준의 상세함이 요구될 때 진리이다.
3. 텍스트에서 그래픽으로 전환된 엔지니어들은 오래 전부터 성공을 거두어 왔다. 그들은 손그림과 설계도만으로 정말 현대적이고 기술적인 세상을 만들어 왔다.

미래는 그래픽 언어의 것이다. 왜냐하면 그것이 사람에게 더 잘 맞기 때문이다.

그림 1. 가장 간단한 DRAKON 다이어그램

어떻게 DRAKON이 그래픽에 최적화되어 있나?

왜 또 다른 그래픽 표기법이 필요한가? DRAKON에 특별한 것은 있나?

1. DRAKON 차트의 요소들은 계층적인 방식으로 정렬된다. 당신은 가장 중요한 것을 먼저 본다.
2. DRAKON은 인간의 시각적인 습성을 고려하고 있으며, 다이어그램을 살펴보는데 최소한의 공수만 든다. 당신의 시각은 사물을 찾아내거나, 이리저리 점프하지 않고도 자연스럽게 패턴을 반복해 움직이게 된다.
3. DRAKON의 엄격한 규칙과 가이드라인은 다이어그램이 모호해지지 않게 한다. 순서가 항상 보장되며, 라인과 화살표는 거미집처럼 복잡하게 되는 일이 없다.

가장 중요한 것을 가장 먼저

DRAKON 다이어그램은 Branch라고 부르는 몇 개의 수직적인 영역을 가지고 있다. 이 Branch는 문제의 논리적인 분할을 나타낸다.
DRAKON 다이어그램을 한 번 살펴보면 다이어그램의 요약을 이해할 수 있으며, 다음의 중요한 질문들의 답을 알 수 있다.

1. 문제의 이름이 무엇인가?
2. 문제는 몇 개의 부분으로 구성되나?
3. 부분들의 이름은 무엇인가?

Begin 레이블은 다이어그램의 이름을 나타내며, 첫 번째 질문의 답이 된다.
다수의 Branch들은 두 번째 질문의 답이 된다. Branch의 이름들은 세 번째 질문에 대한 답이 되며, 문제의 주요한 논리 영역을 말해준다.
그 Branch의 이름과 Begin 레이블은 다이어그램 내의 윗부분에 배치된다. 이것은 다이어그램의 요약이 항상 같은 자리에서 발견되도록 해준다.

그림 2. DRAKON 다이어그램에서의 Branch와 헤더

Branch들

Branch는 액션의 흐름을 나타낸다. 액션은 위에서 아래의top-down 방향으로 Branch 안에서 기록된다. 이 방향은 우리의 현실에서 아주 중요한데, 중력이 사물을 아래로 떨어지도록 만들기 때문이다. 이것은 왜 아래쪽으로의 움직임을 우리 눈이 “자연스럽게" 받아들이는지에 대한 이유가 된다.

규칙: 브랜치는 하나의 입구와 다수의 출구를 가진다.

입구는 상단에 위치한 특별한 아이콘으로 Branch 이름을 가진다. Branch 이름은 다이어그램 안에서 고유해야 한다. Branch 입구는 브랜치의 시작이 이루어지는 유일한 지점이다.
Branch 종료는 Branch의 하단에 있는데, 다음과 같은 두 종류의 Branch 종료가 있다.

• 다음 Branch의 이름을 나타내는 Address 아이콘
• 알고리즘의 종료를 선언하는 End 아이콘

왜 Branch 인가?

커다란 알고리즘은 사람이 동시에 매우 많은 사물을 처리하기에 적합하지 않으므로 이해하기 어렵다. 알고리즘을 여러 개의 개념적인 부분으로 나누면 가독성이 향상된다.
분할해서 정복하는 접근법을 사용해서 크고 복잡한 구조를 다양한 상세 수준에서 볼 수 있다. 대개 이것은 재귀적으로 하나의 간단한 액션 리스트를 서브루틴으로 분할해서 이루어진다.
DRAKON은 이 기법에 고유한 기능을 부여했는데, DRAKON Branch이다. 당신은 동일한 다이어그램에서 이러한 두 가지 수준의 분할을 볼 수 있다. 하지만 서브루틴은 한 가지 수준의 아이템만을 보여준다.

그림 3. 커다란 알고리즘을 서브루틴으로 분할

그림 4. 커다란 알고리즘을 분할하기 위해 Branch를 사용함

Branch가 어떻게 작동하는가?

DRAKON 다이어그램의 기능은 달리기 주자가 선을 따라서 이동하는 것으로 시각화될 수 있다.

1. 주자가 가장 왼쪽에 있는 Branch를 관통해 아래로 내려간다.
2. 그리고 나서 왼쪽 끝부분까지 이동하고, 왼쪽 최 상단 코너까지 올라간다.
3. 그리고 나서 이전 Branch의 Address 아이콘이 가리키는 Branch를 찾을 때까지 우측으로 미끄러진다.
4. 그 Branch를 관통해서 내려간다.
5. 이전과 같은 방식으로 다음 Branch를 찾는다.

주자가 한 Branch에서 다른 Branch의 중간으로 직접 이동하듯이 Branch들을 뛰어넘는 것은 허용되지 않는다.

Branch의 순서

DRAKON 다이어그램의 Branch들은 자신들의 시간 순서의 흐름에 따라 왼쪽에서 오른쪽으로 진행한다.

규칙: 우측으로 이동하는 것은 시간 순서상 나중이다.

이러한 규칙을 따르게 되면 Branch의 공간적 배치가 시간적인 배치를 그대로 나타낸다. Branch 하단에 있는 Address 아이콘은 다음 Branch를 가리키며 이것은 잠재적으로 Branch들 간에 어떤 순서를 만들어 낸다. 하지만 DRAKON은 Address 아이콘이 우측에 있는 다음 Branch를 가리키지 않는 두 가지 경우는 적법한 것으로 본다.

1. 하나 또는 그 이상의 Branch들이 생략되어야 할 때. 이것은 조건문 (if나 switch 같은)의 평가 결과로만 발생한다. 재미로 Branch들을 이동해 갈 수는 없다.
2. 어떤 Branch가 한 번 이상 실행되어야 할 때. 이것은 “Branch loop”라고 부르는 특별한 형태의 loop이다.

위의 가이드라인을 따르는 다이어그램은 인체공학적이다. 왜냐하면 신문에 있는 컬럼 텍스트와 같이 일관성이 있으며 자연스러운 방식으로 정렬되기 때문이다.

그림 5. 다이어그램내의 Branch 순서

꼬챙이

꼬챙이는 고기를 굽는데 사용하는 철로 된 날카로운 막대기이다. 꼬챙이는 Branch 내의 요소들을 정렬하는 주요 원칙을 나타낸다.

1. 입구와 Branch의 주요 출구는 직선의 수직 라인으로 연결된다.
2. Branch의 주요 경로를 의미하는 아이콘들은 수직 경로 상에 배치된다.

이러한 규칙이 충족되면 다이어그램은 깔끔하게 보이고 조직화하기 쉽다. 꼬챙이가 없다면 Branch는 깨지고 보기 흉해질 것이다.

그림 6. 꼬챙이

Branch의 주요 경로

한 Branch가 if 나 switch 같은 조건적인 아이콘을 가진다면, 그것을 통과하는데 하나 이상의 경로가 있음을 의미한다. 이 경우 한 경로를 주 경로the main route로 부르고, 다른 것들을 부차적인 경로secondary routes로 부를 수 있다. 주 경로는 가장 성공적인 진행을 나타내는 경로이다. 다시 말해, 알고리즘의 해피 시나리오happy path라고 할 수 있다. 이것이 모든 것이 의도된 대로 동작하는 경로이다.

한 번만 살펴 보더라도 Branch의 주 경로를 발견할 수 있어야 한다. 주 경로는 즉시 알아차릴 수 있어야 한다.

규칙: 주 경로는 꼬챙이 상에 위치해야 한다.

Branch에 있는 if 나 switch 아이콘의 출구는 주 경로가 맨 왼쪽 Branch의 수직을 따라가도록 바뀌어야 한다.

그림 7. 주 경로는 직선상에 놓이고, 꼬챙이를 따라 가야 한다.

부차적인 경로의 순서

부차적인 경로는 주 경로를 제외한 알고리즘상에 있는 모든 경로이다. 부차적인 경로는 주 경로의 우측에 위치한다.

부차적인 경로의 규칙: 우측으로 가면 갈수록 안 좋다.

이것의 의미는 주 경로에서 멀리 떨어지면 질수록 의미하는 바와 같이 좋지 않은 상황이라는 것이다.

DRAKON이 탄생한 이유 중 하나는 전통적인 플로우차트가 끔찍할 정도로 인체공학과는 맞지 않는 다는 점이 고려된 것이다. 그들은 이해하기가 아주 아주 어렵다. 반면에 DRAKON 다이어그램은 일관된 시각적인 구조를 가지고 있어서 질서와 명확성을 보장한다. 이 구조는 알고리즘에 대한 “충분한” 정보를 제공해서, 이해하기 쉽게 만들어주는 추가적인 프리젠테이션 레이어이다.

모든 경로가 동일하게 해피 시나리오라면? 그러면 경로들을 정렬하는 다른 방안을 생각해 내야 한다. 예를 들면,

• 우측으로 치우쳐 있으면, 주 경로에서 더욱 벗어난 것
• 우측으로 치우쳐 있으면, 더 높은 것
• 우측으로 치우쳐 있으면, 더 빠른 것
• 우측으로 치우쳐 있으면, 더 무거운 것
• 우측으로 치우쳐 있으면, 더 비싼 것

여기서의 아이디어는 경로를 정렬하는데 일관되게 적용할 수 있고 상황에 들어맞는 수트suites로서의 기준을 선택하는 것이다.

그림 8. 찻잔을 쏟았을 경우 부차적인 경로의 규칙

다이어그램의 주 경로

부차적인 경로는 그 자신의 부모 경로로 회귀하거나 자신의 address 아이콘을 가진 Branch의 끝으로 진행할 수 있다. 여러 개의 부차적인 경로가 있기 때문에 그 Branch는 여러 개의 부차적인 종료를 가진다. 주 종료는 꼬챙이의 가장 끝에 있는 종료이다. 부차적인 경로의 규칙은 Branch의 종료에도 똑같이 적용된다.

부차적인 종료의 규칙: 종료에서 멀어지는 것은 주 출구의 우측의 우측에 있다는 것으로 좋지 않은 상황이다.

이 규칙으로 인해 한 번 보고 알고리즘의 일반적인 아이디어를 파악하는 것이 가능해진다. Branch의 주 출구는 Branch의 주요 경로와 연결되어 있고, 다이어그램의 주요 경로를 형성한다. 이런 방식으로 우리는 전체 알고리즘의 해피 시나리오happy path를 쉽게 파악할 수 있고, 상세 내용은 나중에 파악할 수 있다.

If 아이콘

If 아이콘은 하나의 입구에 두 개의 출구가 있는 것이다. 출구는 yes나 no의 레이블을 가진다.

• 주 종료는 아이콘의 밑으로 나오고, 우측 종료는 아이콘의 우측에서 나온다.
• 종료를 왼편에 놓는 것은 금지된다.
• yes 레이블을 가지는 종료가 밑으로 나오던, 우측으로 나오면 상관없다.
• “true” 대신에 yes를, “false” 대신에 no를 사용한다. 어린이들은 아주 어릴 때부터 yes와 no를 배운다. yes와 no는 직관적이다.

If 아이콘은 육각형으로 플로우차트에서처럼 다이아몬드가 아니라는 점을 기억하라. 육각형 모양은 다이어그램에서 자리를 덜 차지한다.

개선된 인체공학

If 아이콘에서 나오는 아래로 가는 경로와 우측 경로를 바꾸는 것은 중요한 튜닝 기법이다. 이렇게 해서 다이어그램의 알고리즘이 바뀌진 않는다. 다만, 경로의 순서 규칙 (우측으로 멀리 떨어질 수록, 나쁜 경우)과 주 경로 규칙 (주 경로는 꼬챙이 상에 위치해야 한다)을 따름으로써 인체공학적인 개선을 의도한다.

그림 11. If 아이콘의 사용

결합

인체공학을 개선하는 또 다른 방법은 아이콘의 중복과 아이콘의 그룹을 제거하는 것이다.

규칙: 당신 자신을 반복시키지 마라

다이어그램에서 복사-붙여넣기는 코드에서도 그렇지만 좋지 않은 짓이다. 중복을 제거하는 기법이 있다. 수직적, 수평적 결합이 그것이다.

그림 12. 수평적 결합

수평적인 결합에서 수직 라인은 수평 라인을 만날 때까지 아래로 내려간다. 수평 라인의 실행 흐름은 왼쪽이나 오른쪽 중 하나의 방향을 가질 수 있다. 수평적인 결합은 실행 흐름이 수평 라인의 왼쪽으로 진행할 때만 허용된다. 이 생각 이면에 있는 사고는 간단하다. 독자가 위에서 내려올 때 수평 라인을 만나면 어디로 가야 하는지 생각하지 않아야 한다는 것이다. 항상 왼쪽으로 간다.

그림 13. 잘못된 수평 결합

규칙: 수평적인 결합이 발생하면 실행 흐름은 왼쪽으로 간다

그림 14. 수직적인 결합

유사한 한 방향 규칙이 수평적인 결합에도 적용된다. 위로 올라가면서 라인을 만나는 것은 금지된다.

규칙: 수평적인 결합이 발생한 이후 실행 흐름은 아래로 간다.

비슷하게 설명이 가능하다. 독자의 눈은 라인이 위로 올라가는지 내려가는지 알기 위해 전체 다이어그램을 이리 저리 옮겨 다니지 않아야 한다. 항상 아래 방향이다.

그림 15. 잘못된 수직 결합

어떤 라인도 교차해서는 안 된다!!!

전통적인 플로우차트는 라인과 화살표가 꼬인 거미줄처럼 빠르게 변하는 경향 때문에 미움을 받아왔다. 연결 선이 격자모양으로 밀집하면 다이어그램을 읽기가 소스 코드 보다 어려워 진다. 이것이 알고리즘을 설명하기 위해 의사코드pseudocode를 선호하는 프로그래머가 다이어그램을 홀대하는지에 대한 이유이다. 라인 교차는 다이어그램이 어지러워지는 주요 이유이다.

규칙: 라인 교차와 라인 끊김break은 금지된다.

모든 종류의 라인 교차는 인체공학적으로 좋지 못해 금지된다. 명확성을 위해 DRAKON은 불필요한 상세함과 시각적인 노이즈를 배제한다.

교차점을 금지하면 심각한 위상의topological 제약을 가져온다. 이렇게 되면 복잡한 실생활의 알고리즘을 표현하는데 제약이 될까? 아니다. DRAKON이 라인 교차 없이도 어떤 알고리즘이든 표현할 수 있다는 점이 수학적으로 증명되어 있다.
만일 특정 다이어그램이 규칙을 위배한다면, 우리는 다음의 순서로 규칙의 우선순위를 조정할 수 있다.

1. 항상 DRAKON의 기본 규칙을 따른다. 즉, 라인 교차는 허용하지 않으며, If 아이콘의 왼편에는 종료가 있어서는 안 된다 와 같은 것들이다.
2. 주 경로 규칙을 따른다.
3. 연결 선에 모서리 수를 최소화 한다.
4. 수직 라인의 수를 최소화 한다.

비록 인체공학 규칙을 위배하는 비용 때문에 다이어그램 상의 요소들을 줄이려는 유혹이 있지만, 결코 그런 일은 일어나서는 안 된다.

삽입 아이콘

소프트웨어에서 서브루틴은 두 가지 역할을 한다.

1. 단일 프로그램 내에서 코드 재사용. 서브루틴은 프로그램의 여러 부분에서 호출될 수 있는, 이름을 가진 코드 조각이다.
2. 논리적인 알고리즘의 분해. 일부 코드가 단 한 곳에서만 호출되더라도 여전히 서브루틴으로 분리하는 것이 합당하다. 서브루틴의 이름은 그 코드가 하는 일을 설명해야 한다.

삽입 아이콘은 서브루틴처럼 다른 DRAKON 다이어그램을 호출하는데 사용하는 표기법이다.

그림 16. 삽입 아이콘

For Loop

For 회전은 Loop의 가장 깔끔한 형태이다. For 아이콘은 다른 프로그래밍 언어에서 for 나 foreach 키워드와 유사하다. For 아이콘은 실제로는 두 개의 아이콘으로 Begin For와 End For로 구성된다. For 아이콘을 사용하는 일반적인 시나리오는 다음과 같다.

1. 컬렉션을 반복한다. foreach (var item in megaList)
2. 카운터 기반의 루프. for (int = 0; i < length; i++)

여러 번 실행되는 코드는 Begin For와 End For 사이에 놓여진 아이콘들로 표현된다. For 루프를 들어가고 나가는 규칙은 다음과 같다.

1. Begin For는 루프 바디에 들어가는 단 하나의 출구이다.
2. 여러 가지 변종들이 있을 수 있는데, 루프 바디에서 바로 나갈 수 있다.

바로 나가기는 If 나 Switch 같은 조건 아이콘에서 발생한다.

그림 17. For Loop

그림 18. For Loop는 단 하나의 입구만 있지만 출구는 여러 개가 될 수 있다.

While, Do-Until, 하이브리드 Loops

때때로 어떤 조건이 유지될 때까지 액션을 수행하고 싶을 때가 있다. 이런 경우 If 아이콘을 기반으로 한 간단한 루프가 좋은 선택이다. 언제 For 루프보다 If 루프를 써야 할까?

• 컬렉션을 반복하거나 카운터의 사용이 명시적이지 않을 때
• 명확히 정의된 반복단계인 2의 배수를 반복할 때. 즉, 종료 조건에 액션과 체크가 있을 때

If 아이콘은 세 가지 방법으로 루프를 구성할 수 있다.

1. 질문 - 액션. 프로그래밍 언어에서 while 루프와 유사하다.
2. 액션 - 질문. do-until 루프와 유사하다.
3. 액션 - 질문 - 액션. 하이브리드 루프로 불린다.

루프는 위쪽으로의 라인 연결 상황이라는 점을 기억한다. 위를 가리키는 라인은 화살표를 가지는 라인으로써는 DRAKON에서 유일한 예외이다. Branch 내의 모든 화살표는 루프를 표현한다. 다른 모든 라인은 화살표를 가지지 않는데, 화살표의 과도한 사용은 불필요한 그래프 복잡도를 증가시키기 때문이다.

그림 19. 루프 기반의 If 아이콘

위로 올라가는 라인은 DRAKON에서 특별하며 그들이 아이콘을 가지지는 않는다.

규칙: 위로 올라가거나 옆으로 가는 라인에는 어떤 아이콘도 두지 않는다.

이것은 아주 중요한 DRAKON에서의 원리이다. 다음 아이콘은 현재 실행 지점보다 아래에 존재한다. 화살표는 어떤 아이콘 위로 실행 지점이 이동해 가는 데만 사용한다.

규칙: 화살표는 아이콘을 가리키지 않는다. 화살표는 내려가는 라인만을 가리킨다.

그림 20. 루프 화살표의 잘못된 / 올바른 사용법

중첩된 루프와 진입하자 마자 나가는 루프

텍스트로 루프를 프로그래밍하는 것은 강력한 방식이지만, 위험한 습관이다. 전통적인 텍스트 기반의 루프 표현은 몇 가지 약점을 가지고 있다.

• 많은 언어에서 발견되는 for 와 while 프로그래밍은 종료를 위해서 루프 조건이 false를 리턴 하도록 강요한다. 이것은 임의적인 제약으로 프로그래머가 NotDone이나 불필요한 Not 연산자 같은 직관적이지 않은 식별자를 쓰도록 한다.
• 중첩 루프를 빠져나갈 때 루프의 어느 부분에서 멈추는지 추적을 어렵게 한다.

위의 문제 어느 것도 DRAKON에는 적용하지 않았다.

DRAKON은 프로그램의 흐름이 어떤 루프 조합이나 if 구문에서도 명확하다. 알고리즘이 얼마나 복잡하든 간에 다음 번에 어떤 아이콘이 실행될지 항상 명확하다.

그림 21. 진입에서 빠져 나가는 중첩 루프. DRAKON과 의사코드의 비교

그림 22. 플로우차트와 DRAKON의 비교. 인체공학의 중요성.

Switch

If 아이콘은 “yes”나 “no”로 대답해야 하는 질문을 가진 경우 동작한다. 만일 그 질문에 또 다른 대답이 있다면, Switch 구문을 사용해야 한다. Switch 구문은 다음과 같이 구성된다.

1. 하나의 질문을 가진 하나의 Select 아이콘.
2. 그 질문에 대한 가능한 대답을 가진 두 개 또는 그 이상의 Case 아이콘

Case 아이콘에 질문을 배치할 때, DRAKON 규칙을 다시 고수한다.

• 주 경로는 꼬챙이 상에 위치해야 한다.
• 우측으로 멀어질수록, 더 좋지 않은 것이다.

한가지 대답이 다른 것보다 좋지 않을 경우, 우리는 왼쪽에서 오른쪽으로 오름차순에 의거한 Case 경로를 배치하기 위한 기준을 알아야 한다.
가장 우측에 있는 Case 아이콘은 비어있거나 아무 값이 없을 수도 있다. 이 아이콘은 다른 모든 값들을 의미하고, 다른 언어에서 쓰는 switch 구문의 default 절과 유사하다.

그림 23. Switch 구조

Case 아이콘은 Select 아이콘 뒤에 곧바로 나와야 한다.

규칙: Select 아이콘과 Case 아이콘 사이에 어떤 아이콘이나 연결이 있어서는 안 된다.

그림 24. Switch 에러

가장 우측에 있는 Case 아이콘은 Case 아이콘 위에 있는 어떤 부분을 가리키거나 회돌이cycle를 만든다. 이 구조는 Switch 루프라 부른다.

그림 25. Switch 루프

Branch 루프

한 Branch의 작업이 완료된 후 제어권은 Address 아이콘에 의해 다음 Branch로 이동한다. 기술적으로, Address 아이콘은 다이어그램 상의 다른 Branch의 이름을 가지고 있지만, Branch 규칙은 호출할 다음 번 Branch가 우측에 있는 다음 Branch라는 것을 말해준다.
다음의 예외는 있다.

1. 몇몇 Branch 들은 If 나 Switch 구조가 그렇게 하도록 정한 경우 생략될 수 있다.
2. 다음 번 Branch는 같은 Branch이거나 의도적으로 액션을 반복하고자 하는 경우 왼쪽에 있는 Branch 일 수도 있다.

후자의 경우 Branch loop라고 불린다. 다른 루프들처럼 Branch loop 또한 다수의 종료를 가질 수 있다.
Branch loop를 사용하는 일반적인 경우 중 하나는 반복적으로 호출되는 하나의 Branch를 다른 루핑 구조가 감싸는 중첩 루프를 형성하는 것이다.

그림 26. Branch loop

Address 아이콘은 특별한 표시가 되어야 하는 루프를 만들어 낸다. 이 표시는 또 루프 바디의 시작 부분에 있는 Branch에도 표시되어야 한다.

로직 표현

DRAKON은 두 가지 방식의 로직 표현을 지원한다. 하나는 텍스트형이고 하나는 시각형이다. 텍스트형 방식에서는 관례적인 프로그래밍 언어에서처럼 If 아이콘 내에 전체 표현식을 적는다. 이 방법은 추천되지 않는다.
시각적인 방식은 다음의 두 단계를 거친다.

1. 복잡한 로직 표현식의 각각의 단위 오퍼랜드를 개별 If 아이콘으로 바꾸어 놓는다.
2. 최종 결과와 오퍼랜드의 평가 순서가 동일하도록 If 아이콘들을 연결한다.

그림 27. 텍스트형과 시각적인 로직 공식

이러한 시각적인 공식은 사용하기 편하고 쉽게 인식할 수 있는 패턴을 형성한다.

규칙: AND는 if 아이콘을 꼬챙이 상에 놓고, OR는 if 아이콘을 계단식으로 정렬한다.

yes 종료는 가능한 꼬챙이에 가깝게 배치해야 하며, no 종료는 우측으로 가야 한다. 다른 방식으로 돌아가는 것은 허용되지만 추천하지 않는데, 독자에게 혼동을 주고 패턴을 깨뜨리기 때문이다.

그림 28. 시각적인 로직 패턴을 깨뜨리지 말라

로직 표현식을 적는 시각적인 방식은 이해와 디버깅이 어렵다. 왜냐하면, 아주 짧은 문장 안에 대단히 많은 발생 가능한 결과들을 숨겨두기 때문이다.

로직 표현의 평가에서 이른바 짧은 회로 평가short-circuit evaluation는 문제에 어려움을 가중시킨다. 많은 프로그래밍 언어들이 이 기법을 사용한다. 이것은 출력이 왼쪽 오퍼랜드에만 결부되어 있으면, 표현의 우측 오퍼랜드는 평가하지 않는 것이다.

willBuy = LooksCool (gadget) and not TooExpensive (gadget)

이 예제에서 그 기계장치가 멋져 보이지 않으면 우측 오퍼랜드 (not TooExpensive (gadget))는 계산될 필요가 없다. 어쨌든 우리는 사지 않을 것이다.
짧은 회로 평가는 알고리즘에 묵시적이며 보이지 않는 경로들을 추가한다.
DRAKON은 명시적이고 명확한 방식으로 모든 발생 가능한 실행 경로들을 나타내줌으로써 상당한 장점을 가지고 있다.

그림 29. 시각적인 로직 공식의 이점

로직을 표현하는 시각적인 방식에서는 NOT 오퍼랜드를 사용할 필요가 없다는 점을 주의 깊게 보라. 모든 필요한 효과는 If 아이콘에 있는 yes와 no를 서로 바꿈으로써 만들 수 있다.

그림 30. DRAKON은 복잡한 로직 공식을 쉬운 방법으로 표현한다.

로우 레벨 DRAKON과 실시간 오퍼레이터

지금까지 언급한 언어는 DRAKON의 하이 레벨 버전이다. 이것은 대부분 문서화를 의도하거나 사람이 읽는 경우를 목적하고 있다.
프로그램을 만드는데 사용할 수 있는 모든 상세함을 가진 DRAKON의 다른 로우 레벨 버전이 있다. 이 버전은 DRAKON-2로 불리며, DRAKON-2의 아이콘은 텍스트가 아닌 C++이나 Java 같은 공식적인 프로그래밍 언어의 구문을 담고 있다.
할당과 메소드 호출은 일반적인 방식으로 구현되어 있지만, 흐름 제어는 DRAKON 다이어그램의 개요가 대신 쓰인다. 다이어그램이 빌드되는 시간에 소스 파일로 변환되고 이후에 컴파일 될 수 있다.
DRAKON-2는 타이머, 동시성concurrency, 쓰레딩과 입-출력을 지원하는 이른바 실시간 오퍼레이터를 가지고 있다.

요약

1. DRAKON은 빠르고 쉬운 이해를 목적으로 한다.
2. DRAKON은 독자가 가장 중요한 것을 먼저 보도록 해준다.
3. DRAKON은 명확성을 보장하기 위해 상세화에 대단히 신경을 많이 쓴다.
4. DRAKON은 루프를 표현하는데 있어 알려진 최고의 방식이다.
5. DRAKON은 로직 공식을 설명하는데 탁월하다.
6. DRAKON은 실제 프로그래밍을 위해 실시간 확장을 가지고 있다.

.Fin.