(작성중) FlutterKaigi 2025 참가 세션 정리

DevLETi·2025년 11월 15일

느낀점

상상 이상으로 Flutter에 관심을 가지고 있는 회사/사람이 많았다.
역시 1년은 초보다. 전문 검색을 구현하기 위해 강의에서만 본 FFI를 활용해 Rust 코드를 Dart까지 끌어오는 테크닉에 경외심이 들었다. Rust -> Native Code -> Dart였는데 아직도 이해가 잘 안된다..
Flutter 만지자마자 설렜다. 주변 스태프분들에게 열심히 내년 개발에 참여하고 싶다고 어필했는데 참여가능하면 좋겠다.
최근 회사 적응 + 업무량으로 인해 개발을 거의 놓다싶이 했는데 다시 동기부여가 되었다.
언어는 문제를 해결하기 위한 툴이라는걸 다시 한번 상기시켜주는 컨퍼런스였다. 문제 정의, 해결을 위한 to-do 정의, 각각의 to-do를 해결해주는 패키지/코드/언어의 특징 조사, 이후 적용. 이 순서를 유념하면서 일을 하면 생산성이 올라가지 않을까.

들었던 세션

The Flutter Effect (KeyNote)

게임을 하다가 작동방식을 궁금하게 되어 유니티 입문
이후 스타트업, 모바일 어플 개발 등을 경험하다가 플러터 입문
직장에서 지역 플러터 컨퍼런스가 있다는 소식을 듣고 참여했다가 여러 기술을 알게 되었고 다양한 이야기 및 여러가지 매력에 빠지게 됨
이후 기회가 되어 FlutterCon(?)에서 강연자가 됨
그렇게 GDE(Google Developer Experts) 한분을 만나게 됨
우연히 다른 컨퍼런스에서도 만나게 되었고, GDE가 되기 위한 추천을 받아 2개의 테스트를 볼 수 있게됨
합격! GDE가 되었습니다!
'나비효과처럼 작은 행동이 GDE까지 이어지게 되었습니다.'

개발 기술과 관련된 내용은 아니었지만 이 강의로 열심히 다양한 활동을 해서 주도적으로 기회를 늘려야겠다는 생각을 하게 되었다.

Hands on

독서 동기를 높여주는 Flutter Application의 UI를 더 예쁘게 만들어보는 핸즈온
기본적으로 코드가 이미 주석처리로 작성되어 있고 주석 처리를 해제해가며 적용해보는 방식 (handson_document.md)
달성률에 따른 축하 UI를 여러 layer로 분리해 하나씩 층층히 쌓아가며 구현 (배경, 원 그래프 + 메세지, 컨페티)

unawaited(Future 안기다림), CustomPainter를 통한 원형 파문 그리기, 이전 데이터에서 새로운 데이터로 값 이동을 도와주는 Tween 위젯 등을 알게 되었다

GoldenTest
- 어느 시점의 코드로 렌더링된 UI의 화면을 기대화면으로서 사진으로 저장해두고, 실제 렌더링 결과와 비교를 행하는 테스트.
- 비교해서 차이가 있으면 Test 실패 판정.
- (ex:기대화면의 가운데 텍스트가 100인데 실제 가운데 텍스트가 0이면 Test 실패)
VRT:(Visual Regression Testing): 시각적 회귀 테스트로서 이용됨

목적

의도하지 않은 UI의 변경을 막기
- 의도한건 사진을 재 랜더링해서 Commit
- 의도하지 않은 것은 (저장해둔)화면이 변경되지 않았기 때문에 Test실패
코드의 변경에 따른 UI의 영향을 가시화
- PR의 코드를 실행하지않고 어떤 UI가 변경되었는지 파악 가능

testWidgets('HomePage VRT', (WidgetTester tester) async {
  // 描画
  await tester.pumpWidget(
    MaterialApp(
      theme: ThemeData(fontFamily: 'NotoSans'),
      home: const MyHomePage(title: 'title'),
    ),
  );

  // 確認
  await expectLater(
    find.byType(MyHomePage),
    matchesGoldenFile('goldens/my_home_page.png'),
  );
});

Scroll이 필요한 GoldenTest 흐름

위젯을 그림
Finder에 스크롤하는 위젯의 검색조건을 설정
해당조건을 만족할때까지 스크롤
Golden화면과 확인

Scroll이 필요한 GoldenTest 실패 (1)

Silver(ListView/GridView)에서는 화면이 표시되는 부분만 위젯이 렌더링 되기 때문에, 그려지기 전 까지 Finder에서는 알 수 없음
- 해결법1: Widget이 렌더링 될 때 까지 scrollUntilVisible의 maxScrolls을 늘린다
- 해결법2: Scroll이 불필요한 GoldenTest의 사이즈로 변경한다

