전체 가이드

Claude Code, Codex, OpenCode 세션에서 마지막 턴에 무엇이 바뀌었는지 검토하는 방법 (diff 요약)

나중에 돌아와 "무엇이 바뀌었지?"에 빠르게 답하는 실용적인 방법: 도구 타임라인, diff로 이동, 휴대폰에서도 통하는 턴 종료 검토 루프.

기준 버전
CLI
0.2.17
프리뷰 ref
a2c45c8

긴 세션을 돌리다 보면 결국 이런 순간이 옵니다.

한 시간 뒤(또는 다음 날) 돌아왔는데 단순한 질문 하나에도 답할 수 없습니다.

무엇이 바뀌었지?

트랜스크립트는 깁니다.

도구 호출은 흩어져 있습니다.

그리고 휴대폰이라면 스크롤 자체가 실패의 원인이 됩니다.

그러니 "전부 읽으려" 하지 마세요.

대신 diff와 도구 타임라인을 중심으로 작은 검토 루프를 만드세요.

이 가이드가 그 루프입니다.

요약

  1. 트랜스크립트 전체를 다시 읽지 마세요. "무엇이 바뀌었나" 화면에서 시작하세요:
    • 수정된 파일
    • diff
    • 도구 호출
  2. 도구가 지원한다면 Claude Code/Codex/OpenCode의 도구 호출을 통일해 보여 주는 도구 타임라인을 쓰세요.
  3. 턴 종료 루프를 쓰세요:
    • 도구 타임라인 행 훑어보기
    • diff로 이동
    • 결정: 유지 / 되돌리기 / 나누기
  4. Happier는 모바일에서 이를 쉽게 해 주는 선택지 중 하나입니다. 트랜스크립트가 도구 호출을 전용 도구 표시(카드 또는 활동 피드)로 렌더링하고, 탭하면 파일/diff 화면으로 바로 이동합니다.

문제

피하고 싶은 건 일이 아닙니다.

끝없는 검토입니다.

"무엇이 바뀌었는지" 빠르게 볼 수 없으면 둘 중 하나가 됩니다.

  • 검토하지 않은 변경을 믿거나
  • 맥락을 다시 파악하느라 시간을 낭비하거나

검토 루프에는 끝이 있어야 합니다.

일반적인 방법과 트레이드오프

  • 트랜스크립트를 처음부터 끝까지 읽기: 짧은 실행에는 괜찮지만 긴 실행에는 형편없습니다.
  • git diff만 보기: 좋지만 변경이 왜 일어났는지 놓칩니다.
  • 모델에게 요약 요청: 도움이 되지만 그래도 실제 diff는 보고 싶습니다.

Happier가 처음이라면

Happier를 처음 본다면: 코딩 세션을 위한 오픈 소스 컴패니언 앱(모바일/웹/데스크톱)입니다.

이 가이드에서 관련 있는 부분은 UI 검토 루프입니다.

  • 도구 호출이 타임라인 행(또는 도구 카드)으로 표시됨
  • 타임라인 행을 탭하면 세부 정보로 이동
  • 도구 호출에서 diff/파일로 바로 이동 가능

설정하기:

실제로 쓸 수 있는 검토 루프

2분 버전 (휴대폰)

휴대폰에서는 "전체 검토"를 하려 하지 마세요.

범위를 정한 한 번의 확인만 합니다.

  1. 도구 타임라인 행을 훑어봅니다.
  2. 위험이 커 보이는 diff 하나로 이동합니다.
  3. 결정: 유지 / 되돌리기 / 요약 요청.

그리고 멈춥니다.

10분 버전 (키보드)

키보드 앞으로 돌아오면 더 깊이 봅니다.

  1. 변경된 파일 목록 검토.
  2. diff를 덩어리별로 검토.
  3. 변경을 커밋으로 나누기.
  4. 그대로 둘 것과 다시 할 것 결정.

이 가이드의 나머지는 두 가지 확인을 모두 예측 가능하게 만듭니다.

1) 턴 종료 "diff 요약" 도구 사용 (나타날 때)

Claude Code, Codex, OpenCode 세션에서 Happier는 턴이 끝날 때 마지막 턴 diff 요약 도구를 보여 줄 수 있습니다.

