AX 컨설턴트 및 바이브코딩 필수 주의사항 10가지

 AX CONSULTING · VIBE CODING

바이브코딩, 빠르게 만들수록
더 먼저 지켜야 할 10가지

고객사 자료, API Key, 업무 데이터를 다루는 AX 컨설턴트라면 속도보다 먼저 확인해야 할 안전수칙이 있습니다. AI가 만든 결과를 안심하고 전달하기 위한 실무 기준을 정리했습니다.

바이브코딩은 아이디어를 빠르게 화면과 기능으로 바꿔줍니다. 하지만 파일 하나를 프로젝트 폴더에 넣는 일, 환경변수 이름 앞에 접두사를 붙이는 일, AI가 “완료했습니다”라고 말하는 일을 가볍게 넘기면 보안 사고나 잘못된 산출물로 이어질 수 있습니다.

핵심은 단순합니다. 민감한 정보는 밖으로 나가지 않게 하고, AI의 답변은 실행 결과로 검증하며, 애매한 판단은 사람이 확정한다. 아래 원칙을 프로젝트 시작 전과 고객사 전달 전에 점검해 보세요.

1. 고객사 원본 자료는 함부로 올리지 않습니다

계약서, 제안서, 회의록, 녹취록, 직원·고객 정보, 급여·근태·매출 자료, 내부 규정, 고객 DB와 원본 엑셀·PDF는 모두 민감할 수 있습니다. 웹 기반 AI 도구에 첨부한 파일은 외부 서비스로 전송되고, 프로젝트 폴더에 잠시 둔 원본은 나중에 커밋·배포·로그 출력으로 이어질 수 있습니다.

가장 흔한 실수
테스트를 빨리 하려고 실제 엑셀을 /data 폴더에 넣고 AI에게 읽게 한 뒤, 폴더 전체를 저장소에 올리는 경우입니다. 저장소가 비공개여도 배포 URL이나 빌드 로그가 별도의 노출 지점이 될 수 있습니다.

• 원본은 고객사가 허용한 환경에서만 처리합니다.
• 개발과 테스트는 더미 데이터 또는 가명 처리 샘플로 시작합니다.
• 고객사 실데이터가 필요한 최종 검증은 승인 범위 안에서 최소한으로 진행합니다.
• 애매하면 업로드하기 전에 PM 또는 보안 담당자에게 먼저 확인합니다.

2. API Key와 비밀번호는 코드에 쓰지 않습니다

API Key, 토큰, 비밀번호는 시스템의 열쇠입니다. 한 번 공개 저장소나 배포된 브라우저 코드에 들어가면 비용 발생과 데이터 접근으로 이어질 수 있습니다. AI 에이전트가 코드를 작성하고 커밋까지 돕는 환경에서는, 첫 지시문에 보안 규칙을 명확히 넣어두는 편이 가장 실용적입니다.

주의: Next.js/Vercel에서 NEXT_PUBLIC_으로 시작하는 환경변수는 브라우저에 전달됩니다. API Key·비밀번호처럼 비밀이어야 하는 값에는 절대 붙이지 마세요.

프로젝트 시작 시 AI에게 줄 보안 지시문

[보안 규칙 - 반드시 준수]
1. API Key, 비밀번호, 토큰은 코드에 직접 쓰지 말고 .env 파일에만 저장하고 환경변수로 불러와라.
2. .gitignore에 .env, *.key, *.pem, service-account*.json, node_modules/를 포함하라.
3. 실제 값이 없는 .env.example 파일을 별도로 만들어라.
4. git add, commit, push 전에는 포함 파일을 먼저 보여주고 승인받아라.
5. API Key·비밀번호 성격의 배포 환경변수에는 NEXT_PUBLIC_ 접두사를 붙이지 마라.
6. 코드 주석, README, 커밋 메시지에 실제 비밀값을 남기지 마라.

커밋 전 확인이 필요하다면 AI에게 아래 명령어를 실행해 파일 목록을 보여달라고 요청하세요.

git status
git diff --cached

이미 Key를 공개했다면

1. 즉시 폐기(Revoke)합니다. 파일 삭제만으로는 충분하지 않습니다.
2. 새 Key를 발급하고 .env와 배포 환경에 반영합니다.
3. Git 기록에 남은 값도 노출된 것으로 보고 팀 리드·보안 담당자에게 공유합니다.

