에어데스크 + Gmail API 개발일지
24시간 안에 Gmail API 연동하기
지메일 API를 연동한 에어데스크의 모습안녕하세요. 에어데스크의 프로그래머 한상훈입니다. 지난주 금요일(2월 22일)부터 에어데스크에서 지메일을 사용할 수 있게 됐습니다. 이제 클릭 한 번이면 이메일을 확인할 수 있습니다! 그럼 어떻게 개발했는지 하나하나 적어보겠습니다.
첫번째날: 0~12시간
어떤 디자인으로 만들까?
저는 만들기 전 항상 완성된 모습을 상상합니다. 완성된 모습이 아름답기 위해서 모티브로 삼을 디자인을 찾아보았습니다. 도움을 받은 사이트는 드리블과 비핸스입니다. 드리블은 최신 웹 디자인이 모두 모여있는 성지이고, 비핸스는 전세계 최고의 포트폴리오 사이트입니다.
Inbox - Web Appby Michal Parulski, Dribbble많은 디자인, 레이아웃이 있었지만 그 중에서 가장 마음에 든 것은 위의 이미지입니다. 넓은 공간과 밝은 색체감이 마음에 들었습니다. 이 이미지를 가이드라인으로 정하고 개발을 시작했습니다.
API 문서 살펴보기
지메일을 자신의 애플리케이션에 사용하기 위해선 API를 사용하면 됩니다. 한가지 장점은 구글의 거의 모든 제품은 API를 제공하고 있고, 메커니즘이 동일합니다. 그렇기 때문에 이미 구글 캘린더와 테스크 기능을 개발해본 상황에서 지메일 API 역시 빠르게 익힐 수 있었습니다.
개발 문서를 살펴보면서 API가 작동되는지 테스트했습니다. 기본이 되는 메일 보기, 메일 리스트 가져오기, 삭제하기를 사용해보고 메커니즘을 이해하는데에 오랜 시간이 걸리지 않았습니다. 한 번씩 작동시켜보고, 어떤 매개변수(파라메터)가 들어가는지 확인합니다.
이제 확장 프로그램에서 테스트해봅니다. 큰 골격이 되는 함수를 만들어 확장 프로그램에서 테스트를 진행한 후에 정상적으로 작동되는걸 확인했습니다. 여기까지 1시간 내외의 시간이 소요됐습니다.
확장 프로그램 프로그래밍
이제 본게임을 시작합니다. 먼저 에어데스크의 메인 메뉴바에 지메일 아이콘을 추가해줍니다. 아이콘을 직접 그리지 않고 Flaticon에서 가져옵니다. 이미 Flaticon의 라이센스를 구입한 상태기 때문에 저작권 표시를 따 해줄 필요도 없습니다.
메인 메뉴에 추가된 지메일 아이콘적절한 아이콘을 넣어본 후 창 이벤트를 만듭니다. 아이콘을 클릭했을 때 창이 열리고 닫힐 수 있도록 하는 과정입니다. 지메일은 창의 형태과 구조가 다르다보니 기존의 사용하던 창 생성 함수가 아닌 새로운 함수를 만들어 사용했습니다. 창이 열리면 필수 이벤트를 부여합니다. 드래그와 크기조절, 열리고 닫힐 때의 애니메이션 효과 등입니다. 이 과정이 끝나고 레이아웃을 구성하는 HTML를 만들어줍니다.
기본 골격이 되는 레이아웃1번엔 사이드 메뉴를 넣습니다. 2번엔 이메일 리스트를 보여줍니다. 3번엔 이메일이 열린 상태를 보여줍니다.이렇게 큰 틀의 레이아웃을 만든 후에 각각의 구성요소를 만드는 하위 함수를 만들어줍니다.
개별 이메일 상자 만드는 함수
별표 체크를 모두 관리하는 함수
각각의 편리함을 여는 함수
각각의 이메일을 여는 함수
각각의 함수 안에는 다양한 이벤트가 함께 들어갑니다. 예를 들면 각각의 이메일이 열리면 그 안에 삭제 이벤트 역시 포함되어 있습니다. 저도 만들면서 놀란 부분 중 하나는 지메일 API의 구조는 재사용성이 높아 코드를 수정해서 사용할 필요가 거의 없습니다. 예를 들자면 모든 GET요청을 다루는 함수에 필요한 변수가 한 개입니다. 이렇게 매개변수 하나인 함수를 모든 GET 요청에 사용할 수 있기 때문에 기능을 구현하는 과정은 매우 빠르게 이뤄졌습니다.
시간을 끄는 요인은 결국 스타일링
기능의 구현을 모두 마치는데에 큰 시간이 소요되지 않았습니다. 하지만 뭐든 멋지게 만들어야 하지 않겠습니까? 원하는 디자인과 작동방식을 만들기 위해 수 천 번의 새로고침을 진행하며 CSS파일을 수정합니다.
중점을 둔 부분은 글씨 크기와 크기 변화에 따른 이질감을 줄이는 일이었습니다. 위의 레이아웃은 크기 변동이 없는 단순한 이미지입니다. 반면 저는 창의 크기변화까지 고려한 디자인을 해야했습니다.
기본 사이즈의 메일 화면위의 이미지는 기본 사이즈의 메일 창을 열었을 때의 모습입니다. 이렇게 이메일이 텍스트가 아닌 경우 모든 컨텐츠를 보여주지 못하는 경우가 발생합니다. 하지만 크기를 자유롭게 조절할 수 있다면 아래처럼 넓게 볼 수 있습니다.
넓은 화면의 메일창자유롭게 크기를 조절할 수 있으면서 전체적인 무게감을 해치지 않는 디자인을 짜기 시작했습니다. 각각의 구성요소의 디테일한 부분을 기존 테마 컬러와 대조하면서 스타일을 수정했습니다. 이 과정이 약 8~9시간 가까이 소요되었습니다. 이제 남은 부분은 이메일 쓰기였기에 내일이면 끝내겠구나 싶은 마음으로 편안한 잠에 들 수 있었습니다.
두번째날: 12~20시간
이렇게 쉽게 끝날리 없지
첫번째날의 성과는 좋았습니다. API를 성공적으로 테스트했고, 이메일 가져오기, 삭제하기, 별표, 읽기 모두 구현했기 때문입니다. 그러나 저는 몰랐습니다. 이메일 쓰기가 그렇게 어려운건지.
저는 전날의 API 테스트 덕분에 이메일 쓰기 과정을 쉽게 생각했습니다. 하지만 이메일 쓰기 과정은 생각보다 어려웠습니다. 첫번째로 발견한 문제는 API가 작동하지 않고 에러를 발생하는 것입니다. 틀린 부분이 없는데도 자꾸 에러를 발생하고, 어떤 경우엔 되고 어떤 경우엔 안되는 상황이 지속됐습니다. 알고보니 이메일 전송 양식에 들어가는 텍스트 문제였습니다.
from memegenerator.net지메일 API는 RFC 2822 포맷을 활용해서 이메일을 전송합니다. 그런데 이 포맷은 띄어쓰기 하나만 부적절하거나 줄바꿈이 하나 더 있거나 없으면 문제가 발생합니다. 이때 제가 실수한 부분은 잘 모르니 RFC 2822 문서를 잘 읽어봐야지 했다면 좋았을텐데 휙 보고, '아 보기 싫다.'하고 구글링만 했던 점입니다. 만약 이메일 API를 사용하시려는 분들은 꼭 RFC 포맷을 잘 읽어보시길 추천드립니다.
지메일 API의 이메일 전송은 과정은 3단계로 구성됩니다.
이메일의 모든 데이터를 품은 raw 텍스트를 만듭니다. raw 텍스트에는 보내는 사람, 받는 사람, 함께 받는 사람, 데이터 형식, 인코딩 형식등 모든 메타 데이터를 포함하고, 이메일 본문과 HTML, 함께 보내지는 여러 파일들까지 들어갑니다.
그 다음 이 전체를 base64url로 인코딩합니다. base64url 인코딩은 base64와 약간 다릅니다. 인터넷에서 사용되는 몇가지 문자를 추가적으로 치환해서 인코딩하는 방식입니다. 보통 웹 앱의 경우 base64url을 처리해주는 모듈을 설치해서 이를 쉽게 해결할 수 있지만 확장 프로그램에서는 모듈을 사용하는데 문제가 있습니다. 그렇기에 직접 코드를 작성해야하는데 이 과정에서 어려운 점을 또 발견합니다.
바로 UTF8 입니다. 한국어를 포함한 많은 언어들이 인코딩할 때 추가로 처리해주어야하는 경우가 발생합니다. 보통의 경우 UTF8로 인코딩한다는 간단한 명령으로 가능하지만 이메일 전송에는 RFC 2822 포맷에 맞게 해줘야한다는 문제가 있습니다.
만만치 않아.. RFC 2822.. 아니 너무 쌔..
RFC 포맷은 아주 철저합니다. 인터넷의 고대 시대부터 사용되던 기술이기 때문에 많은 제약이 있습니다. 요즘은 데이터를 보낼 때 띄어쓰기나 줄 바꿈에 신경써서 데이터를 보내지 않지만 이 친구는 용납하지 않습니다.
헤더에는 빈칸이 없이 줄의 처음을 채워야 합니다. 띄어쓰기가 들어간 헤더의 줄이 있으면 Invalid 에러를 만납니다. 그 뿐 아니죠. 헤더에 들어가는 이메일, 제목에도 신경을 써야합니다. 특히 제목이 한글인 경우 UTF8 인코딩을 해줘야하는데 보통의 인코딩 함수로 변경을 해서 보내면 안됩니다. 이것이 UTF8로 인코딩되었다는 표시를 RFC 포맷에 맞게 표시해주어야 합니다.
=?UTF-8?B?인코딩된 제목?=
그럼 이렇게 하면 끝이냐? 그것도 아닙니다.
위의 방법대로 하면 한글 제목을 전송할 수는 있지만 또다른 문제가 생깁니다. "안녕"이라는 제목으로 이메일을 보내면 잘 보내지지만 "22"나 "abc" 처럼 짧고, 영어만 있는 것들은 보내지지 않는 현상이 나타납니다. 아주 열받는 일입니다. 하라는대로 인코딩 코드를 넣어두었더니 도리어 잘 보내지던 텍스트가 안 보내집니다.
도대체 어쩌라는거야?많은 삽질 끝에 알게된 원인은 인코딩할 필요없는 텍스트를 인코딩하면 RFC 2822 포맷에 어긋나기 때문입니다. 결국 인코딩을 해야하는 것과 안 해야하는 것을 구분하는 함수도 포함해서 헤더를 구성해야했습니다. 물론 인코딩 필요성을 구분하는 함수는 자바스크립트 내장 함수를 통해 3~4줄로 구현할 수 있었기에 더이상 헤더에서 문제가 발생하지 않았습니다.
세번째날: 20~24시간
별거 없는 마지막날
마지막날엔 기본적인 작업을 했습니다. 세부적인 디자인을 손보고, 문제가 되는 부분은 없는지 테스트하고, 업데이트 준비를 했습니다.
지메일 API를 3일에 걸쳐서 구현을 해봤는데 생각보다 더 쉬웠습니다. 만약 이렇게 쉬운 줄 알았다면 진작에 만들었으면 좋았을거 같습니다. 만약 각각의 포맷이나 인코딩과 같은 부분에 지식이 있었다면 하루만에라도 거의 모든 부분을 끝낼 수 있었을거 같아요. 하지만 프로그래머는 모두 삽질하면서 성장한다는걸 알기 때문에 즐거운 시간이었습니다.
