프로젝트에서 보기 →

[flutter] ios와 android 앱을 한번에 만들어 보자 | 기간제교사 공고 확인 앱 - 개발자 이선생

태그
기술 react native 리액트 네이티브 모바일 앱
시작일
종료일
수정일

https://www.youtube.com/watch?v=kD6pGXUmVek

1. 이건 꼭 알아야 한다[^1]

[? 질문] 구식이고 모바일에서 보기 불편한 서울시교육청 기간제/시간강사 구인 게시판을 더 편하게 확인하려면 어떻게 해야 하는가[^2]
[= 답] 모바일에서 한 손으로 필터/정렬/원문/첨부를 빠르게 확인할 수 있는 전용 앱을 직접 만들면 된다(발표자는 이를 Flutter로 구현했다).[^9]

[? 질문] iOS와 Android 앱을 “거의 동일한 UI/UX”로 동시에 만들 수 있는 현실적인 방법은 무엇인가[^13]
[= 답] Flutter를 사용하면 하나의 구현으로 iOS/Android에서 같은 인터페이스를 제공하는 앱을 만들 수 있다(발표자 경험 기반).[^21]

[? 질문] 이 앱은 데이터를 어떻게 저장하고, 앱은 어떤 방식으로 데이터를 가져오는가(구현 아키텍처)?[^18]
[= 답] 데이터 저장은 DynamoDB, API는 AWS Lambda로 구성하고, 앱 실행 시 Lambda가 DynamoDB에서 데이터를 조회해 앱에 전달한다.[^18]

2. 큰 그림[^2]

이 콘텐츠는 발표자가 이직 준비 기간에 서울시교육청 구인 게시판을 이용하다가, 모바일에서 지나치게 불편한 UI/검색 흐름을 경험한 뒤 이를 해결하기 위해 Flutter로 iOS/Android 동시 개발 앱을 만든 과정을 소개하는 데 목적이 있다.[^2][^9] 앱의 실제 화면에서 어떤 문제를 어떤 기능으로 해결했는지(필터/정렬/원문/첨부/동시 정보 노출), 그리고 백엔드 구성이 무엇인지(DynamoDB+Lambda)를 짧게 시연한다.[^10][^18]

  • 문제 인식(불편함의 구체): 게시판이 “구식”이고 검색/필터 시 페이지가 계속 새로고침되며, 모바일 최적화가 없어 휴대폰에서 보기 어렵다.[^3][^4][^7]
  • 해결(앱 기능으로 재구성): 학교급/과목/지역 선택, 마감 임박 정렬, 원문 열기, 첨부파일 미리보기 등 “한 화면/한 손 조작” 중심의 사용성을 제공한다.[^11][^14]
  • 메시지(Flutter의 장점 체감): 간단한 앱이지만 iOS와 Android에서 정말 똑같은 인터페이스를 구현할 수 있었다는 점을 큰 장점으로 강조한다.[^21]

3. 하나씩 살펴보기[^2]

3.1 시작: “Flutter로 iOS/Android를 동시에 개발한 이야기”를 꺼내다[^2]

📸 0:06

발표자는 인사와 자기소개(“개발자 이선생”) 후, 오늘의 주제로 Flutter를 이용해 iOS와 Android 앱을 동시에 개발한 경험담을 들려주겠다고 예고한다.[^2] 즉, 특정 앱을 만들며 느낀 Flutter의 효용(동일 UI/동시 개발 가능성)을 사례로 설명하는 구성임을 처음부터 밝힌다.[^2]

  • 발표 흐름의 전제:
    • “한 번의 개발로 iOS와 Android를 함께”라는 목표가 중심이다.[^2]
    • 그 목표를 실제로 적용한 결과물(기간제교사 공고 확인 앱)을 시연한다.[^9][^10]

3.2 문제의 출발점: 이직 준비 중 ‘시간제 강사/기간제’ 공고를 찾다가 생긴 불편[^3]

📸 0:14

발표자는 회사에 오기 전 이직 과정에서 “학교가 조금 그립기도” 했고, 이직 기간 동안 “하루이틀 시간제 강사”를 해볼까 하는 마음으로 서울시교육청 홈페이지에 들어가 공고를 찾아봤다고 설명한다.[^3] 그 과정에서 구인 게시판을 접했는데, 첫인상이 “딱 봐도 너무 구식”이었다고 말한다.[^4]

