✍️ 글

Branch predictor: How many “if"s are too many? Including x86 and M1 benchmarks!

클라우드플레어에서 절대로 실행되지 않는 if 구문이 실제로 프로그램 실행 성능에 어떤 영향을 줄까라는 의문에서 시작해서, CPU의 Branch Prediction 기능을 실험해보는 글.

여러 종류의 CPU에서 Conditional jmp, Unconditional jmp, Never-taken jmp 등이 어떻게 성능에 영향을 주는 지를 실험합니다.

CPU 마다 BTB(Branch Target Buffer)의 구현이 다르고, 컴파일러 영향도 무시할 수 없으니 어디에나 적용될 수 있는 솔루션은 없긴 하지만, 아래와 같은 몇가지 인사이트는 얻을 수 있었다는 것이 결론입니다.

  • 프로그램의 hot code는 CPU의 BTB entries 크기를 벗어나지 않게끔해야 효율적
  • 절대 실행되지 않는 if 구문을 추가하는 것은 웬만하면 비용을 추가하지 않음

클라우드플레어는 예전부터 블로그에 굉장히 흥미로운 주제의 글들을 많이 올리고 있으니, 관심이 있다면 시간 날 때마다 들러서 확인해봐도 좋을 듯 싶습니다.

My current HTML boilerplate

13년차 웹 개발자가 웹 프로젝트를 할 때 자신이 사용하는 HTML 보일러플레이트 코드를 소개한 글입니다.

HTML의 head에 들어가는 다양한 태그들의 역할을 소개하고 있어, 저같이 필요할 때마다 야매로 웹 개발을 하는 사람들이 참고하기 좋은 듯 합니다. 이 글을 소개한 해커뉴스 스레드에도 사람들이 다양한 팁을 소개하고 있습니다.

추가로, htmlhead.dev에서 이 글에서 소개하는 것 외에도 다양한 태그를 소개하고 있습니다.

코더

최근 서울대 하순회 교수님이 매일경제에서 한 인터뷰에서, 컴퓨터공학 전공 학생들이 일찌감치 산업계로 나가는 것을 두고 “잡스는 커녕 단순 개발자만 키우고 있다” 며 아쉬움을 토로한 바 있는데, 이에 대해 긴 시간동안 현역에서 일한 개발자께서 쓰신 개발자라는 직업에 대한 고찰입니다. (사실 교수님의 인터뷰 내용의 본지는 코더에 대한 비판이라기 보다는 대학원 좀 많이 와줘😭하는 호소인 것 같기는 합니다.)

이 글을 쓰신 분은 포켓몬고를 만드는 Niantic에 계시다가 최근 구글로 이직하진 박상민님.

우리나라에서는 단순히 코딩을 하는 코더보다 큰 그림을 그리는 이른바 엔지니어 혹은 아키텍트를 더 높고 뛰어난 것으로 보는 경향이 있는데 (사무직과 현장직의 사회적 시선 차이와 비슷하다고 볼 수 있을까요?), 이 글에서는 결국 개발자는 코드와 싸울 때 가장 빛이 난다고 얘기합니다.

이 글에서는 개발자를 가수에 비유하는데요. 뛰어난 가수였던 박진영이 이제는 다른 가수들을 관리하는 소속사의 대표가 되었지만, 가장 빛이 나는 순간은 본인이 방송에 나와 노래를 부르는 순간이라는 것입니다.

한 편으로 저는 다른 분이 얘기한 요리사 비유를 좋아하는데, 레스토랑에서 메인 주방장은 직접 요리를 하기 보다는 다른 요리사들을 이끌고 전체적인 요리 퀄리티를 올리고 유지하는 것이 평소의 역할이지만, 중요한 순간에는 누구보다도 뛰어난 수준의 요리를 만들 수 있어야 한다는 것입니다.

추가로 이 글에서는 고급 개발자의 조건을,

  1. 개발을 잘할 것
  2. 겸손할 것
  3. 커뮤니케이션을 잘할 것

의 세 가지로 요약합니다.

문제는 이 셋을 모두 만족하는 사람은 매우 드물기에 고급 개발자를 찾아보기 힘들다고 합니다.

사실 이 중 1번은 타고날 수도 있고, 학계에서 배울 수도 있지만, 2번과 3번 조건은 학계에서보다는 오히려 산업계에서 몸으로 배워야 하는 것이기에, 꼭 천재 박사 개발자 == 고급 개발자는 아닌 것이지요.

Rust’s Most Unrecognized Contributor

Rust의 알려지지 않은 초기 기여자인 Dave Herman에 대해 소개하면서, 초기 Rust의 개발이 어떤 환경에서 이루어졌는지를 대략적으로 소개하는 글입니다.

