로그

진보와 보수의 세계관

뻔돌이 — Thu, 4 Apr 2024 08:43:25 +0900

갈수록 각종 이익 집단들과 언론 뿐 아니라 대통령까지 거들어서 국민의 분열이 가속화되고 일상화되는 가운데, 진보와 보수는 무엇이 다른가 다루는 글이나 영상들을 자주 볼 수 있다. 안타깝게도 많은 경우 그 차이 보다는 도덕적 우열을, 때로는 심지어 지능의 차이를 말하기도 한다. 누군가는 저쪽에 있는 사람들을 설득하고 "올바른 길로 인도하는 것이 가능한가" 를 가지고 토론하기도 한다. 정말 진보와 보수를 옳고 그름으로, 혹은 정의와 불의로 구분하고 나눌 수 있는 것인가?

좌파니 우파니 진보니 보수니 하는 말들이 언제부터 왜 생겼는지는 잘 모른다. 200 여년 전 프랑스 혁명에서 시작된 거라는데 그 때의 그 의미와 지금의 그 의미가 같을까? 잘 모르겠다. 그저 스스로를 진보라 하거나 보수라 하는 자들의 언행을 관찰하여 그들이 어떤 집단인가를 생각해볼 필요가 있다. 겉으로 드러나는 차이를 여러가지 말할 수 있겠지만, 그런 차이가 왜 생기는지 이해할 수 있다면 자신을 돌아보고 어느 길로 가야할 지 결정하는 데 도움이 될 수 있을 것이다.

왜 사람들은 각자 다른 가치관과 사상을 가지게 될까? 또 그런 가치관이 그대로 정치 성향에 반영이 될까? 사람의 가치관은 개인의 경험에 좌우된다. 태어나서 다른 사람들 속에서 자라고 이것 저것 보고 들으며 세상이 어떻게 생긴 것인지 인지한 후에야 가치관이라는 것이 생긴다. 말하자면, 사람의 가치관은 그의 세계관에 따라 만들어진다고 볼 수 있다. 따라서, 세계관이 바뀌지 않으면 가치관이 바뀌지 않는다. 진보와 보수는 세계관이 무척 다르다.

초등학생 자식을 키우고 있는 친구가 어느 날 술자리에서 이런 얘기를 했다. "요즘 젊은 애들이 점점 보수화되는 이유가 뭔지 아냐? 게임 때문이야" 그 친구의 주장에 따르면, 과거 우리들은 의례 인간의 성장 과정이 그러하듯 질풍 노도의 시기에 반항적이고 비판적인 시각으로 세상을 바라봤지만 요즘 애들은 안그런다는 것이다. 요즘 애들은 아주 어릴 때부터 모바일 게임에 (특히 MMORPG 와 같이 다른 사람들과 경쟁하며 자신의 아바타를 강하게 만드는 것이 목적인) 흠뻑 빠져 있는데, 그렇게 어릴 때부터 게임의 룰에 익숙해진 결과 외부에서 주입된 룰을 수동적으로 받아들이고 학습하게 되며, 그 결과가 보수화라는 것이다. 뭔가 말이 되는 것 같기도 하고 아닌 거 같기도 했다. 요즘 애들이 주어진 룰에 수동적이진 않지 않나? 제멋대로인 건 우리가 애들이었을 때랑 비슷한 거 같은데...정말 게임이 보수적 정치 성향을 조장하는 모르겠지만, 그 때 그 친구의 말을 계기로 세계관에 대한 어떤 생각이 떠오르게 되었다.

보수 진영의 사람들을 관찰해보면, 그들이 바라보는 세계는 복잡한 부품으로 구성된 시계와 같은 거대한 기계 장치 또는 구조물인 것 같다. 크고 작은 톱니바퀴는 서로 제 자리를 지키고 정해진 규칙에 따라 움직여야 하며, 그렇지 않으면 시계가 멈추거나 고장난다. 사회는 그렇게 유지되고 돌아가기 때문에, 사람들은 각자에게 주어졌거나 혹은 자신이 선택한 역할에 충실하며 일사불란하게 움직여야 하는 것이다. 임금은 임금으로서 할 일이 있고, 신하는 신하로서 해야 할 일이 있으며, 그 선을 넘으면 안된다. 가정 내에서도 아버지, 어머니, 아들, 딸이 각자 역할이 있고 그 소임을 다해야 하는 것이다. 그래서 가부장적인 문화가 강한 환경에서 자란 사람은 보수적인 정치 성향을 가지기 쉽다.

그런 세계관에서는 차별과 경쟁이 당연시 된다. 복잡하고 정교한 기계 장치라면 귀하고 대체 불가능한 부품이 있는가 하면, 흔하고 쉽게 대체 가능한 부품이 있다. 그러므로 부품의 중요도가 다르고 그에 따라 가치가 달라지게 된다. 그와 같이 사회에서 어떤 역할은 중요하고 대체 불가능한 반면, 어떤 역할은 중요하지 않고 대체 가능한 것이 있다고 본다. 중요한 역할은 그에 맞는 능력과 자격을 갖추어야 하며, 그 일을 가장 잘 할 수 있는 자가 그 역할을 맡아야 하므로 경쟁을 통해 가장 걸맞는 자를 뽑아야 하는 것이다. 그러므로 경쟁은 바람직하고, 그에 따른 결과와 보상 역시 달라질 수밖에 없고, 그에 따라 생기는 차별은 정당한 결과이다.

이들이 볼 때 성적 소수자들은 마땅히 해야 할 역할을 하지 않으므로 위험한 존재다. 이들에게는 파업을 하고 시위를 하는 자들은 규칙을 지키지 않고 주어진 역할을 거부하기 때문에 사회를 고장내려는 위험한 존재다. 그러므로 국가는 사회를 유지하기 위해 이 위험한 존재들을 관리하거나 처벌해야 한다. 또한 이들은 사회 계층이 섞이거나 움직이는 것을 싫어한다. 우수한 명품견은 똑같이 우수한 명품견과 짝짓기를 해야 역시 우수한 명품견 새끼를 낳을 수 있는 것이니까. 아무리 우수한 명품견이라도 잡종견하고 짝짓기를 하면 잡종이 태어난다. 우수한 혈통과 품질을 유지하려면 같은 것끼리 짝짓기해야 하는 것이다. 진돗개의 우수함을 보호하고 유지하려면 진돗개끼리 짝짓기를 하게 해야 하지 않겠는가? 그래서 이들은 사회 계층을 섞으려는 국가 정책을 거부한다. 우수한 혈통이 보호되지 못하고 그 결과 부적합한 자가 중요한 역할을 맡게 되면 사회가 무너지게 되니까.

반면 진보 진영의 사람들이 바라보는 세계는 꽃밭이나 정원 같은 것이다. 환경에 따라 그에 적응한 종들이 번영하고 그에 맞는 곤충이 모이고 그를 잡아먹는 동물들이 모인다. 다양한 형형색색의 식물과 곤충과 동물이 생기고 사라지고 적응하고 진화하며 역동적으로 변화하는 세상이다. 좁고 한정된 공간에서 강한 자가 모든 것을 차지하게 그대로 내버려두면 나머지가 모두 도태되고 사라져버린다. 그러면 적응력이 떨어져서 환경이 급변했을 때 결국 모두 죽고 그 꽃밭은 사막이 되거나 잡초밭이 되고 말 것이다. 그러므로 이런 환경에서는 다양성이 중요하다. 다양성을 확보하기 위해서는 어느 정도 인위적인 국가 또는 사회적 차원의 간섭이 필요하다. 당장은 하찮은 약자더라도 보호해주어야 스스로 일어날 힘을 갖고 언젠가 사회를 구원하는 중요한 역할을 할 수도 있다고 보는 것이다.

그런 관점에서 보면 작거나 크거나 예쁘거나 못생겼거나 모두 저마다의 가치가 있고 소중하고 평등한 존재인 것이다. 이들에게 성적 소수자들은 다른 사람들에게 딱히 피해를 끼치지 않는 그냥 다른 존재일 뿐이다. 이들이 볼 때 고용인과 피고용인은 서로 평등한 계약 관계일 뿐이므로 언제든 서로가 그 계약 내용 변경을 요구할 권리가 있는 것이고 파업과 시위는 협상 결렬의 결과일 뿐이다. 이들은 사회 계층이 섞이지 않고 고착화되는 것을 근친상간을 통한 번식과 같은 매우 위험한 것으로 본다. 소규모 집단 내에서 남매끼리 사촌끼리 짝짓기를 하면 그 결과 유전자가 열화되어 그 집단은 결국 멸종하게 되듯, 사회 역시 다양한 계층의 교류와 융합이 없으면 위태로워진다고 본다. 이와 같이 진보 성향의 사람들은 사회 계층이 섞여야 생존할 수 있다고 보기 때문에 때로는 정책과 법률로 이를 강제하려고 한다. 가부장적인 가정 환경에서 강한 반감을 가지게 되었거나 자상하고 온화한 부모가 있는 사람들은 진보 성향을 가지기 쉽다.

보수가 볼 때 진보의 세계는 무질서하고 혼란스러운 곳이다. 진보가 볼 때 보수의 세계는 권위적이고 폭력적인 곳이다. 같이 놓고 보면 그토록 다른 사람들인데 아이러니하게도 추구하는 가치들과 말들은 비슷하다. 양쪽 다 공정, 상식, 정의, 자유, 평등을 말하는데 실제로 그들이 받아들이는 의미나 정도는 사뭇 다르다. 예를 들어, 보수가 부르짖는 자유는 주로 국가와 규제로부터의 자유를 의미한다. 자신의 능력과 자원을 최대한 발휘할 자유가 최우선이다. 그러나 그 자유는 평등하지 않다. 자격을 갖춘 자들, 그러니까 더 중요한 역할을 맡은 자들의 자유가 더 보장받아야 한다. 그래야 시계가 멈추지 않고 잘 돌아간다고 생각한다. 반면 진보는 이해관계가 다른 집단들 간의 평등과 다양성이 보호되는 조건이 만족되어야 자유를 인정한다. 누가 되었든 합의 없이 다른 사람의 자유를 침해하는 자유는 제재해야 마땅하다. 그래야 꽃밭을 더 오래도록 아름답게 가꿀 수 있다고 생각한다.

결국 두 진영은 목적지가 다른 것이 아니라 경유지가 다른 것이다. 만약 서로 비판해야 한다면 그 숨은 의도나 도덕적 결함을 걸고 넘어질 게 아니라, 각자 주장하는 방법으로 과연 원하는 목적지까지 갈 수 있는지 없는지를 다루어야 한다. 그런데 서로 너무 다른 생각을 하는 사람들끼리 서로가 왜 그런 생각을 하는지 이해하지 못하고 그럴 생각도 없으니, 상대방을 비정상이거나 나쁜 사람으로 보게되는 것 같다.

사실 대부분의 사람들은 둘 중 어느 하나의 세계관에서만 살고 있지는 않다. 사람들은 가족, 직장, 친구, 취미, 학교 등 동시에 여러 집단에 소속되어있다. 어떤 조직은 보수의 세계관이 잘 맞는가 하면, 다른 조직은 진보의 세계관이 더 적합할 수 있다. 그렇기에 사람들은 양 쪽의 가치관이 혼합되어 스위치를 껐다 켰다 하듯이 어떨 때는 보수처럼 굴고 어떨 때는 진보처럼 군다. 나이가 들거나 입장이 바뀌면 가치관도 바뀌는 경우가 많다. 대체적으로 점점 더 많은 사람들이 사회 문화적 측면에서는 진보로 가는 것 같은데, 경제 측면에서는 보수로 가고 있는 것으로 보인다.

사실 사회는 워낙에 복잡하고 다양한 변수가 있기 때문에 한 가지 관점으로만 보는 것은 불가능하다. 둘 중 어느 하나를 더 중요하게 여길 수는 있지만, 그렇다고 다른 하나를 완전히 없애기는 어렵다. 둘 다 각각 필요할 때와 장소가 있기 때문이다. 하지만 사람은 일관성을 지키려는 습성이 있기 때문에 자신의 정체성을 극단적으로 한 쪽 방향으로 정해놓고 모든 것을 그것에 끼워맞춰 해석하려고 한다. 옛날부터 사람의 성격 유형을 구분하는 방법들이 많이 있었다. 혈액형만 해도 4가지가 넘는다. 아직도 유행하는 MBTI 는 16가지나 된다. 그런데 이상하게 정치 성향은 꼭 진보와 보수 두 가지로만 나누어서 사람들을 그 틀안에 다 가두려고만 한다. 그러고는 한 쪽만 무조건 옳고 다른 쪽은 무조건 틀리다고 생각하며 그 근거를 찾고 정당화하는데 많은 시간을 허비한다.

간혹 정치성향이 극단적으로 왔다갔다 하는 사람들을 보는데, 자기만의 뚜렷한 가치관을 가지지 못하고 주변 사람들에게 수동적으로 반응하기 때문인 것 같다. 그러니까 이런 식이다. 알고 지내는 사람이 있는데 돈을 안빌려줬더니 뒤에서 주위 사람들에게 어려운 사람을 안도와준다고 내 흉을 보고 다녔다. 근데 알고보니 민주당 지지자네. 아, 민주당 새끼들은 다 개새끼구나. 난 국민의힘으로 가야지. 난 열심히 성실하게 일하는데 불합리하게 갑질을 당했다. 알고보니 그 새끼가 국민의힘 당원이네. 국민의힘 새끼들은 다 개새끼구나. 난 민주당 지지해야겠다. 이런 식으로 개인의 경험을 확대하고 일반화해 다른 집단을 모조리 똑같은 무리로 간주하고 낙인찍는다. 어떤 진영 소속의 인물을 악마로 만들면 그것을 일반화하여 그 무리를 다 나쁜놈들로 간주해버리니까 참 한국인들은 요리해먹기 편한 민족인 것 같다. 누구든 다양한 면을 가지고 있으며 언제든 틀릴 수 있고 잘못할 수 있다는 생각을 다시 해본다. 누가 더 나쁜놈인지 싸우는 것이 얼마나 쓸데없고 소모적이고 해로운 짓인지 다시 한 번 되뇌이고 앞으로는 그런 바람에 휘둘리지 않겠다고 다짐해본다.

조국과 질투의 힘

뻔돌이 — Tue, 26 Mar 2024 10:32:50 +0900

요즘 총선을 앞두고 조국의 활약이 의외로 대단하다. 몇 년 동안 워낙에 전국민적인 맹공을 받았던 탓에 괜히 나섰다가 오히려 더 망가지는 것 아닌가 싶었는데 참 한국인들은 알다가도 모르겠다. 국민들이 윤석열과 한동훈의 비열한 본색을 알아챈 후 지금까지 조국이 당한 멸문지화 수준의 처형이 공정하지 않다는 느낌을 받았기 때문이라는 해석이 많다. 난 조국 가족이 막 두들겨 맞던 그 비슷한 시기 나경원 자녀의 특혜와 비리에 대한 일부 진보 언론 기사와 보도를 접했고, 시민단체의 고발에도 불구하고 일체의 수사가 없었으며 대다수의 보수 언론은 언급조차 없던 것에 나경원이 검찰 개혁을 열렬히 반대하기 때문에 서로 편들어주는 건가보다 했었다. 그런데 검찰 개혁을 하려는 조국과 그 가족이 검찰에게 노골적인 학살을 당하는 것을 보고 아, 이건 검찰이 자기 권력을 건드리려는 자에 대한 정치적 보복이구나, 하는 생각이 바로 들었다. 그건 의심의 여지가 없었다. 공정과 상식을 말하는 자들이 비슷한 사안을 두고도 자기 편을 들어주는 자와 아닌 자에 대한 법 정의 적용이 하늘과 땅보다 더 큰 차이가 있었으니까.

조국 일가가 정말로 그런 일을 당할 정도로 큰 죄를 지었나도 의문이었다. 일부 유튜버들이 재판을 다녀와서 그 내용과 검찰의 주장과 논리가 무엇이었는지를 정리해주는 영상들을 보면, 저런 식이면 누구든 범죄자로 만들 수 있겠는데? 싶어 소름이 돋을 정도였다. 조국 가족들은 실제로 기득권 계층이기도 했고, 일반 서민들은 누리지 못하는 특혜를 누리긴 했을 거다. 그런데 그 특혜가 부당한 불법적인 범죄를 통해 남들로부터 뺏은 것인지, 또한 그로 인해 실제로 누군가 피해를 입었는지에 대한 심판보다는, 진보 인사가 특혜를 누렸다는 것 자체가 비난의 대상이 되었다. 평소에 공정과 정의을 외치는 진보 인사들은 더 엄격한 도덕성과 청렴결백함을 강요받기 때문에, 정당성을 떠나 특혜를 누린 것 자체가 위선과 불공정으로 보이기 때문이다. 진보와 보수는 적용되는 도덕적 잣대의 수준이 다르다. 경제가 어려운 시기에 진보 인사가 주식 투자를 해서 돈을 벌면 비난의 대상이 된다. 반면 보수 인사가 부동산 폭등의 시기에 부동산 투기를 해서 떼돈을 버는 것은 아무도 문제삼지 않는다.

