Functional Reactive

갑자기 옛날 생각이 떠올랐습니다. 우리나라에 도로명주소가 도입되었을 때 이것이 편하냐 불편하냐에 대한 많은 논란이 있었습니다. 저는 도로명주소를 무조건 사용하도록 강제하고 더불어서 지번주소는 아예 이 세상과 전산시스템에서 소멸시켜야 한다는 매우 급진적인 입장을 가지고 있었는데, 도로명주소의 사용이 강제되면 아무래도 예상치 못한 주소 때문에 DB 칼럼을 비효율적일 정도로 크게 잡아야 하는 일도, '샵'을 '샾'이라고 써서 저장한 사람들에게 EUC-KR로 인코딩 된 우편 전문이 오류를 일으켜서 편지가 반송되는 일도 없을 거고 언제나 답 안 나오던 주소 입력 UI도 확 바뀔 수 있지 않을까 하는 기대가 있었기 때문입니다.

하지만 많은 사람들이 체계적이지 않은 우리나라의 도로 사정에 체계성을 기반으로 한 도로명 주소가 도입되면 많은 혼란이 있고 실 생활에서 얻는 편리함보다는 불편함이 클 수 있음을 지적했었는데, 당시에 '길'이 가진 위상은 아무래도 '동'이 가진 위치에 비해 많이 부족했고 사람들은 새롭게 부여된 도로명 주소에서 규칙성을 쉽게 찾지 못했던 것입니다. 예를 들어서 도신로라는 이름을 들었을 때 그 이름만으로 그것이 어디에 있는 길인지 유추하는 사람은 아무도 없었기에 저는 '도림동과 신길동을 잇는 길이라서 도신로입니다'라고 설명을 해주고 '참고로 도림동은 신도림동 옆에 있는 동입니다'라고 설명을 해준 뒤 '신도림동은 도림동에서 분리되어 새로운 도림동이라는 뜻으로 그런 이름을 가지게 되었습니다'까지 설명해야 대략적인 위치를 각인시켜줄 수 있었습니다. 무엇이든 설명이 많이 필요하다는 사실은 불편하다는 말이 되니 도로명주소의 도입은 어찌 보면 데이터베이스의 효율성을 얻고 일상생활의 편리함을 잃는 선택이기에 데이터베이스보다 일상생활의 비중이 높았던 많은 사람들이 싫어한 것도 당연한 일이었을지 모르겠습니다.

도로명주소가 도입된지 몇 년이 지나고, 도로명주소 반대파가 대부분 도로명주소가 지배한 세상에 굴복하여 더 이상 논란을 찾아보기 어려워졌을 2019년 가을, 제가 갑자기 5년 전의 도로명주소 논란을 떠올린 이유는, 도신로에서 8300 킬로미터쯤 떨어진 지점에서 어떻게 지도 없이 도로명만 가지고 거리를 가늠하는지에 대해서 저에게 열성적으로 설명해주려는 친절한 무리가 있었기 때문입니다.

물론 논란 당시 도로명주소를 도입해야 한다는 주장을 강하게 펼쳤던 저는 제 주장을 뒷받침하기 위한 근거, 그러니까 도로가 바둑판처럼 잘 짜인 계획도시에서 도로명주소가 얼마나 편리한지를 잘 알고 있었고, 서울은 계획도시가 아니라는 주장에 대해 그럼 도로명주소의 도입을 반대할 것이 아니라 일단 도입하고 나중에 서울에 운석이 떨어지면 그때 도로를 잘 배치하면 되는 것 아니냐, 심시티나 시티즈 좀 해봤다면 당신도 동의할 텐데 왜 그렇게 부정적인지 모르겠다는 입장을 자주 피력했던 전력이 있었기 때문에 굳이 저한테는 도로명 주소의 편리함에 대해 알려줄 필요는 없다고 말하고 싶었지만, 이걸 영어로 말하려니 아찔해지는 기분이 들어서 그냥 잠자코 듣고 있었습니다.

대충 설명은 이랬습니다. 이 방향으로 나있는 길은 Street 이고 그와 직교하면서 그어진 길은 Avenue인데 여기 사무실 옆에 있는 길이 James Street이고 사무실 앞에 있는 길이 2nd Avenue라는 겁니다. 그리고 각 길 사이의 거리는 일정하기 때문에 예를 들어서 5th Avenue와 2nd Avenue 사이에는 얼마의 거리가 있는지 지도를 보지 않고 쉽게 알 수 있고 어느 정도 걸어야 도착할지도 바로 알 수 있다고 설명해줬는데 하필이면 그 미국인들이 피트 단위로 말해줘서 미국 생활 5일 차였던 저에게는 전혀 와 닿지 않았습니다. 그냥 Avenue 사이에는 100미터 정도 떨어져 있으니 5th Avenue와 2nd Avenue 사이는 300미터 거리가 떨어져 있다고 설명해줬으면 바로 알았을 텐데 말이죠.

