AI 코딩에서 사람의 역할은 코드를 쓰는 일에서 "무엇이 맞는지 정의하고, 실제로 맞는지 확인하는 일" 로 옮겨갔습니다. 이 두 가지를 하지 않으면 AI는 틀린 코드를 아주 빠르게, 아주 일관되게 만들어 냅니다.
핵심 한 줄: 코드 생산은 싸졌지만 소프트웨어 공학이 쉬워진 것은 아닙니다. 어려움이 윗단(분해·판단·검증·아키텍처) 으로 올라갔을 뿐입니다.
"엔지니어링이 잘 된 영역은 10~100배 빨라지고, 안 된 영역은 같은 비율로 나빠진다."
AI는 주변 코드를 그대로 복제합니다. 그래서 나쁜 패턴은 더 빨리 퍼지고, 나중에 치우는 비용은 10배 이상으로 불어납니다.
AI 코드 리뷰를 운영하면 두 가지 실패를 겪습니다. 문제를 놓치는 것(false negative)과 쓸데없는 지적이 쌓이는 것(false positive)입니다. 그리고 가장 섬뜩한 관찰은 이것입니다.
2025년 상반기만 해도 사람들은 AI 리뷰를 더블체크했다. 지금은 많은 개발자가 AI 코멘트를 아예 읽지 않는다. 그 결과 실패율이 올라가고 있다.
백엔드는 깔끔한 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)가 아니라 촘촘하게 얽힌 의존성 그물입니다. 그래서 모델 성능보다 "1분 안에 끝나는, 믿을 수 있는 빌드" 가 결과를 더 크게 좌우합니다. AI 코딩을 "루프 엔지니어링" 이라고 부르는 이유도 여기에 있습니다. 피드백 루프의 속도가 전부라는 뜻입니다.
거대한 모노레포라도 AI에게 가르쳐야 할 정규 패턴(canonical pattern)은 100줄 남짓입니다. 이 패턴을 명시적으로 선언해 두자는 것이 "결정론적 엔지니어링(Deterministic Engineering)" 의 주장입니다.
AI는 "에러 없이 돌아가는 코드" 를 만드는 데 최적화되어 있습니다. 하지만 에러가 나지 않는 것과 의도대로 동작하는 것은 전혀 다른 문제입니다.
| 항목 | 확인할 점 |
|---|---|
| 테스트 통과 ≠ 동작함 | 테스트가 통과해도 실제 요구사항을 만족하는지는 따로 확인합니다. |
| 조용한 실패 | 예외를 삼키거나 기본값으로 넘어가 아무 일도 없었던 것처럼 보이는 코드를 의심합니다. |
| 파괴적 작업의 기본값 | 문법적으로 완벽하고 리뷰에서도 눈에 띄지 않지만, 데이터를 날리는 코드가 있습니다. |
| 경계에서 검증 | 타입은 런타임에 사라집니다. 외부 입력은 경계에서 직접 검증합니다. |
| 첫 패턴의 영향력 | AI는 옆 코드를 복제합니다. 처음 들어간 패턴이 코드베이스 전체를 결정합니다. |
| 스펙 자체의 모순 | AI는 서로 모순되는 요구사항도 그럴듯하게 "구현"합니다. |
| 영어 중심 가정 | 학습 데이터가 압도적으로 영어라서 한글·전각 문자·한국 주소·주민번호·원화 단위에서 같은 종류의 버그가 반복됩니다. |
AI가 만든 코드를 전부 꼼꼼히 읽는 것은 지속 가능하지 않습니다. 읽는 양을 줄이면서 놓치지 않는 방법이 필요합니다.
rg 로 검사할 수 있게 씁니다. 취향에 기대는 규칙은 지켜지지 않고, grep으로 잡히는 규칙은 지켜집니다.