Simon Willison이 인용한 D. Richard Hipp와 AI 일자리 예측에 도전하는 SQL 비유

Simon Willison은 7월 29일 D. Richard Hipp의 SQL 비유를 조명하며, AI가 프로그래머를 없앨 것이라는 예측에 역사적 반론을 직접 제기했다. Hipp의 논지는 과거의 노동 변화에서 출발한다. SQL은 한때 맞춤형 데이터 처리 프로그램으로 수행하던 업무를 자동화했지만, 프로그래밍은 사라지지 않았고 다른 형태로 확장됐다.

이 글은 짧지만, 그 시점은 중요하다. AI 코딩 시스템은 이제 함수, 테스트, 쿼리, 문서화, 그리고 때로는 리포지토리 전반에 걸친 조율된 변경까지 생성한다. 이러한 발전은 사람들이 일상 언어로 소프트웨어를 설명할 수 있게 되면 조직이 훨씬 적은 수의 프로그래머만 필요로 하게 될 것이라는 더 강한 주장을 부추겼다.

Hipp는 덜 극적인 모델을 제시한다. 새로운 추상화는 일부 지시를 표현하는 비용을 낮추고, 인간의 노력을 명세화, 검증, 아키텍처, 유지보수로 옮긴다. SQL은 프로그래밍을 끝내지 않았다. 대신 어떤 문제에 맞춤형 코드가 필요한지, 어떤 문제를 데이터베이스 엔진에 맡길 수 있는지를 바꿨다.

이 비유가 AI가 같은 경로를 따를 것임을 증명하는 것은 아니다. 대규모 언어 모델은 확률적 출력을 생성하는 반면 데이터베이스는 정의된 규칙에 따라 SQL을 실행한다. 그럼에도 이 비교는 소프트웨어 경력에 관한 주장에 유용한 검증 기준을 제공한다. 도구가 엔지니어링 업무를 제거하는가, 아니면 그 업무를 다른 계층으로 옮기는가?

Simon Willison은 인용문을 노동시장 논거로 전환한다

이 소식은 새로운 SQLite 기능이나 AI 제품이 아니다. 자동화 주장을 평가하기 위한 더 날카로운 역사적 틀이다.

Simon Willison은 자신의 7월 29일 게시물에서 SQL이 등장하면서 데이터 업무가 어떻게 바뀌었는지를 설명한 D. Richard Hipp의 말을 인용했다. SQL 이전에는 조직들이 대규모 데이터 세트를 검색, 조인, 필터링, 요약하는 절차적 소프트웨어를 만들기 위해 프로그래머에게 비용을 지불하곤 했다.

Hipp는 다소 단순화해서 그 노동자들을 COBOL 프로그래머로 지칭했다. SQL은 사용자가 간결한 쿼리로 원하는 결과를 지정할 수 있게 했다. 그러면 데이터베이스 엔진이 이전에는 맞춤형 프로그램에 포함됐던 실행 로직의 상당 부분을 생성하거나 선택했다.

Hipp의 비교에서 핵심 문구는 프로그래머가 사라지지 않았다는 점이다. 그들의 일은 바뀌었다.

이 구분은 사소하게 들릴 수 있지만, 현재 AI 인력 전망의 가장 큰 가정 중 하나를 파고든다. 많은 예측은 코드 생산을 프로그래밍 노동의 정의적 단위로 취급한다. 소프트웨어가 코드를 생산할 수 있다면, 과거에 그것을 입력하던 노동자는 불필요해진다는 논리다.

SQL은 코드의 양과 엔지니어링 가치가 같은 것이 아님을 시사한다. 선언형 쿼리는 수많은 줄의 절차적 데이터 처리 코드를 대체할 수 있다. 그러나 누군가는 여전히 데이터를 정의하고, 결과의 의미를 결정하며, 권한을 관리하고, 엣지 케이스를 테스트하고, 성능을 모니터링하고, 요구사항이 충돌할 때 대응해야 한다.

선언형 프로그래밍은 모든 실행 단계를 일일이 명시하지 않고 시스템이 산출해야 할 결과를 지정하는 방식을 뜻한다. SQL은 사용자가 원하는 데이터를 선언하고 쿼리 플래너가 데이터베이스의 검색 방식을 선택한다는 점에서 대표적 사례가 됐다.

