🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI는 Chromium을 Atlas 앱 프로세스 밖의 격리된 서비스로 분리한 OWL 아키텍처를 구축해 빠른 시작, 높은 응답성, 네이티브 UI, 신속한 개발, 안전한 에이전트 브라우징을 함께 구현했다.

📌 핵심 요약

• Atlas는 ChatGPT를 웹 전반에서 질문·제안·작업 수행을 돕는 공동 조종자로 만들기 위해 기존 브라우저 구조를 재검토하고, Chromium 런타임을 주 애플리케이션에서 분리했다.
• OWL은 Atlas를 SwiftUI와 AppKit 중심의 클라이언트로 유지하면서 Chromium 브라우저 프로세스를 별도의 호스트로 실행하고, 양측을 Chromium의 메시지 전달 체계인 Mojo 기반 IPC로 연결한다.
• 이 구조에서는 Chromium이 백그라운드에서 비동기적으로 시작되므로 화면을 빠르게 표시할 수 있고, Chromium의 지연이나 충돌이 Atlas 전체로 전파되는 위험도 줄어든다.
• 웹 콘텐츠와 팝업은 공유 합성 컨테이너와 CALayer 기반 위임 렌더링으로 표시되며, 입력 이벤트는 Swift 측에서 Blink 형식으로 변환한 뒤 Chromium 렌더러로 전달된다.
• 에이전트 모드에서는 화면 밖 팝업까지 하나의 이미지에 합성하고 자동 입력을 권한이 높은 브라우저 계층이 아닌 렌더러로 직접 보내며, 로그아웃 세션마다 격리된 인메모리 저장소를 사용한다.

🧩 주요 포인트

1. Atlas는 ChatGPT를 웹 전반에서 질문·제안·작업 수행을 돕는 공동 조종자로 만들기 위해 기존 브라우저 구조를 재검토하고, Chromium 런타임을 주 애플리케이션에서 분리했다.
2. OWL은 Atlas를 SwiftUI와 AppKit 중심의 클라이언트로 유지하면서 Chromium 브라우저 프로세스를 별도의 호스트로 실행하고, 양측을 Chromium의 메시지 전달 체계인 Mojo 기반 IPC로 연결한다.
3. 이 구조에서는 Chromium이 백그라운드에서 비동기적으로 시작되므로 화면을 빠르게 표시할 수 있고, Chromium의 지연이나 충돌이 Atlas 전체로 전파되는 위험도 줄어든다.
4. 웹 콘텐츠와 팝업은 공유 합성 컨테이너와 CALayer 기반 위임 렌더링으로 표시되며, 입력 이벤트는 Swift 측에서 Blink 형식으로 변환한 뒤 Chromium 렌더러로 전달된다.
5. 에이전트 모드에서는 화면 밖 팝업까지 하나의 이미지에 합성하고 자동 입력을 권한이 높은 브라우저 계층이 아닌 렌더러로 직접 보내며, 로그아웃 세션마다 격리된 인메모리 저장소를 사용한다.

🧠 상세 정리

1. ChatGPT를 웹의 공동 조종자로 만들기 위한 재설계

Atlas는 완전한 기능을 갖춘 웹 브라우저인 동시에, 사용자가 인터넷을 탐색하는 동안 ChatGPT에 질문하고 제안을 받으며 작업까지 맡길 수 있도록 설계됐다. 이 목표를 달성하려면 ChatGPT를 브라우저 옆에 단순히 덧붙이는 수준을 넘어, 브라우저가 실행되고 화면을 그리며 입력을 처리하는 방식 자체를 다시 생각해야 했다. OpenAI가 특히 해결하려 한 과제는 즉각적인 시작, 탭이 늘어나도 유지되는 응답성, 그리고 에이전트가 웹을 안전하게 조작할 수 있는 기반이었다. 이에 따라 Atlas의 핵심 기술적 선택은 Chromium을 버리는 것이 아니라, Chromium 런타임과 주 애플리케이션의 결합 방식을 근본적으로 바꾸는 것이었다.

2. Chromium을 기반으로 삼되 기본 구조에는 얽매이지 않기

