...++
=


엊그제에 밤2시까지 삽질해 성공한 기념으로 아주 간략하게 작성. 질문 받습니다.
여기서 말하는 "닷홈"이란 한국식 LAMP 스택의 shared hosting이라고 보시면 됨.


사전 준비사항

  • 이 글은 모든 작업을 윈도우에서 한다고 가정한다. 리눅스/맥 쓰시는 분들은 훨씬 쉽게 할 수 있는 작업이니 필요한 명령줄은 알아서 연구하시길.
  • 최소한의 php 상식
  • php, composer (라라벨 인스톨러는 쓰지 않는다.)
  • Git 관리툴 (FTP로 수동배포하는 과정에서 버전을 관리하기 위한 용도. 잘 모르면 소스트리 쓰자.)
  • FTP 클라이언트 (닷홈에 수동배포하려는 용도. 잘 모르면 파일질라 쓰자.)
  • PHP 5.6.4 이상이 돌아가는 닷홈 계정 (닷홈에서 PHP 7.0을 굴리려면 무제한 호스팅을 받아야 한다. 여기서 도메인 구매하는 댓가로 FREE 티어를 쓸수있게 해놓았으니 참고하시길... 제길 이런글 쓴다고 레퍼럴 받는것도 아닌데)


tl;dr

이하의 서술은 닷홈 호스팅의 두 가지 문제를 극복하는 과정을 안내한다. composer와 artisan을 못 쓰는 문제, 요청 실행 담당 파일이 마음대로 지목되지 않는 문제. 이 두 가지가 별문제가 아니라고 생각된다면 더 읽지 않아도 됨.

로컬에서는 php artisan make:migration create_foo_table 같은 콘솔도 쓸 수 있고 composer install foo 같은 것도 얼마든지 실행할 수 있지만 닷홈의 대부분 호스팅 상품은 공식적으로 SSH 접속이나 컴포저 실행, 쉘스크립트 실행 등을 할 수 없다. 요즘처럼 모든 것이 패키징 체계로 되어 있는 웹앱 개발 환경에서 이는 치명적인 제약이다.

게다가 로컬의 라라벨과 프로덕션인 닷홈은 웹 요청 수행 방식이 다르다. 라라벨은 루트폴더의 server.php를 실행하는데, 닷홈은 별도의 .htaccess 설정이 없는 한은 걍 아무 생각 없이 각 계정에 대하여 /host/home숫자/계정명/html 디렉토리의 index.htm(l)이나 index.php만을 열고 보기 때문이다. 어떤 요청에 대해서 .htaccess가 특정 파일을 포인팅해 주지 않으면, 그 요청의 응답은 영원히 403404, 500 또는 310(Too many redirects)뿐일 것이다.

여기에 사소한 몇 가지 요점을 짚고 가려고 한다. 예컨대 라라벨 버전 문제인데, PHP 7.1이 아닌 PHP 7.0의 서버라면 라라벨 버전은 5.5까지만 쓸 수 있다. 이제부터 조금씩 살펴보자.


1. 상쾌하게 새 앱으로 시작하기 (단, 버전에 맞춰서)

이미 로컬에서 돌아가고 있는 라라벨 앱이 있다면 최악의 경우 그 앱을 다운그레이드해야 하는 상황이 올 수 있다. 그런데 라라벨에서 다운그레이드란 새 프로젝트를 낮은 버전으로 시작해 거기에 마이그레이션하는 것만을 뜻한다. 그렇게 따지면 아마도 이 스텝은 필수인 듯.

1-1. 라라벨을 올리고 싶은 닷홈 호스팅의 PHP 버전을 알아내고, 이 버전을 지원하는 최신 라라벨 버전이 뭔지 각 버전별 설치 문서에 가서 확인해 본다. 대리클릭을 해드리자면 PHP가 7.0일 땐 5.5까지, PHP가 5.6.4 이상일 땐 5.4까지.

1-2. 앱을 설치할 디렉토리로 가서 커맨드를 열고 라라벨 설치 명령을 실행한다. 예컨대 설치할 수 있는 라라벨 최고 버전이 5.5버전대라면 이렇게 입력한다. (자동으로 현시점 최신 버전인 5.5.28을 깔아준다.)

