1223v

2025년 9월 5~6일에 열린 Amazon Q Developer Hackathon에 참여하게 되었습니다.“개발자라고 한다면, 코딩하는 사람이 아닌 우리의 비즈니스 문제를 해결하는 사람”요즘 개발자에 대한 정체성을 확립해 나가는차에 바이브 코딩이 어디까지 가능할지, 바이브코딩을 하며 우리가 주의 깊게 봐야하는 부분이 어디인지를 확인해보고 싶었다. 사건의 발단 왜 나가게 되었는가?처음 시작은 취준 팟에서 최근 커서와 클로드의 강력함을 깨닫고, 이거 관련해서 빠른 익혀보고, 특히 안전하고 잘 활용할 수 있게 AI 익히고자 했다.사실, AI를 활용해서 서비스를 제작해보고, 진짜 운영해 우리가 풀고자하는 문제를 정확히 이해하고자 시작했다. 서비스 소개우린 포트폴리오 기반 AI 꼬리 질문 서비스를 제작했다.h..

쿼리에서 성능까지 – 옵티마이저의 역할 이해사용자가 작성한 선언적 SQL(어떤 데이터를 원하는가)을 DBMS가 실행할 명령적 절차(데이터를 어떻게 가져올 것인가)로 변환하는 핵심적인 역할을 수행한다.이 변환의 결과물이 바로 Execution Plan이며, 이는 쿼리의 성능을 좌우하는 요소이다. 동일한 결과를 반환하는 SQL이라 할지라도 실행 계획에 따라 성능은 수십, 수백 배까지 차이 날 수 있다. 따라서 대용량 데이터베이스 환경에서 고성능을 달성하기 위한 여정은 옵티마이저의 작동 원리를 이해하고, 이와 효과적으로 협력하는 것에서부터 시작된다. SQL 실행 계획옵티마이저와 우리의 역할옵티마이저는 사용자가 작성한 SQL 문을 가장 빠르고 효율적으로 수행할 최적의 경로, 즉 실행 계획을 생성하는 DBMS..

상반기에 여러 기업에 서류가 모두 떨어지고, 제가 걸어온 길이 맞는가에 대한 의심이 되었습니다.또한 계속 이 길을 걸으면서 "이게 맞나..."라는 성장에 대한 잡생각이 머리를 잠식해서 결국 슬럼프에 빠지게도 된것 같습니다. 근데 문득 그런 생각이 들더군요..잡생각하면 뭐해.. 달라지는게 없는데.. ㅋ그냥 해야지~ 그리고 저보다 더 악한 상황에서 달리시는 분들도 있는데, 고작 1~2년 돌바닥 살짝 뛰었다고 엄살 부리는 제 자신이 너무 현타오기도 했습니다. 그래서 저를 점진적으로 갈아넣을 수 있게 계획을 짜서 움직여 봤습니다. 운이 좋게, 저와 갓생을 같이 살아줄 끈기 넘치는 친구를 만나게 됐습니다.그분과 돌아오는 네카라쿠배당토 공채를 뚫기라는 쉼없는 여정을 함께하기로 다짐했습니다. 특히, 저희는 목..

현대 관계형 데이터베이스 관리 시스템의 중심에는 B-Tree 인덱스가 자리 잡고 있다.B-Tree 인덱스는 데이터 검색, 삽입, 삭제, 그리고 범위 기반 쿼리에 대해 균형 잡힌 성능을 제공하며, 수십 년간 데이터베이스 기술의 표준으로 기능해왔다. 그 범용성과 안정성 덕분에 대부분의 데이터베이스 워크로드에서 기본적이고 효과적인 해결책으로 채택된다. 그러나 데이터의 규모가 폭발적으로 증가하고 애플리케이션의 요구사항이 복잡해짐에 따라, B-Tree 인덱스만으로는 해결하기 어려운 특정 성능 병목 현상들이 나타나기 시작했다. 높은 동시성 환경에서의 삽입 경합(High-Concurrency Insert Contention) 문제온라인 트랜잭션 처리 시스템에서 주문 번호나 로그 시각처럼 순차적으로 증가하는 값을 인..

왜 더 나은 트리가 필요한가…대부분의 데이터베이스 시스템에서 성능 병목 현상은 CPU나 메모리보다 디스크 입출력(I/O)에서 발생디스크에서 데이터를 읽어오는 시간은 크게 세 부분으로 구성자기 디스크의 헤드를 원하는 트랙으로 이동시키는 탐색 시간(seek time)원하는 섹터가 헤드 아래로 회전해 올 때까지 기다리는 회전 지연 시간(rotational latency)실제 데이터를 전송하는 시간(transfer time) 이 중 탐색 시간과 회전 지연 시간이 데이터 전송 시간에 비해 압도적으로 길기 때문에, 디스크 I/O의 총비용은 데이터의 양보다 접근 횟수에 의해 결정이러한 물리적 제약은 메모리 내에서 효율적으로 동작하는 자료 구조가 디스크 환경에서는 비효율적으로 변하는 주된 이유 대표적인 예가 이진 탐색..

