PHP는 정말 배울 가치가 없을까?
주류 언어 중 PHP만큼 비판받는 언어도 없다. PHP에 대한 비판이 지나치다 못 해 인신공격까지 서슴치 않는 경우도 있다. 오늘도 가루가 되도록 까이는 PHP를 위해 해명을 곁드린 PHP의 효용 가치에 대한 내 생각을 이야기 해보려고 한다.
PHP는 다른 언어들처럼 뚜렷한 큰 목적이나 이론(사상)을 기반으로 만들어진 언어가 아니다. 초기 PHP의 약자는 Personal Home Page였다. 즉, 개인 홈페이지 만들려고 나온 언어다. 그런 언어가 이제는 웹사이트 서버사이드 프로그래밍 언어 중 점유율이 매년 늘어나 2013년에는 78.7%에 달하고 있다. 기술 수준과 완성도가 진리라 생각하는 개발자나 해커로서는 땅을 치고 통탄 할 일이 아닐 수 없을 것이다. 그들에게 PHP는 쓰레기 같은 언어고, 당연히 쓰레기로서 취급을 받아야 마땅한 일일테니까 말이다.
"오마이갓! 무슨 일이 일어난거죠?"
그분들은 이리 생각하시고 계시는 듯 하다.
1. PHP는 프로그래밍 언어로서 치명적인 기초 설계 결함이 있고, 그로 인한 한계가 너무나도 크다.
2. 보안 문제나 단점은 적기조차 버거울 정도로 많다.
3. 그런 PHP가 시장에서 널리 사용되는 것은 잘 못 된 일이다.
4. 새로 프로그래밍을 배울 때 PHP를 배우는 것은 잘 못 된 개발의 길로 들어서는 일이다.
5. PHP로 만들어진 기존 시스템도 훌륭한 다른 언어 - 아마도 그 분들이 쓰고 계신 각자의 언어로 - 다시 개발해야한다.
6. PHP를 프로그래밍 언어 시장에서 완전히 쫓아내 아무도 사용하지 않는 언어로 만들어야 한다.
PHP가 가진 문제점 자체를 부정하는 사람은 거의 없다. 대부분의 PHP 개발자도 사실 관계로서의 단점에 대한 지적은 수긍을 하는 편이다. 나 또한 그러하다. 그런데 우리는 많은 문제점과 낮은 기술 수준을 가진 제품이 오히려 시장에서 더 인정을 받고, 결국 더 오래 살아남는 경우를 종종 보아왔다. PHP는 정말로 하루라도 빨리 시장에서 사라져야만 하는 것일까? 아니면 단점과 낮은 기술 수준에도 불구하고 시장에서는 더 오래 살아남았던 것들 중 하나가 될 것일까?
개인적으로 몇 년 전까지만 해도 프로그래밍 언어를 추천 해 달라고 하면 일반인에게는 파이썬(Python)을 추천 해 주었다. 개발자를 지망하는 사람에게는 C 언어를 - 그리고 펄(Perl)도. 1999년 PHP를 처음 배울 때부터 여러 단점 때문에 짜증을 낼 때가 많았다. 아마도 이런 경험이 나로 하여금 PHP를 추천하지 않게 하였을듯 하다. 예를 들어 PHP 4의 클래스는 이걸 쓰라고 만든 것인지 의심스러울 정도였다.
그러나 PHP가 주류 언어 중 하나로 성장하면서 지적됐던 단점들이 하나씩 보완되고 있기 때문에, 여전히 남은 단점들에도 불구하고 시장에서 빨리 퇴출시켜야 된다는 주장에 무작정 동의하기 보다 몇몇 상황에서는 PHP를 배우길 추천하고 싶다.
1. 웹사이트가 일이나 취미에 보완적으로 도움이 되는 경우
프로그래밍 그 자체가 주목적이 아니라 마케팅과 같은 비기술적인 일이나 커뮤니티 같은 취미에 웹사이트가 도움이 될 것 같아 직접 만들거나 운영하려는 사람들에게는 PHP가 학습 비용 및 운영 비용에서 잇점이 있는 언어다.
PHP는 현재 PHP를 사용하지 않은 개발자들도 대부분 어느 정도는 알고 있을 정도로 - 심지어 PHP를 비판하시는 분들 조차도 - 주변의 도움을 얻기 쉬운 언어다. PHP를 모르더라도 숙련된 C/C++ 개발자라면 즉석에서 PHP 메뉴얼을 보고 답을 줄 수 있을 정도다.
또한 PHP는 웹호스팅 비용이 매우 저렴하다. PHP를 제공하지 않는 웹호스팅 업체는 거의 없을 정도고, 제공하는 서비스의 완성도도 높은 편이라 문제를 겪을 일도 적고, 발생한 문제에 대한 기술 지원도 잘 이루어진다. 웹호스팅 업체 직원도 PHP는 대부분 알고 있다. 적은 비용으로 하고자 하는 일이나 취미에 도움이 되는 웹사이트를 운영 할 수 있다.
2. PHP로 만들어진 도구를 이용해야 하는 경우
PHP가 높은 시장 점유율을 가진 것의 절반은 이런 도구들 때문이라고 생각한다. CMS 시장의 1, 2, 3위를 차지하는 워드프레스(WordPress)와 줌라(Joomla), 드루팔(Drupal) 모두 PHP로 개발되어 있다. 조그마한 소호(SOHO) 사업을 하거나, 쇼핑몰이나 커뮤니티, 소규모 미디어 사업 등을 위해 이런 도구들을 이용하는 경우 PHP를 배우는 것이 유리한 점이 많다.
각종 플러그인이나 기능들을 직접 원하는대로 수정하여 운영 할 수 있는 경우 다른 사이트에 비해 경쟁력을 갖추는데 도움이 된다.
3. 개인 또는 제한된 사용자 규모를 가진 웹페이지를 만들어야 할 경우
다른 언어(특히 C/C++) 개발자가 개인 또는 내부 직원들에게 배포 할 용도로 1 ~ 2 페이지 정도 규모의 웹페이지를 만들어야 할 경우 두 언어 모두 능숙하다는 가정하에 HTML과 로직을 마구 섞어서 사용 할 수 있는 PHP의 접근 비용이 더 적을 수 있다. 물론 이 때에도 기존에 다른 언어로 구축 된 라이브러리들을 이용해야 한다면 PHP는 선택 대상이 아니겠지만, 그렇지 않은 경우는 고려 해 볼만한 하다.
4. 이미 PHP로 구축된 시스템이 있는 경우
개인적으로 PHP를 사용하고 계속 공부하고 있는 가장 큰 이유다. 백만 라인을 가뿐히 넘는 PHP(+HTML) 소스 코드를 PHP가 단지 단점이 많고, 완성도가 떨어진다고 다른 언어로 재개발 해야 한다고 주장하려면 책상 위에 사직서를 올려놓고 이야기를 시작해야 할지도 모른다. 사업에 캐시카우인 시스템이 PHP라면 당연히 PHP의 단점을 잘 이해하고 해결(회피) 할 수 있는 방법까지 터득한 절정의 PHP 실력을 갖추도록 노력하는 것이 맞다. PHP를 버리고 다른 언어로 다시 재개발하기 보다 단점을 해결하는 수준을 넘어 안드로메다까지 끌어올린 회사를 우리는 알고 있다. 페이스북.
이제 이야기를 정리하고 마무리 하자.
PHP는 외부 라이브러리의 매개변수 순서를 자신에게 맞추지 않고, 원형 그대로를 유지 할 정도로 실용을 우선시 하는 언어다. 덕분에 체계적이거나 기술적 완성미와는 거리가 멀다. 그러므로 PHP를 선택하거나 배우려 할 때도 실용에 초점을 두는 것이 맞다. 프로그래머로서 해커로서 엔지니어로서 기술적 욕구에 대한 충족은 미안하지만 다른 언어로 채우는 것이 낫다. PHP는 분명 나아지고 있고 언젠가 그 단점들을 모두 해결해낼지 모르지만, 당분간 그게 이뤄질 가능성은 없어낮아 보인다. 몇몇 언어들처럼 PHP6가 하위 호환성을 버리고 단점들을 한 방에 정리 할 것 같진 않다는 이야기다.
한 마디로 정리하자면 이렇다.
PHP는 실용성이 중요한 상황이라면 배워 둘만한 실용적 가치 정도는 있는 언어다.
자유로운 기업 문화를 어떻게 만들 수 있을까?
2013년이 시작된지 몇 일이 지나 SBS에서 '리더의 조건'이란 프로그램을 방송했다. 여기서 '제니퍼소프트'라는 회사가 소개됐는데, 스타트업에서 일하던 시절 화제가 됐던 회사여서 크게 더 관심을 두진 않았다. 하지만 평소 좋아하던 표철민님과 윤석찬님이 서로 다른 의견을 내시면서, 다시 한 번 기업 문화에 대해 생각을 하게 되었다.
4월이 시작한 지금 뒤늦게 이 문제를 정리하는 이유는 논란이던 시점에 정리하면 내 생각 보다는 시류에 편승 할 위험이 있기 때문이고, 논란의 흐름과 상관없이 창업을 하거나 사업을 관리 할 때 이 부분은 언제나 가장 고민스러운 부분이기 때문이다. 훗날 스스로 업을 일으킬 때 잊어버리지 않기 위해서라도 이것을 정리해 글로 남기고 싶었다.
혹시 두 분 글을 안 읽어 본 분은 여기서 잠시 멈추고, 글을 먼저 읽어보는 것이 좋을 듯 싶다.
- 표철민님 블로그 - 자유를 누릴 자격이 있는 사람
- 윤석찬님 페이스북 - https://www.facebook.com/channyblog/posts/397707593656441
기본적인 관점에서 두 분의 의견 모두 맞다고 생각한다. 개인적으로 윤석찬님의 의견에 공감을 하지만, 표철민님 생각도 맞다고 본다. 그런 이런 두 관점에 대한 차이는 어디서 나오는걸까?
그건 바로 올바른 기업 문화를 사업 초기부터 잘 설정하고 유지했느냐 못 했느냐의 차이다. 보통 자유를 허락하는 기업의 경우 반드시라고 할 정도로 꼭 체리피커가 등장한다. 바로 이 체리피커를 어떻게 관리를 하고 자유로운 기업 문화를 유지하느냐가 이 논란의 핵심이다.
문제는 우리나라는 체리피커를 관리하는데 두 가지 어려움이 존재한다. 하나는 한국 사회의 인정 위주 문화로 인한 쓴소리 하기 어려운 분위기이고, 또 다른 하나는 사업 규모를 빠르게 키우려고 하는 조급함 내지는 내외부의 압력이다.
체리피커가 처음 등장했을 때 초기부터 합리적으로 설명을 하고, 태도에 변화가 없으면 즉시 내보내야 하는 것이 중요한데, 설명과 이해와 동의 보다는 단순한 질책과 화를 내는 것이 전부인 경우가 많고, 막상 그 이후에 바로 내보내지도 못 하면서 속만 끓이는 경우가 많다. 이러는 사이에 기업 문화는 점점 망가져 가며, 각종 규칙과 제재란 것이 등장하면서 자유로운 기업 문화를 사라지게 된다.
이런 체리피커는 만들어내고 정리하지 못하게 되는 원인 중 하나는 조급한 사업 규모의 확장이다. 사업 규모를 성급하게 키우면 세가지 문제점이 나타난다. 첫째 사람에 대한 충분한 검증할 시간이 부족해 체리피커를 채용 할 가능성이 높아진다. 둘째 이질적인 기업 문화에서 일하던 사람들의 비율이 증가해서 기업 문화 원형이 가진 압력과 설득력, 그리고 원형 그 자체가 손상받기 쉬워진다. 셋째 장기적 발전을 위한 기업 문화의 유지 보다 매출 같은 결과로서의 숫자에 회사 역량이 쏠리게 된다. 단기적으로 이게 좋아보일지 몰라도 앞으로 성장 할 수 있는 잠재력을 다 갉아먹는 일이다. 거기에 더해 전체적인 임금 규모가 커지면서 개개인에 대한 복지 확대가 어려워져 인재에 대한 유인력이 떨어지고, 단기적인 성과에 기존 직원들이 내몰리게 되는 문제도 있다.
자유로운 기업 문화로 인해 사업(회사)가 망가지는 것을 어떻게 하면 막을 수 있을까?
창업자들끼리는 기업 문화에 대한 생각과 모양새에 대해 확고한 공감대를 가지고 있는 것이 좋다. 혹시 기존에 어떤 모델이나 사례, 기업이 있다면 명확히 우리 회사는 어떤 것을 기초로 한다는 것을 서로 공유하는 것이 좋다.
채용을 쉽고 급하게 하지 말아야 한다. 오랜 시간 뜸을 들여서 신중히 채용을 해야 한다. 또한 직원을 채용 할 비용을 확보하고 채용해야 한다. 당장 매달 나가는 직원의 급여만큼 벌지 못 하면서 직원을 늘리는 것은 회사와 직원 모두에게 안 좋다. 직원을 채용 할만큼 안정적인 수익이 늘어나거든 그때 채용을 한다. 단, 채용을 조건으로 의미있는 수준의 지분을 받는 사람은 직원이 아니라 창업자로 보아야 한다. 대신 급여 수준을 회사가 감당 할 수 있는 수준으로 낮추자.
새로운 직원이 들어오면 기업 문화에 대해서 충분히 이해를 시키도록 해야 한다. 거기에 더해 기업 문화에 어긋나는 행동을 하면 누구라도 해고될 수 있다는 점도 주지시켜야 한다. 다만 기업 문화를 세세한 항목별로 규칙으로서 만드는 것은 좋지 않다. 가장 기본이 되는 큰 흐름에서 서너가지 정도로 압축을 하고, 나머지는 상식에 맞기자.
기업 문화에 어긋나는 행동을 한 사람에게는 바로 지적을 하고 그것이 기업 문화에 어떤 악영향을 주는지 설명한다. 물론 다시 어길 경우 해고 될 것이라는 경고도 잊지 말자. 아울러 이런 경우가 발생하였다고 그것을 막기 위한 규칙을 만들어서 회사에 공표하는 것은 금물이다. 또 어긴다면 매정하게 보일지라도 바로 내보내야 한다.
기업 문화를 잘 만들고 유지하는 것은 성장 엔진을 만들고 매출을 늘리는 것만큼이나 어렵다. 어려운만큼 중요성도 작지 않다. 다양한 스타트업 및 중소기업에서 근무 또는 창업을 하면서 기업 문화에 대해 많은 고민을 하였다. 10년이 넘는 시간 동안 실험과 실패, 그리고 교훈을 배우면서 이제는 조금 전보다는 잘 할 수 있다는 자신감 같은 것을 얻었다. 전문가는 아니지만 부족하나마 실전을 통해 얻은 교훈과 생각을 공유하고 싶었다.
관리자(프로듀서)에게 기술력을 요구하지 말자
소프트웨어 개발 프로젝트 안에는 여러 직군이 있지만, 그 중 대표적인 것이 '개발자'와 '관리자'다. 이 둘은 각각 역할을 성공적으로 해내기 위해 여러가지 기술을 갖출 것이 요구 되는데, 공통적인 것도 있지만 서로 다른 부분이 훨씬 더 많다. 개발자라면 프로그래밍 언어와 플랫폼에 대한 이해를 비롯해 각종 알고리즘 등과 같은 컴퓨터 과학의 지식들이 필요하다. 관리자는 문서 작성 능력이나 대인 기술 등이 중요 할 것이다. 이렇게 요구되는 기술이 서로 다름에도 불구하고 경력있는 개발자들이 관리자로 자의 또는 타의로 바뀌고 있는 것이 불행한 현실이다.
이런 현상에 대해 여러가지 이유가 있겠지만, 그 중 개발자들이 관리자의 개발 기술력을 따지는 것도 한 원인으로 보고 있다. 개발자와 관리자는 요구하는 기술이 다른데 왜 관리자에게 기술력까지 요구하는 것일까?
그것은 우리나라 소프트웨어 개발에서 디렉터, 아키텍트, 프로듀서의 역할이 제대로 분리되어 있지 않기 때문이다. 현실은 이 셋의 역할을 관리자라는 이름으로 같은 사람이 다 맡고 있다 보니 관리자로서 개발자들을 지원만 해주는 것이 아니라, 여러가지 민감한 기술적인 최종 결정도 내려야 하는 상황이 생기고, 그러다 보니 개발자들은 관리자에게 자신들보다 더 높은 기술력을 요구하게 됐다. 그 결과 많은 경험을 쌓은 개발자가 관리자가 되어야 하는 악순환의 고리가 생겨버린 것이다.
개발자들 보다 더 높은 기술력과 많은 경험이 요구되는 것은 아키텍트다. 그럼에도 불구하고 개발자들은 관리자(프로듀서)에게 기술력을 요구하는 경우가 많다. 실상 요구를 해야 하는 것은 관리자가 아키텍트로서 역할을 하지 말아달라고 하는 것이며, 관리자에게 기술력을 갖추라고 하는 것은 경험 많이 쌓고 기술력을 갖춘 개발자를 관리자로 떠다 미는 효과만을 낳을 뿐이다.
디렉터가 결정을 내리고, 아키텍트가 아키텍트를 디자인 하며, 프로듀서가 프로젝트를 프로듀싱 할 때 개발자가 자꾸 관리자로 변신을 해야 하는 상황을 막을 수 있다.
관리자에게 기술력을 갖추길 요구하지 말고, 아키텍쳐는 아키텍트가 결정을 할 수 있게 해달라고 요구하자. 아키텍트가 없다면 리드 프로그래머라도 그 역할을 대신 수행하면 된다.