본문으로 이동

서비스형 소프트웨어

한울위키, 우리 모두의 백과사전.
(SaaS에서 넘어옴)

서비스형 소프트웨어(Software as a service, SaaS /sæs/)[1]는 제공자가 클라이언트에게 응용 소프트웨어 사용을 제공하고 필요한 모든 물리적 및 소프트웨어 리소스를 관리하는 클라우드 컴퓨팅 서비스 모델이다.[2][3] SaaS는 일반적으로 웹 애플리케이션을 통해 액세스한다. 다른 소프트웨어 딜리버리 모델과 달리 "소프트웨어의 소유와 소유권을 사용에서 분리"한다. SaaS 사용은 2000년경에 시작되었으며 2023년까지 응용 소프트웨어 배포의 주된 형태가 되었다.

대부분의 자체 호스팅 소프트웨어 제품과 달리 소프트웨어의 버전이 하나뿐이며 지원되는 운영 체제와 구성은 하나뿐이다. SaaS 제품은 일반적으로 하드웨어와 때로는 운영 체제 및 미들웨어를 포함한 임대식 서비스형 인프라스트럭처(IaaS) 또는 서비스형 플랫폼(PaaS) 시스템에서 실행되어 사용량이 빠르게 증가하는 것을 수용하고 고객에게 즉각적이고 지속적인 가용성을 제공한다. SaaS 고객은 무한한 컴퓨팅 리소스를 추상화하는 반면 규모의 경제성은 비용을 낮춘다. SaaS 아키텍처는 일반적으로 멀티 테넌트이다. 일반적으로 효율성을 위해 클라이언트 간에 리소스를 공유하지만 때로는 추가 요금을 내고 사일로 환경을 제공한다. 일반적인 SaaS 수익 모델에는 프리미엄, 구독 및 사용 기반 요금이 포함된다. 기존 소프트웨어와 달리 특정 버전의 소프트웨어에 대한 영구 라이선스를 구매하는 것은 거의 불가능하다.

SaaS를 다른 애플리케이션 개발과 구별하는 특정 소프트웨어 개발 관행은 없지만 빈번한 테스트와 릴리스에 중점을 두는 경우가 많다.

클라우드 컴퓨팅

 이 부분의 본문은 클라우드 컴퓨팅입니다.
파일:Comparison of on-premise, IaaS, PaaS, and SaaS.png
온프레미스, IaaS, PaaS, SaaS의 비교

서비스형 인프라스트럭처(IaaS)는 가장 기본적인 형태의 클라우드 컴퓨팅으로, 물리적 컴퓨터와 같은 인프라 리소스를 사용자가 소유하지 않고 클라우드 제공자로부터 임대한다. 그 결과, 컴퓨터가 배송되고 설정될 때까지 몇 주를 기다릴 필요 없이 인프라 리소스를 빠르게 늘릴 수 있다. IaaS는 운영 체제와 애플리케이션의 형태로 인프라를 활용하기 위해 시간과 전문성이 필요하다.[4] 서비스형 플랫폼(PaaS)에는 운영 체제와 미들웨어가 포함되지만 애플리케이션은 포함되지 않는다.[5][6] SaaS 제공자는 일반적으로 PaaS 또는 IaaS 서비스를 사용하여 애플리케이션을 실행한다.[5]

IaaS가 없다면 다양한 수의 사용자에게 SaaS 제품을 확장 가능하게 만들고 고객이 기대하는 즉각적이고 지속적인 가용성을 제공하는 것은 매우 어려울 것이다.[7] 대부분의 최종 사용자는 SaaS 제품만 사용하며 물리적 하드웨어와 운영 체제의 기술적 복잡성에 대해 걱정할 필요가 없다.[8] 클라우드 리소스는 인간의 상호 작용 없이 액세스할 수 있기 때문에 SaaS 고객에게 무한한 컴퓨팅 리소스의 추상화가 제공되는 반면 규모의 경제성으로 인해 비용이 절감된다.[9] 클라우드 컴퓨팅의 또 다른 주요 특징은 소프트웨어 업데이트를 거의 즉시 모든 고객에게 배포하여 제공할 수 있다는 것이다.[10] 2019년에 SaaS는 클라우드 컴퓨팅 시장의 다수인 43%를 차지한 것으로 추산되었고, IaaS와 PaaS를 합치면 약 25%를 차지했다.[11]

