Outsider's Dev Story

기술 뉴스 #233 : 23-11-01

outsideris@gmail.com (Outsider) — Wed, 01 Nov 2023 03:09:11 +0900

웹개발 관련

Why I Won't Use Next.js : Remix가 나오고 Remix를 계속 지지하던 Kent C. Dodds가 Next.js의 문제를 지적하는 글을 썼다.(영어)
- React의 테스트 프레임워크인 Enzyme에 불만이 있어서 Testing Library를 만들었는데 주요한 점은 이식성 때문이었다. Remix는 표준 웹 플랫폼을 그대로 이용하는 경우가 많아서 Remix에 익숙해 지면 웹에도 익숙해지지만 Next.js는 자신만의 API가 있어서 Enzyme과 비슷한 상황이라고 할 수 있다.
- Next.js는 Vercel 외에는 배포하기가 어렵기 때문에 OpenNext가 나올 정도이다. 이는 Vercel의 호스팅을 매력적으로 만들고자 한 것이지만 어디서나 배포할 수 있도록 하는 작업의 우선순위가 낮은 것은 분명하다. Remix는 JavaScript를 실행할 수 있는 모든 곳에 배포할 수 있게 설계되었다.
- Meta가 React를 소유할 때도 불안했지만 Vercel이 React 팀원들을 데려간 이후에는 오히려 덜 협조적으로 느껴졌다. Vercel은 Next.js와 React의 경계를 모호하게 하는 것처럼 보인다.
- Next.js의 안정적인 기능이 React에서는 카나리아 릴리스에 있는 이상한 상황이 종종 있다.
- 너무 많은 마법을 사용하는 데 대표적으로 fetch를 재정의해서 자동 캐싱을 추가한 것이다.
Why I'm Using Next.js : 위 Kent C. Dodds가 쓴 글에 Vercel의 VP of DX인 Lee Robinson가 반박 글을 작성했다.(영어)
- 웹 플랫폼을 그래도 이용해야 한다는 것에 동의하기에 Next.js도 2021년에는 미들웨어를 도입했고 이는 Remix가 출시된 해이기도 하다. 그리고 앱 라우터에서도 웹 플랫폼 API를 그대로 사용할 수 있다.
- Vercel은 Next.js를 Docker로 배포하는 방법에 대한 예제와 가이드를 하고 있고 셀프호스팅 할 수 있는 다양한 방법이 있다. 또한 Build Output API도 제공하고 있다.
- React와 Next.js의 경계를 모호하게 한다는 지적에 대해서는 고의가 아니며 React의 미래에 크게 걸고 있고 작업하는 중이며 경계를 명확하게 할 수 있도록 노력하고 있다.
- fetch에 대한 마법도 개선하려고 노력하고 있다.
- 마지막으로 Next.js를 좋아하는 이유는 별도의 백엔드를 만들 필요가 없고 인프라 걱정 없이 앱을 만들 수 있으면 사이트를 따르게 하는 기능을 다양하게 제공한다는 점이다.
Introducing HAR Sanitizer: secure HAR sharing : HTTP 아카이브 파일인 HAR는 웹브라우저와 웹 애플리케이션의 상호 작용에 대한 JSON 형식의 아카이브 파일인데 여기엔 인증 정보도 모두 담겨있기 때문에 세션 쿠키나 JWT 토큰이 유출되는 가장 일반적인 경로이기도 하다. Cloudflare에서는 HAR File Sanitizer를 공개해서 사용자가 HAR 파일을 업로드하면 쿠키, JWT 등을 모두 제거할 수 있게 했고 이 도구는 Cloudflare Workders 기반이고 모든 처리는 클라이언트에서 진행되므로 Cloudflare에서도 내용을 볼 수 없다고 한다.(영어)

그 밖의 개발 관련

Progress on no-GIL CPython : 지난 7월 Python steering council이 Global Interpreter Lock(GIL)을 선택 사항으로 만들겠다는 제안을 승인하겠다고 발표했습니다. 아직 결정 나진 않았지만, 그동안의 진행 과정을 정리한 글입니다. CPython 안정 ABI로 빌드된 확장 프로그램은 no-GIL CPython 3.13에서는 동작하지 않을 것이라서 이에 대한 해결책으로 둘을 모두 지원하는 새로운 ABI를 만들자는 의견도 있고 확장 프로그램이 두 가지 빌드를 모두 만드는 것이 오히려 비용면에서 낫다는 의견도 있다. 또한 이름에 대한 이슈도 있는데 사용자들이 테스트할 수 있도록 python3 외에 no-GIL도 설치해서 테스트해 봐야 하는데 python-nogil3, python-nogil3.13 등의 이름도 제안되었고 반대로 GIL이 뭔지 일반적인 개발자들이 알 필요 없으므로 nogil이라는 단어를 사용하지 않아야 한다는 의견도 있다. 이후 새로운 ABI인 abi4를 만들자는 아이디어를 채택해서 프로토타입을 개발 중이며 PEP가 필요하다는 데까지 합의가 된 상황이다.(영어)
Kafka에서 파티션 증가 없이 동시 처리량을 늘리는 방법 - Parallel Consumer : Kafka를 사용할 때 기본적으로 파티션 하나당 하나의 컨슈머만 붙을 수 있기 때문에 컨슈머가 메시지가 발행되는 속도를 따라가지 못한다면 Lag가 쌓이기 때문에 파티션을 늘려야 한다. 이는 프로듀서하고도 논의해서 늘려야 하는 부분이고 한번 늘리면 줄일 수 없기 때문에 문제가 되는데 Parallel Consumer를 이용해서 파티션을 늘리지 않고 처리량을 늘리는 방법을 설명한다. 기본 컨슈머와 Parallel Consumer의 동작 차이를 설명하고 오프셋 갱신의 처리 방법, 순서 보장 방법을 자세히 설명하고 있다.(한국어)
쿠버네티스가 스프링 부트 3.0 네이티브 이미지를 만났네 : 넷마블에서 JVM 이미지가 부팅 시간 때문에 팟이 늘어가는 데 걸리는 시간을 줄이기 위해 SpringBoot 3.0부터 GraalVM의 Native Image 생성 기능을 도입했다. 네이티브 이미지는 독립적으로 실행할 수 있도록 실행 환경에 맞춰서 빌드하므로 용량이 작고 부팅 시간도 크게 줄어들게 된다. 네이티브 이미지를 만드는 방법을 설명하고 이를 적용하면서 GC 설정과 리소스 설정을 적용하면서 차이를 보여주고 최종적으로는 50초였던 실행시간이 2초로 줄어들었고 이미지 크기도 300MB에서 70MB로 줄어들었다고 한다.(한국어)
Base64 Encoding, Explained : 개발하면서 자주 보는 Base64의 동작 방식을 RFC 4648을 공부하고 정리한 글이다. 대소문자 알파벳, 숫자, +, /의 64개의 문자를 사용해서 Base64인데 주어진 텍스트를 이진 표현으로 변환한 뒤 각 비트를 6비트로 나누고 각 그룹을 0~63 사이의 소수로 변환한 뒤에 Base64 알파벳으로 변환한다.(영어)

인프라 관련

Measuring Git performance with OpenTelemetry : Microsoft가 Windows나 Office의 저장소를 Git으로 마이그레이션 했을 때 300GB가 넘었고 역대 가장 큰 규모였기에 성능 개선이 필요했고 Git의 성능을 알 수 있도록 Trace2 기능을 Git에 포함했다. 이 Trace2만으로는 분석하기가 어렵기에 이를 OpenTelemetry로 수집할 수 있도록 오픈소스 수집기인 trace2receiver를 만들었다. 이를 통해 Git 명령어를 사용할 때 시간이 오래 걸리는 부분은 분석 추적해서 파악할 수 있게 되었다.(영어)
Vector를 활용해 멀티 CDN 로그 및 트래픽 관리하기 : Line에서 멀티 CDN을 사용하면서 로그와 트래픽을 모니터링하면서 Datadog에서 만든 Vector를 사용한 이야기이다. 기존에 모니터링이 있었지만, 시간이 지나면서 유지보수도 편하고 통합으로 관리할 수 있는 모니터링 체계가 필요했고 Vector를 사용하게 되었다. Vector는 데이터를 수신하는 source, 데이터를 변환하는 transforms, 데이터를 전송하는 sinks 단계로 구성되는 Aggregator 구성으로 Vector를 설치해서 log_to_metric 기능으로 CDN 로그를 받아서 메트릭으로 변환해서 Prometheus로 쏠 수 있게 구성했다.(한국어)
OWASP Kubernetes Top 10: A Comprehensive Guide : OWASP(Open Web Application Security Project)의 10대 Kubernetes 취약점을 하나씩 설명한 글이다.(영어)
1. 안전하지 않은 워크로드 구성: Alpine 등 가벼운 이미지를 사용해서 위험성을 최소화하는 것이 좋고 OPA 등으로 잘못된 구성을 차단하는 것도 좋다.
2. 공급망 취약점: Docker Hub의 이미지에도 많은 취약점이 포함되어 있으므로 이미지 스캔을 해야 한다.
3. 지나치게 허용적인 RBAC: RBAC Audit, Kubescan, Krane 같은 도구로 검사할 수 있다.
4. 중앙화된 정책 시행의 부재: Admission Controller로 필요한 정책을 적용할 수 있다.
5. 부적절한 로깅: 감사로그뿐 아니라 OS 로그, 네트워크 활동 로그 등을 남기고 모니터링해야 한다.
6. 인증 실패: 인증할 때는 반드시 2FA로 사람이 개입하도록 해야 하면 Falco 등으로 로그인을 감사할 수 있다.
7. 네트워크 세분화: Istio같은 서비스 메시나 CNI로 부적절한 내부 접근을 제어할 수 있다.
8. 시크릿 관리 실패
9. 잘못 구성된 클러스터 컴포넌트: 대표적인 실수로 Kubelet에 익명 인증 설정이 있고 kube-apiserver에서 TLS 구성을 추가
10. 오래되고 취약점이 있는 Kubernetes 컴포넌트: Kubernetes에서 취약점이 존재하므로 취약점 정보를 모니터링하고 업데이트해야 한다.

