바이브 코딩 실전 14화: 드디어 실제 스마트폰에서 실행해봤습니다

지금까지 MyLog는 꽤 많이 성장했습니다.

기록을 작성할 수 있고,

회원가입과 로그인이 되고,

사용자마다 자신의 기록만 볼 수 있고,

Supabase 클라우드에 데이터도 저장됩니다.

개발 화면에서 실행해보면 제법 멀쩡합니다.

에뮬레이터에서도 잘 됩니다.

그렇다면 이제 이런 생각이 듭니다.

여기서 스마트폰을 한 번 꺼내보겠습니다.

오늘은 코드를 거의 추가하지 않습니다.

대신 지금까지 만든 MyLog를 실제 스마트폰에 직접 설치해 사용해봅니다.

그리고 생각보다 빨리 깨닫게 됩니다.

에뮬레이터에서 잘 돌아가는 앱과

실제로 손에 들고 사용할 수 있는 앱은 조금 다르다는 것을요.

1. 에뮬레이터에서 잘 되는데 왜 굳이 실제 폰에서 테스트할까?

Flutter 개발 중에는 Android Emulator나 iOS Simulator가 상당히 편합니다.

앱을 바로 실행할 수 있고,

화면 크기도 바꿀 수 있고,

개발 PC에서 빠르게 확인할 수 있습니다.

문제는 에뮬레이터가 너무 좋은 환경일 때가 많다는 것입니다.

개발 PC는 빠릅니다.

인터넷도 안정적입니다.

화면도 우리가 예상한 크기입니다.

키보드도 상황에 따라 실제 스마트폰과 조금 다르게 느껴질 수 있습니다.

그런데 실제 사용자는 그렇지 않습니다.

저가형 Android 스마트폰

오래된 기기

느린 LTE 환경

배터리 절약 모드

큰 글자 설정

작은 화면

화면 회전

불안정한 Wi-Fi

이런 환경에서도 앱을 사용합니다.

Flutter 공식 문서 역시 Android와 iOS 모두 에뮬레이터나 Simulator뿐 아니라 실제 기기에서 직접 테스트할 수 있도록 별도의 설정 방법을 제공하고 있으며, iOS 문서에서는 실제 기기에서도 테스트할 것을 권장하고 있습니다.

이제 MyLog도 현실 세계로 내보낼 차례입니다.

2. 오늘은 기능을 만들지 않는다

이번 편에서 중요한 원칙입니다.

실기기 테스트를 하면서 문제가 보인다고 바로 이것저것 추가하지 않습니다.

오늘의 목적은

문제를 찾는 것

입니다.

흐름은 이렇게 가져갑니다.

현재 정상 버전

↓

실제 스마트폰 설치

↓

사용

↓

문제 기록

↓

재현

↓

원인 분류

↓

필요한 것만 수정

↓

다시 테스트

기능 개발과 테스트를 동시에 시작하면 무엇 때문에 문제가 생겼는지 또 흐려집니다.

그래서 이번 편에서는 먼저 현재 MyLog가 얼마나 잘 버티는지 보겠습니다.

3. 테스트 전에 Git 상태부터 확인한다

이제 익숙합니다.

git status

현재 변경사항이 없어야 좋습니다.

그리고 이전 회차에서 만든 정상 상태가 커밋되어 있는지도 확인합니다.

예를 들면

feat: 사용자별 Supabase 클라우드 기록 저장 구현

이 상태가 오늘의 테스트 기준 버전입니다.

테스트하다가 수정할 일이 생겨도 무엇을 기준으로 문제가 생겼는지 비교할 수 있습니다.

실기기 테스트에서도 Git은 계속 보험 역할을 합니다.

4. Android 스마트폰부터 연결해보자

Android는 비교적 접근하기 쉽습니다.

실제 Android 기기에서 Flutter 앱을 실행하려면 먼저 스마트폰에서 개발자 옵션과 USB 디버깅을 활성화해야 합니다.

그다음 USB로 PC와 연결하고 스마트폰에

같은 메시지가 나타나면 허용합니다.

Windows 환경에서는 스마트폰 제조사에 따라 별도의 USB 드라이버가 필요할 수도 있습니다.

