Stop being skeptical about AI for development with Charity Majors

URL: https://www.youtube.com/watch?v=HC8T1OlgYi0
날짜: 2026-08-13
채널: t3chfeed
출연: Charity Majors(Honeycomb 공동 창업자·CEO, 전 Facebook·Parse 엔지니어) / Gergely Orosz(The Pragmatic Engineer)

---

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

==AI가 작성한 코드를 사람이 읽지 않고도 운영 환경에 배포할 수 있는가? 이 질문은 ‘가능한가’가 아니라 ‘어떤 검증·평가·관측성·책임 체계를 갖추면 언제 가능한가’로 바뀌고 있다.==

• AI를 둘러싼 낙관론자와 회의론자는 각자 실제 현상을 보고 있다. 전자는 개발 속도·자동화의 이득을, 후자는 운영 장애·슬롭(slop)·신뢰성 하락을 직접 겪는다.
• 코드를 생성하는 비용은 급락하지만, 신뢰를 만드는 비용은 테스트(test), 평가(eval), 관측성(observability), 가드레일(guardrail)로 이동한다.
• 소프트웨어는 논리와 언어로 이루어져 있고 컴파일·테스트·실행이라는 검증 장치가 있어 AI의 가장 적합한 영역일 가능성이 크다. 그러나 AI를 마법으로 취급하면 기존의 엔지니어링 기반을 훼손한다.
• 개인 생산성보다 팀의 결과와 고객의 실제 경험을 측정해야 하며, AI가 사람의 책임과 존중을 대체하지 않는다는 원칙이 필요하다.

이 대화의 결론은 AI를 거부하거나 무조건 숭배하라는 것이 아니다. AI를 일반적인 기술로 만들고(“make AI boring again”), 비결정적(non-deterministic) 생성 과정에서 빼앗긴 신뢰를 결정적 테스트와 운영 데이터로 다시 쌓으며, 변화가 두려운 사람도 직접 실험해 주도권(agency)을 되찾으라는 것이다.

1. 도입: AI 이전에도 존재했던 ‘개발자 생산성’의 함정

1.1. 2020년의 질문과 2026년의 재등장

1. 개별 엔지니어 생산성을 측정할 수 있는가

   1. Charity와 Gergely는 AI가 등장하기 전인 2020년, 각자의 블로그에서 “엔지니어 한 명의 생산성을 측정할 수 있는가?”라는 질문에 답한 적이 있다.
   2. 두 사람의 공통된 결론은 일부 차원(dimension)은 측정할 수 있지만, 지표 하나로 전체 기여를 설명할 수 없다는 것이다. 팀의 핵심 연결자나 멘토 역할처럼 개인 산출물에 나타나지 않는 기여가 있기 때문이다.
   3. 좋은 매니저나 팀 리드는 데이터로 판단을 보완하되, 실제 맥락과 사람을 세부적으로 알아야 한다. 측정값이 있다고 해서 판단 책임을 지표에 떠넘길 수는 없다.

2. AI 시대에 같은 질문이 더 위험해진 이유

   1. AI 도구가 코드·PR·커밋의 양을 늘리면 조직은 개인별 출력(output)을 더욱 쉽게 세고 싶어 한다.
   2. 그러나 측정하기 쉬운 속도나 라인 수가 더 나은 제품, 더 높은 품질, 고객이 원하는 기능을 뜻하지는 않는다.
   3. Charity는 AI가 오히려 “좋음(good)이란 무엇인가?”, “생산성이란 무엇인가?”, “더 나음과 훌륭함은 어떻게 다른가?”를 이른 시점부터 반복해서 묻게 만든다는 점을 긍정적으로 본다.

1.2. 속도 숭배와 팀 결과의 구분

1. 빠름은 ‘더 나음’의 미성숙한 대용물이다

   1. AI 논의는 “더 빨리 할 수 있다”는 주장으로 빠르게 수렴한다. 하지만 빠른 배포가 더 좋은 기능이나 고객 가치로 이어진다는 보장은 없다.
   2. Gergely는 Anthropic과 Spotify 엔지니어링 리더가 Claude Code로 주당 또는 일일 4,500개 변경을 배포한다고 말한 사례를 언급한다. 두 사람은 속도는 들었지만 품질·기능의 유용성·고객 선호까지는 듣지 못했다고 지적한다.
   3. Spotify 장애로 일부 에피소드가 올라가지 않았던 경험을 통해, 변경 횟수만 늘어도 사용자가 원하는 결과가 자동으로 늘지는 않는다는 점을 보여 준다.

2. 측정 단위는 개인이 아니라 팀과 제품이어야 한다

   1. 버튼이 계속 움직이는 것을 고객이 원하는지, 기능이 실제 문제를 해결하는지, 시스템이 안정적인지를 봐야 한다.
   2. 팀의 산출물(team output)과 고객 경험이 개인 커밋 수보다 우선한다.
   3. AI는 산출물을 양적으로 부풀리기 쉬우므로, 무엇을 만들었는지보다 그것이 어떤 결과를 만들었는지를 확인하는 체계가 중요해진다.

2. Charity Majors의 배경과 관측성으로 향한 여정

2.1. Second Life, Parse, Facebook

1. Linden Lab에서 Second Life를 만들다

   1. Charity의 첫 직장은 현재 촬영 장소 길 건너편에 있던 Linden Lab이었다.
   2. 당시 Second Life를 만드는 일을 하며, 대규모 온라인 시스템과 운영 문제를 경험했다.

2. Parse 인수와 실패에서 얻은 기회

   1. 이후 모바일 백엔드 개발자에게 사랑받던 개발자 도구 Parse를 만들었다. Parse는 모바일 서비스를 위한 백엔드로 널리 사용되었다.
   2. Facebook이 Parse를 인수했지만 결국 서비스를 종료했다. Charity는 대부분의 인수가 실패한다는 첫 번째 큰 교훈을 이때 얻었다.
   3. 그럼에도 Facebook에서 이름을 알리게 되었고, 회사를 떠날 무렵 투자자들이 “돈을 받아 보겠느냐”고 제안했다. 그 경험이 Honeycomb 창업으로 이어졌다.

2.2. Facebook의 Scuba가 Honeycomb의 영감이 된 과정

1. 운영 장애의 바늘을 찾는 문제

   1. Parse가 급성장하며 매주 새로운 앱 하나가 iTunes 상위 10위권에 올라갔고, 그러면 갑자기 장애가 발생했다.
   2. 백만 개가 넘는 모바일 앱을 호스팅하던 시기에 로그 속 “건초더미 속 바늘”을 찾는 데 몇 시간 또는 몇 주가 걸렸다.
   3. 로그를 많이 생성한 앱이 원인처럼 보이더라도 실제 원인은 그 뒤에서 모두가 대기하게 만든 다른 문제일 수 있었다.

