과학이나 공학이나

새벽 4시쯤에 가만히 누워서 감각이 없어진 듯한 손바닥의 어제(魚際) 부분을 만져보다가 문득 그런 생각이 들었습니다. 경미한 수준의 화상과 경미한 수준의 동상은 쉽게 구분하기 어렵겠구나. 저는 두 달 전쯤에 전기 주전자의 공격을 받고 같은 부위에 약한 화상을 입고 약하게 고통받았던 기억이 있었는데, 그때와 비슷한 통증이 느껴졌거든요. 그렇다면 앞으로 일주일 정도는 미약한 통증이 함께하겠구나라는 생각이 들며 이 모든 것이 어디에서부터 잘못된 것인지에 대해서 고민을 했습니다.

 

오후 4시는 뭔가를 새로 시작하기에는 늦은 시간이고, 그렇다고 뭔가를 마무리하기에는 또 너무 이르기에 참 애매한 시간입니다. 특히나 요일이 금요일이라면 더더욱 그렇습니다. 금요일 오후 4시쯤에 대충 하던 일이 정리가 되면 새로운 일을 시작할까 말까에 대해서 심각하게 고민할 수밖에 없는데, 만약 새로 시작한 일이 생각보다 어려워서 다 못 끝내고 퇴근하는 불상사가 벌어지면 주말 내내 찝찝한 기분을 달고 놀아야 하는 문제가 있기 때문입니다.

 

자율출퇴근제는 이럴 때 시간을 헷징 할 수 있는 좋은 제도이지만, 일찍 퇴근해서 얻은 시간을 투자할 곳이 마땅치 않았던 저는 그냥 남은 결함 중 하나를 할당받아서 처리해야겠다고 마음먹었습니다. 그래서 남은 결함 중 2시간 정도면 끝낼 수 있는 쉬운 결함을 찾아봤지만, 그런 착한 결함들은 모두 입도선매가 끝난 상태였고 남아있는 결함들은 하나같이 다 통일미처럼 애매한 결함들이었습니다.

 

그래서 저는 마음을 바꿔서 그중에서도 가장 애매한 결함을 하나 잡아서 저에게 할당했습니다. 아주아주 가끔 발생하며, 어떤 시나리오를 거쳐서 재연할 수 있는지 파악이 안 된, 그래서 결함이라고 취급하기도 애매한 그런 결함이었습니다. 하지만 저는 애매한 타이밍엔 애매한 결함이 필요하겠다는 생각을 했는데, 이 결함이라면 두 시간 정도 고민해보고 안 풀리면 그냥 집에 가도 별로 찝찝하지 않고 주말에도 마음 편히 쉴 수 있겠다는 계산이 섰기 때문입니다.

 

결함의 내용은 간단했습니다. 아주 간헐적으로 동그란 버튼이 네모로 표시되는 문제가 발생함. 원인도 모르겠고, 발생 시나리오도 없음. 전략적으로 할당받은 결함이었지만, 막상 내용을 보고 있으려니 속에서 뭔가 불만스러운 기운이 올라오는 것을 막을 수 없었습니다. 개발자들이 재연 시나리오가 명확하지 않은 결함을 결함으로 취급하지 않는 이유는 재연 시나리오가 없으면 원인을 파악하기도 너무 어렵고, 설령 뭔가 추정해서 고쳤다고 해도 그게 제대로 고쳐졌는지 확인할 수 없기 때문입니다. 뭔가 고치려는 시도를 하기에는 정보가 너무 부족했기에 일단 이게 얼마나 간헐적으로 나오는 문제인지 파악하기 위해서 마우스를 이리저리 눌러봤습니다.

 

다양한 방식으로 버튼을 눌러보면서 동그라미가 네모가 되기를 기대했지만, 버튼은 언제나 완전한 원형을 유지했습니다. 새로고침도 해보고, 버튼을 빠른 속도로 눌러보기도 하고, 가운데 버튼으로도 눌러보고, 오른쪽 버튼으로도 눌러보고, 버튼 위에서 마우스 커서를 휘두르기도 하면서 증상이 재현되기를 기대했지만 증상은 전혀 나타나지 않았습니다. 그러다 문득 이렇게 마구잡이로 조작하면서 어쩌다 증상이 나타난다고 해도 문제가 해결되지는 않을 것 같다는 생각이 들었습니다.

 

