2020.07.17

종착역에 도달한 윈도우 상의 PHP

Simon Bisson | InfoWorld
PHP는 나온 지 꽤 오랜 시간이 지났지만, 여전히 중요한 웹 개발 툴이다. 선언적 프로그래밍 모델을 기반으로 하는 PHP는 부가적인 명령과 함수로 익숙한 HTML 구문을 더 확장해서 웹 콘텐츠에 인라인 프로그래밍과 확장 기능을 추가한다. 이 모델은 많은 콘텐츠 관리 시스템의 중요한 부분이 되어 데이터베이스를 통해 제공되는 콘텐츠를 관리하고 동적 템플릿으로 페이지 서식을 설정하기 위한 프레임워크를 제공하고 있다.
 
ⓒ Getty Images Bank
 

윈도우에서 PHP의 미래

많은 CMS는 기업 방화벽 내부에서 실행되면서 인트라넷과 내부 협업 툴을 호스팅한다. 그렇게 보면 마이크로소프트가 윈도우용 공식 PHP 빌드를 제공하는 것도 자연스러운 일이다. 사실 가장 오래된 마이크로소프트 자체 오픈소스 프로젝트 중 하나다.

그러나 좋은 일에도 끝은 있는 법이다. 마이크로소프트는 최근 윈도우용 PHP 8 공식 빌드는 없을 것임을 발표했다. 지금까지 마이크로소프트는 IIS와 기타 윈도우 웹 서버용으로 winodws.php.net에 바이너리와 소스 코드로 윈도우 릴리스를 제공해왔다. 그러나 PHP 7 지원 라이프사이클에 걸쳐 윈도우 PHP 빌드를 담당하는 팀이 다른 프로젝트로 이동하면 이후 릴리스 제공은 중단된다.

이번 정책의 변화가 윈도우에서 PHP의 미래에 어떤 영향을 미칠까? 그리고 이번 기회에 작업 방식을 바꾼다면 대안은 무엇일까?
 

분명, 미래는 있다

우선 가장 중요한 점은 윈도우용 PHP가 사라지지 않는다는 것이다. PHP의 수요가 워낙 많은 만큼 PHP 7 이후에도 누군가는 PHP 윈도우 버전을 계속 빌드하고 배포할 것이 분명하다. 마이크로소프트는 리소스와 서버를 직접 투입하지는 않겠지만, 적어도 윈도우 빌드가 자동화된 PHP CI/CD(지속적 통합/지속적 제공) 프로세스를 통해 나올 수 있도록 하기 위해서라도 PHP 프로젝트에 라이선스와 서버를 기증할 가능성이 높다.

비주얼 스튜디오의 빌드 설정이 적절한지 확인해서 필요한 테스트를 실행하고, 코드가 제대로 최적화되었는지 확인하는 데 필요한 윈도우 스킬셋을 익히는 것은 이제 PHP 팀의 몫이다. 크게 어려운 일은 아니겠지만 세계 최대의 소프트웨어 업체에서 전담 리소스를 두는 것과는 다를 수밖에 없다.

또는 다른 업체가 자체 PHP 툴로 만들거나 오픈소스 코드베이스를 기반으로 한 자발적 참여자들이 제공하는 다른 윈도우 PHP 버전도 있다. 지원이 필요한 경우 상용 PHP 버전을 선택하는 것이 좋고, 개방형 빌드는 윈도우 PHP 개발 환경을 구성하는 데 이상적이다.
 

PHP 개발에 WSL 사용하기

대안을 찾고 있다면 마이크로소프트 자체의 애저 앱 서비스(Azure App Service) 클라우드 호스팅 애플리케이션 플랫폼이 PHP를 지원한다는 점에 주목하라. 다만 이 경우 윈도우가 아닌 리눅스에서 실행된다. 따라서 애저 앱 서비스용으로 코드를 빌드한다면 개발 프로세스의 중심에 리눅스 버전의 PHP를 두고, 비주얼 스튜디오 코드에서 원격 워크스페이스 툴을 사용해 대상으로 지정해야 한다. 비주얼 스튜디오 코드용 PHP 확장은 인텔리센스(IntelliSense) 지원부터 디버깅, 코드 서식 툴에 이르기까지 많다.

