“합의는 채팅에서 시작해도 된다.
다만 기록은 티켓으로 닫아야 팀이 같은 지도를 본다.”

팀 채팅은 빠르다. 중요한 합의도 종종 스레드에서 끝난다.
문제는 일주일 뒤다. 리뷰어, QA, 다른 개발자는 그 스레드를 못 찾거나, 찾아도 안 읽는다.

그래서 스레드에서 합의가 끝나면, 티켓 맨 위에 한 문단만 더 옮긴다.
티켓·채팅·저장소를 잇는 루프에서 말한 세 축 중, 여기서는 티켓 첫 문단만 다룬다. PR 본문 3단락은 이 글과 짝이다.

TL;DR

  • 스레드 합의는 티켓 4줄로 닫는다 — 의도, 비목표, 영향 범위, 스레드 링크.
  • 길게 쓰지 않는다. 짧을수록 나중에 읽힌다.
  • 문서화가 아니라 기억 외주화다.

옮길 때 남기는 4줄

  1. 이번 변경의 핵심 의도
  2. 의도적으로 제외한 비목표
  3. 영향받는 앱·화면
  4. 원본 스레드 링크 (내부 URL이면 팀 규칙에 맞게)

이 네 가지만 있어도, 나중에 “왜 이건 안 했지?”가 줄어든다.

예시 템플릿

## 이번 변경 요약
- 의도: checkout·wallet 문구 정합성 통일
- 비목표: native shell 경로는 별도 티켓
- 영향 범위: checkout, mypage, home
- 합의 스레드: (링크)

이 습관이 통하는 이유

  • 리뷰어가 스레드를 뒤지지 않는다
  • QA가 테스트 범위를 빠르게 잡는다
  • 회고 때 “그때 왜 그랬지?”를 덜 듣는다

채팅은 빠르고, 티켓은 느리다.
두 개를 연결할 때 협업이 빨라진다.

마치며

스레드에서 끝난 합의는 반쪽이다.
티켓 한 문단으로 닫아야 팀의 실행력이 된다.

한 줄 결: 합의는 채팅에서 시작하고, 티켓에서 끝낸다.