인간 시뮬레이터

참고글
http://tapm.blogspot.com/2007/03/2-1.html : 인지적 견해: 소프트웨어 설계를 보는 다른 시각

제가 처음 컴퓨터를 배울때 바로 BASIC을 배웠습니다만 컴퓨터는 없이 문법을 설명하는 책 한권과 노트가 주어졌을 뿐입니다. BASIC이 어떻게 수행되는지 책은 저에게 설명해 주고 있었지만 그것을 돌려볼 수 있는 컴퓨터는 없었습니다. 그래서 전 제 스스로가 컴퓨터가 되기로 하였죠. 86년도에는 다행이 요즘처럼 그렇게 복잡한 개발환경을 요구하지도 않았고 초등학교 2학년생이 그런 프로그램을 작성할리도 없었기에 노트에 적혀진 BASIC 코드를 따라가는 것은 그리 어려운 작업은 아니었습니다. 89년도에 GW-BASIC을 배울때도 학원에서 일부러 진도를 느리게 만들려고 했는지는 모르겠습니다만 일단 순서도(Flow Chart)를 그리고 노트에 코드를 적어서 선생님에게 검사를 맞고 나서야 컴퓨터를 켜고 입력해 볼 수 있었습니다. 이런 짓을 오랫동안 하다 보니 한페이지 정도의 프로그램을 화면에 띄워 두고 눈으로 돌려보는 것은 그렇게 어려운 작업은 아닌 것 같습니다.

Tistory의 경우 개발된 코드가 최종적으로 적용되기 위해선, 심지어 스킨들도 QA과정을 거칩니다. 이 과정은 현재 주로 제가 담당하고 있습니다. 업데이트 계획이 수립되고 적용 코드의 검증이 시작되면 적용범위가 저에게 통보되고 저는 형상관리 프로그램(현재 TnC는 SubVersion을 사용중입니다.)의 도움으로 정확히 적용되는 변화를 볼 수 있습니다. 실제로 인풋을 넣어보는 테스트도 하겠지만 그전에 눈으로 변화 코드를 추적하면서 많은 부분을 확인하거나 이후 테스트 대상들을 확인할 수 있습니다. 여러가지 코드 검증방법이 있습니다만 눈으로 코드를 돌려보면서 검증하는 이 테스트는 일종의 White Box 테스트이기에 테스터의 능력에 따라서는 많은 부분을 쉽고 정확히 검증할 수 있습니다.(물론 사람이 하는 작업이기에 이를 보완하기 위한 전통적이고 자동화된 테스팅들이 반드시 보충이 되어야 합니다. 더불어 기존의 테스팅이 찾아내지 못하는 부분을 인간의 지성으로 찾아내는, 보완적인 방법의 특성도 있습니다.)

최근에 이런 작업을 좀더 확장 시키고 있습니다. 우선 Analysis라 불리는 작업들부터 언급해야 할 것입니다. 코딩전에 Requirement 정의나 System Architecturng등의 High Level Design 등 코딩이 없는 작업에서 일종의 디버깅 차원에서 Analysis 작업을 합니다. 그리고 최근의 Prototype을 사용한 개발방법론등을 짬뽕시켜 볼때, 프로토타입 이전부터 시스템의 디버깅이 가능하다고 보고 있으며 가령 Requirement 작업중에도 디버깅은 가능하다는 것입니다. 바로! "머리속으로 시스템 돌리기" 되겠습니다.

디버깅이라는 것이 일단 구현된 시스템이 나와야 할 수 있다고 보기 쉽습니다만 Prototype은 그것을 코딩 전에 구라 시스템(^^)을 만들어서 시도해 봅니다. 더불어 시스템이라 부를 뭔가가 나오기 전에도 인간의 상상력은 대단해서 머리속에서 그 뭔가를 만들어 볼 수 있고 역시 디버깅이 가능합니다. Requirement의 R자만 나와도 바로 확인이 가능하다는 것입니다. 이것이 중요한 것은 역시나 문제점은 빨리 찾을수록 수정 비용이 적기 때문이겠죠. 더구나 처음 시스템의 형태를 잡을때의 실수 하나는 프로젝트 자체를 취소하게 하는 요인도 될 수 있기 때문에 더더욱 중요한 부분일 것입니다.

Prototype은 개발 프로세스와는 거리가 먼 고객을 상대로 할때 쓸만한 방법입니다만 개발과정에서 그정도 단계면 상당히 멀리 왔을 때라고 보입니다. 그 이전에 Requirement 후보 리스트만 나왔을 때 부터 참여자들은 돌려볼 수 있고 현재까지 확정된 것들로 구현하고자 하는 무엇인가를 확인할 수 있습니다. 여기서 중요한 것은 역시 아직 정해지지 않은 부분은 그대로 둔다라는 것입니다. 현재의 상태에서는 그 부분은 중요하지 않거나, 중요하다면 다음에는 그 부분을 좀더 보강해서 디버깅을 해야 하겠다라고 알 수 있습니다. 그리고 현재 나열된 것들에 대해서는 이미 검증(디버깅)을 할 수 있습니다.

위의 링크에 걸린 글 마지막부에 보면 마음속으로 시스템을 돌려본다라는 말이 있지만 요즘의 시스템들은 머리속에 다 우겨넣고 돌리기엔 좀 규모가 큰 것 같습니다. 뭐 대가분들의 메모리와 시피유는 성능이 좋아서 가능하신것 같습니다만 담배와 술로 일부가 맛이간 저로서는 역시 화이트 보드가 최고인 것 같습니다. 전에는 화이트 보드와 보드마커만으로 했습니다만 최근에 본 다른 방법들의 영향을 받아 포스티잇을 통해 디테일한 기술을 하고 있습니다. 당장은 디테일 레벨이 맞지 않지만 나중에 쓸만한 거라던가 흐름의 코멘트에 사용중입니다.

이번에 디버깅중인 시스템

보안상(?) 대부분의 내용은 모자익 처리했습니다만 현재까지 받은 인풋만을 가지고 시뮬레이션&디버깅 해 본것입니다. 저 작업은 혼자 하였습니다만 일이 진행되고 사이즈가 커지면 혼자 할 수도 없고 다들 땀 뻘뻘 흘리면서 타올라봐야 겠죠.

최근에 저도 역시 실제 코딩을 시작하는 것은 매우 느려지고 있습니다. 아니 설계도라던가 상세 설계의 시작도 역시 상위의 것들이 맘에 들어야(?) 시작할 수 있게 되더군요.

PS.
광고는 아닙니다만, 보드마커는 역시 스테XX 제품이 짱!