은탄환 – 소프트웨어 개발이 여전히 어려운 이유

Source: Dev.to

“There is no single development, in either technology or management technique, which by itself promises even one order‑of‑magnitude improvement within a decade in productivity, in reliability, in simplicity.”
— Fred Brooks, No Silver Bullet – Essence and Accident in Software Engineering

은탄환 신화

1986년을 상상해 보세요. 소프트웨어는 이미 어려웠습니다. 프로젝트는 지연되고, 예산은 폭발하며, 버그는 곳곳에 존재하고, 모두가 구원을 찾고 있었습니다—새로운 언어, 새로운 방법론, 새로운 패러다임이 마침내 소프트웨어를 쉽게 만들 것이라는 기대였습니다.

그때 Fred Brooks는 **“No Silver Bullet”**이라는 에세이를 씁니다. “은탄환”이라는 표현은 전설에서 온 것으로, 괴물을 즉시 죽이는 마법의 총알, 즉 완벽하고 깔끔한 해결책을 의미합니다. Brooks는 소프트웨어에는 그런 탄환이 없다고 주장합니다. 이것이 전체 논점입니다. 그런데 왜일까요?

우연적 어려움 vs. 본질적 어려움

Brooks는 두 종류의 어려움을 미묘하고 강력하게 구분합니다:

우연적 어려움

• 도구의 마찰: 구문, 타이핑, 보일러플레이트, 메모리 관리, 환경 설정 등.
• 이러한 고통은 우리가 사용하는 도구의 산물입니다. 도구를 개선하면 이 고통은 줄어듭니다.

시간이 흐르면서 우연적 어려움은 실제로 줄어들었습니다: 고급 언어가 어셈블리를 대체하고, 프레임워크가 반복적인 배관 작업을 대신하며, IDE가 많은 기계적 마찰을 없애고, 오늘날 AI는 몇 초 만에 전체 파일을 초안으로 만들 수 있습니다. 우연적 어려움은 계속 공격받고 있습니다.

본질적 어려움

• 소프트웨어가 복잡하고 지저분한 현실을 정확히 모델링해야 한다는 사실.
• 비즈니스는 모순된 규칙들로 가득합니다. 사용자는 예측할 수 없게 행동합니다. 요구사항은 변합니다. 엣지 케이스가 늘어납니다. 모든 시스템은 다른 시스템과 상호작용하고, 모든 추상화는 결국 누수를 일으킵니다.

현실 세계의 프로세스를 정확하고 논리적인 단계로 설명하려고 하면, 그것이 얼마나 얽혀 있는지 알게 됩니다. 그것이 괴물입니다. 타이핑 속도나 구문이 아니라, 복잡성을 모델링하기 위해 필요한 사고의 명료함이 문제입니다.

본질적 괴물

Brooks는 도구가 아무리 진보해도 본질적 복잡성을 없앨 수 없다고 주장했습니다. 도구는 기계적 작업을 부드럽게 만들 뿐입니다. 핵심 인지 부하는 문제 자체에서 나오며, 도구에서 나오지 않습니다.

현대적 맥락

오늘날 우리는 코드를 작성해 주는 AI를 가지고 있습니다. 보일러플레이트는 거의 무료이며, 반복적인 스캐폴딩은 사소합니다. 그럼에도 팀은 여전히 요구사항에 대해 논쟁하고, 시스템은 경계에서 실패하며, 아키텍처 결정은 여전히 중요하고, 트레이드오프는 존재하며, 복잡성은 계속 쌓입니다.

우리는 더 잘 무장했지만 괴물은 여전히 존재합니다. 도구는 매우 중요합니다; 도구는 병목 현상이 어디에 있는지를 이동시킵니다. 기계적 노력이 감소함에 따라 병목은 설계, 판단, 시스템 사고 쪽으로 위로 이동합니다. 이상하게도 코딩이 쉬워질수록 사고가 더 가치 있게 됩니다.

결론

“No Silver Bullet”은 비관주의가 아니라 지적 현실주의입니다. 빠른 타이핑이 복잡성을 해결한 것이 아님을 혼동하지 말라고 상기시키며, 기적을 약속하는 과대광고 사이클에 경고합니다. 소프트웨어가 어려운 이유는 현실을 모델링하는 것이 어렵고, 현실은 지저분하기 때문입니다.