1. (구) 프라치노 스킨에서 심플 스킨으로 스킨을 변경하였습니다. 이유는 라이센스 위반의 소지, 프라치노 스킨의 유지 보수의 힘듬, 그리고 신규 스킨으로 블로그를 좀 바꾸고 싶었기 떄문이라고 하면 될까요? 일단, 다양한 스킨들을 테스트 해 봤지만, 일단 심플 스킨이 제일 나은거 같아서 선택을 하였습니다. 요즘 스킨들은 대부분이 포스트에 이미지를 넣을 것을 가정하고 만들어져 있어서, 블로그를 낙서장처럼 글만 쓰는 사람들에게 적합한 스킨이 별로 없었습니다. 심지어 심플 스킨도 모든 글에 사진을 올린다는 가정을 하고 만들어진 걸로 보이는데, 이 부분은 천천히 코드를 수정하면서 해결을 해야할 것 같습니다.

2. 블로그의 과거 글들이 해금됩니다. 해금이라고 하니 좀 리듬게임 덕후 같아 보이네요. 앞서 이야기를 해보자면, 2010년도에 블로그 데이터가 꼬인 대형 사고가 있었던 이후로 미디엄으로 옮겨갔던 적이 있습니다. 이 이후에 하도 불편해서, 다시 티스토리로 돌아왔지만요. 그 과정에서 대부분의 글들을 비공개처리를 했던 적이 있습니다. BenjaminBlog.net 이라고할 수 있는 옛 블로그와 Bengi.kr이라고 하는 신 블로그의 글 통합과 데이터 이전이 좀 문제가 많았었는데, 현재 XML로 백업된 데이터를 다 찾아서 끼워 맞추는 작업을 하고 있습니다. 저는 인터넷에 올라온 글은 영원히 남아야한다는 주의라서, 일단 중고등학교에 썼던 글들부터 싹 다 공개로 전환하는 작업을 할 예정입니다. :)

3. 티스토리는 지속적으로 운영될 의지가 있어 보입니다. 테터툴즈의 한계로 PHP로 돌아가기는 하지만, 전반적인 스킨 수정과 반응형 사이트를 입맛대로 만들 수 있다는 점은 아직도 매력적입니다. 카카오는 브런치라는 대체재가 있음에도 지속적으로 운영을 할 생각인가 봅니다. 텍스크큐브 닷컴이라던지, 미투데이라던지, 다양한 서비스들이 신규 서비스 런칭 이후 유지보수가 안 되다 망하는 경우가 잦았는데, 이 부분들에 대해서는 2-3년간 지켜본 결과 계속 쓸만한다는 판단을 내려 지속적으로 쓸 예정입니다.

4. BenjaminBlog.net 도메인을 살렸습니다. 뭐 여기저기 팔렸다가 다시 원 주인 (?)으로 돌아가는 거지만, 지속성을 위해서 새로운 구 블로그를 테터툴즈 혹은 그에 준하는 서비스로 파고, 거기서 여기로 리다이렉트 되도록 셋팅을 할 예정입니다. 뭐 복잡한 절차이지만, 일단은 이렇게 하는게 제일 마음에 놓일 것 같습니다.

1. 파이콘에서 "혹시 XXX님 아니신가요? 깃헙 레포 YYY 만드시고, ZZZ 회사 운영하시는 분?" 이라고 인사를 받은 충격적인 (...) 경험을 겪고 나서, 음 어 행실을 좀 더 바르게 해야하지 않았나 싶은 느낌이 들었다. 뭐, 아니 근데 솔직히 아니 으악, 진짜로 도대체 왜 사람들이 내 이름을 기억하는지, 왜 내 얼굴을 아는지 (뭐 당연하게도 깃헙에 박아놨으니?) 그리고 왜 내 프로젝트들에 대해서 신경을 쓰고 있는지에 대해서는 정말로 잘 모르겠다. Y 프로젝트는 2년 전에 별 100개 넘게 받았던 프로젝트이고, 8할 정도 글을 내가 쓴 거긴하지만 그렇다고 타인의 도움이 없었던 것도 아니고, 운이 좋게 페이스북도 타고 뭐 이런 저런 일들이 있어서 (사실 나중에 지인이 투고를 했다는 걸 알았다. 그 때 스타수가 50개를 넘어간 시점이었지만) 성공을 했었던 거고, 지금 와서 봤을 때에는 다시 재개를 하고 싶다는 생각이 들지만, 깃헙의 특징상 텍스트 문서 이력 관리는 말처럼 쉽지가 않고, 뭐 회사는 외부에서는 멋진 회사로 보이지만 (1년 정도 버텼으니 뭐 회사 꼴은 갖춰지긴했다) 내부적으로는 아직도 문제가 많다. 이런 일들을 하도 겪다보니, 내 재능이 겉으로 보기에는 괜찮은 것처럼 보이도록 만드는게 아닌가라는 생각이 들 정도이다.

2. 출판 제의나 프로젝트 제의나 헤드 헌팅의 경험이 없는 건 아니다. 한 두 번씩은 있었고, 그 때마다 드는 생각은 "도대체 왜?"였었다. 출판은 저 정도로 글을 6개월 동안 잡고 쓸 능력이 없으니 던졌고, 프로젝트 제의는 내가 프로젝트를 제대로 관리한 경험이 없었으니 싹 다 거절했고, 헤드 헌팅은 대부분 스타트업에서 준 만능 개발자가 필요하니 온 경우였지만, 결국 내가 그 포지션에 맞을 거라는 외부 판단 아래서 나에게 연락을 한 것이라고 생각한다. 결국 외적으로 내가 의외로 괜찮아 보인다는 게 제일 큰 문제일텐데, 사실 이거 때문에 스트레스를 의외로 많이 받는다.

3. 실력 대비 평가가 높은 케이스 혹은 사람들의 최후는 대부분 비슷하다. 보통 피터의 법칙이라고 하는 경영학 법칙으로 설명을 주로 하는데, 사실 무능력함이 드러날 때까지 계속 평가가 올라가는 케이스가 그것이다. 아니 정확히 말해서 무능력함이 드러나는 시점이 그 사람이 갖는 명성의 한계치인데, 보통 이 시점이 오는데까지 걸리는 시간은 대충 실력보다 더 높은 자리에 올라간지 2~3년인 거 같고, 대부분 결국 자기가 할 수 있는 수단과 방법을 가리지 않고 대외적인 평판과 실력으로 커버할 수 없는 고인물 종착역에 다다르게 된다. 뭐 그런 경험들도 있었고, 대학 다니면서 배운 것과 회사 운영에 참여하면서 배운 것들이 대부분 그것이었다. 실력, 발목 잡는 타이밍, 손절 타이밍, 매몰비용 등등으로 다가왔지만, 결국 내 자신도 내 한계에 의해서 실패하는 경험을 꽤 많이 했었었다. 그게 작은 3일짜리 프로젝트인 해커톤일 수도, 1~2년 짜리 스타트업일 수도, 몇 개월짜리 토이 프로젝트일 수도 있었지만, 이런 실패 및 도주의 경험은 언제나 쓰디쓴 무언가였다.

4. 나는 자신이 이 글에서 서술한 특징에서 벗어난 적을 본 적이 없다. 결과적으로 상당히 방어적으로 행동할 수 밖에 없는데, 투입 시간 총량과 아웃풋 총량을 비교하면서, 결국 갈 수 없는 길이나 투입 비용에 따른 산출물을 계산해서 적정 포인트를 뽑아내고, 대충 어디 쯤에서 발을 뺄지를 많이 고민하게 된다는 것이다. 결국 외부 평가나 성과라는 지표에 상당히 강박적이게 되는데, 특히 첫 꼭지에서 언급한 것들이 제일 스트레스를 받게 하는 주 요인이다. 사실 깃헙 프로젝트도, 회사도, 뭐 내가 해왔던 대부분의 일들은 우연치 않게 시작해서 우연치 않게 망한 케이스이고, 정말 괜찮았던 무언가라면 지금까지 잘 굴러가고 있어야할 것들이어야만 할 것이다. 뭐 근데, 그럴리가, 손 수 하나씩 묘지에 묻어주고, 비석까지 세워놓고, Since 2017 이런거 적어 놓은게 태반인데 뭘 존경 받고 인정 받아야 할지는 잘 모르겠는 것이다.

