WAS 장애·세션 유실·APM 선택 기준 정리 — OPENMARU iAP 제품 소개 자료 다운로드

세션 유실, 스레드 고갈, Full GC까지 WAS 장애 유형별로 어디를 봐야 하는지 정리했습니다. 오픈소스·국내 상용·해외 SaaS·통합 플랫폼 네 가지 APM 비교표와 함께 OPENMARU iAP 제품 소개 자료를 받아 보십시오.

세션 클러스터링을 지원하는 WAS 에서 왜 세션이 사라집니까?

세션이 WAS 안쪽 메모리에 들어 있기 때문입니다. 서버가 죽으면 그 안의 세션도 함께 사라집니다. 복제를 촘촘히 하면 이번에는 메모리 정리 지연과 네트워크 부하가 생깁니다. 세션을 서버 밖의 별도 저장소로 옮기면 문제가 갈라집니다. 서버를 교체해도 세션은 그대로 남습니다.

용어부터 정리하겠습니다. 세션은 사용자가 로그인한 뒤 로그아웃할 때까지 서버가 기억하는 사용자 상태입니다. 이게 사라지면 로그인이 풀립니다.

세션 클러스터링은 여러 서버가 세션을 나눠 갖는 방식입니다. 서버 하나가 죽어도 사용자는 로그인 상태를 유지합니다.

문제는 그 세션을 어디에 두느냐입니다. 기존 WAS의 내장 복제는 세션을 자바 힙 메모리 안에 둡니다. 그래서 Full GC의 영향을 그대로 받습니다. Full GC는 자바가 메모리를 정리하려고 프로그램을 잠시 멈추는 동작입니다. 이 멈춤이 길어지면 응답이 끊깁니다.

대안은 세션을 WAS 밖의 별도 메모리 저장소에 두는 것입니다. 이 저장소를 IMDG(인메모리 데이터 그리드)라고 부릅니다.

[자료 19쪽] 세션을 JVM 밖으로 — 내장 복제와 외부 IMDG 비교

내장 복제 방식과 외부 IMDG를 세션 저장 위치·GC 영향·확장성·장애 복구·이기종 WAS 지원 다섯 항목으로 비교한 표

같은 항목을 놓고 두 방식을 비교한 자료입니다. 왼쪽이 기존 WAS의 내장 복제, 오른쪽이 외부 IMDG입니다.

읽는 순서는 두 번째 행부터입니다. GC 영향 행이 새벽 2시 장애의 직접 원인입니다. 세션이 힙 안에 있으면 Full GC 정지가 곧 세션 접근 지연입니다. 힙 밖에 있으면 GC가 세션을 건드리지 않습니다.

장애 복구 행은 신고 건수를 가릅니다. 내장 복제는 노드가 죽는 순간 복제가 덜 된 세션을 잃습니다. 외부 IMDG는 무손실 페일오버를 목표로 설계합니다.

마지막 이기종 WAS 지원 행은 실무에서 늦게 체감하는 항목입니다. Tomcat과 JBoss가 섞인 환경에서 세션을 공유해야 한다면 내장 복제로는 풀리지 않습니다. 자료는 Hazelcast·Redis·Apache Ignite 연동을 밝히고 있습니다. 모두 분산 메모리 그리드입니다.

세션을 밖으로 빼면 WAS는 상태를 갖지 않는 구조가 됩니다. Stateless라고 부릅니다. 인스턴스를 늘리고 줄이고 교체해도 사용자가 로그아웃되지 않습니다. 무중단 배포가 실제로 무중단이 되는 지점입니다.

여기까지 정리
세션 유실의 원인은 복제 횟수가 아니라 저장 위치입니다.
힙 안에 두면 GC와 노드 장애를 그대로 받습니다.
밖으로 빼면 무중단 배포와 이기종 WAS 세션 공유가 함께 열립니다.

네 가지 제품군 비교표와 MTTR·TCO 산출 기준을 자료에서 확인하십시오.

OPENMARU iAP 제품 소개 자료 · PDF 45쪽 · 통합 아키텍처와 구축 5단계 수록

자료 다운로드 ›

스레드 덤프와 GC 로그를 다 봤는데 왜 원인이 안 나옵니까?

