랜턴의 서비스 기획 이야기 13

WEBGL 컨텐츠 

 

내가 만들고 있는 웹은 크게 2가지의 유즈 케이스를 가지고 있었다.

1. 전형적인 정적 컨텐츠 위주의 화면을 제공하는 경우 

2. WEBGL 기반의 유저 인터랙션을 동반하는 시뮬레이션 화면을 제공하는 경우 

특히, 2번의 경우는, Web+App을 만들겠다는 리더들의 염원에 의해 강력하게 이루어졌는데,

이를 반대했던 나로서는 개발 과정의 중간에서라도 점검하고 싶었다. 

 

나는 시장의 기대보다 작동하지 않을 경우를 대비하여

Two Track으로 대응 방안을 수립했다.

1. 컨텐츠 글로벌 사용 정책 수립 -> 글로벌 전개 시 동시 배포

2. 개발 과정 중 WEBGL 컨텐츠 동시 제작 + 필드 베타 테스트 

+a. 로컬에 캐싱을 지원하는 서비스 구성   

 

1번의 대응방안은, 네트워크 불안 지역 또는 그러한 경우에 

안정적인 정적웹 기반 컨텐츠를 소비할 것을 안내하고 교육하는 것이었다. 

대신, 정적웹은 완전히 정적웹으로서 작동할 수 있게끔 고안되어야 했으므로,

이는 3월부터 정적 컨텐츠 화면 기획 시 특히 공을 들였던 부분이기도 했다.

 

2번은, WEBGL 컨텐츠만 별도로 웹 퍼블리싱하고,

특정 용도에 맞게 필드 베타 테스트 목적으로 배포하는 것이었다.

플러스 알파는, 웹 배포 시에 내가 갖고 갈 전략이었다. 

혹시 필드의 반응이 너무 좋지 않을 경우, 

팀장님을 포함하는 그룹 리더와 빠르게 대응방안을 세우고 초기 진화를 시도해야할 것을 상정했다. 

필드 반응이 좋더라도, 캐싱하는 데 걸리는 물리적 시간은 절대적이었으므로,

다음 프로젝트로 삼아도 좋은 항목이었다. 

 

결과적으로, 1번은 권역 23-24년 권역 교육 및 자료배포 활동 등으로 잘 수행할 수 있었다.

2번 활동은 끝내 일정 상의 문제로 실현시키지 못했다.

 

 

ISMS 심사 

 

회사의 IT 관련 매출이 증가하면서 ISMS심사 대상이 되었다.

ISMS는 사내 시스템이더라도, 개인정보를 다루는 모든 시스템이 심사 대상이 되므로, 

내가 운영하고 있는 구 시스템도 대상이 되었다.

신규 시스템을 개발하면서 동시에 구 시스템 업데이트를 해야하는 

어처구니 없는 상황이 되었다. 

 

5-6월 내용 파악을 하고, 6월부터는 본격적인 서면 대응 작업에 들어갔다.

구 시스템은 역시나 헛점이 많았으므로, 

이를 일일히 챙기면서, 신규 시스템 기획까지 잡아나가는 일이 쉽지만은 않았다

개발 일정을 어쩔 수 없이 뒤로 미뤄야 했다. 

 

각종 버전 업데이트가 이뤄져야 했고,

정적검사 결과에 따른 조치가 이뤄져야 했다.

ISMS 심사는 그 해를 넘어서 다음해 2-3월까지 이어졌다. 

결국 어떻게든 보완을 해 잘 마루리 할 수 있긴 했으나.. 예상치 못한 업무 부하 상승에 

프로젝트 진행이 갑절로 어려워진 주요 요인이기도 했다.