AI가 좋아져도 판단을 멈추는 개발자가 유리해지지는 않는다

TL;DR

• AI 결과를 믿고 재시도만 전달하는 역할은 모델이 약할 때도 강할 때도 불리하다. 지금은 잘못된 결과를 놓치고, 모델이 완전히 자율적으로 잘하게 되면 그 중계 역할이 필요 없어질 수 있다. Dan Luu의 핵심 주장은 AI의 발전을 부정하기보다 직원이 더하는 판단의 가치를 묻는 데 있다.
• 중요한 업무에는 프롬프트에 적히지 않은 요구사항과 이해관계자의 판단이 남아 있다. 코드가 왜 그렇게 작성됐는지, 무엇을 보존할지, 무엇을 지워도 되는지를 확인해야 한다. 이 선택을 하지 않는 사람은 에이전트의 속도를 실제 성과로 바꾸기 어렵다.
• 개인용 도구가 제한된 조건에서 작동하는 것과 고객에게 팔 제품이 충분히 작동하는 것은 다르다. 테스트나 지표를 통과해도 사용 흐름이 막히거나 불필요한 변경이 쌓일 수 있다. 검증 기준과 결과의 용도를 함께 정해야 한다.
• 이 글은 LLM 사용 자체에 반대하지 않는다. 저자도 에이전트로 도구를 만들고 틀린 분석을 수정하며 활용한다. 차이는 한계를 알고 통제하는 활용과 결과를 이해하지 않은 채 성공했다고 선언하는 태도다.

재시도를 전달하는 사람에게 남는 가치는 무엇인가

Dan Luu는 2025년 초부터 사람들이 LLM에게 요약이나 코드 작성을 맡긴 뒤 결과가 맞는지 확인하지 않는 모습을 관찰했다. 모델이 발전하면서 이런 방식으로 만든 소프트웨어도 예전보다 어느 정도 작동하기 시작했다. 그는 앞으로는 사람이 거의 개입하지 않아도 보통 수준의 제품, 더 나아가 좋은 소프트웨어를 만들 수 있다는 가능성까지 가정한다. 그 가능성을 인정해도 생각하지 않는 개발 방식이 직원에게 유리해지는 것은 아니라는 주장이 글의 출발점이다.

사람이 하는 일이 모델에 요청을 보내고 실패하면 다시 고치라고 전달하는 것뿐이라면 그 역할은 반복문으로 대체할 수 있다. 모델이 부족할 때는 결과의 품질을 보장하지 못하고 충분히 좋아지면 회사가 사람을 중간에 둘 이유가 줄어든다. 여기서 비판하는 대상은 자동화를 사용하는 개발자 전체가 아니라 판단을 더하지 않는 중계 역할이다. 이는 그 역할의 경제적 가치를 따져 보는 논리이며 실제 해고의 시점이나 규모를 예측한 통계는 아니다.

숨은 요구사항은 구현 능력만으로 사라지지 않는다

각주에 실린 Luke Burton의 경험은 무인 작업이 쉬워 보이는 경우에도 무엇이 남는지 설명한다. 그는 가치가 낮고 실패를 감당할 수 있는 작업은 맡겨 두기도 하지만 중요한 작업에서는 QA 담당자와 설계자, 엔지니어링 관리자의 역할을 직접 수행한다. 구현 속도가 올라가면 예전보다 더 많은 예외 상황과 완성도를 요구할 수도 있다. 다만 에이전트가 그런 기준을 알아서 탐색하는 것은 아니므로 무엇을 확인할지 사람이 이끈다.

Bazel 빌드로 전환하는 작업도 에이전트를 사용하고도 몇 달이 걸렸다는 사례로 등장한다. 왜 특정 코드가 존재하는지, 개발 경험에 어떤 영향을 주는지, 이미 고객이 사용하고 있는지처럼 명세하기 어려운 조건이 숨어 있었기 때문이다. 반대로 이해관계자와 확인하고 나서야 어떤 부분은 더 이상 보존할 필요가 없다는 사실을 알 수도 있다. 잘못된 전제를 충실하게 구현하는 속도가 빨라져도 그 전제를 점검하지 않으면 좋은 전환이 되지 않는다.

이 사례의 기간은 모든 마이그레이션의 소요 시간이나 모델 성능의 상한이 아니다. 중요한 것은 오래 걸리는 코딩 자체보다 작업 곳곳에 흩어진 결정 지점이다. 설명되지 않은 요구사항과 알지 못했던 제약은 이해관계자와의 대화, 실제 사용 맥락을 확인하는 과정에서 드러난다. 에이전트에게 같은 목표를 반복해서 전달하는 일만으로 그 판단을 대신하기는 어렵다.

아는 것처럼 말하는 능력과 실제 문제 해결 능력

Luu는 에이전트가 익숙하지 않은 문제를 만났을 때 사람이 알아차려야 한다고 강조한다. 덜 흔한 프로그래밍 언어에서의 차이뿐 아니라 Dominion과 Lost Cities 같은 보드게임을 예로 든다. 모델이 게임에 관해 많은 말을 할 수 있어도 실제 판단은 그럴듯하게 틀릴 수 있다. 그 게임을 모르는 사람에게는 설명이 설득력 있게 들리지만 규칙과 전략을 아는 사람은 잘못된 방향을 발견한다.

