최근의 vibe coding은 첫 구현 단계만 보면 상당히 빠릅니다.

인증 관련 화면, 관리 UI, 이미지 업로드, Webhook 수신부. 이전이라면 반나절이 걸렸을 초안이, agent에게 task를 넘기는 것만으로 단번에 나옵니다.

다만, 여기서 무서운 것은 "AI가 코드를 작성하는 것" 그 자체가 아닙니다. 무서운 것은, 동작하는 것이 빨리 나온 탓에 review 할 수 있는 단위를 만들지 않은 채 공개에 가까워지는 것입니다.

저라면 agent가 작성한 코드를 특별 대우하지 않습니다.

인간이 작성한 변경 사항과 마찬가지로 PR에 올립니다. 그 위에, PR 전, PR 중, 공개 전의 3곳에 security gate를 둡니다.

첫 번째 gate는 security tool이 아니라 task sizing입니다.

agent에게 다음과 같은 의뢰를 하면 대체로 위험합니다.

사용자 등록, 로그인, 이미지 업로드, 관리 화면, Stripe 연동까지 구현해줘

동작하는 것은 나올지도 모릅니다. 하지만 차이(diff)가 너무 커서 review 할 의욕이 사라집니다.

저라면 이렇게 나눕니다.

1. email/password login의 UI와 server action만 만들기
2. session cookie 설정과 middleware만 만들기
3. image upload endpoint만 만들기
...

입도는 소박하지만, PR에서 확인됩니다.

AI agent의 안전성은 모델의 똑똑함만으로 결정되지 않습니다. 인간이 review 할 수 있는 차이로 나눌 수 있는지에 따라 상당히 결정됩니다.

PR을 만들기 전에, 먼저 local diff를 봅니다.

git diff --stat
git diff --name-only

여기서 보는 것은 코드의 아름다움이 아니라 "건드리지 않았으면 하는 곳을 건드리지 않았는가"입니다.

예를 들어 frontend의 UI 수정을 부탁했는데, 왠지 다음과 같은 내용이 들어있다면 중단시킵니다.

.env
package-lock.json
server/auth.ts
...

물론 정당한 이유가 있는 경우도 있습니다. 다만, agent의 변경에서는 "하는 김에 고쳐두었습니다"와 같은 차이가 섞이기 쉽습니다. 그 부분을 PR 전에 걸러냅니다.

Copilot CLI의 preview 환경이라면, local changes에 대해 /security-review를 실행하는 선택지도 있습니다.

/security-review

여기서 기대하는 것은 완벽한 감사가 아닙니다.

secret이 섞여 있지 않은가. 권한 없는 write endpoint가 늘어나지 않았는가. URL fetch나 file upload에서 SSRF / path traversal의 냄새가 나지 않는가. dependency를 추가한 이유를 설명할 수 있는가.

그 정도의 거친 확인이면 충분합니다. 오히려 PR 전 gate를 너무 무겁게 만들면 작업이 이어지지 않습니다.

다음은 PR입니다.

여기서 중요한 것은, "AI가 만들었으니까 별도의 review 경로로 한다"가 아니라, 일반적인 PR 경로에 반드시 태우는 것입니다.

최소한, 저라면 이 정도를 required check로 설정하겠습니다.

- lint
- typecheck
- test
...

GitHub 측에서도, third-party coding agent가 만든 코드를 security validation의 대상으로 만드는 방향으로 나아가고 있습니다. 이는 상당히 자연스러운 흐름이라고 생각합니다.

agent branch가 있고, commit이 있고, PR이 있다. 거기에 security validation과 human review를 끼워 넣는다.

"AI에게 안전성을 묻는" 것보다, "AI가 만든 변경 사항을 기존의 안전한 경로에 통과시키는" 쪽이 더 강력합니다.

AGENTS.md나 repo instruction에 security policy를 적는 것도 방법입니다.

