(win7) 윈도우7 에서 IIS (웹서비스) 실행하기

Posted by 나에요임마
2018. 2. 28. 23:22 Program/ASP
윈도우 OS 에서는 자체적으로 ‘인터넷 정보 서비스(Internet Information Services, IIS)’를 지원한다.
물론, 각 OS 버전별로 가정용으로 제작되어 나오는 ‘홈에디션(Home Edition)’의 경우에는 지원하지 않으므로 주의할 것.
일반적으로, ‘프로페셔널(Professional)’ 버전 이상의 버전에서는 간단한 절차만 거치면 ‘IIS 서비스’를 가동할 수 있다.
‘윈도우XP’ 까지는 ‘IIS’를 사용하기 위해서 다시 윈도우 CD가 필요했는데, 다름 아니라 윈도우 CD 의 ‘i386’ 폴더에 관련 정보가 들어있기 때문이다.
‘윈도우7’의 경우에는 일단 설치만 하면, 나중에 필요할 때 몇 가지 간단한 절차를 거치면 바로 ‘IIS’ 를 기동할 수 있다.
하지만, 일반적으로 인터넷에 올라온 자료에서는 자세한 설명이 빠져 있어서, ‘ASP’로 작성된 웹페이지를 가동하려고 할 때 에러가 나서 무엇이 문제인지 한참을 헤매게 된다.
이하, ‘IIS’ 를 가동하고, ‘ASP 스크립트’로 작성된 웹사이트를 기동하기 위한 상세한 절차를 설명해본다.

‘IIS’ 서비스를 설치하기 위해서는 ‘제어판 → 프로그램 및 기능’ 항목을 클릭한다.

‘프로그램 및 기능’ 팝업창이 뜨면, 좌측의 메뉴에서 ‘Windows 기능 사용/사용 안함’ 항목을 클릭한다.

그러면 다시 ‘Windows 기능’ 이라는 팝업창이 뜬다.
여기에서 ‘인터넷 정보 서비스’ 항목을 찾아 그 하부의 ‘World Wide Web 서비스’ 항목과 ‘웹 관리 도구’ 항목에 체크한 뒤 ‘확인’ 버튼을 눌러 설치한다.
이것이 인터넷에 올라온 자료들에서 설명하는 방법이다.
그런데, 이렇게 하게 되면 ‘ASP 스크립트’로 작성된 웹페이지가 동작하지 않고 오류가 발생한다.

물론, 브라우저에서 ‘http://localhost’ 라고 입력하면, 위 화면에서처럼 ‘IIS 서비스’가 정상적으로 구동되었음을 보여주는 화면을 볼 수 있다.
하지만, ‘윈도우7’ 에서는 ‘ASP’ 로 만들어진 웹페이지를 기본적으로 지원하지 않는다.
아마도 윈도우에서 ‘닷넷’을 여전히 계속 밀고 있기 때문인 것 같은데, ‘ASP’ 로 작성된 웹페이지를 구동하기 위해서는 조금 더 주의를 기울여야 한다.

이렇게 설치된 ‘IIS’ 환경에서 ‘ASP’ 로 작성된 웹페이지를 기동해보면 에러페이지가 출력된다.
일단, ‘ASP’ 로 작성된 웹페이지가 가동되게 설정을 바꾼 뒤 자세한 설명을 이어간다.

기본적으로 설치된 ‘IIS’ 의 디렉터리 위치는 아래와 같다.

‘C:\inetpub\wwwroot’ 폴더에 ‘iisstart.htm’ 이라는 문서가 동작한 것이다.
하지만, 이 문서에는 ‘ASP’ 로 작성된 스크립트 코드가 들어있지 않다.
정확한 테스트를 위해서, IIS 의 시작폴더를 임의의 다른 폴더로 변경해보자.


다시 ‘제어판 → 관리도구’ 에서 ‘IIS(인터넷 정보 서비스) 관리자’를 찾아 클릭한다.
(‘IIS’ 서비스가 정상적으로 설치되었다면, 이 항목이 생겨난다.)

좌측 디렉터리 메뉴에서 ‘Default Web Site’ 항목을 클릭하면, 우측 중간 부분에 ‘고급 설정...’ 이라는 항목이 보일 것이다.
이 항목을 클릭하면, ‘IIS’ 가 시작되는 폴더를 임의로 변경할 수 있다.

‘고급 설정’을 눌러 뜬 팝업창에서 ‘실제 경로’에 지정된 경로를 클릭하면 경로를 변경할 수 있다.

