가능한 작게 만들자

해커톤이 좀 익숙해지고 나서는 참가할 때마다 팀원들에게 최대한 작게 만들자고 제안한다. 욕심을 버리고 현실적으로 생각해서 뭐라도 데모 때 보여줄 수 있는 걸 완성하려면 이 방법 밖에 없다. 눈속임으로 동작하는 것처럼 보이는게 아니라 정말로 구현하는 것이기 때문에 예상치 못한 복병이 항상 숨어있다. 그래서 시간이 부족하다. 시간이 남는 경우는 거의 없다.

작게 만들자는 제안이 수용되지 않았는데 뭔가 완성된 경우는 없었다. 회의와 토론에 시간을 전부 쓰기 때문이다. 작게 만들기로 약속했더라도 얼마나 작게 만들 것인지는 조금씩 생각이 다른데, 이런 약속이 없다면 구현은 뒷전이고 정말 행사가 끝날 때까지 회의만 한다.

모든 것이 익숙하더라도 단 하나의 챌린지가 있으면 일이 어떻게 될 지 모른다. 해커톤에서는 모든 것이 챌린지다. 처음 보는 사람들끼리 만나 커뮤니케이션이 쉽지 않다. 팀원들의 기술 스택도 일정하지 않다. 마감까지 시간도 짧다. 환경도 열악하다. 와이파이 안 터지면 정말 망한다. 지금 만들고 있는 사이드 프로젝트도 정말 단 하나의 기능만 한다. 하지만 그 하나의 기능이 나에겐 상당히 도전적이다. 그래서 기술적인 문제 때문에 생각보다도 더 오래걸리고 있다.

완벽하고자 하는 욕심을 버려야한다. 내가 표현하고 싶은 가장 핵심적인 부분에만 집중하자. 제품을 더 좋게 할 수 있는 아이디어가 많지만, 핵심 가치에 직접적인 도움이 되지 않는다면 잠시 내려놓아야 한다.

무엇을 만들 것인가

프로그래밍을 공부하면서 내가 학습한 것들은 ‘어떻게 만드는가’에 관한 것이다. 하지만 정말 어려운 것은 ‘어떻게 만드는가’가 아니라 ‘무엇을 만드는가’에 관한 것이다. 작년 한 해는 이걸 깨달은 해였다. 프로그래밍 독학을 막 시작했을 때는 이걸 할 줄 알면 뭐든지 할 수 있을 것 같았다. 하지만 사실이 아니다. 무엇을 만들어야 좋을지 모른다면 어떻게 잘 만들지 알고 있어도 무색하다.

‘어떻게 만드는가’는 쉽게 배울 수 있다. 많은 사람들이 다양한 분야에서 이 고민을 함께 하고 있다. 여러가지 매체를 통해 지식을 습득할 수 있다. 학습의 내용도 상세하고 정확하다. 가끔 성공의 공식도 존재한다. 하지만 ‘무엇을 만드는가’는 배우기 어렵다. 두루뭉술하고 추상적이다. 이게 맞는 것인지 확신할 수 없다. 정말로 ‘무엇을 만드는가’를 잘 아는 사람조차도 이런 지식과 지혜를 제대로 전달하기 어려워하는 것처럼 보인다. 결국 스스로 생각하는 수 밖에 없는 것 같다.

프레임워크, 프로그래밍 언어, 디자인 툴 등 제품을 개발할 때 쓰는 많은 도구들은 점점 사용하기 편하고 개발자의 고민을 줄여주는 방향으로 발전한다. AWS, Google Cloud 등 클라우드 인프라 서비스들을 보면 이런 경향이 뚜렷하다. 초기 클라우드 서비스들은 가상 컴퓨팅만 제공하는 것으로부터 시작했지만 점점 더 관리된 형태(managed)의 컨테이너 기반 서비스를 출시하면서 인프라 운영에 대한 고민을 없애고 있다. 더 나아가 정말로 비즈니스 로직만 고민할 수 있도록 다양한 서비스들을 Serverless화 하고 있다. 심지어 코드 한 줄 없이도 서비스를 만들 수 있는 zero-code 서비스도 여러 클라우드 서비스에서 관심을 가지고 있다고 한다. (하지만 이것도 terraform 코드로 관리하겠지)