여기에 긴 security essay를 두면 아마 읽히지 않을 것입니다. agent가 매번 읽는다면, 짧고 구체적이며 차이(diff)에 효과적인 내용으로만 구성하고 싶습니다.

예를 들면 이 정도입니다.

## Security review policy (보안 검토 정책)
- 비밀 정보(secrets), 실제 토큰, 또는 운영 환경의 `.env` 값을 커밋하지 마십시오.
- 인증(auth) 체크 없이 공개 쓰기 엔드포인트(public write endpoints)를 추가하지 마십시오.
...

포인트는 "좋은 코드를 작성하라"가 아니라, "위험한 종류의 변경 사항을 놓치지 마라"에 맞추는 것입니다.

agent는 추상적인 품질 목표보다, 구체적인 금지 사항이나 확인 항목을 더 다루기 쉬워합니다.

개인 개발에서도 PR template은 효과가 있습니다.

거창할 필요는 없습니다.

## Security checklist (보안 체크리스트)
- [ ] 비밀 정보나 실제 `.env` 값이 포함되지 않았음
- [ ] 새로운 의존성(dependencies)에 대한 설명이 포함되었음
...

이 checklist가 있는 것만으로도, agent가 생성한 summary를 그대로 믿기 어렵게 만듭니다.

특히 vibe coding에서는 PR description이 묘하게 깔끔하게 정리되어 있는 경우가 있습니다. 깔끔한 summary와 안전한 차분(diff)은 별개의 문제입니다.

마지막은 공개 전 단계입니다.

이 단계는 인간이 직접 수행합니다. AI의 summary가 아니라, 화면, 네트워크(network), 서버 로그(server logs)를 확인합니다.

모든 것을 볼 필요는 없습니다. 핵심 경로(critical path)를 3개에서 5개 정도로 압축합니다.

예를 들어 작은 web app이라면, 이 정도 수준입니다.

1. 로그인 / 로그아웃 (login / logout)
2. 파일 업로드 (file upload)
3. 공개 쓰기 동작 (public write action)
...

확인하는 관점도 고정합니다.

- 권한 부여(authorization) 없이 실행될 수 있는가
- 클라이언트(client)에 서버 비밀값(server secret)이 노출되지 않았는가
- 로그(log)에 토큰이나 사용자 데이터(user data)가 출력되지 않는가
...

이 단계까지 오면, 더 이상 "AI가 작성해서 불안하다"는 차원의 이야기가 아닙니다.

일반적인 release gate입니다.

최소한의 형태라면, 다음과 같이 시작할 수 있습니다.

name: pr-check
on:
  pull_request:
...

CodeQL도 도입한다면, 별도의 workflow로 분리하여 필수 체크(required check) 항목으로 설정합니다.

name: codeql
on:
  pull_request:
...

이것이 모든 것을 안전하게 만들어주는 것은 아닙니다.

하지만 agent가 만든 거대한 차분(diff)을 아무런 검증 없이 main 브랜치에 가깝게 가져가는 것보다는 훨씬 낫습니다.

만약 지금 agent로 개인 개발 app을 구축한다면, 저는 이 방식을 택할 것입니다.

PR 전
- task를 1개의 PR에서 읽을 수 있는 입도(granularity)로 만든다
- git diff --stat / --name-only를 확인한다
...

AI agent를 많이 사용할수록, 리뷰는 의욕(기합)의 문제가 아니라 경로(pipeline)의 설계 문제가 됩니다.

구현은 빠르게 해도 좋습니다. 하지만 공개 판단까지 대충 빠르게 해서는 안 됩니다.

제 관점에서는, 이 지점이 vibe coding과 production shipping의 경계선입니다.

• GitHub Changelog: Security validation for third-party coding agents
• GitHub Changelog: Dedicated security review command in Copilot CLI
• GitHub Docs: About Copilot coding agent / cloud agent
• GitHub Changelog: Copilot code review AGENTS.md support
• Claude Code Docs: Hooks