웹 애플리케이션

3. 구조

웹 애플리케이션은 기본적으로 클라이언트-서버 모델을 따르며, 월드 와이드 웹을 기반으로 하는 분산 컴퓨팅의 한 형태로 볼 수 있다. 대표적인 웹 애플리케이션에서는 웹 브라우저가 HTTP 프로토콜을 이용해 웹 서버와 통신하며 HTML 문서를 받아 화면에 표시한다. 이때 DOM을 통해 JavaScript가 웹 페이지의 내용을 동적으로 조작하고, 필요에 따라 웹 서버와 데이터를 주고받으며 상호작용한다.

웹 애플리케이션을 구현하는 기술 스택은 매우 다양하며, 명확하게 정의된 기준은 없다. 동적인 웹 페이지와의 경계도 모호한 편이다.

웹 애플리케이션의 기능이 점차 강화되고 복잡해짐에 따라, 이러한 복잡성을 관리하기 위해 다양한 소프트웨어 아키텍처가 고안되고 적용되고 있다. 웹 애플리케이션은 네트워크를 통한 분산 환경에서 동작하므로, 그 특성에 맞는 아키텍처를 선택하는 것이 중요하다. 가장 흔한 구조는 3계층 아키텍처이지만, 애플리케이션의 복잡도에 따라 N계층 아키텍처 등 더 세분화된 구조가 사용되기도 한다. 최근에는 여러 개의 작은 마이크로서비스들을 API를 통해 연결하여 하나의 웹 애플리케이션을 구성하는 방식도 많이 사용되고 있어, 분산 컴퓨팅으로서의 특징이 더욱 강화되는 추세이다.

3. 1. 3계층 아키텍처

• 프레젠테이션 계층 (Presentation Layer): 첫 번째 계층으로, 웹 브라우저가 여기에 해당한다. 사용자에게 보여지는 인터페이스를 담당한다.
• 애플리케이션 계층 (Application Layer): 중간 계층으로, 동적 웹 콘텐츠 기술을 사용하는 엔진이 이 계층에 속한다. 예를 들어 ASP, ASP.NET, CGI, ColdFusion, JSP/Java, Node.js, PHP, 파이썬, 루비 온 레일즈 등이 있다. 이 계층은 비즈니스 로직을 처리하고 데이터베이스와 상호작용하여 데이터를 가공한다.
• 저장 계층 (Storage Layer): 세 번째 계층으로, 데이터베이스가 해당된다. 데이터를 영구적으로 저장하고 관리하는 역할을 한다.

3. 2. N계층 아키텍처

3. 3. 2계층 아키텍처

4. 기술적 고려 사항

웹 애플리케이션 개발 과정에서는 여러 중요한 기술적 요소들을 고려해야 한다. 대표적으로 다양한 운영 체제와 웹 브라우저 환경에서 문제없이 작동하도록 하는 크로스 플랫폼 지원 능력 확보가 필수적이다. 이를 위해서는 웹 표준 기술을 준수하고 브라우저 간의 구현 차이로 인한 호환성 문제를 해결해야 한다. 또한, 사용자가 글꼴이나 색상 등 개인 설정을 변경할 수 있다는 점을 염두에 두고 유연하게 반응하는 사용자 인터페이스를 디자인하는 것도 중요하다. 과거에는 플래시나 자바 애플릿 같은 플러그인 기술을 활용한 리치 인터넷 애플리케이션(RIA) 방식도 사용되었으나, HTML5^[1], PWA(Progressive Web Apps)와 Service Worker API^[2], WebAssembly^[3] 등 웹 표준 기술이 발전하면서 점차 그 중요성이 줄어들고 있다. 이러한 기술적 고려 사항들은 웹 애플리케이션의 품질과 사용자 경험을 결정짓는 핵심 요소이다.

4. 1. 크로스 플랫폼 지원

4. 2. 사용자 인터페이스 디자인

4. 3. 리치 인터넷 애플리케이션 (RIA)

5. 보안

웹 애플리케이션에서 발생하는 보안 침해는 기업 정보와 개인 고객 데이터를 모두 위험에 빠뜨릴 수 있어 중요한 문제로 인식된다. 이러한 자산을 보호하는 것은 웹 애플리케이션 운영의 핵심이며, 개발 초기 단계부터 보안을 고려하는 것이 장기적으로 더 효과적이다.

5. 1. 보안 취약점

• 표준 기능으로 미디어 재생이 어려웠던 문제: HTML5의 HTMLMediaElement를 이용한 미디어 재생 및 제어 기능으로 해결.^[1]
• 웹 서버 장애 또는 통신 두절 시 이용 불가 문제: PWA(install + Service Worker API^[2])를 통한 오프라인 동작 지원으로 개선.
• 네이티브 앱 대비 느린 실행 속도 문제: WebAssembly를 통해 네이티브 수준의 코드 실행 속도 확보.^[3]

