출시 후부터가 진짜 개발이다

최근 약 한 달 동안 B2G 교육청 사업 프로젝트에 참여하며 학생들이 사용하는 수강 웹 애플리케이션 개발을 맡았다. 이 프로젝트는 지금까지 경험한 서비스 중 가장 큰 트래픽을 기록한 서비스였으며, 출시 후 현재까지 매일 약 5-10개의 학교에서 실제로 사용중이다. 출시 후 약 1~2주간은 운영 대응에 집중해야 했고, 트래픽이 적지 않았던 만큼 다양한 이슈들이 발생했다. 대부분의 문제는 교사들의 문의를 통해 접수되었고, 간단한 문제부터 원인을 알기 어려운 복잡한 문제까지 다양했다. 초기 운영 대응은 예상보다 만만치 않았고, 그 과정에서 압박감과 죄책감, 불안감, 외로움 등 여러 감정들을 느꼈다🥺. 하지만 이러한 경험을 통해 많은 것을 배우고, 개인적으로 성장할 수 있었다. 이 글에서는 출시 후 운영 과정에서 겪었던 어려움과 그로부터 얻은 깨달음들을 공유하고자 한다.

크로스브라우징 이슈

실서비스 운영 중 처음으로 크로스브라우징 이슈를 경험했다. 정확히 말하자면, 버전 호환성 문제였다. 웹과 앱 내 웹뷰 환경에서 동일한 서비스를 제공해야 했는데, 일부 사용자 환경에서 화면이 축소되는 문제가 발생했다. 처음에는 원인을 파악하기 어려웠지만, CSS 호환성 문제로 추정하고 여러 가지 방법을 시도해보았다.

그 중에서, 해당 화면에서 사용하고 있던 dvh 단위를 제거했을 때 문제가 유사하게 재현되는 것을 확인했다. 그 후 caniuse를 통해 dvh 단위가 최신 스펙이라는 사실을 알게 되었고, 이를 제거하면서 문제를 해결할 수 있었다.

이 경험을 통해, 개발 과정에서 최신 속성을 무작정 도입하기보다는 CSS, Web API, JavaScript의 호환성을 사전에 확인하는 습관이 중요하다는 점을 깨달았다. 그러나 모든 사용자 환경을 완벽히 지원하는 것은 현실적으로 어려운 일이라는 것도 알게 되었다. 그만큼 트레이드오프가 필요한 순간이 있을 수 있다는 생각이 들었다. 예를 들어, 특정 최신 CSS 속성이 복잡한 UI 구현에 필수적이라면, 사용자 환경을 제한하거나 호환성을 고려해 구현에 더 많은 시간을 투자하는 선택이 필요할 수 있다.

또한, 당시 테스트 기기가 부족해 문제를 재현하는 데 어려움이 있었는데, 모바일 환경을 시뮬레이션할 수 있는 BrowserStack이라는 사이트를 통해 문제를 재현할 수 있었다. 앞으로 다양한 테스트 환경을 확보해야 할 때 이 서비스를 유용하게 활용할 계획이다.

어플리케이션 실행 환경에 대한 이해

여기서 말하는 어플리케이션 실행 환경은 운영체제, 브라우저 엔진, WebView 등과 같은 기술적인 환경을 의미한다. 개발 초기에는 단순히 브라우저 종류와 버전만 확인하면 호환성 여부를 쉽게 판단할 수 있을 거라고 생각했다. 그러나 실제로는 이보다 훨씬 복잡한 요소들이 사용자 환경에 영향을 미친다는 것을 알게 되었다. 특히 모바일 환경과 WebView 지원에서 많은 시행착오를 겪었다. 그래서 경험을 바탕으로 환경별 특징을 정리해보았다.

• PC 환경
  비교적 간단한 환경으로, 브라우저 종류(Chrome, Edge, Firefox 등)와 버전을 확인하면 호환성 여부를 판단할 수 있다.

• 모바일 환경
  모바일 환경에서는 PC보다 훨씬 다양한 변수들이 존재했다. 주요 플랫폼인 iOS와 Android를 기준으로 사용자 환경을 분석한 결과, 다음과 같은 사실을 알게 되었다.

  • iOS
    • Safari와 WebView는 iOS 시스템의 WebKit 엔진에 의존한다.
    • iOS 버전이 업데이트되면 Safari와 WebView도 함께 업데이트된다.
    • 따라서 iOS 사용자 환경의 호환성은 iOS 버전만 확인하면 파악할 수 있다.
  • Android
    • Android 5 이전: OS에 내장된 기본 브라우저와 WebView가 OS 버전에 의존했다.
    • Android 5 이후: 기본 브라우저(Chrome)와 WebView는 Chromium 엔진을 기반으로 동작하며, OS와 독립적으로 업데이트가 가능하다.
    • 따라서, 호환성 여부는 Chromium 버전을 기준으로 판단할 수 있다.

이 과정을 통해, 다양한 브라우저와 운영체제의 호환성을 확인할 때 어떤 요소들을 체크해야 할지 정리가 되었다.

