에이전트 (Agent) 시대의 가장 기묘한 점은 난제들이 매우 오래된 것처럼 느껴진다는 것입니다.

데모(Demos)는 새로워 보입니다. 모델이 저장소 (Repo)를 읽고, 파일을 수정하고, 풀 리퀘스트 (Pull Request)를 생성하며, 도구 (Tools)를 호출하고, 문서를 검색하고, 명령어를 실행하며, 의심스러울 정도로 자신감 있게 스스로를 설명합니다.

그 부분은 충분히 새롭습니다.

하지만 그 다음 에이전트는 두 번 실행되어야 합니다. 잘못된 것을 기억하지 않으면서 무언가를 기억해야 합니다. 재시도 (Retry)를 해야 하고, 상태 (State)를 유지해야 하며, 권한 (Permissions)을 준수하고, 데이터 유출을 방지하며, 자신이 수행한 일에 대해 진실을 말하고, 인간이 이해할 수 있는 방식으로 실패해야 합니다.

갑자기 우리는 더 이상 프롬프트 엔지니어링 (Prompt Engineering)에 대해 이야기하고 있지 않게 됩니다.

우리는 시스템 (Systems)에 대해 이야기하고 있습니다.

이것이 제가 에이전트 시대를 위한 최고의 독서 목록이 제목에 "AI"가 가득 담긴 책들로 채워진 서가가 아니라고 계속 생각하는 이유입니다. 그중 일부는 유용할 수 있습니다. 하지만 에이전트가 프로덕션 워크플로 (Production Workflows)로 이동할 때 실제로 무엇이 고통을 줄지 이해하고 싶다면, 오래된 시스템 서적들이 여전히 더 나은 지도입니다.

AI 에이전트 스택 (AI agents stack)에 관한 O'Reilly의 최근 글은 이 점을 간접적으로 시사합니다. 흥미로운 부분은 모델 (Models)과 프레임워크 (Frameworks)뿐만이 아닙니다. 그것은 상태 (State), 메모리 (Memory), 오케스트레이션 (Orchestration), 락인 (Lock-in), 마이그레이션 비용 (Migration cost), 그리고 소프트웨어가 더 많은 주도권을 갖기 시작할 때 책임이 어디에 존재하는가라는 고통스러운 질문입니다.

이것은 마법 같은 새로운 학문이라기보다, 소프트웨어 엔지니어링 (Software Engineering)이 이전의 모든 교훈을 한꺼번에 기억해 내는 것에 더 가깝게 들립니다.

프롬프트는 인터페이스이지, 시스템이 아니다

프롬프팅 (Prompting)은 중요합니다. 모호한 지침은 시간을 낭비할 수 있습니다. 좋은 작업 설명, 저장소 지침, 예시, 제약 조건, 그리고 검토 기대치는 실질적인 차이를 만듭니다.

하지만 프롬프트는 인터페이스 (Interface)입니다.

그것은 시스템 전체가 아닙니다.

에이전트가 도구를 호출하고, 파일을 편집하고, 문서를 탐색하고, 테스트를 실행하며, 프로덕션 인접 시스템 (Production-adjacent systems)을 다룰 수 있게 되면, 프롬프트는 더 큰 기계로 들어가는 하나의 입력값이 됩니다. 그 기계에는 아이덴티티 (Identity), 권한 (Permissions), 큐 (Queues), 로그 (Logs), 비용 (Costs), 재시도 (Retries), 도구 카탈로그 (Tool catalogs), 메모리 (Memory), 평가 (Evals), 그리고 인간의 검토 (Human review)도 포함됩니다.

만약 그 기계(machine)가 약하다면, 더 나은 프롬프트(prompt)는 대부분 당신이 실패에 더 빨리 도달하도록 도울 뿐입니다.

이것이 바로 오래된 책들이 계속해서 다시 소환되는 이유입니다.

Designing Data-Intensive Applications는 에이전트(agent)에 관한 책은 아니지만, 에이전트가 우리가 기억해주길 바라는 습관들, 즉 데이터 모델 (data models), 저장소 (storage), 복제 (replication), 일관성 (consistency), 스트림 (streams), 배치 작업 (batch work), 그리고 시스템이 말하는 것과 시스템이 보장할 수 있는 것 사이의 간극을 가르쳐줍니다.

