건축 비유
<업데이트 중>

사람들은 종종 "설계"의 중요성을 설파할 때 건축이라는 분야를 들먹거립니다. 건축이란 맥락의 여러 개념들을 고스란히 가져와서 타 분야에 그대로 오버랩시킵니다. "우리도 건축처럼 일단 완벽한 설계도를 만들고 나서..."
 
하지만 저는 이러한 "건축의 비유"가 쓸모없는 경우가 많으며, 이 비유에 기반한 주장들은 대부분 잘못되었다고 생각합니다.

건축의 비유에 두 가지 문제점이 있습니다(우선 소프트웨어에 대해서만 생각해 보겠습니다). 첫 째, 소프트웨어는 건물과 너무도 다른 점이 많기 때문에 그 비유가 유용하다기보다 가상의 제약을 주는 경우가 많다는 점입니다. 두 째, 실질적 건축보다도 훨씬 더 과장되고 왜곡된 건축의 이미지를 갖고 비유한다는 점입니다.

우선은 두 번 째 문제에 대해서 이야기를 해봅시다. 제가 이야기하는 것보다 건축가의 입을 빌리는 것이 좋을 것 같습니다. 다음은 한국 현대 건축에 가장 큰 족적을 남긴 건축가 중 하나로 평가받는 김수근 선생의 글입니다.

큰 건물뿐 아니라 조그만 주택 하나 짓는 경우라도 설계할 시점과 착공할 때, 준공할 무렵에는 그 내용과 양상이 매우 달라지는 것은 많은 사람이 경험하는 것이다.

설계대로 지은 집은 별로 좋은 집이 될 가능성이 없다. 좋은 집을 지으려면 많은 설계변경이 이루어진 것이어야 한다.

설계대로 지은 집이란 설계시점보다 조금도 발전시키지 않고서 지었다는 것을 말한다. 공사과정을 보면 계획이나 설계하는 시점으로부터 시간이 많이 흐른다. 현대의 급속한 기술발전과 여러 가지 새로운 재료의 발달은 눈이 부실 정도로 그 속도가 빨라서 설계시점에서 가능한 기술과 재료가 완공 무렵에는 구형의 쓸모없는 것으로 전락하는 경우가 허다하다. 이러한 신정보를 항상 입수하면서 설계 그 자체를 발전시켜야 한다.

건축설계하는 사람이 신이 아닌 이상 완벽한 설계를 해놓는다는 것은 불가능하다. 그러므로 설계도는 완전한 것이 없다. 설계도면에 있어서 완전한 것을 기대하는 것은 어리석은 짓이다. 도면에 표현된 내용은 어디까지나 발전의 여지와 보완의 기대를 내포하는 것이다. 그렇기 때문에 설계변경이 요구된다. 공사 도중에 설계변경이 많으면 많을수록 집은 좋아질 수 있다고 말할 수 있다.

개인주택이나 빌딩인 경우에는 그 설계변경이 비교적 쉽게 이루어진다. 그러나 관의 건물인 경우에는 쉽지 않다. 설계변경이란 관에서는 터부이다. 감사를 할 때도 설계변경은 집중의혹의 목표가 된다. 물론 이것은 공사금액과 관련되기 때문에 부정의 여지를 가졌다는 이유에서다. 그러나 설계대로 짓고 있다고 하는 관의 건물이라 해도 실제론 설계대로 되어 가는 집은 전무하다.

같은 비용 갖고 더 좋은 집을 짓도록 설계변경하는 길을 막고 있다. 그러므로 관의 건물이 좋은 건축이 되기 어려운 것이다. 지금 짓는 관의 건축비는 일률적으로 규제되어 있다. 관의 건물일지라도 여러 종류의 다른 기능과 내용을 요구하고 있다. 후손에 물려줄 좋은 유산을 만들려면 설계변경, 즉 설계발전을 설계 시작에서부터 완공 때까지 허용하고 오히려 장려하지 않으면 안 될 것으로 믿는다.

--김수근, 知的 설계변경, 동아일보, 1984년 3월 19일 (강조는 김창준)


저는 종종 이런 이야기를 했습니다.

