엑셀을 치우고 싶을 때
지금이야 엑셀로 최소한 내가 의도한 작업을 수행하는데는 별다른 지장이 없게 됐지만 지금 하는 일을 처음 시작할 때만 해도 도통 엑셀을 다룰 줄 몰랐습니다. 정확히는 이 일에 엑셀이 그렇게까지 많이 필요한 줄은 미처 몰랐어요. 어느 정도 수준이었냐 하면 학교에서 시간표를 만들 때 편하게 사용하는 것 외에는 별다른 용도가 없었고 셀에 ‘3+4’를 입력해도 왜 계산되지 않는지 그 이유를 몰랐습니다. 하지만 사람은 모가지가 걸린 위기가 찾아오면 이를 해결하기 위해 바둥거리기 마련이고 그럭저럭 적응하게 목숨을 부지했습니다. 이 다음부터 꽤 오랜 기간 동안 엑셀은 주어진 임무를 수행하는데 빼놓기 어려운 프로그램이 되었습니다. 그런데 시간이 흐르면서 개발 환경이 변해 가고 한동안은 엑셀을 작업 환경에서 뺄 수 있지 않을까를 생각해 보기도 했습니다. 그래서 오늘은 이 이야기를 해 보려고 합니다.
개발환경에서 엑셀은 꽤 광범위한 용도로 사용됩니다. 워드프로세서에 표를 만든다면 ‘보여주기 위한’ 용도 외에 사용하기 어렵겠지만 엑셀에 만든 표는 어디에든 활용할 수 있습니다. 제가 기억하는 범위 안에서 엑셀이 어떤 식으로 사용되는지를 나열해 보겠습니다.
첫째. 관계형 데이터를 표현하는데 사용합니다. 거창하지만 행과 열로 이루어져 있는 데이터를 가장 쉽게 표현할 수 있습니다. 우리가 알고 있는 거의 대부분의 데이터가 이런 형태로 되어 있습니다. 가령 아이템 데이터를 이루는 각 열은 아이템 아이디나 이름, 특징 따위를 나열하고 각 행에는 아이템이 종류 별로 늘어서 있습니다. 이러한 데이터는 엑셀 파일을 그대로 사용하거나 XML이나 JSON 따위로 변환해서 게임 데이터에 직접 사용하기도 합니다.
둘째. 검색하는데 사용합니다. 검색에는 여러 가지 형태가 있습니다. ‘253812번이 뭐하는 아이템이지?’ 같은 질문에 대답하거나 이름에 ‘포션’이 들어가는 아이템이 몇 개나 되는지를 세는데 사용할 수 있습니다. ‘인벤토리에 쌓을 수 있는 아이템 중에서 사용할 때 사용 대상 정보가 필요한 아이템이 있던가?’ 같은 질문에 답하는데 사용합니다. 단순히 ‘Ctrl + F’ 키를 눌러 문자열이나 수식을 검색하는 것 이상의 교차검색을 하는 용도로 사용하고 있습니다. 사실 이것은 엑셀을 사용한다기 보다는 엑셀에 관계형 데이터가 입력되어 있기 때문에 엑셀을 통해 검색을 한다는 것 이상의 의미를 가지지는 않습니다만, 다양한 검색 니즈를 수용하기에 적당한 역할을 하고 있다는 것은 확실합니다.
셋째. 통계 정보를 얻는데 사용합니다. 방금 검색 이야기를 하면서 조금 이야기해 버렸지만 ‘이름에 포션이 들어가는 아이템이 몇 개나 되는지’ 같은 질문에 대답하는 수준에서 시작해서 ‘각 레벨 별로 사용하는 스킬의 대미지 최소값과 최대값이 전체 밸런스에 맞는가’ 같은 질문에 대답하기 위해서는 필요한 값을 검색해낸 다음 이들을 시각화하는 기능이 필요합니다. 엑셀에서는 값을 검색해낸 다음 다른 워크시트나 워크북에 복사, 혹은 연결한 다음 시각화하고 이들의 통계를 내는 등의 작업을 할 수 있습니다.
넷째. 다중작업을 지원합니다. 보통 데이터 파일이 커지면 작업자 한 명으로 커버하기 어려운 시점이 옵니다. 당연히 혼자 작업할 때는 일어나지 않던 이상한 상황이 생기기 시작하는데, 몇 가지 방법을 통해 이런 이상한 상황을 완화할 수 있습니다. 일단 파일 자체에 다중 사용자의 편집을 지원하는 기능이 있어서 공유디렉토리 같은 곳에 올려놓고 여러 사람이 열어서 수정할 수 있습니다. 또 VCS를 사용한다면 버전 간 비교와 병합을 지원합니다. 마지막으로 셀에 설명을 기록하거나 메모를 남기는 방법으로 여러 사람들 사이에 의사소통을 할 수 있고 이런 정보들이 모여 작업 히스토리를 구성하게 됩니다. 좋은 방법은 아니지만 셀에 미리 약속한 색을 칠해 추가 정보를 제공하거나 누군가는 셀 강조 규칙 따위를 사용해 함께 편집하는 다른 사람들에게 주의를 줄 수도 있습니다.
다섯째. 실제 사용되는 데이터와 이를 만들기 위한 기반 데이터를 함께 보관합니다. 엑셀 파일 자체를 실제 데이터로 사용하는 사례는 드물고 몇 가지 편의를 위해 XML이나 JSON, 또는 다른 스크립트 형태로 변환한 다음 적용하는 경우가 대부분입니다. 그런데 이 사이에 엑셀 같은 편집 프로그램이 없다면 최소한의 편집 기능을 갖춘 인하우스 툴에 의존하거나 최악의 경우에는 텍스트 에디터를 열어 편집을 해야 할 수도 있습니다. - 실제로는 텍스트 에디터보다 인하우스 에디터가 더 나쁜 경우도 있어요 - 편집환경 외에도 실제 데이터를 만들기 위해 기반 데이터가 필요한 경우도 있는데, 이를 연관된 장소 - 보통은 같은 파일의 다른 워크시트 - 에 보관해 관리할 수 있습니다. 이를테면 스킬의 공격력은 하나의 숫자로 표현될 수 있지만 이 숫자를 뽑아내기 위한 기반 데이터는 다른 워크시트에 여러 개의 데이터나 수식의 형태로 작성되어 있을 수 있는데, 이들이 서로 연관되지 않은 장소에 보관되어 있거나 아예 없다면 상당히 괴로울 겁니다.
여섯째. 작업 맥락을 유지합니다. 위에서 이야기한 ‘다중 작업’과 겹치는 부분이 있는데, 프로그래머가 코드에 주석을 달거나 별도로 문서화를 하는 것과 비슷하게 데이터를 만들 때에도 의도나 상황, 단기간의 상태, 로드맵 등을 데이터와 아주 가까운 곳에 직접 기록하는 경우가 있습니다. 이번 주 내내 문제를 일으킨 데이터를 수정하면서 - 좋은 방법은 아니지만 - 셀에 색을 칠해 두거나 메모를 남겨 놓거나, 실제 데이터에는 사용되지 않는 열을 추가해 정보를 남겨놓거나 하며 작업의 맥락을 유지합니다. 지금 작업을 하는 나 자신을 제외한 나머지 작업자들에게 - 심지어는 미래에 작업을 할 나 자신을 포함해서 - 현재 작업의 맥락을 공유해 이후 작업을 계속할 때 맥락을 처음부터 다시 파악하거나 맥락 없이 작업하는 상황을 줄일 수 있습니다.
마지막으로 데이터를 대량으로 수정하는데 사용합니다. 오늘부터 ‘포션’ 대신 ‘물약’이라고 표현하기로 결정했는데 테스트 아이템을 포함해 고쳐야 할 데이터가 한 200개쯤 되는 기초적인 상황부터 ‘쿨타임이 15초를 초과하는 사용 대상을 설정해야 하는 스킬이 사용되는 아이템 중에서 스킬 효과의 환산 점수가 50을 넘는 것들의 이름에 접두어를 추가’ 같은 조금 더 복잡한 형태로 수정하는 일도 일어납니다. 여기에는 몇 가지 기능을 섞어서 사용하게 되는데, 필터를 사용해서 수정 대상인 데이터만 표시하도록 조작하거나 몇 단계의 교차 검색을 통해 수정할 범위를 파악한 다음 각각의 데이터를 직접 수정하기도 합니다.
개발 환경이 변해 가면서 언제까지나 엑셀이 전지전능하게 사용되는 것은 아닙니다. 시간이 지나면서 입력과 수정을 위한 온갖 기능을 제공하지만 결국 독립된 파일 단위로 데이터를 뽑을 수밖에 없는 한계 때문에 편집 환경에서 엑셀을 제거하는 시도가 일어납니다. 엑셀만으로 처리하기에 만만치 않은 것들, 이를테면 데이터를 즉시 검증하거나 클라이언트와 서버에서 실시간으로 수정된 데이터의 결과를 보여줘야 하거나 데이터 파이프라인에 바이너리 데이터가 끼어있거나 하면 프로그래머 입장에서는 엑셀만 치우면 문제를 해결할 수 있을 것으로 느껴집니다. 개발 환경에서 엑셀을 치우려는 시도는 보통 다음의 순서로 진행됩니다.
일단 문제가 일어납니다. 원인은 여러 가지였겠지만 표면적으로는 데이터 포멧 문제의 형태로 시작됩니다. 엑셀을 데이터 작업에 사용한다면 거의 대부분은 어떤 방식으로든 실제 사용되는 포멧으로 바꾸는 컨버터를 사용하고 있을 겁니다. 이는 당연히 마지막으로 수정한 데이터와 실제 적용된 데이터가 일치하는지를 판단하기 어렵고 이는 문제가 생겼을 때 수정을 어렵게 만듭니다. 이런 온갖 문제는 데이터를 입력할 때 즉시 검증하도록 만들면 해결할 수 있을 것 같은데 엑셀파일 자체만으로는 검증을 하고 싶은 프로그래머들의 영역으로 가져올 수 없기 때문에 엑셀 포멧 대신 다른 포멧을 사용하자는 이야기가 나옵니다.
엑셀을 없애자는 이야기가 본격적으로 수면 위에 올라오면 온갖 새로운 포멧 이야기가 오가기 시작합니다. 사실 포멧은 어떤 것이라도 크게 상관 없습니다. 지금까지 문제로 느껴지던 여러 가지 사건은 엑셀을 사용하지 않음으로써 데이터를 프로그래머들의 영역으로 가져오기만 하면 해결할 수 있을 것처럼 보입니다. 데이터를 입력하는 즉시 검증해 문제가 생길 데이터를 미리 알려주고 수정하게 하거나, 관계형 데이터에서 늘 문제가 되던 한 셀에 여러 데이터를 입력해야 하는 이상한 상황도 즉시 해결할 수 있습니다. 또 데이터가 고정된 값이 아니라 그때그때 상황에 맞게 재계산 되어야 하는 경우도 데이터를 루아 테이블 같은 형태로 표현하면 쉽게 보여줄 수 있을 것 같습니다. 여러 가지 포멧이 도마에 올라왔다가 현재 개발 환경에 기술적으로 가장 손이 덜 가는 포멧이 선택됩니다.
포멧을 결정해 바꾸는 일은 단순하지만 지금까지 엑셀을 가지고 편집을 하던 사람들에게 XML이나 JSON, 루아 테이블 같은 것을 직접 편집하라고 던져주기에는 조금 무리가 있습니다. 그래서 기왕 데이터를 프로그래머의 세계로 가져온 김에 편집 환경도 프로그래머의 세계로 가져오기로 합니다. 그 동안 엑셀을 사용했기 때문에 서로 다른 행에 표현된 데이터가 연결되어 있는 모습을 시각화할 수 없었지만 이제는 편집 환경에서 실시간으로 트리를 그려 관계를 시각화 해서 보여주기로 합니다. 시각화된 정보를 선택하면 옆에 프로퍼티 윈도우를 보여주고 거기서 수정한 데이터는 즉시 시각화된 정보에 반영되는 멋진 인하우스 에디터가 탄생합니다.
지금까지는 꽤 괜찮은 시나리오였다면 문제는 여기서부터 시작됩니다. 위에서 개발환경에서 엑셀이 어떤 식으로 사용되는지에 대해 조금 다룬 이유가 이것입니다. 엑셀은 프로그래머들의 예상보다 좀 더 광범위하게 사용되고 있었습니다. 데이터를 추가하고 수정하고 삭제하는 작업 외에도 검색, 통계, 다중 작업과 히스토리, 데이터 소스 관리, 작업 맥락의 유지, 다중 수정 등에 사용되고 있었는데 방금 만든 인하우스 에디터는 이들 중 최소한의 임무만 수행할 수 있는 수준입니다. 굳이 거칠게 표현하자면 코드 에디터가 있는데 주석은 달 수 없는 겁니다. 혹은 문자열 검색은 가능한데 정규표현식은 사용할 수 없는 겁니다. 처음에는 이런 니즈에 어느 정도 대응하지만 시간이 지나면서 엑셀에서 20년 넘게 만들어 대응하던 온갖 기능을 인하우스 에디터로 따라가는 것은 불가능하다는 결론에 다다르게 되고 다음 단계로 넘어갑니다.
편집 환경에서 엑셀과 경쟁할 수는 없다는 판단에 다다르면 다시 엑셀을 편집 환경에 집어넣자는 이야기가 나오게 됩니다. 보통은 대량 수정을 언제나 프로퍼티 에디터 같은 것을 통하기는 어렵기 때문에 몽땅 엑셀에서 읽을 수 있는 형태로 익스포트 한 다음 엑셀에서 원하는 온갖 기능을 사용해 편집한 다음 다시 인하우스 에디터에서 편집할 수 있는 형태로 임포트하는 기능을 추가하게 됩니다. 하지만 위에서 이야기한 대로 엑셀을 사용할 때에 나타나는 장점은 엑셀을 지속적으로 사용할 때 나타나는 것들이 대부분입니다. 다중 작업을 하거나 작업의 맥락을 저장하거나 기반 데이터를 보관하는 등의 작업이 그렇습니다. 이들은 모두 일시적인 엑셀 사용만으로는 얻을 수 없는 장점입니다. 거기에 대량 수정을 위해 엑셀로 데이터를 익스포트 했다는 것은 작업하는 동안 다중 사용이 불가능해진다는 것을 의미하기까지 합니다. 결국 편집 환경에 엑셀을 다시 집어넣었음에도 엑셀을 사용할 때 얻을 수 있는 장점 대부분을 잃어버리고 대량 수정 작업에나 근근히 사용하는 수준이 되고 맙니다.
한 가지 다행인 것은 인간은 적응하는 동물이고 개발팀은 시간이 지남에 따라 스탭이 교체된다는 점입니다. 불편한 작업 환경에 일부는 적응하고 또 다른 일부는 시간이 지남에 따라 교체됩니다. 시간이 지나고 나면 인하우스 에디터로 교체하는 과정을 겪은 사람이 거의 없어지고 남은 사람들은 ‘원래 이렇게 해 왔던 것’으로 느끼며 별다른 불만 없이 작업을 하게 됩니다. 불편하고 비효율적인 작업 환경에서 오는 퍼포먼스 저하를 알아챌 만한 스탭이 더 이상 존재하지 않게 되기 때문에 이 상태가 계속해서 유지됩니다. 혹은 시작할 때 이야기한 엑셀 파일과 컨버터가 있는 처음 상태로 돌아가기도 합니다.
개발 환경에서 엑셀은 생각보다 더 넓은 범위의 용도에 사용되고 있고 이를 한 번에 다른 도구로 대치하는 것은 그리 간단한 문제는 아닙니다. 단순히 편집 환경에서 엑셀을 제거하고 이를 대신할 도구를 제공하는 식의 접근보다는 조금 더 섬세하게 데이터 파이프라인을 점검해 보고 실제로 당면한 문제가 무엇인지를 파악해야 합니다. 실제 문제는 ‘엑셀을 실제 데이터로 컨버팅하는 것’이 아니라 ‘새로 추가하는 데이터의 아이디를 즉시 검증할 수 없는 것’과 같이 보다 국소적인 문제일 수 있습니다.
엑셀을 개발 환경에 계속해서 사용해 나타나는 문제도 있습니다. 서기 2013년에는 좀 더 똑똑하고 편안하게 해결할 수 있는 문제들인데도 말입니다. 방금 이야기한 아이디 관리 같은 것이 그렇습니다. 사실 아이디는 각각의 행을 유일하게 만들어주는 값이면 충분하지만 십 수년 전에 게임 만들 듯 만번에서 이만번 사이는 회복아이템, 오만번에서 칠만번 사이는 장비아이템 하는 식으로 아이디를 나눠 매번 행을 추가할 때마다 룰에 어긋나지 않도록 인간이 신경 쓰는 일은 사실 멍청할 뿐만 아니라 정확하지도, 효율적이지도, 미래지향적이지도 않습니다. 또 엑셀이 중간에 끼어 있어 데이터 컨버팅에 생기는 온갖 문제를 안고 있고 데이터를 실시간으로 서버와 클라이언트에 적용해보는 서기 2013년의 개발환경이라면 충분히 고려해볼만한 장점도 쉽사리 얻지 못하고 있습니다.
분명 엑셀은 좋은 도구이지만 서기 2013년의 개발환경에서 지난 십 수년 동안 별 생각 없이 유지해 온 엑셀을 포함한 개발 환경과, 데이터 파이프라인에 대한 고려 없이 단지 엑셀 파일을 사용하는 것을 문제로 정의하고 이를 일 대 일로 교체하려는 이미 실패했을 온갖 시도를 반복하는 것은 대략 좋지 않습니다. 만약 엑셀을 작업 환경에서 치우려고 한다면 치워야 하는 정확한 이유가 무엇인지를 파악한 다음에 시도해야 하고, 시도 과정에는 엑셀이 어떤 식으로 사용되고 있었는지에 대한 좀 더 깊숙한 조사와 준비가 필요합니다. 그래서 엑셀을 쓰라는 말인가, 쓰지 말라는 말인가. 물론 그건 개발팀의 결정에 따라야죠. :)