Chromium은 강력한 보안 모델과 검증된 성능, 폭넓은 웹 호환성을 제공하며 세계적인 개발자 공동체가 지속적으로 개선하는 웹 엔진이어서 Atlas의 자연스러운 기반이었다. 그러나 Chromium은 부팅 순서, 스레딩 모델, 탭 모델을 비롯한 여러 영역에 구체적인 구조적 전제를 갖고 있어 Atlas의 목표를 기본 상태만으로 충족하기는 어려웠다. OpenAI는 Chromium을 대폭 수정하는 방안도 검토했지만, 패치 규모가 커지면 새 Chromium 버전을 빠르게 통합하기 어렵다는 문제가 있었다. 따라서 웹 엔진의 장점은 유지하면서도 상위 UI와 제품 구조를 자유롭게 설계하고, 업스트림과의 차이는 작게 유지할 새로운 통합 방식이 필요했다.

3. 네이티브 UI와 빠른 개발 주기를 동시에 추구

Atlas 디자인팀은 Agent 모드를 포함한 기능에 풍부한 애니메이션과 시각 효과를 적용하려 했고, 이를 위해 Chromium의 오픈소스 UI를 겉모습만 바꾸는 대신 SwiftUI, AppKit, Metal 같은 현대적인 macOS 네이티브 프레임워크를 선택했다. 그 결과 Atlas의 사용자 인터페이스는 기존 Chromium UX의 변형이 아니라 애플리케이션 경험 전반을 새로 구축한 형태가 됐다. 동시에 OpenAI는 새 엔지니어도 입사 첫날 오후에 작은 변경을 병합할 수 있어야 한다는 개발 문화를 유지하려 했다. Chromium 소스를 내려받고 빌드하는 데 몇 시간이 걸릴 수 있다는 점을 고려하면, 대부분의 개발자가 Chromium을 직접 빌드하지 않고도 수분 안에 Atlas를 빌드할 수 있는 구조가 필수적이었다.

4. OWL의 핵심인 클라이언트와 호스트의 프로세스 분리

이러한 요구에 대한 해답이 OpenAI의 Web Layer를 뜻하는 OWL이다. OWL은 Chromium 브라우저 프로세스를 Atlas의 주 애플리케이션 프로세스 밖에서 실행하며, 탭을 별도 프로세스로 분리한 Chromium의 발상을 한 단계 더 확장해 Chromium 자체를 격리된 서비스 계층으로 옮긴다. 상위 구조에서 Atlas는 OWL Client이고 Chromium 브라우저 프로세스는 OWL Host이며, 두 구성 요소는 Chromium의 메시지 전달 체계인 Mojo를 이용해 IPC로 통신한다. OpenAI는 Swift 앱이 호스트 측 인터페이스를 직접 호출할 수 있도록 Mojo용 Swift 바인딩과 TypeScript 바인딩까지 작성했다.

5. 분리 구조가 제공하는 성능·안정성·유지보수 이점

OWL 구조에서는 Chromium이 백그라운드에서 비동기적으로 부팅되기 때문에 Atlas가 엔진 시작을 기다리지 않고 화면 픽셀을 거의 즉시 표시할 수 있다. Chromium의 복잡한 메인 스레드가 멈추더라도 Atlas는 함께 멈추지 않으며, Chromium 프로세스가 충돌해도 주 애플리케이션은 계속 실행될 수 있다. Atlas 자체는 거의 전부 SwiftUI와 AppKit으로 구성된 단일한 네이티브 코드베이스를 유지하고, Chromium 오픈소스 UI에 대한 의존을 줄여 업스트림과의 차이와 병합 부담도 축소한다. 또한 OWL을 내부에서 미리 빌드된 바이너리로 제공하므로 대부분의 엔지니어는 Chromium을 로컬에서 컴파일하지 않고도 빠르게 기능을 실험하고 변경 사항을 전달할 수 있다.

6. 서비스 API와 위임 합성으로 웹 화면 표시

OWL 클라이언트 라이브러리는 호스트 전체를 설정하고 제어하는 Session, 사용자별 브라우저 상태를 관리하는 Profile, 개별 웹 콘텐츠를 탐색·입력·확대·렌더링하는 WebView 등의 개념을 간결한 Swift API로 노출한다. WebContentRenderer는 입력을 Chromium 렌더링 파이프라인에 전달하고 결과를 돌려받으며, LayerHost와 LayerClient는 UI와 Chromium 사이에서 합성 정보를 교환한다. 탭의 WebView들은 공유 합성 컨테이너에 번갈아 연결되고, Chromium 측의 gfx::AcceleratedWidget은 CALayer로 뒷받침되며 해당 레이어의 컨텍스트 ID가 클라이언트에 전달된다. Atlas는 NSView와 CALayerHost를 이용해 이를 삽입하고, OWL은 화면 크기와 배율에 맞는 레이어가 생성되도록 양측의 뷰 위치와 크기를 계속 동기화한다.

