고급 - 타이밍

"타이밍"은 재요청 주기, 타임아웃 및 Alive Notice 설정을 포함하여 구간 제어 세그먼트의 타이밍 동작을 제어하는 고급 구성으로, 시스템 성능 및 사용자 경험을 최적화합니다.

개요

구간 제어 세그먼트의 고급 타이밍 설정은 네 가지 주요 타이밍 측면을 관리합니다:

1. 재요청 주기: 대기실의 방문자가 진입 권한을 확인하는 빈도 제어
2. Alive Notice 재요청 주기: 사용자가 보호된 구간 내에 있는 동안 시스템이 "여전히 활성 상태" 신호를 보내는 빈도 제어
3. Alive Notice 기간 만료: 사용자가 보호된 구간 내에서 유지될 수 있는 최대 기간 설정
4. 타임아웃: 활동 또는 완료 신호가 수신되지 않으면 자동으로 리소스 해제

이러한 설정은 시스템이 상태 확인을 처리하고 다단계 구간 전반에 걸쳐 활성 사용자 상태를 유지하는 시점과 빈도를 구성하여 서버 성능과 사용자 경험 사이의 균형을 맞추는 데 도움이 됩니다.

실제 비유: 공유 코워킹 공간

서비스를 제한된 책상이 있는 코워킹 공간으로 생각해보세요:

• 책상 예약 = 보호된 구간 진입 (nfStartSection)
• 책상에서 작업 (타이핑, 마우스 이동) = 구간 내 페이지에서의 활성 사용자 상호 작용
• 책상 떠나기 = 구간 완료 (nfStopSection)

타이밍 설정은 진입 대기열 관리, 시스템이 활성적으로 작업 중인지 감지하는 방법, 최대 책상 사용 시간, 그리고 사라지면 책상이 다른 사람에게 사용 가능해지는 시점을 제어합니다.

타이밍 옵션이 함께 작동하는 방식:

주요 상호 작용

• 재요청 주기: 사용자가 대기실에 있는 동안에만 활성
• Alive Notice 주기: 사용자가 활성 상태인 동안 주기적으로 타임아웃 카운트다운을 초기화
• Alive Notice 기간 만료: Alive Notice 전송의 최대 기간 설정 (기본값 300초)
• 타임아웃: 타임아웃 기간 동안 Alive Notice가 도착하지 않을 때만 트리거 (기본값 20초)

관계: Alive Notice 주기 < 타임아웃 < Alive Notice 기간 만료

재요청 주기

기능: 대기 중인 방문자가 진입 가능성을 확인하기 위해 보내는 요청 간의 동적 타이밍을 제어합니다. 시스템은 각 방문자의 대기 순번을 기반으로 이 주기를 지능적으로 조정합니다.

코워킹 공간 예약 대기열을 생각해보세요: 줄 앞쪽에 있는 사람들은 프론트 데스크를 자주 확인합니다("지금 책상이 사용 가능한가요?"), 반면 뒤쪽에 있는 사람들은 덜 자주 확인합니다. NetFUNNEL은 동일한 논리를 적용합니다 - 진입에 가까운 방문자는 1-2초마다 확인하고, 뒤쪽에 있는 방문자는 8-10초마다 확인합니다. 이것은 예약 시스템을 압도하지 않으면서 앞쪽의 사람들이 책상이 사용 가능해질 때 놓치지 않도록 보장합니다.

작동 방식:

1. 주기적 상태 확인: 방문자의 대기실 로직이 진입 권한을 확인하기 위해 NetFUNNEL 서버에 반복적으로 연락
2. 서버 응답: 각 요청은 PASS (진입 진행) 또는 WAIT (계속 대기)를 받음
3. TTL (Time To Live): WAIT 응답에는 다음 확인 전에 정확히 얼마나 기다려야 하는지 클라이언트에 알려주는 TTL 값이 포함됨
4. 동적 계산: TTL은 각 방문자의 대기 순번을 기반으로 계산됨

범위를 구성하는 이유, 고정 값이 아닌:

다른 방문자는 대기열을 통해 이동하면서 변경되는 다른 확인 빈도가 필요합니다. 단일 고정 주기가 아닌 범위 (예: 1-10초)를 구성합니다.