Hipp는 이전에도 이 구분을 강조했다. 그는 데이터베이스 프로필에서 많은 개발자가 선언형 언어가 절약할 수 있는 작업량을 과소평가한다고 주장했다. 그는 데이터베이스가 처리할 수 있는 조인을 애플리케이션 코드에서 수동으로 수행하는 사례를 지적했다.

이 관찰은 AI 코딩과 직접 연결된다. 개발자는 이제 모든 문장을 직접 입력하지 않고도 어시스턴트에게 기능 구현을 요청할 수 있다. 이 요청은 SQL 쿼리가 절차적 데이터 작업을 압축하는 방식과 마찬가지로 눈에 보이는 노력을 압축한다.

그 압축은 실제다. 책임이 사라지는 것은 아니다.

SQL 사용자는 올바른 결과를 요청할 책임이 계속 있다. AI 지원 개발자는 생성된 소프트웨어가 의도한 동작과 일치하는지 판단할 책임이 계속 있다. 두 경우 모두 인터페이스는 더 높은 수준으로 올라가지만, 중요한 결정은 사람에게 남는다.

Willison의 선택은 Hipp의 비유에 더 넓은 의미를 부여한다. SQL 역사에 관한 언급을 자연어 코딩이 자동으로 프로그래머 없는 미래를 만든다는 생각에 대한 응답으로 바꾼다.

이 글은 손쉬운 반AI 결론도 피한다. Hipp가 자동화가 아무것도 이루지 못한다고 주장하는 것은 아니다. SQL은 분명 특정 프로그램을 손으로 작성할 필요를 없앴다. 이 비유는 상당한 생산성 향상을 인정하면서도, 생산성에서 직업의 소멸로 곧장 이어지는 경로는 거부한다.

이것이 이 사건의 핵심 긴장이다. 같은 역사는 두 가지 해석을 뒷받침할 수 있다. 자동화는 특정 작업을 없애지만, 동시에 소프트웨어 제작 비용을 충분히 낮춰 소프트웨어 수요를 더 늘리기도 한다.

SQL은 작업의 단위를 바꿨다

SQL은 모든 프로그래밍 작업을 보존하지 않았다. 많은 작업을 경제적으로 불필요하게 만들고, 더 높은 수준의 결정으로 관심을 옮겼다.

관계형 데이터베이스와 널리 채택된 쿼리 언어가 등장하기 전에는 비즈니스 데이터에서 새로운 답을 추출하려면 전용 프로그램이 필요할 수 있었다. 프로그래머는 레코드 레이아웃, 접근 경로, 정렬 루틴, 파일 형식, 보고 요건을 이해해야 했다.

질문에 작은 변화가 생겨도 또 다른 프로그램이나 상당한 수정이 필요할 수 있었다. 조직은 단순한 결과가 아니라 절차에 비용을 지불했다.

SQL은 이 구성을 바꿨다. 사용자는 선택, 조인, 그룹화, 정렬을 통해 결과를 기술할 수 있었다. 데이터베이스는 그 요청을 실행 계획으로 변환했는데, 이는 요청된 데이터를 반환하기 위해 사용되는 작업의 집합이다.

Hipp의 비유는 그가 인용문의 틀을 통해 인정하듯 긴 기술 역사를 압축한다. SQL이 등장했다고 COBOL이 사라진 것은 아니다. COBOL 시스템은 계속해서 급여, 은행, 보험, 정부, 트랜잭션 처리 업무를 수행했다.

중요한 변화는 더 좁은 범위에 있었다. 조직은 관계형 쿼리로 표현할 수 있는 일반적인 질문마다 새로운 절차적 프로그램을 만들 필요가 더는 없었다.

이는 작업 수준에서 의미 있는 일자리 대체 형태다. 도구는 그 작업을 포함하는 직업을 없애지 않고도 전문 구현에 소요되는 시간을 제거할 수 있다.

AI 논쟁에서는 직업과 작업의 구분이 흔히 사라진다. 직업은 활동, 책임성, 도메인 지식, 커뮤니케이션, 결정이 묶인 집합이다. 자동화가 그 묶음의 모든 부분에 같은 속도로 도달하는 경우는 드물다.

