[GN#78] 개발자와 파워유저를 위한 윈도우 툴 모음 / 억만 장자 만들기

2020-12-28 ~ 2021-01-03 사이의 주요 뉴스들
개발자들은 대부분 맥을 사용하는 것 같지만, 요즘엔 MS 윈도우도 많이 편해졌습니다. VSCode 는 맥이나 윈도우 상관없이 사용이 가능하고, WSL 때문에 윈도우에서 리눅스 개발환경 구성이 가능해졌고, Windows Terminal 덕분에 훌륭한 터미널도 가지게 되었기 때문이죠. 각종 프로그램 설치를 도와주는 윈도우용 패키지 매니저 WinGet, 윈도우의 모든 걸 자동화 할 수 있는 AutoHotkey, 화면 공유 시 어디에나 편하게 그림을 그릴 수 있는 ZoomIt, 맥 파인더의 QuickLook 기능을 그대로 구현한 QuickLook 외에 Ear Trumpet, Ditto, NimbleText, Everything 등 생산성을 높여주는 다양한 도구를 총정리한 스캇 한셀만의 "개발자와 파워유저를 위한 윈도우 툴 모음" 글은 윈도우를 사용하신다면 꼭 살펴보시기 바랍니다.

YC의 창립자 폴 그레이엄이 새로 쓴 "억만장자 만들기" 에세이 번역글이 올라왔습니다. YC를 통해서 투자받은 스타트업들이 성장해서 실제로 창업자들이 꽤 많이 억만장자가 되었는데요. YC의 파트너들이 (억만장자가 될 창업자를 찾기 위해) 스타트업 인터뷰에서 창업자들에게 무엇을 묻고, 어떤 걸 파악하려 하는지를 잘 정리한 글입니다. 스타트업하시는 분들은 꼭 읽어보시면 좋겠습니다. 그 글의 마지막에 있는 문장이 맘에 들어서 옮겨와 봅니다.

"억만장자가 되는 가장 확실한 방법은 빠르게 성장하는 회사를 만드는 것이고 빠르게 성장하는 방법은 사용자가 원하는 것을 만드는 것이다.
새로 시작한 스타트업들은 사용자를 기쁘게 해야 하며, 그렇게 하지 않으면 시작조차도 어렵다.
이것은 항상 길잡이 별이 되어야 하고, 큰 회사들조차도 이것에서 눈을 떼면 위험에 빠지게 된다.
사용자를 기쁘게 하지 않으면, 결국 다른 누군가가 그렇게 할 것이기 때문에."

GUI 도구들이 많아졌지만, 여전히 CLI 도구들은 다양한 용도로 쓰이고 있습니다. 심지어 요즘은 Rust / Go 같은 언어들이 여러 OS 용으로 바이너리를 손쉽게 만들어 주면서, 더 강력한 기능과 편리한 텍스트 기반 UI를 가진 도구들이 계속 나오고 있습니다. 이런 CLI 도구를 설계할 때 전통적인 유닉스 원칙을 따르면서도, 최신 도구들에 맞게 업데이트한 "커맨드 라인 인터페이스 가이드라인" 문서가 만들어졌습니다. 꼭, CLI 도구를 개발하지 않더라도 한번 읽어 두시면, 커맨드 라인 도구들에 대한 기본 지식을 많이 얻으실 수 있습니다.


✓ 사내에서 슬랙을 쓰신다면 뉴스채널에 GeekNews SlackBot 을 추가하여 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요.
✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.
✓ 긱뉴스를 팟캐스트로 들어보세요 : 애플, 유튜브, 팟티, 팟빵, 구글, 네이버 오디오클립
✓ GeekCast : 최신 데이터 인프라 이해하기 (시리즈) , 실패하지 않는 뉴욕타임즈 - NYT는 어떻게 디지털화에 성공했나 (48분)

매주 월요일 아침, 지난 일주일간의 GeekNews 중 엄선한 뉴스들을 이메일로 보내드립니다.


개발자와 파워유저를 위한 윈도우 툴 모음

- 스캇 한셀만이 2003년부터 정리해온 Windows용 도구 리스트로, 2014년 이후 6년만에 나온 8번째 업데이트 판

일과 삶을 바꾸는 유틸들
- Windows Subsystem for Linux
- Windows Terminal : 윈도우즈용 모던 터미널
- Windows PowerToys : 컬러피커, 팬시존스, 탐색기 확장, 이미지 리사이저, 키보드 매니저 & 리맵퍼, 애플 스팟라이트와 비슷한 Run
- VS Code
- PowerShell / OhMyPosh / PoshGit / Cascadia Code : 그 외에 Starship 도 참고
- ZoomIt : 화면 공유시 간단히 뭔가를 그릴수 있게 해주는 도구
- Winget : Apt-get for Windows
- QuickLook : 맥에서 쓰던 스페이스바 프리뷰 기능을 윈도우에!

놀라운 .NET 및 개발자 유틸들
- CodeTrack : 무료 .NET Performance Profiler and Execution Analyzer
- LINQPad - 인터랙티브 쿼리 도구
- WinMerge : 무료 오픈소스 파일 비교 & 머지 도구
- WinDbg : UI가 대폭 개선된 표준 디버거
- Insomnia 와 Nightingale : REST Api 호출용 도구
- NuGet Package Explorer : NuGet 패키지 탐색 및 내용 보기
- WireShark : 네트워크 프로토콜 분석기
- GitHub Desktop

윈도우에 기본 내장되어야 할 유용한 유틸들
- Ear Trumpet : 훌륭한 볼륨 컨트롤
- Teracopy : 대규모 파일 고속 복사
- AutoHotkey : 무료 오픈소스, 키보드/마우스 자동화 도구
- 7-Zip : 최고의 압축 도구, 7z 는 ZIP보다 2~10% 압축률이 뛰어남. ZIP,TAR,ISO,RAR,CAB 까지 모두 지원
- Paint.NET : 포토샵의 80% 기능을 가진 무료 그림 도구
- NimbleText : 정규식으로 문자열을 조작하는 도구
- Markdown Monster : 마크다운 편집기
- Fiddler : HTTP 디버깅용 프록시
- NirSoft Utilities Collection : 다양한 유틸 모음. 특히 MyUninstaller 와 WhoIsThisDomain
- Ditto Clipboard Manager : Window + V 키의 놀라운 기능
- TaskbarX : 태스크바 버튼의 위치를 가운데 또는 마음대로 위치
- ShellEx View : 탐색기에서 마우스 오른쪽 버튼 클릭시 나오는 것들을 정리
- OneCommander / Midnight Commander / Altap Salamander : 파일 탐색기
- WinDirStat : 어떤 파일이 얼마나 크기를 차지하고 있나 보여주는 디스크 사용량 분석기
- FileSeek / Everything : 파일 검색
- ShareX, Greenshot, Lightshot : 화면 캡쳐
- screen2gif , LICEcap : 애니메이션으로 캡쳐
- Alt-Tab Terminator : Alt-Tab 을 향상시키기 ( 큰 프리뷰 화면 등)
- PureText : 클립보드 안에 텍스트 포맷을 지우고 순수 텍스트만 붙여넣기
- VLC Player : 모든 것이 재생가능한 동영상/오디오 플레이어
- PSReadline : PowerShell 을 더 Bash 스럽게
- Yori and all Malcolm Smith's Utilities : CMD를 개선한 Yori 및 다양한 유틸

Visual Studio Code 확장들
- GitLens : Git 확장
- Version Lens : 최근 패키지인지 버전 확인
- CodeSnap : 코드가 이뻐보이는 스크린샷 찍기
- .NET Core Test Explorer : .NET 유닛테스팅을 더 훌륭하게
- Arduino for VS Code : 아두이노 개발 도우미
- Coverage Gutters : 테스트 커버리지 보이기
- Docker for VS Code : 컨테이너 탐색/관리/배포
- GitHistory : Git Log 를 훌륭하게 보여주기
- HexDump : Hex 로 보기
- LiveShare : 화면 공유만이 아닌, 오디오/채팅을 포함한 코드 공유
- PowerShell for VS : PowerShell ISE 대체
- Remote Containers : Docker 사용자라면 꼭 사용해야 할 놀라운 확장
- Remote SSH : 원격 SSH 서버를 개발환경으로 사용하기
- Remote WSL : 윈도우에서 원격으로 리눅스 개발/디버깅 하기
- Yoncé : Beyoncé 테마

THINGS I ENJOY
- RescueTime : 생산성 도구, GTD(Getting Things Done) / TCB (Taking Care of Business)
- Carnac : 내가 입력하는 모든 키보드 입력(단축키 포함)를 화면 한 구석에 보여주는 도구. 발표(특히 라이브코딩) 시에 좋음
- DOSBox : 예전 DOS 프로그램 실행하기
- Windows Sandbox : 윈도우 안에서 윈도우를 샌드박스로 실행해서 안전한 환경에서 윈도우 앱 테스트하기

저는 listary 잘 쓰고 있습니다.
everything 과 비슷한 기능이랄까요? 프로그램이나 파일들 검색등등 많습니다.
https://www.listary.com/

 
억만장자 만들기

Y Combinator 의 창립자인 폴 그레이엄이 쓴 글, '억만장자 만들기' 입니다.

인상깊게 읽어 내용을 요약해서 번역해봤습니다. 그리 영어 실력이 부족해서 번역 퀄리티가 좋지 않은 점은 양해 부탁드립니다. ;ㅁ ;

- 글을 두개 쓰려고 했는데.
ㅤㅤ- 하나는 Y Combinator (북미의 스타트업 인큐베이터) 인터뷰에 성공하는 방법. 너무 설왕설래가 많아서 창립자인 내가 직접 쓰는 게 좋을 것 같아서.
ㅤㅤ- 두번째는 일부 정치인이 가끔 말하는 '백만장자는 사람을 착취해야만 될 수 있어'가 왜 잘못되었는지.
- 그런데 이 글 하나를 쓰니 둘 다 포함되더라. 끝까지 읽으면 다 알 수 있어.
- 내 일은 억만장자가 될 사람을 찾는 건데, 정치인들이 말하는 건 틀렸음.
ㅤㅤ- 만약 그랬다면 나는 미식축구 스카우터가 유망주를 찾는 속도처럼 사람을 잘 착취하는 사람들을 찾았을 텐데.
ㅤㅤ- Y Combinator 가 찾는 것과 전혀 다름. 정확히 그 반대를 찾고 있음.
ㅤㅤㅤㅤ- Y Combinator 는 사람이 원하는 걸 만든다가 모토.
ㅤㅤ- 대기업은 별로 그 사람에게 맞지 않는 제품을 부적절한 고객들에게 강요하는 게 가능하지만. 스타트업은 그럴 힘이 없음.
ㅤㅤㅤㅤ- 고객이 진정으로 기뻐할만한 걸 만들지 않으면 스타트업은 스타트도 못할 것.
ㅤㅤㅤㅤㅤㅤ- 이 점이 YC 인터뷰에서 가장 어려운 부분임.
ㅤㅤㅤㅤㅤㅤ- 시장 경제에서 사람들이 아직 가지고 있지 않는 건데 원하는 것을 만드는 건 어려움. 하지만 좋은 점이기도 함. 만약 다른 사람들이 다 알고, 만들어서 만족시킬 수 있다면 이미 그랬을 거고. 그럼 스타트업은 없을 테니까.
ㅤㅤ- 그래서 YC 인터뷰는 새로운 요구나, 새로운 방법으로 만족시킬 수 있는 방법에 대한 것임. 다만 새롭기만 한 건 아니고. 불확실하기도 함.
ㅤㅤㅤㅤ- 필요성이 확실하다면 투자 받을 이유가 없을 거고. 이미 성장하고 있을 테니까.
ㅤㅤㅤㅤ- 따라서 인터뷰는 실제 요구 사항을 발견했는 지와, 이를 충족할 수 있는지 여부를 모두 추측해야 함. 인터뷰어들은 이걸 직업으로 하는 사람들임.
ㅤㅤㅤㅤㅤㅤ- 그 사람들은 이 작업을 위한 1001 개의 휴리스틱스 ( 발견법 ) 를 가지고 있지만. 굳이 말하지는 않을 거임.
ㅤㅤㅤㅤ- 하지만 중요한 점을 말할 수 있어서 기쁨.
ㅤㅤㅤㅤㅤㅤ- 그 사람들을 속일 수는 없다는 것과, 그 사람들을 '해킹'할 수 있는(설득할 수 있는) 유일한 방법은 그냥 창업자로써 해야 할 일을 하는 거임.
ㅤㅤ- 파트너 (인터뷰어) 가 가장 먼저 알려는 건, 지금 만들려는 게 많은 사람들이 원하게 될 것인가? 임.
ㅤㅤㅤㅤ- 당장 모든 사람이 원하지 않아도 됨. 제품이랑 시장은 진화할 거고. 서로 진화하면서 영향을 미칠 테니까.
ㅤㅤㅤㅤ- 그렇지만 결국 거대한 시장이 되어야 만함. 이게 파트너가 알아내려는 것.
ㅤㅤ- 일반적으로 거대한 시작으로 가는 길은 작은 시장을 성장하는 것.
ㅤㅤㅤㅤ- 이건 문구를 만들 가치가 있으니까 '애벌레 시장' 이라고 부르겠음.
ㅤㅤ- 애벌레 시장의 완벽한 예는 1976년에 설립된 Apple이 만든 시장.
ㅤㅤㅤㅤ- 76년에는 대다수의 사람들이 개인 컴퓨터를 원하지 않았는데.
ㅤㅤㅤㅤ- 결국 점점 많은 사람들이 원하게 되었고
ㅤㅤㅤㅤ- 이젠 10살 짜리 어린이도 컴퓨터를 원함.
ㅤㅤ- 이상적인 그룹은 "미래에 살고 있는" 설립자 그룹 - ( http://paulgraham.com/startupideas.html )
ㅤㅤㅤㅤ- 스티브 워즈니악은 컴퓨터를 원했고
ㅤㅤㅤㅤ- 마크 쥬크버그는 대학 친구들과 온라인으로 소통하고 싶었고
ㅤㅤㅤㅤ- 레니랑 세르게이는 웹에서 무언가를 찾고 싶어했음 (구글 창립자)
ㅤㅤㅤㅤ- 이 모든 창립자들은 자기와 동료들이 원하는 걸 만들고 있었고. 변화의 선두에 있었다는 건 앞으로 더 많은 사람들이 이런 걸 원했을 것을 의미했음.
ㅤㅤ- '자신과 동료'는 이상적인 애벌레 시장이지만, 이게 유일한 건 아님.
ㅤㅤㅤㅤ- 지역적인 걸 수도 있음. 한 지역에 서비스하기 위해 만들다가. 다른 위치로 확장.
ㅤㅤ- 초기 시장의 중요한 특징은, 시장이 존재한다는 것 자체.
ㅤㅤㅤㅤ- 당연해 보이겠지만, 대부분 스타트업에서 가장 큰 문제는 시장이 부족하다는 것.
ㅤㅤㅤㅤㅤㅤ- 지금 만들고 있는 걸 원하는 사람이 있어야 하고
ㅤㅤㅤㅤㅤㅤ- 한번도 들어본 적이 없는 회사인데도 기꺼이 사용할 정도로 시급하게 원해야 하는 사람들이 있어야만 함.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 많은 필요는 없는데. 일부는 꼭 있어야 함.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 이 일부 사용자들만 있으면 더 많은 걸 얻을 수 있는 간단한 방법이 있음.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 이 사람들이 원하는 걸 만들고.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 비슷한 사람들을 찾고.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 친구를 추천하게 만들어야 함.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 그렇지만 이 기술은 결국 이 그룹이 있어야만 함.
ㅤㅤ- 그래서 이건 YC 파트너가 인터뷰 중 거의 100퍼센트 파헤칠 거임.
ㅤㅤㅤㅤ- "처음에는 누가 쓸 건가요?"
ㅤㅤㅤㅤ- 스타트업에 자금을 넣어야 하나 여부를 결정해야 한다면. "사람들이 이걸 원하는 지 어떻게 알 수 있나요?"
ㅤㅤ- 가장 설득력 있는 대답은 "우리와, 우리 친구들이 원해서."
ㅤㅤㅤㅤ- 이미 프로토타입을 만들었다는 소식이 이어지고.
ㅤㅤㅤㅤ- 엄청 조잡해도 친구들이 쓰고 있고.
ㅤㅤㅤㅤ- 입소문으로도 퍼지고 있다.
ㅤㅤㅤㅤ- 이런 대답들을 할 수 있고, 거짓말을 하지 않는다면 파트너는 '아니오'에서 '예'로 바뀔 거임. 다른 결격이 없는 한 리스트에 당신이 있다는 말.
ㅤㅤ- 하지만 이건 충족하기 어려운 기준.
ㅤㅤㅤㅤ- Airbnb는 이 기준에 못 맞췄음.
ㅤㅤㅤㅤㅤㅤ- 첫번째 부분 -> 원하는 걸 만들었다는 건 충족했지만.
ㅤㅤㅤㅤㅤㅤ- 두번째 부분 -> 퍼지지는 않았음.
ㅤㅤㅤㅤ- 하지만 여기 미치지 못했다고 기분 나쁠 필요는 없음. Airbnb도 못 맞췄으면 너무 높은 거니까.
ㅤㅤ- 실제 YC 파트너는 사용자의 요구 사항을 깊이 이해하고 있다고 느끼면 만족할 거임.
ㅤㅤㅤㅤ- 그리고 Airbnb는 이걸 가지고 있었음.
ㅤㅤㅤㅤㅤㅤ- 호스트와 게스트의 동기에 대해 모두에게 말할 수 있었고.
ㅤㅤㅤㅤㅤㅤ- 우리는 그 친구들이 답을 모르는 질문은 못했음. Airbnb는 모두 대답함.
ㅤㅤ- YC 인터뷰에서 할 수 있는 좋은 일은 파트너에게 사용자에 대해 가르치는 것.
ㅤㅤㅤㅤ- 인터뷰를 준비하고 싶으면, 사용자에게 가서 뭘 생각하는지 정확히 알아내면 됨.
ㅤㅤㅤㅤ- 어차피 해야 할 일이기도 하고.
ㅤㅤ- YC 파트너는 창업자에게 시장에 대해 이야기하기를 원함.
ㅤㅤㅤㅤ- VC가 아이디어에 대한 잠재적 시장을 어떻게 판단하는지 생각하면...
ㅤㅤㅤㅤㅤㅤ- 일반적으로 전문가는 아니니까. 아이디어를 누구에게 전달하고, 의견을 요청함.
ㅤㅤㅤㅤㅤㅤ- YC는 그걸 수행할 시간은 없지만, 설립자가 만약
ㅤㅤㅤㅤㅤㅤㅤㅤ- 자신이 말하는 걸 전부 알고 있고.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 거짓말은 하고 있지 않다는 걸.
ㅤㅤㅤㅤㅤㅤ- YC 파트너가 그걸 확신할 수 있다면, 다른 전문가를 필요하지 않음.
ㅤㅤ- 이것들이 YC 인터뷰가 프레젠테이션이 아닌 이유들임.
ㅤㅤㅤㅤ- 우린 최대한 많은 창립자에게 자금을 지원받을 기회를 주기 위해 최대한 짧게 인터뷰를 진행함. 10분.
ㅤㅤㅤㅤ- 파트너는 간접적 증거들을 통해 당신이 뭔 말을 하고 있는지 알고 있어야 하고, 거짓말을 하는지도 알아 내야해서 충분한 시간이 아님.
ㅤㅤㅤㅤ- 그래서 파고 들어 질문함. 순차 접근이 아니라 랜덤 접근으로.
ㅤㅤ- YC 인터뷰에서 성공하는 방법으로 들은 것 중 최악의 조언은 '인터뷰를 통제하고, 원하는 메시지를 전달하라.' 임. 인터뷰를 프레젠테이션으로 바꾸라는 건데.
ㅤㅤㅤㅤ- *우아한 욕설*
ㅤㅤㅤㅤ- 그렇게 하려고 하면 너무 짜증남.
ㅤㅤㅤㅤ- 그들이 질문을 하고, 당신이 대답하는 대신. 이미 정교하게 조립된 대사 덩어리를 전달하는 거고. 진짜 빨리 10분을 먹음.
ㅤㅤ- 현재, 또는 이전 YC 파트너를 빼곤 YC 인터뷰에서 해야 할 일에 대해 정확한 조언을 줄 수 있는 사람은 없음.
ㅤㅤㅤㅤ- 인터뷰에 응하는 사람은 성공하더라도 이를 알지 못하는데.
ㅤㅤㅤㅤㅤㅤ- 왜냐하면 인터뷰는 파트너가 알고 싶어하는 내용에 따라 바뀌기 때문.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 가끔은 질문이 모두 창립자에 관한 거고
ㅤㅤㅤㅤㅤㅤㅤㅤ- 가끔은 모두 아이디어에 관한 거고
ㅤㅤㅤㅤㅤㅤㅤㅤ- 가끔은 아이디어의 아주 좁은 측면만 다루고.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 그래서 창업자들은 가끔 아이디어를 완전히 설명 못했다고 불평하면서 인터뷰를 떠나지만. 맞는 말이긴 해도 이미 충분히 설명한 거임.
ㅤㅤ- YC 인터뷰는 질문으로 구성되어 있음. 그러니 인터뷰를 잘하는 방법은 질문에 답을 잘하는 것.
ㅤㅤㅤㅤ- 그리고 솔직하게 말할 것.
ㅤㅤㅤㅤ- 파트너는 당신이 모든 걸 알기를 기대하지 않음.
ㅤㅤㅤㅤ- 그러니까, 질문에 대한 답을 모르면 그 질문에서 벗어나려고 헛소리하지 말아야 함.
ㅤㅤㅤㅤㅤㅤ- 파트너는 경험이 풍부한 투자자와 마찬가지로, 전문적인 헛소리 탐지자인데.
ㅤㅤㅤㅤㅤㅤ- 당신은 아마추어 헛소리 꾼임.
ㅤㅤㅤㅤ- 그러니까 약파는 것보단 정직한 게 나음.
ㅤㅤㅤㅤ- 예를 들어보면. 만약 '뭐가 잘못될 수 있나요?'라고 질문을 했을 때 최악의 대답은 '아무것도!' 임.
ㅤㅤㅤㅤㅤㅤ- 이 대답은 당신의 아이디어가 '방탄유리' 라고 설득하는 게 아니라, 파트너에게 당신이 바보이거나 거짓말쟁이라는 걸 확신시켜줄 거임.
ㅤㅤㅤㅤㅤㅤ- 그냥 끔찍하고 고통스러운 사항들을 알려주는 게 훨씬 좋음.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 이게 무엇이 잘못될 수 있는지 물어볼 때 전문가들이 하는 일.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 이미 파트너는 당신의 아이디어가 위험하다는 걸 알고 있음.
ㅤㅤㅤㅤ- 경쟁사에 대해 묻는 경우도 마찬가지.
ㅤㅤㅤㅤㅤㅤ- 경쟁자는 스타트업을 죽이는 경우가 거의 없음.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 아. 불쌍히도 몇몇 시도들은 그럼.
ㅤㅤㅤㅤㅤㅤ- 하지만 경쟁자가 누구인지는 알고, YC 파트너에게 상대적인 강점과 약점이 무엇인지 말해줘야 함.
ㅤㅤㅤㅤㅤㅤ- 파트너는 경쟁자가 스타트업을 죽이지 않을 거라는 걸 잘 알고 있어서 그리 오래 붙잡지는 않을 거임.
ㅤㅤㅤㅤㅤㅤ- 그렇지만 전혀 모르거나, 위협을 최소화할 것 같으면 반드시 붙잡을 거임.
ㅤㅤㅤㅤ- 파트너는 아이디어가 완벽할 거라고 기대하지 않음. 이건 시드 투자니까.
ㅤㅤㅤㅤㅤㅤ- 이 단계에서 파트너들이 기대하는 건 그럴듯한 아이디어뿐임.
ㅤㅤㅤㅤㅤㅤ- 그렇지만 파트너들은 당신이 사려 깊고 정직하길 원함.
ㅤㅤㅤㅤㅤㅤ- 그래서 당신의 아이디어가 완벽하게 보이려고 애쓰는 게.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 당신을 슬기롭게 보이거나 어리석게 보이면
ㅤㅤㅤㅤㅤㅤㅤㅤ- 하지도 않을 것을 위해 필요한 걸 희생한 거임.
ㅤㅤ- 파트너가 이제 큰 시장으로 가는 길이 있다고 충분히 확신하면. 다음 질문은: 이제 당신이 그걸 만들 수 있을지에 대한 여부.
ㅤㅤㅤㅤ- 그 여부들은... 아래 세가지 질문으로 결정됨.
ㅤㅤㅤㅤㅤㅤ- 설립자의 일반적인 자질과
ㅤㅤㅤㅤㅤㅤ- 이 분야에 구체적인 전문 지식과
ㅤㅤㅤㅤㅤㅤ- 다른 이들과의 관계.
ㅤㅤㅤㅤ- 이런 질문들을 할거임.
ㅤㅤㅤㅤㅤㅤ- 창립자는 어떻게 결정됨?
ㅤㅤㅤㅤㅤㅤ- 만드는 데에는 능숙함?
ㅤㅤㅤㅤㅤㅤ- 일이 잘못되어도 계속 갈 수 있을 만큼 탄력적임?
ㅤㅤㅤㅤㅤㅤ- 우정은 얼마나 강함?
ㅤㅤㅤㅤ- Airbnb는 아이디어 측면에서는 '괜찮았지만'. 이 측면에는 '훌륭하게 잘했음.'
ㅤㅤㅤㅤㅤㅤ- 면접 중에 처음 자금을 어떻게 조달했는지에 대한 질문에 그들은 오바마랑 메케인을 테마로 한 아침 시리얼을 만들어서 조달하려고 했던 계획의 이야기는 투자와는 전혀 상관없어 보였지만. 우리가 투자하는 걸 결정한 중요한 요인이었음.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 이 이야기는 그들이 설립자로써 자질에 대한 엄청 좋은 증거였기 때문에.
ㅤㅤㅤㅤㅤㅤ- 하지만 이걸 보여주는 건 시리얼 이야기 뿐만이 아니었음.
ㅤㅤㅤㅤㅤㅤㅤㅤ- 그들은 돈이나 스타트업이 멋져서 이 일을 한 게 아님. 그들의 프로젝트였기 때문에 열심히 일했고. 그들은 흥미로운 새로운 아이디어를 찾았고, 그걸 놓아줄 수 없었음.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 평범한 들리는 이 소리는 신생 기업 뿐만 아니라 가장 야심 찬 사업에서, 가장 강력한 동기 부여임.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 이게 억만장자나 최소한 창업회사에서 억만장자가 되는 사람들을 이끄는 것.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ- 회사가 곧 그들의 프로젝트였기 때문에.
- 이게 사람을 착취해야 한다는 정치인들의 헛소리가 아닌. 창업회사에서 억만장자가 되는 사람들의 자질이고. 이게 YC가 창립자에게 요구하는 것임.
ㅤㅤ- 진정성.
- 스타트업을 시작하려는 동기들은 혼합되어있음.
ㅤㅤ- 돈을 벌고 싶은 욕구나.
ㅤㅤ- 멋지게 보이고 싶은 욕망.
ㅤㅤ- 문제에 대한 진정한 관심.
ㅤㅤ- 다른 사람을 위해 일하지 않으려는 마음의 조합으로.
- 마지막 두 개는 처음 두 개보다 더 강력한 동기 부여.
ㅤㅤ- 창업자들이 돈을 벌거나 멋지게 보이게 원하는 건 괜찮고. 대다수가 그럼.
ㅤㅤ- 그렇지만 단지 돈을 벌거나, 단지 멋지게 보이기 위해 큰 규모로 성장하지는 않을 것 같음.
ㅤㅤ- 돈을 위해 일 하는 창립자는 충분히 큰 인수 제안을 받을 거고.
ㅤㅤ- 멋지게 보이려고 일하는 사람들은 멋져 보이는 방법들 중, 이것보단 다른 것들이 훨씬 덜 고통스럽다는 걸 빠르게 발견할 거임.
- YC는 확실하게 사람을 착취하는 창립자를 봄.
ㅤㅤ- YC 브랜드를 원하니까.
ㅤㅤ- 하지만 우리는 그런 사람들을 거부함.
ㅤㅤ- 만약 나쁜 사람들이 좋은 창업자를 만들면, 파트너들은 도덕적 딜레마에 직면하겠지만.
ㅤㅤ- 다행히도 그렇지 않음. 나쁜 사람은 나쁜 창립자를 만듬. 이 착취적인 설립자들은 큰 규모로 성공하지 못할 거고, 항상 지름길을 택할 거니까 사실 작은 것도 성공하지 못함. YC를 지름길로 보기도 하고.
ㅤㅤ- 그들의 착취는 보통 공동 창립자로부터 시작하는데. 공동 창립자는 회사의 기초라서 재앙임.
- 그럼 전문적인 억만장자 스카우트가 '그건 아닌데' 라고 말하는데, 그럼 정치인들은 왜 그런 소리를 할까?
ㅤㅤ- 주: 여기서 전문적인 억만장자 스카우트는 자기 자신입니다. Y Combination은 실제로 북미에서 가장 성공적인 스타트업 인큐베이터입니다.
- 그건 한 사람이 다른 사람보다 더 많은 돈을 가질 수 있다는 게 잘못되었다는 느낌에서 출발함.
ㅤㅤ- DNA에서부터 나오는 거고, 다른 종의 DNA에도 있는 거임.
- -> 이하 내용은 북미 정치인들 까기라서 스킵.
- 그래서 파트너들은 뭘 알고 싶냐면.
ㅤㅤ- 사용자가 원하는 게 뭐임?
ㅤㅤ- 그들을 위해 뭘 만들 수 있음?
- 억만장자들은 항상 이 주제에 대해 이야기하고 싶어하고.
- 그게 그들이 억만장자가 된 방법임.

원문의 마지막 부분에 있는 문단이 인상적이어서 추가로 옮겨 둡니다.

The most reliable way to become a billionaire is to start a company that grows fast, and the way to grow fast is to make what users want. Newly started startups have no choice but to delight users, or they'll never even get rolling. But this never stops being the lodestar, and bigger companies take their eye off it at their peril. Stop delighting users, and eventually someone else will.

억만장자가 되는 가장 확실한 방법은 빠르게 성장하는 회사를 만드는 것이고 빠르게 성장하는 방법은 사용자가 원하는 것을 만드는 것이다.
새로 시작한 스타트업들은 사용자를 기쁘게 해야 하며, 그렇게 하지 않으면 시작조차도 어렵다.
이것은 항상 길잡이 별이 되어야 하고, 큰 회사들조차도 이것에서 눈을 떼면 위험에 빠지게 된다.
사용자를 기쁘게 하지 않으면, 결국 다른 누군가가 그렇게 할 것이기 때문에.

 
커맨드 라인 인터페이스 가이드라인

전통적인 유닉스 원칙을 따르면서 현대적으로 업데이트한 오픈소스 가이드

- CLI 디자인 철학
ㅤ→ 사람 우선
ㅤ→ 함께 작동하는 간단한 부속
ㅤ→ 프로그램간 일관성 유지
ㅤ→ 필요한 만큼만 말하기(적지도 많지도 않은 출력)
ㅤ→ 쉽게 발견할수 있게(포괄적인 도움말, 예제, 다음 수행할 명령 제안, 에러가 있을때 할 작업 제안)
ㅤ→ 일반적인 대화처럼
ㅤ→ 견고하게
ㅤ→ 사용자에게 공감하기
ㅤ→ 혼돈 : 규칙을 어겨야 한다면 의도와 목적을 명확히 할 것

- CLI 가이드 라인
ㅤ→ 기초
ㅤㅤ✓ 명령행 파싱 라이브러리 사용할 것 : Go(Cobra,cli), Node(oclif), Python (Click,Typer), Ruby(TTY)
ㅤㅤ✓ 성공시 0, 에러시 0이외의 코드 리턴
ㅤㅤ✓ 출력은 stdout
ㅤㅤ✓ 로그, 에러 등 메시지는 stderr

ㅤ→ 도움말
ㅤㅤ✓ 옵션 지정없이 실행하면 도움말 출력 (-h, --help)
ㅤㅤ✓ 기본적으로 간결한 도움말을 출력
ㅤㅤㅤㅤ· 이 프로그램이 뭐하는지
ㅤㅤㅤㅤ· 한두개의 호출 예제
ㅤㅤㅤㅤ· 플래그 설명(많지 않다면)
ㅤㅤㅤㅤ· 추가 설명용 --help
ㅤㅤ✓ -h, --help 옵션시 전체 도움말 출력
ㅤㅤ✓ 피드백/이슈를 받기위한 경로 제공
ㅤㅤ✓ 도움말에서는 웹버전 문서로의 링크를 제공
ㅤㅤ✓ 예제로 설명할 것
ㅤㅤ✓ 예제가 많다면, 어딘가 다른곳에 올려 둘것 (치트시트 또는 웹페이지)
ㅤㅤ✓ man 페이지엔 신경쓰지 말 것 (많이 안쓰고, 윈도우에서 동작도 안함)
ㅤㅤ✓ 도움말이 길다면 pager로 파이프 할 것
ㅤㅤ✓ 가장 많이 쓰는 플래그와 명령을 도움말 처음에 표시
ㅤㅤ✓ 도움말에서 포맷팅 사용할 것 (볼드체)
ㅤㅤ✓ 사용자가 뭔가를 잘못했고, 그걸 추측할수 있다면 추천할 것
ㅤㅤ✓ 당신의 명령이 뭔가를 pipe로 받아들이길 바라는데, stdin 이 인터랙티브 터미널이면 도움말을 표시하고 바로 종료할 것

ㅤ→ 출력
ㅤㅤ✓ Human-readable(사람이 읽을 수 있는) 출력이 가장 중요
ㅤㅤ✓ 사용성에 문제가 되지 않는다면 machine-readable 출력을 제공
ㅤㅤ✓ human-readable 때문에 machine-readable 이 불가능 하다면 --plain 옵션으로 grep / awk 등과 연계 가능하도록
ㅤㅤ✓ --json 입력을 받으면 JSON 포맷으로 출력
ㅤㅤ✓ 성공시 출력은 없는게 좋지만, 있어야 할 경우 간결하게 할 것. -q 옵션으로 필요없는 출력 제외 지원
ㅤㅤ✓ 상태를 바꾼다면, 사용자에게 말할 것 (git push의 출력 참조)
ㅤㅤ✓ 현재 시스템의 상태를 보기 쉽게 할 것
ㅤㅤ✓ 사용자가 실행할수 있는 명령을 추천할 것. (git status 치면 git add / restore 를 보여주듯이)
ㅤㅤ✓ 프로그램의 내부를 넘어가는 행동들은 명시적 이어야 함. 사용자가 지시하지 않은 파일을 읽고 쓴다거나(캐쉬), 원격서버와 연결하는 등(파일 다운로드)
ㅤㅤ✓ ASCII 아트를 이용해서 정보 밀도 증가 시키기
ㅤㅤ✓ 의도를 가지고 컬러 사용하기. 오남용은 말 것
ㅤㅤ✓ 터미널이 아니거나, 사용자가 요청시 컬러는 끌것
ㅤㅤ✓ stdout 이 인터랙티브 터미널이 아니면 애니메이션을 표시하지 말 것
ㅤㅤ✓ 뭔가를 명확히 할때만 심볼/이모지를 사용할 것
ㅤㅤ✓ 기본적으로, 제작자만 알아볼수 있는 정보들은 출력하지 말 것
ㅤㅤ✓ stderr 를 로그파일처럼 사용하지 말 것 (적어도 기본값으로는 설정하지 말 것. 상세모드에서나 ERR,WARN 같은 로그 레벨을 출력하세요)
ㅤㅤ✓ 많은 텍스트를 출력한다면 less 와 같은 페이징 도구를 사용할 것

ㅤ→ Error
ㅤㅤ✓ 에러를 Catch 하고 사람을 위해 문구를 재작성할 것
ㅤㅤ✓ Signal-to-noise ratio(신호 대 잡음비)가 중요. 똑같은 에러가 여러번 난다면 설명하는 헤더와 함께 묶어서 출력
ㅤㅤ✓ 사용자가 제일 먼저 보는게 어디인지를 고려할 것
ㅤㅤ✓ 예상치 못한/설명할수 없는 오류가 나면, debug/trace 정보를 제공하고, 이 버그를 개발자에게 보내는 방법을 설명할 것
ㅤㅤ✓ 버그 리포트를 별도의 노력없이 보낼수 있도록 할 것. (모든 정보를 다 담은 URL을 만들어주고 브라우저에 넣는 것만으로 신고가 끝나게)

ㅤ→ Argument & Flags : 인자와 플래그
ㅤㅤ✓ 인자 : 위치 파라미터. 순서가 중요. cp bar foo 와 cp foo bar 는 다름
ㅤㅤ✓ 플래그 : 이름붙은 파라미터. "-r" 처럼 한글자 또는 "--recursive" 처럼 여러 글자. 순서는 일반적으로 중요하지 않음.
ㅤㅤㅤㅤㅤㅤㅤㅤ사용자 값을 포함하기도 함. --file foo.txt 또는 --file=foo.txt
ㅤㅤ✓ 인자보다 플래그를 선호할 것. 더 많은 타이핑이 필요하지만, 보다 명확함. 인자가 많으면 나중에 기능 확장을 할 때 어려움
ㅤㅤ✓ 플래그의 짧은 버전과 풀버전을 모두 가질 것. 스크립트에서 풀버전을 쓰면 다른 설명이 필요 없음
ㅤㅤ✓ 주로 사용 하는 플래그에만 한글자 플래그를 사용
ㅤㅤ✓ 간단한 동작을 위해서 여러개의 인자를 받는 것도 가능
ㅤㅤ✓ 서로 다른 두개 이상의 인자가 필요하다면 뭔가를 잘못하고 있는 것일수도
ㅤㅤ✓ 플래그는 (이미 있다면) 표준적인 이름을 쓸 것
ㅤㅤㅤㅤ-a --all , -d --debug , -f --force , -h --help , -o --output , -p --port , -q --quiet , -u --user
ㅤㅤ✓ 대부분 사용자에게 적합한 것을 기본값으로 할 것
ㅤㅤ✓ 사용자가 입력이 필요한 인자/플래그를 넣었는데 받은 값이 없다면, 사용자에게 입력을 요구할 것
ㅤㅤ✓ 항상 인자/플래그로 값을 넘기는 방법을 제공하고, 무조건 입력(prompt)을 요구하지 말 것
ㅤㅤ✓ 뭔가 위험한 일을 하기전엔 항상 확인을 요구할 것
ㅤㅤ✓ 입력 또는 출력이 파일이라면 - 로 stdin 에서 받거나 stdout으로 출력하는 것을 지원할 것
ㅤㅤㅤㅤ$ curl https://example.com/something.tar.gz | tar xvf -
ㅤㅤ✓ 플래그가 추가 값을 받을수 있다면, "none" 같은 특수 단어를 허용할 것. ssh -F none
ㅤㅤ✓ 가능하면 인자와 플래그, 서브커맨드 들을 순서와 상관없이 만들 것
ㅤㅤ✓ 민감한(암호같은) 인자 값들은 파일로 입력될 수 있게 할 것

ㅤ→ Interactivity
ㅤㅤ✓ stdin 이 인터랙티브 터미널일때만 prompt 나 인터랙티브 기능을 사용할 것
ㅤㅤ✓ --no-input 이 전달되면, prompt 나 어떤 인터랙티브 기능도 사용하지 말 것
ㅤㅤ✓ 암호를 입력받을땐, 사용자가 입력하는 값을 보이지 말 것
ㅤㅤ✓ 사용자가 쉽게 나갈수 있게 할것 (vim처럼 하지 말것). Ctrl-C 가 동작하게 할 것. ssh,tmux 등 프로그램 실행관련이라 ctrl-c가 불가능하면 SSH 처럼 ~ 로 시작하는 escape sequence 를 제공한다는 것을 명확히 표시할 것

ㅤ→ Subcommands
ㅤㅤ✓ 복잡한 도구는 subcommand 를 제공해서 복잡도를 줄일수 있음.
ㅤㅤ✓ 또한 긴밀히 연관된 여러도구가 있다면 이걸 하나의 명령으로 묶어서 편하게 사용하게 할 수 있음
ㅤㅤ✓ 서브코맨드 간에 일관적일 것. 같은 플래그는 같은 의미로, 비슷한 출력 포맷을 가지게
ㅤㅤ✓ 여러 단계의 서브 코맨드간에 일관적인 이름을 사용할 것
ㅤㅤ✓ 헷갈리거나 비슷한 이름의 명령을 넣지 말 것. update 와 upgrade 같은

ㅤ→ Robustness
ㅤㅤ✓ 사용자 입력을 모두 검증 할 것. 빨리 체크하고, 이해가능한 에러를 표시할 것
ㅤㅤ✓ 빠른 것보다 반응성이 더 중요함
ㅤㅤ✓ 오래 걸린다면 진행상황을 보일 것
ㅤㅤ✓ 가능하다면 병렬적으로 일을 처리할 것. 하지만 깊이 생각하고 할 것.
ㅤㅤ✓ 타임아웃을 넣을 것
ㅤㅤ✓ 멱등(idempotent)으로 만들 것. (다시 실행해도 결과가 달라지지 않는 것). 에러가 났을때 쉘에서 화살표 위로 올려서 다시 이전부터 이어서 수행가능하게
ㅤㅤ✓ Crash-only로 만들 것. Idempotence 의 다음 단계. 작업후 정리를 수행할 필요가 없거나, 다음 실행시까지 정리를 연기할수 있다면, 프로그램은 실패 또는 중단시 즉시 종료가 가능.
ㅤㅤ✓ 사람들은 당신의 프로그램을 오용할 것임

ㅤ→ Future-proofing
ㅤㅤ✓ 가능하면 변경은 추가(additive)하는 방식으로. 기존 기능을 바꿔서 호환을 깨지말고, 새로운 플래그를 추가할 것
ㅤㅤ✓ 추가방식 변경이 아니라면 먼저 경고할 것
ㅤㅤ✓ 사람들을 위한 출력변경은 대부분 OK
ㅤㅤ✓ 사람들이 주로 쓰는 서브코맨드가 있다고, 명시하지 않아도 그걸 수행하는 catch-all Subcommand 는 만들지 말 것
ㅤㅤ✓ 임이의 Subcommand 명령 약자는 허용하지 말 것
ㅤㅤ✓ 언젠가는 잘 동작하지 않게 되는 "시한 폭탄"은 만들지 말 것

ㅤ→ Signals and control Characters
ㅤㅤ✓ 사용자가 Ctrl-C(INT signal)을 입력하면 최대한 빨리 중단할 것
ㅤㅤ✓ 사용자가 오래 걸리는 Clean-up 상태에서 Ctrl-C를 누른다면 무시할 것. 다시 누르면 강제종료 가능하게
ㅤㅤㅤㅤㅤ^CGracefully stopping... (press Ctrl+C again to force)

ㅤ→ Configuration
ㅤㅤ✓ XDG(X Desktop Group) 스펙을 따를 것
ㅤㅤ✓ 당신의 프로그램 것이 아닌 설정을 수정한다면 사용자에게 확인받고, 명확히 뭘 하는 것인지 알려줄 것
ㅤㅤ✓ 설정 파라미터는 우선 순위대로 적용할 것
ㅤㅤㅤㅤ플래그 > 쉘 환경변수 > 프로젝트 레벨 설정 (.env) > 사용자 설정 > 시스템 설정

ㅤ→ Environment Variables
ㅤㅤ✓ 환경변수는 명령이 실행되는 컨텍스트에 따라 달라지는 동작을 위한 것
ㅤㅤ✓ 이식성을 극대화 하기 위해, 환경변수는 대문자/숫자/밑줄만 포함되어야 하고 숫자로 시작하면 안됨
ㅤㅤ✓ 가능하면 환경변수에는 한줄짜리(single-line) 값을 사용
ㅤㅤ✓ 널리 사용되는 이름을 사용하지 말 것
ㅤㅤ✓ 가능하면 범용 환경변수를 체크하고 사용
ㅤㅤㅤㅤNO_COLOR, DEBUG, EDITOR, HTTP_PROXY, SHELL, TERM, TERMINFO, HOME, TMPDIR, PAGER, LINES ..
ㅤㅤ✓ 필요하다면 .env 에서 환경변수를 로딩
ㅤㅤ✓ 설정 파일로 .env 확장을 사용하지 말 것

ㅤ→ Naming
ㅤㅤ✓ 이름은 간단하고 외우기 쉬운 단어로
ㅤㅤ✓ 소문자만 사용하고, 꼭 필요할때만 -(대쉬) 사용
ㅤㅤ✓ 가능하면 짧게
ㅤㅤ✓ 키보드에서 치기 쉽게

ㅤ→ Distribution
ㅤㅤ✓ 가능하면 싱글 바이너리로 배포
ㅤㅤ✓ 쉽게 언인스톨 가능하게

ㅤ→ Analytics
ㅤㅤ✓ 도구의 사용 및 크래쉬 데이터를 사용자 동의없이 당신에게 보내지 말 것

싱글바이너리로 잘 만들어주는 Rust 와 Go 때문에 좋은 커맨드라인 도구들이 점점 많아지는 것 같습니다.

- 요즘 유용한 커맨드 라인 도구 모음 https://news.hada.io/topic?id=793
- 생산성을 높여주는 rust command line 유틸리티 https://news.hada.io/topic?id=2958

만드는 것도 더욱 편해지고 강력해지는 중

- Rust로 Command Line 앱 만들기 https://news.hada.io/topic?id=972
- Caporal.js - Node CLI 개발용 풀 프레임워크 https://news.hada.io/topic?id=2378
- create-node-cli - Node.js로 CLI 쉽게 만들기 https://news.hada.io/topic?id=3268
- Gooey 로 모든 언어 및 CLI 도구의 GUI 만들기 https://news.hada.io/topic?id=582
- ink - React로 CLI만들기 https://news.hada.io/topic?id=2041

 
왜 아이폰 타이머는 가짜로 시간을 표시할까

- 타이머 사용자가 시간을 직관적으로 인지할수 있도록 약 500ms(0.5초)의 시간을 더해서 계산하는 방식을 사용한다고
- 5초를 잡고 타이머를 누르면 0.5초동안 5라는 숫자를 보이다가 4초로 넘어가며, 0초 숫자도 0.5초만 보여줌
ㅤ→ 즉, 5.5 부터 0.5 까지로 가면서 5와 0을 0.5초씩 보여주는 것
- 위 내용을 자바스크립트로 구현해서 비교한 코드 : https://codepen.io/lhermann/pen/wvzPxXj

 
IP 주소 파싱의 재미

- 빠른 IPv4+v6 파서를 만들면서 배운 것들을 읽기 쉽게 정리한 글
- 정식(Canonical) 표현
ㅤ→ v4 : 192.168.0.1 , 1바이트 들의 Dotted Quad
ㅤ→ v6 : 1:2:3:4:5:6:7:8 , 2바이트 들의 Colon-Hex

[IPv6]
- 중간에 0이 많이 나오게 되므로 :: 로 하면 1개 이상의 0을 제거
ㅤ→ 1:2::3:4 = 1:2:0:0:0:0:3:4
- 마지막 32비트는 v4의 Dotted Quad 방식 표현 사용 가능
ㅤ→ 1:2:3:4:5:6:77.77.88.88 = 1:2:3:4:5:6:4d4d:5858
ㅤ→ fe80::1.2.3.4 = fe80:0:0:0:0:0:102:304
- :: 가 맨앞/맨뒤에 오는 케이스가 생겨서 조금 더 복잡해짐
ㅤ→ ::1 = 0:0:0:0:0:0:0:1
ㅤ→ 1:: = 1:0:0:0:0:0:0:0
ㅤ→ :: = 0:0:0:0:0:0:0:0
- IPv6 Colon-Hex 의 모든 필드는 4자리 16진수, 앞에 0은 제거 가능
ㅤ→ :: = 0000:0000:0000:0000:0000:0000:0000:0000

[IPv4]
- 재미난건, IPv6에서 마지막 32비트의 Dotted Quad 표현을 공식화 하기전에는 어떤 문서에서도 표준화 된적이 없음
ㅤ→ 그래서 보통 업계표준(de-facto)은 "4.2BSD 에서 해석 가능한가?" "다른 OS에서 4.2BSD를 복사했을때 뭘 유지했나" 였음
- 근데 4.2BSD는 좀 이상(whacky)함
ㅤ→ 192.168.140.255 = 3232271615 와 같음
ㅤ→ 즉, 크롬에서 http://3232271615 를 방문하면 http://192.168.140.255 를 로드함. 4바이트 숫자니까!
ㅤ→ 8진수인 http://0300.0250.0214.0377 도 가능
ㅤ→ 그럼 당연히 16진수인 https://0xc0.0xa8.0x8c.0xff 도 다 같은 주소
- CIDR (Classless Inter-Domain Routing) 은 IP주소에도 영향을 줌
ㅤ→ 클래스 C 표현인 192.168.140.255 은 클래스 B로 표현하면 http://192.168.36095 , 클래스 A로 표현하면 http://192.11046143
ㅤ→ 이래서 ping 127.1 = 127.0.0.1 이 가능. IPv6 처럼 중복0을 제거한게 아니라, 클래스 A 네트웍 127의 1번째 호스트를 의미. 즉, 24비트 숫자 1임
- 각 Quad의 숫자앞에 0은 몇개까지 가능할까 ?
ㅤ→ 001.002.003.004 ? 0000000001.0000000002.0000000003.000000004 ?
ㅤ→ ( 크롬은 http://0000000001.0000000002.0000000003.000000004 도 가능 )
ㅤ→ 이때 이 숫자를 8진수로 읽어야 할지, 16진수로 읽어야 할까 ? : 최근 구현들은 8진수/16진수를 포기하고, 앞에 0들을 10진수로 처리
- 이 선행 0 문제는 IPv6에도 영향을 줌
ㅤ→ 000001::00001.00002.00003.00004 = 1::1.2.3.4, or 1::102:304
ㅤ→ 최신 파서들은 대부분 "parse integer" 라이브러리를 사용하기 때문에 앞에 0이 많아도 다 허용

즉, 모든 IP 주소를 파싱하려면 이 거지같은 것들을 다 고려해야 하지만..

필자의 파서는 다음 정도만 추려서 지원
- 클래식한 v4 방식으로 점으로 구분된 정수, 앞에 0 갯수는 무제한으로 가능
- 클래스 A/B 표현식 및 8/16진수는 처리 안함
- unit32 숫자 한개로 모든 걸 표현하는 것도 처리 안함
- IPv6는 정식 colon-hex 방식 및 :: 줄임 방식과, 마지막 32비트에 IPv4 붙이는 것까지 허용(이 IPv4 는 앞의 규칙 적용). 각 필드의 앞 0 갯수는 무제한

* 초기엔 IPv4 에서 IPv6로 쉬운 이전을 위해 마지막에 IPv4 주소를 붙이는 방식을 넣긴 했지만, 실제로 잘 보이지 않음. 그래서 지원은 하지만 그닥 유용하지는 않다고 생각함

 
Archivy - 셀프호스팅 지식 저장소

- 북마킹한 웹페이지 내용을 로컬에 자동 저장
- 노트는 마크다운포맷으로 저장
- ElasticSearch를 이용한 검색
- 파이썬 오픈소스 : Flask 웹앱 + Click 으로 만든 CLI
- 플러그인 시스템 : Pocket/HN 을 자동 저장, Git연동

 
효과적인 비즈니스 이메일을 쓰자

"격식과 절차, 형식에 맞고 잘 읽히는 비즈니스 이메일 작성하기"
1. 메일을 받는 사람이 누구인가?
2. 메일의 주제는 무엇인가?
3. 이메일 스타일
ㅤ1) 어조 (Tone)
ㅤ2) 스타일 형식 (Format)
4. 베스트 프랙티스 총정리
ㅤ1) 제목 (Subject)
ㅤ2) 호칭- 본문 시작
ㅤ3) (분위기를 만들기 위한) 본문 문장 시작
ㅤ4) 실 본문
ㅤ5) 받는 사람에게 요청이 있을경우
ㅤ6) 클로징 멘트
ㅤ7) 서명
ㅤ8) 첨부파일과 링크
ㅤ9) 보내기 전 최종 리뷰

 
LibrePhotos - 구글 포토 오픈소스 대체제

