왜 개발자들은 커머스 플랫폼과 싸우게 되는가

Source: Dev.to

대부분의 개발자가 “이 커머스 플랫폼이 내 가장 큰 적이 될 것이다”라는 생각으로 전자상거래 솔루션을 개발하기 시작하는 경우는 드뭅니다. 하지만 결국 그들은 대부분의 시간을 플랫폼을 우회하는 데 쓰고 있다는 것이 명확해집니다. 이는 보통 도구 때문이거나 전문 지식이 부족해서가 아닙니다.

Opinionated frameworks versus reality

대부분의 전자상거래 프레임워크는 상점이 어떻게 구조화되어야 하는지에 대한 선입견에 의존합니다. 제품을 설계하는 방식, 결제 흐름이 작동하는 방식, 사용할 수 있는 플러그인 등을 강제합니다. 이는 제품이 프레임워크의 가정에 부합하는 한 잘 작동합니다.

요구사항이 그 가정과—조금이라도—다르게 되면 흔히 다음과 같은 문제가 나타납니다:

• 비즈니스 로직이 템플릿과 플러그인에 섞여 들어감.
• 결제 흐름을 확장하기 어려워짐.
• 데이터 구조가 도메인 모델과 맞지 않게 됨.
• 제약이 나타나는 시점이 바로 커스터마이징이 필요할 때임.

When abstraction becomes an issue

커머스 플랫폼은 개발을 단순화하려고 하지만, 숨겨진 제한, 문서화되지 않은 요구사항, 업그레이드 시 고통스러운 커스터마이징을 초래할 수 있습니다. 시간이 지나면서 개발자는 어떻게 기능을 구현할지 묻는 대신 플랫폼이 이를 허용하는지를 묻게 됩니다.

플랫폼의 기능성, 안정성, 지원 가능성에 대한 질문이 대화를 지배하고, 이는 종종 되돌릴 수 없는 지점으로 이어집니다.

First comes infrastructure, second comes storefront

점점 더 많은 사람들은 커머스를 “사이트 빌더”가 아니라 인프라스트럭처로 바라보기 시작했습니다. 플랫폼은 제품 자체에 간섭하지 않고 커머스와 관련된 프로세스를 처리해야 합니다.

이러한 관점은 기존 환경에 원활히 통합되는 커머스 레이어의 부상을 촉진합니다. 예를 들어 현대적인 커머스 레이어인 Unstore는 커머스를 스토어프론트가 아니라 인프라스트럭처로 위치시킵니다.

The real problem

문제는 개발자들이 추상화를 본능적으로 싫어한다는 것이 아니라, 플랫폼이 비즈니스 로직의 자연스러운 흐름을 허용하기보다 회사가 어떻게 운영되어야 하는지를 강제하기 시작할 때 발생합니다.

최고의 커머스 플랫폼은 눈에 보이지 않을 정도로 투명하게 작동하여, 개발자가 플랫폼 제약에 신경 쓰지 않고 제품 개발에 집중할 수 있게 합니다.