하네스가 곧 회사다: SaaS의 종말이 아닌 '비즈니스 하네스'로의 진화와 Top-Level 소유 전략

하네스가 곧 회사다: SaaS의 종말이 아닌 '비즈니스 하네스'로의 진화와 Top-Level 소유 전략

핵심 요약: AI 코딩과 자율 에이전트의 급부상으로 일각에서는 "모든 소프트웨어를 직접 바이브 코딩할 수 있으니 기존 SaaS는 모두 소멸할 것"이라는 극단적인 SaaS 종말론을 제기합니다. 하지만 이는 비즈니스와 소프트웨어 엔지니어링의 본질을 간과한 오판입니다. 현실에서 벌어지고 있는 진짜 패러다임 전환은 SaaS의 소멸이 아니라, "기업 자체가 무상태(Stateless) LLM을 둘러싼 인프라·맥락·검토 루프 전체, 즉 '비즈니스 하네스(Business Harness)'로 변모하고 있다"는 사실입니다. 본 글에서는 Shrivu Shankar의 기념비적인 통찰을 바탕으로 SaaS 4단계 하네스 진화 모델, AI 저품질 양산을 막는 안목 보유자(Taste-holder)와 표본 검토 아키텍처, 그리고 결코 외주화해서는 안 되는 최상위 하네스(Top-Level Harness)의 소유 전략을 소프트웨어 아키텍처 관점에서 심도 있게 분석합니다.

---

1. 프롤로그: "SaaS 종말론" 뒤에 숨은 진짜 현실

최근 테크 씬에서는 자극적인 예언이 넘쳐납니다.

"주니어 엔지니어가 2주 만에 Jira를 복제했다."
"이제 필요한 도구는 직접 에이전트로 만들면 되니 엔터프라이즈 SaaS는 끝났다."

과연 그럴까요? 수천억 규모의 엔터프라이즈 기업들이 고가의 SaaS 솔루션을 구독하는 이유는 단지 '기능을 구현하는 코드 덩어리'가 없어서가 아닙니다.

진짜 이유는 수없이 얽힌 법적 규제, 결제 실패와 데이터 정합성 보장, 24/7 장애 대응 책임, 보안 컴플라이언스(SOC2, GDPR), 그리고 끊임없이 변화하는 복잡한 현실 세계의 엣지 케이스들을 검증된 전문 조직에게 합리적인 비용으로 외주화(Outsourcing)하기 위함입니다. 코드가 공짜가 된다고 해서 이 무거운 운영 책임과 시스템 신뢰의 비용까지 0이 되는 것은 아닙니다.

[SaaS에 대한 오해 vs 현실]

오해 (코드 중심적 시각):
┌────────────────────────┐
│ UI + DB + 비즈니스 로직 │  ───►  "AI로 일주일 만에 짜면 끝 아닌가?"
└────────────────────────┘

현실 (비즈니스 운영 시스템 시각):
┌─────────────────────────────────────────────────────────────────────────┐
│ 엣지 케이스 예외 처리 · 컴플라이언스 · 데이터 정합성 · 장애 책임 · 보안 │
│ + 조직의 도메인 지식 축적 · 지속적인 인간 피드백 검토 루프              │
└─────────────────────────────────────────────────────────────────────────┘
  ▲ 이 모든 거버넌스와 신뢰를 지탱하는 런타임 환경이 바로 '하네스(Harness)'다.

따라서 AI 에이전트 시대에 SaaS는 죽는 것이 아닙니다. 오히려 SaaS 기업의 내부 구조와 동작 방식이 근본적으로 변모하고 있습니다.

제품을 만드는 노동은 사람의 손에서 에이전트로 이동하고, 파운데이션 모델(LLM)은 규격화된 부품으로 전락하며, "회사라는 조직 자체가 모델의 입출력을 제어하고 지식을 주입하며 사람의 안목을 적재적소에 배치하는 거대한 하네스"로 재편되고 있습니다.

---

2. 하네스(Harness)의 재정의: 협의 vs 광의

'하네스'라는 단어는 원래 야생마나 맹견을 제어하기 위해 씌우는 가죽 마구(안장/굴레)에서 유래했습니다. 소프트웨어 공학에서는 강력하지만 어디로 튈지 모르는 비결정적 파운데이션 모델을 통제하는 제어 틀을 의미합니다.

하지만 하네스를 어떤 범위로 정의하느냐에 따라 엔지니어링 전략은 완전히 달라집니다.

🔍 클릭하여 확대

