웹개발방법론
웹개발방법론(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파일을 포함하여, 화면에 나오는 각 종 그림들, 그리고 다양한 멀티미디어 파일의 제작, 클라이언트 스크립팅 등이 포함이 된다.
- 웹 애플리케이션 코딩
코딩은 웹모듈 설명서를 기본으로 해서 작성을 한다. 아래는 실제로 코딩하는 과정에서 간과하기 쉬운 점들만을 골라서 열거하였다.
- 조회하려는 항목이 많을 때는 적당한 개수만큼 한 화면에 뿌려주어야 한다.
- 아무런 메시지를 주지 않는 것보다는 조회한 데이터가 없는지에 대한 친절한 설명을 한다.
- 아직 데이터가 많지 않다고 해서, 모든 데이터를 가져온다거나, 모든 페이지의 번호를 보여주어서는 안된다. 최대로 많이 가져올 수 있는 레코드의 수를 설정해야 한다.
- ‘묻고 답하기’의 게시판을 만들면 질문과 답변의 상호 연결이 있어야 하며, 이메일이 있는 사용자에게는 이름을 클릭했을 때, 바로 메일을 쓸 수 있게 해야 한다.
- 이것은 사용자로 하여금 입력을 위해 마우스를 움직여 커서를 입력필드로 위치시키는 행동을 필요 없게 해준다. 간단한 자바스크립트로 구현을 할 수 가 있는데, 이런 세심한 배려를 해주는 사이트가 적다.
- 사용자의 입력한 폼에서 데이터를 점검하기 위해 자바스크립트가 많이 사용이 된다. 하지만 입력을 하지 않은 필드나 적절하게 입력되지 않은 필드로 인해서 자바스크립트 에러가 발생하는 경우가 있다.
- 게시물을 삭제하는 행위를 다시 복구할 수 없는 의사결정이다. 이와 같은 경우에 자바스크립트 등을 이용해서 한번 더 확인하는 것은 중요하다.
- 테이블의 필드마다 고유한 우리말 이름이 따라다니게 되는 데, 이것이 웹화면마다 다르게 나타날 수 있다. 이는 화면에서는 제목, 다른 화면에서는 글 제목과 같은 경우이다.
- 웹모듈로 넘어가는 URL안의 매개변수는 웹브라우저에서 쉽게 볼 수가 있기 때문에 사용자가 손쉽게 조작을 해서 웹모듈을 실행시킬 수가 있다. 반드시 받아야 할 매개변수를 사용자에 의해서 받지 못하거나, 잘못된 데이터를 받았을 경우 웹모듈은 제대로 작동하는지 살펴야 한다.
- 히든값은 사용자의 입력은 필요가 없지만, 다음의 웹화면으로 이동을 할 때 필요한 매개변수이다. 이것을 사용자가 조작을 했을 경우 예기치 않은 결과가 일어날 수 있는지 확인을 해야 한다.
- 각각의 웹화면은 자기 고유의 제목(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]
종류[편집]
네이티브 앱[편집]
네이티브 앱(Native APP)은 흔히 말하는 애플리케이션을 의미한다. 모바일 기기에 최적화된 언어로 개발된 앱으로 안드로이드 SDK를 이용해 자바(Java) 언어로 만드는 앱과 IOS 기반 SDK를 이용해 스위프트(Swift)로 만드는 대부분의 앱이 여기에 속한다.
iOS, 안드로이드OS 등 각 OS에 맞는 언어로 앱을 개발하는 것을 말한다. 스마트폰에 설치하는 앱은 고객이 자신이 원하는 것만 골라 설치한다는 점에서 일종의 ‘러브마크’라고 할 수 있다.[2]
- 장점
- 성능이 웹앱, 하이브리드 앱에 비해 가장 높다.
- 네이티브 API를 호출하여 사용함으로 플랫폼과 밀착되어 있다.
- 해당 언어에 익숙한 사용자라면 좀 더 쉽게 접근할 수 있다.
- 단점
- 플랫폼에 한정적이다.
- 해당 플랫폼에서 요구하는 언어에 제약적이다. 따라서 해당 언어와 플랫폼의 API를 다루는데 익숙해야 한다.
모바일 웹[편집]
웹앱(Web APP)은 모바일 웹과 네이티브 앱을 결합한 형태로 특징을 가지면서 네이티브앱의 장점을 갖고 있다. 모바일 웹보다는 조금 더 모바일에 최적화된 앱을 의미한다. 웹앱도 모바일웹처럼 일반적인 웹기술로 개발되고 모바일 브라우저에서 실행되지만 풀 브라우저 방식이 아닌 단일 페이지 방식으로 화면을 진화해 속도가 빠르다는 장점이 있다. 모바일 웹은 모바일에서 PC용 사이트의 글자폰트와 이미지 , 터치 아이콘 , 플래시 등 데스크탑 브라우저에서 실행되는 기능을 모바일에 맞추어 표현한 사이트를 의미한다. 쉽개말해 , PC용 홈페이지를 모바일 스크린의 크기에 맞춰 줄여 놓은 것이라 할 수 있다.
다양한 모바일 단말에서 URI 기반의 정보자원을 HTTP를 이용하여 주고받으며, XML 등의 마크업을 사용하는 기술이다. 다양한 모바일 단말에서 다양한 웹 콘텐츠를 편리하게 이용할 수 있도록 하는 표준기술로서, 최근 무선통신 기술, 웹기반 콘텐츠 처리 기술, 그리고 모바일 응용을 위한 서비스 기술 등의 발전으로 인하여 모바일 웹 표준 기술의 활용도가 급격하게 증가하고 있다. [3]
- 장점
- 웹사이트를 보는 것이기 때문에 따로 설치할 필요가 없다.
- 모든 기기와 브라우저에서 접근할 수 있다.
- 별도 설치 및 승인과정이 필요치 않아 유지보수가 용이 하다.
- 단점
- 플랫폼 API(카메라 등) 을 사용할 수 없고 오로지, 브라우저 API만을 사용할 수 있다.
- 친화적인 터치 앱을 개발하기가 약간 번거로운 점이 있다.
- 네이티브, 하이브리드 앱보다 실행이 까다롭다.
하이브리드 앱[편집]
하이브리드 앱이란 기본 기능은 HTML 등의 웹 문서로 구현하고, 패키징은 아이폰, 안드로이드 등 모바일 운영 체제(OS)별로 구현하는 앱이다.[4]
하이브리드 앱은 기본적으로 '네이티브앱 + 웹앱' 이라고 생각하시면 쉽다. 일반적으론 네이티브웹에 웹view를 띄워 웹앱을 실행 시키는 것이 보편적이며 양쪽의 API 를 모두 사용할 수 있는 것이 큰 장점이다.
- 장점
- 네이티브 API 와 브라우저 API 를 이용한 다양한 개발이 가능 하다.
- 웹개발 기술을 사용해 앱을 개발할 수 있다.
- 한 번의 개발로 다수의 플랫폼에 대응할 수 있다.
- 단점
- 네이티브 기능에 접근하기 위해선 네이티브 개발 지식이 결국 필요하다.
- 웹뷰에서 앱을 실행하는 경우이기 때문에 앱의 성능이 곧 브라우저의 성능이다.
- UI 프레임워크 도구를 사용하지 않는다면 개발자가 UI를 제작해야 하다.[5]
핵심용어 용어설명[5] 하이브리드 앱(Hybrid App) 앱의 기반이 되는 콘텐츠 영역은 HTML 기반의 웹 앱으로 제작, 최종 앱 배포에 필요한 패키징 처리만 아이폰, 안드로이드 플랫폼 안에서 처리한 애플리케이션 네이티브 앱(Native APP) 모바일 기기에 최적화된 언어로 개발된 앱으로 안드로이드 SDK를 이용해 Java 언어로 만드는 안드로이드 앱과 IOS SDK를 시용해 Objective-C언어로 개발된 아이폰 앱 등 모바일 웹(Mobile Web) 데스크 탑 브라우저에 실행되는 웹 애플리케이션을 모바일 스크린 크기로 줄여 놓은 것 웹 앱(Web APP) 모바일 웹과 네이티브 앱을 결합한 것으로 모바일 웹의 특성을 가지면서 네이티브 앱의 장점도 가짐
활용[편집]
웹 UI 설계[편집]
상호작용과 컨텐츠를 중심으로 다루어지던 웹을 사용자 중심의 정보관리와 사용자 인터페이스로 재조명해 봄으로써 웹 개발 프로세스 상에서나 개발 후 사용자가 사이트 내에서 효율적으로 정보를 검색하고 사용자의 욕구를 충족시킬 수 있도록 웹의 UI를 조망해 본다. 초창기의 웹은 간단한 문서, 그림, 약간의 상호작용으로 만들어졌다. 초기 HTML과 브라우저는 백그라운드 칼라나 복잡한 그래픽디자인은 상상할 수 없었기 때문이다. 그러나 1994년 넷스케이프 네비게이션의 소개와 함께 웹은 급속한 변화를 갖게 되었다. 이미지와 음성, 동영상 등의 멀티미디어와 그래픽 사용자 환경의 제공으로 학술망이었던 인터넷이 일반인들도 쉽게 접할 수 있고 사용할 수 있게 되었다. 인터넷은 네트워크의 네트워크를 형성하며 기존의 매체들을 웹으로 흡수하기 시작하였고, 지금의 정보화 사회의 기반인 동시, 사이버 세계를 열 수 있는 기초를 마련하는 미디어로서의 자리를 굳히게 되었다. 이제 웹은 단순한 홍보사이트나 브로슈어 개념의 홈페이지가 아닌 사이버 커뮤니티와 전자상거래를 가능하게 하는 중요한 매체로서 인식되고 있다. 즉 정보제공자 중심에서 사용자 중심으로의 변화가 요구되고 있다. [6]
웹 개발론의 변화[편집]
- 초기 웹 개발 방법론
웹 환경에서는 대부분 정적인 정보를 제공하는 웹페이지가 주를 이루었다. 그러나 검색 포털이나 이메일처럼 동적인 페이지를 생성하는 서버 언어또한 존재했다. 가장 많이 활용되었던 언어는 perl 그리고 c 였다. 그리고 이러한 언어들로 CGI(Common GateWay Interface)를 구현해 동적인 데이터를 구현했다. 고속 인터넷이 보급되기 시작하면서 웹에 다양한 미디어들이 나타나고, 플래시가 등장했다. 그리고 이때부터, 웹개발의 범주가 커지면서 '웹마스터' 즉 혼자서 만들고, 디자인하고 관리하는것이 아닌 클라이언트 개발자,서버개발자,웹디자이너로 세분화 되기 시작했다. 이때부터, 플래시와 activeX가 등장하면서 사용자들간의 커뮤니케이션 역시 활성화 시키면서 그들이 남기는 데이터에 대한 효율적인 관리가 필요해지기 시작했다.
- 웹 프로그래밍 언어의 발전
2000년도를 지나면서 다양한 웹 언어가 급격히 활성화 되기 시작했다. asp,jsp,php를 필두로 다양한 웹 프로그래밍 언어가 퍼져나갔다. 웹에서의 사용자 커뮤니케이션이 활성화 되면서 이러한 내용들을 보관하기 위해서 DB가 중요해졌다. 또한 자연스레 데이터들을 관리하고 무결성을 지켜 줄 수 있는 DBMS의 역할이 중요해졌다. 이와 같이 커뮤니티가 강조되는 웹페이지의 역할 변화로 인해서 주류 웹프로그래밍 언어가 기존의 C나, Perl에서 ASP,JSP,PHP로 넘어 갔다. 그리고 데이터베이스가 본격적으로 사용되기 시작했는데, MySQL,Oracle,SQL Server가 활용되기 시작했다.
- AJAX의 등장
구글은 2005년에 구글맵을 공개 했다. 구글맵은 AJAX(Asynchronous Javascript And XML)를 이용한것을 처음 공개했다. AJAX는 자바스크립트를 이용해 비동기로 HTTP Request를 서버로 보내는 기술이다. 이전에는 페이지 주소를 입력하거나 다른 웹페이지에 있는 링크를 눌러야만 전송되었다면, 이제는 화면의 변화 없이도 HTTP Request가 가능해졌다. 따라서 이를 통해 페이지를 새로고침하지 않고, 구글맵에서 확대나 축소 등 지도를 자유자재로 조절할 수 있게 되었다. 이렇게 AJAX 기술로 소스를 비동기로 처리하는 것이 가능해졌기 때문에 웹 개발 방법론이 변화가 일어 났다. 웹 언어로페이지 전체를 생성하는 것이 아니라 본래의 화면은 HTML이나 웹 언어를 조금만 넣어서 기본 페이지를 만들고, 나머지 동적으로 변경 될 수 있는 부분은 별도로 생성하는 웹 언어를 두고 AJAX로 내용을 불러오는 방식을 사용하였다. 처음에 웹페이지를 로딩할 때나 사용자의 입력을 받아서 화면을 새로고치지 않고, 그대로 변경된 내용을 반영해주는 등 이시기 부터 사용자 경험(UX)가 중요한 이슈가 되기 시작했다. 그리고 웹서버에서 처리하던 많은일들이 클라이언트 쪽으로 넘어왔다. 2006년 초창기 ajax 활용 이후 xhtml의 표준화 작업에서 html5 표준화 작업으로 넘어가게 되면서 xml http request를 통해 xml이나 html을 전송받는것이 아니라 다양한 텍스트 또는 JSON 규격의 텍스트를 받는 식으로 개발 방식이 변경되었다. 때부터 웹서비스라고 불리는 API들이 등장하면서 연동 규격으로 JSON을 사용하는 것이 일반화되기 시작하였다. 이러한 api 뿐만 아니라 직접 개발을 도와주는 개발 프레임워크와 라이브러리들이 나왔다. 대표적으로 jquery와 prototype이 있다. 이들을 통해 자바스크립트 활성화가 이루어졌다.
- 모바일 시대의 웹 애플리케이션
다양한 api들과 ajax 활성화 그리고 웹 표준도 HTML5로 정착해 가고있을때, 다양한 웹 애플리케이션이 등장했다. 그 중 대표적인 것이 구글 Docs 이다. 데스크톱에서나 생각했던 기능들이 웹페이지에서 이루어지게 되었다. json의 등장과 더불어 웹 언어에서는 html을 직접 그리는 경우가 점점 줄어들고 자바스크립트에서 html을 그리는데 필요한 정보를 전달하는 역할을 수행한다. 기존에는 웹 언어에서 자바스크립트로 전달할 때 HTML 자체를 생성해서 보내기도하고, XML 기반의 데이터로 보내기도 했는데, 이제는 json으로 데이터를 주고받는 것이 일반적이다. 따라서 api에서도 restful 요청시 웹서버에서 CRUD기능을 수행한 다음, JSON을 통해서 결과를 보내는것이 일반적이게 되었다. 이렇게 HTML과 자바스크립트, CSS를 사용하는 프런트엔드와 웹프로그래밍 언어처럼 서버언어로 이루어진 백엔드 기술이 명확하게 구분되기 시작하게 되었다. 웹서버에서 HTML을 생성하던 부분들까지 클라이언트로 넘어오게 되면서 웹서버의 역할이 줄어들고 클라이언트가 웹서비스를 수행해야 하는 부분이 많아졌다. 웹브라우저에서만 수행하던 기능을 모바일 앱에서도 웹기능을 수행하면서 자바스크립트의 활용은 점점 더 다양해지고 있다.[7]
웹 기반 서비스와 기술[편집]
대부분의 웹 서비스나 웹 애플리케이션이 Vue.js나 React를 이용하여 SPA(Single Page Application)로 개발되었고, 필요에 따라서는 Node.js를 이용하여 SSR 같은 방법을 사용하고 있다. 그리고 테스트 코드를 작성하여 개발 안정성을 높이고 리팩토링을 진행할 때에도 좀 더 손쉽게 개발할 수 있다.[8]
각주[편집]
- ↑ 1.0 1.1 1.2 까만손오공, 〈웹개발방법론 - 1999년 발표된 자료 / 지금도 유용할 듯해서 올려요〉, 《네이버 블로그》, 2012-11-04
- ↑ 지형 공간정보체계 용어사전, 〈Native App〉, 《네이버 지식백과》
- ↑ 지형 공간정보체계 용어사전, 〈Mobile Web〉, 《네이버 지식백과》
- ↑ IT용어사전, 〈하이브리드 앱〉, 《네이버 지식백과》
- ↑ 5.0 5.1 에이콘아카데미, 〈[모바일 네이티브앱 vs 모바일웹앱 vs 하이브리드앱]〉, 《네이버 블로그》, 2017-05-23
- ↑ 〈웹 UI 설계〉《아이티랩》
- ↑ Ideveloper2 , 〈javascript- 속깊은 Javascript [1. 웹과 자바스크립트]〉, 《티스토리》, 2018-04-21
- ↑ Seok Heo, 〈LINE의 웹 기반 서비스와 기술 – LINE은 앱 만드는 회사 아닌가요?]〉, 《라인엔지니어링》, 2019-09-30
참고 자료[편집]
- 까만손오공, 〈웹개발방법론 - 1999년 발표된 자료 / 지금도 유용할 듯해서 올려요〉, 《네이버 블로그》, 2012-11-04
- 지형 공간정보체계 용어사전, 〈Native App〉, 《네이버 지식백과》
- 지형 공간정보체계 용어사전, 〈Mobile Web〉, 《네이버 지식백과》
- IT용어사전, 〈하이브리드 앱〉, 《네이버 지식백과》
- 에이콘아카데미, 〈[모바일 네이티브앱 vs 모바일웹앱 vs 하이브리드앱]〉, 《네이버 블로그》, 2017-05-23
- 〈웹 UI 설계〉, 《아이티랩》
- Ideveloper2 , 〈javascript- 속깊은 Javascript [1. 웹과 자바스크립트]〉,《티스토리》, 2018-04-21
- Seok Heo, 〈LINE의 웹 기반 서비스와 기술 – LINE은 앱 만드는 회사 아닌가요?]〉, 《라인엔지니어링》, 2019-09-30
같이 보기[편집]
