소프트웨어 공학 100 주제 시리즈의 2번째 글이다. (카테고리: 기초와 역사)

한 줄 요약

Fred Brooks 는 1986년 논문에서 소프트웨어의 어려움을 본질(essence) — 복잡한 개념 구조 자체를 정하는 일 — 과 우연(accident) — 그것을 언어와 기계로 표현하는 일 — 으로 나누고, 우연만 줄이는 기술로는 10년 안에 생산성·신뢰성·단순성 중 어느 하나도 한 자릿수(10배) 개선을 기대할 수 없다고 주장했다.

왜 필요한가

새 언어, 새 프레임워크, 새 개발 도구가 나올 때마다 “개발 속도가 몇 배” 라는 주장이 따라온다. 그 주장이 맞는 경우도 있다. 문제는 어디가 빨라지는지를 구분하지 않을 때다.

  • 보일러플레이트를 자동 생성해 주는 도구는 타이핑을 줄인다. 그런데 팀의 시간이 주로 “무엇을 만들지 합의하는 데” 쓰이고 있다면 전체 일정은 거의 줄지 않는다.
  • 반대로 요구사항이 흔들려서 생기는 재작업은 어떤 IDE 도 막아 주지 않는다.

Brooks 의 구분은 도구 도입을 평가할 때 “이것이 본질을 건드리는가, 우연을 건드리는가” 라는 질문을 던지게 해 준다.

핵심 개념

원문과 출간

원 논문은 UNC 기술 보고서 TR86-020, No Silver Bullet: Essence and Accidents of Software Engineering(1986년 9월)이고, 이후 IEEE Computer 20(4), 1987에 실렸다. 제목의 은빛 탄환은 늑대인간을 한 번에 쓰러뜨리는 민담의 무기다. 평범해 보이던 프로젝트가 일정 초과·예산 초과·결함투성이 제품이라는 괴물로 변할 때, 관리자들은 은빛 탄환을 찾는다는 비유다.

핵심 주장은 서론에 있다.

10년 앞을 내다보아도 은빛 탄환은 보이지 않는다. 기술이든 관리 기법이든, 그것 하나만으로 생산성·신뢰성·단순성에서 한 자릿수의 개선이라도 약속하는 단일한 발전은 없다.

그리고 곧바로 “회의론은 비관론이 아니다” 라고 덧붙인다. 꾸준하고 규율 있는 노력이 쌓이면 한 자릿수 개선도 가능하다는 것 — “왕도는 없지만 길은 있다” 가 그의 결론이다.

본질과 우연

Brooks 는 아리스토텔레스를 빌려 어려움을 둘로 나눈다.

구분 원문 정의 예
본질(essence) 소프트웨어의 본성에 내재한 어려움. 데이터 집합, 데이터 간 관계, 알고리즘, 함수 호출이 맞물린 개념 구조를 명세·설계·테스트하는 일 할인 규칙이 서로 충돌할 때 무엇이 우선인가 정하기
우연(accident) 오늘날 생산에 따라붙지만 내재적이지 않은 어려움. 개념 구조를 언어로 표현하고 기계에 매핑하는 일 메모리 수동 관리, 느린 빌드, 장황한 문법

그가 믿은 명제는 이렇다. “소프트웨어를 만드는 어려운 부분은 이 개념 구조의 명세·설계·테스트이지, 그것을 표현하는 노동이 아니다. 구문 오류는 대부분의 시스템에 있는 개념 오류에 비하면 잡음(fuzz)이다.”

초록에는 간단한 산수가 붙어 있다. 지금 하는 일 중 우연적인 일이 10분의 9 이상이 아니라면, 우연적 작업을 모두 0으로 줄여도 한 자릿수 개선은 나오지 않는다.

\[\text{속도 향상} = \frac{1}{(1-a) + a/s}, \quad a=\text{우연적 비율},\ s=\text{그 부분의 가속}\]

암달의 법칙과 같은 구조다. 우연적 비율이 절반($a=0.5$)이면 그 부분을 무한히 빠르게 해도($s\to\infty$) 전체는 2배가 한계다.

