워드프레스 — 넘겨받은 사이트, 회사가 직접 관리할 수 있는 범위 (2026)

워드프레스 사이트를 넘겨받으면 무엇을 '관리'한다고 보나?

워드프레스로 만든 사이트는 소스가 열려 있어도 회사가 직접 다룰 수 있는 범위는 플랫폼이 아니라 사이트를 이루는 구성이 정한다. 관리 대상은 코어·테마·플러그인·커스텀 코드·DB까지 한 묶음이고, 어떤 부분을 회사가 직접 고칠 수 있는지는 그 구성이 어떻게 얽혀 있는지에 달렸다.

넘겨받는 시점에 사이트는 '워드프레스' 하나가 아니라 워드프레스 코어와 테마, 플러그인, 테마에 들어간 커스텀 코드, DB에 쌓인 콘텐츠가 합쳐진 묶음이다. 이 중 어디까지를 회사가 직접 손대도 되는지가 직접 관리 범위다.

페이지 빌더로 만든 페이지는 브라우저에서 보면 일반 문서처럼 보이지만, 실제로는 DB에 구조화된 데이터로 저장된다. 글처럼 보인다는 것과 글처럼 고칠 수 있다는 것은 서로 다를 수 있다.

계정과 라이선스가 어디에 묶여 있는지가 범위를 가르나?

도메인·호스팅·DB·관리자 계정이 어떤 명의와 이메일에 묶여 있는지가 직접 관리의 출발점이다. 관리자 계정이 있어도 상용 테마·플러그인 라이선스가 제작사 계정에 묶여 있으면 갱신과 업데이트를 회사가 직접 하기 어렵다.

인수 시 확인해야 할 자산은 크게 네 가지로 갈린다. 도메인과 호스팅 명의, DB 접근 권한, 워드프레스 관리자 계정, 그리고 유료 테마·플러그인의 라이선스 명의다. 이 중 라이선스가 제작사 개인 계정에 묶여 있으면 해당 테마를 회사가 직접 업데이트할 수 없다.

관리자 계정 비밀번호만 받았다고 해서 관리 범위가 확보된 것은 아니다. 복구가 필요한 순간에 호스팅과 DB 접근이 회사 명의로 되어 있어야 백업·복구까지 이어진다.

커스텀 코드와 문서화가 없는 자리에서 직접 관리는 끝나나?

테마 함수에 들어간 커스텀 코드, 플러그인 설정, DB 구조까지 문서화되어 있지 않으면 직접 관리는 글·이미지 수정에 그친다. 오픈소스라는 점은 코드를 열 수 있다는 뜻이지, 회사가 그 코드를 이해하고 고칠 수 있다는 뜻은 아니다.

업데이트가 가장 흔히 부딪히는 지점이다. 워드프레스 코어나 플러그인 업데이트는 커스텀 코드와 충돌할 수 있어서, 별도로 문서화된 수정 내역이 없으면 업데이트를 눌렀다가 화면이 깨져도 원인을 회사가 직접 찾기 어렵다.

HTML·CSS 지식으로 되는 영역과 PHP·서버·DB 지식이 필요한 영역은 다르다. 직접 관리 범위를 정할 때는 인력의 현재 역량이 아니라 넘겨받은 문서가 어디까지 덮고 있는지로 경계를 정하는 편이 안전하다.

넘겨받을 때 무엇을 확보하면 직접 관리 범위가 정해지나?

인수받는 시점에 계정 명의와 운영 문서를 확정하면 직접 관리 범위가 정해진다. 관리 범위는 플랫폼 이름이 아니라 넘겨받는 자산의 종류로 결정된다.

인수 체크리스트를 계약서가 아니라 운영 문서로 남긴다. 관리자 계정과 도메인·호스팅 명의, 유료 테마·플러그인의 라이선스, 커스텀 코드가 들어간 위치, 백업 주기와 복구 절차를 각각 어느 주체가 책임지는지 적는다.

직접 관리할 수 있는 부분과 전문 운영이 필요한 부분을 처음부터 나눠 두면, 나중에 업데이트나 복구가 필요할 때마다 누가 할 일인지를 다시 정하지 않아도 된다.

범위가 정해져 있지 않으면 운영·유지보수 책임이 나중에 다시 갈리므로, 인수 시점에 문서로 남겨 두는 편이 안전하다.