그렇게 신나게 계획 도시에서 도로명 주소가 얼마나 편리한지에 대해 설명해주던 사람들은 개념을 이해하면 문제를 풀어야 한다고 굳게 믿는 이과 출신들이었는지, 곧바로 너희의 첫 퇴근길이 얼마나 걸릴지 맞출 수 있다고 설명하며 숙소가 어느 Street에 있냐고 물어봤습니다. 어... 잘 모르겠는데 어제 도착할 때 보니까 James Street 였던 거 같았는데?라고 대답하자 사람들이 좋아하며 사무실과 같은 Street에 있으니 계산이 완전 편하다며 몇 번 Avenue에 위치했냐고 물어보는 겁니다. 이미 도착하기도 전에 숙소로 많은 택배를 보내 놨던 저는 숙소 주소를 외우고 있었고 그래서 숙소가 Terry Avenue에 위치했다고 알려줬습니다. 그리고 5 - 2 = 3을 쉽게 계산했던 그들이 Terry - 2 = ??? 에서 형변환 오류를 일으키며 잠시 마비되었다가 구글맵을 켜고 Terry Ave를 검색하는 것을 보면서 저는 도로명 주소에 대찬성하고 반대파와 싸웠던 과거를 살짝 반성하게 되었습니다. 어차피 세상에는 많은 예외가 있고 대부분 구글이 해결해줄 텐데 주소만 가지고 위치를 파악하고 거리를 측정하는 것이 뭐 그렇게 싸우면서까지 지켜야 할 가치였을까요.

구글이 알려준 사실이었지만 Terry Avenue는 9th Avenue 다음에 위치한, 그러니까 10th Avenue에 해당하는 길이었고 따라서 숙소와 사무실 사이의 거리는 800미터 정도가 되었습니다. 제가 한국에서 매일 퇴근할때 도신로를 1.6km 정도 걸어서 퇴근하고 20분 정도 걸렸으니까 대충 퇴근에도 10분 정도가 걸릴 것이라는 사실도 알 수 있었습니다. 그렇기 때문에 그 날 퇴근하면서 800미터를 가는데 20분이 넘게 걸렸다는 사실에 살짝 당황할 수밖에 없었습니다.

물론 낯선 나라에서 잔뜩 긴장했던 저는 가다가 만난 노숙자들이 'Anything Helps'라고 적힌 박스를 들고 있는 것이 '도와주세요'가 아니라 '뭐라도 도와주지 않으면 죽이겠다'로 보이거나 저쪽에서 평범하게 걸어오는 사람이 다 트레버처럼 보이고 평범한 교회가 에덴의 문처럼 보이는 뇌내 이벤트들이 있기는 했지만 실제로 어떤 이벤트가 있거나 하지는 않았습니다. 다만 퇴근이 예상보다 오래 걸렸던 건 순전히 사무실의 이과생들이 다들 2D를 가까이하고 3D를 멀리하느라 그 800미터가 실제로 100미터 높이를 올라가야 하는 매우 가파른 경사로였다는 사실을 몰랐기 때문입니다.

숨이 턱까지 차오른 상태에서 숙소에 들어가면서 내가 지금 힘든 것은 운동이 부족해서인가, 시차적응을 못해서인가, 오랜 비행의 후유증인가, 점심때 먹었던 맥주 탓인가에 대해서 고민하다가 그보다는 아까 들었던 '너네 숙소 바로 앞에 있는 병원이 이 지역에서 외상치료 거점병원이니까 너네 총 맞아도 살 확률이 높을 거야'라는 말이 몇 퍼센트 정도 농담이었을 것일까에 대해 고민하며 앞으로 어떻게 행동해야 무사히 살아서 한국행 비행기를 탈 수 있을까에 대해서 계산해보는 것이 좋을 것 같다는 결론을 내렸습니다.

