들어가며금융·공공기관 시스템을 개발하면서 두 번의 CI 암호화 전환 프로젝트를 경험했다.두 프로젝트 모두 개인정보인 CI를 암호화한다는 점은 같았다. 하지만 실제 개발 과정에서 고민해야 했던 문제는 달랐다.첫 번째 프로젝트에서는 고객사가 제공한 암호화 솔루션을 사용했다. 암호화 알고리즘이나 키 관리 방식은 이미 정해져 있었고, 개발자는 제공된 방식에 맞춰 암호화와 복호화 기능을 연계하면 됐다. 이때 가장 큰 고민은 암호화 방법 자체가 아니었다.운영 DB에 저장된 약 650만 건의 CI를 서비스에 영향을 주지 않고 어떻게 안전하게 전환할 것인지가 핵심이었다.반면 두 번째 프로젝트에서는 자사 MariaDB에 적용할 별도의 암호화 솔루션이 없었다.“개인정보를 암호화해야 한다”는 요구를 실제 코드와 DB 구조에..

계기사실 이 부분을 진지하게 파본 적은 없었다. 2026년 상반기 초, 협업 프로젝트에서 프론트 쪽이 "API가 자꾸 안 붙는다"는 얘기를 했을 때 이것저것 찾아보며 시키는 대로 CORS 설정하고 프론트 담당자에게 proxy 설정을 요청 한 게 전부였다. 이해하려고 해도 완벽하게 되진 않고, 단순히 회사에서 해왔던 CORS 설정을 그대로 가져다 쓰는 정도였다. 그땐 "설정하니까 되네" 정도로 넘어갔다.이번 공모전 프로젝트에서 프론트-백엔드를 혼자 처음부터 세팅하다 보니, 그때 왜 그런 설정을 했었는지가 뒤늦게 이해됐다. 이론보다 역시 체감하는 게 다르다.겪었던 문제와 정리한 내용을 기록해본다.문제 상황frontend : http://localhost:5173 (Vite)backend : http://l..

백엔드 개발을 하다 보면 처음엔 "기능이 돌아가면 됐지"라고 생각하게 된다. 그러다 운영 환경에서 데이터가 쌓이고, 어느 날 조회 하나가 60초씩 걸리기 시작했다.이 글은 그 경험에서 시작해서, 인덱스를 이해하고 실제로 적용하기까지의 과정을 정리한 글이다.인덱스란?인덱스는 테이블 데이터와 별도로 관리되는 정렬된 색인 구조다.책의 목차를 생각하면 이해하기 쉽다. 책에서 특정 내용을 찾을 때 처음부터 끝까지 읽지 않고 목차에서 페이지 번호를 먼저 찾듯이, DB도 인덱스에서 위치를 먼저 찾고 해당 row로 바로 이동한다.PK나 자주 검색하는 컬럼에 인덱스를 걸면 DB는 해당 컬럼 값과 실제 데이터 위치를 별도로 저장한다. 조회할 때는 테이블 전체를 훑지 않고 인덱스에서 값을 먼저 찾은 뒤 실제 row 위치로 ..

국비 수강 시절, 공부 습관이 약했던 나를 붙잡기 위해 캠스터디를 시작했다. 캠을 켜놓고 목표 시간에 맞춰 공부한 뒤 인증하는 방식이었다. 그게 벌써 4년이 넘었다. 지금은 약 22명을 관리하는 방장이 되어 있다. 문제는 어느 순간부터 "공부"보다 "운영"이 더 힘들어졌다는 점이었다.매일 반복되는 수작업들각 스터디원의 공부 시간 확인병가/시험/월휴 같은 예외 처리벌금 계산 후 1/N 정산 및 입금 관리 매일 이렇게 올라오는 단톡방 인증 캡처를 하나하나 확인하고, 다음 날 처리를 해야 했다. 수작업이다 보니 실수도 있었고, 휴가를 다녀온 날 이후엔 밀린 업무처럼 긴 시간을 쏟아야 했다. (솔직히 이게 제일 두려웠다.) 시간을 거짓으로 제출하는 경우도 있어 모든 인증 사진을 직접 대조해야 했다. 그리고 무..

대량 발송 시스템이나 예약/결제 시스템처럼 요청이 순간적으로 몰리는 서비스에서는 단순히 코드를 빠르게 작성하는 것보다, 요청을 어떻게 분산하고 실패를 어떻게 처리할지 설계하는 것이 중요하다.이번 글에서는 동기/비동기 처리, 메시지 큐, DLQ, 멱등성, 멀티스레드, DB 커넥션 풀 개념을 대량 발송 시스템 관점에서 정리한다.1. 동기 처리와 비동기 처리동기 처리는 요청한 작업이 끝날 때까지 호출한 쪽이 기다리는 방식이다.예를 들어 이메일 발송을 동기 방식으로 처리하면 다음과 같다.사용자 요청→ DB 저장→ 이메일 발송 API 호출→ 이메일 발송 완료→ 사용자에게 응답이 구조에서는 이메일 발송 API가 느리면 사용자 응답도 같이 늦어진다.외부 업체 API가 일시적으로 느려지거나 장애가 발생하면 전체 요청 ..

