인가 테스트를 표로 만들었더니 기존 코드에서 버그가 1개 발견되었다

Claude Code로 Laravel 앱의 인가 (Policy) 테스트를 정비하고 있었더니, 의도적으로 찾으려 한 것도 아닌데 기존 코드의 버그가 발각되었습니다. 이번에는 그 이야기에 대해 다룹니다.

「역할 × 액션」 매트릭스로 테스트 작성하기

프로젝트·태스크 관리 미니 SaaS에서 인가 요건은 다음과 같았습니다.

프로젝트 열람·태스크 조작은
**오너(Owner)와 멤버(Member)**만 가능 - 프로젝트 편집·삭제·멤버 관리는
오너(Owner)만 가능

이를 테스트할 때, 정상계(오너는 가능하다)뿐만 아니라, 거부되는 측까지 포함하여 표 형식으로 망라하기로 했습니다.

이유는 단순합니다. 인가(Authorization) 결함은 "해야 할 사람이 못 하는 것"보다 "해서는 안 될 사람이 해버리는 것"이 압도적으로 위험하며, 게다가 알아차리기도 어렵기 때문입니다.

dataset('project_matrix', [
'오너는 편집할 수 있다' => ['owner', true],
'멤버는 편집할 수 없다' => ['member', false],
...

이를 show / edit / update / destroy의 4개 액션 × 3개 역할로 돌렸습니다.

실행해보니, "멤버는 프로젝트를 열람할 수 있다" 행만 실패했습니다. 요건상으로는 열람이 멤버에게도 허용되어 있어야 하는데, 실제로는 403(Forbidden)이 반환되고 있었습니다.

원인을 추적해보니 기존의 Policy가 다음과 같이 되어 있었습니다.

public function view(User $user, Project $project): bool
{
return $this->isOwner($user, $project);
...

view()가 오너에게만 허용되어 있어, 멤버는 차단되는 구현이었던 것입니다.

이 버그의 무서운 점은, 방향이 "너무 엄격한" 쪽이었다는 점입니다. 인가 버그에는 두 가지 방향이 있습니다.

너무 느슨한 쪽 (본래 할 수 없는 사람이 해버림): 인시던트(Incident)로 발각됨. 실질적인 피해가 발생하므로 조만간 발견됨
너무 엄격한 쪽 (본래 할 수 있는 사람이 못 함): 사용자는 "그런 사양인가 보다"라고 생각하며 포기함. 에러로 보고되는 일도 적어 개발자가 알아챌 기회가 거의 없음

이번 버그는 후자였습니다.

만약 인가 매트릭스를 정비하지 않았다면, 이 "멤버는 열람조차 할 수 없다"라는 제한은 아무도 모르는 채로 릴리스되었을 가능성이 있습니다.

이 버그는 찾으려고 해서 찾은 것이 아닙니다. 요건을 「역할 × 액션」의 표로 옮기는 작업 자체가 구현과의 불일치를 기계적으로 드러낸 것이 정확한 표현입니다.

이는 AI와의 협업 관점에서도 시사하는 바가 있습니다. AI에게 "인가 테스트를 작성해줘"라고만 부탁하면 정상계(오너는 가능하다)에 치우치기 쉽습니다.

하지만 "역할 × 액션의 표로, 허용되는 측과 거부되는 측을 모두"라고 지시하면, 기존 버그를 검출하는 검사기로서 테스트 스위트(Test Suite)가 기능하기 시작합니다.

테스트는 올바름을 확인하는 것뿐만 아니라, 요건과 구현의 차이를 찾아내는 도구도 된다는 것이 이번의 배움이었습니다.

인가 테스트는 정상계뿐만 아니라 거부 측도 역할 × 액션의 표로 망라한다
"너무 엄격한" 방향의 버그는 실질적인 피해가 나오기 어렵고 발견되기 쉽지 않다. 표로 만드는 작업이 그 발견 장치가 된다
AI에게 테스트를 작성하게 할 때는 관점(이 경우에는 「역할 × 액션의 표」)을 인간이 지정한다. 관점만 전달하면 구현의 빈틈도 기존 코드의 빈틈도 동시에 검출할 수 있다

이 이야기는 Claude Code로 Laravel 앱을 한 권 완성한 기록을 정리한 책의 일부를 기사용으로 재구성한 것입니다.

인가 관련 실화(AI가 앞서서 Policy를 구현해온 이야기, UI에서 숨기는 것과 인가의 차이 등)는 책의 제5장에, 테스트의 검출력을 측정하는 이야기는 제6장에 자세히 적어두었습니다.

『Laravel × Claude Code 실전 도입 가이드』(Zenn・¥1,200・제1장 무료)