NEIS API 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 패턴까지의 과정을 다룬다.

#2 - Java에서 Flutter로

Mon, 06 Apr 2026 00:00:00 +0000

학교 사업 프로그램

학교에서 학생들의 창업이나 프로젝트를 지원하는 프로그램이 있었다. 아이디어를 제출하고, 팀을 꾸려서 발표하고, 선정되면 활동비와 멘토링을 지원받는 구조였다.

팀원 두 명과 함께 “학교 통합 앱"이라는 주제로 지원했다. 급식, 시간표, 공지사항을 한곳에서 볼 수 있는 앱. 매번 학교 홈페이지에 들어가야 하는 불편함을 해결하자는 단순한 아이디어였고, 다행히 선정되었다.

Java + XML 프로토타입

당시 나는 Java를 조금 공부한 상태였다. 모바일 개발 경험은 전혀 없었지만, Java를 알고 있으니 Android 네이티브가 가장 접근하기 쉬워 보였다. 그래서 첫 프로토타입은 Java + XML Layout으로 만들었다.

159커밋의 기록

이 프로토타입은 단순한 데모가 아니었다. GitHub에 159개의 커밋이 남아 있을 정도로 꽤 오랜 기간 개발했다. v0.12.3 Beta까지 버전이 올라갔다.

구현했던 기능들:

급식 정보 — NEIS 공공데이터 API를 파싱해서 오늘/이번 주 급식을 보여줌. 영양정보까지 표시
시간표 조회 — NEIS API로 시간표 데이터를 가져와서 요일별로 표시
공지사항 — 학교 공지를 앱에서 확인할 수 있는 Fragment 구현
알림 — 매일 급식 알림을 보내주는 기능

개발하면서 겪었던 문제들도 많았다. FutureTask에서 CompletableFuture로 비동기 처리 방식을 전환하기도 했고, UI 디자인을 대규모로 리팩토링한 적도 있었다 (v0.11.5 → v0.12.3 구간). 투박한 첫 UI에서 점점 나아지는 과정이 커밋 히스토리에 그대로 남아 있다.

하지만 이 프로토타입의 가장 큰 가치는 실제로 NEIS API를 호출해서 데이터를 가져오고 화면에 보여줄 수 있다는 걸 증명한 것이었다. 학교 앱이라는 아이디어가 기술적으로 가능하다는 확신을 얻었다.

발표와 부스

프로토타입이 어느 정도 완성된 후, 참여 팀들과 선생님 앞에서 발표하는 자리가 있었다. 발표는 팀원이 맡았다. 앱의 컨셉, 해결하려는 문제, 현재 구현된 기능을 설명하고 실제 동작하는 프로토타입을 시연했다.

그리고 학교 메인 홀에서 부스를 열었다.

부스를 운영하면서 직접 학생들을 만났다. 관심을 가지는 학생도 있었고, “이런 게 왜 필요해?” 하는 반응도 있었다. 하지만 가장 중요한 건, 부스에서 두 가지 결정적인 사실을 알게 되었다는 것이다.

1. Android와 iOS, 거의 반반

부스에 태블릿을 놓고 직접 만든 사전등록 앱을 실행해뒀다. 학번, 이름, 전화번호, 사용 중인 OS를 입력하는 간단한 폼이었는데, OS 필드를 집계해보니 Android와 iOS가 거의 반반이었다.

이건 심각한 문제였다. 지금까지 Java + XML로 Android 앱만 만들고 있었는데, 그러면 학교 학생 절반이 이 앱을 쓸 수 없다는 뜻이다.

그렇다고 Swift로 iOS 버전을 따로 만들 수 있는 상황이 아니었다. 나는 Java를 조금 아는 1학년이었고, 새로운 언어와 완전히 다른 플랫폼을 동시에 학습하면서 두 벌의 앱을 유지보수한다? 비현실적이었다.

이때 처음으로 크로스플랫폼 프레임워크를 진지하게 고민하기 시작했다. React Native와 Flutter가 후보였는데, 당시 Flutter의 성장세가 가파르기도 했고, Dart 언어가 Java에서 넘어오기에 비교적 친숙해 보였다.

2. “2, 3학년은 시간표가 다른데요?”

부스에서 받은 질문 중 하나가 프로젝트의 방향을 바꿨다.

“1학년은 반만 입력하면 되는데, 2학년부터는 선택과목 때문에 시간표가 다 달라요.”

1학년인 나는 이걸 몰랐다. 1학년은 학년과 반을 입력하면 시간표가 그대로 확정된다. 같은 반 학생은 모두 같은 시간표를 따른다.

하지만 2·3학년은 완전히 다른 세계였다. 선택과목 제도 때문에 같은 반이라도 학생마다 시간표가 다르다. A는 3교시에 물리학을, B는 같은 시간에 생명과학을 듣는다. 그리고 그 수업은 각각 다른 반 교실에서 진행된다.