- 도커로 설치가능. Django + React
- 얼굴 몇장에 수동 라벨링 하면 자동으로 나머지 분류하고 사람별 보기 지원
- 사진에 객체 인식하고 검색가능
- "베를린에서의 목요일" 같은 이벤트 자동 생성
- 지도위에서 사진 보기 및 장소로 사진 검색
- 일자별로 사진 보기
- 커스텀 앨범 생성 가능
- 백엔드 캐슁 및 최적화된 프론트 엔드

원래 Ownphotos 라는 별도 오픈소스인데, 원 개발자가 1년전부터 업데이트를 안해서 포크한 뒤에 계속 작업하는 중
올 6월부터 구글 포토에 용량 제한이 생기니까 사진많은 분들은 대체할 곳을 찾는게 필요할거 같아요

 
2020년 Top 10 Python 라이브러리

- Typer : CLI 제작
- Rich : CLI를 아름답게
- Dear PyGui : GPU 가속 GUI
- PrettyErrors : 에러를 보기좋게
- Diagrams : 클라우드 아키텍쳐 그리기
- Hydra & OmegaConf : 복잡하고 큰 어플 개발
- PyTorch Lightning : PyTorch를 쓰기 쉽게
- Hummingbird : 예전 ML모델을 PyTorch등으로 변환해서 더 빠르게
- HiPlot : 고차원 데이터용 대화형 시각화 도구
- Scalene : 고성능 고정밀 CPU & 메모리 프로파일러

