최근 개최된 동아시아 축구대회에서 우리나라 축구팀이 꼴지를 했다고 스포츠 신문을 비롯한 다양한 언론 매체에서 떠들어 대고 있습니다. 심심해서 축구와 Microsoft Office에 대해 몇 자 끄적여 봅니다.

기대치의 상승

2002년 한일 월드컵. 첫 승과 16강이 목표였던걸로 기억난다. 하지만 가뿐(?)이 16강을 통과하고 8강, 그리고 4강을 넘어 결승전까지 넘보던 대한민국 축구팀은 4위로 만족했다. 온 국민이 열광하며 "오~ 필승 코리아"를 외쳤으며, 필자와 3살짜리 아들까지 필승 코리아를 외쳤었다. 대한민국 축구가 세계 4위라니... 당연 빤쑤로 전문가들도 예측하지 못한 결과였으며 한국이 그렇게 선전할 수 있는 이유를 찾기에 급급 했던걸로 기억난다. 그리고 3년이 지난 지금... 북한, 중국, 일본, 한국이 참여한 동아시아 축구대회에서 우리나라는 꼴찌를 했고 그 원인을 대표팀 감독인 본프레레에게서 찾으려는 모습이 보인다.

대표팀 감독이 잘했나 못했나를 따지고 싶지 않다. 필자는 축구를 잘 알지도 못하며 축구를 좋아 하지도 않는다. 가끔 한일전이나 월드컵이나 볼 뿐 프로축구도 잘 보지 않는 필자가 엊그제의 TV 뉴스와 신문을 쳐다보며 이런 생각이 들었다.

"너무 눈만 높아진거 아녀?"

월드컵 4강을 이루어낸 대한민국 축구팬들의 눈이 저 높은 곳으로 올라가버린 것은 아닌가? 그리고 그 높은 기대치에서 바라보면 한국 축구의 최근 성적은 월드컵 진출을 이루어 냈다고는 하나 초라하기 그지 없게 보일 수 밖에 없을 것이다.

오피스 효과

축구에 대한 기대감이 높아진 것이라는 생각과 함께 든 생각은 컴퓨터를 사용하는 우리나라 사용자의 눈 역시 매우 높다는 생각을 해봤다. 여러 가지 요인이 있겠지만 그 원인 중의 하나가 바로 마이크로소프트 오피스가 아닌가 생각이 든다. 현재 사용되는 많은 UI 표준들은 오피스에서 기인하고 있다. 최초로 쿨바(CoolBar), 리바(Rebar)등을 채용한 것이 오피스이며 오피스에 의해 채용된 현란한 UI는 IE 에 의해 채용되다가 종국에는 Windows의 표준 UI로 자리잡게 되고, 그 결과 다양한 응용 프로그램들이 채용하고 있는 UI 표준이 되고 있다. 이뿌장한 UI도 부족해서 스마트 태그니 하는 UI 기능들로 사용자들을 더욱 현혹하는 이유가 뭘까?

Windows 3.1 (1991 년 전후)의 Regedit 프로그램 UI

마이크로소프트는 소프트웨어를 작성해서 판매하는 회사이다. 보다 많은 소프트웨어를 팔아야 하는 것이다. 기능적으로 보았을 때 오피스는 더 이상 많은 기능을 포함할 필요가 없다. 새로운 오피스 버전이 나올 때 마다 등장하는 새로운 기능들을 독자들은 얼마나 사용하고 있는가? 그럼에도 불구하고 마이크로소프트가 2년이 멀다하고 새로운 오피스 버전을 내놓는 이유는 새 소프트웨어를 팔아야 하기 때문이다. 그리고 버전이 바뀌었음을 가장 쉽게 어필할 수 있는 것이 바로 UI 이다. 눈에 가장 잘 띄지 않는가?

많은 사용자들이 접하는 프로그램 중 하나가 오피스, 특히 Excel 일 것이다. 굳이 회사를 다니는 사람이 아니더라도 집에서 그리고 자영업을 위해서도 Excel은 많이 사용되는 프로그램이며 오피스의 현란하고 이뿌장한 UI는 사용자가 응용 프로그램에 대한 UI 기대치를 올리기엔 충분하다. 필자는 이렇게 오피스의 현란한 UI로 인해 사용자가 어플리케이션에게 요구하는 UI 기대치가 상승하는 효과를 오피스 효과라고 명명(필자가 정의한 용어일 뿐이다)한다.