로깅의 중요성

출시한 수강 웹 어플리케이션은 사용 과정에서 새로고침이나 뒤로 가기 등으로 화면에 재진입하면, 사용자는 처음부터 플로우를 다시 수행해야 한다. 이를 바탕으로 처음 화면으로 리디렉션되는 로직을 구현해두었으나, 실제 서비스를 사용하는 과정에서 사용자들이 갑작스럽게 튕기는 이슈를 겪고 있다는 문의가 계속 들어왔고, 일부 사용자는 작업을 처음부터 다시 시작해야 하는 불편을 겪었다.

처음에는 새로고침 문제로 추측하며 대응했지만, 이슈가 반복되면서 내가 전달한 대응 내용이 모호하다는 것을 느꼈고, 문제를 정확히 파악하지 못해 답답함을 느꼈다. 내가 놓친 부분이 있을지도 모른다는 의심도 들었고, 정확한 데이터를 바탕으로 원인을 파악하고 이를 명확하게 전달할 필요성을 느꼈다. 그래서 로깅을 도입하기로 결정했다. Redirection 관련 로깅을 추가하여 사용자 흐름을 기록하고, 이슈가 발생하는 구체적인 조건을 추적하기 시작했다. 로깅을 추가한 후, 사용자로부터 문의가 들어왔을 때 어떤 사용자가, 어떤 화면에서, 어떤 조건으로 리디렉션이 발생했는지 정확히 확인하여 원인을 더 디테일하게 전달할 수 있었다.

이전에는 액션 로깅을 주로 행동 분석에만 활용한다고 생각했지만, 이번 경험을 통해 디버깅에도 필수적이라는 사실을 깨달았다. 만약 개발 리소스가 충분해서 처음부터 디테일한 액션 로깅을 설정할 수 있었다면, 문제를 훨씬 더 빠르고 정확하게 파악할 수 있었을 것이다.

또한, 로깅 데이터를 바탕으로 사용자와 운영팀에게 투명하게 문제 상황을 설명하고, 신뢰를 바탕으로 소통하는 것이 얼마나 중요한지 깨달았다.

(추가적으로, 운영 대응 과정에서 반복적인 튕김 이슈 원인 파악 중에 의심되는 로직을 발견하고 수정했는데, 이후 해당 이슈와 관련된 문의가 크게 줄어든 것으로 보아, 해당 로직이 실제 문제의 원인이었을 가능성이 높다.. 추후, 해당 로직에 대해 딥다이브 예정하여 공유할 예정이다.)

운영팀과의 협업

서비스 운영 중 발생한 문의나 문제들은 운영팀을 통해 전달되었고, 문제를 파악하고 해결하는 과정에서 다음과 같은 여러 어려움을 겪었다.

• 모호한 문의 내용
  운영팀이 사용자로부터 받은 문의를 개발팀에 전달할 때, 내용이 모호한 경우가 많았다. 이로 인해 추가적인 정보 확인이 필요했지만, 무엇을 확인해야 할지 판단이 어려웠고, 일단 해결해줘야겠다는 마음이 앞섰다. 그로 인해 문제 해결에 더 많은 시간이 소요되었다.

  • 운영팀에서 전달하는 문의 내용이 자주 모호하므로, 필요한 디테일 정보를 즉시 확인하고, 필요한 경우 고객에게 직접 문의하도록 안내가 필요함을 느꼈다.
  • 문의를 받을 때, 사용자 환경(브라우저, OS 등)등의 정보를 사전에 수집하면 운영팀이 반복적으로 고객에게 요청할 필요가 없어지고, 문제 해결 속도도 빨라지겠다는 생각이 들었다.
  • Google Analytics, Mixpanel 등의 로깅 도구를 통해 데이터를 확인할 수 있으면 베스트

• 운영팀과의 소통
  문제 해결에 집중하다 보니 소통을 소홀히 했다. 특히 복잡하고 크리티컬한 이슈들이 많아 해결이 지연되었고, 이 과정에서 운영팀이 답답함을 느꼈을 것 같다는 생각이 들었다. 따라서 운영팀이 무기한 기다리지 않도록, 문제 해결 상황을 빠르게 공유하는 것이 중요하다는 것을 깨달았다.

  • 원인 파악 중이라면.. "현재 원인 파악 중이며, 확인 후 바로 안내드리겠습니다."
  • 원인 파악 완료되었다면.. "문제는 XXX였으며, 해결 방안을 적용 중입니다. 예상 완료 시간은 X시입니다.”
  • 문제 해결이 지연될 경우.. 임시 대처 방안이 있다면, 빠르게 안내한다.

• 지원 환경 범위 공유 부족
  앱 사용을 원칙으로 하고, 불가피한 경우에만 Safari/Chrome 브라우저 사용을 권장하기로 했었다. 하지만 나는 해당 내용을 운영팀과 기획팀으로부터 제대로 전달받지 못했고, 대응 과정에서 이를 알게 되었다.. 모든 환경을 대응하기 위해 고민하고 있었다..(실제로 네이버앱 브라우저로 접근한 사용자도 있었다.) 이를 통해, 환경에 대한 지원 범위를 명확히 정의하고 담당자들끼리 공유되어야 한다는 점을 깨달았다.
  