SQL은 쿼리 실행을 자동화했지만, 데이터베이스 관리, 스키마 설계, 쿼리 최적화, 데이터 모델링, 분석, 보안, 애플리케이션 통합에 대한 수요를 만들었다. 또한 더 많은 팀이 데이터에 실질적으로 접근할 수 있게 했다.

Hipp는 SQL의 지속적인 가치를 트랜잭션, 데이터 추상화, 선언형 언어라는 세 가지 개념으로 설명해 왔다. 그는 2024년 SQLite 인터뷰에서 관계형 모델이 많은 현실 세계의 문제를 표현하는 데 여전히 효과적이라고 말했다.

트랜잭션은 관련된 데이터베이스 작업이 통제된 일관성 규칙 아래 완료되도록 보장한다. 데이터 추상화는 논리적 요청을 물리적 저장 세부 사항과 분리한다. 선언형 언어는 사용자가 원하는 답에 집중할 수 있게 한다.

이 역량들은 함께 단순히 키 입력을 줄이는 데 그치지 않았다. 애플리케이션 프로그래머, 데이터베이스 엔진, 데이터베이스 전문가, 비즈니스 사용자 사이의 전문성을 재분배했다.

AI 코딩 어시스턴트도 메커니즘은 다르지만 비슷한 재분배를 시작하고 있다. 이들은 의도를 코드로 번역하고, 낯선 리포지토리를 검색하며, 테스트를 제안하고, 레거시 함수를 설명하며, 마이그레이션이나 문서화 초안을 만들 수 있다.

이러한 역량이 개선되면서 팀은 일상적인 구현 코드를 작성하는 데 드는 시간을 줄이게 될 것이다. 이 결과를 완화해서 말해서는 안 된다. 일부 초급 작업, 유지보수 과제, 외주 코딩 업무는 직접적인 압박을 받게 될 것이다.

그러나 절약된 노력만으로 전체 고용에 어떤 일이 일어나는지는 알 수 없다. 원하는 산출량이 고정돼 있으면 생산 비용 하락은 노동 수요를 줄일 수 있다. 더 저렴한 생산이 훨씬 많은 프로젝트를 가능하게 한다면 노동 수요는 늘어날 수 있다.

소프트웨어는 고정된 시장처럼 작동한 경우가 드물다. 팀은 엔지니어링 역량이 제한돼 있기 때문에 긴 백로그를 유지하고, 내부 도구를 미루며, 수작업 워크플로를 감수하고, 통합을 연기한다. AI가 이러한 프로젝트의 비용을 낮춘다면 조직은 더 많은 프로젝트를 만들 수 있다.

따라서 SQL의 선례는 동시에 두 가지 효과를 제시한다:

• 대체: 시스템이 이전에는 프로그래머에게 배정됐던 작업을 수행한다.

• 확장: 비용 하락으로 추가적인 소프트웨어 및 데이터 작업이 경제적으로 가치 있게 된다.

• 재구성: 남은 역할에서 판단, 설계, 검토, 도메인 지식의 비중이 커진다.

이 효과들이 모든 기업에서 동일하게 균형을 이루지는 않을 것이다. 안정적인 제품과 고정된 로드맵을 가진 기업은 AI를 활용해 채용을 줄일 수 있다. 성장 중인 기업은 더 많은 기능을 출시하면서 인력을 유지할 수 있다. 소규모 조직은 이전에는 감당할 수 없었던 소프트웨어 개발을 시작할 수 있다.

이러한 차이 때문에 “프로그래머”에 대한 광범위한 주장은 설득력이 약하다. 자동화는 특정 조직 내부의 특정 작업에 도달한다. 고용 효과는 수요, 예산, 위험, 그리고 새롭게 만들어지는 업무의 양에 따라 달라진다.

진정한 대립은 작업 자동화와 직업 소멸 사이에 있다

Hipp의 주된 문제 제기는 AI 코딩 도구를 향한 것이 아니다. 코드 생성을 자동화하면 엔지니어링 역할 전체가 사라진다는 가정을 겨냥한다.

생성된 함수는 완성된 작업처럼 보일 수 있다. 빠르게 도착하고, 유리한 경우 컴파일되며, 모델에 제공된 테스트를 통과할 수도 있다. 이 눈에 보이는 산출물은 사람들이 구현을 전체 소프트웨어 생명주기와 동일시하도록 부추긴다.