역사

1960년대에는 다중작업이 발명되어 메인프레임이 여러 사용자를 동시에 서비스할 수 있게 되었다. 다음 10년간 시분할 시스템이 컴퓨팅의 주요 비즈니스 모델이 되었고, 클러스터 컴퓨팅은 여러 컴퓨터가 함께 작동하도록 만들었다.[9] 클라우드 컴퓨팅은 1990년대 후반에 아마존 (1994), 세일즈포스닷컴 (1999), Concur (1993)와 같은 회사들이 인터넷 기반의 애플리케이션을 사용량에 따라 지불하는 방식으로 제공하면서 등장했다. 이 모든 회사들은 높은 시장 점유율을 확보하기 위해 단일 제품에 집중했다.[12] 2004년 Gmail을 시작으로, 이메일 서비스는 소비자에게 대량으로 마케팅된 최초의 SaaS 제품 중 일부였다.[13] SaaS 시장은 21세기 초 내내 빠르게 성장했다.[14][11] 처음에는 기술 혁신으로 간주되었던 SaaS는 이제 비즈니스 모델로 더 많이 인식되고 있다.[15] 2023년까지 SaaS는 기업이 애플리케이션을 제공하는 주요 방법이 되었다.[16]

인기 있는 소비자 SaaS 제품에는 모든 소셜 미디어 웹사이트, Gmail 및 관련 구글 독스 편집기와 같은 이메일 서비스,[17] 스카이프, 드롭박스,[18] 그리고 넷플릭스 및 스포티파이와 같은 엔터테인먼트 제품이 포함된다.[19] 기업용 SaaS 제품에는 세일즈포스닷컴의 고객 관계 관리(CRM) 소프트웨어, SAP 클라우드 플랫폼, 오라클 클라우드 엔터프라이즈 리소스 플래닝이 포함된다.[18]

수익 모델

일부 SaaS 제공업체는 광고, 제휴 마케팅 또는 소비자 데이터 판매와 같은 방식으로 자금을 조달하는 무료 서비스를 소비자에게 제공한다.[20] 인터넷 스타트업 및 모바일 앱의 가장 인기 있는 모델 중 하나는 프리미엄으로, 회사는 지속적인 사용 또는 더 높은 수준의 서비스에 대해 요금을 부과한다. 사용자가 유료 버전으로 업그레이드하지 않더라도, 이는 회사가 더 높은 시장 점유율을 확보하고 경쟁사로부터 고객을 빼앗는 데 도움이 된다.[21] 그러나 유료 버전 사용을 유도하는 데 성공했는지 여부와 관계없이 회사의 호스팅 비용은 사용자 수에 따라 증가한다.[22] 또 다른 일반적인 모델은 무료 버전이 데모만 제공하는 경우이다(크리플웨어). 온라인 마켓플레이스는 SaaS 제공업체 비용을 충당하기 위해 거래 수수료를 부과할 수 있다.[20] 과거에는 SaaS 제품을 일회성 비용으로 제공하는 것이 더 일반적이었지만, 이 모델은 인기가 줄고 있다.[20] 소수의[20] SaaS 제품은 오픈 SaaS라고 불리는 오픈 소스 코드를 가지고 있다. 이 모델은 배포 비용 절감, 공급업체 종속성 감소, 더 많은 이식 가능한 애플리케이션과 같은 이점을 제공할 수 있다.[23]

