jj 설정, 명령어, 통합 도구, GUI·TUI, 에디터 플러그인, 워크플로 도구를 둘러보는 생태계 안내.
16 Sep 2026
이 글은 원래 JJ Con 2026에서 발표한 내용입니다. 슬라이드도 볼 수 있습니다.
안녕하세요! jj 생태계, 즉 jj와 함께 동작하도록 만들어진 명령어, 설정, 도구를 살펴보는 “jj를 넘어”에 오신 것을 환영합니다. 이는 작년 JJCon 발표의 부분적인 후속편이기도 합니다. 당시에는 커뮤니티 전반의 jj 설정을 훑어보았는데, 곧 그 이야기로 돌아가겠습니다.
제가 jj에 관한 발표를 할 수 있는 실질적인 자격은 기본적으로 “새로운 것을 시도하는 일을 좋아하고 jj에 아주 신나 있다”로 요약됩니다. 비실질적인 자격은 “Steve Klabnik이 한때 제 룸메이트였으므로, 제 아이디어를 공식 jj 문서에 넣어 달라고 부탁할 수 있다”입니다. 미리 고마워요, Steve!
말씀드렸듯이 이 발표는 작년 발표의 속편이기도 합니다. 작년에는 이름 설정부터 템플릿, revset, 명령어, 별칭에 이르기까지 jj 설정이라는 개념 전체를 살펴보았습니다. 셸 스크립트를 감싸고, 그 셸 스크립트가 워크플로를 자동화하는 파이썬 스크립트를 감싸는 별칭도 잠깐 다뤘습니다. 별칭은 꽤 복잡해질 수 있습니다.
올해는 jj 설정이 무엇인지보다는 더 큰 질문을 이야기하겠습니다. jj를 갖춘 뒤에는 무엇을 할까요? 순수한 jj만으로 할 수 있는 일을 먼저 보고, jj 설정으로 할 수 있는 일로 넘어간 다음, jj CLI 바깥에서 완전히 독립적으로 할 수 있는 일을 살펴보며 마무리하겠습니다.
이 중 일부는 jj 문서에, 일부는 jj 위키에, 일부는 awesome jj git 저장소에 언급되어 있습니다. 하지만 이 모든 것을 한데 모은 자료는 이전에 없었습니다. 게다가 어느 곳에도 올라오지 않은 추가 항목도 많이 준비했습니다.
다른 도구나 헬퍼, 스크립트를 전혀 추가하지 않아도 jj만으로 정말 놀랄 만큼 많은 일을 할 수 있습니다. 사용자 정의 템플릿, revset, 별칭을 추가하면 상당한 부분을 줄이거나 자동화할 수 있습니다. 작년에 이야기한 jj 설정을 넘어, 여기서 가장 소개하고 싶은 것은 이전에는 외부 스크립트나 도구가 필요했던 기능이 jj 코어에 추가된 사례입니다.
먼저 설정에서 내장 기능으로 옮겨온 기능을 이야기해 보겠습니다.
작년에 저는 가장 가까운 북마크를 찾고 가장 가까운 푸시 가능한 변경으로 옮기는 jj tug라는 별칭을 소개했습니다. 이제는 jj bookmark advance와 단축형 jj b a가 과거 tug와 같은 일을 하므로 tug가 더는 필요 없다는 소식을 전하게 되어 기쁩니다. 기본적으로 bookmark advance는 북마크를 작업 복사본으로 전진시킵니다. 가장 가까운 푸시 가능한 커밋으로만 전진하는 tug 버전을 선호한다면 revsets.bookmark-advance-to를 설정하고 동일한 pushable revset으로 지정할 수 있습니다.
jj bisect 도구는 과거에 래퍼 스크립트가 필요했던 기능을 흡수했습니다. 이제 bisect run을 사용해 bisect하려는 변경을 자동으로 찾을 수 있습니다. 개인적으로 이는 jj와 git 사이의 큰 기능 격차였으므로, 스크립트를 찾아 헤매며 손볼 필요 없이 이제 통합된 모습을 보게 되어 아주 기쁩니다.
bisect는 필요 없지만 revset의 모든 변경을 수정하는 스크립트를 실행하고 싶다면 어떨까요? 그것이 jj run의 용도입니다. 스크립트와 revset을 주면 스크립트가 실행되고, 파일이 수정되었다면 모든 변경이 갱신됩니다. 변경 트리 전체는 그대로 유지됩니다. 또는 다른 관점에서 말하면, 실행이 각 변경을 순회하며 진행될 때 자동으로 리베이스됩니다.
하지만 아마 이렇게 생각하고 있을 겁니다. jj fix와 jj run은 같은 일을 하지 않나요? 변경 범위를 받아 그 변경에 속한 파일을 수정할 수도 있는 방식으로 갱신하는 일 말입니다. 어느 정도는 그렇지만, 실제로는 아닙니다.
jj fix는 변경된 파일에만 수정 사항을 적용하기 위해 존재합니다. 각 변경을 체크아웃하지 않으며, 한 번에 파일 하나만 스크립트에 제공하고 수정된 파일 버전을 출력으로 받습니다.
디스크에 체크아웃된 파일 집합이 있어야 스크립트를 실행할 수 있다면 jj fix로는 할 수 없습니다. 하지만 전체 revset에 걸쳐 변경된 모든 파일에 포매터나 린터를 소급 적용하려는 것이라면 jj fix가 jj run보다 엄청나게 빠를 것입니다.
jj tag는 설정이나 스크립트가 아니라 git 자체로부터 jj 내부로 들어온 기능의 사례입니다. 더는 태그를 관리하려고 git tag를 쓸 필요가 없습니다. 이제 jj tag set과 jj git push --all로 모든 북마크와 태그를 푸시할 수 있습니다. (jj git push --tag NAME으로 태그 하나만 푸시할 수도 있습니다.) 이제 jj tag가 생겼으니, 제 일상 작업에는 더는 git 명령을 실행하는 일이 전혀 없습니다. 모두들, 작년 이후로 큰 진전입니다!
jj arrange는 대화형인 git rebase -i와 같습니다. 텍스트 파일을 편집할 필요 없이 로그 같은 그래프에서 변경을 직접 선택하거나 이동할 수 있습니다. 최근 변경의 이름을 찾고 옮기기 위해 명령 세 개를 실행하고 싶지 않을 때 시간을 절약하기에 좋습니다.
converge 명령은 가장 최신이지만 어쩌면 가장 유용합니다. 변경을 서로 다른 두 곳에서 갱신하면 언제든 분기될 수 있습니다. 1년 전 이 발표를 했을 때는 분기된 변경을 다루는 일이 엄청나게 고통스러웠습니다. 분기의 각 측면을 쉽게 가리키는 /N 문법도 없었고, 두 터미널 창에서 동시에 명령을 실행하거나 원격 브랜치를 가져오는 것만으로도 실수로 분기되기 쉬웠습니다.
오늘날에는 분기된 변경을 가리키는 일이 훨씬 쉬워져서 브랜치를 리베이스하거나 결합하기 쉬워졌을 뿐 아니라, 아예 그렇게 할 필요조차 없을 수 있습니다! converge 명령은 두 개의 분기된 변경 스트림을 하나의 비분기 변경 스트림으로 결합하려 합니다. 병합 충돌이 생길 수는 있지만, 직접 조정해야 하는 별도의 브랜치 두 개보다는 병합 충돌이 낫습니다. 개인적으로 converge를 갖게 되었고 앞으로 사용할 수 있다는 사실에 아주 기대하고 있습니다.
이제 jj에 완전히 내재한 기능을 넘어 jj CLI와 통합되는 것을 살펴보겠습니다.
첫 번째로 이야기하고 싶은 통합 방식은 jj 별칭이 하위 명령을 가질 수 있게 하는 정말 놀라운 해킹입니다. 이는 이슈 #6611의 @tjjfvi 댓글에서 가져왔습니다. 핵심 아이디어는 jj가 공백을 포함하는 별칭 명령을 정의하도록 허용한다는 것입니다. 따라서 jj → jj → jj → bash → jj 실행 흐름을 만들 수 있습니다.
aliases.subcommand = ["util", "exec", "--", "bash", "-c", 'jj "$0 $1" "${@:2}"']
aliases.foo = ["subcommand", "foo"]
aliases."foo bar" = ["..."]
aliases."foo baz" = ["..."]
이 설정을 해 둔 뒤에는 다음을 실행할 수 있습니다.
jj foo bar ARGS
그러면 foo라는 이름의 별칭을 실행합니다. 그런데 그것도 별칭이므로 다음으로 변환됩니다.
jj subcommand foo bar ARGS
그리고 subcommand도 별칭이므로 다음과 같이 확장됩니다.
jj util exec -- bash -c 'jj "foo bar" ARGS'
물론 바깥쪽 jj를 벗기고 그다음 바깥쪽 bash를 벗기면, 결국 다음 명령이 됩니다.
jj "foo bar" ARGS
그리고 당연히 이것이 정의해 둔 하위 명령 별칭이므로, 이제 하위 명령이 실행됩니다! 완전히 정신 나간 방식이고 저는 이게 정말 좋습니다.
바라건대 내년에는 어떤 형태로든 하위 명령을 기본 지원하게 되었다고 말씀드릴 수 있기를 바랍니다. 하지만 그렇지 않더라도, 지금은 우리만의 하위 명령을 성공적으로 설정할 수 있습니다!
git push와 비슷한 것다음으로 아주 인기 있는 별칭 범주는 수동으로 git push를 재현하는 것입니다. 항상 완전히 같지는 않지만, 대체로 다음을 뜻합니다.
tug, 아니, 잠깐, bookmark advancepublish = ["util", "exec", "bash", "--", "-c", '''
jj git-hooks-run-pre-push @ &&
jj bookmark advance -t 'closest_pushable(@)' &&
jj git push -b 'closest_bookmark(@)' &&
jj track-if-untracked 'closest_bookmark(@)'
''']
제 현재 견해로는 이것이 이제 jj 내장 기능에서 가장 큰 빈틈입니다. push -c로 브랜치를 만들고 푸시할 수 있다는 점은 알고 있지만, 그러면 토론이나 검토에 쓸 사람이 읽을 수 있는 이름이 생기지 않습니다.
가까운 미래에 jj에 기여할 생각을 하는 영웅적인 분이 있다면, 사전 푸시 훅에 관한 합의를 이끌어 내고 이 모든 것을 묶어 클라이언트의 최신 변경을 현재 저장소의 백엔드로 보내는 내장 명령을 출시해 주신다면 저와 많은 사람이 당신을 칭송할 것입니다. 개인적으로는 jj publish가 좋습니다. 그러면 git push와 혼동되지 않을 테니까요.
설정과 별칭에 관한 이야기는 모두를 jj 별칭 웹 디렉터리로 안내하며 마무리하겠습니다. 직접 추가하세요! 기존 별칭에 투표하세요! 없이는 살 수 없는 새 별칭을 찾고, jj 코어에 넣어 달라고 청원하세요! 가능성은 끝이 없습니다.
여기에서 확인하세요: jj 별칭 웹 디렉터리
마지막으로 살펴볼 jj 통합 영역은 포지 지원입니다. 작년 이후 눈에 띄는 움직임이 있었지만, 앞으로 성장할 여지가 가장 큰 영역일 것입니다. 현재 세 개의 포지가 jj 스타일 개발 지원을 명시적으로 문서화했거나 구현했습니다.
GitHub에서는 이를 “stacked PRs”라는 기능으로 부릅니다. GitHub는 서로 의존하는 PR 집합으로 푸시할 수 있는 변경 스택에 대해 서버 측 및 gh CLI 지원을 구축했습니다. 이는 서로를 가리키는 PR 체인을 만드는 방식의 약간 더 영리한 버전이며, 여러분도 과거에 이미 해 본 적이 있을 수 있습니다. 일반 GitHub PR에 jj 스택을 통합하도록 돕는 독립형 jj 도구도 이미 몇 가지 있으며, 나중에 살펴보겠습니다.
GitHub 통합의 또 다른 형태는 Erisera의 JJHub입니다. 스스로를 “github 위의 오버레이”라고 부릅니다. 이 오버레이는 일관된 변경 ID와 에이전트가 사용할 스킬 및 MCP 서버를 제공합니다.
피어 투 피어 포지인 Radicle은 git 이메일 흐름에 더 가깝고 명시적으로 스택되지 않은 패치 요청과 jj를 함께 사용하는 방법을 작성했습니다. 공개한 흐름은 jj를 사용해 Radicle에서 패치를 만들고, 승인 및 병합될 때까지 수정하는 방법을 보여 줍니다.
현재 제가 개인적으로 가장 기대하는 포지는 Tangled입니다. Tangled는 ATProto ID를 중심으로 구축된 tangled.org의 공개 포지입니다. 자신의 ID와 활동 데이터는 여러분이 제어하며, 게시물용 Bluesky, 저장소용 Tangled, 블로그용 Leaflet, 그리고 사용자가 웹에서 자기 데이터를 소유하는 방식으로 구축된 성장 중인 온라인 도구 생태계를 포함한 모든 ATProto 애플리케이션에서 하나의 ID를 유지할 수 있습니다.
Tangled는 jj 지원의 최전선에 꾸준히 서 왔으며, jj 변경 ID를 활용하여 서로 다른 PR 버전 간 diff를 검토할 수 있게 하는 “stacking”의 명시적 지원도 포함합니다. 하지만 Tangled는 단지 변경 ID를 지원하는 데 그치지 않습니다. next.tangled.org에서 공개 미리 보기 중인 새로운 검토 UX는 제가 보기에는 jj를 완전히 지원합니다. 풀 리퀘스트의 단일 리비전 또는 리비전 간 interdiff를 검토할 수 있고, 명시적인 jj 변경 ID 추적과 함께 언제든 변경 집합을 검토할 수도 있습니다.
제 생각에 Tangled는 현재 우리가 가진 것 중 “jj 네이티브” 포지에 가장 가깝습니다. 한번 사용해 보시기를 권합니다.
마지막으로, 곧 출시될 예정이지만 아직 공개되지 않은 또 다른 종류의 포지도 있습니다. 그 목록의 맨 위에는 우리 모두가 곧 실험하게 될 것으로 기대하는 프로젝트인 East River Source Control이 있습니다.
ERSC 외에도 웹사이트를 공개하고 제품을 시험해 볼 수 있도록 요청할 수 있다고 말하는 프로젝트가 몇 개 있습니다. 제가 알고 있는 것은 revset.dev, juju.bi, vex.sc입니다. 이 사이트들 중 어느 곳에서도 얼리 액세스를 받지는 못했지만, 반짝이는 새 기술 또는 곧 새로워질 기술을 시험해 보고 싶을 수 있으므로 언급합니다. 아마 그러실 겁니다. 여러분은 JJCon에 있으니까요.
더 나은 jj 지원을 기존 포지에 추가하는 다른 포지나 개발 사례를 알고 있다면 알려 주세요! 나중에 이 블로그 글에 업데이트를 추가하겠습니다.
마지막으로 jj 자체 밖에 존재하는 환경을 둘러보겠습니다. 이는 jj 저장소와 함께 쓰이도록 의도되었지만, jj CLI를 직접 실행하지 않고 사용하는 애플리케이션, 스크립트, 도구를 뜻합니다.
먼저, 이 도구들 중 일부는 공식 jj discord에 전용 채널도 있다는 점을 말씀드리고 싶습니다. 목록에는 그러한 채널의 유무와 관계없이 도구를 포함하려 했지만, jj용 GUI나 TUI를 시작하려면 jj discord를 둘러보는 것만으로도 쉬운 방법이 될 수 있습니다. 다른 사용자 및 유지 관리자와 대화할 수 있기 때문입니다.
첫 번째 도구 범주는 어느 정도 예상 가능한 GUI입니다. git을 오랫동안 사용했다면 유서 깊은 gitk, macOS 포크인 gitx, 또는 GitTower, Fork, Retcon 같은 최신 GUI를 알고 있을 수 있습니다. jj 저장소와 jj 명령을 위해 의도적으로 만들어진 GUI를 살펴보겠습니다.
https://github.com/gulbanana/gg의 gg
gg는 제가 알기로 가장 오래된 jj GUI이며, Rust로 작성되었고 Tauri를 사용해 Linux, Windows, macOS용 앱과 웹 옵션을 제공합니다. gg가 내세우는 문구는 “항상 대화형 리베이스 도중이라면 어떨까? 그런데 그게 실제로 좋은 일이라면?”입니다.
https://github.com/hewigovens/jayjay의 jayjay
JayJay는 스스로를 “Jujutsu를 위한 빠르고 키보드 친화적인 클라이언트”라고 부르는 새 GUI입니다. macOS에서는 SwiftUI 프레임워크로, Linux에서는 Zed의 GPUI 프레임워크로 구축되었습니다.
https://github.com/chronologos/lightjj의 lightjj
lightjj는 스스로를 “jujutsu를 위한 빠르고 강력한 UI”라고 소개합니다. 웹 서버를 생성하므로 로컬 또는 원격 저장소에서 SSH 포트 포워드를 통해 GUI를 사용할 수 있습니다. lightjj가 제공하는 가장 흥미로운 기능은 3패널 diff, 충돌 해결, 분기 해결, diff용 markdown 렌더링입니다.
여기서 더 새롭고 작은 두 가지 시도도 언급하겠습니다. 다음도 주목할 만합니다.
jj는 아직 git만큼 풍부한 GUI 환경을 갖추지는 못했지만, jj 주변에는 많은 열정과 활동이 있습니다. jj가 인기를 얻어 가면서 이 외에도 GUI가 계속 늘어날 것으로 예상합니다.
이 분야가 jj 시대의 진정한 성장 부문입니다. go용 Charm, Rust용 Ratatui 등 환상적인 TUI 라이브러리가 아주 많기 때문입니다. 그 결과 TUI는 다른 어떤 분야보다 다양하고 도구도 많습니다.
https://github.com/Cretezy/lazyjj의 lazyjj
lazyjj는 가장 오래된 jj TUI 중 하나로, 변경 그래프, 파일 탐색, 북마크 관리를 포함해 jj 로그를 전체 터미널에서 대화형으로 보여 줍니다.
https://github.com/faldor20/jj_tui의 jj_tui
jj_tui를 사용하면 commit, rebase, push, pull, squash, split 및 revset 필터링을 포함한 jj 사용 전체를 TUI로 옮길 수 있습니다.
https://github.com/tim-janik/jj-fzf의 jj-fzf
jj-fzf는 “모든 jj 명령에 도움을 주기 위해 fzf를 사용하면 어떨까”라는 개념을 믿기 어려울 정도로 훌륭하게 구현한 도구입니다. jj CLI와 fzf 퍼지 찾기 스크립트 위에서 구축되었으며, log, split, merge, rebase는 물론 메가 병합에 대한 명시적 지원도 제공합니다.
https://github.com/idursun/jjui의 jjui
jjui는 실시간 대화형 자동 완성 revset 표현식이라는 개념을 중심으로 하는 TUI입니다. revset을 작성한 뒤 rebase, squash, browse, split, abandon 등을 할 수 있습니다. revset을 미리 보거나 즉각적인 피드백을 받으며 revset 작성을 연습하고 싶다면 jjui는 훌륭한 도구입니다.
https://github.com/anthrofract/majjit의 majjit
majjit는 magit의 UX에서 영감을 얻은 TUI로, jj 객체 그래프를 탐색하는 동안 키보드 단축키 기반 jj 명령과 변경 및 북마크에 대한 퍼지 매칭을 제공합니다.
찾아낸 모든 도구를 다룰 시간은 없으므로, 영감을 찾고 있거나 다른 도구를 시험해 보고 싶거나 기여할 수 있는 무언가를 찾는 중이라면 다음도 언급하겠습니다.
vscode
https://www.visualjj.com/의 visual jj
https://github.com/keanemind/jjk의 jjk
jjk(이전 이름 Jujutsu Kaizen)는 파일 상태, 상세 diff 보기, 줄 단위 blame, commit, split, squash, rebase, 그리고 op log용 두 번째 패널까지 추가하는 jj용 VSCode 플러그인입니다. VSCode를 떠나지 않고 저장소 작업 이력을 탐색하세요!
https://github.com/brychanrobot/jj-view의 jj-view
JJ View는 jj를 위한 또 다른 VSCode 통합입니다. 예상할 수 있는 jj 변경 그래프가 담긴 대화형 패널에 더해, JJ View는 Gerrit, GitHub, GitLab과 명시적으로 통합되어 검토 토론 및 인라인 댓글을 VSCode 내부에서 직접 보여 줍니다.
다른 모든 에디터 통합을 하나씩 보여 주는 대신, 대부분의 에디터에 어떤 형태로든 명시적인 jj 통합이 있다는 점을 분명히 확인해 드리겠습니다. 여기에서 볼 수 있듯이 거대한 IDE를 쓰든 작은 최첨단 터미널 에디터를 쓰든, 워크플로에 맞는 것을 찾기 위해 시험해 볼 선택지가 적어도 몇 개는 있습니다.
JetBrains (IntelliJ, PyCharm, 등)
vim
emacs
helix
워크플로 이야기가 나왔으니, 워크플로 도구를 살펴보겠습니다.
“원조 세 가지” 스택 도구 외에도, 포지에 제출하고 검토하며 궁극적으로 병합할 스택형 변경을 관리하도록 설계된 도구가 더 있습니다. 위의 세 가지가 잘 맞지 않는다면 다음을 확인하거나 직접 작성해 보세요!
https://mergiraf.org/의 mergiraf
Mergiraf는 병합 중인 언어를 이해하여 폭넓은 git 병합 충돌을 해결할 수 있는 병합 드라이버입니다.
https://github.com/Ataraxy-Labs/weave의 weave
weave는 tree-sitter를 사용해 코드 엔터티 수준의 병합을 가능하게 하여 충돌을 처리하는 병합 드라이버입니다. 에이전트가 작성한 변경에서 충돌이 95% 줄어든다고 주장합니다.
https://github.com/Wilfred/difftastic의 difftastic
difftastic은 최초의 “문법 인식 diff” 시스템으로, 줄 자체의 차이가 아닌 코드 구조의 diff를 보여 줍니다.
https://github.com/dandavison/delta의 delta
delta는 문법 강조와 폭넓은 테마 지원을 모두 포함하는 diff 출력 프로그램입니다. git과 함께 동작하도록 설계되었지만, jj는 git 스타일 diff를 출력할 수 있고 delta가 이를 멋지게 만들 수 있습니다. 저는 개인적으로 delta를 사용하며 아주 좋아합니다.
https://github.com/arxanas/scm-record의 scm-record
scm-record는 jj split, restore, resolve를 실행할 때마다 호출되는 jj 내장 TUI입니다. git add -p의 대화형 대안으로 만들어졌으며, 오늘날 jj와 git-branchless 모두에서 사용됩니다. 이것이 jj와 별개의 프로젝트라는 점, 그리고 기여한다면 개선 사항이 jj뿐 아니라 git-branchless 사용자나 git 또는 mercurial이 scm-record를 사용하도록 설정한 모든 사용자에게도 적용된다는 점을 알리기 위해 언급합니다.
https://github.com/laulauland/jj-hunk의 jj-hunk
대화형 에디터 없이 diff의 선택한 부분 집합을 split, commit 또는 squash합니다. “hunkset” 언어를 사용하고 CLI 플래그 또는 JSON을 통해 인수를 받습니다.
https://github.com/julienvincent/hunk.nvim의 hunk.nvim
hunk.nvim은 jujutsu와 함께 쓰도록 설계된 neovim용 diff 에디터이며, 내장 scm-record TUI의 대안입니다.
https://github.com/KyleKing/jj-diff의 jj-diff
jj-diff는 scm-record의 또 다른 TUI 대안이지만, split, amend, squash에만 초점을 둡니다.
https://github.com/ccqpein/jj-diff.el의 jj-diff.el
jj-diff.el은 Emacs용 Magit 스타일 diff 및 hunk 에디터입니다. Emacs 자체 외에는 의존성이 없으며 대화형 및 비대화형 split을 모두 허용한다는 점이 주요 특징입니다.
https://github.com/emilien-jegou/oyui의 oyui
oyui는 제가 개인적으로 가장 좋아하는 diff 에디터이며, 일상적인 jj split 워크플로에 사용합니다. scm-record를 새로 단장한 것에 가깝고 색상, 문법 강조, 그룹 선택을 추가합니다. cargo install oyui로 한번 사용해 보세요.
이렇게 jj 생태계 둘러보기가 끝났습니다. 살펴보고 시험해 보고 싶은 명령어, 설정, 또는 도구를 알게 되셨기를 바랍니다. 그보다 더 좋게는, 여러분만의 jj 설정을 실험하거나 여러분만의 jj 도구를 만들어 우리 모두와 공유하도록 영감을 드렸으면 합니다.
그렇게 하신다면 알려 주세요! 소셜 미디어에서 @indirect로 연락하시거나 arko.net에 있는 주소로 이메일을 보내실 수 있습니다. 여러분의 이야기를 듣고 싶습니다.
제 글쓰기 시간은 Spinel의 후원을 받습니다. 귀사의 보석, Rails, CI 또는 개발자 생산성에 세계적 수준의 전문 지식이 필요하다면 spinel.coop을 확인하고 저희를 고용해 주세요!