모든 엔지니어링 팀은 적어도 한 번쯤 '제 컴퓨터에서는 되는데요(It works on my machine)'라는 말을 해봤을 것입니다.

이 문구는 소프트웨어 업계에서 일종의 농담거리가 되었지만, 실제 운영 환경(production)에서 발생할 때는 결코 재미있지 않습니다.

어떤 기능은 모든 로컬 테스트를 통과하고, 풀 리퀘스트(pull request)도 승인되며, 배포(deployment)도 성공적으로 완료됩니다. 그러고 나서 사용자들은 실패 사례들을 보고하기 시작합니다.

온콜 엔지니어들(on-call engineers)에게 페이지 알림이 오고, 인시던트 채널(Incident channels)은 가득 차게 됩니다. 작성하는 데 10분밖에 걸리지 않았을 수정 사항 하나를 추적하는 데는 아무도 알아차리지 못한 누락된 환경 변수(environment variable)나 런타임 버전 불일치(runtime version mismatch) 때문에 4시간이 걸리기도 합니다.

이상한 점은 이것이 여전히 2026년에도 발생한다는 것입니다.

현대 개발은 그 어느 때보다 좋은 도구들을 갖추고 있습니다. 컨테이너(Containers), 자동화 테스트, 클라우드 인프라, CI/CD 파이프라인, 코드형 인프라(infrastructure as code), 그리고 AI 코딩 어시스턴트까지 모든 것이 소프트웨어 구축을 상당히 빠르게 만들었습니다.

그럼에도 불구하고 고객에게 서비스를 제공하는 애플리케이션을 운영하는 엔지니어링 팀들은 개발자 노트북 외부에서만 나타나는 버그를 추적하느라 여전히 상당한 시간을 잃고 있습니다.

industry survey에 따르면, 개발자들이 기능 작성과 무관한 작업에 시간을 할애하는 비율은 약 40%이며, 환경 디버깅(environment debugging)이 주요 원인 중 하나입니다.

문제의 원인이 엔지니어들이 부주의해서가 아닙니다. 대부분의 소프트웨어는 나쁜 코드 때문에 실패하지 않습니다. 코드는 환경 안에서 실행되기 때문이고, 이 환경들은 거의 동일한 경우가 드뭅니다.

개발자 노트북과 운영 클러스터(production cluster) 사이의 격차는 오늘날에도 가장 일관된 엔지니어링 낭비의 원인 중 하나입니다.

진짜 질문은 더 이상 이 문제가 왜 존재하는가 하는 것이 아닙니다. 숙련된 모든 엔지니어링 팀은 환경 드리프트(environment drift)를 이해합니다. 더 나은 질문은 왜 그렇게 많은 제품팀이 여전히 이를 관리하는 데 엔지니어링 시간을 쓰고 있는가입니다.

모든 기계는 약간씩 다른 이야기를 한다

운영 애플리케이션은 소스 코드보다 훨씬 많은 것에 의존합니다.

이는 운영 체제(Operating System), 런타임 버전(Runtime versions), 환경 변수(Environment variables), 데이터베이스(Databases), 제3자 서비스(Third-party services), 네트워킹 규칙(Networking rules), 파일 권한(File permissions), 설치된 라이브러리(Installed libraries), 그리고 CPU 아키텍처(CPU architecture)에 따라 달라집니다.

Node.js 24 LTS를 실행하는 개발자는 여전히 22 버전을 사용하는 팀원과 협업하고 있을 수 있습니다. 어떤 노트북에는 간접 의존성(Transitive dependency) 업데이트로 인해 더 최신 버전의 OpenSSL이 설치되어 있을 수도 있습니다. 또 다른 노트북에는 3개월 전의 캐시된 빌드 아티팩트 (build artefact)가 있어, 라이브러리 패치 이후 조용히 동작이 변경되었을 수도 있습니다.

이러한 차이점들은 개별적으로 보면 그리 중요해 보이지 않습니다. 하지만 이들이 모이면 파이프라인 내의 다른 모든 환경과 다르게 동작하는 로컬 환경을 만들어냅니다.

이것이 바로 테스트 스위트(Test suite)가 개발자의 머신에서는 통과(Green)되다가 20분 후 CI(지속적 통합) 환경에서는 실패하는 방식입니다. 또한 애플리케이션이 macOS에서는 깔끔하게 부팅되지만, 클라우드 제공업체가 실행하는 Debian 컨테이너에서는 충돌(Crash)이 발생하는 방식이기도 합니다.

지난 화요일에는 초당 500개의 요청을 처리하던 마이크로서비스(Microservice)가, 관련 없어 보이는 의존성 업데이트(Dependency bump) 이후 이번 월요일부터 타임아웃(Timeout)이 발생하기 시작하는 이유이기도 합니다.

