2008년 3월 17일 월요일

프로그램 그려보기

김진애님의 자기 집을 그려보자 라는 글을 보면서 문득 소프트웨어를 설계할 때도 사용할 수 있는 방법이다 라는 생각이 들었습니다. 제가 관심을 가지게 된 부분은 이 부분인데요.

주택을 설계할 때면 나는 집주인을 유혹하곤 한다. 같이 그려 봅시다 하고. 직업상 나는 남들이 말로 표현하는 것 또는 몸으로 표현하는 것을 잘 파악해서 그림으로 그려 내는 사람이지만 살 사람의 마음 깊은 속, 심리 깊은 속까지 들어가기란 그리 쉽지 않다. 이럴 때 집주인이 뭔가 그려 주면 훨씬 더 가깝게 짐작할 수 있다. 힌트가 풍성해지는 것이다.집주인은 쑥스러워들 한다. “못 그려요.” 그려 보고 나서는 “그리기 만만치 않데.” 하기도 한다. 내가 권하는 것은 건물의 형태나 전체의 구성은 아니다. 이것은 아무래도 어려운 일이고 전문적인 훈련이 필요하기 때문이다. 권하는 것은,

주로 집 내부의 가구 배치, 컴퓨터 배치, 텔레비전 배치 같은 것들이다. 전문가인 나보다도 집주인이 훨씬 더 잘 아는 물품들, 습관들, 선호도가 나타나는 항목들이다.



그러니까 집을 설계할 때 집주인과 함께 그가 정말 원했던 것을 알아가는 과정의 일종으로 좀 더 직관적으로 생각할 수 있는 집의 내부 같은 부분을 그린다. 라는 것인데요. 이 과정의 진정한 가치는 집주인이 단순히 자신이 생각했던 것을 그림으로 표현해서 건축가에게 전달하는게 아니라, 그림을 그리는 과정을 통해서 자신이 인식하고 있지 않았던 혹은 자신도 몰랐던 원했던 것을 발견할 수 있다는데 있는거죠. 그리고 그런걸 발견하지 못할 수도 있지만 집을 짓는 과정의 초반부터 참여하는 것은 집을 짓는 다는 일종의 프로젝트에 대한 참여도와 소속감을 높일 수 있을 것 같구요. 뭐, 물론 이 경우는 자신의 집을 짓는 것이지 당연히 그런게 높겠지만 말이죠.

이제 프로젝트 설계에 적용을 해볼까요?


클라이언트와 회의를 할 때, 그들이 원하는 요구사항을 추출해내는 것이 결코 쉬운게 아니죠. 그렇기 때문에 요구사항에 관련된 서적들 만 해도 몇 권씩 되기도 하는 거구요. 그런데 그런 요구사항을 알기위한 보조적인 방법으로 위와 같은 방법을 사용해보면 어떨까요? 사실 많은 프로젝트에서 대부분 사용자나 클라이언트측의 담당자도 자신들이 원하는 프로그램을 정확히 파악하고 있지 못하는 경우가 많거든요. "이런 이런 형태의 프로그램을 만들어 주세요" 혹은 "이런 기능을 포함하는 프로그램을 만들어 주세요" 라고 이야기를 하지만 프로젝트를 진행하다보면 "이런 기능을 더 추가해야 겠는데요" 라거나 "그 기능은 별로 필요가 없을 것 같네요" 라는 정도의 말을 자주 듣게 되요. 물론, 고마울 정도로 클라이언트 측에서 계획을 잘 세워서 오는 경우도 있기는 하지만, 그렇게 많지는 않죠.

그럼 실제로 그림을 그리는 방법을 어떻게 응용해볼 수 있을까요?


우선 클라이언트와 앉아서 프로그램에서 핵심적인 기능들을 추려보는 거에요. 아마도 그렇게 추려진 기능들은 요구사항이 제대로 추출되지 않았다면 제작후에도 수정을 할 가능성이 많은 부분이겠죠. 그렇게 추려진 기능들을 종이에 한번 그려보도록 유도하는 거에요. 실제 모니터 화면에서 자신이 보게될 화면을 그려보도록 하는거죠. 전체 화면을 그리도록 하고, 특정 기능들을 실행되는 과정을 그림으로 그려보는 거에요. 이런 과정을 통해서 단순히 원하는 요구사항 목록을 뽑는게 아니라 클라이언트가 선호하는 화면구성, 중요요소, 실행과정 같은 걸 알 수 있는 힌트를 얻을 수 있는 겁니다.

CRC(Class-Responsible-Collaboration) Card 라는 소프트웨어 디자인(코드의 설계를 이야기하는 거죠)을 위한 기법이 있는데요. 간단하게 설명하면 인덱스 카드 정도의 종이에다가 3등분을 하여(좁은 가로줄 아래로 등분하는 세로줄을 그리는거죠) 상단에는 클래스의 이름을 하단 왼쪽에는 그 클래스가 해야할 일들을 오른쪽에는 그 클래스와 연관된 클래스의 이름을 적는거죠. 그렇게 프로그램에서 구현된 클래스들을 실제 한장의 카드로 만들어 보는 과정을 통해서 실제로 어떤 클래스들이 만들어 질지 미리 예측을 해볼 수가 있는데요. 그렇게 만든 클래스 카드를 프로그램의 특정 기능을 동작시키는데 사용해보는거죠. 예를 들어 장바구니에 물건을 넣는다고 하고, 장바구니, 물건, 사용자 같은 클래스가 있다고 생각하는거죠. 그러면 물건을 넣는 기능을 그 카드들을 배열해보면서 동작시키는거에요. 물건을 보는 화면에서 장바구니를 클릭하면 물건.물건정보() 같은 메쏘드가 호출이 될 것이고 물건.고유번호() 를 사용자.장바구니얻기() 해서 얻은 장바구니에 장바구니.추가() 같은 방식으로 넣는다. 뭐, 이렇게 꼭 되진 않겠지만 카드를 이리저리 배열해보면서 구성을 하는거죠. 여러명의 개발자가 같이 하고 있었다면 일종의 롤플레잉 게임처럼 각자 나누어 클래스를 담당하고 어떤 기능을 정하고 각자 필요한 부분에서 카드를 내거나 설명을 해요.

이런 방식들로 사용될 수 있는데, 다시 본론으로 돌아가보죠. 그림을 그리는 작업도 어쩌면 CRC카드 처럼 아직 우리가 눈으로 볼 수 없는 것들을 미리 볼 수 있게 해주는 작업일겁니다. 생각만 했는데 실제로 보니 다른 점들이 보이고 하는거겠죠. 그리고 실제로 보니 이런 저런 부분이 바뀌었으면 하는 부분도 있을 테구요.

흠.. 결론은 백번 들어도 한번 보는 것만 못하다 정도가 될 수 있을려나요? :-)

댓글 없음:

댓글 쓰기

Man of Month를 마치며

벌써 2020년 1월 14일이다. 19년의 마지막 달에 Man of Month라는 팀의 제도를 시작한다고 했었는데, 12월이 지나고 그 다음 달도 거의 절반이 흐른 것이다. MoM을 시작하면서 하겠다고 계획했던 것들도 실제 한 것들과 비교해보니...