이제와서 PHP로 개발해야하는 이유 part 2

 In Programming

TL;DR: 모던 MVC프레임웍은 기능이 풍부한 대신에 하위호환에 신경을 쓰지 않는다. PHP는 기능은 떨어지는 대신에 장기적으로 안정된 플랫폼을 제공한다. 지금은 어떤 스타일의 개발이 올바른 방식인지 고민해볼 때이다.

 

전편의 반응이 나쁘지 않아서 시간을 두고 작성하려 했던 2부를 연휴에 바로 작성했습니다. 전편에서는 PHP가 전세계적으로 잘나가는 현상에 대해 이야기 했는데, 실질적인 웹개발 이야기는 빼고 보이는 현상만 다루다보니 2000년대 초반의 악명높은 PHP로 오해하시는 분들도 계시더군요. 이번엔 현재의 웹서버 개발 상황과 모던 PHP에 대해 자세히 설명을 해보겠습니다.

개인적으로 웹서버 개발은 딱히 익사이팅한 작업은 아니라고 생각합니다. 프로그램의 동작 여부와는 상관없는 노가다 작업이 많기 때문입니다.

예를 들자면 일반적인 서버 프로그램은 보통 이런 식으로 동작합니다. 유저 입력이 들어오면 -> 받은 입력을 처리해서 -> 내부로직을 통해 DB의 데이터를 처리하고 -> 결과를 html로 뿌려줍니다. 참 쉽죠?

그런데 이 과정에는 최소한 두가지의 노가다 작업이 필요합니다. 유저에게서 입력받은 데이터가 정상인지 체크하는 Server side validation과, DB의 데이터를 프로그램에서 사용할 수 있는 형식으로 변환해 주는(퉁쳐서 ORM이라고 부르기도 하는) 작업입니다. 이 이외에도 수많은 노가다가 존재합니다만(파일 업로드 처리라던가 pagination이라던가 나열하면 끝이 없습니다.) 이 두가지는 작업량도 많은데다 이미 존재하는 사양을 코드로 변환하는 단순한 과정이기에 재미도 없습니다. 이 중에서 Server side validation은 모든 입력을 대상으로 하지 않으면 보안에 구멍이 생기지만, 안해도 어차피 티가 잘 안나는 작업이라서 누구에게도 인기가 없습니다.

이쯤에서 웹 개발의 초기에 PHP로 작성한 코드를 한번 확인해보겠습니다. 라고 해도, 요즘도 네이버에서 검색하면 지식인에 이런 코드가 나옵니다.

$name = $_GET["name"];
mysql_query("INSERT INTO users (name) VALUES ('$name')", $conn);

정말 끔찍한 코드입니다. Server side validation에 대한 개념 자체가 없네요. $name에 sql injection 코드가 들어가면 DB는 한방에 끝장입니다. 만약에 $name에 script태그라도 들어가 있으면 CSRF에 직빵입니다. 스팸으로 $name에 이상한 값이 들어가게 되면 쓸모없는 유저가 계속 추가되어 디스크와 CPU 자원을 낭비하게 되겠죠. 이런 코드는 바닥부터 새로 만드는 게 훨씬 낫습니다.

세상에는 유저로부터의 입력이 거의 없는 스태틱한 사이트도 있고, DB가 필요없는 사이트도 있기 때문에 대충 만든다고 큰 문제가 되는 경우는 생각보다 많지 않습니다. 하지만 대충 만들어도 되는 사이트에서 프로의 개발자가 짭짤하게 돈벌기는 무척 어려운 일입니다. 돈되는 사이트를 만들려면 바닥부터 제대로 만들어야 하기에, 현장에서는 지겨운 반복 작업을 단순화해 주는 고마운 MVC프레임웍이 활발하게 쓰이고 있습니다.

써보신 분들은 아시겠지만 모던 MVC프레임웍은 기능이 너무 좋아서 지금에 와서 안쓰고 개발한다는 것은 생각할 수도 없습니다. 얼마나 좋은지 Server side validation의 샘플 코드를 통해 확인하고, 마지막으로 모던 PHP 코드와 비교해보겠습니다.

