의견.png

"웹개발방법론"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
7번째 줄: 7번째 줄:
  
 
== 특징 ==
 
== 특징 ==
 +
=== 개발 절차 ===
 +
; 웹화면연결도
 +
연결이란 하나의 웹화면에서 다른 웹화면으로 이동하는 길을 말하는 것으로 HTML 상으로는 <a>태그나 Form의 submit 등을 말한다.
 +
웹화면연결도란 웹환경으로 구현하려는 시스템의 업무분석결과를 도출해내는 도구이자 산출물로써 실제로 구현할 화면간의 연결이 어떻게 되는지를 간단명료하게 도식화해서 나다낸 것을 말한다. 웹의 특징인 HyperLink에 중점을 둔 모델링 방법이다.
 +
웹화면과 웹모듈이 일대일 대응인 경우는 가장 전형적이다. 웹어플리케이션 개발 초기에 이러한 방식으로 많이들 개발을 하였다.
 +
웹화면과 웹모듈이 다대일의 관계일 경우는 하나의 웹모듈만 고치면 다수의 웹화면이 수정이 되서 유지보수의 장점이 있는 반면에, 여러가지 웹화면을 고려하여야 하며 웹모듈의 소스가 복잡해지는 단점이 있다. 다음과 같은 경우일 때 웹하면과 웹모듈이 다대일의 관계가 될 수 있다.
 +
 +
* 첫째, 두개의 웹화면의 차이가 근소한 경우이다. 한글과 영문의 방명록일 경우는 다른 모듈로 개발을 할 필요가 없다. 매개변수를 하나 만들어서, 매개변수에 따라서 한글로 보여주거나, 영문으로 보여주거나 하면 된다.
 +
 +
* 둘째, 웹화면이 단순한 경우이다. 이럴 경우는 이어지는 다음 웹화면이나 이전 웹화면과 합쳐서 하나의 웹모듈로 만들 수도 있다.
 +
 +
; 매개항목할당표 작성
 +
매개항목이란 웹화면사이의 정보교환을 위해서 주고받는 자료들을 말한다. GET방식일 경우는 URL에 직접나타나면서 QUERY_STRING이라는 환경변수를 이용하여 정보를 주고 받고, POST방식일 경우는 표준입력을 이용하여 정보를 주고 받는다.
 +
매개항목할당표는 웹화면연결도에 나타나는 각각의 연결에 어떠한 매개항목들이 있어야 하는지를 표를 이용하여 나타낸 것을 말한다. 웹화면연결도와 매개항목할당표은 구현하려는 업무의 처리과정을 이해하기 위하여 항상 함께 고려가 되어야 한다. 매개항목할당표가 없는 연결은 구체성을 잃게 된다.
 +
 +
; 매개항목설명서
 +
매개항목설명서란 각각의 매개항목들이 어떠한 의미를 가지면 단위 및 값은 어떻게 가질 수 있고, 실제 URL상에서 어떤 변수명으로 나타나는지에 대한 설명서이다.
 +
 +
; 데이타베이스및 파일 설계
 +
매개항목할당표 및 매개항목설명서를 바탕으로 데이타베이스및 파일을 설계한다.
 +
코드및 예제 데이타의 입력도 SQL이나 프로시져 등으로 미리 만들어 놓고, 웹어플리케이션을 개발하는 과정에서 테스트를 위한 별도의 데이타 입력이 없도록 한다. 많은 개발자가 이런 예제 데이타의 입력을 간과하고 개발에 임하는 데, 개발전에 미리 예제데이타를 만들어 주는 것이 개발속도를 빠르게 해주며 다양한 테스트를 할 수 있도록 해준다.
 +
 +
; 웹모듈 설명서
 +
웹모듈 설명서는 구체적으로 각각의 웹모듈의 화면이 어떻게 구성이 되어있으면 어떠한 화면에서 연결이 되어서 어떤 화면으로 연결이 되는지를 자세하게 설명한 문서를 말한다.
 +
 +
