목차
발표자 소개
프레임워크 필요성
PSR 표준과 의존성 관리자(Composer)
Laravel 소개 및 장/단점
Laravel 프로젝트 시연
QnA

발표자
 정광섭
 C/C++, Java, PHP,
 http://lesstif.com, http:/github.com/lesstif
 애자일, 협업 도구 및 프로세스, 이슈 및 지식 관리,
자동화를 통한 프로젝트 성공이 주 관심사.
 닭은 좋아하지만 튀기진 못 할 것 같아서
개발 관련 직무로 사회 생활 지속 소망
 “리눅스를 활용한 회사 인프라 구축의 모든 것” 저자
 현재 “쉽게 배우는 라라벨 5 프로그래밍(가칭)“ 저술중
 https://www.lesstif.com/x/i4C0AQ에 원고 공개중

프레임워크 정의
 "소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재
사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공
하는 것“ – Ralph Johnson
 라이브러리와 달리 애플리케이션의 틀과 구조를 결정하고 그
위에 개발된 개발자의 코드를 제어

프레임워크 필요성 - #1
 서비스의 복잡도 증가, 보안, 대용량 처리, 외부 서비스 연계 등
고려 사항 많음
 단순/반복 작업 최소화, 코드 재사용, 팀원과 원활한 협업 가능
및 구현하려는 본질에 집중 가능
 하지만 의도된 제약 사항으로 인해 customizing 시 어려울 수
있음
 확장성, 안정성, 사용자층, 프레임워크가 제시하는 문제 해결
방식이 적절한지 고려 후 선정 필요

프레임워크 필요성 - #2
 복잡한 비즈니스와 변화에 대응하기 위해서는 프레임워크와
패턴, 개발 방법론 도입이 필요

PHP 패러다임 변화
 Class 키워드가 있는 무늬만 객체지향에서
진정한 객체지향 언어로 성장(5.x)
 동적 메소드/프로퍼티 생성(5.0 - Overloading)
 NameSpace (5.3)
 Trait (5.4)
 Closure(5.4) 등 새로운 기능 도입

PSR(PHP Standards Recommendations)
 PHP-FIG(Framework Interoperability Group) 에서 제정하는 표준
 표준화 부재로 인한 프레임워크/라이브러리간 호환 문제 발생
 PHP 언어와 프레임워크를 더욱 유연하고 상호 운용 가능하도록
사실상의 표준을 제정
 현재 5개의 표준이 통과
 PSR-0 Autoloading Standard => PSR-4 로 대치
 PSR-1, 2 Coding Style Guide
 PSR-3 Logger Interface
 PSR-4 Autoloader
 PSR-7 HTTP Message Interface

PSR-2 - Coding Style Guide

 탭 대신 SPACE 4
 닫는 태그(?>) 사용하지 말 것
 클래스 구문의 여는 괄호는 다음 줄에 사용하고 닫는 괄호는 본문 다음 줄
에 사용
=> Civil war 종료?
 else if 대신 elseif 사용
 기타 등등…
 PSR-1,2 검사 툴 - https://github.com/FriendsOfPHP/PHP-CS-Fixer
PSR-2 - Coding Style Guide

PSR-2 - 예제

패키지 관리 - Don’t Invent Wheel
 해결해야 하는 문제 자체에 집중
 도구가 필요할 경우 기존 개발 여부 확인
 자체 개발 라이브러리보다는 검증된 외부 라이브러
리 사용
 NIH(Not Invented Here) 신드롬 주의

패키지 관리 – 문제 #1
 라이브러리 설치/관리 문제
 ‘A’ Project 에서 사용하는 Hello 는 5개의
추가 lib 설치 필요
Project A
Hello 1.0
World 2.8Foo 2.1
Bar 4.1 Qux 2.3 Baz 1.3

패키지 관리 – 문제 #2
 의존성 지옥(Dependency Hell) – Hello 1.1 업그레이드후
