PHP 생태계에서 Symfony는 단순한 프레임워크가 아닙니다.
마치 레고 블록처럼 필요한 컴포넌트만 골라서 조립할 수 있는 아키텍처 철학을 가진 플랫폼이에요.
Laravel, Drupal, Magento 같은 유명한 PHP 프레임워크들도 Symfony 컴포넌트를 내부적으로 사용하고 있다는 사실, 알고 계셨나요? 😲

오늘은 Symfony의 핵심 중의 핵심인 컴포넌트 기반 아키텍처와 의존성 주입(DI) 컨테이너에 대해 진짜 깊게 파헤쳐볼게요.
코드도 보고, 개념도 잡고, 실무에서 어떻게 쓰는지까지 — 완전 풀패키지로 갑니다 ㄱㄱ 🔥

Symfony는 2005년 Fabien Potencier가 만든 PHP 프레임워크인데요,
처음부터 "모놀리식 프레임워크가 아닌, 재사용 가능한 컴포넌트 집합"으로 설계됐어요.
이게 진짜 혁신적인 부분이에요 ㄹㅇ 🔥

실제로 Symfony 컴포넌트들은 Composer를 통해 개별적으로 설치할 수 있어요.
전체 Symfony 프레임워크를 설치하지 않아도, 필요한 컴포넌트만 가져다 쓸 수 있다는 게 진짜 강점이에요.

예를 들어 Laravel은 내부적으로 symfony/http-foundation, symfony/routing, symfony/console 등을 사용하고 있어요.
Drupal 8 이상도 Symfony 컴포넌트를 대거 채택했고요. 이게 바로 Symfony가 "PHP 생태계의 인프라"라고 불리는 이유입니다 💪

의존성 주입... 이름만 들으면 뭔가 어렵게 느껴지죠? ㅋㅋㅋ
근데 개념 자체는 생각보다 심플해요. 같이 살펴봐요!

// ❌ 나쁜 예시 - 강한 결합(Tight Coupling)
class UserService {
    private $db;
    
    public function __construct() {
        // 내부에서 직접 생성 - 이게 문제!
        $this->db = new MySQLDatabase('localhost', 'root', 'password');
    }
    
    public function findUser(int $id): array {
        return $this->db->query("SELECT * FROM users WHERE id = ?", [$id]);
    }
}

// 사용
$service = new UserService(); // DB 설정이 클래스 안에 박혀있음 ㅠㅠ

// ✅ 좋은 예시 - 의존성 주입(Dependency Injection)

// 인터페이스 정의
interface DatabaseInterface {
    public function query(string $sql, array $params = []): array;
}

// 구현체
class MySQLDatabase implements DatabaseInterface {
    public function __construct(
        private string $host,
        private string $user,
        private string $password
    ) {}
    
    public function query(string $sql, array $params = []): array {
        // MySQL 쿼리 실행
        return [];
    }
}

// 서비스 - 외부에서 의존성을 주입받음!
class UserService {
    public function __construct(
        private DatabaseInterface $db  // 인터페이스에 의존
    ) {}
    
    public function findUser(int $id): array {
        return $this->db->query("SELECT * FROM users WHERE id = ?", [$id]);
    }
}

// 사용 - 외부에서 조립
$db = new MySQLDatabase('localhost', 'root', 'password');
$service = new UserService($db);  // 주입!

// 테스트 시에는 Mock 객체 주입 가능!
$mockDb = new MockDatabase();
$testService = new UserService($mockDb);  // 테스트 쉬워짐 ㄷㄷ

Symfony의 DependencyInjection 컴포넌트는 PHP 생태계에서 가장 강력하고 성숙한 DI 컨테이너 중 하나예요.
설치부터 실제 사용까지 단계별로 살펴볼게요!

composer require symfony/dependency-injection
composer require symfony/config  # 설정 파일 로딩용 (선택)
composer require symfony/yaml    # YAML 설정 파일용 (선택)

use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;

// 컨테이너 생성
$container = new ContainerBuilder();

// 서비스 등록 - Database
$container->register('database', MySQLDatabase::class)
    ->addArgument('localhost')
    ->addArgument('root')
    ->addArgument('secret_password');

