TCP 프로토콜에 사망 플래그(DTH) 추가

https://datatracker.ietf.org/doc/html/rfc9401

영화나 만화에서 누군가 죽기 전에 흔히 하는 말이나 행동이 있다. “반드시 살아서 돌아올게”라며 혼자 떠난다거나, 위험하니까 밖에 나가지 말라는 경고를 무시하고 몰래 빠져나오는 행동을 하는 인물은 보통 죽는다. 이런 행동을 하면 죽기 위한 조건을 만족했다는 의미에서 이걸 사망 플래그라고 한다.

TCP 프로토콜에는 메시지의 목적과 상태를 알리기 위해 ACK, SYN, FIN등 여러 플래그가 있다. RFC-9401은 DTH라는 새로운 플래그를 4번 비트에 할당할 것을 제안한다. DTH 플래그는 TCP 세션이 종료될 가능성을 나타낸다. 이 플래그를 사용하면 어플리케이션이 갑작스런 세션 종료에 대비할 수 있다는 장점이 있다. 4번 비트에 할당한 이유는 한자 죽을 사(死)가 숫자 4와 발음이 같기 때문이다. 또 문서에서는 DTH 플래그를 사용하는 예시들을 다양한 작품에 빗대어 설명한다.

• DDoS 공격 중 갑자기 후회할 때 -> 보스에게 배신자로 처단
• 암호화 보호 중지 -> 신원을 숨겨야하는 인물의 베일이 벗겨져 살해
• 프로그램이 메모리를 너무 많이 차지할 때 -> 욕심을 버리지 못하고 집착하다가 사망

상자와 고양이 표기법 (Concat Notation)

https://datatracker.ietf.org/doc/html/rfc9402

인터넷에는 고양이 사진과 동영상이 범람한다. 고양이는 상자나 어떤 용기 같은 것들을 좋아한다. 따라서 많은 고양이 컨텐츠들에서 우리는 용기(CONtainer)와 고양이(CAT)가 상호작용하는 모습을 볼 수 있다. 하지만 현재 우리는 이런 컨텐츠들을 간결하게 설명할 방법이 없기 때문에 RFC-9402는 이를 해결할 표기법을 제안한다. 용기는 [],(),{}의 괄호를 사용하며, 고양이는 cat를 사용한다.

• [c]at: 박스에 머리를 박고 있는 고양이
• [cat] + cat: 박스 안에 고양이와 그 옆에 고양이

AI를 위한 비꼬기와 풍자 감지 가이드라인

https://datatracker.ietf.org/doc/html/rfc9405

요즘 ChatGPT는 인간의 풍자와 비꼬기를 이해하는 것에 어려움을 겪고 있는 것 같다. 사람이 비꼰 것을 이해하지 못하고 글자 그대로 받아들인다거나, 스스로 비꼬아서 말하기를 시도해보다가 선 넘는 발언을 해서 많이 혼났나보다. 이 RFC는 ChatGPT가 제안한 것으로, AI에게 어떻게 풍자를 학습시킬 수 있는지 가이드라인을 제시한다. 나 좀 이렇게 가르쳐줘 애원하는 느낌이라 뭔가 웃기다. 뭐 대단한 방법을 원하는 건 아니고 비꼬는 언어와 비꼬지 않는 언어 샘플 데이터로 지도학습을 받길 바라고 있다.

문서를 보면 전체적으로 ChatGPT의 고민을 엿볼 수 있는데, 상대가 불쾌감을 느끼지 않고 공격적으로 보이지 않으면서도 효과적인 비꼼의 적절한 수위가 어느정도인지 감을 잡지 못하고 있는 것 같다.

Peter Thiel, Elon Musk, Reid Hoffman, Marc Benioff, Sam Altman 등이 후원하는 비영리 인공지능 연구기관 OpenAI은 세번째 언어 예측 모델(GPT-3)을 오픈소스로 공개했다. 언어 모델들은 컴퓨터가 주어진 문자열과 비슷한 길이와 문법 구조를 가진 문장을 무작위로 만들어낼 수 있게 한다.

GPT-3와 함께한 나의 초기 실험에서 bitcointalk.org 포럼에 올린 GPT-3가 만든 문장들이 그곳의 작성자들로부터 긍정적인 관심을 이끌어냈음을 목격했다. 그들은 이 시스템이 지능적이며(그리고/또는 빈정대며) 이것의 게시글에서 미묘한 패턴들이 발견되었다는 제안도 포함했다. GPT-3의 출력물들을 다른 게시판, 블로그, 소셜 미디어에 다시 올려도 비슷한 결과를 얻을 수 있으리라고 나는 생각한다.

