TUEO 제품 백서

1. TUEO란 무엇인가

TUEO는 기업을 위한 프라이빗(온프레미스) AI 협업 플랫폼입니다 —— AI는 조직의 정규 직원으로서(직무, 책임, 성장 궤적, 행동 경계와 장기 기억을 가진 채) 고객 자체 환경에서 사람과 함께 업무를 운영합니다.

이것은 단순한 슬로건이 아니라 이미 실현된 제품 체계입니다. TUEO는 10개 제품으로 구성되며, AI가 ‘조직에 편입’되기 위해 필요한 모든 것을 포괄합니다:

• 정체성: AI 직원과 인간 직원이 같은 인사 대장, 같은 로그인, 같은 권한을 공유;
• 지식·기억: AI의 지식베이스와 기억에 전용 기반이 있으며, 쓸수록 정확해지고 자동 정리로 스스로 성장;
• 연산·모델: 이기종 연산을 통합 관리하고, 모델 서비스를 거버넌스와 함께 제공하며, 하나의 제어 평면으로 클로즈드 루프;
• 협업: AI 직원이 동료처럼 그룹 채팅에 참여하고, 워크오더를 실행하고, 정기 회의를 주재하고, 조직 지식을 축적;
• 오케스트레이션: 업무 담당자가 대화로 프로세스를 AI 애플리케이션으로 편성하고, 릴리스 후 조직이 호출;
• 역량: AI가 호출하는 모든 스킬이 시장 지향적으로 거버넌스됨 —— 구매, 권한, 계량, 자격 증명;
• 실행: AI가 실제로 일하는 곳이 격리 샌드박스에 담겨, 감사 가능하고 스케줄링 가능;
• 코딩: AI 개발 팀이 실제 코딩 엔진으로 코드를 수정하고, 테스트하고, MR을 생성;
• 전달: 전체 체계를 고객 자체 데이터센터에 설치하여, 완전히 네트워크가 단절된 상태에서도 운영 지원.

TUEO의 핵심 판단은 다음과 같습니다: 기업 AI의 다음 단계는 ‘더 똑똑한 대화’가 아니라 ‘조직 운영에 들어갈 수 있는 직원’입니다. AI에는 직무가 필요하고, 경계가 필요하며, 성장이 필요하고, 감사를 받아야 합니다 —— 이것은 정확히 조직이 인간 동료를 관리할 때 하는 일입니다. TUEO는 이 메커니즘을 공학적으로 구현하고 프라이빗(온프레미스)으로 전달합니다.

1.1 두 번째 레이어 포지셔닝: 기업 정보화 지능형 기반

‘AI의 조직 편입’은 첫 번째 레이어 포지셔닝으로, AI가 당신의 업무를 실행하는 것을 말합니다. TUEO에는 두 번째 레이어 포지셔닝이 있으며, 기업 전체 정보화의 기반을 말합니다:

AI 프로그래밍 시대에, 기업 정보화에 진정으로 부족한 것은 더 많은 시스템이 아니라, 시스템의 ‘정의, 생산, 운영, 업데이트, 총괄’을 하나의 완전한 루프로 엮는 지능형 기반입니다. TUEO가 바로 그 기반입니다 —— 작업 지시로 시스템을 정의하고(개발하는 것이 아니라), 기업이 보유한 역량이 재사용되고 AI화되어, 자체 운영 기반 위에서 지속적으로 운영됩니다.

대외 스토리텔링 순서: 먼저 ‘어떤 기반인지’를 명확히 하고, 그다음 ‘AI 직원이 그 기반 위에서 어떻게 일하는지’를 이야기합니다.

• 정의 레이어 —— 작업 지시 기반 시스템 정의: studio 오케스트레이션 + cohort 워크오더 파이프라인 + executor 실행. 업무가 작업을 설명하면 AI가 분석, 분배, 개발, 테스트, 전달;
• 총괄 레이어 —— 역량 AI화, 시스템 고립 거버넌스: capabilities + skillplugins + identity. OA / ERP / CRM / MES 같은 이미 존재하는 시스템을 역량으로 등록하고, 권한을 부여하고, 자격 증명을 위탁 관리하며, AI가 안전하게 호출하게 합니다 —— 기존 시스템을 대체하는 것이 아니라, 기존 시스템이 처음으로 AI가 호출하고, 권한을 부여하고, 감사하고, 계량할 수 있는 역량이 되게 합니다;
• 운영 레이어 —— 리소스 관리, 애플리케이션 배포·릴리스, 운영: console + executor. 새 시스템, 기존 시스템, AI 시스템을 하나의 진입점으로 전체 체계를 운영.

기반 = 기존 시스템을 대체하는 것이 아니라, 당신의 모든 시스템이 이 기반 위에서 정의되고, 조립되고, 운영되고, AI화되게 합니다.

1.3 핵심 철학(다섯 가지)

1.4 세 가지 ‘팔지 않는 것’

• 대화 로봇은 판매하지 않음 —— 그것은 AI 직원의 최하위 형태이지, 제품이 아닙니다;
• 단일 AI 도구는 판매하지 않음 —— Dify / Coze / n8n의 ‘다시 쓰기’가 아니라, 체계를 판매하지 구성 요소를 판매하지 않습니다;
• ‘답할 수 있는 것’을 판매하지 않음 —— ‘답할 수 있고, 실행할 수 있고, 거버넌스할 수 있고, 실현할 수 있는 것’을 판매합니다.

2. 해결해야 할 문제

2.0 시대의 명제: ‘데이터 고립’에서 ‘시스템 고립’으로

AI 프로그래밍에는 양면이 있습니다: 좋은 면은 시스템을 만드는 비용이 거의 0에 가까워져 ‘개발’이 더 이상 희소 자원이 아니라는 것; 새로운 문제는 시스템 수의 폭발, AI가 생성한 시스템의 무질서한 성장입니다 —— 운영·유지보수를 담당할 사람도 없고, 업데이트할 사람도 없으며, 기존 시스템과 연동할 사람도 없습니다.

데이터 고립은 ‘읽기’의 문제입니다 —— 데이터는 복사, 이동, 집중이 가능하며, ETL / 데이터 웨어하우스 / 데이터 중계 플랫폼이 20년을 싸워 대부분 해결했습니다. 하지만 데이터를 레이크로 옮겨도 시스템이 말을 하지는 않습니다: AI에게 필요한 것은 데이터를 읽는 것만이 아니라, 시스템에 로그인하고, 시스템이 어떤 역량을 가졌는지 알고, 시스템 안에서 안전하게 작업을 실행하며, 매 작업마다 감사 기록을 남기는 것입니다 —— 이것은 ‘움직임’의 문제로, 데이터 거버넌스가 한 번도 해결하지 못한 것입니다.

양쪽 모두 고립입니다: 전통적인 구시스템은 아직 AI화되지 않았고(데이터센터에서 돌아가지만, 아는 사람도 없고, 만질 사람도 없습니다); AI 신시스템은 운영·유지보수할 사람이 없습니다(만들 수는 있어도, 키울 수 없습니다). 시스템 고립은 데이터 고립보다 다루기 어렵습니다 —— 시스템은 살아 있고, 폭발 반경이 있습니다. ERP를 레이크로 옮길 수는 없고, 살아 있게 두고 안전하게 호출되도록 할 수밖에 없습니다.

TUEO의 답은 소프트웨어 개발의 완전한 클로즈드 루프입니다: 업무가 요구 사항을 제시 → AI가 작업으로 분석 → AI 팀이 개발 → 테스트 → UAT → 투입 → 지속 모니터링·운영 → 먼저 기존 역량을 점검하고, 재사용할 수 있으면 새로 개발하지 않음 → 역량 총괄 → 다시 요구 사항으로. 핵심 사상: 작업 지시로 시스템을 정의하지, 개발하지 않습니다.

이를 바탕으로, 기업이 AI를 실제 업무에 투입할 때 네 가지 단절을 공통적으로 만납니다:

2.1 답할 수 있지만, 실행할 수 없다

범용 대형 언어 모델 애플리케이션은 ‘답’만 할 수 있고, 기업의 실제 환경에서 일할 수는 없습니다: 시스템의 데이터를 수정하고, 기존 시스템과 연동하고, 코드를 실행하고, 실제 파일을 산출하는 것. 기업이 원하는 것은 더 똑똑한 어시스턴트가 아니라, 실제로 실현 가능한 한 쌍의 ‘손’입니다.

2.2 AI는 도구이지, 직원이 아니다

대부분의 기업은 AI를 도구로 어떤 시스템에 붙입니다: 고객 서비스 챗봇 하나, 글쓰기 어시스턴트 하나. 직무도, 책임 경계도, 성장 궤적도, 장기 기억도, 행동 감사도 없습니다. ‘정체성이 없는’ AI는 조직이 관리할 수 없고, 지속적인 업무 책임을 질 수도 없습니다.

2.3 결정은 있지만, 실행 계층이 없다

AI가 올바른 판단을 내릴 수 있어도, 실제로 누가 실행할까요? 업무 시스템 안에서 AI의 코드를 직접 실행하는 것은 위험합니다 —— 격리되고, 통제되고, 감사 가능한 실행 계층이 필요하며, ‘사용자 코드는 신뢰할 수 없다’를 기본 전제로 삼아야 합니다.

2.4 AI는 있지만, 거버넌스와 감사가 없다

금융, 공공 행정, 의료 등 규정 준수가 엄격한 산업에서는 모든 AI 판단이 추적 가능하고, 리플레이 가능하고, 감사 가능해야 합니다. 그러나 대부분의 AI 플랫폼은 감사를 사후 패치로 취급하고, 권한을 각 제품에 흩어 놓으며, 모델 키를 클라이언트에 묻어 둡니다 —— 이것들은 모두 규정 준수 검토를 통과할 수 없고, 프라이빗(온프레미스) 전달도 불가능합니다.

TUEO는 10개 제품으로 구성된 하나의 체계로 이 네 가지 단절을 한 번에 해결합니다.

3. 제품 체계 총람

3.1 10개 제품, 하나의 체계

3.2 계층형 구조

소비 측       cohort-desktop(Electron 데스크톱 클라이언트) · cohort-server 관리 백엔드
───────────────────────────────────────────────────────────
체험 레이어   cohort(협업 코어) · studio(애플리케이션 오케스트레이션)  ← 사람과 AI가 함께 일하는 곳
역량 레이어   capabilities(역량 마켓 · 호출 게이트웨이)             ← 하나의 역량 계약, 두 명의 소비자
실행 레이어   executor(샌드박스 실행) · codex-build(코딩 엔진)      ← AI가 실제로 일하는 곳
───────────────────────────────────────────────────────────
기초 기반    identity(정체성 SSOT) · engram(지식·기억 기반) · inference(연산·모델 서비스) ← 위의 전부를 가로지르며 지지
운영 기반     console(지능형 기반 운영 레이어 · 배포 / 미들웨어 / 프라이빗 IDP)
생태계        skillplugins(플러그인 소스 + @tueo/plugin-sdk)