지금은 유망하고 나름대로 튼튼(?)한 언어가 된 것으로 보이는 Rust이지만, 초기 환경은 굉장히 열악했다는 것을 알 수 있는데요.

대표적으로는,

  • 모질라에서 Rust를 언제든지 취소시킬 수 있는 프로젝트라고 생각하였고, 그렇기에 Dave가 모질라의 지원이 이어질 수 있도록 열심히 노력했다는 것
  • Rust가 커뮤니티 기반 언어가 된 것도 이러한 불안전성이 큰 요인이였다는 점
  • Rust의 개발 인원이 너무 적어서 사실 Rust의 많은 부분이 학생 인턴들을 통해 개발되었다는 점

등이 있습니다. 러스트가 개발자들 사이에서 도입하고 싶은 언어로 인기를 얻은 지는 꽤 된 듯 한데, 사실은 굉장히 열악한 환경에서 개발하고 있었다는 점이 흥미롭네요.

그 외에도, Rust가 매크로를 적극 활용하게 된 것이 Dave의 취향이 많이 반영된 점이라던가, Rust의 패키지 매니저인 Cargo를 만든 것이 Ruby의 Bundler나 Node.js의 yarn을 개발한 Yehuda Katz였다는 점도 알 수 있었습니다.

해당 글을 소개한 Hacker News 스레드도 같이 읽어보시면 좋습니다. 자바스크립트의 창시자이자 당시 모질라의 CEO였던 브랜든 아이크도 깨알같이 코멘트를 달았습니다.

The Art of Writing Loops in Python

파이썬의 itertools 라이브러리를 소개하는 글.

사실 글 자체는 미디움에 넘쳐나는 “너네가 모르는 OO의 N가지 특징들” 중 하나이지만, 개인적인 생각을 몇가지 적어두고 싶어서 소개합니다.

파이썬은 굉장히 많은 기능들을 표준 라이브러리나 기본 키워드 형태로 포함하고 있는데요. 대표적으로는 이 글에서 소개하는 itertools나 functools같은 라이브러리, 혹은 다른 언어에는 잘 없는 for loop이나 try/except에서의 else 키워드 등이 있습니다.

Simple is better than Complex라는 파이썬에 격언에 알맞게, 이러한 라이브러리나 키워드를 적재적소에 잘 활용하면 아주 코드를 깔끔하고 예쁘게 작성할 수가 있는데요.

한편으로는 파이썬을 많이 사용해보지 않은 사람이 파이썬으로 개발을 할 때에 이러한 라이브러리와 키워드를 보고 배워야할 러닝 커브가 늘어나는 요소가 되기도 합니다.

이런 점에서 파이썬의 대척점에 있는 언어가 Go라고 저는 생각을 하는데요. 구글에서 자기들이 쓰려고 만든 언어답게, 키워드의 수를 극단적으로 줄이고, 코드 포맷도 강제함으로써 누구나 금방 문법을 익히고 다른 사람의 코드도 금방 읽을 수 있게 만들었습니다.

파이썬을 처음 배울때는 알면 알수록 더 예쁘게 짤 수 있는 파이썬의 특징에 매력을 느꼈었는데요. 요즘은 오히려 Go와 같이 모두가 만족하지 못하지만 그 모두가 그럭저럭 잘 해낼 수 있는 특징을 가진 언어가 더 좋아보이기도 합니다.

Babel is used by millions, so why are we running out of money?

5월 둘째 주 Hacker News를 불타오르게 한 글😂

펀딩으로 운영되는 오픈소스 자바스크립트 트랜스 컴파일러인 Babel이 어떤 식으로 자금난을 겪고 있는지를 얘기한 글입니다.

결국 글 내용은 우리 펀딩 많이 좀 해주세요인데, 사람들의 반응이 폭발적이었던 것은 Babel 개발자에게 지급되는 급여에 대한 부분이었는데요.

유일하게 풀타임으로 Babel을 개발하고 있는 Henry에게 월 $11,000 (한화로 약 1,200만원)이 지급되고 있다는 내용을 보고, 일부 사람들이 너무 많은 양의 급여를 지급하고 있는 것이 아니냐하고 비판한 것입니다.

이에 대한 의견들로는,

  • 실리콘밸리에서 유능한 개발자가 저정도 받는 것은 오히려 부족한 수준이다.
  • 실리콘밸리 기준으로 책정하지 말고, 유럽에서는 그것의 절반 수준으로도 유능한 개발자를 고용할 수 있다.
  • 회사에서 개발자를 고용하면 단순히 지급되는 급여 말고도 복지, 보험 등 다양한 부가비용이 발생하므로 단순 비교는 적절치 않다.

