한 통의 이메일이 전 세계를 건너는 방법

한 통의 이메일이 전 세계를 건너는 방법
— 이메일 표준에서 HR과 협업의 힌트를 얻다

 

얼마 전, 문득 이런 궁금증이 떠올랐습니다.
“네이버 메일이랑 구글 메일은…
대체 어떻게 서로 메일을 주고받는 거야?”

곰곰이 생각해보면 꽤 신기한 일입니다.
회사도 다르고, 인프라도 다르고, 내부 시스템 구조도 전혀 다를 텐데

우리는 아무 생각 없이 ‘전송’ 버튼을 누르고, 메일은 대체로 문제없이 도착합니다.

실제로 전 세계에서는 매일 수억 통 이상의 이메일이 오갑니다.

서버 위치, 운영체제, 개발 회사가 제각각임에도 이메일은 비교적 높은 신뢰도로 전달됩니다.

이게 가능한 이유는 기술의 우월함 때문이라기보다,

“완벽하진 않지만, 최소한 통하기로 한 규칙” 덕분입니다.

---

1️⃣ 서로 달라도 괜찮았던 이유 — 이메일 표준의 탄생

1970~80년대 인터넷 초기에는 기관과 기업마다 네트워크 환경과 시스템 구조가 제각각이었습니다.

그 상태로는 메시지를 안정적으로 주고받는 것 자체가 어려웠죠.

이 문제를 해결하기 위해 만들어진 것이 SMTP(Simple Mail Transfer Protocol)

— 이메일 전송을 위한 표준 프로토콜입니다.

이 표준 설계에 핵심적인 역할을 한 인물이 존 포스텔(Jon Postel)이며,

그가 활동하던 인터넷 표준 커뮤니티(IETF)는 인상적인 원칙을 남겼습니다.

“우리는 완벽한 합의가 아니라, 대략적인 합의와 실제로 작동하는 코드를 믿는다.”

(Rough consensus and running code)

뜻을 풀면 이렇습니다.
모두를 100% 만족시키는 완벽한 규칙을 기다리기보다

“대충 동의할 수 있고, 실제로 잘 돌아가는 방식”을 먼저 채택하자

완벽함보다 작동 가능성, 이상보다 현실적인 합의를 선택한 셈입니다.

---

2️⃣ 이들은 ‘통일’을 강요하지 않았다

이메일 표준의 핵심은 모든 시스템을 하나로 맞추는 것이 아니었습니다.

오히려 정반대였습니다.
- 각 서버는 내부 구조를 자유롭게 설계해도 된다.
- 데이터 저장 방식, 보안 정책, 인프라는 제각각이어도 된다.
- 단, 외부와 통신할 때만 최소한의 형식과 규칙을 맞춘다

즉, “안에서는 각자 마음대로, 밖에서는 같은 언어로” 움직이는 구조였습니다.

상대 서버가 어떤 구조인지 몰라도
- 누가 보냈는지
- 누구에게 가는지
- 내용을 어떤 형식으로 전달할지

이 최소한의 약속만 지키면 시스템은 충분히 협력할 수 있었습니다.

이메일이 안정적으로 작동하는 이유는
기술의 통일이 아니라, 경계에 대한 합의에 가깝습니다.

---

3️⃣ 이건 기술 이야기이면서, 동시에 ‘권력’의 이야기다

흥미로운 점은 이 규칙이 특정 기업이나 정부가 일방적으로 정한 것이 아니라는 점입니다.

인터넷 표준은
- 강제보다는 자발적 채택
- 명령보다는 합의
- 권위보다는 “실제로 잘 돌아가는지”를 기준으로 발전해왔습니다.

즉, 누군가 모든 걸 통제하지 않아도 “다 같이 쓰기 편한 규칙”이 있으면

시스템은 자연스럽게 연결될 수 있다는 철학이 깔려 있습니다.

권력을 중앙에 집중시키기보다, 규칙을 분산시키는 방식으로 협력을 만든 구조라고 볼 수도 있습니다.

---

4️⃣ 이 대목에서 HR과 조직 협업이 떠오른다

조직에서도 비슷한 장면을 자주 봅니다.
협업이 잘 안 되면 우리는 보통 이렇게 말합니다.

- “프로세스를 통일하자”
- “포맷을 하나로 맞추자”
- “보고 체계를 표준화하자”

물론 필요합니다.
하지만 모든 팀을 하나의 방식으로 맞추려는 시도가
오히려 속도를 늦추고, 유연성을 해치고,
현장의 피로도를 높이는 경우도 적지 않습니다.

이메일 표준이 주는 힌트는 조금 다릅니다.

모든 팀을 똑같이 만들 필요는 없다.
대신, 서로 연결되는 ‘접점’만 명확하면 된다.

각 팀은
- 일하는 방식이 달라도 되고
- 사용하는 도구가 달라도 되고
- 의사결정 스타일이 달라도 됩니다

대신, 다른 팀과 만나는 지점에서는 최소한의 약속이 필요합니다.

예를 들면
- 언제 공유하는가
- 어떤 형식으로 전달하는가
- 최종 결정은 어디서 나는가

이건 통제의 문제가 아니라,

“협업이 가능하도록 인터페이스를 설계하는 문제”에 가깝습니다.

이메일 서버들이 서로의 내부 사정을 몰라도 협력하듯,

조직도 모든 걸 통일하지 않아도 충분히 연결될 수 있습니다.

---

5️⃣ HR 관점에서 보면, 이건 ‘제도’보다 ‘합의 구조’의 문제다

HR은 종종 제도를 더 정교하게 만들수록 조직이 더 잘 굴러갈 거라고 믿습니다.

하지만 현실에서는
- 규정이 많아질수록
- 예외가 줄어들수록
- 통제 포인트가 늘어날수록

운영은 더 느려지고, 현장은 더 피로해지기도 합니다. 이메일 표준이 보여준 방식은 정반대입니다.
- 내부는 유연하게 두고
- 외부와 연결되는 최소 규칙만 분명히 하고
- 완벽이 아니라 “충분히 잘 돌아가는 상태”를 목표로 삼는다

조직 운영도 ‘완벽한 설계’보다 ‘운영 가능한 합의’에 더 가까워질 필요가 있을지 모릅니다.

이메일은 완벽해서 살아남은 기술이 아닙니다. 대충 맞지만, 실제로 잘 작동했기 때문에 표준이 됐습니다.

조직도 마찬가지일지 모릅니다.
- 모든 팀을 하나로 맞추려 애쓰는 조직보다
- 서로 다른 팀들이 무리 없이 연결될 수 있는 최소 규칙을 가진 조직이 더 빠르고, 더 오래, 더 유연하게 움직입니다.

“서로 다른 회사 서버들은 어떻게 같은 언어로 대화할까?”
그 답은 완벽한 통일이 아니라, 불완전하지만 현실적인 합의에 있습니다.

그렇다면 우리 조직은 어떨까요?
우리는 지금 더 완벽한 규칙을 만들고 있을까요,
아니면 더 잘 작동하는 약속을 만들고 있을까요?

이메일이 수십 년 동안 살아남은 이유가 완벽함이 아니라 ‘현실적인 합의’였다면

우리 조직의 협업 방식도 그 기준으로 다시 한 번 점검해볼 만하지 않을까요?