[한영자막] "이걸 선택할 줄 아는 사람이 미래의 엔지니어다" — Addy Osmani

URL: https://www.youtube.com/watch?v=wHePopfD6js 날짜: 2026-08-02 채널: Tech Bridge 원어: 영어 (YouTube 자동 자막 기반 한국어 번역)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI가 코드를 생성·검증·운영하는 능력이 빠르게 향상되는 시대에, ==엔지니어의 미래 가치는 '무엇을 만들지 선택하고, 그 결과에 대해 설명하고 책임질 수 있는 사람'==에 있다.

• Addy Osmani는 미래의 엔지니어를 "무엇이 가치 있는 일인지 선택할 수 있는 사람"으로 정의한다.
• 인공지능 에이전트가 능력(inner loop)을 담당하면, 인간은 증거(evidence), 이해(understanding), 판결(verdict)을 소유해야 한다.
• 단순히 코드를 많이 치는 능력은 희소성이 사라지고 있으며, 판단, 책임성, 설명 가능성이 새로운 희소 자원이 된다.

Addy Osmani는 이 강연에서 하네스 엔지니어링(harness engineering)과 루프 엔지니어링(loop engineering)을 거쳐 소프트웨어 팩토리(software factory)로 진화하는 개발 환경을 설명하고, 이 변화 속에서 엔지니어가 지녀야 할 판단력, 책임성, 그리고 회피해야 할 위험을 구체적으로 제시한다.

---

1. 인간을 루프 안에 남기는 엔지니어링

AI 시대의 엔지니어링은 기술적 구조보다 먼저 인간적 책임 구조를 재정의해야 한다.

1.1. 미래 엔지니어의 새로운 정의

1. '무엇이 가치 있는 일인지 선택하는 사람'

   1. Addy는 미래의 엔지니어가 "what is worth doing(가치 있는 일이 무엇인지)을 선택할 줄 아는 사람"으로 규정된다고 말한다.
   2. 이는 단순한 기술적 역량을 넘어 제품·사용자·비즈니스 맥락에서 우선순위를 결정하는 능력을 의미한다.
   3. 코드 생산량이 폭증할수록 '무엇을 만들 것인가'가 '어떻게 만들 것인가'보다 중요해진다.

2. evidence, understanding, verdict의 소유

   1. 미래 엔지니어는 에이전트가 만든 산출물에 대한 증거를 확보해야 한다.
   2. 단순히 결과를 받아들이는 것이 아니라, 왜 그 결과가 나왔는지 이해해야 한다.
   3. 최종적으로는 "ship할 것인가, block할 것인가, redirect할 것인가, risk를 accept할 것인가"의 판결을 내려야 한다.

1.2. 생산 결정에 대한 책임과 설명 가능성

1. verdict의 실제 의미

   1. Addy는 verdict라는 표현이 "모두가 Judge Judy가 되는 것"을 의미하지 않는다고 농담한다.
   2. 진정한 의미는 생산 결정(production decisions)에 대한 책임(accountability)이다.
   3. 품질은 증거를 만들고, 판결은 책임을 할당하며, 답변 가능성(answerability)은 그 판결에 설 수 있게 한다.

2. 답변 가능성이 엔지니어링 요건이 되는 이유

   1. 과거에는 철학적 개념처럼 여겨졌지만, AI 생성 코드가 일상화되면서 답변 가능성은 필수 엔지니어링 요건이 된다.
   2. "어떤 모델이 이 파일을 수정했는가", "어떤 제약이 작업을 이끌었는가", "어떤 증거가 생성되었는가", "누가 결과를 소유하는가" 같은 질문이 공식화되어야 한다.

1.3. 직무 경계의 재편과 시스템 소유

1. Boris Cherney의 직무 재편 언어

   1. Addy는 Boris Cherney가 제시한 개념을 인용하며, 기존 직무 경계가 흐려지고 있다고 설명한다.
   2. 역할들이 '일 자체'를 중심으로 재묶이고(re-bundling) 있다.
   3. 중요한 질문은 "너의 직함이 무엇이냐"가 아니라 "시스템의 어느 부분을 소유할 수 있느냐"가 된다.