스프링

public class User {
    @Size(min=2, max=30) 
    private String name;
}

@Controller
public class FormController {
    @RequestMapping(value="form", method=RequestMethod.POST)
    public String submitForm(@Valid Subscriber subscriber, BindingResult result, Model m) {
        if(result.hasErrors()) {
            return "formPage";
        }
    }
}

strictly typed 언어임에도 annotation으로 예술적으로 깔끔하게 구현했습니다.

 

장고

class NameForm(forms.Form):
    name = forms.CharField(max_length=100)

form = NameForm(request.POST)
    if form.is_valid():
        # do something

python 특유의 문법 덕분에 매우 깔끔하게 구현되었습니다.

 

다음은 루비온레일즈입니다.

class Person < ActiveRecord::Base
  validates :name, presence: true, length: { minimum: 3 }
end
 
person = Person.new
person.valid? # => false
person.errors.messages

가장 짧고 간결할 뿐만아니라 기능도 풍부합니다. 레일즈답네요.

 

모던 PHP에서는 이렇게 처리가 가능합니다.

class UserForm extends BaseForm {
    public $userid;
    public $sanitizeRules = array(
        "userid" => array(
            'required' => true,
            'filter' => FILTER_SANITIZE_FULL_SPECIAL_CHARS
        ),
    );
}

$form = new UserForm();
if ($form->error) {
   // do something
}

filter_var_array라는 내장 함수를 그대로 이용하는 클래스를 간단하게 만들어서 Server side validation구현해봤습니다. 한눈에 봐도 지저분한 데다 그나마 기본제공 기능만으론 부족해서 필요한 기능을 자체 제작해서 넣어야 쓸만해집니다. (sanitization과 validation을 구별하는 것은 별도로 하고요) 확실히 말해서 PHP의 코드는 어찌어찌 굴러는 가지만 아름답지도 않고 제공하는 기능은 필요 최소한입니다.

여기까지만 보면 왜 열등한 PHP를 써야하는지 이해가 안갈껍니다. 세상엔 훨씬 더 나은 개발환경이 널렸으니까요. 해답은 모던 MVC프레임웍의 업그레이드 가이드에 있습니다.

루비온레일즈의 가이드에 보면 업그레이드에 대해 이렇게 설명해놨습니다..

Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade. 업그레이드를 하고 싶다면 꼭 해야하는 이유가 있어야 할 것이다.

장고의 가이드엔 이렇게 나와있네요.

While it can be a complex process at times, upgrading to the latest Django version has several benefits. 업그레이드가 복잡한 일이긴 하지만 최신버전으로 업그레이드 해두면 몇가지 좋은 점이 있다.

스프링의 가이드는 업그레이드 시 필요한 과정에 대한 긴 리스트로 이루어져있습니다. 게다가 이미 3.0, 3.1는 서포트가 끝났고, 3.2는 올해말에 끝날 예정이고 4.0은 시큐리티 패치만 지원되고 있다고 하네요. 거기에다 올해말에 나올 Spring 5는 Java8이상만 지원한다는 군요. 한국의 전자정부 프레임웍이 3.x기반으로 알고 있는데 괜찮은지 걱정이 됩니다.

성공한 웹프레임웍 진영에서는 매년 새로운 기능으로 무장한 업데이트 버전이 나오고 있습니다. 그리고 2~3년이 지난 버전은 서서히 지원을 중단하고 있습니다. 이것은 웹 프레임웍의 코어 뿐만이 아니라 생태계에 포함된 라이브러리나 패키지에도 똑같이 적용됩니다. 하이버네이트의 업그레이드 가이드를 보면 스프링을 어떻게 업데이트 한다해도 하이버네이트를 업데이트 하는건 전혀 다른 작업이라는 것을 알 수 있습니다. 장고의 패키지 사이트에서 최근까지 관리가 잘 되고 있는 프로젝트 중 임의로 한 개를 선택해서 확인해보니 2년전에 나온 1.7 이상만 지원하고 있습니다. 지원하는 버전이 많아지면 전부 대응하기 어려우니 오픈소스를 운영하는 입장에서는 당연한 일입니다.

