영국 비즈니스

Drupal Commerce는 대부분의 온라인 쇼핑몰에게 잘못된 답입니다. 이는 십오 년 동안 탄탄하게 설계되어 온 프로젝트에 대한 비판이 아닙니다. 대부분의 쇼핑몰이 어떤 모습인지에 대한 진술일 뿐입니다. 수백 개의 SKU, 하나의 통화, 소비자 고객, 그리고 마지막에 카드 결제 한 번. 이런 형태의 사업이라면 중요한 모든 축에서 호스팅형 플랫폼이 이기고, 논쟁은 시작되기도 전에 끝납니다. 그런데 계산이 완전히 뒤집히는 소수가 존재하며, 그것은 수익성이 높은 소수입니다. 변형 표로는 표현할 수 없는 구성형 제품. 협상된 가격표를 가진 거래처 계정. 카탈로그 자체가 ...

Drupal 12는 2026년 12월 7일이 있는 주에 나올 예정이고, Drupal 10은 2026년 12월 9일에 지원이 끝납니다. 두 날짜는 Drupal 코어 릴리스 일정 같은 페이지에 두 줄 간격으로 나란히 적혀 있지만, Drupal 10 사이트를 운영하는 사람 대부분은 둘 다 알아차리지 못했습니다. 새 메이저의 첫 알파는 2026년 9월 2일에 태그되었으니, 이번 릴리스의 모양은 이제 추측이 아니라 기록의 문제입니다. 이 충돌이 이야기의 전부입니다. 메이저 버전이 나오는 일 자체는 보통 사이트 소유자에게 급하지 않습니다....

“Drupal은 느리다”는 평판의 출처는 대부분 호스팅이며, 그것은 거의 언제나 소프트웨어의 문제가 아니라 구매 결정의 문제입니다. 사이트는 제대로 만들어지고, 그다음 PHP 파일 몇 개짜리 소개용 사이트를 기준으로 가격이 매겨진 요금제 위에서 오픈합니다. 그 결과 진지한 렌더 파이프라인을 가진 콘텐츠 관리 시스템이, 스스로 바꿀 수 없는 메모리 한도 안에서, 스스로 통제할 수 없는 오피코드 캐시 위에서, 자기 도구를 돌릴 셸도 없이 돌아가게 됩니다. 사람들이 머릿속에서 비교 대상으로 삼는 것은 WordPress이고, 그 비교가 틀렸습니다. WordPress가 거의 ...

개발자 온보딩은 보통 입사 교육이 며칠 걸렸는지로 측정되는데, 그것은 문제의 잘못된 쪽 끝을 보는 일입니다. 정작 중요한 숫자는 따로 있습니다. 새로 온 엔지니어가 무언가를 고치면서 다른 것을 망가뜨리지 않았다고 확신하기까지 얼마나 걸리는가입니다. 대부분의 팀에서 이 값은 며칠이 아니라 몇 달 단위로 측정됩니다. 지연의 원인이 사람인 경우는 드뭅니다. 원인은 시스템의 얼마나 많은 부분이 다른 사람들의 머릿속에만 존재하는지, 그리고 첫 두 주의 얼마나 많은 시간이 그것을 한 번에 하나씩 질문으로 꺼내오는 데 쓰이는지에 있습니다. 추적할 가치가 있는 단 하나의 지표는, ...

가동률 SLA는 약속처럼 보이지만 환불 규정처럼 작동합니다. 공급자는 이 점을 잘 알고 있습니다. 고객은 그렇지 못한 경우가 많아서, 가용성을 샀다고 믿으며 서비스 수준 협약에 서명합니다. 그러나 실제로 산 것은 가용성이 아니라, 그것을 받지 못했을 때 돌려받는 작은 할인입니다. 그것이 반드시 나쁜 거래라는 뜻은 아닙니다. 다만 대부분의 사람이 맺고 있다고 생각하는 거래와는 다른 거래이고, 그 차이는 시스템이 멈추고 누군가 계약서에 뭐라고 적혀 있는지 묻는 순간에 드러납니다. 쓰리 나인은 거의 완벽하게 들리지만 한 달에 43분의 다운타임을 허용합니다. 포 나인은 4분...