현재 Flutter 공식 Android 설정 문서에서도 실제 기기 테스트를 위해 개발자 옵션과 USB 디버깅을 켜고, PC 연결을 승인한 다음 flutter devices로 기기 연결을 확인하는 절차를 안내하고 있습니다.

연결됐는지 확인합니다.

flutter devices

정상이라면 내 스마트폰이 목록에 나타납니다.

예를 들면

Galaxy S25
android-arm64

처럼 보일 수 있습니다.

이 순간 은근히 기분이 좋습니다.

가상 스마트폰이 아니라 내 스마트폰 이름이 개발 도구에 나타났기 때문입니다. 📱

5. 이제 진짜 스마트폰에 설치한다

기기가 연결됐다면 평소와 똑같이 실행할 수 있습니다.

flutter run

여러 기기가 연결되어 있다면 특정 기기를 지정할 수도 있습니다.

flutter run -d <device-id>

잠시 빌드가 진행되고,

내 스마트폰 화면에 MyLog가 나타납니다.

이제부터가 오늘의 본게임입니다.

앱 아이콘을 누르고,

직접 키보드로 입력하고,

Wi-Fi도 꺼보고,

앱을 백그라운드로 보내봅니다.

마우스로 클릭하는 앱에서 엄지손가락으로 사용하는 앱이 되는 순간입니다.

6. iPhone은 설정이 조금 더 필요하다

iOS 실제 기기 테스트는 macOS와 Xcode 환경이 필요합니다.

iPhone을 Mac에 연결하고 처음 연결하는 경우 기기에서 컴퓨터를 신뢰하도록 설정합니다.

그리고 iPhone에서는 Developer Mode도 활성화해야 합니다.

현재 Flutter 공식 iOS 설정 문서는 실제 iOS 기기 테스트 시 기기를 Mac에 연결하고 신뢰 설정을 한 뒤, 설정 → 개인정보 보호 및 보안 → 개발자 모드에서 Developer Mode를 활성화하도록 안내합니다.

여기서 중요한 점이 하나 있습니다.

App Store 출시를 위해서는 Apple Developer Program 등록이 필요하지만, 개인 기기에서 개발 테스트만 하는 경우에는 무료 개인 Apple Developer 계정으로도 시작할 수 있습니다.

즉 아직 앱스토어 출시 단계가 아니어도 실제 iPhone에서 MyLog를 실행해볼 수 있습니다.

우리는 출시 등록 이야기는 뒤에서 별도로 다루겠습니다.

7. 첫 번째 테스트는 그냥 평범하게 사용한다

처음부터 인터넷을 끊고 앱을 괴롭히지는 않습니다.

우선 정말 평범하게 사용합니다.

앱 실행

로그인

기록 목록 확인

새 기록 작성

저장

목록 확인

상세 화면 진입

로그아웃

다시 로그인

이 과정이 실제 스마트폰에서도 자연스럽게 되는지 봅니다.

여기서 중요한 건

기능이 작동하는지만 보지 않는 것입니다.

손으로 사용했을 때 불편하지 않은지도 봅니다.

8. 첫 번째로 발견하기 쉬운 문제, 버튼이 생각보다 작다

에뮬레이터에서는 마우스로 클릭합니다.

정확합니다.

실제 스마트폰에서는 손가락을 사용합니다.

갑자기 버튼이 작아 보입니다.

기록 목록에서 특정 영역을 눌러야 상세 화면으로 들어가는데 클릭 영역이 좁다면

한 번,

두 번,

세 번

누르게 됩니다.

그 순간부터 사용자는 앱을 탓하기 시작합니다.

우리에게 필요한 질문은 이런 것입니다.

버튼을 자연스럽게 누를 수 있는가?

목록 전체를 탭해도 되는가?

뒤로가기 위치가 직관적인가?

저장 버튼이 엄지손가락으로 누르기 쉬운가?

예쁜 것보다 먼저 손으로 쓰기 편한지 확인합니다.

9. 두 번째 문제, 키보드가 올라오면 화면이 달라진다

기록 작성 화면을 열어봅니다.

제목을 누릅니다.

스마트폰 키보드가 올라옵니다.

그리고 갑자기 저장 버튼이 사라집니다.

😐

정확히는 키보드 뒤에 가려졌습니다.

에뮬레이터에서도 테스트할 수 있지만 실제 스마트폰에서 긴 내용을 입력해보면 훨씬 쉽게 발견됩니다.