// 서비스 등록 - Mailer
$container->register('mailer', SmtpMailer::class)
    ->addArgument('smtp.example.com')
    ->addArgument(587);

// 서비스 등록 - UserService (다른 서비스에 의존)
$container->register('user_service', UserService::class)
    ->addArgument(new Reference('database'))  // database 서비스 참조
    ->addArgument(new Reference('mailer'));   // mailer 서비스 참조

// 컨테이너 컴파일 (최적화)
$container->compile();

// 서비스 가져오기
$userService = $container->get('user_service');
// 컨테이너가 알아서 database, mailer 생성해서 주입해줌! 🎉

PHP 코드로 직접 등록하는 것도 좋지만, 실무에서는 YAML 설정 파일을 더 많이 써요.
훨씬 깔끔하고 관리하기 편하거든요 ㅋㅋ

# config/services.yaml

services:
    # 기본 설정
    _defaults:
        autowire: true      # 자동 와이어링 활성화
        autoconfigure: true # 자동 설정 활성화
        public: false       # 기본적으로 private 서비스

    # 네임스페이스 전체 자동 등록
    App\:
        resource: '../src/'
        exclude:
            - '../src/DependencyInjection/'
            - '../src/Entity/'
            - '../src/Kernel.php'

    # 개별 서비스 설정
    App\Service\UserService:
        arguments:
            $db: '@App\Repository\UserRepository'
            $mailer: '@App\Service\MailerService'
        tags:
            - { name: 'app.service' }

    # 파라미터 사용
    App\Service\SmtpMailer:
        arguments:
            $host: '%mailer.host%'
            $port: '%mailer.port%'

parameters:
    mailer.host: 'smtp.example.com'
    mailer.port: 587

// PHP 8.1+ 생성자 프로퍼티 프로모션과 함께 사용
class OrderService {
    public function __construct(
        private UserRepository $userRepository,      // 자동 주입!
        private ProductRepository $productRepository, // 자동 주입!
        private MailerInterface $mailer,              // 자동 주입!
        private LoggerInterface $logger               // 자동 주입!
    ) {}
    
    public function createOrder(int $userId, array $items): Order {
        $user = $this->userRepository->find($userId);
        // ... 주문 생성 로직
        $this->mailer->send(new OrderConfirmationEmail($user));
        $this->logger->info('Order created', ['user_id' => $userId]);
        return $order;
    }
}
// services.yaml에 autowire: true 설정만 해두면
// 컨테이너가 타입 힌트 보고 알아서 다 주입해줌! 🎉

Symfony DI 컨테이너의 진짜 강력한 기능 중 하나가 바로 서비스 태그예요.
특정 인터페이스를 구현한 서비스들을 자동으로 수집해서 처리할 수 있어요. 이거 알면 진짜 레벨업 됨 ㄹㅇ 🔥

// 1. 인터페이스 정의
interface PaymentGatewayInterface {
    public function getName(): string;
    public function processPayment(float $amount): bool;
}

// 2. 구현체들
class StripeGateway implements PaymentGatewayInterface {
    public function getName(): string { return 'stripe'; }
    public function processPayment(float $amount): bool {
        // Stripe API 호출
        return true;
    }
}

class PaypalGateway implements PaymentGatewayInterface {
    public function getName(): string { return 'paypal'; }
    public function processPayment(float $amount): bool {
        // PayPal API 호출
        return true;
    }
}

// 3. 수집기 서비스
class PaymentGatewayRegistry {
    private array $gateways = [];
    
    public function addGateway(PaymentGatewayInterface $gateway): void {
        $this->gateways[$gateway->getName()] = $gateway;
    }
    
    public function getGateway(string $name): PaymentGatewayInterface {
        return $this->gateways[$name] 
            ?? throw new \InvalidArgumentException("Gateway '$name' not found");
    }
}

# services.yaml - 태그 설정
services:
    App\Payment\StripeGateway:
        tags:
            - { name: 'app.payment_gateway' }
    
    App\Payment\PaypalGateway:
        tags:
            - { name: 'app.payment_gateway' }
    
    App\Payment\PaymentGatewayRegistry:
        # 태그된 서비스들을 자동으로 주입!

// 4. 컴파일러 패스 - 태그된 서비스 자동 수집
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;