5. 2. 보안 강화 방안

• 인증 (Authentication, AuthN): 사용자의 신원을 확인하는 과정이다.
• 인가 (Authorization, AuthZ): 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 과정이다.
• 자산 처리: 중요한 데이터를 안전하게 처리하고 저장하는 방식을 의미한다.
• 입력 검증: 외부로부터 들어오는 데이터(사용자 입력 등)의 유효성을 검사하고 악의적인 코드를 차단하는 것이다.
• 로깅 및 감사: 시스템 활동 기록을 남기고 정기적으로 검토하여 보안 사고를 탐지하고 대응하는 것이다.

6. 개발

웹 애플리케이션 프레임워크는 개발 과정을 간소화하여 신속한 애플리케이션 개발을 돕는다. 이 외에도 인터넷 운영 체제를 기반으로 애플리케이션을 개발하는 방법 등이 고려될 수 있다.

6. 1. 웹 애플리케이션 프레임워크

6. 2. 인터넷 운영 체제

7. 인터페이스

웹 인터페이스가 클라이언트의 기능에 제한을 주는 일은 거의 없다. 자바, 자바스크립트, DHTML, 플래시와 기타 기술들을 활용하면 응용 프로그램에 특정적인 방법, 이를테면 화면에 그림을 그리거나 소리를 재생하거나 키보드와 마우스에 접근하는 것이 모두 가능하다. 드래그 앤드 드롭과 같은 일반적인 기법도 앞의 기술로 가능하다. 웹 개발자는 클라이언트측 스크립트를 활용해서 기능을 추가하는 경우가 많은데, 특히 페이지를 다시 불러오지 않으면서 인터렉티브한 경험을 구현하는 것이 그러한 경우이다. 최근에는 클라이언트측 스크립트와 서버측 기술(이를테면 PHP)을 함께 활용하는 기술들이 개발되고 있다. 다양한 기술을 조합한 웹 개발 기법인 Ajax는 더욱 인터렉티브한 경험을 제공하는 기술의 예이다.

8. 기술

일반적으로 특정 종류의 동적 웹 페이지와 웹 애플리케이션을 명확히 구분하기는 어렵다. 웹사이트가 데스크톱 앱이나 모바일 앱과 비슷한 기능을 갖추고 있을 때 "웹 애플리케이션"으로 불릴 가능성이 높다. HTML5는 웹 페이지로 로드되어 로컬에 데이터를 저장하고 오프라인 상태에서도 작동할 수 있는 애플리케이션 제작을 위한 명시적인 언어 지원을 도입했다.

초기 클라이언트-서버 컴퓨팅 환경에서는 각 응용 소프트웨어가 자체 사용자 인터페이스를 가지고 사용자 PC마다 별도로 설치해야 했다. 서버 환경이 변경되면 클라이언트 응용 프로그램도 업그레이드해야 했고, 이는 기술 지원 비용 증가와 생산성 저하로 이어졌다.

반면, 웹 애플리케이션은 웹 브라우저가 지원하는 HTML이나 XHTML 같은 표준 형식의 웹 문서를 동적으로 생성하는 방식으로 작동한다. 클라이언트 측 동작은 표준 스크립트 언어인 자바스크립트가 주로 담당한다. 개별 웹 페이지는 정적 문서 형태로 웹 브라우저에 전달되지만, 연속적인 웹 문서 전달과 웹폼을 통한 정보 교환을 통해 사용자에게 상호작용적인 경험을 제공한다. 웹 브라우저는 이러한 웹 문서를 해석하고 표시하는 역할을 한다.

웹 인터페이스는 클라이언트 기능에 거의 제한을 두지 않으며, 다양한 기술을 활용하여 특정 애플리케이션에 필요한 기능을 구현할 수 있다. 드래그 앤드 드롭과 같은 일반적인 사용자 인터페이스 기법도 구현 가능하다. 웹 개발자들은 특히 페이지를 새로고침하지 않고도 상호작용적인 경험을 제공하기 위해 클라이언트측 스크립트를 자주 활용한다. 여러 기술을 조합한 Ajax는 더욱 동적인 사용자 경험을 가능하게 하는 기술의 예이다.

다양한 변형이 존재하지만, 웹 애플리케이션은 주로 3계층 아키텍처로 구축된다. 가장 일반적인 구성은 웹 브라우저가 첫 번째 계층, 동적 웹 콘텐츠 기술 엔진(ASP, ASP.NET, CGI, ColdFusion, JSP, PHP, 파이썬, 루비 온 레일즈 등)이 중간 계층, 그리고 데이터베이스가 세 번째 계층을 이루는 형태이다. 웹 브라우저는 중간 계층에 요청을 보내고, 중간 계층은 데이터베이스에 쿼리를 보내거나 자료를 업데이트하며 사용자 인터페이스를 생성하여 브라우저로 전달한다.