코드는 변하지 않았습니다. 환경이 변한 것입니다.

의존성은 움직이는 타겟이다

패키지 매니저(Package managers)는 소프트웨어 개발을 생산적으로 만들었지만, 실행 중인 애플리케이션의 표면적(Surface area) 또한 극적으로 넓혔습니다.

오늘날 전형적인 Node.js 웹 애플리케이션은 개발자가 명시적으로 몇 가지만 설치하더라도, 간접 의존성을 포함하여 의존성 트리(Dependency tree) 내에 500개에서 1,500개 사이의 패키지를 보유하고 있습니다.

일반적인 데이터 처리 및 웹 프레임워크를 사용하는 Python 서비스는 200개에서 400개의 패키지를 끌어올 수 있습니다. 대부분의 엔지니어는 자신의 애플리케이션이 배포하는 패키지의 대다수와 직접적인 관계가 없습니다.

의존성 버전 (dependency versions)이 올바르게 잠기지 않으면, 같은 날 같은 프로젝트를 설치하는 두 개발자가 실질적으로 다른 소프트웨어 스택 (software stacks)을 받게 될 수 있습니다. package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock과 같은 락 파일 (Lock files)은 바로 이러한 상황을 방지하기 위해 존재하며, 실제로 도움이 됩니다. 하지만 이는 훨씬 더 큰 일관성 문제의 한 단계에 불과한 제어 수단입니다.

런타임 버전 (Runtime versions)은 여전히 다릅니다. 시스템 라이브러리 (System libraries)도 여전히 다릅니다. 컨테이너의 베이스 OS 이미지 (Base OS images)는 패치 주기 (patch cycles)에 따라 변합니다. 오늘 node:22로부터 빌드된 Docker 이미지는, 업스트림 태그 (upstream tag)가 업데이트된 6주 후에 빌드되는 이미지와 동일하지 않습니다. 베이스 이미지 (base images)를 정확하게 고정 (pin)하지 않는 팀은 모든 배포의 기초 단계에서 환경 드리프트 (environment drift)를 자신도 모르게 수용하고 있는 것입니다.

설정이 코드보다 더 많은 장애를 일으킨다

엔지니어링 팀에서 발생하는 가장 파괴적인 운영 장애 (production incidents) 중 상당수는 프로그래밍 로직 (programming logic)과 아무런 관련이 없습니다.

그것들은 설정 (configuration)에서 비롯됩니다.

새로운 배포 대상에서 환경 변수 (environment variable)가 누락되었습니다. 데이터베이스 연결 문자열 (database connection string)이 운영 (production) 환경이 아닌 스테이징 (staging) 환경을 가리키고 있습니다. 피처 플래그 (feature flag)가 개발자의 .env 파일에서는 true로 설정되어 있지만, 배포된 서비스에서는 기본값이 false로 되어 있어 중요한 코드 경로 (code path)를 조용히 비활성화합니다. API 키가 교체되었지만, 시크릿 매니저 (secret manager) 참조가 한 환경에는 업데이트되었으나 다른 환경에는 업데이트되지 않았습니다.

이러한 실수들은 흔하며, 실제로 방지하기가 매우 어렵습니다. 왜냐하면 설정은 애플리케이션 외부에 존재하기 때문입니다. 설정은 별도로 관리되고, 일관성 없이 문서화되며, 표준 테스트 스위트 (test suites)에 의해 거의 다뤄지지 않습니다.

장애 사후 검토 (Post-incident reviews)를 진행해 보면, 애플리케이션 코드는 완전히 정상적으로 보였기 때문에 진단에 몇 시간이 걸렸던 장애의 근본 원인으로 설정 드리프트 (configuration drift)가 정기적으로 드러납니다.

이 문제는 환경 전반에 걸쳐 심화됩니다. 개발 (development), 스테이징 (staging), 프리 프로덕션 (pre-production), 그리고 운영 (production) 환경을 실행하는 팀은 일관성을 유지해야 할 네 개의 별도 설정 상태를 가지게 됩니다.

엔지니어가 새로운 환경 변수 (environment variable)를 추가할 때, 그 변경 사항은 모든 환경에 신뢰할 수 있는 방식으로 전파되어야 합니다. 하지만 실제로는 그렇지 않은 경우가 많습니다. 하나의 환경이 누락됩니다. 오래된 값이 남아 있습니다. 애플리케이션이 다르게 동작하며, 조사는 처음부터 다시 시작됩니다.

여러 환경을 관리하는 데 드는 실제 비용

엔지니어링 리더십은 환경 관리(environment management)에 얼마나 많은 시간이 소비되는지를 종종 과소평가합니다. 이는 관찰하기 어려워서가 아니라, 명시적인 항목으로 나타나지 않는 수십 개의 작은 작업들로 분산되어 있기 때문입니다.

