원본 설정
변경된 설정

설정 파일 Diff: INI, TOML, .env 파일을 온라인에서 비교

두 설정 파일을 나란히 붙여넣고 어떤 키, 값, 주석이 바뀌었는지 정확히 확인하세요. .env, TOML, INI, .properties, .conf을 지원합니다.

설정 diff 도구란?

설정 파일을 비교하기 위한 무료 브라우저 내 도구입니다. 왼쪽에 staging .env, 오른쪽에 production 버전을 붙여넣으면 누락된 키, 변경된 값, 오래된 주석이 즉시 드러납니다. Poetry 업데이트 전후의 pyproject.toml, 곧 reload할 nginx.conf, 환경 사이를 이동하는 Java application.properties도 같은 흐름으로 처리합니다.

diff는 문자 단위로 동작합니다. 파서도, 스키마도 없고, 어떤 방언을 붙여넣었는지에 대한 가정도 없습니다. 의도된 설계입니다. 설정 파일들은 단일한 문법을 공유하지 않습니다. INI는 정식 사양이 없고 모든 파서가 quoting과 escape에 대해 의견이 다릅니다. TOML 1.0은 엄격한 문법을 가지지만 타입이 있는 값을 추가합니다. .env 파일은 사양이 아예 없으며, dotenv나 셸이 그때그때 하는 동작이 전부입니다.

단순한 텍스트 비교를 찾아오셨다면 텍스트 diff 도구가 맞습니다. YAML 설정(Kubernetes 매니페스트, Helm values, Ansible playbook)에는 YAML diff를 쓰세요. JSON으로 다루는 설정(VS Code 설정, npm package.json, Terraform tfstate)에는 JSON diff가 객체 재정렬을 텍스트 diff보다 깔끔하게 처리합니다.

diff가 실제로 동작하는 방식

diff는 문자 단위로 실행되고, 그 다음 의미적 후처리 단계가 강조 표시를 토큰 중간의 잡음이 아니라 키 전체, 값 전체, 주석 줄 전체에 떨어지도록 옮깁니다. 삽입은 오른쪽 패널에 녹색, 삭제는 왼쪽에 빨간색으로 나타납니다. 각 헤더의 변경 카운터는 알고리즘이 찾아낸 별개 편집 수를 알려줍니다.

설정 형식은 단일 파서로 모두 처리하기 어려울 만큼 다양해서, 이 도구는 의도적으로 형식 비의존적으로 남아 있습니다. .env는 가장 느슨합니다. 대부분의 로더는 오른쪽 전체를 문자열로 다루지만, 일부는 $VAR을 확장하고 일부는 그렇지 않으며, 일부는 export를 인정하고, 공백 포함 값에 대한 quoting은 파서마다 다릅니다. .properties 파일(java.util.Properties API에 문서화된 Java 표준)은 구분자로 = 또는 :을 받고 ASCII가 아닌 문자에 대해서는 \u00e9 같은 Unicode escape를 요구합니다. 실무의 INI 파일은 Windows 관행(대괄호 섹션, 세미콜론 주석)부터 Python의 configparser 모듈이 받는 약간 다른 방언까지 다양합니다.

깨끗한 diff를 신뢰하기 전에 알아두면 좋은 실전 함정 세 가지. 첫째, 줄 끝 공백. API_KEY=abc 같은 값에 줄 끝 공백 한 칸이 섞이면 대부분 로더에게는 다른 문자열이 되고, diff는 알려주지만 사람 눈으로 그 공백을 잡기는 어렵습니다. 둘째, 줄 끝 처리. Windows에서 CRLF로 커밋된 파일과 Linux에서 LF로 작성된 파일은 내용이 같아도 diff에서는 모든 줄이 변경된 것으로 보입니다. 양쪽을 포맷하거나 줄 끝을 먼저 정규화하세요. 셋째, UTF-8 byte order mark. Windows의 메모장은 저장한 .env 시작에 BOM을 무심코 써넣고, 대부분의 로더가 거기에 걸려 1번째 줄에 1글자짜리 유령 diff로 나타납니다.

세 단계로 설정 파일 비교하기

텍스트 패널 두 개, diff 하나. 업로드 없음. 로깅 없음.

  1. 1

    설정 붙여넣기 또는 업로드

    이전 설정을 왼쪽에, 새 설정을 오른쪽에 붙여넣으세요. 또는 어느 한쪽의 Upload를 클릭해 .env, .toml, .ini, .properties, .conf 파일을 직접 로드할 수 있습니다. Sample 버튼은 두 패널을 작은 .env 예제로 채워 주므로, 자기 파일을 붙이기 전에 값 변경, 새 키, 제거된 항목이 어떻게 표시되는지 미리 볼 수 있습니다.

  2. 2

    포맷 및 정규화

    각 패널에서 Format을 눌러 줄 끝 공백을 잘라내고 줄 끝을 일관되게 맞추세요. 가장 흔한 거짓 양성 부류, 즉 똑같아 보이지만 한쪽은 CRLF, 다른 쪽은 LF로 저장돼 완전히 다르게 diff되는 경우를 잡아냅니다. 양쪽이 공백에 합의하면 diff는 진짜 키와 값 변경에 집중합니다.

  3. 3

    diff 읽기

    삭제는 왼쪽에 빨간색 강조, 삽입은 오른쪽에 녹색 강조로 나타납니다. 한쪽을 스크롤하면 다른 쪽이 따라옵니다. 주석과 주석 처리된 키는 일반 텍스트처럼 diff되므로, #을 앞에 붙여 비활성화한 키는 키 삭제가 아니라 주석 줄 추가로 보입니다.

설정 diff가 적합한 상황

로컬과 staging 사이의 .env 파일 diff

로컬에서 feature 브랜치를 띄우면 잘 돌다가 staging의 .env에서 STRIPE_WEBHOOK_SECRET이 빠져 있어 staging에서 크래시. 동작하는 로컬 파일을 staging 파일과 붙여 비교하면 누락된 키, 바뀐 DATABASE_URL 호스트, 오래된 LOG_LEVEL=debug가 한 번에 드러납니다. 두 파일을 한 줄씩 훑는 것보다 빠르고, 두 변수 집합을 터미널에 출력하는 스크립트를 돌리는 것보다 훨씬 안전합니다.

의존성 업그레이드 후 pyproject.toml 비교

Poetry나 uv가 poetry update 후 방금 pyproject.toml을 다시 썼습니다. 이전에 커밋된 버전을 working tree와 diff해 실제 업그레이드를 확인하세요. fastapi0.110.0에서 0.115.4로, 새로운 [tool.ruff.lint] 테이블 등장, build-system.requires 핀 이동 등. TOML 1.0 사양은 충분히 엄격해서 diff가 보통 깨끗하고 읽기 쉽습니다.

reload 전에 nginx.conf 변경 검토

망가진 설정으로 nginx를 reload하면 서버에서 거의 무엇보다 빠르게 운영 사이트가 내려갑니다. nginx -s reload 전에 실행 중인 nginx.conf를 제안된 버전과 붙여 비교해, 변경이 정확히 의도한 것인지 확인하세요. 새 upstream 블록, 갱신된 proxy_pass 대상, TLS cipher suite 교체. diff는 실수로 빠진 세미콜론을 매번 잡아냅니다.

systemd unit이나 supervisord 설정 감사

서비스가 배포 후 무한 재시작 중. 동작하던 foo.service를 새 버전과 diff하면 보통 30초 안에 원인이 보입니다. 바뀐 ExecStart, 빠진 Environment= 줄, 좁아진 NoNewPrivileges 등. supervisord .conf 블록, runit run-script, 오래된 머신에서 아직도 보이는 다양한 .ini 풍 init 설정에도 같은 흐름이 적용됩니다.

Infrastructure-as-Code 설정 파일 비교

terraform.tfvars의 Terraform 변수, Pulumi 스택 설정, Ansible group_vars, Kubernetes ConfigMap용 Helm values. 환경마다 사본이 있고 안전하게 머지하는 유일한 방법은 diff입니다. prod와 staging을 붙여 비교하면 drift가 튀어나옵니다. 한쪽은 region이 us-east-1로, 다른 쪽은 us-west-2로 고정, 누군가 인시던트 중에 키워 놓고 되돌리지 않은 인스턴스 타입, 잘못된 계정을 가리키는 IAM role ARN 등.

CI 환경 파일이 문서화된 템플릿과 일치하는지 확인

신규 엔지니어가 들어와 리포지토리의 .env.example을 복사했지만, 템플릿이 CI 파이프라인이 실제로 기대하는 것과 어긋나서 첫 PR의 빌드가 여전히 실패. 커밋된 .env.example을 빌드가 통과하는 동료의 알려진-양호 .env와 diff하면 누락된 키가 왼쪽 빨강이나 오른쪽 녹색으로 드러납니다. 같은 트릭이 Taskfile의 env 블록, GitHub Actions의 env: 섹션, direnv.envrc 파일에도 적용됩니다.

설정 형식 빠른 참조

이 도구가 가장 자주 보는 형식들을 짧게 정리한 치트 시트. 설정은 평판이 시사하는 것보다 어수선하고, 아래의 차이들이 대부분 diff가 어긋나는 지점입니다.

TopicWhat this tool does
형식 방언INI(정식 사양 없음, 파서별 방언), TOML 1.0(엄격, 타입), .env(사양 없음, 파서 정의), .properties(Java, java.util.Properties 참조), .conf(앱별: nginx, Apache, sshd_config가 모두 다름).
주석 문자INI: ; 또는 #. TOML: #만. .env: #만, 대부분 로더에서 줄 시작에서만. .properties: # 또는 !. nginx .conf: #만.
섹션 헤더INI와 TOML은 [section]을 사용합니다. TOML은 [a.b.c]로 중첩 테이블, [[a]]로 테이블 배열을 추가합니다. .env.properties는 평면이며 섹션이 없습니다. nginx는 헤더 대신 { ... } 블록을 사용합니다.
값 타입TOML에는 타입이 있는 값들이 있습니다: 문자열, int, float, bool, 날짜, 배열, 테이블. INI, .env, .properties는 문자열만이며, true42를 어떻게 파싱할지는 애플리케이션이 결정합니다.
보간 및 확장대부분의 dotenv 로더는 기본적으로 $VAR을 확장하지 않습니다. 일부는 합니다(dotenv-expand, direnv, source .env를 통한 셸 sourcing). TOML은 절대 확장하지 않습니다. INI도 거의 확장하지 않으며, Python의 configparser는 옵트인하면 ${section:key}를 지원합니다.
줄 끝 공백실제 버그의 원인. FOO=bar에 줄 끝 공백이 있으면 대부분의 로더에서 FOO"bar "로 설정되어 다운스트림 문자열 동등 비교에서 실패합니다. 항상 잘라내거나 따옴표로 감싸세요.
줄 끝 처리CRLF(Windows) 대 LF(Unix). 다른 OS에서 저장된 동일 파일 두 개가 모든 줄이 바뀐 것처럼 diff됩니다. diff 전에 Format 버튼을 사용하거나 줄 끝을 정규화하세요(dos2unix, git config core.autocrlf).
인코딩과 BOMTOML은 UTF-8을 강제합니다. .properties는 역사적으로 \uXXXX escape가 들어간 ISO-8859-1을 요구했지만, 현대 Java는 Properties.load(Reader)를 통해 UTF-8을 받습니다. .env 시작의 UTF-8 BOM은 고전적인 유령 diff 원인입니다. Windows의 메모장은 여전히 기본으로 BOM을 씁니다.

설정 diff: 자주 묻는 질문

도구가 값의 타입을 이해하나요?

아니요. 텍스트 diff입니다. TOML은 문자열, 정수, 부동소수, 불리언, 날짜, 배열을 구분하지만, diff는 각 줄을 일반 텍스트로 다루고 어떤 문자가 바뀌었는지를 보여줍니다. 설정 변경은 어차피 문자 변경이라 보통 그것으로 충분합니다. 정말로 타입 기반 비교가 필요하면 원하는 언어로 양쪽 파일을 파싱하고(Python의 tomllib, Rust의 toml crate, Go의 pelletier/go-toml) 결과 맵을 비교하세요. 95%의 경우 텍스트 diff가 잡아야 할 것을 잡아냅니다.

"다르지만" 사실상 같은 주석 처리된 줄은 어떻게 다루나요?