에이전트는 상태 (state)에 대해 매우 확신에 찬 언어를 많이 생성할 것입니다. 엔지니어들은 여전히 상태가 무엇을 의미하는지 알 필요가 있습니다.

그것은 어디에 저장되는가? 누가 소유하는가? 내구성이 있는가 (durable)? 재생 (replay)할 수 있는가? 두 개의 에이전트 세션이 경합 (race)할 수 있는가? 요약본과 데이터베이스가 서로 다를 때 진실의 원천 (source of truth)은 무엇인가?

이것들은 프롬프트 질문이 아닙니다.

이것들은 시스템 질문입니다.

신뢰성 (reliability)은 에이전트 세금이다

만약 에이전트가 텍스트 초안만 작성한다면, 실패는 짜증스러운 일일 뿐입니다.

하지만 에이전트가 풀 리퀘스트 (pull requests)를 열고, 의존성 (dependencies)을 업데이트하며, 인시던트 (incidents)를 분류 (triage)하고, 인프라 (infrastructure)를 변경하거나, 고객 대면 업무를 처리한다면, 실패는 운영 (operational)의 문제가 됩니다.

이 지점에서 SRE 서적들이 고통스러울 정도로 시의적절하게 느껴지기 시작합니다.

Site Reliability Engineering과 The Site Reliability Workbook은 지루하지만 필수적인 개념을 가르칩니다. 신뢰성은 단순히 분위기 (vibe)가 아니라는 점입니다. 신뢰성은 목표 (objectives), 에러 예산 (error budgets), 노고 (toil) 감소, 인시던트 대응 (incident response), 그리고 운영 규율 (operational discipline)을 통해 설계되는 것입니다.

에이전트 플랫폼도 동일한 처우가 필요합니다.

자동화된 마이그레이션 (migration)의 신뢰성 목표는 무엇인가? 얼마나 자주 쓸모없는 풀 리퀘스트를 생성할 수 있는가? 워크플로 (workflow)가 삭제되기 전까지 어느 정도의 검토 노고 (review toil)가 허용 가능한가?

대부분의 팀은 처음에는 이런 질문을 하지 않을 것입니다.

그들은 완료된 작업의 개수만을 셀 것입니다.

그러다 보면 검토 큐 (review queue)가 가득 차고, CI 비용이 이상해지며, 누군가 그럴듯한 실수를 머지 (merge)하게 될 것이고, 팀은 약한 자동화가 오히려 일을 만든다는 사실을 다시 깨닫게 될 것입니다.

SRE 서적들이 유용한 이유는 마법 (magic)에 거부감을 느끼기 때문입니다. 그 책들은 무엇이 '좋은 상태'인지, 그것을 어떻게 알 수 있는지, 그리고 현실이 기대와 다를 때 누가 호출 (paged)되는지를 묻도록 강제합니다.

에이전트에게는 그러한 거부감이 필요합니다.

보안 (security)은 나중에 추가하는 래퍼 (wrapper)가 아니다

에이전트 보안에 대한 논의는 종종 잘못된 사고 모델 (mental model)에서 시작됩니다. 사람들은 마치 에이전트가 단지 정책 교육만 받으면 되는 똑똑한 직원인 것처럼 이야기합니다. 비밀을 유출하지 말라고 말합니다. 위험한 명령을 실행하지 말라고 말합니다. 고객 데이터를 조심해서 다루라고 말합니다.

그것이 약간의 도움이 될 수는 있습니다.

하지만 진정한 보안은 모든 행위자가 현명할 것이라는 점에 의존하지 않습니다. 보안은 실수, 적대적인 입력 (hostile input), 잘못된 기본값 (bad defaults), 그리고 사람들을 편의성 쪽으로 몰아넣는 인센티브를 가정합니다.

이것이 바로 Security Engineering이 여전히 목록에 포함되어야 하는 이유입니다. 위협 모델링 (threat modeling), 접근 제어 (access control), 보안 기본값 (secure defaults), 감사 가능성 (auditability), 그리고 왜 인간이 비참한 시스템을 우회하는지를 가르치는 모든 서적도 마찬가지입니다.

도구 (tool)를 가진 에이전트는 단순한 텍스트 생성기가 아닙니다. 그것은 권한 모델 (permission model) 내부의 행위자 (actor)입니다.

