AI 도입은 강요가 아니라 배려에서 시작한다
제안하는 쪽은 상대의 속도를 존중해야 하고, 받아들이는 쪽은 불편을 이유로 미루지 않아야 한다.
11개의 글이 있습니다.
제안하는 쪽은 상대의 속도를 존중해야 하고, 받아들이는 쪽은 불편을 이유로 미루지 않아야 한다.
언제 올지 모를 인수인계를 기다리던 문서가 이제 다음 티켓에서 쓰인다.
PR을 빨리 통과시키는 대신, 멈춰야 할 곳을 정하고 그 앞단에 시간을 쓰기로 했다.
AI는 코드를 만드는 일뿐 아니라 작업을 이해하고 검토하는 과정도 빠르게 했다. 그럼에도 한 티켓에서 사람이 읽고 판단해야 할 비용은 왜 커졌는지 돌아본다.
AI에게 구현을 맡기기 전에 인수 조건과 예외 케이스를 정하고, 단위·통합 테스트로 완료 여부를 검증하는 방법.
2026년 4월 Claude Code의 /branch, 당시 /fork, /btw를 비교하고 이후 /fork와 /subtask의 역할이 바뀐 과정을 보충한다.
AI가 구현을 바꿔도 기능의 동작을 지키도록, 테스트 범위와 mock 사용 기준을 정리했다.
요구사항 확인, TDD, 정적·동적 검증과 PR 공유를 작은 스킬로 연결하되 작업 크기에 따라 단계를 줄이는 운영 방식을 보여준다.
범용 프레임워크의 계획·TDD·리뷰 원칙은 가져오되, 프로젝트별 SQL·호환성 검증은 작은 전용 스킬로 만든 판단을 설명한다.
변경 명령 화이트리스트보다 읽기 명령 블랙리스트를 택한 이유와, 복합 Bash 명령을 안전하게 판별해야 하는 경계를 설명한다.
SessionStart·PostToolUse·matcher로 세션별 활동 로그를 만들고, matcher 밖 도구의 누락 가능성과 평문 로그 위험까지 함께 짚는다.