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

한 줄 요약

“소프트웨어 공학” 이라는 말은 1968년 10월 독일 가르미슈에서 열린 NATO 과학위원회 후원 회의의 제목으로 일부러 도발적으로 붙여졌다. 소프트웨어 생산도 다른 공학처럼 이론적 기반과 실무 규율 위에 서야 한다는 주장이었고, 그 배경에는 참가자들이 “소프트웨어 위기” 라고 부른 일정·비용·신뢰성 문제가 있었다.

왜 필요한가

오늘 우리가 당연하게 쓰는 요구사항, 설계 리뷰, 테스트 계획, 형상 관리, 유지보수 같은 단어는 처음부터 “프로그래밍” 의 일부가 아니었다. 1960년대 중반까지 프로그래밍은 기계를 다루는 기술, 혹은 수학의 응용으로 여겨졌다. 그런데 기계가 수천 배 빨라지자 사람들이 만들려는 시스템의 규모도 그만큼 커졌고, 개인의 솜씨로는 감당이 안 되기 시작했다.

이 역사를 알아야 하는 실무적 이유가 있다.

  • 지금 팀이 겪는 문제(일정 지연, 추정 실패, 출시 후 결함)는 1968년 보고서에 거의 그대로 적혀 있다. 새 도구가 나올 때마다 “이번엔 해결됐다” 는 말을 경계할 근거가 된다.
  • “공학” 이라는 단어가 무엇을 요구하는지 알면, 우리 팀의 절차 중 어떤 것이 의식(儀式)이고 어떤 것이 실제 위험을 줄이는 장치인지 가를 기준이 생긴다.

핵심 개념

회의의 기본 사실

1차 자료는 회의 보고서 Software Engineering: Report on a conference sponsored by the NATO Science Committee(편집 Peter Naur, Brian Randell, 1969년 1월)다. 표지와 서문에서 확인되는 사실은 다음과 같다.

항목 내용
장소·기간 독일 가르미슈(Garmisch), 1968년 10월 7일~11일
의장 F. L. Bauer (공동의장 L. Bolliet, H. J. Helms)
참가 11개국에서 온 50명 이상 — 사용자, 제조사, 대학
작업 분과 소프트웨어의 설계(Design), 생산(Production), 서비스(Service)
보고서 발간 1969년 1월, NATO 과학사무국

보고서 1장 “Background of Conference” 는 이름의 의도를 이렇게 적는다.

‘software engineering’ 이라는 말은 의도적으로 도발적인 것으로 선택되었다. 소프트웨어 제작이 공학의 전통적 분야에서와 같은 종류의 이론적 기반과 실무 규율 위에 서야 함을 함축하기 때문이다.

즉 1968년의 “소프트웨어 공학” 은 이미 존재하던 학문의 이름이 아니라 요구이자 선언이었다.

편집자 Brian Randell 은 회고 The 1968/69 NATO Software Engineering Reports에서 이 이름을 처음 제안한 사람이 Fritz Bauer 였다고 “기억한다” 고 쓰고, 보고서를 직접 인용을 엮어 만드는 방식(녹음 테이프와 기록자 메모에서 발췌)으로 편집했다고 설명한다. 보고서가 지금 읽어도 토론장처럼 생생한 이유다.

“소프트웨어 위기” 는 합의된 진단이 아니었다

흔히 “1968년 회의에서 소프트웨어 위기가 선언되었다” 고 요약하지만 원문은 더 조심스럽다. 보고서 7.1.2 절은 “일부 참가자들이 ‘software crisis’ 또는 ‘software gap’ 이라고 부르기로 한 것” 에 대해 상당한 논쟁이 있었고, 참가자들의 견해가 크게 엇갈렸다고 적는다.

같은 절에 실린 목소리를 나란히 놓으면 이렇다.

