GPT를 코드 감사자로 활용하기 (코드 생성기로 사용하지 않기)

Source: Dev.to

“GPT 코드 리뷰”가 보통 만족스럽지 않은 이유

아마 다음과 같은 상황을 겪어보셨을 겁니다:

“내 코드를 볼래? 리뷰해줄 수 있어?”

피드백은 보통 합리적입니다:

• 리팩토링 아이디어
• 엣지 케이스
• 스타일 개선

하지만 한 가지가 빠져 있습니다: 결정.
구현이 허용되는가—아니면 아닌가?

최소한의 실험

이 문제를 탐구하기 위해 의도적으로 작은 프로젝트를 만들었습니다.

• FastAPI
• JWT
• 하나의 엔드포인트
• 다중 테넌트 데이터 접근

그리고 정확히 하나의 엔지니어링 결정을 고정했습니다:

tenant_id는 JWT 페이로드에서만 가져와야 하며—다른 어디에서도 가져오면 안 됩니다.
설정 플래그는 없습니다. 코드가 이 결정을 강제하거나, 그렇지 않으면 실패합니다.

이것이 설계 논쟁이 아니라 감사 문제인 이유

tenant_id가 쿼리 파라미터, 헤더, 바디 또는 JWT에서 올 수 있다면:

• 다중 테넌트 접근을 확실히 차단하기 어려워짐
• 보안이 강제 대신 관습에 의존하게 됨
• 리뷰가 판단이 아닌 토론으로 변함

감사는 다음과 같이 말할 수 있어야 합니다: 고정된 요구사항을 고려했을 때, 이 구현은 통과하거나 실패한다.

GPT를 감사자로 전환하기

GPT는 여기서 창의적이거나 영리하게 쓰이는 것이 아닙니다. 역할이 엄격히 제한됩니다:

1. 구현을 고정된 요구사항과 비교
2. 위반 사항이나 모호함을 식별
3. 재현 가능한 판정 도출
4. 이유 설명

결정 표면이 고정되면, GPT는 제안을 멈추고 판단을 시작합니다.

저장소에 포함된 내용

저장소는 의도적으로 최소화되었습니다:

• 고정된 요구사항 (requirements.md)
• 최소 구현
• 실패 사례를 보여주는 테스트
• 구조화된 감사 기록
• 최종 판정

이는 프레임워크도, 튜토리얼도 아닙니다.

Repository

전체 예시는 여기에서 확인할 수 있습니다:
👉

한 파일만 읽어야 한다면 requirements.md부터 시작하세요.

마지막 생각

대부분의 코드 리뷰 고통은 나쁜 코드에서 오는 것이 아닙니다.
GPT가 감사에 유용해지는 것은 그 결정들이 명시적으로 정의된 이후입니다.