https://www.youtube.com/watch?v=-Ovbu3NnkRg

description: |-

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

이 콘텐츠는 “Flutter로 웹(홈페이지)까지 만들 수 있는가?”라는 질문을 축으로, Flutter의 멀티플랫폼 범위, 웹으로 배포할 때의 실무적 장단점, 반응형(Responsive) 설계 기준, 그리고 다음 파트에서 만들 여행사 홈페이지(반응형 웹) 실습의 설계 윤곽을 단계적으로 설명한다.[^1]

• [? 질문] Flutter로 개발할 수 있는 플랫폼의 범위는 어디까지인가[^2]
  [= 답] **모바일(Android/iOS)**뿐 아니라 PC(Windows/Mac/Linux), **웹(Web)**까지 한 코드베이스로 대응 가능하며, 강의자는 “현재 기준으로 모바일+PC+웹을 모두 커버하는 건 Flutter가 가장 독보적”이라고 정리한다.[^2]

• [? 질문] 웹페이지(홈페이지)로 배포하는 방식이 앱 배포보다 가지는 실무적 이점은 무엇인가[^9]
  [= 답] 웹은 서버에 올리면 즉시(실시간) 업데이트가 가능하지만, 앱은 스토어 심사/승인/배포 지연 때문에 업데이트가 늦고 운영 리스크가 커진다.[^9]

• [? 질문] Flutter로 웹을 만들 때 얻는 것과 잃는 것은 무엇인가(장단점/한계)[^19]
  [= 답] HTML을 몰라도 Flutter/Dart 위젯만으로 화면을 만들 수 있고, 한 코드로 모바일/웹을 함께 가져갈 수 있다는 생산성 이점이 있으나, SEO/최적화/웹 생태계 라이브러리/교육자료/웹 접근성 등에서 제약이 있으며, Dart→웹 변환 과정에서 코드가 무거워질 수 있다.[^19]

• [? 질문] 반응형 웹을 구현하기 위해 가장 중요한 기준은 무엇이며, 어떤 폭 구간을 기준으로 삼는가[^36]
  [= 답] 기기 구분의 핵심은 **화면 폭(width)**이며, 예시 기준으로 모바일(~480 또는 767 이하), 태블릿(768~1024), PC(1024 이상) 같은 구간을 잡아 레이아웃을 바꾼다.[^36]

• [? 질문] “코드 푸시(code push)”로 앱도 웹처럼 실시간 업데이트할 수 있는가, 그리고 현실적 제약은 무엇인가[^16]
  [= 답] 가능은 하지만(특히 Google 쪽은 비교적 가능), iOS는 제약이 있고, 무엇보다 과금이 “업데이트 횟수”가 아니라 “설치(사용자 수) 기반”으로 커져 대중 앱에는 비용 부담이 크며, 소규모(인트라넷/회원수 적은 서비스)에 더 적합하다고 설명한다.[^16]

2. 큰 그림[^1]

이번 강의는 Flutter 중급 파트에서 Flutter Web을 염두에 두고, “여행사 홈페이지” 형태의 웹 UI를 Flutter로 구현하기 위한 사전 개념(플랫폼/배포/반응형/장단점)을 정리한 뒤, 다음 시간부터 들어갈 코딩 실습의 설계도를 제시한다.[^1] 또한 앱과 웹의 배포·운영 현실(심사, 리젝, 비용, 업데이트 지연)을 비교하며, Flutter로 웹을 선택했을 때의 의미를 실무 관점에서 짚는다.[^10]

• 멀티플랫폼 전략: Flutter는 모바일·PC·웹을 폭넓게 커버하며 “원 소스” 생산성을 강조한다.[^2] 다만 경쟁 크로스플랫폼(React Native, Xamarin/MAUI)과의 범위·한계 차이도 함께 언급한다.[^3]
• 배포/업데이트 현실: 웹은 서버 배포로 즉시 반영되는 반면, 앱은 스토어 심사/승인/리젝 때문에 업데이트에 시간과 운영 리스크가 생긴다.[^9] iOS 개발자 등록/심사 프로세스의 까다로움과 비용까지 구체적으로 설명한다.[^12]
• 반응형 설계의 핵심: 홈페이지는 PC/태블릿/모바일에서 봐야 하므로 화면 폭 기준으로 레이아웃이 변하는 반응형을 고려해야 하며, 실제로 만들 여행사 홈페이지도 폭에 따라 카드(추천 영역) 배치가 바뀌도록 설계한다.[^46]

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

3.1 오늘 만들 주제 예고: “여행사 홈페이지를 Flutter로”[^1]

강의자는 수업을 시작하며 “새로운 앱을 같이 살펴보자”는 흐름으로 들어가고, 이번 파트의 목표를 여행사의 홈페이지(웹 페이지) 형태로 만들겠다고 선언한다.[^1] 여기서 말하는 “홈페이지”는 단순히 모바일 앱 화면이 아니라, Flutter가 지원하는 **웹 빌드(HTML5 기반으로 브라우저에서 실행되는 형태)**를 염두에 둔 작업이라는 점을 뒤에서 분명히 한다.[^8]

또한 “여행사 홈페이지”라는 예제를 고른 이유는, 여행 서비스 UI가 흔히 가지는 구성(상단 로고/메뉴, 큰 배경 이미지, 예약/검색 입력 영역, 추천 카드 리스트 등)이 비교적 전형적이어서 웹 레이아웃 설계와 반응형 전환을 설명하기에 적합하기 때문이다.[^41]

[!NOTE] 이 강의의 포지션 이번 영상은 “바로 코딩”보다, 다음 시간 코딩을 위한 Flutter Web의 현실/장단점/반응형 개념/설계 방향을 정리하는 성격이 강하다고 강의자가 마무리에서 직접 말한다.[^48]

3.2 Flutter로 가능한 플랫폼 범위: 모바일·PC·웹[^2]