가장 일반적인 SaaS 수익 모델은 구독 및 사용량 기반 지불 방식이다.[24] 고객의 경우, 초기 비용 절감, 유연성 증가, 영구적인 소프트웨어 사용권을 가진 기존 소프트웨어에 비해 전체 비용 절감과 같은 이점이 있다.[25] 어떤 경우에는 기존 소프트웨어 판매자가 요구하는 높은 일회성 비용이 중소기업에게는 감당하기 어려웠지만, 사용량 기반 SaaS 모델은 소프트웨어를 저렴하게 만들었다.[3] 사용량은 사용자 수, 거래 수, 사용된 저장 공간의 양 또는 기타 지표를 기반으로 청구될 수 있다.[26] 많은 구매자는 자신들이 소프트웨어의 사용량이 적다고 믿기 때문에 사용량 기반 지불 방식을 선호하며, 판매자는 그렇지 않았다면 소프트웨어를 구매하지 않았을 가끔씩 사용하는 사용자들에게 도달함으로써 이점을 얻는다.[26] 그러나 이는 판매자의 수익 불확실성을 초래하고 청구에 대한 오버헤드를 증가시킬 수 있다.[27]

SaaS의 구독 모델은 취소될 위험이 있지만, 제공업체에 지속적이고 재생 가능한 수익원을 제공한다.[3] 상당한 수가 취소되면 사업의 생존 가능성이 위태로워질 수 있다.[3] 구독을 쉽게 취소하고 경쟁업체로 전환할 수 있다는 점은 고객에게 판매자로부터 양보를 얻을 수 있는 영향력을 제공한다.[28] 반복적인 수익은 사업에 도움이 되고 투자자를 유치할 수 있지만, 고객에게 구독 갱신을 설득하는 고객 서비스 기술의 필요성은 다른 수익 모델에서 구독으로 전환하는 제공업체에게는 어려운 과제이다.[29]

도입

SaaS 제품은 일반적으로 공용 웹 애플리케이션으로서 웹 브라우저를 통해 접근된다.[30][16] 이는 고객이 설치하거나 업데이트할 필요 없이 언제 어디서든 어떤 기기에서든 애플리케이션에 접근할 수 있다는 것을 의미한다.[16][31] SaaS 제공업체는 종종 제품 가입의 어려움을 최소화하려고 노력한다.[32] 많은 회사들이 서비스 지향적인 구조를 활용하여 고객 피드백에 신속하게 대응하고 수요를 충족하기 위해 제품을 빠르게 발전시킨다. 이는 고객이 제품의 지속적인 개선을 믿게 하고, SaaS 제공업체가 더 깊은 기능 세트를 제공할 수 있는 기존의 전통적인 소프트웨어 회사로부터 고객을 유치하는 데 도움이 될 수 있다.[33][34]

온프레미스 소프트웨어는 SaaS 대안보다 보안이 약한 경우가 많지만,[35] 보안 및 프라이버시는 SaaS 제품을 채택하지 않는 회사들이 언급하는 주요 이유 중 하나이다.[36] SaaS 기업은 서비스 거부 공격 및 해킹을 포함한 남용으로부터 공개적으로 제공되는 서비스를 보호해야 한다.[37] 이들은 종종 접근 제어, 인증, 암호화와 같은 기술을 사용하여 데이터 기밀성을 보호한다.[36] 그럼에도 불구하고, 모든 회사가 SaaS 제공업체가 민감한 데이터를 안전하게 보관할 것이라고 신뢰하는 것은 아니다.[36] 공급업체는 보안 패치를 포함한 소프트웨어 업데이트와 고객 데이터 보호에 대한 책임이 있다.[31] SaaS 시스템은 클라우드 시설로 네트워크 패킷이 전달되는 시간 때문에 온프레미스에서 실행되는 소프트웨어보다 본질적으로 더 큰 레이턴시를 갖는다. 이는 시간 민감 산업 공정 또는 창고 보관과 같은 일부 용도에는 제약이 될 수 있다.[38]

SaaS 제품의 증가는 많은 기업이 자본 지출에서 운영 지출로 IT 예산을 전환하는 한 가지 요인이 되었다.[39] SaaS로의 마이그레이션 및 지원 프로세스 또한 고려해야 할 상당한 비용이 될 수 있다.[40][29]

