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

bboydart91 · 2026-02-19T06:17:29+09:00

핵심 요약 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가 발전해도 사라지지 않음 인간이 판단과 책임의 주체로 남아 있는 한, 판단에 필요한 역량의 본질은 바뀌지 않음 코드 생산이 자동화될수록 생산물을 검수하는 판단력의 비중이 오히려 부각될 것

(evan-moon.github.io)

51P by bboydart91 2달전 | ★ favorite | 댓글 14개

핵심 요약

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)
설계 판단과 암묵지 언어화 역량 수명: 소프트웨어의 본질적 복잡성이 존재하는 한 유효

의도적 수련 설계의 필요성