가상의 할 일 앱에서 AI에게 “완료 표시를 넣어 주세요”라고 요청한 상황을 생각해 보겠습니다. 잠시 뒤 체크박스뿐 아니라 목록 정렬, 색상, 데이터 저장 방식까지 달라진 코드가 나왔습니다. 화면은 그럴듯합니다. 이제 이 변경을 받아들여도 될까요?
PR(Pull Request)은 코드 변경을 합치기 전에 목적과 차이, 검증 근거를 함께 검토하는 요청입니다. AI가 만든 변경을 한곳에 모아, 무엇이 달라졌고 어떤 근거로 받아들일지 검토하는 자리입니다. 좋은 PR은 검토자가 변경의 목적과 확인 방법을 따라갈 수 있는 크기를 가집니다. AI가 긴 설명과 테스트를 함께 만들었다고 해서 이 조건이 저절로 충족되지는 않습니다.
개인용 할 일 앱을 예로 들어 보겠습니다. 아래 화면과 PR 설명은 이해를 위한 가상 예시입니다. 목표는 ‘할 일을 완료로 바꾸고, 새로고침해도 그 상태가 남게 하기’입니다.
PR(Pull Request)이란 무엇인가
PR은 Pull Request의 줄임말입니다. 별도의 작업 공간에서 바꾼 코드를 기준이 되는 코드에 합쳐 달라고 제안하는 요청입니다. GitHub에서는 변경된 파일, 대화, 리뷰 의견, 자동 검사 결과를 함께 살펴볼 수 있습니다. GitHub의 PR 설명도 변경을 합치기 전에 논의하고 검토하는 기능으로 소개합니다.
여기서 몇 가지 용어를 구분하면 흐름이 쉬워집니다. 브랜치는 변경을 진행하는 작업 갈래이고, 커밋은 그 갈래에 남긴 변경 기록입니다. 여러 커밋을 하나의 PR에 담을 수 있습니다. diff는 기존 코드와 바뀐 코드의 차이이며, **merge(병합)**는 변경을 대상 브랜치에 합치는 일입니다.
‘AI PR’도 별도의 파일 형식은 아닙니다. AI가 코드를 만들거나 설명을 작성한 PR, 또는 AI 리뷰를 활용하는 PR을 가리키는 표현입니다. 이 글에서는 AI가 만든 변경을 사람이 검토하는 상황에 초점을 맞춥니다.
- 작업별도 브랜치에서 완료 표시와 상태 저장을 구현하고 커밋합니다.
- PR무엇을 바꾸려는지 설명하고 변경 파일과 확인 근거를 모읍니다.
- 리뷰와 수정다른 사람이나 AI의 지적을 검토하고, 수정된 코드로 다시 검사합니다.
- 병합필요한 검토와 검사를 마친 변경을 기준 브랜치에 합칩니다.
병합과 배포, 즉 사용자가 이용하는 환경에 변경을 내보내는 일은 구분해야 합니다. 저장소 설정에 따라 병합 직후 자동 배포될 수도 있고 별도 작업이 필요할 수도 있습니다. 따라서 PR을 승인할 때는 병합 후 어떤 작업이 이어지는지도 알아야 합니다.
혼자 만드는 앱에도 PR은 쓸모가 있습니다. 코드를 만든 순간과 받아들이는 순간을 나누고, 나중에 “왜 이렇게 바꿨지?”를 되짚을 기록이 생깁니다. 다만 혼자 열고 혼자 읽었다는 이유만으로 다른 사람의 검토를 받은 것과 같아지지는 않습니다.
AI에게 코딩을 맡기기 전 정할 작업 범위
AI가 완성한 뒤 “이 저장 방식은 쓰지 않아요”라고 말하면 작성자와 리뷰어가 같은 기능을 다시 살펴야 합니다. 완료 기능을 맡기기 전에 새로고침 뒤에도 남아야 하는지, 이전 목록은 어떻게 읽을지, 기존 저장 함수를 재사용할지를 먼저 정하면 구현 후 확인할 기준이 생깁니다.
AI에게는 곧바로 코드를 만들게 하기보다 다음처럼 요청할 수 있습니다.
먼저 기존 완료 상태와 저장 흐름을 읽어 주세요. 사용자에게 달라질 동작, 수정할 코드와 재사용할 함수, 이전 데이터 처리, 실패 시 화면 동작을 짧게 제안해 주세요. 기존 구조를 바꿔야 한다면 이유를 설명하고, 결정되지 않은 부분을 표시해 주세요. 계획을 검토한 뒤 완료 상태 저장에 필요한 변경을 진행하겠습니다.
이 예시에서 논의할 쟁점은 ‘완료 기능’이라는 큰 이름보다 작고 구체적입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 사용자 동작 | 체크 표시의 의미 | 새로고침 뒤에도 완료 상태가 남아야 합니다. | 화면에 체크만 표시하는 구현으로 끝나지 않도록 합니다. |
| 저장 구조 | 기존 목록과의 호환 | 기존 저장 경로에 완료 값을 추가하고, 값이 없는 이전 항목의 의미를 정합니다. | 새 저장소를 별도로 만들기 전에 기존 읽기·쓰기 함수를 확인합니다. |
| 실패 처리 | 저장되지 않은 체크 | 저장 실패를 사용자에게 알리고 화면 상태를 어떻게 복구할지 정합니다. | 실패 안내와 상태 복구를 PR의 확인 항목에 넣습니다. |
계획이 있다면 리뷰에서 ‘합의한 접근과 실제 diff가 일치하는가’를 먼저 볼 수 있습니다. 구현 중 바뀐 결정은 이유를 PR에 남깁니다. 계획을 그대로 복사한 설명은 실제 코드가 달라졌을 때 오히려 검토를 방해합니다.
모든 변경에 긴 설계 문서가 필요한 것은 아닙니다. 작은 문구 수정은 목적과 화면 확인으로 충분할 수 있습니다. 데이터 형식이나 여러 기능의 연결이 달라지는 작업은 코딩 전에 주요 결정을 검토하는 편이 좋습니다. 이 절차를 반복 가능한 실행 환경에 넣는 방법은 하네스 엔지니어링: AI 코딩 설계·검증 방법에서 문의 폼 사례로 설명합니다.
좋은 PR 작성법: 제목·설명·검증 근거
‘할 일 앱 개선’이라는 제목만으로는 검토자가 어디까지 확인해야 할지 알기 어렵습니다. ‘완료 상태를 저장해 새로고침 후에도 유지’라는 제목이면 확인할 동작이 드러납니다. GitHub도 PR에 문제, 접근 방법, 결과와 집중해서 볼 부분을 설명하도록 안내합니다. 리뷰를 돕는 PR 작성 지침
이 예시에서 좋은 PR 설명은 다음처럼 쓸 수 있습니다. 실제 PR에는 ‘확인 예정’인 항목을 실행 결과와 증거로 바꿔 적습니다.
제목: 완료 상태를 저장해 새로고침 후에도 유지
문제: 완료 표시를 해도 새로고침하면 미완료로 돌아옵니다.
변경: 완료 여부를 기존 할 일 저장 구조에 함께 기록하고, 앱을 다시 열 때 읽습니다. 기존 저장 데이터에 완료 값이 없으면 미완료로 처리합니다.
확인 예정: 완료→새로고침→상태 유지, 완료 취소→새로고침→미완료 유지, 기존 할 일 불러오기, 저장 실패 시 안내를 확인합니다.
집중 리뷰: 이전에 저장한 목록을 읽는 처리와 저장 실패 시 화면이 잘못된 성공 상태를 보이지 않는지 봐 주세요.
범위: 필터·목록 정렬·테마 변경은 후속 작업입니다.
좋은 설명은 길이보다 판단에 필요한 정보로 결정됩니다. 화면이 바뀌면 전후 화면이 도움이 되고, 저장 방식이 바뀌면 이전 데이터와 호환되는지 설명해야 합니다. “테스트 통과”라고 적을 때도 검사한 코드 버전과 실행한 검사, 결과를 연결해야 다른 사람이 근거를 찾을 수 있습니다.
AI에게 설명을 맡기더라도 작성자는 diff와 대조해야 합니다. “상태 저장을 추가했습니다”라는 문장이 정확해 보여도 실제로는 화면 안에서만 값을 바꿨을 수 있습니다. 설명은 검토의 출발점이고, 코드와 동작이 이를 뒷받침해야 합니다.
PR 코드 리뷰 순서: 요구사항·변경·실패 확인
먼저 어떤 동작이면 성공인지 정합니다. 이 앱에서는 완료 표시, 새로고침 후 유지, 완료 취소, 기존 데이터 보존이 기준입니다. 이 기준 없이 코드를 먼저 읽으면 이름이나 들여쓰기에는 의견을 내면서 정작 저장 누락은 지나칠 수 있습니다.
그다음 변경 파일 목록을 훑습니다. 완료 기능에 필요한 화면과 저장 코드가 바뀌는 것은 자연스럽습니다. 그런데 로그인 설정이나 배포 설정까지 달라졌다면 이유를 물어야 합니다. 목적과 맞지 않는 변경을 먼저 찾으면 읽을 범위가 정리됩니다.
이제 실제 흐름을 따라갑니다. 사용자가 체크박스를 누르면 어떤 값이 바뀌는지, 그 값이 어디에 저장되는지, 다시 열었을 때 어디서 읽는지를 연결해 봅니다. diff에 표시된 줄만으로 이해되지 않으면 그 코드를 부르는 부분과 기존 저장 형식도 확인합니다.
동작 확인은 정상 상황 다음에 경계와 실패 상황으로 넓힙니다. 완료를 다시 취소해도 저장되는지, 오래전에 만든 할 일이 그대로 열리는지, 저장이 실패했는데도 화면만 성공한 것처럼 남아 있지는 않은지 확인합니다. 여기서 실패 처리가 필요하다는 판단은 테스트 개수보다 사용자에게 생기는 결과에서 나옵니다.
동작이 맞다면 다음에 고치기 쉬운 구조인지도 살펴봅니다. 다음 PR에서 ‘완료한 항목만 보기’를 붙일 때 기존 목록의 완료 값을 읽으면 되는지, 서로 다른 화면이 각자 완료 목록을 저장해 맞춰야 하는지 비교해 보세요. 후자의 구조라면 완료를 취소했을 때 두 저장값이 어긋날 가능성을 검토해야 합니다. 테스트 통과 여부와 별개로, 같은 상태를 두 곳에서 관리해야 하는 이유가 설명돼야 합니다.
그렇다고 앞으로 생길 모든 기능에 대비하라는 뜻은 아닙니다. 이미 예정된 필터처럼 가까운 요구 하나를 대입하면 충분합니다. 필요한 구조 변경은 근거를 남기되, 이번 목적과 관계없는 전면 재작성은 별도 제안으로 분리합니다.
코드를 자세히 읽기 어려운 사람도 요구사항과 미리보기 동작, 변경 범위, 검사 기록은 확인할 수 있습니다. 다만 로그인 권한이나 결제, 개인정보 처리처럼 화면만으로 안전을 판단하기 어려운 변경은 해당 코드를 이해하는 검토자가 필요합니다. 같은 AI에게 “문제없지?”라고 다시 묻는 것만으로 그 공백이 채워지지는 않습니다.
AI에게 별도 리뷰를 맡길 때는 지적의 근거를 요구합니다. “잘 작성됐습니다”라는 평가보다 문제 위치, 발생 조건, 사용자에게 생기는 결과, 확인 방법이 있어야 판단할 수 있습니다. GitHub도 Copilot의 리뷰에 잘못된 지적이나 놓친 문제가 있을 수 있으며, 제안된 변경을 검토해야 한다고 설명합니다. AI 리뷰의 용도와 한계
예를 들어 이런 요청이 도움이 됩니다.
이 PR의 목적은 완료 상태를 새로고침 후에도 유지하는 것입니다. diff와 관련 저장·불러오기 코드를 읽고 요구사항 누락, 기존 데이터 손상, 저장 실패 처리를 검토해 주세요. 각 지적에는 파일 위치, 문제가 발생하는 입력이나 순서, 예상되는 영향, 확인할 테스트를 적어 주세요. 실행하지 않은 검사는 실행하지 않았다고 구분해 주세요. 이번 단계에서는 코드를 수정하지 말고 검토 결과만 제시해 주세요.
다른 모델이나 새 대화에 검토를 맡기면 다른 관점이 나올 수 있지만 독립적인 검증이 보장되지는 않습니다. 요구사항과 기존 구조를 전달하지 않으면 검토자도 같은 조건을 놓칠 수 있습니다. 중요한 지적은 실제 코드와 재현 가능한 검사로 확인해야 합니다.
이 검토를 매번 같은 기준으로 반복하려면 작업 지침, 검사 도구, 리뷰 근거와 중단 조건을 함께 설계해야 합니다. 그 구조는 하네스 엔지니어링: AI 코딩 설계·검증 방법에서 문의 폼 사례로 자세히 이어갑니다.
코드 리뷰 의견을 수정과 재검증으로 연결하기
“저장 처리가 이상합니다”라는 의견만 받으면 작성자는 무엇을 고칠지 다시 물어야 합니다. 다음처럼 조건과 결과를 적으면 수정과 재검토까지 이어집니다.
병합 전 수정 요청: 저장 호출이 실패해도 체크 표시가 유지됩니다. 저장이 실패하도록 만든 뒤 완료 버튼을 누르면, 사용자에게는 완료된 것으로 보이지만 새로고침하면 미완료로 돌아옵니다. 실패 안내를 표시하고 화면 상태를 복구하는 처리가 필요합니다. 이 경우를 확인하는 테스트도 함께 검토하고 싶습니다.
이 예시에서는 어디가 문제인지, 왜 중요한지, 어떤 조건으로 확인할지가 연결됩니다. 반대로 변수 이름에 대한 개인 취향이라면 ‘선택 제안’으로 표시하는 편이 좋습니다. 질문, 병합을 막는 문제, 선택 가능한 개선을 구별해야 작성자가 우선순위를 알 수 있습니다.
작성자는 모든 의견을 그대로 받아들일 필요가 없습니다. 기존 코드가 이미 실패를 처리한다면 해당 위치와 근거를 알려 주고 논의하면 됩니다. 수정했다면 바뀐 부분과 다시 실행한 검사를 남깁니다. 의견을 해결했다고 표시하는 것과 문제가 해결됐음을 확인하는 일은 별개입니다.
기능별 PR 분할: 얼마나 작게 나눠야 할까
대체로 한 목적에 집중한 작은 PR이 검토하기 쉽습니다. GitHub도 변경이 커지면 각각 하나의 목적을 갖도록 나누라고 권합니다. 하지만 ‘작다’를 파일 수나 코드 줄 수만으로 정하면 필요한 동작을 중간에서 끊을 수 있습니다. 작고 명확한 PR 지침
할 일 앱에 완료 표시, 완료한 항목만 보기, 어두운 테마를 추가한다면 세 작업은 따로 판단할 수 있습니다. 완료 상태를 저장하고 불러오는 기능을 먼저 검증하고, 그 상태를 이용하는 필터를 다음에 붙일 수 있습니다. 테마 변경은 별도로 검토할 수 있습니다.
반면 완료 기능을 ‘체크박스 화면 PR’과 ‘저장 PR’로 무조건 쪼개면, 첫 PR을 합친 시점에 저장되지 않는 완료 기능이 사용자에게 노출될 수 있습니다. 작은 기능이라면 화면·저장·관련 테스트를 함께 담는 것이 자연스럽습니다. 기준은 그 변경만 합쳤을 때 약속한 동작을 확인할 수 있고, 기존 동작도 유지되는가입니다.
이처럼 화면·처리·저장을 지나 사용자 동작 하나를 완성하는 방식을 **수직 분할(vertical slice)**이라고 부릅니다. 기능별로 나눌 때도 ‘완료 기능 전체’가 너무 크다면 독립적으로 확인 가능한 흐름을 더 찾습니다. 반대로 한 흐름에 필요한 코드를 파일 종류에 따라 억지로 나누지는 않습니다. 변경 줄 수가 적어도 권한 확인 한 줄의 영향은 클 수 있고, 길어도 같은 규칙을 일관되게 적용한 변경은 목적이 분명할 수 있습니다. 분량과 위험을 함께 판단해야 합니다.
큰 기능은 준비 작업부터 나눌 수 있습니다. 예를 들어 이전 데이터도 읽을 수 있게 저장 형식을 확장하고, 다음 PR에서 새 기능을 연결하는 방식입니다. 준비 PR 자체도 검증 가능해야 합니다. 미완성 기능을 숨기는 기능 플래그를 쓴다면 기본값, 활성화 시점, 나중에 제거할 조건까지 관리해야 합니다.
앞 PR에 의존하는 다음 PR을 미리 열 수도 있습니다. 이때는 의존 관계와 병합 순서를 설명하고, 앞선 변경이 수정되거나 병합된 뒤 뒤쪽 PR의 차이와 검사를 다시 확인해야 합니다. PR 수를 줄이려고 모든 변경을 한데 묶는 것과, PR 수를 늘리려고 한 동작을 잘게 끊는 것 모두 검토를 어렵게 만들 수 있습니다.
‘되돌리기 쉬운가’도 좋은 분할 질문입니다. 테마 변경만 되돌리는 것과 저장 구조까지 바뀐 변경을 되돌리는 것은 부담이 다릅니다. 특히 데이터 형식이나 실제 저장 데이터가 바뀌었다면 코드 병합을 되돌리는 것만으로 데이터까지 복구되지는 않습니다. 이런 PR에는 복구 방법과 호환성을 별도로 설명해야 합니다.
작은 PR을 한꺼번에 많이 열어도 괜찮을까
PR 하나의 크기와 동시에 열어 둔 PR 수는 다른 문제입니다. 작은 변경이라도 같은 파일을 고치는 PR이 쌓이면 서로 충돌하고, 먼저 합친 변경 때문에 뒤 PR의 전제가 달라질 수 있습니다. 검토자는 여러 대화와 검사 결과를 오가야 합니다.
여러 AI 작업의 폴더를 나누고 담당 범위 밖 커밋을 검사하는 방법은 Git worktree 사용법: Husky로 AI 병렬 코딩 충돌 줄이기에 정리돼 있습니다. worktree는 작업 공간을 나누고, Husky는 Git 훅으로 검사를 실행합니다. 두 도구를 쓴다고 모든 충돌이나 통합 오류가 사라지는 것은 아닙니다.
처음에는 완료 기능 하나를 검토하고 병합한 뒤 필터를 진행하는 방식으로 시작해 보세요. 테마처럼 별개로 진행할 수 있는 작업은 병렬로 준비하되 같은 코드와 설정을 건드리는지 확인합니다. 앞선 작업의 결정이 자주 바뀐다면 후속 PR을 많이 열기보다 설계와 완료 기준부터 정리하는 편이 낫습니다.
리뷰가 밀릴 때는 대기 원인을 나눠 봅니다. 요구 해석이 매번 달라져 재작업한다면 구현 전 합의를 보완합니다. 근거를 찾느라 오래 걸린다면 PR 설명과 검사 기록을 정리합니다. 변경의 품질이 괜찮아도 검토할 사람이 부족하면 동시에 시작하는 작업을 줄이거나 검토 시간을 확보해야 합니다. 좋은 PR도 검토에는 시간이 필요합니다.
새 PR을 계속 만드는 대신 열린 PR의 실패 검사와 리뷰 의견을 먼저 해결하는 운영을 시도해 볼 수 있습니다. ‘진행 중 작업 수’라는 뜻의 WIP를 관리하는 방법입니다. 고정된 정답 개수를 정하기보다, 가장 오래 기다리는 PR의 이유와 다시 수정하는 횟수를 살펴 조정합니다. 생성량보다 검증을 마치고 실제로 받아들인 변경을 기준으로 속도를 봅니다.
이미 큰 PR이 만들어졌다면 작성자에게 변경 목적별 목록과 의존 순서를 먼저 요청합니다. 기능과 무관한 코드 정리, 전체 서식 변경을 분리할 수 있는지 살피고, 나눈 각 결과가 빌드와 필요한 검사를 통과하는지 확인합니다. 이미 검토 중인 브랜치를 재구성할 때는 리뷰 의견이 어느 변경에 해당하는지 추적할 수 있도록 분할 내역도 남깁니다.
이 글에서 권하는 기준은 ‘AI가 몇 개를 동시에 만들 수 있나’보다 ‘지금 열려 있는 변경을 사람이 설명하고 검토할 수 있나’입니다. 정답인 동시 PR 개수는 프로젝트와 검토 인력에 따라 달라집니다.
PR 리뷰 자동화: CI·AI 리뷰·병합 조건
반복되는 검사는 CI에 맡길 수 있습니다. CI는 변경이 올라올 때 정해진 검사를 자동으로 실행하는 과정이며, GitHub Actions는 이를 구성하는 도구 중 하나입니다. 코드 서식, 정적 검사, 타입 검사, 빌드, 기능 테스트처럼 프로젝트에 필요한 항목부터 정합니다.
자동 검사가 초록색이라고 모든 동작이 확인된 것은 아닙니다. 완료 버튼을 누르는 테스트만 있다면 새로고침 후 상태 유지 문제는 남을 수 있습니다. AI가 구현과 테스트를 함께 만들었을 때도 테스트가 원래 요구사항을 검사하는지 읽어야 합니다. 잘못 구현한 동작을 정답으로 적은 테스트는 오류를 발견하지 못합니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 반복 검사 | 정해진 조건 확인 | CI가 같은 절차를 실행하고 로그와 결과를 남깁니다. | 완료 후 다시 불러와도 완료 상태인지 검사합니다. |
| AI 리뷰 | 놓친 문제 후보 찾기 | 변경과 주변 코드를 읽고 의심되는 부분을 설명합니다. 지적은 확인해야 합니다. | 이전 데이터에 완료 값이 없을 때의 처리 누락을 지적합니다. |
| 사람의 판단 | 요구와 위험 수용 | 원하는 동작인지, 확인 근거가 충분한지, 남은 위험을 받아들일지 결정합니다. | 기존 목록 보존과 실패 안내를 확인한 뒤 병합을 승인합니다. |
도입할 때는 다음 순서로 연결해 보세요. 이는 이 예시에 적용할 수 있는 구성 제안입니다.
- 완료 기준을 검사로 옮깁니다. 할 일 앱에서는 완료·취소·다시 불러오기·기존 데이터 읽기를 대상으로 삼습니다. 어떤 실패를 막으려는 검사인지 설명할 수 있어야 합니다.
- PR 생성과 새 커밋에 검사를 실행합니다. 결과를 PR에서 확인하고, 문제가 생기면 로그를 따라갈 수 있게 합니다. 검사 실패를 무시하고 성공으로 처리하는 설정은 목적에 맞지 않습니다.
- 검사를 병합 조건으로 연결합니다. 브랜치 보호나 저장소 규칙에서 필요한 검사를 지정하고, 팀 작업이면 리뷰 승인도 요구합니다. 검사를 실행하는 설정만으로 병합 차단까지 되는 것은 아닙니다.
- AI 리뷰를 보조로 붙입니다. 프로젝트의 요구사항과 집중 검토 경로를 전달하고, 근거 없는 지적을 걸러 냅니다. AI의 ‘문제없음’을 사람의 승인과 같은 신호로 취급하지 않습니다.
- 수정 후 유효성을 다시 확인합니다. 코드가 바뀌면 검사 결과도 그 버전에 대응해야 합니다. 리뷰 후 새 변경이 들어왔을 때 승인을 다시 받는 정책도 정합니다.
GitHub의 보호 브랜치에서는 필수 상태 검사와 리뷰 승인, 변경 이후의 승인 처리 등을 설정할 수 있습니다. 저장소 공개 여부와 플랜에 따라 사용 가능한 기능이 다르므로 자신의 저장소 조건을 확인해야 합니다. 보호 브랜치 설정과 제공 범위
로컬의 빠른 검사와 CI의 통합 검사를 나누는 기준, Husky 훅을 우회해도 CI가 직접 검사해야 하는 이유는 worktree·Husky 글의 CI 보완 설명에서 이어서 볼 수 있습니다.
자동화에 줄 권한도 이 단계에서 정합니다. 검사와 리뷰만 하는 작업에 배포용 비밀값이나 광범위한 쓰기 권한까지 줄 필요는 없습니다. 외부 기여자의 PR 코드와 PR 제목·본문은 신뢰할 수 없는 입력으로 다뤄야 합니다. 특히 권한이 높은 작업에서 외부 PR의 코드를 실행하는 구성은 피해야 합니다. GitHub의 Actions 보안 지침은 토큰의 최소 권한과 신뢰할 수 없는 입력 처리를 다룹니다.
자동 병합은 그 다음 판단입니다. 먼저 필수 검사와 승인 조건이 실제로 병합을 막는지 확인하고, 영향 범위가 작은 변경부터 적용 범위를 정하는 것이 좋습니다. 데이터 변경이나 권한 변경은 작은 diff라도 검토 부담이 클 수 있습니다. ‘AI가 만들었고 검사도 통과했으니 모두 자동 병합’처럼 출처 하나로 기준을 대신하기는 어렵습니다.
다음 AI 작업에서는 구현 전에 이렇게 범위를 잡아 볼 수 있습니다.
할 일 앱에 완료 상태 저장을 추가해 주세요. 먼저 독립적으로 검토할 수 있는 PR 범위와 완료 기준을 제안해 주세요. 완료·취소·새로고침 후 유지·기존 데이터 읽기·저장 실패를 검토 항목에 넣어 주세요. 필터와 테마는 후속 작업으로 두고, 이번 변경에 필요한 화면·저장 코드·테스트는 함께 계획해 주세요. 구현 뒤에는 실제 diff와 실행 기록을 근거로 PR 설명을 작성하고, 실행하지 못한 검사는 따로 밝혀 주세요.
이 요청에서 중요한 것은 PR을 몇 개 만들라는 숫자가 아닙니다. 한 번에 무엇을 판단할지 합의하고, 그 판단을 뒷받침할 근거를 남기는 것입니다. 그 단위가 잡혀야 작은 PR도, AI 리뷰도, 자동 검사도 같은 목표를 향해 움직입니다.
VIEW—
