깨진 유리창을 그대로 두지 마세요

2023년 5월 17일 작성

이 글은 https://www.artima.com/articles/dont-live-with-broken-windows 를 변역기를 활용해 제 맘대로 번역한 글입니다.

요약

실용주의 프로그래머인 앤디 헌트와 데이브 토바스는 빌베너스와 함께 소프트웨어 장인정신에 대해 이야기하며, 우리의 코드에서 "깨진 창문"과 같은 작은 문제가 큰 문제로 자라나지 않도록 고치는 행위의 중요성을 말했다.

장인정신과 대성당

빌 베너스: 저서 '실용주의 프로그래머'의 서문에서 채석장 노동자의 신조를 인용하셨는데요:

단순한 돌을 자르는 우리는 항상 성당을 구상하고 있어야 한다. 그런 다음 "프로젝트의 전체 구조 안에는 항상 개성과 장인 정신을 발휘할 수 있는 여지가 있다"

고 말합니다. 무슨 뜻인가요?

데이브 토마스: 매우 구조화된 환경에서는 사람들이 책임을 회피하는 경향이 있습니다. 사람들은 "이건 제가 할 일이 아니에요. 상사가 제가 할 일을 따로 정해줬어요. 아주 큰, 최종 목표가 저에게 주어졌지만, 저는 이 모듈, 이 모듈, 이 모듈만 하면 됩니다."라고 말합니다.

이 비유는 매우 큰 전체에서 아주 작은 부분인 석공에 비유할 수 있습니다. 실제로 대성당을 짓는 석공들은 정말 수준 높은 장인들이었습니다. 그들은 자신이 하는 일이 성당의 얼굴이 될 것이라는 사실을 항상 의식하고 있었습니다. 우리가 말하고자 하는 것은, 여러분이 일을 제대로 할 권한이나 책임이 없다고 생각하더라도 현실은 여러분에게 있다는 것입니다. 여러분이 하고 있는 일의 질이 중요합니다. 이는 프로젝트의 전반적인 영향력이나 효과에 기여합니다.

앤디 헌트: 또 다른 측면은 개인의 예술성을 허용하거나 장려한다는 점입니다. 마음대로 할 수는 없죠. 성당을 짓는다고 가정해 보죠. 성당의 전체적인 주제와 일관된 톤에 맞게 석상을 조각해야 합니다. 백조 같은 것을 조각할 수는 없습니다. 하지만 전체적인 디자인 제약 속에서도 전체와 관련하여 최고의 작품을 만들 수 있는 개별적인 예술적 자유는 여전히 존재합니다.

빌 베너스: 그게 왜 중요한가요?

데이브 토마스: 두 가지 이유입니다. 첫째, 프로그래밍은 매우 어렵습니다. 프로그래밍을 잘하려면 엄청난 노력이 필요합니다. 스스로에게 동기를 부여하고 계속 헌신하려면 자신이 하고 있는 일에 자부심을 가져야 합니다. 만약 자신이 스펙을 받아 바이트만 찍어내는 기계 조립 라인 노동자라고 생각한다면, 자신이 하는 일에 흥미를 느끼지 못해 일을 잘 해낼 수 없을 것입니다. 따라서 조직적인 관점에서 개인의 예술성을 장려하는 것은 매우 중요합니다. 개인적인 관점에서는 이렇습니다. 왜 우리가 좋아하지도 않는 일을 해야하나요? 일에 많은 것을 투자하고 싶다면 그 일을 즐기는 것이 중요하겠지요.

앤디 헌트: 예술적 자유라는 개념은 품질 향상을 촉진하기 때문에 중요합니다. 예를 들어 건물 구석에 석상을 조각한다고 가정해 봅시다. 요구된 사양에는 아무 말도 없거나, 다른 석상들과 똑같이 직선형 석상을 만들어달라고 나와 있는 상황입니다. 하지만 현장에 있는 우리는 요구사항보다 더 나은 솔루션을 찾을 수 있습니다.

"아, 이쪽으로 가고일의 입을 구부리면 비가 이쪽으로 내려와 저쪽으로 갈 수 있겠구나. 그게 더 낫겠네."

조각가인 우리는, 디자이너가 예측하지 못했거나 전혀 알지 못했던 조건들을 현장에서 더 잘 대응할 수 있습니다. 우리는 이렇게 상황마다 적절하게 대처하여 전체적으로 더 좋은 결과물을 만들 수 있습니다.

깨진 유리창 이론

