혼자 일할수록 리뷰어가 필요합니다
혼자 제품을 만들 때 가장 위험한 순간은 코드를 처음 작성할 때가 아닙니다. 오히려 더 위험한 순간은 "이 정도면 됐다"라고 생각하고 배포 버튼을 누르기 직전입니다. 기능은 돌아가는 것처럼 보이고, 테스트도 몇 개 통과했고, 화면도 그럴듯합니다. 그런데 바로 그때 빠진 조건 하나, 잘못된 권한 체크 하나, 엉뚱한 사용자 데이터 하나가 숨어 있을 수 있습니다.
팀에서는 이런 위험을 줄이기 위해 코드리뷰를 합니다. 다른 사람이 변경사항을 읽고 "이 경우는 어떻게 되나요?", "여기서 권한 확인이 빠진 것 같은데요?", "이 로직은 결제 실패 시에도 실행되지 않나요?"라고 묻습니다. 하지만 솔로 메이커에게는 그런 사람이 없습니다. 그래서 많은 1인 개발자는 스스로 코드를 작성하고, 스스로 승인하고, 스스로 장애를 맞습니다.
Cursor의 Review, Find Issues, Bugbot은 이 빈자리를 완전히 대체하지는 못합니다. 그러나 중요한 역할은 해 줍니다. 최소한의 두 번째 눈을 만들어 줍니다. 특히 AI Agent가 만든 코드를 다시 AI 리뷰어에게 검토시키면, 내가 너무 빨리 지나친 부분을 한 번 더 멈춰 세울 수 있습니다. Cursor가 소개하는 Bugbot은 PR에서 까다로운 로직 버그를 탐지하고, 실제 수정으로 이어질 가능성이 높은 문제를 찾는 데 초점을 둔다고 설명됩니다.1
이 장의 목표는 "AI가 리뷰해 주니 안심하자"가 아닙니다. 정반대입니다. AI가 만든 코드를 AI에게 먼저 의심하게 만들고, 마지막 판단은 사람이 하는 체계를 세우는 것입니다.
Agent가 만든 diff를 실시간으로 의심하기
코드리뷰는 PR을 올린 뒤에 시작되는 일이 아닙니다. Cursor에서는 Agent가 파일을 수정하는 순간부터 리뷰가 시작됩니다. Agent가 여러 파일을 바꾸고 있을 때, 우리는 종종 결과만 기다립니다. 화면 아래에서 파일명이 지나가고, diff가 쌓이고, 잠시 뒤 "Done"이라는 메시지가 뜹니다. 이때 한 번에 Accept All을 누르는 습관은 매우 위험합니다.
Agent가 만든 diff는 완성본이 아니라 초안입니다. 초안은 읽어야 합니다. 특히 다음 세 가지 순간에는 즉시 멈춰야 합니다.
Agent가 요청하지 않은 파일을 수정하기 시작할 때
기존 함수의 의미를 바꾸면서 테스트를 함께 고치지 않을 때
인증, 결제, 권한, 삭제, 마이그레이션 코드에 손을 대기 시작할 때
실시간 리뷰의 핵심은 "완료 후 평가"가 아니라 "진행 중 개입"입니다. Agent가 이상한 방향으로 가고 있다면 중간에 멈추고 이렇게 말해야 합니다.
잠깐 멈춰줘. 계속 수정하지 말고, 지금까지 바꾼 파일과 이유를 먼저 설명해줘.
특히 기존 동작이 달라지는 부분과 위험할 수 있는 부분을 구분해서 알려줘.이 프롬프트는 단순히 설명을 듣기 위한 것이 아닙니다. Agent의 속도를 늦추기 위한 브레이크입니다. 빠른 코딩 도구를 쓸수록 개발자에게 필요한 능력은 더 빨리 치는 손이 아니라, 더 빨리 멈추는 판단력입니다.
Cursor에서 diff를 볼 때는 전체 수락보다 부분 수락을 기본값으로 삼는 것이 좋습니다. 작은 UI 문구 변경, 타입 이름 정리, 테스트 파일 추가처럼 위험이 낮은 변경은 빠르게 받아들일 수 있습니다. 반대로 데이터 저장 방식, API 응답 구조, 권한 체크, 결제 상태 전환처럼 제품의 의미를 바꾸는 변경은 한 줄씩 읽어야 합니다.
Agent가 만든 코드가 마음에 들지 않는다고 해서 전부 버릴 필요도 없습니다. 좋은 부분만 남기면 됩니다. 예를 들어 UI 컴포넌트 구조는 괜찮은데 서버 액션에서 권한 검사가 빠졌다면, UI 파일은 수락하고 서버 파일은 되돌립니다. 그다음 Agent에게 다시 지시합니다.
수락한 UI 변경은 유지해줘.
서버 구현은 명시적인 권한 확인을 포함해서 다시 작성해줘.
수정하기 전에 어떤 permission model을 적용할지 먼저 설명해줘.이렇게 하면 Agent는 "수정하는 기계"가 아니라 "검토받는 작업자"가 됩니다. 솔로 메이커에게 중요한 전환은 바로 여기에 있습니다. Cursor를 내 손보다 빠른 타자로 쓰는 것이 아니라, 내가 승인권을 가진 작은 개발팀처럼 운영하는 것입니다.
로컬 변경은 Review → Find Issues로 먼저 걸러냅니다
PR을 만들기 전에 해야 할 일이 있습니다. 로컬 diff를 먼저 리뷰하는 것입니다. Cursor의 Agent Review나 Find Issues 흐름은 커밋하거나 PR을 열기 전에 로컬 변경사항을 점검하는 용도로 활용할 수 있습니다.2
이 단계는 생각보다 중요합니다. PR을 올린 뒤에 문제를 발견하면 이미 마음속으로는 "거의 끝났다"는 상태가 됩니다. 그때는 작은 문제를 무시하기 쉽습니다. 반면 로컬 리뷰는 아직 작업 중이라는 감각이 남아 있어서 수정하기가 훨씬 쉽습니다.
솔로 메이커에게 추천하는 로컬 리뷰 절차는 단순합니다.
Agent 작업이 끝나면 먼저 전체 diff를 훑습니다.
명백히 잘못된 파일 변경은 되돌립니다.
Review 또는 Find Issues로 로컬 변경을 검사합니다.
Source Control에서 main 브랜치 대비 전체 변경을 다시 확인합니다.
발견된 이슈를 고친 뒤 테스트와 lint를 실행합니다.
커밋 메시지에 "무엇을 바꿨는지"와 "무엇을 검증했는지"를 남깁니다.
여기서 중요한 것은 Cursor가 찾아준 모든 의견을 그대로 따르지 않는 것입니다. AI 리뷰는 때로 지나치게 일반적인 조언을 합니다. "에러 처리를 추가하세요"라고 말하지만 실제로는 상위 레이어에서 이미 처리하고 있을 수 있습니다. "테스트를 추가하세요"라고 말하지만 해당 코드는 단순한 타입 매핑일 수 있습니다. 그러므로 리뷰 결과를 받으면 세 가지로 분류해야 합니다.
즉시 수정할 문제
맞는 말이지만 이번 PR 범위를 벗어나는 문제
프로젝트 맥락상 받아들이지 않을 제안
이 분류를 하지 않으면 AI 리뷰는 또 다른 소음이 됩니다. 반대로 분류 습관이 생기면 AI 리뷰는 아주 좋은 체크리스트가 됩니다. 특히 혼자 일하는 사람에게 "이번 변경에서 내가 일부러 보지 않은 부분"을 들춰내는 도구가 됩니다.
로컬 리뷰를 더 잘 쓰려면 질문을 좁혀야 합니다.
이 diff에서 기존 사용자 동작을 깨뜨릴 수 있는 회귀 버그만 찾아줘.
포맷이나 네이밍은 무시하고, 실제 동작 변화와 누락된 예외 케이스에 집중해줘.리뷰 요청도 작업 요청처럼 구체적이어야 합니다. Agent에게 "잘 만들어줘"라고 말하면 애매한 결과가 나오듯, 리뷰어에게 "잘 봐줘"라고 말하면 애매한 피드백이 나옵니다.
PR에서는 Bugbot을 merge 전 안전망으로 둡니다
로컬 리뷰가 내 책상 위의 검토라면, Bugbot은 출입문 앞의 보안 검색대에 가깝습니다. PR을 열고 나서 diff 단위로 다시 한 번 문제를 잡아주는 안전망으로 사용할 수 있습니다. Cursor의 Bugbot은 GitHub PR에 코멘트를 남기고, 발견된 문제를 Cursor에서 다시 수정하는 흐름과 연결될 수 있는 도구로 소개되어 왔습니다.3
이 단계가 필요한 이유는 로컬에서 보지 못한 맥락이 PR에서 보이기 때문입니다. 로컬에서는 파일 하나하나를 고치느라 바쁩니다. PR에서는 변경 전체가 하나의 이야기로 보입니다. 어떤 API가 바뀌었고, 어떤 화면이 영향을 받고, 어떤 테스트가 빠졌는지 더 잘 드러납니다.
Bugbot이 특히 잘 잡는 문제는 대체로 "코드상 단서가 명확한 문제"입니다. 예를 들어 null이나 undefined 가능성을 놓친 경우, 비동기 함수에서 에러를 삼키는 경우, 기존 타입과 새 타입이 어긋나는 경우, 입력값 검증 없이 외부 요청을 처리하는 경우, 반복문 안에서 불필요한 데이터베이스 호출이 생긴 경우입니다. 이런 문제는 사람이 피곤할 때 놓치기 쉽고, AI 리뷰어가 반복적으로 보기 좋습니다.
반면 Bugbot에게 맡기면 안 되는 영역도 있습니다. 바로 제품의 의도와 비즈니스 로직입니다. 예를 들어 "무료 체험 기간이 끝난 사용자가 어떤 기능까지 접근할 수 있어야 하는가"는 코드만 보고 완전히 판단하기 어렵습니다. "환불 요청 후 포인트를 즉시 회수해야 하는가, 다음 정산 때 처리해야 하는가"도 마찬가지입니다. "관리자는 다른 팀의 데이터를 볼 수 있는가" 역시 회사 정책과 제품 철학이 섞인 문제입니다.
AI는 코드의 모순을 잘 찾을 수 있습니다. 하지만 사업의 약속은 알지 못합니다. PR 리뷰에서 사람인 내가 반드시 봐야 하는 것은 다음과 같은 질문입니다.
이 변경이 사용자에게 약속한 동작과 일치하는가?
돈, 권한, 데이터 소유권의 경계를 바꾸지는 않는가?
실패했을 때 사용자가 복구할 수 있는가?
운영자가 문제를 추적할 로그와 상태를 얻을 수 있는가?
이번 PR의 범위가 너무 넓어져서 검토가 불가능해지지는 않았는가?
Bugbot은 문 앞의 탐지기입니다. 하지만 출입을 허가하는 사람은 나입니다.
위험한 코드는 AI 리뷰만으로 통과시키지 않습니다
솔로 메이커가 반드시 지켜야 할 원칙이 있습니다. 보안, 결제, 인증, 권한, 데이터 삭제 로직은 AI 코드리뷰만으로 통과시키지 않습니다.
이 원칙은 보수적으로 들리지만, 실제로는 제품을 오래 운영하기 위한 최소한의 안전장치입니다. 단순한 버튼 색상 버그는 사용자가 하루쯤 불편해하고 끝날 수 있습니다. 하지만 권한 체크 누락은 다른 사람의 데이터를 노출시킵니다. 결제 상태 전환 버그는 돈과 신뢰를 동시에 잃게 만듭니다. 삭제 로직 실수는 되돌릴 수 없는 손실을 만듭니다.
위험한 영역을 다룰 때는 리뷰 절차를 한 단계 더 늘려야 합니다. 먼저 Agent에게 구현을 맡기기 전에 정책을 쓰게 합니다. 그런 다음 구현하게 하고, 다시 리뷰하게 합니다. 마지막으로 사람이 직접 시나리오를 검증합니다.
예를 들어 팀 초대 기능을 만든다고 해 보겠습니다. Agent에게 바로 "팀 초대 기능 만들어줘"라고 말하면 초대 링크, 이메일 발송, 권한 부여, 만료 시간, 중복 초대 처리까지 한 번에 바뀔 수 있습니다. 이럴 때는 먼저 정책을 쓰게 해야 합니다.
코드를 쓰기 전에 팀 초대의 권한 규칙을 먼저 정의해줘.
누가 초대할 수 있는지, 누가 초대할 수 없는지, 만료와 중복 초대, 감사 로그 기준을 포함해줘.
아직 파일은 수정하지 마.그다음 정책을 읽고 사람이 승인합니다. 승인 후 구현을 시킵니다. 구현이 끝나면 다시 리뷰를 요청합니다.
방금 구현한 팀 초대 흐름을 승인한 권한 규칙과 대조해 리뷰해줘.
비관리자가 멤버를 초대하거나, 만료된 초대를 재사용하거나, 다른 팀의 초대에 접근할 수 있는 경로가 있는지 찾아줘.이 흐름은 귀찮습니다. 그러나 귀찮음은 안전의 다른 이름입니다. 혼자 일하는 사람에게는 더더욱 그렇습니다. 팀에서는 누군가가 귀찮은 질문을 대신 해 줍니다. 솔로 메이커는 그 질문을 프로세스로 만들어야 합니다.
자기 자신을 위한 코드리뷰 체크리스트
AI 리뷰를 제대로 쓰려면 체크리스트가 필요합니다. 체크리스트는 기억력을 대체합니다. 특히 밤늦게 배포하거나, 고객 문의를 받고 급하게 수정하거나, 며칠 동안 같은 버그를 붙잡고 있었을 때 체크리스트는 감정과 피로를 이깁니다.
아래는 솔로 메이커를 위한 최소 코드리뷰 체크리스트입니다.
[Diff]
- 내가 요청하지 않은 파일이 바뀌었는가?
- 기존 공개 API나 데이터 구조가 바뀌었는가?
- 삭제된 코드가 실제로 더 이상 쓰이지 않는다고 확인했는가?
[Behavior]
- 성공 케이스뿐 아니라 실패 케이스도 처리했는가?
- 빈 값, 중복 요청, 권한 없음, 네트워크 실패를 고려했는가?
- 기존 사용자 흐름이 깨지지 않는가?
[Risk]
- 인증, 권한, 결제, 삭제, 개인정보와 관련된 변경인가?
- 그렇다면 AI 리뷰 외에 사람이 직접 시나리오를 검증했는가?
- 로그, 모니터링, 롤백 방법이 있는가?
[Verification]
- 관련 테스트를 실행했는가?
- lint/typecheck/build 중 필요한 검사를 통과했는가?
- PR 설명에 검증 내용을 적었는가?이 체크리스트는 .cursor/rules/나 리뷰용 문서에 넣어도 좋습니다. 중요한 것은 Cursor에게도 같은 기준을 반복해서 알려 주는 것입니다. "우리 프로젝트에서는 결제 상태 변경 시 반드시 audit log가 필요하다", "삭제 API는 soft delete를 기본으로 한다", "관리자 권한은 role 문자열이 아니라 permission helper로 확인한다" 같은 규칙은 AI가 매번 추측하게 두면 안 됩니다.
리뷰 규칙은 길수록 좋은 것이 아닙니다. 짧고 구체적일수록 좋습니다. 나쁜 규칙은 이렇습니다.
보안에 신경 써라.좋은 규칙은 이렇습니다.
팀 소유 데이터를 읽거나 수정하는 모든 server action은 DB 접근 전에 assertTeamMember(userId, teamId) 또는 assertTeamAdmin(userId, teamId)를 호출해야 한다.
이 확인 없이 teamId로 직접 쿼리하는 코드는 리뷰에서 위험으로 표시한다.AI에게 "잘해라"라고 말하지 말고, "무엇을 보면 멈춰야 하는지"를 알려 줘야 합니다.
리뷰를 작은 의식으로 만들기
좋은 워크플로우는 거창하지 않습니다. 매번 반복할 수 있을 만큼 작아야 합니다. 솔로 메이커에게 추천하는 하루의 코드리뷰 의식은 다음과 같습니다.
작업 시작 시에는 오늘 만들 기능의 위험도를 먼저 표시합니다. UI만 바꾸는 작업인지, 데이터 구조를 바꾸는 작업인지, 결제나 권한에 닿는 작업인지 구분합니다. 위험도가 낮으면 Agent에게 비교적 넓게 맡길 수 있습니다. 위험도가 높으면 Plan Mode에서 정책과 시나리오를 먼저 확정합니다.
구현 중에는 diff를 계속 봅니다. Agent가 만든 변경을 파일 단위로 수락하지 말고, 의미 단위로 수락합니다. "이 컴포넌트 분리는 좋다", "이 API 변경은 아직 안 된다", "이 테스트는 남기되 mock 방식은 바꾸자"처럼 판단합니다.
커밋 전에는 로컬 Review나 Find Issues를 실행합니다. 여기서 나온 문제를 고치고 나서야 커밋합니다. PR을 열면 Bugbot을 안전망으로 둡니다. Bugbot 코멘트는 무조건 수용하지 않고, "수정", "보류", "거절"로 분류합니다. 마지막으로 위험 영역은 사람이 직접 시나리오를 실행합니다.
이 의식은 처음에는 느리게 느껴집니다. 하지만 몇 번만 반복하면 오히려 개발 속도가 빨라집니다. 이유는 단순합니다. 나중에 터질 버그를 앞에서 잡기 때문입니다. 운영 중에 고객 데이터를 복구하고, 결제 오류를 설명하고, 긴급 패치를 배포하는 시간보다 리뷰 10분이 훨씬 쌉니다.
AI 리뷰어에게 맡길 일과 내가 붙잡을 일
Cursor 시대의 코드리뷰는 역할 분담입니다. AI에게 맡길 일은 반복적이고, 패턴이 있고, 코드상 단서가 많은 문제입니다. 내가 붙잡을 일은 제품의 의미와 책임이 걸린 문제입니다.
AI 리뷰어에게는 이런 일을 맡깁니다.
null, undefined, 빈 배열, 예외 처리 같은 누락 찾기
타입 불일치, 사용하지 않는 코드, 깨진 import 확인
테스트 누락, 실패 케이스 누락, 회귀 가능성 탐지
반복되는 쿼리, 불필요한 렌더링 같은 성능 냄새 찾기
프로젝트 규칙과 다른 구현 방식 표시하기
사람인 나는 이런 일을 봅니다.
이 변경이 제품 전략과 맞는지 판단하기
사용자의 권리, 결제, 데이터 소유권에 영향을 주는지 확인하기
장애가 났을 때 복구 가능한 구조인지 점검하기
이번 PR이 너무 커져서 리뷰 불가능해졌는지 결정하기
AI가 제안한 수정이 실제로 더 안전한지 승인하기
이 구분이 명확해지면 AI 코드리뷰에 대한 기대도 건강해집니다. AI는 완벽한 선임 개발자가 아닙니다. 하지만 지치지 않는 1차 리뷰어로는 충분히 가치가 있습니다. 혼자 일하는 사람에게 이 정도의 동료만 생겨도 출시 전 불안은 크게 줄어듭니다.
출시 전 마지막 질문
배포 버튼을 누르기 전에 마지막으로 스스로에게 물어보세요.
"이 코드를 내가 아니라 다른 사람이 작성했다면, 나는 이대로 승인했을까?"
이 질문은 강력합니다. 내가 쓴 코드는 늘 조금 더 좋아 보입니다. Agent가 만든 코드는 더더욱 그렇습니다. 빠르게 완성된 코드는 마치 이미 검증된 것처럼 느껴집니다. 하지만 속도는 품질의 증거가 아닙니다. 동작하는 데모는 안전한 제품의 증거가 아닙니다.
Cursor의 Review, Find Issues, Bugbot은 이 착각을 깨는 도구입니다. Agent가 만든 diff를 실시간으로 의심하고, 로컬 변경을 먼저 검사하고, PR에서 Bugbot을 안전망으로 세우고, 위험한 비즈니스 로직은 사람이 끝까지 붙잡습니다. 이것이 솔로 메이커가 팀 없이도 최소한의 코드리뷰 문화를 갖추는 방법입니다.
혼자 일한다는 것은 혼자 승인한다는 뜻이 아닙니다. 이제 당신에게는 빠르게 코드를 쓰는 Agent가 있고, 그 코드를 의심하는 리뷰어도 있습니다. 남은 일은 하나입니다. 최종 승인권을 절대 넘기지 않는 것.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.