[본문스크랩] 인간과 컴퓨터의 만남 HCI 2회

2372816 [본문스크랩] 인간과 컴퓨터의 만남 HCI 2회 2372820 2008-12-23T15:06:48Z http://cratia21.springnote.com/pages/2372816 2008-12-23T15:06:48Z <div class="post-view pcol2" id="post-view"> 출처 : <a href="http://www.sisait.co.kr/199908/solution/218.htm" class="con_link">http://www.sisait.co.kr/199908/solution/218.htm</a><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />   휴먼 컴퓨터 인터렉션과 인터페이스   좋은 인터페이스?나쁜 인터페이스 사례연구 '클래스룸 2000 프로젝트'   <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />김성우/ 미국 죠지아텍 석사과정. 정보 설계 및 기술 전공(우) gte508k@prism.gatech.edu 이정환/ 미국 죠지아텍 GVU 연구소의 가상환경그룹 연구원(좌)   지난 호에서는 HCI란 어떠한 분야인지 살펴보았고, 인터페이스의 발전사에 대해서도 알아보았다. 이번 호에서는 좋은 인터페이스란 어떤 것이며, 좋은 인터페이스를 개발하는 과정에 대해 소개하고자 한다. 자세한 인터페이스 개발 방법이나 튜토리얼식의 설명은 피하고, 좋은 인터페이스 설계에 대한 설명과는 별도로 HCI 분야의 하나의 사례 연구로서 죠지아텍의 클래스룸 2000 프로젝트에 대해서도 소개한다.<편집자주> 좋은 인터페이스? 나쁜 인터페이스 ?   우선 좋은 인터페이스는 어떤 것이고 이와 대조되는 나쁜 인터페이스는 어떤 것인지를 정의한다. 일반적으로 생각하는 좋은 인터페이스의 조건은 무엇일까? 다음은 좋은 인터페이스의 몇 가지 조건들이다.   - 사용하기 쉬워 보여야 한다.   사용하기 쉬울지 아닐지를 떠나 일단 쉬워 보여야 한다. 첫 대면부터 사용자의 기를 죽이는 인터페이스는 좋은 인터페이스가 아니다.   - 사용자가 예상하는 대로 반응할 수 있도록 설계돼야 한다.   사진 1은 버튼을 가지고 있는 일반 계산기이다. 사용자들이 이 계산기의 버튼을 볼 때 이 버튼들은 눌려져야 작동한다는 것을 쉽게 예상할 수 있다. 이 버튼을 보면서 버튼들을 위로 들어 올려야 작동할 것이라고 생각하는 사용자들은 거의 없을 것이다.   마찬가지로 사진 2에서 사용자들은 이 죠이스틱을 보면서 막대 부분을 붙잡고 상하좌우로 움직이면 화면의 무엇인가도 같은 방향으로 움직일 것이라고 예상할 것이다. 죠이스틱의 막대 부분을 부러뜨린다던가 잡아 빼야 어떤 작동을 할 것이라고 생각하는 사용자들은 거의 없을 것이다.   즉 버튼은 처음부터 눌러야 작동할 것처럼 보이고 마찬가지로 죠이스틱의 막대는 이를 잡고 상하좌우로 흔들어야 작동할 것으로 예상된다. 이처럼 그 외형을 볼 때부터 사용자가 어떻게 사용해야 하는지 쉽게 판단 할 수 있도록 인터페이스가 설계돼야 한다. 이를 visual affordance라고 말한다.    [##_1C|hk73.jpg|width="117" height="187"|_##]  [##_1C|hk74.jpg|width="140" height="138"|_##]  [##_1C|jk60.jpg|width="150" height="209"|_##]                        계산기                       죠이스틱                          돈 노먼     - 서로 구분이 잘 돼야 한다.   글쓴이의 기숙사 엘리베이터는 문열기 버튼과 문닫기 버튼이 같은 모양인데다가 색깔도 같은 검정색으로 칠해져 있고, 비록 버튼에 ><(문열기)와 <>(문닫기)와 같은 아이콘이 그려져 있기는 하나 검정색 바탕에 회색으로 그려져 있어 금방 드러나지 않는다. 또한 허리 정도의 높이에 버튼이 위치하고 있어 위에서 아래로 쳐다보아야 하므로 그 보는 각도로 인해 두 버튼이 쉽게 구분이 가지 않는다. 즉 많은 기숙사 거주자들이 그 버튼을 혼동하지 않도록 대조적인 기능을 가진 두 버튼은 확고하게 구분이 갈 수 있도록 설계해야 한다.   -사용자의 기억력에 호소하지 말아야 한다.   앞서 말한 엘리베이터 버튼의 경우 "오른쪽 버튼은 문닫기 버튼이고 왼쪽 버튼은 문열기 버튼이다"라고 기억을 해 두면 특별히 문제가 없을 것 같다. 그러나 사용자에게 쓸데없이 사용법을 기억하도록 강요하는 인터페이스 설계는 설계 자체가 틀린 것이다.   - 중요한 부분은 눈에 띄도록 한다.   중요한 기능이나 사용자의 작업을 망칠 수 있는 위험을 내포한 인터페이스는 확실하게 눈에 띄게 해야 한다. 좋은 예로 오디오 테입 레코더의 녹음 버튼이 빨간색으로 돼 있는 것을 들 수 있다.   - 피드백이 있어야 하며, 상황에 맞는 피드백을 주어야 한다.   어떤 버튼을 눌렀을 때 빛이 들어온다던가 소리가 나는 것은 그 버튼이 작동됐음을 사용자에게 확신시켜 준다. 이와 같이 인터페이스는 사용자에게 적절한 피드백을 주어야 한다. 그러나 피드백도 아무렇게나 주어지면 안된다.   예를 들어 신호등이 "등"인 이유와 경적이 "경적"인 이유는 상황에 맞는 피드백을 주기 위한 것이다. 사용자가 잘 볼 수 없는 상황에서는 소리로 알려 주고 잘 들을 수 없는 상황에서는 빛으로 알려주듯 상황에 맞는 피드백을 주어야 한다. 소리나 빛과 같은 반응 방식(매체)의 적절한 선택만이 아니라 사용자의 조작에 대해 어떠한 반응과 그에 해당하는 정보를 얼마만큼 주어야 하는지도 고려해야 한다. 정보가 너무 부족한 것과 너무 많은 정보를 주어 사용자의 머리를 혼란스럽게 하는 것은 좋은 인터페이스가 아니다. - 일관성이 있어야 한다.   똑같은 버튼이 어느 경우에는 이렇게 작동하고 어느 경우에는 저렇게 작동하면 사용자에게 혼동을 줄뿐이다. 가능한 일관성을 유지해야 한다.   - 아주 획기적이지 않는 한 기존 인터페이스의 룰을 따른다   사람은 이전의 경험을 바탕으로 새로운 것을 다루려고 한다. 아주 획기적으로 뛰어난 인터페이스라 기존의 모든 문제점을 완전히 극복하고 사용자로 하여금 "이거 정말 편하다"라는 감탄사가 저절로 나올 정도가 아니라면, 기존의 비슷한 인터페이스에서 너무 크게 벗어나게 만드는 것은 자제해야 한다.   즉 사용자에게 친근감을 주고, 사용법이 한눈에 쉽게 들어오며, 조작에 대한 반응이 적절한 인터페이스가 좋은 인터페이스이다. 지난 호에서 언급하였듯이 제일 중요한 것은 바로 사용자이다. 사용자 위주의 인간 중심으로 인터페이스가 설계가 이루어져야 하는 것이 가장 중요한 원칙이다. HCI 관련 분야에 심리학이나 인류학, 사회학 등이 포함돼 있는 것이 인간부터 알아야 인간 중심의 시스템이 나올 수 있기 때문이다.   인간 공학에 관심이 있는 이들은 도날드 노먼(Donald A. Norman)이라는 이름을 한번쯤은 들어보았을 것이다(사진 3). 노먼은 인간 중심적인 기술 설계를 오래 전부터 주장해 온 그 분야에서 가장 권위를 갖춘 전문가이다. 최근의 저서인 "The Invisible Computer"에서 "컴퓨터 제품은 아직도 기술 중심적으로 개발되고 있다. 사용자와 사용자가 하려는 작업을 위한 제품 개발로 개발 과정이 바뀌어야 한다"라고 주장한다.   노먼의 인간 중심적인 제품의 개발이란 기술보다는 사용자와 사용자가 필요하다고 느끼는 것에서부터 시작하는 제품 개발 과정을 의미한다. 최종 목표는 사용자를 만족시키는 기술이고, 이 기술은 사용자가 하려는 작업에 잘 맞아야 하며 여러 복잡다단한 사항은 작업 자체에 있어야 하지 작업 도구에 있어서는 안 된다. 즉 이러한 인간 중심적인 제품의 개발에 핵심 역할을 하는 것은 사용자와 사용자가 하고자 하는 작업을 잘 이해하고 있는 개발자들이다.   invisible" 또는 "transparent"는 HCI 분야에서 "interaction"과 함께 큰 무게를 가지고 있는 단어이다. 즉 컴퓨터는 인간과 인간이 하려는 작업의 중간 매체로서 작업 목적을 위한 하나의 수단에 불과하며 따라서 사용자로부터 가려지거나 안보여질수록(즉 수단 자체가 일이 되지 않을수록) 좋다는 것을 의미한다.   좋은 인터페이스에 대한 관찰은 주위에서부터 당장 시작할 수 있다. 컴퓨터 관련 제품뿐만 아니라 어떤 물건이든 인터페이스라는 것이 따라오기 마련이므로 주위의 물건들의 인터페이스를 평가해 볼 수 있는 것이다. 지금부터는 주위에 있는 물건 몇 개의 인터페이스를 함께 분석해 보기로 한다.   - 책   일반적으로 책은 오른쪽에서 왼쪽으로 페이지를 넘기게 돼 있다. 이는 우리가 글을 왼쪽에서 오른쪽으로 쓰는 데에서 비롯되었을 것이다. 한자로 쓰여진 옛 책들은 왼쪽에서 오른쪽으로 넘기는 구조를 가지고 있는데 이는 한자를 쓸 때 위에서 아래로 쓰면서 오른쪽에서 왼쪽으로 줄을 넘기기 때문이다. 우리가 책에서 가장 먼저 만나는 인터페이스는 오른쪽에서 왼쪽으로 페이지를 넘기는 구조이다.   책은 보통 가장 앞부분에 목차를 가지고 있고 그 다음에 실제 내용이 나온 다음 책의 종류에 따라 맨 마지막에 찾아보기(appendix)가 있다. 이 구조는 우리가 접하는 대부분의 책이 따르고 있는 인터페이스 구조이다. 이 구조를 위반하는 책들이 있는데 이를테면 잡지 중에 광고 페이지를 앞부분에 많이 싣고 목차를 광고 페이지들 중간에 넣어 두어 읽는 이들이 목차를 찾지 못해 이 페이지 저 페이지 넘겨보는 경우가 있다. 읽는 이들에게 광고를 한번이라도 더 보게 하는 상업적 효과를 노린 방법이겠지만 결코 좋은 인터페이스는 아니다. 교과서류 서적 중에 뒷부분에 찾아보기가 없는 책 역시 전형적인 책의 인터페이스 규칙을 위배한 경우이다.   - 뚜껑이 회전하는 휴지통   뚜껑이 회전하는 휴지통은 휴지를 버릴 때 뚜껑이 회전해 열렸다가 자동으로 닫혀 외관상 좋으며 냄새 등을 막아 주는 장점을 가지고 있다. 뚜껑은 360도로 회전이 되므로 앞이나 뒤에서 버릴 수 있다. 나름대로 훌륭한 인터페이스이다. 그렇지만 단점이 없는 것은 아니다. 먼저 뚜껑이 회전해야만 휴지를 버릴 수 있으므로 손으로 뚜껑을 회전시켜 휴지를 버려야 한다. 즉 손에 닿는 거리 안에서만 휴지를 버릴 수 있다는 것이다. 이를테면 방 한쪽 구석에 이 휴지통을 두고 다른 한쪽 구석에서 휴지를 버리려고 할 때 휴지를 던져 넣기는 힘들다. 야구공처럼 휴지의 무게가 많이 나가 휴지가 뚜껑을 밀고 들어가지 않는 한 말이다. 또 하나의 문제는 뚜껑이 회전했을 때 열리는 공간보다 작은 휴지만 넣을 수 있다는 점이다. 종이 상자를 접어서 버리려고 할 때 그 크기는 뚜껑이 회전했을 때 열리는 공간보다 크면 뚜껑 자체를 치우고 종이 상자를 넣어야 한다. - 전자 손목 시계   이제 조금 복잡한 인터페이스를 살펴보자. 글쓴이가 차고 있는 전자 손목 시계(그림 5)는 시간1, 전화번호부, 5개의 알람 예약, 시간2, 타이머 및 스톱워치 기능을 가지고 있다. 시간1과 시간2란 이를테면 죠지아텍이 위치한 애틀란타의 시간과 서울의 시간을 따로 표시할 수 있는 기능(dual time)이다.   이 전자 손목 시계의 인터페이스를 자세하게 분석한다면 그것만으로도 한 회 분량의 글이 나올 것이므로 지면상 간략하게만 살펴보겠다. 먼저 메뉴 버튼부터 보자. 시계의 왼쪽 하단에 있는 이 버튼은 시간1 -> 전화번호부 -> 알람 -> 시간2 -> 타이머 -> 스톱워치 순서로 기능을 바꾼다. 한쪽으로만 진행하기 때문에 버튼을 잘못 눌러 원하는 기능을 지나쳤다면 다시 돌아오는 수밖에 없다. 이를테면 알람을 선택하려고 했는데 한번 더 눌러 시간2가 선택이 되었으면 5번을 더 눌러 다시 알람으로 돌아와야 하는 것이다. 메뉴 버튼 상단에는 ADJUST 버튼이 있는데 이는 시간을 바꾸거나 전화번호를 바꾸는 등 세팅을 변경할 때 사용하는 버튼이다. 시계 중간 아래 부분에 있는 REVERSE 및 FORWARD 버튼은 선택된 메뉴에 따라 그 기능이 달라지기는 하지만 대체로 숫자 값을 증감시킬 때 사용한다. 알람 시간을 한번 바꿔 보자. 현재 이 손목 시계의 알람은 7시 30분으로 맞추어져 있는데 이를 8시 20분으로 바꿔 보도록 하자(참고로 사진 5의 시간은 알람이 아니라 사진을 찍던 당시의 시간이다). 먼저 메뉴 버튼을 두 번 눌러 알람으로 기능을 바꾼다. 여기서 버튼을 두 번 눌렀다는 점을 기록해 두자. 원래 이 시계는 총 5개의 알람을 세팅할 수 있는데 그것까지 고려하면 복잡해지므로 그냥 현재 시계 화면에 나온 알람을 바꾸는 것만 해보자. 이제 ADJUST 버튼을 누르면 세팅된 시간의 시(時) 부분이 깜박거린다. 7시에서 8시로 바꾸려면 FORWARD 버튼을 한번 누르면 된다. 지금까지 총 4번 버튼을 눌렀다. 이제 분을 바꿔보자. 분을 바꾸려면 커서를 분으로 옮겨야 한다. 메뉴 버튼을 한번 누르면 커서가 옮겨진다. 만약 실수로 메뉴 버튼을 두 번 눌렀으면 다시 분으로 커서가 올 때까지 계속 버튼을 눌러 줘야 한다. 실수가 없었다고 한다면 버튼을 누른 횟수는 총 5번이 된다. 30분에서 20분으로 바꾸려면 REVERSE 버튼을 10번 누르면 된다. 지금까지 총 15번 버튼을 눌렀다. 8시 20분으로 시간을 바꾸었으니 이제 다시 ADJUST 버튼을 눌러 새 값을 알람 시간으로 세팅한다. 알람 시간을 바꾸기 위해서 총 16번의 버튼을 눌러야 했다. 다른 버튼형 손목 시계에 비해 16번의 버튼을 누르는 것은 만족스러운 편이다.   이 시계는 대체로 간편한 인터페이스를 갖추고 있기는 하나 한가지 치명적인 실수를 범하고 있다. 다른 기능들에서는 REVERSE 버튼은 값을 감소시키고 FORWARD 버튼은 값을 증가시키는 일관성을 가지고 있는데, 유독 타이머에서는 이 일관성이 지켜지지 않는다는 것이다. 타이머에서 시간을 바꾸려면 다른 메뉴에서와 마찬가지로 ADJUST 버튼을 누르고 메인 메뉴 버튼을 눌러 시 또는 분으로 깜박이는 커서를 옮기는 것까지는 똑같은데 막상 값을 바꿀 때는 오직 FORWARD 버튼만을 사용해야 하고, REVERSE 버튼은 전혀 엉뚱하게 타이머 반복 기능의 유효/무효를 세팅하는 버튼으로 쓰이고 있다(사진6-1, 6-2). 사진6-1은 ADJUST 버튼을 눌러 타이머의 시간을 바꾸려는 순간이다. 커서는 현재 50에 가 있고 사진에서는 드러나지 않지만 50이라는 숫자가 깜박거리고 있다. 이때 REVERSE 버튼을 누르면 49로 숫자가 줄어드는 것이 아니라 사진 7의 동그라미 쳐진 부분처럼 모래시계 모양 같은 아이콘이 나타난다. 이 아이콘은 타이머가 다 끝나면 자동으로 반복할지를 세팅하는 아이콘이다.   이런 비일관성은 첫째로 REVERSE 버튼의 다른 기능에서의 역할에 익숙한 사용자에게 혼동을 주고, 두 번째로 0->60 또는 0->24로 한쪽으로만 값이 바뀌는 FORWARD 버튼만을 이용해서 세팅을 해야 하므로 실수로 버튼을 한번 더 누르면 완전히 한바퀴 돌아와 값을 다시 맞춰야 하는 불편함을 가지고 있다. 이를테면 45분으로 분의 값을 세팅하려고 했는데 실수로 한번 더 눌러 46분으로 세팅돼 버린 경우 46, 47, ...59, 60, 0, 1, 2, ... 순으로 무려 59번이나 FORWARD 버튼을 다시 눌러야 한다는 것이다. 회전하는 숫자가 3개나 5정도이면 큰 불편이 없으므로 조그만 손목 시계에 너무 많은 버튼을 주지 않기 위해서 이런 인터페이스를 쓸 수 있다. 실제 이 시계도 앞서 말한 바와 같이 Menu 버튼을 통해 기능을 바꾸도록 돼 있다. 그러나 숫자가 60이나 되는 경우에는 이런 한쪽 방향으로 회전만 가능한 인터페이스는 결코 좋은 선택이라 볼 수 없다.   이렇게 주위의 물건에서부터도 좋은 인터페이스와 나쁜 인터페이스의 예를 찾아 볼 수 있다. 인터네트에 이와 관련한 아주 재미있는 웹사이트가 있어 함께 소개한다. "Bad Human Factors Design"이라는 이름의 홈페이지(www.baddesigns.com)인데 인터페이스와 디자인이 나쁜 물건들의 예를 모아 종류별로 분류해 두었다(사진 7). 이 홈페이지에 실려 있는 예를 몇 가지 뽑아 소개하겠다.   <table style="WIDTH: 516px; HEIGHT: 511px;"> <tbody> <tr> <td width="195"> [##_1C|ik61.jpg|width="158" height="127"|_##]</td> <td rowspan="2" width="489"> -어떻게 약을 짜내야 하는지 혼동을 주는 1회용 치약   일회용 치약이나 연고류의 약품 등에 흔히 쓰이는 인터페이스인데 뚜껑을 열어보면 윗 부분이 막혀 있다. 이 막힌 부분을 뚫어 사용해야 하는데, 대개 뚜껑 안에 바늘과 같이 생긴 뾰족한 부분이 있어 뚜껑을 거꾸로 꽂아 이를 뚫게 돼 있다. 한번 알고 나면 쉽지만 처음에는 뚜껑 안에 바늘 같은 것이 있다는 것을 알지 못해 이빨로 물어뜯는(!) 등 별별 짓을 다 하게 된다. 제품의 겉에 이를 간단히 소개하는 그림 한 장이라도 있었다면 물어뜯는 고생까지 할 필요가 없을 터인데, 글쓴이는 아직까지 그런 제품은 본 적이 없고 다만 제품 설명서에 깨알같은 글씨로 "뚜껑을 이용해 마개 부분을 따십시오"라고 쓰여져 있는 것을 읽은 적은 있다. 글쓴이는 한국과 미국을 오가는 비행기를 몇 차례 타면서 이제는 이러한 치약에 익숙해 졌으나 처음에는 이 홈페이지의 주인이 경험한 것처럼 어떻게 치약을 빼내야 하는지를 몰라 한참 헤맸다. 사용자로 해금 "촌놈 티를 내는군"이라는 자괴감까지 들게 만든 나쁜 제품 디자인(또는 인터페이스 정보 부족)인 것이다.   인터페이스의 연구에 있어서 문은 전형적인 예로 사용된다. 우리는 흔히 "이 문 어떻게 열리는 거야?"라며 의아해 하거나 '당연히 이렇게 하면 열리겠지' 라고 생각했는데 예상대로 문이 열리지 않는 경우를 종종 경험한다. 밀어야 하는가 아니면 잡아 당겨야 하는가? 어느 쪽을 밀어야 하는가? 밀고 들어왔다면 나갈 때도 밀면 되는가 아니면 잡아 당겨야 하는가? 등등 문 하나만을 가지고도 인터페이스에 대한 이슈를 논할 수 있다. 글쓴이가 어릴 때 보았던 어떤 코메디의 내용은 화장실이 매우 급한 한 사람이 화장실 문을 안으로 밀어 열려고 했는데 문이 안 열리자 잠긴 것으로 알고 계속 노크를 하면서 발을 동동 굴리고 있는데 다른 한 사람이 천천히 걸어오더니 문을 앞으로 잡아 당겨 들어가는 것이었다.</td> </tr> <tr> <td width="195"> [##_1C|ik62.jpg|width="160" height="219"|_##] 쁜 디자인 예</td> </tr> </tbody> </table>   사진에 나와 있는 문의 예를 보자. 이 두 개의 문은 두 빌딩 사이를 연결하는 복도에 있는 문들이다. 이 사진을 올린 사람은 이 복도에 갇힌 경험을 소개하고 있다. 그 사람은 사진의 앞부분에 있는 문을 "잡아 당겨" 문을 열고 복도에 들어갔다. 복도를 걸어가 사진의 뒷부분에 있는 문을 역시 "잡아 당겨" 열려고 했으나 문이 열리지 않았다. 그 문이 잠긴 것으로 생각한 그녀는 다시 사진 앞부분의 문으로 돌아와 다시 문을 "잡아 당겨" 열려고 하였으나 이번에는 이 문도 열리지 않는 것이었다. 이 문도 잠겼다고 생각한 그녀는 완전히 복도에 갇히게 된 것이라 매우 당황했다고 한다(우리 나라와는 달리 미국은 건물 보안상 닫힐 때 자동으로 잠기는 문들이 매우 많다). 잠시간 복도에 갇혀 어쩔 줄을 모르던 그녀는 마침내 복도 안에서는 문을 "밀어야" 열린다는 것을 찾아내어 복도를 벗어났다고 한다.   이 문들의 인터페이스의 문제점을 보자. 이 문들은 두 가지의 큰 문제점을 가지고 있다. 첫째는 문에 붙어 있는 손잡이가 사용자에게 주는 정보와 문의 실제 작동이 일치하지 않는다는 것이다. 사진을 보면 잡아 당겨야 열릴 것 같이 생긴 손잡이가 붙어 있음을 알 수 있다. 복도로 들어가려는 경우(즉 문을 잡아 당겨 여는 경우)에는 이 손잡이가 제 역할을 하지만 복도 안쪽에서 밖으로 나올 때(즉 문을 밀어 여는 경우)는 사용자가 완전히 헛탕질을 하게끔 만드는 것이다. 대개 밀어 여는 문의 경우 널찍하고 평평하게 생긴 손잡이를 써서 한 눈에 보아도 밀어야 한다는 생각을 들게 해야 하는데 이 문은 복도 안쪽에서 바깥쪽으로 나갈 때는 문을 밀어야 함에도 불구하고 잡아당기도록 생긴 손잡이가 붙어 있어 사용자를 혼동시키는 것이다. 앞서 말한 visual affordance에 완전히 어긋나는 경우이다.   이 문의 또 하나의 문제점은 같은 작동을 하는 인터페이스가 서로 일치하지 않는다는 점이다. 문을 잡아 당겨 들어간 사용자는 당연히 다른 쪽 문도 잡아 당겨야 열릴 것이라 생각할 것이다. 그렇지만 복도 안쪽에서는 문을 밀어야 열리는 완전히 대조되는 인터페이스로 작동하게끔 돼 있어 사용자에게 혼동을 주는 것이다.   이 사진을 올린 사람은 자신이 복도에 갇힌 경험은 유머스러운 경험으로 넘길 수 있겠지만 만약 화재와 같은 비상 상황의 경우 불이 난 한쪽 건물에서 다른 쪽 건물로 사람들이 긴급하게 대피하려고 할 때 이런 문의 인터페이스가 가지고 올 결과는 결코 웃음으로 끝날지 않을 것이라 말하고 있다. 긴급한 상황에서 사람은 더욱 당황한다는 것을 생각해 볼 때 더욱 그러할 것이다.   위의 예를 보면서 "그건 사용자가 멍청해서 그런 것도 있지 않겠는가?"라는 질문을 던지는 독자들이 계실지도 모르겠다. 물론 그것도 어느 정도 일리가 있는 말이기는 하다. 그렇지만 인간 공학과 HCI의 이론으로 철저하게 무장한 개발자라면 제품을 제대로 사용하지 못하는 사용자를 탓하는 대신 좋지 못한 인터페이스를 개발한 스스로를 반성할 것이다 앞서 언급한 노먼도 "인간 중심의 제품의 개발은 사용자를 잘 이해하는 개발자에게 달려 있다"라고 말한다. "사용자가 바보래서 쓰는 법을 몰라"라고 비웃기보다는 "사용자가 바보(?)이니까 그 수준에 맞게 더욱 쉬운 사용법을 제공해야 한다"라고 생각을 돌리는 것이 제품 판매에 더욱 도움이 될 것이다. 가장 바람직한 자세는 "사용자가 바보가 아니라 제품 설계 자체가 틀렸다"라고 반성하는 것이다. 인터페이스 개발 과정   어느 한 제품을 개발할 때 대개는 제품의 핵심적인 기능을 먼저 개발하고 이 과정이 어느 정도 궤도선상에 오르면 그때부터 인터페이스를 개발하는데, HCI 학자들은 인터페이스 개발은 어떠한 제품을 만들 것인지 회의하는 첫 날부터 같이 시작해야 한다고 주장한다. 인터페이스와 제품의 핵심 기능을 분리해서 생각하는 것은 소프트웨어 엔지니어링에서 나온 사고 방식이다. HCI에서는 사용자의 성향과 사용자의 사용법이 제품의 기능의 결정에 있어서 핵심적인 조건이 돼야 하므로 인터페이스와 기능을 따로 띠어놓는 사고 방식은 틀린 것이라 주장한다.   대체로 인터페이스의 개발 과정은 다음과 같은 단계를 취한다. 1. 인간에 대한 고찰(human factors) 2. 사용자 정의(user modeling) 3. 프로토타입 개발(prototype) 4. 사용성 테스트(usability test) 5. 3번과 4번의 반복   1. 인간에 대한 고찰   가장 우선해야 되는 것은 바로 사용자 분석이다. 인간에 대한 일반적인 연구부터 구체적으로 누가 주된 사용자가 될 것이며 이들의 성향은 무엇인지를 파악하는 것이 가장 중요한 것이다. 사용자가 이 제품을 통해 하려는 작업이 무엇인지를 파악하는 것도 사용자 분석의 중요한 한 요소이다.   컴퓨터 관련 제품, 특히 소프트웨어를 개발하는데 있어서는 사용자 즉 인간의 성향뿐만 아니라 인간과 협력할 컴퓨터의 성향까지도 고려해야 한다. 즉 인간의 장단점과 컴퓨터의 장단점을 잘 분석해 컴퓨터가 담당할 기능과 사용자가 담당할 기능을 적절하게 분배함으로써 최고의 작업 효과를 얻을 수 있도록 제품을 설계해야 한다는 것이다. 다음 표는 사람의 장단점을 나타낸 것이다.   <table height="105" width="469" style="WIDTH: 469px; HEIGHT: 105px;"> <tbody> <tr> <td width="50%"> 장점 </td> <td width="50%"> 단점 </td> </tr> <tr> <td width="50%"> 무한한 기억력 고도의 학습력 고도의 패턴 인식력 </td> <td width="50%"> 짧은 단기 기억력 오류 가능성 느린 수행력 </td> </tr> </tbody> </table> (표 1) 인간의 장단점   표 1을 잠시 살펴보자. 인간의 장점은 대체로 이해가 쉬울 것이다. 단점 중에 짧은 단기 기억력이란 아주 잠시 무엇인가 접하고 나서 그것을 다시 기억해 내는 능력을 말한다. 이를테면 누군가의 전화번호를 5분전에 듣고 나서 그것을 다시 기억해 내는 능력을 말한다. 인간은 특히 의미 없는 내용(이를테면 전화번호처럼 숫자의 나열 같은)을 잘 기억하지 못한다. 오류 가능성이란 인간은 자신이 잘 하는 일이라도 언제든지 실수할 수 있음을 말하는 것이다. 느린 수행력은 이를테면 컴퓨터에 비해 느린 계산력 등을 말한다.   이 표에 나온 인간의 단점은 대체로 컴퓨터의 장점으로 연결된다. 컴퓨터는 실행시 오류를 내지 않으며 빠른 수행력을 갖추고 있다. 컴퓨터는 특히 단순 반복적인 작업에서 인간과 달리 오류를 내지 않고 작업을 빠르게 처리한다. 그리고 메모리 용량이 허락하는 한 무엇이든 잘 기억한다.   이런 인간과 컴퓨터의 성향을 적절하게 조합하며 인터페이스를 설계하는 것이 중요하다. 이를테면 단순 반복되는 일련의 작업은 매크로 등을 통해 인간이 먼저 정의한 다음 실제 반복 작업은 컴퓨터가 수행하게끔 하면 그만큼 에러가 날 가능성이 줄어드는 것이다. 매크로의 정의는 고도의 학습력을 가진 인간이 그간의 학습을 통해 새로운 사용법을 응용해 내는 것으로 이것은 인간이 잘 할 수 있는 일이며 단순 반복 작업은 말할 것도 없이 컴퓨터가 잘 하는 일이다. 2. 사용자 정의   사용자가 어떻게 작업하는가를 공식화할 수 있다면 사용자가 인터페이스와 어떻게 상호 작용할 것인지를 예측할 수 있을 것이다. 이를 유저 모델링(user modeling)이라고 한다. 유저 모델링의 대표적인 예로 GOMS(Goals, Operators, Methods, Selection Rules)나 Fitt's Law등이 있다. GOMS는 어떤 작업을 수행하기 위해 사용자가 취하는 순서를 계산한다. Fitt's Law는 특히 마우스를 평가할 때 많이 사용하는데 어떤 한 목표물을 커서를 움직여 선택할 때까지 걸리는 시간을 계산하는 공식이다.   GOMS나 Fitt's Law와 같은 경우 너무 수치 중심적이라 모든 상황에 다 적용되기는 힘들다. 이를테면 GOMS같은 경우 각 작업 목표에 정확한 수행 단계가 정해져 있으며 전문 사용자가 한번도 실수하지 않고 작업을 완료한다는 가정을 두고 있다. 따라서 패스트푸드점에서의 음식을 주문 방식과 같이 사용자가 전문가가 아니고 정확한 주문 방식만이 존재하지 않는 인터페이스의 경우 GOMS를 적용할 수 없다.   보다 복잡한 유저 모델링은 수치로 나타낼 수 없는 사용자의 성향까지 고려해야 한다. 이를테면 사용자가 시스템을 대하는 태도, 작업 완료에 대한 열정이나 동기, 교육 수준, 비슷한 시스템에 대한 경험 여부, 색맹과 같은 장애 여부, 성(gender)별 차이 등등 신체적 정신적인 요소뿐만 아니라 사회적 문화적인 요소까지도 포함할 수 있어야 한다. 유저 모델링은 그 자체만으로도 하나의 학위 연구 대상이 될 수 있을 만큼 어렵고 복잡한 작업이다.   3. 프로토타입 개발   사용자에 대한 분석이 끝났으면 인터페이스 및 제품의 핵심 기능을 개발해 가면서 정기적으로 이 인터페이스가 좋은 인터페이스인지 나쁜 인터페이스인지를 테스트해야 한다. 여기서 중요한 것은 개발을 하면서 종종 인터페이스를 평가해 그 결과가 안 좋게 나오면 그때그때 인터페이스의 설계와 필요한 경우 그 인터페이스와 연관된 기능까지도 바꿀 수 있는 탄력성을 가져야 한다는 것이다. 모든 개발이 끝난 후에나 사용성 테스트를 들어가는 것은 형식상 테스트나 한번 해보는 경우가 아닌 바에야 사용성 테스트의 결과에 맞추어 이미 완성된 제품을 다시 개발해야 하는 어려움에 부딪히게 될 가능성이 크다. 개발 도중 정기적으로 사용성 테스트를 하고 테스트의 결과를 다시 개발에 투여하는 것이 보다 바람직하다. 참고로 개발 완료 후에 사용성 테스트를 하는 것을 "최종적인 평가(Summative Evaluation)"라 부르고 개발과 함께 테스트하는 것을 "형성 과정의 평가(Formative Evaluation)"라 부른다. HCI에서는 물론 "Formative Evaluation"을 선호한다.   개발 도중 정기적으로 사용성 테스트를 하기 위해서는 프로토타입(prototype)이 필요하다. 프로토타입은 완성품이 아닌 테스트를 위해 만들어지는 일종의 시제품을 말한다. 프로타입은 그 성격상 쉽고 빠르게 내놓을 수 있어야 한다. 그때그때 테스트하려는 바를 빠르게 구현해야 하기 때문이다. 따라서 프로토타입은 테스트에 필요한 기능만을 구현하거나 모의 조작을 한다던가 아예 제대로 작동한다는 가정을 두고 기능을 구현하지 않기도 한다.   소프트웨어 제품의 경우 프로토타입을 구현하는 데에는 비주얼 베이직과 같은 RAD(Rapid Application Development tool)나 매크로미디어 디렉터와 같은 저작 도구가 많이 사용된다. 앞서 말했듯이 쉽고 빠르게 테스트용 제품을 만들 수 있기 때문이다. 프로토타입에 쓰이는 다른 하나의 방법으로 "오즈의 마법사"라는 것이 있다. "오즈의 마법사"는 제품 뒤에 사람이 한 명 들어가 사용자가 조작하는 대로 기계를 뒤에서 실제 조작하는 방법이다. "오즈의 마법사"는 음성 인식과 같이 당장 구현하기 매우 어려운 제품의 인터페이스를 테스트할 때 특히 많이 쓰인다.   4. 사용성 테스트   테스트를 위해 만들어진 프로토타입을 가지고 인터페이스를 평가하는 방식에도 여러 가지 가 있으며 이를 여러 분류로 나눌 수 있다. 먼저 실험적 방식과 자연적 방식부터 알아보자. 실험적 방식은 사용자를 테스트 환경을 갖추고 있는 연구실(usability test laboratory)로 데려와 테스트를 하는 방식이다. 이와 반대로 자연적 방식은 사용자들이 그 제품을 가지고 실제 작업하고 있는 작업 환경으로 연구가들이 뛰어 들어가 사용성 테스트를 하는 것을 말한다.   이 두 방식은 각자 장단점이 있다. 실험적 방식은 테스트 결과에 영향을 줄 수 있는 부가적인 요소들을 제어할 수 있다. 이를테면 건물 밖에 설치할 키오스크의 인터페이스를 테스트한다고 하자. 테스트 당일에 마침 비가 오고 있다면 자연적 방식에서는 이 비가 부가적인 효과를 가져올 수 있다. 궂은 날씨를 무릅쓰고서라도 키오스크를 사용하는 사용자들은 일반적인 사용자들과는 달리 분명 키오스크를 사용해야 할 특별한 이유가 있어서이므로 이 결과를 일반적인 사용자들의 테스트 결과로 볼 수 없을 것이다. 이에 비해 실험실 방식은 날씨와 같은 부가적인 효과를 제어할 수 있다.   물론 이 예는 설명을 위해 조금 과장된 것으로 이를테면 비가 안 오는 날을 골라 다시 실험할 수도 있을 것이다. 여기서 말하자고 하는 바는 자연적 방식의 경우 여러 부가 요소를 완전히 제어하기 힘들다는 것이다. 이런 면에서 실험적 방식은 장점을 가진다. 반면 실험실 방식의 단점은 말 그대로 실험실에서 테스트를 하는 것이므로 "실전"이라는 면에서 그만큼 뒤떨어질 수밖에 없다는 점이다. 자연적 방식의 장단점은 실험적 방식의 장단점의 반대라고 보면 될 것이다. 자연적 방식은 대체로 인류학에 그 뿌리를 두고 있다.   사용성 테스트에 있어서 사용자를 테스트 대상으로 보지 않고 "협력자"로 간주하는 방법도 있다. "협력적 평가"나 "참여적 평가" 등이 바로 그것인데 사용자를 테스트 수준에서만 접하는 것이 아니라 개발 과정에까지 끌어 당겨 모든 개발 과정에서 사용자의 참여를 유도하는 방법이다. 이밖에도 발견적 방법(Heuristics)등 여러 가지 방법들이 있다.   사용성 테스트 방식   이러한 사용성 테스트 방식에서 실제적으로 쓰는 방법들은 무엇이 있는가 알아보자. 먼저 어떠한 정보들을 수집해야 하는가부터 결정해야 한다. 수집해야할 정보는 크게 객관적 정보와 주관적 정보로 나뉜다. 객관적 정보는 인터페이스 조작에 걸린 시간이나 거쳐간 단계의 총합 등 수치적인 정보이고 주관적 정보는 사용자의 만족도와 선호도와 같이 수치로 나타내기 힘든 정보들을 말한다. 객관적 정보는 사용자들에게 시스템을 통해 풀어야 하는 일종의 시험을 주고 이를 해결하는 과정을 관찰해 추출해 낸다. 주관적 정보는 인터뷰, 앙케트 조사, 소비자 지원 센터 등의 자료 등을 통해 뽑는 것이 일반적이다. 주관적 정보가 객관적 정보보다 수집하기가 더욱 힘들기에 상대적으로 객관적 정보의 수집이 쉬어 보이지만 실제 객관적 정보도 결코 수집하기가 만만치 않은 것으로 알려져 있다.   객관적 정보 수집이 어려운 이유로 크게 두 가지를 들 수 있다. 첫째는 수집 과정에서 필수적으로 따라오는 부과적인 효과를 제어하기 힘들다는 것이고 둘째는 객관적 정보의 해석이 쉽지 않다는 것이다.   수집 과정에서 따라오는 부과적인 효과에서도 가장 제어하기 힘든 부분이 바로 사용자의 심리이다. 인간은 누구나 시험에 대해 긴장하기 마련이다. 따라서 아무리 사용자에게 "맘 편하게 가지고 하라"라고 말해 주어도 막상 시험에 들어가면 사용자들은 긴장해 평상시 업무에서 하던 대로 행동하지 않는 경우가 허다하다. 앞서 말한 실험적 방식의 단점인 "실전에서의 약함"이 바로 이러한 것을 말한다.   객관적 정보의 해석은 사용자의 관찰을 통해 추출한 수치 정보를 어떻게 해석할 것인가에 관한 것이다. 이를테면 어느 사용자가 어느 한 작업을 처리하기 위해 인터페이스를 조작한 시간이 2분 20초였고 그 동안에 거친 조작 단계가 8번이었다고 하자(앞서 설명한 손목 시계의 알람 을 바꾸는 경우는 총 16 단계를 거쳤다). 이 결과를 놓고 이 인터페이스가 좋은 것인지 나쁜 것인지 좋으면 얼마나 좋은 것이고 나쁘면 얼마나 나쁜 것인지 평가하기가 애매해진다. 즉 8번 걸린 것이 괜찮은 것인지 아니면 5번 정도로 줄여야 하는 것인지, 또 2분 20초 이상 걸린 것이 너무 오래 걸린 것인지 적당한 것인지 등등 객관적인 수치의 기준이 없으므로 어떻게 평가하기가 애매하다는 것이다. 만약 기존에 비슷한 시스템이 있다면 그 시스템과의 비교를 통해 어느 정도 좋고 나쁨의 기준을 정할 수도 있겠지만 새로운 종류의 시스템이라면 비교를 통해 기준을 잡기조차 힘들어진다.   객관적 정보의 해석에 있어서 또 하나 어려운 점은 그렇게 추출한 수치가 사용자가 어떤 생각으로 작업을 했는지 보여주지 않는다는 것이다. 어느 사용자가 8번 걸려 주어진 문제를 완료했고 다른 사용자는 10번에 걸쳐 똑같은 문제를 완료했다고 해보자. 8과 10이라는 수치만을 가지고는 왜 다른 사용자가 똑같은 문제에 대해 단계를 두 번 더 밟았는지 알 수가 없다. 이러한 문제를 해결하기 위해 HCI에서는 "소리내어 생각하기(Think-Aloud)"라는 방법을 사용하고 있다.   Verbal protocol   흔히 "verbal protocol"이라고도 불리는 이 방법은 사용자가 주어진 문제를 풀면서 왜 이러한 단계를 거쳤는지 큰 소리로 말하게끔 하는 것이다. 예를 들어 사용자에게 문서 작성기를 이용해 현재의 문서에서 어느 한 단어를 다른 위치로 옮기라는 문제가 주어졌다고 하자. 그러면 사용자는 문서 편집기의 인터페이스를 조작하면서 "단어를 옮기려면 일단 블록부터 쳐야 하니까 마우스를 이용해서 단어의 시작 부분으로 커서를 옮기고 블록을 쳤어요", "복사의 단축키가 ctrl-c이니까 키보드에서 컨트롤키하고 c키를 동시에 누릅니다"와 같이 일일이 자신이 왜 그런 조작을 하였는지 말로 설명하는 것이다. 한마디로 "Think-Aloud"는 사용자의 머리 속에 돌아가는 상황을 말로 표현하게끔 하는 방법이다(그래서 "verbal protocol"이라고도 불리는 것이다).   "Think-Aloud"는 매우 유용한 방법으로 널리 쓰이고 있으나 몇 가지 문제점을 안고 있다. 사용자가 일일이 자신의 작업을 말로 표현하는 것에 익숙하지 않을뿐더러 막상 말로 표현하면서 작업을 하는 경우 엉뚱한 작업을 하거나 시간이 더 오래 걸릴 수도 있기 때문이다. 무엇보다 혼자 "떠들게(!)" 하는 것이 이 방법의 가장 큰 단점이다.   "Think-Aloud"의 이런 단점을 해소하기 위해 "협력에 의한 발견적 학습법(Co-Discovery Learning)"이라는 방법이 쓰이기도 한다. 두 명 이상의 사용자들을 놓고 서로 대화를 통해 "Think-Aloud"를 하게 하는 방법인데, 혼자 말하는 어색함을 줄일 수 있다. 그렇지만 여전히 자신이 하는 작업을 말로 일일이 설명해야 하는 단점이 여전히 있다. 이런 단점을 줄이기 위해 "작업 이후의 통신(Post-Event Protocol)"이라는 방법을 또한 사용하기도 한다.   "Post-Event Protocol"은 사용자가 "Think-Aloud"를 하지 않고 평상시와 마찬가지로 작업을 하게끔 놓아두고 사용자의 작업 과정을 비디오로 촬영한 다음 나중에 사용자와 함께 비디오를 다시 보면서 그때 왜 저런 조작을 했는지 질문하는 방식이다. 이 방식은 "Think-Aloud"의 어색함을 줄이는 장점이 있는 반면 사용자가 그때 왜 그런 조작을 했는지 기억을 못해 낼 수도 있는 단점을 내포하고 있다.   이상에서 볼 수 있듯 사용성 테스트란 결코 쉬운 작업이 아니다. 무엇을 테스트할 것이며 어떻게 테스트의 결과를 해석할 것인지, 테스트에 따라오는 여러 부과적인 효과들을 어떻게 제어할 것이며 이 중에서도 특히 사용자의 심리적 상태를 어떻게 조정할 것인지 등등 사용성 테스트를 수행하는데 있어서 고려해야 할 사항들이 한 두 개가 아니다. 사용성 테스트는 제품의 개발보다 더욱 어려우면 어려웠지 결코 쉽지는 않으며 많은 분야에 걸친 연구가 요구된다. 1회에서도 설명하였듯 HCI가 여러 학문과의 결합을 시도하는 데에는 그럴만한 이유가 있는 것이다.   이것으로 이번호를 마치고자 한다. 지금까지 두 회에 걸쳐 인터페이스에 대해 소개했다. 다음 호에서는 내용이 많이 바뀌어 HCI의 최첨단 분야 중의 하나인 가상 현실에 대해 소개한다. "가상 현실이 HCI와 무슨 관련이 있나?" 라고 의아해 하시는 독자들은 다시 한번 HCI의 마지막 I가 Interface가 아니라 Interaction임을 주시하기 바란다. 지난 6월호에 언급된 알렌 케이나 이번 호에 소개된 돈 노먼 모두 컴퓨터의 투명성(invisibility 또는 transparency)을 주장하고 있다. 가상 현실은 사용자로부터 컴퓨터라는 매체를 가장 잘 숨겨주며 인간과 컴퓨터의 상호 작용을 최적화 할 수 있는 기술로 꼽히고 있다.   <hr style="WIDTH: 489px; HEIGHT: 2px;" />   죠지아텍의 클래스룸 2000 프로젝트 죠지아텍의 클래스룸(Classroom) 2000 프로젝트는 그 이름에서도 알 수 있듯 21세기형 첨단 교육 시스템을 개발하는 프로젝트로 6월호에서도 언급한 바 있는 HCI의 한 분야인 편재 컴퓨팅(ubiquitous commputing)을 기초로 하고 있다. 클래스룸 2000 프로젝트는 어느 정도 성과를 거두어 현재 죠지아텍의 일부 클래스에서 실제 사용되고 있다.   클래스룸 2000 시스템은 50인치 정도 되는 스크린을 가진 전자칠판, 전자칠판에 연결된 프로젝터, 인터네트 접속이 되는 일반 PC에 연결된 또 하나의 프로젝터, 비디오 관련 기계 및 메인 서버 등으로 구성돼 있다(사진 10). 가장 눈에 띄는 전자 칠판은 제록스사에서 개발한 라이브보드(LiveBoard)로 죠지아텍에서 클래스룸 2000 프로젝트에 도입해 사용하고 있다(그림 11). [##_1C|ik63.jpg|width="156" height="129"|_##] [##_1C|hk75.jpg|width="158" height="125"|_##] [##_1C|ik64.jpg|width="163" height="119"|_##]   이 시스템이 어떻게 수업 환경을 바꾸는지 보자. 교수는 그날 강의할 내용을 파워포인트와 같은 프리젠테이션 파일로 미리 준비해와 전자 칠판에 이 파일들을 한 장 한 장 보여주며 강의를 한다(사진 12). 전자 칠판은 일반 칠판과 똑같이 작동한다. 일반 칠판에 분필로 글을 쓰듯 전자펜으로 전자 칠판에 글을 쓰거나 그림을 그릴 수 있도록 돼 있다. 교수가 전자 칠판에서 현재 설명하고 있는 내용은 전자 칠판과 연결된 프로젝트를 통해 교실 앞의 스크린에 크게 확대돼 출력된다.   사진 10에서도 볼 수 있듯 교실에는 2개의 프로젝터가 있어서 하나는 전자 칠판의 내용을 출력하는 데에 사용되고 다른 하나는 인터네트와 연결된 일반 PC와 연결돼 있다. 수업에 필요한 홈페이지를 교수가 이 PC를 이용해 프로젝터가 그 홈페이지를 확대해 보여준다. 또한 이 프로젝터는 VCR과도 연결돼 있어 비디오를 상영할 수도 있다.   이만한 시스템을 갖추고 수업을 한다는 것도 대단하지만 더욱 놀라운 것은 강의의 모든 내용과 교수의 설명이 그대로 서버에 저장돼 수업이 끝나자마자 곧바로 해당 수업의 홈페이지에 등록된다는 점이다. 그 홈페이지를 접속해 보면 각 날짜별로 강의가 등록돼 있다(사진 13). 어느 한 강의를 선택하면 그날 강의에서 교수가 보여주었던 프리젠테이션 화면이 모두 등록되고 있고 또한 교수의 설명이 리얼 오디오 파일로 저장돼 있어 언제든지 재생해서 들어볼 수 있다(사진 14). 그리고 강의 전체가 교실의 천장에 달린 비디오 카메라로 녹화돼 리얼 비디오로도 재생해 볼 수 있다. 단, 이 기능은 비디오 화면이 너무 작아서 그다지 실용성은 없는 것 같았다.  [##_1C|hk76.jpg|width="165" height="136"|_##] [##_1C|ik65.jpg|width="159" height="151"|_##] [##_1C|ik66.jpg|width="165" height="152"|_##] 클래스룸 2000 시스템의 기능이 강의의 재생에만 한정돼 있다면 "그냥 대단하구나. 엄청난 재생 기능을 가진 시스템이군"이라고 생각하고 넘길 수도 있을 것이다. 사실 홈페이지로의 재생 기능만을 보자면 학생들이 개인적으로 노트와 녹음기나 캠코더를 가져와 필기하고 강의를 녹음(녹화)한 다음에 이를 재생해 보면서 필기한 내용을 다시 보는 것하고 큰 차이가 없을 것이다.   정말 감탄할만한 것은 홈페이지에 올라와 있는 수업의 내용이 서로 하이퍼링크(hyperlink)돼 있어서 각 프리젠테이션 파일마다 해당 부분에 대한 교수의 설명을 따로 들을 수 있고, 더욱이 교수가 전자 펜으로 추가적으로 써넣은 부분을 클릭하면 그 부분을 쓰면서 교수가 설명했던 내용만 따로 들을 수 있다는 것이다. 이를테면 사진 15에서 화면 위의 #1이라고 돼 있는 부분을 클릭하면 이 슬라이드에 해당하는 교수의 설명이 리얼 오디오로 재생된다. 또 슬라이드 안의 오른쪽 하단 부분에 교수가 전자펜으로 쓴 글씨 부분(B. Mynatt라고 필기체로 쓰여져 있는 부분)을 클릭하면 교수가 수업 당시 전자펜으로 이 부분을 쓰면서 말하였던 설명만 따로 재생된다.   그리고 교수가 수업 도중 보여준 홈페이지들의 URL이 자동으로 등록돼 학생들이 따로 URL을 적는 수고를 할 필요도 없다. 물론 링크도 돼 있으므로 즉시 그 홈페이지들을 가볼 수도 있다(사진 16). 이 모든 것을 시스템이 다 알아서 해주므로 교수는 시스템에 대한 기초 지식은 이론상 알 필요 없고 기존의 강의처럼 (전자)칠판에 내용을 쓰고 내용을 설명(강의실 자체가 마이크 장치를 구비하고 있어서 교수가 따로 마이크를 장착할 필요조차 없다)하면 된다. 강의 내용의 하이퍼링크 작업이나 이를 홈페이지로 만들어 등록해 주는 작업은 시스템이 전부 알아서 해주는 것이다.   클래스룸 2000 프로젝트는 아직도 진행 중인 프로젝트다. 앞으로는 학생들의 책상에 노트북을 한 대씩 설치하고 이를 모두 네트워크로 연결해 학생들도 전자 칠판에 직접 내용을 써넣는다던가 서로 통신할 수 있게 만든다고 한다. 실제 클래스룸 2000 시스템이 설치된 교실에서 수업을 받던 어느 날 모든 책상에 노트북을 하나씩 설치해 테스트를 해 본 적도 있다.   죠지아텍의 연구가들은 클래스룸 2000 시스템을 개발하는 데에만 투자를 하는 것이 아니라 이 시스템의 교육적 효과 역시 연구하고 있다. 이를테면 이렇게 거의 100% 강의의 재생이 가능한 첨단 환경이 오히려 학생들의 수업의 참여도를 떨어뜨리지 않는가 등을 연구하는 것이다. 단순히 시스템의 개발에만 끝나지 않고 이러한 교육용 시스템이 가지고 올 새로운 교육 환경이나 교육 방식 등 교육 공학(educational technology)적 측면까지 함께 연구하고 있다.   클래스룸 2000 프로젝트에 대해 보다 자세하고 알고 싶으신 독자들은 다음의 홈페이지를 방문하면 자료를 찾을 수 있다. http://www.cc.gatech.edu/fce/c2000/ </div> <div class="post_footer_contents"></div> cratia21 cratia21 1