Simon Willison — AI가 개발자를 대체하지 못하는 진짜 이유

원문: https://simonwillison.net/2026/Jun/14/why-ai-hasnt-replaced-software-engineers/ | Simon Willison, 2026년 6월 14일

참고 글: https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers | Arvind Narayanan·Sayash Kapoor, 2026년 6월 11일

커뮤니티 반응: https://news.ycombinator.com/item?id=48487540

핵심 요약

Simon Willison은 Arvind Narayanan과 Sayash Kapoor의 글을 소개하며, AI가 코드 작성 속도를 높여도 소프트웨어 엔지니어의 핵심 가치는 여전히 문제와 해법을 깊이 이해하는 능력에 달려 있다고 짚는다. 원문의 핵심은 AI가 개발 업무의 실행 계층을 압축하지만, 무엇을 만들지 결정하고 결과를 검증하며 책임지는 계층은 쉽게 사라지지 않는다는 것이다. Hacker News의 반응은 이 주장에 상당히 공감하면서도, 임금 하락·채용 둔화·주니어 기회 축소 같은 현실적 위험을 더 크게 봐야 한다는 반론을 함께 보여준다.

“코드를 쓰는 일”과 “소프트웨어를 납품하는 일”은 다르다

AI가 개발자를 대체할 것이라는 주장은 대개 코드 생성 능력에서 출발한다. 오늘의 코딩 에이전트는 함수 초안, 테스트 코드, 마이그레이션 스크립트, UI 컴포넌트 같은 산출물을 빠르게 만든다. 그래서 “코드의 대부분을 AI가 작성한다면 개발자는 왜 필요한가”라는 질문이 자연스럽게 나온다.

Willison이 주목한 Narayanan·Kapoor의 반론은 이 질문의 전제가 틀렸다는 데 있다. 소프트웨어 엔지니어링은 키보드로 코드를 입력하는 활동만이 아니라, 모호한 요구를 해석하고, 시스템의 제약을 이해하고, 실패했을 때 책임질 수 있는 형태로 결과를 통합하는 일이다. AI가 잘하는 부분은 이 중 실행 계층이다. 그러나 실행이 빨라졌다고 해서 결정과 검증이 동시에 사라지지는 않는다.

이 구분은 개발 현장의 체감과도 맞닿아 있다. AI로 코드 작성 시간이 줄어들면 곧바로 하루 전체가 절약될 것 같지만, 실제로는 리뷰해야 할 산출물, 더 빠르게 생겨나는 대안, 새로 확인해야 할 엣지 케이스가 함께 늘어난다. 도구가 쉬워질수록 질문은 “이 코드를 만들 수 있는가”에서 “이게 지금 만들 올바른 것인가”로 이동한다. 이 이동이 바로 엔지니어의 역할을 없애기보다 재배치하는 힘이다.

대량 해고 서사는 왜 매력적인가

원문은 최근 기업들이 AI를 layoffs의 명분으로 내세우는 현상을 “AI washing”에 가깝게 본다. 회사가 비용 압박, 팬데믹 시기 과잉 채용, 투자자 요구, 조직 계층 정리 같은 이유로 구조조정을 하면서 AI를 앞세우면, 이야기가 훨씬 그럴듯해진다. 시장도 그런 설명을 좋아한다. “우리는 뒤처져서 줄이는 것이 아니라 AI로 더 똑똑해져서 줄인다”는 말은 경영진에게 유리한 프레임이기 때문이다.

하지만 저자들이 제시하는 데이터는 더 느리다. 뉴욕주의 WARN Act 신고에서 AI 관련 체크가 거의 없었다는 사례, AI 구현 전 “예상”만으로 인력 감축을 말하는 경영진 설문, 소프트웨어 고용이 둔화됐지만 붕괴하지는 않았다는 연구가 함께 등장한다. 이 논지는 AI의 영향이 없다는 뜻이 아니다. 영향은 해고보다 채용 속도, 직무 구성, 생산 방식, 회사 내부 권력 구조를 통해 더 천천히 나타날 가능성이 크다는 뜻이다.

이 관점은 경제적으로 더 설득력이 있다. 기존 직원을 해고하면 조직 지식과 시스템 맥락도 함께 사라진다. 그런데 AI 도구를 효과적으로 쓰려면 바로 그 맥락이 필요하다. 큰 코드베이스에서 “왜 이렇게 되어 있는지”를 모르는 사람이 에이전트만으로 안전하게 변경을 밀어 넣기는 어렵다. 따라서 합리적인 회사라면 갑작스러운 대체보다 자연 감소, 신규 채용 조정, 역할 재설계를 먼저 택할 가능성이 높다.

Decide-Execute-Deliver라는 샌드위치

Narayanan·Kapoor가 제안한 가장 유용한 틀은 소프트웨어 개발을 결정, 실행, 전달의 샌드위치로 보는 것이다. 가운데의 실행은 코드 작성, 구현, 반복 생성에 해당한다. AI는 이 부분을 강하게 압축한다. 반면 위쪽의 결정은 사용자 요구, 사업 우선순위, 규제, 장기 유지보수 비용을 해석하는 일이다. 아래쪽의 전달은 테스트, 검증, 배포, 장애 대응, 책임 소재를 포함한다.

