Dart on monkshark.dev

#6 - 급식 API, 80줄에서 320줄까지

Fri, 10 Apr 2026 00:00:00 +0000

Java 시절: 80줄짜리 API

Java 프로토타입의 getMealData.java는 80줄이었다. 하는 일은 단순했다:

URL 조립
HTTP 요청
JSON 파싱
문자열 반환

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


public static CompletableFuture<String> getMeal(String date, String mealScCode, String type) {
 String requestURL =
 "https://open.neis.go.kr/hub/mealServiceDietInfo?" +
 "&Type=json" +
 "&MMEAL_SC_CODE=" + mealScCode +
 "&ATPT_OFCDC_SC_CODE=" + niesAPI.ATPT_OFCDC_SC_CODE +
 "&SD_SCHUL_CODE=" + niesAPI.SD_SCHUL_CODE +
 "&MLSV_YMD=" + date;

 return CompletableFuture.supplyAsync(() -> {
 String 메뉴 = itemObject.getString("DDISH_NM");
 String 칼로리 = itemObject.getString("CAL_INFO");
 switch (type) {
 case "메뉴" -> result = 메뉴;
 case "칼로리" -> result = 칼로리;
 }
 return result.replace("<br/>", "\n");
 });
}

호출할 때마다 네트워크 요청을 보냈다. 캐싱? 없다. 오프라인 대응? 없다. 에러 핸들링? try-catch로 빈 문자열 반환이 전부. 그래도 동작했다. 학교 와이파이가 있으니까.

Flutter 초기: Java를 그대로 옮기다

Flutter 첫 커밋(2023-12-07)에서 GetMealData.dart를 만들었을 때도 구조는 같았다. Java의 CompletableFuture가 Dart의 Future로 바뀌었을 뿐, URL을 조립하고, HTTP 요청을 보내고, JSON을 파싱해서 문자열을 돌려주는 것은 동일했다.

하지만 Flutter 버전이 커지기 시작한 건 테스터가 늘면서다.

문제 1: 매번 네트워크 요청

급식 화면을 열 때마다 NEIS API를 호출했다. 조식, 중식, 석식 — 화면 하나를 열면 API 호출 3번. 날짜를 넘기면 3번 더. 체감상 느렸고, NEIS API가 간헐적으로 느려지는 날에는 화면이 몇 초간 빈 채로 있었다.

해결: SharedPreferences 캐시

첫 번째 개선은 SharedPreferences에 API 응답을 캐싱하는 것이었다.

1
2
3
4
5
6
7
8


static String _cacheKey(DateTime date, int mealType) {
 return 'meal_${DateFormat('yyyyMMdd').format(date)}_$mealType';
}

static void _saveToCache(SharedPreferences prefs, String key, Meal meal) {
 prefs.setString(key, jsonEncode(meal.toJson()));
 prefs.setInt('$key-ts', DateTime.now().millisecondsSinceEpoch);
}

캐시 키는 meal_20240415_2 형태 — 날짜와 끼니(1=조식, 2=중식, 3=석식)의 조합이다. 한 번 불러온 급식 데이터는 로컬에 저장되어 다음에 같은 날짜를 볼 때 네트워크 요청 없이 바로 표시된다.

이것만으로도 체감 속도가 크게 좋아졌다. 하지만 문제가 하나 더 있었다.

문제 2: 날짜를 넘길 때마다 로딩

급식 화면에서 스와이프로 날짜를 넘기면, 그날 데이터가 캐시에 없으니 다시 API를 호출한다. 월요일부터 금요일까지 쭉 넘기면 호출이 15번(5일 × 3끼). 사용자 입장에서는 날짜를 넘길 때마다 잠깐 로딩이 보인다.

해결: 월 단위 프리페치

NEIS API는 MLSV_FROM_YMD와 MLSV_TO_YMD 파라미터로 기간 조회를 지원한다. 한 번의 요청으로 한 달 치 급식 데이터를 전부 가져올 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