Project A
Hello 1.1
World 3.0Foo 2.2
Bar 4.1 Qux
2.3
Baz 1.3
의존성 지옥
3.1

Composer
 기존의 pear 을 대체하는 PHP 용 패키지 관리자
 Npm(Node.js), Bundler(Rails), maven,gradle(java)와 동
일한 역할 수행
 간편하고 편리한 사용 제공

패키지 관리 – Composer의 해결책 #1
 손쉬운 패키지 설치/관리
composer require phpunit/phpunit “~4.8”
composer install
composer update
composer remove phpunit/phpunit

패키지 관리- Composer의 해결책 #2
 Semantic Versioning 에 따른 의존성 관리
이름 예제 의미
정확한 버전 1.0.1 버전 1.0.1과 일치하는 버전
범위 지정(Range) >=1.0 1.0 보다 크거나 같은 버전중 마지막 버전.
2.0, 3.1 도 포함
>=1.2 <2.0 1.2 보다 크거나 같고 2.0 보다 작은 버전중
마지막 버전
물결(~ Tilde) 연산자 ~1.2 바로 위(>=1.2 <2.0)와 동일한 의미
OR 연산자 1.2.3 | 1.3.4 1.2.3 또는 1.3.4
와일드카드 연산자 1.0.* 1.0.x 대중 가장 큰 버전으로 1.1 보다는
작은 버전. >= 1.0 < 1.1 과 동일
삽입 기호(^ Caret) 연산자 ^1.2.3 >=1.2.3 <2.0 와 동일
http://jubianchi.github.io/semver-check/
 Online Semantic Version check

패키지 관리- Composer의 해결책 #3
 방대한 온라인 저장소
 http://www.packagist.org
 http://packalyst.com/

Laravel 프레임워크
 Taylor Otwell 에 의해 개발
 2011 6월 최초 버전 발표, 2015년 10월 5.1.19 발표
 “Freeing you from spaghetti code” – V2 릴리스 후
 PHP 언어 의 최신 기능을 극한까지 활용한 Modern Framework
 Ruby on Rails 못지 않게 편리하고 우아한 코드 작성 가능
 PSR 표준 수용, Composer 적극 활용,
 Symphony 프레임워크의 검증된 컴포넌트 차용 등 PHP 커뮤니티와 생태계 적극