소프트웨어 임치는 소스코드를 중립적인 제3의 기관에 맡겨 두는 제도이며, 충분히 합리적인 두려움에 답하기 위해 존재합니다. 핵심 시스템을 만들고 운영해 온 공급업체가 사라지고, 여러분에게는 의존하고 있지만 스스로 유지보수할 수 없는 무언가만 남는 상황 말입니다. 임치 계약은 소스코드를 그 기관에 보관해 두었다가, 그런 일이 실제로 벌어지면 여러분에게 인도하도록 정해 둡니다. 두려움 자체는 정당합니다. 문제는 이 제도가 자주 오해된다는 점이고, 그 간극에서 매년 돈은 나가지만 정작 필요한 날에는 아무 도움이 되지 않는 계약이 생겨납니다....

고정가 계약과 투입 정산 계약 가운데 무엇을 고를 것인가 하는 문제는 대개 리스크에 관한 선택으로 설명됩니다. 그 설명 자체는 옳지만, 바로 다음 단계에서 잘못 다뤄집니다. 발주사와 수행사 모두 리스크가 자리를 옮길 뿐이라는 사실을 잊고, 어느 한쪽을 고르면 리스크가 사라진다고 가정하기 때문입니다. 리스크는 사라지지 않습니다. 고정가 방식에서는 견적이 틀릴 위험을 공급사가 떠안고, 그 위험을 제시 금액 안에 미리 얹어 둡니다. 투입 정산 방식에서는 같은 위험을 발주사가 떠안습니다. 질문은 어느 쪽이 불확실성을 없애 주느냐가 아닙니다. 어느 쪽이 그 불확실성을 더 잘 ...

소규모 팀에서 재해 복구는 대개 아무도 열어 본 적 없는 문서 안의 한 줄로 끝납니다. 백업은 켜져 있습니다, 라는 문장입니다. 그 문장은 사실이지만 어떤 질문에도 답이 되지 못합니다. 되찾은 데이터가 얼마나 오래된 것인지, 복원에 얼마나 걸리는지, 지금까지 누가 한 번이라도 끝까지 복원을 해 본 적이 있는지에 대해 아무것도 말해 주지 않기 때문입니다. 백업을 가지고 있다는 사실과 실제로 복구할 수 있다는 사실 사이의 간격에서 대부분의 장애는 심각한 사고로 바뀝니다. 존재하고, 최신이며, 한 번도 복원해 본 적 없는 백업은 아직 가설일 뿐입니다. 그리고 그 가설을 처...

소프트웨어 제안요청서, 즉 RFP는 원래 여러 공급업체를 나란히 놓고 비교할 수 있게 만드는 문서입니다. 그런데 실제로 오가는 문서 대부분은 정반대의 결과를 냅니다. 해법을 지나치게 자세히 지정해 답변의 폭을 묶어 놓으면서, 정작 가격을 산출하는 데 누구에게나 필요한 정보는 빠뜨리기 때문입니다. 그 결과 자릿수가 하나 차이 나는 다섯 개의 견적이 나란히 도착하고, 형식상으로는 모두 요구에 응답했지만 같은 것을 재고 있는 견적은 하나도 없습니다. 흔한 진단은 공급업체가 말을 흐린다는 것입니다. 가끔은 사실입니다. 그러나 훨씬 더 자주 벌어지는 일은, 문서가 그 안에 담...

소프트웨어 유지보수 비용은 성공한 프로젝트를 열여덟 달 뒤 껄끄러운 대화로 바꿔 놓는 숫자입니다. 구축은 예산이 잡혔고 승인이 났고 납품까지 끝났습니다. 그런데 서비스가 가동된 다음에 벌어지는 일은 그냥 “지원"이라는 한마디로 정리되었고, 누군가 감으로 찍은 금액이 붙었으며, 그 금액은 거의 언제나 너무 적었습니다. 이유는 부주의가 아니라 구조에 있습니다. 구축에는 값을 매길 수 있는 범위가 있습니다. 유지보수에는 범위가 없습니다. 아직 일어나지 않은 일들이 그 범위를 정하기 때문입니다. 취약점이 발견되는 라이브러리, API를 바꾸는 공급업체, 아무도 예상하지 못한 ...