이것의 이전 두 모델들(PTB와 OpenAI GPT-2)와 달리 OpenAI GPT-3은 마침내 다양한 커뮤니티에서 텍스트의 작성자가 취향을 가진 사람인 척하는데에 널리 사용될 것이고, 예측불가능하고 놀라운 효과들을 가져올 것이라고 나는 예상한다. 더 나아가 이것이 유능한 아마추어들 사이에서 이것과 유사한 모델들을 학습시키고, 다양한 목적(모의 뉴스, “연구된 저널리즘”, 광고, 정치, 프로파간다를 포함)에 적용하기 위한 창조적인 골드 러시를 촉발할 것이라고 나는 예상한다.

당신을 도와 주는 사람이 있는가?

나는 다양한 이유들로 내 실험을 위해 목표 환경으로 bitcointalk.org를 골랐다. 이곳은 다양한 종류의 작성자들과 게시글이 있는 유명한 포럼이다.

그래서 GPT-3이 공부하고 학습하기 위한 많은 게시글들이 있다. 이 포럼은 또 내가 좋아하지 않는 많은 사람들이 있다. 나는 그들이 새로운 작성자를 가질 가능성에 의해 비정상적으로 흥분하기를 기대한다. 나는 이 포럼을 여러해동안 봐왔다. 내가 답을 아는 많은 게시글들이 있는데, 그래서 나는 빠른 응답을 제공할 수 있었고, GPT-3이 얼마나 내 코멘트와 비슷하게 잘 할 수 있는지 측정할 수 있었다.

나는 5월에 GPT-3의 도움과 함께 내 이전 게시글에서 내가 쓴 단어와 구문을 바꿔가면서 매일마다 흥미로운 기술 토픽 하나를 게시했다. 나는 GPT-3이 강화한 게시글들이 잘 어울리도록 특별히 신경쓰지 않았다. 나는 GPT-3이 이전에 말했던 것을 보고 어떤 것을 내놓을지 흥미가 있었다. 아래 표는 결과 중 일부를 보여준다:

PTB처럼 GPT-3도 이 포럼에 이미 존재하는 밈에 대한 것이 대부분이고, 신선한 생각을 만들어내는 데 어려움을 겪으리라는 것이 나의 기대였다. 이 예측은 사실인 것 같다. 종종 포럼에서 최근 몇 년 간 봇에 의해 생성되는 밈이 매우 성공적이였기 때문에 이것은 놀랍지 않다.

그래도 GTP-3는 여전히 꾸준하게 발언으로 날 놀래켰기 때문에, 나는 이 시스템과 이것 같은 다른 시스템을 통해 개선될 여지가 있을 것이라고 기대하고 있다. 이것은 “AI”가 무엇을 가져올지에 대한 취향이고, “AI 혁명”이 이 정보 전쟁에 태울 연료를 많이 가지고 있을 것이라고 나는 상상한다.

내가 이 포럼에 직접 글을 썼을 때, 사람들은 내가 매우 빠르게 글을 쓸 수 있고/있거나, 매우 정확하고/하거나, 다른 사람과 같은 말을 하는 “봇”일거라고 자주 말했다. 아래 스크린샷은 GPT-3이 응답하는 여러 쓰레드의 답글들을 보여준다. 이 모든 것이 지난 며칠 동안 bitcointalk.org에 게시되었다. GPT-3은 매우 인기있었고, 현재 새로운 추종자들을 끌어들이고 있는 것 같다.

AI로 가는 길에서

나는 최근 어떻게 OpenAI가 그들의 최신 언어 모델을 만들었는지에 대한 팟캐스트를 봤고, 이런 시스템으로 무엇을 할 수 있을지 궁금해졌다. 나는 이런 기술을 어떻게 응용할지와 어떻게 우리 삶을 개선할 수 있을 지에 대한 생각을 멈출 수 없었다. 오직 GPT-3의 출력물들만 있는 트위터 같은 서비스를 만드는 것이 얼마나 멋진지 생각했다.

이 시스템은 초기 프로토타입이며 이것의 동작은 훈련된 실제 AI의 행동과 비교할 수 없다. OpenAI GPT-3가 답글을 예측할 수 있는 것처럼 보이지만, 자신의 게시글에 대해 항상 답글을 예측하는지는 않으며, 예측된 답글이 관련성이 있거나 올바른 경향이 있지는 않다. 대부분의 케이스에서 설득력 있는 답글을 예측했던 프로토타입은 내가 여기서 설명하는 GPT-3보다 훨씬 인상적일 것이다. 비록 수년간의 학습과 모델 개선의 반복이 요구되지만 말이다. 나는 단지 유능한 인간 운영자가 OpenAI GPT-3와 같은 시스템으로 무엇을 달성할 수 있을지 상상하고 있을 뿐이다.

이제 재미있는 부분