; HTML 제작 및 검수
 +
웹화면이 실제로 나타나는 모습을 미리 HTML과 Image작업을 해야 한다. 웹의 특징이 웹화면구성요소를 개발후에 마음대로 위치나 크기를 바꾸기가 쉽지 않으므로 개발전에 전문 웹디자이너가 화면의 레이아웃을 미리 디자인하고 고객(사)으로 부터 검수를 받고 디자인을 확정해야 한다.
 +
여기에는 기본적인 HTML파일을 포함하여, 화면에 나오는 각 종 그림들, 그리고 다양한 멀티미디어 파일의 제작, 클라이언트 스크립팅 등이 포함이 된다.
 +
 +
; 웹어플리케이션 코딩
 +
코딩은 웹모듈 설명서를 기본으로 해서 작성을 한다. 아래는 실제로 코딩하는 과정에서 간과하기 쉬운 점들만을 골라서 열거하였다.
 +
 +
* 목록을 나타내는 항목에는 페이지별로 잘 구분해서 나타내는가? 조회하려는 항목이 많을 때는 적당한 개수만큼 한 화면에 뿌려주어야 한다.
 +
 +
* 조회하려는 목록에 데이터가 없을 때는 어떤식으로 나타내는가? 아무런 메시지를 주지 않는 것보다는 조회한 데이터가 없는지에 대한 친절한 설명을 한다.
 +
 +
* 목록을 나타내는 화면에서 가져올 수 있는 레코드의 개수는 제한이 있는가? 아직 데이터가 많지 않다고 해서, 모든 데이터를 가져온다거나, 모든 페이지의 번호를 보여주어서는 안된다. 최대로 많이 가져올 수 있는 레코드의 수를 설정해야 한다.
 +
 +
* 필요한 모든 연결은 시켰는가? ‘묻고 답하기’의 게시판을 만들면 ‘질문’과 ‘답변’과의 상호 연결이 있어야 하며, E-mail이 있는 사용자에게는 이름을 클릭했을 때, 바로 메일을 쓸 수 있게 해야 한다.
 +
 +
* 사용자의 입력을 받는 폼에서 첫 입력필드로 커서가 이동을 하는가? 이것은 사용자로 하여금 입력을 위해 마우스를 움직여 커서를 입력필드로 위치시키는 행동을 필요없게 해준다. 간단한 자바스크립트로 구현을 할 수 가 있는데, 이런 세심한 배려를 해주는 사이트가 적다.
 +
 +
* 사용자의 입력을 받는 폼에서 데이터의 점검을 제대로하고 서버에 보내는가? 사용자의 입력한 폼에서 데이터를 점검하기 위해 자바스크립트가 많이 사용이 된다. 하지만 입력을 하지 않은 필드나 적절하게 입력되지 않은 필드로 인해서 자바스크립트 에러가 발생하는 경우가 있다.
 +
 +
* 중요한 의사결정을 하는 과정에서 한번 더 확인을 하는가? 게시물을 삭제하는 행위를 다시 복구할 수 없는 의사결정이다. 이와 같은 경우에 자바스크립트등을 이용해서 한번 더 확인하는 것은 중요하다.
 +
 +
* 동일한 용어를 사용하는가? 테이블의 필드마다 고유한 우리말 이름이 따라다니게 되는 데, 이것이 웹화면마다 다르게 나타날 수 있다. 이는 화면에서는 ‘제목’, 다른 화면에서는 ‘글제목’ 과 같은 경우이다.
 +
 +
* 사용자가 URL 조작으로 에러를 일으킬 염려는 없는가? 웹모듈로 넘어가는 URL안의 매개변수는 웹브라우저에서 쉽게 볼 수가 있기 때문에서 사용자가 손쉽게 조작을 해서 웹모듈을 실행시킬 수가 있다. 반드시 받아야할 매개변수를 사용자에 의해서 받지 못하거나, 잘못된 데이터를 받았을 경우 웹모듈은 제대로 작동하는지 살펴야 한다.
 +
 +