누구는 수사는 커녕 신문에 한 줄 기사도 나가지 않는데, 누구는 수십만 건의 기사가 언론에 도배되어 가족과 친척들 모두 먼지 한 톨까지 탈탈 털리고 범죄집단으로 낙인찍히고 몰매를 당하는 상황은 내 눈에는 그야말로 광기 그 자체로 보였다. 그 당시 내가 더욱 화가 났던 것은, 너무나도 뻔히 보이는 검찰의 수작질을 대부분의 사람들이 문제삼지 않고 있다는 것이었다. 더 악랄한 놈들이 계획적으로 다른 누군가의 허물을 이용하여 부당한 반사 이익을 얻고 있는데, 그 꼴을 왜 그냥 보고 넘어가지? 대립하는 두 세력 중 하나가 악마가 되면 상대가 자동으로 천사가 되는 이 어이없는 무지함에 홧병이 날 지경이었다. 이러니 한국 정치에서 정책은 사라지고 네거티브 선동질만 남았지.

그 당시 조국 가족들이 재판을 받기도 전에 그 잘나고 똑똑하다는 서울대생들이 조국 물러나가며 시위를 했었다. 뭐 그럴 수는 있다. 그런데 그들은 거기서 멈췄고 그게 다였다. 그들의 눈에 다른 것은 보이지 않았던 걸까? 난 그게 참 안타까웠다. 그렇게 똑똑하다는 애들이 왜 그 정도에서 딱 멈추고 더 이상 나아가지 못했던 걸까. 조국을 계기로 모든 정치인들과 고위 공무원과 검찰까지 의혹이 있는 이들은 모두 똑같이 수사하자고 했어야지. 그게 정의와 공정성을 살리는 길이지. 공정함이 편파적으로 한 쪽에만 강요해서는 안되는 거잖아. 이런 주장들은 5년 전만 해도 범죄자를 두둔하는 것이라며 비난을 받았다. 그런데 이제 와서야 그런 얘기들이 겨우 받아들여지고 있는 것이다. 참 오래도 걸렸다.

하지만 난 이런 상황이 한국인들이 이제서야 공정함에 대해 다시 생각해보게 되었고 그런 면에서 성장했기 때문에 달라진 것이라고 보지 않는다. 난 조국과 그 가족이 전국민적인 마녀 사냥을 당한 진짜 이유는 정치적 암투나 언론 플레이의 영향도 크지만 그보다는 '질투' 라고 본다. 남들보다 앞장서서 조국 일가 사냥의 선봉에 나선 이들은 다름 아닌 기득권 계층 혹은 그를 지향하는 이들이었다. 내가 보기에 그들이 그렇게 열성적으로 조국을 죽이려고 든 것은 그를 질투했기 때문이다.

어렴풋이 그런 생각을 했지만, 그런 생각이 확신으로 변한 것은 본인을 변호사라고 소개한 어떤 여성 유튜버의 영상을 본 이후다. 그는 조민을 아주 대차게 까고 있었다. 공부를 그다지 잘하지 못해서 유학도 못가고 그냥 국내 대학에 겨우 간 거라는 둥 하면서 깎아내리기 바빴다. 변호사라는 그는 긴 생머리에 날씬한 미모의 소유자였다. 난 그 때 그의 말투와 어조, 사용하는 단어와 얼굴 표정에서 어떤 본능적인 느낌을 받았다. 아, 얘가 조민을 질투하고 있구나. 만약 조민이 뚱뚱하고 못샜겼다면 좀 덜 욕먹을 지도 모른다. 아마 그랬을 거다. 그런데 이쁘기까지 하잖아. 재벌은 아니지만 잘생기고 잘난 아빠에 엄마까지 교수고 부족한 거 없이 자랐고 게다가 의사인데 이뻐. 자기도 잘난만큼 잘났다고 생각하지만 조민과 비교했을 때 자신이 조금 딸린다고 생각하는 사람들은 틀림없이 질투심에 활활 불탔을 것이다.

박근혜 탄핵과 문재인 대통령 당선 이후 혜성처럼 나타나 연예인도 아니면서 연예인 급 인기들 한 몸에 받는 조국을 보며 배가 아픈 사람들도 무지 많았을 것이다. 뛰어난 지식과 지성의 소유자일 뿐 아니라 왠지 모를 품격이 느껴지는 잘생긴 외모는 충분히 질투를 불러일으킬 만하다. 만약 조국이 뚱뚱하고 못생겼다면 그렇게 큰 인기를 얻지도 못했을 테고, 그렇게 미움받지도 않았을 거다. 그랬던 사람들이 검찰이 이끈 조국의 몰락을 보며 극심한 복통과 상처받은 자존심이 회복되어 통쾌한 기쁨을 맛보았을 것이다. 열등감과 질투 때문에 자존감이 구겨져 고통받던 사람들이 그 질투의 대상이 어느 날 불행해 지는 것을 보며 신체적 심리적 보상을 받는 것은 마약 하는 것과 같다. 그런 종류의 기쁨은 자신이 스스로 고생하고 노력해서 얻는 결실로 맛보는 기쁨과는 차원이 다른 훨씬 자극적이고 짜릿한 쾌감이 있다. 그런 쾌감은 한 번 맛보면 헤어나기 힘들다. 열등감과 질투는 본능에 가깝고, 본능은 이성보다 강하기 때문이다. 그런 본능에 휘둘린 이들은 광적인 인민재판에 휩쓸리기는 쉽겠지만, 그 뒤에 숨은 음모와 부조리함을 꿰뚫어보기는 어렵다.

난 조국이 이제서야 조금씩 이해받거나 혹은 동정을 받고 지지받는 이유는, 당할만큼 당하고 망할만큼 망해서 더 이상 느낄 질투가 별로 없기 때문이라고 본다. 가만 보면 얼굴도 꽤나 상했다. 정치적으로 망하든 말든 수백억 자산을 자지고 있으면서 남들보다 잘먹고 잘 살고 여전히 매끈하고 탱탱한 피부를 가지고 있었다면 이런 지지를 받지 못했을 것이다. 의사였던 딸 조민이 고졸로 전락하고 의사 자격을 반납하고 백수로 지내다가 그저 그런 특별할 거 없는 일상 공유 유튜버가 되고 돈 벌기 위해 앞광고를 하다가 허위 광고로 고발당해 또 검찰 수사를 받을 정도로 추락하지 않았다면 과연 이런 지지를 얻을 수 있었을까?

난 과거 조국이 범죄 혐의로 언론에 수만 번씩 오르내릴 때 핏대 세워 조국 심판을 외쳤던 그 잘난 서울대생들이 지금 윤석열 한동훈에 그다지 비판적이지 않은 것은 그들에게 질투를 느끼지 않기 때문인 것도 크다고 본다. 윤석열과 한동훈은 학벌과 스펙이 좋다고는 하지만 그들의 말투나 몸짓과 하는 말들을 가만 보면 열등감과 질투를 유발할 정도의 지성과 교양과 품격은 거의 없다. 서울대 출신이 고작 저 정도밖에 안되나 싶을 정도로 참 가볍다. 깃털처럼. 그렇기 때문에 서울대생들이 그들을 지지하거나 좋아할 지는 몰라도, 조국을 볼 때와는 달리 절대 열등감이나 질투를 느끼지는 않을 것이다. 그건 확실하다. 게다가 무능한 정권으로 나라가 망가진다고 해도, 기득권 계층은 그다지 큰 피해를 보지는 않는다. 오히려 이익을 보면 봤지. 그러니 이래 저래 굳이 그들을 비판할 필요가 없다.

조국이 언젠가 정권이 바뀌고 검찰이 씌운 범죄자 프레임에서 벗어나 부활하여 과거의 전성기를 또 다시 누릴 날이 올 수 있을까? 글쎄. 그러기에는 아직 질투의 불씨가 완전히 꺼진 것은 아닌 것 같다. 언젠라도 다시 활활 불탈 수 있는. 지금 받고 있는 지지도 일시적인 것일 지도 모른다. 어쩌면 지금 그가 받는 지지로 또 다른 이들이 다시 질투에 불타고 있을 지 모른다. 검찰이 조국 일가에 가하는 정치 보복이 5년이 지난 아직도 현재 진행형이기 때문에 그들이 받는 고통이 지속되는 한 지지는 계속 이어질 수 있다. 그러나 언젠가 명예를 회복하고 검찰의 비열한 괴롭힘에서 해방되는 날이 온다면? 아무튼...조국과 조민은 좀 더 못생기게 태어났어야 했다.

모바일용 Vue3 + Bootstrap5 폼 필드 공통 콤포넌트 만들기

뻔돌이 — Sun, 27 Aug 2023 01:59:44 +0900

vue3-bootstrap5-cmp.zip

0.76MB

압축을 풀면 필요한 파일이 다 들어있어서 오프라인으로 실행 가능. fieldcmps.html 을 브라우저에서 열면 다음과 같이 폼 필드 콤포넌트 테스트 가능함.

폼 필드 콤포넌트 테스트 화면

사용 라이브러리

- Vue 3.3.4

- Bootstrap 5.3.1

