SQL 기술 블로그 최신 글
SQL 쿼리, 데이터 모델링과 분석·서비스 운영 사례를 다룬 회사 기술 블로그 글입니다.
SQL 관련 최신 기술 블로그 글
검색해도 안 나오는 SQL을 새로 만들다
K-Metrics 제작 후기 #2 검색해도 안 나오는 SQL을 새로 만들다 최고운 AX팀 AI로 더 나은 일하는 방식을 고민하는 AI 엔지니어 업무의 언어를 이해하고, 함께 쿼리를 고치기까지 지난 편에서는 동료들이 업무에서 사용하고 확인한 쿼리를 모아, 자연어로 찾아 재사용하는 이야기를 했어요. 등록된 쿼리로 답할 수 있는 질문이라면 새 SQL을 만들지 않고도 업무를 시작할 수 있죠. 그렇다면 검색이 “못 찾았어요”라고 답한 요청은 어떻게 처리할까요? 등록된 쿼리가 다루지 않는 대상을 조회하거나, 다른 기준으로 집계해야 한다면 새로운 SQL이 필요합니다. 이번 편은 그다음을 다룹니다. 검색으로 답하기 어려운 요청을 K-Metrics가 어떻게 새로운 SQL로 만드는지, 그 과정에서 업무 용어를 해석하고 필요한 조건을 사용자와 확인하는 방법을 살펴볼게요. 만들어진 쿼리를 업무 의도에 맞게 이어서 고치는 과정도 함께 다룹니다. SQL 한 번을 생성하는 것만큼, 그 SQL을 사용자의 업무 의도에 맞게 다듬어 가는 과정에 집중했습니다. 질문이 SQL이 되기까지 “지난달 A상품 신규 가입 고객 수를 연령대별로 보여 줘”라는 요청을 예로 들어볼게요. 이 질문에 답하려면 무엇을 셀지, 어떤 데이터를 사용할지, 기간과 집계 기준을 어떻게 적용할지 정해야 합니다. K-Metrics는 질문을 요구사항으로 나누고, 테이블·컬럼과 조건을 정해 SQL을 작성한 뒤 검증해요. 문제가 있으면 필요한 단계로 돌아가고, 재시도 한도 안에서 해결되지 않으면 남은 문제를 정리해 반환합니다. SQL 생성과 검증·재시도 흐름 이 과정을 모델에게 한 번에 맡기지 않고 여러 단계로 나눈 데에는 이유가 있습니다. 왜 자율 에이전트보다 단계별 워크플로우가 필요했을까? 검색이나 스키마 조회를 도구로 제공하고, 모델이 다음 행동을 선택하도록 만들 수도 있습니다. 판단하고 도구를 사용한 뒤 그 결과로 다음 행동을 정하는 ReAct 방식이라면, SQL 생성 외의 정보 탐색까지 유연하게 연결할 수 있죠. 다만 이 서비스에서는 그 자유도보다 운영 중 처리 과정을 추적하고 통제할 수 있는 구조가 더 중요하다고 봤어요. 그 출발점은 모델에게 한 번에 맡기는 판단의 범위를 정하는 일이었습니다. 온프렘 LLM의 제한된 컨텍스트를 효율적으로 쓰기 위해 작업을 작은 목표로 나눴어요. 테이블을 고를 때는 요구사항과 후보 설명을, SQL을 작성할 때는 선택한 스키마와 확정된 계획을 전달합니다. 각 단계가 해야 할 일과 필요한 정보를 함께 좁힌 것이죠. 작업을 나누고 나니, 단계 사이에서 반드시 지켜야 할 순서도 분명해졌습니다. 특히 생성한 SQL의 검증을 모델에게 도구로 주고 ‘필요하면 호출해’라고 맡기고 싶지는 않았어요. SQL 작성 뒤에는 구조 검증으로 이어지고, 결과에 따라 의도 검증이나 수정으로 넘어가도록 경로를 정했습니다. 모델이 복구 방향을 제안하더라도, 이동할 수 있는 단계와 재시도·종료 조건은 코드가 관리하도록 했어요. 자율 에이전트와 단계별 워크플로우의 차이 이렇게 단계와 경로를 명시하면, 결과가 잘못됐을 때 되짚을 지점도 생깁니다. 최종 SQL만 보는 대신 요구사항 해석·테이블 선택·컬럼 매핑의 중간 결과를 따라가며 어느 판단에서 문제가 시작됐는지 확인할 수 있어요. 단계별 입출력을 기준으로 프롬프트 수정과 테스트의 출발점도 좁혀 볼 수 있습니다. LangGraph는 이 설계를 실행 흐름으로 옮기는 데 사용했습니다. 단계별 결과는 상태로 전달하고, 검증 결과에 따라 앞 단계로 돌아가는 분기와 반복은 조건부 연결로 표현했어요. LangGraph로도 자율 에이전트를 만들 수 있고, ReAct에도 검증과 재시도 제한을 붙일 수 있습니다. 결국 선택의 핵심은 프레임워크의 우열이 아니라, 판단은 모델에 맡기되 반드시 거쳐야 할 검증과 재시도·종료 조건은 코드로 관리하겠다는 것이었어요. 사내에서 쓰는 용어를 실제 조건으로 만들기 생성 흐름을 나눴다고 해서 모델이 우리 행의 업무까지 이해하지는 못 합니다. 사용자가 평소 쓰는 줄임말도 알아들어야 하고, 짧은 요청에 생략된 업무 기
케이뱅크 공식 블로그2026년 11월 3일쿼리가 아니라 정의를 고치기로 했습니다: Databricks Metric View 도입기
Metric View를 신규 런칭 게임의 데이터 파이프라인에 도입하면서, 대시보드와 분석 에이전트가 같은 지표 정의를 읽게 하기 위해 데이터 구조를 어떻게 나눴는지, 그 과정에서 정한 설계 규칙과 결과를 공유합니다.
Devsisters 기술 블로그2026년 9월 18일Querydsl 대량 데이터 처리 완전 정리: Count 병목부터 커서 기반 페이지네이션, Batch Insert/Update까지
Count 쿼리 병목부터 Offset 풀 스캔 문제, 커서 기반 페이지네이션, Batch Insert/Update까지 — 실측 데이터로 검증한 Querydsl 대량 데이터 처리 전략을 정리합니다.
카카오페이 기술 블로그2026년 9월 16일AI가 쓴 SQL을 안전하게 쓰는 법
자연어 질문을 SQL로 바꾸고, 고객 데이터에 실행해도 되는 답으로 만들기까지
아임웹 테크2026년 6월 22일빌링 3.0 성능 이슈 개선 기록 - Part 1
1. 들어가며 최근 안랩클라우드메이트의 SD파트는 '빌링 3.0' 서비스 고도화 작업을 수행하였습니다. SD파트는 이번 작업을 통해 서비스 오픈 후 발생한 대량 인보이스 발송 시의 성능 저하 문제를 분석하고 해결하였습니다. 예상치 못한 DB 쿼리 타임아웃, 커넥션 고갈, 외부 API 연동 지연 등 실제 운영 환경에서 마주할 수 있는 기술적 난제들을 복합 인덱스 생성, 커넥션 풀 설정 최적화, 프론트엔드 로직의 배치 처리 방식 도입 등을 통해 단계적으로 풀어나가며 트러블슈팅을 한 경험을 이번 포스팅을 통해 공유해보겠습니다. 2. 성능 이슈 발생 SD 파트는 지난 해 가을 고객사를 대상으로 새로 개편된 빌링 포털 서비스를 오픈하였습니다. 서비스 오픈 후 몇 가지 예상치 못한 이슈가 있었는데요. 그중 하나가 매월 청구 시기마다 인보이스 200건 정도를 일괄 발송할 때 성능 저하가 발생하는 이슈였습니다. 여러 시행착오 끝에 성능 저하 이슈를 어느 정도 해결할 수 있었습니다. 관련해 1편에서는 발생한 문제 해결 방법을 먼저 알아보고 2편에서는 OpenTelemetry와 Azure Application Insights를 활용한 관측 가능성(Observability) 구축과 K6를 활용한 부하 테스트로 추가적인 문제를 미리 확인하여 개선한 사례를 소개하겠습니다. 3. 발생한 이슈의 정체 당시 운영 중인 빌링 3.0에서 발생한 이슈는 매달 청구서를 발행할 때 발견되었습니다. 서비스 오픈 후 사내 청구 담당자가 발송 대상 청구서를 모두 선택해 일괄 발송을 진행했습니다. 그런데 오픈 전 테스트와 달리 대부분의 청구서 발행 및 이메일 발송이 정상적으로 처리되지 않는 문제가 발견되었습니다. 기존에 구현된 청구서 발송 로직은 건별로 따로 이메일 발송을 요청하는 형태였습니다. 오픈 전 10건 이하로 테스트할 때는 문제가 없었습니다. 그런데 실제 운영 환경에서 200건 이상을 동시에 요청하자 다음과 같은 복합적인 문제가 발생하며 정상적으로 처리되지 않았습니다. ● 건별 인보이스 데이터 조회 시 DB 쿼리 타임아웃 오류 발생 ● 이메일 발송 시 SMTP 서버 업체의 전송 제한(Rate limit)으로 인한 발송 지연 ● 이메일 발송 등에 필요한 사용자 및 고객사 정보 조회 시 DB 최대 커넥션 초과 오류 발생 4. 원인 파악하기 원인을 파악하기 위해 인보이스가 발송되는 과정을 먼저 다시 한번 확인해 보았습니다. 당시 빌링 3.0에서 사용자가 발송할 인보이스를 선택하고 발송을 누르면 다음과 같은 작업이 수행되었습니다. 발송 대상 인보이스의 체크박스를 활성화하여 선택합니다. 이때 선택한 인보이스 정보를 가져오기 위해 백엔드 API를 호출합니다. 발송 버튼을 누르면 선택한 항목들에 대해 다음 작업을 수행합니다. 프론트엔드에서 각 인보이스 PDF 파일을 렌더링합니다. 백엔드의 발송 API를 호출합니다. 인보이스 ID, 공급자/공급받는 자 식별코드, PDF 파일 등을 요청 본문(Request Body)에 담아 일괄 발송을 요청합니다. 백엔드에서는 해당 인보이스의 기본 정보를 조회하고 이를 바탕으로 이메일 발송에 필요한 고객사 및 담당자 정보를 IAM 서비스 API로 조회합니다. 각 인보이스별로 이메일을 발송한 후 결과값을 정리하여 반환합니다. 실제로 200건 정도를 선택해 실행해 보니 발송 단계에 진입하기 전 인보이스 조회를 동시에 여러 건 호출하면서 문제가 발생했습니다. 이전에도 10건 이하를 선택했을 때 조회가 수 초 정도 소요되긴 했으나 한번에 200건의 조회가 몰리자 쿼리가 정상적으로 수행되지 못하고 타임아웃이 발생한 것입니다. 이 문제를 해결한 후에도 실제 발송 과정에서 다시 오류가 발생했습니다. 발송 전 필요한 정보를 IAM에서 조회할 때 처음 수십 건은 처리되었으나 이후 응답이 지연되거나 IAM 측 DB에서 'Too many connection' 오류가 발생했습니다. 5. 인보이스 조회 시 쿼리 타임아웃 해결하기 먼저 인보이스 목록에서 약 200건의 항목을 체크할 때 발생하는 대량의 API 응답 오류부터 해결하고자 했습니다. 이럴 때 흔히
ACME Tech Blog2026년 3월 10일Text2SQL 기반 데이터 분석 서비스 InsightLens 개발기
오늘날 기업 환경에서 데이터 기반 의사결정의 중요성은 아무리 강조해도 지나치지 않습니다. 기획자, 마케터, 운영 담당자 등 비개발 직군에서도 데이터 조회에 대한 니즈가 급증하고 있으며, 원하는 시점에 원하는 데이터를 얼마나 빠르게 확보할 수 있느냐가 비즈니스 경쟁력을 좌우하는 시대가 되었습니다. 하지만 기존 데이터 추출 프로세스를 살펴보면, SQL…
SK플래닛 TECH TOPIC2026년 2월 24일슬로우 쿼리 해결기: 함수형 인덱스로 비트 연산 쿼리 최적화하기
들어가며안녕하세요. LINE VOOM 서비스의 포스트 서버를 개발하고 있는 서용준입니다. 이번 글에서는 저희 팀이 약 7개월에 걸쳐 슬로우 쿼리 문제를 해결한 과정과 그 과정에서 ...
LY Corporation Tech Blog2026년 2월 13일설치 없이 SQL·Java·Git·AWS 연습하는 웹 서비스 개발기
저는 혼자서 학습하기 위해 데이터베이스를 설치하지 않고도, SQL을 연습할 수 있는 웹 서비스를 만들기 시작했습니다. 문제에 필요한 데이터를 미리 준비해 두고, 사용자가 브라우저에서 문제를 열면 곧바로 쿼리를 실행할 수 있게 했죠. 서비스를 공개하고 나니, SQL 외의 다른 기술도 복잡한 준비 없이 연습할 수 있게 만들고 싶어졌습니다. 이 글은 단순히 제가 만든 서비스를 소개하려고 쓴 글이 아닙니다. 대신 만드는 과정에서 설치 없이 연습하는 환경에서 학습자는 무엇을 배울 수 있고, 무엇은 배울 수 없을까? 화면에 성공 표시가 떴을 때, 그 성공은 무엇을 보증할까? 이 글에서는 이 질문들에 답하려고 내린 판단과, 그 판단 때문에 생긴 한계를 함께 정리해 보려고 합니다.
DB 설치와 데이터 준비 없이 SQL을 연습할 수 없을까?
대학교에서 SQL을 처음 배울 때, 저는 SELECT 문보다 설치 화면을 먼저 오래 봤습니다. 문법을 외워도 연습할 데이터가 없으면 JOIN도 GROUP BY도 연습할 수 없었죠. 그래서 DB 설치와 데이터 준비 없이 브라우저에서 바로 SQL을 실행할 수 있는 서비스 'NULL지마'를 만들었습니다. sql.js로 SQLite를 브라우저에서 돌리고, 6개 테이블로 관계를 채운 뒤 문자열이 아니라 실행 결과와 변형 데이터로 재검증하는 채점 로직을 붙인 과정을 정리했습니다.