운영팀과의 원활한 협업과 빠른 대응은 사용자 경험과 직접적으로 연결되어 있음을 느꼈다. 이번 경험을 통해 문제 해결 프로세스를 개선하고, 운영팀과의 협업 방식을 스스로 최적화하는 계기가 되었다.

안정화 버전의 중요성

필자 소속 회사에서는 회사 내부에서 개발한 디지털 드로잉 툴 솔루션을 여러 서비스에 탑재해서 사용하고 있다. 필자는 AI연구소 부서에 소속중이며, 퇴사한 이전 담당자로부터 "안정화된 버전"이라며 v1.0을 전달받아 내부 여러 AI서비스에 탑재하여 사용하고 있었다. 해당 서비스들은 약 1년간 시연 및 이벤트성 용으로 문제없이 운영되어왔다. 드로잉 툴 개발팀에서는 이미 리뉴얼된 v2.0을 여러 실서비스에 안정적으로 탑재해서 사용중이었지만, AI연구소에서는 해당 버전을 탑재하기가 어려웠다. 드로잉 툴 v1.0에서 수집된 그림 데이터가 여러 AI 분석에 사용되고 있었기에, 버전 통합 과정에 많은 리소스가 들었다. 우리 부서에서는 지금까지 v1.0을 사용하면서 큰 문제가 없었다는 이유로, 충분한 검토 없이 실서비스에 탑재했다.

하지만 그 결과, 드로잉 툴에서 여러 이슈가 발생했다. 그림 데이터에 알 수 없는 형태의 표시가 생기고, 다양한 문제가 발생하기 시작했다. 이 당시, 해당 버전의 담당자가 부재한 상황에서, 내가 그 버전의 드로잉 툴을 탑재한 사람으로서 모든 책임이 나에게 돌아왔다. 리소스와 정보가 부족한 상황에서 문제를 해결해야 한다는 압박감은 매우 컸고, 해결 방안을 찾는 데 어려움을 겪었다. 결국, 현재 드로잉 툴 담당자의 도움을 받아 일부 이슈를 해결했지만, 여전히 몇 가지 문제는 미지의 상태로 남아있다. 이 후, 내부적으로 최신 안정화 버전(v2.0)으로의 통합을 결정하게 되었다. 이 계기로, 다음과 같은 깨달음을 얻었다.

• 안정화 여부의 철저한 검증 필요
  • 실서비스 환경과 사용 사례에 따라 예상치 못한 문제가 발생할 수 있기 때문에 충분히 검토해야한다.
  • 안정화된 버전이라는 주관적 판단은 위험하고, 단독 판단보다는 관련 팀과 긴밀히 협업해야 함을 느꼈다.
  • 써드파티 라이브러리나 외부 API를 도입할 때도 마찬가지로, 충분한 검토가 필요하다.
• 책임과 권한의 명확한 분리
  • 내가 직접 개발하지 않은 솔루션에 대해 모든 책임을 떠맡는 것은 비효율적이고 위험하다. 책임과 권한을 명확히 분리하고, 관련 담당자에게 이를 넘기는 것이 중요하다.

Production 환경 테스트의 중요성

앞서 언급한 튕기는 이슈를 디버깅하는 과정에서, React와 Next.js 프레임워크의 동작 원리와 관련된 의심되는 로직을 발견했다. 개발 환경(Dev)에서는 해당 이슈가 재현되지 않아 문제를 간과하고 있었다. 그러던 중, 타 부서의 시니어 개발자와 대화를 나눌 기회가 있었고, Next.js가 Production 환경에서 성능 최적화를 우선시하면서 Dev 환경과는 다른 동작 특성을 보일 수 있다는 점을 배웠다. 이를 통해 Production 환경에서의 테스트의 중요성을 깨닫게 되었다.

Next.js의 성능 최적화 방식에 대해 미리 이해하고 있다면, Production 환경에서 발생할 수 있는 문제를 예측하고 사전에 대비할 수 있을 것이라는 생각이 들었다. 추가적으로, 해당 로직의 동작에 대해서는 이후 딥다이브하여 상세히 공유할 예정이다.

이번 경험을 통해 운영 대응 과정에서 겪었던 다양한 어려움과 그로부터 얻은 교훈들을 정리해보았다. 단순히 문제를 해결하는 것을 넘어, 개발자로서 성장할 수 있는 기회가 되었고, 앞으로의 서비스 운영에서 더욱 신중하고 철저한 접근을 해야 한다는 다짐을 하게 되었다. 앞으로는 문제가 발생했을 때, 더욱 체계적이고 예측 가능한 방식으로 대응할 수 있도록, 계속해서 배우고 개선해 나가고자 한다.