Vibe Coding 보안 체크리스트：AI로 코드를 작성하는 팀을 위한 10가지 규율 · Insights

속도는 올라갔지만 규율은 아직 따라오지 못했다

Vibe Coding — 자연어로 의도를 설명하고 AI에게 구현을 맡기는 방식 — 은 더 이상 일부 개발자의 실험이 아닙니다. 많은 팀에서 스캐폴딩부터 비즈니스 로직 구현까지 상당한 비중의 작업을 담당하고 있습니다.

문제는 보안 프로세스가 '코드는 사람이 쓴다'는 전제로 설계되어 있다는 점입니다. 사람은 자신이 어떤 라이브러리를 넣었는지 기억하고, 낯선 의존성에는 경계하며, Stack Overflow 코드를 붙여넣기 전에 잠시 망설입니다. AI는 그 어느 것도 하지 않습니다. 존재하지 않는 패키지명, 원래 라이선스를 그대로 지닌 오픈소스 조각, 학습 데이터에서 익힌 낡은 작성 방식까지 포함해, 지극히 자연스러워 보이는 코드를 높은 확신으로 출력합니다.

이는 AI 코드 생성에 반대하는 주장이 아닙니다. 오히려 그 반대입니다. 앞으로도 정착하고 비중이 계속 늘어날 것이기에, 이를 뒷받침할 규율을 갖춰야 합니다. 아래 10가지는 개발 흐름의 5단계에 맞춰 정리했으며, 그대로 팀 규범에 옮겨 쓸 수 있는 형태입니다.

1단계: 프롬프트

규율 1 · 제약은 나중에 고치지 말고 프롬프트에 담습니다.

같은 "파일 업로드 API를 작성해줘"라도 "프로젝트에 있는 validation 유틸리티를 사용하고, 새 의존성은 추가하지 말며, 경로 처리는 디렉터리 트래버설을 방지할 것"을 덧붙이면 결과물의 품질이 자릿수 단위로 달라집니다. 기술 스택 제약, 보안 요구사항, 의존성 정책을 프롬프트 템플릿으로 축적하는 편이 코드 리뷰에서 매번 지적하는 것보다 효율적입니다.

규율 2 · 민감한 맥락은 공개 모델에 넣지 않습니다.

운영 환경 설정, 실제 자격 증명, 고객 데이터, 미공개 비즈니스 로직. 이것들을 공개 챗봇에 붙여넣는 순간 통제 범위를 벗어납니다. 팀에는 명확한 데이터 등급이 필요합니다. 어떤 코드 영역은 공개 AI 도구를 써도 되고, 어디는 사내 배포 모델을 써야 하는지. 이 규율의 어려움은 기술이 아니라, 개발자가 우회하지 않을 만큼 쓸 만한 대체 환경을 제공할 수 있느냐에 있습니다.

2단계: 생성

규율 3 · AI는 다작하는 주니어 엔지니어이지 시니어 전문가가 아닙니다.

주니어의 코드가 리뷰를 거치듯, AI가 생성한 코드도 같은 리뷰를 거칩니다. 차이는 생산 속도입니다. AI는 훨씬 빠르게 출력하므로 리뷰 체계가 자동화되어 있어야 합니다. 생성된 코드를 한 줄씩 사람이 읽는 방식으로는 팀이 먼저 지칩니다.

규율 4 · 커밋 시점이 아니라 생성 시점에 검사합니다.

리스크 발견이 늦을수록 수정 비용은 올라갑니다. 이상적인 형태는 IDE 내 실시간 탐지입니다. AI가 코드를 작성한 그 시점에 보안 엔진이 오염 분석, 의존성 확인, 라이선스 대조를 끝낸 상태입니다. 이것이 AI 시대에 시프트 레프트가 도달하는 지점 — 코드 생성 순간까지 왼쪽으로 당기는 것입니다.

3단계: 의존성 도입

규율 5 · 의존성 허용 목록을 만들고 AI는 그 안에서만 고르게 합니다.