프로덕션 엔지니어링에는 훨씬 더 많은 것이 포함된다. 누군가는 모호한 요청을 정확한 동작으로 바꿔야 한다. 그 사람은 이해관계자 간의 충돌을 해결하고, 누락된 요구사항을 찾아내며, 시스템 경계를 선택하고, 데이터를 보호하며, 어떤 실패가 허용되는지 결정해야 한다.

팀은 원래의 맥락이 바뀐 뒤에도 결과물을 유지해야 한다. 의존성은 업데이트된다. 규제가 바뀐다. 사용자는 예상치 못한 워크플로를 발견한다. 공격자는 취약점을 찾는다. 데이터 규모는 첫 버전에 내장된 가정을 넘어 커진다.

AI는 각각의 활동을 지원할 수 있지만, 지원이 자동으로 책임성을 이전하지는 않는다. 생성된 코드가 보안 사고를 일으킬 때 고객과 규제 기관은 모델을 책임 있는 운영자로 취급하지 않는다.

SQL 비교는 이 경계를 더 쉽게 보여준다. 데이터베이스 엔진은 실행 계획을 선택할 수 있지만, 쿼리가 올바른 비즈니스 질문에 답하는지는 결정하지 않는다. 기술적으로 유효한 조인이 오해를 부르는 지표를 만드는지 판단할 수도 없다.

마찬가지로 AI 어시스턴트는 명세가 조직의 실제 요구를 반영하는지 알지 못한 채 구현을 생성할 수 있다. 구현이 더 자동화될수록 명세의 품질은 결과를 더 크게 좌우한다.

여기에는 중요한 역전이 있다. 자연어는 코드보다 쉬워 보이지만, 일상 언어는 소프트웨어가 안전하게 무시할 수 없는 모호함을 허용한다.

“자동 세금 처리를 추가하라”는 말은 시스템이 관할권, 면제, 환불, 반올림 규칙, 적용일, 불완전한 고객 데이터를 다뤄야 하는 상황이 되기 전까지는 명확해 보인다. 전통적으로 인간 엔지니어는 설계와 구현 과정에서 이러한 세부 사항을 발견하고 형식화한다.

AI 에이전트가 코드를 작성하더라도 이런 질문들이 사라지는 것은 아니다. 프롬프트, 명세, 테스트, 정책 문서, 리뷰 세션, 혹은 프로덕션 장애로 옮겨갈 뿐이다.

2026년 6월 codeless future에 대한 분석도 비슷한 주장을 제기했다. 이 글은 AI를 프로그래밍 추상화의 또 다른 단계로 설명하면서, 표현 형식과 무관하게 정밀한 명세는 여전히 코드 역할을 한다고 지적했다.

Hipp의 SQL 비유가 가장 설득력 있는 지점은 여기다. SQL이 성공한 이유는 선언적 범위가 제한돼 있기 때문이다. 데이터베이스는 형식적 의미론 아래에서 테이블, 관계, 조건식, 그룹화, 정렬, 트랜잭션을 이해한다.

일반적인 소프트웨어 요구사항에는 이와 같은 경계가 주어지지 않는다. 기술적 동작에 정책, 미학, 조직의 인센티브, 법적 의무, 그리고 이해관계자가 한 번도 명시하지 않을 수 있는 가정이 뒤섞인다.

AI 코딩 에이전트는 누락된 세부사항을 추론할 수 있다. 이 유연성은 유용하지만 위험도 수반한다. 추론된 요구사항은 그럴듯하면서도 틀릴 수 있다.

SQL 엔진도 특히 통계, 인덱스, 워크로드 가정이 부실할 때 바람직하지 않은 실행 계획을 만들 수 있다. 그래도 그 결과는 결정론적인 데이터베이스 의미론의 지배를 받는다. 대규모 언어 모델은 유사한 프롬프트에서도 서로 다른 구현을 생성할 수 있으며, API나 가정을 지어낼 수도 있다.

따라서 AI 코딩은 단순히 “모든 소프트웨어를 위한 SQL”이 아니다. 더 느슨하면서도 훨씬 야심 찬 인터페이스다.

이 비유는 두 기술 모두 구현 노력을 압축한다는 점에서 경제적 차원에서는 성립한다. 그러나 범용 코드 생성은 출력 공간이 훨씬 크기 때문에 신뢰성 차원에서는 설득력이 약해진다.

이 차이는 검증의 가치를 높인다. 개발자에게는 의미 있는 동작을 포괄하는 테스트, 보안성과 유지보수성을 점검하는 리뷰 관행, 그리고 배포 후 장애를 드러내는 관측 가능성이 필요하다.

팀에는 지속 가능한 맥락도 필요하다. 요구사항, 아키텍처 결정, 장애 이력, 도메인 제약은 에이전트나 엔지니어가 시스템을 변경할 때도 계속 접근 가능해야 한다. 검색 가능한 technical knowledge base는 특히 생성된 변경사항이 낯선 리포지터리에 걸쳐 있을 때 이러한 작업을 뒷받침할 수 있다.

그 결과 역할에서 수동 코드 입력의 비중은 줄어들 수 있다. 그래도 형식화, 검증, 트레이드오프, 책임 소유가 필요하다는 점에서 여전히 엔지니어링에 가깝다.

SQL 비유가 무너지는 지점

SQL은 유용한 노동 변화의 선례를 제공하지만, AI가 얼마나 빠르게 개선될지 또는 기업이 얼마나 많은 프로그래밍 직무를 유지할지는 보여주지 못한다.

역사적 비유는 유사점을 선택하는 대신 차이점을 숨긴다. SQL은 특정 데이터 연산군을 위해 설계됐다. 그 문법과 의미론은 쿼리를 작성하는 사람과 이를 실행하는 데이터베이스 사이에 안정적인 계약을 만들었다.

AI 코딩 시스템은 변화하는 언어, 프레임워크, 리포지터리, 인터페이스, 비즈니스 도메인 전반에서 작동한다. 불완전한 문서와 모순되는 관례를 자주 마주한다. 이들의 과업은 형식 모델 안에서의 최적화에 그치지 않는다.

이처럼 넓은 범위는 AI를 SQL보다 경제적으로 더 중요한 존재로 만들 수 있다. 리포지터리를 탐색하고, 여러 서비스를 수정하고, 테스트를 실행하고, 실패에 대응하는 에이전트는 쿼리 플래너보다 개발 워크플로의 더 많은 부분을 다룬다.

동일한 범위는 신뢰할 수 있는 자동화를 더 어렵게 만들 수도 있다. 제한된 벤치마크에서의 성공이 장기간 운영되는 프로덕션 시스템 내부에서의 안전한 성능을 보장하지는 않는다.

생성된 변경사항은 단위 테스트를 통과하면서도 문서화되지 않은 운영 가정을 위반할 수 있다. 리포지터리에 이미 존재하는 안전하지 않은 패턴을 반복할 수도 있다. 눈에 보이는 티켓은 해결하지만 미래 유지보수 비용을 늘릴 수도 있다.

인간 개발자도 이런 실수를 한다. 중요한 질문은 AI가 그 실수의 빈도, 탐지 가능성, 규모를 어떻게 바꾸는가다.

속도는 좋은 결과물과 나쁜 결과물 모두를 증폭시킬 수 있다. 팀이 변경사항을 다섯 배 더 많이 만든다면, 변경당 오류율이 더 낮더라도 전체 리뷰 작업은 늘어날 수 있다. 반대로 강력한 자동화 테스트는 장애를 늘리지 않고도 팀이 산출량을 확대하게 할 수 있다.

이 불확실성은 양측의 확신에 찬 예측을 약화한다. SQL이 프로그래밍 일자리를 없애지 않았다는 이유만으로 그 일자리가 안전하다고 선언하기에는 이르다. 인상적인 코드 생성 시연을 근거로 대규모 일자리 소멸을 추론하는 것도 마찬가지로 이르다.

완전 자율 코딩에 관한 Hipp 자신의 공개 발언도 신중한 입장을 보여준다. 그는 2024년 인터뷰에서 AI가 유용하지만 과대평가됐으며, 완전 자동 코드 생성보다 보조형 코딩이 더 가능성이 높아 보인다고 말했다.

이 전망은 측정된 결과가 아니라 하나의 관점에 불과하다. AI 역량과 제품 설계는 계속 바뀌고 있으며, 조직은 통제된 개발 프로세스 안에서 에이전트를 배치하는 방법을 아직 배우는 중이다.

