Atuin Desktop: 실행 가능한 Runbooks

 (blog.atuin.sh)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Atuin Desktop은 문서처럼 보이지만 터미널처럼 실행되는 로컬 우선 runbook 편집기로, 반복되는 운영 절차를 공유 가능한 워크플로로 만들려는 도구임
  • 셸 명령, 데이터베이스 쿼리, HTTP 요청을 스크립트 블록과 내장 터미널, 데이터베이스 클라이언트, Prometheus 차트 안에서 함께 다룸
  • Atuin CLI가 동기화·검색 가능한 셸 히스토리를 제공했다면, Desktop은 팀 지식이 개인 기억이나 히스토리에만 남지 않도록 실행 가능한 문서로 확장함
  • Atuin 팀은 CLI 릴리스, 환경 간 인프라 마이그레이션, staging/prod 실행, 라이브 데이터베이스 쿼리 관리와 협업에 이미 사용 중임
  • 다음 단계로 Team accounts와 셸 히스토리에서 runbook을 만드는 기능을 계획 중이며, 현재 early access를 배포 중임

개인 기억에 의존하던 운영 절차를 문서화

  • 많은 인프라 작업은 장애가 났을 때 누군가 기억하는 몇 개의 명령에 의존하고, 문서는 없거나 오래된 상태가 되기 쉬움
  • 실제 해결 단서는 Slack 스레드, Notion 문서, 개인 셸 히스토리에 흩어져 있을 수 있음
  • Atuin CLI는 동기화되고 검색 가능한 셸 히스토리로 이 문제의 일부를 해결했지만, 팀에는 히스토리 이상의 공유 가능한 워크플로가 필요함
  • Atuin Desktop은 “runbook은 실행되어야 한다”는 전제에서 만든 실행형 runbook 편집기임
  • 다운로드는 다운로드 페이지에서 제공됨

문서 안에서 실행되는 터미널 워크플로

  • Atuin Desktop은 문서 UI 안에서 실제 터미널 워크플로를 실행하도록 구성됨

  • 한곳에 묶이는 작업 요소

    • 스크립트 블록
    • 내장 터미널
    • 데이터베이스 클라이언트
    • Prometheus 차트

  • 제공 기능

    • 컨텍스트 전환 감소: 셸 명령, 데이터베이스 쿼리, HTTP 요청을 연결함
    • 썩지 않는 문서: 문서에서 직접 실행해 최신성을 유지함
    • 재사용 가능한 자동화: Jinja 스타일 템플릿으로 동적 runbook을 만듦
    • 즉시 회상: 실제 셸 히스토리에서 자동완성을 제공함
    • Local-first, CRDT-powered: 터미널에서 실행되는 것은 runbook에서도 실행됨
    • Atuin Hub 동기화와 공유: 기기와 팀 사이에서 최신 상태를 유지함

