허락보다 용서가 쉽다

"허락보다 용서가 쉽다"

이건 어느 게임기 광고 문구이다. 여러 의미를 담고 있겠지만 나에게는 권한이 없을때 과감하게 추진했었던 몇가지 일을 떠올리게 했다. 성공적 결과를 가져오긴 했지만 그 과정을 합리화하려는 건 아니고 필요하다면 용서도 필요했던 그런 일들이었다.

 

1. 군 훈련소 시절, 오후 2시 대략 100여명 정도 되는 훈련생들이 창고앞에 모였다. 창고에는 피복과 각종 장비들을 담은 박스가 엄청 쌓여있었고 오늘 오후의 미션은 이 박스들을 500미터쯤 떨어진 창고로 모두 옮기는 일이었다 2개조로 나누어 옮기는 일이 시작되었는데 조교는 오늘 다 못하면 내일까지 이어서 한다고 했다.

박스 하나가 혼자 들기엔 좀 버겁고 둘이 들기엔 애매한 사이즈와 무게였다. 제각각 각자의 방법대로 박스를 옮겼고 나 역시도 박스를 들고 두번 왔다갔다하니 일이 장난 아니었다. 힘도 들거니와 내일까지 하더라도 할 수 있을까 하는 물량이었다. 일부는 바닥에 질질 끌고 가다가 조교에게 혼이 나기도 했다. 그 순간 나는 컨베이어벨트가 떠올랐고 창고 입구로 달려가 바닥에 박스를 세네개 이어 붙여놓고 새 박스를 끌어보았다. 그 결과 박스끼리의 마찰이 적어 미끄러지듯 움직였다.

 

조교에게 제안해볼까도 했지만 당시 워낙 호랑이 같이 무서운 조교여서 엄두가 안났다. 그래도 그 생각은 계속 머릿속을 멤돌았고 결국 박스위로 올라가 다른 훈련생들에게 방법을 일러주었다. 우리조 인원들을 오 좋은데 하면서 적극적으로 박스를 일렬로 배치하여 떨어진 창고까지 이어갔고, 박스를 옮겨보니 예상대로 작업이 매우 빨라졌다. 옆에조도 보다가 같은 방법으로 박스를 옮기기 시작했고 작업은 몇시간만에 끝날 수 있었다.

잠시 자리를 비웠었던 조교도 보더니 처음에는 뭐라고 하다가 지켜보기 시작했는데 작업이 성공적으로 다 끝나고 나니 누구 아이디어냐고 물었다. 나는 조용히 피씩 웃었다. 친했던 주변의 동기들도 그걸보더니 조용히 있어주었다. 그날 저녁엔 특식이 추가되었다.

 

 

2. 어느 공공기관 프로젝트를 할때였다. 개발은 한 주 마다 당당자와 중간 점검차 개발완료된 기능들을 테스트하며 진행되었다. 요구사항이 상세해서 개발하는데 어려운 부분들도 있었으나 가장 큰 골칫거리는 익스플로어 호환문제였다. 담당자는 IE6 를 사용 중이었는데 번번히 오동작을 하거나 화면이 깨지기 일쑤였다. 호환성 문제해결은 상당한 시간이 걸리는 작업이었고 개발일정은 점점 조여들었다.

 

선임들과 식사를 하다가 왜 담당자는 저리도 IE6를 고집하는지에 대한 얘기가 나왔다. 대국민 서비스니까 서비스가 불가한 환경이 있어서는 안된다는 논리로 담당자는 끝까지 업데이트 하지 않는다고 했다. 당시 IE6를 쓰면 지금 개발중인 프로젝트 뿐만 아니라 정상적인 인터넷을 사용하기가 어렵기 때문에 MS에서도 업데이트를 하라고 계속 푸시를 주고 있었고 실제 IE6 사용자도 통계상 1~2프로 남짓이었다. 나는 이런 상황들을 얘기하고 담당자만 업데이트를 하고 만약 오픈이후 IE6 사용자가 접속시 업데이트 권장 팝업을 추가해주면 되는 되는일 아니냐고 의견을 내보았다.

 

