6개월 전까지 코드 한 줄 못 짰던 사람이 지금은 12개 중소기업의 ERP, SaaS, 쇼핑몰, 현장 태블릿 앱을 운영한다. 허구가 아니다. dev.to에 올라온 실제 운영자의 고백이다. 도구는 Claude Code 하나. 이 한 줄짜리 사실이 불편한 이유는, 그게 곧 '개발자 없이도 프로덕션이 돌아간다'는 명제에 가까워 보이기 때문이다.
그런데 본문을 끝까지 읽으면 반전이 있다. 이 운영자가 실제로 고통받은 지점은 코드 생성이 아니었다. 스테이징과 프로덕션 스키마가 조용히 벌어진 것, 쓰기 실패를 UI에 노출하지 않아 일주일 뒤 인보이스 오류로 드러난 것, 삭제된 버튼의 API 엔드포인트가 수개월째 무방비로 열려있던 것. AI가 코드를 틀리게 짠 게 아니라, 검증 습관이 없었던 것이 문제였다. 저자의 표현을 빌리면 "에이전트는 거의 병목이 아니었다. 감사 습관의 부재가 병목이었다."
이 사례는 AI-First 워크플로우가 실제로 작동하는 방식을 정확하게 보여준다. AI는 코드 생성 속도를 극적으로 높여주지만, 프로덕션 신뢰성은 여전히 구조적 검증 루프—스키마 드리프트 감지, 전 경로 에러 노출 강제, 권한 매트릭스 전수 점검—에서 온다. 이 루프를 설계하고 실행하는 역할은 AI가 채워주지 않는다. 저자가 결국 손으로 만든 것도 체크리스트였다. 체크리스트가 기발함을 이긴다는 교훈과 함께.
여기서 두 번째 소스가 겹쳐진다. GeekNews에 소개된 분석 글 '우리는 떼돈을 벌게 될 것이다'는 약 5년 시계열로 AI 코딩 확산의 부작용을 추적한다. 핵심 논리는 단순하다. LLM은 기존 코드를 리팩터링하기보다 새 코드를 추가하는 경향이 강하다. 컨텍스트 창이 아무리 커져도 대형 레포지토리 전체를 담지 못한다. 결과적으로 중복 구현이 쌓이고, 기술 부채가 누적되고, 버그 총량이 늘어난다. 그리고 주니어 채용이 줄어들면서 이 엉킨 코드베이스를 정리할 숙련 인력의 공급도 함께 감소한다.
두 글이 교차하는 지점이 바로 오늘 우리가 봐야 할 곳이다. 비개발자도 프로덕션을 운영할 수 있게 된 세계에서, 역설적으로 '무엇을 삭제할지, 어떤 추상화가 잘못됐는지, 접근 자체를 다시 설계해야 하는지'를 판단하는 능력의 시장 가치는 올라간다. AI가 빠르게 쌓아올린 복잡성을 해석하고 구조적으로 정리하는 일은, AI가 잘 못하는 영역이기 때문이다.
팀 리빌딩 관점에서 이 흐름이 의미하는 바는 명확하다. AI-First 팀에서 개발자의 핵심 기여는 코드 타이핑 속도나 언어 숙련도가 아니다. 검증 구조 설계, 복잡성 예산 관리, 삭제 판단력이다. 비개발자가 Claude Code로 12개 프로덕션을 돌리는 데 6개월 걸렸다면, 그 시스템이 6개월 뒤에도 신뢰할 수 있는 상태로 유지되려면 다른 종류의 역량이 필요하다. 저자가 스스로 만든 감사 체크리스트가 그 역량의 흔적이다.
솔직하게 짚어두자. '시니어 개발자 희소성으로 COBOL 개발자 같은 기회가 온다'는 시나리오는 낙관적 가정에 기댄다. AI 모델이 5년 안에 리팩터링과 추상화 설계까지 능숙해진다면 그 시나리오는 바뀐다. 다만 현재 시점에서 관찰되는 데이터—주니어 채용 감소, 시니어 번아웃 22% 증가, AI 생성 코드베이스의 복잡성 누적—는 실재한다. 지금 당장의 결론은 이렇다. AI가 코드를 생성하는 속도에 맞게 검증과 정리의 속도도 설계되어야 하며, 그 설계는 여전히 사람의 몫이다.
테크리드와 시니어 개발자에게 남는 실천 질문은 하나다. 우리 팀의 AI 생성 코드베이스에 지금 '감사 습관'이 있는가. 스키마 드리프트를 감지하는 프리플라이트가 있는가. 모든 쓰기 경로에 명시적 실패 노출이 강제되어 있는가. 권한 매트릭스를 전수 점검하는 하네스가 레포에 남아있는가. 이 질문들에 '아직'이라고 답하는 팀이라면, 비개발자가 6개월 만에 배운 체크리스트를 먼저 들여다볼 필요가 있다.