강의자는 Flutter의 가장 큰 특징으로 “개발 가능한 플랫폼이 매우 다양하다”는 점을 먼저 정리한다.[^2]

1. 모바일: Android, iPhone(iOS)[^2]
2. PC(데스크톱 앱): Windows(예: exe 설치형), Mac, Linux까지 가능하다고 언급한다.[^2]
3. 웹: 웹도 가능하며, 이 경우 “HTML 파일이 만들어진다”는 식으로 빌드 산출물 관점에서 설명한다.[^2]

강의자의 문제의식은 “지금까지 이렇게 다 되는(모바일+PC+웹을 폭넓게 포괄하는) 케이스가 흔치 않았다”는 것이고, 그 비교 대상으로 크로스 플랫폼/하이브리드 도구들을 이어서 소개한다.[^2]

3.3 크로스플랫폼/하이브리드 비교: React Native, Xamarin→MAUI, Flutter[^3]

강의자는 Flutter를 “하이브리드 개발 툴(크로스 플랫폼 개발 툴)” 범주와 함께 놓고, 대표 사례로 React Native, Xamarin, 그리고 Xamarin의 변화로 이어진 MAUI를 든다.[^3]

• React Native:
  원래 React는 웹 개발용이지만, 모바일 용도로 확장된 것이 React Native이며, 장점은 JavaScript로 모바일 앱을 만들 수 있다는 점이라고 설명한다.[^3]

• Xamarin → MAUI:
  MS 계열에서 만든 Xamarin이 버전업되며 “MAUI”라는 이름/프레임워크로 바뀌었다고 말한다.[^3]
  Xamarin의 역사도 함께 언급하는데, 원래는 오픈소스 기반의 독립 회사였고 “iPhone과 Android를 한 소스로 개발”한다는 점이 획기적이어서 주목받다가 MS에 인수되었다는 흐름으로 설명한다.[^4]

• 코드 재사용 비율(강의자 체감):
  강의자는 Flutter는 플랫폼 상관없이 소스가 **약 95% 정도 중복(재사용)**된다고 보며, Xamarin 계열은 그보다 조금 떨어져 약 80~90% 정도 수준으로 체감했다고 말한다.[^4]

• MAUI의 지향점:
  MS의 Windows UI 기술(WPF 등)과 섞이며 문법을 많이 바꾸고 호환성을 높이려 했다고 설명한다.[^5]

• 범위의 한계(강의자 주장):
  강의자는 “모바일+PC+웹을 모두 커버하는 건 현재 Flutter가 가장 확실하다”는 식으로 정리한다.[^6]
  또한 어떤 도구(문맥상 Xamarin/MAUI 계열을 지칭)가 “모바일만 된다(PC, 웹은 안 된다)”고 말하며, 플랫폼 커버리지의 차이를 강조한다.[^5]

3.4 왜 Flutter가 ‘독보적’이라고 보는가: 웹/하이브리드의 성능·구조 논점[^6]

강의자는 React Native 등도 가능하다고 보면서도, “완전한 네이티브냐” 관점에서 애매함이 있다고 말한다.[^6]
여기서 React Native를 포함한 “하이브리드 앱”을 설명하면서, 웹뷰(webview)처럼 HTML을 내장하는 방식을 예로 들고, 성능/지원이 “거의 99.9%”에 가깝지만 “정확히 말하면 100%는 아니다”라는 뉘앙스를 준다.[^6]

또한 과거에도 비슷한 “GUI 툴”들이 있었고(볼랜드(Borland) 사례, 터보 파스칼/델파이 언급), 사용자층 부족으로 쇠퇴한 역사도 짚는다.[^7] 이 대목은 “멀티플랫폼/크로스플랫폼 도구는 계속 등장해왔지만, 지금 시점의 Flutter는 그중에서도 범위와 커뮤니티가 강하다”는 분위기를 만드는 역할을 한다.[^7]

+++ 상세 예시: 볼랜드/델파이 언급이 왜 나오나 강의자는 20~30년 전의 개발 환경을 예로 들며, 터보 파스칼/델파이로 GUI 개발을 했던 시대가 있었고, 그런 계열의 도구도 결국 사용자층이 줄며 “지금은 거의 없어지다시피” 했다고 말한다.[^7] 이는 “플랫폼/툴의 흥망”을 보여주면서, Flutter가 살아남으려면 커뮤니티/지원/범용성이 중요하다는 맥락을 간접적으로 강화한다.[^7] +++

3.5 Flutter Web의 의미: HTML5 브라우저에서 실행, 그리고 ‘웹의 즉시 배포’ 장점[^8]

강의자는 Flutter가 웹도 지원하며, 한 소스코드로 HTML을 만들어 배포할 수 있고, 사용자는 크롬/엣지 등 HTML5 지원 브라우저로 접근해 볼 수 있다고 말한다.[^8] (Internet Explorer는 단종되었고 지원되지 않는 흐름도 함께 언급)[^8]

여기서 강의자는 웹을 여전히 선호하는 이유로 “웹페이지의 장점 = 실시간 업데이트”를 든다.[^9]

3.5.1 웹은 왜 실시간 업데이트가 쉬운가[^9]

웹은 “웹 서버에 소스만 배포하면 바로 반영”되므로, 앱처럼 심사를 거치지 않고 즉시 업데이트된다는 점을 강조한다.[^9]

3.5.2 앱 배포는 왜 느리고 운영 리스크가 큰가 (스토어 심사/승인/지연)[^9]

앱 배포 플랫폼은 크게 구글 플레이 스토어와 애플 앱스토어로 나뉘며, 심사/승인 시간이 발생한다는 점을 비교한다.[^9]

• 구글 플레이 스토어:
  처음 심사는 “하루~” 정도 걸릴 수 있고, 업데이트는 비교적 빠르다고 말한다.[^10]

• 애플 앱스토어:
  구글보다 더 복잡/까다롭다고 설명한다.[^11]

