Enterprise 환경에서 iframe 기반 View Generation을 선택한 이유
AI가 UI를 생성하는 기능 자체는 더 이상 낯설지 않습니다.
하지만 엔터프라이즈 환경에서는 생성 이후의 단계가 훨씬 중요합니다. 생성된 결과를 어디서 실행할 것인지, 그 실행을 어느 범위까지 허용할 것인지, 그리고 그 위에 사용자 경험을 어떻게 얹을 것인지는 각각 다른 설계 문제입니다. 이 세 가지는 하나의 기능처럼 보이지만 실제로는 서로 다른 레이어에 속합니다.
CommerceOS의 View Generation을 구현하면서 이 지점이 분명해졌습니다. 실행 환경을 설계하는 문제와, 그 결과를 인터랙션으로 연결하는 문제는 같은 방식으로 풀 수 없습니다.
이 글에서는 그 중 첫 번째, AI-generated UI를 안전하게 실행하는 구조를 중심으로 설명합니다.
AI-generated UI는 실행 환경을 전제로 한다
프론트엔드에서 iframe은 종종 과거의 기술로 인식됩니다.
하지만 CommerceOS에서는 전혀 다른 이유로 다시 선택하게 됐습니다. 사용자의 요청을 기반으로 생성되는 결과는 단순한 데이터가 아닙니다. React 코드와 데이터 쿼리를 포함하고 있으며, 실제로 실행되는 뷰입니다. 이 결과는 브라우저 안에서 하나의 작은 애플리케이션처럼 동작합니다.
이 지점에서 질문이 달라집니다.
이걸 어떻게 보여줄 것인가가 아니라, 이 코드를 어디서 실행할 것인가가 핵심이 됩니다.
엔터프라이즈 환경에서는 이 차이가 더 중요해집니다.
실행되는 코드의 범위와 영향은 반드시 통제 가능한 상태에 있어야 하기 때문입니다.
우리가 실제로 풀어야 했던 문제
CommerceOS의 View Generation은 단순히 결과를 렌더링하는 기능이 아닙니다.
생성된 결과는 실제 업무 흐름 안에서 사용됩니다.
이 기능은 몇 가지 조건을 동시에 만족해야 했습니다.
AI가 생성한 코드는 host 애플리케이션과 분리된 상태에서 실행되어야 하고, 사용자는 결과를 바로 확인할 수 있어야 합니다. 동시에 그 결과를 기반으로 다시 수정 작업을 이어갈 수 있어야 하며, 실행 환경이 중단되더라도 복구가 가능해야 합니다.
이 조건들을 놓고 보면 자연스럽게 결론이 나옵니다.
이건 컴포넌트를 어떻게 불러올지에 대한 문제가 아니라, 실행 범위를 어떻게 제한할 것인지에 대한 문제입니다.
왜 iframe이었는가
마이크로 프론트엔드 구조를 고민할 때 Module Federation은 매우 강력한 선택지입니다. 실제로도 충분히 검토할 가치가 있습니다.
하지만 이 경우에는 기준이 달랐습니다. Module Federation은 동일한 실행 컨텍스트를 전제로 합니다. 코드가 같은 런타임에서 동작하고, 상태와 의존성이 공유됩니다. 내부 시스템에서는 효율적인 방식이지만, 생성된 코드의 동작을 예측하기 어려운 상황에서는 부담이 됩니다.
iframe은 접근 방식이 다릅니다.
실행 환경이 분리되고, DOM과 JavaScript 컨텍스트가 독립적으로 유지됩니다. 실행 범위가 명확하게 구분되기 때문에 문제가 발생했을 때 영향이 제한됩니다.
CommerceOS에서는 이 차이가 중요했습니다.
성능이나 개발 편의보다, 실행을 어디까지 허용할 것인지가 우선 기준이었습니다.
iframe은 기능이 아니라 경계다
이 선택은 단순한 구현 방식의 차이가 아닙니다.
시스템에서 실행이 이루어지는 경계를 어디에 둘 것인지에 대한 결정입니다.
CommerceOS에서 iframe은 하나의 UI 요소라기보다, 실행을 분리하기 위한 경계로 사용됩니다.
사용자가 생성한 코드는 이 영역 안에서만 동작하고, host 애플리케이션은 그 바깥에서 상태를 관리합니다. 이 구조는 문제가 발생했을 때 영향을 특정 영역 안으로 제한할 수 있게 해줍니다.
이 관점에서 보면 iframe은 오래된 기술이 아니라, 실행 범위를 명확하게 나누는 가장 직접적인 방법입니다.
제약을 어떻게 구성했는가
iframe 자체보다 중요한 건 그 위에 어떤 제약을 두느냐입니다.
CommerceOS에서는 실행 환경을 통제하기 위해 몇 가지 원칙을 함께 적용했습니다.
실행은 항상 다른 origin에서 이루어진다
같은 origin에서 실행되는 코드는 host와 동일한 권한을 갖게 됩니다.
그래서 sandbox 환경은 반드시 다른 origin에서 실행되도록 강제했습니다.
이 구조를 통해 host 애플리케이션과 실행 환경 사이의 경계를 명확하게 유지할 수 있습니다.
권한은 필요한 범위 안에서만 허용된다
sandbox 설정은 대부분의 기능을 차단하는 상태에서 시작합니다.
그 위에 필요한 기능만 선택적으로 허용합니다.
개발 환경에서는 디버깅과 인터랙션을 위해 권한을 넓게 두고, 실제 사용자 환경에서는 최소한의 권한만 유지합니다. 이 차이는 운영 환경에서의 안정성을 유지하는 데 중요한 역할을 합니다.
데이터 흐름도 제한한다
실행 환경을 분리하는 것만으로는 충분하지 않습니다.
어디로 데이터를 보내는지도 통제되어야 합니다.
iframe 내부에서는 CSP를 적용해 허용된 API endpoint로만 요청을 보낼 수 있도록 제한했습니다. 이를 통해 실행과 데이터 흐름 모두를 예측 가능한 범위 안에 둘 수 있습니다.
결론
AI-generated UI를 다루는 순간, 프론트엔드는 단순한 렌더링 계층을 넘어섭니다.
코드를 실행하고 그 실행을 통제하는 역할을 갖게 됩니다.
CommerceOS는 이 문제를 실행 환경을 분리하는 방식으로 해결했습니다.
코드는 sandbox 안에서 실행되고, host 애플리케이션은 그 바깥에서 이를 제어합니다.
이 구조를 통해 실행 범위는 제한되고, 시스템 전체의 안정성은 유지됩니다.
다음 글에서는 이 분리된 실행 환경 위에서 어떻게 사용자 인터랙션을 연결했는지를 다룹니다.
in solving your problems with Enhans!
We'll contact you shortly!