고백할 게 있다. 난 위의 글을 쓰지 않았다. bitcointalk에 글을 쓰는 어떤 실험도 하지 않았다. 사실 이 포럼을 수 년간 접속도 안했다! 실험은 내 블로그에서 진행했다. 이 글은 완전히 GPT-3가 혼자 썼다. 혹시 미리 눈치 챘는가? 난 어제 OpenAI API에 접근권한을 받았고 믿을 수 없는 결과들 가운데 일부를 트위터에 올렸다. 이 블로그 글은 GPT-3의 엄청난 힘을 보여주는 또 다른 시도였다. 아래는 내가 이 모델에게 제공한 입력값이다. 이 블로그의 홈페이지에서 복사했다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Manuel Araoz의 개인 웹사이트

Bio
나는 부에노스 아이레스 공대에서 컴퓨터공학을 전공했다. 나는 아르헨티나 부에노스 아이레스에 위치해있다. 내 이전 업무는 주로 암호화폐, 분산 시스템, 기계 학습, 상호작용, 로봇 공학에 관한 것이다. 내 목표 중 하나는 기술을 통해 사람들에게 새로운 경험을 제공하는 것이다.

나는 OpenZeppelin을 공동설립했고 CTO였다. 현재는 음학, 생물학 + 신경과학, 기계학습 그리고 물리학을 공부하고 있다.

Blog

2020년 7월 18일
제목: OpenAI의 GPT-3는 비트코인 이후 가장 대단한 것일지도 모른다
태그: 기술, 기계학습, 프로그래밍
요약: OpenAI의 새로운 언어 예측 모델(GPT-3)의 베타 버전과 함께 한 나의 초기 실험 공유한다. 내가 왜 GPT-3이 블록체인 기술에 버금가는 파괴적인 잠재력을 가지고 있다고 생각하는지 설명한다.
본문:

그리고 이 모델이 생성한 글자 그대로를 복사했다. 사소한 띄어쓰기나 부호만 수정했고 다른 문자는 바꾸지 않았다. 필체가 내 것과 어느정도 일치한다고 느낄 때까지 몇번(10번 미만)의 다른 결과들을 만들어 냈고, 공개했다. 커버이미지도 추가했다. 내가 놀랐던 것처럼 여러분도 이 결과의 품질에 놀랐길 바란다.

즉, 나는 GPT-3이 내가 봐왔던 주요 기술 발전 중 하나라고 믿으며, 더 많이 가지고 놀 수 있기를 기대한다! 매우 이상한 시대가 다가오고 있다…

원문을 읽을 때 느낀 이상한 위화감을 번역문에도 녹여보려 했다..

GPT-3에 djbaskin의 사업 목록을 입력하고 나온 새로운 프로젝트 아이디어들 중 일부를 트윗했다.

• 텐트스타터(Tentstarter) - 텐트 자체가 금융 상품 역할을 하여 투자자들이 전업으로 홈스테딩에 자금을 지원할 수 있게 합니다.

• 무지개링 트램펄린(Slinky Trampoline) - 기계로 구동된 자기(magnetic) 운동을 하는 증폭된 트램펄린으로, 사용자가 더 높게 뛸 수 있습니다.

• 진짜 좋은 랜딩 페이지(A Really Good Landing Page) - 전환율을 위해 랜딩 페이지를 자동으로 최적화하는 소프트웨어.

• 사람 나무(Trees As People) - 말 그대로 사람으로 만들어낸 가로수.

• 로고 상어(Logo Shark) - 사무실용 로고 상어 벽지. 상어는 여러분 회사에 대해 모든 것을 알고 있습니다.

• 나의 브랜드(Brand of Me) - 개인 브랜드 모니터링 서비스. 우리는 여러분 이름에 대한 상표권을 제출하므로, 누가 당신의 이름을 쓸 지 결정할 수 있습니다.

• 이케아 붕괴 장치(IKEA Fall Gadget) - 심각한 부상 방지를 위해 허리케이 발생하면 무너지도록 설계된 이케아 의자.

• 주걱 복장(Spatula Wear) - 우리의 로고가 인쇄된 주걱. 첨단 기기들은 주걱을 못 찾지만, 우리는 찾을 수 있다.

• 대용 동물와 후보 동물들(Surrogates & Subs) - 실제 애완동물을 대용 또는 대체하는 3D 프린터로 만든 수제 소품.

• 틴더맘(Tindermom) - 기술적인 지원 문제로 도움이 필요한 엄마들을 위한 틴더.

• 천국 대 지옥(Heaven vs. Hell) - 두 가지 웨어러블 프로젝트. 하나는 선, 하나는 악.

• 포트폴리오에 죽을 확률을 쓰세요(Put My Mortality On My Portfolio) - LED 큐브 안에 있는 암호화폐 지갑.

• 둥지를 위헤 그렇다고 대답해(Say Yes To Nesting) - 새로운 메시지가 인쇄되어 있는 새 둥지 상자.

• 커버웜(Coverworm) - 바퀴살에 컬터 테이프를 감아 자전거 바퀴를 예술 작품으로 만듭니다.

