AI에게 맡기면 안 되는 일 — 결제·개인정보·스토어 정책

테스트 결제를 눌렀습니다. 성공 화면이 떴고 이용 권한도 열렸어요. 다 끝난 것처럼 보였죠.

이번엔 결제 창을 중간에 닫아 봤습니다. 다시 누르니 이전 시도가 남아서 새 결제를 시작할 수가 없었어요. 다른 계정으로 들어가 보니 누가 산 상품인지 구분도 흐렸고요.

AI에게 "결제를 붙여 줘"라고 시킨 결과가 틀린 건 아니었습니다. 결제 창은 분명히 열렸으니까요. 제가 필요했던 게 그보다 넓었을 뿐이에요. 돈이 맞는 사람에게 붙고, 실패한 시도는 풀리고, 취소된 권한은 닫혀야 했거든요.

이런 일을 겪으면 "AI에게 결제를 맡기면 안 된다"고 말하고 싶어집니다. 그런데 그 말도 너무 거칠어요. AI는 코드를 만들고, 예외를 나열하고, 반복 검사를 돕는 데 얼마든지 쓸 수 있으니까요. 맡기면 안 되는 건 손질이 아니라 무엇이 안전한지 결정하고 끝났다고 승인하는 판단입니다.

저는 경계를 이렇게 긋습니다. 틀렸을 때 글자 하나 고치면 끝나는 일은 넓게 맡깁니다. 틀렸을 때 돈, 다른 사람의 정보, 계정 권한, 출시 자격이 어긋나는 일은 제가 기준을 들고 직접 장면을 확인하고요.

결제는 버튼이 아니라 돈의 귀속입니다

결제 화면이 보이면 구현이 끝난 것처럼 느껴져요. 그런데 화면은 가장 앞쪽 장면일 뿐입니다.

누가 무엇을 얼마에 샀는지, 서버가 그 금액과 상품을 확인했는지, 같은 요청이 겹쳤을 때 중복 처리되지 않는지, 실패한 시도가 다시 열리는지, 취소와 환불 뒤 권한이 어떻게 되는지가 전부 맞아야 하거든요. 사용자가 보낸 값을 그대로 믿지 않고 운영자가 정한 상품과 권한을 기준으로 대조해야 하고요.

이 목록을 AI에게 물어볼 수는 있어요. 빠진 경우를 찾아 달라고 해도 되고요. 다만 나온 답을 그대로 설계 결정으로 채택하면 안 됩니다. 우리 결제 사업자, 상품 구조, 환불 약속, 이미 쌓인 사용자 상태를 AI가 자동으로 책임져 주지는 않으니까요.

저는 결제 작업을 요청할 때 성공 장면보다 실패 장면을 먼저 적습니다.

"사용자가 결제 창을 닫아도 다시 시도할 수 있어야 해요."

"다른 계정으로 로그인했을 때 이전 구매자의 권한이 보이면 안 돼요."

"결제가 취소되면 화면 표시만이 아니라 실제 이용 권한도 정해진 규칙대로 바뀌어야 해요."

개발 용어는 하나도 없지만 전부 검수할 수 있는 문장이에요. 결제를 붙이며 배운 것도 성공 버튼보다 중간 상태와 복구 경로를 먼저 본 기록입니다.

개인정보는 보이는 화면 밖에서 샙니다

앱 화면에서 이름을 가렸다고 개인정보 처리가 끝난 게 아니에요. 알림, 위젯, 오류 기록, 분석 도구, 내려받은 파일, 관리자 화면에 남을 수 있거든요. 로그아웃한 뒤 캐시에 남아 다음 사람에게 보일 수도 있고요.

AI에게 "개인정보를 안전하게 처리해 줘"라고 요청하면 넓은 모범 답안이 옵니다. 하지만 어떤 정보가 왜 필요한지, 누가 언제까지 봐야 하는지, 지운 뒤에 어디에서도 사라져야 하는지는 제품 운영자가 정해야 해요.

제가 먼저 묻는 건 기술 이름이 아닙니다.

• 이 정보가 없어도 기능이 되는가
• 꼭 필요하다면 누가 볼 수 있어야 하는가
• 화면 밖 어디에 복사되는가
• 관계가 끝나거나 계정이 바뀌면 무엇이 남는가

필요 없는 정보는 아예 받지 않는 게 제일 단순합니다. 필요한 정보는 보이는 경로와 숨겨야 할 경로를 함께 적고요. "삭제된다"는 문장도 화면에서 사라지는지, 다시 로그인해도 없는지, 다른 사용자에게 안 보이는지를 장면으로 나눠야 해요.

AI가 이 장면들의 테스트 코드를 만들 수는 있습니다. 그런데 테스트 목록이 실제 제품의 약속을 다 담았는지는 사람이 확인해야 해요. 기획서가 실력이 되는 이유가 개인정보 영역에서 더 무거워지는 까닭입니다.

스토어 정책은 기억이 아니라 현재 문구로