Willison은 여기에 자신의 경험을 덧붙인다. AI는 결정과 검증에도 도움을 주지만, 자신이 제공하는 가치는 여전히 문제와 해법을 얼마나 깊게 이해하느냐에 달려 있다는 것이다. 이 말은 단순한 직업 방어가 아니다. 오히려 AI를 잘 쓰는 사람일수록 이해의 중요성을 더 빨리 깨닫는다는 관찰에 가깝다.

코딩 에이전트를 감독하는 일은 겉보기보다 피곤하다. 에이전트는 빠르게 많이 만든다. 하지만 많이 만든다는 것은 많이 판단해야 한다는 뜻이다. 변경이 요구사항을 만족하는지, 보안상 안전한지, 기존 설계와 충돌하지 않는지, 장애 상황에서 되돌릴 수 있는지 확인해야 한다. AI가 실행 비용을 낮출수록 검증의 병목은 더 선명해진다. 그래서 “AI가 코드를 다 쓴다”는 문장은 “사람이 책임질 검토 대상이 폭증한다”는 문장과 함께 읽어야 한다.

커뮤니티의 반응: 동의보다 중요한 불안

Hacker News에서는 이 글이 300점 이상과 수백 개의 댓글을 모으며 활발하게 논의됐다. 공감하는 쪽은 대체로 “내 일의 중심이 코딩에서 계획, 스펙 작성, 리뷰, 반복 조정으로 이동했다”는 경험을 공유했다. 이는 글의 샌드위치 모델과 잘 맞는다. AI가 실행을 맡아도 엔지니어는 여전히 산출물을 사용할 수 있고 유지 가능한 상태로 만드는 데 시간을 쓴다는 것이다.

반론도 강했다. 어떤 댓글은 결정과 전달도 결국 자동화될 수 있으며, 지금 인간이 남아 있는 이유는 기술 한계보다 조직이 AI에 책임을 물을 수 없기 때문이라고 봤다. 또 다른 반응은 “완전 대체”가 아니어도 충분히 큰 변화가 온다고 지적했다. 남은 개발자들이 더 많은 코드를 처리하게 되면 회사는 예전만큼 많이 채용하지 않을 수 있고, 개발 업무는 더 상품화되어 임금 압박을 받을 수 있다는 것이다.

이 반론은 중요하다. 원문이 반박하는 것은 “능력 임계점을 넘으면 대량 해고가 자동으로 발생한다”는 단순 서사다. 그러나 그것이 “개발자는 아무 영향도 받지 않는다”는 뜻은 아니다. 특히 주니어 개발자에게는 위험이 크다. 과거에는 작은 버그 수정, 단순 CRUD, 내부 도구 작성 같은 일이 학습의 진입로였다. AI가 그 일을 흡수하면, 신입은 더 빨리 고수준 판단을 요구받을 수 있다. 총수요가 유지되더라도 경력 사다리의 아래쪽은 흔들릴 수 있다.

개발자의 미래는 사라짐보다 재분배에 가깝다

이 논의에서 가장 현실적인 결론은 “개발자는 사라지지 않는다”가 아니라 “개발자의 가치가 다른 곳으로 이동한다”이다. 문법 지식, 프레임워크 암기, 반복 구현 능력은 상대적으로 덜 희소해진다. 대신 문제를 잘 자르는 능력, 시스템의 역사와 제약을 이해하는 능력, AI가 만든 결과를 빠르게 의심하고 검증하는 능력, 여러 이해관계자 사이에서 책임 있게 결정을 내리는 능력이 더 중요해진다.

경제적으로는 소프트웨어 수요의 가격 탄력성이 핵심이다. 만들기 쉬워지면 필요한 소프트웨어의 양이 줄어드는 것이 아니라, 오히려 이전에는 비용 때문에 만들지 않았던 내부 도구와 맞춤형 워크플로가 늘어날 수 있다. 그렇게 되면 개발 역량은 빅테크 내부에만 집중되지 않고, 병원, 제조업, 회계법인, 공공기관 같은 비소프트웨어 조직 안으로 더 깊게 퍼질 가능성이 있다.

다만 낙관론에도 조건이 있다. 개발자가 AI를 “타이핑 보조 도구” 이상으로 활용하려면, 더 강한 테스트 문화와 운영 책임, 보안 감각, 제품 판단이 필요하다. AI가 만든 코드를 이해하지 못한 채 승인하는 방식은 단기 생산성처럼 보일 수 있지만, 장기적으로는 장애와 기술부채를 축적한다. 반대로 깊은 이해를 가진 엔지니어가 AI를 사용하면, 실행 속도는 빨라지고 더 많은 실험이 가능해진다.

Willison의 짧은 코멘트가 오래 남는 이유는 여기에 있다. AI가 아무리 좋아져도, 가치의 원천은 “내가 무엇을 만들고 있는지 알고 있는가”라는 질문으로 돌아온다. 개발자에게 필요한 태도는 AI를 과소평가하는 것도, 자신을 자동 대체될 타자수로 축소하는 것도 아니다. 실행은 점점 자동화될 것이다. 그러나 결정과 책임의 층을 두껍게 만들 수 있는 사람에게는 오히려 더 넓은 문제의 연못이 열릴 수 있다.