여기서 중요한 건 단순히 “불편했다”가 아니라, 발표자가 불편함을 구체적인 조작/화면 전환/검색 조건의 제약으로 나열하며 문제를 정의한다는 점이다.[^4][^5][^6][^7]

3.2.1 검색/탐색 흐름이 끊기는 구조: 클릭할 때마다 페이지가 새로고침[^5]

발표자는 예로 “초등학교를 구하고 싶으면 초등학교를 누르고 검색”해야 하는데, 그 과정에서 페이지가 새로 고쳐지게(새로 거치게) 된다고 말한다.[^5] 즉, 사용자가 조건을 변경/탐색할 때마다 화면이 갱신되어 탐색 흐름이 매끄럽지 않고, 연속 탐색에 불리하다는 문제의식을 드러낸다.[^5]

  • 사용자가 원하는 흐름(발표자 의도): 가까운 곳/원하는 조건을 빠르게 좁혀가며 연속적으로 확인.[^6]
  • 실제 사이트 경험: 조건 선택/검색마다 새로고침 발생.[^5]

3.2.2 지역구 필터가 ‘선택’이 아니라 ‘직접 입력’에 가깝다[^6]

발표자는 “가까운 데로 찾고 싶으니까 지역구를 고르려면 이렇게 직접 쳐야 돼요”라고 말하며, 예로 “관악구”를 입력해 검색하는 과정을 보여준다.[^6] 그리고 이 역시 “또 페이지가 새로 고쳐”진다고 말한다.[^6]

정리하면 발표자가 느낀 문제는:

  • 지역 필터가 UI로 쉽게 고르는 방식이라기보다 텍스트 입력 기반에 가깝고,[^6]
  • 검색 실행 시마다 새로고침이 발생해,[^6]
  • 모바일/빠른 탐색 상황에서 피로도가 커진다는 점이다.[^7][^8]

3.2.3 공고 리스트와 블로그/상세를 “동시에” 볼 수 없다[^7]

발표자는 공고를 크게 보고 싶고(리스트), 동시에 “블로그” 같은 부가 정보(혹은 상세)를 같이 보고 싶은데, “이 두 가지를 동시에 볼 수가 없어요”라고 말한다.[^7] 그래서 “공고를 쭉 보고 다음에 블로그를 보고”처럼 왔다 갔다 해야 한다고 설명한다.[^7]

이 대목은 앱에서 무엇을 개선할지(한 화면에서 정보 구성/전환 최소화)로 이어지는 문제정의다.[^7][^11]

3.2.4 중등 검색의 조건 결합 한계: 과목과 다른 조건을 같이 검색하기 어렵다[^8]

발표자는 “중등 같은 경우는 과목도 과목이랑 (다른 조건) 같이 검색할 수가 없어요”라고 말하며, 조건 결합 검색이 불편하거나 지원이 부족하다는 점을 지적한다.[^8] 이는 이후 앱에서 “중등 과목도 고를 수 있다”는 기능 소개로 직접 연결된다.[^14]

3.2.5 모바일 최적화 부재: 휴대폰에서 거의 볼 수 없고 확대를 반복해야 한다[^7][^8]

발표자는 특히 결정적인 문제로 “모바일로 보면 모바일 페이지가 따로 없어서 굉장히 보기가 불편”하며 “핸드폰에서는 거의 볼 수 없어요”라고 말한다.[^7] 사용자는 매번 “확대를” 해야 하고, (버튼/선택 UI도) “홈페이지가 없기 때문에 보기가 굉장히 힘들죠”라는 식으로 모바일 사용성의 부재를 강조한다.[^8]

[!IMPORTANT] 모바일에서의 ‘확대 반복’은 치명적인 사용성 문제로 제시됨
발표자는 기간제/시간강사 공고를 이동 중 휴대폰으로 보려는 맥락에서, 매번 확대해야 하고 UI가 불편해 “거의 볼 수 없다”는 수준으로 문제를 규정한다.[^7][^8]

3.2.6 결론: “내 기간제를 구할 게 아니더라” → “쉽게 볼 수 있는 앱을 만들어보자”[^9]

여러 불편을 겪은 뒤 발표자는 “아이고 내 기간제를 구할 게 아니더라”라고 말하며, 이직 기간 동안 이 공고들을 모바일로 쉽게 볼 수 있는 앱을 한번 만들어보자는 결론에 도달했다고 말한다.[^9] 즉, 불편의 나열이 곧 앱 제작의 동기이자 요구사항 정의로 작동한다.[^9]

