1968 년 NATO 컨퍼런스 에서 *처음 *“소프트웨어 위기” 라는 단어 가 등장했다. 컴퓨터는 빨라지는데, *소프트웨어는 *제 시간 / 제 예산 / 제 품질로 안 만들어진다. 그 후 60 년 이 지났지만 — 위기는 *형태를 바꾸어 *반복 된다. 이 글은 4 가지 *하드웨어 (CPU / Memory / HDD / SSD) 의 발전사 가 어떻게 *위기를 *만들었는지 의 연대 기.

TL;DR

시기 하드웨어 도약 그로 인한 소프트웨어 위기
1950 ~ 1960 진공관 → 트랜지스터, kB 메모리 기계 어 직접 작성, 조작 의 *복잡도 — 어셈블러 / FORTRAN 등장
1968 IBM/360 — 대용량 OS NATO 컨퍼런스 — Software Crisis 용어 공식화
1970 ~ 80 마이크로프로세서, MB 메모리 프로젝트 비대화 — 구조적 프로그래밍 / 모듈화
1990 ~ 2000 GHz CPU, GB 메모리, HDD GB → TB 분산 시스템 / 인터넷 — 객체지향 / 패턴
2005 ~ 15 멀티 코어, RAM GB, SSD 등장 병렬화의 어려움 — 함수형 / 액터 / 동시성 모델
2015 ~ 25 NVMe / DDR5 / 큰 캐시 SSD 클라우드 / MSA / 컨테이너 — 분산 시스템 의 *새 위기
2025 ~ NPU / AI 가속기 / Edge SSD AI 시대 의 *새 위기 — AI 가 *어떻게 *공존 가능한가

요약 한 줄 :

소프트웨어 위기는 *끝난 적 없다. 하드웨어 의 *각 도약 이 새 위기 를 *낳고, 소프트웨어 는 *적응 의 *경주 를 계속 한다*.

1. 1968 — *NATO 컨퍼런스 와 *소프트웨어 위기 의 시작

Software Crisis 용어 의 기원

1968 년, NATO 가 독일 가르미슈 에서 컴퓨터 과학 컨퍼런스 를 열었다. 50 명 의 최고 전문가 가 모여 문제 의 본질 을 논의 :

“하드웨어 는 매년 *2배 가 빨라지는데 — 우리가 *그 빠른 컴퓨터 로 *해결 가능한 문제 는 왜 *느리게 *늘어 나는가.”*

이 간극 이 Software Crisis. Edsger Dijkstra 의 *1972 튜링상 강연 “겸손한 프로그래머” 에서 결정 적 언급 되며 고전화.

증상

당시 대형 프로젝트 의 *80% 가 :

  • 예산 초과
  • 일정 지연
  • 요구사항 미충족
  • 유지보수 *불가능
  • 버그 가 *무한

대표 사례 — IBM OS/360 (1964 ~). 수천 명 의 인력, 수년의 지연, 수십만 줄 의 코드 가 *디버깅 불가능. Frederick Brooks 의 유명한 책 The Mythical Man-Month (1975) 의 현장.

2. CPU 발전사 — Moore’s Law 와 *위기의 *연쇄

1947 ~ 1980 — 진공관 → 트랜지스터 → IC → 마이크로프로세서

1947  : 트랜지스터 발명 (Bell Labs)
1958  : 집적회로 (IC) — Jack Kilby
1965  : Moore's Law — *2년마다 트랜지스터 2배*
1971  : Intel 4004 — *최초 *4-bit *마이크로프로세서*
1978  : Intel 8086 — *PC 의 *시조*

이 시기 위기 : 기계 어를 *직접 *작성 해야 하는 부담. 인간이 *수만 개 명령어 를 *손으로 짜는 것 은 비효율. → 고급 언어 의 *탄생 (FORTRAN 1957, COBOL 1959, C 1972, Pascal 1970).