2. 5가지 엔지니어링 모드

   1. Addy는 prototype, build, sweep, grow, maintain이라는 다섯 가지 엔지니어링 모드를 긍정적으로 평가한다.
   2. 이 다섯 모드는 낙관적이면서도 모호하지 않은 실질적 활동 단위다.
   3. 에이전트는 이 모든 모드를 돕겠지만, 희소한 것은 '작업 수행'이 아니라 '제품이 어떤 모드가 필요한지, 어떤 품질 기준이 적용되는지, 최종 책임은 누구에게 있는지 아는 것'이다.

---

2. 하네스 엔지니어링에서 루프 엔지니어링, 그리고 소프트웨어 팩토리로

AI 개발의 패러다임은 단일 모델 프롬프팅을 넘어 하네스·루프·팩토리라는 구조로 확장되었다.

2.1. 하네스 엔지니어링: 지능을 위임 가능한 형태로 전환

1. 모델만으로는 부족하다

   1. Addy는 "모델이 전부가 아니다"라고 강조한다.
   2. 코딩 에이전트는 모델 자체보다는 모델 주위의 하네스(harness)이다.
   3. 하네스는 컨텍스트, 도구, 파일 시스템, Git 등을 포함한다.

2. 하네스의 핵심 역할

   1. 하네스는 '지능(intelligence)'을 '위임할 수 있는 형태'로 전환하는 장치다.
   2. 모델이 언제든 무엇이든 생성할 수 있지만, 하네스 없이는 제품에 통합하거나 신뢰할 수 없다.
   3. 따라서 엔지니어는 모델을 감싸는 구조를 설계하는 능력을 길러야 한다.

2.2. 루프 엔지니어링: 지속적인 프롬프트-검증-기억-결정

1. 한 번의 프롬프트를 넘어선 설계

   1. 루프 엔지니어링은 단일 실행이 아니라 지속적으로 프롬프트하고, 검증하고, 기억하고, 다음을 결정하는 시스템을 설계하는 것이다.
   2. 이 구조에서 에이전트는 인프라처럼 느껴지기 시작한다.
   3. Addy는 이 루프가 "에이전트가 인프라처럼 느껴지기 시작한 순간"이라고 표현한다.

2. 루프의 산출물과 인간의 위치

   1. 루프 안에서는 에이전트가 내부 루프(inner loop)에서 실행되고 증거(evidence)가 나온다.
   2. 인간은 여전히 생산 결정(production decisions)을 내리는 주체로 남는다.
   3. 목표는 인간을 루프에서 밀어내는 것이 아니라, 인간의 판단을 가장 영향력 높은 체크포인트로 이동시키는 것이다.

2.3. 소프트웨어 팩토리의 등장

1. 팩토리의 의미

   1. 하네스와 루프를 결합하면 '소프트웨어 팩토리'가 만들어진다.
   2. Dex의 강연을 인용하며, 이 구조가 이미 구체적으로 논의되고 있음을 언급한다.
   3. 팩토리는 에이전트를 지속적으로 운영할 수 있는 생산 체계다.

2. 팩토리에서의 승리 조건

   1. 승리 조건은 '에이전트가 인간을 대체하는 것'이 아니다.
   2. 인간의 판단(human judgment)을 가장 높은 레버리지 체크포인트로 옮기는 것이다.
   3. 즉, 에이전트가 실행을 담당하고, 인간은 결정과 책임을 담당한다.

---

3. 검증의 병목과 답변 가능성의 부재

AI 생성 코드가 일상화되면서 코드 생성 비용은 떨어지지만, 검증과 거버넌스는 새로운 병목이 되고 있다.

3.1. AI 보조 코드가 '보통의 코드'가 되는 시점

1. Sonar 2026 설문의 시사점

   1. Addy는 Sonar의 2026년 설문을 인용하며 AI-assisted code가 더 이 marginal(주변적)이 아니라고 말한다.
   2. AI 보조 코드는 점점 코드베이스에서 큰 역할을 하고 있다.
   3. 이 지점을 지나면 답변 가능성(answerability)은 철학이 아닌 엔지니어링 요구사항이 된다.

2. AI 코드에 대한 보편적 회의

   1. Sonar의 연구에 따르면 거의 모든 엔지니어가 AI 코드에 대해 의심한다.
   2. 하지만 실제로 커밋 전 항상 검증하는 사람은 약 절반에 불과하다.
   3. 이는 '신뢰 부족(distrust)'과 '검증 대역폭 부족'이 공존하는 위험한 상태다.

3.2. 클린 코드의 재정의: 다음 인간을 넘어 다음 에이전트를 위한 코드

1. 클린 코드의 새로운 수혜자

   1. 과거 클린 코드는 '사람이 읽을 수 있는 코드'를 의미했다.
   2. 이제는 '다음 사람'뿐 아니라 '다음 에이전트'도 수혜자가 된다.
   3. 정리된 코드는 에이전트가 더 적은 토큰으로 더 적은 재시도(revisit)를 하게 만든다.

2. Sonar 연구의 구체적 결과

   1. 깔끔한 저장소와 지저분한 저장소의 통과율(pass rate)은 비슷했다.
   2. 그러나 깔끔한 코드가 더 적은 토큰을 사용하고 재방문 횟수가 적었다.
   3. 이는 유지보수성이 곧 팩토리의 효율성이며 비용 절감으로 직결됨을 보여준다.

3.3. 검증이 병목이 되는 조직적 이유

1. 생성 저렴화 ≠ 검증 저렴화

   1. Addy는 "생성을 저렴하게 만드는 것이 검토를 저렴하게 만들지는 않는다"고 강조한다.
   2. 코드 생성 비용이 낮아질수록 검토 대상의 양은 폭증한다.
   3. 결과적으로 검증(review)과 검증(validation)이 조직적 병목이 된다.

2. 거버넌스의 속도 차이

   1. AI 도입 속도는 기업이 정책을 세울 수 있는 속도보다 훨씬 빠르다.
   2. 거버넌스가 따라잡지 못하면 리뷰와 검증이 제약이 된다.
   3. 안전은 검증을 더 저렴하게, 더 명확하게, 더 건너뛰기 어렵게 만드는 데서 나온다.

3.4. 조직이 스스로에게 던져야 할 어려운 질문들

1. 모델의 개입 추적

   1. "이 파일을 실제로 모델이 만졌는가?"
   2. "어떤 제약이 작업을 안내했는가?"
   3. "어떤 증거가 생산되었는가?"

2. 책임의 소재

   1. "어떤 위험이 수용되었는가?"
   2. "누가 결과를 소유하는가?"
   3. 이런 질문들이 기술적 선택을 넘어 조직적 책임 구조의 핵심이 된다.

---

4. 알파와 감소: 어떤 능력이 오래갈까

모든 개인적 우위(alpha)는 모델 발전에 따라 감소(decay)하지만, 그 반감기는 능력에 따라 다르다.

4.1. 알파와 감소의 정의

1. alpha(알파)

   1. alpha는 "오늘 당신이 할 수 있는 것"과 "현재 모델이 할 수 있는 것" 사이의 차이다.
   2. 이 간극이 당신의 현재 경쟁 우위다.
   3. 그러나 모델이 발전하면서 이 간극은 지속적으로 줄어든다.

2. decay(감소)

   1. decay는 그 알파에 달린 시계다.
   2. 만약 당신을 특별하게 만드는 것이 '능력(capability)'이라면, 결국 프론티어가 그것을 따라잡을 것이다.
   3. 따라서 단일 능력에 의존하는 전략은 장기적으로 불안정하다.

4.2. 테이스트(taste)의 재정의

1. Paul Graham의 시각

   1. Paul Graham은 "누구나 무엇이든 만들 수 있게 되면, 무엇을 만들지 선택하는 것이 매우 중요해진다"고 했다.
   2. Addy는 이 주장에 동의하지만, '테이스트'가 설명되지 않는 영역을 가리키는 마법 같은 단어가 되어서는 안 된다고 경고한다.

2. Mitchell Hashimoto의 실용적 정의

   1. Mitchell Hashimoto는 테이스트를 "아직 객관적 지표가 없는 상황에서 고품질의 질적 판단을 내리는 능력"으로 정의했다.
   2. 이 정의가 중요한 이유는 테이스트가 벤치마크보다 앞서고, 시장이 완전히 평가하기 전에 작동하기 때문이다.
   3. 모델의 UX와 경험을 볼 때 종종 '테이스트가 있는지 없는지' 직감적으로 알 수 있다.

3. 테이스트의 한계

   1. 테이스트도 알파이며 감소한다.
   2. 모델이 예시와 선호도로부터 학습하면서 테이스트의 반감기는 길지만 영원하지 않다.
   3. 따라서 테이스트를 신비화하지 말고, 비평(critique), 예시, 더 나은 판단으로 구체화해야 한다.

4.3. 능력들의 감소 속도

1. 속도(speed)

   1. 에이전트는 이미 인간보다 빠르게 코드를 생성할 수 있다.
   2. 따라서 '빠르게 코딩하기'라는 알파는 이미 감소했다.

2. 기억(recall)과 검증(verification)

   1. 하네스는 메모리를 가지고 있으며, 검증은 evals, static checks, model critique 등으로 이동하고 있다.
   2. 이런 능력들도 점차 자동화의 영역으로 편입된다.

3. 테이스트(taste)

   1. 테이스트는 상대적으로 천천히 감소하지만, 모델이 예시와 선호도에서 학습하면 재설정된다.
   2. 심지어 판단(judgment)조차도 완벽한 장벽이 아니라 경사면(slope)이다.

4. 전략적 함의

   1. 어떤 한 가지 능력에 매달리는 것이 아니라, 능력의 수준을 한 단계 높여 지속적으로 이동해야 한다.
   2. 더 이상 "에이전트가 무엇을 할 수 없는가"가 아니라 "무엇이 오직 인간만이 답변할 수 있는가"를 묻는 것이 더 나은 전략적 질문이다.

---

5. 엔지니어가 피해야 할 세 가지 위험

AI 활용이 확대되면서 엔지니어와 조직이 빠지기 쉬운 세 가지 함정이 있다.

5.1. 인지 부채(Cognitive Debt)

1. 정의와 발생 원인

   1. cognitive debt는 문제 해결에 대한 이해와 기억이 서서히 마모되는 상태다.
   2. 매일 에이전트에 더 많이 의존할수록, 우리는 점점 문제 해결 과정에서 멀어진다.
   3. Addy는 자신도 이것을 많이 느낀다고 고백한다.

2. 위임 부채(Delegation Debt)

   1. 빌드는 통과하고 테스트도 통과하며 PR도 머지될 수 있다.
   2. 하지만 팀은 실제로 운영 환경에 배포하는 시스템을 설명하는 능력을 잃을 수 있다.
   3. 저장소에 존재하는 코드 양과 팀이 진정으로 이해하는 코드 양 사이의 간극이 위험이다.

3. 장기 실행의 위험

   1. 에이전트가 시스템 안에서 장시간(1시간, 하루 단위) 머무를 수 있다.
   2. 30초 실행은 상호작용처럼 느껴지지만, 긴 호라이즌 작업은 하나의 업무 흐름(work stream)이다.
   3. 병렬로 많은 에이전트를 실행할 때 리뷰는 단순히 끝에 훑어보는 것이 아니라 전체 제어 시스템이 되어야 한다.

5.2. 인지 항복(Cognitive Surrender)

1. 위임과 항복의 차이

   1. 위임(delegation)은 "일을 하고, 내가 판단할 수 있을 만큼의 증거를 보여달라"는 것이다.
   2. 항복(surrender)은 "네 답이 내 답이 되기 전에 내 의견을 형성하지 않는 것"이다.
   3. 위임에는 여전히 인간의 판단이 포함되지만, 항복에는 없다.

2. Wharton 연구의 경고

   1. Wharton의 연구에 따르면 AI가 틀렸을 때 73%의 사람이 여전히 자신이 틀린 답을 선택했다.
   2. 더군다나 그들은 더 확신에 찬 느낌을 받았다.
   3. 이는 AI 사용 자체가 아니라 '빌린 자신감(borrowed confidence)'이라는 실패 모드를 보여준다.

5.3. 오케스트레이션 세금(Orchestration Tax)

1. 에이전트 수 ≠ 인지 대역폭

   1. 실리콘밸리에서는 수백, 수천 개의 에이전트를 운영한다고 자랑하는 분위기가 있다.
   2. 하지만 더 많은 에이전트가 실행된다고 해서 당신의 인지 대역폭이 늘어나는 것은 아니다.
   3. 인지 대역폭은 병렬화되지 않는다.

2. 주의력 시스템 설계

   1. 모든 루프는 결정(route), 병합(merge), 검증(verify), 통합(integrate)의 추가 결정을 만든다.
   2. 해결책은 단순히 에이전트를 줄이는 것이 아니라 주의력을 시스템처럼 설계하는 것이다.
   3. 어디에 개입하고, 무엇을 요구하고, 무엇을 재사용할지 의도적으로 설계해야 한다.

