Pickle을 만들며 고른 기술들 (05) - 왜 Pickle은 익스텐션 UI를 iframe으로 격리했을까

익스텐션 UI가 어떤 사이트에서는 예쁘고, 어떤 사이트에서는 깨져 보인다면 기능보다 신뢰가 먼저 무너집니다.

들어가며

Pickle 익스텐션을 만들면서 의외로 빨리 부딪힌 문제 중 하나는 기능보다 UI 자체였습니다. 저장 버튼과 오버레이 흐름은 구현할 수 있었지만, 웹페이지 위에 띄운 UI가 각 사이트의 스타일 영향을 너무 많이 받았기 때문입니다.

처음에는 일반적인 방식으로도 충분할 것처럼 보였습니다. 하지만 작업을 진행할수록 사이트마다 UI가 조금씩 달라지거나 깨지는 경우가 계속 나왔습니다. 어떤 곳에서는 폰트 크기나 여백이 미묘하게 어긋났고, 어떤 곳에서는 부모 페이지의 스타일이 오버레이까지 덮어쓰는 문제가 생겼습니다.

이 글에서는 왜 Pickle이 사이트별 스타일 차이를 개별 보완으로 막기보다, 아예 iframe 안에서 UI를 렌더링하는 쪽을 택하게 되었는지를 정리하려고 합니다.

왜 UI 격리가 먼저 문제로 떠올랐는가

익스텐션은 내가 만든 페이지에서만 동작하는 UI가 아닙니다. 수많은 웹페이지 위에 올라가야 하고, 그 페이지들의 스타일과 레이아웃 제약을 그대로 마주해야 합니다.

Pickle에서는 오버레이 UI가 어느 사이트에서나 비슷한 크기와 밀도로 보여야 했습니다. 그래야 저장 흐름도 일관되게 느껴질 수 있기 때문입니다. 그런데 부모 페이지의 스타일이 그 기준을 계속 흔들었습니다.

즉 문제는 "UI를 띄울 수 있는가"가 아니라, "어느 사이트에서도 같은 UI처럼 보이게 할 수 있는가"에 가까웠습니다.

왜 스타일 보완만으로는 부족하다고 봤는가

처음에는 스타일을 조금 더 조심해서 짜거나, 사이트별 예외를 보완하는 방식으로도 버틸 수 있을 것처럼 보였습니다. 어느 정도는 실제로 그렇게 대응할 수도 있습니다.

하지만 Pickle에서는 그것만으로는 부족하다고 느꼈습니다. 이유는 생각보다 단순했습니다. 실제로 사이트마다 UI가 조금씩 깨지거나 달라지는 케이스가 계속 나왔고, 그걸 스타일만으로 계속 보완하는 방식에는 한계가 있다고 봤기 때문입니다.

• rem 단위는 결국 부모 문서의 기준에 영향을 받습니다.
• 부모 페이지의 transform이나 필터 효과가 UI에 스며들 수 있습니다.
• 사이트마다 전역 스타일과 레이아웃 조건이 너무 달랐습니다.

이런 종류의 문제는 컴포넌트를 조금 더 조심해서 짠다고 해결되기보다, 아예 실행 환경을 분리하는 편이 더 낫다고 판단했습니다. 즉 "사이트마다 예외를 덧대며 맞춘다"보다 "처음부터 영향을 덜 받는 환경으로 분리한다"는 쪽이 Pickle에는 더 맞았습니다.

그래서 iframe을 택했습니다

Pickle에서는 오버레이 UI를 별도의 iframe 안에서 렌더링하는 쪽을 택했습니다. 이 방식은 구현은 더 번거롭지만, 대신 부모 페이지의 CSS와 레이아웃 영향에서 훨씬 더 독립적입니다.

제가 이 방식을 택한 이유는 세련된 구조를 만들고 싶어서가 아니었습니다. 반대로, 각 사이트의 예외를 매번 쫓아다니며 고치고 싶지 않았기 때문입니다. 작업 중에도 사이트마다 조금씩 UI가 깨지거나 달라지는 케이스가 계속 나왔고, 그걸 스타일만으로 막는 데에는 한계가 있다고 느꼈습니다. UI가 부모 페이지에 덜 흔들릴수록, 저장 흐름도 더 일관되게 유지할 수 있다고 봤습니다.

즉 iframe은 기능을 더하는 선택이 아니라, 기능이 사이트마다 다르게 깨지지 않게 하기 위한 선택에 가까웠습니다.

격리만으로 끝나지 않는 이유

UI를 iframe으로 분리한다고 해서 모든 문제가 끝나는 것은 아닙니다. 그다음에는 또 다른 질문이 따라옵니다.

• UI는 어느 프레임에 띄울 것인가
• 크기와 위치는 어떻게 잡을 것인가
• 클릭이 통과해야 하는 영역은 어떻게 처리할 것인가
• 백그라운드, 컨텐트 스크립트, 오버레이 사이 메시지는 어떻게 주고받을 것인가

그래서 Pickle에서는 UI 격리를 따로 떼어낸 기술 트릭처럼 보지 않았습니다. 오히려 전체 익스텐션 흐름 안에서, "같은 경험을 유지하기 위한 한 단계"로 보는 편이 더 맞았습니다.

결국 중요한 것은 설명 가능한 일관성이었습니다

이 선택을 통해 가장 얻고 싶었던 것은 완벽한 기술적 순수성이 아니었습니다. 어느 사이트에서는 잘 되고 어느 사이트에서는 깨지는 UI보다, 여러 사이트에서 비슷하게 동작하는 UI를 만드는 편이 훨씬 중요했습니다.

익스텐션에서는 이런 일관성이 신뢰로 이어집니다. 사용자는 내부 구조를 모르지만, 어느 페이지에서든 비슷하게 보이고 비슷하게 동작하는지는 바로 느낄 수 있기 때문입니다.

그래서 Pickle에서 iframe 격리는 선택 가능한 최적화가 아니라, 결국 필요해진 구조에 더 가까웠습니다.

마치며

Pickle에서 iframe을 쓴 이유는 웹페이지 위에서 UI를 띄우는 기술이 없어서가 아니었습니다. 오히려 선택지가 있었기 때문에, 그중에서 무엇이 더 오래 덜 흔들릴지를 판단해야 했습니다.

결국 제가 중요하게 본 것은 "부모 페이지가 달라도 같은 Pickle처럼 보여야 한다"는 점이었습니다. 그 기준으로 보면, UI를 별도 환경으로 격리하는 쪽이 더 맞았습니다.

다음 글에서는 익스텐션이나 인증 흐름에서 잠시 벗어나, 왜 Pickle에서 디자인 토큰과 아이콘을 자동 생성 파이프라인으로 묶게 되었는지를 정리해 보려고 합니다.