은탄환은 없다 - RosettaLens 번역

읽는 데 8분

2020년 9월 10일

전체 크기로 보려면 Enter 키를 누르거나 이미지를 클릭하세요

소프트웨어 공학의 본질과 우연: 은탄환은 없다( No Silver Bullet: Essence and Accident in Software Engineering ), 프레드 브룩스의 논문은 1986년에 처음 발표된 기념비적 저작이다. 이 블로그의 ‘고전으로 읽는 컴퓨터 과학’ 시리즈의 첫 글로 이 논문을 고른 이유가 몇 가지 있다. 첫째, 이 블로그의 존재 이유, 즉 “어떻게 하면 더 나아질 수 있을까?”라는 질문에 곧장 답을 건네기 때문이다. 또 하나의 이유는, 30년도 훨씬 전에 나온 글임에도 지금도 여전히 씨름하고 있는 소프트웨어 개발의 난제들을 다루고 있기 때문이다.

_은탄환은 없다_에서 브룩스는 소프트웨어 프로젝트를 늑대인간에 비유한다. 평소에는 멀쩡한 사람처럼 보이지만, 때때로 목을 물어뜯는 괴물로 변하는 존재. 이 괴물을 죽일 수 있는 유일한 방법은 은탄환으로 쏘는 것이다.

“그렇다면,” 그는 묻는다. “우리의 통제에서 벗어나고, 터무니없이 비싸며, 늘 늦어지는 이 괴물 같은 소프트웨어 프로젝트를 무찔러 줄 은탄환은 어디에 있나?” 글쎄, 답은 우리도 짐작한다. 기사 제목이 바로 “은탄환은 없다”가 아닌가. 이 뉴스의 리드를 숨기지는 않았다.

은탄환은 없다.

슬픈 소식이다. 우리는 믿고 싶지 않다. 브룩스의 법칙(“늦은 프로젝트에 인력을 추가하면 더 늦어진다”)처럼, 우리는 진실을 무시한 채 태연히 버스를 절벽으로 몰아간다. 반복해서.

브룩스는 더 나아가 말한다. 은탄환만 없는 게 아니다 — 프로그래머 생산성을 한 자릿수도 아닌 한 자릿수 이상의(즉, 10배 수준의) 향상을 약속하는 무언가도 지평선 어디에도 보이지 않는다. 제때 예산 안에, 신뢰할 수 있고 버그가 거의 없는 소프트웨어를 전달할 능력을 획기적으로 높여 줄 그 무엇도 당분간 기대하기 어렵다.

왜 이렇게 심각한가? 왜 이렇게 비관적인가? 브룩스는 그냥 비관주의자, 늘 먹구름을 이고 사는 이요르 같은 인물인가? 좋아요, ‘자칭 기술 근육남’ 여러분, OS/360 경험이 별로 좋지 않았다는 건 알겠어요. 그렇다고 그 앙금을 우리에게 푸시려는 건가요?

사실, 그가 그런 입장을 고수할 만한 설득력 있는 이유가 있다. 논문의 앞부분에서 그는 소프트웨어가 거의 모든 다른 인공물과 어떻게 다른지, 그 ‘본질’을 들여다본다.

본질과 우연

그는 지금까지 우리가 생산성에서 가장 큰 도약을 이뤘던 돌파구들이 소프트웨어 개발의 ‘본질’을 건드린 것이 아니라 ‘우연적(부수적) 속성’을 다룬 덕분이었다고 주장한다.

본질과 우연이라니, 이게 무슨 말인가? ‘우연’이 어떻게 ‘본질적’인 것과 엮이는가? 혼란스러울 수 있다. 우리가 흔히 말하는 ‘우연’은 예기치 못하고 의도하지 않은 사건, 아마 실수나 잠깐의 방심에서 비롯된 일이다.