빌 베너스: 깨진 유리창 이론이란 무엇인가요?

앤디 헌트: (먼저, 이론이 탄생한 배경을 설명하자면) 도시 쇠퇴를 연구하는 연구원들은 왜 어떤 동네는 도심의 폐허에서 벗어나고, 바로 옆 동네는 인구 통계와 경제 구성이 같은데도 경찰이 들어가기 무서워하는 지옥 같은 곳이 되는지 알아보고 싶었습니다. 그들은 무엇으로부터 차이가 생기는지 궁금해했어요.

먼저, 재규어와 같은 멋진 차를 타고 뉴욕의 사우스 브롱크스에 주차했습니다. 그리고는 오리 블라인드로 후퇴하여 어떤 일이 일어나는지 지켜보았습니다. 그들은 차를 4일 정도 주차해 두었지만 아무 일도 일어나지 않았습니다. 차에 손도 대지 않았죠.

이번엔, 앞에 있는 건물에 올라가서 작은 창문을 깨고 다시 블라인드로 돌아갔어요. 그러자 약 4시간 만에 차가 뒤집히고, 불이 붙고, 모든 부품이 벗겨졌어요.

그들은 더 많은 연구를 통해 "깨진 유리창 이론"을 발전시켰습니다. 아파트 건물에 창문이 깨졌지만 아무도 고치지 않았습니다. 창문이 깨진 채로 방치되면, 또 다른 무언가가 깨집니다. 사고일 수도 있고 아닐 수도 있지만 그것도 고쳐지지 않습니다. 낙서가 나타나기 시작합니다. 점점 더 많은 손상이 누적됩니다. 아주 빠르게 기하급수적으로 늘어납니다. 건물 전체가 붕괴됩니다. 세입자가 이사합니다. 범죄가 들어옵니다. 그리고 당신은 게임에서 졌습니다. 모든 게 끝났죠.

우리는 프로젝트의 기술 부채(technical debt)를 관리할 때 깨진 유리창 이론을 비유로 사용합니다.

빌 베너스: 기술 부채란 무엇인가요?

앤디 헌트: 워드 위키에서 나온 용어입니다. 수정을 미룰 때마다 부채가 발생합니다. 무언가 고장난 것을 알지만 지금 당장 고칠 시간이 없는 경우가 있습니다. 장부에 기록이 되고, 빚을 지게 됩니다. 실제 부채처럼, 관리만 잘하면 괜찮을 수도 있습니다. 부채가 몇 개 있거나 많더라도, 잘 관리하고 있다면 괜찮습니다. 이 문제들을 기간 내에 해결하면 됩니다. 그런 다음, 돌아가서 몇 가지만 수정하면 될거예요.

하지만 실제 빚과 마찬가지로, 갚을 수 없는 지경에 이르는 데는 그리 오랜 시간이 걸리지 않으며, 문제가 너무 많아서 다시 돌아가서 해결할 수 없게 됩니다.

데이브 토마스: 이를 비유하자면 제 이메일 받은 편지함을 들 수 있습니다. 저는 가끔씩 한동안 이메일에 답장을 하지 않는 습관이 있기 때문입니다. 그러다가 메시지가 250개쯤 되면 갑자기 '이 메시지에는 절대 답장하지 않겠다'는 생각이 들죠. 소프트웨어의 보류 중인 변경 사항도 마찬가지입니다.

빌 베너스: 기술 부채는 깨진 유리창 이론과 어떤 관련이 있나요?

앤디 헌트: 기술 부채를 방치해서는 안 됩니다. 작은 문제가 큰 문제로 커지기 전에 막아야 합니다. 길리아니 시장은 뉴욕시에서 이 접근법을 매우 성공적으로 사용했습니다. 무단횡단, 낙서, 팬 취급과 같은 삶의 질을 떨어뜨리는 사소한 범죄에 대해 매우 엄격하게 대처함으로써 4~5년 동안 살인, 강도, 절도 등 주요 범죄율을 절반가량 줄였습니다.

심리학의 영역에서 이 방법은 실제로 효과가 있습니다. 작은 문제를 해결하기 위해 노력을 들인다면, 그 문제는 더 큰 문제로 번지지 않습니다. 부수적인 피해를 만들지 않는 것이죠. 잘못된 코드는 그 자체의 기능과 무관하게 엄청난 양의 부수적인 피해를 유발할 수 있습니다. 이를 제대로 파악하지 못하면 시스템의 다른 요소에 피해를 주기 시작합니다. 따라서 프로젝트에서 깨진 창문을 허용하면 안된다는 것이지요.

