삽질 on monkshark.dev

#11 - 작업이 전부 날아갔다

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

날아갔다

2026년 4월 3일. 전날부터 UI 전면 개편 작업을 하고 있었다. 앱의 거의 모든 화면을 건드리는 큰 작업이었다. 게시판 레이아웃을 바꾸고, 채팅에 읽음 표시를 넣고, 개인정보 동의 화면을 만들고, 교사용 시간표를 추가하고, Cloud Functions로 푸시 알림을 연결하고 — 한 마디로 앱 전체를 뜯어고치는 중이었다.

그리고 한순간에 전부 사라졌다.

배경: OneDrive 폴더

프로젝트 폴더가 OneDrive 동기화 경로 안에 있었다. 처음부터 의도한 건 아니고, 바탕화면이 OneDrive에 연결되어 있었는데 거기서 프로젝트를 만든 거다.

평소에는 별 문제가 없었다. 파일을 수정하면 OneDrive가 알아서 클라우드에 올리고, 혹시 모를 상황에 백업도 되니까 오히려 편하다고 생각했다. 실제로 한동안 아무 탈 없이 잘 돌아갔다.

문제는 이 구조가 Flutter 프로젝트와 근본적으로 맞지 않는다는 점이다. build/, .dart_tool/, node_modules/ 같은 폴더는 빌드할 때마다 수천 개의 파일을 생성하고 삭제한다. OneDrive는 이 파일들을 전부 동기화하려고 한다. 파일 잠금이 걸리고, 동기화 충돌이 나고, 결국 빌드 자체가 안 되는 상황이 온다.

터진 순간

빌드가 안 됐다. 정확한 에러는 기억 안 나지만, 캐시나 빌드 파일이 꼬인 전형적인 증상이었다. flutter clean을 해야 하는 상황.

그런데 OneDrive 동기화가 걸려 있으면 clean이 제대로 안 된다. 파일을 지워도 OneDrive가 클라우드에서 다시 복원하거나, 동기화 중인 파일이라 삭제가 안 되거나, 잠금이 걸려서 빌드 디렉토리를 못 지운다.

그래서 OneDrive 백업 설정을 껐다. “이 폴더 동기화 중지.” 이러면 깔끔하게 clean build를 할 수 있을 거라고 생각했다.

OneDrive는 동기화를 중지하면서 로컬 파일을 클라우드에 마지막으로 저장된 상태로 되돌렸다. 마지막 커밋 시점. 커밋하지 않은 모든 변경사항 — UI 전면 개편의 모든 작업이 증발했다.

터미널에서 git status를 쳤을 때 nothing to commit, working tree clean이 뜬 그 순간의 기분은 설명하기 어렵다. 분명 수십 개 파일을 수정했는데, clean이라니.

날아간 것들

커밋 메시지에 남긴 복구 목록이다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Restored (lost from git reset --hard):
- Category chips Wrap, post action sheet, bookmark, chat icon
- Chat: leave, message delete, read receipts, system messages, limit(30)
- Privacy consent checkbox, privacy policy in-app screen
- Home refresh (WidgetsBindingObserver, RefreshIndicator), board→recent order
- Crashlytics + crash log to Firestore
- Onboarding→login flow, HomeScreen tab refresh
- My activity 3 tabs (posts/comments/bookmarks)
- Teacher timetable, today highlight, font 12px
- Cloud Functions: chat push, reply notifications
- Firestore rules: crash_logs, field-level post update

실제로는 git reset --hard를 한 게 아니라 OneDrive가 파일을 되돌린 건데, 효과는 같았기에 커밋 메시지에 그렇게 적었다. 핵심은 커밋하지 않은 작업이 전부 사라졌다는 것이다.

하나씩 보면:

채팅 시스템 대규모 개선. 읽음 표시, 메시지 삭제, 나가기 기능, 시스템 메시지, 메시지 30개 제한. 채팅 화면만 344줄이 바뀌었다. 이건 단순 UI가 아니라 Firestore 쿼리, Cloud Functions, 클라이언트 로직이 엮인 기능이다.

개인정보 처리방침. 회원가입 시 동의 체크박스, 인앱 개인정보처리방침 화면. 법적으로 필요한 기능이라 빠뜨릴 수 없었다.

