
저는 이 글을 통해 PHP를 비난할 생각은 전혀 없습니다.
혹시라도 이 글이 자신을 비난하는 것 처럼 느껴지신다면, 자신과 언어를 동일시하고 있는 게 아닌지 생각해보시기 바랍니다.

## PHP로 시작하다

저는 프로그래밍을 PHP로 시작했습니다.
사실 첫 시작은 프로그래밍이라고 할 수 도 없고, 제로보드 4를 설치하고 아웃로그인[^1]을 붙이는 정도의 간단한 작업을 했습니다.
제 개인 홈페이지를 만들고 싶었기 때문이죠.[^2]
점점 욕심이 생겨서 스킨도 고쳐보고, 플러그인도 뜯어고쳐보기 시작했습니다.
이윽고는 제로보드 4에 없는 기능을 쑤셔 박기 시작합니다.
여기까지는 좋았습니다.
제 마음대로 이것저것 고치는 게 재밌었거든요.

## 보안이 거슬리기 시작하다

어느 날, 게시판에 올린 게시물에 스크립트를 삽입하는 광경을 목격하게 됩니다.
당시 사용자들은 게시물에 서명[^3]에서 랜덤한 이미지를 출력하거나, 댓글란에 placeholder[^4] 같은 것을 만드는 용도로 스크립트를 사용했는데, 어떤 사용자는 그걸 악용해서 무한대로 경고 창을 띄우는 등으로 악용하는 사람이 나타났습니다.
저는 이 심각한 문제를 고치고 싶었습니다.

그때부터 저는 input을 통해 들어온 값에 스크립트를 삽입하는 행위, 즉 XSS[^5]를 막는 방법에 대해 혼자서 연구를 시작했습니다.
그 결과, `<script>` 라는 글자 입력을 막는 것만으로는 부족하다는 것을 알게 되었죠.
그래서 효율적인 방어를 위해 정규식[^6]을 배웠고, 이를 토대로 여러 가지 방법으로 방어해봤습니다.
하지만 정규식으로도 다 막을 수 없었습니다. 당시의 제 지식으론 뾰족한 방법이 없었으므로, 안전한 HTML을 출력하는 대신 위험한 HTML을 감지해서 출력하지 않는 쪽으로 생각을 바꿨습니다.

## 살짝이지만 PHP의 한계는 일찍이 느꼈다

당시 제가 겪던 PHP 문화라고 하면 이렇습니다.

1. PHP 5가 나온 지 얼마 되지 않았다.
2. DB는 MySQL에서 MyISAM을 쓰는 것이 당연했다.
3. EUC-KR 기준의 웹 개발
4. 2로 인해 트랜젝션이 안되므로 안 되므로 DB 작업 전후로 테이블 단위 lock을 건다.
5. 함수[^7] 기반의 프로그래밍. class는 쓰지 않는다.
6. `register_globals`

저는 욕심이 났습니다.
PHP 5도 써보고 싶었고, EUC-KR이 아닌 UTF-8도 써보고 싶었습니다.
그래서 호스팅도 옮기고, 웹 사이트도 UTF-8로 고쳤죠.

이러니 좀 더 본질적인 문제가 나타났습니다.
저는 좀더 고급 프로그래밍 기법을 사용하고 싶었는데, PHP에서는 이를 전혀 지원하지 않았습니다.
가령 함수를 변수로 넘겨줄 때, PHP에서는 함수명을 `'` 로 감싸야만 한다던가 하는 부분이 맘에 안 들었습니다.
타입을 변수처럼 다룰 수 없는 문제도 맘에 안 들었던 것 같습니다.
변수를 정수로 바꾸려면 `(int)`를 써야 하는데, PHP에서는 타입을 함수 인자로 지정해줄 방법이 없었습니다.

그리고 마침내, PHP의 한계와 정면으로 부딪칠 일이 생겼습니다.
바로 웹페이지가 아닌 것을 만들게 된 것이죠.
제가 당시 관심을 가졌던 것은 IRC 봇이었습니다.
IRC가 뭔지 잘 모를 분도 계시므로 간단히 설명하자면 채팅 프로그램입니다.
접속 여부를 검사하기 위해서 일정 시간마다 서버와 PING을 교환해야만 합니다.
하지만 PHP로 봇을 구현을 하자 그 부분을 구현할 방도가 없었습니다.
제가 사용자로부터 온 명령어 A를 10초동안 처리하는 동안 서버가 PING 교환 요청을 보내면 명령어 처리를 멈추고 PING부터 보내야 하는데, PHP로는 그게 안됬던 것이죠.
그리고 당시 저는 Windows를 쓰고 있었는데, PHP로 작성한 봇 구동을 위해서 브라우저상에 웹 페이지를 하나 띄워놔야만 한다는 점도 매우 성가신 부분이었습니다.

## 다른 언어와의 첫 만남

저는 이쯤에서 "다른 언어를 써볼까?"라는 생각을 하게 됩니다.
당시 저는 PHP만 했으므로 다른 언어에 대한 정보가 적었습니다.
당시 제 주변에는 Java, AutoIt, Python을 쓰는 사람들이 있었습니다.
그 중에서 제가 IRC 봇에 관심을 갖게 만든 인클봇이 Python으로 개발되어 있었다는 사실을 알게 되었죠.
그래서 Python을 써보기 시작합니다.
그 당시 Python은 최신이 2.5였던 것으로 기억하고 있습니다.

그 당시엔 문제 해결을 위해 Python을 익혀나가고는 있었지만, 오직 봇 개발을 위해서만 생각했습니다.
다른 언어를 쓰는 것은 처음이었기 때문에 너무나도 어색했죠.[^8]
그래서 당연히 Python으로 웹 개발을 해보겠다는 생각은 그 당시엔 해보지도 못했죠.
그보다는 Python으로 웹 개발이 가능하단 사실 자체를 몰랐다는게 맞는 것 같습니다.

## 염증과 불안을 느끼다

사실 Python을 처음 접했을때 그렇게까지 강한 매력은 느끼지 못했습니다.
저는 그 당시의 PHP 문화가 너무 익숙했기에 Python이 이질적으로 느껴진 것이죠.

전 웹 사이트를 만드는 것이 목적이었기 때문에 PHP 외에 JavaScript도 다뤘는데, 특히 Ajax에 관심이 많았습니다.
그 이후로 JavaScript로 프로그래밍이라는게 가능하다는 걸 알게 되고, DOM 관련 함수들이나 jQuery등을 알게 되었죠.

Python도 그러하지만 JavaScript 등으로 인해 여러가지 신문물을 맛보다보니 염증과 불안을 느끼게 되었습니다.

> "왜 PHP에는 Ajax 처럼 이렇다할 변화가 없는거지?"
> "왜 PHP에는 분명 불편한 부분들이 존재하는데 개선이 안 되는 거지?"

불만은 점점 쌓여만 갔고, PHP로 웹 게임도 운영해보고, 웹 에이전시 활동을 하면서 점차 PHP를 향한 모호한 형태의 불만이 더 커져만 갔습니다.
모호한 형태의 불만이라고 말한 것은, 제가 그 당시에는 다른 언어에서는 어떻게 하는지 잘 몰랐기 때문이죠.

## PHP 말고 다른 것으로도 웹 사이트를 만들 수 있다

사실 알고 있었습니다.
PHP 말고도 ASP나 JSP 같은게 있었으니까요.
그러다가 제가 왜 PHP로만 웹 개발을 했는지 알게 되었습니다.

<p style="font-size: 1.2em; font-weight: bold; text-align: center;">내가 쓸 수 있는 웹 호스팅이 지원하는 것이 PHP밖에 없었어!</p>

하지만 주변 개발자들은 다른 수단을 써서 여러가지 공부[^9]를 하는 것이 보이는데, 마냥 제자리 걸음인 제가 싫었습니다.