3. GitHub 저장소는 기본값을 Private으로 둡니다

판단이 애매하면 Private이 기본입니다. 고객사명, 실데이터, 내부 문서, 접속 정보, 개발 중인 산출물이 하나라도 포함될 가능성이 있다면 공개 저장소로 시작하지 않습니다.

Public을 고려할 수 있는 경우	반드시 Private이어야 하는 경우
완전한 더미 데이터만 사용하고, 고객사·개인·내부 정보가 없으며, 교육·포트폴리오·오픈소스 목적이 분명할 때	고객사명, 실제 엑셀·PDF·회의록, 직원·고객·매출·급여·근태 정보, API Key·접속 정보가 있거나 고객사 공개 승인이 없을 때

저장소 비공개 ≠ 배포 사이트 비공개
배포 URL은 별도의 접근 보호가 필요합니다. 실제 고객 데이터를 다루는 서비스라면 배포 보호 설정과 플랜의 제한도 함께 점검하세요.

4. AI가 “완료했다”는 말을 실행 근거로 삼지 않습니다

AI가 만든 코드는 그럴듯하게 보이고, “정상 작동합니다”라는 답변도 자연스럽습니다. 하지만 그 문장은 실제 실행과 검증을 의미하지 않습니다. 특히 파일 생성, 집계, 변환 작업은 결과물을 직접 열어 원본과 대조해야 합니다.

• 근거가 아닌 것: AI의 완료 메시지, 에러 없이 저장된 코드, 커밋 메시지
• 근거가 되는 것: 실제 실행 로그, 생성된 결과 파일, 원본과 대조한 행 수·합계, 빈 값·0·음수·중복을 넣은 테스트

고객에게 전달할 때의 기준: “AI가 된다고 했습니다”가 아니라 “실행했고, 이 테스트를 했고, 이 결과를 확인했습니다”라고 설명할 수 있어야 합니다.

5. 숫자·시간·날짜 계산은 특히 엄격하게 검증합니다

정산, 근태, 급여, 교육시간, 매출, 인원 계산은 한 글자만 틀려도 문제가 됩니다. AI가 코드를 작성하는 것은 괜찮지만, 계산 자체를 대화형 답변이나 암산에 맡기지 말고 결정론적인 코드와 테스트로 확인해야 합니다.

원본 값	놓치기 쉬운 점
46174	단순 숫자가 아니라 Excel 날짜 일련값일 수 있습니다.
0.375	0.375시간이 아니라 하루를 1로 본 Excel 시간값, 즉 09:00일 수 있습니다.
10% / 0.10	셀 서식에 따라 의미가 달라질 수 있습니다.
120만원 / 1,200,000원	정규화 전에 단위를 통일해야 합니다.

• 계산 함수는 분리하고 샘플 입력과 기대값으로 테스트합니다.
• 애매한 값은 자동 확정하지 말고 확인필요로 분류합니다.
• 결과 파일을 다시 열어 주요 셀과 합계가 맞는지 확인합니다.

6. 한글 이름과 기관명은 유사도만으로 합치지 않습니다

“홍길동”, “홍 길동”, “홍길동 과장”, “홍길동(영업팀)”은 같은 사람일 수도, 아닐 수도 있습니다. 이름만으로 병합하라고 지시하면 AI는 문자열 유사도를 기준으로 판단하기 쉽고, 동명이인 병합이나 누락은 파일이 멀쩡해 보이는 상태로 남습니다.

• 사번, 이메일, 부서, 직책 등 보조 키를 함께 사용합니다.
• 확신할 수 없는 매칭은 확인필요로 남깁니다.
• 원본 값, 정규화 값, 매칭 결과를 로그로 남겨 추적 가능하게 만듭니다.

7. PDF·OCR 추출 결과는 원본과 대조합니다

PDF는 화면에 보기 좋게 배치된 문서일 뿐, 표의 열과 셀 구조가 정확히 보존되지 않는 경우가 많습니다. OCR 역시 숫자 0을 알파벳 O로 읽는 식의 오류를 낼 수 있습니다. 이 오류는 에러 없이 그럴듯한 값으로 남는다는 점이 더 위험합니다.

• 파일명보다 본문과 원본 화면을 우선 확인합니다.
• 계약금액·날짜처럼 중요한 필수 항목이 비면 실패로 처리합니다.
• 스캔 PDF의 OCR 결과는 사람이 반드시 원본과 대조합니다.