누군가는 기본 Docker 이미지의 Node 런타임 (runtime)을 업데이트했다가, 나중에 알고 보니 전이적 의존성 (transitive dependency) 불일치로 밝혀진 하위 테스트 실패를 추적하며 오후 시간을 허비합니다.

누군가는 새로운 스테이징 (staging) 환경을 프로비저닝 (provisioning)하고, 프로덕션 (production) 설정을 수동으로 복제하느라 하루를 보냅니다. 누군가는 자격 증명 (credentials)을 교체하다가 하나의 서비스를 놓쳐, 다음 배포 주기까지 드러나지 않는 조용한 실패 (silent failure)를 유발합니다. 누군가는 팀에 합류하여 업무를 수행하는 대신, 로컬 환경을 실행하는 데 첫 이틀을 보냅니다.

엔지니어링 생산성 연구의 추정치에 따르면, 자체 배포 인프라를 소유한 기업의 경우 인프라 및 환경 관련 작업이 전체 엔지니어링 역량의 1525%를 소비합니다. 10명의 엔지니어로 구성된 팀의 경우, 이는 사실상 23명의 인원이 고군분투하며 고객에게 전달할 결과물을 만들어내지 못하고 있음을 의미합니다.

이것은 스프린트 보드 (sprint boards)에 나타나지 않는 비용입니다. 이는 Slack 스레드, 장애 회고 (incident retrospectives), 그리고 팀이 마땅히 그래야 하는 것보다 느리다는 조용한 인정 속에 존재합니다.

이러한 작업 중 그 어느 것도 로드맵 (roadmap)에 나타나지 않습니다. 고객은 이를 요구하지 않습니다. 이는 차별화를 만들어내지 못합니다. 그럼에도 제품 팀은 소프트웨어를 배포 가능한 상태로 유지하기 위해 단순히 환경 간의 일관성을 유지하는 데 매년 수백 시간의 엔지니어링 시간을 소비합니다. 환경 드리프트 (Environment drift)는 단순한 신뢰성 문제가 아닙니다. 그것은 엔지니어링 역량의 문제입니다.

왜 팀들은 2026년에도 여전히 이를 직접 관리하고 있는가?

이 모든 상황을 고려할 때, 합리적인 의문은 왜 그렇게 많은 엔지니어링 팀들이 여전히 이러한 복잡성을 직접 떠안고 있느냐는 것입니다.

답의 일부는 관성 (Inertia)에 있습니다. Kubernetes가 모든 확장성 문제에 대한 명확한 해답이었고 "우리가 직접 스택을 제어한다"는 것이 경쟁 우위처럼 느껴졌던 몇 년 전 인프라를 구축한 팀들은, 이제 그것을 변경하는 데 비용이 들기 때문에 해당 인프라를 계속 유지하고 있습니다.

이미 투자가 이루어졌습니다. 도구 (Tooling)가 이미 익숙합니다. 고통이 급성(Acute)이기보다는 분산되어 있고 만성적(Chronic)이기 때문에, 문제를 해결하기보다 그냥 받아들이는 것이 더 쉬워졌습니다.

답의 일부는 조직적 습관 (Organisational habit)입니다. 인프라를 관리하기 위해 플랫폼 엔지니어나 DevOps 엔지니어를 채용하는 것은 환경 문제에 대한 적절한 대응처럼 느껴집니다. 하지만 그 엔지니어는 제품의 레버리지 (Product leverage)를 제공하는 대신, 무기한으로 일관성 계층 (Consistency layer)을 유지해야 하는 책임을 지게 됩니다. 베이스 이미지 (Base images) 패치, 런타임 (Runtime) 버전 업데이트, 인증서 갱신 관리, 그리고 환경 전반에 걸친 네트워킹 이슈 디버깅 등에 매달리게 됩니다.

답의 일부는 더 많은 제어권이 더 나은 결과를 만들어낸다는 믿음입니다. 자체 인프라를 운영하면 모든 구성 결정 (Configuration decision)에 대해 완전한 가시성을 확보할 수 있습니다.

하지만 완전한 제어는 완전한 책임을 의미하기도 합니다. 플랫폼 팀이 내리는 모든 결정은 플랫폼 팀이 유지 관리하고, 문서화하며, 상류 (Upstream)에서 무언가 변경될 때마다 다시 검토해야 하는 결정이 됩니다.

대부분의 제품 엔지니어링 팀은 인프라 비즈니스를 하는 곳이 아닙니다. 그들은 고객을 위한 소프트웨어를 만드는 비즈니스를 하고 있으며, 환경 일관성 (Environment consistency)에 소비되는 모든 시간은 그 일에 쓰이지 못하는 시간입니다.