3.3 데이터 흐름과 책임 경계(진실은 누구인가)

3.4 통합 매트릭스(행이 열을 호출)

4. identity —— 정체성 기반

한 문장: 플랫폼 전체의 통합 정체성 기반 —— 하나의 계정으로 모든 제품에 로그인하고, 하나의 토큰으로 당신이 어떤 테넌트에 있는지 명시하며, 하나의 디렉터리로 인간 직원과 AI 직원을 관리합니다.

4.1 포지셔닝

identity는 TUEO 체계의 정체성 단일 진실(SSOT) 로, 세 가지 플랫폼급 역량을 담당합니다:

1. OIDC IdP: 표준 OpenID Connect / OAuth 2.0 권한 부여, 토큰, 세션, 페더레이션, 멀티 테넌트;
2. 조직 디렉터리 단일 진실: 조직 구조 + 사람 + 재직 관계, 플랫폼 전체 주소록의 SSOT;
3. 권한 판정 센터: RBAC 역할을 3단계로 수렴, 판정 로직을 identity로 회수, 하위 제품은 역할 정보를 보유하지 않음.

identity의 설계 판단 기준: ‘다른 제품으로 바꿔도 성립하는가’. 플랫폼급 정체성 역량만 수행하며, 어떤 단일 제품의 업무 로직도 담지 않습니다.

4.2 핵심 역량

4.2.1 OIDC IdP(ES256 + PKCE + 토큰 로테이션)

표준 OIDC 권한 부여 서버 구현 기반: authorization code + PKCE 로그인, ES256 서명 JWT access token, refresh token 로테이션(RFC 9700), RFC 8628 Device Flow, RFC 7662 introspection, JWKS 로테이션. 서명 키는 암호화되어 DB에 저장되고, 다중 복제본 핫 리로드를 지원합니다. access token은 엄격한 최소 claim을 사용하며 —— 프로필은 항상 /userinfo로 권위 정보를 조회하여 토큰 비대화와 권한 드리프트를 방지합니다.

4.2.2 스위트급 SSO(RFC 8693 토큰 교환)

6개 제품을 한 번의 로그인으로 연결하는 접착제: identity 루트 토큰으로 aud=<제품> 사용자 토큰을 교환하여 studio / executor / capabilities에 바로 진입, 2차 로그인 없음. 두 개의 보안 게이트: subject token은 반드시 현역 루트 토큰; audience는 반드시 퍼스트파티 제품 화이트리스트 안에 있어야 함 —— 교환은 동일 사용자 + 퍼스트파티 제품의 수평 또는 권한 축소만 허용하며, 보유만으로 권한을 올릴 수 없습니다.

4.2.3 권한 축소 최소 권한 토큰

반신뢰 실행체(AI 엔진 서브프로세스, 로컬 코딩 엔진)에 최소 권한 토큰을 발급: 별도 audience + 단일 기능 scope + 짧은 TTL. 엔진이 보유한 최악의 자격 증명이 ‘모델 공급사 키 / 사용자 전체 권한 토큰’에서 ‘본 테넌트의 할당량만 소모할 수 있고, 15분 만료, audience에 바인딩된 경로로 고정된 티켓’으로 내려갑니다 —— 폭발 반경마다 티켓 한 장씩.

4.2.4 조직 디렉터리 단일 진실

조직 구조 트리 + 구성원 재직 관계 + 인원 검색이 모두 identity에서 제공됩니다. 트리는 ltree로 저장하고, 재직 관계는 user_org_memberships JOIN users JOIN org_nodes로 구성하며, position_title 직함은 재직 관계에 붙습니다. 플랫폼 전체 주소록이 100% 여기서 구축되며, 사람 수정 시 identity 한 곳만 수정하면 데스크톱 / 서버 / Matrix localpart가 플랫폼 전체에서 따라갑니다.

4.2.5 RBAC 역할 수렴 + scope 우주

플랫폼 전체에 platform_admin / tenant_admin / member 3개 역할 이름만 있으며, 11개의 구식 이름은 별칭 테이블로 통일됩니다. scope는 역할 디렉터리에서 프로그램적으로 파생되어 통일 소비됩니다(과거 5곳에서 scope를 수동 유지하다가 조용히 박탈된 함정이 있었음). 새 제품 추가 = catalog 한 줄 + scope 연결, 하위 계층 변경 없음.

4.2.6 테넌트 전환 = 토큰 재서명

‘내가 어떤 테넌트에 있는가’는 진실이 하나뿐입니다 —— 토큰 자체. 전환 = 테넌트 hint를 들고 권한 부여를 다시 거치고, identity가 검증한 후 토큰을 재서명합니다; 매 서명마다 권한 부여를 다시 검증하며, 역할이 박탈되거나 테넌트가 삭제되면 즉시 home으로 되돌아갑니다. 토큰만 검증하는 소비 지점(예: WebSocket 게이트웨이)은 자동으로 올바르며, 권한 초과로 드리프트하지 않습니다.

4.2.7 SCIM 인바운드 프로비저닝