static Future<void> _prefetchMonth(DateTime date) async {
 final monthKey = DateFormat('yyyyMM').format(date);

 // 같은 달을 중복 요청하지 않도록 guard
 if (_prefetchingMonths.containsKey(monthKey)) {
 await _prefetchingMonths[monthKey];
 return;
 }

 final firstDay = DateTime(date.year, date.month, 1);
 final lastDay = DateTime(date.year, date.month + 1, 0);

 final requestURL = 'https://open.neis.go.kr/hub/mealServiceDietInfo?'
 '&Type=json&pIndex=1&pSize=100'
 '&MLSV_FROM_YMD=$fromDate'
 '&MLSV_TO_YMD=$toDate';

 // 응답의 모든 급식 데이터를 각각 캐시에 저장
 for (var row in rows) {
 final key = _cacheKey(mealDate, mealCode);
 _saveToCache(prefs, key, meal);
 }
}

한 번의 API 호출로 해당 월의 모든 급식(보통 60~90개 항목)을 가져와서 각각 캐시에 저장한다. 이후 같은 달의 어떤 날짜를 보더라도 캐시에서 즉시 표시된다.

_prefetchingMonths Map으로 같은 달의 중복 요청을 방지한다. 급식 화면을 열면서 프리페치를 시작하고, 그 사이에 사용자가 날짜를 넘겨도 같은 달이면 이미 진행 중인 프리페치를 기다린다.

주간 프리페치도 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


static Future<void> prefetchWeek(DateTime baseDate) async {
 final monday = baseDate.subtract(Duration(days: baseDate.weekday - 1));
 final friday = monday.add(const Duration(days: 4));

 if (monday.month == friday.month) {
 await _prefetchMonth(monday);
 } else {
 // 월이 걸치면 두 달 모두 프리페치
 await Future.wait([
 _prefetchMonth(monday),
 _prefetchMonth(friday),
 ]);
 }
}

월~금이 월경계에 걸릴 수 있다. 예를 들어 3월 31일(월)~4월 4일(금)이면 3월과 4월 데이터를 모두 프리페치한다.

문제 3: 캐시가 오래되면?

급식 데이터는 학교 사정으로 바뀔 수 있다. 어제 캐시한 데이터가 오늘도 맞다는 보장이 없다. 그렇다고 캐시를 매번 무시하면 캐싱의 의미가 없다.

해결: SWR 패턴

SWR(Stale-While-Revalidate)은 웹 개발에서 온 패턴이다. 오래된 캐시를 일단 보여주고, 백그라운드에서 새 데이터를 가져온다. 사용자는 즉시 데이터를 보고, 데이터가 바뀌었으면 자동으로 갱신된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


static Future<Meal?> getMeal({...}) async {
 final cached = _getFromCache(prefs, cacheKey);

 if (cached != null && cached.meal != null) {
 if (_isCacheStale(prefs, cacheKey)) {
 // SWR: 만료된 캐시를 즉시 반환하고 백그라운드에서 갱신
 _prefetchMonth(date); // await 하지 않음
 }
 return cached;
 }

 // 캐시 없으면 네트워크 요청
 await _prefetchMonth(date);
 return _getFromCache(prefs, cacheKey);
}

핵심은 _prefetchMonth(date)를 await 하지 않는 것이다. 캐시가 stale이면 일단 오래된 데이터를 반환하고, 프리페치는 백그라운드에서 돌린다. 다음에 화면을 열면 갱신된 데이터가 표시된다.

캐시 만료 정책도 계층적이다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


static Meal? _getFromCache(SharedPreferences prefs, String key) {
 final age = DateTime.now().millisecondsSinceEpoch - ts;

 if (meal.meal == ApiStrings.mealNoData) {
 if (age > 5 * 60 * 1000) return null; // "데이터 없음"은 5분만 캐시
 } else if (age > 24 * 60 * 60 * 1000) {
 if (age > 3 * 24 * 60 * 60 * 1000) return null; // 3일 지나면 완전 만료
 }
 return meal;
}