덤프와 로그는 한 시점의 사진이기 때문입니다. 장애는 요청이 여러 서버를 지나며 만들어집니다. 사진 여러 장을 놓고 순서를 맞추는 일이 남습니다. 그래서 요청 하나를 처음부터 끝까지 따라가는 추적이 필요합니다. 웹서버에서 WAS, 세션 저장소, 데이터베이스까지 한 줄로 이어 봐야 막힌 지점이 보입니다.

APM은 어느 요청이 어디서 막혔는지 코드 수준까지 추적하는 도구입니다. 애플리케이션이 느려지거나 오류가 날 때 씁니다. 지표와 로그가 “무엇이 일어났는가”를 알려 준다면, APM은 “어느 요청이 어디서 막혔는가”를 알려 줍니다.

아래 표는 장애 유형별로 어디를 먼저 열어야 하는지를 정리한 것입니다. 증상만 보고 도구를 고르지 않도록 순서를 붙였습니다.

장애 유형	증상	어디를 봐야 하는가
스레드 고갈	응답 지연, 요청 큐 적체	스레드 상태·블로킹·데드락 실시간 분석
커넥션 풀 고갈	특정 시점부터 전면 지연	트랜잭션 구간별 지연 + SQL 연동 분석
Full GC 폭주	주기적 정지, 메모리 사용량 우상향	힙·GC 이벤트와 트랜잭션 지연의 상관관계
세션 복제 지연·유실	로그인 풀림, 노드 교체 시 이탈	세션 그리드 동기화 실패·데이터 흐름 이상
데이터베이스 병목	WAS는 정상인데 느림	실행 SQL과 처리 결과 연동

스레드 고갈은 요청을 처리할 일꾼이 전부 붙잡혀 새 요청이 대기하는 상태입니다. 서버는 살아 있는데 응답이 안 옵니다. 헬스 체크가 통과하는 이유도 여기에 있습니다.

표의 오른쪽 칸을 보면 공통점이 보입니다. 전부 한 요청을 끝까지 따라가야 답이 나오는 항목입니다.

[자료 21쪽] Web부터 DB까지, 하나의 트랜잭션으로 추적

웹 서버에서 WAS, 세션 클러스터, 데이터베이스까지 하나의 트랜잭션 ID로 전 구간을 추적하는 구조도

네 개의 상자가 요청이 지나는 경로입니다. 이 네 구간을 하나의 트랜잭션 ID로 묶는 것이 그림의 요지입니다.

왜 묶어야 하는지는 반대 상황을 떠올리면 분명합니다. 웹서버 로그, WAS 로그, 세션 저장소 지표, 데이터베이스 슬로우 쿼리가 따로 놉니다. 사람이 시각을 맞춰 가며 짝을 짓습니다. 세 시간은 그렇게 흘러갑니다.

아래 세 상자 중 오른쪽 수치에는 조건이 붙습니다. 장애 대응 시간 50% 단축은 제품 자료가 인용한 대형 유통 사례 기준입니다. 일반화된 벤치마크가 아닙니다.

여기서 갈리는 지점이 하나 더 있습니다. 외부 APM 에이전트는 WAS 커널 내부와 세션 그리드까지 보지 못하는 경우가 많습니다. 미들웨어 계층에서 난 장애는 표면 지표만 남습니다. 제품 자료 22쪽은 세 가지를 직접 계측한다고 설명합니다. 스레드 상태, 힙과 Full GC 이벤트, 세션 그리드 파이프라인입니다.

여기까지 정리
덤프와 로그는 시점 정보이고, 장애는 구간에서 만들어집니다.
장애 유형별 확인 지점은 전부 한 요청을 끝까지 따라가야 답이 나옵니다.
세션 그리드까지 보이느냐가 미들웨어 장애에서 갈리는 기준입니다.

APM은 무엇을 기준으로 고릅니까?

여섯 가지를 봅니다. 추적 깊이, 세션 저장소 가시성, 폐쇄망 지원 여부입니다. 여기에 비용이 늘어나는 방식, AI 기능, 국내 지원을 더합니다. 오픈소스는 시작이 쉽습니다. 국내 상용은 지원이 두껍습니다. 해외 SaaS는 한 화면에서 다 봅니다. 미들웨어 안쪽까지 봐야 한다면 통합 플랫폼을 검토합니다.

시장은 네 유형으로 나뉩니다. 우열이 아니라 결정적 요건으로 읽으시면 됩니다.

