AI 시대의 프로그래머: 코드 생성에서 비결정성 통제로의 역할 전환

▲ 이미지 출처: GeekNews

2022년에 발표된 통제 실험에서 GitHub Copilot을 쓴 개발자는 같은 과제를 55% 빠르게 완료했다. 언론은 “개발자 절반이 사라진다”는 헤드라인을 뽑았다. 그런데 불과 3년 뒤인 2025년 7월, 정반대의 데이터가 등장했다. 숙련된 오픈소스 개발자 16명을 대상으로 한 무작위 대조 시험(RCT)에서, AI 도구를 허용한 조건의 개발자들은 허용하지 않은 조건보다 과제 완료에 19% 더 오래 걸렸다. 같은 개발자들이 사후 설문에서 “AI 덕분에 20% 빨라졌다”고 답한 것과 정면으로 배치되는 결과였다. 이 역설 속에 AI 시대 프로그래머의 본질적 도전이 숨어 있다.

Andrej Karpathy의 Software 1.0→2.0→3.0 프레임

테슬라·OpenAI 출신의 Andrej Karpathy는 2017년 에세이 Software 2.0에서 패러다임 전환을 처음 명확히 정의했다. 전통적인 Software 1.0에서 프로그래머는 명시적 규칙(알고리즘)을 손으로 코딩한다. Software 2.0에서는 신경망이 데이터로부터 가중치 공간을 탐색해 스스로 ‘프로그램’을 컴파일한다. 개발 팀은 두 역할로 분리된다. 한쪽은 데이터셋을 큐레이션·정제하는 “2.0 프로그래머”, 다른 한쪽은 학습 인프라와 시각화 도구를 유지하는 “1.0 프로그래머”다.

Karpathy는 이 에세이에서 소프트웨어 2.0의 핵심 약점도 솔직하게 인정했다. 시스템이 “직관에 반하는 당혹스러운 실패”를 일으킬 수 있고, 학습 데이터의 편향을 묵묵히 내재화하며, 적대적 입력에 취약하다고 지적했다. 특히 “90% 정확도로 이해할 수 있는 모델”과 “99% 정확도지만 이해할 수 없는 모델” 중 하나를 골라야 하는 상황이 온다는 경고는 오늘날 생성형 AI 도입 현장에서 그대로 재현되고 있다.

2025년 6월 YC AI Startup School 기조연설에서 Karpathy는 개념을 한 단계 더 확장해 Software 3.0을 제시했다. LLM 자체가 런타임이 되고, 프롬프트가 프로그램이 되는 세계다. 그는 LLM의 핵심 특성으로 “들쑥날쑥한 지능(Jagged Intelligence)”을 지목했다. 복잡한 추론은 훌륭히 수행하지만, 단순 과제에서 예측 불가능하게 실패한다는 것이다. 이 비결정성이 바로 AI 시대 개발자가 통제해야 할 핵심 변수다.

METR 연구: 숙련 개발자는 왜 느려졌나

2025년 7월 METR(Model Evaluation and Threat Research)이 발표한 무작위 대조 시험(arXiv:2507.09089)은 AI 도구 도입의 맹점을 정밀하게 드러냈다. 연구 설계는 엄밀했다. 평균 22,000개 이상의 GitHub 스타를 보유한 성숙한 오픈소스 프로젝트에서 평균 5년의 경험을 가진 개발자 16명이 246개의 실제 이슈를 해결했다. 각 과제마다 AI 허용/불허 여부를 무작위로 배정했고, 개발자들은 화면을 녹화하며 구현 시간을 직접 기록했다. 보수는 시간당 150달러로 설정해 외부 유인을 통제했다.

결과는 충격적이었다. AI 도구 허용 조건에서 개발자들은 19% 더 오래 걸렸다(신뢰구간 +2%~+39%). 사전 예측(“AI가 24% 빠르게 해줄 것”)과 사후 체감(“20% 빨라졌다”) 모두 실제와 정반대였다. 경제학 전문가들은 39% 단축, ML 전문가들은 38% 단축을 예측했지만 모두 빗나갔다. 연구팀은 속도 저하의 원인으로 세 가지를 꼽았다. 첫째, 인지 전환(cognitive mode-switching): 코딩 모드와 프롬프팅 모드를 오가는 전환 비용이 흐름(flow state)을 방해했다. 둘째, 검증 부담: 제한된 컨텍스트 창으로 인해 AI가 존재하지 않는 모듈의 임포트 구문, 잘못된 파라미터 시그니처, 기존 아키텍처와 충돌하는 패턴을 생성해 전체 과제 시간의 9%가 AI 출력 검토·수정에 소요됐다. 셋째, 컨텍스트 불일치: AI는 프로젝트의 암묵적 맥락과 이력을 파악하지 못했다.