이 경로를 마우스로 클릭하면, 우측 끝에 ‘...’ 으로 보이는 버튼이 생성되는데, 이 버튼을 클릭하면 ‘폴더 찾아보기’ 팝업창이 생긴다.
이 경로를 임의의 경로인 ‘C:\testWEB’ 라는 곳으로 변경해보자.
(물론, 새로 폴더를 만들어야 한다.)

이 과정이 모두 끝났다면, 새로 만든 폴더에 ‘ASP’ 로 작성된 웹페이지를 올려놓고 다시 주소창에 ‘로컬호스트(localhost)’를 입력하여 호출해본다.

위 화면에서처럼, 새로 만든 폴더에서 텍스트 문서를 하나 새로 만든다.

그리고 이 텍스트 문서에 ‘ASP 스크립트’를 작성해서 넣는다.

이제, ‘ASP’ 스크립트를 작성하여 만들어진 웹사이트를 실행할 준비는 마쳤다.

하지만, 실제로 브라우저에서 ‘localhost’를 호출해보니, 위의 화면처럼 에러가 출력되었다.
위에서 언급했듯이, 설정을 따로 하지 않고 그냥 기본 값으로 ‘IIS’를 설치하면 이렇게 된다.

다시, ‘IIS’ 설치를 할 때의 화면으로 돌아 가보자.

다시 ‘제어판 → 프로그램 및 기능’ 을 연 뒤, 좌측 메뉴에서 ‘Windows 기능 사용/사용 안함’ 항목을 클릭해서, ‘IIS’ 의 설치 세부 항목을 살펴보자.

‘인터넷 정보 서비스’ 항목을 찾는다.

‘응용 프로그램 개발 기능’ 항목의 하부 항목을 살펴보면, ‘ASP’ 라는 항목의 체크가 빠져 있는 것을 볼 수 있을 것이다.
즉, 따로 설정 값을 바꾸지 않고 기본 값으로 설치하면, ‘ASP’ 기능이 빠진 채로 설치가 되는 것이다.
‘ASP’ 항목에 체크를 하고, ‘서버측 include’ 기능도 필요하면 미리 체크를 해두고 ‘확인’ 버튼을 누른다.
(*서버측 include: ASP 스크립트에서 상대 경로를 사용하여 현재 실행 위치보다 상위의 파일을 include 할 때 유용하게 사용 됨)

이렇게 설치가 완료되면, ‘C:\Windows\System32\inetsrv’ 폴더에 들어가보면 ‘asp.dll’ 이라는 파일이 보일 것이다.
만약, 기본 값으로 그냥 설치하면, ‘asp.dll’ 파일이 없다.
그래서 ‘ASP’ 코드로 작성된 웹페이지가 실행될 때 에러가 나는 것이다.

‘IIS 관리자’ 에서 ‘처리기 매핑’ 항목을 보면 ‘ASPClassic’ 이라는 항목을 사용하는 것으로 되어 있을 것이다.
즉, ‘ASP’ 기능을 사용하게 설치를 해야, ‘ASP’ 와 관련된 서비스 기능들이 정상적으로 설치가 되고, 그에 따라 ‘ASP’ 코드로 작성된 웹페이지가 정상적으로 가동할 수 있게 되는 것이다.

다시, 브라우저에서 ‘http://localhost’를 쳐보자.
IE9 에서는 위에서 보이는 것처럼 이상한 페이지가 나올 수 있다.

이런 경우, 브라우저 우측의 ‘호환성 보기’ 버튼을 클릭해주면, 한글이 정상적으로 출력된다.


SI와 솔루션 개발의 차이 - 아키텍처 편

Posted by 나에요임마
2018. 2. 28. 23:17 Story/Development story

불과 얼마 전까지만 해도 소프트웨어는 기관이나 기업에서 필요에 의해 만들어지는 경우가 대부분이었다. 컨설팅이 고객에게 시스템의 필요성을 전달하고 고객은 필요한 예산을 확보한 후 SI(System Integration) 프로젝트로 이어지는 흐름이었다. 하지만 최근에는 어느 정도 구축이 완료된 상태인 ICT의 투자 필요성이 많이 줄어들었고 오픈 플랫폼, 클라우드와 같은 다양한 ICT 기술이 나타나면서 SI 사업은 예전보다는 많이 줄어들고 있는 추세다.