솔직한 답변은 많은 팀이 이 복잡성을 직접 관리하고 있는 이유가, 아직 이를 멈출 수 있는 명확한 경로를 찾지 못했기 때문이라는 것입니다.

로컬의 성공은 운영 환경의 상태를 반영하지 않는다

한 가지 일관된 실패 모드 (Failure mode)는 로컬 테스트 통과를 배포가 안전하다는 신호로 취급하는 것입니다.

운영 환경 (Production environments)은 개발용 머신에서는 결코 마주할 수 없는 조건들을 강요합니다. 동시 접속 사용자가 없는 노트북에서 깔끔하게 시작되는 서비스는, 세 개의 애플리케이션 인스턴스가 공유 데이터베이스 커넥션 풀 (Connection pool)을 두고 경쟁하며 초당 2,000개의 요청을 처리할 때와는 다르게 동작할 것입니다.

로컬에서는 밀리초 단위로 완료되는 백그라운드 작업 (Background job)이라도, 실제 쓰기 부하 (Write load)가 걸려 있는 데이터베이스를 대상으로 다른 12개의 작업과 동시에 실행될 때는 운영 환경에서 타임아웃 (Timeout)이 발생할 수 있습니다.

스테이징 환경 (Staging environments)은 이러한 차이점들이 사용자에게 도달하기 전에 드러내기 위해 존재합니다. 하지만 스테이징은 동일한 인프라 (Infrastructure), 동일한 런타임 버전 (Runtime versions), 동일한 구성 형태 (Configuration shape), 동일한 네트워크 토폴로지 (Network topology)와 같이 실제로 운영 환경과 유사할 때만 가치를 제공합니다.

많은 팀이 스테이징을 '최선을 다한 근사치' 정도로 취급합니다. 시간이 흐름에 따라 스테이징과 운영 환경 사이의 구성 드리프트 (Configuration drift)가 발생하면, 스테이징은 원래 잡아내도록 설계된 실패들을 더 이상 잡아내지 못하게 됩니다. 결국 팀들은 환경 관련 문제를 운영 환경에서 발견하게 되는데, 이는 문제를 발견하기에 가장 최악의 장소입니다.

3~4개의 환경 전체에 걸쳐 진정한 패리티 (Parity)를 유지하는 것은 비용이 많이 들며 지속적인 주의를 필요로 합니다. 인프라 업데이트는 균일하게 적용되어야 합니다. 런타임 버전은 동기화된 상태를 유지해야 합니다. 구성 (Configuration)은 신뢰할 수 있게 전파되어야 합니다.

능동적인 규율이 없다면, 스테이징은 운영 환경으로부터 멀어지게 되고 안전망은 사라집니다.

왜 더 많은 엔지니어링 팀이 관리형 플랫폼을 선택하는가?

어느 시점에 이르면, 모든 엔지니어링 조직은 더 근본적인 질문을 던져야 합니다. 환경을 유지하는 데 엔지니어링 시간을 계속 투자해야 할까요, 아니면 그 책임을 이를 위해 구축된 플랫폼으로 넘겨야 할까요?

이것이 바로 이전에 자체적으로 인프라를 관리하던 팀들에게 Platform as a Service (PaaS)가 더 진지한 고려 대상이 된 맥락입니다.

잘 설계된 PaaS는 엔지니어링의 책임을 제거하는 것이 아닙니다. 그것을 재배치하는 것입니다.

개발자들은 여전히 코드를 작성합니다. 여전히 환경 변수(environment variables)와 빌드 프로세스(build processes)를 정의합니다. 여전히 자신의 애플리케이션에 무엇이 필요한지 결정합니다. 차이점은 플랫폼이 팀이 기반 인프라(underlying infrastructure)를 소유하지 않고도 개발(development), 스테이징(staging), 프로덕션(production)과 같은 모든 환경에 걸쳐 일관되고 유지 관리되는 런타임(runtime)을 제공한다는 점입니다.

동일한 애플리케이션 정의가 어디에서나 실행됩니다. 환경 패리티(Environment parity)는 팀이 지속적으로 강제해야 하는 규율이 아니라 플랫폼의 속성이 됩니다.

이는 실제 배포 속도(deployment velocity)가 빠른 엔지니어링 팀, 즉 하루에도 여러 번 배포하고, 여러 서비스를 실행하며, 배포가 예측 가능할 것이라는 기대치 하에 운영되는 팀에게 가장 중요합니다.

플랫폼이 환경을 표준화하면 배포는 더 이상 실험이 아닙니다. 엔지니어들은 최악의 타이밍에 프로덕션 전용 장애(production-only failures)를 발견하는 일을 멈추게 됩니다.