소년이여, 덕후가 되어라
제가 처음 상경하여 도시가스 시스템 통합 프로젝트에 투입되었을 때의 이야기입니다. 이제 겨우 3개월간의 수습 기간을 지나 연봉계약서에 적힌 월급(이라고 해봐야 열정 페이라는 단어가 정말 정말 가슴으로 다가오는 액수이지만)이 제대로 나오려는 찰나, 차장급씩이나 되는 저의 사수님이 다른 프로젝트에 발령이 나는 바람에 180본에 달하는 서브시스템 하나를 통째 넘겨받게 되었습니다. 급격한 상황 변화를 받아들이지 못하고 욕설과 함께 격한 반응이 터져나왔던 건 저뿐만이 아니었습니다. 당연하게도(그리고 불행히도), 꼬꼬만 개발자였던 제가 갑님을 대하는 솜씨는 갑님들이 저를 대하는 솜씨에 비할 바가 못 되었습니다. 그동안 차장님의 꼿꼿한 주장을 꺾지 못했던 현업분들은 그야말로 쾌재를 불렀습니다.
그중에서도 가스계량기 리퍼비쉬 업무는 가장 뜨거운 감자였습니다. 좀 더 자세히 풀어쓰자면, 수리를 요하는 계량기의 수량이 지역별, 용량별로 DB에 담겨 있습니다. 계량기 수리는 시간이 걸리는 작업이므로, 도시가스가 몇 개의 수리 업체에 주문을 넣으면 수리 업체는 리퍼품을 전달합니다.
문제는 이 두 개의 테이블(수요/공급)이 각각 2차원 그리드로 표현되어야 한다는 점이었습니다. 개발 중인 프로젝트를 넘겨받았을 당시, 이 두 개의 그리드 사이로 수량이 오고 가는 과정은 매우 비 직관적이었습니다.
이 문제를 공학적으로 접근해 봅시다. 수요 테이블은 거칠게 지역/등급/수량이라는 필드가 있고, 공급 테이블은 업체/등급/수량 필드가 있을 겁니다. 두 테이블은 명시적으로 어떠한 관계도 맺지 않았지만, 암시적으로는 m:n 관계를 맺어야 합니다. 한 업체가 두 개 이상의 지역을 커버할 수도 있고, 반대로 한 지역의 수량을 여러 업체에 배분할 수도 있을 테니까요. 이렇게 엔티티가 m:n이라는 아름다운 관계를 맺고 있는 상황을 전문 용어로 '엿 됐다'라고 표현합니다(죄송합니다. 그런 용어는 없습니다). 당연히 이 관계를 각각 m:1과 1:n으로 중개하는 테이블이 필요했겠지만, 이미 늦어질 대로 늦어진 프로젝트 상황상 프로젝트 매니저는 엔티티의 변경을 허용하지 않았습니다.
저는 어쨌든 이 개족보를 중개 테이블 없이 로직으로만 풀어야 했고, 여기에 더해 사용자 편의성을 더하는 건 무척 난감한 과제였습니다. 현업과의 몇 차례 인터뷰는 물론, 그들이 일하는 사무실에 직접 방문해 레거시 시스템에서 업무를 처리하는 방법도 어깨너머로 배우고 심지어는 계량기가 등급별로 어떻게 생겨먹었는지, 어떤 구조로 사용한 가스를 계량하는지 따위 등 프로그램과는 직접적인 연관도 없는 지식까지 다 묻고 배웠습니다. 마침내 저는 현업이 만족할 만한 UX를 제안하였는데, 그 UX는 우습게도 '월드 오브 워크래프트'의 인벤토리 시스템을 살짝 응용한 것이었습니다. 프로젝트가 완료되고, 시스템 오픈 전 수행한 통합 테스트에서 제가 개발한 서브시스템은 이슈 0개라는 비현실적인 기록을 달성하였습니다.
위 사례에서 제가 문제를 해결하는 데 가장 중요한 열쇠가 두 가지 있습니다.
첫째는 프로그램의 기능뿐만이 아닌, 그 프로그램과 조금이라도 관련 있는 모든 제반 지식을 습득한 것이었습니다. 한동안 저는 퇴근을 하면서 보이는 모든 건물의 계량기 위치와, 이 계량기가 좌측에서 흡기하고 우측으로 배기하는 계량기인지 혹은 그 반대인지를 눈여겨보았습니다. 등급별 모양의 특징이 어떠한지, 2009년 이후로 추가된 신등급 계량기가 어떻게 생겼는지와 같은 잡지식은 프로그램 자체를 구현하는 데는 아무 쓸모가 없지만, 이후 현업과의 거듭된 인터뷰와 그들이 일하는 절차를 좀 더 손쉽게 이해하는 데 도움을 주었습니다.
두 번째는 일리단만 잡고 효도하겠다는 다짐을 하게 한 문제의 게임이었습니다. 지금이야 많은 소프트웨어의 UX 수준이 눈에 띄게 향상되었지만, 당시만 해도 블리자드사의 게임은 다른 게임과 차별화되는 탁월한 UX를 자랑했습니다. 누군가에게는 본격 미래로만 가는 타임머신에 불과했겠지만, 저에게는 실전에 응용 가능한 각종 UX를 담고 있는 보물창고와 같은 존재였죠(물론 그걸 노리고 게임 폐인이 된 건 아니었습니다만 -_-).
많은 사람들이 통찰을 소수 천재들만의 전유물로 오해합니다. 하지만 이는 사실과 다릅니다. 주위의 모든 사소함에서 '왜?'를 찾고 관찰하는 건 후천적 습관에 가깝습니다. 그리고 이렇게 모은 사색의 조각들이 언젠가는 거대한 조형물이 되어 내 눈앞에 나타나는 법입니다. 세상 거의 모든 분야와 접점이 발생하는 소프트웨어는 더더욱 그러합니다. 그러므로 - 비약된 주장이라고 생각하실지는 모르겠지만 - 여러분이 학업 또는 직장생활에 치어 충분히 체계적으로 학습할 기회가 없다고 생각한다면, 차라리 덕후가 되십시오. 비록 당장은 아무 쓸모가 없어 보일지 몰라도, 언젠가 여러분의 덕력이 실무에서 작은 보탬이 될 수 있을 겁니다. 물론 어느 분야의 덕후가 되든 간에, 적어도 여느 덕후보다는 더 뛰어난 덕후가 되어야겠다는 다짐 정도는 필요하겠죠 :)
여러분은 아마 '호접지몽'이라는, 고대 중국의 고사를 들은 적이 있을 것입니다. 장자가 꿈속에서 나비가 되어 훨훨 날다가, 깨어난 뒤 꿈임을 깨닫고 탄식하며 '내가 나비가 된 것인지, 나비가 내가 된 것인지 알 수 없도다'라고 탄식하였다는 이야기입니다. 그런데 믿거나 말거나이지만, 여기엔 뒷 이야기가 더 있습니다.
장자의 제자 중 한 명이 이렇게 탄식하는 장자의 뺨을 때리며, '외람되오나, 지금 저에게 뺨을 맞으신 분은 장주십니다. 한낱 호접이 아닙니다. 이다지도 의미 없는 탄식이 무슨 소용이옵니까?'라고 따졌다고 합니다. 어떤 의미에서는 당돌하고, 어떤 의미로는 발랑 까진 제자로군요 :-P 허나 장자는 이런 되바라진 제자를 나무라기는커녕 차분하게 대답하였다고 합니다.
'지금 네가 딛고 있는 땅을 보거라. 겨우 몇 뼘짜리 땅이면 두 발로 딛고 서는 데 족하느니라. 하지만 만약 그 한 줌의 땅덩이를 빼고 사방이 천 길 낭떠러지여도 너는 그 땅위에 온전히 서 있을 수 있겠느냐?'
바야흐로 전문가의 시대입니다. 우리는 어느 분야에서든 깊이를 요구받습니다. 하지만 땅을 깊이 파기 위해서는, 어느 순간부터는 적당한 너비가 필요하다는 사실을 여러분도 잘 아실 겁니다.