8. 실제 고객 데이터는 마지막에, 제한적으로 사용합니다

초기 개발 코드는 가장 많은 버그를 가질 수 있습니다. 실데이터를 바로 열면 원본이 덮어써지거나, 디버깅 과정에서 값이 콘솔과 대화 기록에 노출될 수 있습니다. 안전한 순서를 지키는 것이 좋습니다.

1. 더미 데이터로 기능을 개발합니다.
2. 구조만 유지한 가명 처리 샘플로 테스트합니다.
3. 고객사 승인 후, 최소한의 실제 데이터로 제한 검증합니다.
4. 고객 담당자와 결과를 함께 확인한 뒤 산출물을 전달합니다.

9. AI에게 맡길 일과 사람이 확정할 일을 구분합니다

AI가 잘 돕는 일	사람이 반드시 확인할 일
초안 작성, 코드 뼈대·테스트 코드 작성, 반복 작업 자동화, 문서 요약, 더미 데이터 생성, 오류 원인 후보 정리	기밀자료 업로드 여부, 개인정보 포함 여부, 최종 금액·시간·인원 계산, 계약·법률·노무 판단, 고객 전달 최종본, 저장소 공개 여부, API Key 포함 여부

AI의 역할은 빠른 초안과 반복 작업의 가속입니다. 최종 책임과 판단은 사람에게 남겨두어야 합니다.

10. 고객사 전달 전, 마지막으로 확인할 체크리스트

• 이 자료를 외부 AI나 클라우드에 올려도 되는가?
• 고객사 실명, 직원·고객 정보, 매출·급여·근태 정보가 포함되어 있는가?
• GitHub 저장소와 배포 URL의 공개 범위를 확인했는가?
• .env, API Key, 비밀번호가 Git에 포함되지 않았는가?
• 더미 데이터와 실제 데이터를 구분했는가?
• 숫자·시간·날짜 계산을 테스트했는가?
• 결과 파일을 다시 열어 원본과 대조했는가?
• 애매한 값은 확인필요로 남겼는가?
• 고객에게 보여줄 수 있는 수준의 실행 근거와 로그가 있는가?

모든 프로젝트에 넣어둘 표준 지시문

아래 문구는 새 프로젝트의 첫 메시지 또는 프로젝트 규칙 파일에 넣어두면 좋습니다. Codex는 AGENTS.md, Claude Code는 CLAUDE.md, Cursor는 .cursorrules 또는 Rules 설정에 저장할 수 있습니다.

[AX 컨설팅 프로젝트 표준 지시문]

1. 고객사 원본 자료와 민감정보는 git 저장소 밖에 두고, 개발·테스트는 더미 데이터로 먼저 진행하라.
2. 실데이터를 다룰 때 개별 값을 콘솔에 출력하지 말고 행 수와 요약 통계만 출력하라.
3. API Key·비밀번호·토큰은 .env에만 저장하고 코드에는 환경변수로만 사용하라.
4. .gitignore에 .env, *.key, *.pem, service-account*.json, node_modules/를 포함하라.
5. git add, commit, push 전에는 포함 파일 목록을 보여주고 승인받아라.
6. GitHub 저장소는 기본 Private으로 만들고, Public 전환은 명시적 요청이 있을 때만 진행하라.
7. 코드를 직접 실행하고 결과 파일·행 수·합계를 원본과 대조하기 전에는 완료라고 보고하지 마라.
8. 숫자·시간·날짜는 코드와 테스트로 검증하고, 애매한 값은 확인필요로 분류하라.
9. 이름만으로 데이터를 병합하지 말고 사번·이메일 등 보조 키를 사용하라.
10. PDF·OCR 추출값은 필수 항목이 비거나 형식에서 벗어나면 실패로 처리하라.
11. 계약·법률·노무 판단, 최종 금액·시간·인원 계산, 고객 전달 최종본은 검토 필요로 표시하라.
12. 위 지시와 충돌하는 상황이 생기면 임의로 판단하지 말고 먼저 확인하라.

마지막 한 줄

고객사 자료는 함부로 올리지 않고, API Key는 공개하지 않으며, 숫자와 결과는 AI의 말이 아니라 테스트로 확인합니다.
판단이 애매한 경우에는 임의로 진행하지 말고 프로젝트 PM 또는 보안 담당자에게 먼저 확인하세요.