“커서는 작은 프론트엔드 수정에서 특히 강하다.
다만 어디가 진짜 문제인지 판정하는 일은 아직 사람의 몫이다.”

이번에는 한 주문 화면의 배송지 경고 폼을 다듬는 작업을 거의 Cursor만으로 밀어 보았다.
엄밀히 말하면 완전히 혼자 시킨 것은 아니다. 방향을 정하고, 실제 화면을 보고, 어디가 어색한지 판정한 것은 나였다. 하지만 코드를 읽고, 찾고, 고치고, 커밋으로 잘게 나누는 흐름은 거의 Cursor와 같이 갔다.

이 글은 그 기록이다.

핵심 결론부터 적으면 이렇다.

복잡한 구조 설계보다, 작은 프론트엔드 수정이 Cursor와 훨씬 잘 맞았다.
특히 이번처럼 배송지 입력 영역에서 인라인 에러, alert, focus, viewport 이동, 이모지 검증, fixed footer에 가려지는 문제 같은 것을 정리하는 일은 Cursor가 꽤 잘 달렸다.

그렇다고 해서 “이제 이런 건 AI가 다 한다” 는 결은 아니다.
오히려 반대로 느꼈다.

작은 작업일수록 사람이 판정해야 할 기준을 더 짧고 명확하게 줄 수 있고, 그때 Cursor의 속도가 실제 장점이 된다.

들어가면서

처음 문제는 얼핏 작아 보였다.

배송지 경고 상태에서 에러 문구를 정리하고
연락처 포커스를 빈 칸으로 보내고
우편번호/기본주소가 비었으면 주소 검색 쪽으로 보내고
이모지 검증과 alert 문구를 다듬고
fixed 결제 바에 에러 문구가 가려지는 걸 보정하고
디자인 의뢰와 다른 에러 위치를 맞추는 것

이 정도였다.

그런데 막상 들어가 보면 이런 종류의 작업은 아주 자잘한 규칙이 많다.

완전히 비었을 때와 일부만 입력했을 때의 문구가 다르다.
alert 전에 focus를 줄지, alert 후에 줄지 결정해야 한다.
연락처가 세 칸이면 첫 번째 input이 아니라 첫 번째 빈 칸으로 가야 한다.
기본주소는 직접 입력 필드가 아니라 주소 검색 버튼으로 가야 한다.
11️⃣ 같은 키캡 이모지까지 잡으려면 정규식이 조금 더 세밀해야 한다.
포커스는 갔는데 fixed footer가 아래를 덮으면 사용자는 “안 갔다”고 느낀다.
에러 문구는 보이기만 하면 되는 게 아니라, 디자인 기준 위치에 있어야 한다.

이건 알고리즘 문제라기보다 작은 UX 규칙 묶음에 가깝다.
그리고 신기하게도, 이런 종류가 Cursor와 꽤 잘 맞았다.

왜 이번에는 잘 됐나

예전에 더 큰 기능이나 더 복잡한 구조를 Cursor와 같이 다룰 때는, 생산성이 올라가는지 애매할 때가 꽤 있었다.

이유는 단순하다.

문제 정의가 크고
문맥이 깊고
설계 선택지가 많고
검증 루프가 길면

Cursor는 빠르게 제안하지만, 빠르게 평균으로 흐른다.

반대로 이번 작업은 달랐다.

문제 범위가 작았고
기대 동작을 내가 바로 말할 수 있었고
화면에서 바로 확인할 수 있었고
수정 단위를 커밋으로 잘게 쪼갤 수 있었다

즉, 이번에는 Cursor가 잘한 게 아니라
Cursor가 잘할 수 있는 문제를 내가 잘라서 준 셈에 가까웠다.

이 차이가 꽤 중요하다고 느꼈다.

Cursor가 특히 잘했던 것들

1. 가까운 문맥을 따라가는 능력

이번 작업은 한 파일만 보면 끝나는 일이 아니었다.

