


C++ 분석 데이터베이스 엔진을 고치고 필요한 테스트까지 통과시키기
C++로 만든 분석 데이터베이스 엔진의 코드를 고칠 때 사용한다. AI가 SQL 파싱부터 실행까지의 흐름을 따라 고칠 곳을 찾고, 생성 파일은 원본 소스에서 고치며, C++ 작성 규칙과 오류 처리 규칙을 지키고, SQL 로직 테스트와 필요한 빌드를 모두 통과한 뒤에 마친다.
이 AI 규칙을 사용하려면
## 작업 단계에 맞춰 빌드 종류와 돌릴 테스트 고르기
일상적인 반복 작업을 불필요하게 늦추지 않으면서 유의미한 어설션과 진단을 제공하는 빌드 구성을 선택하라.
### 빌드 전략
- 필요한 검사를 유지할 수 있다면 디버그 심볼을 포함한 최적화 빌드를 일반 개발 구성으로 사용하라.
- 메모리 안전성, 어설션 실패 또는 최적화가 영향을 줄 수 있는 동작을 조사할 때는 완전히 계측된 디버그 빌드를 사용하라.
- 커밋하기 전에 저장소 포매터를 실행하라.
- 승인된 생성 대상을 통해 원본에서 파생된 파일을 다시 생성하라. 이 대상은 필요한 포매팅도 적용해야 한다.
### 테스트 전략
- 일반적인 반복 작업 중에는 빠른 단위 테스트 스위트를 실행하라.
- 범위가 명확한 변경을 진단할 때는 한 번의 실행을 하나의 테스트 파일이나 테스트 사례로 제한하라.
- 변경이 공유 동작에 영향을 줄 수 있다면 광범위한 인계 전에 느린 테스트를 포함한 전체 스위트를 실행하라.
- 지속적 통합 실패를 수정할 때는 문서화된 순서대로 필요한 각 구성을 재현하라.
- 영향을 받는 경계에서 요구한다면 구성 매트릭스, 벡터화 실행, 새니타이저, 어설션 빌드를 포함하라.
- 차이가 무관하다는 근거 없이 실패한 권위 있는 게이트를 더 빠른 로컬 구성으로 대체하지 마라.
## 고치기 전에 SQL 파싱부터 결과 반환까지 쿼리 흐름 따라가기
증상을 드러낸 첫 번째 모듈만 수정하지 말고 쿼리의 전체 수명 주기를 따라 동작을 추적하라.
### 파이프라인 단계
1. SQL 텍스트를 구문, 표현식, 테이블 참조 구문 트리로 파싱한다.
2. 논리 계획을 만들면서 카탈로그에 맞춰 이름과 타입을 바인딩한다.
3. 의미를 보존하는 규칙과 비용 기반 선택으로 논리 계획을 최적화한다.
4. 논리 연산자를 물리 연산자로 변환한다.
5. 벡터화된 병렬 파이프라인을 통해 물리 연산자를 실행한다.
6. 연결 및 클라이언트 컨텍스트를 통해 결과를 반환한다.
### 컴포넌트 소유권
- 문법과 파서 변환을 동기화하라. 모든 문법 규칙에는 그에 상응하는 변환이 필요하다.
- 바인딩, 타입 해석, 하위 쿼리, 논리 연산자는 플래너가 소유하게 하라.
- 옵티마이저가 관찰 가능한 의미를 바꾸지 않고 계획을 변환하게 하라.
- 물리 계획, 연산자, 표현식 평가는 실행 계층이 소유하게 하라.
- 영구 저장소, 버퍼링, 압축, 체크포인트, 미리 쓰기 로깅은 저장소 계층에 유지하라.
- 카탈로그를 스키마, 테이블, 함수, 타입에 대한 단일 진실 공급원으로 취급하라.
- 트랜잭션, 실행 취소 상태, 다중 버전 동시성 제어를 작업 예약 및 병렬 파이프라인과 분리하라.
## 데이터를 열 단위 묶음으로 처리하고 소유권 규칙 지키기
분석 엔진은 파싱된 구문, 바인딩된 표현식, 열 식별자, 물리 벡터, 소유권을 명확히 구분하는 데 의존한다.
### 데이터 흐름
- 데이터를 한 번에 한 행씩 처리하지 말고 열 기반 배치로 처리하라.
- 각 배치 열을 엔진의 벡터 추상화로 표현하라.
- 계획과 실행 전반에서 테이블 및 열 인덱스의 안정적인 쌍을 전달하라.
- 파싱된 표현식을 바인딩하지 않은 상태로 유지하고, 타입이 지정되어 바인딩된 표현식과 분리하라.
- 벡터화 표현식 실행기를 통해 바인딩된 표현식을 평가하라.
### 소유권과 타입
- 기본적으로 배타적인 스마트 소유권을 사용하라.
- 여러 수명이 실제로 요구할 때만 공유 소유권을 사용하라.
- null을 허용하는 비소유 참조와 null이 아님을 보장하는 참조를 구분하라.
- 소유권을 가진 원시 포인터를 절대 사용하지 마라.
- 타입 승격과 캐스트를 하나의 권위 있는 규칙 집합으로 처리하라.
- 타입 시스템을 우회하지 말고 확장 메커니즘을 통해 사용자 지정 타입을 추가하라.
- 트리 순회에는 방문자를, 역직렬화에는 팩토리를, 연산자·항목·표현식 계층에는 타입이 지정된 하위 클래스를 사용하라.
## 확장 기능과 생성 파일은 원본 소스에서 고치기
트리 내부 확장 기능, 외부에서 유지 관리되는 확장 기능, 생성 코드, 릴리스 산출물을 서로 다른 소유권 클래스로 취급하라.
### 확장 기능 경계
- 트리 내부 확장 기능은 명시된 원본 디렉터리에서 직접 편집하라.
- 외부에서 유지 관리되는 확장 기능은 별도 저장소에 두고, 저장소가 소유하는 변경은 지정된 패치 메커니즘을 통해 적용하라.
- 전체 확장 기능 집합 또는 명시적인 하위 집합을 빌드할 수 있도록 지원하라.
- 확장 기능 변경을 내장 기능이 사용하는 것과 동일한 핵심 인터페이스 및 타입 규칙에 대해 테스트하라.
### 생성 산출물
- API 바인딩, 등록, 설정, 직렬화 코드, 저장소 메타데이터, 메트릭, 열거형 유틸리티를 생성하는 원본 파일을 식별하라.
- 생성 산출물의 생성 결과만 편집하지 말고 그 원본을 편집하라.
- 원본을 변경한 후 승인된 생성 대상을 실행하라.
- 생성된 차이에 관련 없는 변경이 있는지 검사하고 표준 포매터로 포맷하라.
## C++ 작성 규칙을 따르고 주석은 짧게 쓰기
저수준 코드의 일관성은 소유권, 인덱스, 공개 인터페이스, 제어 흐름을 둘러싼 모호성을 줄인다.
### 코드 스타일
- 저장소의 들여쓰기 및 정렬 규칙을 사용하고 포매터로 줄 너비 제한을 강제하라.
- 플랫폼에 따라 달라지는 정수 너비보다 고정 너비 정수 타입을 선호하라.
- 오프셋, 인덱스, 개수에는 프로젝트가 지정한 인덱스 타입을 사용하라.
- 사소하지 않은 읽기 전용 객체는 상수 참조로 전달하라.
- 순회를 명확히 표현할 수 있다면 범위 기반 반복문을 선호하라.
- 조건문과 반복문에는 항상 중괄호를 사용하라.
- `const_cast`를 절대 사용하지 마라.
- 정립된 파일, 타입, 변수, 함수 명명 규칙을 따르라.
### 주석
- 주석은 짧게 유지하고 명확한 코드가 일반적인 설명을 담당하게 하라.
- 오래 유지되는 의도, 제약 또는 명확하지 않은 불변 조건을 주석으로 남겨라.
- 특정 문제에 국한된 수정 이력을 코드에 남기지 마라.
- 오프바이원 수정 같은 변경 내역은 변경 설명이나 커밋 메시지에 기록하라.
- 코드 구조와 명명으로 불변 조건을 명확히 표현할 수 없을 때만 긴 주석을 사용하라.
## 오류 종류에 따라 예외와 어설션을 고르고 SQL 로직 테스트 쓰기
쿼리를 종료해야 하는지, 복구할 수 있는지, 내부 프로그래머 결함이 발생했는지에 따라 오류 전달 경로를 선택하라.
### 오류 정책
- 파싱 오류, 객체 부재, 메모리 고갈처럼 쿼리를 종료시키는 실패에는 예외를 사용하라.
- 같은 쿼리 중에 복구할 수 있는 조건에는 반환값을 사용하라.
- 사용자 입력으로 절대 발생해서는 안 되는 프로그래머 오류에는 디버그 어설션을 사용하라.
- 위반된 불변 조건을 드러낼 수 있을 만큼 어설션을 구체적으로 작성하라.
- 예상된 잘못된 입력을 내부 어설션 실패로 바꾸지 마라.
### SQL 논리 테스트
- 쿼리 동작에는 C++ 테스트보다 선언적 SQL 논리 테스트를 선호하라.
- 반드시 성공해야 하는 구문과 반드시 실패해야 하는 구문을 따로 표시하라.
- 쿼리에 예상되는 결과 열 타입을 선언하라.
- 프레임워크의 정식 구분 기호로 쿼리 텍스트와 예상 행을 분리하라.
- 정확한 문구를 의도적으로 불안정하게 둔 경우에만 오류 텍스트에 정규식 기대값을 사용하라.
- 필요한 환경 변수를 명시적으로 선언하라.
- 기본 실행을 실용적으로 유지할 수 있도록 느린 테스트에 프레임워크의 느린 테스트 지정을 부여하라.
- 정상 경로만이 아니라 숫자, 문자열, 중첩 타입과 잘못되거나 예상하지 못한 사용법도 다뤄라.
- 제출 전에 전체 권위 테스트 스위트가 통과하도록 요구하라.
## 테스트에서 고칠 곳을 찾고 필요한 확인을 모두 마친 뒤 완료하기
편집하기 전에 테스트와 아키텍처 소유권을 사용해 기능을 찾은 다음, 변경의 영향을 받는 모든 파생 표면을 검증하라.
### 조사 순서
1. 기존 테스트를 찾아 지원되는 구문과 예상 동작을 파악한다.
2. 파서부터 바인더, 옵티마이저, 물리 계획을 거쳐 실행까지 기능을 추적한다.
3. 해당 구문, 연산자, 표현식, 카탈로그 또는 함수 타입을 찾는다.
4. 기능이 등록된 위치와 공개 선언이 있는 위치를 확인한다.
5. 저장소의 표준 코드 검색 도구로 구현 파일과 공개 헤더를 검색한다.
6. 변경된 원본에 의존하는 생성 파일과 확장 기능 표면을 식별한다.
### 완료 검사
- 광범위한 테스트 전에 범위가 명확한 회귀 테스트를 추가하거나 업데이트하라.
- 포매팅과 원본 생성을 실행하라.
- 범위가 명확한 테스트를 실행한 다음 필요한 단위, 느린, 새니타이저, 어설션, 구성, 벡터 테스트 스위트를 실행하라.
- 영향을 받는 실행 파일과 확장 기능을 빌드하라.
- 생성된 차이와 문서 소유권을 검토하라.
- 필요한 모든 게이트에 실제 결과가 나올 때까지 완료를 주장하지 마라.
