신승환

좋은 아키텍처, 나쁜 아키텍처, 이상한 아키텍처

2012-01-06

스페인에 가면 당연히 봐야 하는 건축물들이 있다. 그중에서 반드시 봐야 하는 건축물을 꼽으라고 한다면, 아마도 '사그라다 파밀리아 성당'일 것이다. 이 성당은 건축가 안토니 가우디가 설계한 것으로, '가우디 성당'이라고 더 잘 알려졌다. 가우디가 이 성당의 건축을 맡은 것은 1883년이었다. 그는 죽기 직전까지 이 성당의 건축에 매달렸지만, 아쉽게도 완공이 되는 것을 보지 못하고 죽었다. 그렇다면 이 성당은 언제 완공이 되었을까? 아니다. 이 성당은 지금도 건축중이란다. 관광수입으로 조금씩 짓고 있다고 한다.

 

가우디 성당

 

미국의 산호세에 가면 기괴한 건물이 하나 있다. '윈체스터 맨션'이라는 건물인데, 총기를 제조하는 원체스터社의 상속녀인 사라 윈체스터가 지은 건물이다. 이 건물이 이상한 이유는, 건축이유에서 찾을 수 있다. 사라는 그녀의 남편이 죽자 남편 회사의 일부 지분과 남편의 재산을 상속받는다. 어느날 남편의 혼과 이야기를 나눈 주술사에게 충격적인 이야기를 든는다. 남편은 주술사를 통해서 부인에게 이런 이야기를 전했다고 한다.

 

"부인, 우리가 만든 총에 죽은 원주민들과 동물들 그리고 당신이 살 집을 지으시오. 단, 공사를 멈추지 마오. 공사를 멈추면 당신은 죽음을 맞이하게 될 것이오."

 

이 이야기를 듣고 기절초풍한 사라는 어떻게 했을까? 산호세로 이사해서 지금의 윈체스터 맨션에 자리를 잡았다고 한다. 처음에 이 집은 방 몇만 있었다. 하지만 그녀는 이사하고 나서 공사를 시작했다. 그리고 그녀가 죽을 때까지 약 38년간 공사를 쉬지 않고 했다. 그 동안 수 백 채의 방을 지었고 그만큼의 방을 부수기도 했다. 무계획적인 공사 덕분에 맨션에는 엄청난 규모의 계단이 생겼고 어떤 방에는 사람이 살 수 없게 만들어지기도 했다고 한다.

 

윈체스터 맨션

 

전함 바사에 관한 이야기다. 전함 바사는 예전 포스트에서도 소개한 적이 있다. 1620년 대 스웨덴은 폴란드와 전쟁중이었다. 스웨덴 임금은 해상권을 장악하기 위해서 화력이 강력한 전함을 만들 것을 지시했다. 이 프로젝트의 책임은 '헨릭 허비슨'이 맡았다. 서로 모순되는 요구사항이 너무 많은 탓에 전함을 건조하는 일은 쉽지 않았다. 그 중에서 가장 어려운 것은 많은 수의 대포를 장착하는 것이었다. 어찌어찌하여 전함은 건조되었고 드디어 출항하는 날이 밝았다. 첫 출항을 자축하는 축포를 발사하다가 웃지 못할 사건이 벌어졌다. 대포가 너무 강력하다 보니 축포의 반동으로 배가 기울고 말았다.

 

전함 바사

 

앞에서 설명한 가우디 성당, 윈체스터 맨션, 전함 바사의 공통점은 무엇일까? 여러가지가 있겠지만, 난 '아키텍처'라고 본다. 가우디가 죽고 나서 수십 년이 지났음에도 원래 계획대로 공사가 진행될 수 있었던 이유는 무엇일까? 가우디가 성당의 전체적인 청사진인 '아키텍처'를 잘 잡았기 때문이다. 유령 들린 집의 대명사가 된 윈체스터 맨셔의 경우는 어떤가? 아키텍처라고 부를만한 것이 없다. 그 집의 공사를 총괄한 사라 윈체스터의 목적은 공사의 진행이었다. 결국 아키텍처의 부재는 사람이 살지 못하는 기괴한 집이 만들어지게 했다.

 