이제 기업용 MIS 어플리케이션(소위 인사/노무, 회계, 전자 결재 등등)은 업무적인 기능 뿐만 아니라 예쁜 UI에도 많은 신경을 써야 한다. 시스템이 오픈될 때, 현업(최종 사용자)이 업무에서 요구하는 기능이 정확하게 구현 되었는 가를 살펴보기 전에 제일 먼저 눈에 띄는 것은 UI 이다. UI가 이뿌장하게 나타나면 벌써 사용자는 50%는 만족하고 들어간다. 이때 조회가 안되었을 때(오류가 났을 때) 사용자의 반응은 다음과 비슷할 것이다.

"어? 왜 안되지? 내가 뭘 잘못했나?"

하지만... 화면을 딱 열었을 때 UI가 호좁하게 보이면, 일단 눈살을 찌푸린다. 그리고 나서 조회를 했는데 거기서 오류가 난다면, 아마도 이런 반응을 보일 것이다.

"아 쓰바... 이런 것도 안되?"

개발자는 UI에 약하다

동일한 오류에 대해 이뿌장한 UI를 가진 프로그램과 그렇지 못한 UI를 가진 프로그램에 대한 사용자의 반응은 이처럼 크게 차이 난다. 심지어 일부 중요하지 않는 기능이 잘못 작동하더라도 미려한 UI를 가진 프로그램에 대해 사용자는 상당히 너그러워 진기 마련이다. UI가 이뿌면 좋다는 걸 모르는 개발자가 있을까? 하지만 개발자는 디자이너가 아님을 명심해야 할 것이다. 개발자는 기능을 높은 성능 하에서 정확하게 구현하는 것이 임무이다. UI를 이뿌게 가져가는 것은 디자이너와 UI 설계자의 몫일 것이다. 이뿌게 설계가 되어 있어야 이뿌게 구현할 거 아닌가?

하지만 현실은 어떠한가? 웹 어플리케이션이라면 웹 디자이너가 관여되는 것이 일반적이지만 윈폼 어플리케이션에 전문 디자이너가 관여되는 경우는 드물다. 정확히 말해 윈폼 어플리케이션 디자이너가 없다고 봐야 한다. 웹 디자인과 윈폼 디자인은 명백히 다르다. 윈폼 디자인은 단순히 이미지와 <table> 태그로 떡칠하면 이뿌게 되는 것이 아니기 때문이다. 윈폼 디자이너는 디자인 감각 뿐만 아니라 각 윈폼 컨트롤의 특성과 작동 방식을 알아야 하며, 심지어 프로젝트에서 사용하는 써드 파티 컨트롤들에 대한 디자인적인 특성 까지 파악해야만 한다. 또한 웹에서 사용되는 이미지들과 윈폼 어플리케이션에서 사용되는 이미지들(툴바 이미지, 버튼 이미지)은 그 제작 기법이 약간 다르다. 예를 들어 버튼용으로 작성되는 웹 이미지는 버튼의 3차원 특성(버튼의 그림자 부분)까지 이미지에 포함되어야 하지만 윈폼에서 버튼에 포함될 이미지는 버튼의 3차원적 특성은 버튼 컨트롤 그 자체가 표시하는 경우가 있으므로 이미지에서 제외되어야 하는 경우도 있다.

이뿌게 디자인된 윈폼 화면을 구현하는 것은 역시 개발자의 몫이다. 보다 이뿐 화면은 보다 많은 코드를 필요로 하기 마련이다. 버튼 액션에 따라 서로 다른 이미지가 버튼에 나타나게 하려면 하다 못해 몇 줄의 코드라도 더 들어갈 것 아닌가?

된장... 사용자의 수준은 높다.

이야기가 삼천포로 빠졌지만, 오피스 효과에 의해서건 다른 이유에서건 사용자의 수준은 높다는 것이 결론이다. 그리고 이 사용자의 기대 수준에 맞추기 위해서 개발자 역시 디자인에 신경을 많이 써야 하며, 윈폼 디자이너라는 새로운 쟝르의 IT 디자이너가 필요하다는 것이 필자의 생각이다. 기대 수준을 맞추기 위해 개발자는 좀더 조뺑이 쳐야 하는 것이 사실이며, 이러한 조뺑이의 원인 중에는 마이크로소프트 오피스가 한 따까리 한다는 것도 사실이다.

---

---