개발 환경 지옥 탈출기: '내 컴퓨터에선 되는데요?'를 없애줄 Nix 알아보기

개발 환경 지옥 탈출기: '내 컴퓨터에선 되는데요?'를 없애줄 Nix 알아보기

"제 컴퓨터에서는 잘 되는데요."

개발자라면 이 말처럼 등골을 서늘하게 만드는 말이 또 있을까요.

팀원마다 다른 라이브러리 버전, 운영체제에 따라 미묘하게 달라지는 설정, 그리고 내 컴퓨터에서는 잘만 되던 빌드가 CI/CD 파이프라인에서는 실패하는 절망적인 상황은 우리에게 너무나도 익숙한 풍경입니다.

그런데 만약, 이 모든 혼돈을 끝내고, 개발부터 배포까지 모든 환경을 100% 동일하게 복제할 수 있는 기술이 있다면 어떨까요.

최근 개발 도구에 깊은 관심을 가진 개발자들 사이에서 '궁극의 도구'로 불리며 조용하지만 강력하게 퍼져나가고 있는 기술, 바로 Nix에 대한 이야기입니다.

오늘은 Nix가 무엇이고, 어떻게 이 지긋지긋한 "내 컴퓨터에선 되는데요?"라는 말을 없애주는지, 그 원리와 실제 활용 사례까지 깊이 있게 파헤쳐 보겠습니다.

1. Nix란 무엇인가? 세 가지 얼굴을 가진 삼위일체

Nix는 한마디로 정의하기 어려운 복합적인 기술입니다.

크게 세 가지 요소가 서로를 기반으로 쌓아 올려진 '삼위일체'와 같은 구조를 가지고 있는데요.

첫 번째 얼굴: 닉스(Nix) 언어, 모든 것의 설계도

가장 근본이 되는 것은 바로 '닉스 언어'입니다.

이것은 소프트웨어를 어떻게 빌드하고 구성할지를 정의하기 위해 만들어진, 특별한 목적을 가진 함수형 프로그래밍 언어입니다.

문서가 부족하고 에러 메시지가 불친절하기로 악명이 높지만, 일단 익숙해지면 어떤 소프트웨어든 완벽하게 '재현 가능하도록' 만드는 강력한 힘을 발휘합니다.

닉스 코드로 작성된 하나의 빌드 레시피를 '파생(Derivation)'이라고 부르는데, 이것이 바로 모든 재현성의 핵심 설계도입니다.

두 번째 얼굴: 닉스 패키지 매니저, 레시피를 현실로 만드는 요리사

닉스 언어 위에는 '닉스 패키지 매니저'가 있습니다.

이것은 apt나 brew와 같은 일반적인 패키지 매니저처럼 소프트웨어를 설치해주는 도구입니다.

하지만 결정적인 차이점이 있습니다.

닉스는 미리 컴파일된 바이너리를 그냥 가져오는 것이 아니라, 'nixpkgs'라는 거대한 레시피 모음집(Git 저장소)에서 원하는 소프트웨어의 설계도(파생)를 가져와, 당신의 컴퓨터에서 그 레시피 그대로 소프트웨어를 직접 빌드합니다.

이 과정에서 생기는 모든 결과물은 '닉스 스토어(/nix/store)'라는 특별한 공간에 저장되는데요.

이 닉스 스토어는 각 소프트웨어의 모든 의존성을 해시(hash)값으로 관리하기 때문에, 똑같은 파이썬이라도 의존성이 다르면 완전히 별개의 것으로 취급하여 격리합니다.

덕분에 시스템에 여러 버전의 복잡한 라이브러리가 충돌 없이 공존하는, 마법 같은 일이 가능해집니다.

세 번째 얼굴: 닉스OS(NixOS), 시스템 전체를 코드로 정의하다

이 모든 것의 정점에는 바로 '닉스OS'가 있습니다.

닉스OS는 운영체제 전체를 단 하나의 거대한 닉스 코드로 정의합니다.

단순히 어떤 소프트웨어를 설치할지를 넘어, 셸 프롬프트는 어떻게 생겼는지, 시스템 서비스는 어떻게 설정되어 있는지 등 모든 구성(configuration)까지 코드로 관리합니다.

이것의 의미는 실로 엄청납니다.

내 노트북의 운영체제를 정의하는 닉스 코드를 그대로 다른 컴퓨터나 서버에서 실행하면, 데이터를 제외한 모든 소프트웨어와 설정이 100% 동일한 시스템을 순식간에 복제할 수 있는 것입니다.

2. 말보다 코드: 닉스 파생(Derivation) 살펴보기

