Flutter에서 Swift, 그리고 React Native까지 – AI가 어떻게 실험의 장벽을 낮추는가

AI가 나의 일상적인 업무에서 변화시킨 것에 대한 가장 솔직한 설명은 "내 코드를 대신 작성해 준다"가 아닙니다. 물론 코드를 작성해 주기도 합니다. 하지만 그것이 핵심은 아닙니다.

핵심은 이것입니다: AI는 새로운 것을 시도하는 데 드는 장벽을 낮춰줍니다. 다른 언어, 다른 프레임워크, 나에게 맞는지 아직 알 수 없는 디자인 시스템(Design System), 그리고 실제로 시도해 보기에는 비용이 너무 많이 들어 머릿속으로만 굴려보고 버렸을 아키텍처(Architectural) 변형들 말입니다.

그 "너무 많은 비용"이 바로 사라진 것입니다. 그리고 그것은 그 어떤 자동 완성(Tab completion) 기능보다 더 많은 것을 변화시켰습니다.

의도적으로, 먼저 옛날 방식으로

2025년 말, 나는 Flutter와 Dart를 깊이 파고들었습니다. 몇 개의 데모 프로젝트와 몇 개의 일회용 프로토타입(Prototype)을 만들었습니다. 의도적으로 Claude를 사용하지 않고, IDE에 기본적으로 탑재된 단순한 AI 에이전트(AI agents)들만 사용했습니다.

그것은 고집이 아니었습니다. 하나의 결정이었습니다. 새로운 언어를 진정으로 이해하고 싶다면, 언어를 우회하는 것이 아니라 직접 통과해야 하기 때문입니다. 나는 직접 Dart를 타이핑하고, Flutter 위젯 트리(Widget trees)를 스스로 잘못 중첩해 본 뒤, 그것을 다시 스스로 풀어내고 싶었습니다. 그렇지 않았다면 앱은 돌아가겠지만, 프레임워크를 실제로 내면화하지 못한 채 끝났을 것입니다.

그 단계는 느렸습니다. 바로 그렇기 때문에 가치가 있었습니다. 그 이후에 오는 모든 것들은 그 토대 위에 구축됩니다.

Migrena – Flutter 유니버스 안에 머물기

2026년 초, 첫 번째 실제 앱인 편두통 추적 앱 'Migrena'가 나왔습니다. 이때 나는 엄격하게 Flutter 유니버스 안에 머물렀습니다. 하나의 언어, 하나의 프레임워크, 하나의 멘탈 모델(Mental model). 다른 생태계에서 가져오는 것은 없었습니다.

그것은 내가 방금 배운 것을 공고히 하기 위한 올바른 결정이었습니다. 하지만 동시에, 대안을 훑어보지도 않고 편의성을 위해 스택(Stack)을 결정한 마지막 프로젝트이기도 했습니다.

DoomStop – Flutter 프로토타입이 Swift 앱이 되다

다음 프로젝트인 DoomStop은 양상이 달랐습니다. 요약하자면 이렇습니다: Apple의 스크린 타임 API(Screen Time API)는 네이티브 Swift 확장(Swift extensions)에서만 작동하기 때문에, 여기서 Flutter는 잘못된 경로였습니다.

흥미로운 부분은 전환 과정입니다. 저에게는 Flutter 프로토타입이 있었습니다. 이를 몇 주 동안 수작업으로 다시 만드는 대신, 빠르게 살펴보기 위해 그것으로부터 생성된 네이티브 Swift 변형(variant)을 가질 수 있었습니다.

React Native는 이 부분에서 훨씬 더 앞서 있습니다. Callstack의 @callstack/liquid-glass는 iOS 26 효과를 React Native 앱에 네이티브로 가져오며, Expo 생태계의 expo-glass-effect는 Apple의 네이티브 효과 바로 위에 놓이는 GlassView 컴포넌트를 제공합니다. 두 방식 모두 이전 iOS 버전이나 Android에서는 일반 뷰(view)로 깔끔하게 폴백(fallback)됩니다. 별도의 손질 없이도 오늘날 이미 그 기반이 마련되어 있습니다.

진짜 테스트: 그곳이 내 집처럼 편안한가?

이론적으로 따져보는 대신, 저는 그냥 직접 시도해 보았습니다. 저의 Zutato 프로토타입은 여전히 가벼운 상태였습니다. 약간의 인증(auth)과 몇 개의 화면이 전부였죠. 그래서 그것으로부터 생성된 React Native 변형(variant)을 만들었고, 몇 가지 아키텍처(architectural) 결정을 내린 뒤 타이핑을 시작했습니다.