오픈소스 경량 APM — Scouter, Pinpoint. Scouter는 LG CNS가, Pinpoint는 네이버가 만든 자바 계열 도구입니다. 도입 장벽이 낮은 대신 운영 주체가 곧 사용자입니다. Pinpoint는 HBase 의존성 때문에 운영 난도가 올라갑니다.
국내 상용 APM — 제니퍼소프트, 와탭. 국내 서버 APM에서 사용층이 가장 두껍습니다. 제니퍼소프트는 웹·미들웨어 APM 시장에서 60% 이상 점유율로 보도됩니다.
해외 SaaS 통합 관측 — Datadog, New Relic. 로그·지표·추적을 한 화면에서 다룹니다. 데이터가 밖으로 나가고, 사용량이 늘면 비용이 함께 늡니다.
통합 미들웨어 플랫폼 — OPENMARU iAP. Web/WAS·세션 클러스터·APM·AI 운영을 단일 라이선스로 묶은 방식입니다.

아래 표는 위 네 유형을 여섯 기준으로 나란히 놓은 것입니다. 자기 환경에서 양보할 수 없는 한 줄을 먼저 찾으시면 선택이 빨라집니다.

비교 기준	오픈소스 경량 APM	국내 상용 APM	해외 SaaS APM	통합 미들웨어 플랫폼(iAP)
트랜잭션 추적 깊이	메서드 단위 추적, JVM 심층 분석은 별도 도구	트랜잭션·SQL 추적 성숙	분산 추적 강점, 다언어 지원	Web→WAS→세션 Cluster→DB 단일 ID 추적
세션 클러스터 가시성	대상 아님	대상 아님(WAS 기능으로 별도)	대상 아님	세션 그리드 동기화 실패까지 계측
폐쇄망 지원	자체 구축이므로 가능	온프레미스 구축 지원	SaaS 기본, 폐쇄망은 제약	물리·가상 환경 지원
도입·운영 비용	라이선스 없음, 인건비가 비용	라이선스 + 유지보수	사용량 과금, 트래픽 증가 시 상승	단일 영구 라이선스에 통합 포함
LLM 연동	없음	제품별 상이	자체 AI 기능 제공	LLM 기반 VibeOps 내장
국내 기술 지원	커뮤니티	국내 벤더 직접	파트너 경유	국내 벤더 직접, GS 1등급·조달청 등록

경쟁 제품 칸은 각 벤더의 공개 자료에서 확인 가능한 사실만 적었습니다. 확인되지 않은 항목은 “제품별 상이”로 두었습니다.

[자료 39쪽] 표준·세션·APM·AI 비교 — 제품 자료의 자체 비교표

Jakarta EE 대응, 세션 외부화, APM 통합, AI 운영, 프로비저닝 속도, TCO 절감 여섯 항목으로 글로벌 상용·국내 상용·오픈소스 상용 WAS와 OPENMARU iAP를 비교한 표

앞의 표가 APM 제품군 비교라면, 이 표는 WAS 제품군 비교입니다. 비교 대상을 먼저 확인하시기 바랍니다. WebLogic·WebSphere·JEUS·JBoss·Tomcat입니다.

읽을 때 주의할 행이 두 개 있습니다. 세션 외부화 행과 APM 통합 행입니다. 상용 WAS는 세션을 내장 복제로 처리하고 APM은 따로 삽니다. 앞 절에서 본 두 가지 비용이 여기서 다시 나타납니다.

Jakarta EE 11 대응 행은 표현을 나눠 읽으셔야 합니다. 제품 자료 16쪽 기준으로 iAP가 인증을 받은 규격은 Jakarta EE 10입니다. EE 11은 대응 단계입니다. 인증과 대응은 다른 말입니다.

이 표는 제품 자료의 자체 비교입니다. 벤더가 자기 제품을 놓고 만든 표라는 점을 감안해 읽으시면 됩니다.

자료로 확인할 수 있는 것
네 유형을 우리 환경 기준으로 비교한 표, 구성 요소별 아키텍처, 지원 환경 목록이 45쪽 자료에 들어 있습니다.
OPENMARU iAP 제품 소개 자료 받기 — 이 글 아래 다운로드 카드에서도 받으실 수 있습니다.

AIOps와 VibeOps는 뭐가 다릅니까?