내 활동 3탭. 내 글, 내 댓글, 북마크를 탭으로 나눠 보여주는 화면. 각 탭이 별도 Firestore 쿼리를 가지고 있었다.

교사 시간표. 일반 학생 시간표와 구조가 다르다. 교사는 여러 학급에서 수업하니까 학년/반 선택이 필요하고, 멀티 클래스 선택을 지원해야 했다.

Cloud Functions. 채팅 푸시 알림, 댓글 답글 알림. 클라이언트가 아니라 서버 사이드 코드라 별도로 테스트하고 배포한 거였다.

전부 커밋 전이었다. Git에 흔적이 없다.

복구: 6시간

같은 날 오전 6시 반에 복구 작업을 시작해서, 12:26에 복구 커밋을 찍었다.

1

18 files changed, 1,432 insertions(+), 314 deletions(-)

6시간 만에 18개 파일, 1,432줄을 다시 쳤다. 거기에 원래 계획에 없던 피드백 시스템(버그 신고 + 학생회 건의함)까지 새로 추가했다.

한 번 만들어본 코드를 다시 치는 건 확실히 빠르다. “이 화면에 이 위젯이 필요하고, 이 Firestore 쿼리를 써야 하고, 이 Cloud Function이 이 트리거로 동작한다” — 설계를 처음부터 고민할 필요가 없으니까. 머릿속에 완성된 그림이 있고, 타이핑만 하면 된다.

하지만 원본과 같은 코드는 아니다. 처음 만들 때는 시행착오를 거친다. 이 변수명이 맞나, 이 조건 분기가 맞나, 이 에러 핸들링은 충분한가 — 그 과정에서 다듬어진 디테일들이 있다. 복구할 때는 “대충 이랬다"로 넘어간다. 복구한 코드는 기능은 같지만, 처음 코드가 가졌던 미세한 개선들은 빠져 있다.

그래도 전부 잃는 것보단 훨씬 낫다.

이후 바꾼 것들

프로젝트 폴더 이동

OneDrive 동기화 경로 밖으로 프로젝트를 옮겼다. C:\Users\Desktop\ 아래에 두되, OneDrive 동기화 대상에서 제외했다. 백업은 Git이 하면 된다. 클라우드 동기화 서비스는 코드 저장소가 아니다.

커밋 습관

“큰 작업 끝나면 한 번에 커밋하자” → “작은 단위로 자주 커밋하자"로 바꿨다.

이전에는 여러 기능을 한꺼번에 만들고 한 커밋에 몰아넣었다. 커밋 메시지에 “Major update: board, notifications, admin web, UI overhaul” 같은 게 나오는 이유다. 깔끔한 커밋 히스토리보다 작업 흐름을 끊지 않는 게 더 중요하다고 생각했다.

사건 이후에는 기능 하나가 완성되면 바로 커밋한다. 완벽하지 않아도. 커밋 메시지가 좀 지저분해져도. 커밋하지 않은 코드는 존재하지 않는 코드다.

.gitignore

OneDrive와 무관하게, .gitignore를 꼼꼼하게 관리하기 시작했다. build/, .dart_tool/, node_modules/ 같은 폴더가 동기화되거나 추적되지 않도록. 이건 OneDrive 사건과 직접 관련은 없지만, 빌드 아티팩트가 소스 코드와 섞이면 안 된다는 걸 체감한 뒤로 더 신경 쓰게 됐다.

돌이켜보면

클라우드 동기화 폴더에서 개발하는 건 시한폭탄이다. OneDrive, Dropbox, iCloud Drive — 전부 마찬가지다. 이 서비스들은 문서, 사진, 일반 파일을 동기화하도록 설계되었지, 수천 개의 임시 파일을 초 단위로 생성하고 삭제하는 개발 프로젝트를 위한 게 아니다.

Git은 이미 완벽한 분산 백업 시스템이다. git push만 해도 코드는 원격 저장소에 안전하게 보관된다. 그 위에 OneDrive까지 겹치면 동기화 충돌, 파일 잠금, 빌드 실패가 생기고, 최악의 경우 이 글처럼 작업이 통째로 날아간다.

개발 폴더는 동기화 범위 밖에 둬라. 백업은 Git에 맡겨라. 그리고 커밋은 자주 해라.