발언자 요지
David & Fraser (입장문) 야망과 성취 사이의 격차가 벌어진다 — 약속한 성능과 실제, 추정 비용과 지출 사이. 대형 소프트웨어의 오류는 생사의 문제가 될 수 있다
Hastings 비관론이 과하다. OS/360 을 쓰는 많은 대형 설치처가 예전보다 낮은 비용으로 필요한 일을 하고 있다
Gillette 항공기 산업도 일정·사양 문제를 겪는다. 우리는 젊은 산업이고 배우는 중이다
Buxton 컴퓨터의 99%가 그럭저럭 돌아가는 건 당연한 얘기고, 문제는 사회적으로 결정적인 “가장자리” 다

이 구도는 오늘날에도 반복된다. “소프트웨어는 대체로 잘 돌아간다” 는 말과 “중요한 곳에서 실패하면 대가가 크다” 는 말은 둘 다 참이다. 공학이 필요한 곳은 후자다.

1972년, Dijkstra 가 붙인 설명

위기의 원인에 대한 가장 유명한 설명은 회의 참가자이기도 했던 Edsger Dijkstra 의 1972년 ACM 튜링상 강연 The Humble Programmer (EWD340)에 있다. 그는 인터럽트 같은 기계 구조 변화는 “작은 원인” 이고, 주된 원인은 기계가 몇 자릿수 강력해진 것 자체라고 말한다.

기계가 없던 동안 프로그래밍은 전혀 문제가 아니었다. 약한 컴퓨터 몇 대가 생기자 가벼운 문제가 되었고, 이제 거대한 컴퓨터가 생기자 프로그래밍도 똑같이 거대한 문제가 되었다.

하드웨어의 진보가 문제를 풀어 준 게 아니라 문제의 크기를 키웠다는 통찰이다. 클라우드와 GPU 가 싸진 지금도 같은 구조가 보인다. 자원이 싸질수록 우리가 짓는 시스템은 더 커지고 더 많이 연결된다.

보고서에 이미 있던 주제들

보고서 목차는 오늘날 소프트웨어 공학 교과서의 목차와 놀랄 만큼 닮았다.

4. DESIGN        — 설계 기준, 사용자 요구, 신뢰성, 설계 순서, 구조화, 고급 언어
5. PRODUCTION    — 규모의 문제, 신뢰성, 생산 계획, 인력, 생산 통제, 내부 소통, 도구
6. SERVICE       — 현실적인 목표, 첫 릴리스, 릴리스 빈도, 배포, 유지보수
8. 초청 강연      — M. D. McIlroy, 'Mass Produced' Software Components

특히 McIlroy 의 강연은 “소프트웨어 산업은 산업화되지 않았다” 고 진단하고, 정밀도·견고성·범용성·시공간 성능에 따라 고를 수 있는 부품 계열(family)과 카탈로그를 제안했다. 표준 부품 제조사도, 표준 부품 카탈로그도 없다는 그의 불만은 오늘날의 패키지 저장소와 오픈소스 라이브러리 생태계로 상당 부분 현실이 되었다. 동시에 그 생태계는 의존성 관리라는 새 문제를 낳았다.

1969년 로마, 두 번째 회의

이듬해 1969년 10월 27일~31일 로마에서 2차 회의가 열렸고 보고서(Software Engineering Techniques, 1969)는 Buxton 과 Randell 이 편집했다. Randell 의 회고에 따르면 2차 회의는 관리 문제보다 기술 문제에 집중하려 했으나 1차만큼 조화롭지 못했고, 편집자의 역할도 달라졌다. 이론과 실무 사이의 간극이 그때부터 이미 갈등의 축이었다는 뜻이다.

실무 적용

1968년 보고서를 “옛날 얘기” 로 두지 않고 팀 점검표로 바꿔 보면 쓸모가 생긴다. 아래는 보고서의 세 분과(설계·생산·서비스)를 현재 팀의 질문으로 옮긴 것이다.