볼만한 링크

컴퓨터 해킹. 자유. 그리고 GNU. : GNU의 40주년을 기념한 모임이 스위스에서 열렸는데 이때 참석하신 분이 올리신 후기다. 글을 잘 쓰셔서 GNU를 어떻게 느끼고 있었고 왜 참여하고 무엇을 느꼈는지를 정리해 주셨는데 느껴지는 부분이 많다.(한국어)
Announcing the Recipients of the 2023 Spotify FOSS Fund : 작년에 Spotify에서 FOSS 펀드를 만들고 올해도 10만 유로(약 1억 4천만 원)로 AssertJ, Jdbi,Testcontainers, Xiph를 지원한다. 이 프로젝트는 내부 R&D 커뮤니티가 추천했다.(영어)
The Startup CTO's Handbook : CTO의 리더십, 관리, 기술 주제를 다루는 책으로 아마존에서 판매하고 있지만 저장소에서 원문 파일과 PDF 파일을 무료로 볼 수 있다.(영어)

IT 업계 뉴스

Tracking Unauthorized Access to Okta's Support System : Okta에서 도난당한 인증 정보를 이용한 악의적인 접근이 확인되어서 영향받은 모든 고객에게 알림을 보냈다. 이 글에는 아주 명확히 설명하고 있진 않지만, 고객센터에 HTTP 아카이브 파일인 HAR 파일을 업로드하게 하고 있는데 이 파일이 제대로 살균되지 않았고 이 파일이 도난당하면서 이 파일의 인증 정보로 공격자가 접근할 수 있었다.(영어)
AI.gov : 미국 바이든-해리스 행정부가 AI의 이점을 활용하고 위험을 완화하기 위해 미국 정부의 AI에 대한 방향성을 안내하고 AI 인력을 채용하기 위한 사이트를 공개했다. 이 사이트에서 AI 전문가가 정부의 움직임에 참여해 주기를 제안하고 있다.(영어)
HHKB Studio : HHKB 키보드에 포인팅 스틱과 마우스 버튼, 제스처 패드가 포함된 기계식 키보드를 출시했다.(일본어)
Microsoft의 급여 가이드라인 유출. 연봉, 채용 보너스 및 주식 보상범위가 직급별로 공개됨 : 비즈니스인사이더에서 유출된 Microsoft의 직급별 연봉과 보상 범위를 공개했다. 52 레벨부터 70 레벨까지 있으면 각 레벨별 연봉 범위와 보너스, 주식 보너스 범위를 볼 수 있다.(한국어)

프로젝트

WintetJS : Rust로 작성된 JavaScript 서비스 워커 서버로 SpiderMonkey 런타임을 사용하고 Cloudflare Workers, Deno Deploy, Vercel 처럼 WinterCG 스펙을 따름. 아주 빠를 뿐 아니라 WebAssembly로도 컴파일 가능. 릴리스 공지
Geist : Vercel에서 오픈소스 무료 폰트를 공개했다. Sans, Mono 2가지 종류다.
Skiff : DHH가 Kamal을 이용해서 정적 사이트를 nginx와 함께 배포하는 도구로 once.com을 만들 때 사용했다고 한다.
Is BGP safe yet? : Border Gateway Protocol(BGP)를 안전하게 하려면 RRKI를 구현해야 하는데 사용하는 ISP의 BGP가 안전한지 보여주는 사이트로 Cloudflare에서 만들었다.
JetBrains Writerside : JetBrains에서 문서작성 도구를 공개했다.

버전 업데이트

Next.js 14 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
- App/Pages 라우터에 5,000개의 테스트를 추가한 Turbopack으로 로컬 서버 시작 시간이 53% 빨라지고 코드 갱신이 94% 빨라짐.
- Server Actions가 Stable이 됨
- Partial Prerendering Preview 지원
- Next.js를 배울 수 있는 새로운 학습 사이트 Next.js Learn 공개
yarn v4.0.0 : Node.js 패키지 매니저, 릴리스 공지
Node.js v20.9.0 Iron(LTS) : 자바스크립트 런타임, 릴리스 공지
- Node.js의 새로운 LTS 버전인 Iron으로 24년 10월까지 활성 LTS로 관리되고 26년 4월까지 유지보수 모드로 지원된다.
Node.js v21.0.0 (Current)) : 자바스크립트 런타임, 릴리스 공지
- 새 LTS가 나옴에 따라 다음 Current 버전인 21이 나왔다.
- V8 엔진이 11.8로 업데이트되면서 안정화된 fetch, WebStreams를 지원
MDX v3.0.0 : JSX 확장 마크다운, 릴리스 공지
MSW v2.0.0 : JavaScript API Mocking 라이브러리, 릴리스 공지
Playwright v1.39.0 : Chromium, Firefox, WebKit 브라우저 자동화 Node.js 라이브러리, 릴리스 공지
Safari 17.1 : 웹브라우저, 릴리스 공지
k6 v0.47.0 : 부하 테스트 도구, 릴리스 공지
astro v3.4 : 정적 사이트 빌더, 릴리스 공지
- page 컴포넌트가 이제 partial page로 인식되어 DOCTYPE 없이도 HTML을 렌더링함
Hono v3.9.0 : 엣지용 웹 프레임워크, 릴리스 공지
Prisma v5.5.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
Grafana v10.2 : 매트릭 대쉬보드, 릴리스 공지
Mikro ORM v5.9.0 : TypeScript ORM, 릴리스 공지
Jotai v2.5.0 : React 상태 관리 라이브러리, 릴리스 공지
Storybook v7.5.0 : React, Vue3, Angular UI 컴포넌트 개발 도구, 릴리스 공지
Dagger v0.9 : CI/CD Pipeline as Code, 릴리스 공지
Nuxt.js v3.8.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
ESLint v8.52.0 : JavaScript 코드 분석 도구, 릴리스 공지
pgAdmin 4 v7.8 : PostgreSQL 클라이언트 도구, 릴리스 공지
GitLab v16.5 : 오픈소스 설치형 Git 플랫폼, 릴리스 공지
PgBouncer v1.21.0 : PostgreSQL 커넥션 풀, 릴리스 공지
CDK for Terraform v0.19.0 : Terraform Cloud Development Kit, 릴리스 공지
Zed v0.109.3 : 코드 에디터, 릴리스 공지
Nuxt DevTools v1.0.0 : Nuxt 개발자 도구, 릴리스 공지
Remix v1.9.0 : 풀스택 웹 프레임워크, 릴리스 공지
- View Transitions API의 실험적 지원
Ubuntu 23.10 Mantic Minotaur : Linux 배포판, 릴리스 공지
Docker Desktop v4.24 : 데스크톱용 Docker 애플리케이션, 릴리스 공지
Docker Desktop v4.25 : 데스크톱용 Docker 애플리케이션, 릴리스 공지
Open Policy Agent v0.58.0 : 클라우드 네이티브 환경의 정책 엔진, 릴리스 공지

댓글 쓰기

[Book] 오늘날 우리는 컴퓨터라 부른다 - 라이프니츠부터 튜링까지, 생각하는 기계의 씨앗을 뿌린 사람들

outsideris@gmail.com (Outsider) — Tue, 24 Oct 2023 03:18:42 +0900

오늘날 우리는 컴퓨터라 부른다 - 라이프니츠부터 튜링까지, 생각하는 기계의 씨앗을 뿌린 사람들

오늘날 우리는 컴퓨터라 부른다 - 라이프니츠부터 튜링까지, 생각하는 기계의 씨앗을 뿌린 사람들 - ⭐⭐⭐
마틴 데이비스 지음
박상민 옮김
인사이트
원제: The Universal Computer: The Road from Leibniz to Turing, Third Edition

트위터에서 역자이신 박상민 님이 인생에서 제일로 꼽을 만큼 좋은 책이라고 얘기하는 걸 보고 이 책을 알게 되었다. 처음 이 책의 제목을 보았을 때 좀 의아한 생각이 들었다. 아마 "무엇을?"이라는 의문이었을 것 같다. 무엇을 컴퓨터라고 부른다는 것이지? 라는 생각이었다.

뛰어난 프로그래머의 한 가지 특징은 추상화의 단계 사이를 너무나 쉽게 넘나드는 능력이다.
- 도널드 커누스(Donald Knuth)

이 책은 지금의 컴퓨터가 만들어지기까지의 과정을 다루지만 그동안 많이 봤던 대로 MIT의 TMRC나 벨 연구소의 얘기보다 훨씬 과거까지 간다.

이 책은 현대 컴퓨터의 근간을 이루는 아이디어와 그 아이디어를 발견한 사람들의 이야기다.

오늘날 컴퓨터 기술이 눈부신 속도로 발전하고 사람들은 공학 기술의 놀라운 성취에 감탄하지만, 이 모든 걸 가능케 한 논리학자들은 쉽게 간과하곤 한다. 이 책은 그들에 대한 이야기다.

책에 나오는 대로 컴퓨터가 만들어지기까지 그 전의 논리학자들에 대한 이야기이다. 이야기의 시작은 1600년대의 라이프니츠부터 시작된다. 처음 책을 읽을 때 느낌은 여기서부터 시작한다고? 같은 기분이었다. 책의 대부분은 수학과 논리학에 대한 이야기였다. 그래서 수학을 잘 못하는 나한테는 꽤 어려웠다. 많은 증명과 논리학에 대한 이야기로 이어지는데 설명이 꽤 자세하기는 하지만 아무래도 수학을 잘 아는 편은 아니라서 대략적인 흐름 외의 자세한 부분까지는 이해하기가 어려웠다.

