100만 원짜리 실수, AI에게 절대 맡기면 안 되는 것

AI에게 맡길 수 있는 것과 없는 것의 경계가 곧 당신의 차별화다.

100만 원짜리 실수의 시작

지난해 한 스타트업 창업자는 Claude Cursor를 이용해 결제 기능을 3시간 만에 구현했어요. "드디어 완성되었다"는 기쁨도 잠깐, 첫 사용자의 결제가 완료되자마자 문제가 터졌습니다. 결제 응답을 처리하는 코드에 API 키가 하드코딩되어 있었던 거예요. GitHub에 커밋된 순간, 누군가는 이미 그 키를 찾아 API를 마음대로 호출 중이었어요. 한 달 뒤 청구서는 100만 원을 넘었습니다.

이건 남의 이야기가 아닙니다. AI 도구가 "매우 편한" 상태에서 보안의 경계가 흐려지는 게 당연해요. 문제는 AI가 편하다는 게 아니라, 어디서부터 AI에게 맡기면 안 되는지 모르는 상태에서 일어납니다.

위임의 경계선, 외부 의존 vs 내부 핵심

모든 코드가 같은 무게를 가지지 않아요. 어떤 코드는 AI가 생성해도 괜찮고, 어떤 코드는 반드시 당신이 직접 검토해야 합니다.

AI가 안전하게 맡을 수 있는 영역

"반복적이고, 검증 가능하고, 외부에 의존하지 않는 것."

• 데이터 포맷 변환 (JSON → CSV)
• UI 컴포넌트 기본 구조 (버튼, 카드 레이아웃)
• 알고리즘 구현 (정렬, 필터링)
• 문서 생성 (API 문서, 테스트 케이스)

AI에게 절대 맡기면 안 되는 영역

"위임의 결과가 직접 손실을 가져오는 것."

• 보안 관련 모든 것 (인증, 암호화, API 키 관리)
• 결제와 금융 거래 (PG 연동, 환율 계산, 거래 기록)
• 개인정보 처리 (이용자 데이터 저장, 조회, 삭제)
• 도메인 핵심 로직 (당신의 비즈니스 경쟁력)
• 법적 준수 사항 (약관, 개인정보처리방침, 컴플라이언스)

경계를 명확히 하면 두 가지 이점이 생깁니다. 첫째, AI가 할 일이 명확해져서 더 정확한 프롬프트. 둘째, 무언가 잘못됐을 때 책임 소재가 명확. "AI가 잘못 만들었다"는 변명은 소용없어요.

보안의 경계, AI가 만든 코드는 왜 뚫리는가

AI 생성 코드에서 가장 빈번한 보안 취약점은 API 키와 인증 토큰의 노출이에요. Trend Micro 연구에 따르면 ChatGPT 생성 코드 중 상당수가 하드코딩된 API 키를 포함하고 있었습니다. "결제 API를 연동해줘"라고 요청하면, AI는 가장 간단한 방식인 '소스 코드 직접 입력'을 제시하는 경우가 많아요.

"개발 환경에서만 테스트할 거니까 괜찮겠지"라는 생각이 가장 위험합니다. 한 번 커밋된 코드는 GitHub 히스토리에 영원히 남아요.

2023년 구글 API 키 사건도 있었어요. 개발자들이 공식 가이드를 따라 API 키를 설정했는데, 구글이 시스템을 변경해 API 키가 제미나이 인증 토큰으로 기능하도록 만들었습니다. 결과? 수억 원대의 무단 과금.

한국 상황은 더 복잡해요. PG(결제대행) 연동 시 각사의 보안 정책이 모두 다릅니다. 토스페이먼츠, NHN KCP, NICE 페이먼츠 등의 결제 API는 문서는 있지만 정확한 보안 가이드는 전화 상담으로만 가능한 경우가 많아요. AI에게 "결제 기능 만들어줘"라고 요청하면 일반적인 패턴만 따르는데, 이게 당신의 PG 규약을 위반할 수 있습니다.

결제와 보안은 "대충 돌아가는" 수준으로는 절대 안 됩니다. 1%의 오류가 100만 원 손실로 이어집니다. 반드시 전문가(PG 기술팀 또는 결제 전문 개발자)와 함께 검토하고, 그 이후에야 AI 도움을 청하세요.