그리고 제가 계획하지 않았던 일이 일어났습니다. 즉시 더 편안하게 느껴진 것입니다. Liquid Glass 때문이 아니었습니다. 바로 언어(language) 때문이었습니다.

제 백엔드(backend)는 TypeScript입니다. 제 어드민(admin)도 TypeScript입니다. 제 웹 프론트엔드(web frontend)도 TypeScript입니다. React Native를 사용하면 서버에서 앱에 이르기까지 동일한 멘탈 모델(mental model)을 유지할 수 있습니다. 하루에도 몇 번씩 Dart와 TypeScript 사이를 오가며 컨텍스트 스위칭(context switch)을 할 필요가 없습니다. 동일한 타입(types), 동일한 패턴(patterns), 그리고 버그가 어디서 발생하는지에 대한 동일한 직관을 가질 수 있습니다.

이것은 객관적인 "React Native가 Flutter보다 낫다"는 뜻이 아닙니다. Flutter는 훌륭한 프레임워크이며, 다른 프로젝트라면 저 역시 다시 Flutter를 선택할 것입니다. 이것은 _나 자신_이 어디에서 생산적인지에 대한 매우 개인적인 깨달음입니다. 그리고 빠른 실험이 없었다면 저는 결코 이를 깨닫지 못했을 것입니다. 그저 Flutter가 저에게 당연한 선택이라고 계속 가정했을 것입니다.

PetTrack – 그렇지 않았다면 절대 손대지 않았을 프로젝트

아마도 가장 명확한 사례는 얼마 전 제가 직접 작성했던 작은 웹 앱인 PetTrack일 것입니다. 순수하게 개인용으로만 사용되었기에 그에 맞춰 성장했습니다. 모든 것이 하드코딩(hardcoded)되어 있었고, 설정 레이어(configuration layer)도 없었습니다. 제가 유일한 사용자였고 모든 값이 어디에 있는지 정확히 알고 있었기 때문입니다.

저는 Claude를 사용하여 앱을 완전히 개편했습니다. 새로운 디자인, 그리고 무엇보다도 오직 저만이 실제로 사용하는 기능을 위한 완전한 어드민 및 설정 백엔드(configuration backend)를 구축했습니다. 오늘날, 과거에 하드와이어드(hardwired)되어 있던 것들은 이제 설정 가능(configurable)해졌습니다.

좋은 시작점과 깔끔한 사양(specs)이 있다면, 이 작업은 거의 결함 없이 실행되었습니다. 하지만 진짜 핵심은 다른 데 있습니다. 저는 절대로 이 작업을 수작업으로 하지 않았을 것입니다. 단일 사용자 앱을 위한 설정 가능한 백엔드(configuration backend)라고요? 절대 아닙니다. 투입되는 노력이 얻을 수 있는 이익에 비해 전혀 비례하지 않았을 테니까요. 하지만 AI와 함께라면, "할 가치가 없다"는 생각이 "음, 안 될 거 없지"로 바뀌었습니다.

그리고 바로 그 점이 당신이 시도하려는 도전의 범위 자체를 변화시킵니다.

이 모든 것의 이면에 있는 패턴

이 프로젝트들을 나란히 놓고 보면, 공통된 실타래는 "AI가 내 앱을 만든다"가 아닙니다. 그것은 바로 "실험 비용이 붕괴되었다"는 점입니다.

다른 언어를 살펴보거나, 디자인 시스템(design system)을 스트레스 테스트(stress-testing)하거나, 몇 시간 동안 문서를 읽지 않고 라이브러리(library)를 평가하거나, UX가 개선되는지 확인하기 위해 대안적인 컴포넌트 변형(component variant)을 구축하는 것—이 모든 것들은 과거에는 너무나 큰 마찰(friction)을 동반했기에, 확신이 서지 않으면 그냥 포기하곤 했습니다. 하지만 오늘날에는 단 몇 분에서 몇 시간 정도의 문제입니다.

이것은 순진한 과대광고가 아닙니다. 이것은 마법 같은 도구입니다. 단, 사용법을 알고 있을 때만 말이죠. AI는 무엇을(what) 만들어야 하는지에 대한 명확성을 앗아가는 것이 아닙니다. 어떤 경로가 애초에 올바른 경로인지 '알아내는(finding out)' 과정에서의 마찰을 제거해 주는 것입니다.

저는 오늘날 더 의도적인 결정을 내립니다. 단순히 추측하는 대신 실제로 더 많은 대안을 확인했기 때문입니다. 그것이 진정한 승리입니다.

AI는 내 코드를 대신 써주는 것이 아닙니다. AI는 무언가를 시도하지 않을 핑계를 없애줍니다.

원문은 grossbyte.io에 게시되었습니다.