AI 코딩이 ‘일회용 소프트웨어’를 만들 때 생기는 문제, 기술부채

요즘 AI 코딩이 너무 빠르죠. 가히 일회용 소프트웨어 시대라 할만 합니다.
그런데 이 속도가 단순히 “개발 생산성 상승”에서 끝나지 않고,
소프트웨어 자체를 수공예(craft)에서 산업형(industrial)으로 바꿔버릴 수 있다는 관점이 있습니다.

이 글에서 말하는 산업형 소프트웨어는 한마디로, 사람의 숙련도에 덜 의존하고 자동화된 공정으로 더 싸고 더 많이 만들어지는 소프트웨어를 뜻합니다.

오늘은 이 관점에 대해서 함께 이야기 해보려고 합니다.

산업형 소프트웨어의 시대로 진입

전통적으로 소프트웨어는 고숙련 인력의 노동비가 생산비를 결정했고,
그 인력 자체가 병목의 원인이기도 했습니다.
그래서 “잘 만들면 가치가 큰 상품”이었죠.

그런데 산업화가 이 소프트웨어 분야에 침투하면 그 목표는 똑같습니다.

• 자동화를 통해 인간 노동 의존도를 낮추고,
• 더불어 비용을 낮추며,
• 생산 규모를 크게 늘리는 것
• 그리고 인간의 역할은 점점 감독/품질관리/공정 최적화 쪽으로 이동하게 됩니다.

“좋은 제품” 공급망이 흔들린다 – 산업화의 부정적 효과

현재 관련 업계에서는 다음과 같은 사항을 체감하고 있다고 합니다.

노동이 탈중개되고, 진입장벽이 낮아지고, 경쟁이 심해지고,
변화 속도가 한층 더 빨라지고 있다는 것이죠.

✅ 체감 포인트(개발자/팀 관점)

• “이 정도는 AI로 뚝딱” → 유사 제품 폭증
• 기능은 빠르게 나오지만, 설계/테스트/운영은 뒤늦게 따라옴
• 결과적으로 “작동은 하는데 왜 이렇게 불안하지?” 같은 SW가 늘어남

‘일회용 소프트웨어’가 쏟아져 나온다

여기서 핵심이 등장합니다.
산업화는 단지 “좋은 걸 더 싸게”만 만들지 않습니다.
종종 저품질·저비용 제품을 엄청난 규모로 찍어내기도 합니다.

그리고 소프트웨어에선 그 결과물이 일회용 소프트웨어일 수 있다고 말해요.

일회용 소프트웨어: 소유, 유지보수, 장기적 이해를 전제로 하지 않고 “일단 만들고 쓰고 버리는” 소프트웨어 (Chris Loy)

어떤 사람은 이걸 “AI slop”이라고 부릅니다.
재생산이 너무 쉬워져서, 개별 산출물의 경제적 가치가 낮아진다는 것이죠.

제번스 역설: 효율이 좋아지면 ‘총량’이 늘어난다

여기서 제번스 역설(Jevons paradox)이 연결됩니다.
효율이 좋아져 비용이 내려가면 소비가 줄어드는 게 아니라,
오히려 수요가 늘어 총소비가 증가할 수 있다는거죠.

모델이 더 효율적으로 되면,
더 많은 수요(사용)가 발생해 총소비가 늘 수 있다는 것입니다.

• 코딩이 쉬워짐(비용 하락)
  → 더 많은 소프트웨어가 만들어짐(SW 산출물 폭발)
  → 공유/복제/폐기까지 그 규모가 비대해짐

전통적 소프트웨어는 끝날까? “유기농 소프트웨어” 가능성

일회용 소프트웨어로 인해
당장 전통적 소프트웨어가 사라진다고 생각지는 않습니다.

확정적으로 단정할 수는 없지만
미래는 “한 가지”가 아니라 일정 수준 이상의 폭이 있는 스펙트럼일 가능성이 큽니다.