직무 범주는 더 작아지거나 진입하기 어려워지면서도 존속할 수 있다. 은행은 여전히 COBOL 전문가를 고용하지만, 그렇다고 COBOL이 예전과 같은 경력 경로를 제공한다는 뜻은 아니다. 기술은 중요한 전문성을 보존하면서도 일상 업무를 수행하는 사람의 수는 줄일 수 있다.

주니어 역할은 특히 주목할 필요가 있다. 시니어 엔지니어는 흔히 작은 버그 수정, 단순한 통합, 테스트 작성, 감독 아래의 기능 개발을 통해 배웠다. 바로 그런 작업이 현재의 코딩 어시스턴트가 잘 처리하는 영역이다.

기업이 교육 방식을 재설계하지 않은 채 이 작업을 자동화하면, 미래의 시니어 엔지니어를 길러내는 파이프라인을 약화할 수 있다. SQL은 새로운 전문 분야를 만들었지만, 기본 구현을 예전만큼 자주 연습하지 않는 사람들 사이에서 AI 중심 팀이 어떻게 판단력을 길러야 하는지에는 답하지 못했다.

또 다른 불확실성은 조직의 행동과 관련된다. 생산성 향상이 반드시 추가 소프트웨어 생산으로 이어질 필요는 없다. 경영진은 이를 인력 축소, 더 높은 산출 목표, 더 짧은 일정, 혹은 그 조합으로 흡수할 수 있다.

분배 방식은 기술 역량만큼 중요하다. 개발자는 AI를 활용해 더 큰 시스템을 관리하고 그동안 방치된 문제를 해결할 수 있다. 반대로 경영진이 모든 시간 절감을 영구적인 추가 생산능력으로 간주한다면 업무 강도가 높아질 수도 있다.

Hipp의 비유는 이 갈등을 해결하지 못한다. 다만 이를 더 선명하게 드러낸다.

질문은 AI가 프로그래밍 작업을 자동화하는지 여부가 아니다. 이미 자동화하고 있다. 핵심은 절약된 시간을 누가 통제하는지, 어떤 책임이 인간에게 남는지, 그리고 늘어나는 소프트웨어 수요가 대체된 일을 흡수하는지다.

AI 코딩은 기업이 구매하는 역량을 바꾼다

구현 비용이 낮아질수록 조직은 올바른 결과를 정의하고 그럴듯한 실수를 찾아낼 수 있는 사람을 더 가치 있게 평가한다.

SQL로의 전환은 쿼리 문법만 아는 사람이 아니라 데이터 모델과 비즈니스 질문을 이해하는 사람에게 보상했다. AI 코딩도 도메인 이해, 시스템 설계, 테스트, 운영 판단에 비슷한 프리미엄을 만들 가능성이 높다.

프롬프트 작성만으로는 지속 가능한 대체 역량이 되기 어려울 것이다. 프롬프트는 인터페이스이며, 제품이 성숙할수록 인터페이스는 더 쉬워진다. 더 희소한 역량은 그럴듯한 답변이 실제 요구사항을 충족하지 못하는 순간을 알아차리는 능력이다.

개발자에게 이는 생성된 diff를 넘어 시스템을 이해해야 한다는 뜻이다. 데이터 흐름을 추적하고, 신뢰 경계를 식별하고, 실패 모드를 평가하며, 코드 변경을 사용자에게 미치는 결과와 연결해야 한다.

코드 작성의 중심성은 줄어들어도 코드 읽기는 더 중요해질 수 있다. 엔지니어는 낯선 결과물을 검토하고 그것이 현지 관례에 맞는지 판단해야 한다. 미묘한 결함을 알아차릴 만큼의 기초 지식도 필요하다.

테스트 역시 달라진다. 생성된 테스트는 커버리지를 넓힐 수 있지만, 모델은 코드와 테스트 모두에서 같은 오해를 반복할 수 있다. 팀에는 생성된 구현이 아니라 원하는 동작을 기준으로 한 독립적인 인수 기준과 테스트가 필요하다.