> composer create-project laravel/laravel 앱이름 "5.5.*" --prefer-dist

1-3. 컴포저 특유의 무반응이 잠시 이어지다가 한바탕 폭풍 설치가 끝나면 Git 관리툴을 열고 이 폴더를 기존 존재하는 저장소로서 생성해 커밋&푸시하고 버전 관리를 시작한다.
소스트리 기준으로 설명하자면: New Tab > Create > 지금 만든 폴더 선택 > 저장소 이름이나 나머지는 뭐 알아서 > 생성 > Yes > 작업공간 > 모두 스테이지에 올리기 > 커밋 > Push.

1-4. 설치된 디렉토리로 이동해 php artisan serve를 실행해본다. 별문제가 없어야 한다.

1-5. /public 폴더에 assets라는 이름으로 빈 폴더를 하나 만들고 거기에 css 폴더와 js 폴더를 때려넣어 둔다. 3번 스텝에서 해야 할 작업을 미리 해놓는 것.


2. 최초 버전 unzip 배치

이짓을 하는 이유는 /vendor 디렉토리에 너무 많은 폴더와 파일이 들어 있기 때문이다. 이걸 전부 FTP로 올리는 것은 바보짓이며, 번번이 이렇게 할 수도 없는 노릇이다. composer가 바로 이 문제를 해결한 툴이지만, 우리는 닷홈 서버를 빌려 쓰고 있어 컴포저를 쓸 수 없으니 일단 갓 구워진 라라벨 정도로만 올려보자. AWS 엘라스틱 빈스톡에서 영감을 얻음.

2-1. 라라벨이 설치된(=server.php 파일이 있는) 폴더의 내용 전체를 압축해 파일명.zip을 만들어둔다.

2-2. 다음 코드를 적당히 활용한 적당한이름.php 파일을 만들어둔다.

<? header("Content-Type: text/html; charset=UTF-8"); ?>

<a href="?unzip=true">Unzip 실행</a>

<?php
if ($_GET['unzip']) {
$zip = new ZipArchive;
if ($zip->open('파일명.zip') === TRUE) {
$zip->extractTo('./');
$zip->close();
echo '<br><br>배치 성공';
} else {
echo '<br><br>배치 실패';
}
} else {
phpinfo();
} ?>

대단히 스트레잇포워드한 코드인데 설명하자면 이렇다. 파일을 웹브라우저로 딱 보면 Unzip 실행이라 써진 링크 하나가 있고 그 밑에 이 서버의 php 정보가 줄줄이 달린다. 링크를 누르면 그 정보가 없어지고 배치가 성공했는지 실패했는지를 알려준다.

2-3. FTP 클라이언트로 닷홈 계정에 접속해 파일명.zip 압축파일과 적당한이름.php 파일을 같이 루트폴더에 올린다. (닷홈은 전형적으로 /html 폴더가 루트임)

2-4. http://닷홈계정주소/적당한이름.php 에 접속해본다. 설명한 대로 링크 하나와 php 설치정보가 떠야함.

2-5. 과감하게 Unzip 실행을 한다.

2-6. 배치 성공이라 떴는지, 그리고 실제로 FTP로 새로고침을 했을 때 로컬에 보이는 폴더와 파일들이 막 보이는지 확인한다.

2-7. 큰 산을 넘었다는 안도감을 가지도록 한다. (이후 필요할 경우 /vendor 폴더에 대해서만 이 꽁수를 써서 일괄 업로드할 수도 있을 것이다. extractTo() 함수는 덮어쓰기가 기본이므로 별문제 없을 것.)


3. public 폴더 바꿔치기

이 스텝은 왜 필요한가 하면 앞서 설명한 index.php를 루트에 띄워주기 위해 필요하다. 희한하게도 서양에서는 'public' 폴더가 닷홈 호스팅의 'html'에 해당한다고 한다. 요컨대 라라벨 앱 업로드 과정에서 그 public을 이 public으로 자연스럽게 덮어쓸 수 있으면 OK라는 것이다. 그래서 물정 모르는 서양 답변자들은 가끔 "퍼블릭폴더 위에 앱을 설치하면 그만인데 왜 우는소리를 해~" 같은 속터지는 소리를 한다. 하지만 닷홈은 그게 안 되니까 이짓을 하는 것. 결정적으로 도움이 된 것은 이 문서.