대표적인 웹 애플리케이션의 기술 스택은 웹 브라우저가 HTTP를 이용해 HTML 문서를 받아 표시하고, 이를 DOM을 통해 JavaScript가 조작하며, 필요에 따라 웹 서버와 통신하여 데이터를 갱신하는 방식이다. 이처럼 '''웹을 기반'''으로 만들어지는 '''응용''' 소프트웨어를 통칭하여 웹 애플리케이션(Web 앱)이라고 부른다. 이는 웹 애플리케이션을 구현하는 기술 스택의 한 예일 뿐이며, 다양한 기술 조합으로 웹 앱을 만들 수 있다.

웹 애플리케이션의 예로는 위키백과 등에서 사용되는 위키, 블로그, 전자 게시판, 은행의 인터넷 뱅킹, 증권사의 온라인 트레이딩, 전자 상가 등 통신 판매의 쇼핑 카트 기능 등이 있다. 웹 애플리케이션과 대비되는 개념으로는 로컬 데스크톱 환경에서 동작하는 데스크톱 애플리케이션이나 스마트폰에서 동작하는 네이티브 앱이 있다.

웹 앱은 클라이언트-서버 모델을 기본으로 하며, WWW를 기반으로 하는 분산 컴퓨팅의 한 형태로 볼 수 있다. 2010년대 후반부터는 다수의 마이크로서비스를 API를 통해 연동하여 구성하는 웹 앱이 증가하면서 분산 컴퓨팅으로서의 측면이 더욱 강화되고 있다.

1990년 월드 와이드 웹 등장 이후 웹 애플리케이션이 발명되면서, 성능, 편의성, 사용자 경험(UX)을 향상시키기 위한 기술 개발이 꾸준히 이루어져 왔다. 초기 웹은 정적 HTML 파일들을 하이퍼링크로 연결한 형태였으나, CGI의 등장으로 사용자 입력에 따라 동적으로 자원을 생성하고 반환하는 것이 가능해졌다. 이후 Java Servlet, Apache HTTP Server용 모듈인 mod_php^[4], 마이크로소프트의 ASP 등이 등장했으며, Ajax, 플래시, HTML5 등으로 기술이 발전했다. 2019년경부터는 특히 스마트폰 앱 분야에서 네이티브 앱과 동등한 경험 제공을 목표로 하는 '''프로그레시브 웹 앱'''(PWA) 관련 기술 개발이 활발히 이루어지고 있다^[5]. 또한 클라우드 컴퓨팅의 발전으로 자체 웹 서버 대신 클라우드 서비스를 백엔드로 활용하는 웹 앱 개발도 확산되고 있다.

8. 1. 프로그래밍 언어

8. 2. HTML

8. 3. DOM

8. 4. 통신 프로토콜

8. 5. 캐시 및 동기화

캐시는 원리적으로 항상 동기화 문제를 안고 있다. 캐시는 기본적으로 복사된 시점의, 즉 시간이 지난 오래된 리소스를 제공하기 때문이다. 따라서 각 웹 애플리케이션의 요구 사항에 맞춰 적절한 캐시 전략을 선택해야 한다. 또한, 사용자가 데이터를 변경하는 POST 요청 시 캐시에 먼저 내용을 반영하고 나중에 캐시와 백엔드 서버를 동기화하는 방식도 사용될 수 있다. 이 경우에도 동기화 과정에서의 데이터 충돌이나 경합 문제는 원리적으로 존재한다.

동기화 방법 중 하나로 차분 동기화(delta sync)가 있다^[9]。가장 단순한 동기화 방법은 캐시를 새로고침하는 것, 즉 모든 데이터를 서버로부터 다시 가져오는 방식이다. 충분한 계산 능력과 통신 자원이 있다면 모든 데이터가 최신 상태임을 쉽게 보장할 수 있다. 그러나 자원이 제한적인 경우, 캐시에 저장된 데이터와 서버의 최신 데이터 사이의 차이(delta)만을 계산하여 갱신함으로써 자원 사용량을 줄일 수 있다. 차분 동기화 방식에서는 여러 종류의 쿼리가 사용된다: BaseQuery, DeltaQuery, 그리고 필요에 따라 SubscriptionQuery^[9]。BaseQuery는 캐시 새로고침과 같이 전체 데이터를 가져오는 쿼리이며, DeltaQuery는 데이터 원본으로부터 변경된 차분 정보만을 가져오는 쿼리이다. 데이터 원본 서버는 변경된 정보를 별도로 기록해두고, DeltaQuery 요청이 오면 해당 갱신 정보 큐(Queue)에서 정보를 보내준다. 이를 통해 기존 데이터 전체에 접근하지 않고도 동기화가 가능해진다. DeltaQuery는 주기적으로 서버에 요청(fetch)하여 구현할 수 있으며, 실시간 갱신이 필요하다면 WebSocket 등을 사용한 구독(Subscription) 방식으로 차분 정보를 받아 구현할 수도 있다.

