PHP 8.x 업데이트 이후 WordPress 플러그인 호환성 오류 해결 방법

PHP 8.x 업데이트 이후 WordPress 플러그인 호환성 오류 해결 방법은 오류를 시각적으로 드러내고, 백업을 수행하며, 플러그인을 하나씩 테스트하고, 호환되지 않는 플러그인을 업데이트하거나 대체하며, 필요시 PHP 버전을 일시적으로 이전 버전으로 되돌리는 단계로 구성됩니다. 흰 화면, 치명적 오류, 500 오류, fatal error, deprecated 경고 또는 관리 패널에 접근할 수 없는 문제의 경우, 가장 안전한 접근 방식은 라이브 사이트에 직접적으로 개입하기보다는 스테이징 환경에서 테스트를 수행하고, 오류 로그를 검토하며, 변경 사항을 통제된 방식으로 적용하는 것입니다.

PHP 8.x는 WordPress 사이트에 심각한 성능 및 보안 이점을 제공하지만, 오래된 코딩 표준으로 작성된 테마나 플러그인에서 호환성 문제를 드러내기도 합니다. 특히 PHP 7.4 및 이전 버전에서 단지 경고만 발생하던 코드가 PHP 8.x에서는 치명적인 오류로 변할 수 있습니다. 따라서 PHP 업그레이드는 단순한 버전 변경이 아니라 WordPress 생태계의 품질 관리 과정입니다.

이 가이드에서는 Hostragons 블로그 독자들을 위해 실제로 가장 자주 발생하는 시나리오에 따른 실용적인 해결 흐름을 준비했습니다. 목표는 단지 사이트를 다시 열게 하는 것이 아니라, 같은 오류가 다음 PHP, WordPress 또는 플러그인 업데이트에서 반복되지 않도록 지속 가능한 유지 관리 체계를 구축하는 것입니다. 적절한 WordPress 호스팅 인프라를 선택하고, PHP 버전을 관리하고, 정기적인 백업을 수행하는 것이 이 과정의 핵심입니다. 이 시점에서 워드프레스 호스팅 패키지와 웹 호스팅 서비스와 같은 리소스가 결정 과정에서 도움이 될 수 있습니다.

PHP 8.x 이후 WordPress 플러그인 호환성 문제는 왜 발생하나요?

PHP 8.0, 8.1, 8.2 및 8.3 버전은 타입 검사, 오류 처리 동작, 사용되지 않는 함수의 제거 및 성능 개선 측면에서 이전 버전보다 더 엄격합니다. WordPress 코어는 최신 PHP 버전과 호환되도록 지속적으로 개발되고 있지만, 모든 플러그인 및 테마가 같은 속도로 업데이트되지 않습니다. 문제는 일반적으로 WordPress 코어에서 발생하는 것이 아니라, 오랫동안 유지보수가 이루어지지 않거나 오래된 PHP 습관으로 작성된 서드파티 구성 요소에서 발생합니다.

예를 들어 PHP 7.4에서 작동하는 플러그인에서 잘못된 파라미터 순서는 단지 경고로 로그 파일에 기록되지만, PHP 8.1에서 같은 줄은 fatal error를 발생시킬 수 있습니다. 마찬가지로 이전 버전에서 허용되었던 null 값 사용이 PHP 8.x에서는 TypeError로 변할 수 있습니다. WooCommerce 결제 플러그인, 폼 플러그인, 페이지 빌더, 보안 플러그인 및 오래된 숏코드 플러그인들이 이 상황에서 가장 큰 영향을 받는 그룹입니다.

호환성 문제는 일반적으로 다음과 같은 이유로 발생합니다:

• 플러그인의 마지막 업데이트가 12개월을 초과하고 활성 유지보수가 이루어지지 않음.
• 플러그인의 PHP 8.x 호환성 정보가 WordPress 플러그인 페이지에 명시되지 않음.
• 테마와 플러그인이 동일한 기능을 다르게 사용함.
• 특별히 작성된 functions.php 코드가 오래된 PHP 구문을 포함함.
• 서버에서 활성화된 PHP 플러그인, 예를 들어 ionCube, mbstring 또는 imagick 모듈이 누락됨.
• 캐시, 방화벽 또는 최적화 플러그인이 오래된 설정과 충돌함.

증상에 따른 빠른 진단 표