이런 경향은 결국 제품 개발의 진입장벽을 낮춘다. 과거에 비해 지금은 더 적은 지식으로도 제품을 만들고 출시할 수 있다. 시간이 흐를수록 ‘어떻게 만드는가’의 중요성은 작아질 것이다. 반면 사회가 복잡해지고 변화가

Yak shaving

원래 목적을 이루기 위해 다른 일을 먼저 하는 것을 야크 쉐이빙(Yak shaving)이라 한다. 요리를 하기 전에 먼저 설거지를 하거나, 시험공부에 집중하기 위해 방청소를 하는 것이 야크 쉐이빙이다.

한 단계정도의 야크 쉐이빙(A -> B)은 괜찮다. 여러 단계(A -> B -> C -> D)라면 문제가 있다. 본래 하고자 했던 일을 시작하기도 전에 지칠 수 있다. 원래 무엇을 하려고 했는지 까먹을 수도 있다. 더 큰 문제는 직접 일을 진행하면서 요구사항을 직면하기 전까지는 이 작업이 몇 단계의 야크 쉐이빙이 필요한지 알기 어렵다는 것이다. 두 단계라고 생각하고 시작했지만 네 단계, 다섯 단계일 수도 있다.

내가 쓰던 블로그를 그대로 두고 텀블러에서 새로 글을 쓰는 이유도 야크 쉐이빙을 없애는데에 목적이 있었다. 이전 블로그는 Github pages 위에서 호스팅했는데 글 쓰는 과정이 매우 길었다. 글을 하나 쓰려면

  1. 컴퓨터를 켜고
  2. 에디터를 켜고 (유튜브도 켜고)
  3. 메모장에서 글감을 가져와 붙혀넣은 뒤에
  4. 마크다운 문법이 올바른지 확인하고
  5. git commit && git push

해야한다. 과정을 줄여보려고 netlify-cms를 블로그에 통합했지만, 속도가 느리고 과정도 별로 줄지 않았으며 모바일에서의 경험이 나빴다. 이전에 썼던 글들도 이미지가 깨져 수정해야한다. 그래도 Github 위에 블로그를 운영하는게 개발자로써 좀 더 있어보인다. 커스터마이징도 자유롭다. 이전 블로그를 계속 가지고 가면서 적용해볼 수 있는 이런저런 솔루션을 찾던 도중에 마음의 소리가 들렸다.

글 안쓰니?

뜨끔. 빠르게 글을 쓰자는 문제 해결에만 집중해 얼른 블로그 플랫폼 하나를 선택했다. 이제는 글감을 붙혀넣고 버튼만 누르면 된다. 모바일에서도 빠르게 글을 쓸 수 있다.

야크쉐이빙은 대부분 욕심이다. 꼭 하지 않아도 원래 목적을 달성할 수 있음에도 더 완성도를 높이고 싶은 마음에 일을 길게 늘어뜨린다. 일을 미루는 습관이 있다면 야크쉐이빙으로

사이드 프로젝트를 하자

사이드 프로젝트를 하자. 업무나 회사일 따위가 아니라 우리가 모든 것을 결정하는 그런 프로젝트말이다. 사이드 프로젝트는 여러분의 결정에 대해 상사나 동료, 클라이언트에게 동의를 구할 필요 없고, 조율과 회의 대신 구상과 실험만 존재하는 아주 멋진 활동이다. 무엇을 할 지, 왜 하는지, 어떻게 할 지 모두 우리가 정하고 책임진다.

사이드 프로젝트의 가장 중요한 목표는 언제나 완성과 배포다. 완성하지 못했지만 되돌아보니 좋은 경험이 되었다고 얘기할 수도 있다. 그러나 제자리를 걸어도 신발은 닳는다. 그러므로 당신이 프로젝트를 완성할 확률을 최대한 높일 수 있도록 계획해야한다. 프로젝트를 완성할 확률을 높이려면 무엇을 만들 것인지, 왜 그것을 만들 것인지, 어떻게 만들 것인지, 이 세 가지를 잘 선택해야한다.