1980 ~ 2005 — Clock Speed 의 *황금기

1989 : Intel 486 — 25 MHz
1995 : Pentium Pro — 200 MHz
2000 : Pentium 4 — 1.5 GHz
2005 : Pentium 4 — *3.8 GHz 한계*

이 15 년 간 *CPU clock 가 *100 배 빨라짐. 개발자 의 멘탈 모델 :

“느린 코드 는 *내년 *하드웨어 에 *맡기면 됨.”*

이게 흔한 *합리화. 그러나 2005 년 에 Clock Speed 한계 *물리적 도달. 발열 + 누설 전류 가 Pentium 4 *를 *벽에 *처박았다.

2005 ~ 현재 — 멀티 코어 시대

2006 : Intel Core 2 Duo (2 cores)
2010 : Core i7 (4 cores)
2017 : Threadripper (16 cores)
2024 : EPYC 9754 — *128 cores*
2025 : Intel Granite Rapids — *144 cores*

이게 진짜 의 *새 위기. 단일 thread 가 더 안 빨라진다 → 기존 소프트웨어 가 *자동 으로 빨라지지 않음. 코드 *재 작성 필요. 병렬화 의 어려움 이 소프트웨어 의 *지배 적 *과제 가 됨.

3. Memory 발전사 — kB → TB 로 *6 배 정도

1960 ~ 80 — kB 단위 의 *치열함

1965 : 4 KB    (PDP-8)
1981 : 64 KB   (IBM PC)
1990 : 8 MB    (일반 PC)

이 시대 의 기술 :

  • 수동 *메모리 관리
  • 오버레이 — 큰 프로그램 을 작은 메모리 에 *조각 으로 *실행
  • swap 의 *진심 — 디스크 *왕복 비용 허용
  • 압축 코드 / *bit packing

1990 ~ 2010 — MB → GB 로 *폭증

2000 : 256 MB  (일반 PC)
2010 : 8 GB    (일반 PC)

