글
실행 가능한 비즈니스 온톨로지, 런타임 거버넌스, 에이전트가 운영하는 애플리케이션에 관한 글 51개.
추천 글
추천 글
여기서부터: 「온톨로지가 곧 소프트웨어다」가 무슨 뜻인지, 비즈니스 정의 계층은 누가 소유해야 하는지, AI가 만든 앱이 왜 코드가 아니라 메타데이터여야 바꿀 수 있는지.
-
「온톨로지가 곧 소프트웨어다」는 무슨 뜻인가? 실행 가능한 비즈니스 온톨로지의 정의
이 문장은 ObjectStack의 포지셔닝이고, 이 글은 그 정의다. 실행 가능한 비즈니스 온톨로지는 여섯 종류의 핵심, 네 가지 투영, 그것이 아닌 세 가지로 이루어지며, 핵심과 투영을 가르는 테스트가 있다.
앱 개발 개발자 온톨로지실행 가능한 비즈니스 온톨로지 -
열린 기업 온톨로지: 비즈니스 정의 계층은 누가 소유해야 하는가
2025년 11월부터 2026년 8월까지 다섯 플랫폼이 비즈니스 정의 계층을 출시했고 — 둘은 온톨로지로, 셋은 의미 계층으로 — 대부분 MCP 읽기 경로를 열었다. 그러나 정의 자체는 안에 남는다. 프로토콜은 열리고 정의는 닫혔다 — 소유권 질문은 더 날카로워졌다.
보안과 거버넌스 비즈니스 리더 온톨로지시맨틱 레이어MCPFabric IQUnity CatalogSnowflakePalantirLooker -
AI-native 애플리케이션의 핵심은 코드 생성이 아니라 메타데이터 생성이다
코드 생성은 프로토타입을 빠르게 만들 수 있지만, 엔터프라이즈 애플리케이션에는 객체, 필드, 관계, 뷰, 권한, 워크플로, 액션, Agent 도구를 함께 통제하는 메타데이터 런타임이 필요합니다.
앱 개발 비즈니스 리더 -
Vibe Coding 기술 부채: AI가 만든 앱은 왜 나중에 바꾸기 어려운가
AI가 만든 경비 정산 시스템은 몇 달 동안 잘 돌아갔다. 하지만 세무 규칙이 바뀌자 아무도 읽어 본 적 없는 12,000줄 코드를 건드리지 못했다. 장기 시스템에는 코드가 아니라 검토 가능한 정의가 필요하다.
앱 개발 IT / CIO
최신 글
최신 글
ObjectOS 블로그의 최신 글입니다.
-
익명 방문자가 거버넌스된 업무 앱에 폼을 제출하게 하려면? 공개된 문 하나, 너비는 필드 다섯 개
v17부터 익명 데이터 접근은 항상 거부된다. 유일하게 열린 문은 공개 폼 뷰다. 런타임이 폼 자체에서 권한을 도출한다 — 필드 다섯 개가 들어오고, 한 행이 만들어지고, 돌아오는 것은 그 id뿐이다. 18.3.0에서 실측.
앱 개발 비즈니스 리더 공개 폼Web-to-Lead익명 접근 -
누가 고객 레코드를 열었는지, AI 에이전트까지 포함해 증명할 수 있는가? 레코드 조회 감사와 조회 행이 결코 기록하지 않는 네 가지
@objectstack/cli 18.3.0에서 사람의 REST 읽기와 에이전트의 MCP get_record는 각각 sys_audit_log에 read 행 하나를 남겼고, 목록·미등록 객체·거부된 읽기는 아무것도 남기지 않았다. 행이 담는 것과 결코 담지 않는 네 가지.
보안과 거버넌스 IT / CIO 감사 추적레코드 조회 감사AI 에이전트컴플라이언스 -
뷰, 대시보드, 앱은 온톨로지의 투영이다: 그것이 리뷰에서 바꾸는 것
ObjectStack 번들 앱에 필드 하나를 더하면 테이블, REST API, MCP describe 호출, Console 폼은 스스로 따라오고, 필드 이름을 고정한 뷰, 데이터셋, 번역은 그대로다. 명명 테스트가 어느 쪽인지 알려 준다.
앱 개발 개발자 온톨로지실행 가능한 비즈니스 온톨로지리뷰 가능한 diff메타데이터 리뷰 -
옛 시스템의 스프레드시트를 AI가 만든 앱으로 어떻게 가져오나? 임포트 매핑, 드라이 런, 그리고 한 행이 매칭되지 않는 세 가지 결말
ObjectStack 18.3.0에서 측정: 이름 붙은 임포트 매핑이 낯선 헤더와 코드를 한 객체의 필드로 투영하고, 드라이 런은 아무것도 저장하지 않은 채 행별 전체 보고서를 돌려주며, 매칭되지 않는 행은 생성되거나 건너뛰거나 실패한다.
통합과 데이터 비즈니스 리더 CRM 데이터 임포트임포트 매핑드라이 런 -
AI 모델은 기업에서 무엇이 부족한가? 세계, 손, 울타리
지능이 아니다. 기업에 들어온 모델에게는 추론할 세계, 행동할 손, 행동을 둘러싼 울타리가 없다. 실행 가능한 비즈니스 온톨로지 하나가 세 가지를 모두 공급하며, 출처를 단 표가 각각을 런타임 메커니즘에 대응시킨다.
AI와 에이전트 IT / CIO AI 에이전트실행 가능한 비즈니스 온톨로지MCP에이전트 권한 -
검증 규칙, 훅, 플로우? AI가 쓴 앱에서 비즈니스 규칙은 어디에 살아야 하는가 — CRM 하나, 규칙 일곱, 집 세 곳
CRM 하나 위의 비즈니스 규칙 일곱 개, 각각 놓일 수 있는 집 세 곳. 선택은 취향이 아니라 표다: 술어는 검증 규칙, 저장 전 레코드 재작성은 훅, 나머지는 모두 플로우 — 플로우는 데이터로 리뷰되기 때문이다.
앱 개발 개발자 CRM AI 에이전트비즈니스 규칙 -
AI가 조용히 바꾼 권한을 배포 전에 어떻게 잡아내는가? 7개 항목짜리 CRM으로 실측한 접근 매트릭스 스냅샷 게이트
@objectstack/cli 18.2.0에서 에이전트가 allowDelete를 false에서 true로 바꿔도 os validate는 아무것도 보고하지 않는다. 옵트인한 앱에서는 os compile이 빌드를 실패시키고, 누가 무엇을 얻었는지 한 줄로 적어 사람이 스냅샷을 다시 만들 때까지 멈춘다.
보안과 거버넌스 개발자 AI 에이전트에이전트 권한리뷰 가능한 diff -
실행 가능한 비즈니스 온톨로지를 쓰지 말아야 할 때는 언제인가?
실행 가능한 비즈니스 온톨로지가 오늘은 맞지 않는 다섯 가지 워크로드, 대신 쓸 것, 잘못 골랐을 때의 비용, 그리고 모든 행에 출처를 단 결정표.
앱 개발 IT / CIO 온톨로지실행 가능한 비즈니스 온톨로지언제 쓸까 -
에이전트가 운영하는 앱: 모든 객체와 액션이 사용자 권한 아래의 MCP 도구가 될 때
에이전트가 운영한다는 것은 앱이 이미 MCP 서버이고 에이전트가 사용자로서 접속한다는 뜻이다. 한 번의 실행, 두 사용자, 하나의 액션: 같은 열두 개의 도구, 그리고 권한 결정은 목록이 아니라 매 호출마다 내려진다.
AI와 에이전트 개발자 AI 에이전트MCP에이전트가 운영 -
비즈니스 앱이 AI가 쓸 수 있으려면? 네 개의 게이트: Typed, Validated, Reviewed, Governed
AI가 쓸 수 있다는 것은 모델이 아니라 대상 형식의 성질이다. 네 개의 게이트, 한 번의 실제 실행: 고의적 실수 세 개, 49개 규칙, 위치가 특정된 오류 세 개, 그리고 수정 후 통과.
AI와 에이전트 개발자 AI 에이전트AI가 작성 -
실행 가능한 온톨로지 vs 지식 온톨로지: 「상속 없음, 공리 없음, 추론기 없음」이 왜 핵심인가
지식 온톨로지는 추론되기 위해, 실행 가능한 비즈니스 온톨로지는 검증되고 실행되기 위해 만들어진다. 증거는 키 하나다. abstract는 상속을 약속했고, 아무것도 하지 않았으며, 남겨지는 대신 제거되었다.
앱 개발 개발자 온톨로지실행 가능한 비즈니스 온톨로지지식 그래프 -
온톨로지가 곧 소프트웨어다
기업 소프트웨어는 인터페이스를 세 번 바꿨지만 사용자는 한 번도 바뀌지 않았다. 에이전트는 사십 년 만의 새 사용자다. 필요한 것은 API가 아니라 런타임이 실행하고, AI가 쓰고, 에이전트가 운영하고, 당신이 소유하는 온톨로지다.
AI와 에이전트 일반 온톨로지AI 에이전트실행 가능한 비즈니스 온톨로지 -
FDE(포워드 디플로이드 엔지니어)는 어떤 도구를 쓰나? 온톨로지 우선 오픈 스택
FDE가 60–180일짜리 배포에서 실제로 무엇을 만드는가, 이 일을 정의하는 다섯 가지 고통, 그리고 2026년의 모방 물결이 왜 직군만 베끼고 그 아래의 기반은 베끼지 못했는가.
AI와 에이전트 개발자 온톨로지MCP포워드 디플로이드 엔지니어Palantir -
업무 앱은 몇 토큰일까? 완전한 CRM 전체가 150k 미만
완전한 CRM은 150k 토큰 미만의 타입 메타데이터로 구성됩니다. 비즈니스 로직은 100k 미만, UI는 약 50k이며, 번들 레퍼런스 CRM은 여전히 약 16k입니다.
AI와 에이전트 개발자 CRM AI 에이전트 -
AI 에이전트가 운영 데이터베이스를 삭제할 때: 런타임 가드레일이 필요한 이유
Replit 데이터베이스 사고가 보여준 구조적 교훈은 agent의 영향 반경을 프롬프트에만 맡기면 안 된다는 것이다. 권한, 승인, 감사는 런타임이 강제해야 한다.
AI와 에이전트 IT / CIO AI 에이전트Replit -
Retool RBAC와 감사 로그: 거버넌스를 갖춘 AI 앱 개발용 Retool 평가
Retool의 RBAC, 감사 로그, 접근 정책을 Retool 공식 문서로 검증한다. AI가 생성한 앱에서 무엇을 다스리는지, 엔터프라이즈 앱에서 Retool과 Lovable은 어떻게 다른지, 그리고 남는 권한 간극까지.
앱 개발 개발자 RetoolRBAC감사 로그Lovable -
Power Platform 락인: Dataverse, Azure, 셀프 호스팅을 어떻게 판단할 것인가
Power Platform의 강점은 분명하다. ID, Teams, Dynamics, 청구가 같은 테넌트 안에 있다. 다만 주권, 규모 비용, AI 변경 리뷰가 중요하다면 Dataverse와 Azure 런타임의 경계를 먼저 확인해야 한다.
보안과 거버넌스 IT / CIO DataversePower AppsPower Platform -
Lovable는 프로덕션에 안전한가: 접근 제어 리뷰의 문제
Lovable는 빠른 프로토타입에 강하다. 하지만 프로덕션 시스템에서 물어야 할 것은 작동하는지가 아니라, 누가 접근 제어를 검토할 수 있는지다. RLS, 프런트엔드 필터, 보안 스캔의 경계를 구분해야 한다.
보안과 거버넌스 개발자 Lovable -
Airtable Omni: 생성된 결과물을 수정할 수 있나, 그리고 변경은 누가 승인하나?
Airtable Omni는 한 문장으로 실제 운영되는 앱을 만든다. 생성된 결과물은 요소의 소스 코드까지 수정할 수 있다. 하지만 대부분의 변경은 Omni가 만드는 즉시 적용되므로, 검토는 변경 전이 아니라 후에 온다.
앱 개발 비즈니스 리더 AirtableAirtable Omni -
AI가 앱을 쓴 뒤: 그 diff를 리뷰하고 Merge할 수 있는가
AI는 돌아가는 앱을 빠르게 생성하고 CI도 통과할 수 있다. 진짜 문제는 아무도 전체를 이해하지 못하는 큰 PR에 누가 책임지고 Merge할 수 있느냐다.
앱 개발 개발자 -
Agent 규칙 파일 작성법: AI가 거버넌스 가능한 앱을 생성하게 하기
AGENTS.md, .cursor/rules, CLAUDE.md는 코드 스타일만 다뤄서는 안 된다. 권한, 승인, 감사, 대상 메타데이터 형식을 쓰면 AI 생성 앱은 처음부터 검토하기 쉬워진다.
AI와 에이전트 개발자 MCPAI 에이전트 -
EU AI Act 감사 준비: 당신의 AI 런타임은 증거를 낼 수 있는가
AI 판단의 전체 기록을 요구받을 때 모델 품질만으로는 부족하다. 런타임은 권한, 증거, 감독, 감사 이력을 보여줄 수 있어야 한다.
보안과 거버넌스 IT / CIO -
MCP 보안: 프로토콜만으로는 왜 충분하지 않은가
MCP와 A2A는 agent와 도구의 연결을 쉽게 만든다. 하지만 연결은 인가가 아니다. 기업에 필요한 것은 호출마다 신원, 권한, 감사를 강제하는 도구 계층이다.
AI와 에이전트 IT / CIO MCP거버넌스 도구AI 에이전트A2A -
AI Agent 파일럿이 프로덕션 전에 실패하는 이유: 빠진 네 계층
데모에서 박수받은 agent가 법무의 질문 하나로 멈추는 경우가 있다. 문제는 모델이 아니라 의미, 권한, 승인, 감사라는 네 실행 계층이 없다는 데 있다.
AI와 에이전트 비즈니스 리더 AI 에이전트 -
AI Agent 가격: 동작당 과금과 셀프 호스팅 실행 비용
동작 단위나 token 단위 과금은 유연해 보이지만, agent가 자율적일수록 도구 호출은 늘어난다. 비용은 사용량 곡선, 데이터 반출, 락인, 자체 운영의 분기점을 함께 봐야 한다.
보안과 거버넌스 비즈니스 리더 AI 에이전트Agentforce -
Agentforce, Copilot Studio 너머: 왜 어떤 기업은 개방형, 셀프 호스팅 런타임을 택하는가
한 회사가 Agentforce에 서명하기 직전, 벽 바깥에 있는 데이터 절반에 닿지 못한다는 사실을 발견했다. 닫힌 스위트와 열린 셀프 호스팅 런타임을 정직하게 비교하고, 언제 무엇을 고를지 — 그리고 왜 '둘 다 쓰기'가 정답일 때가 많은지 짚는다.
AI와 에이전트 IT / CIO AgentforceCopilot StudioServiceNow -
Ontology는 AI 스택의 표준이 될까? 런타임이 열려 있어야 하는 이유
Ontology는 AI 스택의 표준 구성 요소가 될까? agent 인터페이스는 이미 그렇게 됐다. Ontology MCP가 2026년 6월 GA로 전환됐다. 정의 계층도 뒤따르고 있다. 런타임은 닫힌 채로 남았고, 이동성은 바로 거기에 있다.
보안과 거버넌스 비즈니스 리더 온톨로지MCPPalantir시맨틱 레이어 -
한 문장에서 객체, 뷰, 권한, Agent까지: AI Builder 생성 체인
AI Builder에서 중요한 것은 한 문장을 페이지로 바꾸는 것이 아니라, 비즈니스 요구를 객체, 필드, 뷰, 워크플로, 권한, 자동화, Agent 도구로 분해하는 것입니다.
앱 개발 비즈니스 리더 AI 에이전트 -
Airtable처럼 만들고, 대화처럼 수정하는 애플리케이션
AI Builder의 가장 선명한 제품 이미지는 표 기반 애플리케이션 구축과 자연어 상호작용의 결합입니다. 객체, 필드, 뷰, 권한, 자동화를 대화로 생성하고 수정할 수 있습니다.
앱 개발 비즈니스 리더 Airtable -
대화로 업무 시스템 바꾸기: 필드, 워크플로, 뷰, 자동화
AI Builder의 진짜 제품 가치는 지속적인 대화형 개선에 있다. 필드, 워크플로, 뷰, 권한, 자동화를 메타데이터 계층에서 안전하게 진화시킬 수 있다.
앱 개발 비즈니스 리더 -
고객 문제를 스스로 이해하는 지원 시스템: AI 티켓 허브 만들기
문의, 고객 이력, SLA, 지식 베이스를 하나의 티켓 허브로 묶는다. AI는 답변을 서두르는 것뿐 아니라 권한과 감사 경계 안에서 다음 조치를 제안해야 한다.
앱 개발 비즈니스 리더 케이스 관리고객 포털 -
영업이 CRM을 손으로 채우지 않게: 대화형 AI 세일즈 어시스턴트
영업 메모, 기회, 후속 조치를 AI가 정리한다. 중요한 것은 입력을 줄이는 것뿐 아니라 고객 데이터를 권한 범위 안에서 다루는 것이다.
앱 개발 비즈니스 리더 CRM AI 에이전트 -
프로젝트 리스크는 진행 업데이트에 숨어 있다: AI 프로젝트 관리 어시스턴트
진행 업데이트, 이슈, 지연 신호를 읽어 프로젝트 리스크를 더 일찍 발견한다. AI는 제안할 수 있지만 상태 변경과 알림은 권한과 승인 아래 움직여야 한다.
앱 개발 비즈니스 리더 -
공급업체 리스크를 더 일찍 보기: AI 구매 의사결정 앱
공급업체, 가격, 납기, 컴플라이언스 정보를 연결해 구매 판단의 리스크를 더 일찍 발견한다. AI 제안은 승인과 감사가 있는 업무 흐름에 올라야 한다.
앱 개발 비즈니스 리더 공급망과 구매 제조 -
경비 심사는 OCR만이 아니다: 규칙을 이해하는 AI 재무 심사 앱
경비 심사는 OCR만으로 끝나지 않는다. AI는 영수증, 사내 규정, 예외 사유를 읽고 승인자가 검토할 수 있는 형태로 리스크를 제시한다.
앱 개발 비즈니스 리더 금융 서비스 -
티켓 제출에서 대화로: AI 기업 서비스 센터
사내 문의를 티켓 제출에서 대화로 옮긴다. AI는 답변 후보를 내고 필요한 절차로 안내하지만, 직원 데이터와 승인은 런타임이 지켜야 한다.
앱 개발 비즈니스 리더 HR 및 내부 앱케이스 관리 -
계약 검토를 먼저 AI에게 맡길 수 있을까: AI 계약 리스크 앱
계약 리스크, 빠진 조항, 승인 경로를 AI가 먼저 읽는다. 법무 판단을 대체하지 않고, 검토 가능한 차이와 감사 증거를 남기는 앱이어야 한다.
앱 개발 비즈니스 리더 금융 서비스 -
콘텐츠 팀의 AI 워크벤치: 아이디어부터 회고까지
기획, 작성, 리뷰, 배포, 회고를 하나의 AI 워크벤치로 묶는다. 콘텐츠 운영에서도 권한, 승인, 이력은 생성 속도만큼 중요하다.
앱 개발 비즈니스 리더 통신과 미디어 -
규정을 손으로 뒤지는 컴플라이언스에서: AI 내부통제 앱
규정, 증거, 예외, 시정 작업을 연결해 내부통제를 지속적으로 확인한다. AI는 판단을 돕고, 사람의 승인과 감사 로그를 남겨야 한다.
앱 개발 IT / CIO 금융 서비스 -
비즈니스 시스템에 Agent 붙이기: 실행 가능한 AI 워크벤치
업무 시스템에 agent를 붙인다면 채팅창만으로는 부족하다. 실행 가능한 액션, 권한, 승인, 감사를 같은 워크벤치에서 다뤄야 한다.
앱 개발 IT / CIO 거버넌스 도구AI 에이전트에이전트 권한 -
기업 AI 애플리케이션 플랫폼을 먼저 셀프 호스팅해야 하는 이유
AI가 업무 데이터를 읽고, 워크플로를 실행하고, 애플리케이션을 생성하고, 도구를 호출한다면 기업은 객체, 권한, 도구, 승인, 감사를 제어하는 런타임을 통제해야 합니다.
보안과 거버넌스 IT / CIO -
하나의 요구사항에서 실행 앱까지: 수리 업무로 보는 ObjectStack 메타데이터
장비 수리 시나리오를 통해 AI Builder가 하나의 요청을 객체, 필드, 관계, 뷰, 권한, 작업, 워크플로, API, 에이전트 도구로 바꾸는 과정을 보여줍니다.
앱 개발 개발자 -
AI 에이전트가 기업 권한 경계 안에서 작동하는 방식
기업에 필요한 것은 슈퍼 관리자 AI가 아닙니다. 사용자 권한을 상속하고, 위험한 작업은 승인으로 보내며, 모든 행동을 감사할 수 있는 제어된 에이전트입니다.
보안과 거버넌스 IT / CIO AI 에이전트에이전트 권한 -
제조팀이 legacy system에 AI를 연결하는 방법: ERP 교체가 아니라 보고서와 작업지시서부터
제조 시스템은 오래되고 무겁고 교체하기 어렵습니다. 실용적인 AI 경로는 기존 시스템을 연결하고 보고서, 작업지시서, 예외 분석에서 시작하는 것입니다.
통합과 데이터 IT / CIO 케이스 관리공급망과 구매 제조 -
복잡한 비즈니스에서 low-code가 무너지는 이유와 AI-native 앱 플랫폼의 차이
Low-code는 페이지와 workflow를 빠르게 만들게 해주지만, 복잡한 비즈니스 시스템은 객체, 권한, 통합, 변화, 유지보수성에 의해 제한됩니다.
앱 개발 IT / CIO HR 및 내부 앱케이스 관리 -
CRM에서 시작하기: AI가 고객, 영업기회, follow-up 이력을 이해하는 방법
대부분의 CRM에는 고객, 영업기회, 연락처, 활동 이력이 이미 있습니다. 유용한 길은 데이터를 내보내 일회성 분석을 하는 것이 아니라, 권한 아래에서 AI가 그 비즈니스 객체를 이해하게 하는 것입니다.
통합과 데이터 비즈니스 리더 CRM AI 에이전트에이전트 권한 -
마이그레이션 없이 기존 비즈니스 시스템을 AI-native로 만들기
자체 운영형 ObjectOS(Enterprise)에서 이미 운영 중인 데이터베이스를 기본 읽기 전용으로 연결하고, 코딩 에이전트가 테이블을 객체로 모델링하게 하면 원래 시스템을 건드리지 않고도 권한 아래에서 실제 데이터에 AI를 적용할 수 있습니다.
통합과 데이터 일반