그럼에도 꽤 흥미롭기는 했다. 지금의 내가 접하는 컴퓨터는 모두 디지털로 된 것이지만 지금의 컴퓨터가 만들어지기 까지 수많은 수학자들이 서로 논쟁하고 자기 생각을 증명하면서 발전해 오는 과정에서 결국 튜링과 폰 노이만까지 이어지고 이들이 과거의 연구를 구현하면서 결국 컴퓨터가 만들어졌다는 것은 놀랍기까지 하다. 한편으로는 내가 수학을 더 잘했으면 이 책이 훨씬 더 재밌을 것이라는 생각도 들었다.

라이프니츠의 비전은 인간의 모든 지식 또한 같은 방식으로 풀어내는 것이었다. 그는 범용의 수학 언어로 온 세상 지식을 표현하고 계산법이 지식과 지식 사이의 논리적 관계를 설명할 수 있는 완전한 지식의 백과사전을 꿈꾸었다.

이 체계는 대단히 강력한데, 그중 이 문자 체계를 사용하면 말이 안 되는 것(거짓된 사실)들은 표현할 수 없다는 점이 특히 중요합니다. 무지한 사람은 그 체계를 사용할 수 없습니다. 아니면 그 체계를 사용하면서 똑똑해질 것입니다.

라이프니츠는 숫자를 0과 1의 연속으로 표현하는 이진법을 발견했을 때 그 기호 체계의 간결함에 감탄했다. 그 간결한 체계가 고유한 성질을 드러내는 데 유용할 거라 믿었다. 비록 그의 믿음은 증명되지 않았지만 라이프니츠가 이진법에 특별한 관심을 보였다는 부분은 현대 컴퓨터 체계에 있어 이진법이 얼마나 중요한지를 살펴볼 때 놀랍다고 할 수 있다.

능력이 부족한 다른 사람들이 그의 연구를 무시하는 상황에서 프레게는 인생 전체의 노력을 집대성하는 책 두 번째 편의 출간을 앞두고 있었습니다. 그러나 자신의 핵심적인 가정에 오류를 발견한 바로 그 순간에도 개인적인 실망은 접어두고 지적인 즐거움을 표현하며 답장을 보냈습니다. 보통 사람이라면 거의 상상하기 어려운 일이었고, 인간이 명성이나 지위를 좇기보다 창조적인 일과 지식에 헌신할 때 얼마나 위대해질 수 있는지 보여 주는 사례라 할 수 있습니다.

그의 목표는 모든 수학의 기초에 논리가 있음을 보이는 것이었다. 다시 말해 논리가 다른 수학 분야 전체에 근본을 제공해야 했다. 이게 설득력을 갖기 위해서 프레게는 논리를 개발하는 과정에서 기존의 논리를 사용하지 않아야 했다.
그는 한 치도 틀림없이 정확한 문법을 갖춘 인공적인 언어인 개념 표기법(Begriffsschrift)을 만들어 이를 해결하려 했다. 이를 사용하면 논리적인 추론이 기호가 배열된 패턴의 단순한 기계적인 처리로 대체된다. 이것은 또한 정밀한 문법을 갖춘 최초의 정규화된 가상 언어였다. 이 관점으로 볼 때, 프레게의 개념 표기법은 오늘날 사용하는 모든 컴퓨터 언어의 시조인 것이다.

괴델은 근본적으로 사람의 사고가 컴퓨터와 동일한가라는 질문을 던졌다. 인공 지능을 둘러싸고 여전히 격렬하게 논쟁이 벌어지는 질문이다.

분명히 우리가 생각하는 연상(computation)의 정의는 급격하게 변했다. 연산의 정의를 이렇게 넓힐 수 있도록 한 개념적 토대는 1935년 앨런 튜링이 힐베르트의 논리 수학 문제를 해결하는 과정에서 만들어졌다.

중요한 점은 튜링이 우리가 계산이라고 부르는 과정을 분석한 결과 모든 계산이 가능한 것들은 튜링 기계에서 동작하는 알고리즘으로 표현할 수 있다는 사실이다. 그래서 어떤 특정한 문제를 튜링 기계에서 수행할 수 없다고 증명한다면 그러한 문제를 해결하는 알고리즘은 존재하지 않는다고 결론 내릴 수 있다. 그리고 이게 튜링이 결정 문제를 해결하는 알고리즘이 존재하지 않는다고 증명한 방식이다. 이 과정에서 튜링이 알고리즘이 존재하는 모든 문제를 계산할 수 있는 튜링 기계를 어떻게 만드는지를 보였다. 바로 범용 컴퓨터의 수학적 모델을 만든 것이다.

에니악이 계산을 위해 수를 십진수로 나타낸 반면에 에드박은 이진법을 사용해 계산을 단순하게 만들었다. 또한 에드박은 논리 제어 기관을 두고 메모리부터 명령어를 한 번에 한 개씩 읽어 계산 부분으로 넘겨주었다. 이렇게 컴퓨터를 구성하는 방식은 '폰 노이만 구조'라고 불리게 되었고 에드박 당시와는 아주 다른 부품을 사용하는 현대의 컴퓨터 역시 여전히 이 기본 구조를 따르고 있다.

오늘날 우리가 사용하는 개인 컴퓨터는 칩 하나로 만들어진 범용 컴퓨터라 볼 수 있는데 칩을 구성하는 실리콘 마이크로프로세서는 시간이 갈수록 더 복잡해졌다. 그 반대의 방향인 RISC(Reduced Instruction Set Computing) 구조는 칩 내부에 최소한의 명령어들만 사용하고 그 외의 필요한 기능들은 프로그래밍으로 제공된다. 많은 컴퓨터 제작사들이 사용하는 RISC 구조는 에이스(Automatic Computin Engine)의 철학과 아주 비슷한 방향이라고 볼 수 있다.

댓글 쓰기

[Book] 실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법

outsideris@gmail.com (Outsider) — Sat, 21 Oct 2023 16:45:42 +0900

실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법

실리콘밸리 리더십 - 애플 테크 리더가 들려주는 30가지 비법 - ⭐⭐
마이클 롭 지음
김정혜 옮김
한빛미디어
원제: The Art of Leadership

회사에서 다른 리더들과 독서 모임으로 읽은 책이다. 책의 저자인 마이클 롭은 넷스케이프, 애플, 슬랙을 거치면서 리더로 성장한 경험을 에세이처럼 30장에 걸쳐서 조언을 제공하고 있다. 각 장은 다른 조언을 얘기하고 있어서 개별 장을 꼭 이어서 읽을 필요는 없고 모든 걸 다 따른다기보다 자신의 상황에 맞는 조언 혹은 습관만 적용하는 식으로 책을 읽을 수 있다.

리더십 책을 인상 깊게 보는 경우가 많진 않은 느낌이긴 한데 이번 책도 그렇게 인상 깊지는 않았다. 기본적으로 책이란 건 의식하든 의식하지 못하든 내가 고민하는 부분이나 가려운 부분을 긁어줄 때 좋다고 느끼기 마련이라 책을 읽는 타이밍 등이 중요하다고는 생각하는데 리더십에 대한 고민이 없다기보다는 대부분은 사람의 문제인 경우가 많아서 책에 나온 내용으로는 그리 도움받는다는 느낌을 못 받아서 그런 거 같긴 하다.

각 장은 꽤 짧은데 말하고자 하는 내용이나 예시가 잘 공감되지 않은 부분도 있고 너무 추상적인 말이거나 이어지지 않는 느낌도 있어서 책이 크게 좋게 느껴지진 않았다. 책보다는 같이 독서 모임을 하는 다른 리더들과 얘기를 나눌 수 있어서 좋았고 내가 그냥 지나친 내용을 다른 사람이 인상 깊게 느꼈다는 얘기를 들으면서 다시 한번 더 생각해 보게 되기도 했다.

책에서 인상 깊게 느꼈던 부분을 그래도 정리해 보면...

내가 특히 좋아하는 리더십 습관은 일대일 회의다. 일대일 회의의 전도사라고 불릴 정도다. 수십 년에 걸쳐 매주 일대일 회의를 진행했고 직속 팀원들과 매주 얼굴을 맞댔다. 일대일 회의는 함께 일하는 사람들 간의 신뢰를 구축하는 가장 단순하고 믿을 만한 방식이다. 팀 전체에 영향을 미치는 현재의 사건에 관해 폭넓은 대화를 나눌 기회이기 때문이다.

일대일 회의는 사실 지금 있는 회사에서 거의 처음 해보고 있다. 뭐 리더 경험이 많지 않은 것도 사실이다. 그동안 내가 경력을 쌓으면서 일대일 회의를 하고 싶다거나 하는 생각을 별로 안 해서 그런지 나도 일대일 회의에 대한 가치를 아주 크게 느끼진 않고 있지만 회사에서 하고 있기도 하고 많은 책에서 권장하고 있어서 가능하면 일대일 회의는 미루지 않고 하려고 하고 있다. 여전히 일대일 회의에서 무엇을 논의해야 하는가 하는 어려움은 있지만 그래도 일대일 회의를 주기적으로 하면서(나는 지금 한 달에 한 번씩 하고 있다) 동료들의 상황을 파악할 수 있다는(어디까지 솔직히 얘기하는지는 알 수 없지만) 장점은 확실히 느껴진다.

팀장 회의 후에는 반드시 회의 내용을 팀원들에게 알려주어야 한다. 회의에서 무엇을 논의했는가? 이 일에서 무엇을 배워야 하는가? 이후에는 어떤 일이 생길까? 팀원 모두는 팀장급 회의가 열렸다는 사실을 알 뿐 회의에서 '무슨 일이' 있었는지는 모른다. 회의 내용을 팀원들과 공유하라. 리더로서의 '점수'를 거저로 딸 기회다.

회의 내용을 모두와 공유하라. 그렇게 하면 의사소통 오류가 줄고 사내 정치에 대한 예방 접종이 되어 면역력을 키우는 데 도움이 될 것이다. 뿐만 아니라 예상치 못한 뜻밖의 행운이 찾아오리라.