7. 팝업·네이티브 요소·입력 이벤트를 연결하는 방식

HTML 선택 메뉴나 색상 선택기처럼 별도 팝업 위젯으로 렌더링되는 요소도 자체 RenderWidgetHostView와 AcceleratedWidget을 가지므로 동일한 위임 렌더링 방식을 적용할 수 있다. 이 기법은 권한 요청처럼 SwiftUI 대체 구현을 처음부터 만들기 어려운 기능을 빠르게 제공하기 위해 Chromium의 일부 네이티브 Views UI를 Atlas에 선택적으로 투영하는 데도 쓰이며, macOS 설치형 웹 앱을 위한 Chromium 인프라를 크게 참고했다. 입력 처리에서는 숨겨진 Chromium 프로세스가 플랫폼 이벤트를 직접 받지 못하므로 Swift 클라이언트가 macOS NSEvent를 Blink의 WebInputEvent 형식으로 변환해 전달한다. 페이지가 처리하지 않은 이벤트는 클라이언트로 되돌아오며, Atlas는 이를 다시 NSEvent로 합성해 애플리케이션의 다른 부분이 처리할 기회를 준다.

8. 에이전트 브라우징을 위한 화면·입력·저장소 격리

Atlas의 컴퓨터 사용 모델은 화면 전체를 하나의 이미지로 입력받지만 선택 메뉴처럼 탭 경계 밖의 별도 창에 표시되는 요소가 있어, Agent 모드에서는 이런 팝업을 정확한 좌표에 맞춰 본문 이미지에 다시 합성한다. 덕분에 모델은 웹 페이지와 부가 UI를 분리된 화면이 아니라 하나의 완전한 맥락으로 볼 수 있다. 에이전트가 생성한 입력은 권한이 높은 브라우저 계층을 거치지 않고 렌더러로 직접 전달되므로, 웹 콘텐츠와 무관한 브라우저 단축키 같은 동작을 합성하는 것을 막고 샌드박스 경계를 보존한다. 로그아웃 상태의 에이전트 작업에는 사용자의 시크릿 프로필을 공유하지 않고 Chromium StoragePartition 기반의 독립적인 인메모리 저장소를 만들며, 각 세션의 쿠키와 사이트 데이터는 종료 시 폐기되고 여러 탭의 세션도 서로 격리된다.

🧾 핵심 주장 / 시사점

• OWL의 핵심 가치는 새 웹 엔진을 만드는 데 있지 않고, 검증된 Chromium을 애플리케이션 밖의 서비스로 재배치해 제품 UI와 엔진의 발전 주기를 분리한 데 있다.
• 프로세스 격리는 시작 속도와 충돌 내성뿐 아니라 업스트림 패치 축소, 사전 빌드 바이너리 배포, 첫날 코드 병합이 가능한 개발 경험까지 하나의 구조적 선택으로 개선한다.
• 에이전트 기능은 기존 화면 자동화의 단순한 추가가 아니라, 팝업 합성으로 관찰 맥락을 완성하고 입력 경로와 세션 저장소를 제한해 자동화 상황에서도 보안 경계를 유지하도록 설계됐다.

✅ 액션 아이템

• OpenAI의 OWL 사례처럼 Chromium 런타임을 앱 프로세스 외부 호스트로 분리해 시작 지연과 장애 전파 경로를 줄인다.
• SwiftUI/AppKit 중심 클라이언트는 유지하되 Swift 측 입력을 Blink 형식으로 바꿔 Mojo IPC로 보내는 경로를 정리해 책임 경계를 고정한다.
• 에이전트 모드에서는 화면 밖 팝업을 단일 합성 이미지로 표시하고 자동 입력을 렌더러로 직접 보내며 세션별 인메모리 저장소 격리를 유지한다.

❓ 열린 질문

• 백그라운드 비동기 시작 구조가 실제로 체감 지연을 개선한다는 기준은 어떤 수치로 판정할 것인가?
• Swift 변환 이벤트가 Mojo IPC를 타고 전달될 때 웹 팝업 간 동작 차이를 어떤 방식으로 탐지할 것인가?
• 권한 높은 브라우저 계층을 우회해 렌더러로 직접 입력할 때 세션별 인메모리 격리의 신뢰성 기준은 어디로 잡아야 하는가?