• 앞쪽에 가까운 방문자: 더 짧은 TTL 값 수신 → 더 자주 확인 → 리소스가 사용 가능해지면 더 빠른 진입
• 뒤쪽의 방문자: 더 긴 TTL 값 수신 → 덜 자주 확인 → 불필요한 서버 요청 감소
• 진행하면서: TTL 값이 자동으로 줄어들어 대기 중 전체에 걸쳐 우선순위에 적합한 확인 빈도 보장

이것은 서버 부하 (불필요한 요청 감소)와 사용자 경험 (사용 가능할 때 즉시 진입) 사이의 균형을 맞춥니다.

시각적 예시 (범위: 1-10초):

대기 순번     TTL 값    확인 빈도
─────────────────────────────────────────────────
    앞쪽     →    1-2초    →  매우 자주
   중-상     →    3-5초    →  보통
   중-하     →    6-8초    →  덜 자주
    뒤쪽     →    9-10초   →  가장 덜 자주

    방문자 1  (대기열 앞쪽)
    ↓ 진입에 가까워질수록 더 자주 확인
    ↓
    방문자 100 (대기열 중간) 
    ↓ 진행하면서 TTL이 점진적으로 감소
    ↓
    방문자 500 (대기열 뒤쪽)

이 그라데이션은 앞쪽의 방문자가 리소스가 사용 가능해지면 빠른 진입을 받도록 보장하는 동시에, 뒤쪽의 방문자가 불필요한 요청으로 서버를 압도하지 않도록 합니다.

기본값: 최소 1초, 최대 10초

구성 가능한 범위: 최소값과 최대값 모두 1-60초

구성 방법:

1. 세그먼트의 고급 설정으로 이동
2. 최소 값 설정 (1초 권장)
3. 최대 값 설정 (10초 권장)
4. 시스템이 대기 순번을 기반으로 이 범위 내에서 각 방문자의 주기를 자동으로 조정

권장 사항: 기본값(1-10초)을 사용하세요. 이것들은 NetFUNNEL 서버 사양에 최적화되어 있습니다. 변경하는 것은 일반적으로 필요하지 않습니다 - 기본 균형은 이미 시스템 용량을 고려합니다. 성능 모니터링에서 특정 요구 사항이 있는 경우에만 조정하세요.

Alive Notice 재요청 주기

기능: 사용자가 보호된 구간 내에서 활성 상태인 동안 NetFUNNEL 에이전트가 서버에 Alive Notice(opcode 5003) 신호를 보내는 빈도를 제어합니다. 이 신호는 서버에 "여전히 여기에 있고 리소스를 사용 중입니다"라고 알려 타임아웃으로 인한 자동 키 반환을 방지합니다.

코워킹 공간에서 책상을 예약했다고 상상해보세요. 책상에 앉으면 시스템이 주기적으로 확인합니다: "여전히 이 책상에 있나요?" (5초마다). 이것은 타이핑, 읽기, 생각하기 또는 그냥 앉아 있기 등 활성적으로 무엇을 하고 있는지와 관계없이 자동으로 발생합니다 - 예약된 영역(보호된 구간)에 있는 한 확인이 계속됩니다. 이러한 주기적 확인이 도착하는 한 시스템은 당신을 활성 책상 사용자로 간주합니다.

필요한 이유: 구간 제어에서 사용자는 다단계 구간 전체(예: 콘서트 선택, 시간대 선택)에 걸쳐 리소스를 점유합니다. 활동이 감지되지 않으면 키 반환 타임아웃이 자동으로 리소스를 해제하지만, 사용자는 여러 페이지를 탐색하는 동안 활성 상태를 유지해야 합니다.

작동 방식:

1. 자동 주기적 전송: 사용자가 보호된 구간에 진입하면 NetFUNNEL 에이전트가 구성된 주기로 Alive Notice 요청 전송을 자동으로 시작
2. 서버 응답: 각 Alive Notice가 서버의 키 반환 타임아웃 타이머를 초기화
3. 연속 루프: 사용자가 구간 내에 남아있는 동안(Alive Notice 기간 만료까지) 에이전트가 이러한 신호 전송을 계속
4. 리소스 보호: Alive Notice가 계속 도착하는 한 서버는 사용자의 리소스 점유를 유지하고 활성 사용자로 유지

기본값: 5초

구성 가능한 범위: 1-60초

이 주기가 중요한 이유:

• 너무 짧음 (예: 1-2초): 많은 사용자가 활성 상태일 때 과도한 서버 요청, 잠재적으로 서버 압도
• 너무 김 (예: 10초 이상): 주기가 키 반환 타임아웃 임계값을 초과하면 서버가 사용자가 떠났다고 생각하고 다음 Alive Notice가 도착하기 전에 자동으로 리소스를 해제할 수 있음
• 중요한 제약: Alive Notice 재요청 주기는 타임아웃 최소값보다 짧아야 조기 리소스 해제를 방지

권장 사항: 기본값(5초)을 사용하세요. 이것은 타임아웃 기반 해제를 방지하기에 충분히 자주 확인하면서 서버 부하를 관리 가능하게 유지합니다. 성능 모니터링을 기반으로 특정 요구 사항이 있는 경우에만 조정하세요.

시각적 예시:

타임아웃 초기화 메커니즘

각 Alive Notice가 서버의 타임아웃 카운트다운을 0으로 초기화합니다. 이것은 사용자가 활성적으로 페이지를 탐색하는 동안(5초마다) 타임아웃이 트리거되지 않음을 의미합니다. 사용자가 Alive Notice 전송을 중지할 때만(예: 브라우저 닫기) 타임아웃 카운트다운이 완료됩니다.

Alive Notice 기간 만료

기능: 시스템이 Alive Notice 전송을 중지하기 전에 사용자가 보호된 구간 내에서 활성 상태로 유지될 수 있는 최대 총 기간을 설정합니다. 이것은 자동 해제되기 전에 사용자가 리소스를 점유할 수 있는 상한선입니다.

코워킹 공간의 책상 예약에는 최대 기간이 있습니다(예: 이 비유에서는 5분, 실제 공간은 시간 단위일 수 있음). 이 시간 제한 내에서 작업, 휴식, 회의를 할 수 있습니다. 하지만 완료 신호 없이 5분 후에도 여전히 책상에 있다면 시스템은 뭔가 잘못되었을 수 있음을 압니다 - 체크아웃을 잊었거나 세션이 멈췄을 수 있습니다. 5분 후, 시스템은 활동 신호를 기대하지 않습니다. 20초 이내에 체크아웃하지 않으면 자동으로 책상을 해제하여 다음 사람이 예약할 수 있도록 합니다.

필요한 이유: Alive Notice 기간 만료 제한 없이는 멈추거나 의도적으로 구간에 무기한 머무르는 사용자가 리소스를 영원히 점유하여 다른 대기 중인 사용자의 진입을 방지할 수 있습니다. Alive Notice 기간 만료는 사용자가 완료 지점에 도달하지 않더라도 리소스 슬롯이 결국 해제되도록 보장합니다.

작동 방식:

1. 전역 타이머: 만료 타이머는 사용자가 처음 보호된 구간에 진입할 때 시작
2. 연속 추적: 이 타이머는 구간 내 모든 페이지에 걸쳐 지속됨 (페이지 간 이동 시 초기화되지 않음)
3. Alive Notice 전송 제한: 만료 타이머에 시간이 남아있는 한 에이전트가 Alive Notice 전송을 계속
4. 자동 중지: 만료 기간에 도달하면 에이전트가 Alive Notice 전송을 중지
5. 리소스 해제: Alive Notice가 중지되면 표준 타임아웃 메커니즘이 구성된 타임아웃 기간 후에 리소스를 해제

예를 들어, Alive Notice 기간 만료가 300초(5분)로 설정되고 타임아웃이 20초인 경우:

• 사용자가 구간 진입 → 만료 타이머 시작 (300초 카운트다운)
• 에이전트가 최대 300초 동안 5초마다 Alive Notice 전송
• 300초에 에이전트가 Alive Notice 전송 중지
• 20초 후(총 320초), 타임아웃이 리소스를 해제

시각적 예시:

Alive Notice 기간 만료 vs 타임아웃

• Alive Notice 기간 만료: 에이전트가 Alive Notice를 전송하는 최대 시간 (예: 300초). 도달하면 에이전트가 모든 Alive Notice 전송을 중지합니다.
• 타임아웃: 마지막 활동 후 서버가 자동 해제 전에 대기하는 시간 (예: 20초). 이것은 마지막 Alive Notice가 수신된 후 카운트다운을 시작합니다.

