적과 아이템으로 게임의 규칙 만들기
지난 장에서 캐릭터는 드디어 달리고 점프하기 시작했다. 이제 손끝으로 움직이는 맛은 생겼다. 그런데 아직은 놀이터에 가깝다. 아무리 점프감이 좋아도 피해야 할 것이 없고, 얻어야 할 것이 없고, 도착해야 할 이유가 없으면 플레이어는 금방 묻게 된다. 그래서, 어디로 가면 되죠?
이번 장의 목표는 단순하다. 플레이어 바깥에 있는 요소를 추가해 위험과 보상, 그리고 목표가 있는 게임 구조를 만드는 것이다. 적은 긴장을 만들고, 아이템은 선택의 이유를 만든다. 그리고 점수와 출구는 그 둘을 하나의 규칙으로 묶는다. 이 장이 끝나면 당신의 게임은 더 이상 "움직이는 테스트 씬"이 아니라, 짧더라도 분명한 목적을 가진 첫 액션 게임이 된다.
움직임만으로는 게임이 되지 않는 이유
게임은 보통 두 가지 질문으로 굴러간다. 하나는 "무엇을 피해야 하는가", 다른 하나는 "무엇을 얻어야 하는가"다. 이 두 질문이 생기는 순간 플레이어의 행동에는 의미가 붙는다.
예를 들어 보자. 발판 위를 달리기만 하는 장면은 몇 초 동안은 재미있을 수 있다. 하지만 곧 익숙해진다. 여기에 순찰하는 슬라임 하나만 놓아도 상황은 달라진다. 이제 플레이어는 타이밍을 보기 시작한다. 거기에 코인과 열쇠를 두면 더 달라진다. 이제는 단순히 살아남는 것만이 아니라, 무엇을 먼저 먹고 어디로 갈지를 고민하게 된다.
좋은 입문용 규칙은 복잡하지 않다. 오히려 한 문장으로 설명되어야 한다.
코인 10개를 모으면 출구가 열린다.
열쇠를 얻어야 문을 통과할 수 있다.
적을 피하면서 제한 시간 안에 목표 점수를 채운다.
이 정도만 되어도 플레이어는 스스로 행동의 이유를 이해한다. 게임이 갑자기 "할 일 있는 세계"처럼 느껴지는 이유가 바로 여기에 있다.
Tag와 Layer를 먼저 나누면 충돌이 덜 꼬인다
초보자가 적과 아이템을 붙일 때 가장 자주 헷갈리는 부분이 바로 Tag와 Layer다. 이름도 비슷하고, 둘 다 분류에 쓰이기 때문이다. 하지만 역할은 꽤 다르다. Tag는 "이 오브젝트가 무엇인가"를 나타내는 이름표이고, Layer는 "이 오브젝트가 누구와 상호작용할 것인가"를 정하는 그룹에 가깝다.1
쉽게 말하면 이렇다.
Player, Enemy, Item 같은 말은 Tag에 잘 어울린다. 반면 Ground, Pickup, Enemy, Hazard 같은 말은 Layer에 잘 어울린다. Tag는 스크립트에서 대상을 확인할 때 읽기 쉽고, Layer는 Physics2D의 충돌 매트릭스와 레이캐스트, 감지 범위를 관리할 때 훨씬 강력하다.1
이번 장의 2D 플랫폼 게임에서는 아래처럼 시작하면 충분하다.
| 구분 | 추천 이름 | 용도 |
|---|---|---|
| Tag | Player | 플레이어 판별 |
| Tag | Enemy | 적 판별 |
| Tag | Item | 아이템 판별 |
| Tag | Exit | 출구 판별 |
| Layer | Ground | 바닥과 발판 충돌 |
| Layer | Enemy | 적의 몸체 충돌 |
| Layer | Pickup | 코인, 열쇠, 회복 아이템 |
| Layer | Hazard | 가시, 함정, 데미지 영역 |
| Layer | Player | 플레이어 관련 감지와 충돌 |
중요한 것은 "Tag와 Layer를 둘 다 달았으니 다 알아서 되겠지"라고 생각하지 않는 것이다. 먼저 Layer로 큰 흐름을 정리하고, 그다음 충돌 콜백 안에서는 Tag 비교를 최소한으로만 쓰는 편이 훨씬 안정적이다.
Physics2D 충돌 매트릭스에서 절반은 끝난다
적과 아이템이 많은데도 게임이 안정적인 프로젝트는 대개 스크립트가 특별해서가 아니라, 충돌 규칙을 먼저 설계했기 때문이다. Unity의 Collider2D는 충돌과 트리거 메시지를 제공하고, 레이어 설정으로 어떤 대상끼리 접촉할지 미리 줄여 줄 수 있다.2
이번 장에서는 먼저 Edit > Project Settings > Physics 2D에서 Layer Collision Matrix를 정리하자. 입문 단계에서는 다음 규칙이면 충분하다.
| 조합 | 충돌 여부 | 이유 |
|---|---|---|
| Player ↔ Ground | 예 | 서고, 걷고, 착지해야 함 |
| Player ↔ Enemy | 예 | 부딪히면 위험해야 함 |
| Player ↔ Pickup | 예(트리거) | 지나가며 획득해야 함 |
| Enemy ↔ Ground | 예 | 적도 바닥 위를 돌아다녀야 함 |
| Enemy ↔ Pickup | 아니오 | 적이 코인을 밀거나 먹으면 곤란함 |
| Pickup ↔ Ground | 아니오 또는 최소화 | 바닥과 불필요한 충돌 계산 방지 |
| Enemy ↔ Enemy | 보통 아니오 | 서로 밀어내며 꼬이는 상황 방지 |
여기서 핵심은 이것이다. 아이템은 보통 Is Trigger를 켠다. 적 몸체와 바닥은 실제 충돌이 필요하므로 일반 충돌로 둔다. Trigger는 겹침을 감지하지만 물리적으로 밀어내지 않고, Collision은 실제로 부딪히며 반응한다.2
이렇게 매트릭스를 먼저 정해 두면, 코드에서는 복잡한 예외 처리를 덜 하게 된다. 예를 들어 코인 스크립트는 "플레이어가 들어왔는지만" 보면 된다.
void OnTriggerEnter2D(Collider2D other)
{
if (!other.CompareTag("Player")) return;
Collect();
}반대로 적의 몸체는 "플레이어와 부딪혔는지만" 보면 된다.
void OnCollisionEnter2D(Collision2D collision)
{
if (!collision.gameObject.CompareTag("Player")) return;
DealDamage();
}짧아 보여도 이 차이는 아주 크다. 매트릭스에서 이미 걸러졌기 때문에, 콜백 안의 비교는 최소한만 남는다. 그 덕분에 버그가 줄고 읽기도 쉬워진다.
적 AI는 똑똑한 것보다 읽히는 것이 먼저다
초보자가 적을 만들 때 가장 많이 하는 실수는 너무 빨리 "AI다운 AI"를 만들려는 것이다. 하지만 첫 게임에 필요한 적은 복잡한 전략가가 아니다. 플레이어가 이해할 수 있는 패턴만 있어도 충분하다.
처음 적은 세 단계로 생각하자.
감지 → 이동/순찰 → 충돌 시 결과
이 세 단계만 분명하면 난이도는 금방 생긴다. 멀리 있을 때는 두 지점을 왔다 갔다 순찰하고, 플레이어가 가까이 오면 따라오고, 닿으면 데미지를 준다. 이 구조는 Unity Learn의 입문형 적 구현처럼 큰 작업을 작은 단계로 쪼개 테스트하기에도 좋다.3
좋은 소식은, 이 정도만 해도 플레이어는 이미 적을 "위협"으로 인식한다는 점이다. 특히 플랫폼 게임에서는 적이 얼마나 똑똑한지보다 언제 위험해지는지가 읽히는가가 더 중요하다.
실습: 두 지점을 왕복하다가 플레이어를 감지하는 슬라임 만들기
이번 실습에서는 땅 위를 왔다 갔다 하는 간단한 슬라임을 만든다. 경로 탐색, 점프 추격, 복잡한 상태 머신은 넣지 않는다. 지금은 패턴이 잘 읽히는 적 하나면 충분하다.
1단계: 적 오브젝트 세팅
Enemy_Slime 오브젝트를 만들고 다음 컴포넌트를 붙인다.
Sprite RendererRigidbody2DBox Collider 2D또는Capsule Collider 2D아래의
EnemyPatrol2D스크립트
그리고 Layer는 Enemy, Tag는 Enemy로 지정한다. Rigidbody2D는 회전하지 않도록 Freeze Rotation Z를 켜 두자. 그래야 플레이어와 부딪혔을 때 적이 뒤집히며 굴러가는 사고를 막을 수 있다.
이제 Enemy_Slime의 자식으로 빈 오브젝트 두 개를 만들고 PointA, PointB라고 이름 붙인다. 이 두 점이 순찰의 끝점이 된다. 말하자면 슬라임에게 "여기부터 여기까지만 왔다 갔다 해"라고 길을 그려 주는 셈이다.
2단계: 순찰과 감지를 한 스크립트로 묶기
아래 스크립트는 세 가지 역할을 한다. 평소에는 A와 B 사이를 왕복하고, 플레이어가 감지 반경 안으로 들어오면 잠시 추격하고, 부딪히면 플레이어 체력 스크립트에 데미지를 요청한다.
using UnityEngine;
public class EnemyPatrol2D : MonoBehaviour
{
[SerializeField] Transform pointA;
[SerializeField] Transform pointB;
[SerializeField] float speed = 2f;
[SerializeField] float detectRadius = 2.5f;
[SerializeField] LayerMask playerLayer;
Rigidbody2D rb;
Transform target;
void Awake() => rb = GetComponent<Rigidbody2D>();
void Start() => target = pointB;
void FixedUpdate()
{
Collider2D hit = Physics2D.OverlapCircle(transform.position, detectRadius, playerLayer);
Vector2 destination = hit ? hit.transform.position : target.position;
rb.MovePosition(Vector2.MoveTowards(rb.position, destination, speed * Time.fixedDeltaTime));
if (!hit && Vector2.Distance(rb.position, target.position) < 0.1f)
target = target == pointA ? pointB : pointA;
}
void OnCollisionEnter2D(Collision2D collision)
{
if (!collision.gameObject.CompareTag("Player")) return;
collision.gameObject.GetComponent<PlayerHealth>()?.TakeDamage(1);
}
void OnDrawGizmosSelected()
{
Gizmos.color = Color.red;
Gizmos.DrawWireSphere(transform.position, detectRadius);
}
}이 코드는 의외로 많은 것을 가르쳐 준다. Physics2D.OverlapCircle은 감지 범위 안에 플레이어 레이어가 있는지 본다. 플레이어가 없으면 순찰 점으로 가고, 있으면 그쪽으로 방향을 바꾼다. 그리고 OnDrawGizmosSelected는 감지 반경을 씬에서 원으로 보여 준다. 숫자만 보고 detectRadius를 조절하는 것보다 훨씬 빠르게 튜닝할 수 있다.
3단계: 먼저 테스트해야 할 것
스크립트를 붙였다고 바로 끝나지 않는다. 아래 순서대로 꼭 확인하자.
슬라임이 PointA와 PointB를 제대로 왕복하는가
플레이어가 가까워졌을 때만 추격하는가
감지 반경이 너무 크거나 작지 않은가
충돌 시 플레이어가 밀리거나 이상하게 튕기지 않는가
여기서 중요한 태도는 "한 번에 다 맞추려 하지 말기"다. Unity Learn의 적 구현 튜토리얼도 큰 작업을 작은 단계로 쪼개고, 단계마다 화면에서 확인하는 흐름을 강조한다.3
처음에는 순찰만 넣고, 그다음 감지를 넣고, 마지막으로 데미지를 넣자. 이 순서가 디버깅 시간을 크게 줄여 준다.
감지 범위는 숫자가 아니라 눈으로 맞추는 편이 빠르다
적이 지나치게 멀리서 반응하면 억울하게 느껴지고, 너무 가까워야 반응하면 존재감이 약해진다. 그래서 감지 범위는 수학보다 체감의 문제다.
이럴 때 Gizmos가 정말 유용하다. 슬라임을 선택했을 때 빨간 원이 보이면, 디자이너처럼 반경을 조절할 수 있다. "2.5가 적당할까?"를 머리로 계산하는 대신, 씬 위에서 "이 정도면 플레이어가 봤을 때 납득 가능하네"라고 판단할 수 있다.
특히 초보자에게 이 방식이 좋은 이유는, 디버깅의 속도가 빨라지기 때문이다. 적이 왜 갑자기 달려드는지 모를 때 숫자만 보면 막막하다. 그런데 씬에 감지 원이 보이면 바로 이해된다. 아, 내가 생각한 것보다 훨씬 넓었구나. 바로 이런 깨달음이 튜닝 시간을 줄인다.
아이템은 종류마다 스크립트를 만들지 말고 데이터로 늘리자
이제 보상을 만들 차례다. 많은 초보자가 여기서 CoinPickup.cs, KeyPickup.cs, HeartPickup.cs를 각각 만든다. 처음에는 빨라 보이지만, 아이템이 세 개를 넘어가는 순간 슬슬 지친다. 효과는 조금씩 비슷한데 파일만 계속 늘어나기 때문이다.
더 좋은 방법은 수집 행동과 아이템 효과를 분리하는 것이다. 아이템을 먹는 순간 일어나는 공통 행동은 거의 비슷하다.
플레이어가 닿으면 획득한다.
효과음을 재생한다.
점수나 체력, 열쇠 수를 반영한다.
아이템을 비활성화하거나 파괴한다.
달라지는 것은 "무슨 효과를 주는가"뿐이다. 그러니 그 차이를 데이터로 빼면 된다.
1단계: 아이템 데이터를 만든다
먼저 어떤 아이템인지 설명하는 데이터를 만든다.
using UnityEngine;
public enum ItemType { Coin, Key, Heal }
[CreateAssetMenu(menuName = "Game/Item Definition")]
public class ItemDefinition : ScriptableObject
{
public ItemType type;
public int scoreValue;
public int healAmount;
public AudioClip pickupSound;
}이 스크립트의 역할은 "아이템의 설명서"다. 코인은 scoreValue가 있고, 회복 아이템은 healAmount가 있고, 열쇠는 type으로 구분하면 된다.
2단계: 획득 처리 스크립트는 하나만 둔다
using UnityEngine;
public class ItemPickup : MonoBehaviour
{
[SerializeField] ItemDefinition data;
void OnTriggerEnter2D(Collider2D other)
{
if (!other.CompareTag("Player")) return;
var receiver = other.GetComponent<PlayerItemReceiver>();
if (receiver == null) return;
receiver.Apply(data);
gameObject.SetActive(false);
}
}3단계: 플레이어가 효과를 받는다
using UnityEngine;
public class PlayerItemReceiver : MonoBehaviour
{
public int score;
public int keys;
public int hp = 3;
public void Apply(ItemDefinition data)
{
score += data.scoreValue;
hp += data.healAmount;
if (data.type == ItemType.Key)
keys += 1;
}
}이 구조의 장점은 정말 크다. 코인, 열쇠, 회복 아이템이 모두 같은 패턴으로 움직인다. 나중에 적을 처치했을 때 랜덤으로 아이템을 떨어뜨리고 싶다면, 적 사망 시 ItemPickup 프리팹만 생성하면 된다. 아이템 종류가 늘어나도 핵심 코드는 거의 안 흔들린다.
초보자 입장에서는 이게 다소 돌아가는 길처럼 느껴질 수 있다. 하지만 사실은 반대다. 초반에 살짝 구조를 잡아 두면, 중반부터는 훨씬 덜 피곤하다.
점수는 숫자가 아니라 목표 문장과 연결될 때 살아난다
점수는 그냥 화면 구석에서 올라가는 숫자로 끝나면 금방 배경음처럼 흐릿해진다. 반대로 점수가 어떤 문과 연결되고, 어떤 출구와 연결되면 즉시 플레이의 목적이 된다.
이번 장에서는 가장 쉬운 규칙 하나를 추천한다.
코인 10개를 모으면 출구가 열린다.
이 규칙이 좋은 이유는 아주 명확하다. 플레이어는 위험을 감수하고 코인을 먹으러 가야 하고, 그 과정에서 적을 피해야 한다. 보상과 위험이 하나의 문장 안에 묶인다.
구현도 어렵지 않다. PlayerItemReceiver.score가 10 이상이면 출구의 문을 열고, 그렇지 않으면 닫아 두면 된다. 이때 출구는 처음부터 지나갈 수 있는 배경이 아니라, "조건이 충족되면 활성화되는 목표"로 다뤄야 한다. 그래야 플레이어가 스테이지를 어떻게 읽어야 하는지 즉시 이해한다.
열쇠 규칙도 비슷하다. keys >= 1이면 문을 열고, 지나가면 열쇠를 소비하게 만들 수 있다. 혹은 회복 아이템을 적 근처에 두어 "위험을 감수하면 생존이 쉬워진다"는 선택을 만들 수도 있다.
좋은 규칙은 대개 숫자보다 관계가 선명하다.
코인은 출구를 연다.
열쇠는 문을 연다.
회복 아이템은 위험 지역 진입을 돕는다.
적은 이 모든 선택에 비용을 붙인다.
이 네 줄만 있어도 게임은 꽤 그럴듯해진다.
실전 배치: 코인을 어디에 놓아야 재미있을까
아이템을 아무 데나 뿌리면 수집은 되지만 재미는 약하다. 배치는 늘 질문이 따라야 한다. "왜 여기 있어야 하지?"
좋은 배치의 기본은 위험과 보상의 균형이다. 예를 들어 쉬운 코인 다섯 개는 초반에 놓아 플레이어에게 성공 경험을 주고, 나머지 다섯 개는 적의 순찰 반경 근처나 점프가 필요한 발판 위에 두면 된다. 그러면 플레이어는 자연스럽게 난이도 곡선을 느낀다.
열쇠는 보통 더 명확한 역할이 필요하다. 눈에 잘 띄는 곳에 두되, 그냥 걸어가서 먹기보다는 작은 도전 하나를 통과해야 좋다. 예를 들어 슬라임이 순찰하는 좁은 발판의 끝, 혹은 떨어지면 다시 올라와야 하는 보조 루트의 끝에 두면 "아, 저걸 먹으러 가는구나"가 곧바로 전달된다.
한마디로 정리하면 이렇다. 아이템은 장식이 아니라 플레이어의 동선을 설계하는 도구다.
AI 활용: 임시 에셋은 빠르게, 테스트는 플레이 감각부터
이 장에서는 시각 자산에 오래 매달리지 않는 편이 좋다. 아직은 적이 얼마나 위협적으로 읽히는지, 코인이 얼마나 잘 보이는지, 아이템 충돌 범위가 어색하지 않은지를 먼저 확인해야 한다.
그래서 테스트 단계에서는 Unity AI Generators 같은 도구로 임시 스프라이트를 빠르게 만든 뒤, 실제 플레이 감각을 먼저 검증하는 접근이 효율적이다. 완성도 높은 일러스트보다 지금 중요한 것은 세 가지다.
플레이어가 적을 한눈에 구분할 수 있는가
아이템이 배경에 묻히지 않는가
스프라이트 크기와 충돌 범위가 체감상 자연스러운가
예를 들어 슬라임 테스트용 프롬프트는 이렇게 시작할 수 있다.
AI에게 묻자
"2D platformer placeholder sprite, cute but readable slime enemy, high contrast silhouette, 64x64, transparent background, side view, simple colors, no text."
코인과 열쇠도 마찬가지다.
AI에게 묻자
"2D platformer pickup icons, coin, key, heart, bright colors, strong silhouette, easy to read on dark cave background, transparent background."
여기서 중요한 태도는 "마음에 드는 그림이 나올 때까지 붙잡기"가 아니다. 오히려 "판정과 가독성을 확인할 만큼만 빠르게 만든다"에 가깝다. 나중에 최종 에셋으로 바꾸는 일은 생각보다 쉽다. 하지만 초기에 재미없는 규칙을 예쁜 그림으로 덮는 일은 쉽지 않다.
AI에게 규칙 설계를 같이 맡기면 튜닝이 빨라진다
AI는 그림만 만드는 도구가 아니다. 이 장에서는 오히려 규칙을 말로 설명하고 피드백을 받는 용도가 더 강력하다.
예를 들어 지금 스테이지가 너무 쉽다고 느껴진다면, AI에게 숫자만 던지지 말고 체감까지 함께 말하자.
AI에게 묻자
"Unity 2D 플랫폼 게임을 만들고 있어. 플레이어 이동 속도는 6, 점프력은 12, 슬라임은 감지 반경 2.5에서 추격해. 코인 10개를 모아야 출구가 열리는 구조야. 지금은 너무 쉽게 느껴져. 초보자용 첫 스테이지답게 좌절감은 낮게 유지하되 긴장은 조금 더 주고 싶어. 적 배치, 코인 위치, 열쇠 동선 관점에서 3가지 수정안을 제안해줘."
좋은 프롬프트의 핵심은 세 가지다. 현재 수치, 현재 체감, 원하는 방향. 이 세 개가 들어가면 AI는 단순한 잡담이 아니라 꽤 유용한 설계 조언을 내놓는다.
자주 생기는 문제를 미리 알고 가자
적과 아이템을 붙이는 순간부터는 "왜 안 되지?"의 종류가 조금 달라진다. 다행히 자주 나오는 문제는 거의 정해져 있다.
아이템이 안 먹어진다면 가장 먼저 Is Trigger가 켜져 있는지 보자. 그리고 Player와 Pickup 레이어가 Physics2D 매트릭스에서 실제로 접촉 가능하게 되어 있는지도 확인하자. 코드가 맞아도 레이어가 막혀 있으면 콜백은 오지 않는다.
적이 플레이어를 너무 멀리서 감지한다면 detectRadius만 보지 말고, 플레이어가 정말 playerLayer에 들어가 있는지부터 점검하자. 반경은 맞는데 레이어가 틀려서 감지가 안 되는 경우도 의외로 많다.
충돌 시 플레이어 체력이 순식간에 0이 된다면 OnCollisionEnter2D 대신 OnCollisionStay2D를 쓰고 있지 않은지 보자. Stay는 닿아 있는 동안 계속 호출되므로, 무적 시간이나 쿨다운이 없으면 데미지가 너무 빠르게 누적된다.
아이템은 사라졌는데 점수가 오르지 않는다면 ItemDefinition이 프리팹에 연결되어 있는지, 그리고 플레이어에 PlayerItemReceiver가 붙어 있는지 확인하자. 이런 문제는 대부분 "스크립트가 틀렸다"보다 "참조가 비어 있다"에 가깝다.
이 장의 핵심은 규칙이 플레이어 바깥에서 생긴다는 점이다
지금까지 우리는 플레이어를 중심으로 게임을 만들어 왔다. 움직이게 하고, 점프하게 하고, 애니메이션을 붙였다. 그런데 게임의 진짜 재미는 그 바깥에서 자란다. 적이 나타나고, 아이템이 놓이고, 출구가 잠기면서 비로소 플레이어의 행동에 이유가 생긴다.
이 장에서 만든 것은 거창한 시스템이 아니다. 하지만 의미는 아주 크다. 이제 당신의 게임에는 위험, 보상, 조건, 목표가 들어왔다. 이것만으로도 플레이어는 더 이상 멍하니 달리지 않는다. 피하고, 먹고, 모으고, 도착하려고 한다.
바로 그 순간부터 게임은 진짜로 시작된다.
이 장에서 배운 것
Tag는 오브젝트의 의미를, Layer는 물리 충돌과 감지 규칙을 관리한다는 점
Physics2D 충돌 매트릭스를 먼저 설계하면
OnTriggerEnter2D,OnCollisionEnter2D안의 비교를 최소화할 수 있다는 점적 AI는
감지 → 이동/순찰 → 충돌 시 결과의 세 단계만으로도 충분히 게임의 긴장을 만들 수 있다는 점아이템은 종류마다 스크립트를 새로 만들기보다 공통 수집 처리와 효과 데이터를 분리하면 훨씬 확장하기 쉽다는 점
점수는 숫자 표시보다 승리 조건과 연결될 때 플레이 목적을 분명하게 만든다는 점
테스트 단계에서는 최종 아트보다 판정 크기, 가독성, 위협 인지 속도를 먼저 검증하는 편이 효율적이라는 점
다음 장에서 만들 것
다음 장에서는 지금 만든 규칙을 플레이어가 더 또렷하게 읽을 수 있도록 UI와 게임 흐름을 붙인다. 점수와 생명을 화면에 보여 주고, 시작 화면과 게임오버 화면을 만들고, 씬 전환까지 연결할 것이다. 규칙이 생겼다면, 이제 그 규칙을 플레이어에게 친절하게 보여 줄 차례다.
참고
1Mastering Layers and Tags: Smart Object Classification and Management in Unity
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.