* Norfair : 실시간 2D 객체 트래킹

그외 Honorable Mentions
- quart : Flask 호환 API를 가진 비동기 웹프레임워크
- alibi-detect : 테이블 데이터, 텍스트, 이미지, 시계열등에서 이상값(outlier) 모니터링
- einops : 읽기 쉬운 텐서 코드. numpy,PyTorch,TensorFlow 등 지원
- stanza : 자연 언어 처리
- datasets : 공개 데이터셋을 쉽게 로딩하고 전처리 하도록 도와주는 라이브러리
- pytorch-forecasting : 시계열 예측
- sktime : 머신러닝용 시계열 처리 프레임워크
- netron : 신경망/딥러닝/머신러닝 모델 뷰어
- pycaret : Low-Code 머신러닝 라이브러리
- tensor-sensor : 텐서 에러 메시지를 보기 좋게 시각화

 
MS Monaco Editor

- VSCode의 코드 에디터를 웹에서 사용 가능하게 분리한 모듈
- 크롬/Edge/FF/Safari 등 지원. 모바일은 지원 안함
- npm 모듈로 설치하여 사용 가능
- HTML,JS,TS,CSS,LESS,SCSS,JSON 의 IntelliSense 및 Validation
- 기본적인 언어들 Syntax Highlighting (Monarch 기반)
ㅤ→ PHP,C#,C++,Java,VB,Lua,R,Python,Ruby,Markdown 등
- 두 개의 창으로 Diff 보기 내장 (지원하는 모든 언어)
- 다크 테마 지원

 
Kit FUI - 영화/TV/게임에 나온 미래 UI 모음

