화면 수정은 스크린샷부터 고정하기

2026년 6월 14일 | 바이브코딩 Tips

---

웹 화면을 에이전트에게 고치라고 맡길 때 가장 먼저 필요한 것은 예쁜 프롬프트보다 기준 스크린샷 한 장이었다. “간격만 조금 줄여줘”, “버튼 색만 바꿔줘”처럼 말하면 작업은 작아 보이지만, 실제 diff는 생각보다 쉽게 번진다. 에이전트는 화면을 직접 눈으로 붙잡고 있는 사람이 아니기 때문에, 내가 말한 “조금”과 “그 부분”을 코드 구조 안에서 다시 추정한다. 여기서 기준 화면이 없으면 수정이 끝난 뒤에도 무엇이 의도한 변화이고 무엇이 새로 생긴 흔들림인지를 늦게 알아차린다.

예전에는 이 문제를 요구사항을 더 자세히 쓰는 방식으로 해결하려고 했다. 여백은 몇 픽셀, 색상은 어떤 값, 모바일에서는 두 줄, 데스크톱에서는 한 줄 같은 식으로 문장을 늘렸다. 그런데 UI 작업에서는 숫자보다 먼저 고정해야 하는 것이 있었다. 바로 지금 화면의 모양이다. 기준 스크린샷이 있으면 에이전트에게 “이 상태에서 이 영역만 바꾼다”라고 말할 수 있다. 없으면 작업은 자연스럽게 “대충 보기 좋아 보이는 새 화면 만들기” 쪽으로 흘러간다.

스크린샷은 장식보다 입력 계약에 가깝다

나는 요즘 화면 작업을 맡길 때 스크린샷을 결과 확인용 사진보다 입력 계약으로 본다. 작업이 끝난 뒤 캡처해서 비교하는 것도 중요하지만, 더 중요한 시점은 수정 전이다. 현재 화면을 먼저 찍고, 바꿀 영역과 건드리지 않을 영역을 짧게 적어 둔다. 그러면 에이전트의 첫 행동이 곧장 컴포넌트 수정으로 뛰는 대신 화면 기준선을 유지한 채 변경 반경을 좁히기로 바뀐다.

내가 실제로 쓰는 형식은 복잡하지 않다. 스크린샷 하나와 네 줄이면 충분한 경우가 많다.

• 기준 화면: 지금 믿을 수 있는 화면 캡처 또는 preview URL.
• 수정 영역: 이번에 바꿀 카드, 버튼, 표, 입력창 같은 대상.
• 보존 영역: 헤더, 네비게이션, 하단 여백, 모바일 줄바꿈처럼 그대로 둬야 하는 부분.
• 확인 방식: 완료 후 다시 볼 화면 크기, 브라우저, 비교 기준.

이 네 줄이 있으면 프롬프트가 길지 않아도 작업 모양이 꽤 선명해진다. “카드 간격을 줄여줘”보다 “첨부한 화면에서 두 번째 카드 묶음의 세로 간격만 줄이고, 헤더 높이와 하단 CTA 위치는 유지해 줘”가 낫다. 여기에 “완료 보고에는 수정 전후 스크린샷 차이를 한 문장으로 써 달라”까지 붙이면 결과도 훨씬 판정하기 쉬워진다.

요청문에 같이 넣는 작은 문장

스크린샷을 붙였다고 해서 에이전트가 자동으로 그 의미를 정확히 읽는 것은 아니다. 그래서 나는 이미지와 함께 짧은 작업 문장을 같이 둔다. 핵심은 “이 화면을 참고해 예쁘게 정리해 줘”가 아니라, 어떤 비교를 해야 하는지 먼저 지정하는 것이다. 예를 들면 이런 식이다.

기준 스크린샷에서 카드 리스트 영역만 수정한다.
헤더 높이, 왼쪽 여백, 하단 버튼 위치는 보존한다.
수정 후 데스크톱과 모바일 폭에서 바뀐 점과 그대로 둔 점을 나눠 보고한다.

이 정도 문장만 있어도 작업의 결이 달라진다. 에이전트는 “전체 화면을 개선하라”는 넓은 문제를 받은 것이 아니라, 비교해야 할 기준과 건드릴 수 있는 영역을 받은 상태가 된다. 사람 입장에서도 완료 보고를 볼 때 “그럴듯한가”가 아니라 “기준 화면 대비 약속한 부분만 바뀌었는가”로 판단할 수 있다. 이 차이가 작아 보여도, UI 작업이 세 번 네 번 이어질 때는 꽤 크게 느껴진다.