도메인 핵심, 당신의 unfair advantage는 여기서 나온다

"AI가 못 만드는 게 뭐냐"고 묻는 사람이 많아요. 답은 간단합니다. 당신의 도메인 핵심 로직이에요.

예를 들어 당신이 만드는 앱이 "피부 타입별 화장품 추천"이라면, 핵심 로직은 "사용자 입력값을 피부 타입으로 정확히 분류하는 알고리즘"입니다. AI는 일반적인 분류 알고리즘을 만들 수 있지만, "예민한 피부인데 민감도가 높은 사람"처럼 미묘한 경계 케이스를 정확히 판단하려면? 당신이 직접 피부 전문가와 상담해서 규칙을 정의해야 합니다.

이커머스 플랫폼 예시:

• AI가 할 수 있는 것: 상품 목록 UI, 검색 필터, 리뷰 표시 형식
• AI가 절대 해선 안 되는 것: 수수료 계산 로직, 환불 정책 판단, 재고 관리 규칙

왜 그럴까요? 그 규칙들이 당신의 경쟁력이자 비즈니스 모델이기 때문이에요. AI는 "일반적인" 이커머스 로직을 만들 수 있지만, "당신의" 이커머스 로직은 못 만듭니다.

당신이 직접 비즈니스 로직을 이해하지 못하면, 첫 사용자가 만나는 순간 문제가 터집니다. 초기 10명의 사용자 피드백이 가장 값진데, "왜 이렇게 만들었는지" 설명 못 하면 대응 속도가 느려져요.

디자인의 결, 일관성은 사람이 지킨다

UI 컴포넌트 하나하나는 AI가 완벽하게 만들 수 있어요. 하지만 이들을 하나로 묶었을 때의 일관성은 AI가 보장 못 합니다.

디자인 시스템이란 "일관된 경험을 만드는 규칙의 집합"이에요. Figma에서 정의한 폰트 크기, 색상, 간격, 모서리 반경을 모든 화면에서 정확히 구현해야 합니다.

• 버튼 기본 높이 44px → 모든 버튼이 44px
• 헤더 폰트 Pretendard 16px Bold → 모든 헤더가 같은 규격
• 간격 8px 단위 → 12px 간격 있으면 안 됨

AI가 생성한 컴포넌트 10개는 각각 논리적으로 맞을 수 있지만, 함께 놓으면 조화롭지 않을 가능성이 높아요. AI는 "이전에 만든 버튼"을 완벽히 기억하지 못하기 때문입니다.

실전 디자인 일관성 4단계

1. Figma에서 컴포넌트 라이브러리를 먼저 만든다
2. AI에게 "이 Figma 파일의 컴포넌트를 기반으로" 구현 요청
3. 구현된 코드를 원본 디자인과 나란히 놓고 비교 (DevTools로 색상, 간격 측정)
4. 불일치하는 부분을 명시적으로 수정 지시

위임 금지 체크리스트

마무리

이 글의 핵심은 "경계 긋기"입니다. AI가 못 하는 게 아니라, 해선 안 되는 일을 명확히 하는 것이 진정한 우위예요. 당신의 앱이 "빠르게 만들어진 평범한 앱"이 되는지, "느리지만 차별화된 앱"이 되는지는 이 경계를 어떻게 그었는지에 달려 있습니다.

다음 편에서는 출시 직전의 마지막 검문소를 다룹니다. 만든 것보다 빠뜨린 것이 더 많이 망치는 이유, 그리고 그걸 피하기 위한 출시 전 체크리스트예요.

참고 자료

1. Security Vulnerabilities of ChatGPT-Generated Code — Trend Micro (2023)
2. 생성형 AI 개발·활용을 위한 개인정보 처리 안내서 — 개인정보보호위원회 (2025)
3. AI 에이전트 보안 취약점, 하드코딩된 API 키 문제 — MegaZone Soft
4. Codex Command Injection Vulnerability — OpenAI Security Blog (2026)
5. 토스페이먼츠 MCP 공식 가이드 및 개발자 커뮤니티 사례 (2026)

이전 편: 개발자를 위한 AI 빌드 코스 (Cursor와 Claude Code, 3배 증폭기로 쓰는 법)
다음 편: 만든 것보다 빠뜨린 것이 더 비싸다, 출시 전 체크리스트

김민철, 프리아이브 CEO, 페일스쿨