강의자는 본인의 경험 기반으로 업데이트 승인 시간이 “세네 시간 정도” 걸렸고, 승인 후에도 “배포 딜레이(웹에서는 보이는데 모바일에서 잠깐 안 보이는 시간 차)”가 약 30분 정도 있을 수 있다고 설명한다.[^10]

3.6 iOS 앱스토어의 추가 현실: 개발자 등록, 비용, 리젝(Reject), 그리고 일정 리스크[^11]

강의자는 앱스토어 쪽이 복잡한 이유를 “개발자 등록 단계부터” 설명한다.[^11]

3.6.1 개발자 등록 절차와 소요 시간[^11]

• 구글은 개발자 등록이 “간단하고 무료”에 가깝다고 말한다.[^11]
• 애플은 개발자 등록 심사 자체가 있고, 보통 1주~3주 걸릴 수 있다고 말한다.[^11]
• 심사에서 **리젝(탈락)**될 수 있으며, 리젝되면 다시 신청해야 해서 시간이 더 늘어진다고 경고한다.[^12]

3.6.2 개발자 등록 비용(연 단위)[^12]

애플 개발자 비용이 1년 단위 갱신이며, “대략 10만 원대(약 12~15만 원 사이)”라고 구체적으로 언급한다.[^12]

3.6.3 앱 최초 심사의 까다로움과 리젝의 반복 패턴[^13]

강의자는 “첫 심사 통과가 엄청 어렵다”고 말하며, 실무적으로 1~2개월 여유를 잡으라고 조언한다.[^13]
특히 iPhone/iPad(태블릿) 대응에서 “준비를 별도로 해야 한다”는 점을 강조한다.[^13]

또한 리젝이 발생하면:

• 짧으면 2~3일, 길면 1주일 소요될 수 있고[^13]
• 한 번에 모든 문제를 알려주는 게 아니라 “스텝별로 걸리면서” 고치라고 하므로[^14]
• 본인 경험으로 적게는 3~4번, 많게는 10번까지 리젝을 겪을 수 있다고 말한다.[^14]

3.6.4 운영 관점 결론: 배포는 신중해야 하고, 오류를 3일 안고 갈 수도 있다[^15]

동일 앱을 운영할 때, 앱스토어 업데이트 지연 때문에 “에러가 나면 3일 동안은 에러를 안고 갈 수밖에” 있는 상황이 생길 수 있어 배포에 신중해야 한다고 정리한다.[^15]

3.7 서버 기술에 따른 ‘웹 배포’ 방식의 차이: 스크립트 언어 vs 컴파일/재기동 필요[^15]

웹이 “바로 배포된다”고 해도 백엔드 기술에 따라 다르다고 덧붙인다.[^15]

• PHP 같은 스크립트 언어: 저장하면 바로 반영(실시간 업데이트에 가까움)[^15]
• Java, ASP 등: 컴파일/배포가 필요해서 서버를 내렸다 올리는 작업이 발생할 수 있고[^16]
  • 낮에 배포하면 로그인 사용자들이 튕기거나 서버가 내려가므로 새벽 배포를 하는 경우가 많다고 설명한다.[^16]

이 파트는 “웹도 무조건 무중단/즉시 반영은 아니며, 백엔드 운영 구조를 알아야 한다”는 실무적 맥락을 제공한다.[^16]

3.8 앱의 ‘실시간 업데이트’를 노리는 시도: Code Push의 개념과 비용 구조[^16]

강의자는 Flutter 쪽에서 “앱도 실시간 업데이트처럼” 만들려는 움직임이 있고, 그 대표가 **코드 푸시(Code Push)**라고 소개한다.[^16]

3.8.1 코드 푸시란 무엇인가[^16]

• 사용자의 폰에 앱을 한 번 설치해두고[^16]
• 변경 사항이 생기면 스토어 심사를 거치지 않고 서버에 올려두면[^16]
• 앱이 자동으로 업데이트되도록 하는 방식이라고 설명한다.[^16]

3.8.2 플랫폼별 이슈: 구글은 상대적으로 가능, iOS는 제약/문제가 남아 있음[^17]

현 시점(강의자 언급: “2023년 9월”로 들림)에서 구글은 그나마 되지만, iOS는 아직 문제가 있다고 말한다.[^17]

3.8.3 비용이 왜 문제인가: ‘업데이트 횟수’가 아니라 ‘설치/사용자 수’ 기반[^17]

강의자는 코드 푸시가 유료 서비스이며 “비싸지 않다”고 하면서도, 곧바로 과금 기준이 애매하고 위험하다고 설명한다.[^17]

• 예시로 “4천 번 배포에 5만 원 정도” 같은 식으로 말하지만[^17]
• 핵심은 “4,000번이 업데이트 횟수가 아니라 **설치 횟수(사용자 수)**에 걸린다”는 점이라고 강조한다.[^17]
• 따라서 고객(사용자)이 4만 명이면, 업데이트 한 번에 큰 비용(예: 50만 원)이 나갈 수 있어 감당이 어렵다고 한다.[^17]
• 회원 1만 명이면 업데이트 1회마다 10만 원씩 깨질 수 있다는 식으로, 대중 서비스에서는 부담이 커진다고 설명한다.[^18]

3.8.4 어느 경우에 현실적으로 쓸 만한가: 소규모/인트라넷[^18]

강의자는 코드 푸시가 다음 같은 경우에는 가능성이 있다고 본다.[^18]

• 병원 내부 환자 진료용 앱 같은 인트라넷/내부용[^18]
• 회원수가 500~1,000명 정도인 소규모 유료 서비스[^18]

반면 불특정 다수 대상의 일반 앱은 비용 구조상 문제를 일으킬 수 있다고 결론낸다.[^18]

3.9 “Flutter로 홈페이지를 만들 수 있나?”에 대한 답: 가능하지만 무게/복잡성 이슈[^19]