아키텍처도 또 다른 압박 지점이 된다. AI 시스템은 익숙한 패턴을 제안할 수 있지만, 익숙한 패턴이 항상 적절한 것은 아니다. 서비스 경계, 일관성, 지연 시간, 데이터 보존, 운영 복잡성에 관한 결정은 구체적인 제약을 반영한다.

도메인 전문가는 모델이 보유하지 못한 맥락을 제공할 수 있기 때문에 영향력이 커진다. 의료 워크플로, 금융 조정 시스템, 산업용 컨트롤러에는 일반 학습 데이터에서 신뢰성 있게 복원할 수 없는 규칙이 담겨 있다.

이것이 모든 개발자가 아키텍트가 된다는 의미는 아니다. 역할의 경제적 중심이 자동화된 작업을 선택하고, 제약하고, 검증하는 방향으로 이동한다는 뜻이다.

일부 직무는 축소될 것이다. 팀은 반복적인 변환, 기본 인터페이스 골격 구성, 일상적인 테스트 생성에 더 적은 인력을 필요로 할 수 있다. 구현 물량을 판매하는 계약자는 고객이 내부에서 수용 가능한 초안을 만들 수 있게 되면서 가격 압박을 받을 수 있다.

다른 직무는 통합과 보증을 중심으로 확대될 것이다. 조직에는 AI 시스템을 비공개 리포지터리에 연결하고, 도구 권한을 통제하며, 결과물을 평가하고, 개발 인프라를 유지하며, 장애를 조사할 사람이 필요하다.

레거시 현대화는 이러한 복합적 효과를 보여준다. IBM 연구진은 엔터프라이즈 COBOL 패턴으로 학습한 모델을 활용해 Java로의 변환을 지원하는 사례를 설명해 왔다. 이들의 modernization work는 여전히 CICS, Db2, VSAM, IMS, 그리고 오래된 시스템에 내장된 비즈니스 동작에 대한 이해에 의존한다.

변환은 대체와 동의어가 아니다. 시스템에는 수십 년간 축적된 문서화되지 않은 결정이 담길 수 있다. Java 문법을 만들어냈다고 해서 새 프로그램이 필요한 모든 동작을 보존한다는 보장은 없다.

숙련된 COBOL 프로그래머는 손으로 작성하는 마이그레이션 루틴이 줄어들 수 있다. 그러나 모델에는 역사적·제도적 맥락이 없기 때문에 그 사람의 지식은 검증 과정에서 더 중요해진다.

SQL도 비슷한 분업을 만들었다. 쿼리 엔진은 알고리즘 선택을 자동화했지만, 복잡한 워크로드에는 여전히 스키마, 인덱스, 통계, 애플리케이션 동작을 이해하는 사람이 필요했다.

따라서 AI 코딩은 개발자에게 구현과의 접점을 잃지 않은 채 더 높은 수준으로 이동하라는 압박을 준다. 코드에 대해 추론할 수 없는 리뷰어는 자신이 검토하는 바로 그 시스템에 의존하게 된다.

기업 역시 관리상의 과제에 직면한다. 더 빠른 코드 생산과 신뢰할 수 있는 결과의 더 빠른 제공을 구분해야 한다. 리뷰, 보안 점검, 이해관계자 의사결정, 배포 프로세스가 여전히 병목이라면 생성된 코드는 고객 가치를 높이지 못한 채 쌓일 수 있다.

코드 줄 수나 완료된 티켓을 기반으로 한 지표는 더욱 쓸모없어진다. 팀은 리드 타임, 유출 결함, 장애 빈도, 재작업, 출시된 기능이 의도한 문제를 해결하는지를 살펴봐야 한다.

지속 가능한 우위는 자동화를 명확한 명세와 독립적인 검증에 결합하는 팀에 있다. 기존 프로세스에 AI 어시스턴트만 추가해서는 책임이 어디로 이동해야 하는지 드러나지 않는다.

Simon Willison의 인용문이 주목할 만하게 만드는 것

다음 단계는 생성된 코드의 양이 아니라 자율성, 소프트웨어 수요, 경력 형성에 관한 증거를 통해 판단해야 한다.

첫 번째 신호는 AI 에이전트가 제한적인 인간 개입만으로 지속적인 프로덕션 작업을 완료할 수 있는지다. 짧은 코딩 시연만으로는 더 이상 충분하지 않다. 더 강력한 검증은 여러 파일에 걸친 변경, 모호한 요구사항, 배포 제약, 보안 검토, 출시 후 유지보수를 포함한다.