차분 동기화를 구현할 때는 BaseQuery와 DeltaQuery의 적절한 사용 시점, 오프라인 상태 대응 등이 중요한 문제가 된다. 예를 들어, 네트워크 연결이 끊겼다가 다시 연결되었을 때 BaseQuery를 다시 실행하도록 설계할 것인지, DeltaQuery의 요청 빈도는 어떻게 조절할 것인지(예: 지수 백오프(exponential backoff)와 지터(jitter) 적용), 실시간 구독 방식 사용 시 연결이 끊어졌을 때 재접속은 누가 책임질 것인지 등을 고려해야 한다. 또한, 데이터 원본 서버 측에서 차분 정보를 어떻게 생성하고 유지 관리할 것인지(생성 방식, 보존 기간 및 형식 등)도 중요한 고려 사항이다.

8. 6. 접근 제어

8. 7. 데이터 바인딩

8. 8. 데이터 액세스

9. 기능에 따른 분류

웹 애플리케이션은 제공하는 기능에 따라 다양하게 분류할 수 있다. 예를 들어, 동영상이나 음악과 같은 미디어 콘텐츠를 다루는 기능이나 인터넷 연결 없이도 작동하는 오프라인 기능을 중심으로 웹 앱을 나눌 수 있다. 이 외에도 전자 상거래, 소셜 네트워킹, 온라인 게임, 업무용 도구 등 목적과 기능에 따라 웹 애플리케이션의 종류는 매우 다양하다.

9. 1. 미디어 (동영상, 음성)

• <audio> 요소: HTML의 `<audio>` 태그는 `src` 속성만 설정하면 웹 페이지에 간단한 오디오 재생 위젯을 표시할 수 있다. <audio> 요소 (MDN)
• HTMLMediaElement DOM 인터페이스: JavaScript를 사용하여 미디어 재생을 세밀하게 제어할 수 있는 DOM API이다. 재생, 정지, 탐색, 볼륨 조절 등을 프로그래밍 방식으로 구현할 수 있다. HTMLMediaElement (MDN)
• Web Audio API: 오디오 처리를 위한 저수준 API이다. AudioNode로 구성된 오디오 처리 그래프를 JavaScript로 구축하여 복잡한 오디오 합성, 효과 적용, 분석 등을 수행할 수 있다. Web Audio API (MDN)

9. 2. 오프라인

• 로컬에 존재하는 소프트웨어 프로그램
• 실패하는 네트워크 요청 처리
• 온라인 복귀 시 동기화

10. 사업 용도

기업 환경에서 웹 애플리케이션은 다양한 목적으로 활용된다. 고객 관계 관리(CRM), 전사적 자원 관리(ERP)와 같은 내부 업무 시스템을 웹 기반으로 구축하여 접근성과 효율성을 높이는 경우가 많다. 또한, 전자 상거래 플랫폼, 온라인 예약 시스템 등 고객에게 직접 서비스를 제공하는 용도로도 널리 사용된다.

최근에는 소프트웨어 자체를 웹을 통해 서비스 형태로 제공하는 애플리케이션 서비스 제공업체(ASP) 모델이 중요한 사업 방식으로 부상하고 있다. 이는 기업이 별도의 소프트웨어를 설치하거나 관리할 필요 없이 웹 브라우저를 통해 필요한 기능을 이용할 수 있게 해준다.

10. 1. 애플리케이션 서비스 제공업체 (ASP)

참조

_[1] 웹사이트 HTMLMediaElement. MDN web docs https://developer.mo[...]
_[2] 웹사이트 サービスワーカー API. MDN web docs https://developer.mo[...]
_[3] 웹사이트 WebAssembly の概要 - WebAssembly とは何か. MDN web docs https://developer.mo[...]
_[4] 문서 Perl, mod_perl, Python, mod_python, Ruby, mod_ruby 관련 문서
_[5] 웹사이트 プログレッシブウェブアプリ. MDN web docs https://developer.mo[...]
_[6] 웹사이트 MDN web docs - Web API https://developer.mo[...]
_[7] 웹사이트 React Docs - コンポジション vs 継承 https://ja.reactjs.o[...]
_[8] 웹사이트 React Docs - React の最上位 API https://ja.reactjs.o[...]
_[9] 웹사이트 AWS AppSync - チュートリアル: Delta Sync https://docs.aws.ama[...]
_[10] 웹사이트 scs-architecture.org https://scs-architec[...]