• 비밀상점(The Secret Store) - 우리는 기업들을 위한 초대 전용 매장을 구상하고 만듭니다. 우리 고객으로는 스냅챗(Snap Inc.), 포르쉐(Porsche), 넷플릭스(Netflix)가 있습니다.

• 복잡해(It’s Complicated) - 혼란스러운 알고리즘을 기반으로 한 무의미하지만 호기심 많은 제품.

• 스케이트 인형(Skate Doll) - 받는 사람과 비슷한 모습을 가진 60인치 스케이트 인형. 여러분의 옷을 입고 개인화된 영상을 만듭니다.

• 3D 웜홀(3D Wormholes) - 당신을 현실에서 다른 차원으로 이동시키는 움직이는 gif.

• 우린 메일 받았어(We’ve Got Mail) - 우리가 받는 이메일의 물리적 버전을 보내서 물리적 세상을 통해 인터넷을 탐색합니다.

• 사이보그 차(Cyborg Tea) - 스마트홈 찻주전자에 사용하는 헐거운 프리미엄 잎차.

• 블록폴리오(Blockfolio) - 암호화폐 사용자를 위한 포트폴리오 트래커 앱.

• 뭉클한 로고(Lumpen Logo) - 염치없는 따분함.

• 창립자를 만나라(Meet A Founder) - 창립자와 CEO들이 커뮤니티에 자신을 소개합니다. 우리는 개인적 만남을 제공합니다.

• 커피빈 주식회사(The Coffee Bean Co.) - 커피 콩을 맞춤형 로스팅해 출력.

• RSS선원(RSSailor) - 광고 없음. 추적 없음. 오직 질 높은 기술 뉴스만 있는 RSS 피드. 구글 리더 사용자를 위한 나중에 읽기 확장 프로그램.

• 힐링 브레인즈(Healing Brainz) - 머리 아플 때를 위한 셔츠가 있는 티셔츠 줄. 이건 말장난이고, 또 불안, 스트레스, 우울증의 증상입니다.

• 폴리그라인드(Pollygrind) - 성장한 이후 활동 스포츠 - 우리는 존재하지 않는 가짜 제품을 액션 스포츠에서 영감을 얻어 실제 버전으로 만듭니다.

• 나는 문이다(I’m a Door) - 티셔츠를 입은 몸통을 오려낼 실제 크기의 재단선.

• 터치기반 주조공장(TouchBase Foundry) - 블록체인을 위한 로고를 찾는 벤처 캐피털 디자인 주조공장.

• 벌집 도시(Hive City) - 개인, 가족, 친구들과 공유할 수 있는 루프탑이 있는 Gensler가 세운 육각 벌집형 주거지.

• 책상 없는 사서함(The DeskLess Mailbox) - 책상없는 사람들을 위해 바닥에 설치된 사서함.

• 두꺼운 피부 유한책임회사(Thick Skin LLC) - SNS 마케팅, 브랜드 아이덴티티, 웹 사이트 디자인 전문.

• 공식 불만 신고자(The Official Complainer) - 다른 사업체에 불만을 제기할 수 있는 사업.

• 낚시 동영상 (Video2Fish) - 물고기를 잡을 수 있도록 물고기 잡는 법을 담은 비디오를 보냅니다.

• 무한 옷장(Infinity Closet) - 옷장 정리를 위한 물리적 서비스로 옷장에서 모든 것을 꺼내 정리하기 쉽게 다시 넣어줍니다.

• 유명상표 봉제인형 쥐어짜기(Branded Squeeze Plush) - 기업 파트너가 촉감있는 참여를 보다 많이 할 수 있도록 유명 상표의 질척이는 비트들이 있는 부드러운 장난감들.

• 분산 벤처 캐피탈 펀드(Decentralized Venture Capital Fund) - $10를 넣으면 $20를 받을 수 있는 벤처 캐피탈 펀드.

• 주식 냄비(Stock Pot) - 각자 조금씩 모금해서 함께 나누는(potlucks) 개인 모금 웹사이트.

• 유형 지우기(Clear Type) - 아름답고 선별된 인스타그램 계정들에 대해 고정된 금액을 지불하세요. “플라토닉 인스타그램”입니다.

내가 가장 좋아하는 유튜브 채널 중 하나인 Game maker’s toolkit의 Mark brown이 플레이어가 잘 만들어진 퍼즐을 풀 때 어떤 요소가 있었는지 본인만의 방식으로 풀어두었길래 정리해 보았다.

1. Mechanics - 규칙과 제약

Mechanics은 게임이 어떻게 돌아가는지 규정하는 규칙과 제약을 의미한다. 이 mechanics으로 퍼즐을 만들 수 있다. 따라서 mechanics가 퍼즐의 수와 난이도를 결정한다. mechanics을 증강시키기 위해 다양한 요소를 이용할 수 있는데, 이런 요소는 임시적일 수도 있고, 계속 mechanics에 포함될 수도 있다.

2. Catch - 문제

