PrestaShop의 글로벌 설정 테이블(global configuration table)로 인해 모듈의 삭제(uninstall) 루틴이 전혀 관련 없는 다른 확장 기능의 설정을 삭제하기 쉬운 구조가 되었습니다. Configuration::deleteByName('width') 호출 한 번으로 다른 샵의 사용자 정의 너비(width) 값을 지워버릴 수 있으며, 이로 인해 상점 운영자는 혼란에 빠지고 원인이 된 모듈은 아무런 해가 없는 것처럼 보일 수 있습니다.
공유 설정 테이블이 중요한 이유
PrestaShop은 모든 모듈의 설정을 키(key)와 값(value)만 저장하는 하나의 테이블에 보관합니다. 이 테이블에는 어떤 모듈이 행(row)을 생성했는지 기록하는 컬럼이 없으며, 어떠한 명명 규칙(naming convention)도 강제하지 않습니다. 그 결과, 우연히 같은 키(예: “width” 또는 “API_DATE_FROM”)를 사용하는 두 모듈은 동일한 데이터베이스 행을 읽고 쓰게 됩니다. 마지막에 작성된 값이 적용되며, 이후에 발생하는 삭제 작업은 양쪽 모두의 행을 제거합니다.
삭제 코드가 데이터 삭제 도구로 변질될 때
일반적인 삭제(uninstall) 메서드는 다음과 같습니다:
public function uninstall()
{
return Configuration::deleteByName('width');
}
의도는 모듈 자체의 설정을 정리하는 것이지만, 키에 네임스페이스(namespace)가 지정되어 있지 않기 때문에 해당 문구는 “width”라는 이름의 모든 행을 삭제합니다. 경고 로그도 남지 않고 예외(exception)도 발생하지 않으며, 행은 그냥 사라집니다. 상점의 다른 모듈은 조용히 설정을 잃게 되고 비정상적으로 작동하기 시작할 수 있습니다.
이 문제는 버전 업그레이드 시 특히 발생하기 쉽습니다. 버전 1.0에서 2.0으로 전환하는 개발자는 MY_MODULE_WIDTH와 같이 접두사가 붙은 키 아래에 값을 저장하기 시작할 수 있습니다. 기존의 접두사가 없는 항목들을 “정리”하기 위해, 개발자는 레거시 데이터만 삭제한다고 믿고 삭제 호출을 삭제 루틴에 추가합니다. 하지만 실제로는 동일한 일반 키 아래에 저장된 다른 확장 기능의 데이터까지 모두 삭제하게 됩니다.
감사(audit)를 통해 밝혀진 사실
57개의 공개 모듈 저장소를 대상으로 실시한 감사 결과, 다음과 같은 반복적인 패턴이 발견되었습니다:
- 많은 모듈이 모듈 이름에서 유도된 접두사 없이 “width”, “height” 또는 “API_DATE_FROM”과 같은 일반적인 키를 사용합니다.
- 여러 삭제 메서드에 이러한 일반 키를 대상으로 하는
Configuration::deleteByName호출이 포함되어 있습니다. - 이 문제는 특정 개발자나 특정 유형의 모듈에 국한된 것이 아니라, 공유 테이블 설계로 인한 시스템적 위험입니다.
감사 결과, 다른 모듈의 설정이 삭제되었음을 상점 소유자에게 알리는 로그나 에러 메시지는 발견되지 않았습니다. 유일한 증상은 설정이 갑자기 사라지는 것이며, 상점 운영자는 이를 캐시 문제나 자신의 코드에 있는 버그로 오해할 수 있습니다.
모듈 개발자를 위한 더 안전한 관행
- 모든 키에 네임스페이스 적용 – 모든 설정 키 앞에 모듈의 기술적 이름을 접두사로 붙입니다 (예:
my_module_width). 이를 통해 별도의 소유권 컬럼에 의존하지 않고도 고유한 식별자를 생성할 수 있습니다. - 접두사가 없는 오래된 키 삭제 지양 – 테이블에 몇 개의 쓸모없어진 행을 남겨두는 것은 저장 공간 측면에서 비용이 거의 들지 않으며, 부수적인 피해의 위험을 제거합니다.
- 삭제 전 소유권 확인 – 삭제가 정말로 필요한 경우, 먼저 해당 키의 값이 자신의 코드에 의해 설정되었는지 확인합니다 (예: 모듈만 알고 있는 마커 값을 저장).
- 삭제 메서드 감사 – 코드베이스에서
deleteByName호출을 검색합니다. 각 호출이 고유한 네임스페이스를 사용하는 키를 대상으로 하는지 확인해야 합니다. - 명명 규칙 문서화 – 모듈의 README에 짧은 가이드라인을 포함하여 향후 기여자들이 접두사 키의 중요성을 이해할 수 있도록 합니다.
의도치 않은 모듈 간 삭제 테스트 방법
실제 운영 중인 샵에 적용되기 전에 버그를 잡는 실질적인 방법은 다음과 같습니다:
- **설정 테이블에 데이터를 미리 삽입(seed)**합니다. 이때 다른 모듈에 속한 키(예:
other_module_setting=>test)를 사용합니다. - 제어된 환경에서 모듈의 삭제 루틴을 실행합니다.
- 삭제가 완료된 후에도 삽입했던 키가 여전히 존재하는지 확인(assert)합니다.
모듈의 유닛 테스트(unit-test) 스위트에 이 확인 과정을 자동화하면, 향후 잘못된 deleteByName 호출이 포함된 변경 사항이 발생했을 때 테스트가 실패하게 되어 즉시 검토를 유도할 수 있습니다.
상점 운영자가 주의 깊게 살펴봐야 할 사항
상점 운영자는 내부 데이터베이스 행을 직접 보는 경우는 드물지만, 증상은 포착할 수 있습니다. 모듈을 비활성화하거나 삭제한 후, 다른 확장 기능이 갑자기 기본 설정으로 돌아가는 경우입니다. 이런 일이 발생하면 개발자에게 모듈의 삭제 코드가 글로벌 설정 테이블을 준수하는지 확인해 달라고 요청하십시오. 모듈이 사용하는 모든 설정 키 목록을 요청하고, 명확한 접두사가 없는 키가 있다면 주의 신호(red flag)로 간주하십시오.
핵심 정리
PrestaShop의 설계 방식은 설정 테이블을 공유 리소스로 만들기 때문에, 부주의한 삭제 루틴은 다른 모듈의 설정을 흔적도 없이 지워버릴 수 있습니다. 키에 네임스페이스를 지정하고, 과도한 정리 작업을 지양하며, 외부 항목을 보호하는 간단한 테스트를 추가함으로써 개발자는 소리 없는 데이터 손실을 방지하고 상점의 안정성을 유지할 수 있습니다. 이에 필요한 노력은 미미하지만, 설정 손실로 인해 발생하는 비용—고객 불만, 지원 요청, 평판 저하 등—은 훨씬 더 클 수 있습니다.