class PaymentGatewayCompilerPass implements CompilerPassInterface {
    public function process(ContainerBuilder $container): void {
        if (!$container->has(PaymentGatewayRegistry::class)) {
            return;
        }
        
        $registryDef = $container->findDefinition(PaymentGatewayRegistry::class);
        
        // 'app.payment_gateway' 태그가 붙은 모든 서비스 찾기
        $taggedServices = $container->findTaggedServiceIds('app.payment_gateway');
        
        foreach ($taggedServices as $id => $tags) {
            // 레지스트리에 자동으로 추가
            $registryDef->addMethodCall('addGateway', [new Reference($id)]);
        }
    }
}

// Kernel 또는 Bundle에 등록
class AppKernel extends Kernel {
    protected function build(ContainerBuilder $container): void {
        $container->addCompilerPass(new PaymentGatewayCompilerPass());
    }
}

use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;

#[AutoconfigureTag('app.payment_gateway')]
class StripeGateway implements PaymentGatewayInterface {
    // ...
}

// 또는 AsTaggedItem 사용
use Symfony\Component\DependencyInjection\Attribute\AsTaggedItem;

#[AsTaggedItem('app.payment_gateway', priority: 10)]
class StripeGateway implements PaymentGatewayInterface {
    // ...
}

실무에서는 개발(dev), 테스트(test), 운영(prod) 환경마다 다른 설정이 필요하죠.
Symfony는 이걸 정말 우아하게 처리해요 😎

config/
├── services.yaml          # 공통 서비스 설정
├── services_dev.yaml      # 개발 환경 전용
├── services_test.yaml     # 테스트 환경 전용
├── services_prod.yaml     # 운영 환경 전용
├── packages/
│   ├── framework.yaml
│   ├── doctrine.yaml
│   └── dev/
│       └── web_profiler.yaml  # 개발 환경에서만 로드
└── routes/
    ├── annotations.yaml
    └── dev/
        └── web_profiler.yaml

# config/services.yaml - 공통 설정
parameters:
    app.name: 'My Application'
    app.version: '1.0.0'
    
services:
    App\Service\UserService:
        arguments:
            $appName: '%app.name%'  # 파라미터 참조

---
# config/services_dev.yaml - 개발 환경
parameters:
    app.debug: true
    
services:
    # 개발 환경에서만 사용할 서비스
    App\Service\DebugMailer:
        decorates: App\Service\MailerService  # 데코레이터 패턴!

---
# config/services_prod.yaml - 운영 환경
parameters:
    app.debug: false

# .env 파일
DATABASE_URL="mysql://user:password@localhost:3306/mydb"
MAILER_DSN="smtp://user:pass@smtp.example.com:587"
APP_SECRET="your-secret-key-here"

# config/services.yaml에서 환경 변수 사용
parameters:
    database_url: '%env(DATABASE_URL)%'
    
services:
    App\Repository\DatabaseConnection:
        arguments:
            $dsn: '%env(DATABASE_URL)%'
            # 환경 변수 프로세서 사용
            $port: '%env(int:DATABASE_PORT)%'  # 정수로 변환
            $debug: '%env(bool:APP_DEBUG)%'    # 불리언으로 변환

Symfony DI 컨테이너의 또 다른 킬러 기능! 바로 서비스 데코레이션이에요.
기존 서비스를 수정하지 않고 기능을 확장할 수 있어요. 개방-폐쇄 원칙(OCP) 완벽 구현 ㄷㄷ

// 원본 서비스
class UserRepository {
    public function find(int $id): ?User {
        // DB에서 사용자 조회
        return $this->db->findOne('users', $id);
    }
}

// 캐싱 데코레이터
class CachedUserRepository {
    public function __construct(
        private UserRepository $inner,  // 원본 서비스 주입
        private CacheInterface $cache
    ) {}
    
    public function find(int $id): ?User {
        $cacheKey = "user_{$id}";
        
        // 캐시에서 먼저 찾기
        if ($this->cache->has($cacheKey)) {
            return $this->cache->get($cacheKey);
        }
        
        // 없으면 원본에서 가져와서 캐시에 저장
        $user = $this->inner->find($id);
        $this->cache->set($cacheKey, $user, 3600);
        
        return $user;
    }
}

