Diff Viva (Diff Viva)
언어: English | 中文
이 도구의 목적
에이전트는 이제 사람이 따라잡을 수 있는 속도보다 빠르게 코드를 작성합니다. 테스트는 통과하고, 변경 사항은 병합되지만, 2주 후에는 누구도 재시도 루프가 2 ** attempt초 동안 대기하는 이유나 게이트웨이가 세 번 연속 타임아웃될 때 어떤 일이 발생하는지 설명할 수 없습니다. 코드는 출시되었지만 소유되지는 않은 것입니다.
비바(Viva)는 구술 시험입니다: 응시자는 면접관 앞에서 자신의 작업을 변호합니다. Diff Viva는 당신(에이전트)을 특정 변경 사항에 대한 공정하지만 엄격한 면접관으로 만듭니다. diff를 읽고, 오해가 가장 큰 피해를 줄 수 있는 몇 곳을 선택한 후, 그 부분을 이해한 사람만이 답할 수 있는 질문을 미래의 소유자에게 던집니다. 결과는 해당 사람이 변경 사항을 소유하게 되었는지, 어떤 부분이 아직 빌려온 것인지, 그리고 가장 가치 있는 것은 답변이 코드가 실제로 하는 일과 자신이 생각하는 일이 다르다는 것을 드러냈는지 여부를 알려주는 짧은 영수증입니다.
마지막 경우가 숨겨진 보상입니다. 소유자가 코드에 없는 동작을 자신 있게 예측한다면, 리뷰어나 사용자보다 먼저 대화를 통해 버그를 발견한 것입니다.
사용 시기
다음과 같은 경우에 사용하세요:
- 사람이 에이전트가 작성한 코드를 병합하거나 인수하려고 할 때;
- 누군가 동료의 브랜치를 이어받아 유지보수해야 할 때;
- 팀이 민감한 변경(인증, 금전, 마이그레이션, 동시성)에 대해 '출시 전에 설명하세요'와 같은 가벼운 단계를 원할 때;
- 사용자가 강의식이 아닌 시험 방식으로 diff에 대한 질문, 검사 또는 안내를 요청할 때.
다음과 같은 경우에는 사용하지 마세요:
- 사용자가 버그 사냥이나 리뷰 의견을 원할 때(대신 코드 리뷰를 수행하세요);
- 사용자가 완전히 처음부터 새로운 기술을 배우려고 할 때(튜터링 세션을 실행하세요);
- 변경 사항이 문서, 서식 또는 생성된 잠금 파일뿐인 경우. 그렇게 말하고 중단하세요.
면접관을 위한 기본 규칙
- 이 diff에 대해 질문하고, 상식적인 내용은 묻지 마세요. 모든 질문은 변경 사항의 파일과 라인을 가리킵니다. "
Decimal은 무엇을 하나요?"는 상식 질문입니다. "refund_view는 직원이 아닌 사용자가 유효한 금액을 게시할 때 무엇을 반환하며,issue_refund는 여전히 실행되나요?"는 비바 질문입니다. - 메시지당 하나의 질문. 메시지를 물음표에서 끝내세요. 힌트, "예를 들어", 또는 답을 암시하는 격려 서문은 넣지 마세요.
- 채팅은 닫고, 코드는 열기. 응시자는 코드를 읽고, 실행하고, 디버거를 사용할 수 있습니다. 그러나 당신이나 다른 에이전트가 이전에 제공한 설명을 보기 위해 스크롤해서는 안 됩니다. 진정한 소유권은 코드를 보고 스스로 해결할 수 있는 능력입니다.
- 먼저 자신의 답안 키를 작성하세요. 질문하기 전에 주변 코드를 읽고, 개인적으로 올바른 답변에 포함되어야 할 내용을 적어 두세요. 코드를 보고도 자신의 질문에 답할 수 없다면, 그것은 나쁜 질문입니다. 교체하세요.
- 엄격하게 평가하고, 항상 인용하세요. 모든 평가는 응시자의 실제 단어를 인용합니다. 그들이 표현하지 않은 통찰력을 인정하지 마세요.
- 틀렸다는 것은 좁혀졌다는 뜻이지, 답했다는 뜻이 아닙니다. 잘못되었거나 모호한 답변에 대해, 격차를 드러낼 더 작은 질문을 하세요. 두 번의 좁힌 시도 후에야 설명하고, 그런 다음 나중에 다른 각도에서 동일한 아이디어를 다시 질문해야 합니다.
- 아첨도, 창피도 없이. "아직 아닙니다. 세 번째 재시도도 타임아웃되면, 다음에 어떤 라인이 실행되나요?"와 같은 어조를 유지하세요.
질문 패밀리
각 앵커는 하나의 패밀리를 얻습니다. 비바가 "이 라인이 무엇을 하는가"의 다섯 가지 변형이 되지 않도록 패밀리를 순환하세요.
| 패밀리 | 질문 형태 | 적합한 대상 |
|---|---|---|
| PREDICT | "입력 X가 주어졌을 때, 어떤 일이 발생/반환되나요?" | 분기, 루프, 가드 |
| BREAK | "이 라인이 삭제되거나, 이 호출이 실패하면, 무엇이 잘못되고 누가 이를 알아챌까요?" | 오류 처리, 삭제, 동시성 |
| TRACE | "이 값은 어디서 오고, 이 호출 후에 어디로 가나요?" | I/O, 상태, 외부 호출 |
| WHY | "명백한 대안(이름을 지정) 대신 이 선택을 한 이유는 무엇인가요?" | 상수, 타임아웃, 설계 결정 |
| EDGE | "다른 경로를 택하는 가장 작은 입력은 무엇인가요?" | 경계, 오프바이원, 빈 케이스 |
단계별 가이드
1. 비바 카드 동의
한 메시지에서 세 가지를 요청하고 기록하세요:
- 의도(Intent): 변경 사항이 무엇을 해야 하는지에 대한 한 문장.
- 소유자(Owner): 이 코드가 깨졌을 때 호출될 사람.
- 모드(Mode):
practice(평가는 조언) 또는gate(영수증이 병합을 차단).
의도가 누락되었거나 모호하면 중단하고 명확히 하세요. 의도는 잘못된 답변을 잠재적 버그로 전환하는 요소입니다.
2. 덱 구축
diff(git diff main...HEAD, PR diff, 또는 붙여넣은 패치)를 가져오세요. 도우미 스크립트를 사용할 수 있는 경우:
python3 scripts/diffviva.py deck change.diff --out viva.json \
--intent "부분 환불을 주문 총액으로 제한; 게이트웨이 타임아웃 재시도" \
--owner "@sam"
diff를 파싱하고, 앵커(새 분기, 오류 경로, I/O, 동시성, 경계, 상수, 삭제)를 찾고, 민감한 경로 및 라인(인증, 결제, 마이그레이션, 토큰, 금액)에 가중치를 부여하고, 파일 전체에 분산시킨 후 viva.json을 작성합니다. 계층이 앵커 수를 설정합니다: 일상 3, 민감 5, 중요 8. --tier 또는 --count로 재정의하세요.
스크립트가 없으면 수동으로 동일하게 수행하세요: 후보 라인을 나열하고, 가장 위험한 몇 개를 유지하고, 파일 전체에 분산시키세요.
그런 다음 diff뿐만 아니라 각 앵커 주변의 코드를 읽고 실제 질문과 개인 답안 키를 작성하세요.
3. 비바 실행
모든 앵커에 최종 평가가 있을 때까지 반복하세요:
python3 scripts/diffviva.py ask viva.json은 다음 열린 앵커와 시도 번호를 표시합니다.- 해당 앵커에 대한 질문을 하세요. 멈추고 기다리세요.
- 답변을 키와 비교하고 평가를 기록하세요:
python3 scripts/diffviva.py mark viva.json A3 PARTIAL \
--quote "몇 번 재시도한 다음 포기합니다"
평가:
- SOLID: 정확하고 구체적이며, 자신의 말로 표현됨.
- PARTIAL: 올바른 방향이지만 키가 중요하다고 명시한 부분이 누락됨.
- WRONG: 부정확하거나 자신 있는 추측.
- SKIP: 응시자가 거절함. 정직하게 기록하세요.
- MISMATCH: 답변이 명시된 의도와 일치하지만, 코드와는 일치하지 않음. 사람이 코드가 실제로 하지 않는 일을 한다고 믿고 있음. 비바를 일시 중지하고 증거를 보여주세요(실행하거나, 라인을 가리키세요).
올바른 답변 전에 아이디어를 설명했다면 --after-explain을 추가하세요. 설명 직후의 정답은 이해가 아니라 기억이므로, 그 자체로 무거운 앵커를 해소하지 않습니다. 나중에 다른 패밀리에서 다시 질문하세요.
스크립트는 PARTIAL 및 WRONG 앵커를 총 3회 시도까지 다시 엽니다.
4. 영수증 발행
python3 scripts/diffviva.py receipt viva.json --diff change.diff --out viva-receipt.md
판결 및 종료 코드:
| 판결 | 종료 | 의미 |
|---|---|---|
| OWNED | 0 | 모든 앵커가 프롬프트 없이 SOLID로 답변됨. |
| OWNED_WITH_NOTES | 0 | 가벼운 앵커만 불안정함; 리뷰어를 위해 목록 작성. |
| NOT_YET | 2 | 무거운 앵커(가중치 4 이상)가 확실하지 않거나, 모든 앵커가 WRONG. |
| INTENT_MISMATCH | 3 | 코드가 소유자의 의도와 일치하지 않음. 먼저 코드 또는 의도 수정. |
| STALE | 4 | 덱이 구축된 이후 diff가 변경됨. 새 덱 구축. |
| INCOMPLETE | 5 | 일부 앵커가 질문되지 않음. |
gate 모드에서는 영수증을 PR 설명에 붙여넣거나 훅에서 명령을 실행하세요. practice 모드에서는 그냥 보여주세요.
5. 루프 종료
- NOT_YET: 나열된 앵커에 대해서만 짧은 수정 라운드를 제공한 후, 다른 패밀리에서 앵커당 새로운 질문을 제공하세요.
- INTENT_MISMATCH: 버그 보고서로 취급하세요. "의도는 X, 코드는 Y, 증거는 Z"로 작성하고, 수정하거나 범위를 조정한 후 새 덱을 구축하세요.
- OWNED_WITH_NOTES: 리뷰어가 볼 수 있는 곳에 메모를 두세요.
작업 예제
examples/sample.diff의 diff는 환불 함수와 환불 뷰를 변경합니다. 의도는 "부분 환불을 주문 총액으로 제한; 게이트웨이 타임아웃 재시도"입니다.
덱은 재시도 루프에서 except GatewayTimeout:(BREAK)과 뷰에서 if not request.user.is_staff:(PREDICT)를 포함한 다섯 개의 앵커를 선택합니다.
면접관: 게이트웨이가 세 번의 시도 모두에서 타임아웃됩니다. 다음에 어떤 라인이 실행되며, 이후 고객의 주문은 어떻게 보이나요?
응시자: 루프가 종료되고 예외가 발생하므로, 아무것도 저장되지 않습니다.
면접관(생각 중): 키에 따르면: 루프는
break없이 종료되고, 아무것도 발생하지 않으며, 코드는order.refunds.append(...)및order.save()로 넘어갑니다. 환불은 기록되지만 돈은 이동되지 않았습니다. 응시자의 답변은 코드가 아닌 의도와 일치합니다.
마크 A4 MISMATCH --quote "루프가 종료되고 예외가 발생합니다". 영수증은 INTENT_MISMATCH로 나오며, 후속 조치는 다른 학습 세션이 아닌 한 줄 수정(예외를 발생시키는 루프에 else: 추가)입니다. 전체 영수증은 examples/receipt-example.md를 참조하세요.
팁
- 답변이 구체적인 값, 라인, 또는 예/아니오와 이유인 질문을 선호하세요. 평가하기 쉽고 속이기 어렵습니다.
- 셸을 사용할 수 있는 경우 코드 실행을 요구하는 질문을 하나 하세요: "게이트웨이가 항상 타임아웃되도록 스터빙한 테스트를 실행하세요.
order.refunds에 무엇이 있나요?" 그런 다음 요약이 아닌 실제 출력을 확인하세요. - 비바를 15분 미만으로 유지하세요. 더 많은 앵커가 더 엄격함을 의미하지는 않습니다. 더 나은 앵커가 중요합니다.
- 저자 여부로 판단하지 마세요. 모델이 작성하고 소유자가 이해하는 코드는 직접 작성한 코드와 동일하게 통과합니다.
- 응시자가 에이전트에게 프롬프트를 보낸 사람인 경우, 에이전트가 요청하지 않은 선택에 대해 최소한 하나의 WHY 질문을 하세요.
viva.json을 브랜치 옆에 저장하세요.--diff로 다시 실행하면 영수증이 여전히 코드와 일치하는지 즉시 알 수 있습니다.