결함을 수정하는 작업은 보통 그 원인을 찾아서 문제를 해결하는 방식으로 일종의 면역요법에 해당합니다. 하지만 마구잡이로 휘두른 마우스에 맞은 버튼이 어쩌다 증상을 토해낸다고 해도 그것은 결함의 원인이 아닌 결과이기 때문에, 그 결과를 분석해서 고치는 행동은 일종의 대증치료에 가까울 수밖에 없습니다. 별로 논리적이지도, 과학적이지도 않은 시도를 반복하고 있다는 생각이 들었고, 이렇게 근본 없는 시도를 반복하다가 결국 아무것도 해결하지 못하고 집에 가면 매우 불행할 것 같다는 생각이 들었습니다.

 

그래서 저는 마우스에서 손을 떼고 과학적인 방식으로 문제를 해결해보고자 했습니다. 간헐적으로 나타난다는 사실보다는 '어떤 경우에 버튼이 네모로 변하는가?'에 대한 고민을 해보고 그 원인을 찾아서 가설을 세운 뒤 확실한 재연 시나리오를 만들어서 증명해보고자 마음을 바꾼 것입니다. 그래서 소스를 찾아보니 버튼은 평범한 사각형이었고, 대신 모서리의 곡률을 픽셀 단위로 지정하도록 되어 있었습니다. 이는 이 버튼이 상황에 따라서 완전한 원형이거나 가로가 길고 모서리가 둥근 사각형으로 왔다 갔다 할 수 있었기 때문이었는데, 성능 측면에서나 코드 측면에서나 애니메이션 측면에서나 모두 유리한 점이 많은 설계였습니다. 버튼은 기본적으로 가로 세로 48픽셀의 정사각형에 각 모서리마다 24픽셀의 곡률을 가지고 있었기에 이 상황에서는 원형으로 보이는 게 정상이었고, 실제로 버튼은 동그랗게 잘 보였습니다.

 

증상이 발생했을 때, 캡처된 그림을 보면 버튼이 사각형으로 표시될 때는 곡률이 전혀 없는, 완전한 정사각형으로 그려지는 것을 알 수 있었습니다. 때문에 증상이 발생했을 때는 곡률이 24픽셀이 아닌 0픽셀로 정의되었다는 추측을 할 수 있었습니다. 이는 코드에서 24픽셀로 지정이 제대로 되었으나, 무슨 연유에선가 그려질 때 그 코드가 적용되지 않았을 가능성, 혹은 코드에서 24픽셀로 지정이 되기 전에 화면이 그려졌을 가능성 등을 내포하고 있었습니다.

 

잠시 인터넷을 뒤져서 border-radius 속성이 지정되었지만 적용되지 않는 케이스가 있는지에 대해서 찾아본 저는, 딱히 그런 케이스가 흔한 것은 아니라는 결론을 내리고는 두 번째 가능성, 즉 코드에서 곡률이 24픽셀로 지정되지 않을 가능성에 대해서 생각해보기로 했습니다. 코드를 가만히 보니 곡률은 24픽셀로 고정되어 있는 것은 아니었고, 화면이 그려질 때 높이의 절반으로 계산해서 지정되도록 짜여 있었는데, 이 타이밍은 명백히 화면이 그려지기 이전 타이밍이었기에 계산되기 전에 화면이 그려질 가능성은 없었고, 곡률은 계산되는 값이지만 그 곡률 계산을 위한 높이는 48픽셀로 완전히 정적으로 정의되어 있었기에 24픽셀이 아닌 다른 값이 들어갈 가능성도 없었습니다.

 

높이가 고정이지만 곡률이 계산된 값으로 지정된 이유는 아마 나중에 높이가 변경되었을 경우를 대비한 설계였을 수도 있고, 지정된 높이와 화면에 실제로 그려진 높이가 다른 케이스에 대응하기 위한 설계였을 수도 있는데 어느 쪽이든 모두 일리 있는 구현이었습니다. 한번 곡률이 정해져서 그려지고 나면 다시 계산되는 일도 없었기에, 코드는 굉장히 견고해 보였습니다. 적어도 제가 이미 그려진 버튼을 이리저리 괴롭히면서 네모나게 변하는 케이스를 찾아보려고 한 일이 헛수고였다는 사실은 분명했습니다.

 