이와는 반대로, 모바일 디바이스와 같은 개인용 기기가 늘어나면서 불특정 다수가 사용하는 솔루션 소프트웨어가 증가 추세에 있다. 솔루션 소프트웨어는 고객이 미리 정해져 있지 않기 때문에 소프트웨어를 개발하는 프로세스나 방법이 SI와는 다소 상이한 편이다. SI는 고객의 요구사항을 파악하고 분석하는데 많은 시간을 할애하지만 솔루션은 개발과 딜리버리, 그리고 업그레이드 등에 많은 시간을 할애한다. 다수의 사용자가 원하는 소프트웨어를 개발하고 오랫동안 사용될 수 있도록 서비스하고 업그레이드를 해야 하기 때문이다.


SI와 솔루션 소프트웨어의 차이를 좀 더 체계적으로 확인하여 소프트웨어 개발에 도움을 주고자 이번 달에는 SI와 솔루션 개발의 차이를 아키텍처, UX, 테스트, 그리고 개발 관점으로 알아보고자 하며, 이번 회에서는 아키텍처 관점으로 차이점을 살펴보기로 한다. 먼저, SI의 아키텍처와 솔루션 아키텍처의 구성과 역할에 어떤 차이가 있는지 알아보고, 두 아키텍처의 설계 프로세스를 비교하여 차이점을 살펴보기로 한다.


아키텍처 구성과 역할의 차이


아키텍처 구성의 차이


사전에서 정의하는 아키텍처란 컴퓨터 시스템의 컴포넌트를 배치하고 통합하는 방식으로 나타나 있고, IEEE에서는 시스템을 구성하는 요소를 식별, 정의하고 그들 간의 관계를 설정해 놓은 기본적인 구조체, 그리고 설계와 전개에 대한 가이드 원칙으로 나타나 있다. 아키텍처는 다양한 의미로 해석되고 활용되지만 한마디로 요약하면 “시스템의 구조체”라는 것이다. 시스템을 만들기 위한 기본적인 요소를 비즈니스, 애플리케이션, 데이터, 기술로 나누어 구성한다. 이러한 4개의 구성을 계획자, 분석자, 설계자, 개발자의 관점으로 살펴본다면 <그림 1>과 같이 나타낼 수 있다.



SI는 고객의 요구사항에 맞춰 시스템을 구성하기 때문에 시스템 개발 초기에 기술적으로 시스템의 큰 그림을 그리는 성향이 강하다. SI는 시스템의 뼈대를 만들고 그에 맞춰 살을 붙여가는 것을 고객에게 보여주면서 완성해야 하기 때문이다. 솔루션은 고객의 요구사항을 전달받기보다 프로젝트 팀에서 사용자가 원하는 것을 자체적으로 파악하는 경우가 많기 때문에 소프트웨어를 개발하는 자체에 더 초점이 맞춰져 있다.

이러한 이유로, <그림 1>을 살펴보면 SI는 세부 기술과 관련된 데이터, 기술 아키텍처에 집중하는 성향이 강하고, 솔루션은 비즈니스, 애플리케이션에 집중하는 성향이 강하다. 이해관계자 관점에서 본다면, 전사적인 모델을 구축하는 계획자, 분석자는 SI 개발에서 더 많은 역할을 하고, 직접적으로 소프트웨어 개발을 하는 설계자, 개발자는 솔루션 개발에서 더 많은 역할을 한다.


아키텍처 역할의 차이


앞에서 살펴본 것처럼 아키텍처의 가장 큰 역할은 고객, 프로젝트 팀원과 같은 이해관계자들 간의 의사소통 수단이다. 특히 SI 프로젝트 초기에는 시스템의 실체가 없기 때문에 시스템의 뼈대를 보여주는 아키텍처의 중요성은 매우 높다. 또한 SI에서 아키텍처는 프로젝트를 성공시키기 위해 필요한 기술적인 접근방법, 프로젝트 위험을 최소화하기 위한 기준과 가이드 등을 제시하여 이해관계자의 의사결정과 프로젝트 관리계획을 수립하는데 가장 중요한 역할을 한다. 아래는 SI에서 아키텍처의 역할을 정리한 내용이다.


  • 이해관계자 간의 의사소통 수단

  • 기술적으로 집중해야 할 사항을 결정

  • 시스템의 초기 설계 결정의 기준과 가이드 제공

  • 프로젝트에서 일어나는 기술적인 문제점을 최소화

  • 재사용 가능한 추상화 모델 수립


SI에서 아키텍처는 위에서 보는 것처럼 만들고자 하는 시스템에 대한 의사소통과 의사결정을 위한 추상화 모델의 역할이라고 할 수 있지만, 솔루션에서 아키텍처는 불특정 다수가 사용하는 소프트웨어를 설계하고 개발하는 원칙과 개발 후 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델을 수립하는 역할이라고 볼 수 있다. 아키텍처의 구성 별 역할을 <표 1>과 같이 정리하였다.