flowchart TB
    subgraph BroadHarness["🏢 광의의 비즈니스 하네스 (The Business Harness)"]
        direction TB
        DomainContext["📚 기업 독점 도메인 맥락 / 지식베이스"]
        GovPolicy["🛡️ 거버넌스 · 보안 · 출시 게이트 (Ship Criteria)"]

        subgraph MetaHarness["⚙️ 메타 하네스 (Meta-Harness / Orchestrator)"]
            subgraph SpecHarness["1. 기획 하네스 (Spec)"]
                S_Agent["요구사항 수집 & 명세 작성"]
            end
            subgraph CodeHarness["2. 구현 하네스 (Code)"]
                C_Agent["코드 작성 & 단위 테스트"]
            end
            subgraph ReviewHarness["3. 검증 하네스 (Review)"]
                R_Agent["정적 분석 & 회귀 테스트"]
            end
            SpecHarness --> CodeHarness --> ReviewHarness
        end

        subgraph TasteHolders["👤 안목 보유자 (Human Taste-holders)"]
            T1["PM / 도메인 리드 (표본 검토)"]
            T2["아키텍트 / 시니어 엔지니어"]
            T3["디자인 / 브랜드 가디언"]
        end

        DomainContext --> MetaHarness
        GovPolicy --> MetaHarness
        MetaHarness <-->|안목 주입 & 예외 에스컬레이션| TasteHolders
    end

    subgraph LLM["🧠 교체 가능한 무상태 모델 (Stateless LLM APIs)"]
        M1["Claude / GPT / Gemini / 로컬 오픈모델"]
    end

    MetaHarness <==>|도구 호출 & 프롬프트| LLM
  

1) 협의의 하네스 (Narrow Harness)

개발자들이 흔히 떠올리는 하네스입니다. LangGraph, AutoGen 같은 프레임워크나 Codex, Claude Code, Cursor 같은 코딩 에이전트 툴체인이 여기에 해당합니다.
- 상태를 보존하지 않는(Stateless) 단일 LLM API 호출에 로컬 셸, 파일 시스템, MCP 도구, 대화 세션 상태를 부착하여 하나의 특정 작업을 끝마치도록 돕는 런타임 스캐폴딩(Runtime Scaffolding)입니다.

2) 광의의 하네스 (Broad Harness: The Business Harness)

Shrivu Shankar가 제시한 개념으로, 기업이 보유한 인프라, 비즈니스 인터페이스, 고객 맥락, 상태 머신, 권한 체계, 그리고 인간의 검토 루프 전체를 포괄합니다.
- 이 관점에서 회사는 개별 업무를 담당하는 서브 하네스들(요구사항 명세 하네스, 코드 작성 하네스, 품질 검증 하네스)의 결합체이며,
- 이 하위 하네스들의 작업 시점과 우선순위를 조율하는 총괄 시스템을 메타 하네스(Meta-harness)라고 부릅니다.
- 결국 제품은 모델의 출력물이 되고, 기업의 실체는 모델에 맥락을 제공하고 결과를 검증하는 비즈니스 하네스 그 자체가 됩니다.

---

3. SaaS 기업의 4단계 하네스 진화 로드맵

대부분의 소프트웨어 서비스 기업은 에이전트 도입 수준에 따라 다음 4단계의 질적 전환을 겪게 됩니다.

단계	운영 모델 (Paradigm)	주체와 하네스의 관계	인간의 주된 역할
1단계	전통적 SaaS (Legacy)	하네스 부재	사람이 직접 기획, 코딩, 테스트, 고객 지원 수행
2단계	페어링 (Copilot / Assistant)	개인이 하네스를 운용 (Individuals operate harnesses)	엔지니어·PM·영업 담당자가 1:1로 에이전트를 도구 삼아 생산성 가속
3단계	클라우드 비동기 위임 (Background Agents)	개인이 하네스를 조율 (Individuals orchestrate harnesses)	수십 개의 클라우드 백그라운드 에이전트에게 프롬프트로 작업을 발주하고 결과 검토
4단계	자율형 비즈니스 하네스 (Proactive Systems)	하네스가 개인을 조율 (Harnesses orchestrate individuals)	에이전트가 선제적으로 과업을 발굴·실행하고, 사람은 표본 검토 및 안목 집중

[하네스 성숙도에 따른 주도권의 역전]

1~2단계: 사람 ─────────────────────► 도구 / 에이전트
         (사람이 직접 과업을 설계하고 지시함)

3단계:   사람 ───[오케스트레이션]───► 백그라운드 에이전트 군단
         (사람이 프롬프트를 작성하고 전수 검토를 수행함)