논리적으로 생각해보면, 곡률이 높이의 절반으로 계산된 값인데 그 결과가 0이 되었다면 높이가 0이 되었다는 가정을 해보는 게 좋을 것 같았습니다. 하지만 정적으로 정의된 48픽셀의 높이는 이 애플리케이션이 실행되기 전에도 이미 48이었기에 높이가 0이 되는 케이스는 논리적으로 전혀 존재할 수 없는 것처럼 느껴졌습니다. 여기까지는 추론을 잘했지만 뭔가 막히는 기분이 들었습니다.

 

그러다 문득 그런 생각이 들었습니다. 버튼의 높이는 48픽셀로 고정이지만, 버튼 자체가 존재하지 않는다면? 버튼이 화면에 그려지지 않는 케이스가 있다면 그 시점에 버튼의 높이는 뭘까? 가상의 48픽셀일까, 아니면 그려진 적이 없었기에 0픽셀일까? 그런데 버튼이 그려지지 않는 케이스가 있을까? 버튼이 그려지지 않는 케이스를 고민해보니 쉽게 답이 나왔습니다. 반응형 레이아웃에서는 화면의 해상도나 브라우저의 크기에 따라서 화면이 좁을 때는 덜 중요한 버튼이나 객체들은 가려지도록 만드는 것이 일반적입니다. 혹시나 하는 마음에 브라우저의 가로길이를 줄였더니 역시나 동그란 버튼이 사라지는 것을 알 수 있었습니다.

 

버튼이 사라지는 순간 갑자기 심장이 두근거리는 것을 느낄 수 있었습니다. 만약 이 상태에서 새로 고침을 한다면? 버튼이 다시 화면에 그려져야 할 때 레이아웃에 의해서 버튼이 그려지지 않아야 한다면? 그렇다면 이론적으로 버튼은 존재하지 않기에 높이는 0이 될 수 있고, 이에 따라서 곡률도 0이 될 수 있었습니다. 이 상태에서 화면을 늘려서 버튼을 보이게 한다면 이미 곡률이 0으로 계산된 뒤에 버튼이 그려지기 때문에 원형이 아닌 사각형의 버튼이 나타나는 것이 이론적으로는 가능했습니다.

 

여기까지 사고 실험을 마친 저는, 설레는 마음으로 새로 고침 버튼을 누르고, 떨리는 손으로 브라우저의 크기를 다시 키웠습니다. 그리고 마침내 사각형 버튼이 나타나는 것을 확인한 순간 마우스 패드를 집어던지며 유레카를 외치고 싶은 기분이 되었습니다. 원인이 파악된 결함은 태풍 앞의 민들레 홀씨만큼 무력해졌고, 저는 6번의 타이핑으로 결함을 해결할 수 있었습니다. 그리고 매우 좋은 기분으로 퇴근할 수 있었습니다. 아, 이건 완전히 과학적인 해결 과정이었다.

 

해결 못 할 것이라 생각했던 결함을 해결한 것도 물론 기분 좋은 일이었지만, 그 과정이 매우 마음에 들었기에 저는 퇴근하고 나서도 한동안 에너지 레벨이 무척 높은 상태를 유지할 수 있었습니다. 그래서 그 높은 에너지를 활용하기 위해 대청소를 해야겠다는 마음을 먹었습니다. 지난주에 재택근무를 하면서 청소를 꽤 많이 했는데 뭔가 끝까지 하지 않은 듯한 기분이 계속 들었거든요. 그래서 시작한 대청소는 로봇청소기의 물통을 채우는 것에서부터 컴퓨터의 바탕화면과 오래된 파일을 정리하는 것까지 정말 다양한 차원을 고려하며 새벽 2시까지 이어졌습니다.

 

얼추 청소가 마무리되고 마지막으로 화장실의 거울을 닦다가 문득 해결하지 못한 도전과제가 하나 남았다는 생각이 들었습니다. 이 집에 이사 올 때부터 샤워기 수압이 조금 약한 게 항상 마음에 들지 않았는데, 이번 기회에 한 번 고쳐봐야겠다는 생각이 들었던 것입니다. 샤워기 수리는 평상 한 번도 해본 적이 없었지만, 그래도 나름 (납땜 한번 해본 적 없지만) 공대 출신이고, (소프트웨어 쪽이기는 하지만) 엔지니어인데, 그리고 나도 움직여야 할게 안 움직이면 WD-40, 움직이지 말아야 할게 움직이면 덕트 테이프 정도의 공식은 외우고 있는데 고칠 수 있지 않을까라는 생각을 했습니다. 무엇보다도 오늘 오후에 해결이 불가능해 보일 것 같았던 사각형 버튼 문제를 해결했는데 그에 비하면 샤워기 문제는 아무것도 아닌 것처럼 느껴졌습니다.

 