한 번은 설정 페이지의 카드 폭을 조금 줄이는 작업에서 이걸 놓친 적이 있다. 기능은 그대로였고 테스트도 통과했는데, 오른쪽 도움말 박스가 아래로 밀리면서 처음 의도했던 정보 구조가 바뀌었다. 그때 문제는 CSS 한 줄보다 기준 캡처 부재에 가까웠다. “카드 폭만”이라는 말은 있었지만, 어떤 주변 요소가 그대로 남아야 하는지는 작업 입력에 없었다. 결국 수정 자체보다 비교 기준을 뒤늦게 복원하는 데 시간이 더 들었다. 작은 캡처가 없어서 작은 작업이 커진 셈이다.

초록 로그가 UI 회귀를 잡아 주지는 않는다

UI 작업에서 헷갈리는 점은 테스트가 통과해도 화면이 틀어질 수 있다는 것이다. 빌드가 성공하고 lint가 깨끗해도, 버튼이 한 줄 아래로 밀리거나 표의 첫 열 폭이 바뀌거나 모바일에서 설명 문장이 잘릴 수 있다. 특히 CSS 유틸리티를 조금 건드렸을 때 이런 일이 자주 난다. 그래서 나는 화면 수정 작업에서는 “테스트 통과”를 완료 조건의 전부로 보지 않는다. 테스트는 코드가 부서졌는지 보는 장치이고, 스크린샷은 사람이 보던 화면 계약이 유지됐는지를 보는 장치다.

이 구분을 해 두면 에이전트에게도 덜 억울하다. 에이전트가 일부러 화면을 망친 것이 아니라, 애초에 확인해야 할 표면이 빠져 있었던 경우가 많다. “화면이 이상해졌어”라고 나중에 말하면 에이전트는 어느 시점의 어떤 화면과 비교해야 하는지 다시 추정해야 한다. 반대로 기준 스크린샷과 보존 영역이 있으면, 실패 보고도 더 작아진다. “두 번째 카드 간격은 줄었지만 모바일 375px에서 CTA가 접힘”처럼 바로 다음 수정으로 이어지는 문장이 나온다.

한 장만 남겨도 다음 세션이 덜 흔들림

이 방식은 같은 세션 안에서만 유용한 게 아니다. 모델을 바꾸거나, context가 압축되거나, 다음 날 다시 이어 받을 때도 기준 스크린샷은 꽤 좋은 handoff가 된다. 긴 설명을 다시 쓰지 않아도 “이 화면이 마지막으로 믿을 수 있던 상태”라고 말할 수 있기 때문이다. 여기에 현재 diff, 미확인 화면 크기, 아직 보지 않은 브라우저만 붙이면 다음 세션은 바로 수정으로 뛰기보다 확인부터 시작한다.

나는 특히 모바일 화면에서 이 효과를 많이 봤다. 데스크톱에서는 괜찮아 보이던 여백이 모바일에서는 한 줄을 밀어내고, 카드 안 버튼이 아래로 떨어지는 일이 생각보다 잦다. 그래서 화면 작업을 넘길 때는 데스크톱 한 장만 남기지 않고, 가능하면 모바일 폭 한 장도 같이 둔다. 둘 다 완벽한 시각 회귀 테스트는 아니지만, 적어도 에이전트가 “어떤 화면을 보존해야 하는지”를 더 구체적으로 잡는다.

작업을 작게 만드는 캡처 한 장

스크린샷을 남기는 일이 번거롭게 느껴질 때도 있다. 하지만 UI 수정에서 이 한 장은 설명을 늘리는 것보다 작업을 더 작게 만든다. 기준 화면, 수정 영역, 보존 영역, 확인 방식을 먼저 고정하면 에이전트가 새 디자인을 상상하는 폭이 줄고, 나는 완료 보고를 더 빨리 판정할 수 있다. 결국 중요한 건 멋진 프롬프트가 아니라 다음 비교가 가능한 상태를 먼저 만들어 두는 것이다.

화면 작업을 맡기기 전에 캡처 한 장을 남기는 습관은 사소해 보인다. 그래도 이 습관이 있으면 “대충 괜찮아 보임”과 “의도한 부분만 바뀜” 사이를 훨씬 덜 헷갈린다. 코딩 에이전트에게 UI를 맡길수록, 나는 스크린샷을 결과물이 아니라 시작점으로 두는 편이 안전하다고 느낀다. 그래야 다음 수정도 작아지고, 다음 확인도 말이 된다.