만드는데에 시간이 짧게 소요되는 프로젝트가 좋다. 이 프로젝트를 시작하게 만든 동기가 프로젝트의 완성까지 함께 할 수 있게 만들자. 진행 중에 갑자기 다른 일로 바빠지거나, 새로운 아이디어가 생각나서 지금 프로젝트에 흥미가 떨어진다거나, 번아웃될 수 있다. 이런 상황들은 언제 우리에게 찾아올지 모르고, 찾아오면 제어하기 어렵다. 그렇기 때문에 이런 것들이 찾아올 수 있는 시간을 줄여야한다. 위에서 언급한 무엇을, 왜, 어떻게 만들 것인지를 선택할 때 이 점을 고려하여 선택하자.

나는 무엇인가

물리적으로 무엇을 ‘나’라고 부르는걸까? 먼저 내 신체를 ‘나’라고 부를 수 있겠다. 몸 안에 박은 철심이나 임플란트도 ‘나’에 포함할 수 있는 부분일까? 포스트 아포칼립스 작품들은 신체 일부를 기계로 대체하는 것이 보편화되어 있다. 만약 팔이나 다리가 하나 없는 신체라고 하더라고 여전히 ‘나’라고 부를 수 있을 것이다. 그렇다면 신체를 조금씩 계속 잘라낼 때 ‘내가 내가 아니게 되어버리는 순간(…)’은 언제일까? 언제까지 나라고 부를 수 있고, 언제부터 내가 아닌걸까? 잘려나간 신체는 더 이상 내가 아닌걸까?

개인의 정체성은 얼굴을 통해 형성된다고 한다. 수술이나 사고로 얼굴이 바뀐 사람은 이전 얼굴에 대해 그리움을 느끼는데, 이 그리움은 타인에 대한 그리움과 완전히 동일하다. 영화 뷰티 인사이드에서 자고 일어나면 모습이 바뀌는 우진은 실제 현실에선 제대로 된 생활을 영위하지 못할 것이다. 본인의 정체성에 대한 이미지를 그릴 수 없기 때문이다. 그렇다면 얼굴을 포함한 머리 부분이 ‘나’라고 부를 수 있는 최소한의 영역일까?

좌뇌와 우뇌는 뇌량이라는 부위를 통해 정보를 교환한다. 과거엔 간질 치료를 위해서 이 뇌량을 자르기도 했다. 그런데 이런 치료를 받은 사람들은 독특한 경험을 한다. 좌뇌와 우뇌가 각각의 의식이 있는 것처럼 행동한다. 두 뇌 모두 스스로를 ‘나’이라고 하면서 반대편의 뇌를 ‘나’와는 다른 존재로 여긴다. 뇌량을 자르기 전의 우리의 의식은 어디로 간 것일까? 누가 진짜 나일까?

감각의 필터

우리는 세상을 우리의 몸을 통해 관찰한다. 눈으로 세상을 보고, 귀로 듣고, 코로 냄새를 맡고, 혀로 맛보고, 피부로 사물을 느낀다. 우리는 이 감각들을 통해서만 세상을 파악할 수 있다. 다르게 말하면 우리는 우리 몸에 갇혀있다.

우리는 눈을 통해 사물의 색을 알 수 있다. 우리 눈은 전자기파의 매우 일부분만 볼 수 있다. 이걸 빛(가시광선)이라고 부른다. 물체에서 반사된 가시광선을 통해 우리는 물체의 색깔을 인식한다. 그러나 실제로 사물은 아무 색도 없다.

우리가 특정 영역의 전자기파를 파란색이라 부르기로 약속했다. 하지만 이 파장을 뇌에서 시각적으로 처리하는 방식이 사람마다 다를 수 있다. 당신에게는 파란색으로 보이는 하늘이 나에겐 빨간색으로 보일 수 있다. 하지만 우린 모두 이걸 파란색이라고 부른다.

물질을 이루는 원자의 거의 전부는 빈 공간인데, 마치 꽉 차 있는 것처럼 보인다. 이 세상은 사실 3차원 공간으로 이루어진게 아닐 수도 있다. 눈과 뇌가 현실을 3차원처럼 보이게 우리를 속이고 있을 수 있다. 물질이 실제로 어떤 모습인지 알 수 없다.