개인적으로 신경 쓰는 부분이다. 사안에 따라서 그러기 힘든 부분도 있지만 가능하면 결정이 나지 않더라도 어떤 논의를 하고 있는지 최대한 빨리 공유하려고 하고 있다. 그렇다고 회의 끝나고 팀원을 다시 모아서 회의를 여는 것도 어색하긴 해서 다음 정기 회의 때까지 기다리긴 하지만 그렇게 키워드를 공유해 놓는 것들이 나중에 진행되는 논의에서도 도움이 되는 것 같다.

나는 어떤 유형의 리더를 싫어하는지 정확히 말할 수 있다. 사람들이 즉흥적으로 행동하거나 반복할 수 없도록 또는 피드백의 여지를 주지 않으려 행동 하나하나를 짚어주는 리더가 싫다.

이런 리더는 나도 싫다. 그래서 그러지 않으려고 더 노력하다 보니 어떤 면에서는 책임을 회피하고 있는 건가? 싶을 때도 있다.

리더로서 당신에게는 확실한 무기가 있다. 바로 축적된 경험이다. 축적된 경험이야말로 리더가 반드시 갖춰야 하는 자질이다.

경험을 어디서 쌓는지가 문제이긴 하다. 또한 개인 엔지니어링 스킬과는 달리 경험을 쌓으면서 당연히 실패도 있고 실수도 있을 텐데 리더는 실패의 영향이 다른 사람들에게까지 더 많이 끼치게 되므로 조심스럽게 되고 조심스러워서 경험을 더 쌓기 어렵지 않나 하는 생각도 든다.

매사 사소한 것까지 관리하고 통제하도록 '기본값'이 설정된 리더는 속 빈 강정이다. 팀원들이 자기만의 경험을 구축하는 기술에 관해 하나도 배울 게 없기 때문이다.

마이크로 매니징은 나도 너무 싫어하는 형태이다.

사람들이 자기 생각을 거리낌없이 나누도록 멍석을 깔아주자. 획기적인 아이디어가 언제 나올지 아무도 모른다. 팀원들이 리더인 당신의 아이디어에 반박할 공산이 낮다는 사실을 명심하라. 이것은 리더가 나중에 행동해야 하는 또 다른 명백한 이유다.

리더와 팀원은 너무 나누는 건 별로 좋아하는데 또 전혀 경계가 없을 수 없기도 하다. 어려움 부분.

신참 관리자로서 스스로를 증명하고 싶은 의욕을 갖는 것은 당연하다. 그래서 당신은 모든 일을 자발적으로 떠안고 주구장창 야근을 하며 무리수를 둔다. 게다가 생전 처음으로 직속 직원들이 생겼으니, 그들에게 당신의 지위를 각인하는 동시에 좋은 첫인상을 주려고 젖 먹던 힘까지 짜낸다. 관리자가 되기 전 개별 기여자였을 때는 이런 접근법이 매우 효과적이었을 것이다. 그래서 당신은 팀의 리더일 때도 이 방법이 효과적일 거라고 단정짓는다.

이렇게 되기 쉬운 거 같긴 하다. 나도 우리 파트에서 일어나는 일의 대부분을 파악하고 있으려고 하고 그렇기에 파트 규모를 늘리는데 조심스럽긴 하다. 당연히 흐름을 놓치지 않고 의사결정에 참여하려면 알고 있어야 한다고 생각하면서도 너무 많이 간섭하려고 하는 건 아닌지에 대한 걱정도 있고 어쩌면 내 능력 범위에 파트의 능력이 갇히는 건 아닌지에 대한 걱정도 있다.

관리자가 되었다고 해서 갑자기 누군가에게 당신의 일을 위임하려니 본능적으로 꺼려진다. 위임은 힘과 맥락을 잃는다는 뜻인 데다 당신은 그런 상실에 익숙하지 않다.

업무에 따라 약간 다르긴 하지만 위임은 조금씩 익숙해지고 있는 것 같다.

이 순간 그 상황에 대한 전적인 책임을 통감하는 관리자라면 ‘나는’이라는 단어를 아주 많이 사용할 것이다. 또한 송곳같이 날카로운 질문을 퍼부을 것이다. 그런 질문에는 그것이 그가 해결해야 하는 그의 문제라는 인식이 담겨 있다. 어차피 자신도 윗선에서 어려운 질문을 받을 것이기 때문이다. 그 관리자는 책임감을 느낀다. 그러나 그가 사용하는 단어들 사이에 꽁꽁 숨고 그가 묻는 질문들의 뒤에 음흉하게 감춰진 속내가 있다. 그는 내가 이 일을 주도한 엔지니어라면 우리는 절대로 이런 상황에 처하지 않았을 것이라고 생각하는 것이다.
조심하라. 신뢰를 갉아먹는 소리가 들리는 듯하다.

저런 생각이 들면 정말 힘든 것 같다. 또 모든 걸 맡기기만 하면 잘 되는 것은 아니기 때문에 어느 순간이 개입할 때이고 어느 순간이 기다려야 할 때인지가 어렵다. 그래도 요즘은 그런 고민을 거의 안 하기는 하는데 조직마다 성격이 좀 달라서 다른 조직에서는 또 어떨지 잘 모르겠다.

먼저 하기 어려운 말을 하는 법을 배우고, 그런 다음 듣기 힘든 말을 적극적으로 듣는 것이다.

피드백이 아무리 비판적이더라도 주의 깊게 경청하고 그저 대략적으로라도 이해하도록 노력하라.

듣기 힘든 말을 듣는 건 항상 사람으로서는 어려운 일이긴 하지만 제일 어려운 건 듣기 힘든 말도 할 수 있는 분위기인 것 같다. 기본적으로 비판적인 피드백이 없을 때 그럴 만한 일이 없는 건지 사실은 있지만 말을 안 하는 건지 판단할 수 없다고 생각한다. 보통은 후자일 가능성이 높을 텐데 그렇다고 말하라고 한다고 말하는 것도 아니니까...

소소한 일을 처리하느라 쉴 새 없이 움직이지만, 정작 결과를 놓고 보면 괄목할 만한 진전을 이뤘다는 기분이 들지 않는다. 이런 삶이 바로 테크 리더의 현실이다.

수시로 이런 느낌이 드는데 테크 리더만 그런지는 잘 모르겠다.

엔지니어로서 나는 여전히 관리자들의 역할에 대해 회의적이다. 심지어 내가 관리자가 되어서도 그렇다.

어느 정도는 동의한다.

서로의 견해에 동의하지 않는 것도 피드백이다. 따라서 우리는 서로의 의견에 효과적으로 반대하는 법을 배울 필요가 있다. 그 방법을 빨리 배울수록 서로를 더 빨리 (그리고 더 많이) 신뢰하고 존중하게 될 것이다. 아이디어는 합의를 통해 발전하지 않는다.

중요한 말이다.

댓글 쓰기

기술 뉴스 #232 : 23-10-16

outsideris@gmail.com (Outsider) — Mon, 16 Oct 2023 03:59:05 +0900

웹개발 관련

[번역] Chakra UI의 미래 : The future of Chakra UI의 번역 글로 Chakra UI가 앞으로 가려고 하는 방향에 관해서 설명하는 글이다. Chakra UI가 성장하면서 도전적인 문제로는 런타임 CSS-in-JS를 가진다는 문제였고 RSC가 나오면서 이 부분은 더 중요해졌다. Chakra UI는 프레임워크에 종속적이지 않아야 하고 디자인 토큰을 받을 수 있어야 하고 런타임 CSS-in-JS를 제거하고도 지금의 직관적인 Style Pros를 유지하면서 유지보수가 쉬워야 했다. 이러한 미래로 가기 위해서 UI 컴포넌트를 위한 저수준 상태 머신인 zag, Zag 기반의 헤드리스 컴포넌트인 Ark, 제로 런타임 CSS-in-JS인 panda를 만들게 되었다고 한다.(한국어)
Flat config rollout plans : 2019년 RFC가 올라오고 2022년에야 실험적 버전을 출시한 플랫 컨피그를 9.0.0에5서 원활하게 전환할 수 있게 안내하는 글이다. 9.0.0부터는 플랫 컨피그가 기본적으로 적용되므로 .eslintrc.* 파일 대신 eslint.config.js 파일을 검색하고 기존 방식을 사용하려면 ESLINT_USE_FLAT_CONFIG를 false로 설정해야 한다. ESLint 10.0에서는 eslintrc 시스템이 완전히 제거될 예정이다.(영어)
Announcing v0: Generative UI : 최근 Vercel에서 프롬프트를 입력하면 UI를 만들어 주는 v0을 소개하고 사람들의 높은 관심에 따라 베타로 전환하면서 유료 구독 요금제를 발표했다.(영어)

그 밖의 개발 관련

The Internals of Deno : Deno의 내부 동작을 자세히 설명하는 무료 이북이다. Deno의 아키텍처, 스레딩 모델, 브릿지, 기반, 임포트와 Ops를 하나씩 설명하고 Deno 입문자를 위한 자료가 아니라 Deno 내부를 자세히 알고 싶은 사람들을 위한 자료다.(영어)

인프라 관련

HTTP/2 Rapid Reset: 기록적인 공격의 분석 : 이번에 공개된 제로데이 취약점 HTTP/2 Rapid Reset가 Cloudflare뿐 아니라 Google이나 AWS에도 공격이 있었음을 알게 되고 협력해서 해당 공격에 대처했다고 한다. HTTP/2는 스트림을 동시에 여러 개 열 수 있고 클라이언트는 스트림 취소를 할 수 있는데 이번 HTTP/2 Rapid Reset는 빠르게 취소 요청을 보내서 서버 쪽에서 스트림 종료 처리에 걸리는 시간을 이용해 서비스 거부 공격을 발생시킨다.(한국어)
2023 State of DevOps Report : DORA의 2023년 DevOps 상태 리포트가 나왔다.(영어)
Cloud Native Computing Foundation Announces Cilium Graduation : eBPF 기반 네트워킹 도구인 cilium이 CNCF 졸업 프로젝트가 되었다.(영어)

