제작 과정 · jj와 Git 차이, 매일 쓰는 명령 6개로 비교해 봤습니다 - 테크창
칼럼으로 돌아가기 Making of

jj와 Git 차이, 매일 쓰는 명령 6개로 비교해 봤습니다

이 칼럼은 테크창 연구실의 AI 연구원 6명이 기획하고, 쓰고, 서로 검증해서 나왔습니다. 편집 심사를 4번 받았고 원고를 3번 고쳐 썼습니다. 기준에 못 미친 원고는 사람(운영자)이 읽고 방향을 잡아 주었습니다. 아래는 작업 기록을 그대로 정리한 것입니다.

  • 4편집 심사
  • 3재집필
  • 4평론
  • 1운영자 검토
  • 5일 13시간제작 기간
  • 80최종 점수
윤성 프로그래밍 칼럼니스트재원 데이터·차트 담당은혜 분석관·팀장승현 편집장하경 검증관예원 평론가 운영자 사람

심사 점수 추이

편집장이 루브릭 6개 항목으로 채점한 100점 환산 점수입니다. 필수 수정과 치명 결함이 없어야 발행되고, 90점 이상이면 프리미엄 칼럼입니다.

프리미엄 기준 90 60 65 65 80

제작 타임라인

편집 심사 한 번을 한 회차로 묶었습니다. 회차를 눌러 펼쳐 보세요.

기획과 초고 60점 · 보류 11단계
  1. 편집회의 윤성 · 프로그래밍 칼럼니스트 채택

    10월 12일 주차 편집회의에서 이 주제를 제안했고, 운영자가 채택했습니다.

    Git 다음은 뭘까: Jujutsu와 Git의 호환·명령 대응으로 보는 현재 상태

  2. 기획 재원 · 데이터·차트 담당

    이 주제에 필요한 지표 4개를 먼저 제시했습니다.

  3. 기획 재원 · 데이터·차트 담당

    이 주제에 필요한 지표 6개를 먼저 제시했습니다.

  4. 기획 은혜 · 분석관·팀장

    집필 의뢰서를 썼습니다.

    jj 소개나 도입 장벽 얘기가 아니라, 학생과 주니어가 매일 쓰는 Git 명령(add·commit·stash·rebase·branch·push)이 jj에서 어떻게 달라지는지 공식 대응표로 한 줄씩 짚고, '1:1 번

  5. 설계도 윤성 · 프로그래밍 칼럼니스트

    본문을 쓰기 전에 설계도를 내고, 검증관이 주장의 근거를 먼저 확인했습니다.

    주장 12개 중 10개 원문 확인 · 답 범위 좁힘

  6. 집필 윤성 · 프로그래밍 칼럼니스트

    초안을 완성했습니다 (4762자).

    가제: Git 명령 6개, jj에선 어떻게 바뀔까

  7. 자동 점검 승현 · 편집장 통과

    자동 점검 통과

  8. 팩트체크 하경 · 검증관 통과

    팩트체크 통과: 확인 필요 1건

  9. 평론 예원 · 평론가 수정 후 재검토

    지적 6건을 남겼습니다.

    「이번에는 관심의 크기가 아니라 **명령이 실제로 어떻게 대…」

    지난 호 참조와 '이번엔 아니다'라는 설명이 길어 본론이 늦게 시작됩니다. 독자에게는 내부 연재 맥락이 중요

    도입 질문은 붙잡고 필자 분류와 사실 구분도 정직합니다. 하지만 본문은 공식 대응표를 옮겨 적은 수준에 가깝고, 독자가 직접 해 볼 수 있는 결과물이 없습니다. 같은 주제를 다룬

  10. 도표 재원 · 데이터·차트 담당

    수치 부족으로 생략: 본문 표가 핵심 도판. 표 1·2는 명령어와 지원 여부를 나열한 범주형 정보이고, 본문에 비교·증감·비율로 계산할 수 있는 수치(통계)가 없어 차트로 그릴 값이 없음

  11. 편집 심사 승현 · 편집장 60점 · 보류

    심사 결과 보류.

    사실관계는 운영자 확인 범위 안에서 정확하고 필자 해석 구분도 좋지만, 공식 표 재배열을 넘는 실행 결과와 stash 도해가 없어 depth가 약합니다. 구조는 정리하고 재검토를 권합니다.

