Addy Osmani가 제시한 AI 시대 엔지니어 판단 기준 5가지

Addy Osmani가 제시한 AI 시대 엔지니어 판단 기준 5가지

코드를 만드는 비용이 떨어질수록, 무엇을 만들지 고르고 그 결과에 이름을 거는 판단의 값은 올라간다.

Addy Osmani는 Tech Bridge 채널 대담에서 미래의 엔지니어를 코드를 쓰는 사람이 아니라 최종 판정(Verdict)을 내리는 사람으로 다시 정의한다. 에이전트가 탐색·구현·테스트로 이어지는 내부 루프를 가져가면서 조직의 병목은 구현에서 검증으로 옮겨졌고, 생성량이 이해 속도를 넘어서는 지점에서 인지적 부채와 인지적 순응이라는 실패 모드가 나타난다. 개인이 쥔 기술 우위는 모델이 좋아질수록 감쇄하는 반면 결과물에 이름을 걸 수 있는 신뢰는 그렇지 않고, 그래서 실무에 남는 기준은 설명할 수 없는 코드는 배포하지 않는다는 한 줄이다.

구현이 싸질수록 병목은 사람이 읽고 판단하는 검증 단계로 옮겨간다.

한눈에 보기

· 에이전트가 코드 생성을 맡으면서 병목은 구현에서 검증·리뷰로 이동했고, 조직 처리량은 사람이 읽고 판단하는 속도에 묶인다.

· 인지적 부채는 내가 배포한 코드를 내가 설명하지 못하는 상태, 인지적 순응은 모델의 답을 검증 없이 받아들이는 습관을 가리킨다.

· 에이전트를 무작정 여러 개 돌리면 조율 비용인 오케스트라 과세가 붙어 산출물보다 인지적 대역폭이 먼저 고갈된다.

· 기술 우위인 알파는 모델 업데이트마다 감쇄하지만, 결과에 책임지는 서명은 사람에게 귀속되어 대체되지 않는다.

· 사람이 지켜야 할 구간은 탐색·구현·테스트의 내부 루프가 아니라 검증·승인·위험 수용의 외부 루프다.

코드 생성량이 이해 속도를 앞지를 때

에이전트 도구가 붙은 개발 환경은 사람이 한 줄씩 쓰던 작업장이 아니라 지시와 검수로 돌아가는 생산 라인, 곧 소프트웨어 팩토리에 가까워졌다. 프롬프트 한 번에 파일 여러 개가 동시에 바뀌고 테스트까지 붙어 돌아온다. Osmani가 짚는 문제는 이 라인의 출력 속도가 사람의 독해 속도와 아무 상관 없이 빨라진다는 점이다. 생산 라인은 하루에 몇 배씩 빨라지는데 검수대는 그대로면, 늘어난 산출물은 이득이 아니라 재고가 된다.

구현이 싸지면 병목은 사라지지 않고 자리를 옮긴다. 새 병목은 검증과 리뷰다. 모델 버전이 올라가도 리뷰어 한 명이 하루에 읽고 판단할 수 있는 변경량은 거의 그대로이기 때문이다. 팀 전체 속도는 가장 느린 구간이 정하므로, 생성 단계만 최적화한 팀은 체감 속도가 오히려 떨어진다.

이 격차는 팀이 보던 지표를 먼저 망가뜨린다. 머지된 PR 수와 추가된 줄 수는 올라가는데, 그 코드가 왜 그런 모양인지 답할 수 있는 사람은 오히려 줄어든다. 실제 처리량은 생성량이 아니라 설명 가능한 생성량이고, 둘의 차이가 벌어질수록 장애 대응 시간이 늘어난다. 지표가 좋아 보이는 동안 조직의 복구 능력이 조용히 나빠지는 구조다.

검증 병목이 시작됐다는 신호는 대체로 비슷하게 나타난다.

· 리뷰 코멘트가 승인 한 줄로 수렴하고, 설계 의도를 묻는 질문이 사라진다.

