소프트웨어 개발에서 우리 예절이 사라지고 있나요?

Source: Dev.to

위의 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 기술 용어는 그대로 유지됩니다.)

Introduction

소프트웨어를 오래 쓸수록 “인상적”이라는 감각이 변합니다. 요즘 저를 실제로 놀라게 하는 것은 최신 기술이 아니라 오래된 시스템과 그것을 만든 사람들입니다.

Take Windows 95: a full operating system from almost 30 years ago with GUI, drivers, multitasking, multimedia, process and thread management—all of it lived in roughly 50 MB on disk and ran on 4–8 MB of RAM.

Now compare that to today. The browser tab I’m using to type this text currently takes over 1 GB of memory. I’m not compiling anything. I’m not rendering video. I’m just editing text.
오늘날과 비교해 보세요. 현재 이 텍스트를 입력하고 있는 브라우저 탭은 1 GB가 넘는 메모리를 사용합니다. 저는 아무것도 컴파일하지도 않고, 비디오를 렌더링하지도 않습니다. 단지 텍스트를 편집하고 있을 뿐입니다.

That number alone would horrify engineers from the 1980s — people who ran full multi‑user Unix environments on machines with 2 MB of RAM and 20 MB hard drives. Entire development workflows — editors, compilers, networking, users — fit inside constraints that feel impossible now.
그 숫자만으로도 1980년대 엔지니어들을 깜짝 놀라게 할 것입니다— 2 MB RAM과 20 MB 하드 드라이브를 가진 머신에서 전체 멀티유저 Unix 환경을 운영하던 사람들 말이죠. 전체 개발 워크플로우—편집기, 컴파일러, 네트워킹, 사용자—가 지금은 불가능해 보이는 제약 안에 들어맞았습니다.

Even small things today feel heavy. A simple “Hello, World” after activating a virtual environment can easily pull in tens of megabytes of libraries before any real logic runs. Not because the problem is complex, but because the ecosystem around it is.
오늘날에도 작은 것들이 무겁게 느껴집니다. 가상 환경을 활성화한 뒤 간단한 “Hello, World”조차도 실제 로직이 실행되기 전에 수십 메가바이트의 라이브러리를 쉽게 끌어옵니다. 문제가 복잡해서가 아니라, 그 주변 생태계가 복잡하기 때문입니다.

사라지는 규율

내가 놀란 것은 하드웨어가 빨라진 것이 아니라—그것은 필연이었으니까. 내가 놀란 것은 풍요로움이 우리의 행동을 바꾼 방식이다. 우리는 소프트웨어 매너를 잃었다.

희소성이라는 제약은 한때 암묵적인 행동 규범을 강제했다:

• 메모리는 귀중했다 — 스스로 정리했다
• 모든 사이클이 중요했다 — 루프를 돌기 전에 생각했다
• 의존성은 얻어야 했다 — 사소한 작업에 라이브러리를 함부로 끌어오지 않았다
• 추상화는 이해했다 — 내부에서 무슨 일이 일어나는지 알았다

옛 시스템은 마법이 아니었다. 제약이 있었고, 그 제약이 규율을 강요했다. 우리는 그 규율을 편리함과 교환했다.

전문가 패러독스

런타임에 리소스(그리고 비용)를 소모하는 방대한 라이브러리, 클라우드 SDK, 추상화 레이어를 사용하지 않으면, Developer B에게 밀려날 위험이 있습니다. Developer B는 “전달자”이며, 결과는 신경 쓰지 않고 빠르게 배포합니다!

신중한 장인 정신에 불리하게 작용하는 지표들은 다음과 같습니다:

• 속도 > 효율
• 출시된 기능 > 소모된 리소스
• 시장 진입 시간 > 기술 부채 고려
• 프레임워크 친숙도 > 기본 원리 이해

우리는 가장 “생산적인” 개발자가 추상화 위에 추상화를, 의존성 위에 의존성을 쌓아 전체 구조가 너무 부풀어 하드웨어 업그레이드가 필요할 정도가 되고, 클라우드 비용이 급증하는 세상을 만들었습니다.

무례함의 비용

이것은 단순한 향수가 아닙니다. 그 결과는 현실적입니다:

• 환경 영향 – 단순한 작업을 수행하는 비효율적인 소프트웨어를 실행하기 위해 메가와트를 태우고 있습니다
• 접근성 저하 – 최신 하드웨어를 요구하는 소프트웨어는 구형 기기를 사용하는 사용자를 배제합니다
• 보안 취약성 – 의존성 층이 공격 표면을 만들지만 우리는 이를 충분히 이해하지 못합니다
• 혁신 정체 – 모든 에너지를 부풀린 유지보수에 쏟아부면 진정한 돌파구를 위한 여력이 남지 않습니다

2 MB PDP‑11에서 C++를 만든 엔지니어들은 단순히 영리했을 뿐만 아니라 사려 깊었습니다. 그들은 하드웨어, 다음 프로그래머, 사용자의 자원을 고려했습니다. 그 고려는 그들의 전문 윤리였습니다.

매너 재학습

그래서 맞아요, 우리는 매너를 잃어가고 있습니다. 하지만 매너는 다시 배울 수 있습니다. 작은 배려의 행동에서 시작됩니다:

• 질문 의존성 – “간단한 작업에 이 50 MB 라이브러리가 정말 필요할까?”
• 끊임없이 프로파일링 – 코드가 실제로 무엇을 하는지, 당신이 생각하는 것이 아니라
• 한 단계 아래 이해하기 – 추상화 아래에서 무슨 일이 일어나는지 알기
• 효율성 옹호 – 성능을 부가 기능이 아니라 핵심 기능으로 만들기

가장 인상적인 소프트웨어는 가장 많은 자원을 사용하는 것이 아니라, 가장 적은 자원으로 가장 많은 것을 이루는 것입니다. 그 규율, 그 배려, 기계와 사용자에 대한 전문적인 예의—이것이 우리가 되찾아야 할 것입니다.

결국 소프트웨어 개발은 단순히 컴퓨터에게 일을 시키는 것이 아니라, 제한된 자원의 세계에서 우리가 어떻게 존재할지를 선택하는 일입니다. 좋은 매너는 삶에서 그렇듯 코드에서도 똑같이 중요하다는 사실이 드러납니다.