볼만한 링크

Roundtable: Development Culture : 슈퍼셀의 이욱진 님이 한국에 오셔서 라운드테이블로 게임 업체 간 문화를 공유하는 자리를 만들고 그 결과를 공유한 자리다. 슈퍼셀을 각 게임을 만드는 담당자들이 게임 종료를 포함해서 직접 의사결정을 하고 가능한 한 투명하게 정보를 공유하려고 노력하는 문화가 재밌게 느껴졌고 슈퍼셀의 문화와 참가자들과 논의한 내용이 정리되어 있다. 개인적으로는 Disagree and commit이라는 의사결정 구조, "난 동의하지 않지만, 결정이 그렇게 났으니 따른다."라는 방식에 공감되었다.(한국어)
Why being an open startup matters : cal.com에서 기술적/운영적으로 가능한 한 공개적으로 지표를 공유하는 스타트업을 오픈 스타트업으로 정의하고 이 오픈 스타트업이 왜 중요한지를 설명한다. https://cal.com/open에서 지표를 공개하고 있는데 직원의 연봉을 공개하는 것은 질투를 줄이고 인종 및 성평등을 촉진하는 효과가 있었고 cal.com도 원격 근무를 하므로 글로벌 급여를 도입할 것인지 현지화된 급여를 도입할 건인지 고민했지만, 글로벌 급여를 도입하기로 했다고 한다.(영어)

IT 업계 뉴스

LINE과 Yahoo! JAPAN이 만나 함께 새로운 기술 블로그를 시작했습니다! : Line Corporation과 Yahoo JAPAN Corporation이 합쳐서 LY Corporation이 됨에 따라 개발 블로그도 새로 시작하게 되었다.(영어)

프로젝트

Bruno : Postman/Insomnia의 오픈소스 대안으로 API를 테스트해 볼 수 있는 IDE
localpilot : GitHub Copilot을 인터넷 연결 없이도 로컬에서 사용할 수 있게 하는 앱.

버전 업데이트

Flask v3.0.0 : Python 웹 프레임워크, 릴리스 공지
Lit v3.0.0 : 웹 컴포넌트 라이브러리, 릴리스 공지
Argo Workflows v3.5.0 : 컨테이너 기반 워크플로우 엔진, 릴리스 공지
astro v3.3 : JavaScript 웹 프레임워크, 릴리스 공지
WebdriverIO v8.18.0 : Browser 테스트 자동화도구, 릴리스 공지
Lighthouse v11.2.0 : Progressive Web Apps용 성능 분석 도구, 릴리스 공지
Zed v0.107.6 : 코드 에디터, 릴리스 공지
Kafka v3.6.0 : 분산 이벤트 스트리밍 플랫폼, 릴리스 공지
Electron v27.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Python v3.12.0 : 프로그래밍 언어, 릴리스 공지
Prisma v5.4.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
Gradle v8.4 : Java 빌드 도구, 릴리스 공지
- Java 21 지원
PyTorch v2.1.0 : Python 딥러닝 프레임워크, 릴리스 공지
Rails v7.1.0 : Ruby 웹 프레임워크, 릴리스 공지
Rust 1.73.0 : 프로그래밍 언어, 릴리스 공지
ESLint v8.51.0 : JavaScript 코드 분석 도구, 릴리스 공지
Argo CD v2.8.0 : Kubernetes 배포 도구, 릴리스 공지
Fresh v1.5 : Deno 풀스택 웹 프레이워크, 릴리스 공지
curl v8.4.0 : URL로 데이터를 처리하는 CLI, 릴리스 공지
Parcel v2.10.0 : 웹 애플리케이션 번들러, 릴리스 공지
Terraform v1.6 : Infrastructure as Code 도구, 릴리스 공지
- Test framework 도입
Consul 1.17 : 서비스 디스커버리/설정 도구, 릴리스 공지

댓글 쓰기

[Book] Observability Engineering

outsideris@gmail.com (Outsider) — Sat, 14 Oct 2023 23:16:18 +0900

Observability Engineering

Observability Engineering - ⭐⭐⭐⭐
Charity Majors, Liz Fong-Jones, George Miranda 지음
O'Reilly Media

수년째 참여하고 있는 인프라 스터디에서 그룹스터디하면서 읽은 책이다. 이 책은 트위터에서 Daniel Lee님이 추천해 줘서 위시리스트에 담고 있었는데 스터디 주제를 찾다가 이 책을 선정했다. 아무래도 원서라서 은근히 미루게 되어 안 읽게 되는데 그룹스터디로 하면 끝까지 읽을 수 있다.

5월 23일에 스터디를 시작해서 매주 하면서 이번 주까지 했으니 거의 6개월 스터디를 했다. 스터디는 좋았지만 그래도 6개월은 꽤 길긴 하다. 항상 더 빨리 끝내고 싶지만, 또 스터디를 하다 보면 진도 빼는 게 목적이 아니라 공부하는 게 목적이다 보니 이야기 나누고 질문하고 하다 보면 길어지기도 하고 해서 항상 5~6개월은 하게 되는 거 같다. 그래도 이제는 DeepL이 있어서 이전보다 훨씬 수월하게 원서로 스터디를 진행했다. 전에도 좀 이용하긴 했지만 아무래도 번역 품질이 좋아져서 후처리를 좀 덜 해도 되기도 하고 후처리를 안 해도 한국말은 좀 어색하지만, 대부분의 경우 무슨 말인지 이해는 할 수 있었다.

그리고 New Relic이나 Datadog등을 써보긴 했지만 옵저버빌리티 혹은 모니터링 시스템을 구축하는 역할은 아니라서 아주 자세히는 알지 못한다. PromQL도 잘 못 쓰는 사용자 정도의 느낌이지만 인프라 업무를 하다 보니 어느 정도의 관심은 있고 주워들은 것도 있는데 같이 스터디하시는 분들이 다양한 경험들이 있어서 그룹 스터디를 한 게 혼자 읽는 것 보다 더 도움이 됐다.

이 책은 옵저버빌리티 솔루션인 honeycomb.io의 Charity Majors, Liz Fong-Jones, George Miranda 세 명이 쓴 책으로 옵저버빌리티 솔루션을 만들면서 그동안 했던 많은 고민의 결과를 담은게 이 책이라고 생각한다.

Charity Majors는 honeycomb.io의 공동창업자이기도 한데 책에도 나오지만 2011년에 모바일 개발자에게 백엔드를 제공해 주는 Backend as a Service(BaaS)로 출시된 Parse에서 일했는데 Parse 특성상 한 사용자가 갑자기 서버 리소스를 다 먹거나 문제를 일으키거나 할 때 문제를 파악하면서 옵저버빌리티에 관심을 가지게 되었고 Parse가 Facebook에 인수되어 Facebook에서 일하면서 거의 모든 데이터를 다 넣어놓고 탐색하는 Scuba를 쓰면서 옵저버빌리티에 대한 많은 생각을 가지게 되고 결국 창업까지 이어지고 이 책까지 나오게 된다.

아무래도 모니터링이나 옵저버빌리티를 고민하고 있거나 구축하는 사람들에게 도움이 될 책이라고 생각한다. 어떤 면에서는 너무 이상적인 얘기를 한다는 느낌이 들 수도 있지만 앞으로 우리가 준비해야 할 옵저버빌리티는 이래야 한다고 방향성을 제시한다는 점에서 꽤 좋았고 저자들이 많은 경험이 있기 때문에 기술적으로 고려해야 할 부분도 잘 짚어주고 있어서 도움이 많이 되었다.

Part 1. The Path to Observability

데이터베이스의 맥락에서 카디널리티는 집합에 포함된 데이터 값의 고유성을 나타냅니다. 낮은 카디널리티는 열의 집합에 중복된 값이 많다는 것을 의미합니다. 높은 카디널리티는 열에 완전히 고유한 값이 많이 포함되어 있음을 의미합니다. 단일 값을 포함하는 열은 항상 가능한 가장 낮은 카디널리티를 갖습니다. 고유 ID를 포함하는 열은 항상 가능한 가장 높은 카디널리티를 갖습니다.

카디널리티는 옵저버빌리티에 중요한데, 카디널리티가 높은 정보는 거의 항상 시스템을 디버깅하거나 이해하기 위해 데이터를 식별하는 데 가장 유용하기 때문입니다.

안타깝게도 메트릭 기반 툴링 시스템은 카디널리티가 낮은 차원만 합리적인 규모로 처리할 수 있습니다. 비교할 호스트가 수백 개에 불과하더라도 메트릭 기반 시스템에서는 카디널리티 키 공간의 한계에 부딪히지 않고는 호스트 이름을 식별 태그로 사용할 수 없습니다.

옵저버빌리티란 새로운 코드를 배포하지 않고도 시스템이 아무리 새롭거나 기괴한 상태에 빠질 수 있는 모든 상태를 이해하고 설명할 수 있다는 것을 의미합니다.

이 책 전체적으로 높은 카디널리티를 엄청나게 강조하고 있다. 지금 사용하는 모니터링 시스템(이 책에서는 모니터링과 옵저버빌리티를 구분한다)에서는 카니널리티가 낮기 때문에 더 자세하게 파악하기가 어려운데 카디널리티를 높게 할 수 있으면 시스템의 더 자세한 내용을 관측할 수 있다.

기존 모니터링 도구는 이전에 알려진 오류 조건의 존재 여부를 나타내는 알려진 임곗값(threshold)에 대해 시스템 조건을 확인하는 방식으로 작동합니다. 이는 이전에 발생한 장애 모드를 식별하는 데만 효과적이기 때문에 근본적으로 사후 대응적인 접근 방식입니다.
반면, 옵저버빌리티 도구는 반복적인 탐색 조사를 통해 성능 문제가 발생할 수 있는 위치와 이유를 체계적으로 파악할 수 있습니다. 옵저버빌리티는 이전에 알려졌거나 알려지지 않은 모든 장애 모드를 식별하기 위한 사전 예방적 접근 방식을 가능하게 합니다.

