brunch

You can make anything
by writing

C.S.Lewis

by 스캇아빠 Jun 19. 2024

통신과 웹페이지

다들 잘 살고 있지?


[따르릉!!! 전화벨이 울린다]

- 여성: 여보세요

- 남자아이: 안녕하세요. 저는 영대친구 섭섭인데요. 영대 집에 있나요?

- 친구엄마: 아~ 섭섭이구나. 영대 지금 너 만나러 나간다고 오전에 나갔는데? 못 만났니?

- 섭섭이: 아니요. 저 아침에 할머니집에서 갔다 와서 지금 와서 전화드린 건데요?

- 친구엄마: 아. 그러니? 그럼 영대 찾으면, 바로 집에 들어오라고 전해줄래?

- 섭섭이: 네. 알겠습니다. 그럼 안녕히 계세요.

- 친구엄마: 그래, 그럼 들어가라


당시에는 그랬다. 핸드폰이란 것이 없었고, 삐삐도 없던 시절에는 집으로 전화하는 것이 유일한 통신 수단이었다. 부모님 세대는 그런 것도 없었다고 배부른 소리라고 하실지 모르겠지만, 지금 생각하면 그냥 야만의 세계가 아니었나 싶다.


지금 사용하는 컴퓨터 통신도 그런 야만의 세대에 만들어졌다. 웹통신이니 이메일이니 하는 것들 말이다. AI가 세상을 지배하는데 통신은 핸드폰도 없던 시절의 규격이라니 조금 우습기도 하고, 반대로 진짜 잘 만들어진 규격이었으니까 지금까지 쓸 수 있나 싶기도 하다.


1. 인터넷통신

인터넷통신은 물 위에 띄우는 종이배와 같다. 종이배에 받는 사람이름과 보내는 사람 이름을 쓰고 띄우면, 개천이 강을 만나고 강이 바다를 만나서 바다를 헤매다, 다시 강을 거슬러 올라가고 개천을 지나 받는 사람 집 앞으로 흘러가는 종이배와 같다. 그러면 다시 받은 사람은 잘 받았다는 종이배를 띄우고….


이렇게 보내는 행위를 통신이라고 하고 잘 보내는 사람 받는 사람주소를 써서 잘 받았다는 통신을 하면 TCP/IP 통신이라고 한다. 받았다는 걸 답장 안 하면 UDP 통신인데, 그런 것은 별로 중요하진 않다. 중요한 것은 그 TCP나 UDP 통신에 다시 말해 종이배에 어떤 것을 올리느냐가 통신에 중요한 것이 아닐까? 마치 맞춤법은 틀려도 재미있는 글이 있는 반면, 맞춤법은 다 맞지만, 읽는데 재미가 하나도 없는 글처럼 말이다.


통신은 전달되는 방식에 따라 대화형이 있고 요청/응답 방식이 있다. 우리가 이메일을 보낼 때 쓰는 통신은 (SMTP) 대화형이다. 일단 통신이 시작되면 서로 인사(HELO)부터 하고 내 이름은 뭐야라고 하면 OK라고 하고 받는 사람은 누구야 라고 하면 또 OK라고 하고 내용을 보낸다. 그리고 우리가 웹통신을 할 때 쓰는 통신은 (HTTP) 요청/응답 식이다. 내 이름부터, 내가 쓰는 브라우저, 이전에 통신을 한적에 있는지 아닌지, 그리고 이번 요청의 목적까제 한 문장으로 쭉 써서 보내면, 받은 사람은 요건에 맞으면 응답을 해준다.


섭섭이 : 제 이름은 섭섭이인데요, 아침에 할머니집에 다녀와서 이제 막 전화해요. 영대 있나요?

친구엄마 : 영대 없는데, 너 만나러 아침에 나갔는데, 만나면 집에 당장 들어오라고 전해라.