이 저장소 (repository)를 읽을 수 있는가? 네트워크에 접속할 수 있는가? 이 MCP 서버를 호출할 수 있는가? 이 토큰을 볼 수 있는가? 워크스페이스 외부로 쓸 수 있는가? 브랜치를 생성하거나 배포를 트리거할 수 있는가?

이러한 질문들은 더 친절한 시스템 프롬프트 (system prompt)로 해결할 수 있는 것이 아닙니다.

경계 (boundaries)를 통해 해결해야 합니다.

최고의 에이전트 플랫폼은 챗봇이라기보다는 좋은 UX를 갖춘 보안 실행 환경 (secure execution environments)처럼 느껴질 것입니다. 즉, 최소 권한 (least privilege), 단기 자격 증명 (short-lived credentials), 감사 가능한 도구 호출 (auditable tool calls), 범위가 제한된 파일 시스템 (scoped filesystems), 명시적인 네트워크 정책 (explicit network policy), 그리고 정당한 작업을 위한 빠른 경로 (fast paths)를 제공해야 합니다.

다시 말하지만, 이것은 새로운 것이 아닙니다.

새로운 인터페이스를 입은 오래된 보안 공학 (security engineering)일 뿐입니다.

조직은 런타임 (runtime)의 일부이다

가장 과소평가된 에이전트 의존성은 조직도 (org chart)입니다.

에이전트는 소유권 (ownership)을 만들어내지 않습니다. 에이전트는 소유권이 존재하는지를 드러낼 뿐입니다.

코드베이스에 명확한 소유자가 없다면, 에이전트는 여전히 변경을 수행할 수 있습니다. 다만 에이전트는 팀이 그 결과에 대해 신경 쓰게 만들 수는 없습니다. 만약 리뷰 문화가 판단력보다 속도에 보상을 준다면, 에이전트 또한 그 현상을 증폭시킬 것입니다.

이것이 바로 Peopleware, The Mythical Man-Month, Accelerate, Team Topologies, 그리고 The Goal과 같은 책들이 여전히 중요한 이유입니다.

이 책들은 에이전트에 관한 책이 아닙니다.

좋습니다.

이 책들은 에이전트가 투입되는 인간 시스템 (human systems)에 관한 책입니다.

Accelerate는 팀들에게 "더 많은 출력물"보다 더 넓은 의미의 전달 성능 (delivery performance)에 관한 언어를 제공합니다. 배포 빈도 (Deployment frequency), 리드 타임 (lead time), 변경 실패율 (change failure rate), 그리고 복구 시간 (recovery time)은 여전히 에이전트가 생성한 코드 라인 수보다 더 나은 신호입니다.

Team Topologies는 유용합니다. 왜냐하면 에이전트 워크플로우 (agent workflows)에는 소유권 경계 (ownership boundaries)가 필요할 것이기 때문입니다. 플랫폼 팀 (Platform teams)은 잘 닦인 길 (paved roads)을 제공할 것이고, 스트림 정렬 팀 (stream-aligned teams)은 여전히 제품 결과물에 대한 책임을 질 것이며, 복잡한 서브시스템 (subsystems)에는 여전히 전문가가 필요할 것입니다. 에이전트는 이러한 인수인계 (handoffs) 과정을 더 가시적으로 만듭니다.

The Goal은 유용합니다. 모든 에이전트 도입 사례는 결국 병목 현상 (bottleneck) 이야기로 귀결되기 때문입니다.

코드 생성 (code generation)이 빨라지면 리뷰 (review)가 제약 사항이 될 수 있습니다. 리뷰가 개선되면 테스트 환경 (test environments)이 제약 사항이 될 수 있습니다. 테스트가 개선되면 제품 명확화 (product clarification)가 제약 사항이 될 수 있습니다.

핵심은 모든 국소적인 단계 (local step)를 자동화하는 것이 아닙니다.

핵심은 시스템을 개선하는 것입니다.

내가 실제로 팀에게 추천할 리스트

만약 어떤 팀이 진지한 에이전트 워크플로우를 구축하기 전에 무엇을 읽어야 할지 묻는다면, 나는 프롬프트 요리책 (prompt cookbook)부터 시작하지 않을 것입니다. 나는 여기서부터 시작할 것입니다:

