Enterprise 환경에서 View Generation을 인터랙션으로 연결하는 방법

1편에서 실행 환경을 분리하는 구조를 다뤘습니다.

이제 생성된 UI는 안전한 범위 안에서 동작합니다.

하지만 이 상태만으로는 제품 기능이라고 보기 어렵습니다.

사용자는 결과를 확인한 뒤, 그 결과를 기반으로 다시 작업을 이어갑니다.

텍스트를 바꾸거나, 데이터 쿼리를 수정하거나, 화면 구성을 다시 조정하는 과정이 자연스럽게 이어져야 합니다.

즉, 생성된 UI는 단순한 출력물이 아니라 다음 액션을 유도하는 인터페이스가 되어야 합니다.

‍

‍

iframe 환경에서는 제어 방식이 바뀐다

일반적인 프론트엔드에서는 DOM에 직접 접근하고 상태를 공유합니다.

하지만 cross-origin iframe에서는 이 접근 자체가 불가능합니다.

CommerceOS에서는 이 제약을 회피하지 않고, 그 전제를 기준으로 구조를 다시 설계했습니다.

직접 접근하는 대신, 상태와 의도를 메시지로 주고받는 방식으로 전환했습니다.

이 구조에서 중요한 건 어떤 메시지만 허용할 것인가를 정의하는 것입니다.

‍

‍

postMessage 처리하기

postMessage는 브라우저가 제공하는 가장 단순한 cross-origin 통신 수단입니다.

문제는 이 방식이 기본적으로 열려 있다는 점입니다.

어떤 window든 메시지를 보낼 수 있고, 형식도 강제되지 않습니다.

그래서 CommerceOS에서는 이 레이어를 그대로 쓰지 않고, 명확한 규칙을 가진 구조로 제한했습니다.

메시지는 항상 특정 origin에서만 받아들이고, 요청과 응답은 고유 식별자를 기준으로 매칭됩니다.

또한 전달되는 데이터는 사전에 정의된 구조를 통과해야만 처리됩니다.

이 과정을 통해 postMessage는 제한된 인터페이스로 동작하게 됩니다.

이 설계의 핵심은 하나입니다.

허용된 메시지만 흐르게 만든다

‍

‍

요청과 응답을 분리하면 흐름이 안정된다

실제 구현에서 중요했던 부분 중 하나는 요청과 응답을 명확하게 분리하는 구조였습니다.

iframe은 필요한 시점에 host에게 요청을 보내고, host는 그 요청에 대해 응답을 반환합니다.

이 흐름이 명확하지 않으면 다음과 같은 문제가 생깁니다.

• 동일 요청이 중복 처리되는 경우
• 이전 요청에 대한 응답이 뒤늦게 도착하는 경우
• 의도하지 않은 메시지가 처리되는 경우

이를 방지하기 위해 모든 요청에는 고유한 식별자가 포함되고, 응답은 반드시 해당 요청과 연결된 경우에만 처리됩니다.

이 구조는 단순해 보이지만, 비동기 환경에서 안정성을 유지하는 데 중요한 역할을 합니다.

‍

‍

인증 흐름을 분리하면 통제 범위가 명확해진다

iframe 내부에서 API를 호출하려면 인증 정보가 필요합니다. 하지만 쿠키 기반 인증은 iframe 환경에서 일관되게 동작하지 않습니다.

CommerceOS에서는 인증 흐름을 iframe 내부에 두지 않았습니다.

iframe은 필요한 시점에 토큰을 요청하고, host는 현재 세션 기준으로 토큰을 전달합니다. 이 구조를 통해 인증은 한 곳에서 관리되고, iframe은 필요한 정보만 받아 사용하는 형태가 됩니다.

이 방식은 인증 책임을 어디에 둘 것인가에 대한 설계 결정에서 특히 중요합니다.

‍

‍

“이 UI가 준비됐는지”를 판단하는 문제

iframe은 로드 이벤트를 제공하지만, 이 이벤트는 HTML이 로드됐다는 의미에 가깝습니다. 실제 애플리케이션이 준비된 시점과는 차이가 있습니다. 또한 sandbox 환경은 일정 시간 후 종료될 수 있기 때문에, 초기 로딩 이후에도 상태를 계속 확인해야 합니다.

