문제 상황Python requests 라이브러리로 API에 PUT/POST 요청을 보낼 때, 배열 길이가 100개를 초과하면 403 Forbidden 오류가 발생했습니다.같은 API를 브라우저 UI나 Postman에서 호출하면 정상 동작했기 때문에, Python에서의 요청 형식에 문제가 있다고 판단했습니다.원인 분석requests 자체 제한 없음: 라이브러리 차원에서 배열 크기나 본문 길이를 제한하지는 않습니다.직렬화 방식 차이: json= 옵션은 기본적으로 ensure_ascii=True, 직렬화 시 공백 포함 → 바디가 불필요하게 길어짐.전송 형식 차이: Content-Length가 명확히 지정되지 않거나 청크드 전송이 되면, 보안 장비(WAF)가 차단할 수 있음.UI와 차이: 브라우저/포스트맨은 항..

리눅스나 macOS 환경에서 개발 작업을 하다 보면 source 명령어를 자주 접하게 됩니다. 특히 AWS나 기타 서비스의 인증 토큰을 담은 token.sh 같은 스크립트를 불러올 때 자주 활용됩니다. 이번 글에서는 source 명령어가 무엇인지, 왜 필요한지, 그리고 실제 활용 방법을 정리해보겠습니다.1. source 명령어란?source는 쉘 내장 명령어로, 스크립트 파일을 새로운 프로세스가 아닌 현재 쉘에서 실행하게 합니다.즉, 파일 안에 들어 있는 export 같은 환경 변수 설정이 현재 터미널 세션에 그대로 반영됩니다.실행 방식: source 짧은 축약형: . 2. bash 과의 차이많은 분들이 bash token.sh처럼 실행하는데, 이렇게 하면 새로운 하위 셸에서 실행됩니다.하위 셸이 종료되..

최근 프로젝트에서 PostgreSQL 기반의 대용량 데이터를 한 번에 집계하려다가 shared memory segment 에러를 자주 겪었습니다. 처음 한 달 정도는 잘 동작했지만, 기간을 늘려 6개월·1년 단위로 조회하는 순간 DB 메모리 관련 에러가 발생했습니다. 운영 환경에서 서버 파라미터를 크게 건드리기도 부담스러워서, 결국 쿼리를 기간 단위로 쪼개어 조회하고 자바에서 합산하는 방식으로 우회했습니다.아래는 제가 직접 적용했던 과정과 방법들입니다.1. 문제 원인장기간 데이터를 한 번에 조회 → 정렬/집계 단계에서 메모리 과부하PostgreSQL은 공유 메모리 한도를 넘으면 바로 오류 발생DB 설정(work_mem, shared_buffers)을 조정하면 해결 가능하긴 하지만, 운영 중인 환경에서는 ..

문제 상황adoptopenjdk/openjdk11:jre 이미지를 기반으로 자바 애플리케이션 Docker 이미지를 빌드하던 중, 보안 스캐너에서 CRITICAL 등급의 SQLite 관련 취약점(CVE)이 지속적으로 발견되었습니다.보안 점검 도구(Trivy 등)로 스캔한 결과, libsqlite3-0 라이브러리에서 발생하는 취약점이 주기적으로 보고되었고, 빌드 파이프라인이 이를 이유로 차단되는 상황이었습니다.원인 분석adoptopenjdk/openjdk11:jre는 Debian/Ubuntu 계열 기반으로 제작되어 있으며, 기본적으로 sqlite3와 libsqlite3-0 패키지를 포함하고 있습니다.문제는 다음과 같습니다.해당 이미지는 최신 보안 패치 적용 주기가 느립니다.저희 애플리케이션에서는 SQLite..

최근 TimescaleDB에 실시간 센서 데이터를 적재하는 과정에서 몇 가지 오류를 경험하였습니다. 로그를 분석하고 해결 방법을 찾아가는 과정을 정리해봅니다.1. 문제 상황Kafka에서 수집한 수천 개의 센서 데이터를 TimescaleDB에 적재하는 컨테이너 로그에서 다음과 같은 오류가 반복적으로 발생했습니다.1.1 statement_timeout 오류ERROR: canceling statement due to statement timeout이는 PostgreSQL의 statement_timeout 값(쿼리 실행 최대 시간)을 초과하면 발생하는 에러입니다. 대량 데이터를 한 번에 Insert하거나, 인덱스 부재, 네트워크 지연, 병렬 쓰기 병목 등으로 실행 시간이 길어질 경우 나타납니다.1.2 row i..