“작은 수정은 빠르게 끝날 줄 알았다.
그런데 진짜 시간은 구현보다 리뷰에서 더 많이 들었다.”

얼마 전 나는 작은 프론트엔드 수정에 대해
“이 정도는 Cursor와 꽤 잘 맞는다”
는 글을 썼다.

그 판단 자체는 여전히 유효하다.

작은 수정, 특히 프론트엔드의 자잘한 UX 보정은 Cursor와 잘 맞는다.
문제 범위가 작고, 기대 동작을 바로 말할 수 있고, 화면으로 즉시 검증할 수 있기 때문이다.

그런데 이번에는 그 다음 단계가 왔다.

수정은 작았는데 리뷰가 길어졌다.

그리고 그 경험은 이전보다 더 흥미로웠다.

왜냐하면 이때부터는 “코드를 빨리 고치는 능력”보다
리뷰를 견디고, 의도를 설명하고, 다시 정리하는 능력이 더 중요해졌기 때문이다.

이 글은 그 기록이다.

핵심 결론부터 쓰면 이렇다.

Cursor는 작은 프론트엔드 수정을 빠르게 밀어주는 데 분명히 유용하다.
하지만 리뷰가 길어지는 순간부터는, AI의 속도보다 사람의 기준과 서사가 더 중요해진다.

시작은 정말 작았다

처음 문제는 평범했다.

주문 화면의 배송지 영역에서 몇 가지 UX를 다듬는 일이었다.

배송지 warning 상태에서 직접 입력 폼 보여주기
연락처 에러 문구 정리
포커스를 빈 칸으로 보내기
주소 검색 버튼으로 포커스 이동하기
상세주소 에러 위치 맞추기
이모지 검증 보완하기
fixed 결제 바에 가려지는 문제 보정하기

겉으로 보면 전부 작은 수정이다.

그리고 실제로도 한 항목씩 보면 큰 기능은 아니었다.

그래서 처음에는 꽤 기분 좋게 진행됐다.

관련 파일을 찾고
로직을 읽고
한 군데씩 수정하고
작은 커밋으로 나누고
다시 다음 리뷰 포인트를 반영하고

이 흐름 자체는 이전 글에서 적었던 것처럼, Cursor와 꽤 잘 맞았다.

문제는 그 다음부터였다.

작은 수정인데 왜 리뷰는 길어졌나

처음에는 나도 좀 의아했다.

“이 정도 수정이면 그렇게까지 길게 리뷰가 오갈 일인가?”

그런데 지나고 보니 이유는 단순했다.

이런 종류의 수정은 코드 양은 적어도
정책, 호환성, UX, 접근성, 계층 분리, 운영 리스크가 한꺼번에 달라붙기 쉽다.

예를 들면 이런 식이다.

상세주소를 정말 전체 플로우에서 필수로 볼 것인가
과거 저장 데이터와 충돌하지 않는가
warning 상태와 일반 상태에서 정책을 다르게 가져갈 것인가
사용자를 막을 때 수정 가능한 경로를 같이 주는가
validator가 UI 계층 훅을 알아도 되는가
warning 배너는 role="status"가 맞나 role="alert"가 맞나
memo 선택값은 key를 저장하는가, 실제 문구를 저장하는가
훅이 두 군데서 인스턴스화되면 ref가 어긋날 가능성은 없는가

이건 한마디로 작은 UI 수정처럼 시작했지만, 중간에 “설계와 운영”의 언어가 섞여 들어온 경우였다.

코드만 보면 몇 줄인데,
리뷰어는 거기서 시스템 전체의 전제를 다시 묻는다.

그래서 리뷰가 길어진다.

코드가 길어서가 아니라,
작은 수정이 기존 규칙과 충돌할 수 있는 지점이 많아서다.

이때부터 중요한 건 “정답”보다 “입장”이었다

이번에 더 분명하게 느낀 건,
리뷰가 길어지는 순간부터는 단순히 “버그를 고쳤냐” 보다
“이 변경을 어떤 입장으로 가져가느냐” 가 중요하다는 점이었다.

대표적인 게 상세주소(address2)였다.

표면적으로는 간단해 보인다.

상세주소가 비어 있으면 막을까?
아니면 기존 데이터 호환성을 위해 통과시킬까?

그런데 실제로는 이게 아니었다.

질문은 오히려 이쪽에 가까웠다.

상세주소는 정책상 필수인가
그렇다면 checkout에서도 같은 정책을 집행해야 하는가
그렇다면 과거 저장 데이터가 비어 있을 때는 어떤 UX를 제공해야 하는가
그 UX는 차단 없는 유도인가, 차단 + 수정 경로 제공인가

즉, 단순히 if 문 하나의 문제가 아니었다.

정책을 유지할지, 호환성을 우선할지, 운영 리스크를 어떻게 해석할지에 대한 입장 문제였다.