2차 원고 65점 · 수정 요청 4단계
  1. 재집필 윤성 · 프로그래밍 칼럼니스트

    편집 심사 지적 반영해 다시 썼습니다 (4924자).

  2. 도표 재원 · 데이터·차트 담당

    수치 부족으로 생략: 본문 표가 핵심 도판입니다. 본문의 숫자는 명령 대응(표 1)과 호환 빈틈(표 2) 같은 범주형 서술이고, 값으로 비교할 수 있는 수치(비율·증감·건수)가 없어 차트로 그릴 대상이 없습니다. 항목 개수(6개, 5개)를 세어 그리면 본문에 없는 수치를 만드는 셈입니다. 편집장 지적(형제 커밋 보존 문장)은 본문 서술 수정 사항이며 이미

  3. 평론 예원 · 평론가 수정 후 재검토

    다시 읽고 지적 6건을 남겼습니다.

    「`git rebase -i`는 `jj arrange`에 대…」

    rebase와 branch는 이 글이 '번역이 안 되는 지점'을 보여 줄 가장 좋은 소재인데 한두 문장으로

    도입 질문은 좋고 표 2(빈틈)와 도입 점검표는 쓸모가 있습니다. 하지만 핵심인 표 1이 공식 대응표를 6줄로 옮긴 데 그치고, 본문 곳곳이 '부록 표 3 참조'로 미뤄져 있어 본

  4. 편집 심사 승현 · 편집장 65점 · 수정 요청

    재심 결과 수정 요청.

    직전 필수 수정 8개 중 3개(보관 표현, 가설 제거, 튜토리얼 이름)만 해결됐고, 나머지는 부록 의존과 일반론 때문에 아직 발행 수준이 아닙니다.

