웹 표준은 발전하는데, 왜 웹 개발은 점점 더 어려워지는가
모바일 웹 브라우저들의 파편화
B2C 웹 서비스를 개발하다 보면, 개발자가 예상하지 못했던 지점에서 발생하는 오류를 상당히 자주 마주하게 됩니다.
흥미로운 점은 이러한 오류의 상당수가 비즈니스 로직이나 애플리케이션 자체의 결함에서 발생하는 것이 아니라는 것입니다. 동일한 코드를 작성했음에도 사용자의 운영체제, 브라우저, 브라우저 엔진, 버전, 디바이스 환경에 따라 전혀 다른 결과가 나타나는 경우가 있습니다.
특히 모바일을 대상으로 하는 서비스라면 이러한 문제는 더욱 복잡해집니다.
이번 글에서는 B2C 웹 서비스를 개발하면서 자주 마주하게 되는 브라우저 호환성 문제를 중심으로, 왜 웹 표준이 존재함에도 이러한 문제가 계속 발생하는지, 그리고 새로운 웹 기술을 도입하는 과정에서 개발자가 어떤 현실적인 문제를 마주하게 되는지를 정리해보려 합니다.
목차
- 웹 개발에서 예상하기 어려운 오류들
- 첫 번째 문제: 모바일 OS와 브라우저의 파편화
- 두 번째 문제: 인앱 브라우저와 레거시 엔진
- 결국 필요한 것은 수많은 테스트
- HTML5와 웹 표준이 등장한 이유
- 그런데 표준이 발전할수록 새로운 문제가 생긴다
- B2C 서비스가 가진 구조적인 한계
- 결국 개발자가 선택해야 하는 것
- 웹 개발의 아이러니
1. 웹 개발에서 예상하기 어려운 오류들
B2C 서비스를 개발하면서 가장 난감한 오류 중 하나는 개발 환경에서는 재현되지 않는 오류입니다.
PC의 Chrome에서는 정상적으로 동작하고, 개발자가 사용하는 모바일 기기에서도 문제가 없는데 특정 사용자의 기기에서만 UI가 깨지거나 특정 버튼이 동작하지 않는 상황이 발생합니다.
더 어려운 것은 이런 문제가 반드시 명확한 에러 메시지를 남기는 것도 아니라는 점입니다.
JavaScript의 경우에는 콘솔에 에러가 출력되면 비교적 접근하기 쉽습니다. 하지만 CSS나 브라우저 렌더링과 관련된 문제는 상황이 다릅니다.
어떤 CSS 속성이 특정 브라우저에서 다르게 해석되거나, 특정 버전에서만 지원되지 않거나, 브라우저의 viewport 처리 방식 때문에 화면이 예상과 다르게 렌더링될 수도 있습니다.
결국 개발자는 다음과 같은 질문을 거꾸로 추적해야 합니다.
“왜 이 사용자의 환경에서만 이 코드가 다르게 동작하는가?”
그리고 이 질문에 답하기 위해서는 단순히 소스 코드만 살펴보는 것이 아니라 사용자의 실행 환경 자체를 분석해야 합니다.
2. 첫 번째 문제: 모바일 OS와 브라우저의 파편화
가장 대표적인 문제 중 하나가 모바일 OS의 차이에서 발생하는 CSS 및 렌더링 이슈입니다.
일반적으로 Android와 iOS는 모두 현대적인 웹 표준을 상당 부분 지원하지만, 세부적인 구현이나 브라우저 엔진의 동작 방식에는 차이가 존재합니다.
특히 iOS 환경에서는 이러한 차이가 더욱 민감하게 느껴지는 경우가 있습니다.
아이폰은 비교적 제한된 하드웨어 생태계를 가지고 있지만, 그렇다고 해서 모든 사용자가 동일한 소프트웨어 환경을 사용하는 것은 아닙니다.
오래된 기기는 최신 iOS로 업데이트할 수 없는 경우가 있고, 특정 기기에서 지원되는 OS의 최대 버전이 정해져 있기 때문입니다.
결국 하나의 B2C 서비스 안에 다음과 같은 환경이 동시에 존재할 수 있습니다.
- 최신 iPhone + 최신 iOS
- 구형 iPhone + 구형 iOS
- 최신 Android + 최신 Chrome
- 구형 Android + 구형 Chrome
- 제조사별 커스텀 브라우저
- 각종 애플리케이션의 인앱 브라우저
개발자는 최신 환경을 기준으로 개발하고 싶지만, 사용자는 개발자가 원하는 시점에 자신의 디바이스를 교체하거나 운영체제를 업데이트해주지 않습니다.
이것이 B2C 웹 개발에서 발생하는 첫 번째 딜레마입니다.
개발 환경은 계속 앞으로 나아가는데, 사용자의 환경은 과거에 머물러 있을 수 있습니다.
3. 두 번째 문제: 인앱 브라우저와 레거시 엔진
여기에 인앱 브라우저라는 변수가 추가되면 상황은 한층 복잡해집니다.
일반적인 Chrome이나 Safari라면 브라우저 자체의 버전과 지원 범위를 확인하는 것이 비교적 쉽습니다.
하지만 특정 애플리케이션 내부에서 웹 페이지를 실행하는 인앱 브라우저는 이야기가 다릅니다.
결국 웹 페이지가 실행되는 환경은 단순히
“사용자가 Chrome을 사용한다.”
정도로 설명되지 않습니다.
그 내부에서 어떤 렌더링 엔진을 사용하고 있는지, 해당 엔진의 버전은 무엇인지, 애플리케이션이 얼마나 오래된 WebView를 사용하고 있는지까지 고려해야 할 수 있습니다.
특히 과거에는 Chromium이나 WebKit과 같은 브라우저 엔진을 기반으로 하면서도 애플리케이션에 특정 버전의 엔진을 포함해 사용하는 경우가 많았습니다.
대표적으로 과거 모바일 애플리케이션에서 활용되었던 Crosswalk 같은 기술을 생각해볼 수 있습니다.
당시에는 특정 웹 기술을 일관된 환경에서 제공하기 위한 합리적인 선택이었지만, 시간이 지나면서 웹 표준과 브라우저 기술이 빠르게 발전하면 과거에 고정해 둔 엔진 버전 자체가 기술적 부채가 될 수 있습니다.
현재의 브라우저에서는 당연하게 사용할 수 있는 CSS나 JavaScript API가 과거의 엔진에서는 존재하지 않거나, 일부만 지원될 수도 있습니다.
따라서 개발자가 작성한 코드가 틀린 것이 아님에도 실행 환경이 이를 이해하지 못하는 상황이 발생합니다.
4. 결국 필요한 것은 수많은 테스트
여기서 문제가 하나 더 생깁니다.
이러한 문제들은 대부분 테스트를 통해서만 발견할 수 있다는 것입니다.
예를 들어 다음과 같은 환경을 고려해야 한다고 가정해보겠습니다.
| 구분 | 환경 |
|---|---|
| OS | Android / iOS |
| OS 버전 | 최신 / 구버전 |
| 브라우저 | Chrome / Safari / 기타 |
| 브라우저 버전 | 최신 / 레거시 |
| 접근 방식 | 일반 브라우저 / 인앱 브라우저 |
| 디바이스 | 최신 기기 / 구형 기기 |
| 화면 | 다양한 해상도 및 비율 |
각각의 조건이 독립적으로 존재하는 것이 아니라 서로 조합됩니다.
따라서 단순히 “모바일에서도 확인했습니다.”라고 말하는 것만으로는 충분하지 않습니다.
실제로는
어떤 모바일 환경에서 확인했는가?
가 더 중요한 질문이 됩니다.
이 때문에 B2C 서비스에서는 기능 하나를 개발하더라도 개발 자체보다 검수에 더 많은 시간이 들어가는 경우가 생깁니다.
특히 결제, 회원가입, 본인인증처럼 사용자 이탈에 직접적인 영향을 주는 영역에서는 이러한 호환성 문제가 더욱 치명적입니다.
5. HTML5와 웹 표준이 등장한 이유
그렇다면 자연스럽게 이런 의문이 생깁니다.
“이런 문제를 해결하기 위해 HTML5와 웹 표준이 발전해 온 것 아닌가?”
어느 정도는 맞는 이야기입니다.
웹의 역사를 살펴보면 브라우저마다 서로 다른 기능과 문법을 제공하던 시기를 거쳐, 보다 일관된 웹 표준을 정의하고 이를 브라우저들이 구현하는 방향으로 발전해왔습니다.
HTML5 역시 단순히 새로운 HTML 문법을 추가한 것 이상의 의미를 가집니다.
웹에서 멀티미디어를 처리하고, 그래픽을 렌더링하고, 다양한 디바이스 기능을 활용하고, 보다 풍부한 애플리케이션을 구현할 수 있도록 웹 플랫폼 자체의 기능이 확장되었습니다.
개발자 입장에서는 상당히 중요한 변화였습니다.
과거처럼 특정 브라우저에만 존재하는 비표준 기능에 의존하기보다는, 표준화된 API와 기술을 기반으로 여러 환경에서 동일한 애플리케이션을 구현할 수 있는 기반이 마련되었기 때문입니다.
그렇다면 이제 브라우저 호환성 문제는 점점 사라져야 할 것처럼 보입니다.
그런데 실제 현실은 조금 다릅니다.
6. 그런데 표준이 발전할수록 새로운 문제가 생긴다
아이러니하게도 웹 표준이 발전한다고 해서 브라우저 파편화가 완전히 사라지는 것은 아닙니다.
오히려 새로운 표준이 등장할 때마다 표준과 실제 사용 환경 사이에 시간차가 발생합니다.
새로운 CSS 기능이 표준에 포함되었다고 해서 모든 브라우저가 그 기능을 동시에 지원하는 것은 아닙니다.
어떤 브라우저는 빠르게 지원하고, 어떤 브라우저는 몇 년 뒤에 지원하며, 어떤 구형 브라우저는 영원히 지원하지 않을 수도 있습니다.
결국 개발자는 다음과 같은 선택을 해야 합니다.
“최신 표준을 적극적으로 사용할 것인가?”
혹은
“아직 남아 있는 구형 브라우저까지 고려할 것인가?”
최신 기술을 사용하면 개발 생산성이 올라가고 코드가 단순해질 수 있습니다.
반면 레거시 환경까지 지원하려면 fallback을 작성하거나 polyfill을 추가하거나, 아예 새로운 API를 사용하지 않고 과거의 구현 방식을 유지해야 할 수도 있습니다.
즉, 웹 표준의 발전과 웹 호환성의 확보가 항상 같은 방향으로 움직이는 것은 아닙니다.
7. B2C 서비스가 가진 구조적인 한계
이 문제를 더욱 어렵게 만드는 것은 B2C 서비스의 특성입니다.
사내 시스템이라면 비교적 쉽게 지원 범위를 제한할 수 있습니다.
예를 들어
“Chrome 최신 버전만 지원합니다.”
라고 명시할 수 있습니다.
하지만 일반 소비자를 대상으로 하는 서비스에서는 이야기가 다릅니다.
사용자가 어떤 스마트폰을 가지고 있는지, 어떤 OS를 사용하는지, 어떤 브라우저를 통해 접속하는지 개발자가 통제할 수 없기 때문입니다.
특히 이미 서비스를 이용하고 있는 사용자가 구형 기기를 사용하고 있다고 해서 그 사람에게 최신 기기로 변경하라고 요구할 수도 없습니다.
결국 개발자는 자신이 통제할 수 없는 실행 환경을 대상으로 서비스를 제공해야 합니다.
이것이 웹 개발이 다른 플랫폼 개발과 구별되는 상당히 독특한 특성 중 하나라고 생각합니다.
웹의 가장 큰 장점은 플랫폼에 대한 종속성이 낮다는 것입니다.
하지만 역설적으로 바로 그 장점 때문에 개발자는 수많은 플랫폼과 환경을 동시에 고려해야 합니다.
8. 결국 개발자가 선택해야 하는 것
그래서 웹 개발에서 중요한 것은 단순히
“최신 기술을 사용할 것인가?”
라는 질문이 아닌 것 같습니다.
보다 현실적인 질문은 다음에 가깝습니다.
“우리 서비스가 어디까지의 레거시 환경을 책임질 것인가?”
지원 범위를 지나치게 넓히면 개발 및 테스트 비용이 증가합니다.
반대로 지원 범위를 지나치게 좁히면 일부 사용자가 서비스 이용에 어려움을 겪게 됩니다.
따라서 결국 서비스의 사용자층과 비즈니스 특성, 브라우저 사용 통계, 기능의 중요도 등을 기준으로 지원 범위에 대한 명확한 정책을 수립하는 것이 중요해집니다.
모든 브라우저를 영원히 지원하는 것은 현실적으로 불가능합니다.
중요한 것은 모든 환경을 지원하는 것이 아니라, 어떤 환경까지 지원할 것인지 명확하게 정의하고 그 기준을 일관되게 유지하는 것일 것입니다.
9. 웹 개발의 아이러니
결국 웹 개발이라는 분야는 상당히 재미있는 역설을 가지고 있습니다.
웹 표준은 브라우저 간의 차이를 줄이기 위해 발전해왔습니다.
HTML5와 CSS, JavaScript 표준은 개발자가 특정 플랫폼에 종속되지 않고 동일한 애플리케이션을 만들 수 있도록 발전해왔습니다.
하지만 표준이 발전할수록 새로운 기능이 등장하고, 그 기능을 지원하는 브라우저와 지원하지 않는 브라우저 사이에 새로운 간극이 생깁니다.
그리고 과거의 브라우저는 단순히 사라지는 것이 아니라 상당 기간 동안 사용자 환경에 남아 있습니다.
결국 개발자는 미래를 향해 발전하는 기술과 과거에 머물러 있는 사용자의 환경 사이에서 균형을 잡아야 합니다.
최신 CSS를 사용하고 싶지만 구형 Safari 때문에 망설이게 되고, 최신 JavaScript API를 사용하고 싶지만 오래된 WebView 때문에 polyfill을 추가하게 됩니다.
개발자는 계속해서 앞으로 나아가야 하지만, 서비스를 이용하는 사용자가 반드시 같은 속도로 따라와 주는 것은 아닙니다.
어쩌면 이것이 B2C 웹 개발에서 발생하는 호환성 문제의 본질일지도 모르겠습니다.
웹은 하나의 플랫폼처럼 보이지만, 실제로는 수많은 서로 다른 실행 환경 위에서 동작하는 거대한 플랫폼의 집합에 가깝습니다.
그리고 웹 표준의 발전은 이러한 파편화를 완전히 제거하는 것이 아니라, 그 복잡성을 조금씩 다른 형태로 재편해왔습니다.
결국 웹 개발자에게 필요한 것은 단순히 최신 기술을 빠르게 습득하는 능력만은 아닐 것입니다.
어떤 기술이 현재의 사용자 환경에서 실제로 유효한지 판단하고, 새로운 기술을 도입함으로써 얻는 이점과 호환성을 유지하기 위해 지불해야 하는 비용 사이에서 적절한 균형점을 찾는 능력.
B2C 웹 서비스를 개발한다는 것은 어쩌면 끊임없이 변화하는 웹 표준과 좀처럼 사라지지 않는 레거시 환경 사이에서 그 균형점을 찾아가는 과정인지도 모르겠습니다.