웹 사이트 공학 (Web Site Engineering)

다음은 1999년 8월 2일에 HCI연구회 칼럼에 올린 글이다.
1993년 지금의 넷스케이프의 전신인 모자익이 나왔을 당시 고퍼나 아치, 메일 시스템 등과 같은 인터넷 사용환경은 텍스트 일변도였다.
여기에 웹은 풍부한 텍스트와 이미지, 음성, 동영상 등의 멀티 미디어와 그래픽 사용자 환경으로 학술망이었던 인터넷을 일반인들도 쉽게 접할 수 있고 사용할 수 있도록 하는데 큰 공헌을 했다.
인터넷이 넷트웍의 넷트웍으로 공개와 공유의 대 원칙 아래서 지금의 정보화 사회의 초석이 되고, 사이버 세계를 열 수 있었던 것은 바로 웹이 인터넷의 미디어로서 그 역할을 수행했기 때문이 아닌가 싶다.
오늘 날 웹은 신문, 잡지, 책등의 온라인 출판뿐 아니라, 전자상거래, 금융, 가상 공동체, 마케팅, 광고 등의 다양한 분야에서 실생활과 연계를 하고 있고, 기업에서도 웹 사이트가 제품 홍보 뿐 아니라 제품의 판매, 마케팅 등 매출에 막대한 영향을 미치는 중요한 위치를 차지하게 되었다.
그러나 초기 웹사이트 들은 대부분 온라인 출판의 형태로 브로셔웨어 기능을 하였고, 사용자에게는 단방향적이고 정적인 형태였다. 즉, 웹 사이트 제공자가 사용자에게 일방적으로 정보를 제공하고, 종이 인쇄의 형태에서 디지털화된 형태로 온라인 상에 제공하는 수준이었다. 또한 이미지와 동영상등의 멀티미디어와 그래픽 사용자 인터페이스로 시각 디자이너들이 자연스럽게 웹 사이트 개발에 참여하게 되었고, 웹 사이트의 규모도 그리 크지 않았다.
점차 웹 사이트에 관한 기술이 발전하고, 방문자의 니즈가 증가함에 따라서 방문자와 웹 사이트와의 양방향 커뮤니케이션을 이루게 되었고, 웹사이트도 동적으로 변화하였다. 또한 CGI , Java, 데이타 베이스 처리 등 전산 기술들이 추가 되면서 웹 사이트는 더 이상 종이와 화면상의 컨텐츠 차이가 아니라 웹 기반의 전자우편 시스템, 인트라넷 MIS 시스템등 소프트웨어와 구분도 모호해 지게 되었다.
웹 사이트는 개인이나 기업, 국가에게도 그 중요성이 날로 증가 하고 있고, 그 규모는 점차 커지고 복잡해져 가고 있다. 또한 컨텐츠에 대한 비용이 증가하고, 전자상거래 작업이나 빠른 업데이트 등 웹 사이트에 대한 요구도 같이 증가하고 있다.
웹 사이트의 규모가 커지고 복잡해져감에 따라서 소수의 웹 디자이너들이 웹 사이트를 개발했던 것에서 개발에 필요한 인력과 그 역할을 나누게 되었고, 다른 제품 처럼 납기를 위한 일정 관리가 필요하게 되었다.
또한 웹 사이트에 대한 시장의 요구가 많아 짐에 따라서 생산성에 대한 문제가 발생했고, 그래픽 디자인, 정보설계, 탐색, 편집기술,  컨텐츠 등의 사용성을 향상시키는등의 품질 향상을 위한 노력을 하게 되었다.
웹 사이트 개발시 각 개발 단계에 대한 명확한 정의나 개발단계별 역할 및 산출물 등에 대한 정의가 거의 없는 것이 사실이다. 대부분 경험에 입각한 나름 대로의 개발 프로세스 들을 가지고 있다.
웹 사이트의 실패는 마케팅이나 그래픽 디자인, 탐색, 정보 디자인 자체의 잘못도 있지만, 그보다는 분석과 기획, 설계 단계의 결함이 더 심각하다. 테스트의 경우에도 단위 테스트, 통합 테스트, 사용환경별 테스트등의 정형화된 테스트 방법론도 거의 없어서 다양한 웹의 사용자들에게 웹 사이트가 원래 원하지 않는 모습을 보여 줄 수도 있는 것이다.
이렇듯 표준화된 개발 프로세스들을 가지고 있지 않는 경우, 일반적으로 웹 사이트의 생산성이 떨어지게 됨을 알 수 있다.
요즘에 이미 개발된 웹 사이트에 대해서 BPR(Busines Process Reengineering) 하듯이 다시 기획부터 시작해서 설계, 개발을 하거나 웹 사이트 평가나 클리닉에 대한 요구가 늘어나고 있는데, 이는 다른 이유도 있겠지만 아마도 개발 프로세스에 대한 이해 없이 구현에만 급급한 웹 사이트가 많아서이지 않나 싶다.
또 웹 사이트 개발에 있어서 품질 보증 활동도 거의 이루어지지 않고 있는 점도 심각한 문제점을 지적하고 싶다.
개발 단계별 산출물에 대한 정의도 없고, 개발 문서도 거의 없어서 나중에 유지보수나 웹 사이트 재 구축등을 할 때 심각한 문제가 발생하기도 한다.
국내에서도 많은 분야에서 품질에 대한 높은 관심으로 ISO 인증을 획득하기 위한 많은 노력을 하고 있다. 소프트웨어에도 여러개의 ISO 인증 제도가 있다. 그러나 웹 사이트 개발에 있어서는 아직 품질 보증 활동이 없는 것으로 알고 있다.
너무도 급격하게 발전하고 변화해서이기도 하지만, 소프트웨어와 온라인 출판등 어느 분야에도 확실히 속하지 않는 명확하지 않은 영역 때문일 수도 있을 것이다. 그렇지만 앞으로 웹 사이트에 대한 품질의 중요성이 커짐에 따라서 품질 활동은 분명 그 중요성이 커질 것이다.
그간의 웹 사이트는 그래픽 디자인이나 정보설계, 사용자 인터페이스등의 사용성 중심으로 개발되어 왔다면 이제 점점 웹 사이트 개발에 있어서 생산성이나 예산, 일정, 품질에 대한 문제점들이 서서히 나타나고 있다.
그렇다면 이러한 문제점 들을 어떻게 해결해야 할 까.
사실, 소프트웨어에서도 이와 비슷한 문제가 있었다.
1960년대 하드웨어 기술 발전 속도가 소프트웨어 기술 발전 속도 보다 빨라서 새로운 소프트웨어에 대한 시장의 요구를 감당하기 힘들었다. 또한 기존 소프트웨어에 대한 유지보수가 힘들어 졌고, 이러한 일련의 문제들은 인건비 상승 효과와 우수한 소프트웨어의 부족현상으로 악화되어 소프트웨어 생산성 문제에 직면하게 되었다. 이를 ‘소프트웨어 위기’ 라고 한다. 이러한 개발 예산 초과, 개발 일정의 지연, 저조한 생산성, 미흡한 품질등을 해결하기 위한 노력으로 소프트웨어 개발에 구조적이고 공학적인 접근방법을 시도하여 소프트웨어 공학(Software Engineering) 이란 학문으로 이러한 문제들을 연구해 오고 있다.
똑같은 문제는 아니지만 위에서 언급한것 처럼 웹사이트 개발에 있어서도 소프트웨어 위기 까지는 안된다 하더라도 개발 예산, 일정, 생산성, 품질 및 개발 프로세스등의 문제들은 비슷하다.
소프트웨어의 이러한 문제점을 해결하기 위하여 표준 방법론을 모색하고, 생산성과 품질을 향상시키기 위한 소프트웨어 공학을 웹 사이트 개발에 적용시키려고 하는 것이 바로 웹 사이트 공학(Web Site Engineering) 이다.
물론, 소프트웨어 공학을 그대로 웹 사이트 개발에 적용할 수는 없지만, 점차 웹 사이트가 소프트웨어 처럼 되어 가고 있고, 현재 웹 사이트 개발에 있어서 필요한 표준 개발 방법론이나 프로젝트 관리등을 소프트웨어 공학에서 적용시킬 수 있을 것이라고 본다.
그동안 웹 사이트 개발에 있어서 일련의 과정들에 대한 정형화되고 표준화된 작업 방법이 없었던 것이 사실이다. 따라서 예산과 개발 일정을 고려하고, 더 나은 생산성과 품질을 얻기 위해 기획, 설계, 개발, 그래픽 디자인, 정보 설계, 컨텐츠, 테스트, 유지보수 등의 일련의 과정들을 프로세스화 하고, 구조적으로 접근하는 방법등 웹 사이트 개발에 있어서 소프트웨어 공학의 이러한 표준 개발 방법론이나 프로젝트 관리, 품질 관리등을 적용시킨 다면 현재의 웹 사이트 개발에 있어서 돌파구를 찾을 수 있을 것이라고 본다.
 