- dayjs 1.11.9 (https://day.js.org/)

- bootstrap-datepicker 1.10 (https://github.com/uxsolutions/bootstrap-datepicker)

- font-awesome 6.4.2 (Free Icon 만 사용)

- jQuery 3.7.0

datepicker 는 처음에는 Vue 용 datepicker 를 쓰려고 했는데 DOM 형태가 Bootstrap 에 맞게 되어있지 않아 Bootstrap 용을 사용했다. 오늘/닫기/삭제 버튼과 PDA 용으로 전체 화면 크기로 확대해서 보여주는 기능을 추가하기 위해 소스 수정을 약간 했기 때문에 min 버전을 쓰지 않았다. 거기에 한국어 지원을 위한 추가 소스를 별도로 받아서 소스 아래 부분에 추가함. 원래 datepicker 는 다양한 옵션과 기능이 있지만 기타 옵션을 사용하지 않고 오직 년월일 형태만 허용하고 단순하게 제한없이 날짜 하나만 선택하는 기능만 사용. 온전히 기능을 다 사용하기엔 스피너를 그에 맞게 구현하기에 까다로워서 포기..

시리얼 목록은 바코드 스캐너 입력을 위한 필드다. 바코드 스캐너는 보통 스캔한 값을 인풋 필드에 한 번에 입력하지 않고, 읽은 문자 하나씩 매우 빠르게 입력한다. 그래서 한 글자 한 글자 키다운 이벤트가 발생한다. 상품 코드나 유효일자 제조로트 시리얼 번호 등 많은 데이터를 포함하는 GS1 바코드일 경우 AI 구분자인 FNC1 문자가 입력되지만 실제 input value 에는 추가되기 않는다. FNC1 문자는 국제 표준으로 29번 아스키코드를 쓰는데, 간혹 바코드 스캐너에 따라 ALT 나 F8 을 쓰는 것들이 있어 키 다운 이벤트에서 그것까지 포함하여 체크, 있으면 29번 아스키코드를 String 으로 변화하여 강제로 추가해 줘야 한다. 그렇게 하면 크롬 브라우저의 경우 양쪽 화살표 같은 모양이 input value 에 추가된 것이 눈에 보인다. 근데 사파리는 안보인다. 그래도 콘솔에 찍어보면 나온다. 그렇게 해줘야 서버단에서 데이터를 파싱할 때 AI 를 정상적으로 구분할 수 있다. GS1 바코드라면 시리얼 번호만 뽑아내야 하기 때문에 스캔 값을 Ajax 로 (로딩 마스크 적용 sync 옵션) 서버에 보내 어떤 유형의 바코드인지 구분하고 스캔해야 할 상품이 맞는지 상품 코드를 검증하고 파싱 결과 데이터를 받아 처리하는 부분이 있는데 그건 제거하였다.

그 외 각 콤포넌트 기능 옵션은 props 에 있는 것들을 사용하고 소스가 그리 복잡한 건 아니기 때문에 공통화를 위한 콤포넌트 개발을 고민하는 개발자라면 문제 없이 분석 가능할 거라 생각해서 따로 설명을 달지 않았음.

...

최근 회사 솔루션 신규 버전 개발을 완료하고 곧 착수할 신규 프로젝트에 처음으로 적용하기로 했는데, 그를 위해 급하게 PDA 용 표준을 새로 만들었다. 회사 솔루션은 Sencha ExtJS 를 사용하는데, 그게 PDA 에 쓰기에는 좀 그랬다. 왜냐하면 PDA 는 화면이 무척 작은데 ExtJS 모던 테마 콤포넌트들이 큼직큼직하기 때문에 나중에 꽤나 곤란해질 수 있기 때문이다. SASS 를 지원하지만 쓸 줄 모르고 있다해도 사이즈에 관련된 속성은 많지 않다. 게다가 ExtJS 가 콤포넌트 템플릿이 굉장히 복잡하기 때문에 CSS 에 직접 손대는 건 거의 지옥에 가까운 작업이다. 또한 CSS 가 아니라 콤포넌트 자바스크립트 소스에 직접 하드코딩으로 사이즈가 들어가있는 경우도 꽤 있어서 사이즈 조정하는 건 생각보다 매우 어렵다.

아무튼. 과거 솔루션 버전은 PDA 용 소스가 jQuery 로 떡칠이 되어있어서 소스가 아주 드럽고 뭐 하나 수정하기가 너무 힘들었다. 일일이 인풋 객체에 값을 넣어주고 빼고 목록 조회해서 그걸로 html 을 직접 조작하고...화면을 보면 별 거 아닌 거 같아도 소스가 굉장히 길었고 개발 생산성도 매우 나빴다. 아주 그냥 $ 가 소스에 판을 치고 있어서 눈알이 핑핑 돌았다. 그래서 React 나 Vue 처럼 콤포넌트화 가능하고 뷰모델 양방향 바인딩을 지원하는 프레임웍을 꼭 써야겠다고 생각했다. 요즘 PDA 는 안드로이드 운영체제라 크롬 브라우저가 다 있기 때문에 큰 걱정없이 최신 프론트엔드 프레임웍 사용이 가능하다. 아무래도 예전에 잠깐이지만 Vue 를 공부해본 적이 있고 아무리 봐도 React 는 좀 어려워 보여서 Vue 를 쓰기로 했다.

순수 Vue 외에 BootstrapVue 나 Vuetify 도 생각을 해봤는데, 아무래도 콤포넌트와 강력하게(?) 엮여있는 디자인은 변경이 어려워서 꺼려졌다. 하지만 우리 회사에는 퍼블리셔가 없기 때문에 화면 디자인을 할 줄 아는 사람이 없다. 그래서 Bootstrap 을 쓰는 게 가장 최선으로 생각되었다. 그래서 Vue3 와 Bootstrap5 를 써서 차근차근 폼 필드 공통 콤포넌트부터 만들고 로그인, 메인 화면, 각 메뉴 화면, 데이터 조회와 저장 등 개발 표준을 거의 완성했다. 몇 년만에 밤세워 코딩했다. 아직 완전히 테스트가 끝난 게 아니라서 결함이 있을테지만 그렇더라도 혹시 모바일용 어플리케이션 개발시 공통 콤포넌트 개발에 고민하고 있는 사람들에게 도움이 될 수 있지 않을까 해서 공개해본다.

근데 요즘 Vue3 공부하는 사람들이 만약 이 소스를 보면 Composition API 를 쓰지 않고 과거 Vue2 방식의 Options API 를 쓰고 있기 때문에 꽤 의아하게 생각할 지도 모르겠다. 왜 그랬냐고 묻는다면...Composition API 가 더 진보한 거라고는 하지만 왠지 내겐 산만해 보였다고 할까. 괜히 소스가 정리되지 않은 느낌? 익숙치 않아서 그런 거 아니냐고 묻는다면 아니라고는 못하겠다. jQuery 도 사용했는데, Bootstrap 용 datepicker 가 jQuery 에 의존하기 때문이기도 했고, 필요한 DOM 조작이나 값 변경을 Vue 만 가지고는 안되는 경우도 있었기 때문이기도 했다. 또 나에겐 Ajax 도 잘 나간다는 axios 보다 그냥 jQuery 의 $.ajax() 가 편하기도 했다.

나는 옛날 사람이어서 html, css, javascript, java, sql 등 잡다하게 다 해오긴 했지만 사실 프론트 엔드는 내 적성이 아니었다. 백 엔드 체질이라 화면 개발을 무척 싫어한다. 해야 하기 때문에 어쩔 수 없이 하지만, 요즘처럼 프론트 엔드가 전문화되고 프레임웍이 고도로 발전하면서 잘게 쪼개진 모듈화나 자체 언어와 빌드 시스템까지 갖춘 모습은 영 적응이 안된다. 자바스크립트 라이브러리를 npm 으로 배포하고 설치하는 것도 영 어색하다. 그냥 사이트에 들어가서 통짜 js 파일 하나를 다운로드 받는 게 좋다. 사실 자바 9에 나온 모듈 시스템도 잘 몰라서 아직 제대로 써 본 적이 없다. 난 아직도 모놀리식 아키텍처가 좋다...내가 그런 면에서 시대에 뒤쳐진 건 이유가 있다.

회사 솔루션은 SAAS 가 아니라 On-premiss 방식으로 고객사 맞춤 커스터마이징이 필수여서 SI 처럼 구축된다. 시스템이 다중화 서버 환경이기는 해도 프론트 엔드 서버와 백 엔드 서버가 분리되어 있는 건 아니다. 프로젝트 할 때마다 잘 훈련된 고정 멤버들이 투입되는 게 아니라 외주 프리랜서가 반 이상 투입되고, 회사 정규직 개발자들도 어느 정도 경력이 쌓이면 이직해버려서 신입 아니면 나처럼 라떼를 벗어나지 못한(?) 뒤쳐진 나이 많은 사람들 뿐이다. 한마디로 우리 회사 솔루션 구축 프로젝트에는 뛰어난 개발자가 투입되지 못한다. 심지어 스프링부트조차 익숙하지 않은 사람들이 많다. 그런 환경이기 때문에 필요한 콤포넌트가 모듈화되어 다 산재되어 있고 적절히 어디에 뭐가 있는지 알고 import 해야 하는 건 너무 복잡하다. 그러기에 SPA 도 애초에 고려 대상이 아니다. 프로젝트 끝나면 다시는 서로 안볼, 몇 개월 동안 말을 섞기는 커녕 서로 인사조차 안하는 개발자들끼리 모여있는데, 그런 환경에서 무슨 SPA? 누군가 잘못 개발하면 화면 전체가 에러나서 다른 개발자들 모두 영문도 모른채 작동하지 않는 화면을 보고 어라 갑자기 왜 이러지 하면서 삽질하고 있을텐데. 서로 동일한 이름의 전역 변수를 만들어서 쓰면 언제 어디서 어떤 오류가 날 지도 모르고. 그 때문에 개발자들끼리 서로에게 영향을 주지 않도록 하기 위해 모든 메뉴 화면은 iframe 으로 생성하게 만들었다.

그런 이유들로 (사실은 내가 잘 몰라서) 복잡하게 import, export 하거나 .vue 같은 확장자를 가진 템플릿 소스에 빌드를 해야하는 방식 말고, 그냥 통짜 라이브러리 파일 하나만 로드해서 쓰는 방식으로 만들었다. 가뜩이나 서버단 비즈니스 로직 구현도 복잡하고 아직도 Mybatis 를 써서 쿼리를 작성하는 방식이어서 그것만으로도 벅찬데, 화면단까지 복잡하면 생산성이 너무 떨어진다. 특히 화면은 수정 요구도 자주 발생하여 개발에 상당한 시간이 소요되기 때문에 화면 구성 패턴이 정해져 있어야 하고 공통화가 잘 되어있어 코딩해야 하는 소스 양이 적어야 한다. 만들어야 하는 파일 수도 적어야 한다. 그리드 여러 개에 탭에 팝업 등등 어지간히 복잡한 화면이라도 그냥 파일 하나에 길어봐야 500 라인 넘지 않을 정도여야 한다. 신입이나 외주 개발자도 기존 개발된 소스만 보고도 아~ 하면서 바로 개발할 수 있을 정도로. 그냥 한 두시간 교육받으면 비슷하게 생긴 화면 복붙해서 필요한 부분만 쓱싹 수정하면서 공장에서 물건 찍어내듯이 소스를 찍어낼 수 있을 정도로. 기본만 되어 있다면 그냥 어중이 떠중이들 데려다가 개발 시켜도 문제가 없을 정도로. 특히 요즘은 점점 고객사가 요구하는 프로젝트 구축 기간이 줄고 있어서 생산성은 더욱 중요해지고 있다. 그런 면에서 ExtJS 가 공통화만 잘 하면 꽤 좋다. 그런 사상으로 표준을 잡았기 때문에 요즘 트랜드에 비춰보자면 무식해 보일 수 있겠지만, 개발 생산성은(속도) 사내에서도 다들 인정하는 부분이다. 그래서 이번에 PDA 표준도 그렇게 잡았다. 물론 통짜 라이브러리를 쓰면 용량이 좀 된다. 하지만 브라우저가 정적 소스는 대부분 캐싱을 하기 때문에 처음에 한 번만 용량이 많지 그 다음부터는 트래픽을 그리 많이 잡아먹지는 않을 거라는 게 내 생각이다.

누가 써보실 지는 모르겠지만, 혹시 버그를 발견한신다면 댓글 부탁 드림...

국민의 힘? 어떤 국민의 힘인가요? 일본 국민의 힘?

뻔돌이 — Tue, 21 Mar 2023 10:54:14 +0900

부자와 거지, 신세대와 구세대, 남자와 여자, 진보와 보수, 좌파와 우파, 공산당과 친일파. 늘 갈라지고 분열하면서도 어떻게든 버티는 한심하면서도 신기한 나라. 이런 나라에 살고 있다는 것을 느낄 때마다, 내 심장이 흥분하고 분노할 때마다, 사람들마다 입장이 다르고 생각이 다를 수 있는 거지, 하면서 마음을 가다듬는다. 사람들끼리 다투는 문제들을 보면 옳고 그름을 따지기 어려운 일들이 많다. 되도록 편견이나 극단적 치우침에 빠지지 않으려고 늘 내 생각을 반대로 뒤집어 역지사지 해보려고 노력한다. 그런데 아무리 생각해봐도 최근 3.1 절부터 터져나온 한일 관계, 반일 감정에 대한 논쟁과 다툼은 확실히 윤석열과 국민의 힘이 잘못하고 있다는 생각이 든다.

첫째 이유는, 미래 지향이라는 이유로 청산되지 않은 과거를 그냥 묻어버리려 하기 때문이다. 역사 하면 떠오르는 말이 있다. "역사는 반복된다" 는 것. 역사가 반복되는 이유는, 인류가 역사로부터 아무것도 배우지 못하고 같은 실수를 저지르기 때문이다. 뼈아픈 과거일수록 더욱 치열하게 들여다보고 결코 잊지 말아야 하는 이유다. 역사 청산은, 같은 잘못을 반복하게 하는 불씨를 없애겠다는 데 의의가 있다. 독일은 말과 행동으로 그런 의지를 보였고 믿음을 얻었다. 하지만 일본은 아니다. 한일 관계에서 진정한 역사 청산이란, 다시는 제국주의 또는 전쟁과 정복이 반복되지 않도록, 미래 우리 자손들이 똑같은 일을 당하지 않도록, 비극을 예방하고 방지하는 확실한 체제를 구축하는 것이다. 그것은 일본이 공식적이고 공개적으로 반인류 범죄를 반성하고 사죄하며 전쟁 범죄자들을 국가 영웅으로 떠받드는 어리석음을 중단하는 것부터 시작해야 한다. 일본은 피해자들이 사과라고 느낄만한 사과를 한 적이 없다. 사과 한답시고 한 유감 표명은 그냥 지들 기분이 안좋다는 뜻이지 잘못했고 미안하고 다시는 그런 일 없게 하겠다는 뜻이 절대로 아니다. 백번 양보해서 말로 사과했다고 친들, 행동은 그렇지 않았다. 겉으로는 토착 종교나 문화로 포장하면서 실제로는 여전히 전쟁 범죄자들의 뜻을 기리고 있지 않은가?

한일 관계에서 불편한 역사의 청산은 일본이 먼저 해야 하는 일이다. 그것은 돈으로 하는 것이 아니다. 말과 행동으로 해야 하는 것이다. 일본 식민지 시대 피해자들이 진정 원하는 것은 그런 것이다. 역사를 제대로 청산하지 않으면, 그 역사는 반복된다. 그런데 역사 청산은 커녕 회피하고 그냥 땅에 묻어버리려고 하면서, 그렇게 그 위험하고 처절한 역사가 반복될 씨앗을 심으면서, 미래와 미래 세대를 위한 결정이었다고? 도대체 어떤 미래와 미래 어떤 세대를 의미하는 건가? 한국이 이런 식으로 정당이 바뀔 때마다 흔들리고 국민의 의견이 한 뜻으로 모이지 못하고 분열되는 것을 보면, 언젠가 또 일본 식민지가 되고 안그래도 쪼개진 국가가 또 반으로 쪼개진다 해도 전혀 이상한 일이 아니다.

둘째 이유는, 대통령과 집권당 정치인이라는 사람들이 자국 국민들보다 외국 국민들 편을 들고 있기 때문이다. 국민의 힘에서는 일본에게 진심어린 사과를 요구하는 것을 두고 "악을 쓴다" 고 말했다. 민족 비극의 반복을 방지하기 위한 역사 청산을 그저 개인적인 복수나 땡깡 정도로 치부하는 치명적인 단어 선택이었다. 그런 단어를 쓴다는 것 자체가, 제대로 사과받지 못해서 한이 맺힌 피해자들을 그냥 돈이나 뜯어 먹으려고 피해자 코스프레 하는 양아치 도둑 집단으로 인식하는 듯 보인다. 일본인들이 그런 말을 들으면 한국인들을 얼마나 우습게 보겠는가? 저 봐라, 한국의 집권당이 자국 대법원의 판결까지 뒤집으며 저렇게 말했다, 일본을 비난하는 '일부' 한국인들은 선량한 일본을 이유없이 비난하는 싸이코 집단이다, 이렇게 말할 것 아닌가? 악을 쓴다니? 정치인들이 자국인들 편을 들어야지, 왜 자국 국민들을 우습게 보고 무시하는 외국 편을 드는 것인가? 그들은 누구를 위해 존재하는 사람들인가? 전쟁 범죄 피해자들이 왜 수십년이 지나도록 상처를 회복하지 못하는지, 도대체 어떤 아픔이 있었길래 아직도 눈물을 흘리고 있는지, 제대로된 정치인이라면 귀를 귀울여야 하는 것 아닌가? 도대체 국민들에 대한 공감 능력이 전혀 없는 그들이 정치를 할 자격이 있는 것인가? 왜 그런 자들을 정치하라고 뽑아주는 것인가? 그런 자들을 정치하라고 뽑아주는 인간들은 도대체 어떤 인간들인 걸까?

모든 정치 활동의 궁극적인 목표는 국익이어야 한다. 모든 나라가 그렇게 한다. 국익은 먼저 국민들의 정서와 행복을 가장 우선시하는 것부터 시작해야 한다. 정치인은 국민들의 대변인이어야 한다. 경제적인 국익도 장기적인 시각을 갖고 구체적인 비전과 계획이 있어야 한다. 지금 윤석열과 국민의 힘은 우리 국민들을 제대로 대변하고 있는가? 그들이 말하는 미래는 얼마나 구체적이고 장기적인 비전을 바탕으로 한 것인가? 북한과의 관계 개선이나 통일은 전혀 고려하지 않고 무조건 영원한 적으로 못박은 채 그려진 미래만 바라보고 있는 것 아닌가? 미국 중국 일본에 휘둘리지 않는 힘을 가질 수 있는 미래를 꿈꾸고는 있는 것인가? 말로만 미래를 위해 어쩌구 하는데 그게 도대체 어떤 미래인지, 그리고 그 미래를 만들어 나가는데 지금 하고 있는 일들이 어떻게 기여하는 것인지 아무런 설명도 계획도 청사진도 없다. 정말 극단적으로 생각하거나 분노와 증오에 휩싸이기 싫은데, 도무지 이 놈의 나라는 그러지 않을 수 없게 만든다. 미칠 노릇이다.

아직도 분열과 다툼은 멈추지 않고 있다. 그 와중에 선동적이고 자극적이고 비논리적인 구호만 넘쳐나고 있다. 그 어디에도 합리적이고 진지한 논리는 없어 보인다. 특히 공산당 대 친일파 프레임 전쟁은 3.1 절만 되면 늘 터져나오고 반복되는 일이다. 이 역시 역사 청산이 첫 단추부터 제대로 되지 않은 탓이 크다. 근시안적인 시각으로 지금 당장의 이익과 자기들 각자의 자리만 생각한 탓이 크다. 서로 비난하고 싸우는 것은 각자 꿈꾸는 미래가 있기 때문일텐데, 그것부터 얘기해보고 그런 미래를 만들기 위해 지금 하는 일이 옳은지 따지는 것이 순서 아닐까 싶다. 단, 당장 5년 10년 후의 미래뿐만이 아닌, 100년 후까지 바라보는 미래여야 할 것이다. 영원한 적도 동맹도 없는 냉정하고 잔혹한 국제 관계에서, 그 와중에 아직 힘도 없고 주변 강대국의 대결 구도 한복판에 서서 눈치 잘 보며 처신해야 하는 입장에서, 너무 성급하게 역사를 생매장하고 한 쪽 눈만 뜬 채 무모하게 움직여서 잘못된 길로 들어서고 있는 것은 아닐까? 당장의 이익 뿐 아니라 미래의 이익까지도 송두리째 날려버리고 있는 건 아닐까?

유토피아를 꿈꾼다면 그릴 수 있는 모습은 수백 수천개 되겠지만, 국제 관계와 안보 면에서 생각해보자면, 한국이 강한 나라가 되었으면 좋겠다. 미국 중국 일본 등 다른 나라들에 할 말은 하면서 확실하게 이익을 챙길 수 있는 힘을 가졌으면 좋겠다. 그러려면 북한과 통일이 되어야 할 것이다. 처음에는 힘들고 방황하겠지만 둘로 쪼개진 상태로는 강한 힘을 가지기 힘들다. 그런 힘을 바탕으로 일본이 다시는 한국을 넘보지 못하게 확실하게 사과 받고 재발 방지 약속도 받으면 좋겠다. 한국과 일본의 관계와 역사를 알고 있는 미국 중국 등 다른 나라들이 봤을 때, 일본에게 먼저 손을 내밀면서 사과 안해도 된다며 너털 웃음을 짓는 한국과, 엄중하게 경고하며 진심어린 공개적 공식적 사과와 재발 방지 약속을 받아내고야 마는 한국 중, 어떤 한국을 더 강하고 무시할 수 없는 나라로 볼까? 형제들끼리 쪼개진 채 영원히 주변 국가들을 끌어들여 서로 싸우는 한국과, 아픔을 딛고 끝내 서로 용서하고 화해하고 힘을 합치는 한국 중, 어떤 한국을 더 성숙하고 앞선 나라로 볼까? 대체 우리는 어떤 한국을 꿈꾸는 걸까? 지금 우리가 가는 길이, 한국을 그런 나라를 만들어가는 길일까?

MyBatis + Oracle 에서 insert into ~ select 오류

뻔돌이 — Fri, 23 Dec 2022 16:02:25 +0900

데이터 추가 수정이 있을 때 히스토리를 남겨야 한다거나, 무언가 설정할 때 기본 값들을 복사해서 넣어주거나 할 때 일괄 insert 하는 쿼리문을 작성해서 사용하곤 한다. 개발 중 아주 단순한 쿼리인데 구문 오류가 났다. 어디 콤마를 잘못 찍었나 했는데 아무리 눈씻고 봐도 잘못된 곳이 없다. 심지어 SQL Developer 에 복사해서 실행하면 잘만 된다. 지금까지 10년 넘게 개발하면서 이런 적이 한 번도 없었는데 뭐지 이건. insert into ~ values 는 아무 이상이 없었고, insert into ~ select 할 때만 발생했다. 어딘가 설정상의 문제일 것 같아서 검색을 해보았다.

아주 단순한 insert into ~ select 구문. 이게 에러날 게 뭐 있어...?!

INSERT INTO XXX ( ... ) SELECT ... FROM YYY WHERE ~

java.sql.SQLSyntaxErrorException: ORA-00933: SQL 명령어가 올바르게 종료되지 않았습니다

	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:447)
	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
	at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:951)
	at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:513)
	at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:227)
	at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
	at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:208)
	at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1046)
	at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1336)
	at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3613)
	at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3714)
	at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1378)
	at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
	at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
	at net.sf.log4jdbc.sql.jdbcapi.PreparedStatementSpy.execute(PreparedStatementSpy.java:443)
	at jdk.internal.reflect.GeneratedMethodAccessor87.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.apache.ibatis.logging.jdbc.PreparedStatementLogger.invoke(PreparedStatementLogger.java:59)
	at jdk.proxy3/jdk.proxy3.$Proxy108.execute(Unknown Source)
	at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:47)
	at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:74)
	at org.apache.ibatis.executor.ReuseExecutor.doUpdate(ReuseExecutor.java:52)
	at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:117)
	at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:194)
	at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:181)
	at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:176)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:427)
	at jdk.proxy2/jdk.proxy2.$Proxy88.insert(Unknown Source)
	at org.mybatis.spring.SqlSessionTemplate.insert(SqlSessionTemplate.java:264)

