이전 회사에서 레거시 API를 REST하게 바꾸려는 노력을 했었는데요, 실제 코드를 보면서 확인해 보겠습니다. 아래는 훈련인증서(Certificate)를 CRUD 하고 훈련인증서를 고객의 이메일로 전송해주는 API들입니다. API URL 코드는 PHP/Laravel 을 기반으로 만들어졌습니다.

Before (개선전)

Before 코드를 확인해보면, 다음과 같은 점이 잘못됐다고 볼 수 있습니다.

1. URI에 자원에 대한 행위가 포함 되어 있다. (update, edit, show, delete)
2. /certificate-edit은 자원에 대한 행위가 Edit인데, HTTP Method는 GET으로 구현이 되어 있다.
3. 마지막줄의 Route::post('/certificate', 'CertificateController@sendMailCertificate'); 같은 경우에는 고객에게 Mail을 보내는 API인데 URI만 보아서는 어떤 동작을 하는지 추론하기 어렵고, 오히려 certificate를 create 하거나 update 하는 행위로 보여진다.
4. 복수형을 사용하기보다 단수형을 사용했다.
5. /certificate-update, /certificate-edit이 서로 어떤 다른 동작을 하는지 알 수 없다.

After (개선후)

개선은 위의 잘못된 점을 바탕으로 진행하였습니다.

[POST] /certificate-update => [PUT] /certificates -> Admin의 인증서 생성 또는 업데이트 하는 API [GET] /certificate-show => [GET] /certificates -> Admin의 인증서 정보를 가져오는 API [DELETE] /certificate-delete => [DELETE] /certificates -> Admin의 인증서를 지우는 API [POST] /certificate => [POST] /users/{user_id}/send-mail -> Admin에게 속한 {user_id}에게 Admin의 훈련 인증서를 전송하는 API

이제 REST API라고 부를 수 있을까?

개선 후의 코드는 확실하게 개선전의 코드보다 REST API 설계 원칙을 잘 따르고 있다고 보여집니다. 이제 REST API라고 부를 수 있을까요?

REST 제약조건들 중 가장 지켜지지 않는 것은 Uniform Interface인데, 이중에서도 self-descriptive messages와 HATEOAS가 가장 지켜지지 않는다고 합니다. [GET] /certificates 를 Postman을 활용해 직접 호출한 뒤 self-descriptive messages와 HATEOAS를 따져보겠습니다.

BODY

HEADER

Self-descriptive

1. Response Header의 Content-Type을 확인하여 media type(application/json)을 알 수 있습니다.
2. 명세에는 json 문서가 나타나있기 때문에 json 문서를 파싱하는데 성공합니다.
3. 하지만 Body의 "id", "client_id", "type"등 키값이 무엇을 의미하는지 알 수 없습니다.
4. 결론적으로 Self-descriptive 하지 못하기 때문에 완벽한 REST API가 아닙니다. ❌

HATEOAS

1. HATEOAS 원칙에 따라서 다음 상태로 전이할 링크를 찾습니다.
2. 전이할 링크가 JSON response안에 포함 되어 있지 않습니다.
3. 결론적으로 HATEOAS 원칙을 지키지 못했기 때문에 완벽한 REST API가 아닙니다. ❌

꼭 Self-descriptive와 HATEOAS를 지켜야 하는가?

로이 필딩은 REST의 제약조건을 한개라도 지키지 않는다면 REST API라고 부를 수 없다고 본인이 직접 밝혔습니다. 우리는 Self-descriptive와 HATEOAS를 포함한 REST 제약조건을 정확히 지킨 REST API를 만들지, 아니면 구색만 갖춘, 사실 REST API가 아닐지도 모르는 API를 설계하고 REST API라고 부를지 정해야할 것 같습니다. 사실 대부분의 서비스에서는 암묵적으로 Self-descriptive와 HATEOAS가 빠져도 REST API라고 칭하고 있는 것 같습니다. 그럼에도 로이필딩은 이러한 API를 REST API가 아닌 HTTP API 라고 불리길 바랍니다.

꼭 REST API 여야만 하는가? (REST API의 단점)

로이필딩은 시스템 전체를 통제할 수 있다고 생각하거나 진화에 관심이 없다면 REST에 대해 따지느라 시간을 낭비하지 말라고 했습니다. 그리고 REST에는 다음과 같은 단점들이 존재합니다.

✅ 1. 안티패턴으로 설계될 가능성

REST API에 대해 이해도가 떨어질 경우 구색만 갖춘, REST 사상에 어긋나는 API를 설계할 수도 있는 가능성이 있습니다.

✅ 2. 표준 규약이 없는 점

사실 REST는 표준이 없습니다. REST 아키텍처는 사실 암묵적인 규칙(Defector reference)이며, 이로 인해 안티패턴의 형태로 발전하는 경향도 커지고 있습니다.

✅ 3. RDBMS의 표현에 적합하지 않은 점

RDBMS는 다양한 키들이 존재하는데, REST API는 리소스를 표현할 때 나열하기 용의한 형태(ex: JSON)를 사용하기에 RDBMS에는 표현이 적합하지 않을 수도 있습니다.

이러한 단점들을 개선한 통신 규약으로는 GraphQL이 있습니다. 하지만 아직까지는 REST API가 더 많이 사용되며, GraphQL도 장단점이 명확히 존재하니 상황에 맞춰 적절한 통신 규약을 선택해야 합니다.

끝으로