# 1968 NATO 보고서 3분과 → 오늘의 점검 질문
design:
  - 사용자 요구가 문서든 예제든 "검증 가능한" 형태로 남아 있는가?
  - 설계 결정과 그 이유가 기록되는가? (ADR 등)
  - 신뢰성 목표를 설계 단계에서 정했는가, 출시 후에 정했는가?
production:
  - 일정 추정이 과거 실적에 근거하는가, 희망에 근거하는가?
  - 진행 상황을 "90% 완료" 대신 관찰 가능한 산출물로 보는가?
  - 사람이 늘 때 소통 비용을 계획에 넣는가? (SE100 #003 에서 다룬다)
service:
  - 첫 릴리스의 범위를 현실적으로 잘랐는가?
  - 릴리스 빈도와 배포 절차가 사람의 기억이 아니라 자동화에 있는가?
  - 운영 중 결함 보고가 개발 쪽으로 되돌아오는 경로가 있는가?

이 질문들이 반세기 넘게 유효하다는 사실 자체가 교훈이다. 기술은 바뀌었지만 규모가 커질 때 사람이 조율하는 문제는 그대로다. 생명주기 모델의 기초는 소프트웨어 개발 생명주기에서 다뤘다.

흔한 오해와 함정

  • “1968년에 소프트웨어 공학이 확립되었다.” 원문은 확립이 아니라 필요의 선언이다. 이름부터 “도발적” 이라고 스스로 밝힌다.
  • “모두가 위기라는 데 동의했다.” 보고서 7.1.2 절은 견해가 크게 엇갈렸다고 명시한다. 위기론은 당시에도 논쟁적이었다.
  • “소프트웨어 위기는 해결되었다.” 무엇을 위기로 정의하느냐에 달려 있다. Dijkstra 의 설명대로라면 능력이 커질수록 야망도 커지므로, 위기는 끝나는 사건이 아니라 계속되는 조건에 가깝다.
  • “공학 = 무거운 문서와 절차.” 1968년 참가자들이 원한 것은 “이론적 기반과 실무 규율” 이었다. 절차의 양이 아니라 위험을 줄이는 근거가 핵심이다.
  • 2차 출처의 인용을 그대로 옮기기. 이 회의에 관한 유명한 “명언” 중 상당수는 원문 확인 없이 돌아다닌다. 보고서 PDF 가 공개되어 있으니 원문을 확인하는 습관을 들이자.

확인 문제

  1. 1968년 NATO 회의 보고서는 “software engineering” 이라는 이름을 왜 골랐다고 설명하는가?
  2. 보고서가 “소프트웨어 위기” 를 다루는 방식은 흔한 요약과 어떻게 다른가?
  3. Dijkstra 는 소프트웨어 위기의 “주된 원인” 을 무엇이라고 보았는가?
  4. McIlroy 가 1968년에 제안한 것과 오늘날 패키지 생태계의 공통점, 그리고 그가 예상하지 못했을 법한 새 문제는?
  5. 회의의 세 작업 분과는 무엇이었나?

풀이

  1. 소프트웨어 제작도 기존 공학 분야처럼 이론적 기반과 실무 규율 위에 서야 한다는 함의를 담아 “의도적으로 도발적인” 이름으로 골랐다.
  2. 보고서는 “일부 참가자가 그렇게 부르기로 한 것” 이라고 표현하고, 그 심각성에 대해 견해가 크게 엇갈렸다고 기록한다. 만장일치의 선언이 아니었다.
  3. 기계가 몇 자릿수 강력해졌다는 것 자체. 능력이 커지자 사회가 기계에 맡기려는 야망도 비례해 커졌다.
  4. 필요한 성질에 따라 골라 쓰는 재사용 부품과 카탈로그라는 발상. 새 문제로는 전이 의존성, 공급망 보안, 버전 충돌 같은 의존성 관리 비용이 있다.
  5. 설계(Design), 생산(Production), 서비스(Service).

더 읽을거리 (References)