프레드 브룩스의 고전 ‘No Silver Bullet’를 통해 소프트웨어 개발의 본질적 난제와 우연적(부수적) 난제를 구분하고, 생산성을 비약적으로 끌어올릴 은탄환은 없다는 점을 짚는다. 대신 구매 vs. 자체 개발, 요구사항 정제와 빠른 프로토타이핑, 점진적 성장, 그리고 뛰어난 설계자의 중요성 등 실질적 개선 방향을 제시한다.
읽는 데 8분
2020년 9월 10일
전체 크기로 보려면 Enter 키를 누르거나 이미지를 클릭하세요
소프트웨어 공학의 본질과 우연: 은탄환은 없다( No Silver Bullet: Essence and Accident in Software Engineering ), 프레드 브룩스의 논문은 1986년에 처음 발표된 기념비적 저작이다. 이 블로그의 ‘고전으로 읽는 컴퓨터 과학’ 시리즈의 첫 글로 이 논문을 고른 이유가 몇 가지 있다. 첫째, 이 블로그의 존재 이유, 즉 “어떻게 하면 더 나아질 수 있을까?”라는 질문에 곧장 답을 건네기 때문이다. 또 하나의 이유는, 30년도 훨씬 전에 나온 글임에도 지금도 여전히 씨름하고 있는 소프트웨어 개발의 난제들을 다루고 있기 때문이다.
_은탄환은 없다_에서 브룩스는 소프트웨어 프로젝트를 늑대인간에 비유한다. 평소에는 멀쩡한 사람처럼 보이지만, 때때로 목을 물어뜯는 괴물로 변하는 존재. 이 괴물을 죽일 수 있는 유일한 방법은 은탄환으로 쏘는 것이다.
“그렇다면,” 그는 묻는다. “우리의 통제에서 벗어나고, 터무니없이 비싸며, 늘 늦어지는 이 괴물 같은 소프트웨어 프로젝트를 무찔러 줄 은탄환은 어디에 있나?” 글쎄, 답은 우리도 짐작한다. 기사 제목이 바로 “은탄환은 없다”가 아닌가. 이 뉴스의 리드를 숨기지는 않았다.
은탄환은 없다.
슬픈 소식이다. 우리는 믿고 싶지 않다. 브룩스의 법칙(“늦은 프로젝트에 인력을 추가하면 더 늦어진다”)처럼, 우리는 진실을 무시한 채 태연히 버스를 절벽으로 몰아간다. 반복해서.
브룩스는 더 나아가 말한다. 은탄환만 없는 게 아니다 — 프로그래머 생산성을 한 자릿수도 아닌 한 자릿수 이상의(즉, 10배 수준의) 향상을 약속하는 무언가도 지평선 어디에도 보이지 않는다. 제때 예산 안에, 신뢰할 수 있고 버그가 거의 없는 소프트웨어를 전달할 능력을 획기적으로 높여 줄 그 무엇도 당분간 기대하기 어렵다.
왜 이렇게 심각한가? 왜 이렇게 비관적인가? 브룩스는 그냥 비관주의자, 늘 먹구름을 이고 사는 이요르 같은 인물인가? 좋아요, ‘자칭 기술 근육남’ 여러분, OS/360 경험이 별로 좋지 않았다는 건 알겠어요. 그렇다고 그 앙금을 우리에게 푸시려는 건가요?
사실, 그가 그런 입장을 고수할 만한 설득력 있는 이유가 있다. 논문의 앞부분에서 그는 소프트웨어가 거의 모든 다른 인공물과 어떻게 다른지, 그 ‘본질’을 들여다본다.
그는 지금까지 우리가 생산성에서 가장 큰 도약을 이뤘던 돌파구들이 소프트웨어 개발의 ‘본질’을 건드린 것이 아니라 ‘우연적(부수적) 속성’을 다룬 덕분이었다고 주장한다.
본질과 우연이라니, 이게 무슨 말인가? ‘우연’이 어떻게 ‘본질적’인 것과 엮이는가? 혼란스러울 수 있다. 우리가 흔히 말하는 ‘우연’은 예기치 못하고 의도하지 않은 사건, 아마 실수나 잠깐의 방심에서 비롯된 일이다.
브룩스가 말하는 ‘우연’은 그런 뜻이 아니다. 그는 철학적 의미, 아리스토텔레스까지 거슬러 올라가는 의미로 쓴다. 아리스토텔레스에게서 ‘본질적’ 성질이란 그 사물에 내재된, 때로는 정의 자체에 해당하는 성질이다. 의자는 다리와 좌판을 가진다. 이것이 의자의 본질이다. 이것이 없으면 우리는 그 사물을 의자라 부르지 않는다. 다시 말해, 어떤 대상의 본질적 성질이란 그것을 제거하면 그 대상이 더 이상 그 자체로 남아 있지 못하는 성질이다. 의자의 다리를 떼어버리면, 남은 그 무언가가 무엇이든 더 이상 의자는 아니다.
반대로 ‘우연적(부수적)’ 성질은 제거하거나 바꾸어도 원래의 대상이 여전히 그대로 남아 있는 성질이다. 예를 들어 빨간 의자를 갈색으로 바꿔도 여전히 의자다. 색깔은 ‘우연적(부수적)’ 속성이다. 오늘날 말로는 ‘부차적’, ‘부수적’이라 하는 편이 더 적절할 것이다.
저자는 먼저 묻는다. “소프트웨어 개발은 원래 이렇게 어려운가? 정말 은탄환은 없는가?”
그의 답은 이렇다. 그렇다, 원래 어렵다. 그리고 아니다, 은탄환은 없다.
이 작가의 업데이트를 받으려면 Medium에 무료로 가입하세요.
그는 이렇게 답한다. 소프트웨어 시스템 개발에는 네 가지 ‘본질적’ 어려움이 있기 때문이다.
이 네 가지 본질적 어려움을 개관한 뒤, 브룩스는 과거 생산성에서 큰 향상을 이끌어 온 영역들을 검토한다. 그의 결론은, 그 돌파구들은 본질적 어려움이 아니라 우연적(부수적) 어려움을 다뤄 왔다는 것이다.
고급 언어는 하드웨어 아키텍처를 추상화하여, 개발자가 레지스터 같은 저수준 구성 요소를 신경 쓰지 않아도 되게 했다. 추상화 수준은 계속 높아지고 있지만, 이것이 프로그램의 복잡성을 줄이지는 않는다. 프로그램과 그 구성물을 ‘표현하는’ 어려움을 줄였을 뿐, 상태 폭증과 관리 복잡성의 문제는 그대로 남는다.
시분할 시스템은 지금은 과거의 유물이 되었지만, 당시 프로그래머에게 즉각적인 피드백을 제공했다. 예전에는 프로그램을 입력하고, 잡을 제출하고, 메인프레임이 언젠가 실행해 주기를 기다려야 했다. 이제는 에디터에서 바로 입력하고, 즉시 컴파일하고, 실행할 수 있게 됐다. 과정은 빨라졌지만, 역시 소프트웨어의 본질적 복잡성을 줄이지는 못했다.
통합 개발 환경(오늘날의 IDE)은 프로그래머에게 또 하나의 도약이었다. 개발자는 하나의 환경에서 일하며 여러 도구(에디터, 링커, 로더 등)를 이리저리 넘나들 필요가 없다. 이 또한 개발 속도를 높였지만, 본질적 복잡성을 줄이지는 못했다. 공정하게 말하자면, 현대 IDE는 강력하며 귀찮은 보일러플레이트 코드를 많이 생성해 준다. 우리는 그것이 무척 고맙다. 하지만 당면 문제의 내재적 복잡성은 생성 코드에 전혀 꿈쩍하지 않는다. 게다가 우리는 패키지 매니저, 번들러, IoC 컨테이너 같은 도구로 새로운 복잡성을 보탰다. 이것들을 설정하고 유지하는 데도 상당한 지적 노력이 든다. 정규식을 써서 문제를 풀면 “문제가 둘로 늘어난다”는 격언과 비슷하다.
지금까지 생산성의 가장 큰 성과들이 소프트웨어 본질과는 무관한 문제를 해결하면서 얻어졌음을 보인 뒤, 괴팍한 브룩스 박사는 은탄환으로 광고되던 여러 기술을 검토한다. 고급 언어의 지속적 발전, 객체지향, 인공지능, 전문가 시스템, ‘자동’ 프로그래밍, 그래픽 프로그래밍, 프로그램 검증, 프로그래밍 환경과 워크스테이션의 개선 등이다. 이들 모두 어느 정도 유용하며 무시해서는 안 되지만, 이 가운데 어느 것도 생산성을 두 배로 늘려 줄 것조차 약속하지 못한다고 그는 말한다. 저자가 제시한 여러 이유에서, 이들 항목은 소프트웨어 개발의 본질적 복잡성을 건드리지 못한다.
그렇다면 요점은 무엇인가? 아무것도 도움이 안 된다면, 도대체 어떻게 소프트웨어 개발을 개선할 수 있다는 말인가? 브룩스가 그려낸 풍경은 무척 우울하고, 거의 냉소적이기까지 하다.
저자에 따르면, 은탄환은 없더라도 희망은 있다. 적어도 늑대인간을 물리칠 ‘마늘’은 손에 쥘 수 있다(중세의 몇몇 신화에서 마늘은 뱀파이어, 늑대인간, 온갖 사악한 존재를 물리치는 도구였다). 브룩스는 생산성 향상을 약속하는 네 가지 영역을 개략적으로 제시한다. 그는 소프트웨어 개발의 어려움을 정확히 지적할 뿐 아니라, 오싹할 만큼 예지력 있게 실제로 우리에게 도움이 될 것들을 내다본다.
이 글(브룩스의 논문)을 꼭 읽어 보길 바란다. 시대에 뒤떨어진 부분도 많지만, 그것들은 이 글의 ‘우연적’ 속성들이다(무슨 말인지 느낌 오죠?). ‘본질’은 그 어느 때보다 적용 가능하다. 그리고 단 한 가지라도 가져가야 한다면, 이것이다. 훌륭한 개발자가 되어라. 그리고 내가 훌륭해지도록 도와달라.
브룩스는 IBM의 OS/360 운영체제 프로젝트 책임자로서 얻은 소프트웨어 개발의 지혜를 담은 고전 _맨먼스 미신( The Mythical Man-Month )_으로 가장 잘 알려져 있다. 이 책에서 유래한 ‘브룩스의 법칙’은 이렇다. 늦은 프로젝트에 인력을 추가하면 더 늦어진다. 모두가 동의하면서 아무도 지키지 않는 관찰이다. 내 경험으로는 — 절대로, 정말 단 한 번도 — 틀린 적이 없다. 늦은 프로젝트에 사람만 더 쏟아붓는 일은 마른 아첨꾼 관리자의 초라한 엉덩이를 구해 줄지는 몰라도, 프로젝트에는 전혀 도움이 되지 않는다.
브룩스는 수년에 걸쳐 수많은 상을 받았는데, 아마도 가장 권위 있는 상은 1999년 ACM 앨런 J. 튜링상일 것이다. 수상 사유는 “컴퓨터 아키텍처, 운영체제, 소프트웨어 공학에 대한 기념비적 공헌”이다. 그는 IBM 메인프레임의 인터럽트 시스템을 고안(해당 특허 보유)했고, ‘컴퓨터 아키텍처’라는 용어를 만들었으며, IBM 시스템에서 최소 가주소 단위를 8비트 바이트로 정립한 것으로도 유명하다. 진짜 거물이다.