아래 표는 PHP 8.x 업데이트 이후 발생하는 일반적인 WordPress 플러그인 오류를 빠르게 분류하는 데 도움이 됩니다. 이 표는 정확한 진단보다는 첫 번째 방향성을 제시하는 것을 목표로 하며, 최종 결정은 반드시 오류 로그를 검토해야 합니다.

해결에 들어가기 전 안전한 준비를 하세요

1. 전체 백업 받기

첫 번째 규칙은 간단합니다: 백업 없이 작업하지 마십시오. 파일, 데이터베이스, wp-content 폴더, uploads 디렉토리 및 .htaccess 파일을 포함한 전체 백업을 받아야 합니다. 특히 전자상거래 사이트에서는 주문, 재고 및 고객 데이터가 몇 분 내에 변할 수 있기 때문에 백업 시간을 기록하는 것이 중요합니다. 회원제 또는 WooCommerce 사이트를 관리하고 있다면 해결하는 동안 새로운 주문 수신을 임시 유지보수 모드로 전환하는 것이 데이터 무결성 측면에서 더 안전합니다.

좋은 호스팅 패널에서는 원클릭 백업, 예약 백업 및 복원 옵션이 제공되어야 합니다. 이러한 기능들은 치명적 오류가 발생했을 때 몇 시간을 절약해 줍니다. 백업 전략에 대해서는 웹사이트 백업 가이드와 안전한 호스팅 측면에서 Hostragons 호스팅 솔루션을 검토할 수 있습니다.

2. 라이브 사이트 대신 스테이징 환경 사용

PHP 8.x 호환성 테스트를 위한 가장 적합한 장소는 스테이징 환경입니다. 스테이징은 라이브 사이트의 복사본에서 위험 없이 실험할 수 있도록 해줍니다. 여기서 PHP 8.0, 8.1, 8.2 또는 8.3 버전을 테스트하고, 플러그인을 하나씩 업데이트하고, 결제, 폼, 회원 가입, 검색 및 관리 패널과 같은 중요한 기능을 점검할 수 있습니다. 라이브 사이트에서 직접 플러그인을 비활성화하면 방문객의 구매 또는 커뮤니케이션 과정에 지장을 줄 수 있습니다.

실용적인 테스트 계획을 수립하세요: 메인 페이지, 카테고리 페이지, 제품 또는 글 상세 페이지, 장바구니, 결제, 연락처 폼, 사용자 로그인 및 관리 패널 페이지를 각각 점검하세요. 트래픽이 많은 사이트에서는 이 테스트를 낮은 트래픽 시간대에 수행하여 가능한 중단의 영향을 줄이는 것이 좋습니다.

단계별 PHP 8.x WordPress 플러그인 오류 해결 방법

1. WordPress 디버그 모드 활성화

문제를 추측하여 해결하려고 하면 시간 낭비가 됩니다. 먼저 오류를 시각적으로 드러내세요. wp-config.php 파일에서 디버그 설정을 일시적으로 활성화할 수 있습니다. 라이브 사이트에서 오류를 화면에 표시하는 대신 로그 파일에 기록하는 것이 더 안전합니다. 논리는 다음과 같습니다: 방문자는 오류 메시지를 보지 않아야 하며, 당신은 오류가 어떤 파일 및 줄에서 발생했는지 알아야 합니다.

추천하는 접근 방식은 WP_DEBUG 값을 true로 설정하고, WP_DEBUG_LOG로 오류를 기록하며, WP_DEBUG_DISPLAY 값을 false로 유지하는 것입니다. 이렇게 하면 wp-content/debug.log 파일에서 관련 치명적 오류, 경고 또는 deprecated 메시지를 읽을 수 있습니다. 작업이 끝나면 디버그 모드를 끄는 것을 잊지 마세요; 왜냐하면 오랫동안 켜져 있는 로그 파일은 불필요한 디스크 사용 및 정보 유출 위험을 초래할 수 있기 때문입니다.

2. 오류 로그에서 플러그인 이름 찾기

로그 파일에서는 일반적으로 문제가 있는 플러그인의 폴더 이름이 명확하게 나타납니다. 예를 들어 오류 줄에서 wp-content/plugins/old-form-plugin/includes/class-handler.php와 같은 경로가 있다면, 첫 번째 의심자는 해당 플러그인입니다. Fatal error, Uncaught TypeError, Call to undefined function, Attempt to read property on null 및 Creation of dynamic property와 같은 표현은 PHP 8.x 전환에서 자주 발생합니다.

