라라벨 MCP 서버 구축 방법 정리: ChatGPT OAuth·JWT·DB Tool 구조까지 직접 구현해본 후기

PHP Laravel 기반 MCP Server를 실제 운영 구조로 구성해보니 기존 REST API와는 방향 자체가 달랐다.

최근 들어 MCP(Model Context Protocol) 관련 이야기가 개발 커뮤니티에서 꽤 많이 나오기 시작했습니다. 처음에는 단순히 ChatGPT 플러그인이나 GPT API 확장 정도로 생각했는데 실제로 구조를 구현해보니 느낌이 완전히 달랐습니다. 기존 REST API가 “사람이 호출하는 API”였다면 MCP는 “AI가 Tool을 호출하는 구조”에 훨씬 가까웠습니다.

반응형

특히 ERP나 MES 같은 실제 운영 시스템과 연결하기 시작하면 단순 챗봇 느낌이 아니라 AI 전용 API 레이어를 만드는 느낌에 가까워집니다. 이번에는 Laravel 10 기반으로 ChatGPT MCP 서버를 직접 구축하면서 OAuth 인증, JWT 처리, DB Tool 구조까지 실제 운영 관점으로 구성해봤습니다.

---

MCP(Model Context Protocol)는 기존 API와 무엇이 달랐을까?

처음 MCP를 접했을 때 가장 먼저 느낀 건 API 호출 흐름 자체가 기존 REST 방식과 꽤 다르다는 점이었습니다. 기존 구조에서는 사용자가 직접 화면에서 데이터를 조회했습니다.

하지만 MCP 구조에서는 AI가 Tool을 호출하고 필요한 데이터를 읽기 시작합니다. 예를 들면 사용자가 단순히 질문만 입력해도 AI가 내부적으로 적절한 Tool을 선택하고 DB 조회까지 진행하는 흐름에 가까웠습니다.

실제로 구현해보면 기존 CRUD API를 몇 개 만드는 수준과는 체감이 꽤 다릅니다. 단순 응답 API가 아니라 “AI가 사용할 수 있는 인터페이스”를 설계하는 느낌에 더 가까웠습니다.

---

라라벨 기반 MCP 서버 구조는 어떻게 구성했을까?

이번 구축은 Laravel 10 기준으로 진행했습니다. 기존 Laravel Service 구조를 최대한 유지하면서 MCP 레이어를 추가하는 방향으로 설계했습니다. 기본적으로는 다음 구조에 가깝게 구성했습니다.

ChatGPT
↓
OAuth 인증
↓
JWT Access Token 발급
↓
MCP Tool 호출
↓
DatabaseToolService 실행
↓
Query Builder 기반 데이터 조회

 

 

Laravel 10 MCP OAuth + JWT + DB 스키마 기반 구조 구축하기: ChatGPT MCP 서버 직접 만들기

▲ 라라벨로 MCP oAuth 구축 정리 ▲

 

기존 라라벨 구조 위에 MCP Tool 계층을 추가하는 방식이라 생각보다 확장성이 괜찮았습니다. 특히 Service 구조와 Query Builder를 그대로 활용할 수 있다는 점이 꽤 장점처럼 느껴졌습니다.

---

OAuth 인증 구조가 생각보다 가장 어려웠다.

처음에는 단순 토큰 인증 정도로 생각했습니다. 그런데 실제 MCP 구조에서는 authorize, redirect, access token, refresh token 흐름까지 모두 맞춰야 했습니다. 특히 ChatGPT MCP 연결 과정에서는 redirect URI나 bearer token 처리 흐름이 조금만 어긋나도 정상 동작하지 않았습니다. 실제로 구현했던 OAuth 토큰 처리 코드는 아래와 비슷한 형태였습니다.

public function token(Request $request)
{
    $user = User::where('email', $request->email)->first();

    if (!$user || !Hash::check($request->password, $user->password)) {
        return response()->json([
            'error' => 'invalid_credentials'
        ], 401);
    }

    $accessToken = auth()->login($user);

    return response()->json([
        'access_token' => $accessToken,
        'token_type' => 'Bearer',
        'expires_in' => auth()->factory()->getTTL() * 60,
    ]);
}

 

