💡 「Codex」 활용술: 실록·AI에게 Windows 앱을 Android로 이식하게 해보니, Flutter를 바라보는 관점이 조금 바뀌었다

AI가 이 정도로 자유자재로 코드를 쓸 수 있게 된다면, 「Flutter나 React Native 같은 크로스 플랫폼 (Cross-platform) 기술은 머지않아 불필요해지지 않을까」――.

그렇게 생각하던 시기가 있었습니다. Kotlin도 Swift도 C#도 AI가 완벽하게 구분해서 쓸 수 있다면, 굳이 공통 프레임워크라는 추상화 레이어 (Abstraction Layer)를 끼워 넣지 않고 각 플랫폼의 「정답」대로 개별적으로 작성하면 되는 것이 아닌가 하고 말이죠.

하지만 얼마 전, Windows용으로 직접 만든 작은 타이머 앱을 Android로 이식했을 때, 그 생각이 조금 바뀌었습니다. 공통 프레임워크는 불필요해지는 것이 아니라, 그 역할이 「인간의 노동력 절감」에서 「AI와의 설계 공유를 위한 발판」으로 시프트 (Shift) 되어가는 것이라고 느꼈기 때문입니다.

계기: Windows용 타이머 앱의 존재

이번에 Android로의 이식을 시도한 것은 이전에 WPF (C#)로 작성한 「Visual Progress Timer」라는 앱입니다.

기능: 설정한 시간에 맞춰 화면의 「면」 색상이 서서히 변화하며 남은 시간을 시각화함.

특징: 숫자를 쫓지 않아도 직관적으로 시간을 알 수 있음. 종료 시 알림과 소리가 울림.

이를 스마트폰에서도 사용하고 싶어져서, AI와 상담하며 이식 작업을 진행했습니다.

이번에 작성한 앱은 이런 느낌입니다.

1. 이식은 「변환」이 아니라, AI에 의한 「재구성」이었다

놀라웠던 점은 AI (Codex/Claude)의 제안이 매우 전략적이었다는 것입니다. 단순히 C#의 로직을 Dart로 바꾸는 것이 아니라, 다음과 같은 「재설계」를 스스로 수행하기 시작했습니다.

사양의 해석: 원래 WPF의 동작을 읽어내어, Android에서 재현해야 할 핵심 경험을 정의.

OS 고유의 리스크 회피: 장시간 타이머나 슬립 (Sleep) 모드 시의 동작 등, 모바일 특유의 제약을 고려.

역할 분담: 「UI는 Flutter, OS와 깊게 연관된 알림 기능은 Android 네이티브 (Native)」라는 하이브리드 (Hybrid) 설계를 제안.

그것은 「코드의 변환」이라기보다, 플랫폼의 특성을 이해한 숙련된 엔지니어에 의한 「재구현」에 가까운 경험이었습니다.

2. 장시간 타이머를 통해 보인, 「공통화하지 않는다」는 정답

특히 인상적이었던 것은 종료 알림의 구현입니다. AI는 Flutter 플러그인만으로 완결 지으려 하지 않고, 굳이 Android 네이티브의 메커니즘을 직접 호출하는 구성을 권했습니다.

Flutter가 담당하는 것: 타이머 화면의 묘사, 색상 변경 로직, 다크 모드 (Dark Mode) 대응, 남은 시간의 실시간 표시.

Android 네이티브가 담당하는 것: AlarmManager를 통한 정확한 시간 관리, 알림 권한 핸들링, 단말기 재부팅 후의 타이머 복원.

「OS의 제약이 강한 부분까지 억지로 공통 프레임워크로 은폐 (추상화)하려고 하지 않는 편이, 결국은 솔직하고 견고한 앱이 된다」. AI는 그 경계선을 놀라울 정도로 정확하게 판단해 주었습니다.

3. 그럼에도, Flutter는 「방해」가 아니었다

「AI가 네이티브 코드를 완벽하게 쓴다면, Flutter라는 계층은 불필요하지 않은가?」라는 최초의 의문으로 돌아가 보겠습니다.

결론부터 말하자면, Flutter는 전혀 방해가 되지 않았습니다. 오히려 AI 시대의 개발에 있어 「강력한 공통 언어」로서 기능하고 있었습니다.

UI 재현 속도: 선언적 UI (Declarative UI)를 가진 Flutter는 AI에게 있어 「의도를 코드로 만드는 최단 경로」였습니다.

설계의 발판: UI의 상태 관리 (State Management)와 네이티브 측의 이벤트가 깔끔하게 분리되기 때문에, AI와의 대화 구조가 매우 명확해집니다.

확장성: 「다음은 iOS 버전도」라고 할 때, AI에게도 인간에게도 공통된 구조가 있다는 것은 작업의 압도적인 숏컷 (Shortcut)이 됩니다.

4. 프레임워크의 가치는 「마법」에서 「발판」으로

지금까지 공통 프레임워크의 가치는 「인간이 두 번 쓰지 않아도 되는 마법」이었습니다.

하지만 AI 시대의 가치는 「인간과 AI가 공통의 구조를 이해하고, 변경이나 이식을 원활하게 수행하기 위한 발판」으로 변해가는 것이 아닐까요.

앞으로의 시대에 요구되는 것은 OS의 최신 사양을 블랙박스 (Black Box) 안에 숨겨버리는 「두꺼운 라이브러리 (Library)」가 아니라, AI가 네이티브 사양을 보완하기 쉽고, 또한 인간도 직관적으로 다룰 수 있는 「얇고 전망이 좋은 도구」일지도 모릅니다.

5. 실기에서 울린 알림음

PC와 Android 실기기를 연결하고, 생성된 APK를 설치한 순간.

내가 설정한 「면」이 천천히 색을 바꾸고, 시간이 되면 스마트폰이 떨리며, 설정한 대로의 소리가 울린다.

「이 부분의 테두리 색상, WPF 버전에 좀 더 가깝게 맞춰줘」

「알림 우선순위를 높여서 잠금 화면에서도 보이게 해줘」

그런 대화를 반복하며 앱이 실체를 갖추어 가는 과정은, 이제 '프로그래밍 (Programming)'이라기보다 'AI와의 공동 창작'이었습니다.

마치며: AI 시대의 크로스 플랫폼 (Cross-platform) 개발

AI는 이식 비용을 극적으로 낮추었습니다. 하지만 그것이 크로스 플랫폼 개발을 불필요하게 만드는 것은 아닙니다.

오히려 "이 부분은 공통화하여 속도를 내고, 이 부분은 네이티브 (Native)로 내려가 품질을 담보한다"라는 경계선의 설계를 AI와 함께 시행착오를 거치며 결정해 나가는. 그런 "하이브리드 (Hybrid) 개발"이 앞으로의 표준이 될 것이라는 예감이 듭니다.

이하는 세션 로그입니다.

🧑💻 사용자

VisualProgressTimer를 Android 버전 앱으로 컨버트 (Convert)하고 싶습니다.

지금 상황에서는 Flutter로 만드는 것이 좋을 것 같은데, 어떻게 생각하시나요?

🤖 Codex

Flutter는 상당히 좋은 선택이라고 생각합니다. 특히 VisualProgressTimer가 이름 그대로 "시각적인 타이머", "진행 상황 표시", "애니메이션 (Animation)", "설정 화면" 등을 가진 앱이라면, Android 버전을 만들기 위해 궁합이 좋습니다.

이유는 다음과 같습니다.

• Android/iOS 양쪽 모두 대응하기 쉬움
• UI 재현성이 높고, 커스텀 드로잉 (Custom Drawing)이나 애니메이션에 강함
• 타이머, 알림, 백그라운드 처리 (Background Processing), 로컬 저장 등의 구현이 비교적 쉬움
• Windows 버전의 외관이나 조작감을 모바일용으로 다시 만들기 쉬움
• 향후 Web 버전이나 데스크톱 (Desktop) 버전도 노릴 수 있음

다만, "현재 있는 Windows 앱을 그대로 변환"할 수 있는 것은 아니며, 기본적으로는 Flutter로 다시 만드는 형태가 됩니다. 기존 코드의 로직 (Logic) 부분만 재사용할 수 있는 가능성은 있지만, UI는 모바일 전제로 재설계하는 것이 아마 더 깔끔하게 완성될 것입니다.

개인적으로는 다음과 같은 진행 방식이 좋아 보입니다.

• 기존 앱의 기능을 정리 (Inventory)한다
• Android 버전에서 필요한 화면과 조작을 결정한다
• Flutter로 최소 기능 버전 (MVP)을 만든다
• 타이머 정밀도, 화면 꺼짐 시, 알림, 백그라운드 동작을 조기에 검증한다
• 외관과 사용성을 Windows 버전에 맞춰 나간다

주의할 점은 Android의 백그라운드 제한입니다. 화면을 닫아도 정확하게 타이머를 작동시키고 싶다거나, 종료 알림을 반드시 내보내고 싶다거나, 장시간 타이머를 안정적으로 유지하고 싶다는 요구사항이 있다면, Flutter뿐만 아니라 Android 측의 알림·서비스 (Service) 주변부도 조금 정성스럽게 설계할 필요가 있습니다.

결론적으로, Android 버전을 제대로 만든다면 Flutter로 진행하는 것은 현실적이며 추천할 만합니다. 우선 이 리포지토리 (Repository)를 보고, Flutter 이식의 용이성과 설계안을 내는 것부터 시작하는 것이 좋아 보입니다.

🧑💻 사용자

종료 알림을 반드시 내보내고 싶다, 장시간 타이머를 안정시키고 싶다 ← 이 요구사항은 넣고 싶습니다.

우선 설계안 부탁드립니다.

🤖 Codex

설계 방침으로는, Flutter로 UI를 만들면서 종료 알림의 보장에 가까운 부분만 Android 네이티브 (Native)로 가져가는 것이 좋습니다. Flutter 단독으로 타이머를 계속 돌리는 설계로 하지 않는 편이 안전합니다.

결론

VisualProgressTimer의 Android 버전은 다음과 같은 구성을 추천합니다.

Flutter UI
↓
TimerController / TimerState
...

중요한 사고방식

타이머는 "1초씩 줄이는" 것이 아니라, 시작 시점에 endAt을 저장합니다.

시작 시:
duration = 45분
startedAt = 현재 시각
...

이렇게 하면 앱이 백그라운드로 가더라도, OS에 의해 일시 정지되더라도, 다시 표시될 때 올바른 남은 시간으로 복귀할 수 있습니다.

종료 알림 설계

종료 알림은 Flutter의 화면 갱신과는 별개로, Android의 AlarmManager를 통해 예약합니다.

권장 순서는 다음과 같습니다.

• 알림 권한 POST_NOTIFICATIONS를 획득 - 정확한 알람 권한을 확인
• 허용되어 있다면 AlarmManager로 종료 시각에 정확한 알람을 예약
• 알람 수신 시 알림과 알람음을 출력
• 앱 실행 시·복귀 시·단말기 재부팅 시 타이머 상태를 복원

Android 13 이후는 알림에 POST_NOTIFICATIONS가 필요합니다. Android 14 이후는 정확한 알람이 기본적으로 거부되기 쉬우므로, canScheduleExactAlarms()

를 확인하고, 필요하다면 사용자를 설정 화면으로 안내하는 설계가 필요합니다. 이는 공식 문서에서도 명시되어 있습니다.

「반드시 출력한다」의 현실적인 라인

꽤 중요한 점입니다만, Android에서는 앱 측에서만 100% 보장할 수는 없습니다.

알림이 반드시 나오는 조건은 대략 다음과 같습니다.

• 사용자가 알림을 허용하고 있음
• 정확한 알람 권한(Exact Alarm Permission)이 허용되어 있음
• 앱이 강제 종료(Force Stop)되지 않음
• 단말기의 극단적인 절전 제한에 의해 차단되지 않음
• 알림 채널(Notification Channel)이 비활성화되지 않음

따라서 UI 상에서는, 최초 설정 시 「알림」 「정확한 알람」을 체크하고, 미허용 상태라면 타이머 시작 전에 경고를 띄우는 것이 좋습니다.

Flutter 측 구성안

lib/
main.dart
app.dart
...

Flutter 측의 책임:

• 원형 타이머 UI
• 드래그/스와이프로 분 설정
• Start / Stop / Reset
• 남은 시간 표시
• 테마, 색상 설정
• 상태 저장
• Android native bridge 호출

Android 측 구성안

android/app/src/main/kotlin/.../
MainActivity.kt
TimerAlarmReceiver.kt
...

Android 측의 책임:

• 정확한 종료 알람 예약
• 종료 알림 표시
• 알람음·진동
• 단말기 재부팅 후 복원
• 알림 권한, 정확한 알람 권한 확인

저장할 상태

최소한 이것을 저장합니다.

{
"durationSeconds": 2700,
"startedAtWallMillis": 1710000000000,
...
}

통상적인 상황에서는 elapsedRealtime을 기반으로 남은 시간을 계산하면, 사용자가 시계를 변경해도 틀어지기 어렵습니다. 재부팅 후에는 elapsedRealtime이 리셋되므로, wall clock의 endAtWallMillis로 복원합니다.

패키지 후보

• flutter_local_notifications: 알림 표시·알림 채널·사운드
• android_alarm_manager_plus: Android AlarmManager 이용
• shared_preferences: 가벼운 설정 저장. 단, 중요한 상태는 네이티브 측의 SharedPreferences와 동기화하는 설계가 안심할 수 있음

다만, 종료 알림을 진정으로 안정화하려면, 알람 예약 부분은 Flutter 플러그인에 맡기기보다 Kotlin으로 작게 직접 구현하는 것이 가독성이 좋고 Android의 권한 변경에도 대응하기 쉽습니다.

구현 단계 안

• Flutter로 타이머 UI와 상태 관리를 만든다
• endAt 기반의 타이머 로직으로 만든다
• Android 네이티브로 종료 알람 예약을 구현한다
• 알림 권한·정확한 알람 권한 체크를 추가한다
• 재부팅 복원, 앱 복귀 시의 재동기화를 추가한다
• 실기기에서 화면 꺼짐, Doze, 장시간 유지, 재부팅을 테스트한다

🧑‍💻 사용자

설계는 OK입니다. 그리고 Android 버전은 별도 폴더에 생성하고 싶습니다.

🤖 Codex

Android 버전을 별도 폴더에 생성했습니다. 기존의 Windows 버전은 건드리지 않았습니다.

생성 위치: VisualProgressTimerAndroid

포함된 내용은 Flutter의 타이머 UI와 Android 네이티브 측의 AlarmManager 기반 종료 알림입니다. 앱을 닫아도 종료 시각으로부터 복원할 수 있도록, 1초씩 줄이는 방식이 아닌 endAtWallMillis를 저장하는 설계로 했습니다.

주요 구현:

• Flutter UI: main.dart
• Android 브릿지: MainActivity.kt
• 알람 예약: TimerAlarmScheduler.kt
• 종료 알림: NotificationHelper.kt
• 재부팅 후 복원: BootReceiver.kt

확인 완료했습니다.

flutter analyze
flutter build apk --debug

둘 다 성공했습니다.

23 개의 파일이 변경되었습니다 (+1140 / -0)

• <<생략>>

🧑‍💻 사용자

Android 단말기를 PC에 연결했으므로, 실기기에서 동작 확인을 하고 싶습니다.

🤖 Codex

🧑‍💻 사용자

Android 단말기를 PC에 연결했으므로, 실기기에서 동작 확인을 하고 싶습니다.

🤖 Codex

알겠습니다. 일단 기다리겠습니다.

현재 상태로는 실기기 설치 및 실행에 성공했습니다. 알림 권한도 ADB를 통해 허가되었습니다. 단말기 측에서 Start를 누르고, 시간이 다 되었을 때 알림과 소리가 나는지 확인해 주세요.

🧑‍💻 사용자

알림, 소리 모두 OK입니다. 다만 소리를 멈추는 방법은 어떻게 되어 있나요?

🤖 Codex

현재 구현으로는 "소리를 멈추는 전용 조작"은 아직 없습니다.

현재는 NotificationHelper.kt에서 알림 채널(Notification Channel)에 TYPE_ALARM 소리를 설정하여, 알림이 나오는 타이밍에 Android 측에서 소리가 나도록 하고 있습니다. 즉, 앱 내부에서 MediaPlayer를 실행하는 것이 아니라, OS 알림음으로서 울리고 있는 것입니다.

따라서 현재의 중지 방법은 기본적으로 다음과 같습니다.

• 알림을 탭(Tap)한다
• 알림을 스와이프(Swipe)하여 지운다
• 단말기 측의 알림/음량 조작으로 멈춘다

다만, 이렇게 하면 "알람 앱처럼, 정지 버튼을 누를 때까지 계속 울린다"라거나 "알림에 Stop 버튼을 표시한다"와 같은 제어는 불가능합니다.

본격적으로 구현하려면 다음 설계로 변경하는 것이 좋습니다.

• 종료 시에 알림을 띄운다
• 동시에 AlarmSoundService를 기동하여 MediaPlayer로 소리를 낸다
• 알림에 Stop 액션(Action)을 추가한다
• Stop 누름 시 소리를 멈추고 알림도 지운다
• 앱 화면에도 정지 버튼을 표시한다

현재 확인 결과는 좋습니다. 다음 구현으로는 "종료 알림에 Stop 버튼을 달아서, 소리를 명시적으로 멈출 수 있게 하는 것"이 자연스럽습니다.

🧑‍💻 사용자

알림을 탭하면 소리가 멈추기는 하는데, 그 알림에 STOP 버튼을 추가한다는 말씀이신가요?

🤖 Codex

네, 그 이해가 맞습니다.

지금은 "알림 본체를 탭하면" 알림이 열리면서 결과적으로 소리도 멈추게 됩니다. 여기에 더해, 알림 위에 STOP 버튼을 표시하는 이미지입니다.

Visual Progress Timer
Time is up.
[ STOP ]

STOP을 눌렀을 때의 동작은 다음과 같이 합니다.

• 앱 화면을 열지 않는다
• 알림을 지운다
• 알림음을 멈춘다
• 타이머 상태를 completed 또는 idle로 변경한다

다만, 현재 구현에서는 소리가 OS 알림 채널의 소리로 울리고 있으므로, STOP 버튼으로 확실하게 소리를 멈추려면 구현을 조금 바꾸는 것이 좋습니다.

추천하는 방식은 다음과 같습니다.

• 알림 자체는 무음으로 한다
• 종료 시 Android 측에서 MediaPlayer를 사용하여 알람음을 울린다
• 알림에 STOP 액션을 추가한다
• STOP을 수신하는 BroadcastReceiver에서 MediaPlayer를 정지시킨다
• 알림도 취소(Cancel)한다

이렇게 구성하면 "알림 탭", "STOP 버튼", "앱 내 정지 버튼" 중 어느 것으로든 소리를 멈출 수 있게 됩니다.

🧑‍💻 사용자

왠지 익숙함의 문제인 것 같아서 지금 이대로도 괜찮을 것 같습니다.

이 건은 향후 개선안으로서 별도로 문서에 정리해 두세요.

🤖 Codex

개선안으로 정리했습니다.

추가 위치: future-improvements.md

내용은 현재의 "알림 탭으로 소리가 멈추는" 동작을 초기 버전에서는 유지하면서, 향후 알림에 STOP 버튼을 추가할 경우의 구현 방침과 트레이드오프(Trade-off)를 정리하고 있습니다.

확인도 완료되었습니다.

flutter analyze

— No issues found!

1 개의 파일이 변경되었습니다

VisualProgressTimerAndroid/docs/future-improvements.md

🧑‍💻 사용자

색상 변경 기능이 구현되어 있는데, 타이머의 테두리 색상도 맞춰서 변경해 주지 않겠어요?

🤖 Codex

대응했습니다. 색상 변경 시, 타이머 테두리의 채우기 색상과 테두리 선 색상도 게이지 색상에 맞춰 연하게 변하도록 했습니다.

변경 사항: main.dart

구체적으로는 TimerPainter에 색상 혼합(Color Blend) 처리를 추가하여, Windows 버전과 유사한 느낌으로 다음과 같이 만들었습니다.

• 라이트 모드(Light Mode): 테두리가 선택 색상 쪽으로 은은하게 치우침
• 다크 모드(Dark Mode): 테두리가 선택 색상 쪽으로 조금 더 강하게 치우침
• 테두리 선도 동일한 선택 색상에 맞춰 변화

확인 완료했습니다.

flutter analyze

flutter build apk --debug

둘 다 성공했습니다.

1 개의 파일이 변경되었습니다

VisualProgressTimerAndroid/lib/main.dart

🧑💻 사용자

여기서 테스트하고 있는데 타이머 테두리 색이 바뀌지 않았습니다.

🤖 Codex

아마 원인은 두 가지였습니다.

• 지난번에는 APK를 빌드만 했을 뿐, 실기기(Real Device)에 다시 설치하지 않았습니다.
• 테두리 색의 변화가 매우 미미해서, 실기기에서는 구분하기 어려웠습니다.

지금 테두리 색의 변화를 강화한 뒤, 실기기에 최신 버전 APK를 덮어쓰기 설치(Overwrite Install)하여 다시 실행했습니다.

변경 후에는 색을 Red나 Green으로 바꾸면,

• 타이머 내부 색상
• 외부 테두리 채우기
• 테두리 선

이 함께 바뀌어야 합니다.

확인 완료:

flutter analyze

flutter build apk --debug

adb install -r

로 실기기에 설치

단말기에서 다시 한번 색상 변경을 시도해 보세요.

1 개의 파일이 변경되었습니다

VisualProgressTimerAndroid/lib/main.dart

🧑💻 사용자

OK입니다.

🤖 Codex

다행입니다. 테두리 색도 함께 바뀌는 상태로 반영이 완료되었습니다.

🧑💻 사용자

조금 잡담이 될 수도 있는데, 들어주실 수 있나요?

이번에 Windows 앱을 Android 앱으로 변경해 주셨는데, 지금까지 만져본 느낌으로는 Android나 iOS의 버전 업데이트에 대응하는 것도 꽤 잘 해줄 것 같고, 레거시(Legacy) 코드를 최신 코드로 고치는 것도 전혀 문제없이 해주고 있습니다.

지금까지 라이브러리(Library) 버전 업데이트나 OS 버전 업데이트는 정말 힘들었거든요.

그 재작성을 이렇게나 잘 해내고 있어서 대단하다고 생각하고 있고, 또 이렇게 간단하게 다른 플랫폼으로 앱을 이식할 수 있다면, 지금까지 인간이 노력해 온 '사용하기 쉬운 라이브러리'라든가 'Android와 iOS에서 같은 코드를 돌릴 수 없을까?' 하는 Flutter 같은 기술들에 대해 의견을 듣고 싶습니다. 그런 것들이 AI에게는 방해가 되지는 않나요? 그런 라이브러리를 거치지 않고 네이티브(Native)로 동작하는 코드를 만드는 편이 더 간단하지 않을까 생각했는데... 그 부분에 대해서는 어떻게 생각하시나요?

🤖 Codex

물론입니다. 굉장히 흥미로운 질문입니다.

감각적으로는, AI가 강해질수록 "크로스 플랫폼(Cross-platform) 기술이 불필요해지는" 측면이 조금은 있지만, 전부 없어지기보다는 역할이 바뀔 것이라고 생각합니다.

인간에게 Flutter나 React Native 같은 기술은 "Android와 iOS를 각각 전부 쓰는 것은 힘드니까 공통화하고 싶다"라는 발명이었습니다. AI가 코드 이식이나 API 업데이트를 상당히 도와줄 수 있다면, 확실히 "같은 UI를 Kotlin/Swift로 각각 써도 괜찮잖아"라는 선택지가 현실성을 띱니다.

하지만, 그럼에도 Flutter 같은 계층에는 가치가 남습니다.

이유는, AI에게도 "공통의 추상화 (Common Abstraction)"가 편리하기 때문입니다.

같은 UI, 같은 상태 관리 (State Management), 같은 렌더링 로직 (Rendering Logic), 같은 테스트 관점을 하나의 코드베이스(Codebase)로 다룰 수 있으면, AI도 인간도 리뷰하기 쉽습니다. Android 버전과 iOS 버전에서 동작이 미묘하게 어긋날 리스크도 줄어듭니다.

반면, 이번 종료 알림 같은 부분은 반대입니다.

OS 권한, AlarmManager, 알림 채널 (Notification Channel), 백그라운드 제한 같은 부분은, Flutter에서 너무 숨기기보다는 네이티브에 가깝게 가져가는 것이 정직합니다. AI에게도 "Android의 공식 API에 따라 Kotlin을 작성하는 것"이, 오래된 플러그인 (Plugin)의 특성이나 추상화의 틈새 때문에 고민하는 것보다 쉬울 때가 있습니다.

따라서 앞으로의 설계는 아마 이렇게 될 것이라고 생각합니다.

UI・상태 관리・일반적인 화면:
Flutter 등으로 공통화

OS 밀착형 기능:
(네이티브 작성)

즉 "전부 Flutter"도 "전부 네이티브"도 아니라, 공통화해야 할 부분만 공통화하고, OS다움이 중요한 부분은 네이티브로 작성하는 것이 강력합니다. AI가 있으면 이 하이브리드(Hybrid) 구성의 번거로움이 상당히 낮아집니다.

그리고 AI에게 라이브러리가 방해되느냐고 묻는다면, 이것은 절반은 YES이고 절반은 NO입니다.

YES인 상황:

• 라이브러리가 오래됨
• 추상화가 OS의 최신 사양을 따라가지 못함
• 내부에서 무엇을 하는지 알기 어려움
• 버그 회피를 위한 정체불명의 설정이 많음

NO인 상황:

• 널리 사용되어 정보가 많음
• API가 안정적임
• 공식에 가까움
• 정형화된 처리를 안전하게 숨겨줌
• 테스트가 되어 있음

AI는 코드를 작성하는 속도는 빠르지만, OS의 세밀한 동작이나 단말기 간의 차이를 "실제로 밟아보며 검증하는" 부분은 여전히 현실 세계에 묶여 있습니다. 그렇기 때문에 실적이 있는 라이브러리는 지금도 상당히 고맙습니다.

다만 앞으로는, "인간이 쓰는 양을 줄이기 위한 거대 프레임워크"보다는 AI가 읽기 쉽고, 교체하기 쉬우며, OS의 공식 사양에 가까운 얇은 라이브러리의 가치가 올라갈 것 같다는 느낌이 듭니다.

이번 앱의 경우로 말하자면, Flutter를 선택한 것은 아직 상당히 타당합니다. 시계 UI나 색상 변경, 설정 화면은 Flutter로 기분 좋게 만들 수 있습니다. 반면, 종료 알림이나 장시간 타이머는 Android 네이티브 (Android Native)로 넘겼습니다. 이것은 AI 시대다운, 상당히 좋은 절충안이라고 생각합니다.