4단계:   비즈니스 하네스 ───────────► 사람 (Taste-holder)
         (에이전트가 선제적으로 일하고, 인간의 안목이 필요한 지점만 호출함)

이 로드맵에서 가장 극적인 변곡점은 3단계에서 4단계로 넘어갈 때 발생합니다.

• 3단계까지는 여전히 인간이 일을 정의하고 에이전트에게 시킵니다. 하지만 엔지니어 한 명이 수십 개의 비동기 에이전트를 돌리기 시작하면, '에이전트의 산출물을 전수 검토(Consistent Review)하는 일' 자체가 극심한 인지 병목으로 작용합니다.
• 4단계에 도달하면 이 병목을 해소하기 위해 주도권이 역전됩니다. 에이전트가 모니터링 로그, 고객 피드백, 코드베이스 이슈를 감지하여 스스로 작업을 생성하고 해결책을 도출합니다.
• 이때 인간은 모든 과정을 일일이 지켜보는 것이 아니라, 하네스가 지정한 '결정적 품질 게이트'에서 표본 검토(Sampled Review)만을 수행하게 됩니다.

---

4. "슬롭(Slop) 공장"의 함정과 안목 보유자(Taste-holder)

많은 이들이 4단계의 자율 에이전트 기업 모델을 들었을 때 즉각적으로 반감을 표합니다:

"AI가 기획하고, AI가 코딩하고, AI가 셀프 리뷰하면 결국 인터넷에 굴러다니는 저품질 쓰레기 코드와 무의미한 기능들(AI Slop)만 대량 양산하는 공장이 되지 않겠는가?"

이 비판은 정곡을 찌르는 지적이지만, '완전 무인 운영(Lights-out Automation)'이라는 비현실적 전제를 깔고 있을 때만 유효합니다. 훌륭한 비즈니스 하네스는 모든 사람을 해고하고 스위치를 내리는 무인 공장이 아닙니다.

오히려 "인간의 주의력(Human Attention)이 비즈니스 가치에 가장 결정적인 영향을 미치는 극소수의 지점에만 인간의 에너지를 몰아주는 선택적 배분 장치"입니다.

🔍 클릭하여 확대

sequenceDiagram
    autonumber
    actor Customer as 고객 / 시장
    participant Agent as 🤖 선제적 에이전트 (Proactive Agent)
    participant Harness as ⚙️ 비즈니스 하네스 (가드레일 & 필터)
    actor TasteHolder as 👤 안목 보유자 (Taste-holder)

    Customer->>Agent: VOC, 미팅 질의, 사용 로그 유입
    Agent->>Agent: 100건의 패턴 분석 & 기능 가설 도출
    Agent->>Harness: 기능 시안 A/B/C 및 ADR 초안 제출
    Harness->>Harness: 기본 정책·보안·단위테스트 결정론적 필터링
    alt 일상적/경미한 변경 (낮은 리스크)
        Harness-->>Customer: 자동 롤아웃 (Auto-ship with monitoring)
    else 핵심 아키텍처 / 브랜드 / UX 영향도 높음
        Harness->>TasteHolder: 🎯 선별된 상위 2개 핵심 대안에 대한 안목 검토 요청
        TasteHolder->>Harness: 최종 승인 및 미묘한 설계 피드백 반영
        Harness-->>Customer: 정식 배포
    end
  

안목 보유자(Taste-holder)의 실전 배치 모델

이 구조에서 핵심 인재의 역할은 '단순 반복 작업자'에서 안목 보유자(Taste-holder)로 승격됩니다:

1. 제품 안목 (Product Taste-holder):
   - 에이전트가 고객 미팅 녹음 50건을 분석하고 자주 나오는 불만을 종합하여 3가지 기능 데모 프로토타입을 합성해 둡니다.
   - 제품 리드는 50시간의 미팅에 일일이 들어갈 필요 없이, 합성된 데모를 보고 "이 방향이 우리 제품의 철학에 부합하는가?"라는 본질적인 안목만 행사합니다.

2. 엔지니어링 안목 (Engineering Taste-holder):
   - 에이전트가 성능 병목 구간을 프로파일링하여 데이터베이스 샤딩 및 쿼리 최적화 PR 10개를 작성하고 벤치마크 결과를 붙입니다.
   - 시니어 아키텍트는 문법이나 사소한 오타를 보는 대신, "이 시스템 구조가 3년 뒤 기술 부채를 유발하지 않는가?"라는 아키텍처적 결정을 검토합니다.