MyBatis 와 관련되어 몇 개의 블로그를 봤는데, sql 매퍼에서 <insert> 태그를 쓰지 말고 <update> 태그를 쓰라는 것이었다. 해보니까 에러 안나고 되긴 하는데, 상식적으로 이해가 되지 않았다. 무슨 상관이지 그게? 모든 DBMS 벤더들은 자바 어플리케이션용 드라이버를 제공할 때는 무조건 JDBC API 를 구현해야 한다. 그 틀을 벗어날 수 없다. 근데 JDBC API 는 insert 나 update 를 구분하지 않는다. 그냥 Statement 의 execute 나 executeUpdate 를 쓰는데, insert 든 update 든 delete 든 둘 중 아무 메서드나 써도 상관없다. MyBatis 도 쿼리 xml 작성할 때 <insert>, <update>, <delete> 태그를 쓴다고 해서 실제로 그게 insert 문인지 update 문인지 delete 문인지 체크해서 검사하거나 그러지도 않는다. 그런데 태그 차이로 이런 에러가 난다는 게 도무지 이해가 되지 않았다. 진짜 범인은 다른 곳에 있는 게 분명했다! 일단 오늘 할 일을 끝내놓고 나서 갓 오브 워 공략이나 볼까 했는데, 삽질하느라 열 좀 받고나니 이 자식부터 족쳐봐야겠다는 생각이 들었다. 이 녀석 잡을 생각에 후딱 일을 끝내고 본격적으로 디버깅을 해봤다.

개인적인 생각으론, Oracle 의 autoGeneratedKeys 관련한 PreparedStatement 구현 상의 제한인 것 같다는 결론이다. MyBatis 가 Proxy 를 하도 많이 써서 인터페이스나 추상클래스도 많아 소스만 보며 따라가기는 힘들다. 직접 브레이크 포인트를 찍어가면서 디버깅을 해야 실제 수행되는 소스를 따라갈 수 있는데, MyBatis 의 PreparedStatementHandler 에서 아래와 같은 부분을 만났다.

@Override
protected Statement instantiateStatement(Connection connection) throws SQLException {
  String sql = boundSql.getSql();
  if (mappedStatement.getKeyGenerator() instanceof Jdbc3KeyGenerator) {
    String[] keyColumnNames = mappedStatement.getKeyColumns();
    if (keyColumnNames == null) {
      return connection.prepareStatement(sql, PreparedStatement.RETURN_GENERATED_KEYS);
    } else {
      return connection.prepareStatement(sql, keyColumnNames);
    }
  } else if (mappedStatement.getResultSetType() == ResultSetType.DEFAULT) {
    return connection.prepareStatement(sql);
  } else {
    return connection.prepareStatement(sql, mappedStatement.getResultSetType().getValue(), ResultSet.CONCUR_READ_ONLY);
  }
}

디버깅하는 중에 보니까 첫번째 if 에 걸려들었다. 이건 뭐지, 키 제네레이터? 이름에서 왠지 MySQL 에서 auto_increment 컬럼 있는 테이블에 insert 할 때 쓰는 useGeneratedKeys 옵션이 생각났다. 뭔가해서 자료를 찾아보니 그게 맞았다. 사실 그와 관련하여 Connection 의 prepareStatement 메서드가 하나만 있는 게 아니라 두번째 파라미터가 있는 녀석들이 있다는 것도 이번에 처음 알았다.

나는 개발 일을 처음 시작할 때부터 Oracle 쓰는 프로젝트만 해왔고, 최근 MySQL 몇 년 써보고 MSSQL 은 올 해 처음 써봤다. 개발팀 성향에 따라 DB 설계 방식이 다른 면이 있어서, PK 를 여러 개 만들어서 쓰는 곳이 있는가 하면, 무조건 자동증가 채번 값을 유일한 PK 로 만들어 쓰는 곳들도 있는데, 난 주로 PK 를 여러 개 만드는 솔루션 회사에서 일해왔다. Oracle이다보니 sequence 를 쓰고, NEXTVAL 로 채번하는 매퍼를 별도로 만들어서 그것을 사용했다. 예를 들어 사원 번호나 주문 번호 혹은 상품 번호 같은 것들은 코드 자체가 아무 의미없이 순번인 경우도 있지만, 고객사에 따라 자릿수를 특정 갯수로 맞춰 달라든가, 날짜나 어떤 의미를 담고 있는 코드 값을 접두어로 붙여달라는 곳들이 꼭 있어서, 쿼리에 직접 sequence 를 썼다가는 변경이 발생할 경우 손댈 곳이 많아질 수 있다. 데이터 insert 하는 곳이 꼭 한 군데라는 법은 없으니까. 그렇기 때문에 sequence 를 쓸 때는 꼭 별도 매퍼로 만들어 그 값을 리턴하는 메서드를 만들 후 그것을 가져다 쓰도록 만드는 것이 좋다. 그런 환경에서 일해 왔으니 MyBatis 를 쓰면서도 useGeneratedKeys 옵션을 써본 적이 없다. 사실 아직도 어색하다...

MySQL 을 쓰는 곳에서 일했을 때는, PK 가 서너 개 이상 많아질 경우에는 auto_increment 컬럼을 유일 PK 로 설계하는 그런 곳이었다. MySQL 은 sequence 가 없다보니 PK가 auto_increment 컬럼인 부모 테이블에 insert 하면서 자식 테이블에도 동시에 insert 할 경우 useGeneratedKeys 옵션을 쓸 수밖에 없다. 근데 이상하다. 지금 난 Oracle 쓰고 있는데. useGeneratedKeys 옵션도 쓴 적 없고..? 혹시나 해서 다시 <insert> 태그로 바꾼 다음 useGeneratedKeys 속성을 false 로 넣어주고 해보니까 이상없이 잘 되었다. 흠 근데 이거 디폴트가 true 란 얘긴가?

아 잠깐, 이거 기본 configuration 으로 설정되어 있나보다, 하는 생각이 문득 들어서 MyBatis config xml 파일을 보니까 역시나 useGeneratedKeys 옵션이 true 로 설정되어 있었다. 그래서 false 로 바꾸고 다시 해보니까 <insert> 태그로 insert into ~ select 를 해도 문제없이 잘 되었다. 이런 건 놓치기 쉽단 말이지. 기본 설정은 한 번 해놓으면 몇 년씩 그대로 아무 생각없이 복붙해서 쓰니까. 아마 MyBatis 는 <insert> 태그일 때만 useGeneratedKeys 기본 설정을 자동으로 적용시키는 것 같다. 재미있는 것은, 혹시나 해서 <update> 태그로 하고 수동으로 useGeneratedKeys 속성을 true 로 해줬더니 실제로 적용이 되어버려서 에러가 났다. 야 이거 update 일 때는 적용 안되게 막아야지 ㅋㅋ

<configuration>
    <settings>
        <setting name="cacheEnabled" value="false" />
        <setting name="lazyLoadingEnabled" value="true" />
        <setting name="aggressiveLazyLoading" value="true" />
        <setting name="useGeneratedKeys" value="false" />
        <setting name="defaultExecutorType" value="REUSE" />
        <setting name="mapUnderscoreToCamelCase" value="true" />
        <setting name="callSettersOnNulls" value="true"/>
        <setting name="jdbcTypeForNull" value="VARCHAR" /><!-- NULL, OTHER, VARCHAR -->
    </settings>
</configuration>

근데 아직도 의문점이 있다. 이 옵션이 왜 단 건 insert 는 문제 없는데 여러 건 동시 insert 할 때만 문제가 되는 걸까? API 를 다시 찾아봤는데 문제될 것이 없었다. 왜냐하면, PreparedStatment 의 getGeneratedKeys 메서드는 리턴 타입이 ResultSet 이기 때문이다. 당연히 여러 건을 리턴할 수 있다. 근데 왜 에러나지? 간단히 테스트 코드를 작성해서 Oracle 와 MariaDB 로 비교해보았다. MariaDB 는 여러 건 동시 insert 할 경우에도 auto_increment 컬럼 값을 잘 가져왔다. Oracle 일 때만 문제가 되는 것 같다. MSSQL 은 안해봤지만 왠지 걔도 문제 없을 것 같은 느낌이 든다.

DB 벤더라면, JDBC API 에 정의된 기능이 잘 수행되도록 드라이버를 만들어야 한다. 그게 개발자들과의 약속 아닌가? 근데 Oracle 이 그게 안된다는 건 계약 위반이다! API 명세를 따라야지 왜 지원을 안해주는 건데...아마 애초에 DB 설계가 그렇기 때문이 아닐까 싶기도 하다. Oracle 은 sequence 객체의 CURRVAL 속성으로 현재 값을 가져오는 방식이다. 여러 건 동시 insert 하면서 NEXTVAL 사용 가능하지만, 이후 CURRVAL 을 쓰면 마지막 채번된 값 하나만 가져온다. 그 외 insert into ~ values ~ returning ~ into ~ 구문도 있으나, 이 역시 단 건 insert 전용이다. 일단 현재까지 알아본 바로는, Oracle 은 복수 건 insert 시 자동 증가 채번 값을 여러 개 가져오는 기능 자체가 없는 것 같다. 그렇다면 JDBC API 의 getGeneratedKeys 메서드도 당연히 명세대로 제대로 구현할 수 없다. 그래, 명세대로 정확히 구현할 수 없는 것을 그냥 되는대로 할 수 있는 데까지만 구현해 놓느니, 차라리 에러를 내버리는 게 낫지. 정 필요한 경우라면 개발자들이 뭔가 다른 방법을 찾을테니까. MySQL(MariaDB) 은 SELECT LAST_INSERT_ID() 하면 마지막 인서트한 auto_incerement 컬럼 값을 가져오고, 만약 복수 건 insert 한 후라면 그 중 가장 먼저 insert 된 행에서 그 값을 가져온다. 그래서 어떻게든 API 를 구현할 수 있었던 것 같다. 여기까지 나름대로의 결론. 더 이상은 알 수 없음.

결론. MyBatis 기본 configuration 설정에서 useGeneratedKeys 옵션을 true 로 하지 말 것. 꼭 필요할 때만 <insert> 태그에 true 로 속성 값을 수동으로 지정해주자.

DB 프로시저 VS 자바 프로그래밍, 논쟁 후 드는 생각들

뻔돌이 — Tue, 20 Dec 2022 15:42:59 +0900

웹 개발 환경과 기술이 날로 복잡해지고 변화 속도가 점점 빨라지고 있다. 말 그대로 격변의 연속이다. 경력이 많아질수록 실력이 발전하여 여유가 생겨야 마땅한데, 요즘은 뭐 하나라도 몇 년 경험을 쌓아서 좀 안다 싶을 정도가 되면 벌써 새로운 게 나와서 케케묵은 것이 될 정도이다. 예전에 신입들 가르칠 때는 기초 원리와 개념 학습을 통한 응용력 향상을 위해 프레임웍 없는 쌩짜 서블릿과 JDBC 부터 가르쳤는데, 요즘은 그냥 곧바로 스프링, 아니 스프링부트부터 가르친다. 공부할 게 너무 많아서 학교도 학원도 아닌 회사에서 그런 기초부터 가르치기에는 시간이 너무 없다. 사실 나도 많이 까먹었기도 하고. 기술 영역이 점점 세분화되고 전문화되어 뭐 하나라도 간단히 배울 수 없는 이 시대에, 풀스택 어쩌구 하는 말을 들으면 개소리로 들린다. 시스템이 복잡해지는만큼 업무가 더욱 분업화되기 때문에 각 파트 담당자들의 주장이나 의견을 찰떡같이 알아들어 갈등을 해소하고 올바른 결정을 내려 전체 조직이 잘 통합되도록 하기 위해서는 관리자나 리더가 이것 저것 다 조금씩 알아야 할 필요는 있다. 그러나 실무 담당자가 풀스택이길 바라는 것은 지나친 욕심이다.

시간은 부족한데 배워야 할 건 많고, 기초를 건너뛰고 원리도 모른채 달달 외워야 하는 요즘 프로그래밍. 전문 기술인데도 마치 암기 과목이 된 듯 하다. 그런만큼 기술을 깊이있게 제대로 아는 사람은 점점 줄어들고, 갈수록 더 소수의 집단이 기술을 독점하고 있다. 그들은 참으로 지칠 줄 모르는 열정과 체력을 가졌나보다. 그들이 무자비하게 쏟아내는 신기술을 배우고 익히는 것은 이제 포기했다. 새로운 것을 배우는 것이 힘든 이유는, 지금까지 알고 있던 것과 너무 달라서 뇌구조를 변경해야 하기 때문이다. 그러니까 수년간 혹은 십수년간 때로는 수십년간 쌓아온 내가 가진 것들과 지금까지 성장해왔던 나를 잠시 땅 속에 묻고 이제 막 새로 태어난 아기가 된 마음가짐으로 다시 시작하여 변화에 적응해야 가질 수 있는 것이 신기술이다. 나보다 한참 어리고 경험과 경력도 적은 것들, 아니 분들한테 고개를 숙이고 배워야 한다. 그것은 기회이기 보다는 위협으로 받아들여지기 쉽다. 사람은 희망보다 위협을 느끼면 자기 것을 지키기 위해 방어하고 더 벽을 쌓는다. 그런 자들은 새로운 것을 배울 때 사소한 거 하나 하나를 기존 것과 비교하며 나쁜 점을 찾으려 든다. 그렇게 과거에 머문 이들과 이제 막 시작하는 이들이 뒤섞여 있는 IT 업계는 회사 혹은 개발자들의 기술 격차가 엄청나게 크다. 그들이 만나면 뜨거운 논쟁이 벌어진다.

사실 개인적인 경험에 비춰 생각해보면, 고리짝 기술로 개발된 시스템이라고 해서 최신 기술로 무장한 시스템보다 품질이 현격히 떨어지는 것은 아니다. 품질이란 평가 기준이 여러가지 있겠지만, 대략 중요한 것을 뽑자면 기능, 성능, 보안성(개인정보, 사용자 권한, 소스), 유지보수/생산성, 비용 등을 들 수 있다. 시스템 품질 평가는 평가하는 사람의 개인적인 경험이나 목적에 따라, 그리고 시스템 규모에 따라 기준과 방법이 달라질 수 있다. 신기술은 이러한 시스템 품질 항목들을 개선하기 위해 발전하는 것이다. 이 신기술들이 목표로 삼는 시스템들은 대체로 규모가 크고 복잡한 것들에 해당한다. 대체로 시스템 규모가 작을수록 신기술의 필요성은 떨어진다. 시스템 규모가 클수록 신기술을 받아들일 필요가 있다는 것인데, 신기술은 구축 유지 비용이 비싸다. 시스템 구축 유지에 드는 비용 중 가장 큰 비중을 차지하는 것은 인건비인데, 신기술은 영역이 세분화되어 있어 더 많은 사람이 필요하다. 기술이 발전하면 인건비가 줄어들 것 같지만 IT 분야는 오히려 반대다. 더 많은 전문 인력이 필요하고 더 좋은 장비가 필요하기 때문에 비용이 더 많이 든다.

개발자들 입장에서야 시스템 품질을 생각할 때 비용을 별로 생각하지 않지만, 시스템 구축 관리를 의뢰하고 돈을 내는 입장인 고객들은 비용을 매우 매우 중요하게 생각한다. 그게 신기술 도입의 딜레마이다. 이미 오래 전 엄청나게 크고 복잡한 시스템을 엄청난 비용을 들여 구시대의 기술로 구축해놓았고 그럭저럭 잘 쓰고 있다면, 아무리 좋은 차세대 시스템이라고 해도 또 다시 엄청난 비용을 들여 새로 구축하기는 쉽지 않은 일이다. 들어가는 시간과 비용, 기대되는 품질 향상을 따져볼 때 반드시 꼭 그래야하는 경우는 드물다. 게다가 시스템을 새로 만들면 조직원들이 새로운 시스템 사용법을 배우고 적응해야 한다. 그 또한 쉬운 일이 아니다. 그래서 보통 규모가 큰 회사들의 업무 시스템은 한 번 구축하면 적어도 10년 이상 쓴다. 정 안되겠다 싶으면 차세대를 하기 전에 고도화를 먼저 고려한다. 버틸 수 있을 때까지 버티는 것이다. 아무리 사업하는 사람들이 그렇게 짜다고 해도 대기업은 대기업이다. 쓸 땐 통 크게 쓴다. 그들 덕분에 비싼 개발자들이 비교적 많은 돈을 벌어먹고 산다. 개발자인 내가 봐도 대기업이 시스템 구축 유지 관리에 쓸데없이 여기 저기 돈을 쓴다는 생각이 들 때가 있다.