중요한 맥락: 이 연구는 “우리 참가자와 리포지터리가 소프트웨어 개발 다수를 대표한다고 주장하지 않는다”고 명시했다. 그리고 2025년 8월에 시작된 후속 연구에서는 최신 AI 도구를 사용한 더 넓은 개발자 풀이 평균 18%의 속도 향상을 보였다(다만 선택 편향이 개입해 해석에 주의가 필요하다). AI 도구는 빠르게 진화하고 있고, 맥락이 달라지면 결과도 달라진다.

반대편 데이터: 단순 과제와 입문자에서의 극적 효과

METR 연구가 숙련된 개발자와 성숙한 프로젝트를 대상으로 했다면, 2022년의 GitHub Copilot 통제 실험은 정반대의 조건을 보여준다. 95명의 전문 개발자에게 JavaScript로 HTTP 서버를 구현하는 과제를 부여한 결과, Copilot 사용 집단은 평균 1시간 11분, 미사용 집단은 2시간 41분이 걸려 55.8% 빠른 완료(p=.0017)를 기록했다. 과제 완료율도 78% 대 70%로 Copilot 집단이 높았다. 개발자 73%가 흐름 상태 유지를, 87%가 반복 작업에서의 정신적 에너지 절약을 보고했다.

두 연구의 차이는 명확하다. 과제의 친숙도와 복잡도, 그리고 기존 코드베이스의 규모가 AI 효과를 결정한다. 신규 프로젝트의 보일러플레이트 코드, 테스트 케이스 자동 생성, 반복적 패턴 구현 같은 작업에서 AI는 큰 속도 이점을 제공한다. 반면 수백만 줄 규모의 성숙한 코드베이스에서 암묵적 설계 결정과 프로젝트 이력을 고려해야 하는 고난이도 이슈는 오히려 AI 개입이 마찰을 증가시킬 수 있다. 2년에 걸쳐 노르웨이 공공부문 대형 조직 NAV IT를 대상으로 진행된 종단 연구(39명 개발자, 26,317개 커밋)에서도 Copilot 도입 후 커밋 수나 코드 라인 수의 통계적으로 유의미한 변화는 없었으며, 연구자들은 “인지 부하 감소와 워크플로 흐름 개선 같은 정성적 이점이 기존 지표로는 포착되지 않는다”고 결론지었다.

비결정성 통제: AI 시대 개발자의 핵심 역량

두 연구가 공통적으로 가리키는 방향이 있다. AI 도구의 효과는 개발자가 그 비결정성을 얼마나 효과적으로 통제하느냐에 달려 있다는 것이다. 비결정성은 두 차원으로 나타난다. 첫째는 모델 수준의 비결정성이다. 동일한 프롬프트도 실행마다 다른 코드를 생성하고, Karpathy가 말한 “들쑥날쑥한 지능”처럼 예측 불가능하게 실패한다. 둘째는 명세(specification) 수준의 비결정성이다. 모호한 요구사항이 AI에 그대로 전달되면 AI는 임의의 해석으로 구현을 채운다.

METR의 후속 연구(2026년 2월)에서 주목할 만한 현상이 관찰됐다. 원래 연구에 참여했던 일부 개발자들은 재실험에서 AI 없이 과제를 수행하기를 거부했다. 한 참가자는 이렇게 말했다. “인공지능 없이 너무 많은 것을 하려 하면 머리가 터질 것 같다. 마치 걸어서 도시를 횡단하는 것을 배웠다가 이제는 우버에 익숙해진 것처럼.” AI 도구의 내재화는 되돌리기 어렵다. 문제는 이 내재화가 주체적 통제력 강화를 동반하느냐, 아니면 맹목적 의존으로 빠지느냐다.

Karpathy는 Software 3.0 강연에서 구체적인 설계 원칙으로 생성-검증 루프(Generator-Verifier Loop)를 제시했다. AI가 코드를 생성하는 속도와 인간이 그 출력을 검증하는 속도를 동시에 최적화해야 한다는 것이다. 이는 AI를 쓰는 개발자의 핵심 업무가 “무엇을 만들지 정확히 명세하기”와 “만들어진 것이 의도대로 동작하는지 검증하기”로 이동했음을 의미한다. Anthropic의 2026 Agentic Coding Trends Report에 따르면 에이전트 코딩 세션의 평균 길이와 도구 호출 횟수는 자동완성 시대 대비 큰 폭으로 증가했고, 세션당 파일 읽기·코드 작성·명령 실행·반복의 수십 단계가 포함된다. 더 많은 자율성을 에이전트에 위임할수록 검증의 중요성도 비례해서 높아진다.