누가 판단하느냐가 다릅니다. AIOps는 이상 징후를 찾아내고 정해진 규칙대로 처리합니다. 판단은 사람이 합니다. VibeOps는 AI가 로그와 지표와 추적을 함께 읽습니다. 한국어로 물으면 원인을 짚어 답합니다. 운영자는 알람을 확인하는 자리에서, 조치를 승인하고 정책을 설계하는 자리로 옮겨 갑니다.

용어를 먼저 갈라 두겠습니다. AIOps는 머신러닝으로 이상 징후를 찾아내고 정해진 규칙에 따라 자동 처리하는 운영 방식입니다. VibeOps는 여기서 한 걸음 더 나아갑니다. 한국어로 물으면 AI가 원인을 찾아 답하는 운영 방식입니다.

[자료 24쪽] DevOps에서 AIOps, 그리고 VibeOps로

DevOps·AIOps·VibeOps 세 단계를 각각 하는 일과 사람의 역할로 구분해 나열한 도식

세 상자를 왼쪽부터 읽으면 사람이 하는 일이 어떻게 바뀌는지가 보입니다.

DevOps는 배포 파이프라인을 자동화했습니다. 분석과 대응은 여전히 사람 몫입니다. AIOps는 머신러닝으로 이상을 탐지합니다. 다만 로그와 지표와 추적을 가로질러 원인을 잇는 데는 한계가 있습니다.

VibeOps는 그 연결을 AI가 맡습니다. 아래 파란 상자의 설명이 핵심입니다. 운영자의 자리는 복구 담당에서 정책 설계로 옮겨 갑니다.

그래서 실제로 무엇이 달라지는지 두 장면으로 보겠습니다.

이전 — 장애 발생, WAS 로그 수동 확인, APM 트랜잭션 추적, 데이터베이스 쿼리 분석. 수 시간이 걸립니다.
이후 — “어제 새벽 2시 WAS 세션 소실 이유를 분석해 줘”라고 묻습니다. 실시간 세션 데이터와 과거 APM 데이터를 함께 분석해 원인과 조치를 답합니다. 수 초입니다.

답변의 수준도 갈립니다. “메모리 누수 의심”은 조치로 이어지지 않습니다. 필요한 것은 이런 문장입니다. “A 서비스의 B 메서드에서 C 객체가 과도하게 생성되어 Old Generation이 급증했습니다. X 시점 Y 배포 이후 시작된 것으로 추정됩니다.”

여기까지 정리
AIOps와 VibeOps의 차이는 성능이 아니라 판단 주체입니다.
쓸 만한 답변은 “의심”이 아니라 원인·시점·코드 영역까지 짚습니다.
운영자의 역할은 알람 확인에서 정책 설계로 옮겨 갑니다.

"AI가 알아서 한다"는 말을 어디까지 믿어야 합니까?

승인 없이 실행하는 자동화는 믿지 않으셔도 됩니다. AI 운영에서 실제로 중요한 것은 모델 성능이 아니라 통제 장치입니다. 아래 다섯 가지가 없으면 자동화는 사고 확대 장치가 됩니다.

실행 단계 제한과 비용 상한 — 한 번에 밟을 수 있는 단계와 호출 비용을 미리 묶습니다.
도구 허용 목록 — AI가 호출할 수 있는 명령의 범위를 확정합니다. 목록에 없으면 실행하지 않습니다.
조치 전 사람의 승인 — 스크립트는 생성하되 실행은 승인 뒤에 합니다.
감사 로그 — 무엇을 근거로 그 결론을 냈는지 남깁니다. 사후 검증이 가능해야 합니다.
근거 강화 — 운영 데이터에 근거하지 않은 답변을 억제합니다. 이 방법을 RAG라고 부릅니다. AI가 답하기 전에 실제 운영 데이터를 먼저 찾아보게 하는 방식입니다.

제품 자료는 실시간 세션 데이터와 과거 APM 데이터를 함께 검색해 답변 근거로 쓴다고 설명합니다. 답변이 지어낸 문장인지 데이터에서 나온 문장인지를 가르는 장치입니다.

운영 로그를 외부 LLM에 보내도 됩니까?