등이 있었습니다.

오픈소스로 먹고 사는 부분, 국가간 급여 차이에 대한 부분 등 여러 가지 고찰해볼 거리가 많은 글인 듯 합니다.

Parse, don’t validate

Type-driven development 방법론을 파싱을 예로 들어 소개하는 글입니다.

Type-driven development는 어떤 기능을 구현하기 위한 타입을 우선적으로 정의하는 방법론인데요. 이에 대한 예시로 이 글은 리스트의 첫 요소를 반환하는 head 함수를 얘기합니다.

head 함수는 비어있지 않은 리스트에 대해서는 정상적으로 작동하지만, 비어있는 리스트가 입력으로 들어왔다면 실패합니다.

하스켈을 기준으로 생각하면, head 함수는 실패할 수도 있는 Maybe 타입을 반환해야 하고, 이를 검사하는 것은 head 함수를 호출하는 Caller의 역할이 되는데요.

1
2
3

head :: [a] -> Maybe a
head (x:_) = Just x
head []    = Nothing

이 글에서는 그러한 리턴값을 완화하는 방식(weakening the type of result)보다는, 함수의 입력 타입을 강화하는 방식(strengthening the type of the argument)을 제안합니다.

즉, head 함수의 입력 타입을 모든 리스트가 아니라 비어있지 않은 리스트로 정의해주면 된다는 것이지요.

여기서 한 걸음 더 나아가서, 이 글은 입력이 들어왔을 때의 파싱과 검증으로 이루어지는 일반적인 2단계의 과정을, Type-driven development를 이용해 파싱 과정에서 엄격한 타입 검사를 하는 방식으로 1단계로 줄일 수 있다고 얘기합니다. 그리고 초기 단계에 타입 검사를 마침으로서 후에 발생할 수 있는 오류로 방지하고 퍼포먼스도 향상시킬 수 있다고 말합니다.

함수형 언어가 아닌 다른 언어에도 이러한 패러다임을 쉽게 적용할 수 있을지는 잘 모르겠습니다만, 처음 들어보셨다면 전문을 읽어보시는 걸 추천하는 글입니다.

📌 북마크

Rust 입문용 치트시트

Rust를 처음 배우는 사람들을 위한 짧은 치트시트입니다.

📰 기술 뉴스

NDTI로 알아보는 나의 맞춤 채용 제안

기술 뉴스…는 아닌 것 같지만, 네이버에 이력서를 등록해 놓으면 맞춤 채용 공고를 보내주는 서비스.

최근 개발자에 대한 대우가 점점 높아지면서, 대기업들도 인재 채용에 열일인 모양입니다.

네이버에서는 월간 영입도 그렇고, 최근 직원들에게 주식을 나눠주는 것도 그렇고, 다양한 방식으로 인재를 모집하고 지키려는 모양새인데, 개발자로서 이런 풍토가 지속되었으면 하는 바람입니다.

Faster CPython

얼마 전 은퇴를 번복하고 마이크로소프트에 입사한 파이썬의 아버지 Guido가 CPython을 5년간 5배 더 빨라지게 만들겠다는 프로젝트를 공개했습니다.

사실 서드파티에서도 파이썬의 퍼포먼스를 개선하기 위한 프로젝트가 여럿 있었는데요. 대표적으로는 인스타그램의 Cinder나, 개발이 중단되었다 최근 개발을 재개한 Pyston 등이 있습니다.

수년 뒤의 파이썬은 어떤 모습일지 기대가 됩니다.

⚙️ 소프트웨어 / 프로젝트

AI Dungeon

GPT-3을 이용하여 만들어진 텍스트 어드벤쳐 게임.

자기가 하고자 하는 행동이나 말을 텍스트로 입력하면 그에 맞춰서 자동으로 스토리가 생성됩니다.

하다보면 가끔 이상한 문장들이 튀어나오기는 하지만, 전체적으로는 굉장히 자연스러워서 자연어 처리 기술의 발전을 느낄 수 있는 게임입니다.

다만 최근에는 유저들이 성적인 발언을 학습시킨다던가, 그것을 검열한다던가하는 이슈로 곤혹을 치르고 있는 듯 합니다.

Coding Escape

코딩으로 하는 방탈출 게임.

여러명이서 함께 플레이할 수 있습니다.

굳이 방탈출 게임을 코딩으로 해야하나 싶긴 합니다만😂

Qovery

흔히 얘기하는 CI/CD에서 Continuous Deployment(CD) 기능을 제공해주는 서비스.

자신의 AWS 계정을 등록해놓으면, 깃헙에 코드를 푸시했을 때 알아서 클라우드상에 배포해주는 서비스입니다.