이런 자리는 Cursor가 대신 결정해주지 못한다.

Cursor는 선택지를 빠르게 펼쳐준다.

warning에만 적용
일반 플로우도 적용
feature flag로 제어
direct edit flow 제공
PR 본문에 리스크 명시

그런데 그중 무엇을 채택할지는 결국 사람이 결정해야 한다.

이번에 내가 다시 느낀 건 이거였다.

AI는 빠르게 제안하지만, 그 제안의 기준은 사람 쪽에서 끝까지 고정해줘야 한다.

기준이 없으면 리뷰마다 흔들린다.
기준이 있으면 리뷰가 길어져도 방향은 유지된다.

Cursor가 여기서도 도움이 되긴 했다

그렇다고 리뷰가 길어지는 순간 Cursor가 무용해지는 건 아니다.
오히려 역할이 조금 바뀐다.

처음 구현 단계에서 Cursor가 잘했던 건:

코드 탐색
가까운 문맥 읽기
작은 수정 빠르게 반영
커밋 잘게 나누기

리뷰 루프로 들어가고 나서는 도움이 되는 포인트가 달라졌다.

1. 논점을 구조화하는 데 도움된다

리뷰가 길어지면 사람이 지친다.

왜냐하면 비슷한 말이 반복되는데, 매번 다른 층위의 이야기처럼 느껴지기 때문이다.

예를 들면:

이건 진짜 버그인가
아니면 정책 disagreement인가
코드 수정이 필요한가
아니면 PR 설명 보강이 필요한가
운영 확인이 필요한가
나중에 feature flag로 풀어야 하는가

이걸 머릿속으로 계속 분류하는 게 꽤 피곤하다.

Cursor는 여기서 의외로 괜찮았다.

내가 조금만 잘라 말하면:

“이건 코드 수정”
“이건 리뷰 답변”
“이건 PR 본문”
“이건 운영 확인”

처럼 정리하는 데 도움을 줬다.

즉, 더 이상 “코드를 대신 짜는 도구”가 아니라
논점을 분해하는 도구처럼 썼을 때 효율이 있었다.

2. 반복 수정의 비용을 줄인다

리뷰가 길어지면 비슷한 성격의 수정이 계속 이어진다.

훅 위치 옮기고
중복 인스턴스 없애고
pass-through 컴포넌트 제거하고
role 속성 바꾸고
타입 에러 잡고
포팅 후 깨진 레이아웃 고치고
다시 경고 문구 조정하고

이걸 사람이 손으로만 해도 된다.
당연히 된다.

다만 문제는, 리뷰가 길어질수록 집중력이 먼저 떨어진다는 점이다.

코드는 작은데 맥락은 길고,
맥락은 긴데 수정은 사소하다.

이럴 때 Cursor는 작은 수정을 다시 반영하고,
그걸 작은 커밋으로 쪼개고,
변경 범위를 다시 설명하는 데 꽤 도움이 됐다.

즉, 긴 리뷰에서 Cursor의 장점은
“천재적인 해결책”이 아니라
작은 후속 수정의 피로를 줄여주는 것에 가까웠다.

하지만 리뷰 국면에서 더 분명해진 한계도 있었다

긴 리뷰 상황은 Cursor의 한계도 더 선명하게 보여줬다.

1. 리뷰어의 진짜 우려를 종종 코드 레벨 문제로만 번역한다

예를 들어 리뷰어가
“이대로 가면 장애 위험이 있다”
라고 말할 때, 그 말은 항상 곧바로 코드 수정으로 대응할 수 있는 게 아니다.

어떤 경우는 진짜로 코드 문제다.
하지만 어떤 경우는:

데이터 확인 필요
운영 판단 필요
정책 입장 정리 필요
rollout 체크 필요

같은 종류다.

Cursor는 자주 이걸 즉시 수정 가능한 코드 문제처럼 환원하려고 한다.

그건 빠르지만, 때로는 틀린 반응이다.

왜냐하면 리뷰어가 묻는 건 if 문이 아니라
“이 변경을 어떤 책임 하에 배포하느냐” 이기 때문이다.

이건 사람이 구분해야 한다.

2. 서사를 모르면 맞는 코드도 틀린 답처럼 보이게 만든다

긴 리뷰에서는 코드보다 설명이 중요할 때가 있다.

이번에도 그랬다.

예를 들어 address2를 막는 코드는 정책상 맞을 수 있다.
그런데 리뷰어 입장에서는 이렇게 읽힌다.

기존 사용자를 막는 변경 아닌가?
과거 데이터 확인했는가?
수정 경로를 같이 제공하는가?
이게 실수인지 의도인지 설명되었는가?

이때 코드만 고치면 오히려 더 흔들릴 수 있다.

설명을 먼저 정리해야 한다.

정책은 동일하게 유지한다
기존 배송지도 동일하게 막는다
대신 직접 수정 폼으로 유도한다
남은 리스크는 운영 확인 포인트다