본질의 네 가지 성질

Brooks 는 본질적 어려움이 어디서 오는지 네 가지 성질로 설명한다.

  1. 복잡성(complexity) — 소프트웨어는 같은 부분이 거의 없다. 같으면 서브루틴으로 합치기 때문이다. 규모가 커지면 같은 요소가 반복되는 게 아니라 다른 요소가 늘어나고, 요소들이 비선형으로 상호작용한다. 그래서 복잡성을 추상화로 지우면 본질까지 지워진다.
  2. 순응성(conformity) — 물리학자는 통일 원리가 있다고 믿지만, 소프트웨어가 맞춰야 하는 인터페이스는 서로 다른 사람·기관이 정한 자의적인 것이다. 세법, 레거시 API, 파트너사 파일 포맷은 소프트웨어만 다시 설계한다고 단순해지지 않는다.
  3. 변경 가능성(changeability) — 소프트웨어는 기능을 담고 있고, 기능이 가장 변경 압력을 받는다. 게다가 바꾸기 쉬워 보인다. 그는 “성공한 소프트웨어는 모두 변경된다” 고 쓴다.
  4. 비가시성(invisibility) — 건물에는 평면도가 있지만 소프트웨어 구조는 제어 흐름, 데이터 흐름, 의존 관계, 이름 공간 같은 여러 방향 그래프가 겹쳐 있어 하나의 그림으로 보이지 않는다. 설계와 소통 모두를 방해한다.

과거의 돌파구는 우연을 공략했다

논문 3장은 고급 언어, 시분할, 통합 프로그래밍 환경(Unified Programming Environments)을 과거의 큰 성과로 꼽고, 모두 우연적 어려움을 줄였다고 평가한다. 4장은 당시 은빛 탄환으로 거론되던 후보들 — Ada 와 고급 언어 발전, 객체지향 프로그래밍, 인공지능, 전문가 시스템, 자동 프로그래밍, 그래픽 프로그래밍, 프로그램 검증, 환경과 도구, 워크스테이션 — 을 하나씩 검토하고, 각각이 쓸모는 있지만 본질을 한 자릿수로 줄이지는 못한다고 판단한다.

본질을 공략하는 네 가지 길

5장에서 Brooks 는 본질에 닿는 방법으로 넷을 제안한다.

제안 원문 요지 오늘의 모습
만들지 말고 산다(Buy versus Build) 가장 급진적인 해법은 아예 만들지 않는 것 SaaS, 오픈소스, 관리형 서비스
요구사항 정제와 신속한 프로토타이핑 “소프트웨어 시스템을 만드는 가장 어려운 단일 부분은 정확히 무엇을 만들지 정하는 것” 프로토타입, 사용자 테스트, 짧은 피드백 주기
점진적 개발 — 짓지 말고 키운다 먼저 돌아가는 뼈대를 만들고 조금씩 살을 붙인다 반복·증분 개발, 지속적 배포
위대한 설계자 나쁜 설계와 좋은 설계의 차이는 방법론에 있을 수 있지만, 위대한 설계는 위대한 설계자에게서 나온다 설계 역량을 키우는 멘토링과 커리어 경로

두 번째 항목에서 그는 고객조차 자신이 원하는 것을 모른다고 단언하고, 고객과 설계자 사이의 광범위한 반복을 계획에 넣어야 한다고 말한다. 요구사항 공학과 애자일이 왜 생겼는지에 대한 1986년판 답이다.

실무 적용

도구나 기술을 도입하자는 제안이 올라오면 다음 표를 채워 보자. 숫자는 정확할 필요 없다. 팀의 시간이 어디에 쓰이는지 눈으로 보는 것이 목적이다.