브룩스가 말하는 ‘우연’은 그런 뜻이 아니다. 그는 철학적 의미, 아리스토텔레스까지 거슬러 올라가는 의미로 쓴다. 아리스토텔레스에게서 ‘본질적’ 성질이란 그 사물에 내재된, 때로는 정의 자체에 해당하는 성질이다. 의자는 다리와 좌판을 가진다. 이것이 의자의 본질이다. 이것이 없으면 우리는 그 사물을 의자라 부르지 않는다. 다시 말해, 어떤 대상의 본질적 성질이란 그것을 제거하면 그 대상이 더 이상 그 자체로 남아 있지 못하는 성질이다. 의자의 다리를 떼어버리면, 남은 그 무언가가 무엇이든 더 이상 의자는 아니다.

반대로 ‘우연적(부수적)’ 성질은 제거하거나 바꾸어도 원래의 대상이 여전히 그대로 남아 있는 성질이다. 예를 들어 빨간 의자를 갈색으로 바꿔도 여전히 의자다. 색깔은 ‘우연적(부수적)’ 속성이다. 오늘날 말로는 ‘부차적’, ‘부수적’이라 하는 편이 더 적절할 것이다.

정말 이렇게 어려워야 하나?

저자는 먼저 묻는다. “소프트웨어 개발은 원래 이렇게 어려운가? 정말 은탄환은 없는가?”

그의 답은 이렇다. 그렇다, 원래 어렵다. 그리고 아니다, 은탄환은 없다.

Ken Baum의 글을 이메일로 받아보세요

이 작가의 업데이트를 받으려면 Medium에 무료로 가입하세요.

그는 이렇게 답한다. 소프트웨어 시스템 개발에는 네 가지 ‘본질적’ 어려움이 있기 때문이다.

복잡성(Complexity)

소프트웨어는 같은 규모의 다른 어떤 인간의 산물보다도 더 복잡하다. 특히 문장(statement) 수준을 넘어가면 서로 같은 부분이 거의 없다. 그 결과 소프트웨어가 취할 수 있는 상태의 수가 터무니없이 많아진다. 그리고 복잡성은 크기에 따라 선형으로 증가하지 않는다. 더 큰 시스템은 작은 구성요소의 더 큰 버전들로 이루어지지 않는다. 더 많고, 더 다양한 부분과 상태들로 구성된다. 복잡성은 사실상 선형이 아니라 준-지수적으로 자란다.
규모가 커질수록 관리 또한 복잡해진다. 사람은 늘고, 의사소통 경로는 기하급수적으로 늘어난다. 소통은 필수적이지만 동시에 어렵다. 관리해야 할 세부사항이 폭증해 결국 중요한 항목이 간과되거나 대충 넘어가기 쉽다. “이는 엄청난 학습과 이해의 부담을 만들어, 인력 이탈을 재앙으로 만든다.”(p. 3)

합치성(Conformity)

“그(소프트웨어 엔지니어)가 마스터해야 하는 복잡성의 상당 부분은 임의적(arbitrary) 복잡성이다. 수많은 인간 제도와 시스템이 요구하는 각종 인터페이스에 ‘맞추기 위해’ 별다른 이유 없이 강요되는 복잡성 말이다.”(p. 3–4) 아인슈타인은 자연법칙이 정연하고 이해 가능하며, 신이 설계했기에 “신은 우주에서 주사위를 던지지 않는다”고 믿었다. 그러나 소프트웨어 개발자에게 그런 믿음은 위안을 주지 못한다. 우리의 요구사항은 신이 아니라 인간, 대개는 다수의 인간이 준다.

가변성(Changeability)

“소프트웨어는 끊임없이 변화 압력에 노출된다.”(p. 4) 다른 대상들도 변화 압력을 받지만, 물리적 대상은 비용과 노력이 잘 알려져 있어 변경이 상대적으로 드물다. 아무도 2층집을 3층집으로 만들겠다며 2층을 들어 올려 그 사이에 한 층을 끼워 넣자고는 하지 않는다. 소프트웨어는 바꾸기 쉽다고 ‘인지’되기 때문에, 이런 부자연스러운 요구가 소프트웨어 세계에서는 흔하다.

비가시성(Invisibility)