여기서는 라라벨을 닷홈 서버의 루트에 설치한다고 가정한다. 이 작업 자체는 닷홈 서버에서만 수행한다.

3-0. 잘 모르겠다면 다음 내용을 복사해 루트폴더에 .htaccess 파일로 저장하고 접속해 본다. 이것만 했는데 해결이 됐다면 (즉, 사이트가 뜬다면) 사실 이후의 3-x단계 및 4-x단계는 안 해도 된다. Thanks to 잘보고갑니다

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)$ public/$1 [L]
</IfModule>

해결이 안 되면 다음 스텝으로 넘어간다.

3-1. 1-5를 아직 해놓지 않았다면 지금이라도 해놓고 닷홈서버에서도 동일하게 적용해 준다.

3-2. /public 폴더에 있는 '파일들'을 모두 복사해 그 위 폴더인 루트 폴더에 붙인다.

3-3. 라라벨 5.5 기준으로는 지금 붙여넣은 루트폴더의 index.php에 이런 라인들이 있을 것인데, 각각 알맞게 고친다.

require __DIR__.'/../vendor/autoload.php'; // 이렇게 생긴 라인은
require __DIR__.'/vendor/autoload.php'; // 이렇게 고칠것

$app = require_once __DIR__.'/../bootstrap/app.php'; // 이렇게 생긴 라인은
$app = require_once __DIR__.'/bootstrap/app.php'; // 이렇게 고칠것

한마디로, /public 폴더 기준으로 써져 있었던 로딩 파일들 주소를 루트폴더 기준으로 고친다.

3-4. 하나 더, 루트폴더에 있는 server.php를 고쳐준다.

# 고치기 전

if ($uri !== '/' && file_exists(__DIR__.'/public'.$uri)) {
    return false;
}

require_once __DIR__.'/public/index.php';


# 고친 후

if ($uri !== '/' && file_exists(__DIR__.$uri)) {
    return false;
}

require_once __DIR__.'/index.php';

3-5. http://닷홈계정주소/home 에 접속해 본다. 뷰 파일을 건드린 적이 없는데도 css와 js 파일이 로딩되지 않아 와장창 깨지고 있을 것이다. 이 부분을 4단계에서 해결한다.


4. 환경 구분해주기

이제 거의 모두 해결됐고, 3단계에서 해결되지 않은 퍼블릭 애셋 경로 문제만 남는다. php 소스들 자체는 로컬에서나 닷홈에서나 같아야 하는데, 로컬에서는 asset() 함수에 'assets/css/app.css' 경로를 넘겨줘야 되는 반면 닷홈에서는 'public/assets/css/app.css'를 넘겨줘야 된다. 어쩌면 좋냐고? htaccess 쓸줄 모른다고? 걱정마시라. 이런 건 env로 아주 간단하게 조치하면 된다.

4-1. 로컬의 루트에 있는 .env 파일을 편집기로 열고 다음 설정을 아무데나 추가한다.

ASSETS_DIR=assets

4-2. 소스코드 내 필요한 모든 곳에서 다음과 같은 찾아바꾸기를 실시한다. 4-1에서 저장한 변수를 불러오도록 하는 것.

// 바꾸기 전
{{ asset('assets/css/app.css') }}

// 바꾼 후
{{ asset(env('ASSETS_DIR').'/css/app.css') }}

4-3. 로컬의 .env 파일 내용 전체를 복사한 다음, 닷홈서버의 루트에 .env 파일을 새로 만들고, 그 파일의 내용을 방금 복사한 내용으로 덮어쓴 다음에, 이 부분을 고친다.

ASSETS_DIR=public/assets

4-4. 이것으로 우리는 마침내 로컬에서 돌아가는 여러분의 앱이 닷홈에서 그 모습 그대로 똑같이 돌아가는 것을 보게 되었다. 앞으로 애셋을 불러와야 할 일이 있을 때는 아묻따 env('ASSETS_DIR') 하나로 오케이.


5. 부록: 버전을 관리해서 필요한 파일만 추가 FTP 배치하기

아주 간단히 설명하고 지나간다.