3.3 앱 시연(1): iOS에서 공고 확인, 원문 열기, 첨부파일 보기[^10]

📸 1:51

발표자는 “이 앱을 같이 살펴보도록 하겠습니다”라고 말한 뒤, 본인이 만든 앱 화면을 보여주며 구체 기능을 소개한다.[^10]

3.3.1 공고 목록을 앱에서 보기 + 항목 클릭 동작[^11]

발표자는 앱이 “이렇게 볼 수 있게 만들었”다고 하며 공고 목록 UI를 보여준다.[^11] 그리고 “여기서 클릭하면 … 이렇게 볼 수 있고”라고 말해, 공고 항목을 탭하면 상세/미리보기 형태로 내용을 확인할 수 있음을 시연한다.[^11]

원문 자막에 일부 음성 인식 오류가 있으나, 전체 맥락상 “탭 → 상세 확인” 흐름을 보여주는 장면이다.[^11]

3.3.2 ‘원문보기’로 공식 사이트를 열 수 있음[^12]

발표자는 “원문보기 하면 당연히 사이트가 열리구요”라고 말해, 앱 내부에서 요약/목록만 제공하는 것이 아니라 공식 원문 링크로 이동하는 기능을 제공함을 명확히 한다.[^12]

  • 앱의 역할:
    • 공고 탐색과 필터링을 편하게 만들고,[^14]
    • 필요 시 원문을 바로 열어 확정 정보를 확인하게 한다.[^12]

3.3.3 첨부파일이 있는 공고는 ‘첨부파일 미리보기’가 가능[^13]

발표자는 “첨부파일이 있는 경우에는 첨부파일도 보이는데”라고 말하고, 실제로 “첨부파일도 이렇게 보실 수가 있습니다”라고 하며 첨부파일 표시/열람을 시연한다.[^13] 즉, 기존 웹에서 불편했던 열람 경험을 앱에서 더 직접적으로 제공하려는 기능이다.[^13]

[!TIP] 공고 확인에서 자주 막히는 지점(첨부 확인)을 앱에서 바로 해결
발표자는 “첨부파일이 있는 경우”를 별도로 짚고, 앱 내에서 첨부파일을 열람(미리보기)할 수 있음을 시연한다.[^13]

3.4 앱 시연(2): 필터/정렬—학교급, 과목(중등), 마감 임박 정렬, 지역 다중 선택[^14]

📸 2:25

발표자는 이어서 한 손 조작을 강조하듯 “지금 한손으로…”라는 표현을 섞어가며, 조건을 고르는 UI를 보여준다(자막 일부 누락/오인식이 있으나 기능 소개의 흐름은 분명하다).[^14]

3.4.1 학교급 선택 + 중등 과목 선택 가능[^14]

발표자는 “학교… 여기서 고를 수가 있고”라고 말하며 학교급(초/중등 등) 필터를 선택할 수 있음을 보여준다.[^14] 특히 “중등 같은 경우엔 과목도 … 수 있고”라고 말해, 기존 사이트에서 불편했던 과목 조건을 앱에서 필터로 제공함을 강조한다.[^14]

이는 앞서 제기한 문제(중등에서 과목과 다른 조건을 같이 검색하기 어렵다)를 앱에서 해결한다는 대응 관계를 이룬다.[^8][^14]

3.4.2 마감일 임박 순 정렬(초등 선택 후 가능) 언급[^14]

발표자는 “초 등을 골라서 마감일이 임박한 순서대로 정렬을 할 수도 있구요”라고 말한다.[^14] 즉, 단순 검색 결과 나열이 아니라 사용자가 의사결정을 빠르게 하도록 정렬 기능(마감 임박)을 제공한다.[^14]

3.4.3 지역 선택: 강서구/관악구 등 선택 + 추가 선택 가능(다중 선택 뉘앙스)[^15]

발표자는 “지역도 … 강서구 관악구를 골랐는데”라고 말하며 지역구 예시를 들고, “추가해서 선택할 수가 있습니다”라고 한다.[^15] 이는 지역 필터를 텍스트 입력으로 반복하는 대신, 앱에서는 선택 기반으로 더 편하게 조합할 수 있음을 시사한다.[^15]

3.4.4 공고 정보와 (부가)정보를 같이 보여준다[^16]

