2025년 5월 01일·7분
임베딩과 게임 스크립팅에 Lua가 탁월한 이유
작은 런타임, 빠른 실행, 간단한 C API, 코루틴, 샌드박싱 옵션, 우수한 이식성 등 Lua가 임베딩과 게임 스크립팅에 적합한 이유를 살펴봅니다.
작은 런타임, 빠른 실행, 간단한 C API, 코루틴, 샌드박싱 옵션, 우수한 이식성 등 Lua가 임베딩과 게임 스크립팅에 적합한 이유를 살펴봅니다.
스크립팅 언어를 “임베딩”한다는 건 애플리케이션(예: 게임 엔진)이 언어 런타임을 포함해서 함께 배포하고, 애플리케이션 코드가 그 런타임을 호출해 스크립트를 로드·실행한다는 의미입니다. 플레이어는 별도로 Lua를 시작하거나 설치하거나 패키지를 관리하지 않습니다. Lua는 단지 게임의 일부일 뿐입니다.
반대로 독립 실행형 스크립팅은 스크립트가 자체 인터프리터나 도구(예: 커맨드 라인에서 스크립트 실행)에서 돌 때를 말합니다. 자동화에는 좋지만 모델이 다릅니다: 애플리케이션이 호스트가 아니라 인터프리터가 호스트입니다.
게임은 반복 속도가 다른 서브시스템들의 혼합체입니다. 저수준 엔진 코드(렌더링, 물리, 스레딩)는 C/C++의 성능과 엄격한 제어가 유리합니다. 반면 게임플레이 로직, UI 흐름, 퀘스트, 아이템 튜닝, 적 행동 등은 전체 빌드를 다시 하지 않고 빠르게 편집 가능한 이점이 큽니다.
언어를 임베딩하면 팀이:
사람들이 Lua를 임베딩용으로 “선택되는 언어”라 부를 때, 모든 것에 완벽하다는 뜻은 아닙니다. 대신 프로덕션에서 검증되었고, 통합 패턴이 예측 가능하며, 출시 게임에 맞는 실용적 절충(작은 런타임, 강한 성능, 오랜 기간 다듬어진 C 친화적 API)을 제공한다는 의미입니다.
다음으로 Lua의 풋프린트와 성능, C/C++ 통합이 보통 어떻게 이루어지는지, 코루틴이 게임플로우에 무엇을 가능하게 하는지, 테이블/메타테이블이 데이터 주도 설계에 어떻게 기여하는지 살펴보겠습니다. 또한 샌드박싱 옵션, 유지보수성, 툴링, 다른 언어와의 비교, Lua가 엔진에 적합한지 판단할 체크리스트도 제공합니다.
Lua 인터프리터는 잘 알려진 대로 작습니다. 게임에서는 추가되는 메가바이트 하나하나가 다운로드 크기, 패치 시간, 메모리 압력, 일부 플랫폼의 인증 제약에 영향을 미치므로 중요합니다. 컴팩트한 런타임은 또한 빠르게 시작되는 경향이 있어 에디터 도구, 스크립팅 콘솔, 빠른 반복 워크플로에서 유리합니다.
Lua 코어는 군더더기가 적습니다: 작동 부품이 적고 숨겨진 서브시스템이 적으며 추론 가능한 메모리 모델을 갖고 있습니다. 많은 팀에게 이는 예측 가능한 오버헤드로 이어집니다—대개 메모리는 엔진과 콘텐츠가 지배하고 스크립팅 VM은 그렇지 않습니다.
작은 코어가 진짜 빛을 발하는 건 이식성입니다. Lua는 포터블 C로 작성되어 데스크탑, 콘솔, 모바일에서 널리 사용됩니다. 엔진이 이미 여러 대상에서 C/C++을 빌드한다면 Lua는 일반적으로 같은 파이프라인에 무리 없이 들어갑니다. 이는 동작 차이나 런타임 기능 누락 같은 플랫폼 깜짝을 줄여줍니다.
Lua는 보통 작은 정적 라이브러리로 빌드되거나 프로젝트에 직접 컴파일됩니다. 설치해야 할 무거운 런타임이나 맞춰야 할 큰 의존성 트리가 없습니다. 외부 요소가 적을수록 버전 충돌, 보안 업데이트 사이클, 빌드 실패 가능성이 줄어듭니다—오래 유지되는 게임 브랜치에서 특히 가치 있습니다.
경량 스크립팅 런타임은 단지 배포를 쉽게 하는 것 이상입니다. 에디터 유틸리티, 모드 도구, UI 로직, 퀘스트 로직, 자동화 테스트 등 더 많은 곳에 스크립트를 넣을 수 있게 해 주며, 코드베이스에 "새로운 플랫폼을 추가"하는 느낌을 주지 않습니다. 바로 이 유연성이 많은 팀이 게임 엔진에 Lua를 임베딩하는 큰 이유입니다.
게임 팀은 드물게 스크립트가 프로젝트에서 "가장 빠른 코드"가 되길 원합니다. 대신 스크립트가 디자이너가 반복 작업을 할 때 프레임률이 무너지지 않게 충분히 빠르고, 스파이크를 진단하기 쉽도록 예측 가능하길 원합니다.
대부분 타이틀에서 "충분히 빠름"은 프레임 당 밀리초 예산으로 측정됩니다. 스크립팅 작업이 게임플레이 로직에 할당된 조각(보통 전체 프레임의 일부) 안에 머무르면 플레이어는 차이를 느끼지 못합니다. 목표는 최적화된 C++를 능가하는 것이 아니라 프레임 당 스크립트 작업을 안정적으로 유지하고 갑작스러운 가비지나 할당 버스트를 피하는 것입니다.
Lua는 작은 가상 머신에서 코드를 실행합니다. 소스는 바이트코드로 컴파일되고 VM이 이를 실행합니다. 프로덕션에서는 미리 컴파일된 청크를 배포해 런타임 파싱 오버헤드를 줄이고 실행을 비교적 일관되게 유지할 수 있습니다.
Lua VM은 함수 호출, 테이블 접근, 분기 같은 스크립트가 자주 하는 연산에 맞춰 조정되어 있어 전형적인 게임플레이 로직은 제약된 플랫폼에서도 부드럽게 동작하는 편입니다.
Lua는 흔히 다음 용도로 사용됩니다:
Lua는 보통 물리 통합, 애니메이션 스키닝, 경로탐색의 핵심 커널, 파티클 시뮬레이션 같은 핫(inner) 루프 용도로 쓰이지 않습니다. 그런 부분은 C/C++에 두고 Lua는 고수준 함수로 노출합니다.
몇 가지 습관이 실제 프로젝트에서 Lua를 빠르게 유지합니다:
Lua가 게임 엔진에서 명성을 얻은 이유 중 하나는 통합 스토리가 단순하고 예측 가능하기 때문입니다. Lua는 작은 C 라이브러리로 제공되며, Lua C API는 스택 기반 인터페이스를 중심으로 설계되었습니다.
엔진 측에서 Lua 상태를 만들고 스크립트를 로드하고 값을 스택에 푸시해 함수를 호출합니다. 이 과정은 "마법"이 아니기 때문에 신뢰할 수 있습니다: 경계 너머를 지나는 모든 값을 볼 수 있고 타입을 검증하며 오류 처리 방식을 결정할 수 있습니다.
전형적인 호출 흐름은:
C/C++ → Lua는 AI 선택, 퀘스트 로직, UI 규칙, 능력 수식 같은 스크립트 결정에 적합합니다.
Lua → C/C++는 엔진 액션(엔티티 생성, 오디오 재생, 물리 쿼리, 네트워크 전송)에 이상적입니다. 종종 모듈 스타일 테이블 형태로 C 함수를 노출합니다:
lua_register(L, "PlaySound", PlaySound_C);
스크립트 측에서는 자연스럽게 호출됩니다:
PlaySound("explosion_big")
수동 바인딩(직접 작성한 glue)은 작고 명시적이어서 노출하는 API 표면이 제한적일 때 완벽합니다.
생성기(SWIG 스타일 도구나 커스텀 리플렉션 툴)는 큰 API를 빠르게 노출시킬 수 있지만 너무 많은 것을 노출하거나 혼란스러운 오류 메시지를 만들 수 있습니다. 많은 팀은 데이터 타입에는 생성기를, 게임플레이 대상 함수에는 수동 바인딩을 섞어 씁니다.
잘 구조화된 엔진은 보통 "모든 것"을 Lua에 던져 넣지 않습니다. 대신 포커스된 서비스와 컴포넌트 API를 노출합니다:
이 분리는 스크립트를 표현력 있게 유지하면서 엔진은 성능 핵심 시스템과 가드레인을 통제하도록 합니다.
Lua 코루틴은 스크립트가 전체 게임을 멈추지 않고 일시중단/재개할 수 있게 해주므로 게임플레이 로직에 자연스럽게 맞습니다. 수많은 상태 플래그로 퀘스트나 컷신을 분할하는 대신 직선적인 순서로 작성하고 기다려야 할 때마다 yield하면 됩니다. 엔진은 조건이 충족될 때 코루틴을 재개합니다.
대부분의 게임플레이 작업은 단계적입니다: 대사 한 줄 보여주기 → 플레이어 입력 대기 → 애니메이션 재생 → 2초 대기 → 적 스폰 등. 코루틴을 쓰면 각 대기 지점은 단순한 yield()가 됩니다. 엔진은 조건이 충족되면 해당 코루틴을 재개합니다.
코루틴은 협력적입니다(선점형 아님). 게임에서는 이 점이 장점입니다: 스크립트가 어디에서 일시중단될지 개발자가 결정하므로 동작이 예측 가능하고 많은 스레드 안전성 문제(락, 레이스, 공유 데이터 경쟁)를 피할 수 있습니다. 게임 루프가 주 컨트롤을 유지합니다.
일반적 접근법은 내부적으로 yield하는 wait_seconds(t), wait_event(name), wait_until(predicate) 같은 엔진 함수를 제공하는 것입니다. 스케줄러는(보통 실행 중 코루틴 목록) 각 프레임마다 타이머/이벤트를 검사해 준비된 코루틴을 재개합니다.
결과: 스크립트는 비동기처럼 느껴지면서도 추론하기 쉽고 디버그 및 결정론적 유지가 용이합니다.
Lua의 “비밀 무기”는 테이블입니다. 테이블 하나로 객체, 사전, 리스트, 중첩 구성 블롭 등 다양한 역할을 할 수 있습니다. 덕분에 엔진 코드를 새로 작성하거나 복잡한 파싱 코드를 만들 필요 없이 게임플레이 데이터를 모델링할 수 있습니다.
모든 파라미터를 C++에 하드코딩하는 대신 디자이너가 테이블로 콘텐츠를 표현할 수 있습니다:
Enemy = {
id = "slime",
hp = 35,
speed = 2.4,
drops = { "coin", "gel" },
resist = { fire = 0.5, ice = 1.2 }
}
이 방식은 확장성이 좋습니다: 필요한 필드를 추가하고, 필요 없으면 생략하며, 오래된 콘텐츠는 계속 작동하게 할 수 있습니다.
테이블은 무기, 퀘스트, 능력 같은 게임플레이 객체를 빠르게 프로토타입하고 현장에서 조정하기 자연스럽게 해 줍니다. 반복 과정에서 행동 플래그를 바꾸거나 쿨다운을 조정하거나 특별 규칙용 서브테이블을 추가할 수 있으며 엔진 코드를 건드릴 필요가 줄어듭니다.
메타테이블을 통해 많은 테이블에 공유 동작을 붙일 수 있습니다—경량 클래스 시스템처럼 동작합니다. 기본값(예: 누락된 스탯), 계산 속성, 간단한 상속 유사 재사용을 정의하면서 콘텐츠 작성자가 읽기 쉬운 데이터 형식을 유지할 수 있습니다.
엔진이 테이블을 기본 콘텐츠 단위로 다루면 모드는 간단해집니다: 모드는 테이블 필드를 오버라이드하거나 드롭 리스트를 확장하거나 새 아이템을 추가하는 식으로 동작합니다. 결과적으로 튜닝과 확장이 쉬운 게임이 되고 커뮤니티 콘텐츠와도 친화적이며 스크립팅 레이어가 복잡한 프레임워크로 변질되지 않습니다.
Lua를 임베딩하면 스크립트가 무엇에 접근할 수 있는지를 개발자가 책임져야 합니다. 샌드박싱은 스크립트가 게임플레이 API만 호출하도록 제한하고 호스트 머신, 민감한 파일, 엔진 내부의 노출되지 않을 부분 접근을 막는 규칙 집합입니다.
실용적 기준선은 최소 환경에서 시작해 기능을 의도적으로 추가하는 것입니다.
io와 os를 완전히 비활성화합니다.loadfile 비활성화, load를 허용할 경우 패키지된 콘텐츠처럼 사전 승인된 소스만 허용전체 글로벌 테이블을 노출하는 대신 디자이너나 모더가 호출해야 할 함수들을 모은 하나의 game(또는 engine) 테이블을 제공합니다.
샌드박싱은 또한 스크립트가 프레임을 멈추거나 메모리를 고갈시키는 것을 막는 일입니다.
일급 스크립트와 모드를 다르게 취급하세요.
Lua는 반복 속도 때문에 도입되는 경우가 많지만 장기적 가치는 프로젝트가 수개월의 리팩터링을 거쳐도 스크립트가 계속 동작할 때 드러납니다. 이를 위해 몇 가지 의도적인 관행이 필요합니다.
Lua에 노출되는 API를 제품 인터페이스처럼 다루고 C++ 클래스의 직접 노출을 피하세요. 작은 게임플레이 서비스(스폰, 사운드 재생, 태그 조회, 대화 시작 등)를 노출하고 엔진 내부는 비공개로 유지하면 경계 변경으로 인한 파괴력이 줄어듭니다.
파괴적 변경은 피할 수 없습니다. 이를 관리 가능하게 만들려면 스크립트 모듈이나 노출 API에 버전 관리를 도입하세요:
간단한 API_VERSION 상수만 있어도 스크립트가 올바른 경로를 선택하는 데 도움이 됩니다.
핫리로드는 코드를 재로딩하되 런타임 상태는 엔진이 소유할 때 가장 신뢰할 만합니다. 능력, UI 동작, 퀘스트 규칙을 재로딩하고 메모리·물리 바디·네트워크 연결을 소유한 객체는 재로딩하지 않는 것이 안정적입니다.
실용적 방법은 모듈을 재로딩한 뒤 기존 엔티티에 콜백을 재바인딩하는 것입니다. 더 깊은 리셋이 필요하면 모듈 부작용에 의존하지 말고 명시적 초기화 훅을 제공하세요.
스크립트 오류는 다음을 알려줘야 합니다:
Lua 오류는 엔진 메시지와 동일한 인게임 콘솔과 로그 파일로 라우팅하고 스택 트레이스를 보존하세요. 디자이너가 읽었을 때 조치 가능한 티켓처럼 보이면 수정이 빨라집니다.
Lua의 가장 큰 툴링 장점은 엔진과 같은 반복 루프에 자연스럽게 들어맞는다는 점입니다: 스크립트를 로드하고 게임을 돌리고 결과를 확인하고 수정하고 재로딩. 핵심은 그 루프를 팀 전체에 관찰 가능하고 반복 가능하게 만드는 것입니다.
일상 디버깅에는 세 가지 기본이 필요합니다: 스크립트 파일에 브레이크포인트 설정, 한 줄씩 스텝, 값 감시. 많은 스튜디오는 Lua의 디버그 훅을 에디터 UI에 노출하거나 기성 원격 디버거를 통합해 이 기능을 제공합니다.
완전한 디버거가 없더라도 개발자 편의 기능을 추가하세요:
스クリ프트 성능 문제는 대개 "Lua 자체가 느리다"가 아니라 "이 함수가 프레임당 10,000번 호출된다" 같은 경우입니다. 스크립트 진입점(AI 틱, UI 업데이트, 이벤트 핸들러)에 가벼운 카운터와 타이머를 추가하고 함수명별로 집계하세요.
핫스팟을 찾으면 다음 중 하나를 결정합니다:
스크립트를 코드처럼 다루세요. 순수 Lua 모듈(게임 규칙, 수학, 전리품 테이블)에 대한 유닛 테스트와 핵심 흐름을 실행하는 통합 테스트를 수행하세요.
빌드에서는 스크립트를 예측 가능한 방식으로 패키징하세요: 평문 파일(패치 쉬움) 또는 번들 아카이브(흩어진 에셋 감소) 중 하나를 선택합니다. 어느 쪽이든 빌드 타임에 문법 검사, 필수 모듈 존재 확인, 모든 스크립트를 로드하는 스모크 테스트를 실행해 출시 전에 누락 에셋을 잡으세요.
스크립트 주변의 내부 도구(예: 웹 기반 스크립트 레지스트리, 프로파일링 대시보드, 콘텐츠 검증 서비스)를 만들 계획이라면 Koder.ai 같은 도구가 프로토타이핑과 출시를 빠르게 도와줄 수 있습니다. 채팅을 통해 전체 스택 애플리케이션(일반적으로 React + Go + PostgreSQL)을 생성하고 배포·호스팅·스냅샷/롤백을 지원하므로 스튜디오 툴을 빠르게 돌려볼 때 유용합니다.
스크립팅 언어 선택은 "최고"를 고르는 문제가 아니라 엔진, 배포 대상, 팀에 무엇이 맞느냐의 문제입니다. Lua는 경량, 게임플레이에 충분한 성능, 임베딩이 단순한 언어가 필요할 때 강점을 보입니다.
Python은 툴과 파이프라인에 훌륭하지만 게임 내에 임베드할 경우 더 무거운 런타임을 요구합니다. Python을 임베드하면 더 많은 의존성이 따라오고 통합 면이 더 복잡해지는 경향이 있습니다.
반면 Lua는 메모리 풋프린트가 훨씬 작고 플랫폼 간 번들링이 쉽습니다. 또한 임베딩을 위해 처음부터 설계된 C API를 가지고 있어 엔진 호출(및 그 반대)이 더 단순하게 느껴지는 경우가 많습니다.
속도 측면에서: 고수준 로직에는 Python도 충분히 빠를 수 있지만, Lua의 실행 모델과 게임에서의 일반적 사용 패턴은 빈번히 호출되는 스크립트(AI 틱, 능력 로직, UI 업데이트)에 더 적합한 경우가 많습니다.
JavaScript는 많은 개발자가 이미 알고 있고 최신 JS 엔진은 매우 빠르다는 매력이 있습니다. 단점은 런타임 무게와 통합 복잡성입니다: 전체 JS 엔진을 배포하는 것은 더 큰 작업이고 바인딩 레이어 자체가 하나의 프로젝트가 될 수 있습니다.
Lua 런타임은 훨씬 가볍고 임베딩 스토리는 게임 엔진 스타일 호스트 애플리케이션에서 대개 더 예측 가능합니다.
C#은 생산성 높은 워크플로, 훌륭한 툴링, 익숙한 객체지향 모델을 제공합니다. 이미 매니지드 런타임을 호스팅하고 있다면 반복 속도와 개발자 경험은 훌륭할 수 있습니다.
하지만 맞춤 엔진을 제작하거나(특히 제약이 큰 플랫폼의 경우) 매니지드 런타임을 호스팅하면 바이너리 크기, 메모리 사용량, 시작 비용이 증가할 수 있습니다. Lua는 더 작은 런타임 풋프린트로 충분히 좋은 사용성을 제공하는 경우가 많습니다.
제약이 엄격(모바일, 콘솔, 맞춤 엔진)하고 임베딩된 스크립팅 언어가 눈에 띄지 않게 동작하길 원하면 Lua가 경쟁력이 큽니다. 반면 개발자 친숙성이나 이미 특정 런타임(JS나 .NET)에 의존하고 있다면 팀의 강점에 맞추는 것이 Lua의 풋프린트 이점보다 우선일 수 있습니다.
Lua를 임베딩할 때는 엔진 내부의 하나의 제품으로 다루는 게 가장 좋습니다: 안정적 인터페이스, 예측 가능한 동작, 콘텐츠 제작자가 생산적으로 작업하도록 돕는 가드레일.
원시 엔진 내부를 노출하기보다 작은 엔진 서비스 집합을 노출하세요. 전형적 서비스로는 시간, 입력, 오디오, UI, 스폰, 로깅이 있습니다. 스크립트가 폴링하지 않고 반응하도록 이벤트 시스템을 제공해("OnHit", "OnQuestCompleted" 같은) 반응형으로 구성하세요.
데이터 접근은 명시적으로 유지: 설정용은 읽기 전용 뷰, 상태 변경은 통제된 쓰기 경로. 이렇게 하면 테스트·보안·진화가 쉬워집니다.
Lua는 규칙, 오케스트레이션, 콘텐츠 로직에 사용하고 무거운 작업(경로탐색, 물리 쿼리, 애니메이션 평가, 대규모 루프)은 네이티브로 두세요. 규칙 예시: 많은 엔티티에 대해 매 프레임 실행되는 작업이라면 C/C++로 두고 Lua 친화적 래퍼로 노출하세요.
초기에 규칙을 정하세요: 모듈 레이아웃, 명명법, 스크립트가 실패를 알리는 방식. 오류를 throw할지, nil, err를 반환할지, 이벤트를 발생시킬지 결정하세요.
로깅을 중앙화하고 스택 트레이스를 실무에 쓸 수 있게 만드세요. 스크립트가 실패하면 엔티티 ID, 레벨 이름, 마지막으로 처리한 이벤트를 포함하세요.
현지화: 문자열을 로직에서 분리하고 현지화 서비스로 라우팅
저장/로드: 저장 데이터 버전 관리, 스크립트 상태 직렬화 가능(프리미티브 테이블, 안정적 ID)
결정론(리플레이나 넷코드용): 비결정적 소스(실시간 시계, 순서가 없는 반복)를 피하고 난수 사용을 시드된 RNG로 제어
구현 세부사항과 패턴은 /blog/scripting-apis 및 /docs/save-load를 참조하세요.
Lua는 임베딩하기 쉽고 대부분의 게임플레이 로직에 충분히 빠르며 데이터 주도 기능에 유연성을 제공하므로 게임 엔진에서 명성을 얻었습니다. 최소한의 오버헤드로 배포할 수 있고 C/C++과 깔끔하게 통합되며 코루틴으로 게임플로우를 구조화할 수 있습니다. 무거운 런타임이나 복잡한 툴체인에 엔진을 얽매지 않아도 됩니다.
다음으로 빠른 평가를 해보세요:
대부분에 대해 "예"라면 Lua는 강력한 후보입니다.
wait(seconds), wait_event(name))하고 메인 루프와 통합하세요.실용적 시작점은 /blog/best-practices-embedding-lua의 최소 임베딩 체크리스트를 참조하세요.
임베딩은 애플리케이션이 Lua 런타임을 포함하고 그것을 제어한다는 뜻입니다.
독립 실행형 스크립팅은 외부 인터프리터나 도구(예: 터미널에서 스크립트 실행)에서 스크립트를 돌리는 방식이며, 애플리케이션은 그 결과를 소비합니다.
임베디드 스크립팅은 관계가 반대입니다: 게임이 호스트가 되고 스크립트는 게임 프로세스 안에서 실행되며, 타이밍·메모리 규칙과 노출된 API는 게임이 소유합니다.
Lua가 임베딩 용도로 자주 선택되는 이유는 다음과 같습니다:
일반적으로 다음과 같은 면에서 이점이 큽니다:
스크립트는 오케스트레이션에 적합하고 무거운 커널은 네이티브로 두세요.
좋은 Lua 사용 예:
다음은 Lua에서 피해야 할 핫 루프입니다:
실제 프로젝트에서 프레임 시간 스파이크를 피하려면 다음 습관이 도움이 됩니다:
대부분의 통합은 스택 기반입니다:
Lua → 엔진 호출을 위해서는 큐레이션된 C/C++ 함수를 노출합니다(종종 engine.audio.play(...) 같은 모듈 테이블로 그룹화).
코루틴은 스크립트가 프레임 전체를 블록하지 않고 일시중단/재개할 수 있게 해 주므로 퀘스트나 컷신 같은 순차적 작업에 적합합니다.
일반 패턴:
wait_seconds(t) / wait_event(name)를 호출하고 yield이로써 퀘스트/컷신 로직이 읽기 쉽게 유지되고 상태 플래그로 난잡해지지 않습니다.
최소 환경에서 시작해 기능을 의도적으로 추가하세요:
io와 os를 비활성화해 파일·프로세스 접근 차단Lua를 장기 유지보수 가능하게 하려면 몇 가지 규율이 필요합니다:
API_VERSION 상수, 단계적 폐기, 호환성 shim이런 관행이 있으면 리팩터링 후에도 스크립트 파괴를 줄일 수 있습니다.
loadfileloadgame 또는 engine 같은 단일 큐레이션 테이블만 제공신뢰도 낮은 콘텐츠는 별도 Lua 상태로 실행하고 API 표면을 줄여 격리하세요.