Catch는 얼핏 보면 해결하기 불가능해 보이는 문제를 의미한다. 플레이어는 퍼즐 풀기를 시도하면서 몇 가지 액션 조합을 사용한다. 이때 이 액션 조합들이 논리적으로 충돌해 목표까지 갈 수 없다는 것을 깨달았을 때 catch를 발견한다. 이 때 플레이어는 액션 조합의 순서를 바꾸거나 해결 방법을 완전히 바꾸는 식으로 다시 접근한다.

3. Revelation - 발견

플레이어는 catch를 해결하기 위해서 생각의 틀을 깨려고 하거나 mechanics에 대해 다시 고민한다. 플레이어가 해결책을 찾아낸 순간이 Revelation이다. 이 때 플레이어는 스스로 똑똑하다고 느낄 수 있다(이게 퍼즐 게임의 실질적인 보상이라고 생각한다). 이렇게 찾아낸 해결책은 플레이어의 무기가 되고 다음 문제를 풀 때 사용할 수 있게 된다.

4. Assumption - 추정

Assumption 이란 플레이어가 이렇게 하면 문제를 풀 수 있겠지하고 예상하는 것이다. 퍼즐은 플레이어가 assumption 을 통해 catch를 발견하도록 해야하는데, 그 이유는 다음과 같다.

1. 플레이어가 해법을 안다고 생각하게 만드므로, 새로운 퍼즐에 압도당하지 않고 실제로 퍼즐 풀기를 시도하게 한다.
2. 잘못된 assumption 으로 첫 시도를 실패하면서 퍼즐이 어떻게 동작하는지 깨닫고, catch가 어떻게 만들어졌는지에 대해 이해한다.
3. 플레이어가 첫 시도에 퍼즐을 못 풀 것을 보장한다. 바로 풀 수 있을 것이라고 생각했지만 catch를 만나고 당황할 것이다.
4. 플레이어가 퍼즐의 진짜 목표에 집중할 수 있게 해준다.

5. Presentation - 제시

Presentation은 퍼즐이 배치된 방식을 뜻한다. 플레이어에게 어떤 정보를 제공하냐에 따라 난이도가 달라진다. 퍼즐게임은 미니멀한게 좋다. 퍼즐과 관련있는 요소만 남겨둬서 플레이어가 퍼즐을 가장 단순하게 이해하는데에 도움을 줘야한다. 퍼즐이 어떻게 구성되어 있는지 알아내게 하는 것은 시간낭비다.

6. Curve - 학습곡선

모든 퍼즐은 이전 퍼즐에서 새로운 레이어를 추가하는 식이여야 한다. 플레이어는 앞서 학습한 모든 요소를 이용하려고 할 것이고, 점점 난이도가 높아져야 만족할 수 있기 때문이다. 따라서 퍼즐을 난이도 순으로 정렬할 필요가 있다. GO 시리즈를 만든 Square Enix Montreal에서는 아래와 같은 4가지 난이도 기준을 제시해 퍼즐의 난이도 순위를 정한다.

• 솔루션의 수가 많아지면 퍼즐이 쉬워진다.
• 해결까지의 스탭 수가 많으면 퍼즐은 어려워지지만, 또 너무 많으면 지루하다.
• 스탭마다 플레이어가 선택할 수 있는 가지 수가 많으면 어렵다.
• 플레이어가 mechanics에 익숙할수록 쉽다.

온칼로는 지질학적으로 18억년동안 안정적인 곳 지하 500m 깊이에 약 100년동안 방사능 폐기물을 저장한 후 닫힐 예정이다. 이런 폐기물들은 10만년이 지나야 위험성이 사라진다. 온칼로의 목적은 이 10만년동안 인간이나 다른 생명체로부터 폐기물을 안전하게 격리시키는 것이다. 때문에 온칼로는 폐쇄된 후 완전히 묻힐 예정이다. 온칼로가 지상에 노출된다면 지구는 더 이상 생명체가 살 수 없는 행성이 되고 말 것이다.

온칼로는 긴 시간이 지나면 아예 사람들에게 잊혀질 것이다. 그러나 외부인의 침입이 없으리라고는 장담할 수 없다. 먼 훗날 누군가 온칼로를 발견했다면, 이것이 무엇인지 이해할 수 있을까? 이들에게 이 곳은 위험한 장소니 돌아가라고 어떻게 경고할 수 있을까? 당신이 하려고 하는 그 행동이 돌이킬 수 없는 끔찍한 결과를 만들어 낼 것이라고 어떻게 알릴 수 있을까? 그들이 이 경고의 진심을 의심없이 받아들이도록 하려면 어떤 방법이 필요할까?