# 지난 스프린트 시간 배분을 대략 적고, 도구가 줄여 줄 부분만 가속해 본다.
# 숫자는 모두 설명용 가정이다.
activities = {
    # 이름: (비율, 본질/우연, 새 도구의 가속 배수)
    "요구사항 합의·재작업":   (0.30, "essence",  1.0),
    "설계 논의":              (0.15, "essence",  1.0),
    "코드 작성(타이핑)":      (0.20, "accident", 3.0),
    "빌드·배포 대기":         (0.10, "accident", 5.0),
    "디버깅":                 (0.15, "mixed",    1.5),
    "테스트 작성":            (0.10, "mixed",    2.0),
}
new_time = sum(r / s for r, _, s in activities.values())
print(f"전체 속도 향상: {1/new_time:.2f}배")

실행 결과:

전체 속도 향상: 1.46배

코드 작성을 3배, 빌드 대기를 5배 빠르게 해도 전체는 1.5배가 안 된다. 같은 표에서 “요구사항 재작업” 을 반으로 줄이는 시나리오와 비교해 보면, 어디에 투자할지가 보인다. 이 계산은 예측이 아니라 대화를 위한 틀이다.

추가로 볼 만한 질문:

  • 이 도구는 개념 구조를 표현하는 일을 줄이는가, 정하는 일을 줄이는가?
  • 순응성(외부 인터페이스) 때문에 생기는 복잡성을 우리가 설계로 없앨 수 있다고 착각하고 있지 않은가?
  • 살 수 있는 것을 만들고 있지 않은가?

흔한 오해와 함정

  • “Brooks 는 진보가 불가능하다고 했다.” 반대다. 단일한 돌파구가 없다는 것이지, 여러 혁신을 꾸준히 쌓으면 한 자릿수 개선도 가능하다고 썼다.
  • “본질 = 비즈니스 로직, 우연 = 기술 코드.” 근사적으로는 맞지만 Brooks 의 정의는 활동 기준이다. 개념 구조를 정하고 검증하는 일이 본질이고, 그것을 표현하는 노동이 우연이다. 기술 영역에도 본질(예: 분산 합의의 정확성)이 있다.
  • “우연적 복잡성은 쓸모없다.” 우연적 어려움은 줄일 가치가 크다. 과거의 큰 생산성 향상은 모두 여기서 나왔다. 다만 그것만으로는 상한이 있다는 것이다.
  • “10년” 기한을 무시하기. 원문의 예측은 “10년 앞” 이라는 범위를 가진다. 이 논문을 영원한 법칙처럼 인용하거나, 반대로 몇십 년 뒤의 기술로 “틀렸다” 고 반박하는 것 모두 원문의 범위를 벗어난다.

확인 문제

  1. Brooks 가 말하는 본질적 어려움과 우연적 어려움을 각각 한 문장으로 정의하라.
  2. 우연적 작업 비율이 60%일 때, 그것을 0으로 만들면 전체 생산성은 최대 몇 배가 되는가?
  3. “순응성” 이 리팩터링만으로 해결되지 않는 이유는?
  4. Brooks 가 제안한 본질 공략법 네 가지는?
  5. “Brooks 는 소프트웨어 생산성의 큰 개선은 불가능하다고 했다” 는 요약이 틀린 이유는?

풀이

  1. 본질: 소프트웨어의 개념 구조(데이터, 관계, 알고리즘, 호출)를 명세·설계·테스트하는 데 내재한 어려움. 우연: 그 구조를 언어와 기계로 표현하는 과정에서 생기는, 내재적이지 않은 어려움.
  2. 남는 시간이 40%이므로 $1/0.4 = 2.5$배가 상한이다. 한 자릿수(10배)에 못 미친다.
  3. 그 복잡성은 외부 기관·시스템이 자의적으로 정한 인터페이스에서 오므로, 우리 소프트웨어 설계만 바꿔서는 사라지지 않는다.
  4. 만들지 말고 사기, 요구사항 정제와 신속한 프로토타이핑, 점진적 개발(키우기), 위대한 설계자 육성.
  5. 원문은 “단일한” 기술이나 기법으로 10년 안에 한 자릿수 개선은 없다는 주장이며, 규율 있는 노력이 쌓이면 한 자릿수 개선도 가능하다고 명시한다.

더 읽을거리 (References)