시각뿐만 아니라 모든 감각이 이와 같다. 우리는 감각기관이 작동하는 방식으로 세상을 투영한다.

발명과 발견

바벨의 도서관이라는 것이 있다. 호르헤 루이스 보르헤스의 소설 제목인데, 이 소설의 배경이기도 하다. 도서관에 있는 모든 책은 각각 400페이지이고, 한 페이지에는 1600자의 글자가 들어있다. 모든 글자는 알파벳(a-z)과 공백( ), 콤마(,), 마침표(.)로만 구성되어 있다. 도서관에는 이 글자들로 조합가능한 모든 책이 나열되어있다. 대부분의 책은 의미없는 쓰레기고, 가치있는 책을 찾기 위해 사람들이 돌아다닌다.

누군가 도서관에서 ‘무한동력 배터리’의 제조법을 찾기 위해 평생을 바쳤다. 그는 수 많은 책을 살펴봤고 마침내 제조법이 적힌 책을 찾아내었다. 이 제조법을 아직 인류에게 알려지지 않은 것이다. 그는 발명을 한 것일까, 발견을 한 것일까?

이제 도서관 밖을 보자. 누군가 ‘무한동력 배터리’의 제조법을 찾기 위해 평생을 바쳤다. 그는 무수한 가능성을 열어둔 채 수 많은 실험을 했고 마침내 제조법을 찾아내었다. 이 제조법은 위의 제조법과 같은 것으로 역시 아직 인류에게 알려지지 않은 것이다. 그는 발명을 한 것일까, 발견을 한 것일까?

위의 물음과 아래의 물음에 대한 대답이 다르다면 발명과 발견의 차이는 무엇일까?

여러 가능성 중 무언가 만드는 방법을 찾는 것을 우리는 발명이라 불렀다. 그러나 우리 우주에 존재하는 원자의 종류와 개수는 유한하고, 물리법칙은 불변이다. 즉 무언가를 만들 수 있는 경우의 수는 유한하다. 도서관의 책들도 일정한 조건 하에 유한한 가능성의 집합이다. 이 책 더미 속에서 무언가 만드는 방법을 찾는 것을 발명이라고 할 수는 없을까?

도서관의 책과 마찬가지로 우리 우주 안에서 어떤 것이 존재할 수 있는지 없는지는 이미 결정되어있다. 우리가 배운게 틀리지 않았다면 현실에서 ‘무한동력 배터리’는 존재할 수 없다. 어떤 실험을 해도 만들 수 없고, 도서관에서 진짜 ‘무한동력 배터리 제조법’는 찾을 수 없다.

말하는 재미

요즘 친구 H군과 함께 영어로 말하고 듣는 연습을 하고 있다.

영어를 잘하는 이 친구는 군대 때문에 한국에 잠시 왔다가 졸업하기 위해 올해 11월에 다시 미국으로 건너갈 예정이다. 나는 H군이 미국가기 전까지 내 영어 연습을 도와주면 합당한 금액을 주겠다고 제안했고, 그는 돈은 됐고 만날때마다 맛있는거나 사달라고 하면서 딜이 성사됐다. 일주일에 세 번정도 만나는데 맛있는 걸로만 먹으러 다니다보니 매번 밥값만으로도 큰 지출이 발생하고 있다. 그래도 시간을 내준 H군이 고마워서 돈은 전혀 아깝지 않다.

영어를 연습하려면 말을 많이 해야한다. 말을 많이 하기 위해서 H군과 만나기 전에 무엇을 얘기할지 주제를 몇 가지 골라서 간다. 내가 준비한 주제라서 내가 더 많이 알고 있고, 자연스레 더 많이 말을 할 수 있다. 대화는 주제만 딱 얘기하고 끝나지 않고 우리만 알고 있는 이야기나 공통의 다른 관심사로 자유롭게 흐른다.

H군과의 영어 대화는 내게 편하다. 내가 틀린 영어를 쓰지 않을지 걱정하지 않고 자연스레 일단 뱉어본다. 내가 어떤 개드립을 쳐도 이상하게 보이지 않을 걸 알기에 이런 저런 생각을 말로 표현한다. 어떤 단어를 써야할지 모르는 경우엔 듣는 사람이 답답하든 말든 신경쓰지 않고 그 단어의 개념을 풀어서 설명해보려 애쓴다. (이게 더 연습된다는 핑계로 단어는 전혀 외우지 않는다)