- FUI : Fantasy / Fictional / Fake / Futuristic / Film / Future UI
- 영화/TV/게임등에서 미래세계를 표현할 때 사용했던 UI 들을 모은 사이트
ㅤ→ UI 스크린 샷
ㅤ→ UI 비디오
ㅤ→ 관련 정보(IMDb, TMDb, TheGamesDB)
ㅤ→ 제작 스튜디오 및 디자이너들

비슷한 다른 사이트들
- SF영화의 폰트만 모은 사이트 Typeset In The Future : https://typesetinthefuture.com/
- 영화에 나온 소스코드를 분석하는 유튜브 채널 Behind The Screens : https://www.youtube.com/channel/UCzOc0EEdwWAlnwrWV-7sDbg
- 영화/TV에 나온 코드들만 클로즈업해서 보여주는 Source Code in TV and Films : https://moviecode.tumblr.com/
- 영화/TV/뮤직비디오에 나온 모션 디자인 분석 https://paulroberts.tv/
- FUI Vision Video 모음 https://visionsofcomputing.wiki.cs.st-andrews.ac.uk/index.php/…
- 지난 50년간의 가상 컴퓨터 인터페이스 모음 https://glow-internet.com/infographics/…

 
M1 맥에서 바뀐 시작모드들

기존처럼 부팅할 때 키 조합을 눌러서 시작 모드를 바꾸는 방식이 아니라
터치아이디 전원버튼을 길게 누르고 있는 것 만으로 시작모드 옵션을 바꿀 수 있는 메뉴가 나타난다.