여러 오류가 있다면 가장 위의 첫 번째 fatal error 줄에 집중하세요. 아래 줄의 오류는 대부분 주 오류의 결과입니다. 오류 발생 시간을 확인하세요. PHP 업그레이드 직후 시작된 기록은 호환성 증거를 강화합니다.

3. 플러그인을 통제된 방식으로 비활성화

관리 패널에 접근할 수 있다면 플러그인 페이지에서 모든 플러그인을 비활성화한 후 하나씩 활성화하세요. 각 활성화 후 사이트와 관리 패널을 테스트하세요. 문제가 다시 발생하는 순간 마지막으로 활성화한 플러그인이 의심스러운 원인입니다.

관리 패널에 접근할 수 없다면 FTP 또는 파일 관리자에서 wp-content/plugins 폴더의 이름을 plugins-disabled로 변경하세요. 이 작업은 모든 플러그인을 비활성화합니다. 그런 다음 폴더 이름을 다시 plugins로 변경하고 플러그인 폴더들을 하나씩 다시 이름을 바꿔가며 테스트할 수 있습니다. 이 방법은 특히 흰 화면과 치명적 오류 상황에서 빠른 결과를 제공합니다.

4. WordPress, 테마 및 플러그인 버전 업데이트

호환성 문제의 대부분은 최신 버전으로 해결됩니다. 그러나 업데이트할 때는 순서가 중요합니다. 먼저 전체 백업을 받고, 그 다음 WordPress 코어, 활성 테마 및 플러그인을 업데이트하세요. 큰 버전 전환 시 한 번에 20개의 플러그인을 업데이트하기보다는 중요한 플러그인들을 그룹으로 나누는 것이 더 안전합니다. 예를 들어 먼저 보안 및 SEO 플러그인, 그 다음 폼 및 캐시 플러그인, 마지막으로 결제 및 회원 플러그인을 업데이트할 수 있습니다.

플러그인 페이지에서 마지막 업데이트 날짜, 활성 설치 수, 지원 포럼 응답 및 테스트된 WordPress 버전을 검토해야 합니다. 마지막 업데이트가 2년 이상 된 플러그인, 지원 요청에 응답하지 않는 플러그인 및 PHP 8.x 호환성이 명시되지 않은 플러그인은 장기적으로 위험합니다.

5. 호환되지 않는 플러그인에 대한 대안 찾기

어떤 플러그인은 더 이상 유지보수가 되지 않을 수 있습니다. 이 경우 오류를 임시 패치로 눌러버리는 것보다 현대적이고 활성 개발되는 대안으로 전환하는 것이 더 건강합니다. 예를 들어 오래된 연락처 폼 플러그인이 PHP 8.2에서 TypeError를 발생시킨다면, 최신 폼 플러그인으로 전환하는 것이 보안과 사용성 측면에서 더 나은 결과를 가져올 것입니다.

대안을 선택할 때 단순히 별점만 보지 마세요. 다음 기준을 사용하세요: 정기적인 업데이트 빈도, PHP 8.x 지원, WordPress 최신 버전 호환성, 개발자 문서, 데이터 이전 용이성, 성능 영향 및 지원 품질. 특히 결제, 예약 및 회원과 같은 수익을 창출하는 기능에서는 무료 플러그인보다는 전문적인 지원을 제공하는 솔루션을 선택하는 것이 좋습니다.

6. PHP 버전을 일시적으로 다운그레이드

라이브 사이트가 완전히 종료되었고 빠른 복구가 필요한 경우, PHP 버전을 일시적으로 이전 안정 버전으로 내리는 것이 합리적일 수 있습니다. 그러나 이는 영구적인 해결책이 아닙니다. 예를 들어 PHP 8.2 이후 사이트가 열리지 않는 경우, 이전에 PHP 8.0 또는 7.4에서 작동했던 경우 호스팅 패널에서 버전을 일시적으로 낮춰 방문자 중단을 줄일 수 있습니다. 이후 스테이징 환경에서 실제 호환성 작업을 수행해야 합니다.