<표 1> 솔루션 아키텍처의 역할


구성

역할

비즈니스

아키텍처

- 불특정 다수 사용자에 대한 솔루션의 프로세스, UX 수립

애플리케이션

아키텍처

- 불특정 다수 사용자가 원하는 기능/비기능 요건을 분석

- 소프트웨어의 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델 수립

데이터

아키텍처

- 소프트웨어에 필요한 데이터 모델 수립

- 소프트웨어의 기능 추가, 업그레이드에 유연하게 대처하는 데이터 모델 수립

기술

아키텍처

- 다수의 운영 환경(플랫폼, 클라우드 등)에 유연하게 대처하는 인프라 모델 수립

- 원활한 운영을 위한 성능, 가용성에 대한 대응 전략 수립


위와 같이 솔루션에서 아키텍처는 누가, 언제, 어떻게 사용하더라도 유연하게 대처하는 모델을 수립하는 것이 가장 중요하다. 또한 대개 완성 후 개발이 종료되는 SI와는 다르게 솔루션은 배포, 기능 추가, 업그레이드에 대한 전략이 반드시 필요하고, 관리 측면에서는 소프트웨어의 버전을 관리하는 버저닝(Versioning) 전략도 고려해야 한다.


버저닝 개념 이해

http://www.esri.com/news/arcuser/0110/versioning101.html


SI 아키텍처와 솔루션 아키텍처 비교


앞에서 살펴본 것처럼, SI는 고객이 요구하는 소프트웨어이고 솔루션은 구체적인 목표가 없는 상태에서 필요에 의해 만들어지는 소프트웨어이기 때문에 SI 아키텍처와 솔루션 아키텍처는 무슨 소프트웨어를 만들 것인지 목적이 다르다. 따라서 구성되는 아키텍처의 특징도 <표 2>와 같이 다르게 나타난다.


<표 2> SI 아키텍처와 솔루션 아키텍처의 특징


SI 아키텍처의 특징

솔루션 아키텍처의 특징

고객의 요청에 의해 프로젝트 구성

필요에 의해 프로젝트 구성

사전에 협의된 요구사항 범위와 목표에 의해 시작

구체적인 목표나 계획 없이 시작

전통적인 프로세스, 방법론에 따라 진행

세부적인 문서 등이 없이 진행

아키텍처를 먼저 수립하고 아키텍처를 기반으로 개발 진행

개발이 먼저 진행되고 아키텍처는 느슨하게 존재

기능/비기능 요구사항에 맞춘 아키텍처 수립

집단 지성과 협업에 의해 아키텍처 수립


<표 2>를 살펴보면, SI 아키텍처는 기술적인 요소가 반드시 포함되고 그에 따라 개발이 진행된다. 하지만, 솔루션 아키텍처는 설계와 개발이 진행되면서 아키텍처가 서서히 정의되기 때문에 기술적인 요소가 아예 포함되지 않을 수도 있다.


또한 두가지 아키텍처의 근본적인 목표는 비즈니스 요구사항을 만족하는 소프트웨어를 만들기 위한 요소들과 그 관계를 정의한 것이다. 따라서 비즈니스를 분석하여 정의하는 프로세스가 두가지 아키텍처에서 모두 존재하게 되는데, 여기서 SI 아키텍처와 솔루션 아키텍처의 가장 큰 차이점이 나타난다. SI 아키텍처는 비즈니스 요구사항을 기술로 해석한 후 필요한 요소들을 정의하여 소프트웨어를 개발하는 것이고, 솔루션 아키텍처는 비즈니스 요구사항을 그 자체로 해석한 후 소프트웨어를 개발한다. 아키텍처는 개발이 진행되면서 최종 완성된다. SI 아키텍처에 요구사항이 제대로 반영되었는지 고객들이 검증하기 어려웠던 것은 기술로 정의된 요인이 크다. <그림 2>는 SI 아키텍처를 정의하는 것을 나타내고 있다.

<그림 2> SI 아키텍처 설계 프로세스



<그림 2>를 살펴보면, 비즈니스 아키텍처 수립 후에 애플리케이션, 기술, 데이터 아키텍처가 정의되는 것을 볼 수 있다. 하지만 내부의 아키텍처 정의 내용들이 모두 기술적으로 정의되고 있다. 기술 요소로 구성된 SI 아키텍처는 설계자나 개발자들이 해석하고 활용하기는 좋으나 추상적인 비즈니스를 기술적인 아키텍처로 옮기기에는 다소 무리가 있다. 이러한 이유로, SI에서는 비즈니스와 기술을 연결해주는 부분을 해결하고자 엔터프라이즈 아키텍처(EA, Enterprise Architecture)를 적용하였지만 크게 호응을 얻지는 못했다.