6년 후 , 2005.09.25
이 칼럼을 쓴 1999년도 당시에는 점차 그래픽 디자인/산업 디자인 하는 사람들이 웹 시대가 되면서 뒙 디자이너라는 직업으로 자리잡고 있었다. 그리고, HTML 페이지로 정적으로 만들어지는 웹 사이트가 규모가 커지고 동적인 요구사항이 많아졌고 모든 것이 웹 플랫폼으로 이동하고 있었다.  나도 1996년도에 우리나라 최초라고 신문에 났던 삼성그룹의 인트라넷 처음 버전을 개발했었으니깐 말이다.
그 당시 웹 사이트는 서버를 운영하는 웹 매스터와 방명록, 게시판과 같은 프로그램 정도, 그리고 웹 디자이너가 만들었다. 나는 모든 것이 웹 프랫폼으로 바뀌면서 규모가 큰 웹 사이트는 처음 만들때 부터 운영/유지 보수를 하면서 문제가 발생할 것으로 생각했고, 실제로 일어났다. 1999년도에 Louis Rosenfeld and Peter Morville가 쓴  Information Architecture for World Wide Web 라는 책도 large scale 의 웹 사이트에서의 IA의 중요성을 제시했다. 연구회에서도 스터디를 했었다. 사실 이책은 웹 사이트를 대규모로 만들 때에는 구조가 중요하다는 메시지 밖에 없었다고 기억한다.
나는 웹 페이지를 그래픽 디자인 출신의 웹 디자이너가 공학적인 접근을 하지 않고 만들기 때문이라고 생각했고, 이 얘기를 칼럼으로 쓰기 전에 연구회 정모에서 얘기 했다가 디자이너들 한테 싫은 소리를 들었었다.
웹을 뉴미디어로 보는 견해도 있었지만, 나는 의미적인 측면 보다는 형식적인 측면과 무엇을 만들때에는 소프트웨어공학 방법론 밖에 몰랐기 때문에 웹도 소프트웨어라고 생각했고, 소프트웨어공학처럼 웹에도 개발 프로세스가 적용되어야 한다고 생각했었다.
그 당시 웹 에이전시라는 말이 생겨났고, 지금은 거의 사리지고 없지만 많은 웹 에이전시들이 생겨났었다. 그리고 웹 사이트 개발 방법론에 대해서 관심을 많이 두었던 것 같다.
 

 
그러고 보니 이 고민을 서진원 군에게 얘기했고, 서군은 자기 대학원에서 하고 있다는 책을 보내주어서 연구회에서 스터디를 했었다. 이 책은 전산학자가 쓴 것으로 기존의 소프트웨어공학 기초 정도의 개념을 웹 개발에 정말 빨리 적용해서 책을 쓴 것으로 생각했었다.
6년이 지난 지금 인터넷 업계라는 것이 시장으로 자리 잡고 있고, 우리나라에서는 웹 기획자, UI 기획자라는 이름의 역할이 생겨났고, 웹 프로그래머라는 이름도 생겨났고, HTML 코더까지도 생겨났다.
국내에서도 웹 사이트 개발에 대한 몇권의 책들이 나오는 등 나름대로의 소프트웨어 공학적인 접근이 되고 있고, 최근에는 프로젝트 관리기법도 웹 사이트 개발에 적용되고 있는 것 같다. 하지만 6년 전에 비해서 크게 달라진 것 같지는 않다.
아직도 예전의 프로그래머들이 했던 비지니스 기획 및 제품 기획을 웹 기획자 또는 사업기획자라는 역할이 하지만, 일하는 방법은 스스로 새로 만들고 있을 뿐이다. 사용자 인터페이스는 프로그래머 한테 만들게 해서 동작하는 것을 보고 다시 생각하고, 예전에 프로그래머들이 했던 데로 자기가 사용자를 가장 잘 안다고 생각하고 있다. 프로그래머들도 개발 언어와 플랫폼만 바뀌었지 아직도 설계 활동보다는 코딩을 먼저하고, 개발 문서는 최종 승인을 받을 때나 필요한 것으로 인식하고 있는 사람이 많은 것 같다.
역시나 방법론은 새로운 알고리즘 만큼 어려운 것이고, 동시에 사람들의 습관과 비슷한 것 같아서 알고리즘 보다 더 적용하기 어려운 것인지도 모른다.
학교 교육을 받을 때 무엇가에 대한 계획을 세우고, 방법을 세우고, 실행하고, 반성하는 식으로 받지 않았는데, 직장에서 어찌 일하는 방법이 몸에 익혀졌겠는가. 여기에 문서화는 텍도 없는 소리일 것이다.
튼튼한 웹 사이트 개발 방법론이 어딘가에 있을 지도 모른다.  그렇지만 웬만한 대가가 아니고서는 뭔가의 방법론을 만드는 것은 어려운 일이다. 다만  내가 할 수 있는 일은 내가 하는 일을 혁신하는 것이고, 그러기 위해서 내가 하는 일과 그 과정을 같이 고민할 뿐이다.