말로만 들어서는 이해하기 어려울 수 있습니다.

실제 닉스 코드가 어떻게 생겼는지 간단한 예제를 통해 보겠습니다.

이 코드는 presenterm이라는 러스트(Rust) 기반의 터미널 프레젠테이션 도구를 빌드하는 '파생'의 일부입니다.

# presenterm을 빌드하는 닉스 파생(Derivation) 예제

{ lib, rustPlatform, fetchFromGitHub, libsixels }:

rustPlatform.buildRustPackage rec {
  pname = "presenterm";
  version = "0.9.0";

  src = fetchFromGitHub {
    owner = "mfontanini";
    repo = "presenterm";
    rev = "v${version}";
    # 이 해시값이 재현성을 보장하는 핵심입니다.
    hash = "sha256-4i+WqvZz/zPjL8e7pY2gHqW5jO5d6kX8vC7eI6mN/fU=";
  };

  # 빌드에 필요한 시스템 의존성을 명시합니다.
  buildInputs = [ libsixels ];

  # ... 기타 메타데이터 ...
}

여기서 가장 중요한 부분은 바로 `hash`입니다.

닉스는 GitHub에서 소스 코드를 내려받은 후, 이 해시값과 일치하는지 반드시 확인합니다.

만약 누군가 Git 태그를 몰래 바꾸더라도, 해시값이 다르기 때문에 빌드는 실패합니다.

이처럼 모든 입력값에 대한 철저한 검증이 바로 닉스가 '완벽한 재현성'을 보장하는 비결입니다.

3. 그래서 이게 회사에서 어떻게 쓰일까요?

이토록 강력한 닉스는 실제 기업 환경에서 어떻게 활용되고 있을까요.

크게 세 가지 영역에서 그 가치를 발휘하고 있습니다.

첫 번째: 완벽하게 통일된 개발 환경

가장 일반적이고 강력한 활용 사례입니다.

팀원마다 다른 테라폼 버전, 다른 노드 버전 때문에 고통받는 문제를 근본적으로 해결합니다.

devbox와 같이 닉스 위에 만들어진 더 쉬운 도구들을 사용하면, 프로젝트에 필요한 모든 도구와 버전을 단 하나의 설정 파일로 정의할 수 있습니다.

개발자는 그저 devbox shell이라는 명령어만 실행하면, 모든 것이 완벽하게 갖춰진 격리된 개발 환경에 즉시 들어갈 수 있습니다.

"내 컴퓨터에선 되는데요?"라는 말은 이제 사라집니다.

두 번째: 총알도 막아내는 CI/CD 파이프라인

닉스를 이용해 CI/CD 파이프라인을 정의하면, 원격 서버에서 실행될 파이프라인과 100% 동일한 환경을 내 로컬 컴퓨터에서 실행해볼 수 있습니다.

코드를 푸시하고, 파이프라인이 실패하기를 기다렸다가, 다시 수정하고 푸시하는 고통스러운 과정을 겪을 필요가 없습니다.

내 컴퓨터에서 통과되면, 원격 서버에서도 반드시 통과됩니다.

세 번째: 선언적으로 관리되는 거대한 서버 군단

수천 대의 서버나 개발자들의 노트북을 관리해야 하는 IT 부서에게 닉스는 꿈의 도구가 될 수 있습니다.

Ansible이나 Packer 같은 전통적인 도구들을 대체하여, 서버의 상태 전체를 단 하나의 닉스 코드로 선언적으로 정의하고 관리할 수 있습니다.

모든 서버가 항상 동일한 상태를 유지하도록 보장하는 것입니다.

결론: 패러다임의 전환, 그러나 가파른 학습 곡선

Nix는 단순히 또 하나의 패키지 매니저나 설정 관리 도구가 아닙니다.

소프트웨어를 빌드하고 시스템을 구성하는 방식에 대한 근본적인 '패러다임의 전환'을 요구하는 철학에 가깝습니다.

물론, 그 강력함만큼이나 학습 곡선이 매우 가파르고, 아직은 모든 것이 친절하지 않은 것이 사실입니다.

하지만 개발 환경의 불일치로 인해 낭비되는 수많은 시간과 비용을 생각해 본다면, 닉스가 제시하는 '완벽한 재현성'이라는 약속은 앞으로 더 많은 기업과 개발자들이 주목할 수밖에 없는 거대한 흐름이 될 것입니다.

만약 여러분이 반복되는 환경 문제에 지쳐있다면, 지금 바로 닉스의 세계를 탐험해 보는 것은 어떨까요.

---