세상 사람 누구나 '설계'라는 단어의 의미를 안다. 돈을 주고 사고 파는 가전제품, 건축물, 자동차, 옷 등 다양한 상품들이 설계라는 과정을 통해서 만들어진다는 것도 안다. 그리고 설계 없이 무언가가 만들어진다는 것은 상상하기 어렵다. 아이들의 장난감조차도 말이다. 그런데 정작 수천만원에서 수억의 돈을 들여서 만들어지는 웹 사이트, 프로그램들을 구현할 때 제대로 설계가 이루어지지 않는다고 한다면 소프트웨어를 모르는 일반인들이 이해할 수 있을까? 수백억을 들여 영화를 제작하는데 있어서 시나리오도 없이 촬영하고 편집한다는 얘기와 다를 바 없는 것이다. 그런데, 막상 소프트웨어를 제작하는 사람들 중 대다수가 소프트웨어를 어떻게 설계하는가에 대해서 거의 모른다고 할 수 있다.

물론 IT에서 10년 이상 개발을 해온 나 자신도 정확히 어떻게 설계하는 것이 법칙(규칙)이라고 말할 수 없다. 왜냐하면 소프트웨어 설계에서 대해서는 단 한번도 규칙이나 원칙이 만들어진 적이 없기 때문이다. 서점이나 인터넷을 뒤져보면 분명히 소프트웨어 설계에 관한 문서들을 찾을 수 있다. 하지만 그것들은 거의 ~론이라고 불리운다. 어떻게 하는 것이 좋다는 주장이자 의견이지 법칙이 아니라는 것이다. 춘추전국 시대의 온갓 사상처럼 무엇이 옳다, 무엇이 대세다 라고 말할 수 없이 그저 혼란스러울 뿐이라는 것이다. 소프트웨어 관련 기술 혹은 분야는 사실상 '성숙된 산업이나, 학문이라고 할 수 없다'라고 단언할 수 있다.

그럼에도 불구하고, 아니 그렇기 때문에 더욱 더 소프트웨어 설계, 아키텍쳐 설계가 중요한 것이다. 왜냐하면 소프트웨어는 더 이상 한두 사람의 노력으로 만들 수 있는 것이 아니며 - 80년대 그리고 90년대 초까지만 해도 한명이나 서너명의 노력으로 소프트웨어를 제작할 수 있었다 -, 비용 면에서는 수억에서 수백억의 투자가 발생하는 거대 비지니스이기 때문이다. 몇달에 걸쳐 수십명의 개발자, 그리고 수억의 돈이 투자되는 이유는 그만큼 중요하고 필수적인 인프라이기 때문이다. 대기업에서 소프트웨어 구축 프로젝트가 한두달 지연되면 수천억 이상의 손해가 발생할 수 있다. 만일 은행 시스템이 하루라도 중단되면 어떤 일이 벌어질까? 네이버 검색 시스템 개편이 한달 지연된다면 NHN이 감당해야할 손해는 얼마일까?

어쩌면 아키텍쳐 설계가 다 부질없는 짓일지도 모른다. 소프트웨어 개발은 고통스러운 일이며, 아무도 인정해주지 않는 일이기 때문에 열심히 일해봐야 소용없고 더 나이들기 전에 그만두는 것이 낫다는 의견도 일리는 있다. 우리나라에서는 아키텍트라는 직종이 존재하지도 않고, PM은 그저 아랫사람들을 열심히 닥달하기만 하면 되는 것일지도 모른다. 그러나, 그런 식의 태도와 접근이 해답일까? 아무것도 아니다. 아무런 노력도 하지 않는다면 미래는 나아지지 않는다. 사회가 바뀌지 않는다고 노력하지 않으면 떠내려 가고 과거의 유물이 될 뿐이다. 당장 수억을 들여 개발하는 프로젝트가 제대로 된 아키텍쳐 없이 진행되고 있다면 성공할 확률보다 실패할 확률이 높다는 것이 자명하다. 그걸 알면서도 내버려 두고, 아무런 시도도 하지 않겠다는 것은 변명도 무엇도 아니다. 그저 포기 선언일 뿐이다.

아키텍쳐 설계 자체는 목표가 될 수 없다. 아키텍쳐 설계는 '프로젝트 성공'과 '우수한 소프트웨어' 개발을 위한 방편이며, 도구이다. 아주 필수적이고 당연한 것이란 말이다. 아무런 원칙도 규칙도 없을지라도 어떠한 방식으로라도 설계해야만 한다. 자동차가 처음 나올 때부터 지금의 모습이었는가? 수십년 이상에 걸쳐서 수정된 모습일 것이다. 설계는 아무나 할 수 없는 것이라는 편견도 버려야 한다. 당신이 만들고자 하는 소프트웨어의 모습을 어떤 방식으로든 그려내면 된다. 연필과 펜만 있이면 된다. 게다가 무수히 많은 방법론과 이론을 다 공부할 수는 없다. 다만 써먹을 수 있는 것 한가지라도 갖추어야 할 것이다. 설계에서 중요한 것은 어떤 이론이나 규칙을 적용했느냐가 아니라, 남들이 당신의 설계를 이해할 수 있느냐, 설계서를 보고 무언가를 만들 수 있는가 하는 것이다. 비록 채택한 방법론이 결국 틀린 것 혹은 비주류의 것이라는 판단을 하게 될지라도 말이다. (사실 아주 틀린 것은 없다. 구조적 프로그래밍 기법도 여전히 객체지향 내부에 살아있기 때문이다.)

결론은 단순하다. 일을 잘해서 프로젝트를 성공시키고 인정받자. 그러기 위해서 소프트웨어 아키텍쳐를 설계할 줄 알아야 한다. 그러면 혹시 성공할지도 모른다. 반면에 설계할 줄 모른다면 거의 대부분 실패할 것이다.