개발

파일:SaaS architecture.jpg
SaaS 아키텍처. 모든 고객은 동일한 플랫폼에서 동일한 버전의 소프트웨어를 실행한다.[41]

SaaS 제공업체의 과제는 수요를 미리 알 수 없다는 점이다. 시스템은 모든 사용자를 거부하지 않고 처리할 수 있을 만큼 충분한 여유를 가져야 하지만, 불필요한 너무 많은 리소스에 비용을 지불해서는 안 된다. 리소스가 정적이라면 비피크 시간 동안 낭비될 것이 확실하다.[42] 때로는 부하를 분산하고 낭비를 줄이기 위해 더 저렴한 비피크 요금이 제공되기도 한다.[43] 지속적인 서비스에 대한 기대치가 너무 높아 SaaS 소프트웨어의 중단은 종종 뉴스에 보도된다.[44]

SaaS와 다른 유형의 애플리케이션 개발을 구별하는 특정 소프트웨어 개발 관행은 없다.[45] SaaS 제품은 SaaS 전달 모델의 유연성을 활용하기 위해 조기에 자주 출시되는 경우가 많다.[46] 애자일 소프트웨어 개발은 이러한 출시 일정을 지원하기 위해 일반적으로 사용된다.[47] 많은 SaaS 개발자들은 서비스의 가용성과 신속한 배포를 보장해야 할 필요성 때문에 테스트 주도 개발을 사용하거나 빈번한 소프트웨어 테스트를 강조한다.[48] 비즈니스 목표가 개발을 주도하는 도메인 주도 설계는 SaaS 제품이 유용함으로써 고객에게 스스로를 판매해야 하므로 인기가 많다.[49] SaaS 개발자는 고객이 제품에 접근하려는 기기(데스크톱 컴퓨터, 태블릿 또는 스마트폰 등)를 미리 알 수 없으며, 다양한 기기를 지원하는 것이 프론트엔드 웹 개발 팀에게는 종종 중요한 관심사이다.[50] 프로그레시브 웹 애플리케이션은 기기가 오프라인 상태일 때도 일부 기능을 사용할 수 있도록 한다.[51]

SaaS 애플리케이션은 주로 광역 통신망을 통해 작동하는 통합 프로토콜 및 응용 프로그래밍 인터페이스(API)를 제공한다.[52]

아키텍처

SaaS 아키텍처는 제품마다 크게 다르다.[53] 그럼에도 불구하고 대부분의 SaaS 제공업체는 멀티테넌시 아키텍처를 제공한다.[30] 이 모델에서는 단일 버전의 애플리케이션이 단일 구성(하드웨어, 네트워크, 운영체제)으로 모든 고객("테넌트")에게 사용된다.[54] 이는 회사가 여러 버전과 구성을 지원할 필요가 없다는 것을 의미한다.[16] 각 고객이 자체 하드웨어에서 자체 버전의 소프트웨어를 실행하는 것에서 아키텍처가 변화하면서 애플리케이션의 설계 및 보안 기능의 여러 측면에 영향을 미친다.[54] 멀티테넌트 아키텍처에서는 많은 시스템 리소스를 여러 테넌트가 사용하거나 여러 테넌트 간에 공유할 수 있다.[55]

파일:Application and control planes of a SaaS product.png
SaaS 제품의 애플리케이션 및 제어 평면

일반적인 SaaS 애플리케이션의 구조는 애플리케이션 평면과 제어 평면으로 나눌 수 있다.[56] SaaS 제품은 이러한 평면이 어떻게 분리되는지에 따라 다르며, 이는 밀접하게 통합될 수도 있고 이벤트 또는 메시지 기반 모델에서 느슨하게 연결될 수도 있다.[57] 제어 평면은 시스템을 지시하는 역할을 하며 테넌트 온보딩, 청구, 지표, 그리고 SaaS 제공업체가 서비스를 구성, 관리 및 운영하는 데 사용하는 시스템과 같은 기능을 포괄한다.[56] 많은 SaaS 제품은 다양한 가격으로 다양한 서비스 수준(티어링이라고 불림)으로 제공된다. 이는 제어 평면에 일반적으로 배치되지만, 두 평면의 아키텍처에도 영향을 미칠 수 있다.[58] 애플리케이션 평면과 달리 제어 평면의 서비스는 멀티테넌시를 위해 설계되지 않았다.[59]

