이메일이 X.400이었다면 우리 삶이 어떻게 달라졌을까

우리가 매일 쓰는 이메일, 사실 '임시방편'이 살아남은 거예요

혹시 이런 생각 해본 적 있으세요? 왜 이메일은 아직도 스팸이 이렇게 많고, 첨부파일은 25MB만 넘어도 막히고, 발신자 주소를 위조하는 게 이렇게 쉬운지요. 사실 이게 다 우연이 아니에요. 우리가 지금 쓰는 SMTP라는 이메일 프로토콜은 1982년에 '일단 돌아가게 만들자'는 생각으로 빠르게 만들어진 물건이거든요. 그런데 재미있는 건, 비슷한 시기에 훨씬 정교하게 설계된 X.400이라는 표준 이메일 시스템이 있었다는 거예요. 그리고 만약 그쪽이 살아남았다면, 우리의 이메일 경험은 지금과 완전히 달랐을지도 모릅니다.

Buttondown 블로그에 올라온 이 글은 'SMTP가 이긴 게 정말 잘된 일일까?'라는 도발적인 질문을 던져요. 결론부터 말씀드리면, 이긴 건 기술적 우수성이 아니라 '단순함'과 '인터넷'이라는 시대적 흐름이었다는 거죠.

X.400이 뭐냐면, 이메일계의 '항공우주국'이었어요

X.400은 1984년에 ITU(국제전기통신연합)와 ISO가 함께 만든 메시징 표준이에요. 이게 뭐냐면, 통신회사들이 모여서 '전 세계가 쓸 수 있는 완벽한 이메일을 만들자'고 작정하고 설계한 시스템이에요. 그래서 처음부터 우리가 지금 SMTP에서 고생하는 문제들을 다 해결하도록 만들어졌어요.

예를 들어볼게요. X.400은 발신자 인증이 프로토콜 레벨에 내장되어 있어요. 지금 SMTP에서 우리가 SPF, DKIM, DMARC 같은 약자 세 개를 외워가며 겨우 막아내고 있는 스팸과 피싱 문제가, X.400에서는 애초에 일어날 수 없게 설계되어 있었던 거예요. 메시지를 보내려면 인증된 사용자여야 하고, 메시지에는 디지털 서명이 붙고, 수신 확인도 프로토콜이 보장해주거든요.

또 X.400 주소는 우리가 아는 'user@domain.com' 같은 단순한 형태가 아니라 'C=KR; A=KT; P=Samsung; O=Research; S=Kim; G=Minsu' 이런 식으로 국가, 통신사업자, 조직, 부서, 이름이 구조화되어 들어가요. 끔찍해 보이죠? 그런데 이게 사실은 디렉토리 서비스랑 결합되면 굉장히 강력해요. 회사 안에서 '연구소의 김민수'를 찾는 게 데이터베이스 쿼리처럼 정확하게 됩니다.

첨부파일도 마찬가지예요. SMTP는 원래 7비트 ASCII 텍스트만 보낼 수 있게 만들어져서, 우리가 지금 사진이나 PDF를 보내려면 MIME이라는 인코딩으로 텍스트로 바꿔서 보내고 있어요. 그래서 1MB 파일이 1.33MB로 부풀어 올라요. X.400은 처음부터 바이너리 데이터를 그대로 보낼 수 있도록 설계되어 있었습니다.

그런데 왜 졌을까요? '완벽함'이 패배한 이유

자, 이렇게 좋은데 왜 망했을까요. 글쓴이는 세 가지 이유를 꼽아요.

첫째, 너무 복잡했어요. X.400을 구현하려면 OSI 7계층 스택을 다 깔아야 했어요. 반면 SMTP는 TCP만 있으면 누구나 며칠 만에 구현할 수 있었죠. Sendmail의 첫 버전은 한 사람이 짧은 시간에 만들었어요. 결국 '돌아가는 70점짜리'가 '완벽한 100점짜리 설계도'를 이긴 거예요.

둘째, 돈이 들었어요. X.400은 통신사업자들이 운영하는 폐쇄적인 네트워크였어요. 메시지 하나 보낼 때마다 요금이 매겨졌습니다. 반면 SMTP는 인터넷 위에서 공짜로 돌아갔어요. 1990년대에 인터넷이 폭발적으로 보급되면서 게임은 끝난 거죠.

셋째, 표준화 위원회의 함정에 빠졌어요. ISO와 ITU가 모든 걸 합의해서 정하는 동안, IETF는 'rough consensus and running code(대충 합의하고 일단 돌리는 코드)' 정신으로 빠르게 움직였어요. 이건 표준화 역사에서 자주 반복되는 패턴이에요.

우리가 지금 치르고 있는 비용

이 글이 흥미로운 건, 우리가 지금 쓰고 있는 '공짜' 이메일이 사실 엄청난 사회적 비용을 치르고 있다는 점을 짚어준다는 거예요. 전 세계 이메일의 절반 이상이 스팸이고, 피싱으로 인한 피해는 매년 수십억 달러에 달하죠. Gmail이나 Outlook 같은 대형 사업자에 이메일이 집중되는 것도, 결국 SMTP 자체로는 인증과 신뢰를 보장할 수 없어서 거대 사업자의 평판 시스템에 의존하게 된 결과거든요.

비슷한 사례를 떠올려보면, HTTP가 HTTPS로 바뀌는 데 30년 가까이 걸린 것도 비슷해요. '일단 돌아가는 단순한 것'으로 시작하면, 나중에 보안과 신뢰를 덧붙이는 게 엄청나게 어려워져요. Matrix 프로토콜이나 ActivityPub 같은 현대 분산 메시징 시스템들이 처음부터 인증과 암호화를 내장하려 애쓰는 이유도 이 교훈 때문이에요.

한국 개발자에게 던지는 질문

이 글은 단순히 옛날이야기가 아니에요. 지금 우리가 만드는 시스템에도 똑같은 질문이 적용돼요. 'JWT로 대충 인증 붙일까, 처음부터 OAuth 제대로 깔까?', 'GraphQL 스키마를 느슨하게 갈까, 엄격하게 갈까?', '이벤트 페이로드에 타입 검증을 넣을까 말까?' 같은 일상적인 결정들이요.

특히 한국에서 사내 메신저나 이메일 게이트웨이를 다루는 개발자라면, 우리가 SPF/DKIM/DMARC 설정에 들이는 시간이 사실 1980년대에 잘못 선택된 길의 유산이라는 걸 알아두면 좋아요. 그리고 새로운 프로토콜을 설계할 때, '단순해서 빨리 보급되지만 나중에 후회할 것'과 '복잡하지만 처음부터 제대로 된 것' 사이의 트레이드오프를 의식적으로 고민해보는 계기가 될 수 있을 거예요.

마무리

결국 이메일의 역사는 '완벽한 설계'보다 '빠르게 퍼지는 적당한 것'이 이긴다는 기술 보급의 진리를 보여주는 사례예요. 그런데 그 대가를 우리는 40년째 치르고 있는 셈이고요.

여러분이라면 지금 새로운 통신 프로토콜을 처음부터 설계할 수 있다면, X.400처럼 무겁더라도 인증과 구조를 강제하는 쪽을 택하시겠어요, 아니면 SMTP처럼 가볍고 자유로운 쪽을 택하시겠어요? 기술이 사회에 미치는 영향이라는 관점에서 한 번 생각해보면 재미있을 것 같아요.