Gemini로 만든 메일 정리 도구: 첫 MVP에는 AI 기능이 없어도 됩니다

핵심 요약 (TL;DR)

AI로 만든 앱이 꼭 AI로 판단할 필요는 없습니다. 한 제작자는 Gemini와 대화하며 메일 정리 스크립트를 만들었지만, 실제 분류에는 단순한 규칙을 골랐습니다. 처음 만드는 도구라면 ‘똑똑한 기능’을 늘리기보다 매일 반복하는 불편 하나를 줄여 보는 편이 좋겠습니다. 이 사례는 작은 자동화에서도 오분류와 복구를 먼저 생각해야 함을 보여 줍니다.

최근에 확인된 제작 사례가 맞나요?

제작자 apparent의 Show HN 글은 2026년 10월 31일 6시 53분 31초(KST)에 게시됐습니다. 11월 1일 오전 7시 기준 최근 48시간 안의 소개입니다. 최초 배포일이나 개발 착수일은 확인되지 않았으므로, 이틀 만에 완성한 제품이라고 말할 수는 없습니다.[1]

작성자는 Gemini와 대화한 뒤 Google 스크립트를 만들었다고 설명하며, 본문 말미에는 Gemini가 코드를 작성했다고 덧붙였습니다. 실제 코드도 같은 글에 공개돼 있습니다. 단순히 AI라는 이름을 붙인 서비스가 아니라 제작 과정의 AI 활용을 직접 밝힌 사례입니다. 다만 이는 작성자의 자기보고이며, 대화 기록을 독립적으로 검증한 것은 아닙니다.[1]

왜 AI에게 메일 내용을 읽히지 않았을까요?

제작자는 반복되는 원치 않는 영업 메일로 받은편지함이 어수선해지는 문제를 해결하고 싶었습니다. Gemini는 AI로 메일을 처리하는 방향도 제안했지만, 작성자는 모든 메일을 언어모델에 보내고 싶지 않았다고 설명합니다. 그래서 내가 이전에 메일을 보낸 적이 없는 발신자를 별도로 검토하는 방식을 택했습니다.[1]

공개 코드는 읽지 않은 받은편지함 대화를 가져와 발신자를 확인하고, 해당 주소로 검색한 결과가 없으면 받은편지함에서 보관 처리한 뒤 검토용 라벨을 붙입니다. 영구 삭제는 하지 않습니다. 작성자는 매분 실행한다고 설명하지만, 그 실행 주기 자체를 설정하는 코드는 본문 함수에 포함돼 있지 않습니다.[1]

여기서 중요한 차이가 보입니다. ‘AI가 만들어 준 코드’와 ‘운영 중 AI를 호출하는 기능’은 별개입니다. 첫 MVP를 설계할 때도 판단 기준을 짧은 문장으로 설명할 수 있다면, 우선 그 규칙이 실제 불편을 줄이는지부터 확인해 볼 만합니다.

그대로 쓰기 전에 무엇을 테스트해야 할까요?

가장 큰 위험은 처음 연락한 정상 발신자입니다. 댓글에서도 새 고객이나 새 거래처의 메일이 함께 분류될 수 있다는 지적이 나왔고, 작성자도 계속 확인할 필요를 인정했습니다. 받은편지함에 잠시 도착한 뒤 처리되므로 알림을 반드시 차단하는 도구도 아닙니다.[1]

공개 코드에는 의도와 구현의 간격도 있습니다. ‘보낸 적이 있는가’를 확인한다는 주석과 달리 검색식에는 보낸편지함을 한정하는 조건이 없습니다. 따라서 검색 결과가 곧 실제 발송 이력이라는 가정은 별도 확인이 필요합니다. 이번 조사에서 계정에 설치하거나 분류 정확도를 측정하지는 않았습니다.[1]

처음 시험한다면 이동 없이 후보만 기록하는 방식으로 시작해 보세요. 기존 연락처, 처음 연락한 지인, 필요한 자동 알림을 나눠 넣고 예상과 결과를 비교하는 것입니다. 이는 조사자의 테스트 제안입니다. 빠르게 만든 기능을 곧바로 자동 실행하는 것보다, 틀려도 되돌리기 쉬운 단계에서 쓸모를 확인하는 편이 낫습니다.

자주 묻는 질문은 무엇인가요?

이것도 첫 앱이나 MVP로 볼 수 있나요?

화려한 화면이 없어도 반복되는 문제와 확인 가능한 결과가 있으면 작은 MVP가 될 수 있습니다. 이 사례의 출발점은 새로운 서비스가 아니라 자신의 받은편지함이었습니다.

공개 코드가 있으니 그대로 켜도 되나요?

바로 켜기보다 분류 대상과 복구 방법부터 확인하세요. 제작자에게 편리한 규칙이 내 연락 방식에도 맞는지는 다른 문제입니다. 첫 연락을 놓치면 안 된다면 자동 이동보다 검토 목록이 더 나을 수 있습니다.

출처는 어디에서 확인하나요?

[1] 제작자 설명·공개 코드·댓글: https://news.ycombinator.com/item?id=50310650