* 사용자가 HIDDEN값의 조작으로 예상치 않은 웹화면으로 갈 수 있는가? HIDDEN값은 사용자의 입력은 필요가 없지만 다음의 웹화면으로 이동을 할 때 필요한 매개변수이다. 이것을 사용자가 조작을 했을 경우(예를 들어, 자신의 PC로 파일을 다운로드 받아서 HIDDEN값을 고친후 실행을 시켰을 때) 예기치 않은 결과가 일어날 수 있는지 확인을 해야 한다.
 +
 +
* 각각의 웹화면은 자신의 정보를 갖고 있는가? 각각의 웹화면은 자기 고유의 제목(HTML의 TITLE)를 가져야 하고, 웹화면에서도 현재의 화면에 대한 제목이 그림이나 글로 있어야 하며, 목록조회를 하는 웹화면은 현재 몇 페이지를 보고 있는지, 검색결과를 나타내는 웹화면은 검색조건이 무엇인지 등의 정보를 웹화면에 출력을 해야 한다. 즉, 각각의 웹화면은 전화면과 독립된 정보를 가지고 있어야 하며, 하나의 웹화면만을 출력해도 이전화면을 보지 않은 다른 사람이 그 내용을 이해할 수 있어야 한다.
 +
 +
;테스트
 +
테스트는 여러사람들이 같이 도와 주는 것이 필요하다. 그래야 프로그램의 미비한 점이나 버그등을 빠른 시간에 잡을 수가 있다. 테스트에 참여하는 사람은 수정할 사항에 대해서 말보다는 일정 양식을 이용해서 문서로서 전달을 한다. 테스트할 양식은 수정을 요하는 웹모듈명, 문제점, 개선방향 등이 포함이 되어 있어야 한다.
 +
HTML은 물리적은 형식이 아니라 논리적인 형식을 지향하기 때문에 하나의 브라우저만으로 테스트를 해서는 안된다. 대표적인 양대 브라우저인 넷스케이프(Netscape)사의 커뮤티케이터(Communicator)와 마이크로소프트(Microsoft)사의 익스플로어의 다양한 버전으로 테스트를 해야 한다. 다양한 브라우저가 아니라 특정한 브라우저만을 대상으로 하는 사이트일 경우는 첫화면에 추천브라우저와 버전이 표기되어 있어야 하겠다.<ref name="개요" />
 +
 +
=== 단점 ===
 
웹애플리케이션(Web Application)이란 웹브라우저를 기본 클라이언트하면서 서버나 클라이언트쪽에서의 실행되는 응용프로그램을 말한다. 여기에는 CGI 응용프로그램, 웹서버 API응용프로그램, 자바애플릿, 자바스크립트, ActiveX 등 모두 포함된다.
 
웹애플리케이션(Web Application)이란 웹브라우저를 기본 클라이언트하면서 서버나 클라이언트쪽에서의 실행되는 응용프로그램을 말한다. 여기에는 CGI 응용프로그램, 웹서버 API응용프로그램, 자바애플릿, 자바스크립트, ActiveX 등 모두 포함된다.
 
웹애플리케이션 개발은 C/S와 같은 점도 많이 있지만 여러 가지 다른 점도 많이 존재한다. 웹환경은 C/S환경에 비해 느린 전송속도, 어려운 사용자 인터페이스 변경, 자료흐름도(Data Flow Diagram)적용의 어려움을 들 수 있다.  
 
웹애플리케이션 개발은 C/S와 같은 점도 많이 있지만 여러 가지 다른 점도 많이 존재한다. 웹환경은 C/S환경에 비해 느린 전송속도, 어려운 사용자 인터페이스 변경, 자료흐름도(Data Flow Diagram)적용의 어려움을 들 수 있다.  
  