다음날 PL은 담당자 호출로 갔다가 오시는 길에 우리에게 V 표시를 했다. 평소처럼 IE6에서만 동작하지 않던 문제를 보러 갔다가 담당자가 잠시 자리를 비운사이 업데이트를 하셨다고 했다. 다운그레이드가 안되고 윈도우를 새로 설치하더라도 최신 IE가 설치될테니 돌이킬 방법은 없었다. 담당자도 처음에는 화를 내셨다고 했는데 결국은 인터넷 사용이 자신도 불편해서 이번 프로젝트만 끝나면 업데이트를 하려고 하던 참이었다고 하셨다. 다행히 헤프닝으로 일은 마무리 되었고 프로젝트도 일정에 차질없이 끝날 수 있었다.

 

 

3. 개발하던 서비스가 부득이한 이유로 종료를 해야 했던 상황이었다. 서비스 오픈도 어렵지만 서비스 종료는 더더욱 어려웠다. 뿐만아니라 팀원 모두도 서비스 종료 상황을 겪어본적이 없다보니 서비스 종료일은 다가오는데 진행은 생각만큼 수월하게 진행되지 않았다. 나는 우선 유사서비스의 국내와 해외 종료 사례 그리고 일반 서비스의 사례들을 찾아보았다. 그리고 종료에 따른 기사들과 커뮤니티에 나오는 유저들의 반응까지 전부 스크랩했다. 이러한 자료들은 의사결정에 크게 도움이 되었다.

 

문제는 사용자들의 정보 백업서비스에서 발생했다. 수동으로 선별적 백업하는 방식과 모든 정보를 압축해서 백업하는 방법이 병행되었다. 압축처리 하는 방법을 맡아서 개발을 진행하였는데 순간적으로 많은 트래픽이 몰릴 수 있는 상황이기 때문에 다양한 고려가 필요했다. 거기다가 용량이 너무 큰 경우 압축된 파일이 4GB이상이 된다면 디스크 볼륨 제약으로 인해 이슈가 있는 상황이었다.

 

미리 압축해 놓는게 아니라 실시간 압축이 되면서 분할 압축까지 해야하는 고난이도 기술이 필요했다. 밤새 솔루션을 개발하고 시뮬레이션 했지만 리스크가 너무 컸다. 원본파일을 쪼개야만 했다. 따라서 유일한 해결책은 모든 사용자의 데이터를 미리 압축해 놓은 거였다. 이용률이 얼마나 될지 모르는 상황에서 이 방법은 비용도 크고 너무 비효율적이라고 생각했다.

 

또 다른 해결 방법이 있었다. 모든 분할 압축의 사이즈를 동일하게 하는 것은 어렵지만 원본 파일 사이즈와 압축률을 계산해서 분할 압축 사이즈를 모두 비슷하게 맞추는 것은 가능했다. 원본파일을 쪼개지 않아도 되어 리스크를 줄이고 실시간 압축이 보장되었다. 이 이슈는 개발팀 내부에 공유되었고 문제는 있을 수 있으나 추가 해결방안이 없으므로 일단은 상황을 지켜보자는 의견으로 모아졌다. 그 말은 즉 미리 압축하는 건 하지 않겠다는 강한 의지이기도 했다. 물론 그것 말고도 불확실한 여러 상황들이 많아 일정에 영향을 줄 수 있었기 때문이기도 했다.

 

일정상 전체 사전 압축을 할 수 없을때 개발팀은 이 이슈를 공개했고, 기획은 어쩔 수 없다는 반응으로 백업 서비스가 오픈되었다. 결과적으로 사용자들은 대부분 선별 백업 방식을 취했고, 분할 압축 백업의 경우도 별다른 CS 없이 무사히 서비스를 종료할 수 있었다.

 

 

일을 진행하다보면 굉장히 많은 선택의 기로에 서게 된다. 그 선택이 좋았는지 좋지 않았는지는 단순리 결과가 말해주는 것도 아닌 것 같다. 다만 그 과정에서 어떻게 하면 다음에는 더 나은 선택을 할 수 있을지 그 조각을 조금이나마 찾는건 도움이 되지 않을까 싶다.