---

6. 책임성과 에이전시(Agency)의 운영 모델

AI가 실행 능력을 대체할수록 인간의 차별점은 책임성(accountability)과 에이전시(agency)에서 나온다.

6.1. 책임성이 시스템을 확장시키는 메커니즘

1. 책임성의 본짠

   1. Addy는 책임성이 "에이전트가 능숙해진 후에 남는 것"이 아니라 "나머지 시스템을 확장시키는 것"이라고 말한다.
   2. 에이전트가 더 많은 일을 더 빠르게 할수록, 설명, 증거 검토, 위험 수용, 잘못된 결정 개선 능력이 희소해진다.

2. signature와 신뢰의 반감기

   1. 개별적인 우위(edge)의 반감기는 한 번의 모델 릴리스일 수 있다.
   2. 하지만 signature—즉 작품에 붙는 이름, 개인, 팀, 기관의 신뢰—는 훨씬 오래간다.
   3. 기술은 레버리지를 얻게 해주고, 책임성은 그 레버리지를 신뢰로 전환한다.

6.2. 능력(inner loop)과 에이전시(outer loop)의 경계

1. 에이전트의 실행 영역

   1. 에이전트는 investigate, implement, test, report까지 내부 실행 루프를 돌 수 있다.
   2. 이는 분명한 레버리지를 제공한다.

2. 인간의 외부 루프

   1. 그러나 외부 루프—deciding, verifying, approving, owning—는 여전히 엔지니어링이다.
   2. 내부 루프는 능력(capability)이고, 외부 루프는 에이전시(agency)다.
   3. Addy는 이 경계를 매우 중요하게 여긴다.

3. 실행과 책임의 분리

   1. 에이전트는 선택, 라우팅, 병합, 에스컬레이션, 정책 내 운영까지 할 수 있다.
   2. 하지만 실행(execution)과 책임(responsibility)은 다르다.
   3. 에이전트는 런북을 따를 수 있지만, 그 결과를 물려받을 수는 없다.

6.3. 에이전시 사다리(Agency Ladder)

1. 하단: 문제 지적

   1. 가장 낮은 단계는 문제를 표시하고 시스템에 맡기는 것이다.
   2. 이는 행동이지만 책임은 아니다.

2. 중간: 실행부터 해결까지

   1. 그 위로는 execute(실행), diagnose(진단), propose(제안), recommend(권고), resolve(해결)의 단계가 있다.
   2. 이 단계들은 점점 더 많은 소유권을 요구한다.

3. 최상단: 분별(discernment)

   1. 가장 높은 움직임은 분별이다.
   2. 문제를 찾고 그것에 투자할 가치가 있는지 결정하는 것이다.
   3. 때로는 투자하지 않고 넘어가는 것도 분별의 일부다.
   4. 에이전트가 가능한 경로를 늘리면, 에이전시는 모든 경로를 쫓는 것이 아니라 어떤 경로에 주의와 소유권을 투자할지 결정하는 것이다.

6.4. 운영 규칙: "Explain it or don't ship it"

1. 규칙의 의미

   1. Addy는 "설명할 수 없으면 배포하지 말라"는 운영 규칙을 제시한다.
   2. 이는 인간이 모든 줄을 직접 쳐야 한다거나 읽어야 한다는 의미가 아니다.
   3. 누군가는 그 작업을 충분히 이해하여 방어할 수 있어야 한다는 의미다.

2. OWNERS 파일과의 유사성

   1. 대형 코드베이스의 OWNERS 파일처럼 특정 서브디렉토리에 책임자를 두는 개념을 생각할 수 있다.
   2. 아키텍처의 어느 부분에 누가 책임지는가를 명확히 해야 한다.
   3. 모델이 코드를 쓰더라도, 그 변경사항을 설명할 수 있는지, 리스크를 이해하고 있는지가 핵심이다.

---

7. 결론 및 시사점

AI는 코드 생산의 바닥을 높이고, 엔지니어링은 그 위로 한 단계 이동한다.

7.1. 역사적 패턴의 반복

1. 기술 발전과 수요의 확대

   1. Addy는 소프트웨어 작성이 쉬워질 때마다 사람들이 "소프트웨어가 덜 필요할 것"이라고 예측했지만 정반대가 일어났다고 말한다.
   2. 고수준 언어, 프레임워크, 클라우드, 로우코드 모두 같은 패턴을 따랐다.
   3. 비용을 낮추면 잠재 수요(latent demand)가 나타난다.