# services.yaml - 데코레이터 설정
services:
    App\Repository\UserRepository: ~  # 원본 서비스
    
    App\Repository\CachedUserRepository:
        decorates: App\Repository\UserRepository  # 데코레이션!
        arguments:
            $inner: '@.inner'  # 원본 서비스 자동 참조

Symfony 컴포넌트와 DI 컨테이너를 활용한 실전 아키텍처를 살펴볼게요.
재능넷 같은 플랫폼을 만든다고 가정하고 설계해볼게요! 🎯

src/
├── Controller/           # 프레젠테이션 레이어
│   ├── UserController.php
│   └── OrderController.php
│
├── Application/          # 애플리케이션 레이어
│   ├── Command/
│   │   ├── CreateUserCommand.php
│   │   └── CreateUserHandler.php
│   └── Query/
│       ├── GetUserQuery.php
│       └── GetUserHandler.php
│
├── Domain/               # 도메인 레이어
│   ├── Entity/
│   │   └── User.php
│   ├── Repository/
│   │   └── UserRepositoryInterface.php  # 인터페이스만!
│   └── Service/
│       └── UserDomainService.php
│
└── Infrastructure/       # 인프라 레이어
    ├── Repository/
    │   └── DoctrineUserRepository.php   # 구현체
    ├── Mailer/
    │   └── SymfonyMailer.php
    └── Cache/
        └── RedisCache.php

// Command - 사용자 생성 명령
class CreateUserCommand {
    public function __construct(
        public readonly string $email,
        public readonly string $name,
        public readonly string $password
    ) {}
}

// Handler - 명령 처리
class CreateUserHandler {
    public function __construct(
        private UserRepositoryInterface $userRepository,
        private PasswordHasherInterface $passwordHasher,
        private EventDispatcherInterface $eventDispatcher,
        private LoggerInterface $logger
    ) {}
    
    public function __invoke(CreateUserCommand $command): User {
        // 이메일 중복 확인
        if ($this->userRepository->existsByEmail($command->email)) {
            throw new UserAlreadyExistsException($command->email);
        }
        
        // 사용자 생성
        $user = new User(
            email: $command->email,
            name: $command->name,
            passwordHash: $this->passwordHasher->hash($command->password)
        );
        
        $this->userRepository->save($user);
        
        // 이벤트 발행
        $this->eventDispatcher->dispatch(new UserCreatedEvent($user));
        
        $this->logger->info('User created', ['email' => $command->email]);
        
        return $user;
    }
}

# services.yaml - 자동 와이어링으로 간단하게!
services:
    _defaults:
        autowire: true
        autoconfigure: true
    
    App\:
        resource: '../src/'
    
    # 인터페이스 → 구현체 바인딩
    App\Domain\Repository\UserRepositoryInterface:
        alias: App\Infrastructure\Repository\DoctrineUserRepository
    
    App\Domain\Service\PasswordHasherInterface:
        alias: App\Infrastructure\Security\BcryptPasswordHasher

DI 컨테이너가 편리하긴 한데, 잘못 쓰면 성능 이슈가 생길 수 있어요.
Symfony는 이 문제를 어떻게 해결하는지 알아볼게요!

// Symfony는 컨테이너를 컴파일해서 최적화된 PHP 파일로 저장
// var/cache/prod/App_KernelProdContainer.php 같은 파일이 생성됨

// 컴파일된 컨테이너는 이런 형태
class App_KernelProdContainer extends Container {
    // 모든 서비스 정의가 최적화된 PHP 코드로 변환됨
    protected function getUserService(): UserService {
        return $this->services['App\\Service\\UserService'] 
            ??= new UserService(
                $this->getDoctrineUserRepositoryService(),
                $this->getSymfonyMailerService()
            );
    }
}

// 운영 환경에서는 이 캐시된 컨테이너를 사용
// → 매 요청마다 YAML 파싱 없음, 즉시 사용 가능!

# services.yaml - 무거운 서비스는 lazy 설정
services:
    App\Service\HeavyReportGenerator:
        lazy: true  # 실제로 사용될 때만 인스턴스 생성
        
    App\Service\ExternalApiClient:
        lazy: true

// PHP 8.4+ 에서는 Lazy Ghost 객체 지원
// 실제 메서드 호출 전까지 초기화 안 됨