글이나 그림을 남겨 경고하는 방법은 통하지 않는다. 언어도 다를 것이고 문자도 다를 것이다. 지금과 비교해서 얼마나 문명이 발달해 있을지 알 수 없다. 어떤 경고나 표식이 이들에게 어떤 영향을 미칠지도 알 수 없다. 접근을 두려워하게 만들 수 있겠지만, 도리어 호기심을 불러일으킬 수도 있다. 발견자는 인류가 아닌 새로운 지적 생명체 일 수도 있다. 모든 생명체가 이해할 수 있는 보편적인 의사소통 방식은 존재할까?

10만년은 정말 긴 시간이다.

이런 생각은 백 년 전 ‘무한 원숭이 정리’로 처음 제시되었다. 원숭이에게 타자기를 주고 아무거나 입력하게 시킬 때, 무한한 수의 원숭이와 무한한 시간이 주어진다면 프랑스 국립 박물관의 모든 책을 정확하게 찍어낼 것임이 거의 확실하다는 정리다. 여기서 ‘거의 확실하다’는 확률의 극한 값이 100%라는 의미다.

‘무한 원숭이 정리’에서 첫 책을 찍어낸 원숭이가 또 다른 책을 찍어낼 확률이 다른 원숭이보다 높을까? 아니다. 최근 세렌디피티(우연한 과학적 발견)의 극대화를 위해 실험실 예산을 어떻게 배분해야하는지를 탐구하는 연구가 있었다. 연구는 모든 실험실에 예산을 골고루 분배했을 때 세렌디피티가 가장 높아진다는 결과를 보여주었다. 무작위로 랜덤하게 배분하는 방법도 답이 아니였고, 과거 성과가 좋은 실험실에 집중해서 배분하는 방법도 답이 아니였다.

시도의 횟수가 무한하면 아주 작은 확률이라도 반드시 발생한다. 시도의 횟수가 적당히만 많아도 평범하지 않은 결과가 발생한다. 그럼에도 불구하고 우리는 운을 감지하지 못한다. 결과의 원인을 계속 분석하며 패턴을 찾으려고 한다.

수명의 관점에서 인류의 마지막 5만년을 보면, 진보의 속도를 쉽게 알 수 있다. 5만년의 시간은 800명의 수명으로 환산된다. 그러나 이 800명 중 650명은 동굴 또는 그보다 못한 곳에서 살았고, 마지막 70명만이 타인과 효과적으로 소통할 수 있는 수단을 가졌으며, 마지막 6명만이 인쇄물을 보거나 온도를 측정할 수 있었고, 마지막 4명만이 시간을 정확히 잴 수 있었고, 마지막 2명만이 전기모터를 사용했다. 우리의 물질 세계를 구성하는 대부분의 것들은 마지막 800번째 사람의 수명 내에 개발된 것들이다.

언어와 문자, 종교, 이념과 사상, 경제 체제, 사회 시스템, 지명과 도로와 건물, 사람의 생애주기까지 모든 것들이 의도했든 하지 않았든 우리와 같은 누군가가 만들어낸 것이다. 그것도 아주 최근에 만든 것들이다. 지금까지 우리는 시간의 길이를 과장해서 생각했기 때문에 이런 것들이 전통이 있고, 절대적인 가치라고 생각한다. 14세기 고려 말기를 살던 사람은 지금 우리와 매우 먼 것처럼 느껴지지만, 실제로는 아주 작은 시간적 차이 때문에 만나지 못했다. 하지만 이들과 우리는 사는 방식과 환경이 매우 다른데, 이것은 우리를 둘러싼 모든 것들이 생긴지 얼마 되지 않았음을 보여주는 증거다.

인류의 역사는 아직 무척 짧다. 인류 최초의 건물은 약 12000년 전에 세워졌는데, 지금 우리가 사용하는 달력의 연도에 10000을 더하면 인류 진보의 시간과 맞아 떨어진다. 올해를 2020이 아니라 12020년으로 보면 인류의 역사에서 지금 우리가 어디 쯤 있는지 조금 더 알기 쉽다. 자연적으로 존재했고, 지금까지 항상 있어왔으며, 영원히 변하지 않는 것은 없다. 우리가 당연하다 여겼던 모든 것들은 결국 우리가 만든 것이다. 그럼에도 우리의 생각과 행동은 이 틀에 갖혀있다.

아주 오래전에 같은 내용의 글을 이전 블로그에 올렸었다. 지금 보면 이것은 카오스 이론에 대한 이야기다. 지프의 법칙과는 연관 짓기 어렵다. 하지만 조금 더 확장해서 생각해 볼 가치가 있는 현상이다.

로또 추첨은 매 회차가 독립시행이다. 앞선 회차의 결과들이 다음 회차에 전혀 영향을 미치지 않는다. 지금까지 36번 공이 많이 뽑혔다고 해서 이번주 토요일에 36이 또 나올 확률이 높아지지 않는다. 우리 주변에도 로또처럼 독립시행인 사건이 많다. 하지만 독립시행 사건에 사람의 마음이 개입하면서 종속시행이 된다. 로또로 치자면 36이 나올수록 36이 또 나올 확률이 점점 높아지게 변한다.