AI가 의존성을 고르는 근거는 학습 데이터상의 인기도이지, 우리 팀의 기술 스택 계획이나 라이선스 정책, 보안 기준이 아닙니다. 통제된 의존성 집합 안에서 AI가 작업하게 하는 편이, 도입된 라이브러리를 사후에 하나씩 심사하는 것보다 현실적입니다.

규율 6 · 존재하지 않는 패키지에 능동적으로 대비합니다.

AI는 실재하지 않는 패키지명을 완전히 자신 있는 어조로 참조합니다. 공격자들은 이렇게 자주 등장하는 가상의 이름을 조직적으로 등록해 왔습니다. 이것이 슬롭스쿼팅입니다. 방어는 3중으로 구성합니다. 설치 전에 패키지가 실재하며 합리적인 배포 이력을 갖는지 검증하고, 내부 저장소 미러를 운영해 내부 우선으로 해석하며, 신규 의존성의 첫 설치에는 사람의 확인을 거칩니다.

규율 7 · 전이 의존성도 대상입니다.

AI가 도입한 패키지 하나가 수십 개의 전이 의존성을 끌고 올 수 있습니다. 그것들도 똑같이 공격면이 되고 라이선스 의무의 원천이 되지만, 누구의 시야에도 들어오지 않은 채 남습니다. 완전한 의존성 트리 해석과 지속적인 취약점 대조는 AI 시대 의존성 관리의 기본 조건입니다.

4단계: 리뷰

규율 8 · 조각 단위 탐지로 오픈소스 재현을 잡아냅니다.

AI는 학습 데이터의 오픈소스 코드를 그대로 재현하기도 합니다. 이런 조각은 어떤 의존성 선언 파일에도 나타나지 않아 매니페스트만 읽는 도구로는 탐지할 수 없습니다. 하지만 조각이 수반하는 라이선스 의무는 실재합니다. 조각 단위 지문 대조가 현재로서는 이런 리스크를 드러내는 유일한 수단이며, AI 생성 코드의 비중이 높아질수록 이 역량은 '있으면 좋은 것'에서 '필요한 것'으로 바뀝니다.

규율 9 · 리뷰의 초점은 문법이 아니라 비즈니스 로직에 둡니다.

AI가 생성한 코드는 대개 문법적으로 정확하고 스타일도 일관됩니다. 사람이 쓴 것보다 정돈되어 있기도 합니다. 오류가 생기는 지점은 다른 곳입니다. 비즈니스 규칙에 대한 이해 차이, 경계 조건 누락, 권한 판정 위치 오류, 지나치게 관대한 예외 처리. 사람 리뷰어는 기계가 서툰 이런 판단에 주의를 집중해야 하며, 문법과 스타일은 도구에 맡깁니다.

5단계: 병합

규율 10 · 생성 이력의 흔적을 남깁니다.

어떤 코드가 AI 생성인지, 어떤 모델로, 언제, 어떤 프롬프트에서 나왔는지. 이 정보는 세 가지 상황에서 갑자기 중요해집니다. 보안 사고의 추적, 라이선스 분쟁에서의 입증, 그리고 앞으로 나타날 수 있는 컴플라이언스 감사 대응입니다. 비용은 커밋 시 마커 하나를 더하는 것뿐이고, 필요할 때 근거를 제시할 수 있다는 이점을 얻습니다.

10가지 규율을 게이트로 바꾸기

10가지 규율이 문서 안에만 있으면 정착률은 오르지 않습니다. 효과적인 방법은 흐름에 녹여 넣는 것입니다. 프롬프트 템플릿은 IDE 플러그인으로, 의존성 허용 목록은 저장소 설정으로, 검사는 IDE와 CI로, 생성 이력 마커는 커밋 템플릿으로. 그리고 마지막에 CI 게이트가 도입 여부를 판정합니다. 기준을 충족하지 못한 코드는 주 브랜치에 들어가지 못합니다.

AI는 코드 생산 속도를 한 자릿수 끌어올렸습니다. 보안 역량도 같은 속도로 따라가야 합니다. 이는 개발자에게 부담을 지우기 위한 것이 아니라, 강력한 도구를 안심하고 쓸 수 있게 하기 위한 것입니다.

---