AI가 코드를 쏟아내는 시대, 물이 빠지면 누가 발가벗고 수영했는지 드러난다

핵심 요약

• ChatGPT 등장 3년 만에 개발자의 하루가 "코드 작성"에서 "AI 출력 검수"로 이동하고 있음
• 개발자의 역할은 사라지는 게 아니라 코드 작성자에서 리뷰·승인권자로 무게 중심이 이동하는 것에 가까움
• AI는 법적 인격체가 아니라 책임을 질 수 없고, EU AI Act 등 규제도 책임을 인간에게 귀속시키는 방향으로 강화 중임
• AI 시대에 요구되는 핵심 역량은 프롬프트 기술이 아니라 장기 변경 비용 예측, 추상화 판단, 암묵지 언어화 등 지금도
  좋은 개발자에게 필요한 것들과 본질적으로 같음
• Fred Brooks의 우발적 복잡성 vs 본질적 복잡성 개념으로 설명하면 AI가 해결하는 건 우발적 복잡성뿐이고, 도메인의
  본질적 복잡성은 여전히 인간의 판단이 필요함
• 도구 숙련도(프롬프트 엔지니어링 등)의 유효기간은 도구 교체 주기에 묶여 있지만, 설계 판단과 암묵지 언어화 역량은
  소프트웨어의 본질적 복잡성이 존재하는 한 유효함

---

상세 요약

ChatGPT 이후 3년

• 2022년 말 ChatGPT 등장 당시 이 속도로 발전할 것이라 예상하지 못했음
• 기존 개발자의 정의: "자연어 요구사항 분석 → 설계 → 직접 구현"을 모두 수행하는 사람
• 현재는 "AI에게 맥락 전달 → 생성된 코드 읽고 고치고 재요청" 이 하루의 상당 부분을 차지함
• 이미 AI 코딩 에이전트는 단순 보조 수준을 넘어 함수·모듈 단위에서 사람이 작성한 코드와 구별하기 어려운 수준임

작성자에서 의사결정권자로

• 코드 생산 행위가 "직접 코드 작성"에서 "코드에 대한 판단" 으로 이동 중
• "판단"이란 AI 출력이 의도대로 됐는지 확인하는 것이 아니라, 비즈니스 의도가 기술적 구현으로 올바르게 번역됐는지
  검증하는 것
• "AI가 작성한 코드로 결제 버그가 생겼을 때 누가 책임지는가?" 라는 질문이 핵심
• AI는 법적 인격체가 아니므로, 코드를 리뷰하고 승인한 개발자와 조직이 책임 주체임
• 2024년 발효 EU AI Act: 의료·금융·인프라 등 고위험 영역에서 AI 시스템에 인간 감독 의무화
• 자율주행차 사고 책임 → 제조사·운전자, FDA 승인 의료 AI → 최종 판단은 의사, 2010년 Flash Crash → 알고리즘 운영
  주체가 규제 대상
• 자동화가 고도화될수록 책임 구조는 희미해지는 것이 아니라 오히려 더 선명하게 인간 쪽으로 귀속되는 경향이 있음

AI 시대에 개발자에게 요구되는 역량

① 장기 변경 비용을 예측하는 역량

• AI는 "작동하는 코드"를 만드는 데 최적화돼 있음 (학습 데이터에서 가장 빈번한 패턴을 재현)
• 지금 당장 작동하는 코드와 6개월 뒤에도 유지보수가 쉬운 코드는 전혀 다른 기준
• 나쁜 설계의 비용은 코드를 작성한 시점이 아니라 변경이 필요한 시점에 발생함
• LinkedIn에서 "AI로 만들었는데 유지보수 어려워서 개발자 고용", "기능을 못 붙혀 접었다"는 글이 늘고 있음

② 코드를 다각도로 평가하는 역량

• 기능적 정확성(테스트로 검증 가능) 너머에 구조적 품질, 성능적 함의, 보안적 측면을 동시에 고려해야 함
• AI 코드 생성 속도가 빨라질수록 생산 속도와 리뷰 역량 사이의 균형이 쉽게 깨짐
• 사람이 직접 쓰던 시절엔 코드 생산량에 물리적 상한이 있었지만, AI는 수초 만에 수백 줄을 생성함
• 리뷰 기준·병렬 리뷰 체계·자동화 게이트가 불충분하면 기술 부채가 더 빠르게 쌓임
• 많은 회사들이 AI 도입 후 생산성 증가를 못 느끼는 이유: 코드 생산은 빨라졌지만 AI 코드를 리뷰하는 과정이 병목