“데이터 없음” 응답: 5분만 캐시한다. 학교에서 아직 급식을 등록 안 했을 수 있으니 곧 다시 시도
정상 데이터: 24시간까지 fresh, 24시간~3일은 stale(SWR 대상), 3일 이후는 완전 삭제

오프라인 대응

1
2
3
4


if (await NetworkStatus.isUnconnected()) {
 if (cached != null) return cached;
 return Meal(meal: ApiStrings.mealNoInternet, ...);
}

네트워크가 없으면 캐시가 아무리 오래되었어도 반환한다. 오래된 데이터라도 “인터넷 연결 없음"보다는 낫다. 캐시도 없으면 그때 안내 메시지를 보여준다.

Meal 모델의 등장

Java에서는 급식 데이터가 String이었다. “메뉴”, “칼로리”, “영양정보"를 별도 호출로 가져왔다.

Flutter에서는 Meal 모델 하나에 전부 담는다:

1
2
3
4
5
6
7


class Meal {
 final String? meal; // 메뉴
 final String kcal; // 칼로리
 final String ntrInfo; // 영양정보
 final DateTime date; // 날짜
 final int mealType; // 1=조식, 2=중식, 3=석식
}

toJson()/fromJson()이 있어서 캐시 직렬화도 한 줄이다. Java에서 getMeal(date, "1", "메뉴"), getMeal(date, "1", "칼로리")로 따로 호출하던 걸, getMeal(date: date, mealType: 1)로 한 번에 전부 가져온다.

80줄 → 320줄, 뭐가 늘었나

구분	Java (80줄)	Flutter (320줄)
URL 조립	O	O
HTTP 요청	O	O
JSON 파싱	O	O
데이터 모델	X (String)	O (Meal 클래스)
캐시	X	SharedPreferences
월 단위 프리페치	X	O
중복 요청 방지	X	Completer
SWR 갱신	X	O
캐시 만료 정책	X	3단계 (5분/24시간/3일)
오프라인 대응	X	O
테스트 지원	X	@visibleForTesting

코드가 4배 늘었지만, 네트워크 요청은 수십 분의 1로 줄었다. 사용자가 체감하는 로딩 시간은 거의 0이 되었다. 80줄에서 320줄로 가는 과정이 곧 “동작하는 코드"에서 “쓸 만한 앱"으로 가는 과정이었다.

다음 글에서는

앱의 커뮤니티 기능을 뒷받침하는 Firestore 스키마 설계 — 게시판, 채팅, 사용자 관리까지의 구조와 초기 실수들을 다룬다.

#5 - Flutter 첫 한 달

Thu, 09 Apr 2026 00:00:00 +0000

12월 7일, 같은 날의 두 커밋

2023년 12월 7일. Java 레포에 v0.12.3 Beta 마지막 커밋을 남기고, 같은 날 Flutter 레포에 first commit을 찍었다. 하나를 끝내고 바로 다음을 시작한 것이다.

첫 커밋은 flutter create 그 자체였다. 137개 파일, 5,126줄. Flutter가 자동 생성하는 프로젝트 템플릿이다. android, ios, web, linux, macos, windows — 모든 플랫폼의 보일러플레이트가 포함되어 있었다.

하지만 이 커밋에 이미 Java에서 가져온 파일 3개가 들어 있었다:

1
2
3


lib/GetMealData.dart
lib/GetNoticeData.dart
lib/GetTimeTableData.dart

Java의 getMealData.java, getNoticeData.java, getTimetableData.java를 Dart로 포팅한 것이다. 프로젝트를 만들자마자 가장 먼저 한 일이 NEIS API 연동 코드를 옮기는 것이었다.

첫째 주: 뼈대 잡기 (12/7 ~ 12/13)

화면 구조

둘째 커밋(12/8)에서 화면 4개의 껍데기를 만들었다:

1
2
3
4