2. Scuba의 전환점

   1. Facebook 내부 도구 Scuba에 데이터를 넣자 문제를 “보고서 실행 → 클릭 → 원인 발견”의 흐름으로 찾을 수 있었다.
   2. 운 좋게 원인을 맞혀야 하는 어려운 엔지니어링 문제가 즉시 탐색 가능한 문제로 바뀌었고, Charity는 이를 “정말 마음이 날아갈 만큼 큰 문제를 해결한 경험”으로 기억한다.
   3. Honeycomb은 엔지니어가 이런 능력을 잃지 않도록, Scuba 같은 관측성 도구를 누구나 쓸 수 있게 하려는 생각에서 출발했다. 처음에는 모든 스타트업이 실패한다고 생각하며, 실패하면 다시 구석에서 Go 코드를 쓰고 결과물을 오픈소스화할 계획까지 세웠다는 농담도 덧붙인다.

3. 회의론에서 ‘언제’의 질문으로: AI 코드 생성의 전환

3.1. 2025년의 AI와 2010년의 클라우드

1. 초기 회의론은 합리적이었다

   1. Charity는 2025년 초 AI를 클라우드보다 큰 프로그래밍 언어 정도의 변화로 봤지만, 세대를 바꾸는 사건으로까지는 보지 않았다.
   2. 2025년 3월 SRCON에서 Fred Hebert와 함께 “vibe coding을 해 보라”고 권했을 때 청중은 웃고 야유하며 신음했다.
   3. 당시의 설득 논리는 “AI를 배워야 더 잘 불평할 수 있다”는 것이었다. 도구를 직접 써 봐야 무엇이 잘못되었는지 구체적으로 비판할 수 있기 때문이다.

2. 모델보다 하네스(harness)가 변화를 가속했다

   1. Charity는 2025년 11월 Opus 4.5를 계기로 생각이 크게 바뀌었지만, 뒤돌아보면 모델 자체보다 하네스와 도구 체계가 핵심이었다고 설명한다.
   2. 초기에는 실패하면 다시 시도하는 셸 스크립트 정도였던 것이, 에이전트가 맥락을 유지하고 작업을 반복하며 도구를 호출하는 구조로 발전했다.
   3. 2025년 7월 무렵부터 이미 “생각보다 빨리 온다”는 사람들이 있었고, 그들은 Claude Code·Pi·OpenCode 같은 하네스를 직접 사용한 사람들이었다.

3.2. 과거의 과장된 약속과 이번 변화의 차이

1. 회의론의 역사

   1. 신경망이 곧 마법을 부릴 것이라는 예측은 과거에도 반복되었다.
   2. “이미 우리에게는 모든 것을 해결하는 프로그래밍 언어가 있다. 이름은 COBOL이다”라는 스티커 농담은 기술의 유행과 과장을 비튼다.
   3. 노코드(no-code)와 로우코드(low-code)도 사람의 약속은 비슷했지만 결과는 과장에 가까웠다. 그래서 과거에 회의적이었고 실제로 옳았던 경험이 이번 회의론을 강화했다.

2. 그러나 이번에는 ‘될까’보다 ‘어떻게 대비할까’가 중요하다

   1. AI가 제한된 범위에서 중간 수준의 소프트웨어 엔지니어처럼 코드를 작성할 수 있다는 주장은 처음에는 비범한 주장이라 의심할 만했다.
   2. 이제는 AI가 읽지 않은 코드를 배포하게 될 가능성 자체를 두고 논쟁하는 것이 생산적이지 않다.
   3. 진짜 질문은 “어떤 검증을 거치면 읽지 않은 코드를 안전하게 배포할 수 있는가?”다. Charity는 이것이 곧 엔지니어링의 질문이라고 말한다.

4. 읽지 않은 코드를 배포하는 세계의 설계

4.1. 코드가 ‘캐시(cache)’가 되는 이유

1. 생성 비용의 급락

   1. AI로는 한 번 직접 작성하는 것보다 함수의 10,000개 변형을 생성하는 편이 더 빠를 수 있다.
   2. 생성이 값싸지면 희소 자원은 코드 작성 시간이 아니라 평가(evaluation), 테스트, 계약 확인, 운영 검증으로 이동한다.
   3. 지금까지 소프트웨어 비용의 큰 부분은 작성보다 유지보수와 누적된 코드 라인에 묶여 있었다. 생성 비용이 떨어지면 기존 코드에 계속 수선하는 방식 자체가 비경제적일 수 있다.

2. 불변 인프라에서 불변 애플리케이션 코드로

   1. 불변 인프라(immutable infrastructure), 상태 비저장 서비스(stateless services), 컨테이너(containers), 블루 배포(blue deployments), 코드로서의 인프라(infrastructure as code)는 “실행 중인 것을 고치지 말고 교체하라”는 공통 전제를 공유한다.
   2. Chaff Fowler의 표현을 빌리면 AI는 이 전제를 인프라에서 애플리케이션 코드로 밀어붙인다. 수정(mutation)을 계속하면 엔트로피가 쌓이지만, 교체(replacement)는 상태를 리셋한다.
   3. 코드를 계속 편집하는 대신 명세(specification)와 계약(contract)을 저장하고, 여러 구현을 생성·평가해 교체하는 방향이 가능해진다.

3. 재작성의 비용과 겸손

   1. Parse의 Ruby on Rails API 원본 작성에는 약 6개월이 걸렸지만, 이를 Go로 다시 쓰는 데는 2년이 걸렸다.
   2. Go가 당시 미성숙했고 MongoDB 드라이버 등 주변 구성 요소도 직접 만들어야 했다. Ruby·MongoDB·JavaScript 조합은 타입 안전성이 약해 더 고통스러웠다.
   3. 기존 아키텍처 바깥에 새 아키텍처를 세우는 strangler-fig 패턴은 사용자의 계약을 하나씩 깨뜨리며 발견하는 방식이다. 이 계약을 문서와 다이어그램으로 보존해 명세에서 코드를 생성할 수 있다면 더 나은 산출물이 될 수 있다.
   4. 다만 복잡한 데이터베이스 마이그레이션을 해 본 사람이라면 계약을 완벽하게 추론하고 저장할 수 있다고 자신해서는 안 된다. Charity는 AI 생성이 어디까지 갈지는 모르지만 지금보다 더 멀리 갈 수 있고, 그 과정이 우리에게 유익할 것이라고 선을 긋는다.

4.2. 시스템 관리와 QA에서 배울 것