이 문제를 해결하기 위해 heartbeat 패턴을 사용했습니다.

iframe은 일정 주기로 상태 신호를 보내고, host는 이 신호를 기준으로 현재 상태를 판단합니다.

이 구조를 통해 두 가지 상황을 동시에 다룰 수 있습니다.

• 애플리케이션이 실제로 준비된 시점
• 실행 환경이 중단된 시점

별도의 복잡한 상태 관리 없이, 하나의 메커니즘으로 두 상황을 모두 처리할 수 있다는 점이 중요합니다.

‍

‍

Edit Mode는 “접근”이 아니라 “해석”의 문제다

사용자가 iframe 내부의 요소를 클릭해서 수정할 수 있게 만드는 기능은 표면적으로는 간단해 보입니다. 하지만 cross-origin 환경에서는 해당 요소에 직접 접근할 수 없습니다.

CommerceOS에서는 이 문제를 접근 방식 자체를 바꾸는 것으로 해결했습니다. 코드 생성 단계에서, 편집 가능한 요소에 대한 정보를 함께 삽입합니다.

이 정보에는 다음과 같은 내용이 포함됩니다.

• 어떤 요소가 수정 가능한지
• 해당 요소가 어떤 파일과 연결되는지
• 어떤 데이터 쿼리와 연결되는지

iframe은 클릭 이벤트를 감지한 뒤 이 정보를 수집해 전달하고, host는 이를 기반으로 편집 UI를 구성합니다. 이 과정에서 중요한 점은 DOM 자체를 제어하지 않는다는 것입니다.

대신, 의미 단위로 해석 가능한 정보만 전달합니다.

‍

‍

코드까지 연결해야 실제 수정이 가능해진다

편집 인터페이스를 제공하는 것만으로는 충분하지 않습니다.

실제 코드가 변경되어야 결과가 반영됩니다.

하지만 host는 iframe 내부 파일에 직접 접근할 수 없습니다.

그래서 파일 접근 역시 동일한 방식으로 해결합니다.

host가 필요한 파일을 요청하면, iframe이 해당 파일을 읽어서 전달합니다. 이 과정에서도 실행 환경의 경계는 유지됩니다. 코드는 여전히 sandbox 안에 있고, host는 필요한 정보만 전달받습니다.

이 구조는 단순하지만 중요한 원칙을 따릅니다.

경계를 유지한 상태에서 필요한 정보만 교환한다

‍

‍

재시도와 타이밍 문제를 어떻게 다뤘는가

실제 운영 환경에서는 모든 요청이 항상 즉시 처리되지 않습니다.

특히 iframe 내부 애플리케이션이 아직 초기화되지 않은 경우, 요청이 전달되더라도 응답이 오지 않을 수 있습니다.

이 문제를 해결하기 위해 요청에는 재시도 로직이 포함됩니다.

일정 시간 내 응답이 없으면 요청을 다시 보내고, 최대 횟수를 넘으면 실패로 처리합니다.

이 방식은 단순하지만, 초기화 타이밍과 네트워크 지연이 섞이는 상황에서 전체 흐름을 안정적으로 유지하는 데 중요한 역할을 합니다.

‍

‍

결론

실행 환경을 분리하는 것만으로는 충분하지 않습니다.

그 위에 인터랙션이 연결되어야 실제 제품 기능이 됩니다.

CommerceOS는 이 문제를 메시지 기반 구조로 풀었습니다.

• 메시지는 제한된 인터페이스로 정의되고
• 상태는 지속적으로 확인되며
• 인터랙션은 허용된 범위 안에서 처리됩니다

이 구조를 통해 View Generation은 단순한 미리보기를 넘어, 실제 수정과 반복이 가능한 인터페이스로 동작하게 됩니다.

‍

‍

본 접근 방식의 엔터프라이즈 적용에 대한 상세 논의가 필요하시면 인핸스에 문의해 주시기 바랍니다.

문의하기

‍