lib/Screens/homeScreen.dart +28줄
lib/Screens/mainScreen.dart +11줄
lib/Screens/mealScreen.dart +29줄
lib/Screens/noticeScreen.dart +29줄

Java 프로토타입과 동일한 구조다. 홈, 급식, 공지. BottomNavigation으로 전환하는 방식도 같았다. 이미 Java에서 검증한 화면 흐름을 그대로 가져왔다.

파일 구조 리팩토링

셋째 커밋(12/10)에서 바로 파일 구조를 정리했다:

1
2
3


GetMealData.dart → Data/mealDataApi.dart
GetNoticeData.dart → Data/noticeDataApi.dart
GetTimeTableData.dart → Data/tiemtableDataApi.dart

루트에 흩어져 있던 API 파일들을 Data/ 폴더로 모았다. 파일명도 PascalCase에서 camelCase로 바꿨다. Java 습관을 Dart 컨벤션으로 전환하는 과정이었다. (참고로 tiemtable은 오타다. 나중에 timetable로 고쳤다.)

알림 첫 시도 (12/12 ~ 12/13)

Flutter 시작 5일 만에 알림 기능에 손을 댔다. #3에서 자세히 다뤘지만, NotificationManager.dart 165줄을 만들고, FirebaseCloudMessaging.dart를 넣었다 4시간 만에 삭제하는 사건이 이때 일어났다.

돌이켜보면 너무 일찍 손을 댄 것이었다. 화면 구조도 다 안 잡힌 상태에서 알림까지 만들려고 했으니.

둘째 주: 기능 구현 (12/15 ~ 12/20)

12월 17일에 커밋이 9개다. 하루에 9번. 이 시기가 가장 집중적으로 개발한 때였다.

이 주에 만든 것들:

급식 화면 — NEIS API 연동, 조식/중식/석식 표시, 날짜 이동
시간표 화면 — 학년/반 선택, 요일별 시간표 표시
설정 화면 — 학년/반 저장, 알림 on/off
로그인/회원가입 — Firebase Auth 연동
달력 — 학사일정 표시

12월 20일에는 커밋이 7개. 이 이틀(17일, 20일)에 전체 첫 달 커밋의 거의 절반이 몰려 있다. 기숙사에서 자습 시간과 주말을 전부 개발에 쏟은 날들이다.

셋째 주: API 안정화 (12/20 ~ 12/27)

12월 25일, 크리스마스에도 코딩했다. 이날 커밋은 API 3개를 전부 리팩토링한 것이다:

1
2
3


lib/API/MealDataApi.dart +72줄, -65줄
lib/API/NoticeDataApi.dart +54줄, -38줄
lib/API/TimetableDataApi.dart +38줄, -27줄

Java에서 포팅한 초기 코드가 Dart답지 않았다. HttpURLConnection 스타일로 작성했던 걸 http 패키지의 get() 방식으로 바꾸고, 에러 핸들링을 추가하고, JSON 파싱을 정리했다.

12월 27일에는 파일명을 Dart 컨벤션(snake_case)으로 전환했다:

1
2
3


MealDataApi.dart → meal_data_api.dart
NoticeDataApi.dart → notice_data_api.dart
TimetableDataApi.dart → timetable_data_api.dart

Java의 PascalCase → Dart의 snake_case. 이런 사소한 컨벤션 전환이 프로젝트 초기에 계속 있었다.

넷째 주: Meal 모델 (1/7)

1월 7일 커밋에서 Meal 데이터 모델이 처음 등장한다:

1

lib/Data/meal.dart +13줄

그 전까지는 급식 데이터를 String으로만 다뤘다. Java 시절과 똑같이 API 응답을 문자열로 받아서 화면에 바로 뿌렸다. 하지만 급식 정보에는 메뉴, 칼로리, 영양정보, 날짜, 끼니 구분 등 여러 필드가 있고, 이걸 하나의 모델 클래스로 묶어야 코드가 정리된다.