발표자는 “그럼 … 정보도 같이 보여주게 됩니다”라고 말해, 공고와 함께 참고가 되는 정보(자막에는 “그루브”로 인식되나 맥락상 공고 관련 부가정보/블로그/상세 등)를 함께 볼 수 있도록 구성했음을 말한다.[^16] 이는 앞서 “공고를 보고 다음에 블로그를 본다”는 분리된 흐름의 불만을 해결하려는 장치로 연결된다.[^7][^16]

3.4.5 현재 상태 평가: 개선점은 남아 있지만 ‘요즘 괜찮은 것 같지 않나요’[^17]

발표자는 “아직 개선할 점은 … 많이 남아있지만”이라고 솔직히 말하면서도, 현재 결과물에 대해 “그래도 요즘 좀 괜찮은 것 같지 않나요”라고 평가한다.[^17] 즉, 완성형 제품이라기보다 실사용하며 개선해갈 수 있는 단계의 앱임을 명확히 한다.[^17]

3.5 앱 시연(3): Android에서도 동일한 화면/기능을 확인[^17]

📸 2:47

발표자는 “역시 안드로이드 폰에서도 똑같은 화면을 확인하실 수 있습니다”라고 말하며, Android에서도 동일 UI가 동작하는 장면을 보여준다.[^17]

3.5.1 Android에서 원문보기 동작 + 첨부파일 미리보기 동작[^17]

발표자는 Android 화면에서 “원문 보기 하면 여기서도 이렇게 … 나오구요”라고 말해 원문 열기 동작을 재확인한다.[^17] 또한 “첨부파일 미리보기도 가능합니다”라고 말해 iOS에서 보여준 첨부 열람 기능이 Android에서도 동일하게 제공됨을 강조한다.[^17]

3.5.2 Android에서 필터 선택(학교급/지역/급 등) 시연[^17]

발표자는 Android에서도 “여기서도 … 고를 수 있고 지역도 마찬가지로 고를 수 있습니다”라고 말하며 필터 UI가 동일하게 동작함을 보여준다.[^17] 이어 “급도 이렇게 골라 줄 수 있구요”라고 말해 추가 필터(학교급/모집 구분 등 ‘급’으로 표현된 항목)를 선택할 수 있음을 보여준다.[^17]

[!IMPORTANT] ‘동일 UI’ 자체가 Flutter 선택의 근거로 제시됨
발표자는 iOS 시연 후 Android 시연을 바로 붙여, 동일한 기능/화면이 재현되는 것을 보여주며 Flutter의 장점을 체감 사례로 만든다.[^17][^21]

3.6 아키텍처 설명: DynamoDB + Lambda로 데이터 저장/제공[^18]

📸 3:28

시연 이후 발표자는 “아키텍처에 대해서 간단하게 설명”한다며 기술 구성을 요약한다.[^18]

3.6.1 저장소: DynamoDB[^18]

발표자는 “앱에 필요한 데이터를 저장하는 건 다이나모 DB라는 데이터베이스를 사용하고 있구요”라고 말해 데이터 저장 계층이 Amazon DynamoDB임을 명시한다.[^18]

3.6.2 API 계층: AWS Lambda로 구현[^18]

발표자는 “그리고 API를 람다를 이용해서 만들었습니다”라고 말한다.[^18] 즉, 서버를 상시 운영하는 형태라기보다, 요청 시 실행되는 서버리스 함수(Lambda)로 API를 구성했다는 의미다.[^18]

3.6.3 동작 흐름: 앱 실행 → Lambda 호출 → Lambda가 DynamoDB 조회 → 앱에 전달[^18]

발표자는 “앱이 실행되면 이 람다를 통해서 데이터를 호출”하고, Lambda가 “다이나모 DB에서 필요한 데이터를 불러다가 앱에게 전달해 주는 방식”이라고 설명한다.[^18]

이를 순서도로 풀면:

  1. 사용자가 앱 실행/조회 → 2) 앱이 Lambda API 호출 → 3) Lambda가 DynamoDB에서 데이터 조회 → 4) 조회 결과를 앱에 응답.[^18]

3.7 결과 평가와 현실적 제약: 간단히 만들었고, 요구사항은 있지만 모두 반영 못함[^19]

📸 3:52