· 롤백이나 핫픽스 상황에서 원 작성자가 자기 코드 흐름을 처음부터 다시 읽는다.

· 장애 회고 문서에 왜 이렇게 짰는지 모르겠다는 문장이 반복해서 등장한다.

· PR 하나의 변경 파일 수가 리뷰어가 한 번에 훑을 수 있는 범위를 넘어선다.

· 테스트는 통과하는데 그 테스트가 무엇을 보증하는지 설명하는 사람이 없다.

그래서 먼저 손봐야 할 곳은 생성 속도가 아니라 검증 경로다. 하네스 엔지니어링은 에이전트가 도구·컨텍스트·권한을 안전하게 쓰도록 감싸는 실행 환경 설계를 말하고, 루프 엔지니어링은 에이전트가 스스로 돌려보고 고치도록 만드는 순환 설계를 말한다. 두 갈래 모두 목표는 같다. 사람이 마지막에 확인해야 할 것의 양을 줄여, 남은 판단이 실제로 판단다워지게 만드는 것이다.

인지적 부채와 인지적 순응

인지적 부채는 내가 배포한 코드를 내가 설명하지 못하는 상태다. 당장은 동작하니 비용이 보이지 않지만, 장애가 나거나 요구사항이 바뀔 때 이자가 한꺼번에 청구된다. 부채가 쌓인 코드베이스에서는 한 줄을 고치기 위해 필요한 재학습 시간이 최초 작성 시간보다 길어진다. 금융 부채와 다른 점은 잔액이 장부에 찍히지 않아, 터지기 전까지 아무도 규모를 모른다는 것이다.

인지적 순응은 성격이 다르다. 모델이 내놓은 답을 검증 없이 받아들이는 습관, 즉 판단 주체 자리를 비워두는 상태다. 답이 문법적으로 매끄럽고 근거처럼 보이는 설명까지 붙어 있으면, 사람은 반박 근거를 찾는 대신 수긍하는 쪽으로 기운다. 특히 자기 전문 영역 밖의 코드일수록 확인 비용이 커서 순응이 합리적 선택처럼 느껴진다.

구분

인지적 부채

인지적 순응

무엇이 비는가

코드 이해

판단 주체

생기는 순간

읽지 않고 머지할 때

근거 없이 동의할 때

겉으로 보이는 신호

설명 요청에 코드를 다시 읽음

리뷰에서 반대 의견이 사라짐

터지는 시점

장애·리팩터링 시점

설계가 틀린 방향으로 굳은 뒤

갚는 방법

요약 문서화, 소유자 지정

반증 질문, 독립 근거 확인

방치했을 때

수정 비용이 계속 증가

같은 오판이 조직 전체로 확산

둘은 서로를 키운다. 이해가 얕을수록 반박할 근거가 없어 순응하기 쉽고, 순응이 반복될수록 이해할 기회가 다시 줄어든다. Osmani가 설명할 수 없는 코드는 배포하지 않는다는 기준을 반복해 강조하는 이유는 이 고리를 끊을 수 있는 지점이 배포 직전 한 곳뿐이기 때문이다. 그 앞 단계에서는 이해 부족이 비용을 내지 않으므로 아무도 멈추지 않는다.

실무에서 이 기준은 개인 규율이 아니라 절차로 박아야 버틴다. 배포 전에 작성자가 변경 의도, 실패했을 때 영향 범위, 되돌리는 방법을 한 문단으로 쓰게 하면 설명하지 못하는 변경은 그 자리에서 걸러진다. 문서 품질을 요구하는 장치가 아니라, 이해 여부를 강제로 드러내는 장치라는 점이 핵심이다.

오케스트라 과세와 병렬 실행의 한도

에이전트를 동시에 여러 개 돌리면 산출물은 늘어나지만 조율 비용도 함께 붙는다. Osmani는 이 비용을 오케스트라 과세라고 부른다. 지휘자가 한 명인데 연주자만 늘리면 소리가 아니라 큐 사인이 먼저 밀리는 상황과 같다. 늘어난 산출물이 이득으로 바뀌려면 그만큼 늘어난 검토를 누군가 감당해야 한다.