Meal 모델을 만들면서 동시에 meal_card.dart가 95줄이나 추가되었다. 급식 카드 위젯이 별도 파일로 분리된 것이다. Java에서는 MealFragment 하나에 271줄이 전부 들어 있었는데, Flutter에서는 위젯 단위로 분리하기 시작했다.

첫 달의 숫자

항목	수치
기간	2023-12-07 ~ 2024-01-07
커밋 수	36
가장 많은 날	12/17 (9커밋), 12/20 (7커밋)
커밋 0개인 날	12/9, 12/11, 12/14, 12/16, 12/21~24, 12/26, 12/28~1/6

커밋이 없는 날이 꽤 많다. 매일 코딩한 게 아니라, 할 수 있는 날에 몰아서 했다. 기숙사 생활이라 평일 저녁 자습 시간과 주말이 개발 시간이었고, 시험이나 학교 일정이 있으면 며칠씩 손을 못 대기도 했다. (근데 사실 공부는 안했다.)

돌아보면

첫 한 달의 핵심은 Java에서 검증한 구조를 Dart로 옮기는 것이었다. 화면 구조, API 파싱, 데이터 흐름 — 전부 Java에서 한 번 해봤던 것들이다. 덕분에 “무엇을 만들어야 하는지"는 고민하지 않았고, “Flutter에서는 이걸 어떻게 만드는지"에만 집중할 수 있었다.

동시에 Java 습관을 하나씩 버리는 과정이기도 했다. 파일 이름, 폴더 구조, 코딩 컨벤션을 Dart 방식으로 바꿔가면서, 코드가 점점 “Flutter다워"졌다. 이 전환은 첫 달에 끝나지 않고 이후 몇 달간 계속되었다.

다음 글에서는

첫 달에 포팅한 NEIS API 급식 파싱이 이후 어떻게 진화했는지 — 캐싱, 월 단위 프리페치, SWR 패턴까지의 과정을 다룬다.

#4 - Java 코드에서 가져온 것, 버린 것

Wed, 08 Apr 2026 00:00:00 +0000

159커밋의 유산

#2에서 Java 프로토타입 159커밋을 버리고 Flutter로 전환한 이야기를 했다. 코드는 버렸지만, 모든 걸 버린 건 아니었다. Java에서 삽질하며 만든 설계와 경험은 그대로 가져갔고, 동시에 초보 시절의 나쁜 습관은 버렸다.

Java 프로토타입의 실제 코드를 보면서, 뭘 가져가고 뭘 버렸는지 정리해본다.

가져간 것: NEIS API 파싱 구조

Java — `getMealData.java`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


public static CompletableFuture<String> getMeal(String date, String mealScCode, String type) {
 String requestURL =
 "https://open.neis.go.kr/hub/mealServiceDietInfo?" +
 "&Type=json" +
 "&MMEAL_SC_CODE=" + mealScCode +
 "&ATPT_OFCDC_SC_CODE=" + niesAPI.ATPT_OFCDC_SC_CODE +
 "&SD_SCHUL_CODE=" + niesAPI.SD_SCHUL_CODE +
 "&MLSV_YMD=" + date;

 return CompletableFuture.supplyAsync(() -> {
 // HTTP 연결, JSON 파싱...
 String 메뉴 = itemObject.getString("DDISH_NM");
 String 칼로리 = itemObject.getString("CAL_INFO");
 String 영양정보 = itemObject.getString("NTR_INFO");

 switch (type) {
 case "메뉴" -> result = 메뉴;
 case "칼로리" -> result = 칼로리;
 case "영양정보" -> result = 영양정보;
 }
 return result.replace("<br/>", "\n");
 });
}

Flutter — `MealDataApi`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