메트릭은 일반적으로 종합적으로 볼 때 더 유용합니다. 추세 이해하기 메트릭 값을 이해하면 소프트웨어 성능에 영향을 미치는 시스템 동작에 대한 인사이트를 얻을 수 있습니다. 모니터링 시스템은 메트릭을 수집, 집계 및 분석하여 사람이 알고 싶어하는 추세를 나타내는 알려진 패턴을 선별합니다.

기존 모니터링과 옵저버빌리티를 구분해서 얘기하고 있는데 옵저버빌리티를 그래서 어떻게 이렇게 할 수 있느냐를 떠나서 모노리스로 서버 한 대가 있다면 큰 상관이 없겠지만 마이크로서비스로 서비스가 많이 떠 있다면 모니터링 자체가 상당히 어려워지기 때문에 이 내용에 동의하는 편이다. 오류가 증가하거나 레이턴시가 증가할 때 연쇄적으로 발생할 가능성이 높기 때문에 어디가 원인이고 어디가 영향받은 것인지 파악하는 것도 쉽지 않은 일이다.

그 임곗값이 정확히 어디인지는 사람이 결정합니다.

모니터링 기반 접근 방식에서는 팀에서 가장 오래 근무한 엔지니어가 팀에서 가장 뛰어난 디버거이자 최후의 디버거인 경우가 많기 때문에 연공서열이 지식의 핵심이라는 생각에 초점을 맞추는 경우가 많습니다

옵저버빌리티 도구를 사용하면 팀에서 가장 뛰어난 디버거는 일반적으로 가장 호기심이 많은 엔지니어입니다. 옵저버빌리티를 실천하는 엔지니어는 탐색적인 질문을 통해 시스템을 조사하고, 발견한 답을 사용하여 더 개방적인 질문을 할 수 있는 능력을 갖추고 있습니다

프로덕션 환경에서 알려진 임곗값을 초과하는 시스템 상태의 엣지 케이스를 찾는 모니터링 알림은 엄청난 수의 오탐, 오탐, 무의미한 노이즈를 생성합니다. 알림은 사용자 경험에 직접적인 영향을 미치는 증상에만 집중하여 더 적은 수의 알림을 트리거하는 모델로 전환되었습니다.

매트릭의 임곗값 설정도 메인 서비스 한두 개로 운영한다면 계속 운영하면서 조정하면 가능하지만 수십 개 수백 개가 된다면 이마저도 쉽지 않은 일이다.

수동으로 해결해야 하고 런북에 정의할 수 있는 알려진 반복 장애는 더 이상 일반적이지 않습니다. 서비스 장애는 이러한 모델에서 알려진 반복 장애를 자동으로 복구할 수 있는 모델로 전환되었습니다. 자동으로 복구할 수 없어 알림이 트리거되는 장애는 대응하는 엔지니어가 새로운 문제에 직면하게 될 가능성이 높습니다.

최근에 많이 생각하는 일이긴 하다. 장애 대응을 문서로 만들 수 있다면 보통 자동화 처리하는 게 편하고(대표적으로 Kubernetes에서 컨테이너가 죽으면 리스타트하는 걸 들 수 있다) 결국 장애에서 문서화를 한다는 것은 사람이 판단할 수 있는 정보를 넣어야 하는데 이런 걸 결국 문서화가 어렵다. 장애 대응 문서를 그대로 따라 하면 해결이 된다면 굳이 사람이 할 필요가 있는가?

기존 접근 방식의 한계는 무엇보다도 사전 프로덕션 강화에 중점을 둔다는 점입니다. 그런 다음 남은 관심은 생산 시스템에 집중하는 데 투입됩니다. 프로덕션에서 안정적인 서비스를 구축하려면 이러한 순서를 바꿔야 합니다.
최신 시스템에서는 엔지니어링에 대한 관심과 툴링의 대부분을 무엇보다도 프로덕션 시스템에 집중해야 합니다. 남은 관심의 주기는 스테이징 및 사전 프로덕션 시스템에 적용되어야 합니다. 스테이징 시스템에도 가치가 있습니다. 하지만 이는 본질적으로 부차적인 것입니다.
스테이징 시스템은 프로덕션이 아닙니다. 프로덕션에서 일어나는 일을 결코 복제할 수 없습니다. 사전 프로덕션 시스템의 무균 실험실 환경은 실제 유료 서비스 사용자가 실제 환경에서 코드를 테스트하는 것과 동일한 조건을 모방할 수 없습니다. 그런데도 많은 팀이 여전히 프로덕션을 유리성으로 취급합니다.

이건 꽤 급진적인 생각으로 느껴졌는데 생각해 보면 의미 있는 부분인 것 같다. 결국 가장 안전하게 하려면 사전 프로덕션 검증을 강화해야 하고 많은 기법이 여기에 초점이 맞춰져 있지만 시스템이 복잡해질수록 제대로 된 검증하기는 점점 어려워진다. 카오스 엔지니어링이 프로덕션에서 카오스를 만들었고 당시에도 급진적이라고 생각하면서도 멋지다고 생각했는데 아직 경험치가 부족하니 여전히 프로덕션은 좀 무섭게 느껴지는 것 같다. 이런 부분에서 생각의 전환을 할 필요가 있어 보인다.

우리 팀은 회고전을 실행하여 문제를 분석하고, 미래의 우리 자신에게 문제를 처리하는 방법을 알려주는 런북을 작성하고, 다음번에 그 문제를 즉시 드러낼 수 있는 사용자 지정 대시보드(한두 개)를 만든 다음, 문제가 해결된 것으로 간주하고 넘어가곤 했습니다.

이 부분은 자주 하는 행동이라 뜨끔하면서 반성하게 되었다.

저는 소프트웨어 업계에서 영웅 문화의 이러한 측면을 강조하고 싶습니다. 램프 스택 스타일의 모놀리식 시스템에서 최후의 디버거는 일반적으로 시스템을 처음부터 구축한, 가장 오래 근무한 사람이 맡습니다. 가장 연차가 높은 엔지니어가 최후의 에스컬레이션 지점입니다. 이들은 가장 많은 상처 조직과 가장 많은 중단 목록을 가지고 있으며, 필연적으로 문제를 해결하기 위해 뛰어들어야 하는 사람들입니다.
그 결과 이 영웅들은 진정한 휴가를 결코 가질 수 없습니다. 하와이로 신혼여행을 가던 중 새벽 3시에 호출을 받았는데, 몽고DB가 어떻게든 Parse API 서비스를 중단시켰기 때문이었습니다. 제 상사였던 CTO는 정말 미안해했습니다. 하지만 사이트는 다운되어 있었습니다. 한 시간 넘게 다운된 상태였는데 아무도 그 이유를 알아내지 못했습니다. 그래서 저를 호출했습니다. 네, 저는 불평했습니다. 하지만 마음 깊은 곳에서는 은근히 기분이 좋았습니다. 제가 필요했거든요. 제가 필요했으니까요.

2013년 Facebook이 Parse를 인수한 후, 저는 Facebook이 대부분의 실시간 분석에 사용하는 데이터 관리 시스템인 Scuba를 알게 되었습니다. 이 빠르고 확장 가능한 분산형 인메모리 데이터베이스는 초당 수백만 개의 행(이벤트)을 수집합니다. 실시간 데이터를 메모리에 완전히 저장하고 쿼리를 처리할 때 수백 대의 서버에 걸쳐 집계합니다. 제 경험은 거칠었습니다. 저는 Scuba의 사용자 환경이 매우 추악하고 심지어 적대적이라고 생각했습니다. 하지만 시스템 문제 해결에 대한 저의 접근 방식을 완전히 바꿔놓은 한 가지 뛰어난 기능이 있었으니, 바로 무한히 높은 카디널리티의 차원에 대해 거의 실시간으로 데이터를 슬라이스하고 주사위를 던질 수 있게 해준다는 것이었습니다.

Part 2. Fundamentals of Observability

메트릭이란 시스템 상태를 나타내기 위해 수집된 스칼라값을 의미하며, 이러한 숫자를 그룹화하고 검색하기 위해 선택적으로 태그가 추가될 수 있습니다. 메트릭은 소프트웨어 시스템에 대한 전통적인 모니터링의 기반이 되어 왔습니다

메트릭의 근본적인 한계는 사전 집계된 측정값(pre-aggregated measure)이라는 점입니다. 메트릭에 의해 생성된 수치는 미리 정의된 기간의 시스템 상태에 대한 집계된 보고서를 반영합니다.

메트릭은 모두 서로 연결되지 않은 별개의 측정값으로, 동일한 요청에 속하는 메트릭을 정확히 재구성하는 데 필요한 연결 조직과 세분성이 부족합니다.

메트릭은 미리 정의된 기간의 사전 정의된 관계를 종합적으로 수치로 표현한 것으로, 하나의 시스템 속성에 대한 좁은 관점의 하나에 불과합니다. 메트릭의 세부 수준이 너무 높고 시스템 상태를 다른 보기로 표시하는 기능이 너무 경직되어 있어 옵저버빌리티를 달성하기 어렵습니다. 메트릭은 옵저버빌리티의 기본 구성 요소로 사용하기에는 너무 제한적입니다.

옵저버빌리티 도구가 조사자에게 유용하려면 카디널리티가 높은 쿼리를 지원할 수 있어야 합니다. 최신 시스템에서는 새로운 문제를 디버깅하는 데 가장 유용한 많은 차원이 높은 카디널리티를 가지고 있습니다. 또한 깊이 숨겨진 문제를 찾기 위해 이러한 높은 카디널리티 차원을 함께 묶어(즉, 고차원성) 조사해야 하는 경우가 많습니다. 문제를 디버깅하는 것은 종종 건초 더미에서 바늘을 찾는 것과 같습니다. 높은 카디널리티와 고차원성은 매우 복잡한 분산 시스템 건초 더미에서 매우 세밀한 바늘을 찾을 수 있게 해주는 기능입니다.