전함 바사의 경우는 어떨까? 통일성이 있고 그 규모의 배를 만드는 일이었기 때문에, 아키텍처는 분명히 있었다. 하지만 아키텍처를 설계하면서 요구사항이 제대로 반영될지 요구사항 간 모순이 없는지 검토하지 않았기 때문에 출항하자마자 침몰하는 운명을 맞게 되었다.

 

결론적으로 보자면 아키텍처가 좋거나 이상하거나 나쁘면, 그 결과물도 좋거나 이상하거나 나쁘다. 앞의 예들은, 분야는 다르지만 아키텍처가 얼마나 중요한지를 보여주는 좋은 사례라고 생각한다. 그렇다면 소프트웨어에서 좋은 아키텍처란 어떤 특징을 가져야 할까? 최신 UML 도구를 사용해서 그리고 UML을 실행해서 아키텍처의 성능 평가를 할 수 있어야 좋은 아키텍처를 그리는 것일까? 이것도 중요한 조건이겠지만, 난 아키텍처를 그리는 표기법이나 도구는 정말 부차적인 요소라고 생각한다. 즉 아키텍처를 그리는 목적에 부합하지 않는다면, 아무리 좋은 표기법이나 도구를 써도 소용없다.

 

최근에 내가 쓴 '대한민국 소프트웨어 리스타트'에서도 아키텍처와 아키텍트에 대해서 몇 개 chapter를 할애했다. 그 가운데 좋은 아키텍처가 가져야 할 조건으로 두 가지를 이야기했다. 요구사항은 기능 요구사항과 비기능 요구사항으로 나눈다. 요구사항 측면에서 보자면 아키텍처는 기능 요구사항을 잘개 쪼개서 개발자가 단위 설계에 집중해서 자신이 맡은 모듈을 만들 수 있는 수준으로 나눌 수 있어야 한다. 흔히 말하는 분해(decomposition) 작업을 하면서 응집성이 높고 결합성이 낮은 구조가 되도록 아키텍처를 구성해야 한다.

 

다음으로 비기능 요구사항을 아키텍처가 담아낼 수 있을지 검증해야 한다. 예를 들어서 고객이 비기능 요구사항의 하나로 가용성을 요구했다. 가용성의 수준이 99.99%라고 한다면, 과연 우리가 만드는 소프트웨어 시스템이 이런 가용성을 달성할 수 있을지 어떻게 알 수 있을까? 만약에 아키텍처에서 이런 것들을 고민하지 않는다면 개발자들의 단위를 완성하고 나서 각 단위를 모두 합치고 통합테스트를 해보기 전까지 이런 가용성을 만족할 수 있을지 알 수 없다. 물론 이런 통합테스트도 해야 한다.

 

하지만 통합테스트에서 가용성을 만족하지 못했을 때 어떻게 해야 할까? 부분 최적화라는 피말리는 작업을 해야 한다. 밤을 새고 휴일을 반납한 채 부분최적화를 해도, 아키텍처의 구조적인 문제 때문에 해결이 안된다면? 그렇기 때문에 비기능 요구사항을 만족할 수 있을지 아키텍처를 설계하면서 관련자들이 상세하게 살피고 검토해야 한다.

 

아키텍처와 아키텍트가 중요하다고 말한다. 그런데 왜 중요하죠?라고 물으면 제대로 답을 하는 사람이 그다지 많지 않다. 소프트웨어를 만드는 조직이라고 한다면, 그 규모의 크기와 관계 없이 어떤 시스템을 만들든 반드시 아키텍처를 설계하고 검증해야 한다. 이 작업을 제대로 하지 않고 생기는 문제를 처리하기 위해 삽질을 하는 것은, 그 누구의 잘못도 아니다. 바쁘니 아키텍처 같은 건 고민하지 말고 일하라고 지시한 경영층의 과실과 이에 동조한 엔지니어의 작품이다. 그래서 새해엔 우리 모두 아키텍처에 조금 더 관심을 갖는 시간이 되었으면 좋겠다.

 

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

대한민국 소프트웨어, 리스타트

Yes24 교보문고 알라딘 리브로 인터파크

반복되는 일상이 행복하지 않다면!