Gmail to SQLite

Hacker News 의견

• 궁금한 점은 왜 스키마에서 특정 헤더들을 따로 분리했는지임 예를 들어, recipients, subject, sender 같은 필드들도 전부 headers라는 json 항목 하나에 다 넣을 수 있는데, 굳이 따로 분리할 이유가 궁금함 만약 성능 때문이라면, 여전히 headers를 json 블롭 형식으로 두고, 필요한 필드만 생성 열로 뽑아서 쓸 수 있음 나는 이렇게 하면 테이블 alter을 통해서 사용자가 필요한 쿼리별로 인덱싱된 생성 컬럼을 자유롭게 추가할 수 있어서 정말 강력한 모델이라고 생각함 예를 들어, dkim status 쿼리가 필요하다면 ALTER TABLE로 추가하고 인덱스도 쉽게 만들 수 있음 원하는 대로 자유롭게 필드를 확장 가능하기 때문에 여러 용도에 유리함

  • 사실 생성 열이 없어도 됨, SQLite는 표현식에 인덱스를 바로 만들 수 있음 그래서 예를 들어 subject의 인덱스를 json_extract로 바로 만들면 되고, 이 인덱스를 필요할 때마다 쿼리에서 써먹을 수 있음 나는 이런 식으로 인덱스만 따로 만들고 뷰로 이용하는 게 주 테이블을 ALTER로 바꾸는 것보다 더 유용하다고 느낌

  • 그냥 단발성 쿼리를 위해 인덱스 추가하는 건 썩 좋은 습관이 아닌 것 같음 보통은 앞으로 확실히 일관되게 쓸 컬럼만 꼭 따로 뽑아두는 걸 선호함, 특히 이메일 헤더처럼 구조가 안정적인 경우에 더욱 그러함 헤더를 json 하나에 몰아넣어서 나중에 스키마를 바꾸는 게 쉬울 수 있지만, 결국 쓰기에서의 고생을 읽기 쿼리에서 다시 하는 것이고, 때에 따라선 조용하게 실패하는 케이스도 허용해버림

  • 나도 postgres에서 비슷한 패턴을 자주 씀 먼저 확실하게 필요한 필드들만 컬럼으로 빼고, 추가 메타데이터는 json 컬럼에 몰아넣음 2개월 지나보면 실제로 필요한 필드를 다시 json에서 채워넣고, API가 유지되게 바꾼다거나, 뷰를 만든다거나 자유롭게 조정함 이렇게 하면 처음에 mongo나 파일시스템 등에 아무 생각 없이 몰아넣고 나중에 후회하게 되는 성장통을 피하기에 아주 유용했음

  • dkim 컬럼을 NOT NULL로 만들었던데, 만약 이메일에 Dkim-Signature 헤더가 아예 없으면 어떻게 처리되는지 궁금함

• 최근 내 앱에 Gmail 연동을 시도해봤음 이 과정에 정말 많은 시간을 쏟았으나 결국 Gmail 지원을 포기했음 Gmail to SQLite가 자격증명 과정이 6 단계면 끝난다는데, 실제로는 그렇지 않았음 6단계 끝나자 구글이 앱이 퍼블리시(공개)되어 있지 않다는 식으로 다시 알려줬고, 퍼블리시하니까 또 워크스페이스 유저가 아니라서 내부용 앱이란 게 안 된다고 알림 외부앱으로 바꾸면 또 별도의 인증 절차(도메인·주소·세부정보 요구, 사용권한에 대한 이유, 영상 설명, 검수에 시간 소요 등)를 추가로 요구함 구글이 요구하는 이런 복잡한 과정을 일반 사용자에게 시키는 건 너무 심하다고 생각함 직접 경험에 당황함

  • 그냥 예전 방식대로 IMAP에 앱 비밀번호만 발급받아서 쓰면 됨 구글이 요구하는 번거로운 절차를 피하는 게 좋음

  • 구글에서 API 키 하나 받으려고 거치는 단계가 정말 미친 듯이 번거로움 도대체 왜 이렇게까지 만들어놨는지 이유를 아는 사람 있는지 궁금함