실제 사용 사례와 배포 상태

  • Atuin 팀은 이미 실제 작업에 Atuin Desktop을 사용 중임
    • Atuin CLI 릴리스
    • 환경 간 인프라 마이그레이션
    • staging 또는 prod 실행
    • 라이브 데이터베이스 쿼리 관리와 협업
  • 다음 기능으로 Team accounts와 셸 히스토리에서 runbook을 생성하는 기능이 예정되어 있음
  • 현재 배포 중이며, early access list를 통해 참여할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Emacs가 궁금한 사람이라면 org-babel로 비슷한 일을 할 수 있음
    평문 파일 하나가 프로그램이면서 문서/노트북/웹사이트가 될 수 있고, 문학적 프로그래밍의 설득력 있는 예시임
    좋은 설명은 여기 있음: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • 기능 면에서 org-babel은 문학적 프로그래밍 시스템 중 가장 강력한 축이고, 어쩌면 최강일 수도 있음
      프로그래밍 책으로 공부할 때 크게 도움을 받았고, 나중에 그 문학적 프로그램을 다시 보면 처음 책을 읽을 때보다 훨씬 빨리 이해가 돌아옴
      문학적 부분이 당시 추론이나 내 생각을 100% 기억하지 못해서 생기는 “바보 같은” 질문에 답해줌
      물론 학습 곡선은 있어서, 그런 걸 배우기 싫은 사람에게는 맞지 않음
    • org-babel은 이 작업에 잘 맞고 훌륭한 문서를 만들 수 있음
      발표 영상[0]과 더 고급 데모가 있는 Git 저장소[1]도 볼 수 있음
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • BBEdit의 Shell Worksheets도 비슷하게, 설명문과 키 한 번으로 실행할 수 있는 명령을 섞어 쓸 수 있음

  • 약 7년 전에 이걸 시도해 봤음: https://nurtch.com/
    아이디어 자체는 장점이 많고, JupyterCon Paris 2023에서도 관련 발표를 했음: https://www.youtube.com/watch?v=TUYY2kHrTzs
    문서 안에 실행 가능한 코드가 있으면 사람들은 문서에도 PR 리뷰 워크플로를 적용하고 싶어 하는데, 이건 위키를 편집하는 것보다 팀 차원의 투자가 더 필요함

    • 처음 든 생각도 “왜 Jupyter가 아니지?”였고, 같은 생각을 한 사람이 있어서 반가움

  • AWS에 있을 때 우리 팀에 딱 원했던 물건임
    자동화하기엔 살짝 위험한 운영 작업이 정말 많은데, 이건 그런 작업을 반복적으로 자동화로 키워가는 경로를 제공함

    • 개인 의견일 뿐이고 고용주의 입장은 아님
      AWS에 있었던 게 언제인지 궁금함
      최근 몇 년간 AWS에서 운영 런북을 코드화하고 안전하게 자동 실행하도록 도와 운영 잡일을 줄이는 내부 플랫폼 서비스를 만들었음
      Atuin Desktop도 어떤 면에서는 그 서비스와 비슷하지만, 그 내부 서비스는 기능이 훨씬 많았음
    • AWS에 있을 때 위키에서 바로 실행할 수 있는 걸 만들었음
      CloudWatch 쿼리, AWS CLI 명령 같은 것들을 사용자 입력과 함께 실행하되, 올바른 자격 증명을 안전하게 가져오고 입력을 포맷하는 설정 부담은 없애는 식이었음
      이후 GitHub에서 바로 실행하도록 다시 만들었고, GitHub 위키에서 사용자 입력으로 Lambda 함수를 4줄 코드로 호출하는 예시는 여기 있음: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • Amazon에 있었던 코로나 이전 시기라면 Eider를 그런 용도로 쓸 수 있었을 것 같음
      IAM 통합이 있는 호스팅 노트북이었음

  • 로컬 Jupyter 노트북과 어떻게 다른지 궁금함
    .ipynb에서 !나 %로 이걸 할 수 있지 않나?
    이 회사나 CLI 제품을 잘 몰라서 진심으로 묻는 질문임

    • Jupyter 노트북을 완전히 Python만 쓰는 일이 아니면 피하게 만드는 가장 큰 이유는 Python임
      pipenv/pyenv/conda/poetry/uv/dependencies.txt와 “이 노트북을 실행하려면 Python을 올려야 하네, 아… 알겠어”로 시작해서 2주 뒤 “그 업그레이드가 오래된 Ansible을 깨뜨렸고 이제 간신히 버티던 서버 15대를 못 고치겠다”가 되는 흐름은 지옥임
      기반 자동화에는 Python을 멀리하려고 함
      내가 다루는 Python 프로젝트는 의존성이나 런타임 문제로 최소 1년에 한 번은 깨지고, Ansible, 빌드 파이프라인, deploy.py 같은 것에도 해당됨
      Jupyter 노트북은 거대한 의존성 트리와 요구 사항을 끌고 오기 때문에, 그런 중요하고 기반이 되는 자동화에는 쓰지 않을 것임
      물론 내 일은 코드베이스를 과하게 많이 다루게 만들고, 최근 두 달만 해도 Python 프로젝트가 최소 6개였음
      어떤 건 Python 2.7이 필요하고, 어떤 건 폐기된 lib-something.h 버전이 필요하고, 어떤 건 최첨단이고, 어떤 건 문서화는 안 됐지만 실제로는 아주 엄격해서 “담당 개발자 한 명의 머신에서 아무것도 업데이트하지 않는 한 동작함” 같은 상태임
      Puppet이나 Chef도 Ruby라서 똑같이 나쁘고 같은 문제를 겪지만, Ruby는 수십 년 동안 패키지 관리 시스템이 하나뿐이었다는 차이는 있음
    • Jupyter 노트북은 터미널 용도로는 늘 좀 해킹처럼 억지로 맞춘 느낌이라, 이걸 한번 써보고 싶음
    • 같은 질문이 100% 듦
      보통 Jupyter는 유연한 스크립팅과 운영체제 명령 지원을 둘 다 주는 것처럼 느껴짐
      !/%나 os.system()으로도 가능함

  • 이건 https://runme.dev와 매우 비슷해 보임

    • Runme 공동 제작자임
      실행 가능한 문서를 좋아하고, 아직 충분히 많지 않다고 봄

  • 흥미로워 보임
    최근 Jupyter 노트북 대체재로 https://marimo.io/를 쓰기 시작했는데, 여러 개선점이 있고 이것도 비슷한 방향의 움직임처럼 보임

  • 로컬 우선이면 이미 부패(rot) 의 대상임
    전부 컨테이너에서 실행하는 게 아니라면 그렇고, 컨테이너에서 실행한다면 로컬이라는 점은 중요하지 않음
    런북을 기록하고 싶으면 그냥 런북을 기록하면 됨
    텍스트 파일, Confluence 문서, 화면 녹화, 셸 스크립트 등 방법은 수없이 많음
    사람들은 이미 그걸 안 하고 있고, UI가 더 멋져졌다고 갑자기 더 하게 되진 않을 것임
    개인적으로는 시스템을 X 상태처럼 만들기 위해 하루 종일 코드나 문서를 쓰고 싶지 않음
    수동으로 X 상태를 만든 다음 도구로 상태를 덤프하고, 나중에 그 도구를 다시 실행해 그 상태를 만들거나 강제하고 싶음
    컴퓨터가 그 상태에 도달하는 방법을 코드로 설명하고 싶지 않고, 이름만 다른 코드인 선언형 설정도 쓰고 싶지 않음
    직접 하고, 스냅샷을 뜨고, 재생하고 싶음
    Bash 셸 명령을 감시하는 식의 의존 없이 어디서든 어떤 시스템에서도 동작해야 함

    • 그러면 왜 그런 상태가 되었는지에 대한 문서가 없는 상태의 바이너리 덩어리만 갖게 되는 것 아닌가? 유지보수 가능해 보이지 않음
      Dockerfile은 사실상 이와 비슷하지만, 그 상태에 도달하기 위해 거친 단계들을 파일로 문서화함
    • 원하는 건 autoexpect에 가까워 보임
      https://linux.die.net/man/1/autoexpect
    • 그런 절차는 대체로 이식성이 낮고, 서로 다른 시스템마다 반복해야 함
      그쯤 되면 X 상태에 도달하는 데 필요한 단계로 자동 변환할 수 있는 선언적 기술이 이미 있는 편이 좋음
    • 그게 Docker 선언문이었음
    • 설명하는 건 Ansible에 가까워 보임
      패키지가 설치되어 있는지, 파일이 존재하는지나 특정 내용을 갖는지 같은 일반 작업에는 모듈을 쓰고, 선언적이며 멱등적임

  • Atuin CLI와 동기화 서버처럼 이것도 오픈소스가 될지 궁금함
    제품화될 예정인가?

  • 이게 왜 필요한지 잘 모르겠음
    내가 놓친 게 뭔지 설명해 줄 수 있나? 왜 단순한 셸 스크립트 대신 이걸 써야 하지?

    • 런북을 겪어본 경험은 이랬음
      여러 대상을 담당하는 팀에 있고, 그중 어떤 건 아주 잘 알고 자주 만지지만 어떤 건 존재만 어렴풋이 알고 거의 건드리지 않음
      후자에 속하는 X가 고장남
      X를 실제로 아는 사람들은 모두 휴가/사망/회의 중임
      다행히 이 상황에서 해야 할 일을 설명하는 문서가 있음
      그런데 그 문서는 어찌 된 일인지 낡았고 틀렸음이라는 나쁜 정보의 기적을 보여줌
      이게 해결하려는 문제임
      제작자와 좀 이야기해 본 바로는, 의도는 Jupyter Notebooks와 Ansible Tower의 중간 같은 걸 만드는 것에 가까움
      문서, 스크립트, 지표가 서로 가까이 있어 무엇이 잘못됐는지, 어떻게 고치는지, 고친 게 효과가 있었는지 더 쉽게 알 수 있게 하는 방식임
      [1] 공개: atuin Discord 운영을 돕고 있음
    • 셸 스크립트를 위한 문학적 프로그래밍처럼 보임
      그래서 “Runbooks That Run”임
    • Rust로 작성됐고 여기가 Hacker News라서임
    • 배포가 보통 Ansible이나 Deployer 같은 도구로 구성되는 목적은 뭘까? 그리고 흔한 작업을 수행하는 Python 스크립트를 추가로 패키징해서 전부 Git 저장소에 넣는 이유는?
      어떤 사람들은 특정 워크플로나 도구 흐름을 좋아해서 그냥 만드는 것임
      충분한 사람에게 맞으면 시장성이 있을 수도 있고 아닐 수도 있음
      개인 프로젝트에서는 그냥 그러고 싶어서 PHP 배포 과정을 쓰는데, 내가 따로 할 필요 없이 작업의 60%를 처리함
      그에 대한 런북은 도구에 내장된 작업이고 전체 서버 배포와 같은 Git 저장소에 있음
      별도 명령을 기억해야 하는 임의의 장소나 셸 스크립트에 넣고 싶지는 않음
      프로그래머에게 코드는 복잡성을 피하고 단순한 함수형 스타일을 유지하면 본질적으로 자기 문서화가 됨
      가끔 “MySQL 사용자를 만들고, 비밀번호를 회전하고, 관련 서비스에 새 사용자/비밀번호 조합을 반영하고, VPN 차단에 실패했을 가능성에 대비해 해고된 직원이 자격 증명을 가진 이전 사용자를 제거한다” 같은 단순한 흐름이 아닌 부분에만 주석을 달면 됨

  • 꿈꾸는 도구는 모든 도구가 터미널 인터페이스를 제공해서, 머릿속에 있는 맥락을 모두 담은 거대한 책을 만들 수 있게 되는 것임
    Jira, Datadog, GitHub 등을 한 화면에 모으는 식임

    • 개인적으로는 조금 더 사용자 친화적인 TUI도 좋아함
      각 내부 서비스용 컴포넌트를 가진 내부 TUI 프레임워크가 있고, 그걸 레고처럼 조립해 개인화된 TUI 대시보드를 만들 수 있다고 상상해 보면 좋음
      회사에서 사이드로 해볼 만한 일 같고, 엄청 큰 작업이겠지만 흥미로울 듯함
    • API만 있어도 충분하고, 그 위에 도구를 만들 수 있음
      이상적인 세계에서는 모든 서비스, 도구, 애플리케이션이 내가 쓸 수 있는 API를 제공했으면 함
      예를 들어 냉장고 문이 너무 오래 열려 있으면 API 폴링이나 웹훅으로 감지하고, Roomba API를 써서 닫게 보내는 식임
      왜 안 되겠나? API의 세계임
    • GitHub와 Datadog은 이미 공식 CLI 도구가 있음
    • wtfutil 같은 걸 말하는 걸 수도 있음
      개발이 1년째 멈춘 것 같긴 하지만, 대략 그런 아이디어임
      https://wtfutil.com/
    • 그렇다면 MCP가 마음에 들 수도 있음
답변달기