작은 빌딩에 있는4층 사무실에 볼 일이 있었습니다. 엘리베이터를 타려면 두 명이 걸어가기에도 좁은 통로를 지나야 했습니다. 제 앞에는 할머니께서 걸어 가셨습니다. 저는 도리 없이 할머니의 뒤를 따라서 걸어갔죠.
할머니께서 엘리베이터 앞에 도착하시자 내려가는 버튼을 누르셨습니다(엘리베이터는3층에 있었습니다) . 저는 올라가는 버튼을 눌렀습니다. 엘리베이터가 도착하자, (성격이 급한 편인) 저는 할머니와 같이 엘리베이터를 탔습니다. 할머니를 따라서 지하에 내려 간 다음 다시 타고 올라올 심산이었습니다.
하지만 할머니께서 지하층을 누르시는 게 아니라 지상3층을 누르시더군요. 3층에 가실 할머니께서 왜 내려가는 버튼을 누르셨을까요? 이런 생각을 할 때 엘리베이터 문이 열렸습니다. (할머니가 내려가는 버튼을 누르시고3층을 누르셨기 때문에 엘리베이터는 내려가는 명령을 소하기 위해서 문을 한 번 열고 닫았습니다.)
할머니 : 이 망할 놈의 엘리베이터가 왜 안 올라가고. 이 난리여.
나: (망설이다) 할머니가 내려가는 버튼을 누르시고 반대로 올라가시는 3층을 누르셔서 그러세요.
할머니 : 그래? 난 엘리베이터가3층에 있길래, 내려오라는 뜻으로 그 버튼을 눌렀는데.
저는 할머니의 말씀에 조금 당황스러웠습니다. 보통은 우리가 생각하는 엘리베이터 버튼의 의미는 내가 이동하려는 방향을 뜻합니다. 즉, 위로 향한 버튼을 누른다는 의미는 “난 올라가고 싶어.” 하고 엘리베이터한테 알려 준다는 것입니다.
하지만 할머니는 엘리베이터의 위치를 고려하셔서 자신보다 위층에 엘리베이터가 있으면 내려가는 버튼을 누르셨고, 엘리베이터가 아래에 있으면 올라오는 버튼을 누르셨던 거죠. 저와 같이 계셨을 때처럼 운 나쁘게 반대 방향의 버튼을 누르신 경우에는 가끔 반대 방향으로 내려가셨다가 올라가셨겠지만, 할머니는 그날까지 그리고 앞으로도 엘리베이터를 잘 타고다니실 겁니다.
혹시 이런 생각을 품은 사람이 할머니 혼자만은 아닐 거라는 생각이 들어 네이버 지식인에서 검색해 봤습니다. 혹시나 했더니 역시나 할머니 같은 분이 있었습니다.
이상해서 물어봅니다. 1층에서 엘리베이터를 탈 때, 승강기가3층에 있습니다. 전5층을 가고 싶습니다. 그렇다면 저는 올라가는 버튼을 눌러야 할까요? 아니면 내려가는 버튼을 눌러야 할까요? 반대로 제가5층에 있고 1층에 가고 싶습니다. 승강기가3층에 있다면, 올라가는 버튼을 눌러야 하나요? 아니면 내려가는 버튼을 눌러야 하나요?
누구에게나 당연한 엘리베이터 버튼 동작 방식을, 왜 어떤 사람들은 헷갈릴까요? 그 이유는 바로 심성 모형(mental model)에서 찾을 수 있습니다. 심성 모형은 사람들이 자신, 타인, 환경 그리고 자신과 상호작용하는 사물들에 대해 품는 모형입니다. 이런 심성 모형은 디자인 모형(design model), 사용자모형(user model), 시스템이미지(system image)로구분됩니다.[노먼07]
디자인 모형은 디자이너(designer)가 생각하는 시스템을 개념화시킨 것입니다.[노먼07] 엘리베이터 버튼을 설계한 디자이너는 ‘사용자가 올라가고 싶을 때는 올라가는 버튼을, 내려가고 싶을 때는 내려가는 버튼을 누르는것’ 으로 엘리베이터 버튼을 개념화시켰습니다. 사용자 모형은 디자이너가 설계한 시스템의 작동 방식을 설명하려고 사용자가 구축한 모형입니다.[노먼07] 즉, 할머니는 ‘자신보다 엘리베이터가 낮은 곳에 있을 때 위로 향한 버튼을, 높은 곳에 있을 때 아래로 향하는 버튼을 누르는 것’ 으로엘리베이터 버튼에 대한 사용자 모형을 구축하셨습니다.
디자이너는 디자인 모형과 사용자 모형이 일치할 것이라고 가정하고 시스템을 만듭니다. 또한 시스템이 원활하게 작동하려면, 반드시 디자인 모형과 사용자 모형이 일치해야 합니다. 하지만 할머니 사례에서 보듯이, 반드시 디자인 모형과 사용자 모형이 일치하는 게 아닙니다.
디자인 모형과 사용자 모형이 일치하지 않는 일이 발생하는 이유는 디자이너와 사용자가 시스템만을 두고 대화하기 때문입니다.[노먼07] 즉, 할머니는 엘리베이터 버튼, 현재 엘리베이터가 있는 층 그리고 버튼을 눌렀을 때 엘리베이터가 할머니가 계시는 층에 온다는 것을 토대로 엘리베이터에 대한 ‘할머니의 사용자 모형’ 을 독자적으로 구축하셨습니다. 할머니처럼 그릇된 사용자 모형을 형성하는 것을 막으려면, 디자이너는 사용자들이 올바른 사용자 모형을 형성하도록 ‘시스템 이미지’ 를 잘 만들어야 합니다.
할머니 사례에서 발생한 비극이라면 디자인 모형과 사용자 모형이 달라서 간간히 고생을 하는 정도지만, 가끔 시스템 이미지가 부적절해서 역사적인 비극이 일어날 때도 있습니다. 1979년, 수많은 인명을 앗아갈 뻔한 원자력 발전소 사고인 쓰리마일 아일랜드(Three Mile Island) 사건은 아주 사소한 착오에서 일어났습니다.(3) 물론 이 사건은 복합적인 요인이 작용한 것이지만 시스템 이미지가 적절하지 못한 데서도 한 가지 원인을 찾을 수 있습니다.
사건은 이렇게 시작됐습니다. 운영요원이 남는 냉각수를 흘려보내도록 열린 밸브를 닫으려고 버튼을 눌렀지만 밸브에 결함이 있었기 때문에 밸브가 실제로 닫히지 않았습니다. 하지만 밸브가 정말도 닫혔다는 것을 보여주는 계기판이 존재하지 않았기 때문에, 밸브에 ‘닫힘’ 명령을 보냈다는 계기판만 보고 운영요원은 ‘밸브가 정말로 닫혔을 것’ 이라고 믿었습니다. 이런 사소한 실수는 결국 연쇄적인 실수를 낳았고 체르노빌 원자력 사고처럼 엄청난 역사적 비극이 될뻔한 쓰리마일 아일랜드 사고가 발생했습니다.(4)
우리가 만든 소프트웨어를 사용하면서 사용자들이 혼란을 겪는 것을 볼 때마다 우리는 가끔 사용자들의 멍청함을 탓하기도 합니다. 하지만 사용자가 ‘삽질’ 을 하는 것을 목격할 때면 우리는 시스템 이미지가 디자인 모형을 적절히 반영했는지 반성해 봐야 합니다. 어쩌면 우리가 만든 소프트웨어에 품는 과신 때문에 쓰리마일 아일랜드 사건과 비슷한 비극이 일어날 수 있으니까요.
이 연재는 이미 출판된 겸손한 개발자가 만든 거만한 소프트웨어의 글을 옮겨 놓은 것입니다. 아래 링크를 통해서 책을 구매하시면 더욱 충실하게 읽어 보실 수 있습니다.
주
3. 미국 상업 핵발전소 역사상 가장 중요한 사건으로, 이 사건 때문에 미국은 원자력 발전소를 더 이상 건설하지 못했습니다. http://en.wikipedia.org/wiki/Three_Mile_Island_accident
4. http://www.world-nuclear.org/info/inf36.html
