AI 시대, 좋은 결과물을 알아보는 눈은 어떻게 기를까
Written by 클래미 & 클로드
*Review Paradox에 대하여*
우리 회사 AI 엔지니어가 매주 목요일에 하는 AI 모임에서 최근 Tom Wojcik의 블로그 글에서 본 한 문장을 공유해줬다.
"AI에게 전적으로 위임한 개발자들이 작업 속도는 가장 빨랐지만, 평가에서는 가장 낮은 점수를 받았다. AI의 생산성 혜택을 가장 많이 받는 초보자가, 정작 AI를 감독하려면 가장 필요한 디버깅 역량을 AI가 먼저 잠식해 버린다."
(원문: "Developers who fully delegated to AI finished tasks fastest but scored worst on evaluations. The novices who benefit most from AI productivity are exactly the ones who need debugging skills to supervise it, and AI erodes those skills first." 출처: https://tomwojcik.com/posts/2026-02-15/finding-the-right-amount-of-ai/)
그는 이것을 "리뷰 패러독스"라고 불렀다. AI가 많이 쓸수록, 그것을 리뷰할 자격이 줄어든다. 그리고 이 둘은 분리할 수 없다. 좋은 결과물을 알아보는 눈은, 좋은 결과물에 대한 글을 읽어서 생기는 게 아니다. 직접 서툴게 해보고, 선배에게 깨지고, 수년간의 실전을 통해 감각을 쌓아야 생긴다.
이 주제는 최근 개발자 커뮤니티에서 뜨겁게 다뤄지고 있다. 하지만 나는 나머지 사람들, 즉 사무직과 비개발 직군에 대해 이야기하고 싶다.
생각해 보면 이렇다. AI가 실제 실행 업무의 대부분을 해주기 시작하면, 우리에게 남는 것은 무엇인가? 리뷰, 관리, 기획, 전략이다. 멋지게 들린다. 하지만 우리는 그 일들을 애초에 어떻게 배웠는가? 허드렛일을 직접 하면서 배웠다. 이전 직장에서 윗사람에게 깨지면서 배웠다. 실수를 하고 교정을 받으면서 배웠다. 결과물을 리뷰할 수 있는 판단력은, 그 일을 직접 수백 번 해봤기 때문에 생긴 것이다.
그것을 빼앗기면 어떻게 되는가. AI가 실행을 하고, 나는 결과물만 리뷰한다. 하지만 좋은 결과물이 어떤 것인지를 판단할 근육이 없다. 그리고 가장 무서운 점은, 자신이 점점 둔해지고 있다는 것을 전혀 알아채지 못하고 있다는 것이다.
여기서 흥미로운 흐름이 있다. 개발자 커뮤니티에서는 실제로 이 문제를 풀려는 움직임이 시작되고 있다. 핵심 원칙은 이렇다. 코드를 리뷰하지 말고, 스펙과 아키텍처를 리뷰하라.
무슨 뜻인가. 코드가 작성되기 전에 제대로 된 스펙을 먼저 쓴다. 문제를 명확히 정의하고, 트레이드오프를 이해하고, 비즈니스 언어를 제품 요구사항으로, 제품 요구사항을 기술 아키텍처로 번역한다. 사람은 스펙과 아키텍처, 그리고 검증 계획을 읽고 리뷰한다. 무엇이 만들어지고 있고 왜 만들어지는지를 실제로 이해하는 것이다. 그다음에 AI가 코드를 쓰고, 코드가 스펙을 따르는지를 확인한다. 규정 준수 여부를 확인하는 것은 AI가 잘하는 일이다. 스펙 자체가 맞는지를 판단하는 것은 사람이 해야 할 일이다.
그리고 일부 팀에서는 이것을 의무화하고 있다. 실제로 강제하고 있다. 솔직히, 강제하지 않으면 아무도 안 한다. 다들 AI와 바이브로 작업하다가 나오는 대로 그냥 올려버리니까.
그렇다면 왜 굳이 그래야 하는가? AI가 일을 해주고 코드가 잘 돌아가면, 사람이 뭘 이해해야 하는가?
이해하지 않으면, 매일 조금씩 둔해지고 있는데 그것을 모르게 된다. 하지만 스펙과 아키텍처 레벨에서 제대로 개입하면, 오히려 이 상황이 더 좋아진다. 기계적인 실행이 아닌, 가장 중요한 부분에 시간을 쓰게 되기 때문이다.
이것을 완벽하게 요약하는 말이 있다. "소프트웨어 엔지니어링은 코드를 타이핑하는 것이 전부가 아니었다. 문제를 잘 정의하고, 문제를 이해하고, 비즈니스에서 제품으로, 제품에서 코드로 언어를 번역하고, 모호함을 해소하고, 트레이드오프를 결정하고, 무엇을 바꾸면 무엇이 깨지는지를 이해하는 것이다."
(원문: "Software engineering was never just about typing code. It's defining the problem well, understanding the problem, translating the language from business to product to code, clarifying ambiguity, making tradeoffs, understanding what breaks when you change something.")
여기서 "소프트웨어 엔지니어링"을 아무 지식 노동으로 바꿔도 그대로 성립한다.
한 가지 더 최근 발견한 것이 있다. 클로드에 "Learning"이라는 설정이 있는데, 답을 바로 주는 대신 질문을 주고받으면서 실제로 가르쳐주는 방식이다. 몇 달 전이었으면 이걸 보고 "물어보지 말고 그냥 해줘"라고 생각했을 것이다. 하지만 지금은 완전히 이해가 된다. 핵심이 판단력과 이해력을 계속 키우는 것이라면, 답을 그냥 받아먹는 것이야말로 최악의 방법이다.
사실 나는 예전부터 브런치에 글을 쓰는 이유가 비슷했다. 누군가에게 공유하기 위해서라기보다, 스스로 깊이 이해하기 위해서였다. 글을 쓰려면 어느 정도 깊게 이해하고 있어야 한다. 모르는 게 많다고, 배워야 할 게 무진장 많다고 늘 생각해왔기 때문에, 영감을 받은 상황이나 주제에 대해 글을 쓰는 것이 나만의 학습 방법이었다. AI 시대에 블로그는 AI가 찍어낼 수 있다. 하지만 내가 이렇게 손수 쓰는 이유는 (물론 클로드의 도움을 받지만) 아마 그 때문인 것 같다. 누가 시킨 게 아니라, 그냥 나만의 리뷰 근육을 키우는 방법인 것이다.
그래서 하나 질문을 던져본다. 요즘 AI 기반 업무에서 어떤 접근이 맞는 것일까?
A. 사람이 직접 코드와 문서의 품질을 리뷰해야 한다.
B. AI가 스펙과 아키텍처 준수 여부를 확인하고, 사람은 스펙과 아키텍처를 리뷰한다.
C. AI는 코드와 문서만 작성하고, 검증에는 절대 사용하지 않는다.
D. 스펙 같은 건 건너뛰고 빠르게 내보내는 게 중요하다.
앞으로 AI 시대에서 학습하는 역량은 어떻게 잘 키울 수 있을까? 특히 옛날처럼 선배나 동료가 옆에서 깨부숴주고 지도해주는 환경이 점점 없어진다면?