WSL (Windows Subsystem for Linux)에 PHP를 설치하는 과정은 쉽다. 선택한 패키지 관리자를 통해 필요한 모든 종속 항목이 설치된다. 우분투 WSL 인스턴스에 PHP를 설치하면 아파치 웹 서버가 설치 및 구성되므로 코드를 쓰고 테스트하는 단계에서 프로덕션 웹 서버에서 실행하는 단계까지 신속하게 이동할 수 있다. 설치에는 몇 분 정도가 소요되며 윈도우 터미널 안에서 모든 항목을 즉시 실행할 수 있고, 윈도우 내에서 실행되는 비주얼 스튜디오 코드에서 액세스할 수 있다. WSL 1을 사용하든 WSL 2를 사용하든 과정은 대부분 동일하다.

리눅스 PHP 인스턴스가 개발 머신에서 실행되면, 이제 PHP 애플리케이션을 빌드하고 애저 앱 서비스나 호스팅되는 웹 서버에 배포하기 전에 테스트할 수 있다. WSL 2를 사용한다면 새 개발 모델과 함께 도커 컨테이너 최신 릴리스를 사용할 수 있다. 개발 PC로 WSL에서 코드를 빌드한 다음 컨테이너로 패키징하면 네트워크, 호스팅 서비스 또는 퍼블릭 클라우드의 서버에 더욱 쉽게 배포할 수 있다.

WSL을 통해 리눅스에서 PHP를 사용하는 방법은 윈도우 기반 PHP 개발 측면에서 가장 원만한 옵션이지만, 더 현대적인 웹 개발 모델에서는 다른 방법도 사용할 수 있다. 선택할 수 있는 옵션은 많다. ASP.NET을 사용해 마이크로소프트 생태계 내에 남을 수도 있고, 잼스택(Jamstack)과 같은 접근 방법을 사용해 정적 사이트 개발을 기반으로 하는 크로스 플랫폼 모델로 전환할 수도 있다.
 

새로운 개발 모델: 닷넷 블레이저와 애저 스태틱 웹 앱

한 가지 확실한 것은 PHP에 사용되는 선언적 웹 애플리케이션 개발 모델은 사라지지 않는다는 점이다. 마이크로소프트의 PHP에 대한 공식 지원이 종료되는 데 대한 가장 설득력 있는 설명은 더 새로운 마이크로소프트 기술이 더 적은 리소스를 사용하고 여러 플랫폼에 걸쳐 작동하면서 비슷한 개발 옵션을 제공할 수 있다는 것이다. 또한 새로운 웹 기술을 지원하기 위한 로드맵도 있다.

ASP.NET 코어는 서버 측 닷넷 코드를 사용해 HTML 및 자바스크립트 구성 요소를 제공하는 크로스 플랫폼 환경이다. ASP.NET 코어의 레이저(Razor) 구문은 이식 가능한 닷넷 코어 런타임을 기반으로 PHP와 비슷한 선언적 프로그래밍 방법을 제공한다. 그러나 서버 측 블레이저(Blazor) 프로그래밍 모델과 함께 사용하는 경우에는 큰 차이가 있다.

단일 페이지 웹 애플리케이션에 초점을 두는 블레이저 서버는 웹 서버에서 ASP.NET 코드를 실행하고, 브라우저 콘텐츠와 백엔드 서비스 간의 시그널 R(Signal R) 연결과 함께 콘텐츠를 사전 렌더링된 웹 구성 요소로 컴파일한다. 이 방법은 각 상호작용에 필요한 서버와 브라우저 사이의 왕복 연결로 인한 약간의 지연이 발생하는 대신 필요한 대역폭이 비교적 적다는 이점이 있다. 이 방식으로 콘텐츠를 사전 렌더링하면 UI 구성 요소를 새로 고치는 상호작용을 통해 사용자가 체감하는 애플리케이션의 응답성이 더 높아진다.