#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 첫 커밋부터 한 달간 무엇을 만들었는지, 초기 개발의 속도와 순서를 다룬다.

#3 - 급식 알림의 삽질기

Tue, 07 Apr 2026 00:00:00 +0000

단순해 보였던 기능

“매일 아침에 오늘 급식 메뉴를 알림으로 보내준다.”

한 줄로 설명 가능한 기능이다. 사용자 입장에서는 당연히 있어야 할 것 같고, 구현도 간단해 보인다. 알림 예약하고, 시간 되면 보내면 되는 거 아닌가?

이 “간단한” 기능을 제대로 동작하게 만드는 데 1년이 걸렸다. 2023년 12월부터 2024년 12월까지, 접근 방식을 네 번 바꾸고, 파일을 만들었다 지우기를 반복하고, 결국 처음과 전혀 다른 구조로 끝났다.

1차 시도: NotificationManager (2023년 12월)

Flutter로 전환한 직후, 가장 먼저 만들고 싶었던 기능이 급식 알림이었다. Java 프로토타입에서도 알림 기능이 있었으니까, Flutter에서도 금방 만들 수 있을 거라고 생각했다.

NotificationManager.dart를 만들었다. 165줄. flutter_local_notifications 패키지를 사용해서 로컬 알림을 예약하는 구조였다.

1
2


// 2023-12-12, 첫 번째 시도
// NotificationManager.dart — 165줄

같은 커밋에서 FirebaseCloudMessaging.dart라는 빈 파일도 만들었다. 이름에서 알 수 있듯이, FCM(Firebase Cloud Messaging)으로 서버에서 푸시를 보내는 것도 고려하고 있었다.

2차 시도: FCM을 넣었다 뺐다 (같은 주)

다음 날, FirebaseCloudMessaging.dart에 60줄의 코드를 채워 넣었다. FCM 토큰을 받고, 메시지를 수신하는 기본 구조를 작성했다. 동시에 NotificationManager.dart도 대폭 수정했다. 90줄 분량의 변경.

그리고 같은 날 밤, FCM 코드 60줄을 통째로 삭제했다.

1
2


2023-12-13 20:05 FirebaseCloudMessaging.dart +60줄
2023-12-13 23:53 FirebaseCloudMessaging.dart -60줄

4시간 만에 되돌린 것이다. 이유는 단순했다. 급식 알림은 서버가 보내는 게 아니라 기기가 스스로 보내야 하는 알림이었다. FCM은 서버에서 클라이언트로 푸시를 보내는 도구인데, 매일 아침 급식 메뉴를 보내려면 서버 측에서 스케줄러를 돌려야 한다. Firebase Functions를 쓰면 가능하지만, 당시에는 무료 플랜(Spark)을 쓰고 있었고, Functions 배포가 불가능했다.

그래서 방향을 틀었다. ScheduledNotification.dart를 새로 만들고, 기기 로컬에서 알림을 예약하는 방식으로 갔다.

이때까지만 해도 “방향만 잡으면 금방 끝나겠지"라고 생각했다.

7개월의 공백, 그리고 다시 시작 (2024년 7월)

급식 알림은 한동안 손을 대지 못했다. 게시판, 채팅, 로그인 같은 핵심 기능들이 우선이었고, 알림은 “나중에 제대로 하자” 목록에 들어갔다.

2024년 7월, 다시 notification_manager.dart를 열었다. 150줄 이상을 수정하는 대규모 리팩토링이었다. 7개월 전에 작성한 코드를 다시 보니, 당시에는 이해가 부족해서 엉성하게 작성한 부분이 많았다. 알림 채널 설정, 권한 요청, 스케줄링 로직을 전부 다시 썼다.

하지만 근본적인 문제가 남아 있었다. 앱이 꺼져 있을 때 알림이 안 왔다.

flutter_local_notifications의 zonedSchedule은 앱이 살아 있거나 백그라운드에 있을 때는 잘 동작한다. 하지만 사용자가 앱을 강제 종료하거나, 시스템이 메모리 부족으로 앱을 죽이면? 예약된 알림도 같이 사라진다. 특히 Android 제조사(삼성, 샤오미 등)의 배터리 최적화가 공격적으로 백그라운드 프로세스를 죽이는 환경에서, Flutter 앱의 로컬 알림은 불안정했다.