5. 최대치까지 성장을 언제나 못했었다. 중간에 때려쳤었고, 이것저것 할 만한 것들을 찾아다녔었고, 그리고 뭐 여기까지 와 버렸다. 예전에는 능력을 인정 받고 싶었기에 가성비 찾아다니면서 그랬었겠지만, 지금은 벌어먹고 살아야하기 때문이니 이런일을 하면 할 수록 자괴감이 든다. 아니 뭐 이런거 해서 이 돈 받아먹고 살아야하나, 내 실력으로 이걸 해도 되는가, 내 실력으로 이렇게 말해도 되는가에 대한 고민은 언제나 나를 옥죈다. 뭐 블록체인이라는 산업을 잡은 것도, 주요 플레이어가 만만하고 시장 성숙도가 떨어지기 때문이 아니었던가. 난 내가 무엇을 하는지 아직도 잘 모르겠다. 뭐 그래도 유튜브 채널 안 만들고, 슬랙 프라이빗 채널 안 만드는게 다행이지... 큿....

1. 어제 술 좀 마시고 좀 그지 같은 이야기를 트위터에서 했다. 그지 같은 이야기라고 하지만, 그냥 별로 이야기를 하고 싶지 않았던 것들이라고 하는 게 정확한데, 스타트업 하면서 쌓인 게 한두 가지가 아니라는 것이다. 개발 관련해서도, 업계 관련해서도, 그리고 운영에 관해서도. 경영학이라는 학문에 대한 의구심을 갖고 있었지만, 경영을 해보면서 느끼는 건 "이런 경영학의 기초도 모르는 사람이 경영을 하면 안 되는구나"라는 걸 자주 깨닫고, 그것을 반면교사 삼으면서 계속 버티고 있다는 게 정확한 표현일 것이다. 경영학 그 자체는 상당히 다양한 분야로 나뉘어있고, 각각의 분야는 대략 6가지 꼭지로 수렴이 되게 된다. 마케팅, HR, 오퍼레이션 관리, 회계, 재무, MIS가 그것인데, 대부분의 기업은 이 6가지 (혹은 회계와 재무를 합쳐 5가지)에 대해서 일정 수준의 이해를 요구받거나, 한 분야의 전문성을 요구받는다. 이 글을 쓰는 사람조차도 이 6가지 중에서 회계를 잘 못 하며(C+로 도배를 했고, 아직도 회계 관련한 부분은 별로 안 좋아한다), 오퍼레이션 관리나 MIS는 역시 백그라운드가 백그라운드인지라 중간은 간다고 생각하고 있다. 뭐 재무, HR, 마케팅은 곁눈질로 배운 게 다이며, 일단 전공 서적과 케이스 스터디를 통해서 공부를 했었지만, 역시 마케딩은 디자인의 연장선상으로, HR은 인간관계의 연장선상으로, 재무는 스타트 업식 땜빵으로 커버를 치는 경우가 더 많다고 하고 싶다. 결국, 지금 갖고 있는 경영학이라는 인식은 그렇게 깊지도 넓지도 않다는 것을 매번 깨달으며 계속 공부하는 처지에 놓인 것이다. 최소한 회계라도 제대로 하면 좀 더 장기적으로 뽑아낼 수 있는 수치가 많지 않을까, 자금 흐름의 예측을 좀 더 잘하지 않을까 생각을 많이 하게 되는데, 역시 이런 것들은 단순하게 돌아가지는 않는다. 외부에서 오는 일감이나 프로젝트는 제한적이고, 시기를 타는 경우가 많은데, 이런 것들은 조절할 수 있는 변수가 아니다. 대부분 BI나 CI라는 마케팅 카르마를 쌓아야 하는데, 이런 카르마를 초창기에 쌓지를 못했다는 점, HR을 인간관계로 땜빵을 때렸다는 점 (장기적으로 이렇게 운영하면 안 된다), 기업 간 라인 구축을 제대로 하지 못했다는 것 등등이 문제라면 문제라고 할 수 있다. 이런 것들을 해결을 어떻게 하느냐가 핵심인데, 일반적으로 블록체인 업게라는 특수성이 사실상 스타트업의 활로를 너무 제약하지 않나 싶다. 타 업종에서는 기피하고 있는 분야이고, 재정 건전성이 언제나 의심을 받는 구조이고, 그리고 언제나 ICO나 IEO로 귀결되는 시스템이기 때문에 활로라고 할 수 있는 방향성이 없다. ICO는 일종의 시작점이자 종점인데, ICO를 성공적으로 한 후, 메인 넷 론칭에 있어서는 그 누구도 검증 가능하거나 검증을 할 수 있는 방법이 없다고 보고 있고, 사실 이더리움을 제외한 어떤 프로젝트도 제대로 ICO 이후의 플랜(심지어 이더리움은 ICO다운 ICO도 아니었다)을 지키지도 못했다. 뭐, 그런 면에서 엣식의 기회나 투자의 기회는 애매하기 짝이 없는데, 엑싯 사례는 없다고 봐야 하고, ICO는 사실상 성공할 수 없는 독이 든 성배이며, 이 두 상황에서 투자를 받는 거 자체가 불가능한 무언가라고 봐야 한다는 것이다. 결과적으로 이 회사가 선택할 수 있는 방법은 상황유지라는 방법이나 자체 상품을 개발 후 탈 블록체인 하는 수밖에 없는 것이다. 실제로 많은 기업들이 블록체인이 아닌 일들을 하기 시작했다. 뭐 말이야 블록체인의 오딧팅, 보안 감사, Dapp 제작 등이라는 형태를 띠지만, 오딧팅/보안감사는 언제나 보안 감사 전문 업체의 일이었고, Dapp 제작은 앱 제작과 별반 차이가 없다는 것을 알아야 한다. 일반적으로 이러한 상황에서 추가적인 메인넷 개발을 하는 팀을 국내에서 찾기는 엄청 힘든데, 토종 코인이라고 할 수 있는 BOS는 실제로 프로젝트가 망했다고 보고 있고, 그 외 몇몇 메인넷 런칭 준비 중인 프로젝트들의 경우 경험상 이것을 메인넷이라고 부를 수 있는가에 대한 질문을 할 수밖에 없고, 런칭 된 메인넷의 경우 이더리움의 변종인 경우가 많다. 결과적으로 포크나 약간의 시스템 개선 이후 중앙화 된 노드들이 사용되는 형태로 변화하고 있는데, Quorum을 그렇게 많이도 참고하는 거 같다. 뭐 이런 상황에서 일반적인 스타트업 방법론이나 중견기업 이상에서 먹힐 만한 방법론이 통하는 업계가 아니라는 건 알 수 있다. 일종의 미궁 속을 계속 헤매고 있는 것과 같은데, 이걸 해결할 일종의 돌파구가 어디서 나올지는 잘 모르겠다.

2. 실제로 블록체인의 경우 기술의 난이도가 높지 않은 편이다. 정확히 말하자면, 기술 성숙도가 낮기 때문에 현재는 접목할 수 있는 기반 기술들이 상당히 많으며, 선행 연구가 많이 되어있는 편이다. 하지만, 문제는 이것이 통화 경제학, 금융공학, 게임이론, 분산처리, VM, 암호학 등등 각 학문에 있어서 거의 끝판왕이라고 할 수 있는 것들의 총집합이라는 것이다. 게임이론을 주로 다루거나 시뮬레이션을 돌리고 있는 (Truebit 시뮬레이션으로 유명한) 디콘 같은 데를 눈여겨볼 수도, SOOHO나 HACHI 같은 오딧팅이나 보안 감사를 하는 곳을 생각할 수도, 플라즈마 네트워크 임플레멘테이션을 만드는 온더를 생각할 수도 있겠지만, 실제로 아직은 기술력에 대한 의문점이나 기술 성숙도에 대한 의문점을 지울 수 없다. 일반적으로, 이 업계가 갖고 있는 문제는 한 분야의 최고가 아니기 때문에, 혹은 블록체인이 핫하기에 들어왔다가 발을 못 빼니 계속 하고 있는 경우가 대부분이기 때문이다. 그런 특징들은 현재 어떤 문제를 해결하려고 노력하는 것을 통해서 알 수 있는데, 현재 블록체인의 코드나 사용하는 언어를 좀 보자. 블록체인 메인넷 코드들에서는 오딧팅 툴에 바로 걸리는 잘못된 사용(Use After Free, Double Free...)이나 배포 환경에 대한 대응 미비(nix를 팩키지 매니저로 쓰라는 Cardano라던지), 특정 라이브러리 의존성(Bticoin 계열의 BDB 4.8, OpenSSL 1.0) 등등이 발견됨에도 불구하고, 국내 몇 팀 제외하고 이런 부분에 대한 패치나 개선을 하지 못하거나, 이 문제 자체를 이해를 못 하는 경우가 많다. 언어의 경우 새로운 단어를 재발명해서 사용하고 있다는 점을 눈여겨봐야 한다. 핀테크(Fintech)보다는 DeFi 같은 단어가 더 간지나보이고 Decentralized 된 것처럼 보이리라 생각하지만, 실제로는 뜯어보면 구조는 대부분 같다. 탈중앙화 되어있다지만, 중앙화 된 무언가가 정부에서 기업으로 이전되는 것일 뿐이고, 실제로 그 이전되는 기업은 탈중앙화를 외치는 그 기업들이라는 것이다. 대중은 결국 블록체인이라는 것이 섞여있는 무언가만 보면 알레르기 반응을 보이는 상황까지 와 버렸고 (비트코인 25000달러 돌파와 김치 프리미엄에 기인한 것이 대부분이지만) 이러한 단어들의 선택은 블록체인 업계가 얼마나 안일하게 시장을 파악하고 끌어가고 있는가에 대한 방증일 뿐이다.