Hashicorp의 Terraform이 클라우드 리소스를 관리해주는 IaaS 도구라면, Qovery는 거기에 소프트웨어 배포 프로세스를 얹은 서비스라고 할 수 있을 듯 합니다.

정확히 무엇에 비유하면 좋을지는 모르겠는데, Qovery는 자신들이 백엔드 계의 Netlify다라는 표현을 사용합니다.

2020년에 공개되어 1년 정도된 서비스인데, 배포 프로세스를 구축하기 번거로운 작은 팀에서 사용해보면 좋을 듯 합니다.

readme.so

리드미에 넣을 내용을 섹션별로 작성하게 도와주는 온라인 에디터.

리드미 파일을 본격적으로 쓰려다보면 무엇을 넣으면 좋을지 고민하다 다른 레포지토리를 참고하여 쓰게 되는 경우가 많은데, 그런 경우에 간단히 쓰기에 좋은 서비스일 듯 합니다.

이런 소소한 불편함을 캐치해서 서비스로 만들어내는 것도 훌륭한 개발자의 능력이겠지요.

깃헙 공식 트위터에서도 이 서비스를 소개했습니다.

Project Starline

Google I/O에서 새로 공개된 구글의 프로젝트입니다.

코로나 시국에 맞추어 멀리 떨어져 있는 사람들을 마치 눈 앞에 있는 것처럼 보여주는 기술인데요. 소개 영상만 보면 굉장히 감성적인데, 들어가 있을 기술은 어마어마할 것 같다는 생각이 듭니다.

우선 사람을 고화질 3D 이미지로 캡쳐하는 기술이 필요하고, 이를 실시간으로 전송할 수 있을 정도로 압축해야 합니다. 다시 이를 사실적으로 렌더링하는 기술도 필요할 것이구요.

나아가서 안경등과 같은 VR 장비 없이 하나의 디스플레이만으로 깊이감이 느껴질 수 있도록 하는 장치도 필요할테고, 음성을 실제로 대화하는 것처럼 공간감을 살려서 들려줄 수 있는 장치도 필요하겠죠.

구글이 이러한 기술들을 바탕으로 미래에 어떤 제품을 보여줄 지 기대가 되는 부분입니다.

📙 책 / 강의

A Philosophy of Software Design

티클(Tcl) 언어를 개발한 것으로 알려져있는 John Ousterhout 스탠포드 교수가 쓴 소프트웨어 디자인 방법에 대한 책.

이 책의 핵심 키워드는 복잡성(Complexity) 으로, 다양한 선택들이 소프트웨어의 복잡성을 더하는 요소가 될 수 있으며, 이를 지양해야 한다고 말합니다.

책의 대부분은 공감가고 쉽게 이해할 수 있는 내용이지만, 몇 가지 생각해 볼만한 아이디어들이 있어서 소개합니다.

  • 외부에 노출되는 것은 작은 모듈 여러개보다는 큰 모듈 하나가 낫다

처음 개발을 배울 때에, 한 모듈이나 함수가 크고 길어지면 잘못되었고 큰 함수를 여러 개로 나누는 것이 좋다는 얘기를 하는 경우가 많습니다.

그러나 이 책에서는 유저에게 자잘한 작고 많은 모듈을 노출시키는 것은 복잡성을 더하는 요소라고 말합니다.

대표적으로 소개하는 것이 Java의 I/O인데,

1
2
3

InputStream inputStream = System.in;
Reader reader = new InputStreamReader(inputStream); 
BufferedReader bufferedReader = new BufferedReader(reader);

기초적인 I/O 클래스와 버퍼링을 지원해주는 I/O 클래스를 구분함으로써, 대부분의 경우 이 둘을 같이 사용해야 함에도 불구하고 복잡성을 늘린 케이스라고 지적합니다.

  • 테스트는 중요하지만 테스트 주도 개발(TDD)은 좋아하지 않는다

테스트 주도 개발은 테스트의 단위가 되는 개별적인 기능을 개발하는 것에 집중하게 하고, 전체 소프트웨어의 최적의 디자인을 찾는 것은 뒷전으로 만들기 때문에 좋아하지 않는다고 말합니다.

Learn Rust With Entirely Too Many Linked Lists

다양한 링크드 리스트를 만들면서 러스트 문법 배우기.

최근 몇가지 러스트 강의를 살펴봤는데, 그 중에서 가장 러스트를 학습하기에 좋다고 느껴지는 강의입니다.

단순히 잘 되는 코드를 보여주는 것이 아니고, 수많은 러스트의 컴파일 에러와 싸워가면서 점진적으로 코드를 완성해나가는 내용이 인상적입니다.