요근래 EBS의 다큐프라임이라는 내용을 보고, 다시 한번 프로그래밍이라는 작업에 대해서 생각하게 되었다. 특히, '사소한 것의 기적' 이라는 내용은 프로그래밍에 대한 패러다임을 다시 한번 생각하게 된다. TV 프로그램의 내용은 하찮고 사소한 것을 행동으로 옮겼을 때 그 여파는 상당하다는 것이다. TV에서는 이를 실생활에서 직접 실험을 통해 보여주고 있었는데, 어느 동네에 쓰레기 더미로 몸살을 앓고 있는 장소가 있었다. 물론, 골목 한귀퉁이에 전봇대가 놓여져있고, 밤만 되면 쓰레기가 쌓이고, 그 장소는 감시 CCTV이외에도 각종 경고문들이 붙어 있었다. 처음 실험은 이 장소에 아무것도 없는 상태에서 쓰레기 한 비닐을 그냥 놓아둔 것이다. 시간이 흐름에 따라 여러 사람들이 이 장소에 쓰레기를 버리기 시작했고, 다음 날 아침에서는 쓰레기 더미가 쌓여져 있었다. 물론, 이러한 과정을 몰래카메라를 설치하여 지켜보았지만, 지켜보는 나로써도 과연 저런 상황이 발생할 수 있을까 싶을 정도로 사람들이 쓰레기를 버리고 있었다. 그 다음날 제작진은 이 쓰레기 더미를 모두 치우고, 이 장소를 말끔히 치운 다음, 화단을 만들어서 꽃을 심어놓았다. 물론, 쓰레기를 버리지 마라는 경고문도 같이 떼어냈다. 그리고, 그날 저녁 몰래카메라를 통해 지켜본 결과는 쓰레기가 전혀 쌓이지 않았다는 것이다. 밤에 어떤 사람이 쓰레기를 무심코 버리려고 한 비닐 가득 가지고 왔지만, 쓰레기를 화단 옆에 놓고서는 잠시 머뭇거리더니 다시 쓰레기를 가져갔다.
이러한 현상은 '깨진 유리창 이론' 으로 잘 알려져 있지만, 이론을 실험을 통해 실생활에서 직접 보니 느낌이 더 새로왔다.
요즘 예전에 했던 프로젝트에 다시 들어와서 운영 중인 시스템에 대한 리모델링을 작업 중이다. 처음 이 프로젝트에 들어와서는 나름대로 코드, 컴포넌트, 시스템 관리에 중점을 두어서 신경을 쓰며 작업했던 생각이 난다. 그 시간 동안에는 원칙과 원론들이 같이 적용되어서 최적의 시스템을 만들려고 애를 쓰며 고생했었다. 하지만, 시스템을 오픈하고 어느 정도 지난 시점에 다시 들어와보니 코드의 질 뿐만 아니라, 컴포넌트/시스템의 질이 처음 작업하던 것보다도 더 안좋아졌다는 느낌이 들었다. 단적인 예로, 개발 시점에는 늘 소스에 대한 컴파일과 컴포넌트에 대한 의존관계를 염두해두면서 작업했었는데, 지금의 소스는 이런 차원에서 너무나도 벗어났고, 심지어 컴파일이 되지 않은 소스가 배포버전에 있는 것이 아닌가. 심각한 관리 부재를 느낄 수 있는 부분이며, 개발시점에 그렇게 코드에 대한 리뷰로부터 시작해서 설계 인스펙션까지 진행함에도 불구하고, 시스템이 이렇게 한순간에 망가질 수 있을까 하는 생각이 들었다. 하지만, '사소한 것의 기적' 이라는 TV 프로그램을 보고서야 그 이유를 알 수 있었다. 우선 컴파일이 되는 소스코드에 대한 관리는 가장 기본적인 일일 것이다. 그렇지만, 이 코드가 테스트에서 발생한다고 보면 아마 사소한 것쯤으로 인식이 될 것이다. 또한, 다른 사람들은 자신이 건드리는 소스 이외의 다른 사람들의 소스를 건드릴 필요가 없다고 생각해서 이러한 에러쯤은 그냥 무시하고 작업했을 것이다. 정말 사소한 것이다. 이쯤 되면 사람들은 전체 프로그램에 대한 배포를 하지 못할 것이고, 자신의 소스나 컴포넌트만을 배포할 것이다. 그렇다 보니, 서로 연관관계에 있는 컴포넌트에 문제가 발생될 가능성이 있고, 이러한 문제는 해당 컴포넌트가 실행되기 전까지 아무도 알아차리지 못했을 것이다. 결국, 어떻게 소스가 컴파일되고 컴포넌트 배포까지는 되었다고 하더라도, 해당 기능이 수행되기 전까지는 아무도 어떤 부분이 잘못되었는지를 알아채지 못한다.
또한, 컴포넌트간의 의존관계는 개발시점의 원칙이 운영시점에서는 하나 둘씩 깨지기 시작했을 것이다. 그렇다보니, 다른 개발자들도 잘못된 의존관계를 보면서 새로운 코드나 기존 코드를 작성하거나 수정했을 것이며, 전체적인 컴포넌트에 대한 의존관계는 걷잡을 수 없을 만큼 복잡하게 되었다.
만일, 누구 한사람 만이라도 소스나 컴포넌트에 대한 건정성(건강성) 측면에서 이를 수정했더라면, (사실 이러한 노력이 그리 어렵다거나 복잡하고, 시간이 많이 걸리는 작업이 아니다.) 지금의 운영 시스템은 나름 다루기 더 수월한 형태로 유지되고 있었을 것이다.
정말 사소한 것으로부터의 변화는 이러한 변화의 양끝단에 서있는 사람에게는 극과극이다. 변화는 돈을 많이 들이거나 시간을 많이 들여서 바꿀 수 있는 것도 있겠지만, 대부분의 변화는 사소한 것에서 출발하여 바꿀 수 있는 것들이 더 많을 것이다. 어쩜 프로그래밍도 그러한 차원에서 하찮은 것 하나하나 시시하게 그냥 넘어가지 않는 자세가 필요한 것일지도 모른다.
이러한 현상은 '깨진 유리창 이론' 으로 잘 알려져 있지만, 이론을 실험을 통해 실생활에서 직접 보니 느낌이 더 새로왔다.
요즘 예전에 했던 프로젝트에 다시 들어와서 운영 중인 시스템에 대한 리모델링을 작업 중이다. 처음 이 프로젝트에 들어와서는 나름대로 코드, 컴포넌트, 시스템 관리에 중점을 두어서 신경을 쓰며 작업했던 생각이 난다. 그 시간 동안에는 원칙과 원론들이 같이 적용되어서 최적의 시스템을 만들려고 애를 쓰며 고생했었다. 하지만, 시스템을 오픈하고 어느 정도 지난 시점에 다시 들어와보니 코드의 질 뿐만 아니라, 컴포넌트/시스템의 질이 처음 작업하던 것보다도 더 안좋아졌다는 느낌이 들었다. 단적인 예로, 개발 시점에는 늘 소스에 대한 컴파일과 컴포넌트에 대한 의존관계를 염두해두면서 작업했었는데, 지금의 소스는 이런 차원에서 너무나도 벗어났고, 심지어 컴파일이 되지 않은 소스가 배포버전에 있는 것이 아닌가. 심각한 관리 부재를 느낄 수 있는 부분이며, 개발시점에 그렇게 코드에 대한 리뷰로부터 시작해서 설계 인스펙션까지 진행함에도 불구하고, 시스템이 이렇게 한순간에 망가질 수 있을까 하는 생각이 들었다. 하지만, '사소한 것의 기적' 이라는 TV 프로그램을 보고서야 그 이유를 알 수 있었다. 우선 컴파일이 되는 소스코드에 대한 관리는 가장 기본적인 일일 것이다. 그렇지만, 이 코드가 테스트에서 발생한다고 보면 아마 사소한 것쯤으로 인식이 될 것이다. 또한, 다른 사람들은 자신이 건드리는 소스 이외의 다른 사람들의 소스를 건드릴 필요가 없다고 생각해서 이러한 에러쯤은 그냥 무시하고 작업했을 것이다. 정말 사소한 것이다. 이쯤 되면 사람들은 전체 프로그램에 대한 배포를 하지 못할 것이고, 자신의 소스나 컴포넌트만을 배포할 것이다. 그렇다 보니, 서로 연관관계에 있는 컴포넌트에 문제가 발생될 가능성이 있고, 이러한 문제는 해당 컴포넌트가 실행되기 전까지 아무도 알아차리지 못했을 것이다. 결국, 어떻게 소스가 컴파일되고 컴포넌트 배포까지는 되었다고 하더라도, 해당 기능이 수행되기 전까지는 아무도 어떤 부분이 잘못되었는지를 알아채지 못한다.
또한, 컴포넌트간의 의존관계는 개발시점의 원칙이 운영시점에서는 하나 둘씩 깨지기 시작했을 것이다. 그렇다보니, 다른 개발자들도 잘못된 의존관계를 보면서 새로운 코드나 기존 코드를 작성하거나 수정했을 것이며, 전체적인 컴포넌트에 대한 의존관계는 걷잡을 수 없을 만큼 복잡하게 되었다.
만일, 누구 한사람 만이라도 소스나 컴포넌트에 대한 건정성(건강성) 측면에서 이를 수정했더라면, (사실 이러한 노력이 그리 어렵다거나 복잡하고, 시간이 많이 걸리는 작업이 아니다.) 지금의 운영 시스템은 나름 다루기 더 수월한 형태로 유지되고 있었을 것이다.
정말 사소한 것으로부터의 변화는 이러한 변화의 양끝단에 서있는 사람에게는 극과극이다. 변화는 돈을 많이 들이거나 시간을 많이 들여서 바꿀 수 있는 것도 있겠지만, 대부분의 변화는 사소한 것에서 출발하여 바꿀 수 있는 것들이 더 많을 것이다. 어쩜 프로그래밍도 그러한 차원에서 하찮은 것 하나하나 시시하게 그냥 넘어가지 않는 자세가 필요한 것일지도 모른다.
반응형
'Homo Ware' 카테고리의 다른 글
편향과 지향 (0) | 2008.12.09 |
---|---|
Meritocracy (0) | 2008.09.19 |
뭘 많이 매겨 (3) | 2008.03.11 |
사람이 더 중요한 소프트웨어 (0) | 2008.03.10 |
열역학 법칙 (0) | 2008.03.03 |