# Tilt - 개발 환경을 코드로 관리하기

> Clean Markdown view of GeekNews topic #20586. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20586](https://news.hada.io/topic?id=20586)
- GeekNews Markdown: [https://news.hada.io/topic/20586.md](https://news.hada.io/topic/20586.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-04-29T10:22:49+09:00
- Updated: 2025-04-29T10:22:49+09:00
- Original source: [github.com/tilt-dev](https://github.com/tilt-dev/tilt)
- Points: 6
- Comments: 1

## Summary

**마이크로서비스 개발**을 위한 무료 오픈소스 도구로, **코드 변경**부터 **배포 갱신**까지의 과정을 자동화하여 개발 환경을 효율적으로 관리할 수 있습니다. 이 도구는 **Kubernetes**를 중심으로 하지만, **docker-compose**나 **로컬 커맨드** 기반의 워크플로도 지원합니다. 2022년 **Docker**에 인수되었으나, 여전히 독립적인 오픈소스 프로젝트로 유지되며 발전하고 있습니다. **현대적인 개발 환경 통합 관리**를 목표로 하여, 복잡한 마이크로서비스 구조를 쉽게 이해하고 관리할 수 있도록 돕습니다.

## Topic Body

- Kubernetes 기반 **마이크로서비스 개발**을 위한 무료 오픈소스 개발 환경 자동화 도구  
- **코드 변경 → 파일 감시 → 이미지 빌드 → 배포 갱신** 흐름을 자동화하여 `tilt up` 명령으로 전체 환경을 띄울 수 있음  
- Kubernetes를 중심으로 하지만, **docker-compose**나 **로컬 커맨드** 기반 워크플로도 지원함  
- 2022년 **Docker**에 인수되었지만, 독립적인 오픈소스 프로젝트로 유지되며 발전 중임  
- 마이크로서비스 복잡성을 관리하기 위해 **현대적인 개발 환경 통합 관리**를 목표로 함  
  
---  
  
### Tilt란 무엇인가  
  
- 현대 앱은 단일 바이너리가 아니라 여러 서비스와 데이터베이스, 프론트엔드 서버 등이 HTTP로 상호작용하는 구조임  
- Tilt는 이런 복잡한 구성 요소를 한 번에 이해하고 관리할 수 있는 **마이크로서비스 개발 환경 툴**임  
- 파일 수정, 이미지 빌드, 서버 갱신 과정을 모두 자동화하여 개발 속도를 높임  
  
### Tilt를 사용할 팀  
  
- 마이크로서비스 기반 앱을 개발하는 팀에 적합함  
- 다수의 터미널 창을 열어 서버 로그를 관리하거나, 복잡한 셸 스크립트로 개발 환경을 세팅하는 팀에게 특히 유용함  
- `tilt up` 명령어 하나로 누구나 동일한 개발 환경을 쉽게 구축할 수 있음  
  
### 왜 Kubernetes를 중심으로 하나  
  
- Kubernetes는 컨테이너, 파드, 서비스 등 **표준화된 서버 실행 블록**을 제공함  
- 개발 환경에서도 이 표준을 사용하면, 운영 환경과 개발 환경의 차이를 줄일 수 있음  
- Tilt는 Kubernetes 외에도 docker-compose나 로컬 명령어를 지원하지만, 궁극적으로는 Kubernetes 중심으로 수렴할 것으로 기대함  
  
### Tilt의 개발과 미래  
  
- Tilt는 원래 독립 스타트업이었으나, 2022년에 **Docker**에 인수됨  
- 현재도 오픈소스로 유지되며, Docker Compose와 Docker Desktop 등과도 연계하여 개선 중임  
- 새로운 프로젝트들도 개발 중이며, Tilt의 아이디어를 더 넓은 개발자 생태계로 확장하려고 함  
  
### 이름의 의미  
  
- "Tilt"는 **돈키호테의 풍차에 돌진하는 이야기**에서 영감을 얻음  
- 데모 앱 이름은 **Servantes**로, 돈키호테 작가인 세르반테스를 참조함

## Comments



### Comment 37943

- Author: neo
- Created: 2025-04-29T10:22:49+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43806296) 
* 이곳에서 이 주제를 보게 되어 흥미로움. 나는 Tilt를 몇 년간 사용해 왔지만, Docker에 인수된 후 개발 속도가 느려진 것 같음
  - Tilt는 로컬 개발 환경을 만들어주어 서비스가 프로덕션, 테스트, 개발에서 동일하게 실행되도록 해줌
  - 서비스 코드가 크게 단순화되고 품질이 향상되었음
  - 특히 CRD를 다루는 부분에서 개선이 필요함 (k8s_yaml이 CRD에 의존하는 것을 표시할 방법이 없어 tilt up 호출이 자주 깨짐)
  - 새로운 프로젝트를 시작할 때 가장 먼저 하는 일은 "tilt up"을 작동시키는 것임
  - 테스트에 사용한 것들로는 보안 및 관찰 가능성을 위한 eBPF 기반 수집기, 데이터 파이프라인, 헬름 차트 개발, Kubernetes 컨트롤러 등이 있음
  - 매우 유연하고 다양한 개발에 강력함

* 이 피치는 나에게 좀 웃김
  - 현대 앱은 너무 많은 서비스로 구성되어 있음. 이들은 어디에나 있고 끊임없이 소통 중임
  - 그래서 더 많은 서비스를 쉽게 만들 수 있도록 도구를 만들었음

* 속도와 정확성 사이에서 항상 타협이 필요함
  - 로컬 통합 환경을 유지하려고 하면 너무 느리고 비용이 많이 들게 됨
  - 문제는 Kubernetes 자체가 아니라, 의존성이 증가하면서 로컬에서 세계의 복사본을 실행하려고 하면 점점 느려짐
  - 나는 docker-compose 같은 것을 사용하여 빠르고 간결한 개발 환경을 좋아함. 이는 빠른 속도를 유지하기 위해 일부 의존성을 모의로 처리할 수 있음. 로컬 테스트가 통과되면 다른 환경에서는 Kubernetes를 사용함

* "개발 환경"은 정말로 언어의 네이티브 도구로 직접 테스트를 실행해야 한다고 생각함. 예를 들어 `cargo test`, `bundle exec rspec` 등
  - Kubernetes를 실행하는 VM을 실행하고, 그 VM이 Docker 컨테이너를 실행하여 테스트를 실행하게 한다면 매우 화가 날 것임
  - 이를 제대로 하고 신뢰성 있게 하는 것은 여전히 많은 작업이 필요함. Docker를 사용하지 않는 것이 목표라면 더 많은 작업이 필요할 수 있음 (macOS에서 네이티브로 실행하려면 반드시 필요함)
  - 이 분야에는 많은 도구가 있는 것 같음. 이들이 "개발 환경"을 위한 도구라고 부르지 않았으면 좋겠음. 이는 "로컬 머신에 앱을 배포하는" 도구에 더 가까움

* nix-shell을 언급하지 않을 수 없음: [nix-shell 링크](https://nix.dev/manual/nix/2.18/command-ref/nix-shell)

* Tilt를 실제로 보고 싶다면, 우리 Chroma 오픈 소스 저장소에서 개발 및 CI를 위한 데이터베이스의 분산 버전을 실행하는 데 사용함. 매우 멋짐 - 클론 후 `tilt up`을 실행하면 작동함
  - [Chroma 링크](https://github.com/chroma-core/chroma)

* 로컬 환경 설정이 문제였던 적은 없음
  - 단일 클러스터 배포는 매우 쉬움
  - 문제는 우리가 프로덕션에서 관리하는 서비스들이 여러 지역(또는 k8s 클러스터)에 걸쳐 배포된다는 것임
  - 분산 애플리케이션을 디버깅하는 것이 문제임

* Tilt는 "skaffold dev"와 어떻게 비교되는가? 우리는 그 목적을 위해 skaffold를 사용함. 클러스터 내에서 개발하기 위해 사용함

* 얼마 전 Tilt를 잠시 사용해 봤음. Tilt, Garden, 아마도 몇 가지 다른 것들도 사용해 봤고, DevSpace로 정착했음
  - 기억에 따르면, 기존의 프로덕션 인프라와 가장 잘 맞았음. 모든 것을 다른 방식으로 다시 작성할 필요가 없었음
  - 즉, 기존의 kustomize+k8s 설정과 잘 맞았음. 포트 포워딩과 실행 중인 컨테이너로의 빠른 파일 동기화를 추가함. 이것이 내가 정말로 원하는 전부임. 변경할 때마다 이미지를 다시 빌드하는 것은 싫음

* 이것은 본질적으로 개발 컨테이너가 아닌가?