강의자는 본론 질문으로 돌아와, Flutter로 홈페이지(웹)를 만들 수 있는지에 대해 “만들 수 있다”고 답한다.[^19]

다만 직접 해보니 “약간 무거운 점”이 있다고 말한다.[^19]

• 이유: 개발자가 HTML을 직접 쓰는 게 아니라 Dart/Flutter 코드로 작성하면, 그것이 웹 산출물로 변환되는 과정에서 코드가 복잡해지고[^19]
• 많은 부분이 스크립트(자바스크립트로 변형된다고 표현)로 바뀌며[^19]
• 불필요한 코드가 덕지덕지 붙어 무거워질 수 있다는 것이다.[^20]

그럼에도 불구하고 큰 장점을 하나로 압축해 강조한다:

• HTML/화면 디자인 지식이 없어도, Dart 문법과 Flutter 코드만으로 화면을 “똑같이” 만들 수 있다는 점.[^20]

강의자는 “HTML 10줄 쓰는 것보다 Dart 20줄이 더 편할 수 있다”는 식으로, 특히 레이아웃 잡는 부분에서 Flutter 위젯 기반 설계가 오히려 편해질 수 있다고 말한다.[^20]

또한 복잡한 대규모 웹사이트는 결국 HTML 기반 전문 접근이 유리할 수 있지만, 간단한 한 페이지/서너 페이지짜리이고 HTML이 능숙하지 않다면 Flutter로도 충분히 만들 수 있다고 정리한다.[^20]

3.10 Flutter로 웹(홈페이지)을 만들 때의 장점들: 원코드, 생산성, 핫 리로드, 위젯 재사용, 반응형, 커뮤니티 등[^20]

강의자는 “Flutter로 홈페이지를 만들 때 장점이 뭐냐”를 항목처럼 이어간다.[^20]

3.10.1 원 코드베이스(단일 코드)로 모바일/웹을 함께 가져갈 수 있음[^21]

• “모바일 앱도 바로 만들 수 있고, 웹에도 그대로 옮길 수 있다”는 점을 매우 큰 장점으로 든다.[^21]
• 그래서 생산성이 올라간다고 연결한다.[^21]

3.10.2 웹에서도 핫 리로드 지원 (코드 변경 즉시 화면 확인)[^21]

• Flutter의 강점인 핫 리로드가 웹에서도 된다고 말한다.[^21]
• 브라우저를 옆에 띄워놓고 Dart 코드를 바꾸면서 디자인 변경을 실시간 확인 가능하다고 설명한다.[^21]

3.10.3 웹 접근성(여기서는 “위젯을 웹에 그대로 적용 가능” 의미로 사용)[^21]

강의자는 “웹 접근성”이라는 표현을, HTML을 몰라도 Flutter 위젯(버튼, 텍스트필드 등)을 그대로 웹에 적용할 수 있다는 의미로 우선 설명한다.[^21]
즉, 기존에 배운 위젯들을 웹에서도 동일하게 재사용할 수 있다는 요지다.[^21]

3.10.4 반응형(Responsive) 디자인: 폭에 따라 레이아웃이 변하는 설계[^22]

반응형 디자인을 별도로 정의하면서:

• 화면 크기(정확히는 화면 폭)에 따라 레이아웃/디자인이 변형되는 것[^23]
• 모바일/태블릿/PC에서 각각 보기 좋도록 배치가 바뀌어야 한다는 점을 설명한다.[^23]

그리고 강의 진행 중 해상도 때문에 화면이 잘 안 보일 수 있어 폰트를 키우는 등, 실습 환경(원격/외부 환경) 이슈를 잠시 언급한다.[^22]

3.10.5 SEO 지원(검색엔진 최적화): “있긴 하지만 점수가 높진 않다”[^26]

강의자는 SEO를 “키워드” 같은 개념으로 설명하면서, Flutter Web의 SEO는 “그닥 좋지는 않다”, “50점 정도”라는 표현으로 제한을 인정한다.[^26]

3.10.6 네이티브 성능, 다양한 기능/서드파티, 오픈소스/커뮤니티, 발전 가능성[^26]

• 성능은 네이티브 100%는 아니지만 네이티브 성능에 가깝게 낼 수 있다는 취지로 말한다.[^26]
• Flutter 내부 기능(비동기 통신, 부분 갱신 등)과 외부 오픈소스/서드파티 라이브러리가 많다는 점을 강조한다.[^27]
• 커뮤니티가 활성화되어 있고, 국내도 원코드 모바일 개발의 이점 때문에 사용자들이 늘고 있다고 말한다.[^27]
• 구글이 대대적으로 밀고 있어 결제 시스템 등도 Flutter로 많이 바뀌는 흐름을 언급하며 “발전 가능성”을 든다.[^28]

3.10.7 (확장 전망) Dart/Flutter의 백엔드까지 통합하려는 움직임[^28]

강의자는 아직 해보진 않았지만, Flutter/Dart가 프런트엔드에 그치지 않고 “백엔드까지 통합”하려는 움직임이 있다고 말한다.[^28]

다만 현실적 부족 요소도 함께 든다:

• 백엔드에서 중요한 DB 커넥터는 오라클, MS 같은 DB 벤더가 Dart용 제공을 적극적으로 하지 않아 100% 기능을 쓰기 어렵다고 설명한다.[^29]
• 그래서 아직은 부족하지만, 사용자층이 커지면 언젠가 제공될 수도 있다는 전망을 덧붙인다.[^29]

3.11 Flutter Web의 한계/단점: SEO/최적화(쓰레기 코드)/라이브러리/교육자료/동적 웹/접근성 요구 대응[^29]

강의자는 장점 다음에 “한계도 있다”고 전환하고, 항목별로 단점을 나열한다.[^29]

3.11.1 SEO는 HTML만큼은 어렵다 (외부 SEO 툴 미지원)[^30]