• Designing Data-Intensive Applications: 상태 (state), 일관성 (consistency), 스트림 (streams), 그리고 데이터에 대한 겸손함을 위해.
• Site Reliability Engineering: 신뢰성 (reliability)을 제품의 속성으로 다루기 위해.
• Security Engineering: 권한 모델 (permission models)이 정중한 지시 사항보다 더 중요하다는 것을 기억하기 위해.
• Release It!: 운영 환경의 실패 모드 (failure modes), 타임아웃 (timeouts), 그리고 백프레셔 (backpressure)를 위해.
• Accelerate: 가공되지 않은 출력물에 숭배하지 않고 전달 (delivery)을 측정하기 위해.
• Team Topologies: 소유권 (ownership)과 플랫폼 경계 (platform boundaries)를 위해.
• Peopleware: 도구는 망가진 팀을 구원할 수 없다는 불편한 진실을 위해.
• The Goal: 병목 현상 (bottlenecks), 대기열 (queues), 그리고 전체 시스템 개선을 위해.

그다음에 AI 특화 자료를 추가할 것입니다.

에이전트 프레임워크 (agent frameworks), 평가 (evals), MCP, 메모리 아키텍처 (memory architectures), 벤더 문서 (vendor docs), 그리고 논문들에 대해 읽으십시오.

하지만 그것들을 시스템 서가 대신 읽는 것이 아니라, 시스템 서가 위에 쌓아서 읽으십시오.

그렇지 않으면 모든 새로운 에이전트 기능이 새로운 카테고리처럼 보이겠지만, 사실 그 중 상당수는 더 나은 마케팅이 입혀진 오래된 카테고리들입니다.

메모리 (Memory)는 상태 (State)입니다. 도구 사용 (Tool use)은 분산 시스템 (Distributed systems)입니다. 에이전트 자율성 (Agent autonomy)은 권한 (Permission) 문제입니다. 멀티 에이전트 협업 (Multi-agent coordination)은 워크플로우 오케스트레이션 (Workflow orchestration)입니다. 프롬프트 인젝션 (Prompt injection)은 입력 처리 (Input handling)와 보안 (Security)의 결합입니다. 평가 (Evals)는 테스트 (Testing)와 측정 (Measurement)입니다. 컨텍스트 엔지니어링 (Context engineering)은 인터페이스 디자인 (Interface design)과 정보 아키텍처 (Information architecture)의 결합입니다.

이름은 바뀝니다.

하지만 본질적인 작업은 변하지 않습니다.

결론 (the punchline)

에이전트 시대가 된다고 해서 고전적인 소프트웨어 엔지니어링 (Software engineering)의 중요성이 줄어드는 것은 아닙니다.

오히려 그것을 피하기가 더 어려워질 뿐입니다.

코드 생성 (Code generation) 비용이 저렴해질수록, 값비싼 부분들이 더 명확해집니다: 무엇이 존재해야 하는지 결정하는 것, 상태 (State)를 올바르게 유지하는 것, 실패 (Failures)를 읽기 쉽게 만드는 것, 경계 (Boundaries)를 보존하는 것, 큐 (Queues)를 관리하는 것, 그리고 소유권 (Ownership)을 할당하는 것입니다.

이것들은 훌륭한 시스템 서적들이 수십 년 동안 우리에게 가르치려 노력해 온 것들입니다.

그러니 네, 새로운 도구들을 배우십시오.

하지만 실제 운영 환경 (Production)에서 살아남는 에이전트를 구축하고 싶다면, 프롬프트 (Prompts)만을 공부하지 마십시오.

큐 (Queues)를 공부하십시오. 상태 (State)를 공부하십시오. 실패 (Failure)를 공부하십시오. 인센티브 (Incentives)를 공부하십시오. 팀 (Teams)을 공부하십시오. 보안 (Security)을 공부하십시오. 운영 (Operations)을 공부하십시오.

분명히 미래는 에이전트 중심적 (Agentic)입니다.

하지만 그 미래 역시 여전히 시스템 (Systems)으로 이루어져 있습니다.

참고 문헌 (references)

• O'Reilly: The AI Agents Stack (2026 Edition)
• O'Reilly: Signals for 2026

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.