3. 강의를 나가거나 술자리에서 이야기를 할 때마다 하는 소리는, 토렌트랑 GPG/PGP랑 합쳐놓으면 그게 블록체인이라는 이야기를 많이 한다. 블록체인 자체 저장 시스템은 링크드 해시드 리스트와 머클 트리, 스테이트 관리를 위한 트라이(Trie)의 집합일 뿐이다. 거기다가 버클리 디비나 레벨 디비를 사용하고 있으니 실제로 저장은 키-밸류 스토리지에 쳐 박히는 구조인데, 이것이 뭔가 대단한 것처럼 말하는 것도 좀 그시기하다. 사실 보면 그냥 학부 3~4학년이 열심히 노력하면 (그게 뭐 본인 대학 기준으로 말하니 타 대학 기준으로는 석사까지 갈 수도 있다.) 만들 수 있는 시스템이고, 실제로도 많은 강좌들이 주목하는 지점은 Hash와 ECC, 분산 네트워크에 관한 것이다. 뭐 더 나아가면 데이터를 압축해서 저장하거나 패딩을 넣거나, 아님 블록 바이너리를 어떻게 다루는지에 대한 부분인데, 이 부분은 임베디드 시스템에서 메모리 최적화하는 기법이랑 별 반다를 바가 없다. 사실 바이트 단위로 블록 데이터를 저장하고 이를 가져와서 처리를 개떡같이 하니 사람들이 공포감에 휩싸이는 거지, 이것도 CTF에서 낮은 레벨의 문제이다. 대부분 노가다하면 풀리니는 부분이니

그렇다면, 블록체인의 문제는 무엇인가? 아니 문제라기보다는 업계의 문제는 무엇인가?

블록체인 업계 문제점은 의외로 단순 명료하다. 기술 공유의 부재, 별 것 아닌 지식의 무기화 및 자산화, 기존 방법론에 대한 적용 미비, 리서치 미비 등등일 것이다. 요즘 DID가 대세가 돼가고 있다. DID가 대세가 되리라는 것은 쉽게 할 수 있는데, ECC로 비대칭키를 구현하고 사이닝까지 하는 구조에서, PKI 인증(공인인증서에 쓰이는 그것 맞다)을 블록체인으로 할 수 있을 거 같은데 왜 안 하냐라는 질문이 나오는 건 당연한 것이다. 구조적으로 PKI 인증을 해서 그 기반으로 암호화폐가 전송되는 것인데, PKI 인증을 암호화폐에만 하면 좀 거시기하지 않는가? (실제로 이렇기에 카카오톡 PKI인증은 초반에 비트코인에 OP_RETURN으로 데이터를 쓰고 그것으로 인증 결과를 블록체인에 올렸다고 주장했다)

근데 까놓고 말해서, 이런 거 새로 만드는 건 바퀴를 재발명하는 것과 같다. 이미 DID가 아닌 PKI 인증에는 표준 규격이 존재하고, 이미 DID 관련해서도 규격화된 것들이 많다. 그냥 갖다 쓰면 되는 것이다. 오히려 지금 업계가 해야 할 일은 기존 시스템에 잘 붙게 라이브러리 만들고, 표준 스펙 만들고, 스펙 공유해서 각 블록체인 노드를 하나로 통합하는 일이다. 솔직히 Litecoin과 Bitcoin의 소스코드 디핑만 떠봐도 얼마나 유사도가 높은지, 루니버스니, 클레이튼이니를 Quorum이나 Geth와 디핑을 떴을 경우 유사도가 얼마나 되는지를 본다면, 실제로 이게 뭔 개 짓거리인지를 쉽게 파악할 수 있다. 대부분 베끼고, 개선이라는 명목 아래 새로운 체인을 만들고, 그 체인에서 암호화폐를 발행함으로써 일종의 채권을 만들어서 파는 것뿐이다. 이러한 무안단물 장사는 그만 되어야 한다. 통일화된 스마트 컨트랙트 규격, 스크립트 바이트 코드, 호환 가능한 VM 등등이 선행되지 않는다면 이 시장은 파편화가 되거나, 아예 몇몇 메이저 플레이어를 제외하고 다 망하는 대청소 시간이 올 것이라는 것은 누구라도 알 것이다. 하지만, 앞서 말했듯이 이 업계에서 그런 실력을 갖고 있는 데가 얼마나 되는가?

4. 기존 업체들은 신규 플레이어의 진입이 시작되는 것을 제일 두려워한다. 뭐 기술력의 부재는 이미 앞에서 길게 말했으니 넘어가고, 여기서 다룰 꼭지는 신규 플레이어의 강력함이다. 나 자신도 처음에는 JP 모건의 Quorum을 보면서 콧웃음을 쳤지만, 클레이튼이나 루니버스에 적용되는 것을 보고 가능성에 대해서 생각을 하게 되었는데, 실제로 이러한 시스템이 널리 퍼지고, Geth나 Parity에 확장된 코어를 붙여 여러 개의 암호화폐를 사용할 수 있는 단일 클라이언트가 나온다면 상당히 새로운 서비스를 구상할 수 있다. 일반적으로 인터체인이라고 할 수 있는 Polkadot이 그것을 하는 것처럼 보이지만, 이러한 인터체인 기술은 그렇게 어려운 것도 아니다. 그냥 블록체인 클라이언트가 여러 체인 데이터를 다룰 수 있으면 되는 것 뿐이고, 그걸로 채굴을 할 것도 아니니 SPV 같은 기술과 엮으면 실제로 하나의 온전한 블록체인에 접근할 수 있는 무언가가 나올 것이다. 또한, 분산처리나 언어론을 주구장창 하던 대학교 랩들이 분산처리 관련해서 이더리움 프로젝트에 컨트리뷰트하거나 새로운 합의 알고리즘을 만들어내던가, 정적 분석기 개발된 것들을 좀 더 개량해서 자바스크립트 분석기를 솔리디티 분석기로 가져다 쓰는 경우 같은 것도 생기고 있다. 이미 거래소 솔루션 장사로 몇 십억씩 돈을 번 케이스도 목격되는데, FX 마진이나 해외 선물 시장 솔루션 만들던 증권사 SI들이 달려들어서 암호화폐 거래소 솔루션 만들어서 돈을 벌어먹었다는 사례는 정말 유명하고, 실제로 몇몇 메이저 거래소를 제외하고는 대부분 이러한 솔루션 빵판으로 찍어낸 것들이 대부분이다. (그렇기에 비슷한 취약점을 공유하고 해킹도 많이 된다)