static Future<Meal> _fetchSingleMeal(...) async {
 final requestURL = 'https://open.neis.go.kr/hub/mealServiceDietInfo?'
 'key=${niesApiKeys.NIES_API_KEY}'
 '&Type=json&MMEAL_SC_CODE=$mealType'
 '&ATPT_OFCDC_SC_CODE=${niesApiKeys.ATPT_OFCDC_SC_CODE}'
 '&SD_SCHUL_CODE=${niesApiKeys.SD_SCHUL_CODE}'
 '&MLSV_YMD=$formattedDate';

 // ...
 final meal = Meal(
 meal: (row['DDISH_NM'] as String).replaceAll('<br/>', '\n'),
 kcal: row['CAL_INFO'] as String,
 ntrInfo: (row['NTR_INFO'] as String?)?.replaceAll('<br/>', '\n') ?? '',
 );
}

URL 구조가 거의 동일하다. ATPT_OFCDC_SC_CODE, SD_SCHUL_CODE, MMEAL_SC_CODE — NEIS API의 파라미터 이름은 바뀌지 않으니까. Java에서 이미 API 문서를 파고들어서 필요한 파라미터를 정리해뒀기 때문에, Flutter에서는 URL을 그대로 가져다 쓸 수 있었다.

<br/> → \n 변환도 그대로다. NEIS API는 메뉴 항목을 <br/> 태그로 구분해서 보내주는데, 이걸 줄바꿈으로 바꿔야 화면에 제대로 표시된다. Java에서 이미 알아낸 사실이라 Dart에서는 고민 없이 처리했다.

JSON 응답 구조도 동일하다. mealServiceDietInfo → row 배열 → 각 항목에서 DDISH_NM, CAL_INFO, NTR_INFO 추출. 이 구조를 파악하는 데 Java 시절에 꽤 시간을 썼는데, 한 번 알면 두 번 다시 삽질할 필요가 없다.

가져간 것: 알러지 괄호 제거

Java — `HomeFragment.java`

1
2
3
4


private String deleteBracket(String msg) {
 msg = msg.replaceAll("[().1234567890]", "");
 return msg;
}

Flutter — `DailyMealNotification`

1
2
3
4
5
6
7
8


String _cleanMenu(String? menu) {
 if (menu == null || menu.isEmpty) return '';
 return menu
 .split('\n')
 .map((e) => e.replaceAll(RegExp(r'\([0-9.,\s]+\)'), '').trim())
 .where((e) => e.isNotEmpty)
 .join(' · ');
}

같은 목적, 다른 구현. NEIS API의 급식 메뉴에는 비빔밥(5.6.13) 형태로 알러지 정보가 붙어 있다. 사용자에게 보여줄 때는 이 괄호를 제거해야 한다.

Java 버전은 단순했다. 괄호, 점, 숫자를 전부 지워버리는 방식. 하지만 이러면 메뉴 이름에 포함된 숫자까지 날아갈 수 있다. Flutter 버전에서는 정규식을 \([0-9.,\s]+\) — 괄호 안에 숫자/점/쉼표/공백만 있는 패턴으로 좁혀서, 알러지 정보만 정확히 제거하도록 개선했다.

Java에서 “알러지 괄호를 제거해야 한다"는 문제 자체를 발견한 것이 가장 큰 유산이었다. 해결 방법은 더 나은 걸로 바꿨지만, 문제를 아는 것과 모르는 것의 차이는 크다.

가져간 것: 급식 알림의 기본 구조

Java — `FirebaseMessaging.java`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public void setAlarms(@NonNull Context context) {
 AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

 Calendar currentCalendar = Calendar.getInstance();
 int dayOfWeek = currentCalendar.get(Calendar.DAY_OF_WEEK);
 if (dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY) return;

 PendingIntent pendingIntent1 = createPendingIntent(context, 1, "조식", 6, 30);
 PendingIntent pendingIntent2 = createPendingIntent(context, 2, "중식", 12, 0);
 PendingIntent pendingIntent3 = createPendingIntent(context, 3, "석식", 17, 0);

 alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, calendar1.getTimeInMillis(), pendingIntent1);
}

Java — `AlarmReceiver.java`

1
2
3
4
5
6


