목록으로
업무 생산성 개선을 위한 AI 활용
AI 답을 AI로 검사하고 원문과 대조하며 옷장 앱을 만든 기록
개발을 배운 적 없는 대학생이 Claude로 만들고 ChatGPT·Gemini로 따지게 해, 중요한 주장과 숫자를 원문으로 확인하며 옷장 앱 시험판을 만든 방법입니다.
🤖 활용 AI 도구
Claude, ChatGPT, Gemini 등
① 어떤 상황에서 AI를 활용했나요
저는 개발을 배운 적이 없는 대학생입니다. AI와 앱을 만들면서 가장 큰 문제는, AI의 답이 맞는지 제가 가려낼 수 없다는 점이었습니다. 코드든 정책이든 통계든, 자신 있게 말하면 그대로 믿기 쉬웠습니다.
가진 옷만으로 오늘 입을 코디를 정해 주는 옷장 앱을 만들고 있습니다. 2026년 9월 웹 시제품을 만든 뒤, AI가 쓴 코드·문서·조사 결과를 확인하는 일이 제 핵심 업무가 됐습니다. 그래서 AI 하나를 믿는 대신, AI끼리 서로 검사하게 만들었습니다.
10월 28일 확인표 기준으로 안드로이드는 0.4.1(vc6)이 구글 플레이 비공개 테스트에 게시됐고, 0.5.0은 구글 검토 중입니다. 아이폰은 TestFlight에 0.5.0을 올렸습니다. 테스터 설치는 AI 상담을 넣은 새 빌드로 11월 6일 시작할 예정입니다. AI 옷장 상담 서버는 10월 28일 올렸지만 11월 6일 0시 전에는 닫혀 있고, 그 화면을 넣은 앱은 아직 배포 전이라 현재 앱 화면에는 AI 답변이 나오지 않습니다. 날씨는 11월 3일부터, AI 상담은 11월 6일 처리방침 시행 뒤 제공할 계획입니다. 정식 출시는 11월 20일 목표이며, 심사·승인이 확정된 일정은 아닙니다.
② 어떤 AI를 어떻게 활용했나요
역할을 나눴습니다. Claude는 코드·문서를 만들고 다른 AI 답을 원문과 대조했습니다. ChatGPT는 공식 자료를 찾고 일부러 반대 의견을 냈습니다. Gemini는 별도로 조사했습니다. 저는 매일 앱을 써 보고 이상한 곳을 짚고 마지막에 결정했습니다.
지킨 규칙은 다섯 가지입니다.
만든 AI의 검사만으로 끝내지 않는다.
중요한 질문은 서로의 답을 보여 주지 않고 따로 묻는다.
중요한 숫자 3~5개는 공식 문서나 논문 원문을 연다. 이는 제 점검 방식이지 정확성을 보장하는 기준은 아니다.
주장마다 「확인함·추정·확인 못 함」을 구분한다.
바꾼 것은 「옛 결정 → 새 결정·이유」로 남긴다.
③ 활용 결과 어떤 변화가 있었나요
첫 번째 장면은 Gemini 광고 전략 보고서를 검토할 때입니다. 보고서에는 「Google Play 정책 위반 코드(SPLIT_BUNDLE 1003 등)」이 확인된 내용처럼 적혀 있었습니다. 하지만 연결된 Google Play 광고 정책 본문에서는 그 코드를 찾지 못했습니다. 공식 근거로 쓰지 않기로 했습니다. Google Play 광고 정책
「최소 12~16dp 여백 분리」도 나왔습니다. 다만 원문에는 이미 「[추측]」이 붙어 있었습니다. AdMob 문서는 버튼·콘텐츠 바로 옆 배치를 피하라고 설명하지만 그 간격을 정하지는 않습니다. 따라서 이를 정책 수치로 쓸 수도, AI가 의무 규정이라고 단정한 사례로 쓸 수도 없습니다. Claude의 검토 표현도 원문에 맞춰 좁혔습니다. AdMob 배너 구현 안내
개인정보 관련 「[의무] 개인정보와 행태정보 처리 시스템 분리」라는 표현도 따졌습니다. 인용된 개인정보위 정책 방안은 광고 사업자와 광고 매체 사업자를 나누며, 비식별 처리의 안전조치 등에는 「권고조치를 준수하도록 노력하여야 한다」고 적습니다. 이를 앱 개발자에게 일괄 적용되는 의무처럼 옮기지 않기로 했습니다. 개인정보위 정책 방안
숫자도 가정을 따로 봤습니다. Gemini의 「일일 활성 사용자(DAU) 3,000명」은 실측이 아니라 「[추측]」이었습니다. 검토안에서는 30명·100명·300명 가정으로 다시 계산했습니다. 다른 조건이 같다면 3,000명 가정의 광고 수익은 이보다 10~100배 커집니다. 실제 이용자 수나 매출이 그만큼 부풀려졌다고 입증한 것은 아닙니다.
두 번째 장면은 검토하던 Claude 자신이 틀렸을 때입니다. 제 확인표에 남은 판단은 「설정 파일에 expo-build-properties 가 없으니 R8 (코드 줄이기) 은 꺼져 있다」였습니다. Expo 공식 문서는 SDK 58의 Android 템플릿에서 릴리스 빌드의 R8이 기본으로 켜진다고 설명합니다. Expo SDK 58 안내 제 확인표에는 실제 vc6 빌드의 r8.json에서도 난독화·최적화가 켜진 것을 확인하고 판단을 뒤집었다고 적혀 있습니다. 이 경험은 작업 확인표에 근거하며, 빌드 원본은 이 글에 첨부하지 않았습니다. 검토하는 AI도 원문과 실물로 확인해야 한다는 원칙을 세웠습니다.
지표를 고친 기록도 구분해 남겼습니다. RevenueCat 2026의 2.1%는 분석 대상 freemium 앱의 「설치 후 35일 유료 전환율」 중앙값이지 월 활성 이용자 중 구독자 비율이 아닙니다. 이를 잘못 적용한 계산을 고쳤다는 작업 기록과, 수정 뒤 계획서에 올바른 지표를 적었다는 확인표가 있습니다. 다만 수정 전 계산 원문은 찾지 못했으므로 전후 계산을 모두 입증했다고 쓰지는 않습니다. 이 외부 수치는 제 앱의 성과나 예상 전환율도 아닙니다. RevenueCat 2026
10월 28일 제공 확인표에 기록된 작업량은 변경 기록 306건, 자동 검사 2,198개 통과, 근거 자료 356줄입니다. 이 집계는 작업 확인표에 근거하며, 검사 실행 시각은 원본 로그와 추가 대조가 필요합니다. 356줄은 10월 12일 연구 DB의 행 수입니다. 작업량을 보여 줄 뿐, 절약한 시간이나 오류 감소율을 뜻하지는 않습니다.
가장 큰 변화는 「AI가 맞는지 모르는 상태」에서 「어디까지 확인했는지 아는 상태」로 바뀐 것이라고 생각합니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요
차별점은 AI를 여러 개 쓴 것보다, 검토 AI의 판단까지 원문으로 다시 확인하고 바꾼 이유를 남기는 절차입니다. 답이 갈리면 원문을 열고, 답이 같아도 중요한 숫자는 확인합니다. 여러 AI의 동의만으로 정답이라고 보지 않습니다.
지시문은 목표·이미 아는 것·조사할 것·출처 순서·「못 찾으면 못 찾음」을 적고, 답의 끝은 「표 + 결론 3줄 + 반례」로 고정했습니다. 공식 원문을 먼저 보고, 논문·기관 자료·언론·블로그 순서로 확인합니다.
⑤ 다른 사람도 따라 할 수 있나요
네. 두 AI에 만드는 역할과 따지는 역할을 나눠 맡기는 것으로 시작할 수 있습니다. 중요한 질문을 따로 묻고, 원문을 열고, 확인 수준과 바꾼 이유를 한 줄씩 남기면 됩니다. 도구별 검색·원문 열람 기능과 사용 한도는 다를 수 있습니다. 개발이 아니어도 과제·보고서·조사처럼 「AI 답을 믿어도 되나」가 걸리는 일에 적용해 볼 수 있습니다.
⑥ AI 사용 범위와 책임
제 경험과 작업 기록을 바탕으로 썼고, 앱 개발·조사뿐 아니라 이 글의 초안·대조·문장 다듬기에도 AI의 도움을 받았습니다. 확인되지 않은 것을 확인했다고 쓰지 않고, 최종 판단과 책임은 제가 집니다.
공개 원고와 증빙에서는 개인 식별정보·비공개정보를 빼고, 타인의 콘텐츠는 이용 권한과 출처를 확인합니다. AI가 만든 예문을 실제 이용자 의견으로 쓰지 않습니다. 사람의 외모나 몸을 점수로 매기는 기능은 넣지 않았으며, 아직 배포하지 않은 AI 상담에는 AI가 만든 답변임을 표시할 계획입니다.
저는 개발을 배운 적이 없는 대학생입니다. AI와 앱을 만들면서 가장 큰 문제는, AI의 답이 맞는지 제가 가려낼 수 없다는 점이었습니다. 코드든 정책이든 통계든, 자신 있게 말하면 그대로 믿기 쉬웠습니다.
가진 옷만으로 오늘 입을 코디를 정해 주는 옷장 앱을 만들고 있습니다. 2026년 9월 웹 시제품을 만든 뒤, AI가 쓴 코드·문서·조사 결과를 확인하는 일이 제 핵심 업무가 됐습니다. 그래서 AI 하나를 믿는 대신, AI끼리 서로 검사하게 만들었습니다.
10월 28일 확인표 기준으로 안드로이드는 0.4.1(vc6)이 구글 플레이 비공개 테스트에 게시됐고, 0.5.0은 구글 검토 중입니다. 아이폰은 TestFlight에 0.5.0을 올렸습니다. 테스터 설치는 AI 상담을 넣은 새 빌드로 11월 6일 시작할 예정입니다. AI 옷장 상담 서버는 10월 28일 올렸지만 11월 6일 0시 전에는 닫혀 있고, 그 화면을 넣은 앱은 아직 배포 전이라 현재 앱 화면에는 AI 답변이 나오지 않습니다. 날씨는 11월 3일부터, AI 상담은 11월 6일 처리방침 시행 뒤 제공할 계획입니다. 정식 출시는 11월 20일 목표이며, 심사·승인이 확정된 일정은 아닙니다.
② 어떤 AI를 어떻게 활용했나요
역할을 나눴습니다. Claude는 코드·문서를 만들고 다른 AI 답을 원문과 대조했습니다. ChatGPT는 공식 자료를 찾고 일부러 반대 의견을 냈습니다. Gemini는 별도로 조사했습니다. 저는 매일 앱을 써 보고 이상한 곳을 짚고 마지막에 결정했습니다.
지킨 규칙은 다섯 가지입니다.
만든 AI의 검사만으로 끝내지 않는다.
중요한 질문은 서로의 답을 보여 주지 않고 따로 묻는다.
중요한 숫자 3~5개는 공식 문서나 논문 원문을 연다. 이는 제 점검 방식이지 정확성을 보장하는 기준은 아니다.
주장마다 「확인함·추정·확인 못 함」을 구분한다.
바꾼 것은 「옛 결정 → 새 결정·이유」로 남긴다.
③ 활용 결과 어떤 변화가 있었나요
첫 번째 장면은 Gemini 광고 전략 보고서를 검토할 때입니다. 보고서에는 「Google Play 정책 위반 코드(SPLIT_BUNDLE 1003 등)」이 확인된 내용처럼 적혀 있었습니다. 하지만 연결된 Google Play 광고 정책 본문에서는 그 코드를 찾지 못했습니다. 공식 근거로 쓰지 않기로 했습니다. Google Play 광고 정책
「최소 12~16dp 여백 분리」도 나왔습니다. 다만 원문에는 이미 「[추측]」이 붙어 있었습니다. AdMob 문서는 버튼·콘텐츠 바로 옆 배치를 피하라고 설명하지만 그 간격을 정하지는 않습니다. 따라서 이를 정책 수치로 쓸 수도, AI가 의무 규정이라고 단정한 사례로 쓸 수도 없습니다. Claude의 검토 표현도 원문에 맞춰 좁혔습니다. AdMob 배너 구현 안내
개인정보 관련 「[의무] 개인정보와 행태정보 처리 시스템 분리」라는 표현도 따졌습니다. 인용된 개인정보위 정책 방안은 광고 사업자와 광고 매체 사업자를 나누며, 비식별 처리의 안전조치 등에는 「권고조치를 준수하도록 노력하여야 한다」고 적습니다. 이를 앱 개발자에게 일괄 적용되는 의무처럼 옮기지 않기로 했습니다. 개인정보위 정책 방안
숫자도 가정을 따로 봤습니다. Gemini의 「일일 활성 사용자(DAU) 3,000명」은 실측이 아니라 「[추측]」이었습니다. 검토안에서는 30명·100명·300명 가정으로 다시 계산했습니다. 다른 조건이 같다면 3,000명 가정의 광고 수익은 이보다 10~100배 커집니다. 실제 이용자 수나 매출이 그만큼 부풀려졌다고 입증한 것은 아닙니다.
두 번째 장면은 검토하던 Claude 자신이 틀렸을 때입니다. 제 확인표에 남은 판단은 「설정 파일에 expo-build-properties 가 없으니 R8 (코드 줄이기) 은 꺼져 있다」였습니다. Expo 공식 문서는 SDK 58의 Android 템플릿에서 릴리스 빌드의 R8이 기본으로 켜진다고 설명합니다. Expo SDK 58 안내 제 확인표에는 실제 vc6 빌드의 r8.json에서도 난독화·최적화가 켜진 것을 확인하고 판단을 뒤집었다고 적혀 있습니다. 이 경험은 작업 확인표에 근거하며, 빌드 원본은 이 글에 첨부하지 않았습니다. 검토하는 AI도 원문과 실물로 확인해야 한다는 원칙을 세웠습니다.
지표를 고친 기록도 구분해 남겼습니다. RevenueCat 2026의 2.1%는 분석 대상 freemium 앱의 「설치 후 35일 유료 전환율」 중앙값이지 월 활성 이용자 중 구독자 비율이 아닙니다. 이를 잘못 적용한 계산을 고쳤다는 작업 기록과, 수정 뒤 계획서에 올바른 지표를 적었다는 확인표가 있습니다. 다만 수정 전 계산 원문은 찾지 못했으므로 전후 계산을 모두 입증했다고 쓰지는 않습니다. 이 외부 수치는 제 앱의 성과나 예상 전환율도 아닙니다. RevenueCat 2026
10월 28일 제공 확인표에 기록된 작업량은 변경 기록 306건, 자동 검사 2,198개 통과, 근거 자료 356줄입니다. 이 집계는 작업 확인표에 근거하며, 검사 실행 시각은 원본 로그와 추가 대조가 필요합니다. 356줄은 10월 12일 연구 DB의 행 수입니다. 작업량을 보여 줄 뿐, 절약한 시간이나 오류 감소율을 뜻하지는 않습니다.
가장 큰 변화는 「AI가 맞는지 모르는 상태」에서 「어디까지 확인했는지 아는 상태」로 바뀐 것이라고 생각합니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요
차별점은 AI를 여러 개 쓴 것보다, 검토 AI의 판단까지 원문으로 다시 확인하고 바꾼 이유를 남기는 절차입니다. 답이 갈리면 원문을 열고, 답이 같아도 중요한 숫자는 확인합니다. 여러 AI의 동의만으로 정답이라고 보지 않습니다.
지시문은 목표·이미 아는 것·조사할 것·출처 순서·「못 찾으면 못 찾음」을 적고, 답의 끝은 「표 + 결론 3줄 + 반례」로 고정했습니다. 공식 원문을 먼저 보고, 논문·기관 자료·언론·블로그 순서로 확인합니다.
⑤ 다른 사람도 따라 할 수 있나요
네. 두 AI에 만드는 역할과 따지는 역할을 나눠 맡기는 것으로 시작할 수 있습니다. 중요한 질문을 따로 묻고, 원문을 열고, 확인 수준과 바꾼 이유를 한 줄씩 남기면 됩니다. 도구별 검색·원문 열람 기능과 사용 한도는 다를 수 있습니다. 개발이 아니어도 과제·보고서·조사처럼 「AI 답을 믿어도 되나」가 걸리는 일에 적용해 볼 수 있습니다.
⑥ AI 사용 범위와 책임
제 경험과 작업 기록을 바탕으로 썼고, 앱 개발·조사뿐 아니라 이 글의 초안·대조·문장 다듬기에도 AI의 도움을 받았습니다. 확인되지 않은 것을 확인했다고 쓰지 않고, 최종 판단과 책임은 제가 집니다.
공개 원고와 증빙에서는 개인 식별정보·비공개정보를 빼고, 타인의 콘텐츠는 이용 권한과 출처를 확인합니다. AI가 만든 예문을 실제 이용자 의견으로 쓰지 않습니다. 사람의 외모나 몸을 점수로 매기는 기능은 넣지 않았으며, 아직 배포하지 않은 AI 상담에는 AI가 만든 답변임을 표시할 계획입니다.
