“계획은 이슈 트래커에, 실행은 저장소에, 합의는 채팅에 남는다.
그 사이를 메우는 건 도구가 아니라, 내가 들고 있는 문맥이다.”
반기 정리나 성과를 쓸 때면 자꾸 같은 질문이 생긴다.
- 무엇을 했는가 는 커밋과 PR에 흩어져 있고
- 왜 그 순서였는가 는 티켓과 스레드에 흩어져 있고
- 어디까지가 범위였는가 는 내 머릿속에만 남아 있는 경우가 많다.
이번에는 그걸 Cursor와 같이 한 줄로 묶어 보는 실험을 했다.
회사 밖에 내놓을 글은 아니지만, 과정만 블로그에 올려도 되는지 물어본 자리에서, 그 기록을 여기에 적는다.
세 개의 파이프
요즘 내가 일을 추적할 때 의식적으로 쓰는 축은 세 가지다.
- 이슈 트래커 — 무엇을 약속했는지, 어떤 Epic/스프린트에 붙는지, AC가 무엇인지.
- 코드 호스트 (GitHub 등) — 브랜치 이름, PR, 실제 diff. 무엇이 바뀌었는지의 증거.
- 팀 채팅 — PM·기획·동료와의 정정과 합의. “처음엔 A라고 생각했는데 B가 맞다” 같은 것.
세 축만 놓고 보면 각각 잘 된다.
문제는 서로를 자동으로 연결해 주지 않는다는 점이다.
- 티켓 번호가 브랜치에 없으면 나중에 찾기 귀찮다.
- 스레드에서 정리된 범위가 티켓 설명에 안 올라가면 리뷰어는 모른다.
- 코드만 보면 “왜 이 경로만”이 안 보인다.
그래서 약간 과장해서 말하면 이렇게 정리할 수 있다.
이슈에 적힌 계획이 저장소에서 얼마나 처리되고 있는지, 그리고 채팅으로 흐름이 매끈했는지를 같은 날에 한 번씩 겹쳐 본다.
숫자 대시보드가 아니라, 이름 붙은 한 줄의 이야기로 말이다.
Cursor가 들어간 자리
Cursor는 여기서 코드를 대신 짠다 보다, 세 축을 같은 언어로 번역하는 데 가까웠다.
예를 들면 이런 식이다.
- 스레드에서 “범위는 PDP가 아니라 장바구니 안의 버튼이다”라고 정리됐다면,
그걸 티켓 설명의 한 단락과, 저장소에서 찾을 훅/파일 후보와, PR 설명의 첫 문장으로 한 번에 나열해 달라고 한다. - “결제하기 쪽은 이미 하는데, 바로구매만 안 한다” 같은 말이 나왔다면,
두 코드 경로를 비교해 차이를 짧게 적게 한다. - 브랜치 이름은
feat/티켓-슬러그처럼 팀 규칙에 맞추고, 티켓 링크는 PR에만 붙인다.
즉, 탐색과 초안은 빨라지고,
틀린 범위로 가속하는 것을 막으려면 여전히 사람이 스레드와 화면을 읽어야 한다.
이건 예전에 썼던 “AI는 제안한다, 사람은 선택한다” 와 같은 층이다.
다만 이번 루프에서는 선택의 단위가 함수 하나가 아니라 티켓 한 줄 + 브랜치 한 개 + 스레드 한 토막이었다.
블로그에 써도 되는 경계
회사 내부 숫자, 고객 이슈, 티켓 본문 그대로, 슬랙 캡처는 올리기 어렵다.
그래도 과정은 괜찮다고 본다.
- 어떤 축(티켓·저장소·채팅)을 의식적으로 맞췄는지
- 에이전트에게 무엇을 맡기고 무엇을 맡기지 않았는지
- 공개 글에서는 어떤 식으로 익명화·일반화했는지
이 정도면 “우리 팀의 비밀” 은 아니고, “나만의 작업 습관” 에 가깝다.
내가 가져간 규칙 몇 가지
- 브랜치 이름에 티켓 키를 넣는다. 나중에
git log와 보드가 서로 인사하게. - PR 첫 문단에 “무엇을 같게 만들었는지” 한 줄. diff가 길어질수록 이게 생명이다.
- 채팅에서 바뀐 범위는 티켓 설명에 한 번 더 적는다. 리뷰어가 스레드를 안 읽어도 되게.
- Cursor에는 “파일 찾아서 비교해 줘” 처럼 행동 단위로 시킨다. “장바구니 잘 봐줘” 는 너무 크다.
마치며
성과를 Cursor와 정리했다는 말은,
문서 한 장을 AI가 써줬다는 뜻보다 세 축을 같은 날에 맞춰 봤다는 뜻에 가깝다.
블로그로 쓸 만한가에 대한 답은 그렇다다.
다만 매력은 “Jira 대비 GitHub 처리율 87%” 같은 숫자가 아니라,
계획·실행·합의를 한 줄로 잇는 습관 쪽에 있다.
한 줄 결: 티켓은 약속, 브랜치는 증거, 채팅은 맥락이다. 그 셋을 잇는 건 여전히 사람이고, Cursor는 그 사이를 빠르게 번역하게 해 주는 펜에 가깝다.