Ansible 써본 사람은 아는 그 답답함
서버 여러 대를 설정할 때 Ansible 많이들 쓰시죠. YAML 파일에 '이 패키지 깔고, 이 파일 복사하고, 서비스 재시작해라' 하고 순서대로 적으면 알아서 해주는 그 도구요. 편하긴 한데, 한 번쯤 이런 데서 막혀본 적 있으실 거예요. 대상 서버에 파이썬 버전이 안 맞아서 안 돌아가고, 모듈 하나 쓰려니 의존성 설치하다 꼬이고, YAML로 조건 분기 좀 짜려면 문법이 괴상해지고요. Show HN으로 올라온 Unobin은 바로 이 지점을 정면으로 겨냥한 도구예요.
Unobin의 핵심 아이디어는 제목 그대로예요. '인프라 코드(Infrastructure as Code)'를 딱 하나의 실행 바이너리로 컴파일한다는 거죠. 이게 왜 대단하냐면요, 결과물이 어디에도 의존하지 않는 독립 실행 파일이라는 뜻이거든요.
'해석'이 아니라 '컴파일'이라는 발상의 전환
여기서 개념 하나 짚고 갈게요. Ansible은 '인터프리터' 방식이에요. YAML을 실행 시점에 한 줄씩 읽어서 해석하고, 그때그때 파이썬으로 대상 서버에서 작업을 수행해요. 그래서 실행하는 쪽이든 대상 쪽이든 파이썬 런타임과 관련 모듈이 깔려 있어야 해요.
반면 Unobin은 '컴파일' 방식이에요. 이게 무슨 말이냐면, 여러분이 작성한 자동화 코드를 미리 Go 언어 기반의 단일 바이너리로 빌드해버린다는 거예요. Go로 만든 프로그램은 필요한 걸 전부 하나의 파일 안에 넣어버리는 특성이 있거든요. 그래서 완성된 바이너리 하나만 서버에 툭 던져 넣고 실행하면 끝이에요. 대상 서버에 파이썬이 있든 없든, 아무것도 미리 깔 필요가 없어요. 이게 실무에서 얼마나 큰 해방인지, 배포 환경 셋업으로 고생해본 분들은 바로 아실 거예요.
컴파일 방식의 또 다른 장점은 '실행 전에 오류를 잡을 수 있다'는 거예요. YAML은 실제로 돌려보기 전엔 오타나 타입 오류를 알기 어렵잖아요. 한참 실행하다 중간에 터지면 서버가 어정쩡한 상태로 남기도 하고요. 컴파일 단계에서 문제를 먼저 걸러내면 이런 사고를 크게 줄일 수 있어요.
업계 맥락에서 보면
인프라 자동화 도구는 크게 두 갈래로 나눌 수 있어요. 하나는 '서버 프로비저닝(있는 서버 설정하기)'을 하는 Ansible·Chef·Puppet 계열이고, 다른 하나는 '클라우드 자원 자체를 만들기'를 하는 Terraform·Pulumi 계열이에요. Unobin은 Ansible이 있던 첫 번째 자리를, '컴파일된 단일 바이너리'라는 새 무기로 파고드는 거예요.
비슷한 흐름으로 Pulumi가 이미 'YAML 대신 진짜 프로그래밍 언어로 인프라를 짜자'는 길을 열었고요. Go 생태계에서도 정적 바이너리로 배포되는 데브옵스 도구가 대세가 된 지 오래예요(도커, 쿠버네티스 도구들 대부분이 그렇죠). Unobin은 이 두 흐름, 즉 '코드로서의 인프라'와 'Go 단일 바이너리의 편리함'을 합쳐놓은 셈이에요. 다만 Ansible이 수년간 쌓아온 방대한 모듈 생태계에 비하면 아직 신생 도구라, 성숙도 면에선 갈 길이 멀다는 점은 감안해야 해요.
한국 개발자에게 주는 시사점
소규모 팀이나 개인 프로젝트에서 특히 매력적이에요. '대상 서버에 파이썬 안 깔아도 된다'는 건, 컨테이너 안이나 최소 설치 리눅스, 임베디드 환경처럼 런타임 넣기 껄끄러운 곳에 자동화를 배포할 때 엄청난 강점이거든요. CI 파이프라인에서도 바이너리 하나만 캐싱하면 되니 깔끔하고요.
당장 회사의 대규모 Ansible 자산을 갈아엎으라는 얘긴 아니에요. 하지만 새 프로젝트의 배포 자동화를 고민 중이라면, 후보로 한 번쯤 살펴볼 가치가 있어요. 무엇보다 '설정도 컴파일해서 미리 검증한다'는 사고방식 자체가 배워둘 만하고요.
한 줄 정리하면, 인프라 자동화도 이제 '해석'에서 '컴파일'로, 의존성 없는 단일 바이너리 시대로 가고 있다는 거예요. 여러분은 아직도 대상 서버마다 런타임 맞추느라 시간 쓰고 계시진 않나요?
🔗 출처: Hacker News