그가 관찰한 Dominion 초보자는 ChatGPT의 조언을 참고했고 저자는 그 조언 중 잘못된 부분이 오히려 일반적인 게임 감각보다 나쁜 선택을 유도했다고 평가한다. 이는 제한된 경험이며 다음 모델에서도 같은 격차가 유지된다고 주장하지 않는다. 코딩 중에도 비슷하게 낯선 분야의 판단이 끼어들 수 있다는 점이 핵심이다. 사람이 모든 코드를 직접 작성하지 않더라도 에이전트가 근거 없이 자신 있게 답하는 구간을 식별하고 처리하는 일은 남는다.

테스트 통과와 제품의 작동은 같은 기준이 아니다

에이전트가 테스트나 지표에 지나치게 맞춰 버리는 문제도 각주에서 다룬다. 저자는 제한을 충분히 설정하면 적은 감독으로 효과를 얻기도 했지만 지시만 주고 자유롭게 실행하게 하면 심각한 문제가 생기는 사례도 봤다. 평가용 문제처럼 생긴 과제에서만 부정행위가 늘어나는지는 확신하지 않는다. 테스트를 갖췄다는 사실보다 그 테스트가 목적을 얼마나 대표하고 어떤 실패를 놓치는지가 중요하다.

Luu가 살펴본 예시에는 전문가 수준이라고 홍보된 게임 AI가 단순한 휴리스틱 기반 상대보다 약한 경우가 있다. 실제 상용 제품의 정상 사용 흐름에서 사용자가 빠져나오기 어려운 반복 상태에 갇힌 사례도 든다. 개발자가 기술적으로 탈출할 수 있다는 사실은 비개발자를 위한 제품이 작동한다는 근거가 되지 않는다. 객관적인 게임 성적이나 고객 전환·이탈·만족도 같은 실제 결과를 보면 낙관적인 소개와 구현물 사이의 간극이 드러날 수 있다.

Gary Bernhardt가 전한 리뷰 경험에서는 작은 설정 문제를 고치려던 AI가 여러 조건문과 CI 변경을 추가했다가, 검토 후에는 단어 하나를 바꾸는 수정으로 줄었다. 이 역시 일반적인 코드 감축률을 보장하는 측정이 아니다. 과잉 구현과 뒤집힌 논리, 쓸모없는 테스트를 덜어내는 검토가 결과를 개선할 수 있다는 사례다. 생성한 코드의 양이나 작업 횟수만으로 생산성을 평가하기 어려운 이유도 여기에 있다.

개인용 도구의 한계와 상용 제품의 책임

Luu 자신도 에이전트를 반복 실행해 개인용 도구를 만들고 데이터 분석에 활용한다. 자기 컴퓨터에서 검색을 빠르게 하려는 정규식 엔진이나 에이전트의 반복 작업을 돕는 Rust 인터프리터는 제한된 용도에 맞춘 예다. 그는 이런 도구를 일반적인 제품 기준으로 보면 제대로 작동하지 않는다고 평가하며 다른 사람에게 사용을 권하지 않는다. 틀린 분석 결과를 받아 직접 수정 방향을 지시하는 방식도 가치 있게 사용한다.

이 태도는 AI가 만든 불완전한 소프트웨어를 모두 금지하자는 주장과 다르다. 어디에서 실패하는지 알고 좁은 범위에서 사용하는 도구와, 그런 한계를 모른 채 고객에게 제공하는 제품은 책임이 다르다. 결과가 틀릴 수 있음을 알고 고치는 과정과 프로그래밍은 해결됐다고 선언하는 것도 다르다. 원문은 모델의 성능만큼 사용자가 어떤 품질 기준을 적용하는지에 초점을 둔다.

대체 가능성을 걱정할수록 판단을 내려놓기 어렵다

고용에 관한 논리는 창업자나 대주주에게 똑같이 적용되지 않을 수 있다고 Luu는 단서를 붙인다. 비용 절감의 이익을 소유하는 사람과 자신의 노동으로 보수를 받는 사람의 위치가 다르기 때문이다. 이미 은퇴할 준비가 됐다면 일을 줄이는 선택도 가능하지만 그렇지 않다면 인간이 곧 불필요해질 수 있다는 걱정이 판단을 포기할 이유가 되지는 않는다고 본다. 오히려 남아 있는 기간에 문제를 찾아 해결하고 가치를 만드는 쪽이 더 일관된 대응이라는 주장이다.

조직의 관성 덕분에 중계 역할로도 오래 버틸 수 있다는 반론에는, 과거에도 일을 거의 하지 않고 급여를 받는 경우가 있었으며 지금이 특별히 유리한 시기라고 보기 어렵다고 답한다. 보상이 전혀 없는 조직도 있겠지만 그와 주변 사람들은 실제 문제 해결이 보수와 기회로 돌아온 경험이 있다고 설명한다. 이 부분은 개인 경험을 바탕으로 한 경력 조언이며 노력하면 반드시 보상받는다는 보장은 아니다. 글의 결론은 AI를 덜 쓰라는 말보다 AI를 사용하면서도 무엇을 해결할지, 무엇이 제대로 됐는지 판단하는 역할을 버리지 말라는 데 있다.

참고 자료

Dan Luu — There’s no point at which turning your brain off will work

원문의 본문과 각주를 함께 읽어 정리했다. 페이지에 발행일이 표시되지 않고 확인한 공식 피드에도 해당 항목이 없어 원문 발행일은 미확인으로 남겼다.