use Symfony\Component\DependencyInjection\Attribute\Lazy;

class OrderController {
    public function __construct(
        #[Lazy] private HeavyReportGenerator $reportGenerator,
        // 이 서비스는 실제로 사용할 때만 초기화됨!
    ) {}
    
    public function index(): Response {
        // reportGenerator는 여기서 초기화 안 됨
        return new Response('Hello');
    }
    
    public function generateReport(): Response {
        // 여기서 처음 사용될 때 초기화됨
        $report = $this->reportGenerator->generate();
        return new Response($report);
    }
}

DI 컨테이너의 가장 큰 장점 중 하나가 바로 테스트 용이성이에요.
의존성을 외부에서 주입하니까 테스트 시 Mock 객체로 쉽게 교체할 수 있거든요!

use PHPUnit\Framework\TestCase;
use PHPUnit\Framework\MockObject\MockObject;

class CreateUserHandlerTest extends TestCase {
    private UserRepositoryInterface&MockObject $userRepository;
    private PasswordHasherInterface&MockObject $passwordHasher;
    private EventDispatcherInterface&MockObject $eventDispatcher;
    private CreateUserHandler $handler;
    
    protected function setUp(): void {
        // Mock 객체 생성
        $this->userRepository = $this->createMock(UserRepositoryInterface::class);
        $this->passwordHasher = $this->createMock(PasswordHasherInterface::class);
        $this->eventDispatcher = $this->createMock(EventDispatcherInterface::class);
        
        // 직접 의존성 주입! (컨테이너 없이도 테스트 가능)
        $this->handler = new CreateUserHandler(
            $this->userRepository,
            $this->passwordHasher,
            $this->eventDispatcher,
            new NullLogger()  // 실제 로거 대신 Null 로거
        );
    }
    
    public function testCreateUserSuccessfully(): void {
        // Given
        $command = new CreateUserCommand('test@example.com', 'Test User', 'password123');
        
        $this->userRepository
            ->expects($this->once())
            ->method('existsByEmail')
            ->with('test@example.com')
            ->willReturn(false);  // 이메일 중복 없음
        
        $this->passwordHasher
            ->expects($this->once())
            ->method('hash')
            ->willReturn('hashed_password');
        
        $this->userRepository
            ->expects($this->once())
            ->method('save');
        
        $this->eventDispatcher
            ->expects($this->once())
            ->method('dispatch')
            ->with($this->isInstanceOf(UserCreatedEvent::class));
        
        // When
        $user = ($this->handler)($command);
        
        // Then
        $this->assertEquals('test@example.com', $user->getEmail());
        $this->assertEquals('Test User', $user->getName());
    }
    
    public function testThrowsExceptionForDuplicateEmail(): void {
        $command = new CreateUserCommand('existing@example.com', 'User', 'pass');
        
        $this->userRepository
            ->method('existsByEmail')
            ->willReturn(true);  // 이메일 중복!
        
        $this->expectException(UserAlreadyExistsException::class);
        
        ($this->handler)($command);
    }
}

use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;

class UserServiceIntegrationTest extends KernelTestCase {
    private UserService $userService;
    
    protected function setUp(): void {
        // Symfony 테스트 커널 부팅
        self::bootKernel(['environment' => 'test']);
        
        // 컨테이너에서 서비스 가져오기
        $this->userService = static::getContainer()->get(UserService::class);
    }
    
    public function testFindUser(): void {
        // 실제 테스트 DB 사용 (test 환경)
        $user = $this->userService->findUser(1);
        $this->assertNotNull($user);
    }
}

# config/services_test.yaml - 테스트 환경 전용
services:
    # 실제 메일러 대신 Null 메일러 사용
    App\Service\MailerInterface:
        alias: App\Service\NullMailer
    
    # 실제 결제 게이트웨이 대신 Mock 사용
    App\Payment\PaymentGatewayInterface:
        alias: App\Payment\MockPaymentGateway
    
    # 외부 API 클라이언트 Mock
    App\Api\ExternalApiClient:
        alias: App\Api\MockExternalApiClient

// ❌ 나쁜 예 - 서비스 로케이터 패턴 (안티패턴!)
class UserController {
    public function __construct(
        private ContainerInterface $container  // 컨테이너 자체를 주입
    ) {}
    