기업, 대학교, 연구소가 아니라도, 데프콘이나 코드게이트, 코드엔진만 봐도 실제로 블록체인 이슈가 얼마나 핫한지 알 수 있다. 보안하는 사람들 안 좋은 버릇이 파이 좀 커지고 먹을만해지면 이제 취약점 찾아서 돈과 명성을 얻는 것인데, 실제로 발표장에서 이제 이거 이렇게 공략하면 크레딧 이 정도 나온다를 공유할 정도의 사이즈까지 되었고, 비슷한 예시로 IoT, 즉 임베디드 산업이 2014년 이후로 엄청나게 핫해지면서 기존 공격 기법들 재활용(리눅스 2.6이 돌아가는 시스템이니 15년 전 기법도 통한다)을 하면서 명성을 쌓는 경우를 많이 봤다. 심지어 글쓴이도 그렇게 IoT 장비들을 분석하고 공격하면서 명성을 쌓았었다. 블록체인으로 방향을 우연히 틀게 되면서 블록체인에서도 동일한 깃발 꼽기 싸움이 생길 거라는 것을 직간접적으로 경험하게 되었는데, 역시 코드 퀄리티가 개판이라는 점과 단순 DoS 같은 공격으로 전체 시스템이 마비되는 수준이라는 것은 공유되는 CVE나 공격 사례들로 증명이 이미 충분히 되었고, 실제로 스마트컨트랙트 실행이나, 네트워크 공격 관련된 부분에 대해서 상당히 취약점이 많으리라고 생각된다. 일반적으로 Gas라는 개념이나 Fee라는 개념으로 이를 방어를 하지만, DAO Attack 때도 그렇듯이 이런것들을 우회할 수 있는 공격들을 찾아서 공격을 하는게 주된 방식이고, 스마트컨트랙트는 시스템의 복잡도를 높여 이런 취약점을 만들어낼 가능성이 높다는 것이다.

금융공학이나 게임이론 쪽은 결과적으로 JP 모건 같은 금융사에서 들어오기 시작하면서 시장이 꽤 많이 바뀔 것이라고 생각한다. 기술에 대한 이해도는 낮겠지만, 금융 서비스의 보급에 있어서는 상당히 큰 역할을 할 것으로 보이고, 사실 엔지니어 입장에서는 몸값이 더 높아지는 거니 사실 나쁘지 않은 상황일 것이다. 탈중앙화를 지지하거나, 자유주의적 사상에 경도되어있다면 좀 많이 암울한 느낌이 들겠지만, 결과적으로 중앙이나 큰 손들의 영향을 벗어나기는 상당히 힘들다는 것이고, 개인에게 좀 더 큰 자유와 덜 중앙화 된 무언가를 제공해야 한다는 것에 만족을 할 수밖에 없을 것으로 보인다. 아니면 진짜 완벽하게 정부를 엿 먹이는 자체 네트워크를 구축하는 쪽으로 가야할텐데 쉽지는 않을 것이다.

5. 사실 너무 두서 없는 글이 되어버렸는데, 실제로 기존 업계 디스와 스타트업 운영하면서 겪게 되는 스트레스와 뭐 이런저런 이야기들을 다 섞어서 하게 되어버렸다. 2~3번의 퇴고를 거쳤지만, 메인 주제라고 할 수 있는 건 없고, 그냥 약 2년간 블록체인 관련 일을 하면서 겪었던 것들에 대한 푸념이라고 해야하나? 그런 글이 되어버렸다. 뭐, 그렇다고, 아니 그렇다고 뭐 이게 바뀌겠는가. 뭐 그러니 우리나 잘 해야지. 아 엄마 보고싶다. 블록체인 거지 같아요. 엄마 살려줘요. 이게 입에 붙어버렸다. 엄마 으악 X스

기억력이 그렇게 좋은 편은 아니다. 뭐 아티반의 효과 덕분이기도하고, 나이를 먹은 것도 있고, 알콜이 간 세포 뿐만 아니라 뇌세포도 죽여서 그런 것도 있겠다. 뭐, 에전에도 말한 거 같지만 장기 기억력은 나쁘지는 않은데, 단기 기억력이 그렇게 좋지 못하고, 그것도 요즘은 옛날 기억들이 하나씩 사라지는 경험을 하고 이썽서 장기 기억도 좋다고 하긴 좀 그런거 같다. 중고등학교 떄 있었던 일들의 많은 것들을 잊어가고 있다는게 상당히 슬픈 일이기도 하지만, 과거의 많은 상처들을 지워주는 일도 해주니 그렇게 나쁜 건 아닐 것이다.

하지만, 여기서 드는 의문은 과거의 나를 통해서 현재의 나가 존재하는데. 과거의 나에 대한 기억이 존재하지 않는다면 현재의 나는 어디서 구성이 되는가일 것이다. 몸이 기억한다, 혹은 해마 같은 것들의 도움을 안 받는 다른 기억 혹은 나이테와 같은 형태의 축적된 무언가가 있다면 뭐 그것이 나를 구성을 하는 거겠지만, 성격이나 행동 패턴의 경우 선행적인 입력이 있어야 형성되는 것이 아닌가? 뭐 답은 대부분 알려진대로, 이러한 입력에 대한 상태가 패턴화되고 고착화되면서 굳어진 것일 것이다. 외부 충격이나 입력은 신경망 어딘가에서 적절한 상수 값으로 존재하는 것이다. 기억이나 조사를 할 수는 없지만.

나이를 먹을 수록 이러한 부분들이 많아지고 있는데 이를 탈피하기 위해 새로운 것을 공부하거나, 새로운 걸 시도를 해보고 있다. 하지만, 직업이 직업인지라 체력의 한계나 시간의 한계도 명백하고, 결국 내가 내 자신과의 싸움에서 진 채 열심히 진이나 홀짝거리고 있는 것이다. 뭐, 술 마시는 것만큼 재미있는 것도 없긴 하고, 요즘 어떤 외부 자극도 그렇게 재미있게 다가오지 않으며, 사실 학문적인 열망을 불태울 무언가도 없다는게 사실이긴하다. 블록체인이 그나마 요즘 하고 싶은 일이자 업이 되었는데, 암호학과 분산처리, 병렬처리 같은 부분에 대해서 호기심이 확장된 형태이지 기술 그 자체를 해먹을 타입도 아니다.

패턴화를 뚫기 위해서 노력하지만, 프로그래밍이라는 일 자체가 패턴화이기도 하고, 일 자체도 그렇게 나의 흥미를 자극하는 일들의 연속이라기보다는 기존 사례의 적용과 변형에 연속이라는 부분이 계속 발목을 잡는다. 책을 읽거나, 다른 취미 활동을 한다고 해도, 프로그래밍이나 회사 업무 밖의 일을 하려고 하는 편도 아니고 뭐 사실 이번 생에는 망하지 않았나 싶다.

윽, 그래서 뭘 해야하지? 공부를 더 하기는 싫고. 테니스 같은 건 치지도 못하는 몸이고. 술이나 더 마시자. 전자정부프레임워크 OUT, 유지보수 OUT....

경영학을 좀 많이 무시를 하고, 별로 안 좋아하는 내색을 많이 냈었는데, 경영학 학사 과정에서 배울 수 있는 지식은 상당히 지대넓얕이기도하고, 정량화된 계량경영이라는 것을 배울 때에는 고학년이 되거나, 아님 기술경영이나 회계학, 오퍼레이션관리 등을 진로로 잡을 때에나 가능한 것이지 일반적인 학부생 입장에서는 재무회계 B+ 정도 받으면 교수에게 넙죽 절을 하는 그런 상황이었기 때문이었다. 뭐, 그건 둘째치고, 사실 회사의 운영에 있어서 경영이라는 것은 애매한데, 대부분 지표나 지수로 나타낼 수 있는 것이 있는가하면, 게량화 될 수 없는 대부분 인적 리소스나, 조직 구조, 마케팅, 혹은 브랜딩 등에 대해서 생각을 해야할 때가 많다는 것이다. 그리고, 아마도 이런 면에서 계량화된 무언가보다는 가치 평가를 하기 힘든 것들과 싸움을 하게 되는데, 이러한 것들을 대처하게 되는 방식은 역시 기존에 배웠던 모델들이나 방법론, 케이스 스터디를 했었던 것들을 통해서 방향을 잡고 움직일 수 있게 되는 것이다. 뭐, 아니, 사실 암흑 속을 걷는 것 같지만, 어쨌든 시행착오를 통해 방향성을 잡고, 시장 조사와 소비자 테스트를 꾸준히 하면서 실제 시장에 대한 이해를 하는 것, 그것을 다시 제품에 피드백으로 넣거나 새로운 제품으로 갈아타는 것 등... 사실 근 2년간 정말 많은 것들을 경험하였다. 그리고, 이런 것들을 회고하면서, 경영대에서 배웠던 과목들 슬라이드를 다시 돌려보고 있는데, 그 때 배웠던 것들이 정말 허투로 배운 건 아니라는 느낌이 들기는 한다. 그 당시에는 비판도 하고, 의미도 없고, 암묵적인 지식 혹은 당연하게 공유하고 있는 지식을 다시 정리하는 것의 무의미함을 설토했지만, 그 때에도 계속 상기를 시켰던, 대부분의 경영적 실패는 동일한 방식으로 실패를 겪고, 대부분 회고 가능한 형태로 존재한다는 것이 정말 많이 와 닿는다는 것이다.