그래서 도피를 시작합니다.

<p style="font-size: 1.2em; font-weight: bold; text-align: center;">내가 지금은 PHP를 쓰지만, 다른 대안이 PHP만큼 익숙해지면 옮겨가야지!</p>

## Python을 하게 된 계기

그래서 본격적으로 다른 언어를 물색해보기로 했죠.
언어를 찾아 떠돌아다니는 여정을 하기로 했습니다.
맘에 드는 언어를 찾기 위해 떠나기 시작했죠.
마침 지인 중 한 명이 Python으로 웹 사이트를 만드는 예를 보여줬었는데 그것이 멋있어 보였기 때문에 일단 첫 시도로 Python을 선택합니다.

PHP를 버린 저를 공격하던 어느 분이 제게 Python을 선택할 때 그렇게까지(PHP를 관둘만큼의) 합리적인 이유가 있었냐고 물으셨었는데, 제가 Python을 고른 이유는 이런 식입니다.

1. 봇 만들때 써봤다. 좀 더 잘 다룰 수 있으면 재밌을 것 같다.
2. 주변에 Python을 쓰는 사람이 많다. 조언을 구하기 쉽다.
3. 다른 것을 알아보기 위해서 어떻게 해야하는지 잘 몰랐다.

이런 이유들입니다.
처음 언어를 살펴보는데에 합리적인 이유가 필요할까요?
저는 언어를 처음 선택해서 탐색할 때엔 그 사유가 꼭 합리적일 필요는 없다고 생각합니다.
언어는 도구에 불과하고, 도구 중에 선택지가 여럿 있어서 써보고 고를 수 있는 상황이라면 사소한 동기라도 그 언어를 즐기겠다는 생각이 더 중요하다고 생각하니까요.
오히려 합리적이어야 하는 것은 Python을 주력으로 삼은 이유인 것 같습니다.

하지만 이 결심 이후로 공백기가 좀 길었습니다.
집안 사정도 매우 안좋았고, 더구나 저도 입원을 해야할 만큼 건강이 안좋았으니까요.
그리고 실질적인 시작을 하게 된 것은 그리 길지 않습니다.

## Python 웹 개발

지금까지 쭉 줄글로 써서 꼭 선형적인 사건들을 말하고 있는 것 같지만, 사실은 위에 적은 이야기들은 동시다발적인 사건들입니다.
아래 나올 얘기들도 마찬가지지만요.
Python을 배울 때에는 2.5였지만 그 중간에 봇을 여러 번 갈아엎었고, 윗 단락에서 언급한 '공백기' 당시에 제가 썼던 Python 버전은 3.2로 기억합니다.

Python으로 웹 개발을 처음 접한 것은 Flask였습니다.
처음엔 가볍게 가위바위보 정도를 만들어봤었죠.
하지만 그것만으로도 상당히 신선한 경험이었다고 생각합니다.
당시의 저는 하나에 몰두하는 재미를 몰랐기 때문에 이것저것 찾아서 어슬렁 거리고 있었습니다.

그러다가 Software Maestro에서 Flask를 본격적으로 보기 시작했죠.

## 불만의 구체화

소마 당시에 했던 개발 프로젝트에서 제 PHP를 향한 불만들이 좀 더 명확하게, 형언 가능한 형태로 정리되기 시작했습니다.

1. 개발자마다 각기 다른 스타일로 개발했습니다.
2. MVC가 나뉘어지지 않은 코드가 많았습니다.
3. 함수나 class, type등을 개발자 맘대로 다룰 수 없었습니다.
4. 연산자 오버라이딩 등의 기능이 없습니다.
5. background 연산 등의 비동기적 task를 처리할 방법이 없었습니다.
6. 로컬에서 테스트 환경을 구성하기 어려웠습니다.
7. 유니코드가 존재하지 않았습니다.

생각해보면 더 있을 것 같지만 더 찾아도 의미가 없다고 생각하기에 이정도만 적습니다.

1, 2번은 사실 개발자, 개발 문화의 문제입니다.
그에 비해 Python은 보다 성숙한 문화를 가지고 있었고, 그에 따라 이미 갖춰진 것을 배웠으므로 고통이 덜합니다.
저는 이런 부분들을 보면서 PHP를 쓰는 사람들과 Python을 쓰는 사람들의 문화 중에서 **적어도 내 취향에는** Python이 더 맞다고 생각했습니다.

## 더 이상 PHP를 주력으로 쓰지 않는 이유

제가 Python을 처음 시작한 이유는 아마 저를 공격한 사람들이 기대(?)한 것 처럼 합리적이지는 못합니다.
하지만 제가 PHP를 다시 주력으로 쓰지 않으려는 이유는 제 개인적 포지션에서 볼 때, 합리적이라고 생각합니다.

### 저는 명시적이고, 개선 가능한 언어를 좋아합니다

PHP도 namespace가 생긴 뒤로 명시적인 편이 되긴 했지만 제가 원하는 기대(module 시스템)에는 이르지 못했습니다.
개선이라는 부분에서는 아직도 bytes만 존재하고 unicode를 직접 다룰 수 없는 부분 등에서 제 기대에 미치지 못합니다.
그 외에도 `in` 연산자를 도입하자는 RFC가 거절당하는 등의 사건을 보고 PHP 코어 개발자들이 뭘 하고 싶은지 모르게끔 만든 것 같네요.

그 외에도 PHP는 파서 레벨에서 매우 유연하지 못합니다.
확장성등의 면모에서 다른 언어들에 비해 불편합니다.
PHP 소스를 직접 고치면 될 지도 모르지만, 그러면 PHP의 장점인 널리 보급된 코어를 쓸 수가 없습니다.

### 저는 공부하고 발전하는 분위기를 좋아합니다

그런 면에서 기존 PHP 코드에 PSR-2 조차 적용하기 힘든 문화권[^10]과는 조합이 맞지 않습니다.
PSR-2도 안되는데 composer는 어떻게 도입하고, PSR-4는 어떻게 도입할까요.

PHP에 대한 글을 썼을때 받은 답변은 대부분 "PHP를 합리적으로 쓸 수 있다." 같은 체계적인 비판이 아니라 "글의 저자가 이상하다"는 식의 단순한 공격이었습니다.
제 생활 범위 내에 있는 것은 다 찾아서 읽어봤습니다만, 대부분 문장을 오해하고 하는 말들 뿐, 반박의 근거가 존재하지 않았죠.
저는 그렇게 무책임한 비난만 늘어놓고 싶진 않기 때문에 더더욱이 공부를 하는 분위기가 필요합니다.

### 저는 웹 외의 작업도 하고 싶습니다

저는 Python을 접한 뒤로 봇, Crawler, 웹 사이트, 데몬 등의 여러 개발을 해봤습니다.
그 결과 제 안에는 웹 외의 개발도 하고 싶다는 욕구가 있음을 알게 되었죠.
그리고 그런 구현에는 PHP로 멀리 돌아가는 것 보다는 Python으로 깔끔하게 처리하는 것이 더 낫다고 생각하게 되었습니다.
PHP로도 짤 수 있겠지만 PHP로 하는 것이 비효율적이라고 생각합니다.

더군다나, web의 요구사항이 PHP의 한계를 벗어나고 있습니다
Websocket 등의 새로 등장한 요구사항들은 PHP와 맞지 않다고 생각합니다.
물론 PHP로도 Websocket 서버를 구현할 수 있고 구현체도 존재하지만 좀 더 편한 방법이 존재하는데 괜히 심하게 돌아가는 느낌이라는 생각입니다.

### 제 자신을 PHP에 한정시키고 싶지 않습니다

