Should AI Engineers Still Read Code in 2026? The Z/L Continuum — Alex Volkov, ThursdAI

한 줄 핵심

2026년에는 AI가 코드를 더 많이 쓰더라도 모든 코드를 직접 읽는 습관보다, 변경마다 필요한 증거와 검증 수준을 구분해 시스템과 중요한 경로에 판단을 집중하는 방식이 더 중요하다.

시간별 요약

1. 0:01
   AI Engineer Europe에서 한쪽은 “Code is free”를, 다른 쪽은 “Read every effing line of code”를 외치며 같은 불안을 드러낸다. 2025년 말 이후 모델이 16시간 이상 걸리던 작업을 끝내기 시작했고, AI 엔지니어링은 코드를 쓰는 일보다 에이전트를 감독하는 일로 바뀌었다.
2. 2:00
   Boris와 Anthropic 사례, GitHub 커밋 급증 같은 흐름은 코드 생산량이 폭증했음을 보여준다. 그러나 출력이 많아진 만큼 품질이 자동으로 따라오지는 않으며, 대규모 생성이 오히려 안정성과 리뷰 병목을 드러낸다.
3. 8:02
   핵심 쟁점은 “코드를 읽을 것인가”가 아니라 “이 변경에 어떤 증거가 필요한가”로 바뀐다. 비중요 코드에는 속도를 우선하고, 인증·결제·권한·되돌릴 수 없는 데이터처럼 중요한 경로는 직접 읽고 검증해야 하며, 같은 엔지니어도 작업에 따라 서로 다른 수준의 검토를 적용해야 한다.
4. 14:00
   실무적으로는 변경을 원자적인 PR로 쪼개고, traces·evals·shadow mode·rollback 같은 검증 장치를 붙이며, 코드를 쓰는 에이전트와 테스트·검토를 하는 주체를 분리해야 한다. 결국 중요한 것은 “코드를 읽는 시간”이 아니라 “시스템이 기억하고 검증하게 만드는 구조”를 설계하는 일이다.
5. 18:02
   loops는 계획-실행-검증-재시도를 자동으로 돌리는 방식으로, 사람의 개입을 줄이되 검토를 없애는 것이 아니라 숨기는 데 가깝다. 향후 능력치가 더 올라가면 리뷰의 대상은 코드에서 작업 방향과 루프 자체로 이동하겠지만, 어떤 단계에서도 판단과 증거의 필요성은 사라지지 않는다.

실무 인사이트

• 코드 리뷰 기준을 “전체를 볼 것인가”가 아니라 “이 변경이 요구하는 증거 수준은 무엇인가”로 재정의하면, 속도와 안전을 동시에 관리하기 쉽다.
• 에이전트가 코드를 쓰는 조직일수록 생성·검토·테스트 역할을 분리하고, critical path에만 인간 검토를 집중하는 운영 규칙이 필요하다.
• loops나 자동 수정 체계를 도입할 때는 실패 시 재시도보다 관측성, 롤백, 검증 기준을 먼저 설계해야 품질 하락의 악순환을 막을 수 있다.