    public function createUser(): Response {
        // 컨테이너에서 직접 꺼내 씀 - 의존성이 숨겨짐!
        $userService = $this->container->get(UserService::class);
        $mailer = $this->container->get(MailerInterface::class);
        // ...
    }
}

// ✅ 좋은 예 - 필요한 서비스만 직접 주입
class UserController {
    public function __construct(
        private UserService $userService,
        private MailerInterface $mailer
    ) {}
    // 의존성이 명확하게 드러남!
}

// ❌ 나쁜 예 - 생성자에 의존성이 너무 많음 (단일 책임 원칙 위반 신호!)
class GodService {
    public function __construct(
        private UserRepository $userRepo,
        private OrderRepository $orderRepo,
        private ProductRepository $productRepo,
        private MailerInterface $mailer,
        private CacheInterface $cache,
        private LoggerInterface $logger,
        private EventDispatcherInterface $dispatcher,
        private PaymentGateway $payment,
        private ShippingService $shipping,
        private NotificationService $notification
        // 이렇게 많으면 클래스 분리 신호!
    ) {}
}

// ✅ 좋은 예 - 책임 분리
class OrderService {
    public function __construct(
        private OrderRepository $orderRepo,
        private PaymentService $paymentService,  // 결제 관련 묶음
        private ShippingService $shippingService  // 배송 관련 묶음
    ) {}
}

# 등록된 서비스 목록 확인
php bin/console debug:container

# 특정 서비스 상세 정보
php bin/console debug:container App\Service\UserService

# 자동 와이어링 가능한 타입 목록
php bin/console debug:autowiring

# 특정 타입으로 필터링
php bin/console debug:autowiring Logger

# 이벤트 리스너 목록
php bin/console debug:event-dispatcher

# 라우팅 정보
php bin/console debug:router

Symfony 6.x부터는 PHP 8의 Attribute를 적극 활용해서
YAML 설정 없이도 서비스를 설정할 수 있어요. 진짜 개편함 ㄷㄷ 🔥

use Symfony\Component\DependencyInjection\Attribute\Autowire;
use Symfony\Component\DependencyInjection\Attribute\TaggedIterator;
use Symfony\Component\DependencyInjection\Attribute\When;

class NotificationService {
    public function __construct(
        // 환경 변수 직접 주입
        #[Autowire('%env(NOTIFICATION_API_KEY)%')]
        private string $apiKey,
        
        // 특정 서비스 명시적 주입
        #[Autowire(service: 'app.primary_mailer')]
        private MailerInterface $mailer,
        
        // 태그된 서비스들 이터레이터로 주입
        #[TaggedIterator('app.notification_channel')]
        private iterable $channels
    ) {}
}

// 특정 환경에서만 활성화
#[When(env: 'dev')]
class DebugNotificationService extends NotificationService {
    // 개발 환경에서만 사용되는 구현체
}

// 서비스에 태그 자동 추가
use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;

#[AutoconfigureTag('app.notification_channel', ['priority' => 10])]
class EmailNotificationChannel implements NotificationChannelInterface {
    public function send(string $message): void {
        // 이메일 발송
    }
}

#[AutoconfigureTag('app.notification_channel', ['priority' => 5])]
class SmsNotificationChannel implements NotificationChannelInterface {
    public function send(string $message): void {
        // SMS 발송
    }
}

Symfony 컴포넌트 기반 아키텍처와 DI 컨테이너는 처음에는 복잡해 보일 수 있어요.
근데 한 번 제대로 이해하고 나면 코드 품질, 유지보수성, 테스트 용이성이 엄청나게 올라가요.

특히 팀 프로젝트나 장기 운영 서비스에서는 이런 아키텍처가 진짜 빛을 발해요.
재능넷처럼 다양한 기능이 계속 추가되는 플랫폼을 개발할 때도 Symfony의 컴포넌트 기반 접근법이 큰 도움이 됩니다 💪

처음에는 의존성 주입 개념 → 기본 컨테이너 사용 → 자동 와이어링 → 고급 기능 순서로 차근차근 익혀가세요.
어느 순간 "아 이래서 Symfony가 PHP 생태계의 인프라구나!" 하는 순간이 올 거예요 ㅋㅋㅋ 🎉