AI로 빠르게 배포하는 것이 함정인 이유

모두가 잘못된 숫자를 자랑하고 있습니다. AI를 사용하여 20분 만에 기능을 배포했다고 주장하는 것은 자랑거리가 아닙니다. 그것은 업무에서 가장 저렴한 부분을 가속화하고, 가장 값비싼 작업은 건너뛰었다는 고백입니다.

코드 생성 (Code generation)은 결코 어려운 부분이 아니었습니다. 진짜 도전 과제는 언제나 요구사항을 정의하고, 범위를 축소하며, 제약 조건을 명시하고, 변경 사항이 올바르다는 것을 어떻게 증명할지 결정하는 것이었습니다. 이를 건너뛰면, AI는 단지 당신이 잘못된 것을 더 빠르게 배포하도록 도울 뿐입니다. 당신은 '완료된 것처럼 보이는 것'과 '실제로 완료된 것' 사이의 간극이 커지는 함정을 만들고 있는 것입니다. 모델은 깔끔하고 자신감 넘치는 코드를 제공하지만, 그것이 시스템에 적합한지 또는 6개월 후에 어떤 비용을 치르게 될지는 알려주지 않습니다.

AI는 당신의 엔지니어링 (Engineering)을 업그레이드하지 않습니다. 그것은 당신이 이미 가지고 있던 루프 (Loop)를 증폭시킵니다. 좋은 판단력은 더 빨라지지만, 나쁜 판단력 또한 더 빨라집니다. 현재 워크플로 (Workflow)의 현실을 보십시오:

• 출력 결과가 자신감 있게 들리고 아무도 차이점 (Diff)을 읽지 않았기 때문에 사람들이 운영 데이터베이스 (Production databases)를 삭제하고 있습니다.
• 리뷰 부담 (Review burden)은 당신이 얼마나 많이 썼느냐가 아니라, 얼마나 많은 코드를 수락했느냐에 따라 확장됩니다.
• 대부분의 장애는 여전히 잘못된 생성 (Generation)이 아니라 불분명한 요구사항에서 비롯됩니다.

이것들은 새로운 가면을 쓴 엔지니어링 문제들입니다. 이제 중요한 기술은 주말이면 배울 수 있는 프롬프팅 (Prompting)이 아닙니다. 요구사항, 간극 식별, 계획, 작은 변경, 리뷰, 그리고 검증 (Verification)이라는 명확한 순서를 통해 업무를 형성하는 것입니다. 당신의 첫 번째 프롬프트는 마지막 프롬프트가 아니라, 작업이 올바르다는 것을 증명하는 테스트에 관한 것이어야 합니다.

Git부터 CI/CD에 이르기까지 모든 진지한 도구들은 팀이 그 도구를 중심으로 워크플로를 재구축하기 전까지는 쓸모가 없었습니다. 도구도 중요하지만, 워크플로가 더 중요합니다. 이 단계에서 승리하는 엔지니어는 AI를 가장 많이 사용하는 사람이 아닐 것입니다. 그들은 코드를 가속하기 전에 문제를 늦추는 사람들일 것입니다. 대부분의 사람들은 AI를 사용하고 있지만, 그것을 가지고 엔지니어링을 하는 사람은 거의 없습니다. 당신은 이러한 검증의 간극을 고려하여 내부 워크플로를 어떻게 조정하고 있습니까?