사석에서는 몇번 얘기했지만, 이래뵈도 나는 중고등학교를 통틀어, 이른바 "빵셔틀" 이었다. 운동을 안한것도 아니었지만 누구와 맞서서 싸운다는것 자체가 그 당시의 내 심성에는 맞지 않았다.
힘이 있는 아이들이 시키면 그대로 따랐고 광대처럼 웃고 한대씩 뒤통수를 맞으면 그냥 끝나는 일이었다. 그래서 내 정신의 어딘가가 고칠 수 없을정도로 망가지는것도 알지 못한채 그렇게 망가졌었다.
이러한 괴롭힘은 고3때 싸움같지도 않은 폭력사태로 내 코뼈가 부러졌을때까지 계속되었다. 다행히 공부는 못했어도 크게 모난점없이 인사성이 밝았던 덕분에 나는 선생님들에게 그때서야 겨우 보호받을 수 있었고, 그렇게 시작된 관심은 고3이라는 시기와 맞물려 내 남은 1년도 안되는 시간을 그럭저럭 무탈하게 보낼 수 있게 해주었다.
내 인생의 첫 물리적 싸움은 대학교를 들어가고 나서였다. 한끼에 8끼를 먹으며 살았던 대학교 생활은 내 덩치를 짧은 시간안에 키웠고 첫 폭력은 술김에 걸려온 시비에 지고싶지 않았던 작은 분노였었다. 그 별것도 아니었던 사소한 싸움은 이후 문제에 대응하는 나의 자세를 180도 바꿔놓았다.
대학교에서 나는 생각보다는 볼품없는 사람이 아니구나...라고 생각할때쯤 살고있는 동네에서 과거의 트라우마를 물리적인 폭력으로 해결할 수 있는 기회가 주어졌었다. 물런 지금보다 훨씬 더 거칠것이 없었던 나는 내가 할 수 있는 최선의 방법으로 사태를 해결했다.
이후로 군대를 갈때까지 나는 걸려오는 시비를 성별을 가리지 않고 "단 한번도" 그냥 넘긴적이 없었다. 내 자존심이 녹아내렸던걸 더이상은 용납하지 않겠다는듯 쌈닭이라는 표현도 모자랄 정도로 나이조차 가리지 않고 교수와도 뒤를 생각하지 않고 싸웠다. 매 순간 진심이었다.
지금이라고 해서 다 "나았다" 고 생각하지는 않는다. 여전히 걸려오는 시비는 피하지 않는다. 그리 영리해 지지도 않았다. 다만 이전보다 혹시라도 틀려지게 보인다면 그건 경험에 의한 용납의 범주가 좀 더 넓어진 정도겠지.
여전히 나는 그런 경우에 대해 왜 타협해야 하는지 이유를 느끼지 못한다. 나는 내가 필요로 하는 만큼은 충분히 강하며, 남에게 불필요한 시비를 걸지도 않는 "스스로 생각하기에 그럭저럭" 합리적인 사람이다. 굳이 불의에 져야할 이유를 알지 못하며 계산을 잊지도 않는다. 그럼에도 오늘 이 만화를 봤을때, 나는 내 손을 잡아줄 사람이 있었다면 조금 더 틀려졌을까? 라는 생각이 드는건.. 나와 비슷한 트라우마가 있는 사람이면 공감할까 싶기도 하다.
하긴... 경험했다고 해서 누군가를 온전히 이해한다는건 애초에 불가능한 일이지만..
http://comic.naver.com/webtoon/detail.nhn?titleId=699658&no=30&weekday=sun
mobile native app 을 제작한다면...
1. mobile 프로그래밍은 web 보다 어렵다. 단순이 java 와 php 의 level 이 아니다. 문제는 reverse enginnering 이다. 소스코드의 로직이 다 드러날 수 있다는게 문제
2. 그런면에서 mobile-web 은 고민을 덜하게 된다. 바깥의 틀만 native 고 기본적으로는 web 이니까. 하지만 user expirence 가 틀리지. 그러니 native app 을 고집하게 되는데.......
3. 자.. 각설하고 이 native app 을 만든다면 여러가지 고민을 해야한다. 특히 데이터베이스 코드가 잘못 사용되면 web 의 sql injection 보다 훠얼씬 위험한 상황이 될 수 있다. 우리팀처럼 많은 삽이 아니라고 하더라도 서버와 json 으로 통신하는 과정은 필요하다. 그리고 login session 관리도 필요하다. session 의 요청을 통해 불필요한 사용자 정보가 흘러나가는 경우도 막아야 한다. 이외에도 신경쓸게 매우 많다
4. 그럼 이정도냐? 아니다. 사실 해킹등을 대비하려면 좀 더 신경써야 하는게 많다. 대부분 귀찮아서 그냥 넘어가지만... 사실은 넘어가서는 안되는것중에 하나가 clock skew. mobile 과 서버의 시간이 틀어지는 부분도 원래는 대비해야 맞다
UI/UX 를 빼고도 사실은 고민해야할 부분이 많은데... 제대로 신경쓰는곳은 몇곳이나 되려나 싶다. 사실 나라면 크래킹을 할때 mobile app 이 제공된다면 그것부터 뚫겠다. 적어도 mobile app 은 소스를 다 볼 수 있기때문에 상대적으로 web 보다 수월하다는 개인적인 생각.
요즘와서 드는 생각인데.. C 를 위시한 legacy 개발환경이 은근 외면받고 있는듯한 느낌이다(아니 현실이 이미 그렇지만)
내가 소속된 개발팀은 그럼에도 불구하고 꽤나 고전적인 방법들을 선호하는(이라고 쓰고 강요당하는) 편인데, 사실 이건 기본 또는 기초에 대한 문제기도 하다.
1. 대다수의 php 를 필두로한 스크립트 개발자들은 socket 프로그래밍에 대해 이해하지 못한다. 때문에 조금만 고민해도 훨씬 효율적인 시스템을 구성할 수 있음에도 불구하고 그걸 자기가 알고있는 일반적인 지식에서만 구현하려하는 습성을 가져가기 때문에 결과적으로는... 직관적이지 못한 시스템으로 갈 가능성이 많은편이다
2. 아는가? 우리들이 쓰는 그 스크립트 언어들의 인터프리터등은 지금도 C 또는 C++ 등으로 개발되고 있다는걸? 아 물론 자바스크립트로 웹브라우저에서 동작하는 에뮬레이터를 만드시는 분들도 있다는것 인정. 하지만 그분들은 이미 legacy development 를 꿰고 있는 사람들이라는것도 염두에 두어야 하지 않을까?
3. 요 근래 mysql 에 대해서 외부 및 내부에서 미묘한 사례가 나왔다. database 및 구조와 효율에 대해서 전~혀 고민하지 않고 기준없이 설계하는 경우. 물론 요즘와서야 DB 를 oracle 등으로 접하기 "시작한" 사례가 그리 많지 않으리라는 현실은 이해가 간다만... 적어도 개발자라면 그런 사례를 일일히 설명해 주기 전에 고민에 대한 컨셉으로 나머지를 예상해 낼 수 있어야 한다. 개인적으로는 이게 legacy development 가 주는 이점이라고 생각.
4. 물론 web 서비스 외에 뭐가 더 필요하냐고 할 수 있다. 그리고 대부분의 경우는 그게 맞을 수도 있다. 물론 facebook 도 php 를 쓰고, 나 역시 web project 의 경우는 php 를 최우선 순위로 삼는 편이다. 하지만 그 facebook 조차도 php "만으로" 모든 시스템이 이루어져 있지는 않다. 하다못해 IDC 며 서버 하드웨어를 설계하는 기술이 php 만으로 다 된다고 착각하는 사람은 없곘지. 물론 이건 C 언어를 안다는 수준을 한참전에 벗어난 경우겠지만, 적어도 우리가 사용하는 OS 의 근간은 컴파일러 언어라는 사실은 잊지 말아야 겠다.
5. 이런저런 잡설을 집어 치우고라도 간단한 예를 들어보자. 적어도 C 또는 컴파일러 언어에서 thread 프로그래밍을 "직접" 해본 사람은 효율에 대한 이해의 레벨이 다르다. 또한 C 에서 포인터를 직접 짜본 사람 역시 메모리 소모에 대한 고민의 정도가 다르다. 절대적 이라는건 아니지만 상당히 높은 확률로.
6. 사실 개인적으로는 개발자들이 이러한 old legacy development 에 관심을 가지지 않는게 이익이다. 왜냐하면 그럼으로서 나, 또는 내가 속한 개발팀의 가치는 올라갈 테니까. 그럼에도 불구하고 발끝을 아직 담그고 있는 사람으로서는 안타깝기도 하다.
7. 이 내용은 지극히 어그로로 발전할 수 있는 가능성을 지니고 있다. 하지만 오해는 하지 많아주셨으면! 지금의 기술이 나쁘거나 저렴하다는 의미가 아니다. 속칭 "원천기술" 을 가지고 지금의 것을 구현하는 것과, 신기술을 follow 하기에 바쁜건 분명 틀리다. 그 점은 엔지니어고 불리고 싶다면 한번정도는 고민해 봐야할 부분이 아닐까 싶다. - 라는 그냥 개인적인 생각