과세가 붙는 자리는 서버 비용이 아니라 사람의 주의력이다. 병렬 작업 하나가 늘 때마다 컨텍스트 전환, 결과 비교, 충돌 정리, 무엇을 채택할지 고르는 결정이 같이 늘어난다. 인지적 대역폭이 먼저 고갈되면 나머지 에이전트의 산출물은 검토되지 못한 채 쌓이고, 그 상태에서 채택된 코드가 앞 절에서 말한 부채로 그대로 전환된다.

병렬 실행을 늘리기 전에 확인할 조건은 단순하다.

· 병렬 작업은 서로 파일 경계가 겹치지 않을 때만 늘린다.

· 각 작업에 무엇을 보면 성공인지 판정 조건을 먼저 적고 시작한다.

· 동시에 열어두는 작업 수는 내가 하루에 실제로 리뷰할 수 있는 수를 넘기지 않는다.

· 결과를 합치는 순서를 미리 정해 충돌 정리를 마지막으로 미루지 않는다.

· 실패한 작업은 즉시 닫는다. 살려두면 나중에 맥락을 복원하는 비용이 다시 든다.

여기서 쓸모 있는 개념이 주체성 사다리다. 에이전트에게 줄 권한을 제안만 하기, 승인 후 실행, 자율 실행처럼 단계로 나눠 놓고 작업 위험도에 맞춰 칸을 옮기는 방식이다. 위험도가 낮고 반복적인 작업은 위 칸으로 올리고, 되돌리기 어려운 변경은 아래 칸에 묶어두면 조율 대상 자체가 줄어든다. 과세를 줄이는 방법은 에이전트를 덜 쓰는 것이 아니라 사람이 개입할 지점을 미리 좁혀두는 것이다.

알파 감쇄와 서명의 수명

알파는 남들이 못 하는 것을 해내는 기술 격차다. 특정 프레임워크 숙련도, 손에 익은 디버깅 요령, 남보다 빠른 구현 속도가 여기 들어간다. Osmani의 진단은 냉정하다. 모델이 한 세대 좋아질 때마다 이 격차의 상당 부분이 시장에서 그냥 사라진다.

서명은 다르다. 결과물에 이름을 걸 수 있는 신뢰, 즉 저 사람이 승인했으면 배포해도 된다는 평판이다. 서명은 모델 업데이트로 대체되지 않는데, 책임을 지는 주체가 사람이어야만 성립하는 값이기 때문이다. 자동화가 아무리 진행돼도 사고가 났을 때 결정 근거를 설명하고 다음 판단을 바꾸는 일은 사람 몫으로 남는다.

항목

알파(Alpha)

서명(Signature)

정체

기술 격차

책임과 신뢰

수명

모델 세대마다 감쇄

판단 이력이 쌓일수록 강화

복제 가능성

도구가 금방 따라잡음

개인에게 귀속

쌓는 방법

새 도구·문법 학습

결정 근거 기록과 결과 책임

잃는 방법

가만히 있어도 줄어듦

설명 못 할 변경을 승인할 때

실무 함의는 학습 계획의 우선순위를 바꾼다. 새 도구를 하나 더 익히는 시간과, 내가 내린 결정과 그 근거를 남겨 추적 가능하게 만드는 시간 중 길게 보면 후자의 수익률이 높다. 아키텍처 영역별로 소유자 파일을 두고 누가 무엇을 승인했는지 기록하는 방식이 대표적인 서명 축적 수단이다. 기록이 없으면 잘한 판단도 개인 자산으로 남지 않는다.

주의할 점은 서명이 무오류를 뜻하지 않는다는 것이다. 틀렸을 때 그 사실을 빨리 드러내고 되돌린 이력도 서명에 쌓인다. 서명이 깎이는 순간은 틀렸을 때가 아니라 감췄을 때다.

내부 루프와 외부 루프의 경계