3. 디자인/브랜드 안목 (Design Taste-holder):
   - 에이전트가 디자인 시스템 컴포넌트를 조합해 20가지 UI 변형을 만들고 A/B 테스트를 시뮬레이션합니다.
   - 디자인 리드는 상위 후보 2개를 보고 브랜드의 감성과 사용자 여정의 일관성을 최종 승인합니다.

이것은 과거 제조업을 혁신했던 도요타 생산 시스템(TPS)의 지능화 버전입니다. 라인은 컨베이어 벨트(에이전트)를 타고 24시간 멈추지 않고 돌아가지만, 이상이 감지되거나 중요한 품질 기준을 넘어야 할 때만 안돈 코드(Andon Cord)를 당겨 장인의 안목을 개입시키는 것입니다.

---

5. 경쟁 우위의 대전환: 최상위 하네스(Top-Level Harness)를 소유하라

파운데이션 모델 시장의 양상을 보면 명확한 사실이 하나 있습니다. 모델 그 자체는 결코 영구적인 해자(Moat)가 될 수 없다는 점입니다.

오늘 최고인 모델도 3개월 뒤면 더 싸고 성능 좋은 경쟁 모델에 자리를 내어줍니다. AI 네이티브 스타트업이 모델 API 래퍼 수준에 머물러 있다면, 그 회사의 기술적 방어선은 사실상 0에 가깝습니다.

그렇다면 진정한 차별화와 해자는 어디에 존재하는가? 바로 하네스 설계 능력입니다.

[차별화 요소의 이동]

전통적 SaaS 시대:
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  신뢰 (Trust)   │     │ 유통 (Channel)  │     │ 도메인 맥락     │
│ 기능 안정성 보장│     │ 영업 인력의 크기│     │ 데이터베이스 축적│
└─────────────────┘     └─────────────────┘     └─────────────────┘

비즈니스 하네스 시대:
┌─────────────────────────────────┐
│ 하네스가 배포 조건(Ship Gate)을 얼마나 정밀하게 규정하는가? (~신뢰)
├─────────────────────────────────┤
│ 하네스가 피드백 루프를 얼마나 초저지연으로 순환시키는가? (~효과성)
├─────────────────────────────────┤
│ 조직 내부의 암묵지와 정책을 하네스가 어떻게 주입·학습하는가? (~도메인 맥락)
└─────────────────────────────────┘

소유해야 할 하네스 vs 플러그인할 하네스

여기서 기업 아키텍처의 가장 중대한 의사결정이 발생합니다. "모든 것을 사내에서 직접 만들어야 하는가?"

그렇지 않습니다. 정답은 "최상위 하네스는 반드시 소유하고, 하위 워크플로는 벤더 제품으로 플러그인(Swap)한다"입니다.

구분	최상위 하네스 (Top-Level Harness)	워크플로 하위 하네스 (Sub-Harness)
역할	무엇을 만들지 결정하고 결과를 최종 검토하는 Outer Loop	명세를 받아 테스트된 PR을 만드는 등의 Inner Loop
소유 여부	무조건 자체 개발 및 소유 (In-house Core)	시장의 우수한 서드파티 벤더 제품으로 대체 가능
외주화 시 위험	비즈니스 모델 전체가 범용 상품화(Commoditized)되어 소멸	벤더 종속성 최소화 상태에서 최신 기술로 손쉬운 교체 이점
대표 사례	Ramp, Stripe, DoorDash 사내 AI 플랫폼	코드 생성 에이전트, CI 자동화 린터, 테스트 생성 도구

🔍 클릭하여 확대

flowchart LR
    subgraph InHouse["🏢 기업 고유 자산 (절대 외주화 금지)"]
        TopHarness["👑 Top-Level Harness<br>(우선순위 결정 & Taste-holder 검토)"]
    end

    subgraph SwappableVendors["🔌 교체 가능한 외부 벤더 생태계"]
        V1["벤더 A: Spec-to-PR"]
        V2["벤더 B: CRM 자동화"]
        V3["벤더 C: 보안 스캐닝"]
    end

    TopHarness -->|작업 명세 위임| V1
    TopHarness -->|이벤트 트리거| V2
    TopHarness -->|정적 검사 위임| V3

    V1 -->|결과물 반환| TopHarness
    V2 -->|로그 반환| TopHarness
    V3 -->|보안 리포트 반환| TopHarness

    style TopHarness fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#ffffff
    style InHouse fill:#f8fafc,stroke:#94a3b8,stroke-dasharray: 5 5
  