1. 시스템 관리자(CIS admin)의 교훈

   1. 예전에는 서버 한 대 한 대를 ‘반려동물(pets)’처럼 손으로 설정하고 옷을 입혔다. 자동화가 이를 대체하자 시스템 관리자 역할은 사라졌지만, 사람 자체가 사라진 것은 아니다.
   2. 이들은 운영체제와 하드웨어를 이해했기 때문에 소프트웨어 엔지니어, 프로덕트 매니저, 기술 영업 등으로 옮겨갈 수 있었다.
   3. Charity는 CPU와 메모리를 깊이 이해하는 세대의 디버깅 능력이 여전히 가치 있다고 본다. 모든 사람이 저수준 지식을 배울 필요는 없지만, 기반을 이해한 경험은 새로운 생성 시스템을 검증하는 데 도움을 준다.

2. QA와 Ops가 소프트웨어 엔지니어링에 주는 교훈

   1. 소프트웨어 엔지니어링은 “어떻게 되어야 하는가(how it should be)”에 집중해 왔고, Ops와 QA는 “실제로 무엇인가(what is)”와 “정말 작동하는가”에 집중해 왔다.
   2. 코드가 존재하는 저장소(repo)가 세계의 전부라는 믿음은 틀렸다. 시스템의 진짜 상태는 운영 환경(production)에 있다.
   3. 소프트웨어 엔지니어가 프로덕션을 볼 수 없게 하는 조직도 있지만, 운영은 개발 이후에 붙는 단계가 아니라 개발의 한 단계다.
   4. AI가 이 사실을 다시 드러내고 있다. 사람이 작성한 코드도 Ops 관점에서는 믿을 수 없는 에이전트가 만든 코드였으며, 이제 AI는 그 사실을 더 노골적으로 보여 준다.

4.3. 코드 리뷰는 하나의 일이 아니다

1. ‘코드 리뷰’에 과도하게 많은 의미가 묶여 있다

   1. 코드 리뷰가 없다고 하면 동료와 대화하지 않거나 주니어를 멘토링하지 않겠다는 뜻으로 오해되기 쉽다.
   2. Parse 동료이자 현재 GitHub에서 풀 리퀘스트를 담당하는 David Poole에게 코드 리뷰는 “이것을 우리 제품에 넣을 것인가?”를 결정하는 일이다.
   3. 제품의 정신 모델이 일관적인지, 아키텍처 방향이 옳은지, 추가할지 말지를 논의하는 것은 인간이 잘하는 일이며 코드 리뷰 이전에 하는 것이 이상적이다.

2. 코드 자체를 읽는 리뷰의 한계

   1. API 설계, 제품 방향, 계약은 대화와 설계 검토로 다루는 편이 낫다.
   2. 문법·버그·스타일을 눈으로 읽는 리뷰는 나쁘지 않지만, 사람이 기억하고 확인해야 할 가드레일이 없다면 비싼 수동 보정 작업이 된다.
   3. 새로 합류한 사람이 팀의 규칙을 배울 때는 유용할 수 있으나, 린터·문서·자동화된 검증으로 추출할 수 있는 지식을 매번 사람의 시간으로 채우는 것은 좋은 설계가 아니다.

3. AI 검증형 PR의 사례

   1. Charity는 Intercom(현재 Finn)이 루비 모놀리스(Ruby monolith)를 10~15분마다 하루 수백 번 배포하는 것을 오래전부터 높은 수준의 엔지니어링 규율로 봐 왔다.
   2. Intercom은 AI로 검증된 PR 방식을 공개했다. 매우 높은 품질 기준을 자동화해 가장 시니어한 엔지니어들의 지혜가 모든 diff에 적용되도록 한다.
   3. 사람이 모든 diff를 기억하고 사소한 부분을 지적하는 대신, 자동 검증은 “이 방향이 맞는가?”라는 중요한 인간 대화에 집중할 여지를 만든다.

5. 비결정성, 신뢰 계정, 그리고 AI를 ‘지루하게’ 만들기

5.1. 비결정적 시스템에는 더 많은 규율이 필요하다

1. AI는 규율을 증폭한다

   1. AI는 규율이 있는 팀의 자동화와 검증을 증폭시키고, 규율이 없는 팀의 부주의와 기반 침식을 증폭시킨다.
   2. 사람이 예측할 수 있는 고장만 테스트하는 것은 낮은 기준이다. AI가 생성한 코드가 무엇을 할지 모른다면 테스트와 평가가 더 넓어져야 한다.
   3. QA의 행동 테스트(behavioral tests), 성능·부하 테스트, 퍼즈 테스트(fuzz testing), 스모크 테스트(smoke test), 적합성 테스트(conformance testing) 등이 함께 필요하다.

2. 적합성(conformance)이 절대 성능만큼 중요하다

   1. 새 코드가 이전 구현보다 무조건 빠른지만 볼 것이 아니라, 기존 시스템이 지키던 경계와 동작에서 과도하게 벗어나지 않는지 확인해야 한다.
   2. AI가 생성한 여러 변형이 같은 계약과 성능 범위 안에 있는지 비교하면, 사람이 모든 코드를 읽지 않고도 신뢰를 평가할 수 있다.
   3. “이 코드를 읽지 않는다면 이전에 생성한 코드의 성능 범위 안에서 동작하는지 어떻게 알 것인가?”라는 질문이 적합성 테스트의 출발점이다.

5.2. 신뢰는 생성 단계에서 검증 단계로 이동한다

1. 신뢰 계정(trust account)의 은유

   1. 지금까지 우리는 코드를 사람이 작성하고 이해했다는 사실을 신뢰의 근거로 삼았다.
   2. AI 생성 코드를 읽지 않으면 생성 단계에서 신뢰를 인출(debit)하게 된다.
   3. 그 신뢰는 테스트, 평가, 가드레일, 프로덕션 검증으로 다른 장소에서 다시 입금(credit)해야 한다.

2. 결정적 시스템과 비결정적 시스템을 함께 운영하기

   1. 결정성(determinism)은 여전히 매우 가치 있다. 같은 입력이 같은 결과를 내는 영역을 잃어버리면 비즈니스 소프트웨어의 예측 가능성이 사라진다.
   2. AI는 강력하지만 결과가 널뛰기하는 비결정적 도구다. 따라서 “AI가 마음대로 돌아다니게” 두지 말고, 잘라 놓은 경로와 제한된 영역(carved pathways and corralled places)을 제공해야 한다.
   3. AI를 마법이나 종교가 아니라 일반 기술로 다루고, 유용한 초능력은 쓰되 기반을 침식하는 사용 방식은 차단해야 한다. 이것이 Charity가 말하는 “AI를 다시 지루하게 만들기(make AI boring again)”다.

