가능한 작게 만들자

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

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

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

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

무엇을 만들 것인가

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

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

프레임워크, 프로그래밍 언어, 디자인 툴 등 제품을 개발할 때 쓰는 많은 도구들은 점점 사용하기 편하고 개발자의 고민을 줄여주는 방향으로 발전한다. 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군과의 영어 대화는 내게 편하다. 내가 틀린 영어를 쓰지 않을지 걱정하지 않고 자연스레 일단 뱉어본다. 내가 어떤 개드립을 쳐도 이상하게 보이지 않을 걸 알기에 이런 저런 생각을 말로 표현한다. 어떤 단어를 써야할지 모르는 경우엔 듣는 사람이 답답하든 말든 신경쓰지 않고 그 단어의 개념을 풀어서 설명해보려 애쓴다. (이게 더 연습된다는 핑계로 단어는 전혀 외우지 않는다)

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

잘 설계된 DynamoDB 앱은 단 하나의 테이블만 필요합니다

어그로 오지는 이 제목은 아마존 문서에서 발췌했다.

데이터를 어떻게 정의할 것인가

DynamoDB를 처음 접하면서 가장 어려웠던 부분이다. NoSQL 테이블 디자인에 대해 구글링하면서 가장 많이 봤던 문장은

서비스를 먼저 디자인하고 어떤 쿼리가 필요한지 파악한 후 테이블을 디자인한다.

서비스를 운영하면 기능을 변경하거나 추가할 필요가 생긴다. RDB라면 필요한 데이터를 미리 정의해두고 쿼리만 바꾸면서도 기능을 변경하거나 추가할 수 있다. 그런데 저 문장은 마치 NoSQL은 고정된 디자인을 가진 서비스를 위한 데이터베이스라고 말하는 듯 했다.

며칠을 고민하면서 겨우 실마리를 찾은 것 같다. RDB를 쓸 때도 필요하다면 쿼리를 바꾸는 것보다는 비용이 더 들긴 하지만 스키마를 변경할 수 있다. NoSQL을 쓰는 것도 필요하다면 쿼리를 바꿀 수 있다. 다만 이미 저장된 데이터는 기존 쿼리에 최적화되어 있으니, 새로운 형태의 데이터를 저장하면 된다. RDB와는 다르게 중복 저장도 환영이다.

자원이 많다면 가능한 모든 쿼리를 고려하여 데이터를 중복 저장할 수 있다. RDB를 사용할 때처럼 하나의 데이터타입에 하나의 테이블을 사용할 수도 있다. 그러나 DynamoDB의 과금 정책상 이 방법은 효율적이지 않다.

데이터를 어떻게 저장할 것인가

이제 간단한 게시판 서비스를 하나의 테이블만으로 만들 것이다. 물론 코드는 한 줄도 없고, 과정 속에서 서로 다른 형태의 데이터가 어떻게 하나의 테이블에 저장될 것인지 설명한다.


1:1

STORY: 사용자는 이메일로 계정을 생성하고 로그인할 수 있다

사용자 정보를 저장할 테이블을 하나 구상한다.

id (PK) createdAt (SK) email hashed_password
USER-1 createdAt user@email.com password

‘id’ 속성의 USER-1은 데이터의 타입도 함께

프로그래밍에서 창의성이란 무엇인가?

넷플릭스에 알파고 다큐멘터리가 올라와서 봤다. 영상은 이세돌과 알파고의 Google Deepmind Challenge match의 비하인드 스토리를 흥미롭게 풀어냈다. 재미있게 시청중에 이세돌의 멘트에 정신이 번쩍했다.

바둑에 정말 창의성이 필요한가?
바둑에서 창의성이란 무엇인가?

프로그래밍에 정말 창의성이 필요한걸까? 프로그래밍에서 창의성이란 무엇인가?

이런 고민들을 앞서 해본 다른 사람들의 생각을 구글링하여 읽어봤다. 대체적인 의견은 프로그래밍은 예술활동에 비견될 수 있다는 것이다. 이 둘은 결과물을 만들기 위해 여러가지 도구를 다양한 방법으로 사용하여 무엇인가를 만드는데에 그 공통점이 있다.

그렇다면 프로그래밍에서 도구는 무엇이고, 다양한 방법은 어떤 것들이 있으며, 작품은 무엇이란 말이지? 장비와 에디터등 개발 환경이 도구라면, 그 위에서 사용하는 언어와 프레임워크, 라이브러리는 개발 방법인가? 아니면 이런것들 모두 도구라고 볼 수 있으니, OOP나 functional programming 같은 개발 패러다임이 개발 방법인가? 심지어 완성된 코드는 누군가에겐 또 다른 도구가 될 수 있다. 이런 것들을 명확하게 구분지을 순 있는 것인가? 구분지을 필요는 있을까?