작은 회사는 시스템 규모가 작기 때문에 굳이 신기술을 적용하여 복잡하게 만들 필요가 없다. 상대적으로 구시대 기술이 구조가 단순하고 새로운 전문 인력을 수급하지 않고 기존 인력을 활용할 수 있기 때문에 비용도 적게 든다. 사실 작은 회사는 IT 부서가 없거나 있다 해도 직접 시스템 개발 유지하기 보다는 외주사에 맡기는 경우가 많아 기술 트렌드에 그리 민감하지 않은 편이다. 또한 작은 회사일수록 비용을 최우선으로 생각하기 때문에 저렴한 외주사를 찾기 마련이다. 저렴한 개발사가 최신 기술로 무장한 전문 인력을 보유하는 경우는 거의 없다. 작은 회사는 시스템 규모가 작기 때문에 뒤엎고 새로 만들기도 쉬울 것 같지만, 그게 또 그렇지 않다. 시스템 구축 비용이 적게 든다고 해도 매출 규모 또한 적기 때문에 그들 입장에서는 싼 게 싼 게 아니다. 단순한 모바일 앱 하나라도 만들려면 네이티브 앱이면 안드로이드와 IOS 개발자, 하이브리드면 거기에 추가로 프론트엔드 웹 개발자가 필요하고, 거기에 백엔드 개발자, DB 설계 개발, 서버 관리 등 별도로 프로젝트 관리자 없이 개발자만 투입한다고 해도 최소 서너명에 살인적인 일정으로 3개월 잡아도 인건비 억대가 훌쩍 넘어가고, 디자이너가 추가로 필요할 수도 있는데다가, 개발 후 유지보수도 비슷한 비용이 들어가는데, 사업을 막 시작하는 사람들은 많아봤자 오천만원이면 떡을 칠 거라고 생각하는 경우가 태반이다. 그들에게 실상을 말해주면 사기를 치는 줄 안다. 그런 사람들이 신기술 적용하겠다고 돈을 쓰겠는가?

IT 기술이 아무리 변한다고 해도 실제 그것을 사용하는 세상은 이런 식으로 돌아가기 때문에 과거에 머문 이들이 버티고 살아남고 있는 것이다. 그러니 자바 프로그래밍을 거부하고 DB 프로시저를 선호하는 곳이 아직도 있다는 것이 놀라운 일은 아니다. 바로 우리 회사다. DB 프로시저가 더 좋으냐, 자바 프로그래밍이 더 좋으냐로 싸우는 것은 아주 오래된 일인데, 의외로 아직도 이 문제로 싸우는 곳이 많은 것 같다. 검색해보면 각각 장단점 비교하는 그리 오래되지 않은 글들을 심심치 않게 볼 수 있다. 내가 처음 개발자로 일하기 시작할 때는 오라클 DB에 프로시저로 개발하는 경우가 많았다. 그 당시에는 복잡한 업무는 거의 프로시저로 작성했었다. 그래서 SQL 작성 능력이 매우 중요했다. 고정된 소규모 인원이 장기간 유지 관리하고 변화가 별로 많지 않은 시스템이라면 프로시저가 나쁘지 않다. 그러나 대규모 인원에 이동이 잦거나 수정 추가 등의 변화가 많은 시스템이라면 프로시저로 개발할 경우 유지 관리하기가 매우 힘들다. 그래서 어느 정도 규모가 있는 회사들은 예전부터 프로시저를 금지했었고, 심한 경우 사용자 정의 함수 작성도 금지했었다. 더군다나 클라우드가 대세가 된 요즘은 그 경향이 더 커지고 있다.

신입 시절 한 2년 정도는 프로시저 위주로 개발했다가 이직 후 디자인 패턴을 공부하고 여러가지 개발 방법론에 관심을 가지게 되고 어떻게 해야 객체지향적인 프로그래밍을 할 수 있을까 고민하기 시작하면서부터 프로시저는 멀어지게 되었다. 그러다보니 점점 프로시저의 단점이 많이 보이기 시작했다. 그 후 지금 회사에 입사해서 R&D 부서에 들어왔는데 솔루션이 너무 오래되어 개선을 추진하고 있다. 팀 내부에서는 시스템 주요 로직이 프로시저로 개발되어 있는 것을 자바로 바꾸기로 했는데, 프로젝트 수행 사업부에서는 반발하고 있다. 프로시저가 더 좋은데 왜 자바로 개발하냐는 것이다. 특히 PM 들이 말이 많은데, 그들이 자바를 반대하는 가장 큰 이유는 성능이다. 개인적으로는 그건 핑계고 사실은 자기들이 개발에 관여하고 싶은데 자바는 잘 모르고 프로시저는 좀 아니까 그렇게 주장하는 것 같다는 생각이긴 하지만.

프로시저로 개발하는 게 자바로 개발하는 것보다 성능 면에서 유리하다는 것은 반만 맞는 말이다. 프로시저는 콜하면 여러 쿼리가 DB 서버 내에서 수행되는 반면, 자바로 로직을 구현하면 쿼리를 수행할 때마다 DB 서버와 어플리케이션 서버간 네트워크 I/O 에 추가 시간이 필요한 건 맞다. 하지만 자바를 자바답게 객체지향으로 개발하면 프로시저와 로직이 완전히 달라진다. 당연히 수행하는 쿼리문도 달라지고, 쿼리 수행 횟수도 줄일 수 있다. 자바를 자바답게 개발하고 비교해야지, 프로시저 소스 코드를 쿼리까지 그대로 똑같이 자바 소스로 옮겨놓고 성능 비교를 하는 것은 바보짓이다. 예를 들어 급여나 연말 정산, 상품 주문 재고 할당 등 엄청나게 복잡한 업무 같은 경우 프로시저로 개발하면 프로세스 단계별로 여러 개의 프로시저로 나누어서 개발하고 각종 옵션과 예외 상황 등 업무 설계에 따라 한 건 처리하는 데 수행되는 쿼리문 수가 수백 수천 개에 다다르기도 한다. 때로는 데이터 조회 쿼리문 한 개가 수백 수천 라인이 되기도 한다. 쿼리문 잘못 짜면 성능이 심각하게 떨어진다. 반면 자바로 개발하면 쿼리문이 단순해진다. 로직은 자바로 구현하기 때문에 복잡한 쿼리문을 짤 일이 없다. 그러니 성능이 심각하게 떨어질 쿼리를 짤 일도 없다. 잘 변경되지 않는 기준 정보는 캐싱을 이용해 반복 조회하는 시간을 절약할 수 있다. 복잡한 로직 없이 단순히 CRUD 쿼리만 반복되는 작업을 프로시저와 자바로 구현하고 소요 시간 비교한 것을 근거로 프로시저가 더 성능면에서 좋다고 주장하는 사람들도 많은데, 그 사람들이 내 앞에 있다면 바보짓 그만 하라고 얘기해주고 싶다. 쌩짜 JDBC 로 작성해도 addBatch, executeBatch 쓰면 대량 데이터 CUD 작업도 순식간인데 뭔 소리야. 사실 엄청난 대량 데이터가 아니고서야 네트워크 I/O 시간은 거의 무시해도 될 수준이다. 1분 1초가 아쉽다면 또 모를까. 더군다나 그런 사람들이 테스트할 때 자바 어플리케이션에서 로깅을 어떻게 하고 있는지는 얘기도 안꺼낸다. 로깅도 꽤나 시간을 많이 잡아먹는 놈이다. 그러니까 확실히 성능 비교하려면 로깅도 꺼야 한다.

또한 우리는 품질을 다각도에서 고민해야지, 한 가지만 가지고 판단해서는 안된다. 그래서 여러 면에서 프로시저와 자바를 비교하여 회의 자료로 제출한 것을 정리해 보았다. 선정한 항목은 크게 기능, 성능, 보안성, 유지보수성, 생산성, 비용으로 구분 후 각각 세부 사항을 뽑았다. 표로 정리하면 좋겠지만 화면이 좁아서 항목별로 나열했다.

● 기술적 차이

자바 : 컴파일된 소스를 어플리케이션 서버에 배포하여 실행하는 객체지향 프로그래밍. 비교적 간단한 쿼리로 데이터를 조회한 후 자바 객체를 이용해 로직을 구현함.

프로시저 : DB 서버에서 소스를 컴파일 후 실행하는 절차지향 프로그래밍. 쿼리 집합. 순차적으로 쿼리를 수행하여 로직 구현. 문법이 DBMS 마다 다르다.

● 성능/부하 관련

자바 :

- 어플리케이션 서버의 사양에 영향이 크고 DB 서버 사양에 비교적 덜 영향받는다.

- 쿼리 성능 외에 네트워크 IO 횟수에도 영향을 받는다.

- 객체지향다운 구현과 단순하고 효율적인 쿼리를 사용하여 DB 접속 네트워크 I/O 횟수를 줄이는 것이 좋다.

- 수행 쿼리 로그를 콘솔과 파일로 남길 경우 그를 위한 추가 자원과 시간이 필요하다. 네트워크 I/O 보다 로깅이 더 많은 시간을 잡아먹는다. 최신 로깅 라이브러리가 지원하는 비동기 로깅을 고려해볼 수 있다.

- 캐싱 기법으로 동일 쿼리 재수행을 최소화할 수 있다.

- 멀티 쓰레드를 활용하여 성능 향상을 기대할 수 있다. 단, 데드락에 주의해야 함. 또한 스프링 트랜잭션 전파는 멀티 쓰레드에 적용되지 않는다는 것도 주의.

- 성능 이슈가 발생할 경우 로깅 파일 살펴보면 응답이 느린 쿼리를 찾아내기 쉽다.

프로시저 :

- DB 성능이 매우 중요하다. 그러므로 DBMS 선택도 중요하고 DB 서버 사양도 중요함.
- 로직이 복잡할 경우 복잡한 쿼리를 사용하게 되어 쿼리 작성 실력과 튜닝이 더욱 중요해짐.
- 트랜잭션 격리 수준에 따라 다르지만, 동일 쿼리 반복 수행시 실제로 데이터를 조회하므로 비효율적인 쿼리 수행이 많음.

- 프로시저 자체에서 멀티쓰레드를 지원하진 않지만, 어플리케이션에서 멀티 쓰레드로 프로시저를 실행할 수는 있다.

- 성능 이슈가 발생할 경우 프로시저 내에서 속도가 느린 쿼리를 찾아내기 어렵다. DB 관리자의 지원이 절대적으로 필요.

● 형상관리 (버전관리)

자바 : IDE 툴을 통해 모든 소스가 SVN, GIT 등으로 형상 관리가 되고 그것이 그대로 서버에 배포되므로 변경 추적과 원복이 용이하다. 동시에 같은 소스를 다른 개발자가 따로 수정할 경우 conflict 오류가 발생하여 서로 알아채고 merge 하기 쉽다.

프로시저 : 별도로 소스 변경 내역을 수동으로 백업하며 관리하여야 하고 그것이 DB 서버에 실제로 반영되었음을 보장하지 않으므로 변경 추적과 원복이 어렵다. 동시에 같은 소스를 다른 개발자가 따로 수정할 경우 아무런 오류 없이 나중에 컴파일된 소스가 반영되므로 서로 알아채기 어렵다.

● 배포관리

자바 : 변경 소스를 반영하기 위해 어플리케이션 서버를 무중단 서버로 구축하거나 재시작 해야한다.

프로시저 : DB 에서 프로시저 컴파일만 하면 되므로 권한이 있는 사람이면 아무 때나 수정 배포할 수 있다. 단, 어플리케이션 서버에서 콜하는 프로시저이고 파라미터 갯수나 타입 등이 바뀔 때에는 어플리케이션 소스도 변경 배포되어야 하므로 두 작업이 되도록 동시에 이루어지도록 타이밍을 잘 맞추어야 한다.

● 디버깅/테스트

자바 : 개발자들이 개발시 사용하는 IDE 툴로 쉽게 디버깅이 가능하다. 로깅 설정으로 로그 파일을 남기면 실제 수행된 쿼리와 바인딩된 변수 확인이 가능하므로 운영 환경에서도 문제 추적이 용이하다. 소스 일부 테스트와 테스트 자동화가 용이하다.

프로시저 : 디버깅 지원하는 DB 툴이 있어야 하며, 파라미터를 수동으로 입력하고 실행하여 디버깅을 해야 한다. 잘못된 파라미터 입력으로 버그나 오류가 발생했는데 애꿎은 프로시저만 디버깅하느라 삽질하는 경우가 종종 있다. DB 서버 자체에 쿼리 수행 로그가 남지만 개발자에게 접근 권한을 주는 경우는 거의 없으므로 운영 환경에서 문제 추적이 어렵다. 프로시저 내에 특정 부분만 테스트할 수 없고 프로시저 단위로 수행해야 하므로 테스트 자동화가 까다롭다.

● 에러 처리

자바 : 다양한 추상화 기법으로 일관된 에러 메시지 생성과 처리가 용이함.

프로시저 : 발생한 에러 메시지를 어플리케이션에 OUT 변수로 전달해야 한다. 경우에 따라 어플리케이션에서는 이를 다시 특정 Exception 으로 포장하거나 분기 처리해야 하므로 비교적 다루기 복잡함.

● 트랜잭션 관리

자바 : 스프링 등의 선언적 트랜잭션 관리 기법으로 코딩이 아닌 설정을 통한 다양한 트랜잭션 전략 활용 용이하고, 그에 따라 트랜잭션을 조건에 따라 다양하게 옵션화할 때도 동일한 소스를 수정없이 재사용할 수 있다. 단, 일부 특수한 트랜잭션 설정은 DBMS 에서 지원해주는 것만 가능하다.

프로시저 : 기본적으로 어플리케이션에서 트랜잭션을 관리하지만, 프로시저에서 수동 커밋 롤백이 가능함. 프로그래밍적으로 직접 커밋 롤백 명령문을 작성해야 하므로 트랜잭션 분리 전략을 다양하게 활용하기 어렵다.

● DB 의존도

자바 : 특정 DBMS 특화 문법이나 함수 사용을 지양하고 표준 ANSI SQL 위주로 개발하면 DB 의존도를 최소화하여 변경 비용을 크게 줄일 수 있다.

프로시저 : DBMS 마다 프로시저 문법이 다르므로 의존도가 매우 높다. 양이 많고 복잡하다면 한 번 프로시저로 개발하면 DBMS 변경이 현실적으로 거의 불가능하다.

● 소스 보안 (안티 리버싱)

자바 : 자바 특성상 디컴파일이 쉽기 때문에 완벽한 비공개가 어렵다. 전문 상용 난독화 툴을 적용하면 분석이 거의 불가능하게 만들 수 있기는 하다.

프로시저 : DBMS 에 따라 자체 제공하는 소스 암호화 방법이 있다. 그 외 접근 제한을 통해 소스를 보호할 수도 있다.

● 개발/수정 생산성

자바 : 객체지향 개발 특성상 개발 초기에는 자바 소스를 여럿 작성해야 해서 시간이 걸리지만, 일단 개발이 완료되고 나면 수정 변경에 유연하고 견고한 시스템을 구축할 수 있다.

프로시저 : 개발 초기에는 프로시저만 작성하면 되어 금방 만들 수 있지만, 절차 지향 특성상 로직이 복잡해지고 소스가 길어질수록 점점 수정 변경이 어려워지고 리스크가 커진다.

※ 결론

프로시저 개발보다 자바 개발이 유리한 점이 많다. 다만 소규모 시스템에 기능 추가나 수정이 많지 않고 적은 인원이 장기간 유지 보수하는 경우라면 프로시저로 개발하는 게 더 편할 수 있다. 그 외의 경우라면 자바로 개발하는 것이 바람직하다. 프로시저와 자바의 성능 비교는 무의미하다고 볼 수 있다. 어지간한 대용량 데이터 일괄 처리가 아닌 한 네트워크 I/O 는 문제가 될 정도로 큰 차이는 없다. 자바로 개발시 수행 쿼리 로깅은 문제가 될 정도로 많은 시간을 지연시킬 가능성이 있긴 하나, 디버그와 에러 추적이 용이해지고 느린 쿼리를 찾기 쉽다는 이점도 있다. 성능 저하를 최소화하고 이점을 가져가기 위해 로깅을 비동기로 설정하는 것을 고려해볼 수 있다.

MySQL + MyBatis + log4jdbc 에서 괴상한 버그 발견..

뻔돌이 — Sat, 24 Apr 2021 01:21:25 +0900

최근 업무 중 여태껏 한 번도 마주치지 못한 괴상한 버그, 음 버그라고 하는 게 맞을 지는 모르겠지만, 아무튼 좀 어이없는 녀석을 만나 기록해둔다.

목록 조회 쿼리 수행시 다음과 같은 에러 발생.

### Error querying database. Cause: java.lang.NullPointerException

### The error may exist in file [...매퍼 xml 파일 경로...]

### The error may involve ...매퍼 java interface 메서드 경로...

### The error occurred while handling results

### SQL: ...쿼리...

### Cause: java.lang.NullPointerException

개발자의 영원한 친구 NullPointerException! 별 거 아닌 놈인데 이 경우는 달랐다. 이게 발생할 이유가 도저히 없는 부분이었다. ResultSet 을 지정한 타입으로 매핑하는 도중 발생한 것인데, 이건 뭐 내가 직접한 것도 아니고 MyBatis 가 알아서 해주는 건데 거기서 이게 나올 일이 뭐가 있단 말인가?

