2025년 10월 10일·7분
백엔드 애플리케이션용 PHP vs Go: 성능, 개발자 경험, 배포
백엔드 앱에 적합한 스택 선택을 위해 PHP와 Go를 비교합니다: 성능, 동시성, 도구, 호스팅, 채용, 최적 사용 사례를 확인하세요.
백엔드 앱에 적합한 스택 선택을 위해 PHP와 Go를 비교합니다: 성능, 동시성, 도구, 호스팅, 채용, 최적 사용 사례를 확인하세요.
PHP와 Go 사이를 고르는 것은 단순한 언어 선호를 넘어서—백엔드를 어떻게 설계하고 배포하며 운영할지를 결정하는 일입니다.
일반적인 백엔드 애플리케이션은 보통 다음을 섞어 가집니다:
PHP와 Go는 위 작업을 모두 처리할 수 있지만, 각각 다른 기본값으로 팀을 이끕니다.
PHP는 성숙한 웹 생태계 안에서 빠르게 움직이는 데 유리합니다: 배터리 포함 프레임워크, 저렴한 호스팅, 오랜 웹 운영 역사. 인증, 관리자 패널, CRUD, 템플레이팅, 콘텐츠 중심 사이트 같은 전형적인 웹 제품에 적합합니다.
Go는 예측 가능한 성능과 운영 단순성에 초점을 둡니다: 컴파일된 바이너리, 직관적인 동시성, 광범위한 표준 라이브러리. 높은 처리량을 다루거나 실시간 작업에 효율적인 서비스에 자주 적합합니다.
추상적인 벤치마크보다 실제 제약이 더 중요합니다:
다음 섹션에서 PHP와 Go의 운영 시 거동—성능 기본, 런타임과 동시성, 프레임워크, 개발 도구, 배포 패턴, 보안, 선택 및 마이그레이션—을 비교합니다.
PHP와 Go는 모두 튼튼한 백엔드를 만들 수 있지만 출발점이 다릅니다. PHP는 웹 중심으로 성장했고, 공유 호스팅에 널리 퍼져 있으며 요청/응답 모델에 깊이 통합되어 있습니다. Go는 나중에 서비스 지향으로 설계되어 단일 바이너리, 작은 표준 라이브러리, "한 가지를 잘하라"는 철학을 장려합니다.
PHP는 웹을 최우선으로 합니다. 프레임워크와 관례 덕분에 라우팅, 밸리데이션, 템플레이트, 큐, DB 접근까지 아이디어에서 동작하는 엔드포인트까지 빠르게 이동할 수 있습니다.
방대한 생태계—패키지, CMS 플랫폼, 호스팅 옵션—가 있어 빠른 반복과 이용 가능한 라이브러리를 중시하는 팀에는 최단 경로처럼 느껴집니다.
Go는 컴파일되므로 산출물이 보통 자체 포함 실행파일입니다. 이는 배포를 단순하고 예측 가능하게 만듭니다.
Go의 동시성 모델은 큰 매력입니다. 고루틴과 채널은 많은 병렬 작업(팬아웃 호출, 백그라운드 잡, 스트리밍 연결)을 복잡한 스레딩 코드 없이 구현하기 쉽게 합니다.
PHP는 웹 앱, 콘텐츠 중심 사이트, SaaS 대시보드, 인기 프레임워크로 만든 JSON API에 널리 사용됩니다. 기존 PHP 코드베이스나 PHP 인재 풀을 활용하려는 경우에도 흔합니다.
Go는 API, 내부 서비스, CLI 도구, 마이크로서비스 환경에서 성능 민감한 컴포넌트에 자주 쓰입니다—일관된 런타임 거동과 단순한 운영 패키징이 필요할 때 특히 적합합니다.
사람들이 PHP와 Go를 "성능"으로 비교할 때 보통 두 가지 다른 개념을 혼동합니다: 지연(latency) 과 처리량(throughput).
지연은 단일 요청이 "클라이언트 전송"에서 "클라이언트 수신"까지 걸리는 시간입니다. 엔드포인트가 느리게 느껴진다면 대개 지연 문제입니다.
처리량은 시스템이 안정적으로 처리할 수 있는 초당(또는 분당) 요청 수입니다. 트래픽 급증 시 서버가 버티지 못하면 대개 처리량 문제입니다.
언어는 둘 모두에 영향을 줄 수 있지만, 많은 백엔드 병목은 코드 주변에서 일어나는 일 때문에 생깁니다.
일부 작업은 CPU 바운드입니다: 큰 페이로드 파싱, 무거운 JSON 처리, 암호화, 이미지 조작, 데이터 변환, 복잡한 비즈니스 규칙. 이런 경로에서는 Go가 컴파일된 네이티브 바이너리로 동작하기 때문에 우위를 보이는 경우가 많습니다.
하지만 대부분의 백엔드 앱은 I/O 바운드입니다: DB 쿼리 대기, 다른 서비스 호출, 서드파티 API, 큐에서 읽기, 객체 저장소 쓰기 등. 이 경우 언어 런타임보다 중요한 것은:
PHP 서비스를 Go로 리라이트하기 전에 높은 레버리지를 주는 수정부터 찾아보세요:
요청 시간의 70–90%가 DB 및 네트워크 대기 시간이라면, 쿼리와 캐싱 개선이 대부분의 언어 수준 최적화를 능가합니다—보통 더 적은 위험과 노력으로 가능합니다.
PHP와 Go의 가장 실용적인 차이는 문법이 아니라 코드가 서버에서 "어떻게 살아 있는가"입니다.
클래식 PHP는 요청별 모델로 동작합니다: 웹서버(대개 Nginx)가 각 HTTP 요청을 PHP-FPM에 전달하면 PHP가 코드를 실행해 응답을 만들고 요청 컨텍스트는 종료됩니다.
이 모델의 결과:
현대 PHP 앱은 또한 큐, 웹소켓, 스케줄러용 장기 실행 워커를 사용합니다. 이들은 서버 프로세스처럼 동작하며 연결을 유지하고 시간이 지나면 메모리가 쌓일 수 있어 관리가 필요합니다.
Go는 보통 컴파일된 단일 바이너리로 실행되어 장기 실행 HTTP 서버를 시작합니다. 메모리에 상주하며 내부 캐시를 유지하고 요청을 연속으로 처리합니다.
프로세스 내부에서 Go는 많은 작업을 동시에 수행하기 위해 고루틴을 사용합니다. 매 요청마다 인터프리터를 띄우는 대신 동일한 런타임이 모든 것을 처리합니다.
백엔드가 대부분 "요청 들어오면 응답 하나 내보내기"라면 두 언어 모두 적합합니다. 차이는 동시에 많은 작업을 해야 하거나 장기 연결, 지속 스트리밍이 필요한 경우 나타납니다.
Go는 경량 동시성을 중심으로 설계되었습니다. 고루틴은 다른 작업과 함께 동작하는 매우 작은 "태스크"이며 채널은 안전하게 결과를 주고받는 방법입니다.
다음은 "많은 병렬 호출" 패턴의 간단한 예입니다(20개의 서비스를 호출해 결과를 모은다고 가정):
results := make(chan string, len(urls))
for _, url := range urls {
go func(u string) {
// pretend httpGet(u) does an API call
results <- httpGet(u)
}(url)
}
var out []string
for i := 0; i < len(urls); i++ {
out = append(out, <-results)
}
동시성이 런타임의 일부이기 때문에 Go는 다음에 강합니다:
클래식 PHP(특히 PHP-FPM)는 여러 독립 워커를 실행해 동시성을 처리합니다. 각 요청은 워커가 처리하고, 워커/서버를 늘려 처리량을 확장합니다. 이 모델은 전형적인 웹 앱에 단순하고 안정적입니다.
실시간 워크로드에서는 PHP도 가능하지만 보통 다음 중 하나를 선택합니다:
프레임워크 선택은 얼마나 빨리 배포하는지, 코드베이스가 어떻게 진화하는지, 팀에서 "좋은 구조"가 무엇인지를 좌우합니다. PHP와 Go는 모두 깔끔한 백엔드를 지원하지만 서로 다른 기본값으로 팀을 유도합니다.
PHP의 중심에는 배터리 포함 프레임워크—주로 Laravel과 Symfony—가 있습니다. 이들은 라우팅, 컨트롤러, 템플레이트, ORM, 마이그레이션, 큐, 백그라운드 잡, 밸리데이션, 인증에 대한 확립된 패턴을 제공합니다.
이는 일관된 "골든 패스"를 원할 때 유리합니다: 예측 가능한 폴더 구조, 표준 미들웨어 파이프라인, 의사결정 피로를 줄이는 관례. 많은 백엔드에서는 프레임워크 자체가 곧 아키텍처입니다: MVC와 서비스 클래스, 레포지토리, 이벤트, 잡 등의 조합.
위험은 프레임워크 매직에 과도하게 의존하는 것입니다. 관례는 복잡성을 숨길 수 있고(암묵적 컨테이너 연결, ORM 행위, 라이프사이클 훅), 큰 앱은 경계를 의도적으로 강제하지 않으면 프레임워크 형태의 모놀리식으로 굳어질 수 있습니다.
Go 팀은 보통 net/http로 시작해 소규모 집중 라이브러리를 조합합니다: 라우터(chi, gorilla/mux, httprouter 등), 로깅, 구성, 메트릭, DB 접근. "프레임워크"도 존재하지만 미니멀리즘이 일반적입니다: 아키텍처는 보통 명확한 인터페이스를 가진 패키지들의 집합입니다.
이 명시적 구성은 데이터 흐름과 의존성을 보기 쉽게 만듭니다. 또한 "클린/헥사고날" 경계나 HTTP 핸들러를 얇게 두고 비즈니스 로직을 테스트 가능하게 하는 패턴을 촉진합니다.
어느 쪽이 자동으로 더 나은 것은 아닙니다—프레임워크에 의존할 정도를 얼마나 원하는지, 직접 결정하고 구성할 의지가 있는지에 따라 선택하세요.
개발자 경험은 PHP와 Go가 일상에서 가장 다르게 느껴지는 부분입니다: PHP는 "빠르게 뭔가 돌려보는" 데 최적화된 반면, Go는 "어디서나 일관되게" 동작하도록 최적화되어 있습니다.
PHP는 실행 방식(Apache/Nginx + PHP-FPM, 내장 서버, Docker)에 따라 설정이 달라집니다. 많은 팀이 OS별 차이를 피하기 위해 Docker로 표준화합니다.
의존성 관리는 성숙하고 친숙합니다: Composer와 Packagist로 라이브러리 추가가 간편하고, 프레임워크(Laravel/Symfony)가 구성과 부트스트랩 관례를 제공합니다.
Go는 보통 설치가 단순합니다: 하나의 런타임, 하나의 컴파일러, 예측 가능한 툴체인. Go 모듈이 내장되어 있고 버전 관리가 명확하며 빌드는 별도 패키지 매니저 없이 재현 가능합니다.
PHP는 PHPUnit/Pest와 같은 폭넓은 유닛·통합 테스트 생태계를 갖추고 있습니다. 프레임워크는 HTTP 테스트, DB 트랜잭션, 픽스처용 헬퍼를 제공해 현실적인 테스트 작성 속도를 높입니다.
Go는 표준 라이브러리에 테스트가 포함되어 있습니다(go test). 이는 기본적인 테스트가 모든 프로젝트에서 동일하게 적용된다는 장점이 있습니다. 목킹은 인터페이스와 페이크를 선호하는 패턴이 많고, 코드 생성 도구를 쓰기도 합니다. 통합 테스트는 흔하지만 보통 프레임워크 헬퍼보다 자체 테스트 하네스를 구성합니다.
PHP 디버깅은 주로 Xdebug(중단점, 스택 트레이스)와 프레임워크 오류 페이지에 중심을 둡니다. 프로파일링은 Blackfire나 Xdebug 프로파일러로 합니다.
Go는 강력한 내장 도구를 가집니다: 스택 덤프, 레이스 검출기, CPU/메모리 프로파일링용 pprof. 관찰성 측면에서 두 생태계 모두 OpenTelemetry와 일반 APM과 잘 연동되지만, Go는 명시적 계측이 더 자주 필요하고 PHP 프레임워크는 더 많은 기본 후크를 제공할 수 있습니다.
둘 중 하나를 결정하기 전에 비용을 줄이려면 동일한 엔드포인트와 백그라운드 잡을 병렬로 프로토타이핑하는 것이 유용합니다. 예를 들어 Koder.ai 같은 플랫폼은 채팅으로 서비스를 설명하면 동작하는 웹 UI(React)와 백엔드(Go + PostgreSQL)를 생성하고 아키텍처 선택을 빠르게 반복할 수 있게 도와줍니다. 실제 프로토타입을 빠르게 배포하고 소스 코드를 내보낼 수 있으면 “데이투” 현실을 빨리 평가하기 좋습니다.
배포는 PHP와 Go가 가장 다르게 느껴지는 부분입니다: PHP는 보통 "웹서버 안에서 동작하는 앱"이고, Go는 보통 "실행해서 운영하는 서버"입니다. 이 차이는 호스팅 선택부터 업데이트 롤아웃 방식까지 모든 것을 바꿉니다.
PHP는 낮은 마찰의 호스팅에서 강점을 보입니다. 공유 호스팅이나 기본 VPS에서 Apache나 Nginx + PHP-FPM으로 잘 동작하고 많은 제공자가 이미 합리적 기본값을 제공합니다. 배포는 보통 코드 복사, 의존성 설치(Composer), 웹 스택이 요청을 처리하도록 하는 식입니다.
Go는 단일 정적 바이너리(또는 작은 컨테이너 이미지)로 배포되는 경우가 많습니다. 이로 인해 이식성과 예측 가능성이 높지만 VPS + systemd, Docker, Kubernetes 같은 운영 체계로 향하게 합니다. "PHP-FPM 설정" 대신 포트에서 서비스로 실행하고 Nginx(또는 로드밸런서)를 앞에 둡니다.
PHP는 버전, 확장, Composer 의존성을 서버 전반에 걸쳐 조정해야 하는 경우가 있습니다. 프로세스 관리는 보통 PHP-FPM이 담당하고, 블루/그린 또는 제로 다운타임 배포는 가능하지만 OPcache, 워밍업, 공유 상태 관리를 신중히 해야 합니다.
Go는 장기 실행 프로세스를 관리합니다. 로드밸런서와 롤링 업데이트로 제로 다운타임 배포가 비교적 간단합니다(또는 일부 설정에서는 systemd 소켓 활성화를 사용할 수 있음). 구성(env vars), 헬스체크, 그레이스풀 셧다운에 대한 표준 관행을 도입하세요.
기술 선택은 시간이 지날수록 사람 문제로 전환됩니다: 누가 안전하게 코드를 변경할 수 있는지, 새 팀원이 얼마나 빨리 생산적이 되는지, 의존성 업데이트 비용이 얼마인지.
PHP 프로젝트는 특히 풀스택 앱에서 프레임워크와 패키지 표면적이 커지는 경향이 있습니다. 이는 괜찮지만 장기 비용은 종종 의존성 업데이트, 보안 패치, 프레임워크 메이저 업그레이드에 의해 좌우됩니다. 모듈 경계, 일관된 네이밍, 규율 있는 패키지 관리가 언어보다 더 중요할 때가 많습니다.
Go는 보통 작은 의존성 그래프와 "우선 표준 라이브러리" 마인드를 유도합니다. gofmt 같은 포맷팅과 관례 중심 도구가 있어 코드베이스가 팀 전반에 걸쳐 더 균일하게 느껴지는 경우가 많습니다. 반대급부로, Go 서비스가 명확한 아키텍처 없이 커지면 내부 패키지가 얽힐 수 있고, 언어가 그걸 자동으로 막아주지는 않습니다.
팀이 이미 PHP(Laravel/Symfony)에 익숙하면 온보딩이 빠릅니다: 생태계가 익숙하고 커뮤니티 관행이 풍부합니다.
Go는 배우기 비교적 직관적이지만 동시성, 에러 처리, 서비스 구조에 대한 사고방식 전환이 필요할 수 있습니다. 작은 서비스에서는 빠르게 생산적이 될 수 있지만 성능과 동시성 패턴에 자신감이 생기기까지 시간이 걸릴 수 있습니다.
PHP 인재는 웹 제품팀과 에이전시에서 널리 구할 수 있어 "해결하려는 일을 해낼" 개발자를 찾기 쉬운 편입니다.
Go 개발자는 API, 인프라, 마이크로서비스를 구축하는 회사에서 흔하지만 지역에 따라 풀(pool)이 작을 수 있습니다. 빠른 팀 성장을 예상한다면 지역 채용 시장을 확인하고 내부 교육에 투자할지 고려하세요.
실용적인 규칙: 2시(심야)에도 팀이 침착하게 유지·운영할 수 있는 언어를 선택하세요—어느 쪽이든 의존성과 업그레이드 작업에 시간을 예산으로 잡아두어야 합니다.
보안은 "PHP vs Go" 기능 문제보다 백엔드를 어떻게 구축·운영하는지의 습관 문제입니다. 두 언어 모두 적절히 구성하면 안전하고, 잘못 사용하면 노출될 수 있습니다.
입력 검증과 출력 이스케이프가 양 생태계의 1차 방어선입니다. PHP 프레임워크(Laravel, Symfony)는 요청 검증과 템플릿을 통한 XSS 방지를 장려합니다. Go에서는 보통 라이브러리로 직접 검증을 구성하는 경우가 많아, 규율 있게 하면 더 안전하지만 빠르게 개발할 때 실수로 놓치기 쉽습니다.
인증과 인가는 양쪽에서 성숙한 솔루션이 있습니다. PHP는 세션, 쿠키, CSRF 보호, 패스워드 해싱에 대한 검증된 라이브러리와 통합이 풍부합니다. Go는 암호화 패키지, 미들웨어 패턴이 탄탄하고 JWT/OAuth2 라이브러리도 많지만 조합을 직접 구성하는 일이 많습니다.
의존성 업데이트는 동일하게 중요합니다. PHP는 Composer 패키지에 의존하고, Go는 모듈과 강한 버전 관리 툴체인을 사용합니다. 공급망 위험은 어느 쪽도 사라지지 않으므로 검토, 버전 고정, 업데이트 루틴이 필요합니다.
구성 실수가 빈번한 원인입니다.
PHP의 흔한 실수: 디버그 모드 노출, .env 파일 유출, 업로드 처리 권한 부여 부주의, 안전하지 않은 역직렬화, 소스 파일에 대한 접근을 허용하는 잘못된 웹서버 규칙.
Go의 흔한 실수: 커스텀 인증 미들웨어 오류, 너무 관대한 CORS, 로그에 비밀 기록, 프록시 헤더 무분별한 신뢰, 클라이언트 호출에서 TLS 검증을 끄는 실수.
어느 언어든 복사·붙여넣기한 코드나 유지보수가 중단된 라이브러리 사용은 사고로 이어질 수 있습니다.
항상 다음을 준수하세요:
보안을 팀의 "완료 정의(definition of done)"에 포함시키세요. 따로 떼어놓은 단계가 되어서는 안 됩니다.
PHP와 Go 중 어느 것이 "더 낫다"는 문제가 아니라, 당신이 만드는 백엔드의 성격, 팀의 작업 방식, 어디에 단순함을 원하느냐(일상 개발 vs 런타임/운영)에 따라 다릅니다.
PHP는 웹 제품 자체가 중심일 때 강점을 발휘합니다—페이지, 폼, 관리자, 콘텐츠, 빠른 반복 개발 등.
대부분의 요청이 짧은 HTTP 상호작용(페이지 렌더링, 입력 검증, DB 읽기/쓰기, 응답)이라면 PHP의 장점이 빠르게 드러납니다.
Go는 백엔드가 전통적 웹 앱보다 서비스에 가깝게 동작할 때 우위를 보입니다.
Go 런타임과 표준 라이브러리는 장기 실행 프로세스와 동시성이 중요한 워크로드에 자연스럽게 어울립니다.
많은 팀은 둘을 조합해 최적 결과를 얻습니다:
이렇게 하면 위험을 줄일 수 있습니다: 이미 생산적인 부분은 유지하고, 운영·성능상의 명확한 이점이 있는 부분만 Go로 도입하세요.
선택을 쉽게 하려면 "선호"를 몇 가지 제약으로 바꾸세요. 목표는 미래를 완벽히 예측하는 것이 아니라 6개월 후 비싼 리라이트를 강요하지 않는 선택을 하는 것입니다.
다음 질문으로 방향을 압박해 보세요:
실용적 지름길: 트래픽이 불확실하고 빠른 반복이 필요하면 팀이 자신있게 배포할 수 있는 것으로 시작하세요—그리고 교체 가능하도록 경계를 설계하세요.
현재 PHP 시스템이 있고 특정 기능 때문에 Go가 필요하면 점진적으로 옮길 수 있습니다:
제품이 주로 CRUD 페이지, 폼, 관리자 패널, 콘텐츠 중심 흐름이라면 PHP(특히 Laravel/Symfony)가 가장 빠른 배포 경로인 경우가 많습니다.
백엔드가 장시간 실행되는 서비스(고동시성, 스트리밍/WebSocket, 많은 병렬 I/O)라면 Go를 선택하세요. Go는 단일 바이너리로 예측 가능한 배포를 제공하기도 합니다.
일반적으로 CPU 바운드 작업과 고동시성 환경에서 Go가 더 빠른 경우가 많습니다. 하지만 많은 실제 시스템은 I/O 바운드입니다(데이터베이스, 네트워크 호출). 이런 경우 언어보다 중요한 것은:
실제 워크로드에서 p95 지연과 처리량을 측정해 보고, 리라이트가 도움이 되는지 확인하세요.
PHP는 보통 PHP-FPM을 통해 요청마다 실행됩니다: 각 요청은 워커 프로세스가 처리하고, 요청이 끝나면 메모리가 해제됩니다.
Go는 보통 장기 실행 프로세스로 동작하며, 고루틴으로 많은 요청을 계속 처리합니다. 이는 그레이스풀 셧다운, 장기 메모리 거동, 계측 같은 운영 이슈에 대한 고려사항을 바꿉니다만, 요청당 해석기 오버헤드를 줄여줄 수 있습니다.
PHP-FPM에서는 동시성이 보통 워커/프로세스 수를 늘리는 방식으로 해결됩니다. 요청/응답 앱에서는 간단하고 신뢰할 만한 방법입니다.
Go에서는 고루틴과 채널이 1급 시민이라서:
같은 작업을 자연스럽게 구현할 수 있습니다.
PHP도 가능하지만 보통 또는 같은 라이브러리를 사용하거나, 워커 기반으로 팬아웃을 처리합니다.
표준적인 웹 요구를 빠르게 해결하고 싶다면 PHP 프레임워크가 유리합니다:
Go에서는 보통 net/http + 경량 라이브러리 조합을 선호하며, 명시적 구성으로 의존성이 더 명확해집니다. 즉, PHP는 "골든 패스"를 제공하고, Go는 구성과 제어를 강조합니다.
Go는 단일 컴파일 바이너리(또는 작은 컨테이너)를 배포하는 경우가 많아 운영이 단순한 편입니다. 포트에서 서비스로 실행하고 로드밸런서를 앞에 두면 됩니다.
PHP는 보통 코드 + Composer 의존성 + PHP-FPM/Nginx 구성과 OPcache 워밍업, 워커 튜닝 같은 운영 세부사항이 필요합니다. 전통적인 호스팅에서는 PHP가 매우 편리하고, 컨테이너화/서비스 지향 환경에서는 Go가 더 단순할 수 있습니다.
PHP는 여러 FPM 워커를 운영하기 때문에 시스템 차원에서 메모리 사용량이 클 수 있습니다.
Go는 보통 하나의 프로세스지만 아래로 인해 메모리가 증가할 수 있습니다:
어떤 스택을 선택하든 실제 트래픽으로 메모리를 모니터링하고 제한을 설정하세요( PHP는 워커 수, Go는 리소스 요청/제한과 프로파일링).
위험을 최소화하는 현실적인 방법:
데이터베이스를 공용으로 쓰려면 쓰기 소유권 규칙을 명확히 정의해 충돌을 방지하세요.
두 스택 모두 대부분의 보안 사고는 구성 실수와 통제 부재에서 옵니다.
일반적인 PHP 위험: 디버그 모드 노출, .env 노출, 업로드 처리 부주의, 안전하지 않은 역직렬화, 잘못된 웹서버 규칙.
일반적인 Go 위험: 인증 미들웨어 오류, 광범위한 CORS 허용, 로그에 비밀 노출, 프록시 헤더 신뢰, TLS 검증 생략.
언어에 관계없이 다음을 지키세요: 파라미터라이즈드 쿼리, 엄격한 밸리데이션, 비밀 관리, 의존성 패치, HTTPS, 레이트 리미팅.
실제 환경과 유사한 소규모 E2E 비교를 실행하세요:
대부분의 경우, 팀이 안정적으로 배포·운영할 수 있는 스택이 승리합니다.