<그림 3>은 솔루션 아키텍처 설계 프로세스를 나타내고 있다. 비즈니스 전략과 목적을 통해 비즈니스 모델을 만들고 엔터프라이즈 아키텍처를 거쳐 비즈니스 프로세스와 비즈니스 시스템, 그리고 솔루션 아키텍처를 만들고 있다.


<그림 3> 솔루션 아키텍처 설계 프로세스




자료: Alan McSweeney의 Structured Approach to Solution Architecture

솔루션 아키텍처의 근본적인 목적은 <그림 4>에서 보는 것처럼 비즈니스 모델에서 요구되는 요구사항을 효율적이고 명확하게 파악하여 비즈니스 시스템을 정의하고, 이를 소프트웨어로 만들어 딜리버리 하도록 하는 것이다. 비즈니스 모델을 비즈니스 시스템으로 정의하기 위해 엔터프라이즈 아키텍처를 활용한다. 일반적으로 TOGAF를 많이 사용하며, TOGAF는 하단을 참조한다. 여기까지는 SI와 유사하다고 볼 수 있다.

<그림 4> 솔루션 아키텍처 설계의 근본적인 목적


자료: Alan McSweeney의 Structured Approach to Solution Architecture


Enterprise Architecture: TOGAF 개념 이해

https://www.opengroup.org/togaf/


<그림 5>는 비즈니스 요구사항과 아키텍처 기준을 기반으로 솔루션 아키텍처를 정의하고, 이를 솔루션으로 딜리버리하는 것을 나타내고 있다. 이처럼 비즈니스 요구사항 자체를 아키텍처에 반영하고, 이를 바탕으로 원하는 소프트웨어를 딜리버리 하는 것이 솔루션 아키텍처의 장점이라고 볼 수 있다. 다만, 이러한 비즈니스를 반영하기 위해 설계자와 개발자도 비즈니스에 대한 많은 경험과 지식이 요구된다.

<그림 5> 솔루션 딜리버리를 위한 아키텍처 설계



자료: Alan McSweeney의 Structured Approach to Solution Architecture


아키텍처는 만들고자 하는 소프트웨어를 미리 살펴보면서 필요한 요소들을 큰 그림으로 나타내는 것이다. 그리고 소프트웨어를 분석, 설계, 개발하면서 원래의 의도대로 만들고 있는지 비교해보는 기준을 나타내기도 한다. 지금까지 살펴본 바와 같이 SI와 솔루션 아키텍처는 만들어지는 목적과 시점이 다소 다르다. SI의 아키텍처는 고객이 요구하는 환경에 맞게 구성해야 하고, 솔루션 아키텍처는 소프트웨어가 구동하는데 가장 이상적인 환경을 가정하여 구성한다.


이번 회에서는 SI와 솔루션 아키텍처를 구성하는 방법과 역할, 그리고 두 아키텍처에 대한 차이점을 비교해보면서 장단점을 살펴보았다. 모바일 디바이스의 증가 추세로 볼 때, 불특정 다수가 사용하는 솔루션 형태의 소프트웨어가 점점 증가할 것으로 보인다. 지금까지 안정화된 많은 SI 아키텍처의 특징과 구성을 잘 파악하여 지속적으로 늘어나는 솔루션 아키텍처를 효율적으로 구성할 수 있도록 해야 할 것이다. 솔루션 아키텍처는 기하급수적으로 늘어나는 솔루션들의 개발 방향을 알려줄 것이다.

"기본 제공 관리자 계정을 사용하여 XXX를 열 수 없습니다." 메세지가 뜰 때

Posted by 나에요임마
2018. 2. 28. 23:13 Program/Windows


그간 업데이트가 없다가 어느날 윈도우 10 업데이트하고 엣지 브라우저를 열었더니 뜨는 메세지.


굳이 MS 엣지가 아니라도 여러 시스템을 건들 떄마다 떠서 조금 알아봤습니다.



먼저 제어판에서 관리 도구로 들어갑니다.



로컬 보안 정책 -> 보안옵션에서


사용자 계정 컨트롤 : 기본 제공 관리자 계정에 대한 관리자.. 항목을 선택합니다.



이를 사용으로 수정하고 확인 후 재부팅합니다.



출처: http://eteris.tistory.com/963 [Eteris's Palace]

출처: http://eteris.tistory.com/963 [Eteris's Palace]