제가 느끼는 최근의 웹 개발은 이런 패턴입니다. 최신의 웹 프레임웍 선정(경우에 따라서 안정성을 위해 한버전 아래를 선택하기도 합니다.) -> 최신 기술을 써서 멋진 사이트 개발 -> 1년후: 새 프레임웍이 나왔지만 아직도 현재 프레임웍이 쓸만하다. -> 2년후: 슬슬 기능 업데이트와 써드 파티의 지원이 끊기고 있다. xxx기능을 쓰고 싶은데 추가가 어려우니 포기한다. 슬슬 업그레이드를 하면 좋겠다고 생각한다. -> 3년후: 보안패치가 끊긴다는데 공격당할 일이 있을까? 이미 오래된 프로젝트라 손대면 할일이 많으니까 조용히 있는다. -> 4년이후: 호환되는 코드가 없고 처음에 개발한 사람도 어디론가 가버렸다. 작은 문제는 땜빵하지만 큰 문제가 생기면 방법이 없다.

개발자들이 최상의 성능을 가진 모던 MVC 프레임웍으로 개발하기 위해서는 최소 3~4년에 한번씩 업그레이드를 해야합니다. (그럼에도 2년째 부터는 개발이 답답해지는 문제가 있습니다.) 그런데 현실적으로 개발자를 위해서, 혹은 유지보수의 편의를 위해서 서버 스택을 적절한 시기에 교체하는 회사는 기술력 중심이거나 급속도로 성장하는 스타트업 정도가 아닐까 합니다. 아무래도 업그레이드 비용에 대한 의견은 개발자와 경영자가 다를 수 밖에 없습니다. 물론 과거의 스택에 그대로 매여있어도 됩니다. 최신 기술을 못쓸 뿐이지 기본적인 기능은 전부 가능한데다 기능이 적어서 심플하고 리퍼런스도 많으니까요. 웹사이트의 성능이 좀 떨어져도 된다면, 그리고 그 스택을 유지 보수할 줄 아는 개발자가 계속 존재한다면 별 상관 없습니다.

하지만 그런 개발은 별로 재미없고 도전적이지도 않습니다. 개발자의 경력에 안좋기도 하구요. 그래서 모던 PHP를 이용한 개발이 의미가 있습니다. PHP로 개발하면 레거시 문제를 효과적으로 다룰수 있는데다 비용을 거의 들이지 않고도 쿨한 새로운 기능(PHP 7.0의 경우 null coalescing operator나 극적으로 개선된 엔진 등)을 쓸 수 있습니다. 모던 PHP개발은 개발자와 경영자가 동시에 만족할 수 있는 방법론입니다.

누구나 다 인정하듯 PHP의 코드는 지저분하기때문에 높은 생산성을 유지하는 것은 쉬운 일이 아닙니다. 노하우를 쌓을 때까지는 많은 시간과 노력이 걸릴것이고, 모던 PHP에 익숙한 개발자를 구하기도 어렵습니다. 하지만 투자의 가치는 있다고 자신합니다. 지금 당장이라도 멋진 사이트를 제작하고 싶으신 분들은 저희 회사로 연락주시면 성심성의껏 상담해 드리겠습니다. 언제든 환영합니다!