5-1. 로컬에서 이 소스를 Git으로 관리한다.

5-2. 배포할 커밋 위치로 체크아웃한다.

5-3. 다음 명령어 실행하여 싹 zip으로 묶는다.

git archive --format=zip master -o ../foobar.zip

5-4. 2번 스텝에서 만들어 놓은 코드를 활용해 묶어놓은 zip을 루트에 싹 올려 덮어씌운다. 끝.


6. 부록: 아티즌 콘솔 써서 마이그레이션 하기

닷홈서버의 DB에 이미 잔존하는 테이블을 활용하는 거라면 걍 DB 덤프받아 로컬에 복붙해 시딩하고 php artisan make:model Foo 돌려 모델 만들고 그걸 배포하면 그만이지만, 없던 테이블을 만든다면 라라벨의 컨벤션에 맞게 정식으로 스키마를 만들어 마이그레이션하는 과정을 거쳐야 한다.

6-1. 일단 로컬에서 마이그레이션 직전까지 해놓는다. php artisan make:migration create_foo_table을 실행해 파일 자동 생성을 시키고, 생성된 파일의 up() 메소드와 down() 메소드를 적당히 매뉴얼 봐 가면서 채운다.

6-2. /routes/web.php 파일의 맨 끝에 아티즌 콘솔 명령을 실행하는 라인을 하나 넣는다.

Route::get('/artisan_console', function(){
Artisan::call('migrate');
});

6-3. 로컬에서 localhost:8000/artisan_console 에 접속해 up() 메소드가 계획대로 잘 돌아갔는지 확인하고, 확인되었으면 닷홈서버의 /database/migrations 디렉토리에 생성된 마이그레이션 파일을 올린 다음 /routes/web.php에 로컬과 같은 수정내역을 적용해, 마찬가지로 접속 실행한다. 닷홈DB에 migrations 테이블이 자동으로 만들어지게 되는데, 없으면... 걍 하나 만들면 됨.


후기

  1. 쓸데없이 길어졌네요. 제가 읽고 싶었던 문서를 제가 쓰다 보니 그렇게 되었던듯
  2. 아무튼 .htaccess는 웬만하면 건드리는 것이 아닙니다. 혹시 RewriteBase, RewriteCond, RewriteRule 같은것 붙잡고 씨름하고 계시다면 머리를 비우고 새로 다시 처음부터 생각해 보시길.
  3. 도움이 되려나 모르겠네요.


Posted by 엽토군
:

늘 쓰고 싶던 테마였는데 이번에 무한도전 "시즌1" 종영을 기념하여 아주 콤팩트하게 써본다. 이거보다 길어지면 나도 헷갈리고 모두가 헷갈리는듯.


세트장이라는 것이 있다. 지금이야 너무 당연해진 개념이지만 예전에는 '버라이어티 예능'을 하기 위해 도입된 혁신적 장치였던 세트장이란, 어떤 굉장한 볼거리를 만들어내기 위해 (그리고 그것을 보장받기 위해) 각종 장치와 설비가 고안되어 작동하는 기계/전기 조립체 일체였다. 사람들은 그 안에 들어가서 울고 웃고 때리고 뒹굴며 '오락 프로'를 만들었다.

세트장은 목적지향적, 결과지향적 엔터테인먼트의 정수라 할 수 있다. 세트장을 만드는 이유 자체가 무슨 일이 있어도 어떤 '그림'만큼은 '따내겠다'라는 의지에 있기 때문이다. 세트장은 그것을 가능하게 해 준다. 대신 그 반대 급부로서 주어진 규격과 분량에 맞춰서, 계산된 재미를 위해서, 모두가 각본에 따를 것을 요구한다.

여기서는 자세히 다루지 않겠지만, 그런 의미에서 세트장은 21세기 초엽까지 우리에게 주어져 있던 성장 중심적 계획과 사회의 첨병에 다름아니었다. 어떤 목표와 도전 과제를 달성할 수 있다고 보장하는 대신, 각 개인의 계획과 규격, 행복의 기준과 방향을 제어하는 세상을 우리는 살았고, 그게 어느 정도 순기능을 했다. 우리는 한때 대형 버라이어티 쇼의 거대한 세트장을 진심으로 우러러보았던 적이 있는 것이다.