NEIS API에서 제공하는 시간표 데이터는 반(CLASS_NM)별로 내려온다. 1학년이라면 자기 반 데이터만 가져오면 끝이지만, 2·3학년의 선택과목 시간에는 여러 반의 수업이 뒤섞여 있었다. 단순히 API를 호출해서 보여주는 것으로는 해결이 안 되는, 로직이 필요한 문제였다.

이걸 들었을 때 솔직히 막막했다. 하지만 동시에 “이걸 해결하면 진짜 쓸 수 있는 앱이 되겠다"는 생각이 들었다.

기숙사에서 2주

당시 기숙사에 살고 있었다. 평일 저녁 자습 시간과 주말을 온전히 개발에 쏟을 수 있는 환경이었다. 부스에서 받은 시간표 피드백을 해결하겠다는 목표를 잡고, 2주를 잡았다. 1주는 기획, 1주는 구현.

개발을 시작한 지 얼마 안 된 상태에서 이 로직을 만들어야 했기 때문에, 쉽지 않을 거라는 건 알고 있었다.

1주차: NEIS API 분석과 로직 기획

먼저 NEIS API의 시간표 데이터 구조를 철저히 분석했다. API를 호출하면 이런 형태의 데이터가 온다:

1
2
3
4
5
6
7


{
 "ALL_TI_YMD": "20260414",
 "GRADE": "2",
 "CLASS_NM": "3",
 "PERIO": "4",
 "ITRT_CNTNT": "물리학Ⅰ"
}

날짜, 학년, 반, 교시, 과목명. 이걸 조합해서 개인 시간표를 만들어야 했다.

핵심 문제를 정리하면:

학년	시간표 결정 방식
1학년	학년 + 반 입력 → 시간표 확정 (단순 조회)
2·3학년	학년 전체 시간표에서 반별 과목 추출 → 사용자가 선택과목 선택 → 해당 과목의 반·교시 매칭 → 커스텀 시간표 생성

2·3학년의 흐름을 더 구체적으로 설계했다:

getTimeTable() — NEIS API에서 해당 학년의 전체 시간표를 가져온다. 반 필터 없이 전체를 요청해서, 모든 반의 모든 과목 데이터를 확보한다.
getAllSubjectCombinations() — 가져온 전체 시간표에서 반별 과목 조합을 추출한다. “3반 4교시 = 물리학Ⅰ”, “5반 4교시 = 생명과학Ⅰ” 같은 매핑을 만든다. 이걸로 사용자에게 “어떤 과목을 듣는지” 선택지를 보여줄 수 있다.
사용자가 자기 선택과목을 고른다 — UI에서 과목 목록을 보여주고, 자기가 듣는 과목을 체크한다.
getCustomTimeTable() — 선택한 과목이 어느 반의 몇 교시에 있는지 역추적해서, 그 학생만의 개인 시간표를 생성한다.

📎 시간표 API의 전체 구조는 TimetableDataApi 문서에서 확인할 수 있다.

일주일 동안 노트에 데이터 흐름을 그리고 또 그렸다. API 응답 구조부터 최종 시간표까지의 변환 과정을 머릿속에서 완전히 정리한 후에야 코드를 쓸 수 있겠다는 확신이 들었다.

2주차: 구현

기획대로 코드를 작성했다. 처음이라 삽질도 많았지만, 기획을 확실히 해둔 덕분에 방향을 잃지는 않았다.

까다로웠던 부분들:

반별 과목 파싱

NEIS API 응답에서 날짜별 → 반별 → 교시별 과목을 3중 중첩 Map으로 정리해야 했다.

1
2


// 날짜 → 반번호 → [1교시, 2교시, 3교시, ...]
Map<String, Map<String, List<String>>>

API에서 넘어오는 데이터는 flat한 배열이라, 이걸 날짜와 반으로 그룹핑하고, 교시 순서대로 정렬해서 넣어야 했다. 교시(PERIO) 사이에 빈 시간이 있을 수도 있어서, 리스트를 교시 수만큼 미리 할당하고 해당 인덱스에 과목명을 넣는 방식으로 처리했다.

1
2
3
4


while (classList.length < perio) {
 classList.add('');
}
classList[perio - 1] = content;

선택과목 시간표를 처음 구상했을 때의 핵심 아이디어가 바로 이것이었다. 빈 2차원 배열(요일 × 교시)을 먼저 만들어놓고, 사용자가 선택한 과목을 해당 위치에 채워 넣는 방식. 빈 시간표라는 틀을 먼저 준비하고, 거기에 자기 과목을 하나씩 배치한다는 발상이 전체 로직의 출발점이었다.

선택과목 매칭

사용자가 고른 과목명이 어느 반의 몇 교시에 해당하는지 역추적하는 게 핵심이었다. 같은 과목이 여러 반에 걸쳐 있을 수 있다. 예를 들어 “물리학Ⅰ"이 3반에서도, 7반에서도 진행될 수 있다.

이 문제를 해결하기 위해 Subject 모델에 subjectClass(반 번호)를 포함시켰다. 단순히 과목명만으로는 부족하고, 어느 반의 물리학인지까지 알아야 정확한 시간표를 만들 수 있었다.

