다크 팩토리(Dark Factory). 원래는 제조업 용어다. 조명을 꺼도 돌아가는 공장, 사람 없이 자동화만으로 운영되는 생산 라인을 가리키는 말이다. 지금 이 개념이 소프트웨어 업계로 넘어오고 있다. AI가 코드를 쓰고, AI가 리뷰하고, 파이프라인이 배포한다. 거기서 인간은 어디에 있나.
다크 팩토리, IT판으로 번역하면
제조업의 다크 팩토리는 ‘인간이 없어도 돌아간다’가 핵심이다. IT판에서는 조금 다르게 번역된다. ‘인간이 있어도 코드를 안 읽는다’에 가깝다.
GitHub Copilot, Cursor, Claude Code 같은 AI 코딩 어시스턴트가 일상 도구가 됐다. 생산성은 올라갔다. 코드 라인 수도 늘었다. 그런데 그 코드를 처음부터 끝까지 읽고 이해하는 사람은 줄어들고 있다. AI가 생성한 코드를 AI가 리뷰하고, 사람은 그 결과를 승인하는 구조. 여기까지 오는 데 그렇게 오래 걸리지 않았다.
실제로 일어나고 있는 일들
조지아 공대 SSLab이 운영하는 ‘Vibe Security Radar’ 프로젝트는 AI 코딩 도구가 실제로 공개 취약점 데이터베이스(CVE, NVD 등)에 등록된 보안 결함을 얼마나 만들어내는지 추적한다. 2025년 하반기에는 7개월 동안 약 18건이 발견됐는데, 2026년 1분기에는 56건으로 급증했다. 2026년 3월 한 달에만 35건 — 2025년 전체를 뛰어넘었다.
더 흔한 케이스는 기술 부채다. AI가 생성한 코드는 동작한다. 그러나 팀의 기존 아키텍처 원칙을 무시하거나, 이미 deprecated된 라이브러리를 참조하거나, 비슷한 기능이 다른 모듈에 이미 있다는 사실을 모른 채 중복 구현하는 경우가 잦다. 아무도 코드를 읽지 않으면 이런 문제는 표면으로 올라오지 않는다. 조용히 쌓인다.
진짜 문제는 코드가 아니라 맥락이다
코드 리뷰의 목적은 버그를 잡는 것만이 아니다. 더 중요한 기능은 조직의 지식을 공유하고, 결정의 흔적을 남기는 것이다. 누가 왜 이 구조를 선택했는지, 어떤 트레이드오프를 감수했는지. 그 맥락이 팀 전체에 쌓이는 과정이 코드 리뷰다.
AI가 리뷰를 대체하면 그 과정이 사라진다. 표면의 품질은 유지될 수 있다. 그러나 시스템에 대한 집단적 이해는 증발한다. 6개월 후 그 코드를 수정해야 할 때, 팀에는 왜 이렇게 만들었는지 아는 사람이 없다. 코드는 있는데 맥락이 없는 상태.
구글 엔지니어링 블로그에서 오래전부터 강조해 온 개념이 있다. “코드는 쓰는 것보다 읽히는 횟수가 훨씬 많다(Code is read far more than it is written).” 다크 팩토리식 개발이 무너뜨리는 건 이 전제다.
그래서, 괜찮은가
대답은 조건부다.
단기적으로는 괜찮다. 생산성이 오르고, 빠르게 돌아간다. 작은 팀이 큰 팀처럼 움직일 수 있다. AI 코드 생성이 가져다 준 이점은 실재하고, 무시할 수 없다.
그러나 장기적으로는 다르다. 시스템의 복잡도가 올라가고, 도메인 지식이 개인에게서 조직으로 이전되지 않는 구조가 굳어지면, 그 기술 부채의 이자는 나중에 한꺼번에 청구된다. 아무도 전체를 이해하지 못하는 시스템. 바꾸려고 하면 어디서부터 손을 대야 할지 모르는 코드베이스.
다크 팩토리는 선택지가 될 수 있다. 하지만 인식하지 못한 채 그 상태가 되는 건 다른 문제다. 코드를 읽지 않기로 ‘결정’하는 것과, 어느 날 보니 아무도 읽고 있지 않았던 것 사이의 차이.
결론
코드를 읽는다는 건 버그를 잡는 행위만이 아니다. 시스템이 왜 지금 이 모습인지를 이해하는 과정이다. 다크 팩토리가 그 과정을 지워버릴 때, 회사는 자신이 무엇을 만들고 있는지 모르는 상태가 된다.
지금 당장 생산성 지표는 좋아 보일 수 있다. 그러나 1년 후 시스템을 뜯어고쳐야 할 때, 그 팀에 맥락을 가진 사람이 남아 있는가. 그게 더 중요한 질문일지 모른다.
AI 코드 생성을 쓰지 말자는 이야기가 아니다. 쓰되, 읽어야 한다. 그 단순한 원칙을 잃지 않는 게 지금 개발 조직에 필요한 것 같다.