Kaisel, 라우팅을 값으로 만든 Flutter 신호

라우팅은 화면 이동이 아니라 앱의 지도다

Kaisel은 "Routes as values"를 내세우는 Dart 3 기반 Flutter 라우터다. 문자열 경로와 codegen 없이 sealed class, exhaustive switch, List 형태의 history stack으로 내비게이션을 표현한다. 표면적으로는 모바일 개발 도구 뉴스처럼 보이지만, AI 코딩 시대에는 더 넓은 의미가 있다. 앱 구조가 타입으로 드러날수록 에이전트가 코드를 읽고 고칠 때 실수할 공간이 줄어든다.

Flutter 공식 문서는 복잡한 deep link와 웹 주소 동기화가 필요한 앱에서는 Router 또는 go_router 같은 패키지를 쓰라고 설명한다. Flutter navigation 문서는 named route의 한계를 분명히 적고, go_router는 사실상 표준적인 declarative routing 선택지로 자리 잡았다. Kaisel은 여기서 한 걸음 더 들어가 경로를 문자열 설정이 아니라 Dart 값으로 다룬다.

Dart 3 sealed class가 만드는 닫힌 세계

Kaisel의 핵심은 Dart 3의 sealed class다. Dart class modifiers 문서에 따르면 sealed는 알려진 subtype 집합을 만들고 switch가 빠짐없이 처리되는지 정적으로 확인하게 한다. 라우트를 sealed type으로 만들면 새 화면을 추가했을 때 컴파일러가 처리하지 않은 분기를 찾아준다. AI 에이전트가 화면 하나를 추가하거나 이름을 바꿀 때 이 차이는 크다.

From go_router 마이그레이션과 auto_route를 비교해 보면 철학이 갈린다. go_router는 경로 중심의 선언적 설정을, auto_route는 코드 생성 기반 타입 안전성을, Kaisel은 직접 작성한 값과 exhaustive switch를 강조한다. 정답은 앱 규모와 팀 취향에 따라 다르지만, "빌드러너 없이 타입으로 라우트 맵을 닫는다"는 선택지는 에이전트 친화적인 면이 있다.

에이전트에게 필요한 것은 예쁜 API보다 검증 가능한 경계다

AI 코딩 에이전트가 Flutter 앱을 수정할 때 흔한 실패는 화면 파일은 추가했지만 라우팅, 탭 히스토리, deep link, analytics observer를 동시에 맞추지 못하는 것이다. Kaisel은 history를 List of route objects로 둔다고 설명한다. push, pop, set이 리스트 연산이 되면 widget tree 없이 테스트할 수 있고, 프로세스 종료 후 복원도 명확해진다. Agent API 설계, 명시적 계약이 안전장치다가 말한 계약의 힘이 UI 라우팅에도 적용된다.

이런 구조는 코드 리뷰에도 유리하다. 에이전트가 새 결제 화면을 추가했다면 reviewer는 문자열 검색으로 경로 누락을 찾는 대신 sealed route subtype과 switch 분기를 본다. SimpleEnglish, 에이전트 문서 품질의 작은 표준처럼 사람과 모델이 모두 읽기 쉬운 구조가 품질을 만든다.

한국 모바일 팀의 적용 기준

Kaisel을 바로 도입할 팀은 아직 신중해야 한다. 새 라우터는 앱의 spine을 바꾸므로 안정성, community support, release cadence를 봐야 한다. 하지만 새 Flutter 프로젝트나 내부 도구라면 실험 가치가 있다. 특히 탭, modal flow, adaptive layout, deep link가 많고 에이전트가 자주 코드를 만지는 팀이라면 라우팅을 값으로 다루는 방식이 유지보수 비용을 줄일 수 있다.

Jelly UI, 촉각적 웹 컴포넌트의 실험이 UI 컴포넌트의 질감을 다뤘다면 Kaisel은 UI 구조의 정합성을 다룬다. AI가 화면을 빠르게 찍어내는 시기에는 미려한 위젯보다 화면 사이의 약속이 더 중요해진다. 라우팅이 깨지면 사용자는 앱 전체를 불신한다.

자주 묻는 질문

Q1: Kaisel은 AI 도구인가요?

A: 직접적인 AI 도구는 아니다. 다만 타입으로 앱 구조를 드러내기 때문에 AI 코딩 에이전트가 안전하게 수정하기 쉬운 형태를 제공한다.

Q2: go_router를 대체해야 하나요?

A: 기존 앱에서 go_router가 안정적으로 동작한다면 성급히 바꿀 필요는 없다. 새 프로젝트나 라우팅 테스트가 중요한 앱에서 비교할 만하다.

Q3: codegen이 없는 것이 왜 장점인가요?

A: 생성 파일과 빌드 단계가 줄어들면 에이전트와 사람이 실제 소스만 보고 변경 영향을 이해하기 쉽다.

Q4: sealed route의 실무 장점은 무엇인가요?

A: 새 route를 추가했을 때 처리하지 않은 switch 분기를 컴파일 단계에서 잡을 수 있다.

Q5: 한국 팀은 무엇을 확인해야 하나요?

A: deep link, browser history, analytics observer, restoration, testability를 현재 라우터와 비교한 뒤 작은 모듈에서 먼저 검증하는 것이 좋다.