클라우드의 편리함을 버리고 온프레미스로 돌아온 이유

👤 인스피

조회 수 21

1. 첫 번째 삽질: 환경변수를 바꿨는데 왜 엉뚱한 포트를 찾을까? (Connection refused)

가장 먼저 겪은 황당한 문제는 DB 연결 오류였습니다. 우분투 서버에 PostgreSQL을 무사히 설치하고, .env 파일의 DB 접속 URL 포트를 클라우드용 포트에서 로컬 기본 포트인 5432로 변경했습니다. 하지만 서버를 재시작하자 터미널에 끔찍한 에러가 출력되었습니다.

Connection refused: Cannot connect to port 6543

분명 .env에는 5432를 입력했는데, 시스템은 계속해서 6543 포트를 찾으며 연결을 거부하고 있었습니다. 캐시를 지워보고 컨테이너를 재시작해도 소용이 없었습니다. 도대체 어디서 포트 번호가 꼬인 것일까요? 저는 리눅스 터미널을 열고 텍스트 검색의 강력한 무기인 grep 명령어를 빼들었습니다.

검색 결과는 충격적이었습니다. 과거에 Supabase 외부 커넥션 풀링(Connection Pooling)을 세팅할 때, database.py 파일 깊숙한 곳에 URL 문자열 중 .replace(":5432/", ":6543/")을 통해 강제로 포트를 변환해버리는 하드코딩 로직을 제가 직접 짜두고 까맣게 잊고 있었던 것입니다. 이 하드코딩된 코드를 찾아내어 깔끔하게 삭제하고 나니, 그제야 FastAPI가 로컬 DB에 정상적으로 뿌리를 내리기 시작했습니다. 과거의 제가 파놓은 함정에 제가 빠진 셈이었습니다.

2. 두 번째 삽질: 극한의 성능을 향해, 비동기 드라이버(asyncpg) 전환

로컬 DB 연결에는 성공했지만, 대량의 트래픽과 벌크 인서트를 감당하기 위해 저는 기존에 사용하던 동기식 드라이버(psycopg) 대신, 파이썬 생태계에서 가장 빠른 비동기 PostgreSQL 드라이버인 asyncpg로 엔진을 완전히 교체하기로 했습니다.

하지만 드라이버를 바꾸자 이번에는 SQLAlchemy 설정에서 호환성 에러가 뿜어져 나왔습니다. 기존 동기식에서 잘 작동하던 커넥션 타임아웃이나 서버 세팅 인수들이 asyncpg 규격과 전혀 맞지 않았기 때문입니다. 공식 문서를 수십 번 뒤져가며 database.py의 connect_args 설정을 비동기 규격에 맞게 정교하게 튜닝해야만 했습니다.

이 튜닝을 거친 후 비동기 처리의 마법이 시작되었습니다. 데이터베이스 응답을 기다리느라 멈춰있던 백엔드 스레드들이 병렬로 자유롭게 풀려나면서, 서버의 동시 처리 능력이 차원이 다르게 쾌적해졌습니다.

3. 세 번째 삽질: Cloudflare 524 에러와 청크(Chunk) 최적화

마침내 아키텍처 세팅을 끝내고 봇을 가동하여 수십 개의 게시글을 한 번에 올리는 테스트를 진행했습니다. 그런데 업로드 도중 갑자기 웹 화면에 'Cloudflare 524 A timeout occurred' 에러가 뜨면서 중복 게시글이 마구잡이로 올라가는 치명적인 버그가 발생했습니다.

원인은 백엔드의 '작업 대기 시간'에 있었습니다. 벌크 업로드를 할 때 단순히 DB에 텍스트만 넣는 것이 아니라, 외부 번역 API를 호출하고 로직을 처리하는 무거운 작업이 포함되어 있었습니다. 이 작업이 100초를 넘어가자, 서버 앞단을 지키고 있던 클라우드플레어가 "서버가 응답이 없으니 연결을 끊겠다"라며 강제로 100초 타임아웃(524 에러)을 발생시킨 것입니다. 서버는 뒤에서 계속 글을 쓰고 있는데 프론트엔드 연결만 끊기니, 봇은 "업로드 실패인가?" 하고 동일한 글을 또다시 전송하여 중복 포스팅이 일어난 것이었죠.

이를 해결하기 위한 아키텍처 최적화는 '분할 정복'이었습니다. 자동화 스크립트가 백엔드로 한 번에 전송하는 전송 단위(Chunk Size)를 기존 20개에서 5개로 대폭 줄였습니다. 한 번에 5개씩만 번역 API를 태우고 DB에 밀어 넣도록 쪼개어 처리하니, 백엔드 응답 시간이 20초 이내로 단축되어 클라우드플레어의 100초 타임아웃 장벽을 완벽하게 피해 갈 수 있었습니다.

길고 험난했던 트러블슈팅을 마치고 나니, 결과는 상상 이상이었습니다. 데이터베이스가 외부 클라우드 네트워크를 타지 않고 localhost 내부에서 즉각적으로 통신하게 되면서 DB 응답 속도가 비약적으로 상승했습니다. 수십 개의 게시글과 썸네일 미디어를 다루고 4~16분 간격으로 예약 발행하는 무거운 자동화 봇 로직을 3개 이상 동시에 돌려도 서버 자원(CPU, RAM)이 넉넉하게 유지되었습니다.

클라우드가 무조건적인 정답은 아닙니다. 현재 서비스의 트래픽 패턴과 자동화 로직의 성격에 따라, 때로는 이렇게 온프레미스(로컬) 환경으로 묵직하게 시스템을 옮기는 것이 최고의 성능을 내는 아키텍처가 될 수 있음을 뼈저리게 배운 소중한 경험이었습니다.

❓ 자주 묻는 질문 (FAQ)

Q1. 클라우드 DB(Supabase)의 요금제를 올려서 스케일업(Scale-up)하면 해결되지 않나요?

A. 물리적인 리소스를 늘리면 일정 부분 병목이 해소될 수 있습니다. 하지만 클라우드 DB는 태생적으로 서버와 DB가 서로 다른 물리적 위치에 존재하므로, 네트워크 지연(Network Latency) 자체가 사라지지는 않습니다. 실시간 대량 처리가 잦은 백엔드 구조에서는 서버와 DB를 같은 로컬 환경에 두는 것이 비용과 성능 면에서 훨씬 압도적인 효율을 보여줍니다.

Q2. Cloudflare의 100초 타임아웃(524 에러) 설정값을 임의로 늘릴 수는 없나요?

A. 무료 플랜(Free)이나 프로 플랜 사용자 기준으로, 클라우드플레어의 100초 타임아웃은 하드 리밋(Hard Limit)으로 강제 설정되어 있어 사용자가 임의로 늘릴 수 없습니다. 고액의 엔터프라이즈 요금제에서만 조절이 가능하므로, 백엔드 로직 자체의 응답 속도를 100초 이내로 단축(Chunking)시키는 것이 유일하고 올바른 아키텍처 해결책입니다.

Q3. 비동기 asyncpg 드라이버를 도입할 때 가장 주의해야 할 점은 무엇인가요?

A. 기존의 psycopg2 같은 동기식 드라이버 설정 코드를 단순히 비동기로 이름만 바꾼다고 작동하지 않습니다. sessionmaker를 사용할 때 반드시 AsyncSession 클래스를 상속받아야 하며, DB에 쿼리를 던질 때는 모든 로직 앞에 await 키워드를 붙여 스레드 차단을 막아야 완벽한 비동기 성능을 낼 수 있습니다.