모듈이나 플러그인, 테마를 만들 때는 원하는 기능부터 구현하게 된다.
대부분의 CMS나 프레임워크에는
훅, 이벤트, 플러그인, 디렉터리 구조, 권한, 데이터 접근 방식 같은 확장 규칙이 있다.
이 규칙을 사용하지 않아도 기능은 만들 수 있다.
라라벨 기반 CMS라면
CMS의 확장 규칙을 거치지 않고 Laravel의 기능을 직접 이용해 구현하는 것도 가능하다.

여러 확장을 만들고 업데이트하다 보면
직접 구현하려던 기능이 이미 플랫폼에 있거나,
코어를 수정하지 않았는데도
내부 구현에 의존한 부분이 변경의 영향을 받는 경우가 있었다.
문서에서 찾지 못한 기능을 공식 샘플이나 코어에서 발견하기도 했고,
코어에 있는 클래스나 메서드가 확장에서 사용하도록 공개된 것은 아닌 경우도 있었다.
G7 CMS에서도 비슷했다.
코어에 기본 기능으로 보이지 않더라도 훅이나 플러그인 같은 확장 구조를 통해 구현할 수 있는 기능이 있고,
이미 다른 확장에서 구현된 사례도 있다.
반대로 코어에 있는 기능이라고 해서 모두 확장에서 직접 사용해도 되는 것은 아니었다.

자연스럽게 코드를 만들기 전에 공식 문서와 샘플을 먼저 보게 됐다.
필요한 경우 코어까지 확인하되,
코어의 구현을 그대로 가져다 쓰기 위해서가 아니라
플랫폼이 어떤 기능과 확장 지점을 제공하는지 확인하기 위해 살펴본다.
기능의 존재 여부뿐 아니라 확장에서 사용하도록 공개된 것인지도 확인한다.
사용할 수 있는 훅, 액션, API 등이 있다면 그대로 사용하고 부족한 부분만 구현한다.

AI를 이용하면서 이런 과정은 더 중요해졌다.
AI는 Laravel 같은 기반 프레임워크를 이용해 필요한 기능을 빠르게 구현할 수 있으나,
해당 CMS가 이미 제공하는 확장 방식을 건너뛸 수도 있다.
그래서 AI에게도 바로 구현을 맡기기보다 플랫폼의 문서와 실제 구현을 먼저 확인하게 한다.
이미 제공되는 기능을 찾으면 새로 만들 필요가 없고, 없다면 그때 필요한 코드를 만든다.

처음에는 특정 CMS에서 겪은 문제였다.
여러 확장을 만들고 업데이트하면서 비슷한 상황을 반복해서 겪다 보니,
요즘은 새로운 기능이 필요하면 어떻게 만들지보다 먼저 어디까지 만들어져 있는지 살펴본다.

플랫폼의 확장 지점을 존중하는 것과 마찬가지로,
내가 만드는 확장도 어디까지를 기능으로 제공할 것인지 경계를 정할 필요가 있다고 생각한다.
내가 만든 확장이 각자의 환경에 맞게 수정되어 사용되는 것까지 모두 고려해 만들 필요는 없다고 본다.
확장 소스를 공개할 때도 최대한 범용으로 사용할 수 있는 부분까지만 구현한다.
특정 환경이나 개별 요구에 맞추기 시작하는 지점에서는 닫는다.

- 지형을 읽다가, 💫Glitter Gim