③ 추상화 역량

• AI도 인터페이스 정의, 클래스 분리, 모듈 분리를 할 수 있고 형식적으로는 잘 함
• 결정적 차이: AI의 추상화는 통계적 평균 기반, 숙련된 개발자의 추상화는 한정된 자원과 불확실한 미래 속의 트레이드오프
  판단
• AI 출력 코드의 위험한 점: 겉보기에 좋아 보임 — 파일이 적절히 나뉘고, 네이밍도 관례를 따르고, 패턴도 익숙함
• 문제는 변경이 필요한 시점에 드러남: "결제 수단 하나 추가하려는데 '깔끔해 보이던' 구조 여기저기를 동시에 수정해야
  한다는 걸 그제야 깨달음"
• 프론트엔드 예시: AI는 하나의 거대한 컴포넌트에 데이터 페칭·상태 관리·UI 렌더링을 몰아넣거나, 반대로 간단한 차트
  하나에 커스텀 훅 3개 + 컨텍스트 프로바이더를 만들어놓기도 함

④ 암묵지를 명시화할 수 있는 역량

• "뭔가 이상한데"라는 직감을 "이 함수는 두 가지 책임을 가지고 있다" 는 구체적인 언어로 바꿀 수 있어야 AI에게 정확한
  명령을 내릴 수 있음
• few-shot, chain-of-thought 같은 형식적 프롬프트 기법이 아니라 무엇을 만들어야 하는지 명확하게 정의하고 어떤 맥락이
  중요한지 판단해서 전달하는 능력
• 도구 숙련도 수명: 도구 교체 주기에 묶임 (jQuery → React, Webpack → Vite)
• 설계 판단과 암묵지 언어화 역량 수명: 소프트웨어의 본질적 복잡성이 존재하는 한 유효

의도적 수련 설계의 필요성

• "도구가 할 수 없는 것에 집중하라"고 하지만, 정작 그것을 기를 기회가 줄어드는 모순적 상황

① AI에게 넘기지 말아야 할 두 지점: 설계와 리뷰

• 코드 작성 앞단의 설계: 프롬프트 치기 전에 인터페이스와 책임의 경계를 먼저 정의하면, AI 출력과 자신의 설계 결정을
  비교할 수 있게 됨
• AI에게 PR 리뷰를 맡기고 별 문제 없으면 승인해버리는 습관 = "체육 시간에 운동장 나가서 벤치에만 앉아 있다가 들어오는
  것"

② 의도적으로 직접 짜보는 시간

• 설계 감각은 구현의 고통을 알아야 생김. 겪어보지 못한 고통은 감각으로 남지 않음
• 주니어 개발자: AI 생성 코드를 리뷰하는 건 "아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것"
  과 비슷함
• 미래의 코딩 능력: 매일 하는 업무가 아니라 판단력을 유지하기 위한 훈련 (리뷰어 면허를 따는 과정)

③ "왜"를 언어화하는 연습

• "이상한데"에서 멈추면 직감, "이 함수가 두 가지 책임을 가지고 있다" 까지 가면 언어
• AI가 만든 코드가 작동한다고 거기서 멈추지 않고 "왜 이 구조를 선택했을까", "다른 구조였다면 트레이드오프는?" 을
  스스로에게 물어보는 습관

결국 본질은 변하지 않았다

• Fred Brooks(1986): 우발적 복잡성(도구의 한계) vs 본질적 복잡성(문제 자체에 내재)
• AI가 해결하는 건 우발적 복잡성 — 보일러플레이트, 반복 패턴, 문법 오류
• 본질적 복잡성 (비즈니스 요구사항의 모호함, 상충하는 설계 목표 균형, 미래 변경 불확실성)은 AI가 발전해도 사라지지
  않음
• 인간이 판단과 책임의 주체로 남아 있는 한, 판단에 필요한 역량의 본질은 바뀌지 않음
• 코드 생산이 자동화될수록 생산물을 검수하는 판단력의 비중이 오히려 부각될 것