앱을 내놓을 때 "이 정도면 괜찮을 거예요"라는 답은 참 편합니다. 제출 버튼을 누르기 전 불안을 줄여 주니까요. 저도 그런 답을 믿었다가 기다려야 하는 검토 과정을 다시 시작한 적이 있어요.

스토어 정책과 제출 요건은 통과 여부를 가르는 외부 기준입니다. AI가 예전에 배운 내용이나 비슷한 사례를 말할 수는 있어도, 지금 적용되는 공식 문구와 내 계정에 표시된 요구사항을 대신하지는 못해요.

그래서 이 영역에서는 답보다 확인 경로를 요구합니다.

"현재 공식 문서의 어느 항목을 근거로 판단했나요?"

"내가 제출 화면에서 직접 확인할 장면은 무엇인가요?"

"확인하지 못한 부분은 어디인가요?"

정확한 정책 판단이 필요한 순간에는 최신 공식 문서를 직접 열고 제출 화면의 실제 상태를 봐야 합니다. 이 글은 특정 스토어의 현재 규정을 설명하는 글이 아니에요. 규정은 바뀌니 여기서 세부 조건을 단정하지 않겠습니다. 제가 경험으로 말할 수 있는 건 낙관적인 요약을 승인 근거로 쓰지 말라는 데까지예요.

전면 신뢰와 전면 금지 사이에서

AI의 역할을 나누는 이야기는 쉽게 양극단으로 갈립니다. 둘 다 실제 작업에는 잘 안 맞았어요.

"AI가 코드를 썼다면 결과 책임도 AI에게 있는 것 아닌가." 작업을 누가 했는지와 제품을 누가 내놓는지는 다른 문제입니다. AI가 만든 코드가 사고를 쳐도 환불을 하고, 손님에게 설명하고, 스토어에 답하는 사람은 운영자예요. 그렇다고 모든 코드를 직접 이해해야 한다는 뜻은 아닙니다. 비개발자가 코드 전체를 읽는 방식으로 안전을 확보하기는 어려우니까요. 대신 돈이 어긋나는 장면, 다른 계정에서 정보가 보이는 장면, 실패 뒤 다시 시작하는 장면을 직접 실행해 볼 수는 있어요. 책임을 가진다는 건 모든 손질을 혼자 한다는 뜻이 아니라 무엇을 확인해야 출시할지 결정한다는 뜻입니다.

"결제와 개인정보는 전문가에게만 맡기면 안전하다." 전문가의 도움은 필요할 수 있어요. 설계와 검토의 깊이가 확실히 달라지니까요. 하지만 외부 전문가도 우리 상품 약속과 운영 장면을 저절로 알지는 못합니다. 환불 뒤 어떤 권한을 닫아야 하는지, 가족이 함께 쓰는 기기에서 무엇을 숨겨야 하는지는 운영자가 설명해야 해요. 맡기는 순간 질문까지 포기하면 빈칸이 생깁니다. 전문가를 쓰지 말라는 것도, 전문가를 의심하라는 것도 아니에요. 책임 있는 위임에는 구체적인 장면과 확인 결과가 함께 있어야 한다는 이야기입니다.

"테스트가 통과했으면 직접 볼 필요가 없다." 자동 검사는 같은 실수를 반복해서 찾는 데 강합니다. 코드가 바뀔 때 이전 기능이 깨졌는지도 빠르게 알려 주고요. 다만 검사에 적힌 것만 봅니다. 로그아웃 뒤 위젯이 비어야 한다는 장면을 아무도 검사에 안 넣었다면, 초록색 결과는 그 장면을 하나도 보증하지 않아요. 건수나 형식이 맞아도 사용자 짝이 뒤바뀌는 오류가 남을 수 있고요. 그렇다고 직접 확인만 믿는 것도 과합니다. 사람이 매번 같은 경로를 빠짐없이 보기는 어려우니까요. 자동 검사는 반복을 맡고, 사람은 검사 목록이 실제 위험을 덮는지 확인한다. 서로 대체하는 관계가 아닙니다.

"위험한 영역은 AI를 아예 안 쓰는 게 낫다." 그렇게 하면 놓치는 게 줄 것 같지만 사람도 예외를 빠뜨려요. AI에게 실패 경로를 반박해 달라고 하고, 검수 목록의 빈칸을 찾게 하고, 반복 테스트 초안을 만들게 하면 확실히 도움이 됩니다. 문제는 사용 여부가 아니라 권한이에요. AI의 제안을 참고 자료로 둘지, 확인 없이 출시 결정으로 쓸지를 나눠야 합니다. 코딩보다 어려웠던 부분은 AI를 덜 쓰자는 이야기가 아니라 검수할 장면을 사람이 가져야 한다는 이야기예요.

맡길 일과 승인하면 안 될 일

같은 결제 작업 안에서도 나눌 수 있습니다.