옵션에서 Command + D를 누르면 분석 모드 Diagnostics Mode
Options 아이콘을 누르고 계속하면 기존 복구 모드 Recovery Mode
쉬프트 누르고 Disk 아이콘을 선택하면 안전 모드 Safe Mode
디스크 목록이 다 나타나길 기다렸다가 어느 디스크로 부팅할 지 선택도 가능
옵션키를 누르고 Disk 아이콘 선택하면 Default 부팅 디스크 선택 가능
Verbose Mode는 복구 모드 윈도우 메뉴에서 볼 수 있음
SMC/NVRAM 리셋은 불가능
DFU Mode 공장 초기화 모드 가능 (다른 맥에 연결해서 복구 가능)
타겟 디스크 모드는 복구 모드에서 Share Disk로 선택
싱글 유저 모드는 복구 모드 터미널 여는 정도만 가능

 
TabFS - 브라우저 탭을 파일시스템처럼 다루기

- 브라우저의 탭들을 파일시스템 처럼 마운트 해주는 확장
ㅤ→ 탭이 세개 열려있으면 폴더가 3개로 보임
ㅤ→ 폴더안에 url.txt 는 주소 , title.txt 웹페이지 타이틀, text.txt 는 텍스트 내용
ㅤ→ 폴더를 지우면 탭이 닫힘
- 맥/리눅스 용 크롬/FF 브라우저 지원
- 사용 가능한 모든 도구/언어로 브라우저 컨트롤이 가능 (브라우저 확장을 만들 필요 없이)