REST API는 HTTP 통신을 기반으로 하는 개발에서 정말 중요하다고 생각합니다. 이번 블로그 글의 작성 겸험을 바탕으로 REST API를 REST 원칙에 어긋나지 않도록 설계할 수 있을 것 같습니다 🙆🏻‍♂️ 이 글은 아주 유명한 영상인 그런 REST API로 괜찮은가(https://www.youtube.com/watch?v=RP_f5dMoHFc)의 영향을 많이 받았습니다.

REST란

REST는 REpresentational State Transfer(자원의 표현에 의한 상태전달)의 약자입니다. REST는 2000년도에 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 공개되었습니다. 로이 필딩은 HTTP의 저자 중 한 사람인데, HTTP 설계의 우수성에 비해서 제대로 사용하지 못하는 모습에 REST 아키텍처를 개발하게 됐습니다. 로이 필딩이 REST를 개발할 당시 WEB은 이미 빠른 발전을 이룬 상태였고, REST로 인해 WEB이 망가지지 않도록 독립적으로 만드는 것에 힘을 쏟았다고 합니다. 이러한 노력들이 REST 안에 잘 녹아들어가 있습니다.

🙆🏻‍♂️ REST는 자원을 정의하고 자원에 대한 주소를 지정하는 방법의 전반을 일컫는 아키텍처 중 하나이며, REST의 정의는 로이 필딩의 논문에서 다음과 같이 명시되어 있습니다.

REST : 분산 하이퍼미디어 시스템(ex:web)을 위한 아키텍쳐 스타일

웹같은 분산 하이퍼미디어 시스템을 위한 제약조건의 집합이라는건데, 이는 다음과 같습니다.

REST를 구성하는 스타일(제약조건들)

1. Client-Server

✅ Server와 Client의 역할을 확실하게 하여 의존성 줄이기

Server는 API 제공, Client는 세션, 로그인 정보등 Client단에서 관리할 수 있는 것들을 관리합니다. 각각의 역할이 확실하게 구분되기 때문에, Server와 Client에서 개발할 내용이 명확해집니다. 또한 이는 서로간의 의존성을 줄여주는 이점을 줍니다.

2. Stateless (무상태성)

✅ 상태정보를 저장하지 않음으로서 구현을 단순화시키기

상태정보를 저장하거나 관리하지 않습니다. 세션 정보나 쿠키 정보를 별도로 저장하거나 관리하지 않기 때문에 서버는 단순하게 들어오는 요청만 처리하면 됩니다. 이로 인해 애플리케이션의 자유도가 높아지고, 서버에서 불필요한 정보를 관리하지 않음으로 구현이 단순해집니다.

3. Cache (캐시)

✅ 캐싱 기능이 가능한 REST

HTTP 웹표준을 그대로 사용하기 때문에 웹의 인프라를 그대로 사용 가능하며, Client-Server 간에 캐싱 기능 적용이 가능합니다. HTTP 표준에서 사용하는 Last-Modified태그, E-Tag를 이용하면 캐싱 구현이 가능합니다.

4. Uniform Interface

✅ HTTP 표준을 따르는 환경이라면, 언어와 플랫폼에 상관없이 사용할 수 있는 인터페이스 스타일

URI를 사용해서 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일(제약조건의 집합)을 말합니다. Uniform Interface의 제약 조건은 4가지가 있습니다.

1. Identification of resources
   ❗️리소스가 URI로 식별된다.
2. Manipulation of resources through representations ❗️리소스를 CRUD할 때 HTTP에 표현을 담아야 한다.(GET, POST, PUT, DELETE)
3. Self-descriptive messages ❗️메세지는 스스로를 설명할 수 있어야 한다.
4. Hypermedia as the engine of application state (HATEOAS) ❗️애플리케이션의 상태는 항상 Hyperlink를 이용해 전이되어야 한다.

5. Layered System

✅ 다중 계층 구성을 지원하여 중간 매체 사용이 가능하게 하기

REST 서버는 다중 계층으로 구성될 수 있으며, 보안, 로드밸런싱, 암호화 계층을 추가하여 구조상 유연성을 가질 수 있습니다. 또한 Proxy, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있게 합니다.

6. Code-On-Demand(optional)

✅ feat. JS

요청을 받으면 Server에서 Client로 실행 가능한 코드를 전송하여 클라이언트의 기능을 확장할 수 있는 기능입니다. (Javascript)

REST의 구성 요소

1. 자원(Resource) : HTTP URI

모든 자원은 URL를 가지고 Client는 자원의 상태를 조작하기 위해 URL로 요청을 보냅니다.

2. 행위(Verb) : HTTP Method

Client는 URI를 이용해 자원을 조작하기 위해 HTTP Method(GET, POST, PUT, DELETE 등)를 사용합니다.

3. 표현(Representations) : HTTP Message Payload

Client가 Server로 Request를 보냈을 때 서버가 Response로 보내주는 자원의 상태를 Representations라고 합니다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있습니다.

REST API

앞에서 설명한 REST의 구성하는 스타일과 구성요소를 기반으로 서비스 API를 구현한 것을 REST API라고 합니다. 그렇기 때문에 각 요청이 어떤 동작이나 정보를 위한 것인지 그 요청의 모습 자체로 추론할 수 있어야 합니다. (Uniform Interface) OpenAPI를 제공하는 기업의 대부분은 REST API를 제공합니다.

REST API 설계

🙆🏻‍♂️ REST API를 설계하는 방법은 다음과 같습니다.

1. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현해야하며 URI에 포함되어서는 안됩니다.

❌ BAD [DELETE] http://localhost:8080/delete/users/3 ⭕️ GOOD [DELETE] http://localhost:8080/users/3

2. URI 는 명사를 사용해야합니다. (컨트롤 자원을 의미하는 경우 예외적으로 동사를 허용하기도 합니다.)

❌ BAD [GET] http://localhost:8080/getUsers ⭕️ GOOD [GET] http://localhost:8080/users

3. 슬래시 / 를 활용해서 계층관계를 표현합니다.

⭕️ GOOD [GET] http://localhost:8080/users/3

4. 밑줄 _ 을 사용하지 않고 하이픈 - 을 사용합니다.

❌ BAD [GET] http://localhost:8080/blogs/this_is_example ⭕️ GOOD [GET] http://localhost:8080/blogs/this-is-example

5. URI는 소문자로만 구성합니다.

❌ BAD [GET] http://localhost:8080/USERS ⭕️ GOOD [GET] http://localhost:8080/users

6. 파일확장자는 URI에 포함하지 않습니다.

❌ BAD http://localhost:8080/photo.jpg

7. URI의 마지막은 슬래시를 포함하지 않습니다.

❌ BAD [GET] http://localhost:8080/users/ ⭕️ GOOD [GET] http://localhost:8080/users

8. URI는 복수형을 사용하는게 좋습니다.

❌ BAD [GET] http://localhost:8080/user/3 ⭕️ GOOD [GET] http://localhost:8080/users/3

끝으로

REST API란?(2) - 개선사례편(https://velog.io/@seo_kk/REST-API%EB%9E%80-%EA%B0%9C%EC%84%A0%EC%82%AC%EB%A1%80%ED%8E%B8)에서는 이러한 설계원칙을 바탕으로 직접 사내서비스를 개선해 보았던 사례를 담고 있습니다.

OAuth 와 JWT 의 차이점을 비교하는 사람들이 많지만, 사실 이는 잘못된 이야기입니다. OAuth는 하나의 Framework이자 프로토콜(Protocol)이고 JWT는 토큰의 형식들 중 하나이니까요.

** OAuth는 토큰을 요청하는 요청 및 응답의 순서와 형식을 가지고 있으며, JWT는 이러한 OAuth의 과정에서 발생하는 하나의 산물이라고 볼 수 있습니다. **

그렇다면 OAuth는 무엇이고, JWT는 무엇이며 왜 사용할까요?

OAuth

❓OAuth

예전에는 개인정보를 여러 곳에 입력하면서 보안이 불안해지고, Application이 안전하다는 보장이 없었습니다. 이러한 문제를 보완하기위해서 Twitter는 2007년에 OAuth 1.0을 만들게 됩니다.

OAuth를 간략하게 설명해보자면, 간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 행위로 볼 수 있습니다.

• 인증 : 인증이란 시스템의 접근을 확인하는 것입니다. 로그인 같은 것이 이러한 행위라고 볼 수 있습니다.
• 권한 : 권한의 권리를 검증하는 것입니다. HTTP의 특성 중 하나인, "상태를 저장하지 않는다"(stateless) 를 보완하기 위해 권리를 검증해야 합니다.

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. (위키백과)

OAuth는 우리가 사용하는 환경에서도 많이 찾아볼 수 있습니다. (카카오톡 로그인, 구글 로그인 등)

OAuth를 이용해서 인증하는 과정을 OAuth Dance라고 하며, OAuth Dance를 다음과 같이 표현할 수 있습니다.

이렇듯 OAuth는 Consumer (Oauth 인증을 사용해 Service Provider의 가능을 사용하려는 쪽)가 Service Provider (OAuth를 사용하는 Open API를 제공하는 서비스) 의 기능을 사용하기 위해 AccessToken을 발급받는 과정입니다.

OAuth를 사용하면 여러 서비스 제공자의 API를 신뢰할 수 있는 방법으로 사용할 수 있다는 것으로 해석해볼 수 있겠죠?

❓OAuth 1.0

처음 개발 되었던 OAuth 1.0은 문제를 가지고 있었습니다.

• 절차가 복잡하여 구현이 복잡하다. (서비스 프로바이더에게 연산 부담이 발생한다.)
• 웹이 아닌 Application의 지원이 부족하다.
• HMAC을 통해 암호화를 하는 번거로운 과정을 겪는다. (HMAC란 해싱 기법을 적용하여 메시지의 위변조를 방지하는 기법)
• 인증 토큰(Access token)이 만료되지 않는다.

그래서 이러한 단점들을 보완하기 위해 OAuth 2.0이 탄생하게 됩니다.

❓OAuth 2.0

그렇다면 OAuth 2.0은 어떻게 보완되어 탄생했을까요?

• Siganature 단순화 정렬과 URL 인코딩이 필요 없도록 만들었다.
• 웹 뿐만 아니라 Application에 지원을 강화했다.
• 암호화가 필요 없다. HTTPS를 사용하며, HMAC를 사용하지 않는다.
• 인증 토큰(Access token)에 Life-time을 지정할 수 있도록 했다.

이 외에도 OAuth 2.0에서 사용하는 용어 체계는 OAuth 1.0과 완전히 다르다고 합니다. 목적만 같고 다른 프로토콜이라고 볼 수 있는 것이죠.

이제 OAuth 과정에서 생성되는 Token의 종류 중 하나이며 가장 자주 사용되는 JWT에 대해서 정리해보겠습니다.

JWT

❓Token 기반 인증

HTTP 방식의 통신에서 쿠키나 세션을 이용한 인증보다 보안성이 강하며 효율적이라고 평가받는 인증은 바로 토큰 기반 인증입니다. 토큰 기반 인증은 사용자가 자신의 아이덴티티를 확인한 뒤 고유한 Access토큰을 받을 수 있는 프로토콜을 말합니다. JWT는 토큰 기반 인증 프로토콜에서 가장 대표적인 토큰입니다.

❓JWT

Json Web Token의 약자로 전자 서명 된 URL-safe(URL로 이용할 수 있는 문자로만 구성된 것인데, URL에서 파라미터로 사용할 수 있도록 하기 위함)의 JSON 입니다. JWT는 자가수용적(self-contained)이라는 특징을 가지고 있는데, 이는 JWT가 필요한 모든 정보를 자체적으로 가지고 있다는 것을 뜻합니다. JWT 토큰은 3가지 구조로 나뉘어 있습니다.

• 헤더(header)

  • 토큰의 타입정보가 들어가있습니다.
  • 해시 알고리즘 정보가 들어가있습니다.
  • 헤더의 내용은 BASE64 방식으로 인코딩해서 기록됩니다.
  • 헤더를 디코딩 한 모습을 다음과 같이 볼 수 있습니다.

    {
    "typ": "JWT",
    "alg": "HS256"
    }

• 내용(payload)

  • 토큰에 담을 정보가 들어가 있으며, 이 정보의 한 조각을 클레임이라 부릅니다.

  • 총 3가지 클레임을 조합하여 BASE64 인코딩된 정보입니다.

    • 등록된 클레임 (registered)
      • 토큰 발급자(iss), 토큰 제목(sub), 토큰 대상자(aud), 토큰의 만료시간(exp)
    • 공개 클레임 (public)
      • 충돌을 방지하기 위한 URI 형식의 이름
    • 비공개 클레임 (private)
      • 양 측(클라이언트, 서버)의 협의하에 사용되는 클레임

  • 인코딩 전 종합한 모습을 다음과 같이 볼 수 있습니다.

    {
    "iss": "seo_kk.com",        // 등록된 클레임
    "exp": "1485270000000",     // 등록된 클레임
    "https://seo_kk.com/jwt_claims/is_admin": true,    // 공개 클레임
    "userId": "11028373727102",    // 비공개 클레임
    "username": "seo_kk"        // 비공개 클레임
    }

• 서명(signature)

  • JWT가 원본 그대로라는 것을 확인할 때 사용합니다.
  • 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호코드입니다.
  • 별도생성된 JWT secret을 헤더에 지정된 암호 알고리즘으로 암호화한 것입니다.
  • 헤더(base64인코딩) + 페이로드(base64인코딩) + SECRET_KEY 를 사용하여 JWT를 발급하는 백엔드 서버에서 발행됩니다.

생성된 JWT는 이러합니다.

이렇게 생성된 JWT는 다음과 같은 Process를 가집니다.

JWT Process

그림으로 표현하면 다음과 같이 볼 수 있습니다.

이렇게 JWT의 Process를 알아 보았습니다.

세션기반 인증, 쿠키기반 인증보다 효율적이라고 하지만 분명히 장단점은 존재하겠죠? JWT의 장단점에는 무엇이 있을까요?

JWT의 장점

• JWT는 사용자 인증에 필요한 모든 정보를 토큰에 포함하기 때문에 별도의 인증 저장소가 필요합니다.
• 쿠키를 사용하지 않아도 되기에 쿠키 사용으로 인한 취약점이 해결됩니다.
• URL 파라미터와 헤더로 사용하기에 편리합니다.
• 트래픽에 대한 부담이 낮습니다.
• REST 서비스로 제공 가능합니다.
• 만료기한이 내장되어 있습니다.

JWT의 단점

• JWT는 토큰 자체에 사용자 인증에 필요한 정보를 담고 있기 때문에 정보를 완전히 차단하고 있다고는 어렵습니다.
• 정보를 담는 Payload에 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있습니다.
• Payload 자체는 암호화된것이 아니라 BASE64로 인코딩 된것이기에, JWE로 암호화 하거나 중요 데이터를 Payload에 넣으면 안됩니다. 중간 탈취자가 디코딩할수도 있기 때문이죠.
• JWT는 stateless(상태를 저장하지 않는다)이기 때문에, 토큰을 임의로 삭제하는 것이 불가능합니다. 그렇기에 토큰 만료시간을 꼭 넣어주어야 합니다.
• 토큰을 Client 측에서 저장해야 합니다.

정리

OAuth와 JWT는 많은 Application에서 사용하고 있다고 알고 있습니다. 저도 개발을 진행하면서 JWT를 사용하고, OAuth를 자주 사용했습니다. 하지만 "왜 사용하는지, 어떻게 동작하는지" 에 대해서는 정확히 인지하지 못하고 사용했습니다. 자료들을 찾아보면서 HTTP의 상태를 저장하지 않는 성질에 대한 측면, 사용자의 편의, 보안성에서 굉장히 효율적이라는 생각을 했고 앞으로의 서비스들에서 사용하는 이유에 대해 명확하게 인지하고 사용할 수 있는 계기가 되었습니다.

📚 참고

• https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html
• https://d2.naver.com/helloworld/24942
• https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
• https://gorokke.tistory.com/181

라라벨(Laravel)은 PHP 기반의 web framework 중 하나입니다. 모델-뷰-컨트롤러(MVC) 아키텍처 패턴을 따르고 있으며, 최고의 PHP 프레임워크라고 불립니다. 세계에서도 많은 인기를 끌고 있는 프레임워크입니다.

Laravel의 장단점

그렇다면 라라벨을 사용하는 이유에는 무엇이 있을까요?

그 이유는 다음과 같습니다.

장점 

- 많은 기능을 포함하여 빠른 개발 속도
- 거대한 커뮤니티
- 데이터 베이스 작업시 ORM인 Eloquent를 제공하여 편한 DB 연결
- PHP 패키지 매니저인 composer를 지원
- 간결하고 기억하기 쉬운 문법을 제공하는 파사드 패턴

이런 이유들과는 다르게, 라라벨의 단점이라고 불리우는 이유들도 있습니다.

단점

- 많은 기능을 포함하고 있기에 다른 프레임워크에 비해서 느린 속도
- PHP에 대한 부정적인 시선들

Laravel life cycle

larave의 life cycle을 알아보고 laravel의 이해도가 좀 더 높아지길 기대합니다.

1. Web server에서 public/index를 실행

Web server Nginx, Apache 에는 configuration을 설정할 수 있습니다. 이곳에는 laravel application의 첫번째 경로가 지정되어 있습니다. 이 경로를 통해서 laravel application의 public/index.php 를 실행합니다.

2. public/index.php 에서 composer autoload 를 실행

composer 는 PHP의 의존성 관리 도구입니다. 프로젝트에서 사용하는 라이브러리를 선언하고 의존성을 해결해줍니다.

3. public/index.php 에서 bootstrap/app.php 를 실행

composer autoload를 실행한 후 public/index.php 에서는 bootstrap/app.php 스크립트에서 laravel application instance 를 가져오게 됩니다. bootstrap은 한 번 시작되면 알아서 진행되는 일련의 과정을 뜻합니다. bootstrap 에서는 Http kernel, console kernel, exception handler 를 singleton 디자인 패턴을 통해서 다음 사진과 같이 인스턴스화 합니다.

4. 애플리케이션이 시작된 유형에 따라 전송된 요청을 HTTP 커널이나 Console 커널로 전달합니다.

커널의 역할은 다음과 같습니다.

1. 사용자의 요청을 미들웨어에 전달, 예외 발생시 예외 처리
2. closure 나 controller에 반환되는 최종 response를 client에게 제공

HTTP Kernerl과 Console Kernel이 하는 행동은 다음과 같습니다.

• HTTP Kernel

  1. Illuminate\Foundation\Http\Kernel 클래스를 상속한다.
  2. 요청을 실행하기 전에 처리되는 bootstrappers(시작코드)의 배열을 정의한다. (에러 처리, 로그 설정)
  3. application 에서 request가 통과하는 Middleware의 목록을 정의한다.
  4. HTTP 세션을 읽고,쓰고 CSRF토큰을 확인하는 등 request가 처리되기 전에 실행한다.

• Console Kernel

  1. laravel console 에서 사용하는 cron, artisan 에서 사용한다.

5. 서비스 프로바이더 로딩

서비스 프로바이더 로딩은 라라벨의 라이프 사이클 과정중에 가장 중요한 것 중 하나라고 볼 수 있습니다.

커널의 부팅 과정이 일어나면서 라라벨 애플리케이션의 서비스 프로바이더가 함께 등록됩니다. 애플리케이션의 서비스 프로바이더는 config/app.php 파일의 providers 배열에 위치하고 있습니다.

모든 서비스 프로바이더의 register 메소드가 먼저 호출 되고, 이후 모든 boot 메소드가 호출 됩니다. register() 함수는 등록된 서비스 프로바이더에서 해당 메서드를 통해 인스턴스를 서비스 컨테이너에 저장하는 역할을 합니다. boot() 함수는 저장된 인스턴스를 호출해서 실행하는 역할을 합니다.

다음은 그 예로 Swagger service provider 입니다.

서비스 프로바이더는 DB, Queue, Validation, Routing 등 부팅(부트스트래핑)의 처리를 책임지기에 가장 중요합니다.

애플리케이션 코드를 작동시키기 전, 사전에 실행해야하는 코드는 서비스 프로바이더에 넣는 것이 적합합니다.

애플리케이션을 위한 기본 서비스 프로바이더는 app/Providers 디렉토리에 존재합니다. 기본적으로 AppServiceProvider는 비어있는데, 이 프로바이더는 부트스트래핑과 서비스 컨테이너 바인딩 코드를 추가하기 위한 곳입니다. 즉 얼마든지 원하는대로 서비스프로바이더를 만들 수 있습니다.

6. Request 처리-디스패칭

라라벨 애플리케이션이 부트스트래핑되고, 서비스 프로바이더가 등록 된 후, Request가 라우터를 통해 전달됩니다.

7. Middleware, Controller

라우터를 통해 Request가 지정된 미들웨어와 컨트롤러로 전달됩니다.

마무리하며

프레임워크가 어떻게 동작하는지 이해한다면 앞으로 프레임워크를 다루는데 있어서 자신감과 호기심이 생길 수 있다고 생각했습니다 :) 호기심은 학습에 좋은 도구라고 생각하고 있습니다. 라라벨 라이프 사이클 학습을 시작으로 라라벨은 물론 다른 프레임워크에게도 어떤 특성과 라이프 사이클이 있는지 궁금해졌습니다. 또한 앞으로 한 층 더 이해도 높게 라라벨을 다룰 수 있게 될 것 같습니다.

📚 참고 (라라벨 korea 공식문서) https://laravel.kr/docs/8.x/lifecycle

평범한 4년제 전자공학과에 다녔다. 나는 공대를 다니면서 하드웨어와 소프트웨어를 둘 다 만져볼 수 있는 기회가 있었는데, 처음으로 접하게 된 프로그래밍 언어는 C언어였다. 대학교 1학년 때 수업이었는데, 그때는 처음 보는 컴퓨터 언어에 굉장히 생소했었고, 흥미도 없었다. 그 때문에 1학년 1학기, 2학기에 배웠던 C언어 과목 학점을 완전히 말아 먹었다.

1학년이 지나고 군대를 가기 전에 나의 담당 교수님께 가서 "군대에서 시간이 남는다면 어떤 공부를 하는 게 저에게 도움이 될까요?" 하고 물었을 때 교수님은 나에게 C언어를 공부하라고 말씀해 주셨다.

담당 교수님이 C언어를 가르켜주신 교수님이어서 그런 것일수도 있지만 지금 현재는 그 교수님께 정말 감사하다.

나는 그래서 병장일때 동네 서점에서 C언어 책을 하나 사서 밤에 연등 시간이나 당직을 서게 되면 그 책을 뭔지도 모르고 노트에 하나하나 적으면서 이해해보려고 했었다. 내가 기억하기로 그때 군대에서 C언어의 함수까지 했었던 것으로 기억한다. 3분의 2정도 되는 분량이었던거 같다.

전역한 후 2학년이 되었을 때 알고리즘 수업이 있었는데, 2시간이었던 알고리즘 수업 시간마다 코딩에 몰입을 했었다. 평소 어떤 일에 오랫동안 열중하기가 어려웠었는데, 코딩을 할 때만큼은 정말 나만의 zone에 빠진 것만 같은 느낌이 들었다. 군대에서 혼자 손으로 그려갔던 코드들이 콘솔에 나오는 모습에 정말 기분이 좋았었다.

그렇게 코딩이 나를 흥미롭게 한다는 사실을 알고난 후, 프로그래밍 언어를 사용하는 직업에 대해서 궁금증이 생기기 시작했었다.

그리고 1학년 때 말아먹은 C언어와 객체지향프로그래밍 수업을 재수강했다

친구들도 그 당시에 내가 신기했었나보다. 하드웨어가 중점이 되는 우리 과에서 소프트웨어가 재미있다고 떠벌리고 다녔던 건 나뿐이었다.

그렇게 막연하게 코딩이 좋아서 개발자라는 꿈을 가지게 되었다.

개발자가 되고 싶다고 생각한 후

개발자가 되고싶다고 생각한 후에는 대학교 졸업 작품을 만들게 되었는데, 이 때 스마트 무드등을 만들었었다. 나는 친구들이 만든 무드등을 C언어로 제어하는 역할을 맡았었고, 처음으로 코딩으로 알고리즘이 아닌 실제로 움직이는 무언가를 만들어 보았던 것 같다.

나는 C언어를 사용하여 아두이노 LED를 제어했었고, 이 결과물로 캡스톤 경진대회에서 우수상을 받았었다. 그리고 이 때 삼성교육센터인 SSAFY에 지원도 했었는데, 시원하게 떨어졌다.

유튜브를 보면 수많은 사람들이 개발자가 되는데, 독학으로도 충분하다는 말에 처음엔 앱, 웹, 이러한 것들에 대한 개념도 모르고, 생활코딩에서 HTML, CSS, JAVA를 공부했다. 정말 그 때는 JAVA가 짱인줄 알았다. JAVA가 안좋다는 건 아니다.

부트캠프를 선택하기 까지

처음에는 동네 친구가 국비지원 학원을 수료하고 취업을 하는 모습을 보고, 나도 저렇게 졸업 후에 국비지원 학원을 수료하고 개발자가 되어야겠다고 다짐했다. 졸업을 앞두고 여러 국비지원 학원을 검색해보았는데, 너무나도 안 좋은 이야기들만 눈에 들어왔다.

무언가 하기 전에 돌다리도 한번 더 두드려보고 가는 성격인 나에게 이러한 국비지원에 대한 악플들은 국비지원으로 향하는 발걸음을 점점 멀어지게 했던 것 같다.

그렇게 여러가지를 찾아본 결과, 부트캠프라는 시스템을 알게 되었고, 나는 이것저것 많은 것을 고려해 보았었다.

1. 기간
2. 기술 스택
3. 부트캠프 가격
4. 수료자 평균 연봉

1. 기간

부트캠프를 수료하는데 드는 기간은 솔직히 중요하지 않았다. 왜냐하면 애초에 국비지원갈 생각에 6개월은 생각 했었는데, 대부분의 부트캠프들이 6개월 이내였다.

중요한건 "언제 시작할 수 있냐" 였다. 졸업 후 시간이 붕 뜨는 것을 볼 수 없었기 때문이다.

2. 기술 스택

이 부트캠프에서 내가 주체성을 가지고 기술을 선택할 수 있느냐에 대한 생각을 했었던 것 같다. 그 때에는 솔직히 어떤 기술이 있는지도 잘 몰랐지만, 여러 부트캠프들을 비교하면서 대략적인 흐름을 알아갔던 것 같다.

3. 부트캠프 가격

부트캠프들의 가격은 정말 많이 비싸다. 그렇기에 가격을 고려하지 않을 수가 없었다. 사실 부트캠프의 가격은 어떤 부트캠프를 고르냐의 척도가 되기 보다는 내가 과연 부트캠프를 갔을 때, 국비지원이나 독학보다 좋은 아웃풋을 낼 수 있는지가 가장 중요했다.

4. 수료자 평균 연봉

부트캠프의 아웃풋과 직결되는 문제가 수료자들의 평균 연봉이나 취업률이라고 생각했다. 또한 현실적인 궁금증을 가장 잘 해소 시켜주었던 것이 수료자들의 평균 연봉 수치였다.

기간은 신청 후 1개월 정도 기다렸었고, 백엔드와 프론트엔드 사이에서 고민할 수 있었다. 또한 수료자들의 취업률과 평균 연봉이 마음에 들었다.

무엇보다 수강신청을 한 첫날에 부트캠프에서 면담을 받았었는데, 이 때 위워크의 시설이 정말 마음에 들었고, 상담을 담당해주셨던 멘토님이 너무 친절하게 궁금했던 것들을 해소시켜주셔서 좋았던 것 같다.

부트캠프에서의 생활

세상에 열심히 하는 사람은 많다.

부트캠프에 처음 왔을 때 놀랐던 것은, 모두가 정말정말정말!! 열심히 한다는 점이었다. 10시부터 19시까지가 정규 시간이지만 대부분의 사람들이 19시에 가지 않는다. 그리고 주말에도 거의 대부분 나왔다.

이러한 학습열정으로 인해서 자연스럽게 공부 분위기가 형성 되었던 것 같다. 나도 3주차 정도 부터는 거의 항상 막차를 타고 집으로 귀가했었다.

또한 함께 있는 멘토님들도 옆에서 정말 많이 도와주신다. 멘토님들도 물론 거의 항상 7시 이후까지 남아있었고, 특히나 프로젝트 전날 같은 경우에는 새벽까지도 남아계셨다.

이런 멘토님들을 보면서, 아무리 교육과 코딩에 열정이 있어도 본인의 여가 시간을 포기하면서까지 도움을 주기가 쉽지 않았을텐데, 정말 고마움을 많이 느꼈다.

나는 아직 늦지 않았고 평범하다.

휴학을 1년하면서, 자연스럽게 한학번 낮은 친구들과 2학년부터 생활을 했었다. 1년 먼저 졸업하는 친구들을 보면서, 무언가 뒤쳐진다는 기분이 들었었는데, 이 곳에서 만난 많은 동기님들은 사회에서 여러가지 경험을 겪은 후 개발자가 되기위해서 오신 분들이 대부분이었다.

나와 같이 졸업하고 바로 온 사람들은 그렇게 많지 않았다. 그런 분들을 보면서 친구들에 비해 1년 뒤쳐져서 조바심을 냈던 나 스스로가 부끄러웠다.

개발은 진짜진짜 뚫어져라 쳐다보고 생각하면 되는 것 같다.

부트캠프에서 공부하면서 정말 내가 이걸 구현해 낼 수 있을까? 라고 고민하고, 또 마음처럼 되지 않아서 힘들었던 순간들이 많았다. 가장 힘들었었을 때가 처음 장고를 배웠을 때였는데, 로그인 기능과 댓글 기능을 구현해보는 것이었다.

거의 장고에 개념을 잡는데에만 1주일이라는 시간이 걸렸었는데, 그 때 주변 사람들한테 힘든티를 좀 많이 내서 부끄럽다. 내가 그 당시에 멘토님께 "진짜 아무것도 모르겠는데 이렇게 뚫어져라 쳐다보면 혹시 마법처럼 다 알게 될까요?" 라고 물어봤었다. 근데 멘토님이 웃으면서 "마법처럼 다 알게되는건 없어요" 라고 했다. ㅋㅋㅋㅋ

그런데 일주일동안 정말 뚫어져라 쳐다보고 그냥 뭔지 모르겠지만 계속 이해하려고 생각하다 보니까 어느 순간 장고쉘에서 ORM을 자연스럽게 쓰고 있는 나를 발견하게 되었다.

지금도 어떻게 내가 장고가 익숙해졌는지 신기할 때가 있다. 하지만 내가 마법처럼 알게 된다고 한건 정말 마법이 아니라 뚫어져라 쳐다보고 생각을 많이해서 그렇게 된 것 같다.

그 이후에 API들을 구현하면서 벽에 부딪힐 때 마다 장고를 처음 접하고 아무것도 할 수 없었던 일주일을 생각했다.

동료들과의 커뮤니케이션이 너무너무 중요하다.

커뮤니케이션의 중요성을 정말 많이 배웠다. 개발은 협업인데, 소통이 잘 되지 않으면 정말 많이 힘들었다.

3번의 프로젝트를 진행하면서, 정말 많은 프로젝트 팀들이 형성 되었다. 누가 보아도 화목한 팀들이 있었고, 누가 보아도 힘든 팀도 있었다.

이렇게 팀을 두가지로 양분하는 대표적인 문제점이 소통의 문제였는데, 그로 인해서 커뮤니케이션의 중요성을 너무나도 많이 깨달았다.

개발은 절대로 혼자하는 일이 아니기 때문에 언제나 커뮤니케이션이라는 스킬을 중요시 해야겠다고 마음먹었다.

동료들과의 커뮤니티도 너무너무 중요하다.

첫 세션에서 이런말을 들었던 것 같다.

개발자는 정말 커뮤니티가 크고 서로의 지식을 알려주기위해 노력한다고, 그렇기에 개발이 이렇게 급속도로 성장할 수 있었던 거라고 말이다.

이러한 말에 너무나도 동감한다. 정말 주변에 좋은 동기분들에게 도움을 받은적이 너무많다. 모르는 문제에 막혔을 때 옆에서 도와주고 힘들 때 같이 으쌰으쌰 해주던 동기분들께 너무나도 감사하다.

지금도 수료를 했지만 바로 동료들과 함께 토이프로젝트를 시작했다. 지금까지 만난 동기들, 개발자들, 그리고 앞으로 만날 수많은 현업에 있는 개발자들과도 좋은 커뮤니티를 형성하기 위해 노력해야겠다고 느꼈다.

새로운것을 두려워하지 않을 수 있는 용기.

개발은 공부의 연속이기 때문에 새로운 것을 두려워하면 안된다고 생각한다. 새로운 기술들에서 재미를 찾고 항상 호기심을 잊지 않도록 노력해야겠다고 느꼈다.

12주라는 적은 기간동안 정말 많은 양의 "새로운 것" 에 대해서 공부했는데, 12주동안 잘 이겨낸 것 처럼 앞으로 배울 많은 새로운 것들을 두려워하지 않을 것이다.

부트캠프에서의 아웃풋

나는 부트캠프에서 3번의 프로젝트를 진행했다.

1. 카카오프렌즈샵

첫 프로젝트였는데, 프론트엔드 3명, 백엔드 2명으로 개발을 시작했고 2주일이 걸렸다.

어려웠던 점

첫 프로젝트였기에 무엇을 어떻게 만드는지조차 많이 어려웠던 것 같다. 초기세팅을 시작으로 모델링, 크롤링, 데이터베이스 구축, API 개발 심지어 프론트 엔드와 개발한 API를 붙이는 것 까지 쉬운일이 단 하나도 없었던 것 같다.

이 때 개발했던 대부분의 API들이 지금 다시보면 GET VIEW 여서 데이터베이스에 넣어놓은 상품의 상세정보를 보여주는 것이 불과했지만, 이렇게 개발을 한다는 것 자체가 생소 했기 때문에 많은 벽에 부딪혔던 것 같다.

발전한 점, 느낀점

이 프로젝트로 인해서 다음 2차프로젝트에 있어서 어떻게 개발이 진행되는지에 대한 전체적인 그림을 그릴 수 있었던 것 같다.

그리고 처음에 모델링이 정말 어렵다고 느껴서 주말에 따로 강의까지 들었었는데, 전체적인 그림을 알게 되니까 모델링을 함에 있어도 숙련도가 늘어났었던 것 같다.

그리고 나의 API가 처음으로 화면 앞단에 보였을 때의 기분은 정말 잊지 못한다.

2. 필리

두번째 프로젝트로 알약사이트인 필리를 클론했다. 프론트엔드 3명 백엔드 3명으로 개발을 했다. 마찬가지로 2주일이라는 시간이 걸렸다.

어려웠던 점

두번째 프로젝트에서 내가 맡았던 부분은 설문조사 부분이었는데, 사용자의 대답에 따라서 다음 질문이 동적으로 나와야 했다.

또한 모든 설문조사가 끝났을 때에는 사용자의 설문조사를 분석하여 사용자에게 알약을 추천해주어야 했는데, 설문조사 API를 만드는데 시간을 가장 많이 썼다.

이 때까지도 아직 장고에 그렇게 익숙하다는 느낌이 없었기에, 프론트엔드쪽이 원하는 데이터를 프론트에게 주고 받는 방법에 있어서도 많이 고민했었고, 설문조사의 알고리즘에 대해서 크롤링이 불가했기 때문에, 그러한 알고리즘도 많이 생각했었던 것 같다.

발전한 점, 느낀점

두번째 프로젝트를 진행하면서 장고와 정말 많이친해졌다. 정참조와 역참조의 개념에 대해서도 많이 알게 되었고, 실제로 사용도 많이 했던 것 같다.

또한 GET API가 아닌 POST API도 많이 만들어 보면서, 부족한 개발능력을 채워 나갔다.

그리고 모델링에 대한 수정이 개발하면서 끊임없이 이루어졌는데, 모델링의 중요성을 다시 한번 깨달았다.

설문조사 API를 만들면서 프론트엔드와 계속 소통을 했는데, 커뮤니케이션의 중요성 또한 극대화로 느끼게 되는 프로젝트였다.

그리고 필리를 클론하면서 개발에 대한 자신감들이 생겼던 것 같다. 아무리 어려워도 못할 건 없다는 자신감.

3. 원티드

원티드는 기업협업을 나가서 했던 프로젝트이다.

나는 기업협업을 (주)INSA라는 회사에서 했는데, INSA라는 회사는 채용사이트를 만들 계획을 가지고 있었다.

이런 회사의 목적과 가장 비슷한 사이트가 원티드였는데, 원티드를 만들면서 우리가 사용하는 Django와 React의 가능성을 보고자 했다.

개발 기간은 4주였고, 프론트엔드 1명 백엔드 4명으로 시작했다.

어려웠던 점

우리는 원티드를 유저의 페이지만 개발한 것이 아니라, 기업 페이지까지 개발 했다.

원티드에서는 유저가 어떠한 정보를 올리면 기업페이지에 해당 유저의 정보들이 업로드 되고, 기업 페이지에서 어떠한 행위를 하게 되면 유저의 페이지에서 업로드 되었다.

한 마디로 어떠한 개발에 있어서 모든 API들이 거미줄처럼 엮여있다는 생각이 들었다.

모든 API들이 상호작용을 하고 있었기 때문이었다.

백엔드가 4명이었기 때문에 역할분배도 쉽지 않았고, 이렇게 역할 분담을 하고 나서 서로의 작업에 지장이 가지 않게 하기위해 노력했다.

발전한 점, 느낀점

처음으로 현업에서 개발을 해보았다. 우리는 같은 언어를 사용하지는 않지만 현업에서 15년정도 개발하신 개발자분이 사수로 계셨는데, 부트캠프에서는 배울 수 없었던 많은 디테일들을 배웠던 것 같다.

이러한 디테일들이 설계에서부터 시작되어야 한다는 점을 정말 많이 느꼈고, 앞으로 있을 나의 개발에서는 이런 디테일들에 대해서 최대한 고민해야겠다고 느꼈다.

또한 상호작용이 많은 페이지였기에 다시 한번 커뮤니케이션에 중요성을 느꼈다.

그리고 테스트에 중요성을 느꼈다. 우리가 개발한 페이지에서 CTO님이 정말 이것저것 눌르시면서 테스트를 하셨는데, 그럴 때마다 생각하지못한 에러들이 우리를 반겨주었다. 실제 서비스를 한다면 정말 치명적인 버그들이 생기는 것이다. 그래서 개발만한다고 끝이 아니라 내가 개발한 결과물이 정말 완벽한지 테스트를 해보는 것이 아주 많이 중요하다고 느꼇다.

마지막으로

부트캠프에서 12주라는 짧은 과정을 마치고 나는 이제 취업을 준비하는 취준생이 되었다.

취업을 하기전에 개발 욕심이 많이 생겨서 부트캠프 동기분들과 함께 토이프로젝트를 시작했고, 새로운 기술스택에 대한 호기심이 생겨서 Django가 아닌 Flask로 개발을 할 계획이다.

12주동안 느낀점들을 말하려면 하루종일 말해도 부족하다. 하지만 하나 확실해졌던 점은 내가 정말 개발을 즐기고 좋아한다는 점이다.

** 내가 좋아하는 것을 알지 못하고 이것저것 시행착오를 겪지 않고, 개발이라는 것을 만난 것에 감사하다. **

12주동안 정말 빠른 성장을 했던 것 같다. 앞으로도 이런 마음 잃지 않고, 좋은 개발자들 많이 만나고 멋있는 아웃풋을 꾸준히 내고 성장하는 개발자가 되고싶다.