3. 채용 도구가 보여 준 비결정성의 위험

   1. Hacker News에서 화제가 된 HackerRank의 이력서 점수 시스템은 로컬 모델로 같은 이력서를 100번 실행해도 약 66점에서 99점까지 달라졌다.
   2. 많은 회사가 85점을 통과 기준으로 둔다면, 같은 사람의 합격 여부가 실력보다 동전 던지기에 가까워진다.
   3. AI가 모든 사용 사례에 적합한 것은 아니다. “AI가 아니라 이 문제에 맞지 않는 도구”라고 말할 수 있는 조직적 신뢰가 필요하다.

6. Honeycomb의 AI 규범과 인간의 책임

6.1. “사람이 루프 안에 있다”가 아니라 “당신이 루프를 소유한다”

1. 책임의 외주화는 금지된다

   1. 강력한 도구가 등장하면 조직의 기준도 올라간다. Honeycomb은 AI를 쓸지 말지의 이분법보다 더 나은 결과(better outcomes)를 기준으로 삼는다.
   2. “Claude가 그렇게 말했다”는 변명이 될 수 없다. AI가 만든 결과도 사용자 자신의 작업이며, 그 루프의 소유자는 인간이다.
   3. 루프를 소유한다는 것은 에이전트가 무엇을 읽고, 쓰고, 배포하고, 누구의 권한으로 행동할 수 있는지 통제한다는 뜻이다.

2. 동료의 시간과 관심을 존중하라

   1. Charity의 기본 규칙은 자신이 읽지 않은 것을 누구에게도 보내지 않는 것이다.
   2. 만드는 데 걸린 시간보다 받는 사람이 읽는 데 더 오래 걸린다면, 그것은 대체로 슬롭이며 상대의 시간과 관심을 무례하게 소비하는 일이다.
   3. AI에게 답을 찾게 하지 않고 동료에게 바로 질문하는 습관, 자신이 대충 생성한 문서를 그대로 넘기는 습관도 돌아봐야 한다.
   4. 영어가 제2언어인 사람이나 신경다양성이 있는 사람이 AI를 사용하는 것은 존중을 위반하는 것이 아니다. 핵심은 AI 사용량이 아니라 합리적인 요청과 상대방의 주의를 존중하는 태도다.

3. AI를 얕은 지름길과 깊은 사고의 도구로 구분하라

   1. AI를 적게 생각하기 위한 지름길로 사용할 수도 있고, 더 깊고 엄밀하게 생각하기 위한 보조 도구로 사용할 수도 있다.
   2. 핵심 업무에서는 후자를 우선해야 한다. 특히 다른 사람에게 검토를 요청한다면 생성물을 먼저 이해하고 필요한 맥락을 제공해야 한다.
   3. 글쓰기는 종이에 생각하는 일이다. Charity는 어려운 문제를 생각해 글로 공유하는 자신의 핵심 업무를 AI에 외주화하지 않는다. 대신 구조 검토나 피드백을 받는 데 AI를 사용한다.

6.2. AI가 소프트웨어에 특히 잘 맞는 이유

1. 논리와 언어의 결합

   1. 소프트웨어는 논리와 언어로 만들어지고, AI 역시 논리와 언어를 다룬다.
   2. 코드에는 컴파일, 타입 검사, 테스트, 실행 결과 같은 구조화된 검증 장치가 있다.
   3. 법률 문서나 일반 문장처럼 그럴듯하지만 틀린 결과를 찾기 어려운 영역보다, 코드에서는 실패를 더 명시적으로 관찰할 수 있다.

2. 소프트웨어가 AI의 ‘킬러 앱’일 가능성

   1. 코드는 목적을 가진 언어의 단순화된 형태이며, 실행 가능성과 검증 가능성을 가진다.
   2. 법정에 제출한 문서에 AI가 만든 가짜 판례가 섞이면 법원이 변호사를 제재할 수 있지만, 어떤 문장을 어떻게 검증할지 체계화하기는 더 어렵다.
   3. 따라서 소프트웨어에서 작동하는 가드레일과 평가 방식이 다른 산업으로 확장될 수는 있어도, 소프트웨어에서 제대로 검증하지 못하는 것을 다른 산업에서 더 잘 검증하기는 어렵다.

7. AI의 두 진영과 운영 현실의 충돌

7.1. ‘AI pill’ 진영과 회의론 진영은 모두 실제를 본다

1. 낙관론자의 현실

   1. AI를 적극 사용하는 사람들은 변화가 지수 곡선의 안쪽에서 진행되고 있으며, 다른 회사가 빠르게 앞서가고 자신들이 뒤처질 수 있다고 느낀다.
   2. 이런 속도의 기술 변화는 드물다. 보통 지수적 변화는 오래 지속되지 않지만, 지금은 충격적인 변화가 계속 발생하고 있다.
   3. 실제로 재작성, 반복적인 고충 자동화, 에이전트 기반 작업에서 믿기 어려운 성과가 나오고 있으며, 이를 경험한 사람들은 다시 없애고 싶어 하지 않는다.

2. 운영자의 현실

   1. 온콜(on-call) 책임자는 시스템이 녹아내리는 정신 모델, 부주의하게 생성된 슬롭, 장애와 정리 작업을 직접 본다.
   2. AI 사용이 늘어난 뒤 시스템이 더 나빠지고, 사고가 많아지고, 품질이 떨어지는 현상을 “기분 탓”으로 치부할 수 없다.
   3. Charity는 두 진영이 모두 자신들이 소수이고 억압받는다고 느끼는 역설을 지적한다. 한쪽은 변화에 뒤처지는 팀 안에서 고립되고, 다른 쪽은 비용을 말하면 AI를 싫어하는 사람으로 취급된다.

7.2. Meta와 Intercom이 보여 준 비용

1. Meta의 Sev0 사례

   1. Meta 내부에서 최고 심각도인 Sev0가 약 두 달 동안 비정상적으로 많이 발생했다는 이야기가 전해졌다.
   2. Instagram과 WhatsApp에서 신뢰·안전 및 신뢰성 담당 인력이 제거된 시기와 겹쳤고, 각각의 장애에는 포스트모템이 남지만 연결을 부정하기는 어려웠다.
   3. Meta는 거의 10년 동안 이런 ‘배지’를 달지 않았지만, 사람과 안전망을 줄이고 속도만 강조하면 “move fast and break things”가 다시 현실이 될 수 있다.

2. Intercom의 18개월 데이터

   1. Intercom은 18개월 동안 신뢰성과 코드 품질이 하락했다고 공개적으로 보여 주었다.
   2. 최근에야 회복 조짐이 나타났지만, 아직 과거 수준으로 돌아오지는 않았다.
   3. Charity가 Intercom을 높이 평가하는 이유는 승리만 홍보하지 않고 “무엇이 좋아졌고, 그 대가가 무엇이었으며, 아직 무엇을 청소 중인지”를 공개하기 때문이다.

