위키원
"웹개발방법론"의 두 판 사이의 차이
| 4번째 줄: | 4번째 줄: | ||
불과 1~2년 전만해도 웹을 기반으로 하는 어플리케이션의 개발은 특정 몇몇 웹개발자들만이 할 수 있는 고유한 영역이었다. 하지만 이제는 인터넷과 웹이 대중화됨으로 인해서, 웹이라는 환경이 프로그래머라면 당연히 경험해야 하는 필수과목이 되었다. 클라이언트/서버(이하 “C/S") 환경에서만 익숙한 개발자들도 웹과의 연동에 대한 솔류션과 기술을 보유해야만 하는게 현실이다. 많은 고객들이 웹을 통한 서비스를 요청하고 있기 때문이다. | 불과 1~2년 전만해도 웹을 기반으로 하는 어플리케이션의 개발은 특정 몇몇 웹개발자들만이 할 수 있는 고유한 영역이었다. 하지만 이제는 인터넷과 웹이 대중화됨으로 인해서, 웹이라는 환경이 프로그래머라면 당연히 경험해야 하는 필수과목이 되었다. 클라이언트/서버(이하 “C/S") 환경에서만 익숙한 개발자들도 웹과의 연동에 대한 솔류션과 기술을 보유해야만 하는게 현실이다. 많은 고객들이 웹을 통한 서비스를 요청하고 있기 때문이다. | ||
이러한 정보기술의 흐름에 맞추어, 여러 회사에서 웹환경을 기반으로 하는 많은 어플리케이션을 개발하였고, 많은 개발자들이 웹에 대한 많은 관심을 가지고 있다. 하지만 어떤 절차를 거쳐서 웹어플리케이션을 만드는 것이 효율적인지에 대한 길잡이 역할을 하는 지침서나 안내서가 없기에 개별적인 여러움과 시행착오가 있었다. | 이러한 정보기술의 흐름에 맞추어, 여러 회사에서 웹환경을 기반으로 하는 많은 어플리케이션을 개발하였고, 많은 개발자들이 웹에 대한 많은 관심을 가지고 있다. 하지만 어떤 절차를 거쳐서 웹어플리케이션을 만드는 것이 효율적인지에 대한 길잡이 역할을 하는 지침서나 안내서가 없기에 개별적인 여러움과 시행착오가 있었다. | ||
| − | 작은 움막을 지을 때는 설계도가 필요가 없지만 큰 집을 지을 때는 설계도는 반드시 필요하다. 웹환경의 어플리케이션들도 초기의 작은 집을 벗어나 이제 그 규모가 커지고 있다. 이에 이 글에서는 웹어플리케이션을 어떤 방법을 통해서 개발을 하며, 어떤 진행절차를 통해서 개발을 하는 것이 효율적인가에 대해서 많지 않은 개발경험을 바탕으로 설명하고자 한다. <ref name="개요">까만손오공, 〈[https://m.blog.naver.com/PostView.nhn?blogId=kkson50&logNo=120172560481&proxyReferer=https:%2F%2Fwww.google.com%2F 웹개발방법론]〉, 《네이버 블로그》, 2012-11-04</ref> | + | 작은 움막을 지을 때는 설계도가 필요가 없지만 큰 집을 지을 때는 설계도는 반드시 필요하다. 웹환경의 어플리케이션들도 초기의 작은 집을 벗어나 이제 그 규모가 커지고 있다. 이에 이 글에서는 웹어플리케이션을 어떤 방법을 통해서 개발을 하며, 어떤 진행절차를 통해서 개발을 하는 것이 효율적인가에 대해서 많지 않은 개발경험을 바탕으로 설명하고자 한다. <ref name="개요">까만손오공, 〈[https://m.blog.naver.com/PostView.nhn?blogId=kkson50&logNo=120172560481&proxyReferer=https:%2F%2Fwww.google.com%2F 웹개발방법론 - 1999년 발표된 자료 / 지금도 유용할 듯해서 올려요]〉, 《네이버 블로그》, 2012-11-04</ref> |
== 특징 == | == 특징 == | ||
| − | === | + | 웹애플리케이션(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환경의 애플리케이션이 매뉴라는 윈도우의 자원을 쓰는것과 대조적이다. 따라서 웹환경에서는 화면간의 연결이 포함이 되게 모델링 작업을 해야한다. | ||
| + | |||
| + | == 종류 == | ||
| + | === 네이비브 앱 === | ||
| + | === 모바일 웹 === | ||
| + | === 하이브리드 앱 === | ||
{{각주}} | {{각주}} | ||
2020년 9월 15일 (화) 10:15 판
웹개발방법론(WDM; Web Development Methodology)은 인터넷 웹사이트 개발 방법에 대한 이론으로서, 웹사이트 개발 과정, 절차, 방법, 산출물, 도구 등을 체계적으로 정리하고 표준화시킨 것이다. 소프트웨어 개발방법론의 일종이다.
목차
개요
불과 1~2년 전만해도 웹을 기반으로 하는 어플리케이션의 개발은 특정 몇몇 웹개발자들만이 할 수 있는 고유한 영역이었다. 하지만 이제는 인터넷과 웹이 대중화됨으로 인해서, 웹이라는 환경이 프로그래머라면 당연히 경험해야 하는 필수과목이 되었다. 클라이언트/서버(이하 “C/S") 환경에서만 익숙한 개발자들도 웹과의 연동에 대한 솔류션과 기술을 보유해야만 하는게 현실이다. 많은 고객들이 웹을 통한 서비스를 요청하고 있기 때문이다. 이러한 정보기술의 흐름에 맞추어, 여러 회사에서 웹환경을 기반으로 하는 많은 어플리케이션을 개발하였고, 많은 개발자들이 웹에 대한 많은 관심을 가지고 있다. 하지만 어떤 절차를 거쳐서 웹어플리케이션을 만드는 것이 효율적인지에 대한 길잡이 역할을 하는 지침서나 안내서가 없기에 개별적인 여러움과 시행착오가 있었다. 작은 움막을 지을 때는 설계도가 필요가 없지만 큰 집을 지을 때는 설계도는 반드시 필요하다. 웹환경의 어플리케이션들도 초기의 작은 집을 벗어나 이제 그 규모가 커지고 있다. 이에 이 글에서는 웹어플리케이션을 어떤 방법을 통해서 개발을 하며, 어떤 진행절차를 통해서 개발을 하는 것이 효율적인가에 대해서 많지 않은 개발경험을 바탕으로 설명하고자 한다. [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환경의 애플리케이션이 매뉴라는 윈도우의 자원을 쓰는것과 대조적이다. 따라서 웹환경에서는 화면간의 연결이 포함이 되게 모델링 작업을 해야한다.
종류
네이비브 앱
모바일 웹
하이브리드 앱
각주
- ↑ 까만손오공, 〈웹개발방법론 - 1999년 발표된 자료 / 지금도 유용할 듯해서 올려요〉, 《네이버 블로그》, 2012-11-04
참고 자료
같이 보기