그리고 초창기 무한도전은 바로 이 '세트장'을 빠져나오려 하는 예능이었다. 아하 게임을 하던 '스튜디오'(그것은 최소한의 의미에서의 세트장이기도 하다)에서 시작한 그들은 장충체육관으로, 동대문 운동장으로 (이것들은 좀더 세트장에서 멀어진 것이다) 가더니 지하철과 달리기를 할 수 있는 어딘가로(여기서부터 세트장이 아니었다) 가면서부터 본격적으로 물리적인 세트장을 탈피해 왔다.

한때는 전형적이고 다소 상투적이기까지 했던 방송가의 물리적 세트장을 벗어나는 것만으로도 큰웃음이 보장되곤 했다. 대표적으로 모내기 특집이 그랬다. 비 오는 논두렁에서 뒹구는 일은 그 자체로 시답잖게 우스운 것이다. '세트장 아닌 세트장'을 통해 변칙적으로 재미를 확보하는 이러한 의존성은 최근의 방콕 특집 같은 것에도 발견되었던 바다.

아무튼, 이후 시간이 지나면서 물리적 세트장을 벗어나기만 해서는 머지않아 '(성장 발전상의 )동력' 자체를 잃어버릴 것을 직감한 TEO 사단은 새로운 세트장을 구성한다. 바로 관념적 세트장이다. 무한도전은 갈수록 'OOO 특집'의 이름으로 특정 주제/과제/컨셉을 내걸고 이것 하나에 모든 여건과 아이디어와 몸개그를 전면 집중해 70분을 채우는 (그걸 실패한 '특집'은 통편집되어 재방송을 타는) 체제를 만들어냈다.

왜 관념적 세트장이냐면, 기존의 세트장에서 볼 수 있던 철골 구조물, 카펫, 폭죽 같은 물리적 요소들은 사실상 없어지되 개그, 상황극, 캐릭터, 도전, 팀 꾸리기, 액션, 교훈, 사회적 의의 등등 비물질적이고 관념적인 요소들을 철저하게 계산하여 특정 감동과 재미를 창출할 수 있도록 배치하고 있었기 때문이다. 이것들이 계획대로 잘 될수록 그 특집은 레전설이 되었고, 잘 안 되었을 때는 통편집되어 창고에 박혀 있다가 발굴되곤 했다.


그들은 과연 세트장 자체에서 벗어난 것일까? 그렇게 보기 어렵다. 방송의 본질상 70여분간 별 요점이 없는 신변잡기를 내보낼 수는 없었다는 점에서, 무한도전의 지난 십몇 년 역사상 그들은 성장주의, 목적주의, 성과주의에서 결코 벗어나본 적이 없었다. 각본과 세트장이 주어지지 않는 예능에서도 빅재미를 만들어낸다며 뛰쳐나간 그들이 정작 스스로 만든 각본과 세트장에서 낑낑대게 된 꼴이란 아이러니가 아니면 무엇인가.

심지어 '쉬러 간다', '우천시 취소하는 특집으로 한다' 같은 관념적 세트장을 나가는 듯한 기획마저도 사실은 치밀하게 (또는 어쩔 수 없이) 그 자체로서 하나의 각본, 체계, 어떤 그림을 무조건 따내기 위해 고안된 설계와 배치로 기능했다. 방송이니 그래야만 했다. 심지어 무한도전은 리얼 예능을 표방한 탓에 오히려 그 반대로 작위미, "일부러 철저하게 어떠어떠하게 한다" 하는 기획이 주는 즐거움도 넘볼 수 없게 됐다.

그런 점에서 무한도전 "시즌1" 종영은 시사적이다. 이렇게까지 일부러 대본과 내용구성, 로케이션 등을 '어기고' 다닌 방송은 일찌기 없었는데, 그런 쇼가 유지 불가능성이 가시화된 이후로 그걸 끝내 부정하다가 마지못해 마침내 수긍한 것이기 때문이다. 이렇게 요약할 수 있을까? "그것이 쇼이기를 표방하는 이상은, 그것은 반드시 어떤 형태로든 기획, 각본, 목적하는 결과의 집합체(set)에서 실행되게 되며 그래야만 한다."