암묵적인 금기를 어기고 인터넷을 뒤져서 증상을 찾아보니, 샤워기로 들어가는 냉수와 온수관에 있는 나사를 돌려서 조금 풀어주면 물이 잘 나온다는 블로그 포스팅을 찾을 수 있었습니다. 글이 뭔가 대충 쓰여있어서 뭔가 미덥지는 않았지만 시도해볼 만한 가치는 있겠다는 생각을 했습니다. 애초에 샤워기의 구조를 열심히 살펴봐도 제가 뭔가 조작할만한 부품은 두 개의 수도관 사이에 있는 밸브 마개처럼 생긴 나사가 전부였던 것입니다.

 

다만 두 개의 밸브가 블로그에서 봤던 사진과는 매우 다른 구조를 하고 있는 것이 마음에 조금 걸렸습니다. 사진에는 밸브가 완전히 노출되어 있기도 했고, 돌리기도 편해 보였는데 저희 집 샤워기로 들어가는 수도관의 밸브는 드라이버를 사용하기도 어려울 정도로 애매한 위치에 있었던 것입니다. 그래서 잠시 이 수도가 어디에서 들어와서 어디로 가는 것인가, 내가 이 밸브를 어느 방향으로 돌려야 원하는 목표에 도달할 수 있을 것인가에 대해서 계산해보다가 이내 답답한 기분이 들어서 생각을 관뒀습니다.

 

저는 그냥 샤워기에서 물이 좀 더 강하게 나왔으면 하는 목표를 가지고 있었고, 이를 위해서 두 개의 밸브를 시계방향 혹은 반 시계방향으로 돌려보는 총 4가지의 시도를 해볼 수 있었습니다. 그럼 그냥 샤워기를 틀어놓고 1번 밸브를 시계방향으로 돌려보고, 변화가 없으면 반시계 방향으로 돌려보고, 또 변화가 없으면 2번 밸브를 돌려보고 그러면 되는 게 아닌가라는 생각이 들었습니다. 하나하나 따지면서 계산할 시간에 그냥 돌려보면 되는 게 아닌가라는 생각이요.

 

드라이버가 들어갈 구석은 없어 보였지만 어떻게든 동전 같은 걸로 돌려보면 돌릴 수 있겠다는 판단이 선 저는, 샤워기를 최대로 틀어놓고는 복잡한 구조의 수도관에 동전을 집어넣어서 밸브의 나사홈에 끼우고는 잠시 고민하다가 아무래도 나사가 풀리는 방향이 맞겠지 싶은 생각으로 밸브를 반시계 방향으로 돌렸습니다. 하지만 자세의 불편함과 물리적인 한계 때문에 밸브는 한 번에 고작 10도 남짓 돌릴 수 있었습니다. 당연히 샤워기의 수압에는 변화가 없었고, 약간 오기가 생긴 저는 매우 낑낑거리면서 장시간에 걸쳐서 밸브를 조금씩 반시계 방향으로 돌렸습니다.

 

어느 정도 유의미하게 밸브를 풀었을 때, 샤워기 수압이 좀 강해졌나 확인해봤는데 뭔가 살짝 좋아진 것 같기는 했지만 그냥 기분 탓인 거 같기도 했고 유의미한 결과는 아니라는 생각이 들었습니다. 어쨌든 물이 안 나오는 것은 아니니까, 그럼 이 밸브를 조금 더 풀고 나머지 밸브도 마저 풀면 수압이 강해지는 게 아닐까라는 생각이 들어서 다시 밸브를 풀기 시작했을 때, 갑자기 밸브에서 물이 졸졸졸 새어 나오기 시작했습니다.

 