2. 에이전트가 잠재 수요를 해금할 것

   1. 에이전트도 마찬가지로 사람들이 실행 가능하다고 생각하지 못했던 아이디어들을 실현시킬 것이다.
   2. 이는 엔지니어링 일자리를 없애는 것이 아니라 병목을 '만들 수 있는가'에서 '존재해야 하는가, 그리고 그에 답변할 수 있는가'로 옮긴다.

7.2. 미래 엔지니어의 실제 업무

1. 새로운 핵심 영역

   1. 루프 설계(loop design)
   2. 증거 설계(evidence design)
   3. 브라운필드 관리(brownfield stewardship)

2. 줄어드는 것과 늘어나는 것

   1. 키 입력 수는 줄어들 수 있다.
   2. 하지만 테이스트, 검증, 소유권, 관리(care)가 필요한 표면적(surface area)은 오히려 늘어난다.

7.3. Addy의 최종 메시지

1. 두 가지 지시

   1. "팩토리를 만들어라(build the factories)."
   2. "판결의 불을 켜 두어라(keep the lights on on the verdict)."
   3. 즉, 자동화된 생산 체계를 구축하되, 최종 결정과 책임에 대한 인간적 통제는 유지하라.

2. 낙관적 마무리

   1. Addy는 이 분야의 미래에 대해 그 어느 때보다 흥분돼 있다고 말한다.
   2. 그는 기술이 발전할수록 엔지니어링의 범위와 영향력이 확장될 것이라고 믿는다.

---

주요 발언 모음

"I think that the engineer of the future is going to be really defined by the person who is able to choose what is worth doing." — 미래의 엔지니어는 무엇이 가치 있는 일인지 선택할 수 있는 사람으로 규정될 것이다.

"Quality is something that we all talk about a lot, but quality produces evidence. A verdict assigns responsibility." — 우리는 품질을 많이 이야기하지만, 품질은 증거를 만들고, 판결은 책임을 할당한다.

"Making generation cheaper does not automatically make review cheaper." — 생성을 저렴하게 만드는 것이 자동으로 검토를 저렴하게 만들지는 않는다.

"Taste is the ability to make high-quality qualitative judgments where no objective metric exists yet." — 테이스트는 아직 객관적 지표가 없는 상황에서 고품질의 질적 판단을 내리는 능력이다.

"Explain it or don't ship it." — 설명할 수 없으면 배포하지 말라.

"Build the factories, keep the lights on on the verdict." — 팩토리를 만들되, 판결의 불을 켜 두어라.

---

핵심 데이터 & 수치

• Sonar 2026 설문: AI-assisted code가 더 이상 marginal이 아니며, 코드베이스에서 점점 큰 역할을 하고 있다.
• AI 코드에 대한 신뢰: 96%가 AI 코드를 완전히 신뢰하지 않는다.
• 커밋 전 검증률: AI 코드를 완전히 신뢰하지 않는 96% 가운데 커밋 전 항상 검증하는 사람은 약 절반에 불과하다.
• Wharton 연구: AI가 틀린 답을 제시했을 때, 73%가 여전히 그 틀린 답을 선택했고 더 확신에 찬 느낌을 받았다.
• 깔끔한 코드 vs 지저분한 코드: 통과율은 비슷했으나, 깔끔한 코드가 더 적은 토큰과 더 적은 재방문(revisit)을 필요로 했다.

---

결론 및 시사점

1. AI 에이전트는 코드 생성과 실행을 대체하지만, 최종 책임과 판단은 인간에게 남는다.
2. 미래 엔지니어의 가치는 '할 수 있는 것'이 아니라 '해야 하는 것을 선택하고 설명할 수 있는 것'에 있다.
3. cognitive debt, cognitive surrender, orchestration tax를 피하기 위해 의도적이고 시스템적인 주의력 관리가 필요하다.
4. 개별 능력은 빠르게 감소하지만, 신뢰와 책임성으로 구성된 signature는 오래간다.
5. 기술 발전은 엔지니어링 수요를 줄이지 않고, 오히려 새로운 설계 영역—loop design, evidence design, brownfield stewardship—을 확장한다.