특히 작은 화면에서는

앱바

제목 입력

내용 입력

키보드

만으로 화면이 거의 꽉 차버립니다.

따라서 확인합니다.

키보드가 올라와도 입력 영역이 보이는가?

내용이 길어지면 스크롤할 수 있는가?

저장 버튼에 접근할 수 있는가?

키보드의 완료 버튼 동작은 자연스러운가?

이런 문제가 보인다면

SingleChildScrollView

같은 스크롤 구조나 화면 레이아웃을 다시 검토해야 할 수 있습니다.

하지만 아직 AI에게 무조건 고치라고 하지 않습니다.

문제부터 기록합니다.

10. 세 번째, 긴 글자를 넣어본다

개발 중에는 보통 테스트 데이터를 이렇게 넣습니다.

제목: 테스트
내용: 테스트입니다.

너무 착한 데이터입니다.

실제 사용자는 이렇게 작성할 수도 있습니다.

오늘 회의하면서 정리한 바이브 코딩 앱의 장기적인 개발 방향과 앞으로 해결해야 할 문제점 정리

긴 제목입니다.

본문도 수천 자가 될 수 있습니다.

그래서 일부러 길게 입력해봅니다.

제목이 화면 밖으로 튀어나오지 않는가?

목록에서 너무 많은 줄을 차지하지 않는가?

상세 화면에서 스크롤할 수 있는가?

한글과 영어를 섞어도 문제없는가?

이모지도 넣어봅니다.

오늘 앱 첫 실기기 테스트 📱🚀

앱을 예쁘게 쓰는 테스트보다 조금 못되게 쓰는 테스트가 더 많은 문제를 찾아냅니다.

11. 네 번째, 앱을 백그라운드로 보내본다

기록을 작성하던 중 홈 화면으로 나갑니다.

잠시 다른 앱을 사용합니다.

그리고 MyLog로 돌아옵니다.

작성 중이던 내용이 그대로 있나요?

로그인 상태는 유지되나요?

다시 데이터를 불러오나요?

앱이 완전히 새로 시작되나요?

모바일 앱에서는

앱 실행

↓

백그라운드

↓

복귀

라는 상황이 굉장히 흔합니다.

사용자는 앱을 매번 정식으로 종료하지 않습니다.

카카오톡 보고,

사진 찍고,

브라우저 열고,

다시 돌아옵니다.

그 사이 앱이 어떤 상태를 유지하는지도 제품 품질에 포함됩니다.

12. 다섯 번째, 앱을 완전히 종료한다

이번에는 조금 더 강하게 갑니다.

앱을 최근 앱 목록에서 제거합니다.

다시 실행합니다.

확인할 것은 크게 세 가지입니다.

로그인 Session이 정상적으로 복원되는가?

클라우드 기록을 다시 불러오는가?

화면이 이상한 중간 상태에서 시작하지 않는가?

MyLog는 이미 Supabase Auth와 클라우드 DB를 사용하고 있으므로 이 테스트는 꽤 중요합니다.

정상이라면

앱 실행

↓

Session 확인

↓

로그인 사용자 확인

↓

Cloud Records 조회

↓

목록 표시

순서로 자연스럽게 돌아와야 합니다.

13. 이제 인터넷을 끊어본다

여기부터 MyLog가 조금 긴장하기 시작합니다. 😎

Wi-Fi를 끄고 모바일 데이터도 끕니다.

앱을 실행합니다.

기록을 불러오려고 합니다.

현재 MyLog는 Supabase에서 클라우드 데이터를 가져옵니다.

당연히 실패할 수 있습니다.

여기서 우리가 보는 것은

가 아닙니다.

현재 MVP에는 완전한 오프라인 동기화를 넣지 않았기 때문입니다.

우리가 확인하는 것은 이것입니다.

14. 네트워크가 없다고 앱이 얼어붙어서는 안 된다

나쁜 형태는 이런 겁니다.

로딩 중...

로딩 중...

로딩 중...

로딩 중...

영원합니다.

사용자는 기다립니다.

3초.

5초.

10초.

결국 앱을 종료합니다.

조금 더 좋은 형태는

기록을 불러오지 못했습니다.

네트워크 연결을 확인해주세요.

[다시 시도]

입니다.

그리고 인터넷을 다시 켠 뒤

다시 시도