Scroll이 필요한 GoldenTest 실패 (2)

scrollUntilVisible에서는 Finder에서 단일로만 사용가능
현재 섹션이 여러개 있기 때문에, セクション으로 찾으려 하면 여러 위젯이 나오기 때문에 에러 발생
- 해결법1: Silver(ListView/GridView)을 이용할 땐 Finder가 단일이 되도록 설정한다
- 해결법2: Type 지정이면 복수개가 될 때 ValueKey등으로 단일이 되도록 설정(ValueKey는 테스트 대상이 되도록 지정)

마무리

GoldenTest를 이용할 때 VRT는 예상하지 못한 UI의 변경을 막아주거나 하는 편리한 기술
scrollUntilVisible에 지정한 스크롤 위치의 GoldenTest가 가능
Silver(ListView/GridView)를 이용한 GoldenTest에서 scrollUntilVisible을 이용할 때는 maxScrolls를 고려해서, Finder는 단일로 되도록 한다

Flutterアプリ運用の現場で役立った監視Tips 5選 (Flutter 어플 운용의 현장에서 도움이 되었던 감시 Tips 5선)

1. 여러 계층의 상태를 만든다(정보 수집의 다양화)

유저의 단말 내 설정(Shared Preference의 내부)
- Shared Preference는 유저에 따라 다르기 때문에 감시 가능한 상태가 바람직함(개인정보 수집 관련해서 조심히 접근하는 것도 중요)
단말의 스펙
- Sentry에는 기본으로 탑재되어있는 정보. 안드로이드는 특별히 단말 스펙이 다양하기 때문에 단말에 따라 일어나거나 일어나지 않는 상황이 다양함. Low 단말에서만 일어나는 문제는 우선도를 올리기/낮추기 등, 판단에 사용한다.

2. Alert 정보를 자세히 조사한다

모바일 어플의 성질상 하위버전의 서포트할 필요가 있고, 바이너리에 따라 발생하는 에러가 다르다. 어떤 플랫폼, 버전에서 일어나는지는 Alert에 필수 정보가 된다.
보통 최신 버전에서 발생하는 에러가 과거 버전에서 발생하는 에러보다 대응우선도가 높을 때가 많다.

3. 버전에 따라 감시하는 체제를 만든다

Alert
- 모바일 어플에 있어서 최신 버전의 어플이 감시의 온도감(심각성)이 높은 대상이며, 특히 단계적 공개(점점 최신 버전을 유저에게 공개하는 방식)로 어플을 공개할 경우 전체 Alert만으로는 degradation(후퇴)를 깨닫는 것이 늦을 수 있다.
  이를 위해 어플 릴리즈시 자동으로 관리하는 Alert를 최신 버전으로 갱신하는 로직을 도입한다.
대시보드
- Alert와 동일한 이유로 버전 단위로 어플의 상태를 알 수 있는 대시보드를 생성.

버전 및 스펙, 플랫폼 등 다양한 정보를 통해 문제 원인 파악 정확도를 높이는 부분이 중요하지 않을까 생각

4. 신규 에러는 AI가 멋대로 조사하는 Flow를 만든다

AI 툴을 사용하는하는 것으로 지금까지 인간이 했던 에러 조사와 대응을 대체.
지금까지 우선도가 높은 문제만 대응 가능했지만, 대응의 범위를 넓힐 수 있음.

5. 감시지표를 단계 릴리즈의 평가에 사용한다

모바일 어플리케이션을 안전하게 릴리즈하는 방법으로서 단계적 공개가 있다.
새로운 바이너리를 이용하는 유저를 단계적으로 넓힘으로서 장애가 있을 때 최소한의 유저 영향으로 끝낼 수 있다.
하지만, 어느 타이밍에 100% 공개할지 판단하는 것이 어렵다.
WinTicket에서는 독자의 평가지표로 일정 샘플이 쌓였을 타이밍에 리포트를 작성.
이것으로 단계 공개중 바이너를 100% 공개해야 하는가 판단 가능.
어떻게 지표와 경계를 정하는게 좋은가? -> "프로덕트에 따라 다르다"
- E-Commerce 사이트에서 '99퍼의 유저가 구입 성공하는 상태'를 정상 상태라고 정상하면, (0.5% 오차 허용 범위에서) 2640건의 구입결과가 있으면 판단 가능하다.
- 모비율 신뢰구간의 오차를 기준으로 표본수 n은 다음식으로 구할 수 있다.
  - Z: 신뢰수준에 대응하는 표준 정규분포의 수 (95% -> 1.96, 99% -> 2.58 등)
  - E: 허용오차 (예: 0.01)
  - p: 성공률(예: 0.99)