이런 방법도 있구나....
여러 일들을 하면서 가장 많이 깨달은 게 있습니다. 일을 하는데 선택할 수 있는 방법은 정말 다양하다는 사실이죠. 이렇게 해도 되나....? 싶은 것도 하나의 방법이 될 수 있고, 나라면 하지 않을 거라 생각했던 것들도 하나의 방법이 될 수 있습니다. 항상 옳은 건 없다는 걸 새삼 깨닫게 되었습니다.
IT 업계에 유명한 말이 하나 있습니다. "은탄환은 없다(No Silver Bullet)"라는 말인데, 튜링상을 받으신 프레드 브룩스란 분이 쓴 책에서 나온 말입니다. 늑대인간과 같은 괴물을 해치울 수 있는 무기를 의미하는 '은탄환'은 어려운 문제를 쉽게 해결해 줄 수 있는 '최고의 방법'을 의미합니다. 하지만 소프트웨어는 이런 은탄환이 없다는 의미로 쓰인 말입니다. 여러 회사를 다니면서 이 말이 정말 맞다는 걸 아주 많이 깨닫게 되었습니다.
프로그래밍이란 분야를 공부해 보면 '객체지향'이라는 방법론에 대해 배우게 됩니다. 프로그램을 만들 때, 객체를 중심으로 프로그램을 설계하고 만들어가는 것을 의미합니다. 브런치를 만든다고 가정한다면, "작가"라는 객체를 만들고 "기사(또는 글)"라는 객체를 만들고, "서랍"이라는 객체를 만든 뒤 각 객체 간의 소통이 일어나도록 프로그램을 만드는 방법이죠. 조금 규모가 큰 프로젝트는 대부분 이런 형태로 작업을 진행하게 됩니다. 그래서 나중에 수정하기도 용이하고 확장하기도 좋거든요.
새롭게 다니는 회사는 이런 것과 무관했습니다. 놀라울 정도로요. 이전에 프로젝트 규모에 대해서 살짝 이야기했는데, 프로젝트 규모 자체가 작은 건 아니었습니다. 기능의 양이나 사용자 수 등을 감안한다면 꽤 규모가 있었습니다. 그럼에도 이 회사의 프로젝트는 배울 점이 매우 많았습니다..... 안 좋은 쪽으로 말이죠.
가장 놀랐던 점은 아무런 개념 정리가 없이 펼쳐진 내용들이었습니다. 이 상태로 계속 서비스할 수 있을까....? 싶을 정도로 제 기준에서는 엉망진창인 내용들이 가득했습니다. 저희가 공부할 때는 같은 행동을 반복하지 말라고 이야기합니다. 비슷한 동작을 하는 내용들은 묶어서 기능으로 만드는 것을 기본으로 배우죠. 그리고 이곳에는 비슷한 동작을 하는 수십 개의 기능이 나뉘어 있었습니다. 비슷하게, 그리고 다 다르게. 고치기도 어렵고, 합치기도 어렵게 나뉘어 있었습니다. 그래서 큰 충격을 받았습니다.
이것도 방법이라면 방법이구나....
이상하게 들리실 수 있지만, 그때 저는 저렇게 느꼈습니다. 이것도 방법이 맞겠구나.... 하고. 잘 만들었다 생각했던 프로젝트보다 이 프로젝트가 더 많은 사용자들이 이용하고 있었거든요. 옳다 그르다의 이야기가 아닌, 다양성의 관점에서 이 또한 하나의 방법이라고 깨닫게 되었습니다.
그 이면에는 수많은 사람들의 노고가 있었습니다. 이 또한 방법이지만, 이 방법은 문제가 생기기 쉬운 방법이었습니다. 그럼, 문제가 많이 발생하겠죠? 그걸 사람이 막아내고 있었습니다. 사용자에게 서비스가 전달되기 전 QA라는 과정을 거친 뒤 사용자에게 서비스가 전달됩니다. 그리고 이곳에서 쓰는 방법은 QA 기간과 인력을 충원해서 문제점을 최대한 많이 찾아서 넘기는 방식을 택했습니다. 이곳은 그렇게 돌아가고 있었습니다.
어떤 배달 앱을 만들었던 회사는 초기에 직접 전화로 주문배달을 했다고 합니다. 어떻게 보면 "그렇게 한다고?" 싶을 방법이지만, 당시 선택할 수 있는 방법 중 하나를 선택했을 거라 생각됩니다. 방법은 한 가지가 아닙니다. 그 방법이 조금 어설퍼 보이거나 허술해 보일 수 있지만, 그 또한 한 가지 방법일 거라 믿습니다. 내 방법이 이상하다 생각될 수 있지만, 그게 좋은 방법일 수 있습니다. 방향대로 잘 나아가고 있다면, 방법은 어떤 방법이든 나올 수 있으니까요.
- 메인 서버가 되고 난 뒤, 1년간 서버를 거의 새로 만들었습니다.
- 그리고 얼마 뒤, 팀에서 개발자가 저 혼자 남는 사태가 발생하게 됩니다....