회사에서 나오는 최종의 산출물은 HTML + JavaScript + Flash ActionScript 의 집합체다. 그것을 만들어 주는 것을 MFC로 구성된 프로그램이 수행하기는 하지만, 대부분의 문제점은 저 최종 산출물 그러니까 껍데기에서 나온다. 그러다 보니 전자책이라는 그 특성상 각 브라우저에서 어떻게 보여지는가를 신경쓰지 않을 수 없다.
내 업무용 데스크 탑에는 익스플로러, 파이어폭스, 넷스케이프, 사파리, 오페라의 5개의 웹 브라우저가 깔려있다. 그리고 Mac iBook에는 사파리, 파이어폭스, 오페라의 3개 브라우저가 깔려있다. 물론 국내의 경우에는 IE의 영향이 지대하고, 솔루션이나 책을 구매하여 서비스하는 고객들도 IE외에의 호환성에는 신경쓰지 않는다.
물론 구색 내기 좋아하는 예외적인 경우도 있지만 대부분 IE로만 Ok이다. 그러나 이 거래처가 일본으로 넘어가면 또한 사정이 달라진다. 생각보다 Mac유저가 많기 때문에 대부분 Mac에서의 호환성도 요구를 한다. 더군다나 IE외의 다른 유저도 많아서 어쩌다 일본에 걸리게 되면 도합 8개의 브라우저 테스트를 진행해야 한다.
정말 사람 미치는 일이 아닐 수 없다. 차리리 그것만 하면 다행이다. 나는 개발자이지만, 이곳에서 테스트도 하고 CS도 하고, 영업과 '네고'도 한다. 가끔 파악되지 않는 오류가 나오면 외근도 가서 기술지원 및 영업도 하고 온다. 지금 이 시간 위에서 기술한 삽질을 하고 있다.
솔직히 이런 일을 예상못했던 바는 아니다. 언제나 계속되는 일정없는 요구사항에 대해서 근 일주일 내일 퇴근을 하면서 만든 산출물이니, 겉은 그럴싸 했지만 속을 까보면 엉망진창. 분명 IE외에서의 원활한 작동을 보장할 수 없었다. 결국 고생은 다하고, 그 부메랑이 다시 돌아와 다시 또 수정하느라 고생하는 것이다. 끓어지지 않는 악순환.
충분한 시간과 여유를 주면, 후자의 삽질을 하지 않아도 될 것인데 왜 그걸 모르는 걸까? 이렇게 오류가 고객에 의해서 들통나 돌아오면 그 만큼 신뢰도도 깍아먹는 길이고, 내부인원이 다시 고생한다는 길인데. 물론 모를리 없겠지. 자신들의 노고가 들어가지 않기 때문에 그저 부품을 돌릴뿐이다.
텅 빈 사무실에 혼자 남아 한 삽 뜨고나니 한숨이 나와 이렇게 넋두리를 해본다.