에이전트가 낮은 재작업과 적은 유출 결함으로 이런 워크플로를 반복적으로 처리한다면, 제한적인 작업 대체를 예측하는 Hipp의 SQL 비유는 약해진다. AI가 엔지니어링 업무 묶음의 더 큰 몫을 자동화하게 될 것이다.

인간 리뷰가 여전히 지배적인 제약으로 남는다면 이 비유는 강해진다. 직업은 사라지는 대신 감독과 명세 작성 쪽으로 이동하게 될 것이다.

두 번째 신호는 전체 소프트웨어 수요입니다. 기업들은 생산성 향상이 더 작은 팀으로 이어지는지, 안정적인 팀이 더 긴 백로그를 처리하게 하는지, 혹은 이전에는 감당할 수 없었던 프로젝트의 확대로 이어지는지를 보여줘야 합니다.

채용 데이터만으로는 해석하기 어려울 것입니다. 기업은 산출량을 늘리면서 채용 속도를 늦출 수도 있고, 경력 엔지니어를 치열하게 확보하려 하면서 주니어 직무를 줄일 수도 있습니다. 고용의 구성은 전체 인원 수라는 헤드라인보다 더 많은 것을 말해줄 것입니다.

어떤 프로젝트가 자금을 지원받는지 주시해야 합니다. 내부 도구, 소상공인용 소프트웨어, 맞춤형 통합, 접근성 개선의 성장은 과거의 추상화 이후 나타났던 확장 효과를 뒷받침할 것입니다. 이익이 기존 제품 내부에 집중된다면 더 강한 대체 효과를 뒷받침하게 됩니다.

세 번째 신호는 엔트리 레벨 업무의 구조입니다. 에이전트가 전통적인 초급 업무 다수를 수행할 때, 조직은 개발자를 훈련할 수 있는 신뢰할 만한 방법을 마련해야 합니다.

감독된 AI 워크플로, 더 강화된 도제 프로그램, 디버깅이나 시스템 추론에 기반한 평가는 이 직업이 적응하고 있음을 보여줄 것입니다. 대체 교육 없이 주니어 채용이 장기간 붕괴한다면, 이는 더 심각한 경력 경로의 혼란을 시사할 것입니다.

이러한 신호는 단일 출시나 벤치마크가 아니라 시간에 걸쳐 나타나야 합니다. 고용 시스템은 모델 역량보다 더 느리게 조정됩니다. 예산, 조달 규정, 보안 요구사항, 레거시 아키텍처는 기술적 잠재력이 운영 관행으로 전환되는 속도를 제한합니다.

Simon Willison의 글이 중요한 이유는 Hipp이 더 나은 출발 질문을 제시하기 때문입니다. AI가 코드를 작성할 수 있는지를 묻는 대신, 어떤 업무 계층이 선언적으로 바뀌며 그 위에 어떤 인간의 책임이 남는지를 물어야 합니다.

SQL은 막대한 양의 절차적 데이터 작업을 불필요하게 만들었습니다. 동시에 더 큰 소프트웨어 시스템, 더 폭넓은 데이터 접근, 새로운 기술 전문 분야를 가능하게 했습니다. 두 결과 모두 사실이었습니다.

AI 코딩도 더 큰 혼란을 초래하면서 이러한 혼합된 패턴을 따를 수 있습니다. 일상적인 구현의 가치는 낮아질 것입니다. 정확한 판단, 도메인 지식, 검증, 그리고 책임 의식의 가치는 높아질 것입니다.

개발자는 AI가 실제로 업무를 제거하는 곳과 복잡성을 가릴 뿐인 곳을 시험하며 대응해야 합니다. 팀은 생성된 코드가 준수해야 하는 제약 조건을 문서화하고, 배포 후 결과를 측정해야 합니다.

다음 세대의 프로그래머는 더 강력한 실행 엔진을 명령하는 SQL 사용자에 가까울까요, 아니면 더 이상 완전히 이해하지 못하는 시스템을 감독하는 검토자에 가까울까요? 그 답은 자동화가 발전하는 동안 기업이 검증, 학습, 책임성을 얼마나 의도적으로 보존하느냐에 달려 있습니다.