=== 단점 ===
 
 
; 느린 전송속도  
 
; 느린 전송속도  
 
C/S환경과 웹환경의 가장 큰 특징을 찾는다면 전송속도의 차이라고 할 수 있다. 이 전송속도의 차이는 두 가지의 원인에서 찾을 수가 있다.
 
C/S환경과 웹환경의 가장 큰 특징을 찾는다면 전송속도의 차이라고 할 수 있다. 이 전송속도의 차이는 두 가지의 원인에서 찾을 수가 있다.

2020년 9월 15일 (화) 11:32 판

웹개발방법론(WDM; Web Development Methodology)은 인터넷 웹사이트 개발 방법에 대한 이론으로서, 웹사이트 개발 과정, 절차, 방법, 산출물, 도구 등을 체계적으로 정리하고 표준화시킨 것이다. 소프트웨어 개발방법론의 일종이다.

개요

불과 1~2년 전만해도 웹을 기반으로 하는 어플리케이션의 개발은 특정 몇몇 웹개발자들만이 할 수 있는 고유한 영역이었다. 하지만 이제는 인터넷과 웹이 대중화됨으로 인해서, 웹이라는 환경이 프로그래머라면 당연히 경험해야 하는 필수과목이 되었다. 클라이언트/서버(이하 “C/S") 환경에서만 익숙한 개발자들도 웹과의 연동에 대한 솔류션과 기술을 보유해야만 하는게 현실이다. 많은 고객들이 웹을 통한 서비스를 요청하고 있기 때문이다. 이러한 정보기술의 흐름에 맞추어, 여러 회사에서 웹환경을 기반으로 하는 많은 어플리케이션을 개발하였고, 많은 개발자들이 웹에 대한 많은 관심을 가지고 있다. 하지만 어떤 절차를 거쳐서 웹어플리케이션을 만드는 것이 효율적인지에 대한 길잡이 역할을 하는 지침서나 안내서가 없기에 개별적인 여러움과 시행착오가 있었다. 작은 움막을 지을 때는 설계도가 필요가 없지만 큰 집을 지을 때는 설계도는 반드시 필요하다. 웹환경의 어플리케이션들도 초기의 작은 집을 벗어나 이제 그 규모가 커지고 있다. 이에 이 글에서는 웹어플리케이션을 어떤 방법을 통해서 개발을 하며, 어떤 진행절차를 통해서 개발을 하는 것이 효율적인가에 대해서 많지 않은 개발경험을 바탕으로 설명하고자 한다. [1]

특징

개발 절차

웹화면연결도

연결이란 하나의 웹화면에서 다른 웹화면으로 이동하는 길을 말하는 것으로 HTML 상으로는 <a>태그나 Form의 submit 등을 말한다. 웹화면연결도란 웹환경으로 구현하려는 시스템의 업무분석결과를 도출해내는 도구이자 산출물로써 실제로 구현할 화면간의 연결이 어떻게 되는지를 간단명료하게 도식화해서 나다낸 것을 말한다. 웹의 특징인 HyperLink에 중점을 둔 모델링 방법이다. 웹화면과 웹모듈이 일대일 대응인 경우는 가장 전형적이다. 웹어플리케이션 개발 초기에 이러한 방식으로 많이들 개발을 하였다. 웹화면과 웹모듈이 다대일의 관계일 경우는 하나의 웹모듈만 고치면 다수의 웹화면이 수정이 되서 유지보수의 장점이 있는 반면에, 여러가지 웹화면을 고려하여야 하며 웹모듈의 소스가 복잡해지는 단점이 있다. 다음과 같은 경우일 때 웹하면과 웹모듈이 다대일의 관계가 될 수 있다.

  • 첫째, 두개의 웹화면의 차이가 근소한 경우이다. 한글과 영문의 방명록일 경우는 다른 모듈로 개발을 할 필요가 없다. 매개변수를 하나 만들어서, 매개변수에 따라서 한글로 보여주거나, 영문으로 보여주거나 하면 된다.
  • 둘째, 웹화면이 단순한 경우이다. 이럴 경우는 이어지는 다음 웹화면이나 이전 웹화면과 합쳐서 하나의 웹모듈로 만들 수도 있다.
매개항목할당표 작성

매개항목이란 웹화면사이의 정보교환을 위해서 주고받는 자료들을 말한다. GET방식일 경우는 URL에 직접나타나면서 QUERY_STRING이라는 환경변수를 이용하여 정보를 주고 받고, POST방식일 경우는 표준입력을 이용하여 정보를 주고 받는다. 매개항목할당표는 웹화면연결도에 나타나는 각각의 연결에 어떠한 매개항목들이 있어야 하는지를 표를 이용하여 나타낸 것을 말한다. 웹화면연결도와 매개항목할당표은 구현하려는 업무의 처리과정을 이해하기 위하여 항상 함께 고려가 되어야 한다. 매개항목할당표가 없는 연결은 구체성을 잃게 된다.

매개항목설명서

매개항목설명서란 각각의 매개항목들이 어떠한 의미를 가지면 단위 및 값은 어떻게 가질 수 있고, 실제 URL상에서 어떤 변수명으로 나타나는지에 대한 설명서이다.

데이타베이스및 파일 설계

매개항목할당표 및 매개항목설명서를 바탕으로 데이타베이스및 파일을 설계한다. 코드및 예제 데이타의 입력도 SQL이나 프로시져 등으로 미리 만들어 놓고, 웹어플리케이션을 개발하는 과정에서 테스트를 위한 별도의 데이타 입력이 없도록 한다. 많은 개발자가 이런 예제 데이타의 입력을 간과하고 개발에 임하는 데, 개발전에 미리 예제데이타를 만들어 주는 것이 개발속도를 빠르게 해주며 다양한 테스트를 할 수 있도록 해준다.

웹모듈 설명서

웹모듈 설명서는 구체적으로 각각의 웹모듈의 화면이 어떻게 구성이 되어있으면 어떠한 화면에서 연결이 되어서 어떤 화면으로 연결이 되는지를 자세하게 설명한 문서를 말한다.

HTML 제작 및 검수

웹화면이 실제로 나타나는 모습을 미리 HTML과 Image작업을 해야 한다. 웹의 특징이 웹화면구성요소를 개발후에 마음대로 위치나 크기를 바꾸기가 쉽지 않으므로 개발전에 전문 웹디자이너가 화면의 레이아웃을 미리 디자인하고 고객(사)으로 부터 검수를 받고 디자인을 확정해야 한다. 여기에는 기본적인 HTML파일을 포함하여, 화면에 나오는 각 종 그림들, 그리고 다양한 멀티미디어 파일의 제작, 클라이언트 스크립팅 등이 포함이 된다.

웹어플리케이션 코딩

코딩은 웹모듈 설명서를 기본으로 해서 작성을 한다. 아래는 실제로 코딩하는 과정에서 간과하기 쉬운 점들만을 골라서 열거하였다.

  • 목록을 나타내는 항목에는 페이지별로 잘 구분해서 나타내는가? 조회하려는 항목이 많을 때는 적당한 개수만큼 한 화면에 뿌려주어야 한다.
  • 조회하려는 목록에 데이터가 없을 때는 어떤식으로 나타내는가? 아무런 메시지를 주지 않는 것보다는 조회한 데이터가 없는지에 대한 친절한 설명을 한다.
  • 목록을 나타내는 화면에서 가져올 수 있는 레코드의 개수는 제한이 있는가? 아직 데이터가 많지 않다고 해서, 모든 데이터를 가져온다거나, 모든 페이지의 번호를 보여주어서는 안된다. 최대로 많이 가져올 수 있는 레코드의 수를 설정해야 한다.
  • 필요한 모든 연결은 시켰는가? ‘묻고 답하기’의 게시판을 만들면 ‘질문’과 ‘답변’과의 상호 연결이 있어야 하며, E-mail이 있는 사용자에게는 이름을 클릭했을 때, 바로 메일을 쓸 수 있게 해야 한다.
  • 사용자의 입력을 받는 폼에서 첫 입력필드로 커서가 이동을 하는가? 이것은 사용자로 하여금 입력을 위해 마우스를 움직여 커서를 입력필드로 위치시키는 행동을 필요없게 해준다. 간단한 자바스크립트로 구현을 할 수 가 있는데, 이런 세심한 배려를 해주는 사이트가 적다.
  • 사용자의 입력을 받는 폼에서 데이터의 점검을 제대로하고 서버에 보내는가? 사용자의 입력한 폼에서 데이터를 점검하기 위해 자바스크립트가 많이 사용이 된다. 하지만 입력을 하지 않은 필드나 적절하게 입력되지 않은 필드로 인해서 자바스크립트 에러가 발생하는 경우가 있다.
  • 중요한 의사결정을 하는 과정에서 한번 더 확인을 하는가? 게시물을 삭제하는 행위를 다시 복구할 수 없는 의사결정이다. 이와 같은 경우에 자바스크립트등을 이용해서 한번 더 확인하는 것은 중요하다.
  • 동일한 용어를 사용하는가? 테이블의 필드마다 고유한 우리말 이름이 따라다니게 되는 데, 이것이 웹화면마다 다르게 나타날 수 있다. 이는 화면에서는 ‘제목’, 다른 화면에서는 ‘글제목’ 과 같은 경우이다.
  • 사용자가 URL 조작으로 에러를 일으킬 염려는 없는가? 웹모듈로 넘어가는 URL안의 매개변수는 웹브라우저에서 쉽게 볼 수가 있기 때문에서 사용자가 손쉽게 조작을 해서 웹모듈을 실행시킬 수가 있다. 반드시 받아야할 매개변수를 사용자에 의해서 받지 못하거나, 잘못된 데이터를 받았을 경우 웹모듈은 제대로 작동하는지 살펴야 한다.
  • 사용자가 HIDDEN값의 조작으로 예상치 않은 웹화면으로 갈 수 있는가? HIDDEN값은 사용자의 입력은 필요가 없지만 다음의 웹화면으로 이동을 할 때 필요한 매개변수이다. 이것을 사용자가 조작을 했을 경우(예를 들어, 자신의 PC로 파일을 다운로드 받아서 HIDDEN값을 고친후 실행을 시켰을 때) 예기치 않은 결과가 일어날 수 있는지 확인을 해야 한다.
  • 각각의 웹화면은 자신의 정보를 갖고 있는가? 각각의 웹화면은 자기 고유의 제목(HTML의 TITLE)를 가져야 하고, 웹화면에서도 현재의 화면에 대한 제목이 그림이나 글로 있어야 하며, 목록조회를 하는 웹화면은 현재 몇 페이지를 보고 있는지, 검색결과를 나타내는 웹화면은 검색조건이 무엇인지 등의 정보를 웹화면에 출력을 해야 한다. 즉, 각각의 웹화면은 전화면과 독립된 정보를 가지고 있어야 하며, 하나의 웹화면만을 출력해도 이전화면을 보지 않은 다른 사람이 그 내용을 이해할 수 있어야 한다.
테스트

테스트는 여러사람들이 같이 도와 주는 것이 필요하다. 그래야 프로그램의 미비한 점이나 버그등을 빠른 시간에 잡을 수가 있다. 테스트에 참여하는 사람은 수정할 사항에 대해서 말보다는 일정 양식을 이용해서 문서로서 전달을 한다. 테스트할 양식은 수정을 요하는 웹모듈명, 문제점, 개선방향 등이 포함이 되어 있어야 한다. HTML은 물리적은 형식이 아니라 논리적인 형식을 지향하기 때문에 하나의 브라우저만으로 테스트를 해서는 안된다. 대표적인 양대 브라우저인 넷스케이프(Netscape)사의 커뮤티케이터(Communicator)와 마이크로소프트(Microsoft)사의 익스플로어의 다양한 버전으로 테스트를 해야 한다. 다양한 브라우저가 아니라 특정한 브라우저만을 대상으로 하는 사이트일 경우는 첫화면에 추천브라우저와 버전이 표기되어 있어야 하겠다.[1]

단점

웹애플리케이션(Web Application)이란 웹브라우저를 기본 클라이언트하면서 서버나 클라이언트쪽에서의 실행되는 응용프로그램을 말한다. 여기에는 CGI 응용프로그램, 웹서버 API응용프로그램, 자바애플릿, 자바스크립트, ActiveX 등 모두 포함된다. 웹애플리케이션 개발은 C/S와 같은 점도 많이 있지만 여러 가지 다른 점도 많이 존재한다. 웹환경은 C/S환경에 비해 느린 전송속도, 어려운 사용자 인터페이스 변경, 자료흐름도(Data Flow Diagram)적용의 어려움을 들 수 있다.

느린 전송속도

C/S환경과 웹환경의 가장 큰 특징을 찾는다면 전송속도의 차이라고 할 수 있다. 이 전송속도의 차이는 두 가지의 원인에서 찾을 수가 있다.

  • 첫째, C/S는 한번 클라이언트와 서버가 연결을 맺은 다음에는 연결상태를 계속 유지하게 되는데, 웹은 서버에서 불러오는 각각의 파일마다 각각의 연결을 맺는다. 따라서 이미지 파일이 4개 들어있는 HTML파일을 웹브라우저가 불러들일 때는 HTML파일을 포함하여 모두 5번의 연결을 맺었다 끊었다 하는 작업을 반복한다. 이것은 HTTP프로토콜 자체가 한번에 여러파일을 전송하는 것을 지원하지 않기 때문이다.
  • 둘째, C/S는 사내망이나 직접 연결된 전용선을 통해서 자료의 전송이 이루어지는데, 웹은 몇번의 노드를 거쳐서 연결이 되는 인터넷망을 기본으로 하고 있다. 물론 물리적으로 바로 연결이 되는 웹서버와 웹브라우저도 있겠지만, 일반적으로 웹서버를 찾기 위한 시간과 자료 전송의 시간이 C/S보다는 훨씬 많이 걸린다.

이러한 이유로 인해서 웹개발자는 웹브라우저가 받는 데이터의 크기를 줄이기 위해 노력을 했다. 사용하는 색을 줄여서 그림파일의 크기를 줄이고, 자바 클래스도 최소한의 상속을 받아서 코딩을 하거나, 필요한 그래픽 파일은 하나의 그래픽 파일로 만든 후 잘라서 사용하는 방식 등이 사용되고 있다. 웹 클라이언트 측에서는 불필요한 서버와의 연결을 피하기 위해 폼을 통하여 사용자의 입력을 받은 후에는 자바스크립트 등의 클라이언트 스크립팅 기술을 이용하여 입력자료를 검사한 후에 웹서버로 보내거나, 자바스크립트 변수에 필요한 정보를 저장하고 있다가 document.write를 이용하여 클라이언트 측에서 HTML을 생성하는 방법도 사용되고 있다.

어려운 사용자 인터페이스 변경

C/S환경에서의 대부분의 개발 툴들은, 사용자에게 보여주는 화면을 개발자 임의대로 바꿀 수 있고, 컴파일 후에도 쉽게 고칠 수 있다. 개발툴들이 위지윅(WYSIWYG, What You See Is What You Get)을 지원하기 때문에, 위치를 변경하거나 새로운 컴포넌트를 추가하려고 할 때는 마우스로 원하는 위치와 크기만을 지정하면 된다. 하지만 웹환경에서는 아직 위지윅을 C/S환경처럼 자유롭게 지원하는 툴이 없고, HTML이라는 마크업 언어 자체가 물리적인 위치를 지정하는 데 쓰이는 언어가 아니기 때문에 웹브라우저에서 나타나는 모습에 대해 정밀한 제어를 할 수 없다. 또한 HTML을 화면에 나타내는 모양도 브라우저마다 차이가 나게 된다. 물론 이를 극복하기 위한 CSS나 XML 등의 기술이 발전하고 있지만 아직은 요원한 상태이다. 따라서 웹시스템 설계자들은 그래픽 디자이너에게 각각의 웹화면의 모양과 그 안에 들어갈 컴포턴트와 이미지들을 기술한 '웹모듈설명서'를 미리 작성해야 한다. '웹모듈설명서'에 의해서 웹디자이너는 HTML코딩과 이미지 작업을 하고, 이를 바탕으로 프로그래머는 코딩을 해야 한다. 한 번 코딩이 된 웹화면의 인터페이스를 바꾸기 위해서는 프로그래머가 HTML과 자바스크립트를 능숙하게 구사할 수 있어야 한다.

자료흐름도 적용의 어려움

C/S환경에서 업무분석을 하는 방법론에는 여러 가지가 있는데 그 중에서도 자료 흐름도는 대상 업무를 모델링하는데 가장 중요한 도구로 사용되어 왔다. C/S에서는 자료흐름도를 바탕으로 자료사전 및 미니명세서를 작성한 후에 데이터베이스와 소프트웨어를 설계하는 과정으로 이동하게 된다. 하지만 웹을 기반으로 하는 개발환경에서는 이와 같은 자료흐름도를 대상업무를 분석하는데 사용할 수 없다. 그 이유는 다음과 같다.

  • 첫째, 웹브라우저는 단순히 서버에서 보내진 데이터를 HTTP규약에 맞게 사용자에게 보여주는 역할만을 하지만, C/S환경에서의 클라이언트는 컨트롤에 대한 레이아웃에 대한 정보 및 이벤트 처리에 관한 루틴을 포함하고 있다. 따라서 웹브라우저는 필요한 모든 정보(화면 레이아웃, 데이터 등)를 웹서버에서 받아와야 하는 반면에, C/S에서는 꼭 필요한 정보만을 클라이언트에서 가져오고, 나머지 부분은 클라이언트가 처리할 수 있다.
  • 둘째, 웹브라우저는 서버에서 보내온 HTML만을 화면에서 보여주고 연결을 끊기 때문에 더 이상의 화면에 변화가 없다. 따라서 웹화면에 부분적인 변화를 줄 수는 없고, 변화된 전체 페이지를 서버에서 가져와 다시 화면에 보여줘야 한다. 이는 C/S환경에서 특정 컴포넌트 내용을 데이터베이스에서 가져와 쉽게 바꿀 수 있는것과 대조적이다.
  • 셋째, 웹브라우저에서는 별도의 매뉴가 존재하지 않고, 각각의 화면들에 산재하여 존재한다. 이것은 C/S환경의 애플리케이션이 매뉴라는 윈도우의 자원을 쓰는것과 대조적이다. 따라서 웹환경에서는 화면간의 연결이 포함이 되게 모델링 작업을 해야한다.[1]

종류

네이비브 앱

모바일 웹

하이브리드 앱

각주

  1. 1.0 1.1 1.2 까만손오공, 〈웹개발방법론 - 1999년 발표된 자료 / 지금도 유용할 듯해서 올려요〉, 《네이버 블로그》, 2012-11-04

참고 자료

같이 보기


  의견.png 이 웹개발방법론 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.