[할 수 있는 작업들 예제]
- 모든 탭의 제목만 보기
ㅤ→ cat mnt/tabs/by-id/*/title.txt
- 모든 스택 오버플로 탭만 닫기
ㅤ→ rm mnt/tabs/by-title/*Stack_Overflow*
- 모든 탭의 텍스트 내용을 파일로 저장
ㅤ→ cat mnt/tabs/by-id/*/text.txt > text-of-all-tabs.txt
- 원하는 스크립트 실행
ㅤ→ echo 'document.body.style.background = "green"' > mnt/tabs/last-focused/execute-script
ㅤ→ echo 'alert("hi!")' > mnt/tabs/last-focused/execute-script

 
리눅스 강화 가이드

보안 및 정보보호에 중점을 둔 리눅스를 설정하는 법

1. 리눅스 배포본 선택하기
2. 커널 강화
3. 필수 접근 관리
4. 샌드박싱
5. 메모리 할당자 강화
6. 컴파일 플래그 강화
7. 메모리 세이프한 언어들
8. 루트 계정
9. 방화벽
10. 식별자
11. 파일 권한
12. 코어 덤프
13. 스왑
14. PAM
15. 마이크로코드 업데이트
16. IPv6 개인정보보호 확장
17. 파티션 & 마운트 옵션
18. Entropy
19. 루트계정으로 파일 편집
20. 배포폰별 강화
21. 물리적 보안
22. 모범 사례