를 누르면 정상적으로 데이터를 불러오는지 확인합니다.

이런 순간부터 앱이 데모 프로그램에서 실제 제품으로 넘어가기 시작합니다.

15. 느린 네트워크도 생각해야 한다

인터넷은 연결됐다고 항상 빠른 것이 아닙니다.

실제 사용자는 지하철,

엘리베이터,

지하주차장,

해외 로밍,

공공 Wi-Fi

같은 환경에서도 앱을 사용합니다.

이때 API 응답이 늦어질 수 있습니다.

따라서 기록을 불러오는 동안 화면이

하얀 화면

으로 멈춰 있다면 사용자는 앱이 죽었다고 생각할 수 있습니다.

우리가 #13에서 만든 Loading 상태가 여기에서 필요합니다.

기록을 불러오는 중...

혹은 로딩 인디케이터를 보여줍니다.

작은 UI 하나지만 사용자는

라고 이해할 수 있습니다.

16. 로그인 중에도 인터넷을 끊어본다

네트워크 오류는 기록 조회에만 발생하지 않습니다.

로그인 화면으로 갑니다.

이메일과 비밀번호를 입력합니다.

그리고 인터넷을 끕니다.

로그인 버튼을 누릅니다.

앱이 죽나요?

버튼이 계속 눌리나요?

무한 로딩인가요?

아니면

네트워크 연결을 확인해주세요.

라고 알려주나요?

이런 테스트를 해보면 우리가 #12에서 만든 오류 처리가 정말 잘 되어 있는지 확인할 수 있습니다.

17. 저장 버튼을 연속으로 눌러본다

이번에는 인터넷을 다시 켭니다.

새 기록을 작성합니다.

그리고 저장 버튼을 빠르게 여러 번 누릅니다.

다다다다닥.

그러면 어떻게 될까요?

목록에 같은 기록이 두 개,

세 개,

네 개 생긴다면 문제가 있습니다.

#13에서 저장 중 중복 클릭을 방지했던 이유가 여기서 확인됩니다.

저장 시작

↓

버튼 비활성화

↓

서버 응답

↓

성공 또는 실패

↓

버튼 활성화

정도가 필요합니다.

자동화 테스트도 중요하지만 이런 종류의 문제는 사람이 직접 앱을 막 눌러보면 아주 빨리 발견됩니다.

18. 뒤로가기 버튼도 눌러본다

Android 사용자라면 시스템 뒤로가기 동작도 중요합니다.

예를 들어

Record List

↓

Record Detail

로 들어갑니다.

시스템 뒤로가기를 누릅니다.

목록으로 정상적으로 돌아오나요?

작성 화면에서 내용을 입력하다가 뒤로가기를 누르면?

그냥 사라지나요?

저장하지 않은 내용이 있다면 확인창이 필요할까요?

현재 MVP에서는 기능을 추가하지 않더라도 이런 상황을 출시 전 개선 후보로 기록할 수 있습니다.

모든 문제를 발견하는 즉시 해결할 필요는 없습니다.

우선 목록을 만듭니다.

19. Android와 iPhone 둘 다 확인해야 할 이유

Flutter의 큰 장점 중 하나는 동일한 코드베이스로 여러 플랫폼을 대상으로 개발할 수 있다는 점입니다.

하지만 그렇다고 실제 화면과 동작이 100% 같다는 의미는 아닙니다.

Android와 iOS는

뒤로가기 동작,

키보드,

시스템 글꼴,

상태바,

Safe Area,

네비게이션 영역,

권한 UX

등에 차이가 있습니다.

따라서

Android에서 성공

=

iOS에서도 자동 성공

으로 생각하면 안 됩니다.

가능하다면 최소한 Android 1대와 iPhone 1대에서는 주요 흐름을 직접 확인하겠습니다.

Flutter 공식 문서 역시 각각 실제 Android 및 iOS 기기에서 앱을 실행하고 테스트할 수 있는 별도의 개발 흐름을 제공합니다.

20. 작은 스마트폰에서도 한번 보고 싶다

내 스마트폰이 최신 플래그십이라고 해보겠습니다.

화면이 큽니다.

CPU도 빠릅니다.

메모리도 많습니다.

MyLog가 아주 잘 됩니다.

그렇다고 제품 성능이 좋다고 결론 내리기는 이릅니다.

