글

Python httpx readtimeout 사례 & 해결법

파이썬의 비동기 http 클라이언트 라이브러리 Httpx에서 발생하는 readtimeout은 HTTPError > TransportError > TimeoutException의 하위 Timeout Exception이다. httpx.TimeoutException은 timeout 에러의 Base class이며 시간 내에 작업이 수행되지 않았을 때 발생한다. Timeout에 해당하는 예외처리 중에 보다 세부적인 케이스로 ConnectTimeout : host에 연결하는 도중 Timeout ReadTimeout      : host로부터 데이터를 받는 도중 Timeout WriteTimeout      : host로 데이터를 보내는 도중 Timeout PoolTimeout       : pool로부터 connection을 얻으려고 대기하는 도중 Timeout 가 있다. Agent를 개발하면서 LLM API를 호출할 때 ReadTimeout을 많이 겪게 된다. host인 LLM API 서버로부터 응답을 기다리다가 발생하는 것인데 host와 client ( https client ) 둘 다 튜닝이 필요하다. host에서는 응답 데이터를 압축한다던가 응답 토큰 수에 제약을 두는 방법을 적용하고 client에서는 https client의 readtimeout 스레시홀드를 늘리는 방법이 유효하다. 다만 client의 readtimeout을 무한정 늘리면 양측에 열린 connection이 계속해서 자원을 점유하기 때문에 LLM API의 응답 데이터를 제한시키는 것이 좋다.  
댓글 쓰기
Read more »

Python bcrypt를 활용해 비밀번호 hashing 할 때 발생하는 에러.

bcrypt 라이브러리는 패스워드 해싱을 위한 라이브러리다. https://pypi.org/project/bcrypt/ 그런데 프로젝트 설명을 보면 argon2id나 scrypt를 사용하라고 권장하고 있다. 왜 인지는 모른다. 4.3.0 버전에서는 해싱함수가 정상적으로 작동했으나 최신버전은 5.0.0에서는 다음과 같은 ValueError가 발생한다. ValueError: password cannot be longer than 72 bytes, truncate manually if necessary 프로젝트 Changelog를 보면 다음과 같이 나와있다. hashpw에 전달되는 패스워드가 72바이트보다 길면 ValueError를 일으키도록 되어있다. 이전까지는 Error를 Raise하지 않고 라이브러리 내에서 truncate해서 return했다고 한다. (OpenBSD의 bcrypt 구현) Python 3.14 환경을 사용해야하는 제약이 없다면 4.3.0으로 다운그레이드하거나 직접 ValueError를 핸들링해주는 방법이 있겠다. ====================================================== 여담으로 본래 고속 연산 작업을 하기 위해 C로 작성된 소스코드가 컴파일된 .so 형태로 존재했고 CFFI ( C Foreign Function Interface )가 python <-> c간의 인터페이스 변환 역할을 했다. 그러나 현대에 이 라이브러리는 최신버전 4.0.0 이후 보안성과 메모리 안전성을 위해 Rust로 작성하였고 (.rs) src/lib.rs에서 그 흔적을 찾아볼 수 있다. PyO3라는 라이브러리를 통해 Rust와 Python 소스코드를 바인딩하고 Rust 컴파일러인 rustc가 기계어 파일로 컴파일 한다. 본문에서 말한 hashpw 함수는 lib.rs 소스코드의  68 ~ 138에 해당한다. 해당 소스코드에서는 let hashed = py .detach(|| bcrypt::ha...
댓글 쓰기
Read more »

방송/영상 표준 해상도

모니터 디스플레이 (16:9) HD         1280 x 720         1k=1000 FHD       1920 x 1080       2k QHD      2560 x 1440         3k UHD      3840 x 2160       4k DCI 규격 영화 스크린 Digital Cinema Initiatives 할리우드 스튜디오들이 디지털 영화 상영을 위해 정의한 기술 규격 2048 x 1080     DCI 2K FULL 4096 x 2160      DCI 4K Full . . . . .
댓글 쓰기
Read more »

Before coding in Spring framework

오래된 Spring framework 코드를 유지보수 할 일이 생겼다. 여타 웹 애플리케이션 프레임워크가 그렇듯, http request-response를 다루니까 크게 코드를 읽는 데 불편하지는 않았다. 그러나 애플리케이션 로직이 java 문법으로 작성된 만큼  java 개발 생태계를 익혀야 할 필요성을 느껴 간략하게 상기하는 차원에서 특별한 순서 없이 작성하였음. =============================================================== JAVA  JAVA'S Editions  java에는 여러가지 에디션이 있는데 1. java SE (J2SE) : 표준 에디션 2. jakarta EE(J2EE , 구 java EE) : 서버 페이지에 특화 3. java ME (J2ME) : 임베디드 환경에 특화 / 경량 등이 있다. 프로그램을 제작할 때, 사용 환경에 따라 적합한 유형의 java를 선택하여 개발할 수 있다. JSP HTML 페이지를 동적으로 생성하기 위한 파일. JSP Template은 Java Servlet 코드로 변환된다. HTML page에 Java 코드가 포함된 꼴을 띄고 있다. 최근엔 JS, JS 프레임워크에 비해 밀리는 추세. 동적 HTML page 생성 vs  AJAX 서버 사이트 스크립트 언어를 사용해서 HTML Page를 동적으로 만드는 것이 줄고 있음. 왜냐하면 현대에는 API를 사용하여 서버 자원에 접근을 하고(DB, File) 화면에 보여주는 UI는 HTML/CSS/JS를 사용한다. 따라서 client <-> server 간 통신이 필요하고 XHR, XML HttpRequest를 사용한다. 이런 프로그래밍 기법을 AJAX라함. .java 소스코드의 컴파일  프로그래머가 작성한 .java 소스 코드는 Javac 컴파일러에 의해 .class코드로 변환되고 windows / linux / mac 환경에 각각 깔린 jvm에 의해 해당 시스템의 기계어...
댓글 쓰기
Read more »

미술 작품 촬영과 Tiff 확장자 파일

이미지
미술 작품의 디지털화, 아카이빙 사물들은 어떤 조명을 받는 지에 따라서 반사해내는 빛의 다르다. 미술관, 전시관에 가면 작품에 조사하는 조명이 중요한데 조명에 따라 보이는 색이 다르기 때문이다. 조명에 따라 관객이 다르게 받아들일 수 있다. 작품 본연의 색깔이라고하면은 보통 백색광을 조사했을 때 반사되는 빛을 말한다. 미술 작품들을 촬영 후 디지털화 하여 저장할 때 바로 TIFF 확장자 파일이 등장한다. - 촬영 미술 작품을 촬영할 때는  국제 표준 인증을 충족하는 촬영 환경이 전제되어야 높은 색채 정확도와 원본에 가깝게 재현력을 확보할 수 있다. - 저장 디지털화 된 파일은 원본에 가깝게 유지해야하므로 손실 압축 방식인 JPG보다는 PNG가 선호된다. TIFF는 여기서 한 발 더 나아가 채널 당 저장할 수 있는 색상 깊이가 PNG에 비해 더 높다. (PNG: 1채널에 16비트, TIFF : 1채널에 32비트) 보편적인 이미지-뷰어 프로그램들은 대부분 JPG, PNG, GIF 등의 이미지를 지원하지만 전문가용 카메라로부터 추출된 RAW 파일, TIFF 파일등은 전문 사진 편집용 프로그램에서만 열 수 있는 경우가 많다. 디지털화 된 미술 작품의 출력 이제 아카이빙 된 파일을 복합기, 인쇄기를 통해 출력한다고 가정하자. PNG로 저장된 작품을 인쇄할 때와 TIFF로 저장된 작품을 인쇄할 때의 질이 확연히 다르다. 주로 웹 상에서 DID, 모니터 장치에 RGB로 출력되는 JPG의 경우 중복된 영역을 탐지하여 일부 정보 손실을 감안하고 압축하여 저장한다. PNG의 경우 무손실 압축방식이지만 CMYK가 지원되지 않으며 색상 정보가 상대적으로 TIFF보다 적다. TIFF는 RGB, CMYK모두 지원되며 색상정보가 풍부한 무손실 포맷이다.
댓글 쓰기
Read more »

데이터 연구 분야, 기술 통계 vs 추측 통계

이미지
기술 통계 이미 보유하고 있는 데이터에 대해 분석한다. 있는 그대로 요약, 정리, 시각화하여 데이터의 특성을 도출한다. 보유하고 있는 데이터의 모집단과 같이 데이터의 범위를 확장하여 추정하지 않고 가지고 있는 데이터에만 집중한다. 가지고 있는 데이터 그대로의 특성을 분석하므로 불확실성이나 오차와 같은 개념이 없다. 추측 통계 작은 표본을 가지고 전체의 특성을 유추한다. 전수 조사가 불가능할 때 데이터의 일부만 가지고 전체의 특성을 추정하므로 오차가 필연적으로 발생하고 - 확률 - 신뢰 구간 - 예측 모델의 개념이 추가된다. 예측 모델은 과거의 표본을 분석하여 수학적 패턴을 찾아낸다. 대표적인 통계적 모델은 회귀 분석 모델, 로지스틱 회귀, 시계열 분석 모델(ARIMA) 등이 있다. 머신러닝 모델 vs 통계적 모델 통계적 모델들은 수학적인 패턴이 존재하기 때문에 왜 그런 결과가 나왔는지 해석이 가능하다. 최신 머신러닝/딥러닝 모델은 결과에 대한 설명보다는 **"결과를 얼마나 잘 맞히는지(정확도)"**에 올인하기 때문에 속을 알 수 없는 복잡한 구조(블랙박스)인 경우가 많다.
댓글 쓰기
Read more »

데이터 연구 분야 시뮬레이션 vs 최적화

이미지
시뮬레이션 예시 그림의 유체 역학과 같은 물리적 상호작용을 보여주는 시각적 프로그램 뿐 아니라 현실과 가깝게 만든 모델 을 제작한 뒤 여러 변수를 대입 하여 실험해 보는 행위가 모두 시뮬레이션에 속한다. 가상의 네트워크를 만들어서 네트워크 트래픽을 시뮬레이팅 할 수도 있고 가상의 주식 시장을 만들어서 시장의 변동성을 시뮬레이팅 할 수도 있다. 불확실성이 많은 현실 세계의 도메인에서 시스템의 동작과 흐름을 모방하여 미래를 예측하고 이해한다. 결국 시뮬레이션도 미래를 예측하고 이해하기 위해 사용한다. 이 모델에서 조건을 바꾸면 어떤 일이 일어날 지를 관찰한다. 최적화 목표를 달성하기 위한 가장 좋은   방법 을 찾는다. 방법이라고하면 최소값 or 최대값의 해답을 의미한다. 꼭 값 하나로 귀결 되는 것은 아니며 단일 스칼라 값 외에도 스케줄, 경로, 벡터 행렬 등으로도 표현될 수 있다. 방법을 찾기 위 전제되어야 할 조건은 목표가 명확해야 한다는 것이다. 시뮬레이션과 최적화 최적화 과정을 통해 후보 해를 도출하고 시뮬레이션으로 검증하여 사용한다.
댓글 쓰기
Read more »

이 블로그의 인기 게시물

Blogger 커스터마이징 : CSS 수정 (sticky-header)

이미지
sticky-header, centered-top-container sticky animating 삽질1 google blogger의 템플릿 테마중 하나인 Contempo에서는  스크롤을 어느 정도 내린 상태에서 다시 올리면 상단의 검색창이 내려와서 스크롤을 다시 내릴 때까지 유지된다. (이 "어느 정도"에 해당하는 값은  기본 테마의 javascript에 코딩 되어있을 것으로 추측한다.) css 수정 후 이 부분에 문제가 생겨서 내릴때에도 올릴 때에도 계속 검색창이 내려오고 사라졌다를 반복한다. < 페이지 최하단 모습 > 데이터를 색인하여 찾을 때는 유용한 기능이라고 생각하지만 검색 기능은 이미 블로그 최상단에 존재한다. 따라서 해당 기능을 제거하기로 했다. scroll event를 감지하고 그에 따라 html이나 css문서를 수정하는 작업은  javascript가하는 일이다. html 편집기를 통해 코드를 살펴본 결과 이 javascript 코드는 외부 cdn 서버에서 가져오는 것 같다.  javascript 코드를 직접 건드려야되나 싶어서 구글링 해 본 결과 간단하게 css 코드를 수정해서 없앨 수 있었다. sol) sticky-header 제거 https://joshua-dev-story.blogspot.com/2020/04/blogger-remove-sticky-header.html FE, Publishing 에서는 '고정 헤더'라고 부르고 있는 이 태그의 css를 수정하면 된다. display 옵션을 none으로 바꿔서 기존 요소의 block을 전부 없애고 기능까지 해제해버리는 것. 이 sticky header를 보이지 않게하는 방법은 opacity를 0으로 만들거나 visibility를 hidden으로 할 수도 있지만 display : none 옵션이 가장 확실해보인다. 수정 후 여전히 scroll 이벤트에 따라 DOM의 변경이 일어나는 것 같지만 sticky header는 더이상 보이지 않는다. 삽질2...
Read more »

노마드코더 개발자북클럽 Clean code 완주, 독후감

이미지
짧은 기간 동안 Java로 쓰여진 클린 코드 책을 읽으며 코드를 짤 때 더 정성을 들여 쓰는 습관을 들였다. 당장 작동하는 코드보다는 유지 보수가 편한, 수정보다는 확장을 할 수 있는, 잘 읽히는, 정직하고, 하나의 일에 몰두하는 그런 코드를 짜려고 했다. 퇴근을 하고 책상 앞에 앉으면 오늘 작성했던 class가 아른거리고 과연 이게 최선이었을까 생각하게 되었다. ========================================================== 책을 읽으면서 대부분 공감하고 고개를 끄덕일 수 있었지만 좋은 코드를 쓰는 법을 아는 것과 좋은 코드를 쓰는 것에는 큰 차이가 있다. 좋은 코드를 쓰는 법을 알기만 해서는 그저 말로만 잘난 체 할 수 밖에 없을 것이다. 좋은 코드를 쓰는 사람은 코드 리뷰를 하며 시스템 변경에 유연한 구조인지 고민한다. 확실히 후자가 더 고된 작업이지만 견고한 프로덕트를 만드는, 실체가 있는 실력이 는다고 생각한다. ========================================================== Java기 반의 코드를 이해하기는 쉽지 않았지만 확실히, Java가 객체 지향적인 장치가 많다고 느꼈다. Python 웹 개발자라면 당장 객체지향 원칙이나 디자인 패턴을 익히기 보다는 웹 애플리케이션 프레임워크를 익히기를 추천한다. 그 중에서도, FastAPI를 추천하는데 Layer와 Depends를 사용한 설계 장치를 사용하며 실전 감각을 기르면서 객체지향적인 사고를 할 수 있다. 혼자 상향식으로 배우기 버겁다면 Framework의 규칙을 따르며 배워나가는 것이 효율적이라고 생각한다. 그리고 이렇게 해야 실전 감각을 느낄 수 있다. ========================================================== 클린 코드 북클럽 챌린지 덕분에 오늘도 나는 하나의 괴이한 모듈을 처리했다. util 패키지의 fileutil이라는 모듈인데 온갖 잡다한 파일 처리를 다 도맡아 하...
Read more »

노마드코더 개발자북클럽 Clean code TIL 7 : 7장. 오류 처리

이미지
       오늘 TIL 3줄 요약 논리가 오류 처리 코드와 뒤섞이지 않으므로 오류가 발생하면 예외를 던지는 편이 낫다. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 외부 라이브러리, API 가 던지는 예외를 전부 잡아내지말고 감싸는 클래스, Wrapper를 사용하여 의존성을 줄이자. 가능하다면, 예외 유형 하나로 오류를 구분하자. TIL (Today I Learned) 날짜 2025. 06.03 오늘 읽은 범위 7장. 오류처리 기억하고 싶은 내용을 써보세요. 오류 플래그, 호출자에게 오류 코드 반환하기  vs 예외 던지기. 에외를 지원하지 않는 프로그래밍 언어가 많았다. try-catch-fianally try 블록은 트랜잭션과 비슷하다. catch 블록에서 예외 유형을 좁혀라. 확인된 예외는 OCP를 위반한다. 하위 단계의 코드 변경이 상위 단계 메서드 선언부 전부를 고치게 만들기 때문이다. 예외에 의미를 제공하라. 특히, 애플리케이션이 로깅을 제공한다면 catch 블록에서 오류를 기록하도록 충분한 정부를 넘겨준다. 오류를 처리하는 대부분의 로직. 1) 오류를 기록하고 2) 프로그램을 계속 수행해도 좋은지 확인한다. 정상 흐름부터 정의하라. NULL을 반환하지 마라. 호출자에게 문제를 떠넘기는 것이다. NULL확인이 누락된 코드를 고치는 게 아니라 특수 사례 객체를 통해 NULL확인을 만들지 마라! NULL을 전달하지 마라. null을 전달받는 쪽에서 처리하지 말고 null 을 전달하는 쪽에서 전달을 막아라. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 NULL을 확인할 일 자체를 최소화해야겠다. NULL대신 적합한 기본값을 사용하자. 깨끗한 코드는 가독성도 좋아야하지만 안전성이 높아야한다. 그리고 이 둘은 시간-공간 개념처럼 Trade off되는, 상충되는 개념이 아님. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면...
Read more »