배송지 변경 흐름만 해도 대략 이런 것이 엮였다.

배송지 경고 폼 UI
주문서 검증 로직
배송지 추가/수정 다이얼로그
배송지 목록/생성/수정/삭제 API 연결
캐시 갱신
모바일 웹뷰 레이어 처리
결제 바 fixed footer

이런 건 다행히도 “거대한 설계 문서”가 아니라, 옆 파일 몇 개를 정확히 읽는 능력이 중요했다.

Cursor는 이럴 때 괜찮았다.

이 훅이 어디서 불리는지 찾고
이 컴포넌트가 어느 분기에서 렌더링되는지 보고
이 mutation이 어떤 서비스 레이어를 타는지 확인하고
어떤 query key를 invalidate 하는지 따라가는 일

이런 근거리 탐색은 꽤 빠르고 자연스러웠다.

큰 시스템 전체를 꿰뚫는 느낌은 아니지만,
지금 손대는 주변 문맥을 빠르게 좁히는 능력은 확실히 있다.

프론트엔드 수정은 의외로 이 능력이 중요하다.

2. 반복되는 UX 규칙 정리

이번에 내가 Cursor에게 가장 많이 한 말은 거의 이런 종류였다.

“완전 공백일 때만 이 문구”
“부분 입력이면 다른 문구”
“alert은 그대로”
“붉은 문구만 바꾸자”
“수령인처럼 먼저 focus”
“주소 검색 버튼으로 가야지”
“상세주소 아래에 보여야지”

이런 건 어려운 로직이라기보다 일관성 정리 작업이다.

사람 혼자 해도 할 수 있다.
그런데 생각보다 피곤하다.
코드는 짧은데 판단은 자꾸 미세하게 갈라지기 때문이다.

Cursor는 이런 자리에서 괜찮았다.

내가 아주 짧게 기준만 정해주면, 그 기준을 로직 곳곳에 반영하는 작업은 빠르게 했다.
즉, Cursor는 문제를 발견하는 것보다 기준이 이미 정해진 문제를 정리하는 것에 강했다.

3. 커밋을 잘게 나누는 비용을 낮춘다

이번 브랜치에는 커밋이 꽤 많이 쌓였다.

이게 중요한 이유는 “AI가 많이 했다” 가 아니다.
오히려 그 반대다.

작은 수정일수록 커밋을 더 잘게 나누는 게 좋았고, Cursor는 그 비용을 낮췄다.

예를 들면 이런 식이다.

연락처 포커스만 따로
주소 검색 버튼 포커스만 따로
alert 카피만 따로
이모지 정규식만 따로
fixed footer 스크롤 보정만 따로
배송지 에러 문구 위치만 따로

손으로 해도 당연히 가능하다.
하지만 바쁠 때는 이런 걸 자꾸 한 커밋에 묶게 된다.

Cursor와 작업하면, 내가 “이건 따로 커밋하자” 라고 말했을 때 그걸 다시 정리하는 데 드는 마찰이 적었다.
이건 꽤 실질적인 장점이었다.

AI가 코드를 대신 짠다기보다,
의도를 잘게 나눈 채 유지하는 비용을 줄여준다는 느낌에 가까웠다.

그런데 잘 안 되는 자리도 분명했다

이번 작업이 잘됐다고 해서, Cursor가 문제를 본질적으로 이해했다고 말하고 싶지는 않다.
오히려 한계는 더 또렷했다.

1. 보이는 현상과 실제 원인을 자주 섞는다

가장 인상적이었던 건 focus/scroll 문제였다.

처음엔 나도 그렇고 Cursor도 그렇고
“이건 타이머 문제인가?”
쪽으로 생각이 갔다.

왜냐하면 alert가 닫힌 뒤 포커스가 안 맞는 것처럼 보였기 때문이다.