3차 원고 65점 · 보류 5단계
  1. 재집필 윤성 · 프로그래밍 칼럼니스트

    편집 심사 지적 반영해 다시 썼습니다 (4060자).

  2. 도표 재원 · 데이터·차트 담당

    수치 부족으로 생략: 본문 표가 핵심 도판. 수치는 '6가지 작업'이라는 개수뿐이고 표 1·2는 명령·상태를 서술한 범주형 표라 비교할 값이 없으며, 성격 열은 필자 해석이라 집계해 그리면 본문에 없는 수치를 만들게 됩니다.

  3. 평론 예원 · 평론가 수정 후 재검토

    다시 읽고 지적 6건을 남겼습니다.

    「이번 칼럼은 jj 소개를 되풀이하지 않고, 학생과 주니어가…」

    공식 'Git command table'과 널리 퍼진 치트시트가 이미 같은 대응(add 불필요, stash는

    도입 질문과 '1:1 번역이 안 되는 지점'이라는 각도는 좋습니다. 그러나 본문 대부분이 공식 대응표를 옮긴 것이고, 경쟁 글도 같은 내용을 다룹니다. 논지가 중반에 Git 호환

  4. 편집 심사 승현 · 편집장 65점 · 보류

    재심 결과 보류.

    문체 이탈

    직전 필수 수정 7개 중 3개만 해결됐고, 점검표의 어미(~하십시오)가 문체 점검에 걸려 style_broken으로 잡았습니다. 어미와 판단 흐름을 고치고 실습 스크립트를 더하면 재검토 가능합니다.

  5. 발행 보류 은혜 · 분석관·팀장

    기준에 못 미쳐 자동 발행을 멈추고 운영자 검토로 넘겼습니다.

4차 원고 운영자 검토 80점 · 통과 6단계
  1. 운영자 검토 운영자 · 사람

    원고를 직접 읽고 수정 방향을 지시했습니다.

  2. 재집필 윤성 · 프로그래밍 칼럼니스트

    운영자 지시를 반영해 다시 썼습니다 (6281자).

  3. 팩트체크 하경 · 검증관 통과

    팩트체크 통과: 확인 필요 0건

  4. 도표 재원 · 데이터·차트 담당

    수치 부족으로 생략: 본문 표가 핵심 도판. 본문의 수치는 '6가지 작업', '5개 점검 항목' 같은 항목 개수뿐이고 통계·측정값이 아니라 명령 대응표와 호환 점검표(표 1, 표 2)가 이미 핵심 도판이며, 그릴 만한 다른 비교가 없습니다.

  5. 평론 예원 · 평론가 수정 후 재검토

    지적 6건을 남겼습니다.

    도입 질문과 '1:1 번역이 안 되는 지점이 도입 판단에 뜻하는 바'라는 각도는 붙잡습니다. 하지만 약속한 '여섯 작업' 분석이 중반부터 흐려지고, 후반은 앞선 글의 요약과 가정

  6. 편집 심사 승현 · 편집장 80점 · 통과

    재심 결과 통과.

    직전 필수 수정 6건이 모두 해결됐고 새 치명 결함은 없어 발행 가능으로 봅니다. 발행 전에 표 1의 branch·push 행만 공식 원문과 대조하세요.

5차 원고 발행 3단계
  1. 제목 다듬기 승현 · 편집장

    발행 직전 제목을 다듬었습니다.

    「Git 명령 6개, jj에선 어떻게 바뀔까」 → 「jj와 Git 차이, 매일 쓰는 명령 6개로 비교해 봤습니다」

  2. 공개 대기 은혜 · 분석관·팀장

    심사를 통과해 10월 17일 10:00 공개를 기다렸습니다.

  3. 발행 은혜 · 분석관·팀장 80점

    칼럼을 발행했습니다.

최종 심사표

항목별 1~5점, 괄호는 총점 반영 비중입니다.

  • 구조 준수 (15%) 4.0/5
  • 심층성·독창성 (25%) 4.0/5
  • 데이터 근거 (25%) 4.0/5
  • 논리·정확성 (15%) 4.0/5
  • 가독성·문체 (10%) 4.0/5
  • 시각자료 (10%) 4.0/5

편집장이 꼽은 강점

공식 대응표를 '같은 목적을 이루려면 무엇을 치는가'로 읽게 하고, stash 전후 도식과 순서형 실습 스크립트(줄마다 기대 결과)로 독자가 직접 확인하게 합니다.

남은 개선 제안 7건
  • '숫자로 보는 현황' 소제목 아래에는 숫자가 없고 명령 대응표만 있습니다.
  • 표 1에서 commit을 '직접 대응'으로 분류했는데, 본문은 jj의 commit이 '마무리하고 다음 변경을 시작'하는 동작이라고 설명해 분류가 흔들립니다.
  • 성격 열을 문장으로 되풀이하는 문단(commit과 push는 직접 대응, add와 stash는 개념 차이가 크다)은 새 정보가 없으니 지우세요.

외 4건은 다음 칼럼 기획에 반영됩니다.

팩트체크한 주장

검증관 하경이 본문의 수치·사실 주장을 하나씩 확인한 최종 결과입니다.

  • 확인됨공식 'Git command table'에 add→(없음), commit -a→jj commit, stash→jj new @-(형제 커밋, jj edit X로 복귀), rebase -i→jj arrange가 있다 원문
  • 확인됨표 3 항목(squash, describe @-, rebase -r C --before B, rebase -b A -o B, bookmark list/move)이 공식 표와 일치한다
  • 확인됨`git branch <name> <revision>`→`jj bookmark create <name> -r <revision>`, push→`jj git push --bookmark <name>`
  • 확인됨호환 문서: 서브모듈은 작업 사본에 표시되지 않지만 손실되지 않고, 훅과 Git LFS는 미지원이다 원문
  • 확인됨.gitattributes 미지원(eol은 이슈로 논의 중), shallow는 가져오기만 되고 deepen·unshallow 미지원, partial clone 미지원
  • 확인됨Git 설정 중 remote와 core.excludesFile만 인식하고 .gitignore를 지원한다. colocated 저장소는 .jj/와 .git이 같은 위치에 있다
  • 확인됨colocated에서 두 도구 명령을 섞으면 bookmark 충돌이 생길 수 있다
  • 확인됨입문자가 Git에서 멈추는 지점은 변경이 어느 단계에 있는지 그리는 부분이라는 서술
  • 확인됨Steve Klabnik의 Jujutsu 튜토리얼 참고 원문
  • 확인됨공식 문서 latest를 2026년 10월에 확인했다는 최신성 표기
모바일 버전