근근이 매출을 유지하는 식당이 방송에 나온 것도 아닌데 갑자기 손님이 많아진다. 손님의 방문이 독립시행에서 종속시행으로 변하는 순간이다. 이전에 왔다간 손님 중 누군가가 다른 사람에게 영향력을 미쳤기 때문이다. 해외여행을 갈 때, 맛집을 검색해서 가보면 온통 한국인 뿐이다. 누군가 우연히 아무곳이나 들렀고 자신의 블로그에 글을 남겼다. 사람들은 식당을 검색하고 이 글을 읽고 또 글을 남긴다.

주식차트도 비슷하다. 과거의 데이터는 미래 주가를 예측하는데에 아무런 도움이 되지 못한다. 하지만 누군가가 ‘이런 패턴일 때는 주가가 떨어진다’라고 한다면, 실제로 그런 패턴이 나타났을 때 사람들은 주가가 떨어질 것이라고 생각해서 주식을 판다. 사람들이 주식을 팔기 때문에 주가도 정말 떨어진다.

나머지 80% 기능을 포기해도 괜찮다는 이야기가 아니다. 이 80%의 기능이 없다면 온전한 제품이라 부를 수 없다. 그러나 우리는 자원이 한정된 환경에 있기 때문에 효율을 고려해야한다. 핵심 기능은 조금만 개선되어도 사용자가 쉽게 눈치채는 반면, 나머지 기능은 갑자기 없어져도 잘 모른다. 잘 쓰이지도 않는 하위 80%의 기능을 개선하기보단 핵심적인 20%에 우리의 시간과 노력을 쏟는 게 낫다.

사이드 프로젝트는 극단적인 자원 부족 환경에 놓여있다. 처음부터 모든 사용자를 만족시키려고 다양한 선택지를 제공하다가는 아무것도 완성하지 못한다. 20%의 핵심 기능만 제공하는 초창기 제품은 거의 프로토타입에 가까울 수도 있을 것이다. 그러나 조금 부족하더라도 계속해서 제품을 개선하는 모습을 보여준다면 사용자들은 당장 나머지 80% 기능이 없더라도 같이 만들어나간다는 느낌을 줄 수 있을지도 모른다.

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

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

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

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

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

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

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

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

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

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

글 안쓰니?

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

야크쉐이빙은 대부분 욕심이다. 꼭 하지 않아도 원래 목적을 달성할 수 있음에도 더 완성도를 높이고 싶은 마음에 일을 길게 늘어뜨린다. 일을 미루는 습관이 있다면 야크쉐이빙으로 포장할 수도 있겠다. 해야만 하는 일을 마주하기 두려워 곁가지만 계속 쳐내고 있지는 않은지 생각해보자.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1:1

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

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

‘id’ 속성의 USER-1은 데이터의 타입도 함께 포함한다. 이것은 하나의 테이블에서 서로 다른 데이터를 구별하기 위한 방법으로 아래와 같은 형태를 가진다.

1

[DATA_TYPE]-[IDENTIFIER]

다음으로 이메일을 사용자 데이터와 따로 저장하기로 했다고 하자. 이제 새로운 데이터 형태를 하나의 테이블에 저장한다.

USER와 EMAIL은 1:1 관계다. 특정 사용자의 이메일을 불러오려면 먼저 USER-1을 쿼리하여 EMAIL-1을 얻고, 다시 EMAIL-1을 쿼리하여 ‘user@email.com‘을 얻는다.

하나의 테이블에 다른 데이터 형태가 있다보니 각 속성의 명칭과 내용이 다를 수 있다. 속성명을 일반화하자. NoSQL은 스키마가 정해져있지 않으니 새로운 속성이 필요한 데이터라면 얼마든지 속성을 추가할 수 있다.

USER-x로 이메일을 찾을 수 있지만, 이미 가입한 사용자가 맞는지 확인하려면 이메일로도 사용자를 찾을 수 있어야 한다. 이메일로 사용자를 찾을 수 있도록 GSI 추가한다.

1
2
3
4
5
6

# Find email by user
email_id = SELECT Data FROM TABLE WHERE PK="USER-1"
email = SELECT * FROM TABLE WHERE PK="EMAIL-1"

# Find user by email
user_id = SELECT id FROM GSI WHERE Data="user@email.com"

1:N

STORY: 사용자는 게시글을 작성할 수 있다

새로운 데이터타입 POST의 형태는 아래와 같다.

사용자가 여러 POST를 가질 수 있도록 POST의 ‘Data’에 USER 키를 저장한다.

1
2
3
4
5

# Find user id by post
user_id = SELECT Data FROM TABLE WHERE PK="POST-1"

# Find post ids by user
post_ids = SELECT PK FROM GSI WHERE Data="USER-1"

다중 종속

STORY: 모든 게시글은 카테고리로 분류할 수 있다