있다면 정보가 많은 출발점입니다. 이미 다음 범위로 좁혀져 있기 때문입니다.

  • "마지막 턴에 어떤 파일이 바뀌었나"
  • "에이전트가 실제로 무엇을 편집했나"

좋은 기본 순서:

  1. 마지막 턴 diff 요약을 탭합니다.
  2. 위험이 커 보이는 파일 하나를 먼저 엽니다.
  3. 괜찮아 보이면 계속합니다.
  4. 이상해 보이면 멈추고 파일별 이유를 요청합니다(또는 그 파일만 되돌립니다).

2) Source Control에서 마지막 턴 검토 ("진짜 diff" 화면)

빠르게 훑는 게 아니라 제대로 검토하고 싶다면 Source Control로 가세요.

데스크톱/넓은 레이아웃에서:

  1. 세션을 엽니다.
  2. 오른쪽 사이드바 → Source Control을 엽니다.
  3. 변경된 파일 목록에서 관심 있는 파일을 엽니다.
  4. diff를 검토합니다.

바꾸고 싶은 걸 찾았는데 채팅에서 지시를 다시 쓰고 싶지 않다면, diff에 바로 줄 단위 리뷰 코멘트를 추가하세요.

코멘트를 실행으로 옮길 준비가 되면:

  • 작성기의 Review comments (N) 칩 탭
  • 필요하면 맥락 한 문장 추가("이걸 적용하고 테스트 다시 실행해")
  • 전송

모호한 주고받기 대신 "정확히 이 변경을 적용해"라는 구조화된 메시지가 됩니다.

휴대폰/좁은 레이아웃에서도 흐름은 같습니다. 고정된 사이드바 대신 전체 화면 보기를 쓸 뿐입니다.

"끝없는 검토" 대신 "마지막 턴만"으로 유지하는 법:

  • 마지막 턴 diff 요약 도구에서 시작해 파일 1~3개를 고르고, 그 같은 파일을 Source Control에서 검토하세요.
  • 세션이 여러 턴 동안 실행되었다면, 현재 커밋되지 않은 것 전부를 검토하려 하지 마세요.

3) Files를 "범위를 좁힌 탐색기"로 쓰기 (수정된 것만 필터)

Files 탭은 Git 의미를 생각하지 않고 변경된 것의 짧은 목록을 원할 때 유용합니다.

  1. 세션을 엽니다.
  2. 오른쪽 사이드바 → Files를 엽니다.
  3. 수정된 것만 필터를 켭니다.
  4. 좁혀진 트리로 파일 사이를 이동합니다.

본격적인 diff 검토라면 최종 "유지/되돌리기?" 결정은 Source Control에서 하세요. Files는 방향을 잃지 않게 해 주는 좋은 방법입니다.

트랜스크립트를 스크롤하지 않아도 되는 깔끔한 검토 화면이 생깁니다.

4) (선택) 도구 타임라인을 "왜 이렇게 됐지?" 색인으로 쓰기

무언가가 왜 바뀌었는지 아직 모르겠다면, 도구 타임라인이 다음 질문에 답하는 보조 화면이 됩니다.

  • 어떤 명령이 실행됐나?
  • 설치/테스트 출력은?
  • 어떤 순서로 그 diff가 나왔나?

하지만 선택 사항입니다. 대부분의 검토는 diff 요약과 Source Control diff로 충분합니다.

5) 도구 세부 정보를 얼마나 깊이 볼지 정하기 (훑기 / 깊이)

도구 세부 정보를 줌 렌즈처럼 다루세요.

  • 훑기 모드: "어떤 도구가 실행됐나"를 보고 위험한 단계를 알아챌 정도.
  • 깊이 모드: 정확한 명령/출력이 필요할 때 도구 호출 하나를 엶.

핵심은 "도구 세부 정보"가 끝없이 다시 읽는 두 번째 트랜스크립트가 되지 않게 하는 것입니다.

6) 긴 턴은 항상 결정으로 끝내기 (유지 / 되돌리기 / 나누기)

턴 종료 검토의 결정은 항상 다음 중 하나입니다.

  • 모두 유지
  • 파일 하나 되돌리기
  • 변경을 커밋 2개로 나누기

