라이브러리를 구축하기 위해 읽지 마세요. 문제를 해결하기 위해 읽으세요.

대부분의 엔지니어링 독서 목록은 지식 축적에 최적화되어 있습니다.

현대의 엔지니어링은 병목 현상 제거 (bottleneck elimination)에 보상을 줍니다.

지난주, 한 주니어 엔지니어가 저에게 "모든 엔지니어가 읽어야 할 도서 Top 10" 목록을 보여주었습니다. 그것은 제가 10년 전에 보았던 목록들과 거의 동일해 보였습니다.

똑같은 고전들.

똑같은 프로세스 관련 서적들.

똑같은 가정:

책을 충분히 읽으면 더 나은 엔지니어가 될 것이다.

대부분의 고성과 팀들이 학습하는 방식은 그렇지 않습니다.

제가 아는 최고의 엔지니어들은 책을 중심으로 학습 계획을 세우지 않습니다.

그들은 제약 사항 (constraints)을 중심으로 학습 계획을 세웁니다.

표준적인 독서 목록의 문제점

대부분의 독서 목록은 지식이 보편적으로 가치 있다고 가정합니다.

실제로 엔지니어링의 가치는 매우 맥락적 (contextual)입니다.

데이터베이스 경합 (database contention)으로 고군분투하는 백엔드 엔지니어에게는 Agile에 관한 또 다른 장이 필요하지 않습니다.

LLM 추론 (inference)에 매달 수천 달러를 지출하는 팀에게는 일반적인 소프트웨어 공예 (software craftsmanship) 서적이 필요하지 않습니다.

지연 시간 (latency) 문제와 싸우는 스타트업에게는 리더십 프레임워크가 필요하지 않습니다.

그들에게 필요한 것은 바로 눈앞에 있는 병목 현상에 대한 해결책입니다.

독서 목록은 이러한 점을 거의 고려하지 않습니다.

그것들은 완결성을 위해 최적화되어 있습니다.

엔지니어링은 관련성 (relevance)에 보상을 줍니다.

대부분의 엔지니어가 놓치는 변화

기초 (fundamentals)는 여전히 중요합니다.

분산 시스템 (Distributed systems)은 중요합니다.

데이터베이스 (Databases)는 중요합니다.

네트워킹 (Networking)은 중요합니다.

운영 체제 (Operating systems)는 중요합니다.

그것들은 구식이 아닙니다.

하지만 그것들만으로는 더 이상 충분하지 않습니다.

현대적인 시스템은 불과 몇 년 전에는 거의 존재하지 않았던 제약 사항들을 도입합니다:

AI 추론 비용 (AI inference costs)
컨텍스트 윈도우 제한 (Context window limitations)
에이전트 오케스트레이션 (Agent orchestration)
평가 파이프라인 (Evaluation pipelines)
시맨틱 캐싱 (Semantic caching)
비결정론적 워크플로우 (Non-deterministic workflows)
모델 라우팅 (Model routing)
인간 참여형 시스템 (Human-in-the-loop systems)

많은 전통적인 독서 목록은 이러한 문제들을 전혀 다루지 않습니다.

하지만 이것들이 바로 팀들이 매일 해결하고 있는 문제들입니다.

과제는 더 이상 단순히 올바른 소프트웨어를 작성하는 것이 아닙니다.

과제는 본질적으로 확률론적인 (probabilistic) 구성 요소들 위에 신뢰할 수 있는 시스템을 구축하는 것입니다.

무엇이 변했는가

수십 년 동안 엔지니어들은 주로 결정론적 (deterministic) 시스템을 다루어 왔습니다.

동일한 입력이 주어지면, 동일한 코드는 동일한 출력을 생성했습니다.

오늘날 많은 프로덕션 (production) 시스템은 다르게 동작하는 구성 요소들을 포함하고 있습니다.

프롬프트 (prompt)는 서로 다른 응답을 생성할 수 있습니다.

에이전트 (agent)는 서로 다른 실행 경로를 선택할 수 있습니다.

모델 업그레이드는 애플리케이션 코드를 변경하지 않고도 동작을 변화시킬 수 있습니다.

아키텍처 (architecture) 측면의 과제들이 달라집니다:

품질을 어떻게 평가할 것인가?
신뢰성을 어떻게 측정할 것인가?
장애를 어떻게 관찰 (observe)할 것인가?
비용을 어떻게 제어할 것인가?
확률론적 (probabilistic) 동작을 어떻게 디버깅 (debug)할 것인가?

이것들은 더 이상 예외적인 케이스 (edge cases)가 아닙니다.

이것들은 일상적인 엔지니어링의 일부가 되어가고 있습니다.

완독이 아니라 메커니즘 (mechanisms)을 위해 읽으세요

대부분의 엔지니어들은 처음부터 끝까지 다 읽습니다.

가장 강력한 엔지니어들은 메커니즘을 위해 읽습니다.

병목 현상 (bottleneck)에 직면했을 때, 그들은 근저에 있는 메커니즘을 식별하고 정확히 무엇이 필요한지를 학습합니다.

지연 시간 (latency)이 문제가 된다면:

배칭 (batching)을 공부하세요.
캐싱 (caching)을 공부하세요.
비동기 실행 (asynchronous execution)을 공부하세요.

컨텍스트 (context)가 문제가 된다면:

검색 (retrieval)을 공부하세요.
청킹 (chunking)을 공부하세요.
메모리 아키텍처 (memory architectures)를 공부하세요.

에이전트 (agents)가 신뢰할 수 없게 된다면:

평가 (evaluation)를 공부하세요.
상태 관리 (state management)를 공부하세요.
워크플로우 오케스트레이션 (workflow orchestration)을 공부하세요.

학습은 프로덕션 결과와 직접적으로 연결됩니다.

지식은 즉시 레버리지 (leverage)로 전환됩니다.

실제로 확장 가능한 학습 루프 (Learning Loop)

제가 관찰한 가장 효과적인 학습 루프는 간단합니다:

병목 현상을 식별합니다.
그 뒤에 있는 메커니즘을 찾습니다.
필요한 것만 공부합니다.
즉시 적용합니다.
결과를 측정합니다.
반복합니다.

이 접근 방식은 단순히 완독을 목적으로 책을 소비하는 것보다 훨씬 빠르게 복리로 성장합니다.

목표는 읽기 목록을 끝내는 것이 아니기 때문입니다.

목표는 시스템을 개선하는 것입니다.

실전 테스트

다음 책을 시작하기 전에, 다른 질문을 던져보세요:

내 현재 시스템에서 가장 큰 제약 사항은 무엇인가?

지연 시간 (latency)?

비용 (cost)?

신뢰성 (reliability)?

관찰 가능성 (observability)?

평가 (evaluation)?

이제 그 특정 문제를 해결하기 위한 최고의 리소스를 찾으세요.

가장 인기 있는 리소스가 아닙니다.

모두가 추천하는 리소스도 아닙니다.

병목 현상 (bottleneck)을 직접적으로 타격하는 리소스입니다.

엔지니어링은 독서 경연 대회가 아니기 때문입니다.

그것은 제약 조건 해결 (constraint-solving) 전문직입니다.

시스템이 당신이 다음에 무엇을 배울지 결정해야 합니다.

목록이 아니라 말입니다.