가능하다면 다른 화면 크기의 기기나 조금 낮은 성능의 Android 기기에서도 확인해보는 것이 좋습니다.

최소한 에뮬레이터를 이용해 다양한 화면 크기는 확인할 수 있습니다.

특히 체크할 부분은

텍스트 잘림

버튼 겹침

Overflow

키보드 가림

목록 스크롤

Safe Area

입니다.

화면이 깨지는 순간 Flutter는 꽤 친절하게 줄무늬 경고까지 보여줍니다.

개발자의 마음에는 친절하지 않습니다. 🟨⬛

21. 글자 크기를 키워본다

실제 스마트폰에는 사용자 설정이 있습니다.

글자 크기를 크게 사용하는 사람도 있습니다.

이때 앱이

기본 글자 크기에서만 정상

이라면 문제가 될 수 있습니다.

특히 제목과 버튼 글자가 커졌을 때

줄이 바뀌거나,

버튼이 잘리거나,

레이아웃이 밀릴 수 있습니다.

아직 완벽한 접근성 검토 단계는 아니지만 실기기에서 시스템 글자 크기를 한번 키워보는 테스트 정도는 지금부터 습관으로 들이면 좋습니다.

이 부분은 출시 전 UI 및 접근성을 점검하는 #21에서 더 깊게 다루겠습니다.

22. 성능은 Debug 모드만 보고 판단하면 안 된다

실제 스마트폰에서 앱을 실행했더니 화면 전환이 조금 버벅입니다.

바로

라고 판단하면 안 됩니다.

기본 flutter run은 일반적으로 Debug Mode로 실행됩니다.

Flutter 공식 문서에서는 Debug Mode가 빠른 개발과 디버깅을 위해 구성된 모드이며 실행 성능이나 앱 크기 최적화를 위한 모드가 아니라고 설명합니다.

성능을 제대로 확인하려면 Profile Mode를 사용합니다.

flutter run --profile

Flutter 공식 성능 문서 역시 실제 성능 측정은 Debug Mode가 아니라 Profile Mode에서 진행하도록 안내하고 있습니다.

즉

Debug에서 조금 느림

↓

바로 성능 버그 판정

은 하지 않습니다.

성능 문제는 나중에 #20에서 DevTools와 함께 제대로 살펴보겠습니다.

23. 그래도 스크롤은 한번 거칠게 해보자

MyLog에 기록을 여러 개 만들어봅니다.

10개,

30개,

50개.

그리고 목록을 빠르게 위아래로 스크롤합니다.

버벅거리나요?

화면이 멈추나요?

기록을 누르면 반응이 늦나요?

현재 데이터가 많지 않다면 크게 문제가 없을 겁니다.

하지만

와

는 다른 이야기입니다.

오늘은 성능 최적화까지 가지 않고 문제가 있는지 체감 정도만 확인하겠습니다.

24. 실기기에서는 실제 네트워크 환경도 보인다

개발 PC에서는 Supabase 요청이 항상 빠르게 느껴질 수 있습니다.

하지만 실제 스마트폰에서 테스트하면

앱 실행

↓

Session 확인

↓

클라우드 데이터 요청

↓

응답 대기

↓

화면 표시

순서가 눈에 보이기 시작합니다.

이때

로그인 화면이 잠깐 나타났다가 목록으로 바뀌거나,

빈 목록이 순간적으로 나타났다가 데이터가 채워지거나,

로딩 화면이 깜빡이는

현상도 발견할 수 있습니다.

이런 현상을 화면 깜빡임이나 상태 전환 문제로 기록해둡니다.

앱이 기능적으로 틀린 것은 아니지만 사용 경험은 어색할 수 있습니다.

25. 테스트하면서 발견한 문제는 바로 AI에게 던지지 않는다

예를 들어 이런 문제를 발견했습니다.

바로 AI에게

하지 말고 먼저 상황을 명확하게 만듭니다.

실제 Android 스마트폰에서
Record Create 화면을 테스트했다.

문제:
내용 입력을 위해 키보드가 올라오면
작은 화면에서 저장 버튼에 접근하기 어렵다.

에뮬레이터에서는 같은 문제가 잘 보이지 않았다.

아직 코드를 수정하지 말고

1. 원인
2. 영향을 받는 화면
3. 수정 방법 후보
4. 기존 레이아웃에 미치는 영향

