Don’t Build Agents You Can’t Answer For — Addy Osmani
📺 원본 영상: Don’t Build Agents You Can’t Answer For — Addy Osmani
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-15
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Addy Osmani의 이 강연은 AI 에이전트가 코드를 작성하고, 테스트하고, 병렬로 작업을 수행하는 시대에 엔지니어의 역할이 어디로 이동하는지를 다룹니다. 핵심 주장은 단순합니다. 에이전트가 더 많은 일을 할수록 인간의 가치는 손으로 코드를 더 많이 치는 능력이 아니라, 무엇을 위임하고 무엇을 검증하며 무엇에 책임질 수 있는지를 판단하는 능력으로 이동한다는 것입니다.
강연자는 이를 “answerability”, 즉 결과에 대해 설명하고 책임질 수 있는 능력의 문제로 정리합니다. AI가 만든 코드가 보통의 코드가 되는 순간, 품질은 더 이상 취향이나 철학의 문제가 아니라 운영 가능한 엔지니어링 요구사항이 됩니다. 따라서 앞으로의 엔지니어링은 에이전트를 얼마나 많이 쓰느냐보다, 에이전트가 만든 결과를 어떤 증거와 책임 구조 안에서 받아들일 수 있느냐가 중심이 됩니다.
인간이 루프 안에 남아야 하는 이유
강연의 출발점은 아키텍처가 아니라 인간입니다. Osmani는 미래의 엔지니어가 “무엇이 할 가치가 있는 일인지 선택할 수 있는 사람”으로 정의될 것이라고 말합니다. 이는 단순히 업무 우선순위를 정한다는 뜻이 아니라, 자동화된 작업의 증거를 소유하고, 그 의미를 이해하며, 최종 판단에 책임지는 역할을 뜻합니다. 에이전트가 더 많은 실행을 맡게 될수록 인간은 실행자가 아니라 판정자에 가까워지지만, 이 판정은 추상적인 승인 버튼이 아니라 생산 환경에 영향을 미치는 책임 있는 결정입니다.
그가 말하는 verdict, 즉 판정은 법정의 판결 같은 과장된 의미가 아닙니다. 어떤 변경을 배포할지, 차단할지, 방향을 바꿀지, 아니면 위험을 감수하고 받아들일지를 결정하는 실제 엔지니어링 행위입니다. 품질은 증거를 만들지만, 판정은 책임을 배정합니다. 그리고 그 책임을 실제로 감당할 수 있게 만드는 조건이 바로 answerability입니다.
이 관점에서 보면 AI 에이전트 시대의 “human-in-the-loop”는 사람이 모든 것을 수동으로 확인한다는 뜻이 아닙니다. 오히려 인간 판단이 가장 큰 레버리지를 갖는 지점으로 이동한다는 뜻에 가깝습니다. 에이전트가 작업을 생성하고, 테스트하고, 보고할 수 있다면 인간은 그 산출물이 충분한 증거를 갖췄는지, 시스템의 제약을 지켰는지, 조직이 감당할 수 있는 위험인지 판단해야 합니다.
강연자는 엔지니어링 역할도 prototype, build, sweep, grow, maintain 같은 모드로 재구성될 수 있다고 설명합니다. 중요한 점은 각 모드가 단순한 업무 분장이 아니라, 에이전트에게 맡길 수 있는 실행과 인간이 책임져야 하는 판단의 경계를 다시 그리는 방식이라는 점입니다.
02:17 - prototype, build, sweep, grow, maintain 같은 엔지니어링 모드와 역할 재구성에 대한 설명
Harness Engineering에서 Software Factory로
강연자는 최근 엔지니어링 논의가 모델 자체에서 모델을 둘러싼 실행 환경으로 이동하고 있다고 설명합니다. Harness Engineering(하네스 엔지니어링)은 모델, 컨텍스트, 도구, 파일 시스템, Git 같은 주변 구조가 합쳐져 실제로 위임 가능한 코딩 에이전트를 만든다는 관점입니다. 즉 모델의 지능만으로는 충분하지 않고, 그 지능이 안전하게 작업할 수 있는 작업대와 제약 조건이 필요합니다.
이 흐름은 Loop Engineering(루프 엔지니어링)으로 이어집니다. 한 번 프롬프트를 보내고 결과를 받는 방식이 아니라, 계속 프롬프트하고, 검사하고, 기억하고, 다음 행동을 결정하는 시스템을 설계하는 단계입니다. 이때 에이전트는 단발성 도구가 아니라 인프라처럼 느껴지기 시작합니다. 반복 가능한 루프와 증거 생산 방식이 생기면, 인간은 매번 모든 세부사항을 직접 수행하기보다 루프가 생산한 결과를 검토하고 판정하는 위치에 서게 됩니다.
그다음 단계가 Osmani가 말하는 Software Factory(소프트웨어 팩토리)입니다. 소프트웨어 팩토리에서는 에이전트가 내부 실행 루프에서 조사, 구현, 테스트, 보고를 수행하고, 인간은 바깥 루프에서 결정, 검증, 승인, 책임을 맡습니다. 이 구분이 중요한 이유는 에이전트의 능력이 커질수록 내부 루프는 더 빨라지지만, 외부 루프의 책임은 사라지지 않기 때문입니다.
03:17 - Harness Engineering, Loop Engineering, Software Factory의 관계와 인간 판정 루프
AI 코드가 보통의 코드가 될 때 생기는 병목
Osmani는 AI-assisted code, 즉 AI 보조 코드가 더 이상 주변적인 현상이 아니라고 말합니다. 강연에서 언급된 Sonar의 조사에 따르면 AI 보조 코드는 점점 더 많은 코드베이스에서 큰 비중을 차지하고 있습니다. 이 변화가 중요한 이유는 AI가 만든 코드와 인간이 만든 코드를 별개의 것으로 취급할 수 없게 되기 때문입니다. AI가 만든 코드가 제품에 들어가고 운영 환경에 배포된다면, 그것은 곧 조직이 책임져야 하는 일반 코드입니다.
강연자는 깨끗한 코드가 인간에게만 좋은 것이 아니라 에이전트에게도 좋다고 강조합니다. Sonar의 다른 연구에서는 깨끗한 저장소와 지저분한 저장소의 테스트 통과율은 대략 비슷했지만, 깨끗한 코드는 더 적은 토큰을 사용하고 재방문도 덜 유발했다고 합니다. 이는 유지보수성이 단지 사람의 읽기 편의성에 머무르지 않고, 에이전트 기반 개발 루프의 비용과 효율에도 영향을 미친다는 뜻입니다.
04:18 - Sonar 연구를 바탕으로 깨끗한 코드가 토큰 사용량과 에이전트 재방문 횟수에 미치는 영향
그러나 생성 비용이 낮아졌다고 해서 검토 비용까지 자동으로 낮아지는 것은 아닙니다. 강연자는 AI 코드에 대해 거의 모두가 회의적이지만, 실제로 커밋 전에 항상 검증하는 사람은 절반 정도에 그친다는 Sonar 수치를 언급합니다. 이 간극이 바로 위험한 지점입니다. 불신은 있지만 검증할 시간과 체계가 없다면, 조직은 AI를 믿지 않으면서도 AI가 만든 결과를 그대로 받아들이는 모순에 빠지게 됩니다.
판단의 희소성: Alpha와 Decay
강연의 중반부에서 Osmani는 커리어 관점의 두 개념으로 alpha와 decay를 제시합니다. Alpha는 현재의 모델이 할 수 있는 일과 인간이 할 수 있는 일 사이의 간극입니다. 반면 decay는 그 간극이 줄어드는 속도입니다. 어떤 능력이 지금은 인간의 강점처럼 보이더라도, 그것이 단순한 기능적 능력이라면 모델의 다음 발전에 의해 빠르게 잠식될 수 있습니다.
이 대목에서 그는 taste, 즉 취향 또는 안목의 중요성을 다룹니다. Paul Graham의 관점을 빌려, 누구나 무엇이든 만들 수 있는 시대에는 무엇을 만들지 선택하는 능력이 중요해진다고 설명합니다. 그러나 Osmani는 taste가 설명 불가능한 마법어가 되어서는 안 된다고 경계합니다. Mitchell Hashimoto의 정의처럼, taste는 아직 객관적 지표가 존재하지 않는 영역에서 고품질의 정성적 판단을 내리는 능력으로 이해되어야 합니다.
07:15 - taste를 객관적 지표가 없는 영역에서의 정성적 판단 능력으로 설명
따라서 taste도 영원한 방어막은 아닙니다. 모델은 인간의 예시와 선호를 학습하고, 시간이 지나면 더 많은 판단 영역을 흡수할 수 있습니다. 그렇기 때문에 전략은 특정 능력 하나에 매달리는 것이 아니라, 자신의 판단 경계를 계속 한 단계 위로 이동시키는 것입니다. “에이전트가 무엇을 할 수 있는가”보다 “오직 인간만이 무엇에 책임질 수 있는가”가 더 나은 질문이 되는 이유가 여기에 있습니다.
피해야 할 세 가지 함정: Cognitive Debt, Cognitive Surrender, Orchestration Tax
Osmani는 에이전트 시대의 엔지니어가 피해야 할 첫 번째 함정으로 Cognitive Debt(인지 부채)을 제시합니다. 이는 문제를 해결하는 방법에 대한 이해와 기억이 점차 침식되는 현상입니다. 코드 관점에서는 저장소에 존재하는 코드의 양과 팀 내 인간이 실제로 이해하는 코드의 양 사이의 간극이라고 볼 수 있습니다. 테스트가 통과하고 PR이 병합되더라도, 팀이 자신들이 배포하는 시스템을 설명할 수 없다면 엔지니어링 역량은 이미 약해지고 있는 셈입니다.
두 번째 함정은 Cognitive Surrender(인지적 항복)입니다. 이는 AI의 답변을 판단 없이 자신의 답변으로 받아들이는 상태를 뜻합니다. 위임은 “작업을 수행하고, 내가 판단할 수 있을 만큼의 증거를 보여달라”는 태도이지만, 항복은 “내가 의견을 형성하기 전에 네 답이 내 답이다”라고 말하는 것과 같습니다. 강연에서 언급된 Wharton 연구에 따르면 AI가 틀렸을 때도 73%의 사람들이 자신이 틀린 답을 골랐다는 사실을 알면서도 오히려 더 확신했다고 합니다. 문제는 AI 사용 자체가 아니라, 빌려온 확신입니다.
11:31 - Wharton 연구를 언급하며 AI가 틀렸을 때도 사람들이 빌려온 확신을 갖게 되는 문제
세 번째 함정은 Orchestration Tax(오케스트레이션 비용)입니다. 더 많은 에이전트를 병렬로 실행한다고 해서 인간의 인지 대역폭이 함께 병렬화되는 것은 아닙니다. 에이전트가 많아질수록 라우팅, 병합, 검증, 통합해야 할 결정도 늘어납니다. 따라서 해결책은 단순히 에이전트를 줄이는 것이 아니라, 어디에 주의를 투입하고, 어떤 증거를 요구하며, 무엇을 재사용할지 시스템적으로 설계하는 것입니다.
책임은 자동화 이후의 잔여물이 아니라 확장의 조건이다
강연자는 accountability, 즉 책임성이 에이전트가 충분히 좋아진 뒤에도 어쩔 수 없이 남는 부담이 아니라고 말합니다. 오히려 책임성은 전체 시스템이 확장될 수 있게 하는 조건입니다. 에이전트가 더 빠르게, 더 많이, 더 병렬적으로 작업할수록 희소해지는 것은 의도 설명, 증거 검사, 위험 수용, 실패 후 시스템 개선 능력입니다. 이 능력이 없다면 자동화는 생산성 향상이 아니라 통제 불가능한 변경의 증폭기가 됩니다.
여기서 Osmani는 signature, 즉 작업 위에 남는 이름의 중요성을 말합니다. 특정 기술적 우위의 반감기는 모델 릴리스 하나만큼 짧을 수 있지만, 신뢰와 전문성의 반감기는 훨씬 깁니다. 어떤 팀, 어떤 사람, 어떤 기관이 배포된 결과 뒤에 서 있는지가 중요해집니다. 능력은 레버리지를 만들지만, 책임은 그 레버리지를 신뢰로 전환합니다.
에이전트는 선택하고, 라우팅하고, 병합하고, 정책 안에서 동작할 수 있습니다. 그러나 실행과 책임은 다릅니다. 에이전트는 runbook(운영 절차서)을 따를 수 있지만, 그 결과가 실패했을 때의 영향 범위와 후속 책임을 물려받을 수는 없습니다. 결국 중요한 질문은 누가 정책을 이해했고, 누가 위험을 받아들였으며, 누가 그 영향을 소유하느냐입니다.
High Agency의 재정의
Osmani는 최근 채용과 조직 문화에서 자주 언급되는 High Agency(높은 주도성)를 새롭게 정의합니다. 전통적으로 High Agency는 스스로 문제를 해결하고 끝까지 밀고 나가는 태도로 이해되었지만, 에이전트 시대에는 “내가 모든 것을 직접 한다”는 의미로는 확장될 수 없습니다. 대신 언제 위임하고, 언제 검사하고, 언제 멈추며, 언제 결과에 자신의 이름을 올릴지를 아는 판단력이 핵심이 됩니다.
강연자는 이를 agency ladder라는 개념으로 구체화합니다. 낮은 단계에서는 문제가 있음을 표시하고 시스템에 넘기는 수준에 머물지만, 더 높은 단계에서는 실행, 진단, 제안, 추천, 해결로 올라갑니다. 가장 높은 단계는 discernment, 즉 어떤 문제가 투자할 가치가 있는지 판단하는 능력입니다. 에이전트가 더 많은 경로를 열어줄수록, 주도성은 모든 경로를 추적하는 것이 아니라 어떤 경로가 나의 책임과 관심을 받을 만한지 결정하는 능력이 됩니다.
14:52 - agency ladder와 discernment 개념을 통해 인간 주도성의 상위 단계를 설명
이 관점은 운영 모델로도 이어집니다. 에이전트는 내부 실행 루프에서 조사, 구현, 테스트, 보고를 맡을 수 있습니다. 그러나 외부 루프의 결정, 검증, 승인, 책임은 여전히 엔지니어링의 영역입니다. 내부 루프가 capability라면 외부 루프는 agency입니다.
“설명할 수 없으면 배포하지 말라”
강연의 가장 실천적인 규칙은 “Explain it or don’t ship it”입니다. 이는 인간이 모든 코드를 직접 작성하거나 모든 줄을 읽어야 한다는 뜻이 아닙니다. 누군가는 그 작업을 방어할 수 있을 만큼 충분히 이해해야 한다는 뜻입니다. 대규모 코드베이스에서 특정 디렉터리나 영역에 owner가 지정되는 것처럼, 에이전트가 작성한 변경에도 책임의 소유자가 필요합니다.
16:16 - Explain it or don’t ship it이라는 운영 규칙과 코드 소유권의 필요성
이 규칙은 AI 에이전트를 제한하기 위한 보수적 구호가 아닙니다. 오히려 에이전트를 더 크게 쓰기 위한 운영 원칙에 가깝습니다. 에이전트가 diffs, tests, logs, rationale, traces, trajectories, screenshots 같은 증거를 반환하면, 인간은 그 증거가 충분한지 판단해야 합니다. 증거와 책임이 만나는 지점에서 비로소 엔지니어링이 시작됩니다.
따라서 앞으로의 엔지니어링은 키보드 입력량이 줄어드는 만큼 가벼워지는 일이 아닙니다. 자동화는 바닥을 끌어올리고, 엔지니어링은 한 단계 위로 이동합니다. 새로운 일은 loop design, evidence design, brownfield stewardship처럼 더 추상적이고 운영적인 영역으로 확장됩니다. 적은 타이핑은 적은 엔지니어링이 아니라, 더 넓은 표면적에 대한 취향, 검증, 소유권, 돌봄을 요구합니다.
마무리 / 핵심 정리
Osmani의 결론은 낙관적이지만 무책임하지 않습니다. 그는 소프트웨어를 더 쉽게 만들 때마다 세상이 소프트웨어를 덜 필요로 할 것이라고 예측했지만, 실제로는 반대가 일어났다고 말합니다. 고수준 언어, 프레임워크, 클라우드, low-code가 등장할 때마다 숨어 있던 수요가 드러났고, 이전에는 만들기 어렵다고 여겨졌던 아이디어들이 현실화되었습니다. 에이전트도 같은 방식으로 더 많은 소프트웨어 수요를 열어젖힐 가능성이 큽니다.
다만 병목은 바뀝니다. 앞으로의 핵심 질문은 “우리가 이것을 만들 수 있는가”에서 “이것이 존재해야 하는가, 그리고 우리가 이것에 책임질 수 있는가”로 이동합니다. 에이전트를 만들고, 소프트웨어 팩토리를 구축하고, 자동화의 불을 켜두는 것은 중요합니다. 그러나 마지막에는 누군가가 판정을 소유해야 합니다. 강연의 제목처럼, 답할 수 없는 에이전트는 만들지 말아야 하며, 만들었다면 그 결과를 설명할 수 있는 구조까지 함께 설계해야 합니다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Don’t Build Agents You Can’t Answer For — Addy Osmani |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-15 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.