Stripe, Ramp, DoorDash 같은 실리콘밸리 최고의 테크 기업들이 왜 시중에 넘쳐나는 상용 AI 개발 도구들을 놔두고 막대한 엔지니어링 리소스를 투입해 사내 AI 개발 하네스를 직접 구축하고 있을까요?

그들이 '기술 오타쿠'라서가 아닙니다. 외부 벤더의 SDLC 도구가 자기네 도메인 인터페이스를 지원할 때까지 기다리는 순간 제품 진화의 속도가 벤더의 로드맵에 종속되기 때문입니다.

더욱이 비즈니스의 시작(무엇을 만들 것인가)과 끝(어떻게 검증하고 출하할 것인가)을 관장하는 Outer Loop를 외부 서비스에 넘겨주는 순간, 그 기업은 언제든 대체 가능한 껍데기 회사로 전락한다는 사실을 정확히 꿰뚫고 있기 때문입니다.

---

6. 엔지니어링 실무자를 위한 4대 아키텍처 제언

기업을 비즈니스 하네스로 진화시키기 위해 소프트웨어 엔지니어링 팀이 지금 당장 구축해야 할 구체적인 아키텍처 원칙은 다음과 같습니다.

1) 내부 시스템의 완전한 헤드리스(Headless)화와 표준 인터페이스

• 백그라운드 에이전트가 사내 소프트웨어를 직접 조작하려면 사람이 클릭하는 GUI에 갇혀 있어서는 안 됩니다.
• 사내의 모든 핵심 도구(배포 시스템, 데이터 분석기, 고객 관리망)는 API는 물론, 에이전트가 직접 탐색하고 도구로 호출할 수 있는 MCP(Model Context Protocol) 인터페이스를 일급 시민(First-class citizen)으로 제공해야 합니다.

2) 결정론적 가드레일(Deterministic Assert)과 LLM의 계층 분리

• LLM에게 모든 판단을 맡기면 반드시 환각이나 규정 위반이 발생합니다.
• 하네스는 결정론적 코드(정규식, 스키마 검증, 권한 체크, 단위 테스트)를 최전방 1차 방어선으로 배치하고, 그 통과물에 한해서만 LLM 추론과 인간 안목 보유자의 검토를 요청하는 다계층 구조(Multi-tier Architecture)를 유지해야 합니다.

3) 일회성 프롬프트가 아닌 '영구 회귀 테스트 스위트' 축적

• 에이전트가 오류를 범했을 때 프롬프트에 "앞으로는 이러지 마"라고 한 줄 추가하는 것은 최악의 안티패턴입니다.
• 실패 사례는 즉시 하네스의 결정론적 회귀 테스트 케이스나 영구 메모리 저장소(예: Memento / 벡터 온톨로지)로 등록되어, 다음 세대 파운데이션 모델로 교체되더라도 동일한 실수를 원천 차단할 수 있는 조직적 자산으로 승격되어야 합니다.

4) 조직도를 '하네스 중심의 안목 배치도'로 재설계

• 팀원의 가치는 하루에 코드를 몇 줄 짜느냐로 측정되지 않습니다.
• 하네스가 생성해 낸 방대한 산출물 속에서 핵심 아키텍처 결함과 고객 가치를 단 5분의 표본 검토로 식별해 낼 수 있는 '안목(Taste)의 날카로움'이 조직 구성원의 핵심 경쟁력이 됩니다.

---

7. 마치며: 모델은 부품이고, 하네스가 곧 회사다

과거 온프레미스 서버를 사서 직접 인프라를 구축하던 기업들이 AWS 클라우드로 전환하면서 완전히 새로운 아키텍처를 맞이했듯, 지금 우리는 소프트웨어 개발과 비즈니스 운영의 모든 축이 에이전틱 하네스로 이동하는 거대한 지각변동의 한가운데 서 있습니다.

SaaS의 종말을 두려워할 필요도, AI가 모든 것을 알아서 해줄 것이라는 맹목적인 무인화 환상에 빠질 필요도 없습니다.

• 파운데이션 모델은 언제든 갈아 끼울 수 있는 저렴한 전기이자 연료입니다.
• 그 전기를 끌어와 우리 조직만의 독점적 데이터와 결합하고, 가드레일로 안전을 확보하며, 장인의 안목을 배치해 가치를 창출하는 제어 시스템—즉 '하네스'를 소유한 기업만이 AI 시대의 유일무이한 승자가 될 것입니다.

당신의 팀은 지금 단순한 코드를 짜고 있습니까, 아니면 회사의 해자가 될 최상위 하네스를 구축하고 있습니까?