계획과 설계는 다음의 경우 바뀌어야 한다:

  • 세상이 바뀌거나
  • 내가 더 똑똑해지거나

설계가 완성되는 시점은 그 구현체가 완성되는 시점이다.

(계속)...

by 애자일컨설팅 | 2007/06/01 01:10 | 트랙백(1) | 덧글(13)
트랙백 주소 : http://agile.egloos.com/tb/3462830
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 떵꺼리 &amp; 수샤 at 2007/06/01 10:01

제목 : 소프트웨어 설계와 건축
제가 즐겨가는 블로그인 애자일이야기에서 건축에 대한 얘기가 있어 저도 몇 자 적어봅니다.개발을 하면서 설계에 대한 중요성은 아무리 강조해도 지나치지 않습니다. "이 서비스는 이러이러하니 이런 방법과 뼈대로 제작해가면 완성되겠구나."이렇게 보면 건축의 그것(설계)와 흡사해 보입니다.그래서 최대한 많은 고민과 아이디어를 짜내어 제작하기 전에 설계도/설계서에 쏟아냅니다.문제는 여기서 부터 시작되고 있습니다.초기에 많은 것을 넣다보니......more

Commented by 태현 at 2007/06/01 02:08
어떤 분야든 변화에 유연해야 할 것 같아요. 인생 설계도 마찬가지겠죠? =)
Commented by Steve at 2007/06/01 06:07
code complete를 읽어보았소?
Commented by 푸른바다 at 2007/06/01 06:32
설계변경이 많은 수록 좋은 집이 지어질지 몰라도, 건축구조설계분야에서는 기존 설계를 유지하는게 안전하게 집을 짓는 거라고 생각됩니다.
설계변경이 잦은 건물은 구조설계도 다시 해야되는데, 변경할 때마다 하중및 용도, 조건이 변경되기 때문에 구조에 문제가 있을 수 있습니다.
건축이라는 것은 아름다우면 좋겠지만, 사람들이 생활하는 곳이니, 안전하고 경제적으로 짓는 것도 무시못하거든요. 건축가라는 사람들은 자신
들의 미의식, 작가의식에 의거 후세에 남을 아름다운 건물을 짓겠다고 설계변경을 자주하는데 그런 설계변경을 받쳐주는 분야가 건축구조설계분야인데
대부분의 사람들은 그것을 잘 모르죠. 겉으로 보여지는 것을 중요시되는 것 같아요. 그냥 제생각입니다.^^