그대로는 안 됩니다. 로그에는 사용자 식별자와 요청 값이 들어 있습니다. 모델에 넘기기 전에 개인정보를 가리는 단계가 필요합니다. 망분리 환경이라면 모델을 망 안에 두는 구성을 검토합니다. 규제 요건이 곧 배치 방식을 결정합니다.

제약은 네 가지입니다. 순서대로 확인하시면 됩니다.

규제 — 개인정보 처리와 국외 이전 문제가 먼저 걸립니다. 금융과 공공은 망분리 요건이 더해집니다. 금융 분야 망분리 규제는 완화 흐름에 있지만, 완화는 조건부입니다.
망분리 환경 — 업무망과 인터넷망을 나눠 둔 환경입니다. 외부 API 호출 자체가 막힙니다. 모델이 망 안에 있어야 합니다.
비용과 지연 — 로그와 지표는 양이 큽니다. 토큰 단위 과금에서 상시 분석은 곧 비용입니다. 왕복 지연은 장애 대응 속도를 깎습니다.
데이터 주권 — 학습에 쓰이지 않는다는 보장, 저장 위치, 삭제 요구권을 조직이 통제할 수 있어야 합니다.

결론부터 말씀드리면 “무조건 내부 모델”이 답은 아닙니다. 실제 결정 요인은 데이터가 어디까지 나가는가입니다. 이 문제는 두 가지 수단으로 풉니다. 하나는 넘기기 전에 가리는 것이고, 다른 하나는 모델을 어디에 두느냐입니다.

제품 자료 27쪽은 모델을 동적으로 선택하는 구성을 제시합니다. 운영 시나리오에 따라 GPT·Claude·Gemini를 고릅니다. 그리고 그 앞단에 컨텍스트 계층을 둡니다. MCP는 AI에게 데이터를 넘기는 통로를 표준화한 규격입니다. 자료는 이 계층에서 한국어 개인정보를 자동으로 가린다고 밝히고 있습니다.

아래 표는 조직 유형별로 먼저 확인할 항목을 정리한 것입니다. 자기 조직 행만 보시면 됩니다.

조직 유형	먼저 확인할 것	실무 판단
일반 기업	개인정보 포함 여부, 국외 이전 동의	마스킹 계층을 갖추면 외부 모델 활용 여지가 큽니다
공공기관	망분리 여부, 감사 추적 요건	망 안 배치를 우선 검토하고 감사 로그를 필수로 둡니다
금융회사	전자금융감독규정, 내부망 이용 요건	조건부 완화 범위를 먼저 확인한 뒤 배치 방식을 정합니다

한 가지는 분명히 해 두겠습니다. 제품 소개 자료에는 “로컬 LLM 내장”이나 “자체 호스팅 모델”이라는 서술이 없습니다. 자료가 제시하는 것은 하이브리드 모델 선택과 컨텍스트 계층의 마스킹입니다. 망 안에 모델을 두는 구성이 필요하시다면 도입 검토 단계에서 별도로 확인하시기 바랍니다.

여기까지 정리
판단 기준은 모델 종류가 아니라 데이터의 이동 범위입니다.
넘기기 전 마스킹과 모델 배치 위치, 두 수단으로 풉니다.
조직 유형에 따라 확인 순서가 다릅니다.

도입하면 무엇이 얼마나 달라집니까?

제품 자료 기준으로 네 가지가 달라집니다. 장애 복구 시간이 60% 줄어듭니다. 세 시간 걸리던 복구가 한 시간대로 내려오는 수준입니다. 장애 건수는 40% 줄고, 총 소유 비용은 30~40% 줄어듭니다. 가용성은 99.9% 이상을 유지합니다.

MTTR은 장애가 나서 복구할 때까지 걸리는 평균 시간입니다. 이 시간이 곧 서비스 중단 시간입니다. TCO는 라이선스뿐 아니라 유지보수·인력·장애 대응까지 합친 총 소유 비용입니다.

[자료 41쪽] 숫자로 증명되는 도입 효과

MTTR 60% 단축, 장애 발생 40% 감소, TCO 30~40% 절감, 서비스 가용성 99.9% 이상 네 지표를 카드로 정리한 도식

네 개의 카드 아래에 작은 글씨로 근거가 붙어 있습니다. 숫자만 보지 마시고 그 아래 한 줄을 함께 보시기 바랍니다.

MTTR 60% 단축의 근거는 VibeOps 자동 원인 분석입니다. 장애 40% 감소는 AI 예측과 예방입니다. TCO 30~40% 절감은 단일 라이선스 통합에서 나옵니다. 가용성 99.9% 이상은 IMDG 무손실 페일오버입니다. 각 수치는 서로 다른 기능에서 나온 값입니다.

비용 구조는 한 번 더 짚겠습니다. 제품 자료 40쪽 기준으로 라이선스 1카피는 최대 32코어·1노드 영구 라이선스입니다. 여기에 Web/WAS·APM·세션 클러스터·설치 도구·AI가 포함됩니다. 조립식 구매에서 생기는 라이선스 합산과 관리 포인트 분산을 없애는 것이 절감의 출처입니다.

이 수치들은 모두 제품 자료 기준입니다. 제3자 검증 결과가 아닙니다. 산출 기준과 전제 조건은 자료 본문에 적혀 있습니다.

숫자의 산출 근거를 확인하시려면
MTTR·TCO 수치의 계산 전제, 구성 사례, 구축 5단계, 지원 환경 목록이 45쪽 자료에 들어 있습니다.
OPENMARU iAP 제품 소개 자료 받기

자주 묻는 질문

Q1. 세션 클러스터링이란 무엇입니까?

여러 서버가 사용자 세션을 나눠 갖는 기술입니다. 서버 하나가 죽어도 사용자는 로그인 상태를 유지합니다. 세션을 어디에 두느냐에 따라 내장 복제와 외부 저장으로 나뉩니다. 외부 저장은 세션을 WAS 밖의 메모리 그리드에 둡니다.

Q2. APM과 모니터링 도구는 어떻게 다릅니까?

보는 단위가 다릅니다. 모니터링 도구는 서버와 자원의 상태를 봅니다. APM은 요청 하나를 코드 수준까지 따라갑니다. CPU가 정상인데 특정 화면만 느린 상황은 APM에서만 설명됩니다.

Q3. 스카우터에서 옮긴다면 무엇을 확인해야 합니까?

네 가지를 확인하시면 됩니다. 지금 겪는 장애가 미들웨어 안쪽에서 나는지 봅니다. 세션 저장소까지 볼 필요가 있는지 봅니다. 기술 지원을 누구에게 받을지 정합니다. 운영 인건비를 포함한 총비용 변화를 계산합니다. 오픈소스는 라이선스가 없는 대신 운영을 직접 해야 합니다.

Q4. 폐쇄망에서도 AI 운영 기능을 쓸 수 있습니까?

구성에 따라 다릅니다. 판단 기준은 운영 데이터가 망 밖으로 나가는지 여부입니다. 제품 자료는 컨텍스트 계층에서 한국어 개인정보를 자동으로 가리는 방식을 제시합니다. 망 안에 모델을 두는 구성이 필요하시다면 도입 검토 단계에서 확인하시기 바랍니다.

Q5. iAP는 쿠버네티스를 지원합니까?

iAP는 물리 서버와 가상화 환경에서 운영하는 기존 Web/WAS를 대상으로 하는 제품입니다. 쿠버네티스 오케스트레이션이 필요하시면 상위 제품인 MSAP COP가 담당합니다. 마이크로서비스와 AI 서비스 영역은 MSAP.ai로 이어집니다. 지금 쓰는 WAS를 그대로 두고 개선하실 계획이라면 iAP가 검토 대상입니다.

참고 리소스

남은 질문은 자료에서 확인하십시오

여기까지 읽으시면 판단 기준은 서 있습니다. 남은 것은 우리 환경의 숫자입니다.

45쪽 OPENMARU iAP 제품 소개 자료에는 아래 내용이 들어 있습니다.

네 가지 제품군을 여섯 기준으로 비교한 표와 각 항목의 근거
Web/WAS·세션 클러스터·APM·AI 운영의 통합 아키텍처 구성도
MTTR·TCO 수치의 산출 기준과 라이선스 구조
컨설팅부터 기술 이전까지 구축 5단계
운영체제·JDK·WAS 등 지원 환경 목록

OPENMARU iAP 제품 소개 자료 받기

도입 환경을 놓고 상담을 원하시면 OPENMARU 문의로 연락 주십시오. 현재 구성과 장애 유형을 알려 주시면, 어느 항목부터 확인하면 되는지 먼저 정리해 드립니다.