여기서 주의해야 할 점은 보안입니다. 지원 기간이 만료된 PHP 버전에서 오랫동안 머물면 사이트가 보안 취약점에 노출될 수 있습니다. 따라서 다운그레이드는 긴급 상황에서의 응급 조치이며, 유지 관리 계획의 대체물이 아닙니다.

7. 서버 PHP 설정 확인

일부 오류는 플러그인에서 직접 발생하는 것이 아니라 서버 구성에서 발생합니다. memory_limit, max_execution_time, upload_max_filesize, post_max_size 및 max_input_vars 값은 특히 WooCommerce, 페이지 빌더 및 다국어 사이트에서 중요합니다. 예를 들어 대형 페이지 빌더로 편집된 페이지에서 max_input_vars가 낮으면 등록 작업이 실패할 수 있습니다. 많은 제품 변형을 가진 WooCommerce 사이트에서는 메모리 한도가 부족할 경우 500 오류가 발생할 수 있습니다.

일반 시작 값으로는 memory_limit에 대해 256M, max_execution_time에 대해 120초, max_input_vars에 대해 3000 이상이 많은 WordPress 사이트에서 더 건강할 수 있습니다. 그러나 각 사이트는 다릅니다; 불필요하게 높은 값보다는 실제 필요를 분석해야 합니다. 서버 측 지원이 필요할 때 워드프레스 호환 호스팅 및 기술 지원 호스팅 서비스 옵션이 과정을 쉽게 할 수 있습니다.

자주 발생하는 PHP 8.x 오류 및 실용적인 해결책

Fatal Error: Uncaught TypeError

이 오류는 일반적으로 함수에 예상된 유형의 데이터를 전송하지 않을 때 발생합니다. 예를 들어 플러그인이 숫자를 기대할 때 null 값을 받으면 PHP 8.x에서 더 엄격하게 처리하여 프로세스를 중단할 수 있습니다. 해결책은 플러그인을 업데이트하거나 개발자가 배포한 패치를 적용하는 것입니다. 특별한 코드에서는 변수가 사용되기 전에 비어 있는지 확인해야 합니다.

Call to Undefined Function

이 오류는 사용 중인 함수가 현재 PHP 버전, WordPress 코어 또는 필요한 PHP 모듈에 존재하지 않음을 나타냅니다. 플러그인이 오래된 함수에 의존하고 있거나 서버에서 필요한 모듈이 활성화되지 않을 수 있습니다. 먼저 플러그인 문서의 시스템 요구 사항을 확인하고, 그 다음 호스팅 패널에서 PHP 확장자를 검사하세요.

Deprecated 및 Warning 메시지

Deprecated 메시지는 대부분 사이트의 작동을 중단시키지 않지만, 미래에 fatal error가 발생할 수 있음을 암시합니다. 라이브 사이트에서 이러한 경고는 방문자에게 표시되지 않아야 합니다. 경고를 로그 파일에 기록하고, 관련 플러그인을 업데이트하거나 개발자에게 보고하거나 대안을 계획하는 것이 올바른 접근입니다.

Allowed Memory Size Exhausted

이 오류는 메모리 한도를 초과했음을 나타냅니다. memory_limit를 단기적으로 늘리는 것이 해결책이 될 수 있지만, 근본적인 원인은 최적화되지 않은 플러그인, 무거운 쿼리 또는 비대해진 데이터베이스일 수 있습니다. WooCommerce 보고서, 백업 플러그인 및 이미지 최적화 도구들이 이 오류를 유발할 수 있습니다. 메모리 한도를 늘린 후 플러그인 소비를 모니터링해야 합니다.

호스팅 측에서 확인해야 할 사항

PHP 8.x 전환이 원활하게 이루어지려면 호스팅 인프라가 최신 상태이고 유연하며 추적 가능해야 합니다. 호스팅 패널에서는 PHP 버전 선택, 확장 관리, 오류 로그 접근, 백업 복원, SSL 관리 및 자원 사용 모니터링이 가능해야 합니다. SSL 측의 오류는 PHP 호환성 문제와 직접적인 관계가 없더라도 업데이트 이후 리디렉션 및 안전한 연결 문제와 함께 발생할 수 있습니다. 이와 관련하여 SSL 인증서 솔루션 및 무료 SSL 설치 가이드가 유용할 수 있습니다.

