Nvidia Brev 보안 침해, 고객 VM 접근 권한에 의문 제기
Nvidia는 악용 증거를 찾지 못했음에도 10월 4일부터 10월 20일까지 Brev에서 무단 활동이 발생한 뒤 고객 접근 키를 교체한 것으로 알려졌다. Nvidia Brev 보안 침해는 암호화된 원격 접속 프로토콜인 Secure Shell에 사용되는 자격 증명인 SSH 키와 관련된다. 이 키는 개발자를 원격 인프라에서 실행되는 소프트웨어 정의 컴퓨터인 가상 머신에 연결한다. 따라서 노출 가능성은 계정 정보의 보안을 넘어 머신 접근 권한에 관한 의문을 제기한다.
Tom’s Hardware가 설명한 고객 통지에 따르면, Nvidia는 영향을 받은 키를 교체하고 고객 머신을 업데이트했다. 이는 즉각적인 접근 위험을 해결한다. 그러나 별도의 질문은 남는다. 기존 자격 증명이 교체되기 전에 사용됐는지를 어떤 증거로 확인할 수 있는가? 클라우드 환경에 단발성 실험을 넘어선 작업물이 들어 있는 개발자에게는 이 구분이 중요하다.
핵심적인 긴장은 자동화된 접근 관리와, 관리형 자격 증명에 문제가 제기됐을 때 뒤따르는 책임성 사이에 있다. Amazon EC2는 기존 키 페어 방식에서 개인 키의 보관 책임을 고객에게 맡기기 때문에 유용한 비교 대상이다. Brev는 이 운영 작업의 더 많은 부분을 서비스 안에서 처리한다. 어느 방식도 위험을 없애지는 않지만, 문제가 발생했을 때 책임을 배분하는 방식은 서로 다르다.
Nvidia Brev 보안 침해 보도가 확인한 내용
Tom’s Hardware는 2026년 11월 2일 Brev 보안 사고에 관한 보도를 게재했다. 핵심 조사 결과는 영향을 받은 고객에게 발송된 통지에 근거한 것으로 전해진다. 보고된 무단 활동 기간은 10월 4일부터 10월 20일까지다.
통지는 플랫폼이 관리하는 SSH 키를 포함해 Brev 내에 보관된 정보가 노출됐을 가능성을 지목한 것으로 알려졌다. Nvidia는 해당 자격 증명을 교체하고 연결된 인스턴스를 업데이트했다고 밝혔다. 회사는 부적절한 사용의 증거를 찾지 못했다고도 말했다.
자격 증명 노출 가능성과 고객 머신에 대한 확인된 접근은 서로 다른 조사 결과다. 현재 알려진 내용은 전자를 보도할 근거는 제공하지만, 후자는 미해결 상태로 남긴다. 또한 모든 Brev 고객이 영향을 받았다는 사실을 입증하지는 않는다.
보도는 진입 지점, 영향받은 대상 범위, 고객 워크로드 접근의 정도도 명확히 밝히지 않는다. 이러한 공백은 사고 평가에 제약을 준다. 그렇다고 특정 공격자나 기법에 관한 추정으로 빠진 세부 사항을 채워도 된다는 뜻은 아니다.
Nvidia Brev 침해 사건의 설명을 찾는 독자에게 핵심 구분은 보유와 사용 사이에 있다. 조사관이 성공적인 로그인을 확인하지 못했더라도 누군가 접근 자격 증명을 확보했다면 보안 문제는 발생한다. 반대로 성공적인 로그인이 확인된다면 권한과 그 후속 행위에 관한 추가 질문이 제기된다.
이는 조사 과정의 별개 단계다. 한 단계의 증거가 다음 단계의 답을 자동으로 제공할 수는 없다. 이를 같은 것으로 취급하면 침해를 과장한 서사가 되거나 지나치게 안심시키는 복구 서사가 만들어진다.
사고 날짜에도 같은 주의가 필요하다. 보고된 무단 플랫폼 활동 기간이 모든 영향을 받은 고객 환경에 대한 지속적인 접근을 뜻하지는 않는다. 마찬가지로 그 종료 시점만으로 모든 시정 조치가 언제 마무리됐는지는 설명되지 않는다.
독자들은 이 통지를 관련 없는 Nvidia 제품에 대한 결론으로 확대해서도 안 된다. 보고된 사건은 Brev와 그 개발 환경에 연결된 자격 증명에 관한 것이다. 범위를 확대하려면 추가 증거가 필요하다.
현재로서는 방어 가능한 평가는 제한적이지만 중요하다. Nvidia는 노출 가능성이 있는 머신 접근 자격 증명에 조치한 것으로 알려졌다. 고객은 여전히 이 조치를 자신의 환경 및 보안 기록과 연결할 수 있을 만큼 충분한 정보를 필요로 한다.
이 때문에 이번 공개는 단순한 계정 보안 공지를 넘어선다. 개발 플랫폼과 그 플랫폼이 관리하도록 돕는 머신 간의 관계를 면밀히 살펴보게 한다. 실질적 의미는 해당 자격 증명이 어떤 권한을 부여했는지와 조사관이 무엇을 검증할 수 있는지에 달려 있다.
개발자는 자동 접근 관리 뒤의 조사를 떠안는다
즉각적인 부담은 개발 환경을 계속 신뢰할 수 있는지 결정해야 하는 팀에 놓인다. 교체 키는 그 결정의 한 부분을 해결한다. 그러나 모든 고객의 내부 검토에 필요한 증거를 자동으로 제공하지는 않는다.
개발자는 교체 후에도 정상 연결이 작동하는지 합리적으로 물을 수 있다. 보안팀은 더 폭넓은 답을 필요로 한다. 어떤 환경이 범위에 포함되는지, 어떤 접근이 가능했는지, 그리고 어떤 기록이 평가를 뒷받침하는지를 이해해야 한다.
내부 문서를 기준으로 AI 모델을 평가하기 위해 원격 머신을 사용하는 가상의 팀을 생각해 보자. 그 환경에는 테스트 파일, 소스 코드, 다른 서비스의 자격 증명이 있을 수 있다. 이 사례는 잠재적 영향을 보여 주는 예시일 뿐이며, 이런 자료가 Brev를 통해 노출됐다는 증거는 아니다.
팀의 대응은 실제 구성에 따라 달라진다. 공개 예시만 포함된 환경은 내부 리소스에 연결된 환경과 다른 문제를 제기한다. “개발”이나 “실험” 같은 라벨만으로는 이러한 차이를 판단할 수 없다.
여기서 Nvidia Brev 침해의 영향은 운영상의 질문이 된다. 고객은 해당 기간에 영향을 받은 환경에 무엇이 있었는지 파악해야 한다. 또한 그 환경이 접근할 수 있도록 허용된 다른 시스템이 무엇인지 이해해야 한다.
소프트웨어가 다른 서비스를 호출할 때 사용하는 자격 증명인 application programming interface 키는 이러한 종속성 문제를 잘 보여 준다. 머신의 SSH 자격 증명을 교체한다고 해서 그러한 키까지 자동으로 교체되지는 않는다. 추가 교체가 필요한지는 증거와 노출 상황에 달려 있다.
이러한 구분은 조직 경계를 넘는 작업을 만든다. 실험을 시작한 사람은 그 파일을 알고 있을 수 있다. 다른 팀은 외부 자격 증명을 관리할 수 있다. 중앙 보안 그룹은 관련 접근 기록을 보유할 수 있다.
조율이 없으면 각 그룹은 자체 작업을 완료하면서도 전체 평가는 미완성으로 남길 수 있다. 인프라 담당자는 연결성을 확인할 수 있지만, 애플리케이션 소유자는 민감한 자료에 관한 명확한 설명을 여전히 얻지 못할 수 있다. 공급업체의 시정 조치 메시지는 이러한 내부 매핑을 대체할 수 없다.
환경 소유권을 검색할 수 있는 기록은 이러한 책임을 연결하는 데 도움이 된다. 문서화 관행을 검토하는 팀은 의사결정과 절차를 위해 기술 지식 베이스를 고려할 수 있다. 비밀 값 자체는 자격 증명 보호를 위해 설계된 시스템에 보관해야 한다.
엔터프라이즈 구매자는 관련된 구매 질문에 직면한다. 관리형 접근 메커니즘이 연루됐을 때 개발 서비스가 조사를 어떻게 지원하는지 알아야 한다. 온보딩을 가속하는 기능에는 소유권, 접근 철회, 증거 제공 가능성에 관한 명확한 설명이 따라야 한다.
이는 영향을 받은 모든 환경이 같은 대응을 해야 한다는 의미가 아니다. 고객이 상황에 비례하는 결정을 내릴 수 있도록 충분한 세부 정보가 필요하다는 뜻이다. 플랫폼이 접근을 단순화하면서도 사고 범위를 재구성하기 어렵게 만들면 운영 부담은 커진다.
관리형 키는 편의성과 함께 책임도 옮긴다
Brev의 자동 SSH 구성 문서는 사용자를 위해 키와 연결 설정을 처리하는 워크플로를 설명한다. 서비스를 제어하는 텍스트 기반 도구인 명령줄 인터페이스는 사용자가 로그인한 후 개인 키를 다운로드한다. 문서는 로컬 개인 키 파일을 ~/.brev/brev.pem로 명시한다.
이 워크플로는 보고된 노출 가능성이 Brev의 제품 설계에 중요한 이유를 설명한다. 사용자는 접근 설정의 일부를 플랫폼에 위임한다. 수동 단계를 없애는 동일한 통합 기능은 조사관이 자격 증명 처리를 평가할 때도 중요해진다.
자동 키 관리는 운영 책임을 이전할 뿐, 근본적인 보안 결정을 없애지는 않는다. 여전히 누군가는 자격 증명이 어디에 위치하는지, 어떤 머신이 이를 허용하는지, 권한 부여가 어떻게 종료되는지를 결정한다. 제품 인터페이스는 이러한 결정을 숨길 수 있지만, 사라지게 하지는 않는다.
Amazon은 기존 EC2 키 페어에 대해 다른 보관 방식을 문서화한다. 공개 키는 인스턴스에 저장되고 고객은 개인 키를 보관한다. AWS는 EC2가 해당 개인 키의 복구 가능한 사본을 보관하지 않는다고 설명한다.
이 비교는 양사의 전반적인 보안에 대한 판정이 아니라 특정 접근 워크플로에 관한 것이다. EC2에서 동등한 사고가 발생할 수 없다는 사실을 입증하지도 않는다. 고객이 보관하는 자격 증명에는 저장, 공유, 복구에 관한 자체 책임이 따른다.
그럼에도 이러한 아키텍처 차이는 유용하다. 개인 키 보관을 책임지는 개발자는 이를 로컬에서 보호해야 한다. 관리형 워크플로는 자격 증명의 전체 수명 주기에 걸친 서비스의 처리 방식에 대한 신뢰를 필요로 한다.
이러한 방식은 사고 대응에도 영향을 준다. 자체 키를 보유한 고객에게는 신뢰할 수 있는 목록과 교체 절차가 필요하다. 관리형 자격 증명에 의존하는 고객은 공급자가 영향을 받은 권한 부여를 식별하고 시정 조치를 설명할 수 있다는 확신이 필요하다.
Brev의 SSH 키 관리 문서는 팀 구성원이나 자동화 시스템을 위한 추가 키도 허용한다. 이 기능은 모든 검토에 또 다른 구분을 더한다. 플랫폼 관리 자격 증명과 별도로 추가된 자격 증명은 자동으로 동일한 조사 대상이 되지 않는다.
추가 키가 존재한다는 사실이 이번 사건에 그것들이 연루됐음을 뜻하지는 않는다. 다만 정확한 범위가 왜 중요한지는 보여 준다. 한 자격 증명 범주에 관한 설명은 다른 접근 경로와 어떤 관계가 있는지 밝혀야 한다.
따라서 Nvidia Brev 침해의 영향을 평가하는 팀에 적절한 비교 기준은 책임과 가시성이다. 누가 자격 증명 생성을 통제하는가? 누가 접근을 철회할 수 있는가? 누가 의심스러운 연결을 설명하는 데 필요한 기록을 제공할 수 있는가?
서비스는 이러한 작업을 잘 관리함으로써 상당한 가치를 제공할 수 있다. 이번 사건은 Nvidia가 불리한 상황에서도 그러한 관리가 이해 가능하도록 해야 한다는 압박을 가한다. 고객은 편리한 연결 명령 뒤에 놓인 보안 동작을 이해할 필요가 있다.
이러한 상충 관계는 호스팅형 개발 서비스 전반에서 익숙하다. 위임은 수동 설정으로 인한 실수를 줄일 수 있다. 동시에 공급업체의 통제와 조사 역량은 고객 자체 보안 태세의 일부가 된다.
키 교체는 미래의 접근을 다루고, 증거는 과거를 다룬다
노출된 자격 증명을 교체하는 일과 교체 전에 무슨 일이 있었는지 확인하는 일은 별개의 작업이다. 둘 다 중요하지만 서로 다른 질문에 답한다. 한 작업의 완료를 다른 작업의 증거로 취급하면 복구 평가는 신뢰할 수 없게 된다.
기존의 SSH 키 인증에서는 서버가 연결 주체가 보유한 개인 키에 대응하는 공개 키를 수용합니다. 기존 권한을 제거하는 일은 해당 자격 증명의 효용을 끝내는 핵심 절차입니다. 단순히 새 키를 만드는 것만으로는 완전한 결과를 설명할 수 없습니다.
보도된 Nvidia의 조치에는 고객 인스턴스 업데이트가 포함됐으며, 따라서 이는 의미 있는 세부 사항입니다. 그러나 공개된 설명은 인스턴스별 검증 기록을 제공하지 않습니다. 고객은 각자의 환경에 관한 세부 사항을 직접적인 소통을 통해 확인해야 합니다.
건전한 검토는 예정된 교체와 완료된 교체를 구분해야 합니다. 또한 새 자격 증명의 성공적인 배포와 이전 권한이 더 이상 작동하지 않는다는 확인도 구분해야 합니다. 이는 Nvidia가 어느 한 단계를 생략했다는 주장이 아니라 평가 기준입니다.
과거 활동 검토는 또 다른 과제를 제시합니다. 조사관은 노출 기간 중 관련 활동을 보여줄 수 있는 기록이 필요합니다. 결론은 해당 기록이 무엇을 포괄하는지, 얼마나 오래 보존됐는지, 어떻게 평가됐는지에 따라 달라집니다.
따라서 “악용 증거 없음”은 범위가 있는 조사 결과입니다. 이는 의심스러운 활동을 발견하지 못한 신중한 검토를 반영할 수 있습니다. 그 검토에 관한 정보가 없다면 외부인은 그 완전성을 평가할 수 없습니다.
신중한 대응은 이 진술의 두 부분을 모두 보존하는 것입니다. Nvidia는 부적절한 사용의 증거를 발견하지 못했다고 밝혔습니다. 현재 이용 가능한 보도만으로는 고객 시스템이 영향을 받지 않았음을 독립적으로 입증하지 못합니다.
공개 세부 정보가 부족하다는 사실만으로 숨겨진 피해가 존재한다고 추론하는 것도 잘못입니다. 기업은 조사 중 기술적 공개를 제한해야 할 정당한 이유가 있을 수 있습니다. 그럼에도 고객은 자신의 위험과 관련된 정보를 얻을 적절한 경로가 필요합니다.
가상의 성공적인 로그인 사례는 이 구분이 왜 중요한지 보여줍니다. 침입자가 시스템에 접근했다면 이후의 활동은 별도 조사가 필요합니다. 원래 자격 증명을 교체한다고 해서 파일을 읽었는지 또는 다른 권한이 변경됐는지는 설명되지 않습니다.
이 시나리오는 이번 사건에 대한 설명이 아니라 위험 모델입니다. 여기서 검토한 검증된 증거는 Brev에서 이러한 일이 발생했음을 입증하지 않습니다. 가상의 결과와 관측된 활동을 분리하면 분석이 비난으로 변질되는 일을 막을 수 있습니다.
Nvidia Brev 침해 사건의 설명을 찾는 이들에게 핵심 해석 원칙은 다음과 같습니다. 차단 조치와 과거 활동에 대한 보증을 독립적으로 평가해야 합니다. 성공적인 교체에 대한 강력한 증거는 대응에 대한 신뢰를 뒷받침합니다. 이전 활동에 대한 강력한 증거는 노출 평가에 대한 신뢰를 뒷받침합니다.
어느 결론도 유용하기 위해 절대적일 필요는 없습니다. 그 한계가 명시된다면 고객은 범위가 정해진 조사 결과를 바탕으로 실질적인 결정을 내릴 수 있습니다. 근거 없는 안심과 뒷받침되지 않은 경보 모두 이러한 작업을 더 어렵게 만듭니다.
다른 AI 플랫폼 침해 사례는 맥락을 제공할 뿐, 원인을 특정하지는 않는다
Wiz가 10월 30일 공개한 AI platform breaches 분석은 10월 중 사고를 공개한 개발자 플랫폼이 최소 9곳이라고 파악했습니다. 언급된 서비스에는 Fireworks AI, Railway, Lightning AI, Warp가 포함됐습니다. 업데이트된 설명에는 보도된 Brev 사건도 언급됩니다.
이 연구는 더 넓은 그룹에서 보고된 침입 경로가 서로 달랐다고 설명합니다. 공격자들이 애플리케이션 비밀 정보를 담을 수 있는 구성 값인 저장된 자격 증명과 환경 변수에 관심을 보인다는 점을 강조합니다. Wiz는 공격들을 연결하는 단일 취약점이나 종속성은 없다고 밝혔습니다.
고객 자격 증명에 대한 공통된 관심이 공통 원인을 입증하는 것은 아닙니다. 더 넓은 패턴은 이러한 서비스를 면밀히 살펴봐야 하는 이유를 설명합니다. 하지만 Brev 관련 보도 뒤에 있는 공격자, 동기 또는 기술적 경로를 식별하지는 않습니다.
이 경계가 중요한 이유는 침해 사고 보도가 종종 별개의 사건들을 하나의 캠페인 서사로 압축하기 때문입니다. 비슷한 표적은 서로 무관한 공격자들의 관심을 끌 수 있습니다. 특정 침입을 연결하려는 주장은 발생 시점과 관련 정보의 일반적 범주를 넘어서는 증거를 필요로 합니다.
Fireworks AI 및 Railway와의 비교는 고객 의존성 측면에서 유용합니다. 이러한 서비스는 개발 워크플로에서 서로 다른 위치를 차지합니다. 그럼에도 고객은 각각의 서비스를 통해 다른 곳의 활동을 승인할 수 있는 정보를 처리하는 데 의존합니다.
SSH 키와 모델 서비스 자격 증명은 이러한 의존성의 서로 다른 형태를 보여줍니다. 전자는 원격 세션을 승인할 수 있습니다. 후자는 다른 서비스로의 요청을 승인할 수 있습니다. 어느 것도 서로 대체 가능한 것으로 설명해서는 안 됩니다.
기업 구매자에게는 사고를 보고한 공급업체 수를 단순히 세는 것보다 자격 증명 관리 방식이 더 유용한 비교 기준입니다. 관련 질문은 각 플랫폼이 무엇을 저장하는지, 그 항목들이 무엇을 승인하는지, 그리고 노출 이후 고객이 어떻게 증거를 받는지에 관한 것입니다.
Nvidia Brev 보안 침해는 보고된 자격 증명 범주가 시스템 접근 가능성을 가리킨다는 점에서 이 논의에 포함됩니다. 이 특수성은 유지돼야 합니다. 다른 회사의 사고에서 나온 결과를 가져오면 고객이 실제로 필요로 하는 사실이 흐려집니다.
자동화된 공격자에 관한 주장에도 같은 절제가 적용됩니다. 더 넓은 연구는 공격 기법의 발전을 설명할 수 있습니다. 하지만 이에 상응하는 증거 없이는 그러한 기법이 특정 사건을 일으켰다고 입증할 수 없습니다.
경쟁 구도 역시 독자가 인식해야 할 유인을 만듭니다. 인프라 공급업체는 자신의 접근 방식이 더 안전하거나 관리하기 쉽다는 인상을 줄 이익이 있습니다. 따라서 비교 주장은 경쟁사가 현재의 뉴스 헤드라인에 없다는 사실이 아니라 문서화된 아키텍처와 사고 조사 결과에 근거해야 합니다.
고객은 모든 호스팅 개발 서비스가 동일한 위험을 제시한다고 가정할 필요가 없습니다. 서로 다른 구성을 평가하는 공통된 방법이 필요합니다. 자격 증명 범위, 접근 기록, 검증된 권한 철회는 클라우드 보안에 대한 일반화된 진술보다 더 유용한 기준을 제공합니다.
업계 맥락은 이러한 기준의 필요성을 강화합니다. 그러나 Brev에 남아 있는 미해결 질문을 해결하지는 않습니다. 서비스 내에서 어떤 일이 일어났는지를 판단하는 데에는 Nvidia 자체 조사와 고객 커뮤니케이션이 여전히 관련된 출처입니다.
다음 공개 내용은 원인, 범위, 검증을 명확히 해야 한다
다음으로 가장 유용한 진전은 영향을 받은 고객의 불확실성을 줄이는 증거입니다. 앞으로 몇 달 동안은 특정 순서에 따라 세 가지 신호에 주목할 가치가 있습니다. 각각은 완료된 기술 대응과 충분히 설명된 사고를 구분하는 데 도움이 됩니다.
첫 번째 신호는 침입 지점과 영향을 받은 범위에 관한 실질적인 설명입니다. 기술 사고 검토는 서비스의 어느 부분에서 무단 활동이 발생했는지 설명해야 합니다. 또한 관련 자격 증명 범주와 고객 집단을 정의해야 합니다.
조사 결과로 뒷받침되는 일관된 경계를 제시한다면 신뢰가 강화될 것입니다. 범위가 더 넓다면 고객은 이전의 가정을 다시 검토해야 합니다. 모호함이 지속되면 팀은 개별 지원 문의에 의존할 수밖에 없습니다.
그 세부 정보에 공격자를 돕는 지침이 포함될 필요는 없습니다. 고객에게는 주로 영향을 받은 시스템과 책임을 이해할 수 있는 설명이 필요합니다. 플랫폼 접근, 자격 증명 노출, 고객 시스템 접근을 명확히 구분하면 공개 기록이 크게 개선될 것입니다.
두 번째 신호는 자격 증명 교체에 대한 검증입니다. 고객은 관련 환경이 업데이트를 받았고 이전 권한이 더 이상 접근을 허용하지 않는다는 보장이 필요합니다. 예외 사례를 어떻게 처리했는지 명시적으로 설명하면 이러한 보장이 더 유용해집니다.
완전한 교체의 증거는 차단 조치에 대한 신뢰를 뒷받침합니다. 미완료된 업데이트의 증거는 이를 약화시키며 후속 조치를 요구합니다. 새 키가 존재한다는 사실만 반복하는 보고서는 권한 문제를 충분히 설명하지 못합니다.
세 번째 신호는 과거 활동에 관한 더 명확한 조사 결과입니다. Nvidia는 어떤 기록이 평가의 근거가 됐는지, 고객이 추가 출처를 검토해야 하는지를 명확히 할 수 있습니다. 검증된 고객 시스템 악용이 있다면 사건 해석은 실질적으로 달라질 것입니다.
반대로 관련 기록으로 뒷받침된 범위가 명확한 조사 결과는 현재의 안심을 강화할 것입니다. 그 가치는 무엇을 검토했는지 설명하는 데서 나옵니다. 반복만으로는 현재 확보된 증거에 거의 보탬이 되지 않습니다.
이러한 신호는 구매자가 향후 플랫폼 변경을 평가할 실용적인 방법도 제공합니다. 새로운 통제 수단은 관련 장애 경계나 고객 가시성을 개선할 때 중요합니다. 그러한 연결이 없는 제품 발표는 사건의 핵심 질문을 해결하지 못합니다.
Nvidia Brev 보안 침해에 대한 다음 판단은 반응의 강도가 아니라 증거를 따라야 합니다. 잠재적 노출은 주의를 기울일 사안입니다. 확인된 악용은 다른 평가를 요구하며, 검증된 차단 조치는 그 자체로 인정받을 가치가 있습니다.
팀에서 Brev를 사용한다면 먼저 조직과 관련된 통지를 확보하고 그 범위에 속하는 환경을 파악하세요. 접근 검토의 책임자가 누구인지, 이를 뒷받침하는 기록이 무엇인지, 이전 권한의 종료를 무엇으로 확인하는지 물어보세요. 동료들이 각 결정의 이유를 이해할 수 있도록 확인된 결과와 예방 조치를 분리해 두세요. 공급업체의 커뮤니케이션을 자체 평가와 함께 보관하고, 새로운 증거가 나올 때 결론을 다시 검토하세요. 유용한 질문은 구체적입니다. 팀이 무엇이 노출됐고, 무엇이 변경됐으며, 자체 환경에서 무엇이 여전히 해결되지 않았는지 설명할 수 있습니까?