을 먼저 분석해줘.

이제 AI에게 실제 재현 조건을 줄 수 있습니다.

그냥

보다 훨씬 좋은 디버깅 정보입니다.

26. 버그를 기록하는 간단한 방법

첫 실기기 테스트부터 거창한 버그 관리 시스템이 필요한 것은 아닙니다.

프로젝트 안에 작은 파일 하나를 만들어도 됩니다.

docs/
├── PRD.md
├── PROJECT_RULES.md
├── APP_FLOW.md
└── TEST_NOTES.md

예를 들어

# MyLog 실기기 테스트

## BUG-001

환경:
Galaxy / Android

재현:
Record Create → 내용 입력 → 키보드 표시

문제:
저장 버튼이 키보드에 가려짐

심각도:
Medium

상태:
Open

이 정도면 충분합니다.

이렇게 기록하면

를 반복하지 않아도 됩니다.

AI에게 TEST_NOTES.md를 보여주고 우선순위를 정하게 할 수도 있습니다.

27. 모든 문제를 버그라고 부르지 않는다

테스트 중 이런 생각도 생길 수 있습니다.

이건 버그가 아닙니다.

BUG

기능이 요구사항대로 동작하지 않음


IMPROVEMENT

동작하지만 개선하면 좋음

으로 나눠보는 것이 좋습니다.

예를 들어

BUG
로그아웃 후 다른 사용자의 기록이 보임

이건 즉시 해결해야 합니다.

반면

IMPROVEMENT
목록 카드 간격을 조금 줄이면 좋을 것 같음

은 나중에 처리해도 됩니다.

실기기 테스트를 하면 개선 아이디어가 폭발합니다.

여기서 또 기능이 살찌기 시작하지 않도록 조심해야 합니다.

28. 특히 사용자 데이터 문제는 최우선으로 본다

오늘 테스트에서 다음 문제가 발견된다면 UI 문제보다 먼저 해결합니다.

다른 사용자 기록이 보임

로그아웃 후 이전 사용자 데이터가 남아 있음

저장했다고 표시됐는데 실제 DB에 없음

같은 기록이 중복 저장됨

앱 재실행 후 데이터가 사라짐

이런 것은 데이터 신뢰와 관련된 문제입니다.

버튼 위치나 색상보다 훨씬 중요합니다.

제품에서 사용자가 가장 먼저 믿어야 하는 것은

이기 때문입니다.

29. 첫 실기기 테스트 체크리스트

이제 우리가 직접 MyLog를 테스트할 체크리스트를 만들어보겠습니다.

[ ] 실제 스마트폰에서 앱이 설치된다.
[ ] 앱이 정상적으로 실행된다.
[ ] 첫 실행에서 크래시가 발생하지 않는다.

[ ] 회원가입할 수 있다.
[ ] 정상적으로 로그인할 수 있다.
[ ] 잘못된 비밀번호가 적절히 처리된다.
[ ] 앱 재실행 후 Session이 정상적으로 복원된다.
[ ] 로그아웃 후 이전 사용자 데이터가 보이지 않는다.

[ ] 새 기록을 작성할 수 있다.
[ ] 제목 필수 검증이 동작한다.
[ ] 기록이 클라우드에 저장된다.
[ ] 앱 재실행 후 다시 불러온다.
[ ] 상세 화면이 정상적으로 열린다.

[ ] 키보드가 입력 영역을 심하게 가리지 않는다.
[ ] 작은 화면에서도 주요 버튼을 누를 수 있다.
[ ] 긴 제목이 레이아웃을 깨뜨리지 않는다.
[ ] 긴 본문을 스크롤할 수 있다.
[ ] 한글, 영어, 이모지가 정상 표시된다.

[ ] 인터넷이 없을 때 앱이 멈추지 않는다.
[ ] 기록 조회 실패 메시지가 표시된다.
[ ] 로그인 네트워크 오류가 처리된다.
[ ] 다시 시도할 수 있다.
[ ] 저장 중 버튼 연타로 중복 기록이 생기지 않는다.

이 정도만 해도 첫 실기기 테스트에서 꽤 많은 문제를 잡을 수 있습니다.

30. 실제 기기 테스트를 자동화할 수도 있다

지금은 손으로 테스트하고 있지만 앱이 커지면 같은 작업을 매번 반복하기 어렵습니다.