일단은 콘솔에 찍힌 쿼리를 Heidi 에서 돌려보았다. 몇몇 컬럼 값이 null 인 행들이 있었다. 거의 본능적으로 그것들이 문제라는 것을 직감하고 해당 컬럼들을 IFNULL 로 감싸서 null 이면 빈문자열을 리턴하도록 쿼리를 변경했다. 일단은 그렇게 해서 Exception 은 해결되었다. 그런데 MyBatis 를 사용하면서 조회 목록 컬럼 값이 null 이어도 이런 일이 발생한 적은 한 번도 없었다. 상식적으로 생각해봐도 그런 일이 발생하면 안된다! 그런데 유독 그 쿼리에서만 이런 일이 발생했다. 왜일까...

예외 발생한 부분을 StackTrace 로 찍어보았다.

Caused by: java.lang.NullPointerException
	at net.sf.log4jdbc.sql.resultsetcollector.DefaultResultSetCollector.methodReturned(DefaultResultSetCollector.java:112)
	at net.sf.log4jdbc.sql.jdbcapi.ResultSetSpy.reportAllReturns(ResultSetSpy.java:100)
	at net.sf.log4jdbc.sql.jdbcapi.ResultSetSpy.reportReturn(ResultSetSpy.java:192)
	at net.sf.log4jdbc.sql.jdbcapi.ResultSetSpy.wasNull(ResultSetSpy.java:2497)
	at org.apache.ibatis.type.BaseTypeHandler.getResult(BaseTypeHandler.java:70)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.applyAutomaticMappings(DefaultResultSetHandler.java:498)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.getRowValue(DefaultResultSetHandler.java:385)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValuesForSimpleResultMap(DefaultResultSetHandler.java:339)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValues(DefaultResultSetHandler.java:314)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSet(DefaultResultSetHandler.java:287)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSets(DefaultResultSetHandler.java:183)
	at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:64)

MyBatis 가 아니라 log4jdbc 에서 발생한 것이었다. 아래서부터 소스를 따라가보니, MyBatis 가 쿼리를 날리고 받아온 ResultSet 을 매퍼에서 지정한 타입으로 매핑할 때 특정 컬럼 값이 null 이면 뭔가 문제가 발생한 것이다. 일단은 무엇이 null 인지 보려고 DefaultResultSetCollector 를 까보았다. IntelliJ 님은 java 소스가 없어도 class 파일을 참 깔끔하게 디컴파일 해주신다.

public boolean methodReturned(ResultSetSpy resultSetSpy, String methodCall, Object returnValue, Object targetObject, Object... methodParams) {
    if (methodCall.startsWith("get") && methodParams != null && methodParams.length == 1) {
        String methodName = methodCall.substring(0, methodCall.indexOf(40));
        if (GETTERS.contains(methodName) && this.getColumnCount() != 0) {
            this.setColIndexFromGetXXXMethodParams(methodParams);
            this.makeRowIfNeeded();
            this.row.set(this.colIndex - 1, returnValue);
        }
    }

    if (methodCall.equals("wasNull()") && this.getColumnCount() != 0 && Boolean.TRUE.equals(returnValue)) {
        this.row.set(this.colIndex - 1, "[null]");
    }
    //중략...
}

흠, 두번째 if 문에서 this.row 가 null 이어서 set 할 때 NullPointerException 이 발생한다는 건데...인스턴스 변수로 선언된 이 놈의 타입은 java.util.List 였다. 그렇담 이걸 언제 생성해주지? 찾아보니까 바로 위의 if 문 this.makeRowIfNeeded() 메서드에서만 유일하게 this.row 를 생성해주고 있었다. 그러니까...첫번째 if 문과 그 안쪽의 if 문 두 개를 다 통과하지 못한 상태에서 두 번째 if 가 true 면 NullPointerException 이 발생할 수밖에 없단 얘기네. debug 모드로 확인하기 귀찮아서 그냥 맨 윗줄에 System.out.println 으로 파라미터 methodCall 를 찍어보았다. 그랬더니 이렇게 찍혔다.

new ResultSet
getMetaData()
getType()
next()
getClob(...컬럼명/Alias...)
wasNull()
getClob(...컬럼명/Alias...)
wasNull()
...이하 이런식...

그리고 GETTERS 는 이렇게 선언되어 있었다. getClob 이 없다! 그러니까 첫번째 컬럼부터 연속으로 Clob 타입 컬럼이 있는데 그러다가 그 중 값이 null 인 게 있으면 wasNull 로 null 여부 체크를 할 때 NullPointerException 이 발생하는 것이다!

private static final List<String> GETTERS = Arrays.asList("getString", "getLong", "getInt", "getDate", "getTimestamp", "getTime", "getBigDecimal", "getFloat", "getDouble", "getByte", "getShort", "getObject", "getBoolean");

이상한 건, 내가 조회한 테이블은 Clob컬럼이 없었는데 Clob 타입으로 인식된 컬럼이 있다는 것이었다. 그건...Subquery 였다. 여러가지로 더 테스트 해봤는데, Scala Subquery 가 모두 Clob 타입인 건 아니었다. 어떤 경우는 String 타입으로 찍혔다. 컬럼의 데이터 타입은 MyBatis 가 맘대로 하는 것이 아니라 ResultSet 의 MetaData 에 따라 정해진다. 근데 그건 DB 가 알려주는 건데...흠 MySQL 거 참 이상한 놈이네...같은 서브쿼리인데 어떨 때는 Clob 타입이고 또 어떨 때는 String 타입이고 이랬다 저랬다야...

DefaultResultSetCollector 는 jdbc.resultsettable logger 를 활성화할 때 사용되는 것 같다. 아래는 ResultSetSpy 소스 일부이다. 생성자에서 DefaultResultSetCollector 를 만드는 조건은 this.log.isResultSetCollectionEnabled() 가 true 일 때인데, 이게 jdbc.resultsettable logger 옵션인 거 같다.

 public ResultSetSpy(StatementSpy parent, ResultSet realResultSet, SpyLogDelegator logDelegator) {
    if (realResultSet == null) {
        throw new IllegalArgumentException("Must provide a non null real ResultSet");
    } else {
        this.realResultSet = realResultSet;
        this.parent = parent;
        this.log = logDelegator;
        if (this.log.isResultSetCollectionEnabled()) {
            this.resultSetCollector = new DefaultResultSetCollector(this.log.isResultSetCollectionEnabledWithUnreadValueFillIn());
        }
        this.reportReturn("new ResultSet", "", realResultSet);
    }
 }
    
protected void reportAllReturns(String methodCall, Object returnValue, Object... methodParams) {
    if (this.resultSetCollector != null) {
        boolean finished = this.resultSetCollector.methodReturned(this, methodCall, returnValue, this.realResultSet, methodParams);
        if (finished) {
            this.log.resultSetCollected(this.resultSetCollector);
            this.resultSetCollector.reset();
        }
    }
    String toString = "void";
    if (returnValue != null) {
        toString = returnValue.toString();
    }
    this.log.methodReturned(this, methodCall, toString);
}

jdbc.resultsettable 는 조회 결과 데이터를 표 모양으로 이쁘게 로깅하는 logger 옵션이다. ConsoleAppender 를 사용하면 개발할 때 따로 쿼리를 DB 툴에서 날려보지 않아도 콘솔에 조회 결과 데이터가 바로 찍히니 편할 때가 있다. 형상관리 서버에서 프로젝트 소스를 내려받을 때부터 ConsoleAppender 와 RollingFileAppender 둘 다 사용하도록 이 옵션이 활성화된 상태였는데, 목록 갯수가 많은 걸 조회할 때는 너무 버벅거려서 ConsoleAppender 설정을 지우고 사용하고 있었다. 아예 jdbc.resultsettable 옵션을 끄고 다시 테스트해보니까 NullPointerException 이 발생하지 않았다..

결론. 테스트 결과 아래와 같은 조건에서 이런 어이없는 NullPointerException 이 발생했다는 것을 확인했다.

log4jdbc 를 사용, 로깅 옵션을 활성화하고 jdbc.resultsettable 까지 설정하면 조회 결과 목록을 로그로 남기기 위해 DefaultResultSetCollector 가 사용된다.

이 때, MyBatis 를 이용하여 데이터 조회할 때 첫번째부터 데이터 타입이 Clob 으로 인식되는 컬럼들이 연속으로 이어지고 그 중에 값이 null 인 게 있으면, DefaultResultSetCollector 에서 NullPointerException 이 발생한다.

MySQL 셀렉트문 컬럼이 Scala Subquery 일때 간혹 Clob 타입으로 인식되는 경우가 있다.

그러면 이럴 때 해결 방법은...

log4jdbc 로깅 옵션에서 jdbc.resultsettable 를 끈다.

혹은, 데이터 타입이 DefaultResultSetCollector 의 GETTERS 목록에 포함된 컬럼을 셀렉트문 첫번째에 둔다.

기싱꿍꼬또

뻔돌이 — Sat, 6 Mar 2021 14:22:20 +0900

어린 아이들은 궁금한 게 참 많다. 이게 뭐에요? 저건 뭐에요? 그건 왜 그래요? 왜 안되요? 왜요? 물어보고 또 물어보고 계속 물어보는 탐구자. 그들에게 의심이란 것이 생기기 시작하면서 가지게 되는 공통된 질문이 몇 가지 있다. 그 중 하나. 산타 할아버지는 진짜로 있을까? 사람마다 다르겠지만, 산타 할아버지는 이 세상에 존재하지 않는다는 사실을 대부분의 사람들이 꽤나 일찍 깨닫게 된다. 일곱살 때쯤인 거 같다. 누군지는 기억이 안나지만 누군가가 나에게 산타 할아버지는 없다고 말해줬다. 사실은 부모님이 선물을 사다주는 거라고. 그 뒤 크리스마스 아침 아버지가 산타 할아버지가 냉장고에 선물을 놔뒀다고 해서 열어봤더니 크런키 초코렛이 몇 개 있었다. 애걔...하며 실망했던 기억이 난다. 산타 할아버지한테가 아니라 부모님한테. 또 다른 질문. 귀신은 정말 있을까? 귀신은 산타 할아버지와는 많이 다르다. 귀신이 있는 것 같으면서도 없는 것 같기도 하고 아무래도 없는 것 같지만 그래도 혹시 있을 지 모른다는 생각은 꽤나 오래 간다. 유물론자이며 무신론자인 나는 영혼이나 신 따위는 믿지 않는다. 그렇지만 한때 귀신을 두려워했던 기억은 아직 남아있다. 그 기억은...특정한 조건이 만족되면 불쑥 튀어나와 심장을 채찍질하고 혈관을 움켜쥐며 공포의 감정을 유발한다. 믿음과 공포는 별 관계가 없는 것 같다.

산타 할아버지가 없다는 것을 알게 된 때쯤 귀신에게 납치당할 뻔한 기억이 있다. 물론 꿈이지만. 생생한 꿈. 단칸방에서 살았던 때라 세 식구가 이불을 깔고 잤는데, 머리 쪽에는 피아노가 있었다. 어떤 귀신들이 마치 사람을 들것에 실어 나르듯 자고 있는 나를 들어 피아노 의자에 눕히고 어딘가로 데려가려고 했다. 방 안은 빨간색 파란색 불빛이 비치고 있었다. 앗, 안 돼...! 피아노 의자가 없으면 피아노는 어떻게 치라고! 날 그냥 두고 가! 하며 도망치려 했지만 몸은 움직여지지 않았다. 그때 옆에 누워있던 아버지가 팔을 뻗어 나를 다시 피아노 의자에서 끌어내렸다. 방 안의 빨간색 파란색 불빛이 사라지고 귀신들도 사라졌다. 아버지는 아무 일도 없었다는 듯 다시 잠들었고 그래서 나도 그냥 다시 잤다. 그 귀신들이 어떻게 생겼는지는 잘 기억나지 않는다. 검은 도포에 갓을 쓴 저승사자였던 것 같기도 하고, 소복 입은 긴 산발머리 귀신이었던 것 같기도 하고. 그런 꿈을 꾼 건 아마도 전설의 고향 탓이었겠지. 지금 생각해보면 유치하기 짝이 없는데, 그때는 그게 참 무서웠다. 그렇게 무서워하면서 또 왜 봤을까. 그것도 불을 끄고 이불 속에 숨어서 말이다. 전설의 고향을 본 날이면 밤에 잘 때 이불을 눈 바로 밑에까지 덮고 어딘가에 귀신이 숨어있는 건 아닐까 싶어 천장 구석 구석을 살펴보곤 했다. 잘 때는 귀신이 잡아갈까봐 번데기처럼 온 몸을 이불로 감쌌는데, 특히 발이 이불 밖으로 나오면 안 됐다. 귀신이 내 발을 잡을 수도 있으니까. 이불로 발을 그냥 덮기만 하지 않고, 발을 살짝 들어 이불 끄트머리를 안쪽으로 말리게 한 다음 그 위에 발을 올려놓았다. 마치 침낭에 들어간 듯한 느낌으로. 그렇게 하지 않으면 귀신이 이불을 들어올며 내 발을 잡을 수도 있으니까. 무슨 근거로 이불이 귀신으로부터 나를 보호해준다고 생각했는지는 모르지만 그땐 그냥 그랬다. 그런데 자는 동안 이불을 차버리고 뒤척거려서 그런지 아침에 일어나보면 이불을 안고 있거나 깔고 누워 있었다. 요즘도 잘 때는 그때처럼 이불을 발 끝까지 감싼다. 귀신 때문은 아니고, 안그러면 발이 시렵기 때문이다.

일찍 자고 일찍 일어나야 착한 어린이라는 말을 누가 만들었고 그게 어떻게 퍼지게 되었을까? 언제부터 그런 말을 듣기 시작했는지는 기억이 안나지만, 그 기준으로 보면 난 착한 어린이는 아니었다. 일찍 일어난 기억은 없고, 늦게 잔 기억은 많다. 학교 갔다 와서 동네 친구들이랑 집 앞 주차장이나 놀이터에서 놀다가 저녁을 먹고 또 나가서 놀았다. 엄마가 나와서 이름을 부르면 맞기 전에 들어가야 했다. 그렇게 친구들이 하나씩 하나씩 집으로 들어가 마지막 하나가 남을 때까지 밖에서 계속 노는 거다. 밖에서 놀다가 집에 들어가면 모래가 떨어지기 때문에 일단 화장실부터 들어가서 옷을 벗고 씻고 나와야 했다. 아버지는 일과 술로 항상 늦게 들어왔고, 어머니는 동네 아줌마들과 함께 큰 텔레비전이 있는 어떤 집에 모여 사랑과 야망 같은 드라마를 보며 과일과 다과와 담화를 나누다 들어왔다. 그동안 나는 TV 를 켜고 잠이 올 때까지 전설의 고향 같은 것을 보았다. 그때 TV 에서 본 귀신이나 무서운 장면은 몇 일 동안 계속 생각나서 밤에 잠을 잘 못자기도 했다. 그러다가 귀신한테 납치당하는 꿈을 꾼 거였겠지.

밤낮 가리지 않고 놀았던 때인데, 난 낮에 놀았던 것보다 밤에 놀았던 기억이 더 많다. 딱히 장난감이 많지 않았던 시절이라 딱지치기나 구슬치기 정도였고, 한 때 줄팽이가 유행했을 땐 미친듯이 팽이를 치기도 했다. 팽이는 길거리 아스팔트나 보도블럭에서 돌리면 영 시원찮았기 때문에 반반한 시멘트 바닥인 아파트 공동 현관 앞 복도에서 쳤다. 그러다가 시끄럽다고 어른들이 소리를 치면 다른 현관으로 이동해서 또 팽이를 쳤다. 여름에는 어디서 왔는지 모를 잠자리가 무지하게 날아다녔다. 그때는 미친듯이 잠자리를 잡고 다녔다. 친구들이 여럿 모이면 무궁화 꽃이 피었습니다, 우리 집에 왜 왔니, 38선, 얼음땡, 다방구, 땅따먹기, 사방치기 등을 하며 놀았다. 그 중 친구들을 골탕먹이기 좋은 놀이는 술래잡기, 그것도 밤에 하는 술래잡기다. 불빛이 닿지 않는 아주 컴컴한 곳은 숨는 것도 무서웠지만 그곳에 숨어있을 것 같은 친구를 잡으러 가는 것도 무서웠다. 그래서 밤의 술래잡기는 깜짝 놀래키기 혹은 깜짝 놀라기 놀이가 되기도 했다.