“소프트웨어는 보이지 않고, 시각화할 수 없다.”(p. 4) 건물의 평면도는 머릿속에서 곧바로 방이나 건물의 형태로 번역된다. 컴퓨터 프로그램에는 그런 표상이 없다. 그래서 내 생각에, 수년간 제안되어 온 수많은 설계 다이어그램이 별로 도움이 되지 않는 것이다. 클래스 구조나 프로세스 흐름처럼 산출물의 일부 단면을 담을 수는 있지만, 전체 시스템의 복잡성을 관리하는 데 도움이 되는 표상은 없다.

우연적 개선들

이 네 가지 본질적 어려움을 개관한 뒤, 브룩스는 과거 생산성에서 큰 향상을 이끌어 온 영역들을 검토한다. 그의 결론은, 그 돌파구들은 본질적 어려움이 아니라 우연적(부수적) 어려움을 다뤄 왔다는 것이다.

고급 언어는 하드웨어 아키텍처를 추상화하여, 개발자가 레지스터 같은 저수준 구성 요소를 신경 쓰지 않아도 되게 했다. 추상화 수준은 계속 높아지고 있지만, 이것이 프로그램의 복잡성을 줄이지는 않는다. 프로그램과 그 구성물을 ‘표현하는’ 어려움을 줄였을 뿐, 상태 폭증과 관리 복잡성의 문제는 그대로 남는다.

시분할 시스템은 지금은 과거의 유물이 되었지만, 당시 프로그래머에게 즉각적인 피드백을 제공했다. 예전에는 프로그램을 입력하고, 잡을 제출하고, 메인프레임이 언젠가 실행해 주기를 기다려야 했다. 이제는 에디터에서 바로 입력하고, 즉시 컴파일하고, 실행할 수 있게 됐다. 과정은 빨라졌지만, 역시 소프트웨어의 본질적 복잡성을 줄이지는 못했다.

통합 개발 환경(오늘날의 IDE)은 프로그래머에게 또 하나의 도약이었다. 개발자는 하나의 환경에서 일하며 여러 도구(에디터, 링커, 로더 등)를 이리저리 넘나들 필요가 없다. 이 또한 개발 속도를 높였지만, 본질적 복잡성을 줄이지는 못했다. 공정하게 말하자면, 현대 IDE는 강력하며 귀찮은 보일러플레이트 코드를 많이 생성해 준다. 우리는 그것이 무척 고맙다. 하지만 당면 문제의 내재적 복잡성은 생성 코드에 전혀 꿈쩍하지 않는다. 게다가 우리는 패키지 매니저, 번들러, IoC 컨테이너 같은 도구로 새로운 복잡성을 보탰다. 이것들을 설정하고 유지하는 데도 상당한 지적 노력이 든다. 정규식을 써서 문제를 풀면 “문제가 둘로 늘어난다”는 격언과 비슷하다.

지금까지 생산성의 가장 큰 성과들이 소프트웨어 본질과는 무관한 문제를 해결하면서 얻어졌음을 보인 뒤, 괴팍한 브룩스 박사는 은탄환으로 광고되던 여러 기술을 검토한다. 고급 언어의 지속적 발전, 객체지향, 인공지능, 전문가 시스템, ‘자동’ 프로그래밍, 그래픽 프로그래밍, 프로그램 검증, 프로그래밍 환경과 워크스테이션의 개선 등이다. 이들 모두 어느 정도 유용하며 무시해서는 안 되지만, 이 가운데 어느 것도 생산성을 두 배로 늘려 줄 것조차 약속하지 못한다고 그는 말한다. 저자가 제시한 여러 이유에서, 이들 항목은 소프트웨어 개발의 본질적 복잡성을 건드리지 못한다.

그렇다면 요점은 무엇인가? 아무것도 도움이 안 된다면, 도대체 어떻게 소프트웨어 개발을 개선할 수 있다는 말인가? 브룩스가 그려낸 풍경은 무척 우울하고, 거의 냉소적이기까지 하다.

은탄환은 없지만 마늘은 있다?