순간 당황한 저는 샤워기를 잠갔지만, 물은 헛된 노력을 비웃듯이 계속 새어 나왔습니다. 순간 아 이 밸브는 상수도에서 샤워기로 가는 중간 경로니까 샤워기를 잠그든 말든 별 상관이 없겠구나라는 생각에 밸브를 자세히 봤더니 어느 정도 풀린 밸브의 나사산에 있던 고무패킹이 살짝 삐져나오면서 그 사이로 물이 새는 것을 볼 수 있었습니다. 아 내가 너무 많이 풀었구나라는 생각에 다시 밸브를 시계방향으로 돌리면서 잠그려고 했는데 어느 정도 돌렸는데도 물이 계속 새는 겁니다.

 

이게 무슨 일이지?라는 생각에 다시 자세히 들여다봤더니 한번 밖으로 삐져나온 고무패킹이 제대로 체결되지 않고 튀어나온 채로 밸브를 헛돌게 만들고 있었습니다. 조금 더 강하게 밸브를 조이면 알아서 자기 자리를 찾아 들어가지 않을까라는 생각에 밸브를 시계방향으로 더 강하게 돌려봤는데 오히려 고무패킹이 더 튀어나오고 물이 더 많이 새기 시작했을 뿐 상황이 나아지지 않았습니다.

 

그래서 아무래도 이건 밸브를 더 풀어서 고무패킹이 자기 자리를 찾을 공간을 마련한 뒤, 자기 자리를 찾으면 다시 채우는 게 맞겠다는 생각을 했습니다. 차가운 물이 새어 나오는 밸브를 계속 이리저리 돌리느라 손이 얼어붙는 것 같았지만 물이 새는 채로 놔둘 수도 없었기에 - 주말 새벽이라 사람을 부를 수도 없었고 - 다시 열심히 밸브를 반시계 방향으로 돌리며 풀었습니다.

 

그렇게 다시 인고의 시간을 거쳐서 밸브를 풀던 중 어느 순간, 갑자기 뭔가 터지는 듯한 소리와 함께 물이 졸졸졸에서 콸콸콸로 바뀌면서 밸브 마개가 저를 향해 튀어나오려는 압도적인 힘을 느낄 수 있었습니다. 순간적으로 밸브를 눌러서 튀어나오는 것은 간신히 막았지만, 완전히 개방된 수도의 수압은 엄청나게 강했고 밸브 마개가 탈출하려는 힘은 한 손으로 누르기 벅차서 양손을 써야 할 정도였습니다. 순간 머릿속에서 이걸 놓치면 어떻게 될까에 대해서 시뮬레이션을 돌려봤는데 데이터가 부족해서 결과를 예측할 수가 없었습니다. 그래서 어떻게든 밸브 마개를 다시 누르면서 시계 방향으로 마개를 돌려서 콸콸콸을 졸졸졸로 바꾸려고 노력했습니다.

 

10분이 넘는 사투 끝에, 강한 수압으로 분출되는 수도관에 밸브 마개를 다시 채우려는 것은 자석의 같은 극을 붙이려는 시도와 비슷하다는 데이터를 수집하고는 결국 인생을 포기하는 듯한 심정으로 밸브 마개를 뺐습니다. 그리고 온수가 전혀 섞이지 않은 차가운 수돗물이 베수비오 화산처럼 맹렬한 기세로 분출되며 저를 덮쳤습니다.

 

순간 너무 비현실적인 상황에 물을 피할 생각도 하지 못했고, 머릿속에는 주마등처럼 많은 생각들이 지나갔습니다. 아니 이렇게 수압이 강한데 샤워기 수압은 왜 그 모양이었을까, 역시 이모티콘이 가득한 블로그 포스팅은 믿는 게 아니구나, 그래도 배수구 청소를 미리 해놔서 물은 잘 빠지겠네. 다행이다. 이대로 주말 내내 놔두면 수도요금 많이 나오겠지. 그 요금을 주말 새벽에 전문가 부르는 비용과 비교했을 때 어느 쪽이 경제적일까. 주말 야간 근무 할증이 몇 배였는지 계산하다가 잠시 뒤 이성을 찾은 저는 일단 비켜서 상황을 정리해야겠다는 생각을 했습니다.

 