public void onReceive(Context context, Intent intent) {
 String 분류 = intent.getStringExtra("분류");
 final String[] 메뉴 = new String[1];
 메뉴[0] = getMenu(분류, spDate).join();
 NotificationUtil.sendMealNotification(context, 분류 + " 정보", 메뉴[0]);
}

여기가 아이러니한 부분이다. #3에서 Flutter로 급식 알림을 만드는 데 1년이 걸렸다고 했는데, Java 프로토타입에는 이미 동작하는 급식 알림이 있었다.

AlarmManager + setExactAndAllowWhileIdle + BroadcastReceiver — Android 네이티브 API를 직접 쓰는 방식이었다. 알림이 울리면 AlarmReceiver가 NEIS API를 호출해서 실제 메뉴를 가져오고, NotificationUtil이 BigTextStyle로 보여준다. 주말은 건너뛴다.

Flutter에서 이 기능을 다시 만들 때, 처음에는 flutter_local_notifications로 시작했다가 안정성 문제로 Kotlin 네이티브(MealNotificationReceiver.kt + MealWorker.kt)로 갔다가, 결국 다시 Flutter로 돌아왔다. 1년간의 삽질 끝에 도달한 exactAllowWhileIdle — 이건 Java의 setExactAndAllowWhileIdle과 같은 Android API를 Flutter 래퍼로 호출하는 것이다.

돌고 돌아 원점이었다. 다만 Java 시절에는 “이게 왜 동작하는지” 이해하지 못한 채 코드를 썼고, Flutter에서 삽질한 후에야 AlarmManager의 exact alarm이 Doze 모드에서도 동작하는 이유를 이해하게 되었다.

버린 것: 한글 변수명

Java 프로토타입에서 가장 눈에 띄는 특징은 한글 변수명이다.

1
2
3
4
5
6
7


String 메뉴 = itemObject.getString("DDISH_NM");
String 칼로리 = itemObject.getString("CAL_INFO");
String 영양정보 = itemObject.getString("NTR_INFO");

// AlarmReceiver.java
String 분류 = intent.getStringExtra("분류");
final String[] 메뉴 = new String[1];

Java는 유니코드 식별자를 허용하기 때문에 기술적으로 문제는 없다. 그리고 솔직히 코드를 읽을 때 String meal보다 String 메뉴가 직관적이긴 하다.

하지만 Flutter로 전환하면서 전부 영어로 바꿨다. 이유:

라이브러리/프레임워크와의 일관성 — Flutter의 모든 API가 영어다. 내 코드만 한글이면 섞여서 읽기 어렵다
자동완성 — IDE에서 me까지 치면 meal, mealType 같은 후보가 뜨는데, 한글이면 ㅁ을 치고 한영 전환을 해야 한다
협업 가능성 — 혼자 만드는 앱이지만, 코드를 GitHub에 올리는 이상 영어가 맞다

버린 것: 커밋 메시지 “Update”

Java 레포의 159커밋 중 대부분의 메시지가 이렇다:

1
2
3
4
5
6


Update
Update
Update
Update
Merge remote-tracking branch 'origin/main'
Update

9월 12일 하루에 커밋이 20개가 넘는데, 전부 “Update”. 뭘 바꿨는지 메시지만 봐서는 전혀 알 수 없다. Git을 처음 쓰면서 “저장” 버튼처럼 사용했던 것 같다.

Flutter 레포로 넘어오면서 커밋 메시지에 변경 내용을 적기 시작했다. 처음에는 “Migration"이 많았지만, 점차 구체적으로 바뀌어 갔다.

버린 것: `static` 남용

1
2
3
4
5
6
7
8


// getMealData.java
static String result = null;

public static CompletableFuture<String> getMeal(...) {
 // result에 직접 대입
 result = 메뉴;
 return result.replace("<br/>", "\n");
}

static 필드에 결과를 직접 대입하는 방식. 여러 곳에서 동시에 getMeal을 호출하면 result가 덮어씌워질 수 있다. 실제로 HomeFragment에서 급식과 시간표를 동시에 비동기 호출하고 있었는데, 운 좋게 문제가 안 터졌을 뿐이다.