Flutter는 Integration Test를 실제 Android 및 iOS 기기에서도 실행할 수 있도록 지원합니다. 공식 문서에서는 연결된 실제 모바일 기기에서 integration test를 실행하는 방법을 제공하고 있습니다.

예를 들어 나중에는

로그인

↓

기록 작성

↓

목록 확인

↓

상세 화면 확인

같은 핵심 사용자 흐름을 자동화할 수 있습니다.

하지만 오늘은 자동화보다 먼저

사람이 직접 사용하면서 무엇이 불편한지 느끼는 단계

가 중요합니다.

자동화 테스트는 버튼이 눌렸다는 것은 알려줄 수 있어도

까지는 대신 느껴주지 못합니다.

31. 테스트가 끝났다면 우선순위를 정한다

예를 들어 오늘 다섯 개의 문제가 발견됐다고 해보겠습니다.

1. 다른 사용자 데이터가 순간적으로 표시됨

2. 네트워크가 없으면 무한 로딩

3. 키보드가 저장 버튼을 가림

4. 긴 제목이 두 줄로 어색하게 표시됨

5. 앱 아이콘이 아직 Flutter 기본 아이콘

무엇부터 할까요?

당연히 1번입니다.

대략 이런 기준으로 보면 편합니다.

P0
보안, 데이터 손실, 앱 실행 불가

P1
핵심 기능 사용 불가

P2
불편하지만 사용 가능

P3
디자인이나 사소한 개선

그러면 위 문제는 대략

1 → P0
2 → P1
3 → P1 또는 P2
4 → P2
5 → P3

정도로 볼 수 있습니다.

바이브 코딩에서 AI가 빠르다고 발견된 문제를 전부 동시에 해결시키지 않습니다.

중요한 것부터 하나씩 고칩니다.

32. 수정할 때도 한 번에 하나씩

네트워크 무한 로딩을 해결한다고 해보겠습니다.

AI에게 이렇게 요청합니다.

실기기 테스트 결과
네트워크가 없는 상태에서 Record List 화면이
계속 Loading 상태로 유지되는 문제가 확인됐다.

이번 작업에서는 이 문제만 수정한다.

완료 조건:

1. 네트워크 오류가 발생하면 Loading이 종료된다.
2. 사용자에게 오류 상태가 표시된다.
3. 다시 시도 버튼을 제공한다.
4. 인터넷 복구 후 다시 시도하면 Record를 정상 조회한다.
5. 인증과 다른 Record 기능은 변경하지 않는다.

수정 전에 원인과 변경 파일을 먼저 설명해줘.

수정합니다.

실제 스마트폰에서 다시 테스트합니다.

정상입니다.

Git Commit.

그리고 다음 문제로 갑니다.

우리가 지금까지 계속 사용했던 개발 루프가 실기기 테스트에서도 그대로 유지됩니다.

33. Debug 모드의 속도에 너무 예민해지지 말자

실제 스마트폰에 앱을 넣으니 첫 화면이 조금 느립니다.

스크롤도 약간 어색해 보입니다.

이때 바로 대규모 최적화를 시작하지 않습니다.

Flutter 공식 문서에 따르면 기본 flutter run은 Debug Mode이며, 이 모드는 개발과 디버깅에 초점을 둔 환경이라 실제 출시 성능을 판단하기에는 적합하지 않습니다. 실제 성능 분석에는 Profile Mode를 사용하는 것이 권장됩니다.

따라서 성능이 의심된다면 먼저

flutter run --profile

로 확인해봅니다.

본격적인 성능 분석은 #20에서 DevTools를 열고 제대로 파헤쳐보겠습니다.

지금은 성급하게 최적화하지 않습니다.

최적화는 개발자가 빠지기 쉬운 또 다른 아름다운 늪입니다. 🐊

34. 실기기 테스트를 하면 앱을 보는 눈이 달라진다

이번 편에서 새로운 기능은 거의 만들지 않았습니다.

그런데 실제 스마트폰에 넣어보면 지금까지 보이지 않았던 것들이 눈에 들어옵니다.

에뮬레이터에서는

가 중심이었다면,

실기기에서는

로 질문이 바뀝니다.

터치하기 편한가?

기다리는 동안 무엇이 보이는가?

오류가 났을 때 사용자는 무엇을 해야 하는가?

앱을 나갔다 돌아와도 괜찮은가?

인터넷이 끊어져도 앱이 망가지지 않는가?

다른 사용자 데이터가 섞이지 않는가?

바로 이 질문들이 MVP와 제품 사이의 차이를 조금씩 채워줍니다.

35. 오늘의 완료 조건

이번 편도 마지막으로 확인해보겠습니다.

[ ] 실제 Android 또는 iPhone에 MyLog를 설치했다.

[ ] flutter devices에서 실제 기기를 확인했다.

[ ] 실제 기기에서 로그인부터 기록 조회까지 테스트했다.

[ ] 기록을 새로 작성하고 클라우드 저장을 확인했다.

[ ] 앱을 백그라운드로 보냈다가 다시 사용했다.

[ ] 앱을 완전히 종료한 뒤 다시 실행했다.

[ ] Session 복원 상태를 확인했다.

[ ] 로그아웃 후 사용자 데이터가 섞이지 않는지 확인했다.

[ ] 긴 제목과 긴 본문을 입력해봤다.

[ ] 한글, 영어, 이모지를 함께 저장해봤다.

[ ] 키보드가 화면을 가리는지 확인했다.

[ ] 인터넷을 끊은 상태를 테스트했다.

[ ] API 오류 후 다시 시도할 수 있는지 확인했다.

[ ] 저장 버튼을 빠르게 여러 번 눌러봤다.

[ ] 발견한 문제를 BUG와 IMPROVEMENT로 구분했다.

[ ] 수정이 필요한 문제를 우선순위별로 정리했다.

여기까지 했다면 MyLog는 이제 처음으로 실제 스마트폰에서 살아본 앱이 됐습니다.

그리고 아마 체크리스트를 전부 통과하지 못했을 겁니다.

그게 정상입니다.

오히려 아무 문제도 발견하지 못했다면

조금 더 못되게 테스트해볼 필요가 있습니다. 😈

36. 그런데 문제가 하나 생겼다

실기기 테스트를 반복하면서 버그를 고칩니다.

AI에게

저기서 또 문제가 생깁니다.

코드는 점점 늘어납니다.

처음에는 main.dart와 화면 몇 개뿐이었는데,

이제 Auth,

Supabase,

RecordService,

화면 상태,

오류 처리까지 들어왔습니다.

그리고 어느 순간 AI가 이렇게 말하기 시작합니다.

드디어 올 것이 왔습니다.

바이브 코딩 프로젝트에서 흔히 만나는 다음 문제입니다.

처음에는 너무 잘 만들던 AI가 프로젝트가 커질수록 조금씩 코드를 엉키게 만드는 현상.

다음 편에서는 이 문제를 정면으로 다뤄보겠습니다.

[바이브 코딩 실전 #15] AI가 만든 코드는 왜 점점 엉킬까? | 바이브 코딩 리팩터링 입문

다음 편에서는

리팩터링이 무엇인지,

언제 해야 하는지,

왜 "전체 코드 깔끔하게 정리해줘"가 위험한 요청인지,

AI에게 안전하게 구조를 정리시키는 방법

을 MyLog에서 직접 살펴보겠습니다.

앱이 커지고 있습니다.

이제 방을 하나씩 늘리는 것만으로는 부족합니다.

복도도 한번 정리할 때가 됐습니다. 🧹📱

연재 기준: 2026년 8월현재 Flutter 공식 문서는 실제 Android 기기에서 개발자 옵션과 USB 디버깅을 활성화한 뒤 flutter devices로 연결을 확인하도록 안내하고 있으며, iOS에서는 Xcode와 Developer Mode 설정 후 실제 기기 테스트를 지원합니다. 또한 성능 확인은 Debug Mode가 아니라 Profile Mode에서 수행하는 것이 권장됩니다. 실기기 설정과 플랫폼 요구사항은 변경될 수 있으므로 실제 테스트 시점의 Flutter 공식 문서를 함께 확인하는 것이 좋습니다.

#바이브코딩 #VibeCoding #AI코딩 #Flutter #Flutter실기기테스트 #앱테스트 #Android앱개발 #iOS앱개발 #FlutterRun #모바일앱테스트 #QA #비개발자앱개발 #MVP테스트 #Supabase #MyLog #바이브코딩실전