본인의 임무를 다하지 못하고 빠져버린 밸브 마개를 들고 빅토리아 폭포처럼 쏟아지는 수도관을 쳐다보고 있으려니, 어릴 때 가지고 놀던 장난감이 부서졌을 때처럼, 누워서 스마트폰을 보다가 떨어뜨려서 안경에 금이 갔을 때처럼, 잘못된 코드가 릴리즈 되어 초당 1200건의 속도로 데이터가 삭제되고 있다는 사실을 알게 되었을 때처럼, 뭔가 비가역적이고 돌이킬 수 없는 실수를 했다는 기분이 들었습니다. 그러니까 망했다는 생각이 들었던 것입니다. 하지만 부서진 장난감은 고칠 수 있었고, 금이 간 안경은 렌즈를 다시 연마할 수 있었고, 삭제된 데이터는 로그를 기반으로 되살릴 수 있었던 것처럼, 멍하게 서있는 것보다는 뭐라도 시도를 해야 상황에 변화를 줄 수 있지 않을까라는 생각을 했습니다. 설령 그것이 상황을 악화시키는 방향이라고 해도 가만히 있는 것보다는 의미 있지 않을까 싶어서요.

 

그래서 저는 집 밖으로 나가서 수도계량기가 어디 있는지 찾아봤습니다. 계량기가 생각했던 위치에 있지 않아서 잠시 당황하며 L3버튼을 누르고 싶다는 생각을 하기는 했지만, 그래도 간신히 정신을 가다듬고 옆 집 현관문 근처에서 저희집 계량기를 찾을 수 있었습니다. 이 계량기를 열어서 집으로 들어가는 수도를 일단 잠그면 저 재난을 잠시 일시정지 시킬 수 있지 않을까 생각을 했습니다. 그런 희망으로 판도라의 상자를 열듯이 계량기함을 열어보니 기대했던 계량기와 수도 밸브는 보이지 않고 맙소사 스티로폼밖에 보이지 않았습니다. 잠시 당황한 저는 아 동파 방지를 위해서 이렇게 했나 보다 하고 스티로폼을 꺼내보려고 시도했으니 스티로폼이 계량기함 입구보다 훨씬 커서 도저히 꺼낼 수가 없었습니다. 그래서 잠시 구조를 살펴보고는, 계량기함의 나사를 다 풀고 분해하지 않으면 이 스티로폼을 꺼내지 못하겠다는 생각이 들어서, 집에 들어가서 드라이버를 들고 나왔습니다.

 

바람을 동반하지 않은 공동주택 복도의 영하 14도 추위는 춥기는 해도 무섭게 춥다는 느낌은 없었지만, 온몸이 젖은 상태에서는 죽도록 춥다는게 뭔지 알게 해줬습니다. 그래서 최대한 빠르게 계량기함의 나사를 다 풀고, 스티로폼 덩어리를 조심스럽게 적출한 저는 무섭게 올라가는 계량기의 숫자를 잠시 외면하려고 노력하면서 계량기 바로 옆에 위치한 평범한 수도꼭지를 보고 살짝 고민했습니다. 이 수도꼭지를 어느 방향으로 돌려야 집으로 들어오는 수도를 원천 차단할 수 있을까?

 

잠시 고민하다가 너무 추워서 에라 모르겠다는 심정이 된 저는 무의식적으로 수도꼭지를 반시계 방향으로 돌렸고, 잠시 상황을 지켜봤습니다. 그리고 잠시 뒤 살짝살짝 들리던 물 쏟아지는 소리가 갑자기 우르르쾅쾅 하며 현관문을 넘어서까지 들릴 정도로, 그러니까 누가 지나가다가 이 소리를 들으면 무조건 119에 신고하겠구나라는 생각이 들 정도로 강해지는 것을 듣고서는 아, 반시계 방향이 상황을 악화시키는 방향이구나. 그렇다면 시계방향이 상황을 개선시키는 방향이렷다!라는 판단을 하고는 황급히 수도꼭지를 시계방향으로 끝까지 돌렸습니다.

 

짧은 시간이 지난 뒤, 물소리가 줄어들다가 완전히 멈추는 것을 들은 저는 집안으로 뛰어들어가서 모든 수도가 차단된 것을 확인했습니다. 그리고는 보기만 해도 정신이 나갈 것 같은 밸브 마개를 다시 들고는 이번에는 신중하게 고무패킹이 자리를 찾아가도록 유도하면서 밸브를 완전히 잠갔습니다. 그리고는 다시 계량기로 달려가서 수도를 조심스럽게 개방하고, 다시 집으로 들어와서 물이 나와야 할 곳에서는 잘 나오고 나오지 말아야 할 곳에서는 나오지 않음을 확인하고는 아주 살짝 나아진 기분으로 계량기함을 다시 조립했습니다.

 