실제로는 refresh token 처리나 middleware 인증 흐름까지 추가되면서 생각보다 복잡해졌습니다. 일반 로그인 시스템보다 “AI가 안전하게 Tool을 호출할 수 있는 구조” 자체가 훨씬 중요했습니다.

---

JWT 구조는 왜 중요했을까?

MCP 구조에서는 단순 로그인보다 JWT 구조가 훨씬 중요하게 느껴졌습니다. 특히 Tool 호출 시 권한 제어가 굉장히 중요했기 때문입니다. 예를 들어 특정 Tool은 관리자만 호출 가능하게 제한하거나 특정 데이터 범위만 조회 가능하도록 구성해야 하는 경우도 있었습니다. 라라벨에서는 JWTSubject 구현으로 비교적 자연스럽게 연결할 수 있었습니다.

class User extends Authenticatable implements JWTSubject
{
    public function getJWTIdentifier()
    {
        return $this->getKey();
    }

    public function getJWTCustomClaims()
    {
        return [];
    }
}

 

 

특히 access token과 refresh token 흐름을 운영 환경에 맞게 수정하면서 기존 웹 로그인과는 방향 자체가 꽤 다르다는 걸 체감하게 됐습니다.

---

MCP Tool 구조에서는 Query 제한이 거의 필수였다.

실제로 운영 구조를 만들면서 가장 중요했던 부분 중 하나는 Query 제한이었습니다. 처음에는 단순 select 정도만 생각했는데 실제로는 AI가 데이터를 반복 조회하거나 과도하게 호출하는 상황도 고려해야 했습니다. 그래서 운영 단계에서는 다음 같은 제한이 거의 필수에 가까웠습니다.

1. limit 제한
2. read only 정책
3. soft delete 제외
4. 특정 컬럼 제한
5. 위험 Query 차단
6. 권한별 Tool 제한

 

특히 MCP는 AI가 Tool을 직접 호출하는 구조이기 때문에 기존 REST API보다 훨씬 더 보수적으로 접근하는 게 중요했습니다.

실제로 Query Builder에서는 아래처럼 limit 제한을 기본으로 넣는 형태로 구성했습니다.

$query = DB::table('blog_posts')
    ->where('is_deleted', 'N')
    ->orderBy('created_at', 'desc')
    ->limit(10);

return $query->get();

 

단순 CRUD 구조에서는 크게 중요하지 않았던 부분들이 MCP 환경에서는 굉장히 중요하게 느껴졌습니다.

---

MCP를 구현하면서 가장 크게 느낀 점

이번 작업을 하면서 가장 크게 느낀 건 앞으로는 “AI가 읽을 수 있는 시스템 구조” 자체가 점점 중요해질 가능성이 높다는 점이었습니다.

예전에는 사람이 화면에 들어가 데이터를 조회했습니다. 하지만 앞으로는 AI가 Tool을 호출하고 필요한 데이터를 정리하는 흐름이 훨씬 많아질 가능성이 높아 보였습니다.

특히 Laravel처럼 기존 웹서비스 구조를 그대로 활용하면서 MCP 레이어를 추가할 수 있다는 점은 꽤 인상적이었습니다. 기존 시스템을 모두 새로 만드는 것이 아니라 현재 운영 중인 구조 위에 AI 인터페이스 계층을 추가하는 느낌에 가까웠습니다.

실제로 MCP 구조를 구현하다 보면 기존 REST API 개발과는 방향 자체가 꽤 다르게 느껴집니다. 단순 데이터 응답 API보다 “AI가 사용할 수 있는 구조를 어떻게 설계할 것인가”가 훨씬 중요해지는 느낌이 강했습니다.

최근에는 티에이치스터디에서도 라라벨 MCP 구조와 OAuth·JWT 흐름, 실제 Tool 설계 방향에 대해 계속 정리하고 있는데 구현을 진행할수록 앞으로는 단순 CRUD 중심 개발보다 AI 연동 구조 자체를 이해하는 경험이 꽤 중요해질 가능성이 높다는 생각이 들었습니다.