우리가 쓰는 이메일은 오히려 대화형이고, 웹통신은 편지처럼 오고 간다는 게 아이러니다. 하지만, 인터넷 속도도 빨라지고, 개개인의 컴퓨터(클라이언트)가 빨라지면서, 요청/응답식의 통신도 충분히 빨라졌고, 문제를 일으키는 일이 적어졌다. 실제로 우리가 모르는 사이 종이배가 오가면서 종이배가 가라앉기도 하고, 먼저 보낸 종이배가 나중에 보낸 종이배보다 늦게 도착하는 경우도 발생하기도 한다.


2. 웹페이지 기술

웹페이지는 정말 많은 기술이 빠르게 개발되고 있다. React, Angular, Vue.js, jQuery, Ember.js, Backbone.js, Svelte,.... 등등등 이제는 포켓몬스터 이름만큼이나 많아진 것 같다.


아주 오래전 친구 놈 한놈이 HTML만 알면 외국(유럽 어느 나라 던 것 같은데, 기억이 잘..)에서 취업할 수 있다고 한 적이 있었다. 외국은 인터넷 속도도 느리고, 컴퓨터 발전이 더뎌서, 우리나라같이 인터넷이 발전된 나라 사람들이 가면 돈을 긁어모을 수 있다고 했었다. 당연한 이야기지만, 사실은 그렇지 않았다.


영어를 사용하는 나라의 개발자들은 표준 규약이나 새로운 기술에 대한 안내서를 쉽게 접할 수 있다. 예전에 RFC문서 (표준규약문서)를 하나 읽는 데 낑낑거리면서 며칠을 보냈던 나로서는, AWS 튜토리얼 문서를 간단히 읽으면서 하나씩 "아 그렇구나" 라며 개발하는 캐나다 개발자들이 부럽지 않을 수 없었다. 개발자 문서 또는 인터넷 커뮤니티를 통해 플랫폼 발명자들의 글을 읽으면서 실시간으로 지식을 쌓는 자들과 단어 하나하나마다 사전을 찾아보며 개발하는 자의 실력차이를 확인하는 데는 오랜 시간이 걸리지 않았다. 그리고 안타깝게도, 그 격차는 웹페이지를 빨리 만들기 위한 플랫폼들이 하나씩 생길 때마다 더 벌어지는 것처럼 보였다.


지금 여기서 무슨 기술을 공부하라고 말할 수도 있다. 어떤 플랫폼이 전망이 좋으며 어떤 것의 장단점을 이야기해서 정보를 제공할 수도 있다. 하지만 그렇게 하지 않겠다. 내가 게으른 것도 있지만, 다른 이유로는 어느 것도 별로 중요하지 않기 때문이다. 비슷한 시기에 나온 플랫폼은 서로 간의 장단점을 알고 있다. 그리고 그 장단점을 보완하려 노력했다. 만약 당신이 한 가지를 이용해서 뭔가를 만들 수 있다면, 다른 플랫폼으로도 만들 수 있을 것이다. 그래서 지금 하고 싶은 말은?


"선택은 간단히 하고 일단 시작해서, 뭔가를 만들어봐. 선택은 중요하지 않아"


PS. 지운글의 기록

4시간 넘게 작성한 글을 모두 지웠다. 통신 관련 글에는 할 말이 너무 많고, 역사도 너무 길다. 프로그래머로써 나의 첫 번째 프로젝트는 한국어/중국어/일어 문자변환기(Serialization)였고, 두 번째 프로젝트는 FTP통신클라이언트였다. 그리고, 그렇게 신이 나서 한참을 쓰다 보니, 글은 산으로 가고 있었고, 대부분의 글은 나의 지난 무용담으로 가득한 글이 되었다.

첫 번째 직장이야기, 두 번째 직장이야기, FTP, HTTP, KSC-5061, CP949, ISO-2022-KR, SMTP, POP3,  VC++, VB, Sybase, 멀티스레드, 첫 디버깅, gdb, IETF, RFC, MIME,...

들어도 별 도움도 안 되고, 재미도 없는 이야기 등 등 말이다.


누군가에게 필요한 정보를 알기 쉽게 전달하고자 했던 것은 내 욕심이 아니었을까 라는 후회도 들지만, 이글이 정말 누군가에게 조금이라고 도움이 되었으면 한다.




이전 05화 컴퓨터 데이타
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari