# ThePrimeagen이 말한 AI 코딩의 효용과 한계

> 2025-03-23 · Lex Fridman · 큐레이션 김태우
> https://challengekim.com/insights/theprimeagen이-말한-ai-코딩의-효용과-한계
> 원문: https://lexfridman.com/theprimeagen-transcript

## 핵심 요약

- ThePrimeagen은 예측 가능하고 자료가 풍부한 작업에서 AI 코딩 도구가 유용하지만, 덜 문서화된 기술이나 복잡한 변경에는 약하다고 평가했다.
- 그는 GitHub Copilot을 쓰면서 생성된 코드를 충분히 생각하지 않고 받아들여 버그를 들인 경험을 말했다. 렉스 프리드먼은 AI 코드를 읽고 수정하는 능력도 별도의 기술이라고 봤다.
- 두 사람은 복잡한 오류를 찾거나 큰 코드베이스의 맥락을 판단할 때 개발자의 검토가 중요하다고 말했다.
- ThePrimeagen은 AI가 발전하더라도 개발자가 여러 계층을 이해하고 더 큰 프로젝트를 다룰수록 결과를 지휘하고 검토하기 좋다고 주장했다.

## AI가 잘하는 작업과 어려워하는 작업

ThePrimeagen은 작업의 **예측 가능성**을 AI 코딩 도구의 효용을 가르는 기준으로 제시했다. 그의 평가에 따르면 널리 쓰이고 문서가 많은 TypeScript에서는 좋은 결과를 내는 반면, 상대적으로 문서가 적은 Zig에서는 그렇지 못하다. 널리 알려진 알고리즘을 작성하는 일은 겉보기의 난도와 달리 AI에 쉬운 요청일 수 있다고도 말했다.

프리드먼은 API를 다루는 기본 코드에서 도움을 받았다고 설명했다. 유튜브 API 문서를 제공하고 읽기·쓰기 함수 작성을 요청하면 빠르게 초안을 만들 수 있다는 것이다. 다만 생성된 코드는 모두 읽고 확인해야 한다고 덧붙였다. 그는 AI가 빈 함수에서 시작하는 부담을 줄여 작업을 끝내는 데도 도움이 됐다고 말했다.

## 코드 생성 속도와 검토 비용

ThePrimeagen은 Copilot 초기 접근 권한을 받아 사용했을 때 조건문을 맞혀 제안하는 모습에 놀랐다고 회상했다. 그러나 사용이 길어지면서 버그를 들이는 일이 반복됐다. 직접 코드를 쓸 때와 남이 작성한 코드를 읽을 때 쓰는 사고 방식이 달랐고, 자신은 제안을 비판적으로 검토하기보다 그대로 받아들이기 쉬웠다는 설명이다. 그는 이를 자신의 도구 사용 방식에서 생긴 문제로 한정했다.

그는 약 6개월 전까지 Copilot을 사용했으며, 다시 Cursor를 집중적으로 써 보려는 생각도 밝혔다. 다만 당시 자신의 작업에서는 생성 결과를 검토하거나 다시 작성하는 데 시간을 써서 절약한 시간이 뚜렷하지 않았다고 말했다. 특히 현재의 함수가 약 2,000줄 뒤에 필요한 작업과 어떻게 이어질지 생각하며 코드를 짤 때, 빠른 생성 과정에서 그 연결을 놓치기 쉬웠다고 설명했다.

프리드먼은 필요한 파일과 요구 조건을 AI에 충분히 제공해야 한다고 강조했다. 반면 ThePrimeagen은 도구의 인터페이스가 크게 개선된다면 지금 익히는 프롬프트 작성 습관이 얼마나 남을지 물었다. 프리드먼은 모델이 바뀌어도 AI에 어떤 정보가 필요한지 파악하고 생성된 코드를 수정하는 경험은 이어질 것이라고 답했다. 두 사람의 견해는 AI 활용법을 익히는 가치에 동의하면서도, 현재의 사용 방식이 얼마나 오래 유효할지에서는 갈렸다.

## 에이전트와 디버깅의 경계

ThePrimeagen은 코드 저장소를 살펴보고 변경·커밋까지 시도하는 AI 에이전트 Devin의 구상에 기대를 보였다. 작은 버그나 밀린 작업을 맡기고 결과를 나중에 검토하는 방식이 가능해지기를 바랐다. 그러나 자신의 사용 경험에서는 요청 범위를 좁힐수록 성공 가능성이 높았고, 요구가 너무 많거나 적으면 결과가 어긋났다. 아이콘 하나를 추가하는 식의 작은 작업에서도 결국 직접 다시 작성한 경우가 있었다고 말했다.

프리드먼은 드물게 발생하는 논리 오류나 경계 조건을 찾는 일이 AI에 특히 어렵다고 평가했다. ThePrimeagen은 AI가 수정까지 맡기보다 큰 코드베이스에서 관련 위치를 찾아주는 검색 도구로 도움을 줄 수 있다고 봤다. 그는 curl 유지관리자가 재현되지 않는 AI 생성 보안 제보를 받는 사례도 언급했다. 코드의 앞선 조건문 때문에 실행될 수 없는 경로를 취약점으로 지목한다면, 그럴듯한 설명만으로는 제보를 확인할 수 없다는 취지다.

## 개발자 역할에 대한 엇갈린 전망

ThePrimeagen은 젊은 개발자에게 어려운 기술을 익히지 말고 AI에 맡기라는 조언을 경계했다. 코드가 커지거나 복잡해질수록 AI가 오류 사이를 오갈 수 있으며, 스스로 판단할 기술이 없다면 해결 능력이 모델의 수준에 묶인다는 주장이다. 그는 개인정보 보호와 모든 사람이 AI를 사용할 때 필요한 연산 자원도 미해결 질문으로 들었다.

그렇다고 개발자의 일이 영원히 같은 형태로 남는다고 단정하지는 않았다. 기술 발전이 계속되면 언젠가 코딩이라는 기술이 불필요해질 수도 있지만, 그 시점을 예측하지 않겠다고 했다. 프리드먼은 자연어가 개발 도구의 일부가 될 가능성을 제시했다. ThePrimeagen은 자연어의 모호성 때문에 더 명확한 중간 언어가 생길 수 있으며, 그 역시 프로그래밍 언어의 또 다른 변화일 수 있다고 봤다.

## 스타트업과 큰 조직의 개발 방식

대담은 AI 밖의 개발 방식에도 닿았다. ThePrimeagen은 1인 개발자 피터 레벨스가 운영 환경에 직접 변경을 반영하는 방식은 작업자와 제품을 한 사람이 잘 아는 조건에서 성립한다고 평가했다. 반면 여러 사람이 같은 제품을 바꾸는 큰 조직이나, 변경의 영향이 다른 곳까지 번지는 복잡한 애플리케이션에는 그대로 적용하기 어렵다고 했다. 그는 제품의 복잡성, 코드의 결합 정도, 참여 인원에 따라 테스트와 배포 방식을 판단해야 한다고 설명했다.

넷플릭스 경험도 조직 규모에 따른 차이를 보여준다. ThePrimeagen은 한 프로그램의 시즌 표시 순서를 바꾸기 위해 여러 팀의 엔지니어 약 20명을 모아야 했다고 회상했다. 데이터 저장부터 서비스 계층, 웹·모바일·TV 화면까지 변경이 이어졌기 때문이다. 그는 조정 권한을 맡아 작업을 나눴고 약 3주가 걸렸다고 말했다. 겉보기에는 작은 기능도 큰 서비스에서는 여러 시스템의 문제라는 설명이다.

AI가 작성하는 코드가 늘어날수록 대담에서 반복된 쟁점은 생성 속도만이 아니었다. 요청에 필요한 맥락을 전달하고, 결과가 실제 문제를 해결하는지 확인하며, 변경이 다른 부분에 미치는 영향을 판단하는 일이 함께 남는다.

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://lexfridman.com/theprimeagen-transcript)