• 대량 생산된 일회용 소프트웨어(빠름/싸지만 유지보수 취약)
• 사람이 공들여 만든 고급 소프트웨어(느리지만 신뢰/내구성이 있음)

LLM은 ‘소프트웨어의 증기기관’일 수 있다

산업혁명 시대에 증기기관이 그랬듯이
LLM(을 이용한 AI 코딩)이
한정된 인간 노동에 의존하던 작업의 비용을 급격히 낮춰
소프트웨어의 산출을 가속한다는 것입니다.

그리고 소프트웨어는 이미 그 동안 ‘산업화’되어 왔는데
LLM이 그 가속 페달을 한층 더 세게 밟고 있는 중입니다.

정리하기

자동화를 통한 대량 산출시대에는
생산이 문제가 아니라 관리가 크게 이슈가 될 것 입니다.
왜냐하면 소프트웨어 생태계에는
의존성 체인, 유지보수 부담, 보안, 기술부채가
산출물 총량과 함께 ‘복리’처럼 커지기 때문입니다.

그래서 이 이슈를 제기한 Chris Loy는 핵심 질문을 던집니다.

“아무도 소유하지 않는 소프트웨어를 누가 유지보수하는가?”

실전 체크리스트: “일회용 소프트웨어”로 안 망하려면

AI 코딩 속도가 너무 빨라진 지금, 핵심은 “빨리 만드는 것”이 아니라 “나중에 나 자신 또는 다른 팀원이 봐도 버리지 않고 쓸 수 있는 상태로 남기기”입니다. 아래 항목들을 팀 차원의 최소 가이드라인으로 삼으면, 일회용 소프트웨어의 부작용을 꽤 줄일 수 있습니다.

1. 테스트 없는 배포 금지 – 최소한의 안전선 만들기

• 스모크 테스트라도 없으면 배포 금지
  전체 테스트 스위트가 없어도 좋으니, “앱이 기본적으로 뜨는지 / 핵심 플로우 1~2개가 도는지”를 확인하는 스모크 테스트를 반드시 자동화합니다.
  예: HTTP 200 응답 확인, 핵심 API 한두 개 호출, 주요 배치 잡 dry-run 등.
• “수작업으로 한 번 확인해봤다”는 증거가 아니라 로그로 남기기
  CI에서 pytest -m "smoke" 같은 최소 테스트가 돌고 성공해야만 머지를 허용하도록 파이프라인을 고정합니다.
  이렇게 하면 “AI가 짠 코드를 그냥 올렸다가 바로 터지는” 케이스를 크게 줄일 수 있습니다.

2. 의존성 관리 – 나중에 설치조차 안 되는 상태를 막기

• lockfile 필수: requirements.txt + poetry.lock/package-lock.json 등
  패키지 버전을 정확히 고정해서 “그때는 되던 코드가 지금은 안 되는” 상황을 줄입니다.
  특히 AI가 자동으로 붙인 라이브러리를 그대로 쓰면, 마이너 버전 변경에서 생각지 못한 깨짐이 자주 발생합니다.
• 주기적인 업데이트 루틴 정의
  “버그 터지면 그때 올리자”가 아니라,
  예: 한 달/분기마다 pip-tools 나 npm-check-updates로 의존성을 올리고, QA/스테이징에서 한 번 돌려보고 반영하는 리듬을 정합니다.
  이건 결국 “기술부채를 한 번에 상환하지 말고, 할부로 갚자”는 전략입니다.

3. 문서 최소 단위: “설계 요약 1장”은 남기기

• 핵심 로직/흐름에 대해 A4 1장 수준의 설명이라도 남깁니다.
  예:
  • 이 서비스/스크립트의 목적
  • 외부 시스템/데이터와 어떤 계약이 있는지(API 스펙, 파일 포맷 등)
  • 비즈니스 규칙/예외 처리의 핵심 포인트
  • “이 부분은 위험해서 쉽게 바꾸면 안 된다” 같은 경고
