AI로 만든 시제품을 실제 서비스로 올리기 전에 확인할 것
요즘은 개발을 모르셔도 시제품이 나옵니다. AI 코딩 도구에 원하는 것을 설명하면 화면이 만들어지고, 데이터가 저장되고, 실제로 동작합니다.
그리고 여기서 대부분 멈춥니다.
"돌아가긴 하는데, 이걸 진짜 손님한테 열어도 되는 건지 모르겠습니다."
당연한 질문입니다. 코드를 직접 쓰지 않았으니 품질을 판단할 방법이 없습니다. 그런데 판단이 안 되면 다음 단계로 못 갑니다. 더 만들자니 잘못된 위에 쌓는 것 같고, 다시 만들자니 지금까지가 아깝습니다.
1. 비밀 키가 어디에 있는지
가장 먼저 볼 것이고, 가장 자주 문제가 되는 곳입니다.
외부 서비스를 쓰면 비밀 키를 받습니다. AI API 키, 결제사 키, 데이터베이스 접속 정보 같은 것들입니다. 이 키가 사용자 브라우저까지 내려가면 누구나 꺼내 쓸 수 있습니다.
남이 내 키로 AI를 호출하면 요금은 내가 냅니다. 실제로 하룻밤에 수백만원이 나가는 사고가 이 경로로 생깁니다.
개발자 없이 확인하는 법: 서비스를 브라우저에서 열고 Ctrl+U(맥은 Cmd+Option+U)를 눌러 소스 보기를 켠 다음, Ctrl+F로 key, secret, sk-, api 같은 단어를 찾아보십시오. 긴 영문·숫자 조합이 나오면 위험 신호입니다.
2. 같은 것을 하나로 묶고 있는지
데이터를 여러 곳에서 모으는 서비스라면 여기가 핵심입니다.
같은 제품이 판매처마다 다른 이름으로 올라와 있습니다. "비타민D 2000IU 90캡슐"과 "비타민디 2000아이유 (90정)"이 같은 제품인데, 시스템이 다른 것으로 보면 둘 다 반쪽짜리 정보가 됩니다.
이게 왜 중요하냐면, 추천이나 비교가 되지 않기 때문입니다. 같은 제품인데 가격 비교가 안 되고, 리뷰가 나뉘고, 검증을 통과한 상품도 후보에서 빠집니다.
"쓸 만한 데이터가 부족하다"
이렇게 느껴지신다면 데이터를 더 모으는 문제가 아니라 이 묶기 문제인 경우가 많습니다. 더 긁어와도 똑같이 흩어집니다.
확인하는 법: 같은 제품을 두세 판매처에서 찾아 서비스에 넣어보십시오. 하나로 나오면 정상, 따로 나오면 여기가 문제입니다.
3. 실패했을 때 어떻게 되는지
시제품은 잘 되는 경우만 시험합니다. 실제 서비스는 안 되는 경우가 훨씬 많습니다.
- 외부 API가 응답을 안 하면
- 데이터를 모으다가 중간에 끊기면
- 같은 작업이 두 번 실행되면
시제품은 대개 여기서 조용히 멈추거나, 반쪽 데이터를 남깁니다. 반쪽 데이터가 더 나쁩니다. 멈추면 알아채지만 반쪽은 모르고 지나갑니다.
확인하는 법: 인터넷을 잠깐 끊고 서비스를 써보십시오. 오류 메시지가 뜨는지, 아무 일도 안 일어나는지를 보시면 됩니다. 아무 반응이 없으면 실패 처리가 없다는 뜻입니다.
4. 남이 이어받을 수 있는지
지금은 AI 도구에 물어보면서 고치실 수 있습니다. 문제는 다른 사람이 붙을 때입니다.
개발자를 구하든 외주를 맡기든, 처음 보는 사람이 코드를 열었을 때 어디를 고쳐야 하는지 찾을 수 있어야 합니다. 같은 일을 하는 코드가 여러 곳에 흩어져 있으면, 한 곳만 고치고 나머지를 놓칩니다.
확인하는 법: 특정 기능 하나를 정하고 AI 도구에 물어보십시오. "이 기능은 어느 파일에 있나" 라고. 한 곳을 짚으면 괜찮고, 여러 곳에 흩어져 있다고 하면 정리가 필요합니다.
전부 다시 만들 필요는 없습니다
검토를 받으면 "다시 만들어야 합니다"라는 말을 듣기 쉽습니다. 대부분 사실이 아닙니다.
시제품은 보통 세 무더기로 나뉩니다.
| 구분 | 성격 | 보통 비율 |
|---|---|---|
| 그대로 쓸 것 | 화면, 기본 흐름, 단순 기능 | 절반 이상 |
| 고칠 것 | 구조가 얽혀 있으나 논리는 맞는 부분 | 상당수 |
| 다시 만들 것 | 보안 문제, 데이터 구조의 근본 오류 | 소수 |
중요한 것은 이 분류에 "왜"가 붙어 있는지입니다. 이유 없이 "다시 만들어야 한다"고 하면 그것은 판단이 아니라 견적입니다.
외부에 검토를 맡기실 때
이 세 가지를 요청하시면 검토가 쓸모 있어집니다.
- "유지 / 수정 / 재작성으로 나누고 각각 이유를 적어달라" - 결론만 있는 보고서는 다음 단계에 못 씁니다
- "지금 당장 위험한 것을 따로 표시해달라" - 보안은 순서와 무관하게 먼저입니다
- "안 된다면 대신할 방법까지 적어달라" - "그 방식은 불가능합니다"로 끝나는 검토는 돈만 나갑니다
세 번째가 특히 중요합니다. 데이터 수집처럼 정책이 걸리는 영역은 "불가능"이라는 답이 나오기 쉽습니다. 그때 대안이 없으면 검토를 받기 전과 똑같은 자리에 서 있게 됩니다.
시제품이 돌아간다는 것은 이미 큰 일을 하신 것입니다. 남은 질문은 "이게 좋은 코드인가"가 아니라 "다음에 무엇을 할 것인가"입니다. 검토는 그 답을 얻으려고 받는 것입니다.
여기까지 읽으셨다면 지금 이 업무에 월 몇 시간이 들어가는지 계산해 보실 수 있습니다. 가입도 이메일도 필요 없습니다.