본인은 최근에 직장일 때문에 이메일을 자동으로 생성해서 보내는 프로그램이란 걸 난생 처음으로 작성해 봤다. 소켓 API만 써서 말이다.
서식이고 첨부고 몽땅 다 생략한 최소한의 형태만 생각한다면, 이메일을 보내는 것 자체는 내 예상보다 굉장히 간편하게 쉽게 자동화할 수 있는 일이라는 걸 알 수 있었다. SMTP 서버 명령어 몇 개만 스펙대로 주고 받으면 된다.
발신자는 말할 것도 없고 수신자조차도 실제로 수신하는 대상과 화면에 표시되는 수신자가 서로 다르게 얼마든지 조작 가능하다. 스팸 메일을 대량으로 살포하는 건 일도 아니겠다는 걸 이제야 느꼈다. 이런 문제도 있고, 또 이메일 내용을 다른 해커가 가로챌 수도 있으니 이 바닥에도 온갖 복잡한 인증과 암호화 계층이 나중에 도입된 거지 싶다.
이메일과 관련하여 서버에다 요청을 보낼 때는 줄 바꿈 문자가 \n이 아니라 반드시 \r\n을 써야 한다는 게 인상적이었다. 이건 어째 유닉스가 아닌 DOS/Windows 진영의 관행과 일치한다. 그리고 메일 본문의 끝을 의미하는 게 도스의 copy con이 사용하는 Ctrl+Z 같은 제어 문자가 아니라 그냥 "빈 줄+마침표+빈 줄"이다.
또 주목할 만한 것은 DATA(본문)에 들어가는 발신 날짜였다. 난 메일을 보내면 발신 시각 정도는 메일 서버가 자기 시각을 기준으로 당연히 자동으로 넣어 줄 거라고 생각했다. 사람이 이메일을 보낼 때 발신 시각을 일일이 써 넣지 않듯이 말이다.
하지만 내부적으로는 그렇지 않았다. 보내는 쪽에서 알려 줘야 하며, 허위로 조작된 임의의 날짜· 시각을 보내는 것도 얼마든지 가능하다.
그리고 여기에 써 주는 날짜· 시각은 "Tue, 18 Nov 2014 13:57:11 +0000" 같은 형태로, 날짜와 시각, time zone을 모두 포함하고 있다. 심지어 요일이라는 일종의 잉여 정보도 있다.
이 형식은 RFC 2822에 표준 규격으로 정해졌는데, 보다시피 사람이 읽기 편하라고 만들어졌지 컴퓨터의 입장에서 간편하게 읽고 쓸 수 있는 형식은 아니다. 컴퓨터의 관점에서는 그냥 1970년 1월 1일 이래로 경과한 초수, 일명 Unix epoch 숫자 하나가 훨씬 편할 텐데 말이다. time zone도 무시하고 UTC만 통용시키고 말이다.
실제로 이 날짜· 시각 문자열은 그 형태 그대로 쓰이지 않는다. 어차피 이메일 클라이언트가 파싱을 해서 내부적으로 Unix epoch 같은 단순한 형태로 바꿔야 한다. 그래야 당장 메일들을 오래된 것-새것 같은 순서대로 정렬해서 목록을 뽑을 수 있을 테니 말이다. 또한 그걸 출력할 때는 "2014년 11월 18일 오후 10시 57분 11초"처럼 사용자의 언어· 로케일과 설정대로 형태가 또 바뀌게 된다.
그러니 사람보다는 기계가 더 활용하는 날짜 시각 문자열 포맷이 왜 저렇게 복잡한 형태로 정해진 건지 의문이 들지 않을 수 없다. 읽고 쓰기 위해서 달 이름과 요일 이름 테이블까지 참조해야 하고 말이다. 글쎄, SMTP 명령어를 사람이 직접 입력해서 이메일을 보내던 엄청난 옛날에 사람이 읽고 쓰기 편하라고 저런 형태가 정해진 건지는 모르겠다.
Windows API의 GetDateFormat/GetTimeFormat 내지 C 언어의 asctime/ctime 함수 어느 것도 이메일의 날짜· 시각 포맷과 완전히 일치하는 문자열을 되돌리지는 않는다. 특히 C 함수의 경우,
Tue Nov 18 13:57:11 2014
로, 년월일 시분초 요일까지 정보가 동일하고 맨 처음에 요일이 나오는 것까지도 일치하지만.. 이메일 포맷과는 일치하지 않는다. C 함수도 나열 순서와 글자수가 언제나 동일하고 불변인 것이 보장돼 있기 때문에 저걸 변경할 수는 없다. 저 결과값을 그대로 쓸 수도 없으니 답답하기 그지없다.
참고로 일반인이 저런 날짜· 시각 format 함수를 작성한다면 그냥 단순무식하게 sprintf "%02d %s" 같은 방식으로 코딩을 하겠지만, 프로그래밍 언어 라이브러리에서는 그런 짓은 하지 않고 성능을 최대한 중요시하여 각 항목들을 써 넣는 것을 한땀 한땀 직접 구현한다. 해당 라이브러리의 소스를 보면 이를 확인할 수 있다.
Windows API에는 SYSTEMTIME이라는 구조체가 있고, C에는 tm이라는 구조체가 있어서 날짜와 시각을 담는 역할을 한다. 그런데 tm이라니.. 구조체 이름을 무슨 변수 이름처럼 참 이례적으로 짧고 성의없게 지은 것 같다. -_-
C 시절에는 앞에 struct라는 표식을 반드시 덧붙이기라도 해야 했지만 C++은 그런 것도 없으니 더욱 난감하다. C++의 등장까지 염두에 뒀다면 이름을 절대로 저렇게 지을 수 없었을 것이다.
또한 tm 구조체의 멤버들 중 월(tm_mon)은 1이 아니라 0부터 시작한다는 것, 그리고 연도(tm_year)는 실제 연도에서 1900을 뺀 값을 되돌린다는 것도 직관적이지 못해서 번거롭다. 즉, 2019년 7월은 각각 119, 6이라고 기재된다는 것이다. 그에 반해 Windows의 SYSTEMTIME은 그렇지 않으며 wYear과 wMonth에 실제값이 그대로 들어가 있다.
월이 0부터 시작하는 건 쟤네들 문화권에서는 어차피 월을 숫자가 아닌 이름으로 취급하기 때문에 배열 참조의 편의를 위해서 그렇게 했을 것이다. 그런데 연도는.. 무슨 공간을 아끼려고 굳이 1900을 뺐는지 모르겠다. 16비트 int 기준으로 서기 32767년만 해도 정말 까마득하게 먼 미래인걸 말이다.
아 하긴, 20세기 중후반엔 연도의 마지막 두 자리(10과 1)만 써도 70이니 90이니 하면서 월과 일의 숫자 범위보다 월등히 컸기 때문에 변별력이 있었다. 연도도 두 자리만 쓰는 게 관행이었기 때문에 1900을 빼는 것은 그런 관행을 반영한 조치였을 것이다. Office 97은 있어도 Office 07은 없고 2007이니까 말이다.
엑셀 같은 스프레트시트들도 날짜 겸 시각을 저장하는 자료형의 하한이 1900년 1월 1일로 잡혀 있다. 그래서 한국 최초의 철도가 개통한 1899년 9월 18일 같은 날짜는 아슬아슬하게 날짜형으로 저장하지 못하며, 일반 문자열로만 취급된다. =_=;;
이렇게 인간 가독형 날짜· 시각 말고 기계 가독형으로 직렬화된 날짜· 시각을 저장하는 정수 자료형으로 Windows에는 FILETIME이 있고, C에는 time_t가 있다. FILETIME은 Windows NT 시절부터 64비트로 시작했지만 후자는 2000년대 이후에 와서야 2038년 버그를 미연에 방지하기 위해 각 플랫폼별로 64비트로 확장됐다. 사실, 이때부터 PC도 64비트로 바뀌어서 플랫폼에 따라서는 long 같은 자료형도 64비트로 바뀌기도 했다..
그리고 요일이야.. 두 구조체 모두 일요일이 0이고 토요일이 6이다.
요일도 이름이 아닌 숫자로만 취급하는 언어는 내가 알기로 중국어밖에 없는데 혹시 더 있는지 궁금하다. 물론 인간의 언어에는 설마 0요일이 있을 리는 없고 1부터 시작할 텐데.. 중국어의 경우 일요일은 日이어서 이게 0 역할을 하고, 월요일부터 토요일까지가 1요일~6요일에 대응한다.
이상이다. 이메일 얘기로 시작해서 날짜 시각 얘기로 소재가 바뀌었는데..
이메일(POP3/SMTP)을 비롯해 HTTP, FTP 같은 표준 인터넷 프로토콜들을 클라이언트와 서버를 모두 소켓 API만으로 직접 구현해 보는 건 코딩 실력의 향상에 도움이 될 것 같다. 일상생활에서야 이미 만들어져 있는 솔루션만 사용하면 되니까 실용적인 의미는 별로 없겠지만, 학교에서 학술..도 아니고 그냥 교육적인 의미는 충분히 있을 테니 말이다. 내부 구조를 직접 살펴보면, 이런 프로토콜의 secure 버전이 왜 따로 만들어져야 했는지 이유도 알게 될 것이다.
더구나 이를 응용해서 특정 메일에 대해 자동 회신을 보내는 프로그램, 한 FTP 서버의 파일을 다른 FTP 서버로 올리는 프로그램까지 만드는 건 시험이나 과제 용도로도 괜찮아 보인다. 요즘은 FTP 같은 거 명령어로 이용할 줄 아는 사람이 얼마나 될까? 당장 본인도 모른다. ㅎㅎ
이메일을 쓰지 않는다는 도널드 커누쓰 할배가 문득 생각난다. 이분이야 뭐 1970년대, 컴퓨터 네트워크라는 건 그냥 기업· 연구소, 정부 기관만의 전유물로 여겨졌고 이메일이란 게 처음으로 발명됐던 시절에 그걸 다뤄 왔던 분이다. 그러다가 현역 은퇴 후에 때려치우고 온라인 공간의 속세와 단절한 셈이다. 이젠 뭐가 아쉬워서 누구에게 이메일로 연락을 하거나 연락을 기다려야 할 처지도 전혀 아니고.. 그냥 아날로그 종이 편지를 취급하는 것만으로 충분하시댄다.
Posted by 사무엘