메모리 가 *풍부 해지자 :

  • GC 언어 의 *대중화 (Java 1995, C# 2002)
  • 객체지향 의 *확산 — 추상 비용 허용 가능
  • 프레임 워크 의 *비대화 — Spring, .NET, Ruby on Rails

위기 : 메모리가 *충분 하니 *낭비 적 코드 가 *기본 — 후일 의 *시스템 운영 의 *비용. unbounded cache, 느린 ORM, N+1 query — 2010 년 대 *Java 의 *흔한 문제.

2010 ~ 현재 — DDR5 + ECC + HBM

2020 : DDR4 — *클라이언트 32GB, 서버 1 TB*
2023 : DDR5 — *클라이언트 64GB, 서버 8 TB*
2025 : HBM3e (GPU 측) — *대역폭 1 TB/s*

위기 의 새 형태 :

  • GC pause 가 *큰 heap 에서 *치명적 (어제 글 의 ZGC 등장 배경)
  • NUMA — 멀티 소켓 환경의 *메모리 접근 *불균등 비용
  • In-memory DB (Redis, Memcached, SAP HANA) — 분산 캐시 의 표준화

메모리는 커진 *그만큼 *새 *문제 를 *낳았다.

4. HDD 발전사 — 느림과 *함께 *50 년

1956 ~ 90 — 큰 자석 디스크 시대

1956 : IBM 350 — *5 MB, *세탁기 크기*
1980 : Seagate ST-506 — *5 MB, *PC 시장*
1995 : 1 GB HDD — *일반 PC*
2005 : 500 GB
2025 : 30 TB+

HDD 의 *물리적 한계

  • Sequential : 수십 MB/s → 최근 200 MB/s — 비교 적 *향상
  • Random : 5 ~ 10 ms latency, 100 IOPS — 50 년 거의 *변화 없음

이 부동의 한계 가 소프트웨어 의 *수많은 *우회 를 만듦 :

  • DB 의 *B-Tree 인덱스 — random 을 *어떻게 *최소 화
  • LSM Tree — random write → sequential write 변환
  • Page cache 의 *역할
  • Write-Ahead Log — 순차 쓰기 후 *체크포인트
  • Buffer Pool — 메모리 의 *디스크 대리

→ HDD 의 *느림 이 DB 와 OS 설계의 *수십 년 *지배자.

5. SSD 등장 — 2008 ~ *디스크 *혁명

발전사

2008 : MLC SSD — *80 GB / $500
2011 : SATA SSD 일반화 — *수십 만 IOPS
2014 : NVMe 등장 — *100 µs latency
2020 : PCIe 4.0 NVMe — *7 GB/s
2024 : PCIe 5.0 NVMe — *14 GB/s, *2M IOPS
2025 : Optane / 3D XPoint 의 *대안 발전*

SSD 가 *불러온 *새 *기회 와 *새 위기

기회 :

  • Random IOPS 의 *제약 *사라짐
  • 작은 random read 가 *수십 µs 안
  • DB 의 *재 설계 가능 — 디스크 *경계 *완화

새 위기 :

  • Write 가 *마모 를 가짐 — Wear Leveling, GC, TRIM 의 *추가 복잡도
  • Power Loss Protection — 캐시 데이터 보존
  • Filesystem 이 *SSD 친화 로 재설계 필요 (ext4, btrfs, ZFS, F2FS)
  • DB 의 *옛 가정 (random 비용 최소화) 가 과한 우회 가 됨 — 오히려 성능 *저하 가능

SSD 는 옛 위기를 *해소 하면서 새 위기를 *불러온다. 기술 변화 의 *공통 패턴.

6. 위기 의 *형태 — 각 시대 마다 *다르다

1960 년대 — 기계 어 직접 작성 의 위기

→ 해결 : 고급 언어

1970 ~ 80 — 프로젝트 비대화 의 *위기

→ 해결 : 구조적 프로그래밍, *모듈화, *RDB 모델

1990 ~ 2000 — 분산 시스템 / 인터넷 의 *위기

→ 해결 : 객체지향, *디자인 패턴, *3-tier 아키텍처

2005 ~ 15 — 멀티 코어 의 *위기

→ 해결 : 함수형 (Scala / Clojure / Haskell 인기), *Actor 모델 (Erlang / Akka), *Goroutine, *async / await

2015 ~ 25 — 클라우드 / MSA 의 *위기

→ 해결 : 컨테이너, *Kubernetes, *서비스 메시, *eventual consistency

2025 ~ — AI 시대 의 *위기 (진행 중)

→ 해결 시도 : vibe coding, *LLM 기반 자동 코드 생성, *Agentic 시스템, Edge AI

7. Brook 의 *No Silver Bullet

1986 년, Frederick Brooks 가 유명한 논문 “No Silver Bullet — Essence and Accidents of Software Engineering” 발표 :

“앞으로 *10 년 안 에 소프트웨어 생산성 을 10 배 올릴 단일 기술 은 없다. 어려움 의 *본질 이 복잡도, *변경 가능성, *비가시 성, *적합성 에서 나오기 때문 이다.”*

Brook 의 *옳음 / 그름

지난 40 년 을 보면 :

  • 틀린 부분 — AI / LLM 이 *2024 년 *부터 *생산성을 *체감 *2~3 배 올리는 중. *Brook 의 *예언 이 드디어 *깨질 가능성.
  • 맞은 부분 — 본질 적 *복잡도 (변하는 요구사항, 도메인 의 어려움) 는 *여전히 *그대로. 어떤 도구 도 *완전 해결 못 함.

→ 소프트웨어 의 *본질 이 아직도 *위기 안 에 있다.

8. 지금 의 *위기 — AI 시대 의 *복잡성

2025 ~ 현재 의 *새 위기 의 *형태

  • AI 가 *코드 를 만든다 — 사람 이 *읽고 *판단하는 시간이 *증가
  • Cloud / Edge / Mobile / IoT 의 *동시 운영 — 멀티 환경 *복잡도
  • 보안 + 프라이버시 + 규제 — 코드 외 부 의 *요구 들이 *비대화
  • 공급망 (npm / Maven / pip) 의 위협 — 간접 *의존성 *공격
  • 모델 운영 (MLOps) — *모델 + 데이터 + 코드 + 인프라 의 *4 차원

이 모든 것 이 옛 위기 와 *다른 *형태. 각 시대 의 위기 와 *마찬가지 로 — 적응 의 *경주 가 계속.

9. 60 년 의 *주기적 *교훈

위기 의 반복 에서 읽히는 *공통 패턴 :

  1. 하드웨어 의 *도약* 이 *새 위기 의 *원인 — *변화 의 *속도 가 *소프트웨어 의 *적응 속도 *를 *초과.
  2. 위기 의 *해결 이 *새 위기 의 *원인 — 객체지향 이 *멀티코어 위기 를 불렀고, 클라우드 가 분산 시스템 위기를 *불렀다.
  3. **Silver Bullet 은 *없다 — Brook 의 *고전적 *진단 이 여전히 *유효.
  4. 인간 의 *복잡도 처리 능력* 이 *진짜 *상한선 — *추상 + 도구 + 협업 의 총합 이 경쟁 력.

10. 백엔드 엔지니어 의 *시야

본인 7 년차 *시점 에서 본 위기의 *현실:

내가 직접 본 *위기 의 *형태

  • 메모리 부족 — 작은 *서비스 의 OOM, *GC pause. 어제 글 의 메모리 / GC 와 직결.
  • 디스크 IOPS — HDD 에 *ES 깐 *비상. NVMe 로 *옮기자 *해결.
  • CPU bound — JSON 직렬화, *암호화, *대용량 *처리.
  • 분산 시스템 의 복잡도 — eventual consistency, *분산 락, *retry storm.
  • AI 시대 의 적응 — Copilot, *Cursor, *Claude, *벡터 DB 등 *매주 새 도구.

직접 경험한 *대응

  • 옛 기술 + 새 기술 의 *동시 활용
  • 하드웨어 *제약 *직 접 측정
  • 추상 의 *과 다 를 경계
  • 팀 의 *공통 언어 *유지
  • 지속 적 *학습 + 시도 + *폐기

11. 마치며

소프트웨어 위기는 *60 년 *전 *시작 되었고 현재 진행 중. 각 시대 의 *위기 의 *모습은 *다르지만 *본질 은 같다 — *변화의 *속도 와 *적응의 *속도 *간 *격차.

3 줄 요약 :

  1. CPU / Memory / HDD / SSD 의 발전 *각 단계 가 새 위기 를 *낳았다 — 위기 의 원인 은 *진보 자체.
  2. 위기 의 *해결 은 *다음 위기 의 *원인 — *객체지향 → 분산 → 클라우드 → AI 의 *연쇄.
  3. Silver Bullet 은 없지만 *적응 의 *경주 는 계속 — 깊은 *기본 + *빠른 *학습 의 조합 이 생존 력.

7 년차 백엔드 엔지니어 의 회고 :

“위기를 *없애려 *애쓰지 *마라. 위기 와 *공존 하는 능력 이 직업 의 *깊이.”*

다음 글 — AI 시대의 *소프트웨어 *재정의 — vibe coding, *Agent, *Auto-debug 의 *변화 의 *깊이. 같은 시리즈 로 이어 집니다.

본 글은 7년차 백엔드 엔지니어 의 *역사 / 시야 회고. 역사 사실 은 *문헌 기반. 해석 은 *내 *시각. 다른 *전문가의 *해석 도 *존중 *받을 수 있다. 위기 의 *본질 은 각자 *경험 하는 *현실 의 *총합.