근데, 그래서, 개발은 언제?

1. 다양한 이유로 글을 안 쓰게 되었는데, 사실 일 할 시간에 글을 쓰고 앉아 있다는 죄책감이 제일 큰 이유로 작용하는 것 같다. 남아있는 일은 있는데, 그 일을 마치지 못하고 뭔 딴 일을 한다는 게 상당히 짜증나는 일로 다가오는 경우가 많다. 이런 습관은 중고등학교 때 공부하던 습관과도 맞닿아있는데, 일단 공부를 제대로 안 한 거 같으면 제대로 여가 활동이나 딴 일을 못했던 강박에서 비롯된 것이 많은 것 같다. 이런 습관을 이겨내지 못하면 상당히 생산성이 떨어지고, 일 하는데 있어서 제대로된 일정 관리도, 진척도 없다는 부분이 제일 큰 문제인데, 사실 대부분 즉흥적인 결정이나 판단아래 계획을 해오던 입장에서는 상당히 고통스러운 일이 아닌가 싶다.

2. 사실 내가 잘하는 것과 내가 잘하고 싶은 것은 분명히 다르다. 단위 시간당 생산성이 높은 일들은 대부분 내 자신이 터부시하는 일이나 천대하는 일들이 대부분이고, 내가 정작 하고 싶은 것들은 대부분 노력이나 상당한 시간의 투입이 필요한 일들이다. 아니 정확히, 내가 못하거나 아님 적당한 수준의 실력을 갖고 있는 일들을 어떻게든 하려고 한다는게 제일 큰 문제가 아닌가 싶다. 그냥 못 하겠으면 다른 사람에게 넘겨야하지만, 결국 자기 자신과의 싸움이기도 하고, 자존심의 문제이기도 하고, 그리고 제일 큰 문제는 협조적인 상황에서 일을 한 적이 그렇게 많지 않다는 것이다. 팀 단위로 일을 하더라도 대부분 혼자서 작업하고 이어 붙이는 작업은 나중에 하거나, 아니면 상대방과 같이 일을 한다기 보다는 완성된 설계도를 넘겨 받아 다 뜯어고치는 일을 주로 했었다.

3. 거기다가 소힘한 성격인지 혼자서 다 하려는 습관인지 대부분 그냥 하라는 대로 구현을 완성시키다가 실패하는 경우가 종종 있다. 다만, 이런 것들은 그냥 습관적인 부분인지 아님 대인 관계 문제인지에 대해서는 아직도 파악이 안 된다. 뭐 이게 어디서 시작된 문제인지는 알지만, 이 문제를 해결하기 위해서는 타임머신을 타고 초등학생 때로 돌아가야하지 않을까... 뭐 이미 내재화 된 부분들은 해결이 힘들다는 걸 알고, 회피형 성격을 최대한 뜯어고치려고 하지만, 안정적으로 개선이 될 여지는 수 년간의 노력을 통해서도 보이지 않는다.

4. 결국 남는 선택지는 학자의 길을 걷는 것인데, 학자라고 해도 결국 연구부터 발표까지 대부분 그룹간 협업을 통해서 이루어진다는 것이다. 2~3명 혹은 5~6명 정도의 소규모 그룹을 만들어서 어떤식으로든 운용을 한다고 해도, 그룹 사이즈가 줄어듬에 따라 문제가 덜 발생하고 누군가에 의해서 주도적으로 움직임에 따라 해결이 된다는 것이지, 내가 해결을 하는 건 아니라는 것도 문제다.

