웹 사이트 프로젝트(Web Site Project)와 웹 응용프로그램 프로젝트(Web Application Project)의 차이

혹시 알고 넘어가는지 모르겠지만, 닷넷에서 웹 앱을 만드는 데 2가지 프로젝트 형식이 있다.
바로 웹 사이트 프로젝트와 웹 앱 프로젝트인데, 이 둘의 차이점은 간단하게 짚어보는 시간을 갖겠다.

웹 사이트 프로젝트(Web Site Project)

타 언어 웹 사이트로 치자면, ASP, PHP, 일반 JSP 페이지를 만드는 꼴이라고 보면 된다. VS 2005부터 소개되었다.
폴더 루트를 잡고, 거기에 페이지와 리소스, 백엔드 코드를 특정 폴더인 App_Code 에 넣는 방식이다.
프로젝트 생성이 빠르고, 단순하다. 그리고 프로젝트 파일도 생성하지 않는다. 그럼 구성 설정은 어디다가 저장하냐?
바로 솔루션 파일과 구성 설정 파일인 web.config에다 저장한다. 각기 역할은 당연히 틀리고 대부분 설정은 web.config에다 저장한다.
개발만 하고 폴더 그대로 IIS에 배포할 수 있다. 사이트 설정만 하면 작동을 시작한다. 나머진 IIS가 파싱하여,
각 페이지마다 변경 사항이 생길 때마다 컴파일 후, 각기 페이지마다 DLL 파일이 생성되어 페이지를 렌더링 한다.
그렇기 때문에 빠른 배포와 수정이 장점으로 통한다. 하지만 이런 특성이 단점으로 작용하는데,
이렇게 될 경우 각 페이지 내에서 클래스 네임 중복을 확인하지 않는다, IIS는 그걸 인식하지 않고 파일마다 컴파일 하기 때문에,
클래스 이름이 중복되더라도 다른 이름으로 클래스를 생성 후 컴파일하기 때문에 참조 등에서 어떤 문제가 나올 지 파악이 어렵다.
이런 불상사를 예방하기 위해 “게시” 기능이 있다. 게시할 때 “미리 컴파일(Precompiled)” 개념이 있으며, 최적화하고 정리하여 깔끔한 백엔드와 성능을 보장받을 수 있다.

이럴 때 웹 사이트를 쓰면 좋다. 프로토타입, 시연, 데모, 단순한 소개 사이트.

웹 응용프로그램 프로젝트(Web Application Project)

웹 앱을 아예 응용 프로그램처럼 프로그램 단위로 관리하고 운영하는 프로젝트로, VS2005 SP1부터 내장되었으며, 이런 개념은 이미 VS 2003부터 도입이 되었다.
폴더 루트에 .csproj.vbproj 등의 프로젝트 파일이 생기며, 프론트엔드 코드와 백엔드 코드를 아무 곳이나 넣을 수 있으며, 예외 설정 등이 가능하여
관리적 측면에서 아주 유리한 프로젝트이다. 왠만한 구성 설정은 프로젝트 파일에 저장하기 때문에 web.config 파일엔 서버 운영에 필수적인 구성 설정밖에 없는 것도 장점이다.
단점이라면, 매 수정시마다 빌드(컴파일)해줘야 하고, 당연히 컴파일된 상태로 배포를 해야 한다. 물론 아예 “게시”하여 배포할 수 있다.
빌드 후에는 모든 백엔드 코드가 하나의 DLL에 담게 된다. 배포 방식이야 웹 사이트처럼 폴더째로 담으면 땡이지만, 백엔드 코드를 DLL에서 바로 불러오기 때문에 성능 측면에서 이득이다.
또한 게시 기능을 통해 웹 사이트처럼 모든 페이지의 백엔드 코드까지 퉁쳐서 하나의 DLL로 담은 후 배포할 수 있기 때문에,
성능과 안정성 측면에서 당연히 가장 추천되는 웹 앱 프로젝트 방식이다.

이럴 때 웹 응용 프로그램을 쓰면 좋다. 웹 사이트에서 소개한 거 빼고 전부 다. 모든 서비스들 말이야.

결론?

참고로 ASP.NET Core 프로젝트는 웹 사이트 프로젝트가 아직 없다. 웹 앱 프로젝트 방식이다. ASP.NET 팀에서는 ASP.NET Core Web Pages 으로 만들고 있다.
닷넷 코어는 IIS 종속이 아니기 때문에 어떤 방식으로 배포하고 운영할 지는 모르겠으나, 어자피 정식 웹 앱을 만드는 데에는 웹 앱 프로젝트 만큼 관리가 좋은 건 없으니 그거 쓰자.
어자피 WebMatrix는 VS Code가 그 뒤를 계승 이미 끝났으니 신경 끄고.

composite / 2017년 8월 30일 / Piss Development
태그:, , , , ,

답글 남기기

Your email address will not be published / Required fields are marked *