내부 루프는 문제를 탐색하고 코드를 쓰고 테스트를 돌려 고치는 반복 구간이다. 에이전트가 가장 잘하는 영역이고 위임했을 때 이득도 가장 크다. 반복 횟수가 늘어도 사람의 피로가 늘지 않기 때문이다. 실패한 시도를 버리는 비용이 거의 없다는 점도 사람과 결정적으로 다르다.

외부 루프는 그 결과를 받아 검증하고 승인하고 위험을 떠안는 구간이다. Osmani는 사람이 여기를 놓치면 앞선 자동화 전체가 의미를 잃는다고 본다. 승인할 사람이 없는 산출물은 아무리 많이 쌓여도 배포될 수 없고, 승인은 했지만 근거가 없는 산출물은 배포되면 더 나쁘다.

구간

내부 루프

외부 루프

하는 일

탐색·구현·테스트·재시도

검증·승인·위험 수용

주체

에이전트

사람

잘하는 이유

반복 비용이 0에 수렴

시스템 맥락과 책임을 함께 쥠

실패 모드

잘못된 목표를 빠르게 달성

읽지 않고 승인

필요한 산출물

재현 가능한 테스트

판단 근거 기록

경계를 문서로 못 박아두면 매번 벌어지는 논쟁이 줄어든다. 어떤 변경이 에이전트 자율 실행 대상이고 어떤 변경이 사람 승인 대상인지 목록으로 적어두면, 사안마다 새로 판단하지 않아도 된다. 데이터 마이그레이션, 권한 변경, 과금 로직처럼 되돌리기 비싼 영역은 예외 없이 외부 루프에 묶어두는 편이 안전하다.

경계가 흐려지는 전형적인 상황은 급할 때다. 배포 시간이 촉박하면 검증 단계가 가장 먼저 생략되고, 그 생략이 한 번 사고 없이 통과하면 다음부터 기본값이 된다. 경계는 여유 있을 때 정해두고 급할 때는 바꾸지 않는 편이 낫다.

그래서 무엇이 달라지나

바뀌는 것은 도구가 아니라 채점 기준이다. 얼마나 빨리 만들었는지가 아니라 왜 그걸 만들었고 무엇을 책임지는지가 평가 대상이 된다. Osmani의 표현대로면 엔지니어링의 병목은 구현 가능 여부에서 존재 당위성과 책임 가능 여부로 옮겨간다.

당장 적용할 수 있는 판단 기준은 다섯 개로 정리된다.

1. 만들 가치가 있는가 — 구현이 쉬워졌다는 사실 자체는 만들어야 할 이유가 되지 않는다.

2. 설명할 수 있는가 — 변경 의도, 실패 시 영향, 되돌리는 방법을 한 문단으로 쓰지 못하면 배포하지 않는다.

3. 알파인가 서명인가 — 지금 쓰는 시간이 감쇄할 기술로 가는지 남을 신뢰로 가는지 구분한다.

4. 내부 루프인가 외부 루프인가 — 위임할 구간과 직접 승인할 구간을 목록으로 분리해 문서화한다.

5. 조율 비용을 감당할 수 있는가 — 동시에 돌리는 에이전트 수를 내 리뷰 처리량 안에 묶는다.

여기서부터는 추측이다. 검증 병목이 계속 커지면 리뷰와 승인 자체를 보조하는 계층, 예컨대 변경 요약과 위험도 산정을 자동으로 붙여주는 도구가 표준 개발 환경으로 들어올 가능성이 크다. 다만 승인 버튼을 누르는 주체까지 자동화될지는 이 대담에서 다루지 않았고, 책임 귀속 문제가 남는 한 그 자리는 사람이 지킬 것으로 본다.

정리

에이전트가 구현을 가져간 자리에서 사람에게 남는 일은 무엇을 만들지 고르고 결과에 이름을 거는 판정이다. 그 판정을 유지하는 최소 장치가 외부 루프 분리와 설명 책임이며, 둘 다 개인 의지가 아니라 절차로 박아야 급할 때 살아남는다. 기술 격차는 모델 세대마다 줄어들지만 책임의 값은 줄지 않는다.