• HTML만큼 SEO가 잘 되지 않는다고 말한다.[^30]
• SEO 최적화는 보통 외부 라이브러리/유료 툴을 쓰는데, 그런 툴들이 Flutter를 지원하지 않는 경우가 있어 어렵다고 설명한다.[^30]

3.11.2 최적화의 어려움: Dart→HTML(웹 산출물) 변환 과정의 “쓰레기 코드”[^30]

• Dart 코드가 자동 변환되면서 “쓰레기 코드”가 들어가고 코드가 무거워진다고 말한다.[^30]
• 이것은 구조상 어쩔 수 없는 측면이라고 정리한다.[^30]

3.11.3 웹 라이브러리 생태계 대비 부족 + (중요) 모바일 위주 라이브러리의 웹 미지원[^31]

• 웹에는 좋은 라이브러리가 많지만, Flutter Web은 상대적으로 부족하다는 요지다.[^31]
• “없다는 게 아니라 많긴 한데”라고 균형을 잡으며[^31]
• 특히 pub.dev 등 Flutter 생태계의 라이브러리 중 웹을 지원하지 않는 것들이 많다고 지적한다.[^31]

3.11.4 교육 자료 부족: Flutter Web을 전용으로 쓰는 사례가 아직 많지 않음[^31]

강의자는 “이게 사실 제일 문제”라고 하며, Flutter로 웹을 ‘전용’으로 사용하는 일이 아직 많지 않아 자료가 부족하다고 말한다.[^31]

3.11.5 호환성 문제는 과거보다 덜 걱정(HTML5 엔진 기반)[^32]

강의자는 호환성은 크게 걱정하지 않아도 된다고 말한다.[^32]
HTML5 규격을 지원하는 브라우저(웹 엔진)면 동작하는 흐름으로 설명한다.[^32]

3.11.6 동적 웹페이지 요소: jQuery 같은 의존 요소를 못 쓰는 이슈[^32]

강의자는 “동적 웹페이지”를 구현할 때, 외부에서 흔히 쓰는 jQuery가 있는데 “그게 지원이 안 된다”는 취지로 설명한다.[^32]
그래서 외부 연동/동적 처리에서 어려움이 있을 수 있다는 식으로 말한다.[^32]

3.11.7 (의미의) 웹 접근성 요구: 장애인 접근성(스크린리더 등)과 Flutter의 대응: Semantics[^33]

앞에서는 “위젯 재사용”을 웹 접근성처럼 말했지만, 여기서는 발주/요구사항에서 말하는 진짜 의미의 “웹 접근성(Accessibility)”을 설명한다.[^33]

• 발주 측이 “웹 접근성 코딩을 해달라” 요구할 수 있고[^33]
• 시각/청각 등 장애가 있는 사용자의 접근을 고려해야 한다고 말한다.[^33]
• Flutter는 전통적인 웹 접근성 구현처럼 완전하진 않지만, 최근에는 Semantics 같은 방식으로 개선 중이라고 설명한다.[^34]

Semantics 설명의 핵심 흐름:

• 텍스트/라벨/이미지 등에 “의미(semantic) 문자/라벨”을 넣어주면[^34]
• 이미지가 표시될 때 그 의미가 텍스트로도 제공되고[^34]
• 시각이 불편한 사용자는 이를 음성으로 “읽어” 도움을 받을 수 있다는 것이다.[^34]

3.12 이번 실습 목표: 여행사 홈페이지를 ‘반응형 웹’으로 설계하기[^34]

강의자는 이제 실제 만들 대상(여행사 홈페이지)을 다시 꺼내며, 이 홈페이지가 노출될 환경을 열거한다.[^35]

• PC 웹브라우저[^35]
• 모바일 웹브라우저[^35]
• 태블릿 웹브라우저[^35]
• (앱이라면) 플레이스토어/앱스토어 배포까지도 가능하지만, 이번에는 “웹”을 한다고 정리한다.[^35]

그리고 이런 구분의 기준은 “간단하게 말하면 화면 사이즈”라고 강조한다.[^36]

3.13 반응형 폭 기준 예시: 모바일/태블릿/PC 구간과 설계 기준 폭[^36]

강의자는 반응형 웹 디자인에서 흔히 쓰는 폭 기준 예시를 제시한다.[^36]

• 모바일: 폭이 대략 320~480, “500 미만이면 모바일로 보면 된다”는 식으로 설명[^37]
• 태블릿: 768~1024 구간으로 제시[^37]
• PC: 1024 이상이면 PC로 간주[^37]

또한 “미디어 쿼리에서 따온 기준”이라고 말하며,

• 최소 폭 1024 이상이면 PC[^38]
• 768 이상이면 태블릿[^38]
• 767 이하이면 모바일[^38] 같은 형태의 구간 나눔을 설명한다.[^38]

다만 이 기준이 100% 맞지 않는 이유로 갤럭시 폴드 같은 폴더블 기기의 “비율 문제”를 든다.[^39]

3.13.1 폴더블(갤럭시 폴드)로 인한 반응형의 난점: ‘폭/비율’이 기존 가정과 다름[^39]

강의자는 폴더블은 폭이 짧고 거의 정사각형에 가까운 비율이라, 기존 기준으로 UI를 만들면 버튼이 안 보이거나 팝업이 가려지는 등 문제가 생길 수 있다고 말한다.[^39]
과거에는 긴 직사각형 비율을 가정해 “팝업이 떠도 괜찮았는데”, 폴드처럼 비율이 바뀌면 기준을 잘못 잡으면 UI가 망가진다는 것이다.[^40]

결론적으로:

• 모든 케이스를 사전에 완벽히 커버할 수는 없고[^40]
• 배포/테스트 과정에서 여러 기기에서 실제 테스트해보는 수밖에 없다고 조언한다.[^40]
• 특히 안드로이드는 해상도가 너무 다양하다고 강조한다.[^40]

또한 웹이라 해도 모바일로 보는 사용자가 많으니, 웹페이지를 만들 때도 모바일을 꼭 염두에 두라고 강조한다.[^41]

3.14 여행사 홈페이지 UI 레퍼런스 분석: 공통 구성요소와 “에어비앤비 스타일 입력란” 포인트[^41]

강의자는 국내/해외 여행 관련 사이트 레퍼런스를 여러 개 가져와 공통적인 룰(패턴)을 설명한다.[^41]

3.14.1 상단 구조의 공통 룰: 로고 → 메뉴 → 큰 이미지(히어로 섹션)[^41]

전형적인 패턴으로:

• 회사 로고가 상단에 있고[^41]
• 상단에 메뉴가 가로로 배치되고[^41]
• 큰 배경 이미지(히어로 이미지)를 “빵” 깔아주며[^41]
• 일정/검색이 중요한 서비스는 검색/예약 입력 UI를 전면에 배치하는 흐름을 설명한다.[^42]

3.14.2 본문 구조: 추천 상품/추천 장소 카드, 사용자 평가/장점 나열[^42]

히어로 섹션 아래로는:

• 추천 콘텐츠(추천 여행지/상품) 이미지/카드가 이어지고[^42]
• 사용자 평가/타이틀/장점 나열 등 반복 요소가 배치된다고 설명한다.[^42] 강의자는 “대부분 요소가 비슷하다”고 정리한다.[^42]

3.14.3 구현 포인트로 찍은 UI 디테일: ‘라벨+값/힌트가 한 덩어리인 입력란’[^42]

강의자는 특히 최근 디자인 트렌드로, 에어비앤비 같은 서비스에서 많이 쓰는 입력란 형태를 짚는다.[^42]

• 예전/전통적 형태: 타이틀(라벨)이 위에 있고 입력란이 따로 있는 구조[^43]
• 강조하는 형태: 하나의 입력 박스 안에서
  • 위/좌측에 라벨이 있고
  • 그 아래/안쪽에 실제 데이터 또는 힌트 텍스트가 들어가는 구성[^43]

강의자는 “우리가 앞에서 바로 했던 형태”라고 연결하며, 이번 여행사 홈페이지에서도 이 입력 형태(예약/체크인 등)를 구현해보겠다고 말한다.[^43]

3.15 이번에 만들 화면 설계 스케치: 상단 메뉴 + 배경 + 예약 입력 + 추천 카드, 그리고 모바일 전환[^44]

강의자는 직접 펜으로 화면을 스케치하며, 구현할 레이아웃을 단계적으로 그려 설명한다.[^44]

3.15.1 PC(넓은 화면)에서의 기본 레이아웃[^45]

강의자가 그린 구조는 다음 흐름이다.[^45]

1. 상단 바(헤더)

   • 로고 배치[^45]
   • 메뉴들이 가로로 쭉 배치[^45]

2. 히어로 영역

   • 배경 이미지 크게 배치[^45]

3. 예약/상태 입력 영역(에어비앤비 스타일 입력 UI)

   • 히어로 영역 위/내부에 예약 관련 입력 UI를 올리는 형태로 설명[^45]

4. 추천 영역(카드/리스트 반복)

   • 추천 컨텐츠가 여러 개 카드 형태로 반복[^46]
   • 각 추천 카드에는 타이틀/광고/사용자 데이터/별점 등이 들어갈 수 있다고 설명[^46]

3.15.2 모바일(좁은 화면)에서의 반응형 전환 목표[^46]

강의자는 PC에서는 추천 카드들이 가로로 여러 개 보일 수 있지만, 모바일로 폭이 줄면 그렇게 두면 “작아져서 안 보인다”고 말한다.[^46]

그래서 폭에 따라:

• PC: 한 줄에 여러 카드(가로 나열)[^46]
• 모바일: 한 줄에 하나씩 내려오는 형태(세로 스택)[^46]

로 자동 변환되는 “반응형”을 만들겠다고 한다.[^46]
이렇게 만들어 HTML로 배포하면, 모바일/PC 어느 환경에서든 반응형 웹으로 볼 수 있어 “Flutter 하나로 홈페이지도 만들 수 있다”고 결론을 잇는다.[^47]

다만 강의자는 “아주 복잡하고 무거운 웹은 권장하지 않는다”고 선을 긋고, “어지간한 건 만들 수 있다”는 현실적 표현을 쓴다.[^47]

또한 이런 홈페이지가 특히 적합한 영역으로, 단순히 보여주는 정적 페이지보다는:

• 설문조사, 인트라넷 같은 계산/로직이 들어가고[^47]
• 예약/조회/DB 연동 등 코딩 중심 기능이 있는 웹앱 성격이 더 잘 맞는다고 조언한다.[^47]

3.16 다음 시간 예고: 폭 읽기, 웹 스타일 지정, HTML 태그(H1~H6) 흉내내기 등 코딩으로 연결[^48]

강의자는 이번 시간은 Flutter Web 개발을 위해 필요한 것들과 현재 상황을 전반적으로 설명했다고 정리한다.[^48]

그리고 다음 시간부터는 코딩 실습으로 들어가며, 다음 주제를 다루겠다고 예고한다.[^48]

• 화면의 폭을 읽어오는 방법(반응형의 핵심 재료)[^48]
• 웹에서 쓰던 폰트 사이즈 지정 등 jQuery식으로 하던 스타일 제어 느낌을 Flutter에서 어떻게 할지[^48]
• HTML에서 자주 쓰는 태그(예: H1 ~ H6)를 Flutter에서 “비슷하게 흉내” 내는 방식[^48]

마지막으로 잠깐 쉬었다가 다음 시간에 이어서 실습을 계속하겠다고 인사하며 영상을 마친다.[^49]

4. 핵심 통찰[^1]

1. Flutter Web은 “웹 전용 기술”을 대체한다기보다, Flutter 위젯/코드 자산을 웹으로 확장하는 관점에서 생산성 이점을 만든다.[^20]

   • 웹 레이아웃이 익숙하지 않은 개발자에게는 “HTML 10줄 vs Dart 20줄”처럼 오히려 Flutter가 편해질 수 있다는 논리를 제공한다.[^20]

2. 앱/웹의 선택은 UI 문제가 아니라 배포/운영 체계의 차이가 크다.[^9]

   • 특히 iOS는 개발자 등록부터 심사, 비용, 리젝 반복으로 인해 일정/운영 리스크가 커질 수 있다는 점을 구체적 기간/비용으로 체감시키는 구성이다.[^12]

3. 반응형의 본질은 “기기 종류”가 아니라 화면 폭(width)에 따른 레이아웃 변환이다.[^36]

   • 예시 구간(모바일/태블릿/PC)을 제시하면서도 폴더블 같은 예외가 있어 실기기 테스트가 필수라는 결론으로 이어진다.[^40]

4. “코드 푸시”는 앱 업데이트 지연을 해결할 수 있는 매력적인 아이디어지만, 과금 단위가 사용자 수로 커질 때 대중 서비스에서는 현실성이 급격히 떨어질 수 있다.[^17]

   • 실행 시사점: 조직 내부 앱/소규모 회원 서비스처럼 사용자 수가 제한된 환경에서 우선 검토하는 것이 합리적이라는 방향성을 준다.[^18]

5. Flutter Web의 한계는 단순히 “기능이 부족”이 아니라, (1) Dart→웹 변환에 따른 번들 무게/최적화, (2) 웹 생태계의 방대한 도구 대비 SEO/라이브러리/교육자료의 갭이라는 “생태계 격차”로 설명된다.[^30]

• 실행 관점 체크리스트(강의 내용에서 자연스럽게 도출)
  • 웹으로 갈 때는 SEO 요구 수준을 먼저 확인한다.[^30]
  • 목표 UX가 반응형이면 폭 구간을 잡되, 폴더블 등 예외 기기까지 고려해 테스트 플랜을 포함한다.[^40]
  • 웹앱 성격(예약/조회/DB/로직)이 강하면 Flutter Web의 강점이 더 살아날 수 있다.[^47]

5. 헷갈리는 용어 정리[^16]

• 하이브리드(크로스플랫폼) 개발 툴: 하나의 코드로 여러 플랫폼(모바일/웹/PC 등)을 동시에 지원하려는 개발 도구/프레임워크를 통칭하는 강의자의 용어 사용.[^3]
• React Native: JavaScript(React) 기반으로 모바일 앱을 만드는 크로스플랫폼 프레임워크로 소개.[^3]
• Xamarin(자마린): iOS/Android를 한 소스로 개발하는 MS 계열 도구로 설명되며, 이후 MAUI로 변화했다고 언급.[^3]
• MAUI(마우이): Xamarin이 버전업되며 바뀐 크로스플랫폼 프레임워크로 소개.[^3]
• 핫 리로드(Hot reload): 코드를 수정하면 결과를 실시간으로 확인하는 Flutter의 개발 생산성 기능이며, 웹에서도 지원된다고 설명.[^21]
• 반응형 디자인(Responsive design): 화면 폭(디바이스 크기)에 따라 레이아웃이 변형되는 설계.[^23]
• SEO(Search Engine Optimization): 검색 엔진 최적화. 강의에서는 키워드/검색 노출 최적화 맥락으로 설명.[^26]
• 코드 푸시(Code Push): 스토어 심사 없이 서버에서 변경분을 내려 앱을 업데이트하는 방식으로 소개(유료, 사용자 수 기반 비용 이슈 언급).[^16]
• 웹 접근성(Accessibility): 장애(시각/청각 등)를 가진 사용자의 접근을 보장하기 위한 요구사항으로 설명.[^33]
• Semantics(시멘틱/세멘틱): 이미지/텍스트 등에 의미 라벨을 부여해 스크린리더가 읽을 수 있게 돕는 Flutter 측 접근성 지원 개념으로 소개.[^34]

---

참고(콘텐츠 정보)[^1]

• 제목: [Flutter] 모바일 앱 개발자를 위한 Flutter(플러터) 제대로 배우기 Part.3 중급 2[^1]
• 채널: 아이티동스쿨[^1]
• 길이: 49분 27초[^1]
• 링크: https://www.youtube.com/watch?v=-Ovbu3NnkRg[^1]
• 키워드(제공됨): 플러터배우기, 플러터공부, FLUTTER강의, 플러터인강, FLUTTER앱개발, 플러터강좌, FLUTTER교육, FLUTTER공부, 플러터강의, 플러터[^1]

각주[^1]

