itsdev의 IT Blog

Cloudflare에서 보안 권고가 올라왔다.10월 19일, eMudhra가 발급한 중간 인증서 8개의 개인키가 손상된 사실이 확인됐고, Cloudflare는 다음날 Tunnel 사용자에게 cloudflared 2026.10.2 이상으로 업그레이드하라고 안내했다.처음에는 외부 CA 사고가 내 서비스랑 무슨 관계가 있나 싶었다.그런데 DJC의 네트워크 구조를 생각하면 이야기가 달라진다. DJC는 외부 인바운드 포트를 열지 않고 Cloudflare Tunnel을 서비스와 관리 경로의 진입점으로 쓰고 있다. 그 Tunnel의 Connector가 이번에 문제가 된 인증서를 계속 신뢰하고 있다면 사실상 DJC의 정문이 열려 있는 것과 같은 상태다.어떤 위험이 있었나이번 사고의 핵심은 TLS 암호화 자체의 취약점이..

DJC(DevJob-Collector)를 처음 만들면서 가장 먼저 필요했던 것은 채용 공고 데이터였다.처음에는 어렵게 생각하지 않았다.공공데이터 API를 호출해서 JSON을 받고 DB에 저장하면 되는 것 아닌가?구조만 놓고 보면 맞다. RestTemplate으로 공공데이터포털의 채용정보 API를 호출하고, 응답을 DTO로 받은 뒤 JobPost로 변환해 저장했다.그런데 실제 데이터를 연결하면서 생각보다 기본적인 곳에서 계속 문제가 나왔다. API 응답 구조가 일정하지 않았고, 외부 공고 ID의 타입을 잘못 가정했고, 중복 확인 때문에 같은 종류의 SQL이 반복됐다. 나중에는 서버를 테스트용으로 띄웠을 뿐인데 수집기가 자동으로 데이터를 저장하는 문제까지 발견했다.이번 글에서는 이 문제들을 해결하면서 DJC..

운영 중인 DJC(DevJobCollector)의 데이터베이스를 자체 호스팅 VM MySQL 8.0.46에서 OCI Managed MySQL 26.7.0-cloud로 이전했다. 리허설 Import, 정합성 검증, Shadow 환경 테스트, 최종 컷오버까지의 전체 과정을 기록한다.왜 옮겨야 했는가DJC는 애플리케이션 서버(E2 VM)와 DB 서버(별도 VM)를 각각 직접 운영하는 구조였다. MySQL 설치, 패치, 백업, 계정 관리를 전부 직접 해야 했고, 애플리케이션을 OCI Ampere A1으로 이전하면서 DB 연결 구조도 함께 정리할 필요가 있었다.기존 Security List에는 /16 대역으로 3306 포트가 열려 있었다. 접근 범위를 최소화하고, DB 운영 부담을 줄이면서, 운영 데이터 442M..

DJC(DevJob-Collector)의 초기 백엔드 배포 방식은 단순했다.GitHub Actions에서 Spring Boot JAR을 만들고 서버에 전송한 뒤 systemd를 재시작했다.GitHub Actions ↓bootJar ↓SCP ↓app.jar ↓systemctl restart개발 초기에는 이 구조가 오히려 효율적이었다.Docker Registry도 필요 없고 컨테이너 운영도 신경 쓰지 않아도 된다. JDK만 설치돼 있으면 Spring Boot를 바로 실행할 수 있었다.하지만 DJC 인프라를 OCI Ampere A1 Flex로 이전하면서 상황이 달라졌다.기존 서버와 새 서버의 실행 환경을 동일하게 맞춰야 했고, A1은 ARM64 아키텍처였다. 배포가 실패했을..

WithBuddy 연재 11편이자 시즌 4의 시작이다. 지금까지는 성능 개선과 아키텍처 설계를 중심으로 정리했다. 이번 편에서는 방향을 바꿔 실제 운영 과정에서 겪었던 장애 세 가지를 다룬다. Anthropic API의 529 과부하, Grafana 알림 오탐, 그리고 Blue/Green 배포 과정에서 발생한 트래픽 불일치를 어떻게 발견하고 원인을 추적했는지 정리한다.이 글에서 다루는 내용HTTP 200 뒤에 숨어 있던 SSE 스트리밍 오류를 추적한 과정RabbitMQ 장애처럼 보였지만 실제로는 알림 규칙이 잘못됐던 Grafana 오탐Nginx는 Green을 가리키는데 일부 트래픽은 Blue로 유입됐던 배포 문제세 장애를 겪으며 운영 방식에서 바꾼 것들이번에는 잘된 것보다 잘못된 것을 기록해보려 한다지금..

