소규모 사업체

프로그레시브 웹 앱 개발은 영국의 발주자가 프로젝트 시작 첫 10분에 후보에서 빼고, 두 번째 네이티브 코드베이스가 조용히 예산을 다 먹어치운 뒤 18개월 만에 다시 발견하는 선택지입니다. 빠지는 이유는 이 주제로 쓰인 글이 거의 두 진영 중 하나에 속하기 때문입니다. iOS가 하지 않으려는 부분을 건너뛰는 옹호론이거나, 플랫폼이 정말로 그것을 못 하던 2019년에서 물려받은 회의론이거나 둘 중 하나입니다. 지금은 둘 다 틀렸고, 게다가 계산을 바꾸는 방식으로 틀렸습니다. Safari는 iOS 16.4부터 홈 화면에 추가한 웹 앱에서 푸시 알림을 지원합니다....

Salesforce와 HubSpot을 비교한 글은 거의 전부 둘 중 한쪽의 파트너가 쓴 것입니다. 음모가 아니라 경제적인 사실입니다. 두 제품을 비교할 만큼 깊이 아는 사람은 둘 중 하나를 구축하며 먹고살기 때문입니다. 그 결과 한쪽에는 가장 강한 논거를, 다른 쪽에는 약점의 정중한 요약을 주는 장르의 글이 만들어집니다. 우리는 두 제품을 모두 구축하고 연동하며, 고객사를 양쪽 방향으로 옮겨 본 적이 있습니다. 아래는 테이블 건너편에서 물어 오는 고객에게 우리가 그대로 들려줄 비교입니다. 가격은 2026년 9월에 각 벤더 자신의 가격 페이지에서 읽었고,...

wordpress vs wix를 검색하면 첫 페이지의 거의 모든 결과가 누군가에게 수수료를 지급합니다. Wix도 Squarespace도, 대형 매니지드 WordPress 호스팅 업체들도 모두 제휴 프로그램을 운영합니다. 비교 사이트는 그 수수료를 수확하려고 존재하며, 추천은 조사가 시작되기도 전에 지급액 표에서 결정됩니다. 그래서 결론이 하나같이 비슷하고, 어느 기업도 실제로는 품고 있지 않은 질문에 답하는 것입니다. 기업이 품는 질문은 어떤 플랫폼이 가장 좋은가가 아닙니다. 세 가지 모두 15페이지짜리 브로슈어 사이트를 운영하기에 충분하고,...

WordPress 호스팅은 월 3파운드 남짓에서 수백 파운드까지 걸친 가격대로 팔리는데, 그 양 끝에 있는 요금제는 거의 똑같은 말로 자신을 설명합니다. 빠릅니다. 안전합니다. 백업됩니다. 지원됩니다. 구매자가 둘을 구분할 수 있게 해줄 사양, 즉 사이트가 어떤 PHP 브랜치에서 도는지, 그 뒤에 어떤 데이터베이스 엔진이 있는지, 캐시 계층이 몇 개이고 그중 실제로 켜져 있는 것은 무엇인지는 정작 결제를 요구하는 페이지에 대개 없습니다. 그 부재는 상품의 일부입니다. “관리형"은 기술 범주가 아니라 마케팅 범주이며, 이를 정의하는 표준화 기구는 없습니다....

Drupal 지원을 찾는 사람 대부분은 이미 그 사이트를 소유하고 있습니다. 손을 뗀 에이전시에서 넘겨받았거나 퇴사한 개발자에게서 물려받았고, 이제 업데이트는 기한을 넘겼고 어떤 양식은 메일을 보내지 않으며 보안 권고문이 하나 떨어졌는데 그것이 우리에게 해당하는지 아무도 말하지 못합니다. 그들이 원하는 것은 영업 페이지가 아닙니다. 일이 무엇이고, 공정한 계약에는 무엇이 적혀 있으며, 얼마가 드는지를 적은 범위 문서입니다. 이 글이 바로 그 문서입니다. Drupal 사이트가 매달 진짜로 필요로 하는 일, 유지보수 계약이 값어치를 하는지 가르는 운영상의 사실, 그리고 ...

Elementor와 커스텀 테마를 둘러싼 논쟁은 대개 취향 문제로, 가끔은 진영 논리로 다뤄집니다. 둘 다 아닙니다. 이것은 비용 문제이며 그 모양은 예측 가능합니다. 페이지 빌더는 비용을 구축 단계에서 사이트의 운영 기간으로 옮깁니다. 그 거래가 이득인지는 거의 아무도 협상 테이블에 올리지 않는 두 숫자에 달려 있습니다. 사이트에 페이지가 몇 개인지, 그리고 그 페이지가 얼마나 자주 바뀌는지입니다. 논쟁이 끝나지 않는 이유는 양쪽 모두 일화로 말하기 때문입니다. 누군가는 빌더가 느리다고 말하고, 다른 누군가는 초록색 Lighthouse 점수를 올리며, 아무것도 정리...

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

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

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

MVP 소프트웨어 개발이 어긋나는 지점은 구현 단계가 아니라 범위를 정하는 회의입니다. 누군가 “최소 기능 제품"이라고 말하면 모두가 고개를 끄덕이고, 그다음에 도착한 기능 목록에는 사용자 계정과 관리자 화면, 결제, 알림, 대시보드, 그리고 모바일 앱까지 들어 있습니다. 그것은 최소 기능 제품이 아닙니다. 그것은 이미 완성된 제품이고, 머릿속에 떠올린 숫자보다 세 배는 더 오래 걸립니다. 정작 문제를 일으키는 단어는 “기능하는”, 즉 뒤에 붙는 viable입니다. 대부분의 팀은 이 말을 “누구에게나 팔 수 있을 만큼 좋은 상태"로 읽지만, 실제 의미는 “...