5. 플래너 쓰는 이유가 그래서 그런데, 기록이라도 잘 하면 대충 후 처리가 편하기 때문일 것이다. 기억력에 의존해서 일처리하는 방식을 점점 개선해 나가는 중이지만, 역시 인덱싱에 있어서는 아직도 문제가 많다. :(

리눅스를 다루게 된다면 마땅한 텍스트 편집기가 존재하지 않는다는 이유라던지, 아니면 emacs가 싫어서 못 써먹겠다던지의 이유로 vim을 에디터로 쓰게 되는 일들이 종종 있다. 아니면 nano보다는 좀 더 강력한 편집기가 필요하거나, vi 말고는 어떠한 텍스트 편집기도 리눅스에서 쓸 수 없다는 착각을 하고 살거나, 여하튼 vim을 쓰기 시작하는 이야기는 다양하지만, 그 끝이 좋은 걸 본 적이 없다.

사실, 이 글을 쓰게 된 이유는 간단하다. Vim을 쓰는 최악의 실제 사례를 트위터에서 보고, 설마하고 vim을 쓰는 사람들이 대부분 이렇게 쓰는 거 아닌가 하고 확인을 하다가, 실제로 다들 그렇게 쓴다는 것을 보고 경악을 했기 때문이다. "아니 도대체 왜 그렇게 쓰세요?"라는 질문은 접어두고, 실제로 중학교 때부터 vim을 써오고, (아직도 학부생이지만) 학부 때 주변에 vim을 추천하고 다녔던 과거의 일들이 주마등처럼 스치면서 "도대체 (내가 왜) vim을 이렇게 쓰라고 주변에 알려줬나, 도대체 vim은 뭔 인외마경인가"라는 질문이 갑자기 들어서 꽤 큰 현자타임이 왔었다.

vim은 필요에 의해서 만들어진 텍스트 에디터이다. 그리고, 그 필요는 IDE의 등장 이후로는 점점 사라지는 추세가 아닌가 싶다. 터미널 화면이라는 제한적인 상황에서 최소한의 통신과 키스트로크만으로 코딩을 해야했었던 상황과 ed, ex 같은 라인 에디터로 라인을 수정하던 불편함을 해소해야 한다는 상황은 GUI의 등장과 IDE의 등장 이후에는 의미가 없어졌다. vim이 갖고 있는 유일한 장점은 IDE의 기능들과 Ctrl, Alt와 조합 가능한 명령어들로 대체가 되기 시작하였고, 심지어 이 새로운 명령어들은 OS 레벨에서 지원하는 보편적인 명령어 조합들과 호환성이 대부분 보장이 된다. (CCCV처럼)

이러한 상황에서 vim이 자랑할 수 있는 것은 유일하다. 터미널 시절의 그 열악한 환경에서 최소한의 시간으로 최대한의 작업을 뽑아내기 위해 만든 각종 명령어 조합들이 그것이다. 이러한 시스템은 vim이라는 에디터의 진입 장벽을 높였을 뿐만 아니라, 일단 진입 이후 대체재를 못 찾게 만드는 주 원인이 된다. 컨트롤 C 컨트롤 V대신 dd나 yy를 사용해서 라인을 카피 뜨고, p를 이용해서 원하는 자리에 넣는 것은 어쨌든 편하고, 거기다가 이 복사 과정에서는 마우스를 쓸 일 조차 없다. 프로그래머가 마우스라는 엄청나게 불편한 화면 포인팅 장비를 쓰지 않고도, 키보드에서 손을 한 번도 안 떼고도, 새끼손가락을 그렇게 고생시키지 않아도, 키 조합을 충분히 외우고 있으면 엄청나게 빠르게 복사 붙여 넣기를 할 수 있는 것이다. 심지어 vim은 내부적으로 스택을 사용해서 이 복사 붙여 넣기 과정을 관리한다. 그러니, 여러 라인을 여러 번 복사하면, 기존 OS처럼 복사한 내용이 사라지지 않고, 스택처럼 쌓여서 프로그래머의 생각대로 막 복붙이 되는 것이다! (실제로 OS에서는 복사 내용이 사라지지는 않고 기록은 하긴 한다. 다만 Ctrl-V는 최신으로 복사한 내용만 붙여 넣기 해줄 뿐이지)

하지만 이러한 장점은 너무나도 복잡한 시스템에 의해서 상쇄된다.

vim을 초반에 사용하는 패턴들은 대부분 비슷한데, .vimrc의 존재를 모르는 상황에서 인덴트 옵션이나, 신텍스 하이라이팅 옵션은 커녕, set nu나 set rnu 같은 건 키지도 않는 상황에서 엄청나게 불편한 메모장처럼 쓰는 것이 첫 단계이다. 둘째 단계는 그나마 괜찮아지는데, bottom-line command mode나, command mode에서 생산성을 높여주는 몇몇 명령어들을 외우고, 이를 이용해서 vim이 다른 IDE보다 우월한 이유를 찾아내는 것이다. 이럴 때 대부분 vim을 주변에 추천하고 다닌다. 하지만, vim에 대한 이해도는 그렇게 높지 않은 편이고, 실제로 여기서 주저앉아서 아는 기능들만 쓸 것인지, 아니면 불편하면 찾아서 명령어들을 새로 외우면서 더 많은 기능들을 배울지가 갈린다. 셋째 단계부터는 .vimrc를 수정하고 vundle 등의 각종 확장 프로그램 매니저를 깔고 점점 더 나은 터미널 생활을 하는 것이다. 대부분 이 단계에서 멈춰있고, 이 단계만 되어도 충분히 생산성을 보장받는 건 사실이다. 최소 1년에서 길면 3~4년 정도 걸려서 이게 뭔 기능인지 하나하나 테스트하면서 알아내는 게 대부분이지만, 일단 프로그래밍 실력이 상승함과 동시에 터미널에서 작업을 할 일이 많다면 어쩔 수 없이 받아 들어야 하는 숙명 정도로 느끼게 되는 것이다. 그리고 사람들이 잘 모르는 넷째 단계가 있는데, 대부분 플러그인을 만들고 있거나, 컬러스킴을 만들고 있거나 여튼 vim script를 이용하여 뭔가를 만들고 있다. 다섯번째 단계로 가면, 정규표현식이나 매크로 같은 기능들을 이용해서 코드 골프를 치고 있는 경우가 나오는데, 프로그래머가 vim을 쓰는건지 vim이 프로그래머를 쓰는건지 모르는 상황에 다 다르는 것이다.

뭐 여튼, 장황한 이야기를 넘어서서, 사실 vim 추천을 극도로 꺼리는 것은 구글링을 해도 그렇게 좋은 vim 자습서와 사용례들이 없기 때문이다. 사실 vim을 접한 지 꽤 되었고, 충분히 프로그래밍도 잘하시는 분이 bottom-line command에 :9999999를 넣어서 마지막 라인으로 이동한다는 이야기를 듣고, 설마 해서 트윗을 올렸다가 대부분 그렇게 쓴다는 이야기를 듣고 상당히 기분이 이상해졌는데, 생각해보니 보통 gg 명령어, hjkl에 숫자를 섞어 쓰거나 대문자로 썼을 경우 vim에서 어떻게 처리하는가에 대한 부분에 대해서 제대로 설명하는 데가 없었다는 것이다. 뭐 유명한 vim 책이나 vim 어드벤쳐 같은 걸 차근차근히 진행을 해 봤다면 알고는 있겠지만, 구글링과 각종 삽질로 배우다 보면 놓치게 되는 부분들이 있는 것은 사실이다. 그리고, 이런 걸 놓치면 솔직히 vim을 권하는 의미가 상당히 없어진다는 것이 문제다.

다시 발단부터 되짚어 보면서 vim의 기능들에 대해서 다시 이야기를 하자면...

20대 중반에는 'Vim 쉽게 배우기'를 믿지 않게 되었다. q!랑 wq만 알면 실무의 90%는 대부분 해결 가능하다.

— 이름뭐하지 (@nameEO) 2019년 5월 4일

그리고 몇몇 대화와 타임라인을 읽다가 {숫자}gg로 라인이동을 하는 게 아닌 :{숫자}로 라인이동을 하는 사례가 의외로 많다는 것을 보고 충격을 받는다.

왜 여러분 :{숫자} 로 라인 이동을 하십니까... ESC 누르고 Shift + ; 누르고 숫자 입력을 하신다니.... ESC 누르고 {숫자}gg 누르면 그 라인으로, 그냥 G 누르시면 파일 맨 끝으로 갑니다.......

— Bengi (@Bengi_Mk3) 2019년 5월 4일

이 이후, vim에 대해서 쌍욕을 하기 시작하는데...

vim은 솔직히 그냥 편집기 자체가 쓰레기라고 보고 있음. 중딩 때 입문해서, 키스트로크 최소화 이딴 소리 믿고 쓰고 있는데 아무리 봐도 iosa 로 입력 모드로 들어가고, 비주얼 모드 쓰는 법이나 dd, de, yy, ye 같은 커맨드 외우우기 등등 배우기 시작하면 끝이 안 보임

— Bengi (@Bengi_Mk3) 2019년 5월 4일

vim 명령어는 ioas, IOAS로 바로 편집하는 기능, gg=G, 123gg, G, dd, yy, u, U, pp 정도이고, 그 이후에 :s/{바꾸기전문자열}/{바꾼후문자열}/ 등등 커맨드 모드에서 외워볼만한 명령어 일부, de 같은 명령어 조합, hjkl 키 바인딩 (그렇게 외울 필요는 없음), /{찾을 문자열} 로 찾고 n,N으로 순회

— Bengi (@Bengi_Mk3) 2019년 5월 4일

?{찾을 문자열}도 있음. 여튼 이 이후부터는 .vimrc를 조져야하는데, set nu나 set rnu 일단 키고, IME 관련 셋팅 다 엎어야하는데... 이게 말처럼 쉽지 👼 슬슬 중수 이상 되면 vundle 같은 패키지 관리자 붙이고, 컬러스킴을 커스터마이징 하기 시작하고, 신텍스 셋 추가하기 시작하는데...

— Bengi (@Bengi_Mk3) 2019년 5월 4일

사실 빡침의 이유는 간단하다. 막 주변에 vim 추천하고 다니는데 정작 vim의 장점을 제대로 설명하지 못하는 것, 그리고 vim의 핵심적인 기능을 끝까지 써보지 못하고 끝이 나도록하는 것이 그것이다. (으... 이런 미친 X을 다 봤나! 라는 생각이 드는가? 그렇다 vim은 제대로 쓰지 않으면 의미가 없다 으하하하)

Vim의 명령어 조합은 상당히 직관적이다. 사실 직관을 넘어서서 단순하다고 하는 게 낫겠지만, 대부분 command mode에서는 대부분 숫자와 키보드의 키 몇 개의 조합으로 대부분 원하는 기능을 뽑아낼 수 있다. KLDP에서 오래전부터 돌고 있던, 이 이미지부터 시작을 해야 할 것 같다.

이 이미지에 겁을 먹을 필요는 없다. 사실 모든 키에는 기능이 하나씩 있다는 것 정도만 알면 된다. 그리고 저기에 있는 키들은 대부분 조합 가능한 형태라는 것이다. 그리고 그 명령어는 현재 커서 위치에 의해서 상대적으로 결정된다.

대표적으로 처음 배우는 명령어 중 외울 만한 녀석은 다음과 같다.

1. 입력 모드 들어가기 (iosa 나 ioas로 외우면 편하다. IOSA의 경우 iosa의 기능의 반전 느낌이다.)

i : 커서 자리부터 쓰기

o : 다음 라인부터 쓰기

a : 맨 뒤에 붙여쓰기

s : 커서가 가리키는 문자 지우고 새로 쓰기

2. 편집 시 사용하는 것

dd : 라인 삭제

yy : 라인 복사

p : 라인 붙여 넣기

u : 되돌리기

U : 되돌린 거 취소

3. 커서 이동

gg : 파일 맨 처음 라인으로 이동

G : 파일 맨 마지막 라인으로 이동

h, j, k, l : 좌, 하, 상, 우 이동

e : 단어 끝으로 이동

w : 다음 단어로 이동

{ , } : 다음/이전 빈 줄로 이동 (문단 시작/끝이라는데 그냥 그건 vim이 그렇게 똑똑하다는 증거가 아니다)

4. 명령어의 조합

{숫자}gg : 숫자에 해당하는 곳으로 커서 이동

{숫자} + h, j, k, l : 숫자만큼 이동

{숫자}w

{숫자}dd

{숫자}yy

...

de

ye

{숫자}de

...

gg=G

...

실제로 vim의 핵심은 명령어의 조합이다.

3de 라던지, 11}, gg=G, 5>>, 3<< 같은 처음 보면 뭐 이딴게 다 있는가라고 느껴지는 것들이 많은데 대부분 이러한 조합에는 대부분 규칙이 있고, 그 규칙만 잘 지키면 상당히 쾌적한 코딩을 할 수 있다. 특히 입력 모드의 경우 다 외워 놓는 게 좋은데, 이건 대부분 강제로 쓰다 보면 외워지게 되는 부분이다. 그리고, 이 명령어들은 .vimrc를 만지지 않아도 대부분 같은 형태로 지원해주고 있으니 이 명령어들을 외우고 다니는 게 핵심이 된다. 그리고, 아마 꾸준한 노력 없이는 hjkl이 아니라 마우스와 키보드 화살표를 사용하게 되는데, 사실 이를 .vimrc에서 막으라는 조언은 듣지 않는 걸 추천한다. 초기 학습 곡선이 엄청나게 높아지는 건 둘째 치고, 숫자 + 명령어 조합에 익숙해지면 어쩔 수 없이 hjkl을 쓰게 된다.