위 예시에서: 300초(Alive Notice 기간 만료) + 20초(타임아웃) = 해제 전 총 320초 리소스 점유.

기본값: 300초(5분)

구성 가능한 범위: 60-3600초

이 기간이 중요한 이유:

올바르게 설정:

• 목표: 전체 구간을 통한 평균 사용자 여정 시간 + 안전 버퍼 (일반적으로 20-30초)
• 예시 계산: 평균 체크아웃이 120초 소요 → Alive Notice 기간 만료를 150-180초로 설정
• 너무 짧음: 정상 사용자가 프로세스 중간에 차단되어 조기에 위치를 잃고 불필요하게 다른 사람을 차단할 수 있음
• 너무 김: 실제로 포기했거나 오류를 만난 사용자가 무기한으로 리소스를 점유하여 병목 현상 생성

가이드라인:

• 실제 평균 구간 여정 시간 측정
• 느린 사용자를 위해 20-30초를 안전 버퍼로 추가
• 체크아웃/등록의 경우: 일반적으로 2-5분(120-300초)
• 더 긴 프로세스의 경우: 실제 사용자 행동을 기반으로 조정
• 중요: Alive Notice 기간 만료는 항상 가장 긴 예상 합법적 사용 사례보다 길어야 함

권장 사항: 실제 사용자 여정 시간을 모니터링하고 Alive Notice 기간 만료를 평균 시간 + 30초로 설정하세요. 보수적으로 시작하고 메트릭을 기반으로 조정하세요.

타임아웃

기능: 방문자가 서비스 세션을 제대로 완료하지 않으면 방문자의 진입 슬롯을 자동으로 해제하여 리소스가 대기 중인 다른 사람에게 계속 사용 가능하도록 보장합니다.

방문자가 서비스에 진입하면 NetFUNNEL은 리소스 사용을 추적합니다. 방문자가 완료한 후(구매 완료, 콘텐츠 보기 또는 서비스 상호 작용) NetFUNNEL은 다음 대기 중인 방문자를 위해 슬롯을 해제하기 위해 완료 알림을 기대합니다.

때로는 이것이 발생하지 않습니다: 방문자가 브라우저를 닫거나, 다른 곳으로 이동하거나, 오류를 만날 수 있습니다. 타임아웃 없이는 슬롯이 무기한으로 점유되어 모든 대기 중인 방문자를 차단합니다.

키 반환 타임아웃("타임아웃"이라고 함)은 마지막 활동(Alive Notice 또는 키 반환 요청) 후 서버가 자동으로 리소스를 해제하기 전에 대기하는 최대 기간입니다. 이것은 포기되었거나 멈춘 사용자에 의해 리소스 슬롯이 무기한으로 보유되는 것을 방지합니다.

이렇게 생각해보세요: 예약된 책상에 있고 시스템이 5초마다 주기적 확인을 받고 있습니다: "여전히 여기 있나요? 네." 그런 다음 갑자기 이러한 확인이 도착하지 않습니다 - 긴급한 전화를 받고 체크아웃 없이 떠났거나, 세션이 충돌했거나, 브라우저를 닫았을 수 있습니다. 시스템이 알아챕니다: "20초 동안 확인을 받지 못했습니다. 떠났을 수 있습니다." 확인이 없는 20초 후, 시스템이 자동으로 책상 예약을 해제하고 다음 대기 중인 사람이 사용할 수 있도록 표시합니다. 이것이 안전 메커니즘입니다: 누군가 제대로 체크아웃(nfStopSection)하지 않고 사라지더라도 책상이 영원히 "예약된" 상태로 유지되어 다른 사람의 작업을 차단하지 않습니다.

작동 방식:

1. 타임아웃 카운트다운: 진입이 허용되면 시작 (0초)
2. Alive Notice가 타임아웃 초기화: 수신된 각 Alive Notice가 타임아웃 카운트다운을 0으로 초기화
3. 완료 감지:
   • 코드 기반 통합 (CBI): 서비스가 nfStopSection()을 호출할 때 완료가 신호됨
4. 정상 흐름: 적절한 완료가 수신되면 슬롯이 정상적으로 해제됨
5. 타임아웃 시나리오: 타임아웃 기간 동안 Alive Notice가 도착하지 않으면(기본값 6-20초), NetFUNNEL이 자동으로 슬롯을 해제