보통은 따로 다루지 않고, 도구가 그것을 표시한 것을 다행으로 여겨야 합니다. API_KEY=abc에서 #API_KEY=abc로 가는 줄은 의미적으로 중요합니다. 키가 이제 비활성화되었다는 뜻입니다. diff는 주석 접두사 변경을 강조하는데, 이는 사람 리뷰어가 설정 리뷰에서 봐야 할 바로 그것입니다. 정말로 주석 churn을 무시하고 싶다면 붙여넣기 전에 양쪽을 포맷해서 주석만 있는 줄을 떨어뜨리세요. 다만 보안에 민감한 파일에서는 거의 옳은 선택이 아닙니다.

한쪽에 키가 빠졌는지 어떻게 확인하나요?

두 파일을 붙여넣고 diff를 돌리면, 한쪽에는 있고 다른 쪽에는 없는 키는 줄 전체의 빨간 삭제 또는 녹색 삽입으로 나타납니다. diff는 키를 구조적으로 정렬하려 하지 않으므로, 다른 위치로 재정렬된 키는 한 번은 삭제, 한 번은 삽입으로 나타납니다. 완전히 순서 무관 비교가 필요하면 먼저 양쪽 파일을 키로 정렬(Unix에서 sort .env)한 뒤 diff하세요. 형식 비의존 접근 방식은 파서 없이도 누락된 키를 잡아냅니다.

실제 secret이 들어 있는 .env를 붙여 넣어도 안전한가요?

네, 입력은 절대 브라우저를 떠나지 않습니다. diff는 전적으로 클라이언트에서 실행됩니다. 서버 업로드도 없고, 패널 내용에 대한 텔레메트리도 없으며, 입력 내용을 캡처하는 분석도 없습니다. 의도된 설계입니다. .env diff는 이 사이트에서 가장 신뢰가 필요한 워크플로 중 하나이기 때문입니다. 의심이 든다면(약간은 의심하시는 게 좋습니다) 브라우저 devtools를 열고 붙여 넣는 동안 네트워크 탭이 비어 있는지 확인하세요. 완전 air-gapped 도구를 선호하는 조직이라면 사이트를 한 번 오프라인으로 열어두면, 캐시된 자산이 추가 네트워크 접근 없이 동작합니다.

TOML과 INI의 차이는 무엇인가요?

INI는 관행이고, TOML은 사양입니다. INI는 Windows에서 자랐고 정식 문법이 없으며, 각 파서가 경계 사례(quoting, escape, 리스트 값, 중첩 섹션)를 조금씩 다르게 다룹니다. TOML 1.0은 엄격하고 버전 관리되는 사양으로, Cargo, Poetry, Hugo, 그리고 점차 pyproject.toml을 통한 Python 패키징에서 사용됩니다. 둘 다 [section] 헤더와 key = value 쌍을 사용해 첫눈에는 비슷해 보이지만, TOML은 타입이 있는 값, datetime 리터럴, 인라인 테이블을 추가하며 이는 고전 INI 파일에는 없습니다.

diff가 키 대소문자나 공백을 정규화하나요?

아니요. API_KEY=abcapi_key=abc는 바이트가 다르므로 diff에는 다른 줄입니다. 대부분의 로더도 대소문자를 구분합니다(dotenv, java.util.Properties, 기본 configparser). 따라서 현실과 일치합니다. = 주변 공백은 그대로 보존되는데, 이는 일부 더 엄격한 파서(특히 일부 Bash sourcing 패턴)가 공백이 있는 FOO = bar를 거부하고 FOO=bar만 허용하기 때문입니다. Format 버튼은 줄별 끝 공백을 잘라내는데, 이것이 적용하는 유일한 정규화 단계입니다.

개인정보와 동작 방식

설정 파일은 절대 브라우저를 떠나지 않습니다. diff, 포매터, 입력의 모든 바이트는 로컬 머신에 머무릅니다. 패널 내용에 대한 분석도, 로그도, 업로드도 없습니다. .env 파일은 일상적으로 데이터베이스 비밀번호, API 키, OAuth 클라이언트 secret을 담고 있고, 이를 서버 왕복 도구에 붙이는 것은 실제 보안 사고가 되므로, 이 점은 대부분의 diff 도구보다 여기서 더 중요합니다. 형식에 대한 배경 자료: TOML 1.0, INI 파일, 그리고 Unix의 환경 변수 개념. 파일에 절대 두면 안 되는 secret이라면 sops, HashiCorp Vault, AWS Parameter Store를 보세요.