파일:Tenant routing for SaaS example.png
일부 서비스는 공유되고 다른 서비스는 테넌트별로 할당되는 아키텍처 예시[60]

애플리케이션 평면은 제품의 특성에 따라 크게 다르지만, SaaS 제품의 핵심 기능을 구현한다.[59] 주요 설계 문제는 서로 다른 테넌트가 다른 테넌트의 데이터 또는 리소스를 보거나 변경할 수 없도록 분리하는 것이다.[61] 가장 간단한 SaaS 애플리케이션을 제외하고, 일부 마이크로서비스 및 기타 리소스는 모든 테넌트 간에 공유되는 것이 아니라 테넌트별로 할당된다.[62] 테넌트 요청을 적절한 서비스로 라우팅하는 라우팅 기능이 필요하다.[60]

프리미엄 티어에서 완전한 사일로화를 제공하고 다른 테넌트에게는 혼합된 마이크로서비스 배포를 제공하는 SaaS 배포 아키텍처 예시[63]

일부 SaaS 제품은 테넌트 간에 리소스를 전혀 공유하지 않는데, 이를 사일로화라고 한다. 비록 이것이 SaaS의 많은 효율성 이점을 상쇄하지만, 레거시 소프트웨어를 SaaS로 마이그레이션하는 것을 더 쉽게 만들고[64] 때로는 더 높은 가격의 프리미엄 제품으로 제공되기도 한다.[65] 모든 리소스를 풀링하면 더 높은 효율성을 달성할 수 있지만,[66] 서비스 중단은 모든 고객에게 영향을 미치므로 가용성을 더 크게 우선시해야 한다.[67] 많은 시스템은 두 가지 접근 방식을 조합하여 일부 리소스는 풀링하고 다른 리소스는 사일로화한다.[68] 다른 회사들은 여러 테넌트를 포드(pod)로 그룹화하고 그들 간에 리소스를 공유한다.[69]

법적 문제

미국에서 헌법상의 수색영장 관련 법률은 모든 형태의 SaaS 동적으로 저장된 데이터를 보호하지 않는다. 그 결과, 정부는 소유자의 동의 없이 SaaS 제공업체로부터 데이터를 요청할 수 있다.[70][71]

GPL-2.0와 같은 특정 오픈 소스 사용권은 독일에서 SaaS 제품으로 배포를 허용하는 권한을 명시적으로 부여하지 않는다.[72]

같이 보기