이 이후 매크로나 bottom-line 명령어들을 알아가는 과정이 필요한데, 이 부분은 솔직히 이 글을 쓰는 당사자도 모르는 게 많은 편이다. 문자열 치환이나 검색 같은 건 기본적으로 하지만, 그 이후부터는 정규표현식이나 확장 프로그램에 의존을 많이 하게 되는 편이라서 이 부분은 결국 입맛대로 가게 될 수밖에 없다. 하지만 이 정도면 이미 vim이 왜 좋은지에 대해서는 알 수 있겠고, 서버에서 config 파일 수정할 때나 로그 검색할 때 어쩔 수 없이 vim을 쓰게 될 때에 그나마 도움이 될 것이라 생각한다.

그래서 하고 싶은 말이 무엇인가? Vim은 인외마경이다. 사실 제대로 배우고 쓸 생각을 하는 초보자가 있다면 일단 익숙한 IDE부터 하나는 있어야 할 것이고, 타이핑의 속도나 텍스트 처리의 속도를 높여주는 용도일 뿐이지, 프로그래밍을 더 잘하게 해주는 도구가 아니라는 것을 일단 인지하고 있어야 한다. 어느 정도 익숙해지면 내 생각의 속도만큼 빠르게 텍스트를 변형시킬 수 있다. 정도로 접근을 해야 할 부분이며, 그 이상의 효과를 기대하는 것은 무리이다.

사실 이런 면에서 vim을 사용하도록 장려하는 것이나, vim 좋다는 인식을 주는 것을 반대한다. 모교에서도 1학년 때 vim을 접하고 프로그래밍도 배우기 어려운 상황에서 그지 같은 에디터(그냥 워드프로세서처럼 쓸 수 있는 IDE나 추천할 것이지)랑 씨름하는 것은 어쨌든 도움이 안 되는 게 아닌가 싶고, 대부분 주변 개발자들을 보면 IDE에 vim 익스텐션을 깔지 vim 그 자체를 쓰는 것도 아닐뿐더러, 그렇게 쓰는 사람도 적은 편이다. vim이 좋다고 설파하는 사람들은 특정 언어와 특정 환경에서 사용하는 케이스가 많고, 그런 특정 상황은 대부분 잘 일어나지가 않는다. 특히 수업에서 Python을 vim으로 짜게 하는 경우가 있는데, 것도 2.7 쓰면서 vim 쓰면 좋긴 한가... 그냥 PyCharm 쓰고 Type 관련한 문제 더 빠르게 잡는 게 편할 것이다.

1. 내쉬 균형(Nash equilibrium)의 존재성 글을 읽다가 문득 떠오른 게, 2년 전에 들었던 게임이론(정확히는 게임이론 수업 이후에 듣는 정보경제학) 관련 수업이다. 초반에 Screening 관련으로 배울 때에는 "이게 뭐지 X발"이라는 상태로 들었는데 (두 교수가 돌아가면서 수업을 하는 거였고, 중간고사 이전에는 별 관심도 없었던 파트라서 대충 들었다가 나중에 연습 문제 풀다가 ㅈ되었음을 알게 되었다) Screening에서 어떻게 두 집단을 모델 설계로 분류를 해낼 수 있느냐였다. 보상을 하는 방식을 조절함으로써 어떻게 역선택과 모럴 해저드를 막느냐에 대한 논의가 대부분이었는데, 수업도 대충 들었지, 슬라이드에 내용은 대충대충 설명되어있지, 수업은 한국인 교수가 영어로 하지, 여튼 대 멘붕 상태가 중첩되다가 시험 2주 전에, "현대정보경제학"이라는 책을 어떻게든 찾아내서 연습 문제를 다 풀면서 정보경제학을 간신히 이해한 기억이 난다. 정보 경제학을 다 듣고 나서, 본격적인 게임이론 수업을 하였는데, 이해가 안 되는 부분에 대해서는 박영사에서 나온 "게임이론" 연습 문제를 싹 다 풀었었다. 그럼에도 불구하고, 기말고사에서 내쉬 균형이 존재하는가, 존재하지 않는가에 대한 문제가 연속으로 나와 아주 엿을 제대로 먹었었는데, 대부분 연습 문제의 변형이라서 어떻게든 땜빵을 치긴 했었다. B 맞고 교수님들에게 감사의 기도를 몰래 올렸었던 건 덤이고. 뭐 주저리 주저리지만, 사실 내쉬 균형 잡는 건 솔루션이라고 해야 하나 파훼법이라고 해야 하나 여튼 계산하는 방법이 있으니 그대로 풀면 된다는 친절한 책의 설명과, 교수님의 대충 이 정도면 무조건 나온다는 범위에 대한 귀뜸까지 정말로 많이 배워간 수업이라는 기억이 든다. 사족을 덧붙이면, 게임이론은 컴퓨터 공학이 자랑하는 자기 스스로 개척한 몇 안 되는 학문 아닌가. 그걸 경제대에서 배우고 있다는 건 좀 웃기지만 말이다.

2. 근 몇 개월간 쳐다보지도 않은 블로그를 다시 쓰게 되면서 제일 먼저 보게 된 게 통계 파트인데, 스타트업에서 몰입하게 만든다는 것이 인기 3위를 차지하고 있는 걸 보고 상당히 놀랐다. 약 1년하고도 4개월 전에 쓴 글인데도 블로그 유입의 대부분을 차지하고 있는 거 같아서, 다시 앍어봤는데, 지금 운영하는 스타트업에 대해 반성을 할 계기가 되고 말았다. 2017년이라면, 스타트업 업계에 1.5년 차 플래그를 꼽고 네임드 창업 보육원에서 설치고 있었을 때인데, 그때 각종 대표들과 개발자들을 만나면서 느꼈던 것들이 엄청 많았을 때일 것이다. 학업과 개발을 병행하면서 살았었고, 보육원 생활 6개월 동안 갖가지 일을 다 겪었으면서, C-Level과 일반 직원들에 대한 미묘한 차별, 월급이라는 부분, 열정, 커리어, 그리고 스타트업이 도대체 무엇인지에 대한 생각을 엄청 많이 했었다. 지금 와서 보면, 스타트업은 그냥 중소기업의 열화판이자, 정부 보조금에 빌붙어 사는 무언가가 아니라로 생각이 정리되었지만, 그 당시에는 스타트업은 정말 세상을 바꾸는 무언가라고 믿었을 때이니 정말 고민을 많이 했던 거 같다. 결국, 지금 다시 회고하자면, 그때 만난 대부분의 스타트업이 Class B도 가보지 못하고 엎어졌었고, (임직원 탈주와 사기저하는 덤이고) 한국의 스타트업 열풍은 퇴직자의 치킨집 창업과 원론적으로 무엇이 다른지 모르겠다 인상만 남았지만 말이다. 뭐 건너편에 있었던 두 세 곳은 플래텀 등 각종 언론지에서 투자받고, 성장하고, 신제품을 내놓는다는 이야기를 하지만, 그곳들도 나름 다양한 고충과 실패를 겪었던 걸 기억한다. 한 곳은 시장성이 없는 제품으로 밀고 가다가 다른 제품으로 피벗을 하면서 성공한 케이스고, 딴 스타트업도 IoT 관련 기술에 대한 기술력을 쌓고, (기존 제품의 기능을 대부분 바꾼) 신제품을 내놓고 추가 투자를 받고 성공한 케이스였다. 그 과정에서 정말 많은 것들이 바뀌는 것을 보았다. 사람, 돈, C-Level, 심지어 CEO까지도...