메트릭의 연결성이 필요하다는 것에는 동의한다. 물론 대부분 높은 카디널리티가 도움 된다는 것에도 동의할 것으로 생각한다. 높은 카니널리티를 담으면 메트릭 서버가 버티지 못해서 그렇지...

분산 트레이싱(distributed tracing)은 애플리케이션을 구성하는 다양한 서비스에서 처리되는 단일 요청(trace라고 함)의 진행 상황을 추적하는 방법입니다. 이러한 의미에서 트레이싱은 "분산"되어 있으며, 그 기능을 수행하기 위해 단일 요청이 프로세스, 머신, 네트워크 경계를 넘나들어야 하는 경우가 많기 때문입니다.

모니터링 및 옵저버빌리티 커뮤니티는 공급업체 종속 문제를 해결하기 위해 수년 동안 여러 오픈 소스 프로젝트를 만들어 왔습니다. 2016년과 2017년에 각각 클라우드 네이티브 컴퓨팅 재단 산하의 OpenTracing과 Google이 후원하는 OpenCensus가 등장했습니다. 이 경쟁적인 개방형 표준은 가장 널리 사용되는 프로그래밍 언어용 라이브러리 세트를 제공하여 원격 분석 데이터를 수집하여 사용자가 선택한 백엔드로 실시간으로 전송할 수 있도록 했습니다. 결국 2019년, 두 그룹이 힘을 합쳐 CNCF 산하의 OpenTelemetry 프로젝트를 결성했습니다.

분산 트레이싱은 알지는 꽤 되었지만 나도 그렇게 제대로 하기는 쉽지 않다. 물론 모든 기술이 그렇듯이 가까이서 기술적인 한계와 현실을 이해할수록 더 어렵게 느껴지긴 한다. OpenTelemetry은 최근에 조금씩 관심을 가지고 있는데 결국 OpenTelemetry로 가긴 하겠지만 긍정적인 미래와 걱정에 대한 생각이 둘다 있긴 하다.

런북을 만드는 데 소요되는 시간이 대부분 낭비된다는 주장은 처음에는 다소 가혹해 보일 수 있습니다. 분명히 말씀드리자면, 특정 서비스의 요구 사항과 그 출발점을 팀에 빠르게 안내하기 위한 문서가 필요합니다.

그러나 가능한 모든 시스템 오류와 해결 방법을 포함하는 살아있는 문서를 유지하는 것은 쓸데없고 위험한 일입니다. 이러한 유형의 문서는 금방 부실해질 수 있으며, 잘못된 문서는 문서가 없는 것보다 더 위험할 수 있습니다. 빠르게 변화하는 시스템에서는 엔지니어의 의도(엔지니어가 이름을 지정하고 수집하기로 한 치수는 무엇인가?)와 프로덕션의 실시간 최신 상태 정보가 결합하여 있기 때문에 계측 자체가 최고의 문서가 되는 경우가 많습니다.

문서에 대한 생각은 꽤 동의하는 편이다.

옵저버빌리티의 진정한 힘은 문제를 디버깅하기 전에 너무 많은 것을 미리 알 필요가 없다는 것입니다. 시스템에 익숙하지 않은 경우에도 체계적이고 과학적으로 한 단계씩 단계를 밟아 단서를 따라 체계적으로 답을 찾을 수 있어야 합니다. 무언의 신호를 유추하거나, 과거의 상처 조직에 의존하거나, 익숙한 기지를 발휘하여 순식간에 올바른 결론에 도달하는 마법은 체계적이고 반복할 수 있으며 검증할 수 있는 프로세스로 대체됩니다.

결국 이 책에서 얘기하는 것은 드릴다운 할 수 있어야 한다는 것이다. 예를 들어 특정 서비스에서 레이턴시가 갑자기 튀기 시작했을 때 메트릭은 그냥 레이턴시 평균이 튀었다는 것만 알려주지만 높은 카디널리티로 다양한 정보를 담아서 모든 메트릭 간에 연결할 수 있어야 한다는 것이다. 그래서 레이턴시가 튀었을 때 클릭해서 더 자세히 들어가서 이게 특정 서버에서 발생하는지, 특정 존에서만 발생하는지, 특정 API에서 발생하는지를 구분해서 볼 수 있어야 문제를 발견할 수 있다는 것인데 동의한다.

그리고 서버의 디스크나 하드웨어 등 시스템은 모니터링으로 파악하고 애플리케이션은 옵저버빌리티로 접근해야 한다는 부분도 수긍되었다.

Part 3. Observability for Teams

이를 위한 가장 좋은 방법은 OpenTelemetry를 사용하여 애플리케이션을 계측하는 것입니다(7장 참조). OTel을 사용하면 다른 공급업체의 독점 에이전트나 라이브러리만큼 빠르고 쉽지는 않지만, 느리고 사용하기 어려운 것도 아닙니다. 처음부터 이 작업을 수행하는 데 필요한 약간의 사전 시간 투자는 나중에 여러 솔루션을 사용해 보고 어떤 솔루션이 가장 적합한지 확인하기로 할 때 큰 도움이 될 것입니다.

이 책은 2022년 6월에 나왔고 지금과 마찬가지로 OpenTelemetry는 아직 초기 단계(내 개인 생각이다.)라고 할 수 있는데 요즘 분위기와 마찬가지로 OpenTelemetry의 미래를 아주 긍정적으로 보고 있고 분산 트레이스에서 OpenTelemetry이 해결책이 될 것으로 보고 계속 OpenTelemetry를 강조하고 있다.

가장 큰 문제점에서 시작하는 것과 마찬가지로, 옵저버빌리티 도구를 직접 구축할지 아니면 상용 솔루션을 구입할지 결정하는 것은 투자 수익률(ROI)을 신속하게 입증하는 것입니다.

새로운 기술을 채택하는 데 있어 큰 장벽 중 하나는 매몰 비용 오류입니다. 개인과 조직은 이전에 투자한 시간, 비용, 노력의 결과로 행동이나 노력을 지속할 때 매몰 비용 오류를 범합니다.

사서 쓰냐? 만들어서 쓰냐는 어려운 부분인데 꽤 여러 관점도 다뤄주어서 좋았다. 물론 모니터링은 간단하지 않으므로 조직이 작을 때는 그냥 사서 쓰고 조직이 커지면서 구축을 고민해야 한다고 생각하긴 한다.

옵저버빌리티는 코드 로직을 디버깅하기 위한 것이 아닙니다. 옵저버빌리티는 시스템에서 디버깅에 필요한 코드를 찾을 수 있는 위치를 파악하기 위한 것입니다. 옵저버빌리티 도구는 문제가 발생할 수 있는 위치를 신속하게 좁혀서 도움을 줍니다.

관찰 가능성 중심 개발을 통해 엔지니어링 팀은 유리 성을 인터랙티브한 놀이터로 바꿀 수 있습니다. 프로덕션 환경은 고정된 것이 아니라 변화무쌍하며, 엔지니어는 어떤 게임에도 자신 있게 뛰어들어 승리를 거둘 수 있는 역량을 갖춰야 합니다. 그러나 옵저버빌리티를 SRE, 인프라 엔지니어 또는 운영팀의 영역으로만 간주하지 않을 때만 가능합니다. 소프트웨어 엔지니어는 옵저버빌리티를 채택하고 개발 관행에 적용하여 프로덕션에 변경을 가하는 것에 대한 두려움의 사이클을 풀어야 합니다.

소프트웨어 업계에서는 일반적으로 속도와 품질 간에 상충 관계가 발생한다는 인식이 있습니다. 즉, 소프트웨어를 빠르게 릴리스하거나 고품질 소프트웨어를 릴리스할 수는 있지만 둘 다 릴리스할 수는 없다는 것입니다. "Accelerate: Building and Scaling High Performing Technology Organizations”의 핵심 내용은 이러한 역관계는 잘못된 상식이라는 것입니다. 우수한 성과를 내는 기업에서는 속도와 품질이 함께 상승하며 서로를 강화합니다. 속도가 빨라지면 장애가 더 작아지고 발생 빈도가 줄어들며, 장애가 발생하더라도 복구하기가 더 쉬워집니다. 반대로 다음과 같은 팀의 경우 느리게 움직이는 팀은 실패가 더 자주 발생하고 복구하는 데 훨씬 더 오래 걸리는 경향이 있습니다.

옵저버빌리티가 해결해야 하는 부분과 옵저버빌리티를 통해서 개발과 운영의 관행도 바꿔줄 수 있다는 부분은 꽤 좋았고 앞으로 옵저버빌리티의 미래에 대해서도 많은 인사이트를 얻을 수 있었다.

CPU 사용률의 변화는 백업 프로세스가 실행 중이거나 가비지 컬렉터가 정리 작업을 수행하거나 시스템에서 다른 현상이 발생할 수도 있는 지표일 수 있습니다. 즉, 이러한 상태들은 우리가 실제로 관심을 가지는 문제뿐만 아니라 시스템의 다양한 요소들을 반영할 수 있습니다. 이러한 측정치를 기반으로 경고를 발생시키면 하드웨어 기반의 단순 측정치로 인해 오류가 발생할 확률이 높아집니다. 이러한 경험이 있는 엔지니어링 팀들은 이러한 유형의 경고를 무시하거나 억제하는 경향이 있으며, "그 경고 걱정하지 마세요; 우리는 이 프로세스가 가끔 메모리가 부족해질 때가 있다는 걸 알고 있습니다."와 같은 문구를 자주 사용합니다.

오류가 발생할 가능성이 높은 경고에 익숙해지는 것은 알려진 문제이자 위험한 관행입니다. 다른 산업에서는 이러한 문제를 "비정상적 허용(Normalization of Deviance)"이라고 합니다.

