AI로 만든 MVP 화면이 흔들릴 때, 실제로 수정한 순서

처음 한 일은 화면을 다시 보는 것이었다

코드를 보기 전에 먼저 실제 화면을 봤습니다. 비개발자 고객이 느끼는 문제는 코드의 함수 이름이 아니라 눈앞의 화면입니다.

확인한 것은 이런 것들이었습니다.

• 첫 화면에서 핵심 이미지가 중앙에 안정적으로 보이는가
• 모바일에서 카드가 한 화면 안에 자연스럽게 쌓이는가
• 이미지 로딩 전후에 레이아웃이 튀지 않는가
• 언어 선택 UI가 다른 버튼과 충돌하지 않는가
• nav 간격과 로그인 아이콘이 화면 크기별로 어색하지 않은가
• 카드 안 인물 이미지의 비율과 높이가 일정한가

이 단계에서 중요한 건 "보기 좋게"가 아니라 "어디가 사용자를 방해하는지"를 찾는 것입니다. 예쁜 화면과 안정적인 화면은 다릅니다. MVP에서는 안정적인 화면이 먼저입니다.

AI가 만든 코드는 증상이 여러 곳에 나뉘어 있다

AI로 만든 코드에서 자주 보이는 패턴이 있습니다. 하나의 문제처럼 보이지만 실제 원인은 여러 곳에 흩어져 있습니다.

예를 들어 카드 높이가 안 맞는다고 해서 카드 CSS만 고치면 끝나지 않습니다. 이미지 원본 비율, 부모 컨테이너 높이, 모바일 breakpoint, 애니메이션 시작 상태, lazy loading까지 같이 봐야 합니다.

언어 선택 UI도 마찬가지입니다. 드롭다운 위치만 바꾸면 되는 것처럼 보이지만, nav의 z-index, 모바일 헤더 높이, 홈 화면 애니메이션과 겹치는지까지 확인해야 합니다.

이런 상황에서 AI에게 "카드 높이 맞춰줘"라고만 시키면 한 군데는 좋아지고 다른 화면이 깨질 수 있습니다. 실제 작업에서는 문제를 다음처럼 나눴습니다.

1. 홈 화면 중앙 이미지와 애니메이션
2. Talk/Read 카드 섹션의 높이와 이미지 비율
3. 모바일 Home 화면의 여백과 줄바꿈
4. nav 간격과 로그인 아이콘 표시
5. 언어 선택 UI의 위치와 충돌 여부

이렇게 나누면 수정 범위가 작아지고, 고객에게도 "무엇을 고쳤는지" 설명하기 쉬워집니다.

전체를 갈아엎지 않고 현재 구조 안에서 고쳤다

처음 보는 MVP 코드를 받을 때 가장 위험한 선택은 마음에 안 든다고 구조를 전부 바꾸는 것입니다. 개발자 입장에서는 새로 정리하고 싶을 수 있지만, 고객 입장에서는 갑자기 다른 문제가 생기면 더 불안합니다.

이번 작업에서는 현재 정적 HTML 구조를 유지했습니다. 대신 화면이 흔들리는 원인을 만드는 부분만 좁혀서 수정했습니다.

• 이미지 영역에는 안정적인 비율과 높이 기준을 둠
• 모바일 카드에는 화면 폭에 맞는 여백과 높이 기준을 둠
• nav와 로그인 아이콘은 공통 기준 안에서 정렬
• 언어 선택 UI는 다른 인터랙션과 충돌하지 않게 위치 정리
• 애니메이션은 시작 전후 레이아웃이 바뀌지 않게 조정

이 방식의 장점은 고객이 검수하기 쉽다는 점입니다. "완전히 달라진 사이트"가 아니라 "불안정했던 부분이 안정된 사이트"가 됩니다.

GitHub PR에는 비개발자가 이해할 수 있게 남겼다

작업은 별도 브랜치에서 진행하고 GitHub PR로 정리했습니다. PR에는 파일 목록만 적지 않았습니다. 비개발자 고객이 이해할 수 있도록 세 가지를 남겼습니다.

• 문제 원인: 왜 화면이 흔들렸는지
• 해결 방식: 어떤 기준으로 수정했는지
• 확인 방법: 고객이 어떤 화면에서 무엇을 보면 되는지

예를 들어 "CSS 수정"이라고 쓰는 대신 "이미지가 늦게 로딩될 때 카드 높이가 다시 계산되면서 모바일 화면이 흔들리던 문제를, 이미지 영역의 기준 높이와 비율을 고정해 줄였습니다"처럼 적었습니다.

비개발자에게 중요한 것은 코드 한 줄이 아닙니다. 내가 맡긴 작업이 어디까지 끝났고, 무엇을 확인하면 되는지입니다. 그래서 PR 설명은 작업물의 일부라고 봐야 합니다.

이런 문제를 맡기기 전에 준비하면 좋은 것

비슷한 상황이라면 처음부터 완벽한 문서를 준비할 필요는 없습니다. 아래 정도만 있어도 진단 속도가 빨라집니다.

• 문제가 보이는 화면 주소
• 데스크톱과 모바일 중 어디에서 더 심한지
• 캡처나 화면 녹화
• 최근 AI가 수정한 내용이나 커밋
• GitHub 저장소 여부
• "어디까지 되면 해결인지"에 대한 기준

예를 들어 "모바일에서 카드가 이상해요"보다 "아이폰에서 홈 화면을 열면 카드 이미지가 로딩된 뒤 아래 영역이 밀립니다"가 훨씬 좋습니다. 개발자는 그 문장으로 재현부터 시작할 수 있습니다.

정리

AI로 만든 MVP 화면이 흔들릴 때는 바로 새로 만들기보다 먼저 나눠서 봐야 합니다.

1. 실제 화면에서 사용자가 느끼는 문제를 확인한다
2. 문제를 화면 단위로 나눈다
3. 현재 구조를 유지한 채 필요한 부분만 수정한다
4. 별도 브랜치에서 작업한다
5. PR에 원인, 해결 방식, 확인 방법을 남긴다

이 과정을 거치면 작은 UI 이슈도 "그냥 감으로 고친 것"이 아니라 검수 가능한 작업이 됩니다. LastFix가 실제 작업에서 중요하게 보는 지점도 여기입니다. 빠르게 고치되, 추측으로 덮지 않는 것.

관련 글: AI 코딩 에이전트가 고치지 못하는 버그의 3가지 특징, Lovable로 만든 사이트 수정이 안 될 때, AI가 만든 코드가 점점 복잡해질 때 멈춰야 하는 신호