그런데 실제로는 그보다 fixed 결제 바가 하단을 덮고 있어서,
포커스는 가더라도 에러 문구가 그 뒤에 남는 문제가 더 컸다.

이건 굉장히 다른 문제다.

타이머 문제라고 보면 setTimeout 을 만진다.
fixed footer 문제라고 보면 뷰포트와 레이아웃 기준으로 스크롤을 보정해야 한다.

Cursor는 이런 자리에서 꽤 자주
그럴듯한 첫 설명을 먼저 준다.
문제는 그 설명이 맞을 때도 있고, 아닐 때도 있다는 점이다.

특히 프론트엔드 UI 문제는 코드만 봐서는 원인이 다 안 보인다.
브라우저에서 실제로 무엇이 가려지고, 무엇이 움직이고, 무엇이 보이지 않는지 봐야 한다.

즉, Cursor는 설명은 빠르지만, 화면의 물리적 현실은 자주 놓친다.

2. 검증 순서를 스스로는 잘 의심하지 않는다

이모지 검증도 그랬다.

처음엔 11️⃣ 같은 값이 안 걸리는 걸 보고
“정규식이 약한가?”
라고 생각하기 쉬웠다.

실제로 정규식 보강도 필요했다.
하지만 더 큰 문제는 검증 순서였다.

연락처 미입력이 먼저 걸리면, 수령인 이모지 검증까지 내려가지 못한다.
그러면 사용자는 “이모지 검증이 안 되네?” 라고 느낀다.

코드상으로는 이모지 검증이 존재한다.
하지만 플로우상 도달 불가능하면 없는 것과 다르지 않다.

Cursor는 이런 종류를 자주 늦게 본다.

로직이 “있는지”
실제 사용자 플로우 안에서 “도달하는지”

는 완전히 다른 문제인데,
AI는 전자에 더 강하고 후자에는 약하다.

이건 실제 화면을 보고
“왜 연락처만 뜨지?”
라고 의심하는 인간의 감각이 더 중요했다.

3. 요청이 조금만 흐리면 평균으로 간다

개발에서도, 문서 정리에서도 똑같이 느꼈다.

내가 기준을 명확히 말하지 않으면 Cursor는 늘 평균적인 방향으로 간다.

예를 들면:

“가이드”를 원했는데 “계획”처럼 쓰거나
alert은 그대로인데 문구까지 바꾸거나
붉은 문구만 정리하면 되는데 alert까지 같이 건드리거나
첫 빈 칸으로 가야 하는데 첫 input으로 고정해 버리거나

이건 모델이 멍청해서가 아니다.
그냥 내 머릿속 기준이 문자열로 충분히 전달되지 않았기 때문이다.

이번 작업이 잘된 이유 중 하나는, 중간 이후부터 내가 요청을 아주 짧고 판정 가능하게 말했기 때문이다.

“완전히 비었을 때만”
“일부 입력이면 올바른 연락처”
“alert은 동일”
“focus 먼저”
“수령인처럼”
“주소 검색 버튼으로”
“상세주소 아래”

이런 문장은 작은데 강하다.
반대로
“배송지 validation 좀 깔끔하게”
같은 말은 너무 크고 약하다.

이번 작업으로 얻은 규칙

이번 브랜치를 지나며, Cursor와 같이 일할 때 내 쪽 규칙이 조금 더 분명해졌다.

규칙 1. 기능 단위보다 행동 단위로 말한다

“배송지 폼 고쳐줘”는 너무 크다.

대신 이렇게 말해야 한다.

완전 공백일 때만 이 문구
부분 입력이면 다른 문구
첫 번째 빈 칸으로 focus
alert 전에 focus
에러 문구는 상세주소 아래
fixed footer 위로 보여야 함

모델은 작은 행동 규칙을 훨씬 잘 따른다.

규칙 2. 화면에서 보이는 현상을 더 믿는다

코드 설명은 그럴듯할 수 있다.
하지만 특히 프론트엔드에서는 실제 화면 증거가 더 중요하다.