그렇기에 PHP외에 다른 언어를 꾸준히 배우려고 생각하고 있습니다.
물론 이 생각은 Python에 대해서도 마찬가지 입니다.
저는 Python을 제가 만족할 만큼 잘 다루고 있다고는 생각하지 못합니다.
하지만 벌써부터 Python으로 처리하기 유리하지 않은 일이 있다는 점을 느끼고 있고[^11], 다른 언어를 배우는 것도 적극적으로 검토하고 있습니다.
실제로 최근엔 Ruby를 배우고 있기도 하구요.

### 아직 Modern PHP가 제 기대치만큼 Modern하지 않습니다

Modern PHP가 기존 PHP의 불편함을 인식하고는 있다고 생각하지만, 그 문제를 완전히 해소했다고 보기엔 무리가 많습니다.
저는 최종적으로는 PHP가 근본적으로 나은 언어가 되어야 한다고 생각하는데, PHP 코어 개발자들의 행동은 저로썬 납득이 안되는게 많습니다.
가령 저라면 PHP는 최종적으로 `strlen("item4")` 대신 `"item4"->length` 같은 방법도 쓸 수 있게 되어야 한다고 생각합니다.[^12]
하지만 그런 부분에 대해서는 전혀 논의조차 없는 것이 불편합니다.

### PHP를 쓰면 에너지 소모가 큽니다

위의 이야기를 총 정리한 결론인 것 같습니다.
제가 기대하는 작업을 하기에는 PHP를 쓰면 에너지 소모가 너무 큽니다.
Python 문화권에서 이미 쉽게할 수 있는 대책이 많이 존재합니다.
같은 작업을 해주는 것이 PHP에도 존재할 지 모르지만 오히려 학습비용이 더 큰 상황이 되었습니다.
개발을 혼자하는 것이 아니기 때문에 동료들도 새로 배우는 부분에 동의를 해줘야 하는 부분이구요.
PHP는 하나의 작업에 대한 것도 너무 구현체가 많거든요.
일일히 리서치를 해보는 것에 피로감을 느낍니다.
Python의 경우는 많이 쓰이는 부분은 PEP을 통해서 공통의 인터페이스를 정의하기 때문에 그런 부분이 덜하다고 생각합니다.[^13]

## 결론

저는 합리적인 이유를 떠나서도 PHP보다 Python의 여러 요소를 더 좋아합니다.
합리적인 이유를 찾으라고 하면 그것은 Python을 고른 이유라기보단 Python을 좋아하게 된 이유들입니다.
만약 제가 Python이 아니라 다른 언어를 접했더라면 또 다른 경험을 가지고 있었겠죠.

제가 지난 글에 "그것이 정말 PHP만의 장점입니까?" 라는 대목을 써놨었는데, 그 이유를 여기서 설명할까 합니다.
언어들은 각기 장점을 서로 공유합니다.
**PHP의 장점이 전무하진 않습니다만, 그것이 PHP만의 장점도 아니거니와 PHP만 고집할 이유는 안된다는 이야기** 였습니다.

Python도 마찬가지입니다.
Python의 장점을 다른 언어들도 공유합니다.
그리고 그것이 Python만 고집할 이유도 되지 않습니다.
그래서 필요에 따라 적합한 언어가 생기게 마련이죠.
하지만 저는 제 경험상 PHP보다 Python이 대부분 선택지의 앞에 놓게 되었고, 적어도 저는 PHP를 고를 일은 많지 않을 것 같습니다.

여러분이 PHP를 좋아하신다면 쓰시면 됩니다.
기존 스타일이 나쁜 방식이어도 그것으로 만족한다면 그냥 그대로 충분합니다.
하지만 그것을 싫어하는 사람이 있을 수 있음을 인정하지 못하면 그건 그냥 맹신입니다.
물론 PHP뿐만 아니라 Python, 그리고 그 어떤 언어도 마찬가지구요.