출처

  • Ballhausen, Miriam (2014). “OpenSaaS: Using Free and Open Source Software as Software-as-a-Service”. 《International Free and Open Source Software Law Review》 6: 61–68. ISSN 2666-8106. 
  • Bhandari, Guru Prasad; Gupta, Ratneshwer (2019). 〈An Overview of Cloud and Edge Computing Architecture and Its Current Issues and Challenges〉 (영어). 《Advancing Consumer-Centric Fog Computing Architectures》. IGI Global. 1–37쪽. ISBN 978-1-5225-7149-0. 
  • Dempsey, David; Kelliher, Felicity (2018). 《Industry Trends in Cloud Computing: Alternative Business-to-Business Revenue Models》 (영어). Springer International Publishing. ISBN 978-3-319-87693-1. 
  • Garbis, Jason; Chapman, Jerry W. (2021). 《Zero Trust Security: An Enterprise Guide》 (영어). Apress. ISBN 978-1-4842-6703-5. 
  • Golding, Tod (2024). 《Building Multi-Tenant SaaS Architectures》 (영어). O'Reilly Media. ISBN 978-1-0981-4061-8. 
  • Ibrahim, Ahmed Mamdouh Abdelfatah; Abdullah, Norris Syed; Bahari, Mahadi (2023). 《Software as a Service Challenges: A Systematic Literature Review》 (영어). Springer International Publishing. 257–272쪽. ISBN 978-3-031-18344-7. 
  • Kinnunen, Juha (2022). 《ERP as Software-as-a-Service: Factors Depicting Large Enterprises Cloud Adoption》 (영어). Springer International Publishing. 123–142쪽. ISBN 978-3-030-99191-3. 
  • Lynn, Theo; Mooney, John G.; Rosati, Pierangelo; Fox, Grace (2020). 《Measuring the Business Value of Cloud Computing》 (영어). Springer Nature. ISBN 978-3-030-43198-3. 
    • Tallon, Paul P.; Mooney, John G.; Duddek, Marvin (2020). 〈Measuring the Business Value of IT〉 (영어). 《Measuring the Business Value of Cloud Computing》. Springer International Publishing. 1–17쪽. ISBN 978-3-030-43198-3. 
    • Rosati, Pierangelo; Lynn, Theo (2020). 〈Measuring the Business Value of Infrastructure Migration to the Cloud〉 (영어). 《Measuring the Business Value of Cloud Computing》. Springer International Publishing. 19–37쪽. ISBN 978-3-030-43198-3. 
    • Clohessy, Trevor; Acton, Thomas; Morgan, Lorraine (2020). 〈The SaaS Payoff: Measuring the Business Value of Provisioning Software-as-a-Service Technologies〉 (영어). 《Measuring the Business Value of Cloud Computing》. Springer International Publishing. 39–55쪽. ISBN 978-3-030-43198-3. 
  • Manvi, Sunilkumar; Shyam, Gopal (2021). 《Cloud Computing: Concepts and Technologies》. CRC Press. 105쪽. ISBN 9781000337952. 
  • Watt, Andy (2023). 《Building Modern SaaS Applications with C# And . NET: Build, Deploy, and Maintain Professional SaaS Applications》 (영어). Packt. ISBN 978-1-80461-087-9. 
  • Younas, Muhammad; Jawawi, Dayang N. A.; Ghani, Imran; Fries, Terrence; Kazmi, Rafaqut (2018). “Agile development in the cloud computing environment: A systematic review”. 《Information and Software Technology》 103: 142–158. doi:10.1016/j.infsof.2018.06.014. ISSN 0950-5849. 