코드의 버그, 프로세스의 문제, 잘못된 요구 사항, 잘못된 문서 등 무언가 잘못되었다는 것을 알게 되면 바로 그 자리에서 멈추고 문제를 해결해야 합니다. 그냥 고치세요. 도저히 고칠 수 없다면 그 주위에 경찰 테이프를 붙이세요. 그 위에 합판을 못으로 박으세요. 모든 사람들이 그것이 고장 났고, 그것을 신뢰해서는 안되며, 가까이 가지 말아야한다는 것을 알도록하십시오. 실제로 문제를 해결하는 것만큼이나 상황을 잘 파악하고 있다는 것을 보여주는 것도 중요합니다. 무언가가 고장 났는데도 고쳐지지 않으면 팀 전체에 불쾌감이 퍼지기 시작합니다. "저거 고장났네. 내가 방금 망가뜨렸어. 아, 그렇구나."

내가 잘 하면, 다른 사람들도 잘 할 것이다.

데이브 토마스: 관심을 갖고 있다는 것을 보여주는 것이 중요합니다. 예를 들어 팀원들에게 공유되어있지만, 대부분 제가 작업하는 모듈의 코드가 있다고 합시다. 분명히 잘못된 코드가 있는데도, 저는 고치지 않고 그냥 남겨두는 사람이라고 가정해봅시다. 그 모듈에 들어오는 다른 사람은 "글쎄요, 데이브도 신경 쓰지 않는 모듈이잖아요. 제가 왜 신경 써야 하죠?" 이런 종류의 부패는 아파트 건물뿐만 아니라 모듈에도 발생합니다.

반면, 제가 코드에서 작동하지 않는 엣지 컨디션을 발견했다고 가정해 봅시다. 버그인 것은 알지만 현재 애플리케이션에 중요한 버그가 아니어서 수정할 시간이 없습니다. 최소한 주석이라도 달 수는 있겠죠. 또는 더 좋은 방법은 assertion을 넣어서 에지 조건이 발생하면 제가 그 위에 있다는 것을 보여줄 수 있는 무언가가 일어나도록 하는 것입니다. 이렇게 하면 우선 문제를 더 쉽게 파악할 수 있습니다. 또한 다른 사람들에게도 문제가 발생했을 때 그 문제를 해결할 수 있을 만큼 제가 관심을 갖고 있다는 것을 보여줄 수 있습니다.

앤디 헌트: 버그가 난무하고 빌드가 제대로 작동하지 않는 등 엉망인 프로젝트에 들어가면 최선을 다할 동기가 생기지 않을 것입니다. 하지만 모든 것이 깔끔한 프로젝트에 들어가면 가장 먼저 버그를 발견하고 싶을까요?

빌 베너스: 책에서 태피스트리 화재에 대한 이야기가 나옵니다.

앤디 헌트: 실화입니다. 코네티컷에 있는 제 전직 회계사는 매우 고급스럽고 부유한 지역에 살았습니다. 그 사람은 초호화 저택에 살았죠. 벽난로와 너무 가까운 벽에 태피스트리를 걸어두었는데 어느 날 불이 났어요. 소방서가 출동했습니다. 불은 활활 타오르고 있었어요. 집이 불길에 휩싸이기 직전이었죠. 하지만 소방서는 그냥 현관문으로 들이닥치지 않았습니다. 그들은 현관문을 열고 작은 카펫을 깔았습니다. 그런 다음 그들은 카펫 위에 더러운 호스를 가져와 불을 껐습니다. 그들은 카펫을 다시 걷어 올리며 정말 고맙다고 말했습니다.

불길이 거세게 치솟는 와중에도 소방서는 카펫을 내려놓고 호스를 계속 사용하도록 주의를 기울였습니다. 그들은 이 남자의 값비싼 저택을 망치지 않도록 각별히 주의를 기울였습니다. 위기 상황이었지만 그들은 당황하지 않았습니다. 그들은 문제를 처리하는 동안 어느 정도의 청결과 질서를 유지했습니다. 위기는 항상 발생하기 때문에 프로젝트에서 이러한 태도를 길러야 합니다. 물건에 불이 붙고 타기 시작합니다. 문제를 해결하려고 정신없이 뛰어다니다가 더 큰 피해를 입히고 싶지는 않을 것입니다. 카펫을 깔아주세요.

제대로 하세요.