최근 애저 앱 서비스의 일부로 출시된 애저 스태틱 웹 앱(Azure Static Web Apps)은 애저와 윈도우에서 웹 콘텐츠를 만들고 사용하는 새로운 방법을 제공한다. 비주얼 스튜디오 코드를 사용해서 로컬로 사이트를 빌드하고 깃허브(GitHub)에 콘텐츠를 호스팅하면 맞춤형 깃허브 작업이 업데이트된 콘텐츠를 애저에 배포한다. 사이트는 HTML, 클라이언트 측 자바스크립트와 데이터베이스, 그리고 다른 서비스에 대한 API 연결을 사용해서 구축된다.

블레이저 및 PHP와 마찬가지로 잼스택도 사이트 디자인에 대해 템플릿 기반 접근 방식을 사용하지만, 전통적인 CMS보다는 콘텐츠 제공 네트워크를 통해 배포가 가능한 파일 기반 콘텐츠에 더 적합하다. 이러한 네트워크를 사용해 사용자에게 더 근접한 위치에서 콘텐츠를 캐시할 수 있다. 잼스택 기술을 사용해서 콘텐츠 기반 애저 스태틱 웹 앱 사이트를 빌드할 수 있지만, 새 콘텐츠를 게시할 때마다 전체 사이트를 다시 빌드해야 한다는 점에 유의해야 한다.

마이크로소프트가 자체 PHP 빌드에 대한 지원을 끝내는 것을 두고 재앙이라고 할 수는 없다. 마이크로소프트의 우선 순위가 바뀌었음을 나타내는 신호로 보는 것이 타당하다. WSL, 애저에서 호스팅되는 리눅스와 같은 기술은 PHP 코드를 빌드하고 실행하기 위한 대체 경로를 제공한다.

또한 웹 애플리케이션 개발을 위한 다른, 더 현대적인 접근 방법이 닷넷 및 현대적 애플리케이션 개발 기술을 기반으로 하는 마이크로소프트의 현재 클라우드 중심 경로와 더 밀접하게 정렬된다는 신호일 수도 있다. 여러분 입장에서는 어떻게 하기로 결정하든 선택할 수 있는 옵션은 풍부하다. editor@itworld.co.kr


PHP / WSL / 닷넷
2020.07.17

종착역에 도달한 윈도우 상의 PHP

Simon Bisson | InfoWorld
PHP는 나온 지 꽤 오랜 시간이 지났지만, 여전히 중요한 웹 개발 툴이다. 선언적 프로그래밍 모델을 기반으로 하는 PHP는 부가적인 명령과 함수로 익숙한 HTML 구문을 더 확장해서 웹 콘텐츠에 인라인 프로그래밍과 확장 기능을 추가한다. 이 모델은 많은 콘텐츠 관리 시스템의 중요한 부분이 되어 데이터베이스를 통해 제공되는 콘텐츠를 관리하고 동적 템플릿으로 페이지 서식을 설정하기 위한 프레임워크를 제공하고 있다.
 
ⓒ Getty Images Bank
 

윈도우에서 PHP의 미래

많은 CMS는 기업 방화벽 내부에서 실행되면서 인트라넷과 내부 협업 툴을 호스팅한다. 그렇게 보면 마이크로소프트가 윈도우용 공식 PHP 빌드를 제공하는 것도 자연스러운 일이다. 사실 가장 오래된 마이크로소프트 자체 오픈소스 프로젝트 중 하나다.

그러나 좋은 일에도 끝은 있는 법이다. 마이크로소프트는 최근 윈도우용 PHP 8 공식 빌드는 없을 것임을 발표했다. 지금까지 마이크로소프트는 IIS와 기타 윈도우 웹 서버용으로 winodws.php.net에 바이너리와 소스 코드로 윈도우 릴리스를 제공해왔다. 그러나 PHP 7 지원 라이프사이클에 걸쳐 윈도우 PHP 빌드를 담당하는 팀이 다른 프로젝트로 이동하면 이후 릴리스 제공은 중단된다.

이번 정책의 변화가 윈도우에서 PHP의 미래에 어떤 영향을 미칠까? 그리고 이번 기회에 작업 방식을 바꾼다면 대안은 무엇일까?
 

분명, 미래는 있다

우선 가장 중요한 점은 윈도우용 PHP가 사라지지 않는다는 것이다. PHP의 수요가 워낙 많은 만큼 PHP 7 이후에도 누군가는 PHP 윈도우 버전을 계속 빌드하고 배포할 것이 분명하다. 마이크로소프트는 리소스와 서버를 직접 투입하지는 않겠지만, 적어도 윈도우 빌드가 자동화된 PHP CI/CD(지속적 통합/지속적 제공) 프로세스를 통해 나올 수 있도록 하기 위해서라도 PHP 프로젝트에 라이선스와 서버를 기증할 가능성이 높다.

비주얼 스튜디오의 빌드 설정이 적절한지 확인해서 필요한 테스트를 실행하고, 코드가 제대로 최적화되었는지 확인하는 데 필요한 윈도우 스킬셋을 익히는 것은 이제 PHP 팀의 몫이다. 크게 어려운 일은 아니겠지만 세계 최대의 소프트웨어 업체에서 전담 리소스를 두는 것과는 다를 수밖에 없다.

또는 다른 업체가 자체 PHP 툴로 만들거나 오픈소스 코드베이스를 기반으로 한 자발적 참여자들이 제공하는 다른 윈도우 PHP 버전도 있다. 지원이 필요한 경우 상용 PHP 버전을 선택하는 것이 좋고, 개방형 빌드는 윈도우 PHP 개발 환경을 구성하는 데 이상적이다.
 

PHP 개발에 WSL 사용하기

대안을 찾고 있다면 마이크로소프트 자체의 애저 앱 서비스(Azure App Service) 클라우드 호스팅 애플리케이션 플랫폼이 PHP를 지원한다는 점에 주목하라. 다만 이 경우 윈도우가 아닌 리눅스에서 실행된다. 따라서 애저 앱 서비스용으로 코드를 빌드한다면 개발 프로세스의 중심에 리눅스 버전의 PHP를 두고, 비주얼 스튜디오 코드에서 원격 워크스페이스 툴을 사용해 대상으로 지정해야 한다. 비주얼 스튜디오 코드용 PHP 확장은 인텔리센스(IntelliSense) 지원부터 디버깅, 코드 서식 툴에 이르기까지 많다.

WSL (Windows Subsystem for Linux)에 PHP를 설치하는 과정은 쉽다. 선택한 패키지 관리자를 통해 필요한 모든 종속 항목이 설치된다. 우분투 WSL 인스턴스에 PHP를 설치하면 아파치 웹 서버가 설치 및 구성되므로 코드를 쓰고 테스트하는 단계에서 프로덕션 웹 서버에서 실행하는 단계까지 신속하게 이동할 수 있다. 설치에는 몇 분 정도가 소요되며 윈도우 터미널 안에서 모든 항목을 즉시 실행할 수 있고, 윈도우 내에서 실행되는 비주얼 스튜디오 코드에서 액세스할 수 있다. WSL 1을 사용하든 WSL 2를 사용하든 과정은 대부분 동일하다.

리눅스 PHP 인스턴스가 개발 머신에서 실행되면, 이제 PHP 애플리케이션을 빌드하고 애저 앱 서비스나 호스팅되는 웹 서버에 배포하기 전에 테스트할 수 있다. WSL 2를 사용한다면 새 개발 모델과 함께 도커 컨테이너 최신 릴리스를 사용할 수 있다. 개발 PC로 WSL에서 코드를 빌드한 다음 컨테이너로 패키징하면 네트워크, 호스팅 서비스 또는 퍼블릭 클라우드의 서버에 더욱 쉽게 배포할 수 있다.

WSL을 통해 리눅스에서 PHP를 사용하는 방법은 윈도우 기반 PHP 개발 측면에서 가장 원만한 옵션이지만, 더 현대적인 웹 개발 모델에서는 다른 방법도 사용할 수 있다. 선택할 수 있는 옵션은 많다. ASP.NET을 사용해 마이크로소프트 생태계 내에 남을 수도 있고, 잼스택(Jamstack)과 같은 접근 방법을 사용해 정적 사이트 개발을 기반으로 하는 크로스 플랫폼 모델로 전환할 수도 있다.
 

