fix(core,board,ecommerce,page,gdpr,ckeditor5,kginicis,admin_basic,basic): 목록 조회·검증 계층 정비 및 감사 지적 전건 처리

목록 조회 성능 축(깊은 OFFSET·정렬·색인)과 그 검증 계층에서 계획서 전수검수와 3회에 걸친
감사가 지적한 항목을 처리했다. 세부 경위는 의 각 회차 문서에 있다.

검증 계층 — 컨트롤러가 base Request 를 직접 주입받던 확장 13곳을 전용 FormRequest 로 옮겼다.
옮기면서 기존 동작 계약은 그대로 두었다: 상한 초과 limit 을 거부하지 않고 상한까지 반환하던
공개 API, per_page 를 범위로 조정하던 관리자 목록, 미지원 period 를 year 로 해석하던 인기글
목록 모두 종전과 같은 응답을 낸다. 상한/폴백을 rules 로 승격시키면 200 이던 응답이 422 가
되어 기존 링크가 깨지므로, 규칙은 타입만 닫고 클램프·폴백은 접근자가 맡는다. period 는
접근자가 닫힌 집합만 반환해 캐시 키 공간도 함께 닫힌다.

ckeditor5 이미지 업로드만 ResponseHelper 봉투를 쓰지 않는다. 응답을 파싱하는 주체가 CDN 으로
로드되는 상위 CKEditor5 43.3.1 의 SimpleUploadAdapter 라 규약을 바꿀 수 없어, 각 응답 지점에
사유를 명시한 면제를 부착하고 근거를 API 문서에 남겼다.

하네스 — 룰 5개의 대상 경로 패턴이 매처와 맞지 않아 번들 확장 컨트롤러가 검사 대상에서
통째로 빠져 있었다. 패턴을 고치자 확장 위반 17건이 드러나 전건 처리했다. severity 오타가
요약 집계 양쪽에 안 잡혀 "0 error" 로 보고되던 문제도 런너 사전 검증으로 막았다.