물론 계산은 실패했지만, 다행히도 무사히 살아남아서 그 언덕을 50번쯤 오르내렸을때 저는 출근에 걸리는 시간을 15분, 퇴근에 걸리는 시간을 10분까지 단축시켜서 결국 첫날 계산했던 그 시간을 정답으로 만들어낼 수 있었습니다. 여기서 주목할 점은 순수 고도로만 100미터를 내려가는 내리막 길이었던 출근길은 15분이 걸렸고, 100미터를 올라가는 오르막 길이 오히려 더 짧은 10분만 걸렸다는 사실인데 이것은 어떤 물리 법칙보다는 인간적인 관점에서 해석해야 했습니다. 출근길과 퇴근길은 컨텍스트가 달랐던 것입니다. 저희 직업에서 컨텍스트라는 용어는 주로 어떤 일을 수행할 때 그 수행의 배경이 되는 특정한 상황을 의미하는데, 아무리 내리막길이라고 해도 굳이 빨리 갈 필요가 없었던 출근길은 매우 천천히 걸어가는 것이 보통이었고 가파른 오르막길이라도 최대한 빨리 집에 가는 것이 이득이었던 퇴근길은 거의 뛰듯이 올라갔던 것입니다.

누군가는 이 상황을 보고 '그래. 사람 일은 다 마음먹기에 달려있어'라고 총평할지 모르겠습니다만 저는 기본적으로 마음먹기에 달렸다는 그 말을 별로 좋아하지는 않습니다. 천천히 걸어가도 힘든 언덕길을 단숨에 뛰어올라가게 만드는 것이 긍정적인 마음가짐의 결과라고 해석해주는 것은 감사한 일이지만, 보통 그놈의 마음먹기 타령은 힘든 상황일 때 훨씬 많이 들리는 편이고, 내가 힘든 것은 그 상황을 만든 나쁜 것들의 잘못이 아니라 힘든 상황을 극복하지 못한 내 잘못이라고 탓하는 것 같아서 별로 위로가 되지 않았기 때문입니다. 

다른 곳도 비슷할 것이라고 생각하지만, 저희 회사는 처한 상황이 바뀌면 마음가짐도 따라서 바뀌어야 한다고 믿는 분들이 많았는지 입사를 하거나 진급을 하면 다양한 종류의 교육 프로그램을 이수해야 했습니다. 사실 그러한 투자에 미안하게도 저는 받았던 교육내용을 대부분 까먹었지만 유일하게 잊어버리지 않고 기억하는 내용이 딱 하나 있었는데, 사과를 할 때는 조건을 붙이면 안 된다는 말이었습니다. '미안합니다'라는 말과 '그렇게 느꼈다면 미안합니다'라는 말은 비슷한 말이 아니라 완전히 다른 말, 그러니까 전자는 사과이지만 후자는 사과가 아니라는 말이었습니다.

그 강의를 들었을때는 왜 그런지는 잘은 모르겠지만 무척이나 그럴듯하다고 생각해서 기억해두고 있었는데, 그 이후로 인생의 경험이 쌓이면서 왜 사과를 할 때 조건을 붙이면 안 되는지에 대해서 정확히 알 것 같다는 생각을 했습니다. 미안합니다 라는 말 앞에 붙어야 하는 말은 '내가 어떻게 어떻게 해서'가 붙어야지 '네가 어떻게 어떻게 느꼈다면'이 붙으면 안 되는 겁니다. 앞의 것은 사과의 주체가 사과를 하는 사람, 그러니까 보편적으로 잘못을 한 사람이 됩니다. 하지만 뒤의 표현은 사과의 주체가 오히려 사과를 받는 사람, 그러니까 보통 피해를 받은 사람이 됩니다. 무슨 말이냐면 '네가 만약 그렇게 느끼지 않았다면 나도 미안하지 않다'라는 표현을 담고 있다는 것입니다. 물론 사과를 하는 사람은 본인은 그런 뜻이 아니었다고 주장할지도 모르겠습니다만.

그리고 진짜 재미있는 것은, 심지어 '그렇게 느꼈다면 미안하다'라는 표현에서 사과를 하는 사람이 미안한가 미안하지 않은가는 그 말을 하는 시점에 결정되지 않는다는 것입니다. 이것은 일종의 함수 같아서 f(너의_느낌) -> 미안함_여부와 같은 계산식을 상대방에게 던지는 것이지 그 함수의 계산 결과, 그러니까 미안한지 미안하지 않은지 여부를 주는 것이 아닌데, 이는 사과를 던지는 사람 입장에서야 던지는 것만으로 상황을 정리할 수 있고, 사과를 듣는 사람은 자신의 마음가짐에 따라서 필요할 때 '내가 지금 기분이 거지 같은 걸 보니 상대방은 미안해하는구나'라고 계산해야 하기 때문에 사과를 하는 사람의 엔트로피가 줄어들고 받는 사람의 엔트로피가 증가하는 효과가 있습니다. 가해자가 이득을 보고 피해자가 손해를 보는 이러한 상황은 인간관계에서는 매우 끔찍하지만 이산 세계에서는 효율적이기에 최근의 프로그래밍은 무언가의 계산을 요청받으면 그 시점에 바로 모든 리소스를 동원해서 계산한 뒤 그 결과를 반환해주는 고전적인 방식에서, 결과를 도출해내기 위한 계산식, 그러니까 함수를 반환해주고 필요한 시점에 계산을 수행하고 결과를 가져가는 함수 반응형 프로그래밍으로 넘어가는 트렌드가 자리 잡고 있습니다.

