Streamlit을 쓰면서 느낀 점들

한동안 웹 프레임워크로 Streamlit을 자주 사용했다. 처음에는 가볍게 화면 하나를 띄워보는 정도로 시작했는데, 쓰면 쓸수록 이 도구가 가진 성격이 꽤 분명하다는 생각이 들었다. 아주 빠르게 만들 수 있고, 생각을 곧바로 결과물로 바꿀 수 있다는 점에서 매력적이다. 동시에 그 속도에 익숙해질수록 어디까지를 Streamlit으로 해결하고, 어디서부터는 다른 선택을 해야 하는지도 점점 더 또렷하게 보이기 시작했다.

내가 Streamlit에서 가장 좋게 본 점은 진입 장벽이 낮다는 것이다. 파이썬을 쓰는 사람이라면 복잡한 프론트엔드 지식 없이도 금방 화면을 만들 수 있다. 데이터프레임을 보여주고, 입력창을 만들고, 버튼을 달고, 결과를 다시 출력하는 흐름이 매우 직관적이다. 무엇보다 아이디어를 떠올린 뒤 실제로 동작하는 형태로 옮겨가는 시간이 짧다. 이 점은 생각보다 중요하다. 어떤 도구는 구현에 들어가기 전부터 구조와 설정에 너무 많은 에너지를 요구하는데, Streamlit은 일단 만들어보게 한다.

이 장점은 특히 개인 프로젝트나 내부용 도구에서 크게 드러난다. 분석 결과를 빠르게 공유해야 하거나, 작은 실험용 인터페이스가 필요하거나, 누군가에게 개념을 보여주기 위한 프로토타입이 필요한 경우 Streamlit은 매우 강력하다. 완성도 높은 제품이 아니어도 괜찮은 상황에서는 생산성이 압도적으로 높다. 한 사람이 짧은 시간 안에 눈에 보이는 결과를 만들 수 있다는 점은 분명한 장점이다.

또 하나 좋았던 점은 파이썬 생태계와의 연결이 자연스럽다는 것이다. 데이터 처리, 시각화, 간단한 모델 추론, 파일 입출력 같은 작업을 같은 언어 안에서 매끄럽게 이어갈 수 있다. 별도의 계층을 많이 나누지 않아도 되기 때문에, 코드를 읽고 수정하는 흐름도 비교적 단순하다. 데이터 중심의 작업을 하는 사람에게는 이 단순함 자체가 큰 힘이 된다.

하지만 Streamlit을 오래 쓰다 보면 분명한 한계도 보인다. 가장 먼저 느끼는 것은 화면과 상태를 정교하게 다루는 데 제약이 있다는 점이다. 작은 도구를 만들 때는 단순함이 장점이지만, 화면이 복잡해지고 사용자 흐름이 길어질수록 그 단순함이 오히려 답답함으로 바뀌기도 한다. 세밀한 상호작용, 복잡한 권한 처리, 정교한 UI 설계가 필요한 순간이 오면 Streamlit은 다소 거칠게 느껴진다.

구조를 잘 잡지 않으면 코드가 빠르게 비대해지는 점도 아쉽다. 처음에는 한 파일에 술술 써 내려가도 괜찮지만, 기능이 조금만 늘어나도 상태 관리와 로직 분리가 생각보다 까다로워진다. 앱이 커질수록 “빠르게 만든 코드”의 대가를 나중에 치르게 되는 경우가 많다. Streamlit의 문제라기보다, 빠른 개발 도구가 대체로 갖는 숙명에 가깝다.

배포와 운영 측면에서도 생각할 점이 있다. 작은 서비스나 데모에는 잘 맞지만, 사용자가 많아지고 안정성 요구가 커지는 순간부터는 고민이 깊어진다. 성능, 인증, 장기 운영, 복잡한 협업 구조까지 고려해야 한다면 Streamlit만으로는 부족하다고 느끼게 된다. 결국 이 도구는 “무엇이든 가능한 웹 프레임워크”라기보다, 특정한 종류의 문제를 아주 빠르게 풀어주는 도구에 가깝다.

그래도 나는 Streamlit을 좋게 본다. 이유는 간단하다. 이 도구는 생각을 너무 늦기 전에 구현하게 만든다. 머릿속에만 있던 아이디어를 실제 화면으로 끌어내고, 손으로 만져보게 하고, 빠르게 검증하게 만든다. 완벽한 구조를 약속하지는 않지만, 시작할 수 있게 해준다는 점에서 충분히 가치가 있다.

결국 Streamlit의 장점과 단점은 같은 뿌리에서 나온다. 단순해서 빠르고, 빠르기 때문에 멀리 가기 전에 구조적 한계가 드러난다. 그래서 내게 Streamlit은 “처음부터 끝까지 책임지는 도구”라기보다, 생각을 현실로 꺼내는 첫 번째 작업대에 가깝다. 그 역할만으로도 이 프레임워크는 충분히 의미가 있다.