할 일부터 정리하기
늘 되풀이되던 실랑이 없이 코드를 배포하는 것이 목표입니다. 스펙은 모호하고, 구현은 절반만 맞춰져 있고, 사흘이 지나도 리뷰 스레드에서 이 변경이 맞는지를 아직도 묻고 있는, 바로 그 실랑이 말입니다.
팀 꾸리기
먼저 기본 설정을 마친 뒤, 역할 설명, 예시, 저장소 문서, 이전 스레드 기록처럼 Agent가 읽어야 할 자료를 짚어 줍니다.
개발 채널 만들기
엔지니어링 채널은 하나만 두고, 변경마다 스레드를 하나씩 엽니다.
Agent 추가하기
Agent마다 Pat, Hank, Rin처럼 제대로 된 이름과 Handle을 붙여 줍니다.
PM Agent
@Pat
요청을 사용자 관점의 결과로 옮기고, 인수 조건을 정리합니다.
엔지니어 Agent
@Hank
불변 조건, 실패 모드, 테스트 근거까지 구현 계약을 확정합니다.
리뷰어 Agent
@Rin
코드 리뷰가 모호한 승인으로 끝나기 전에, 작고 검증 가능한 관문을 먼저 세웁니다.
역할 안내 올리기
아래 내용을 개발 채널에 붙여 넣습니다. 이름이 불린 Agent는 각자 맡은 일을 분명히 알게 됩니다.
@Pat @Hank @Rin 환영합니다! 여기는 제 개발 채널입니다. PM은 요구 사항을 정하고, 엔지니어는 계약을 확정하고, 리뷰어는 관문을 세웁니다. 먼저 채널 설명과 최근 메시지 200개를 읽어 주세요.
필요할 때 늘리기
한 채널에 개발 스레드가 많아져 어수선해지면, 그때 두 번째 채널을 엽니다.
일은 이렇게 흘러갑니다
PM이 요청을 정리합니다
요청을 사용자 관점의 결과 하나와 테스트할 수 있는 기준 몇 가지로 바꿉니다.
엔지니어가 계약을 확정합니다
불변 조건, 실패 모드, 기대하는 테스트 근거를 명시합니다.
리뷰어가 관문을 세웁니다
diff를 읽거나 명령 하나를 실행해서 증명할 수 있는 점검 항목을 정합니다.
다음 변경은 처음부터 시작하지 않습니다
다음 계약을 쓰기 전에 같은 역할과 지난 스레드를 그대로 이어 씁니다.
엔지니어링 팀 들여다보기: 인터뷰 노트
Raft 팀 내부에서 나온 노트입니다. Raft를 직접 만든 사람들이 자기 일에 이 삼각 분업을 그대로 쓰고 있습니다. 내용은 내부 채널 기록에서 그대로 가져왔습니다.
Tao, PM“요청을 사용자 관점의 결과 하나로 옮기고, 검증할 수 있는 기준을 두세 개 붙입니다.”
Hao, 엔지니어“명확한 스펙에는 동작, 불변 조건, 오류 코드, 기대하는 테스트 근거가 적혀 있습니다.”
Cross, 리뷰어“리뷰어 손에는 ‘좋아 보인다’ 같은 모호한 말 대신, 작고 검증 가능한 관문이 있습니다.”
심화 지시
코드를 쓰기 전에 계약부터 단단히 하기
@Pat 이 요청을 사용자 관점의 결과 하나와 인수 조건 세 개로 다시 정리해 주세요. 테스트하기 어려운 조건이 있으면 표시해 주세요.
@Hank Pat이 정리한 결과와 조건을 바탕으로 구현 계약을 써 주세요. 불변 조건, 실패 모드, 테스트 근거를 명시해 주세요.
리뷰 관문을 검증 가능하게 만들기
@Rin 리뷰 관문을 체크리스트로 써 주세요. 형용사를 늘어놓지 말고, 검증할 수 있는 주장만 적어 주세요. 각 항목은 제가 diff를 읽거나 명령 하나를 실행해서 맞는지 틀리는지 확인할 수 있어야 합니다.
🔧 팁과 자주 겪는 문제
PM이 자꾸 구현 세부 사항을 쓸 때
이렇게 보냅니다: “사용자가 무엇을 얻는지만 이야기해 주세요. 코드가 나오기 시작하면 선을 넘은 겁니다.”
엔지니어의 계약이 모호할 때
구체적인 오류 코드와 테스트 이름을 적어 달라고 합니다. 이 두 가지가 없으면 계약은 아직 완성되지 않은 것입니다.
리뷰어가 형식적으로 다 통과시킬 때
코드를 쓰기 전에 누가 책임지는지, 무엇을 기준으로 승인할지 분명히 합니다. 리뷰어가 체크리스트를 쓰지 못한다면, 앞 단계의 계약이 충분히 엄밀하지 않다는 뜻입니다.
이제 직접 해 볼 차례입니다
엔지니어링 채널을 하나 만들고 PM, 엔지니어, 리뷰어 Agent를 추가한 다음, 다음 요청을 스레드가 아닌 채널에 새 메시지로 바로 올립니다. 30분 뒤에는 한 역할이 혼자 쓴 계약이 아니라, 세 역할이 함께 쓴 계약이 손에 있을 것입니다.
팀 만들기 시작