또한 도메인 DNS 리디렉션, CDN 사용 및 캐시 레이어도 테스트 결과에 영향을 미칠 수 있습니다. 예를 들어 플러그인을 수정했다고 생각하는 동안 CDN이 이전의 잘못된 페이지를 계속 표시할 수 있습니다. 따라서 서버 캐시, 플러그인 캐시, 브라우저 캐시 및 CDN 캐시가 있는 경우 별도로 모두 지워야 합니다. 새로운 사이트 이전이나 도메인 구성 작업을 하고 있다면 도메인 조회 및 등록 및 DNS 관리 가이드 링크가 자연스러운 시작점이 될 수 있습니다.

지속적인 예방 조치: 업데이트 전 호환성 루틴

PHP 8.x 호환성 문제를 한 번만 해결하는 것으로는 충분하지 않습니다. WordPress 생태계는 지속적으로 변화하기 때문에 정기적인 유지 관리 루틴을 수립해야 합니다. 전문 사이트에서는 최소한 한 달에 한 번 플러그인 및 테마 업데이트를 점검하고, 3개월마다 스테이징에서 PHP 호환성 테스트를 수행하며, 중요한 업데이트는 계획적으로 라이브로 전환해야 합니다.

간단하지만 효과적인 점검 목록은 다음과 같습니다:

• 모든 업데이트 전 파일 및 데이터베이스 백업을 받으세요.
• 플러그인 변경 로그에서 PHP 8.x 노트를 읽으세요.
• 유지보수가 이루어지지 않는 플러그인을 최소한 연 1회 대체 플러그인과 비교하세요.
• 보안, 결제 및 폼 플러그인을 우선적으로 테스트하세요.
• 스테이징 환경에서 주요 사용자 경로를 수동으로 테스트하세요.
• 업데이트 직후 및 24시간 후 오류 로그를 다시 확인하세요.
• 불필요한 플러그인을 삭제하세요; 단순히 비활성화하는 것만으로는 충분하지 않습니다.

이 루틴의 가장 큰 장점은 위기를 조기에 발견할 수 있다는 점입니다. 예를 들어 플러그인이 PHP 8.3에서 경고를 발생시키기 시작한 것을 스테이징 환경에서 발견하면 라이브 사이트에서 판매 손실 없이 해결책을 계획할 수 있습니다. 특히 기업 웹사이트, 전자상거래 프로젝트 및 트래픽이 많은 블로그를 위해 이 접근 방식은 기술적인 사치가 아니라 운영상의 필수입니다.

예시 시나리오: 흰 화면에서 작동하는 사이트로

현실적인 예를 통해 진행해 보겠습니다. 한 WordPress 사이트에서 PHP 7.4 버전에서 PHP 8.2 버전으로 전환되었다고 가정해 보겠습니다. 업데이트 이후 메인 페이지가 흰 화면을 표시하고, 관리 패널은 치명적 오류 메시지를 보여줍니다. 먼저 호스팅 패널에서 파일 및 데이터베이스 백업을 수행합니다. 그런 다음 wp-config.php에서 디버그 로그를 활성화합니다. debug.log 파일에서 오류가 wp-content/plugins/old-slider 플러그인에서 발생했음을 확인합니다.

관리 패널에 접근할 수 없기 때문에 FTP를 통해 old-slider 폴더의 이름을 old-slider-disabled로 변경합니다. 사이트가 다시 열립니다. 그런 다음 플러그인의 마지막 업데이트가 3년 전에 이루어졌음을 발견합니다. 스테이징 환경에서 최신 슬라이더 플러그인을 설치하고, 오래된 슬라이드 이미지를 옮기고, 페이지 디자인을 테스트합니다. 캐시를 지우고, 모바일 뷰를 확인한 후 변경 사항을 라이브로 전환합니다. 마지막 단계에서 PHP 8.2를 보존하고 오래된 플러그인은 완전히 삭제합니다. 이 시나리오에서 영구적인 해결책은 PHP 버전을 낮추는 것이 아니라, 유지보수가 이루어지지 않는 플러그인을 교체하는 것입니다.

언제 전문가의 지원을 받아야 하나요?

