"이걸 선택할 줄 아는 사람이 미래의 엔지니어다" — Addy Osmani가 말하는 AI 시대의 판단력과 책임감

출처: Tech Bridge — [한영자막] "이걸 선택할 줄 아는 사람이 미래의 엔지니어다" — Addy Osmani (AI Engineer World's Fair 2026.07.14) · 러닝타임 18분 5초

"에이전트는 여러분이 리뷰할 수 있는 것보다 더 많은 것을 배포할 수 있습니다. 그렇다면 이제 여러분은 무엇을 위해 존재합니까?" — Addy Osmani, AI Engineer World's Fair 키노트에서

2026년 7월 14일, AI Engineer World's Fair 무대에 오른 구글 크롬 개발자 관계 총괄이자 저명한 엔지니어링 저술가 Addy Osmani는 "미래의 엔지니어는 무엇을 할 가치가 있는지 선택할 줄 아는 사람"이라는 도발적인 정의로 강연을 시작한다. 코딩 에이전트가 사람보다 더 빠르게, 더 많은 코드를 만들어내는 시대에 인간 엔지니어에게 남는 역할은 무엇인가? 이 리포트는 그가 제시한 "하네스 엔지니어링 → 루프 엔지니어링 → 소프트웨어 공장"이라는 흐름과, 그 공장을 운영하는 인간에게 요구되는 판단력(Judgment)·취향(Taste)·책임감(Accountability)의 개념을 시간순으로 정리한다.

1. 미래의 엔지니어란 누구인가 (00:00~00:57)

Osmani는 건축(아키텍처) 이야기를 하기 전에 먼저 인간적인 측면을 짚고 넘어가고 싶다고 말한다. 그가 던진 정의는 명확하다. "미래의 엔지니어는 무엇을 할 가치가 있는지 선택할 수 있는 사람으로 정의될 것이다." 이들은 에이전트가 수행하는 점점 더 자동화되는 업무에 대해 증거를 확보하고, 그 업무에 대한 이해와 판단을 모두 책임지게 될 것이라고 그는 전망한다.

2. 판결(Verdict)이란 무엇인가 — 품질, 판결, 책임의 삼각관계 (00:57~01:23)

여기서 그가 쓰는 "판결(Verdict)"이라는 용어는 우리가 갑자기 재판관이 된다는 뜻이 아니다. 그는 세 개념을 명확히 구분한다. 품질(Quality)은 증거를 만들어내는 점검 시스템이고, 판결(Verdict)은 그 증거로부터 내려지는 인간의 책임 있는 결정이며, 답변 가능성(Answerability)은 그 판결을 나중에 설명하고 옹호할 수 있는 능력이다. 배송 가능한가, 막아야 하는가, 방향을 바꿔야 하는가 — 이런 제작 결정에 대한 책임을 지는 것이 바로 판결이며, 책임감이야말로 사람이 확신을 갖고 판결을 내리게 해주는 핵심 요소라고 그는 강조한다.

3. 역할의 재편 — 직함이 아니라 시스템의 어느 부분을 소유하는가 (01:23~02:18)

Osmani는 업계 전반에서 역할이 재편되고 있다는 것을 보여주는 사례로 Anthropic의 Boris Cherny가 정리한 다섯 가지 아키타입을 인용한다. 프로토타입 제작자(Prototyper), 빌더(Builder), 스위퍼(Sweeper·정리자), 그로어(Grower·성장 담당), 메인테이너(Maintainer). 기존 직종 간 경계가 모호해지고 업무 자체를 중심으로 역할이 재편되면서, 중요한 질문은 "당신의 직함이 무엇인가"가 아니라 "시스템의 어떤 부분을 소유할 수 있는가"로 바뀐다는 것이다. 그는 이 분류가 지나치게 모호하지 않으면서도 낙관적이라 마음에 든다고 평했다.

4. 하네스 엔지니어링에서 루프 엔지니어링으로, 그리고 소프트웨어 공장 (02:18~03:16)

왜 이런 변화가 일어나는가? Osmani는 최근 며칠간 업계가 논의해온 "하네스 엔지니어링"과 "루프 엔지니어링" 개념으로 설명한다. 하네스 엔지니어링에서 코딩 에이전트는 모델과 그 주변을 감싸는 "하네스"(환경, 도구, 파일 시스템, Git)의 합으로 정의되며, 이 하네스가 지능을 위임 가능한 무언가로 바꿔준다. 다음 단계인 루프 엔지니어링은 한 번만 실행하고 끝나는 것이 아니라, 끊임없이 알리고 확인하고 기억하고 다음 행동을 결정하는 시스템을 설계하는 것이다. 이 모든 것을 하나로 모으면 "소프트웨어 공장"이 탄생한다. 다만 이 내부 순환 고리 안에서 에이전트가 무엇을 하든, 생산에 대한 최종 결정은 여전히 인간이 내린다는 것이 핵심이다. 인공지능의 발전이 인간의 역할을 없애는 것이 아니라, 오히려 인간의 판단력을 가장 중요한 평가 기준으로 끌어올렸다는 것이 그의 진단이다.

5. AI 코드는 이제 일반적인 코드다 — 책임 소재는 철학이 아닌 엔지니어링 필수 요건 (03:16~04:05)

Sonar의 2026년 개발자 설문조사에 따르면 AI 기반 코딩은 더 이상 주변적인 요소가 아니다. 2023년 6%에 불과했던 커밋 코드 중 AI 생성·보조 비중은 2024년 19%, 현재 42%, 2026년 예상 55%, 2027년 예상 65%까지 치솟는다. Osmani는 이를 "공장은 더 이상 실험 단계가 아니다. 이미 커밋 히스토리에 들어와 있다"고 표현한다. 일단 AI 코드가 코드베이스에서 큰 비중을 차지하게 되면, 책임 소재는 더 이상 철학적 차원의 문제가 아니라 엔지니어링 필수 요건이 된다. 여기에는 품질 측면도 있다. Sonar의 또 다른 연구에 따르면 깔끔한 저장소와 지저분한 저장소의 통과율은 비슷했지만, 깔끔한 코드는 실제로 토큰을 더 적게 쓰고 재방문 비용도 더 적었다. 유지보수 용이성이 공장 전체의 효율성을 좌우한다는 뜻이다.

6. 검증의 역설 — "신뢰 없이는 용량도 없다" (04:05~05:34)

제작 비용이 낮아진다고 해서 리뷰 비용까지 저절로 낮아지는 것은 아니다. Sonar의 통계는 냉정하다. 응답자의 96%가 AI 생성 코드를 완전히 신뢰하지 않는다고 답했지만, 커밋 전에 항상 검증한다는 응답은 48%에 그쳤고, AI 코드 리뷰가 사람 코드보다 오래 걸린다는 응답은 38%였다. 즉 회의론(스켑티시즘)은 높은데 검증은 그 속도를 따라가지 못하는 "2배의 신뢰 격차"가 존재한다는 것이다. Osmani는 이를 "위험은 엔지니어가 AI를 불신한다는 데 있는 게 아니라, 불신하면서도 검증보다 빠르게 배포한다는 데 있다"고 요약한다. 안전성은 검증 비용을 낮추고, 검증 과정을 명확히 하며, 사람들이 검증을 건너뛰기 어렵게 만드는 데서 나온다. 개인 차원을 넘어 조직 전체로 보면, 거버넌스가 따라가지 못할 때 리뷰와 검증이 병목이 되며, 도입 속도는 기업의 정책 수립 속도보다 훨씬 빠르다.

7. 알파와 디케이 — 능력 격차는 시계처럼 붕괴한다 (05:34~06:01)

이 지점에서 Osmani는 이 강연의 핵심 개념인 "알파(Alpha)"와 "디케이(Decay·붕괴)"를 제시한다. 알파는 지금 당신이 할 수 있는 것과 현재 모델이 할 수 있는 것 사이의 격차, 즉 당신을 의미 있게 더 낫게 만드는 능력이다. 디케이는 모델이 그 격차를 얼마나 빨리 따라잡는가를 뜻한다. 당신을 특별하게 만드는 것이 어떤 능력이라면, 결국 프런티어 모델이 그 능력을 따라잡을 시계가 째깍거리고 있다는 것이다.

8. "취향(Taste)"의 역할과 한계 (06:01~07:56)

누구나 무엇이든 만들 수 있게 된 시대에는 "무엇을 만들지 선택하는 것"이 중요해진다는 폴 그레이엄의 지적을 Osmani는 지지하면서도, "취향"이라는 단어가 아직 설명하고 싶지 않은 모든 것을 가려주는 마법의 단어로 남용될 위험을 경계해야 한다고 말한다. 그는 Mitchell Hashimoto가 내린 더 유용한 정의를 인용한다. "취향이란 객관적인 측정 기준이 아직 존재하지 않는 상황에서 수준 높은 질적 판단을 내릴 수 있는 능력이다." 생산 비용이 저렴해질수록 취향은 중요해지고, 누구나 10가지 선택지를 낼 수 있다면 진짜 희소한 능력은 어떤 선택지가 존재할 가치가 있는지 가려내는 것이다. 하지만 그는 못박는다. 취향은 영원한 해자가 아니다. 이것도 결국 알파의 일종이며, 모델이 예시와 선호를 학습함에 따라 결국 초기화된다. 안목 있는 사람들은 앞으로도 오랫동안 중요하겠지만, 그 기술의 가장 좋은 형태는 신비로움이 아니라 더 나은 판단을 내리고 팀과 시스템이 학습할 수 있는 모범 사례를 남기는 것이라고 그는 강조한다.

9. 붕괴 테스트 — 판단력조차 벽이 아니라 경사면이다 (07:56~08:33)

Osmani는 "이것이 능력이라면 결국 붕괴한다"는 테스트를 각 요소에 적용해본다. 속도(Speed)는 이미 사라졌다 — 커피 가지러 간 사이 600줄이 만들어진다. 기억력(Recall)도 사라졌다 — 이제는 그저 컨텍스트 윈도우일 뿐이다. 검증(Verification)은 자동화되는 중이며, 우리가 약한 고리였다. 취향(Taste)은 알파이며 릴리스마다 초기화되지만 붕괴하는 데는 더 오래 걸릴 것이다. 그리고 판단력(Judgment)조차 어떤 면에서는 벽이라기보다 완만한 경사면에 가깝다. 그러므로 전략은 어느 한 가지 능력에만 집착하지 않고 계속 실력을 한 단계씩 끌어올리는 것이다. 이제 "에이전트가 무엇을 할 수 있는가"는 최선의 전략적 질문이 아니다. 에이전트가 할 수 없는 일의 목록은 계속 줄어들기 때문이다. 더 중요한 질문은 "오직 인간만이 답할 수 있는 것은 무엇인가"이다.

10. 엔지니어가 피해야 할 것 ① — 인지적 부채(Cognitive Debt) (08:33~10:44)

"이제 누구나 개발자다. 하지만 그것이 그들을 엔지니어로 만들어주지는 않는다." Osmani는 '엔지니어'라는 단어에 더 엄격한 기준이 필요해진 이유를 여기서 설명한다. 엔지니어는 단순히 코딩을 하고 무언가를 만들어내는 사람이 아니라, 시스템에 대해 추론하고 제약 조건을 고려하며 절충안을 옹호하고 위험을 관리하며 문제가 생겼을 때 도움을 요청할 수 있는 사람이다. 그가 첫 번째로 경계하는 함정은 인지적 부채다. 이는 문제를 해결하는 방법에 대한 이해와 기억이 퇴화하는 현상으로, 에이전트에 점점 더 많이 의존할수록 코드에서 이런 격차 — 저장소에 있는 코드의 양과 팀원이 실제로 이해하는 코드의 양 사이의 격차 — 가 벌어진다. 빌드가 테스트를 통과하고 병합 가능한 PR이 있어도, 팀이 실제로 프로덕션에 배포하는 시스템을 제대로 설명할 능력을 잃어버릴 수 있다는 것이다. 30초짜리 짧은 실행은 상호작용처럼 느껴지지만, 한 시간이나 하루 걸리는 장기 작업은 워크플로우로 봐야 하며, 이럴 때 리뷰는 마지막에 한 번 훑어보는 것이 아니라 완전한 통제 시스템이 되어야 한다.

11. 엔지니어가 피해야 할 것 ② — 인지적 굴복(Cognitive Surrender) (10:44~11:29)

두 번째로 피해야 할 것은 AI의 답을 묻지도 따지지도 않고 받아들이는 인지적 굴복이다. 위임은 "일을 하고, 내가 판단할 수 있도록 증거를 제시해 달라"고 말하는 것이지만, 굴복은 "내가 아직 아무 의견도 형성하지 않았는데 당신의 답이 이제 내 답이 됐다"고 말하는 것이라고 그는 구분한다. 와튼 스쿨이 1,372명을 대상으로 진행한 연구는 경고 신호를 보낸다. AI가 틀린 답을 내놓았을 때에도 73%가 여전히 자신이 그 답을 골랐다고 생각했고, 오히려 더 확신을 느꼈다. Osmani의 결론은 명확하다. "실패의 원인은 AI를 쓰는 데 있는 것이 아니라, 남에게서 자신감을 빌려오는 데 있다."

12. 엔지니어가 피해야 할 것 ③ — 오케스트레이션 세금(Orchestration Tax) (11:29~12:55)

세 번째는 오케스트레이션 세금 — 여러 AI 에이전트를 동시에 관리할 때 겪는 수확 체감과 인지적 소모다. 샌프란시스코 베이 지역에서 노트북을 켜놓고 클라우드 에이전트 얘기만 하는 사람들을 흔히 볼 수 있는 것처럼, 업계는 점점 더 많은 에이전트를 병렬로 돌리거나 수백·수천 개의 에이전트를 탑재한 제품을 이야기한다. 하지만 더 많은 AI 에이전트가 돌아간다고 해서 당신의 지원 여력(bandwidth)이 커지는 것은 아니다. 인지적 대역폭은 병렬화되지 않기 때문이다. 루프를 하나씩 만들 때마다 라우팅, 병합, 검증, 통합에 관한 더 많은 결정이 필요해진다. 해결책은 에이전트 수를 줄이는 것이 아니라 주의력을 시스템처럼 설계하는 것 — 어디로 들어가는지, 무엇이 필요한지, 무엇을 재사용하는지를 의도적으로 설계하는 데 있다.

13. "엣지의 반감기는 릴리스 하나, 서명의 반감기는 커리어 전체" (12:55~14:52)

Osmani는 "진로 계산법"이라는 개념으로 넘어간다. 속도, 기억력, 검증 능력, 심지어 취향까지 — 능력의 반감기는 모델 출시 한 번 정도에 불과하다. 하지만 서명(Signature)의 수명, 즉 당신의 신뢰도와 전문성은 훨씬 더 오래간다. 여기서 "서명"이란 작품에 붙는 이름 — 실제로 배송된 것 뒤에 서 있는 개인, 팀, 조직을 의미한다. 기술은 영향력을 발휘하게 해주고, 책임감은 그 영향력을 신뢰로 바꿔준다. 그는 여기서 아주 분명한 선을 긋는다. 에이전트는 정책 안에서 선택하고 라우팅하고 병합하고 에스컬레이션하고 운영할 수 있으며 많은 시스템에서 실제로 그래야 한다. 하지만 실행(Execution)과 책임(Accountability)은 완전히 다른 것이다. 에이전트는 운영 지침을 따를 수 있지만 그에 따른 결과를 계승할 수는 없다. 일이 실패했을 때 문제는 "누가 정책을 이해했는가, 누가 위험을 감수했는가, 그 여파에 대한 책임은 누구에게 있는가"이다. 요즘 채용에서 강조하는 "높은 자율성(High Agency)" 역시 모든 것을 직접 한다는 뜻이 아니라 자신의 결과에 대해 적극적으로 책임지는 것 — 언제 위임하고, 언제 점검하고, 언제 중단하고, 언제 결과에 이름을 올려야 하는지 아는 것이라고 그는 재정의한다.

14. 내부 루프와 외부 루프 — 새로운 운영 모델 (14:52~17:04)

조직 내 승진 체계로 비유하면, 맨 아래는 문제를 발견해 시스템에 넘기는 사람이고 상위 직급은 실행·진단·제안·권고·해결을 담당하며, 가장 중요한 움직임은 어떤 문제에 투자할 가치가 있는지를 가려내는 분별력이다. 이를 운영 모델로 옮기면: 에이전트는 내부 실행 루프를 돌며 조사·실행·테스트·보고를 하고, 엔지니어는 외부 루프를 소유하며 결정·검증·승인·소유의 책임을 진다. 담당 에이전트가 증거 — 차이점, 테스트, 로그, 근거, 추적, 스크린샷 등 — 를 제출하면, 그때부터 본격적인 엔지니어링 작업이 시작된다. 그 일이 할 가치가 있었는지 판단하고, 증거가 충분한지 확인하고, 프로덕션에 도달할 내용을 승인하거나 방향을 바꾸거나 소유권을 갖는 것이다. 몇 개의 에이전트와 일하든 수천 개와 일하든 이 원칙은 동일하다. 경계는 인간이 AI의 결과물을 어떻게 바라보느냐가 아니라 증거와 책임이다. 그의 운영 규칙은 단순하다: "이유를 설명하지 못하면 배송하지 마라." 대규모 코드베이스에 흔한 오너 파일(OWNERS file)처럼, 코드베이스의 어느 부분에 누가 책임을 지는지가 명확해야 한다는 것이다.

15. 마무리 — 소프트웨어 수요는 줄지 않는다 (17:04~18:05)

Osmani는 낙관으로 강연을 마무리한다. 자동화는 모두에게 새로운 기회를 열어준다. 엔지니어링은 계속 한 단계 더 발전하고 있으며, 새로운 업무는 루프 설계, 증거 설계, 오염 부지 관리 같은 것이 되겠지만, 키보드 입력 횟수가 줄어든다고 해서 엔지니어링 업무 자체가 줄어드는 것은 아니다. 오히려 취향·검증·소유권·관리가 필요한 표면적이 더 넓어진다는 뜻이다. 소프트웨어 작성이 쉬워질 때마다 사람들은 세상이 필요로 하는 소프트웨어의 양이 줄어들 것이라 예측해왔지만, 실제로는 정반대였다. 고급 언어, 프레임워크, 클라우드, 로우코드 — 비용을 낮추면 잠재된 수요가 드러났다. 에이전트도 똑같은 일을 할 것이다. 엔지니어링 작업 자체가 사라지는 게 아니라, 병목 현상이 "이걸 만들 수 있을까?"에서 "이게 존재해야 할까?"와 "우리가 그것에 대해 해명할 수 있을까?"로 옮겨간다는 것이 그의 결론이다. "공장을 짓고, 판결이 나올 때까지 전력을 공급하라."

핵심 요약 (Key Takeaways)

• ☑ 미래의 엔지니어는 "무엇을 할 가치가 있는지 선택할 수 있는 사람"이며, 그 역할의 본질은 코딩이 아니라 판결(Verdict) — 증거에 기반해 책임을 지고 내리는 결정 — 에 있다.
• ☑ AI 코드 비중은 2023년 6%에서 현재 42%, 2027년 예상 65%로 급증하고 있다. AI 코드는 이미 "일반적인 코드"이며 책임 소재는 철학이 아닌 엔지니어링 필수 요건이 됐다.
• ☑ 96%가 AI 코드를 완전히 신뢰하지 않지만 항상 검증하는 사람은 48%뿐이다. 위험은 불신 자체가 아니라 "불신하면서도 검증보다 빠르게 배포하는 것"이다.
• ☑ 속도·기억력·취향 등 모든 개별 "능력"은 결국 모델이 따라잡아 붕괴(Decay)한다 — 판단력조차 벽이 아니라 완만한 경사면이다. 그러므로 한 가지 능력에 집착하지 말고 계속 실력을 끌어올려야 한다.
• ☑ 엔지니어가 피해야 할 3가지 함정: ① 인지적 부채(이해 없는 위임 누적) ② 인지적 굴복(와튼 연구: AI가 틀려도 73%가 자기 확신처럼 받아들임) ③ 오케스트레이션 세금(에이전트를 늘려도 인지 대역폭은 늘지 않음).
• ☑ "엣지(기술 우위)의 반감기는 릴리스 하나, 서명(책임과 신뢰)의 반감기는 커리어 전체"다. 실행(Execution)과 책임(Accountability)은 완전히 다르며, 에이전트는 결과를 계승할 수 없다.
• ☑ 새 운영 모델: 에이전트는 내부 루프(조사·실행·테스트·보고)를, 엔지니어는 외부 루프(판단·검증·승인·소유)를 담당한다. 원칙은 "이유를 설명하지 못하면 배송하지 마라."
• ☑ 소프트웨어 제작 비용이 낮아질 때마다 역사적으로 수요는 오히려 폭증했다. 에이전트도 같은 효과를 낼 것이며, 병목은 "만들 수 있는가"에서 "존재해야 하는가·해명할 수 있는가"로 이동한다.

본 리포트는 유튜브 원본 영상을 요약·정리한 것이며, 이미지 캡처는 학습·비평 목적입니다. 원본 채널: Tech Bridge