3. 두 진영을 다시 연결하는 방법

   1. AI를 사랑하는 사람은 생산성의 승리뿐 아니라 장애·재작업·신뢰성 비용도 말해야 한다.
   2. 온콜 담당자는 자신의 비용을 말하되, 자동화와 재작성에서 발생한 실질적 승리를 가짜라고 단정하지 말아야 한다.
   3. Charity의 부탁은 “전체 이야기를 말하라”는 것이다. AI는 마법이 아니지만, 큰 긍정적 변화를 이미 만들고 있으며 비용까지 계산해야 그 변화가 지속된다.

8. DevOps의 미완성 피드백 루프와 관측성

8.1. DevOps의 의도와 실패

1. Dev와 Ops 사이의 원죄

   1. DevOps 이전에는 개발자가 코드를 만들고 Ops가 벽 너머로 전달받아 서버와 리눅스 버전을 관리했다.
   2. 한쪽은 코드를 쓰고 다른 쪽은 그것을 운영하는 분할은, 작성자가 자신의 코드가 실제로 어떻게 동작하는지 모르게 만드는 split-brain이었다.
   3. DevOps 운동은 Ops가 코드를 배우고 개발자가 운영을 이해하도록 해 이 간극을 메우려 했다.

2. 분리 자체는 건강할 수 있지만 피드백은 연결되어야 한다

   1. 플랫폼 팀은 인프라의 안정성·복원력·자기보호를 책임지고, 애플리케이션 팀은 사용자의 경험을 책임지는 식의 분리(separation of concerns)는 유효하다.
   2. Anthropic도 클라우드 플랫폼 팀과 사용자 기능·통합을 다루는 Applied AI 팀을 분리한다. 플랫폼 팀은 엔지니어가 사라지지 않을 것이라 보는 반면 Applied AI 팀은 가능성을 더 열어 둔다.
   3. 문제는 책임 경계가 아니라, 코드를 쓰는 사람과 프로덕션의 빠른 피드백 루프가 끊기는 것이다. Charity는 20년간의 DevOps가 이 하나의 루프를 만들려 했지만 아직 실패했다고 평가한다.

8.2. 관측성은 시스템의 배출가스와 제품의 왕관 보석을 구분한다

1. 메트릭·로그·트레이스라는 세 기둥의 재해석

   1. 메트릭과 로그는 많은 제3자 소프트웨어가 내보내는 시스템 배출가스(exhaust)다. 팀이 작성하거나 소유하지 않은 소프트웨어도 실행해야 하므로 데이터를 받아 값싼 곳에 저장해야 한다.
   2. 반면 회사의 핵심 코드와 고객 경험을 드러내는 텔레메트리는 왕관 보석(crown jewels)이다.
   3. 이 데이터는 단순한 운영 부속품이 아니라 어떤 것을 측정하고 어떤 관계를 보존할지 결정하는 제품 의사결정이어야 한다.

2. 관계가 데이터의 가치를 만든다

   1. 29개의 데이터 필드가 있는 wide event나 trace에 30번째 필드를 추가하면, 그 하나는 기존 필드들의 조합을 가능하게 해 다른 모든 필드보다 더 큰 가치를 만들 수 있다.
   2. 비결정적 소프트웨어는 무엇을 할지 미리 예측하기 어렵기 때문에, 실행 순간의 관계와 맥락을 풍부하게 저장해야 한다.
   3. AI 에이전트가 관측성 저장소를 읽을 때도 개별 로그보다 여러 이벤트 사이의 관계가 의사결정에 더 중요하다.

8.3. OpenTelemetry와 AI 에이전트용 새 관측성 프리미티브

1. 자동 계측(auto-instrumentation)의 진입장벽 하락

   1. OpenTelemetry는 누구나 사용해야 할 표준으로 자리 잡았고, 일반적인 코드 패턴은 모델의 학습 데이터에도 많이 반영되어 있다.
   2. 이제는 계측하지 않는 것보다 계측을 포함해 작성하는 편이 빠르고 쉬워졌다.
   3. 과거에는 메트릭인지 로그인지 트레이스인지, 카운터인지 게이지인지, 로그 레벨과 카디널리티를 어떻게 정할지 고민하며 계측에 코드 작성 시간의 두세 배 또는 네 배를 썼다. 배포 후 대시보드를 찾는 일까지 포함하면 더 어려웠다.

2. Span과 Trace

   1. 스팬(span)은 트레이스(trace)를 이루는 구조화된 로그 조각이며, 트레이스는 전체 실행의 시간적·인과적 흐름을 담는다.
   2. 웹 시스템의 기본 단위였던 단일 트랜잭션은 AI 시스템의 긴 대화와 다중 에이전트 호출을 표현하기에 부족하다.

3. Honeycomb의 Timeline

   1. 고객의 대화에 대응하는 감독자 에이전트가 여러 하위 에이전트를 만들고, 각 에이전트가 API와 저장소를 호출한 뒤 결과를 반환하는 상황은 몇 시간에 걸칠 수 있다.
   2. 이때 엔지니어는 여러 트레이스 탭을 열고 ID를 복사하는 대신, 전체 흐름을 축소해 보고 필요할 때 하위 스팬으로 확대할 수 있어야 한다.
   3. Honeycomb의 Timeline은 스팬 위에 놓이는 메타트레이스(meta-trace), 즉 트레이스들의 트레이스를 표현하려는 새 프리미티브다.
   4. 앞으로는 테스트·텔레메트리·평가(evals)가 에이전트와 결합해, 어떤 AI 결과가 어떤 시스템 상태와 고객 경험으로 이어졌는지 함께 검증하는 방향으로 발전할 가능성이 크다.

8.4. 관측성 에이전트의 컨텍스트 문제

1. 전통적 텔레메트리의 쓰레기화
   1. 메트릭·로그·트레이스를 그대로 에이전트 컨텍스트에 넣으면 중요하지 않은 데이터가 컨텍스트 윈도우를 채운다.
   2. 실제로 일부 AI SRE 스타트업은 배포한 에이전트가 관측성 데이터를 대부분 건너뛰고, 더 풍부하고 온전한 원본 텔레메트리로 upstream 이동한다는 사실을 관찰했다.
   3. 에이전트에게 데이터를 많이 주는 것이 아니라 의사결정에 필요한 관계를 보존하고 요약해 제공해야 한다.

9. Observability Engineering 2판과 지속 가능한 리더십

9.1. 책의 전면 재작성

1. 정의가 안정된 뒤에야 가능한 개정

   1. O'Reilly는 책이 성공하고 주제가 여전히 중요하면 2판을 제안한다.
   2. 초판은 2019~2021년에 쓰여 관측성의 정의가 집필 도중에도 변했고, Charity는 “더는 못 하겠다. 가져가서 충분하기를 바란다”는 상태로 마무리했다고 회고한다.
   3. 2판에서는 관측성의 정의는 더 안정되었지만 세상과 AI 시스템이 급변하는 상황을 본격적으로 다룬다.