저자에 따르면, 은탄환은 없더라도 희망은 있다. 적어도 늑대인간을 물리칠 ‘마늘’은 손에 쥘 수 있다(중세의 몇몇 신화에서 마늘은 뱀파이어, 늑대인간, 온갖 사악한 존재를 물리치는 도구였다). 브룩스는 생산성 향상을 약속하는 네 가지 영역을 개략적으로 제시한다. 그는 소프트웨어 개발의 어려움을 정확히 지적할 뿐 아니라, 오싹할 만큼 예지력 있게 실제로 우리에게 도움이 될 것들을 내다본다.

사서 쓰기 vs. 직접 만들기(Buy vs. Build)

최고의 소프트웨어는, 애초에 ‘안 만들어도 되는’ 소프트웨어다. 해법을 사는 편이 만드는 것보다 싸다고 그는 말한다. 당시에는 구체를 알 수 없었겠지만, 이는 오픈소스의 확산과 함께 상당 부분 현실이 되었다.

요구사항 정제와 빠른 프로토타이핑

이 대목에서 그는 애자일 개발을 예견했다.

점진적 개발 — 소프트웨어는 ‘짓지’ 말고 ‘키워라’

시스템을 조금씩 ‘키워’ 나가면, 완성되기 전에 동작하는 소프트웨어를 전달할 수 있다. 사용자는 자신이 무엇을 얻게 될지 보고, 큰 재작업과 재설계 없이도 조정이 가능하다. 애자일의 핵심 정신 그대로다.

뛰어난 설계자(Great designers)

이것이 회심의 일격이다. 브룩스는 가장 중요한 사실을 극적으로 마지막에 꺼낸다. 우리를 허를 찌르는, 너무도 자명하면서도 가장 무시된 진실. 위대한 시스템은 위대한 프로그래머가 만든다. 우리가 방법론, 도구, 자동화에 집착하는 동안, 진짜로 신경 써야 할 것은 ‘개발자 자체를 개발하는 것’이다. 서로를 성장시키고, 주변 모든 개발자의 실력을 끌어올리는 데 노력을 기울여야 한다. 그러나 우리 대부분은 자신에게만 바쁘고, 새 도구와 섹시한 언어에 기꺼이 시선을 빼앗긴다. 우리의 최고의 생각과 노력을 빼앗아야 하는 일은 ‘훌륭한 프로그래머가 되는 것’, 그리고 ‘주변 모두를 훌륭하게 만드는 것’이다.

이 글(브룩스의 논문)을 꼭 읽어 보길 바란다. 시대에 뒤떨어진 부분도 많지만, 그것들은 이 글의 ‘우연적’ 속성들이다(무슨 말인지 느낌 오죠?). ‘본질’은 그 어느 때보다 적용 가능하다. 그리고 단 한 가지라도 가져가야 한다면, 이것이다. 훌륭한 개발자가 되어라. 그리고 내가 훌륭해지도록 도와달라.

프레드 브룩스는 누구인가?

브룩스는 IBM의 OS/360 운영체제 프로젝트 책임자로서 얻은 소프트웨어 개발의 지혜를 담은 고전 _맨먼스 미신( The Mythical Man-Month )_으로 가장 잘 알려져 있다. 이 책에서 유래한 ‘브룩스의 법칙’은 이렇다. 늦은 프로젝트에 인력을 추가하면 더 늦어진다. 모두가 동의하면서 아무도 지키지 않는 관찰이다. 내 경험으로는 — 절대로, 정말 단 한 번도 — 틀린 적이 없다. 늦은 프로젝트에 사람만 더 쏟아붓는 일은 마른 아첨꾼 관리자의 초라한 엉덩이를 구해 줄지는 몰라도, 프로젝트에는 전혀 도움이 되지 않는다.

브룩스는 수년에 걸쳐 수많은 상을 받았는데, 아마도 가장 권위 있는 상은 1999년 ACM 앨런 J. 튜링상일 것이다. 수상 사유는 “컴퓨터 아키텍처, 운영체제, 소프트웨어 공학에 대한 기념비적 공헌”이다. 그는 IBM 메인프레임의 인터럽트 시스템을 고안(해당 특허 보유)했고, ‘컴퓨터 아키텍처’라는 용어를 만들었으며, IBM 시스템에서 최소 가주소 단위를 8비트 바이트로 정립한 것으로도 유명하다. 진짜 거물이다.