• 코드 주석 대신, 리포지토리 루트에 ARCHITECTURE.md/SYSTEM_OVERVIEW.md로 두는 편이 좋습니다.
  그래야 다른 도구나 AI에게 맥락을 먹이기도 쉽고, 코드 리팩토링을 해도 “의도”는 남습니다.

4. 보안 기본선 – “AI가 가져온 예제” 그대로 쓰지 않기

• 비밀키/토큰 하드코딩 금지
  .env + 환경변수 + 시크릿 매니저(예: AWS SSM/Secrets Manager)로 분리하는 패턴을 템플릿으로 고정합니다.
  리포지토리에 .env.example만 남기고 실제 값은 절대 커밋하지 않는 규칙을 강제합니다.
• 의존성 취약점 스캔 자동화
  GitHub Dependabot, GitLab SAST, pip-audit, npm audit 등 어떤 방식이든 “의존성 보안 경고가 자동으로 올라오는 채널”을 하나 만듭니다.
  일회용 코드라도 한 번 배포되는 순간, 외부에서 공격 받을 수 있는 표면이 됩니다.
• 권한 최소화
  • DB 계정: 읽기 전용 계정과 쓰기 계정을 명확히 분리
  • API 키: 필요한 권한 스코프만 허용
  • 클라우드 IAM: “AdministratorAccess”는 금지, 역할별 최소 권한

5. “Owner” 지정 – 코드가 아니라 책임의 주인을 정하기

• 각 서비스/모듈마다 “소유자(팀 또는 사람)”를 명시
  README/서비스 카탈로그에 Owner: 팀 이름/슬랙 채널을 적어두는 것만으로도, 나중에 사고 났을 때 “이걸 누가 봐야 하는지”가 분명해집니다.
• Owner의 역할은 ‘직접 개발자’가 아니라 ‘마지막 책임자’
  AI가 80%를 짜든, 외주가 만들었든 상관없이
  • 이 서비스의 품질 기준을 어떻게 둘지
  • 배포 승인 기준은 어디까지로 할지
  • 장애 시 어떤 수준까지 대응할지
    를 결정하는 사람/팀이 명시되어 있어야 합니다.

6. 수명 주기(Lifecycle) 정의 – “언제 죽일지”를 처음부터 정하기

• 프로덕션에 들어간 순간, “언제까지 살려둘지”를 함께 정의합니다.
  • PoC/실험: 3개월 후 자동 종료 후보
  • 내부 툴: 사용량 없으면 6개월 후 폐기
  • 핵심 시스템: 장기 유지 (별도의 유지보수 예산/오너 명시)
• “없는 것보다 나쁜 상태”가 되기 전에 정리하는 루틴
  정기적으로 사용량/에러/알람을 보고,
  • 아무도 안 쓰는 API/스크립트는 문서화 후 제거
  • 대체 서비스가 있으면 리다이렉트/Deprecated 표시 후 단계적 종료

7. AI 사용 가이드 – “코드 생성”과 “설계/책임”을 분리하기

• AI는 생성 도구이지, 설계자도, 책임자도 아니라는 전제를 명확히 합니다.
  • 생성된 코드에 대해 “누가 검토했는지”를 PR/커밋 메시지에 남기기
  • 복잡한 비즈니스 로직은 AI에게 “코드”보다 “의사결정 이유/규칙 설명”부터 먼저 뽑아보게 한 후, 사람이 검증한 뒤 코드화
• 반복되는 패턴은 템플릿 레벨로 승격
  여러 곳에서 비슷한 방식으로 AI 코드를 쓰게 된다면, 공용 라이브러리 / 코드 생성 프롬프트 / 사내 스캐폴드 템플릿 등으로 올려서 “일회용 → 재사용 가능 부품”으로 승격시키는 루프를 만드는 것이 좋습니다.