울타리 위 혹은 건물 담장에 올라가서 걷는 것도 놀이 중 하나였다. 놀이터 울타리는 가슴 높이에 5센치미터 정도 두께였다. 그 위에 올라가 양팔을 벌려 균형을 잡으며 한 쪽 끝에서 다른 쪽 끝까지 떨어지지 않고 친구들보다 더 많이 걸어가면 이기는 거였다. 균형을 잃어서 떨어지면 친구는 자기가 이겼다고 좋아했고, 그러면 난 바람이 불어서 떨어진 거니까 다시 해야 한다고 우겼다. 아파트 화단과 인도변 울타리는 통나무 모양의 철근 콘크리트 울타리였다. 각각의 통나무는 높이가 달라서 들쭉날쭉 했고, 중간에 빠진 것도 있는가 하면 윗 부분이 깨져서 철근이 삐죽 튀어나온 것도 있었다. 울타리를 따라 심어진 회양목 같은 나무들이 너무 커서 지나가는 사람들이 비켜가야 할 정도로 통나무 몇 개를 덮어 튀어나와 있기도 했다. 그래서 그 통나무 울타리에서 떨어지지 않고 높이 솟아있는 것만 밟으며 깡총깡총 뛰어서 끝까지 가는 것도 도전적인 놀이였다. 아파트 단지 한쪽 진입출로에서 반대편 진입출로까지 통나무 울타리들이 죽 이어져 있었는데, 물론 중간 중간 교차하는 도로가 있어 끊어지는 구간이 있긴 했지만, 그 길이 꽤 길어서 도중에 떨어지지 않고 끝까지 가기는 쉽지 않았다. 인적 드문 밤에는 혼자서 하기 무서우니까 친구들 몇 명이 모여 줄을 서서 속도를 맞춰 하기도 했다. 그래도 가로등이 꺼져있거나 어두운 곳은 무서웠다. 그때 어떤 친구가 노래를 부르면 귀신이 가까이 오지 않는다고 해서 만화 주제가 같은 노래를 불렀는데, 더 어두운 곳에선 더 큰 목소리로 노래를 불렀다. 특히 가장 뒤에 있는 친구가 가장 크게 노래를 불렀다. 그런데 그럴수록 더 무서워졌다. 귀신이 가까이 오지 못하게 하기 위한 노래에 의지하면 할수록 귀신이 근처에 있고 심지어 우리가 노래를 멈추기를 기다리며 따라오고 있을지도 모른다는 상상이 점점 믿음으로 변해갔기 때문이었다.

수능 끝난 후였던가? 대학교 휴학하는 동안이었나? 언제인지 기억이 잘 안나지만 운동 삼아 잠깐 동네 태권도장에 다닌 적이 있었다. 어느 여름날 밤에 태권도 관장님과 사범님들이 초등학생 제자들 담력을 키운다며 인근 둔촌동 일자산 공동묘지에 데려간 적이 있었다. 그 때 관장님이 나한테 애들 겁주는 거 좀 도와달라고 했다. 나는 재미있을 것 같아서 흔쾌히 도우미로 나섰다. 산길 중간에 모여있던 아이들에게 주어진 임무는 한 명씩 혼자서 어두운 산 언덕길을 올라 공동묘지를 지나 반대편에 기다리고 있는 사범님에게 가는 것이었다. 난 공동묘지 입구 근처 샛길 안쪽에 앉아있다가 아이들이 지나갈 때 다리를 다쳐서 그런데 좀 도와달라며 흐느끼듯이 떨리는 목소리로 아주 천천히 아이들을 불렀다. 얘야아...다리를...다쳐서...그런데...이리 와서...나 좀...도와줘어...어서...이리 와...어떤 아이는 못본 척 무시하고 지나갔고, 어떤 아이는 이이씨 쒼발년아아! 하면서 막 욕을하고 으르렁거리며 공격 태세를 취하기도 했다. 어떤 아이는 신발을 던지기도 했다. 난 돌을 던지지 않은 게 다행이라고 생각하며 신발 한짝을 눈 앞에서 잃어버려야 하나 귀신 가까이 가야하나 고민하는 그 아이에게 다시 신발을 던져주었다. 아이들은 다양한 반응을 보였지만 내 앞으로 가까이 온 아이는 하나도 없었다. 그리고 노래를 부르는 아이도 하나도 없었다. 공동묘지 가는 길에 아이들한테 노래를 부르면 귀신이 가까이 오지 않는다고 말해줬다면 노래를 불렀을까?

여덟 살 정도까지 사람은 마트료시카나 양파 같은 것이어서 껍데기가 한 겹씩 쌓여 어른이 된다고 생각했다. 그러니까 어른 안에는 더 작은 사람이 들어있고, 그 안에는 더 작은 어린이가 들어있다고 생각했던 것이다. 언젠가 큰 병원에 갔을 때 기괴한 해골과 핏줄과 근육이 그려진 해부도를 보고 마치 귀신을 본 것만큼 무서웠던 기억이 난다. 해골이 너무 허약해 보여서 그랬던 것도 있지만, 그냥 엄청나게 징그럽고 흉측해 보였다. 그때쯤부터 세상에는 엄마와 귀신 말고 무서운 게 참 많다는 것을 깨닫기 시작했다. 어렸을 때 TV 에서 뭔가를 보고 잠을 못잘 정도로 무서웠던 것 중 최고는 미국 드라마 V 였다. 다이아나가 쥐를 잡아먹는 것도 그랬지만, 외계인들이 납치한 인간들을 식량으로 만들어 유리관에 보관하고 있던 거대한 창고 장면은 너무나 충격적이었다. 그보다 더 경악스럽고 끔찍했던 것은 속이 보이는 유리 관 안에 초록색 외계인 시체 옆에 누워있던 어떤 여자가 막 깨어난 장면이었다. 그 관은 우주로 방출되기 직전이었고 여자는 죽을 때까지 시체와 함께 우주를 떠돌아야 하는 공포를 온 몸으로 표현하고 있었다. 요즘 보면 허술하고 어색하기 짝이없는 장난감 같은 분장이지만 그때는 그 외계인 얼굴이 왜 그리 험악하게 느껴졌던지. 우뢰매 외계인 악당들은 그보단 덜 무서웠다. 밤에만 나타나며 노래를 부르면 가까이 오지 않고 굳이 이불 속에 숨은 아이에게 해코지 하지 않는 귀신 따위는 점점 무서워하지 않게 되었다. 그러다가 누구나 그렇게 되듯, 나이가 들수록 세상에서 가장 무서운 건 다름 아닌 바로 사람이라는 것을 점점 더 실감하게 되었다. 이제는 귀신이나 외계인이나 괴물 따위가 나오는 꿈은 꾸지 않는다. 사람이 나오는 꿈을 꾸는데, 흐헉 소리와 함께 팔 다리를 파다닥거리며 잠에서 깨곤 한다.

조기 교육

뻔돌이 — Mon, 8 Feb 2021 20:26:36 +0900

아버지는 6.25 전쟁이 끝나기 전에 태어났고, 어머니는 끝난 후 태어났다. 살짝 넓게 보면 베이비붐 세대다. 두 분의 어렸을 적 기억은 사뭇 다르다. 친할아버지는 이북 출신으로 전쟁이 금방 끝날 거라 생각해서 거의 맨몸으로 남한으로 내려왔다가 고생 끝에 겨우 정착했는데 화재와 사기 등으로 그나마 없는 재산도 탈탈 털려 길거리에 천막치고 살 때가 있었을 정도로 가난했다고 한다. 장남인 아버지는 공부를 포기하지 않고 대학에 가서 학원 선생 아르바이트로 학비도 벌고 가족 생활비도 벌며 나중에는 학교 교사가 되었다. 아버지는 본인이 부모님한테 십원 한 푼 받은 것 없이 자수성가했다는 것을 자랑스러워했지만, 술 취했을 때 가끔은 자기 주위에 주는 사람은 없고 받는 사람밖에 없다며 신세한탄을 하기도 했다.

어머니는 어린 시절을 물어보면 집에 식모를 두고 살며 미제 과자와 초코렛을 먹었던 얘기를 했다. 외할아버지는 어머니가 중학교 때 돌아가셨다. 남은 가족들은 버는 것 없이 가진 것을 쓰기만 하면서 살았고, 그렇게 상가 건물과 한옥집은 다 사라지고 10년 후에는 빈털털이가 되었다. 하지만 어머니는 부잣집 장녀였던 그 시절을 결코 잊은 적이 없었다. 마치 몰락한 왕조의 자존심 쎈 공주같은 느낌이랄까. 어머니는 대학에서 유아교육을 전공했고 졸업 후 유치원 교사 일을 했다가 나를 낳고 그만 두었다. 어머니는 본인이 직접 돈을 많이 벌지는 않았지만 우리 집이 중산층 수준으로 사는 것은 다 본인 덕분이라고 자주 말했다. 왜냐하면 자기가 복이 있는 사람이기 때문에 아버지 일이 잘 풀렸다는 것이다. 그래도 IMF 이후에 두어번인가는 아버지가 자수성가한 건 사실이고 지하 단칸방에서 시작해 지금 이렇게 살게 된 게 참 대단한다고 칭찬한 적이 있기는 했다.

두 분은 각자의 이유로 돈의 소중함을 강조했다. 특히 어머니는 좀 극단적인 편이었다. 세상에서 제일 중요한 건 돈이었다. 사랑이고 뭐고 돈이 있어야 가능하지 돈이 없으면 다 소용이 없다고 늘 강조했다. 돈의 소중함을 가르쳐준다며 어머니 집안 일을 거들거나 아버지 구두를 닦거나 뭔가 일을 해야만 용돈을 주는 부모들이 많았지만, 내 부모님들은 그러지 않았다. 그건 어머니의 영향이 컸다. 어머니는 사람이 쪼들려서 살면 심성이 꼬이고 천박해진다며 부족함 없는 환경의 중요성을 강조했다. 내가 둘만 낳아 잘 기르자는 분위기였던 그 시대에 흔치 않았던 외아들인 이유도 그런 거였다. 둘이 나눠 가지면 쪼들리니까. 어머니는 아버지가 옆에 있을 때 그런 얘기를 더욱 더 힘주어 말했다. 아버지는 그럴 때 몹시 불쾌한 표정을 지었지만 별 말을 하진 않았다. 그래서 난 어렸을 때부터 아무 대가 없이 그냥 용돈을 충분히 받았다. 먹고 싶은 과자를 아쉽지 않게 사먹을 정도여서 동네 친구들한테 과자를 사주기도 했다. 그렇지만 뭐 엄청 가지고 싶은 것도 없고 엄청 하고 싶은 것도 없고 그랬다. 중고등학교 때 애들이 환장하는 나이키 농구화도 가지고 싶어한 적 없고 부모님한테 사달라고 한 적도 없다. 난 아직도 신발이나 옷이나 자동차 같은 것에 전혀 관심이 없고 그런 쪽에 돈을 거의 쓰지 않는다. 하여간 어렸을 때부터 딱히 돈을 쓸 일이 많지 않기도 했고 돈에 쪼들린 적도 별로 없었고 돈에 그리 큰 관심도 없었다. 책을 사서 보는 데 용돈을 좀 쓰긴 했다. 한 때는 오쇼라즈니쉬나 법구경 같은 책에 심취하기도 했다. 대학교 졸업할 때까지도 학비와 각종 비용 뿐 아니라 용돈도 받았기 때문에 그 때까지 아르바이트를 해서 돈을 벌어본 적이 한 번도 없다. 서른 넘어서 취업하기 전까지 백수 시절에도 용돈을 받았다. 그 때 아르바이트를 몇 번 했는데 그것도 한 달에 두어번씩 학교 선배 일을 도와준 것이 전부다. 일련의 사소한 일들로 운좋게 뜻하지 않은 취업을 한 후 지금까지 근근이 벌어먹고 살고있는데, 그게 아니었다면 지금까지 미혼 중년 백수로 살고있을 지도 모른다. 부모님이 날 해외 유학 보내줄 정도로 돈이 많았다면 유학파 미혼 중년 백수로 살고있을 지도. 난 지금까지 살면서 그다지 쪼들리지 않았지만 쪼들림에 대한 공포심이 있다. 어쩌면 스스로 쪼들리는 상황을 만들고 싶지 않아서 그렇게 소극적으로 살아왔을 지도 모르겠다는 생각이 들 때가 있다. 사실 아이를 낳지 않은 건 쪼들리며 살고 싶지 않았던 것도 있다. 아이를 낳는다면 그 아이가 쪼들리지 않고 살 수 있게 할 자신도 없었고. 만약 내가 어렸을 때부터 돈에 쪼들려서 살았다면 내 인생은 달라졌을까? 어쩌면 그런 건 별로 중요하지 않을 지도 모른다. 당장 내일도 불투명한 요즘 시대엔 일부 상류층을 제외하고 누구나 쪼들리며 살고 있거나 그럴 운명이니까.

부모님은 돈이 중요하다고 늘 강조하셨지만 금융이나 부동산 같은 것을 잘 알지 못했다. 그저 나에게 돈이 중요하다는 말만 했을 뿐이다. 부모님들이 할 줄 아는 재테크는 절약과 저축이 전부였다. 나도 아직까지 할 줄 아는 재테크는 절약과 저축밖에 없다. 아니, 흠, 생각해보니 절약은 빼야겠다. 펑펑 쓰는 건 아니지만 그렇다고 아끼며 사는 것도 아니니까. 저축도 요즘은 금리가 없는 거나 마찬가지 수준이니...사실상 내가 할 줄 아는 재테크는 현재로서는 없다고 봐야겠다. 사실 재테크보다 더 중요한 것은 일이다. 일단 굴리고 불릴 정도의 돈을 벌어야 그걸 굴리든 불리든 말든 하지. 세상이 변하고 있지만 그래도 돈 버는 가장 쉬운 길은 공부다. 공부해서 대학 가고 직장 얻는 게 돈 버는 가장 쉬운 방법이다. 많이 벌지는 못해도 예체능 분야에서 경쟁하거나 자기 사업해서 버는 것보다 백배는 더 쉬울 거다. 그래서 옛부터 부모님들은 자식들에게 공부를 강조했다. 돈은 중요하다. 공부를 잘 하면 나중에 돈을 잘 벌 수 있다. 그러므로 공부를 열심히 해야한다. 공부는 때가 있다. 그러니까 지금 당장 빡세게 공부를 시켜야 한다. 교육 관련해서는 자식들에게 아낌없이 투자하는 부모들의 허술한 듯 그럴듯한 논리다. 어머니도 내 교육에 많은 시간과 돈을 들였다. 아버지는...바쁘셨다.

어머니의 교육 방식은 채찍과 채찍이었다. 당근은 기억나지 않는다. 난 생일이 빨라 일곱살 때 학교에 들어갔다. 남들보다 한 살 어려서 교과 과정을 잘 따라가지 못했다. 그래서 속셈학원에 다니긴 했지만 어머니가 따로 더 공부를 시켰다. 남들 다 보는 학습지를 풀게 한 것은 물론이고, 어머니가 직접 문제를 만들어 풀게 하기도 했다. 어머니는 내가 배운 걸 잘 모르면 가르쳐줬는데 왜 모르냐며 혼을 냈다. 받아쓰기 연습할 때였던 거 같은데, '운동회' 를 '운동외' 로 잘못 썼는데 어머니가 틀렸다고 고치라고 했다. 난 뭐가 틀렸는지 알 수가 없었다. 고민하며 연필을 만지작거리는데 어머니가 손가락으로 탁탁 치면서 틀렸다고 다시 지적하는데 그 손가락이 가리키는 글자는 '외' 인 것 같았다. 몇 초 눈치를 보다가 '외' 의 'ㅇ' 위에다가 점을 찍었다. 당시 교과서나 학습지의 서체는 명조체 같은 것이었는데, 'ㅇ' 이 그냥 동그랗기만 한 모양이 아니라 위에 점이 있었다. 그걸 뭐라고 부르는 지 모르겠는데, 난 그 때 그게 없어서 틀린 건줄 알고 그렇게 했다. 그랬더니 어머니는 그걸 왜 모르냐고 막 소리를 질렀다. 당황한 나는 너무 똑바로 찍었나 싶어서 떨리는 손으로 'ㅇ' 위에 점을 지우개로 지우고 그 위에 약간 삐딱하게 짦은 사선을 그었다. 어머니는 틀렸다는데 왜 자꾸 똑같이 틀린 걸 적느냐며 또 마구 소리를 질러댔다. 그런 어머니의 열정적인 교육 덕분인지 국민학교 때 내 받아쓰기 점수는 거의 90점이나 100점이었다. 그런데 국민학교 때 받아쓰기를 그렇게 잘 한 게 무슨 소용인가 싶기도 하다. 사실 난 아직도 맞춤법이나 띄어쓰기를 잘 알지 못한다. 지금까지 살면서 수백 번은 사전을 찾아보며 확인했지만 아직까지도 결제와 결재가 헷갈려 잘못 쓰곤 한다.