발표자는 “iOS와 안드로이드 괜찮게 만들어지지 않았네요(=괜찮게 만들어졌네요)”라는 뉘앙스로 결과를 평가한다.[^19] 동시에 이 앱이 “굉장히 간단하게 만든 거”라고 선을 긋고, 실제 사용자(선생님)들이 사용하면서 “이런 점들 고쳐 달라”는 요구사항이 있긴 하지만 “아직 반영을 못했습니다”라고 말한다.[^19]

그 이유로는 “이것만 계속 개발하고 있을 수 있는 게 아니라서요”라고 말해, 시간/리소스 제약 때문에 요구사항 반영이 지연됨을 설명한다.[^20]

  • 제품 성격:
    • 실사용 가능한 형태로 만들었지만,[^11][^17]
    • 개선 요청이 계속 들어올 수 있고,[^19]
    • 개인 프로젝트/사이드 성격이라 즉각 반영이 어려움.[^20]

3.8 결론: Flutter의 가장 큰 장점—iOS/Android에 “정말 똑같은 인터페이스” 구현 가능[^21]

📸 4:14

발표자는 “그치만 이렇게 간단하게 iOS와 안드로이드 앱을 똑같은, 정말 똑같은 인터페이스를 가진 채로 구현할 수 있다는 게 Flutter의 굉장히 큰 장점”이라고 결론을 내린다.[^21]

이 결론은 영상 초반 예고(Flutter로 동시 개발)와 시연(iOS 화면 → Android 동일 화면) 및 기술 구성 설명을 바탕으로 강화된다.[^2][^17][^21]

[c Flutter의 큰 장점으로 ‘동일 UI를 iOS/Android에 함께 구현’할 수 있음을 사례로 제시한다.][^21]

3.9 다음 콘텐츠 제안 및 마무리: 댓글 반응에 따라 Flutter 강의/비교 영상 가능[^22]

📸 4:22

발표자는 Flutter에 대해 “더 듣고 싶으신 분들은 댓글 창에 댓글 남겨”달라고 요청한다.[^22] 반응을 보고:

  • Flutter에 대한 강의를 할 수도 있고,[^22]
  • 다른 기술(자막상 “리액트 네이티브 비교”로 해석 가능)과 비교하는 영상을 찍을 수도 있다고 안내한다.[^22]

마지막으로 시청 감사 인사, 구독/좋아요/알림 설정 요청으로 영상을 마무리한다.[^23]

4. 핵심 통찰[^21]

  1. 불편한 웹 경험을 개선하는 가장 직접적인 방법은 “사용 흐름”을 기준으로 요구사항을 뽑아 앱 기능으로 재배치하는 것이다.[^5][^9]

    • 기존 사이트의 문제는 “새로고침/입력/비동시 정보” 같은 사용 흐름의 끊김으로 표현되고, 앱은 “필터/정렬/원문/첨부/동시 표시”로 그 흐름을 매끈하게 만든다.[^6][^14]

  2. [h 모바일 최적화 부재(확대 반복)는 사용자 이탈을 부르는 결정적 문제로 인식되며, 전용 앱은 이를 정면으로 해결한다.] [^7]

    • 이동 중 확인이라는 맥락에서 “핸드폰에서는 거의 볼 수 없다”는 수준의 불편이 앱 제작 동기가 된다.[^7][^9]

  3. Flutter의 설득 포인트는 추상적인 “크로스플랫폼”이 아니라, 실제 결과물에서 확인되는 “iOS/Android 동일 화면”의 재현성으로 제시된다.[^17][^21]

  4. 서버리스 조합(DynamoDB + Lambda)은 “앱이 필요한 데이터만 호출해 받는” 단순한 구조로 설명 가능하며, 개인/사이드 프로젝트에서 빠른 구현 방식으로 선택될 수 있다.[^18]

  5. 실제 사용자 피드백(“고쳐 달라” 요구)이 발생해도, 개인의 시간 제약으로 즉시 반영이 어려울 수 있다는 현실을 함께 공유한다.[^19][^20]

    • 실행 시사점:
      • 요구사항을 backlog로 쌓고 우선순위를 정해야 한다.[^19]
      • “계속 개발할 수 없는” 조건을 사용자에게 투명하게 커뮤니케이션하는 것이 중요하다.[^20]

