주말 동안 간략하게 Gmail API를 살펴봤다. 나는 MVP 개발에서 Gmail API와 Upstage Document Parse 파이프라인을 담당했다. 실제 Gmail API를 사용해보는데, OAuth 활용이 쉽지 않았다. Google Cloud Platform에서 서비스 설정과 사용하는 API 어플리케이션을 설정하고 인증 정보를 확인하는데 오랜 시간이 걸렸다. 이마져도 시간이 지나면 인증이 만료되어서 매번 인증 정보가 담긴 JSON 파일을 삭제하고 다시 생성해야 했다.
단일 메일을 출력하는데 인코딩된 문자열이 너무 많았다. 메일 본문과 비교가 안 되어서 어떻게 파싱할지 감이 안 잡혔는데, 다른 팀원이 base64 기반 인코딩이라는 걸 발견했다. dict 구조가 겹겹이 쌓여있어 파악이 힘들었는데, 덕분에 인코딩에 대한 실마리를 찾았다.
오늘 한 일은 크게 3가지였다.
- HTML으로 작성된 메일 본문에서 정보 추출하기
- Gmail Thread에서 각 Thread 별로 메일 송수신 내역 가져오기
- refresh_token 정보 저장하는 방법을 찾아서 해결하기
3의 경우, 나와 Gmail을 같이 담당한 팀원이 프로젝트를 로컬 프로젝트로 설정하니 자동으로 해결했다는 경험을 공유해줬다. GCP 프로젝트를 삭제하고 다시 설정해야하나 고민하다가 run_local_server 함수에 넘겨주는 인자를 추가하니 해결했다. o1의 힘을 빌렸는데, o1이 없으면 많이 헤맸을 것 같다.
1은 원래 인코딩 문자열 디코딩을 담당하다가 다른 팀원이 HTML 구조로 파싱하는데 성공해 HTML 구조에서 정보를 읽어오기로 했다. 생각보디 HTML으로 작성된 메일이 정말 많았다. 특히 table 태그 파싱은 디자인적인 요소와 실제 정보(이를테면 행과 열의 순서에 따른 정보 등)가 혼재돼있어 어떻게 파싱할지 여러 방향으로 시도했다. 결국 Solar Pro로 읽어오니 plain text를 추출할 수 있었다. 다만 API를 한 번 더 호출하는 만큼 서비스 운용 비용이 늘어나는 점이 걸렸다.
팀 회의를 진행하면서 메일 분류 - 단일 메일 요약 - 요약문 취합 순으로 구상한 파이프라인을 단일 메일 요약(HTML 소스 그대로) - 메일 분류 - 요약문 취합 순으로 바꾸자는 아이디어가 나왔다. 우선 2번 작업인 각 Thread를 읽어오는 작업도 HTML 코드가 너무 길어서 확인이 안 되어 단일 메일 요약이 선행될 필요성이 있었다.
현장에 있는 멘토님께 HTML 파싱과 관련해서 특히 table 데이터를 다루는 방법을 여쭤봤다. 몰랐던 사실인데, table 데이터를 다루는 테스크가 생각보다 매우 어렵다는 갈 말씀해주셨다. 따로 table만 처리하는 모델이 있을 정도로 볼륨이 큰 테스크였다. 멘토님은 MVP에서 table을 배제하고 plain text만 고려하라는 조언을 주셨다. 이번 프로젝트에서 정말 많은 것을 배우고 실습할 것 같아서 기대가 된다. 이전 프로젝트와 확실히 출발부터 다르다는게 피부로 와 닿는다.
