# 거대한 SaaS-Lighting - IT 사용자들은 어떻게 "가스라이팅"을 당했나 > Clean Markdown view of GeekNews topic #23942. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23942](https://news.hada.io/topic?id=23942) - GeekNews Markdown: [https://news.hada.io/topic/23942.md](https://news.hada.io/topic/23942.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-10-27T11:00:29+09:00 - Updated: 2025-10-27T11:00:29+09:00 - Original source: [unworkableideas.com](https://unworkableideas.com/the-great-saas-lighting-how-it-users-got-gaslit/) - Points: 7 - Comments: 1 ## Summary SaaS가 한때 약속했던 **‘기술 대신 비즈니스에 집중하라’** 는 이상은 이제 **고객 잠금과 반복 결제 구조**로 변질되었다는 비판입니다. 대형 공급자들은 ‘고객 성공’을 명분으로 **데이터 수집과 이탈 방지**에 초점을 맞추며, 업계 전반은 **‘베스트 프랙티스’라는 이름의 획일화** 속에 스스로 혁신을 봉쇄하고 있습니다. 결국 진짜 경쟁력은 모두가 쓰는 동일한 SaaS가 아니라, **조직의 맥락에 맞는 정보 시스템을 직접 설계하고 운영하는 능력**에 있다는 통찰을 던집니다. SaaS의 편리함 뒤에 숨은 구조적 피로감을 느껴본 개발자라면, 이 글에 꽤 공감하실듯 합니다. ## Topic Body - SaaS 모델은 한때 **‘필요한 만큼만 지불하고, 기술 대신 비즈니스에 집중하라’** 는 약속으로 IT 업계를 설득했으나, 실제로는 고객을 **잠금(lock-in)** 하는 구조로 변질됨 - 주요 공급자들은 고객 만족보다 **지속 결제 유지와 데이터 수집**에 초점을 맞추며, ‘고객 성공 관리자’조차 **이탈 방지를 위한 역할**에 불과 - 업계 전반이 **‘모범 사례(best practice)’** 라는 이름 아래 변화와 혁신을 회피하면서, 결과적으로 **획일적이고 평범한 소프트웨어 생태계**를 양산 - SaaS 시장은 **1980년대 미국 쇼핑몰**처럼 과도하게 통제되고 예측 가능한 구조로 변해, 대형 플랫폼이 **임대인과 상점** 역할을 동시에 수행 - 진정한 해결책은 모두가 사용하는 동일한 시스템이 아니라, **조직에 맞는 정보 시스템**을 구축하는 것이며, 이는 자체 호스팅과 같은 대안적 접근으로 실현 가능 --- ### SaaS 모델의 약속과 현실 - SaaS는 처음에 **‘필요한 만큼만 지불(pay as you go)’** , **‘기술보다 비즈니스에 집중’** 이라는 이상을 내세워 IT 운영의 효율화를 약속 - 사용자는 **자본과 시간을 절약**하고, **기술 관리 부담을 줄일 수 있다**는 메시지로 설득 - 그러나 실제로는 Microsoft, Google, Intuit 등 주요 공급자들이 **고객 중심보다 고객 종속**을 우선시하는 구조로 발전 - 모든 상호작용 후 고객 만족도 조사를 실시하지만, 이는 **빅데이터 수집**을 위한 또 다른 수단에 불과 - 조사 결과는 부차적이며, 실제로는 **고객이 머물면서 계속 결제**하기만 바람 - 수집된 데이터는 **주변부의 점진적 개선**을 위해서만 활용 ### 고객 성공 관리자의 역설 - 거의 모든 SaaS 업체가 **고객 성공 관리자(Customer Success Manager)** 역할을 만들었음 - 이들은 계정에 배정되어 **온보딩을 돕고 이탈을 방지**하는 역할 수행 - '성공'이란 조직의 실제 성공이 아니라, **제품을 충분히 사용하도록** 만드는 것에 불과 - 고객이 유용하다고 생각하는 제품을 만드는 것 자체는 나쁘지 않지만, SaaS 비즈니스 모델은 시간이 지나면서 **고객 성공이 아닌 복종(submission)** 과 **관성(inertia)** 에 기반한 구조로 변질 - 특정 시점에 도달하면 **고객 기반과 제품이 너무 커져서 변화가 불가능**해짐 ### Safety in Numbers - 숫자의 안전성이라는 착각 - 많은 기업이 SaaS를 채택하는 이유는 **‘다른 모두가 하니까’** 라는 심리와 **네트워크 효과** 때문 - 다른 모든 사람이 하고 있다면 좋거나 적어도 **충분히 좋다는 최소 저항 경로**가 됨 - 네트워크 효과에도 가치가 있지만, **숫자는 특정 지점까지만 안전** - 숫자는 보이지 않는 위험, 특히 **블랙 스완 유형의 위험**을 은폐함 - 드물지만 재앙적인 위험은 너무 희귀하고 잠재적으로 재앙적이어서 아무도 실제로 생각하지 않음 - 백업, 재해 복구, 비즈니스 연속성 시스템은 **단일 시스템 장애로부터는 보호**할 수 있지만, **컨텍스트와 노하우 손실**로부터는 보호하지 못함 - 진짜 문제는 손실이 아니라 **축적** - 너무 많은 프로그램, API, 통합, 그리고 정교한 시스템으로 위장한 **과도한 복잡성** - 컨텍스트 복구 시스템은 존재하지 않지만, 성공적인 조직은 **데이터가 아닌 컨텍스트에 의존** - 테라바이트의 데이터는 **왜 데이터를 보유하는지, 무엇을 의미하는지, 어떻게 활용해야 하는지** 모르면 의미가 없음 ### 정보 과잉과 의사결정의 함정 - 정보와 콘텐츠는 **무한하고 확률적**이며 반드시 예측 가능한 것은 아님 - 더 많은 정보가 더 나은 의사결정으로 이어지는 것이 아니라, 단지 **더 많은 데이터**로 이어질 뿐 - 이는 **알지 못하는 것에 대한 두려움과 위험**을 먹이로 삼음 - 의사결정을 내리기 전에 모든 정보를 알 수는 없지만, **미지와 불확실성에 직면했을 때 '베스트 프랙티스' 채택**은 아늑한 안전 담요를 제공 ### Undifferentiated Best Practices — 차별성 없는 모범 사례 - 업계 전반에 **'베스트 프랙티스' 템플릿**에 대한 맹목적 신뢰가 있음 - 베스트 프랙티스의 문제점은 **세상이 변화를 멈췄다고 가정**한다는 것 - 현실에서 세상은 정적이지 않으며, 계속 변화하고 **지속적인 개선과 진화**가 필요 - 템플릿화된 베스트 프랙티스를 맹목적으로 채택하는 것은 **최고가 되는 길이 아니라 평범한 평균으로 가는 길** - '바퀴를 재발명하지 말자'는 논리를 악용 - 이미 해결된 문제를 해결하는 데 시간과 노력을 들일 필요가 없다는 주장 - 실제로는 **경쟁사와의 동등함(parity)을 달성하는 데만 뛰어날 뿐** - 이러한 접근은 **평범함(bland mediocrity)** 을 양산하고, 진정한 차별화나 발전을 가로막는 구조로 작동 ### Bland and Generic Applications — 획일화된 소프트웨어 생태계 - 상용 소프트웨어 환경을 보면 수천 개의 카테고리에 수천 개의 애플리케이션이 있지만, 여전히 **노트 작성이나 캘린더 애플리케이션**에 대한 다른 변형만 제공 - 일부 프로그램은 더 예쁘거나 더 직관적으로 느껴질 수 있지만, **문제 정의와 접근 방식은 유사** - 소프트웨어가 **동일한 해결 가능한 문제를 반복적으로 해결**하는 이유는 남은 과제들이 기술로 해결하기 **정말 어렵기 때문** - 커뮤니케이션과 협업은 **디지털화를 거부하는 뉘앙스와 미묘함**으로 가득함 - 이는 SaaS 업체에만 국한된 것이 아니라, 대부분의 소프트웨어 업체가 제품 마케팅과 판매를 위해 **SaaS 대열에 합류** - 유료 멤버십으로 유인하기 위해 충분한 기능만 제공하는 **무료 버전** - 그 다음 good, better, best 옵션의 **표준 3가지 구독 옵션** 직면 - 커뮤니케이션 도구를 추가해도 **커뮤니케이션의 질은 향상되지 않고** 단지 커뮤니케이션 양만 대폭 증가되어 **잡음과 피로감 증가** 초래 ### Let’s Go to the Mall — SaaS와 1980년대 쇼핑몰의 유사성 - SaaS는 **1980년대 미국 쇼핑몰**과 같은 기술이 되었음 - 과도하게 비싸고 예측 가능하며, 모든 쇼핑몰에서 **상품이 거의 동일** - 이는 역동적인 시장이 아니라 **매우 통제된 시장** - landlord가 플랫폼을 설정하고 소매업체들이 이 훌륭한 위치로 몰려들어 **막대한 이익과 규모의 이점**을 얻음 - 쇼핑몰의 임대료를 감당할 수 있는 소매업체들은 **매우 통제된 경험**을 제공 - 1980년대 쇼핑몰은 **대담한 실험과 위험 감수의 장소가 아니었으며**, 위험은 임대 계약서에 서명하는 것이었음 - Google과 Microsoft는 쇼핑몰의 상점이면서 동시에 **landlord로서 쇼핑몰 경험을 통제** - Apple은 자체 쇼핑몰을 운영하며 **더 빛나지만 다르지는 않음** - 오늘날 물리적 쇼핑몰은 Apple Store가 트래픽을 유입하지 않으면 유령 도시가 될 것 - 어느 시점에서 문화는 쇼핑몰 경험에 **지쳐버렸고**, 미국 전역에 **버려진 쇼핑몰**이 가득함 - 이 모델은 특정 지점까지는 작동하지만 **유행은 변화**함 - 신중하게 큐레이션된 상품을 가진 **작은 상점**이 등장하여 군중을 끌어들임 - 정보 기술의 미래도 **매우 유사**함 - 중요한 것은 다른 모든 사람이 가진 것과 동일한 시스템을 갖는 것이 아님 - 중요한 것은 **자신에게 맞는 정보 시스템**을 갖는 것 ## Comments ### Comment 45506 - Author: neo - Created: 2025-10-27T11:00:30+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45702877) - 소비자들이 음식이나 옷의 **‘진짜 가격’** 을 내기 싫어하듯, 소프트웨어의 진짜 가격도 지불하기를 꺼리는 현상에 대해 이야기함 예전에는 Postman 같은 툴을 한 번에 $40에 샀지만, 지금은 구독형으로 $30/월을 내야 하는 구조임 SaaS는 항상 최신 버전을 유지할 수 있게 해주는 장점이 있음 하지만 소프트웨어 개발은 본질적으로 **경제적으로 비싼 작업**이며, 오픈소스 기여자들의 무급 노동 덕분에 그 가치를 과소평가하고 있음 - “버전 4면 충분한데 왜 계속 업그레이드해야 하냐”는 반론을 제시함 지난 20년간 엄청난 양의 소프트웨어가 만들어졌지만, **혁신적인 돌파구**는 거의 없었다고 느낌 컴퓨터 성능은 10~20배 좋아졌지만, 오히려 느리고 복잡해졌다는 점을 지적함 - 소프트웨어는 음식과 달리 **필수재가 아님**을 강조함 오늘날의 소프트웨어는 종종 소비자에게 강제로 제공되며, 데이터 수집과 감시에 이용되는 **트로이 목마** 역할을 한다고 비판함 소비자는 음식·물·주거에는 돈을 내지만, 소프트웨어에는 내지 않으려 함 - Postman이 비싼 이유는 개발비 때문이 아니라 **VC 상환 구조** 때문이라고 주장함 합리적인 규모의 투자와 팀이었다면, 단순한 curl GUI에 Adobe 수준의 요금을 받을 필요가 없었을 것이라 말함 - 과거 패키지 소프트웨어는 **업그레이드 할인**이 있었고, 중고 판매도 가능했음을 상기함 SaaS가 오픈소스 기여자들에게 더 많은 보상을 주는 것도 아니라고 지적함 - Postman의 문제는 단순히 개발자 생계가 아니라, **기업 수익 극대화**를 위해 제품이 복잡해지고 본래의 단순함을 잃은 것이라고 말함 회사가 이미 여러 클라이언트를 거쳐 옮겨 다녔고, Postman도 결국 같은 길을 걷고 있다고 함 - “AWS가 다운됐다”는 식의 호들갑스러운 글들이 사라지고 **정상적인 논의**로 돌아가길 바람 과거에는 온프레미스 서버로도 충분히 운영이 가능했으며, 지금보다 훨씬 효율적이었다고 회상함 이제는 개발자도 AWS를 이해해야 하고, **보안 위험**과 LLM을 통한 지식 유출까지 걱정해야 하는 시대가 됐다고 토로함 기술 발전이 오히려 **디스토피아적 개발 환경**을 만들었다고 느끼며, 단순하고 직관적인 UX를 그리워함 - 대부분의 기업은 이메일, 캘린더, VPN, CRM 등에서 **‘충분히 좋은 SaaS’** 를 쓰는 게 합리적이라고 주장함 Google Workspace나 HubSpot, Power BI 같은 도구들이 과거 오프라인 제품보다 훨씬 낫다고 느낌 - 그러나 “30년 전 이미 완성된 오피스 소프트웨어에 **사용자당 임대료**를 내는 건 부당하다”고 반박함 - HubSpot 모바일 앱이 **버그가 많고 조작이 불편**하다는 개인 경험을 공유함 작은 화면에 많은 정보를 담기 어려운 점은 이해하지만, 여전히 어색하다고 느낌 - SaaS의 **보안 기능을 계층별로 인질처럼 판매**하는 구조를 비판함 - “SSO(싱글사인온)”을 예로 들며, 일반 로그인으로도 충분히 안전할 수 있다고 주장함 피싱에 걸리는 건 회사의 문제이지, 벤더의 책임은 아니라고 말함 - SaaS 논의에서 빠질 수 없는 **‘불법 복제(piracy)’** 문제를 제기함 - SaaS는 기업이 사용자 통제를 완벽히 할 수 있게 만들었고, **Salesforce의 확산 전략**처럼 개인→팀→조직으로 자연스럽게 확장되게 했다고 설명함 설치가 필요 없다는 점이 도입을 쉽게 만들었음 - 아이러니하게도, FOSS 지지자들이 말하던 “서비스 계약으로 수익을 내는 세상”이 현실이 되었지만, 결과적으로 **더 폐쇄적인 환경**이 되었다고 말함 - 과거 스타트업에서 만든 시스템이 중국 SaaS 회사에 **소스코드째로 복제**된 경험을 공유함 지식재산 도용이 흔하지만, 데이터는 결국 **자유로워지려는 성질**을 가진다고 덧붙임 - 기업 환경에서는 불법 복제가 거의 없었기 때문에, SaaS가 그 문제를 해결하려고 만든 모델은 아니라고 분석함 - 《Fundamentals of Data Engineering》을 읽으며, **웹 스크래핑이 SaaS 시대의 새로운 ‘복제’ 형태**라는 점을 깨달았다고 언급함 - SaaS 자체는 나쁜 개념이 아니며, **필요한 만큼만 비용을 내는 구조**로는 합리적이라고 설명함 문제는 구독 모델이 과도해지고, **벤더 락인**으로 인해 데이터 이동이 불가능해지는 점임 AWS의 **‘모트(moat)’ 전략**처럼, 사용자가 스스로 만든 종속성 때문에 벗어날 수 없게 됨 따라서 핵심 기능은 SaaS에 의존하지 말아야 한다고 조언함 - AWS Amplify가 **최악의 락인 사례**였다고 강하게 비판함 - SaaS의 부정적인 면만 강조하는 건 불균형적이라고 지적함 **B2B SaaS**는 경쟁이 유지되는 한, 고객에게 큰 이점을 줄 수 있음 벤더는 **이탈(churn)** 을 막기 위해 제품을 꾸준히 개선하고, 신규 기능을 무료로 제공하려는 동기를 가짐 반면, 구형 온프레미스 소프트웨어는 유지보수 계약이 비싸고 품질이 낮았다고 회상함 결국 구매자는 **타협점을 선택**해야 한다고 말함 - Photoshop이나 AutoCAD 같은 제품은 **단기 구독 옵션**이 있었다면 프리랜서에게 유용했을 것이라고 말함 하지만 현실적으로 구독을 자유롭게 켜고 끄는 건 어렵다고 함 - 2000년 버전의 Photoshop 6.0을 구매해 현대 PC에서 사용 중이며, **DRM 없이 완벽히 작동**한다고 공유함 한 번 구매로 충분하다고 강조함 - SaaS의 근본적인 락인은 두 가지 요소의 결합에서 온다고 분석함 1) **선언적이고 안정적인 인터페이스**, 2) **전문 운영팀의 지원** 이 둘을 분리(unbundle)해야 한다고 주장하며, 첫 번째는 이미 [Nix](https://ryanrasti.com/blog/why-nix-will-win/)가 해결할 가능성이 있다고 설명함 남은 과제는 **자체 호스팅 기반의 지원 비즈니스 모델**을 만드는 것임 기술적으로 해결할 수 있을 것이라 믿지만, 아직 구현된 적은 없다고 함