코딩은 해결된 문제가 아니다

AI가 코드 생성 비용을 낮췄다고 해서 소프트웨어 개발이 해결된 것은 아님. 실제 운영 비용의 큰 부분은 유지보수, 신뢰성, 보안, 확장성에 있으며, 기능 요구사항 충족도 여전히 검증이 필요함 LLM의 코딩 능력은 하네스와 피드백 루프에 크게 의존함. 구문 오류와 실행 오류를 되먹임하고 테스트를 반복해도 논리적 한계, 긴 입력에서의 정확도 저하, 비결정적 출력 문제가 남음 위험 허용도가 낮은 소프트웨어에서는 이해와 책임을 코드 생성에 맡길 수 없음. AI가 설명을 제공할 수는 있어도 엔지니어를 대신해 이해하거나 장애의 결과를 책임질 수는 없음 생산성은 코드 줄 수나 PR 수, 토큰 사용량보다 서비스 수준과 사업 가치로 판단해야 함. 빠른 생성이 검토와 장애 분석 비용까지 줄였는지, 고객이 실제로 더 나은 서비스를 받는지가 중요함 AI는 코드를 설명해 줄 수는 있어도 대신 이해해 줄 수는 없음. 누가 작성했든 배포한 코드의 책임은 사람에게 남으며, 생성 속도만큼 검토와 장애 대응에 드는 시간도 고려해야 함 코드 생성과 운영 가능한 소프트웨어의 차이 핵심은 AI 반대가 아니라 ‘코딩은 해결됐다’는 단정에 대한 반박임. LLM 코딩 도구와 자체 하네스, AI 제품을 활용해 온 경험을 바탕으로 하며, 일부 판단은 지난 4년간의 경험에 근거한 의견임 코드 작성은 저렴해졌지만, 대규모 운영에서는 비기능 요구사항(NFR) 인 유지보수, 신뢰성, 보안, 확장성이 비용의 대부분을 차지함 코드가 무엇을 해야 하는지에 관한 기능 요구사항도 완전히 해결되지 않았음. 결과물을 읽지 않는 사람이 오히려 더 확신하는 현상은 Dunning-Kruger 효과와 맞닿아 있음 코드를 반드시 읽지 않아도 되는 제품은 세 범주로 나뉨 개인용 소프트웨어: 개인적 불편 해결, 자동화, 직접 만든 패치 등임 개념 증명(POC): 기술적 실현 가능성과 제품 성립 가능성을 확인함 무기화된 AI: 위험을 인지한 상태에서 특정 대상에 피해를 주도록 사용함 앞의 두 범주는 위험 허용도가 높고, 마지막 범주는 위험 자체를 무기화함. 반면 의료, 금융, 자동차, 국방, 발전소, 항공, 제조처럼 실수가 금전 손실이나 인명 피해, 법적 결과를 낳는 분야에는 책임이 필요함 AI에 맡길 수 없는 책임 AI는 벌금이나 징역 같은 결과를 감당하지 못하므로 결과에 대한 책임을 물을 수 없음. 전원을 끄는 것은 사람에게 책임을 묻는 것과 다름 배포한 코드에 책임지려면 시스템의 동...