1
2
3
4


Subject(
 subjectName: "물리학Ⅰ",
 subjectClass: 3, // 3반에서 진행되는 물리학
)

커스텀 시간표를 만들 때는, 사용자가 선택한 과목 목록을 반별로 그룹핑한 뒤, 해당 반의 시간표에서 매칭되는 교시를 찾아서 개인 시간표에 채워 넣었다.

폴백 전략

시간표가 항상 있는 건 아니다. 방학 중에는 시간표 데이터가 없고, 시험 기간에는 특별 시간표가 올라오기도 한다. 이번 주 데이터가 없으면 앱이 빈 화면을 보여주는 건 좋지 않았다.

그래서 3단계 폴백을 구현했다:

이번 주 시간표를 가져온다
없으면 다음 주 시간표를 가져온다
그래도 없으면 지난 주 시간표를 가져온다

이렇게 하면 방학 직전이나 직후에도 가장 가까운 시간표를 보여줄 수 있었다.

캐싱

NEIS API를 매번 호출하면 느리고, 불필요한 네트워크 요청이 늘어난다. SharedPreferences에 캐싱을 구현했다.

12시간 이내: 캐시 데이터를 바로 반환 (네트워크 요청 없음)
12시간 ~ 3일: Stale-While-Revalidate — 일단 캐시를 반환하되, 다음 요청 때 갱신
3일 초과: 캐시 삭제 후 새로 요청

SWR 패턴을 적용한 건 나중의 일이지만, 캐싱의 기본 개념은 이때 처음 구현했다. 네트워크 상태가 좋지 않은 학교 와이파이 환경에서 캐싱이 얼마나 중요한지 실감했다.

159커밋을 버리는 결정

시간표 로직을 완성한 뒤, 프로젝트 전체를 Flutter로 전환하기로 결정했다.

159개의 커밋이 쌓인 Java 프로젝트를 버리는 건 쉬운 결정이 아니었다. 급식 파싱, 시간표 조회, UI 리팩토링까지 수개월의 작업이 담겨 있었다. 하지만 부스에서 확인한 현실이 명확했다.

학교 학생의 절반이 iOS를 쓴다 → Android만으로는 안 된다
Swift로 iOS를 따로 만들 여력이 없다 → 크로스플랫폼이 필수
Flutter는 Dart 하나로 양쪽을 커버한다 → 유일한 현실적 선택지

그리고 Java 프로토타입에서 이미 해결한 문제들 — NEIS API 파싱, 시간표 로직, 캐싱 전략 — 은 코드는 버려도 설계와 경험은 그대로 가져갈 수 있었다. 실제로 Flutter로 다시 작성할 때 Java에서 삽질했던 부분들은 훨씬 빠르게 구현할 수 있었다.

Java 프로토타입은 GitHub에 그대로 남겨두었다. v0.12.3 Beta, 159커밋. 여기까지가 이 앱의 선사시대다.

Flutter로의 전환

Dart는 Java와 문법이 비슷해서 언어 자체의 진입 장벽은 낮았다. 하지만 Flutter의 위젯 트리 개념은 XML Layout과 완전히 달랐다. XML에서는 화면을 선언적으로 정의하지만 로직과 분리되어 있었고, Flutter에서는 UI 자체가 코드다.

처음에는 어색했지만, 익숙해지니 오히려 편했다. 특히 핫 리로드 — 코드를 수정하면 앱을 재시작하지 않아도 바로 화면에 반영된다 — 가 생산성을 극적으로 올려줬다. Java + XML 시절에는 빌드하고 에뮬레이터에 올리고 기다리는 시간이 길었는데, 그 시간이 거의 0으로 줄었다.

시간표 로직도 Dart로 다시 작성했다. Java에서의 경험이 있으니 설계는 이미 머릿속에 있었고, Dart의 컬렉션 API가 Java보다 간결해서 코드량도 줄었다. Map, List, Set의 함수형 메서드들이 데이터 파싱에 특히 유용했다.

돌아보면

부스에서 받은 피드백 두 개가 프로젝트의 방향을 결정했다.

“iOS는 안 돼요?” → Flutter 전환
“2학년 시간표는요?” → 선택과목 커스텀 시간표 로직

사용자를 직접 만나는 게 얼마나 중요한지 체감한 순간이었다. 혼자 방에서 코딩만 했으면 절대 알 수 없었을 것들이다. 기획서를 아무리 잘 써도, 실제 사용자 앞에서 프로토타입을 보여주는 것만큼 확실한 검증은 없다.

그리고 159커밋을 버린 건 아깝지만, 프로토타입의 목적은 원래 “버리기 위해 만드는 것"이다. 프로토타입에서 얻은 기술적 경험과 사용자 피드백이 Flutter 버전의 기초가 되었으니, 하나도 낭비된 게 아니었다.

다음 글에서는

Flutter 전환 직후 가장 먼저 만들고 싶었던 기능, 급식 알림. 단순해 보였던 이 기능을 제대로 만드는 데 1년이 걸린 이야기를 다룬다.