공부할 때 중요한 것은 예습과 복습이다. 어머니는 복습을 매우 중요하게 여겼다. 그래서 저녁마다 내가 학교에서 필기해온 것을 확인하고 복습을 시켰는데, 난 워낙에 악필이라 내가 써놓고도 잘 못 알아보곤 했다. 어머니는 내가 글씨를 또박또박 잘 쓰지 못해 복습을 제대로 못한다고 생각한 모양인지, 글씨를 제대로 쓰지 못하면 공책을 사정없이 북북 찢어버리고 다시 쓰게 했다. 글씨를 또박또박 쓰려고 노력했지만 삐뚤삐뚤한 악필은 잘 고쳐지지 않았다. 어머니는 매일같이 공책을 찢고 또 찢었다. 난 지켜보는 어머니 옆에서 그 날 필기한 것을 몇 번씩 다시 써야 했다. 눈물로 범벅이 되서 공책이 쭈글쭈글해질 지경이었다. 글씨 교정 학원에도 다녔지만 나의 악필은 결국 고쳐지지 않았다. 그래도 더 이상 내가 써놓고도 잘 못 알아보는 경우는 없었다. 공책을 찢는데 지쳐버린 어머니는 그 정도에서 만족하기로 하고 나를 명필가로 만드는 것을 포기하고 말았다. 그 때문인지 난 아직도 엄청나게 무지막지한 악필이다. 다행히 내가 써놓고도 잘 못 알아보는 경우는 아직까지 없지만. 흠 잠깐. 잘 못 알아보는? 잘 못알아보는? 잘못 알아보는? 뭐가 맞는 거지?

더하기 빼기는 배울 때 크게 어려웠던 것 같지는 않았는데, 나누기는 어려워서 익히는 데 많은 시간이 들었다. 나누기를 배웠지만 잘 이해가 가지 않아서 많은 문제를 틀렸다. 예를 들어 10 나누기 3 하면 몫은 3 이고 나머지는 1 인데, 몫은 2 고 나머지는 4 이런 식으로 풀곤 했다. 손가락 10개로 해결할 수 없는 문제는 거의 다 틀렸다. 똑같은 문제는 답을 외워서 다시 풀 때 맞췄지만 어머니가 숫자를 조금만 바꿔서 문제를 내면 틀려버리고 말았다. 그런 모습이 답답해진 어머니는 분노에 차서 소리를 마구 질렀다. 너무 울어서 눈이 팅팅 부은 바람에 문제가 잘 안보이기도 했다. 심하게 운 어느 날에는 점심에 먹은 짜파게티를 토했는데 면발이 콧구멍으로 나와 덜렁거렸던 기억이 난다. 그 때 그걸 손가락으로 당겨서 뺐던가, 들이켜서 삼켰던가? 난 그렇게 어렵사리 나누기를 익혔다. 다행히 5학년 쯤 되고부터는 내가 멍청했던 게 아니라 단지 느렸을 뿐이었다는 게 증명되었다. 학년이 올라갈수록 산수가 점점 어려워져서 나중에 다각형과 원 둘레나 부피 같은 게 나오면서 어머니보다 내가 더 문제를 잘 풀게 되었던 것이다.

어릴 적 나에게 그런 어머니는 언제 터질 지 모르지만 어쨌든 터지고야 마는 폭탄이었다. 국민학교 3학년인가 그 쯤에는 가출 생각을 할 정도로 어머니가 너무 미울 때도 있었다. 그렇다고 늘 그런 건 아니었다. 가끔은 즐겁게 장난을 치면서 놀기도 했다. 어머니가 날 간지럽히면 방으로 도망쳤고, 어머니는 쫓아 들어와서 내 양 손을 붙잡아 꼼짝 못하게 한 다음 내 배나 옆구리 등에 입을 대고 뿌우뿌우 불어서 또 간지럽혔다. 그렇게 낄낄거리며 놀다가 낮잠을 자고 밥을 먹고나서는 공부와 함께 눈물 잔치가 시작되는 거다. 어머니가 날 그렇게 공포에 떨게 굴었을 때는 절대 유치원 선생님이었을 리가 없다고 생각했다. 그러다가도 아주 어린 시절 내 사진 앨범을 보면 어머니가 유치원 선생님이긴 했나보다 싶기도 했다. 기저귀를 차고 돗자리에 앉아 잔뜩 얼굴을 찌푸리고 있는 내 사진 옆에 '햇님이 너무 방긋 웃어서 우리 아들이 눈이 부신가보네~' 라고 적힌 노란색 병아리 모양 색종이가 불어있었고, 침흘리며 영어 잡지 책을 입에 물고 앉아서 멍때리고 있는 내 사진 옆에는 '어머, 우리 아들이 벌써 영어 책을 읽네!' 라고 적힌 하얀색 구름 모양 색종이가 붙어있는가 하면, 걸음마를 시작한 지 얼마 안된 듯 금방 넘어질 듯한 포즈로 아슬아슬 발을 내딛는 사진들 옆에는 '우리 아들 춤도 잘 추네~!' 라고 적힌 황토색 강아지 모양 색종이가 붙어있는, 뭐 그런 식으로 꾸며져 있었기 때문이다. 다 어머니가 쓰고 자르고 붙인 것들이었다. 또 그러다가도 어머니의 고성과 손찌검에 눈물을 펑펑 흘린 날이면 '역시 엄마는 유치원 선생님이었을 리가 없어!' 라고 생각했다.

어머니는 공부시키는 것에만 관심있지는 않았다. 사람은 다루는 악기 하나쯤은 있어야 하고 할 줄 아는 운동 하나쯤은 있어야 한다고 늘 말했다. 어머니는 유치원 선생님 경력이 있었기 때문에 피아노를 칠 줄 알았다. 11평짜리 작은 아파트에 살았을 때도 집에 피아노가 있었다. 그래서 난 학교 다니기 전부터 어머니에게 피아노를 배웠다. 어머니는 옆 집 형도 가르쳤다. 잘은 모르지만 아마 알바비 얼마 받으셨겠지? 바이엘을 다 떼고 체르니 앞부분 조금 하다가 그만 두었다. 피아노를 치면서 많이 울었던 기억이 난다. 하기 싫은데 억지로 시켜서 울었던 건지 못한다고 혼나서 울었던 건지 잘 기억나지 않는다. 아마 둘 다이지 않았나 싶다. 중학교 때인가 어머니는 그 피아노를 외삼촌네에 갖다주고 전자 피아노를 샀다. 문화센터 같은 곳에서 재즈 피아노를 배워와서 집에서 연습하는 어머니를 보니 궁금하기도 하고 쿵짝쿵짝하는 전자음이 신기하기도 해서 나도 몇 번 즉흥연주를 해보곤 했다. 그 당시에 어머니는 기타도 배웠는데, 강요 비슷한 적극적인 권유로 나도 기타를 배웠다. 가볍게 하려다가 어머니가 비싼 기타를 사주는 바람에 열심히 하게 되었다. 포크 기타도 배우고 클래식 기타도 배웠는데, 난 코드 잡는 것보다 줄 하나씩 뜯는 게 더 재미있었다. 한 때 로망스나 그린 슬리브즈 같은 연주곡에 심취해서 손에 굳은 살이 박히도록 연습하기도 했다. 그 외에 한문, 서예, 미술, 수영, 테니스, 볼링, 스케이트 등등 중학교 때까지 학교 공부 관련된 것 이외에도 여러가지 학원을 다녔다. 그런데 남들 다 다닌 학원 중 내가 안다닌 학원이 하나 있다. 바로 태권도 학원이다. 어머니에게 왜 날 태권도 학원에 보내지 않았냐고 물어본 적이 있다. 내가 태권도 학원에 간 첫날부터 무섭다고 울고불고 난리를 치는 바람에 안보낸 게 아니고 못보낸 거라는데, 난 전혀 그런 기억이 없다. 고등학교 때부터는 입시 공부 외에 다른 모든 것이 밀려났다. 그 입시 지옥의 회오리에 모든 게 날아가버렸기 때문인지, 난 지금 다룰 줄 아는 악기는 하나도 없고, 운동도 할 줄 아는 게 하나도 없고, 별로 좋아하지도 않는 사람이 되어버렸다.

병아리 학살자

뻔돌이 — Sun, 7 Feb 2021 22:28:45 +0900

아마도 대학교 1학년 때 자취하는 친구들 방에서 술을 마시며 놀았던 때였던 것 같다. 어떤 누나가 자긴 두 살 때 기억이 난다고 했다. 다락방에서 언니들하고 아빠 맥주를 몰래 훔쳐서 먹었는데 기분이 알딸딸했다는 뭐 그런 얘기였다. 그 때 나는 세 살 때 기억이라면 또 몰라도 두 살 때 기억은 말도 안된다며 소리를 쳤고 그 누나는 진짜라며 소리를 쳤다. 하필 술마시는 자리에서 말하는 가장 어릴 때의 기억이 술마시는 거라니. 두 살짜리 여자애가 어두컴컴한 다락방에서 맥주를 훔쳐 마시며 헤롱거리는 모습이 상상되는가? 그 상상 속의 상황이 워낙에 특이해서 그 뒤로도 술자리에서 다른 사람들하고 가장 어릴 때 기억은 무엇인가 서로 물어보곤 했었다. 그런데 그 인상이 얼마나 특이했으면 그 때가 언제였는지, 그가 누나였는지 친구였는지 동생이었는지, 그 외 또 누구랑 있었는지 제대로 기억나는 것이 하나도 없다.

나의 가장 어릴 적 기억은, 몇 살 때였는지 생각은 안나지만, 병아리 목욕시키기였다. 아마 세 살 때 쯤이었을 거다. 집 안이 아니고 어딘가 밖이었고 바닥은 단단한 흙이었다. 병아리를 목욕시킨다며 흔한 고무 대야에 물을 담아 병아리를 집어넣고 휘휘 저어 소용돌이를 일으키는 거다. 그러면 병아리가 소용돌이 치는 물 속에서 빙빙빙 돌았다. 그 때 난 병아리가 재미있어할 거라고 생각했다. 그래, 난 그렇게 생각했다고 기억한다. 그리고 병아리 몸에 비누칠을 하고 다시 씻겨준다며 또 그걸 반복했다. 목욕 다 끝났다~ 하면서 병아리를 바닥에 내려놓았는데, 깃털이 흠뻑 젖어서 몸을 제대로 가누지 못하고 눈도 못뜬 채 금방 쓰러질 듯 기우뚱 기우뚱 했다. 그 이후 물에 젖어 축 늘어진 병아리가 저 쪽 풀밭 속으로 던져졌던 모습이 어렴풋이 기억난다. 아마 어머니나 아버지가 그랬을 것이다. 그 때 난 반바지와 민소매 옷을 입고 있었는데, 둘 다 하얀색과 남색의 가로 줄무늬였다. 내가 그렇게 병아리를 죽인 것을 처음으로 기억한 것은, 열 살 때쯤 내가 어릴 적 사진 앨범 속에서 그런 옷차림으로 고무 대야들 들고 있는 모습의 내 사진을 봤을 때였던 것 같다. 그러니까 좀 더 정확히 말하자면, 내가 열 몇 살 때 아주 어릴 적 내 사진을 보고 '아, 그 때 내가 병아리를 그렇게 목욕시킨다며 죽인 적이 있었지' 하며 당시의 기억을 떠올린 것을 기억하고 있는 것이다.

넓은 잔디 마당이 있는 2층집 반지하 단칸방에서 살았던 적이 있다. 셋방살이였다. 긴 언덕 길을 헉헉거리며 올라가야 할 정도로 높은 곳에 있었던 집으로 기억한다. 어머니가 나를 데리고 장을 보러 가면 내가 ET 장난감이 들어있는 과자를 사달라고 졸랐고, 그 ET 장난감을 손에 들고 헉헉거리며 언덕을 올랐던 기억이 난다. 내가 다섯 살 때 부모님이 처음으로 '내집마련' 을 실현하여 아파트를 샀으니까 확실히 내가 다섯 살이 되기 전이다. 어머니는 내가 그 나이 때는 밖에 나갈 때마다 업어달라고 떼를 쓰며 땅바닥에 주저앉는 바람에 힘들었다고 하셨지만, 이상하게도 난 그랬던 기억이 전혀 없다. 그 때 골판지 사과 박스 같은 것에 병아리 두 마리를 키운 적이 있었다. 하나는 뚱뚱했고 하나는 홀쭉했다. 그 때 뚱뚱한 녀석이 홀쭉한 녀석을 괴롭힐까봐 둘이 붙어있으면 뚱뚱한 녀석을 거칠게 밀어서 떼어놓곤 했다. 어느 화창하고 더운 날에 병아리들이 더울까봐 분무기 같은 것으로 막 물을 뿌려줬는데, 그 때 병아리들이 물에 젖어 눈을 못뜬 채 삐약거렸던 모습이 떠오른다. 그 뒤 모습은 전혀 기억나지 않는다. 그 때 죽은 것일까?

옛날에는 길거리에서 병아리와 모이를 파는 사람들이 종종 있었는데, 어린 아이들은 삐약거리는 작고 노란 털복숭이들이 뒤뚱뒤뚱거리는 귀여운 모습을 참지 못하고 용돈을 털어 병아리를 사곤 했다. 언젠가 길거리에서 병아리 한마리를 사다가 먹이를 먹이겠다고 모이를 물에 불리다가 집 안을 난장판으로 만들어 어머니에게 된통 혼난 적이 있다. 정확히 언제인지는 기억이 안나지만 초등학교, 아니 국민학교 2학년 때 고층 아파트로 이사가기 전이었던 건 확실하다. 그 때는 요즘처럼 종량제 봉투 같은 것도 없었고 재활용 분리 수거 같은 것도 없었다. 그 때 내가 살았던 아파트는 5층짜리였는데, 집집마다 쓰레기 투입구가 있었다. 그 안에 쓰레기를 버리면 아파트 지하 쓰레기장으로 떨어졌다. 보통 아파트는 건물 주위에 화단이 둘러싸여있고, 중간 중간 공동 현관문이 있다. 그 아파트는 공동 현관문들 사이에 쓰레기장 출입구가 있었다. 공동 현관문 앞에는 올라가는 계단이 있었던 반면, 쓰레기장 출입구 앞에는 내려가는 계단이 있었다. 반지하 정도 깊이의 그 계단을 내려가자마자 어른이 허리를 숙이고 들어가야 할 정도로 작은 철문이 바로 앞에 있었는데, 그게 바로 지하 쓰레기장 문이었다. 사람들은 거기가 쓰레기장이라는 것을 알았기 때문에 지나가면서 그 계단 아래로 쓰레기를 내다버리기도 했다. 아직 남아있는 90년대 초반 이전에 지어진 아파트들을 잘 살펴보면 더 이상 사용하지 않은 쓰레기장 철문을 지금도 찾아볼 수 있다. 어머니는 나를 밖으로 데리고 나가서 다시는 사지 말라고 화를 내며 내가 보는 앞에서 병아리를 그 쓰레기장 계단 아래로 던져버렸다. 쓰레기장 문 앞에 쌓인 쓰레기 위에 물에 불린 모이가 철퍼덕하며 사방으로 튀고 그 속에 병아리가 파묻혔다. 그 이후 우리 집에서 죽어나간 병아리는 없었다. 그건 다행이었지만, 다른 사람들이 병아리를 닭이 될 때까지 키워본 적이 있다는 얘기를 할 때마다 왠지 모를 꿀꿀한 기분이 들었다.

그 당시에 아파트에서 쓰레기를 그렇게 버렸다니 참 미개하게 느껴지기도 하다. 그런데 도시에서 나온 쓰레기들을 아무 처리 없이 그냥 땅속에 파묻는 건 지금도 똑같지 않은가. 언젠가 쓰레기를 친환경적으로 분해하는 기술이 온다면 그 때는 지금 우리들이 엄청나게 미개해 보이겠지. 한가지 의아한 점은, 그 때 우리집은 1층이었으니 냄새가 심하게 났을 것 같은데 딱히 냄새 때문에 고생했던 기억은 없다는 것이다. 그 쓰레기장의 철문은 자물쇠로 잠겨있었다. 쓰레기 수거해가는 사람들이 일할 때만 열고 들어갔을 것이다. 그런데 가끔 잠겨있지 않을 때가 있었다. 한 번은 잠겨있지 않은 쓰레기장 철문을 보고 영화 스타워즈의 한 장면이 떠올라 들어가본 적이 있었다. 주말의 명화였나 아무튼 TV 에서 스타워즈를 방영한 적이 있었는데, 그 때 난 너무 어려 영화의 내용을 전혀 이해하지 못했지만 몇몇 장면은 인상이 깊어 기억에 남았다. 주인공 일당들이 우주선 안에서 적들에게 쫓겨 도망친답시고 통로 벽의 쓰레기 투입구로 들어갔다가 거대한 쓰레기장으로 떨어졌는데, 거기서 쓰레기를 먹고 사는 덩치 큰 괴물한테 먹힐뻔하고 거기에 또 압착기에 눌려 죽을뻔한 장면이다. 끼이익 거리는 쓰레기장 철문을 조심스럽게 열고 어두컴컴하고 습하고 메스꺼운 공간에 몇 발 내딛다가 어떤 무서운 생각이 들어 도망치듯 밖으로 나왔다. 그건 내 마지막 병아리가 그 쓰레기장에 버려지기 전이었을까, 그 다음이었을까?