무한도전은 자기가 얻어야 할 교훈을 이미 다 얻었겠지만, 그걸 보며 몇 년을 함께한 일반 대중은 과연 어떤 교훈을 제대로 얻고 있을지 모르겠다. 이들의 삶 여러 영역에, 사실은 불가능한 그리고 누구도 강요한 적 없는 성장주의 계획이 삼투되어 있지 않은가 하는 우려가 있기 때문이다.

처음부터 물리적 세트장을 가질 수 없었기에 철저히 자신들의 엔터테인먼트를 자본과 미디어에 의존하고 있었던 일반 대중도, '디카'와 스마트폰을 손에 넣으며 다른 의미에서 물리적 세트장 없이 '쇼'를 해 오기는 했다. 그러나 어쨌든 쇼는 쇼이므로 이들에게는 크게 둘 중 한 가지 일이 일어났는데, 하나는 무한도전이 그랬듯 각종 컨셉과 설정으로 무장한 관념적 세트장을 구축하는 것이고, 다른 하나는 자기 인생 전체를 물리적이고 통합된 세트로 구성해 버린 것이다.

둘 다 별로 건전하지 못하다. 전자는 경제규모 상위국가의 대표 민영방송사의 간판 예능조차 끝내 버티지 못한 고강도의 정신 노동을 일반 대중 개개인이 감수한다는 점에서 그러하고, 후자는 속된말로 자기 인생을 팔아서 관심을 얻고 유지를 하는 마이너스 게임이기 때문이다. 일반 대중이 보고 배운 것은 무한도전이나 인간극장, 세상에 이런일이 등이었을지언정, 그들이 정말 그것을 동경하고 모방할 수는 없는 노릇인 것이다.


탈-세트장 예능의 대표주자였던 무한도전의 종언 이후 가장 질서 있는 퇴장은 무엇일까. 어쩌면 그냥 순순히, 물리적이고 인위적이며 전면적이고 조작적인 계획의 존재를 인정해 버리는 것도 방법일 수 있지 않을까. 우리가 "쇼"라고 이해하는 세계는 철저히 그 계획 속의 세계로 한정하고 샌드박싱하여, 그 안에서만 쇼의 문법과 방식이 작동하게 내버려두고 현실을 사는 사람들은 그 밖에 나와 있는 방식인 것이다.

예를 들자면, 누군가가 아주 그로테스크한 만화의 작가가 될 수는 있겠으나, 작가로서의 그를 예능 방송 게스트로서의 그의 자리에 불러내는 일은 하지 않는 방식일 것이다. 또는, 유튜브 채널을 운영하더라도, 자기 개인사를 죄다 털어놓는 지금 대다수 유튜버들의 방식을 따르기보다는, 채널 속 자아를 좀더 허구적 체계로 확립하고, 분리 관리하며 그것을 게임의 룰로 이해하는 방식일 수도 있겠다.

요는, 쇼를 하겠다는 사람들이 어쭙잖게 대본과 세트장과 계획과 목적의 존재로부터 완전히 벗어나려고 하다간 실패만 하기 십상이라는 것이다. 무한도전 역시 무한하지 못하게 도전을 멈췄다. 우리는 아직 목적지향주의 자체를 중단하고 그 너머를 상상할 만큼의 급진성과 거기 따르는 각종 능력 요건을 갖추지는 못했으므로, 쇼는 결국 쇼이니 순순히 세트를 짜고 그 안에서 행동하자는 겸손한 교훈으로 돌아가야 할 때가 된 것인지도 모른다, 하는 생각이 든다.

'4 생각을 놓은' 카테고리의 다른 글

"개발자" 관련 탐라 플로우 단상  (0) 2021.07.03
김어진쇼에 관하여  (0) 2018.10.09
포주 레진  (0) 2018.01.31
장르로서의 이생망  (0) 2017.10.31
텍스트  (0) 2017.01.10
Posted by 엽토군
:

카테고리

분류 전체보기 (801)
0 주니어 PHP 개발자 (6)
1 내 (326)
2 다른 이들의 (253)
3 늘어놓은 (37)
4 생각을 놓은 (71)
5 외치는 (76)
9 도저히 분류못함 (31)

최근에 올라온 글

최근에 달린 댓글

달력

«   2018/04   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30