1. 배경관리자 화면에서 공연을 등록할 때, 회차나 이미지가 늘어나면 클라이언트에서 30초 타임아웃이 발생했다.서버 로그와 DB를 확인해보니 S3 업로드와 DB 반영은 타임아웃 이후에도 계속 진행되어 결국 완료되는 경우가 있었다. 즉, "요청은 실패로 보이는데 데이터는 들어가 있다" 는 불일치 현상이 발생했고, 이를 해결하는 과정을 정리했다.2. 원인 정리2.1 긴 요청 처리 시간createShow() 하나를 호출하면 아래 작업들이 순차적으로, 하나의 트랜잭션 안에서 실행되고 있었다.[단일 @Transactional 범위]① S3 포스터 업로드 ← 네트워크 I/O② DB: Show INSERT③ S3 상세이미지 업로드 × N장 ← 네트워크 I/O × N (순차 처리 시 ..

이전에 RDS로 띄우고 5일만에 7만원정도 비용이 나온적이 있었다. 그땐 급하기도 했고, 내가 뭔가 잘못 설정했었겠지 란 생각에 이번 프로젝트에서 최소 비용으로 도전하고 싶었다. 연결 자체는 AWS는 참 쉬운 듯 보였으나 보안을 위해 RDS를 프라이빗 서브넷(Private Subnet)에 넣었더니, 로컬 IntelliJ에서 DB 연결하는 과정이 거의 첩보 작전 수준이었다. SSH 터널링 설정하랴, 보안 그룹(Security Group) 열어주랴 그 외 2일 정도를 이것저것 도전하는 사이 비용이 누가봐도 이대로라면 10만원 넘겠더라. "이럴 거면 차라리 가성비로 가자." RDS를 과감히 정리하고, 기존에 이용하던 외부 DB 서비스인 Aiven을 이용하는 걸로 변경했다.1.가성비 아키텍처: ALB 없이 NA..

토이 프로젝트를 활용해 Terraform과 Packer를 이용한 인프라 자동화를 구축하며 겪은 시행착오와 '비싼' 배움의 기록을 정리했다. 단순히 기술을 나열하는 것이 아니라, 이 과정이 얼마나 정교한 설계와 책임감을 요하는지 깨달은 시간이었다. 1. Packer와 Terraform, 이 둘은 뭐가 다를까?가장 먼저 두 도구의 역할을 명확히 이해하는 게 중요했다.Packer (The Baker): 서버의 '원형'인 AMI(Amazon Machine Image)를 만드는 도구다. 운영체제 위에 필요한 소프트웨어(Java)를 설치하고, 애플리케이션(app.jar)을 미리 담아 언제든 바로 실행 가능한 '밀키트' 상태로 포장하는 역할을 한다.Terraform (The Architect): Packer가 만든 ..

또또또 부과됐다. AWS 해볼까 할 때마다 단기간에 이렇게까지 나올수있나 싶다.이번에는 인강 들으면서 켜놨던 리소스를 제대로 종료하지 않았고 다음 날이라도 확인했었야했는데, root계정으로 로그인을 하지 않다보니 시간이 지나서 확인하여 생긴 문제 ㅠ ㅠ재빨리 대시보드로 일정 예산 금액 넣으면 알림이 오게 해놨다.. 지금 이런 경험으로 AWS 구축에 오기가 생긴다!!01. 왜 이런 설계를 선택했나포트폴리오지만 실무처럼 — FinOps 마인드셋으로 설계한 이유포트폴리오 프로젝트라도 AWS를 실무처럼 띄워놓고 방치하면 한 달에 수십만 원이 과금될 수 있다. 비용과 트레이드오프를 명확히 인지하고, 어떻게 비용을 억제하면서 실무급 아키텍처를 구성했는지 기록하는 과정이다. 핵심 전략 Terraform IaC로 전체..

1. RAG vs 파인튜닝(Fine-Tuning): 목적이 완전히 다르다둘의 개념을 처음 받아들였을 때 둘 다 AI교육을 하는건데 구분을 하기가 헷갈렸다. RAG (검색 증강 생성): "외부 DB 조회 (오픈북 테스트)"개념: 질문이 들어오면 사내 DB나 문서를 먼저 검색한 뒤, 그 내용을 프롬프트에 끼워 넣어 대답하게 하는 방식이다.특징: 지식이 바뀔 때마다 데이터베이스나 데이터셋을 새로운 정보로 업데이트하기만 하면 된다. 출처 확인이 가능해 신뢰도가 높고 환각(거짓말)을 줄일 수 있다.깨달음: "최신 팩트와 정보"가 필요하다면 무조건 RAG를 써야 한다.실생활 활용 사례고객 지원 챗봇 (FAQ): 특정 분야 내의 질답(FAQ)을 처리할 때 주로 사용사내 규정 및 매뉴얼 검색: "올해 바뀐 연차 수당 ..