Recent Posts
Showing 16 comments
  • akdrp
    응답

    글 잘 읽었습니다.

    저도 PHP에 애증이 있긴 하지만 유지보수 때문이라는 시각은 새롭네요.

    제가 좋아하는 점은 작성-테스트 주기를 빠르게 할 수 있고 언어의 편의성이 높으면서도 괜찮은 기능들(5.3 이상)도 꽤 있다는 점이고,
    빈약한 디버거, 일부 일관성 없는 사용법 같은 건 문제점이라고 생각합니다.

    사실 5.x 에서 7.0 올라가면서 꽤 바뀐 부분이 있는데 미묘하게 다르게 동작하는 부분도 있어서 호환에 문제가 없다고 얘기하긴 무리가 있네요. 다른 언어에 비해 상대적으로 적은 건 맞는 듯 합니다.

    바뀐 부분 정보: http://php.net/manual/en/migration70.php
    (1편 글에 어느분이 버전별 문서가 없다고 했는데 혹시 언급된 문서가 이거 아닌가 싶네요.)

    • 박 종희
      응답

      바뀐 부분은 있지만 예전부터 사용을 권하지 않았던 부분이 없어진 것이라서요. 제일 큰 변경은 호환성을 위해 남겨뒀던 PHP 4 style constructors가 사라진건데, __construct를 전체 소스를 돌려서 이름만 바꿔주면 되는 일이라 실제로 업데이트 했을 때 별 문제 안되더군요. Exception의 타입이 둘로 나눠진 것도 문제이긴 했는데, 그것도 금방 수정했네요. 아주 깔끔하게 단시간에 업데이트했습니다.

      디버거는 xdebug에 Intellij Idea를 붙이니 쓸만하더군요. 게다가 PHPDoc을 이용하면 Intellij의 auto-complete 기능을 쉽게 이용할 수 있다는 장점이 있습니다. PHP함수의 일관성없는 사용법은 귀찮긴한데, 그냥 감수하며 쓰고 있습니다. 함수도 auto-complete가 되서 직접 써보면 생각보다 편합니다. Intellij없었으면 PHP개발은 불가능하지 않을까 하네요..

  • 나그네
    응답

    저같은 경우는 일관성 없는 함수문제도 유틸용 라이브러리 이용해서 해결했다고 해야하나 여튼 구글 귀찮게 검색한번 더 하는 수고를 덜었습니다.
    js,php 둘다 언더스코어로 통일하고 이거든요. 컴포저의 등장이 신의 한수같아요…

    • 박 종희
      응답

      js에선 언더스코어 대신에 lodash가 대세가 되는 듯한데, lodash의 php버전은 안보이네요. 저는 그래서 필요한 최소기능만 구현한 커스텀 라이브러리를 운영하는게 낫다고 생각합니다. 문제는 회사에서 라이브러리 관리에 들어가는 시간과 노력을 인정해주느냐 하는 것이겠지만요.

  • 떡밥물었음
    응답

    PHP는 학부때 잠깐 써본 기억밖에 없습니다.
    편한 언어인 건 분명합니다.
    그리고 종희님처럼 경험 많은 개발자가 잘 만들면 유지보수 하기 좋게 만들 수 있을 겁니다.

    제가 생각하기에 언어에서 가장 중요한 점은 능력자들이 얼마나 그 언어에 관심을 갖고 발전 시켜나가느냐에 달려 있다고 생각합니다.
    프로그래밍 언어는 계속 변화하니까요.

    그래서 현재 많이 쓰이는 언어와 신규 개발자가 많이 유입되는 언어를 분리해서 생각해볼 필요는 있는 것 같습니다.
    상대적으로 PHP는 신규 유입되는 개발자가 적기 때문에 발전 속도가 점점 더뎌 질것 같기도 하구요.

    덧, 결국에 떡밥을 물어버렸는데요. ㅠ
    언어는 도구에 불과해서 뭐가 좋다고 하는 게 의미가 있나 싶습니다.
    영어가 가장 좋은 언어는 아니지만 많이 쓰이기에 꼭 배워야 하는 것처럼, 개인적으로는 가장 많이 쓰는 언어를 배우며 트렌드를 따라가는 게 좋다는 생각입니다.

  • 지나사
    응답

    논점이 조금 이상한 것 같습니다.
    지금 PHP는 언어 그 자체가 영속성이 있다고 하시면서, 영속성이 보장되지 않는 것의 예시로는 프레임워크를 드시고 계십니다.
    마치 금속은 영속성이 보장되어 있지만, 자동차 휠은 그렇지 않다 라고 주장하는것과 유사해 보입니다.

    PHP가 5.3이후 부터 영속성을 보장해 주지만 타 프레임워크들은 그렇지 않다고 하셨는데, 이는 사실 PHP기반의 프레임워크들은 영속성을 보장하지만 타 언어를 기반으로 한 프레임워크들은 그렇지 않다 라고 비교하여야 정상적인 비교가 됩니다.
    따라서 본문의 내용에서 비교를 하시려면 코드이그나이터2와 코드이그나이터3, 혹은 cafephp2와 cakephp3에서 상호 영속성이 존재하는지를 보이셔야 정상적인 비교가 가능하지 않을까요.

    모던PHP는 어디까지나 PHP로 개발할 때 이런식으로 하면 좋다라는 개발 지침에 가깝습니다. 자바로 본다면 자바 디자인 패턴이 되겠고 파이썬으로 하자면 PEP8이 되겠죠.
    해당 언어를 잘 사용하기 위한 지침서 대로만 개발을 할 수 있다면 어떤 언어든 문제가 될까요.
    결국 얼마나 잘 디자인된 프로그램을 얼마나 잘 코딩하고 얼마냐 잘 관리하느냐는, 개발자의 역량이 중요한 것입니다.

    예를 들어 자바의 경우 별도의 디펜던시가 없다면 1.4버전에서 작성한 코드도 1.8에서 정상 동작이 가능합니다.
    앞선글의 댓글에서 들어주신 예시는 톰캣의 버전이 다르고, 톰캣6와 7간의 영속성이 적은것은 알려진 사실입니다.
    파이썬의 경우도 2.4에서 작성한 코드는 2.7에서도 동작이 가능하고, 3.1에서 작성한 코드는 3.6에서도 동작합니다.
    이에대해 php의 영속성을 말씀하시며 5.3이후는 다 된다 라고 주장하셨지만, 이는 5.3이전과 5.3이후의 영속성은 적다고 인정한 것과 동일합니다.

    또한 php 5.3이후버전과 7.x의 영속성이 높다는 말도 동의가 어렵습니다..
    최근에 php5.4에서 동작하던 프로그램의 서버를 마이그레이션 하는 업무를 처리하며 테스트 삼아 php7에 올려보았던 적이 있었으나, php7이 되면서 동작이 바뀌거나 사라진 함수들로 인해 정상동작하지 않았습니다.
    간단한 수정을 통해 동작이 가능하다면 가능하면 성능이 좋은 php7으로 올리고자 코드 마이그레이션을 시도하였으나, 오히려 php7을 마이그레이션을 하기에는 업무량이 많다는 인상만 받고 결국 php5.5를 썼던 기억이 납니다.

    장인보고 도구를 바꾸라고 강제하거나, 이미 만들어져 있는 것들을 다 버리고 다른것으로 새로 만들라는 것은 당연히 말도 안되는 주장이겠지요.
    만약 프로젝트를 하는것에 있어서 보유 인력이 PHP 관련 인력밖에 없다거나, 혹은 PHP에 대한 인정받을만한 능력의 개발자가 있다면 PHP로 개발하는것도 나쁘지 않겠지요.
    왜냐면 그 프로젝트는 좋은 디자인을 가지고, 잘 코딩될 것이며, 잘 관리될 테니까요.
    하지만 그렇지 않다면 좀더 문법적으로 좋은 디자인을 강요하는 언어를 사용하거나(JAVA), 혹은 좀더 좋은 코딩을 강요하는 언어를 쓰거나(python), 혹은 좀더 좋은 관리 기술을 강요하는 프레임워크(루비온레일즈)를 사용하는 것이 좋겠죠.

    혹시나 오해가 있을까 싶어 첨언하는데 제 주장은 PHP가 절대악이니 당장 그것을 버려야 한다는 종류가 아닙니다.
    기존에 잘사용하고 있는 잘 훈련된 PHP프로그래머가 굳이 그것을 버릴 이유나, 이미 잘 만들어진 프로그램을 재작성해야할 이유는 전혀 없지요.
    하지만 새로이 배우는 신입 프로그래머에게 PHP가 지닌 수많은 언어적 함정을 피해서 모던PHP 형식으로 사용하는 훈련을 굳이 시켜야할 이유도 없다고봅니다.
    새로운 사람은 더 나은걸 배우는게 더 나으니까요.

    • 박 종희
      응답

      근본적으로 뭔가 오해하고 계시는데 PHP 자체가 low-level의 웹프레임웍입니다. PHP는 타 언어에서는 라이브러리에 의존해야하는 Request, Response처리, Input Validation, ORM 등등 무수히 많은 기능을 기본으로 포함하고 있습니다. 그것이 PHP를 웹용 언어로서 특별하게 하는 것이죠. 그러므로 PHP와 다른 언어를 비교한다면 루비+RoR이나 파이썬+장고, 자바+스프링같이 프레임웍과 1대1로 비교해야 합니다. cakephp같은 PHP 프레임웍은 저로서는 왜 쓰는지 모르겠네요. PHP에서는 MVC 프레임웍이 없어도 MVC개발이 가능합니다.

      PHP5.4로 작성된 코드가 PHP7.0에서 동작하지 않는다면 PHP5.4코드가 Best Practice로 작성되지 않아서 그럴 가능성이 높습니다. 제가 만든 코드는 Exception과 Error처리 부분의 수정 이외에는 업그레이드 할때 전혀 문제가 없었고, wordpress plugin을 업데이트 했을때도 class의 constructor만 문제가 되었습니다.

      신입을 가르치거나 경력직을 뽑을때 PHP가 불리하다고 하는 주장은 저로서는 동의하기 어렵습니다. 어차피 웹기술은 계속 트렌드가 바뀌는데 PHP의 러닝커브는 그렇게 높지 않기때문입니다. 타 회사라면 문제가 될수도 있겠지만 저희 회사는 아닙니다. 그리고 이 글의 궁극적인 목적은 어그로 끌기가 아니라 저희 회사의 기술력 홍보입니다.

  • youbenGo
    응답

    안녕하세요 깊이있고 심도있는 내용이라 정말 잘 읽고 갑니다!
    혹시 실례가 안된다면 다른 언어도 포함해서 조금 더 깊게 질문하고 싶은 내용이 있는데 폐북계정이나 이메일 주소 등을 알려주실수 있나요?

  • 완두
    응답

    좋은글 잘읽었습니다. 🙂 한가지 아쉬운점은 비교대상이 잘못된것 같습니다. 언어의 비교는 언어로 한정해야지, 프레임워크랑 비교하면 안되는것 같습니다. PHP도 코드이그나이터나 라라벨같은 프레임워크의 예시를 들었으면 한결 더 좋지 않았나 생각이드네요.

    • 박 종희
      응답

      PHP 자체가 low-level의 웹프레임웍이기때문에 별도의 프레임웍이 없어도 MVC개발이 가능합니다. 제가 Proof-of-Concept로 프레임웍을 만들었는데 별 문제 없이 잘 쓰고 있습니다. 시간이 될때 문서화해서 공개하고 싶은데 요즘은 자바스크립트하느라고 계속 바빴네요 ㅠ.ㅜ

  • 홍기원
    응답

    비슷한 생각과 고민을 가지고 있던 개발자인데..
    뭔가 고민 하던 것에 대한 해갈한 것 같아 다행이네요.
    좋은 글 잘 읽었습니다.

  • 지나가다
    응답

    간단히 돈많이 벌리고 잘팔리는 기술(언어)를 배우고 그것으로 일(프로그래밍)하면 되요. 이런 논쟁은 30년전이나 지금이나 반복되는 불필요한 논쟁이에요.

  • 헐프레임워크일줄이야
    응답

    php가 웹 프레임워크라고 해도 스프링, 장고등과 비교는 잘못된것 같아요.
    일단 스프링부터가 시작과 용도부터가 다른 프레임워크이고..
    굳이 하려면 스프링 웹mvc와 해야하는데 스프링 웹mvc 마저도 수많은 자바 웹표준 스펙들을 추상화한 구현체니까요.
    그중에 서블릿/jsp를 포함해서 추상화 한것이구요.
    그런 관점에서 서블릿/jsp가 php와 그나마 유사한 수준의 low-level 웹프레임워크(?)인것 같네요.
    orm의 경우도 하이버네이트가 아니라 jpa와 비교해야해요.
    jpa구현체가 하이버네이트이긴 한데, jpa구현체가 하이버네이트만 있는 것도 아니고..
    jpa표준 스펙에 맞춰서 개발하면 호환성 이슈에서 많이 자유로워질 수 있습니다.
    해봤자 설정이나 설치 라이브러리가 달라지는 정도이죠.
    파이썬도 장고보다는 flask나 psp가 적당해 보입니다만,
    어찌보면 파이썬 자체가 일종의 c언어 프레임워크 역할을 할때가 많아서… 파이썬 자체만 놓고 봐야 할지도?
    파이썬도 자체 표준스팩 들이 많이 있지만 자바와는 느낌이 좀 다르죠.
    루비는 모르겠습니다. 안써봐서… ^^
    아무튼 자바나 파이썬 프레임워크와 비교하려면 표준 스펙들과 해야 급이 맞아보입니다.
    그렇게 하면 언급하신 호환성 이슈에서 상당히 자유롭습니다.
    php가 호환성에서 자유롭다고 하셨지만, 상당수 퍼진 개발방법으로는 이에 자유롭지 못하기 때문에 좀 어폐가 있는 편이죠.
    그렇기 때문에 박종희 님의 주장과 다르게 언급하신 이슈들이 php만의 장점도 아니고 타프레임워크만의 단점이 아니에요.
    그런데 php를 언어가 아니라 프레임워크라고 생각하고 보니 상당히 괜찮아 보이긴 하네요.
    기능이나 성능만 놓고 보면 타 프레임워크들을 압도하는 것 같군요.
    말하신 대로 Best Practice만 제대로 알려진다면 별도의 프레임워크가 필요 없겠네요.
    대신 프레임워크를 쓰는 것보다 코드량은 많아지겠죠.
    여담이지만 최신 서블릿 스팩만으로 스프링 웹mvc처럼 어노테이션만으로 개발이 가능합니다.
    그런데 자바쪽도 이런걸 모르는 분들이 정말 많아요. 아직도 xml이 난무하거나 jsp로 떡칠한다던지 그러는줄 알고있어요.
    그래서 더더욱 프레임워크를 사용하게 되구요. 그런 점이 현재 php 개발자들과 비슷한 상황인것 같습니다.

  • 파이썬은..
    응답

    Python을 아예 모르는 사람이라고 가정하고 아래와 같은 식(코드)을 봤을 때 어떤 결과를 예상하시나요?

    >>> 3 / 2

    Python 3.4의 결과는 다음과 같습니다:

    >>> 3 / 2
    1.5

    예상한대로 나왔습니다. 3에서 2를 나누면 1.5죠. (Node.JS, Perl, Haskell, Lua, PHP 등의 언어 또한 이와 같이 동작합니다.)

    이제 다음 Python 2.7의 결과를 확인해봅시다:

    >>> 3 / 2
    1

    3에서 2를 나눴는데 어떻게 1이 나올까요?

    Python 2.x에서는 int / int 의 결과는 항상 int이기 때문입니다. 위 식을 Python 2.x에서 원하는대로 돌아가게 하기 위해서는 다음과 같이 입력해야 합니다:

    >>> 3 / 2.0
    1.5
    >>> 3.0 / 2
    1.5

    5년 지났는데 이렇다는군요…

    • Niafilmuh
      응답

      전 그거 이상하지 않다고 생각해요. 자료형이 제멋대로 변하면 그게 더 골치아프더라고요.
      자료형의 자동 변환은 경우에 따라서는 편하긴 하지만 개인적으로 직접 컨트롤하는편이 더 안전하다고 생각합니다.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search