Flutter 버전에서는 각 함수가 독립적인 반환값을 가지고, 상태를 공유하지 않는다.

버린 것: 배터리 최적화 해제 강제 요청

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// HomeFragment.java
private void checkBatteryOptimization(Context context) {
 PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
 if (!pm.isIgnoringBatteryOptimizations(packageName)) {
 Intent intent = new Intent();
 intent.setAction(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
 intent.setData(Uri.parse("package:" + packageName));
 context.startActivity(intent);
 }
}

앱을 열 때마다 배터리 최적화 해제를 요청하는 코드. 알림이 안정적으로 오게 하려는 의도였지만, 사용자 경험이 최악이다. 앱을 열 때마다 시스템 팝업이 뜬다. Google Play 정책에서도 이런 방식은 권장하지 않는다.

Flutter 버전에서는 이런 강제 요청 대신, exactAllowWhileIdle 모드로 시스템의 정상적인 알림 경로를 사용한다.

돌아보면

Java 프로토타입은 “이것도 되나? 저것도 되나?” 하면서 마구 시도한 코드였다. 정리되지 않았고, 위험한 패턴도 있었다. 하지만 그 덕분에:

NEIS API의 구조를 완전히 파악했다
급식, 시간표, 알림의 핵심 로직을 한 번 구현해봤다
뭘 하면 안 되는지(한글 변수명, static 남용, 강제 권한 요청)를 경험으로 배웠다

코드는 버렸지만 경험은 전부 가져갔다. Flutter 프로젝트의 첫 커밋이 Java 마지막 커밋과 같은 날(2023년 12월 7일)인 건, 하나를 끝내고 바로 다음을 시작할 수 있을 만큼 준비가 되어 있었다는 뜻이다.

다음 글에서는

Flutter 첫 커밋부터 한 달간 무엇을 만들었는지, 초기 개발의 속도와 순서를 다룬다.

Dart on monkshark.dev

#6 - 급식 API, 80줄에서 320줄까지

Java 시절: 80줄짜리 API

Flutter 초기: Java를 그대로 옮기다

문제 1: 매번 네트워크 요청

해결: SharedPreferences 캐시

문제 2: 날짜를 넘길 때마다 로딩

해결: 월 단위 프리페치

문제 3: 캐시가 오래되면?

해결: SWR 패턴

오프라인 대응

Meal 모델의 등장

80줄 → 320줄, 뭐가 늘었나

다음 글에서는

#5 - Flutter 첫 한 달

12월 7일, 같은 날의 두 커밋

첫째 주: 뼈대 잡기 (12/7 ~ 12/13)

화면 구조

파일 구조 리팩토링

알림 첫 시도 (12/12 ~ 12/13)

둘째 주: 기능 구현 (12/15 ~ 12/20)

셋째 주: API 안정화 (12/20 ~ 12/27)

넷째 주: Meal 모델 (1/7)

첫 달의 숫자

돌아보면

다음 글에서는

#4 - Java 코드에서 가져온 것, 버린 것

159커밋의 유산

가져간 것: NEIS API 파싱 구조

Java — getMealData.java

Flutter — MealDataApi

가져간 것: 알러지 괄호 제거

Java — HomeFragment.java

Flutter — DailyMealNotification

가져간 것: 급식 알림의 기본 구조

Java — FirebaseMessaging.java

Java — AlarmReceiver.java

버린 것: 한글 변수명

버린 것: 커밋 메시지 “Update”

버린 것: static 남용

버린 것: 배터리 최적화 해제 강제 요청

돌아보면

다음 글에서는

Java — `getMealData.java`

Flutter — `MealDataApi`

Java — `HomeFragment.java`

Flutter — `DailyMealNotification`

Java — `FirebaseMessaging.java`

Java — `AlarmReceiver.java`

버린 것: `static` 남용