많은 SaaS 제품이 더 이상 다른 SaaS 제품과 경쟁하지 않고 있습니다. 이제는 조립식 오픈소스 AI 스택과 경쟁하고 있는 것입니다.
오픈소스 AI는 이제 많은 기업이 더 이상 좁은 범위의 워크플로우마다 별도의 구독이 필요하지 않은 수준에 도달했습니다. 대신, 오픈 모델, 오케스트레이션 레이어, 데이터베이스, 자동화 도구, 그리고 경량 인터페이스로 구성된 유연한 스택을 조립하여 SaaS 도구가 담당하던 업무의 상당 부분을 처리할 수 있게 되었습니다.
그렇다고 SaaS가 죽었다는 뜻은 아닙니다.
기본 질문이 다음과 같이 바뀌고 있다는 의미입니다.
"어떤 도구를 사야 할까?"
에서 다음과 같이 바뀌고 있습니다:
"이걸 살까, 아니면 오픈소스 AI로 직접 조립할까?"
이는 큰 변화입니다.
그리고 이러한 변화가 일어나고 있는 이유는 오픈소스 생태계가 더 이상 연구실, 취미 개발자, 또는 인프라에 집중된 엔지니어링 팀만을 위한 것이 아니기 때문입니다. 더 많은 통제력, 더 낮은 한계 비용, 그리고 더 적은 벤더 의존성을 원하는 스타트업, 에이전시, 운영자, 그리고 기술 팀에게 실용적인 선택지가 되고 있습니다.
이 글에서는 오픈소스 AI 스택이 실제로 무엇인지, 왜 SaaS의 일부를 대체하기 시작했는지, 가장 취약한 카테고리는 무엇인지, 현대적인 스택의 모습은 어떠한지, 어떤 부분에서 강점을 보이고 어디서 여전히 부족한지, 그리고 회사를 유지보수 프로젝트로 만들지 않고 도입하는 방법에 대해 알아봅니다.
사람들이 오픈소스 AI가 SaaS를 대체한다고 말할 때 실제로 의미하는 것
이 문구는 과장되기 쉽습니다.
오픈소스 AI가 모든 SaaS 기업을 한 번에 대체하는 것은 아닙니다. 핵심 가치를 점점 더 재현할 수 있게 된 워크플로우 특화, 미들웨어 중심, 인터페이스가 가벼운 제품이라는 성장하는 클래스를 대체하고 있는 것입니다.
실질적으로는 다음과 같은 작업을 중심으로 구축된 소프트웨어를 포함합니다:
- 내부 문서에 대한 질문에 답변하기
- 회의록이나 대본 요약하기
- 티켓 분류 및 라우팅
- 보고서나 제안서 생성
- 반복적인 백오피스 작업 자동화
- 리드 및 CRM 데이터 강화
- 내부 코파일럿 구축
- 복잡한 문서에서 구조화된 데이터 추출
- 경량 고객 지원 어시스턴트 생성
- 규칙과 트리거를 통해 도구 연결
이러한 카테고리의 놀랍도록 많은 SaaS 제품이 워크플로우 설계에 깊은 진입 장벽을 가지고 있지 않습니다. 그들의 강점은 종종 패키징, 유통, UX, 그리고 신뢰에서 나오며—대체 불가능한 기술적 핵심에서 나오는 것이 아닙니다.
기술적 핵심이 바로 오픈소스 AI가 더 저렴하게 복제할 수 있게 만드는 부분이기 때문에 이는 중요합니다.
이러한 변화가 지금 일어나고 있는 이유
이는 단지 더 나은 모델에 관한 것이 아닙니다.
다섯 가지 변화가 동시에 일어난 결과입니다.
- 오픈 모델이 이제 많은 비즈니스 작업에 충분히 좋아졌습니다
가장 큰 변화는 오픈 모델이 모든 벤치마크에서 최고의 프론티어 모델을 이긴다는 것이 아닙니다.
더 이상 그럴 필요가 없다는 점입니다.
많은 비즈니스 워크플로우에서 "세계 최고"는 필요하지 않습니다. 팀이 실제로 필요한 것은:
- 일관된 구조화된 출력
- 수용 가능한 추론 능력
- 강력한 요약 능력
- 괜찮은 검색 기반 근거
- 수용 가능한 지연 시간
- 프라이버시 및 배포 통제
입니다.
그 기준은 프론티어 모델의 과대 광고가 암시하는 것보다 훨씬 낮습니다.
많은 사용 사례에서 오픈 모델은 이미 그 기준을 넘어섰습니다.
- 모델 주변의 인프라가 성숙해졌습니다
모델 하나만으로는 SaaS 도구를 대체할 수 없습니다.
모델에 더해:
- 추론 레이어
- 인터페이스
- 검색 시스템
- 자동화 로직
- 로깅
- 권한
- 스토리지
- 평가
를 갖추면 제품처럼 보이기 시작합니다.
주변 생태계가 오픈소스 스택을 실행 가능하게 만드는 요소입니다.
- SaaS 확장이 비용이 많이 들고 운영상 복잡해졌습니다
팀들은 구독 레이어링에 지쳐있습니다.
새로운 도구가 도입될 때마다:
- 또 다른 청구서
- 또 다른 로그인 시스템
- 또 다른 벤더 검토
- 또 다른 데이터 사일로
- 또 다른 통합 표면
- 또 다른 갱신 결정
이 따라옵니다.
하나의 오픈소스 스택이 좁은 범위의 도구 3~6개를 대체할 수 있다면, 경제성은 빠르게 주목을 받기 시작합니다.
- AI 네이티브 워크플로우는 본질적으로 조립식입니다
전통적인 SaaS는 종종 고정된 워크플로우를 가정했습니다.
오픈소스 AI 스택은 구성을 장려합니다.
즉, 기업들은 점점 더 사전 구축된 소프트웨어 가정에 운영을 맞추는 대신, 실제 운영에 맞춰진 시스템을 구축할 수 있습니다.
- 통제가 전략적으로 중요해지고 있습니다
더 많은 팀이 이제 다음에 대해 깊이 신경 쓰고 있습니다:
- 데이터가 어디에 저장되는지
- 어떤 모델 제공업체에 의존하는지
- 대규모 사용 시 비용이 얼마인지
- 벤더를 전환할 수 있는지
- AI 제품의 동작을 검사할 수 있는지
오픈소스 스택은 많은 SaaS 제품이 제공할 수 없는 방식으로 통제권을 제공합니다.
오픈소스 AI에 가장 취약한 SaaS 카테고리
모든 SaaS가 동등하게 취약한 것은 아닙니다.
가장 취약한 카테고리는 일반적으로 네 가지 특성을 공유합니다:
- 워크플로우가 반복적입니다
- 인터페이스가 상대적으로 얇습니다
- "지능"은 대부분 텍스트 변환이나 라우팅입니다
- 모델, 프롬프트, 검색, 자동화를 결합하여 제품을 재현할 수 있습니다
가장 취약한 카테고리
- 내부 지식 어시스턴트
많은 팀이 이제 엔터프라이즈 AI 지식 도구를 평가하는 것보다 내부 문서 기반 채팅 시스템을 더 빨리 구축하고 있습니다.
- AI 글쓰기 및 요약 도구
핵심 제품이 "텍스트를 입력받아 더 나은 텍스트를 출력하는 것"이라면, 복제 장벽은 급격히 낮아졌습니다.
- 기본 지원 코파일럿 및 FAQ 봇
검색, 안전장치, 에스컬레이션이 잘 처리되면, 많은 지원 사용 사례가 더 이상 전문 벤더가 필요할 정도로 기술적으로 복잡하지 않습니다.
- AI 레이어가 있는 워크플로우 자동화 도구
"AI 자동화" 제품의 상당 부분이 오픈소스 오케스트레이션, API, 로컬 또는 호스팅 모델의 조합에 의해 도전받고 있습니다.
- 리드 강화 및 리서치 어시스턴트
이러한 도구는 여전히 신중한 소싱과 규정 준수가 필요하지만, 워크플로우의 많은 부분을 오픈 데이터, 적절한 스크래핑 파이프라인, 강화 API, AI 요약으로 재현할 수 있습니다.
- 문서 추출 및 분류 소프트웨어
이는 주요 카테고리입니다.
많은 구조화된 문서 워크플로우에서 팀은 이제 OCR, 추출 파이프라인, 검증 로직, LLM을 결합하여 비싼 포인트 솔루션을 대체할 수 있습니다.
덜 취약한 카테고리
일부 SaaS는 다음과 같은 요소에 의존하기 때문에 더 방어적입니다:
- 독점적 유통망
- 특화된 규정 준수
- 네트워크 효과
- 규제된 워크플로우
- 깊이 내장된 통합
- 엔터프라이즈 규모의 신뢰 및 감사 가능성
- 독특한 데이터셋 또는 운영 기록 시스템
즉, 오픈소스 AI는 문제가 워크플로우 지능일 때 가장 강력하며, 진입 장벽이 제도적 신뢰, 유통, 또는 인프라 중력일 때는 그렇지 않습니다.
현대적인 오픈소스 AI 스택의 실제 모습
사람들이 "오픈소스 AI 스택"이라고 말할 때, 종종 너무 모호하게 설명합니다.
실제로는 일반적으로 여러 레이어로 구성됩니다.
- 모델 레이어
언어 또는 멀티모달 지능이 위치하는 곳입니다.
일반적인 선택지는 다음과 같습니다:
- 추론 및 생성을 위한 오픈 가중치 LLM
- 저비용 분류 및 추출을 위한 더 작은 로컬 모델
- 임베딩, 전사, OCR, 재순위화를 위한 특화된 모델
핵심적인 변화는 모델이 더 이상 제품의 전부가 아니라는 점입니다. 더 큰 시스템의 한 레이어일 뿐입니다.
- 추론 레이어
이는 실제로 모델을 서빙하는 런타임입니다.
일반적인 패턴은 다음과 같습니다:
- 실험 및 비공개 워크플로우를 위한 로컬 런타임
- 팀을 위한 자체 호스팅 추론 서버
- GPU 관리가 필요하지 않을 때 호스팅 오픈 모델 제공업체
이 레이어는 비용, 속도, 운영 복잡성, 프라이버시 태세를 결정합니다.
- 검색 및 데이터 레이어
이는 일반 모델을 비즈니스 도구로 바꾸는 요소입니다.
일반적인 구성 요소:
- Postgres 또는 기타 구조화된 스토리지
- 의미론적 검색을 위한 벡터 검색
- 문서 저장소 및 객체 스토리지
- 메타데이터 및 필터링 시스템
- 데이터 커넥터 및 수집 파이프라인
AI 제품 유용성의 큰 부분은 기본 모델이 아닌 이 레이어에서 비롯됩니다.
- 오케스트레이션 레이어
이 레이어는 시스템의 동작 방식을 제어합니다.
다음을 결정합니다:
- 모델을 호출할 시기
- 사용할 모델
- 컨텍스트를 검색하는 방법
- 도구를 호출할 시기
- 단계를 연결하는 방법
- 실패 및 재시도를 처리하는 방법
이곳에서 자동화 플랫폼, 워크플로우 엔진, 에이전트 프레임워크가 가치를 발휘합니다.
- 인터페이스 레이어
이는 사용자가 실제로 만지는 부분입니다.
다음과 같을 수 있습니다:
- 채팅 UI
- 대시보드
- 브라우저 확장 프로그램
- 내부 관리 도구
- Slack 봇
- API 엔드포인트
- 양식 기반 워크플로우 화면
오픈소스 스택이 이제 경쟁할 수 있는 핵심 이유는 많은 비즈니스 도구가 가치를 전달하기 위해 예외적으로 복잡한 UI를 필요로 하지 않기 때문입니다.
- 관찰 가능성 및 평가 레이어
이는 장난감과 신뢰할 수 있는 시스템의 차이를 만듭니다.
다음을 알아야 합니다:
- 어떤 프롬프트가 실행되었는지
- 어떤 컨텍스트가 검색되었는지
- 요청이 얼마나 오래 걸렸는지
- 추론 비용이 얼마인지
- 무엇이 실패했는지
- 출력 품질이 향상되었는지 또는 저하되었는지
AI 제품이 성숙해짐에 따라, 이 레이어는 스택에서 가장 전략적으로 중요한 부분 중 하나가 되고 있습니다.
스택이 여러 도구를 동시에 대체하는 실제 예시
소규모 영업 또는 운영 팀을 생각해보십시오.
과거에는 다음과 같은 항목에 대해 별도로 비용을 지불했을 수 있습니다:
- 회의 전사
- AI 요약
- CRM 강화
- 내부 검색
- 제안서 초안 작성
- 워크플로우 자동화
- 지원 문서 검색
현대적인 오픈소스 스택은 이들 중 많은 부분을 하나의 내부 시스템으로 결합할 수 있습니다.
예를 들어:
- 통화를 위한 전사 모델 또는 API
- 플레이북, 대본, 제안서를 위한 문서 저장소
- 지식 검색을 위한 벡터 검색
- 요약을 CRM으로 라우팅하는 워크플로우 엔진
- 후속 초안을 생성하는 프롬프트 템플릿
- 팀 접근을 위한 대시보드 또는 채팅 UI
- 답변 품질 및 워크플로우 신뢰성을 측정하는 평가 레이어
하나의 스택으로 여러 좁은 도구를 대체하면서도 출력 형식, 모델 선택, 비용 동작에 대해 더 많은 통제권을 팀에 제공할 수 있습니다.
이것이 바로 많은 SaaS 카테고리가 취약한 이유입니다.
오픈소스 AI가 이론적으로 강력하기 때문이 아닙니다.
여러 소프트웨어 구매를 하나의 조립식 시스템으로 점점 더 통합할 수 있기 때문입니다.
현재 가장 일반적인 오픈소스 AI 스택 패턴
팀마다 성숙도와 목표에 따라 다른 버전의 스택을 채택합니다.
패턴 1: 솔로 빌더 스택
인디 해커, 기술 창작자, 컨설턴트 사이에서 흔합니다.
일반적인 구성 요소:
- 로컬 또는 저비용 모델 런타임
- 간단한 데이터베이스
- 워크플로우 자동화 도구
- 경량 프론트엔드
- 하나의 검색 레이어
- 하나의 배포 대상
이 스택은 속도와 비용 규율에 최적화되어 있습니다.
패턴 2: 스타트업 내부 도구 스택
내부 코파일럿이나 프로세스 자동화를 구축하는 회사에서 흔합니다.
일반적인 구성 요소:
- 호스팅 또는 자체 호스팅 모델 레이어
- Postgres + 벡터 지원
- 문서 수집
- 인증 및 역할 기반 접근
- 워크플로우 엔진
- 로깅 및 추적
- 관리 대시보드
이 스택은 빠른 내부 활용도에 최적화되어 있습니다.
패턴 3: 에이전시 또는 운영자 스택
이 패턴은 종종 자신이나 고객을 위해 여러 반복적인 SaaS 도구를 대체하는 에이전시에서 사용됩니다.
일반적인 사용 사례:
- 리드 리서치
- 제안서 생성
- 보고 자동화
- 고객 지원 어시스턴트
- 콘텐츠 워크플로우
- 접수 및 라우팅 시스템
이 스택은 프로젝트 간 재사용에 최적화되어 있습니다.
패턴 4: 제품화된 AI SaaS 대체 스택
이는 팀이 스택을 내부적으로만 사용하는 것을 넘어 제품으로 전환할 때입니다.
이 시점에서 스택에는 종종 다음이 추가됩니다:
- 결제
- 멀티테넌시
- 세분화된 권한
- 더 강력한 모니터링
- 피드백 및 QA 워크플로우
- 더 강력한 데이터 거버넌스
이것이 오픈소스 구성이 AI 중심 SaaS 기업에 직접적인 위협이 되는 지점입니다.
이러한 스택에서 계속 등장하는 도구들
구체적인 스택은 끊임없이 변하지만, 일부 카테고리는 반복적으로 나타납니다.
레이어별 일반적인 구성 요소
레이어
일반적인 오픈소스 선택
중요한 이유
모델
오픈 가중치 LLM, 임베딩 모델, 재순위화기
핵심 추론 및 검색 품질
추론
Ollama, vLLM, 자체 호스팅 런타임, 오픈 모델 API
비용, 프라이버시, 서빙 유연성
데이터베이스
Postgres, pgvector, 문서/객체 스토리지
구조화 및 의미론적 메모리
자동화
n8n 및 유사한 워크플로우 도구
시스템 연결 및 수동 작업 감소
앱 레이어
Next.js, React, 내부 대시보드, API
경량 제품 표면
채팅/검색 UI
Open WebUI, 사용자 정의 인터페이스
내부 AI 워크플로우에 대한 빠른 접근
관찰 가능성
Langfuse, 추적 도구, 사용자 정의 로그
신뢰성, 품질, 반복 속도
인증/백엔드
Supabase, 사용자 정의 인증, 관리형 DB 레이어
빠른 제품 조립
평가
프롬프트 테스트, 회귀 테스트 스위트, 루브릭 채점
조용한 품질 저하 방지
중요한 점은 각 도구의 정확한 브랜드 이름이 아닙니다.
중요한 점은 모든 주요 레이어에 이제 신뢰할 수 있는 오픈소스 또는 오픈 표준 옵션이 있다는 것입니다.
그것이 구축 대 구매 방정식을 변화시킵니다.
SaaS가 더 쉬워 보일 때도 팀이 오픈소스 경로를 선택하는 이유
언뜻 보면 SaaS가 여전히 더 단순해 보입니다.
종종 그렇습니다.
그렇다면 왜 더 많은 팀이 더 어려운 길을 선택하고 있을까요?
적절한 상황에서는 더 어려운 길이 전략적으로 더 낫기 때문입니다.
- 장기적 비용 절감
하나의 구독은 저렴해 보입니다.
일곱 개의 중복되는 구독은 그렇지 않습니다.
오픈소스 스택은 종종 설정 비용이 더 높고 한계 비용이 더 낮습니다. 특히 이미 내부에 기술 인재가 있는 팀의 경우 더욱 그렇습니다.
- 더 나은 맞춤 설정
대부분의 AI 워크플로우는 팀마다 동일하지 않습니다.
SaaS 도구는 종종 팀을 중간 수준의 워크플로우로 강요합니다.
구성된 시스템은 팀이 자신만의 로직, 프롬프트, 승인, 검색 동작을 인코딩할 수 있게 합니다.
- 프라이버시 및 데이터 통제
많은 기업이 민감한 내부 데이터를 일련의 타사 도구를 통해 보내는 것에 대해 점점 더 불편해하고 있으며, 스택의 더 많은 부분을 자체 호스팅하거나 관리할 수 있습니다.
- 벤더 종속 감소
오픈소스 스택은 구성 요소를 더 쉽게 전환할 수 있게 합니다.
다음을 변경할 수 있습니다:
- 모델 제공업체
- 추론 전략
- UI 레이어
- 자동화 엔진
- 평가 프로세스
전체 시스템을 처음부터 다시 구축할 필요 없이 말입니다.
- 더 빠른 학습 루프
스택을 소유하면 워크플로우가 실제로 어디서 실패하는지 알게 됩니다.
이는 종종 너무 일찍 세련된 추상화를 구매하는 것보다 더 가치 있습니다.
SaaS가 여전히 명확히 우세한 분야
성숙한 분석은 또한 이것을 명확히 말해야 합니다:
SaaS가 여전히 더 현명한 결정인 경우가 많이 있습니다.
SaaS는 다음이 필요할 때 여전히 우세합니다:
- 최소한의 엔지니어링 노력으로 즉시 배포
- 규정 준수, SLA, 조달 준비 상태
- 엔터프라이즈 지원 및 명확한 책임 소재
- 비기술 팀을 위한 고도로 세련된 사용자 경험
- 깊은 독점적 통합
- 맞춤형 소유권을 정당화할 만큼 전략적이지 않은 워크플로우
- 워크플로우 레이어가 아닌 기록 시스템
이것이 최고의 운영자가 독단적이지 않은 이유입니다.
오픈소스가 유행이기 때문에 SaaS를 대체하지 않습니다.
경제성, 통제력, 제품 유연성이 그것을 정당화할 때 SaaS를 대체합니다.
팀이 오픈소스 AI를 도입할 때 저지르는 가장 큰 실수
너무 많은 것을 너무 일찍 대체하려고 하는 것입니다.
이는 일반적으로 두 가지 나쁜 결과 중 하나를 초래합니다.
결과 1: 스택이 내부 과학 프로젝트가 됩니다
팀은 비즈니스 가치를 제공하기 전에 인프라를 조립하는 데 몇 달을 보냅니다.
결과 2: 취약한 프로토타입을 출시하고 그것을 제품으로 착각합니다
데모에서는 워크플로우가 작동하지만, 관찰 가능성, 권한, 평가, 복구 로직이 무시되었기 때문에 실제 사용 시 실패합니다.
이 스택을 올바르게 도입하는 방법은 전체 소프트웨어 스택을 처음부터 재구축하는 것이 아닙니다.
다음 조건을 충족하는 하나의 워크플로우에서 시작하는 것입니다:
- SaaS 비용이 명확한 경우
- 워크플로우가 반복적인 경우
- 로직이 설명 가능한 경우
- 통제의 ROI가 높은 경우
그것이 오픈소스 AI가 가장 잘 수행되는 분야입니다.
스택을 도입하는 더 현명한 방법
가장 강력한 팀은 일반적으로 순서를 따릅니다.
1단계: 마찰이 큰 하나의 워크플로우 식별
좋은 예시:
- 문서 및 녹음본에 대한 내부 검색
- 반복적인 보고서 생성
- 리드 자격 부여 및 강화
- 지원 초안 작성
- 문서 추출
2단계: 먼저 지능 레이어만 재구축
모든 것을 대체하지 마십시오.
가장 비용이 많이 들거나 유연성이 가장 낮은 부분을 대체하는 것으로 시작하십시오.
3단계: 필요하다고 느껴질 때보다 일찍 관찰 가능성 추가
다음을 기록하십시오:
- 입력
- 출력
- 검색 컨텍스트
- 실패
- 비용
- 지연 시간
이것 없이는 시스템이 개선되고 있는지 알 수 없습니다.
4단계: 인터페이스를 간단하게 유지
작동하는 기본 UI가 출시를 지연시키는 복잡한 UI보다 낫습니다.
5단계: 스택을 확장하기 전에 비즈니스 가치 입증
하나의 워크플로우가 작동하면 신중하게 확장하십시오.
이것이 오픈소스 AI 스택을 기술적 쇼가 아닌 운영적 레버리지로 만드는 방법입니다.
SaaS에 대한 진정한 경쟁 위협은 모델이 아닙니다
구성입니다.
많은 사람들이 여전히 놓치고 있는 전략적 아이디어입니다.
SaaS 기업은 주로 하나의 더 나은 모델에 의해 위협받는 것이 아닙니다.
그들은 기업이 점점 더 다음 요소로 자신만의 시스템을 구성할 수 있는 세상에 의해 위협받고 있습니다:
- 오픈 모델
- 오픈 인프라
- 유연한 자동화
- 상용 데이터베이스
- 경량 인터페이스
- 재사용 가능한 프롬프트 및 평가 레이어
이것이 정상이 되면, 중심이 이동합니다.
승리하는 제품은 더 이상 자동으로 가장 예쁜 대시보드를 가진 제품이 아닙니다.
가장 적응하기 쉽고, 운영 비용이 가장 저렴하며, 기존 워크플로우에 통합하기 가장 덜 고통스러운 제품일 수 있습니다.
이는 경쟁 환경을 실질적으로 변화시킵니다.
창업자와 운영자를 위한 의미
지금 소프트웨어를 구축하거나 구매하고 있다면, 실용적인 교훈은 간단합니다.
모든 AI 워크플로우 문제를 소프트웨어 조달 문제로 취급하는 것을 중단해야 합니다.
때로는 여전히 그렇습니다.
하지만 점점 더, 그것은 스택 설계 문제가 되고 있습니다.
즉, 물어볼 가치가 있는 질문은 다음과 같습니다:
- 이 워크플로우는 소유할 만큼 전략적인가?
- 우리는 지금 재현 가능한 무언가에 대해 SaaS 가격을 지불하고 있는가?
- 하나의 조립식 내부 스택이 여러 포인트 도구를 대체할 수 있는가?
- 진정한 진입 장벽은 벤더에 있는가, 아니면 단지 실행 속도와 패키징에 있는가?
- 세련된 외부 제품이 필요한가, 아니면 신뢰할 수 있는 내부 시스템만으로 충분한가?
이러한 질문을 잘 던지는 팀은 향후 몇 년 동안 훨씬 더 나은 기술 결정을 내릴 것입니다.
마지막 생각
오픈소스 AI 스택이 모든 SaaS를 대체하는 것은 아닙니다.
하지만 소프트웨어 시장이 새로운 현실로 강제될 만큼 충분히 대체하고 있습니다.
점점 더 많은 도구가 편리하다는 이유만으로 더 이상 안전하지 않습니다.
핵심 가치가 오픈 모델, 검색, 오케스트레이션, 스토리지, 얇은 인터페이스로 재구축될 수 있다면, 그들의 카테고리는 압박을 받고 있습니다—그들이 인정하든 말든.
그렇다고 모든 회사가 모든 것을 자체 호스팅하기 위해 서둘러야 한다는 뜻은 아닙니다.
이는 오래된 가정인—먼저 사고, 절대적으로 필요할 때만 구축하라—이 약해지고 있다는 것을 의미합니다.
AI 중심 워크플로우에서는 새로운 가정이 등장하고 있습니다:
로직이 재현 가능할 때는 먼저 구성하고, 신뢰, 규모, 또는 복잡성이 그것을 진정으로 정당화할 때만 구매하라.
그것이 변화입니다.
그리고 현대 소프트웨어의 많은 부분에 대해, 그것은 이제 막 시작되었을 뿐입니다.
