Lecture · Web Architecture

Flask vs Streamlit,
실무에서 어떻게 고르는가

프레임워크 선택은 기능 목록 비교가 아니라 제품의 본질에 대한 질문에서 시작합니다. 답이 명확하면 나머지는 따라옵니다.

핵심 질문 하나로 분기
"UI 자체가 제품인가, 데이터/분석이 제품인가?"
Flask Streamlit Python REST API Chart.js
01

핵심 질문 — 무엇이 제품인가

decision framework

두 프레임워크는 경쟁 관계가 아니라 서로 다른 제품을 위한 도구입니다. UI 자체가 사용자에게 전달되는 가치라면 프론트엔드를 직접 통제하는 Flask가, 데이터와 분석 로직이 가치이고 UI는 전달 수단일 뿐이라면 Streamlit이 맞습니다.

이 질문에 대한 답이 명확하지 않다면 아직 프레임워크를 고를 단계가 아닙니다 — 제품 정의부터 다시 하세요.
02

두 갈래의 구조

flask · streamlit
적합한 상황
  • 공개 서비스 — 불특정 다수 접근
  • 디자인·브랜딩이 중요한 경우
  • 복잡한 폼, 사용자 인증, 권한 체계 필요
  • 다른 팀원이 프론트를 따로 개발 (API 분리)
  • 드래그앤드롭, 커스텀 애니메이션 등 특정 인터랙션
개발자가 관리해야 할 것
# 개발자 책임
├── 라우팅 설계 (URL 구조)
├── HTML/CSS/JS 직접 작성
├── REST API 설계
├── 세션/인증 관리
└── 배포 구성 (nginx, gunicorn 등)
Trade-off — 자유도 높음 → 결정할 것도 많음. 프론트 작업량이 백엔드만큼 따라옵니다.
적합한 상황
  • 내부 도구 — 팀, 부서 단위 사용
  • 데이터 분석가·엔지니어가 혼자 만들고 혼자 씀
  • 빠른 프로토타입 → 이해관계자 시연
  • 분석 결과를 인터랙티브하게 보여주는 것이 목적
  • UI보다 로직·데이터가 핵심인 경우
개발자가 관리해야 할 것
# 개발자 책임
├── Python 로직
├── st.widget() 배치
└── 데이터/시각화

HTML/CSS/JS · REST API · 라우팅 — 없음
Trade-off — 빠른 개발 → UI 커스터마이징 한계. Streamlit이 전체 실행 흐름을 제어합니다 (re-run 모델).
03

실무 결정 체크리스트

interactive

다섯 가지 질문에 답하면 아래 판정이 실시간으로 갱신됩니다. 프로젝트를 하나 떠올리고 눌러 보세요.

Q1
사용자가 누구인가?
Q2
UI 커스터마이징이 필요한가?
Q3
인증/권한이 복잡한가?
Q4
누가 만드는가?
Q5
속도 vs 완성도?
Verdict
질문에 답하면 판정이 나타납니다.
FlaskStreamlit
04

사례 분석 — parts_cycle_dashboard

case study
기준현재 상태판단
사용자본인 + 내부Streamlit 유리
UI 디자인Chart.js 직접 작성 중이미 Flask의 수고를 하고 있음
인증없음Streamlit 유리
공개 여부sielain.com에 붙이려는 중공개면 Flask 유지도 고려
개발자혼자Streamlit 유리
결론 — 분석·시각화 중심의 내부 도구라면 Streamlit 전환이 맞습니다. 단, sielain.com에 공개 노출하면서 디자인 통일감이 중요하다면 Flask + 서브도메인 유지도 합리적인 선택입니다.