이런 용도에 가장 적합한 배포본으로 Gentoo 를 추천하지만, 직접 선택하고 빌드해야 하는 사용성 문제가 있으니
그나마 나은 대안으로 Void 의 musl 버전 빌드를 추천하네요.
(글 내부에서 기본 C 라이브러리는 크고 복잡해서 공격지점이 많은 glibc 보다는 musl 을 추천하고 있습니다)

** 글 앞에 있는대로 이 가이드에서 추천하는 옵션들이 정확히 뭔지 더 조사해 보고,
ㅤ 그에 따른 사이드이펙트가 어떤게 있는지도 알아본 뒤에 적용해야 한다는걸 명심하세요.

배포본별 강화 가이드
- Fedora https://static.open-scap.org/ssg-guides/ssg-fedora-guide-index.html
- Debian https://wiki.debian.org/Hardening
- Gentoo https://wiki.gentoo.org/wiki/Hardened_Gentoo
- Redgat https://access.redhat.com/documentation/en-us/…
- SUSE https://documentation.suse.com/sles/12-SP4/single-html/SLES-hardening/

- 각 배포본용 보안 강화 Ansible 컬렉션 https://github.com/dev-sec/ansible-collection-hardening

 
오늘날의 GPU 연산 API

## 엔비디아
시장의 개척자, 발달한 툴킷. 여전히 빠르게 발전하고 있고 특히나 고레벨(higher-level) API는 더더욱 그러함. 엔비디아가 판매하는 모든 GPU는 CUDA를 지원함.
PGI로 불렸던, 리눅스에서만 사용 가능한 HPC SDK는 OpACC, C++ 표준 병렬화 (stdpar), OpenMP (베타) 지원을 추가함.
엔비디아의 HPC SDK 라이센싱의 문제 중 하나는 다음 조항임:
**You shall strictly prohibit the further distribution of the Run-Time Files by users of an End-User Application**
사용자가 번들된 앱에서 필요로 하는 런타임 파일을 포함한 채로 앱을 재배포할 수 없기 때문에 애플리케이션을 아예 배포할 수 없을 수도 있음. 이 문제는 대부분이 사용하고 있는 CUDA SDK에는 해당되지 않음.

## AMD
AMD 하드웨어에서 주력하고 있는 GPGPU 프로그래밍은 ROCm임. AMD가 소유한 HIP 외에 공식적으로 지원되는 건 OpenMP와 OpenACC.
여기에는 몇 가지 확실한 단점이 있음:
- 리눅스 전용, 따라서 시장 상당 부분에서 선택지에 들지 못함.
- ROCm 툴체인으로 생성된 바이너리는 IR을 타겟으로 하지 않고 하드웨어에 종속적임. 새로운 세대가 나오면 바이너리를 재컴파일 해야 함.
- 릴리즈 이후 꽤 오랜 시간 동안 새 하드웨어에 대한 지원이 사실상 없음.
이런 단점은 데스크탑에서의 유용성을 사실상 없는 것으로 만들고 OpenCL만 AMD GPU 하드웨어를 위한 벤더 제공 API로 남게함.

## Intel
oneAPI는 최근 출시한 모든 인텔 GPU에서 지원되지만 고성능은 아직 없음. Intel의 Level Zero 외에 공식적으로 지원되는 API는 OpenMP와 SYLC.
oneAPI의 Level Zero는 SPIR-V를 IR로 사용하여 향후 출시하게 될 하드웨어에 seamless한 지원을 가능하게 함. 윈도우 또한 지원함.

## Khronos
여러 벤더사에서 사용할 수 있는 업계 표준을 제공함.
OpenCL 3.0으로 알려진 reset은 아직 큰 영향이 없음. SYCL과 Vulkan 연산의 결합은 좋은 개발자 경험과 함께 단일 바이너리를 여러 벤더에서 사용 가능하게 하는 더 나은 길이 될 수 있음.

실제 OpenCL 지원:
오늘날 엔비디아는 extensions을 지원하는 OpenCL 1.2를 제공함.
AMD는 쓸만한 OpenCL 1.2 구현과 함께 엄청나게 버그가 많은 OpenCL 2.x 구현을 제공함 (제대로 디버깅할 방법도 없음).
Intel은 Intel GPU를 위한 OpenCL 3.0 구현을 제공함.
OpenCL 1.2는 Apple Silicon을 포함, macOS에서도 지원하긴 하지만 문서는 deprecate됨.

## Microsoft
C++ AMP는 죽은 것처럼 보임. Vendor-independent이면서 Visual C++의 지원을 받았지만 D3D11 후로 업데이트된 적이 없음. 오래된 ROCm 버전 또한 지원됐었음.