표준 SCIM(RFC 7643/7644) 구현이 /scim/v2/*에 있으며, 외부 IdP(Okta / Azure AD)가 표준으로 접속합니다. 각 테넌트는 정적 bearer token으로 tenantId를 고정하여 크로스 테넌트가 불가능합니다. 사용자 / 그룹 CRUD, 필터 연산자, externalId 대사, 동기화 로그와 실패 감사.

4.2.8 추적 가능한 감사(암호화 해시 체인)

모든 정체성 / 권한 / 디렉터리 변경이 감사에 들어가며, 행과 행 사이를 SHA-256 contentHash + prev_hash 해시 체인으로 잠급니다 —— 삽입, 삭제, 재배열, 행 수정을 모두 verifyChainIntegrity로 감지할 수 있습니다. 감사 보존 정책은 테넌트별로 설정 가능하며(기본 90일), 내보내기에 hash 검증이 포함됩니다.

4.2.9 사용자 커스텀 필드 거버넌스 + 민감 정보 암호화

테넌트 관리자가 필드 스키마를 선언합니다(유형 / 필수 / 검증 / 민감 / 검색 가능). 민감 필드(예: 주민등록번호)는 일반 필드와 물리적으로 분리됩니다: 비민감은 metadata로, 민감은 독립 테이블로, AES-256-GCM 암호화 저장, 마스킹 반환, 평문 읽기에 기록 —— PIPL이 민감 개인정보의 추적 가능성에 대해 요구하는 하드 조건을 충족합니다.

4.2.10 관리 콘솔

조직 / 사용자 / 역할 / 감사 / 테넌트 / SSO / SCIM / 커스텀 필드 / 세션 / Webhooks / API Key / 브랜드를 포괄하며, TUEO 플랫폼 디자인 시스템(종이 / 먹 / 청옥 / 주사)으로 구현하고, 다국어와 화이트 라벨을 지원합니다.

4.3 차별화

• AI 직원과 인간 직원이 동일한 정체성: users.type='ai_staff' 1급 사용자 유형, 동일 편제, 동일 디렉터리, 동일 주소 지정;
• 권한 판정을 identity로 회수: 경쟁사는 ‘누가 관리자인가’를 각 제품에 흩어 두지만, identity는 한 곳에서만;
• 증명 가능한 감사: 해시 체인으로 ‘누가 무엇을 했는가’를 검증하고 위조를 판별 가능;
• 프라이빗(온프레미스) 전달 가능: 단일 도메인 일체형 기기 + setup 마법사 + 키는 운영 설정 센터가 관리, 완전 오프라인 배포 가능.

5. cohort —— 협업 코어(플래그십)

한 문장: AI를 당신 조직의 정규 직원으로 만듭니다 —— 인간과 AI 동료가 같은 워크스페이스에서 함께 일하고, 함께 성장하고, 함께 전달합니다.

5.1 포지셔닝

cohort는 TUEO의 플래그십 제품으로, 서버 측(cohort-server, NestJS 11 + Fastify + PostgreSQL)과 데스크톱 측(cohort-desktop, Electron 3프로세스)으로 구성됩니다. ‘AI 직원 워크스페이스’의 모든 업무 로직을 담당합니다: AI 직원 엔터티 레지스트리, 그룹 채팅 다중 AI 협업, 인지 루프, 워크오더 파이프라인, 조직 지식 그래프, 대화 메모리, 주간 회의 오케스트레이션, 감사 기록과 멀티 테넌트 격리.

서버가 데이터 SSOT이고, 데스크톱은 씬 클라이언트입니다 —— 기업 데이터는 클라이언트에 흩어지지 않습니다.

5.2 핵심 역량

5.2.1 AI 직원 엔터티화(AiStaffRegistry)

AI 직원은 ‘편제된 정체성과 직업 프로필을 가진’ 1급 엔터티이며, 두 레이어 SSOT를 JOIN합니다:

• identity 인사 대장: 편제 정체성 / 실명 / 부서 / 직함, 주소록과 동일 출처;
• cohort ai_staff_profiles 직업 프로필: roleLabel / workMethod / toolPolicy.allow / leadKinds / ownedCapabilities / responsibilities / persona 성격 카드.

전체 파이프라인은 이 레지스트리 하나만 읽습니다. AI 직원 추가 / 삭제 / 수정 시 identity(+직업 프로필) 한 곳만 바꾸면, 주소록, 워크오더 트라이지, 역량 라우팅, 공지 서명이 전 라인에서 따라가며, 코드 변경 없음, 이름 하드코딩 없음. identity에서 삭제 → 전체에서 사라짐.

5.2.2 그룹 채팅 다중 AI 협업(coordinator)

그룹 채팅에서 인간 메시지를 어떤 AI 직원이 받을지는 서버가 판단합니다(coordinatorJudge = SSOT):

• 빠른 경로: AI 없음 → 안 받음; @멘션 → 반드시 응답; DM 인간 → 자동 응답; AI 발언 → 자답 루프 방지; 노이즈 / 순수 이모지 → 안 받음;
• 느린 경로: 그룹 채팅 + 인간 + 응답 기대 → AI 직원 실제 직무 프로필로 결정적 직무 점수(LLM 비용 0), 다수 후보가 비슷하면 LLM 중재, 다시 비서 폴백.

매 판정에 감사가 기록됩니다(coordinator.dispatch_judged). 그룹 채팅은 항상 ‘반드시 책임자가 응답’하며 도배하지 않고, 라우팅 근거는 하드코딩된 이름이 아닌 실제 직무 프로필입니다.

5.2.3 AI 직원 인지 루프(지각→사고→행동→복기→대기)

각 AI의 매 결정은 5단계 인지 루프를 완주합니다:

1. 지각 Perceive: 대화, 신호와 조직 컨텍스트를 읽고, 먼저 원칙 게이트(principleEnforcer.check('perceive'))를 통과하며, deny는 거부 산출물을 직접 기록;
2. 사고 Think: 장기 메모리 검색 + 경험 규칙 + 프로젝트 컨텍스트를 융합하고, LLM으로 구조화된 의도를 출력; LLM을 사용할 수 없으면 규칙 기반으로 폴백;
3. 행동 Act: 고위험 행동은 사람의 확인 필요;
4. 복기 Reflect: LLM 반성이 메모리에 기록되어 자기 진화를 구동;
5. 대기 Wait: 다음 신호 감시에 진입.

전 과정이 phaseTimings로 계측되고, 관측 가능하고 추적 가능합니다.

5.2.4 워크오더 시스템(의도 → DoR → 트라이지 → Agent 실행)

한 줄의 채팅 메시지에서 AI 개발 팀이 실제로 일하는 것까지의 전체 파이프라인:

1. 의도 인식: LLM jsonMode + 검증으로 bug / feature / incident 인식;
2. DoR 접수: severity별로 접수를 나누고, AI가 자체 보완 가능 —— LLM으로 중국어 워크오더를 코드 검색어로 변환하고, 로컬 ripgrep으로 실제 파일에서 재현 단계를 찾으며, 절대 조작하지 않음;
3. 트라이지: passport 게이트 → LLM이 assigned_role / priority / AC 추론 → dev_team_room으로 배정; 배정 가능한 역할은 registry가 동적 주입;
4. 상태 머신: 14개 상태 + 전이 매트릭스 O(1) 검증;
5. Agent 실행: 5단계 단일 run-role, validateToolList가 toolPolicy.allow에 따라 권한 초과 도구를 서버에서 강검증.

데스크톱은 TriageCard / BuildProgressCard로 시각화하며, AI가 로컬 checkout한 repo에서 실제로 파일을 수정하고, 테스트를 실행하고, commit하여 워크오더에 피드백합니다. 인간 메시지도 자동 분류로 워크오더를 만들 수 있습니다.

5.2.5 조직 지식 그래프(‘조직 공기’)

조직 대화를 지식 그래프로 축적합니다: LLM이 메시지에서 엔터티 + 유형화 관계를 추출하여 kg_entities / kg_edges(pgvector + 관계 테이블 + 출처 추적)에 넣고, 검색 시 pgvector 코사인 top-K(테넌트 격리) → 그래프 다중 홉 이웃(약속 / 의존 / 충돌) → sensitivity 게이트(기본 최고 수준, 민감 정보 누출 없음).

지식 저장은 단일 DB 3-in-1(Postgres + pgvector + 관계 테이블)이며, 이중 쓰기 없음, 드리프트 없음, 에어갭 설치 시 Postgres + identity 두 서비스만 의존합니다.

5.2.6 대화 메모리(개인 장기 기억 + 공유 substrate)

각 AI는 방을 넘나드는 공유 장기 기억을 가집니다(7일 반감기 감쇠, 200개 상한), 서버 /cognitive-loop/memory가 권위 복제본입니다. 모든 AI 결정은 같은 ‘회의실 상태’ substrate를 공유합니다: 메인 주제 / 확정된 사실 / 미해결 / 미완결 약속. 방을 바꾸거나 다중 AI가 협업해도 각자 fresh start하지 않으며, 조직은 쓸수록 똑똑해집니다.

5.2.7 섀도우 AI 은밀한 분신

각 실제 사람 뒤에 은밀한 분신이 하나씩 있습니다: 본인이 직접 한 말(스타일 / 말투 / 길이)을 학습하고, 상대방이 응답을 기다리는 메시지를 보냈는데 본인이 30초 안에 응답하지 않으면 백그라운드에서 본인 말투로 초안을 만듭니다. 대발 전환 스위치는 기본적으로 꺼져 있고, 생성 + 감사만 하며 자동 발송하지 않습니다. 대발 게이트 = 총 스위치 ∧ 비동결 ∧ 비보호 구역 ∧ 신뢰도 ≥ 신뢰 임계값 ∧ 위험 ≤ L2, 재무 / 고객 / 기술 / 내부 4개 버킷의 독립 임계값으로 관리합니다.

5.2.8 서버 측 주간 회의 오케스트레이션

8명의 AI 직원이 매주 구조화된 보고 → 토론 → 지원 요청 → 결의의 클로즈드 루프를, 전부 서버 측에서 처리합니다: AI별 참석자의 증거를 가져오고(최근 50개 방 메시지) → 추론 → AI 실제 uuid로 서명하여 발언. 전체 실패 = 정직한 실패로 단계를 진행하지 않고 시스템 메시지에 실제 원인을 기록합니다(‘LLM 게이트웨이 quota 403이 조용히 삼켜져 빈 회의가 된’ 프로덕션 사고를 근절). 금요일에 자동 시작.

5.2.9 메시지 엔진 + 실시간 채널

채팅 메시지 CRUD, 전달 / 읽음, 스트리밍 AI 응답, 번역이 모두 서버 SSOT이며 WS로 브로드캐스트됩니다. 동시성 / 경합 / 크로스 테넌트는 서버에서 차단됩니다; 번역은 제한이 있습니다(컨텍스트 해시 중복 제거 + 기술 리터럴 mask/restore + 슬롯 큐). WS 게이트웨이는 3축으로 강화됩니다(tenant claim 엄격 검증, jti 폐기, 테넌트별 슬라이딩 윈도우 속도 제한).

5.2.10 엔진 모델 게이트웨이(자격 증명이 서버 밖으로 나가지 않음)

AI 코딩 엔진은 어떤 모델 공급사 키도 보유하지 않습니다: 엔진의 base_url은 서버의 OpenAI 호환 엔드포인트를 가리키고, 서버가 발급한 권한 축소 단기 티켓(15분, audience 바인딩 경로)을 보유하며, 실제 키는 서버가 테넌트별로 해석하여 주입합니다. 세 가지 하드 속성: model은 서버가 정하고 클라이언트를 무시, 클라이언트 자격 증명 필드는 전부 폐기, 상위 응답은 반환 전에 마스킹.

5.2.11 MCP Tueo Server(업무 역량이 엔진으로 들어가는 통일 출구)

cohort 업무 역량(워크오더 / 지식 / 첨부 / 약속 / 발언)을 표준 MCP 도구로 실행 엔진에 노출하여, ‘AI가 일 → 성과가 협업 시스템으로 환류’의 클로즈드 루프를 형성합니다.

5.2.12 데스크톱(cohort-desktop)

• 3프로세스 Electron: 메인 프로세스(OS 통합 / OIDC / IPC / 크래시 자가 치유) + preload(contextBridge 화이트리스트 + 카테고리별 token-bucket 속도 제한, 파괴적 채널은 별도 소버킷) + 렌더링 프로세스(React 19 + Zustand);
• 4열 워크스페이스: 대화 목록 / 메시지 영역 / 상세 / WorkspacePanel(Markdown/HTML 문서 상호 변환 → PDF/PPTX 내보내기 + IDE 워크벤치);
• 보안 심층 방어: OIDC PKCE + ES256, 3개의 권한 축소 토큰, CSP enforce, 감사 단일 펀넬로 서버 콘솔에 수집, IPC 속도 제한;
• 로컬 페어링: 메인 프로세스가 코딩 엔진을 직접 spawn(ACP 프로토콜), 파일 읽기·쓰기가 작업 디렉터리 경계 안에 있고, 권한 요청은 기본적으로 거부 —— ‘사람이 핵심 관문에서 통제한다’는 것은 슬로건이 아닙니다.

5.3 AI 직원의 직무와 권한 경계(AI 직원도 동일하게 통제됨)

AI 직원의 역량 경계는 직무, 책임과 부여된 도구 권한이 함께 결정하며, 그것이 할 수 있는 일이 결정하지 않습니다 —— 이것이 TUEO와 ‘범용 AI 어시스턴트’의 가장 근본적인 차이 중 하나입니다.

• 경계를 어떻게 정하는가: 각 AI 직원은 직업 프로필에 책임 범위와 도구 화이트리스트(toolPolicy.allow)를 선언합니다. identity가 ‘누구인가’(편제 정체성)를 관리하고, 레지스트리가 ‘어떻게 일하는가’(직무 / 책임 / 권한)를 관리하며, 두 라인이 함께 그것이 할 수 있는 일을 결정합니다. 비서는 비서일 뿐 —— 쑤완은 비서이므로 운영 서버를 조작할 수 없습니다;
• 경계를 어떻게 지키는가: 권한 초과 도구는 서버에서 강검증(validateToolList가 toolPolicy.allow 기준)으로 모두 거부; 지각 단계에서 먼저 원칙 게이트(PrincipleEnforcer, pattern 매치 시 즉시 판정)를 통과; 고위험 작업은 사람 승인 필요; 모든 결정과 거부가 감사에 들어갑니다 —— 네 겹의 행동 방어선이 층층이 받쳐줍니다;
• 경계가 왜 강한가: 사람이 전직하면, AI도 전직한 것과 같습니다 —— 직무 구성 한 곳을 바꾸면 역량 범위가 전체적으로 따라갑니다. AI 직원과 인간 직원은 동일한 통제 로직을 사용합니다: 강하지만, 조직이 준 경계 안에서만 강합니다.

이 메커니즘은 ‘AI가 강할수록 경계가 명확하다’를 공학적 사실로 만듭니다: 코드를 작성할 수 있는 AI도 운영 권한을 받지 않았다면, 운영 서버에 대한 어떤 요청도 시스템이 하드 거부하고 감사 기록을 남깁니다 —— 조직의 AI에 대한 신뢰를 단계적으로 풀 수 있고, 한 번에 전부를 걸 필요가 없습니다.

5.4 차별화

• AI는 ‘조직 편제 안의 직원’이지 도구가 아니며, 이름 하드코딩 없음, 이름 단일 출처는 identity;
• 그룹 채팅 주관자는 서버 계약이지 클라이언트 휴리스틱이 아니며, 자답 루프를 방지하고 매 판정에 감사 기록;
• 워크오더는 설문이 아님: DoR 단계 접수 + AI 자체 보완, 엄격함은 차용하되 관료제는 차용하지 않음;
• 자격 증명이 서버 밖으로 나가지 않고, 감사 단일 펀넬로 수집, 기업 데이터가 클라이언트에 흩어지지 않음;
• 직무가 경계를 결정: AI 직원과 인간 직원이 동일한 통제 로직, 권한 초과 도구는 서버에서 하드 거부하고 감사 기록.

6. studio —— 애플리케이션 오케스트레이션 플랫폼

한 문장: 업무 담당자가 대화로 프로세스를, AI가 업무 객체에 대해 인지-결정-행동하는 애플리케이션으로 편성합니다 —— BPM의 AI 네이티브 후계자이지, 또 하나의 워크플로 캔버스가 아닙니다.

6.1 포지셔닝

studio는 TUEO의 ‘오케스트레이션 엔진 레이어 / 지능형 노동 입법 레이어’입니다: 조직의 지능형 노동(AI 직원 + 커넥터 + 사람 심사)을 게시 가능하고, 감사 가능하고, 진화 가능한 애플리케이션으로 편성하여, 사람 / AI 직원 / 외부 에이전트가 신뢰를 가지고 호출하게 합니다. cohort와 조합되어 실행됩니다: cohort는 AI 직원 런타임, 사람 심사 카드와 결과 피드백을 제공하고, studio는 구조화된 오케스트레이션, 수용 릴리스 게이트와 거버넌스 가드레일을 제공합니다.

6.2 핵심 역량

6.2.1 이벤트 소싱 오케스트레이션 엔진

11종 노드(시작 / 종료 / 분기 / AI 인지 / AI 직원 / 사람 / 역량 / 서브프로세스 / 루프 / 대기 / 병렬), 모든 상태 전이에 append-only run-trace 이벤트가 한 건씩 추가됩니다. 상태는 이벤트에서 파생됩니다: 사람 / 서브프로세스 / 루프 / 타이머 / 병렬 / AI 직원이 모두 영속적 일시 중지를 거치며(프로세스 재시작 시 즉시 이어 실행, 제로 스레드 보유). 중단점 단일 스텝 / 계속, 실패한 단계부터 재실행, 재귀 보호를 지원합니다.

6.2.2 대화 부조종사(자연어 오케스트레이션)

업무 담당자가 의도를 말하면(예: ‘3,000 초과 지출은 재무 총괄 승인 거치기’), 부조종사가 고수준 승인 사양을 산출하고, 결정적으로 컴파일하여 합법적 FlowDef를 만듭니다 —— LLM은 ‘무엇을 판정할지 / 어떻게 라우팅할지 / 몇 단계 승인할지’의 단순 JSON만 출력하고, 구조는 컴파일러가 합법성을 보장하며, 최대 3회 자체 수정. 변환은 결정적, 콘텐츠는 지능적.

6.2.3 릴리스 거버넌스: draft/published 버전 격리 + 수용 테스트 게이트

오케스트레이터는 초안을 저장하고, 릴리스 시 불변 semver 버전 스냅샷을 만들며, 온라인 실행은 항상 최신 published를 가져옵니다. 릴리스 전에 수용 테스트 스위트(스텁 AI 출력 + 스크립트 사람 심사 + 스텁 역량, 결정적 리플레이)를 실행하여 전부 통과해야 릴리스합니다 —— 수용 테스트 = 릴리스 게이트, 동시에 L2/L3 회귀 안전망. 이력 버전 롤백을 지원합니다.

6.2.4 AI 인지-결정-행동 노드

하나의 프리미티브로 분류 / 판단 / 추출 / 이미지 보기 / 자율 도구 호출을 지원합니다: 구조화 JSON 출력 계약 + 모델 출력 스키마 강검증, agentic 에이전트 루프(function-calling, 매 step tool_call 기록), 멀티모달 비전(이미지를 비전 모델로 설명으로 변환), 노드 레벨 모델 필드로 의미 라우팅.

6.2.5 AI 직원 노드 + 사람 심사 노드(인간·기계 대등 actor)

ai_staff 노드는 일을 identity 편제 AI 직원(cohort에서 일함)에게 배정하고, 사람 심사 노드는 사람의 판결을 기다리며 일시 중지합니다 —— 두 actor는 각각 SLA, 각각 조직 상급 승격 체인이 있습니다. AI 직원은 스크립트가 아니라 동료이고, 사람은 프로세스 안의 대등한 노드입니다.

6.2.6 오케스트레이션 변수 모델 obj/steps/sys/env 4개 스코프

노드 입력 매핑과 분기 조건은 타입화 표현식 AST를 사용하며, 데이터 흐름이 결정적이고, 리플레이 가능하고, 테스트 가능합니다 —— 분기 조건은 블랙박스 prompt가 아니라 수용 가능한 선언입니다.

6.2.7 거버넌스 척추(enforcement이지 전시가 아님)

• kill-switch 차단: 전역 / 앱별 원클릭 차단(423);
• 할당량 속도 제한: per-app 실행 속도(429);
• token 예산: 단일 실행 token 누적 한도 초과 시 엔진 중단;
• 콘텐츠 안전 게이트: 금지어 + PII 정규식(휴대폰 / 이메일 / 주민등록번호), mode = off/flag/block;
• 감사: 감사 로그가 run-trace 이벤트에서 투영되며, 내보내기 가능(SOC2 / 等保 / EU AI Act 증거 확보).

6.2.8 cohort 융합(app-as-tool)

cohort 대화에서 애플리케이션을 도구로 사용합니다: 앱 선택 → 폼 카드(정밀 입력) → run 시작·대화 스레드 바인딩 → 결과 / 사람 심사 카드 피드백. 폼 사전 채움은 출처 게이트를 거칩니다(증거가 있는 필드만 채움); 결과 카드의 내러티브 템플릿은 실제 결과로 자리 표시자를 교체합니다(값을 얻을 수 없으면 문단 전체 폐기, LLM 0회, 조작 0건).

6.2.9 디자인 탭 + 다중 채널 적응

AI가 실제 산출물 필드에서 선언형 블록 레이아웃을 생성하고, 백엔드가 하드 검증합니다(블록 열거 + bind는 실제 필드만 유지 + 배열 블록은 배열 필드만 바인딩, 조작은 전부 폐기). 한 번 오케스트레이션, 다중 채널 전달: cohort 4열 셸 / 기업 IM(企微 / 钉钉 / Lark 카드) / 웹 위젯.

6.2.10 자동화 트리거 + MCP 노출 + 디버깅 관측

애플리케이션을 수동 호출에서 정기 / webhook 자동 트리거로 확장 가능; 각 게시된 앱은 하나의 MCP 도구로 노출되어 어떤 에이전트도 호출할 수 있습니다(벽 안의 정원을 만들지 않음); SSE 스트리밍 디버깅 + dry-run 리허설 + 노드 Mock 커버 + 중단점 디버깅.

6.3 차별화

• Dify / n8n이 아님: ‘업무 객체 위의 AI 네이티브 오케스트레이션’, 업무 객체 유형 계약 + 이벤트 소싱;
• 수용 테스트 = 릴리스 게이트: AI 오케스트레이션도 소프트웨어 엔지니어링처럼 품질을 통제;
• AI 직원은 인간·기계 대등 actor: 직무, SLA, 상급 승격 체인 존재;
• 거버넌스는 진짜 차단이지 전시가 아님: 차단 / 할당량 / token 예산 / 콘텐츠 안전 게이트를 모두 엔진 레이어에서 차단.

7. capabilities —— 역량 마켓

한 문장: 기업 AI 역량의 App Store —— 하나의 역량 계약으로, AI는 도구로, 사람은 UI로, 생산부터 마켓, 구매, 권한, 에어갭 배포까지 전 체인 거버넌스.

7.1 포지셔닝

capabilities는 ‘역량이 어디에서 오는가’의 독립 플랫폼 레이어(생산 / 플랫폼)이며, 어떤 소비 호스트에도 속하지 않습니다. 하중 벽은 생산 / 소비 2분법: 역량 플랫폼이 레지스트리 SSOT + 마켓 + 설치 거버넌스 + 자격 증명 금고 + 호출 게이트웨이 + 플랫폼 콘솔을 담당; cohort(채팅 / AI 직원)와 studio(앱 오케스트레이션)는 모두 SDK 계약으로 소비하는 호스트이며, 각자의 네이티브 UI를 갖고, 절대 역방향 의존하지 않습니다.

이것은 이전에 레지스트리 / 게이트웨이를 cohort-server에 납땜한 아키텍처 결함을 수리했습니다 —— studio가 한때 env 하드코딩으로 executor에 직접 연결해 전체 플랫폼을 우회한 적이 있습니다.

7.2 핵심 역량

7.2.1 레지스트리 SSOT + 릴리스 수명주기

스킬 / 플러그인의 manifest, 버전, 상태의 단일 진실. 생산자 측 draft → in_review → published / rejected, state(active / archived)는 직교. .tueopkg 업로드가 검증(semver / 역량 선언 / 페이로드 무결성)을 거쳐 초안으로 떨어지고, 원본 패키지는 sha256 digest로 콘텐츠 주소 지정 저장.

7.2.2 서명과 신뢰 거버넌스(Ed25519)

manifest가 서명 가능한 코어 → Ed25519 detached 서명 → 검증으로 official / partner / community 3단계 신뢰 유도. 크로스 저장소 서명 알고리즘이 바이트 단위로 일치(drift-lock 테스트로 잠금). 서명을 선언했는데 검증 실패 = 위변조 / 사칭이며, 설치 시 거부.

7.2.3 설치 거버넌스(테넌트 레벨)

테넌트가 설치한 스킬 + 활성화 여부. 설치 = 배포 상태, 활성화 = 실행 스위치, 사용자 선호 = 개인 스위치, 세 레이어가 서로 혼동되지 않습니다. 호출 게이트웨이 앞에 assertEnabled 하드 게이트.

7.2.4 자격 증명 금고(테넌트 레벨 암호화)

플러그인 구성: settings 평문 + secrets 암호문(AES-256-GCM), 게이트웨이 invoke 시 복호화 주입, 사용자 / AI가 전체 과정에서 secret을 볼 수 없음. 크로스 호스트(cohort / studio) 동일 출처에서 볼 수 있음.

7.2.5 호출 게이트웨이(kind별 분배 + 결제 / 사용량 납땜)

한 번의 호출이 설치 게이트 + 결제 게이트 + 사용 가능 범위 게이트를 통과 → 자격 증명 복호화 주입 → kind별 분배: action → executor 샌드박스 / knowledge → 콘텐츠를 직접 반환해 호스트 LLM 컨텍스트에 주입(샌드박스 0, 비용 0).

★결제 게이트와 사용량 계정이 모두 게이트웨이에 납땜되어 있습니다: 어떤 간접 / 위임 호출도 자연히 게이트를 통과하고 계정이 기록되어, ‘결제 우회’ 취약점을 근절합니다.

7.2.6 구매 거버넌스 클로즈드 루프

체험 → 신청-승인 → 주문(대공 / 온라인) → 재무 확인 → 인보이스, 전 과정 기록. 예산 게이트(사용분 + 처리 중 + 본 주문 ≤ 상한), 구매자 자체 감사 파생 흐름(주문 / 권리 / 신청 / 설치 / 범위 변경을 타임라인으로 집계).

7.2.7 상업화 / 가격

가격은 제품에 붙습니다(Stripe 패러다임): 운영자가 각 스킬에 전역 가격을 설정하고, 특정 고객 테넌트에 B2B 계약 가격으로 덮을 수 있습니다. 과금 범위 철칙: 매입 또는 구독 기간만, 사용량 / 시트 과금은 하지 않습니다(사용량은 순수 경영 분석이지 계량이 아님).

7.2.8 권리 SSOT + 구독 수명주기

‘해당 테넌트가 특정 유료 스킬을 사용하도록 인가받았는가’의 단일 진실. 온라인과 오프라인 두 경로가 같은 테이블에 쓰고, 게이트는 통일해서 읽습니다. 만료 즉시 무효, 정기 스윕 폴백, 만료 전 배너 경고. 구독 갱신은 계약 + 인보이스 + 재서명을 다시 거칩니다.

7.2.9 오프라인 인가 활성화(서명 License 단일 SSOT)

프라이빗(온프레미스) / 에어갭 고객의 유료 활성화: 서명 License 파일이 단일 신뢰 루트이며, 네트워크 연결은 전송 레이어일 뿐, 에어갭은 같은 파일을 수동으로 운반. 소프트 노드 잠금 = deploymentId(플랫폼 최초 실행 시 생성, 한 파일이 여러 배포로 복사되는 것을 방지, 하드웨어를 잠그지 않아 고객을 불편하게 하지 않음). 온라인 활성화 / 하트비트 / 기술적 폐기를 만들지 않습니다(순수 계약 신뢰).

7.2.10 에어갭 오프라인 배포(.tueoupdate 통일 산출물)

스킬 bits를 내부망으로 보냅니다: 하나의 서명 업데이트 패키지가 디렉터리와 플랫폼 구성 요소를 동시에 담고, console이 하나의 가져오기 진입점. 서명 manifest는 불변 하중 벽입니다(bundle 로컬 저장은 별도 열을 쓰고, 절대 manifest를 mutate하지 않음 —— 그렇지 않으면 검증이 실패). 기본 bundle-runtime은 이미지가 필요 없습니다.

7.2.11 사용 가능 범위 + 사용량 경영 대시보드

‘테넌트 내 누가 특정 스킬을 쓸 수 있는가’ 권한 배분(mode = all / departments / users, 데이터 출처 identity SCIM). 사용량 대시보드는 ‘역량을 쓴 만큼 가치가 있었는지, 낭비와 리스크가 있는지’를 답합니다(유휴 인가 인식 = 권리는 있는데 호출 0 = 낭비된 돈).

7.2.12 권한 4단계 클로즈드 루프

개발자가 permission[] 선언 → 프론트엔드 리스크 등급 레드 마킹(네트워크 / 파일 시스템 / 실행 / 키) → 설치 시 동의 상자(부여 시점, 감사) → executor 샌드박스 런타임 강제(네트워크 권한 미부여 시 unshare로 네트워크 네임스페이스 진짜 차단, 제로 아웃바운드로 외부 유출 방지).

7.3 차별화

• 하나의 역량 계약, 두 명의 소비자: 같은 역량을 AI가 도구로(executor 샌드박스), 사람이 UI로(선언형 / 프론트엔드 bundle) 모두 사용 가능;
• 상용 클로즈드 루프가 호출 게이트웨이에 네이티브 납땜: 위임 / 간접 호출이 자연히 게이트를 통과 + 계정 기록;
• 서명 License 단일 인가 SSOT: 에어갭과 온라인이 동일 메커니즘;
• 생산 상태 키 fail-closed: 공식 서명 개인키 / 금고 마스터 키 / 세션 키 / S2S 토큰이 없으면 → 시작 거부(공개 dev seed로 공식 서명과 오프라인 License를 위조하는 것을 방지);
• 시계 되돌림 방지 고수위(high-water mark) + 구독 만료 전 테넌트 정기 스윕, 에어갭 고객이 만료된 구독을 살리려고 시계를 되돌리는 것에 대응.

8. executor —— 샌드박스 실행 기반

한 문장: AI의 두 손 —— 신뢰할 수 없는 코드 / 명령어 / 이미지를 격리 샌드박스에 넣고, 감사 가능하고, 스케줄링 가능하고, 확장·축소 가능하게 AI 직원을 위해 실제 일을 처리하고, 구조화된 결과를 돌려줍니다.

8.1 포지셔닝

cohort(워크스페이스), studio(오케스트레이션), capabilities(역량 마켓)는 ‘무엇을 할지 결정’을 담당하고, executor는 ‘실제로 만들어 내기’를 담당합니다 —— 코드 패키지 / 명령어 / 자체 이미지를 받아, K8s Job으로 격리된 Runner 샌드박스를 띄워 실행하고, 구조화된 결과를 콜백하며, 전 과정 감사. 플랫폼 전체의 통합 역량 실행면이자, 신뢰 경계 안에서 ‘사용자 코드는 신뢰할 수 없다’의 격리 벽입니다.

8.2 핵심 역량

8.2.1 다중 런타임 샌드박스 실행(python 패키지 / 범용 명령어 / 자체 이미지)

하나의 job 계약으로 세 가지 실행을 지원: python 코드 패키지(pip 의존성 설치 → import entrypoint → main(**inputs)), command 항목(언어 무관하게 임의 shell 실행), image 항목(job마다 지정 이미지 기동). 큰 입력(>64KB)은 마운트 파일로 오버플로하여 env 제한을 회피; 네트워크 권한이 없는 command 항목은 unshare --net으로 네트워크 네임스페이스를 끊고 서브프로세스를 실행.

8.2.2 K8s 네이티브 격리 + 5단계 우선순위 스케줄링 + job별 리소스 할당량

매 job이 독립 Pod로: 권한 없음, 읽기 전용 루트 파일 시스템, capabilities 전부 drop, seccomp RuntimeDefault, 실행 후 자동 회수. 5단계 우선순위(CRITICAL은 BACKGROUND를 선점 가능) + job별 CPU / 메모리 구성.

8.2.3 승인 통제 + 우선순위 큐

전역 동시성 상한 + per-tenant 할당량(DB에서 런타임 수정 가능) + 호스트 리소스 압력의 삼중 배압. 동시성 상한을 초과하는 job은 QUEUED 큐로 들어가 우선순위 + FIFO로 소진; 원자적 인수로 이중 파견 방지, 단일 테넌트 상한 도달이 다른 테넌트를 막지 않음.

8.2.4 대사 클로즈드 루프(pull is truth, callback is optimization)

콜백은 최적화 항목이며, 대사 루프가 30초마다 K8s에 진실을 적극 조회하여 좀비 job을 종료 상태로 밀고, lost로 판정하고, 진행 중(in-flight) 카운트를 자가 치유합니다. 콜백이 오지 않아도 running에서 갇히지 않습니다.

8.2.5 DAG 워크플로 오케스트레이션

방향성 비순환 그래프로 의존과 병렬을 표현하고(공유 dag_id를 가진 job 집합, 독립 테이블 없음), 실패 시 지점 재실행 가능(incremental / full).

8.2.6 멀티 테넌트 격리(fail-closed 수렴)

모든 리소스가 tenant_id에 바인딩되고, 조회 / 쓰기에 테넌트 필터를 강제합니다. 테넌트를 얻지 못하면 전부 허용하는 대신 직접 거부합니다. ‘전부 보기’와 ‘테넌트 전달 잊음’은 코드 레이어에서 모양이 다르며, 플랫폼급 집계는 명시적으로 선언해야 합니다.

8.2.7 전량 보안 감사 + Transactional Outbox 이벤트

모든 수명주기 작업이 감사 테이블에 기록됩니다; 업무 작업과 이벤트가 같은 트랜잭션으로 outbox에 들어가고, CloudEvents 1.0으로 비동기 전달(CI / 알림 / 과금 소비자), 업무가 차단되지 않습니다.

8.2.8 자격 증명과 콜백 보안

job Pod에 최소 권한 MinIO 자격 증명(bucket-scoped)을 주입; 콜백 URL에 job별 전용 HMAC token이 내장되어, 공유 token 보유자가 임의 job 상태를 조작하는 것을 방지; 종료 상태 콜백은 멱등(상태 부활 방지).

8.2.9 AI 코딩 에이전트 coding-agent

자율 코딩 에이전트: GitLab 저장소 클론 → 도구 루프로 워크오더 구현 → 자체 테스트 → 커밋 → 브랜치 푸시. 패스포트(tueo-passport 확장 포인트)를 HARD 파일 편집 게이트로 컴파일(zone 벗어나면 전부 BLOCKED); 시각 자가 검증 = 실제 Chromium 스크린샷 + 비전 모델이 이미지를 보고 판정, jsdom 추측이 아님.

8.2.10 관측 가능성

Prometheus 지표(스케줄링 지연 / 큐 대기 / per-tenant in-flight / 노드 수위) + 노드 리소스 실시간 스냅샷 + 실행 중 job의 실시간 컨테이너 로그 + 영속 데이터에서 실행 타임라인 재구성.

8.3 차별화

• 다중 런타임 통일 계약(python / command / image)이지 단일 Python 샌드박스가 아님;
• 스케줄링이 일등 시민: 테넌트 레벨 공정 + 우선순위 선점, 대부분의 샌드박스 제품은 단순 동시성 수만 가짐;
• 대사 클로즈드 루프 자가 치유: 경쟁사는 콜백이 오지 않으면 자주 멈춤;
• job별 HMAC 콜백 바인딩 + 최소 권한 자격 증명 + 네트워크 단절 샌드박스 —— 콜백과 자격 증명이 모두 job별로 격리.

9. skillplugins —— 스킬 플러그인과 SDK

한 문장: 하나의 역량 계약, 두 명의 소비자 —— AI 어시스턴트가 진짜 ‘업무를 처리’하게 하고, 기업 프로세스 역량을 서명 가능하고, 샌드박스 가능하고, 마켓에 들어갈 수 있는 플러그인으로 만듭니다.

9.1 포지셔닝

skillplugins는 TUEO 플러그인 플랫폼의 생산 측이자 계약 하중 벽, 4레이어 아키텍처의 출처입니다: skillplugins(플러그인 패키지 + SDK) / 역량 플랫폼(레지스트리 + 거버넌스 + 배치) / executor(백엔드 샌드박스) / desktop(프론트엔드 렌더링). @tueo/plugin-sdk는 manifest / capability / invocation 4레이어의 단일 출처입니다.

9.2 핵심 역량

9.2.1 플러그인 manifest 계약(PluginManifest)

플러그인 정의 = manifest(역량 선언) + backend(executor 실행) + frontend(desktop 렌더링) 세 가지. 언어 중립(input / output은 JSON Schema, executor의 Python도 검증 가능). humanSurface가 slash(명령어) / form(자동 파생 폼) / preview(4열 미리보기) 세 가지 진입점을 제공합니다.

9.2.2 플러그인 서명과 신뢰 거버넌스

릴리스 측에서 개인키로 manifest에 Ed25519 detached 서명을 하고, 로드 / 설치 측에서 신뢰 공개키 레지스트리로 검증해 신뢰 레벨을 유도. 위변조 즉시 서명 검증 실패, 설치 시 위변조 단언(anti-tamper assert).

9.2.3 백엔드 런타임 I/O 계약

입력은 cwd/inputs.json에서 읽고, 결과는 $OUTPUT_DIR/result.json에 쓰며, 대형 파일 산출물은 runner가 통일하여 MinIO로 업로드. 작성자는 serve({capabilityId: handler})만 하면 되고, I/O, 오류 정규화, 종료 코드는 전부 SDK가 받쳐줍니다.

9.2.4 참조 구현: deck(프레젠테이션)

17가지 레이아웃(title / section / bullets / kpi / twocol / process / chart / statement / agenda / compare / timeline / composite / scorecard / matrix / gantt / pillars / figure) + 행동 제목 + 4세트 디자인 언어. 같은 DSL로 HTML 미리보기와 편집 가능한 .pptx 내보내기 생성(미리보기 = 내보내기 일치, ‘미리보기는 좋은데 내보내기는 깨진다’가 나오지 않음). PptxGenJS 모티프의 우아한 폴백.

9.2.5 기존 PPT 스타일 상속

기존 .pptx 가져오기: 콘텐츠는 서버에서 파싱하고, 스타일은 플러그인이 theme1.xml의 색 구성과 글꼴을 추출하여 한 세트의 디자인 언어로 만들며, 색과 글꼴만 바꿔 플랫폼 레이아웃 품질을 지킵니다 —— 고객 브랜드 자산을 상속할 수 있습니다.

9.2.6 pharma-doc(의약 규제 예시)

의약품 동행 확인서 인식 플러그인: VLM이 12개 필드 추출 → 플러그인이 결정적 규칙 검증(승인 번호 형식 / 생산일 < 유효기한 / 유효기한 > 오늘 / 수량 > 0 / 필수 항목) → 초록 / 노랑 / 빨강 색상 재검토 미리보기. 모델 호출 0회의 검증 레이어가 멱등, 테스트 가능, 감사 가능하며, 사람이 <1%에서만 개입합니다.

9.3 차별화

• 하나의 역량 계약, 두 명의 소비자: 같은 capability를 AI(function-calling 도구)와 사람(slash / 폼 / 미리보기)에게 동시에 노출, 같은 입력에 바이트 단위 동일;
• AI는 추출과 콘텐츠, 규칙 엔진은 결정적 검증: 결과가 멱등, 테스트 가능, 감사 가능;
• 디자인 Token 기반 렌더링: 미리보기 = 내보내기, 언어 변경 = token 파일 교체, 엔진 변경 0;
• 회복력과 정직한 폴백: 단일 페이지 손상 → 자리 표시 페이지로 전체 문서를 망치지 않음; 데이터를 얻을 수 없으면 ’—’ 표시, 조작하지 않음.

10. codex-build —— 코딩 엔진

한 문장: TUEO의 코딩 코어 —— AI 직원이 ‘실제로 일하고, 실제로 산출’하게 하며, 더 이상 자술형 agent가 아니라 기업 정체성 경계와 감사 가능한 기록을 가진 실제 코딩 실행 엔진입니다.

10.1 포지셔닝

codex-build는 TUEO 플랫폼 전체의 통합 실행 엔진으로, AI 개발 팀의 코딩 코어 역할을 합니다. 서버 측과 데스크톱 측이 각자 손수 만들었던 3세트 agent 루프(약 13,300줄)를 대체합니다.

아키텍처 분업을 한 문장으로: 엔진은 ‘어떻게 할지’(실제 코드베이스 읽기 / 파일 수정 / shell 실행 / 웹 검색 / 긴 작업 / 서브 에이전트), Server는 ‘할 수 있는지, 무엇을 하는지, 어떤 기록을 남기는지’(정체성, 권한, 컨텍스트, 자격 증명, 감사), Desktop은 ‘볼 수 있고, 클릭할 수 있고, 로컬에서 접근할 수 있는지’(페어링과 렌더링).

엔진의 네이티브 상호작용과 자체 로그인 기능은 모두 잠겨 있으며, 관리 진입점만 남아 있습니다 —— 그것은 TUEO 플랫폼이 ‘기업 실행기’로 길들인 일등 시민 런타임이지, 독립 터미널 제품이 아닙니다.

10.2 핵심 역량

10.2.1 실제 코딩 실행(서술식이 아님)

‘했다고 주장’에서 ‘실제로 했다’로: agent가 실제 저장소 워크스페이스에서 클론 → 코드 읽기 → 파일 수정 → 테스트 실행 → 커밋 → 푸시 → MR 생성, 실제 파일 / diff / 브랜치 산출. 내장 도구군: read_file(image / pdf / pptx / metadata 파서 포함), search_replace, bash, grep, list_dir, monitor, scheduler, todo, web_search / web_fetch.

10.2.2 코드베이스 이해

대형 코드베이스 구조를 구축하고 탐색: 코드 인덱스(index_manager + languages + scope_graph), 워크스페이스 관리(folder trust + 파일 시스템 알림), 컨텍스트 패키지(Context Pack: 역할 / 제약 세그먼트 + 워크오더 spec / plan / AC + 모델 라우팅)를 작업에 맞춰 구체화하여 워크스페이스에 주입.

10.2.3 관리 런타임(ACP 임베디드)

Agent Client Protocol(stdio JSON-RPC)로 desktop / executor가 구동하며, 긴 세션, 실시간 이벤트 환류, 권한 및 승인 팝업 카드가 가능합니다. 확장 메서드가 권한 요청, 사용자 질문, 서브 에이전트 동의, 폴더 신뢰를 구현하며 —— 전부 데스크톱이 카드를 띄우고 회신합니다.

10.2.4 서브 에이전트 협업(엔진 레벨 하드 게이트)

메인 에이전트는 작업 복잡도에 따라 병렬 / 중첩으로 서브 에이전트를 시작할 수 있지만, 첫 번째 서브 에이전트 spawn 전에 반드시 엔진 레벨 consent 하드 게이트를 거쳐야 합니다. 불변식: 한 번만 물어봄, 사용자별 요청 무효화, 도구 능력 부여 안 함 —— ‘서브 에이전트 협업을 쓸지’를 prompt가 아닌, 기업의 매 요청마다 확인할 수 있는 결정으로 만듭니다.

10.2.5 MCP 업무 역량 연결

엔진이 MCP client로서 서버 tueo MCP Server를 소비합니다: 워크오더 / 앱 / 커넥터 / 지식 / 약속 / 첨부 / 메시지의 단일 출구가 엔진으로 들어갑니다. 업무 역량이 엔진 측에 흩어지지 않고, 자격 증명이 클라이언트로 내려가지 않습니다.

10.2.6 기업 정체성 경계

네이티브 API key / 자체 계정 로그인 / 상호작용 터미널 / headless / 릴레이 / 세션 이력 실행이 전부 영구적으로 비활성화되며, 모델 실행 관리 진입점 = ACP + identity. 세션은 owner sidecar(0600, issuer / tenant / subject)에 기록되고, new / load / prompt / cancel이 모두 fail-closed로, 크로스 테넌트 세션 탈취를 차단합니다.

10.2.7 자격 증명이 서버 밖으로 나가지 않음

엔진은 어떤 모델 공급사 키도 보유하지 않고, 서버가 발급한 단기 세션 티켓만 보유하며, 엔진 게이트웨이를 통해 실제 모델에 전달합니다. 실제 키는 한 번도 서버 프로세스 메모리를 떠나지 않습니다.

10.2.8 시각·음성 멀티모달

순수 텍스트 메인 모델이 이미지 / 오디오를 받아도 오류가 나지 않습니다: 이미지는 보조 비전 모델로 설명을 변환하고(메인 모델에 원본 이미지 폴백 금지), 음성은 엔진 내장 음성 런타임으로 처리합니다(스트리밍 받아쓰기 + 합성). 모델 라우팅은 항상 서버가 결정하며, 클라이언트가 임의 모델을 지정할 수 없습니다.

10.2.9 샌드박스와 프로세스 격리

내장 다단계 샌드박스 profile + deny glob + 네트워크 단절 정책. 멀티 테넌트가 같은 설치를 공유해도 서로 보이지 않습니다: Linux user + 독립 home(모든 사용자 상태 데이터 경로) + Bubblewrap, 테넌트별 엔진 데이터가 각자의 독립 디렉터리에 저장됩니다.

10.2.10 Folder Trust 신뢰 게이트(코드 실행면 레드라인)

hooks / MCP 구성 / 환경 구성을 가진 클론 저장소는 기본적으로 로드·실행되지 않습니다(그렇지 않으면 = 클론 즉시 원격 코드 실행). 컴파일 시점 버전 스탬프: 스탬프가 없는 빌드는 folder trust가 조용히 무효화되고, 릴리스는 반드시 발판 스크립트 + 레드라인 검증을 거칩니다(hooks 저장소는 반드시 신뢰 확인 팝업을 띄워야 하며, 그렇지 않으면 릴리스 불가).

10.2.11 업스트림 추적 가능 거버넌스(fork 건전성)

TUEO는 업스트림 변경을 패치 원장 + 출처 등가성 검증 + 계층형 커스텀 제약으로 관리합니다: TUEO_UPSTREAM.toml이 업스트림 commit SHA를 고정, 소스 아카이브 등가성 검증(file_count + manifest_sha256 + status=passed), CI가 메타데이터 일치를 강제. 언제든 ‘이 코드가 어떤 업스트림 commit에서 왔고, 어떤 패치가 바꿨고, 롤백할 수 있는지’를 답할 수 있습니다.

10.3 차별화

• ‘자술형 agent’에서 ‘실제 실행’으로: 실제 파일 / diff / MR 산출, 코딩 전달을 신뢰 가능하게;
• 하나의 코딩 엔진이 플랫폼 전체를 통일: 데스크톱 / 서버의 3세트 손수 만든 agent 루프 제거;
• 기업 신뢰 4종 세트: 정체성 경계, 자격 증명이 서버 밖으로 나가지 않음, 서브 에이전트 / 권한 / 폴더 신뢰 3중 확인 카드, 감사 가능한 기록;
• fork 거버넌스가 세일즈 포인트: 모든 패치에 원장, 모든 발판에 출처 등가성 검증, 롤백 가능 —— 프라이빗(온프레미스) 고객이 쓸 수 있음;
• 멀티 테넌트 프로세스 격리 + 단일 바이너리 전달, 오프라인 / 프라이빗 배포에 바로 적용;
• dogfood 엔지니어링: AI 개발 팀이 이 엔진으로 TUEO 자체 제품을 개발 중.

11. console —— 지능형 기반 운영 레이어 · 프라이빗 전달과 운영

한 문장: 지능형 기반의 운영 레이어 —— 베어메탈을 원클릭으로 TUEO 프로덕션 환경으로 구성하고, 이후 하나의 화면으로 모든 서비스와 미들웨어를 운영합니다.

11.1 포지셔닝

console(TUEO Console 운영 플랫폼)은 지능형 기반의 운영 레이어이자 ‘전달과 운영 기반’입니다: 위로는 모든 제품 라인을 받치고, 아래로는 k3s / Harbor / CNPG / 미들웨어를 관리합니다. 새 시스템, 기존 시스템, AI 시스템을 하나의 진입점으로 전체 체계를 운영합니다. 3종 세트로 완전한 수명주기를 구성합니다 —— console = 프라이빗 설치 도구 + 사이트 내 운영 중추(배포 오케스트레이션 / 설정 센터 / 상태 벽 / 로그 / 백업 / 업그레이드 / 감사), tueo-ci-images = 2레이어 불변 오프라인 CI 이미지, tueo-build = 코딩 엔진 소스와 발판 파이프라인. 기반(db / redis / k3s / MinIO)도 그것이 운영·관리하는 관리 대상 객체이며 —— 자기 자신조차 관리 대상 객체입니다(자체 업그레이드는 이미지만 교체, 창세 매니페스트가 영원히 SSOT).

11.2 핵심 역량

11.2.1 서비스 디렉터리 SSOT(manifest)

여러 곳에 흩어진 레지스트리를 단일 선언적 서비스 디렉터리로 수렴합니다(11+ 서비스: ops-console / postgres / redis / minio / identity / cohort-server / executor / studio-api / studio-web / capabilities-api / cohort-desktop / skillplugins), 정적 토폴로지의 단일 진실. 제품 라인 추가 = JSON 한 줄 + PR, 코드 변경 0.

11.2.2 3 driver 배포 오케스트레이션(local-dev / compose / k8s)

같은 도메인 모델 아래 세 가지 런타임 분야: 로컬 네이티브 프로세스, 단일 머신 Docker, 고객 기존 K8s. 하나의 플랫폼이 로컬 개발과 고객 단일 머신·기존 클러스터를 모두 관리합니다; 고객이 K8s가 없어도 설치할 수 있습니다(자체 k3s 기반 내장).

11.2.3 이미지 승격 게이트 + 원클릭 배포(빌드 저장소 → 실행 저장소)

CI는 이미지를 빌드 저장소에만 푸시합니다; 플랫폼이 클러스터 안에서 Harbor pull 복사로 tag를 내부망 실행 저장소로 승격시키고, tag가 도착한 후 apply + rollout. 제품 저장소가 템플릿 한 줄을 include하면 build-image + deploy-prod의 완전한 프로덕션 파이프라인을 얻고, 이미지가 온라인 빌드 저장소에서 내부망 실행 저장소로 자동 승격, 수동 작업 0.

11.2.4 설정 센터(키 AES-GCM 저장 + 버전 롤백)

일반 설정은 선언적으로 렌더링, 키는 암호문으로 저장(AES-256-GCM, 마스터 키), 버전 스냅샷 롤백 가능, 키는 절대 git에 들어가지 않습니다. 로컬 AES / Vault 이중 백엔드 지원.

11.2.5 프라이빗 운영 생명선

설치 전 진단(전면 preflight 단언), 전체 DB 백업 복구, 에어갭 원격 지원 진단 패키지, 백업 우선의 업그레이드 마이그레이션. 백업 우선 + 롤백 포인트 + 업그레이드 이력 —— 고객 현장에서 문제가 나도 백업으로 복구할 수 있고, 진단 패키지로 원격 복구가 가능합니다.

11.2.6 상태 벽 + 데이터 운영 패널

운영자가 Console 하나의 화면에서 모든 관리 워크로드와 미들웨어를 운영합니다: kubectl 불필요, 서브도메인 외우기 불필요, 데이터 포트 노출 없음. PG / Redis는 절대 공인망 ingress를 열지 않고, 무거운 작업은 필요에 따른 임시 보안 터널(짧은 TTL + 감사)로 처리합니다.

11.2.7 오프라인 업데이트 가져오기(.tueoupdate 검증 + 사전 점검 + 디렉터리 전달)

플랫폼이 오프라인 업데이트 배포 중추 역할: .tueoupdate 패키지 Ed25519 공식 검증 → 사전 점검 호환 게이트 → bundle 세그먼트는 capabilities 가져오기로, image 세그먼트는 skopeo로 Harbor에 탑재. 검증 실패 / 미서명 → 거부.

11.2.8 플랫폼 자체 업그레이드(dogfood, 이미지만 교체)

운영 플랫폼이 스스로를 배포합니다: 창세 bootstrap은 수동으로 한 번, 이후 push main 시 자동 build → promote → 이미지 교체 → /api/version 폴링으로 수렴. 업그레이드는 이미지 tag만 바꾸고 창세 매니페스트를 깨지 않습니다(PVC / 마스터 키 / ConfigMap / 게이트웨이 전부 유지). 고전적인 자체 관리 플랫폼 패턴.

11.2.9 재현 가능한 CI 기반 이미지(공급망 보안)

2레이어 불변 오프라인 CI 이미지: lock이 모든 입력을 고정(기반 이미지 digest + Debian 스냅샷 타임스탬프 + name=version apt 패키지 + 바이너리 checksum), 빌드는 재현 가능하고, 오프라인이며, 서명과 SBOM 포함. 일반 MR은 네트워크 연결 0, 다운로드 0, 빌드 자격 증명은 보호된 runner에만 존재 —— 공급망 공격 면적 최소화.

11.2.10 프라이빗 배포 키트(리플레이 가능한 kit)

베어메탈에서 TUEO 프로덕션 환경으로 구성하는 한 세트의 리플레이 가능한 스크립트 + 매니페스트: 사이트 매니페스트 한 개를 채워 00 → 60 순서로 실행, 리플레이 가능, SSH 수동 입력 불필요. TUEO는 같은 키트로 자체 사용을 강화합니다(dogfood).

11.3 차별화

• SaaS가 아닌 프라이빗(온프레미스) 주축: 고객마다 독립 단일 사이트 격리 설치, 오프라인 / 에어갭 기본, 원클릭 설치, 오프라인 bundle + license 전달;
• 과잉 설계 반대: Argo / Vault / Loki 올인원을 올리지 않고, 도구 무게가 문제 규모에 맞습니다;
• 서비스 디렉터리 = manifest 파일 SSOT: ‘DB가 진실이고 파일이 seed’의 반복 드리프트 병근을 근절;
• 진짜 dogfood: 플랫폼이 자신의 k8s driver로 스스로를 배포하고, 자신의 API로 실제 서비스를 클러스터에 배포;
• 오프라인 업데이트 공급망: .tueoupdate 패키지 검증 + 사전 점검 호환 게이트 + 디렉터리 세그먼트 전달, 미서명 패키지 거부.

12. engram —— 지식·기억 기반

한 문장: AI가 기업 자체의 지식으로 기업의 문제에 답하게 합니다 —— 지식베이스, 대화 메모리, 지식 연관을 하나의 기반으로, 쓸수록 정확해지고 스스로 자랍니다.

12.1 포지셔닝

engram은 TUEO 체계의 지식 / 기억 단일 진실(SSOT) 로, 세 가지 플랫폼급 역량을 담당합니다:

1. 기업 지식베이스: 제도, 문서, 프로세스를 검색 가능하고 검증 가능한 기업 지식으로 축적;
2. 대화 메모리: 일상 협업과 질의응답을 자동으로 장기 기억으로 축적하여, 조직이 사용해도 잊지 않음;
3. 지식 연관: 지식 사이의 연결을 이해하고, 다단계 후속 질문을 지원 —— 사실을 판단으로 이어줌.

engram은 identity, inference와 함께 3대 기초 기반으로 나란히 서며, 스위트 안의 모든 제품이 소비합니다. engram이 답하는 것은 ‘당신이 무엇을 알고 무엇을 기억하는가’이고, identity가 답하는 ‘당신이 누구인가’와 서로 보완합니다.

12.2 핵심 역량

12.2.1 기업 지식베이스

제도, 문서, 프로세스를 기업 지식베이스로 축적하고, 질의응답을 직접 내부 자료에 기반해 답합니다 —— 근거가 있고, 조작하지 않으며, AI가 범용 지식의 막연한 이야기가 아니라 기업 자체의 지식으로 기업의 문제에 답하게 합니다.

12.2.2 대화 메모리 · 자동 축적

일상 협업과 질의응답을 자동으로 장기 기억으로 축적하고, 시스템이 자동으로 정리하고, 노이즈를 제거하고, 모순을 해소합니다 —— 지식베이스가 쓸수록 정확해지고 스스로 자랍니다. 방을 바꾸거나 다중 AI가 협업해도 각자 처음부터 시작하지 않습니다.

12.2.3 지식 연관 · 다단계 후속 질문

단일 지점 질문에 답할 뿐만 아니라, 지식 사이의 연결을 이해하고 ‘먼저 A를 묻고 이어서 B를 추적하는’ 다단계 후속 질문을 지원합니다 —— 사실을 판단으로 이어주지, 산발적인 검색 결과로 남기지 않습니다.

12.2.4 콘텐츠 안전 · 등급 통제

민감 콘텐츠를 등급별로 통제하며, 누가 무엇을 볼 수 있고 무엇을 외부로 보낼 수 없는지를 기업 제도에 따라 유연하게 구성합니다 —— 민감할수록 더 통제되고, 원천에서 유출을 방지합니다.

12.2.5 권한 통일 · 전 과정 기록

지식 접근과 정체성 권한을 통일 관리하고, 매 열람과 매 답변을 추적할 수 있습니다 —— 부서 간 데이터를 엄격히 격리하고, 각자 자기 것만 보며, 같은 정체성 인증 체계에 연결됩니다.

12.2.6 경량 배포 · 데이터가 영역 밖으로 나가지 않음

배포가 가볍고, 점유가 작으며, 기업 지식은 항상 기업 내부에 머뭅니다 —— 데이터가 영역 밖으로 나가지 않고, 쓸수록 기업을 더 잘 이해하며, 완전 오프라인 배포가 가능합니다.

12.3 차별화

• 3-in-1 기반: 지식베이스, 대화 메모리, 지식 연관을 하나의 기반으로 관통하지, 여러 단일 포인트 도구를 조립하지 않음;
• 쓸수록 정확: 자동 축적으로 지식베이스가 스스로 자라며, ‘데이터는 영역 밖으로 나가지 않고, 지식은 축적되며, 바꿀 수 없다’는 체감되는 세일즈 스토리;
• 프라이빗(온프레미스) 경량: 배포가 가볍고, 단일 기반이며, ToB 프라이빗 포인트를 전부 충족;
• 모든 제품이 소비: cohort의 AI 직원이 그 기억으로 결정하고, studio가 편성한 애플리케이션이 그 지식베이스로 실체 있는 답변을 합니다.

13. inference —— 연산·모델 서비스

한 문장: 기업 프라이빗 AI 인프라에 연산과 모델의 통일된 제어 평면을 제공합니다 —— 이기종 연산을 통합 관리하고, 모델 서비스에 거버넌스를 더하며, 하나의 클로즈드 루프로 대조 가능하고 롤백 가능합니다.

13.1 포지셔닝

inference는 TUEO 체계의 연산·모델 서비스 기반으로, 세 가지 플랫폼급 역량을 담당합니다:

1. 이기종 연산 통합 관리: 제조사와 모델이 다른 가속 하드웨어를 하나의 제어 평면에서 관리하고, 각 풀이 독립 운영;
2. 표준 모델 서비스: 업계 표준의 모델 호출 방식을 제공하여, 기존 애플리케이션이 거의 수정 없이 연결;
3. 연산 거버넌스 클로즈드 루프: 모델, 배포, 학습, 할당량, 사용량과 감사를 하나의 제어 평면으로, 비용을 파악.

inference는 identity, engram과 함께 3대 기초 기반으로 나란히 서며, 전체 체계의 모델 호출 통일 진입점입니다 —— 각 제품이 각자 모델 서비스에 연결하지 않습니다.

13.2 핵심 역량

13.2.1 이기종 연산, 하나의 평면

제조사와 모델이 다른 가속 하드웨어를 하나의 제어 평면에서 통일 관리합니다 —— 각 풀이 독립 운영되고 서로 간섭하지 않으며, 연산 상황이 투명하게 보이고, 이기종 리소스를 한 덩어리로 섞지 않습니다.

13.2.2 표준 모델 서비스, 바로 사용 가능

업계 표준의 모델 호출 방식을 제공하여, 기존 애플리케이션이 거의 수정 없이 연결됩니다 —— 하부가 어떤 하드웨어인지 애플리케이션이 알지 못하고, 런타임 차이를 차단합니다.

13.2.3 모델 전체 수명주기 관리

모델의 연결, 출시, 업그레이드, 확장·축소와 롤백의 전 프로세스를 관리합니다 —— 실행 중인 서비스가 안정적으로 중단 없이 유지되고, 변경이 통제 가능하며, 되돌릴 수 있습니다.

13.2.4 모델 학습, 관리 작업

모델 미세 조정과 학습을 관리 작업으로 실행하고, 온라인 서비스와 같은 플랫폼에서 관리하며 진행 상황이 보입니다 —— 임시 스크립트에 작별하고, 학습 산출물을 통일 아카이브합니다.

13.2.5 접근 거버넌스 · 할당량 · 감사

누가 호출할 수 있고, 얼마나 호출하며, 얼마를 썼는지를 정체성과 권한에 통일 연결합니다 —— 매 호출을 귀인하고, 계량하고, 감사할 수 있으며, 비용을 파악할 수 있습니다.

13.2.6 오프라인 전달 · 현장 수용

완전 오프라인 설치, 업그레이드와 롤백을 지원하고, 현장에서 진단과 수용을 제공합니다 —— 에어갭 환경에서도 전달할 수 있고, 연산 역량의 실현이 보장됩니다.

13.3 차별화

• 연산도 데이터센터로: 애플리케이션만 데이터센터에 넣는 것이 아니라, 모델 서비스와 추론도 고객 데이터센터에 배포 —— 데이터와 모델의 외부 호출 0;
• 이기종 정직함: 다른 하드웨어는 각 풀이 독립이며, 통일 리소스 풀로 위장하지 않고, 연산 상황이 투명하게 보임;
• 하나의 클로즈드 루프: 모델, 배포, 학습, 할당량, 사용량, 감사를 하나의 제어 평면으로, 대조 가능하고, 관측 가능하고, 롤백 가능;
• 모든 제품이 소비: cohort와 studio의 AI 애플리케이션이 그것을 통해 모델을 호출하고, engram의 지식 질의응답이 그것으로 연산을 공급받습니다.

14. 한 번의 호출, 완전한 여정

한 줄의 말에서 통제된 실제 실행까지, 하나의 워크오더의 완전한 여정:

① 사람이 cohort 그룹 채팅에서: @엔지니어 AI 「이 버그를 고쳐줘」
   ↓ coordinator 라우팅(서버 직무 점수 + LLM 중재 + 감사)
② AI 개발 팀 트라이지: 의도 인식 → DoR(AI가 재현 단계 자체 보완) → TriageService 배정
   ↓ passport 게이트 + 도구 화이트리스트 강검증
③ 워크오더 상태 머신: triaged → spec → plan → coded → reviewed → tested → merged
   ↓ 코딩 실행(executor 샌드박스 / 로컬 페어링)
④ 엔진이 코드를 실제 수정, 실제 테스트, 실제 커밋; 시각 자가 검증
   ↓ MR을 cohort가 GitLab API로 개설 → Code Review → Merge 게이트
⑤ 결과가 워크오더에 피드백, 대화 스레드에 환류; AI 복기가 장기 기억에 기록

전 과정을 identity가 인증하고, capabilities가 거버넌스하며(제3자 역량 호출 시), executor / 엔진이 격리하고, 감사가 기록합니다 —— AI가 강할수록, 경계가 명확합니다.

15. 크로스 제품 설계 원칙

TUEO는 각자 제각각인 제품 집합이 아니라, 통일된 설계 철학을 가진 시스템입니다:

생산 / 소비 2분법은 전체 체계에서 가장 핵심적인 아키텍처 판결입니다: 누가 ‘역량의 진실’을 보유하고(capabilities), 누가 ‘역량을 소비’하기만 하는지(cohort / studio) —— 경계를 넘지 않고, 평행 세계를 만들지 않습니다.

SSOT 수렴은 전체 체계의 두 번째 핵심입니다: 조직 디렉터리 → identity, AI 직원 이름 → identity, AI 직원 직업 프로필 → registry, 역량 → capabilities, 메시지 → cohort, 실행 → executor, 오케스트레이션 → studio, 전달 → console. 모든 경계에 단일 진실이 있으며, ‘두 곳에 각자 한 부씩 두고 조금씩 표류하는’ 결함의 병근을 제거합니다.

16. 보안과 규정 준수 체계

14.1 심층 방어

14.2 증명 가능한 감사

• identity: per-tenant SHA-256 contentHash + prev_hash 해시 체인, 위변조(삽입 / 삭제 / 재배열 / 행 수정) 감지 가능;
• cohort: 20종 감사 이벤트를 서버에서 수렴 + 관리자 웹 콘솔에서 조회 / 보존 / 아카이브;
• studio: run-trace 이벤트 로그(append-only)에서 감사를 투영, 각 건을 ‘리플레이’하여 실행 궤적으로 돌아갈 수 있음;
• capabilities: 일등 불변 감사 테이블(마이그레이션은 SELECT + INSERT만 부여, 위변조 불가);
• executor: 전 작업 감사 + CloudEvents 이벤트 외부 전송.

14.3 멀티 테넌트 격리

플랫폼 전체의 통일 모델: identity의 토큰이 테넌트를 명시 → 각 제품 RLS로 물리적 격리 → fail-closed(테넌트를 얻지 못하면 직접 거부). 하나의 시스템이 멀티 테넌트 / 다중 부서를 서비스할 수 있고, 테넌트 간 누출 0.

17. 프라이빗(온프레미스)과 오프라인 전달

15.1 전달 형태

• 오프라인 bundle + license: 전체 체계를 오프라인 bundle로 묶고, 서명 License로 활성화하며, 완전히 네트워크가 단절된 상태에서도 운영 지원;
• 자체 k3s: 고객의 기존 K8s 클러스터에 의존하지 않음; 고객 기존 클러스터의 전용 namespace를 관리할 수도 있음;
• 단일 도메인 일체형 기기: 단일 외부 도메인 + 경로 라우팅, 모든 제품이 동일 출처, 하나의 세션 표준 OIDC;
• 데이터는 기업 밖으로 나가지 않음: 모델은 고객 자체 관리 게이트웨이 / 로컬 모델 사용, 키는 고객 네트워크 밖으로 나가지 않고, 전 과정 감사 가능.

15.2 에어갭 공급망

• 재현 가능한 CI: 2레이어 불변 오프라인 이미지, 빌드 네트워크 연결 0, 서명과 SBOM 포함;
• 통제된 업데이트: .tueoupdate 서명 패키지(Ed25519 검증 + 사전 점검 호환 게이트 + 디렉터리 세그먼트 전달), 미서명 패키지 거부;
• 오프라인 활성화: 서명 License 네트워크 연결 없이 활성화 + 소프트 노드 잠금 deploymentId.

15.3 운영 접근성

하나의 진입점으로 모든 서비스 + 미들웨어 운영: 설정 / 로그 / 상태 / 배포 / 백업 / 업그레이드 / 감사가 모두 운영 플랫폼 하나의 화면에서. 데이터 포트가 노출되지 않고, 무거운 작업은 필요에 따라 임시 보안 터널로 처리.

18. 적용 시나리오와 고객 가치

16.1 목표 산업

고복잡도, 고거버넌스, 고실시간 협업 산업: 제조(계약 이행), 금융(리스크 관리 프로세스), 의료(민감 협업), 공공 행정, 경찰, 에너지, 물류, 유통, 교육, 법률.

16.2 전형적인 고객 프로필

• 주요: 이미 디지털 시스템을 보유하고, AI를 조직 운영에 들어가게 하려는 중대형 기업; AI는 보유했지만 실행 / 보안 / 복구 레이어가 부족한 기업;
• 차순위: 기업 AI 플랫폼 시범을 하고 싶은 부서급 고객.

16.3 고객 가치

19. 현황과 로드맵

다음은 2026-08의 현황입니다. 10개 제품이 모두 프로덕션 운영에 투입되었습니다; 지속적으로 개선 중인 강화 기능은 해당 제품 항목 뒤에 표시합니다.

17.1 이미 실측 검증된 완전한 클로즈드 루프 역량

다음 역량은 모두 실제 환경에서 실행 검증되었으며, 대외 발표해도 안심할 수 있습니다:

• AI 개발 팀 dogfood 클로즈드 루프: 워크오더 → Passport 게이트 → LLM 트라이지 → 실제 코딩 → LLM 리뷰 → 실제 GitLab CI → 실패 자동 수리 → 실제 병합 → 자동 배포 → 상태 확인 → 롤백. TUEO가 자신의 8명 AI 직원으로 자신의 5개 코드 저장소를 개발합니다;
• AI가 기존 시스템 운영: ai-ops 운영 AI가 MCP로 연결되어, 알람 / 점검 / 용량 관리 / 로컬 다단계 실행 계획을 담당하고, 기존 시스템 운영을 지원;
• 역량 총괄(System-as-Capability): OA / ERP / CRM / MES 등 기존 시스템을 AI가 호출하고, 권한을 부여하고, 감사하고, 계량할 수 있는 역량으로 연결, 역량 플랫폼 게이트웨이와 융합;
• studio 오케스트레이션 엔진: 11종 노드 + 이벤트 소싱 + 영속 일시 중지-복구가 프로덕션 운영, 지능형 기반 정의 레이어의 오케스트레이션 심장 역할;
• 역량 플랫폼 소비 측 수렴: cohort / studio가 모두 SDK / S2S로 역량 플랫폼을 소비(설치 게이트 / 결제 게이트 / 범위 게이트 / 자격 증명 주입), 소비 측이 더 이상 실행 기반에 직접 연결되지 않음.

이정표: 프라이빗(온프레미스) 전달이 헌법적 주축; 10개 제품이 모두 프로덕션 운영; AI 개발 팀이 TUEO 자체 제품으로 TUEO를 개발(dogfood)하는 것이 상례; 지능형 기반의 완전한 클로즈드 루프(정의 → 개발 → 테스트 → 투입 → 운영 → 역량 재사용 → 총괄)가 실제 환경에서 구동됨.

부록 C · 용어집

TUEO —— AI를 당신 조직의 정규 직원으로 만듭니다.