화면 문구의 초안, 반복되는 코드의 작성, 테스트 목록의 초안, 오류 메시지 정리는 AI에게 맡겨도 돼요. 빠르고 선택지도 여러 개 줍니다. 반면 실제 상품 금액과 권한의 연결, 환불 뒤 처리 원칙, 개인정보 수집 범위, 스토어 규정의 현재 해석, 출시 가능 여부는 사람이 확인하고 승인해야 해요. 필요하면 관련 전문가나 공식 지원 경로의 확인을 받아야 하고요.

경계가 애매하면 실패 비용을 물어보면 됩니다. 틀려도 바로 되돌릴 수 있는가. 문구와 간격은 대개 고치기 쉬워요. 틀린 상태가 다른 사람에게 퍼지는가. 잘못된 권한이나 알림 노출은 퍼집니다. 나중에 기록을 복구해야 하는가. 결제 귀속과 데이터 삭제는 과거 상태까지 다뤄야 하죠. 외부 승인이 걸려 있는가. 스토어 제출과 법적 약속은 우리 화면만 고쳐서 끝나지 않고요. 뒤로 갈수록 사람의 직접 확인이 커져야 합니다.

검수 목록은 용어가 아니라 장면으로

비개발자가 가장 막히는 순간은 "보안 검수하세요" 같은 말을 들을 때예요. 어디를 눌러야 하는지를 모르니까요. 장면으로 바꾸면 그때부터 시작할 수 있습니다.

• 결제 창을 중간에 닫고 다시 시도한다
• 같은 버튼을 연달아 눌러도 구매가 겹치지 않는지 본다
• 로그아웃한 뒤 이전 사람의 일정과 이름이 남는지 본다
• 다른 권한의 계정으로 들어가 숨겨야 할 정보가 보이는지 본다
• 삭제 뒤 새로고침하고 다시 로그인해도 사라졌는지 본다
• 공식 제출 문서의 현재 항목과 실제 설정 화면을 나란히 본다

이 목록은 제품마다 다릅니다. 그대로 복사해 놓고 완전한 검사라고 부르면 안 돼요. 다만 "안전하게 해줘"라는 요청을 실행 가능한 확인으로 바꾸는 출발점은 됩니다.

현장을 아는 사람이 직접 도구를 만들 때 강해지는 부분도 여기예요. 어떤 순간에 손님이 창을 닫고, 직원이 계정을 바꾸고, 사장이 앱을 안 여는지 알고 있으니까요. 현장이 있는 사람이 도구를 만들면 생기는 변화는 기능 수보다 이 실패 장면을 빨리 찾는 데 있습니다.

그렇다고 과하게 겁먹진 마세요

돈과 개인정보 이야기를 하다 보면 아무것도 출시하지 못할 것 같은 기분이 듭니다. 모든 위험을 없애고 시작하는 제품은 없어요.

중요한 건 위험을 모르는 채로 낙관하지 않는 겁니다. 이번에 다룰 수 있는 범위를 정하고, 확인하지 못한 부분을 남기고, 피해가 커지기 전에 멈출 장치를 두세요. 확인되지 않은 언어나 기능을 접는 판단도 기능을 접은 이유처럼 실패가 아니라 범위를 지키는 일입니다.

한 번의 확인으로 영원히 안전하다고 생각하는 것도 금물이고요. 결제 상품이 바뀌고, 권한 구조가 바뀌고, 외부 정책이 바뀌면 검수 장면도 다시 봐야 합니다. 다음 빌드에서 다르게 할 것을 굳이 남기는 이유도 같은 실수를 기억에만 맡기지 않으려는 거예요.

AI에게 맡기지 말아야 할 것은 코드가 아닙니다. 무엇이 맞는지 정하는 일, 확인하지 못한 것을 확인됐다고 말하는 일, 그리고 손님 앞에 내놓아도 된다고 승인하는 일이에요. 손질은 빠르게 맡겨도 됩니다. 마지막 확인의 기준만은 넘기지 마세요.

자주 묻는 질문

비개발자가 결제나 개인정보를 어떻게 검수하나요?

코드 전체를 읽기보다 위험한 사용 장면을 적고 직접 실행하세요. 결제를 중간에 닫기, 계정 바꾸기, 로그아웃하기, 삭제 뒤 다시 들어오기처럼요. 전문 검토가 필요한 영역은 도움을 받되, 우리 제품의 약속과 실제 결과를 설명할 책임은 그대로 남습니다.

AI가 공식 문서 링크를 줬다면 믿어도 되나요?

링크가 실제 공식 문서인지, 현재 적용되는 내용인지, 인용한 문장이 그 페이지에 있는지 직접 확인하셔야 해요. 정책이 중요한 판단이라면 검색 요약이나 AI의 재설명보다 현재 원문과 실제 제출 화면을 우선하세요.

어디까지 만들고 출시를 멈춰야 하나요?

돈의 귀속이 불명확하거나, 다른 사용자의 정보가 보이거나, 실패 뒤 복구할 수 없거나, 필수 외부 승인을 확인하지 못했다면 멈추는 게 맞습니다. 단순한 모양 문제와 손님 피해 가능성을 같은 우선순위로 다루지 마세요.