참고(콘텐츠 정보)

  • 제목: [flutter] ios와 android 앱을 한번에 만들어 보자 | 기간제교사 공고 확인 앱 - 개발자 이선생[^1]
  • 채널: 개발자이선생[^1]
  • 길이: 5분 3초[^1]
  • 링크: https://www.youtube.com/watch?v=kD6pGXUmVek[^1]
  • 키워드(제공됨): react native, 리액트 네이티브, 모바일 앱, 아이폰, 안드로이드, 플러터, 비전공자, 코딩 독학[^1]

[^1]: 영상 메타데이터(사용자 제공): “# [flutter] ios와 android 앱을 한번에 만들어 보자 | 기간제교사 공고 확인 앱 - 개발자 이선생 / 채널: 개발자이선생 / 길이: 5분 3초 / https://www.youtube.com/watch?v=kD6pGXUmVek / 키워드 …” [^2]: @[00:06] “오늘은 제가 플러터를 이용해서 ios와 안드로이드 앱을 동시에 개발한 이야기를 좀 해드릴게요” [^3]: @[00:14] “이직하는 과정에서… 이직하는 기간 동안 하루이틀 시간제 강사를 좀 해볼까 하고 서울시교육청 홈페이지에 들어가…” [^4]: @[00:25] “구인 게시판이 있는데… 딱 봐도 너무 구식이더라구요” [^5]: @[00:36] “초등학교를 누르고 검색을 하면… 페이지도 새로…” [^6]: @[00:36] “가까운 데로 찾고 싶으니까 지역구를 고르려면 이렇게 직접 쳐야 돼요… 관악구… 검색을 하면 또… 페이지가 새로…” [^7]: @[00:57] “(공고를) 크게… 보고 싶은데… 이 두가지를 동시에 볼 수가 없어요…”, @[01:15] “모바일로 보면… 페이지가 따로 없어서 굉장히 보기가 불편하다”, @[01:22] “핸드폰에서는 거의 볼 수 없어요” [^8]: @[01:10] “중등 같은 경우는 과목도… 같이 검색할 수가 없어요”, @[01:24] “확대를 매번…”, @[01:34] “굉장히 불편하다” [^9]: @[01:34] “이직하는 기간 동안은 이거를 좀 쉽게 모바일로… 볼 수 있는 앱을 한번 만들어보자” [^10]: @[01:51] “이 앱을 한번 같이 살펴 보도록 하겠습니다” [^11]: @[02:01] “이렇게 볼 수 있게 만들었구요… 클릭하면… 이렇게 볼 수 있고…” [^12]: @[02:09] “원문보기 하면 당연히 사이트가 열리구요” [^13]: @[02:13] “첨부파일이 있는 경우에는 첨부파일도…”, @[02:21] “첨부파일도 이렇게 보실수가 있습니다” [^14]: @[02:25] “한손으로… 학교부(학교급) 여기서 고를 수가 있고 중등 같은 경우엔 과목도…”, @[02:33] “마감일이 임박한 순서대로 정렬…” [^15]: @[02:33] “지역도… 강서구 관악구를 골랐는데… 추가해서 선택할 수가 있습니다” [^16]: @[02:43] “그럼 … 정보도 같이 보여주게 됩니다” [^17]: @[02:47] “개선할 점…”, @[02:52] “안드로이드 폰에서도 똑같은 화면…”, @[02:59] “원경(원문) 보기…”, @[03:04] “첨부파일 미리보기도 가능합니다”, @[03:10] “여기서도… 지역도…”, @[03:22] “급도 이렇게 골라…” [^18]: @[03:28] “아키텍쳐… 다이나모 db…”, @[03:35] “api를 람다…”, @[03:38] “앱이 실행되면… 람다를 통해서 데이터를 호출…”, @[03:45] “람다가 다이나모 db에서… 앱에게 전달…” [^19]: @[03:52] “ios와 안드로이드…”, @[03:58] “간단하게 만든… 선생님들이 사용하면서… 요구사항… 아직 반영 못했습니다” [^20]: @[04:06] “이것만 계속 개발하고 있을 수 있는게 아니라서요” [^21]: @[04:14] “ios와 안드로이드 앱을… 정말 똑같은 인터페이스… 구현할 수 있다는게 플러터… 큰 장점” [^22]: @[04:22] “플러터에 대해서… 더 듣고 싶으신 분들은 댓글… 반응을 보고… 강의를… 아니면… 비교하는 영상…” [^23]: @[04:42] “오늘 영상은 여기까지… 시청… 구독과 좋아요… 알림 설정…”

← 프로젝트에서 보기