- 🐍 Python | Raspberry Pi에서 오픈소스 LLM으로 뉴스 요약기 만들기 ---
2️⃣ 개요 (Intro)
- 오늘은 라즈베리 파이에서 오픈소스 LLM을 활용해 웹 뉴스 요약기를 만드는 프로젝트를 구상했다. - 주요 목표는 Daum 포털에서 뉴스 데이터를 수집하고, 경량 LLM을 통해 300자 이내로 요약하는 기능을 구현하는 것. - 사용한 기술 스택은 Python, BeautifulSoup, Hugging Face Transformers, Phi-3 Mini 모델.
📅 날짜: 2025.11.05 🎯 목표: Raspberry Pi에서 뉴스 요약기 구상 🧰 기술: Python, Hugging Face, BeautifulSoup, Phi-3 Mini
---
3️⃣ 문제 정의 (Problem / Motivation)
- 라즈베리 파이처럼 리소스가 제한된 환경에서 LLM을 실행하려면 경량화된 모델이 필요하다. - 웹에서 뉴스 데이터를 자동으로 수집하고, 이를 요약하는 기능을 구현하려면 크롤링과 자연어 처리 기술이 결합되어야 한다. - Daum 포털의 HTML 구조를 분석해 주요 뉴스 텍스트를 추출하는 방식으로 접근했다.
# Daum 뉴스 헤드라인 수집 예시 soup.select("a.link_txt")
---
4️⃣ 해결 과정 (How I Solved It)
- Hugging Face에서 제공하는 Phi-3 Mini 모델을 선택해 Python 코드로 불러오는 방식으로 구성했다. - BeautifulSoup을 활용해 Daum 메인 페이지에서 주요 뉴스 텍스트를 추출하고, 이를 LLM에 입력해 요약 결과를 생성했다. - 전체 흐름은 뉴스 수집 → 요약 요청 → 결과 출력으로 구성되며, 추후 Streamlit을 통해 UI도 확장 가능하다.
- 뉴스 헤드라인을 수집하고, LLM을 통해 간결한 요약 결과를 생성하는 데 성공했다. - 라즈베리 파이에서도 실행 가능한 경량 모델을 활용함으로써 저전력 환경에서도 AI 기능을 구현할 수 있다는 가능성을 확인했다.
✅ Daum 뉴스 요약 기능 구현 성공 📉 리소스 사용량 최소화, 실행 속도 안정적
---
6️⃣ 느낀 점 / 회고 (Reflection)
- 오픈소스 LLM의 발전 덕분에 소형 디바이스에서도 자연어 처리 기능을 구현할 수 있다는 점이 인상 깊었다. - 다음에는 Streamlit을 활용해 웹 UI를 추가하고, 요약 결과를 저장하거나 공유할 수 있는 기능을 확장해보고 싶다. - 또한 뉴스 외에도 블로그, 기술 문서 등 다양한 텍스트에 적용해보는 실험도 흥미로울 것 같다. ---
7️⃣ 참고자료 (References)
- [Hugging Face - Phi-3 Mini 모델](https://huggingface.co/microsoft/phi-3-mini) - [BeautifulSoup 공식 문서](https://www.crummy.com/software/BeautifulSoup/bs4/doc/) - [Daum 포털](https://www.daum.net) - [Open Source LLMs in 2025 - GeeksForGeeks](https://www.geeksforgeeks.org/artificial-intelligence/top-10-open-source-llms-in-2025) ---
🐍 Python | PC에 흩어진 .whl 파일, 한 곳으로 모으는 자동화 스크립트 개발기
AI가 그려준 이미지
📅 개요 (Intro)
날짜: 2025.10.26
목표: 여러 프로젝트와 폴더에 흩어져 있는 .whl(휠) 파일들을 하나의 지정된 폴더로 모아주는 Python 스크립트를 개발하여 라이브러리 관리를 효율화한다.
기술: Python, os 모듈, shutil 모듈
🧐 문제 정의 (Problem / Motivation)
Python으로 여러 프로젝트를 진행하다 보니 가상 환경(venv), 다운로드 폴더 등 PC 곳곳에 .whl 파일들이 쌓이기 시작했습니다. 특정 라이브러리의 구버전이 필요하거나 오프라인 환경에서 설치해야 할 때, 이 파일들을 찾아 헤매는 일이 잦아졌습니다.
수동으로 *.whl을 검색해서 일일이 옮기는 것은 너무 번거롭고, 실수로 중요한 파일을 누락할 위험도 있었습니다. 이 반복적인 정리 작업을 자동화할 필요성을 느끼게 되었습니다.
🛠️ 해결 과정 (How I Solved It)
이 문제를 해결하기 위해 Python의 내장 라이브러리만을 사용하여 간단한 스크립트를 작성하기로 했습니다.
1. 파일 시스템 순회 및 .whl 파일 검색
가장 먼저 PC의 특정 드라이브(예: C:\)부터 시작해 모든 하위 폴더를 탐색해야 했습니다. Python의 os 모듈에 포함된 os.walk() 함수가 이 작업에 안성맞춤이었습니다. 이 함수는 지정된 경로의 모든 폴더와 파일을 순회하는 제너레이터(generator)를 반환해 줍니다.
파일을 찾은 후에는 문자열의 .endswith(".whl") 메서드를 이용해 확장자가 .whl인 파일만 골라 리스트에 추가했습니다.
import os
def find_whl_files(start_path): """지정된 경로와 그 하위 디렉토리에서 .whl 파일을 찾습니다.""" whl_files = [] for root, dirs, files in os.walk(start_path): for file in files: if file.endswith(".whl"): whl_files.append(os.path.join(root, file)) return whl_files
2. 찾은 파일들을 지정된 폴더로 이동
파일 검색이 완료되면, 이제 이 파일들을 한 곳으로 옮겨야 합니다. 파일 이동, 복사, 삭제 등 파일 시스템 관련 고급 작업을 처리하는 shutil 모듈의 shutil.move() 함수를 사용했습니다.
혹시 모를 오류(권한 문제 등)에 대비해 try-except 구문으로 각 파일 이동 작업을 감싸 안정성을 높였습니다.
import shutil
# 파일을 옮길 목적지 폴더 destination_folder = r'C:\Users\nari4\downloads'
# 목적지 폴더가 없으면 생성 if not os.path.exists(destination_folder): os.makedirs(destination_folder)
# 찾은 파일 리스트(all_whl_files)를 순회하며 이동 for file_path in all_whl_files: try: shutil.move(file_path, destination_folder) print(f"이동 완료: {file_path}") except Exception as e: print(f"'{file_path}' 이동 중 오류 발생: {e}")
✨ 결과 (Result)
스크립트를 실행하자 PC에 흩어져 있던 모든 .whl 파일들이 제가 지정한 C:\Users\nari4\downloads 폴더로 깔끔하게 정리되었습니다.
개선된 점:
이제 필요한 .whl 파일이 있다면 지정된 폴더만 확인하면 되므로 라이브러리 관리가 매우 편해졌습니다.
불필요한 파일을 찾아 헤매거나 중복으로 다운로드하는 시간이 사라졌습니다.
단순 반복 작업을 자동화하여 생산성이 향상되었습니다.
실행 결과 예시:
C:\ 드라이브에서 .whl 파일을 검색합니다...
[찾은 .whl 파일 목록] C:\projectA\venv\downloads\some_package-1.0-py3-none-any.whl C:\Users\nari4\Downloads\another_package-2.1-cp39-cp39-win_amd64.whl
[총 2개의 .whl 파일을 'C:\Users\nari4\downloads'로 이동합니다] 이동 완료: C:\projectA\venv\downloads\some_package-1.0-py3-none-any.whl 이동 완료: C:\Users\nari4\Downloads\another_package-2.1-cp39-cp39-win_amd64.whl
파일 이동이 완료되었습니다.
📝 느낀 점 / 회고 (Reflection)
교훈: 역시 "반복적인 작업이 있다면 자동화를 고민하라"는 말이 정답이었습니다. 잠시 시간을 투자해 만든 스크립트 덕분에 앞으로의 개발 환경이 훨씬 쾌적해졌습니다.
기술:os.walk()와 shutil.move()라는 Python의 기본적이면서도 강력한 도구의 활용법을 다시 한번 되새길 수 있었습니다.
다음 목표: 이 스크립트를 좀 더 발전시켜보고 싶습니다. 예를 들어, 이동 전에 파일명이 중복되는 경우 사용자에게 덮어쓸지 물어보는 옵션을 추가하거나, 오래된 버전의 .whl 파일을 식별하여 따로 분류하는 기능을 구현해 볼 계획입니다.
Connection conn = DriverManager.getConnection("jdbc:sqlite:mydata.db"); Statement stmt = conn.createStatement(); stmt.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)"); stmt.execute("INSERT INTO users (name) VALUES ('Kang')"); ResultSet rs = stmt.executeQuery("SELECT * FROM users");
필요한 JAR 파일
SQLite:sqlite-jdbc-3.43.2.0.jar
6. H2 사용법
Connection conn = DriverManager.getConnection("jdbc:h2:./testdb", "sa", ""); Statement stmt = conn.createStatement(); stmt.execute("CREATE TABLE IF NOT EXISTS users (id INT PRIMARY KEY, name VARCHAR(255))");
필요한 JAR 파일
H2:h2-2.2.224.jar (직접 실행하거나 Maven으로 자동 포함 가능)
이 글은 Java로 로컬 파일을 다루고, 문자열을 분석하고, 간단한 데이터베이스를 활용하는 방법을 정리한 내용입니다. 테스트용 앱이나 로그 분석, 간단한 GUI 앱에도 활용할 수 있어요!
오늘은 기존 습관 기록 앱에 쿠팡 파트너스 API를 연동하여 광고 상품을 보여주는 페이지를 개발하고, 사용자 경험을 개선하기 위해 이미지 로딩 성능을 최적화하는 과정을 거쳤습니다. 이 글에서는 전체 개발 과정과 마주쳤던 문제들, 그리고 해결 방법을 공유합니다.
1. ViewModel 상태 관리 및 API 연동
가장 먼저, API 통신 결과를 UI에 효과적으로 전달하기 위해 ViewModel에서 상태 관리를 구현했습니다. API 요청 상태를 Loading, Success, Error로 나누어 관리하는 AdProductState Sealed Interface를 정의하고, 이를 StateFlow로 UI에 노출시켰습니다.
// MainViewModel.kt
sealed interface AdProductState { object Loading : AdProductState data class Success(val products: List<BestProduct>) : AdProductState data class Error(val message: String) : AdProductState }
@HiltViewModel class MainViewModel @Inject constructor(...) : ViewModel() {
private val _adProductState = MutableStateFlow<AdProductState>(AdProductState.Loading) val adProductState = _adProductState.asStateFlow()
fun fetchCupangData(context: Context) { viewModelScope.launch { _adProductState.value = AdProductState.Loading try { // ... API 호출 로직 ... val response = CupangClient.getClient().getBestCategories(...)
if (response.data != null) { _adProductState.value = AdProductState.Success(response.data) // 성능 개선을 위한 이미지 프리로딩 호출 preloadImages(context, response.data) } else { _adProductState.value = AdProductState.Error("No products found") } } catch (e: Exception) { _adProductState.value = AdProductState.Error(e.message ?: "Unknown error") } } } // ... }
2. Composable UI 구현: AdProductPage
ViewModel에서 제공하는 adProductState를 구독하여 상태에 따라 다른 UI를 보여주는 Composable 화면을 만들었습니다. LazyColumn을 사용하여 상품 목록을 효율적으로 표시하도록 구성했습니다.
// AdProductPage.kt
@Composable fun AdProductPage(viewModel: MainViewModel = hiltViewModel()) { val state = viewModel.adProductState.collectAsState() when (val currentState = state.value) { is AdProductState.Loading -> { Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center) { CircularProgressIndicator() } } is AdProductState.Success -> { LazyColumn(modifier = Modifier.fillMaxSize()) { items(currentState.products) { product -> // 상품 아이템 UI } } } is AdProductState.Error -> { Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center) { Text(text = currentState.message) } } } }
3. 이미지 로딩 성능 개선 과정
단순히 이미지 URL을 Coil에 넘겨주자, 사용자가 스크롤할 때마다 로딩 인디케이터가 보이면서 사용자 경험을 해쳤습니다. 앱 시작 시점에 이미 상품 정보를 모두 가져왔으므로, 광고 페이지에 진입했을 때는 이미지가 즉시 표시되어야 했습니다.
3.1. 1차 개선: 로딩 인디케이터와 플레이스홀더
우선 로딩 중임을 명확히 보여주기 위해 AsyncImage 대신 SubcomposeAsyncImage를 사용하고, loading 파라미터에 CircularProgressIndicator를 설정해주었습니다. 이는 로딩이 길어질 때 사용자에게 피드백을 주기 위한 최소한의 조치였습니다.
근본적인 문제를 해결하기 위해, 이미지 프리로딩 기법을 도입했습니다. ViewModel에서 상품 정보 API를 호출한 직후, 응답으로 받은 이미지 URL 목록을 Coil의 캐시에 미리 저장하는 방식입니다.
주의: 처음에는 preloadImages 함수 내에서 ImageLoader(context)로 새로운 이미지 로더 인스턴스를 만드는 실수를 했습니다. 이 경우 프리로딩에 사용된 캐시와 UI에서 사용된 캐시가 달라져 효과가 없었습니다.
애플리케이션 전역에서 사용되는 싱글톤 ImageLoader 인스턴스 (context.imageLoader)를 사용해야 캐시가 공유되어 프리로딩이 정상적으로 동작합니다.
// MainViewModel.kt (최종)
private fun preloadImages(context: Context, products: List<BestProduct>) { // context.imageLoader를 사용하여 싱글톤 인스턴스에 접근 val imageLoader = context.imageLoader products.forEach { val request = ImageRequest.Builder(context) .data(it.productImage) // 실제 이미지를 보여줄 필요는 없으므로, 메모리/디스크 캐시에만 저장 .build() imageLoader.enqueue(request) } }
4. 캐시 동작 확인 및 디버깅
프리로딩이 정말 효과가 있는지 확인하기 위해, SubcomposeAsyncImage의 onSuccess 콜백을 사용하여 이미지 데이터의 출처(dataSource)를 로그로 확인했습니다.
앱을 처음 실행하고 광고 페이지에 접근했을 때는 NETWORK 또는 DISK에서 이미지를 로드했지만, 앱을 다시 시작하거나 다른 화면에 갔다 돌아오면 MEMORY 캐시에서 이미지를 즉시 불러오는 것을 확인할 수 있었습니다.
OnBackInvokedCallback 경고: Android 13의 예측 뒤로가기 제스처 지원을 위해 AndroidManifest.xml에 android:enableOnBackInvokedCallback="true" 속성을 추가했습니다.
hiltViewModel Deprecation:androidx.hilt.navigation.compose.hiltViewModel 대신 androidx.hilt.lifecycle.viewmodel.compose.hiltViewModel를 사용하도록 import 경로를 수정했습니다.
결론
단순한 기능 구현에서 시작하여, 사용자 경험을 저해하는 성능 문제를 발견하고 이를 개선하는 과정을 통해 많은 것을 배울 수 있었습니다. 특히 이미지 로딩과 같은 비동기 작업을 다룰 때, 캐시 전략과 라이브러리의 동작 원리를 정확히 이해하는 것이 얼마나 중요한지 다시 한번 깨닫게 되었습니다. 이제 사용자는 광고 페이지에 진입했을 때, 지연 없이 상품 이미지를 즉시 확인할 수 있게 되었습니다.
#billcorea #운동동아리관리앱
🏸 Schneedle, um aplicativo obrigatório para clubes de badminton!
👉 Match Play – Grave pontuações e encontre oponentes 🎉
Perfeito para qualquer lugar, sozinho, com amigos ou em um clube! 🤝
Se você gosta de badminton, definitivamente experimente
Acesse o aplicativo 👉 https://play.google.com/store/apps/details?id=com.billcorea.matchplay