각주

  1. ↑ Panker, Jon; Lewis, Mark; Fahey, Evan; Vasquez, Melvin Jafet (August 2007). “How do you pronounce IT?”. 《TechTarget》. 2016년 11월 28일에 원본 문서에서 보존된 문서. 2012년 5월 24일에 확인함. 
  2. ↑ Golding 2024, 14쪽.
  3. ↑ 가 나 다 라 Dempsey & Kelliher 2018, 2쪽.
  4. ↑ Rosati & Lynn 2020, 22쪽.
  5. ↑ 가 나 Rosati & Lynn 2020, 23쪽.
  6. ↑ Ibrahim et al. 2023, 258쪽.
  7. ↑ Dempsey & Kelliher 2018, 17쪽.
  8. ↑ Dempsey & Kelliher 2018, 17–18쪽.
  9. ↑ 가 나 Dempsey & Kelliher 2018, 19쪽.
  10. ↑ Dempsey & Kelliher 2018, 33쪽.
  11. ↑ 가 나 Rosati & Lynn 2020, 20쪽.
  12. ↑ Dempsey & Kelliher 2018, 23, 31쪽.
  13. ↑ Watt 2023, 8쪽.
  14. ↑ Dempsey & Kelliher 2018, 24, 32쪽.
  15. ↑ Dempsey & Kelliher 2018, 35쪽.
  16. ↑ 가 나 다 라 Watt 2023, 4쪽.
  17. ↑ Watt 2023, 4, 8쪽.
  18. ↑ 가 나 Clohessy et al. 2020, 40쪽.
  19. ↑ Watt 2023, 9쪽.
  20. ↑ 가 나 다 라 Dempsey & Kelliher 2018, 48쪽.
  21. ↑ Dempsey & Kelliher 2018, 61–63쪽.
  22. ↑ Dempsey & Kelliher 2018, 63–64쪽.
  23. ↑ Bhandari & Gupta 2019, 21쪽.
  24. ↑ Dempsey & Kelliher 2018, 48, 57쪽.
  25. ↑ Clohessy et al. 2020, 40–41쪽.
  26. ↑ 가 나 Dempsey & Kelliher 2018, 57쪽.
  27. ↑ Dempsey & Kelliher 2018, 57–58쪽.
  28. ↑ Dempsey & Kelliher 2018, 11쪽.
  29. ↑ 가 나 Dempsey & Kelliher 2018, 66쪽.
  30. ↑ 가 나 Garbis & Chapman 2021, 185쪽.
  31. ↑ 가 나 Kinnunen 2022, 123–124쪽.
  32. ↑ Golding 2024, 18쪽.
  33. ↑ Golding 2024, 20쪽.
  34. ↑ Watt 2023, 15쪽.
  35. ↑ Watt 2023, 6, 16쪽.
  36. ↑ 가 나 다 Ibrahim et al. 2023, 264, 266, 268쪽.
  37. ↑ Garbis & Chapman 2021, 186쪽.
  38. ↑ Kinnunen 2022, 137, 139쪽.
  39. ↑ Tallon et al. 2020, 2쪽.
  40. ↑ Kinnunen 2022, 124쪽.
  41. ↑ Golding 2024, 25쪽.
  42. ↑ Dempsey & Kelliher 2018, 36쪽.
  43. ↑ Dempsey & Kelliher 2018, 37쪽.
  44. ↑ Dempsey & Kelliher 2018, 39쪽.
  45. ↑ Watt 2023, 11쪽.
  46. ↑ Watt 2023, 16쪽.
  47. ↑ Younas et al. 2018, 142쪽.
  48. ↑ Watt 2023, 11–12, 16쪽.
  49. ↑ Watt 2023, 12쪽.
  50. ↑ Watt 2023, 13–14쪽.
  51. ↑ Watt 2023, 13쪽.
  52. ↑ Manvi & Shyam 2021, 105쪽.
  53. ↑ Golding 2024, 47쪽.
  54. ↑ 가 나 Golding 2024, 25–26쪽.
  55. ↑ Golding 2024, 26쪽.
  56. ↑ 가 나 Golding 2024, 27쪽.
  57. ↑ Golding 2024, 44쪽.
  58. ↑ Golding 2024, 40쪽.
  59. ↑ 가 나 Golding 2024, 28쪽.
  60. ↑ 가 나 Golding 2024, 38쪽.
  61. ↑ Golding 2024, 36–37쪽.
  62. ↑ Golding 2024, 37쪽.
  63. ↑ Golding 2024, 76쪽.
  64. ↑ Golding 2024, 55쪽.
  65. ↑ Golding 2024, 55, 74–75쪽.
  66. ↑ Golding 2024, 69쪽.
  67. ↑ Golding 2024, 70쪽.
  68. ↑ Golding 2024, 75–76쪽.
  69. ↑ Golding 2024, 78쪽.
  70. ↑ Arthur, Charles (2010년 12월 14일). “Google's ChromeOS means losing control of the data, warns GNU founder Richard Stallman”. 《The Guardian》. 영국. 2014년 2월 28일에 원본 문서에서 보존된 문서. 2012년 2월 16일에 확인함. 
  71. ↑ Adhikari, Richard (2010년 12월 15일). “Why Richard Stallman Takes No Shine to Chrome”. 《Linux Insider》. 2021년 1월 23일에 원본 문서에서 보존된 문서. 2015년 3월 24일에 확인함. 
  72. ↑ Ballhausen 2014, 61쪽.

모듈:Authority_control 159번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).

원본 주소 "https://www.hanul.wiki/w/index.php?title=서비스형_소프트웨어&oldid=43827"