매일 아침 급식 알림이 가끔 오고 가끔 안 온다. 이건 없느니만 못한 기능이었다.

3차 시도: Kotlin 네이티브로 (2024년 8월)

“Flutter 레벨에서는 한계가 있다. 네이티브로 내려가자.”

2024년 8월 1일, 결정을 내렸다. Android의 네이티브 알림 시스템을 직접 사용하기로 했다. 하루 만에 세 개의 파일을 새로 만들었다:

MealNotificationReceiver.kt (78줄) — BroadcastReceiver를 상속. AlarmManager에서 트리거되면 실제 알림을 생성하는 역할
MealWorker.kt (61줄) — Worker를 상속. WorkManager에 등록되어, 시스템이 적절한 시점에 급식 데이터를 가져오고 알림을 예약
MainActivity.kt — Flutter와 네이티브 코드를 연결하는 MethodChannel 설정 (+61줄)

동시에 notification_manager.dart에서 160줄을 삭제했다. Flutter 측의 알림 로직을 대부분 걷어내고, Kotlin 네이티브에 위임하는 구조로 바꾼 것이다.

1
2
3
4
5


2024-08-01 커밋 stat:
 MealNotificationReceiver.kt +78줄 (신규)
 MealWorker.kt +61줄 (신규)
 MainActivity.kt +61줄
 notification_manager.dart -160줄

이 접근의 핵심 아이디어는 이랬다:

WorkManager가 시스템 수준에서 작업을 스케줄링한다. 앱이 죽어도 시스템이 살려서 실행한다
MealWorker가 NEIS API를 호출해서 급식 데이터를 가져온다
MealNotificationReceiver가 실제 알림을 사용자에게 보여준다

Android의 WorkManager는 앱이 종료되어도 시스템이 보장하는 백그라운드 작업이다. 이론적으로는 완벽한 해법이었다.

그런데 문제가 또 터졌다

이후 일주일간의 커밋 기록을 보면 상황이 얼마나 힘들었는지 알 수 있다:

1
2
3
4


2024-08-04 Migration (MealWorker, Receiver 수정)
2024-08-06 Migration (notification_manager +105줄)
2024-08-07 Migration (Kotlin + notification_manager 동시 수정)
2024-08-07 commit (같은 날 또 수정)

일주일 동안 거의 매일 커밋이 있었고, 같은 날 두 번 커밋한 날도 있었다. 네이티브 코드와 Flutter 코드를 동시에 수정하고 있다는 건, 둘 사이의 통신이 제대로 안 된다는 뜻이었다.

문제들:

MethodChannel 통신 불안정 — Flutter에서 Kotlin으로, Kotlin에서 Flutter로 데이터를 주고받는 과정에서 타이밍 이슈가 발생. 앱이 cold start 상태일 때 채널이 준비되기 전에 호출이 가는 경우가 있었다
NEIS API를 Kotlin에서 직접 호출해야 하는 문제 — Flutter 쪽에 이미 잘 동작하는 MealDataApi가 있는데, 같은 로직을 Kotlin으로 다시 작성해야 했다. 코드 중복에 버그 가능성까지 두 배
iOS는? — Kotlin으로 네이티브를 작성하면 iOS에서는 별도로 Swift 코드를 작성해야 한다. AppDelegate.swift도 78줄이 추가되었지만, 플랫폼별로 다른 코드를 유지보수하는 건 크로스플랫폼의 이점을 스스로 버리는 것이었다

8월 27일, MealNotificationReceiver.kt에서 줄을 빼기 시작했다. 동시에 Flutter 쪽에 meal_notification_worker.dart(33줄)를 새로 만들었다. 네이티브에서 다시 Flutter로 로직을 옮기기 시작한 것이다.

Kotlin 포기 (2024년 9월)

2024년 9월 25일의 커밋이 결정적이었다:

1
2
3
4


MealNotificationReceiver.kt -65줄 (삭제)
MealWorker.kt -63줄 (삭제)
notification_manager.dart +215줄
meal_notification_worker.dart 수정

Kotlin 네이티브 파일 두 개를 완전히 삭제했다. 2개월 전에 “이게 정답이다"라고 확신하며 작성한 코드를 통째로 버렸다. 동시에 notification_manager.dart에 215줄을 추가하며, 알림 로직을 전부 Flutter로 되돌렸다.