새로운 개발 모델: 닷넷 블레이저와 애저 스태틱 웹 앱

한 가지 확실한 것은 PHP에 사용되는 선언적 웹 애플리케이션 개발 모델은 사라지지 않는다는 점이다. 마이크로소프트의 PHP에 대한 공식 지원이 종료되는 데 대한 가장 설득력 있는 설명은 더 새로운 마이크로소프트 기술이 더 적은 리소스를 사용하고 여러 플랫폼에 걸쳐 작동하면서 비슷한 개발 옵션을 제공할 수 있다는 것이다. 또한 새로운 웹 기술을 지원하기 위한 로드맵도 있다.

ASP.NET 코어는 서버 측 닷넷 코드를 사용해 HTML 및 자바스크립트 구성 요소를 제공하는 크로스 플랫폼 환경이다. ASP.NET 코어의 레이저(Razor) 구문은 이식 가능한 닷넷 코어 런타임을 기반으로 PHP와 비슷한 선언적 프로그래밍 방법을 제공한다. 그러나 서버 측 블레이저(Blazor) 프로그래밍 모델과 함께 사용하는 경우에는 큰 차이가 있다.

단일 페이지 웹 애플리케이션에 초점을 두는 블레이저 서버는 웹 서버에서 ASP.NET 코드를 실행하고, 브라우저 콘텐츠와 백엔드 서비스 간의 시그널 R(Signal R) 연결과 함께 콘텐츠를 사전 렌더링된 웹 구성 요소로 컴파일한다. 이 방법은 각 상호작용에 필요한 서버와 브라우저 사이의 왕복 연결로 인한 약간의 지연이 발생하는 대신 필요한 대역폭이 비교적 적다는 이점이 있다. 이 방식으로 콘텐츠를 사전 렌더링하면 UI 구성 요소를 새로 고치는 상호작용을 통해 사용자가 체감하는 애플리케이션의 응답성이 더 높아진다.

최근 애저 앱 서비스의 일부로 출시된 애저 스태틱 웹 앱(Azure Static Web Apps)은 애저와 윈도우에서 웹 콘텐츠를 만들고 사용하는 새로운 방법을 제공한다. 비주얼 스튜디오 코드를 사용해서 로컬로 사이트를 빌드하고 깃허브(GitHub)에 콘텐츠를 호스팅하면 맞춤형 깃허브 작업이 업데이트된 콘텐츠를 애저에 배포한다. 사이트는 HTML, 클라이언트 측 자바스크립트와 데이터베이스, 그리고 다른 서비스에 대한 API 연결을 사용해서 구축된다.

블레이저 및 PHP와 마찬가지로 잼스택도 사이트 디자인에 대해 템플릿 기반 접근 방식을 사용하지만, 전통적인 CMS보다는 콘텐츠 제공 네트워크를 통해 배포가 가능한 파일 기반 콘텐츠에 더 적합하다. 이러한 네트워크를 사용해 사용자에게 더 근접한 위치에서 콘텐츠를 캐시할 수 있다. 잼스택 기술을 사용해서 콘텐츠 기반 애저 스태틱 웹 앱 사이트를 빌드할 수 있지만, 새 콘텐츠를 게시할 때마다 전체 사이트를 다시 빌드해야 한다는 점에 유의해야 한다.

마이크로소프트가 자체 PHP 빌드에 대한 지원을 끝내는 것을 두고 재앙이라고 할 수는 없다. 마이크로소프트의 우선 순위가 바뀌었음을 나타내는 신호로 보는 것이 타당하다. WSL, 애저에서 호스팅되는 리눅스와 같은 기술은 PHP 코드를 빌드하고 실행하기 위한 대체 경로를 제공한다.

또한 웹 애플리케이션 개발을 위한 다른, 더 현대적인 접근 방법이 닷넷 및 현대적 애플리케이션 개발 기술을 기반으로 하는 마이크로소프트의 현재 클라우드 중심 경로와 더 밀접하게 정렬된다는 신호일 수도 있다. 여러분 입장에서는 어떻게 하기로 결정하든 선택할 수 있는 옵션은 풍부하다. editor@itworld.co.kr


PHP / WSL / 닷넷
X