어쩌다 Collection이 등장했는가..? 문제점 : 배열의 한계생성 시 크기가 고정된다는 점이다.이로 인해 불특정한 수의 객체를 저장하기 어렵고, 예상보다 데이터가 많아지면, 배열을 새로 생성하고 기존의 데이터를 복사해야하는 번거로움이 발생한다.반대로, 데이터를 삭제하면 해당 인덱스 공간이 비어 메모리 낭비가 발생.데이터 삽입, 삭제, 검색과 같은 고수준의 데이터 조작을 위한 편리한 메서드를 기본적으로 제공하지 않아 개발자가 직접 구현해야함. Collection 이전 시대자바에는 Vector, Hashtable과 같은 클래스들이 존재했음.데이터 그룹을 관리하는 기능을 제공하지만, 각기 다른 방식으로 처리되어 일관성 부족.표준화된 설계 부재각 클래스의 사용법을 개별적으로 익혀야 함→ 상호 운용성도 떨어..

클러스터링 테이블: 데이터 공동 위치의 원칙데이터베이스 성능 튜닝의 궁극적인 목표 중 하나는 I/O를 최소화하는 것이다. 클러스터링 테이블은 데이터의 물리적 공동 위치(co-location)를 강제하여 이 목표를 가장 직접적으로 달성하는 구조이다. 클러스터링 테이블의 기본 개념Cluster는 하나 이상의 테이블 데이터를 공유된 cluster key 값을 기준으로 물리적으로 같은 데이터 블록에 함께 저장하는 스키마 객체이다. 클러스터링의 근본적인 목적은 자주 함께 조회되는 데이터를 물리적으로 한곳에 모아둠으로써 I/O를 획기적으로 줄이는 것이다.IOT가 테이블의 한 종류인 것과 달리, 클러스터는 먼저 독립적인 저장 공간 컨테이너로 생성된 후, 그 안에 테이블들이 소속되는 방식으로 구성된다. 클러스터링을 ..

인덱스 일체형 테이블(IOT): 데이터와 인덱스의 통합분리형 테이블의 구조적 한계를 극복하기 위해 등장한 인덱스 일체형 테이블(Index-Organized Table, IOT)은 테이블과 인덱스의 경계를 허무는 혁신적인 아키텍처이다. 이 구조는 특정 접근 패턴에서 압도적인 성능을 제공하지만, 그에 상응하는 새로운 제약과 복잡성을 가진다. 분리형과 일체형의 비교IOT의 특징을 명확히 이해하기 위해, 먼저 분리형 테이블과의 구조적, 기능적 차이점을 비교 분석하는 것이 중요하다.분리형 테이블과 인덱스 일체형 테이블(IOT)의 비교 분석특징분리형 테이블 (Heap-Organized)인덱스 일체형 테이블 (IOT)데이터 저장 방식데이터와 인덱스가 별도의 세그먼트에 저장됨데이터와 인덱스가 기본키(PK) B-Tre..

분리형 테이블(Heap-Organized Table): 전통적인 표준 모델관계형 데이터베이스 시스템에서 가장 보편적으로 사용되는 테이블 구조는 데이터와 인덱스가 물리적으로 분리된 분리형 테이블이다.이 구조는 데이터 입력(INSERT) 속도에 최적화되어 있어 다양한 워크로드에서 안정적인 성능을 제공하지만, 특정 데이터 접근 패턴에서는 비효율을 초래하기도 한다. 분리형 테이블의 구조분리형 테이블 구조의 핵심은 테이블 데이터와 인덱스 데이터가 각각 독립된 저장 공간, 즉 세그먼트에 저장된다는 점이다.이러한 물리적 분리는 관계형 데이터베이스의 가장 일반적인 데이터 저장 형식으로, 대용량 데이터를 관리하는 데 있어 높은 유연성과 효율성을 제공한다. 저장소 계층 구조 분석분리형 테이블의 데이터는 다음과 같은 계층..

문제 발견redis를 사용하면서 인덱스를 사용할 일이 있었는데, 문득 TTL로 만료를 시키면 인덱스를 설정한 값은 인덱스의 값이 지워질까라는 의문이 들었다. 댕글링 인덱스인덱스는 남아 있지만, 그 인덱스가 가리키는 실제 데이터는 사라진 상태끊어진 포인터만 허공에 둥둥 떠다니는 ( dangling ) 모습과 같다고 해서 붙여진 이름 왜 발생해?근본적으로 Redis가 데이터와 인덱스를 완전히 별개의 키로 취급하기 때문이다. 주로 데이터에만 만료시간을 설정했을 때 발생한다. 시나리오 1. 데이터와 인덱스 생성데이터 = user:100 -> { name: "홍길동", ... } (30분 뒤 자동 삭제)인덱스 (도서 카드) = user:email:test@example.com -> {"100"} 2. 데이터..