## Apple
Metal 연산은 macOS/iOS/…를 위한 것일 뿐. GPGPU 분야에서는 매력이 상당히 떨어짐, 특히나 GPU 연산 성능에선 더욱 그러함.

 
Stork - 정적 웹사이트를 위한 검색 라이브러리

"JAMStack을 위한 빠른 검색"
- Rust + WASM
- 스태틱 사이트 전체를 인덱싱해서 인덱스를 파일로 저장하고
ㅤ브라우저에서 JS가 인덱스 파일을 다운로드해서 검색창에 한글자 타이핑할 때마다 즉시 결과를 표시
- 모든 Static Site Generator 와 잘 동작. Netlify등에 호스트 한 것도 가능
- Stemming(스테밍, 어간추출)은 영어계열만 지원

인덱스를 아예 내려 받는 거니 Typesense 보다도 빠르긴 하겠네요.
너무 큰 사이트는 문제가 되긴 하겠지만 개인 블로그 등에는 사용하기 좋아보입니다.
- typesense - 오픈소스 검색 엔진 https://news.hada.io/topic?id=3369

 
Cosmopolitan libc - Build-Once Run-Anywhere C

- C코드를 어디서든 실행가능하게 만들어주는 라이브러리
ㅤ→ Java랑 비슷하지만 인터프리터나 VM필요없음
ㅤ→ Go/Rust 수준의 이식성을 제공하지만 C언어 그대로 사용
ㅤ→ 제공된 5개의 라이브러리 파일로 컴파일하면 그대로 맥/윈도우/리눅스 지원
- glibc 수준의 속도
- ape(αcτµαlly pδrταblε εxεcµταblε) 라는 포맷을 만들어서 사용
ㅤ→ Windows Portable Executable 을 UNIX 6th 에디션 쉘스크립트로 만들수 있다는 사실을 이용
ㅤ→ 포터블하지만 Go 버전 헬로월드 보다 100x 작음
- 내부에 BIOS 부트로더를 내장해서 베어메탈 부팅 후 실행도 가능

작성자인 Justine Tunney 는 유명한 해커입니다.
https://en.wikipedia.org/wiki/Justine_Tunney

베어메탈 실행 방법은 작성자가 HN에 댓글로 달아줬네요
https://news.ycombinator.com/item?id=25558363

뭔가 C로 코맨드라인 도구를 만드는 새로운 방법이 될수 있을듯 하네요

깃헙을 뒤져보는데.. 안에 각 OS를 표시한 ASCII 아트들이 인상적입니다.
https://github.com/jart/cosmopolitan/blob/master/ape/ape.S

 
6가지 무서운 장애 이야기

## 1. Charity Majors, CTO of Honeycomb
- 특정 지역(동유럽)의 사용자에게 push noti가 가지 않음
- ASG 사이즈 변경 직후부터 발생
- Round Robin DNS record가 UDP 패킷 사이즈를 넘어가서 발생

## 2. Matthew Fornaciari, CTO of Gremlin
- 디스크가 꽉차서 로그를 쓰지 못해 장애 발생
- 로그 로테이팅 기능 개발
- 디스크 사용량 얼럿 설정
- Gremlin을 통해 테스트 가능하게 추가 (카오스엔지니어링)

## 3. Lirran Haimovitch, CTO of Rookout
"매일 특정 시간에 서버가 다운된다는 도시 전설,
몇주에 걸친 조사 끝에 보안 카메라에서 원인 발견,
청소부가 진공 청소기 연결을 위해 서버 연결을 끊었음"

## 4. Daniel "Spoons" Spoonhower, CTO of Lightstep
- 앱 로딩이 되지 않음
- 당일 배포, 인프라 변경 없었음
- 내부 사용자들만 되지 않는 것으로 확인
- 앱로드용 api 확인중 내부 사용자의 경우 추가 데이터 반환부분 확인
- 지난 몇 주 동안 천천히 payload가 증가하다 그 날 오후 최대 payload 크기를 넘기면서 앱 로딩 실패

## 5. Lee liu, CTO of LogDNA

## 6. Ting Huang, CTO of Transpoit
- 트위터 모바일에서 읽을 수 없음
- 신규라이브러리에서 세션 쿠키 파싱을 못하는 문제 발견

 
USDS 디지털 서비스 플레이북

- 미국 대통령실 직속인 USDS(미국 디지털 서비스)가 정부의 디지털 서비스들이 성공하기 위한 13가지 핵심요소를 정리한 플레이북
- 각 항목당 체크리스트 와 주요 질문들로 구성
(꼭 정부뿐만 아니라 모든 디지털 서비스에 대응한다고 봐도 될듯 합니다)

1. 사람들이 필요한게 무엇인지 이해할 것
2. 처음부터 끝까지 전체 경험 해결을 목표로
3. 간단하고 직관적으로
4. 민첩하고 반복적인 방식을 사용하여 서비스 구축
5. (외주 개발작업을 계약할 때) 납품이 성공적으로 가능하도록 예산과 계약을 구조화
6. 한명의 리더를 지정하고, 그 사람에게 권한을 주고 책임지게 하기
7. 경험이 풍부한 팀을 영입
8. 최신 기술 스택을 선택
9. 유연한 호스팅 환경에 배포
10. 테스트 및 배포 자동화
11. 재사용 가능한 프로세스를 통해 보안 및 개인 정보 관리
12. 데이터를 사용하여 의사 결정
13. 기본적으로 Open 할 것 : 공개 협업 및 구축, 데이터 공개, 대중의 쉬운 기여, 누구나 재사용

USDS는 오바마가 오바마케어 초기시절 만들었던 https://www.healthcare.gov 의 실패 때문에 (트래픽을 감당 못하고 엄청 느림)
2014년에 만든 조직으로 트럼프 정부에서도 살아남았고, 현재 직원은 175명 정도입니다.
그들중 대부분은 기술 회사들에서 임시 휴직을 하고 들어온 기술 인력들입니다.
정부가 멍청한 디지털 서비스를 만들어서 예산을 아끼는 걸 방지하고 효율적으로 일하는걸 돕는 역할을 합니다.

지금은 구글에서 SafeSearch,Google Family Filter 개발에 참여했던 소프트웨어 엔지니어인 Matt Cutts가 수장으로 있습니다.
( Matt는 구글 검색결과에서 포르노 관련 결과물이 노출되는 걸 제보하는 사람에게 와이프가 만든 수제 쿠키를 선물하는 것으로 유명해서
"Porn Cookie Guy" 라는 별명을 가지고 있습니다. )

USDS 관련한 Wired의 기사 "Obama's US Digital Service Survives Trump—Quietly"
https://wired.com/story/…

 
Do You Love Me? [video]

- 보스턴 다이나믹스의 로봇들 Atlas, Spot, Handle이 노래에 맞춰 춤추는 영상
ㅤ→ Atlas : 2족보행, 28개의 유압 조인트, 1.5m / 80kg
ㅤ→ Spot : 4족보행, 84cm / 32.5kg, $75000(판매중)
ㅤ→ Handle : 2바퀴로 움직이는 외팔 로봇, 3m팔로 15kg 까지 들수 있음

* 노래는 The Contours 의 1988년도 곡 Do You Love Me?

현대가 인수해서 더 관심이 가는데요
손에잡히는 경제에서 보스턴 다이나믹스의 주인이 바뀌는 사연과 상용화에 걸림돌이 되는 소음에 대한 자세한 이야기를 들을 수 있습니다.
https://youtu.be/W8Ejbj6dnSQ?t=656

현대가 인수해서인지 음악만 한국노래로 바꾼것들이 나오네요. 묘하게 싱크로가 잘 맞습니다.

이박사 몽키매직 : https://www.youtube.com/watch?v=QP2yapbF9i8
Bot 내려온다 (범내려온다) : https://www.youtube.com/watch?v=9dWCuqxpwrg

 
YearCompass - 새해 나침반

- 올 한해를 돌아보고 새해 계획을 도와주는 다이어리
- 출력해서 손으로 적는 버전과 입력이 가능한 PDF 두가지 제공 (한글판)
- 혼자 또는 그룹으로 같이 진행 가능

작년
- 나의 작년은 어땠나요
- 6가지 문장으로 나의 작년을 적어보기
- 작년 한해에 대한 6개의 질문
- 최고의 순간은 ?
- 내가 성취한 가장 큰 3가지 목표는 ?
- 나의 가장 큰 도전 3가지
- 용서하기
- 흘려보내기
- 작년의 3가지 단어
- 작년에 읽었던 인상깊었던 책
- 작년에 일어난 것들에게 작별을 고하세요

새해
- 꿈은 크게 꾸기
- 새해에는 이런 일들이 일어날 거에요
- 미래를 위한 마법의 3가지 단어
- 6가지 문장으로 내년의 나를 표현해 보세요
- 새해 의 나를 대표하는 단어는
- 비밀스러운 소원

출력용 : https://yearcompass.com/booklets/…
입력용 : https://yearcompass.com/booklets/…

 
JSON Lines 포맷

"Newline Delimited JSON"
1. UTF-8 인코딩
2. 각 라인은 유효한 JSON 값(객체)이어야 함
3. 라인 구분자는 '\n'

한줄 당 하나의 JSON 객체가 들어가는 데이터 저장 포맷
ㅤ→ 데이터 스트리밍에 적합
ㅤ→ 중첩구조 처리가 쉬움
ㅤ→ .jsonl 파일 확장자를 추천