[^1]: 웹 페이지에 로그인 칸을 별도로 삽입하는 것을 그렇게 불렀었습니다.
[^2]: 당시에 자기 홈페이지를 만드는게 유행이었던 것 같습니다.
[^3]: 아직도 몇몇 BBS 솔루션에 남아있는 Signature 기능
[^4]: 당시에는 `placeholder` 속성이 없었습니다.
[^5]: Cross Site Scripting. 이 기법을 이용하면 경고 메시지 띄우기뿐만 아니라 비밀번호 강제 변경, 로그인 세션 탈취, 악성코드 다운로드 등의 클라이언트 공격이 가능합니다.
[^6]: 그 당시에는 지금은 쓰지 않는 `ereg` 계열 함수를 썼습니다.
[^7]: 프로시저 라는 단어가 더 정확할 것 같습니다. 함수형 프로그래밍에서 말하는 Pure function과는 거리가 멉니다.
[^8]: 물론, 당연히 JavaScript도 써봤습니다. 하지만 저는 그 당시에 JavaScript가 언어라는 사실을 인지하기에는 JavaScript를 거의 안썼습니다.
[^9]: Windows application을 만든다던가, 웹 사이트에 자동으로 글을 올리는 봇을 만든다던가 하는 것.
[^10]: 모든 PHP개발자가 그렇다는것은 절대 아닙니다.
[^11]: Python 2/3이 갈라져있는 현 상황, 비동기적 이슈에 대한 대응 방식 등
[^12]: Python에서 안되는 기능 아니냐고 하실텐데, Python의 `len` 함수는 내부적으로 주어진 인자의 `.__len__()` 함수를 실행하는 방식입니다.
[^13]: 물론 [PSR-6](http://www.php-fig.org/psr/psr-6/)등의 논의가 있는 것은 알고 있습니다. 하지만 존재하는 것과 널리 쓰이는 것은 다르다고 생각합니다.


제가 PHP를 버리고 Python으로 옮긴 이유와 과정을 설명합니다.

내가 PHP를 버리고 Python으로 옮긴 이유


<blockquote class="twitter-tweet" data-lang="ko"><p lang="ko" dir="ltr">오늘 하루 종일 PHP에 대한 글을 쓴 것으로 비난을 받고 나서 생각해보니 역시 이 피로감의 원인은 SNS인 것 같다. Facebook에서 욕먹고, Disqus에 악플이 달리니까 머리도 아프고 피곤하다.</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702209660070146048">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">그에 비하면 트위터는 매우 평화로운데, 아마 내 글을 보고 기분 나빴더 사람이라면 나한테 벽돌을 던졌을 것이다. 혹시라도 내게 욕을 해왔다면 반대로 내가 벽돌을 던졌을 것이다. 소통을 하지 않음으로써 문제가 해결되는 아이러니함이 발생하고 있다.</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702210032293670912">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">이러한 점을 보면 SNS Tiredness로 인해서 FB는 유저를 유지하기 힘들지 않을까 싶다. FB는 아는 사람 중심으로 뭉쳐있고, 실명과 사진을 노출하고(난 안했지만) 하는 대화에서 노골적인 갈등이 드러나도 다른 지인때문에 쉽사리 버릴 수 없다.</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702210859615977472">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">하지만 트위터를 구독계처럼 사용한다면 내가 좋아하는 동물 짤방, 유머 짤방 같은것만 24시간 보면서 리트윗해도 뭐라고 할 사람이 없다. FB가 인터렉션으로 지침을 유발한다면 트위터는 그런 부담이 전혀 없는 것.</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702211157759688705">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">이 이야기를 하고나니 IRC에서 이런 이야기를 들었다.<br><br>&lt;M*&gt; &quot;트위터, 빠른 시일 내에 타임라인에 알고리즘 도입하기로&quot;<br><br>빨리 트위터처럼 잉여잉여 덕질덕질하기 좋은 대안 웹사이트가 나와야..</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702215356186624000">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">농담은 여기까지 하고, 나는 fb에 이미 지칠데로 지쳤지만 아직도 버리지 못하는데, fb으로만 연락이 가능한 사람들과의 관계를 대체할 방법이 없기 때문이다. 그 사람들이 트위터로 와주면 문제가 해결될지도 모르지만 그럴 일은 없을 것 같고 (...)</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702219349080182784">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">내가 취할 수 있는 최적의 솔루션은 fb에선 fb로만 연락 가능할 사람들과만 연락하고 fb를 쓰지 않는 것이다. 맨 첫 트윗에서 언급된 disqus는 그런 의미에서 최악의 SNS다. 조만간 작별을 고해야할 듯.</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702219952527290368">2016년 2월 23일</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="ko"><p lang="ko" dir="ltr">내가 이해할 수 없는 점은 tw가 fb의 로직을 부러워한다는 것인데, 유저 수가 많은 것이 fb의 그런 부분 때문이라고 &#39;착각&#39;하고 있는 것 같다. 자기 장점을 제대로 모르는 tw의 모습이 아쉽다. 이러다 정말 <a href="https://twitter.com/hashtag/PrayForTwitter?src=hash">#PrayForTwitter</a> 가 현실로;</p>&mdash; item4 (@item4) <a href="https://twitter.com/item4/status/702220796761022464">2016년 2월 23일</a></blockquote>


페이스북과 트위터에 대한 짧은 생각

페이스북과 트위터


![언어의 부적절성 by @Hwangwon_Juliet CC-BY](php.png)

저는 PHP를 싫어하는 편에 속하는 개발자입니다.
보통 `PHP를 싫어하는 개발자`라고 하면 `PHP를 옹호하는 개발자`분들은 "PHP를 비난함으로써 자신이 좀 더 우월한 존재라고 어필"하려고 한다던가, "자신이 쓰는 언어의 우월함을 과시"하려고 한다고 생각하죠.
심지어는 "니까짓게 PHP를 알아?"라고 생각하는 사람도 있겠죠.

저는 2011년 정도까지 PHP를 주력 언어로 썼던 개발자입니다.
첫 입문 언어도 PHP 였습니다.
한국 PHP 문화에 큰 영향을 끼친 Zeroboard 4에도 몇 차례 보안 패치를 내놓은 적이 있습니다.
갈아타고 나서도 [PHP 7의 신기능](/2015-10-30/A-Short-Postscript-about-Using-PHP-7.0rc6.html)을 미리 접해보기도 했었고 [PHP를 보다 잘 써보고자 하는 사람들의 페이스북 그룹](https://www.facebook.com/groups/655071604594451/)에서도 활동하고 있습니다.

그래도 전 PHP의 호불호 문제에서는 PHP를 싫어한다고 자신있게 말합니다.
저는 이 글을 통해서 제가 **왜** PHP를 싫어한다고 말하고 다니는지 말해보고자 합니다.

## 잘못 끼운 첫 단추

이미 PHP 안티들의 성서쯤의 위치에 자리잡혀버린 [PHP: 잘못된 디자인의 프랙탈](http://noraesae.github.io/PHP-a-fractal-of-bad-design-kr/)[(원문)](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)에서 이미 잘 설명하고 있습니다.
제가 더 길게 쓰지 않아도 저 글이 이미 PHP 자체의 문제점은 많이 지적하고 있습니다.

그런데, PHP는 왜 이렇게 이상해졌을까요?
저는 PHP가 첫 단추를 잘못 끼웠다고 생각합니다.
PHP의 창시자는 [Rasmus Lerdorf](https://en.wikipedia.org/wiki/Rasmus_Lerdorf)라는 사람입니다.
이 사람이 이제까지 해왔던 어록을 짚어보면 PHP의 이상함의 근원을 알 수 있습니다.

> I actually hate programming, but I love solving problems.[^1]

> 저는 정말로 프로그래밍을 싫어해요. 하지만 문제를 처리하는 것은 좋아하죠.

이 사람은 처음부터 프로그래밍에 관심이 없었습니다.
프로그램을 만든다기보다는 문제 해결을 위한 코드 뭉치가 필요했다는 말이 정확할 것 같습니다.
그 결과 이렇게 됩니다.

> I really don't like programming.
> I built this tool to program less so that I could just reuse code.[^2]

> 저는 정말로 프로그래밍을 싫어해요.
> 저는 코드를 다시 써서 프로그래밍을 덜 하게 만들기 위해 이 툴을 만들었어요.

코드를 다시 쓰는 것, 즉 코드의 재활용이 뭐가 나쁘냐고 말할 수 있을거라 봅니다.
하지만 그 결과가 PHP에 전역적으로 배치된 천여개[^8]의 내장 함수입니다.
정말 다 필요한가요?

이 사람에게 필요했던 것은 자신의 문제를 처리해줄 프로그램이지, 프로그래밍을 할 도구를 만드는 것이 아니었습니다.
프로그래밍을 할 도구, 언어 개발자로써의 그는 어떨까요?

> I was really, really bad at writing parsers.
> I still am really bad at writing parsers.[^3]

> 저는 예전에 정말 파서를 잘 못만들었어요.
> 그리고 지금도 저는 파서를 잘 못만들어요.

그는 PHP 파서를 잘 못만든다고 합니다.
다행히도 지금은 그의 말대로[^4] PHP를 그가 혼자서 만들진 않습니다.
PHP 7에선 AST도 도입되었죠.
하지만 그는 PHP라는 문제 해결에 있어서 파서를 **막** 만들었습니다.

> I'm not a real programmer.
> I throw together things until it works then I move on.
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that."
> I’ll just restart Apache every 10 requests.[^5]

> 저는 진짜 프로그래머가 아니에요.
> 다 던져두고 돌아가게 되면 그때 행동해요.
> 진짜 프로그래머들은 말하죠. "그래, 돌아는 가, 하지만 당신 코드는 산지사방에서 메모리가 새고 있어. 어쩌면 우리가 그걸 고칠 수 있을지도 몰라"
> 저는 그냥 Apache를 요청 10회마다 재시작할 뿐이에요.

그리고 그 결과물이 PHP의 시작입니다.

> I've never thought of PHP as more than a simple tool to solve problems.[^6]

> 저는 PHP보다 문제 해결에 있어 심플한 툴을 상상할 수 없어요.

이 외에도 Rasmus Lerdorf의 **이상한** 발언은 수도 없이 많지만[^7] 더 파해칠 필요는 없다고 생각합니다.
이미 이만큼 봤으면 충분히 PHP의 시작이 잘못 되었음을 알 수 있으니까요.

## 계속, 더욱 더 심하게 잘못 흘러간다

사실 Rasmus가 첫 단추를 끼워나가기 시작한 건 사실이지만, 그는 이제 더 이상 PHP의 중요한 결정에 영향력이 없습니다.[^9]
하지만 더 심각한 문제는 그 이후로도 한동안[^10] PHP가 갈수록 더욱 더 괴악해졌다는 점입니다.

대표적인 예로 [register_globals](http://stackoverflow.com/questions/3593210/what-are-register-globals-in-php)이 있습니다.
간단히 말하자면 외부에서 오는 입력을 모두 전역변수로 풀어놔버리는 것인데, 초기화 되지 않은 변수여도 모두 덮어씁니다.
현재까지도 PHP 소스의 보안을 날려버리는 최악의 선택 중 하나로 꼽힙니다.

하지만 이 기능으로 인해 SQL Injection 위험성이 있자 PHP 진영은 [Magic Quote](http://php.net/manual/en/security.magicquotes.php)라는 더 이상한 솔루션을 붙여놨습니다.
외부에서 들어오는 모든 값에서 SQL과 연관이 있어보이는 `"`, `'`, `\`를 escape하는 것이죠.
하지만 이것만으로 모든 이슈가 해결되지도 않거니와, 모든 외부 변수가 escape가 되어있는 관계로 순수하게 변수값이 필요한 상태라면 다시 escape를 풀어야 하는 상황에 놓입니다.

저는 이 기능들이 왜 PHP 5.4까지 살아남았는지 이해할 수 없습니다.

이 글을 읽고 오해하신 분들을 위해 별첨하자면 PHP의 이상한 방식은 이것 하나만은 아닙니다.
아래서 보충설명하지만 저는 PHP의 나쁨에 대한 백과사전을 저술중인 것이 아니므로 가장 대표적인 예를 든 것에 불과합니다.

## 안 고쳐지더라

PHP의 문제점은 이미 많은 사람들이 지적해왔습니다.
하지만 커뮤니티는 비판을 수용하지 않아왔습니다.
대표적인 사례가 [수호신](https://suhosin.org/stories/index.html)이 있습니다. (이름은 한글이지만 독일 프로그래머가 개발했습니다.)
언어 레벨의 보안 이슈를 해결하기 위해서 PHP를 확장하는 extension이 개발되었습니다.
왜 이래야 했을까요?
PHP 코어 진영에서 패치를 보내도 받아주지 않았기 때문입니다.

이상한 사례는 또 있습니다.
PHP의 `mt_rand`는 출시 이후로 줄곧 고장난 상태였습니다.
함수명 앞에 들어있는 mt는 Mersenne Twister를 의미하는데, twist 구현이 올바르지 않은 상태였죠.
이건 엄연한 버그이고, 즉각 수정되어야하는 부분이었지만 [PHP 진영은 이 패치를 Revert해버립니다.](https://github.com/php/php-src/commit/a0724d30817600540946b41e40f4cfc2a0c30f80)
이유는 API Breaking이 생긴다는거였죠.
버그를 breaking이라고 부르는데 어떻게 받아들여야할지 모르겠습니다.

## 잘못된 학습과 나쁜 버릇의 고착

문제는 여기서 끝나지 않습니다.
PHP로 프로그래밍을 하는 개발자들은 대부분 **PHP로 개발을 하면 이렇게 하는거구나**라고 생각을 하고 그 당시의 PHP를 익혔습니다.
그리고 그것을 대다수의 개발자가 그대로 이어오고 있습니다.

가령, 위에서 언급한 `register_globals`는 PHP 5.4에서 사라졌습니다.
그러자 변경점을 적용하지 않으려던 개발자들이 취한 선택은 두 가지로 나뉩니다.
5.3 이상으로 올리지 않거나, `register_globals`와 똑같은 동작을 재현한 겁니다.

```php
<?php
extract($_GET);
extract($_POST);
extract($_COOKIE);

```

보안상 안좋아서 막아버린 기능을 구태여 다시 재현하여 개발을 합니다.
그 결과 보안적으로 전혀 나아지지 않습니다.
정상적인 해법을 배우지 않고 이런 식으로 우회적인 꼼수만 늘려갑니다.
PHP 문화권 중에서 예전 코드를 **변경 없이** 다시 쓰려는 사람들에게는 이미 저 분위기가 지배적입니다.

## 원인

저는 원인이 두 가지 있다고 생각합니다.
하나는 PHP로 작성된 코드를 (위험성을 알건 모르건) 다시 바꿀 생각이 없는 **생산품의 주인**들입니다.
이미 잘 돌아가는 것**처럼** 보이므로 딱히 서버의 PHP 버전을 올린다던가 해서 문제를 더 만들고 싶지 않습니다.
따라서 그냥 방치합니다.

또 하나는 PHP로 작성된 코드를 (위험성을 알건 모르건) 다시 바꿀 생각이 없는 **생산품의 생산자**들입니다.
문제가 있다는 것을 알지도 못할 정도로 소식통이 막힌 개발자도 실존하리라 봅니다.
문제가 있다는 것을 알고도 그냥 방치하는 개발자도 많습니다.
왜냐, 학습은 비용이 들고(굳이 돈이 아니더라도 시간, 정신력 등), 자신은 그것보단 다른 것(상품을 더 만들어서 파는 것 등)에 몰두하고 싶기 때문이죠.
그래서 더 이상의 개선의 여지가 없어져버립니다.

## 생존 전략

이게 싫은 개발자들은 크게 두 가지 행동을 취했습니다.

### 첫째. PHP를 잘 써보기로 합니다.

[PHP: The Right Way](http://www.phptherightway.com/)와 [Modern PHP](http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=68414290)로 대표되는 움직임입니다.
PHP가 _과거에_ 이상했던 부분이 워낙 많았지만 그래도 조금씩이라도 더 나은 부분을 만들고자 하므로, 나쁜 버릇은 버리고 깔끔하게 새로 시작하자는 것입니다.
하지만 이미 과거의 유산들이 너무 비대하고, 그 문화가 팽배하기 때문에 새 문화를 위한 투자를 이해하지 못하는 사람들이 많아서 아쉽게도 확산은 더딘 편입니다.

### 둘째. PHP를 버리기로 합니다.

[언어 커뮤니티의 문제](http://blog.dahlia.kr/post/21044381028)를 인지하고는 그냥 그 언어로부터 탈출을 감행합니다.
웹 개발에 쓸 수 있는 언어는 이미 PHP 외에도 Python, Ruby, Node.js, ASP.NET 등 선택지가 다양합니다.
이미 탈출이 불가능한게 아니라는 것이죠.
이 사람들은 이미 PHP에 데여봤으므로 PHP를 혐오하는 발언을 하기도 합니다.
그리고 이 사람들이 PHP를 싫어하는 모습을 보고 PHP를 실제로 해보지는 않았지만 PHP를 싫어하는 사람이 생기는 것 또한 사실입니다.

## PHP는, PHP 개발자는 어떻게 해야 하는가

현재 PHP는 무서울 정도로 널리 보급되어 있습니다.
PHP가 세팅 안 된 서버를 찾기 힘들고, PHP와 궁합이 잘 맞는 MySQL이 없는 서버 또한 찾기 힘들기 때문에 PHP의 범용성은 극히 최강이라고 할 수 있습니다.
또한, 파일단위로 구성되기 때문에 매 배포마다 서버를 재실행해야한다던가 하는 부담이 없기 때문에 호스팅 사업을 하기에도 용이하죠.
하지만 그 이면에는 사용자의 레거시 코드로 인해 서버들이 PHP 버전을 올리지 못하고, 그로 인해 보안 문제가 발생되는 시궁창 같은 상황도 연출되고 있죠.

이미 인프라가 준비되어있는 PHP를 그냥 버리라고는 말하기 힘듭니다.
하지만 기존처럼 쓰면 한계가 올 것입니다.
당장에 PHP 7에서 `mysql_`로 시작하는 모든 함수가 삭제되었습니다.
PHP 구버전의 보안 패치가 중단됨을 감안하면 이런 옛 버릇을 버리고 새로운 문화를 배우던가, 아니면 PHP를 과감히 버리고 다른 곳으로 옮겨야 한다고 생각합니다.

저는 PHP를 잘 써보려고 나름대로 엄청 고민하다가 PHP를 버리는 쪽을 택했고, 언어를 찾다보니 Python을 택했습니다.
Rasmus Lerdorf가 좋아한다던 문제 해결을 Python으로도 많이 해봤고, PHP만 하던 시절보다 더 많은 것을 배웠습니다.
웹 개발자로 먹고 살다보면 PHP를 아예 버리는 것은 불가능한게 현실이지만, 적어도 저 자신을 위한 개발에서는 PHP는 쓰지 않을 것 같습니다.
PHP 옹호론자분들이 말씀하시는 "장점"이라는 부분 중에서 제가 공감할 수 있는 것은 이젠 **쉬운 배포** 말곤 단 하나도 남지 않았습니다.
나머지는 제 상황에선 다른 언어를 쓰는것이 PHP를 쓰는 것보다 명확하고 깔끔한 솔루션이라고 생각하니까요.

하지만 PHP를 잘 쓰는 방법도 나쁘지 않다고 생각합니다.
PHP에 대한 Needs는 사라지지 않을 것이고, 앞으로도 굳이 써야한다면 최대한 Modern하게 쓰는 것이 좋겠죠.
PHP를 새 트렌드에 맞춰 제대로 써보고 싶으신 분들께는 [페이스북의 Modern PHP User Group](https://www.facebook.com/groups/655071604594451/)을 추천드립니다.
국내에서 가장 활발하게 PHP의 Modernization을 논의하는 곳입니다.

PHP를 버리건 계속 쓰건, 어느 쪽이 되었건 공부는 해야합니다.
개발자에게 있어서 공부는 숙명이나 다름 없다고 생각합니다.
공부를 안하고, 문화권의 상태와 공존을 고려하지 않는 개발자라면 PHP가 아니라 다른 언어를 쓰더라도 나쁜 코드를 만들고 있을 것입니다.

이 글을 읽고 "아냐, 그래도 나쁘게 쓴 PHP도 좋아" 내지는 "너는 그냥 니 언어를 추천하고 싶을 뿐이잖아" 라는 이야기를 하며 PHP를 옹호하는 발언을 하려는 분에게 감히 여쭙겠습니다.
PHP를 옹호하는 이유가 정말 합리적이고, 그것이 PHP만의 강점이 맞나요?

## 답변들

문맥을 오해하시는 분들을 위해 답변 벌첨을 달게 되었습니다.
마지막 문단에 수정사항이 있는데, 제 게시물은 언제나 GitHub에서 확인이 가능하므로 Diff를 직접 보시면 될 것 같네요.
스크린샷을 사용했었으나 인신공격으로 보여질 것 같아서 그냥 모두 내립니다.

### 1. PHP를 나쁘게 만드는 사람

제가 zb4에 보안 패치를 보낸 것이 나쁜 일이었다고 하면 나쁠 수도 있겠습니다만 zb4는 제 프로덕션이 아닙니다.

제가 왜 PHP를 나쁘게 만들었다고 생각하시나요?
제가 뭘 해야 PHP를 좋게 만든 사람이라고 평가를 받을 수 있나요?

### 2. extract를 쓰는 사람이 이상하다

개발하면서 extract를 못보신 분은 좋은 환경에서 개발하신 겁니다.
저는 올해도 외주하다가 저런 코드를 봤습니다.
제가 그렇게 만든 것도 아니고, 제가 그걸 변경할 권한도 없었습니다.
그런 걸 볼때마다 PHP를 잘 써보려고 노력했던 사람으로써 얼마나 비참한지 아십니까?

### 3. Python 우월주의에 빠져있다

제가 막 Python의 강점을 글에 내세우며 PHP는 나쁘다는 전개를 했더라면 Python 우월주의자라는 말을 들을 순 있다고 생각합니다.
하지만 저는 그냥 Python으로 옮겨갔다고만 적었을 뿐입니다.
제가 만약 Ruby나 Node.js를 적어놨다면 그때는 뭐라고 하셨을까요?
언어는 우월감에 쓰는 것이 아니라고 생각합니다.

### 4. 근거 빈약

글이 너무 장황해지고 본 목적을 잃어버리니까 대표적인 예를 들어서 적었을 뿐입니다.
PHP를 나쁘게 언급하려면 PHP의 나쁨에 대한 백과사전을 저술해야합니까?
PHP의 나쁨이 `register_globals` 단 하나일 리 없지 않습니까.

### 5. Python을 고른 합리적인 이유

**지면이 부족합니다.**
본 글의 취지에서도 한참 멀리 갑니다.
이 부분에 대해선 여러분의 열화와 같은 성원에 힘입어 **새 글**로 쓰겠습니다.
지금 이 논제로 계속 말싸움이 생기고 있는 상대방이 몇 분 계신데, 제 블로그의 컨텐츠로써 자료를 어떤 식으로 처리할지를 결정하는건 접니다.

### 6. 일이 커지는 걸 즐기고 있다?

첫째, 저는 글을 퍼나르지 않았습니다.
제가 직접 제 글을 인용한 곳은 제 개인 Facebook/Twitter 뿐입니다.
나머지 유포되는 것은 이 글에 공감하거나, 혹은 이 글을 조리돌림 하고 싶으신 분들이 퍼다 나른 것이겠죠.
Modern PHP 그룹에도 어느 분께서 "바퀴벌레", "살충제" 같은 단어를 써서 인용해가셔서 말싸움이 났고, 그걸 PHP School에도 어느 분이 퍼가셔서 저를 비난했죠.
전혀 생산적이지 못한 감정싸움인지라 하나도 즐겁지 않습니다.

그리고 저는 "사실이 아니거나 잘못된 정보"로 제가 비난당하는 것을 싫어합니다.
사실관계는 명확히 했으면 합니다.

### 7. Rasmus를 비난할 자격

제가 Rasmus보다 뛰어난 프로그래머인지 아닌진 모릅니다.
제가 Rasmus보다 못한 사람이라 해서 제가 제 의견을 피력하면 안 되는 것 또한 아닙니다.

저는 Rasmus의 발언들을 PHP의 첫 단추를 잘못 끼운 사람으로써 언급했습니다.
그리고 저는 Rasmus의 사상이 이상하다고 생각했던 것이죠.
Rasmus의 사상에 공감하시는 분이 계시다면 제가 기분 나쁠 수는 있겠지만, PHP와 Rasmus 어록에서 찾을 수 있는 그의 사상은 이제는 무관해져야 한다고 생각합니다.

[^1]: http://www.sitepoint.com/phps-creator-rasmus-lerdorf/5/
[^2]: http://web.archive.org/web/20130729213507id_/http://itc.conversationsnetwork.org/shows/detail58.html
[^3]: http://web.archive.org/web/20130729204354id_/http://itc.conversationsnetwork.org/shows/detail3298.html
[^4]: [I did not develop the PHP we know today. Dozens, if not hundreds of people, developed PHP. I was simply the first developer.](http://www.sitepoint.com/phps-creator-rasmus-lerdorf/)
[^5]: http://web.archive.org/web/20130729204354id_/http://itc.conversationsnetwork.org/shows/detail3298.html
[^6]: https://twitter.com/rasmus/status/1938080214814720
[^7]: https://en.wikiquote.org/wiki/Rasmus_Lerdorf
[^8]: 수천여개라고 적었다가 만개에 육박하는 듯이 보이는 듯 해서 정정합니다. 제가 PHP를 한창 배울때 보통 책들이 소개하는 PHP 함수 갯수가 2,000여개 정도 있었습니다. 하지만 저라면 저쯤 되면 모두 함수로 만드는 것이 아닌 다른 대안을 생각해봤을 것 같네요.
[^9]: Facebook에서 [Moon Kyong](https://www.facebook.com/moon.kyong.1)님께서 오해의 소지가 있다고 하셔서 문단을 수정했습니다.
[^10]: 한때의 이야기입니다. 전체적인 흐름상으로는 PHP는 나아지고 있습니다.


PHP의 이상한 문화에 대한 개인적인 생각

PHP의 이상한 문화


tl;dr: [read this answer.](http://askubuntu.com/a/708233/508021)

간만에 홈서버에 SSH로 접속하자 Ubuntu 15.10으로 업데이트를 권하더군요.
저는 가벼운 마음으로 업데이트를 실행했습니다.
그리고 이런저런 트러블슈팅을 해야했죠.[^1]
그중에 가장 끔찍했던 것이 바로 Samba, 파일 공유 서버입니다.

## Samba?

Samba는 linux와 다른 운영체제간에 파일 공유를 할 수 있게 해주는 서버입니다.
Windows의 폴더 공유의 확장판 같은 느낌이죠.

## 재시작 명령어부터 남달랐다.

Ubuntu 15.04 이후로 대부분의 서버 데몬들은 systemd에 기반해서 이런 식으로 재시작이 가능합니다.

```bash
sudo systemctl restart nginx
```

하지만 samba는 남달랐습니다.
samba를 재시작 하시려면 이렇게 하셔야 합니다.

```bash
sudo /etc/init.d/samba restart
```

아무래도 아직 upstart를 사용하는 모양입니다.

## Console로 Samba 테스트하기

하지만 samba를 아무리 재설치하고 재실행해도 제 맥북에서 접속이 안되더군요.
이게 samba의 문제인지, ubuntu의 문제인지 진단이 필요했습니다.
그래서, ubuntu에 samba 클라이언트를 설치해보기로 했습니다.

```bash
sudo apt-get install smbclient
```

왜 `samba-client`가 아닌지는 저도 모릅니다.

서버에 어떤 것들이 띄워져 있는지는 이렇게 확인 가능합니다

```bash
smbclient -L localhost -U item4
```

여기서 item4 자리에 자신의 user를 넣으면 됩니다.

서버에 접속은 이렇게 합니다

```bash
smbclient //localhost/myshare -U item4
```

여기서 myshare 자리에 자신의 공유 이름을 넣으면 됩니다.
(smb.cnf를 참조하세요.)

그런데, 아무리 해도 `NT_STATUS_ACCESS_DENIED` 라는 에러가 나왔습니다.

## 유저가 없나?

가장 먼저 해본 의심은 **설정 미스** 아닐까 싶어서 samba를 지웠다 깔았다를 여러번 반복해보며 실험했습니다.
하지만 전혀 나아지지 않더군요.

그래서 실험하다가 실수로 비밀번호를 **오타**를 냈는데, 아니 이게 뭡니까?
**동일한 에러**가 나오더군요.
그래서 유저가 없나 싶어서 유저를 다시 만들었습니다.

```bash
sudo smbpasswd -a item4
sudo smbpasswd -e item4
```

하지만 유저가 있음에도, 비밀번호가 맞건 틀리건 에러는 같았습니다.
사태는 점점 더 미궁속으로 빠져듭니다.

## 기승전검색

그래서 이젠 검색을 열심히 해봤습니다.
커뮤니티에서 여러가지 문답들이 오갔었는데, 나오는 솔루션은 다 시도해봤습니다.
그래도 안되더군요.
그래서 자포자기모드로 Ask Ubuntu에서 추천을 못받은 질문들을 읽어보기 시작했습니다.

[그리고 이 답변을 만났습니다.](http://askubuntu.com/a/708233/508021)
답변 내용은 간단했습니다. hostname이 15자가 넘으면 안된다는 것이었죠.
15자라는 말을 보자 떠오른 게 있었습니다.
`smbclient -L localhost -U item4`의 결과였죠

```bash
smbclient -L localhost/hdd1 -U item4
```

```
Enter item4's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.17-Ubuntu]

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       IPC Service (item4-homeserver server (Samba, Ubuntu))
	****            Disk      ****
	print$          Disk      Printer Drivers
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.17-Ubuntu]

	Server               Comment
	---------            -------
	ITEM4-HOMESERVE      item4-homeserver server (Samba, Ubuntu)

	Workgroup            Master
	---------            -------
	WORKGROUP
```

제 hostname은 `item4-homeserver` 입니다.
16글자이죠.
그리고 서버목록엔 R이 짤려있습니다.
그래서 바로 솔루션에서 제안하는 것 처럼 `[global]` 섹션 아래다가 `netbios name = item4-homesv` 라고, 15자 미만으로 적어보았습니다.

```bash
smbclient -L //localhost/hdd1 -U item4
```

```
Enter item4's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.17-Ubuntu]

   Sharename       Type      Comment
   ---------       ----      -------
   print$          Disk      Printer Drivers
   ****            Disk      ****
   IPC$            IPC       IPC Service (item4-homeserver server (Samba, Ubuntu))
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.17-Ubuntu]

   Server               Comment
   ---------            -------
   ITEM4-HOMESV         item4-homeserver server (Samba, Ubuntu)

   Workgroup            Master
   ---------            -------
   WORKGROUP            ITEM4-HOMESV
```

차이점이 보이시나요? `WORKGROUP`에 매칭된 Master가 없었는데 새로 생겨났습니다.

## 예상

아무래도 samba 내부적으로 `Server`를 생성할 때는 15자로 자르는 데, Workgroup에 Master짝을 찾을 때는 hostname을 fullname으로 찾아서 대조를 하니 없는 것을 버리는 것 같습니다.
하지만 이 사실은 [공식 문서의 설정 파트](https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html)에도, [문제 상황시 체크 리스트](https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/diagnosis.html)에도 없습니다.
저 답변이 없었으면 저는 ubuntu 업데이트가 꼬였다고 생각하고 ubuntu를 재설치하고 있었겠네요.
이 이슈를 공유하고 싶지만, Samba팀은 bugzilla만 운영하는데 저기까지 가서 뭘 하자니 밤 늦게까지 삽질을 해서인지 너무 지쳐서 포기했습니다.[^2]

## 후기

마음같아선 Samba를 버리고 이사를 가고 싶지만 딱히 대안이 없는 관계로 참고 있습니다.

## 참고사항

- [GitHub 이슈를 통해 Windows의 넷바이오스로 인해 길이 제한이 있을것이라는 제보를 받았습니다.](https://github.com/item4/item4.github.io/issues/1/)

[^1]: nginx의 `site-availabe/default`가 바뀌어서 tt-rss가 먹통이 되었다던가 하는 점.
[^2]: (아마도)Perl CGI로 된 소스를 아직까지도 돌리고 있는 곳에 가입까지 해야한다는 점에서 의욕이 더 추락했습니다.


Samba를 세팅하다가 NT_STATUS_ACCESS_DENIED 에러를 조우했던 이야기

Samba와 NT_STATUS_ACCESS_DENIED


**※ 카드 결제 관련해서 본문에 중요한 변경사항이 많습니다. (2016년 2월 21일 수정)**

이니시스사에서 제공하는 Inipay를 모바일 웹에서 사용할 수 있도록 연동하는 작업을 했는데, 공식 문서라고 할만한게 **사실상 아예 없는지라** 기록을 위해서라도 삽질 기록을 남겨놓습니다.

## 중요 상수 & 변수

여기 나열된 변수명은 실제 변수명과 일치한다는 보장은 없습니다.
자주 쓰이는 네이밍 정도로 이해하시면 될 것 같습니다.

### `MID`

`Market ID` 입니다.
상점마다 고유값이 발급됩니다.
테스트중일 땐 `INIpayTest`로 지정하면 됩니다.

### `OID`

`Order ID` 입니다.
각 주문마다 고유하게(unique하게) 직접 발급해주셔야 합니다.
보통 timestamp[^1]이나 고유성이 보장 안 된 랜덤값을 사용하는데, 방문자 수가 많은 곳이라면 피하는게 좋습니다.

### `TID`

`Transaction ID` 입니다.
각 결제 진행마다 고유하게 발급됩니다.
환불 프로세스를 구성해야한다면 DB에 저장해야할 것으로 보입니다.

### `P_AMT`

가격을 담는 변수입니다.
당연하지만 정수로 적어야 합니다.

### `P_NEXT_URL`

결제창이 끝난 후 이동할 페이지의 URL입니다.
실험해보진 않았으나 전체 경로를 적어야할 것으로 보입니다.

### `P_NOTI_URL`

카드 결제 진행시 결과를 저장할 때 쓰이는 URL입니다.
실험해보진 않았으나 전체 경로를 적어야할 것으로 보입니다.

### `P_RETURN_URL`

카드 결제 진행 완료시 넘어가는 페이지입니다.
아무런 정보도 받을 수 없는 페이지 입니다.
실험해보진 않았으나 전체 경로를 적어야할 것으로 보입니다.

## HTML 소스

[https://www.inicis.com/smartphone/iphone/INIpayMobile_Sample.html](https://www.inicis.com/smartphone/iphone/INIpayMobile_Sample.html)의 소스를 열어봅시다.
주소만 봐서는 iPhone용인데, 해본 결과 그냥 다 됩니다.[^2]

이 소스를 가져다가 여러분의 결제 신청 폼에 맞게 개조하시면 됩니다.[^3]
단, 다른건 다 바꿔도 `<form>`태그는 있어야하고, `<input>` 태그들에서 `name` 속성은 바꾸시면 안됩니다.
결제 창을 폼 전송을 통해 띄우기 때문입니다.

여기서 꼭 설정해야하는 값들은 `<input>` 태그 형태로 생성되어있는, 위에서 이미 언급한 변수들입니다.

## 카드 결제 결과 저장

카드결제를 진행하고 난 뒤에 이니시스측에서 상점 홈페이지쪽으로 정말 정상적으로 결제가 진행됬는지 확인 PING을 보냅니다.
해당 부분은 `OK` 또는 `FAIL`을 보내줘야 서버가 인식하고 거래를 처리합니다.
그 외의 값이 출력되면 일정 시간 후에 다시 PING이 옵니다.

[이 부분의 소스 예제는 이니시스측에서 JSP, ASP, PHP로 제공하고 있습니다.](https://www.inicis.com/blog/archives/15036)
소스를 받아서 열어보면 WEB 방식엔 필요 없다고 하는데, 카드 결제에는 무조건 필요합니다.

또 하나 주의할 점은 넘어오는 정보는 `euc-kr`로 인코딩 되어 있습니다.
utf-8 환경에서는 변경해서 사용해야합니다.

```python
# 예시로 Flask를 사용합니다.
from flask import redirect, request, url_for


# P_NOTI_URL
@app.route('/shop/noti/', methods=['POST'])
def noti():
    ip = request.remote_addr
    if ip in ('211.219.96.165', '118.129.210.25'):
        p_status = request.form['P_STATUS']
        if request.form['P_TYPE'] == 'vbank':
            if p_status != '02':
                return 'OK'
        else:
            # 존재하는 상품이 맞다면
            if is_correct_production(request.args['good_id'], requst.form['P_AMT']):
                result = save_into_db(...)
                # DB에 성공적으로 저장되었다면
                if result:
                    return 'OK'
    return 'FAIL'


# P_RETURN_URL
@app.route('/shop/return/')
def return_page():
    return redirect(url_for('shop.buy_list'))

```

예시로 사용된 코드에서는 GET으로 `good_id`란 값을 넘겨서 실제 상품과 가격이 맞는지 대조하고 있습니다.
상품정보 조작을 방지하려면 꼭 해야하는 작업입니다.
`P_NOTI_URL`에서 `?good_id=123` 과 같은 식으로 주소 뒤에 덧붙여서 충분히 인자 전송이 가능합니다.

## 기타 거래 결과 저장

결제창이 끝나면 `P_NEXT_URL`으로 POST 형식으로 `TID`를 포함한 몇 가지 값이 넘어옵니다.
문제는 넘어온 값만 봐서는 얼마를 결제했는 지 알 수 없으므로 추가 작업을 해줘야만 합니다.

소스는 Python과 PHP의 2벌의 예제로 준비하였습니다.

### Python

Python은 **실제로 돌려보진 않았습니다.**

의존성으로 requests를 사용하였습니다.
본 예제에는 Python 3이 메인입니다. Python 2를 위한 소스는 주석을 쳐두었으니 참고 바랍니다.

```python
from urllib.parse import parse_qsl, urlencode
# from urllib import urlencode
# from urlparse import parse_qsl

from flask import redirect, request
import requests


@app.route('/shop/result/', methods=['POST'])
def result():
    if request.form['P_STATUS'] == '00' and 'P_TID' in request.form:
        request_body = {
            'P_MID': 'INIpayTest', # 여러분 값에 맞게!
            'P_TID': request.form['P_TID'],
        }
        request_body = urlencode(request_body)
        raw_data = requests.post(request.form['P_REQ_URL'], request_body).content
        data = {x[0]: x[1] for x in parse_qsl(raw_data.decode('cp949'))}

        # 적당한 조건을 충족하면
        if data['P_STATUS'] == '00' and data['P_AMT'] == 1000:
            # DB에 저장합시다.
            save_into_database(data)
            return redirect('shop.success')
        else:
            # 아니면 저장하면 안되겠죠!
            kickban()
            return redirect('shop.fail')
    return redirect('shop.fail')
```

### PHP

PHP는 사실 설명할 생각이 없었는데, 아직도 많은 분들이 현업에서 PHP를 쓰고 있고, Python은 몰라도 PHP는 아는 분이 많으실 수 있으니 설명합니다.

PHP쪽은 iconv와 curl 의존성이 있습니다.
iconv나 curl을 쓸 수 없다면 적당히 대체 소스를 찾아보시는 것을 권합니다.

```php
<?php
if ($_POST['P_STATUS'] === '00') {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $_POST['P_REQ_URL']);
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_POSTFIELDS, 'P_MID=INIpayTest&P_TID='.$_POST['P_TID']) ; // 여기 수정하세요!
    $inipay = iconv('euc-kr', 'utf-8', curl_exec($ch));
    curl_close($ch);
    $result = array();
    parse_str($inipay, $result);

    if ($result['P_STATUS'] == '00' && (int)$cashmoney === (int)$result['P_AMT']) {
        save_into_db();
        header('Location: /shop/success/');
    } else {
		kickban();
		header('Location: /shop/fail/');
	}
}
```

## 테스트 결제

다 세팅이 되셨다면 테스트 결제를 해보시면 됩니다.
테스트 계정으로 테스트를 하셨다면 결제에 쓰인 돈은 당일 23시 즈음 환불됩니다.
다만 가상계좌(`vbank`)의 경우는 다르다고 쓰여있더군요.

## 후기

문서화의 소중함을 새삼 느꼈습니다.
문서가 없으니 두 명이서 이곳저곳에서 문서들을 짜집기하면서 만들었습니다.

이니시스측의 예제 소스는 왜 아직도 HTML 4 시절의 `<table>` 기준 레이아웃을 쓴다던가 하는 시대 퇴행적 면모를 보여주는가 하는 의문도 생겼습니다.
그 밖에도 왜 상품을 하나 밖에 지정을 못하는가[^4] 하는 API 구조상의 의문 등이 있으나 의문이 쌓여도 해소가 될 것 같지 않으므로 그냥 잊기로 했습니다.

이번 작업은 모바일이었기에 ActiveX가 필요 없었지만 아직도 한국 PC용 PG 연동은 ActiveX로 점철되어있습니다.
문서화도 그렇고, 좀 더 개발자 친화적인 PG 생태계가 되었으면 좋겠다는 생각입니다.

[^1]: PHP의 `time()`, JavaScript의 `Date().getTime()` 같은 것.
[^2]: 심지어 PC에서도!
[^3]: 기초적인 HTML 및 JavaScript 내용이므로 생략합니다.
[^4]: 몇년 전 PayPal의 PHP 연동 작업을 했었는데 쇼핑몰에서 구입하는 상품의 각각의 명칭과 갯수까지 기입할 수 있었습니다.


이니시스 Inipay 모바일 연동 방법을 소개합니다.