핵심은 의도적으로 결정하는 것입니다.

특히 휴대폰에서 크게 도움이 되는 선택지가 하나 더 있습니다. "즉석에서 고치려" 하지 말고 리뷰 코멘트를 남기세요.

거의 맞는데 정확한 변경 몇 개가 필요하다면, 보통 이게 더 빠릅니다.

  1. diff에 바로 줄 단위 리뷰 코멘트 몇 개 추가
  2. Review comments (N) 칩으로 구조화된 메시지 하나로 전송

에이전트에게 관심 있던 정확한 줄에 고정된, 무엇을 바꿀지에 대한 문자 그대로의 체크리스트가 전달됩니다.

7) 재사용 가능한 "무엇이 바뀌었나?" 체크리스트

체크리스트 하나만 기억한다면 이것으로 하세요.

  • 어떤 파일이 바뀌었나?
  • 설정/인증/마이그레이션을 건드렸나?
  • 테스트를 실행했나?
  • 의존성이 바뀌었나?
  • 커밋하면 안 되는 생성물이 있나?

8) 올바른 종류의 요약 요청하기 (diff가 너무 클 때)

diff가 너무 커서 휴대폰으로 검토할 수 없다면 "요약해 줘"라고 하지 마세요.

구조화된 검토 도움을 요청하세요.

  • "바꾼 파일과 이유를 파일마다 한 문장으로 모두 나열해."
  • "기계적인 변경과 개념적인 변경은 무엇이야?"
  • "빌드를 깨지 않고 되돌릴 수 있는 변경은 무엇이야?"

다음 키보드 검토가 훨씬 빨라집니다.

유용한 워크플로: 인라인 리뷰 코멘트 → 구조화된 "이 변경을 적용해" 메시지 하나

휴대폰에서 검토할 때나 정확히 무엇을 바꿔야 하는지 명시하고 싶을 때 유용합니다.

"diff 고쳐 줘" 같은 모호한 메시지 대신, diff/파일에 바로 줄 단위 리뷰 코멘트를 남기고, 그걸 구조화된 메시지 하나로 에이전트에게 보낼 수 있습니다.

전체 흐름:

  1. Settings → Features에서 File review comments를 켭니다(실험적).
  2. diff를 엽니다(Source Control 또는 아무 diff 화면에서).
  3. 바꾸고 싶은 정확한 줄에 리뷰 코멘트 몇 개를 추가합니다.
  4. 작성기의 Review comments 칩(Review comments (N)으로 표시)을 탭하고, 필요하면 한 문장을 더한 뒤 전송합니다.

에이전트는 파일 경로, 줄 앵커, 코드 조각이 담긴 구조화된 "Review comments:" 블록을 받습니다. 그래서 관련 없는 코드를 다시 쓰는 대신 정확하게 변경을 적용할 가능성이 훨씬 높아집니다.

"세션 안에서 쓰는 GitHub PR 리뷰 코멘트" 같다고 느낀다면, 바로 그게 핵심입니다.

문제 해결

무엇이 바뀌었는지 모르겠음

  • 도구 타임라인에서 시작
  • 그다음 diff로 이동
  • diff를 쓸 수 없으면 파일별 목록과 이유 요청

타임라인이 시끄러움

훑기 모드(간결)로 바꾸고 다음을 찾으세요.

  • 편집/쓰기 도구
  • git 도구
  • 설치

위험한 변경을 놓칠까 걱정됨

"위험 필터"로 확인하세요.

  • 마이그레이션
  • 인증
  • 패키지 관리자 파일
  • CI 설정

다른 건 다 무시하더라도 이것들은 검토하세요.

FAQ

매 턴 검토해야 하나요?

매 턴은 아닙니다.

하지만 턴에서 의미 있는 파일 변경이 나왔다면 최소한 2분 버전은 하세요.

검토에서 흔한 큰 실수는?

검토를 끝없이 만드는 것입니다.

diff 요약 워크플로의 목적은 검토에 시작과 끝을 만드는 것입니다.

관련 가이드

diffreviewclaudecodexopencodeworkflowsmobile
마지막 업데이트: 2026-10-26