Java 프로토타입 159커밋을 버릴 때도 그랬지만, 코드를 버리는 건 매번 아프다. 특히 이번에는 “Flutter로는 안 되니까 네이티브로 가야 한다"는 나름의 기술적 판단을 했던 것이라 더 그랬다. 그 판단이 틀렸다는 걸 인정하는 것이기도 했으니까.

하지만 돌아보면 틀린 게 아니라 맞는 방향을 찾아가는 과정이었다. 네이티브로 내려가봤기 때문에 네이티브의 한계와 복잡성을 직접 체감했고, “Flutter 안에서 해결하되, 더 똑똑하게 하자"라는 결론에 도달할 수 있었다.

구조 전환: DailyMealNotification (2024년 12월)

2024년 12월 2일, 대규모 구조 전환을 했다.

1
2
3
4
5
6


notification_manager.dart -253줄 (삭제)
meal_notification_worker.dart -33줄 (삭제)
daily_meal_notification.dart +259줄 (신규)
daily_alarm_notification.dart +82줄 (신규)
MainActivity.kt -155줄
AppDelegate.swift -92줄

기존의 notification_manager.dart(253줄)를 삭제하고, daily_meal_notification.dart(259줄)를 새로 만들었다. 동시에 MainActivity.kt에서 155줄, AppDelegate.swift에서 92줄을 제거했다. 네이티브 쪽의 알림 관련 코드를 전부 걷어낸 것이다.

`matchDateTimeComponents`의 발견

이 구조 전환에서 가장 결정적이었던 건 flutter_local_notifications의 이 옵션이다:

1
2
3
4


await _localNotificationsPlugin.zonedSchedule(
 ...
 matchDateTimeComponents: DateTimeComponents.dayOfWeekAndTime,
);

dayOfWeekAndTime으로 설정하면, 매주 같은 요일 같은 시간에 반복되는 알림을 시스템이 직접 관리한다. 앱이 살아 있든 죽어 있든, 시스템 알람 스케줄러가 처리하기 때문에 안정적이다. exactAllowWhileIdle 모드와 결합하면 Doze 모드에서도 동작한다.

1년 전에 이 옵션을 알았으면 Kotlin 네이티브로 내려갈 필요가 없었을지도 모른다. 하지만 이 옵션이 “정답"이라는 걸 확신하려면, 다른 방법들이 왜 안 되는지를 직접 경험해봐야 했다.

그래도 남은 문제

구조는 잡혔지만, 이 버전에는 치명적인 문제가 있었다. 앱을 일정 기간 열지 않으면 알림이 오지 않았다.

원인은 알림 스케줄링 시점에 있었다. 당시 코드는 스케줄링할 때 미래의 특정 날짜 급식을 미리 가져와서 알림 내용에 박아넣는 구조였다:

1
2
3
4
5
6


// 2024-12 버전 — 스케줄링 시점에 특정 날짜의 급식을 가져옴
String bigText = (await MealDataApi.getMeal(
 date: DateTime(scheduledDate.year, scheduledDate.month, scheduledDate.day),
 mealType: mealType,
 type: MealDataApi.MENU,
))?.meal ?? '급식 정보가 없습니다';

matchDateTimeComponents: DateTimeComponents.dayOfWeekAndTime은 매주 반복 알림을 시스템에 등록한다. 하지만 알림의 내용은 등록 시점에 고정된다. 월요일에 스케줄링하면 그 주 월요일 급식 메뉴가 알림에 박히고, 다음 주 월요일에도 똑같은 내용이 표시된다.

그래서 앱을 열 때마다 scheduleDailyNotifications()를 호출해서 알림을 새로 등록하는 방식으로 우회했는데, 문제는 앱을 오래 안 열면 갱신이 안 된다는 것이었다. 2주 동안 앱을 안 열면 2주 전 급식 메뉴가 계속 뜨거나, NEIS API에 해당 날짜 데이터가 없어서 “급식 정보가 없습니다"만 반복되었다.

알림이 오긴 오는데 내용이 엉뚱하거나, 아예 의미 없는 메시지가 뜨니까 사용자 입장에서는 “알림이 안 온다"와 다름없었다.

현재 버전으로의 진화 (2026년 3~4월)