그리고는 화장실에서 수도를 조금 더 지켜보며 갑자기 밸브가 튀어나오며 물이 콸콸콸 쏟아져내리거나 하는 기미가 보이지는 않는지 체크해보고, 아무래도 잘 고쳐진 것 같다는 판단을 내린 저는 그제야 몸을 대충 닦고 옷을 번개같이 갈아입고는 침대를 향해 맹렬히 뛰어들 수 있었습니다.

 

온수매트를 최대 온도로 올려놓고 이불속에서 오들오들 떨던 저는 거의 한 시간이 지나서야 간신히 진정을 찾을 수 있었습니다. 그리고는 가만히 누워서 감각이 없어진 듯한 손바닥을 만져보며 동상과 화상의 기전과 증상에 대해서 잠시 고민해보다가 그건 별로 중요한 게 아니라는 생각에 고민을 멈췄습니다. 대신 다른 것을 고민했습니다. 오늘의 참사는 엔지니어링의 비극이라고 볼 수도 있지만 그래도 문제의 발생과 해결을 놓고 보면 그럭저럭 공학적이지 않았나 라는 생각을요.

 

예전에 제가 개발자들을 위한 MBTI를 만들어보면 어떨까 고민하다가 생각한 것인데, 개발자들은 크게 S형과 E형으로 나눌 수 있습니다. S형은 과학자형으로, 무언가를 만들거나 해결하기 전에 이론적인 토대를 견고하게 세우고 완벽한 시나리오를 바탕으로 실행에 옮기는 것을 좋아하는 타입이고 E형은 엔지니어형으로, 일단 시도를 먼저 하면서 많은 시행착오를 겪어가며 뭔가를 만들거나 문제를 해결하는 것을 좋아하는 타입입니다.

 

물론 많은 개발자들이 양쪽 성향을 다 가지고 있지만, 사람에 따라서는 어느 한쪽에 치우친 성향을 보이는 경우가 종종 있는데, 제가 관찰한 결과로는 과학자 성향이 강한 개발자는 이론이 증명될 때, 그러니까 치밀하게 계산한 결과를 구현에 성공해냈을 때 행복하고, 반대로 이론적인 토대를 갖추지 못한 상태에서 무작정 구현부터 해야 할 때 불행해집니다. 반대로 엔지니어형 개발자는 다양한 삽질 끝에 만족할만한 결과물을 내놓았을 때 행복해지는 편이고, 반대로 자신이 만들어낸 결과물의 이론적인 약점을 공격받고 방어해야 할 때 불행함을 느끼는 경우가 많았습니다.

 

그렇게 분류하고 나니, 막상 나는 무슨 타입일까에 대해서 고민해봤지만 결국 결론을 내리지 못했습니다. 가끔은 S형에 가까운 성향을 보일 때도 있는데, 어떨 때는 완전 E형인 거 같기도 하고 딱히 한쪽 성향이라고 보기 어려웠습니다. 그래서 내가 어떻게 일해도 불행함을 느끼는 게 아닌가 결론을 내릴 수 있었는데, 그 결론이 마음에 들지 않았던 저는 개발자 성격 분류 모델을 더 이상 발전시키지 않고 폐기해버렸습니다.

 

슬슬 몸이 뜨거워지는 것을 느껴져서, 온수매트의 온도를 낮추면서 가만히 생각해봤습니다. 오늘 나는 과학적이지 못했으면서 과학적이었고, 공학적이지 못했으면서 공학적이었는데 딱히 어느 한쪽에도 이거다 싶은 느낌이 오지 않는 것을 보니 역시나 애매한 성향을 가진 것이 확실한 것 같다. 그런데 뭐, 어쨌든 지금 따뜻하게 누워있고, 아까 그 결함도 완벽하게 고쳤고, 지금 물도 안 새고 있는데. 과학이나 공학이나 그게 내 인생에 뭐가 중요할까. 아마 이게 잠들기 전에 마지막으로 했던 생각이었던 것 같습니다.