타임아웃이 Alive Notice와 상호 작용하는 방식:

Alive Notice가 도착을 중지할 때 타임아웃 트리거:

기본값: 6-20초 범위 (일반적으로 기본값 20초)

구성 가능한 범위: 최소값과 최대값 모두 6-60초

범위인 이유:

NetFUNNEL은 완료율 - 진입을 위해 발급된 키 대비 반환/수집된 키의 비율 -을 기반으로 타임아웃을 동적으로 조정합니다. 100% 완료율은 모든 키가 제대로 반환되고 있음을 의미하고, 낮은 비율은 키가 반환되지 않고 있음을 나타냅니다(타임아웃 기반 자동 해제 필요).

• 낮은 완료율 (키가 제대로 반환되지 않음) → 타임아웃이 최소값(6초) 쪽으로 이동하여 정지된 리소스를 더 빠르게 해제하는 데 도움
• 높은 완료율 (키가 제대로 반환되고 있음, 100%에 가까움) → 타임아웃이 최대값(20초) 쪽으로 이동하여 방문자가 완료할 충분한 시간 제공

6-20초인 이유:

기본 범위는 서비스 무결성과 리소스 잠금 방지 사이의 균형을 맞춥니다:

• 서비스 작업: API 응답(밀리초), 페이지 로드(일반적으로 1-2초)
• 20초: 방문자가 작업을 완료할 충분한 시간 제공
• 너무 낮음 (예: 1-2초): 서비스가 완료되기 전에 조기 해제를 일으킬 수 있음

중요한 관계: Alive Notice 재요청 주기 < 타임아웃

Alive Notice 재요청 주기는 타임아웃 최소값보다 짧아야 조기 리소스 해제를 방지합니다.

예를 들어, 타임아웃 최소값이 6초이면 Alive Notice 주기는 5초 이하여야 합니다. 그렇지 않으면 다음 Alive Notice가 도착하기 전에 타임아웃이 트리거되어 합법적인 활성 사용자가 리소스를 잃을 수 있습니다.

모범 사례

1단계: Alive Notice 기간 만료에 집중

중요한 설정만 조정하세요.

평균 사용자의 워크플로우를 코워킹 공간의 책상 예약 관리처럼 생각해보세요. 일반적으로 작업을 완료하는 데 얼마나 걸리나요(양식 작성, 옵션 선택, 처리)? 최대 책상 예약 기간을 정확히 설정해야 합니다 - 너무 짧으면 사용자가 작업 중간에 쫓겨나고, 너무 길면 포기된 세션이 대기 중인 다른 사람의 책상을 차단합니다.

다음 세 가지는 기본값을 사용할 수 있습니다:

• 재요청 주기 (1-10초): 대기실 대기열 확인 - NetFUNNEL 서버 성능에 최적화됨
• Alive Notice 재요청 주기 (5초): 활성 상태 확인 빈도 - 서버 부하와 응답성 균형
• 타임아웃 (6-20초 범위): 자동 반환 시간 - 기본값으로 마지막 Alive Notice 후 최대 타임아웃 후 키가 자동으로 반환됨

그러나 Alive Notice 기간 만료는 신중한 고려가 필요합니다.

중요한 이유는 무엇인가요?

과도한 진입을 방지하는 상한선입니다.

진입이 허용된 후 사용자는 서비스 여정 전반에 걸쳐 리소스를 점유하며, 이 시간 동안 다른 사용자는 진입할 수 없습니다. Alive Notice 기간 만료가 지나지 않으면 해당 슬롯은 "점유된" 상태로 유지됩니다.

⚠️ 너무 짧음 → 정상 사용자가 강제로 쫓겨남

예시: Alive Notice 기간 만료가 100초로 설정되었지만 실제 평균 여정 시간이 150초인 경우:

• Alive Notice가 프로세스 중간에 중지되고 서버가 "이 사용자가 떠났다"고 생각
• 활성 사용자가 리소스를 빼앗기고 서버가 다음 사용자가 진입하도록 허용
• → 과도한 진입 발생 → 서버 과부하 → 시스템 실패

⚠️ 너무 김 → 리소스 해제 지연

• 실제로 포기했거나 떠난 사용자가 계속 Alive Notice 신호를 전송
• 리소스가 불필요하게 장기간 점유됨
• → 대기열 병목 → 나쁜 UX

구성 방법

Alive Notice 기간 만료 = 평균 여정 시간 + 안전 버퍼 (20-30초)

구체적인 예시:

• 구간의 평균 여정 시간이 150초인 경우 → Alive Notice 기간 만료를 160-180초로 설정
• 구간의 평균 여정 시간이 120초인 경우 → Alive Notice 기간 만료를 150-180초로 설정

2단계: 타임아웃도 고려

타임아웃은 Alive Notice 신호도 키 반환 신호도 보내지 않는 사용자를 얼마나 기다릴지 정의합니다.

코워킹 공간에서 작업을 마치고 떠나기로 결정한 사람이 있으면 체크아웃 프로세스가 있습니다 - 작업을 저장하고, 애플리케이션을 닫고, 정리하고, 체크아웃 데스크로 걸어갑니다. 시스템은 즉시 떠나는 것을 알지 못합니다. 마찬가지로, 사용자가 서비스에서 "완료"를 클릭하면 타임아웃은 시스템이 전체 체크아웃 프로세스("완료" 클릭 → 네트워크 지연 → 서버 처리 → nfStopSection)를 기다릴 충분한 시간을 보장하지만, 포기된 세션이 책상을 차단할 정도로 길지는 않습니다.

복잡한 이유는 무엇인가요?

사용자가 정상적으로 완료하는 경우에도 서버는 모릅니다.

사용자가 "예약 완료"를 클릭할 때:

1. UI 처리
2. 네트워크 통신
3. 서버 응답
4. nfStopSection() 호출

이 단계 동안 서버는 "서비스가 아직 완료되지 않았습니다"라고 가정해야 합니다.

구성 방법

"완료" 버튼 클릭 → nfStopSection() 호출까지의 시간

API 처리 지연 및 브라우저 렌더링 시간을 고려한 안전 버퍼를 포함하세요.

예시: 평균 3초가 걸리는 경우 → 타임아웃을 5-6초로 설정

⚠️ 너무 짧음? → 적절한 반환 전에 리소스 해제

사용자가 완료 버튼을 클릭했지만 타임아웃이 2초이고 반환이 3초가 걸리는 경우:

• 서버가 반환 요청이 도착하기 전에 리소스를 해제
• → 서버가 리소스 사용을 감소시키고 더 많은 사용자가 진입하도록 허용 → 중복 리소스 점유 → 과도한 진입

⚠️ 너무 김? → 포기된 사용자에 대한 리소스 해제 지연

• 사용자가 실제로 브라우저를 닫았거나 연결이 끊어졌지만 서버는 10초 이상 후에야 알 수 있음
• → 리소스 해제 지연 → 병목

💡 권장 사항: 타임아웃은 최적 성능을 위해 "정상 반환 흐름보다 약간 길어야" 합니다.

3단계: 필요한 경우에만 다른 값을 조정한 다음 테스트

이러한 설정은 일반적으로 기본값을 유지할 수 있지만 필요하면 조정할 수 있습니다:

• 재요청 주기: 대기열이 너무 반응적이면 감소, 서버 부하가 높으면 증가
• Alive Notice 재요청 주기: 일반적으로 기본값 유지. 타임아웃 최소값보다 짧아야 함
• Alive Notice 기간 만료: 조정해야 함 - 먼저 실제 여정 시간 측정
• 타임아웃: 완료 신호가 누락되면 증가, 리소스가 너무 오래 보유되면 감소

중요 사항:

• 조정 후 실제 트래픽으로 테스트하여 예상 동작 확인
• 안전을 위해 모니터링 메트릭을 기반으로 점진적으로 조정

구성 체크리스트

구간 제어 타이밍으로 배포하기 전에:

• 다단계 구간을 통한 평균 사용자 여정 시간 측정
• Alive Notice 기간 만료 = 평균 시간 + 20-30초 설정
• Alive Notice 재요청 주기 < 타임아웃 최소값 확인
• 타임아웃 시나리오 테스트 (브라우저 닫기, 네트워크 연결 끊김)
• 조기 리소스 해제 또는 멈춘 리소스 모니터링

관련 구성 옵션은 대기 순번 유지 및 진입 키 무효화 문서를 참조하세요.