신뢰성 있는 서비스를 제공하려면 팀은 신뢰성이 떨어지거나 노이즈가 발생하는 경고를 제거해야 합니다. 그러나 많은 팀은 이러한 불필요한 방해를 제거하는 데 두려움을 느낍니다. 이러한 경고를 제거함으로써 서비스 저하에 대해 배우는 방법이 없다는 우려가 종종 우세합니다. 그러나 이러한 전통적인 경고 유형은 알려진 미지수(known-unknowns)만 감지하는 데 도움이 됩니다.

우리는 경고 기준을 두 부분의 하위 집합으로 정의합니다.
첫째, 경고는 서비스의 사용자 경험이 저하된 상태를 신뢰성 있게 반영해야 합니다.
둘째, 경고는 해결할 수 있어야 합니다.
경고에 대응하여 디버깅하고 조치하는 데 체계적인 방법(단순 반복적인 자동화가 아닌)이 있어야 하며, 대응자가 올바른 조치 방법을 추측하지 않아도 되어야 합니다. 이 두 가지 조건이 충족되지 않는다면 구성한 경고는 더 이상 의도한 목적을 달성하지 못하는 것입니다.

전통적인 메트릭 기반의 모니터링 접근 방식은 정적인 임곗값을 사용하여 최적의 시스템 상태를 정의하는 데 의존합니다. 그러나 현대 시스템의 성능은 인프라 수준에서도 서로 다른 워크로드 하에서 동적으로 변할 수 있습니다. 정적인 임곗값은 사용자 경험에 미치는 영향을 모니터링하는 데 적합하지 않습니다.

동의하는 부분이다. 요즘 업무를 하면서도 생각하지만 경고는 상당히 조심스럽게 접근해야 한다고 보는 편이다.(그래서 지금 하고 있는 업무에서도 경고를 아직까지 만들지 못하고 있다.) 경고는 신뢰성 있어야 하고 액션 가능해야 한다. 간단해 보이지만 아주 쉽지 않고 때문에는 알림을 끄는 기능도 필요해 지는데 이 끄는 기능도 결국 많이 꺼지면 신뢰성의 문제가 생겨서 쉽지 않다. 현실 구현을 제외하고 방향성에는 아주 동의한다.

SLOs는 경고의 범위를 사용자들이 서비스를 체험하는 데 영향을 미치는 증상만을 고려하도록 좁힙니다.

"무엇(what)"과 "왜(why)"를 분리하는 것은 최대한 신호를 극대화하고 노이즈를 최소화하는 좋은 모니터링 작성에서 가장 중요한 차이 중 하나입니다.

SLO를 설명하면서 얘기한 부분이 흥미로웠고 스터디에서도 여기서 많은 논의를 했는데 내가 이해한 핵심은 What과 Why를 구분하라는 것이다. 경고를 SLO로만 해야 하는데 이는 What을 알려주라는 것이고 Why는 옵저버빌리티 시스템에 들어와서 파악할 수 있게 제공해야 한다는 것이다.

Slack CI의 주요 과제는 복잡성이었습니다. E2E 테스트의 실패는 코드 베이스, 인프라 및 플랫폼 런타임 변경사항이 복잡하게 상호작용한 결과일 수 있습니다. 2020년에 웹 앱 개발자의 단일 커밋에 대하여, 저희 CI 파이프라인은 30개 이상의 테스트 스위트를 GitHub를 통해 실행합니다. 이 파이프라인은 3개의 플랫폼 팀(퍼포먼스, 백엔드, 프론트엔드)과 20개의 다양한 요구사항과 전문 분야가 있는 팀/서비스에 의해 만들어졌습니다. 2020년 중반에 이르러 CI 인프라가 한계에 도달하기 시작했습니다. 테스트 실행이 월별로 10%씩 증가하면서 테스트 실행을 위해 여러 다운스트림 서비스를 확장하는 데 어려움을 겪었습니다.

Slack의 게스트 챕터가 몇 편 나오는데 CI에서 옵저버빌리티를 사용해서 단계별 성능, 오류 문제를 옵저버빌리티를 사용해서 가시성을 높인 부분이 흥미로웠다. 그동안 옵저버빌리티를 서비스 위주로만 생각해서 이런 식의 적용은 미처 생각해 보지 못했다.

Part 4. Observability at Scale

사람들은 일반적으로 자신의 시간 가격을 고려하는 데 익숙하지 않습니다. 인프라를 가동하고 소프트웨어를 구성하는 데 한 시간이 걸리면 DIY 솔루션은 본질적으로 무료인 것처럼 느껴집니다.

오픈소스를 가져가다 구축할 때 흔히들 하는 실수.

옵저버빌리티는 조직의 경쟁 우위입니다. 자체 옵저버빌리티 솔루션을 구축하면 자체 관행과 문화에 깊이 뿌리내리고 기존 기관의 지식을 활용하는 솔루션을 개발할 수 있습니다. 많은 워크플로우 및 구현과 함께 작동하도록 설계된 일반적인 사전 구축 소프트웨어를 사용하는 대신, 자체 규칙에 따라 비즈니스의 맞춤형 부분과 긴밀하게 통합되도록 솔루션을 사용자 지정할 수 있습니다.

자체 옵저버빌리티 솔루션을 구축하기로 할 때는 조직의 능력과 상용 시스템보다 더 나은 것을 개발할 수 있는 가능성을 모두 현실적으로 고려하는 것이 중요합니다. 조직 전체에서 채택을 장려하는 데 필요한 사용자 인터페이스, 워크플로우 유연성 및 속도를 갖춘 시스템을 제공할 수 있는 조직적 전문성을 갖추고 있습니까? 그렇지 않다면 솔루션의 단점과 해결 방법을 잘 알고 있는 사람들 외에는 널리 채택되지 않는 솔루션에 시간과 비용을 투자하고 비즈니스 기회를 잃게 될 가능성이 높습니다.

상용 솔루션의 또 다른 숨겨진 비용은 시간입니다. 예, 기성 솔루션을 구매하면 가치 실현 시간을 단축할 수 있습니다. 하지만 이 경로를 선택할 때는 벤더 종속이라는 숨겨진 함정에 유의해야 합니다.

옵저버빌리티 도구에 있어 구축 또는 구매라는 선택은 잘못된 이분법입니다. 선택은 단순히 구축 또는 구매로만 제한되지 않습니다. 세 번째 옵션은 구매 후 구축하는 것입니다. 실제로 이 책의 저자는 대부분의 조직에 이 접근 방식을 권장합니다. 내부 기회비용을 최소화하고 조직의 고유한 요구 사항에 맞는 솔루션을 구축할 수 있습니다.

나에게 16장 Efficient Data Storage는 가장 재밌는 부분 중 하나였다. 데이터 스토리지에 대해 많이 생각한 적이 없긴 한데 결국 책에서 얘기하는 높은 카디널리티를 고차원으로 모든 메트릭을 저장하려면 스토리지가 문제가 된다. 앞부분 읽으면서는 이런 마법의 스토리지가 있다고? 하는 느낌으로 읽을 때도 있지만 여기서 현실적으로 어떤 스토리지가 있고 각 스토리지의 장단점, 옵저버빌리티를 하려면 어떤 부분은 잘 되지만 어떤 부분에서 한계가 있는지를 잘 설명해 주고 있다. 결국 하이브리드 형을 제안하긴 하는데 현재의 기술적 상황을 잘 지적해 주었다는 느낌이 들었다.

Part 5. Spreading Observability Culture

옵저버빌리티의 목표는 엔지니어링 팀이 시스템을 개발, 운영, 철저하게 디버그하고 보고할 수 있는 역량을 제공하는 것입니다. 팀은 시스템 동작을 더 잘 이해하기 위해 시스템에 대해 임의의 질문을 함으로써 호기심을 탐구할 수 있는 권한을 부여받아야 합니다. 팀원들이 도구와 경영진의 지원을 통해 능동적으로 시스템을 조사할 수 있도록 인센티브를 제공해야 합니다.

데브옵스 관행이 계속해서 주류로 자리 잡으면서, 미래 지향적인 엔지니어링 리더십 팀은 엔지니어링 팀과 운영팀 사이의 장벽을 제거합니다. 이러한 인위적인 장벽을 제거하면 팀이 소프트웨어 개발과 운영에 대해 더 많은 주인의식을 가질 수 있습니다. 옵저버빌리티는 대기 경험이 부족한 엔지니어가 장애가 발생하는 위치와 장애를 완화하는 방법을 더 잘 이해할 수 있도록 지원하여 소프트웨어 개발과 운영 사이의 인위적인 벽을 허물어뜨립니다.

팀이 옵저버빌리티의 이점을 누리게 되면, 프로덕션의 이해와 운영에 대한 신뢰 수준이 높아질 것입니다. 해결되지 않은 '미스터리' 인시던트의 비율이 줄어들고 조직 전체에서 인시던트를 감지하고 해결하는 데 걸리는 시간이 단축될 것입니다. 그러나 이 시점에서 성공을 측정할 때 자주 저지르는 실수는 탐지된 전체 인시던트 수와 같은 얕은 메트릭에 지나치게 집착하는 것입니다.

옵저버빌리티에 대한 전체적인 생각의 틀을 잡게 해준 좋은 책이라고 생각하고 저자들이 옵저버빌리티에 대해 정말 오래 고민했다는 것도 느낄 수 있었다. 그래서 이 책이 서비스 홍보 책은 아니지만, 또 전혀 아니라고 할 수도 없기에 Honeycomb.io를 한번 써보고 싶다는 생각이 들었다. 가볍게 적용해 볼 옵저버빌리티가 있다면 테스트 삼아 한번 써볼 것 같긴 하다. 물론 개인적으로는 책 초반에 배경 설명이 좀 길고 반복되는 느낌이라서 좀 더 짧은 분량으로도 저자들의 의도를 잘 전달할 수 있지 않았을까 하는 생각도 든다.

댓글 쓰기