정렬 게이트 대조 하네스는 관계 정렬 변형만 쓰는 저장소를 탐지하지 못한 채 통과시키고 있었다.
탐지·제외·인자 파싱을 함께 고치고 단위 테스트를 신설했다.
This commit is contained in:
HeuJung
2026-08-02 15:29:29 +09:00
parent 5f4a733b3b
commit b10e89bef0
276 changed files with 12519 additions and 1438 deletions
+12
View File
@@ -20,6 +20,18 @@ use App\Extension\AbstractUpgradeStep;
* 외래키 컬럼의 비어 있는 한국어 comment 를 채운다. `->comment()` 가
* `->constrained()` 뒤에 체인되어 컬럼이 아닌 FK 정의에 부착되던 문제를
* 소스에서 교정했으나, 기설치본은 마이그레이션이 재실행되지 않아 남는다.
* 04_AddNotificationLogSortIndexes.php
* 알림 발송 이력의 수신자명·제목 정렬 인덱스를 추가한다. 마이그레이션만으로는
* 신규 설치에만 반영되므로 기존 사이트에 동일 인덱스를 적용한다.
* 발송 이력이 많으면 ALTER TABLE 이 수 분 걸리며 그동안 해당 테이블 쓰기가 대기한다.
* 05_AddTiebreakToCoreListIndexes.php
* 코어 목록 인덱스에 고유 키 tiebreak 를 더한다. 정렬이 비고유 컬럼만으로
* 끝나면 동률 구간의 페이지 경계가 흔들려 같은 행이 중복 노출된다.
* 위 04 와 같은 이유로 ALTER TABLE 이 오래 걸릴 수 있어 마지막에 실행한다.
*
* 실행 순서는 파일명 정렬(`sort()`)을 따른다. 부작용이 없고 빠른 스텝(01~03)을 앞에 두고,
* 테이블 락을 오래 잡는 인덱스 추가(04~05)를 뒤에 배치했다 — 인덱스 스텝이 지연·실패해도
* 앞선 교정은 이미 적용된 상태가 된다.
*
* 본 클래스는 `AbstractUpgradeStep` 의 default `run()` 에 위임 — 별도 override 없음.
*
@@ -0,0 +1,79 @@
<?php
namespace App\Upgrades\Data\V7_0_6\Migrations;
use App\Extension\Upgrade\DataMigration;
use App\Extension\UpgradeContext;
use Illuminate\Support\Facades\Schema;
/**
* 알림 발송 이력 목록의 정렬 인덱스를 추가합니다.
*
* 목록은 지연 조인으로 페이지네이션되는데, 그 전제는 "정렬은 인덱스가 있는 닫힌 집합" 입니다.
* 인덱스가 없으면 inner 쿼리도 전체 스캔이 되어 깊은 OFFSET 개선 폭이 사라집니다. 화면 정렬
* 셀렉트가 수신자명순·제목순을 제공하므로 두 컬럼에 인덱스를 둡니다.
*
* 신규 설치는 마이그레이션이 처리하지만 기존 사이트에는 반영되지 않으므로 업그레이드 시점에
* 동일 인덱스를 추가합니다.
*
* 발송 이력이 많은 사이트에서는 ALTER TABLE 이 수 분 걸릴 수 있고 그동안 알림 발송 기록
* 쓰기가 대기합니다. 진행 상황을 로그로 남깁니다.
*
* idempotent: 이미 존재하는 인덱스는 건너뜁니다. V-1 안전: Facades\Schema 만 사용합니다.
*/
class AddNotificationLogSortIndexes implements DataMigration
{
private const TABLE = 'notification_logs';
/**
* 추가할 인덱스 정의 (이름 => 컬럼 목록)
*
* @var array<string, array<int, string>>
*/
private const INDEXES = [
'idx_notification_logs_recipient_name' => ['recipient_name'],
'idx_notification_logs_subject' => ['subject'],
];
/**
* 마이그레이션 식별자를 반환합니다.
*
* @return string 마이그레이션 이름
*/
public function name(): string
{
return 'AddNotificationLogSortIndexes';
}
/**
* 정렬 인덱스를 추가합니다.
*
* @param UpgradeContext $context 업그레이드 컨텍스트
*/
public function run(UpgradeContext $context): void
{
if (! Schema::hasTable(self::TABLE)) {
$context->logger->info('[core:7.0.6] 알림 발송 이력 테이블 부재 — 정렬 인덱스 추가 스킵');
return;
}
$existing = array_column(Schema::getIndexes(self::TABLE), 'name');
foreach (self::INDEXES as $name => $columns) {
if (in_array($name, $existing, true)) {
$context->logger->info("[core:7.0.6] 이미 존재하는 인덱스 — 스킵: {$name}");
continue;
}
$context->logger->info("[core:7.0.6] 정렬 인덱스 추가 시작: {$name} (발송 이력이 많으면 수 분 걸릴 수 있고 그동안 알림 발송 기록 쓰기가 대기합니다)");
Schema::table(self::TABLE, function ($table) use ($columns, $name) {
$table->index($columns, $name);
});
$context->logger->info("[core:7.0.6] 정렬 인덱스 추가 완료: {$name}");
}
}
}
@@ -0,0 +1,87 @@
<?php
namespace App\Upgrades\Data\V7_0_6\Migrations;
use App\Extension\Upgrade\DataMigration;
use App\Extension\UpgradeContext;
use Illuminate\Support\Facades\Schema;
/**
* 코어 목록(활동 로그·알림 발송 이력·회원)의 정렬 색인 끝에 기본키를 덧붙입니다.
*
* 세 목록 모두 작성일 내림차순으로 정렬하는데, 색인이 작성일에서 끝나면 같은 시각에 쌓인
* 구간의 순서를 색인으로 만들 수 없어 추가 정렬 작업이 붙습니다. 활동 로그처럼 같은 초에
* 여러 건이 쌓이는 목록에서는 이 구간이 일상적입니다.
*
* 신규 설치는 마이그레이션이 처리하지만 기존 사이트에는 반영되지 않으므로 업그레이드
* 시점에 같은 교체를 수행합니다.
*
* 기록이 많은 사이트에서는 색인 교체가 수 분 이상 걸릴 수 있고 그동안 해당 테이블 쓰기가
* 대기합니다. 새 색인을 먼저 만들고 기존 색인을 나중에 지우므로, 중간에 중단되어도 조회가
* 색인 없이 남는 구간은 없습니다.
*
* idempotent: 이미 교체된 대상은 건너뜁니다. V-1 안전: Facades\Schema 만 사용합니다.
*/
class AddTiebreakToCoreListIndexes implements DataMigration
{
/**
* 대상 [테이블 => [신규 색인명, 컬럼, 교체 대상 기존 색인명(없으면 null)]]
*
* @var array<string, array{0: string, 1: array<int, string>, 2: string|null}>
*/
private const TARGETS = [
'activity_logs' => ['idx_activity_logs_created_id', ['created_at', 'id'], 'g7_activity_logs_created_at_index'],
'notification_logs' => ['idx_notification_logs_created_id', ['created_at', 'id'], null],
'users' => ['idx_users_created_id', ['created_at', 'id'], 'idx_users_created_at'],
];
/**
* 마이그레이션 식별자를 반환합니다.
*
* @return string 마이그레이션 이름
*/
public function name(): string
{
return 'AddTiebreakToCoreListIndexes';
}
/**
* 목록 정렬 색인을 기본키 포함 형태로 교체합니다.
*
* @param UpgradeContext $context 업그레이드 컨텍스트
*/
public function run(UpgradeContext $context): void
{
foreach (self::TARGETS as $table => [$newIndex, $columns, $oldIndex]) {
if (! Schema::hasTable($table)) {
$context->logger->info("[core:7.0.6] 테이블 부재 — 색인 교체 스킵: {$table}");
continue;
}
$existing = array_column(Schema::getIndexes($table), 'name');
if (in_array($newIndex, $existing, true)) {
$context->logger->info("[core:7.0.6] 이미 교체된 색인 — 스킵: {$newIndex}");
} else {
$context->logger->info("[core:7.0.6] 목록 정렬 색인 교체 시작: {$table} (기록이 많으면 수 분 이상 걸릴 수 있고 그동안 해당 테이블 쓰기가 대기합니다)");
Schema::table($table, function ($blueprint) use ($columns, $newIndex) {
$blueprint->index($columns, $newIndex);
});
$context->logger->info("[core:7.0.6] 새 색인 생성 완료: {$newIndex}");
}
// 기존 단일 색인은 새 색인의 좌측 프리픽스라 남겨 두면 쓰기 비용만 늘어난다.
// 반드시 새 색인 생성 이후에 지운다.
if ($oldIndex !== null && in_array($oldIndex, $existing, true)) {
Schema::table($table, function ($blueprint) use ($oldIndex) {
$blueprint->dropIndex($oldIndex);
});
$context->logger->info("[core:7.0.6] 상위집합에 포함된 기존 색인 제거: {$oldIndex}");
}
}
}
}