앱을 만들다 보면 화면을 정말 많이 손봅니다. 버튼이 조금 붙어 있어서 띄우고, 글자가 잘려서 줄이고, 색이 안 맞아서 바꾸고… 저는 이걸 AI한테 시킬 때 늘 한 번에 하나씩 했어요. “이 버튼 간격 좀 띄워줘” → 빌드해서 확인 → “이번엔 글자 크기 줄여줘” → 또 빌드 → 확인. 이 왕복이 생각보다 느립니다.
그런데 이번에 재밌는 일이 있었어요. 제가 쓰는 AI 코딩 에이전트가 스스로 “그렇게 하나씩 말고, 이렇게 묶어서 돌리자”며 4단계 작업 방식을 제안한 겁니다. 초보인 저한테도 바로 와닿아서, 오늘은 버그 해결기가 아니라 AI와 일하는 방식에 대해 정리해 보려고 해요. 방법을 제안한 게 사람이 아니라 AI였다는 점도 이 글의 포인트고요.
왜 ‘한 번에 하나씩’이 느릴까
문제는 빌드(build, 코드를 실제로 돌아가는 앱으로 만드는 과정)에 있습니다. 화면 하나 고칠 때마다 빌드하고 기기에서 확인하면, 그 빌드 시간이 매번 쌓여요. 고칠 게 열 군데면 빌드도 열 번입니다.
게다가 AI 입장에서도 손해예요. 한 번에 한 군데만 보여주면, AI는 전체 화면들이 서로 어떻게 얽혀 있는지 모르는 채로 그 한 곳만 고칩니다. 그러다 보면 A 화면을 고치느라 B 화면과 안 어울리게 되는, 그런 어긋남이 생기죠. 마치 시험지를 한 문제씩 가려서 채점하면 “이 학생이 어디서 계속 같은 실수를 하는지” 전체 패턴을 못 보는 것과 비슷해요.
묶음 루프(Batch Loop) 4단계
에이전트가 제안한 방식은, 고칠 것들을 모아서 한 묶음으로 처리하는 흐름이었습니다. 단계별로 풀어보면 이래요.
1단계 — 화면을 몰아서 캡처한다
먼저 손볼 화면들의 스크린샷을 한꺼번에 모읍니다. 홈 화면, 설정 화면, 목록 화면… 신경 쓰이는 상태를 하나씩 고칠 때마다 찍는 게 아니라, 대상이 되는 화면들을 미리 다 찍어두는 거예요. 뒤에서 AI가 이걸 통째로 볼 수 있게요.
2단계 — AI가 화면을 ‘보고’ 할 일 목록을 짠다
여기가 핵심입니다. AI가 그 스크린샷들을 Vision(화면을 글이 아니라 이미지로 직접 이해하는 기능)으로 봅니다. 제가 말로 “버튼이 좀 붙어 있어”라고 설명하는 대신, AI가 화면을 눈으로 보고 어디가 어색한지 직접 짚는 거예요. 그리고 바로 고치지 않고 할 일 목록(백로그, 즉 처리할 작업들을 쌓아둔 목록)부터 만듭니다. “간격 띄우기, 글자 줄이기, 색 맞추기…” 이렇게 계획을 먼저 세우는 단계죠.
3단계 — 수정을 몰아서 적용한다 (아직 빌드 안 함)
계획이 서면 AI가 코드 수정을 연달아 적용합니다. 중요한 건 이 단계에서 매번 빌드하지 않는다는 거예요. 열 군데를 고쳐도 빌드는 미뤄둡니다. 앞에서 빌드 왕복이 느림의 원인이라고 했으니, 그걸 뒤로 몰아버리는 거죠.
4단계 — 한 번에 빌드·테스트하고, 어긋나면 루프가 다시 돈다
이제 몰아둔 수정을 한 번에 빌드하고, 테스트를 돌려 실제 기기에서 확인합니다. 뭔가 어긋나 있으면 그 결과를 다시 AI에게 돌려 자동으로 다시 시도하고요. 이 “확인 → 다시” 가 도는 게 바로 루프입니다. 그리고 다 통과하면 그때 PR(풀 리퀘스트, 내가 고친 코드를 본체에 합치자고 올리는 요청)을 머지해 마무리합니다.
왜 이게 더 빠른가
정리하면 이득이 세 가지예요.
첫째, 빌드 횟수가 확 준다. 열 번 빌드할 걸 한 번으로 줄이니, 쌓이던 대기 시간이 사라집니다.
둘째, AI가 전체 맥락을 쥐고 계획한다. 화면들을 한꺼번에 보니, 한 곳만 고쳐서 다른 곳이 틀어지는 실수가 줄어요. 문제를 한 문제씩이 아니라 시험지 전체로 놓고 푸는 셈이죠 — 딱 한 번만 쓰는 제 수학쌤 비유입니다.
셋째, 내가 리뷰할 단위가 깔끔해진다. 매 수정마다 옆에 붙어 확인하는 대신, 한 묶음이 끝난 결과를 한 번에 검토합니다.
초보가 꼭 챙길 점
이게 편해 보인다고 눈감고 다 맡기면 안 됩니다. 4단계의 마지막이 괜히 “테스트 → PR 머지”인 게 아니에요. AI가 알아서 묶음을 돌리더라도, 실제 기기에서 눈으로 확인하는 것과 PR을 사람이 검토하고 머지하는 것은 남겨둬야 합니다. 자동으로 도는 루프일수록, 마지막에 사람이 지키는 관문이 더 중요해져요. 안 되는 걸 그대로 다시 돌리면, 틀린 풀이를 그대로 다시 쓰는 것과 같으니까요.
그래서 뭘 하면 되나
앱 UI를 AI와 함께 손볼 일이 있다면, 이 표대로 한번 해보세요.
| 단계 | 하는 일 | 초보 팁 |
|---|---|---|
| 1. 캡처 | 손볼 화면을 미리 다 찍는다 | 🟢 한 번에 몰아 찍기 |
| 2. 분석·계획 | AI가 화면을 보고 할 일 목록부터 | 🟡 바로 고치지 말고 계획 먼저 |
| 3. 수정 | 고칠 걸 연달아 적용 | 🟢 중간중간 빌드하지 않기 |
| 4. 빌드·테스트·루프 | 한 번에 빌드→테스트→PR | 🔴 실기기 확인·PR 리뷰는 사람이 |
한 문장 요약: 화면을 하나씩 고치고 매번 빌드하지 말고, 캡처와 수정을 묶어 한 번에 빌드·테스트하는 ‘묶음 루프’로 돌려라 — 단 마지막 확인과 머지는 사람이 쥔다.
처음엔 화면 두세 개만 묶어보는 걸로 작게 시작하는 걸 권해요. 익숙해지면 묶는 단위를 늘리면 됩니다. 재밌는 건, 이 방식을 저에게 알려준 게 사람 멘토가 아니라 AI 에이전트였다는 점이에요. 요즘은 도구가 “이렇게 일하면 더 낫다”고 먼저 제안하기도 하더라고요. 그럴 때 무작정 따르기보다, 오늘처럼 왜 그게 더 나은지 한 번 뜯어보고 받아들이면 그게 진짜 내 것이 됩니다.