소프트웨어 유지보수성: AI 코드는 안전한가

AI가 작성한 코드를 나중에 다른 개발자가 유지보수할 때 어떤 일이 벌어질까. arXiv에 2025년 7월 게재된 연구 Echoes of AI(arXiv:2507.00788)는 이 질문을 151명의 참가자(95% 전문 개발자)를 대상으로 2단계 통제 실험으로 검증했다. 1단계에서 AI 있음/없음 조건으로 기능을 추가하고, 2단계에서 다른 참가자가 AI 없이 그 코드를 발전시켰다. 결과는 “AI 보조로 개발된 코드를 다른 개발자가 발전시킬 때, 유지보수성의 체계적 이점도 단점도 발견하지 못했다”는 것이었다. AI 지원 조건에서 완료 시간은 30.7% 단축됐지만, 다운스트림 품질에 미치는 영향은 통계적으로 유의미하지 않았다.

이 결과는 두 가지로 해석할 수 있다. 낙관론: AI가 코드 품질을 해치지 않는다. 경계론: 코드 복잡도 증가, 불필요한 코드 팽창, 개발자의 인지 부채(cognitive debt) 같은 장기 리스크는 단기 실험으로 포착하기 어렵다. 연구팀도 이 가능성을 “향후 연구 과제”로 명시했다.

에이전트 시대의 새로운 위험: 명세 부식과 비용 폭주

AI 코딩이 대화형 보조에서 자율 에이전트로 진화하면서 새로운 문제가 부상하고 있다. 36Kr의 분석에 따르면 코딩 에이전트는 기존 라이브러리를 재사용하는 대신 처음부터 기능을 구현하는 경향을 보인다. 라이브러리 학습 데이터의 불균형과 버전 업데이트에 따른 API 변경 불확실성 때문이다. 에이전트가 “바퀴를 반복 발명”하면 코드베이스는 비대해지고 의존성 관리는 복잡해진다.

비용 통제도 임박한 실무 문제다. Cursor는 구독 플랜을 초과한 토큰 소비로 인해 연속으로 가격을 인상하고 기능을 축소했다. 에이전트 세션이 길어지고 자율성이 높아질수록 한 번의 작업에서 예상치 못한 토큰 비용이 발생할 수 있다. 에이전트에 명확한 범위(scope)와 종료 조건(exit condition)을 설계하는 것은 기술적 문제인 동시에 비용 관리 문제다.

중소기업·스타트업에 대한 시사점

• 과제 유형을 분류하라 — 신규 기능의 보일러플레이트, 테스트 코드, 반복 패턴에는 AI를 적극 활용한다. 성숙한 코드베이스의 고난이도 버그 수정이나 핵심 아키텍처 결정은 AI 보조를 제한적으로 쓰고 숙련 개발자의 판단에 무게를 둔다.
• 명세 역량이 곧 생산성이다 — 모호한 요구사항을 AI가 이해할 수 있는 정밀한 명세로 변환하는 능력이 AI 도구 효과의 핵심 결정 변수다. 팀 내에 명세 작성 규범을 만들어라.
• 검증 프로세스를 제도화하라 — AI 출력을 체계적으로 검토하는 코드 리뷰 체크리스트, 자동화 테스트 커버리지 기준을 도입한다. 개발 속도 이점이 검증 비용보다 클 때만 AI 도구가 순편익을 가져온다.
• 에이전트 범위를 설계하라 — 에이전트에 위임할 과제의 시작과 끝 조건, 최대 토큰 예산을 명시한다. 자율성 슬라이더(Karpathy의 표현)를 팀이 적절히 조정하는 것이 관리자의 역할이다.
• 종속 비용을 모니터링하라 — 월별 AI 도구 토큰·API 비용을 추적하고, 기대 생산성 향상과 실제 비용의 ROI를 분기마다 점검한다. Cursor 사례처럼 구독 플랜이 예고 없이 바뀔 수 있다.

AI가 코드를 쓰는 시대에 개발자의 차별점은 타이핑 속도가 아니다. AI의 비결정적 출력을 명세로 통제하고, 생성된 결과를 시스템 수준에서 검증하는 판단력이다. 이 역량 차이가 팀의 실제 생산성을 가른다.

---