이 서사가 있어야 코드가 맞게 읽힌다.

Cursor는 코드 제안은 빠르지만,
리뷰어가 어떻게 읽을지를 기준으로 서사를 세우는 일은 여전히 사람 쪽 몫이었다.

3. 리뷰가 길어질수록 “그럴듯한 말”이 위험해진다

작은 구현 단계에서는 그럴듯한 말이 크게 해롭지 않을 때가 있다.

그런데 긴 리뷰에 들어오면 다르다.

“이 정도면 괜찮을 것 같습니다”
“문제 없을 것으로 보입니다”
“아마도 여기서만 쓰입니다”

이런 말은 금방 약해진다.

리뷰어는 이미 여러 번 지적했고,
그 말의 빈틈을 다시 찌른다.

그래서 이 단계부터는 말도 더 구체적이어야 했다.

어떤 훅이 실제로 무엇을 감지하는지
어떤 필드가 폼에 없어서 수정 불가능한지
어떤 값은 option key가 아니라 실제 value인지
어떤 알림은 초기 마운트 시 뜨지 않는 구조인지

즉, 리뷰가 길어질수록
말은 짧아져야 하지만 근거는 더 구체적이어야 한다.

이건 Cursor보다 사람이 더 신경 써야 하는 부분이었다.

이번 경험으로 바뀐 내 작업 규칙

이번에는 구현보다 리뷰를 지나며 생긴 규칙이 더 분명해졌다.

규칙 1. 작은 수정도 초반부터 “입장”을 적어둔다

코드를 고치기 전에, 적어도 내 머릿속에는 먼저 있어야 한다.

이건 정책 변경인가
정책 집행 범위 조정인가
호환성 보완인가
UX 개선인가
운영 확인 과제인가

이게 없으면 리뷰마다 흔들린다.

규칙 2. 리뷰 코멘트는 코드와 분리해서 관리한다

승인 리뷰, 인라인 코멘트, PR 본문, 일반 코멘트는 역할이 다르다.

이번에 느낀 건:

APPROVE는 짧게
긴 설명은 PR 코멘트로
인라인 코멘트는 꼭 필요한 것만
PR 본문은 설계/리스크/확인 포인트 정리

이렇게 분리하는 게 제일 안전했다.

규칙 3. “수정 완료”와 “운영 확인 필요”를 섞지 않는다

이건 정말 중요했다.

예를 들면:

수정 완료: warning 직접입력, 직접 수정 폼 진입, 훅 분리, 접근성 조정
운영 확인 필요: 과거 address2 공란 데이터 규모, 스테이징 검증, 브라우저/웹뷰 수동 테스트

이 둘이 섞이면, 읽는 사람은
“아직 이게 덜 끝난 건가?”
라고 느낀다.

그래서 표현을 분리해야 했다.

규칙 4. 리뷰가 길어질수록 더 작은 커밋이 필요하다

처음엔 작은 수정이니까 작은 커밋을 만드는 줄 알았다.
그런데 지나고 보니 반대이기도 했다.

리뷰가 길어질수록, 오히려 더 작은 커밋이 필요했다.

그래야

어느 리뷰 포인트를 반영했는지 분명하고
되돌리기 쉽고
설명하기 쉽고
나중에 다시 읽기도 쉽다

Cursor는 여기서 꽤 유용했다.

결국 이번에 남은 결론

이전 글에서는
작은 프론트엔드 수정은 Cursor와 잘 맞는다
는 쪽에 무게를 뒀다.

지금도 그 말은 맞다고 생각한다.

다만 이번에는 한 줄이 더 붙는다.

작은 수정은 Cursor와 잘 맞는다.
하지만 리뷰가 길어지는 순간부터는,
속도보다 사람의 기준과 설명 능력이 더 중요해진다.

이건 AI가 부족하다는 말이 아니다.
오히려 역할 분담이 더 또렷해졌다는 뜻에 가깝다.

Cursor는 탐색과 반복 수정에 강하고
사람은 정책, 서사, 운영 판단, 리뷰 해석에 강하다

이번 경험이 흥미로웠던 건,
이 둘의 경계가 생각보다 명확하게 보였기 때문이다.

처음엔 행복했다.
작은 수정이 빠르게 밀리는 느낌이 있었으니까.

그리고 나중엔 조금 지쳤다.
리뷰가 길어졌으니까.

그런데 지나고 보니, 그 긴 리뷰가 오히려 더 많은 걸 남겼다.

구현보다도
작은 수정이 왜 길게 논의되는지,
그리고 그때 무엇을 사람이 끝까지 붙잡아야 하는지를 더 분명하게 배웠다.

한 줄 결: 작은 프론트엔드 수정은 Cursor와 잘 맞는다. 하지만 긴 리뷰를 통과시키는 힘은 여전히 사람의 기준과 설명에서 나온다.