3. 그러고보니 AI 한다는 스타트업 다 어디로 갔나... 10억 투자받은 거기 기억 안 나는데, 여튼 잘들 지내겠지... 하하 블록체인 업계에서는 서로 보지 말자고! (이미 하나 봄)

1. 미디움에서 글을 쓴다는 소리를 약 2년 전에 한 뒤로 미디움이 거지 같다는 글을 쓰기도 하고, 다시 미디움을 쓴다는 이야기도 했지만 솔직히 글을 그렇게 자주 쓰지는 않았다. 트위터라는 배출구도 있었고, 사실상 글을 쓸 여력도, 시간도, 그리고 글감도 그렇게 없었기 때문이라고 하겠지만, 대부분 자기변명에 가까웠던 거 같다. 뭐 사실, 미디움의 편집기가 거지 같아서 쓸 마음이 안 생겼다고 하는 게 좀 더 정확한 말이지만...

2. 티스토리를 버리게 된 계기는 예전 글에서도 서술한 대로, 백업 기능의 폐지였다. 다음카카오, 뭐 정확히는 카카오는 브런치를 밀어줄 것이 뻔하고, 티스토리는 장기적으로 유지보수 단계에서 끝이 날 예정이라는게 자명하기 때문이다. 다음 블로그처럼 티스토리도 중장기적으로 -다음 블로그가 폐쇄 수순을 밟지 않는 이상- 유지되리라고 보고 있지만, 텍스트큐브닷컴처럼 어느 순간 신 플랫폼에 통폐합이 되지 않을까 하는 게 제일 큰 걱정이었다. 특히, 백업 기능이 없는 상황에서 티스토리 셧다운과 강제 통폐합은, 테터툴즈로 옮겨갈 방법도 존재하지 않는 상황에서 약 10년간의 글들이 다 날아가는 최악의 상황이 발생하지 않나 싶은 그런 느낌이었고, 백업 후 블로그 방치라는 방어적인 태도를 취하게 되지 않았나 싶다.

3. 티스토리가 갑작스럽게 신규 에디터 도입을 발표했다. 별 생각은 없었는데, 일단 공지사항을 보니 전체적으로 깔끔해지고, 노력을 많이 했다는 느낌을 받고 있다. 모바일 지원도 안 되고, 크롬에서 최적화 되어 IE 호환은 좀 더 기다려야 한다는 거 보면 상당히 급조를 한 티가 많이 난다. 뭐 그래도, 일단 계속 서비스를 어떻게든 운영하겠다는 의지를 보인 게 아닌가 싶고, 티스토리를 계속 써야 하지 않을까 싶은 계기가 되었다. 솔직히 옛날 세대라서 그런건지는 모르지만 정적 블로그들을 다 싫어하는 편이다. 개츠비건 뭐건 버전 관리보다는 디비가 붙어서 웹에서 편집하고, 웹에서 바로 퍼블리싱 되는 걸 볼 수 있는 걸 더 선호하는데, 아마도 퇴고를 하기 편하다는 것과 이미지 업로드가 거지같이 짜증나기 때문일 것이다. 사실 글에 버전 관리가 필요하다고 해도 위키도 아니고 버전 관리가 얼마 만큼 필요하겠는가?

4. 사실은 SNI 필드 감청 건으로 장문의 트윗을 쓸 일이 있었고, 이를 정리해서 언론 매체에 투고를 했어야했으나 (...) 약 한 달간 잠수를 타고 있는 상황이다. 바쁘다는 핑계도 있고, 뭐 글을 쓸 도구를 제대로 찾지 못했다는 것도 있지만, 역시 블로그를 꾸준히 해오지 않아서 그런 게 아닌가 싶어서, 다시 글이나 쭉쭉 작성하면서 내가 어떤 생각을 하는지, 어떤 걸 하고 싶은지, 뭘 해야 할지에 대한 생각을 정리하는 쪽으로 습관을 다시 고쳐먹기로 했다. 예전에는 블로그 방문자 수를 엄청 따졌는데, 뭐 그때는 어렸을 때이고, 그 누구도 블로그를 주로 사용하지 않고 쓰기 편한 에버노트 (?)처럼 사용하지 않는가. 뭐 나도 그렇게 사용하면 되지 않을까 싶다. 그리고, 이미 기사 내는 건 물 건너갔으니까 여기다 가라도 적어야 하지 않나 싶다.

5. 근데 약간 욕심이 나는 부분이 개발 관련 부분과 개발 관련하지 않은 부분을 나눠야하는가이다. 대부분의 개발 블로그들이 취하는 방법이기도 하고, 사실 RSS 구독하면서 제일 짜증 나는 게 일상 글 섞여있는 블로그인데, .dev 도메인이 풀리기도 하였고, 그냥 기존에 파둔 티스토리 블로그 하나를 개조해서 개발 블로그로 만들면 좀 더 이 블로그에 안심하고 독후감이나 각종 잡다한 이야기를 할 수 있지 않나라고 생각 중인데 양날의 검과 같은 선택이 아닌가 싶다. 사실 기술 글이나 깊은 글을 쓰는 것보다 그냥 이렇게 생각들의 뭉치를 던지는 게 목표였고, 이를 보강한다는 점에서는 좋은 선택이겠지만, 대부분 두 블로그 다 방치 상태로 가는 경우도 많지 않은가...

6. 덧붙여서 블록체인 관련으로 일을 하면서, orbit db 쪽에 관심을 많이 갖게 되었는데, 분산형 스토리지와 DB 조합으로 시스템을 구축할 경우 정적 페이지에서도 비동기적으로 데이터를 fetch 해오면서 동적 페이지처럼 작동하는 형태로 뭔갈 만들 수 있지 않나 싶다. 생각만하고 있지만, 사실 블록체인이나 IPFS 같은 분산 스토리지의 목표는 그런 게 아니어야 하나 싶다. 이 부분은 나중에 적기로 하고... 아니 서비스를 만들고 적기로 하고... 이만 총총

나를 매혹시킬, 나를 움직이게할, 나를 고통으로부터 해방 시킬 무언가를 갈망하며 찾기를 어언 수 년 동안 했던 것 같다. 그러나, 나를 만족시키는 것은 무엇이 있었느냐?라고 되 묻는다면, 나에게는 그렇게 남아있는 것이 없어 보인다. 티끌 하나도 남아있지 않았다고 하는게 좀 더 정확하겠지

많은 사람을 만났고, 실망하였고, 절망하였고, 상처를 주었다.

정말 많은 일들을 했었고, 실패하였고, 포기하였고, 그리고 모든 걸 망쳤었다.

지금은 좀 다를지 모른다. 독특한 사람들의 조합이라던지, 특수한 시장 상황이라던지, 안정적인 인력배치라던지... 하지만, 그게 얼마나 오래 갈 지 모르겠다. 단계적으로 나라는 존재가 정신적으로 무너지는 시점에서 더 앞으로 나아가봤자 의미가 있나 싶다.

패배주의적인 면모라고 비웃었던, 안정된 직장, 안정된 일, 안정된 관계, 그리고 루틴화된 일상이 그렇게 그리우다는 사실만 봐도 이미, 끝날 만큼 끝났다는 느낌이다. 창업 보육원에서의 삶, 나의 목표, 각종 대외적인 활동, 학교, 멘토링 등등... 빛 바랜 추억들만이 내 주변을 맴돌 뿐, 더 이상 앞으로 나갈 무언가가 보이지가 않는다.

어떤 이는 안식을 취하라 한다. 하지만, 잠시만의 안식은 나를 다시 움직이게 할 원동력인가? 빙하에 갇힌 증기선을 생각하라. 지금 당장 증기 터빈을 잠시 안 돌린다고 문제가 될 것은 없다. 그렇다고 해서 빙하에 갇혔다는, 그 문제가 해결 되지도 않을 것 아닌가. 안식은 잠시 동안의 도피처는 될 지 모르겠지만, 해결책은 될 수 없을 것이다.

광야를 떠돌며, 물 한 모금을 찾아 정처 없이 걷는 것 뿐이 나에게 남아있는 길일지도 모른다. 그래, 광야 속에서 그늘 한 켠에서 쉬기는 해야겠지.