타이머처럼 보이지만 overlay 문제일 수 있고
정규식처럼 보이지만 검증 순서 문제일 수 있고
focus 문제처럼 보이지만 scroll 문제일 수 있다

그래서 화면을 보고 이상하면, 먼저 현상을 기준으로 다시 문제를 정의해야 한다.

규칙 3. 커밋은 생각보다 더 잘게 나눈다

Cursor와 함께할수록, 나는 오히려 커밋을 더 잘게 나누는 편이 좋다고 느꼈다.

그 이유는 품질보다 의도 보존에 있다.

AI는 빠르게 넓게 퍼뜨릴 수 있다.
작은 커밋은 그 퍼짐의 경계를 만든다.

규칙 4. 작은 작업에서 먼저 이득을 챙긴다

요즘 AI 도구 얘기를 하면 자꾸 큰 그림으로 가기 쉽다.

거대한 리팩터링
복잡한 설계 자동화
기능 전체 생성
PR 전체 리뷰 대체

물론 그 방향도 계속 갈 것이다.
하지만 실제로 당장 효율이 나는 자리는, 이번 경험상 훨씬 소박했다.

작은 UX 수정, 자잘한 검증 규칙 정리, 포커스 보정, 문구 정렬, 화면 피드백 반영.

이런 데서는 Cursor가 꽤 유용하다.

이번 경험에서 본 장점

정리하면 이번 브랜치에서 체감한 장점은 이렇다.

주변 코드를 빨리 읽고 연결한다
탐색 비용을 줄여준다
반복되는 수정 규칙 반영이 빠르다
작은 커밋으로 나누는 비용이 낮다
사람의 판정이 명확할 때 속도가 크게 난다

이건 결국 한 문장으로 줄이면 이렇게 된다.

Cursor는 “모르는 문제를 대신 풀어주는 도구”보다,
“내가 이미 알고 있는 방향을 빠르게 구현하게 해 주는 도구”에 더 가깝다.

이번 경험에서 본 한계

반대로 한계는 이랬다.

실제 원인보다 그럴듯한 설명을 먼저 내놓는다
검증 순서나 도달 경로를 늦게 본다
UI의 물리적 문제는 코드만으로 자주 틀린다
요청이 흐리면 평균적인 수정으로 간다
사람이 판정을 멈추는 순간, 빠른데 어긋난 결과가 나온다

즉, Cursor는 빠르다.
하지만 그 빠름은 판정이 있는 빠름일 때만 가치가 있다.

판정이 없으면, 빠른 속도로 평균으로 간다.

마치며

이번 작업은 거대한 기능이 아니었다.
오히려 그래서 좋았다.

주문서의 배송지 입력 주변에서
에러 문구, focus, viewport, 이모지 검증, fixed footer 같은
작은 UX 규칙을 정리하는 일이었고, 그 크기에서는 Cursor가 확실히 잘 맞았다.

이번 경험으로 나는 오히려 더 현실적인 결론을 갖게 됐다.

Cursor는 작은 프론트엔드 수정에서 강하다.
왜냐하면 이 영역은

사람이 기대 동작을 바로 말할 수 있고
화면에서 즉시 검증할 수 있고
커밋을 잘게 나누기 쉽고
규칙 정리가 코드 전체 설계보다 더 중요하기 때문이다.

반대로 큰 문제로 갈수록,
AI의 속도보다 사람의 판정 비용이 더 커진다.

그래서 적어도 지금 내 기준에서는, Cursor를 가장 잘 쓰는 방법은
“이걸 한 번에 다 해줘” 가 아니라
“이 행동을 이 기준으로 맞춰줘”
라고 말하는 것이다.

작은 작업일수록 그 차이는 더 선명해진다.

한 줄 결: 작은 프론트엔드 수정에서 Cursor는 강하다. 대신 경계와 판정은 사람이 끝까지 쥐고 있어야 한다.