2. 규모와 구성

   1. 초판 약 250쪽에서 2판 약 600쪽으로 늘었고, 사실상 전체를 다시 썼다.
   2. 총 6부로 구성된다. 1부와 6부는 Charity가 쓰며 결정적·비결정적 시스템과 리더십을 다룬다.
   3. 2·3부는 Liz, Austin, George가 코드 계측과 이해 방법을 AI 사용 여부에 따라 병렬적으로 설명한다.
   4. 4·5부에는 프런트엔드·모바일, CI/CD, ClickHouse의 컬럼형 스토리지, Finn의 Iteratively 관측성 사용법 등 게스트 심층 글이 들어간다.

3. 리더와 조직을 위한 6부

   1. 약 200쪽을 차지하는 6부는 관측성 거버넌스와 리더를 위한 내용이며, CTO에게 “AI 목표는 시스템을 이해하는 능력에 막혀 있다”는 공개편지로 시작한다.
   2. 유행어 대신 시스템 이론을 활용해 소프트웨어 전달을 설명하고, 관측성을 비용 센터가 아닌 투자로 다룰 때와 비용 센터로 다룰 때를 구분한다.
   3. Staff·Principal·Distinguished 엔지니어가 공식 권한 없이 변화를 추진하는 법, build·buy·open source 선택, 공급업체와의 관계도 다룬다.

9.2. 관측성과 공급업체 파트너십

1. 신뢰와 영향력의 누적

   1. 이상적인 공급업체 관계는 서로의 성공을 자신의 성공처럼 여기고, 로드맵에 영향을 주며, 함께 일하는 것을 기뻐하는 두 팀이 하나의 큰 회사를 운영하는 것처럼 느끼는 관계다.
   2. 현실의 많은 관계는 돈과 서비스를 교환하고 악수하는 정도로 끝나도 괜찮다.
   3. 하지만 AI 시대에 시니어 엔지니어와 리더에게 신뢰 구축, 상호성, 상대를 얼마나 믿을 수 있는지 검증하는 능력은 오래가는 기술이다.

2. 리더가 사업을 잘해야 윤리도 지킬 수 있다

   1. Charity가 제시한 리더십 순위는 “친절하고 배려 깊으며 사업 운영에 능한 사람”이 가장 효과적이고, 그다음은 “끔찍한 사람이지만 사업 운영에 능한 사람”이며, 그 외는 뒤따른다는 것이다.
   2. X/Twitter 사례에서 1,700명 수준의 엔지니어 조직이 핵심 제품 약 30명과 다른 팀 약 30명, 총 60명 정도로 운영되는 현상을 언급한다. 결과가 좋고 나쁨의 논쟁은 가능해도 훨씬 적은 인력으로 운영되는 현실 자체는 부정할 수 없다.
   3. 기존 엔지니어가 효율과 높은 기준을 스스로 만들지 않으면 다른 사람이 그 일을 대신해 우리에게 할 수 있다.
   4. 친절함과 DEI 같은 가치를 진심으로 유지하려면 먼저 사업에서 이겨야 한다. 돈이 풍부할 때만 좋은 사람인 척하는 조직은 어려워지면 가치를 쉽게 버린다.

10. 엔지니어링 매니저·디렉터·주니어의 미래

10.1. 리더도 직접 코드를 만져야 한다

1. 리더의 최소 손 감각

   1. 코드 생성이 값싸진 시대에 엔지니어링 매니저와 디렉터는 모두 손을 움직여 프로덕션에 diff를 보내고 PR을 통과시키는 느낌을 알아야 한다.
   2. AI가 빈칸을 채우고 오래된 감각을 되살리는 일이 그 어느 때보다 쉬워졌으므로 “나는 이제 기술과 거리가 멀다”는 변명은 약해졌다.
   3. 팀 규모가 작아지고 한 사람이 더 넓은 영역을 소유할 가능성은 좋은 변화가 될 수 있다. 다만 CEO가 남의 조직 규모 축소를 보고 마법처럼 따라 하거나, 해고를 AI 전략으로 포장하는 방식은 위험하다.

2. 중간 관리자의 핵심 역할

   1. 관리자가 늘어나며 권력이 관리자에게 이동하는 경향과, 관료주의가 “아니오”보다 “예”를 쉽게 만드는 문제는 주기적으로 조정해야 한다.
   2. 그렇다고 중간 관리자가 불필요해지는 것은 아니다. 중간 관리자는 감지(sense-making)와 맥락 제공(context-giving)을 담당한다.
   3. 엔지니어가 단순히 작업 목록을 받아 AI로 처리하는 세계가 아니라, 무엇을 이루려는지와 어떻게 이룰지를 이해하고 정서적·창의적·협업적으로 참여하는 세계를 만들어야 한다.
   4. 맥락은 만들기 어렵고 오래 유지되지 않으므로, 이를 계속 재구성해 팀에 제공하는 역할은 오히려 중요해진다.

10.2. 디렉터와 매니저를 위한 행동 전략

1. 잠시 IC(Individual Contributor)로 돌아가기

   1. 중간 관리자를 좋아하고 능력도 있다면, 한동안 IC로 돌아가는 것이 현실적인 전술이다.
   2. 이를 실패나 강등으로 숨기지 말고 변화의 최전선으로 달려드는 선택으로 소유해야 한다.
   3. 기술 변화에 대한 불안과 흥분은 생리적으로 거의 같으며, 둘을 가르는 것은 주도권(agency)이다.

2. AI 경험을 이력서에 남겨라

   1. 현재 직장에서 AI를 접할 수 없다면 커리어 위험이 크다. 업무에서 작은 AI 프로젝트라도 시작해 경험을 이력서에 기록해야 한다.
   2. 2~3년의 AI 엔지니어링 경험을 가진 사람은 매우 수요가 높지만, 경험이 전혀 없는 구직자에게는 기회를 주지 않는 시장이 될 수 있다.
   3. 지금은 시작하기 쉬운 시기지만 시간이 지날수록 선두와 후발 주자의 격차가 벌어진다. 다음 면접에서 AI 경험이 없으면 필터링될 수 있으므로 “지금 조금이라도 확보하라”는 것이 경고다.

10.3. 주니어 엔지니어는 괜찮을 것이다

1. 가치 측정의 이중 잣대

   1. 어떤 엔지니어의 가치를 측정하는 법도 모르는 상황에서 주니어의 가치를 정량화하겠다는 걱정은 모순이다.
   2. Boris의 관찰에 따르면 고등학생·대학생 개발자들은 소프트웨어 개발 생명주기를 몰라도 이미 놀라운 것을 만들고 있다.
   3. 이들은 기존 세대가 생각하지 못한 결론과 방식을 찾아낼 가능성이 있다.