이 문제를 해결하면서 동시에 여러 개선을 적용한 게 현재 버전이다.

알림 내용 갱신 방식 변경

가장 핵심적인 변경은 급식 데이터를 가져오는 방식이다:

1
2
3
4
5
6
7


// 현재 버전 — 항상 오늘 날짜 기준으로 가져옴
final meal = await MealDataApi.getMeal(
 date: DateTime.now(),
 mealType: mealType,
 type: MealDataApi.MENU,
);
menuPreview = _cleanMenu(meal?.meal);

scheduledDate 대신 DateTime.now()를 사용한다. 어차피 앱이 열릴 때마다 scheduleDailyNotifications()가 호출되면서 알림을 전부 취소하고 다시 등록하기 때문에, 가장 최신 급식 데이터로 갱신된다. 그리고 데이터를 못 가져왔을 때의 폴백도 달라졌다:

1
2
3
4
5


// 2024-12 버전
'급식 정보가 없습니다'

// 현재 버전
'오늘의 $mealLabel 메뉴를 확인하세요' // (i18n 적용 후: l.noti_mealConfirm(mealLabel))

데이터가 없을 때 “정보가 없다"고 보여주는 대신, 앱을 열어보도록 유도하는 문구로 바꿨다. 월이 바뀔 때 데이터가 없거나, 예약 시점에 인터넷이 연결되지 않았을 수 있기 때문이다.

알러지 정보 정리

NEIS API에서 내려오는 급식 메뉴에는 알러지 번호가 붙어 있다. 비빔밥(5.6.13) 이런 식으로. 알림에 이게 그대로 들어가면 지저분하다.

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(' · ');
}

_cleanMenu()가 알러지 괄호를 제거하고, 줄바꿈을 ·로 연결해서 한 줄 미리보기를 만든다. “비빔밥 · 미역국 · 배추김치 · 요구르트” 이런 깔끔한 형태로.

알림 탭 → 급식 화면 이동

2024-12 버전에서는 알림을 탭해도 아무 일도 안 일어났다. 그냥 앱이 열리거나, 아예 반응이 없었다.

현재 버전은 payload를 활용한다:

1
2
3
4


await _localNotificationsPlugin.zonedSchedule(
 ...
 payload: 'meal_screen',
);

알림을 탭하면 notificationStream에 'meal_screen'이 전달되고, 앱이 이를 받아서 급식 화면으로 바로 이동한다. 앱이 꺼져 있었더라도 cold start 후 급식 화면까지 자동으로 네비게이션된다.

1
2
3
4


void _onNotificationTap(NotificationResponse response) {
 log('Notification tapped: ${response.payload}');
 notificationStream.add(response.payload);
}

권한 요청 분리

2024-12 버전에서는 알림 초기화 과정에서 바로 권한을 요청했다. 앱을 처음 열자마자 “알림을 허용하시겠습니까?” 팝업이 뜨는 방식이었는데, 맥락 없이 갑자기 뜨는 권한 요청은 거부율이 높다.

현재 버전에서는 _requestPermissions()를 DailyMealNotification 클래스에서 제거하고, 설정 화면에서 알림을 켤 때 바텀시트로 권한을 요청하는 방식으로 바꿨다. 사용자가 “급식 알림을 받겠다"는 의도를 먼저 표현한 상태에서 권한을 요청하니까 허용율이 훨씬 높다.

다국어 지원

하드코딩되어 있던 한국어 문자열을 전부 AppLocalizations로 교체했다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 2024-12 버전
'🍽️ $mealLabel 알림'
'급식 정보 알림을 제공합니다.'
'한솔고등학교'

// 현재 버전
l.noti_mealBreakfast // 알림 제목
l.noti_mealChannelName // 채널 이름
l.noti_mealChannelDesc // 채널 설명
l.noti_schoolName // 학교 이름

영어를 사용하는 학생도 알림을 이해할 수 있게 되었다.

조식·중식·석식 개별 설정

사용자가 원하는 끼니만 골라서 알림을 받을 수 있다. 기숙사생은 조식·중식·석식 전부, 통학생은 중식만. 시간도 각각 다르게 설정 가능하다.

1
2
3
4
5
6
7
8
9