• 몇 년 전에 Gmail 같은 대용량 이메일을 시각화하는 툴을 만들었었음: https://github.com/terhechte/postsack

  • 이거 정말 멋짐 디스크 용량 시각화 툴 같은 느낌인데, 메일 볼륨 자체에 초점이 맞춰져 있는 모습임 혹시 발신자별로 내 저장공간을 가장 많이 차지하는 사람을 확인하는 사이즈 표시 옵션도 있는지 궁금함 참고로 웹사이트 SSL 인증서가 만료됨

  • 흥미롭게 보임 readme에 gmvault 링크가 더 이상 동작하지 않던데, 이게 맞는 링크인지 https://github.com/gaubert/gmvault 궁금함

  • 정말 흥미로워 보임 나도 qdirstat으로 비슷한 걸 DIY로 만들어본 적 있는데, 이 경우엔 이메일 폴더 구조나 날짜별로 정렬해야 하고, 다양한 기준으로 다시 재조합하기 힘듦 참고로 qdirstat의 캐시 파일은 정말 만들기 쉬워서 여러 파일 같은 데이터를 시각화할 때 유용하게 활용할 수 있음

• 이제는 앱 비밀번호만으로도 로그인할 수 없게 되고 oauth 클라이언트 등록 등 복잡한 과정을 거쳐야 하는 게 정말 아쉬움 내 이메일임에도 구글이 스스로 접근할 수 있는 오픈 스탠다드를 빼앗아가버린 느낌임

  • 무료 Gmail 주소로 받는 스팸이 프리랜서용 유료 주소보다 압도적으로 많고, Gmail 서버에서 오는 스팸도 내 비Gmail 계정에 더 많이 옴 특히 프리랜서 이메일이 상대방 메일 시스템에서 자꾸 스팸 처리되는 걸 느끼고 나니 점점 더 구글 생태계를 벗어나고 싶은 마음이 커짐 다만 구글 의존 루틴에서 어떻게 벗어날지는 막막함, 부담감을 느낌

  • 잘 이해가 안 됨 앱 비밀번호만 있으면 IMAP 전체 접근 권한을 누릴 수 있음

  • 앱 전용 비밀번호는 오픈 스탠다드로 여기고 oauth는 오픈 스탠다드로 여기지 않는 이유가 궁금함

• 정말 멋짐 새로운 기능 요청: 이메일 본문에서 구독 해지 링크를 추출해서 자주 오는 발신자별로 쉽게 구독 해지할 수 있는 기능이 있었으면 함

• 나도 어제 똑같이 해봤었음, 도메인별로 받는 이메일 수를 리스트업 해보고 싶어서임 코드 퀄리티는 낮지만, 여기 있음: https://github.com/hugoferreira/gmail-sqlite-db

  • 나도 똑같이 도메인·발신자별로 그룹핑하려고 해봤음

• 이게 가능한 줄 몰랐음, 고마움

• Archiveopteryx(Postgres 기반 IMAP 서버) 생각이 조금 남: https://github.com/aox/aox AOX의 스키마가 항상 참 좋아보였는데 실제로 제대로 써볼 기회가 아직 없었음 주로 이메일 분석이나 검색 용도로 쓰고 싶었음

• 여기서 대역폭 비용이 얼마나 들어가는지 궁금함 나는 Gmail 용량만 40GB가 넘는데, 이 툴을 쓰면 전송량 때문에 청구서가 나올지 궁금함 물론 구글 테이크아웃(무료로 이메일 전체 다운로드) 받으면 파일 파싱만 하면 되니까 해결은 쉽지만 그래도 이 툴이 훨씬 빠르고 쉽게 시작할 수 있을 것 같음

• 이건 "imap to sqlite" 같은 이름이어야 하지 않나 싶음 왜 특정 이메일 제공업체에만 한정하는지 궁금함

  • 이유는 이 툴이 Gmail에 특화되어 있기 때문임 OAuth와 구글의 API 액세스를 활용하기 때문임 IMAP 방식은 훨씬 더 복잡하고 느리며, 구글의 대역폭 제한에도 걸림

  • 참고로, 몇 년 동안 내 gmail 계정 백업을 imap으로 시도해봤으나(심지어 gmail 맞춤 툴로도) 한 번도 성공한 적이 없음 잘 되는 동기화 툴도 한 달 정도 돌아가다가 결국 특정 메일을 못 가져와서 멈추곤 했음 아마 콜드스토리지 상태라서 그런 것 같기도 함 그래서 구글 고유 API를 쓰면 더 나을 것 같다고 생각함 현재는 Google Takeout에서 mbox를 바로 받고 문제 없이 빠르게 완전히 백업 가능해서 정말 좋아짐(반나절 정도 소요) 단점은 연속적 자동 업데이트가 되지 않음 참고로, 나는 이미 다른 메일 서비스(Infomaniak)로 옮겼고, 미리 독립 도메인을 갖고 있었던 걸 정말 잘했다고 생각함