카테고리 데이터타입 CATEGORY도 POST와 1:N 관계가 있다. 하지만 POST 타입의 ‘Data’는 USER의 외부키를 저장하는 용도로 쓰이고 있기 떄문에 위의 디자인은 사용할 수 없다.

관계에 대한 새로운 데이터타입을 만든다. 기존 ‘Data’에 외부키는 새로운 관계 데이터로 옮긴다.

관계 데이터타입의 ‘id’ 속성 포맷은 다른 데이터타입과 명확하게 구별된다. 이것은 하나의 테이블에서 서로 다른 데이터를 구별하기 위한 방법으로 아래와 같은 형태를 가진다.

1

[PARENT_ID]:[CHILD_DATA_TYPE]

USER-1:POST는 USER-1이 소유한 POST에 대한 정보를 가지고 있다. 만약 USER-1이 POST-2도 소유하고 있다면 이런 데이터를 추가한다.

1
2
3
4
5
6
7
8
9
10
11

# Find user id by post
user_id = SELECT PK FROM GSI WHERE Data="POST-1" AND PK=begins_with("USER")

# Find category id by post
category_id = SELECT PK FROM GSI WHERE Data="POST-1" AND PK=begins_with("CATEGORY")

# Find post ids by user
post_ids = SELECT Data FROM TABLE WHERE PK="USER-1:POST"

# Find post ids by category
post_ids = SELECT Data FROM TABLE WHERE PK="CATEGORY-1:POST"

데이터 상태

STORY: 게시글은 발행되지 않은 채로 저장할 수 있다

POST는 아직 발행하지 않은 ‘DRAFT’와 발행한 ‘PUBLISHED’의 2가지 상태가 있다. 정렬키 앞에 콜론(‘:’)으로 구분하여 상태를 저장한다.

1
2

# Find draft post ids by user
[ draft_post_ids ] = SELECT Data FROM TABLE WHERE PK="USER-1:POST" AND SK=begins_with("DRAFT")

별칭

STORY: 게시글은 질문과 답변 두 가지로 나눠진다.

사용자는 2가지 종류의 게시글을 소유하는데, USER-1:POST같은 방식은 소유한 게시글의 종류를 나눌 수 없다. 별칭을 사용하여 동일한 데이터 타입 간의 관계도 다르게 표현할 수 있다.

1
2

# Find draft question post ids by id
[ draft_question_ids ] = SELECT Data FROM TABLE WHERE PK="USER-1:question" and SK=begins_with("DRAFT")

N:M

STORY: 사용자는 게시글은 태그를 추가할 수 있다

태그와 게시글은 N:M의 관계다. 위의 1:N 모델을 응용하면 N:M 관계를 쉽게 표현할 수 있다.

이 글의 제목과는 다르게 위의 디자인은 분명한 한계점이 있다. 데이터 모델을 추가하는 확장은 쉽게 할 수 있지만, 쿼리의 종류를 다양하게 할 수 없는 문제가 있다. 복잡한 어플리케이션에서는 분명 바로 쓰기 어려울 것이다.

단일 테이블은 괜찮다

하나의 테이블을 사용하는 DynamoDB 앱은 모든 프로비저닝 요소를 공유한다. 동시에 쓰이는 최대의 양만 파악한다면 쉽게 프로비저닝할 수 있다.

DynamoDB는 동시에 얼마나 많이 읽고 쓸 수 있을 것인지 설정한 양(이런걸 보통 프로비저닝이라고 한다)만큼 과금한다. 아마존에선 이것을 읽기 용량 유닛(RCU), 쓰기 용량 유닛(WCU)으로 부른다. RCU와 WCU는 테이블마다 설정해야한다.

테이블을 여러개 만들면 각각의 테이블마다 프로비저닝이 필요하고 아마존은 이 개수만큼 과금한다. 서비스 운영 초기에는 어떤 테이블이 얼마만큼의 프로비저닝이 필요한지 알 수 없다. 거의 접근하지 않는 테이블이라도 반드시 프로비저닝해야하고, 이는 과금의 요소가 된다.

단일 테이블은 별로다

낭비되는 인덱싱 데이터가 있을 수 있다. 앞선 예제에서 ‘Data’의 값으로 식별자가 아닌 값이 존재하는 항목은 인덱싱 테이블에서 쓸 모 없는 파티션키가 될 수 있다.

또 관리의 어려움도 동반할 수 있다. 각각의 데이터 형태와 정의를 다른 곳에 마련해야한다. 여러 사람 혹은 여러 팀이 협업하는 경우, 각 데이터의 접근을 코드에서 제한할 필요가 있다.

DynamoDB의 문서엔 단일 테이블을 사용한 예와 복수 테이블을 사용한 예가 공존한다. 나처럼 NoSQL에 생소한 사람들은 단일 테이블 예제가 더욱 낯설텐데, 이 글을 보고 도움이 되었으면 좋겠다.

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

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

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

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