2. 채용과 인턴십

   1. 결론은 주니어를 실제로 고용하고 기회를 주라는 것이다.
   2. 오픈소스에서 뛰어난 17세 기여자를 발견해 채용한 스타트업 창업자들의 사례처럼, 나이와 전통적인 경력보다 실제로 무엇을 만들었는지를 봐야 한다.
   3. 인턴십은 낮은 위험과 짧은 기간으로 서로를 시험할 수 있고, 일이 맞지 않아도 그 사람에게는 다음 기회를 얻을 훨씬 나은 이력이 남는다.

11. AI 피로를 다루는 법: 종류를 나누고 통제권을 회복하라

11.1. AI 피로는 하나가 아니다

1. 슬롭 피로

   1. AI로 생성했지만 작성자가 읽지 않은 글, PR 설명, 메시지가 동료의 시간을 계속 소비한다.
   2. Charity는 AI로 쓴 것임을 알아볼 수 있는 순간 바로 읽지 않는다고 말할 정도로 이런 콘텐츠에 지쳤다.

2. 과장과 공포 피로

   1. 일부 CEO가 “AI가 곧 모든 것을 끝낸다”는 식으로 계속 공포를 부추기는 것을 Cal Newport가 ‘doom trolling’이라고 부른다는 이야기가 나온다.
   2. 기술의 역사가 삶을 더 편하게 만들 것이라는 기대 대신 가족과 일자리에 대한 공포를 안겨 주는 분위기는 사람을 소진시킨다.

3. 소셜미디어 피로와 일상 대화의 피로

   1. Charity는 AI 슬롭 게시물이 너무 많아 소셜미디어를 멀리하게 되었다.
   2. 에이전트와 사람이 Slack에서 하루 종일 대화하는 모습이 비슷해지는 것도 불쾌하게 느낀다.
   3. Honeycomb은 완전 분산 회사지만, 직접 만나 대화하는 것이 원격 팟캐스트보다 훨씬 즐겁다는 경험을 통해 인간적인 만남의 가치를 확인한다.

11.2. 팀 단위의 작은 실험

1. 바닥에서 시작하는 규범

   1. 팀이 AI로 생성된 PR 설명을 더 이상 원하지 않는다면 그렇게 합의할 수 있다.
   2. 수요일에는 AI를 사용하지 않거나, 일주일 동안 특정 에이전트를 끄고 결과를 비교할 수도 있다.
   3. 변화가 큰 시기에는 실험이 쉬워진다. 리더에게 사전 허가를 기다리기보다 먼저 시도하고 무엇이 작동했는지·작동하지 않았는지·무엇을 배웠는지 알려 주는 편이 낫다.

2. 변화의 빈 공간을 활용하라

   1. 리더도 무엇이 효과적인지 모르는 상황에서 모든 실험을 위에서 설계할 수 없다.
   2. 팀이 시간을 관리하고 캘린더를 통제하며 직접 실험하면, 다른 팀이 결과를 재사용할 수 있다.
   3. 스마트폰이 처음 나왔을 때 18~19세의 개발자가 iOS·Android를 먼저 파고들어 2년 뒤 도메인 전문가가 된 것처럼, 변화가 클 때는 나이와 기존 직급보다 먼저 뛰어드는 사람이 전문가가 된다.

12. 마무리: 책 두 권과 인간으로 남는 법

12.1. Charity가 추천한 책

1. Catastrophe Ethics

   1. 저자는 생명윤리학자 Travis Rieder로 소개된다.
   2. 현대인은 우유를 마시면 소의 고통을 걱정하고, 아몬드 우유를 마시면 물 문제를 걱정하는 식으로 어떤 선택을 해도 누군가를 해치는 것처럼 느낀다.
   3. 공리주의 같은 전통적 윤리 체계도 모든 상황에 적용되는 완벽한 레시피가 아니다.
   4. “신도, 주인도 없다(no gods, no masters)”는 것은 모든 것이 상대적이라는 뜻이 아니라, 세상을 스스로 공부하고 어떤 고통과 원인에 끌리는지 내면을 들여다보며 무엇이 중요한지 직접 결정해야 한다는 뜻이다.
   5. 이 태도는 performative rage, 즉 실제 행동보다 분노를 공연하는 문화와 반대이며, Charity가 AI와 리더십을 대하는 태도와도 맞닿아 있다.

2. More Everything Forever

   1. Adam Becker가 쓴 책으로, 저자는 샌프란시스코의 저널리스트이며 철학 학사와 천체물리학 박사 배경을 가진 것으로 소개된다.
   2. 책은 AI 종교, 특이점(singularity), 효과적 이타주의, 가속주의, 무한 성장주의를 해체한다.
   3. 우주에 대해 우리가 아는 유일한 지수 성장의 사실은 영원히 지속될 수 없다는 점이다. 성장 곡선은 S-curve로 꺾이거나 붕괴한다.
   4. 저자의 건조한 유머는 별 체계를 정복하려는 계획과 영생 연구를 조롱한다. 특히 영생에 집착하는 사람들을 “아빠를 잃은 슬픈 어린 소년들”이라고 묘사하는 대목을 Charity는 인류의 죽음 공포가 드러나는 장면으로 받아들인다.

12.2. 최종 시사점

1. AI를 사용하되, 책임과 존중을 양도하지 말 것

   1. 생성물은 자신의 작업이며, 타인의 시간과 주의를 존중하기 위해 반드시 읽고 이해해야 한다.
   2. AI의 혜택을 말할 때는 장애·재작업·신뢰성 저하라는 비용도 함께 말해야 한다.

2. 신뢰를 검증 체계로 재배치할 것

   1. 사람이 모든 코드를 읽는 관행이 약해질수록 테스트·eval·적합성·관측성·결정적 재현이 더 중요해진다.
   2. 운영 환경은 개발 후의 장소가 아니라 개발의 일부이며, 빠른 피드백 루프가 AI 시대의 핵심 기반이다.

3. 변화에 주도적으로 뛰어들 것

   1. 불안과 흥분은 거의 같은 생리 반응이며 주도권이 둘을 가른다.
   2. 관리자는 직접 손을 움직이고, 중간 관리자는 맥락을 제공하며, 주니어는 기회를 받아야 한다.
   3. 변화가 자신에게 오기를 기다리지 말고 작은 팀 실험으로 먼저 파도에 뛰어들어야 한다.

주요 발언 모음

“개인의 출력이 아니라 팀의 출력이 중요하다.”

