AI 발전해도 개발자 사라지지 않는 이유 (코딩을 알아야 AI를 시켜요.)

제미나이, 챗 GPT가 발전하면서 자신의 일자리를 잃을까 봐 고민하는 개발자가 많습니다. 그런데 AI가 아무리 발전을 하여도, 코딩하는 사람을 대체하지는 못합니다. 그 이유에 대해서 알아봅시다.

AI 발전해도 개발자 사라지지 않는 이유

AI는 “패턴을 따라 코드를 생성”하는 데 강합니다. 그러나 소프트웨어가 돌아가기 위해서는 코드 자체가 아니라 왜 그 구조가 안전하고 유지보수가 가능한지 알아야 합니다.

사용자의 요구와 제약, 실패 시의 비용, 조직의 운영 역량을 한 그릇에 담아 설계 결정을 내리고 책임지는 일은 사람만 할 수 있고, AI가 아무리 발전을 하여도 이런 것을 불가합니다.

영화 터미네이터처럼 완전한 미래에는 가능할지 몰라도, 최소한 지금 AI 시스템으로는 코드만 짤 줄 아는 기계지 그 내면에 있는 시스템까지 관여할 수 없습니다.

AI 발전해도 개발자 사라지지 않는 이유 (코딩을 알아야 AI를 시켜요.)
AI 발전해도 개발자 사라지지 않는 이유 (코딩을 알아야 AI를 시켜요.)

LLM의 한계: 생각하는 존재가 아니다.

LLM은 통계적 언어 모델입니다. 정확한 세계모형, 환경모형이 없을 때 착각이 납니다. 말이 너무 어렵죠? 쉽게 말하면 지금 LLM AI에게 “GDP 성장함과 동시에 무역 수출이 증가한 기록을 비교 분석해봐“라는 것을 시키면 AI는 하지 못합니다.

인간은 눈으로 데이터를 보고 분석하고 결과를 낼 수 있지만 LLM AI는 생각을 하는 존재가 아니고, 다른 사람이 써 놓은 정보를 조합하는 존재기 때문에 누군가 이런 정보를 만들어서 인터넷에 올려놓지 않았으면 정보를 만들어 낼 수 없고, 이게 LLM의 한계입니다.

간단한 코드는 되지만 설계는 못하는 AI

AI에게 코딩을 시키면 잘 짜줍니다. 너무 무섭죠? 개발자 자리가 사라질까봐? 그런데 개발자는 매년 더 늘고 있습니다. 왜 그럴까요?

개발이라고 하는 것은 내가 어떤 코드를 쓸지 알고 있어야 지휘가 가능합니다. 이 지휘를 받아서 수행하는 것은 AI가 가능합니다. 예를 들면 아래와 같은 부탁은 AI가 되었든 코딩 초보가 되었든 누구나 할 수 있습니다.

  • 웹 페이지 HTML 짜고,
  • CSS로 파란색 계열로만 넣어줘

그러나 이를 짜서 지휘하고, 경제, 수익성을 올리는 것은 결국 사람이 할 수 밖에 없습니다.

깊은 코딩은 다르다: 구조 설계와 프로덕션 품질

프로덕션은 돈과 신뢰가 흐르는 자리입니다. 구조가 전부입니다. 아래와 같은 설계를 사람이 하는 것이지, AI가 구조를 짜주는 게 아닙니다.

거래소, 결제, 이커머스, 멀티테넌시, 권한·보안, 데이터 일관성

  • 거래·결제: 정확히 한 번 처리(Exactly-once) 보장, 이중지불 방지
  • 이커머스: 재고 경합, 예약·확정의 사가 패턴
  • 멀티테넌시: 데이터 격리, 속성 기반 접근제어(ABAC)
  • 보안: 비밀 관리, 키 롤링, 최소권한
  • 일관성: 강·최종 일관성의 선택과 보상 설계

SLO, 트랜잭션, 아이들폿, 옵저버빌리티, 롤백·마이그레이션

  • SLO: 가용성·지연·오류 예산으로 의사결정
  • 트랜잭션: DB 경계 설계, 사가/아웃박스 패턴
  • 아이들폿(Idempotency): 재시도 안전 키
  • 옵저버빌리티: 로그·메트릭·트레이스, 코렐레이션 ID
  • 릴리스: 마이그레이션 순서, 롤백/캔어리·피처플래그

마무리하며

AI 때문에 개발자가 사라진다는 것은 개발자가 아니라 단순하게 코드를 입력하는 사람이 사라지는 것입니다. 그런 코드만 입력하는 사람은 고등학생도 가능하죠. 그러나 설계하고 구성하여서 시스템을 만드는 것은 결코 AI가 할 수 없습니다.

  • 핵심 요지: AI는 코드를 빠르게 씁니다. 그러나 소프트웨어의 가치는 왜 그 구조가 안전하고 유지보수 가능한지에 있으며, 그 이유를 설계하고 검증하는 일은 사람의 몫입니다.

FAQ

Q1. AI에게 어디까지 맡겨도 안전하나요?

A1. CRUD와 포맷 변환와 보일러플레이트 같은 반복 작업은 맡기셔도 됩니다. 다만 입력와 출력 스키마, 실패 기준, 금지 API를 스펙으로 고정하셔야 품질이 안정됩니다.

Q2. LLM이 만드는 가장 흔한 버그는 무엇인가요?

A2. 존재하지 않는 API 호출, 경계값 누락, 상태 전이 공백, 동시성 처리 미흡이 자주 나타납니다. 상태 다이어그램와 실패 시나리오를 스펙에 포함하면 예방 효과가 큽니다.

Q3. 프로덕션 품질을 위해 반드시 사람이 결정해야 하나요?

A3. 그렇습니다. 트랜잭션 경계, 일관성 수준, 권한와 보안, SLO와 롤백 전략은 비용와 책임이 걸린 결정이므로 사람이 설계하고 검증하는 것이 원칙입니다.

이 글, 당신 생각이 궁금해요 😊

평가를 통해 저에게 힌트를 주세요.

0명이 이 글을 평가했고, 평균 평점은 0점입니다. 당신도 한 표를 남겨주세요 🙌

아직 평가가 없습니다. 첫 번째 평가자가 되어주세요!

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다