글의 내용이 변화가 필요하다는 내용인데 다른 내용의 덧글이 달아서 좀 그렇네요.. 글 내용은 좋습니다.
Commented by at 2007/06/01 09:32
건축의 경우 설계변경이 되면 단가도 올라가고 시공기간도 변경이 있지만
소프트웨어는 설계변경을 해도 단가는 그대로, 납기일도 그대로이기 때문에 프로그래머들이 잦은 설계변경을 반기지 않겠죠
Commented by Jerry at 2007/06/01 09:37
맞는 말씀이시긴 합니다만, 기본이 갖춰졌을때의 얘기가 아닐까요?
모순 투성이에, 필요한 내용은 빠져있는 요구사항과 설계도를 가지고 작업하는 사람들에게는 설계의 중요성을 아무리 강조해도 지나침이 없을 것입니다.
Commented by 배고픈 바보 at 2007/06/01 09:45
푸른바다님이 말씀하신 건축구조설계와 비슷한 부분이 소프트웨어에서는 데이터모델링이 아닐까요? 초기에 충분한 자원을 투입해 그 기초를 확실히 잡아놓아야 할 것입니다. 그 이후에 있을 수많은 변화에도 유연하게 대응할 수 있도록. 하지만 역시 '겉으로 보여지는것'이 아니기 때문에 상대적으로 그 중요성은 낮게 여겨지는 것 같습니다.
Commented by DalKy at 2007/06/01 09:52
아직 완료되지 않은 글임에도 불구하고 굉장히 공감이 가는 글이긴 합니다만, 이 글을 잘못 적용할 경우에는 쓸데없이 기획을 마구잡이로 변경해버리는 사람들의 변명거리가 될 수 있을 것 같다는 생각도 강하게 드는 것 같습니다. 어쨌든, 김창준님께서는 소프트웨어 개발을 건축 개발에 비유한다는 것 자체가 잘못되었다고 주장하고 계신 만큼, 건축 개발에 있어서도 "건축설계는 계속 변경되고 발전되어간다" 라는 말씀을 굳이 하실 필요는 없을 것 같습니다.^^
Commented by 지나가는이 at 2007/06/01 11:04
건축은 엄밀히 따지면 건축학/건축공학으로 나눌 수 있습니다. 우리나라는 하나로 묶어서 배우다 요즘은 슬슬 나누어지는 모양새이지만.
서구에서는 디자인.인문적 분야는 건축학, 어떻게 구조역학적으로 잘 버틸것인가는 구조공학이라고 하는 분야로 토목공학쪽에 포함되어있습니다.
님께서 인용한 글은 건축학적 입장이 주가된 내용인것으로 보입니다. 프로세스 전과정을 언급한다면 그 커버리지가 부족하죠
소위 IT계에서 이슈화 되고 있는 Project manage라는게 건축.토목의 공정관리에서 처음 나온것이지요 PMP라는 자격증도 요즘은 분야를 넘어서
적용되고 있고요. 개인적인 견해로 소프트웨어 개발의 프로세스를 건축에 비유한다는 말보다 공정관리에 비유한다는 말이 더 적절할것 같습니다.
공정관리는 설계,구조공학,기초공학,공사,관리,재무등등을 다 종합적으로 아우르는 말이니깐요.
Commented by 페르소나 at 2007/06/01 12:52
뜬금없는 소리지만, (포인트도 한참 어긋남) 설계를 할때, 가장 먼저 부지조사 하고, 그 다음 그 부지, 지역, 용도 등등등등에 따라, 컨셉을 잡죠. 컨셉이 하나의 추상적인 주제이기 하지만, 이것은 변하지 않는 하나의 구심점이 되어요. 그다음에 따르는 건물의 배치는 몇번이고 다시 엎습니다. 일단 모든 도면을 시공쪽으로 넘겨도 실제 짓는 것과 책상머리작업과의 차이로 인해 수정이 이루어지는 것은 허다하구요.
컨셉은 변하지 않는 편이 좋습니다. 그러나 그 이후는 의도하지 않던 의도하던간에 수많은 수정은 불가피 합니다. (뜬금없이~;;;;)
Commented by 시즈하 at 2007/06/01 19:50
이것은 어쩌면 개발도중에 요구사항이 자주 변경되서는 안된다는 원리와 충동이 날 수도 있겠는데, 하지만 설계의 변경과 요구사항이 변경되는 것은 구별되어야 할 것 같습니다.

여기서 말하고자 하는 것은, XP에서 말하는 잦은 리펙토링 주기를 갖는 것과 비슷해 보입니다. 설계를 기초부터 뒤업는 다는 것이 아니라, 보다 좋은 디자인으로 발전시켜 나가는 개념으로 봐야하지 않을까 싶네요. 처음부터 완벽한 설계를 할 수 없다면, 차라리 개발을 하면서 수시로 고쳐나가자는 취지로 보입니다.
Commented by kspil at 2007/06/02 12:15
오랜만에 재밌는글 읽었습니다. 감사합니다.
Commented by 영록 at 2007/06/02 16:41
내용에 전적으로 공감하면서도 또한 공감하지 않는 답글을 다신 분들의 마음을 알 것 같군요.

문득 저에게 XP를 가르쳐 준 친구가 해준 말이 생각납니다. "요구사항은 항상 변한다."
Commented by 정신병자 at 2007/06/03 19:18
전반적인 내용에는 공감합니다만, 전제조건이 필요하다고 생각되네요. 개발의 3주체라고 볼 수 있는 기획자, 프로그래머, 디자이너가 모두 프로젝트의 처음부터 끝까지 함께 얘기하고 함께 움직일 수 있는 프로세스 상에서만 성립할 수 있는 얘기 아닐까요?

'계속'이라고 쓰신 부분에서 아마 이 부분을 말씀하시지 않을까, 하고 생각합니다만, 쓸데없는 참견 한마디 불쑥...^^^;

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >