물론 다른 PHP 개발자들이 PHP 날코딩에 익숙해 있었기 때문에 그 당시에는 도입할 수 없었구요.
PHP로 개발을 할 줄 아는 사람들이 바뀌는게 제일 시간이 걸리고 어렵기 때문에
개인적으로 PHP 자체는 문제가 없거나, 충분히 대응할 수단이 있거나, 또는 다른 언어에서와 같이 납득할 수 있는 이유로 생겨난 차이 정도만 있다고 보는데, 말씀하신 인력 문제... 이게 사실상 제일 큰 문제가 아닐까 싶네요.
PHP를 진지하게 사용할 수 있는 개발자들은 이미 오래전의 PHP에 학을 떼고 PHP에서 탈출한 지 오래고,
남아있는 대부분의 사용자들은 PHP가 아무리 발전해도 제대로 봐 주지 않는, 또는 제대로 봐 줄 여력이 되지 않는 사람들...
PHP가 적합하다 생각하는 MVP+a 의 프로젝트엔 전자의 경력자들이 참여할 이유가 없고,
설령 참여한다고 해도, PHP를 선택하지 않거나, PHP를 선택하더라도 후자의 유저가 한두명 끼는 순간 엉망진창이 될거라...ㅋㅋ
적어도 국내에선 만족스러운 PHP 개발 가능 인력을 구하는 것 자체가 쉽지 않네요.
그렇게 또 PHP는 선택지에서 제외되고, 더더욱 평균적인 인력 수준이 낮아지고, 그게 무한 반복되며 악순환을 만들어 나가는 것 같습니다.
~~이렇게라도 계속 약을 팔아 소규모 1~3인 프로젝트에서만이라도~~ 제대로 된 PHP 프로젝트를 시도하는 케이스가 늘어나야 악순환이 끊기지 않을까 생각합니다.
그러는 저도 사실 PHP가 만들어주는 수익이 그리 크지는 않네요. 만족스러운 인력 수급이 너무 힘드니까 PHP를 메인 스택으로 가져갈래야 가져갈 수 없는 현실...
옛 기억을 더듬어보니 최소한 slim twig 조합만 보편화되어 있었어도 프로젝트에서 했던 PHP 실수들을 줄일 수 있었을 것 같습니다. 물론 다른 PHP 개발자들이 PHP 날코딩에 익숙해 있었기 때문에 그 당시에는 도입할 수 없었구요. 다행히 PDO는 표준 라이브러리에 있어서 SQL 인젝션에 대한 대비는 할 수 있었습니다
원 댓글에서 언급하신 버그 영향도 제한이나 처리성능에 대해서는 딱히 부정이나 긍정 의견이 없습니다. 있으면 좋은 기능이라고는 생각합니다만, 처리량 폭증이나 메모리 사용량 문제는 성장단계에서 최소 한번은 고민해야할 문제이기 때문에 그런 문제가 명시적인 형태로 가능한 빨리 나오면 좋다고 생각합니다