프로그래밍 언어와 프레임워크에 따라 용어의 차이가 있기는 하지만 Reactor 프레임워크에서는 함수를 전달해주는 쪽을 Publisher, 그 결과가 필요한 쪽은 Subscriber라고 부르고 이러한 상황을 'Nothing happens until you subscribe'라는 한 문장으로 정리했는데, 이를 다시 조건부 사과의 문제점에 대입하자면 사과를 하는 사람은 사과가 필요해? 그럼 이거나 받아라! 하고 Publisher<Apologize>를 던진 것이고 함수형 프로그래밍을 처음 하는 사람들이 정말 많이 착각하는 지점이지만, 저기에는 사과가 전혀 담겨있지 않습니다. 즉 그 시점에는 사과는커녕 아무것도 일어나지 않은 것입니다. 다만 내가 상대방이 던진 '그렇게 느꼈다면 미안해'라는 말에 '응 그렇게 느꼈어'라고 요청을 해야, 그러니까 subscribe를 해야 비로소 여차 저차 해서 미안하다는 사과가 전달되는 것입니다. 문제는 그 모든 과정이 사과를 받는 사람의 마음속에서만 진행되어서 그래 미안하구나 라는 결과가 나와도 전혀 나아지는 것이 없다는 것이죠.

Reactor 프레임워크보다 조금 더 보편적으로 쓰이는 Rx 프레임워크는 Publisher를 Observable, Subscriber를 Observer라는 용어로 표현합니다. 그러니까 관측 가능한 것과 관측자로 구분하는 것인데 관측을 하기 전까지는 아무것도 일어나지 않고, 관측을 해야만 무언가가 결정되는 상황은 우리가 거의 이해하지 못하는 양자역학에 대한 유일한 이해를 떠올리게 만들어줍니다. 그렇다면 여기에서 한 가지 논리적이고 철학적인 의문이 생겨납니다. 그 사과와 미안함은 결국 누가 만들어낸 것일까요? 잘못을 한 사람일까요, 아니면 피해를 받은 사람일까요? 피해자가 미안함을 만들어내야 하는 이 역설에 우리는 어떻게 대응해야 할까요?

미시 세계는커녕 거시 세계에 대한 이해도 부족한 저는 '너는 남은 인생을 어떻게 살래?'라는 질문에 어떤 심오하고 멋진 대답을 하기보다는 '음...저는 오늘 저녁에 뭘 할지도 잘 모르는데요'라고 대답할 수밖에 없는 사람이기에 이런 인생에 관련된 질문에는 별로 할 말이 없습니다. 인간-컴퓨터 상호작용은 배웠지만, 인간-인간 상호작용은 제 전공분야가 아니기도 하고요. 다만 그저 경험에 기반한 저의 미천한 의견으로는, 함수형 프로그래밍이 사랑받는 가장 큰 이유는 프로그래밍을 하는 우리는 충분히 불변성을 가진 순수 함수를 사용하여 결과가 컨텍스트에 영향을 받지 않고 매개변수에만 영향을 받도록 할 수 있고, 이는 호출 자체가 상황에 영향을 줘서 생기는 부작용들을 깨끗하게 억제할 수 있기 때문인데, 프로그램의 바깥 세계에 위치한 우리는 컨텍스트에서 자유로울 수도 없고 영혼의 불변성과 순수함을 보장할 수도 없기에, 함수형으로 던져진 수많은 명제들에 대한 답을 스스로를 소모하는 부작용 없이 찾아내기 어렵다는 것이고, 그걸 알면서도 굳이 답을 찾기 위해 영혼을 이중 슬릿에 통과시키고 마음을 관측하는 일은 엔트로피를 증가시키고 인생을 복잡하게 만들지도 모르니 차라리 그냥 다 무시하고 아무 일도 일어나지 않도록 한 뒤, 그 시간에 스포티파이에서 Daily Mix 1이나 듣는 쪽이 훨씬 기분에도 좋고 인생에 도움되는 일이 아닐까 하는 의견을 조심스럽게 드리고 싶습니다.