WithBuddy 연재 10편이자 시즌 3의 마지막 글이다. LLM 대화가 길어질수록 프롬프트에 포함되는 히스토리와 토큰 비용도 함께 증가한다. WithBuddy에서는 Redis List의 RPUSH + LTRIM을 이용해 최근 5턴만 유지하고, EXPIRE로 오래된 세션까지 자동 정리했다. 별도의 이력 정리 배치나 삭제 대상 탐색 없이 대화 맥락을 일정한 크기로 제한한 방법을 정리한다.이 글에서 다루는 내용전체 대화 이력을 매번 LLM에 전달하면 비용이 커지는 이유RPUSH + LTRIM으로 최근 N개의 메시지만 유지하는 원리별도의 조회·삭제 로직보다 Redis List를 활용한 이유TTL 30분으로 유휴 세션을 자동 정리하는 방법턴 기반 슬라이딩 윈도우의 한계와 보완 방법문제 — 대화가 길어질수록 L..

WithBuddy 연재 9편. 여러 회사가 함께 사용하는 RAG 서비스에서 회사별 문서를 ChromaDB 컬렉션 단위로 어떻게 격리했는지, 그리고 정책 문서가 변경됐을 때 Redis의 구버전 캐시를 일괄 삭제하지 않고 activeVersion 하나만 변경해 자연스럽게 무효화한 전략을 정리한다. 이 글에서 다루는 내용여러 회사의 문서가 검색 과정에서 섞이지 않도록 만든 ChromaDB 컬렉션 네이밍 규칙컬렉션 이름을 애플리케이션에서 정규화해야 하는 이유정책 문서가 변경됐을 때 기존 캐시를 무효화하는 두 가지 방법SCAN + DEL 방식 대신 버전 기반 캐시 무효화를 선택한 이유formVersion을 캐시 키에 포함해 삭제 없이 구버전 캐시를 자연 소멸시키는 방법 문제는 두 가지였다 — 격리와 갱신8편에서는..

WithBuddy 연재 8편이자 시즌 3의 시작이다. FastAPI + LangGraph 위에서 사내 문서를 기반으로 답변하는 온보딩 RAG 에이전트를 어떻게 구성했는지 정리한다. 사용자의 질문이 SCOPE 판정, ChromaDB 검색, Claude 답변 생성, 가드레일을 거쳐 최종 응답이 되기까지의 전체 흐름을 살펴본다.이 글에서 다루는 내용단일 LLM 호출이 아니라 노드 그래프로 RAG 파이프라인을 구성한 이유회사 업무 범위를 벗어난 질문을 걸러내는 SCOPE 라우터ChromaDB 컬렉션 단위로 멀티테넌트 데이터를 격리한 방법잘못된 정책 답변과 과도한 확정 표현을 줄이는 3단 가드레일검색에 실패했을 때 추측하지 않고 안전하게 폴백하는 방식왜 단순 챗봇이 아니라 에이전트였나WithBuddy가 해결하려는..

WithBuddy 연재 7편이자 시즌 2의 마지막 글이다. 반복적인 폴링 구조를 걷어내고 RabbitMQ 기반 비동기 처리 구조로 전환한 과정, 그리고 실패한 메시지가 유실되지 않도록 DLQ(Dead Letter Queue), 멱등성, 재시도 정책을 설계한 과정을 실제 설정과 검증 결과를 바탕으로 정리한다. 이 글에서 다루는 내용왜 Redis 기반 폴링 구조를 줄이고 RabbitMQ 비동기 처리로 전환했는지알림 큐와 분석 큐의 TTL·prefetch를 다르게 설정한 이유실패한 메시지를 유실하지 않는 DLQ 격리 구조와 적용 방법Redis SETNX + DB UNIQUE 제약으로 중복 처리를 막는 방법1,000건 부하 검증 결과와 DRY_RUN 테스트가 가진 한계왜 비동기였나 — 폴링에서 발생하는 불필요..

WithBuddy 연재 6편. L1(Caffeine) + L2(Redis) 하이브리드 캐시를 적용해 캐시 히트 경로의 p95를 1,643ms에서 263ms까지 줄였다. 이번 글에서는 왜 Redis 단독 구성이 아니라 2단 캐시를 선택했는지, 캐시에서 발생할 수 있는 장애를 어떻게 방어했는지, 그리고 “6.2배 빨라졌다”는 결과를 어디까지 신뢰할 수 있는지 함께 정리한다. 이 글에서 다루는 내용Redis 단독 대신 Caffeine + Redis 2단 캐시를 선택한 이유Cache Stampede, Penetration, 연쇄 장애와 이를 막기 위한 방어 장치캐시 히트 경로 p95를 약 84% 단축한 측정 결과“6.2배 개선”이라는 수치를 해석할 때 반드시 함께 봐야 할 검증의 한계 Redis만으로는 부족했던..

WithBuddy 연재 5편, 시즌 2의 시작. SSE 채팅 부하테스트에서 실패율 65%가 나왔는데 CPU는 놀고 있었다. 이 모순을 추적해 HikariCP 커넥션 풀 고갈을 범인으로 특정하고, p95를 67초에서 9.94초로 되돌린 진단 과정을 처음부터 끝까지 기록한다. 이 글에서 다루는 것"CPU가 낮은데 요청이 실패한다"는 모순을 어떻게 추적했는지HikariCP 지표(active/idle/waiting)로 커넥션 풀 고갈을 특정하는 법SSE + 비동기 AI 응답이 왜 커넥션을 오래 점유하는지풀 크기를 키우되 그것을 Golden Image에 영구 반영해야 하는 이유시작은 오토스케일링 검증이었다4편에서 온디맨드 오토스케일링을 붙였다. 이제 이게 실제로 부하를 견디는지 검증할 차례였다. k6로 SSE..

\WithBuddy 연재 4편. CPU 임계값이 아니라 Grafana 알람을 트리거로 OCI Instance Pool을 켜고, Load Balancer로 트래픽을 분산한 온디맨드 오토스케일링을 만든 과정. 그리고 CPU 기반 스케일링만으로는 절대 못 잡는 병목을 실측으로 확인한 이야기. 이 글에서 다루는 것평상시 추가 서버 비용을 0원으로 유지하는 온디맨드 스케일링 설계Golden Image → Instance Configuration → Instance Pool로 이어지는 자동 확장 파이프라인Grafana 알람 → Webhook → OCI CLI로 Pool을 켜는 구조CPU는 멀쩡한데 SSE 실패율이 65%였던 이유 — HikariCP 커넥션 풀 병목문제 — 부하가 와도 수동 대응만 가능했다3편까지..

WithBuddy 연재 2편. CI/CD 배포를 위해 열어둔 SSH 22번 포트를 단계적으로 없애고, 최종적으로 SSH 키까지 제거한 과정을 실제 설정과 함께 정리한다. 이 글에서 다루는 것GitHub Actions 배포에서 SSH 22포트가 왜 공격 표면이 되는지Cloudflare Tunnel로 인바운드 포트를 0개로 만드는 구체적 설정GitHub OIDC로 SSH 개인키를 Secrets에서 완전히 없애는 방법실무에서 놓치면 다시 Permission Denied / Timeout을 만나는 3가지 함정왜 22포트를 닫아야 했나WithBuddy는 OCI Free Tier 서버 위에서 돌아간다(1편 참고). 배포는 GitHub Actions에서 SSH/SCP로 JAR을 밀어넣는 방식이었다. 그런데 GitHu..

WithBuddy 연재를 시작한다. 첫 편은 아키텍처 다이어그램이 아니라, 그 다이어그램이 왜 그 모양이 될 수밖에 없었는지에 대한 이야기다.발표 자료에는 "의도적으로 설계된 Modular Monolith"라고 적혀 있었다. 틀린 말은 아니지만, 정확한 말도 아니다. 실제로는 예산이 없어서 시작된 구조였다. 그리고 나는 그 사실을 숨기는 것보다 그대로 쓰는 편이 더 설득력 있다고 생각한다.50만 원을 어디에 쓸 것인가팀 자체 예산은 0원이었다. 빌더스리그에서 지원되는 50만 원이 우리가 쓸 수 있는 전부였다.이 돈을 어디에 쓸지가 첫 번째 의사결정이었다. 팀원 전체가 Claude, ChatGPT 같은 AI 개발 도구를 구독하면 생산성이 확실히 올라간다. 하지만 인프라에 돈이 나가기 시작하면 그만큼 구독 ..

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 실제 경험 후기입니다.왜 'AI기초체력훈련'을 선택했는가AI를 배워야 한다는 건 누구나 알고 있다. 문제는 어디서부터 시작하느냐다.이론만 가득한 강의는 듣다 지치고, 그렇다고 처음부터 LLM 파인튜닝이나 프롬프트 엔지니어링 프로젝트에 뛰어들기엔 진입 장벽이 높다. 나 역시 같은 고민을 안고 있었고, 그때 눈에 들어온 게 '구름 AI기초체력훈련'이었다.국민내일배움카드로 90% 지원을 받으면 자비 부담금이 42,880원이다. 8주(67일) 동안 AI 윤리 기초부터 실제 동작하는 웹앱 완성까지 단계별로 밟아갈 수 있는 구성인데, 이 가격이면 솔직히 부담이랄 게 없었다. 일단 신청부터 했다.100% 온라인 자율 학습 — 이게 진짜 편했다수강하면서 가장 좋았던..

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.1. ZEP과 Zoom을 넘나들었던 파이널 엑스포의 열기2026년 7월 14일부터 16일까지, 5개월간의 결실을 맺는 BUILDERS LEAGUE Final Round: Final Expo가 열렸다. 총 17개 팀이 배정된 ZEP 메타버스 공간에서 결과물을 게시하고, 자유 관람과 함께 강사님 및 심사위원들의 질의응답이 이어졌다.우리 3팀 일단모여(WithBuddy) 부스에도 수많은 훈련생과 심사위원들이 찾아왔다. 신입사원 온보딩 AI 코치 서비스로서 그동안 구축해 온 LangGraph 기반 RAG 파이프라인, Claude Haiku 비용 최적화, Redis/RabbitMQ/SSE 스트리밍 기반의 백엔드 아키텍처를 가감 없..

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.구름 부트캠프 빌더스리그 9회차에 참여하며 약 3개월 동안 팀 프로젝트를 진행했다. 우리 팀 이름은 ‘일단모여’이고, 프로젝트 이름은 ‘WithBuddy’이다.WithBuddy는 신입 사원이 입사 초기에 반복적으로 묻게 되는 질문을 사내 문서를 기반으로 답변해 주는 AI 온보딩 서비스이다.처음에는 신입 사원이 사수의 눈치를 보지 않고 편하게 질문할 수 있도록 돕는 서비스로 시작했다. 그러나 MVP 개발, 사용자 인터뷰, Round 2 고도화, 6월 26일 피벗 데이 발표를 거치면서 우리가 해결해야 할 문제와 서비스의 방향도 조금씩 달라졌다.이번 글에서는 빌더스리그를 진행하며 경험한 개발 과정과 협업, Round 2 심사 ..

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.1. 탄탄한 기술 베이스 위에 '진짜 에이전트'의 조건을 더하다MVP 중간 점검이 끝난 뒤, 우리 팀이 받아든 피드백은 예상보다 구체적이었다. 기능 자체에 대한 지적은 거의 없었다. 심사위원들이 주목한 건 그 기능들이 얼마나 에이전트답게, 비즈니스 흐름 위에서 작동하느냐였다."리서치부터 가설 검증까지 이어지는 개연성과 논리성이 탄탄하다." 당시 WithBuddy는 문서 업로드, 한국어 특화 임베딩 모델(jhgan/ko-sroberta-multitask)과 Kiwi 형태소 분석기를 활용한 쿼리 확장까지 핵심 RAG 파이프라인이 이미 안정적으로 올라와 있는 상태였다. 기술 이해도와 문서 완성도에서 좋은 평가를 받은 건 그 결..

백엔드 프로젝트에서 소스 코드는 Git으로 관리한다. 하지만 데이터베이스 구조 변경 이력은 제대로 관리되지 않는 경우가 많다.초기에는 개발자가 직접 SQL을 실행하거나, 로컬 환경에서 ddl-auto=update에 의존해도 큰 문제가 없어 보인다. 그러나 프로젝트 규모가 커지고 협업 인원이 늘어나면 다음과 같은 문제가 반복적으로 발생한다.개발자마다 DB 스키마 상태가 다르고, 운영 서버 SQL 반영이 누락되며, 컬럼 추가 순서가 충돌한다. 배포 후 DDL 실행 오류, 운영 DB와 로컬 DB 구조 불일치, 그리고 롤백 불가능 상태까지. 한 번쯤은 겪어봤을 풍경이다.이러한 문제를 해결하기 위해 사용하는 대표적인 도구가 Flyway다.이 글에서는 Spring Boot 환경에서 Flyway를 어떻게 적용하고, ..

본 콘텐츠는 구름(goorm) 서포터즈 활동 지원을 받아 작성된 실제 참여 후기입니다 솔직히 말하면, 체크포인트 당일 아침은 긴장을 했다.지금까지 쌓아온 것들이 강사님들의 눈앞에 펼쳐지는 순간이었으니까. '우리가 방향을 제대로 잡고 있는 걸까?' 그 질문이 머릿속을 계속 맴돌았다. 하지만 ZEP 구름스퀘어에 접속하는 순간, 그 긴장감은 에너지로 바뀌었다. 화면 너머로 분주하게 움직이는 15개 팀의 아바타들을 보는 것만으로도, 이게 단순한 수업이 아니라는 걸 다시 한번 실감했다. 01. ZEP 구름스퀘어에서 펼쳐진 온택트 열기비대면 메타버스 플랫폼 ZEP 구름스퀘어 JOBS 룸. 오전 9시, Sprint Time이 시작되자마자 각 팀의 분위기가 달라졌다.발표 자료를 마지막으로 점검하는 팀, 시뮬레이션을..