일부 경우에는 스스로 개입하는 것이 위험을 증가시킬 수 있습니다. 특히 결제 인프라, 맞춤형 소프트웨어 통합, 회원 시스템, 다국어 구조, 높은 트래픽의 뉴스 사이트 또는 기업 포털을 사용하고 있다면 무작위로 플러그인을 비활성화하여 문제를 해결하려고 하면 데이터 손실과 수익 손실을 초래할 수 있습니다. 오류 로그에서 특별한 테마 파일, API 통합 또는 데이터베이스 쿼리가 보인다면 전문가의 도움을 받는 것이 더 안전합니다.

전문가 지원을 요청할 때 기술 팀에 다음 정보를 전달하면 해결 시간을 단축할 수 있습니다: 사용 중인 PHP 버전, WordPress 버전, 활성 테마 이름, 문제 발생 전 수행한 작업, 오류 화면 스크린샷, debug.log 내용, 마지막으로 받은 백업 시간 및 중요한 플러그인 목록. 이 정보가 없으면 분석은 일반적으로 시행착오로 전환됩니다.

자주 묻는 질문

PHP 8.x 업데이트 이후 WordPress가 왜 치명적 오류를 발생하나요?

대부분 오래되었거나 유지보수가 이루어지지 않은 플러그인이 PHP 8.x 규칙을 준수하지 않기 때문에 치명적 오류가 발생합니다. PHP 8.x는 잘못된 타입 사용 및 제거된 함수에 대해 더 엄격합니다. 오류 로그에서 관련 플러그인 폴더를 찾아 문제를 명확히 할 수 있습니다.

PHP 버전을 낮추는 것이 문제를 완전히 해결하나요?

PHP 버전을 낮추면 사이트가 일시적으로 열릴 수 있지만, 이는 영구적인 해결책이 아닙니다. 오래된 PHP 버전은 보안 위험을 초래할 수 있습니다. 올바른 접근 방법은 호환되지 않는 플러그인을 업데이트하거나 교체하거나 코드를 PHP 8.x에 맞게 조정하는 것입니다.

어떤 플러그인이 문제를 일으키는지 어떻게 알 수 있나요?

디버그 로그 파일에서 오류가 발생한 파일 경로를 확인하세요. 경로는 일반적으로 wp-content/plugins 아래의 플러그인 폴더를 나타냅니다. 관리 패널에 접근할 수 있다면 플러그인을 하나씩 활성화하여 테스트하거나, 접근할 수 없다면 FTP를 통해 폴더 이름을 변경하여 테스트할 수 있습니다.

PHP 8.2 또는 8.3이 WordPress에 안전한가요?

최신 WordPress 코어와 활성 유지보수가 이루어지는 플러그인과 함께 PHP 8.2 및 8.3은 일반적으로 안전하고 성능이 좋습니다. 위험은 오래된 테마와 플러그인에서 발생합니다. 따라서 라이브로 전환하기 전에 스테이징 환경에서 호환성 테스트를 수행해야 합니다.

이러한 오류를 피하기 위해 어떤 호스팅을 선택해야 하나요?

PHP 버전 선택, 자동 백업, 스테이징, 오류 로그 접근, SSL 관리 및 신속한 기술 지원을 제공하는 호스팅을 선택해야 합니다. WordPress 프로젝트를 위해 최적화된 자원과 간편한 복구 옵션은 위기 상황에서 큰 장점을 제공합니다.

간단 요약 및 다음 단계

PHP 8.x 업데이트 이후 WordPress 플러그인 호환성 문제를 해결하는 가장 안전한 방법은 백업을 받고, 스테이징 환경에서 테스트하며, 디버그 로그를 읽고, 문제 있는 플러그인을 격리하고, 영구적으로 최신 솔루션으로 교체하는 것입니다. PHP 버전을 되돌리는 것은 오직 긴급 상황에서의 임시 방편에 불과합니다. 장기적으로 정기적인 유지 관리, 최신 플러그인 및 강력한 호스팅 인프라가 사이트를 더 안전하고 빠르게 유지합니다.

WordPress 사이트에서 PHP 버전 관리, 백업, SSL 또는 호스팅 측에서 더 제어된 구조를 구축하고 싶다면 Hostragons 리소스를 검토할 수 있으며, 필요에 맞는 솔루션을 차분하게 선택할 수 있습니다. Hostragons 워드프레스 호스팅 및 SSL 인증서 페이지가 좋은 시작점이 될 수 있습니다.