활용 (http://symfony.com/projects/laravel)
 “PHP 로 개발하면 관리가 불가능한 코드가 양산된다”는 선입관을 날릴 수 있는
잘 만든 프레임워크

github star 비교 – PHP Framework

github star 비교 – 타 언어

Laravel 단점 #1
 최신 버전의 PHP 요구(Laravel 5.1 은 PHP >= 5.5.9 이상 필요)
 국내 웹 호스팅은 PHP 버전 제약 있음
 학습 곡선이 길다.
 함수 매뉴얼 보고 코딩하는 기존 개발 방법에 비해 어려움
 PHP 5, 객체 지향, 디자인 패턴(일부)에 대한 이해 필요
 실행 속도가 느리다.
 타 PHP 프레임워크(CI, phalcon) 에 비해 느림
 실행속도보다 개발 생산성이 증가하고 변화에 탄력적이므로 용도에 맞게 선정
 Ex: 사용자 증가로 DB 분산 처리(읽기/쓰기 분리), 파일 저장을 AWS S3로, 세션 처리
를 Redis 로 할 경우 app 변경이 고통스럽지 않음

Laravel 단점 - #2
 한글 자료 부족
 젊은 프레임워크(4년)라 사용자 층이 얇음, 현재 국내 출판 도서 1권(번역본)
 XE 3 발표 및 레퍼런스가 늘어나고, 사용자 증가하면 해결 가능
 너무 빠른 버전업 및 하위 호환성 부족
 새 버전 출시 주기가 빠르고 기존 버전 지원 기간이 짧음
 5.1 LTS(Long Term Support - 2년 지원, 3년 보안 패치) 버전 출시로 어느 정도
해소 예정

특징 – MVC #1
디자이너 개발자
코드 + 디자인
변경이
어려움
기능을
수정해야
하는데..
디자인을
수정해야
하는데..

특징 – MVC #2
사용자
Controller
View
Model
웹 애플리케이션
①요청
②호출
③결과반환
④ 호출 및 모델 전달
⑤ 참조
⑥응답

특징 – MVC #3
M
C
V

특징 – 쉽고 가벼운 템플릿 엔진(blade)
name : jason
email: jason@abc.com
Age : 20
………………
Model View Template
Blade Engine

특징 – 우아하고 미려한 문법

특징 – URL 라우팅
/
/hello
/book
Route
(Front Controller)
R
e
q
u
e
s
t
homeIndex()
helloAction()
bookAction()
 /user/register 처리 소스가 /var/www/myserver/user/register.php 가 아님
 파일 시스템과 매칭되지 않고 전체 app 의 동작을 제어

특징 – 쉬운 DB 코딩 #1 – Query Builder

특징 – 쉬운 DB 코딩 #2 – ORM

특징 – 쉬운 DB 코딩 #3 – ORM

특징 – 미들웨어(MiddleWare) #1
 라라벨 4 => 필터(filters), 5 에서 미들웨어로 변경
 보통 App 보다 먼저 실행
 매번 실행되므로 전체적인 서비스 속도 저하 => 단점
 매번 실행되므로 app 실행전/후에 필요한 공통 기능 추가 쉬움 => 장점
AppAppRequest ResponseApp
Authentication
VerifyCsrfToken
EncryptCookies

특징 – 미들웨어(MiddleWare) #2

특징 – 손쉬운 개발 환경 구축 #1
 개발 환경 구축시 벌어지는 야크 털 깍기(Yak Shaving)는 그만!
 어떤 APM(EasyPHP, WAMP, XAMPP, Apm_setup, AutoSet….) 설치?
 Apache http 에 새로운 가상 호스트를 추가하는 방법은?
 운영 환경은 nginx 를 사용하는데 ?
 PHP 의 mbstring extension 을 활성화하려면?
 디자이너와 퍼블리셔도 개발 환경을 꾸미려면?

특징 – 손쉬운 개발 환경 구축 #2 Homestead
Guest OS(Ubuntu)
홈스테드
가상 하드웨어
(CPU, Memory, Disk)
Hypervisor(VirtualBox)
 VirtualBox + Vagrant
 가상 머신 기반하의 개발 환경 패키지
 개발에 필요한 모든 환경(Linux, nginx,
PHP, DBMS, Redis)가 자동 설치
vagrant box add
laravel/homestead
vagrant up
vagrant halt

특징 – 보안성
 최근 P사의 사태 - 보안은 자사의 비즈니스를 보호하기 위한 핵심 요소
 직군과 상관없이 보안의 중요성 인식 필요
 개발자는 시큐어 코딩(Secure Coding) 으로 안전하고 견고한 app 개발 필요
 89년 국내 모 잡지

특징 – 보안성(XSS; Cross Site Script)
 사용자의 입력(게시판등)을 화면에 출력할 경우 새너타이징 필요
 Blade 의 기본 출력 메소드 : {{ $var }} 에서 자동 새너타이징
&lt;
<
ㅅ
&gt;
>
alert( &quot;
‘
Welcome &quot;
‘
); &lt;
<
script script &gt;
>
새너타이징

특징 – 보안성(SQL Injection) - #1

특징 – 보안성(SQL Injection) - #2
 모든 쿼리는 PDO를 사용하며 Prepared Statement 와 Bound Parameter를 통해
안전하게 처리 – 기본 동작
aaa' or '1' = '1 를 입력해도 password 컬럼 값이 aaa' or '1'='1' 인 레코드를 찾게 됨

특징 – 보안성(CSRF 공격 방지)
 데이터를 변경하는 HTTP 요청(POST/PUT/PATCH/DELETE)는 CSRF(Cross-Site
Request Forgery) 토큰 적용(기본 동작)
 CSRF 에 대한 이해가 없을 경우 app 미동작으로 인한 두통을 유발할 수 있음
 개발자의 두통은 시큐어 코딩 습득 및 보안 강화로 인한 비즈니스 보호로 승화

특징 – Artisan Command
 라라벨 app 를 다루기 위한 명령행 유틸리티
 Ruby on Rails 의 rails 명령어와 같은 기능 수행
 스캐폴딩(Model, View, Controller, 기타 프레임워크 기능) 제공
 DB 마이그레이션 생성 및 적용/롤백
 App 정비 상태로 전환등

특징 – DB Migration #1
 DB 스키마 파일은 버전 관리 가능(Ex: myschema.sql)
 DBMS 가 현재 어떤 버전의 스키마가 적용되었는지는 관리 불가
 변경시 DB 스키마 관련 실수는 자주 발생하며 잦은 변경 전략의 주요 장애물

특징 – DB Migration #2
 DB 수정시 스키마 파일을 건마다 생성
 변경 내역은 DBMS 의 명령어가 아닌 라라벨의 별도 명령어 사용
 스키마 변경 이력은 DBMS 의 메타 테이블(migrations) 를 통해 관리
php artisan make:migration add_phone_column_on_users --
table=users
php artisan migrate

특징 – Model Factory
 App 개발/테스트시(sql 검색문, paging, view 개발등) 테스트 데이터 필요
 테스트 데이터는 어느 정도 의미 있어야 하지만 이런 데이터 생성에 시간을 투
입할 수는 없음
 factory 를 통해 적당히 의미 있는 데이터를 쉽게 생성

특징 – 설정보다 관례 패러다임
 Coc; Convention over Configuration
 유연한 App 를 위해서는 설정을 통한 동작 제어 필요
 복잡한 설정대신 거의 모든 설정은 관례에 의거하여 생략

특징 – 설정보다 관례 #2
관례를 알아야 하는 문제 발생!
테이블 모델 클래스 기본키 컬럼 생성일 컬럼 갱신일
Users User id created_at updated_at
Article_Categories ArticleCategory id created_at updated_at
login URL 로그인후 이동 URL
/auth/login /dashboards

특징 – 설정보다 관례 #3

특징 – IoC Container
 클래스의 의존성을 관리하는 강력한 도구
 DI(Dependency Injection) 을 통해 클래스들의 의존성 제거
 필요한 의존성은 IoC Container 에 의해 런타임에 주입
 라라벨은 IoC 대신 Service Container라 부름

특징 – IoC Container #2

특징 – IoC Container #3

특징 – 파사드(Façade)
 Service Container(IoC) 에 대해 Proxy 접근
 Static 메소드(Cache::get)처럼 사용 가능하므로 new 로 생성할 필요 없음
 사용이 쉬우면서 Static 의 단점인 mock 객체를 만들기 어려운 문제 해결

Todo Service 만들기
cd ~/Code
composer create-project laravel/laravel mytodo.app
cd mytodo.app
sudo serve mytodo.app /home/vagrant/Code/mytodo.app/public
vagrant up
ssh vagrant@192.168.10.10

참고 자료 & QNA
 Laravel 홈 페이지 - https://laravel.com
 라라벨 한국어 매뉴얼 - http://xpressengine.github.io/laravel-korean-docs/
 Laracast 온라인 강의 - https://laracasts.com/
 Laravel 한국 사용자 모임 - http://laravel.co.kr
 컴포저 한국어 매뉴얼 - http://xpressengine.github.io/Composer-korean-docs/
 Laravel 자료 모음 - https://github.com/chiraggude/awesome-laravel
 발표자 블로그의 도서 공개 - https://www.lesstif.com/x/i4C0AQ 참고
 Q&A

감사합니다.