나는 말하기보단 듣기를 더 좋아해서 내가 재미있어하는 것들에 대한 이야기를 잘 하지 않는다. 그런데 영어 연습을 하면서 말하기와 친해지려 노력해보니 이게 듣는 것만큼 재미있다는 것을 알았다.

Citizen cb3010-57e를 사다

뜬금없이 시계를 샀습니다. 신경쓰지 않아도 항상 정확한 시간을 보여주고, 너무 조심하지 않아도 스크래치가 잘 나지 않는 시계를 갖고 싶었습니다. 기계식 시계는 당연히 제외하고, 충전이 필요한 스마트워치도 제외하면 전자식 쿼츠 밖에 남지 않더라구요.

쿼츠 시계는 오차를 보정할 수 있는 방법이 많습니다. 전파를 받아서 시간을 보정하는 시계까지는 예전에도 봤었는데, 요즘은 스마트워치가 아니라 일반 시계에도 블루투스와 GPS가 들어갑니다. 아직 모듈의 크기가 커서 그런지 이런 시계들은 약간 크긴 큽니다. 보통 전파시계의 지름이 38~40mm정도 하는반면 GPS 시계들은 42~44mm의 지름을 가지고 있습니다. 손목이 얇은 사람들은 GPS 시계로 캡틴아메리카를 연출할 수 있습니다.

기계식 시계의 매력 중 하나는 배터리가 필요없다는 것입니다. 쿼츠는 시계가 가지 않으면 배터리를 교체해야 합니다. 그래서 이젠 태양빛으로 배터리를 충전합니다. 여러 브랜드에서 다양한 이름으로 부르지만 대체로 기능과 성능은 비슷한 것 같습니다. 책상 구석에 쳐박아두지 않는다면 시계를 차고 다니면서 충전되기 때문에 마르지 않는 구동전력을 얻을 수 있습니다.

스크래치가 잘 나지 않으려면 경도가 강해야합니다. 시계의 케이스로 스테인리스 스틸과 티타늄을 많이 씁니다. 둘의 무게는 차이가 크지만, 경도는 사실 비슷합니다. 그래서 많은 시계 회사들이 이 재료들의 경도를 높히는 기술을 보유하고 있습니다. 하지만 스테인리스는 여전히 무겁습니다. 스테인리스 스틸줄 시계를 찬다면 손목에 스마트폰 하나를 올리고 있는 것과 같습니다.

제가 원하는 조건을 가진 모델이 몇 가지 있습니다. 가볍지만 단단하고, 너무 크지 않고도 오차를 자동으로 보정해주는 태양광 충전 시계. G-SHOCK의 최상위 라인을 제외하면 가격도 비교적 합리적인 편입니다. (여전히 합리적이지 않습니다) 그 중에서 좋은 스펙을 가지고 있지만 디자인이 깔끔한 시티즌의 cb3010-57e를 구매했습니다.

스펙을 나열하자면…

  • 시계 전체 무게가 87g로

Failure building an AWS Lambda custom runtime for Typescript with Deno

Now AWS Lambda supports custom runtime. And there is TypeScript runtime called Deno. Is it possible to run ‘.ts’ in Lambda using Deno? Let’s try it. Never mind the title.

What is Deno

Deno is a secure JavaScript / TypeScript runtime built on V8. It is led by Ryan Dahl who created Node.js. If you are interested in Deno, check his presentation at JSConf EU 2018.

What is a custom runtime

Simply, you can also run a function in any language that is not provided by AWS. A runtime is a program that runs a Lambda function. You can build your own runtime to run some other languages.

Building a custom runtime

Download Deno from Github repository, unzip it, and rename deno_linux_x64 to deno.

.
└─ deno

According to Custom AWS Lambda runtimes, the runtime is responsible for jobs including getting an event and a context, invoking the function, and handling the response or errors. Instead of implementing them, I forked lambci/node-custom-lambda and migrate bootstrap.js code to runtime.ts for Deno. Here is