“AI가 쓴 코드를 우리가 읽지 않고 배포할 것인가를 두고 ‘될까’를 논쟁할 필요는 없다. 무엇이 있으면 편안하게 배포할 수 있는지를 말해야 한다. 그게 엔지니어링이다.”

“코드는 캐시다(Code is cache).”

“생성 단계에서 신뢰 계정에서 인출했다면, 다른 곳에서 그 신뢰를 다시 쌓아야 한다.”

“프로덕션은 개발이 끝난 뒤에 일어나는 일이 아니다. 프로덕션은 개발의 한 단계다.”

“사람이 루프 안에 있는 것이 아니다. 당신이 루프를 소유한다.”

“AI를 적게 생각하기 위한 지름길로 사용할 수도 있고, 더 깊고 엄밀하게 생각하기 위한 도구로 사용할 수도 있다.”

“AI는 마법이 아니다. AI는 기술일 뿐이다.”

“불안과 흥분은 생리적으로 거의 같다. 둘의 차이는 주도권이다.”

핵심 데이터 & 수치

• Parse는 Facebook 인수 당시 백만 개가 넘는 모바일 앱을 호스팅했으며, 장애 원인을 찾는 데 Scuba가 결정적이었다.
• 2025년 3월 SRCON에서 Charity는 vibe coding을 권했지만 청중의 반응은 웃음과 야유였다.
• 2025년 11월 Opus 4.5가 Charity의 관점을 크게 바꾸는 계기가 되었다.
• AI로 함수 10,000개 변형을 직접 작성하는 것보다 빠르게 생성할 수 있다는 경제성이 재작성·교체 중심 개발을 촉진한다.
• Parse의 Ruby on Rails API는 약 6개월에 작성했지만 Go 재작성에는 약 2년이 걸렸다.
• Intercom은 Ruby 모놀리스를 약 10~15분마다 하루 수백 번 배포한다.
• HackerRank 이력서 점수 모델은 동일 이력서를 100회 실행했을 때 약 66~99점으로 변동했으며, 85점 기준에서는 결과가 동전 던지기가 된다.
• Intercom은 18개월 동안 신뢰성과 코드 품질이 하락했고, 회복 조짐은 보였지만 아직 이전 수준은 아니었다.
• X/Twitter 사례에서는 과거 약 1,700명의 엔지니어가 하던 핵심 제품 업무가 약 30명 규모로, 다른 핵심 팀까지 합쳐 약 60명 수준으로 운영되는 상황이 언급된다.
• Observability Engineering 2판은 초판 약 250쪽에서 약 600쪽으로 늘었고, 그중 리더십·거버넌스 파트만 약 200쪽이다.

스폰서 세그먼트 기록

영상에는 본 대화 외에도 AI 코드 검증과 에이전트 운영을 주제로 한 세 개의 스폰서 메시지가 삽입된다.

1. Antithesis: 결정적 시뮬레이션 테스트(Deterministic Simulation Testing, DST)로 전체 시스템을 적대적 시뮬레이션에서 실행하고, 공격적인 장애 주입(fault injection)으로 버그를 찾는다. 발견한 장애는 결정적 재현(deterministic replay)으로 다시 실행할 수 있어, AI가 만든 코드의 신뢰를 검증하는 맥락과 연결된다.
2. WorkOS: 에이전트가 어떤 사용자·권한으로 무엇에 접근할 수 있는지를 세밀하게 통제하는 Fine-Grained Authorization(FGA), SSO와 SCIM을 제공한다고 소개된다. “루프를 소유한다”는 접근 권한 통제 문제와 연결된다.
3. Buildkite: 에이전트가 커밋을 5배·10배·50배 더 많이 만들 때 CI 병목이 생기므로, 병렬 실행과 런타임 라우팅으로 처리량을 확장하는 CI 플랫폼으로 소개된다. 약 14억 job-minutes/주 규모의 처리 사례와 30일 무카드 시험판이 언급된다.

핵심 요약 (20줄)

1. AI 시대의 생산성은 개인 커밋 수보다 팀의 결과와 고객 경험으로 판단해야 한다.
2. 속도와 변경 횟수는 더 나은 제품이나 높은 품질을 자동으로 보장하지 않는다.
3. 2025년 AI의 급격한 전환은 모델만이 아니라 에이전트 하네스와 도구가 성숙했기 때문에 일어났다.
4. 과거 노코드와 로우코드의 과장 때문에 회의적이었던 태도는 합리적이었지만, 이제는 가능 여부보다 검증 조건을 논의해야 한다.
5. AI는 함수 수천 개의 변형을 값싸게 만들며 개발의 병목을 생성에서 평가와 검증으로 옮긴다.
6. 불변 인프라의 교체 원리는 AI 시대에 애플리케이션 코드 재생성으로 확장될 수 있다.
7. QA와 Ops는 저장소가 아니라 실제 프로덕션에서 소프트웨어가 작동하는지를 확인하는 관점을 제공한다.
8. 코드 리뷰에는 제품 방향·아키텍처 대화와 문법·버그 검사가 뒤섞여 있으므로 역할을 분리해야 한다.
9. 비결정적 시스템을 운영하려면 테스트·eval·퍼즈·부하·적합성 검증이 더 많이 필요하다.
10. AI 코드 생성으로 인출한 신뢰는 자동화된 가드레일과 운영 데이터로 다시 쌓아야 한다.
11. AI를 좁은 경로와 명확한 경계 안에 두어 결정적 시스템과 함께 안전하게 운영해야 한다.
12. 소프트웨어는 논리와 언어, 컴파일과 실행 검증을 갖추었기 때문에 AI의 가장 적합한 영역일 가능성이 크다.
13. AI 낙관론자는 실제 생산성 승리를 보고, 온콜 담당자는 실제 품질 저하와 장애 비용을 본다.
14. 두 진영 모두 틀린 것이 아니며, 승리와 비용을 함께 말할 때 대화가 다시 연결된다.
15. DevOps의 핵심 과제는 코드 작성자와 프로덕션 사이의 빠른 피드백 루프를 만드는 것이다.
16. OpenTelemetry와 풍부한 관계형 텔레메트리는 AI 에이전트의 관측성과 평가를 연결하는 기반이 된다.
17. 매니저와 디렉터도 직접 코드를 생성하고 배포해 기술 변화의 감각을 유지해야 한다.
18. 중간 관리자는 사라지는 역할이 아니라 팀에 맥락을 주고 복잡한 상황을 해석하는 역할로 재정의되어야 한다.
19. 주니어 엔지니어는 새 도구를 먼저 익힐 수 있으므로 채용과 인턴십으로 기회를 제공해야 한다.
20. 불안과 흥분의 차이는 주도권이므로, 작은 실험으로 AI 변화의 방향을 직접 만들어야 한다.