if (settings.isBreakfastNotificationOn) {
 await _scheduleWeeklyNotification(
 id: 1,
 mealLabel: l.meal_breakfast,
 notiTitle: l.noti_mealBreakfast,
 time: _parseTimeOfDay(settings.breakfastTime),
 weekdays: weekdays,
 );
}

월~금 각 요일별로 별도의 알림 ID를 부여해서 (조식×5 + 중식×5 + 석식×5 = 최대 15개) 개별적으로 관리한다. 주말에는 급식이 없으니까 토·일은 제외.

📎 알림 기능의 전체 구조는 DailyMealNotification 문서에서 확인할 수 있다.

2024-12 버전 vs 현재 버전

항목	2024-12 버전	현재 버전
급식 데이터	`scheduledDate` 기준 (고정)	`DateTime.now()` 기준 (갱신)
데이터 없을 때	“급식 정보가 없습니다”	“메뉴를 확인하세요” (유도)
알러지 정보	그대로 노출	`_cleanMenu()`로 제거
알림 탭	반응 없음	급식 화면으로 딥링크
권한 요청	앱 시작 시 즉시	설정 바텀시트에서 맥락적으로
언어	한국어 하드코딩	i18n (한국어 + 영어)
디버깅	`print()` 남발	`log()` 정리
테스트	없음	`sendTestNotification()` 제공

코드 줄 수는 259줄에서 239줄로 오히려 줄었다. 기능은 훨씬 많아졌는데 코드가 줄어든 건, 권한 요청 로직을 분리하고 print() 디버깅 코드를 정리한 덕분이다.

1년 반의 기록

급식 알림 하나를 만드는 데 거친 경로를 정리하면:

시기	접근 방식	결과
2023-12	NotificationManager + FCM	FCM은 서버 필요 → 당일 삭제
2023-12	ScheduledNotification (로컬)	기본 동작은 하지만 불안정
2024-07	notification_manager 리팩토링	앱 종료 시 알림 누락
2024-08	Kotlin 네이티브 (WorkManager)	플랫폼별 코드 중복, 통신 복잡
2024-09	Kotlin 삭제, Flutter 복귀	구조 정리 시작
2024-12	DailyMealNotification 구조 전환	동작하지만 장기 미접속 시 내용 갱신 불가
2026-03~04	현재 버전	딥링크, i18n, 메뉴 프리뷰, 권한 UX 개선

파일 생성과 삭제 횟수를 세면:

FirebaseCloudMessaging.dart → 생성 → 삭제
ScheduledNotification.dart → 생성 → 삭제
MealNotificationReceiver.kt → 생성 → 삭제
MealWorker.kt → 생성 → 삭제
meal_notification_worker.dart → 생성 → 삭제
notification_manager.dart → 생성 → 수차례 대규모 수정 → 삭제
daily_meal_notification.dart → 최종 생존

6개의 파일이 만들어졌다 사라졌고, 1개만 살아남았다.

배운 것

“간단해 보이는 기능"은 없다. 사용자에게 간단하게 보이는 기능일수록 뒤에서 처리해야 할 것이 많다. “매일 아침 알림 보내기"라는 한 문장 뒤에는 타임존, 배터리 최적화, 백그라운드 제약, 플랫폼별 차이, API 호출 타이밍 같은 문제들이 숨어 있었다.

네이티브로 내려가는 건 최후의 수단이어야 한다. 크로스플랫폼 프레임워크를 쓰면서 네이티브 코드를 작성하는 순간, 유지보수 비용이 플랫폼 수만큼 곱해진다. 특히 1인 개발에서는 치명적이다.

“동작한다"와 “제대로 동작한다"는 다르다. 2024년 12월 버전은 동작했다. 알림이 왔다. 하지만 일정 기간 앱을 안 열면 내용이 갱신되지 않았고, 알림을 탭해도 아무 일도 안 일어났고, 권한 요청 타이밍이 나빴다. 기능이 “있는” 것과 “쓸 만한” 것 사이에는 이런 디테일들이 잔뜩 있다.

삽질은 낭비가 아니다. FCM을 시도해봤기 때문에 서버 푸시와 로컬 알림의 차이를 이해했고, Kotlin 네이티브를 경험했기 때문에 Flutter의 한계와 가능성을 정확히 알게 되었다. 최종 코드 239줄에는 1년 반의 시행착오가 전부 녹아 있다.