[^1]: @[00:09] “오늘은요… 새로운 앱… 살펴보려” + @[00:26] “오늘은 여행사의 홈페이지를 만들려 그래요” + 영상 메타(제목/채널/길이/링크) 제공 본문 [^2]: @[00:59]~@[02:02] “플러터로 개발할 수 있는 플랫폼… 모바일(안드로이드/아이폰)… PC(윈도우/맥/리눅스)… 웹… html 파일” [^3]: @[02:12]~@[03:42] “하이브리드… 리액트 네이티브… 자마린… 마우이… 크로스 플랫폼” [^4]: @[04:00]~@[05:09] “자마린… 독립 회사… MS에 팔림… 플로터는 95% 중복… 자마린은 80~90%” [^5]: @[05:14]~@[05:57] “WPF… 섞여 나온 게 마우이… 모바일만… PC 안 되고 웹도 안 돼요” [^6]: @[06:07]~@[06:41] “모바일도 되고 PC도 되고 웹도… 현재는 플로터밖에 없어요… 리액트 네이티브… 웹뷰… 100%는 아니다” [^7]: @[07:04]~@[07:46] “볼랜드… 터보 파스칼… 델파이… 사용자층 적어서…” [^8]: @[08:07]~@[08:53] “한 소스 코드로 html 만들어… 크롬/엣지… 익스플로어 안 되고… html5 기반 브라우저” [^9]: @[09:10]~@[09:39] “홈페이지 장점… 실시간 업데이트… 웹 서버에 소스만 배포하면 바로” [^10]: @[09:47]~@[11:13] “구글 플레이… 처음 심사 하루… 업데이트… 세네시간… 배포 딜레이 30분” [^11]: @[11:20]~@[12:00] “앱스토어… 더 복잡… 개발자 등록… 1주~3주” [^12]: @[12:10]~@[12:50] “리젝… 다시 신청… 비용… 1년 단위… 12~15만 원” [^13]: @[13:01]~@[13:59] “앱 심사… 훨씬 까다로워… 1~2개월 여유… 아이패드 별도 준비… 리젝 후 2~3일~1주” [^14]: @[14:03]~@[14:29] “한 방에 안 알려 줘요… 스텝 계속… 서너 번~열 번 리젝” [^15]: @[15:03]~@[15:20] “에러 났을 때 3일 동안 안고… 배포 신중… 웹은 바로 배포” [^16]: @[15:31]~@[16:21] “자바/ASP… 서버 내렸다 올려… 새벽 배포” + @[16:43] “코드 푸시” [^17]: @[17:02]~@[17:54] “아이폰은 문제… 유료… 4천번 배포 5만 원… 설치 횟수… 4만 명이면 50만 원” [^18]: @[18:05]~@[18:42] “인트라넷/병원… 회원 500~1000… 대중 앱은 비용 감당 안 돼… 만 명이면 10만 원” [^19]: @[19:01]~@[19:59] “홈페이지 만들 수 있냐… 만들 수 있어… 약간 무거움… 다트 코드가 변환… 코드 복잡… html 몰라도…” [^20]: @[20:08]~@[20:47] “html 10줄 vs 다트 20줄… 레이아웃… 한 페이지/서너 페이지… 플러터로” [^21]: @[20:57]~@[22:00] “단일 코드… 모바일 앱… 웹… 생산성… 핫 리로드… 웹도 된다… 위젯 그대로” [^22]: @[22:27]~@[23:13] “반응형 디자인… 해상도 올려서 안 보임… 폰트 키움” [^23]: @[23:16]~@[23:56] “반응형… 화면 폭에 따라 디자인 변형… 모바일/태블릿/PC” [^24]: @[24:02]~@[25:44] “플랫폼별 디자인… m. 네이버… 점프… 반응형 복잡… 다시 플랫폼별로” [^25]: @[26:00]~@[26:13] “화면 사이즈 읽어내는 기능… 반응형 연구” [^26]: @[26:13]~@[27:01] “SEO… 50점… 네이티브 성능…” [^27]: @[27:01]~@[27:54] “비동기… 부분 갱신… 서드파티/오픈소스… 커뮤니티… 국내 증가” [^28]: @[28:01]~@[29:09] “구글이 밀고… 결제 시스템… 백엔드까지 통합 움직임” [^29]: @[29:14]~@[29:46] “DB 커넥터… 오라클/MS… 다트용 제공 부족… 한계” [^30]: @[29:52]~@[30:57] “SEO 한계… 외부 툴 지원 안 해… 자동 컨버트… 쓰레기 코드… 무거워짐” [^31]: @[31:03]~@[32:11] “웹 라이브러리 대비 부족… 웹 지원 안 하는 오픈소스… 교육 자료 부족…” [^32]: @[32:15]~@[33:04] “호환성… html5 지원이면… 동적 웹페이지… 제이쿼리 지원 안 됨” [^33]: @[33:10]~@[33:48] “웹 접근성 코딩 요구… 장애인… 시각/청각…” [^34]: @[34:00]~@[34:34] “시멘틱… 의미 문자… 이미지에… 읽어 줌… 지원” [^35]: @[35:04]~@[35:57] “여행사 홈페이지… PC/모바일/태블릿… 스토어… 이번은 웹” [^36]: @[36:02]~@[36:52] “구분은 화면 사이즈… 폭… 기준” [^37]: @[36:55]~@[37:38] “모바일 320~480… 500미만 모바일… 태블릿 768~1024… 1024 이후 PC” [^38]: @[37:47]~@[38:47] “미디어 쿼리… 1024 이상 PC… 768 이상 태블릿… 767 이하 모바일” [^39]: @[39:03]~@[39:50] “갤럭시 폴드… 비율 안 맞음… 정사각형에 가까움… 버튼 안 보임” [^40]: @[39:58]~@[40:57] “기준 잡으면 UI 망가짐… 여러 기기 테스트… 안드로이드 해상도 다양” [^41]: @[41:01]~@[41:27] “모바일 생각하면서 웹페이지… 레퍼런스 가져옴” [^42]: @[41:39]~@[42:42] “로고… 메뉴… 큰 이미지… 검색/예약… 추천… 사용자 평가… 요소 비슷” [^43]: @[42:48]~@[43:40] “에어비앤비 디자인… 입력란… 라벨+힌트/데이터… 구현해보려” [^44]: @[44:00]~@[45:07] “대충 이렇게… 펜… 스케치 준비” [^45]: @[45:19]~@[46:12] “로고/메뉴… 배경 이미지… 예약 상태 입력 UI 배치” [^46]: @[46:17]~@[47:11] “추천 영역 반복… 모바일에선 한 줄에 하나… 폭에 따라 레이아웃 변경” [^47]: @[47:13]~@[47:59] “HTML 배포… 반응형… 복잡/무거운 건 비권장… 예약/조회/DB 연동에 좋다” [^48]: @[48:16]~@[48:56] “이번 시간은 전반 설명… 다음 시간 폭 읽기… 폰트 사이즈 지정… H1~H6 흉내” [^49]: @[49:05]~@[49:23] “쉬었다가… 다음 시간 이어서… 감사합니다”